Characterization of Tools for
Business
Process Reengineering
Michael Grüninger
Table of Contents
We can consider any software tool for BPR as having five aspects:
- Integrated enterprise models
- Analysis (problem-solving capability)
- Software functionality
- Visualization and Communication
- Intended Users
These properties address two major themes:
- What tasks do the tools perform?
- What support do the tools require?
In this section we present a set of questions which can be used to evaluate BPR tools with respect to the BPR framework.
It will require that we first define the necessary properties of any tools for a particular stage of BPR. That is, given the framework, we must specify the required expressiveness of the enterprise models, the set of analysis tasks, the continuum of auto
mation for these analysis tasks, the set of possible intended users at different stages and their requirements, and the relationship between these properties and the tool's software functionality and visualization.
We first present some issues which can guide us in this characterization of BPR tasks with respect to the framework.
- How is a particular enterprise modelling language useful for supporting BPR at a particular stage in the framework?
- What requirements must the enterprise modelling language satisfy in order to support BPR at some stage?
- Identify the enterprise modelling language required to support the analysis tasks identified for a particular stage of BPR.
- 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.
- What kind of analysis is applicable at a particular stage of BPR, if any? Specify these analysis tasks.
- What enterprise models are required to support the analysis?
- How do the analysis tasks change with the intended users? In particular, consider the following questions:
- 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?
- What needs to be visualized?
- How is the visualization related to the class of analysis task?
How can this characterization of BPR tasks be used to evaluate tools?
How do we evaluate the ontologies for a given tool?
How can we use the following questions to evaluate the modelling capabilities of a tool?
- How do characterize the expressiveness of the ontologies?
- Consider the classes of constraints used in the specification of the competency questions for the BPR Framework; are all of these classes captured in the ontologies that support the tool?
- Are these different classes of constraints integrated within the set of ontologies?
- Can these constraints be used to define special classes of problems and enterprises, or are the ontologies of the tool restricted to a particular class of problems and enterprises?
- Do we characterize the ontologies using the reasoning tasks of the tools as competency questions?
- What role do domain-specific ontologies play?
- Are the ontologies extendible, allowing the incorporation of new classes of constraints and the specialization of concepts and constraints for a particular enterprise?
- Do we keep a repository of examples and motivating scenarios as challenge problems for the ontologies of a tool?
Express all reasoning tasks for a tool as competency questions.
- Do we keep a repository of examples and motivating scenarios as challenge problems for the analysis/reasoning tasks of a tool?
- Different reasoning tasks will fall on different points in the spectrum of automation. How do we specify the questionnaire format for this spectrum?
The software functionality for a tool depends on the expressiveness of the enterprise model and the degree of automation in the tool's reasoning tasks. How can we characterize this relationship for the repository pages?
How rigorously can we specify software functionality and justify it in terms of the analysis and reasoning tasks? On the one hand, the functionality can be quite arbitrary, since it is the set of user requirements. On the other hand, we can define the s
upport required by the user if the tool does not perform the completely automated reasoning tasks. Which of the software functionality classes are based on this relationship to some set of analysis tasks?
The software functionality is also defined by the intended users of the tool. How can we characterize this relationship? Can we identify which aspects of an enterprise model must be made explicit for different users, or whether some classes of users req
uire special assistance in constructing, maintaining, or analyzing enterprise models?
Can we define classes of software functionality?
Tool integration environment
- Does the tool provide a repository of models for different enterprises, problems and solutions?
- Can we export and import models with other tools?
- Is the tool customizable to the class of problems and the class of user?
- Can the tool access information that is available in different forms?
- Does the tool provide an environment for "meaning mapping"? This 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 vari
ous audiences.
Enterprise model management
- Can the tool manage different kinds of data at different levels of formality?
- Can the tool represent the enterprise at different levels of abstraction?
- Can the tool use partial enterprise models, and combine these partial models into an integrated model of the entire enterprise?
- Is the tool opportunistic in providing information by tracking the information that is required?
Enterprise model construction
- Can new models be created from old models using templates?
- Does the tool have the capability of dynamically constructing and modifying models?
- Does the tool support the iterative refinement/elaboration and definition of the enterprise model, "filling in" pieces of incomplete models?
- Can the model acquisition tool handle incomplete and inconsistent information? Can it modify or augment a model when things don't work?
Project management
- Can the tool be characterized as an intelligent project coach, that guides the implementation through the different phases?
- Does the tool provide means of identifying areas of potential impact from other changes within the enterprise's environment and informing affected parties?
- Does the tool manage incremental change by providing 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.
- Does the tool provide guidelines for setting and increasing performance targets based on the process design and known adaptability rates for participating roles and organizations?
- Does the tool provide guidelines for establishing experiments useful to understanding areas that would improve process performance?
Are the tasks performed by a tool different for various classes of users? How can we characterize this difference? Can we in some way determine the required analysis tasks and software functionality for a particular class of users?
To evaluate the tools, we may use the following questions:
- Can the tool be used by different organizations within the enterprise?
How do we use the structured access to the BPR Tool Repository?
The user may want to ask the following questions:
- What tools support a given stage of BPR?
- This is accessed through the BPR Framework page. It can be defined at any level of abstraction in the framework; the different levels of abstraction are defined in different pages.
- At a given stage of BPR, there will be a list of BPR tools, from which we can access their complete description.
- There will also be pointers defining the properties of the tools required at this stage of BPR, through which we can evaluate the list of tools with respect to enterprise models, analysis tasks, software functionality, and visualization. This enables
us to address the question of what tools support a particular analysis task (e.g. simulation) at a particular stage of BPR. Thus, given each property, we can access the tools that support this property at this stage of BPR.
- Do we want to make a distinction between the properties a vendor claims that the tool has and the properties that it actually has?
- What tools support a particular analysis task (e.g. simulation) at any stage of BPR?
- This is accessed through the BPR Tool Properties page. From each of the main properties we access pages that describe the properties in detail. This list is specified using the characterization defined in the preceding section. From these detailed
properties we access a list of tools that address the tool property; from this list we may also access the complete description of the tools.
- Give an evaluation/profile of a given tool; i.e. what stages of BPR does it support, what are the properties of the tool?
- This is defined in the main page for the tool in the repository.
The repository will contain three different classes of pages. The first will give an overview and basic description of the tool, as well as pointers to the detailed property pages. The basic description includes pointers to the pages for the different p
roperties of tools and stages of BPR that are supported by the tool.
There will be a class of page which defines a particular property of a BPR tool (such as an analysis task, characteristic of an enterprise model, description of software functionality) in a particular stage of BPR. On this page will be description of the
property and a list of tools that satisfy this property. Each of these tools will be a pointer to the tool's overview page.
Finally, there will be pointer pages for each of the different stages of BPR and each of the different properties of BPR tools. These were described in the preceding section.
A major issue in updating the repository is the maintenance of consistency and cross-indexing among all of the different pages. By having separate pages for the cross product of BPR tool properties and stages of BPR, we do not need to worry about explici
tly checking for cross indexing, since this is done by pointers. However, we will need to ensure that every tool property page that mentions a particular tool has a pointer that is included in the overview page of the tool.
To add tools to the repository, we will therefore need to first add an overview page. We must then take the user on a guided tour of the repository, so that she can add the properties of the tool at the appropriate place in the structure of pages. This
tour will be in the form of a questionnaire for the different properties of tools and the different stages of BPR.
One problem will be adapting the level of abstraction for the stages of BPR. Do we use the detailed description of each stage as the basis for the questionnaire, or do we allow users to simply say that a tool supports some stage at an arbitrary level of
abstraction?
EIL Homepage
