Hoe hoger in de organisatie, hoe meer je bezig bent om het management rustig te houden

‘Hoe hoger in de organisatie, hoe meer je bezig bent om het management rustig te houden’

Ben Pronk verwierf faam als systeemarchitect bij verschillende Philips-divisies. Een jaar geleden besloot hij zijn carrière af te ronden bij een startup in de robotchirurgie. In de aanloop naar zijn keynote op de Bits&Chips System Architecting Conference vragen we hem naar zijn ervaringen.

René Raaijmakers

In de herfst van 2019 nemen Anupam Nayak en Maarten Steinbuch contact op met Ben Pronk. Met hun startup Eindhoven Medical Robotics werken ze aan apparaten die bij medische ingrepen zelfstandig in bot kunnen boren, zagen en frezen. Daarmee beloven ze een game change in de chirurgie en hebben ze de ambitie om in 2028 marktleider te zijn in robots voor de operatiekamer. Pronk (1959), een systeemarchitect die naam maakte in talloze Philips-divisies en -spinoffs, ziet zijn kans schoon en besluit zich nog één keer te bewijzen.

Een tijdje later zoekt Pronk een stoel en een bureau uit tussen een ploeg jonkies en enkele ervaren rotten. ‘Ik ben de zestig gepasseerd en wil nog een keer iets leuks doen. De medische wereld en de applicatie zijn heel interessant. Wat me voornamelijk aansprak, was de kleinschaligheid. De organisaties waarin ik heb gewerkt, bestonden uit duizenden mensen. Bij Philips-divisies en later Signify heb je voor elk gebied wel een specialist bij de hand of in elk geval iemand die het kan regelen. Hier is weinig tot niets geregeld. Voor een thermische simulatie moet ik de deur uit en ik bestel mijn pc zelf. Onze it-afdeling is Bol.com. Ook programmeer ik weer zelf’, zegt hij, om er lachend aan toe te voegen: ‘Als dat moet.’

Systeem denken

In zijn ruim dertigjarige loopbaan als systeemarchitect zag Pronk het vak evolueren. In de jaren tachtig was een systeemarchitect vaak domeinspecialist. Iemand met expertise op de dominante technologie, zoals röntgen of mri in de medische diagnostiek. Zo iemand wist alles van röntgen. Maar met de oprukkende digitalisering werd alles computergestuurd en raakte meer verweven. De grenzen van vakgebieden vervaagden. Mechanica, elektronica, mechatronica, optica, alles raakte verweven met software. Waar het kon, verschoof de elektronica van analoog naar digitaal en in het laatste decennium gingen producten ook aan het netwerk en de cloud.

De systeemarchitect werd daardoor steeds minder een specialist op de dominante discipline. Pronk: ‘Maar heel weinig producten zijn echt monodisciplinair mechanisch. Je kunt het zo gek niet bedenken of er moet een app bij. Systeemdenken is dan bijna noodzaak. Natuurlijk zijn er nog architecten die puur aan basistechnieken werken zoals aan optica voor lenzen, maar als je naar de totale r&d-groep kijkt, dan zijn dat nichespecialisten. Zelfs kleine bedrijven kunnen niets meer ontwikkelen zonder netwerken en wifi.’

Hoe zie je de rol en taken van de systeemarchitect?

‘Voor mij zijn er twee elementen: de multidisciplinaire verdeling in de r&d en de bredere blik. De systeemarchitect moet overzicht houden, alle disciplines met elkaar verbinden en verdelen over het systeem. Wat doe je waar en hoe doe je dat optimaal? Wat doe je in software? Wat in mechatronica? Niet alles oplossen in mechanica als je het in elektronica kan, niet alles in elektronica als het ook in software kan. Hoe zorg je voor samenhang?’

‘Daarnaast moet de systeemarchitect breder kijken, niet alleen naar r&d. Hij moet afstemmen met marketeers en de mensen die gaan over logistiek en fabricage. Want je kunt wel een prachtig design maken, maar dat moet ook passen op je logistieke flow en de fabricage.’

