In deel I eindigden we met de vraag: “Hoe groot moeten de blokken zijn?” Net als bij LEGO zijn er voor- en nadelen aan grote en kleine blokken. We lazen ook dat één groot, monolithisch blok weliswaar lekker simpel is, maar zo zijn beperkingen heeft in het aantal varianten.

De 1e wet van LEGO geldt dan ook: des te meer blokken, des te meer varianten je kan bouwen.

De 2e wet van LEGO stelt: des te groter de blokken, des te sneller je kan bouwen.

Men kan op verschillende manieren tot een opdeling in modules komen. Top-down, of bottom-up. Om dat te snappen moet men het product, de installatie of machine bekijken als een samenstel van losse delen.

In de meest extreme top-downbenadering ziet men de hele motorfiets als één module (zoals het bedrijf uit deel I). In de meest extreme bottom-up benadering ziet men ieder afzonderlijk deel als één module.

Om een idee te krijgen hoe modulair het product nu eigenlijk is hanteer ik de modulariteitsindex. Heel simpel het aantal modules gedeeld door het totaal aantal onderdelen, uitgedrukt als percentage.

Stel voor dat de motorfiets in ons voorbeeld is opgebouwd uit 1000 losse onderdelen. Maar we ‘houden het simpel’ en onderscheiden 20 modules. De modulariteitsindex is dan 20/1000 x 100%=2%.

Bij een lage index heb je weinig, maar complexere modules: iedere module bevat immers een relatief groot aantal onderdelen.

Bij een hoge index heb je veel, maar eenvoudige modules: iedere module bevat slechts een beperkt aantal onderdelen. De complexiteit zit ‘m dan in de onderlinge samenhang en afhankelijkheden. Er zijn ongetwijfeld knappe koppen die voor u kunnen berekenen hoeveel combinaties er mogelijk zijn met 1, 20, 100 of 1000 bouwblokken.

Grote blokken verbergen een hoop complexiteit. Dat maakt het verleidelijk om het bij een grove modulaire indeling te laten. Het leven is al ingewikkeld genoeg. Laat dat maar aan de R&D en engineering afdelingen over…

Deze ontkenning van complexiteit komt ergens, down-stream in de waardeketen, weer keihard op uw bordje terug.

Er zijn ook slimmeriken die roepen “Ik maak één groot ‘slim’ blok met allerlei opties zodat ik toch heel snel alle varianten kan realiseren.” Vooral populair in de software discipline. Klinkt als een goed idee? Ja… eerst wel, maar later niet. En dat heeft te maken met de beheersbaarheid. Daar gaan we het in deel III over hebben.

Om het niet al te ingewikkeld te maken, heb ik me tot nu toe beperkt tot fysieke, tastbare delen. De meeste bedrijven die modulair bouwen hebben dan ook met name hun Bill of Materials (de onderdelenlijst) modulair gemaakt. Op die manier halen ze vooral logistieke voordelen.

Daarbij gaat men er blijkbaar van uit dat de opties die een klant kiest, en de productvarianten die daaruit voortkomen, te herleiden zijn tot fysieke delen. Vaak zonder de elektrotechnische delen, laat staan de niet tastbare software delen. In een tijd waar software een steeds groter aandeel in de ‘customer value’ krijgt, is dat natuurlijk al lang niet meer het geval.

Je leest dan ook veel over de toenemende complexiteit van producten. Met name omdat men zich bovenstaande begint te realiseren. Een Bill of Materials is nog overzichtelijk vergeleken bij de al dan niet modulaire structuren in software. Daar komt bij dat al die verschillende structuren met elkaar verbonden blijken te zijn en afhankelijkheden hebben (“Ja joh!”). Gek wordt je er van! Maar inderdaad, het is niet langer te ontkennen.

Hoe veel of weinig modules je ook hebt, uw product is complexer dan u dacht!

In deel drie gaan we het hebben over het beheersen van complexiteit.