Exploring VDML with Spreadsheets

I developed a limited implementation of VDML (Value Delivery Modeling Language) using spreadsheets to illustrate the concepts and develop a better understanding of the value computations.  The document describing this implementation and a companion Excel workbook are available at the VDMBee web site: http://vdmbee.com/2015/01/exploring-vdml-spreadsheets/ 

I would be interested in feedback, particularly on VDML since the spreadsheet implementation is essentially a prototype, but the technique can be used for a limited application of VDML.

For more on VDML, see my overview at http://fredacummins.blogspot.com/2013/02/value-delivery-modeling-language-vdml_4878.html

Does a company have a capability if the capability is outsourced?

In a LinkedIn discussion at https://www.linkedin.com/groupItem?view=&item=5912670423937478660&type=member&gid=84758&trk=eml-b2_anet_digest-hero-4-hero-disc-disc-0&midToken=AQFNSRpfQ-416Q&fromEmail=fromEmail&ut=1PAPLXT2WvyCo1 the question was raised, if a capability is outsourced, is it still a capability of the outsourcing company?  Capability analysis has gained attention from capability maps.   Capability also is a key concept of the Value Delivery Modeling Language (VDML), see http://fredacummins.blogspot.com/2013/02/value-delivery-modeling-language-vdml_4878.html .  Capabilities are fundamental to a high-level understanding what a company has or requires to deliver its product or service.  I think the LinkedIn discussion suggests that we do not have a shared definition of outsourcing.

To me, outsourcing is engaging an independent business entity to provide a commodity product or service. The outsourced operations represent a required capability, but the implementation is a black box to the purchaser.  The outsource provider is free to perform/implement the capability as it determines best to meet its obligations on delivery of the product or service and be competitive.  

Consider that the outsource provider may, in turn, outsource some of its needed capabilities.  Furthermore, the outsource provider should also be free to provide the same capability to other purchasers/consumers, including competitors of the purchaser—that is one way it can achieve economies of scale not available to its consumers.  The provider also will try to develop its capability in a way that gives it a competitive advantage over its competitors.

The product or service must be a commodity because the purchaser cannot put its key business capabilities in the hands of an external source to be shared with competitors.  That provider might not have the capacity to meet demand of increased business of the purchaser.  Furthermore, the provider may decide it is advantageous to devote increased capacity to the purchaser’s competitor.  If the provider fails to perform, then what? 

The purchaser must be able to find an alternative source.  Of course the provider may fail as a business, and the purchaser must be able to obtain the product or service elsewhere.  The purchaser should obtain the outsourced services through competitive bidding which ensures appropriate pricing as well as the availability of alternative providers.  The purchaser might be well advised to obtain the product or service from multiple providers. 

If a company needs to engage in defining or managing the details of an outsourced operation, then the capability should not be outsourced.  However, the company does need to invest in managing the relationship with the provider to ensure that the provider meets expectations such as product specifications, responsiveness, product quality, risks, and security that might adversely affect the company’s business.

If we are not dealing with a commodity product or service, I would characterize the arrangement differently.  For example, a franchise involves engaging outside business entities to provide necessary capabilities, but the franchiser will generally require an exclusive franchisee, and control over much of the operation so that there is consistency in the end product or service, and multiple franchise operators (as well as the franchisee) can benefit from economies of scale achieved by the franchiser.

If the purchaser needs critical capabilities for a new business opportunity, it may not be able to develop the capability, or it may not have the necessary intellectual property to be competitive.  Then the needed product or service is no longer commodity.  The purchaser cannot simply engage a black box, and it is desirable to have an exclusive arrangement to exclude competitors.  A joint venture is a possible arrangement.  The participants recognize their interdependence, and they make commitments to working together.  Typically there will be shared benefit from the success of the joint enterprise.

Engaging contract personnel might be considered another form of outsourcing.  Contract personnel may be engaged to increase capacity but with their activities restricted to protect key activities.  However, the company may obtain important special skills from contract personnel, and may more directly control the work products and intellectual property used or created by the contract personnel to preserve competitive advantage.  However, this is a weaker form of possessing the key aspects of an essential capability.

This might be a good time to consider the difference between a capability and a competency.  When a business has or develops a competency, that means it controls the key capabilities to be competitive, or realize competitive advantage.  This includes possession of the key resources, intellectual property, relationships, etc.  An enterprise may obtain a capability through outsourcing, but it cannot realize a competency through outsourcing.

So a capability may be outsourced if it is a commodity and outsourcing achieves economies of scale and/or relieves the outsourcing company of the burden and risks of managing an internal capability.  It is still a capability that is part of the company business.  A competency cannot be outsourced.  There are other alternatives to realizing capabilities from external sources that are essential to a competency, but these involve more collaborative and exclusive relationships that protect the competency and preserve competitive advantage.

VDML Support for Balanced Scorecards and Strategy Maps