Met het uitdijen van opties en technologieën moeten systeemarchitecten steeds meer overzien. Tegelijkertijd vragen r&d-organisaties aankomende technici om eerder in hun carrière op systeemniveau mee te denken. Dat wringt, want het opdoen van ervaring is essentieel voor hun groei. Pronk ziet dat organisaties er meer aandacht aan besteden in hun opleidingen en cursusaanbod. ‘Maar daar is inderdaad nog groei nodig.’

Het leuke, zegt hij, is dat de talenten vanzelf opvallen. ‘Je merkt het vanzelf. Ze zijn nieuwsgierig en hebben van nature de neiging om rond te kijken. Je haalt ze er vrij snel uit.’

Wat was bij medische systemen de grote uitdaging voor systeemarchitecten?

‘Optimaliseren. Om met minimale ontwikkeling maximaal resultaat te bereiken. Diagnostische apparaten zijn grote machines en hebben een bijna onbe-

Ben Pronk: ‘Je steekt vaak heel veel geld en moeite in een toekomst die niet komt.’

perkte vraag naar nieuwe functionaliteit en uitbreidingen. Je moet altijd de technologische ontwikkelingen bijhouden: nieuwe generaties processoren, nieuwe programmeertalen. Allemaal grote stappen.’

Ontwikkeldwangbuis

Bij Philips Medical startte in de jaren negentig het Fusion-project met de ambitieuze doelstelling om met één platform het hele röntgenportfolio af te dekken. Het delen van besturingssystemen en het hergebruiken van softwarecomponenten moesten deze omvangrijke operatie rechtvaardigden, maar eind jaren negentig liep de inspanning averij op.

‘Een van de oplossingen om de behoefte aan ontwikkelcapaciteit te verminderen, is software delen en met platformen te werken. Maar dat is complex. Daar kraakte en steunde het Fusionproject, want we probeerden het hele x-ray-portfolio af te dekken. Het is op het einde teruggebracht tot cardiovasculaire interventie – de Allura-systemen die ingrepen als dotteren mogelijk maken.’

Pronk schetst de ratrace waar een r&d-organisatie in belandt als er miljardenmarkten lonken en de vraag en technologische mogelijkheden alsmaar toenemen. Hij noemt het ‘de development-dwangbuis’. ‘Zo voelt het. Door de digitale explosie en de benodigde software is de ontwikkelvraag eigenlijk eindeloos. Als we bij Medical tien keer zoveel mensen hadden gehad of tien keer zo snel hadden kunnen ontwikkelen, dan hadden we het allemaal kwijt gekund. In de software zijn er golven en trends geweest om met deze groei om te gaan. Platformen en re-use zijn daar voorbeelden van. Het is een tredmolen. Je moet doorrennen, voldoende functionaliteit leveren en tegelijkertijd je systeem technologisch up-to-date houden. Als je dat niet doet, blijf je leunen op je oude systeem en dan is er op een gegeven moment maar één oplossing: bijna helemaal opnieuw beginnen. Ook dat is vaak een bijna dodelijke actie. Het Fusion-project was zo’n moment. We moesten een grote technologische stap maken en stikten er bijna in.’

Hoe zorgen systeemarchitecten ervoor dat ze een open blik op hun wereld houden?

‘Om heel eerlijk te zijn: op een gegeven moment moet je weggaan uit je organisatie. Systeemarchitecten lopen het risico dat ze na twintig jaar uitgroeien tot halfgod. Het reële risico van zo’n goeroestatus is dat mensen niet meer aan je twijfelen, al zeg je dat de aarde plat is. Bovendien belemmeren ze dan de doorgroei van anderen.’

Zelf stapte Pronk van de medische wereld over naar de halfgeleiderdivisie van Philips en later naar Signify, de afgesplitste Lighting-activiteit. Dit soort verhuizingen leveren voor systeemarchitecten nieuwe ervaringen op, maar vormen ook een grote hobbel. ‘Je mag dan de kneepjes van het vak kennen, maar de domeinkennis voor een totaal andere markt moet je van de grond af opbouwen.’

