Tuesday, December 28, 2010

Value Chain Modeling, Part 2: How a Value Chain Relates to Business Processes

This is a continuation of a series of articles on value chain modeling that started with “Value Chain Modeling: Part 1, Capability Analysis.”
Value chain models have been used to structure the development and refinement of business processes of an enterprise.  High-level activities are decomposed into more detailed activities.  These are then used to define more detailed, operational business processes.  This is helpful, but a value chain is not simply an abstraction of operational business processes. When I refer to business processes, I mean conventional, operational processes that might be modeled with BPMN (Business Process Model and Notation).
While sometimes a business process flow may align with a value chain flow, a business process defines controls that drive operations while a value chain defines the flow of deliverables between value-adding activities to deliver a product to a customer.  There are no loops in a value chain and no decisions for alternative actions.  A value chain depicts the incremental contribution of value toward the end product or service to be delivered.  A business process, on the other hand may define repetitive and alternative activities that optimize production and deal with exceptions.
For example, Figure 1, below, illustrates the relationship between a business process—the sequence of boxes, and a segment of a value chain—the sequence of circles (activities).  Note that these diagrams are for illustration only and do not represent a formal notation for the models. The value chain segment defines the acquisition of raw material, the production of parts, and the assembly of parts as activities leading to delivery to a customer.  The value chain metrics are based on the average work to produce a single product or service.  The business process supports the Produce Parts activity of the value chain and controls the production of batches of parts according to a production schedule.  The same production scheduling process may control a number of operations in support of different value chain activities.  The cost attributed to the value chain activity is the average cost per part with the setup cost pro-rated.
Figure 1, Alignment of process and value chain activities.
In the value chain segment, the trapezoid element (basket) depicts an inventory between the Produce Parts activity and the Assemble activity to hold the batch of parts until each part is needed.  This is important to the value chain analysis because there are time and cost factors involved.
In Part 1 of this series, I described how a capability may be implemented as a shared service in order to support activities in different value chains. In some cases, such a service may be invoked directly in support of a value chain activity.  However, the above example illustrates that a service may be engaged by a quite-different business process.  In this example, the service to produce a batch of parts is invoked to fulfill the production schedule.  The operations to produce parts are not driven by the completion of the Acquire Material activity as the value chain segment might suggest.
Another distinction between a value chain and a business process occurs where a business process engages a service that, in turn engages other services.  Figure 2 illustrates this in a somewhat unlikely but useful example.
Here the Process Order process invokes the Pick Parts service (depicted by the arrow between the boxes) to get parts from inventory, and then it engages the Ship Parts service that, in turn, engages the Package Parts service to prepare the parts for shipment.  The dashed lines indicate the correspondence of capability services to value chain activities.  This service-engagement control flow is quite different from the value chain deliverable flow from Process Order to Pick Parts to Package Parts to Ship Parts (the sequence of circles).

Figure 2, Service Engagement vs. Value Chain Flow
A best-practice, process design requirement for a capability is for the business processes to be bounded by the scope of the capability.  In the above example, the boxes represent services and the arrows between them represent invocation of services.  The process in the Fill Order service capability begins and ends within that capability.  It engages the Pick Parts service as another business sub-process that is bounded by the Pick Parts capability.  Similarly, business processes for Ship Parts and Package Parts are bounded by those capabilities.  This promotes the loose coupling of services so that a service can be engaged in different contexts, and the effects of changes to capabilities can more easily contained within each capability.  It enables local optimization and innovation.
In summary, a value chain model provides an abstract view of the operation of the business that is relatively independent of the details of how the business operations actually function and are controlled.  The value chain depicts WHAT the enterprise does to deliver value to the customer, but not HOW it does it.  The metrics of the value chain model provide a less complex and more customer-focused view of the business to help identify opportunities for improvement from an enterprise perspective.

Thursday, December 16, 2010

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.