Terug naar de basis

Het grootste voordeel van value engineering is dat het meteen bruggen slaat tussen marketing, ontwikkeling, fabricage, inkoop en leveranciers. Goof Pruijsen deelt de ervaringen die hij de afgelopen dertien jaar heeft opgedaan in de toepassing van value engineering-methodieken bij de ontwikkeling van hightech apparaten en machines.

Goof Pruijsen is value engineer en cost manager. Na jaren praktijkervaring bij Philips Healthcare geeft hij nu advies via zijn eigen consultancybureau I4value. Voor The High Tech Institute verzorgt hij trainingen over value engineering.

8 maart 2017

Veel ‘beginners’ met kostenreductie in het vizier starten bij de bill of materials van de huidige oplossing, maken een pareto-analyse (20 procent van de componenten zorgt voor 80 procent van de kosten) en willen van de duurste dingen wat af halen (de kaasschaafmethode). Natuurlijk levert die aanpak altijd wel wat op, maar het is vaak niet heel effectief. Anderen hebben bijvoorbeeld al iets vergelijkbaars gedaan op hetzelfde onderwerp zodat er niet veel meer te halen valt. Of nog erger: de kosten worden zo laag dat de kwaliteit geraakt wordt en dat vermindert je imago bij de klant.

Goof Pruijsen adviseert: ‘Voer eerst een grondige analyse uit voordat er aan oplossingen wordt gedacht.’

Met value engineering redeneren we vanuit de waarde voor de klant. Wat is het waarmee je hem helpt? Welke functies zijn daarvoor nodig? Wat is de waarde van die functie en wat zijn de kosten? Een voorbeeld dat ik vaak aanhaal: het gaat niet om de boormachine, maar om het schilderij dat aan de muur moet. Je huis decoreren, daar draait het uiteindelijk om. Teruggaan naar het uiteindelijke doel maakt ruimte voor creativiteit om aan nieuwe oplossingen en concepten te denken.

Het functie-denken blijkt minder goed ingeburgerd dan de meeste bedrijven en ontwikkelaars van zichzelf denken. Juist de oplossingsgerichtheid waarmee veel teams te werk gaan, maakt hen blind voor andere oplossingen. Ze komen niet out of the box. Het helpt – en daar is oefening voor nodig – om een bestaande oplossing te analyseren en van daaruit steeds verder te abstraheren totdat de functies duidelijk zijn, zonder de oplossing te beschrijven. Dan kun je de kosten functioneel in kaart brengen en samen onderzoeken waarom die functies duur zijn. Dat is een goede start voor een volgende productgeneratie. Cost driver-analyse noem ik dat. Als je dit goed doet, begint iedereen het probleem veel beter te begrijpen en ben je al halverwege de oplossing.

Een heel typisch voorbeeld van een cost driver is de tolerantie. Nauwe toleranties in mechanica zijn voor leveranciers duurder om te realiseren. Het kost meer tijd of bewerkingsstappen op een freesbank. Een 24 V voeding met een vermogen van 100 W is niet zo duur maar als de rimpelspanning heel klein gespecificeerd is – ongeacht de belasting – schiet de prijs omhoog.

Sentech Precisiebeurs

Het is verstandig om alle toleranties goed onder de loep te nemen. Zijn ze echt nodig, overal of alleen lokaal? Waarom is die tolerantie zo gespecificeerd? Vaak blijkt dat engineers daar helemaal niet over nadenken. De tolerantie wordt gekopieerd van de vorige tekening. De leverancier is de eerste die de tolerantie echt leest en doorberekent in de prijs. Ontwikkelaars zijn zich meestal niet bewust van de gevolgen van hun risicomijdende kopieergedrag. Als blijkt dat een moeilijke tolerantie-eis niet zo strikt is, dan wordt de fabricage opeens veel makkelijker, sneller en goedkoper. Maakbaarheidsproblemen en yield loss lossen spontaan op.

