Bygge selv eller kjøpe et ferdig system?

Start med det som allerede finnes

Jeg synes det er en styrke å kunne anbefale en ferdig løsning når den passer. Egenutvikling binder tid og oppmerksomhet til vedlikehold, videreutvikling og drift. Den forpliktelsen bør gi noe verdifullt tilbake.

Begynn derfor med å prøve aktuelle standardsystemer på den virkelige arbeidsflyten. Bruk egne, ufølsomme testeksempler. En demonstrasjon viser gjerne den ryddigste veien gjennom produktet. Du trenger også å se hva som skjer ved feil, endringer og unntak.

Skill mellom særpreg og gammel vane

En arbeidsprosess kan være spesiell fordi virksomheten skaper verdi på en annen måte enn konkurrentene. Den kan også være spesiell fordi den har vokst frem rundt gamle verktøy. Det er verdt å undersøke forskjellen før dagens rutiner blir en kravspesifikasjon.

Tenk på en bedrift som sender tilbud. Kanskje tilbudsformatet er en vane som enkelt kan endres. Men måten pris, kapasitet og leveransetid beregnes på kan være sentral for konkurransekraften. Da kan det være riktig å bruke en standardløsning til dokumentene og utvikle beregningen særskilt.

Det finnes et mellomrom mellom kjøpe og bygge

Valget er ofte en kombinasjon. Dere kan kjøpe et system for kundebehandling og bygge en avgrenset integrasjon. Eller beholde et eksisterende fagsystem og lage et enklere grensesnitt for en bestemt brukergruppe.

Denne løsningen har også kostnader. Undersøk om leverandøren gir tilgang til nødvendige data, hvilke begrensninger grensesnittet har og hva integrasjonen koster å holde ved like. En liten kobling kan bli kritisk hvis hele arbeidsflyten avhenger av den.

Sammenlign over tid

Sett opp et flerårig regnestykke med de samme postene for alternativene. Ta med lisenser, innføring, migrering, opplæring, integrasjoner, drift og endringer. For egenutvikling må noen også eie produktprioriteringene. For standardsystemer må dere regne med arbeidet ved å tilpasse prosessene.

Bruk flere scenarioer dersom antall brukere eller datamengden er usikker. Et alternativ kan være rimelig i starten og dyrt når bruken vokser. Samtidig kan det være fornuftig å betale for fleksibiliteten til å prøve behovet før dere bygger selv.

Planlegg hvordan dere kan komme dere videre

Før valget tas, bør dere vite hvordan data kan eksporteres og hvem som har tilgang til dem. Ved egenutvikling gjelder det samme for kildekode, dokumentasjon og driftskontoer. Handlingsrom ved et senere bytte er en del av beslutningen.

Mitt utgangspunkt ville vært å velge den enkleste løsningen som dekker de viktige behovene og gir akseptabelt handlingsrom. Bygg selv der forskjellen er viktig nok til at dere ønsker å eie ansvaret.

• Hva må være annerledes enn i et standardprodukt?
• Hvilke arbeidsvaner kan vi endre?
• Kan vi kombinere en standardløsning med avgrenset utvikling?
• Hva blir samlet kostnad over flere år?
• Hvordan kan vi hente ut data og bytte løsning senere?