Configuration Management
Configuration management in the ERP context describes the discipline of managing system configuration as controlled, version-tracked artefacts that move through environments (development to test to production) under governance. Without configuration management, individual changes accumulate inconsistently across the landscape, environments drift apart, and the operational integrity of the ERP erodes. Mature configuration management is one of the highest-leverage investments in operational ERP stewardship.
What configuration management covers
- Master-data setup — charts of accounts, cost centres, company codes, currency definitions, tax codes
- Process configuration — approval workflows, document-type rules, output formats
- Pricing configuration — discount schemes, rebate agreements, condition tables
- Reports and forms — layouts, filters, output destinations
- Customisation objects — custom fields, custom tables, user-exit code
- Integration definitions — interface mappings, partner profiles, EDI configurations
- Security roles — authorisation objects, role assignments, segregation-of-duty rules
Transport management
The classical ERP approach to configuration management is the transport request — a packaged collection of configuration changes that moves through environments. SAP Transport Management System (STMS) is the canonical example, but Microsoft Dynamics 365 F&O has a similar Configuration and Data Management framework, NetSuite uses SuiteBundles, and most mature ERPs offer transport-equivalent mechanisms. The standard promotion path: DEV (changes built and unit tested) → TEST (user-acceptance testing) → PROD (live system). Each transport request carries an audit trail of who created it, what objects are included, who approved its promotion. Larger projects add additional environments (integration test, training, pre-production) with appropriate transport routing.
Governance disciplines
Configuration governance covers four areas. (1) Change-request management: every configuration change starts as a request with business justification, impact assessment, testing plan and rollback plan. Approval by change-advisory-board or equivalent before development starts. (2) Environment separation: no direct configuration changes in production. All changes flow through the transport process. (3) Documentation: configuration decisions documented with rationale, not just what was changed but why. Knowledge transfer depends on this. (4) Periodic review: quarterly review of accumulated changes, identification of consolidation or retirement candidates, alignment checks against current business needs. Discipline tends to slip during pressure periods; periodic review surfaces drift before it compounds.
Modern practices in cloud ERP
Cloud ERP changes configuration-management patterns. Continuous delivery: cloud ERPs receive vendor updates on fixed cadence (typically quarterly); customer-side configurations must be tested against incoming updates. Configuration as code: modern platforms expose configuration via APIs, allowing version control in Git with peer review (GitHub Pull Requests for ERP configuration). Automated testing: regression tests run against each configuration change before promotion to production. Reduced custom code: clean-core principles (see customising) reduce configuration complexity by preferring vendor-standard behaviour. Mature cloud-ERP operations resemble software-engineering practices (CI/CD, infrastructure-as-code) rather than the classical IT-operations model.
Related Topics
Frequently Asked Questions
How strict should transport-management discipline be?
For production-impacting systems, very strict — no exceptions, no 'quick fixes' in production. Every change flows through the transport process with proper approval and testing. For sandboxes and development environments, looser rules are appropriate to support exploration and learning.
Can we automate configuration testing?
Increasingly yes. Tools like Tricentis Tosca, Worksoft, Eggplant Test and Selenium-based frameworks can automate functional testing of ERP changes. Modern cloud ERPs (Microsoft Dynamics 365, SAP S/4HANA Cloud) include built-in test-automation capabilities. Investment payback varies; manufacturers with complex regulated processes see strong ROI on test automation.
What is the right cadence for configuration deployments?
Mid-market mature operations typically deploy major configurations monthly with smaller hotfixes weekly. Larger operations move toward continuous deployment patterns adapted from software engineering. Less mature operations sometimes accumulate weeks of changes into large deployments, which carries higher risk and slower feedback.