techone --guide=erp-analysis
Process Analysis Before ERP Implementation
Before selecting and configuring ERP, describe the current processes, data, roles and exceptions. Current-state analysis and target design provide a basis for scope, budget and schedule.
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
- Start with discussions with key people, a systems overview and samples of real documents, workbooks and exports.
What the Current State Analysis 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 hand to colleagues.
It also captures informal steps: who resolves an exception, which record the team treats as authoritative and where the process depends on one person's knowledge. The structure needs to support both target design and implementation.
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
Side records, manual transfers and undocumented rules recur across analyses. Each one needs review so the target design can decide what to retain, change or remove.
Important Rules Remain in People's Heads
Specific people know permitted combinations, exceptions and escalation paths, but the rules are undocumented. Analysis records them and determines whether they belong in the system, a working procedure or training.
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
Some cases follow a different path with different documents, steps or rules. Recording them as process variants reduces the risk that they emerge only during testing.
Side records have outgrown their tables
A side workbook can become an important record for packaging, pallets or payments. Treat it as a separate requirement, then decide whether ERP, an add-on, an integration or a process change should cover it.
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 or TO-BE design. We write the process view so sales, logistics and finance users can validate their future work. Depending on scope, it is supplemented by a data model, integration design and technical specification.
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.
Each Data Item Has an Authoritative Source
Define the authoritative system for customers, items, prices, documents and statuses. It does not always have to be ERP; the design must state where a value originates and where it is sent.
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
Before development, decide what to retain, replace or simplify. The brief should cover process variants, responsibilities, data, integrations, open questions and acceptance criteria. A vendor can then prepare a more precise proposal and identify requirements outside its standard product.
The document can also support product and vendor comparison. Follow-up questions will remain, while everyone starts from the same description.
The Holík International process analysis produced documentation used as a brief for gradual implementation. For Lagardère, a five-month analytical project mapped EDI processes and data structures and produced an onboarding manual. The ERP integration service covers the following implementation work.
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. We schedule discussions around key people and complete part of the work from provided data and documentation. Analysis normally does not require operations to stop, although selected shifts or activities may need observation.
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, when the intended use and level of detail are agreed in advance. The document describes roles, processes, data flows, rules and the target state. A new vendor may still request product-specific additions or use its own methodology.
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