Proposals for a Case Management Modeling Standard

Three initial proposals have been submitted in response to the Object Management Group (OMG) Case Management Process Modeling (CMPM) Request for Proposals.  I reported the initiation of this work in a blog entitled “Case Management: The Missing Link in BPM,” in July, 2009.

A recent book, Mastering the Unpredictable, provides a number of perspectives on “adaptive case management.”  The emphasis is on a class of business processes that cannot be predefined as in conventional business processes such as those modeled by BPMN (Business Process Model and Notation).  The OMG CMPM proposals focus on support for modeling the case file structure and process elements of adaptive processes to support the activities of people planning and performing case management or similar knowledge work.

There are two key trends driving the development of case management automation.  First, the Internet has made access to systems available any time, anywhere.  People can access and interact with web pages and email from their cell phones.  This has a significant impact on the level of automation support that is practical.  This development is complemented by a longer-term trend toward a workforce of knowledge workers.  Routine, predictable activities have been automated, leaving the unusual and unpredictable activities to humans to make decisions and take appropriate actions.  The focus of the OMG specification is to support modeling of aspects of each type of case to enable a knowledge worker—case manager or participant—to productively plan, track and perform work interactively with useful guidance, automated alerts and coordination of activities of multiple participants.

I am one of the developers of the proposal entitled “Case Management Model and Notation (CMMN).”  We approached case management as a new process paradigm where the modeler must consider how the case manager and participants will plan and coordinate their work and must anticipate the process elements and case file structure that will be useful for a particular type of case.  The other proposals have approached case management as an extension to the BPMN specification.  In either case, case management may be initiated by a traditional business process, and case management may initiate traditional business processes to perform prescribed services.  However, this integration involves interaction between the processes, not necessarily a single modeling environment designed for modeling both adaptive, unpredictable processes and prescribed, repetitive processes.

However, we recognize that certain groups of activities will emerge as commonly occurring and should be modeled for re-use in an operational environment.  We define these as process fragments.  In general, the case manager will still have discretion to modify these fragments to suit the particular circumstances.  Where these fragments become substantial and stable, they can be specified as BPMN shared sub-processes, to be engaged at appropriate points in a case.

There will be considerable discussion about the potential to extend BPMN.  The following are issues to be considered.

·         Operational paradigm shift.  Case managers and participants actively define what is to be done rather than following a script as defined by a BPMN process.

·         Different modeling paradigm.  Modelers must think in terms of what is useful for case managers and participants while preserving their flexibility and discretion.

·         Event driven.  Various events will occur throughout the lifecycle of a case and must be addressed in the current context of the case.  A BPMN model cannot anticipate many possible events and their different consequences for subsequent activities under different circumstances.

·         Different stage of evolution.  BPMN has matured over many years while case management is new and should be influenced by experience that is incorporated in subsequent versions of the specification independent of BPMN.

·         Participant collaboration.  Participants in a BPMN process are coordinated by following the prescribed process.  Participants in case management must collaborate to define their plan and make decisions.  Automation should facilitate that collaboration.

·         Guidance and controls.  The case file represents the state of the case and will be the basis for guidance and controls affecting plans, decisions and actions, whereas data is a minimal concern in modeling a BPMN process.

·         Knowledge worker empowerment.  Knowledge workers must be able to do what is right, and not be limited by assumptions of the modeler.  BPMN is oriented to specification of a defined process that prevents variation.

·         Continuous improvement.  The repetitive, best practice actions of knowledge workers should be captured and fed back into the case management model to reduce the planning effort and improve outcomes.  BPMN feedback is from comments and observations.

·         More detailed guidance and tracking.  Because of the accessibility of the system, the availability of relevant information and the value of a shared, up-to-date plan, knowledge workers will incorporate case management automation into how they do their work and their record-keeping, resulting in guidance and tracking that are more accurate, timely and complete.  BPMN processes tend to be more abstract and less connected to the specific situation.

·         Product innovation.  Case management is a new, emerging market.  The standard should allow new vendors to enter this market with innovative approaches without the burden of also implementing the BPMN specification.

·         Language simplicity.  Some have complained that BPMN is already too complex.  Integration of case management will increase BPMN complexity,  potentially acting as a disincentive for possible users of both BPMN and case management  technology.

Given these considerations, we will explore the implications of BPMN extension for case management.  An ideal solution would enable one vendor to extend a BPMN product while another vendor implements only a case management product.

Below are some links to previous blogs I have posted about case management.

·         Case Management for Project Management 5-4-10

·         Case Management for Managers 3-2-10

·         Case Management Process Modeling Challenges 9-28-09

