Your Next Process Model’s Degree of Abstraction

Any process model is so much more than a flowchart. It is an abstraction of current or future real-world operations.

Process modeling is one of the core competencies of any capable business analyst. Both the International Institute of Business Analysis (IIBA) Business Analysis Standard [1], and the Project Management Institute (PMI) Guide to Business Analysis [2] call for certified business analysts to be capable of preparing and using process models.

Business analysts and process improvement analysts may prepare process models at key points of business process management, information technology, and regulatory compliance project methodologies. They may specify current or future functional, organizational, and information systems architectures, functional requirements, workflow designs, and even automated operations. What any process model needs to communicate will vary from one project to the next.  The highest quality process model examples provide clear, accurate process information of direct interest to their readers.

Informed business analysts know that one of the secrets to producing a high-quality process model is to establish a clear mission for each model. To be successful, you should mindfully establish the mission of your next process model within the business process management, information technology, or regulatory compliance project that the model will serve.  You will then tailor your elicitations of the model’s content and configuration to meet project needs. Part of your process model mission-setting elicitation agenda will include asking and answering this important question:

What is this model’s required degree of abstraction? [3]

There are three generally accepted degrees of abstraction to consider: conceptual, logical, and configuration.

A Conceptual Process Model  

A conceptual process model graphically presents the defining structure of what a process is.

Business analysts, project sponsors, project managers, domain subject matter experts, regulators, and other process stakeholders use conceptual process models, for the following purposes:

• To make process governance and scoping decisions;

• To gain agreement about and communicate the process’s defined scope and structure, unequivocally distinguishing that process from all others in their business;

• To design enterprise architecture, to define technology solution architectures,

• To be the sound foundation on which forthcoming detailed problem analysis or detailed process definition is scoped out or planned;

• To support project management decisions (e.g. budgeting, scoping).

• To further elicit and fit logical process details upon its sound contextual and structural foundation.

Some business analysts and systems analysts might interpret the term conceptual to mean “high level”. That would be an oversimplification and a mistake. To serve its purpose, a conceptual process model should unequivocally define the sound, stable structure of the process. Despite being the highest degree of abstraction, a high-quality conceptual process model is still precise.  It can clearly and graphically communicate all of these process-defining information:

• The process’s name.

• The process’s initiating event(s) that causes the process to be performed.

• The process’s activities and their expected sequence of execution.

• The process’s expected outcome(s).

• The process’s customer(s).

A Logical Process Model

A logical process model elaborates contextually relevant details about how a process is required to operate, is designed to operate, or currently operates.

A high-quality logical process model could graphically, answer any of these types of how-elaborating questions:

• The decomposition or summary of some of the process’s activities.

• The rule-driven or decision-driven conditional work that may be performed. 

• The assigned responsibilities for performing the process’s activities.

• The data or information required to be used and/or produced.

• The causes of the process to be delayed or interrupted.

• The processing errors, that may occur while the process is executing and how will they be resolved? 

• The process’s related performance or measurement data, and text-based operating procedures, documents, or other specifications.

There is a spectrum of uses for logical process models. Process owners and analysts use logical process models to determine what and where to measure an existing process’s performance or to design and communicate proposed process improvements. They also define requirements for, or the design of manual or automated procedures, or describe the design of workflows.

Competent business analysts and process analysts can anticipate, elicit and document a range of logical refinement types, using clear agendas and reusable modeling patterns [4]. They also know that no two logical process models need to communicate all of the same types of logical refinements. So they will consider the model’s mission within each project and tailor their modeling efforts to focus on eliciting and documenting the types of logical refinements that suit each model’s intended use within its project’s methodology.

A Process Configuration Model

A process configuration model communicates concrete implementation mechanisms such as software operations and user procedures or workflows.