The Kaplan and Norton Balanced Scorecard(BSC) and Strategy Map (SM) are well-known, abstract models for structuring business transformation objectives.  The analysis of objectives helps refine a strategic plan, and the resulting objectives provide a basis for continuing assessment of progress.  This article describes how VDML can provide more robust analysis for setting BSC objectives and defining SM relationships.  VDML (Value Delivery Modeling Language) is a specification in the final stages of adoption by the OMG (Object Management Group).

BSC/SM objectives represent desired changes to the state of the business—key measurements of the operation of the business will drive improvements.  Thus the changes represented by BSC/SM objectives represent key differences between VDML As-Is and To-Be models. 

The diagram, below, characterizes the objectives of a BSC and SM.  For the BSC, Kaplan and Norton define four perspectives that classify objectives: (1) Learning and Growth, (2) Internal Processes, (3) Customer Value, and (4) Financial.  This classification drives a broader analysis starting with the development of capabilities (Learning and Growth), through development of internal methods and processes (Internal Processes), to delivery of customer value (Customer Value), and finally to enterprise success and sustainability (Financial).

 

The Strategy Map identifies causal relationships—some objectives depend on achievement of other objectives.  For example, an internal process will not be successful without the capabilities that support it (e.g., people, machines, knowhow).  The diagram illustrates the general flow of causal relationships—an actual strategy map would link specific objectives.

A VDML model can represent the current or future state of the business and associated operating measurements.  A model could involve multiple lines of business and multiple value streams.  VDML models can extend the BSC/SM analysis to support more robust transformation planning and assessment.  The diagram, below, depicts this.

So a VDML To-Be model can represent the improvements in performance and value creation if the strategy is successful.  As the basis for objectives, these To-Be measurements must be compared to corresponding measurements in an As-Is (current state) model.  The current As-Is model will be updated to reflect changes as the transformation progresses.  If the transformation goes as planned, the As-Is model will become the same as the To-Be model (transformation complete).  Development of these models is discussed in greater detail in Strategic Planning with VDML.

VDML can represent many of the measurements of interest for the BSC/SM objectives, so a BSC/SM objective may obtain its target measurement from the To-Be model and its current measurement from the As-Is model.  VDML does not directly identify objectives for Learning and Growth, but can represent the requirements for resources that must be developed to achieve capability requirements.

VDML can represent objectives of the BSC Financial Perspective as As-Is and To-Be value proposition measurements and market segment forecasts.  However, VDML does not provide support for the development of these market forecasts.  For example, profit is essentially price minus cost.  VDML supports cost detail, but price is a management decision based on market analysis.  Market share is a forecast based on price and other factors including future competition.  VDML can capture those measurements, but does not provide support for market analysis. 

Operational measurements support more extensive analysis and mapping.  For example, if a new capability is needed, the need is represented by the absence of the capability in the As-Is model.  The objective measurement is essentially binary.  If the capability requires skilled people, we might represent the need for growth with a VDML store of people required for the capability in the As-Is and To-Be models.  The To-Be model may also represent new supplier relationships.

From a VDML perspective, causal relationships (i.e., dependencies) are of six different types: (1) changes to enterprise capabilities (i.e., “capital” in Learning and Growth) that are necessary for implementation of Internal Perspective value stream changes, (2) changes to capabilities that increase customer value (Customer Perspective), (3) changes to capabilities that improve investor value (Financial Perspective), (4)  changes to a value stream that affect activity value contributions to customer value (Customer Perspective) that may involve complex changes reflecting multiple dependencies between activities, (5) changes to the value stream that improve investor value (Financial Perspective), and (6) changes in customer satisfaction levels that drive market changes reflected in investor value (Financial Perspective).  These can be seen in the causal relationships depicted in the first diagram, above.

While these are all supported by VDML, they require two VDML models—the As-Is and a To-Be models.  Type (1) can be observed by a change in capabilities (new or modified) between the As-Is and To-Be models.  Type (2) can be observed as value stream changes that improve desired customer value proposition measurements.  Type (3) requires human recognition of the value investors will place on improved enterprise capabilities.  Type (4) can be observed by tracing the sources of changes to the customer values in the To-Be model to the relevant customer value contributions that are improved from the As-Is model.  Type 5 can be observed from changes in value contributions (such as cost reductions) that have a direct impact on investor value.  Type 6 is based on changes in the customer value propositions but it requires market insight and feedback regarding trends and competition to determine the impact on investor value.  In most cases, these causal relationships do not correspond directly to VDML deliverable flows, but rather they represent the consequential effects of changes to As-Is measurements that will directly or indirectly result in changes to To-Be measurements. 

In a substantial transformation, there must be phases of implementation.  Without objectives (or intermediate target objectives) for phases, management would have difficulty assessing progress on a long-duration project with multiple components.  Each phase should be represented by a VDML model for the expected state of the business at the end of the phase.  The development of a transformation plan and associated VDML models for transformation phases is discussed in greater detail in Strategic Planning with VDML.  As the transformation progresses, a series of As-Is models would be created to represent the incremental, current state of the business. The As-Is model evolves toward the To-Be model so that measurements in the current state depict progress toward To-Be targets. 

