The Next Big Thing
Posts about next generation technologies and their effect on business.

Business Process Emancipation

Repost - Originally posted 6/11/10
Labels: BPM| ERP| SOA

Case Management for Managers

I listened to a podcast by Setrag Khoshafian of Pegasystems in which he talked about "Smart Case Management and CRM."  It struck me that case management has potential to improve continuity of service, efficiency and reliability in a number of contexts that may not be considered case management.

I like the following definition of case management presented by Singularity in a white paper entitled "Case Management: Combining Knowledge with Process: "

 "Case management is the management of long-lived collaborative processes that require co-ordination of knowledge, content, correspondence and resources to achieve a goal or objective. The path of execution cannot be pre-defined. Human judgment is required in determining how to proceed and the state of a case can be affected by external events."

 The goal of case management technology is to provide computer support for managing these ad hoc processes.  Henk de Man of Cordys provides an extensive review of past approaches to case management modeling in his BP Trends article Case Management: A Review of Modeling Approaches

In Setrag's discussion of smart case management, he describes using case management to manage a customer support interaction through participation of various organizations that otherwise might each provide their contribution within the scope of their own silo.  Case management can provide a unified view of the customer, the problem to be solved and the cumulative knowledge about that problem without each silo starting their analysis from scratch.  This also provides some opportunity to personalize the customer relationship as the solution is developed.  However, I see a greater opportunity that, I think, goes beyond Setrag's solution.

I see the opportunity for case management to provide continuity and personalization of service for the on-going customer relationship-an on-going case.  This is more like a primary physician's patient care that retains a patient history and incorporates knowledge of, not only the patient's current malady, but a complete file of the patient's problems, treatments and responses potentially over years.

This opens up many more possible applications of case management.  Look again at the Singularity definition.  Isn't this what managers do?  The difference is that unlike the common perception of business processes, management processes go on and on.  A manager has a collection of documents pertaining to his or her responsibility and the state of the organization, as well as a history of problems solved and initiatives completed-a manager's case file.  He or she manages various problems and initiatives to fulfill that responsibility, engaging the participation of others. The focus of the manager's case is the functional capability of the organization.  The manager collaborates with others, applies business knowledge and experience, and performs ad hoc planning and decision-making in pursuit of his or her business goals.  At the same time, the manager engages other employees and services, applies business policies and regulations, and must respond to various events both external events and those that arise in the operation of the organization.

Couldn't we approach any business responsibility in a similar manner?  It seems that this characterizes the job of a quality assurance manager, an information security manager, a vendor relationship manager, a strategic planning facilitator, the chair of a task force and many other on-going business responsibilities involving cross-enterprise collaboration.

The Object Management Group (OMG) has issued a Request for Proposals (RFP) for a Case Management Process Modeling specification.  Work on this specification is in the early stages.  I don't know if we can address this case-management-for-managers capability, but I think it's worth considering.

BPM is the Beginning of the End of ERP

In a recent article, Jack Vaughan quoted Jan Baan as saying, "The successor of ERP is BPM....ERP is becoming the model of complexity.  It has become too complicated."  Baan is CEO of Cordys and former head of Baan Corporation, an ERP vendor.  BPM (Business Process Management) is the leading edge of a major change in enterprise systems.

Much has changed since the heyday of ERP.  The Internet and internet technology has changed communications and integration.  Businesses are on-line and accessible from anywhere, any time.  The marketplace has become global for all enterprises, not just large companies.  The pace of change has accelerated, and information technology is pervasive in the operation of the enterprise and in society in general.  Business services are accessible, ad hoc, over the Internet, and service oriented architecture is changing not only the design of computer systems, but the design of enterprises.

ERP systems are traditionally monolithic solutions for automation of business operations.  They provide a solution for a particular way of doing business and typically require a major investment in implementation and adaptation to align the solution and the business operation.

The future requires enterprises, as well as systems, designed for change.   BPM, supported by business process management systems (BPMS) enables flexible automation of business processes.  ERP systems traditionally embed business processes in the code so that changes to business processes become IT projects.  A BPMS provides the opportunity to model and automate business processes in a way that is visible and adaptable by business people.  The BPMN 2.0 standard from OMG (Object Management Group) defines BPMS notation and modeling elements for defining and automating repeatable business processes. 

