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

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. 

Is Business-IT Alignment Suicide for the CIO?

Last week, Bob Evans published an article entitled, "Suicide Strategy For CIOs: Aligning IT With The Business."  In it he asserts that the CIO must abandon efforts to align IT to the business and instead align with customers.  This does not make business sense.  Information technology enables business capabilities to deliver value to the customer, but the CIO should support the business by ensuring that the business capabilities make effective use of information technology.  The enterprise and its business activities are the customers of the CIO.

The role of the CIO should be to optimize the enterprise information systems and their use of information technology to enable the enterprise to achieve competitive advantage in each of its lines-of-business.  That does not mean the CIO is a technology geek, but rather that the CIO must know about the design of the business to determine how technology can empower the business.

Alignment of IT to the business should be put in the context of delivering value to the enterprise customers.  Value chain analysis as introduced by Michael Porter in his 1985 book, Competitive Advantage: Creating and Sustaining Superior Performance, promotes  business alignment with the customer value.  A value chain identifies those capabilities that contribute directly to the value of a line-of-business product or service delivered to the customer.  The IT organization represents a supporting capability that is necessary for the effective performance of the enterprise value chains.

The CIO should focus not on the implementation of computer and communication systems, but on management of the technical capability, much of which may be outsourced.  This capability includes not only the development of applications and operation of computers and networks, but it includes support for the design of the enterprise.

The enterprise itself in a complex information system.  SOA is a design paradigm for enterprise optimization.  In SOA:A Matrix Architecture I described how SOA leads to a matrix organization where value chains are managed by line-of-business managers, and services are managed by shared capability managers.  The CIO provides the cross-enterprise perspective to develop value chain models, design shared services and provide the applications that support the implementation and integration of the capabilities.  Where shared capabilities are provided as services, Value Chain Modeling Is Essential for SOA Management. The value chain models, as well as other information services managed by the CIO, support management planning, decision-making and governance. By focusing on value chains, the CIO should help determine priorities for investment in technology and business systems design that will improve customer value.  This is alignment of IT with the business.

In The Next Generation CIO I describe this key business role of the CIO.  The CIO is responsible for a critical aspect of the business, just as the CFO is responsible for the financial aspect and the HR executive is responsible for the personnel aspect.  There is no discussion about how the CFO and HR executive align to customer values.  Their jobs are to serve the shared financial and personnel needs of the enterprise.  

The CIO should focus on optimizing the enterprise as an information system through managing the information technology capability.  That includes modeling, designing and transforming the business systems. In that context, the CIO will play in indispensable role in the future of the enterprise, and alignment of IT to the business is a measure of CIO success.

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.