Cees Michielsen - Trainer
Met meer dan 30 jaar ervaring bij enkele van de topnamen in de Nederlandse hightechindustrie, reflecteert Cees Michielsen op zijn geleerde lessen en hoe hij deze kennis probeert door te geven als instructeur van de training “System requirements engineering improvement” bij High Tech Institute.
Het was 1986 toen Cees Michielsen zijn start maakte in de wereld van hightech. Hij kwam destijds bij het Philips EMT-team, dat later Assembleon en uiteindelijk Kulicke & Soffa zou worden, om te helpen bij het bouwen van SMD-plaatsingsrobots. “In die tijd waren onze belangrijkste klanten autobedrijven zoals Ford, GM en Chrysler. We waren volledig zelfstandig en hadden alle essentiële disciplines en competenties in onze business unit”, herinnert Michielsen zich.
Toen hij in het team kwam, lag Michielsens focus op technische informatica, maar al vroeg nam het traject van zijn carrière een omweg. “Het was daar bij Philips dat ik me begon te ontwikkelen tot een systeemdenker en echt loskwam van mijn eigen softwarediscipline”, zegt Michielsen. “Achteraf gezien kan ik zeggen dat dat voor mij de beste start was in mijn carrière; de ervaring gaf me een enorme voorsprong en is de reden waarom ik er vandaag de dag nog steeds zo gepassioneerd over ben.”
“Het was daar bij Philips dat ik me begon te ontwikkelen tot een systeemdenker, en echt loskwam van mijn eigen softwarediscipline”, zegt Cees Michielsen.
Nu, na meer dan drie decennia in de industrie, brengt Michielsen zijn dagen door als requirements engineer bij ASML, maar ook als instructeur aan het High Tech Institute waar hij zijn kennis, en de vele lessen die hij heeft geleerd, deelt met de volgende generatie ingenieurs in de “Systems requirements engineering improvement” training.
Abstractie lagen
Bij het opstellen van systeemvereisten, vooral op systeemniveau, is scoping van het probleem de naam van het spel. Het gaat erom precies te bepalen welke functies het systeem moet hebben, de specifieke eigenschappen die aan die functies zijn gekoppeld en het nauwkeurig definiëren van het probleem dat moet worden opgelost. “Als we het bijvoorbeeld hebben over het projecteren van patronen op wafers, kun je je voorstellen dat dat de hoofdfunctie van het systeem is en dat meerdere bedrijven hetzelfde doen. Maar het zijn de eigenschappen van deze functie die één groep onderscheiden van zijn concurrenten – de nauwkeurigheid, opbrengst, snelheid en betrouwbaarheid,” benadrukt Michielsen.
Voor Michielsen maken deze eigenschappen het verschil in de wereld en is requirements engineering de kunst van het identificeren van de juiste functies en het kwantificeren van hun eigenschappen om het probleem te definiëren. “Als het probleem eenmaal goed gedefinieerd is, is het veel eenvoudiger om de oplossing te vinden”, zegt Michielsen. “Maar je zult de implementatie van je oplossing niet meteen vinden, dus je zult waarschijnlijk een aantal abstractie- of decompositielagen doorlopen.”
Cascade
Tijdens zijn trainingssessie legt Michielsen uit dat in een systeem de hoogste abstractielaag het niveau is met de meest algemene eisen, dat wil zeggen dat het systeem snel moet zijn of een bepaald uiterlijk moet hebben. Maar naarmate je dieper in het systeem komt, wordt het veel gedetailleerder. Plotseling verwijzen de lagen naar verschillende onderwerpen of gebruiken ze verschillende talen om de vereisten uit te drukken, wat een beetje lastig kan zijn voor ingenieurs om de informatie vloeiend te houden.
“Dat is het echte doel van requirements engineering, het vinden van verschillende manieren om ervoor te zorgen dat de gegevens van boven naar beneden en van de behoeften van belanghebbenden naar de implementatie blijven cascaderen, allemaal zonder informatie te verliezen,” suggereert Michielsen. “Ik denk dat als ik de uitdaging voor requirements engineering zou moeten samenvatten, ik zou zeggen dat die vooral ligt in het cascaderen van informatie door elke abstractie- of decompositielaag heen.”
Kwantificering
Volgens Michielsen is een zeer belangrijk onderdeel van de methode het vinden van de complete set eisen voor een systeem. “De vraag wordt al snel ‘wanneer is de set compleet'”, stelt hij. “De beste aanpak die we tot nu toe hebben gezien, kan worden uitgedrukt met behulp van een vergelijking, die we delen in de training. Hiermee kunnen we een systeem volledig definiëren aan de hand van zijn functies, eigenschappen en beperkingen, en het kan worden toegepast vanaf de hoogste niveaus tot aan de componenten en onderdelen op de laagste punten.” Hij vervolgt: “Door deze criteria te specificeren en te kwantificeren, kunnen de echte vereisten worden afgeleid. Dit is een van de belangrijkste stappen van de training, leren hoe je een waarde kunt toekennen aan elk van de eigenschappen van het systeem.”
“Zodra de doelen zijn gedefinieerd, kunnen we oplossingen – ontwerpopties – identificeren op basis van de veronderstelde mogelijkheden van subsystemen. Dit is waar creativiteit het productontwikkelingsproces leidt, omdat er veel verschillende opties worden overwogen om het probleem op te lossen,” geeft Michielsen aan. “Zolang we de aannames die we tijdens dat creatieve ontwerpproces maken documenteren, kunnen we deze aannames later vertalen in vereisten voor de subsystemen op een lager niveau die we nodig hebben in de oplossing.”
Rechtvaardiging
Voor Michielsen is dit een van de krachtigste elementen van de hele methode. De mogelijkheid om de volledige logische lijn te zien van een gekwantificeerde systeemdefinitie naar de ontwerpbeslissingen en uiteindelijk naar de specifieke implementatie van een oplossing. Dat wil zeggen, als ingenieurs in staat zijn om coherentie te behouden tussen systeemvereisten, systeemontwerp en systeembeslissingen – een cruciale factor.
“Zolang de informatie goed wordt gevoed, kunnen we vereisten voor de volgende laag afleiden en de cascade voortzetten. Op die manier kunnen we ervoor zorgen dat welke vereisten we ook krijgen op het laagste componentniveau, door onze methode en onze traceerbaarheid kunnen we precies komen tot de rechtvaardiging van elke vereiste en elke beslissing die in elke laag wordt genomen. Dat is de hele essentie van de methode.”
“Als trainer wil ik helpen vertrouwen in het proces te wekken”, zegt Michielsen.
Na meer dan 30 jaar in de sector, wat wil je het liefst delen in je trainingen?
“Als trainer wil ik helpen vertrouwen in het proces te wekken. Het volgen van de methode is één manier om dat te bereiken, omdat de studenten het gevoel krijgen dat het systeem compleet, consistent en correct kan zijn – in termen van specificaties. Dat kan echt helpen om het minder ontmoedigend te laten aanvoelen. Als je eenmaal over die horde heen bent, kunnen de studenten vrijwel meteen beginnen met het bepalen van de belangrijkste functies van het systeem en beslissen welke eigenschappen gerelateerd zijn en welke beperkingen op dat niveau van toepassing zijn. Door deze aspecten te kwantificeren, zeggen ze niet alleen dat het systeem betrouwbaar moet zijn, ze zeggen expliciet hoe betrouwbaar het systeem moet zijn.”
Geleerde lessen
Met zijn meer dan 30 jaar in procesarchitectuur heeft Michielsen verschillende praktische methoden ontwikkeld om de informatie van laag naar laag te laten stromen. Zijn succes op dit gebied opende de deur voor hem om samen te werken met Nederlandse en Europese topbedrijven, zoals Prorail, Eurocontrol, Punch Powertrain en Vanderlande – en diverse andere bedrijven, om te helpen bij het opzetten en implementeren van processen voor hun eigen requirements engineering programma’s. “Wat ik ontdekte was dat er enorme verschillen zijn tussen elk bedrijf, vooral in de implementatie,” herinnert Michielsen zich. “Toen ik voor DAF ging werken, hebben we in drie jaar tijd een compleet requirements engineering proces opgezet. We konden honderden engineers succesvol trainen en de methode wierp zijn vruchten af.”
'It certainly was a big learning experience for me, and it came with a lot of tough lessons learned.'
Gezien het succes van het DAF-project belde Siemens om Michielsen naar Duitsland te lokken om te helpen dezelfde aanpak voor Daimler op te zetten. “Het was voor mij een enorme stap om uitgenodigd te worden om het systeem te implementeren, maar het werd al snel duidelijk dat de aanpak die we bij DAF hadden ontwikkeld niet overdraagbaar was naar Daimler”, roept Michielsen. “Daimler was gewoon op een heel andere manier georganiseerd, met verantwoordelijkheden die over afdelingen en mensen verdeeld waren op een manier die een succesvolle uitvoering echt moeilijk maakte. Het onvermogen om daar iets van de grond te krijgen was teleurstellend,” zegt hij en vervolgt: “Het was zeker een grote leerervaring voor me en ik heb er veel harde lessen geleerd.”
Zijn deze geleerde lessen je drijfveer in dit domein?
“Gedeeltelijk, ja. Ik heb een enorme passie voor dit hele proces. Ik wil helpen om de productmogelijkheden en de productiefaciliteiten te verbeteren, vooral in het gebied waar ik woon en werk. Ik wil in die zin een impact hebben op de industrie omdat we zoveel geleerd hebben en ik wil deze informatie verspreiden,” benadrukt Michielsen. “Het is niet allemaal mijn werk, het zijn alle bedrijven waar ik voor heb gewerkt en al mijn ervaringen. Ik ben ontzettend dankbaar dat ik dat heb kunnen doen en ik wil die kennis graag verspreiden om ervoor te zorgen dat het hele ecosysteem ervan kan profiteren en wij ervan kunnen groeien.”
Dit artikel is geschreven door Collin Arocho, tech redacteur van Bits&Chips.
Recommendation by former participants
By the end of the training participants are asked to fill out an evaluation form. To the question: 'Would you recommend this training to others?' they responded with a 8.6 out of 10.
High Tech Institute organiseert twee keer per jaar de training 'System requirements engineering improvement'.
Blijf op de hoogte
Ontvang onze maandelijkse updates
