Business Agility, MWD-Style
- August 2, 2012
- 0 Comments
Neil Ward-Dutton hits on the issue with misappropriating the word agility to mean “software” process rather than to reflect the business:
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.
Right. For some of these items, software agility may be required, but the key benefit to the business isn’t the software agility, it is the business agility that software hopefully provides.
Even so, it is possible to design BPM solutions that are not agile (Blasphemy!). To relate an example from early in my BPM career: our customer shipped a lot of products through on of the major parcel carriers in the US. We designed a solution to monitor those shipments via the Carrier’s API and via some EDI/Batch processing. Never did anyone imply that this carrier could be replaced in the process. And yet, one month after go-live, that’s exactly what we did. We switched from one carrier to another.
That switch required some coding – integrating with a new carrier’s API. But the surprising thing (to the customer) was that we had anticipated the possibility of more carriers being in the mix by storing a field for carrier, and creating abstraction layers so that the differences between carriers wouldn’t interfere with the simplicity of the process design. The cut-over took less time than the contract negotiations.
The point is that we can anticipate these kinds of changes in processes. Perhaps we can’t get all the implications right, but we can get many of them correct. And while our job isn’t to design for every eventuality, it is our job to design in future-possible-changes. It is important to let business agility inform your process design.