In grote projecten met meerdere subteams optimaliseert ieder zijn eigen gebied zo veel mogelijk (al is het voor de eer). Als er geen overall architect is, en de teams eigenlijk niet zo goed begrijpen hoe de functie van het geheel is verdeeld over de modules (en teams), dan is de kans op onbalans in design en specificatie groot. Dat heeft zijn weerslag op de kostprijs en de doorlooptijd van de ontwikkeling. Kun je sommige teams vragen iets minder hun best te doen?

Verontwaardigd

Een praktijkcase. In medische diagnostiek, en ook voor materiaaltests, wordt al heel lang röntgen gebruikt. Om röntgenstralen te maken, moeten elektronen worden versneld met hoogspanning (hv) en op een zwaar metaal worden geschoten. Op een gegeven moment was er een nieuwe hv-generator nodig. Volgens marketing met meer vermogen, betere stabiliteit en hogere betrouwbaarheid. En liefst goedkoper.

Zo’n project begint vaak puur performance- en technologiegedreven. In dit geval besloten we echter formeel met een value engineering-workshop te starten om naast de technische richting ook het rendement voor de business te verbeteren. De oude generator werd geanalyseerd in kosten en functies. Het bleek dat relatief veel geld in de ‘staart van pareto’ zat. Je kunt niet snel je vinger leggen op dat ene dure onderdeel; het syndroom is er een van veel onderdelen. De oplossingsrichting is hier vaak dfma: reduceer het aantal onderdelen.

Een andere cost driver lag besloten in het concept. Om het oude volumineuze hoogspanningsconcept (tot 150 kV) op een veilige manier af te schermen van de omgeving wordt dit helemaal ondergedompeld in een met olie gevulde tank. Groot, zwaar, duur.

Per functie hebben we een brainstorm gedaan en daaruit een consistent en optimaal scenario gebouwd voor een totaaloplossing. Voor de hoogspanningsopwekking konden we meeliften op technologievernieuwing. Doordat het mogelijk is geworden met steeds hogere frequenties te transformeren, konden we het volume van het concept verkleinen.

Een van de grootste doorbraken vonden we door naar het gebruik te kijken. De oude generator was ontwikkeld door alle specs als aparte line items te interpreteren. Het gebruikersprofiel was echter anders. Je gebruikt óf een single shot met hoog vermogen of meerdere beelden per seconde met heel laag vermogen (en wat combinaties daartussen in). Toen de engineers dit zagen, begonnen ze verontwaardigd met hun pennen te gooien: ‘Niemand heeft ons dit ooit verteld!’ Het gevolg was dat het totaal gemiddeld continu vermogen met een factor kon worden teruggebracht, wat leidde tot nog meer volumereductie.

Het nieuwe concept heeft daarmee een hoogspanningstank met nog maar een tiende van het oorspronkelijk volume. Desondanks blijft er koeling nodig. In de oude situatie werd dit gedaan met een kwartet grote fans. In de nieuwe oplossing hebben we het probleem letterlijk op zijn kop gezet: de warmtebron zit onder in het kabinet zodat er een convectiestroom ontstaat. In wezen gebruik je een sterkere warmtebron om beter te kunnen koelen. Resultaat: een veel stillere generator met minder componenten.

Het eindresultaat is een hv-generator die kleiner, 35 procent goedkoper en stiller is. Bovendien hebben we minder componenten nodig en halen we een betere betrouwbaarheid. Samen met een andere optimalisatie kan de totale footprint van het systeem met één kabinet worden teruggebracht.

