Process first, system second
The order of work we follow on every project, from survey to handover into operation. Each stage has its own deliverable that can be seen and judged before moving to the next one.
Seven steps
Stages 1–2 can be bought separately as IT consulting. The project continues beyond them only when both sides can see that implementing is worth it.
-
01
Survey
Interviews with process participants, mapping of document routes, an inventory of systems and of manual data transfer. We describe the work as it is, not as the regulation describes it.
Deliverable: as-is process map and list of gaps -
02
Target model and estimate
What the process should look like after the change, which steps disappear, what the system supports. Together with implementation scope, a breakdown into waves, budget and risks.
Deliverable: to-be model, requirements, plan and budget -
03
Pilot on one process
One real process in a working environment with real people and documents. A pilot reveals what a diagram cannot: exceptions, undocumented sign-offs and the places where users work around the system.
Deliverable: a working process and a refined estimate for the rest -
04
Configuration and rollout in waves
Further processes are connected in turns rather than all at once. Each wave has its own go-live date and its own definition of what counts as done.
Deliverable: processes in operation, wave by wave -
05
Data and integrations
Migration of reference data, balances and archives; exchange with the systems that stay in use. This is usually where projects slip, so migration is planned as its own block rather than as an afterthought.
Deliverable: reconciled data and working exchange -
06
Training and handover
Training by role: an accountant, an approver, a records clerk and an administrator each see a different system. Instructions are written for your routes, not for the vendor's general manual.
Deliverable: people working in the system without us -
07
Support and evolution
After go-live processes change: new document types appear, limits and roles shift. Support means making those changes, not only reacting to incidents.
Deliverable: the system changes with the organisation
Rules we hold to
More often than not these, rather than the choice of platform, decide whether a project succeeds.
Process over system
Automated disorder stays disorder and starts costing more. If a process is not described, we describe it first rather than configuring the system.
Pilot before scale
One process is brought to a working state before the rest are connected. It is the cheaper way to find out that we missed something.
Estimate after survey
We quote timelines and budget once we have seen document volumes and current routes. Before that, only a range with an honest explanation of what it depends on.
A process owner on the client side
Every process needs a person who decides on changes. Without one, implementation turns into endless negotiation between departments.
Results as before-and-after numbers
Before the start we fix what is measured: approval duration, share of documents outside the system, number of returns for rework. Without a baseline there is no effect to speak of.
"No" is also a result
If the survey shows implementation will not pay off now, we say so. Losing a project is more honest than running it and leaving the client with a system nobody uses.
What we need from your side
Implementation cannot be bought turnkey without the organisation taking part — this is not a way to shift work, but the condition under which a system takes root.
- A process ownersomeone who decides on changes to routes
- Access to participantsa few hours of interviews with people who actually handle documents
- Access to systemstest environments and reference-data exports for migration
- Decisions on exceptionsan answer on which deviations from the route remain acceptable
- People's time for trainingscheduled hours, not "in between other things"
- Willingness to change the processsometimes the right answer is a change of regulation, not configuration
The survey and target model can be bought as a separate service — see Services. What exactly we implement at stages 3–5 is on the Solutions page.