Monitorering – Dashboards er ikke værdi

Når virksomheder begynder at arbejde med industriel data, er et dashboard ofte det første synlige resultat.

Det er konkret. Det kan demonstreres. Og for første gang bliver det måske muligt at følge maskinens drift, se historiske værdier og sammenligne performance på tværs af installationer.

Det er et vigtigt skridt - Men det er også et sted, hvor mange projekter går i stå.

For når data er opsamlet og visualiseret, kan det føles, som om løsningen er færdig. I praksis er det ofte først her, det egentlige arbejde begynder.

Et dashboard kan vise, at noget er galt. Det ændrer ikke nødvendigvis på det.

Som vi har været inde på tidligere i serien, er data et fundament – ikke et slutmål.

Det samme gælder dashboardet.

Et dashboard kan skabe overblik, gøre udviklinger synlige og give forskellige dele af organisationen et fælles billede af driften. Det kan være afgørende i forbindelse med fejlsøgning, optimering og dokumentation.

Men værdien opstår ikke i det øjeblik, en kurve bliver vist på en skærm.

Den opstår først, når den nye viden fører til en beslutning, en handling eller en ændring i den måde, arbejdet udføres på.

Det lyder måske indlysende. Alligevel ser vi mange løsninger, hvor store mængder data præsenteres i realtid, mens reaktionen fortsat afhænger af, at den rigtige person tilfældigvis åbner det rigtige dashboard på det rigtige tidspunkt.

Et dashboard er grundlæggende et medie, man selv skal opsøge.

Nogen skal logge ind. Nogen skal opdage afvigelsen. Nogen skal forstå, hvad den betyder. Og nogen skal efterfølgende beslutte, hvad der skal gøres.

Under en demonstration fungerer det ofte godt. Her er alle opmærksomme på skærmen, og de viste data er i centrum.

Den daglige drift ser anderledes ud.

Operatører passer produktionen. Serviceorganisationen håndterer eksisterende sager. Produktionsledelsen deltager i møder, og vedligeholdelsesteamet prioriterer mellem mange opgaver. Selv tydelige afvigelser kan derfor blive overset eller udskudt.

Ikke fordi organisationen mangler vilje.

Men fordi opmærksomhed er en begrænset ressource.

Hvis løsningen kun virker, når nogen husker at kigge, er den afhængig af en arbejdsgang, som ofte ikke er defineret.

Et klassisk eksempel er et dashboard med OEE, stopårsager, alarmer og produktionsdata.

Teknisk fungerer alt. Data opdateres, graferne er korrekte, og det er muligt at se, at en bestemt maskine har mange korte stop.

Problemet bliver måske også nævnt på et tavlemøde.

Men hvis det ikke er aftalt, hvem der undersøger årsagen, hvornår det skal ske, og hvordan resultatet skal følges op, ændrer dashboardet ikke nødvendigvis noget.

Efter nogle uger bliver mønstret en del af normalbilledet. De korte stop er stadig synlige, men de vækker ikke længere samme opmærksomhed.

Afvigelsen er blevet accepteret.

Det samme gælder, når data vises i realtid. En måling kan blive opdateret hvert sekund og stadig først blive gennemgået på næste månedsmøde. Omvendt kan en daglig beregning af driftstimer være særdeles værdifuld, hvis den udløser en serviceopgave, inden vedligeholdelsesintervallet overskrides.

Realtid er derfor ikke et mål i sig selv.

Det afgørende er, om informationen når frem til den rette person, mens der stadig kan handles på den. Nogle hændelser kræver opmærksomhed med det samme. Andre skal analyseres over flere dage eller uger, før en handling giver mening.

Ansvar og reaktionstid skal derfor defineres sammen.

Uden en tydelig ejer bliver afvigelsen ikke håndteret. Og hvis informationen kommer for sent, har selv den rigtige reaktion begrænset værdi.

Problemet er ikke manglende data.

Problemet er, at observationen ikke er koblet til en ansvarlig, en tidsramme og en konkret handling.

At et dashboard ikke skaber værdi alene, betyder ikke, at dashboards er uden værdi.

Forskellen ligger i, om dashboardet blot viser information, eller om det er designet til at understøtte en konkret handling.

Det ser vi eksempelvis hos BIRN , hvor realtidsdashboards giver truckførerne den information, de har brug for til at gennemføre smelteprocessen så energieffektivt som muligt.

Her bliver data ikke først gennemgået bagefter. Den bliver præsenteret for den relevante medarbejder, mens der stadig kan handles på den.

Produktionsledelsen kan samtidig bruge de historiske data til at sammenligne processer og identificere forhold, der påvirker performance og energiforbrug.

Dashboardet er stadig kun et værktøj. Men fordi det er koblet til en bestemt rolle, en konkret arbejdssituation og et tydeligt mål, bliver informationen omsat til ændret adfærd.

Kæden bliver dermed:

Måling → feedback → handling → effekt

Det er netop denne kæde, der adskiller monitorering fra reel værdiskabelse.

