Status lives outside the system.
Participants check progress through email, messaging apps, calls and private messages.
The process is digitized, but status is still sought in correspondence
Approval takes longer than the work itself
Most of the cycle is spent waiting, returning items and seeking clarification.
Returns arise due to incomplete data
The completeness of the application, document or request is checked late when the process is already running.
Exceptions are not managed
Exceptions follow informal routes, and deadlines and ownership are lost.
Why this happens
The time taken to approve a contract can far exceed the time participants spend working on it. Most of the cycle consists of waiting, rework caused by incomplete data and delays when the responsible employee is unavailable and there is no automatic escalation.
The same issue occurs in procurement, HR requests, service delivery, contractor coordination and customer enquiries. An electronic form alone does not digitalise a process. Without changes to the workflow, the system simply formalises existing delays.
Digitalisation does not begin with a form, but with a managed route from query to result.
Process participants need to see the task, status, deadline, owner, next step and reason for an exception.
An end-to-end process is a chain of mutual commitments.
Event and outcome
What starts the process and how should it end?
The application, document, request, order, claim or internal service must have a clear start, result and completion criterion.
Event, input, result, completion criteria and full cycle owner.
Route and rules
Which rules govern the workflow?
Stages, participants, approvers and assignees depend on request type, risk, amount, completeness and other attributes.
Stages, roles, SLAs, approval rules, returns, exceptions and escalation procedures.
Status and interaction
Where does the participant see the next step?
Work needs to take place in a system that shows the current stage, responsible person, deadline, status history and action required from each participant.
Workspace, process record, notifications, history, statuses and delay analytics.
More about the model
A digital process defines more than a sequence of screens or forms. It records the triggering event, input data, owner of the complete cycle, participants, deadlines, exception rules and expected result.
The initiator needs to understand the input requirements; the person doing the work needs to know the expected result. The manager needs to see where queues form and why, while the customer or counterparty needs to know the request status and next step.
How we build a digital workflow
We start with the complete cycle from event to result, distinguish productive work from waiting, and define workflow rules. We then select the system, interfaces and automation.
Measure the path from event to outcome
We document the entire process: operations, waiting, returns, transfers outside the system and points where status is lost.
More about our work
Starting point
Each department sees only its part, and the full cycle of a request or document is not measured.
What we do
We map the path from the triggering event to the result, distinguish actual work from waiting, and record rework, queues and informal communication channels.
How to check the results
Full cycle time, waiting time, repeated returns and the stages where delays occur are known.
Design the target workflow and accountability
We exclude stages without managerial or control value and set the owner of the full cycle.
More about our work
Starting point
Approvals repeat, participants check the same data, and responsibility is split across individual functions.
What we do
We define the process owner, participant roles, mandatory stages, approval conditions, handover rules and completion criteria for each step.
How to check the results
Each stage has a clear assignee, approver, deadline and definition of the result.
Define data requirements, completeness checks and exception handling
The process must check the input data in advance and separate the standard cases from the non-standard ones.
More about our work
Starting point
A document or request is returned after the workflow starts because data, supporting grounds or attachments are missing.
What we do
We define mandatory fields, documents, risk indicators, completeness checks, exception routes and automatic escalation conditions.
How to check the results
Incomplete packages are detected before the main workflow starts; exceptions do not disrupt standard request processing.
Embed the workflow in the working system
BPM, ECM, CRM, portal or service platform are chosen for the target route, not a substitute for its design.
More about our work
Starting point
The system is implemented, but participants continue to transmit data through mail, spreadsheets and private messages.
What we do
We configure process records, statuses, notifications, permissions, integrations, activity history and cycle, queue, return and deadline analytics.
How to check the results
Participants see status and the next step in the system; managers see where delays occur and why items are returned.
Services within this practice
Engagements and deliverables: from process assessment to digital workflows, process platforms, portals, automation and analytics.
Process and collaboration assessment
A map of manual operations, gaps, returns, waiting periods, exceptions and informal arrangements in requests, documents, approvals and collaboration across functions.
Designing digital workflows
Target process workflows: status, roles, deadlines, transition conditions, checkpoints, exception handling and escalation rules.
Implementing process platforms and workspaces
Working digital environments for applications, requests, approvals, service workflows, documents, tasks, internal services and interaction with customers or contractors.
Developing portals and self-service accounts
Internal and external portals, self-service accounts and workspaces for employees, customers, contractors, partners and management teams.
Automating routine operations
Automation scenarios for repetitive actions through workflows, integrations, RPA, AI assistants or application services, without unnecessary manual processing.
Building process analytics
Metrics for deadlines, status, bottlenecks, variances, staff workload and process quality from the triggering event to the result.
What the team gets
Full cycle map
The path from event to outcome: operations, waiting, returns, informal handovers and points where status is lost.
Target process workflow
Stages, roles, deadlines, approval conditions, handover rules and completion criteria.
Accountability model
End-to-end process owner, participants, approvers, assignees, escalation and cover arrangements.
Data rules and completeness
Mandatory fields, documents, grounds, checks and conditions for starting the route.
Processing exceptions
Non-standard cases, individual routes, return conditions, notification and escalation.
Process analytics
Data on cycle times, queues, returns, missed deadlines and participant workload.
What changes in the process
Success is visible when the complete cycle becomes measurable, participants can see its status and exceptions follow defined rules. The number of electronic forms is not the measure of success.
The full cycle is measurableIt is clear where work is performed, waits, returns for revision or misses its deadline.
Starting point
Managers see completion or overdue status but cannot identify where delays arise.
What's changing
The execution time is separated from the wait; queues, returns and stages of loss of status are recorded.
How to check the results
It is possible to show the length of the full cycle, bottlenecks and causes of delays for each type of process.
Status visible in the systemParticipants can check request status without asking colleagues.
Starting point
The current stage, owner and next step have to be established manually.
What's changing
The process record shows status, deadline, owner, history and the expected action.
How to check the results
The initiator, executor and manager see the same current status without additional requests.
Fewer items are returnedCompleteness and rules are checked prior to the launch of the main route.
Starting point
The document or application is returned after several stages of processing due to incomplete data.
What's changing
Mandatory fields, attachments and route conditions are checked in advance.
How to check the results
Fewer items are returned because of incomplete packages, incorrect supporting grounds or the wrong workflow.
Volume growth doesn't increase chaosStandard workflows and escalation rules handle more requests without a proportional increase in coordination.
Starting point
As the number of applications increases, participants begin to coordinate through chats, mail and manual lists.
What's changing
Typical routes, SLAs, notifications and escalations support volume growth in the system.
How to check the results
The number of operations increases, but does not lead to a proportional increase in manual coordination.
The process does not depend on a specific employee.History, commitment and the next step are recorded in the system.
Starting point
If an employee is unavailable, participants do not understand the status of the task and the basis of previous decisions.
What's changing
Status history, comments, documents, decisions and the next step are available in the process card.
How to check the results
Replacing an employee does not stop the route and does not require reconstituting the context from the correspondence.
When this practice is especially useful
This practice is needed when a process has formally been digitalised, but participants still manage status updates, rework and approvals through messages, spreadsheets and personal coordination.
Approval time is unpredictable
Most of the cycle is spent waiting for processing rather than performing the work
More details
- Documents remain idle for long periods
- waiting stage is not measured
- The owner is not always clear
- Items are returned late in the process
- deadlines are specified manually
Requests and enquiries arrive through different channels
Email, messaging apps, private messages and spreadsheets replace a single intake point
More details
- Requests are lost between channels
- Participants re-enter the same information
- The client repeats the information to different departments
- status depends on personal correspondence
- Processing history is not stored in one place
Documents are returned due to incomplete set
Completeness is checked too late and disrupts the main route
More details
- The application is launched without mandatory data
- Reasons for approval are not formalized
- Participants return the document for various reasons.
- repeated checks are duplicated
- Non-standard cases follow an informal path.
Interaction with contractors and suppliers is unmanageable
Documents, comments, statuses and obligations are distributed among correspondence, tables and files
More details
- The contractor does not see the current status
- comments are transmitted outside the system
- Ownership changes are not recorded
- There is no general history of interaction
- Deadline monitoring requires manual coordination
This practice in projects
