Business Process Consulting

Process problems I see most often

Growing businesses rarely have bad people. They have processes that grew by accident. What worked with a small team breaks quietly as volume, locations and products increase. The symptoms are remarkably consistent across industries:

• Re-keying: the same order, customer or invoice is typed into two or three systems, with errors at each step.
• Invisible approvals: purchases and discounts wait in someone's inbox, and nobody can see where a request is stuck.
• Spreadsheet dependency: stock, pricing or project costs are tracked in files that only one person fully understands.
• Unclear ownership: when a handoff between sales and operations fails, each side believes the other was responsible.
• Exceptions handled by memory: returns, partial shipments, credit holds and urgent orders depend on experienced staff remembering what to do.
• Disputed numbers: management meetings spend more time arguing about which report is correct than deciding what to do.

None of these are solved by buying software on its own. They are solved by agreeing how the work should flow, who owns each step and what information each step needs. That is exactly what process mapping and requirement work deliver, and it is why I recommend doing it before any system decision.

Why map business processes before buying software?

When a business buys software before agreeing on its processes, the software ends up defining the process by accident. Teams adapt to whatever the default configuration does, or the implementer guesses, and the gaps appear during testing or after go-live, when they are expensive and disruptive to fix.

Process mapping makes the hidden parts of the business visible. In almost every workshop, people discover steps that one department did not know another department was doing, approvals that exist only by habit, and spreadsheets that quietly hold the business together. Those discoveries are exactly what a system project needs to know about.

A good as-is map answers practical questions:

• Who starts the process, and what triggers it?
• Where does information get re-keyed or copied?
• Which approvals are required, and which are just habit?
• Where do delays, errors and customer complaints come from?
• What happens in the exceptions, such as returns, partial deliveries or credit holds?

The to-be design then becomes a deliberate choice rather than an accident. It is the basis for ERP consulting, CRM and automation work that fits the business.

What goes into a good business requirement document?

A business requirement document is the contract between the business and whoever builds the solution. A weak BRD is a list of features copied from a vendor brochure. A strong one describes what the business needs to achieve, in language both managers and implementers understand.

The BRDs I write typically include:

• Objectives and scope: what the project must achieve, and what is explicitly out of scope.
• Process requirements: linked to the to-be maps, step by step.
• Functional requirements: prioritized as must-have, should-have and nice-to-have.
• Reporting and KPIs: the reports and dashboards each role needs.
• Data and integrations: master data ownership, migration needs and connected systems.
• Roles and controls: permissions, approvals and audit requirements.
• Acceptance criteria: how each requirement will be tested and signed off.

This level of clarity helps vendors quote accurately, makes the platform selection fairer, and gives you a firm basis for managing scope during implementation. For a step-by-step template, see how to create an ERP BRD.

Gap analysis, SOPs and KPIs: making the design stick

Once requirements are clear, a gap analysis compares them with what a chosen platform does out of the box. Each gap gets one of four answers: configure it, customize it, integrate another tool, or change the process. Choosing process change where it makes sense keeps customization low, which makes systems cheaper to maintain and easier to upgrade.

Standard operating procedures turn the agreed design into daily practice. Good SOPs are short, role-based and tied to the system screens people actually use. They reduce dependence on a few experienced staff, make onboarding faster, and keep branches or entities working consistently.

KPIs close the loop. For each process, I help you agree a small set of measures, how each is calculated, which system provides the data and who owns it. That prevents the common situation where every department reports a different number for the same thing.

Together, these deliverables make sure the process work does not end up as a document nobody reads. They give your team a shared reference for how the business runs, and a basis for measuring whether changes are working. If that sounds useful, let us talk about where your processes need attention.

How process workshops run remotely

All of my process work is delivered remotely, and it works well when it is structured. A typical engagement follows the same sequence.

1. Scoping call: we agree which processes are in scope, who owns them and what decisions the work must support.
2. Document review: I look at existing forms, reports, spreadsheets and system screens before the first workshop, so time with your team is not spent on basics.
3. As-is workshops: short, focused online sessions per process with the people who actually do the work, not only their managers. I draw the map live so participants can correct it as we go.
4. Validation: maps and pain points are shared for written comment, then confirmed with process owners.
5. To-be design: we agree the target process, controls and handoffs, and capture each requirement with a priority.
6. Handover: you receive the maps, the requirement list or BRD, and a short findings summary for leadership.

Recorded sessions and a shared decision log mean nothing depends on someone's notes. If your project needs a formal requirement document for vendors, the work extends into ERP requirements gathering and BRD consulting.

From process design to systems, integration and reporting

Process design is only useful if it survives contact with the systems that run the business. I stay involved beyond the documents so the design is carried into whatever comes next.

When the next step is a new ERP or CRM, the to-be maps and requirement list become the basis for gap analysis, vendor demos and solution design. Each requirement can be traced from the workshop where it was raised to the configuration that delivers it and the UAT script that proves it works.

When the next step is integration or automation, the maps show exactly where data crosses system boundaries and which steps are rule-based enough to automate. That avoids automating a process that should have been simplified first.

Reporting follows the same logic. The KPIs agreed during process design define what each system must capture, so dashboards can be built on real transaction data rather than manual spreadsheets.

As an independent consultant, I have no product to push into the design. If the best answer is a simpler process with fewer approvals and no new software, I will say so. Your ERP should fit your business; your business should not have to fit the software.