Process agility, meet business agility
Add bookmark
‘Agility’ is one of those business-technology words that means so many things to so many different people (like… well… hundreds of other words too; ‘architecture’ is just one other, but that’s for another day).
In my own little world as someone who researches BPM implementation practices and technologies, it’s a fun word to roll around your brain and around conversations, because ‘agility’ is one of the main hooks that any vendor of BPM platform technology will use when talking about how their product delivers business value. For many people it’s particularly useful when trying to explain the bit of BPM technology’s value that isn’t about ‘efficiency’ or ‘quality’.
Now I don’t want to sound flippant here, because being able to put business process applications in place through an iterative, collaborative style of delivery with frequent and fast feedback loops is a very concrete capability with very concrete value; and the ability to deliver applications that can then be changed with relatively little fuss (and sometimes, depending on the technology you’re using, a pretty high degree of confidence in the impact of changes) is also very useful indeed.
But… but…
So many conversations I’ve had about BPM and agility end up just focusing on agility in the context of a ‘process application’ – the software deliverable from use of a BPM technology platform. Either in how such an application is initially delivered, or in how it can be changed as and when business requirements dictate.
Funny thing is, when I talk to business leaders about *business* agility, their thinking works at a completely different level of abstraction. Agility in the context of a process’ structure or behaviour (or how that is guided or enforced) just isn’t a first-order concern at all. For these people, improving agility might mean:
- Being able to launch a new product or service more quickly.
- Being able to create a new marketing campaign or service bundle more quickly.
- Being able to create and enable new partners more quickly.
- Being able to enter a new market more quickly.
-
Being able to hire (and fire) people more easily…
… and more.
Now, these goals are all potentially easier to achieve if you have a well-established competency that gives you a predictable, repeatable way of designing, crystallising and then guiding your people regarding important practices and patterns of work, quickly and effectively. Hmm, now where have I come across that idea before…?
So – this is not at all a rant against the value of BPM; but instead, it’s a call to action: if you’re in a place where you need to create a business case for BPM investment – either from scratch or to get a new project started – think about this broader view of business agility, and map it to your organisation’s own high-level strategy and goals. Use this to frame some of what you explore when you create your business case.
Don’t get too focused on technical process application agility. That’s important, particularly as you increase in maturity and you start to think about implementing a continuous improvement program; or as you explore work scenarios where a prescribed end-to-end ‘recipe’ for work isn’t practical and you need to put systems in place that can help you embrace variation in operation. But – when you’re trying to tell a bigger, more universal story – remember that business agility is not the same thing at all.
First published on MWD Advisors Blog. Reprinted with permission of MWD.
[inlinead]
