Elektrotechnische standaardisatie: Project-standaarden voor verschillende klanteisen
20 december 2024
De copy-paste chaos
Het is dinsdagochtend en Pieter, electrical engineer bij een system integrator, zucht diep terwijl hij naar zijn scherm kijkt. Voor hem alle documentatie van een nieuwe chocoladefabriek. “Weer een andere elektrotechnische standaard dan de vorige locatie,” zucht Pieter. Al het werk dat hij en zijn collega’s in de bedrijfsstandaard hebben gestoken, lijkt voor niets geweest. Binnen de industriële automatisering, en met name in electrical engineering, is dit een terugkerend probleem. System integrators proberen eindeloos bedrijfsstandaarden op te zetten, maar efficiënt werken met de wisselende eisen van een klant blijft een uitdaging. De oplossing die Pieter vaak kiest – en met hem velen in de industrie – lijkt simpel, maar is riskant: hij kopieert elektrische schema’s uit een eerder project. “Waarom het wiel opnieuw uitvinden?” Maar deze aanpak heeft zijn risico’s. Fouten uit het vorige project worden vaak onbewust meegenomen naar het nieuwe project, waardoor je al met 1-0 achterstaat. Of objecten die mee worden gekopieerd, maar helemaal niet nodig zijn voor het nieuwe project. Dit leidt tot overbodige bestellingen van materiaal en onnodige kosten. Het grote probleem van deze fouten is dat ze vaak pas in een later stadium worden ontdekt, bijvoorbeeld tijdens de paneelbouw of, erger nog, tijdens de inbedrijfstelling. Iedereen kent wel een voorbeeld van een project dat volledig ontspoorde door een simpele fout. Een verkeerde motorspecificatie kan een kettingreactie van problemen veroorzaken. Delen van de schema’s kunnen opnieuw worden gemaakt, terwijl de deadline onveranderd blijft.
.
Project-standaardiseren echt mogelijk
Het is echt mogelijk om een standaard te bouwen in een industrie die gebonden is aan verschillende klantstandaarden. Alleen de denkwijze zal drastisch anders worden. Machinebouwers hebben een eigen product en zijn, over het algemeen, niet gebonden aan klantstandaarden. Zij bouwen een eigen elektrotechnische standaard, waarin macro’s worden gedefinieerd en configureerbaar worden gemaakt. Electrical engineers leren werken met deze standaard en werkwijze. System integrators bevinden zich echter in een andere situatie. Zij hebben geen eigen product en zijn doorgaans wel gebonden aan klantstandaarden. In plaats van een vaste standaard ontwikkelen en hiermee te leren werken, is het een betere methode om te leren een standaard te ontwikkelen. Wat hiermee wordt bedoeld, is dat voor bedrijven die met wisselende klantstandaarden werken, het proces van standaardontwikkeling belangrijker is dan de standaard zelf.
.
Vijf keer of meer
In eerdere blogs hebben we het proces uitgelegd en een verdiepende slag gemaakt in de projectfase pre-engineering. In deze fase verzamel je alle relevante documentatie, zoals P&ID’s, instrumentatieverbruikerslijsten, e-mails met uitgangspunten, de scope van het project, standaarden of macro’s die de klant zelf al heeft, en voorbeeldprojecten en schema’s, zowel van jezelf als van de klant. Ja, ook voorbeeldschema’s van voorgaande projecten. Niet om te kopiëren, maar om inzicht te krijgen in de gewenste vormgeving van de macro’s volgens de klant.
Op basis van al deze gegevens kun je de herhalingsgraad van objecten in het project bepalen. Onze stelregel: alles wat vijf keer of meer voorkomt, is rendabel om te automatiseren. Objecten die minder dan vijf keer voorkomen, worden pas in de nabewerkingsstap opgepakt. Van alle objecten die meer dan vijf keer voorkomen, wordt een standaard gemaakt, of beter gezegd, een project-standaard. Dit betekent dat keuzes over de uitgangspunten van de standaard uitsluitend worden afgewogen binnen de context van het project zelf en niet ten opzichte van eventuele toekomstige projecten. Neem bijvoorbeeld de grootte van een macro. Voor het ene project kan het nodig zijn om een macro zo klein mogelijk op te splitsen, terwijl voor een ander project het efficiënter is om met paginamacro’s te werken. Dit verschil benadrukt het contrast tussen de aanpak van een machinebouwer en een system integrator. Machinebouwers hebben baat bij het nadenken over toekomstige projecten, omdat dit vaak dezelfde machine betreffen in een andere configuratie. Een systemintegrator heeft deze zekerheid niet. Zijn doel is om dit project op de afgesproken levertijd, met de juiste kwaliteit, tegen de juiste prijs te leveren. Zijn “toekomstige project” kan wel van dezelfde klant zijn, maar wellicht niet van dezelfde locatie waardoor hij opnieuw te maken krijgt met andere standaarden.
.
Opstellen van een projectstandaard
In deze fase van het project wordt een macro met extra variabelen een typical genoemd. Voor ieder object dat meer dan vijf keer voorkomt, stel je vragen zoals: hoe wordt de indeling van de typical bepaald? Welke opties en varianten kent het object binnen dit project? Bestaat er al een typical? Waar leggen we de knip in de typical om de detailengineering zo efficiënt mogelijk uit te voeren? Het belangrijkste is dat keuzes rondom standaardisatie alleen gericht zijn op het huidige project. Dit betekent dat je pragmatisch te werk gaat. Een paginamacro maken die je hierna misschien nooit meer gebruikt? Doen, als het dit project helpt. Discussies over PLC’s die de klant ook op andere locaties gebruikt? Niet voeren, want dat is niet relevant voor dit specifieke project.
Van ieder uniek object wordt een voorbeeld schema gemaakt. Dit is één pagina waar één uniek object staat uitgebeeld met alle opties en varianten erin. Dit pakket aan tekeningen wordt met de klant besproken. Het grote voordeel wat je hiermee bereikt is dat klant al heel vroeg in het project, weet wat hij krijgt aan het einde. De verwachtingen worden vroegtijdig afgestemd, de kwaliteit wordt geborgd en de uitkomst van de detail engineering wordt voorspelbaar. Stel, je werkt met een generatietool zoals Typical Manager. Dan is dit ook het moment om de bibliotheek aan te passen op basis van de nieuwe varianten uit de typicals. In de volgende projectfase, automatiseren, ga je de typicals “slim maken” en koppelen aan de bibliotheek. In de tijd die de klant nodig heeft om de voorbeeldschema’s te controleren hoef je dus niet stil te zitten. Je kunt de variabele (datavelden) al verwerken in je bibliotheek. Het goedkeuren of afkeuren van de voorbeeldschema’s heeft geen effect op het toevoegen van de variabelen aan je Typical Manager bibliotheek.
.
Omgaan met het volgende project
Zoals we al eerder stelden, is het beter om de denkwijze te veranderen: het proces van de ontwikkeling van een projectstandaard is belangrijker dan de standaard zelf. De hele standaard wordt gericht op dit ene project. In essentie gooi je de projectstandaard weg zodra het project is afgerond. In de praktijk gebeurt dat niet. De klant gunt je het volgende project, waardoor de projectfases opnieuw doorlopen worden. In de pre-engineeringsfase ontdek je echter dat een deel van de typicals herbruikbaar zijn. Let op: niet kopieerbaar, maar herbruikbaar. Dit betekent dat je bij dit nieuwe project minder tijd hoeft te besteden aan de projectfase standaardisatie. De herbruikbare typicals worden aangepast voor het nieuwe project en vormen de nieuwe projectstandaard. Hier zit de echte tijdwinst. De aanpassingen nemen aanzienlijk minder tijd in beslag dan het ontwikkelen van nieuwe typicals. Hoe meer projecten je voor deze klant mag doen, hoe efficiënter de werkwijze wordt. Het is echter belangrijk om te beseffen dat dit niet betekent dat er vanzelf een bedrijfsstandaard ontstaat. Deze gedachte kun je loslaten, want een standaard die je steeds aanpast, is geen geborgde bedrijfsstandaard.
.
Meer tijd voor de engineer én de klant
Een ander voordeel van de projectfase standaardiseren is de voorspelbaarheid en de extra tijd die men wint in een project. De discussies met klanten over incomplete data wordt steeds groter. Engineers willen bij de start van een project de data al zo compleet mogelijk hebben. De klant en de toeleveranciers zijn vaak nog in gesprek over het ontwerp van de fabriek, terwijl de opdracht voor detailengineering al is gegeven. Voor de engineer voelt iedere nieuwe versie van de P&ID of taglijst als een wijziging, terwijl dit voor de klant voelt als het aanvullen van ontbrekende informatie. Dit fenomeen ontstaat door het kopiëren en plakken van voorgaande projecten. Vanwege de projectdruk zullen engineers direct starten met het kopieer- en plakken waardoor er al snel resultaat is. Maar vanwege de ontbrekende informatie worden engineers gedwongen aannames te doen om door te kunnen met hun werk. Als de klant vervolgens met nieuwe informatie komt en de aannames niet blijken te kloppen, kan een deel van het werk opnieuw worden gedaan. Het positieve aan de projectfase standaardiseren is dat dit fenomeen kan worden afgevangen. Zodra het project begint, kan de engineer zich richten op de objecten die vijf keer of meer voorkomen. Van ieder object wordt een voorbeeldschema gemaakt die ter goedkeuring aan de klant wordt voorgedragen. Wetende dat in de volgende projectstappen wordt geautomatiseerd en gegenereerd, hebben wijzigingen in de data in deze fase weinig tot geen effect. De klant heeft in deze fase misschien niet alle antwoorden op de ontbrekende informatie, maar kan zeker een mening vormen over de vormgeving van de typicals. Na goedkeuring van de klant gaat de engineer in de fase automatiseren aan de slag met het variabel maken van de typicals. Ook in deze stap heeft een wijziging in de data minimaal effect. Pas in de fase daarna, projectverwerking, waarin de engineer de projectdata importeert en de objecten configureert, gaat men weer in gesprek over de ontbrekende data. Omdat we nu twee projectfases verder zijn, heeft de klant voldoende tijd gehad om de ontbrekende data definitief te maken. Voor veel engineers voelt dit als verloren tijd omdat er nog geen complete schema’s in Eplan staan. Maar zodra op de genereerknop wordt gedrukt, heb je ruim 80% van je tekeningen gereed. Je hoeft geen werk opnieuw te doen, de klant weet exact wat hij krijgt omdat de typicals al zijn goedgekeurd én er is voldoende tijd om de objecten die minder dan vijf keer voorkomen te verwerken in de schema’s.
Benieuwd hoe dit voor je eigen proces werkt? Laten we een keer vrijblijvend hierover in gesprek gaan. Yellax ondersteund klanten bij het optimaliseren van hun eigen ontwerpproces. Daarnaast kunnen we ook projecten gezamenlijk uitvoeren. Maak gebruik van de ontwerpstraat van Yellax waarin we dit proces volledig hebben geïntegreerd.