Hij was twaalf jaar elektrotechnisch engineer, dus Chris Brouwer is bekend met de vermeende kloof tussen sales en engineering. Inmiddels werkt hij alweer vijf jaar als consultant voor EPLAN. In die rol ondersteunt Brouwer machinebouwers en systeemintegratoren bij het efficiënt inrichten van hun elektrotechnische engineering en helpt hij bruggen te slaan. De knelpunten liggen volgens hem in de gebrekkige informatieoverdracht en het dominante denken in technische oplossingen.
EPLAN-consultant Chris Brouwer bepleit omslag in denken
Brouwer adviseert bedrijven over hun elektrotechnische engineering. ‘Ik kijk telkens naar het gehele proces en probeer de onderdelen op elkaar te laten aansluiten, zoals sales, r&d, engineering, werkvoorbereiding en productie.’ Die aansluiting ontbreekt nog wel eens en dat heeft alles te maken met de gebrekkige informatieoverdracht, illustreert hij aan de hand van een voorbeeld van een systeemintegrator. ‘De salesmensen hadden een vrij gedetailleerde technische oplossing bedacht en overgedragen aan engineering, met een scope of work die alleen een bestellijst bevatte van wat er in de besturingskast moest komen. Voor de engineers ontbrak de samenhang, wat ze nu precies moesten doen. Dat konden ze niet uit die lijst met materialen afleiden.’ Bovendien bleken daarin bepaalde componenten niet te zijn opgenomen. Er was gewoon niet goed naar de gewenste functionaliteit gekeken. ‘Dat gebeurt vaker, reden waarom engineers soms rechtstreeks met de klant bellen om te vragen wat hem nu eigenlijk is verkocht. Ander voorbeeld, een machinebouwer die zegt alleen standaardmachines te verkopen. Dat blijkt vies tegen te vallen, want hij heeft het configuratiemanagement niet op orde. Sales verkoopt alles wat de klant vraagt, waardoor r&d soms nieuwe technische oplossingen moet bedenken die niet in het configuratieplatform passen. Uren en geld zijn daarvoor niet gecalculeerd, want het was toch standaard…’
Functionele modules
Het komt steeds weer op hetzelfde neer, verklaart Brouwer. ‘De communicatie tussen de verschillende afdelingen is niet goed. Er worden wel lijstjes met informatie uitgewisseld, over orders of standaarden, maar de ontvangers weten vaak niet wat nu wel of niet zinnige informatie is.’ Of neem het containerbegrip modularisatie, het werken met standaardmodules die in varianten beschikbaar zijn om de potentiële klantvraag efficiënt af te dekken. ‘Daar geeft elke discipline haar eigen invulling aan. Dat vraagt dus om goede communicatie vooraf, met afspraken over wat er standaard kan worden verkocht.’ Belangrijk daarbij is modules niet zozeer in mechanische zin (hoe ze in elkaar zijn gezet) als wel in functionele zin (wat ze moeten doen) te beschouwen. ‘Dat is generieker, omdat je voor een bepaalde functie meerdere technische oplossingen kunt bedenken. En het helpt de verschillende disciplines beter te bepalen wat hun bijdrage moet zijn.’ Bovendien is de opdrachtgever vooral geïnteresseerd in de functie, niet in de techniek. De functionaliteit van een installatie of machine is immers gedurende de gehele lifecycle belangrijk, de techniek alleen wanneer die wordt geproduceerd en bij een storing of revisie.
‘Software-engineers zijn beter in functioneel denken dan mechanici’
Software-engineers zijn beter in functioneel denken dan mechanici, aldus Brouwer. ‘Bij machinebouwers zijn de mechanische afdelingen van oudsher echter het grootst en luisteren ze vaak slecht naar de softwaremensen. Een software-engineer is bijvoorbeeld niet geïnteresseerd in waar de motoren en sensoren zich bevinden op een machineframe, maar wil wel weten hoe die samenwerken en wanneer een motor aan of uit moet. Dat is in de functionele beschrijving vastgelegd. De elektrotechnisch engineer zit daar tussenin. Die wil weten waar alle componenten zitten, want daar moeten kabels en draadjes heen. Maar vooral wil hij de functionaliteit begrijpen: hoe moet bijvoorbeeld die motorstarter werken, welke draadjes zijn nodig, klopt dit schema wel of mist hier een sensor of beveiliging?’
Dit artikel hebben wij gepubliceerd in Link 3 2019. Vraag kostleoos een exemplaar aan: info@linkmagazine.nl
Brugfunctie
De valkuil voor engineers, en projectleiders en verkopers met een technische achtergrond, is dat ze direct in technische oplossingen gaan denken. Ze moeten juist abstracter denken, in termen van functionaliteit en dat is in het begin vaak moeilijk, weet Brouwer uit eigen ervaring. ‘Mijn overtuiging is echter dat je eerst de gewenste situatie moet beschrijven en dat je dan technische mensen de beste oplossing laat bedenken.’ Dit geldt al voor een enkele, specifieke klantorder en des te meer voor generieke modularisatie. ‘In de beginfase heb je dan meer tijd nodig, terwijl iedereen al aan die concrete oplossing wil werken. Maar je kunt er beter een keer goed voor gaan zitten en vastleggen wat je telkens kunt hergebruiken, dan dat je in elk project weer de discussie over de beste oplossing krijgt.’
Systeemarchitecten of productmanagers kunnen daarbij een brugfunctie vervullen, maar Brouwer komt ze nog te weinig tegen. ‘Een productmanager kan bijvoorbeeld de wensen vanuit sales beter bundelen en daarbinnen prioriteiten aangeven richting r&d. Als er al een productmanager is, dan is die vaak mechanisch georiënteerd en neemt hij de wensen vanuit software en elektrotechniek niet altijd mee. Mijn boodschap: praat met elkaar over elkaars wensen en behoeften.’
