Hva er teknisk gjeld? En guide til påvirkningen på virksomheten

Coming soon — Get career resources, software reviews, & expert tips right in your inbox Get Free Access

Utforsk konseptet teknisk gjeld – både det gode og det dårlige – slik det gjelder inntektsdrift. Her går jeg gjennom aspekter ved skalerbarhet, datakvalitet og generell effektivitet i virksomheten, slik at du kan oppnå avkastning på investeringen.

Ettersom inntektsledere blir stadig mer presset til å levere effektiv vekst og lønnsomhet, har også avhengigheten av teknologistakken deres økt betydelig. Derfor har RevOps blitt stadig viktigere som funksjonen som kobler mennesker og prosesser sammen med teknologi. 

De fleste teknologiselskaper håndterer i dag en mengde verktøy med mål om å fremme vekst innen markedsføring og salg. Ifølge Scott Brinker fantes det nesten 10 000 teknologi-verktøy for markedsføring og salg i 2022. Fra CRM- og markedsautomatiseringsplattformer til applikasjoner for salgsengasjement og samtale-intelligens vil mye av denne teknologiinvesteringen medføre betydelig teknisk gjeld som kan svekke avkastningen på investeringen (ROI) og hindre virksomhetens samlede resultater. 

Jeg heter Mohammed Abukar og leder for tiden strategien for salgsteknologi i et av Canadas største og mest fremtredende teknologi- og telekommunikasjonsselskaper. I løpet av det siste tiåret har veksten i bruken av forretningsapplikasjoner, særlig i teknologisektoren, vært ganske bemerkelsesverdig. Selv om dette fenomenet har ført til akselerert vekst for noen, har teknisk gjeld blitt en byrde som hindrer andre i å skalere. 

Jeg skrev denne artikkelen for å utforske begrepet teknisk gjeld – både det gode og det dårlige – slik det gjelder inntektsoperasjoner. Jeg vil gå nærmere inn på skalerbarhet, datakvalitet og virksomhetens samlede effektivitet. Til slutt vil jeg dele noen praktiske innsikter og strategier for både håndtering og reduksjon av teknisk gjeld. 

Hva er teknisk gjeld?

Begrepet teknisk gjeld ble skapt av en programvareutvikler ved navn Ward Cunningham i 1992, som en henvisning til kodegjeld innen programvareutvikling. Cunningham var en av forfatterne av Agile-manifestet, som det ofte refereres til i dag.

Cunningham skrev en gang: «Å levere kode for første gang er som å stifte gjeld. Litt gjeld fremskynder utviklingen så lenge den betales tilbake raskt gjennom en omskriving. … Faren oppstår når gjelden ikke blir tilbakebetalt. Hvert minutt som brukes på kode som ikke er helt riktig, teller som renter på denne gjelden.»

Når vi analyserer denne uttalelsen fra Cunningham, er det tydelig at teknisk gjeld i seg selv ikke nødvendigvis er bra eller dårlig. Tvert imot kan teknisk gjeld, akkurat som all annen finansiell gjeld, brukes som et virkemiddel for å drive virksomheten fremover dersom den brukes fornuftig og strategisk.

Med andre ord kan teknisk gjeld være et verktøy organisasjonen din utnytter – på godt og vondt.

I forbindelse med inntektsoperasjoner er teknisk gjeld kostnaden et selskap pådrar seg som følge av ineffektivitet knyttet til teknologi. For eksempel vil en dårlig implementert CRM-løsning eller en systemintegrasjon som ikke er bygget optimalt, regnes som teknisk gjeld.

Denne kostnaden omtales ofte som inntektslekkasje i RevOps-verdenen. Min favorittforklaring på hva inntektslekkasje betyr, er godt beskrevet i The Atlantic.

«Inntektslekkasje er et unngåelig inntektstap som skyldes systemiske svikt i synlighet, prosesser og gjennomføring. Det er inntekter dere har gjort arbeidet for å tjene, som teamet har brukt tid og krefter på, men som ikke havner i balansen. … Disse tapte inntektene er vekst som har forsvunnet.»

