An Operational Process Modeling approach for
ERP implementation
Rakesh Agarwal1, Bhaskar Ghosh1, and Manas Pattnaik2
1Infosys Technologies Limited, Near planetarium,
2
Software Technology Park, CRP square,Bhubaneswar, India
email: {rakesh_a, bhaskarghosh}@inf.com, manas@stpbhu.stpbh.soft.net
Abstract
The decision to purchase an enterprise resource planning (ERP) system is easy but it's effective use is difficult. Enterprise Resource Planning (ERP) have been broadly accepted due to the extensive and useful functionality they provide, even in those situations where the planning/decision support paradigm provided by the system poorly fits the business. The limitations of the ERP paradigm, i.e., redesigning work and assigning responsibilities, need to be clearly recognized if they are to be dealt with in an effective manner. This paper deals with an effective approach and methodology of integrating Cimosa Open System Architecture and operational process modeling by O3ML for effective ERP implementation.
1. Introduction
Conventional reengineering[1] has missed the most vital element that is the substance of effective change: i.e., business process. Business processes can be re-defined as interaction of people. This interaction can be made effective by using proper diverse level of process models.
General models of software development focuses on analyzing data flows and transformation. This modeling accounts only for the organizational data and that portion of the process which interacts with the data. Enterprise Integration[2] extends the computers use beyond transaction processing into process communication and coordination. Successfully integrating these systems into the enterprise requires modeling the manual organizational process into which these systems intervene. Three such applications[3] are identified:
The above three views share a growing requirement to represent the processes through which work is accomplished. Process representation becomes a vital issue in redesigning work and allocating responsibilities between human and computers. Process modeling is different from other types of modeling in computer science because many of the phenomena modeled must be enacted by a human rather than a machine.
Enaction is performed by human beings (may be distributed but have complex coordination) and computer based systems. Controls vary between humans and machines. However, the acceptability of a process model to human involved is a prerequisite to success. Three major process levels are possible in a process model: reusable modeling, project modeling and enactment. Figure 1 shows the interrelationship between these processes.
Figure 1: Three major process model
Many manufacturing companies are taking advantage of recent advances in software and hardware technology to install integrated information systems, called Enterprise Resource Planning (ERP). These systems can provide seamless and real-time data to all who need it. However, the tasks of selection and implementation of such systems can be daunting.
Cimosa (Computer Integrated Manufacturing-Open System Architecture) is an Open System Architecture[4] for supporting the development of systems throughout the whole systems life cycle and is synthesized from the experience of a wide range of manufacturing companies, manufacturing and information technology vendors and research institutions. The total Cimosa architecture identifies a possible future manufacturing system towards which the current systems can evolve.
Integration of systems concerns all phases of the system life cycle, from system inception to daily system operations. It also concerns managers, engineers and workers. Thus, enterprise-wide modeling[2], analysis methods, tools to support system design and implementation according to user requirements are definitely required for the implementation. To achieve full system integration a software layer is to be implemented over the heterogeneous operating systems which can provide a common shared platform on which different system components (i.e. information technology components, manufacturing technology components and human operators) can be interfaced through which they can communicate.
Operational [5][6] and evolutionary principles (Cimosa & ERP) can be brought together to form a powerful process modeling paradigm [7]. For this reason, the final system can be seen as the final step of an evolutionary transformation which enriches the initial abstract model with details and progressively turns it into the deliverable system.
This approach provides important benefits, such as,
In this paper we will discuss how Cimosa can be configured with O3ML (Operational Object-Oriented Modeling Language) [8][9] to provide for a suitable ERP implementation methodology for business process activities to be accomplished in a sequential manner. We give an overview of Cimosa followed by an overview of O3ML. Finally, we show how the process modeling principle (enacted by human) can be combined for having an operational process reengineering environment.
2. The O3ML Methodology
A significant number of object-oriented methods (Rumbaugh [10], Booch [11], ROOM [12], Shlaer & Mellor [13], Jacobson [14], Martin [15], Meyer [16], etc.) have been introduced during the past several years. These methods claim that object-oriented approach creates highly reusable and robust software. After studying the state-of-the-art methods, we found that there were certain limitations in using them when actually developing a software system. The drawbacks encountered are as follows:
On the other hand, classical control models, such as those based on finite-state automata, state charts and Petri nets, are by their very nature operational models. In fact, such modeling languages have intrinsic execution mechanisms, but they can only be used to represent the control aspects of a system.
These artificial discontinuities can be eliminated if a single modeling language is used which is operational [6][7]. The operational approach eliminates the scope and semantic discontinuities in the development process by using a single, integrated, formal set of modeling abstractions to create a given executable model.
It was to address these problems and provide advanced software architectural features, that O3ML [8] was devised. Combining the concept of Operational, OO and Modeling we get a modeling language which we refer to as Operational Object-Oriented Modeling Language (O3ML). Such a language is quite similar superficially with other programming languages but has some additional features by developing the models graphically [17] using high-level Nets[18] or hierarchical state machines (HSMs) [10].
The system or process being considered is represented by an application, which is basically a collection of interacting actors. Actors are the building blocks of the model; actors are instances of classes. Since the model may exhibit great complexity, an application is made modular by means of a number of architectural techniques, such as the decomposition of an application in sub-applications.
Applications are based on class-relationship diagrams establishing which classes and relationships between classes they can rely on. A relationship between classes is the abstraction of a particular kind of association that can be established between the instances of those classes. From the perspective of a given actor the presence of a relationship pertaining to its class determines the presence of a connector in the actor itself: owing to a connector an actor can interact with the other actors that are connected to it by means of the associations derived from the relationship. Through a connector an actor can send and receive events and, what is more, it can perform navigations and ask services of the connected actors.
If an actor is event-driven, its behavior is expressed by means of a high-level net[18]; if its nature is functional the actor provides services. However the net and the services are complementary aspects.
Figure 2 The model of the manufacturing cell
The application in Figure 2 shows a manufacturing cell consisting of 4 machines (M1, M2, M3 and M4), an input device (In1), an output device (Out1), an external supplier (Supplier) and two conveyor units (U1 and U2). Parts flow in the direction of the arrows. Each component of the cell is modeled by an actor. Actors are graphically represented by a square and have two labels: the actor name followed by the class name.
3. Steps in ERP Implementation
Different implementation methodology may have different number of steps [19]. We may not follow all the steps in the process but it is highly essential to have a structured approach. Project leaders must set out clear measurable objectives at the beginning of each process and review the process at intervals.
The number of steps that are essentially required are as follows:
Integrating environments: Based on the different steps in ERP implementation, Figure 3 shows how they interacts with different conceptual and operational tools.
Figure 3: Integration between Cimosa, O3ML and ERP
The meta process for implementing is composed of three cycles – Development of operational models, Simulation and Re-configuration of parameters. In addition there are three interfaces: User, tool and Building blocks repository . Using the three interfaces:
The overall functionality of the meta process is as follows:
Figure 4: Coordinating various activities in meta process
4. Conclusion
The paper provides a view for highly incremental operational process modeling environment for implementing[9] ERP.
The aim of this work is twofold. On the one hand, Cimosa can really be put into practice because there are tools that support it and, what is more, they allow Cimosa models to be validated through simulation and graphical animation using O3ML. In addition, they provide object-oriented structuring mechanisms that allow analysts to build reusable models[7]. On the other hand, the cooperative tools themselves can take advantage of a methodology that guides developers in building models in cooperation which are easier to understand and that is likely to have a broader scope than the initial one.
5. References