Process Modeling Style

John Long

• Publisher: Morgan Kaufmann
• Year: 2014
• ISBN:
  9780128010402
• Topic: Business
• Subtopic: Business Intelligence
• Index: Business

Process Modeling Style focuses on other aspects of process modeling beyond notation that are very important to practitioners. Many people who model processes focus on the specific notation used to create their drawings. While that is important, there are many other aspects to modeling, such as naming, creating identifiers, descriptions, interfaces, patterns, and creating useful process documentation.Experience author John Longfocuses on those non-notational aspects of modeling, which practitioners will find invaluable.

• Gives solid advice for creating roles, work products, and processes
• Instucts on how to organize and structure the parts of a process
• Gives examples of documents you should use to define a set of processes

Chapter 1

Eight of the Biggest Process Modeling Problems

Process modeling projects are not always a success. They can often suffer from many of the same maladies that make other types of projects fail. However, there are specific errors that process modeling projects can fall prey to. This chapter describes some of those errors.

Keywords

Balance; diagram; text; architecture; interfaces; standards; relationship; roles; jobs; organization

Process modeling projects are not always a success. They can often suffer from many of the same maladies that make other types of projects fail. However, there are specific errors that process modeling projects can fall prey to. The following sections describe some of those errors.

1.1 Not Focusing on the Diagrams

Process models are a balance of workflow diagrams and descriptions of workflows. Workflow diagrams are the most powerful and expressive aspect of process models. The diagrams are the first thing that everyone wants to see and it is the diagrams that provide the construct for their understanding of the text. The workflow diagrams, in a very small space, convey tasks, sequencing, decisions, participation, and information. If a picture is worth a 1000 words, then complex workflow diagrams are the equivalent of, perhaps not exactly 1000 words, but at least several hundred. Modeling projects should exercise rigor in the creation of workflow diagrams because those diagrams are the expressive artifacts within the project. By “rigor,” I mean that workflows should actually follow logic, be consistent, and tell the story of how something happens. Some projects are careless in how they create workflow diagrams, and upon review, the diagrams don’t hold up.

1.2 Only Focusing on the Workflow Diagrams

On the other hand, process models do not rely on diagrams alone. Although diagrams are the most powerful aspect of a process modeling project, text and prose are very important as well. Text is really the only way to provide detailed descriptions of roles, work products, activities, and tasks. In addition, textual annotations are important additions to a workflow diagram to help elaborate upon what is happening within a workflow. The textual descriptions, when integrated well, help tell an overall story of the processes you model.

1.3 Ignoring the Process Architecture

A collection of processes defined by a business need to be crafted into an overall process architecture. This is not always easy, primarily because business processes are often done individually or in small projects, resulting in processes with the following characteristics:

• Unevenness, representing different levels of complexity

• Overlapping scope, with starting and stopping points that go over the same space

• Heterogeneous, with different process attributes

The resulting collection of processes will be difficult to use together. You may have to do a lot of redesigning and refactoring of the processes in order to make them usable together.

1.4 Ignoring Process Interfaces

As mentioned elsewhere in this book, processes rarely operate in a vacuum. Often, one process is only one cog in an entire mechanism that makes up a business. The work that is done by one process is almost always used by other processes to do their work.

For example, Customer Relationship Management (CRM) processes create market analysis reports that are used by marketing processes to forecast sales for an upcoming period. Product management processes use those forecasts to make decisions on whether to increase or decrease development activity. Portfolio management processes use those decisions to spawn new development processes. And it goes on and on.

Therefore, it makes sense to focus on the processes that interface with the processes you are working on. Even if those processes are out of scope for your modeling project, it is important to be aware of what processes are related to the ones you are modeling. Failure to identify process interfaces give a false sense that only the processes you are modeling are of any importance. This false understanding may give you tactical success, but it ultimately hurts the business.

1.5 Inconsistent or Nonstandard Notation

Too many projects are started without an agreement beforehand of the notation to be used. “Just start modeling,” they will say. “We’ll work out inconsistencies later.”

Of course, no one would tell programmers to just start writing code without first agreeing on the programming language to use. Technical writers would not start writing unless they first agreed upon the document template they would use. Software architects would not start envisioning the architecture unless they first understood the basic architectural and technical constraints they had to work with.

Yet, unfortunately, well-meaning managers who are inexperienced in process modeling projects just tell modelers to use whatever template or stencil they want from their favorite desktop drawing tool. This always leads to different workers defending their notation as the best one, causing team confusion and conflict. It is best to just nip that one in the bud at the beginning of the project. The lead architect of a project or the lead modeler of the modeling team should establish the practices to be followed. Failing to establish these standards at the beginning of the work will always cause scrap, rework, and delayed time to value.

1.6 Making Overly Complicated Workflows

