techone --guide=erp-analysis
Process Analysis Before ERP Implementation
Process analysis turns current workflows, data, roles, and exceptions into decisions about the target solution. The resulting brief supports option comparison, delivery scope, and implementation planning.
TL;DR
- Purpose of the analysis
- Connect the reason for change with actual operations and identify decisions required before ERP selection or implementation.
- Current state
- Roles, responsibilities, document flows, data transfers, process variants, integrations, and operational constraints.
- Target design
- Future work by role, changes from today, data sources, system boundaries, and scenarios for validating the solution.
- Main output
- A brief for comparing options, defining delivery scope, preparing proposals, and supporting implementation.
- What to prepare
- Time with operational staff, a systems overview, and samples of real documents, workbooks, exports, and exceptions.
What the Analysis Should Decide
Process analysis connects the reason for change with how the company actually operates. Recording today's procedures or collecting wish lists from departments is not enough. The work must identify what the new system should retain, what should change, and which questions remain open for product selection or delivery design.
The current state reveals roles, data, dependencies, and constraints. Target design adds decisions about the future process, ownership, and system boundaries. Together they form a brief that supports option comparison and implementation scope.
The required depth depends on how the output will be used. An initial ERP comparison needs less detail than an implementation with a selected product. Agree on the purpose at the start.
What the Current State Captures
A current-state or AS-IS analysis describes how an order, job, or document actually moves through the company. It compares formal procedures with what people enter in systems, maintain in side records, and pass to colleagues.
Roles and responsibilities
Who starts the process, makes decisions, picks up the case, and confirms completion. The analysis captures real operational roles rather than relying only on the organization chart.
Connected process areas
Sales, purchasing, logistics, warehouse, manufacturing, and finance are described as one flow. Each area shows where the process starts, what it receives, and how it ends.
Data transfers
For each important value, record who creates it, where it originates, where it moves, and who reviews it. Manual re-entry becomes a visible part of the process.
Rules and variants
The normal flow is supplemented by different order types, exceptions, approvals, and rules known only to certain people. The analysis separates them and establishes their importance for target design.
Integration points
For automated and manual flows, document the source, destination, frequency, ownership, and error procedure. This supports decisions about future integrations.
Operational constraints
Record close deadlines, staff availability, shift dependencies, traceability requirements, and other conditions that the design and transition must respect.
Inputs come from the people who perform the work and samples of real records. Formal procedures help, but they do not show every working variation.
What the Analysis Often Reveals
A side record or informal step is not automatically a mistake. Target design still needs a decision on whether its purpose remains, moves into a system, or disappears with a process change.
Rules depend on specific people
Certain employees know the permitted combinations, exceptions, and escalation path, but the rules are undocumented. Decide what the system should enforce, what belongs in a procedure, and what requires training.
The same data is created several times
A value is entered into a shared workbook, ERP, and other tools. The analysis identifies the authoritative source, required recipients, and whether integration or a change in ownership should replace the transfer.
Some cases use a different process
A customer, product, or delivery type may need different documents and controls. Target design must decide whether to standardize the variants or support them separately.
A side record has taken on an operational role
A workbook for packaging, pallets, prices, or payments can become essential to operations. Treat it as a requirement, then decide whether ERP, an application, integration, or a new procedure should own it.
What Target Solution Design Looks Like
Target or TO-BE design describes future operations so people in each role and the system vendor can validate them. Depending on its purpose, it may include a data model, integration design, technical specification, or a map of workspaces and screens.
Work and ownership by role
Each role can see what it enters, reviews, decides, and hands over. Future work can be walked through using a concrete scenario.
Changes from today
For each area, state what remains, what is simplified, and what is replaced. The change can be prepared and explained to users before go-live.
Data sources and system boundaries
Define the authoritative system for customers, items, prices, documents, and statuses. The design states where a value originates, where it goes, and who owns its accuracy.
Scenarios, questions, and acceptance
Important processes and exceptions become validation scenarios. Open questions have an owner and decision date, and the acceptance method is known before delivery.
How the Analysis Runs
Scope and format vary by project, but the work follows a similar sequence. First clarify the purpose, then examine actual operations, make target decisions, and prepare the output for its agreed use.
Define purpose and scope
Identify the reason for change, process areas, participating roles, and whether the output supports selection, a proposal, or implementation planning.
Review actual operations
With people from each role, examine documents, workbooks, exports, current systems, normal scenarios, and cases handled differently.
Design the target state
Describe the future process, ownership, data sources, integrations, changes from today, and decisions that still need to be made.
Validate and hand over the brief
Process owners review target scenarios, confirm data meaning, and address open points. The output is prepared for the agreed next step.
The Brief for Selection and Implementation
The brief should cover process variants, responsibilities, data, integrations, open questions, dependencies, and acceptance. A vendor can then prepare a proposal against the actual operation and identify requirements outside its standard product.
The same document can support product and vendor comparison. Follow-up questions remain, but everyone starts from the same description of the processes and expected result.
The Holík International manufacturing analysis produced a digitization plan and documentation for decisions about phased implementation. For Lagardère, we spent five months mapping EDI processes and data structures and preparing a supplier onboarding manual.
If the decision points to a new Dynamics 365 Business Central environment, our Dynamics 365 Business Central implementation service can follow. Development or connection of the existing environment may lead to ERP integration. The analysis may also show that an option needs further validation before selection.
Frequently Asked Questions
What will you need from us at the start?
We need time with key operational staff, an overview of the systems in use, and samples of working materials: spreadsheets, exports, example documents, and important exceptions. Formal procedures help but are not required to begin.
Can the analysis run during normal operations?
Yes. We schedule discussions around staff availability and complete part of the work from provided materials. Analysis does not usually require operations to stop, although observing a selected shift or activity can be useful for some processes.
What if we are already selecting an ERP?
Analysis turns actual processes and exceptions into shared scenarios for vendors. You can then compare proposals against your own operations instead of different demonstrations prepared by each vendor.
Can another implementation partner use the output?
Yes, when this intended use is agreed in advance. The documentation describes roles, processes, data, integrations, and the target state. The selected implementation partner may request additions for its product and method.
How does process analysis differ from an IT audit?
An IT audit evaluates infrastructure, security, and the state of technology. Process analysis describes how the company works, how data moves, and which rules guide decisions. Its output supports a process or system change.
Related Topics
From Excel to ERP
How to recognise when spreadsheets no longer support operations and what a new system should take over.
When Dynamics 365 Business Central Is a Good Fit
How to assess ERP fit across processes, data, integrations, customisation, and the operating model.
Dynamics 365 Business Central Implementation
From process and data analysis through migration and integrations to launch and support.
Prepare the Brief for Your ERP.
In the initial conversation, we review the reason for change, process areas, current systems, and available materials. This defines the analysis scope and how its output will support selection or implementation.
Discuss ERP Analysis