For example, the ISA-95 standard is based on the Purdue Enterprise Reference Architecture. (PERA) (Williams 1994). In the review paper (Bernus, Noran and ...
------- working paper 2017-02-15 -------
Mirosław Zaborowski The University of Dabrowa Gornicza, Dabrowa Gornicza, Poland
The information-decision model of enterprise business processes This study demonstrates that integrated multilevel management and direct control systems are enterprise process control systems (EPC systems). A business process has been defined as a control system that controls its subordinate processes, whereas a base process – as a control system whose controlled plant is an infrastructural process. EPC systems may be perceived as networks of controlling units of enterprise processes. The structure of these networks reflects the hierarchical and cooperative relationships between business activities. EPC systems may also be perceived as multiagent control systems with passive interactions between agents. This study defines the information-decision state variables of an EPC system and presents a general model of cause-result dependencies between the input and output variables of elementary business agents. In addition, it describes how to model the structure of concrete EPC systems using enterprise process modelling language (EPML) diagrams, which are such UML object diagrams that fulfil the constraints imposed by class diagrams of the EPML metamodel. Class diagrams for the relationships between the most important concepts of EPC theory are presented. In conclusion, it was noticed that the EPML metamodel may be implemented as the software framework, which is designed for modelling and generating EPC systems software that is built from replaceable controlling units of enterprise processes. Keywords: enterprise architectures; enterprise integration; enterprise modelling; enterprise process control; enterprise process state; enterprise business processes;
1. Introduction. The business-IT divide problem Every change in an enterprise’s structure requires corresponding software changes. Therefore, achieving the desired enterprise agility is impossible if software change durations are not negligible relative to the time intervals between them. The primary obstacle to reaching this goal is the ‘business-IT divide’, which refers to the necessity of difficult and prolonged arrangements between business analysts, who understand the actual goals of process reengineering, and IT engineers, who are authorized to make changes to the structure of management systems software. To radically solve this problem, Smith and Fingar, endorsed by the Workflow Management Coalition (WFMC) and the Business Process Management Initiative (BPMI), suggested the creation of management information systems for which business processes could be used as replaceable building blocks (Smith and Fingar 2003). Then, the exchange of these blocks could be performed by business analysts, without the participation of IT engineers, using their own graphical models of designed processes. The business process models should be compatible with the BPMN standard and executable – i.e., transformable into corresponding software applications. To manage the action sequence of processes and the information flow between these processes, a central business process management system (BPMS) can be used, which should function similarly to a database management system (DBMS) (Smith and Fingar 2003). Obviously, production acts that create real goods and/or services in every business processes (Dietz 2006b) can be modelled but, in general, cannot be executed as software application components.
A silent assumption of Smith and Fingar’s conception is each properly acting enterprise management system can be implemented, with all its functions and data, as a set of replaceable business processes. The justification of this assumption may be the observation that from a technical perspective, all enterprise activity consists in performing business processes. So, business process management that answers the questions “What should be done?” as well as “Where, when and how should it be done?”, encompasses all areas of enterprise action management. It includes production management, sales management, accounting, human resource management, and all other functions that correspond to modules of well-known enterprise resource planning (ERP) systems (Langenwalter 1999). Using business processes as replaceable building blocks, built in the central BPMS of an enterprise, is not the only way to obliterate the business-IT divide. An alternative method is the use of replaceable business process controlling units that are embedded in the universal framework system of enterprise process control (FSEPC) (Zaborowski 2016a). In EPC systems, each business process has exactly one controlling unit that performs all its acts except for production acts. Therefore, the embedding or removing the controlling units of selected business processes may be applied to reengineer both the business processes and the enterprise management software. To model the structures of concrete business processes and the structures of process management systems, enterprise process modelling language (EPML) diagrams can be used (Zaborowski 2016a). EPML diagrams are UML object diagrams (Booch, Rumbaugh, and Jacobson 1999) that fulfil the structural constraints of the FSEPC, which are imposed by class diagrams of the EPML metamodel. The formal descriptions of EPML and FSEPC belong to the author’s enterprise process control (EPC) theory (Zaborowski 2011, 2016a). It is a set of definitions, axioms, and relationships among concepts that describe EPC systems, which are integrated systems of enterprise process management and direct control (Scheer 1994; Sholten 2007) whose structure is compatible with the universal FSEPC. Contemporary integration standards for multilevel management and direct control systems are based on enterprise architecture frameworks (EAF), called also reference architectures. These reference architectures are proposed by certain research centres or by research groups that were established specially for this purpose (Bernus, Noran and Molina 2015; Kosanke, Vernadat and Zelm 1999; Noran 2003; Panetto 2007; Saha 2004; Vernadat 2002). For example, the ISA-95 standard is based on the Purdue Enterprise Reference Architecture (PERA) (Williams 1994). In the review paper (Bernus, Noran and Molina 2015) a “framework” concept is described by quoting this definition from the American Heritage Dictionary (2009), which states that it is “a set of assumptions, concepts, values, and practices that constitutes a way of viewing reality”. In the same dictionary a “theory” concept is similarly defined. A theory is “a set of statements or principles devised to explain a group of facts or phenomena, especially one that has been repeatedly tested or is widely accepted and can be used to make predictions about natural phenomena”. Therefore, the EPC theory may be regarded as a description of one of currently proposed frameworks for modelling enterprise architectures. The concepts of the EPC theory are defined deductively, beginning with the most general concepts and moving forward, step by step, to those related to the details of the EPC systems structure. The first part of the present version of the EPC theory (Zaborowski 2016a, 2016b) includes the information-decision (i-d) model of enterprise business processes, which is presented in this paper.
2.
Enterprise processes
The EPC theory is based on the observation that management is a special case of control, which is a goal-oriented action of an object, referred to as a controlling unit, upon another object, referred to as a control plant (Bubnicki 2005). In the case of management, each of these objects is a system with a complex internal structure. In EPC systems, control is decentralized in the hierarchical organizational structure, where control plants may be subordinate control systems
(Mesarović, Macko, and Takahara 1970), and in the multistage structure of cooperative relationships between delivery and receiving processes (Figure 1). Such a decentralized system may include all business processes (i.e., production, preparatory and managerial processes) for all organizational levels of an enterprise. act 2-1 proces-do-monografii
BusiPr
Business Process
CU
BusiPr CU
BusiPr
Controlling Unit
CU
BusiPr
Business Process
CU
BusiPr
Controlling Unit
CU
BusiPr CU
BusiPr Controlling Unit
BasePr
BasePr
BasePr
BasePr
BasePr
BasePr
CU
CU
CU
CU
CU
CU
INFRA
INFRA
INFRA
INFRA
INFRA
INFRA
Figure 1. Sketch of hierarchical and cooperative couplings between the controlling units of enterprise processes
According to EPC theory, enterprise processes, 𝑝 ∈ 𝑃𝑒𝑛𝑡, are divided into business processes, 𝑝 ∈ 𝑃, and base processes, 𝑝 ∈ 𝑃𝑏, 𝑃𝑒𝑛𝑡 = 𝑃 ∪ 𝑃𝑏,
𝑃𝑏 ∩ 𝑃 = ∅.
A business process is a system of control for a finite, partially ordered set of business activities that process resources or services into products, to fulfil the requirements of other business processes that belong to the enterprise or its environment. A business activity is the business process of a lower level or a base process that has no subordinate activities. Products of business processes may be resources or services, including information-processing services. A base process is a system that controls an infrastructural process. Each enterprise process has its own controlling unit, which controls its subordinate and delivery activities. In the illustrative process diagram (Figure 2), the unit that controls activities E, F and G, and belongs to process X, is hidden in the activity denoted by “prcX”. Similarly, the unit that controls activities J, K, L, M, and N of process F is hidden in activity “actF”. Business activities, 𝑎 ∈ 𝐴, are stages of business processes. In special cases, a business process may include only one activity. Conversely, every business process watched from the outside is a business activity (e.g., process F is an activity in process X). Therefore, the set of business processes is a subset of the set of business activities, 𝑃 ⊂ 𝐴. Base activities, 𝑎 ∈ 𝐴𝑏 ⊂ 𝐴, are such business activities on the lowest organizational level of the enterprise that have no subordinate business activities. A base activity is a base process that is seen from the outside. The controlling unit of a specific process determines its decisions on the basis of not only superordinate decisions but also the requirements, which are submitted by the controlling units of the receiving processes (e.g., the controlling unit of process F reacts to decisions from the controlling unit of process X and to orders from the controlling unit of the process G).
The enterprise is an independent organizational unit that is involved in the production of goods or services to satisfy the requirements of consumers or other enterprises. According to EPC theory, every organizational unit of an enterprise environment is regarded as a supplier or receiver of specific goods or services. An enterprise may be perceived as a component of different supply chains. A supply chain is “a global network of organizations that cooperate to improve the flows of material and information between suppliers and customers at the lowest cost and the highest speed. The objective of a supply chain is customer satisfaction” (Dolgui and Proth 2010). class 3-1a Czynności w procesach DiaOb prcW: A
prcY: A
a = 10
a = 12
prcX: A prcZ: A
prcU: A a = 62
a = 11 prcV: A
a = 13
a = 63
actE: A
actG: A
a = 21
a = 41
actF: A a = 31
actO: A
actQ: A
a = 22
a = 23
actK: A actL: A
actH: A a = 51
actJ: A
a = 71
a = 72
a = 61
actM: A
actN: A
a = 81
a = 91
Figure 2. An example of an EPML object diagram for activities in business processes
Business processes are performed by business systems, 𝑠 ∈ 𝑆, and business activities are performed by business units, 𝑢 ∈ 𝑈. In EPC systems, business units and business systems are identified by the identifiers of groups of all business activities and all the business processes performed by them. Therefore, as collected business activities and collected business processes, they are counted among business activities, 𝑢 ∈ 𝑈 ⊂ 𝐴,
𝑠 ∈ 𝑆 ⊂ 𝑃 ⊂ 𝐴.
Each specific business activity is executed by only one business unit. This fact is formally modelled by a composition relationship, in which the activity is a component of a specific business unit (Figure 3). Similarly, each business process is a component of a definite business system. These relationships are function dependencies, 𝑢 = 𝑢(𝑎) ∈ 𝑈, 𝑓𝑜𝑟 𝑎 ∈ 𝐴,
𝑠 = 𝑠(𝑝) ∈ 𝑆 ⊂ 𝑈, 𝑓𝑜𝑟 𝑝 ∈ 𝑃.
Business units are components of business systems (Figure 3). Conversely, business systems, if watched from the outside, are business units of a higher level, 𝑆 ⊆ 𝑈. In the structure tree of business units, the enterprise as a whole is the root. The hierarchical structures of business systems correspond to analogous structures of business processes (Figure 2). The difference between these structures is that composition relationships exist between business systems and units, whereas weak aggregation relationships
exist between business processes and activities. It means that a specific business activity may be a part of many business processes. Hierarchical and cooperative couplings between the controlling units of business systems are similar to those between the controlling units of business processes. class 4-6a drzew o struktury czynnosci biznesow ych
sys10: U
sys1: U
u = 33
sys11: U
u = 14
sys2: U
sys3: U
u = 24
prcX: A
prcW: A
sys4: U
u = 34
sys5: U
a = 11
u = 53
u = 54
sys6: U
sys7: U
u = 64
u = 74
u = 44
sys8: U u = 84
sys9: U u = 94
a = 12
a = 21
actO: A a = 22
actF: A
actQ: A
actG: A
a = 31
a = 23 actJ: A a = 61
actK: A a = 71
a = 41
actL: A a = 72
actM: A a = 81
prcV: A a = 63
a = 13 prcY: A
actE: A
a = 10
prcZ: A
prcU: A a = 62
actH: A a = 51
actN: A a = 91
Figure 3. Structure tree of the business units and business activities of an illustrative EPC system
Among all business systems, the organizational systems, 𝑠 ∈ 𝑆𝑜 ⊂ 𝑆, are particularly notable. Typical examples include the following: • the enterprise as a whole, • a work site, • a workshop, and • a workstation. The controlling unit of an organizational system controls its business processes. If the system is not elementary, its controlling unit also controls its executive units, 𝑢 ∈ 𝑈𝑥 ⊂ 𝑈, which are its subordinate organizational systems. Among business units, we distinguish organizational units, which include executive units and organizational segments, 𝑢 ∈ 𝑈𝑜 = 𝑈𝑥 ∪ 𝑈ℎ ⊂ 𝑈 ⊂ 𝐴. An organizational segment, 𝑢 ∈ 𝑈ℎ ⊂ 𝑈, is a set of parallel executive units that belong to the same organizational system and are grouped by similar products, which can be mutually substituted. Executive units may be also grouped if they share input resources, if their production technologies are similar and the like. Examples of organizational segments include the following: • departments of a work site (i.e., groups of its workshops) and • work centres of a workshop (i.e., groups of its workstations). The hierarchy of processes, the order of their activities and their goal to fulfil the requirements of product receivers are taken into account, though in different words, in the standards BPMN (2013), WFMC (1999) and Yet Another Workflow Language (YAWL) (Hofstede et al. 2010). Processes defined like in these standards are hereafter referred to as “standard business processes”. They are discussed at length in (van der Aalst and van Hee 2002; Iacob et al. 2012; Blackstone and Cox 2005; Davis and Brabander 2007; Reijers 2003; Smith and Fingar 2003; Weske 2012). Another well-known definition states that a business process consists
of an ordered collection of transaction types (Dietz 1999, 2006a, 2006b). These processes are here referred to as “transactional business processes”. A fundamental feature that distinguishes an “enterprise business process” from a standard or transactional process is the existence of a controlling unit (Figure 4). In standard and transactional processes, controlling units do not exist. Conversely, in the standards (BPMN 2013; Hofstede et al. 2010; WFMC 1999), substantial attention is paid to gateways and events, which, in EPC systems, belong to process controlling units and are not visible in process diagrams (Figure 2). Gateways and events may occur in information flow diagrams (section 5) as guard agents, which are special cases of business agents that process information inside controlling units.
3.
Control in business processes
3.1.
Business processes as control systems
The controlling unit of an enterprise process may be presented as a combination of the information unit and the decision unit (Figure 4). In the component control systems of hierarchical EPC systems, the control plants are sets of activities that belong to the business processes or infrastructural objects of the base processes. In a business process, a control plant is a set of subordinate business activities, which may include one or more elements. If the business activity is a base process, then its control plant is an infrastructural activity. In a general case, a given business process may be associated with many superordinate processes, many receiving processes, many delivery processes and many subordinate activities. Therefore, the controlling unit of a business process (Figure 5) may have relationships with many superordinate controlling units, many controlling units of delivery and receiving processes and many controlling units of subordinate activities.
act 5mid Processes as control systems
Controlling units of superordinate business processes
. . . decisions
information
Controlling units of superordinate business processes
...
...
Superordinate business activity
supervised measured variables Base business activity
supervising variables
...
Base process
Business process
Base controlling unit Controlling unit Decision unit
...
information ...
subordinate decisions
Information unit
subordinate information
...
Set of business activities Set of subordinate business processes
Base decision unit
...
... measured controlled variables
base controlling variables
Base information unit
real controlled and disturbing variables
Infrastructural activity Infrastructural process
Figure 4. Enterprise processes as control systems
...
act 6a 2-15koop Information flow betw een business processes
bussiness process Control unit of superordinate JedSter2 JedSter1
Information unit
Decision unit
Superordinate business activity
Superordinate delivery activities
business DeliveryActiv ity3 Activ ity2 process
superordinate decision variables
decision variables
Superordinate receiving activities
business Receiving ProcDost2 Proces odbiorcz process Controlling unit
Controlling unit order variables and return transfer variables
Controlling unit order variables and return cooperative variables
Business process superordinate information variables
Control units of superordinate business processes
...
zmienne sterowane
transfer variables and return order variables
transfer decision variables
decision variables
Decision unit
cooperat. decision variables
information variables Information unit
Decision unit
subordinate decision variables
Information unit Business activity
...
Decision unit
decision variables
information variables
Subordinate business process
information variables
controlled variables
cooperative variables and return order variables
. .. . .
Subordinate business . . . process
Business activity
Subordinate business process
subordinate information variables
Controlling unit subordinate decision variables
subordinate information variables
...
Subordinate business process
Information unit Business activity ...
Subordinate business process
...
Figure 5. Information flow between business process functional units
3.2.
Instants of discrete time
EPC systems are discrete-time control systems. It means that influence on control plants is allowed only at sampling time instants that are separated by sampling time periods. In management systems, sampling periods and sampling instants are often referred to as planning periods and intervention time instants, respectively. For any given intervention instant, reports (information) are processed first, and then, plans and orders (decisions) are made. Sampling instants (i.e., discrete-time instants) are identified by pairs, (𝑙, 𝑡) ∈ 𝐿𝑇 ⊂ 𝐿×𝑇, in which the identification number of time instants, 𝑡 ∈ 𝑇, obtains integer values from the interval determined by time scale number, 𝑙 ∈ 𝐿, 𝑡𝑙− ≤ 𝑡 ≤ 𝑡𝑙+ , 𝑓𝑜𝑟 𝑙 ∈ 𝐿. Sampling periods are identified by the same pairs (𝑙, 𝑡) ∈ 𝐿𝑇, which identify their end instants. The lengths of sampling periods, Δ𝑙 , are constant for a given time scale 𝑙 ∈ 𝐿. In EPC systems, no business activity on a given organizational level, 𝑙 ∈ 𝐿, can have an execution duration shorter than the length, Δ𝑙 , of the corresponding sampling period. In contemporary automatic control systems, on the level of direct control of manufacturing infrastructural processes, sampling periods are shorter than one second. In management systems,
planning periods depend on the organizational level of the enterprise. Higher levels correspond to longer planning periods. For example, sampling periods may be determined as follows: 𝑙 = 4 1 month for enterprises and for organizational systems of their environments, 𝑙 = 3 1 day (and night) for work sites of enterprises and their departments, 𝑙 = 2 1 hour for workshops and their work centres, and = 1 0.1v ariables second for workstations and their base processes. class 8 8mid𝑙functional 0..*
Ib Business v ariables
Ibg Business guard v ariables
Ig Guard v ariables
+initiating variables 0..*
1..* +
i: int 0..*
+ 1
1
IH I-D state v ariables
Io Process v ariables +
i: int
0..*
i: int
+ + +
1..*
Iz Realization v ariables 0..*
IHE Records of i-d state v ariables
Izg Realization guard v ariables
+
+ + + +
0..*
id _IH: int i: int h: int
1 0..* 1..*
i: int
0..*
1..*
IHK Agent acces to i-d state v ariables
0..* Oo Organizational obj ects
+
o: int
+ +
read() write()
Oz Realization obj ects
0..*
Ob Business obj ects
+ +
id_IHK: int i: int h: int k: int
1..*
2 E Business ev ents
j: int
p: int
+ 0..*
A Business activ ities +
+ + + +
id_IHLT: int i: int h: int l(i): int t: int
1 Jg Guard conditions
Pent Enterprise processes
1..*
+ + + + +
i: int
1
1..*
IHLT Signals of i-d state v ariables
O EPML obj ects
I Functional v ariables +
id_IHE: int i: int h: int e: int
K Elementary business agents
Kb Business agents
1..*
a: int
+
k: int
e: int
1
+
k: int
+
action()
0..*
1 1..*
Figure 6. Business agents and i-d state variables
3.3.
Business agents and business events Ax Czynności strukturalne units are functional {root}
Rx Produkty Mx Konta strukturalne strukturalne {root} {root} units of enterprise processes,
Zbiorcze Ix Zmienne Information unitsUxand decision 𝑘 ∈ 𝐾𝑗. Each czynności functional unit isstrukturalne an ordered set of business agents, 𝑘 𝐾𝑏, objects that are strukturalne designed + are rx: int + ∈mx: int which {root} + ax: int + o: int of elementary agents, + o: int the exception to process information and decisions. Business agents, with + o: int ux: int i: intalso may be ordered+ sets of subordinated business agents. Functional units, 𝑘 ∈ 𝐾𝑗 ⊂ 𝐾𝑏,+ are 1..* + ox: int S Business systems business agents. Each business agent belongs to a determined functional unit, a determined + inn: int U Jednostki organizacyjne controlling unit, and consequently, a determined enterpriseS Systemy processorganizacyj and a determined P Business processes + business o: int Ox Obiekty ne activity (Figure 6), strukturalne + p: int IH I-D state v ariables::I Zmienne𝑝(𝑘) funkcj onalne +
i: int
+
∈ 𝑃𝑒𝑛𝑡 ⊆ 𝐴,
s: int
𝑓𝑜𝑟 𝑘 ∈ 𝐾𝑏.
Each elementary business agent, 𝑘 ∈ 𝐾 ⊂ 𝐾𝑏, has exactly one business action, which is an operation that processes its input variables into output variables. It has also one operation of reading input variable and one operation of recording output variable. In EPC systems, elementary business agents are the only software objects that perform data processing operations. All other objects of these systems have only writing and reading operations. Input and output variables of business agents are i-d state variables, which are discussed in later sections. They are passive objects of business agents’ environments through which the agents can communicate. Business agents, including elementary agents, that belong to information units and to decision units, are referred to as information agents, 𝑘 ∈ 𝐾𝑏𝑖 ⊂ 𝐾𝑏, 𝑘 ∈ 𝐾𝑖 ⊂ 𝐾, or decision agents, 𝑘 ∈ 𝐾𝑏𝑑 ⊂ 𝐾𝑏, 𝑘 ∈ 𝐾𝑑 ⊂ 𝐾, respectively. The output variables of elementary information and decision agents are referred to as information variables, and decision variables, respectively. These variables are also output variables of functional units (Figure 5). According to EPC theory, every business event, 𝑒 ∈ 𝐸, is an execution of an elementary agent action (Figure 6). The duration of each business action is formally equal to 0, and all the action is attributed to a concrete discrete time instant. In practice, action execution durations are positive but are so short that the interval between the initial moment of the sampling period and the moment of the action end is imperceptible relative to the length of the sampling period. If this assumption cannot be fulfilled for a certain functional elementary agent, the agent should be substituted by a call agent, whose business action calls a substitute managerial business process. Each elementary agent has two guard conditions, 𝑗 ∈ 𝐽𝑔 (Figure 6). At the initial moment of each sampling period, all guard conditions are set to 0. At the action start moment of a specific agent, its action start blocking condition is set to 1. This causes that at a given discrete time instant, an elementary agent cannot act more than once. Immediately after the end of the action, the ending condition of the given agent is set to 1. This fact is one of action start conditions for all of its subsequent elementary agents. Business agents do not have direct couplings with other agents or with any other active objects. Elementary business agents, that are stimulated by clock impulses at consecutive discrete time instants, investigate the states of objects in their environment in order to decide whether begin their actions In this sense, elementary business agents are autonomous software objects (Lockemann 2006). Consequently, EPC systems are multiagent systems (Timm et al. 2006), which may be counted among multiagent control systems with passive interactions between agents (Monostori et al. 2015).
3.4.
Base control systems
Each control system that belongs to a given EPC system consists of its controlling unit and its control plant or plants. Each control plant, with the exception of infrastructural plants, is composed of a subordinate controlling unit and subordinate control plants. Consequently, the EPC system of an entire enterprise may be presented as a functional block diagram that includes only controlling units and infrastructural control objects (Figure 1). On the lowest organizational level, in a base control system, the control plant is an infrastructural process (Figure 4). The base controlling variables affect infrastructural control plants through their actuating devices. Decision variables in this case are supervising variables, and information variables are measured controlled variables and measured disturbances. In the case of a simple automatic control system, the base decision unit is a controller, and the base information unit is a measurement device. The exact values of controlled variables in a base control system are not known. They differ from corresponding information variables because of measurement errors. However, everybody knows that controlled variables depend on base controlling variables and on disturbances that arise from the infrastructural environment of the control plant. Consequently, measured controlled variables depend on both these variables and measurement errors. The measured values of controlled variables and selected disturbances are accessible as output variables of a base information unit.
3.5.
Hierarchical and cooperative couplings between enterprise processes
In EPC systems, information flows consist in recording values of variables, determined by elementary business agents, to memory places in the controlling units of individual business processes, and then in reading by other elementary agents. Information variables are remembered in the same controlling unit, which includes recording information agents (Figure 5). They are read • as controlled variables by a decision unit, • as superordinate information variables by information units of superordinate business processes, • and by other agents of the same information unit. Furthermore, information agents can generate • disturbance information variables, as illustrated by the dashed lines in Figure 5, that carry information on disturbances measured in a given process. Unlike information variables, the decision variables of EPC systems are remembered not in the controlling units from which they come but in the controlling units that include the decision agents that read their values. To clarify, decisions are remembered where they are to be executed. Decision variables are recorded as follows: • as superordinate decision variables by the decision units of superordinate business processes, • as order variables by the decision units of receiving processes, • as cooperative variables by the decision units of delivery processes that transfer information on the delivery products available to reception, • as return transfer variables by the decision units of receiving processes that transfer information on received business products (in particular, on the products that have been rejected), and • as return order variables by the decision units of delivery processes that transfer information on offers and rejected orders for delivery products. Furthermore, decision variables may be • subordinate decision variables that are recorded by the decision units of business processes in the decision units of subordinate processes. They may also be recorded by the decision units of base processes in the memory places of base controlling variables (Figure 4). According to the i-d model, controlled variables that carry information regarding finished orders are not directly transferred to a receiver, but are instead transformed into transfer decision variables that carry information on products that may be withdrawn. This procedure is necessary for products that may be allowed for different receivers.
4.
Enterprise process modelling language
4.1.
Object diagrams and EPML’s metamodel
EPC systems are IT systems; therefore, in modelling and designing these systems, UML (Booch, Rumbaugh, and Jacobson 1999) could be used, but the EPML (Zaborowski 2016a, 2016b), which is patterned after UML, is easier to learn. From many diagram types of UML only object diagrams are used. The only relationships between objects are associations. Therefore, EPML is much simpler than UML. Among associations, as for the UML standard, the composition and weak aggregation are distinguished. Unlike UML, the order relationships for EPML are also distinguished. They are represented by arrows (Figure 2). These relationships represent the sequence of activity executions, the flow of products between activities, the sequence of events, the information flow between software agents and the like.
Each EPML object, as an object of the EPC system software, includes its own set of attributes, its own set of operations that are executed on the attributes and its own set of relationships with other objects. On the other hand, each EPML object is an element of the set of all EPML objects in the concrete EPC system, 𝑜 ∈ 𝑂. The EPML metamodel, like ArchiMate’s metamodel (Iacob et al. 2012), is a set of class diagrams that impose definite relationships between EPML objects. A class of EPML objects is, as in UML, a generalization of a set of EPML objects that have the same attributes and operations and the same relationships with objects of other classes (Booch, Rumbaugh, and Jacobson 1999). Each class of EPML objects corresponds to the one of the concepts of EPC theory. The relationships between these concepts are visualized in class diagrams of the EPML metamodel as relationships between corresponding classes. The EPML metamodel is identical for every enterprise. However, in a specific EPC system, its classes represent finite sets of objects, whereas the relationships between the classes represent sets of relationships between the objects that belong to the sets. The illustrative object diagrams (Figures 2 and 3) correspond to a fragment of the class diagram shown in Figure 7. In practice, EPML object diagrams will be applied to modelling • • • •
order and weak aggregation relationships between business activities (Figure 2), product flows between business activities (Zaborowski 2016a), order relationships between business agents (Figure 8), and information flows between business agents (Figure 8).
EPML, like ArchiMate (Iacob et al. 2012) and UEML (Vernadat 2002), may be used to model enterprise architecture. Diagrams constructed using these languages for concrete enterprises present the relationships between objects of their architectures, but the metamodels which determine areas of modelled facts, are different. In practice it is also important that models constructed in EPML are executable. This implies that properly adapted CASE systems can be used to generate the software of concrete EPC systems. The FSEPC is a software framework for developing EPC systems, whose structure is determined by the EPML metamodel.
4.2.
Business objects and realization objects
Business products, 𝑟 ∈ 𝑅, exist as resources or services of work in progress, or as finished business products. The first ones are input products that are withdrawn to business activities and waiting for the termination of the activity executions. The second ones are resources or services that are performed in business activities and can be withdrawn through their receiving activities. Business products are recorded in work in progress accounts and in accounts of finished products, respectively. Business accounts, 𝑚 ∈ 𝑀, that belong to a determined business activity are places of information on this activity and its executions. In EPC systems, business products are components of business accounts, and business accounts are components of business activities (Figure 7). Business activities, including business units, as well as business accounts and products, are counted among business objects: 𝑜 ∈ 𝑂𝑏 ⊃ 𝐴 ∪ 𝑀 ∪ 𝑅,
𝑂𝑏 ⊂ 𝑂.
Each business unit, 𝑢 ∈ 𝑈, is an organizational unit or is attributed to exactly one directly superordinate organizational unit, 𝑢𝑜 (𝑢) ∈ 𝑈𝑜 (Figure 7). On the other hand, each organizational object, 𝑜 ∈ 𝑂𝑜 ⊃ 𝐴𝑜 ∪ 𝑀𝑜 ∪ 𝑅𝑜, is a business object that belongs to an organizational unit,
𝑢 = 𝑢(𝑜) ∈ 𝑈𝑜,
𝑓𝑜𝑟 𝑜 ∈ 𝑂𝑜.
Therefore, a business object, 𝑜 ∈ 𝑂𝑏, that belongs to a specific business unit is attributed to the corresponding organizational object, 𝑜 𝑜 (𝑜) ∈ 𝑂𝑜, which belongs to the organizational unit that includes this business unit (figure 7). class 7 7mid business obj ects Uo Organizational units +
0..*
u: int
So Organizational systems
Oo Organizational obj ects
1..*
1
1..*
1
+
S Business systems +
s: int 1..*
Ob Business obj ects
P Business processes
s: int
1..* +
p: int
0..* 1..*
1..*
U Business units +
R Business products
0..* 0..*
1..* A Business activ ities
u: int
+
1..*
1..*
1..*
a: int
+
M Business accounts +
m: int 0..*
0..*
0..*
D Deliv ery activ ities
1..*
C Receiv ing activ ities
0..*
Q Business task products
1 +
+
0..*
d: int
+
c: int
+
1
1..*
Z Business tasks +
zu: int
1
q: int
B Aggregated products of business tasks
0..* Zu Collected business tasks
r: int
1..*
+
b: int
0..* Oz Realization obj ects
z: int
Figure 7. Class diagram for relationships between business and realization objects
The terms “business process” and “business activity” may be understood, depending on the context Ux andZbiorcze on accepted convention, as a model or as an instance of a given process or activity Ax Czynności Mx Konta czynności strukturalne (Weske 2012). According to the EPC theory, these terms strukturalne are assumed to refer Rx toProdukty the models, strukturalne strukturalne {root} {root} whereas the concrete realizations of business processes and activities are referred to as business {root} O+ Obiekty ux: int ax: int 𝑧 ∈ 𝑍, respectively. A business task is a single or serial works, 𝑤 +∈ 𝑊 ⊂ 𝑍, and business tasks, + mx: int + rx: int 𝑢 o: int Ox𝑧Obiekty o: int execution of a business activity.+ EPML The collected business+ task, ∈ 𝑍𝑢, is an+ execution of a o: int strukturalne + unit, o: int 𝑢 ∈ 𝑈 (Figure 7). collected activity of the business Business task products, 𝑞 ∈ 𝑄, are business products that are attributed to definite + czytaj() + zapisz() business tasks. Groups of business task products, 𝑏 ∈ 𝐵, that are recorded in specific business U Jednostki organizacyjne accounts are referred to as aggregated products oforganizacyj businessnetasks. Unlike abstract business S Systemy products,Pent business task products are concrete products attributed to definite business accounts and Procesy + s: int concrete business tasks. Business tasks and their products are referred to as realization objects, przedsiębiorstw a +
p: int
𝑜 ∈ 𝑂𝑧 ⊃ 𝑍 ∪ 𝐵 ∪ 𝑄,
𝑂𝑧 ⊂ 𝑂,
because they are concrete realizations of business activities and products (Figure 7).
4.3.
Functional variables
The changeable attributes of organizational objects are referred to as process variables, 𝑖 ∈ 𝐼𝑜 (Figure 6). One process variable may correspond to many functional variables, 𝑖 ∈ 𝐼, which are information variables, 𝑖 ∈ 𝐼𝑖 ⊂ 𝐼, or decision variables, 𝑖 ∈ 𝐼𝑑 ⊂ 𝐼, 𝑖 ∈ 𝐼 = 𝐼𝑖 ∪ 𝐼𝑑,
𝐼𝑖 ∩ 𝐼𝑑 = ∅,
that are processed by the functional units of enterprise processes (Figure 5). Functional variables are divided into business variables and realization variables, 𝑖 ∈ 𝐼 = 𝐼𝑏 ∪ 𝐼𝑧. The business variables, 𝑖 ∈ 𝐼𝑏 ⊂ 𝐼, and realization variables, 𝑖 ∈ 𝐼𝑧 ⊂ 𝐼, are associative objects that represent the associations of process variables with elementary business agents and the associations of business variables with realization objects, respectively (Figure 6). Each business variable is attributed to exactly one process variable, and each realization variable is attributed to exactly one business variable. Business and realization variables are the corresponding attributes of business and realization objects and, formally, are their components. Among these variables, one can distinguish business guard variables, 𝐼𝑏𝑔 ⊂ 𝐼𝑏, and realization guard variables, 𝐼𝑧𝑔 ⊂ 𝐼𝑧. The guard variables, 𝑖 ∈ 𝐼𝑔 = 𝐼𝑏𝑔 ∪ 𝐼𝑏𝑧 are binary functional variables that are used to control the executions of elementary agent actions. The set of functional variables includes the following: • • • • •
quantity variables, e.g., the quantities and flow rates of products, production costs of specific products, and income of an enterprise; quality variables, e.g., length, diameter, colour, and temperature; time variables, e.g., the due date of a business task; existential variables – i.e., binary variables that indicate whether specific organizational objects exist; and guard variables.
5.
Information processing in business processes
5.1.
Information-decision state variables
Information flow in every IT system consists in recording the system memory and in reading at the same discrete time instant or at a later moment in time. In EPC systems, each functional variable has a definite time scale, 𝑙(𝑖) ∈ 𝐿,
𝑓𝑜𝑟 𝑖 ∈ 𝐼,
that determines the frequency at which its values are observed. In control systems, the variables attributed to a specific moment in time are often referred to as signals (Bubnicki 2005). Therefore, the values of functional variables, 𝑖 ∈ 𝐼, recorded at sampling instants, (𝑙, 𝑡) ∈ 𝐿𝑇,
𝑦𝑖 (𝑙, 𝑡) = 𝑦𝑖 (𝑙(𝑖), 𝑡) = 𝑦𝑖 (𝑡) are values of the signals of functional variables, (𝑖, 𝑙, 𝑡) ∈ 𝐼𝐿𝑇 ⊂ 𝐼×𝐿×𝑇 Knowledge of the current values of functional variables is not sufficient to control enterprise processes. One should also know their values at specific past and future sampling instants. In other words, one should know the i-d state of an EPC system at a given discrete time instant – i.e, a set of current information as well as past information, forecasts and decisions that have been previously remembered and are required for making decisions and forecasts regarding the future values of functional variables. The value, 𝑥𝑖 (𝑙, 𝑡, ℎ) = 𝑥𝑖ℎ (𝑙, 𝑡), of a signal, (𝑖, ℎ, 𝑙, 𝑡) ∈ 𝐼𝐻𝐿𝑇 ⊂ 𝐼×𝐻×𝐿×𝑇, of an i-d state variable, (𝑖, ℎ) ∈ 𝐼𝐻 ⊂ 𝐼×𝐻, at a specific time instant, (𝑙, 𝑡) ∈ 𝐿𝑇 ⊂ 𝐿×𝑇, is equal to the value of a signal of a functional variable that is shifted in time by a definite number of sampling periods, ℎ ∈ 𝐻, of the time scale, 𝑙 ∈ 𝐿, applied to this functional variable, 𝑥𝑖ℎ (𝑙, 𝑡) = 𝑦𝑖 (𝑙, 𝑡 + ℎ),
𝑓𝑜𝑟 ℎ𝑖− ≤ ℎ ≤ ℎ𝑖+ , 𝑖 ∈ 𝐼, (𝑙, 𝑡) ∈ 𝐿𝑇.
(1)
Conversely, the value of a signal of a functional variable is equal to the value of the signal of the i-d state variable with a zero time shift: 𝑦𝑖 (𝑙, 𝑡) = 𝑥𝑖ℎ (𝑙, 𝑡) | ℎ = 0 ∧ (𝑖, ℎ) ∈ 𝐼𝐻,
𝑓𝑜𝑟 𝑡𝑙− ≤ 𝑡 ≤ 𝑡𝑙+ , 𝑙 ∈ 𝐿, 𝑖 ∈ 𝐼.
(2)
Formally, an i-d state variable is a component of a functional variable (Figure 6) and, indirectly, a component of a specific business object, a specific business activity and a specific business unit. One functional variable may correspond to many i-d state variables. I-d state variables, like functional variables, are separated into information state variables, (𝑖, ℎ) ∈ 𝐼𝐻𝑖 ⊂ 𝐼𝐻, and decision state variables, (𝑖, ℎ) ∈ 𝐼𝐻𝑑 ⊂ 𝐼𝐻. Moving to a new discrete time instant does not change the values of i-d state variables but does change their identifiers. Therefore, immediately after creating (by a clock) a new sampling instant, 𝑡 ∈ 𝑇, for a given time scale, 𝑙 ∈ 𝐿 (𝑙, 𝑡) ≔ (𝑙, 𝑡 + 1),
(3)
and prior to making current information on the i-d state, one should decrease the values of the time shifts of i-d state variables by 1 relative to the current time instant, as follows: 𝑥𝑖,ℎ (𝑙, 𝑡) ≔ 𝑥𝑖,ℎ+1 (𝑙, 𝑡 − 1),
𝑓𝑜𝑟 𝑖 ∈ 𝐼, ℎ𝑙− ≤ ℎ ≤ ℎ𝑙+ − 1, (𝑙, 𝑡) ∈ 𝐿𝑇.
(4)
Business events that are regarded as executions of elementary agents, may insert the records of i-d state variables, (𝑖, ℎ, 𝑒) ∈ 𝐼𝐻𝐸 ⊂ 𝐼𝐻×𝐸, in the system memory. Each record (𝑖, ℎ, 𝑒) of an i-d state variable (𝑖, ℎ) is also an effect of one definite event, 𝑒 ∈ 𝐸, and is a formal component of this variable (Figure 6). Each record of an id state variable corresponds to the i-d state variable signal at the instant the record is created and, perhaps, to the signals at certain future time instants.
5.2
Business agents’ access to i-d state variables
The information flow inside a controlling unit of a given enterprise process (Figure 5) may be illustrated in the form of a functional block diagram (Figure 8), in which agents are function blocks with definite cause-result dependencies between input and output variables. Consequently, the functional block diagram of an entire EPC system, which is a network of controlling units that work in component control systems (Section 3.4), may be presented as a network of functional units (section 3.3) and also as a network of elementary agents separated by the memory places of i-d state variables, whose structure is similar to the coloured Petri nets (Jensen 1997). This conclusion is also relevant for any coherent fragment of the entire EPC system, in which individual agents may belong to different enterprise processes. The input and output variables of elementary agents, 𝑘 ∈ 𝐾, are i-d state variables, (𝑖, ℎ) ∈ 𝐼𝐻. Specifically, these variables may be state variables that represent functional variables, 𝑖 ∈ 𝐼, i.e., state variables with zero time shifts relative to functional variables, (ℎ = 0). Each i-d state variable is an output variable of one specific elementary agent, 𝑘(𝑖, ℎ) = 𝑘 𝑟𝑒𝑐 (𝑖) ∈ 𝐾,
𝑓𝑜𝑟 (𝑖, ℎ) ∈ 𝐼𝐻, 𝑖 ∈ 𝐼,
which can record its values. In a class diagram (Figure 6), this regularity is illustrated in the form of corresponding association relations. The unambiguous attribution of each i-d state variable of an EPC system to an agent recording its values may suggest that it is a state variable of this agent. However, this is not the case. The i-d state variables are remembered in the controlling units of enterprise processes and are components of these processes, but they do not belong to elementary agents or functional units of the processes (Figure 5). Business agents are static objects that have no state. However, the controlling units of enterprise processes, as networks of business agents and state variables, are dynamic systems because at specific time instants the values of the output variables of agents depend on the values of their input variables at instants shifted in time. The access of elementary agents to i-d state variables is represented by the following associations: (𝑗, 𝑞, 𝑘) ∈ 𝐼𝐻𝐾 ⊂ 𝐼𝐻×𝐾, that indicate the agents, which may read the values of individual variables. These associations are referred to as inputs of i-d state variables because they identify the values, 𝑖𝑛 (𝑙, 𝑡), 𝑥𝑗,𝑞,𝑘
of input variables, (𝑗, 𝑞) ∈ 𝐼𝐻, that may be read by elementary agents, 𝑘 ∈ 𝐾, (Figure 8) at discrete time instants, (𝑙, 𝑡) ∈ 𝐿𝑇. Each input of an i-d state variable corresponds to exactly one input of a functional variable to the elementary agent, (𝑗, 𝑘) ∈ 𝐼𝐾 ⊂ 𝐼×𝐾.
class 9e Information flow block diagram inf block 1 ag1
st1
inf block 3
x1,2
x
in
x
in
dec block 2 ag2
st2
1,2,3
1,2,4
ag3
st3
dec block 4 ag4
x2,1
inf block 5
x3,1
x
x4,2
x
in
3,1,5
ag5
st5
dec block 6 in
4,2,6
st4
ag6
st6
xin2,1,4 dec block 7
xin4,2,7
ag7
st7
current
InfAg1: K k=1
St12: IH
InfAg3: K
i=1 h=2
k=3
St31: IH
InfAg5: K
i=3 h=1
k=5
previous
DecAg6: K DecAg4: K
DecAg2: K k=2
current
k=4
St21: IH i=2 h=1
i=4 h=2 previous
InfAg1: K
InfAg3: K
k=1
k=3
St42: IH
k=6 DecAg7: K k=7
InfAg5: K k=5 DecAg6: K k=6
DecAg2: K
DecAg4: K
k=2
k=4
DecAg7: K k=7
Figure 8. An example of the memory places of i-d state variables in block diagrams of the information flow in EPC systems
Elementary agents lack memory, and all information regarding the state of EPC systems is placed in objects of the passive interaction between agents (Figure 8). It is an important feature of these systems. In particular, it is a reason why the memory of decisions regarding enterprise processes may be attributed to these processes rather than the processes during which the decisions were made. For example, the decision variable, (𝑖, ℎ) = (4,2), of agent 𝑘 = 4 (Figure 8), is not remembered in the controlling unit of the process to which this agent belongs but in the controlling unit of another process, which includes agents 𝑘 = 6 and 𝑘 = 7.
5.3.
Procedures of i-d state changes
The i-d state of a given EPC system changes only as a result of the actions of elementary business agents that record new values for their output variables to the system memory. An i-d state variable may not be recorded by different agents. On the other hand, at a specific discrete time instant, no elementary agent can act more than once (Section 3.3). Therefore, at a specific time
instant, one can put into memory only one record of a given i-d state variable, and this variable cannot change at this instant more than once. If an i-d state variable changes at a specific time instant, then in this instant, it possesses two values: the “previous” one and the “current” one. This fact does not cause problems because at a given instant, elementary agents act in a definite order that is unambiguously determined by corresponding EPML object diagrams (Figure 8). After executing the business actions of all the elementary agents that should act at a given instant, the values of their output variables are “current”. At the next instant, immediately after substitutions (4), they become previous values of the i-d state variables. The business actions of functional agents are divided into procedural and non-procedural actions. For procedural actions, definite cause-result dependencies exist between their input and output variables. 𝑖𝑛 (𝑙, 𝑡) | (𝑗, 𝑞, 𝑘(𝑖, ℎ)) ∈ 𝐼𝐻𝐾), 𝑥𝑖ℎ (𝑙, 𝑡) ≔ 𝐹𝑖ℎ ((𝑙, 𝑡), 𝑥𝑗,𝑞,𝑘(𝑖,ℎ)
(5)
𝑓𝑜𝑟 (𝑖, ℎ) ∈ 𝐼𝐻, (𝑙, 𝑡) ∈ 𝐿𝑇. This formula is adequate regardless of whether the action of the agent, 𝑘(𝑖, ℎ), is a complex optimization procedure or a calculation of the value of a simple Boolean expression. The dependency (5) is a substitution. On the left is a current value for an output state variable, (𝑖, ℎ). On the right are previous or current values for the input variables (𝑗, 𝑞) of the agent, 𝑘(𝑖, ℎ). It is possible that among these values there is a previous value of the same variable which is also the output variable (𝑖, ℎ) that has a current value recorded by the agent, 𝑘(𝑖, ℎ). Procedural actions are separated into automatic and modifiable actions. For automatic actions, the values of output variables are automatically recorded to their memory places without modifications by the users of the EPC systems. 𝑖𝑛 (𝑙, 𝑡) | (𝑗, 𝑞, 𝑘(𝑖, ℎ)) ∈ 𝐼𝐻𝐾), 𝑥𝑖ℎ (𝑙, 𝑡) ≔ 𝐹𝑖ℎ (𝑥𝑗,𝑞,𝑘(𝑖,ℎ)
(6)
𝑓𝑜𝑟 (𝑖, ℎ) ∈ 𝐼𝐻, (𝑙, 𝑡) ∈ 𝐿𝑇. In the case of modifiable actions, direct dependency on time, (𝑙, 𝑡), indicates that authorized employees of the enterprise may correct the results of the procedure. For non-procedural actions, functional elementary agents serve to record the source information that are introduced by measurement devices or users. The agents may also record decisions made by employees of the enterprise either without specific rules or with rules that are not formally known. The output variables of non-procedural actions may vary in time but they do not depend on any input variables, 𝑥𝑖ℎ (𝑙, 𝑡) ≔ 𝐹𝑖ℎ (𝑙, 𝑡),
𝑓𝑜𝑟 (𝑖, ℎ) ∈ 𝐼𝐻, (𝑙, 𝑡) ∈ 𝐿𝑇
(7)
5.4. State equations of EPC systems From the general dependency (5) one can derive the state equations of an EPC system, 𝑖𝑛 𝑠𝑡 (𝑙, 𝑡) | (𝑗, 𝑞, 𝑘 𝑠𝑡 (𝑖, ℎ)) ∈ 𝐼𝐻𝐾𝑠𝑡), 𝑥𝑖ℎ (𝑙, 𝑡 + 1) = 𝐹𝑖,ℎ (8) ((𝑙, 𝑡), 𝑥𝑗,𝑞,𝑘(𝑖,ℎ) 𝑓𝑜𝑟 (𝑖, ℎ) ∈ 𝐼𝐻, (𝑙, 𝑡) ∈ 𝐿𝑇,
that refer to current values of i-d state variables at discrete-time instants (𝑙, 𝑡 + 1) and (𝑙, 𝑡). According to the commentary on the formula (4) they are “previous” values observed before 𝑠𝑡 changes that occur at these instants. The function 𝐹𝑖,ℎ represent the action procedure of the 𝑠𝑡 (𝑖, substitute business agent 𝑘 ℎ), that is composed of all action procedures which are executed
consecutively at the instant (𝑙, 𝑡) and whose final result is the value 𝑥𝑖ℎ (𝑙, 𝑡 + 1) of the i-d state variable (𝑖, ℎ) at the instant (𝑙, 𝑡 + 1). I-d state variables from all organizational levels may be related to the same time scale (of the lowest level). Then, after creating the i-d state vector 𝒙, whose coordinates are values of i-d state variables 𝑥𝑖ℎ (𝑡), the i-d state equations may be presented in the vector form 𝒙(𝑡 + 1) = 𝑭𝑠𝑡 (𝑡, 𝒙(𝑡)),
𝑓𝑜𝑟 𝑡 ∈ 𝑇
(8a)
or 𝒙𝑡+1 = 𝑭𝑠𝑡 (𝑡, 𝒙𝑡 ),
𝑓𝑜𝑟 𝑡 ∈ 𝑇
(8b)
Each EPC system is a closed system. All output variables of all business agents are i-d state variables, and all input variables are output variables of business agents that belong to a given EPC system. It does not mean that EPC systems have no outside influences. In equations (8,8a,8b) they are represented by explicit dependency of certain i-d state variables on time.
6.
Conclusions
For EPC theory the models of business processes are much more detailed than the models compatible with the BPMN standard. To model the structures of concrete business processes and the details of the structures of process management systems, one can utilize EPML diagrams, which are UML object diagrams that fulfil the structural constraints of the FSEPC imposed by the class diagrams of the EPML metamodel. The structure of the diagrams of information flow between business agents is similar to that of functional block diagrams, which are applied according to the classical control theory. Therefore, the EPC theory may facilitate transferring the results of the classical control theory to the systems of enterprise management, e.g., to analyse enterprise stability and controllability. EPC theory differs significantly from the currently dominant standards of modelling business processes. Furthermore, the concept of the i-d state, which is a component of this theory, differs from the concept of the state of dynamic systems, which is used in traditional control theory. A significant number of new concepts and new interpretations of concepts that belong to three different domains—cybernetics, informatics and management science—may discourage interest in EPC theory. Therefore, in addition to the cognitive values discussed previously, one should show the practical benefits that could result from its application. In practice it is important, that the EPML metamodel is a set of UML class diagrams. So, the models of EPC systems in the form of EPML object diagrams, supplemented by the repository of procedures of elementary business agents, are executable models of EPC system software. Therefore, the FSEPC could be implemented as an extension of a selected CASE system. Thus, it would be not only a framework for comparing different management methods and algorithms but also a software framework for designing and generating software for concrete integrated management and direct control systems. The controlling units of business processes are replaceable building blocks in the software when generated in this manner. In EPC systems, reengineering any business process relies on embedding to it the entire controlling units of new sub-processes and on removing the controlling units of the sub-processes that are selected for elimination. This type of reengineering of business processes is also reengineering of the enterprise software. It eliminates the “business-IT divide” problem described in the introduction. Funding This work was supported by the University of Dabrowa Gornicza.
References Bernus, P., O. Noran, and A. Molina. 2015. "Enterprise architecture: Twenty years of the GERAM framework." Annual Reviews in Control 39: 83–93. doi: 10.1016/j.arcontrol.2015.03.008. Blackstone, J. H., and J. F. Cox. 2005. APICS Dictionary. 11th ed. Falls Church, VA: American Production and Inventory Control Society. Booch, G., J. Rumbaugh, and I. Jacobson. 1999. The Unified Modelling Language. User Guide. Boston: Addison-Wesley. BPMN. 2013. "Business Process Model and Notation,” Ver.2.0.2, OMG. Bubnicki, Z. 2005. Modern Control Theory. Berlin: Springer-Verlag. Davis, R., and E. Brabander. 2007. Aris Design Platform: Getting Started with BPM. Berlin: Springer-Verlag. Dietz, J. L. G. 1999. "Understanding and Modelling Business Processes with Demo." In Conceptual Modeling – ER’99, edited by J. Akoka, M. Bouzeghoub, I. Comyn-Wattiau and E. Métais, LNCS 1728,188–202. Berlin: Springer-Verlag. Dietz, J. L. G. 2006a. "The Deep Structure of Business Processes." Communications of ACM 49 (5): 58–64. doi: 10.1145/1125944.1125976. Dietz, J. L. G. 2006b. Enterprise Ontology: Theory and Methodology. Berlin: Springer-Verlag. Dolgui, A., and J. M. Proth. 2010. Supply Chain Engineering: Useful Methods and Techniques. London: Springer. Hofstede, A. H. M., W. van der Aalst, M. Adams, and N. Russell. 2010. Modern Business Process Automation: YAWL and Its Support Environment. Berlin: Springer. Iacob, M., H. Jonkers, M. Lankhorst, E. Proper, and D. A. Quartel. 2012. Archimate 2.0 Specification. The Open Group. Jensen, K. 1997. Coloured Petri Nets. Berlin: Springer. Kosanke K., Vernadat F., Zelm M. 1999. “CIMOSA: enterprise engineering and integration”. Computers in Industry 40 (2-3): 83-97. Langenwalter, G. A. 2000. Enterprise Resources Planning and Beyond: Integrating Your Entire Organization. New York: St. Lucie Press. Lockemann, P. C. 2006. Multiagent Engineering: Theory and Applications in Enterprises, edited by S. Kirn, O. Herzog, P. Lockemann and O. Spaniol, 17–34. Berlin: SpringerVerlag. Mesarović, M. D., D. Macko, and Y. Takahara. 1970. Theory of Hierarchical, Multilevel, Systems. New York: Academic Press. Monostori, L., P. Valckenaers, A. Dolgui, H. Panetto, M. Brdys, and B. C. Csáji. 2015. "Cooperative Control in Production and Logistics." Annual Reviews in Control 39: 12– 29. doi: 10.1016/j.arcontrol.2015.03.001. Noran, O. 2003. “An analysis of the Zachman framework for enterprise architecture from the GERAM perspective”. Annual Reviews in Control 27: 163-183. Panetto, H. 2007 "Towards a classification framework for interoperability of enterprise applications". International Journal of Computer Integrated Manufacturing, vol. 20 (8): 727–740. doi: 10.1080/09511920600996419. Reijers, H. 2003. Design and Control of Workflow Processes. Vol. 2617. Berlin: SpringerVerlag. Saha P.: Analyzing TOGAF from the GERAM perspective. . Scheer, A.-W. 1994. CIM (Computer Integrated Manufacturing) – Towards the Factory of the Future. Berlin: Springer-Verlag. Scholten, B. 2007. The road to integration. A guide to applying the ISA-95 standard in manufacturing. Research Triangle Park, NC: ISA Publ. Smith, H., and P. Fingar. 2003. Business Process Management: The Third Wave. Tampa, FL: Meghan-Kiffer Press.
The Editors of the American Heritage Dictionaries, 2009. The American Heritage Dictionary of the English Language. 4th ed. Boston: Houghton Mifflin Harcourt. Timm, I. J., T. Scholz, O. Herzog, K. Kremples, and O. Spaniol. 2006. "From Agents to Multiagent Systems." In Multiagent Engineering: Theory and Applications in Enterprises, edited by S. Kirn, O. Herzog, P. Lockemann and O. Spaniol, 35–52. Berlin: Springer-Verlag. Van der Aalst, W., and K. M. van Hee. 2002. Workflow Management: Models, Methods, and Systems Cooperative Information Systems Series. Cambridge: MIT Press. Vernadat, F. 2002. "UEML: Towards a unified enterprise modelling language." International Journal of Production Research 40 (17): 4309–4321. doi: 10.1080/00207540210159626. Weske, M. 2010. Business Process Management: Concepts, Languages, Architectures. Berlin: Springer-Verlag. WFMC. 1999. "Terminology and Glossary,” Doc. N. Wfmc-Tc-1011, Issue 3.0. Williams, T. 1994. "The Purdue Enterprise Reference Architecture". Computers in Industry 24 (2-3): 141–158. Zaborowski, M. 2011. "The EPC II Theory. Review of basic concepts, obtained results and problems to discuss." Management and Production Engineering Review 2 (4): 66–89. Zaborowski, M. 2016a. Introduction to the Theory of Enterprise Process Control, pp 142. Publ. University of Dabrowa Gornicza, ISBN 978-83-64927-94-2. (in Polish) Zaborowski, M. 2016b. "Generalization and Composition Relationships between Objects of Enterprise Process Control Systems." In Proceedings of the 11th Scientific Conference Internet in the Information Society 2016, edited by M. Rostański, P. Pikiewicz, P. Buchwald and K. Mączka, 405–418. Publ. University of Dabrowa Gornicza.
Figure captions Figure 1. Sketch of hierarchical and cooperative couplings between the controlling units of enterprise processes. Figure 2. An example of an EPML object diagram for activities in business processes. Figure 3. Structure tree of the business units and business activities of an illustrative EPC system. Figure 4. Enterprise processes as control systems. Figure 5. Information flow between business process functional units. Figure 6. Business agents and i-d state variables. Figure 7. Class diagram of the relationships between business and realization objects. Figure 8. An example of the memory places of i-d state variables in block diagrams of the information flow in EPC systems.
