Ska vi bygga det? Frågan vi ställer innan vi skriver någon kod

När en organisation vänder sig till ett programvaruutvecklingsföretag är förväntan vanligtvis att samtalet slutar i ett förslag att bygga något: en ny applikation, en ersättare för ett åldrande system, en plattform som binder ihop frånkopplade processer. Det är ett förståeligt antagande, men det hoppar över en fråga som bör besvaras innan någon pratar om teknik, budgetar eller leveransdatum.

Ska vi egentligen bygga det?

På Libertas Software Research (LSR) tror vi att det är lika viktigt att veta om man ska utveckla programvara som att veta hur. Ibland är en skräddarsydd applikation precis rätt. Ibland täcker en etablerad SaaS-plattform behovet utmärkt, eller så ger det att koppla ihop de system man redan har resultatet utan kostnaden och störningen av att byta ut dem. Målet är att förbättra hur en organisation fungerar, inte att lägga till ännu en applikation i en redan komplicerad miljö.

Börja med problemet, inte lösningen

Organisationer tenderar att beskriva den lösning de tror att de behöver snarare än problemet de har. ”En rapporteringsdashboard” eller ”en app som ersätter våra kalkylblad” låter väldefinierat, men säger lite om vad som utlöste förfrågan.

Ta en månatlig ledningsrapport som sätts ihop för hand från flera kalkylblad och system. Den tar dagar, och när den landar är uppgifterna redan inaktuella. Den uppenbara slutsatsen är att man behöver rapporteringsprogramvara. Tittar man närmare är det verkliga problemet ofta frånkopplad data och ojämna processer: ett blygsamt integrationsprojekt, inte en ny applikation. Och om utredningen visar att man behöver specialiserade arbetsflöden eller kontroller som ingen produkt stöder, är det då skräddarsytt förtjänar sin plats.

När det är mer meningsfullt att köpa

Den kommersiella marknaden är mogen. CRM, redovisning, schemaläggning, dokumenthantering och business intelligence har alla produkter med många års förfining bakom sig. Om en av dem uppfyller dina behov utan orimliga begränsningar tillför en skräddarsydd ersättare lite värde.

Men jämför total ägandekostnad, inte abonnemangspriser. En produkt för 500 £ i månaden blir 30 000 £ över fem år, innan du lägger till konfiguration, integrationer, extra licenser eller ändringar i dina egna processer. Kontrollera hur prissättningen skalar, om du kan exportera dina data och vad som händer om leverantören ändrar sin modell. Och var försiktig med att tvinga verksamheten att överge aktiviteter som verkligen skiljer den åt bara för att en produkt förutsätter något annat.

Ibland är svaret att koppla ihop det man redan har

De flesta organisationer samlar på sig system över tid: ekonomi i ett, drift i ett annat, kundservice i ett tredje. Vart och ett fungerar bra; de pratar bara inte med varandra, så man får förseningar, dubbelarbete och inkonsekvent information.

Det är frestande att ersätta allt med en enda applikation, men det är riskabelt. Befintliga plattformar rymmer års driftskunskap och dolda integrationer. Ett noggrant utformat integrationslager (koppling av API:er, automatisering av överföringar, konsolidering av rapportering från auktoritativa källor) kan förlänga livslängden på de investeringarna. Det kräver gedigen eftertanke kring autentisering, dataägande, felhantering och spårbarhet, men att rekommendera integration framför ersättning är inte sämre ingenjörskonst. Ofta är det det mer genomtänkta arkitekturbeslutet.

När skräddarsytt är rätt investering

Vissa krav passar verkligen inte in i vanliga produkter: specialiserad verksamhet, ovanliga säkerhets- eller databehov, eller programvara som i sig är en konkurrensfördel. Här låter skräddarsydd programvara arkitekturen följa hur verksamheten faktiskt arbetar.

Den flexibiliteten kommer med ett långsiktigt ansvar för underhåll, säkerhet, testning och support. Ett system kan uppfylla sin ursprungliga specifikation och ändå vara en dålig investering om det är svårt att underhålla eller inte kan anpassas. Skräddarsydd utveckling är motiverad när fördelarna med en specialbyggd lösning överväger både startkostnaden och det löpande åtagandet att äga den.

