Error: Contact form not found.
Neem contact op voor een kopje koffie.
In het streven naar steeds beter assetmanagement en het vaststellen van de Asset Health van een fabriek of organisatie groeit de hoeveelheid data. In veel gevallen wordt het zo veel dat het beheer en de analyse van die data vraagt om digitalisering. Dat is een stap die zeker waardevol kan zijn, maar ook heel wat voeten in de aarde heeft. Waar moet je op letten?
Een elektriciteitsbedrijf heeft te kampen met een groeiend aantal storingen door falende vermogensschakelaars. Er is behoefte aan beter inzicht in de gezondheid van de assets, zodat preventief, op een gepland moment, vervanging of herstel kan worden uitgevoerd. Wat weten we over deze vermogensschakelaars?
Toen mijn hulp werd ingeroepen, hebben we een Proof of Concept project opgezet, met drie stappen:
In een expertmeeting hebben we met behulp van de leveranciersdocumentatie een FMECA (Failure Mode Effect & Criticality Analysis) uitgevoerd: wat kan er allemaal misgaan en wat is het effect daarvan? Dit zorgde ervoor dat de impliciete kennis (in hoofden) expliciet werd gemaakt.
We hebben data uit drie systemen gedownload: het financiële systeem, het onderhoudsbeheerssysteem en het procesbesturingssysteem. De eerste twee bevatten zogeheten transactionele data (een datapunt per transactie), de derde bevat real-time data (elke milliseconde wordt een statusupdate gelogd). Die twee soorten data laten zich moeilijk combineren. Daarom was dataprocessing nodig om analyses mogelijk te maken. Dataprocessing betekende onder andere: verzamelen, opschonen, naamgevingen gelijktrekken, converteren, aggregeren en visualiseren.
Deze analyse leverde belangrijke inzichten op. Ten eerste lieten de kwaliteit en de compleetheid van de data in de transactionele systemen te wensen over, waardoor analyse moeilijk was. Ten tweede bevatte het procesbesturingssysteem veel data die potentieel interessant waren, maar niet werden benut. Zoals de storingsmeldingen.
Een zeer opvallend resultaat tot slot was een berekening van de open-/sluittijd op basis van de real-time data. Van één vermogensschakelaar bleek deze tijd op te lopen. Eind januari trad een ongepland falen op, maar terugkijkend hadden de gegevens vijf maanden eerder al een duidelijk signaal voor actie moeten zijn. Daarvoor had het bedrijf dan wel een Asset Health-dashboard moeten hebben met deze datavisualisatie.
Aan de ene kant zijn in de FMECA de werking en faalwijzen vastgelegd. Aan de andere kant hebben we de data. Idealiter wil je voor elke faalmodus een conditie-indicator hebben. Die wordt gevoed door de relevante data. De verschillende conditie-indicatoren aggregeren samen tot een Health Indicator.
Dan moet je weten wat de belangrijkste faalmodi zijn. Daarvoor heb je conditie-Indicatoren nodig. Met een match tussen de data en de faalmodi. Dan ontkom je er niet aan vast te stellen welke onmisbare data nog ontbreken. Aanvullende inspectie of monitoring kan dat tekort in veel gevallen oplossen. In het voorbeeld van de vermogensschakelaar hebben we een potentieel interessante indicator gevonden (de open-/sluittijd), maar welke faalmodi worden hiermee afgedekt (en welke niet)?
Het combineren van de afzonderlijke conditie-indicators leidt tot een Asset Health Indicator. Heer belangrijk hierbij is de weging van de verschillende indicatoren: welke indicator overrulet de andere. Dit bepaalt het algoritme achter de Health Indicator.
Ik heb het praktijkvoorbeeld uitvoerig beschreven, omdat het naar mijn mening goed laat zien waar je tegenaan loopt bij het benutten van assetdata om de kennisdriehoek te vergroten. Het is complexe materie en er moet veel gebeuren:
De onderdelen zie je afgebeeld in dit schema, dat een hoger conceptueel niveau weergeeft dan de Proof of Concept uit het voorbeeld. Wat is ervoor nodig als we de Proof of Concept willen opschalen? En we willen niet alleen vermogensschakelaars op die manier gaan monitoren, maar ook transformatoren, scheiders en secundaire apparatuur? Hoe houd je dat beheersbaar?
Om de data uit de verschillende systemen te kunnen combineren zijn afspraken nodig over standaardisering: heeft iedereen het over hetzelfde? Maar er is eveneens een nieuw soort vakmanschap nodig, data-analyse, als aanvulling op het traditionele vakmanschap (werktuigbouw, civiel, elektro).
Data worden op zichzelf een asset, waardevol en kritisch. Net als bij fysieke assets dient zich dan de vraag aan wat de kerncompetentie van je bedrijf is en welke kennis/assets je in eigen huis wilt hebben en wat je beter kunt uitbesteden.
We willen de kennis ‘vangen’ in modellen – zelfgebouwd of aangeboden door leveranciers. De introductie van platformtechnologie biedt nieuwe technische mogelijkheden. Maar wees je ervan bewust dat een aantal grote spelers dit domein willen beheersen, net als in de privé-omgeving (Apple, Google, Microsoft). Dat maakt je afhankelijk; een eenmaal gemaakte keuze is later lastig terug te draaien.
Sowieso brengt meer vertrouwen op data ook een potentiële kwetsbaarheid met zich mee. Direct (malware), maar ook indirect… wat als de concurrent (eventueel via een gezamenlijke leverancier) inzicht krijgt in de gezondheid van jouw assets en te weten komt wanneer zich een grote storing aandient? Zeker bij beursgenoteerde bedrijven is dit gevoelige informatie.
Misschien wel de belangrijkste en lastigste opgave is samenwerking. Op technisch vlak zullen IT, OT (procesbesturing), ET (engineering) en de gebruikers (assetmanagers) nauw moeten samenwerken.
Duidelijk is dat IT een noodzakelijke randvoorwaarde is om opschaling mogelijk te maken: juiste infrastructuur, interoperabiliteit tussen systemen, standaarden, processing-capaciteit, platform, aanschaf software etcetera. In de praktijk komt het regelmatig voor dat de IT-afdeling, in een poging klantvriendelijk te zijn, de assetmanagers maximaal wil ondersteunen. Bijvoorbeeld door na een geslaagde Proof of Concept een maatwerkapplicatie te bouwen of te kopen (in het voorbeeld één waarmee de open-/sluittijden van vermogensschakelaars kan worden gemonitord).
Hierin schuilt een groot risico: fragmentatie. Hoe meer maatwerkoplossingen, hoe onoverzichtelijker het IT-landschap wordt. Met het gevaar van onbeheersbaarheid en als gevolg hiervan juist starheid.
Haast, gedreven door een gevoel van urgentie, is sowieso een valkuil bij digitalisering van Asset Health. Terwijl eerst de basis op orde gebracht moet worden – standaardisatie, vereenvoudiging en dergelijke – voelt men de tijdsdruk. Het is juist verstandig om deze stagnatie te benutten, te omarmen. Wetenschappelijk onderzoek (door de Vrije Universiteit) heeft uitgewezen dat digitale transformatie gebaat is bij stagnatie.
Daar kan ook bewust voor worden gekozen. Het scheelt een hoop paniek, incidentbestrijding en brandjes blussen. Bij de overheid zien we dat nu gebeuren: de Belastingdienst accepteert de komende tijd geen wijzigingen en nieuwe taken meer; eerst brengt men de basis op orde om zodoende in het vervolg te kunnen inspelen op verzoeken vanuit de politiek.
Mijn advies is dan ook om niet meteen na een geslaagde Proof of Concept door te schakelen naar het aanschaffen of bouwen van een softwareapplicatie en een dashboard. Bouw nog een tussenstap in: een pilot. Het doel van deze pilot is om in kaart te brengen welke randvoorwaarden nodig zijn voor verdere opschaling: organisatie, competenties, technologie, processen en data. Tip: betrek alle stakeholders (intern en extern) bij de pilot. Dan mis je geen input en hoef je niet achteraf nog allerlei wijzigingen of aanvullingen te verwerken.
Na de pilot kun je stap voor stap toewerken naar de digitale transformatie. Een ontwikkeling die nog maar in de kinderschoenen staat. Als je nu begint, ben je er op tijd bij. Neem die tijd dan ook, om het goed en doordacht uit te voeren.
"*" geeft vereiste velden aan
Principal Consultant
arjen.van.bruchem@iesbv.nl