Why is process analysis needed before starting an ERP project?

Everything works smoothly in an ERP demo; the catch is that the company in the demo is not your company. Process analysis is the work of mapping, step by step, how things actually run from order to collection before you move to any software. Whether an ERP project goes well often depends on the quality of this work.

In this article we explain why the analysis should not be skipped, what is mapped in it and which documents you should have in hand at the end. We look at it through the principles of YazSis ERP, which we build as an architecture adapted to the business.

What happens if the analysis is skipped?

The software is installed, the screens open, everyone logs in. A few weeks later some employees go back to their old habits. That is because the software was built around how the work is described on paper, not how it actually runs. The four problems below are the most common results.

• The scope drifts: “Let’s add this too” requests pile up mid-project, the schedule stretches and it becomes a debate which items belong in the first phase.
• Double entry begins: Work that has no counterpart in the system is still done in Excel; the two records drift apart over time and it becomes unclear which one is correct.
• Users push back: Instead of making the user’s job easier, a screen makes them fill in extra fields. The software then comes to be seen as an additional burden.
• Responsibility stays unclear: Who gives the approval and who decides the exception become questions argued about after go-live, although these decisions could have been made at the start of the project.

Five steps in process analysis

1. Draw the flow as it is. Write down who an order, a purchase and a stock movement pass through today, and with which tool. What matters is the flow that really happens, not the one that should happen.
2. Collect the exceptions. Returns, partial shipments, price differences and urgent orders, the “not normal” cases, can make up a large part of the daily work. Software struggles most in these cases, so they should be kept in a separate list.
3. Clarify approvals and authority. Above which amount who approves, who can give a discount, who can make a stock correction? These answers should be tied to roles, not to individuals.
4. List the data sources. Where are the customer list, the product card and the price list kept? Which one is current and who keeps it current? The places where the same information lives in more than one spot are the ones to be reduced to a single record in the system.
5. Decide what you will measure. If the few indicators management wants to see every week are chosen up front, the screens and reports are built around them; adding reports later is always harder.

A small example: discount approval

A customer asks for a discount. The sales representative messages the manager on WhatsApp, the manager says “okay” and the representative prepares the quotation. Nobody has defined this as a process, yet it works every day. If this flow is not written down when moving to ERP, the system will have either no approval step at all or an approval step that nobody uses. The analysis puts this invisible rule on paper and makes it something that can be built into the software. The same method applies to other silent rules such as stock corrections, supplier selection and return acceptance: first answer who decides what and on what basis, then write that decision into the system as a step.

A process you cannot explain to the software will not work in the software.

Who should take part in the analysis?

The people who do the work every day know the process best. So the analysis should not stay at the level of management and IT; the sales representative, the warehouse clerk, the purchaser and the accountant should take part as well. Management describes how work should run, and the employee describes how it actually runs. The gap between the two is the real work list of the project. Sometimes this gap is not a software need at all, only a missing rule or an unnecessary approval step; seeing it during the analysis takes far less effort than noticing it after installation.

What should you have in hand at the end of the analysis?

A good analysis does not end with spoken meetings, it ends with concrete documents. These documents become the basis both for the ERP setup and for later changes; when a new employee or manager arrives, they also explain why the system was built the way it was:

• Process maps running from sales to collection and from purchasing to delivery.
• A list of exceptions and special cases, with who decides each one.
• A role and authority table: who sees what, who approves what.
• An integration map showing the data sources and how they will be linked to one another.
• The scope of the first phase and the order of the areas to be added in later phases.

Our approach: ERP should fit the business

We build YazSis ERP on four principles. These principles also determine what will be decided at the end of the process analysis:

• Keep the existing system: If a working ERP exists, it is not ripped out; the missing processes are completed.
• Extend with a custom module: A workflow the standard product does not cover is developed to fit the organization.
• Join the data: A shared flow of information is built through API and database integrations.
• Measure and improve: Management reports make bottlenecks and results visible.

If you would like to map your processes together and define the scope of the first phase, you can reach us from the YazSis ERP page.