- Model your Process
- Manage your Process
- Monitor your Process
- iMprove your Process
Roeland Loggen said...
Maybe your story reflects one of the key issues with current BPM thinking: if the software provides automated concepts of a year 1890 shopfloor, then not much innovation has been created. Since 1890 many many new ideas have been created on people working in processes. The mechanistic view of typical BPM software has not clue of these more modern concepts.
The 20th century knowledge worker's reality and productivity is muh different from Taylor based process thinking... not based on orchestration, central coordination, workflow items, inbox/task screen.... but adhoc, collaboration, changing processes on the fly based on new insights and events....
For the sake of argument: If every 1890 shop floor had an exceptional Process Manager on hand, productivity would have soared... but Roland's right: We can't be satisfied to stop with systems that automate 19th century businesses. It's the 21st Century, and we can do better than that.
The key for doing better is Business Process Visualization (BPV).
In my 19th Century BPMS I discussed someone that I dubbed the "Process Visualizer". This is that person who took the raw metrics that the Process Manager had gathered and turned them into reports, charts and graphs that the Business Owner could use to understand the past and to plan for the future. These reports, charts and graphs are an integral part of BPV, but there's a whole lot more to the full picture.
BPV begins with the Process Diagram. The Process Diagram distills the essence of the problem into a form that Business and IT can share. It's a crucial part of validating that the process is correct and for communicating the requirements from the process owner to programmers who will implement the process application. In most of today's BPM Systems the life cycle of the Process Diagram often goes something like this...
The Business decides to improve their operations, so they hire an Analyst to come in and help them.
The Analyst talks to a lot of people and produces an "As Is" Business Process Diagram. This diagram is often used by the Analyst to reassure the Business that the Analyst really understands what's going on.
Now that the Analyst really understands what's going on, a new "To Be" Business Process Diagram is created. This diagram is used by the Business to capture exactly how they want the new process to operate.
At this point simulations can be run to predict how the new process will behave relative to the old. Simulation is always tricky, but if the assumptions are accurate (hopefully based on historical data), then it's sometimes possible to tune the "To Be" definition to increase the likelihood of success.
Once the Business and the Analyst are happy with the "To Be" diagram, it can be passed on to the Implementers (and it now becomes known as the "As Planned" diagram). The Implementers now morph the diagram into an executable diagram, usually adding way more details than the Business wishes to see.
Slight digression: There's a lot of controversy swirling around BPMN 2.0 over the issue of adding execution semantics to process diagrams. Implementers (in general) want truly executable diagrams but Business folks (in general) don't want to clutter the diagram with non-Business related details. I think there's a simple solution... which I will get to later.
The Implementers work with the Analyst and Business until all are happy and the process application is deployed into production... at this point the Implementer's diagram becomes known as the "As Built" diagram.
Note to all: The "As Built" diagram is a clear differentiation from all pre-BPM Systems. In a BPMS, the "As Built" really is the process that is running in production. Before BPMS the diagram may have been accurate once, but you never really had confidence that the diagram ever matched reality.
In some BPM Systems, the "As Built" diagram is often the end of the line. Once the process application is deployed they don't think about it much until the next time a process change is contemplated... However, in many BPM Systems the "As Built" morphs into a living and breathing "As Running" diagram.
Live and historical data breathes life into the "As Running" diagram. My old friend the Process Visualizer takes the raw data from the Process Manager and animates the "As Running" diagram to give the Business a clear view of what's happening where (and what happened when). The "As Running" diagram gives you your first glimpse of what BPV can achieve.
Thus far the Process Diagram has be limited to a pretty small audience - those involved in designing the process and those involved in implementing the process. BPV should expand the Process Diagrams visibility to a much wider audience.
Go into just about any office and ask a typical worker the following question:
"What Processes do you work on?"
Most likely, the response will be a blank stare.
Now ask the worker:
"What Activities do you perform?"
The blank stare will vanish and you'll get a very accurate litany of tasks.
BPV needs to give each worker the answer to that first question. It's not enough to know what Activities you need to work on - To do your best you really need to know how those Activities fit into a bigger picture. Process knowledge is a bigger picture, and it goes a long way to helping the workers understand why they are doing what they are doing.
A task that seem stupid in isolation may make sense when seen in a process context - or it may really be stupid. In the former case the worker may do a better job, and in the latter case BPV may give the worker the context needed to communicate their frustration.
When folks such as Lombardi's Phil Gilbert talk about BPM on every desk in an enterprise, this is what they are talking about. Process Visualization helps everyone put things in context, and that helps everyone do a better job.
Now for a bit of Devil's advocate: Most workers couldn't make heads or tails out of a BMPN diagram, and if you add all the execution semantics proposed for BPMN 2.0 that percentage is going to drop even further.
Granted, but there's a solution: Different views for different folks.
Returning to my programming roots... I am a huge fan of Aspect Oriented Programming.
Aspect Oriented Programming evolved from a simple fact: Most worthwhile endeavors can be broken down into distinct concerns, and often you can meet the goals sooner by dealing with these concerns (aspects) in isolation. Obviously there are limits to this when concerns overlap, but it's a good place to start.
With Aspects as my inspiration it's easy to see where Process Diagrams need to go: Aspect Oriented Diagrams. If we can identify the aspects of a diagram that the Business Owner is interested in, and those that the Operations Folks are interested in, and those that each Worker is interested in, then we can generate the Views that mean the most to the intended audience. It's all just a matter of Perspective, and BPV enables many, many perspectives. Some views may look like process diagrams, others may look quite different - doing BPV right will employ a lot of artistic scientists.
Here are just a few process views that come to mind:
- Process Owner's "40,000 foot" view
- Activity Owner's "Escalation logic" view
- Participant's "Where does this fit?" view
- Operation's "What's happening now?" view
- Operation's "What happened?" view
- IT's "Capacity planning" view
As Roland said, the future is about "ad hoc, collaboration, changing processes on the fly based on new insights and events"...
BPV's going to help us find those insights.
No comments:
Post a Comment