Every plant says it's special. Build all of it and you end up with one system per plant

Every plant that rolls out a system has a few “we’re different” items: print the documents in our format, receive this material by the bundle, we have a third-party warehouse.

Build them in one by one and each looks reasonable on its own. Later on, the same product looks different in every plant, upgrades don’t merge, and support needs its own people. The fix is to ask one question first: can the standard functions be configured to do this? Only what can’t be configured counts as customization; whatever counts gets listed at kickoff and signed off by the project team and the business.

This post covers four things: the six most common kinds of customization, how to tell whether a request is custom, what happens when there’s too much of it, and how to keep it in check.

1. The six most common kinds of customization, and printer drivers are the easiest to miss

The customization we run into falls mostly into these:

• Documents and print formats: labels, delivery notes, handover sheets; every plant wants its own format, fields and barcode position
• Special material handling: steel plate that needs length, width and batch number recorded, or material received by the bundle with a quantity per bundle
• Plant-specific processes: a third-party warehouse, VMI, repacking; steps the standard flow doesn’t have
• Reports and dashboards: each plant’s managers watch different metrics, measured differently
• This plant’s own equipment and systems: the automated storage, AGVs and surrounding systems here have different interfaces from other plants
• Drivers for different printers: the easiest to overlook. Print the same label on a different brand or model of printer and it needs its own adaptation

Everyone thinks of the first few. The last one usually turns up on site, when the labels won’t print.

2. If standard functions can be configured to do it, it isn’t customization

We use two tests:

• It sits outside the system’s standard functions: the standard product doesn’t have it, so it needs separate development
• It comes from the business’s own special requirements: only this plant or this workshop wants it, and other plants have no use for it

Put the other way round: anything standard functions can be configured to do isn’t customization; it’s solved by configuration. So when a “we’re different” arrives, ask first: can the standard functions be configured for this? Only if they can’t does it go into the customization process.

An example: the business says “this material has to go to its own storage area.” It sounds custom, but the standard putaway rules can already be set by the material’s storage zone, by pallet type or by a fixed location; one rule solves it. Real customization is something the standard product simply doesn’t have, such as receiving by the bundle with a quantity per bundle.

3. Too much customization: the product can’t stay standard, and it ends in dedicated support

One or two customizations are nothing. Once there are many, the problems show up:

• The product can’t stay standard: the same system runs a different version in every plant
• Upgrades and fixes are done plant by plant: when the standard product fixes a problem or adds a function, every plant with customizations has to be checked separately, and anything that doesn’t merge gets changed separately
• In the worst case, it needs dedicated support: only people who know this plant’s customizations can maintain its system, so it needs its own people

At that point the original benefit, “roll out one platform and copy it”, is gone. You end with one system per plant and one support team per plant.

4. Three rules for customization: agree it upfront, keep it out of shared configuration, both sides sign

First, agree it in the project upfront. The project states clearly which items are custom and how far they go. The post on project kickoff said every line in the function list is marked “reuse” or “modify”; customization is the same, marked separately and listed at kickoff, not appearing halfway through development.

Second, keep it out of the shared configuration. Custom functions don’t go into the platform’s shared configuration. A customization belongs to this plant; mix it into shared configuration and every other plant’s upgrade gets dragged along with it.

Third, the project team and the business approve and sign. Every custom function is approved and signed off by both the project team and the business. Like the blueprint and changes, only what’s signed counts. Customization that appears outside what was agreed goes through the change process described earlier: assess it first, then schedule it, and it doesn’t go straight into development.

---

Does your system keep a separate list of customizations?