Business Process Reengineering and Software Agents Development

In the paper it is assumed that Business Process Reengineering (BPR) is the prerequisite and consequence of new software and Information Technology (IT) solutions implementation. Process reengineering includes process modelling as well as roles, rules and information modelling. In the paper the main question is if agent methodologies are BPR-oriented. Analysis includes the current multiagent methodologies like AAII, Gaia, MaSE, Comparative Information Agent Design, ADEPT project, MAS-CommonKADS, CoMoMAS, DESIRE and Cassiopeia. 1 The Move to Business Process Reengineering (BPR) Organisational theorists propose that the organisation of the future will be networked across functions and designed around business processes rather than functional hierarchies [22], [14], [5]. BPR is now being offered as a paradigm of organisational change necessary in order to achieve the required flexibility and competitiveness of the networked organisation [20]. BPR is a strategy-driven organisational initiative to fundamentally re-examine and redesign business processes with the objectives of achieving competitive breakthrough in quality, responsiveness, cost, satisfaction and other critical process performance measures [36]. While business processes can be reworked without Information Technology (IT), recent technological advances have placed greater importance on IT as an enabler of BPR. Increasingly, BPR is being deployed in tandem with the use of IT to revamp or overhaul existing business processes that limit effectiveness. Technologies such as Local Area Network (LANs), client-server architecture, Electronic Data Interchange (EDI), Executive Information Systems (EIS) and Decision Support Systems (DSSs) are some examples of IT which now allow firms to achieve performance gains in the communications dimensions of business processes. The emerging technologies of video/teleconferencing, GroupWare, image processing and workflow technologies are enabled by BPR and by reducing or replacing manual tasks and improving communication. Legacy systems already in place must be selectively destroyed and replaced by cross-functional systems that allow many departments to share a single data warehouse or utilize data simultaneously received form different sources. BPR has been defined as the restructuring of organizational processes through the innovative use of information systems and technology. Reengineering is about rejecting the conventional wisdom and received assumptions of the past. Reengineering is the search for new models of organization work [15], [7]. BPR requires changing the basic assumptions and principles of management, re-examining the nature of processes and creating changes of magnitude through innovation. 2 Processes and Role-oriented Methodologies for BPR Business processes are considered as goal-directed, socially coordinated activities, established through social actions. A process as a flow of activities is to produce an output of value to recipient. Each process can be viewed as an exchange of services embedded in a recipient-supplier relationship. The recipient (customer, client, patient) requests the desired output whereas the supplier performs the process. The process’s activities are the means to transform process input (materials, information) into the desired output. During its performance the process changes states, which are triggered by events. The process flow is determined by business rules (conditions). Although a process can be viewed on different levels of abstraction, depending on the domain of an analysing person, each process follows these outlined principles. Most manufacturing and some office processes are treated as simple and mechanistic. They are modelled as linear, sequential and repeatable series of activities. These processes are interpreted as manipulation of physical objects and controlled flows of tasks e.g. inventory control, manufacturing scheduling, office automation, transaction processing. However upper and top management processes that include knowledge management and lead through idiosyncratic decisions made individually or in groups to unique values, are much more complex and requiring new IT tools and software agents for information searching and processing. For example managers take up normatively regulated interactions and they seek to reach understanding about the problem or situation in order to coordinate their actions by way of cooperating processes of interpretation, argumentation and agreement e.g. problem identification, diagnosing, solving management and strategic problems by boards, groups or communities, defining organizational mission, goals, policies and strategies. Supporting BPR practitioners requires models that can be used to describe the processes to be redesigned. In BPR functionality specification has originally come from Yourdon [37], Coad and Yourdon [4], and Rumbaugh et al. [27] analyses. The business models should be aimed at depicting cross-functional business processes. The models are to give a basis for simulation of the existing processes and proposed re-engineered processes [12]. The purpose of any software requirements technique is to understand and document the needs of the user and the external behaviour of the solution. Software requirements engineering includes two primary groups of activities: problem analysis and requirements specification. Problem analysis is the activity of learning all aspects of the problem domain so as to determine how best to solve a specific set of user needs. Problem analysis is essential for any system development for which the problem being solved is not totally self-evident. Requirements specification is the activity of documenting in a software requirements specification (SRS) the expected external behaviour and external characteristics of a system that solves the problem [8]. "Expected external behaviour" means a description of all inputs to the system all outputs from the system and all the possible mapping relationships between the inputs and outputs [8]. Although requirements engineering is for software design it is difficult to distinguish the activities undertaken in the name of BPR from systems' implementation. This was due to the origins of many early BPR enthusiasts. Information technology was regarded as the "enabler" for BPR [24]. BPR efforts were launched to prepare the ground for more effective software implementation. The supporters of ITbased BPR often take one view, that the "systems is the solution" [24]. However, it is simply not good enough to spend money on new technologies and then to use it in the same old way. Therefore the solution is in the problem analysis. According to Butler [2] a model for BPR should include development of vision and objectives, identification of processes for redesign, understanding and measuring existing processes, pilot/trial new process, developing supportive solutions, making new processes operational and continuous process improvement. So researchers like Butler, Davenport underlies the need of analysis of legacy processes, simply audit of them. Next they opt for modelling a new activities [7]. This analysis is believed as necessary although the important goal of reengineering is to radically free information systems from the past organizational structures. Many researchers emphasize that BPR methodologies should cover not only activities (what?) modelling but also roles (who acts?). According to Hawryszkiewicz model of business processes includes artefacts, roles, actors, environments and tasks specifications [16]. Artefacts are representation of organization’s information base including files, reports, and designs. The artefact includes data values. Roles are abstract entities that represent system decisions. An actor is assigned to each role to make the decisions. Actors are often positions that can be derived using organizational rules. Roles are not permanently associated with positions but are dynamically assigned using organizational rules. A person can have thus many roles and there is nothing to prevent a person from transferring knowledge between roles as often happens in organizations. Environments provide the support structures for workgroups. Environments can be of prolonged duration and support a variety of processes each composed of tasks and roles. These processes can combine the tasks objects and roles into workgroup procedures. Environments can include other environments, as well as tasks, roles and data. An environment must include at least one role and usually covers one workgroup. Tasks represent a complex transactions or simple work tasks such as editing a document. Similarly Walford wrote about the need of rules, roles, dialogs, workflows specification for business process redesign and implementation [31]. Business rules are statements that articulate an operating principle by defining or constraining some aspect of the business. The strength of a rule is the rigor with which the rule needs to be followed. In that regard rules can be classified into requirements, standards, guidelines. Business rules as applied to processes are of particular interest in the context of the process life cycle. So business rules are constraints on the business processes or their relations. Business rules also can be applied to different aspects of a process and its implementation, including the flow control of the process, the functionality required by the process, the data used in the process, and the assignment of human performers to the process. According to Walford a role is an unordered set of cohesive activities. It is defined by the collection activities assigned to it. By that definition, a role is passive and because of that, there must be some mechanisms for the animation of a role. In this case animation means causing the activities defining a role to occur. The mechanism for animation is through the use of a role performer. Walford introduced to proc