Modularity for dummies, part III

In Part II, we discovered that products are becoming increasingly complex, regardless of the number of modules. This time we’re going to talk about the manageability of that complexity.

Let’s see what the relationship is between an option offered, a product variant, its complexity and modularity.

Suppose your product does not have any options and is available in all colors as long as it is black. It probably won’t be long until you meet a potential buyer who loves the product … but … only in yellow. And like any salesperson, you want to ‘please’ the customer and say ‘agree!’. And with that the first option and choice is born.

The sales brochure now contains the following options and variants:

Your product develops further in response to market demands.

With a 2nd option the number of variants doubles from 2 to 4. With the 3rd option it doubles again.

Well, I’ve kept it simple: each option is an ‘either-or’ choice from 2 options. And all options can be combined with each other. In practice, this is often not the case: for example, there is a choice of several colors and some options cannot be combined. But this example makes it clear that the number of variants quickly explodes to a number that can hardly be calculated.

How does a modular product structure help manage all those variants? Well … actually…it doesn’t

… because any way you slice it, an option will work through on to the level of detail at which engineers work. For example, it may happen that what started as a simple customer request, and appeared to be only a small variation on a previous embodiment, turns out to have a significant impact on the design. And with that also on production, logistics and service, lead time, price, etc. ‘The devil is in the detail’ certainly applies to even the simplest looking technical products.

The fact that people are sometimes surprised by this is because the actual, complex product structure has not been mapped out at most companies. All LEGO bricks are, just like in the past, in our living room, scattered across the various departments. They are in 3D CAD designs, electrical schematics and software code.

But because these blocks are not tangible (just chunks of information), no one will be annoyed by the clutter or trip over it. Until … people do stumble over it.

“But doesn’t a modular product structure offer advantages?” Yes, but those benefits are different for everyone:

  • Sales: modules for providing choices to the customer
  • Logistics: modules for simplifying the material flow
  • Production: modules for parallel production and production outsourcing
  • Engineering: modules for reuse of solutions (and knowledge)
  • Service and maintenance: modules for fast interchangeability

A modular construction can hide the complexity, but it cannot reduce it.

Your engineers still need to know in detail how each module is structured and how they relate to each other. Only your most experienced employees will know what inter-dependencies there are and how these blocks can be combined; they are the master builders (in every company you will find a number of these heroes).

The only way to manage complexity is to make it transparent.

And that requires a multi-disciplinary, integrated approach. Call it Systems Engineering, Integrated Project Delivery, BIM, PLM … but you will have to describe what your product is, how it is built, which variants you sell or plan to sell.

To what level of detail should this be done? That depends on your ambitions: do you want to reuse knowledge and engineering solutions or are you satisfied with logistical advantages? Up to component level or are coarse modules sufficient? Modularity index 100% or 1%?

And don’t underestimate it: the product you have been making and selling for years turns out to be more complicated than you thought!

Next time we will highlight product structure and modularity from the different perspectives of sales, engineering, production and service.