CTO & Design Automation. Gouden koppel?

Al jaren en jaren lang gaat het in de industrie over CTO en ETO. Een heel leger consultants proberen u en ik te helpen bij de “transitie”, de “modularisatie”en de “standaardisatie”. Een leger één-ogen in een land vol gewillige blinden.

Al evenveel jaren verbaas ik me over de spraakverwarringen. standaard, basis, default, klantspecifiek, variant, module, interface MTS, ATO, MTO… Het is ook niet makkelijk natuurlijk. Hoewel er ruim voldoende goede literatuur voorhanden is. Maarja, wie leest er tegenwoordig nog een boek?

Een module bestaat uit lucht of papier. Een module is een beschrijving van een te vervullen functie, begrensd door interfaces. De theoretische ruimte die beschikbaar is voor die module kan worden opgevuld met één variant van die module. De “modulevariant” (je bedenkt het niet)

Module: Wiel, Dient om auto van de straat te houden. Zit met 5 bouten vast op een steek van 30, mag niet groter dan 20” en niet breder dan 30cm zijn (anders past hij niet in de wielkast)

De vraag wélke modulevariant je nodig hebt wordt meestal beantwoord door de juiste vragen te stellen. Elk antwoord is een variabele en de combinatie van variabelen bepaalt welke variant ik van de verschillende modules nodig heb.

Variabelen: aantal bouten, steek, diameter, breedte

Als je met deze variabelen naar een dealer of website gaat heb je de keuze uit honderden varianten die allemaal zullen passen.

