Att prata om single source of truth i en RevOps-kontext är enkelt. Att bygga det är svårare – inte för att tekniken saknas, utan för att organisationen redan har en fungerande vardag som inte kan pausas. För en svensk försäljningschef blir frågan därför sällan “vilket system ska vi välja?”, utan “hur skapar vi styrning och tillit utan att slå sönder processer som levererar intäkter idag?”
Det är också här många initiativ går fel. Man försöker ersätta allt på en gång: CRM, ekonomisystem, marketing automation, BI och diverse “egna sanningar” i kalkylark. Resultatet blir ofta att man får nya datakällor, men inte mer samsyn. En single source of truth är i praktiken ett styrningsprojekt lika mycket som ett data-projekt.
Den här analysen handlar om vad begreppet faktiskt innebär, varför det blir politiskt, och hur du kan bygga en gemensam sanning stegvis – utan att ta ned säljmaskinen under tiden.
Vad en “single source of truth” är – och inte är
En single source of truth är inte “ett system där all data bor”. I B2B finns det nästan alltid flera system som behöver vara källor: CRM för pipeline, affärssystem för fakturering, produkt- eller leveransdata för aktivering och retention. Problemet uppstår när ni saknar gemensamma definitioner och en tydlig hierarki för vilken data som vinner när det skiljer sig.
Det mer användbara synsättet är: en gemensam beslutsgrund. Det vill säga en uppsättning mätetal och definitioner som ledning, sälj, marknad och CS accepterar, och som går att spåra tillbaka till datakällor med dokumenterade regler. Det är därför många misslyckas genom att börja i verktyg (nytt BI, nytt datalager) innan de har gjort det svåra arbetet med begrepp och ansvar.
För en försäljningschef märks skillnaden direkt i vardagen: “Varför skiljer sig min pipeline i CRM från prognosen i ledningsmötet?” eller “Varför är win rate olika i BI jämfört med det jag ser i teamet?”. Det är inte en datadetalj – det är en styrningsfråga.
Styrning först: RevOps som ägare av definitioner, inte av system
När single source of truth blir ett IT-initiativ hamnar ni ofta i en teknisk lösning som inte överlever första förändringen i säljprocessen. När det blir ett rent säljinitiativ riskerar ni istället att optimera för kortsiktig rapportering och missa de beroenden som finns till ekonomi, leverans och marknad.
RevOps fyller en annan funktion: att vara neutral part som äger definitioner, mätetal och “spelregler” för data – oavsett var data lagras. Det innebär inte att RevOps ska drifta alla verktyg. Det innebär att RevOps driver besluten om till exempel vad som räknas som en “SQL”, när en affär är “Closed Won”, hur ARR/MRR beräknas, och vilka datumfält som styr periodisering i rapporteringen.
Utan den typen av styrning blir “sanningen” ett förhandlingsresultat i varje möte. Med styrning blir den en stabil bas som ni kan diskutera utifrån – även när siffrorna är obekväma.
Det verkliga hindret: olika sanningar tjänar olika syften
Det är frestande att beskriva problemet som att ni har “dålig data”. Ofta har ni snarare data som är anpassad för olika lokala behov. Sälj behöver snabbhet och flexibilitet. Ekonomi behöver spårbarhet och kontroll. Marknad behöver attribuering och volym. Ledningen behöver jämförbarhet över tid.
När ni försöker skapa en gemensam sanning uppstår friktion eftersom någon upplever att de förlorar handlingsutrymme. Ett konkret exempel: om CRM blir striktare minskar friheten i hur säljare kan registrera affärer, men prognosen blir bättre. Om ni istället låter flexibiliteten vara kvar får ni fler “egna varianter” av pipeline som sedan måste städas i BI. Båda har ett pris.
Nyckeln är att göra trade-offs explicita, och att koppla dem till beslut som faktiskt tas. Den mest värdefulla sanningen är inte den mest kompletta – utan den som används konsekvent när ni styr.
Bygg stegvis: “beslutsdomäner” istället för total ombyggnad
För att undvika att bryta ned allt behöver ni avgränsa ambitionen. Tänk i beslutsdomäner, inte i system. En beslutsdomän kan vara “prognos”, “pipeline hygiene”, “marketing-sourced revenue” eller “net revenue retention”. Varje domän har sina egna kritiska definitioner och sin egen tolerans för fel.
Börja där konsekvensen av olika siffror är som störst. För många försäljningschefer är det prognos och pipeline. Då handlar arbetet om att definiera: vilka affärer får räknas i commit, vilka steg kräver vissa fält, hur ni hanterar probability, och vad som gäller när affärsdatum flyttas. Det är ofta mer avgörande än att ni har perfekt kunddata i alla fält.
När en domän är “låst” – med ägarskap, definitioner och kontroller – kan ni expandera till nästa. På så sätt växer en single source of truth fram som en serie beslutade standarder, inte som ett stort migreringsprojekt. Det minskar risken och gör värdet synligt tidigare.
BI som sista milen, inte som räddningsplanka
BI kan vara en katalysator, men blir ofta en räddningsplanka när grundproblemen inte är lösta. Då bygger ni lager på lager av logik i rapporterna: regler för att rensa data, mappa fält och “korrigera” pipeline. Det fungerar – tills någon ändrar processen, byter team eller lägger till ett nytt system. Då går förtroendet för rapporteringen snabbt förlorat.
BI ska snarare spegla beslutade definitioner än kompensera för oenighet. När definitionerna är styrda av RevOps och förankrade i ledningen blir BI ett verktyg för uppföljning, inte en arena för att debattera vad siffrorna betyder. Det är först då som “en gemensam sanning” blir operativ, inte bara en ambition.
En praktisk tumregel: om ni ofta behöver förklara “hur rapporten räknar” i möten har ni ett styrningsproblem, inte ett visualiseringsproblem.
Vill du komma framåt utan att störa affären: välj en beslutsdomän (ofta prognos), samla sälj, ekonomi och RevOps kring en gemensam definition, och lås den i era processer innan ni breddar – börja där ni faktiskt fattar beslut nästa vecka.
