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.

Tuesday, November 30, 2010

Modeling is Key for the Next Generation CIO

In June, 2009, I posted an article on the HP The Next Big Thing blog entitled “The Next Generation CIO.”  The transition is under way.  In an interview entitled “The Evolving CIO Role: What One Headhunter Says CIOs Need to Know,” Shawn Banerji, managing director of an executive search firm says the CIO role “really is for a business leader, someone with very strong commercial skills and vision who also is a superlative business operator.”  This business leader has enterprise-wide responsibility for optimization and agility of the design and operation of the business systems.  This responsibility cannot be fulfilled without a computer-based modeling capability.
The traditional role of information systems management was application of information technology for automation and integration of human tasks.  This was a bottom-up transformation of the business to exploit information technology, and the business benefits and system requirements were within the scope of the affected business function managers.
This evolution of systems essentially transformed the technology of the business systems, but the basic structure of the business became embedded in computer programs.  As the scope of automation and integration increased, the systems became more complex with interdependencies that crossed organizational boundaries.  At the same time, the pace of change in products and services continued to increase.  Businesses now face global competition, and customers expect access to information and services 24 hours a day, every day of the year.  Not only must the business systems adapt to improve operations, but they must continually adapt to changing business challenges and opportunities.
The enterprise as a whole must be managed as a system that integrates with systems of suppliers and customers.  At the same time the enterprise system must be structured so that it can adapt to change without major overhaul.  This cannot be managed through the traditional budgeting and delegation approach to management of system changes. That narrow perspective results in sub-optimization of both the technology and business operations.  Effective management requires an enterprise optimization perspective on both the business systems and the supporting information technology infrastructure..
In my book, Building the Agile Enterprise with SOA, BPM and MBM, I describe the design of business systems from a business perspective.  Technology is a necessary part, but the focus is on designing the operation of the business to leverage technology.  Modeling is essential to managing the scope and complexity of the business systems of an enterprise.  The CIO should provide the executive leadership to develop and manage the models, support analysis for optimal systems design and investment, and optimize the application and management of technology.
The Object Management Group, an international standards organization, is developing specifications for computer-based, business modeling tools.  A key segment of this effort is development of a "value delivery modeling" capability that builds on value chain modeling that was introduced by Michael Porter in his 1985 book, Competitive Advantage: Creating and Sustaining Superior Performance.  This technology will enable the CIO to provide a model of the capabilities of the enterprise and how they contribute to the development of customer value in the enterprise products or services. It also helps identify and manage shared capabilities for agility and economies of scale. The basic concepts of this modeling approach and related business models and design concepts are discussed in my book.
In subsequent posts, I will discuss value delivery modeling and the development of business modeling standards in more detail.