IT's Role in Business Process Reengineering Initiatives
By some estimates, over seventy percent of today's companies are performing business process reengineering (BPR). BPR realigns business processes along more strategic lines by examining current processes and redesigning those processes to increase efficiency and effectiveness. As more organizations launch BPR projects, one issue becomes painstakingly clear. Radically altering business processes within highly automated work environments typically requires modification to the information systems that support those processes.
Information technology (IT) organizations have had significant difficulty meeting the BPR challenge due to the inherent complexities involved in "retooling" complex legacy environments. In order to more effectively respond to BPR retooling demands, IT must play a more active role throughout a BPR project. IT must:
 | Increase their level of participation in all areas of a BPR initiative; |
| Provide key information regarding automated processes to business analysts; |
| Build a transition strategy that meets short and long-term retooling requirements; |
| Enforce the integrity of redesigned business processes in the target system; |
| Reuse business rules and related components that remain constant in a target application. |
Factors driving a BPR project can include improving customer service, streamlining processes to cut costs, or addressing inefficiencies in other high impact areas. For example, customers frustrated with having to speak to multiple individuals regarding an insurance claim may switch to the competition. To address this problem, an insurance provider determines that service functions must be consolidated to one point of contact. The underlying systems that manage claims handling do not support single point of contact processing. In this case, legacy systems have become a barrier to the success of the BPR initiative.
Regardless of the motivating factors, creating an implementable retooling plan to support a BPR project remains a frustrating, yet essential, challenge to IT organizations. Retooling strategies can include surround technology, off-shore rewrites, redevelopment of impacted systems, webification and package acquisition. Surround strategies, like the creation of graphical user front-ends or a data warehouse, provide some near-term benefit, but tend to ignore fundamental problems with stovepipe information architectures.
Off-shore projects, which involve shipping a system overseas, typically focus on a technical rewrite of a system. Redevelopment of impacted applications normally couples redesign of the technical architecture with redefinition of system boundaries and addition of new functionality. Linking business functions to the internet still requires managing and synchronizing legacy data and applications. As for software packages, organizations must invest adequate time to determine if a package meets BPR requirements and the amount of customization required if it does not. The applicability of each of these approaches must be analyzed on a case-by-case basis.
To determine retooling strategies, a relationship between IT and the business must be formalized early on. This relationship, which supports BPR analysis and implementation, is reciprocal because business and technical analysts must devise a continuous feedback communication loop for projects to work. This is particularly critical because current systems analysis helps articulate the as-is business model while the redesigned business model dictates the impact BPR has on existing information architectures. Once this reciprocal cycle is in place, IT can determine exactly how to upgrade, redesign, or replace selected systems in order to implement reengineered business processes. Figure one highlights key steps in a retooling strategy.
BPR Retooling Steps
|
1. Define strategy, select modeling methodology & establish BPR project plan |
|
2. Build as-is business model for impacted business areas based on strategic vision |
|
3. Refine / expand as-is model for all processes supported by existing systems |
|
4. Integrate as-is process definitions with current system functions & components |
|
5. Finalize functional and technical architecture required to meet BPR objectives |
|
6. Select retooling strategy to redevelop, surround, acquire, webify or off-load applications |
|
7. Maintain design integrity between business requirements and retooled applications |
|
8. Reuse applicable components including rules, interfaces & data in target application |
|
9. Validate retooled application against initial simulation of redesigned processes |
Figure 1
IT Plays Key Role in Assessing Changing Business Requirements
Being able to determine appropriate retooling strategies requires that
individuals with knowledge of the information architecture be on the BPR team.
Early and ongoing involvement of IT personnel benefits all aspects of the
project. Initial IT involvement focuses on discovery. If a process is to be
fully understood, and portions of that process are automated, analysis of
underlying applications facilitates the completion of the as-is business process
model.
Organizations need to develop an organic blueprint of the business to create widespread awareness of vision and a common understanding of how the organization functions. This includes defining the organizational units, processes, resources, and interactions between each of these objects. One approach might be to use Ivar Jacobson’s ‘Use Case’ techniques. Use Case defines stakeholders within an organization and their relationship with various objects.
Use Case modeling was first defined in Jacobson’s book Object-Oriented Software Engineering. A major benefit of Use Case is that it offers a simplified notation for users. Use Case facilitates the expression of business events and objects impacted by those events. Modeling a complete business process is more intuitive when it can be bounded by tangible events. For example, a process begins when a customer places an order and ends when an order is received and payment is made. Use Case is also an excellent way of representing roles within a business model.
Because Use Case integrates with object-oriented techniques, it bridges the gap between strategic business modeling and the systems specification process. This gap has historically resulted in system designs that do not support BPR requirements. To that end, some vendors have automated Use Case modeling to support techniques such as the Booch object-oriented method.
Traditional business process modeling techniques are not as powerful as object-oriented techniques in terms of being able to break down complex systems. Traditional models also do not provide the same level of flexibility, emphasis on reuse, and intuitive link to software design models. Organizations using traditional BPR techniques can end up with rigid models that are unnecessarily redundant and complex. This should be considered when defining the business model and create a cross functional systems design.
While many people agree with the goal of developing flexible, reusable process models that can interface directly with system design models, some challenge the view that object modeling is the best approach. While object-oriented models are mathematically correct, it is non-trivial to follow them. This is particularly true for the non-technical business user.
One approach involves storing business processes and interactions in an automated facility designed to manage those processes. Each process may then be decomposed into the user interface required to implement that process. This requirements model is easy to understand, helps visualize a target system, and actually becomes the front-end design. Another issue typically ignored during a BPR project is that process redesign tends to be an ongoing effort at many companies. Using a process automation tool provides flexibility to business analysts and users who must update business process models on an ongoing basis.
Existing Architecture Must be Mapped to Business Model
One majo IT requirement involves mapping the existing information
architecture to the business model to accurately depict current processes.
Historically, companies could separate business operations and underlying
technology. This distinction is no longer possible. Both areas must be analyzed
in an integrated fashion to understand current business processes. This involves
analyzing the systems, as well as human interaction with those systems. This
includes reviewing system functions, user interfaces, operational procedures,
and the often convoluted process of data sharing.
The method used by IT analysts to refine the as-is process model requires documenting current functions and presenting the information in a way that can be integrated into the business model. For example, if order processing is being reengineered, analysts must review system functions that initiate, register, process, deliver, bill, and collect payment for an order. In many legacy architectures, these functions are scattered across numerous standalone or stovepipe systems.
IT-based analysis involves building an inventory of all impacted systems and includes system name, location, operating environment, owner, interfaces, and programs. This inventory should be established at a subsystem level where applicable. The information collected here can be tracked using spreadsheets or in an open repository using a standardt ransition model. While a formal repository representation of a transitional model is more robust, the spreadsheet is a good communication vehicle for users.
The transition model can be established using standard repository technology. Additionally some products include a database that allows analysts to store information about a system. In some of these products, meta-data can be depicted in an object model that can then be used to model business processes. This integrated view, coupled with the ability to layer objects, allows business analysts to view summary information and IT analysts to view the physical detail.
Building a base of information that defines an existing information architecture requires working with systems analysts to identify which pieces of which systems support key business functions. A function is "a group of business activities which together completely support one aspect of furthering the mission of the enterprise". Research can be done through interviews with system subject matter experts or through interrogation of interfaces, including screen and report headings. This process is called "reverse requirements tracing" and is most effective when results are verified with subject matter experts.
Legacy functions are mapped into the transition model as they are identified. The research process focuses on those systems that contain functions that support the processes defined in the business model. Each function, as it is discovered, is linked to the business process it supports. That function is then linked to the user interfaces that implement or initiate it. Interfaces include on-line screens, batch reports, and job control streams. User interfaces can be linked to the programs that implement that function during the implementation phase - depending on the retooling strategy.
Analysts continue to link business processes to functions, and functions to physical components, until all automated processes in the business model are mapped. The reason a business process is linked to an extracted function as an interim step in the transition model is due to legacy system limitations. Functions, normally scattered across stovepipe systems, are extracted from complex legacy interfaces. Creating an interim mapping is therefore easier than trying to relate legacy components directly to process-driven business models.
Retooling Strategy Must Consider Legacy Architecture
Evolution
In any BPR project, the as-is model should be used as a basis to redesign
workflows. As processes are eliminated, updated, added, and re-sequenced, links
to legacy system functions are maintained in the transition model. The modeling
approach used can be flexible, because the open transition model supports
mapping of legacy functions to object, user interface, or other types of models.
Upon completion of the new business model, work can begin on the retooling
strategy. This requires an assessment of the existing architecture and target
requirements which results in a detailed, retooling implementation plan.
The first step in the assessment requires management to identify feasible retooling hypotheses. This includes surround strategies, redevelopment, offshore options, internet options and / or package acquisition. Several basic issues drive which hypotheses are considered. An immediate requirement to address customer service consolidation may necessitate surround technology, such as graphical front-ends or data warehouse. An offshore rewrite could also serve as an interim strategy to stabilize a weak system. Additionally, selected off-the-shelf packages may meet retooling requirements. Finally, redeveloping impacted systems may be the ideal long-term solution to meet BPR requirements.
Regardless of the approach, the transition model can be used to support detailed analysis, design, and implementation. The analysis needed to finalize the retooling plan includes maintaining links between business models and detailed design models, further decomposition of legacy functions, and mapping legacy functions to detailed target models. The type and depth of analysis depends on the strategy being examined. Fore xample, requirements mapping to a package compares package models with target and legacy design models to determine reuse, deactivation, integration, and migration requirements.
Full-scale redevelopment, depending on the target architecture, requires detailed extraction and reuse of existing business rules. Extracted business rules must be mapped, at the applicable level of detail, to target design models. Augmentation of target models, and reuse of key business rules, can significantly streamline redevelopment cycles and shorten implementation windows. Many of the existing business rules can be reused under a target architecture. Organizations are spending a lot of money trying to recreate business rules when they don’t have to.
These concepts challenge traditional BPR retooling strategies which include surrounding impacted systems or undertaking a complete rewrite. The first approach ignores the fact that underlying architectures remain segregated and convoluted. The second approach rarely accommodates legacy migration requirements and tends to exceed delivery windows and budget plans. Selecting a common sense approach, based on detailed analysis of target and existing architectures, yields the best results.
Several redevelopment options can be applied as a way to retool legacy architectures. Regardless of the approach, systems should be phased in over time, while deactivating legacy components along the way. One approach is to create a system to support the cross section of the business being reengineered. In the order processing example, this means mapping all business rules extracted from multiple standalone systems to a target design model. Rule extraction is accomplished using a combination of slicing and cross-system extraction tools.
Another approach, applying similar techniques, performs multi-system integration on all relevant systems. This approach retools the existing architecture on a broad scale. The focus is on mapping legacy to target design models, rule reuse, redundant rule consolidation, legacy deactivation, and transition management. Both approaches require phased decomposition of existing systems into reusable business logic, data access, and communication segments. Data store consolidation and redesign is performed concurrently. The transition model plays an active and critical role throughout the implementation process.
Internet utilization requires an assessment of the role of legacy data and functionality. Leveraging the Internet requires more than setting loose scores of para coders. Redevelopment offers this broader view of the issue and the solution. Even package strategies require a retooling component. Legacy systems must be inventoried, deactivated, and integrated as part of package implementation. If the package requires retooling, redevelopment techniques may be applied after implementation. Any of these longer term approaches can be coupled with a parallel, interim surround strategy to deliver value near-term.
While it is true that BPR retooling efforts, a relatively new endeavor for IT, have stumbled in the past, this no longer needs to be the case. Following a few basic guidelines, along with education on the tools and techniques that support the process, allows managers to evaluate more options and make more informed retooling decisions in the long run. As IT moves up the retooling maturity curve, realistic interim and long-term retooling options should become the norm.