Why Process Optimization?

Process optimization provides a mechanism to achieve the following challenges and benefits:

- Integrate processes across the whitespace that can occur between functions, departments, business units, or companies

- Achieve business-driven, rather than function- or component-driven process improvement and change

- Create a common requirements vision to mirror shared services across multiple organizational units and achieve continuous improvement

- Improve visibility into vendor functionality to understand degree of fit and reduce integration complexities

- Provide a basis for simulation or activity-based costing (ABC) process performance improvements

Integrate Processes across Whitespaces

Whitespace, as defined in Ch. 3, is the gap that can occur between strategy and operations, between organizational units, and between perceived or actual behaviors. Whitespace problems can lead to poor operational or financial performance, because responsibilities for tasks fall through the organizational cracks (the old line, "But I thought you took care it!") or because they hide weak or deficient processes. Process optimization helps to identify and eliminate whitespaces.

First, defining and assessing the value of existing processes erases corporate assumptions about how work is performed throughout the organization. Everyone may think that they agree on how processes work in their organization, but few actually possess accurate, detailed process knowledge. Once companies capture the realities of their operational environment with models, they can use them as a basis to detect unknown process breaks and weaknesses. Second, the swim lanes that are overlaid on current process and process scenario models enable process analysts and domain experts to visualize how processes cross back and forth across organizational boundaries. By constructing models in this way, it is possible to highlight who does what activities and when during a process. This is especially critical when processes extend to external parties such as customers and suppliers, increasing the likelihood that the execution or management of particular tasks may be obscured. Third, archived models that serve as templates for future process optimization efforts essentially create an institutional memory that can be recalled to fill in gaps left by employees or contractors who have left the company.

Achieve Business-Driven Process Change

Some companies still use and favor two process modeling techniques designed in the 1980s ”the Zachman Framework ^[2] and the Spewak EAP Model ^[3] . Given the mercurial nature of today's business and technology environments, there are drawbacks to relying on either. First, they focus on optimizing domain architectures. As a result they are more function- and component-driven than they are business-driven; and they require that a company invest significant time, money, and resources in an exhaustive analysis of enterprise architecture. Traditionally, business stakeholders have had a difficult time justifying the expense of such efforts because of an unclear or lagging return. In contrast, process optimization focuses already scarce resources on analyzing processes and creating improvements that can satisfy immediate or near- term business needs. Business value (not technological prowess) is the aim, and faster proof of concepts can be produced to sell change ideas to management.

Second, both methods were developed during a time in the 1980s when the business environment and enterprise architectures evolved at a slower pace. In complex enterprise scenarios, completing such an endeavor can take up to two years . Nowadays, the rate of business and technological change is blistering, requiring companies to modify their process environments on the average of every six to twelve months. Companies, and therefore project teams, must respond quickly to accommodate unforeseen changes as they ripple throughout the enterprise architecture. Ch. 1 provides evidence of how changes in the business climate can affect the success of a project. Process optimization, which involves the linking of process models to business and technology models, provides teams with the ability to adapt in step as the initiative's business or technology requirements change.

For each of these reasons, the Zachman and Spewak methods are complements to process optimization ”they are more practical as stand-alone improvement initiatives or as long-range planning exercises that can supplement the day-to-day design of IT projects.

Create a Common Requirements Vision

The increased sharing of IT services across business units and the need to continually find ways to improve the operational environment has led some companies to create a common requirements vision across multiple process activities. Through modeling activities, process optimization facilitates the discovery and pooling of shared requirements. With this aggregated understanding of functional requirements, companies can streamline activities, avoid redundancies, encourage adoption of process standards, manage change efficiently , and uncover customer service or time-to-market improvements. For example, process analysts may discover that they can increase the efficiency of billing activities and offer customers a single point of contact for invoice inquiries by processing all requests through one system. In another scenario, visibility into previously defined common requirements may lead IT analysts to reuse components , rules, interfaces, and data related to an existing order processing application instead of purchasing a new application. From a change management perspective, process optimization can also help to reveal the magnitude of impact that changes in the technology architecture ”such as redesign, replacement, or upgrade ”can have on an interdependent processes environment.

Improve Visibility into Vendor Functionality

With the ever- rising complexity and cost of enterprise application integration (EAI) efforts, it is essential that project teams improve their understanding of how vendor offerings map to processes before purchase and implementation. The definitions, flows, and functional requirements encapsulated in the process model help process and IT analysts to evaluate the fit between the two. By examining these elements of the process model and comparing them against the capabilities of the application package, analysts can expose biases, assumptions, and constraints that are not revealed during the typical feature/function checklist review. Let's take the example of a company evaluating a vendor's supply chain package to determine the fit between its automatic load-routing functionality and their transportation management process. The design of the company's Receive and Ship Orders sub-process requires that carriers meet up-to-date contractual requirements prior to receipt and loading of goods. The functional requirement could be Verify Contract Rates Meet Approved Schedule. The process, in effect, demands that the final package account for this condition in its transportation planning module. If the vendor cannot match this requirement with out-of-the-box functionality, this represents a constraint. Analysts will then have to decide if the requirement is non-negotiable, and if so, how they can satisfy the requirement through customization, alternate package selection, or other means.

In the end, process optimization helps project teams make the right judgment call between end- user non-negotiables and application requirements earlier in the evaluation process, resulting in reduced integration costs and improved solution delivery.

Provide Inputs to Simulation and ABC Efforts

Simulation and ABC efforts are extensions of process optimization that attempt to improve how the process itself performs . Simulation is generally practiced during BPR initiatives. It involves conducting animated "what-if" experiments on current process models to reveal bottlenecks or underutilized activities. These experiments (also known as discrete or continuous event simulations) help process engineers measure the effect of changes on variables such as timing, queuing, scheduling, resources, and costs. ABC methods uncover waste or inefficiency by calculating and analyzing cost consumption per activity (e.g., generate purchase order). This differs from traditional accounting methods that track lumped costs per department (e.g., marketing). Once again, current process models provide the basis for analysis, allowing process engineers to associate operating costs and capital charges with the activities represented in the model.