Modulair werken heeft een eigen taal. Posities, interfaces, modules, varianten en attributen. Wie die taal deelt met engineering en verkoop, bouwt een productmodel dat jaren meegaat. We leggen hem uit met twee beelden die iedereen begrijpt. Een puzzel en een werkbank.
Het product als puzzel

Het lege vak is de positie. Die ligt vast en wacht op een stukje. De nop en de uitsparing vormen samen de interface. Passen die, dan klikt elk stukje dat zich aan de vorm houdt. Het stukje is de module, en er passen meestal meerdere stukjes op hetzelfde vak. Alternatieven en varianten. Een stukje mag zelf weer een kleine puzzel zijn. Modules mogen modules bevatten, zolang ook daar de noppen bevroren zijn.
Vijf lagen, een taal

De test die alles simpel houdt.heeft het een fysieke interface? Het ladeblok schroeft aan het frame, module. Kleur verbindt niets, attribuut. Zo voorkom je dat alles een zware module wordt.
De positie ligt vast, de module wisselt

De interface hoort bij de positie, niet bij de module. Elke module die de interface volgt past erin, ook de module die je volgend jaar pas bedenkt. En let op het brede stukje dat twee vakken tegelijk claimt. Zo'n brede lade is alleen kiesbaar als links en rechts allebei vrij zijn. Dit soort spelregels bewaakt een configurator foutloos, een mens niet.
De interface is het contract

Negentig procent van modulair werken zit in de verbindingen, niet in de blokken. Leg elke verbinding vast op een interfacekaart. Mechanisch (boutgaten, hart-op-hartmaten), elektrisch en de attributen die elke module moet melden. Kaarten hebben een status, versie en eigenaar en vormen samen het interfaceregister, in de industrie bekend als interface control document. Bevroren is bevroren. Wijzigen kan alleen via een nieuwe versie met impactcheck.
Wie levert de waarde van een attribuut?
De positie eist dat een bezette breedte gemeld wordt. De module belooft dat zijn uitvoeringen dat doen. Maar het echte getal komt van de variant. Daar liggen de maten vast. Globale attributen (zoals buitenkleur) leg je eenmalig vast. Gemarkeerde delen lezen mee en een bewuste override blijft mogelijk.
Kleur blijft een eigenschap in het model. Wil je ERP per kleur een eigen artikelcode? Prima, het systeem genereert die op ordermoment. Het punt is niet dat die code niet mag bestaan, maar dat je engineer hem niet meer met de hand maakt.
Van als-dan-regels naar een attribuut

Voorbeeld werkbank. De plint moet passen bij wat er aan zijn kant onder hangt. Naïef wordt dat een web van als-dan-regels dat bij de tiende module onbeheersbaar is. De schone aanpak werkt anders. Elke module meldt een waarde aan zijn positie (de bezette breedte), en elke plint leest alleen zijn eigen kant. Links een blok van 300 mm? Plint links = 3.000 − 300 = 2.700 mm. Nieuwe module volgend jaar? Die meldt alleen zijn breedte. Nul nieuwe regels.
De discipline in drie treden.ontwerp de afhankelijkheid weg (een lengte met vulstuk), anders absorbeer hem in de interface (gepubliceerd attribuut), en pas als laatste een beheerde spelregel in het regelregister, met eigenaar, versie en reden.