Processes typically have interfaces with other processes, but they also have secondary effects on other processes. With process interfaces, one process actually passes a work product to another process. However, a process may also have an effect on other processes even if it does not specifically pass a work product to those processes. When this distinction is not made, workflow diagrams can become a confusing jumble of connections from one process or activity to another. The workflow ends up justifying any connection between any two parts of a workflow. This leaves implementers in a quandary, wondering how to implement it all. This is described in more detail in Section 9.5.

Another way a project can end up with overly complicated workflows is to identify any and all exceptions within a workflow. Workflows should start out with the “sunny day” workflow that indicates what happens when everything is working correctly. After that, the modeler should begin to add primary exceptions to the workflow that describe what happens when things do not go as planned. However, it is possible to model too many exceptions. In actuality, any process, no matter how automated, can be interrupted at any time and go in a different direction, but the value of modeling any and every exception is small. It is best to focus on the most important exceptions to a workflow.

1.7 Focusing on Jobs, Not Roles

Many organizations have a difficult time differentiating between roles and jobs. The differences can sometimes be subtle. When that happens, roles become jobs, and jobs become organizations. Tying a process to an organization can be problematic for a number of reasons.

First, organization-centric workflows can be used to justify the reason for an organization’s existence. The workflows can cause the stakeholders to focus on what the organization does rather than the work itself (whether current or target state). Instead of enabling organizational efficiency analysis, the workflows may help an organization further entrench itself in its behavior. The modeling becomes protective of an organization rather than helping the business improve its efficiency and effectiveness. Instead, a business should identify roles divorced from organizational ties.

Second, organization-centric workflows can restrict the thinking of the organization. Instead of thinking about the types of skills that will be required within the various roles executing a workflow, the organization may try to force-fit the workflow within the mission of an existing organization. The organization must be able to freely think about changing its organizational structure and organizational purpose in order to create a viable and long-lasting set of organizational processes.

1.8 Fuzzy Work Products

Workflows produce outputs. Those outputs are the results of real work that is performed. And those outputs, in turn, tend to be inputs into other work. Inputs and outputs are information work products. As such, these information work products should be defined in sufficient detail to provide guidance for a workflow. If a workflow does not have its work products clearly understood, then that workflow does not know what it is producing, nor does it know what it is consuming.

Sometimes, a process modeling project can concentrate so much effort on getting the flow of work correct that work products become ill-defined. Ill-defined work products may result in:

• Work products that are not tangible

• Work products that are ill-defined

• Fewer work products than are really needed

• Workflows that cannot be executed because no one knows what information is to be produced or received.

When a project allows “fuzzy work products” to exist, the implementers will have to do more work. It slows down implementation and there is a delay in time to value. Thus, fuzzy work products should be avoided. Take the time to define work products in sufficient detail so development will not be delayed.

Chapter 2

Selecting a Notation

To model processes, you have to select a modeling notation. By selecting a standard notation, you establish a standard way of creating your diagrams and a standard approach for integrating the work of multiple process modelers. This chapter describes the primary notations used in process modeling and highlights the most important pros and cons.

Keywords

Notation; flowchart; BPMN; LOVEM; use case; UML; IDEF0

To model processes, you have to select a modeling notation. By selecting a standard notation, you establish a standard way of creating your diagrams and a standard approach for integrating the work of multiple process modelers.

2.1 The Right Notation for You

The beginning of every modeling project should start with a review of the real goals of the effort and the various notation schemes that might apply.

Let me state up front that I have a preference for notation. I think Business Process Modeling Notation (BPMN) is the best notation for process modeling at this time. There are a number of advantages that I will describe later in this chapter. However, not all projects will use BPMN. There are a number of reasons for that, including:

• The sponsors of your project insist on using a different notation

• The modeling tool that you are using requires a different notation

• There is a large number of legacy models that you must integrate with that use a different notation

So, the right notation for your project is the one that works best for you. It is better to review t...

Table of contents

• Cover image
• Title page
• Table of Contents
• Copyright
• Dedication and Thanks
• Author’s Information
• Abstract
• Introduction
• Chapter 1. Eight of the Biggest Process Modeling Problems
• Chapter 2. Selecting a Notation
• Chapter 3. Process Modeling Goals
• Chapter 4. Defining Processes and Process Elements
• Chapter 5. Process Structure
• Chapter 6. How to Fix a Bad Workflow
• Chapter 7. Naming Conventions
• Chapter 8. Identifier Conventions
• Chapter 9. Workflow Connections and Relationships
• Chapter 10. Roles
• Chapter 11. Useful Process Documents
• Chapter 12. Tools
• Chapter 13. Conclusion: Which Style Elements Are Right for Your Team?
• Appendix. Using Process Standards