Process Modeling Motivation
Process, simply defined, is how we do what we do, that is, the knowledge of how work gets done within an organization. This knowledge is usually internalized in a person´s head. In other words, it is tacit, undocumented knowledge and that is difficult to analyze, evaluate or transfer to others involved in the process. In order to perform the actions required to execute the process, the knowledge must be made explicit, that is, documented in one or more formats such as a flowchart or a video that makes it easy for those involved with the process to understand it and use it.
The process for documenting a process and making it explicit is pretty much the same, whether you are documenting an existing process or redesigning and documenting a new process.
If the process already exists, the knowledge needs to be extracted from the current performers and specialists. On the other hand, the new process proponents should formalize the knowledge after listening to the process owner, actual performers and specialists. In both cases, the knowledge must be made explicit, by capturing it from its sources, expressing it in a comprehensive way, delivering it and making it available to those involved in working with the process. The documented process must be used to train and support performers to assure that all parties will execute the process in a consistent manner.
Process Knowledge Dynamic
According to Zaharan, “A process document is a dead object. It only comes alive when it's transformed in knowledge, in people's brain, and only becomes effective when this knowledge directs these people's behavior.” Process Modelling is a tool for documenting process knowledge and making it available to performers, enabling them to execute the process in a standardized way. To summarize, to have value, process knowledge must be documented and externalized in one or more forms and internalized by performers of the new process. Figure 1 below graphically illustrates the transfer cycle that gives process knowledge value.
Process Modelling Current Situation
Generally speaking, process modelling is done to achieve the goals of a mandate. For example: Document all processes in the organization. However, in following the mandate, several issues and concerns must be identified and addressed. Specifically:
- Applicability of the generated models – The generated models do not observe the proper use of the knowledge, giving rise to questions regarding its applicability;
- Cost of modelling in terms of ROI – The modelling has a resource cost that does not provide a reasonable return on investment.
- The model creates overly detailed models that do not prove useful to those directly involved in the process – It is exhaustive in detail, making it difficult for those using it to gain a general understanding of the process, or the specifics regarding any part of the process.
- The model does not adequately describe what is being done or will be done in the future – The modelling just exposes the organizational units to internal inspections, since what is described, in most cases, is not what is being or will be done.
Following describes what I consider to be the 10 most common mistakes in Process Modelling and provides suggestions for ways to avoid them.
1. Failure to understand modelling as a communication tool.
The externalization of knowledge is only valuable to the organization if there is effective transfer of this knowledge from the source to the user. This is the essence of the communication process, as described in Figure 2.
The communication theory is applied to processes Modelling in accordance with the points presented below.
- The original sender is the performer who has the knowledge of the existing process or is the proponent of the new process; the receivers are the performers who will execute the revised or new process. The knowledge is the message to be transferred. There will only be successful communication if there is a comprehensive understanding of the knowledge and an effective delivery of the knowledge to the receivers/performers.
- This transfer occurs in two stages: in the first stage the knowledge is transferred from specialist to the Process Analyst and in the second stage the knowledge is transferred to the performers, connecting the original sender with the receiver/performer.
- The Process Analyst is responsible for promoting efficient communication between the specialist and the performer, using a specific notation/language, appropriate for the goals and purposes;
- It is necessary to establish a communication language and vocabulary common to the specialist, performers, and other persons involved in the process. This common language is a critical element if the communication is to be successful.
- The two biggest deterrence to effective communication are (1) too much information – information that the new performers already know or information that isn't relevant to the specific task, and (2) lack of information – absence of information that performers need to know to perform the job.
2. Modelling without a clear articulated goal
The main goal of process modelling is to externalize the knowledge about how things are done, making that knowledge available for specific purpose including but not limited to:
Standardization goals include:
In this case, the knowledge about how things are done should be used to identify and document opportunities for process improvement. This doesn't mean that all the opportunities for improvement can be achieved immediately. It simply states identifies and documents the opportunities. Implementation of the changes will be determined based on priorities, and available resources
In this case, a new version of the process will be generated that improves the level of performance of the process and problems that interfere with the expected performance of the process should be eliminated.
- Other initiatives related to process
Other initiatives might include:
- Activity-based cost, Risk Identification and Mitigation or Security Problems Identification. In these cases, it is necessary to assure the standardization of the modelling to avoid dealing with theoretical costs, risks, controls and security solutions instead of the real ones.
- Systems Development. In this case, the process modelling, through its flow, procedures and business rules, becomes the major input for the systems programming that will support or automate the process and serves as the basis for the work required to define the specifications for systems development.
- The answer to the question “Why are we going to document/model this process?” determines the objective of the process modelling initiative.
- The objective should also include the definition about who will use the externalized knowledge, what level of detail is required and the expected return on investment of the initiative.
Process Modelling should not be an end in itself.
3. Using the same notation regardless of the target users
The process documentation can serve several purposes based on the needs of the many users involved in the process. The table below highlights some users and stakeholders and their goals, defining notation requirements and some possible representation forms.
BPMN (Business Process Modelling Notation) has become the preferred notation for process modelling. It's important to say that this notation was created with the specific goal of automatically generating process control flow. It is, therefore, very formal and is designed primarily for those involved in systems design. Use of this notation, in its complete form, will not be understandable or usable by most business managers. The restricted use of symbols, in the early stages of modelling, with the gradual addition of symbols as new audiences and new details are added, is a highly recommended practice.
It is worth noting that the level of detail adopted should be commensurate with the modelling goal. Thus, modelling for cost management, for example, will be different from the modelling for standardization in terms of target audience, process attributes, detail level of activities and procedures, to name a few.
4. Not setting reasonable expectations regarding the modelling purpose
Process modelling, as an end in itself, will not generate any measureable benefit to an organization. It is only when the process model is standardized and implemented that measureable benefits will be achieved. Many companies have invested in current process modeling and expect, as a result, a performance improvement, that will not come. It should be made very clear what to expect from each of the several initiatives.
5. Modelling without a well-defined context for the communication process
Process modelling requires definition in three phases, each phase establishing the communication context for the next. The phases are:
This level defines the process name such as “make widget”
This level describes what the process does and provides context for the process by describing why the process exists, where the process begins and ends, and what the primary steps of the process are.
This level determines how things are done; it is the explicit process knowledge, and includes practices used to achieve repeatability and standardization of implementation. It consists of activities, control flow, procedures and others tools that aid in implementation, such as: checklists, policies, forms, etc.
6. Not identifying and organizing the process parts before modelling them
The process description strategy should take into account the communication requirements for the both the modeler and the user and, the complexity of the process. This requires a successive decomposition approach. Besides understanding facilitation, this approach can provide information to different users at the exact level of the required detail. Failure to decompose the model in this manner will result in very large and incomprehensible models, leaving many users confused and unable to understand the model.
7. Not establishing the appropriate level of detail for the model's purpose
As previously stated, the goal of process Modelling is to transfer the ability to carry out the process from some process performers others. It makes important to observe a golden rule: the knowledge to be made explicit and transferred is represented by the gap between what the performer already knows when he assumes his role and what he needs to know in order to perform his/her tasks. (see Figure 3). It is not necessary to describe the technical knowledge required on the part of the performer (doctor, accountant, salesperson, manager, etc.), as their functional role requires them to possess that knowledge. The knowledge to be externalized is usually composed of the rules and activities of the non-technical skills required to perform the process in each specific organization.
8. Not properly evaluating the knowledge transmission capacity of the model developed
Once modelled, the process is sent to the source of information, process specialist, for validation. Since the specialist already has the knowledge necessary to fill this gap, he or she rarely identifies a lack of information in the documentation. Information overload is tolerated since the specialist has prior knowledge of everything documented. It seems obvious, therefore, that the future performer should do the validation/certification of the modelled knowledge. The performer is rarely involved in the evaluation process and should be, since he or she is the final target of communication.
9. Confusing acceptance of the model with adoption of the model or confusing documentation of the process with establishment of a process standard
Many process modelling initiatives end in a process portal without providing the training and support required to enable the performers to execute the process. The mere publication of the model is not sufficient for the adoption of a process model as a standardized of work in the Organization.
10. Including all information necessary to assist the process execution procedures
The documentation should include all the information necessary to implement the process but should be structured considering the performers´ needs. Thus, the information distribution of various kinds, such as flow, procedures, policies, systems manuals, checklist, etc., should consider hypertext mechanisms, from the flow and the procedure with access to complementary information.
The appropriate amount of information, within the defined context and with direct access to the desired points, is what makes the Process Model useful and relevant. This avoids creating documentation that is laden with far too much unstructured information leading to mind numbing reading that is not useful and making the documentation seldom used.
Process Modelling and Governance
Processes models only have value if kept updated, reflecting the way things are really done. Processes should be stable but never static. The lack of clear Governance rules for keeping models updated can cause all the effort in creating these models a waste of time, reinforcing the notion that modelling is a useless endeavor.