As BPM has a long and varied history, what would you say are the key differences between today's BPM and process improvement projects of the past?
SMAC. We're going back and forth, across the DMZ much more than in the past. Nobody's still really doing analytics well, they're few and far between, but some folks are blowing a ton of money in the attempt. A large, multi-year effort on the west coast right now that goes beyond fugazzi immediately comes to mind. It was supposed to save money and streamline things but is achieving the opposite effect in a grand fashion.
The practice itself hasn't changed much either. Either they do or don't get it, usually the latter regardless of how much effort is expended to enlighten. More often than not there's a specific need, specific project and when it's done the lens doesn't pan out any wider than that.
A successful implementation remains the goal.
I don't think it has anything to do with past or current days.
Process Improvement is mostly attacked as a project, while BPM is daily business.
@BPM mentor, come in ;-)
No longer is process automation a choice. The ROI calculaition is not between doing nothing and doing something, it is between improving one thing or more than one thing through automation. The emphasis has shifted from "if" and "why" to "when" and "how".
Today's consumers of process automation are in the enviable position of being able to optimize their own implementations and customize their experience. Reporting and dashboards flow seamlessly from systems offering an unlimited way of visualizing the data. Orchestration of third party techgnologies in the workflow, directly from within the BPMS, eliminates tedious system switching and manual lookups leading to increasing process velocity and accuracy
So I see several things, some of which I am affirming from others.
1. Greater automation and technology- are now always part of processes. And now technology is even helping and empoweting at the individual perfomer level.
2. BPM going wider, more cross funtional, and now much more global.
3. Combination of lean six sigma, BPM, Case management methodologies - doing these frameworks together or what is needed for the organization. No need to have one evangelical method!
4. Improving the work is the work and so building that principle into daily work and processes and doing it daily/regularly. I am only beginning to see that happen in a few companies.
In the past, a BPI project could have an illustrative process (drawn on a wall) and its implicit implementation via coding. Today, we try to work with explicit and directly executable processes.
See as well the table at http://improving-bpm-systems.blogspot.ch/2014/03/bpm-related-tlas-comparison.html
Historically, process improvement has largely been a garbage-in, garbage-out endeavor. People estimate numbers, they estimate times, they estimate error frequency... and based on those WAGs we generated reams of paper explaining how we are going to improve a process by 22.325%, hilariously over-precise and potentially well within the margin of error for the numbers we used in the first place.
BPM provides hard evidence. Real timings, real dollar figures, real exception rates. Measuring improvement issimplya matter of comparing pre- and post-change performace using those numbers. No guesswork, no self-serving approximations provided by the individuals whose jobs you were not-so-secretly trying to eliminate through your Operational Excellence initiative.
And besides—you secretly got most of the improvement when you first automated your process. Everything else is just gravy.
There are 4 core differences between Today's BPM and Process Improvement projects of the past.
1. BPM is no longer Cutting Edge
In the eighties and nineties Six Sigma was the high profile way to improve your company. People like Jack Welch were global superstars and a process improvement operation was something the whole board focused on as their competitive advantage.
Last century was the mass production age with hundreds of thousands of people employed for their manual labour, doing repetitive low-skill tasks. And hundreds of thousands of clerks, doing equally repetitive, low-skill tasks - just in offices, not on factory floors. The manual jobs went first as we moved beond the limitation of human muscle. Now the clerical jobs have gone too except in backward companies.
BPM missed the boat. Like making a better buggywhip just when someone had invented the car. It is restricted to backward companies who still have the sort of labour-intensive processes, or to companies where showing governance for their outdated clerical processes is vital. And it is rarely the key task which makes those companies the darling of the stock market. Process Improvement isn't sexy anymore.
2. All Processes are now Computerised Processes
Process Improvement in the past could only set guidelines. Processes were manual and it created the manual. But people then read the manual their own way, subverting many of the process improvements or twisting them to their own ends. So the process at the end of an improvement project was as good as it got - it would be subverted over time.
Manual processes were hard to obtain information from in any quantifiable and verifiable form. So they tended to be subjectively analysed and stood or fell on the reputation of the person involved. This led to HIPPO (highest paid person's opinion) rulings, "not invented here" syndrome and "someone else's problem" effects.
Computerised processes have real-time data on everything they do. You can see process time, percentage of exceptions, latency and waiting times and even percentage utilisations. You can show these in visual management graphs, AB test and see immediately the effect of any "improvements". Thus the process should be continually improving as people work to reduce the biggest problems first, try out new methods and optimise utiisations. No arguments either - the data drives decision making.
But it hasn't happened like that. Seeing the true efficiency and effectiveness of a process has proved an uncomfortable truth for most managers. So they have stuck with the "project and out of there" approach of traditional process managment. A major opportunity has been missed.
3. Process is Everywhere Now
Process thinking used to be restricted to a few special people with silly names like Black Belts or Kaizen Kraftsmen (seriously - I saw it on a job description). Amazon changed all that. UX came along and with it customer journeys. Suddenly process was being done by web designers, marketers and customer service people, not just self-styled Process Gurus. So the process is no longer set in the IT department, nor as part of a manufacturing or ERP process, but dictated by the customer (anyone know what those are?). Today's BPM is just one of many approaches.
4. BigIT is no longer the way to do things
When IT was hard, business people had to put up with the way they did things. If they wanted to change a web page they had to put in an order in triplicate and wait three months. If they wanted to have a CRM it was a multi-million dollar, three year project. Business Intelligence was even worse, with massive data warehouses and fixed links to each datasource - change one and you broke the lot. Last but not least was Process - deciding their requirements two years before the project went live and waiting patiently while it went through a long Waterfall process was the only way companies knew to do things.
Now interns can set up landing pages on the fly. Salesforce pulled the rug from under IT departments everywhere with SaaS. Data intelligence is now a point and click exercise, with APIs connected instantly and data just falling out fo the system at will - or even connected to a round-trip machine learning process.
BPM is still BigIT. Slow, management intensive and inflexible. Depressing really.
Let's not weep for Today's BPM. Let's look towards tomorrow's Process Improvement. Where demand intelligently drives production and delivery so the right goods are in the right place at the right time. Where markets are tracked automatically and changes built into the process systems which follow them. Where the income flow follows the demand, uninfluenced by sales cycles, promotional imperatives and other distortions. And where a million niche products can be created, tracked and delivered as easily as one monolithic brand leader.
A little concerned that we're assuming "better" is "easier".
I need to point out that, although technology is making it easier, "easy" isn't a function for "improved" output. There's no correlation.
Example A: A developer may attain "certification" in one-of-many BPM development platforms. Certification-in-hand, they're now off and running in (sometimes) major BPM projects. Without seasoned oversight the results are staggeringly cost-heavy failures and a general tarnish upon our process-management methodology.
Here we see a BPM suite leading towards a harmful simplification of the efforts behind organizational change (process improvement). BPM isn't a "training" requirement or certificate. And, though I honestly enjoy using the new(er) BPM technical suites, tools nor their certified training build the house.
Example B: BPM tools allow for "executable models" - this feature provides a direct path between process model (BPMN) to deployed application (IT-asset). This capability tends to shortcut analysis and marginalize business knowhow. Evidence here is easy to point out on most projects by simply asking for (and not finding) the values/KPIs behind general process and composite activities. Where's the fit, or tactical representation, within overall strategy?
Here we see BPM morphing into a functionally oriented point-solution (i.e. just-another-application). BPM suites make this easy... Just hand-over the tools to your IT department and let them have-at-it. There's no process-management outside of name-sake on the development suite.