Voor de nieuwe omgeving betekent een dergelijke overstap ook een forse investering. ‘Ze trekken een hele dure kracht aan die een tijd niet actief is.’ Binnen multinationals als Philips is af en toe switchen policy. Pronk erkent weleens aftastende gesprekken met andere werkgevers te hebben gevoerd en daarbij kwam vooral dit punt uitputtend aan de orde. Dan werd de vraag op tafel gelegd: hoe lang duurt het voordat jij je salaris weer waard bent? Pronk: ‘Voor zeer complexe ontwikkelingen in een specialistische tak van sport kan het zomaar een of twee jaar duren voor je weer op niveau bent.’

Silver sponsor

Sponsors

Powered by

Partner

SYSARCH.NL #BCSA 24 SEPTEMBER 2020 • IGLUU • EINDHOVEN

PROGRAM

09:30

10:30 11:00

11:30

12:00

12:30 13:45

14:15

12:30 15:15

15:45

16:15

16:45

Keynote System Architecture in high-tech systems – is there any time left for system engineering? Ben Pronk, Eindhoven Medical Robotics

Break Cuyperstrap, treacherously simple Dries van Heusden, Associate Value Specialist

System architects’ challenges for state-of-the-art qualification tools in a customer-supplier co-development setting Kees Verbaan, NTS Digital transformation: the importance of a digital twin and model-based systems engineering in the development of a complex bridge system Ferdinand Cornelissen, Altran

Lunch Good architecture, a practical tool to guide the architect Robert Deckers, Atom Free IT

System engineering as a means to collaborate in consortia in the development of complex technology. Two case-studies: a multi-beam electron microscope and tunnel-automation André Nijholt & Remco Jager, Technolution

Break The use of system-engineering principles in the procurement of rolling stock – it will never be perfect, but it does not need to be Louis Michielsen, NS The challenge to define architectures and interfacing standards for a European electric mobility service infrastructure Maarten Bonnema & Roberto Reyes García, University of Twente

Break

Keynote Why model-based systems engineering is becoming a necessity, rather than a luxury Jon Holt, INCOSE UK

Hoe was dat voor jou toen je naar halfgeleiders overstapte?

‘Chips voor de consumentenmarkt was echt een andere wereld dan medische apparaten. Bij Medical verkochten we driehonderd dure systemen per jaar. Bij Semiconductors verscheepten we in sommige maanden tien miljoen onechip-tv’s. In een ziekenhuis kun je niet met slechte spullen aankomen. Het moet de juiste functionaliteit en betrouwbaarheid hebben. De levertijd is belangrijk, maar als het een half jaartje later is, dan ging je niet failliet. Pas als je rotzooi in de markt zette, had je een echt probleem. Bij Medical was de volgorde van prioriteit: kwaliteit, functionaliteit, kosten, levertijd.’

‘In de semiconductormarkt is de werkelijkheid helemaal anders. Je moet simpelweg op tijd zijn om klanten in staat te stellen met kerst te leveren. Anders komt je chip niet in hun tv-design en dan ben je een jaar verder. De chipfabriek dendert door, de kosten zijn gigantisch. Dat betekent dat time to market op de eerste plaats komt, daarna pas functionaliteit en kwaliteit. Echt een totaal andere mentaliteit.’

In de tijd dat jij bij Philips Semiconductors zat, verschoof een groot deel van de softwareontwikkeling naar India.

‘Voor ons ging het vooral om de beschikbaarheid van mensen. Die konden we rond de millenniumwisseling niet meer krijgen. Op de korte termijn was dat ook goedkoper, maar bij salarisstijgingen van 10 procent per jaar in Azië zat daar op den duur de winst niet.’

Bij Semiconductors en later NXP was de r&d al wereldwijd over verschillende sites verspreid, met softwareontwikkeling in Sunnyvale, Californië, chipintegratie in Hamburg en systemen en software in Southampton. Daar kwam kort na 2000 ook software in Bangelore bij. ‘Dit soort verspreidingen geeft onvermijdelijk meer overhead en gaat ten koste van de efficiency. Op één plaats alles doen blijft het meest efficiënt. Maar tegelijk moesten we in India een organisatie met ervaring opbouwen. Daardoor is het in het begin bij een paar projecten helemaal uit de klauwen gelopen. Dat ligt niet aan India of Azië, maar ze moeten daar ook domeinervaring opbouwen. Vaak wordt dat onderschat. In het begin was ook het verloop van de mensen in Bangalore heel groot. Dat maakte het opbouwen nog moeilijker. Maar na verloop van tijd zijn daar prima opererende afdelingen ontstaan.’

