We do not pretend to make complex work simple. We make it manageable. Finance is complex, and ACUMENTIQUE, our implementation method, makes it manageable for the people who carry the responsibility and do the work.
Classic ERP delivery is a waterfall: analyse, design, build, test, train, go live. It has one virtue (everyone knows where they are) and one flaw: nobody sees the whole system until the end, and by then it is too late to disagree. Agile fixes the second problem and creates a third: an ERP is a single set of books, and a ledger does not accept a minimum viable month-end.
ACUMENTIQUE keeps the waterfall's spine: six stages, each closed by a quality gate. Inside the stages, the work runs in streams that move at their own pace, with room to loop back where a finding calls for it.
Six stages, each closed by a quality gate
A stage ends when its deliverables are complete, tested where they can be tested, and signed. A workshop or a walkthrough is a means; what counts is the signed result it produces.
- Initiate
- Analyse
- Build
- Test
- Deploy
- Support
Initiate
Governance comes before configuration: who decides what, when the project meets, who is away when, the project plan, the system landscape and the release schedule.
Analyse
We review the current processes, systems and ways of working with the people who do the work, at their desks and on the shop floor. The Target Operating Model and the gap list come out of it, with the architecture decisions inherited from the ACURATE evaluation.
Build
Configuration, development, electronic reporting, forms and dashboards, and integrations, each tested by us as it is built. On paper they are separate types of work; in reality they are intertwined inside a process scope such as invoicing within order-to-cash, and we manage them that way, by scope, not by work type.
Test
Our lead consultants test end to end, the streams are tested together, and the people who will run the system test it themselves. Key users walk through each work package as it takes shape, so the final acceptance confirms rather than discovers: a late, big-bang acceptance test is the most reliable way to send a project back to the drawing board.
Deploy
The data migration is rehearsed, reconciled and signed off with the accountant who will close the first month. Training runs by role, in the users' language, on their own data. Then the cutover, a smoke test in production (the "penny test") and go-live.
Support
Hypercare through the first closing cycles, with us present. The internal administrator has been on the project since the first stage, and the documentation and the support portal have been growing since the analysis. Go-live is the day they take over, not the day they start.
Streams from A to Z
Inside the stages, the work runs in streams, each named by a letter. The alphabet follows the project, from A at the start to Z at the end:
Administer and initiate
Governance structures, meeting schedules, absence plans and the project plan.
Business analysis
Current processes, systems and ways of working, reviewed with the people who do the work.
Configuration and customisation
The system set up for the processes agreed in the analysis.
Development
What configuration cannot cover, specified, built and tested.
Electronic reporting
E-invoices, payment files and statutory reports.
Forms and dashboards
What customers, suppliers and managers see from the system.
System governance
The system landscape and the release cycles, managed from the first stage.
Integration
The interfaces to the systems around the ERP.
Key-user walkthroughs
Each work package walked through end to end by the people who know the process.
Lead-consultant testing
End-to-end tests by our lead consultants before the users test.
Migration
Data profiled, mapped, rehearsed and reconciled.
System integration testing
The streams tested together.
Training
By role, in the users' language, on their own data.
User acceptance testing
The people who will run the system confirm that it works for them.
Cutover and smoke testing
The switch to the new system, checked in production.
Go-live
The day the business starts running on the new system.
Hypercare
The first closing cycles, with us present.
Every deliverable has a number
Each stream's documents carry its letter and three digits, so a document's number says where it belongs and what it builds on. The same numbers structure the project folder during the project and the support portal after it. That is what institutional learning looks like in practice. Why we always quote for the people
Every project starts from our project templates, so the method is how the work is organised from the first day, not a slide in the proposal.
Functional streams
The letters say what kind of work it is. The functional streams say which part of the business it serves: typically General Ledger, Order Management (order-to-cash), Procurement (procure-to-pay) and Project Management, plus the streams your industry needs: production, service, assets. Each functional stream moves through the stages on its own rhythm and adjusts to what it learns.
Two overarching streams hold them together. The Project Management Office manages dependencies and the timeline across streams. User Adoption keeps the people who will use the system in the room from the first week, and makes sure user experience never leaves centre stage.
General Ledger
- Initiate
- Analyse
- Build
- Test
- Deploy
- Support
Order Management
order-to-cash
- Initiate
- Analyse
- Build
- Test
- Deploy
- Support
Procurement
procure-to-pay
- Initiate
- Analyse
- Build
- Test
- Deploy
- Support
Project Management
- Initiate
- Analyse
- Build
- Test
- Deploy
- Support
Industry streams
production, service, assets: as your business needs
- Initiate
- Analyse
- Build
- Test
- Deploy
- Support
The Target Operating Model comes first
Before any stream configures anything, its lead drafts the Target Operating Model for that scope: policies (why the process exists and what it must guarantee), processes (how it runs end to end), people (who runs each step, where, in which language), and only then technology. Three consequences:
Use the arrow keys to move between the parts of the model.
Direction
Vision
Why the business exists and where it wants to be. Everything below it, from the business idea to the last system setting, should trace back to it.
Direction
Mission
What the business does, for whom, day after day, to move towards the vision. It decides which ideas, plans and strategies belong to the business at all.
Direction
Strategy
The choices that turn vision and mission into priorities: the business strategies and, derived from them, one strategy per function. In the operating model, strategy ends where policies begin.
Direction
Tactics
How the strategy is carried out: the processes that run the work, the people who run the processes and the technology that enables both. This is the part of the model an ERP implementation touches most.
Corporate pyramid
Business idea
Connect the vision and mission to the customer need the business exists to meet. Make the intended value explicit before deciding how to organise delivery.
Evidence: an agreed purpose, target customers and the value promised to them.
Corporate pyramid
Business plan
Describe the business model, expected demand, resources and economics. Test whether the ambition can be sustained and which assumptions need evidence.
Evidence: a viable plan, measurable outcomes and accountable owners.
Corporate pyramid
Business strategies
Choose where to compete, how to serve customers and which capabilities the business must develop. Translate corporate choices into coherent priorities for each function.
Evidence: agreed priorities, capability gaps and a coordinated change portfolio.
Functions
Functional strategies
Selected function
Each function derives its own strategy from the business strategies: research and development, marketing, sales, contracting, service, support, HR, IT and finance. Each function then needs an operating model of its own; the model enlarges Finance as the example.
Functions
Finance Target Operating Model
The finance strategy made operational in four layers, agreed in this order: policies, processes, people and technology. In an implementation, every functional stream drafts the same four layers for its own scope before anything is configured.
Technical services (customisation and integration) follow the functional leads. Never the other way round.
Target Operating Model
Policies
What the business has decided, and why: approval limits, credit rules, revenue recognition, what counts as a project.
Processes are understood in terms of their purpose, not merely as "how we have always done it".
Role in operationalisation
Leader & Director of Operationalisation
- Simple & Clear, not Complex & Vague
Evidence: policy owners, approval limits and agreed treatment of exceptions.
Target Operating Model
Processes
How those decisions are executed, end to end.
Role in operationalisation
Leader & Director of Operationalisation
- executing streamlined Processes
Evidence: future process maps, control points and representative acceptance scenarios.
Target Operating Model
People
Who executes each step, with which skills, in which location and language.
The right people are identified early and enter the testing and training plans by name, so availability gaps and staff transitions are called before they become risks.
Role in operationalisation
Organisation of Resources for Operationalisation
- executing streamlined Processes
Evidence: role ownership, access needs, capacity commitments and a training plan.
Target Operating Model
Technology
Which system, which configuration, which integration supports the three layers above.
The 3Ps are the three layers above: policies, processes and people.
Role in operationalisation
Enabler & Accelerator of Operationalisation
- enabling the predefined 3Ps
- executing streamlined Processes
Evidence: a traceable solution design, tested configurations and assigned operational ownership.
- Processes are understood in terms of their purpose, not merely as "how we have always done it".
- The right people are identified early and enter the testing and training plans by name, so availability gaps and staff transitions are called before they become risks.
- Technology stays a means to business ends, never the reverse.
Technical services (customisation and integration) follow the functional leads. Never the other way round.
Project governance
Governance is the first stream, not an afterthought. In the first stage, the A stream settles who decides what, how often the project meets and how the plan is kept, and the G stream settles the system landscape and the release cycles. The project management office and the stream leads coordinate across the streams and keep dependencies and the timeline visible to everyone. Every stage closes at its quality gate with signed deliverables, so the decisions that steer the project rest on documents, not on impressions.
Why not "just agile" or "just standard"?
Standard configuration first, always. Iteration inside streams, always. But a ledger, a tax return and a payroll run are not features to release incrementally; they are correct or they are not.
The idea that an agile approach, or no fixed method at all, keeps an ERP project lean and simple is a fallacy. Nobody runs an airport without standard operating procedures, because a complex system needs them, and an ERP runs a company. ACUMENTIQUE gives the business the certainty of a waterfall on the things that must be right, and the flexibility of iteration on everything else.