Data engineering och analysplattformar som faktiskt används. BigQuery, pipelines, ETL och BI - byggt så att rätt personer får rätt siffror, i tid och att lita på.
De flesta organisationer jag möter har gott om data. Problemet är att den är utspridd över tio olika system – CRM, affärssystem, kalkylblad, exportfiler, SaaS-rapporter – och att ingen har helheten. Det leder till ett välbekant mönster: två avdelningar räknar samma sak och får olika svar, diskussionen handlar om siffrorna istället för besluten, och förtroendet för datan urholkas gradvis.
En dataplattform löser inte alla problem över en natt. Men den etablerar en central sanning – ett data warehouse där alla källor landar i en gemensam modell – och ett system för att hämta, transformera och presentera data på ett sätt som går att lita på. Nyckeln är att börja med besluten som ska fattas, inte med tekniken. Vilka frågor behöver verksamheten svar på varje vecka, varje månad, varje kvartal? Plattformen byggs baklänges från de frågorna.
Jag ser ofta att den största utmaningen inte är teknisk utan organisatorisk. Att få olika avdelningar att enas om gemensamma definitioner – vad är egentligen en 'aktiv kund'? – är minst lika viktigt som att få pipelines att fungera. Min metod är att bygga i iterationer: en pipeline i taget, en dashboard i taget, med kontinuerlig feedback från verksamheten.
Det finns en pågående trend där allt fler pratar om data lakehouse som en universallösning. I praktiken är valet mellan warehouse, lakehouse eller lake en fråga om vilken typ av data ni hanterar och vad ni vill göra med den. Ett data warehouse (som BigQuery) är utmärkt för strukturerad data och snabba aggregat – perfekt för dashboards och rapporter. En data lake är rätt för rådata, maskininlärning och situationer där ni inte vet vilka frågor ni vill ställa i förväg.
Lakehouse försöker kombinera det bästa av två världar – och det fungerar, men med en komplexitet som många underskattar. Min rekommendation är att börja med en tydlig warehouse-modell för er nyckeldata (försäljning, kunder, ekonomi) och komplettera med en lake för rådata från loggar, sensorer eller externa källor. Det ger en enkel utgångspunkt som går att utöka när behoven växer.
En dataplattforms svagaste punkt är ofta pipelines. De byggs snabbt, dokumenteras sällan, och när de väl fungerar glöms de bort – tills de en dag tyst slutar fungera och en rapport visar felaktiga siffror i två veckor innan någon märker det. Jag bygger pipelines med tre principer: de ska vara övervakade (larm när data inte kommer fram), de ska vara återanvändbara (samma transformationslogik ska inte dupliceras), och de ska vara testade (kvalitetskontroller på vägen).
För de flesta moderna plattformar rekommenderar jag ELT-arkitektur (Extract, Load, Transform) snarare än traditionell ETL. Skillnaden är att rådata laddas in först och transformeras därefter – vilket ger flexibilitet att omdefiniera transformationer utan att hämta data på nytt. Verktygsvalet (dbt, Dataform eller egen kod) styrs av teamets kompetens och plattformens ekosystem.
De organisationer vi arbetar med brottas oftast med minst ett av dessa.
Siffrorna finns - men i CRM, affärssystem, kalkylblad och exportfiler. Ingen har helheten.
Två avdelningar räknar samma sak och får olika svar. Diskussionen handlar om siffrorna, inte besluten.
Någon lägger dagar på att klippa ihop Excel. Insikten kommer alltid för sent.
Ett projekt drogs igång men fastnade. Nu finns halv infrastruktur som varken används eller underhålls.
Selektivt urval av uppdrag - där senior teknisk kompetens gör störst skillnad.
Kartläggning av datakällor, behov och flaskhalsar. En realistisk plan för en plattform som faktiskt används.
Robusta, övervakade pipelines från källsystem till data warehouse - schemalagda och larmade.
BigQuery eller motsvarande som central sanning, modellerat så att det går att bygga vidare på.
Dashboards och rapporter som svarar på verksamhetens faktiska frågor - inte bara visar grafer.
Hämtning från CRM, affärssystem, API:er och externa källor - inklusive scraping där det behövs.
Tester, dokumentation och åtkomststyrning så att data går att lita på och dela tryggt.
Tydlig process från första samtalet till levererat resultat.
Förutsättningslöst samtal om vilka beslut datan ska stödja och var den finns idag.
Genomlysning av källor och behov. Ni får en arkitektur och prioriterad plan.
Pipelines, warehouse och dashboards byggs stegvis med veckovisa demos.
Dokumentation, kod och kunskapsöverföring. Ert team äger plattformen.
Transparenta upplägg utan dolda kostnader. Alla priser exkl. moms.
Kartläggning av källor och behov med arkitekturförslag och prioriterad plan.
Definierat projekt - pipelines, warehouse och dashboards med tydlig scope.
Löpande arbete med plattform, pipelines och rapportering med prioriterad tillgänglighet.
Läs mer om ämnet i våra artiklar.
Svar på det jag oftast får höra.
Nej. BigQuery är ofta ett starkt val tack vare låg driftbörda och bra pris/prestanda, men plattformen väljs efter era krav, befintlig molnmiljö och kompetens.
Ja. En vanlig situation är att ett projekt stannat. Då börjar arbetet med en genomlysning av vad som finns och vad som är värt att bygga vidare på.
Ofta ja. Jag har byggt datainsamling i stor skala, inklusive scraping och integration mot system med begränsade gränssnitt.
Ja. En plattform utan användbara dashboards ger inget värde - BI och rapportering ingår som en naturlig del.
Med tester i pipelines, tydlig modellering, dokumentation och övervakning som larmar när något avviker - så att fel upptäcks innan de når en rapport.
Nästa steg
Har ni en ambitiös idé eller ett tekniskt vägval där det är värt att tänka rätt från början? Hör av er - förutsättningslöst.
Ta kontakt