SAP Taught Me That Configuration Is Not Customization

In SAP consulting, there is a fundamental distinction that shapes every project decision: configuration versus customization. Configuration uses the system's built-in options to match business needs. Customization means writing custom code to extend the system beyond its intended design. The cost difference between these two is staggering.

I once worked on a project where a stakeholder insisted on a custom approval workflow because the standard one did not match their exact process. The customization took three months, cost six figures, and broke during every system upgrade for the next two years. If they had adjusted their process slightly to fit the standard configuration, it would have taken two weeks.

Why This Matters Beyond ERP

This principle applies everywhere. When your team is building on top of Salesforce, Shopify, AWS, or any platform, the first question should always be: can we solve this with configuration? Plugins, settings, integrations, and standard workflows exist for a reason. They are tested, maintained, and upgraded by the vendor.

Custom code is a liability. It has to be maintained. It has to be tested during upgrades. It has to be documented. Every line of custom code is a line your team owns forever.

The PM's Role

As a PM, I push back on customization requests that do not have a clear business justification. "We have always done it this way" is not a justification. "This process is a regulatory requirement that cannot be modified" is.

The conversation is not about being rigid. It is about making the cost explicit. When a stakeholder understands that their custom workflow will add three months and ongoing maintenance burden, they often discover that the standard configuration is acceptable after all.

This is one of the most valuable lessons from my consulting years. Every project has moments where you choose between adapting the process to fit the tool or adapting the tool to fit the process. Choose wisely.