Value Chain Analysis

Recently we discussed how business services are realised in terms of business process, people, information, data, applications, and technology. A business service can be seen as a cohesive business capability that does not share process, data or business rules with any other capability.

The interface (or service contract) between business services is expressed in terms of business events. Business services are not dependent on how other business services are fulfilled, only the business events they raise. Consequently, the business architecture description is very stable. We can update process implementations without impacting any other processes so long as the high level business events are unaffected.

Our technical service components are then aligned with our business services and business events, extending this stability and loose coupling to our IT architecture.

So business capabilities are the key ingredient in determining our service model. But how do we go about identifying business capabilities? Do we simply think about what a business does at a high level and decompose? Or is there a better way?

A while back Nick Malik wrote about the relationship between capability modelling and process modelling. He posed the question as to whether these two approaches conflict, or if they are in fact complimentary. If you've been reading my recent posts on the matter you would probably guess that I feel the two approaches are very much complimentary.

Nick suggests that there are two main approaches one may take in identifying business capabilities. One is process centric where capabilities are defined around process areas within an organisation. The other suggested approach is to align business capabilities with organisational structure. In this approach, capabilities mirror the structure of a business (such as divisions, departments, business units and teams), rather than its processes.

As you've probably gleaned from my previous posts on business architecture modelling, I very much favour the process centric approach. In fact, the premise of modelling business services around capabilities relies on the capabilities being process-centric. As I mentioned above, the interface between business services is expressed in terms of business events. Business events are raised by business processes.

If a single business process were to feature in multiple capabilities (as would be the case if we modelled our capabilities around organisational structure rather than process areas), then multiple capabilities would expose the same business events. Moreover, updating a single business process would potentially involve updating the implementation of multiple business capabilities.

So when using business capabilities as a means of identifying candidate business services we must take a process-centric approach. How then do we produce a process-centric capability model of our enterprise? The answer lies with Value Chain Analysis.

Value Chain Analysis involves identifying the top level process areas (or functions) of an organisation and mapping them as a value chain. The value chain illustrates the series of top-level processes an organisation uses to take inputs from the market, transform those inputs, and then deliver value added products and/or services back to the market at a profit. These processes are synergistic in nature. The total cost of these processes is less than the value added by the organisation, thus justifying the profit margin.

A value chain is modelled in terms of primary and support activities. Primary activities are those that feature in the value chain itself. They are the processes responsible for engaging with the market and directly transforming inputs into outputs. Support activities support the primary activities.

The value chain for a typical insurance organisation is illustrated below.


There are seven primary and seven support activities in the above example. Each activity contains a number of processes that support the activity. Note that not all processes within a primary activity necessarily directly contribute to the value chain. A primary activity must only contain at least one process that contributes to the value chain.

An organisation may also have multiple value chains. Multiple value chains may arise where the organisation serves more than one market. Different markets may be served with fundamentally different processes within the organisation.

For example if we were to take two companies supplying completely different products to completely different markets and a merger were to occur, then we would end up with one organisation with two value chains. Support activities in one value chain may be primary activities in another.

The value chain depicts an end-to-end process that executes left to right. In the above example, Marketing sits at the beginning of the value chain because the business must determine what products it is going to offer before doing anything else. After determining the product mix and pricing strategy, Risk Modelling must occur to determine the means by which premium will be calculated for each product.

Armed with this information, actual pricing (rate charts) can be determined for each product. Note that this occurs in the Marketing activity. So we have transitioned back from Risk Modelling to Marketing. Feedback loops are always going to occur within value chains. The point is that the first process that had to occur (determining the product mix) lay within the Marketing activity, and thus Marketing sits before Risk Modelling in the value chain.

Now the business is in a position to start selling its insurance products to customers. This is the Sales activity. The Sales activity involves quotations, proposals, risk assessment and commission calculation. Commissions are paid to all parties involved in the distribution channel.

Once a policy has been sold, it must be written. This is a Policy Administration activity. Once the policy has been written, the customer must then be billed. Once the premium has been paid by the customer, the customer may at some point register a claim. Note that this activity is optional. A customer may never register a claim. The Customer Service function is then responsible for serving the needs of the customer until his or her policy expires.

A value chain gives us a functional model of our organisation. That is, it models the functions an organisation performs without consideration for how they are performed. This is what gives the model its stability.

Later on as we drill down into the lower level processes supporting each activity in the value chain, we start getting into the implementation details. We start modelling the exact sequence of actions performed and the roles that are responsible for those actions.

It is through defining these lower level processes that we in fact are able to define the roles within the organisation and the responsibilities and KPIs for each role. Armed with this, we are then in a position to determine the organisational structure - that is, the reporting relationships between the defined roles.

This is illustrated below.


As lower level processes change within an organisation, so may the roles and responsibilities and by extension the organisational structure. This is further evidence of why we should model capabilities around business functions rather than organisational structure. It provides a considerably more stable model.

This activity of modelling the value chain has forced us to consider the entire business in a holistic and process centric way. As such it is an excellent tool for identifying our top level process centric business capabilities that we can then use to define our business service model.