techone --guide=erp-analysis
Process Analysis Before ERP Implementation
ERP projects overrun when implementation starts before anyone understands how the company actually works. A current state analysis and a target design give the implementation its brief.
TL;DR
- Who this guide is for
- Companies preparing a new ERP or replacing an old one that want the implementation built on real processes.
- What it covers
- Why implementing without analysis backfires, what a current state analysis captures, and how the target design is written.
- What the analysis captures
- Roles and who really does what, data flows and manual re-entry between systems, process variants, operational limits.
- Main output
- An implementation brief: the target state described per role, readable for operations people and for the system vendor.
- How to start
- Interviews with key people plus samples of working records. The rest we pick up from interviews during normal operations.
What the Current State Analysis Captures
A current state analysis (AS-IS in project language) describes how the company handles an order or a document today. Not by the rulebook. By what people actually do, what they click through and what they forward to each other. The document has a fixed structure that the implementation later uses as a map.
Company and role context
Who takes part in the process and what they own. Real roles instead of an org chart: who receives the order, who develops it, who closes it.
Process areas
Sales, logistics, finance and warehouse as one connected flow. Each area shows where the process starts, who picks it up and how it ends.
Data transfers between roles and systems
A transfer table: who creates a value, where they record it and who re-enters it next. This is where most of the manual work hides.
Process characteristics
What holds the process together: habits, personal knowledge of the rules, side records. Characteristics the new system must respect or deliberately replace.
Integration points
What already flows between systems automatically and what moves by hand. This defines the scope of future integrations.
Operational limits
Where the current state hits a wall: traceability of changes, dependence on specific people, missing checks at order entry.
What the Analysis Typically Reveals
Every company is different, yet the patterns repeat. These are the findings we see in analysis after analysis.
The biggest asset is rarely the software
Operational know-how lives in the heads of specific people: what can be combined, when an exception applies, who needs to know. The system enforces none of it. The analysis writes these rules down so the implementation can turn them into checks and code lists.
The same value is re-entered several times
One piece of information is entered by hand into a shared spreadsheet, into the ERP and into other tools. That keeps operations flexible. It also raises the error rate and makes it hard to trace who changed what and why.
Parallel branches run on habit
Part of the cases follow a different path: different documents, different steps, different rules. The analysis records them as process variants rather than exceptions, so nothing surprises the project later.
Side records have outgrown their tables
A spreadsheet that once started on the side has grown into a system of its own. Packaging and pallets or payment tracking are typical examples. In the target design they deserve a full module, more than a note on an invoice.
Changes arrive until the last moment
Logistics keeps shifting right up to dispatch: dates, carriers, delivery addresses. That is why the target system needs a change log with author and time instead of silently overwritten values.
Decision logic sits outside the systems
Checks such as load limits, allowed product combinations or a customer credit limit happen in people's heads today. The analysis lists them as rules the future system should enforce at order entry.
Target Design Written as a User Guide
The second part of the output is the target design (TO-BE). It takes the form of a user guide rather than a data model or a technical specification: what the day of a sales rep, a logistics planner, an accountant and a customer looks like after the change. People from operations read it and recognize their own work. That is the fastest way to find holes in the design before development starts.
Procedures per role
Each role gets its own chapter: what they see, what they enter, when they hand the case over. Users can picture their day without reading a database schema.
Screen map
A list of screens with who uses each one and for what. The map shows that every role has a working place in the new system.
Data created in one place
Customers, items, prices, documents and statuses have one place in the ERP where they originate. Other tools display them and never rewrite them. Arguments about which copy is valid end there.
What changes against today
For every area the design states what stays, what gets replaced and what gets simplified. The change can be planned and explained to people before it arrives.
The Implementation Brief
The biggest saving comes from decisions made up front. What to keep, what to replace, what to simplify: that gets decided over a document, before development is running. Process variants and outgrown side records are known in advance, so they never show up as a surprise during testing. And the document stands on its own. It works as the implementation brief regardless of who ends up implementing.
This is how it looks in practice: the production process analysis for Holík International produced documentation the company uses as the brief for gradual implementation. For Lagardère we mapped processes and data structures for EDI communication; the client now onboards suppliers on their own using the resulting manual. For how implementation follows the analysis, see our ERP integration service.
Frequently Asked Questions
What will you need from us at the start?
Three things. Time with your key people, typically in short interview blocks. Samples of working records: shared spreadsheets, system exports, example documents. And an overview of the systems in use and who works in them. Formal guidelines help but aren't required.
Can the analysis run during normal operations?
Yes, that is the only way we do it. Interviews run in blocks scheduled around your people, and the rest of the work happens over data samples on our side. The company keeps taking orders and shipping throughout the analysis.
What if we are already selecting an ERP?
The analysis helps the selection. Requirements come from real processes, so you compare vendor offers against your own operations rather than a demo catalog. And the process variants the analysis captures are exactly the questions a vendor should answer before you sign.
Is the output usable if someone else implements?
Yes. The documentation is written as an implementation brief and stands on its own: roles, processes, data flows, rules and the target design. Any system vendor can build a quote and a project from it.
How does a process analysis differ from an IT audit?
An IT audit evaluates infrastructure, security and the state of your technology. A process analysis describes how the company works: roles, data flows and the rules behind decisions. The audit tells you what shape your IT is in. The analysis tells you what the new system must do.
Planning a new ERP?
We'll walk through your operations and tell you what an analysis would capture for you.
Book a consultation