En guide for dere som eier beslutningen om en dataplattform for industri og drift: hva plattformen må gjøre, hva OT/IT-integrasjon innebærer, hvorfor datakvalitet avgjør om den blir brukt, og hvordan dere velger mellom å bygge selv, kjøpe fra de etablerte eller kjøre åpen kildekode.
Utgangspunktet
De fleste industribedrifter registrerer allerede alt. Prosessdatabasen har ti år med målinger, kontrollsystemet logger hver alarm, vedlikehold ligger i ett system og produksjonsplaner i et annet, og korreksjonene som får månedsrapporten til å stemme, finnes i et regneark bare to personer forstår.
Det som mangler, er ikke data. Det er ett sted der en måling vet hvilken pumpe den kom fra, hvilken prosess pumpen inngår i, og hvilke rapporterte tall som avhenger av den. Så lenge det stedet ikke finnes, er hvert spørsmål på tvers av systemene en manuell jobb for de mest erfarne folkene deres.
En KPI i en styrerapport, et utslippstall til myndighetene. Å spore det tilbake gjennom regneark og eksporter tar dager, og personen som setter det sammen, er den eneste revisjonsloggen dere har.
Svaret ligger i tre systemer og i hukommelsen til en ingeniør: trenden i prosessdatabasen, arbeidsordren i vedlikeholdssystemet, endringen i settpunkt som ingen loggførte.
Når en måler byttes eller kalibreres på nytt, må noen vite hvilke rapporter som avhenger av den. I de fleste anlegg finnes den kunnskapen bare som erfaring.
Et dashbord dør den dagen det viser sitt første gale tall. Å vinne tilliten tilbake koster langt mer enn det kostet å bygge dashbordet.
Hvorfor ikke systemene dere har
Et rimelig spørsmål fra alle som eier en database, et dokumentlager og et ERP-system: hvorfor er ikke dette bare ett til? Fordi hvert av dem svarer på spørsmål om sitt eget innhold, og ingenting svarer på spørsmål på tvers av dem. En dataplattform starter med datafrigjøring: å kopiere dataene ut av hvert system som holder dem, til lagring dere eier. Så gjør den det andre ingen av dem kan: ett grensesnitt over alt sammen, for mennesker og for AI-agenter.
SQL-databasene og prosessdatabasen deres er utmerkede på akkurat det de holder. Spør en av dem om en arbeidsordre, eller spør ERP-systemet om en vibrasjonstrend, og den har aldri hørt om noe slikt. Ikke en feil, en grense.
Dokumentlageret kjenner prosedyrer og rapporter; ERP-systemet, SAP for mange, kjenner ordrer, kostnader og vedlikehold. Hvert av dem har rett om sin egen verden. Ingen av dem er hele, og ingen var ment å være det.
Kopier strømmer ut av hvert system til ett sted, lander under en modell av driften, og kan besvares gjennom ett grensesnitt, med ett sett rettigheter. Det er hele forskjellen, og det er hele poenget.
Arbeidsbeskrivelsen
Leverandørene i denne kategorien er uenige om det meste, men selve arbeidet ligger fast. Uansett hva dere kjøper eller bygger, må det gjøre seks ting, og en svakhet i en av dem dukker senere opp som en begrensning i alle de andre. Sammen blir de til det folk faktisk vil ha: et sanntidsdashbord der hvert tall er kontekstualisert, underlagt policy og innenfor gjerdet.
Prosessdatabaser, kontrollsystemer, eksporter fra ERP, laboratoriesvar, filer på et fellesområde, flyttet av dataflyter som er bygget inn i plattformen, ikke skriptet ved siden av. Å koble til en ny kilde må være rutinearbeid, ikke et prosjekt med egen styringsgruppe.
Utstyr, prosesser, ansvar og relasjonene mellom dem, beskrevet en gang i en felles modell: en ontologi som lever i en innebygd kunnskapsgraf, ikke et diagram på en prosjektwiki. Det er denne delen som gjør en måling om til et faktum om en bestemt pumpe i en bestemt prosess.
Industrielle tidsserier er enorme, men svært komprimerbare. Plattformen vår oppnår rundt 100x komprimering på tidsserier og rundt 25x på hendelsesdata, der 2 til 4x er det vanlige. Motoren under er bygget for jobben: ClickHouse leser i vårt oppsett over 10 milliarder rader i sekundet. Lagringsøkonomien avgjør om ti år med sekunddata er en avrundingsfeil eller en egen budsjettpost.
Hvert rapporterte tall bør kunne spores tilbake gjennom hver beregning til råsignalene det kom fra, med kvalitetsflaggene intakte. For regulerte tall er det sporet revisjonsloggen deres.
Tilgang avgjøres per datasett og håndheves i plattformens ene dør, likt for mennesker og AI-agenter. Policyer tegner gjerdet: hva som får leses, hva som får endres, hvor plattformen stopper for å spørre. Styring som ettermonteres, er styring som lekker.
Ingeniører, analytikere og AI-agenter leser fra samme modell uten å vite hvilket kildesystem som eier hvilken tabell, og dashbord viser sanntidsdata som kommer kontekstualisert, underlagt policy og innenfor gjerdet. En plattform ingen kan spørre uten en spesialist, er en ny silo med bedre markedsføring.
OT/IT-integrasjon
OT er kontrollsystemene, sensorene og prosessdatabasene: utstyr som måler fysisk virkelighet, bygget for oppetid og sikkerhet, ofte flere tiår gammelt. IT er forretningssystemene: ERP, vedlikehold, planlegging og økonomi, systemene som beskriver hva driften betyr kommersielt.
Nesten alle spørsmål som betyr noe for en beslutningstaker, berører begge. Hva kostet stansen? Stiger energiforbruket per produserte enhet? Hvilke ordrer ryker hvis denne kompressoren fortsetter å vibrere? Å svare krever at en sensormåling kobles til en arbeidsordre, en produksjonsplan og en pris, og den koblingen er det OT/IT-integrasjon faktisk er.
Gjort riktig er integrasjonen enveis og trygg. Plattformen leser fra kontrollsiden og skriver aldri tilbake, og i sensitive miljøer kan koblingen gå gjennom deres egne nettverkssoner eller helt uten internettforbindelse.
Datakvalitet
Det dyreste som kan skje med en dataplattform, er ikke nedetid. Det er at den kjører feilfritt og blir stille ignorert, fordi folkene som kjenner anlegget, har sluttet å stole på tallene den viser.
Kvalitet må måles, per signal og per dimensjon, og flaggene må følge dataene inn i hver beregning. Da blir et galt tall noe plattformen selv melder fra om, ikke noe en årvåken operatør oppdager. Vi måler seks dimensjoner:
Gjenspeiler verdien det som faktisk skjedde i anlegget?
Finnes det hull, og vet beregningene nedstrøms om dem?
Er to systemer enige om samme faktum?
Er dataene ferske nok for beslutningen de skal støtte?
Er hver hendelse registrert en gang, ikke tre ganger via tre veier?
Er verdien i det hele tatt fysisk og logisk mulig?
Bygge, kjøpe eller vente
Dette er en beslutning som handler om år, ikke kvartaler. Da fortjener den klar tale om alle tre alternativene, også om når vårt er feil.
En pipeline er en helg. En plattform er det ikke. Utstyrsmodellen, sporbarheten, kvalitetsflaggene, tilgangsstyringen og lagringsøkonomien ser hver for seg små ut, og til sammen legger de beslag på to ingeniører på ubestemt tid. Det er greit hvis datainfrastruktur er virksomheten dere vil drive.
Riktig når behovene deres er genuint uvanlige og dere har et fast plattformteam. Dyrt i alle andre tilfeller, bare usynlig i starten.
De store leverandørene i kategorien er dyktige og velprøvde, og for noen organisasjoner er de riktig valg. Prisen for tryggheten er et sjusifret beløp, en innføring målt i år, og lagring det er vanskelig å forlate.
Riktig når dere trenger en stor leverandørorganisasjon i ryggen, med navngitt døgnbemannet support og formelle sertifiseringer, og budsjettet ikke er flaskehalsen. Veier dere en av dem opp mot oss, har vi skrevet hva utvikling i full åpenhet endrer, også der de ligger foran i dag.
Plattformen vår er samme kategori med en annen struktur. Åpen kildekode under AGPL-3.0, gratis å drifte selv, standardkomponenter hele veien, som PostgreSQL, ClickHouse, Neo4j og Apache Pulsar, slik at en exit forblir en eksportjobb og ikke en forhandling.
Bygget og driftet av et lite team i Stavanger. Dere snakker med de som skriver koden, og får all hjelp dere trenger.
Datasuverenitet
For norske og europeiske operatører av kritisk infrastruktur stiller innkjøp nå et skarpere spørsmål enn regionnavn kan svare på: hvilken utenlandsk lovgivning kan nå driftsdataene deres? En europeisk region driftet av en amerikansk-kontrollert skyleverandør lukker ikke det gapet.
Vi svarer strukturelt, ikke med en merkelapp på hostingen. Dere velger hvor plattformen kjører, og hvert lag av det som kjører, kan inspiseres.
Vurderingen
Også oss. En leverandør som svarer på disse åtte uten å nøle, er verdt en pilot. En leverandør som svarer med en lysbildepresentasjon, forteller dere også noe.
En plattform dere ikke får ta på før etter innkjøpet, er en plattform der svakhetene dukker opp etter innkjøpet. Insister på å kjøre den, helst på deres egne data.
Hvis utstyrsmodellen først og fremst finnes i hodet til en konsulent eller på en prosjektwiki, forsvinner den sammen med dem. Modellen hører hjemme i plattformen, versjonert og spørrbar.
Be om lagringskostnaden for sekunddata med deres antall målepunkter over et tiår. Komprimering og lagringsteknikk avgjør om det ærlige svaret er ubetydelig eller skremmende.
Velg en KPI og be om å få den sporet tilbake til råsignalene, med kvalitetsflaggene for hver kilde synlige. Dette er egenskapen revisorer og myndigheter stilltiende regner med at dere har.
Spør hvordan en eksport ser ut etter fem år: formater, verktøy og selve modellen. Åpne standardkomponenter gjør svaret kort. Proprietær lagring gjør det til en forhandling.
Spør hvem som tar imot saken, og hvor langt unna koden de sitter. Ærlige svar om supportkapasitet slår imponerende svar om supportprosess.
En troverdig plan starter med en prosess kontekstualisert fra ende til ende, og gir et svar noen faktisk venter på. En plan som starter med utrulling i hele virksomheten, er en plan for år to av en innføring.
Ofte stilte spørsmål
En dataplattform samler data som ligger i adskilte systemer, på ett sted der de kan kombineres, styres og spørres. En operasjonell dataplattform gjør dette for industriell drift: den kobler målinger, hendelser og forretningsdata til en modell av det fysiske utstyret de beskriver, slik at både folk og programvare kan stille spørsmål på tvers.
Et datavarehus lagrer tabeller for rapportering og forutsetter at spørsmålene er kjent på forhånd. En operasjonell dataplattform lagrer i tillegg modellen av driften, utstyret, prosessene og relasjonene mellom dem, og holder tidsserier og hendelser koblet til den modellen, slik at nye spørsmål kan stilles uten å tegne skjemaet på nytt.
De etablerte leverandørene priser gjerne i millioner per år, med innføringer som tar flere år. Plattformen vår er åpen kildekode. Egen drift er gratis, og dere betaler for hosting eller support hvis dere ønsker det. Den ærlige totalkostnaden domineres uansett leverandør av deres eget integrasjons- og modelleringsarbeid.
Ja. Drift den i eget datasenter eller egen sky, kjør den helt uten internettforbindelse, eller la oss drifte den på infrastruktur vi eier i Stavanger. Koden er åpen under AGPL-3.0, slik at det dere kjører, kan leses linje for linje.
Å koble driftsteknologien, altså sensorene, kontrollsystemene og prosessdatabasene som styrer anlegget, sammen med forretningssystemer som ERP, vedlikehold og planlegging, slik at spørsmål som berører begge kan besvares på ett sted. Gjort trygt leser integrasjonen fra kontrollsiden og skriver aldri tilbake.
Plattformen er åpen kildekode, så dere kan sette den opp i deres eget miljø og laste inn ekte data uten å snakke med noen først. En seriøs pilot kontekstualiserer gjerne en prosess på uker, ikke måneder. Utrulling i hele virksomheten tar den tiden dere gir den, og derfor fraråder vi å begynne der.
Hos oss gjør de det: infrastrukturen står i Stavanger og eies og driftes av et norsk selskap, underlagt norsk lov og EØS-rett. Drifter dere selv, ligger dataene der dere velger å legge dem, noe enkelte operatører foretrekker i miljøer uten internettforbindelse.
Ta med ett spørsmål teamet deres i dag besvarer for hånd. Vi sier ærlig fra om en operasjonell dataplattform er riktig verktøy for å besvare det, og om vår er det.