Had het nog beter gekund? Jazeker. Eén specificatiepunt hebben we tijdens dit traject namelijk niet kunnen doorbreken. De generator was gespecificeerd op 100 kW vermogen. Iedereen ‘wist’ dat dit moest volgens de medische regelgeving. Het heeft me maanden gekost om de bron van deze misvatting te vinden: een medische richtlijn (een advies, geen wet!) die het gebruik van een generator van minimaal 80 kW adviseert om met grotere zekerheid een goede diagnose te kunnen stellen. De regel dateert echter van 1991. In de tussenliggende twintig jaar heeft de beeldbewerkingstechniek zo’n vlucht genomen dat met veel minder vermogen een beter resultaat kan worden verkregen. Uiteindelijk heb ik een productmanager gevonden die toegaf dat het helemaal geen wettelijk richtlijn was, maar een ‘tender-spec’. Omdat de hele industrie jarenlang aan de klanten heeft verteld dat alleen met 100 kW voldoende kwaliteit kan worden gewaarborgd, is het een accepted customer belief geworden. Maar meer is niet altijd beter. Vaak wel duurder.

Door value engineering-technieken toe te passen, kwam Philips tot een hoogvoltagegenerator die kleiner, goedkoper en stiller was.

Balans

Value engineering gaat uit van functiescheiding en stuurt daarmee aan op een modulaire architectuur. Daarmee helpt het de systeemarchitect met zijn team een goede afweging te maken tussen modulaire of geïntegreerde oplossingen.

Nog een voorbeeld uit de praktijk. Een grote module in een productiemachine werd in een aantal kleine modules ontworpen, zodat als er een fout optrad in een van de deelmodules die snel kon worden verwisseld. De aanname was dat de hele module daarvoor te groot was en, gedacht aan de servicevoorraad, ook te duur. De toename in het aantal kritieke interfaces met hoge tolerantie-eisen maakte echter dat de kostprijs verdubbelde en de complexiteit zodanig opliep dat de verwachte betrouwbaarheid dramatisch lager werd. En dan heb ik het nog niet over de extra ontwikkelkosten en het inrichten van de extra productietests. Een ontwerp uit één stuk waarbij de componenten met de meeste uitvalkans op een gemakkelijk bereikbare plaats worden gezet, bleek de betere oplossing. Modulair is meestal beter, maar denk wel na over de gevolgen en de balans.

Een ander voorbeeld. Een meetopstelling die in productie werd gebruikt, bleek interessant om als tool te verkopen aan andere partijen. Het meetsysteem werd in grotere aantallen geproduceerd maar de kostprijs bleek veel hoger dan verantwoord. Dat kwam onder meer doordat de ontwikkelaars de reproduceerbaarheid per installatie moesten tunen (lange installatietijd en hoge kosten). Het achterliggende syndroom was hier het gebrek aan architectuur. De oorspronkelijk meetopstelling was met trial-and-error en hobbywerk aan elkaar geknutseld tot iets dat prima werkte. Alleen was alles slecht gedocumenteerd en slechts op top level gespecificeerd. Functies en functionele blokken waren niet netjes gescheiden (en/of gespecificeerd), zodat een kleine lokale afwijking in componenten een desastreus effect had op de performance. Debuggen was daardoor natuurlijk ook een crime. Omdat een fors deel van het apparaat bij één leverancier was uitbesteed én door gebrek aan functionele scheiding was het niet mogelijk om via benchmarking de prijs onder druk te zetten of bepaalde delen bij andere leveranciers onder te brengen.

Value engineering samengevat:

– Voer eerst een analyse uit voordat er aan oplossingen wordt gedacht

– Ga terug naar het begrip: wat doet het?

– Wat maakt het duur en waarom?

– Inventariseer de aannames en reken ermee af

– Wees creatief; beperk jezelf niet in het denken in traditionele oplossingen (risicomijdend) maar zoek de grenzen op

– Breng de oplossingen tezamen in een totaal overzicht en bouw scenario’s

– Bagatelliseer risico’s niet maar gebruik ze ook niet als excuus om dingen niet te doen. Maak ze expliciet en bepaal hiervoor een oplossing

– Hou de businesscase in het oog. Iedereen is graag creatief bezig maar er moet ook geld worden verdiend. Welk scenario voldoet aan de financiële en organisatorische randvoorwaarden?

– En ten slotte: ga ervoor!

Redactie Alexander Pil