Overbodig werk

Het kan niet anders of een systeemarchitect met dertig jaar ervaring heeft missers begaan. ‘Ja, ik heb natuurlijk heel wat over het hoofd gezien’, reageert Pronk op de vraag om op zijn grootste fouten te reflecteren. Hij zegt in de loop der jaren vooral meer oog te hebben gekregen voor niet-technische aspecten. ‘Daarmee bedoel ik dat je organisatie fit moet zijn om de ontwikkeling uit te voeren. Je kunt wel een architectuur maken, maar je moet ook de mensen hebben om de ontwikkeling en productie uit te voeren.’

Ook veroorzaak je problemen als je architectuur haaks staat op de organisatie. ‘Als je bijvoorbeeld functionaliteit samenvoegt of vervangt die daarvoor door twee afdelingen werd gebouwd, kun je er zeker van zijn dat de conflicten en strijd groot zullen zijn. De invoering van een architectuur kan echter niet zonder aanpassingen in de organisatie. Dan is het logisch om het werk anders op te delen. Als je de bestaande organisatiestructuur moet veranderen of erger: als afdelingen overbodig worden, dan is er werk aan de winkel.’ ‘Politieke verhalen zijn uit den boze’, zegt Pronk over gesprekken met het topmanagement.

Ervaring leerde hem meer down to earth beslissingen te nemen. Zo had Pronk in het verleden sterk de neiging om platformen zeer toekomstbestendig te maken door rekening te houden met veel hergebruik. ‘Dat betekende veel abstractielagen. In de loop der jaren ben ik gaan inzien dat je te snel te veel extendablity inbouwt. Van die extra voorzieningen gebruik je 90 procent nooit meer. Maar wat veel vervelender is: ik kwam er altijd achter dat juist de extensies die ik later nodig had, er niet in zaten. Klant of productmanagers komen altijd met vragen die je niet hebt voorzien. Ik wil maar zeggen: ook de systeemarchitect heeft geen glazen bol. Je steekt vaak heel veel geld en moeite in een toekomst die niet komt.’ Over voorbeelden van beslissingen die juist verrassend goed hebben uitgepakt, hoeft Pronk minder lang na te denken. ‘Van overstappen op standaard componenten heb ik eigenlijk nooit spijt gehad. In de tijd van het Fusion-project bij Philips Medical hebben we bijvoorbeeld dedicated besturingssystemen vervangen door Windows. Bij Semiconductors zijn we voor tv overgegaan naar Linux.’

Die keuzes waren destijds helemaal niet voor de hand liggend. ‘Zowel bij Medical als Semiconductors hebben we intern forse tegenwind gehad. Er is altijd aarzeling. Zijn Windows en Linux wel geschikt? Ze zouden te groot, te zwaar of niet stabiel genoeg zijn. Maar het betaalde zich uit. Dat doet het bijna altijd’, zegt

hij. Met enige zelfspot: ‘Als je eenmaal je eigen spullen stabiel hebt gekregen.’

Het is dus zaak onderdelen van de plank te gebruiken waar het maar enigszins kan. ‘Zelfs als standaard componenten op het eerste gezicht niet helemaal fit for purpose lijken. Het levert vaak veel voordeel op. Ik heb daar nooit spijt van gehad..’

Meer gezeur

Ooit zei een collega tegen hem: ‘Ben, ik maak me pas zorgen als jij je zorgen begint te maken.’ Hij zegt het niet met zoveel woorden, maar Pronk beschouwt de opmerking duidelijk als een compliment. Het zegt veel over de positie en verantwoordelijkheid van de personen die binnen de organisatie op het hoogste niveau het technische overzicht houden.

