Bør vi bygge det? Spørsmålet vi stiller før vi skriver noen kode

Når en organisasjon henvender seg til et programvareutviklingsselskap, er forventningen vanligvis at samtalen ender i et forslag om å bygge noe: en ny applikasjon, en erstatning for et aldrende system, en plattform som binder sammen frakoblede prosesser. Det er en forståelig antakelse, men den hopper over et spørsmål som bør besvares før noen snakker om teknologi, budsjetter eller leveringsdatoer.

Bør vi egentlig bygge det?

Hos Libertas Software Research (LSR) mener vi at det er like viktig å vite om man skal utvikle programvare som å vite hvordan. Noen ganger er en skreddersydd applikasjon akkurat det som trengs. Andre ganger dekker en etablert SaaS-plattform behovet utmerket, eller det å koble sammen systemene man allerede har gir resultatet uten kostnaden og forstyrrelsen ved å erstatte dem. Målet er å forbedre hvordan en organisasjon fungerer, ikke å legge til enda en applikasjon i et allerede komplisert miljø.

Start med problemet, ikke løsningen

Organisasjoner har en tendens til å beskrive løsningen de tror de trenger, i stedet for problemet de har. «Et rapporteringsdashbord» eller «en app som erstatter regnearkene våre» høres godt definert ut, men sier lite om hva som utløste forespørselen.

Ta en månedlig ledelsesrapport som settes sammen for hånd fra flere regneark og systemer. Den tar dager, og når den lander, er dataene allerede utdaterte. Den åpenbare konklusjonen er at du trenger rapporteringsprogramvare. Ser man nærmere etter, er det egentlige problemet ofte frakoblede data og uensartede prosesser: et beskjedent integrasjonsprosjekt, ikke en ny applikasjon. Og hvis undersøkelsen viser at du trenger spesialiserte arbeidsflyter eller kontroller som ingen produkter støtter, er det da skreddersøm fortjener sin plass.

Når det gir mest mening å kjøpe

Det kommersielle markedet er modent. CRM, regnskap, planlegging, dokumenthåndtering og business intelligence har alle produkter med mange års forfining bak seg. Hvis ett av dem dekker behovene dine uten urimelige begrensninger, tilfører en skreddersydd erstatning lite verdi.

Men sammenlign total eierkostnad, ikke abonnementspriser. Et produkt til 500 £ i måneden er 30 000 £ over fem år, før du legger til konfigurasjon, integrasjoner, ekstra lisenser eller endringer i dine egne prosesser. Sjekk hvordan prisen skalerer, om du kan eksportere dataene dine, og hva som skjer hvis leverandøren endrer modellen sin. Og vær forsiktig med å tvinge virksomheten til å gi opp aktiviteter som virkelig skiller den ut, bare fordi et produkt forutsetter noe annet.

Noen ganger er svaret å koble sammen det du allerede har

De fleste organisasjoner samler på seg systemer over tid: økonomi i ett, drift i et annet, kundeservice i et tredje. Hvert fungerer fint; de snakker bare ikke sammen, så man får forsinkelser, dobbeltarbeid og inkonsistent informasjon.

Det er fristende å erstatte alt med én applikasjon, men det er risikabelt. Eksisterende plattformer rommer års driftskunnskap og skjulte integrasjoner. Et gjennomtenkt integrasjonslag (kobling av API-er, automatisering av overføringer, konsolidering av rapportering fra autoritative kilder) kan forlenge levetiden til disse investeringene. Det krever god omtanke rundt autentisering, dataeierskap, feilhåndtering og sporbarhet, men å anbefale integrasjon fremfor erstatning er ikke dårligere ingeniørarbeid. Det er ofte den mer gjennomtenkte arkitekturbeslutningen.

Når skreddersydd er den rette investeringen

Noen krav passer virkelig ikke inn i vanlige produkter: spesialisert drift, uvanlige sikkerhets- eller databehov, eller programvare som i seg selv er et konkurransefortrinn. Her lar skreddersydd programvare arkitekturen følge hvordan virksomheten faktisk jobber.

Den fleksibiliteten følger med et langsiktig ansvar for vedlikehold, sikkerhet, testing og support. Et system kan oppfylle sin opprinnelige spesifikasjon og likevel være en dårlig investering hvis det er vanskelig å vedlikeholde eller ikke kan tilpasses. Skreddersydd utvikling er berettiget når fordelene ved en spesialbygd løsning veier tyngre enn både startkostnaden og den løpende forpliktelsen det er å eie den.