Den umiddelbare løsning på et dashboard, som ingen kigger på, er ofte at oprette flere alarmer og notifikationer.

Men flere beskeder skaber ikke nødvendigvis mere opmærksomhed.

Hvis alle afvigelser udløser en mail, SMS eller pushbesked, flyttes problemet blot fra dashboardet til modtagerens indbakke. Over tid risikerer organisationen, at vigtige hændelser forsvinder mellem gentagne eller mindre relevante beskeder.

Derfor er det vigtigt at skelne mellem en hændelse, en notifikation og en egentlig alarm.

En hændelse fortæller, at noget er sket. En notifikation gør en person opmærksom på hændelsen. En alarm bør derimod være forbeholdt en unormal situation, der kræver en rettidig reaktion fra en bestemt rolle.

Hvis ingen ved, hvad der skal gøres, er der strengt taget ikke tale om en handlingsanvisende alarm.

Så er der snarere tale om information.

Denne skelnen er ikke ny.

I procesindustrien har man i mange år arbejdet struktureret med alarm management efter principperne i ISA-18.2. Standarden beskæftiger sig med hele alarmens livscyklus – fra identifikation og prioritering til design, drift, vedligeholdelse, overvågning og løbende forbedring.

Et centralt princip er, at en alarm skal være relevant, prioriteret og knyttet til en kendt operatørhandling. Ellers risikerer alarmsystemet at skabe støj frem for sikkerhed.

Problemer som alarm floods, chattering alarms og kortvarige, gentagne alarmer opstår typisk i SCADA- og kontrolsystemer, hvor operatøren skal kunne skelne det kritiske fra det mindre væsentlige.

Her kan historiske analyser vise, hvilke alarmer der forekommer hyppigst, hvilke der gentager sig uden reel konsekvens, og hvilke situationer der belaster operatøren med mange samtidige signaler.

Da Inuatek tidligere var en del af INIT, arbejdede vi med en første prototype, der netop flyttede denne analyse op i cloud. Løsningen ekstraherede alarmhistorik fra SCADA-systemet, strukturerede data og anvendte ISA-18.2-baserede beregninger til at identificere blandt andet tilbagevendende, flygtige og chattering alarms.

Formålet var ikke at erstatte SCADA-systemet.

Formålet var at skabe et bedre grundlag for at rydde op i alarmbilledet og forbedre det eksisterende system.

DCC er ikke et traditionelt alarm management-system og analyserer ikke automatisk en komplet SCADA-alarmdatabase efter ISA-18.2.

Men tankegangen er stadig relevant.

Når relevante hændelser og maskintilstande indgår i de data, der sendes til DCC, kan de analyseres over tid og på tværs af maskiner.

Det kan eksempelvis gøre det muligt at se, hvilke hændelser der forekommer hyppigst, hvor længe bestemte tilstande varer, hvilke signaler der gentager sig, og hvad der skete umiddelbart før en hændelse.

Samtidig kan man undersøge, om det samme mønster optræder på flere maskiner eller installationer.

DCC kan dermed understøtte nogle af de samme målsætninger: mindre støj, bedre prioritering og mere relevant kontekst.

Men afgrænsningen er vigtig.

Det er fortsat SCADA-, PLC- eller kontrolsystemet, der håndterer de operationelle og eventuelt sikkerhedskritiske alarmer. DCC kan supplere med historik, flådeoverblik, analyse og målrettede notifikationer uden at overtage rollen som anlæggets alarmsystem.

Pointen er derfor ikke, at alle principper fra ISA-18.2 skal overføres direkte til en cloudplatform.

Pointen er, at vi kan lære af den grundlæggende disciplin:

En alarm skal ikke blot fortælle, at noget er sket. Den skal hjælpe den rette person med at gøre det rette – i tide.

Det samme princip ses i MyM&J Performance , hvor realtidsdata og historiske data bruges til at identificere driftsmæssige afvigelser tidligt og understøtte proaktive serviceprocesser på tværs af den globale maskinflåde.

Her er værdien ikke alene, at en afvigelse bliver synlig. Værdien ligger i, at serviceorganisationen får mulighed for at reagere, før et mindre problem udvikler sig.

Før man opretter et nyt dashboardelement eller en ny alarm, er det nyttigt at definere hele forløbet fra observation til effekt.

Det kræver svar på fem spørgsmål:

1. Hvad betyder signalet?

Hvilken driftsmæssig eller forretningsmæssig konsekvens kan afvigelsen have?

2. Hvem ejer reaktionen?

Er det operatøren, vedligeholdelsesteamet, serviceorganisationen, produktionsledelsen eller maskinbyggeren?

3. Hvad skal der konkret ske?

Skal en værdi kontrolleres, en komponent inspiceres, kunden kontaktes eller en arbejdsordre oprettes?

4. Hvor hurtigt skal der reageres?

Og hvem skal informeres, hvis den første modtager ikke reagerer?

5. Hvordan ved vi, at handlingen virkede?

Skal alarmen kvitteres, hændelsen lukkes, eller skal data efterfølgende vise, at problemet er reduceret?