The BSC/SM model then becomes a series of phase models with As-Is and To-Be supporting models to define intermediate targets—see the diagram, below.  The To-Be VDML model of a phase is the expected As-Is model of the next phase for planning purposes, but the actual As-Is model for a “next” phase will likely vary some from the planned To-Be model.  A BSC/SM short-term, current-phase model represents the objectives of the current phase.  The full BSC/SM model can be derived from the initial As-Is model and the final To-Be model. 

While the full BSC/SM model can be stable (unless the end state of the business evolves), the current-phase BSC/SM model will be incrementally based on new versions of the As-Is model as the transformation progresses, and it will be based on new To-Be models as new phases are started.

In summary, VDML can provide significant value in validating the strategy, developing the transformation plan, and setting and evaluating objectives and causal relationships appropriate to each phase of transformation.  However, the relationships between the BSC/SM objectives and the VDML models require human input to select appropriate key objectives and identify the causal relationships.  Modeling mechanisms for a BSC/SM extension are not defined in the current VDML specification, but are left for VDML implementers to develop if they determine that there is sufficient market demand.

Strategic Planning with VDML

The OMG (Object Management Group) Business Motivation Model (BMM) defines a framework for the capture of strategic planning information.  This framework reflects widely accepted strategic planning techniques.  The resulting strategic plans define requirements for business changes, but there remains a significant gap between these requirements and the realities of implementation.  VDML (Value Delivery Modeling Language) can help bridge this gap through a more rigorous specification of the current state of the business and the future, desired state. See Value Delivery Modeling Language: An Update for an overview of VDML.

In this article, I will begin with a brief overview of BMM and then discuss the application of VDML to further detail and refine the strategy and to support transformation planning and management.

Overview of BMM

The diagram, below, is an abstraction of the Business Motivation Model (BMM) taken from the OMG specification.  I will briefly discuss the Means and Ends that represent a strategic plan.  Influencers and Assessment are elements of the strategic planning process that provide input for development and refinement of the plan, but they are not, per se, elements of a strategic plan.

End

The End contains elements that define the desired future characteristics of the enterprise including the Vision and Desired Result.

Means

The Means contains elements that describe how the future state of the enterprise will be achieved including Course of Action and Directives.

Vision

A strategic plan, at the most abstract level, is expressed as a Vision of what the enterprise wants to be and how it wants to be perceived.  This is complementary to the Mission.

Mission

The Mission expresses why the enterprise exists--what it wants to accomplish.  Successful pursuit of the Mission should support realization of the Vision.  

Desired result

The desired result consists of Goals and Objectives.

Goal

A goal is a long-term, qualitative result that the enterprise may already be pursuing or that may be advanced as a result of a business challenge or opportunity.  It defines a purpose for the strategy.

Objective

Objectives are specific, measurable results to be achieved by a strategy and support enterprise goals.  While there may be many measures of performance, objectives focus on selected, key measurements that reflect progress toward the strategy and goals from a management and investor perspective. 

Course of Action

A course of action is the approach to implementation of the Mission in pursuit of the Goals and Objectives.  It consists of Strategy and Tactics.

Strategy

A strategy defines how the mission will be pursued and objectives will be achieved.  In conventional strategic planning, it is an abstract description of how the enterprise will operate in the future.  Typically, there will be multiple aspects to a strategy, potentially representing the integration of different ideas.

Tactic                                       

Tactics are incremental changes to the state of the enterprise that lead to the desired future state required by the Strategy.  The distinction between strategy and tactics is somewhat subjective.  Tactics will focus on resolving particular problems and steps toward implementing related changes. 

Directives

Directives are the business policies and business rules that are to be incorporated in the future state of the enterprise.

Business policies

Policies are statements of business operating requirements.

Business rules

Business rules define operating criteria or constraints in specific circumstances.  Business rules implement business policies.

Application of VDML

In my previous post, I gave a brief overview of VDML: Value Delivery Modeling Language: An Update .  Here I will focus on the application of VDML for the refinement and implementation of a strategy.  This is not intended as a standard method, but illustrates how VDML can be used to improve the discipline and rigor of strategic planning and transformation.
VDML does not address all aspects of a business transformation.  I expect that VDML will be used to support strategic planning and transformation program management for the operations and capabilities of the business.  It will be complemented by related efforts such as development of policies, analysis and development of markets, design of incentives and development of contractual relationships. 

Development of a single idea

In this section, I will define an approach for development and implementation of a strategy for one idea.  I the next section I will extend this to consider multiple ideas in an on-going business transformation.
The basis for consideration of changes is a VDML As-Is model.  This represents the current state of the business and will contain measurements reflecting current business operations.  The current set of measurements may be in a VDML scenario with another scenario set of measurements representing target measurements.  The As-Is model may actually be a composite of VDML models representing different parts of the business.  The important point is that the current business design and measurements, including value propositions, are established as a basis for evaluating and planning changes.  It provides a context for understanding problems and assessing solutions.

