Poenget er ikke å bremse. Poenget er at hvis dere kan svare godt på hvorfor de billigere alternativene ikke holder, står anskaffelsen mye sterkere — internt, i budsjettprosessen, og overfor dem som skal ta systemet i bruk.
De fem alternativene, fra billigst til dyrest
| Alternativ | Passer når | Typisk kostnad |
|---|---|---|
| Endre rutinen | Problemet er rekkefølge, ansvar eller ventetid | Timer |
| Bruke det dere har bedre | Funksjonen finnes, men er ukjent eller avslått | Opplæring og konfigurasjon |
| Utvide eksisterende system | Én mangel i en løsning som ellers fungerer | Modul eller integrasjon |
| Bytte ut ett system | Løsningen er utdatert eller går ut av support | Anskaffelse |
| Bytte ut flere systemer samtidig | Landskapet henger sammen og må skiftes samlet | Program med flere leveranser |
Gå gjennom dem ovenfra og ned, og skriv én setning om hvorfor hvert alternativ ikke holder. Er den setningen vanskelig å skrive, har du funnet noe verdifullt.
Overraskende ofte finnes funksjonen allerede i et system dere har, men den er aldri skrudd på, aldri lært bort, eller kjent bare av tre personer. Sjekk det før dere skriver kravspesifikasjon — det tar en dag og har spart mange for et årsverk.
Når systemet ikke er problemet
Noen problemer ser ut som systemproblemer og er det ikke:
- Uklart ansvar. Når ingen vet hvem som eier en oppgave, hjelper det lite å digitalisere den. Se systemet uten eier.
- For lite folk. Et system som effektiviserer 15 prosent løser ikke en underbemanning på 40.
- Dårlige data. Flytter du rotete data til et nytt system, får du rotete data i et nytt system. Ryddingen må skje uansett.
- Uenighet om hva som er riktig praksis. Det må avgjøres av mennesker før det kan bygges inn i noe.
Når svaret er ja
Det er det ofte, og med god grunn: leverandøren varsler at støtten opphører, kravene til sikkerhet eller universell utforming har endret seg, volumet har vokst forbi det løsningen tåler, eller dagens systemer ikke kan snakke sammen uten manuelt arbeid.
Da har du i tillegg fått noe verdifullt ut av øvelsen: en tydelig begrunnelse som kan stå rett inn i formål og bakgrunn.
Skriv ned vurderingen
En halv side der alternativene er listet og forkastet med begrunnelse. Den siden blir brukt flere ganger enn du tror: i beslutningsnotatet, i kravspesifikasjonens bakgrunnskapittel, og den dagen noen spør hvorfor dere ikke bare utvidet det gamle.
Vanlige feil
- Alternativene vurderes av dem som allerede har bestemt seg. Be noen utenfor prosjektet lese vurderingen.
- «Systemet er gammelt» brukes som begrunnelse. Alder er ikke et problem. Manglende støtte, sikkerhetshull eller kapasitet er.
- Rutineendring avvises fordi den er upopulær. Den blir ikke mer populær av å komme sammen med et nytt system.
- Vurderingen skrives i etterkant. Da er den en begrunnelse, ikke en beslutning.