Het nadeel is dat de toparchitecten een groot deel van hun tijd kwijt zijn met het managen van managers. ‘Hoe hoger je in een organisatie zit, hoe meer je bezig bent om het management rustig te houden. Je bent het eerste aanspreekpunt voor alle technische problemen. Als een moeilijk project weinig voortgang boekt, dan zit je elke dag bij de ceo. Fusion beïnvloedde de kroonjuwelen van Medical en had de aandacht van de allerhoogste niveaus. Als je ’s ochtends op je werk komt, dan stond bij wijze van spreken de businessunitmanager al aan mijn bureau. Op een gegeven moment ben je voornamelijk bezig om die mensen rustig te houden.’

Beschouwend: ‘Managers hebben natuurlijk een frustrerend beroep. Ze hebben zelf heel weinig grip en moeten zorgen dat anderen het doen. Gaat het niet goed, dan gaan ze oversturen, willen ze drie rapporten per dag. De hoogste technici en de projectleiders lijden daar het meest onder. Die moeten hun bazen goed informeren en vertrouwen vragen.’

Als technicus moet je dit echt willen en er bovendien mee kunnen omgaan. Vertrouwen krijgen en een taal spreken die niet-technici begrijpen is wel een vaardigheid die je kunt ontwikkelen, zegt hij. ‘Niet iedereen vindt dat leuk. Het is op den duur niet alleen technisch. Het gaat ook om strategie en budgetten. Zoals technici dat vaak ervaren: meer gezeur aan je hoofd.’

Je moet eigenlijk een halve psycholoog zijn?

‘Zo zou ik het niet willen omschrijven. Ik heb ook uitglijders gemaakt. Maar je moet wel een beetje met mensen kunnen omgaan. Want in technische ontwikkelomgevingen heb je collega’s die niet van autoriteit houden, anderen hebben een aai over hun bol nodig en weer anderen zijn behoorlijk vierkant. Dan zijn er de pessimisten die altijd denken dat het misgaat en de optimisten die altijd zeggen dat het morgen af is. Die geluiden moet je leren inschatten. Het is geen baan voor iemand met contactproblemen.’

Waar kan het misgaan in de contacten met managers?

‘Transparantie is essentieel. Je moet zorgen voor inspiratie, maar je moet wel een betrouwbaar beeld schetsen van de ontwikkeling van het product. Dat betekent balanceren. Geen politieke correctheid, maar ook geen doemverhalen. Je moet echt altijd een goed beeld van de werkelijkheid schetsen: de grootste risico’s, de vertragingen. Je moet managers echt meenemen in scenario’s en ze erop wijzen dat de boel technisch vastloopt als ze specifieke ingrepen of investeringen niet doen.’

‘Het is heel belangrijk om je toon aan te aanpassen. Bij een ceo zonder technische achtergrond moet je niet in de details duiken. Tegen jonge technici moet je niet roepen dat we volgende maand failliet zijn als het zo doorgaat. Je moet een zekere mate van urgentie overbrengen, maar geen paniek zaaien.’

Pronk onderstreept dat het natuurlijk wel uitmaakt wat voor soort manager er tegenover je zit. ‘Er zijn grote ervaringsverschillen.’ Hij maakte doorgewinterde marketingmanagers mee die goed snapten hoe de r&d van een grote organisatie werkte, maar ook de ‘jongens in korte broek met notenhouten brilletjes’ die vooral gingen voor een snelle carrière.

Bij klanten valt die laatste groep snel door de mand. Om aangedikte marketingverhalen te voorkomen, vragen op

Trusting in experience. Benefitting from innovation. Advancing sensor technology.

Optimale oplossingen, afgestemd op uw behoeften: Ervaar state-of-the-art technologieën en innovaties met industriële sensoren en systemen van Pepperl+Fuchs – het maakt de weg vrij naar volledig gekoppelde productieprocessen voor de toepassingen van de toekomst.

www.pepperl-fuchs.com

‘Het reële risico van een goeroestatus is dat mensen niet meer aan je twijfelen, al zeg je dat de aarde plat is.’

