Mapping current processes without rebuilding them in the new system

The purchasing manager describes to the project team how an order works today: she prints the requisition, the department head signs it, and a colleague types the data into an Excel list. Two weeks later, exactly this workflow appears in the specification, only with a screen instead of paper. The new system then reproduces the detours of the old one. That costs time during implementation, triggers follow-up questions from the business department, and leads to customizations that make every later version upgrade harder.

This article shows you how to capture a process without copying it, and how to mark what should change along the way.

Choose a Process and Define Its Scope

Don't capture "sales" as a whole. Pick one procedure with a clear start and end. Everyday examples:

• An order arrives in the web shop and has to end up as a sales order in the ERP (Enterprise Resource Planning) system.
• An employee looks for information that is scattered across quotes, emails, and project notes.
• A customer inquiry arrives by email and needs to be handled.
• A solar company supports a project from quote through material procurement to invoice.

For your process, define:

1. Trigger: What sets the procedure in motion (email, phone call, order)?
2. Result: How do you know it is finished (invoice posted, ticket closed)?
3. Participants: Who works on it, by role rather than by name?

If you cannot describe the process from trigger to result in a single sentence, it is too big. Split it.

Capture the Process as It Really Runs

Talk to the people who actually carry out the procedure, not only to management. Management knows the target process; the clerk knows the shortcuts and workarounds.

Ask to be shown a real, completed case, ideally based on the document itself: the specific order, the specific invoice, the specific email. For each step, record:

• Who does what, and with what (software, Excel, paper, phone)?
• What information goes in, and what comes out?
• Where does the procedure wait, and for what?
• Where is data retyped that already exists somewhere else?
• Which exceptions occur, and how are they resolved?

In this phase, write down only what is. Judgments such as "that's unnecessary" come later. Otherwise the people involved stop telling you the truth.

Ask Why Behind Every Step

For every step, ask: "What happens if we leave it out?" This yields three possible answers:

• Something concrete happens, such as a missing approval or a mandatory detail on the invoice. The step serves a purpose.
• Nobody knows exactly. The step comes from an old habit or a previous tool.
• The step fixes a problem that another step creates. For example, data is maintained in Excel because the old system lacked a field.

The purpose stays; the step may change. If you need an approval based on a value threshold, you don't necessarily need the printed slip with a signature. So note the purpose next to each step in one sentence.

Mark What Should Change

Go through the documented process using a color system. Three markings are enough:

1. Keep: The step has a clear purpose and works well.
2. Change: The purpose stays, but the way to achieve it should be different (for example, double entry is eliminated).
3. Remove: The step serves only a tool or problem of the past.

Decision rules for marking:

• If a step only transfers data from one system to the next, mark it "Change" and clarify which system should hold the data.
• If a step maintains an Excel list, ask which formula or rule is embedded in it. This rule belongs in the specification; the list itself does not.
• If a step handles an exception, ask how often it occurs. A rare exception seldom justifies a customization of the system. Often a standard process with a changed way of working is cheaper.
• If a step results from law or tax regulations, mark it "Keep" and have your tax advisor confirm the requirement.

The third rule is the most important one for costs: every customization of the standard has to be re-checked during later version upgrades.

From Process to Specification

The marked capture becomes a document that the business department and development understand in the same way. Write the target process in the language of the business department and describe:

• the goal of the procedure and its result,
• the roles and what each role is allowed to decide,
• the data a step needs and where it comes from,
• the rules, such as value thresholds or mandatory fields,
• the exceptions the system has to handle, and those that will continue to be handled manually.

Describe the result, not the operation. "The order is created from the shop order without re-entry" is a requirement. "Field X is filled in screen Y" is already a solution.

Before each requirement, check whether the Odoo version and edition in use already covers it. At Simplify-ERP, this check is part of the process analysis, before any code is written. The principle applies to any software: first clarify what the standard can do, then decide what needs to be customized.

Example: Shop Integration

A retailer sells through a web shop. Current process: In the morning, an employee exports the orders, copies them into a spreadsheet, creates sales orders in the ERP, and reconciles stock by hand.

Marking:

• Export and copying: Change. The purpose, getting orders into the ERP, stays. The transfer should run automatically. Connectors such as the Odoo Shopware Connector import orders in real time and synchronize products in both directions.
• Manual stock reconciliation: Remove, provided one system manages stock and the other takes it over.
• Review of suspicious orders: Keep. The purpose, catching fraud or errors, still applies.

The central question in the specification here is not "How do we rebuild the export?" but "Which system holds the product data?"

Your Next Step

Choose one procedure from your area today and ask the person who carries it out to show you a specific completed case. Write down each step with its purpose and mark it as Keep, Change, or Remove. Afterward, count for how many steps you could not name the purpose. These are the candidates you should not carry over into the new system.