Optimizing Processes in BTM

Before the recent period of "technology for technology's sake," there was an equally irrational time when corporations tackled "process for process's sake." This phase, known as the business process reengineering (BPR) era, called for the radical reinvention of all processes across the enterprise. BPR promised quantum gains in operational efficiency and competitive advantage. However, it often wreaked havoc on organizations, leaving them to wonder what value they received in return for the millions they spent. It's no wonder that now, when you even utter the phrase "process model" some executives and managers go weak in the knees envisioning a return to the "bad old days." So, I want to be clear that when I use the term "process optimization," I do not mean revisiting BPR.

What I do mean by process optimization is the analysis and design of processes to provide a link between the business objectives and the supporting technology for a given IT project. The wholesale revamp of the process environment is not required. Instead, process optimization focuses on improving the specific processes that support each proposed business scenario model. Working from the current process model ”which depicts the existing process environment ”process analysts and domain experts collaborate to generate to-be models that satisfy the aims of the business scenario models. Next, they perform a gap analysis between the current process model and each to-be model to determine which processes need to be eliminated, streamlined, automated, or out-sourced, and to anticipate the potential impact of these changes on supporting applications and systems.

Drilling down from this high-level view of process optimization, there are four key steps within process optimization: translate business model requirements, assess the value of existing processes, analyze process gaps, and develop functional requirements.

Translate Business Model Requirements

Since the process model acts as a lynchpin between the business and technology models, it is important to first understand the relationship it has with the business model. Each process model takes its cue from to-be business scenario models that describe the objectives of the project, elements of the business that it impacts, and scenarios the organization might pursue . This inherited information is then cross-linked to processes, sub-processes, and activities that can operationalize the business model alternatives. Cross-linking between models enables the process analysts, domain experts, and IT specialists to analyze the repercussions that each business scenario model has on operations, resources, assets, information, and supporting technology.

The benefits of linking particular elements of the business model to those of the process model are twofold. First, by translating what are essentially business model requirements into process terms, it is possible to limit process improvements to those that are practical and achievable. Assumptions made in the business model scenarios (which may be based on superficial process knowledge) need to be validated against the intricate realities captured by the process model. Certain business model requirements may not be feasible given constraints within the existing process environment; nor may they be feasible (or even advisable) after changes are enacted in order to fulfill them. For example, a company may wish to assess the viability of their business objective to lower helpdesk support costs by bringing an out-sourced call center function in-house. By evaluating this business objective against current and alternative process environments, they may discover that it is more cost effective ”when considered against the staffing, facilities, training, and systems costs required to support the function internally ”to simply renegotiate the current contract and extend helpdesk service to business units not already covered under its terms. This approach to process optimization is iterative; lessons learned in the process optimization phase can be passed backward to business model definition, allowing requirements to be redefined or initiatives terminated if necessary.

The second benefit of linking business model requirements to elements in the process model is traceability. The rationale for certain process optimization changes can be explicitly traced back to the original business requirement driving the change. The resulting audit trail helps teams to communicate to project stakeholders how the organization plans to realize its objectives. Also, it can help the team to educate stakeholders regarding what it will require in order to accomplish specific goals.

Assess the Value of Existing Processes

Assessing the value of existing processes and internal/external participant relationships fulfills a vital step in process optimization. This assessment, which requires analyzing the current process model in the context of business goals, reveals inefficiencies and redundancies; critical interactions and interdependencies between activities; and opportunities for innovation. Because the current process model provides an accurate and realistic view of how work is carried out in practice ”including typically undocumented workarounds that equate to hidden tasks or decisions ”it can help to uncover bottlenecks, unproductive and counterproductive steps, time delays, hand-offs, and costs. Some activities may be redundant and therefore represent waste that can be excised from the process environment. Others that cross several departmental boundaries may have no identifiable owner and therefore, slip through the cracks. Still others may have outlived the original business rationale that justifies their usefulness . This step is essential for gaining insight into which processes should be eliminated, streamlined, automated, or out-sourced. It also provides the basis for developing to-be process scenario models that describe potential alternatives for operationalizing proposed business model scenarios.

