What is true business agility and what’s really needed to achieve it?  This six-part series takes the position that extreme business agility is inseparable from extreme customizability of the company’s product(s).  You can re-engineer business processes all you want, but until you re-engineer the operational know-how of the product itself, you’ll never completely get there.  You’ll just spin your wheels forever in work-around-land.

Extreme business agility is all about competitive advantage, service excellence, and job satisfaction.  Engineered correctly, it is also about how your company can retain knowledge in a pragmatic, automated, ready-to-deploy form.  The goal in that, of course, is to turn tacit knowledge into explicit knowledge — so it can't ever walk out the door.  This six-part series discusses the latest thinking about what it takes to comprehensively re-engineer the know-how of complex products, and how that gets you to extreme business agility.

I take the position that extreme business agility is inseparable from extreme customizability of the company's product(s).  You can re-engineer business processes all you want, but until you re-engineer the operational know-how of the product itself, you'll never completely get there.  You'll just spin your wheels forever in work-around-land.

Don't misunderstand me.  I'm a great proponent of business process models and business process re-engineering.  They're extremely useful in rethinking how work is conducted independently of organizational boundaries.  But there's much more to business products and your capacity to administer them than input-transform-output.

Specifically, there is structure.  And where there is structure there is always a natural build sequence.  If you want to build a skyscraper, where do you start? You'd better start with the sub-basement!

In business and IT, we usually don't look at things that way.  But think about it carefully.  In insurance being able to pay claims depends on being able to enroll the member in the first place.  Being able to enroll members, in turn, depends on being able to formalize the group plan with the client organization.  Being able to formalize group plans with client organizations depends on knowing each option in the product(s) you are selling.  Knowing what options exist to sell in the products depends on knowing what those options are about in the first place.  In other words, there is a natural dependency among these areas of business capability.  There is a sub-basement — that is, a natural place to start.  These natural dependencies for insurance are illustrated in Figure 1.

Fig. 1.  Insurance product value chain.

Process models seldom model this kind of natural build sequence for your product.  Generally they just assume it (or ignore it) and proceed to model how the value-add of each area is delivered to each relevant stakeholder.  They naturally push you downstream; that is, toward the points where value-add is delivered.  Not infrequently, they push you all the way to ultimate end-point among the value-adds — for example, paying claims.

From a product engineering perspective, that's fundamentally backwards.  Your focus should be on the point of structural origin, then the natural build sequence starting from there.  We consider this kind of diagram to represent a value chain.^[1]  A generalized product value chain is presented in Figure 2.^[2]

Fig. 2.  Generalized product value chain.

How does the value chain diagram differ from business process models?  For one thing, you will probably have multiple business process diagrams (many?) for any given company or line of business.  It is unlikely, however, that you will have more than one product value chain diagram.  That is true even if significant variation exists in the product itself.  For example an insurance company may sell life, disability, health, dental, and so on.  Even so, there is only one product value chain.

Because you probably have multiple process models, you generally also have a choice about where to start.  Since you are modeling transforms — how work is conducted — you'll naturally want to start with the area offering the most significant returns (or exhibiting the greatest level of pain).  In comprehensively re-engineering the product, in contrast, you don't have such a choice.  You must start at the beginning (the sub-basement), and that's really just all there is to it. 

Imagine that you had to build your company's product from the ground up.  Where would you start? There has to be a right answer, or you'd just end up going in endless circles.  Unfortunately, that's just about how many companies seem to find themselves these days. 

References

[1]  "We" refers here to Business Rule Solutions (BRS) and its business analysis methodology, Proteus.  Product value chains are a key deliverable in the Proteus approach to strategic planning.

[2]  Taken directly from Resource Life Cycle Analysis, by Ronald G. Ross with Wanda Michaels, 1992, p. 52.  This book was the seminal work for representing the product build sequence as a value chain.

# # #