Vad är teknisk skuld? En guide till påverkan på verksamheten
Eftersom intäktsansvariga utsätts för allt större press att leverera effektiv tillväxt och lönsamhet har även beroendet av deras teknikstack ökat avsevärt. Därför har RevOps blivit allt viktigare som den funktion som kopplar samman människor och processer med teknik.
I stort sett hanterar de flesta teknikföretag idag en mängd verktyg med målet att driva tillväxt inom marknadsföring och försäljning. Enligt Scott Brinker fanns det nästan 10 000 teknikverktyg för marknadsföring och försäljning år 2022. Från CRM- och marknadsföringsautomatiseringsplattformar till plattformar för säljengagemang och konversationsbaserade analysapplikationer kommer en stor del av dessa teknikrelaterade investeringar att medföra betydande teknisk skuld som kan urholka ROI (avkastning på investering) och försämra verksamhetens övergripande resultat.
Jag heter Mohammed Abukar och leder för närvarande strategin för försäljningsteknik på ett av Kanadas största och mest framstående teknik- och telekommunikationsföretag. Under det senaste decenniet har den ökade användningen av affärsapplikationer, särskilt inom tekniksektorn, varit något av ett spektakel. Även om detta fenomen har lett till accelererad tillväxt för vissa har teknisk skuld blivit en belastning för andra, vilket hindrar deras förmåga att skala upp.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Jag skrev den här artikeln för att utforska begreppet teknisk skuld – både det goda och det dåliga – i relation till intäktsverksamhet. Jag kommer att gå igenom aspekter som skalbarhet, datakvalitet och verksamhetens övergripande effektivitet. Avslutningsvis kommer jag att dela med mig av praktiska insikter och strategier för att både hantera och minska teknisk skuld.
Vad är teknisk skuld?
Begreppet teknisk skuld myntades av en mjukvaruutvecklare vid namn Ward Cunningham 1992, med hänvisning till kodskuld inom programvaruutveckling. Cunningham var en av författarna till det agila manifestet, som citeras flitigt än idag.
Cunningham skrev en gång: ”Att leverera kod för första gången är som att sätta sig i skuld. En liten skuld snabbar upp utvecklingen så länge den betalas tillbaka snabbt genom en omskrivning. … Faran uppstår när skulden inte betalas tillbaka. Varje minut som ägnas åt kod som inte är helt rätt räknas som ränta på den skulden.”
Om man analyserar detta uttalande av Cunningham blir det tydligt att teknisk skuld i sig inte är något som i grunden är bra eller dåligt. Tvärtom kan teknisk skuld, precis som alla andra finansiella skulder, användas som hävstång för att driva verksamheten framåt om den används ansvarsfullt och strategiskt.
Med andra ord kan teknisk skuld vara ett verktyg som organisationen använder till det bättre eller sämre.
I samband med intäktsverksamhet är teknisk skuld den kostnad ett företag drabbas av på grund av ineffektivitet kopplad till teknik. Ett dåligt implementerat CRM-system eller en systemintegration som inte har konstruerats optimalt räknas exempelvis som teknisk skuld.
Denna kostnad kallas ofta för intäktsläckage inom RevOps-världen. Min favoritförklaring av vad intäktsläckage innebär finns väl beskriven i The Atlantic.
”Intäktsläckage är den undvikbara förlusten av intäkter på grund av systemfel inom synlighet, processer och genomförande. Det handlar om intäkter som ni har arbetat för att förtjäna, som ert team har lagt ned tid och ansträngning på, men som inte hamnar i balansräkningen. … Dessa förlorade intäkter är tillväxt som har försvunnit.”
Varför är det viktigt att förstå teknisk skuld?
Precis som med alla andra skulder kommer teknisk skuld att ackumuleras över tid om den inte betalas tillbaka. Denna ackumulering gör det mycket svårt att genomföra processförändringar eller experimentera med nya initiativ. När organisationen växer och lägger till fler processer och personer förvärras problemet ytterligare.
Det är viktigt att se till att ni är medvetna om var organisationen befinner sig när det gäller teknisk skuld, eftersom det gör att ni kan verka inom en hanterbar gräns och vidta åtgärder om den gränsen överskrids.
Att förstå den tekniska skuldens cykel
”Det här verktyget hjälper mig att bygga upp säljpipelinen snabbare” eller ”Den här applikationen kan bidra till att förbättra vår vinstfrekvens i försäljningen.” Om du arbetar inom RevOps har du förmodligen hört någon variant av dessa påståenden tidigare. I sina ansträngningar att förbättra försäljnings- eller marknadsföringsresultaten fattar företagsledare ibland dåliga inköpsbeslut med långsiktiga konsekvenser i utbyte mot kortsiktiga vinster.
Sanningen är att om långsiktig skalbarhet inte tas med i beräkningen kommer dessa nya system med tiden att förlora sin samverkan med den övergripande intäktsmotorn, vilket leder till minskad effektivitet över tid.
Denna situation kräver mer resurser för att hantera all ineffektivitet i systemen, i stället för att använda den tiden och ansträngningen till att utveckla nya funktioner och frigöra ytterligare produktivitet. Detta leder till betydande intäktsförluster, och tyvärr får leverantörerna ofta ta på sig en stor del av skulden för detta.
Enligt Gartner kan detta utvecklas till en ond cirkel av investeringar i intäktsteknik.
I slutändan kommer kostnaden för att underhålla dessa underpresterande komponenter att överstiga deras förväntade avkastning på investeringen. Detta lämnar organisationen kämpande med att betjäna sina kunder effektivt och hålla jämna steg med konkurrenterna.
Vanliga orsaker till teknisk skuld
I samband med intäktsverksamhet finns det ett antal orsaker till teknisk skuld. Det är viktigt att förstå dessa orsaker så att du kan undvika att oavsiktligt lägga till skuld i din teknikstack. Här är tre orsaker att ha i åtanke, tillsammans med exempel på teknisk skuld.
Brist på bra affärsprocesser
Den vanligaste källan till teknisk skuld som jag har sett genom åren kan kopplas till dåligt utformade processer inom organisationer. Detta är ett stort problem som jag har sett förvärras i mindre organisationer där processer byggs för första gången.
Ta exempelvis något så komplext som försäljningsprognoser. Om ditt försäljningsledarskap inte har SOP:er (standardiserade arbetsrutiner) och en etablerad operativ rytm för hur prognoser ska tas fram, är det ganska långsökt att köpa ett nytt system för att förbättra prognoserna.
Det som vanligtvis händer i ett sådant scenario är att själva verktyget fastställer processen för försäljningsledarna. Detta är problematiskt eftersom det aldrig finns ett universellt tillvägagångssätt för hur något så komplext som försäljningsprognoser ska genomföras. Det mest sannolika resultatet? Verktyget fyller inte sitt avsedda syfte och kommer så småningom att kräva ytterligare konfiguration när processerna blir bättre definierade.
För något så kritiskt som försäljningsprognoser kan du stöta på oavsiktliga konsekvenser och intäktsläckage kopplat till felaktiga data, låg användningsgrad eller till och med felaktiga intäktsprognoser.
Att köpa nya system innan du har väl etablerade affärsprocesser på plats är som att plantera ett frö i oförberedd eller ofruktbar jord – potentialen för tillväxt finns där, men utan bra jord (väl definierade processer) blir det svårt för dessa nya system att blomstra och ge positiva resultat.
Duplicering och redundans i tekniken
Teknisk redundans kan också vara en betydande källa till teknisk skuld och medföra många olika utmaningar för organisationer. Duplicering eller redundans i tekniken kan beskrivas som att ha två eller fler system med liknande funktionalitet. Dessa system kan användas oberoende av varandra eller till och med vara integrerade med varandra.
Detta problem uppstår ofta när organisationer har avdelningar som arbetar i silor. Organisationer som inte investerar i intäktsverksamhet påverkas oftast mest av just denna källa till teknisk skuld.
Det tillkommer ett inneboende lager av komplexitet när det gäller redundans i teknikstacken. Dessa komplexiteter kan orsaka problem som datainkonsekvenser, eftersom varje system genererar sina egna resultat.
Redundans i teknikstacken behöver inte alltid vara något negativt. Ibland kan företag medvetet välja att införskaffa system med liknande funktioner. De kan välja att ta på sig teknisk skuld på ett genomtänkt sätt som en kompromiss för att lösa ett kritiskt affärsbehov.
Företag kan exempelvis medvetet välja att ha flera verktyg för databerikning för olika användningsområden. Du kan behöva använda en lösning för databerikning eftersom den erbjuder bättre täckning för kontaktpersoners e-postadresser och telefonnummer. Samtidigt kan du använda en annan lösning för databerikning eftersom den erbjuder bättre täckning för kontodata, det vill säga företagets bransch eller antal anställda.
Om din organisation är strategisk i fråga om hur den medvetet tar på sig denna tekniska skuld kan den utgöra den hävstång som behövs för att öppna nya möjligheter.
Osammanhängande teknikstack
En annan vanlig källa till teknisk skuld kan kopplas till hur system och lösningar integreras eller, i många fall, till bristen på integration mellan dem. Detta problem uppstår när din teknikstack består av olika verktyg som fungerar isolerat utan att kommunicera effektivt med varandra.
När olika verktyg i din teknikstack inte kommunicerar effektivt uppstår luckor i data och information. Det blir allt svårare för dina team att få åtkomst till och dela kritiska data, vilket leder till sämre beslutsfattande.
Osammanhängande system skapar också ofta ineffektiva arbetsflöden. Tänk exempelvis på det arbetsflöde som krävs för att överlämna en ny kund från din försäljningsorganisation till ditt kundframgångsteam. Sker en smidig överföring av information mellan dessa två grupper, eller krävs det manuellt arbete för att överföra data från en plattform till en annan?
Oftare än inte försöker företag införskaffa system som har färdiga integrationer med andra verktyg i deras teknikstack. När dessa integrationer inte finns krävs viss anpassad konfiguration och kod för att koppla samman systemen. Denna anpassade konfiguration kan också vara en källa till teknisk skuld, eftersom koden kräver internt underhåll och löpande förvaltning.
Sammanfattning av den tekniska skuldens konsekvenser
Bristande datakvalitet – Inkonsekventa eller felaktiga data leder till sämre beslutsfattande för din organisation.
Dålig kundupplevelse – Teknisk skuld kan påverka system och processer som möter kunderna. Denna skuld kommer, om den inte betalas tillbaka, att leda till sådant som driftstörningar, ouppfyllda löften och negativa upplevelser.
Operativa ineffektiviteter - Teknisk skuld som inte övervakas kommer att skapa ineffektivitet mellan team. Att ha ett Revops-team som övervakar och implementerar processer från början till slut bidrar till att minska en del av den belastning som skulden medför.
Samarbete och teammoral - Teknisk skuld kan leda till överbelastade teammedlemmar, vilket orsakar frustration och försämrad teammoral. Denna försämrade moral kommer att störa samarbetet mellan olika funktioner och kan till och med leda till att sälj- och marknadsteamen eller sälj- och kundframgångsteamen skyller på varandra.
Dessa konsekvenser kan, om de lämnas obehandlade, få betydande inverkan på organisationens förmåga att skala upp. Se till att övervaka och hantera denna skuld på ett ansvarsfullt sätt, eftersom de oavsiktliga konsekvenserna kan vara tillräckligt allvarliga för att förändra ett företags tillväxtinriktning under många år framöver.
5 sätt att hantera teknisk skuld
För att effektivt kunna hantera teknisk skuld måste organisationer först kunna identifiera och bedöma problemets omfattning. Här är fem sätt för din organisation att både identifiera och hantera teknisk skuld framöver:
- Genomför systemgranskningar - Börja med att utvärdera systemens nuvarande tillstånd. Detta omfattar att identifiera äldre lösningar, ineffektiva processer och områden där bristfälliga data genereras.
- Prioritera dålig teknisk skuld - När du har granskat systemen och upptäckt förbättringsområden börjar du prioritera den tekniska skuld som blir mest kostsam för organisationen. Kom ihåg att all skuld inte är likadan. Fokusera på att minska den tekniska skuld där intäktsläckaget är som mest problematiskt.
- Avsätt resurser - Säkerställ att du har de rätta resurserna som krävs för att hantera skulden. Använd verksamhetsplaneringscykler för att överväga vilka specifika roller du vill anställa för och vilken budget som kan krävas för att minska de negativa konsekvenserna av teknisk skuld.
- Implementera bästa praxis - Gör det till en del av organisationens DNA att implementera bästa praxis när det gäller att hantera teknisk skuld. Säkerställ att ni följer denna bästa praxis och håller teamet ansvarigt för att inte göra det.
- Säkerställ regelbundet underhåll - Som en del av er bästa praxis är regelbundet underhåll ett viktigt sätt att hantera teknisk skuld. Förutom att avsätta särskilda tider under året för underhåll bör ni skapa en regelbunden rutin där systemens sårbarheter granskas och buggfixar prioriteras.
Avslutningsvis…
För att organisationer ska kunna uppnå en ROI på sina investeringar i teknikstacken är det viktigt att de förstår konsekvenserna av teknisk skuld och hanterar den proaktivt. Genom att hantera teknisk skuld på ett systematiskt sätt kan organisationer använda den för att skapa en konkurrensfördel på sin marknad.
Om du uppskattade den här artikeln eller tyckte att den var användbar för att förklara teknisk skuld får du gärna berätta det i kommentarerna. När du ändå är här kan du se till att prenumerera på nyhetsbrevet från The CRO Club för att få de senaste insikterna direkt i din inkorg.
