De flesta dataprojekt börjar med goda intentioner och rätt analys. Informationen sitter i för många system, beslutsunderlagen tar för lång tid att ta fram, och organisationen behöver en gemensam bild. Allt det stämmer.
Ändå landar många datalager i ett tillstånd där de används av ett fåtal, kringgås av resten och kräver fortlöpande underhåll utan att någon riktigt vet vem som äger dem.
Det finns fyra mönster vi ser oftare än vi vill.
Ingen äger datalaget
Tekniken är på plats, men ansvaret för vad som är korrekt, aktuellt och tillförlitligt har aldrig tilldelats någon. När en siffra är fel — och det händer — finns det ingen som tar den frågan. IT skyller på källsystemet. Verksamheten skyller på IT. Analytikern gör en workaround. Tilliten urholkas stille och utan att det beslutas.
Tillgången är för begränsad
Datalager hamnar lätt i ett läge där de fyller ett fåtal standardrapporter men inte är tillgängliga för dem som faktiskt behöver ställa frågor. Controllern begär en ny rapport. Analytikern bygger den. Nästa gång ber någon om ett litet tillägg. Plattformen fungerar som ett produktionsverktyg snarare än ett beslutsstöd, och de som behöver data mest väntar fortfarande i kö.
"Det beror på hur man räknar"
Den frasen är ett symtom. Datalager som inte kodifierar definitioner — vad som är en "aktiv kund", när en affär är "stängd", hur "marginal" beräknas — skapar utrymme för tolkningar och parallella versioner av sanningen. Ingen litar på den gemensamma rapporten eftersom alla vet att den kan räknas annorlunda. Och den gemensamma bilden, som var hela poängen, förblir en önskan.
Det byggdes för teknikens skull
Det är lätt att bli fascinerad av arkitekturen och optimera för teknisk korrekthet utan att lösa det ursprungliga problemet. En plattform byggd för att vara "rätt" snarare än för att besvara specifika beslutsfrågor tenderar att vara komplex att använda och svår att motivera när nästa budgetcykel kommer.
Vad som skiljer en plattform man litar på är inte i första hand tekniken. Det är governance — vem som äger vad, vilka definitioner som gäller, vad som händer när data är fel — och tillgängligheten för dem som ska använda den, utan att gå via en analytiker varje gång.
Det är också ordningen projektet görs i. Börja med beslutsbehoven: vilka frågor ska plattformen besvara och för vem? Arkitektur, datakvalitet och integrationsprioriteter följer av det svaret. Görs det omvänt — bygg plattformen, se sedan vad den kan användas till — är risken tydlig.
Gaia börjar varje dataprojekt med en genomgång av beslutsbehov och ägandeskap. Inte för att det låter bra i en presentationsrubrik, utan för att det är det som avgör om plattformen fortfarande används om tre år.
Om ni har ett datalager som inte levererar det ni hoppades: frågan att börja med är inte "vad är fel tekniskt?" utan "vem äger de definitioner och det ansvar som plattformen förutsätter?" Det svaret pekar på vad som faktiskt behöver förändras.
Gaia System AB
Microsoft Fabric, dataplattformar och systemutveckling i Norrköping sedan 1995