iStone

Jag är affärsområdesansvarig inom Application Management på iStone. Vårt uppdrag är att hålla kundernas IT-system up and running och agera snabbt när det sker oväntade störningar. Enkelt beskrivet ser vi till att våra kunder kan sova gott om natten och att lampan blinkar grönt. Så fort något fallerar uppmärksammas det, ofta innan kunden själva märker något.

För att vi ska kunna leverera snabb och kompetent support krävs en genomtänkt och välsmord process för hur vi hanterar ärenden. För att ni ska få en liten inblick i hur vi jobbar med support på iStone tänkte jag i denna bloggpost dela med mig av hur det går till när vi hanterar kundärenden och vår metodik för att säkerställa effektiv support och förvaltning.

Ett kundärende föds

Alla ärenden hamnar hos iStones servicedesk till vilken kunderna även kan höra av sig direkt. Här finns personal med en väsentlig bredd – men även spets. Våra affärskonsulter och tekniker på support kan välja en eller flera nischer att fördjupa sig i. Sedan stöttar vi varandra med kompetens inom bolaget. Det innebär att många inkommande ärenden avhjälps av servicedesken. Det krävs något exceptionellt och ovanligt för att det ska gå vidare till nästa nivå.

Kniviga ärenden går till ett specialteam

Om ärendet är av en extra klurig karaktär går det vidare till ett lösningsteam. Här handlar det verkligen om ”rätt person på rätt plats”, och i typfallet ingår personer som jobbat med utrullningen av kundens projekt, som känner kunden väl och som byggt den lösning kunden har. Lösningsteamet använder hela iStone som kunskapsbank, det vill säga hela organisationens kompetens engageras vid unika och ovanliga problem. Då kan vi nästan alltid hitta någon som fixar det. Och vid särskilt unika fall kontaktar vi programvaruleverantören, det vill säga den som byggt programvaran som kunden använder.

Det finns alltid problem att eliminera

Mitt och mina kollegors arbete handlar till allra största del om ett ständigt pågående systemunderhåll och förbättringsarbete. De flesta ärenden som vi hanterar är mindre kritiska, men kan vara väldigt problematiska för den enskilda personen som rapporterat det. Det kan till exempel handla om en rapport som inte visar vad man förväntar sig eller programfel som medför att systemet går långsamt. Vi jobbar mycket med att hitta och identifiera grundorsaker till olika symptom och succesivt eliminera dessa, ett löpande underhåll som bidrar till systemets stabilitet.

Jag vill säga att detta löpande underhåll, i ständig dialog med kunden, är vår kärnkompetens inom Application Management. Kundperspektivet måste sitta i väggarna. Långsiktiga förändringar av kundens system görs dels som en respons på återkommande ärenden till servicedesken, och dels utifrån kundens konkreta önskemål, när till exempel någon ny funktionalitet efterfrågas.

Vi måste förstå kundens vardag

En annan viktig aspekt att tänka på är att systemet som kunden använder är inte till för sin egen skull, utan för den verksamhet som bedrivs. Många av de problem som vi åtgärdar har sitt ursprung i användarnas hantering av systemet. De kan till exempel använda en funktion på ett sätt som den inte var avsedd för eller testad för från början. Så det är viktigt att av vårt arbete möter kundens utmaningar i kundens verklighet. Våra system får aldrig begränsa användaren. Jag brukar säga att iStone ska vara oljan i kundens IT-maskineri

Inga dramatiska räddningsaktioner

Jag är som mest nöjd med mitt jobb när uppföljningsmötena med kunden tar en kvart och går ut på att konstatera att allt fungerar smidigt och att arbetet med att utveckla systemen går planenligt. Som IT-världens agenter genomför vi inga dramatiska räddningsaktioner, utan utför snarare ständig och noggrann övervakning, småfix och systemutveckling. Allt för att lampan även fortsättningsvis ska blinka grönt.

Vi stöttar idag Toyota Material Handling Europe med övervakning, incidentberedskap och annan support, 24/7.

Se hur vi gjort för att deras lampa ska lysa grönt

Diskutera detta inlägg

Rekommenderad läsning

I förra blogg-inlägget introducerades konceptet Data Entities. Här fortsätter beskrivningen av komposita entiteter och verktyget Data Management.
För att utveckla integrationer för tidigare versioner av AX krävdes god kunskap om tabellstrukturen och databasmodellen i AX. Bara att uppdatera t.ex. en kundpost var en stor utmaning och eftersom databasen i AX är väldigt normaliserad blev varje integration ofta onödigt jobbig att implementera. Förutom denna problematik hade man dessutom flera olika sätt att integrera på; Application Integration Framework (AIF),  Data Import- and Export Framework (DIXF) samt ren tabellimport/export vilket ständigt skapade diskussioner om vilken metod som var bäst för varje scenario.
Under Tech Conference i Mars 2017 presenterade Microsoft att Dynamics 365 for Operations kommer finnas tillgänglig i tre olika driftsalternativ; Public Cloud (släppt), Cloud+Edge (släpps dec 2017) samt Local Business Data (släppt).
90 % av dagens problem med Office-integration med AX handlar om autentisering, dvs åtkomst av data i AX begränsas av strul med behörigheter och Office-plugin. Detta har Microsoft tagit fasta på i 365 for Operations och en del av att förbättra användarupplevelsen handlar om att man öppnat upp möjligheten till att använda protokollet Open authentication (Oauth). Detta gör att andelen problem med autentisering ska minska och att användarupplevelsen ska bli bättre. Man har också ersatt AX-plugin:et i Excel med en mer dynamisk Dynamics 365 Data Connector. Denna fungerar både i lokal Excel, Excel Online samt även i Excel på iPad.
Hjälpfunktionaliteten har utvecklats stort i Dynamics 365 for Operations jämfört med tidigare releaser och här finns en del riktigt spännande nyheter. Hjälpen nås via frågetecknet i navigation bar och den första nyheten man ser är att det finns två sektioner i hjälpavsnittet; en som kallas Uppgiftsguider (Task guides) och en som kallas Wiki.