Designing Tools to Support Business Process Reengineering
Enterprise Integration Laboratory
Department of Industrial Engineering, University of Toronto
Toronto, Ontario M5S 1A4
tel: 416-978-6347 fax: 416-971-2479
Table of Contents
Market competition is forcing firms to reconsider how they are organized to compete. As a basis for change, they are exploring a variety of concepts, including Time-based Competition, Quality Function Deployment, Activity-Based Costing, Quality Circles, Continuous Improvement, Process Innovation, and Business Process Re-Engineering. Regrettably, most of the concepts are descriptive, if not ad hoc, and lack a formal model which would enable their consistent application across firms. Business process re-engineering is very much in the "guild" mold of application; management consultants are the "masters" and they impart their knowledge through "apprenticeship" to other consultants. The knowledge of business process re-engineering has yet to be formalized and reduced to engineering practice.
The goal of the Enterprise Engineering Project at the University of Toronto is to:
· Formalize the knowledge found in Enterprise Engineering perspectives such as Activity-Based Costing, Agility, Quality, and Time-based Competition. By formalize, we mean the identification, formal representation and computer implementation of the concepts, methods and heuristics which comprise a particular perspective. This not only enables a precise formulation of the intuitions implicit in practice, but it is also a step towards automating the execution of certain tasks involved in enterprise engineering.
· Integrate the knowledge into a software tool that will support the enterprise engineering function by exploring alternative organization models spanning organization structure and behaviour. The Enterprise Engineering system allows for the exploration of a variety of enterprise designs. The process of exploration is one of design, analysis and re-design, where the system not only provides a comparative analysis of enterprise design alternatives, but can also provide guidance to the designer.
· Provide a means for visualizing the enterprise from many of the perspectives mentioned above. The process of design is performed through the creation, analysis and modification of the enterprise from within each of the perspective visualizations.
Business process reengineering knowledge is currently descriptive, ad hoc, or pre-scientific. It is a collection of heuristics which are not applicable in all circumstances. We want to define a theory of BPR by discovering the underlying principles for business process reengineering. We want to understand why different approaches and techniques work for certain enterprises and why they fail for other enterprises.
The results of the project are implemented in a prototype software system for evaluation by our industrial partners. This prototype is intended to be useful for consulting companies, software vendors that try to offer complete solutions for enterprise integration, and for organization units in major companies that analyze and design business processes. The primary advantage of the approach taken in the project is that the tools that are designed are generic for a wide range of applications. In order to ensure that the prototype achieves this goal, an advisory group has been created that is comprised of companies in the above areas and which provide direction to the research efforts. The role of this group is to evaluate existing tools for enterprise design and to propose necessary capabilities for new tools.
To assist in achieving the goal of creating the information technology to support business process reengineering, the group adopted the following set of milestones:
This document presents the group's vision for BPR tools and also specifies criteria for the evaluation of these tools.
- September 94: Sharing of experience and previous work by participants.
- November 94: Development of a common understanding of BPR.
- January 95: Characterize the objectives of BPR.
- February 95: Where in the BPR process is information technology useful?
- March 95: Specify the nature of information technology to support BPR.
- May 95: Specify requirements and identify evaluation criteria for the IT software environment which will support BPR.
We can consider any software tool for BPR as having five aspects:
These properties address two major themes:
- Integrated enterprise models
- Analysis (problem-solving capability)
- Software functionality
- Visualization and Communication
- Intended Users
The following sections consider more detailed questions for each of these aspects of BPR tools. We will then present some preliminary ideas for the nature of BPR tools for each stage in the framework, and propose requirements for these tools.
- What tasks do the tools perform?
- What support do the tools require?
An enterprise model is a computational representation of the structure, processes, information, resources, goals, and constraints of a business, government activity, or other organizational system. It can be both definitional and descriptive, spanning what is and what should be. The role of an enterprise model is to achieve model-driven enterprise design, analysis, and operation.
We are taking what can be viewed as a "second generation knowledge engineering" approach to constructing our enterprise models. Rather than extracting rules from experts, we are "engineering ontologies." An ontology is a formal description of entities and their properties, relationships, constraints, behaviours. It provides a common terminology that captures key distinctions and is generic across many domains.
Our approach to engineering ontologies begins with defining an ontology's requirements; this is in the form of questions that an ontology must be able to answer. We call this the competency of the ontology. For any task in which the ontology is to be employed, the task imposes a set of requirements on the ontology. These requirements can best be specified as a set of queries that the ontology should be able to answer, if it contains the relevant information. The competency questions are the basis for a rigorous characterization of the information that the ontology is able to provide to the task. Competency questions are used to evaluate an ontology in the sense that the ontology must be necessary and sufficient to represent the tasks specified by the competency questions and their solution. These are also the tasks for which the ontology finds all and only the correct solutions. Tasks such as these can serve to drive the development of new ontologies and also to justify and characterize the capabilities of existing ontologies.
An integrated enterprise model provides the language used to specify an explicit definition of an enterprise. For reengineering, we need to explore alternative models in the design of enterprises spanning organisation structure and behaviour. In order to reason about alternative designs for enterprises, we need to reason about different possible sets of constraints for enterprises within the language. We need to ask the questions -- can a process be performed in a different way, or can we achieve some goal in a different way? Can we relax the constraints in the enterprise such that we can improve performance or achieve new goals?
We also need to be able to determine the impact of changes on all parts of the enterprise. For example, if we relax one of the policies, how will this affect the quality of products or services provided by the enterprise? If we purchase a new kind of machine, how will this affect the activities that are performed? Will we need to retrain people in the enterprise to give them the skills to use the machine? If we change the activities that are performed, how will this change resource consumption?
A related problem is the use of benchmarking in the reengineering process. In benchmarking, we are comparing performance between enterprise and then adopting processes and practices from enterprises which are the best performers. However, not all practices can be adopted from other enterprises; the key is to realize that we must identify opportunities for improvement by analyzing the successes and failures of similar enterprises. Herein lies the problem -- what is a similar enterprise? What is compared among enterprises when we use benchmarking? We cannot compare the goals and activities among enterprises unless all constraints and assumptions about the enterprise and its environment are made explicit.
By representing the enterprise as a set of constraints using the ontologies, all of the above questions can be considered as either constraint satisfaction or logical entailment problems in first-order logic. All of the relationships among the different constraints within the enterprise are therefore made explicit.
An enterprise is defined by the following set of constraints:
Using this framework, we can characterize classes of enterprises by sets of assumptions over their processes, goals, and organization constraints.
- definitions of the activities performed by the enterprise.
- constraints on resources required by activities performed in the enterprise.
- constraints among organizational roles, positions, and agents within the enterprise. This includes constraints on the behaviour of agents.
- constraints defining the goals to be achieved by the enterprise.
- constraints on products, including product design requirements, quality constraints, and product standards.
- Rather than manufacture and distribute products, many enterprises provide services to their customers, and we must also be able to model this enterprises within our framework. This requires us to have an ontology for services, where a service is intuitively an activity performed by agents within the enterprise to either change the properties of some resource (e.g. delivering packages, painting buildings, dry cleaning, repair) or to provide information to customers. In this case, the definition of the enterprise must specify a set of constraints on products and information that define the activities the enterprise performs as services.
- set of constraints on activities in the enterprise. This includes policies and performance constraints, such as the following examples:
- All deliveries must be made within 15 minutes of placing the order.
- When an order is made, a copy is sent to the regional office.
- set of constraints defining the external environment of the enterprise, dealing with customers, markets, suppliers, and competitors. This also includes the definitions of the activities performed by agents external to the enterprise (e.g. suppliers, subcontractors), but whose effects are required by the activities within the enterprise.
A necessary first step is the precise definition of the analysis tasks performed by different tools in the environment and the ways in which they interact. This specification is independent of the algorithms used to solve the tasks - we are specifying the problem and what constitutes a solution to the problem. In this way will define the functionality of each tool; this will require the definition of what is the appropriate input to each tool and what is the correct output. The specifications of these tasks for the tools will serve as competency questions for the different ontologies that are being designed.
Each advisor is a constraint-based problem solver - given a set of goals and constraints, a tool searches for a solution that optimizes the goals and satisfies the constraints. Tools also have the ability to generate more than one solution, thereby the enabling the consideration of alternatives and trade-offs.
The tasks for each advisor fall into three main groups:
Evaluation tasks are either decision tasks (does the enterprise model satisfy some set of requirements, such as ISO 9003 compliance) or property evaluation of an enterprise model (what is the cost associated with some set of activities). This requires the ability to compare two different enterprise models along some dimension, such as cost or quality. In addition, the distinction must be made between evaluation of the enterprise model (static set of activities) and the evaluation of a plan or schedule at some point in time.
Analysis tasks involve prediction, monitoring, identification, and explanation with respect to an enterprise model. Prediction is the determination of the value of some proposition at points in the future. Monitoring is the determination of the value of some proposition after executing some set of activities, and comparing this value to the predicted value. Identification is the task of finding objects that satisfy certain properties in an enterprise model. Explanation is the task of determining why a proposition has a certain value at some point in time; this requires deciding what set of event occurred and what propositions hold that entail the value of the proposition in question. For example, we may want to predict the cost associated with some set of activities and then monitor and compare the cost of the execution of the scheduled activities. We may want to know why a particular product has a given cost, or why the activity took so long to complete; these tasks require some mechanism for explanation. Another analysis task may be the identification of the resource bottlenecks within an enterprise model, or the anticipation of resource conflicts.
The explanation tasks illustrate the relationship between evaluation and guidance for the tools. If a particular enterprise model fails to satisfy some property, we may want to know why it fails. This in turn suggests ways in which we may augment the enterprise model so that it does satisfy the property. For example, an enterprise may not be ISO 9003 compliant; the explanation task would recommend that the appropriate quality control processes be included in order to satisfy compliance.
Finally we have the guidance tasks for these tools, in which the tool suggests alternatives. The tool must be able to represent and model the current status of a process and assess potential changes. For static models, this requires the ability to generate different models. This is also related to the evaluation tasks of the tools; if a process fails to satisfy certain requirements, the tool suggests alternative models of the process which do satisfy the requirements. Comparing and evaluating the different alternative futures and possibilities for the processes in an enterprise with respect to the execution of plans and schedules requires a mechanism for hypothetical reasoning.
These are the capabilities of the tools that are independent of the reasoning tasks required for analysis. They deal with properties of the implemented ontologies and analysis tasks, and can be roughly categorized as follows:
A major theme in the BPR framework is the creation of an integrating environment for different tools. Toolkits for spot solutions exist, but there is no consistency among tools. In order to address the problem of integrating different BPR tools and the different enterprise models that support the tools, any IT environment for BPR should use integrated enterprise models spanning activities, resources, organization, goals. products, and services. These integrated enterprise models would then serve as a common repository accessible by multiple tool sets.
- Tool integration environment
- Enterprise model management tools
- Enterprise model construction
- Project management tools
Further, these enterprise models must be extendible, allowing the incorporation of new classes of constraints and the specialization of concepts and constraints for a particular enterprise.
To be effective, the tools and enterprise models must also support reusability, so that we can import and export models among different tools. We must therefore have an IT environment that supports tools that are able to build on previous solutions. This requires that there be a repository for different enterprises, problems, and solutions, so that we can use different methods and reconfigure them to adapt to a given problem. This will be described in more detail later in the paper.
It is vital that the enterprise models and BPR tools used by different organizations within the same enterprise be shareable and usable across these multiple organizations.
Enterprise models also provide representations that are reusable in other stages of BPR.
Tools may be defined with respect to a general class of enterprises or environments. To be useful, these tools must be customizable, both to the class of problems and the class of users, whether they be managers, consultants, or engineers.
To address the problems of managing the different enterprise models to support the tools, we must support and provide synthesis of multiple views of the enterprise. The tools must provide flexibility in information gathering, managing different kinds of data at different levels of formality and representing the enterprise at different levels of abstraction.
In the construction of enterprise models, the tools must opportunistic in providing information by tracking the information that is required at the appropriate time. The tools must also be able to support partial models, and then combine these partial models into an integrated model of the entire enterprise.
Any environment that we design to support BPR must provide new ways of building enterprise models, particularly in the acquisition and validation of an enterprise model. Such an environment must therefore have the following properties:
Tools must have the capability of dynamically constructing and modifying models. They must support the iterative refinement/elaboration and definition of the enterprise model, "filling in" pieces of incomplete models, and facilitating the definition of the completeness of the enterprise model.
- The process of constructing an enterprise model must be interactive and dynamic.
- An environment for enterprise model design must support storyboarding.
There is also the problem of reconciling different enterprise designs that may arise during the acquisition process. Model acquisition tools must therefore be able to handle incomplete and inconsistent information, as well as being able to modify or augment a model when things don't work.
Dynamically linking between what you are constructing and what knowledge you currently have about what you are constructing or improving.
Tools to support BPR must facilitate communication of the properties of an enterprise design or redesign. Minimally, there must be annotated enterprise models. We must also be able to extract multiple pieces of the model in order to explain their interaction.
Ability to produce summaries of the intelligence gathered to support various types of communicating and reporting but retaining linkages to the sources of data.
Another aspect of BPR is that the customers (subjects of the BPR endeavour) are learning about their enterprise through the process of modelling the enterprise. The BPR tools should therefore support this learning process for the customers.
The first objective is the development of a symbology that depicts terms and concepts in the associated enterprise models. The symbology should be precise and general enough to support visual programing for performing the modelling task.
For those tasks that require multiple enterprise models, the primary issue will be the design of graphical interfaces that capture the dimensionality of the interdependencies and the possibility of merging the visualizations of the relevant models.
How do the requirements for BPR tools depend on the intended use of the tools? This question has two aspects. First, the tool may vary with the kind of user -- external consultant, internal consultant, manager, employee. The difference in the tool can include any of its properties, including the analysis tasks, software functionality, and visualization.
There is also the following distinction in the kind of BPR endeavour which must be reflected in the functionality of the tools:
One issue that needs to be explored further is whether there are implementation constraints that should be accepted in the tools. Related to this is the question of what technology is available to different users, which may determine the functionality of the implemented tools. Model acquisition may best be done using a notebook computer, while analysis of the model is done using a more powerful workstation.
- Tools that support BPR as a single intervention in an enterprise.
- Tools that support BPR within an architectural framework for a process-oriented enterprise, and which enable possible future BPR endeavours.
In this section we present a set of questions which can be used to evaluate BPR tools with respect to the BPR framework.
1. How is a particular enterprise modelling language useful for supporting BPR at a particular stage in the framework?
2. What requirements must the enterprise modelling language satisfy in order to support BPR at some stage?
3. Identify the enterprise modelling language required to support the analysis tasks identified for a particular stage of BPR.
4. Specify the terminology required to specify a particular stage of BPR. This means defining the terms used in specifying that stage, as well as constraints on the meanings of these terms.
1. What kind of analysis is applicable at a particular stage of BPR, if any? Specify these analysis tasks.
2. What enterprise models are required to support the analysis?
3. How do the analysis tasks change with the intended users? In particular, consider the following questions:
4. What kind of analysis is being performed by the particular tool that we are evaluating? This should be specified in terms of input and output.
- Are there different tasks for single intervention BPR endeavours as opposed to BPR projects within a process-oriented enterprise?
- Do managers require different analysis tasks than engineers or consultants?
1. What needs to be visualized?
2. How is the necessary information being visualized?
3. How is the visualization related to the kind of analysis task?
Tools for this stage of BPR can be characterized primarily as enterprise model acquisition tools. We first define the requirements for all tools supporting this stage, and then propose an initial set of tools.
The enterprise models must provide definitions and constraints for the following terms:
enterprise, corporation, key process, vision, strategy, objective, goal, core competency, enterprise performance criteria, process performance measures, environment, customer, customer needs, expectations, requirements, market, opportunity, competitor capabilities, sponsor, expected outcome of process, critical success factor for process, ownership of process
By using an enterprise modelling language, we can construct a normative model of the enterprise. This creates a semantics for the enterprise and an extendable model that can later be refined, and which allows semantic transformations between different contexts. We can also create a network of relationships, keep track of what is linked and to whom, and explore and navigate through this network.
We need to integrate global and local views of the enterprise. In particular, there is a need to provide structural frameworks for high-level understanding and integration:
Using an enterprise modelling language allows us to capture a picture of the enterprise that can be reworked. We can then answer the following questions:
- Mapping organizational metrics (business model) to the process perspective (process model).
- Diagnostics for best practice (benchmarks). In this way, we drive out insights for opportunities.
An enterprise model also provides us with mental modelling tools that assists participants for communicating and coming to an agreement.
- Where are the constraints and where can they be broken? That is, what are the invariants?
- What are the behavioral aspects of the enterprise?
In using enterprise models, we need to be aware of possible limitations for the enterprise model used by tools at this stage. In particular, how do we handle fuzzy issues, such as political culture?
By defining the desired outcome of a process, we can guide decision making since design becomes goal (desired state) driven. Other properties of an enterprise that can be represented as goals include desired performance levels are also goals (in which case we need to represent optimization criteria), and skill maps (as-is and desired).
The primary analysis tasks for this stage are:
Formal specifications of the competency questions for these analysis tasks must be provided.
- Determining the completeness of the set of constraints defining the enterprise.
- Model integrity checking -- determining the consistency of the constraints.
- Rationale for objectives and performance criteria -- have the linkages and dependencies been made explicit?
The essential capabilities required for model acquisition tools are concerned with the construction and editing of the model for a specific enterprise.
There are also several aspects of this stage which require that we represent BPR as a project (endeavour) within the enterprise. In this case, the tools must support the management of the endeavour.
The tools should be able to maintain consistency among themselves and the enterprise models, not necessarily uniformity. There may be the problem that the customer language is different than the tool language. In this case, we must provide an environment that can represent the different meanings for terms used by different people ("meaning mapper"). This also involves identifying the relevant assumptions used by different people, tools, or enterprise models. and the ability to capture multiple synonyms and utilize them in translation to various audiences.
Tools must be portable, able to access existing information that is available in different forms and correlate the output of different tools.
At this stage of BPR, the one of the primary tasks is the acquisition of the model for a particular enterprise. Any tool must therefore specify how we gather enterprise models, as well as provide some mechanism for a model repository.
The challenge at this stage is to design the appropriate interface for model acquisition tools. The relationships among goals, activities, and organizational roles are made explicit in the enterprise model; these relationships must also be explicitly visualized in the tools through the symbology of the associated enterprise models.
There is also a requirement to represent the current enterprise in order to communicate the problems and characteristics of the enterprise, as well as informally demonstrating that the enterprise model is complete.
At the stage of setting the context for the BPR endeavour, it is essential to make the case for moving forward with the BPR endeavour. Any tools must therefore be able to effectively communicate the problems and any preliminary solutions.
The enterprise models must provide definitions and constraints for the following terms:
skill requirements to support a process, information requirements for agents to perform their processes, system requirements to support a process, value-added processes, opportunities and possibilities for change.
In addition, we need to develop enterprise models that define the performance criteria (analytical and qualitative measures of processes), and the conditions under which these criteria can be evaluated. Each family of criteria provides a different perspective on enterprise behaviour.
Enterprise models serve as a means of establishing baseline performance and representation for processes.
An integrated enterprise model represents processes across multiple business units.
An enterprise model specifies the links between structure and behaviour, and identifies the impact and linkages of redesigned processes.
The primary kind of analysis in this stage is the evaluation of properties of the as-is enterprise with respect to the performance criteria.
Given the evaluation of the enterprise, there is a need to detect discrepancies between the goals and objectives of the enterprise and the performance of the as-is enterprise. Once these discrepancies are detected, diagnosis is required to identify the problem and potential solution opportunities.
There is also a need to support benchmarking in order to identify best practices that may be adopted and used within the redesign.
Formal specifications of the competency questions for these analysis tasks must be provided.
Ability to recognize various patterns in the data and intelligence gathered during study of processes and organization.
Automatic reconciliations of such things as accuracy and completeness of as-is representations and alternative futures.
With respect to evaluation and discrepancy detection, there are two options for the implementation of the analysis tasks. A tool may automatically perform these tasks, or it may provide a simulation capability which the designer uses to make judgments; the functionality of any tool will be somewhere between these two possibilities.
As in the preceding stage for BPR, we must be able to integrate different tools for BPR.
Any model construction tool for process definition should support (distributed) brainstorming.
- Integrate tools for documentation and simulation.
- Integrate data repositories.
- Customize tools
- Standardize representations among tools
- Integrate software functionality of tools (e.g. data formats)
- Integrate tools and IT of the enterprise. In particular, how is the input/output of the tool linked to the information technology of the enterprise?
One approach is to construct enterprise models using analogies. We can formalize this with the notion of case-based reasoning, which uses libraries of processes, enterprises, and BPR endeavours.
This also necessary for benchmarking and comparison of enterprises and BPR endeavours. We can identify classes of enterprises by the classes of constraints that they satisfy; enterprises that can be benchmarked must be in the same class of enterprises (that is, they must satisfy the same class of constraints).
If we have a case library of processes, enterprises, and BPR endeavours, we also need to define the degree of fit for cases. For opportunity identification, we only require a loose fit, while for guidance, we need a tighter fit.
We also use enterprise models as learning tools. They enable us to ask questions about the model which could not be articulated without a model of the enterprise. In this way we can use BPR tools to facilitate the formalization of people's intuitions about the enterprise and the intended semantics in a motivating scenario by identifying potential unintended models. We need to be able to simulate alternative enterprise models, and then identify the correct model. We can also use this technique to iteratively refine the enterprise model.
Provide visualizations that support the mapping of core competencies against the existing and future enterprise design.
We identified several key roles for enterprise models during design and redesign:
A challenge for any enterprise modelling component of a design tool is managing level of detail in modelling -- given an enterprise model, when do we drill down to a finer level of detail?
- Specify metrics and capture/monitor metric data.
- Identify the potential impact for a redesign. How is the new process integrated with the rest of the enterprise?
- Identify and prioritize processes and opportunities.
- Capture the rationale for a given redesign.
Enterprise models also play a key role in the communication of the change that is the result of redesign. Any design tool must convey magnitude of change and emphasize what must be changed. It must define the outcome of change, and communicate the value of change from different perspectives.
There are primarily three kinds of analysis that may be performed in this stage of BPR:
A key distinction here lies in what is given and what is constructed as the solution to the problem. For example, a planning tool would construct a plan given a set of goals, while a plan evaluation tool considers a plan that may have been constructed by a human designer. In terms of software functionality, this distinction in analysis tasks leads to two different kinds of tools -- those that construct parts of the redesign, and those that assist the designer in the redesign. This leads to the following tasks:
- evaluation of a given enterprise design/redesign
- construction of an enterprise design/redesign
- Assessing complexity of required change
Formal specifications of the competency questions for these analysis tasks must be provided.
- propose alternative designs among which the designer chooses a subset.
- evaluate the consistency of partial designs and generate alerts in case of inconsistency.
- identify the set of possibilities at different stages of design.
Simulation plays a key role during design and redesign, particularly in the planning and execution of the migration to the redesign. Simulation is used to compare and evaluate alternative solutions. Simulation of what-if scenarios allows the designer to explore the space of possible redesigns and to analyze risk among alternatives. Simulation also plays a key role in impact analysis and failure analysis of processes.It is therefore used as an analysis tool, as well as a visualization tool that supports the communication of possible solutions.
Simulation can also be used as a tool for experimentation. If there are alternative possible enterprise models, simulation can be used to articulate the intended behaviour of the model, and compare this behaviour with the intuitions of people in the enterprise.
The issues here arise out of the options presented in the analysis tasks. If a tool is assisting in the redesign, the software functionality must provide an adequate environment for the construction of enterprises. The challenge is to identify what information must be made explicit for the construction of enterprise models.
How are tools that implement different analysis tasks integrated within the environment?
Another set of issues for software functionality arises out of the review and validation of the design with customers, suppliers, performers, and the sponsor. There is a need here to effectively communicate the results of the analysis as well as the advantages and disadvantages of the proposed redesigns.
As with software functionality, the requirements for visualization are driven by the analysis tasks of the tool. A tool that a designer uses to make judgments must have a visualization environment adequate for communicating the essential information for a simulation.
The enterprise models must provide definitions and constraints for the following terms:
change management, sustaining sponsors for the implementation, implementation plan, pilot, driver and supporter of change
At this stage of BPR, we need to analyze the redesigned enterprise model and the implementation plan for this redesign.
The tools must also link success criteria and key measurements of the performance of the change into the overall model so that both a pilot as well as the overall change can be evaluated, validated, and reported.
- Is the redesign feasible?
- Which issues will pose the most complexity? We will need to allocate resources to these issues.
Provide a framework and visualizations with which to capture the various aspects of support and resistance to change, with a set of diagnostics to assess possible resolutions.
The tools for this stage of BPR must support the specification and execution of the implementation plan for the redesign. In particular, these tools are assistants for participants in the implementation plan.
The implementation plan provides bridges from the change's design specifications to the specific new procedures for each role or system to be implemented. It defines the overall roadmap for the change that allows each affected party to see their required changes in the context of the whole as well as in relation to other affected parties. The plan also shows the expected outcomes and benefits for each affected party as well as the overall enterprise.
At this stage, tools are needed to guide the implementation through the different phases, and can be characterized as intelligent project coaches. They must provide means of identifying areas of potential impact from other changes within the enterprise's environment and informing affected parties.
In order to manage incremental change, the tools must provide the overall roadmap for the change that provides the stepwise progression of the implementation plan for each affected party in the context of the overall change steps. Based on actual performance data from the pilot or the overall change, the tools can recommend and integrate refinements to the design or the implementation plan.
It is also necessary to capture failures and use partial solutions.
The visualizations for tools in this stage must support the analysis tasks and the project management aspects of the implementation plan. The tools must allow simple and clear communication of the progress of the change project as well as the results of the pilot or overall change. They must assist each affected party to understand clearly what they are accepting when they confirm acceptance of the change.
The primary analysis task performed in this stage is the detection of discrepancies between the redesign and the implementation of the redesign. This requires some representation that supports execution monitoring.
The tools must first provide a framework for regular measurement of process path, process, subprocess and role performance. This performance tracking would compare plan to actual performance in such areas as cycle time, defects, activity outcomes, and costs. If there are discrepancies, there must be analysis tools to identify inconsistencies with the original design/redesign and establish the root causes of performance failures and/or stretching beyond current targets.
The functionality of tools at this stage are similar to those of the Implementation stage insofar as they must provide meaningful data and representations to process improvement teams and process owners.
The tools at this stage must also support the execution monitoring requirements. They must provide guidelines for setting and increasing performance targets based on the process design and known adaptability rates for participating roles and organizations. To support reasoning about possible failures of the implementation, the tools must also provide guidelines for establishing experiments useful to understanding areas that would improve process performance.
Provide visualizations to support each participant's view of the process.
The necessary functionalities for tools to support management are similar to those for the Operate stage of the BPR endeavour. Both must provide mechanisms for describing and communicating to each affected employee any change requests, potential problems, and potential solutions.
The tools must also define an architecture for a process-oriented enterprise by providing a repository for the following:
- standards for consistent descriptions of processes, process strategy and plans.
- the framework of entities necessary for effective process management
- linkages showing how each employee's job contributes to the building and delivery of value to the enterprise's customers.
To characterize human resources, we must identify the essential properties of agents within the enterprise. For example, we must represent the capacity of agents and behavioural aspects of agents within the enterprise, such as motivation, culture, incentives, and adaptability. We must also represent the constraints on the behaviour of people, such as policies and preferences and provide linkages from the process measurements to the organizational incentives.
Provide a simulation environment to support interactive training of change agents and people affected by new changes.
The analysis tasks (problem solving capability) of tools can be evaluated on a continuum of the degree of automation in the tool and the interface between the user and the tool that is considered as an assistant.
At one end of the continuum, there are tools which are simply visualizations of the enterprise models that facilitate communication and provide insight into the enterprise and its problems. By providing a mental model of the enterprise, the tool supports opportunity identification as participants gain an understanding of how the enterprise succeeds or fails.
As we move along the continuum, we encounter BPR tools that provide analysis of a given model through evaluation, identification, and monitoring of different properties of the enterprise. In these different forms of analysis, we are considering alternative enterprise models, which includes alternative plans or schedules for activities, alternative organizations, or alternative sets of policies for people in the enterprise. We are also considering alternative explanations for different properties of the enterprise, and alternative predictions for possibly hypothetical behaviour of the enterprise.
Given this characterization of alternatives, the analysis tasks may simply compare alternatives models/explanations/predictions in a given set produced by the user of the tool. This is type of analysis performed by current simulation tools.
To provide guidance for the user, the tools may generate alternative models/explanations/predictions which the user then evaluates.
In the most automated form of analysis, the tools perform automated design by generating models/explanations/predictions with particular properties.
The framework for BPR that we have defined in the group can be used in two ways. First, we will be using it to specify a set of requirements on the software tools that the Enterprise Integration Laboratory will be designing to support BPR.
We can also use the framework as a means of evaluating existing tools and identifying the stages of the BPR process where they provide the most support. In this way, we can identify those stages of the BPR process that are not supported by existing tools. To assist in this endeavour, the group agreed to compile a library of tools and summaries of their capabilities. This tool repository will be made available on the World Wide Web.