In the last five posts I outlined five ways that business process models are dificient when it comes to automating work. In this post I give a sixth, and quite possibly the most significant problem: Agreement takes effort, and once you have agreement, that agreement becomes a barrier to further change.
Coming to Agreement
Once the information is collected, and process discovery is completed, the next step is agreement by the stakeholders. The final approval for business process is by representatives of all the different parts of the organization that are subject to the business process. Stakeholders all have their own viewpoints on how their part of the process needs to be. They take into consideration details of their own parts of the organization to interpret what this diagram is going to mean to them. It is important to understand that while the process might meet their needs, their needs are not explicitly expressed in the process. If they can see that all of their own internal requirements are met by the proposed process they will approve process. They aren’t—and don’t need to be—explicit about what their detailed requirements are.
Any stakeholder might alternately determine that the proposed process does not meet their needs and perhaps even violates one of their working patterns. In this case the stakeholder will raise an issue with the process. The stakeholder will suggest a change to the process model such as to add one step in there, or to rearrange some other steps there, etc. The proposed process wasn’t quite right and the stakeholder is now communicating details necessary to make it right. The modified process is presented back to all stakeholders, who one again review it with regards to their unstated needs and goals. This repeats until everyone is satisfied.
Eventually you will come to a process upon which everyone agrees will do the job. Each stakeholder has concluded that the proposed process will not violate any of their implicit assumptions about the way their department or their unit works. The important thing to understand here is that the business process is not a complete representation of what is going on. The business process diagram and the business process model is an abstraction of the real world. It’s an abstraction which all the stakeholders have agreed is good enough to meet their needs. It takes them a bit of work to be sure that that abstraction doesn’t violate any of their working conditions. Once they get basic agreement, then as long as the business process and the organizations themselves remain static then that model will be sufficient.
After You Have Agreement, Change is Even Harder
The problem reappears when anything changes. Imaging that Department X has a reorganization which effects the way they hope to perform their part of the process. The stakeholder from department X will propose changes in the overall process to all the other stakeholders. If the business analyst change the process, the only way to know the new process doesn’t violate some assumptions from other stakeholders is to ask them to review and approve it again. This takes work! It can be a significant effort for the other stakeholders to review the changes, consider their internal constraints, and determine whether the change is acceptable or not. Remember that the process does not include the detailed concerns of all of the stakeholders of all of the other departments. The only way to ensure that the modified business process is acceptable is to go back to all of the stakeholders and ask whether the proposed change is acceptable.
That turns out to be a significant amount of work. The stakeholders:
- are people who have other significant jobs,
- have their own fires to put out, and
- rarely have the free time to review the business process models one more time.
- have already completed a large process review and approval which might have taken months to complete.
- are generally not willing to sit down every few months to revisit it.
- would like to see that process stay the same so they don’t have to go through the trouble of re-approving it.
- don’t really benefit from these changes so they have little motivation to expend effort on approving them.
The department bringing the changes will be criticized for not planned these changes earlier before the process model was approved the first time. They push back against this extra work. This push back can be so significant that it can delay the change of a model for many months in some cases years.
The irony is that the business process was put in place to make the organization more efficient and more effective but if you are prevented from updating the model by other stakeholders then departments may be forced to continue to function in a substandard way. Outdated process definitions can force departments into patterns that are worse than no process; it is not unusual for a department to expend significant effort simply maintaining conformance with an outdated process. There are a variety of different techniques that people used to work around this problem, but it remains a serious problem nevertheless.
Not a Technical Limitation
Don’t think for a moment that the inability to change an update processes is a technical limitation. A modern BPM system generally makes it quite easy to edit the process model and to put it into use almost instantly. Advanced BPM systems even allow multiple versions of the process to run at the same time so that you can introduce a new process before the existing running processes have completed. The limitation is not a technical one, it is an organizational one. Because the process model is shared across a number of stakeholders it is necessary for all the stakeholders to approve any change. This requirement prevents many changes which would otherwise be easy to do.
How Can the Problem be Agreement?
Wait a minute, this is crazy. It seems that the main argument behind having a business process model in the first place to have an agreed upon model that we all follow. If nobody agrees, then how do we have a process? Won’t it be complete confusion without agreement?
It is not that agreement is bad, but it is important to consider what you must agree to. The business process model brings the entire process into a single expression, and the agreement has to be on the entire process. The way that business processes are composed as a comprehensive, omniscient diagram of everything that is going to happen: people are forced to agree to the whole thing. Changes are impeded waiting for agreement if the change does not affect that person. Because there is one process model, and all the activities are on it, every stakeholder needs to re-agree to the changed model, but that is because they agreed to too much in the first place.
The solution, is to break everything into smaller chunks that clearly specify what you will agree to. Those are called “service descriptions”. Those are the right units to agree to. And will find out more as I disclose more from Beyond the Business Process Model here:
Pingback: Business Process Models are Not Agile | Thinking Matters
Pingback: Problem with the ‘Omniscient View’ | Thinking Matters
Agreement is based on the idea that everyone needs to know everyone else’s business. My department might work one way, but to get agreement, it is important that every other department agree that my department is doing things the way it should. That may seem reasonable on the surface, but do the other departments really know how to do my job? If they agree, itsn’t it less of a recognition that the process is right, and more of a recognition that they trust the head of the department? success in gaining agreement on a process model is less about doing things right, and more about having the story that persuades others how they should be done.
Pingback: Po shodnutí se na novém stavu jsou změny složitější | Průmyslové Inženýrství