Hvorfor er det viktig å forstå teknisk gjeld?

Akkurat som med all annen gjeld vil teknisk gjeld akkumuleres over tid dersom den ikke tilbakebetales. Denne opphopingen vil gjøre det svært vanskelig å implementere prosessendringer eller eksperimentere med nye initiativer. Etter hvert som organisasjonen skalerer og legger til flere prosesser og medarbeidere, blir problemet ytterligere forsterket.

Det er viktig å sørge for at dere har oversikt over hvor organisasjonen befinner seg når det gjelder teknisk gjeld, slik at dere kan operere innenfor en komfortabel terskel og iverksette tiltak dersom denne terskelen overskrides.

Get Free Access
Join the next generation of CROs and unlock trends, tips, and tools to help you tackle today's challenges and prepare for the future of GTM.
Get Free Access

Have an account? Log In

Forstå syklusen for teknisk gjeld

«Dette verktøyet vil hjelpe meg med å bygge opp salgspipelinen raskere» eller «Denne applikasjonen kan bidra til å forbedre vinningsraten vår i salg». Hvis du jobber med RevOps, har du sannsynligvis hørt en variant av disse utsagnene før. I arbeidet med å forbedre salgs- eller markedsføringsresultatene tar virksomhetsledere noen ganger dårlige kjøpsbeslutninger med langsiktige konsekvenser, i bytte mot kortsiktige gevinster.

Sannheten er at dersom langsiktig skalerbarhet ikke tas med i vurderingen, vil disse nye systemene over tid miste samspillet med den samlede inntektsmotoren, noe som vil føre til redusert effektivitet over tid. 

Denne situasjonen krever flere ressurser for å håndtere all ineffektiviteten i systemene, i stedet for at tiden og innsatsen brukes på å utvikle nye funksjoner og frigjøre ytterligere produktivitet. Dette fører til betydelige inntektstap, og dessverre ender leverandørene opp med å få mye av skylden for dette. 

infografikk som forklarer syklusen for teknisk gjeld

Ifølge Gartner kan dette utvikle seg til en ond sirkel av investeringer i inntektsteknologi.

Til syvende og sist vil kostnadene ved å vedlikeholde disse komponentene med svak ytelse overstige den forventede avkastningen på investeringen. Dette etterlater organisasjonen med problemer med å betjene kundene effektivt og holde tritt med konkurrentene.

Vanlige årsaker til teknisk gjeld

I forbindelse med Revops finnes det en rekke årsaker til teknisk gjeld. Det er viktig å forstå disse årsakene, slik at du kan unngå å tilføre utilsiktet gjeld til teknologistakken. Her er tre årsaker du bør ha i tankene, med eksempler på teknisk gjeld.

Mangel på gode forretningsprosesser

Den vanligste kilden til teknisk gjeld som jeg har sett gjennom årene, kan spores tilbake til dårlig utformede prosesser i organisasjoner. Dette er et stort problem som jeg har sett forverres i mindre organisasjoner, der prosesser bygges for første gang.

Ta for eksempel noe så komplekst som salgsprognoser. Hvis salgsledelsen din ikke har SOPs (standardiserte driftsprosedyrer) og en etablert operativ rytme for hvordan prognoser utarbeides, er det svært usannsynlig at det å kjøpe et nytt system for å forbedre prognosene vil lykkes.

Det som vanligvis skjer i et slikt scenario, er at selve verktøyet etablerer prosessen for salgslederne. Dette er problematisk, ettersom det aldri finnes én fremgangsmåte som passer for alle når noe så komplekst som salgsprognoser skal utarbeides. Det mest sannsynlige utfallet? Verktøyet oppfyller ikke det tiltenkte formålet og vil etter hvert kreve ytterligere konfigurasjon etter hvert som prosessene blir bedre definert.

