All the articles in the “Human Processes” column for BP Trends are based on the view that there are two distinct types ofbusiness process – step by step and collaborative. They have a lot in common since, at heart, both transform inputs into outputs. However, the means by which they do so is fundamentally different.
Step by step processes were the basis of the industrial revolution and their theory continues to evolve to this day- as reported on, of course, by many writers for this Web site. Examples of step-by-step processes include much supply chain work, both operational and back office, such as order processing, manufacturing, shipment, invoicing, payment and financial accounting. Other examples include case management work such as customer service, fault management and auditing. On a larger scale, construction and software development processes fall also into this category, although project rather than process management techniques are typically used to manage such work.
Collaborative processes, on the other hand, include tasks but it is not useful to analyse them in this way, since tasks emerge from collaboration rather than underpin it. Examples of collaborative work include strategy/policy development, legislation, merger and acquisition, transformative change to services (public, private and third sector), management accounting, health/social care, research and development, venture capital investment, start-up development, military operations, intelligence gathering, crisis response, scientific research, and some forms of marketing. It is often the case that collaborative processes are carried out by people who might shy away from using a software system to support their work.
Step by step processes are formed of tasks, which trigger one another either directly or via messages, and are carried out by human and/or machine actors. Hence, the basis for defining step by step processes is the automata theory of Computer Science, its incarnation in such formal techniques as petri nets and the pi-calculus, and graphical notations such as BPMN which are derived from these techniques.
By contrast, the basis for defining collaborative processes is the five principles of Human Interaction Management (now often referred to as Virtual Team Planning to highlight its cross-boundary nature). These principles assert that collaboration rests on understanding and managing:
- Teams, to assign and accept roles and responsibilities
- Communications, to create and support action
- Knowledge, to maintain and share useful information
- Time, to target effort towards goals and measure its effectiveness
- Plans, to discuss and update them as circumstances change
Since each type of process has a fundamentally different basis, you cannot analyse them in the same way – especially as collaborative processes often include many different organisations as partners. Traditional business analysis techniques fall down at the first hurdle, often failing even to capture the full range of stakeholders involved in collaborative work or the nature of their involvement.
I won't discuss here how to analyse step by step processes, for which you can refer to many articles and columns on this site. Rather, I will offer a few pointers on how to analyse collaborative processes.
The first step is to define the initial goals of the participants. There will generally be an overall goal of the process itself. Associated with this there will be a number of sub-goals, some of which are shared and some of which are specific to particular partners. The dynamic, evolving nature of collaborative work means that refining, extending and sometime curtailing the overall goal and the sub-goals is an inherent part of the work itself, but defining an initial set of goals is always the starting point for analysis. In software that supports collaborative processes, the overall goal may be used as the descriptive text for acollaboration plan, and the sub-goals may be referred to as Stages, Streams or Themes.
Each sub-goal will be of interest to a specific sub-group of stakeholders. Defining these sub-groups is the second step. Not everyone will be interested in all sub-goals, and restricting areas of interest via the process definition is vital in order to cut down the volume of information and messages that people have to deal with.
The third step is to break down (using a technique such as RACI – Responsible, Accountable, Consulted, Informed) who is producing and who is consuming, and what is being produced/consumed, to help achieve each sub-goal. In many collaborative processes, some of the most important items produced by the process are the sub-goals themselves, along with the means used to achieve them – i.e., the collaboration plan produces its own details of “who makes what and who uses it”.
A fully-featured collaboration plan may include much more information, such as start/end dates for specific items to be produced, the form that those items will take, and associated financial or qualitative costs, revenues, benefits and risks. If you use a software system to support collaboration planning, this additional detail can be used to automatically generate online forms and reports for doing and managing the work.
However, in many situations, none of this additional detail is necessary. The three simple steps above are enough to support effective and efficient collaboration, by identifying:
- The goals of the work
- Who has an interest in achieving each goal
- How they will work together to do so
If you are familiar with mainstream techniques for step by step processes, then you will recognise that it is very hard to capture this basic information using graphical notations such as BPMN. In fact, it is counter-productive to try and do so, since the resulting diagrams are more likely to mislead than to inform. Step by step and collaborative processes are very different, and a different technique is needed to capture each type of process.
0 comments:
Post a Comment