Pre-engineering in de Industriële Automatisering van onschatbare waarde
17 september 2024
In de wereld van industriële automatisering is de rol van pre-engineering binnen het engineeringsdomein van onschatbare waarde. Toch wordt het niet, of nauwelijks, bewust uitgevoerd. Met oog op het productiever maken van het ontwerpproces, delen we graag onze kennis en ervaring op het gebied van pre-engineering. Voor onszelf heeft het zoveel opgeleverd dat we vandaag de dag geen project meer uitvoeren zonder een pre-engineeringsfase.
Zoals we in de vorige blog hebben uitgelegd, bestaat het proces van electrical engineering uit zeven stappen: de aanvraag, pre-engineering, projectstandaardisatie, automatiseren, projectverwerking, nabewerking en controleren. Organisaties die dit proces scherp op hun netvlies hebben staan en er ook naar handelen, maken het verschil in steeds grotere en complexere projecten, in een wereld waar het electrical engineeringsras langzaam aan het uitdunnen is. Meer doen met minder mensen kan alleen als het proces effectief wordt doorlopen en dat betekent beginnen met de juiste inzichten: aldus een pre-engineeringsfase.
.
De uitdaging
Aan het begin van een project komen we de grote uitdaging tegen dat informatie niet alleen onvolledig is, maar ook in verschillende documenten én vaak via verschillende wegen wordt aangeleverd: de meeste bestanden via e-mail, een wat groter bestand via WeTransfer en dan de laatste gegevens nog snel even via de telefoon, in een korte Teams Meeting en projectkick-off. En dan maar hopen dat alles op elkaar aansluit en er niet ergens een nieuwere versie over het hoofd wordt gezien.
We zien bijna zonder uitzondering dat documenten zoals de P&ID en de verbruikers- en instrumentatielijst tegenstrijdigheden bevatten. Een P&ID met 70 objecten terwijl de instrumentatieverbruikerslijst er 73 bevat. Welk document is dan leidend? En wat te denken van de ontbrekende gegevens bij de start van een project? Enig idee wat de impact daarvan is op de uren? En is de klant zich daar bewust van? Daarnaast is het tijdens een project altijd een strijd om binnen de uren te blijven en hoe kom je uit de discussie met de klant over meerwerk? Want wanneer is het meerwerk?
Om een project succesvol te starten, zou je dus structuur in de chaos moeten krijgen. Dat is precies wat je met pre-engineering wilt bereiken. Zonder deze structuur is het bijna onmogelijk om effectief te werken en we hebben vaak niet eens door hoeveel impact slechte data heeft op de productiviteit van het ontwerpproces. Hoewel 80% complete data veel lijkt, is het project hiermee maar 45% effectief. Dit betekent dat de uren van engineers meer dan verdubbelen door het verzamelen van de juiste data: overleggen, afstemmen, wachten, uitzoeken en zelfs werk opnieuw doen omdat er aannames gedaan zijn om verder te kunnen met het project. Kleine spoiler alert: voor de klant is het maar een fractie van de tijd om deze data compleet te krijgen, in vergelijking met de tijd van een electrical engineer of projectleider, alleen zijn ze zich daar niet bewust van.
.
De uitvoering
Het succes van de pre-engineeringfase hangt sterk af van de manier waarop deze wordt uitgevoerd. De sleutel tot een succesvolle pre-engineeringfase is het creëren van een “single source of truth”. Dit betekent werken in één bron. Alle gegevens vanuit alle bronnen (e-mail, WeTransfer, vergaderingen enzovoort) worden op één plek verzameld. Hierdoor wordt het inzichtelijk welke gegevens er ontbreken en wat de tegenstrijdigheden tussen de verschillende documenten zijn. Vanaf dat moment is de “single source of truth” de enige bron voor communicatie binnen het project. Gegevens, wijzigingen of andere data worden uitsluitend in dit document vastgelegd. Het bijhouden van een goed versiebeheer is hierbij cruciaal om consistentie en nauwkeurigheid te waarborgen.
Vanuit electrical-oogpunt is het belangrijk om te beoordelen wat er al beschikbaar is en wat nog moet worden gemaakt. Dit omvat onder andere het bekijken van voorgaande projecten om te zien of er macro’s zijn die kunnen worden hergebruikt. Let hierbij op dat het gaat om hergebruiken van macro’s en niet het simpelweg kopiëren en plakken ervan. Zoals iedereen wel weet, heeft het kopiëren en plakken van projecten het risico dat fouten uit het vorige project ook mee gekopieerd worden. De engineer pakt het project waar hij of zij bekend mee is. Daarin zijn vaak niet alle revisies vanuit de paneelbouw meegenomen. Veel fouten worden vaak opgelost in de paneelbouw en niet gedocumenteerd. Het vorige project lijkt wellicht wel op het nieuwe project, maar het is niet een-op-een hetzelfde. Er kunnen objecten voorkomen die in het nieuwe project helemaal niet van toepassing zijn. En het grootste nadeel is dat men er pas in de paneelbouw achter komt dat het niet goed is. Of nog erger, bij de inbedrijfstelling. Het lijkt voor de engineer een snelle werkmethode, maar kopiëren van projecten zorgt er in essentie voor dat je al met 1-0 achterstand begint.
Begrijp ons niet verkeerd, we zeggen niet dat je niks meer moet doen met de projecten die je al gemaakt hebt. Sterker nog, er zit namelijk hele waardevolle informatie in die het nieuwe project onwijs kan versnellen. Leg de focus op het hergebruiken van slimme macro’s in plaats van het kopiëren van complete projectdelen. In de stap automatiseren ga je deze slimme macro’s inzetten om een deel van het nieuwe project te genereren.
Naast de projecten die je al hebt gedaan, is het van belang om te bepalen of de macro’s die de klant aanlevert voldoende dekking geven voor het project of dat er nog nieuwe macro’s moeten worden gemaakt. Klantstandaarden worden steeds strenger en belangrijker. Sommige klanten staan er nog open voor om geadviseerd te worden en geven je de kans om de macro te verbeteren. In de markt horen we echter steeds vaker dat klanten zich strikt aan eigen standaarden vasthouden. Het is dus noodzakelijk dat je een modus vindt waarin je gemakkelijk kunt omgaan met verschillende klantstandaarden.
Als de macro’s bekend zijn, bepaal je welk deel van de macro’s geautomatiseerd kan worden en welk deel handmatig verwerkt wordt. De stelregel hierbij is dat alles wat vijf keer of meer voorkomt, rendabel is om te automatiseren. Maar vijf keer dus. Dat betekent dat de tooling van tegenwoordig al zo goed is, dat we steeds grotere mate van automatisering kunnen toepassen in projecten. Hoe meer we kunnen automatiseren, des te minder vervelende, herhalende taken de engineers hoeven uit te voeren. In positieve zin kun je stellen dat we onze schaarse capaciteit kunnen inzetten waar we ze het hardst nodig hebben en dat is niet in de herhalende taken. Engineers kunnen zich meer en meer richten op de uitdagende taken wat ervoor zorgt dat hij of zij werk doet dat leuk is.
Een ander belangrijk aspect van de pre-engineeringfase is het vooraf inzichtelijk maken van de kosten van wijzigingen in de data. Het is noodzakelijk om in kaart te brengen hoe lang het duurt om één object toe te voegen of te verwijderen in het tekenpakket. “Even één objectje” toevoegen is zo makkelijk gezegd tijdens een project, alleen de impact ervan is vaak groter dan we beseffen. Of wat te denken van het wijzigen van een motorvermogen: Past de grotere bouwvorm wel in het schakelpaneel? Is het verschil in warmteontwikkeling niet te groot? Wat is de impact op kabeldiktes? Een ogenschijnlijk kleine wijziging kan veel invloed hebben. Een engineer kan gemakkelijk 8 uur bezig zijn om het object verwerkt te krijgen. De betreffende fase waarin het project zich bevindt heeft ook invloed op de impact van een wijziging. Naarmate het project vordert in de fases, wordt de impact steeds groter. Een wijziging van bijvoorbeeld een macro is in de projectstandaardisatiefase nog te overzien. Moet je dezelfde wijziging verwerken als het project al gegenereerd en na-bewerkt is, dan is het een heel ander verhaal. Deze inzichten geven de klant een duidelijk beeld van de urgentie van bepaalde gegevens en besluiten in specifieke fases van het project.
Aan alle punten uit de analyse kun je een tijdsindicatie hangen:
- Verwerken van de klantstandaard
- Maken van de ontbrekende macro’s
- Het automatiseren per object
- Handmatig verwerken van een tag
- Controle slagen
- Enzovoort
Koppel je deze tijdseenheden ook nog eens aan de verschillende projectfases, dan heb je een fantastisch overzicht dat je kunt presenteren aan de klant. Dit geeft niet alleen een hele gedetailleerde ureninschatting, maar het geeft tevens een verantwoording van de uren en een startpunt om met de klant in discussie te gaan over mogelijke risico’s en kansen. De risico’s die uit het onderzoek komen, zijn vaak te herleiden naar ontbrekende data ten opzichte van de ingeschatte uren. Kansen zijn te vinden in werkzaamheden die te verdelen zijn tussen de verschillende partijen waardoor de productiviteit van het proces omhoog gaat. Een voorbeeld hiervan is het maken van de macro’s die nog niet aanwezig zijn. Er gaat namelijk tijd zitten in het maken van de macro’s, maar ook het controleren ervan door de klant én het verwerken van feedback. Misschien is het voor jullie beiden een win-win als de klant deze macro’s zelf maakt en jullie hiermee tijd en geld besparen.
.
Het resultaat
Zoals we al stelden, is een goed uitgevoerde pre-engineeringsfase van onschatbare waarde. Het biedt ongelooflijk veel inzicht in de benodigde ontwerpuren, de kwaliteit van de data en daarmee de productiviteit van je ontwerpproces. Het geeft inzicht in de kansen en risico’s van het ontwerpproces, en als je dit dan ook nog bespreekt met de klant, zul je ervaren dat zij zich ervan bewust worden welke onnodige extra werkzaamheden ze aan jullie vragen. Of vanuit een positief oogpunt: hoe een samenwerking tussen twee partijen veel meer waarde oplevert dan een standaard klant-leveranciersrelatie. We hebben zelf het voorbeeld meegemaakt waarbij de ureninschatting uitkwam op 440 uur (electrical) engineering. De projectgegevens waren zo’n 85% compleet. Na een gedegen pre-engineeringsfase hebben we de klant meegenomen in de onderzoeksresultaten. De klant was zich niet bewust van het effect van de aangeleverde data en na dit inzicht wisten zij hun eigen data te verbeteren. Dit resulteerde in een urenvermindering van maar liefst 140 uur. Om de juiste datakwaliteit te halen had de klant slechts 4 uur tijd nodig! Over een geweldige samenwerking gesproken!
De waarde van de pre-engineering was tot voor kort een discussiepunt binnen en buiten onze organisatie. Projectleiders ervaarden geen pijn of verspilling, want zij stuurden alle documenten ‘gewoon’ door naar de engineers. Of zij wel eens vragen terugkregen? Van de ene engineer meer dan de andere. Of er in de uitvoering wel eens een mismatch was tussen de gevraagde scope en de geleverde scope? Daar moesten ze ongemakkelijk bij lachen. De kern van pre-engineering is het signaleren van oneffenheden in een vroeg stadium en hier vroegtijdig mee aan de slag gaan. Juist de stap pre-engineering zorgt voor het halen van milestones. Het heeft ons én onze klanten inzichten en kennis gegeven die vele malen meer waard zijn dan de tijdwinst die we samen weten te boeken in één project.
Bij het uitvoeren van een project wordt de pre-engineeringsfase altijd uitgevoerd. Zelfs als bedrijven niet bewust een pre-engineeringsfase in het proces hebben, wordt veel van het werk onbewust uitgevoerd. Zelf weten we binnen een week dit werk voor onze klanten uit te voeren en ze volledig inzicht te geven in hun eigen project. De extra toegevoegde waarde die we met Yellax ProjectResultaat weten te behalen in deze fase is de unieke relatie tussen datakwaliteit en benodigde ontwerpuren. Stel je eens voor hoe je project verloopt als je start met deze informatie. Onze missie: het direct versterken van de ontwerpproductiviteit voor onze relaties.