A process configuration model is the lowest degree of abstraction. Business analysts and systems analysts typically prepare process configuration models in low-code and no-code software platforms. The platform consumes the process configuration model along with detailed process-related roles, security, forms, system interface, and data specifications to generate operating software, on top of an already well-rounded software product architecture. There is otherwise no or very little programmer intervention in translating the model into working software. When updates to requirements or defects emerge, the analyst revises the configuration model, and the platform regenerates and redeploys the software.

You must adopt and adhere exactly to a chosen low-code or no-code platform’s process modeling syntax. You can learn that by taking the training offered by the low-code or no-code platform’s vendor. Along with a process configuration model, you would specify, in detail:

• System users, their assigned roles, and their responsibilities to perform the configured process flow.

• The sequence of execution of configurable functional components, of an automated end-to-end workflow.

• The configurable functional components involved in the process flow configuration. These are typically the user interfaces (e.g. forms, reports) system integrations (e.g. APIs), and the data attributes used in an automated process workflow. 

Since process configuration models are precisely translated into operating software and business operations, any errors or omissions in the modeling become errors or omissions in the generated software and business operations.  It stands to reason that to be a successful business analyst or systems analyst in a low-code or no-code environment, you must design process configuration models based on sufficiently detailed logical requirements, that you have elicited and understood. 

How to Choose Your Next Process Model’s Degree of Abstraction

Follow these guidelines to choose what the required degree of abstraction of your next process model will be:

Use conceptual process models to get agreement about and communicate what the process is. What is the scope? What causes it to be performed? What are the activities and their expected sequence of activities? What is or are the expected outcome(s)? Use conceptual process models for planning, scoping, and architecture definition.

Use logical process models to get agreement and communicate how a process works or is required to work. Be prepared to elicit and document the answers to logical details such as: What are the detailed or summary activities? Who is responsible for what? What happens if? What happens when? What decisions will be made? What information is produced or used? Remember to elicit and include the details that are relevant to your model’s intended audience: those who participate in the lifecycle of your business process management of information technology project. Keep your model's intended audience in mind when eliciting and documenting details. Use appropriate detailed logical process models for detailed functional requirements or design.

Use process configuration models to specify the configuration of concrete software modules, physical devices, and/or manual operating procedures that implement a process.

You typically use process configuration models in no-code or low-code software generation. To gain the benefits, you must specify very precise and accurate process implementation details, and exactly follow the process configuration modeling syntax.

Conclusion

A process model is not just a flowchart. It communicates what is, or will be real-world operations. It may play a crucial role in the success or failure of you next business process management, information technology, and regulatory compliance project.

The most competent business analysts and process analysts clarify what their model’s required degree of abstraction will be, at the start of their analysis. They then focus their own and their project stakeholders’ efforts and time on the types of model content and format that will best suit each project’s unique needs.  

You are welcome to learn more or share your comments and experiences about Your Next Process Model’s Degree of Abstraction via the Contact Us page at www.ProcessModelingAdvisor.com.

Copyright 2023, Edmund Metera

Author: Edmund Metera, Process Modeling Advisor

 Ed Metera is a Senior Project Manager at CWB Financial Group in Canada. Ed’s more than four decades of practical, successful Business Analysis and Project Management techniques span progressive roles with multinational IT consulting firms, serving many different industries. His recent track record includes highly successful business acquisition/integration, digital transformation, regulatory and enterprise systems programs, and projects. 

He teaches and mentors project managers and business analysts in best practices for professional organizations such as IIBA, PMI, and, CMMI, and bespoke business clients. Ed teaches IIBA-endorsed business analysis courses and is a program advisor to the Northern Alberta Institute of Technology's Corporate and International Training department’s Business Analyst, Process Analyst, and other certificate programs.

Edmund Metera is the author of the book: Universal Process Modeling Procedure: The Practical Guide to High-Quality Business Process Models Using BPMN (Amazon, 2018, 2022), the founder of www.ProcessModelingAdvisor.com, and several IRM Connects, Modern Analyst, and BATimes articles.

REFERENCES

[1] The Business Analysis Standard (IIBA, November, 2022)