I saw this question asked about another technology, and thought it would make for an interesting discussion on BPM. So when we recommend business process management to businesses, what are the underlying assumptions we're making?
Are we going back to basics?
To increase the productivity of work, our civilisation uses the separation of labour and specialisation of people (first mentioned by Adam Smith in “The wealth of the nations” published in 1776). To achieve a common purpose, different people are doing different activities together. To be efficient, their work must be explicitly coordinated, that is:
In the digital and knowledge age, the “belt conveyer” coordination became fully computerised (i.e. as workflows) and more coordination techniques have been made available to enable more flexible and unique teamwork. An example of new coordination techniques is the event-based coordination that uses things that happened or took place, to make decisions about the flow of activities. For example, a traffic jam on a selected route may trigger a change in the journey in order to be on time (as modern GPS navigators do). Other coordination techniques are in ref1.
Business processis an explicitly defined coordination for guiding the business activity flows. In other words, a business process is an agreed plan thatmay include some variants and may be adapted in eachcase of process execution(also known as process instance). Various coordination techniques may be exploited at the same time.
The whole enterprise functioning can be formalised as a system of interrelated business processes spanning the applications, employees, customers and partners within and beyond the boundaries of the enterprise.For example, the sport-events industry has a lot of small well-defined (stable) workflows which are initiated by business-events in unique and unpredictable manner.
Thus better management of the enterprise functioning in support of the enterprise goals can be achieved via managing by business processes. Typical operations on business processes are:
Managing of business processes per se is implemented by specialized software suites (i.e. BPM-suite).
I sometimes get the idea that the underlying assumptions of BPM are that:
And if we want to flip these assumptions, then we call it Case Management, with a dash of Systems Thinking.
It was 15 years ago that the tag BPM was created as a discipline in recognition that a gap had emerged between people and the evolution of IT systems which were largely centered on processing data but did little to actually help people create new data. In reality nothing new in the BPM thinking as a natural follow on from BPR but the evolution of the inside out driven IT systems had resulted in a disconnect between people and the now legacy systems mess.
The push for digital highlights the need to understand how to support users internal and external. So the emphasis is now switching to outside in thinking which is of course all about businesses process management. The 'real key to drive forward is to know that the supporting software will actually deliver direct from the business ideas and of course be flexible to support the inevitable change which those legacy systems just failed to do.
The BPM discipline and supporting software need to be in sync and of course recognise the use of legacy as required by the users. Such is the dissatisfaction with the old IT ways and systems there is no doubt it will be big challenge. So very important such cynicism is quite quickly overcome and give confidence to users that such new systems will truly help them achieve outcomes as they interact with such systems. Fortunately new software can now do just that as in sync with BPM business thinking allowing direct input of ideas without going through the pain of coding. As ever do research test how this is achieved and then a new journey can start for business process management......
The biggest problem with assumptions is that whole "what they make of u and me" but I would say the biggest is assuming the customer knows their business processes at all. Too much is inside the heads of the long time employees (or tribal knowledge) or stuck up on cubicle walls or deep inside some long forgotten binder. C Level executives may point to a written procedure that was created several years ago but the actual process has evolved and changed.
As BPM consultants, I would say we have to assume there is a massive puzzle out there with procedures, internal knowledge, systems, and other factors that make up the pieces, and then decide if it's worth putting those pieces together to see the picture or just draw one from scratch. Sometimes the latter is the easier way to go.
Always good to document assumptions . . . . .
1. "First the problem then the solution", meaning no point mapping/implementing processes if the organization does not have a mission and has not evolved a set of strategies.
2. a reasonable subset of the business activity to be "managed" involves the performance of tasks in logical sequence.
3. the work will be performed more than once (otherwise use Critical Path Method).
4. no work should be performed that does not either directly or indirectly support strategy.
5. the benefits vary such that for a large initiative it is advisable to go through the formality of an ROI or SROI.
6. the more complex the sequencing, the more specialized the tasks (requiring specific skill sets), the larger number of silos that a process must overarch, the more beneficial it becomes to go beyond paper mapping to achieve in-line implementation of a process (as opposed to an off-line or on-line implementation).
7. too low a level of detail (i.e. splitting one short term task to be performed exclusively by one person into three tasks) is bad; too high a level of summary makes monitoring/control difficult (i.e. one task comprising several tasks, to be performed by several people, over an extended period of time).
8. the run-time environment hosting instances of templates (i.e. compiled rolled-out flowgraphs) needs to be able to accommodate re-visiting already committed tasks, recording data at tasks not yet current along their instances, and insertion of ad hoc interventions at the environment.
9. usual run-time services to support the processing of instances include R.A.L.B (three-tier scheduling); a formal History (committed tasks, with date/timestamped user "signatures", with recall of data, as it was, at the time it was entered, on the form versions that were in service at the time); data logging for possible machine real-time predictions OR after-the-fact data mining to allow process owners to improve their processes; data import/export to increase the reach of the run time environment.
10. reasonable accommodation for deviating from instances, but with governance from rule sets at the environment to "rein in" extreme, unwanted deviations i.e. guidance from BPM, governance from the environment. [the highway example of center lines to provide guidance and guardrails on both sides for governance].
11. the environment selected must have a simple UI, otherwise the initiative will fail - i.e. none of these assumptions will increase productivity, increase throughput, decrease errors, improve compliance with internal and external regulations or improve outcomes if the User Interface at the run-time environment fails to improve the user experience (avoid easy for me, difficult for you)
12. adequate trainng must be provided - the best results are obtained when the facilitator kicks off the 1st mapping session by giving the mouse to a stakeholder and saying "let's map out one of your processes".
13. many processes are dynamic, they must be maintained and occasionally targeted as candidates for improvement.
14. 360 degree (i.e. wraparound) BPM is achieved when work performed under the guidance of BPM results in data that can be consolidated to KPIs at the strategy level.
Hurdles that need to be overcome
a) "you can manage complex processes by staring at paper process maps" - not true.
b) except for end-to-end processes, objectives belong at Cases hosting BPM/ACM, not at end points along flowgraphs - many times there are no end points (i.e. process fragments) - users, machines and software thread process fragments at run-time. In theory each Case can be different.
c) Cases can only be closed by Case Managers ("it ain't over until the fat lady sings").
d) Case Managers need decision support (from rules at tasks along flowgraph template instances, from the Case History, from rules global to the run-time environment, from FOMM (Figure of Merit Matrices) to avoid subjective assessment of progress toward Case goals/objectives.
Management needs to exercise reasonable patience, - you can't change a corporate culture overnight.
One HUGE assumption that companies make (especially smaller or medium-sized firms) is that they can decide at a later date when to begin business prcoess management or a process improvement activity.
The assumption that what you are doing right now is not already BPM -- maybe not good BPM or well planned and methodologically sound BPM -- but definitely an activity of managing the way your business works to the best of your ability.
You're already doing it!!! So, invest in talent, technology, time or whatever is necessary to do it well.
Wow. Some long answers here. So, my summary:
I think the flawed assumption is that "anyone* even gives a sh!t about BPM"
* who matters = sponsors, budget holders, business users, end users, customers....
None. No assumptions. The assumption is satsfied in the premise:when we recommend business process management to businesses. Kind of like asking what assumptions we're making when we sell oil changes to people with cars: the assumption is that virtually all cars eventually need their oil changed.
"Recommend BPM to management"?? You mean "sell BPM to management"! : )
First assumption is that there's some business pain. And some work needs automating.
Now let's sell BPM as the best solution to a particular class of automation problems. Which means the work is repetitive. And that management will benefit from the control and flexibility that BPM technology gives you over your work automation solution.
Selling BPM Checklist
__ Business has work-related pain
__ Specifically, some work needs automation, or better automation
__ And the work is repetitive (i.e. not a project)
__ And the work may evolve over time
__ And management wants staff to have more control and visibiility over work instances
Given these assumptions, and because BPM technology is the technology where the concepts of work are first class citizens of that technology, BPM technology should be the most efficient and effective way of solving such business automation problems. All other technologies put a higher cognitive load on humans to achieve the same results.
@John "All other technologies put a higher cognitive load on humans to achieve the same results.".
Spot on, for two reasons . . . .
a) BPM tools can advance/have advanced to where end-users, who best know the work they do, are able to map out their own processes (with some help from BA/IT/external consultants on rule sets).
b) the run-time environment UI can be simple enough such that these same users do not have to navigate up/down menu hierarchies.
I have long maintained that one screen is adequate for workflow./workload management .i.e. calendar on the right, to-do list on the left..