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.