I've gotten to the final parts of this series without giving an actual definition of business agility.  It needed to wait until we had sufficient background.  Now we do.

One notion clearly central to business agility is rapid response — the ability for your business to respond rapidly to new opportunities and changing circumstances.  Is business agility then simply about rapid response?

There's obviously more to it than that.  Brad Appleton, a process architect, puts it this way:

If all I do is respond quickly, that doesn't mean my response is effective and moving me closer to my desired destination.  It also doesn't mean that my response wasn't costly.  If my course of action wasn't effective, or if the cost of making that response-to-change was high, then even if I moved 'fast' … that's not sufficient to be 'agile' in a business context.

Indeed, as I explained in the previous part of this series, business is all about trade-offs and finding the optimal edge.

Appleton then offers this definition:  Rapid response to change with optimal efficiency in motion, economy of effort, energy in execution, and efficacy of impact.  He simplifies that to rapid response with optimal efficiency, economy, energy, and efficacy.

That's good, but doesn't quite capture the sense that true business agility must be grounded in business strategy.  Here then is my definition of business agility:  Rapid response to change such that the amount of time required to deploy a change is simply the amount of time required for the business to ensure proper alignment with goals, policies, and existing know-how.

Under this definition, you achieve full business agility when the IT aspect of change disappears into the plumbing.  That's what the excitement over business rules and enterprise decision management (EDM) is really all about — an exit strategy from change deployment hell.

This vision of business agility is not without significant challenges for engineering.  I will talk more about these challenges in the next and final part of this series, but let me quickly preview central goals.

• No artificial constructs in the representation of business products and your capacity to deliver them to customers.
  
  
• All operational business practices represented as rules.  No hard coding of decision logic.
  
  
• All rules in a form such that they can be readily found, analyzed, modified, and redeployed by qualified business people and product specialists — that is, business-level rule management.

By the way, can you get there via use cases and GUI prototypes?  Not a chance.

One other thing I should mention about achieving business agility is that the amount of time required for the business to ensure proper alignment with goals, policies, and existing know-how may not always be as short as you think.  Some kinds of change will always require significant simulation and testing of assumptions.  In the case of the financial services company discussed in the previous part of this series, for example, an elapsed time of 3-6 days to modify selection criteria might be about as quick as it can be done.

On the other hand, maybe it isn't.  Perhaps much of the simulation and testing of assumptions required to roll out modified selection criteria can be facilitated or performed by automation.  That possibility lands us right at the frontier of decision engineering and analytics.  The real excitement for EDM may have barely begun!

Envisioning the Optimal Edge of Business Performance

How would you know when you're on the optimal edge of business performance?  Here are some criteria.  Yes, they are ambitious, but I think certainly within our reach.

• Location Transparency.  You can outsource or home-source any portions of your operations anywhere in the world, perhaps bringing them together only dynamically and temporarily.  Nonetheless the work always (a) faithfully and comprehensively complies with your business policies, and (b) your customers, products, and workers are all treated exactly as you would want them to be.
  
  
• Consistency Across Channels.  No matter what channel of interaction is used to connect with your market, you are always consistent about pricing, customer treatment, and cross-sale or up-sale offerings.  Example:  Your website offers exactly the same pricing and discounts as your call center and snail mail campaigns.
  
  
• Selective Customer Treatment.  No matter what channel of interaction is used to connect with your market, you are always selective about customer treatment and make the right retention decisions without fail.  Example:  Your call center representatives treat all customers selectively, no matter how many campaigns or campaign segments there are, or how many customers the representatives talk to.
  
  
• Competitive Time-To-Market.  You are as nimble as, or more nimble than, any of your competitors in bringing new products, services, pricing strategies, etc. to the market place, and you do so with greater precision and consistency.  (Note:  If you are government or other non-profit, you can benchmark yourself against earlier points in time for your own operations.)
  
  
• Painless Compliance.  You can easily and cheaply demonstrate compliance at an excruciating level of detail.^[1]

One last point — as discussed in previous parts of this series, note again that these are not process problems, or even performance management problems, they are decisioning problems.  As James Taylor and Neil Raden put it, "No performance management infrastructure in the world can solve this problem; [you'll] just have a real-time, accurate view of how badly it's going."^[2]  Don't we already really know enough about just how badly things are going in change deployment hell?

The sixth and final part of this six-part series proposes twenty basic — and highly controversial — principles for product re-engineering.

References

[1]  For more, refer to Ronald G. Ross, "'Rules of Record' ~ Why 'System of Record' Isn't Enough," Business Rules Journal, Vol. 9, No. 1 (Jan. 2008), URL:  http://www.BRCommunity.com/a2008/b385.html.  See footnote 2 in particular.

[2]  Smart (Enough) Systems:  How to Deliver Competitive Advantage by Automating Hidden Decisions, by James Taylor & Neil Raden, Prentice-Hall (2007), p. 89.  The criteria above are based loosely on this work.

# # #