Ikke alle problemer trenger mer programvare

Noen ganger er prosessen problemet. Godkjenninger, rapporter og administrative trinn hoper seg opp gjennom årene, lenge etter at omstendighetene som skapte dem er borte. Å automatisere dem akkurat slik de er, bevarer bare kompleksiteten.

Hvis et dokument trenger fem godkjenninger, ikke spør hvordan man automatiserer fem godkjenninger, spør hvorfor hver enkelt finnes og hvilken risiko den dekker. Programvare er utmerket til å anvende konsekvente regler, men kan ikke fortelle deg om prosessen er fornuftig. Å forenkle en arbeidsflyt eller klargjøre eierskap kan gi reelle gevinster uten enda et system å lære og støtte.

Se utover startkostnaden

Skreddersydde prosjekter har en stor startkostnad mens SaaS sprer sin over abonnementer, noe som får sammenligningen til å se skjev ut. En rettferdig sammenligning dekker hele levetiden: implementering, lisensiering, hosting, support, vedlikehold, integrasjon, opplæring og fremtidige endringer.

Ta også med kostnaden ved å la være. En ineffektiv prosess som sluker 20 arbeidstimer i uken er rundt 1040 timer i året. Med en illustrativ sats på 35 £ i timen er det omtrent 36 400 £ årlig, forutsatt at tiden faktisk kan gjenvinnes og omdirigeres. Legg til dårlig datakvalitet og trege beslutninger, som er vanskeligere å prissette, men like reelle. Det beste alternativet er ikke det billigste, men det med den sterkeste blandingen av verdi, akseptabel risiko og langsiktig bærekraft.

Hvorfor skulle et programvareselskap anbefale å ikke bygge programvare?

Det er et rimelig spørsmål. Hvis vi anbefaler et produkt eller en liten integrasjon, er det mindre utviklingsarbeid på papiret.

Men det er forskjell på å levere utviklingskapasitet og å fungere som partner innen programvareforskning og arkitektur. Arbeidet vårt begynner før spesifikasjonen finnes: forstå problemet, veie alternativene og hjelpe deg med å bestemme hvor du skal investere. Det har verdi uansett utfall, og det er som regel fortsatt analyse-, arkitektur-, planleggings- og integrasjonsarbeid å gjøre selv når skreddersydd utvikling ikke er svaret.

Å anbefale utvikling du ikke trenger er kontraproduktivt. Et prosjekt levert i tide og etter spesifikasjon mislykkes likevel hvis det ikke var den riktige løsningen. Å hjelpe en kunde med å unngå unødvendige utgifter bygger den typen tillit som varer.

Å kunne bygge er ikke en grunn til å bygge

AI og moderne verktøy gjør kode raskere og billigere å produsere. Det er nyttig, men det gjør tenkingen i forkant viktigere, ikke mindre, fordi innsatsen som en gang tvang folk til å spørre «trenger vi egentlig dette?» er i ferd med å forsvinne. Det er fullt mulig å bygge noe teknisk utmerket, levere det effektivt og oppdage at det var feil svar.

Før utviklingen begynner, vil vi ha klare svar på forretningsproblemet, kostnaden ved å la det være uløst, hvilke krav eksisterende produkter ikke kan oppfylle, hvordan suksess skal måles (behandlingstid, nøyaktighet, oversikt, etterlevelse, ikke antall funksjoner) og hvem som skal drifte og støtte løsningen etterpå.

Det vil være prosjekter der skreddersydd programvare er klart riktig, andre der integrasjon gir bedre verdi, og andre der en ferdig plattform gjør jobben. Det som betyr noe er at anbefalingen følger av forståelsen av din organisasjon, ikke av en antakelse om hva et programvareselskap vil selge.

Før man spør hvordan vi bør bygge noe, er det verdt å avklare om vi i det hele tatt bør bygge det.

Libertas Software Research jobber med organisasjoner for å undersøke, evaluere, designe og utvikle programvareløsninger, med fokus på langsiktig vedlikeholdbarhet, driftsverdi og veloverveide teknologiinvesteringer.