Business processes: notifications and modeling, what to choose?
- Джимшер Челидзе
- Apr 17, 2024
- 25 min read
Updated: May 17
We have discussed with you the main types of organizational structures, but there is another key area - business processes. If org. structure is the skeleton of the organization, then business processes are the central nervous system with built-in reflexes.
Perhaps this all seems boring to you, but in our practice there is one simple rule - there is nothing worse than the arguments “it’s already clear”, “it’s too simple”. They don't bode well. These theses are harbingers of chaos and neglected problems
In general, in life there are 2 extremes of process management - chaos and bureaucracy
Content
Basic approaches to describing business processes
Before diving into the question “how to describe it,” first let’s answer the question: “What are business processes?”
A business process is a specific algorithm of interconnected actions of people and IT systems, which is aimed at transforming “raw materials” into a “product” or result.
For example, the procurement business process roughly includes the following stages: receiving an application - searching for suppliers - collecting proposals - supplying materials - transferring to the customer. But each stage is also broken down into separate business processes. Therefore, you need to understand that describing business processes is an almost endless task; you will need to choose the level of detail at which you say “that’s enough.” And the lower the team’s level of competence, the more detailed the description is needed. Well, or you need to train the team, but then you, as a leader, will also need to grow. Smart personnel will not tolerate being treated like fools.
Conventionally, there are several approaches to describing business processes:
An approach that allows you to describe at the highest level the key areas of activity of the company and divisions and show the relationships between them. Here the focus is on the graphical display of business processes that create value for the client.
That is, this is a kind of “master” model of the entire company to give the entire team an understanding of how their work affects the entire company.
Rules for constructing a value added process model (VAD)
First, you need to determine the key objectives of the company or division that characterize its activities.
Next, their logical relationship is built
The owner and department responsible for the process are identified and specified.
Key documents that regulate the business process are indicated
Additional information and necessary resources to complete the business process are indicated.
Each top-level business process is assigned or attached links to diagrams (VAD or EPC) of a lower level.
Video:
Useful links:
An approach to describing business processes, which is a tool in lean manufacturing. The name reflects the essence of the approach, which focuses on:
Supplier - a person or company that supplies resources to complete a business process (production, money, materials);
Input (inputs) - resources for the business process: materials, money, production capacity);
Process (processes) - all those tasks that, as a result of the work of a business process, allow transforming raw materials into the final product;
Output – products of the business process;
Customer – recipients of the service, those who use the product of the business process.
Algorithm for describing business processes:
1. Determination of the customer of the business process;
2. Description of the final product (output) that the customer needs;
3. 5-7 key operations of the business process;
4. Determining the necessary resources (inputs) for the business process;
5. Identifying suppliers of these resources.
Video:
Useful links:
This approach describes business processes in the form of individual stages/steps of the process and the events that initiate these steps, that is, the structure “event - function - event” is obtained. This approach is well suited for standardizing business processes and analyzing the flow of documents and necessary information throughout the entire business process.
Basic elements of the description:
An event is something that creates the need for action.
A function is an action to obtain the desired result in response to an event.
Performers are those who implement the function, including those who approve, coordinate, and so on.
Resources are everything that is needed to implement a function: money, information systems or individual modules, documents, operational risks.
Unlike the previous approach, where the start was on the left and the finish on the right, here everything starts from the top and goes down.
Description algorithm:
We determine what we have and what we want - boundary events.
We describe the intermediate events that exist within this process and what tasks need to be performed / functions implemented
We add all the necessary information about performers and resources.
Analysis of the completeness and quality of the scheme, whether it takes into account all variations and subprocesses. If necessary, we make additional diagrams for subprocesses. However, here we recommend that you always remember a simple rule - one diagram, one sheet or screen.
The advantage of the approach is the ability to then create understandable regulations in the form of text or tables. This notation is quite common, especially in large organizations. Since, on the one hand, it standardizes the description, and on the other hand, it is quite flexible. For example, it is often used to set up ERP systems .
Useful links:
BPMN today is a de facto standard for describing business processes with a wide range of graphic elements for description and modeling. While this may not be the most convenient approach for ordinary users and managers, for business analysts this is a must-have tool: within the framework of this approach, it will be difficult to describe a fairly large process on 1 sheet; in addition, the approach is quite strict, but there is higher detail and it is easier to identify local errors. An example of a description in this notation is below.
Video:
Useful links:
Flowchart notations are used to represent the process execution algorithm and allow you to specify cause-and-effect relationships and the time sequence of process actions. The notations support decomposition into subprocesses.
The difference between the Process and Procedure notations is that in addition to the graphic symbols used in the Process notation, the Procedure notation uses Swim Lanes to denote the organization. units - performers of process actions. This improves the visibility of the diagram.
Video:
Useful links:
IDEF is a whole family of methodologies of the ICAM (Integrated Computer-Aided Manufacturing) family. This family of notations and modeling methods was originally developed for the US Air Force to describe work processes and implement IT systems. And if you communicate with IT integrators or plan to automate business processes through IT systems, you will come across exactly this approach. But of course, if you are comfortable working with this approach on a daily basis, then you can use it for other scenarios.
The IDEF family includes the following standards:
IDEF0 is a methodology for functional modeling ( Function Modeling ). The most common approach of DEF1 and IDEF1X is Information and Data Modeling Method. IDEF1X provides a clear graphical language for describing objects and relationships in applications, called an entity-relationship diagramming language. The most popular approach currently
IDEF1 and IDEF1X - Information modeling (Information and Data Modeling Method). IDEF1X provides a clear graphical language for describing objects and relationships in applications, called an entity-relationship diagramming language.
IDEF2 - Behavioral modeling (Simulation Modeling Method). Behavioral modeling is based on models and methods of simulation of queuing systems and Petri nets.
IDEF3 - Activity Modeling (Process Flow and Object Stale Description Capture Method). The methodology details the answer to the question not “what the system does,” but “how the system does it.”
IDEF4 - Object-oriented Design Method. The model provides the user with a graphical language for depicting classes, inheritance diagrams, and taxonomy of methods.
IDEF5 - Systematization of application objects (Ontology Description Capture Method). The model represents the ontological information of the application in a user-friendly form. For this, symbolic designations (descriptors) of objects, their associations, situations and a schematic language for describing relationships of classification, “part-whole”, transition, etc. are used. The method has rules for linking objects (terms) into sentences and axioms for the interpretation of terms.
IDEF6 - Using Design Rational Capture Method. Helps prevent structural errors.
IDEF8 - Human-System Interaction Design. The model is intended for designing dialogues between a person and a technical system.
IDEF9 - Taking into account conditions and restrictions (Business Constraint Discovery). The model is intended to analyze existing conditions and restrictions (including physical, legal, political) and their impact on decisions made in the reengineering process.
IDEF14 - Modeling of computer networks (Network Design). The model is intended for presenting and analyzing data when designing computer networks in a graphical language with a description of configurations, queues, network components, reliability requirements, etc.
useful links
Video
Unified Modeling Language (UML) is another process modeling approach that is actively used in IT. It is a notation that can be used for object-oriented analysis and design. It can be used to visualize, specify, construct, and document software systems.
UML has 12 diagrams that define the statistical, behavioral, and physical activities of system components. The most accessible and relevant at present:
Use-case diagram. It is based on an Actor (performer), which establishes logical connections between roles and precedents, and a Use case (the precedent itself), which demonstrates which process is being executed.
A Class diagram is a set of static and declarative model elements that have common attributes and operations. The diagram has the most complete and detailed description of connections in the program code, functionality and information about individual classes.
An Activity diagram displays the dynamic aspects of behavior and the overall performance of a system in a flowchart format. A diagram is necessary to describe business processes, the interaction of multiple systems, the logic of procedures and work flows, especially when moving from one activity to another.
A Sequence diagram describes the behavioral aspects of a system, the type of messages, and clarifies use cases. Necessary for displaying the interaction of objects in dynamics and over time, it implies the exchange of messages within a specific scenario.
The deployment diagram displays a graphical representation of the infrastructure, namely the distribution of system components across nodes and the routes of their connections. A diagram organizes components and solves minor problems associated with a specific aspect of a business process.
Useful links:
Video
One of the lean manufacturing tools, along with SIPOC . Also Value Streams are a fundamental component of SAFe® (Scaled Agile Framework®) and come in two types: Development Value Stream (DVS) and Operational Value Stream (OVS).
Value Stream Mapping is a tool that visualizes the process of transforming raw materials into finished products sold to consumers. Its objects are material and information flows of resources, as well as time.
Creating Value Stream Mapping is divided into three blocks:
A production or process flow is a traditional flowchart in which, from left to right, the path of value creation is recorded, starting with the purchase of raw materials and ending with the shipment of products. If, in addition to the main process, there are additional or auxiliary ones, they are applied under the main one. In this way, the main tasks are separated from the secondary ones.
Information or communication flow - at the top of the value stream map, arrows depict information flows that occur in parallel with production. Both formal and informal data exchange are taken into account. Information flows are plotted on the map in free form, as they flow in reality.
Timeline and distances are lines that are drawn at the bottom of the map. The time line is divided into upper and lower parts. The lead time is displayed at the top - the waiting time. The cycle duration is shown below. Below the time line there may be another line, at the very bottom, showing the distances along which the product or personnel move within the process.
Simplified operation algorithm:
Step 1. Selecting a process for systematizing the value stream (preparatory)
Step 2: Value Stream Mapping Symbols
Step 3: Defining Process Boundaries
Step 4: Process Steps
Step 5. Adding information flows to the map
Step 6: Add data about each step of the process
Step 7. Inventory counting
Step 8. Adding process chronology - Timeline
Step 9: Future State Map
Step 10: Plan for Implementing Improvements
Useful links:
Video
If you begin to build process management, then you need to understand what kind of processes can there be in an organization?
Classification first
According to this classification, there are 3 types of processes.
Value creation/production
The main production processes that create value for the end consumer and affect the cost of services, income: sales, production, etc.
Their effectiveness determines the effectiveness of the company as a whole.
Managerial and supervisory
Processes related to strategic, tactical and operational management. Including approaches to management decision making.
For example, strategy development, production planning, monitoring and measuring performance, financial accounting and planning, project management, etc.
Supporters
Processes that ensure the implementation of value-creating processes: hiring, training and adaptation of personnel; equipment maintenance and repairs; logistics and procurement; IT support.
They can be divided into providing, service, auxiliary, etc. Supporting business processes are associated with certain costs, and the more efficiently they proceed, the less costs the company incurs.
Second classification
Production processes and operational processes
These processes are associated with the production of goods or the provision of services. These include planning, resource procurement, production, quality control and delivery of the final product or service. Manufacturing and operational processes aim to optimize productivity, reduce costs and improve the quality of a product or service.
HR processes
These processes are related to the management of human resources of the organization. These include recruitment, training, development, employee evaluation, performance management, motivation and retention. Human resource management processes are aimed at creating effective teams, developing the potential of employees and ensuring a high level of staff performance and satisfaction.
Marketing and sales processes
These processes are related to positioning products or services in the market, attracting customers, developing marketing strategies, promoting and selling products or services. Marketing and sales processes are aimed at satisfying customer needs, increasing sales and establishing long-term relationships with customers.
Financial management processes
These processes are related to the management of the organization's finances and resources. These include budgeting, financial analysis, investment management, accounting and reporting. Financial management processes are aimed at ensuring financial sustainability, efficient use of resources and making informed financial decisions.
Quality Management Processes
These processes are associated with ensuring a high level of quality of a product or service. These include quality planning, quality control, data analysis, nonconformity resolution, and continuous improvement. Quality management processes are aimed at satisfying customer requirements, minimizing defects, increasing reliability and strengthening the organization's reputation.
Summary
That is, you need to both describe how these processes work and design the future state based on these classifications. An excellent assistant for building process activities is ISO 9001.
Before describing individual processes, you need a clear picture of what to describe. This is where the process registry comes in — a single master list of all company business processes with key attributes for each entry.
The registry is not a diagram and not a regulation. It is a management tool that answers three questions: what processes do we actually have, who is accountable for each, and what has already been documented.
When you need a process registry:
The company is moving from ad hoc process description to a systematic approach
An ERP or BPM system implementation is being planned
You need to prioritize: which processes to describe first
An audit or certification is underway (ISO 9001, etc.)
Minimum fields for a process registry:
Field | Purpose |
Process ID | Unique identifier — links process to documents, tasks, and IT systems |
Process Name | Phrased as "Verb + Object": "MRO Procurement Management", "Recruitment & Onboarding" |
Level (1–4) | Makes hierarchy visible; prevents confusing strategic processes with operational ones |
Process Type | Value-Creating / Management / Support |
Process Owner | A named individual (not a department) accountable for outcomes |
Process Manager | Who ensures day-to-day execution |
IT System | Which system automates (or should automate) this process |
Notation | Description method used: Flow Chart, BPMN, EPC, etc. |
Description Status | Documented / In Progress / Needs Update / Not Documented |
Priority | High / Medium / Low — for sequencing documentation work |
KPI / Metric | Key performance indicator for this process |
Regulation / Document | Link to the governing policy or procedure |
Last Updated | When the entry was last reviewed |
Download the process registry template with sample data:
Registry maintenance guidelines:
Start with levels 1–2. Ten to twenty rows covering the most critical processes beats two hundred rows that no one maintains
The registry is a living document. Review it quarterly: have processes changed, are owners still current?
Only add processes you are genuinely committed to documenting and maintaining. A row without an owner creates the illusion of order — nothing more
Another question that will arise when starting a process activity is the number of process levels. As a rule, there are 3-5 levels of processes.
We recommend the following gradation
Level 1 - general
General description of the company's activities. VAD-scheme of the entire organization. Just like the organizational structure allows you to see the overall picture of the organization.
Level 2 - strategic
External processes are aimed at solving the strategic objectives of the enterprise; several departments can participate in them. So-called end-to-end processes. For example, the distribution of raw materials and materials among the company's production divisions. annual budget planning, strategy development, project portfolio planning, product management and development, strategic decision making.
Level 3 – tactical
Tactical processes achieve tactical goals. Planning of resources and monthly production plan, project management, quality control, order acceptance and production launch scheme.
Level 4 – operating
At this level, individual tasks and operations of the operation are performed: accepting applications, calculating CP, transferring to production, setting up a new employee’s workplace, etc.
Summary
Before dealing with operational processes, it is necessary to go through the upper levels - to describe the general scheme of the organization, it is also useful to describe the organizational structure, the processes of the upper level. And only after this do we move on to tactics and descriptions of individual operations. There is no need to rush and immediately dive into details. The operational level should be described primarily for critical and high-risk operations.
Describing a process is necessary — but not sufficient. Process management only works when every process has metrics: otherwise there is no way to tell whether it has improved or deteriorated, or why it was documented in the first place.
Before selecting specific indicators, you need to understand which measurement tool to use: KPI, OKR, or the Balanced Scorecard (BSC). These are different instruments for different purposes, and in the context of process management each has a distinct role. A full breakdown of each tool is available in the OKR vs KPI article →. Here we focus on how they apply specifically to business processes.
KPIs for Processes: Measuring Stable Operations
KPI (Key Performance Indicators) are the primary tool for measuring business processes. The core logic: KPIs are set for processes that are already established and running reliably, and they must be achieved at 100%. If a KPI is missed, something in the process has broken — and that is a signal to investigate the root cause.
There are four approaches to defining process KPIs:
By Cost — how many resources were consumed to execute the process. For example: cost to process one procurement request, labor hours to resolve one IT incident.
By Efficiency — ratio of output to resources consumed. For example: revenue per sales team member, number of tickets resolved per Service Desk agent per day.
By Results / Productivity — plan fulfillment. The most common type: production plan completion %, number of orders processed per period, output volume.
By Functioning — conformance to the required process algorithm. For example: payroll paid on time (yes/no), average payment processing time from invoice receipt to payment, % of requests handled within SLA.
💡 The optimal number of KPIs per process is 3–5 maximum. More than that, focus is lost and no one tracks anything meaningfully. The total number of KPIs across a company broadly corresponds to the number of processes being monitored.
Core metric groups applicable to most processes:
Time:
Cycle Time — from trigger to output (e.g., from procurement request to MRO delivery at warehouse)
Lead Time — total elapsed time including queues, wait states, and approval steps
Processing Time — active working time only, excluding waiting
Quality:
Defect / Rework Rate — share of process instances where the output had to be redone
First Pass Yield (FPY) — share of instances completed correctly on the first attempt
Number of Complaints / Claims — internal or from customers
Productivity:
Throughput — number of completed process instances per period
Participant Utilization — proportion of working time spent on this process
Cost:
Cost per Process Instance — FTE cost + IT + overhead per unit of output
Cost of Error / Rework — what a single process failure costs
Automation:
Automation Rate — share of steps completed without manual intervention
Labor Savings After Automation — measured in hours or currency
OKRs for Processes: Measuring Change and Transformation
OKR (Objectives and Key Results) is not a tool for stable processes — it is a tool for changing and improving them. Where a KPI says "the process is running normally," an OKR answers the question "how do we make this process significantly better."
The key distinction in the context of processes:
Process KPI | Process OKR | |
Purpose | Monitor stable performance | Drive transformation and improvement |
Target | 100% achievement | 70% is already a breakthrough |
Cadence | Monthly / weekly | Quarterly / semi-annual |
Linked to pay | Monthly / quarterly bonus | Quarterly / semi-annual bonus |
Example | Procurement cycle ≤ 15 days — met/not met | Reduce procurement cycle from 30 to 10 days within the quarter |
Practical rule: KPIs are for processes that have been documented and stabilised. OKRs are for processes you are actively optimising or transforming. For example, if you are rolling out electronic document management and want to shift 100% of requests to digital — that is an OKR. Once the transition is complete and the system is stable, it becomes a KPI ("share of digital requests ≥ 95%").
💡 OKRs must not be tied to regular monthly salary — this undermines motivation. OKRs are about ambition and growth; KPIs are about operational stability. How to combine both systems is covered in detail in the OKR vs KPI article →
BSC: Where to Find the Right KPIs at the Company Level
When you need a metrics system not just for one process but for the entire organisation, the Balanced Scorecard (BSC) provides the framework. It structures metrics across four perspectives:
Finance — What are our financial goals? (revenue, profit, cost)
Customers — How do customers perceive us? (NPS, satisfaction, retention)
Internal Processes — Which processes must we excel at to satisfy customers and hit financial goals?
Learning & Growth — What capabilities and resources do we need for those processes to work well?
The "Internal Processes" perspective in the BSC is the direct bridge between company strategy and process management. It identifies which processes are critical for achieving strategic objectives — and those are the processes that most urgently need passports, owners, and KPIs.
How BSC connects to the process registry:
Company Strategic Goal
↓
BSC Perspective: "Internal Processes"
↓
Priority processes in the registry (Level 2–3, High priority)
↓
KPIs in the process passport
↓
Ongoing monitoring by the Process Owner
Choosing the Right Measurement Tool
Situation | Tool | Logic |
Process is documented, stable, needs monitoring | KPI | Measured regularly, target = 100% |
Process is being optimised or automated | OKR | Stretch goal for the quarter, 70% = success |
Need to decide which process KPIs matter most | BSC | Prioritise through strategic perspectives |
Process is unstable or chaotic | Document and stabilise first | Nothing to set a KPI against until AS-IS is clear |
Where to source metric data:
IT systems (ERP, BPM, CRM, ITSM) — primary source for automated processes
Logs and registers — for non-automated processes
Surveys of participants and customers — for qualitative indicators (NPS, satisfaction)
Audits and compliance checks — for regulatory and conformance metrics
Full guidance on choosing between KPI and OKR, avoiding common metric pitfalls, and designing a motivation system — in the OKR vs KPI article →
If the registry is the catalogue of all processes, the process passport is a structured description of a single process. The passport attaches to the process diagram (notation) and contains everything participants, managers, and the IT team need to know.
The passport answers: why does this process exist, who is accountable, how do we know it is working well, and what resources are required to run it.
Process passport structure:
Block 1. Identification
Process ID and name
Level and type
Version and last updated date
Links to parent and child processes
Block 2. Objective & Scope
Process objective: what it produces and for whom
Trigger / input: what initiates the process
Output / result: what constitutes completion
Start and end events
Block 3. Roles & Responsibilities
Process Owner, Manager, Executors, Architect, Auditor, IT Process Owner (see the "Roles in Process Management" section for full descriptions)
Block 4. Resources & Tools
IT systems involved in the process
Governing documents and regulations
Notation used and link to the diagram file
Block 5. KPIs & Metrics
Metric name, calculation formula, target value, measurement frequency — with KPI/OKR classification and BSC perspective (see the "How to Measure Process Performance" section)
Block 6. Change Log
Version, date, author, summary of changes
Download the process passport template with a worked example (MRO Procurement Management process):
Practical tips:
The passport and the diagram are stored together — in the same folder or the same file. A diagram without a passport is just a picture
Versioning is mandatory. Processes change, and you need to know what changed and when
You do not need to fill in every field immediately. Start with identification, objective, roles, and one KPI — this is sufficient for a version 1.0
One of the most common mistakes when launching process management is: processes get described, diagrams get drawn, everything goes into a folder — and then gets forgotten. A process only stays alive when someone is accountable for it. That's why key roles must be built into the process registry and into every individual process description from the start.
Below are the core roles to define both in your company's overall process registry and in the passport/description of each individual process.
Process Owner
Who it is. A manager who bears end-to-end accountability for the process result — from input to output — regardless of how many departments are involved.
Responsibilities:
Defines process goals and KPIs
Initiates changes and optimization
Aligns resources and priorities
Reports to senior management on process performance metrics
Important: the process owner and the department head are not the same role. The "Procurement" process may be owned by the Chief Commercial Officer, even though 3–4 departments participate in it. This is especially relevant for cross-functional (end-to-end) processes.
In the process registry: full name, title, department.
Process Manager / Process Curator
Who it is. The operational manager of the process — the person who ensures its day-to-day execution in accordance with the documented description.
Responsibilities:
Monitors compliance with regulations and procedures
Identifies deviations and escalates issues to the Process Owner
Organizes training for process participants
Maintains the change log and incident register
Distinction from the Process Owner: the owner is accountable for what the process delivers; the manager is accountable for how it runs. In smaller companies or simpler processes, these can be combined into one role.
In the process registry: full name, title, contact information.
Process Participant (Executor)
Who it is. An employee or system that performs specific steps or functions within the process.
Responsibilities:
Executes assigned operations in accordance with the regulations
Records results (in the system, log, or document)
Reports deviations and failures to the Process Manager
In the process description: defined at each step (swim lane, or the "Executor" column in a table).
💡 One process step = one accountable executor. If "department" is listed — that's diffused accountability, and it leads to chaos.
Process Architect / Business Analyst
Who it is. A specialist who models, documents, and optimizes processes. May be a permanent staff member or engaged on a project basis.
Responsibilities:
Develops and maintains process descriptions (notations, regulations)
Maintains the process registry and knowledge base
Conducts AS-IS / TO-BE analysis
Supports automation: translating process descriptions into IT requirements
In the process registry: listed as "Description Owner" or "Model Author."
Process Auditor / Quality Controller
Who it is. A role responsible for verifying that actual process execution matches its documented description and quality standards.
Responsibilities:
Conducts scheduled and ad hoc process compliance checks
Collects and analyzes metrics (cycle time, deviation rate, NPS, etc.)
Prepares reports for the Process Owner and management
Initiates corrective actions
Context: in large companies and industrial holdings, this role is typically assigned to the Internal Control function, Quality Control department, or a dedicated BPM Office.
Process Sponsor
Who it is. A senior executive or board member in whose strategic area of interest the process sits. Most relevant for cross-functional and strategically significant processes.
Responsibilities:
Allocates resources (budget, headcount, priorities) for process development
Removes organizational barriers between departments
Makes key decisions during major changes or inter-departmental conflicts
In the process registry: captured for Level 1–2 processes (enterprise-wide and strategic).
IT Process Owner / System Analyst
Who it is. An IT department representative responsible for the IT support layer of the process — systems, data, and integrations.
Responsibilities:
Ensures the availability and performance of IT systems supporting the process
Implements IT changes at the request of the Process Owner or Manager
Maintains data architecture and integration design in the context of the process
Context: this role becomes critical during process automation and digitalization. The absence of an IT Process Owner is one of the top reasons ERP and BPM implementations fail — the process is described, but the IT system doesn't support it because no one translated it into a technical requirement.
Summary Table: Roles to Define in the Process Registry and Process Description
Role | Process Registry | Process Description | Process Level |
Process Owner | ✅ mandatory | ✅ in the header | Levels 1–3 |
Process Manager | ✅ for major processes | ✅ in the header | Levels 2–4 |
Executor / Participant | — | ✅ at each step | Levels 3–4 |
Process Architect / Business Analyst | ✅ as "description author" | ✅ in the administrative section | All levels |
Auditor / Quality Controller | ✅ for regulated processes | As needed | Levels 2–3 |
Sponsor | ✅ for strategic processes | — | Levels 1–2 |
IT Process Owner | ✅ when automation is involved | As needed | Levels 2–4 |
Implementation Recommendations
Start with the process registry. For each process, three roles are sufficient at the outset: Owner, Manager, and Architect/Analyst. Add the others as your process maturity grows.
One process, one owner. Assign two people and effectively you have none. Shared ownership is not a governance model — it's a responsibility gap waiting to become a problem.
Separate role from job title. One person can hold multiple roles (especially in smaller teams), but the roles themselves must be explicitly defined — this eliminates grey areas during conflicts and audits.
Capture roles in the process passport header. Standard minimum: process name → level → owner → manager → executors → IT system → last updated date → description author.
In any digitalization initiative, the IT Process Owner is non-negotiable. Its absence is one of the leading causes of automation failures: the process is documented, but the IT system doesn't support it — because no one turned the description into an actual technical requirement.
The mistakes below appear consistently across organisations at different stages of process maturity. Most of them are not technical — they are managerial.
1. Documenting processes for the sake of documentation Processes are described, diagrams are drawn, a folder is created — and that is the end of it. No metrics, no owners, no action plan. Six months later the documentation is stale and has become an artefact of the past. Fix: before describing any process, answer the question "Why? What will actually change as a result of this documentation?"
2. Diffused ownership Two co-owners are assigned, or the owner is listed as "Supply Department" instead of a named individual. Result: when something goes wrong, accountability is unclear. One rule: one process, one owner — a specific person with a first and last name.
3. Documented once, never updated Processes evolve: new people join, a new system is deployed, regulations change. Outdated documentation does not help — it misleads. Review high-priority processes every quarter; all others at least once a year.
4. Describing everything in excessive detail Teams spend months documenting every step of every process, including what experienced staff already understand intuitively. Resources are exhausted; the practical benefit is minimal. Document what carries risk, where errors and rework occur, and where staff turnover is high.
5. The diagram is only understandable to the person who drew it A business analyst produces a detailed BPMN diagram across three pages, the manager nods, and staff open the file, close it, and carry on as before. Always validate: can a new employee follow the diagram without explanation?
6. Automating chaos The most expensive mistake: a broken process gets automated as-is. The ERP system faithfully replicates an inefficient sequence of actions — only now it costs ten times more to run. The rule: describe the process, optimise it, then automate. Never in reverse order.
7. Jumping straight to Level 4 without the enterprise view Teams rush to document operational processes (Level 4) without first building a top-level VAD diagram. The result: fifty detailed procedures that do not connect to each other, and no one understands how they relate within the broader organisational system.
What benefits does a business get from working with processes?
Well, if you have finished reading this article, then most likely the question in your head is: “Which notation should I choose? Which is better?” The answer is quite simple - none. You need to choose a notation for the task and command. The main criterion is that it be clear. You need to understand who will use your scheme and what the level of competence of these people is. If you are a young team/manager, then start with “high-level” notations, for example VAD , VSM . This way you will understand how your team works as a whole. Further, as practice shows, Flow Charting works well in Process notation. It is simple and suitable for managing a single process. Also a great option is Procedure notation in the same approach. For working personnel in our practice, an ordinary block diagram works well.
The most common mistake is drawing huge maps. It is not right. No one will look at the sheets. Choose a “piece” so that it fits on 1 screen or A4 sheet.
And as we said earlier - think about who will work with this description, he must understand the description. Therefore, it is possible to deviate from strict notations. Here is an example below - a description in the form of a simple block diagram and explanation, but this was enough for those who had to work with them, and this already made it possible to bring the description of what is on paper to what is in life.
Also an example of a job description with marriage
Another example is adapting the Process notation
You also need to understand that if you print 1 process on 100 pages, people will simply get confused. Yes, in our age, numbers still have to be printed, because some people still do not perceive monitors well, this must be taken into account. Secondly, not everyone has good large monitors or combinations of them. And in digitalization, we need to think about the convenience of those who ultimately use it all.
For tasks of business analysis and deep dive it is already necessary to use BPMN 2.0 or EPC, for designing IT systems - IDEF.
Another rule is to think about the culture in your company.
The advantage of startups is high flexibility and focus on results. At the same time, due to the total refusal of formalization, big problems with efficiency arise. In large companies, on the contrary, there is a problem of excessive bureaucratization, which kills productivity.
In addition, the more mature an organization you are, the more resources you can allocate, the more complex combination of notations and more detailed descriptions you can use. If you are a small team with limited resources and changes are quite frequent, then you will simply drown in these descriptions
Final list of recommendations:
You need to start working with processes from the moment you found your product and buyer, started selling on an ongoing basis, and there are more than 10-15 of you
Initially, create a VAD diagram for the entire company and prepare a register of processes indicating the owner as well as the participants
Then use product management and systems constraint theory to select priority business processes
It is also important to describe those business processes that are stable and are the best practice for others. Or, conversely, a description of problematic business processes is useful
There is no need to describe every business process. Only those tasks that are either typical or pose business risks
Start describing processes with approaches that are clear to you and taking into account who will use them
Describe business processes so that they fit on one A4 sheet
When you hire a new employee, after 2 months ask him about which processes seemed too difficult and which ones were missing, n
Useful materials
Useful links:
