All the Best,
Systems (of people, of hardware, of software) must be built for change, not built to last.
Agility is not mandatory, but neither is survival.
For example there are companies that have one solution to any problem: changing the organization structure. Process culture is unfavorable to such approach to changes indeed.
The same applies to companies with heroic culture and heroic approach to changes.
The message in the title may be addressed to the organizations that already embraced the process culture but didn't fully realized yet that process management is process change management, really.
As a side note, today some BPM practitioners position themselves as business transformation professionals rather than BPM professionals. For me personally it's too much.
Happy Holidays, Everyone!
Scott's opinions only. Logo provided for identification purposes only.
Let's just think for a moment "process" is a description of people (and "machines") at work creating an outcome. It's how commerce has worked from day one! It has be come more formalised with IT driving systems of record requirements not allowing much flexibility and sadly it has taken decades for software to recognise that change is inevitable. Indeed good "processes" are ones that remain flexible to readily support change.
So I agree they are not mutually exclusive BUT business now needs to recognise the old fear of asking "old IT" for change in supporting software is now confined to history! So there is now that priority to “promote” changes to the process as normal hence some validity to the comment.
Just try to push “culture of change” without good “culture of process” and you will get a serious resistance. The latter is the most powerful tool to achieve the former because via processes one can explain to everyone in a company how their working habits will change for the better.
Also, all other enterprise-wide components must be aligned to process culture, e.g. organisational structures should be generated from processes, there should be a platform for quick delivery of process-centric solutions, etc.
Thus BPM (if applied correctly by BPM professionals) is the most powerful, so far, engine for changes. (Please share with us if you practice something better.)
Naturally some BPM professionals are business transformation professionals.
There's a lot of value in that statement, but I'd like to give it a deeper stab. A culture of change coupled with a culture of process will in most cases drive incremental evolution. Because change will be orderly: imagined, measured, gaps closed, improvement checked.
But this can lead to change myopia: focusing on local optima and missing the big picture, in case there is one.
I think change is a broader undertaking that needs to always scrutinize the uncomfortable unknown. Seeding virulent (and violent) change scenarios in the organization gives the opportunity of escaping potential local optima traps.
I will give one example from the real world: big cloud companies test the resilience of their architecture by throwing wrenches in the machinery - either via special "malevolent" code that randomly kills VM instances or other typical cloud software constructs (see Netflix's "Chaos Monkey"), or via having a guy wander around in the data rooms shutting down machines or creating router loops by wrongly patching Ethernet ports. I'm sure that an architecture that is fed with such test cases is much more resilient than the typical thing that gets out of the develop/unit test/integration test/redo waterfall cycle.
And then if we imagine change as a more generous undertaking, then really a culture of process is simply a small subset of the broader change culture.
- Page :
However, you are not allowed to reply to this post.