Modules

In het vorige deel is beschreven hoe modularisatie een van de centrale bouwstenen  vormt in de aanpak van Lean Product Mix.
Daarbij is gekeken naar de algemene ontwikkeling en de toepassing van het concept modulariteit en 10 belangrijke principes zijn besproken.
Maar hoe ga je nu deze principes toepassen op je productrange en waarmee moet je dan in de praktijk rekening houden?
Hiervoor worden in het volgende een aantal concrete handreikingen gedaan inclusief een proces-checklist  om te gebruiken bij de definities van modules.
Dit gedeelte is vooral toegespitst op die segmenten binnen de maakindustrie waar producten bestaan uit mechatronische systemen zoals onder meer in de apparaten- en machinebouw, automotive, transportmiddelen en industriële equipment.

Wat is een module

Laten we maar gelijk met de deur in huis vallen met een overkoepelende omschrijving van wat een module is: ​
Een module is een
samenstelling van monodelen
die in verschillende varianten en/of instances van varianten
kan voorkomen op zodanige wijze
dat een compleet product kan worden opgebouwd
door van alle verschillende modules één (of geen) variant te  kiezen.
Over de vetgedrukte delen van deze definitie kan het volgende opgemerkt worden:
Een module is steeds een (kleine of grote, eenvoudige of complexe) samenstelling van delen; monodelen in het geval van mechanische systemen, elektrische /hydraulische / pneumatische/ componenten of onderdelen in het geval van elektrische /hydraulische / pneumatische systemen en software regels (of zelfs bytes) voor programma's.
Een module kent over het algemeen meerdere varianten; dat wil zeggen soortgelijke samenstellingen met eenzelfde structuur, interfaces  en hoofdfunctie maar met afwijkingen binnen deze overeenkomsten.
Een modulevariant  kan op zijn beurt eventueel (maar niet noodzakelijkerwijs) zgn. 'instances' bevatten die allemaal dezelfde vorm en karakteristiek hebben op één variabele parameter na zoals bijvoorbeeld een afmeting.
Een module(variant) vormt samen met andere modules/modulevarianten gezamenlijk één specifiek eindproduct; hiertoe wordt voor iedere module één specifieke variant gekozen -of een 'lege' variant indien de module optioneel kan zijn, ofwel niet noodzakelijk voor een compleet eindproduct.

Wat is een module niet?

Na deze wat uitgebreide definitie van een module is het ook nuttig om te benadrukken wat een module niet is:
Een module is niet een verkoop-optie, ook al kan het voorkomen dat een bepaalde verkoop-optie gerealiseerd kán worden door 1 modulevariant.
Een module is niet een noodzakerlijkerwijs dezelfde samenstelling zoals die in produktie als eenheid wordt gebruikt- ook al kan dat wel zo zijn.
Een module is niet een een willekeurige samenstelling van onderdelen; deze samenstelling zal moeten voldoen aan de eerder genoemde kenmerken.

Klantperspectief

I) klant perspectief
​Modules worden zo gekozen dat verschillende combinaties van verkoopopties kunnen worden gerealiseerd door een combinatie van modules. Dit vloeit rechtstereeks voort uit het modularisatie principe #1 'klantkeuzes' zoals eerder aangegeven.
Vanuit dit perspectief wordt gekeken hoe iedere afzonderlijk klantkeuze herleid kan worden tot een combinatie van afzonderlijke modulevarianten. Het meest eenvoudig is dit natuurlijk bij een 1-op-1 relatie zoals een accessoire, een component dat naar wens wel of niet achteraf toegevoegd kan worden aan een product. Het meest ingewikkeld is dat bij een klantkeuze die impact heeft op een groot deel van het eindproduct; denk bijvoorbeeld aan het motorvermogen van mobiele apparaten waarbij alle aandrijflijn componenten beïnvloed worden en wellicht ook nog andere constructieve delen. In dit geval is er sprake van een zgn. '1-op-n' relatie: 1 klantkeuze (optie) beïnvloedt 'n' modules. De tegenhanger hiervan is de 'n-op-1' relatie waarbij meerdere klantkeuzes leiden tot 1 modulevariant zoals bijvoorbeeld bij klantkeuze afmeting + klantkeuze kleur; dit laatste is veel gemakkelijker te structureren en te onderhouden.
Voorbeeld 1-op-1: De klantkeuze  'extra afscherming' leidt tot de module 'afschermkap' die bevestigd kan worden aan standaard bevestigingspunten .
Voorbeeld 1-op-n: De klantkeuze  '2000 kW' leidt tot de modules 'motor 2000kW', 'koppelomvormer 24C', 'koelunit II', 'ophangframe HD' en aansturingssoftware v8.23.
Voorbeeld n-op-1: De klantkeuzes  '17inch velg' + 'materiaal aluminium' leiden tot de module 'set Speedo design aluminium 17" velgen'. 

Technisch perspectief

