Big change comes top down (BPM initiative), small change comes bottom up (ad-hoc business improvement). Both are valuable. Both have their place.
Big change will probably take a holistic view, with senior management support and should drive the business forward to a new level; e.g. focus on CX and new CRM system, addressing new market, rethinking back office operations through Shares Services.
Small, incremental change is critical to maintain continuous improvement, driven at grass roots where the staff see and understand the problems. But it requires a culture of change.
The trick for companies is spotting when small change should be big change. Identifying a better way of correcting invoice errors should probable point to the need for a complete review of the Order to Cash process.
BPM brings real sustainability with good supporting software as a new way to implement and measure results of what is needed whether big or small. This is just the start of a new journey where continuous improvement is supported and fear of change can removed as user’s ideas are incorporated into the “digital” solution.
This brings the real opportunity to empower people where top management move from “command and control” to “empowerment and measurement” style of management to transform the business in today’s competitive and ever changing world?
Good question about BPM versus ad hoc business improvement projects. And the question gets to the heart of what BPM technology is, and the definition of business.
The difference between BPM-enabled business and ad hoc business improvement projects is the difference between craft-based work and industrialism. The various "process maturity stages" (e.g. Gartner) capture exactly this. And the benefit to industrialized processes is productivity, by orders of magnitude. BPM technology enables the automation of clerical work, which is to say that humans can accomplish much more work for the expenditure of the same effort. Ad hoc business projects on the other hand are projects where automation has not been implemented. (This statement is not controversial, it's just a tautology.)
For example, a major life and annuity insurance provider may have 1,000 or more insurance products on offer. The IT department in such an organization is likely to see itself as in the "manufacturing business" (in fact my example is based on the self-description of more than one insurance industry IT executive). And the challenge is when new market opportunities arise, or new regulations impact what can be sold, how fast can a new product be brought to market? And can our brokers be selling the new product months before the competition? Old products may be retired, and new products are constantly being introduced. So it's industrialized insurance software manufacturing. And the full potential is only possible with RAD and BPM tools.
It's worth noting the economics behind the "industrialism". Business operations are necessarily about repetition, because if everything is unique, then transactions costs are too high (Ronald Coase wrote about this in 1937, but you can go back to Adam Smith and forward as well). And if you have a new opportunity to do something substantially different, then that function will be spun off as a separate unit or if non-core, as BPO.
What about the question of ad hoc and case management and the need to distinguish one's self in the market place? Because industrialism can only lead to commodification.
This is the eternal question for management. It's probably worth distinguishing between BPM-as-technology-and-management-science on one hand and ad-hoc-tactical-improvements on the other. They can be seen as apples and oranges. If ad hoc is all you do, then you'll be put out of business when your competition figures out how to automate. But not everything can be automated right away.
What do we learn from this question though? That isn't parenthood-and-apple-pie? My answer is "that we should double-down on BPM", because there's so much automation that hasn't been done yet. The whole BPO industry is a case in point. And it's not for nothing that BPM is the BPO industry's favourite technology and that Ronald Coase is the BPO industry's favourite economist.
Well, I guess I'm not really sure what qualifies as an "ad hoc business improvement project". Certainly, you're going to evaluate your business from time to time without necessarily viewing it through the lens of BPM. Still, once you're doing that, if the plan you develop as a result does not include BPM, well, it might be worth looking again a little more closely.
When I were nowt but a lad living ont' moors in Yorkshire, my Chief Programmer said to me "Na'then Kevin, tha' mu'nt be changing t'code without tha's got a proper ticket an' if tha' dun't 'ave a ticket, tha' need t'create tha-self one," he added, "remember: don't do, document!" And with a smile he'd be off for a 4 mile hike across dell and dale for lunch in the village pub in bracing winds and horizontal rain.
Now, 40 years later, I pass on similar advice to my team, in my newly acquired soft Californian-English, "Dudes," I say, "like don't do, just automate, totally." And then I roller-blade to Starbuck's for a decaf, non-fat, no-foam latte.
Continuous business improvement is essential and it is the responsibility of everyone to optimize what they are doing and how they are doing it. Automation is something everyone should be able to do for any of their tasks. Improvements should be reviewed and shared and will accumulate into measurable benefits for the user community. This micro level, grass roots, improvements must be in the context of a macro level, corporate strategy and direction, process plan. The tools we use for both micro level user empowerment and macro level executive guidance has to support both ends of the user spectrum in terms of ease of use and accessibility.
Humans are recidivists by nature so when an improvement is mooted it is not always adopted because change is hard, even little changes. Automation takes away the choice to do it the old way.
So when you hear an idea for improvement, don't do, don't document, automate.
Agree with John that it is industrialisation vs craft-work. Just a few details:
1. All three BPM (BPM-discipline, BPM-suite and BPM-practice) must work together.
2. Actually, it is necessary to establish an integration and automation platform for quick (low-code) delivery of process-centric solutions. (less unnecessary duplication in the IT environment, etc.)
3. There is an impact on the whole IT department (governance, dev, ops) and the business (closer work with the IT).
4. All phases of an IT solution/application life-cycle are effected. The delivery of the first version (which is 20 % of the TCO) is 3-6 times faster / cheaper. The further evolution (which is 80 % of the TCO) is about 10+ faster/cheaper. [These values are estimations from different sources and my own experience]
We are beginning to see the power of the pixel.
How, while a newspaper is a snapshot in time, a digital newspaper can evolve as the story unfolds.
How search finds exactly what you need in milliseconds, from millions of documents.
And how processes like Amazon’s give real-time data not only on every step, but the gaps between those steps, informing customers so well that customer service is almost unnecessary.
We are also beginning to see the power of connection. How an idea can spread to millions in a few seconds. How it can aggregate and build along the way, building into a powerful force for change, or a silent majority vote for the status quo and with many more inputs building on the first spark.
We can see the power of feedback. How a machine algorithm can do a process once and learn from the data how to do it better. How it does it even better the next time, until it does it better than anyone could ever have designed in the first place.
There are, however, still laggard companies who believe they need a person to come in and tell them what to do. They employ a process improvement consultant. Who then does Random Acts of Process Excellence (RAPE), some aggrandised up by the magic initials BPM - Bigger Profit for Me!
But the reality is these client companies could know what to do – they just aren’t managing their data. The person who complains about the wait – or goes elsewhere where the service is faster. The department which is always sending forms back, because of errors. The backlog when someone goes on holiday. The resource bottleneck, because of callbacks as the problem wasn't sorted first time.
BPM, unlike Lean or Six Sigma, is a pixel driven system – computerization is at its heart. Yes I know it can just be a methodology, but it isn't for most people – it has as its underpinnings a system which turns the process into data – into pixels which can be queried, aggregated, graphed and traffic lighted. It tells you what is going on, in real time. Not just process steps, but gaps. Not just executions, but how many were exceptions. Whether one person has found a better way than another. Whether the system could route things differently for greater utilization of resources or resilience.
You can build dynamic, intelligent systems with BPM. Systems which learn. Which take best practice and make it standard. Systems with visible management so people can see how well they’re achieving. Systems which democratize, aggregating reasons customers and users give for failure and suggestions for improvement, so you get a 3D picture of what works. Systems which can test themselves, constantly doing AB comparisons to create improvements. Even systems which evolve automatically, getting better every day until they are way better than any guru could design.
Unfortunately most people don’t use BPM in this way. Still stuck in the guru era. Still thinking in projects. To them BPM is just a more expensive way of doing Lean or Six Sigma. Shame really, that this is the image BPM has been given by people who don’t know how to use it, yet still sell the hobbled version to clients as the best thing since sliced bread.