In je auto heb je dan ook nog keuze uit een paar motoren, kleuren, bekledingen, waardoor het aantal mogelijke productvarianten al snel explodeert. Tientallen miljoenen is héél normaal. Hét meest gebruikte voorbeeld van wikipedia:  (niet vergeten zo nu en dan een donatie te doen!! https://donate.wikimedia.org/)

Als we deze even uitwerken (verdiepingen laat ik even buiten beschouwing):

design- & solution-space

Een product dat bestaat uit 5 modules, met elk 4 mogelijke modulevarianten kan dus in 4x4x4x4x4 = 1024 productvarianten geleverd worden. Dit noemen we de “design-space”. Omdat niet alle opties met elkaar samen kunnen zal het uiteindelijk aantal mogelijke productvarianten minder zijn dan 1024. Dat noemen we dan de “solution-space”.

Het aantal mogelijke productvarianten kan desalniettemin snel oplopen. Is dat erg? NEE! Natuurlijk niet! Want als je meer productvarianten kunt leveren, dan is de kans groter dat je er eentje kunt leveren waar jouw klant precies blij van wordt. Hoe meer mogelijke varianten, hoe beter. En om dat allemaal eenvoudig onder controle te houden, gebruik je natuurlijk Merkato.
  • Aantal variabelen: Is niet erg belangrijk. Daar heb je een configurator voor, waarmee je efficiënt, foutloos en snel klantwensen vastlegt.
  • Aantal modules: Is ook niet echt boeiend. Ze zullen wel een functie hebben, anders had je ze niet bedacht.
  • Aantal mogelijke product-varianten: Totaal oninteressant. Hoe meer hoe beter!!
  • Aantal module-varianten: Héél interessant. Want modulevarianten zijn échte dingen die beheerd moeten worden. In CAD, PDM, MRP, magazijn, ERP, uitbesteding, forecast, supplychain, etc….

Het lijkt soms net alsof Engineering iets verschrikkelijks is. Bent u nog niet modulair? Och jeetje… Jongen toch…. Wil je erover praten? Zal ik u eens consulteren?

Maar soms is engineering gewoon noodzakelijk. En je kunt er ook prima geld mee verdienen. Zolang je al dat ETO ge-engineer maar niet probeert te verkopen tegen CTO/ATO prijzen.

ETO/CTO is dus niet zwart wit. Het is een proces van veranderende focus. Soms is een deel van je CTO product gewoon wel degelijk nog klantspecifiek.

Ik onderscheid twee soorten engineering:

  • Klantspecifiek maken van een onderdeel dat eigenlijk ongeveer hetzelfde doet als het vorige onderdeel met die functie.
    • Meer van hetzelfde,
    • Vroeger deed je dat met een maattabel op de tekening, tegenwoordig heb je een maattabel in je CAD-pakket. (oftewel een parametrisch CAD-model)
    • Niet echt uitdagend, weinig toegevoegde waarde.
    • “in de chain”, dus géén tijd.
  • Het creatieve proces waar een engineer probeert een oplossing te bedenken voor een specifiek probleem.
    • Gereedschappen zijn potlood, stift. CAD komt pas later aan de orde,
    • Dit noemen we ook wel product development,
    • Niet ”in the chain”,
    • Als organisatie zet je hier je ervaren, creatieve, (dure) engineers op.

Waar we met dit verhaal de aandacht op willen vestigen is dat eerste stukje “engineering” dat dus eigenlijk helemaal geen engineering is. Wat voorbeeldjes:

  • U maakt een machine om vleeswaren te verpakken. Alle verpakkingen hebben altijd een andere breedte. Dus alle machines zijn volledig klant specifiek. Geen twijfel over mogelijk.
  • Of u maakt pneumatische cilinders. Die hebben allemaal een andere lengte. Geen pijl op te trekken, voorraad is onmogelijk. Elke klant wil wat anders. Alle stuklijsten zijn uniek…

Dus bij elke order; huppediekee, hele machine op het CAD-scherm, allemaal nieuwe nummers, want klant specifiek. Iedereen zit te wachten op de nieuwe stuklijsten die uit CAD en PDM moeten komen. Logistiek heeft geen idee wat op voorraad te leggen… Onzin natuurlijk. In het eerste geval zijn alleen de breedte bepalende onderdelen klant specifiek. En in het tweede voorbeeld alleen de lengte bepalende onderdelen.

Wat is nu de grote truuk?

Trek die stuklijst uit elkaar. Maak onderscheid tussen een stuklijst met klant specifieke onderdelen en een stuklijst met standaard onderdelen. Accepteer dat beide stuklijsten op zichzelf geen machine zijn dus! De stuklijst met standaard onderdelen trek je keihard uit “the chain”. Die zit allang in ERP, vrijgegeven uit PDM. Haal hier je CTO voordelen uit. Bij een cilinder is dit dus een stuklijst met voorkant, deksels, pakkingen, bouten, moeren, etc, het hele gebeuren, behalve de lengte bepalende onderdelen. Géén complete assembly dus!

Een paar onderdelen zijn wél klantspecifiek en moeten dus “langs engineering” Het CAD-model met de klantspecifieke onderdelen is dus een verzameling losse onderdelen die door de lucht vliegen. OH horror 😱, de tekenaar heeft dus geen hele machine op zijn scherm…. Nou én ? Dan maar géén sexy plaatjes. Vraag je altijd af of je je geld verdient met tekeningen maken. Behalve Rembrandt en Picasso zijn er echt maar weinig waar dat voor geldt. Elke seconde laadtijd, elke milliseconde processortijd, elke druppel inkt (of PDF) die in “the chain” besteed wordt aan een standaard onderdeel is verlies, muda, kosten, onzin, onnodig en zou keihard bestraft moeten worden.

Maak, als het even kan, van de klantspecifieke onderdelen parametrische CAD modellen en leg de link tussen de configurator en de CAD modellen. Dit is écht niet moeilijk of lastig. Ik deed dit zelf letterlijk 30 jaar geleden al en ook onze klanten doen niet anders. Mocht iemand het tegendeel beweren, vraag je dan altijd af wat zijn of haar belang is.

Als je dit onder controle hebt, dan heb je dus een stuk klantspecifieke engineering geautomatiseerd. Vandaar ook de naam engineering automation voor dit proces.

En er is een heel groot verschil tussen CPQ (salesconfiguratie, productconfiguratie) (geef het maar een naam), zoals wij dat doen, en “engineering automation”. Hoewel leveranciers van het laatste u graag anders zouden doen geloven. Een wijs man zei ooit: “There is no E in CTO” Misschien is dat ook de reden dat je geen engineering automation software moet gebruiken als je salesconfiguratie en CTO wilt motiveren.

Merkato helpt u om het CTO deel van uw product te configureren én de engineering automation onder controle te brengen.