Tidligere ytelse er ikke en indikasjon på fremtidige resultater – med mindre det er kostnadene for kode, data og applikasjoner

Blant mange ting er dette tiden på året da finansielle rådgivere sender meg e-poster med et årssluttsyn på investeringene mine. Her er det nøyaktige språket fra en slik rådgiver:

"Ditt komplette økonomiske bilde. Ett sikkert sted ... Dashbordet ditt gir deg en sanntidsvisning av forbruk, sparing, gjeld og mer med én enkelt pålogging ... Planlegg for alle dine økonomiske prioriteringer - og få en klar oversikt over den anslåtte nettoverdien din."

Tenk på det - a komplett økonomisk bilde som viser en sanntidsvisning av utgifter, sparing, gjeld og mer? Hvem vil ikke vite hva deres anslått nettoformue er ett, fem eller ti år ute? Teknologiledere bør vite denne informasjonen om deres teknologiforbruk. Min tilnærming er basert på et enkelt faktum jeg har lært gjennom flere tiår med implementering av virksomhetskritiske dataplattformer for bedriftsbedrifter over hele verden:

Svært få bedrifter kjenner eller forstår de totale kostnadene for applikasjonene deres – inkludert kode og data – over tid, langt mindre når de markedsføres i produksjon.

Selskaper som tror de vet disse kostnadene, sporer sannsynligvis ikke de faktiske forbrukskostnadene som påvirkes av vekst og kapasitet (overskudd eller mangel).

Hva kan vi gjøre for å måle den totale kostnaden for kode, og dermed spare milliarder på ineffektive prosesser? Vi trenger åpenhet om de sanne kostnadene for applikasjoner, kode og data for å forstå de sanne kostnadene til systemene våre. Dette kan kun skje ved å bygge og styrke partnerskap mellom teknologi og finansdirektørens kontor.

Når de kjøper en applikasjon for å tilby en funksjon for en bedrift, vil mange sammenligne minst tre leverandører på det grunnleggende som funksjonalitet, priser og støtte. Men en mer detaljert analyse av den totale eierkostnaden (TCO) for den applikasjonen over tre år basert på reelle kostnader kan være en bedre tilnærming, fordi hvis to applikasjoner i hovedsak er sammenlignbare, vil TCO skille det beste valget.

En utfordring er at de virkelige kostnadene ikke er offentlige. I tillegg vet mange leverandører egentlig ikke hva kostnadene er fordi de bare vet hva applikasjonen deres gjør, ikke hvilken infrastruktur og hvilke kostnader det vil ta å kjøre applikasjonen for virksomheten din i 3 til 5 år.

En annen måte å se det på er: Hvilken applikasjon vil koste minst å implementere, administrere og vedlikeholde over 3 til 5 år basert på min forretningsmodell og vekstberegninger?

Går til epoken med effektivitet innen teknologi, hva kan det bety å måle effektivitet på tvers av teknologisystemer? Vi må tenke på effektivitet i form av tankesett, handling og måling.

• Hvordan kan vi endre tankesettet vårt for å sette effektivitet i kjernen av alt vi gjør?
• Hvilke tiltak kan vi ta for å bli mer effektive?
• Hvordan kan vi måle effektivitet?
• Hva er konsekvensene av tiltakene som er iverksatt?

Måten bransjen ser på kapasitet har ikke endret seg på 20 år. Vi har vært villige til å leve med ineffektivitet så lenge det ikke er avbrudd eller problemer i produksjonen. Men hvis noe gjøres mer effektivt, vil det koste mindre og utføres raskere, og det er mindre avfall i systemet, noe som betyr et mindre karbonavtrykk. Hvis noe gjøres mer effektivt, skaper vi mer kapasitet uten å måtte øke den, som bare sparer mer ressurser, lisenskostnader og penger.

Designvalgene vi tar for data når det gjelder koding, prosesser og datamodeller har alle varige innvirkninger på bunnlinjen, både fra et ressursperspektiv og enda viktigere på økonomien, ettersom de fleste applikasjonene er i bruk i 10 til 20 år. Hva er den totale eierkostnaden for den koden på lang sikt, og hvordan kan dette påvirkes under designprosessen? Hvis koden kjøres fem millioner ganger om dagen og koster 20 dollar å kjøre i dag, hva vil det koste å kjøre over 5 år, tatt i betraktning forretningsvekst, skykostnader og at koden blir mer ineffektiv ettersom den behandler tilleggsdata?

Fordeler utover kode. Poengeffektivitet starter i applikasjoner, men må deretter spore opp til det generelle systemet og en dag, til bedriften, for teknologi. Å se på de totale kostnadene for systemene våre fra så tidlig som når designbeslutninger tas og frem til applikasjonens levetid betyr ikke bare å se på de økonomiske kostnadene for det totale systemet, men til slutt til det større miljøet.

En ting jeg har innsett i karrieren min: Den felles koblingen mellom alt vi gjør, enten det er ytelse, økonomi eller miljøet generelt – det kommer alltid ned til effektivitet og egentlig enkelhet, dvs. hold det enkelt dumt (KISS).

Akkurat som vi gjør med våre finansielle kontoer, trenger vi en måte å vite teknologikostnadene våre i dag med mer klarhet og projisere kostnadene innenfor teknologistabelen vår som sannsynligvis vil ende opp i himmelen hvis de ikke holdes inne. Men i motsetning til dine finansielle kontoer, der "tidligere resultater ikke er en indikasjon på fremtidige resultater", kan tidligere ytelser til kodene dine fortelle deg mye om fremtidig ytelse. Spørsmålet er, er vi villige til å lytte?