Business Process Requirements, Modeling Technique, and Standard:
How to identify interoperability gaps on a process level
Boriana Rukanova, Kees van Slooten, Robert Stegwee
University of Twente
Department of Business Information Systems P.O.Box 217
7500AE Enschede, The Netherlands Telephone: +31 53 489 40 64
Fax: +31 53 489 21 59
E-mail: {b.d.rukanova, c.vanslooten, r.a.stegwee}@utwente.nl
Abstract
In business-to-business setting there is a growing need for organizations to be interoperable. Information systems involved in automating parts of a business process need to be process-aware, in order to become an integral part of it. Before automation is achieved, the part of the business process to be automated needs to be made explicit and then operationalized. Business process models could be used to make the process explicit. Domain standards could be used to make it operational. However, there is no approach available to evaluate to what extent both the chosen modeling technique and standard are able to cover the actual requirements of the business process.
In this paper, we construct an evaluation framework to identify the fit between business process requirements, a modeling technique and a standard. To construct the framework, we first identify some important characteristics of a business process and then link them to the FRISCO ontology of information systems concepts.
The framework we construct is very general. However, its elements could be further elaborated to allow for a more detailed level of comparison. We demonstrate with an example how the framework could be used to identify the fit between business process requirements, a modeling technique and a standard. Improvement of the framework and in-depth elaboration of its concepts will be subject of further research.
1. Introduction
In business-to-business settings, there is a growing need for different business organizations to work together and communicate, in order to achieve the desired business goal. Computer systems have a great potential to automate parts of the business communication and business processes. In that respect, the notion of interoperability becomes of great importance. According to the IEEE definition, interoperability is defined as “The ability of two or more systems or components to exchange information and to use the information that has been exchanged”. However, it has been argued that to achieve interoperability between organizations, the implicit notion of a system as a computer-based information systems, needs to be expanded to organizational system as a socio-technical system (see Stegwee & Rukanova, 2003).
Following the ideas from organizational semiotics, it has been argued that in business communication, information is inter-subjectively defined, and it can be faultlessly interpreted only if the different parties share the same meanings and intentions (Stamper, 1996). Thus, information directly depends on the context of communication (Vermeer, 2000). When two or more information systems are involved in automating parts of a business process, they need to be process-aware in order to handle complex communication. If we want to use computer systems to support part of a business process, this requires the disparate information systems to be able to express, and especially interpret a broader range of meanings. Thus, the applications that support the business processes, not only have to be able to express what needs to be said, but also to interpret it, and act upon this interpretation in an intelligent manner. Thus the shared communication context of the business process needs to be captured and made operational. One possibility to make this context operational and embed it in the system is by using domain standards1 (see also Rukanova et al., 2003).
EDI2 standards promised significant advantages in facilitating the exchange between business partners, reducing errors, increasing speed, cutting cost, and building in competitive advantage (Kerke & Mukhopadyay, 1992; Mackay, 1993; Wrigly et al., 1994; Jelassi & Figon, 1994, Sokol, 1995; Damsgaardn, 2000). However, the EDI standards failed to capture the shared communication context, in order to support the complex business communication. They were more like languages for depositing character strings into a particular place of a remote computer, than languages for exchange of knowledge. EDI standards were lacking clear and complete lexicon; did not have fully specified grammar, and had nearly no semantics. Furthermore, the focus of many IS professionals on EDI was how to provide technical tools, rather than to support the way people do business (Huang, 1998; Covington, 1997; Kimbrough, 1999).
New standards, which strive to allow for interoperability between disparate systems, are currently developed. These standards try to capture the communication context of a business process, in order to allow for meaningful communication (for example, in the healthcare domain two such standards are HL73 standard for clinical data interchange and DICOM4 for digital images).
Standard development organizations or consortia of companies develop such standards, based on their specific interpretation of the domain. However, in order to have value for a particular business process, a standard needs to be linked to a particular situation, which might be different from what the developers had in mind. Thus, the standard needs to be evaluated (for a specific business process) whether it can cover the communication context (of the particular business process), which needs to be embedded in the system. Failure to cover parts of this context can lead to inter-organizational interoperability problems. The communication context of a business process might be to a large extent implicit. Thus, before making it operational (by using standards), it first needs to be made explicit.
Models could be used to capture and to make this communication context explicit. A commonly accepted way of modeling does not exist (Wand, 1989). However, the modeling power of various methodologies, their weaknesses and strengths, can be analyzed in terms of ontologically based common set of constructs (Wand et al, 1989; Söderström et al., 2002).
1
We will refer mainly to three types of standards: standards that define the meaning of the data, standards that describe what is communicated in a message, and standards that define the intentions of the message.
2
More than thirty years ago the idea was born to eliminate the use of paper documents for exchanging business data, by linking computer systems together. This concept became known as Electronic Data Interchange (EDI) and later on, two domain standards emerged: ANSI X.12 and UN/EDIFACT.
3
HL7 is a HL7 standard for Clinical data interchange
4
From the description above, a few issues arise. First, how to evaluate whether a modeling technique has the capability to cover different elements of the communication context of the business process? Second, how to evaluate to what extent a standard can capture these elements? If we refer to the elements of the communication context of a business process, which need to be embedded in the system, as business process requirements, we can rephrase the issues described above as follows:
How to evaluate the fit between business process requirements, a modeling technique, and a standard?
In this paper we construct an evaluation framework to identify the fit between business process requirements, a modeling technique, and a standard. To construct the framework, we follow the idea of Wand et al. (1989) and Söderström et al. (2002) and try to make the evaluation in terms of an ontology-based common set of constructs. As we want to make the evaluation specific for a business process, we first identify some important characteristics of a business process and then link these characteristics with key concepts, defined in the FRISCO report (
Falkenberg et al.
, 1998). FRISCO provides the ontology to be used in constructing the framework. The framework can be applied to identify mismatches at a high level. Each element of the framework could be further elaborated. This would allow for a more detailed comparison. However, the improvement of the framework and the thorough elaboration of its elements will be done in further research. The rest of the paper is structured as follows: In part two, we explain our approach; we describe some main characteristics of a business process and we introduce FRISCO, which we use for the construction of the framework. In part three, we demonstrate the process of constructing the framework and the elaboration of some of its elements. The use of the framework to identify the fit between business process requirements, a modeling technique and a standard is illustrated in part four. We end this paper with conclusions and further research.2. Setting the basis
2.1. ApproachIn order to evaluate the fit between business process requirements, a modeling technique and a standard, we will follow the idea of Wand (1989) and Söderström et al. (2002) and try to make the evaluation in terms of ontologically based common set of constructs.
We take the FRISCO report as a starting point, because we try to make the comparison at a level, at which we can also consider the appropriateness of a standard to make the business process requirements operational (that is, to embed them in the computer system). The goal of FRISCO is to help solving the problem of miscommunication between parties, coming from different domains, by providing a commonly accepted conceptual reference and terminology. However, the concepts in FRISCO are generally defined and do not directly refer to a business process. In order to facilitate the evaluation of the fit between business process requirements, a modeling technique and a standard, we need to be able to capture abstract elements related to business processes and link them to concepts from the information systems domain. Thus, we construct a framework for evaluating the fit between business process requirements, modeling technique, and standard by linking business process concepts to FRISCO concepts.
To construct the framework, we first identify some key concepts, characterizing a business process. We then try to link them with key FRISCO concepts. At the end we use some additional literature to complete the framework.
In the next section we identify some key concepts related to business processes.
2.2. Key elements of a business process
Business processes are widely discussed in literature. In order to understand the main characteristics of a business process, we will look at how a business process is defined. In this paper we do not aim to conduct a full analysis of business process concepts. Rather, we will try to come to a first operationalization, so that we can illustrate the idea of how a comparison between business process concepts, a modeling technique and a standard can be done.
Davenport (1993, p. 5) describes a business process as “a chain of activities whose final aim is the production of a specific output for a particular customer or market”. According to Ågerfalk (1999), a business process consists of activities ordered in a structured way with the purpose to provide valuable results to the customer. And further, according to Stock and Lambert (2001), a business process can be viewed as a structure of activities designed for action with focus on the end customer and the dynamic management of flows involving products, information, cash, knowledge and ideas. Fernandes (2001) refers to a business processes from a more organizational perspective. According to him, in an organization with business process thinking, the emphasis is on the process, as opposed to hierarchy. The vision in business process oriented companies is derived from customer requirements. And according to McCormack (1999), a business process view captures the process from beginning to end.
Table 1 below is a summary of these ideas. The table is organized in terms of authors and business process related concepts.
Authors Concepts
Davenport Ågerfalk Stock and Lambert Fernandes McCormack Activity Structured order of activities a chain of activities activities ordered in a structured way structure of activities
Aim final aim Purpose production Result (Value) specific output valuable results Customer particular customer or market
customer. End customer customer requirements
Beginning to end beginning to
end
Table 1: Some key business process concepts
The list of elements, describing a business process is not complete and is based on a limited literature review (this list will be enriched in our further research). However we can use it to illustrate how business process concepts can be linked to ontology of information systems concepts.
In the FRISCO report (
Falkenberg et al.
, 1998), a number of assumptions are made, and different definitions are introduced. Some of the concepts are fundamental concepts, for example “thing” and “relationship”. Composite concepts, such as “action” and “actor”, are defined using predefined concepts. Some of the characteristics of the predefined concepts are inherited by the composite concepts. For instance, in the definition of the composite concept “action”, the concept “transition” is used. That means that “action” inherits characteristics of a “transition”. When we construct the framework, we use composite concepts. Each of them however could be further elaborated.Why do we need FRICO? As we said in the beginning of this paper (See part 1), when two or more information systems are involved in automating parts of a business process, they need to be process-aware, in order to handle complex communication. Thus we need to find a way to link abstract business concepts to information system concepts, so that we are able to capture and make operational the shared communication context of the business process. The concepts defined in FRISCO can help us establish this link.
In this section we do not define the FRISCO concepts. A complete definition of these concepts is easily accessible via the Internet.
3. Constructing the framework
3.1. Construction of the high-level framework
In this section we construct a framework to allow for identification of fit between business process requirements, modeling techniques, and standards, using business process concepts and FRISCO concepts. This is a high-level framework and each of its elements could be a subject of further elaboration.
Activity is a key concept defining a business process. Activity within a business process could be presented as “action” in terms of FRISCO. From the definition of “action”5 we can see that an action has a “pre-state” and a “post-state.” In its “pre-state” it consists of non-empty set of “actors” and other things (“actands”), and an empty or not empty set of “actors” and “actands” in its “post-state”. This means that an activity in a business process can be represented in terms of FRISCO as shown in Figure 1.
In Figure 1, the squares represent different states; the oval represents an action; the arrow pointing from the pre-state to the post pre-state and crossing the action indicates that an action is a transition. Pre-sate Actors (R) Actands (R) Post-state Actors (O) Actands (O) Action
Figure 1. Business process activity in terms of FRISCO
5 An action is a transition involving a non-empty set of actors in its pre-state, and, if not "destroyed" or "consumed" by the action, in
its post-state as well, and involving a non-empty or empty set of other things (actands) as part of its pre–state, and having a non-empty or empty set of other things (actands) in its post–state. (FRISCO, p.100)
In the pre- state of an action there is a non-empty set of actors and actands ((R) stands for required or non- empty). In the post-state the set of actors and actands might be empty or not empty ((O) stands for optional).6
We can continue with the construction of the framework, now including the concept of a business process itself. A business process consists of activities ordered in a structured way and it has a beginning and an end (See Table 1). A similar concept in FRISCO is the “composite action,” which is defined as a structure of actions, with a unique “pre-state” and a unique “post-state.” Thus the business process itself could be presented as a composite action (see Figure 2), which contains actions. In Figure 2 the fact that we have a number of actions is represented by “Action 1..N,” and each action has the characteristics described in Figure 1. The actions (1..N) form the composite action (this is represented by the double-lined shape that originates from the composite action).
The “time” concept could help expressing the business process concept “activities ordered in a structured way”. It will govern the order of the occurrence of the different actions within the composite action. Also, in FRISCO, the allowed states and transitions are specified by the “rule.” Thus, the “time” and “rule” concepts are added in the framework, to both composite action and actions. They are depicted with shaded rectangles. The strait lines link “time” and “rule” to the concepts, to which they apply.
Customer is another important concept of a business process. To illustrate that a customer is an external party of the business process, we use the FRISCO concept of “system”. As the concepts that we use to construct the framework are “things”, in terms of FRISCO, and the concept of domain applies to all “things,” we included it in Figure 2 as well. To make the picture complete, we added also the concept of “domain environment” (system, domain and domain environment are represented with dotted rectangles).
6 Figure 1 has commonalties with Petri nets, where the states (the pre-state and the post-state) could be seen as places (an input place
and an output place) in Petri nets, and the Action corresponds to transition. However, we aim to achieve detailed elaboration of each
Pre-sate 1..N Actors (R) Actands (R) Post-state 1..N Actors (O) Actands (O) Action 1..N Rule Time Composite action (Business process) Pre-sate Actors (R) Actands (R) Post-state Actors (O) Actands (O) System Domain Domain Environment Time Rule Substantive aspect Communicative aspect Control aspect Substantive Communicative Control
Figure 2: High-level evaluation Framework
Up till now we managed to cover most of the business process related concepts, described in Table 1. However, we need to take into account that a business process could be viewed from different aspects. In literature there is often the distinction between substantive actions and communicative actions (Stamper, 1988; Goldkuhl, 2001). Stamper (1988) refers also to a third type: control. The substantive aspect focuses on activities that take place in order to achieve the goal. The communicative aspect refers to the messages necessary in order to have the substantial activities in place effectively. The control aspect comes to assure that the necessary activities are being performed. Minzberg (1983) and Galbraith (1977) elaborate on the concept of coordination, which includes both the control and communicative aspects. We can then say that a composite action (business process) consists of substantive, communicative, and control aspect (on figure 2 this is presented with brackets, where the dotted line expresses that a composite action can be decomposed to these three aspects). The same is true for action.
3.2. Elaboration of concepts of the framework
What we did up till now was to try to link some important business process related concepts to Information systems concepts, defined mainly in FRISCO. Each element in the framework is a composite concept that can be further elaborated. This could allow to identify the fit between business process requirements, a modeling technique and a standard at a more detailed level.
Below we demonstrate the elaboration of some concepts. A complete elaboration, however, will be a subject of a further research.
An important characteristic of a business process is that it has a purpose (aim). This could be represented through the concept of “goal”. In FRISCO “the goal of an action is a special input actand of that action, pursued by the actors of that action and stating the desired output state intentionally.” When we relate the goal concept to the business process, two types of goals can be identified: the goal of the composite action (as one type of input actand of the composite action) and the goal of the individual actions (as a type of an input actand of the constituent actions). The goal of the composite action is a high-level goal, which relates to the aim of the business process. Each of the constituent actions has its own goal, which is governed by the goal of the composite action. In Figure 3B, the main goal of the business process is presented as elaboration of the concept “actand” in the pre-state of the composite action (the elaboration of the concepts is presented as a dotted rectangle linked with dashed lines to the main concept. A number of concepts in the dotted rectangle can link to one main concept). The symbol (G) next to Goal indicates that this is a main goal. The lower level goals of the actions contained in the composite action are presented as elaboration of the concept “actand” of the pre-states (1..N) of the constituent actions. We call them goal 1..N (G) to represent that each action has its own goal, which is governed by the goal of the composite action (see Figure 3B).
Pre-state (Composite action)
Actand (R) Goal (G)
Figure 3A: Elaboration of actand: goal as a special type of actand in the pre-state of the composite action
Pre-state 1..N (action)
Actand (R) Goal 1..N (G)
Figure 3B: Elaboration of actand: goal as a special type of actand in the pre-states of the actions 1..N.
The purpose of a business process is to provide a valuable result. Thus defining a separate concept concerning the result is important for the framework. Although a “result” concept is not explicitly specified in FRISCO, by using the analogy with goal, we will include the result as a part of the post-states of the composite action and actions respectively (See Figure 4A and Figure 4B).
Post-state (Composite action)
Actand Result
Figure 4A: Elaboration of actand: result as a special type of actand in the post-state of the composite action
Post-state (Action 1..N)
Actand Result (1..N)
Figure 4B: Elaboration of actand: result as a special type of actand in the post-state of the actions 1..N
Customer is another important concept of a business process. In terms of FRISCO the “goal pursuing actor” of the composite action could capture this concept. As the customer is external to the system, we will call him an external goal-pursuing actor. We will call the actors, pursuing the goals of the individual actions internal goal-pursuing actors (See figure 5A and 5B).
Pre-state
(Composite action)
Actor (R) Goal-pursuing actor(External)
Figure 5A: Elaboration of actor: the external goal-pursuing actor as a special type of actor in the pre-state of the composite action
Pre-state
(Action 1..N)
Actor (R) Goal-pursuing actor(Internal)
Figure 5B: Elaboration of actor: the internal goal-pursuing actor as a special type of actor in the pre-state of the actions 1..N.
In this paper we will go no further in improving the framework and elaborating the concepts. This will be a subject of future research.
4. Usage
In the introduction we stated that information systems need to be process-aware, in order to become an integral part of the business process. We also pointed out that different modeling techniques could capture the requirements of a business process. Standards can be used to embed these requirements into the information system. The main concern was how to identify the fit between business process requirements, a modeling technique and a standard. In section 3.1., we constructed a general framework to help in identification of this fit. The framework links some business process concepts with information system concepts. In section 3.2., we illustrated how concepts of the general framework could be further elaborated. This elaboration could allow for identification of the fit on a more detailed level. Although neither the framework nor the elaboration of the concepts is complete, below we illustrate the use of such an approach with a simple example.
We take as an example a business process from the Healthcare industry. For one requirement of the business process, we evaluate to what extent it could be covered by a certain modeling technique and a standard. The modeling technique that we analyze is “process charting” and the standard is the HL7 v3.0 standard.
Brief description of the business process
Let us look at a situation, where a doctor requests a laboratory to do a blood test. To do the test, the laboratory needs to perform several activities. First, it needs to obtain a blood sample from the patient. After that, the sample has to be transported to a specified location for analysis. Once the sample is analyzed, the results are interpreted, before being sent to the interested parties.
Using the framework to specify business requirements.
Let us have a situation, where parts of the business process described above (e.g. ordering of a blood test and receiving of observation results) need to be supported by disparate applications. We have to identify which elements of the business process need to be captured and embedded into the computer systems.
Walking through the elements of the framework (See Figure 2) and brainstorming with parties involved in the business process, we might identify, that knowledge about actors needs to be embedded in the systems. For example, it might be important to know who orders a specific blood test; who collects the samples; who interprets the results. Thus, one important business requirement is to be able to capture the concept of actor. For the purpose of this example we focus only on this requirement. Below, we analyze whether the chosen modeling technique and the chosen standard could cover this requirement.
The modeling technique
For the purpose of this example we evaluate a modeling technique used in practice called “Process charting” (McSheffrey, 2001). With the process charting, it is possible to model a business event, a business result, elementary processes, mandatory sequences and optional paths (See Figure 6). Business event Business result Process Mandatory sequence Optional path
Figure6: Notation of elements, used in process charting.
Let us try to analyze, which elements of the framework does the process charting cover. The business event refers to the pre-state of the composite action (an example of a business event could be the order of a blood test) and the business result refers to the post-state of the composite action (an example could be the receipt of the observation result). This business event indicates the desired outcome of the business process, so we can link it to the goal of the composite action. The business result refers to the result of the composite action. (See Figure 3A and Figure 4A). Processes corresponds to actions within a composite action; the time concept of the framework can be covered by concepts of mandatory sequence (mandatory sequence can capture the relative time). The allowed set of business events, business results, processes, mandatory sequences and optional paths is governed by rule.
In summary we can say that the “process charting” covers the following elements of the framework7: the goal and the results of the composite action, the actions within the composite action, the time and the rule concepts.
In the previous section, for our blood test example, we identified the need to capture the knowledge about actors. In this section, we analyzed the process charting as a modeling technique. However, from the description above it is clear, that with the process charting the concept of “actor” cannot be modeled8.
The standard
For the purpose of this example we look at the HL7 v.3.0. standard, which is a leading standard in the Healthcare industry. For simplicity reasons we only check whether the concept of actor can be covered using this standard.
The HL7 v.3.0. standard is developed based on the HL7 Reference Information Model (RIM). The RIM captures important concepts from the Healthcare domain. Although the RIM is very generic, it is the starting point for deriving more concrete models, like the Domain message information models and the Refined message information models, which capture the information exchanged between different applications (that take part in the business process).
The HL7 RIM identifies two major "high-level" concepts that are fundamental to understanding the world of healthcare information: intentional "actions" or "services" (Acts), and "people,
7
We also refer to the elaboration of the concepts of the framework
8
There are other elements that cannot be modeled with process charting, but for the purpose of this example we will focus on the concept of actor
places and things" that are of interest in the world of healthcare (Entities). The RIM places two additional classes - Role and Participation - between Act and Entity. The Role class models several important concepts. First, Role captures the fact that the various "static" entities may "temporally" assume one or more "roles" in a particular healthcare context. Second, the concepts of "capability" are also modeled using instances of the Role class. A special class “Participation” is introduced to identify “Entity-in-a-Role”, which participates in a specific “Act.”
Going back to our example, we can say that the concept of “actor” can be represented in terms of the RIM concepts as Entity in a Role, which participates in a specific Act.
Within the example described above we used the framework to specify one requirement of a business process (the requirement that knowledge about actors needs to be embedded within the systems, supporting the business process). We evaluated process charting as a modeling technique and we identified that it cannot cover the concept of actor. We analyzed the HL7 v. 3.0. standard and we found out, that the concept of actor could be captured. Thus we identified a mismatch between a business process requirement, a modeling technique and a standard. This mismatch might not allow knowledge about the actor to be embedded in the information system (even if the standard is capable to cover the concept of “actor”, the chosen modeling technique is not able to model this business process requirement). The result could be a technically functioning system, which however might not be able to become a fully integral part of the business process.
5. Conclusions and further research
We started this paper saying that systems, used to automate part of a business process, need to be business process-aware in order to become an integral part of it. We pointed out the need to evaluate the fit between business process requirements, a modeling technique and a standard. A framework was constructed to facilitate the evaluation of this fit. We further argued a mismatch between the requirements, the modeling technique and the standard can pinpoint inter-organizational interoperability problems. In that respect the framework could be used as a tool for such problem identification. The intended use of the framework was demonstrated with a simple example.
The question that we asked in the beginning of this paper was how to evaluate the fit between business process requirements, a modeling technique and a standard. For simplicity reasons, we presented a very small example of how to identify this fit. The purpose of this example was mainly to illustrate how to work through the framework. However, we can envision situations, in which more complex analysis needs to be performed. For instance, concerning the modeling technique, such an analysis might lead us to the conclusion that the modeling technique does not provide the means for synchronization of process steps, thus it does not provide enough richness of the rules (this can be identified by the rule concept of the framework and its elaborations). Similar analysis could identify gaps in the standard. For instance, in the HL7 v.2.2., the concepts of a “general practitioner” did not exist (in the US, where the standard is developed, the concept of general practitioner does not exist, however, in other countries using the standard, it does). This gap can be identified through the actor concept of the framework and its elaboration. Further, the HL7 standard is very limited in terms of modeling the sequence of actions, which is suggested by the rule and time elements of the framework.
In this paper we constructed a general framework. This framework can be seen as a first attempt to reason about to what extent a modeling technique and a standard are capable to cover the
actual business requirements. Such an evaluation is needed, to check whether the chosen modeling technique is capable to make explicit and correctly capture the business process logic and whether a chosen standard is capable to formalize it. As argued earlier, such an evaluation is important, so that interoperability problems can be identified at an early stage.
Each element of this framework could be further elaborated. This would make possible to have a more accurate comparison between requirements of the business process, the modeling technique and the standard. However, the improvement of the framework and the thorough elaboration of its concepts will be a subject of further research.
References
Ågerfalk, P., Goldkuhl, G., Cronholm, S. (1999). Information Systems Actability Engineering- Integrating Analysis of Business Process and Usability Requirements. Proceedings of 4th International Workshop on the Language Action Perspective on Communication Modeling (LAP’99). Copenhagen, Denmark, September 12-13.
Biazzo, S. (2000). Approaches to Business Process Analysis: a Review, Business Process Mnagement Journal, Vol. 6 No. 2, 2000, pp. 99-112.
Covington, M.A. (1997). On Designing a Language for Electronic Commerce. International Journal of Electronic Commerce, vol. 1, no 4, Summer 1997, pp. 31–48.
Damsgaard J., Truex, D. (2000), Binary Trading Relationships and the Limits of EDI Standards: The Procrustean Bed of Standards. European Journal of Information Systems, vol. 9, no 3, pp. 173-188.
Davenport T.H. (1993). Process innovation. Reengineering work through information technology. Harvard Business School Press, Boston.
Davenport, T. and Short, J. (1990), The new industrial engineering information, technology and business process redesign., Sloan Management Review, Vol. 31 No. 4, pp.11-27.
Falkenberg, E. D., Hesse, W., Lindgreen, P., Nilsson, B. E., Han Oei, J. L., Rolland, C.,
Stamper, R.K., Van Assche, F.J.M., Verrijn-Stuart, A. A., Voss, K. (1998),
A Framework of Information System Concepts: The FRISCO Report, IFIP (1998), available on- line at:http://www.liacs.nl/~verrynst/frisco.html
Fernandes, K.J., Raja V., Autony, J. (2001). Optimal level of goal mapping in a reengineering environmnent”, Business Process Management Journal, Vol. 7 No. 1, 2001, pp. 24-32.
Galbraith, J. (1977), Organization Design. Reading. MA: Addison- Wesley
Goldkuhl, G., (2001), Communicative vs. material actions: Instrumentality, sociality and comprehensibility, In: M. Schoop and J. Taylor (Eds.), Sixth International Workshop on the Language Action Perspective on Communication Modelling (LAP 2001), Montreal, Canada, 1-19 HL7: Health Level 7 http://www.hl7.org/
Huang K. (1998), Organizational Aspects of EDI: a Norm-oriented Approach, PhD thesis, ISBN 90-3651095-3
Jelassi, T. and Figon, O. (1994), Competing through EDI at Brun Passot: Achievements in France and Ambitions for the Single European Market, MIS Quarterly, 18(4), pp. 337-352.
Kekre, S. and Mukhopadyay, T. (1992), Impact of Electronic Data Interchange Technology on Quality Improvement and Inventory Reduction Programs: A Field Study, International Journal of Production Economics, vol. 28, no. 3, pp. 265-282.
Kimbrough S.(1999), EDI, XML, and the Transparency Problem in Electronic Commerce. Available on-line:
http://grace.wharton.upenn.edu/~sok/sokpapers/1999-0/indiana-transparency/paper.pdf
Mackay, D.R. (1993), The Impact of EDI on the Components Sector of the Australian Automotive Industry, Journal of Strategic Information Systems, vol. 2, no. 3, pp. 243-263. McCormack, K. (1999), Business Process Orientation (BPO): What is it and How do you know when you have it?
McSheffrey, E. (2001), Integrating Business Process Models with UML System Models, A Popkin Software White Papere. Available on-line at:
www.popkin.com
Mintzberg, Henry,
Reijswoud, V.E. van, J.L.G. Dietz. (1999). DEMO Modelling Handbook: Volume 1. Available on-line: http://www.demo.nl/DEMO/Literatuurbron/handbook.pdf
Rukanova, B. D., Slooten, C. van, Stegwee, R.A. (2003).Beyond the Standard Development and
the Standard Adoption. In Jakobs, K. (Ed): Proceedings of the 8th EURAS Workshop on
Standardization, July 11-12, 2003, Aachen, Germany.Mainz Publishers, ISBN: 3-86073-762-7, pp. 120-138
Söderström, E., Andersson, B., Johanesson, P., Perjons, E., & Wangler, B., (2002), Towards a Framework for Comparing Process Modeling Languages”, In Pidduck et al. (Eds.), CAISE 2002, LNCS 2348, pp. 600-611, 2002, © Springer- Verlag Berlin Heidelberg, 2002
Sokol, P. K. (1995), From EDI to Electronic Comemrce- a Business Initiative, McGraw-Hill, Inc., New York, ISBN 0-07-059512-7.
Stamper, R. (1988), Computerized assistance During the Information System Life Cycle, T.W. Olle, Verijn-Stuart, L. Bhabuta (eds), Elsevier Science Publishers B.V. (North-Holand) © IFIP, 1988
Stamper, R. (1996), Organisational Semiotics. In: Information Systems: An Emerging Discipline, F.Stowell & J. Mingers (eds.), London and New York, McGraw-Hill.
Stamper, R.K. (1992), Signs, Organizations, Norms and Information Systems, Proceedings of the Third Australian Conference on Information Systems, University of Wollongong, Australia Stegwee, R.A., Rukanova, B.D. (2003). Identification of Different Types of Standards for Domain-Specific Interoperability. In: Proceedings of MIS Quarterly Special Issue on Standard Making: A Critical Research Frontier for Information Systems: Pre-Conference Workshop ICIS 2003. pp. 161- 170, available on line at: http://www.si.umich.edu/misq-stds/proceedings/
Stock, J.R. and Lambert, D.M. (2001), Strategic Logics Management, McGraw-Hill?Irwin
Structure in Fives: Designing Effective Organizations
; Englewood Cliffs : Prentice Hall,
1983.
Vermeer, B. (2000). How Important is Data Quality for Evaluating the Impact of EDI on Global Supply Chain, Proceedings of the 33 Hawaii International Conference on System Science, vol. 7. Wand, Y. & Weber, R. (1989), An Ontological Evaluation of System Analysis and Design”, In: Falkenberg, E.D. & Lindgreen, P. (Eds.) Information System Concepts: An In-depth analysis, Elsevier Science Publishers B.V. (North-Holand) © IFIP, 1989
Wrighly, C.D., Wagenaar, R.W., and Clarke, R. (1994), Electronic Data Interchange in National Trade: Frameworks for the Strategic Analysis of Ocean Port Communities, Journal of Strategic Information Systems, 3(3), pp. 211-234.
