Frågor som kommer före systemvalet
System bör bedömas utifrån verksamheten, inte som produktjämförelse. Följande frågor säger mer om utfallet än en funktionslista gör.
- Vilket verksamhetsproblem ska systemet lösa?
- Var skapas informationen, och vem ansvarar för den?
- Vem använder den, och vilka andra system behöver den?
- Vilka manuella överlämningar finns, och var uppstår informationsförlust?
- Vad ska kunna följas upp, och vilka beslut ska informationen stödja?
När systemet finns men inte används
Det svåraste läget är inte att sakna systemstöd, utan att ha det och ändå inte använda det. Införandet är avslutat, licenserna betalda, och den information arbetet faktiskt styrs av ligger i ett kalkylblad.
Det tolkas ofta som ovilja. Det är sällan det. Människor väljer det som fungerar för uppgiften framför sig, och kräver systemet fler steg än kalkylbladet för samma resultat är valet redan gjort.
Var bristen brukar sitta
När problemet lokaliseras visar det sig ofta vara avgränsat, och därmed möjligt att rätta i det system som redan finns.
- Ett obligatoriskt fält som inte går att fylla i vid det tillfälle steget utförs.
- En behörighet som saknas för den som ska göra jobbet.
- Ett steg som lades in för en organisation som inte längre ser ut så.
- Information som krävs men skapas först senare i processen.
Dubbelregistrering och parallella spår
Registreras samma uppgift på två ställen finns två versioner, och ingen av dem är entydigt den rätta. Det är sällan lättja – det är oftast en logisk anpassning till att systemet inte räcker för uppgiften.
Att leta efter dubbelregistrering är därför ett effektivt sätt att hitta var processen och systemet glider isär.
Innan ni byter system
Ett systembyte som görs utan att den konkreta bristen är lokaliserad flyttar problemet i stället för att lösa det, och tar med sig både kalkylbladen och det parallella arbetssättet in i det nya systemet.
Det är inget argument mot att byta. Ibland är verktyget verkligen fel. Men bytet bör vara en följd av analysen, inte ett substitut för den.