An idea is a potential strategy at an inspirational stage of development.  When that idea is refined, validated and accepted, it becomes a strategy (or a component of a more complex strategy). We start with consideration of one idea to improve the business.  We will focus on aspects of the idea that involve changing the operation of the business.  This may include the impact of new technology, changes in capabilities, activities, resources (including personnel and their skills), organizational changes and the implications to value propositions (potentially multiple market segments).   The diagram, above, depicts steps of development of an idea through transformation of the business.  I will discuss each of these steps in the paragraphs that follow.

1.      Model alternative implementations

I will assume that there are alternative approaches to implementation of the idea under consideration.  Each alternative should be modeled as a VDML To-Be model.  The VDML model will support analysis of the idea to define a cohesive impact on the organization, capabilities, activities, resources, value contributions and value propositions, potentially including business partners. 
Each To-Be model may include new capability methods, some new activities and stores, elimination of some old activities and stores, changes to existing capabilities, changes to organization structures, additions/deletions and changes to business items, changes to staffing and possibly some new types of value measures.  These To-Be models are both the basis for validation and refinement of the idea and for selection of the preferred implementation alternative.  Note that VDML provides the ability to assess changes from an enterprise perspective such as the impact of changes to a shared capability used by other lines of business.
VDML measurements are based on a unit of production.  Consequently, capacity requirements for resources and facilities must be computed by multiplying such measurements by projected production volumes.

2.      Select from alternatives

Each alternative To-Be model is compared to the As-Is model to identify the changes required.  On the surface, this will likely involve changes to activities and associated capabilities, but these may require organizational changes and training or replacement of personnel to obtain necessary skills.  Capabilities may require new or expanded facilities.  The To-Be model provides the basis for estimating activity value contributions as a result of the changes along with their impact on value propositions.  It also provides the basis for estimation of transformation costs and duration.  These measurements, along with other, non-VDML factors will be the basis for selecting an alternative.  Even if there are no alternatives, this is an essential step for the steps that follow.

3.      Define implementation phases

An idea is now a strategy for which an implementation plan must be developed.  VDML will provide the basis for planning the work of transformation.
A plan should have phases of implementation for partitioning and managing work.  Phases should define incremental development and potentially achieve short-term benefits rather than waiting for full implementation of an idea to evaluate the work and realize the desired benefit.  This also provides the opportunity for periodic re-assessment and adjustment of the strategy for changed circumstances.
The changes identified in step 2, above, must be organized into implementation phases.  Each phase will have a package of changes to be implemented together.  Some changes may be dependent on others—the VDML deliverable flows will help identify these dependencies.  Some changes may achieve greater benefits than others.  The priority of changes may be affected by the benefits as well as the availability of funding or resources.  Each phase should achieve implementation of a stable business state that can be measured.  If possible, each phase should yield business benefit.

4.      Model next phase To-Be

Transformation program management will iterate over the current and remaining steps for each phase of the strategy implementation.
Prior to each phase, a To-Be model is developed or refined for the next phase.  The To-Be model incorporates the activities, capabilities and resources to be developed in that phase.  This, in turn, identifies the organization units responsible for the changed business operations as well as the organization units of related activities that will require collaboration and coordination.
Based on the phase To-Be business design, a project plan is developed for the phase.  This will define cost and duration targets for the transformation work along with a timetable for transformation resource requirements.

5.      Define phase objectives

Each phase should have defined objectives for affected organization units as well as the overall impact of the undertaking.  An idea may affect multiple market segments and thus multiple value propositions.  The phase To-Be model includes measurements for the expected value contributions of activities that are affected by the transformation. 
Changes to value contributions for each affected activity will be targets for performance by the organization unit that provides the supporting capability.  Where capabilities are engaged through delegation, organizations responsible for each level of delegation will have target measurements to meet.  The impact on aggregated values will be targets for the overall undertaking for the enterprise or the targeted line(s) of business.

6.      Implement the phase plan

This step involves doing the work of transformation.  Each phase may be managed as a separate project with a detailed plan.  The project must address all aspects of the transformation for that phase including changes in products, technology, organization, personnel, facilities, information systems, and activity inputs and deliverables.  Some aspects are beyond the scope of a VDML model, but the VDML model will help identify them.

7.      Evaluate objectives

At the end of each phase, an As-Is model is created as a new baseline.  This model should be very similar to the To-Be model for the phase, but the measurements are actual value measurements.  These measurements are compared to the To-Be expected value measurements to evaluate success of the phase.  The As-Is and To-Be models may be two VDML scenarios since they should have the same structure but with actual vs expected measurements. 
While the implementation effort may be completed, there may still be work required to stabilize and optimize the capabilities, so there may be some additional time allowed to achieve the targets.  In the meantime, work may proceed on the next phase, returning to step 4, above.
When the last phase is completed, the overall success of the strategy and transformation can be evaluated by comparing actual measurements of the final As-Is model to the expected measurements of the final To-Be model.

Transformation as a continuous process

