Recently several online discussions and posts cover the subject of swimlane diagrams. Most voice concern that swimlane diagrams allow process fragmentation during design. It shows that process diagrams are being considered as a substitute for reality rather than a learning execrcise. Reality however, as Einstein made us aware of is not 3D but 4D, with time being an inseparable part of the continuum. 2D flowcharts diagrams are two dimensions away from showing a plausible model of reality. Therefore swimlane perspectives – when done right – can show the third dimension of organizational build and they show the fourth dimension in a timeline. And yes, I see swimlanes as very helpful as to which elements of an end-to-end process are performed by which process owning team.
But obviously, not only swimlanes are a means to end but so is process management! What it this end? Most would say it is increasing efficiency and effectiveness, when that is not possible in most cases for one and the same process. Efficiency is an internal perspective, while effectiveness is unmeasurable and uncontrollable customer perception. That is even true to some extent for internal customers and support processes. I take the view that process management has only one true end: NOT to build a command and control structure – but to create understanding! As Russel Ackoff pointed out so eloquently in his lectures on Systems Thinking: taking a British car to pieces does not tell you WHY it has the steering wheel on the wrong side. An explanation as to why cannot be found by taking something to pieces but it is always outside in the relationships to the other elements. Therefore a system is defined by the role of elements in the structure and not on their inner detail. A process diagram has to explain WHY a certain activity is executed in its relationship to the other activities. Taking a process to pieces does not tell you WHY a certain activity has to be performed. Even if you dissect it into the tiniest steps it won't tell you that. So much of the analysis is irrelevant. A swimlane diagram however is pretty good in showing relationships in the added two dimensions.
Additionally, one must be aware that swimlane diagrams are a VIEW ONLY. If that is not the case, then boy (or lady), have you got the wrong software! It is a perspective that one chooses and not a system component or an element of structure. One can choose nearly any kind of affinity in a swimlane grouping. Using functional or departmental names as the titles of the swimlanes is as valid as any other view if it helps anyone. But does it help? Yes, they are good for chronological and collaborative views. A swimlane VIEW can be valuable as a perspective of timing relationship versus work assignment without a mandatory sequence of steps or activities. It obviously has a hard time to deal with mutliple process variants, but that is a process design problem not a viewing issue.
What can I do to deal with all the process variations? Easy, stop to design with the help of rigid flowcharts! Or even better, stop to DESIGN processes, period! Especially if there are many process variations, one must control the process progression of multiple, parallel activities with states and rules rather than rigid activity links and decision gateways. In the Adaptive Process model I propose, the various perspectives possible with a swimlane become very valuable. It can show role, team or department lanes and yes, some views may not produce practical results for some processes. A different swimlane view does not change the process design! The question is how much design do we need at all? The benefit of dropping the flowchart design paradigm is that – given the right technology – business users can create processes on the fly and they never look at any diagram. Just at the reality of execution. If a change is needed, the process owners define together the intersections, the CEO defines the outcomes, and the process teams execute differently the next day, while verifying customer perception directly.
So what about hierarchies? Are they tumbling or not? Should we ask people to throw hierarchies out? Do we then create room-filling wall-to-wall covering flowcharts with or without swimlanes to get 10,000 people to change cooperatively? Process models are created that are then shown to everyone in the business so they all understand and then go back to their cubicles and change? What a total and naive illusion that is! People need actionable knowledge, not flowcharts or descriptive text what the rules are. Technology has to give them a clear understanding of the now, all decision information and set them free to collaborate with their team to completion. while applying those few rules that are a must. I am neither proposing all-out BPM nor all-out collaboration and empowerment. A departmental hierarchy is important for HR reasons and a process hierarchy is the CORE of process orientation. Hierarchy enables efficiency by work specialization and parallelization. The individual worker and his team only care about their job – of creating that customer perception and thus for effectiveness - and not about everyone else's. They aren't interested, they won't understand and it is utterly inefficient, as are too many rules. They also dislike that they are being told by others how to do their job! Clear boundaries and full empowerment within those are key elements of worker motivation. End-to-end processes are very difficult to achieve in a collaborative style because who will be the process owner? Collaboration and empowerment happens INSIDE the process owners team who can rely on a clear hierarchical process structure that defines the real-world deliverables between teams.
You can influence a hierarchy top-down but not processes and certainly not in a sustainable way. What is sustainable change supposed to be? That term makes no sense. The processes within a hierarchy can only change bottom-up. Change in the social organization of a business can only be inside-out and can't be driven from the outside. Yes, it is important that those who are changing understand that the customer uses a outside-in perspective to come to his perception of quality. Yes, it is important that the software provides the infrastructure for change and does not hold it back as most BPM/ECM products do. But the change can't be enforced or created by extrinsic motivation. Moving the cheese by giving bonuses for those KPI's ruins intrinsic employee motivation, as much research has shown.
All in all, the question of swimlanes or not is quite irrelevant unless BPM proponents will change and not just ask eveyone else to change to their unrealistic and inhumane process flowchart view of this world.
But obviously, not only swimlanes are a means to end but so is process management! What it this end? Most would say it is increasing efficiency and effectiveness, when that is not possible in most cases for one and the same process. Efficiency is an internal perspective, while effectiveness is unmeasurable and uncontrollable customer perception. That is even true to some extent for internal customers and support processes. I take the view that process management has only one true end: NOT to build a command and control structure – but to create understanding! As Russel Ackoff pointed out so eloquently in his lectures on Systems Thinking: taking a British car to pieces does not tell you WHY it has the steering wheel on the wrong side. An explanation as to why cannot be found by taking something to pieces but it is always outside in the relationships to the other elements. Therefore a system is defined by the role of elements in the structure and not on their inner detail. A process diagram has to explain WHY a certain activity is executed in its relationship to the other activities. Taking a process to pieces does not tell you WHY a certain activity has to be performed. Even if you dissect it into the tiniest steps it won't tell you that. So much of the analysis is irrelevant. A swimlane diagram however is pretty good in showing relationships in the added two dimensions.
Additionally, one must be aware that swimlane diagrams are a VIEW ONLY. If that is not the case, then boy (or lady), have you got the wrong software! It is a perspective that one chooses and not a system component or an element of structure. One can choose nearly any kind of affinity in a swimlane grouping. Using functional or departmental names as the titles of the swimlanes is as valid as any other view if it helps anyone. But does it help? Yes, they are good for chronological and collaborative views. A swimlane VIEW can be valuable as a perspective of timing relationship versus work assignment without a mandatory sequence of steps or activities. It obviously has a hard time to deal with mutliple process variants, but that is a process design problem not a viewing issue.
What can I do to deal with all the process variations? Easy, stop to design with the help of rigid flowcharts! Or even better, stop to DESIGN processes, period! Especially if there are many process variations, one must control the process progression of multiple, parallel activities with states and rules rather than rigid activity links and decision gateways. In the Adaptive Process model I propose, the various perspectives possible with a swimlane become very valuable. It can show role, team or department lanes and yes, some views may not produce practical results for some processes. A different swimlane view does not change the process design! The question is how much design do we need at all? The benefit of dropping the flowchart design paradigm is that – given the right technology – business users can create processes on the fly and they never look at any diagram. Just at the reality of execution. If a change is needed, the process owners define together the intersections, the CEO defines the outcomes, and the process teams execute differently the next day, while verifying customer perception directly.
So what about hierarchies? Are they tumbling or not? Should we ask people to throw hierarchies out? Do we then create room-filling wall-to-wall covering flowcharts with or without swimlanes to get 10,000 people to change cooperatively? Process models are created that are then shown to everyone in the business so they all understand and then go back to their cubicles and change? What a total and naive illusion that is! People need actionable knowledge, not flowcharts or descriptive text what the rules are. Technology has to give them a clear understanding of the now, all decision information and set them free to collaborate with their team to completion. while applying those few rules that are a must. I am neither proposing all-out BPM nor all-out collaboration and empowerment. A departmental hierarchy is important for HR reasons and a process hierarchy is the CORE of process orientation. Hierarchy enables efficiency by work specialization and parallelization. The individual worker and his team only care about their job – of creating that customer perception and thus for effectiveness - and not about everyone else's. They aren't interested, they won't understand and it is utterly inefficient, as are too many rules. They also dislike that they are being told by others how to do their job! Clear boundaries and full empowerment within those are key elements of worker motivation. End-to-end processes are very difficult to achieve in a collaborative style because who will be the process owner? Collaboration and empowerment happens INSIDE the process owners team who can rely on a clear hierarchical process structure that defines the real-world deliverables between teams.
You can influence a hierarchy top-down but not processes and certainly not in a sustainable way. What is sustainable change supposed to be? That term makes no sense. The processes within a hierarchy can only change bottom-up. Change in the social organization of a business can only be inside-out and can't be driven from the outside. Yes, it is important that those who are changing understand that the customer uses a outside-in perspective to come to his perception of quality. Yes, it is important that the software provides the infrastructure for change and does not hold it back as most BPM/ECM products do. But the change can't be enforced or created by extrinsic motivation. Moving the cheese by giving bonuses for those KPI's ruins intrinsic employee motivation, as much research has shown.
All in all, the question of swimlanes or not is quite irrelevant unless BPM proponents will change and not just ask eveyone else to change to their unrealistic and inhumane process flowchart view of this world.