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?
We're assuming that your business will run better if you formalize your processes, and you then monitor, analyze and adapt your processes to be more efficient.
Founder at John Reynolds' Venture LLC - Creator of ¿?Trules™ for drama free decisions
The assumption is already in the question: It is assumed that BPM is a technology.
While actually BPM might be supported by Technology.
Sharing my adventures in Process World via Procesje.nl
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:
A plan of joint work must be commonly understood;
a description of activities, procedures, working instructions must be provided in a clear and non-contradictory way to be easy understandable to the whole team, and
a desired flow of activities must be imposed. For example, a belt conveyer is a popular coordination technique.
[img]file:///C:\Users\ALEXAN~1\AppData\Local\Temp\msohtmlclip1\01\clip_image001.jpg[/img]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:
planning or modelling of the process,
instrumentation or realisation or automation of the process,
machine-assisted execution of process cases,
control of individual process cases,
measurement of processes cases, and
optimisation of the process.
Managing of business processes per se is implemented by specialized software suites (i.e. BPM-suite).
To me, BPM is simply the managment of work to completion with or without technology. Technology of all kinds help especially when speed and accuracy at a low cost with great transpareny and governance is the goal.
Ah, assumptions... I'd rather swap the term with "basic requirements"... The single most important of an underlying assumption is the idea that, in order to add value using BPM, you eliminate functional thinking.
I sometimes get the idea that the underlying assumptions of BPM are that:
a team must work following a plan, rather than working towards a shared goal
a team must follow instructions, rather than have room to figure out how to do the work themselves
team members must be managed individually, rather than at the team level
process must be standardised, rather than agile.
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
[i]begin [/i]business prcoess management or a process improvement activity.
The assumption that what you are doing right now is not already BPM --
[b]maybe not good BPM or well planned and methodologically sound BPM [/b]-- 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.
Sure... I suppose what you are saying is that every organization has "best practices" - they may exist only in the heads of staff, they may be written up as policy/procedure, they may be mapped to paper, they may be on-line, or, once the organization reaches a level of maturity, in-line.
The objective is to have better "best practices".
The objective is to have better "best practices".
Good emphasis on the a priori nature of business process work - which may not be managed well (or even at all). Or current work processes could in fact be well managed, but management wants to evolve the practices. Now the new question is "how". Maybe BPM automation software technology is the right answer...
Wow. Some long answers here. So, my summary:
I think the flawed assumption is that "
[i]anyone* even gives a sh!t about BPM"[/i]
* who matters = sponsors, budget holders, business users, end users, customers....
Yeah, well, same could be said about accounting. But accounting exists. Accounting improves business and life. OK BPM isn't there yet. Maybe BPM needs to be better sold. Sales is the antidote to cynicism. Don't get me wrong, I'm not against cynicism! There's lots of reasons to be cynical. But one shouldn't stop there.
None. No assumptions. The assumption is satsfied in the premise:
[i]when we recommend business process management to businesses. [/i]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.
To take your analogy further - It is amazing how long a car can go without needing the oil changed. Sure it gets less efficient, but it never stops, it just keep plodding along. Unlike gas. When you run out of gas it is over.
BPM / process / ops = oil. Sales / revenue / customers = gas
BPM / process / ops = oil. Sales / revenue / customers = gas
OK, let's go beyond analogy. I worked on an oil rig for a year. First thing on shift, grease 40 grease nipples. Two squirts here. Three squirts here. Without grease or oil, industry "grinds to a halt" (the phrase is a reference to this process) rather quickly. So, complex systems aren't just about inputs of energy (the gas) but about constant maintenance (the lubricant, I suppose, the metaphor is running ouf of gas here).
"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.
[b]Selling BPM Checklist[/b]
__ 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
[u]the [/u]technology where the
[u]concepts of work are first class citizens[/u]of that technology, BPM technology should be
[u]the most efficient and effective way of solving such business automation problems[/u]. 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..
Thanks for your comment Walter! The technology is surely advancing to empower end-users. (And your mention of "panes" I think is important here too -- not just a detail.) Behind the scenes powerful software works its magic. End-users should not have to see code - ever. (And a business rule is not really code in the usual sense.)
- Page :
There are no replies made for this post yet.
However, you are not allowed to reply to this post.
However, you are not allowed to reply to this post.
Join the Discussion
customer service The Year Ahead for BPM IT hype cycle Business tranformation BPM Challenges RPA Red Hat The Year Ahead for Digital Transformation AI BPM 2019 swimlanes Robotic process automation DT transformation case management customer experience digital transformation Process Architecture process mapping Business Process Management 2019 IBM IT Department ACM CX Automation 2019 process maps Business Processes Year Ahead BPM Year Ahead Business Process process Process Re-Use artificial intelligence skills process modeling Open Source BPM RPA 2019 Customer process
Also on BPM
- Overcoming Goliath: The New Nimbleness of BPM and Workflow
- Taking Processes to the Next Level: ProcessMaker Discusses the Ever Evolving Nature of Today's Work
- Post-platform Enterprise Pattern: Faster and Cheaper Inter-Enterprise Ecosystem Business
- First Impression: ADVANTYS WorkflowGen
- Automation and Customer Experience
- A New Architecture for Automation: Neil Ward-Dutton Explains
- Does AI Change How We Deal With Information?