Spending Time on the Future Saves Money

"It's one thing to have a visioning session to discuss 'what we really want to be to our customers,' but it's a whole other thing to say how we actually should bring this off. The future-state touch map is the first step in that sort of actualization of the vision. When you're designing a future state, you're designing it from a vision, and the vision is inherently holistic, because you are looking at your business from the customer's perspective. Once we begin designing processes around that future state, and when we outline the customer interactions around it, we will get a comprehensive, integrated view of our real business.

There are some companies that are extremely self-reflective, constantly examining themselves and paying particular attention to process. For them the kind of visioning that we're talking about ”setting up the future state touchmap ”is a piece of cake; it might be a perspective they haven't thought of very seriously before, but nevertheless, it's something that's not hard to do. For other companies it can be like picking hens' teeth to generate a touchmap of any kind, because they just don't pay a lot of attention to process. They may be too busy simply making sure that their head remains above the day-to-day financial tidewaters. Done right, however, a future-state touchmap will streamline your interactions, cut out waste, eliminate duplication, and give you a more rational feel for your business, not only cutting out costs but pointing out additional revenue opportunities."

” Don Peppers, best-selling author of the One to One book series, and a founding partner at the management consulting firm Peppers and Rogers Group.

Analyze Process Gaps

Comparing current process models against process scenario models allows process analysts and domain experts to analyze differences and identify gaps between their existing and desired environments. This analysis is important for understanding the true impact that proposed changes will have on process design, work and information flows, employees that perform the operational tasks, external relationships such as customers and suppliers, and the underlying technology that must be in place to support it all. For example, process analysts and domain experts often need to ascertain which is more beneficial: reengineering a process to match the functional capabilities provided by a particular application package or customizing the package to fit the requirements of the process. In order to make this type of decision they need to be able to consider a wide range of possible implications (see Table 6.1).

Table 6.1. Modifying processes can impact the enterprise in a number of areas

What, at first glance, may appear to be a simple either/or decision (reengineer or customize), actually involves making a series of sub-decisions. For instance: If we reengineer Process A what impact will that have on Sub-processes X, Y, and Z? Do we need to require that our suppliers change their processes too? What level of information access is required and does that mean we need to change our security protocol? What is the amount of internal technical support that will be required if we make changes to the vendor's application package? Is this same package already being used by other business units for the same process? By analyzing gaps and determining impacts in this way, process analysts and domain experts can make informed decisions regarding the benefits, risks, requirements, and trade-offs involved in implementing changes. They can also use this same information to solicit buy-in on proposed process scenario models from the project's business and technology stakeholders.

Develop Functional Requirements

During gap analysis, process analysts and domain experts may make the decision to automate specific activities with technology or to enhance how previously deployed business applications function. If this is the case, then the subsequent and final step of process optimization is to develop functional requirements for those activities. Functional requirements describe in non-technical terms the steps and possible rules involved in executing the activity. Take a typical insurance industry sub-process, Review and Approve Claims, for example. The functional requirements for automating select activities of this sub-process may look something like this:

- Determine claim type by profile

- Determine payment type by profile

- View claims status

- View claims payment record

- Route approved claims for disbursement

- Single sign-on to claims environment

Describing functional requirements in this way helps process analysts to communicate how work is performed from the perspective of the end- user . The benefit of this is twofold: first, it helps process analysts to carefully think through how processes are performed, which can prevent them from overlooking critical steps; second, it helps IT professionals understand the needs of the user community from more than a bits or bytes viewpoint when trying to build or deploy supporting technologies. The hand-off between these two domains, which is otherwise difficult, must be as seamless as possible in order to avoid miscommunication or misinterpretation of requirements.

After they are developed and prioritized, functional requirements are cross-linked with application and system requirements defined later in the technology model. Creating linkages between the two types of requirements ensures alignment between process and technology domains. It also provides traceability for process analysts and IT teams to verify that all functional requirements are satisfied.