III) technisch perspectief
Modules worden zo gekozen dat zo veel mogelijk een duidelijke technisch/ constructieve samenhang binnen modules bestaat en het mogelijk is afzonderlijke modules onafhankelijk van de rest van het product te standaardiseren en te optimaliseren naar functie, kostprijs en gewicht. Dit raakt met name aan het modularisatieprincipe #2 Functionaliteit. Zo'n samenhang kan bijvoorbeeld zijn 'alle componenten die zorgdragen voor de koeling van de motorolie' of 'alle componenten die de krachten doorleiden vanaf het frame tot aan het beweegbare platform'. Hierbij moet wel rekening gehouden worden met modularisatie principe #3 Maak/Koop besluiten: Het is onhandig als binnen 1 gedefinieerde module variaties kunnen ontstaan die afhankelijk zijn van (willekeurige) wijzigingen die leveranciers doorvoeren in componenten die deel uitmaken van deze module. 
Voorbeeld Wanneer een hefbrug mechanisme in een machine een off-the-shelff besturingskast bevat van een leverancier kan het voorkomen dat deze op een bepaald moment door een nieuw model vervangen moet worden. Dan is het handig wanneer dit alleen de (sub-)module besturingskast raakt en niet het hele mechanisme.

Eenvoud modulestructuur

Tegenover deze eenvoud van de afzonderlijke modules staat als concurrent de eenvoud van de complete modulestructuur. 
Voor een goed overzicht over het totale product en voor het snel kunnen samenstellen van een product is het gewenst om zo min mogelijk verschillende soorten modules nodig te hebben. Dit leidt tot een structuur met een klein aantal, relatief complexe modules met ieder een zeer groot aantal varianten, dus tot een ‘smalle, diepe’ structuur. Deze aanpak is vooral haalbaar wanneer dat grote aantal varianten van de afzonderlijke modules relatief eenvoudig gecreëerd kan worden in het productieproces; anders zou er namelijk veel te veel waarde in het 'work in progress' zitten; denk aan tussenvoorraden met grote hoeveelheden verschillende varianten van een bepaalde module. Dit zou bedrijfseconomisch niet interessant zijn.  

​Uit het voorgaande blijkt duidelijk dat de tweede stap in het bepalen van een optimale modulestructuur duidelijk een compromis is: een compromis tussen optimale module-eenvoud en optimale structuur-eenvoud. Dit compromis zal voor ieder bedrijf en productgroep anders zijn.

Checklist module definitie

Zodra een eerste concept modulestructuur (architectuur) is opgesteld en de daaruit volgende definities van de afzonderlijke modules in concept vastgelegd zijn kunnen deze getoetst worden aan de hand van bijgaande checklist:

Startpunt: Concept module definitie

Klantkeuzecheck: Is er een verkoop optie die opdeling van de module noodzakelijk maakt?

Productiecheck: Is er een produktie samenstelling die opdeling van de module noodzakelijk maakt?

Technische check: Is de samenhang van de inhoud logisch, zijn de interfaces van de module eenduidig en kan de module afzonderlijk geoptimaliseerd worden?

Dieptecheck: Is het resulterend aantal varianten van de module acceptabel (< X) ?

Breedtecheck: Is het resulterend totaal aantal modules voor het gehele product acceptabel (< Y) ?

Eindpunt: Definitieve module definitie

NB: waarden voor X en Y vast te stellen binnen het bedrijf (als policy).

kenmerken van een module

Verdere kenmerken van een module, aanvullend op de eerder gegeven definitie:
Een module is een samenstelling met een duidelijk afgebakende inhoud; die afbakening kan geometrisch of functioneel zijn.
Een module heeft beschrijvende interfaces naar andere modules die bekend zijn en vastgelegd zijn (op meer of minder formele wijze) en niet veranderen bij verschillende eindproducten (op zijn minst binnen een bepaalde productfamilie).
Een module is bij voorkeur als zodanig herkenbaar in de gebruikte systemen waarbinnen productstructuren (zoals stuklijsten, schema's  of CAD-modellen) worden vastgelegd.

Dimensies modulestructuur

Nu we weten wat een module nu eigenlijk wel-en-niet is kunnen we uitzoomen en ligt de volgende uitdaging in het bepalen van de overkoepelende modulestructuur; en die structuur heeft weer alles te maken door de eerder genoemde product-architectuur. De bepaling van de modulestructuur is een weloverwogen keuze vanuit het bedrijf en daarmee een definitie, een gezamenlijke afspraak. Bij het daadwerkelijk bepalen van modulestructuur wordt in feite het beste compromis gezocht langs 2 dimensies:

De dimensie bedrijfsdisciplines:
I) klant perspectief
II) productie perspectief
III) technisch perspectief

De dimensie praktische toepasbaarheid:
a) Eenvoud van de afzonderlijke modules
b) Eenvoud van de complete modulestructuur

Deze twee dimensies zullen in het volgende behandeld worden. Eerst volgen nu de 3 perspectieven die te maken hebben met de dimensie bedrijfsdisciplines.

Productie perspectief

