A Systems Approach to Business Process Management

The Challenge

I have come across businesses where some problems are chronic. In other words, these problems have existed for a long time but nobody attempts to fix them because they are thought to be “unfixable.” I have also come across businesses where problems are approached with a quick-fix mentality. In many cases, the same business may have a class of chronic problems as well as quick fix problems.  Those that are perceived to be difficult take a long time to fix or are never fixed, while those that are perceived to be quick fixes are fixed immediately, but with no context. Both approaches may lead to worsening conditions.

At one company for example, it has been recognized that the different business units each responsible for a different product line was maintaining a copy of the customer information. This redundant but often inconsistent customer information manifested itself to the customer as bad customer experience. The problem was perceived to be big and therefore never fixed.

At the same company, adding additional information to the customer records was considered an “easy fix,” though it had to be repeated for each business unit that maintained the same customer information. The repeats were not trivial since the schema that held the customer information was different for each database.

Just like humans tend to do, companies too simply seem to get a false sense of accomplishment if they do something about a problem rather than not. In this need to do something, companies often focus on the urgent at the expense of the important. However, it would be more prudent for companies to take a systematic approach so that high priority challenges are not pushed to the back burner even when they are perceived as difficult.

The Approach

The systems analysis and design approach to problem solving as a discipline has been around for a long time and we have appreciated and learned a lot from it. Business Process Management (BPM) challenges and Service Oriented Architectures (SOA) too can be tackled using a systems approach. While there is a general sense that BPM and SOA are indeed tackled this way, my own consulting experience has shown otherwise.  For example, in an attempt to get something “out the door,” BPM challenges have been solved in an ad-hoc manner. Similarly sometimes services are built with the expectations that somebody will use them, but nobody does.

In this article I suggest that the business take a systems approach to the challenges. If indeed there are different efforts in the Business Architecture (BA) space, the BPM space, SOA space, Business Rules Management (BRM) space, IT Architecture space, etc., they have to be all brought in alignment and considered holistically, because these efforts should at some point interact and reinforce each other.

It’s imperative for both business and IT to understand these disciplines and determine where their own efforts fit into the overall value-add to the business, as it is critical for the organization to recognize the much larger business value offered by the integration of these disciplines.

The Transformation Framework

Instead of conceptually relating the different disciplines in the form of a venn-diagram as is often done, we attempt to show their interrelationships in a business-to-IT continuum context. We will briefly walk through the different parts of this picture.

As we move from the top to bottom, we go from the business domain to the IT domain.  At the top, the business units may use BA to capture the “blueprint” of their business. BA is like a repository that feeds information to the business process modeling. The important business processes that are cross-organizational, span the enterprise and can be managed through the discipline of BPM. Each task in the process may be a user-centric task, or a system-centric task, which means that primarily a person or a system performs them. External providers may also enable some of these tasks.

A BPM system helps to orchestrate the sequence of tasks that form the basis of the business process. The tasks themselves may be accomplished by “services” that could be provided by a person, IT, or an external or internal entity such as a business unit. An application that’s running within the IT department may provide one such service over the web, in which case it’s called a web-service.

A systems approach to development includes the following major phases: (a) analysis that includes modeling, (b) design that includes architecture, interfaces, and database design, (c) construction or implementation, and (d) operations and management. One can take a similar approach to process optimization and management or even organizational transformation. At a high level, the steps would be the following:

1. Analysis
   1. Analyze and model the current processes
   2. Analyze and model the desired processes
   3. Develop the business architecture that includes the organizational data, roles, etc.
   4. Capture the requirements including service level agreements (SLA)
2. Design
   1. Design of new state including data, user interfaces, and rules
   2. Design the IT architecture that includes how the components are connected with one another
   3. Map the requirements to services – both at a business and IT level – and defining the service interfaces
3. Implementation
   1. Perhaps utilize a BPM system for process orchestration
   2. Implement user interfaces and other interfaces required to interact with the process
   3. Implement the mechanism to capture metrics that are of interest
   4. Implement the data access and management layer
4. Operations and Management
   1. Deploy for production
   2. Capture and analyze metrics that indicate business performance
   3. Determine enhancements that may be required for the next iteration

While these are high-level steps, the point is that one can approach BPM implementation in a systematic manner. As the organization gains maturity in the implementation, it’s own process for such implementation attains higher and higher levels of maturity which means that it will have a robust process in place to implement organizational transformation that continuously enable it to adapt to changing business environments. A few capability maturity models (CMM) have been defined in this space, but a systems approach provides an excellent path to achieving the desired level of maturity.

Conclusions

I recommend a systems approach to organizational transformation – which includes Business Architecture, Business Process Management and Service Oriented Architecture. As the enterprise gains more and more experience in this deterministic approach to transformation, it will be in an enviable position to quickly adapt to changing market conditions and thereby put itself at a competitive advantage.