·         Knowledge-​Driven Processes for Healthcare 7-30-09

·         Case Management​: The Missing Link in BPM 7-8-09

·         Case Management for SOA 1-31-09

Value Chain Modeling, Part 5: The Organizational Perspective

This is a continuation of a series of posts on value chain modeling that started with “Value Chain Modeling: Part 1, Capability Analysis

A value chain represents the work that is done to deliver a product or service. Responsibility for the work and delivery of value belongs to various parts of the organization.  When considering the performance of the value chain, it is important to identify responsibility and accountability for performance and initiation of improvements.  Improvements as well as new business undertakings may also require organizational changes. 

In this article I will discuss a generic organizational modeling capability and its relationship to the value chain model. 

We define a basic, recursive pattern of organization structure that is a collaboration of participants working together, fulfilling roles for some joint purpose.  “Collaboration” and “Role” are fundamental, abstract concepts.  A collaboration may be a formal organizational unit, an ad hoc group such as a task force or committee, or an informal gathering such as a community of interest.  Traditional nodes in a corporate hierarchy are collaborations specialized as “org units.”  Roles may be filled by actors (e.g. people), other collaborations (e.g., org units) or other roles.  Actors do the actual work.  The diagram, below, illustrates relationships between some hypothetical collaborations and roles.

In the diagram, boxes are collaborations and ellipses are roles.  Each arrow represents a participation relationship.  There is one actor, Fred, depicted with a rounded box.  The XYZ Company is a collaboration with two subordinate collaborations shown: the Claims Processing Department and the Quality Policy Committee.  The Claims Processing Department is shown with one Claims Agent role and a subordinate collaboration—the Claim Resolution Team. 

Fred is an employee of the XYZ Company—he fills an Employee role in the company.  As an employee, Fred fills a Claims Agent role in the Claims Processing Department.  As a Claims agent, he is a Quality Reviewer of the Claim Resolution Team, and as a Quality Reviewer, he is a member of the Quality Policy Committee.  Thus roles are filled by other roles.  In other words, Fred would not be a member of the Quality Policy Committee if he were not an Employee, a Claims Agent, and a Quality Reviewer.

Within a collaboration, participants in roles may exchange ideas and work products to achieve their joint purpose.  In the value chain model, from an organizational perspective, a value chain as a collaboration of capabilities performing activities.  Work products flow between activities.  A capability, in turn, is a collaboration among employees who contribute to that capability, and a capability model may include roles of other supporting capabilities.  A business process can also be viewed as a collaboration among participants.  As collaborations, the value chains and capabilities each have roles in the org units that manage them.

From an organizational perspective, a value exchange, discussed in my previous blog post, is a collaboration among independent business entities.  The business entities fill party roles in the exchange collaboration.  Each of the business entities may be viewed as engaging a high-level activity in the exchange.  Deliverables conveying value(s) are exchanged between activities through transactions between party roles and their internal activities.   In an exchange, deliverables are typically exchanged in both directions, whereas, in a value chain, we focus on the transfer of deliverables as defining dependencies between activities.  The output of one activity enables another activity to proceed.

Although it is beyond the scope of the current modeling language specification effort, the value exchange pattern can be applied to any collaboration where participants work together to create or exchange value.  This is an important perspective for strategic planning because not everything that is important to the success of an enterprise can be understood or evaluated based on financial impact.  This can be used to consider value exchanges in  internal communities of interest that share knowledge, participation in industry standards organizations, informal relationships with suppliers and customers as well as informal relationships between individual employees.

Value Chain Modeling, Part 4: Value Exchange

This is a continuation of a series of articles on value chain modeling that started with “Value Chain Modeling: Part 1, Capability Analysis

In preceding articles we have focused on a value chain within a business entity.  In this part we will discuss the exchange of value between business entities and its relationship to the value chain.

I define an exchange as a set of related  interactions between two or more business entities that results in an exchange of value.  A fundamental exchange occurs between a seller and a buyer where the seller provides a product of value to the buyer, and the buyer provides money.  This is a viable exchange if both participants perceive an increase in value: the product is more valuable than the money to the buyer, and the money is more valuable than the product to the seller.

We extend this basic concept with the concept of a value proposition from the previous article.  The seller may provide additional value such as a warranty and return policy.  The buyer may provide additional value by allowing the seller to use the buyer as a reference in advertising.  So the model of an exchange represents an exchange of value propositions: the collections of value provided and received by each of the parties.

This concept can be extended to multiple parties as illustrated, below.