In the real world, enterprises do not focus on the implementation of one idea at a time.  As some ideas are being implemented, other ideas will emerge.  These new ideas will affect some of the same business elements undergoing transformation.  Some ideas will be completed while work on other ideas remains to be done.
Consequently, a strategy may include multiple ideas that must be reconciled, and it may evolve to include new ideas over time.  A VDML model supports analysis of the application and integration of these ideas to achieve a coherent strategy.  The definition of tactics and assignment to teams could result in different interpretations and implementations of the strategy, but a VDML model can provide a shared context for identification and resolution of potential inconsistencies. 
The following paragraphs extend the above transformation steps to reflect on-going, continuous transformation for implementation of multiple ideas.  The numbers in parentheses indicate the affected steps in the above diagram.

Evaluate To-Be alternative models (2)

A new idea may be evaluated and change requirements identified based on the current As-Is model, but the overall evaluation should also consider changes already planned for other ideas that affect some of the same business elements.  This extension effect can be assessed by using the To-Be model for completion of the current, composite strategy so that any planned changes are included in the baseline for the new idea.  Note that there may be trade-offs with the implementations of adopted ideas to be considered in solutions for each new idea.

Align changes to phases (3)

The changes for the new idea must be reconciled with the To-Be models of pending phases of the current strategy, and the program plan must be updated to reflect these changes.  If there are no related changes, then implementation of the new idea may be considered as an independent effort.  When changes affect some of the same activities and supporting capabilities, there must be a determination if they should be included in an existing phase or will require a distinct phase.  This may be affected by the priority of the idea, funding, resource requirements, or other factors such as risk and scope of change.  Changes to the work of existing phases may result in new dependencies and thus require changes to the order of pending phases.

Revise phase To-Be model(s) (4)

Based on the alignment of new changes to pending changes, a To-Be model must be developed or adjusted for the current phase or at least the next phase.  To-Be models for additional phases may be deferred, particularly if the work of pending phases or new ideas are likely to result in adjustments to the model.
The next phase To-Be model is important, as before, for development of expected value measurements for the phase.

Revise phase objectives (5)

To the extent the next phase is expected to achieve different results with the newest idea, it will be necessary to reconsider which value measurements are key to evaluation of success of the phase.

Ideas completed (6)

In a continuous transformation environment, implementation of some ideas will be completed while work on other ideas continues.  When the changes for an idea are completed, the result should be evaluated against the To-Be expected value measurements of the original idea.  The targets should be at least achievable in the near future (allowing for stabilization of operations), or exceeded if changes for other ideas have contributed improvements.

Conclusion

A VDML To-Be model for a strategy and the series of To-Be models for each phase of the implementation define requirements for transformation of the business.  The phases reflect priorities and dependencies between changes.  The To-Be model for a phase reflects the expected impact on the value measurements, activities, capabilities, organizations and resources affected.  Value propositions provide the basis for consideration of the competitive impact of the phase.

The effort to implement these phases must be defined in a transformation plan.  This plan might be defined as a program plan with plans for phases defined as project plans.  The requirements defined by the strategy To-Be model are the basis for the more detailed design and development of resources, business processes, organization roles and responsibilities and performance measures.    

VDML also provides the basis for definition of BMM Objectives.  Implementation phases as well as the final To-Be model provide a basis for estimating costs and durations, and the expected value contributions and impact on value propositions.  Key measurements or milestones should be identified as strategic planning Objectives of the BMM Desired Results.

The To-Be VDML models provide insight on requirements for IT support and system changes, for application of business policies and rules, and for consideration and mitigation of risks.

Application of VDML will bring a change to the way strategic planning and business transformation are performed.  Not only will it enable better planning and monitoring, but it will enable more effective management of complex and multi-faceted transformations needed to keep up with rapid changes of business and technology.

Acknowledgements 

My work on alignment of VDML with BMM and support of strategic planning has been in collaboration with Henk de Man, Director of Research at Cordys.   

Value Delivery Modeling Language (VDML): An Update

VDML (Value Delivery Modeling Language) is a business modeling language.  It supports business analysis, design, and transformation with a focus on optimization of both customer value and business operations from an enterprise perspective.  Modeling of the creation and exchange of value is a distinguishing feature of VDML.  VDML provides an abstract representation of the design of the enterprise that is meaningful to managers and executives, and it provides a basis for collaboration on challenges and opportunities.

A VDML model includes measurements of operating variables and value contributions.  These measurements are the basis for assessing the effectiveness of the business operation.  Changes to the design or operating measurements will be propagated to changes in the measurements that describe overall performance and customer satisfaction. 

VDML is under development as an OMG (Object Management Group) standard.  In late 2010 and early 2011, I did a series of blog posts on VDML starting with Value Chain Modeling Part 1: Capability Analysis.  Since that time, we engaged additional experts, incorporated additional perspectives from a number of business modeling techniques, added graphical notation and refined the earlier metamodel specification. 

In this post, I will provide a brief overview of the VDML principal concepts and their relationships based on the latest draft specification. In subsequent posts I will discuss some of our current work as we move toward adoption of the proposed OMG specification later this year.