drachtgevers vaak of de systeemarchitect bij gesprekken aanwezig kan zijn. ‘Want die houdt geen kletsverhaal en vertelt hoe het echt zit’, zegt Pronk.

Slakkenhuis

Door corona gedwongen wisselt Pronk ten tijde van het gesprek de hectische startupomgeving in voor de keuken thuis. ‘We liggen niet stil, maar we hebben er wel last van. Mensen werken thuis, hun kinderen gaan niet naar school en we hebben leveranciers die niet kunnen leveren. Je snapt: al onze contacten met de medische wereld zijn even on hold. We sturen even geen mensen naar een ziekenhuis. Die hebben nu even een andere focus.’

Eindhoven Medical Robotics (EMR) focust op robotsystemen voor operaties in het gebied van het hoofd en de nek. Daarmee staat de startup voor een forse uitdaging. Anatomisch gezien is het een van de meest complexe gebieden van het menselijke lichaam. Aan chirurgen met kennis en kunde op dit terrein is een groot tekort. Voordat specialisten zelfstandig in deze regio mogen opereren hebben ze er een traject van acht tot twaalf jaar op zitten. EMR zegt dat er hooguit twee concurrenten zijn op zijn terrein.

De eerste systemen gaan assisteren bij het inbrengen van gehoorimplantaten. Om een elektrode in het slakkenhuis van het oor in te brengen, moet een chirurg of robot door zeer hard schedelbot boren. Daarbij is navigatie nodig met nauwkeurigheden van minder dan een tiende millimeter om zenuwen en bloedvaten te ontzien. Als de smalle ingang van de complexe helische cochlearstructuur is bereikt, moet de elektrode worden ingebracht zonder het resterende gehoor te beschadigen. Door het gebrek aan ervaren chirurgen kunnen zo op dit moment maar een op de tien mensen worden geholpen. De inzet van robots kan deze situatie wezenlijk veranderen.

Eindhoven Medical Robotics richt zijn apparaat op het moeilijkste deel van het lichaam. Is het vanuit systeemarchitectuuroogpunt wel slim om meteen voor het hoogste te gaan?

‘De marktevaluatie laat zien dat er een duidelijke kans ligt. Natuurlijk zijn er stapels technische uitdagingen, natuurlijk gaat het moeilijk worden, maar we zitten hier wel in een omgeving met ruime ervaring en kennis in precisiemechanica.’

Wat is de grootste uitdaging?

‘Bij ons is de allergrootste uitdaging dat mensen accepteren dat een machine zelfstandig in een schedel boort. Als de robotarm uitschiet, zit hij in de hersenen. Ook een chirurg schiet weleens uit tijdens een operatie. Meestal gaat dat goed, maar soms ook niet. Waar het misgaat, is dat vervelend, maar wel geaccepteerd. De acceptatie van een robot komt alleen met veiligheid en het is dus een heel lang proces voordat artsen er in een klinische omgeving mee gaan werken. De hele regelgeving hieromheen is horrendous.’

‘Los daarvan heeft een instrument dat autonoom in een schedel boort met toleranties van sub-tiende millimeter allerlei mooie uitdagingen zoals de beeldverwerking om te zien waar je bent en de realtime besturing die meteen reageert als een patiënt gaat hoesten.’

Welke rol speelt de systeemarchitect daarin?

‘Veiligheid is het voornaamste designprincipe. Heel vaak is het bij architectuur functionality first: wat moet het apparaat doen? Daarbovenop komt dan nog de error handling. Safety first geldt tegenwoordig bij alle medische apparatuur, maar in bijvoorbeeld de diagnostiek is het wel ietsje eenvoudiger. Bij behandelmachines is safety echt de rode draad, het allerbelangrijkste aandachtspunt.’

Op de Bits& Chips System Architecture Conference op 24 september in Eindhoven (www.sysarch.nl) houdt Ben Pronk een keynotepresentatie. Hij gaat praten over wat er veranderd is voor systeemarchitecten en wat de constante factoren zijn. Pronk zal ook uitgebreid stilstaan bij de vraag of er met de snelheid in de productontwikkeling en digitalisering nog wel plaats is voor systeemengineering.