The Rule Transformation Approach to Business Renovation
The rapid and constant changes that are very common to today's business environments affect not only the business itself, but also its supporting business information systems [IS]. As a result, both business processes and information systems require constant change, renovation, and adaptation to meet actual business needs.
In the development of business IS, the existence of three elements has long been recognized: data, processes, and rules. Whereas the first two have been integrated using the object-oriented paradigm, rules are commonly neglected and left implicit in the program code (Diaz et al., 1998). The problem was identified in Appleton (1984) as the 'missing link' between high-level data architecture and project-level physical-database design or data-processing. According to Appleton, the fundamental information question was "Which ontology is being represented on our computers? In the early 1980s, it has become the ontology of process, e.g., marketing and product design, and in the next decade (1990s) it will become the ontology of an enterprise, or business." Appleton was right. We can only add: after 2000 it has become the ontology of business networking where, in the process of business renovation, business rules should be bound dynamically to support the challenges of the ever-changing business environment.
Business rules have grown in importance and popularity in the last few years. They have become recognized as distinct concepts that play a key role in developing applications that are flexible and amenable to change (Barnes and Kelly 1997; Date, 2000; Youdeowei, 1997). While a lot of work has already been done in various fields of business rule research -- most notably in rule analysis, classification, articulation, and formalization (Hay and Healy, 1997; Herbst, 1996; Herbst, 1997; Moriarty, 2000; Ross, 1997; Tanaka, 1992) -- a broader view, namely a behavioral or conceptual view on business rules, is required. The fact is that business rules are constantly changing at the business level, but we are not able to keep up with the changes that are required by the supporting IS.
For any thorough and effective renovation project, organizations should meet certain conditions before starting. First, organizations should abandon all obsolete rules and procedures used up to that time. It means that the process should not be constrained by current business rules. Breaking rules is how we recommend people learn to think inductively about technology during the re-engineering process (Kovacic et al., 2001). The application of Information Technology [IT] can break old business rules that limit the way in which work is performed (some typical examples are given in Turban et al., 1998).
In addition, organizations should abandon other inadequate organizational and production principles (Kelly, 1998). Global competition, economic downturn, and the potential offered by emerging technologies are driving organizations on to fundamentally review their business processes (Kalakota and Robinson, 1999). They call for the need to establish an integrative and holistic view on Business Process Reengineering (BPR) (Al-Mashari et al., 2001). Only at this point should the design of a renovated and redesigned organization start.
It should be pointed out that a higher level of IT-supported automated procedures brings about more or less negative results. Even if some of the results of such actions are positive, they prevent managers from seeing all the opportunities offered by the informatization of a redesigned business process and the infrastructure role of informatics. Radical process innovation has been encouraged by some quality experts (Davenport, 1993). There is a natural process improvement sequence that occurs as organizations apply TQM to their work. Watson (1994) suggested an elimination sequence procedure. He stated that most problems could be attacked by applying the basic quality tools of problem-solving and quality improvement processes before there is a need to automate work processes or seek IT-intensive solutions. BPR was a favorite managerial buzzword of the 1990s, but it seems that another popular term for this decade is 'business-model re-engineering.' The traditional 'old economy' companies urgently need to build on and re-evaluate their current business models and create new ones. Accordingly, e-business initiatives have truly strategic imperatives: creating a totally different business model. An e-business model generally means the adapting of a company's current business model to the Internet economy.
Business Renovation [BR] is presented as the highest level of a strategy for managing change that usually cannot be handled by continuous improvement and re-engineering methods or organizational restructuring (Kovacic, 2001). Process renovation is a re-engineering strategy that critically examines current business policies, practices and procedures, re-thinking them through and then redesigning mission-critical products, processes, and services (Prasad, 1999). BR argues for a balanced approach in which we attempt to manage realistic changes rather than always seeking radical change. According to Jacobson, we view business renovation as an umbrella concept for strategic IS planning, and both Business Process Reengineering (BPR) and business improvement (Jacobson, 1995). For their thorough and effective renovation, organizations should combine a radical shift with changes that permanently increase business efficiency and effectiveness.
We also observe that business renovation is now taking significant roles in business processes -- creating new business rules, causing new product development, and commanding new procedures. Following the full implementation of an IS in an organization, these internal changes may also lead to broader shifts in products, markets, and society as a whole (Bosilj-Vuksic et al., 2001). The relationship and influence between BPR and IS strategies is a key part of the classic texts in the area (Davenport, 1993, and Hammer and Champy, 1993).
In our paper we introduce in business renovation a meta-model and a business rule approach as a framework for the business rule refinement process. We propose a rule-based Business Renovation Approach [BRA] to provide a uniform modeling framework at different abstraction levels.
The paper is organized as follows. In the next section we provide the background needed for further discussion -- the business process and IS modeling, related problems, concepts, methods and tools for business rules analysis and refinement. The following two sections form the core of the paper. In these sections we introduce a business activity meta-model as an integration link between business and business process modeling and IS modeling, and a business rule-transformation approach to business renovation.
2. From strategic (business) modeling and tactical (business process) modeling to operational (IS/workflow) modeling
Modeling should be divided into strategic (business), tactical (business process), and operational (IS/workflow [WF]) levels. Business modeling includes the analysis of corporate strengths, weaknesses, and culture, the assessment of information systems in the organization, and organization and management competencies. It is the basis of all further actions and is carried out by corporate management. Corporate goals, strategies, and critical success factors form the basis of selecting and modeling core business processes at the global level of description. Business process model on the tactical level, together with information on the organization's current state, is fundamental for evaluating and benchmarking vis-à-vis other corporations. Detailed information system modeling of the processes or workflow structures takes place at the operational level.
A business model is an abstraction of a business that shows how business components are related to each other and how they operate. Its ultimate purpose is to provide a clear picture of the enterprise's current state and to determine its vision for the future.
Modeling a complex business requires the application of multiple views. Each view is a simplified description (an abstraction) of a business from a particular perspective or vantage point, covering particular concerns and omitting entities not relevant to that perspective. To describe a specific business view, several diagrams are usually used and complemented with textual descriptions.
For many years now, there has been increased recognition in IS modeling of the dynamic behavior of organizations (Green and Rosemann, 2000). Business process models are maps or images of the logical and temporal order of business activities performed on a process object. Business process modeling has been embraced as an appropriate way to describe business behavior. Every process is represented by its precise description, which contains both the behavior and structure of all objects that may be used during process execution. Business process modeling as an approach focuses on understanding the underlying business processes, where business rules are one of the most important elements for the detailed and formalized description of all facts that are to be implemented during IS development.
A number of authors have identified the need for a business (process) model prior to information modeling for the design of an information system in Information Architecture [IA] (Avison and Fitzgerald, 1988), (Curtis, 1989), (Valiris and Glykas, 1999). We propose business process modeling as a starting point for the development of IS/WF models. The IS/WF modeling environment provides a structured way of identifying and capturing all information, relationships, and business rules that make up a business process.
Several methods and tools have been developed to describe business and information (workflow) processes. These methods and tools differ in their constructs, notation, ease of use, and other aspects. Often, different methods are employed at different stages of the development process.
Workflow systems are able to support business processes if the business process is clearly structured and defined (Kovacic et al., 2001). Workflows are refined and modeled at the level of particular interdependent business activities that are performed by actors (resources) in an organization in order to achieve common goals. At this level, the more exact and certain the information about a workflow is, the better the modeling results will be.
In this framework, the notion of a workflow is clearly and closely related to the notion of a process and its execution. At a general level, workflow can be defined as a co-ordinated set of interdependent activities performed by actors in an organization in order to achieve a set of common goals (Yu, 1996, p. 239). In other words, workflow can be understood as a concept that embraces the initiation, realization, and management of business processes.
The problem lies in the conflict of aims between the need for accurate information and the difficulties of obtaining it due to the often obsolete documents describing flow structure, the varying or even contradictory statements from employees, and the time constraints (Grover et al., 1995). Here, we can add that the purely activity-based modeling approach dominant in the WF practice is unsuitable. At this level of detail, re-engineering tools for business rules analyzing and refinement are needed. Such tools allow users to build and tune a workflow before developing application solutions (applications).
2.1 Business rules: the link*/ ?>
Thus, an ongoing business rule management environment is required whereby each business rule instance can be traced from its origin through to its implementation. In IS/WF maintenance, such a link is essential since it provides information on the software modifications required to respond to changes in business policies, organizational tactics, external laws, regulations, etc. (as illustrated in Figure1).
Figure 1. Business rules as an integration link between business modeling and IS/WF modeling
The need to establish a clear link between business modeling and IS/WF modeling was recognized some time ago (Appleton, 1984, Bubenko and Wangler, 1993; Dobson, 1992; Do Prado Leite et al., 1998; Krallmann and Derszteler, 1996; Perkins, 2000; Rosca et al., 1995; Rosca et al., 1997).
In business modeling we distinguish different levels of abstraction (Joosten, 2000). These levels can be classified as follows: (1) value chain; (2) business processes; (3) activities; and (4) software components (procedures and data). Business process modeling covers the first three levels, whereas IS/WF modeling -- also known as Information Architecture (IA) thinking -- covers the last two levels.
An overlap exists at the activity level. Concerning this, usually an n:m relationship between business models and information (workflow) models at the activity level exists (Becker et al., 2000). In this paper, we recognize business rules as the missing link and discuss how they can be used to realize this link.
So far, the business rule approach has been biased mostly towards a structural perspective (Diaz et al., 1998). Our experience has shown that the existing structural "linking" methods or interfaces fall within the business renovation umbrella (see Becker et al., 2000; Green and Rosemann, 2000). These interfaces might provide some syntactical translation, but they cannot bridge the semantic gap between business models and IS/WF models.
2.2 Methods and tools for business rules analysis and refinement in a Business Renovation environment*/ ?>
The aims of using business modeling are:
(1) to help the Business Renovation [BR] team obtain a holistic view of the process under study;
(2) to identify areas for improvement;
(3) to visualize the impacts and implications of new processes (Chen, 1999); and
(4) to describe the rules that underlie the business process.
Business rules should be described in a natural language, and the business process should be modeled only at the level of detail that is sufficient to achieve these objectives.
In order to discuss the methods and tools of business rules analysis and refinement, we first have to expose some limits of existing business process modeling methods:
- Business process modeling is performed using either inadequate descriptive notations from management accounting or through poor use of graphical notations that were created for software development and do not take into account organizational issues (Valiris and Glykas, 1999).
- There is no formal underpinning to ensure consistency across models. When graphical notations are used in business process modeling and business redesign, there is no way of verifying the logical consistency of the resulting models. Semantic mistakes or disregarding of relevant aspects may possibly lead to some expensive misjudgments (Valiris and Glykas, 1999).
- On the other hand, some organizations have a tendency to over-analyze an existing system and therefore get stuck in the business process analysis phase of the project (e.g., analysis paralysis) from which they are never able to move on (Chen, 1999).
As we emphasized in the previous section, usually an n:m relationship between business process models and information (workflow) models exists. This means that several activities of a business process model are implemented via different IS/WF components or modules. More precisely, each business rule can be coded in one or more module structures, and vice versa.
The goal is to obtain a consistent representation over all abstraction levels and at different degrees of accuracy. The modeling process should be supported by appropriate methods and tools to allow and assist the developer to solve such a complexity. But, in practice, mostly all interfaces (methods and tools) between business modeling and IS/WF modeling simply implement a 1:1 coupling between these models. For example:
- The Workflow Management Coalition's [WfMC's] work group was (in 1996) developing
an integration between a business process model and a workflow model (Interface 1)
based on a modeling language. Interface 1 Definition deals with passing Process
Definitions from external modeling tools to the workflow engine where there are enacted.
The Coalition published a new language as a precursor to the Interface definition.
This interface includes a common meta-model for describing the process definition
and also textual grammar for the interchange of process definitions (Workflow Process
Definition Language – WPDL) (WfMC-TC-1016-P, 1999). This model meets standardization
requirements but has very limited practical applicability.
- There are some other possible 'tool-supported' approaches to the deployment of
business process models (i.e., ARIS method and tools) for selected application.
Applications can be implemented either by:
(1) adapting and assembling process-oriented business objects or by developing applications from scratch;
(2) implementing standard business applications (i.e., SAP);
(3) implementing workflow systems; or
(4) an object-oriented system development using the Unified Modeling Language (UML) (Sheer, 1999).
Here, the BR framework consists of the following four levels: Process design, Process management, Workflow, and Application. The connections between particular levels are explained (Sheer and Allweyer, 1999), yet the refinement method that supports the transition is not defined. Event-driven Process Chains (EPCs) have become a widespread process-modeling technique because of the success of products such as SAP/R3 (ERP) and ARIS (tools). Unfortunately, neither the syntax nor semantics of EPCs are well defined. As a result, an EPC may be ambiguous and it is not possible for consistency and completeness (van der Aalst, 1998). These problems are serious because EPC models are used as the specification of business rules processed by IS/WF systems. In using these approaches, experience has shown the tendency to over-analyze existing business processes and IS implementation problems.
To resolve this problem of complexity, some authors propose a rule dictionary (Krallmann and Derszteler, 1996) or rule repository where business rules have to be represented (Herbst, 1996 and 1997; Knolmayer et al., 2000). This repository -- where we capture, store, and manage business rules (Haggerty, 2000) -- is the core of a development environment providing appropriate tools for process, workflow, data and organization modeling, and process refinement, as well as import and export capabilities. A rule repository system also provides the opportunity to implement capabilities for analysis and simulation (Knolmayer et al., 2000).
In most cases, the modeling process should be supported by an appropriate rule repository. Our experience leads us to agree with the authors that this rule-based methodology has advantages over established tool-supported Petri nets (i.e., INCOME) and EPC (i.e., ARIS) rule-refinement approaches (described in van der Aalst, 1998 and Scheer and Allweyer, 1999).
3. Business rules and business activity meta-model
Business rules are explicit statements that regulate how a business operates and how it is structured. Besides being important as an organizational asset, they are also significant for the information systems that support the business. While it has been emphasized many times in the last few years (Kovacic et al., 2001) that business rules -- if appropriately implemented -- can help keep information systems aligned with the business environment, there is still no standard methodology to explain how to do this.
In this respect, our paper presents a meta-model and an appropriate rule-transformation approach as an integration link between business modeling and IS/WF modeling. Its motivation is to establish an environment in which business rules can be traced from their origin in the business environment through to their implementation in information systems. This provides the information necessary for rapid information system maintenance and adaptations to changes in the business environment.
We define the business process as a subset of business activities performed by the organization to achieve the goals it has been created for. Activities correspond to different stages of process execution. In order to be initiated, some activities require particular artifacts or events as an input, which may be taken directly from the environment or produced as outputs by other activities. Thus, an Event is a passive element of the process that reflects a signal in a business environment, which triggers the execution of an activity. A Data object is an instance containing a collection of data and methods for operating on that data.
Business rules can be classified in many different ways. In the business activity meta-model presented in Figure 2 we first divide business rules into two categories: behavioral and structural. The categorization described here is only an example of business rule taxonomy that we have found useful for our research.
Global rules that relate to an overall business process act as an interface between a particular business process and the goal, and critical success factors [CSFs] that the process has to achieve. These rules define or restrict organizational behavior. Such rules should be broken down into detailed behavioral rules governing specific business process activities and further into rules that control the operations within these activities. When examining business rules with regard to business processes, the following three relationships stand out:
- business rule relating to the overall business or Global rule;
- business rule relating to business process or business Activity rule; and
- business rule relating to the IS/WF procedure/definition or Structural rule.
The following example illustrates the different rule types. At the business level, we can usually find global business rules, such as: "Establish the optimal connections with our suppliers, establish an e-payment system…, including supply constraints…." Performing business activity (at the business process level) from these rules, a business activity rule is derived: "An invoice, received by mail or received via Internet, may be registered only if it has been received from our existing supplier." At the IS/WF level, the structure of this rule is transformed to an ECAA notation:
Business rule: "INVOICE _REGISTRATION": ON (invoice) OR (e-invoice) IF (related order exists) AND (receipt exists) THEN begin invoice registration raise event "INVOICE_ACCEPTED" ELSE reject invoice raise event "INVOICE_REJECTED"
When developing IS/WF components or applications in support of business processes, both the business rules that apply to an overall process and the rules that apply to a specific process-activity rule have to be considered and broken down into detailed (structural) rules. A process-activity rule or life-cycle rule is an assertion that governs or constrains changes to business objects or facts (English, 1998). Finally, we define detailed structured rules as specifications of requirements for the development of IS/WF applications.
The taxonomy of structural rules is based on Odell's work (Martin and Odell, 1998) with additional classes coming from the GUIDE scheme (Hay and Healy, 1997). A list of different business rule taxonomies and requirements can be found in Gottesdiener (1997, 2000). It was shown in the work of Herbst (1996) that a combination of Events, Conditions, and Actions (known as an ECA structure) can be used to specify single business rules. These rule components can be defined as follows (Knolmayer et al., 2000):
- The event component specifies when a rule has to be executed. It indicates the transition from one process relevant status to another.
- The condition component indicates a condition to be checked before any action is triggered.
- The action component states what has to be done on the result of the evaluation of the condition component.
At this structural level, business process can be viewed as a sequence of business rules that define how the thread of control is passed from one activity to another and in what circumstances the transition can happen. ECA-structure rules are used to specify dynamic behavior in database management systems. Some authors (Herbst, 1997) (Knolmayer et al., 2000) have argued that this structure is also appropriate for formalizing business rules at the conceptual level (global and activity rules). For the purpose of consistent rule representation, modeling, transforming, and refinement, ECA notation has been extended to ECAA rules that allow specifying an alternative action to be executed when the evaluation of the condition component returns false.
Figure 2: Business activity meta-model
We used an IDEF1X notation convention in the meta-model's development. Relationships between entities have an n:m cardinality. A global rule (in the center of Figure 2) is an aggregation of behavioral and structural business rule components. The first (leftmost) part of the meta-model contains the entities and relationships related to business process and behavioral features (Entities: Goal, CSF (Critical Success Factor), Business Process, Activity, Global Rule, Activity Rule, and Event); the right part of the meta-model is focused on structural and IS/WF implementation characteristics (Entities: Data Object, IS/WF Component (or module), Structural Rule, Event, Condition, and Action).
We regard the business activity meta-model as an appropriate starting point for the business rule refinement process at the business process activity level. The business rules that underline the business activities are first described in a natural language. In subsequent steps, these rules are refined in a structured way as a set of structured rules representing the business process at different abstraction levels. In the case of small and less complex models, a manual revision is more economical and less time-consuming.
The business activity meta-model concentrates on the role that business rules play with respect to IS/WF-related concepts. Its job is to describe the activities that must be undertaken to achieve an explicit goal and establish a clear link between business modeling and IS/WF modeling.
In the light of our experience we agree with the rule-transformation approach. This approach suggests transforming a rule-based description of a business process in one or more refinement steps into a rule-based WF specification (Knolmayer et al., 2000). Here, we see as unrealistic the expectations that structural (ECA or ECAA) rules may not only be used to specify dynamic behavior in database management systems but also for formalizing business rules at the conceptual (business and business process) level.
To support the transition between the business model and the IS/WF model, we propose the following approach based on a hierarchical derivation of business rules in the rule repository, performed by three subsequent iterative development phases, from the higher (behavioral) to the lower (structural) level of abstraction. During each of these phases business rules are discovered, documented, and modeled.
4. Business renovation: the rule-transformation approach
In this section we provide the rule-transformation approach as an iterative methodological framework that incorporates the best practices of more than 10 business renovation projects. Developing this iterative rule-transformation approach we incorporate some differences when compared to other traditional and business rule approaches.
First, we agree that traditional methodologies generally address rules only relatively late (if at all) in the system development life cycle. This, of course, is when it becomes most expensive to do so (Ross, 1999). The goal of a business rule methodology is to significantly shorten development time and to deliver a system that is designed for change (von Halle, 2002). To achieve these goals, we need a flexible methodology that supports a process-centered approach and divides the problem domain into three separate aspects: process, rules, and data. Our Business Renovation Approach [BRA] incorporates some fundamental principles already known in the business system planning, business process reengineering, and IS development environment: business rules and business activity meta-model, iterative development, simulation, and prototyping.
This approach is a radical departure from traditional decomposition approaches to IS development. It exploits "contingency theory" and some advanced ascertaining of the existing business rule approaches (Ross, 1999; Haggerty, 2000; Presley and Liles, 2001; von Halle, 2002; O'Regan and Ghobadian, 2002; Perkins, 2002). In the context of technology investment, contingency theory would suggest that, while technology and organizational practices (such as BPR) may have separate impacts on performance, the two together may also affect performance significantly (Devaraj and Kohli, 2000).
In other words, the impact of information technology [IT] on business performance is contingent on whether organizational processes (such as business renovation) were also implemented. Specifically, doing more of business renovation increases the return of investing in IT. In terms of BRA, IT and business processes are viewed as complementary factors; they must be changed in a coordinated manner to improve performance. BRA uses abstraction approach focused on business processes, business rules, and data in a system from which all knowledge of the business derives.
The BRA planning, development, and implementation process, as seen from the developers' point of view, can be divided into several iterative development phases, as follows:
- Strategic Business Renovation [BR] planning,
- Business process renovation and IA development, and
- IS/WF development and implementation
The fundamental constructs of phases are exhibited in Figure 3. The standard data-flow technique is used to present different phase activities, data flow among inputs, activities, outputs, and typical external entities, along with the most important business renovation approach results.
Figure 3: Business Renovation Approach: phases and results
4.1 Strategic Business Renovation planning*/ ?>
The first task of management and specialists in a process of business process renovation and IS development is to establish the strategic plan that should be closely integrated into the business objectives of the organization (company) -- a plan that achieves the balance between the various demands made on the company resources. The top-down planning process begins with an analysis of the company's goals and objectives, its strategies, and critical success factors [CSFs], determining core or critical business processes [CBPs] and the information infrastructure required to support these.
Strategic planning implies an attempt to alter a company's strength relative to that of its competitors, in the most efficient and effective way. Strategic planning focuses on the direction of the organization and the actions necessary to improve its performance (O'Regan and Ghobadian, 2002). In this process we recognize the (extended) critical success factor [CSF] approach as a beneficial concept and method for companies operating in a dynamic environment with rapidly-changing customer needs.
The CSF approach was developed initially by Rocard (1979). Critical success factors are those few things that must go well to ensure success for a manager or an organization, and therefore, they represent those managerial or enterprise areas that must be given special and continuing attention to bring about high performance (Boynton and Zmud, 1989). The CSF concept and method has received a wide acceptance among business and IT professionals and is employed in a variety of organizational contexts.
Researchers recently demonstrated that the CSF concept is interpretive in character and as such it may be employed for research on the system development process (Butler and Fitzgerald, 2002). In our extended CSF approach, which is derived from Pareto's Law (the philosophy of the "80/20"), the CSF method of strategic control (van Veen-Dirks and Wijn, 2002), and some ascertaining of the business rule approach, the first steps are to establish the goals and objectives of the company as a whole, and to determine its business strategy.
The next step is to generate the critical success factors required to realize this strategy. This is done by eliciting critical information set from the top management and the key staff. The data obtained from the interviews and other sources is further refined and prioritized through group sessions during which the core business processes [CBPs] and key performance indicators [KPIs] are agreed. Core business processes are those with the highest total impact on the level of performance and which are deemed, by management team opinion, essential to fulfill the mission, goals, and CSFs of the company. Through KPIs such as stock and staff turnover, assets utilization, and waste factors the company can define higher return opportunities. A comparison of the KPI's actual value with the benchmark value may result in changes of the strategy.
The strength of using CSFs is that they provide the important link between the business strategy, business process renovation strategy, and the information system development strategy. To be able to establish this link, the extended CSF approach recognizes and determines two distinct results: the key information requirements of top executives, and business rules or business statements relating to overall business (Global rules). Information requirements and global rules should be written in business language. They should be concise and clear. They should state business requirements, not system requirements (Perkins, 2002). All these results are captured in the rule repository and are used in next phases of the Business Renovation [BR] approach.
4.2 Business Process Renovation and Information Architecture Development*/ ?>
First, in the business process renovation phase, a re-engineering strategy is applied that critically examines, rethinks, and then redesigns current business processes, practices, and rules. The methods of business renovation, which combine business process modeling and simulation modeling enabling quantitative estimations of alternative renovated business processes (Bhaskar et al., 1994), are one of the possible approaches to addressing the above-mentioned problem of the evaluation of alternative solutions. Nowadays, e-business renovation strategies focus on the processes between business partners and the applications supporting these processes. These strategies are designed to address different types of processes with the emphasis on different aspects (Kalakota and Robinson, 2001): customer relationship management, supply chain management, selling-chain management, and enterprise resource planning.
Many different methods and techniques can be used for modeling business processes in order to give an understanding of possible scenarios for improvement. IDEF, eEPC, Petri Nets, System Dynamics, Knowledge-based Techniques, and Discrete-Event Simulation are only some examples of widely used business process modeling techniques. The increasing popularity of business process modeling results in a rapidly growing number of modeling techniques and tools. This makes the selection of the proper tool very difficult.
Simulation modeling is being widely used in manufacturing, as well as in areas such as health care, the service industry, network communications, traffic modeling, and the military. The simulation of business processes is suggested for use in Business Renovation [BR] projects as it allows the essence of business systems to be understood, the processes for change to be identified, process visions to be developed, new processes to be designed and prototyped, and the impact of proposed changes on key performance indicators to be evaluated (Greasley and Barlow, 1998). The reasons for the introduction of simulation modeling into process modeling can be summarized as follows: simulation allows for the modeling of process dynamics, the influence of random variables on process development can be investigated, re-engineering effects can be anticipated in a quantitative way, process visualization and animation are provided, and simulation models facilitate communication between clients and an analyst. The final reason for using simulation modeling is the fact that it can increasingly be used by those who have little or no simulation background or experience.
Process modeling tools must be capable of showing interconnections between the activities and conducting a decomposition of the processes. These tools must help users to conduct 'what-if' analyses and to identify and map no-value steps, costs, and process performance (bottleneck analysis). They should be able to develop AS-IS and TO-BE models of business processes, which represent both existing and alternative processes. They must be validated and tested prior to implementation. They can be used to predict characteristics that cannot be directly measured, and can also predict economic and performance data that would otherwise be too expensive or impossible to acquire.
During the analysis, a simulation of the AS-IS model is performed to reveal the actual time spent and the costs of the process activities. The AS-IS model is developed in several iterations. In each iteration the model is validated against the real process in the sense of process flow by following several process executions, and in the sense of performance by comparing times obtained in the simulations to average times measured for the entire process and its segments. The final AS-IS model is reasonably close to the actual process; with some minor discrepancies resulting from the fact that not all real situations can be anticipated and modeled. Finally, a TO-BE model is developed and its efficiency is analyzed.
The experience of a team member helped significantly in this phase of the modeling. The main difficulty in business process modeling is to develop a model that represents the process as it is, since employees usually cannot agree upon how the work is carried out -- particularly in cases such where the process is not well defined. Another difficulty is the determination of the time required to perform each activity, since employees are inclined to overestimate or record the largest execution times. Also, the level of detail had to be made uniform for all segments of the process and the number of transactions had to be determined. Some organizations have a tendency to over-analyze existing processes (analysis paralysis).
During this project phase (in the second step) the information architecture is defined. Information architecture [IA] is the planning, designing, and constructing of an information blueprint that covers the business process rules on the activity level and satisfies the informational needs of business processes and decision-making. It is derived from the TO-BE business process model and the strategic business process renovation plan orientations. This plan is developed in the strategic planning phase. IA calls for a full recognition of the importance of business rules and data in the design and development of information systems -- a perspective that exhibits a balance between processes and data.
The results of the business renovation and information architecture development phase are a company's TO-BE business process model (Process Architecture), global data model (Data Architecture), and technological/organizational foundations. The business process model consists of a profile of major business activities performed, how are they triggered (business events), how they flow in a sequence and how are they executed (business activity rules), and finally the data that is transferred from one activity to the next.
Process modeling is a necessary prerequisite to the data modeling and needs to be iterative, with well-defined deliverables. Here, and also in the further development of information architecture, the "80/20 rule" is used. Determination of the global data model (or data architecture) is the next step in information architecture development. Global data model is presented as an entity-relationship model containing the company's major data entities and business rules in between them. It reflects the global information needs of the company.
Mapping between process and data architecture is recommended (Ohren and Borgen, 1999). This step is carried out by analyzing each activity of the business process model. The information needs for each business activity are defined, according to related activity rules. Data objects that contribute to the information needs are identified and assigned to the process model activities. This step is likely to uncover shortcomings in the global data model, and the analyst should therefore iterate between process and data architecture.
Technological foundations refers to the computer hardware, software, communications network, development tools, and application solutions and workflow tools by which computing and information resources run; these too are developed. This platform also addresses the company's organizational foundations and the question: "how do we organize business processes and IS resources to be best fitted to the company's business strategy?"
4.3 IS/WF Development and Implementation*/ ?>
In the phase of IS/WF development we presume that the company's TO-BE business process model and the global data model developed in the previous phase contain its major business rules and information needs, and thus is a suitable foundation for further development activities. Those activities depend on the company's IS/WF development and implementation strategy.
In the case of the proprietary (own) development, the activities are concerned with the conceptual data modeling and the logical database design. The final results of this stage are a database and application solutions developed for the particular selected application area or company's business process. The database is created based on determining the conceptual, logical, and physical parameters, with database functional enhancement through constraints, triggers, and stored procedures derived from a company's business activities rules.
Prototyping is a design technique that we use when we uncertain about the real requirements for a new system (Haggerty, 2000). It is also a technique that recognizes that IS development is an iterative evolutionary process, that developers cannot always foresee and understand all sides to a problem, and that the end users cannot always completely express their information needs. Prototyping is in a context of conceptualization used as designer's vehicle for testing ideas, determining receptions, testing decisions, and verifying the quality of final, developed data base and application programs.
In the context of prototyping, a special emphasis must be put on the process of heuristic data and business rule analysis and on the role of end-users in this process. The final results of heuristic analysis are knowledge and user experiences captured in the rule repository, data base, and application software (prototyping) solutions. New interactive computer aided software engineering tools [CASE] have become available not only to enable design and evolutionary development of the database and related application software solutions but also to change the business rule repository as our understanding of rule-extended development techniques evolves.
On the other hand, Enterprise Resource Planning [ERP] application solutions and other modern-designed software packages are seen in this phase as one of the most recently-emerging process-oriented tools that can enable and implement business renovation. Before a software selection process begins, it is critical to develop an implementation strategy and important that management realizes how existing strategies, business processes, and supporting systems compare to what they could be with the new system environment.
In this context, we recognize our TO-BE business process model and business rule repository as the starting point of an ERP implementation process. The second condition or starting point presents the existing (reference) ERP process model. Comparing both models and related business rules, we check the degree of match between our way of doing business and the standard practices embedded in the software package. Research shows that even a best software package can meet only 70 percent of the organizational needs (Al-Mashari, 2001). We have to change our business processes (TO-BE model) to conform to the ERP solution or customize the software to suit our needs. The first case leads to higher degree of standardization but also to inflexibility and possible lower business competitiveness. ERP customization is, on the other hand, related to enormous implementation costs and project uncertainty.
In either of those cases, the BR team should make another iteration on the business process design in the TO-BE model (Butler et al., 2000). Iterations between the TO-BE model and the reference ERP model should continue until the most acceptable solution is reached. This solution is one that will achieve business benefits and can also have its IS support requirements met.
The redesign of business processes and the implementation of application program solutions can best face the challenges of today's ever-changing business environment. The rapid and constant changes that are very common in today's business environments affect not only the business itself, but also its supporting applications. As a result, information systems require constant change, renovation, and adaptation in order to meet actual business needs. Thus, a continuous business rule management environment is required in which each business rule instance can be traced from its origin through to its implementation. In IS/WF maintenance, such a link is essential since it provides information on the software modifications required in response to changes in business policies, organizational tactics, external laws, regulations, etc.
In this paper we introduced a business process activity meta-model and a business rule-transformation approach to business renovation as a framework that employs an enterprise-modeling method for business rule elicitation, specification, and business rules refinement in the business renovation process. In practice, some organizations have a tendency to over-analyze their business process, which leads to questions like "What are the benefits of our business modeling?" "Why did we spend years charting and analyzing business processes?" and "Why did the IS implementation project still fail?" We understand that business process models are static models. The behavior of process over time is not clearly identified. But we believe that most of the answers to these problems lie in the obscuring of human work practices that occurs during business process modeling (i.e., Crabtree et al, 2001), and in the appropriate rule-transformation approach. These areas are the subjects of our future research.
Al-Mashari, M., Irani, Z., Zairi, M. (2001), "Business process reengineering: a survey of international experience," Business Process Management Journal, Volume 7, No. 5, pp. 437-55.
Appleton D. S., (1984), "Business Rules: The Missing Link," Datamation, October 15, pp. 145-150.
Avison D.E. and Fitzgerald G. (1988), Information Systems Development: Methodologies, Techniques and Tools, Blackwell Scientific Publications, Oxford.
Barnes, M. and Kelly, D. (1997), "Play by the Rules," Byte (Special Report), 22(6), pp. 98-102.
Becker J. M. Rosemann and C. von Uthmann (2000), "Guidelines of Business Process Modelling," in W. van der Aalst et al. (Eds.), Business Process Management, LNCS 1806, pp. 30-49.
Bhaskar R., Lee H.S., Levas A., Petrakian R., Tsai F. and Tulskie, B. (1994), "Analysing and Reengineering Business Processes Using Simulation," Proceedings of the 1994 Winter Simulation Conference, Lake Buena Vista, Florida, 1994, 1206-1213.
Boynton A.C. and Zmud R.W. (1989), "An Assessment of Critical Success Factors," in Shoof W. H. (Editor), The Management of Information Systems, Orlando, Florida: The Dryden Press,
Bosilj Vuksic V., M. Spremic and A., Kovacic (2001), "Managing Change Toward E-Business Era: Slovenian and Croatian Perspectives," Proceedings of the 8th Slovenian Informatics Conference, Slovenian Society Informatika, Portoroz, Slovenia, pp. 12-27.
Bubenko J.A. jr. and Wangler B. (1993), "Objectives driven capture of business rules and of information systems requirements," Proceedings of International Conference on Systems, Man and Cybernetics. 'Systems Engineering in the Service of Humans,' pp. 670 -677 vol.1.
Butler K.A., A. Bahrami, C. Esposito, R. Hebron (2000), "Conceptual models for coordinating the design of user work with the design in information systems," Data&Knowledge Engineering, Vol. 33, pp. 191-198.
Butler T., B. Fitzgerald, "Unpacking the systems development process: an empirical application of the CSF concept in a research context," The Journal of Strategic Information Systems, Vol.8, Issue 4 December 1999, pp. 351-371.
Chen M. (1999), "BPR Methodologies: Methods and Tools," in: Elzinga D.J. et al. (Ed.), Business Process engineering, Kluwer Academic Publishers, Massachusetts, pp. 187 - 212.
Crabtree A., M. Rouncefield and P. Tolmie (2001), "There's something else missing here: BPR and the Requirement Process," Knowledge and Process Management, Vol. 8, No. 3, pp. 164-174.
Curtis G. (1989), Business Information Systems: Analysis, Design and Practice, Addison Wesley Longman, Inc.
Date C. J. (2000), What Not How: The Business Rules Approach to Application Development, Addison Wesley Longman, Inc.
Davenport T. H. (1993), Process Innovation: Reengineering Work Through Information Technology, Harvard Business School press, Boston, Mass.
Devaraj S. and R. Kohli (2000), "Information Technology Payoff in the Health-Care Industry: A Longitudinal Study," Journal of Management Information Systems, Vol. 16, No. 4, pp. 41-67.
Diaz O., J. Iturrioz and M.G. Piattini (1998), "Promoting business policies in object-oriented methods," The Journal of Systems and Software, Vol. 41, pp. 105-115.
Do Prado Leite, J.C.S., De Sao Vicente, R.M. and Leonardi, M.C. (1998), "Business rules as organisational policies," Proceedings of Ninth International Workshop on Software Specification and Design, pp. 68-76.
Dobson, J. (1992), A Methodology for Managing Organisational Requirements, University of Newcastle upon Tyne, Newcastle, UK.
English L.P. (1998), Advanced Data Modelling, Information Impact, Grimsce, Slovenia
Green P. and M. Rosemann (2000), "Integrated process modelling: An ontological evaluation," Information Systems, Vol.25, pp. 73-87.
Gottesdiener E. (1997), "Business Rules Show Power, Promise," Application Development Trends, 4 (3), pp. 36-42.
Gottesdiener E. (2000), "Business Rules Rule Requirements," Business Rules Journal, Vol. 1, No. 12, (Dec. 2000), http://www.brcommunity.com/a2000/b051.html
Greasley, A. and Barlow, S., "Using simulation modelling for BPR: resource allocation in a police custody process," International Journal of Operations & Production Management, Vol. 18, No. 9/10, 1998, 978-988
Grover V., S. R. Jeong W. J. Kettinger and J. T. C. Teng (1995), The implementation of business process reengineering, Journal of Management Information Systems, 12:1, pp. 109-144.
Haggerty N. (2000), Modeling Business Rules Using the UML and CASE, Business Rules Journal, Vol. 1, No. 10, (Oct. 2000), http://www.brcommunity.com/a2000/b016.html
Hammer M. and J. Champy (1993), Reengineering the Corporation, Harper Collins Books, New York.
Hay D. and Healy K.A. (1997), GUIDE Business Rules Project, Final Report -- revision 1.2, GUIDE International Corporation, Chicago. Now available from the Business Rules Group as Defining Business Rules ~ What Are They Really? 4th ed. (July 2000), available at www.BusinessRulesGroup.org
Herbst H. (1996), "Business Rules in Systems Analysis: A Meta-Model and Repository System," Information Systems, 21 (2), pp.147-166.
Herbst H. (1997), Business Rule-Oriented Conceptual Modelling, Heiderberg, Physica.
Jacobson I. (1995), The Object Advantage, Addison-Wesley, ACM Press Books.
Joosten S. M. M. (2000), "Why Modellers Wreck Workflow Innovations," in: W. van der Aalst et al. (Eds.), "Business Process Management," LNCS 1806, Springer, pp. 289-300.
Kalakota R. and M. Robinson (1999), E-Business: Roadmap for Success, Addison-Wesley, Reading.
Kelly K. (1998), New Rules for the New Economy, Penguin Putnam Inc., New York.
Knolmayer G, R. Endl, and M Phahrer (2000), "Modelling Processes and Workflows by Business Rules," in: W. van der Aalst et al. (Eds.), Business Process Management, LNCS 1806, Springer, pp. 16-29.
Kovacic, A. (2001), "Business renovation projects in Slovenia," Business Process Management Journal, Volume 7, No. 5, pp. 409-19.
Kovacic A., Krisper M., Groznik A. (2001), "Business Process Renovation: Rethinking toward e-business," Proceedings of the 7TH International Conference on Re-Technologies for Information Systems, Lyon, France, pp. 175-188.
Krallmann H. and Derszteler G. (1996), "Workflow Management Cycle," In: Scholz-Reiter, B., and Stickel, E., Business Process Modelling, Springer, Berlin.
Martin J. and Odell, J. (1998), Object-Oriented Methods: A Foundation, Prentice Hall.
Moriarty T. (2000), "Business Rule Management Facility: System Architect 2001," Intelligent Enterprise, 3 (12), August 2000.
Ohren O. and K. Borgen (1999), "Information requirement analysis in business processes," in: Evolution and Chalenges in System Development, ed., Zupancic et al., Kluwer Academic, New York.
O'Regan N. and A. Ghobadian (2002), "Formal strategic planning: Key to effective business process management," Business Process Management Journal, Volume 8, No. 5, pp. 416-29.
Perkins A. (2000), "Business Rules = Meta-Data," Proceedings of 34th International Conference on Technology of Object-Oriented Languages and Systems 2000: TOOLS 34, pp. 285-294.
Perkins A. (2002), "Business Rules Are Meta Data," Business Rules Journal,
Vol. 3, No. 1, (Jan. 2002), URL: http://www.BRCommunity.com/a2002/b097.html
Prasad B. (1999), "Hybrid re-engineering strategies for process improvement," Business Process Management Journal, Volume 5, No. 2, pp. 178 - 197.
Presley A.R and D.H. Liles (2001), "A holon-based process modelling methodology," Internation Journal of Operations & Production Management, Vol. 21, No. 5/6, pp. 565-581.
Rosca D, Greenspan S., Wild C.A., Reubeinstein H., Maly K. and Feblowitz M. (1995), "Application of a Decision Support Mechanism to the Business Rules Life Cycle," Proceedings of the 10th Knowledge-Based Software Engineering Conference, pp. 114-121.
Rosca D, Greenspan S., Feblowitz M. and Wild C.A. (1997), "Decision making methodology in support of the business rules lifecycle," Proceedings of the 3rd IEEE International Symposium on Requirements Engineering, pp. 236 -246.
Ross R. (1997), The Business Rule Book: Classifying, Defining and Modelling Rules, Second Edition, (Ross Method, version 4.0). Business Rule Solutions, Inc., Houston, Texas.
Ross R. (1999), "Exploring Business Rules," Business Rules Journal, Website revision, April 1999, available at http://www.brcommunity.com/a1999/a439.html
Sheer A.-W. (1999), ARIS-Business Process modelling, Springer, Berlin-Heidelberg.
Sheer A.-W. and Th. Allweyer (1999), "From Reengineering to Continuous Process Adaptation," in: Elzinga D.J. et al. (Ed.), Business Process engineering, Kluwer Academic Publishers, Massachusetts, pp. 1- 24.
Tanaka K. (1992), On Conceptual Design of Active Databases, PhD Thesis, Georgia Institute of Technology, Georgia.
Turban E., E. Mclean, J. Wetherbe (1998), Information Technology for Management, John Wiley & Sons, ISBN: 0-471-17898-5.
Valiris G. and M. Glykas (1999), "Critical review of existing BPR methodologies," Business Process Management Journal, Vol. 5 No. 1, pp 65-86.
van der Aalst W.M.P. (1999), "Formalization and verification of event-driven process chains," Information and Software Technology, Vol. 41, pp. 639-650.
van Veen-Dirks P. and M. Wijn (2002), "Strategic Control: Meshing Critical Success Factors with Balance Scorecard," Long Range Planning, Vol. 35, pp. 407-427.
von Halle B. (2002), Business Rules Applied, John Willey & Sons, Inc., New York.
Watson G. H. (1994), Business System Engineering, John Wiley&Sons, New York.
WfMC-TC-1011 (1999), Terminology & Glossary, Workflow Management Coalition Document Number WFMC-TC-1011, February 1999.
WfMC-TC-1016-P (1999), Process Definition Meta-Model&WPDL, Workflow Management Coalition Document Number WFMC-TC-1016-P, February 1999.
Youdeowei A. (1997), The B-Rule Methodology: A Business Rule Approach to Information Systems Development, Ph.D. Thesis, Department of Computation UMIST, Manchester, United Kingdom.
Yu L. (1996), "A Coordination-based Approach for Modelling Office Workflow," in: Scholz-Reiter B. and Stickel E., Business Process Modelling, Springer, Berlin.
# # #