For noe så kritisk som salgsprognoser kan du oppleve utilsiktede konsekvenser og inntektslekkasje knyttet til unøyaktige data, svak bruk eller til og med unøyaktige inntektsprognoser. 

Å kjøpe nye systemer før du har godt etablerte forretningsprosesser på plass, er som å plante et frø i uforberedt eller ufruktbar jord – potensialet for vekst er til stede, men uten god jord (veldefinerte prosesser) vil det være vanskelig for disse nye systemene å blomstre og gi positive resultater. 

Duplisering og redundans i teknologien

Teknologisk redundans kan også være en betydelig kilde til teknisk gjeld og skape mangefasetterte utfordringer for organisasjoner. Duplisering eller redundans i teknologien kan beskrives som å ha to eller flere systemer med tilsvarende funksjonalitet. Disse systemene kan brukes uavhengig av hverandre eller til og med være integrert med hverandre.

Dette problemet oppstår ofte når organisasjoner har avdelinger som arbeider i siloer. Organisasjoner som ikke investerer i inntektsoperasjoner, blir som regel mest påvirket av denne spesifikke kilden til teknisk gjeld.

Det oppstår et iboende ekstra kompleksitetsnivå når teknologistakken inneholder redundans. Denne kompleksiteten kan føre til problemer som datainkonsekvens, ettersom hvert system genererer sitt eget resultat.

Redundans i teknologistakken er ikke alltid negativt. Noen ganger kan virksomheter ta bevisste valg om å anskaffe systemer med tilsvarende funksjoner. De kan velge å påta seg teknisk gjeld på en fornuftig måte som et kompromiss for å løse et kritisk forretningsbehov.

For eksempel virksomheter som bevisst velger å ha flere verktøy for dataanrikning til ulike bruksområder. Du kan ha behov for å bruke én løsning for dataanrikning fordi den gir bedre dekning av e-postadresser og telefonnumre til kontakter. Samtidig kan du bruke en annen løsning for dataanrikning fordi den gir bedre dekning av kontodata, det vil si bransje eller antall ansatte i selskapet.

Hvis organisasjonen din har en strategisk tilnærming til hvordan den bevisst påtar seg denne tekniske gjelden, kan det være den innflytelsen som trengs for å åpne nye muligheter. 

Usammenhengende teknologistakk

En annen vanlig kilde til teknisk gjeld kan knyttes til hvordan systemer og løsninger integreres, eller i mange tilfeller mangelen på integrasjon mellom dem. Dette problemet oppstår når teknologistakken består av ulike verktøy som fungerer isolert uten å kommunisere effektivt med hverandre.

Når ulike verktøy i teknologistakken ikke kommuniserer effektivt, oppstår det hull i data og informasjon. Teamene dine vil få stadig større problemer med å få tilgang til og dele kritiske data, noe som vil føre til dårlige beslutninger.

Usammenhengende systemer skaper også ofte ineffektive arbeidsflyter. Et eksempel er arbeidsflyten som kreves for å overføre en ny kunde fra salgsorganisasjonen til kundesuksessteamet. Skjer det en sømløs overføring av informasjon mellom disse to gruppene, eller kreves det manuelt arbeid for å overføre data fra én plattform til en annen?

Som oftest ser selskaper etter systemer som har innebygd integrasjon med andre verktøy i teknologistakken. Når slike integrasjoner ikke finnes, vil det kreve tilpasset konfigurasjon og kode for å koble sammen systemene. Denne tilpassede konfigurasjonen kan også være en kilde til teknisk gjeld, ettersom koden krever intern oppfølging og vedlikehold.

Oppsummering av konsekvensene av teknisk gjeld

Dårlig datakvalitet – Inkonsistente eller unøyaktige data vil føre til dårligere beslutninger for organisasjonen din. 

Dårlig kundeopplevelse – Teknisk gjeld kan påvirke systemer og prosesser som er rettet mot kundene. Hvis denne gjelden ikke betales tilbake, vil den føre til ting som tjenesteavbrudd, løfter som ikke innfris og negative opplevelser. 

