Core and configuration

What this is for

As soon as a model is to be carried from one unit to several, the wrong question reliably comes first: does every unit get the same solution? It permits only two answers, and both are bad.

The usable question is: which elements have to be standardised, and where is local flexibility commercially sensible? This model is the structure I answer that question with.

The distinction

The core is what applies to everyone and is not negotiable. In practice it is almost always the same things: inventory structure, unique IDs, location data, roles and reporting principles. Precisely the elements that can hardly be unified retroactively, because otherwise each unit establishes its own conventions.

The configuration is everything that may be decided locally: commercialisation route, expansion stage, pace, organisational shape. Here local market reality applies, not group logic.

Choosing what goes into the core is the central decision of the entire effort. Everything included becomes mandatory for every unit — and everything left out is practically impossible to add later.

The two failure patterns

Too much in the core. The standard is complete, correct, and formally accepted by the smaller units while being circumvented in practice. Recognisable when exception requests become the norm.

Too little in the core. Every unit redefines the foundations. Faster in the short term, expensive in the medium term: group-wide analysis becomes impossible because the same terms mean different things.

The entry stage

A blueprint needs a smallest sensible expansion stage. A complete target picture without an entry point gets ignored by exactly the units that would need it most — because from where they stand it describes a project they cannot afford.

Completeness and accessibility are in direct conflict here. You do not resolve that conflict, you decide it.

The corresponding case is written up as the case study on multi-brand scaling.