version af denne artikel oversat af Yesica Danderfer Hvad hvis du ikke anede hvor meget gæld du havde? Det ville være en ubehagelig position at være i, ikke at vide, hvor meget det kostede, eller i hvilken grad det forhindrede din virksomhed i at foretage operationelle forbedringer, reagere på markedsændringer eller endda transformere virksomheden fuldstændigt.
Desuden, hvad nu hvis næsten alle i din organisation kunne stifte gæld uden at søge tilladelse? For eksempel kunne din ejendomschef hurtigt indgå en flerårig lejekontrakt med en lav et-år-leje, men med markant eskalerende husleje i ud-årene – uden at nogen oplyser det andet end i samtale.
Det hele lyder som uforsigtig styring, men det er faktisk ret almindeligt i virksomheder. Fangsten er, at denne form for "gæld" ikke kommer i form af de traditionelle finansielle instrumenter, som vi alle kender så godt.
Teknisk gæld har alle disse egenskaber.
Gæld i sin enkleste form optager lån i dag med den hensigt og lover at tilbagebetale i fremtiden. Gæld giver mening, når dagens lån vil føre til en bedre fremtid, f.eks. at låne til college eller købe et hus. Gælden er generelt dårlig, når lån i dag vil føre til en dårligere morgendag, f.eks. at gå ud til en dyr middag og sætte den på et kreditkort, som du ikke umiddelbart vil betale af.
I virksomhedssammenhæng kan gæld være god, når den opstår for at finansiere investeringer, der vil give et større afkast end omkostningerne ved gælden. Det kan også give mening, hvis du planlægger at sælge virksomheden længe før gælden forfalder. Ulempen ved gæld er, at den har en meget reel udgift, der trækker kontanter og overskud, begrænser fleksibiliteten og kan blive så byrdefuld, at den i sidste ende kan føre til konkurs.
Indtil nu handler den metafor, som vi hentyder til, om finansiel gæld, endnu en form for gæld - teknisk gæld (eller "teknologisk gæld") - har mange lignende karakteristika og skal måles, styres og indgås på en bevidst måde . Hvis det giver din virksomhed mulighed for at komme på markedet foran konkurrenterne, er det meget sandsynligt det værd. På samme måde er det sandsynligvis også det værd at påtage sig teknologigæld for at afbøde en potentielt alvorlig sikkerhedssårbarhed.
Teknisk gæld har dog sine ulemper, hvilket fører til ineffektivitet og træghed – såsom når en afdeling ikke ønsker at bruge en andens software, eller hvis du forsinker en opgradering flere gange for at nå kortsigtede økonomiske mål.
Teknisk gæld er et begreb, der primært er blevet brugt inden for det tekniske samfund, siden Ward Cunningham, en computerprogrammør, opfandt udtrykket i 1992. Dets brug har taget fart for nylig og taget i centrum med udbredelsen af agil programmering. Den tekniske gæld, der diskuteres i denne artikel, handler ikke om programmeringsmetodologi, men snarere de strategiske implikationer af dens eksistens.
Enkelt sagt er teknisk gæld de trinvise omkostninger og tab af smidighed for din virksomhed som følge af tidligere beslutninger, der blev truffet for at spare tid eller penge ved implementering af nye systemer eller vedligeholdelse af eksisterende. Det opstår, når systemer ikke er integreret korrekt, eller koden er alt for kompleks. Dette skyldes en række forskellige årsager, såsom ineffektivitet, tid til markedsovervejelser eller kørsel af forældede versioner af software, blandt mange andre.
Nogle klare eksempler ville være:
Diagrammet nedenfor er en nyttig grafik til at indramme, hvordan tech-gæld adskiller sig fra andre teknologiske implementeringer, der kan laves inden for en virksomheds tech-stack. Ofte forvekslet med at være en fejl, er teknisk gæld meget anderledes, fordi dens tilstedeværelse måske ikke er åbenlyst. Deri ligger faren, da jo længere den bliver uberørt, jo større vil effekten være i fremtiden.
Som CFO, der både har arbejdet indenfor IT og haft IT-rapport til mig i højt gearede virksomhedsvirksomheder, slog det mig, hvor lig teknisk gæld er traditionel gæld. Det slog mig også ved, hvor uigennemskueligt og risikabelt det er. Dem fra en finansiel baggrund er velbevandret i mekanismerne for finansiel gæld - det er håndgribeligt og nemt at beregne. Men ikke for teknisk gæld, som ofte misforstås eller fejlagtigt antages at være en andens problem.
Det korte svar er, at de kontante omkostninger er meget reelle. Der er også nogle vigtige bløde omkostninger, der bør identificeres såvel som separat måles og administreres. Jeg vil nedenfor uddybe nogle eksempler på disse omkostninger:
Teknisk gæld er lige så reel som rentebetalinger. Det manifesterer sig dog normalt på P&L på en mere indirekte måde end en simpel "rente"-linjeudgift, såsom på følgende måder:
Medarbejderantal
Overhead
Salg
Arbejdskapital
Mens hårde omkostninger har faktiske dollarbeløb forbundet med dem, er der også bløde omkostninger, som, på trods af at de er sværere at kvantificere og realisere besparelser på, har en absolut hæmsko for dine forretningsresultater. Disse omfatter:
Marked Intelligence
Produktivitet
Ser man på en sammenligning af teknisk og finansiel gæld, er en af de vigtigste forskelle, at førstnævnte ikke har nogen formel kontrol. Med finansiel gæld er der normalt kreditkomitéer, forvaltningsteams for aktiver og passiver og finanspersonale, der overvåger niveauer som en høg. Med teknisk gæld findes der dog meget få af disse kontroller i traditionelle virksomheder.
Med traditionel gæld sætter bestyrelsen sammen med CEO og CFO typisk kapitalstrukturen, det vil sige hvor meget egenkapital, hvor meget gæld og hvilken type gæld (revolver, aktiv-baseret eller vanilje usikret). Cap-tabellen er endda eksplicit med hensyn til, hvilken gæld der vil blive betalt af, og hvornår. Når alt dette formelt er besluttet, igangsættes en struktureret proces for at rejse gælden.
Långivere ser på en enheds evne til at tilbagebetale gæld via vurderinger af historien om tilbagebetaling af gæld, kreditvurderinger og kvaliteten af den sikkerhed, der understøtter den. Alligevel sker intet af denne formelle proces, kvantificering og sign-off, når der opstår teknisk gæld. Lad os tage et kig på, hvordan og hvorfor dette er gennem de processer, hvor teknisk gæld opstår:
Time to market er alt i erhvervslivet. Implementering af ny teknologi er meget hurtigere at gøre, når det kan gøres på selvstændig basis. Desværre er implikationerne af dette, at andre systemer ikke er synkroniseret med implementeringen. For slanke organisationer med en simpel teknologisk stak virker det måske ikke så slemt.
Det bliver dog problematisk, da systemkonfigurationer formerer sig i deres kompleksitet. I sidste ende automatiserer teknologi processer og fanger data, der bliver transformeret til information. Teknologi, der ikke er integreret, resulterer i forretningsprocesser, der ikke fungerer sammen, og flere versioner af sandheden.
Når tiden ofres for hastighed, kan etablerede testprotokoller ignoreres eller gives dispensation. Dette resulterer normalt i "bugs" hen ad vejen, der viser sig i en form for systemforringelse og distraktion af udviklerens tid til at rette dem.
Hvis vi ser på effekten af tech-gæld over tid, jo længere et emne er urørt, jo større er effekten. Hvad der starter som en lille koderefaktoriseringsøvelse kan snebold ind i en hel moderniserings- og udskiftningsindsats ned ad linjen.
Lad os se det i øjnene - executive teams er under konstant pres for at nå tallene. At holde tilbage på udgifterne i dag kan hjælpe dig med at få kvartalet tilbage, men ligesom ved at låne skal du betale det tilbage på et tidspunkt. Her er nogle måder, hvorpå virksomheder sparer penge på kort sigt, men ender med at resultere i teknisk gæld:
Til tider kan omkostningerne og besværet ved at implementere en periodisk softwareopdatering resultere i, at den bliver forsinket. Nogle gange fortsætter dette i årevis. Vi er alle skyldige i at tvangsafbryde Microsoft AutoUpdate, når det dukker op på ubelejlige tidspunkter.
Når systemer ender med at være langt bagud i deres nuværende version, kan nyere software, der skal integreres med den, simpelthen ikke. Hvad mere er, er det normalt dyrere at opgradere flere versioner på én gang og næsten altid mere tidskrævende end at følge med.
Efterhånden som organisationer vokser i kompleksitet, kan den store indsats med at synkronisere hardwareopdateringscyklusser blive overvældende og dyr. Dette kan resultere i, at den nuværende hardware strækkes til de ekstreme og store forskelle, der eksisterer mellem kvaliteten af hardware mellem teams. Nogle teams bliver frustrerede, køber ny hardware og koster det bare gennem deres skrivebordsbudget i stedet for at vente på, at IT starter opgraderingerne.
Denne forskel har konsekvenser for produktivitet og hardware/filkompatibilitet for samarbejdsøvelser.
I stedet for bare at tale om problemer, lad os nu udvise proaktivitet og foreskrive nogle løsninger til løsning af teknisk gæld.
Til det kan vi bruge de teknikker, der bruges til at håndtere finansiel gæld. For at administrere dine forpligtelser skal du først vide, hvad de er, hvor meget de er, og deres betalingsbetingelser. Lad os nu arbejde igennem dette for teknisk gæld.
Finansiel gæld kommer i trancher, som er defineret af ancienniteten af hvert stykke (f.eks. senior, mezzanine eller revolver), som igen viser, hvem der bliver betalt tilbage først. Teknisk gæld har et lignende anciennitetsmønster; til at begynde med skal du starte med dine missionskritiske systemer. Hvilken teknisk gæld har de? Så se på det bredere økosystem – bedre sagt, hvilken teknisk gæld mellem dine systemer forårsager udgifter?
Overkomplicer ikke denne proces. På et tidspunkt vil du gerne komme til en top-til-bund-vurdering, men du behøver ikke at starte der. Få din it-chef til at trække dit ledelsesteam sammen med dette hjemmearbejde:
Hvis vi havde ryddet op på al vores tekniske gæld for et år siden, hvordan kunne dette år (eller det kommende år) have spillet bedre ud?
Få dine ti bedste ideer og sæt dem i en 2x2 matrix:let/svært at betale ned på den ene akse og graden af fordele på den anden. Forhåbentlig vil det visuelle hjælpe dig med at finde ud af, hvor du skal starte.
Brainstorming-matrix for teknisk gældsløsning| Fordele ved at løse ► | Stærk | ||
|---|---|---|---|
| Svag | |||
| Hårdt | Nemt | ||
| ▲ Bestræbelser på at betale ned | |||
Derfra bor du ind for at validere dine antagelser om størrelsen af præmien og indsatsen. Neutralitet er nøglen her, så vær på vagt over for softwareleverandører, der tilbyder at udføre en "gratis vurdering".
Når du ved, hvilken teknisk gæld du har, skal du nu beslutte dig for, hvordan du skal håndtere den. Der er mange muligheder at tage.
Det kan i sidste ende være bedst at gøre ingenting. For gæld, der enten vurderes til at være "lille" eller med en "lav rente", kan det være optimalt blot at lade den ligge - ligeledes hvis der er en betydelig "indbetalingsbod" ved at betale den før tid. Der kan også være strategiske fordele. At være en version bagud og blive der er normalt fint, og nogle gange har det den fordel, at det lader knæk blive løst på en andens skilling.
At betale tilbage eller reducere teknisk gæld vil indebære at udskifte systemer og tage omkostningerne. Dette kan enten gøres med det samme eller over tid gennem en proces med gradvise forbedringer. Som med finansiel gæld er der kreative måder, hvorpå du kan "refinansiere" teknisk gæld, hvor outsourcing af vedligeholdelsen er en sådan måde. Dette kan i sidste ende koste mere at løse, men det kan alligevel spredes for at sænke det umiddelbare omkostningsslag, og gennem principperne for arbejdsdeling uddelegere opgaven til en mere specialiseret enhed.
Fremkomsten af cloud-baserede software- og hardwaretjenester giver også en sammenligning med populariteten af leasing-baseret finansiering. Brug af cloud-tjenester er også et effektivt værktøj til at reducere teknisk gæld, både til at fjerne CAPEX-krav og flytte udviklingsfokus over på cloud-udbyderen.
Bliv ikke overvældet af omkostningerne ved at reducere din tekniske gæld, og prøv ikke at betale det hele på én gang. Dette ville være en ambitiøs øvelse, der kunne overvælde en organisation af enhver størrelse eller balance.
Igen, gå tilbage til de økonomiske sammenligninger, har en mentalitet om at betale kreditkortet med den højeste rente først. Dette betyder ganske enkelt at angribe aktiviteter med høj værdi/lav indsats først.
I det foregående afsnit diskuterede jeg de forskellige måder at tackle teknisk gæld på. Når du vurderer prisen på hver enkelt, er det bedst at foretage en sammenligningsøvelse. Rangering af pengestrømsomkostningerne for hvert potentielt resultat kan gøre det muligt for interessenterne at have et klart overblik over afvejningen og fordelene ved hver vej. Et eksempel på en sådan visualisering er inkluderet nedenfor.
Denne sammenligning viser den afvejning, der eksisterer mellem en teoretisk opløsning og den skarpe kontrast mellem at løse problemet og ikke gøre noget ("eksisterende baseline"). I dette eksempel vil en SaaS-baseret løsning være den mest økonomiske løsning for virksomheden at tage til en sky.
Når du har etableret din baseline og angrebsplan, vil du både bevare denne synlighed og forhindre ny gæld i at snige sig ind. Tænk på øvelsen som en frisk start og en chance for at implementere bedste praksis for at forhindre problemer fra nogensinde. eskalerer igen i fremtiden.
De fleste teknologiprojekter har en formel godkendelsesproces komplet med en udøvende sponsor, mål på højt niveau, forventede fordele, tidsplan og selvfølgelig omkostninger. Dette er et fantastisk sted at skylle ny teknisk gæld ud, der vil blive opstået, og begrundelsen for den.
Gå ikke for overivrig med at sætte nye standarder. Ligesom du udsteder firmakreditkort med forudindstillede grænser, ønsker du ikke at overstyre teknisk gæld. Meget teknisk gæld er lille og relateret til kodeskrivning, der hurtigt vil blive betalt. Dette gælder især med agil udvikling. Stol på, at din it-chef indstiller og overvåger denne tærskel.
I større virksomheder har IT en proces kaldet "forandringsledelse". Inden ny software går live, går den typisk igennem forandringsledelse. Enkelt sagt er forandringsledelsens opgave at sikre, at nye ændringer i virksomhedens teknologisystem ikke påvirker andre systemer. Det gør de ved at sikre, at det nye system overholder standardiserede metoder og procedurer. Overvej at bruge denne proces til at forhindre eller i det mindste identificere ny gæld i at blive introduceret.
Teknisk gæld er en reel omkostning ved at drive forretning og en reel årsag til systemafbrydelser og trækker virksomhedens overordnede smidighed. Det behøver dog ikke at være en vedvarende byrde, og smarte CFO'er vil vide, hvor meget teknologisk gæld deres organisation har, og hvad der skal til for at optimere det.