how we work

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.

stages

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.

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
principles

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.

from the client

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.