An operations owner requests a different order-release workflow. The proposed solution is a custom extension, but the approval request does not show whether the existing ERP can meet the requirement through configuration, whether the process itself should change, or who will maintain the extension after deployment.
Approve the business requirement before approving the implementation method. Customization is neither inherently wasteful nor inherently strategic. Authorize it when a documented operational need justifies the continuing obligations for ownership, interfaces, testing and support. Otherwise, adopt the standard process, configure available functionality or evaluate an external application.
This is a decision about an individual change request. If the investigation instead reveals that the platform cannot support fundamental business requirements, use the broader ERP improvement-versus-replacement framework before treating successive extensions as the answer.
Establish what the standard process cannot deliver
Start the request with an outcome, not a screen design. “Replicate the old approval screen” prescribes a solution. “Prevent release until the responsible operations owner has accepted the customer-specific handling requirement” states a business control that different designs could satisfy.
In a webinar on ERP digital sovereignty, the SoftEngine speakers reject blanket criticism of customization, arguing that complex processes may require individual adaptation. They also challenge the automatic reproduction of existing workflows: first establish whether a process remains necessary, then whether standard functionality can support it.
The implication for a change approver is to require a demonstration of the proposed standard alternative. Ask the functional consultant and process owner to run the actual business case, including exceptions. A convincing answer identifies the exact missing control or outcome. “Users prefer the old way” is not equivalent evidence, although a demonstrated usability problem that prevents reliable execution deserves consideration.
Record why the requirement matters: a contractual obligation, an operational constraint, a necessary control or a commercially important service capability. Not every justified change must differentiate the business. If the standard process meets the outcome, approve the process adjustment and user preparation rather than rebuilding familiar behavior. If it fails, document that failure narrowly enough to guide the next design decision.
Compare implementation routes against the same requirement
Use the same acceptance scenario for every option. Otherwise, a configuration demonstration may be judged against the full workflow while a custom prototype is accepted after showing only its most attractive feature. Treat the routes below as alternatives to investigate, not a universal ranking.
| Route | When to consider it | Evidence to request |
|---|---|---|
| Adopt the standard process | The outcome can be achieved by changing how people work. | A realistic workflow demonstration and process-owner acceptance of the differences. |
| Configure available functionality | Existing settings, rules or workflow features appear to meet the requirement. | The configuration design, its boundaries and applicable product support terms. |
| Integrate an external application | A separate application merits evaluation for the required capability. | Interface access, transaction ownership, exception handling and continuing commercial terms. |
| Authorize custom development | A material gap remains and the proposed extension has an acceptable lifecycle plan. | A bounded design, supported extension mechanism, maintenance owner and regression tests. |
Make terminology explicit in the proposal. Oracle’s ERP-ACE explanation describes configuration as using standard features to control application behavior and calls configuration “always upgrade safe.” Treat that as Oracle’s characterization, not a contractual guarantee for your installation or evidence that an integration receives the same protection. Ask which product, release, deployment model and mechanism the proposed change actually uses.
The enterprise transformation discussion makes a stronger architectural argument: avoid accumulating technical debt in non-differentiating areas and exercise care about where differentiation belongs. Its clean-core discussion uses SAP as the example and favors an application-oriented approach over additional custom code. For approval purposes, use that opinion to challenge unnecessary development, not to assume identical extension rules across ERP products.
An external application should face the same scrutiny as an internal extension. Ask why its capability warrants the additional interface, operating responsibilities and commercial dependency. Conversely, do not reject a bounded custom extension merely because another application exists. Compare complete designs against the same outcome.
Complete the change-approval worksheet
The following worksheet is an editorial decision aid, not a source-validated architecture standard. Attach it to the change request and assign an accountable person to unresolved items. Approval should describe the implementation and the continuing responsibilities being accepted.
| Approval question | Evidence to attach | Reason to pause |
|---|---|---|
| What outcome is unavailable in the standard process? | Business requirement, failed standard scenario and consequence of leaving the gap unresolved. | The justification only describes a preferred screen or historical habit. |
| Why this implementation route? | Comparison of process change, configuration, integration and custom development. | Alternatives were dismissed without testing the requirement. |
| Who owns the extension? | Business owner, technical maintainer, repository access and agreed use and modification rights. | Ownership means only knowing whom to call. |
| What interfaces and data does it need? | Interface inventory, access entitlements, permissions, transaction boundaries and applicable charges. | “An API exists” substitutes for checking the required operations. |
| How will updates be tested? | Regression scenarios, test environment, release responsibilities and recovery procedure. | Testing stops at installation or message delivery. |
| What continuing work must be funded? | Maintenance tasks, support responsibilities, testing effort and relevant recurring commercial items. | The estimate covers development alone. |
| What if the supplier or roadmap changes? | Handover deliverables, support alternatives, exit provisions and a retirement or replacement approach. | The plan depends on an uncommitted future feature or inaccessible supplier knowledge. |
Separate business ownership from technical maintenance. The process owner should accept what the change does and decide whether it remains necessary. The technical owner should account for its implementation, dependencies and support. Procurement or legal reviewers should confirm the relevant rights rather than infer them from possession of a code repository.
If responsibility is assigned to an implementation partner, verify who will perform the work and how handoffs will operate. That delivery-capacity question belongs in the implementation partner evaluation; the change request should record the agreed responsibilities rather than repeat the supplier-selection exercise.
Approve maintenance and acceptance, not just development
Ask for an ERP extension maintenance plan expressed as tasks and accountable roles before accepting a lifecycle estimate. Include investigation of relevant product changes, test maintenance, execution, defect resolution, deployment and operational support. Add hosting, interface or application charges where the proposed design requires them. Request the assumptions behind the estimate instead of applying an unsupported maintenance percentage.
Hypothetical evaluation scenario: an external application evaluates an order-release condition and returns an approval to the ERP. A successful message transfer is insufficient acceptance evidence. Ask the team to demonstrate that the correct order changes state, an unauthorized approval is rejected, and operations can identify what happened.
Then test failure and recovery: the external application approves but the ERP rejects the update; a response is delayed; an approval is submitted again; or the business cancels the order before completion. Require the design to state who detects each exception, who reconciles the business status and who authorizes recovery. These are proposed acceptance tests, not claims about a particular product’s behavior.
For updates, ask which tests must be rerun and who decides the change remains fit for use. “Upgrade compatible” is a weak answer without the applicable product policy and a test plan for the workflow. Narrow or defer approval if the team cannot establish the supported mechanism, update obligations or responsibility for remediation.
Test dependency before authorizing the change
In the SAP-focused transformation discussion, a participant urges customers to press for the APIs they need, including access for working with other vendors. The useful change-level implication is specific: verify access to the operations and data your design requires before approving an integration. Do not equate a general platform-access statement with entitlement to every required interface.
Run a disruption exercise against the proposed extension. Ask what happens if the maintainer becomes unavailable, a required interface changes, commercial terms become unacceptable or a roadmap feature is withdrawn. Require the team to distinguish what the organization can operate, modify, replace or retire from what remains dependent on another party.
For a custom extension, request an inspectable repository, build and deployment instructions, dependency documentation, test assets and confirmation of the relevant rights. For an external application, examine data export, interface terms, configuration documentation and exit assistance. These are provisions to negotiate and verify, not rights to assume.
Before approving the next change, complete the worksheet with the process owner and technical maintainer, then resolve the missing evidence that could change the implementation choice. Approve the route whose business value justifies its explicit obligations, not simply the route with the most persuasive demonstration.
If you need functional or technical help evaluating that requirement, talk with Digiventi’s ERP specialists about the configuration, integration or development work under consideration.
