Varför jakten på hastighet skapar morgondagens mjukvaruproblem

Trycket att leverera ERP och affärskritisk mjukvara snabbare skapar ofta dolda kostnader som organisationer så småningom måste hantera, hävdar Carl Andrews, VD, Original Software.

Varje CIO har suttit igenom en go-live-fest. Kakan, gratulationerna, lättnaden över att något äntligen har skickats. Det som diskuteras mindre är vad som händer i månaderna efter, när trycket att leverera i tid har tyst överfört kostnaderna till teamen som är kvar för att underhålla det som har skickats.

Detta är inte ett nischproblem. Drivet för snabbare mjukvarudistribution accelererar, inte bromsar. Sprintcykler blir kortare, utgivningsfrekvenser ökar och förväntningen att tekniken ska svara på affärsbehov nästan i realtid är nu standard. Att flytta snabbare är vanligtvis rätt instinkt. Frågan är vad som tyst offras för att göra det hända.

Där skulden börjar

Teknisk skuld dyker sällan upp med en varning. Den byggs genom beslut som, individuellt, verkar helt försvarbara. Dokumentationen hamnar längst ner på prioritetslistan eftersom teamet måste nå en deadline. En lösning läggs till i en ERP-konfiguration eftersom den riktiga lösningen skulle försena projektet. Testningen minskas eftersom tidslinjerna redan är på glid.

En anpassning lämnas på plats eftersom att ersätta den känns för störande.

Ingen sätter sig ner för att ackumulera skuld. Det är vad som finns kvar efter en serie rimliga beslut som fattas under tryck. Vad som började som några genvägar blir ett system som är svårare att ändra, bryter oftare och kostar mer att underhålla än någon budgeterat för.

ERP-miljöer är särskilt sårbara. Av sin natur sitter de i centrum av organisationen, anslutna till ekonomi, HR, leverantörskedja, inköp och andra kritiska affärsfunktioner. Över tiden skapar år av genvägar, lösningar och dåligt dokumenterade ändringar en komplexitet som ingen avsåg, men alla ärver. Resultatet är förutsägbart, även om tidpunkten inte är ett problem som borde ha upptäckts under testning, utan i live affärsprocesser, vanligtvis vid den sämsta möjliga tidpunkten.

Varför organisationer underskattar problemet

En del av utmaningen är att teknisk skuld sällan visas som en uppenbar kostnad. Till skillnad från ett misslyckat projekt eller en missad deadline ackumuleras skulden gradvis. Den visar sig som uppgraderingar som tar längre tid än förväntat. Ändringar som kräver mer ansträngning än de borde. Team som tillbringar veckor med att utreda problem som tidigare skulle ha varit lätta att lösa.

Eftersom dessa kostnader dyker upp långsamt behandlas de ofta som isolerade incidenter snarare än symtom på ett bredare problem. Organisationer tenderar att fokusera på de synliga fördelarna med att leverera snabbt medan de försummar de långsiktiga konsekvenserna av att göra system svårare att underhålla och utveckla.

Resultatet är att teknisk skuld ofta får uppmärksamhet först när den börjar påverka affärsprestation.

Impacten på innovation, produktivitet och motståndskraft

Den största kostnaden för teknisk skuld är inte vanligtvis teknisk. Den är strategisk. När ERP-miljöer blir mer komplexa tillbringar IT-team mer tid med att underhålla befintliga system och mindre tid med att leverera nya funktioner. Resurser som kunde ha stöttat transformationsprojekt, processförbättringar eller AI-initiativ konsumeras i stället av felsökning, ombyggnad och systemunderhåll.

Innovationen bromsar eftersom varje ändring medför större risk. Produktiviteten lider eftersom rutinuppgifter tar längre tid att slutföra. Motståndskraften minskar eftersom systemen blir svårare att testa, stödja och återställa när något går fel. Detta skapar en frustrerande cykel. Organisationer trycker på för att hålla jämna steg, men den skuld som skapas av den hastigheten gör framtida förändringar långsammare, dyrare och svårare att leverera.

Att hitta rätt balans

Svaret är inte att sakta ner. Få organisationer kan förmå sig att göra det. Målet är att bygga leveransprocesser som stöder hastighet utan att kompromissa med långsiktig kvalitet. Det börjar med att erkänna att aktiviteter som testning, dokumentation och styrning inte är hinder för leverans. De är vad som gör hållbar leverans möjlig. För ERP-system i synnerhet är robust återkopplings-testning av avgörande betydelse.

Det ger organisationer förtroende för att ändringar, uppdateringar och uppgraderingar kan införas utan att skapa oväntad störning någon annanstans i verksamheten. I kombination med större automatisering och tidigare testning under leveranscykeln hjälper det till att identifiera problem innan de blir dyra problem.

Det viktigaste är att organisationer måste se teknisk skuld som ett affärsproblem snarare än ett tekniskt problem. Beslut som fattas för att påskynda leverans idag kommer att påverka kostnaden, flexibiliteten och motståndskraften hos systemen under många år framöver.

Go-live är inte målgången. Det är bara den punkt där de långsiktiga konsekvenserna av dessa beslut börjar visa sig. De organisationer som lyckas över tid kommer inte att vara de som flyttar snabbast på kort sikt, utan de som kan fortsätta att förändras och innovativa utan att hindras av de system de är beroende av.