The diagram represents an Internet-based business model.  The Internet Publisher provides information content of interest to customers and includes advertising on the pages that deliver content.  The customer provides value to the Internet Publisher by viewing and clicking on the advertisements.  The merchant purchases advertising with payments based on customer clicks.  The customer purchases products from the merchant based on the advertising.

Each of these parties provides and receives value propositions from each of the other.  Not every exchange involves each party in sending and receiving value propositions with every other party, but the net value of value received must exceed the net value of value provided or the exchange is not viable.

In Part 3 we talked about a value proposition as the output of a value chain.  The value chain is the detail behind the delivery of a product or service by a party in an exchange.  At the same time, a party may receive value from a supplier party as input to a value chain.  From the value chain perspective, the transfer of value from the supplier is represented as a flow of deliverable(s) to one or more activities in the value chain.  In the value chain model, this is represented by a specialized flow element that is linked to a transfer of value in the associated exchange.  The supplier may be represented as a single, abstract activity that provides the deliverable(s) needed in the value chain.

The value obtained from the supplier becomes part of the value delivered to the end customer—the value proposition of the receiving value chain.  A supplier, conceptually, provides a value proposition to the purchaser.  This represents the offer of value. However, actual value comes from actual performance.  Consequently, the purchaser is more interested in the value metrics behind the satisfaction ratings.  These metrics, to the extent they are relevant to the value chain, are input to the value aggregations the same as contributions of other activities in the value chain.  Thus outsourcing to suppliers may hide the details of that segment of the value chain, but the value contribution is still part of the detailed value chain model through the value proposition.

From a broader perspective, an extended enterprise might be viewed as depicted in the diagram, below.  Here the operations of four business entities are each represented by a high-level activity.  The supplier provides parts to the manufacturer, the manufacture provides products to the dealer, and the dealer sells products to the customer.  Of course a real, extended enterprise would likely have more participants and branches in the network.  The small circles indicate that the flow is between business entities and could be represented in a more detailed exchange.

Modeling specifications for value chains and exchanges is a work in process.  In particular we need to reconcile these views with other approaches such as the Value Chain Group’s Value Reference Model,  Value Network Analysis, and e3Value.

Value Chain Modeling, Part 3: Value Propositions

This is a continuation of a series of articles on value chain modeling that started with “Value Chain Modeling: Part 1, Capability Analysis.”  These posts reflect current thinking in on-going work.

The primary focus of a value chain model is the delivery of value to a customer.  This identification of value is then the basis for managing and improving business operations to sustain or enhance customer value.  We have defined a value proposition as representing the collection of values offered to a customer.  We also expect to apply the same general concept to delivery of value to other stakeholders such as the business owners.

A model will link the values in a value proposition to the sources (or potential sources) of value from activities in the value chain.  Figure 1 illustrates the structure of the model linking the value proposition to contributing activities.  

Figure 1, Value Proposition Linkage to Contributing Activities

A value is something of interest to a customer that is provided to the customer as a result of a business transaction.  The value ratings expressed in the value proposition are the customer’s perception (or the enterprise estimate of the customer’s perception) of value.  This includes such things as competitive price, aesthetics, warranty, provider reputation and on-time delivery.

A value, such as on-time delivery, may be affected by multiple activities.  A value aggregation element captures the contributions of multiple activities (rows in the value element) expressed as a relevant metric, such as activity duration.  The value aggregation element computes a value chain result for the value measure.  In the case of on-time delivery, this is the sum of the durations of activities along a critical path representing time to deliver.  This metric is input to the value proposition for the associated value (a row in the value proposition element).

The value proposition applies a customer satisfaction formula for each value to each value measure.  This calculation produces a subjective customer satisfaction rating for the associated value with possible ratings of Excellent, Good, Fair, Poor or Unacceptable.  These ratings reflect the interests of the particular customer or market segment.  For on-time delivery, the rating would be based on the customer expectation for on-time delivery (a specific time to deliver) and an evaluation of the level of satisfaction achieved with the performance represented by the value chain model.

The value proposition then provides for computation of an overall satisfaction rating.  Each of the values is assigned a weight to support computation of a weighted average.

A value chain model may have multiple value propositions representing the values and ratings of different customers or market segments.  Value propositions are also represented in commercial exchanges, to be discussed in a later post.

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

This is a continuation of a series of articles on value chain modeling that started with “Value Chain Modeling: Part 1, Capability Analysis.”

Value chain models have been used to structure the development and refinement of business processes of an enterprise.  High-level activities are decomposed into more detailed activities.  These are then used to define more detailed, operational business processes.  This is helpful, but a value chain is not simply an abstraction of operational business processes. When I refer to business processes, I mean conventional, operational processes that might be modeled with BPMN (Business Process Model and Notation).

