Describe the target process before choosing the tool.
Most ERP projects start with a shortlist of software packages and a series of demos. It is the most natural starting point, and the most expensive one. Here is the reverse approach, the one we practise on engagements: start from the processes, and only look at tools once the need is established.
When the project starts with the tool
The story is always the same. A company decides to change systems. It draws up a list of vendors, sits through demos, fills in a comparison matrix, chooses. The requirements list, when there is one, has often been copied from a template found elsewhere: hundreds of lines of features, with no hierarchy and no link to how the company actually works.
What follows is mechanical. The chosen tool imposes its logic. Teams discover during deployment that their ways of working do not fit into it. Customisations pile up, workarounds spread, costs drift, trust erodes. In the worst cases the company ends up with a system nobody masters and processes nobody can describe any more.
The problem is almost never the tool itself. Market ERPs are mature. The problem is that nobody established, before choosing, what the company expected from its processes.
Four steps, in this order
Framing is not an administrative formality before the real project. It is the moment when the company decides what it wants to become. Four steps, and the order matters.
Describe the target process, with no tool in mind
Domain by domain, you describe how things should work: what the process must produce, for whom, under which rules. The format that works is the objective tree: one master objective per domain, broken down into concrete objectives, from broad to fine.
- In workshops, with the people who do the work
- No software name during these sessions
- A shared vocabulary set from the start
Test the target against reality
You take each objective and compare it with how the company works today. Three possible findings: already achieved, an acceptable gap, or an irritant that costs money. This confrontation produces the raw material of the need.
- Gaps are named and illustrated with real cases
- What works is protected, not only what is missing
- Irritants are quantified whenever possible
Derive the need, ranked
The need comes out of the confrontation, not from a copied template. Each requirement is tied to an objective and to an observed gap. That link changes everything: you know why every line exists, and you can arbitrate.
- Requirements tied to objectives, not an inventory
- A hierarchy: essential, useful, accessory
- A short, defensible consultation file
Choose the tool, last
Demos then run on your scenarios, not on the vendor's standard tour. Each candidate walks through your cases, with your data, in front of your teams. The gap between the pitch and the product becomes visible.
- Demo scenarios drawn from the target processes
- The same cases for every candidate
- The teams score, not only management
What a framing actually produces
A serious framing fits in four deliverables. The objective trees, one per domain, which set the target. The description of the target processes, short, readable by an executive as well as by an operator. The list of gaps between target and reality, ranked. The consultation file, which translates it all for the vendors, demo scenarios included.
These documents outlive the choice of tool. They then serve as the reference for configuration, for acceptance, for change management. A gap between what the integrator delivers and what the framing file says shows immediately.
Four ways to fail a framing
Copying a template requirements list
Eight hundred lines of features ticked as essential say nothing about your company. Every vendor answers yes, and the choice ends up being made on the standard demo.
Letting the vendor run the demo
A vendor's standard tour shows what the product does best. Your scenarios show what it will do in your company. Those are two different pieces of information, and only one matters.
Framing without the teams
A target process written behind closed doors by management or by a lone consultant will be contested at the first deployment workshop. The target is built with the people who will run the system.
Trying to cover everything
Not everything is a critical gap. A framing that does not rank produces a project impossible to hold. The courage of framing is saying what will wait.
What a well-described target looks like
For a project-based company, engineering, custom equipment, build-to-spec work, the full chain is described in eight domains: sales, BOMs, purchasing, downstream purchasing, time tracking, invoicing, accounting, and the project financial control that runs across everything. Each unfolds into an objective tree.
The eight objective trees, published in full
The Method page unfolds the eight domains, objective by objective. It is the starting point of our framings.