Collaborations and roles

The fundamental, structural concept of a VDML model is collaboration. A collaboration is defined as a group of participants, working together for a shared purpose.  An enterprise involves many, networked collaborations including collaborations with customers and suppliers.  Roles within a collaboration define how each of the participants contribute to the collaboration.  A participant can be an actor (person or automaton), a supporting collaboration or another role.  For example, a manager (role) of an organization (collaboration) can be assigned as a member (role) of a task force (collaboration).

There are four specialized types of collaboration in VDML: an organization unit, a business network, a community and a capability method.  These are described in the following paragraphs.

An organization unit, such as a department, a team, a division or a corporation, is a collaboration that is relatively stable with associated resources including people, facilities and intellectual capital. The roles in an organization unit may be filled by people and/or other organization units thus representing an organization hierarchy.  There are typically organizational relationships in an enterprise that do not fit the conventional organization hierarchy pattern such as project teams, interest groups and committees.  VDML provides for the representation of all organizational relationships.

An organization unit typically has defined capabilities based on its purpose, resources, facilities and intellectual capital. The activities required for an organization unit to apply a specific capability can be modeled with a capability method, discussed below. 

A business network is a collaboration among economically independent business entities.  This may represent customer relationships and relationships with suppliers or other business partners.  Business networks focus on the exchange of products, services, money and related values such as product quality and availability of field support.  In a viable business network, participants exchange values where each participant receives values that, in its context, has  greater economic value than the values it provides.

A community is a loose association of members such as a professional association, an industry standards group, a market segment or employees with a common interest who share ideas. In a business network, a typical customer may be represented as a member of a market segment community.

A business capability is the ability to perform a certain kind of work.  A capability method is a collaboration with defined roles and activities for applying a business capability to deliver a particular result.  An organization unit may have a general capability, but it typically delivers more specific capabilities using its resources, facilities and intellectual capital in particular ways.  Its capability methods define patterns of activities and resources required to apply the more specific capabilities.  

Activity networks

Within any collaboration, activities can define what the participants do in their roles.  Activities receive business items and add value to change or produce business items as deliverables.  Stores represent inventories of business items pending consumption by activities or delivery to another recipient.  Business items can include resources, intermediate products, sales orders, money, specifications, intellectual property or anything that is an input or deliverable of an activity that is relevant to the value contribution.  Most deliverables are received by activities or stores in the same collaboration, but some are outputs to other collaborations, including external business entities. 

The dependencies based on deliverable flows between activities and stores form an activity network within a collaboration.  An activity network can represent any form of repetitious, organized behavior including adaptive processes that perform some activities only part of the time. 
 
VDML does not represent process flow-control loops or decision branches, but focuses on the utilization of activities and the flow of deliverables between them.  Measurements of values (for example, cost and duration) associated with activities and stores each represent an average per unit of production, so the measurements for an activity may reflect that it is engaged only once for some units of production, and multiple times for other units of production.

Capabilities

VDML includes a capability taxonomy that may be represented as a capability map.  Each capability identifies the organization units that can provide that capability. 

Each activity requires a capability and identifies the role of an assigned participant has that capability to perform the activity.  The activity defines how that capability contributes to the particular collaboration. The role of a participant may be associated with multiple activities in the collaboration.  The participant must meet the capability requirements of each of the activities associated with that role.

A role may be filled by an actor (a person or automaton), or, where the work of the activity requires multiple participants, it may be filled by an organization unit with the required capability.  The organization unit may identify a capability method that defines how the capability is applied.  The capability method is engaged by the activity through delegation.  Delegation is the mechanism by which a capability method can be shared as with shared services.  Delegation defines the flow of inputs of the parent activity to the capability method and from the capability method to become deliverables of the parent activity. 

Values and value propositions

Activities add value to produce deliverables.  Values may be positive or negative.  Values of interest typically include per-unit cost, duration and defects, but other product-specific values may also be captured.  Each value-add contribution is expressed with a measurement.  From contributing activities, value adds of each type are aggregated in a value proposition that represents the values of the product or service.

A value proposition is a package of values and deliverable(s) that are offered to a recipient, typically a customer, but a value proposition can also be offered to other stakeholders such as business owners or internal “customers.”  The value proposition incorporates those value contributions that are of interest to the recipient.  The value proposition expresses its values from the recipient’s perspective.  For each type of value, the aggregated measure is transformed to a level of satisfaction based on a formula for the particular type of recipient.  Different customers or market segments may be interested in different values with different priorities, so separate value propositions can represent the levels of satisfaction for these different recipients. 

Value stream

The activities, deliverables, capabilities and values that contribute to a value proposition are characterized as the value stream for that value proposition.  Value contributions and deliverable flows that feed the value proposition can be traced back to the activities involved and the capabilities they use to contribute to the value proposition.

When a value proposition indicates a poor level of satisfaction of a value, the value stream can be examined to identify the activities and thus the capabilities that contribute to that value and the analyst will look for potential improvements that could raise the satisfaction level.  Conversely, if a capability is disrupted, an analyst can determine all value streams that will be affected.