Not all business processes can be pre-defined and repeatable.  Some processes require ad hoc planning and decision-making by humans where actions are driven by the state of a case and records related to the case.  We characterize such processes as case management processes.  Some ERP systems provide record-keeping for case management.  Many other case management processes remain paper-based and manual because they don't fit the definable, repeatable model supported by most BPMSs.  OMG has initiated development of a Case Management Process Modeling (CMPM) standard for design and automation support for these processes, thus moving beyond the automation capabilities of ERP systems.

BPM, including case management, will improve the effectiveness and agility of business processes, but it does not necessarily improve the agility and overall efficiency of the enterprise.  Enterprise agility and efficiency involves changes to the design of the enterprise.  It requires the ability to rapidly adapt or create business capabilities and the ability to engage existing capabilities in new ways.  ERP systems are a barrier to such changes.  This agility is enabled by exposing business capabilities as sharable services.

In Business Capability Mapping: Staying Ahead of the Joneses, Denise Cook describes how business capabilities, at an appropriate level of granularity, represent stable components of the enterprise.  As services, these capabilities can be engaged by different business processes to meet the needs of different lines of business and adapt to changing business strategies.  These services must be loosely coupled so that they are independent of the individual lines of business to which they contribute or may contribute to in the future.  In Why SOA is a Business Necessity, I describe the importance of this service oriented architecture (SOA).

The identification and management of business capabilities as services requires a specialized discipline beyond conventional BPM.  This need is addressed by value chain modeling.  Value chain modeling was introduced by Michael Porter in 1985.  For more on value chain modeling and its various incarnations, see Value Chains and Other Processes, by Paul Harmon.  Value chain modeling brings a focus on the delivery of customer value and the capabilities that are required.  This analysis has been used at the executive level in strategic planning, but it typically lacks the detail to identify the stable units of capability that should be engaged as services.  This more detailed analysis as well as the design and management of shared services require a modeling environment to manage the complexity. 

This need will be addressed by a specification for value chain modeling being developed at OMG in response to the Value Delivery Metamodel RFP.  A value chain model will define the network of activities that contribute to the delivery of customer value.  These activities represent uses of business capabilities.  Different lines of business may have different value chains that define the uses, or potential uses, of shared capabilities. In addition to consolidation of capabilities for economies of scale and agility, this perspective supports consideration of investments in improvement as well as outsourcing and configuration of joint ventures.  Optimization will shift to an enterprise perspective, to reflect the cross-enterprise impact of shared capabilities that serve the needs of multiple lines of business.

This architecture is quite different from conventional ERP systems.  The business processes will no longer be embedded in program code.  The functionality that supports the stable business capabilities may be much the same, but it will be carved out to support loosely coupled services.  BPM is the beginning of the end for ERP systems as we know them.

We are in a state of transition to a new business paradigm.  The full transformation of enterprise systems and the enterprise will involve BPM, loose coupling of business capabilities and additional modeling capabilities that together will provide an enterprise architecture model from a business perspective.  Cordys and Hewlett-Packard are at the forefront of defining the business modeling specifications discussed above and the development of future enterprise architecture modeling capabilities. 

Case Management Process Modeling Challenges

The Object Management Group (OMG) has issued a Request for Proposals (RFP) for a Case Management Process Modeling specification.  This RFP will require the integration of process models, data models and rules to provide guidance and record the history of processes that adapt as a result of particular circumstances, events and human judgment.

This is the result of efforts I discussed in July under Knowledge-Driven Processes for Healthcare. The RFP refers to these adaptive processes as case management rather than knowledge-driven because case management is a more widely recognized characterization and focuses on the business objective.

Case management processes may be initiated by conventional, prescribed business processes as specified in BPMN (Business Process Modeling and Notation) and they may engage prescribed business processes to perform desired actions.  In addition, a case management process model may be refined over time to become more prescribed.  Consequently, a case management process model should integrate with BPMN process models, and it should be represented with notation and operational semantics that are consistent with BPMN so that processes can evolve from ad hoc to prescribed as practices become more refined and predictable.

The focus of a case management process is a case.  A case is a situation to be managed.  It may be related to a person to be helped, a problem to be resolved, a repair to be performed, a solution to be defined, a lawsuit to be resolved, a claim to be settled or a variety of similar situations.  In a case management process, the case is represented by a case file containing records that contain data on the history of the case and the current situation.

