Att byta system handlar om att tvingas göra avkall

Systembyten föregås nästan alltid av en behovsanalys med syfte att klarlägga behov och krav. Resultatet sammanställs i en kravspecifikation som används för att utvärdera och välja system. Grundtanken med behovsanalysen och kravspecifikationen är att säkerställa att det nya systemet innehåller den funktionalitet som krävs för att alla verksamhetsprocesser ska få rätt stöd inför framtiden.

Behovsanalysen och kravunderlaget präglas av övertygelsen att kunna skapa förbättringar för verksamheten. I bristande underlag framgår inte hur förbättringen ska uppnås annat än att försöka tolka syftet med kraven och de bästa fallen framgår det tydligt exakt på vilket sätt som förbättringen kommer att uppstå.

Det som dock sällan eller aldrig framkommer med tydlighet är att ”ALLA” systembyten även handlar om att göra avkall. I 100 % av samtliga systembyten finns det alltid funktioner eller rutiner där kunden tvingas att göra avkall på något som faktiskt fungerar bra i den befintliga lösningen. Det kan handla om att informationen för en enskild användare i det gamla systemet är sammanställd på en enda översiktlig sida medan det nya systemet medför minst 3-4 sidor för att få motsvarande översikt. Det kan vara registreringsflöden där det nya systemet kräver fler handgrepp jämfört med det gamla systemet. Det kan också handla om att unika funktioner faktiskt saknas och där utveckling av motsvarande information inte är ekonomiskt försvarbar. Listan kan göras väldigt lång över exempel på ”försämringar” som kan uppstå som följd av ett systembyte. I de flesta fall vägs dessa försämringar med råge upp av alla förbättringar som samtidigt kan realiseras, i annat fall hade inte systembytet kunnat motiveras.

Dessa försämringar är ofta en blandning mellan ”faktiska” försämringar och ”upplevda” försämringar. Med upplevd försämring menas i detta sammanhang att den enskilda användaren upplever systemet som sämre därför att det är annorlunda jämfört med gamla systemet och där logiken för att hitta information och följa arbetsflöden präglas av ”helhetssynen” istället för att det ska vara optimalt för varje enskild användare i varje enskild situation. Med faktisk försämring menas att det nya systemet helt eller delvis hindrar användaren att utföra sin arbetsuppgift effektivt och där nyttorna för helheten inte kan uppväga försämringen för den enskilde.

Även om nya system i allmänhet innehåller fler funktioner samt fler möjligheter jämfört med det gamla systemet så kommer det alltid finnas brister. Även en sådan sak som att det gamla systemet var ”enklare” kan upplevas som en brist/problem när ett nytt och mer innehållsrikt system införs. Trots alla nya finesser och möjligheter så kräver kanske det nya systemet mer utbildning och även mer arbetstid för registrering. Det gamla systemet kanske var väldigt öppet och medförde väldigt många fel pga användare med olika sätt att registrera information och att motsvarande problem aldrig kan uppstå i det nya systemet. Det spelar ingen roll – användarna kommer ändå hävda att det gamla systemet var bättre för att det var enklare.

Inför ett systembyte är det viktigt att ha förståelse för att försämringar kommer att uppstå. Lika viktigt är att försöka förutse vart och hur dessa försämringar kommer att uppstå. Med denna förståelse och en proaktiv behandling av dessa områden kan man förebygga problem som annars uppkommer när användarna börja skälla på systemet och projektgruppen som genomfört implementeringen. Det är därför viktigt att i arbetet med behovsanalys och kravframtagning även fånga de försämringar som kan uppstå och lägga dem i fokus inför det kommande förändringsarbete som alltid krävs vid ett systeminförande.