Measurements and scenarios

VDML provides the ability to represent the same business model under different circumstances.  The structure may be the same, but the measurements are different.  We describe these different circumstances as scenarios.  So the measurements of different product mixes might be represented with different scenarios. 

In addition, a capability method might be engaged more than once within a value stream or by multiple value streams.  The measurements of the capability method will be specific to each context.  VDML manages the measurements separately for each occurrence.

Summary

VDML provides the means to manage the complexity and competitive forces that I outlined in Rethinking Business for a Changing World.  VDML will provide a robust modeling capability for business architects and managers that goes beyond business process modeling to incorporate modeling of value creation and exchange, capabilities and capability sharing, organizational relationships and performance measurements.  Business processes are part of the model but are represented without the flow-controls details.  This will improve understanding of the way the enterprise works, and will provide support for strategic planning, decision-making, innovation and optimization of business value.  It provides a context for consideration of many challenges such as capacity planning, risk management, regulatory compliance, business transformation, new product planning, consolidation and outsourcing.   It will enable development of persistent business models that can be used for on-going analysis and  improvements rather than requiring a new, blank-slate modeling effort for each new challenge or initiative.

At the same time, VDML will improve accountability for customer value contributions.  It will provide information needed by first-line managers to improve their operations with an understanding of their impact on the rest of the business and the related organizations with whom they must collaborate and coordinate.  It enables enterprise-level optimization where many lines of business share capabilities for economies of scale and improved enterprise agility.

Acknowledgements

Henk de Man, Director of Research at Cordys, has been the primary co-developer of the VDML specification.  In addition, a number of other industry experts have made important contributions including Arne Berre of SINTEF, Verna Allee of ValueNet Works, Pavel Hruby of CSC, Pet Rivett of Adaptive, Peter Lindgren of Aalborg University, along with many others who have provided feedback on the draft specifications.

Adaptive Case Management Modeling Specification Proposed

A specification for Case Management Model and Notation (CMMN) was proposed and recommended by the Business Modeling and Integration task force at the OMG (Object Management Group) meeting in December.  Membership voting on the proposal is under way. 

The following companies contributed to the specification:

  Agile Enterprise Design, LLC
  BizAgi Limited
  Cordys Nederland BV
  International Business Machines Corporation
  Kofax plc
  Oracle Incorporated
  SAP AG
  Stiftelsen SINTEF
  TIBCO Software
  Trisotech

The specification defines an exchangeable modeling language for specification of a case type as an adaptive process supported by planning elements and a case file structure.  It supports most of the knowledge worker facilities described in my blog post in July of 2011 entitled "A Knowledge Worker Cockpit." 

However, much of the vision described in my blog depends on the runtime implementation of software products that apply this specifiction as well as the integration of those products with related systems.  I expect there may be some early offerings in 2013.

Business Culture: Part 6, An Abstract Model of Culture

This is the sixth and last part in a series of blog posts on Business Culture.  This part incorporates the concepts discussed in earlier parts to define concepts and relationships used to model a culture or a cultural architecture.

In order to clarify the meanings of the concepts, I will present a series of conceptual model segments that build to an overall business culture conceptual model. I offer this model, not as a final solution, but as a useful basis for understanding culture and for further discussion.  This model should be helpful for considering approaches to development, adaptation or alignment of culture with business goals. It is not an architecture of culture, but rather it defines the elements that might be composed into patterns that represent a particular cultural architecture or composed to represent a business culture with or without awareness of architecture.

Figure 1, Collaboration activities

Figure 1, shows the basic elements of collaboration.  Participants fill roles to perform activities.  The participants provide capabilities that enable performance of the activities.  A capability is the ability to perform a particular kind of work that may include knowledge, skills, tools and resources.  A role may be associated with multiple activities, and each activity may require that the same participant have different capabilities.

Figure 2, Practices and related collaborations

Figure 2 extends the basic elements to identify business practices and recognize relationships with other collaborations.  Business practices are commonly occurring patterns of activities and participant roles.  These patterns enable the collaboration to quickly respond to a situation without a lot of analysis and discussion because they do what has worked before.  Where the situation is a bit different, a business practice may be used as the basis for tailoring the activities to the new situation.  Business practices may not be documented but are understood by the participants.  As circumstances change, old practices may be adapted or abandoned.  Business practices are “the way we do things.”

A role and thus the activities it performs in a collaboration may be filled by another collaboration.  This occurs when the primary collaboration requires skills or resources that it does not have, or the engaged collaboration manages shared resources for economies of scale.  Delegation to such a collaboration occurs in each activity of the same role.  Each activity defines the specific objectives/requirements to be achieved by the engaged collaboration.

Participants in the primary collaboration may also participate in other collaborations.  An engineer may participate in a design review or a professional society.  The interests of participants may be affected by values of other collaborations such as technical guidelines, ethical standards or ideals.  This can influence the participant’s performance in the primary collaboration.   