Når disse spørgsmål er besvaret, bliver det også lettere at vælge de relevante data og den rigtige præsentation.

Uden svarene risikerer virksomheden at bygge et flot informationslag oven på en proces, der stadig er uklar.

Når man taler om at automatisere reaktionen på data, bliver det nogle gange opfattet, som om cloudplatformen automatisk skal ændre værdier i PLC’en eller overtage styringen af maskinen.

Det er kun én – og ofte slet ikke den mest relevante – form for automatisering.

Automatisering kan også være, at den rette person automatisk får besked. At en servicehenvendelse oprettes med maskin-ID, alarmhistorik og de relevante kurver. At en vedligeholdelsesopgave bliver planlagt på baggrund af driftstimer. Eller at en manglende reaktion eskaleres til en anden rolle.

På den måde kan data udløse en organiseret proces, uden at systemet har mulighed for at påvirke selve produktionen.

Det er en vigtig skelnen. Især i industrielle miljøer, hvor sikkerhed, ansvar og kontrol skal være tydeligt placeret.

Den bedste løsning er heller ikke nødvendigvis den, hvor alle beslutninger er automatiseret.

Nogle situationer kræver erfaring, kontekst og faglig vurdering. En tekniker kan have viden om kunden, maskinens historik eller de aktuelle driftsforhold, som ikke findes i datasættet.

Automatisering giver især mening, når handlingen er veldefineret, gentagelig og har en begrænset risiko. Når situationen er kompleks eller sikkerhedskritisk, bør systemet i højere grad understøtte menneskets beslutning.

Målet er derfor ikke altid at fjerne mennesker fra processen.

Målet er at fjerne den unødvendige afhængighed af, at nogen manuelt skal lede efter problemet.

Systemet kan opdage, prioritere og levere konteksten. Mennesket kan træffe den beslutning, hvor menneskelig vurdering skaber værdi.

Dashboards er ikke problemet.

De er særdeles nyttige, når man skal undersøge, hvorfor en hændelse opstod, sammenligne perioder eller maskiner og forstå sammenhængen mellem forskellige signaler.

De kan skabe et fælles udgangspunkt for operatører, teknikere, ledelse og kunder. De er også værdifulde i det mere langsigtede forbedringsarbejde, hvor mønstre ikke nødvendigvis kræver en øjeblikkelig reaktion.

Men dashboardet skal designes til en konkret opgave.

Et dashboard til en operatør bør ikke nødvendigvis ligne et dashboard til en servicechef. Den ene har brug for at se, hvad der kræver opmærksomhed nu. Den anden har måske brug for at se udviklingen på tværs af den installerede base.

Hvis alle får adgang til alle data, får organisationen ikke nødvendigvis mere indsigt.

Den får ofte bare flere steder at kigge.

Det gode dashboard reducerer kompleksitet. Det viser den relevante kontekst for en bestemt rolle og gør det lettere at træffe en beslutning.

Det kan være fristende at måle et dataprojekts succes på antallet af tilsluttede maskiner, dashboards, brugere eller alarmer.

Men disse tal fortæller primært, hvor meget systemet bliver anvendt. Ikke om det skaber værdi.

De mere interessante spørgsmål er:

• Er tiden fra fejl til reaktion blevet kortere?
• Bliver flere problemer løst på afstand?
• Er antallet af gentagne stop reduceret?
• Bliver service udført på det rigtige tidspunkt?
• Er det lettere at finde årsagen til en fejl?
• Og fører den nye viden faktisk til ændringer i drift, service eller produktdesign?

Et dashboard kan være en del af løsningen på alle disse områder.

Men det er effekten i den fysiske drift og i organisationens processer, der bør afgøre, om projektet er en succes.

Overgangen fra monitorering til handling behøver ikke begynde med et stort automatiseringsprojekt.

Ofte er det bedre at vælge én konkret hændelse, som allerede har en tydelig konsekvens. Det kan være et gentaget stop, et serviceinterval eller en temperatur, der over tid bevæger sig uden for normalområdet.

Definér derefter én ansvarlig rolle, én forventet handling og ét mål for effekten.

Når hele kæden fungerer – fra signal til reaktion og dokumenteret resultat – kan samme princip udvides til flere maskiner og use cases.

Det er mere værdifuldt at have én afsluttet handlingskæde end tyve dashboards, som ingen føler et tydeligt ansvar for.

Monitorering gør driften synlig.

Det er vigtigt, men synlighed er kun potentialet for værdi.

Den faktiske værdi opstår, når den relevante information når frem til den rette person på det rette tidspunkt, når der er en kendt reaktion, og når organisationen kan se, om handlingen havde den ønskede effekt.

Dashboardet er derfor ikke slutproduktet.

Det er et værktøj til at forstå, beslutte og lære.

Forskellen ligger i, hvad der sker bagefter.

I næste del ser vi nærmere på de tab, der sjældent udløser en kritisk alarm, men som over tid kan blive langt dyrere end de enkelte store hændelser:

Hvor værdien gemmer sig i de små, tilbagevendende ineffektiviteter.