Quoting an ERP rollout: phases or a shared switchover?

A business wants to use its new ERP at one site first. That sounds manageable. For your proposal, however, establish what that site can do independently and which transactions depend on other departments. A small geographical scope can contain a substantial business transition. Together you can assess whether a phase delivers a complete usable workflow or certain departments must change together. You help the customer decide a sequence through actual work.

This guide is for ERP providers and implementation partners defining the rollout boundary before quoting. It supports choosing between viable phases and a shared change for specific departments. It is neither a finished go-live plan nor technical approval. All examples are explicitly fictional. Features, dates and support services need checking for the actual solution. These questions belong to your consulting; an ERP enquiry does not automatically contain a rollout plan or the decisions and owners needed here.

Describe the smallest fully operational unit

Start with a business process that should work completely after the first change. In the fictional example, one site should process orders and coordinate execution. Ask where an order is accepted, who releases it for processing and who establishes completion. The first unit is connected work rather than simply user accounts. Record the beginning and end so the customer can judge a phase’s usability concretely.

Check whether all required roles belong to that unit. If central order intake stays in the previous system, the workflow crosses a boundary. How does the new site receive orders and how does the central team learn their status? This does not yet select a particular interface. First expose the shared work the phase requires. Only then can you assess whether the proposed boundary is genuinely smaller and manageable.

Map transitions between old and new working methods

Collect every point where the first unit works with departments not yet switched. Consider central product maintenance, internal stock movements and shared customer service where they actually exist. What information does each side need and who owns the complete transaction? Describe dependencies in clear prose or a simple sketch. The customer should see additional transitional work and which existing tasks remain shared.

Follow one transaction using both methods during transition. A fictional order is received centrally and fulfilled at the first site. Where is a later change recorded and who informs the other side? If teams could use different versions, agree a clear business rule before quoting. Do not invent automatic synchronisation. Identify the handover requiring assessment, its decision-maker and whether investigation belongs in your proposed scope.

Compare business and geographical phases

A phase may follow a site, business division or connected workflow. Assess only against the real organisation. A site boundary may fit largely independent work; a process boundary may suit one central process connecting all sites. Neither is universally better. What matters is whether the first unit can finish its task with clear responsibility and what extra transitions would need creating or temporarily performing.

Ask for two genuinely possible boundaries. Compare more than participant numbers: examine shared information, ongoing orders and downstream work. Central intake might belong in phase one despite being elsewhere. An independent department might continue with its existing method. Record reasons for the choice so employees absent from the decision can understand the sequence too.

Give a pilot a specific learning question

If the customer wants a pilot, ask its purpose. Which uncertainty should the first unit reduce for later rollout? It might reveal whether the intended roles understand and execute an agreed process together. A pilot does not succeed merely because users opened the system. Describe the observation and participants. The customer can assess the knowledge this extra phase should deliver and whether its effort is justified.

Check what later characteristics the pilot does not represent. An independent site may not examine cross-site cooperation; a simple order cannot answer every question about a multipart transaction. State those limits. Success in one case does not automatically establish suitability for later departments. They can use the learning but must examine their additional workflows separately. The pilot remains a specific decision aid rather than blanket project approval.

Treat transitional work as separate scope

Phased rollout may require temporary tasks. Ask who performs the handovers, how long they are needed for the business and what shows they can end. A manually agreed interim status differs from a permanent process. Have responsible specialists assess any interim arrangement’s actual feasibility. State included transition services and customer contributions. Hidden extra work makes a phase smaller only on paper.

Consider ordinary daily operation too. Who handles questions when the responsible person is occupied elsewhere, and what does a substitute need to know? One employee improvising once does not define a workflow. Record responsibilities and the next clarification route. Do not promise response times your company does not actually offer. The customer needs to know what support it must arrange and what your team will provide.

Assess readiness through real tasks

Agree how the customer recognises that a unit can start with the planned scope. The roles must perform the defined tasks with checked prerequisites. Ask about documents, work instructions and responsible contacts. Leave unconfirmed prerequisites open. A calendar date alone does not establish readiness. For your proposal, first identify necessary results and owners; participants then assess timing against the state actually achievable.

Walk through a typical question after launch. Who receives it, assesses its business significance and decides the next action? Separate the customer’s business decision from technical investigation by your team. Describe support according to real services. A first phase needs a transition to ongoing support just like a shared switchover. Smaller scope does not remove this task, but can limit it to the actual roles and cases.

Examine when a shared change is needed

If a central workflow cannot sensibly be split between old and new methods, investigate switching affected departments together. This does not automatically mean the entire business. Which departments are inseparable and which remain independent? The shared boundary receives a business justification. The customer sees why roles should start together rather than adopting a large switchover from a general preference for one project model.

Compare both routes’ unresolved prerequisites. A phase with an undefined handover is not viable merely because fewer people participate. A shared date does not establish readiness either. Identify each question and its necessary assessment. If the basis is missing, offer bounded clarification if your business genuinely provides it. Describe its result without promising a fixed launch date or trouble-free change.

Secure the decision before the next phase

Summarise the sequence so the customer recognises the first unit, its handovers and prerequisites for the next step. State what learning is needed from a pilot and who assesses it. Another phase does not begin merely because it appears in a plan. Participants need to know relevant results and open questions. Record the decision and owner without imposing universal, immutable approval criteria on every ERP project.

If the organisation changes later, re-examine the affected boundary specifically. An additional centrally performed task may reconnect a previously independent unit with other departments. Preserve valid pilot learning while investigating the new dependency separately. Your proposal builds on a traceable state. Sales obtains a reasoned next action: offer a particular sequence or first clarify a specifically identified dependency with the responsible people.

Address an unresolved pilot finding precisely

In the fictional pilot the site performs its work, but central intake cannot yet reliably associate a change. Define the finding precisely: the affected points are change handover and business confirmation, not every site task. Who clarifies the missing association and how do both roles assess the corrected workflow together? The next step targets the actual dependency.

Other confirmed tasks need not become “unknown” or be investigated again in full. Record what worked unchanged and which statement is missing. If a proposed change affects further roles, involve those specific roles. Decide the next phase using the relevant result. The customer receives usable progress: established work remains, while one transition question needs resolution by a named owner. The finding can also support a focused change to the rollout boundary if the original separation proves unworkable.

Source context

Microsoft’s Dynamics 365 go-live guidance treats readiness and planned support as separate topics. This manufacturer context replaces neither assessment of your solution nor a decision about the specific rollout boundary.

Turn new ERP enquiries into suitable projects

ERP leads from webRichtung connect you with businesses in Germany seeking proposals. Process area, current systems, planning stage, location and contact details provide the starting point. You clarify the rollout sequence yourself. Register your business and prepare the lead order in webRichtung Customer; you see the current price before a binding order.