While sometimes a business process flow may align with a value chain flow, a business process defines controls that drive operations while a value chain defines the flow of deliverables between value-adding activities to deliver a product to a customer.  There are no loops in a value chain and no decisions for alternative actions.  A value chain depicts the incremental contribution of value toward the end product or service to be delivered.  A business process, on the other hand may define repetitive and alternative activities that optimize production and deal with exceptions.

For example, Figure 1, below, illustrates the relationship between a business process—the sequence of boxes, and a segment of a value chain—the sequence of circles (activities).  Note that these diagrams are for illustration only and do not represent a formal notation for the models. The value chain segment defines the acquisition of raw material, the production of parts, and the assembly of parts as activities leading to delivery to a customer.  The value chain metrics are based on the average work to produce a single product or service.  The business process supports the Produce Parts activity of the value chain and controls the production of batches of parts according to a production schedule.  The same production scheduling process may control a number of operations in support of different value chain activities.  The cost attributed to the value chain activity is the average cost per part with the setup cost pro-rated.

Figure 1, Alignment of process and value chain activities.

In the value chain segment, the trapezoid element (basket) depicts an inventory between the Produce Parts activity and the Assemble activity to hold the batch of parts until each part is needed.  This is important to the value chain analysis because there are time and cost factors involved.

In Part 1 of this series, I described how a capability may be implemented as a shared service in order to support activities in different value chains. In some cases, such a service may be invoked directly in support of a value chain activity.  However, the above example illustrates that a service may be engaged by a quite-different business process.  In this example, the service to produce a batch of parts is invoked to fulfill the production schedule.  The operations to produce parts are not driven by the completion of the Acquire Material activity as the value chain segment might suggest.

Another distinction between a value chain and a business process occurs where a business process engages a service that, in turn engages other services.  Figure 2 illustrates this in a somewhat unlikely but useful example.

Here the Process Order process invokes the Pick Parts service (depicted by the arrow between the boxes) to get parts from inventory, and then it engages the Ship Parts service that, in turn, engages the Package Parts service to prepare the parts for shipment.  The dashed lines indicate the correspondence of capability services to value chain activities.  This service-engagement control flow is quite different from the value chain deliverable flow from Process Order to Pick Parts to Package Parts to Ship Parts (the sequence of circles).

Figure 2, Service Engagement vs. Value Chain Flow

A best-practice, process design requirement for a capability is for the business processes to be bounded by the scope of the capability.  In the above example, the boxes represent services and the arrows between them represent invocation of services.  The process in the Fill Order service capability begins and ends within that capability.  It engages the Pick Parts service as another business sub-process that is bounded by the Pick Parts capability.  Similarly, business processes for Ship Parts and Package Parts are bounded by those capabilities.  This promotes the loose coupling of services so that a service can be engaged in different contexts, and the effects of changes to capabilities can more easily contained within each capability.  It enables local optimization and innovation.

In summary, a value chain model provides an abstract view of the operation of the business that is relatively independent of the details of how the business operations actually function and are controlled.  The value chain depicts WHAT the enterprise does to deliver value to the customer, but not HOW it does it.  The metrics of the value chain model provide a less complex and more customer-focused view of the business to help identify opportunities for improvement from an enterprise perspective.

Value Chain Modeling, Part 1: Capability Analysis

Preface

In a previous post, I asserted that the next generation CIO needs computer-based modeling tools to fulfill the CIO role, and I identified value chain modeling as particularly important. This is the first in a series of posts on the topic of value chain modeling.  Each post will focus on a particular aspect of value chain modeling. The concept of value chains was first introduced by Michael Porter in his 1985 book, Competitive Advantage: Creating and Sustaining Superior Performance. 

These posts, more specifically, are based on work done by Henk de Man of Cordys and myself (Fred Cummins) in response to the Object Management Group (OMG) Request for Proposals (RFP) for a Value Delivery Metamodel.  The resulting specification will define the import-export data structure and graphical notation of value chain models to support the exchange of models between different software product implementations.  The standard does not define how the models are implemented in the software, nor the functionality that a particular implementation may provide.  It does define semantics and relationships of the modeling elements, and it may define a graphical notation for consistent understanding of users. 

Part 1: Capability Analysis

In this model, the value chain (sometimes described as a “value network”) represents activities and dependencies between them much like a PERT network.  The dependencies are generally the flow of deliverables from source activities to dependent activities.  The activities of interest are those that are directly involved in producing the end result--the product or service to be delivered.

The activities are broken down to represent relatively generic capability requirements.  The capability that supports each activity is distinct from the activity just as the activities in a PERT model are distinct from the resources that perform the activities.