II) productie perspectief
Modules worden zo gekozen dat voor productie relevante hoofd-samenstellingen (vaak overeenkomend met  instructietekeningen) kunnen worden opgebouwd uit een combinatie van modules. Dit perspectief is gerelateerd aan de modularisatie principes #3 Maak/Koop besluiten en #5 Assemblage. Hierbij is meerdere modules per productiestation (of cel) te verkiezen boven het omgekeerde, nl. de samenstelling van 1 module over meerdere stations. In het eerste geval kan nog gebruik gemaakt worden van voorsamenstellingen (van een of meerdere modules)  en  kunnen de modules binnen eenzelfde productiestap gecontroleerd worden op kwaliteit. Bij product wijzigingen is bovendien maar op één locatie nieuwe instructie nodig.
​Nu kan in de praktijk de opdeling van assemblagewerk over diverse stations nogal eens wijzigen als gevolg van de totale capaciteit, producteigenschappen of nieuwe productietechnieken; daarom kan het verstandig zijn de modulestructuur iets fijnmaziger te maken dan op een bepaald moment in de tijd strikt noodzakelijk is. 

Eenvoud modules

Naast de hierboven besproken dimensie 'bedrijfsdisciplines'  is er ook nog de dimensie 'praktische toepasbaarheid'; hierbij wordt heel pragmatisch gekeken naar de uiteindelijke modulestructuur die zou volgen uit alle eerdere overwegingen. 
De eerste toetssteen is daarbij de eenvoud van de afzonderlijke modules.
Om het onderhoud  aan de afzonderlijke modules zo eenvoudig mogelijk te maken is het gewenst om zo min mogelijk varianten van een bepaalde module nodig te hebben. Dit leidt tot een structuur met een groot aantal, relatief eenvoudige modules met ieder een beperkt aantal varianten , dus tot een ‘brede, platte’ structuur. 
​Overigens is het eventueel wel mogelijk om dat onderhoud aan een groot aantal modulevarianten beheersbaar te houden door slim gebruik te maken van intelligentie binnen bestaande CAD en PLM systemen; maar uiteindelijk moet het toch steeds weer door mensen overzien en begrepen worden.
Voorbeeld Een samengestelde draagconstructie binnen een machine heeft 192 varianten: links/rechts, 8 verschillende bevestigingsposities, 4 sterkteklassen en 3 typen lageringen. Door de samenstelling te splitsen in een bevestigingsdeel ( met 8 verschillende bevestigingsposities en 3 typen lageringen) en een dragend deel (links/rechts, 4 sterkteklassen) is het resultaat 1 module met 24 varianten en 1 module met 8 varianten.

Hierarchie module-items

Ten slotte nog een toelichting op de hiërarchie van items en benamingen die te maken hebben met modules. In de praktijk treedt namelijk nogal eens wat spraakverwarring op en dat is niet zo vreemd aangezien het woord 'module' op verschillende manieren gebruikt kan worden.  Daartoe wordt eerst nog een nieuw begrip geïntroduceerd, nl. de Module Categorie. Dit beschrijft een groep van modules (met ieder weer hun eigen varianten) die overeenkomstige kenmerken (functie, vorm of plaats in het eindproduct) hebben. 
Voorbeeld De module categorie 'Onderstel' bevat de modules 'hydraulische stelpoten', 'basisframe' en 'hulpmontageframe', ieder weer met hun eigen varianten.
Hiermee kan dan de volgende hiërarchische structuur opgezet worden:
- Module categorie: bevat meerdere modules
- Module: bevat meerdere modulevarianten
- Modulevariant: bevat eventueel meerdere instances
- Modulevariant Instance.
Voorbeeld Voor een dragend deel van een productiemachine zou de hiërarchie er als volgt uit kunnen zien:
​Module categorie: Onderstel
Module: Hulpmontageframe
Modulevariant: Hulpmontageframe t.b.v. transportbandunit
Modulevariant Instance: Hulpmontageframe t.b.v. transportbandunit met lengte 3m
Het onderscheid tussen een module variant en een instance kan wat subtiel lijken aangezien je iedere instance eventueel als aparte variant zou kunnen aanmerken; echter een instance wordt meestal gebruikt als er een niet van te voren gedefinieerd aantal waarden van een parameter gekozen kan worden, deze relatief eenvoudig in productie gerealiseerd kan worden en/of een universeel artikelnummer heeft met alleen een extra aanduiding voor de veranderende parameter (bijv. lengtemaat).

Vanuit het 'hoe' van modules weer terug naar het 'wat' van de opties

Met bovenstaande richtlijnen is het mogelijk de eerder behandelde principes van modulariteit te vertalen naar een concrete modulestructuur en goed gedefinieerde en afgebakende modules. Hiermee is een groot deel van het 'Hoe' vastgelegd (zie de discussie over 'Hoe vs. Wat'). Nu is het tijd om weer terug te gaan naar het parallelspoor van het 'Wat': Wat wil de klant eigenlijk en wat moet het productiebedrijf dus aanbieden? Dit vormt het onderwerp van het volgende deel:
Opties - hoe leg je ze vast en waarmee moet je rekening houden?