ERP AND WORKFLOW SYSTEMS
Do they work together?
Hans Wortmann & Nick Szirbik
University of Groningen, Faculty of Management and Organisation, Information Systems Cluster, PoBox 800, 9700 AV Groningen, The Netherlands
Abstract. This paper discusses the strengths and weaknesses of ERP and WfM systems for the purpose of management and execution of business processes. WfM systems are based on an explicit model of business processes, and they facilitate business process management. However, it is not always easy to describe all exceptional situations in an explicit way. Therefore, WfM systems may become cumbersome. Moreover, such systems assume independence of individual cases, which is seldom realistic. ERP systems lack an explicit model of business processes, and therefore it is impossible to manage business processes. However, execution of business processes is a strong point of ERP systems because the implicit business process description is an efficient way to handle exceptions. The paper investigates various ways in which ERP and WfM systems can be combined. Currently, such combinations are only workable if the granularity of WfM systems is constrained: individual actions in a WfM system should cover a complete transaction in ERP systems (or other transaction processing systems). This insight explains why WfM systems are more and more associated with Enterprise Application Integration suites. However, from a business process point of view it is illogical to have the workflow granularity determined by the accidental boundaries of transaction processing systems. Therefore, combining ERP and WfM with current state-of-the-art technology may lead to disappointing results.
Key words: ERP, Workflow Management Systems, Enterprise systems integration
1.
INTRODUCTION
All organizations need in their Enterprise Information Systems some form of transaction processing, i.e. recording their value-adding activities, as well as changes in ownership and contracts. Many organizations employ
dedicated legacy applications for transaction processing, but more and more organizations choose for ERP packages to satisfy this need. ERP packages are in two ways different from dedicated transaction processing applications. First of all, they are designed to achieve a high degree of data integration in Enterprise Information Systems. For this reason, they are often called: data-centric applications. Second, ERP packages are standard software packages, and therefore highly parameterized.
ERP packages contain “embedded” business process knowledge. However, these packages are not able to represent (parameterised) business processes explicitly, in a natural way1. Therefore, the ERP packages (just as other legacy transaction processing applications) fail to provide tools for managing such business processes. This paper analyses ERP packages and provides arguments for these statements.
Workflow management applications are often positioned to solve this problem of business process management. Especially within an EAI (Enterprise Application Integration) software suite, workflow management solutions are considered a key ingredient. However, it is not easy to integrate workflow management applications with data-centric applications, especially when resources have to be shared in a business process. Workflow management is designed to focus on the single case (or process instance), and all the resulting interference between cases (such as in sharing resources) leads to problems. This occurs even when merely managing persistent data. Therefore, an integration of workflow management with legacy transaction processing will not provide a satisfactory solution for integrated data management and a fortiori not for resource management. The paper provides examples of the problems that may occur.
There is rather scarce literature about the paradoxes of ERP and WFM integration. Some authors [Cardoso et al, 2004] herald (a bit too early in our opinion) a “new era” of integration and offer two kinds of solutions. One approach is to integrate persistent data with the workflow. This persistent data is describing the (workflow) case. The question to be investigated is how these persistent data relate to other persistent data, e.g. as maintained in ERP. The other approach is to view the WFM as an EAI application that binds explicitly together several ERP modules and systems (which each may have their own persistent data and processes). Our paper critically investigates both these proposed solutions and discusses the current achievement and trends in the ERP/WFM supplier area.
The structure of the paper is as follows: in the next Section, we first focus on management and execution of business processes and on ICT-support for 1
As we will explain later in this paper (Section 4), it is possible to represent business processes after parameters have been given values in a particular implementation. However, this is based on reverse engineering and introduces redundancy
these tasks, as provided by WfM systems. Next, in Section 3, we characterize transaction processing systems and more specifically ERP systems. Here we discuss the management and execution of business processes in ERP. We conclude that both WfM and ERP have their drawbacks in management and execution of business processes. In Section 4 we investigate the possibility to use WfM as a “front-end” for ERP. The investigation shows that this option cannot be recommended.
In Section 5 we present some of the possibilities to use WfM in combination with other integration technology to integrate several ERP systems (and other transaction processing back ends). This option looks more promising, but covers only a small fraction of the (real) business processes. Therefore, the paper concludes overall, that more research is needed if advantages of ERP and WfM are to be kept and drawbacks are to be avoided. Section 6 concludes the paper.
Throughout the paper we will use a simple business process as an example, viz. customer order acceptance. This example is introduced now and described in detail in section 8 (Appendix).
2.
MANAGEMENT AND EXECUTION OF
BUSINESS PROCESSES AND ICT-SUPPORT
2.1
Introduction to the example
Consider the following simplified example (detailed in the Appendix). A company has a customer order entry process, which proceeds in two phases. First, there is a customer request for delivery of a catalogue product, which is replied by the company with either a quotation or a decline. In case of a decline, the process ends. Otherwise, the process proceeds with the second phase: if the customer accepts the order, there is an actual delivery followed by a notification of acceptance by the customer. For the sake of simplicity of the example, we shall assume that orders consist of only one order line. Moreover, we assume that orders are to be delivered immediately from stock; in other words, we do not consider problems of future delivery. Below, we will first characterize WfM systems in Section 2.2. The main point about these systems is that they are concerned with cases, which are assumed to be independent. In Section 2.3, we will use the above example to illustrate the notion of independence. The findings are generalized in Section 2.4. Section 2.5 concludes that business process management through work flow systems becomes easily conflicting with management of persistent data.
2.2
WfM systems for management and execution of
business processes
As said, the simplified example is described in more detail in the Appendix. Simplified examples serve to illustrate the points made in reasoning. However, simplified examples have the drawback, that they are unable to show the complexities of reality. In business process modelling, one of the nasty complexities of reality lies in the fact that there are usually many exceptions. In other words, the example described in the appendix would in reality be (much) more complex. This would lead to much larger models, which easily become incomprehensible. In general, business process models can be designed for an organisational purpose, such as business process redesign, in which their purpose is to support communication between humans. Such models should be kept simple. Alternatively, models can be made to support automated management and execution. Such models should be complete. Experience learns that complete models difficult to design and maintain with current are in practice modelling techniques.
Process
New cases Past cases
database
Figure 1. Workflow application (high level)
We start now by a high level description of the typical workflow application. Work flow management systems contain a general description of a business process, which can be depicted in a graphical way. The graphical language in which business processes are expressed are often based on Petri-nets. In Petri-nets, activities are called transitions, and they are always connecting two different states (called places). Workflow languages allow a precise description of the activities which are defined in the business process, as well as of the parallel paths and sequence constraints which are applicable. For an illustration of such a description (or model), see the Appendix. A high-level architectural view is given in figure 1.
Here, the workflow system supporting a business process is depicted as a “black box” containing the activities and their precedence/parallelism relations within the process and identify what “a case” represents. The business process is instantiated for individual cases. The instantiated business process consists of activities, which may have to be performed for each individual case. In a (coloured) Petri net-like illustration, the cases will arrive in an input place (see figure above) and will finish in an “end” place. Persistent information about the running (and past) cases can be kept in a database linked to the workflow engine. For a general architectural description of work flow systems, also in relation to each other. Cf. figure 2 (taken form the workflow management coalition – see at www.wfmc.org).
Process Modelling tools WF enactment system engine Administration
& monitoring enactment Other WF
systems
Other software WF Client
applications
Figure 2. Architecture of WfM systems
The main observation, which we want to make about the WfM approach is that each case has to be independent. This means that the cases each hold their own data. When data from the environment of the case are needed (e.g. due to joint resources or to data sharing). Therefore, the information in the database about resources, and their assignment to the roles that fulfill the activities is static. Also, other restrictions (e.g. an active case cannot modify
the persistent data of another running case) stem from the strong assumption that active cases are independent from each other.
In the example introduced above, this notion of “independence” can be illustrated as follows. In phase one, a number of checks are performed before a customer’s request can be replied by an offer. If any of these checks fails, the order is refused. These checks are e.g.:
• The check whether the customer is known and accepted as a debtor
• The check whether the debtor’s credit limit has been reached
• The check whether sufficient material is in stock.
In phase two, the workflow logic has to assume that some of these checks still hold true. For example, it assumes that the customer object is still present in the database. If the customer object would be removed from the database after phase one, the workflow system might not be able to end properly in phase two. In this situation, the case is not independent.
Thus, “independence of cases” means that each case can control it’s own (persistent) data. However, it is a rather strong assumption that cases are independent in reality. Of course, it can be debated whether (in reality) a customer can be removed from the database while there is still an order entry case in process. However, other persistent data (such as a the credit given to a debtor) is clearly the result of several individual cases. In other words, these cases are not independent.
2.3
Management and execution of business processes
A business process represented by a work flow model can be executed by the workflow engine, This engine interprets the model and keeps track of the state of each case (i.e. the states reached in relation to the case and the activities which are “enabled”, i.e. can start next).
How can a workflow system be used to manage a business process? As an example, we will investigate how it can be linked to a planning application which has to allocate scarce resources to business process instances? In a rather naïve way, this can be achieved via the database (see figure 3 below). In this case, the previous assumption that “the data about resources is static” does not hold, because the planning process continuously changes this data. To make matters worse, in practical situations there is a separate process of resource management that affects (albeit in a different way and with a different rate) the same data. Therefore, we must conclude that (joint) planning of business processes will easily conflict with persistent data management requirements.
Process Extended database The Planning Process Resource mgt.
Figure 3. Workflow management linked to planning
The solution to avoid a collapse of the cases flow is to decouple the planning data and the flow data, as is it done in hospitals, where for example long term planning of nurses does not affect the patients flows. This creates a dual planning system, with no links between tactical planning and operational planning In manufacturing, a similar situation occurs often in repair and refurbishment2. However, this “solution” introduces new problems. For example, a planning system where tactical planning does not have an impact on operational planning (and vice versa) is probably not optimal3. Moreover, figure 3 is just a crude simplification; in real life complex situations there are more processes, more databases and more (distributed and loosely coupled) planning units.
2.4
Generalisation
In the previous subsection, we have analysed a particular aspect of business process management, viz. the planning aspect. However, there are many other aspects in business process management and execution, for
2
A previous study investigates some cases in this area (see [Szirbik & Wortmann, 2004]).
3
In typical environments where tactical plans regulate the flows, choices are regarded as mere exceptions and the planner tackles these by inserting some slack in the plans. However, feedback from operational decisions and progress is nearly always desired in planning applications.
which a similar line of reasoning can be followed. For example, if resources are not planned, but merely employed in execution, the same argument on resource sharing can be given as in figure 3. Also, if cases happen to be processed in one or more activities in batches, or if cases share data related to the case owner, we run into the risk that persistent data management is conflicting with business process management.
2.5
Intermediate conclusion
WfM systems are appropriate to support management and execution of business processes. However, they assume mutual independence of cases, and this assumption in seldom true. Therefore they are likely to conflict with persistent data management requirements. Moreover, experience learns that it is difficult to describe business processes completely in a work flow model. In particular, processes with many exceptions are difficult to capture.
3.
HOW ERP SYSTEMS CONTAIN BUSINESS
PROCESS DEFINITIONS
3.1
Discussion
Both ERP and WfMs contain highly formal process definitions. In the case of the WfMs, this statement is straightforward, because these systems are “programmed” by using business process models. The process description is explicit (in a process modelling language as YAWL for example, see [vd Aalst and ter Hofstede]). In ERP systems, the process definitions are embedded in the database schemas (as structure and static/dynamic constraints), in the application software and in the way the UIs are built. The problem is that these formal definitions are scattered all over the ERP architecture and are very difficult to grasp or to represent in a graphical way (as they are represented in the process modelling languages). Various ERP vendors are offering Business Process Modelling (and management) tools, especially for helping to understand better the system, and also to help the initial configuration process (in a way certain process patterns trigger the selection of specific parameter settings). It will be explained in the remainder of this section, that these systems are not playing any role for workflow enactment in the ERP system. Some workflow engines can be included in the ERP package, but these have usually only peripheral role (mainly in document flows) and they have no operational link with the main business processes supported by the core of the ERP system. Roughly, the logic embedded in any ERP system can be divided into two
main parts: the business logic and the session logic. The session logic can be locally described as “what the user experiences when performs an elementary action in an ERP system”. The business logic is all the logic that is executed automatically in the background, of which users are supposed to be aware but which is not explicitly called by users in sessions.
3.2
ERP session logic
As said, sessions represent the elementary actions in an ERP-system. Actually, the operational use of an ERP-system consists of invoking daily thousands of sessions. Such an action will be usually related either to information retrieval either to enter a business transaction4. Authorized users can only execute these sessions. Sessions guide a sequence of elementary (human) actions in an interactive way, basically by entering data field by field on a screen. There is usually some elementary syntactic checking when data are entered per field, but there is also considerable amount of database checking which is executed automatically in the background. In other words always pieces of business logic5 are called within the session logic. Some ERP-systems are page oriented, and these deal with the data from a whole screen of a session only after the user “submits the screen”. Whereas other ERP-systems are field-oriented, and these process each piece of data immediately after it is being entered. In both cases we may conclude that sessions contain sequences of business process steps. Therefore, they may contain similar business knowledge as may be found in workflow systems.
However, sessions in ERP-systems are elementary actions from a data management point of view: they are either completely executed and successfully passed, or they fail in one-way or another, and then they are rolled back. Sessions are also typically tasks executed by a single-user 6. Consequently, although sessions contain business process steps to be executed, it makes most sense in the comparison with workflow systems to consider sessions as elementary steps. In the remainder of this paper, therefore, sessions are supposed to be elementary steps in comparison with workflow systems.
4
.There are other actions, e.g. to generate reports (in printed or electronic form), to run a batch program (e.g. an MRP-run or a set of EDI-messages), or to perform systems administration tasks. . The arguments in the paper are not fundamentally different for such other actions. For the sake of simplicity we therefore will not discus these.
5
Which is coded in the form of DLLs
6
3.3
ERP Business logic
Business logic in ERP systems usually takes the form of dynamic or static constraints on databases, with additional computation, when appropriate. For example, certain transactions in manufacturing, such as the release of a work order, lead to materials allocation in a warehouse that requires complex data navigation and computation. The database constraints are implemented as allowable database navigation and consistency checks, together with locking and other database management actions required to guarantee that the database moves always from a consistent state to another consistent state.
3.4
Business processes in ERP (in comparison with
workflow management systems)
When comparing ERP business logic with workflow management systems, it becomes obvious that ERP business logic contains similar knowledge on sequence of task execution as encountered in work flow management systems. This is due to the fact that the dynamic constraints implemented in the ERP business logic define which (trans-)actions are allowable and which are not. Moreover, the static constraints have dynamic consequences, because a move from a consistent state to an inconsistent state is simply not allowed.
WfMS are designed to support fixed, highly specified and routinized organizational processes. Users are aware of their position in the system and the state of the flow of cases. In an ERP system users are required a lot of understanding (and work) to keep track and understand the structure and state of the ongoing processes they are involved in. They have to know that has been done, what needs to be done next, and some times to abandon the routine procedure and improvise ad-hoc if the context is exceptional. The main advantage of the ERP system is that it keeps the consistency of the database in any circumstance. If a WfMS user is improvising in the way the ERP system user is doing, this leads almost inevitably to unexpected or undesired states of the overall supported process. Because in a WfMS the process description is complete, the exception handling is labor intensive and tricky; and because in an ERP system the process definition is less constrained (being basically a permitted set of transitions between consistent states of a database), improvisation and ad-hoc problem solving by the ERP user is simpler.
3.5
Intermediate conclusion on ERP
We conclude, that ERP systems are not suitable for support of business process management, because business processes are not explicitly represented. The are however suitable to support business process execution, provided that humans understand the business processes of which they execute parts.7
4.
WFM AS “FRONT-END” FOR ERP
This section describes the “naive” approach to integrate ERP and WfM. One of the authors witnessed an endeavour to create an integration along the lines sketched below, which failed dramatically. An explanation for this failure is also give in the text. We first describe the different user experiences in ERP and WfM, in order to explain why it is appealing to have WfM systems as a front-end for ERP.
4.1
Comparing user experiences in ERP and WfM
The user experience of business process enactment is quite different in ERP-systems as compared with workflow management systems. In ERP systems, the user who is enabled to perform a certain task experiences this in the following way:
1. The (authorized) user will open a session.
2. When in the session, the user can see which cases can be processed further under this session.
3. A list of objects can be opened, which is by the way available for all users who enter this session.
4. There is no push or e-mail driving the user forward to process a particular object in the session.
In workflow management systems, the user experience can be designed in the same manner, but it can also be designed differently. It is possible that the user (or a “user in a particular role”) will be explicitly mailed or pushed
7
The fact that ERP systems do not explicitly represent business processes, is not merely a drawback. Explicit representation of all possibilities (as in WfM systems) is often a burden because of the many exceptions and awkward situations that have to be foreseen. As compared with WfM systems, ERP systems are not forced to provide complete and explicit description of all possible workflow executions. Moreover, ERP systems do not require independence op cases. Rather, they describe precisely what interference is allowed.
to proceed with the cases enabled and that the workflow and history of a case are displayed.
4.2
Process modelling as UI for ERP
How do ERP users know where they are in a business process? How do they get the idea to start a session? The last question is easily answered: most ERP users simply open sessions because it is their job. They are supposed to know which business process steps precede or follow any particular task in the process.
However, ERP systems offering thousands of sessions in long lists are not very user-friendly for incidental users. Therefore, companies such as SAP and Baan have invested in enterprise modelling tool suites; Business Process Models are usually part of such suites. These business process models have been proposed as alternative user interfaces for users who want to select sessions and who need guidance as to where they are in a process.
These user interfaces with process models are then acting as the high-level screen from which sessions can be called by clicking on activities. In this way, a process model helps the ERP users to navigate through the vast amount of sessions, but it is not the same as a real workflow: there is no real case or case data to be carried forward in the graphical process model8. This solution has as a drawback, of course that some activity sequence information is stored redundantly in both the process model and the ERP system. On the other hand, there is no real need to have process models cover all the details and exceptions, because the ERP system will remain robust in exceptionally or unforeseen process instantiations.
4.3
WfM as UI for ERP
A logical next step was presumably to have a workflow management system act as the high-level user interface of an ERP system for selecting sessions. More precisely, business process models can be used as a UI for a workflow and as a high-level UI for ERP. This would allow users to carry real case data with the activities in the workflow and have these data available when entering ERP sessions (coping with issues as in footnote one).
8
In many ERP-systems, users experience the problem that their case data are not carried over from one session to another one. To be sure, of course, the database carries all cases and can provide all data. However, the case data on the particular case that I am just working on are not carried over from one session to another one and have to be re-selected out of a list or in another way.
However, the advantage of WfM systems also has a drawback, which is again redundancy. As soon as a real workflow management system takes over the sequence of actions in a business process, it becomes overlapping with the ERP-environment, triggering problems such as:
• Even if case data that is to be carried with the case from one activity to the next activity in a workflow management system, how can they be this carried over into the ERP sessions?
• What happens, if a case is removed in one system, but still alive in the other system?
• More general, if the WfM describes the change of states of an object, it is likely that the ERP system dos the same – how to keep both systems consistent?
• How to handle a situation where the WfM system pushes a particular case forward, while the ERP system is not yet enabled to proceed with the case?
All these problems go back to redundancy in flow information as a root cause. These problems are not merely theoretical, but we have experienced them in our own professional life as very real. Consequently, we have to conclude that a shared business process model as UI for ERP and WfM is harmful and should be avoided. It is a bad idea, based on lack of understanding of the real paradigms of both approaches.
5.
WFMS AS COMPONENT IN AN ENTERPRISE
INTEGRATION SUITE
The previous Section leads to the conclusion, that actions in an ERP system should not be managed in parallel through a WfM system: rather, WfM systems should consider ERP as a black box. This leads to the conclusion that parts of business processes covered in ERP systems should be single actions in WfM. The role of WfM then becomes almost void in the case of a running ERP system, but it may be much more pronounced in the case of multiple ERP systems. This is exactly what happens currently in practice in the EAI (Enterprise Application Integration) market9: WfM linking several ERPs and other transaction processing legacy (jointly called OLTP systems). We will investigate the pros and cons of this option in the remainder of this Section.
In a situation where several OLTP systems are concurrently in use in a single organization, it is quite common to find out that business processes cross the borders of such systems. For example, it is not unusual to find
9
functional areas of the business that have their own OLTP systems. In relation to the example presented in the Appendix, one might find OLTP systems for Sales, Logistics and Finance. It is to be expected that business processes go across such functional areas, and this is exactly where integration technology is needed. Consequently, it could be expected that work flow systems technology is deployed as part of an Enterprise Application Integration Suite.
However, when work flow technology is used in connection with several OLTP systems, the workflow activities should be defined in such a way that the workflow logic is not duplicating any business logic implemented in the OLTP systems. Otherwise the architectural setting discussed above in Section 4 will emerge again. Therefore, the granularity of the workflow activities will be defined by whatever is covered in existing legacy systems.
6.
CONCLUSION
Whatever the logic of this result may be from an ICT point of view, it is very strange from the business point of view. After all, if work flow management is considered to be the means to execute and manage a business process, its granularity cannot be determined by accidental legacy OLTP systems. Therefore, the result of our search is not yet satisfactory. A genuine way to really create integrated software based models for business process descriptions and models for transaction processing lies still ahead, and will need a lot more research.
7.
REFERENCES
Nick Szirbik, Hans Wortmann, (2004), “Bridging the gap between ERP and WFM using agents”, Proc. of the Intl. IMS Forum 2004, Como, Italy, 17-19 May, see at
http://www.bdk.rug.nl/medewerkers/n.b.szirbik/COMO.pdf
Jorge Cardoso, Robert P. Bostrom and Amit Sheth (2004)“Workflow Management Systems vs. ERP Systems: Differences, Commonalities, and Applications”, , in Information Technology and Management 5, 319-338, 2004, see at
http://citeseer.ist.psu.edu/531507.html
Wil van der Aalst, Arthur ter Hofstede, (2002), YAWL: Yet Another Workflow Language, QUT Technical report, FIT-TR-2002-06, Queensland University of Technology, Brisbane, 2002, see at
http://is.tm.tue.nl/staff/wvdaalst/publications/p174.pdf
Abraham Bernstein (2000), “How can Cooperative Work Tools Support Dynamic Group Processes? Bridging the Specificity Frontier”, Proc. of Computer Supported Collaborative Work (CSCW2000), Conference, Philadelphia, PA, December 2000, ACM.
Alan Newell, Herbert Simon (1972), “Human Problem Solving”, Prentice-Hall, Engelwood Cliffs, N.J., 1972
8.
APPENDIX: AN EXAMPLE TO COMPARE ERP
AND WFM
A company has a customer order entry process, which proceeds in two phases.
• In the first phase, three actions are performed viz: the request is checked for completeness (e.g. is the customer known? is catalogue product known? what is the price?) and prepared for quotation (by the Sales department)
• Action 1: the credibility of the customer is checked (under responsibility of the financial department)
• Action 2: the material availability is checked (under responsibility of the logistics department)
• Action 3: the quotation is completed and sent to the customer (by Sales) We assume that the financial and logistics checks are performed in parallel. See fig. 4. Prepare quotation Check credit Sales Finance Logistics Check material request Credit available? Yes/No Stock Available? Yes/No quotation
Figure 4. Quotation workflow
The second phase is the order delivery phase, initiated by a positive customer response to quotation (which should happen within limited time). In this phase, the customer’s credit is updated and physical delivery takes place. After a notification of delivery by the logistics department, an invoice should be sent to the customer. This is the regular course, see fig. 5.
We assume that updating the customer’s credit is never a problem (although in practice we would have to deal with a situation in which the customer has meanwhile passed the credit limit). However, the physical
delivery may be a problem, because other customers may meanwhile have bought the stock, so that the customer may still get a letter of regret.
Customer Order Manage credit Sales Finance Logistics manage materials invoice Update Credit order Notification of delivery Order (based On quotation) delivery
Figure 5. Regular order delivery process
Logistics
Customer Order Manage creditSales
Finance
manage materials Letter of regret order Notification of Non-delivery Order (based On quotation)Figure 6. Exception handling in case materials are no longer available
This situation is depicted in figure 6. Note, that this exception leads to the need to consider carefully the timing and sequence of updating the creditability. After all, the situation should be avoided where the customer’s credit is updated but nothing is delivered. Therefore, update of the credit in figure 5 should take place after notification of delivery.
Consider how this example would be modelled in an ERP system. The data-centric nature of ERP would first of all require a class diagram, as in figure 7. In addition, the business logic described above needs to be
represented. This can be done by introducing a number of constraints and rules. For example, figure 4 could be specified by the rule:
If ORDER_STATUS = ‘request’ and
(PRODUCT_STOCK < 0 or CUSTOMER_CREDIT < 0) then generate decline message; delete order;
else generate quotation;
update ORDER_STATUS to ‘quotation’;
The action by the customer could be specified as follows:
If ORDER_STATUS = ‘quotation’ and Customer returns order then update ORDER_STATUS to ‘firm’;
Product Price Stock Order status Cust-omer Credit * *
Figure7. Class diagram as basis for ERP solution
The business logic of figure 5, with the additional considerations of figure 6 can be specified as follows:
If ORDER_STATUS = ‘firm’ and PRODUCT_STOCK > 0 then generate delivery; update stock; Update credit; send invoice; update ORDER_STATUS to ‘delivered’ else generate letter of regret; update ORDER_STATUS to
‘cancelled’ Notes:
1. In this simple example, it is easy to trace the process. However, this is due to the fact that the whole process is tied to the status of the ORDER. If we would have chosen to model requests, quotations and regrets as separate objects, it would be much more difficult to trace it, because the process as such is not represented
2. the sequence of actions described above in relation to figure 6 has been modelled by a simple sequence of statements in the then-clause of the last rule. If this task is an automated update of a field, then such a task could be done by a DLL-call in an ERP session. In general, however, this
cannot be done when humans are needed to enter the data (e.g. when human approval is needed before the process can proceed). In such situations, another status-indicator has to be created in the database to account for the approval.
3. More rules and constraints are needed. E.g. a rule should be added which specifies that quotations without response be deleted after the allowable time has passed.
Let us now approach the same problem from a workflow perspective. The first step is pretty obvious, and depicted in figure 8 below.
Process request Check credit Produce answer
Figure8. Workflow model for phase 1
Figure 9 extends the model to include phase 2. The first step (figure 8) has been condensed to the first transition in Figure 9.
Produce answer Check material Decline or no timely response to quotation Produce letter of regret Deliver; Update stock Update Credit; Send invoice
This workflow description is much more close to the original problem description of figures 4 to 6. However, it adds precision, in the sense that the semantics of arrows, joins and splits is clear. However, the workflow description is on a case-by-case basis, and it cannot handle interferences between cases. Such interference may easily occur, both at the level of shared resources and at the level on information management. At the level of shared resources, this case gives two clear examples. First of all, if a particular request for materials can be satisfied, this may result in a positive quotation. However, the materials may disappear due to other requests. In this naïve example, it could be argued that there is no reservation mechanism..
However, a more advanced reservation mechanism would not really solve the issue – because of the fact that reservations are going to compete with each other or with new (real) orders, and the trade-off has to be made somewhere by someone. The real issue is that in the workflow approach there is no concept to make the trade-offs between various orders in a situation of limited resources. A workflow around resources would not really help because resources management is not a process, but an ongoing activity. It is not a structured series of actions, but an unstructured network of options. It is not triggered by an event or a clock but by a set of conditions. It does not lead to a finished case, but to an extended plan of action. It fits more into the idea of an ERP session than to the idea of a flow of work.
The second example of resource sharing is the credit space, to be shared between different requests by the same customer. Each order may consume part of the credit, and when the limit is reached, the next request will be declined. Here too, there is no mechanism in the work order which could handle or prevent the issue. One could think of a credit management workflow, but resolving the credit issue has to be handled at the customer site, not merely at the suppliers side (certainly not as a routine).
Apart from interference of cases via (shared) resources, there is also another point in relation to a workflow solution and that is data management. Suppose (in the above example), that a customer confirms a quotation for a product, but the product has been deleted from the catalogue? In data-oriented approaches (such as ERP), this can be prohibited by constraints. But is workflow-oriented approaches, this is more difficult – it is likely that a workflow-oriented approach presupposes some integration with data management.