Process Model

A process is a set of activities that interact to achieve a result. A process model is a graphical representation of the particular process, which shows the order of the individual process steps along with the indication of who actually performs the steps.

In the context of analysis, the process models represent:

• business process describing how specific parts of the business work
• process within a system showing how a particular part of the business process is realized in software
• workflow specifying the flow of artifacts (task, document, information) in the system from one person to another until a result is achieved

Usage

Processes are everywhere. Each organization is basically an organized system of processes and activities which are performed across the organization units, interact with each other, and transform inputs to outputs. Also, most information systems are based on processes and workflows as the trend is building process-oriented systems that force employees to perform their work in the specific order. With this approach, employees know exactly what the next step is instead of having to find the best way of completing the task themselves.

Processes exist on all levels, from business level to systems, so they are an inevitable part of analysis work. Process analysis is performed to understand how the particular process works at the moment (as-is analysis), how it should work in the future (to-be analysis), or how the processes will be impacted by the anticipated change (delta between as-is and to-be).

If you do not know your processes, you cannot discover the impacts of changes.

High-level processes also represent an essential part of overviews. They can nicely depict the individual process steps together with the information about who performs the steps, in which system, and what outputs the step produces.

Process Representation

The standard form of describing processes is a visual model. Rather than using free-from diagrams, in most cases, analysts use the standardized notations, such as UML Activity Diagram, BPMN (Business Process Model and Notation) or a Flowchart.

Which one to use? Unfortunately, there is no right answer. BPMN was designed specifically for modeling business processes, so it has the most expressive power in this area. But its main advantage is also its biggest disadvantage. It is basically a one-purpose diagram, and what is more, to be powerful, it must be complex, which makes the more advanced features hard to read for the business people. Unless you work in a dedicated team focusing exclusively on process modeling, the sooner or later the main disadvantages of the BPMN will become evident:

1. Complex notation which very few people know thoroughly
   • Very powerful but its potential cannot be fully used as ordinary stakeholders cannot quickly learn it
2. One-purpose notation focused solely on business processes
   • Not a problem when the goal is to analyze only business processes. However, if the intention is to start with the business process and continue elaborating it deeper, possibly to the systems level, the BPMN will not be sufficient and will need to be combined with other techniques.

If any of the concerns above applies to your project, we recommend sticking with the UML Activity Diagram. It has the same expressive power and can be used on all levels of abstraction.

Good Practices

Visual Style

Process models should follow the common diagram guidelines to be easy to understand and maintain.

It is not that the above diagram is incomprehensible, but it could obviously be improved:

1. Naming - Process steps should not include actors or systems names and should meet basic naming conventions - use active voice, present tense and start with a strong verb
2. Swim Lanes - to indicate who performs the step and/or in which application the step is carried out, use swim lanes
3. Layout - the diagram looks neater if the elements are aligned and placed evenly. The elements should also be placed with respect to the process flow so that it could be read from left to right or from top to bottom

Consistent Granularity

Understanding a process usually requires modeling it from multiple levels of detail. The first step is describing a high-level L1 process, which shows the overall picture. When the basic flow is known, it is possible to continue describing the more detailed levels (L2, L3, etc.) where each level specifies one step of the parent process level. However, analyst must ensure that the level of detail of each layer is consistent.

Simple Diagrams

Process models, especially the business process model, are the type of diagram which is usually meant to be discussed with the business people. Most stakeholders can learn the basics of BPMN or UML Activity Diagrams very quickly, yet we cannot expect them to learn the advanced features. For this reason, if the audience is business stakeholders, analysts should try to make the diagrams as simple as possible, applying only the basics of the selected notation.