När man inför ett nytt IT-system – till stöd för till exempel rekrytering, arbetsmiljö, kompetensutveckling eller reseräkningar, för att nämna några, ändrar man samtidigt sättet man arbetar med och hanterar dessa uppgifter. Det går inte att hitta ett systemstöd för exakt de rutiner man råkar ha på det egna företaget ens om man skulle bygga ett skräddarsytt system. Den här insikten leder inte sällan till besvikelser och frustration. Jag erkänner gärna att jag hör till dem som har klagat på att IT-systemen är alltför oflexibla och att de inte stöder de egna, befintliga processerna tillräckligt bra. Vi kan bejaka ett stöd för det egna sättet att arbeta, så länge det inte innebär att vi måste ändra på oss i en annan ände. Och vet ni vad? Vi har helt rätt. Att ändra arbetssätt kan vara nyttigt och nödvändigt, men det kan också vara destruktivt och leda till ineffektivitet.
Att bryta invanda mönster kan vara exakt det som behövs, särskilt om de är ineffektiva och/eller ogenomtänkta. Men vissa av våra mest inarbetade rutiner är effektiva och smidiga och utgör ett viktigt strukturkapital i vår organisation. Kan man hitta system som stöder de bästa av dessa processer och rutiner är det förstås utmärkt. Om inte, måste vi fundera på om vinsten i någon annan ände är tillräcklig för att motivera att vi river upp och ändrar på väl fungerande arbetssätt. Det mest destruktiva är förstås om vi inför ett system som tvingar oss att ändra våra bästa rutiner, men håller oss kvar i dem vi borde ha ändrat. Haken är att det är svårt att avgöra vad som är vad. I kritiken mot det nya systemet kommer det att låta som om alla förändringar blir ineffektiva och dåliga. Skepsisen mot förändringar är mänsklig och naturlig alldeles särskilt när det rör det egna arbetet och ännu mer om beslutet tagits snabbt och utan förankring.
Ett sätt att öka sannolikheten för ett lyckat systeminförande är att så långt det är möjligt skilja mellan utvecklingen av arbetssätt och införande av system. I sin renaste form går man först igenom vilka processer som är effektiva och vilka som inte är det, vilka som skulle vinna på systemstöd och vilka som inte skulle det. När man sonderar marknaden för de aktuella systemen, blir en viktig parameter om systemen ger stöd för rätt slags processer, nämligen dem man vill behålla och effektivisera. Om man sedan måste ändra några av de mindre effektiva arbetssätten, är det lättare att svälja.
I de fall vi har att göra med införande av system inom ett helt nytt område, är möjligheterna till ett lyckat införande närmast oändliga. Tricket där är att bilda sig en uppfattning om hur man vill arbeta innan man beslutar sig för vilket systemstöd man vill ha. Inget system i världen kan hjälpa ett företag att bli bra på ett nytt område om man inte vet vad man är ute efter först. Om man vill kalla det för behovs- eller kravanalys går det bra, men det är egentligen inte specifikationerna för vad systemet ska klara av eller ens uppnå jag är ute efter här, utan vilka processer som stöds. Om vi inte har några processer för systematiskt arbetsmiljöarbete eller kompetensutveckling, för att ta några exempel, vet vi heller inte vilka processer vi ska effektivisera genom vårt system. Vår viktigaste behovsanalys består därför av att införa arbetssätt, processer och rutiner först, för att därefter leta systemstöd. Till en början kan vi använda oss av intranät, kalendrar och mailsystem som stöd för våra nya uppgifter. Om vi tror att det är för många inblandade för att det ska gå att genomföra dessa nya arbetssätt, är det garanterat för många för att ett system ska gå att införa samtidigt.
Är vi lite fiffiga, har vi redan tjuvkikat på vilka system som finns, så att vi redan från början inför arbetssätt som kan få stöd genom något befintligt system. När vi väl har ett sätt att arbeta med arbetsmiljö eller kompetensutveckling, där tågordning, datum, ansvar och dokumentation är igång och fungerar, är det inga problem att införa ett stöd för precis de processer vi redan har.
Motsatsen, som tyvärr är relativt vanlig, att man inför ett system för att “komma igång” med ett nytt område, fungerar sällan. Det slutar ofta med ett underutnyttjande av systemet och därmed också med ett ifrågasättande av hela området.
I de flesta fall inför vi system till stöd för redan etablerade funktioner. Även där har vi, som beskrevs i inledningen, en hel del att vinna på att skilja mellan utveckling av arbetssätt och införande av system. Om vi hittar system som ger stöd för de bäst fungerande processerna och som tvingar oss att byta endast dem som inte fungerar lika bra, kommer införandet att tas emot positivt. Det kan vara en poäng även i dessa fall, att ändra på de processer som måste ändras först, innan vi inför systemet. Om systemet till exempel förutsätter en viss dokumentations- eller beslutsordning, kan vi införa den redan innan vi inför systemet. På det sättet kommer systemet att upplevas för vad det är och stödet för de väl fungerande processerna kommer att uppskattas efter förtjänst. Vi har hunnit gnälla av oss det värsta redan när vi införde de nya rutinerna utan systemstöd. Med lite tur har vi kommit att uppskatta några av dem när det är dags för systeminförandet.
Sammanfattningsvis kan det vara klokt att fundera några extra varv innan man inför ett IT-stöd för en viss funktion. Vad vill vi ha stödet till? Vilka strukturer och rutiner kommer att beröras? Riskerar vi att riva upp fungerande samarbeten och slå sönder effektiva flöden genom införandet? Vad behöver vi i så fall göra för att det ändå ska fungera? Vad kan vi ändra på i förväg, vad kan vi testa, och framför allt: har vi totalt sett mer att vinna än att förlora på att införa systemet?