Alla problem behöver inte mer programvara

Ibland är processen problemet. Godkännanden, rapporter och administrativa steg hopar sig genom åren, långt efter att de omständigheter som skapade dem försvunnit. Att automatisera dem precis som de är bevarar bara komplexiteten.

Om ett dokument behöver fem godkännanden, fråga inte hur man automatiserar fem godkännanden, fråga varför vart och ett finns och vilken risk det täcker. Programvara är utmärkt på att tillämpa konsekventa regler, men den kan inte säga om processen är rimlig. Att förenkla ett arbetsflöde eller tydliggöra ägarskap kan ge verkliga vinster utan ännu ett system att lära sig och supporta.

Se bortom startkostnaden

Skräddarsydda projekt har en stor startkostnad medan SaaS sprider sin kostnad över abonnemang, vilket får jämförelsen att se skev ut. En rättvis jämförelse täcker hela livslängden: implementering, licensiering, hosting, support, underhåll, integration, utbildning och framtida förändringar.

Räkna också med kostnaden för att inte göra något. En ineffektiv process som slukar 20 arbetstimmar i veckan är cirka 1 040 timmar om året. Till en illustrativ timkostnad på 35 £ blir det ungefär 36 400 £ årligen, förutsatt att tiden verkligen kan återvinnas och omdirigeras. Lägg till dålig datakvalitet och långsamma beslut, som är svårare att prissätta men lika verkliga. Det bästa alternativet är inte det billigaste, utan det med den starkaste blandningen av värde, acceptabel risk och långsiktig hållbarhet.

Varför skulle ett programvaruföretag rekommendera att inte bygga programvara?

Det är en rimlig fråga. Om vi rekommenderar en produkt eller en liten integration är det mindre utvecklingsarbete på pappret.

Men det är skillnad på att tillhandahålla utvecklingskapacitet och att agera som partner inom programvaruforskning och arkitektur. Vårt arbete börjar innan specifikationen finns: att förstå problemet, väga alternativen och hjälpa dig avgöra var du ska investera. Det har värde oavsett utfall, och det finns oftast fortfarande analys-, arkitektur-, planerings- och integrationsarbete att göra även när skräddarsydd utveckling inte är svaret.

Att rekommendera utveckling du inte behöver är kontraproduktivt. Ett projekt som levereras i tid och enligt specifikation misslyckas ändå om det inte var rätt lösning. Att hjälpa en kund undvika onödiga utgifter bygger den sortens förtroende som består.

Att kunna bygga är ingen anledning att bygga

AI och moderna verktyg gör kod snabbare och billigare att ta fram. Det är användbart, men det gör tänkandet i förväg viktigare, inte mindre, eftersom ansträngningen som en gång tvingade folk att fråga ”behöver vi verkligen det här?” håller på att försvinna. Det är fullt möjligt att bygga något tekniskt utmärkt, leverera det effektivt och upptäcka att det var fel svar.

Innan utvecklingen börjar vill vi ha tydliga svar om affärsproblemet, kostnaden för att lämna det olöst, vilka krav befintliga produkter inte kan uppfylla, hur framgång ska mätas (handläggningstid, noggrannhet, överblick, regelefterlevnad, inte antal funktioner) och vem som ska driva och supporta lösningen efteråt.

Det kommer att finnas projekt där skräddarsydd programvara är helt klart rätt, andra där integration ger bättre valuta och andra där en färdig plattform gör jobbet. Det som räknas är att rekommendationen följer av förståelsen för din organisation, inte av ett antagande om vad ett programvaruföretag vill sälja.

Innan man frågar hur vi ska bygga något är det värt att avgöra om vi överhuvudtaget ska bygga det.

Libertas Software Research arbetar med organisationer för att undersöka, utvärdera, utforma och utveckla programvarulösningar, med fokus på långsiktig underhållbarhet, operativt värde och välgrundade teknikinvesteringar.