Assessing ERP requests: standard process or customisation?

A prospect shows you a familiar screen: “We need it like this again.” It may embody an important business requirement. Alternatively, a particular interaction may have become familiar over the years while another route could deliver the desired result. For your ERP proposal, make a shared decision about each significant deviation. You help the customer consciously preserve useful experience and assess the options your actual solution offers. Customisation becomes a justified service with a recognisable purpose.

This guide is for ERP providers and implementation partners deciding whether to address a request through a confirmed standard workflow, a checked setting, an additional solution or custom development. Investigate your product’s actual capabilities yourself; these categories promise no features. Every case is explicitly fictional. The goal is a traceable proposal decision about one deviation, rather than another general demonstration or a blanket preference for more or fewer changes.

Translate the request into a work result

First ask the customer to explain the benefit of the current solution. What can an employee decide or complete with it? Ask about the step before the result and the task afterwards. In a fictional case, an extra column shows whether an order needs clarification before processing. The actual need is a visible clarification requirement. Whether the new ERP needs the same column remains open. This respects existing experience while allowing an appropriate new implementation.

Record the result in a sentence the customer can confirm, including who needs the information and when. “Order processing recognises an open clarification item before approval” is a more useful assessment task than “rebuild the old view”. Keep the original request alongside it so the connection remains apparent. Your contact should see that you take the need seriously and understand the existing working method before asking them to consider an alternative.

Investigate the actual standard workflow

With a responsible specialist, examine how your current solution delivers that result. Use the relevant version and appropriate documentation. A memory of a similar feature is insufficient for a proposal. Establish the user’s steps and prerequisites. Leave unconfirmed features explicitly open. The customer needs a dependable comparison between the request and an existing option, rather than a guess about the product.

Discuss the standard route in the same work situation as the original request. Can the responsible person recognise the issue in time and perform the next step correctly? Include infrequent but important cases. An extra view may be unnecessary if the confirmed standard achieves the result understandably. If something essential is genuinely missing, describe that gap specifically. Compare equal results, rather than counting interface elements.

Separate settings, additions and custom development

Classify a possible solution after specialist review. An existing setting differs from an extension supplied by another provider or bespoke development. Ask who supplies each option and who takes responsibility for it in your proposal. State actual prerequisites. “Configurable” alone does not explain whether the customer maintains the change, your consultants set it up or another company must supply services.

Be specific about an additional solution too. What task would it perform, what remains in the ERP, and who investigates how they work together? A product name alone is not a validated offer. Mark options still requiring investigation as open. The customer can distinguish established choices from those depending on review. Do not invent licence terms, compatibility, prices or automatically available add-ons to make the comparison appear complete.

Distinguish necessary deviations from preferred interaction

Respectfully ask what would happen if the customer used the confirmed standard. Would the business result be incomplete, would an essential decision be missing, or would mainly familiar interaction change? Both matter but do not necessarily lead to the same service. A changed working method may need preparation and practice; a genuine gap needs a decision about the missing result. Do not equate relearning with impossibility or dismiss it without examination.

Ask affected employees to explain using an invented case. Which action changes, what information stays visible, and where does extra work arise? Document the observed difference without invented time savings or error rates. If the business team accepts a changed workflow, record the scope of that agreement. If it declines, ask the specific reason. Your team can distinguish a justified special requirement from an alternative that has not yet been understood and choose the next step accordingly.

Follow consequences into the adjacent workflow

A requested change may affect information other employees use. Ask who continues working on the same transaction afterwards. In the fictional case, a clarification marker must not mean something different when the order reaches the warehouse. Examine its meaning there. A local improvement is fully described only when the affected neighbouring workflow and responsibility for unresolved questions have been considered.

Discuss who will assess later changes to the requested behaviour. A department may maintain mapping content while your team handles technical changes. Distinguish those tasks in the proposal so the customer can plan ongoing use. Include statements about future product updates only where your business can genuinely confirm them for the specific solution. The existence of custom code does not promise lasting maintenance or unrestricted compatibility.

Agree an observable assessment result

Before the proposal decision, describe a case for assessing the desired effect. A fictional order receives an open clarification item. The responsible person must recognise it before approval and take the agreed next step. Include a counterexample without an issue so the planned solution’s distinction is understandable. Technical implementation remains subject to specialist assessment; the case initially describes the desired state, not an existing capability.

Assign assessment to the appropriate customer role. Daily users can judge clarity; another person may decide additional scope. Both judgements are separately needed when different people hold those responsibilities. Record what is answered and what remains open. Positive feedback on a sketch replaces neither testing the later result nor commissioning development. The proposal can state this clearly while recognising progress already made.

Present alternatives as a usable decision

Set out the viable routes: confirmed standard, investigated customisation or an unresolved addition. For each, describe the result, necessary participation and genuinely known limits. Keep unknown effort unknown rather than supplying a precise-looking number. If your company offers separate analysis, explain its concrete result. The customer can choose a defined route or first commission investigation of the unresolved option.

Avoid a summary presenting all wishes uniformly as “included”. A confirmed standard case and unchecked development have different foundations. Show the difference in scope and record the decision for each important request, including deferred deviations. Later additions remain possible but are new decisions. The original agreement stays understandable even when further discussions create additional requirements or different priorities.

Record a reasoned customisation decision

The fictional note might conclude: “Make clarification visible before approval; standard route reviewed by specialists; preferred old column unnecessary; changed workflow confirmed with responsible business team.” In another case, an essential gap remains. The note then states the missing result, planned investigation and person deciding customisation afterwards. Both are useful outcomes. Sales obtains a justified next action instead of immediately selling development for every difference or rejecting every special need.

Handle new requests during clarification deliberately

A second request can sound similar while requiring a different decision. In the fictional case, the marker should now also block processing automatically. This goes beyond visible information. Ask who could release the block and what happens if marking was mistaken. Describe this request separately so the customer recognises an additional effect rather than a small redesign of the same view.

Also examine what happens when the clarification item is later resolved. Which action becomes permitted, and how does the next role learn about the changed state? If you cannot answer together, leave that part open. The already confirmed visible marker need not be discussed again from scratch. Your proposal can preserve the established service and identify the added blocking logic as scope requiring separate investigation.

Finally check whether the decision note still describes the current request. Previous approval for a display does not automatically extend to a new automatic effect. Ask for targeted confirmation of the changed part while retaining the other statements. It remains clear what was established and what was newly decided. Your team can proceed without treating an unintended extension as originally commissioned standard scope.

Source context

Microsoft describes fit-to-standard and fit-gap analysis for Dynamics 365 as separate steps for assessing processes and gaps. This source explains the method, not your product’s standard capabilities or a particular customisation effort.

Develop ERP enquiries through your consulting

ERP leads from webRichtung connect you with businesses in Germany seeking proposals. Process area, current systems, planning stage, location and contact details provide an introduction. You clarify special requirements and customisation yourself. Register your business and prepare the lead order in webRichtung Customer; the current price appears before a binding order.