The More People Involved, the Greater the Effect of BPM Implementation

The more people involved in a business process, the greater the impact of implementing a BPM (Business Process Management) system.

Imagine that your operational business is freight transportation, and you manage around 100,000 railcars. You have thousands of clients and hundreds of employees. Let's say one of your processes is coordinating the route with the client that the cargo will follow. The result of this process is a confirmed route, and railcars are prepared for loading.

Several departments are involved in this process, each playing a different role. Every day, company employees perform hundreds of actions to achieve the final result. These are known as end-to-end processes—they are large, complex, and vital to the business.

Economic Benefits from Simplification

Significant economic benefits can be achieved by simplifying such processes.

As a result, customers can get a cheap burger in five minutes, and the company earns millions—everyone’s happy (especially the shareholders 😊).

Success Depends on Business Requirements

When you automate a business process, project success depends on many factors, but the key one is the quality of business requirements.

While the term "business requirements" might seem clear, in practice, everyone interprets it differently.

As a result, poorly defined business requirements might:

• Fail to cover the full scope of the process.
• Complicate the process instead of simplifying it.

If business requirements are weak, the work of all other teams becomes meaningless—and that’s dozens of IT specialists: system analysts, developers, architects, testers, and more.

Imagine a Michelin-starred chef preparing a dish using spoiled ingredients—and missing some of them. The chef might execute the recipe perfectly, but the meal will still be dangerous to eat. The same goes for projects with poor business analysis.

High Stakes in End-to-End Process Automation

In end-to-end process automation projects, the stakes are high: 3–12 months of work and a full development team's budget.

To minimize risks related to poor business requirements, we've developed a checklist:

"Business Requirements Completeness and Consistency Check"

Think of it as checking the ingredients before cooking. Do we have everything needed for the dish? Are all the ingredients fresh and high-quality? If yes, then the customers will be delighted.

The checklist is divided into sections, and we verify business requirements against each block. The fewer items are filled in, the higher the risk of significant delays and budget overruns.

Project Composition and Objectives

The following elements should be clearly defined and documented at the beginning of the BPM initiative:

✅ Stakeholders and Process Owners

A list of stakeholders and business process owners must be documented.
For each individual listed, it should be indicated:

• Which process they are responsible for, or
• Which process they participate in.

✅ Expected Benefits from Process Implementation

The document should describe the anticipated benefits of implementing or transforming business process(es). At least one of the following must be clearly stated:

• Economic advantages (e.g., cost reduction, increased revenue);
• Labor savings (e.g., fewer manual steps, reduced human error);
• Compliance with a company legislation or information security standards;
• Other measurable benefits, both quantitative and qualitative.

✅ List of Target Business Processes

The document must include a list of business processes that are subject to transformation in order to achieve the declared project benefits.

• If a process does not exist in the company’s official registry, the project team should propose a custom process name.
• The name should be concise—ideally no longer than 1–2 sentences.

✅ Brief Description for Each Process

Each business process must have a short description (approximately 150–300 words) that captures:

• The core essence of the process;
• Written as a self-contained paragraph, without references to other texts or documents.

This helps ensure clarity and alignment across the team when initiating analysis, modeling, and subsequent automation steps.

Business Process Description

This section applies to each business process declared within the project.
Each process must be described end-to-end, including all activities involved.

✅ Defined Process Boundaries

• The start event triggering the process is identified and described.
• The preconditions required before the process can begin are listed (e.g., system states or prior approvals).
• Entry points into the process are outlined (e.g., through user action, scheduled job, or external system input).
• Expected results and outcomes upon successful completion are clearly stated.

✅ Main Process Scenario

• The main flow of the process is described step by step, starting with the successful (happy path).
• Afterward, all alternative and exception (error) branches are detailed.
• The description is linear and self-contained — reading other sections of the document should not be necessary to understand the process.

Note: If a business, functional, or non-functional requirement appears at multiple stages, it must be fully described at each point of use (not referenced separately).

✅ User Actions (Inside and Outside the System)

• The process includes all user actions, even those outside of the system, that are essential to achieving the business result.

✅ As-Is and To-Be Process States

If process changes are expected as part of the transformation:

• The document must include both current state (“as-is”) and target state (“to-be”) process diagrams.
• Both diagrams must be accompanied by explanatory text.

✅ System Mapping for Each Step

If specific systems are predetermined:

• Each step or stage must clearly state in which system it is executed.
• If a step is performed outside any system, that should be explicitly noted both in the text and in the diagrams.

✅ Recommended Notation

The recommended process modeling notation is BPMN 2.0.
Other acceptable notations include:

• EPC,
• IDEF0 (with IDEF3),
• Block diagrams (only if they meet all checklist criteria).

✅ Alternative Branches

• All possible alternative flows must be listed.
• Each alternative flow must specify:
  • The step where it branches from the main flow,
  • The triggering event,
  • The key actions in the alternative path,
  • The results of the alternative completion.

✅ Exception (Failure) Paths

• All failure scenarios must be documented, including:
  • The failure events,
  • The outcomes of unsuccessful process execution.

Note: If there are alternative flows, their related failure cases must also be described.

✅ Reporting Requirements

To ensure visibility and control:

• Metrics used to measure project success must be defined and linked to the process.
• Each metric must have:
  • A formula,
  • The business logic for its calculation.
• Reporting requirements from business stakeholders must be listed, including:
  • Report titles,
  • Metrics included in each report.
• For each metric or calculated value, steps to collect necessary data must be embedded in the business process.

By fulfilling all the above, the business process documentation ensures traceability, accountability, and a foundation for reliable automation and analytics.

System Integration Description

✅ Integration Points Identified

• All integration points with external systems have been identified and described — or it's explicitly stated that none exist.
• Each step that uses data from another system is clearly marked.
• The purpose of using external system data is documented within the business process context.
• The external data is sufficient to complete the step or fulfill the goal of the process.
• The frequency of data exchange is specified (e.g., time interval or event-based).

🔄 Optional Enhancements for Complex Processes

These elements are recommended if the business process:

• Has more than 7 steps, and
• Involves 2 or more roles (executors).

✅ Status Model of the Business Process

• A status model is provided to simplify understanding of intermediate outcomes.
• The model covers both alternative and exception branches.
• It helps visualize current progress and identify process bottlenecks.

✅ Access Roles and Permissions

• All roles and access rights required for the process are listed.
• The document describes:
  • Which operations are performed by each role,
  • What data each role must access according to business logic.

✅ Change Tracking and Monitoring

• It is defined who should be able to see the change history and at what level of detail.

✅ Glossary

• A glossary is included, defining all terms and abbreviations used in the document.

✅ Internal Consistency

• There are no contradictions within the business requirements.
  Each requirement is logically aligned and does not conflict with others.

Use Case Requirements

Use when the target IT system is known in advance, and the desired behavior is understood.

✅ Use Case Traceability

• There is a clear mapping between use cases and business process steps.
• For multi-system processes, the document specifies which system executes each use case.
• User actions and system responses are detailed for each step.
• The description of each use case is atomic and complete — no need to look elsewhere for critical implementation details.

Final Thoughts

Anyone who’s ever attended a driving school may recall instructors saying,

“Traffic laws are written in blood.”

The same goes for our checklists — they are built from missed deadlines, budget overruns, and project failures.
Each point reflects one or more “accidents” we've encountered in real-life projects.

Since implementing the checklist "Verifying Business Requirements for Completeness and Consistency", we’ve consistently saved between 15% and 30% of initially planned budgets.
Project timeline accuracy for business requirement implementation has approached 95%.