Operasjonell ineffektivitet – Teknisk gjeld som ikke overvåkes, vil føre til ineffektivitet mellom teamene. Å ha et Revops-team som overvåker og implementerer ende-til-ende-prosesser, vil bidra til å redusere noe av byrden gjelden medfører.

Samarbeid og teammoral – Teknisk gjeld kan føre til overbelastede teammedlemmer, noe som skaper frustrasjon og svekker teammoralen. Denne svekkelsen av moralen vil forstyrre tverrfunksjonelt samarbeid og kan til og med føre til at salg og markedsføring, eller salg og kundesuksess, skylder på hverandre.

Dersom disse konsekvensene ikke håndteres, kan de få betydelig innvirkning på organisasjonens evne til å skalere. Sørg for å overvåke og håndtere denne gjelden på en fornuftig måte, ettersom de utilsiktede konsekvensene kan være betydelige nok til å endre selskapets vekstretning i mange år fremover. 

More Articles

5 måter å håndtere teknisk gjeld på

For å håndtere teknisk gjeld effektivt må organisasjoner først kunne gjenkjenne og vurdere problemets omfang. Her er fem måter organisasjonen din både kan identifisere og håndtere teknisk gjeld på fremover:

  1. Gjennomfør systemrevisjoner – Start med å vurdere den nåværende tilstanden til systemene dine. Dette innebærer å identifisere eldre løsninger, ineffektive prosesser og områder der det genereres data av dårlig kvalitet.
  1. Prioriter dårlig teknisk gjeld – Etter at du har revidert systemene dine og avdekket områder med forbedringspotensial, bør du begynne å prioritere den tekniske gjelden som blir mest kostbar for organisasjonen din. Husk at all gjeld ikke er lik. Fokuser på å redusere teknisk gjeld der inntektslekkasjen er mest problematisk.
  2. Sett av ressurser – Sørg for at du har de riktige ressursene som kreves for å håndtere gjelden. Bruk sykluser for virksomhetsplanlegging til å vurdere hvilke konkrete roller du ønsker å ansette til, og hvilket budsjett som kan være nødvendig for å redusere de negative konsekvensene av teknisk gjeld.
  3. Implementer beste praksis – Gjør det til en del av organisasjonens DNA å implementere beste praksis når det gjelder håndtering av teknisk gjeld. Sørg for at dere følger denne beste praksisen, og hold teamet ansvarlig dersom dere ikke gjør det.
  4. Sørg for regelmessig vedlikehold – Som en del av beste praksis er regelmessig vedlikehold en viktig måte å håndtere teknisk gjeld på. I tillegg til å sette av bestemte tidspunkter gjennom året til vedlikehold bør du etablere en fast rytme der systemsårbarheter gjennomgås og feilrettinger prioriteres.

Til slutt …

For at organisasjoner skal oppnå avkastning på investeringen (ROI) i teknologistakken sin, er det viktig at de forstår konsekvensene av teknisk gjeld og håndterer den proaktivt. Ved å håndtere teknisk gjeld på en systematisk måte kan organisasjoner oppnå et konkurransefortrinn i markedet sitt.

Hvis du likte denne artikkelen eller syntes den var nyttig for å forklare teknisk gjeld, kan du gjerne si fra i kommentarfeltet. Når du først er her, bør du også melde deg på nyhetsbrevet fra The CRO Club for å få den nyeste innsikten rett i innboksen.

Mohammed Abukar
Meet Mohammed Abukar. He currently leads the Sales Technology strategy at TELUS, one of Canada’s flagship telecom and technology companies. With a broad range of experience in Revenue Operations, Mohammed brings a unique lens to the conversations around process, technology, data, and people. When he is not knee deep in software implementations and integrations you can catch him outdoors enjoying time with family and friends.
Follow the author:

You may also like