En sam tehnološki strošek, ki ga ne merite – ki bi lahko prihranil milijone, če bi ga

Eden največjih premikov, ki se zgodi s prehodom v oblak, je način plačevanja tehnologije in aplikacij. Industrija je prešla iz procesiranja vsega, kar lahko, na strežniku z lokalnimi podatkovnimi centri na spremenljivko ali pomožni računalniški model. Glede na nedavno Apptio poročilo, to pomeni, da se »mikrooptimizacije lahko zgodijo na ravni ekipe vsak dan, da se spremeni oblika porabe v oblaku … To je svet OpEx (operativni stroški) namesto CapEx (kapitalski stroški), ki popolnoma spremeni način poročanja o financah in uspelo.«

Posledično je bil tradicionalni model nabave za stroške obrnjen, tako da je moč porabe v rokah inženirjev, ki razvijajo in upravljajo te aplikacije in infrastrukturo, pri čemer se zelo malo ozirajo na stroške poslovanja podjetja. Vsi, ki danes delajo v tehnoloških okopih, so osredotočeni na tukaj in zdaj za svoje specifično področje lastništva, kar zagotavlja, da sistem vsak dan deluje brez izpada. Nihče ne razmišlja o: Bi lahko to, kar počnemo, delali hitreje, bolje, pametneje, torej učinkoviteje znotraj aplikacij in procesov?

Apptio, izdelovalec programske opreme, zasnovane za ocenjevanje in sporočanje stroškov IT storitev za namene načrtovanja, priprave proračuna in napovedi, nadalje opisuje mračno resničnost te situacije kot »inženirji, ki se finančno zavezujejo oblaku, kar vpliva na rezultat njihovih podjetij, medtem ko finančne ekipe težko sledijo tempu in razdrobljenosti porabe.«

Večina inženirjev ne nadzoruje ali popolnoma ne razume kode, ki jo pišejo; zgolj dodajajo infrastrukturo za izvajanje vsega, kar je promovirano v proizvodnjo.

V panogi ni običajna praksa, da bi izračunali skupne stroške za vaše tehnološko okolje za stotine aplikacij ali tehnologij, ki jih podpira vaša ekipa. To je treba spremeniti. (Opomba: ne govorim o avtomatizaciji robotske obdelave-RPA, ki uporablja robote za avtomatizacijo digitalnih opravil.) Moj pristop je osredotočen na učinkovitost aplikacij, kode in procesov, ne na učinkovitost z avtomatizacijo.

Zakaj je merjenje skupnih stroškov kode pomembno.

Aplikacije so zasnovane tako, da poenostavijo procese za poslovne uporabnike. Zahteva veliko sredstev in kompleksnosti, da aplikacija ponudi odgovor, tudi če je odzivni čas le nekaj sekund. Zdaj pa to pomnožite s tisoči ali milijoni aplikacijskih zahtev na sekundo v tisočih strežnikih v vašem podjetju. Stvari zlahka postanejo nedosegljive, ko se toliko dogaja hkrati, kar je povezano tudi s stroški. Če naj bi strežniki, na katerih se izvaja aplikacija, zdržali tri leta, vendar zdržijo samo eno, ker so zmanjkale zmogljivosti, kakšna je dejanska cena te aplikacije? To morajo vedeti finančni direktorji in drugi, ker imajo proračune, ki jih je treba izpolniti.

Učinkovit, zdrav sistem zahteva manj virov za obdelavo enake delovne obremenitve kot neučinkovit sistem. Optimizacija kode sprosti še več virov.

Skoraj vsak sistem ima potencial za racionalizacijo zmogljivosti za vsaj 30 do 40 odstotkov, optimizacija kode pa lahko zagotovi dodatnih 20 do 80 odstotkov prihranka stroškov.

To pomeni, da se enake delovne obremenitve lahko izvajajo na manjših strežnikih, kar zmanjša stroške oblaka in licenc. Vrednost teh prihrankov ni samo kratkoročna, ampak v daljšem časovnem obdobju, saj večina aplikacij zdaj živi od 5 do 20 let ali dlje. Ne gre samo za bistvo, gre za razmislek o tem, kaj bi lahko storili s tem sproščenim kapitalom za nadaljnje poslovne KPI danes.

Predstavljajte si skupne stroške kode v 20 letih in upoštevajte: "Ali bi lahko naredili to kodo za 20 % bolj učinkovito, in če bi, koliko bi lahko prihranili v 20 letih?"

Potem je tu še prehod v oblak in pay-as-you-go v primerjavi z plačilo vnaprej model, ki povečuje stroške delovanja in vzdrževanja podatkovnih sistemov hitreje, kot jih lahko zajamemo in analiziramo. Poročilo Apptio poudarja, kako vsi izgubijo, če ni preglednosti stroškov storitev v oblaku:

• Inženiring porabi več, kot je potrebno, z malo razumevanja stroškovne učinkovitosti.
• Finančne ekipe se trudijo razumeti – in spremljati –, kaj se porabi za osupljivo število možnosti (samo AWS ima približno 300,000 SKU-jev in dodatnih tisoč novih funkcij na leto).
• Vodstvo nima dovolj vpliva na to, koliko bo porabljenega, ali zmožnosti vplivanja na prioritete.
• Nabava ni namerna udeleženka lastnega zunanjega izvajanja.

Ocenjevanje prihrankov, ki jih boste imeli, če optimizirate del kode, preden povzroči neučinkovitost vašega sistema (v najboljšem primeru) ali povzroči izpad (v najslabšem primeru), zahteva malo več načrtovanja in vpogleda. Vendar je potrebno, če želimo slediti trenutni stopnji rasti podjetij.

V naslednjem članku bom govoril o tem, kako lahko izmerimo skupne stroške kode in s tem prihranimo milijarde pri neučinkovitih procesih. Ste z menoj?