Figure 3, Participant Motivation

Figure 3 extends the model to consider motivation.  Participant interests are aspirations and concerns that may inspire the participant to take (or oppose) some action.  Participants have interests that provide motivation to engage in collaboration activities.  In order to engage a participant, some of the participant interests must align with goals, objectives or values of the collaboration.  In addition, the relevant interests of different participants must not be in conflict. 

For example, if representatives of multiple software companies come together to develop an industry standard, each of them has an interest in minimizing the adverse impact of the standard on their product(s).  The collaboration will only be successful if either they can reconcile their different interests in a consensus solution, or they individually recognize that they must participate to mitigate and plan for the consequences to their products in order to compete in an emerging market. 

The synergy of a collaboration may also be affected by the similarity of interests of individuals that go beyond their interests in the goals and incentives of the collaboration, and extend their relationships to a social context—personal relationships.  The social context may improve cooperation, but it may also increase resistance to change.  This reconciliation of interests is part of the formation and evolution of culture.

If a role is filled by another collaboration, the interests of that collaboration are reflected in its own goals and objectives (discussed later). 

Participants  may also have interests that are not relevant, or interests that conflict with the collaboration goals or activities.  A collaboration may include incentives that leverage relevant participant interests to enhance motivation.  Typically, the primary business incentive is financial compensation.  Without incentives, the participant may not be motivated to contribute, although some interests may be strong enough to provide motivation without incentives.

Motivation is a net effect of multiple interests and incentives. Incentives can offset the effects of conflicting interests.  For example, a participant may have an interest in family activities, but will forego some family activities if paid overtime or offered a bonus. 

Figure 4, Work products and values

Figure 4 extends the model with work products and values.  Some work products may be external inputs to the collaboration.  Many of the work products may be used internal to the collaboration as inputs to other activities.  Some of the work products become output products of the collaboration.

Values are properties of work products that affect the desirability of the work product or the activitiy that produces it.  The cost, timeliness and quality of a work product are included as values.  Values may also be negative, depending on the recipient’s perspective.  So the creation of pollution or toxic waste may be of concern to participants as well as to others outside the collaboration.  External incentives, such as laws and regulations, may be created to mitigate the environmental impact.  The collaboration may also have social or economic impacts that are of interest to participants and affect their motivation.  In some collaborations, these are the primary sources of motivation.

Consequently, values reinforce some motivations, and fulfill the intent of some incentives.  A value achieved may fulfill an incentive to become the basis for some benefit such as a bonus or recognition of achievement.  Of course some values may have negative effects on motivation and incentives.

Figure 5, Goals and Objectives

Figure 5 Adds Collaboration goals and objectives.  Goals are general aspirations for the effects of the collaboration over time.  Objectives are specific, measurable accomplishments.  Goals are the basis for the participants to form or join the collaboration.  Objectives are specific to particular undertakings and may be different for different undertakings, but not inconsistent with support for the goals.  Some objectives are internal to adapt or improve the collaboration capabilities.

For example, if the collaboration provides services, the goals would characterize the general purpose and capabilities of the collaboration.  Objectives would define the results to be provided in response to a particular service request.  Consequently, the objectives must be satisfied by values achieved in response to that particular service request.

Incentives are designed to promote the goals and objectives of the collaboration.  Consequently, some incentives may be designed for long-term effects, and others may be designed to affect more specific results of a series of actions by the collaboration.

Relationship to VDML

This culture model aligns with some elements of VDML (Value Delivery Modeling Language).   VDML is a modeling language (a metamodel) under development at OMG for representation of enterprise architecture and business design.  See Outside-In Business Architecture with VDML and earlier posts about VDML on this blog.  The core structure of a VDML model is a network of collaborations, roles and capabilities that contribute to the success of an enterprise.  The modeling elements include collaborations, roles, activities, capabilities, methods, deliverables, flows, values and resources to specify and support analysis of the operation of an enterprise.  Some of these concepts correspond to concepts in the culture model discussed above.  Concepts of the culture model could extend the VDML metamodel to represent the impact of culture and incentives, as well as personal interests, on the operation of an enterprise. 

A final version of the VDML specification is expected to be submitted to the OMG in November, 2012.

Summary

The culture model, above, aligns with the collaborations, the roles, the capabilities, the activities and the value delivery of VDML, including the intangibles of VNA (Value Network Analysis).  It adds objectives, individual interests, incentives and motivation that affect how well and efficiently the work gets done, as well as the feedback that leads to further refinement.  Thus we can see how culture fits into a business model and how it affects the delivery of value.

This model does not define a cultural architecture, nor does VDML define a business architecture, but the elements provide the basis for describing architectures.  An architecture can be expressed as particular patterns of elements and relationships between elements.  By analogy, houses are built, using generally available construction components.  Patterns of configuration and particular features of those elements express an architecture.

While the foregoing discussions and the culture model described above still require more work, I hope they can provide a basis for a better understanding of culture, additional discussion and development of a computer-based, culture modeling capability.