The case file will be updated by the case management process to record the current situation, new information, decisions and actions performed.  However, many case file records are obtained from other sources.  Consequently, the content and format of these records will be defined outside the case management process model.  From an OMG modeling perspective, these records should be defined in an IMM model (Information Management Metamodel). IMM provides logical data modeling and transformations to different data formats such as object-oriented, hierarchical, relational and XML.  It is currently under development. At the same time, case management guidance and constraints will depend on the content of these records, so the fields must be accessible by rules.

The application of rules to define process guidance and constraints is a primary contribution of the case management process modeling specification.  The case management process will be refined over time by the addition of rules that make the process more predictable and reliable.  Rules will provide guidance by suggesting actions that may be appropriate under current circumstances.  Rules will define events of interest—changes of state reflected in the case file, that may result in alerts or initiation of immediate action.  Rules will define constraints on actions that could be detrimental such as administration of a medication to an allergic patient.  Rules may also define process constraints reflecting policies or regulations.

Rules must be written with reference to the case file data and the related actions.  There are several OMG specifications for modeling rules, and it would be undesirable to define yet another rule language for case management.  Semantics of Business Vocabulary and Rules (SBVR) models the semantics of business vocabulary and provides expression of rules in a natural-language-like form using a defined vocabulary.  Object Constraint Language (OCL) is the constraint language of the Unified Modeling Language (UML).  Production Rule Representation (PRR) defines rules for rules engines.  Business Process Modeling and Notation (BPMN 2.0) also includes some rule modeling.  The RFP requires the reuse of existing rule specifications.  It will be up to submitters to determine which is most suitable.

As OMG develops a more complete set of modeling specifications, the compatibility and integration of models has become an increasingly important challenge.  The Case Management Process Modeling specification is a good example.  Efforts are under way in OMG to define a general approach and supporting technology.

An Interesting Convergence of Models

A proposal for organization structure modeling provides a basis for convergence of BPM, SOA, value chains and organizational models.

In my blog Renewed Discussion of an OMG Organization Modeling Specification, I described a simplified organization structure meta model based on organizations as relationships between roles.  The roles in an organizational relationship may be occupied by people or other organizations.  So a department can be represented as an organizational relationship between a manager (role) and roles of groups that are each organizational relationships between roles of people. 

This concept goes much further to represent a variety of types of organizational relationships with the same basic construct.  So a committee is an organizational relationship between committee members, a community of persons with a shared interest can be viewed as an organizational relationship between the participants where some may have coordinating roles, and a purchasing relationship may be represented as an organizational relationship between a buyer (role) and a seller (role).  The relationships may range from very stable to very transitory.  Based on the information needed and the ability to remain current with changing business relationships, the modeler must decide how dynamic and detailed the organization model should be.

In SOA Is a Business Process Architecture, I described the relationship between a service unit (an organization that manages a service capability) and business processes that implement services and may engage other services.  In the service unit model, the service unit is an organizational relationship between the people that manage the capability, and may include constituent organizational relationships (an organizational hierarchy) that each manage particular aspects of the capability.  Then a service unit has relationships with consumers of its services and may have relationships as a consumer of other services.  In these relationships the service units have roles in the consumer-provider relationships.  These consumer-provider relationships are supported by choreographies in a BPMN 2.0 model and interactions in a SoaML model.  A model might be restricted to representing internal relationships, or include relationships with external services.

OMG recently issued an RFP for a Value Delivery Metamodel.  I discussed the relationship of value chains to services in Value Chain Modeling Is Essential to SOA Management.  The nodes of the value chain are capabilities that contribute value to a customer product or service.  In a SOA, the nodes are the responsibility service units.  The arcs represent the transfer of value from a producer to a consumer of a work product, and thus each determines a dependency of a service unit on the delivery of value from one or more other service units.  These dependencies are establish organizational relationships where the producer and consumer have roles in the relationship.

As a result, an organizational model can represent an organizational view of these diverse relationships.  A organization modeling tool could provide a filtering capability to expose or hide certain types of relationships in order to provide views for understanding different aspects of the organization.

Showing results for 
Search instead for 
Do you mean 
Follow Us
About the Author(s)
  • Steve Simske is an HP Fellow and Director in the Printing and Content Delivery Lab in Hewlett-Packard Labs, and is the Director and Chief Technologist for the HP Labs Security Printing and Imaging program.
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.