Value Chain Modeling, Part 1: Capability Analysis

Preface

In a previous post, I asserted that the next generation CIO needs computer-based modeling tools to fulfill the CIO role, and I identified value chain modeling as particularly important. This is the first in a series of posts on the topic of value chain modeling.  Each post will focus on a particular aspect of value chain modeling. The concept of value chains was first introduced by Michael Porter in his 1985 book, Competitive Advantage: Creating and Sustaining Superior Performance. 

These posts, more specifically, are based on work done by Henk de Man of Cordys and myself (Fred Cummins) in response to the Object Management Group (OMG) Request for Proposals (RFP) for a Value Delivery Metamodel.  The resulting specification will define the import-export data structure and graphical notation of value chain models to support the exchange of models between different software product implementations.  The standard does not define how the models are implemented in the software, nor the functionality that a particular implementation may provide.  It does define semantics and relationships of the modeling elements, and it may define a graphical notation for consistent understanding of users. 

Part 1: Capability Analysis

In this model, the value chain (sometimes described as a “value network”) represents activities and dependencies between them much like a PERT network.  The dependencies are generally the flow of deliverables from source activities to dependent activities.  The activities of interest are those that are directly involved in producing the end result--the product or service to be delivered.

The activities are broken down to represent relatively generic capability requirements.  The capability that supports each activity is distinct from the activity just as the activities in a PERT model are distinct from the resources that perform the activities.

Each line of business in an enterprise can be represented by a distinct value chain.  Due to the level of detail, the activities and dependencies may be quite different from one line of business to another.  However, some capabilities may be very similar.

As a result of capturing the characteristics of each capability, it will be possible to recognize where similar capabilities are used to perform multiple activities in either the same or different lines of business.  This provides the basis for specification of shared services.  Similar capabilities can be consolidated and can be given well-defined interfaces to be engaged by multiple activities.  The result can be economies of scale across multiple lines of business.

However, this also creates management challenges.  After consolidations, the enterprise will have a number of shared services that are not strictly aligned to any particular line of business and thus their performance cannot be measured in the context of any particular line of business.  The value chain models, together, provide the context for evaluation of each service from an enterprise perspective.

 The shared services should not be managed by a line-of-business organization or there will be an incentive to optimize the capability for that line-of-business rather than optimizing from an enterprise perspective.  As a result, the sharing of services should drive the enterprise toward a matrix organization: lines of business in one dimension and functional/capability organizations in the other.

Well-defined service interfaces hide the implementation of the services from the users of the services.  Services should be loosely coupled so that they can easily serve requests from different lines of business.  This loose-coupling and implementation-hiding empower the manager of a capability to innovate and improve services without involving other organizations as long as the interface and the service result are not changed.

These generic capability services can then be engaged to deliver new products or services.  A new business opportunity can be modeled as a new value chain.  The model identifies the capabilities that are needed to perform the value chain activities.  Capabilities that exist in the enterprise can provide reasonably accurate estimates of cost and performance in support of the new line of business.  Capabilities that do not exist represent gaps that must be filled to deliver the new product or service.  The costs of creating the new capabilities along with costs required to upgrade existing capabilities represent the cost of entry to the new business.

The identification of shared capability services also provides the opportunity to consider outsourcing of commodity capabilities.  We’ll consider outsourcing in more detail in a later part of this series.