Each line of business in an enterprise can be represented by a distinct value chain.  Due to the level of detail, the activities and dependencies may be quite different from one line of business to another.  However, some capabilities may be very similar.

As a result of capturing the characteristics of each capability, it will be possible to recognize where similar capabilities are used to perform multiple activities in either the same or different lines of business.  This provides the basis for specification of shared services.  Similar capabilities can be consolidated and can be given well-defined interfaces to be engaged by multiple activities.  The result can be economies of scale across multiple lines of business.

However, this also creates management challenges.  After consolidations, the enterprise will have a number of shared services that are not strictly aligned to any particular line of business and thus their performance cannot be measured in the context of any particular line of business.  The value chain models, together, provide the context for evaluation of each service from an enterprise perspective.

 The shared services should not be managed by a line-of-business organization or there will be an incentive to optimize the capability for that line-of-business rather than optimizing from an enterprise perspective.  As a result, the sharing of services should drive the enterprise toward a matrix organization: lines of business in one dimension and functional/capability organizations in the other.

Well-defined service interfaces hide the implementation of the services from the users of the services.  Services should be loosely coupled so that they can easily serve requests from different lines of business.  This loose-coupling and implementation-hiding empower the manager of a capability to innovate and improve services without involving other organizations as long as the interface and the service result are not changed.

These generic capability services can then be engaged to deliver new products or services.  A new business opportunity can be modeled as a new value chain.  The model identifies the capabilities that are needed to perform the value chain activities.  Capabilities that exist in the enterprise can provide reasonably accurate estimates of cost and performance in support of the new line of business.  Capabilities that do not exist represent gaps that must be filled to deliver the new product or service.  The costs of creating the new capabilities along with costs required to upgrade existing capabilities represent the cost of entry to the new business.

The identification of shared capability services also provides the opportunity to consider outsourcing of commodity capabilities.  We’ll consider outsourcing in more detail in a later part of this series.

Modeling is Key for the Next Generation CIO

In June, 2009, I posted an article on the HP The Next Big Thing blog entitled “The Next Generation CIO.”  The transition is under way.  In an interview entitled “The Evolving CIO Role: What One Headhunter Says CIOs Need to Know,” Shawn Banerji, managing director of an executive search firm says the CIO role “really is for a business leader, someone with very strong commercial skills and vision who also is a superlative business operator.”  This business leader has enterprise-wide responsibility for optimization and agility of the design and operation of the business systems.  This responsibility cannot be fulfilled without a computer-based modeling capability.

The traditional role of information systems management was application of information technology for automation and integration of human tasks.  This was a bottom-up transformation of the business to exploit information technology, and the business benefits and system requirements were within the scope of the affected business function managers.

This evolution of systems essentially transformed the technology of the business systems, but the basic structure of the business became embedded in computer programs.  As the scope of automation and integration increased, the systems became more complex with interdependencies that crossed organizational boundaries.  At the same time, the pace of change in products and services continued to increase.  Businesses now face global competition, and customers expect access to information and services 24 hours a day, every day of the year.  Not only must the business systems adapt to improve operations, but they must continually adapt to changing business challenges and opportunities.

The enterprise as a whole must be managed as a system that integrates with systems of suppliers and customers.  At the same time the enterprise system must be structured so that it can adapt to change without major overhaul.  This cannot be managed through the traditional budgeting and delegation approach to management of system changes. That narrow perspective results in sub-optimization of both the technology and business operations.  Effective management requires an enterprise optimization perspective on both the business systems and the supporting information technology infrastructure..

In my book, Building the Agile Enterprise with SOA, BPM and MBM, I describe the design of business systems from a business perspective.  Technology is a necessary part, but the focus is on designing the operation of the business to leverage technology.  Modeling is essential to managing the scope and complexity of the business systems of an enterprise.  The CIO should provide the executive leadership to develop and manage the models, support analysis for optimal systems design and investment, and optimize the application and management of technology.

The Object Management Group, an international standards organization, is developing specifications for computer-based, business modeling tools.  A key segment of this effort is development of a "value delivery modeling" capability that builds on value chain modeling that was introduced by Michael Porter in his 1985 book, Competitive Advantage: Creating and Sustaining Superior Performance.  This technology will enable the CIO to provide a model of the capabilities of the enterprise and how they contribute to the development of customer value in the enterprise products or services. It also helps identify and manage shared capabilities for agility and economies of scale. The basic concepts of this modeling approach and related business models and design concepts are discussed in my book.

In subsequent posts, I will discuss value delivery modeling and the development of business modeling standards in more detail.