BPM and process automation
We move approval routes out of verbal agreements and e-mail threads into the system, with an owner at every stage, deadlines and defined behaviour on rejection. We do not develop a BPM product of our own — we implement established platforms.
The processes people usually start with
Not "all document flow at once", but specific routes where the delay is felt and can be measured.
Contract approval
Legal, finance, security, management — with parallel branches where they really are parallel. You can see whose desk the document is on and for how many days.
Purchase and payment requests
A request is linked to a budget and a contract from creation. The limit is checked when the commitment arises, not during month-end reconciliation.
Incoming and outgoing correspondence
Registration, resolutions, assignments and deadline control. The simplest process for a pilot: the result is visible within a week.
Internal documents
Memos, orders, leave and travel requests. Many similar routes that are easy to describe as templates.
Assignments and follow-up
Who is responsible, by what date, what counts as done. Without this, meetings generate assignments nobody tracks.
Budget change approval
Reallocation between lines with a record of who initiated and who authorised it. "Why did this figure change" stops being an investigation.
Why BPM implementations fail
We have seen all of these. Half of these risks are removed by the survey stage, the other half by the pilot.
Automating an undocumented process
If a route exists only in people's heads, it will freeze in the system in whatever shape it happened to have. Description first, configuration second.
"Do it as it is now, but in the system"
That also automates the step that exists only because departments do not trust each other. Some stages are better removed than digitised.
Ignoring exceptions
Urgent payments and out-of-order documents always exist. If they are not described, users start working around the system and the statistics stop being reliable.
No process owner
Without a person who decides on the route, agreeing the configuration takes longer than the implementation itself.
Launching everything at once
One process in a pilot exposes mistakes cheaply. Ten processes at once expose the same mistakes expensively and in every department.
No baseline measurement
If approval duration and the number of returns are not measured before go-live, there will be nothing to compare against afterwards.
Articles on this topic
No articles in this category yet.
The order of work and what we need from the client is on the How We Work page. The subsystems we implement are on the Solutions page.