En supportfunktion (IT) har sitt ansvar i de flesta fall dokumenterade som SLA:er (Service Level Agreement). Dessa utgör grunden i vad som är överenskommet för supporten att ansvara för. I många fall inbegriper detta endast hårdvara och mjukvara som ligger i produktion, d.v.s. som är implementerat och är känt för användaren. Detta kopplas ihop med att stöd i form av verktyg, process och rutiner som supporten jobbar utefter. Att integrera Self Service som användarstöd för projektimplementationer, kan vara ett ”lycko-kast”.
Vid ett antal tillfällen under mina år inom IT Service & Support har jag hamnat i situation där förväntan på supporten är ”högre” än vad supporten är förberedda att hantera. Dessa situationer kan exempelvis vara diskussioner om tillgänglighet, innehåll, kostnad, hantering/administration, leveranstid mm. Förväntningarna intensifieras ofta när det är dags för förändring i form av nya system/applikationer, uppgradering, byte av hårdvara osv. För användaren startar då en process kring att ta emot och hantera förändringen, vilket i sig kan vara tufft att hantera oavsett om företaget har en låg IT mognad eller hög IT mognad.
Processen kan te sig olika ut – fast hanteras i samtliga fall på bästa sätt genom kommunikation. Att kommunicera och föda mottagaren med information om förändring är definitivt ett krav för att minimera motstånd i förändringen.
För supporten så är en förändring ofta ett lyft, fast det är inte alltid självklart att supportpersonalen har kunskap inom det nya området. För att implementera ett nytt system eller en applikation, så krävs att supporten har rätt kunskap för att hantera supportbehoven. Övergången till det “nya” bör hanteras så smidigt som möjligt, då det har en direkt inverkan i hur användaren upplever förändringen som positiv eller negativ. Oavsett om det ligger på den centrala supporten att ta hand om detta eller ett projektkontor, så är detta ett kritiskt ögonblick för förändringsimplementationen. Återigen – den centrala supporten jobbar utefter givna verktyg, processer och rutiner – projektet behöver därför även säkerställa implementationens användarstöd fullt ut.
Kommunikationsplanens värde
Det jag upplevt är att vid de tillfällen där användaren möts av bred information genom en genomtänkt kommunikationsplan, så har motståndet i regel varit som minst. Företag jobbar olika och har olika synsätt på detta – fast jag har ändå dragit slutsatsen att där förändring föregås av bra och genomtänkt kommunikation – så står man som vinnare.
Exempel på detta är att genomföra roadshows, utskick av regelbundna nyhetsbrev från projektet (riktat användaren), integrera kunskapsdatabas för systemet eller applikationen, erbjuda gemensam projektplats för användaren att följa projektets framfart. Alla dessa ovan resulterar i att antalet samtal inkommande supporten minskar genom att användaren själv kan finna svar på sina frågor om den kommande förändring. Värden som även inverkar mot användarens totala upplevelse av support leveransen. (Att hantera identifiera och hantera värden inm supportleverans, kommer jag att återkomma till i senare blogg)
Insamling av kunskap startar innan implementering
Jag har med mig ett antal projekt-implementationer av ex Windows, MS Office, SAP, uppgradering av hårdvara, byte av telefon växel mm, där etablering av projektplats samt kunskapsdatabas har visat positivt resultat och underlättat för supporten. Det som är en brist i detta är att projekt efterlämnar sig en bra kunskapsdatabas samt en projektplats där bra information och kunskap har samlats men överlämningen av dessa inte har skett till linjen vilket leder till att kunskapen ”tappas bort” så snart projektet avslutats.
När överlämning sker bör även denna typ av information och kunskap inbegripas i den generella KMDB som supporten arbetar i.
KMDB är hjärtat av Knowledge Management och kunskapen är dess syre!
Att etablera en Self Service tjänst som användarstöd för projekt implementationer är framgångsrikt – fast behöver integreras med de standardiserade verktyg, processer och rutiner som finns för att bli perfekt.
Att använda Self Service som användarstöd innan och under implementering gör att övergången mellan projekt och produktion upplevs liten utifrån användarens perspektiv. Används dessutom en och samma plattform för Self Service blir det till ett rent lycko-kast då kunskapen stannar i företaget och verksamheten så att den kan återanvändas även efter avslutat projekt.
@Jancan001, Jannica Wahlund, JanCan Konsult, www.jancan-konsult.com