Tidigare resultat är inte indikativa för framtida resultat – såvida det inte är kostnaden för kod, data och applikationer

Detta är bland mycket annat den tid på året då finansiella rådgivare skickar mig e-postmeddelanden med en bokslutsvy av mina investeringar. Här är det exakta språket från en sådan rådgivare:

"Din fullständiga ekonomiska bild. En säker plats...Din instrumentpanel ger en realtidsöversikt över dina utgifter, sparande, skulder och mer med en enda inloggning...Planera för alla dina ekonomiska prioriteringar – och få en tydlig bild av ditt beräknade nettovärde."

Tänk på det - a fullständig finansiell bild som visar en realtidsvy över utgifter, sparande, skulder och mer? Vem vill inte veta vad de har beräknat nettovärde är ett, fem eller till och med tio år kvar? Teknikledare bör känna till denna information om sina teknikutgifter. Mitt tillvägagångssätt är baserat på ett enkelt faktum som jag har lärt mig genom årtionden av implementering av affärskritiska dataplattformar för företag runt om i världen:

Mycket få företag känner till eller förstår den totala kostnaden för sina applikationer – inklusive kod och data – över tiden, mycket mindre när de marknadsförs till produktion.

Företag som tror att de känner till dessa kostnader spårar sannolikt inte de faktiska konsumtionskostnaderna som påverkas av tillväxt och kapacitet (överskott eller brist).

Vad kan vi göra för att mäta den totala kostnaden för kod och därigenom spara miljarder på ineffektiva processer? Vi behöver insyn i de verkliga kostnaderna för applikationer, kod och data för att förstå de verkliga kostnaderna för våra system. Detta kan bara ske genom att skapa och stärka partnerskap mellan teknik och CFO:s kontor.

När man köper en applikation för att tillhandahålla en funktion för ett företag, kommer många att jämföra minst tre leverantörer om grunderna som funktionalitet, prissättning och support. Men en mer detaljerad analys av den totala ägandekostnaden (TCO) för den applikationen under tre år baserat på verkliga kostnader kan vara ett bättre tillvägagångssätt, eftersom om två applikationer i huvudsak är jämförbara, kommer TCO att skilja det bästa valet.

En utmaning är att de verkliga kostnaderna inte är offentliga. Dessutom vet många leverantörer verkligen inte vad kostnaderna är eftersom de bara vet vad deras applikation gör, inte vilken infrastruktur och vilka kostnader det kommer att ta för att köra applikationen för ditt företag i 3 till 5 år.

Ett annat sätt att se på det är: Vilken applikation kommer att kosta minst att implementera, hantera och underhålla under 3 till 5 år baserat på min affärsmodell och tillväxtmått?

Att gå till eran av effektivitet inom teknik, vad skulle det kunna innebära att mäta effektivitet över tekniksystem? Vi måste tänka på effektivitet i termer av tankesätt, handling och mätning.

• Hur kan vi ändra vårt tankesätt för att sätta effektivitet i kärnan i allt vi gör?
• Vilka åtgärder kan vi vidta för att bli mer effektiva?
• Hur kan vi mäta effektivitet?
• Vilka effekter har de vidtagna åtgärderna?

Hur branschen ser på kapacitet har inte förändrats på 20 år. Vi har varit villiga att leva med ineffektivitet så länge det inte finns några avbrott eller problem i produktionen. Men om något görs mer effektivt kommer det att kosta mindre och köras snabbare, och det blir mindre avfall i systemet, vilket innebär ett mindre koldioxidavtryck. Om något görs mer effektivt skapar vi mer kapacitet utan att behöva öka den, vilket bara sparar mer resurser, licenskostnader och pengar.

De designval vi gör för data när det gäller kodning, processer och datamodeller har alla bestående effekter på slutresultatet, både ur ett resursperspektiv och ännu viktigare på ekonomin, eftersom de flesta applikationer används i 10 till 20 år. Vad är den totala ägandekostnaden för den koden på lång sikt och hur kan detta påverkas under designprocessen? Om koden exekveras fem miljoner gånger om dagen och kostar 20 USD att köra idag, vad kommer det att kosta att köra över 5 år, med hänsyn till affärstillväxt, molnkostnader och att koden blir mer ineffektiv när den bearbetar ytterligare data?

Fördelar utöver kod. Poängeffektivitet börjar inom applikationer, men måste sedan spåra upp till det övergripande systemet och en dag, till företaget, för teknik. Att titta på den totala kostnaden för våra system från så tidigt som när designbeslut fattas fram till applikationens livslängd innebär att man inte bara ser på de ekonomiska kostnaderna för det övergripande systemet utan så småningom till den större miljön.

En sak har jag insett i min karriär: Den gemensamma kopplingen mellan allt vi gör, oavsett om det är prestanda, ekonomi eller miljön överlag – det handlar alltid om effektivitet och egentligen enkelhet, dvs hålla det enkelt dumt (KISS).

Precis som vi gör med våra finansiella räkenskaper behöver vi ett sätt att känna till våra teknikkostnader idag med mer klarhet och projicera kostnader inom vår teknikstack som sannolikt kommer att skjuta i höjden om de inte begränsas. Men till skillnad från dina finansiella konton, där "tidigare resultat inte är indikativa för framtida resultat", kan tidigare prestanda för dina koder berätta mycket om framtida resultat. Frågan är, är vi villiga att lyssna?