A Knowledge-based Approach to Business Analysis for Process Innovation Michele Missikoff Istituto di Analisi dei Sistemi ed Informatica del CNR. Via dei Taurini 19, 00185 Rome, Italy Abstract This paper proposes a methodology for business process analysis, conceived in the context of business process (BP) innovation. The proposal, part of a more encompassing methodology referred to as EasInnova, addresses business process analysis as a knowledge management project. It is based on the progressive construction of a knowledge base about the business organization and, specifically, the process to be innovated. The method has been conceived to be easily adopted by business people without knowledge management experience, keeping them at the centre of the business analysis and, eventually, the application software development. After a brief description of the EasInnova methodology, the paper focuses on the acquisition and management of knowledge about the structural (avoiding the behavioural) aspects of the BP to be transformed, and the construction of the corresponding models. The method is characterised by a progressive approach. It consists in the production of a sequence of six different knowledge artefacts that go from more intuitive, and easy to be managed, plain text descriptions to a more structured semantic table, to a diagrammatic representation. The final knowledge artefact is represented by a BP ontology, i.e., a formal representation of the knowledge about the BP and is operating scenario. Keywords 1 Business Analysis, Business Process Innovation, Knowledge Representation, Lexicon, Class Diagram, Ontology 1. Introduction Enterprise innovation consists in the transformation of some business (e.g., organization, processes, products, services, etc.) in order to gain a given advantage (e.g., in terms of cost, time, quality). Within enterprise innovation, business process (BP) innovation [1] assumes a central position, in fact it cannot be considered in isolation with respect to other elements of the enterprise. Even if our initial focus is on the innovation of a specific BP, we need to consider other connected business elements, such as the documents, the organization, the enterprise structure, the roles and skills of the involved people. Conversely, if our focus is on, say, product innovation, then we are forced to change the involved processes as well. For these reasons, business process innovation is one of the most strategic field of a dynamic enterprise. In this paper we propose a method for BP Analysis (BPA) that is positioned in the context of a methodology, called EasInnova [2], aimed at supporting business process innovation. EasInnova is based on the idea that process innovation is essentially a „knowledge management affair‟. In fact, to carry out a successful innovation, you need to start from a solid base of knowledge (about the enterprise, the process, various methods and tools, etc.) and, during the innovation activities, one of the major endeavours is the acquisition and organization of knowledge. Eventually, the outcome consists in the implementation of a new business solution, together with a rich, articulated body of SEBD 2021: The 29th Italian Symposium on Advanced Database Systems, September 5-9, 2021, Pizzo Calabro (VV), Italy EMAIL: Michele.missikoff@iasi.cnr.it ORCID: 0000-0002-7972-5201 2020 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR Workshop Proceedings (CEUR-WS.org) knowledge, (referred to as InnoBok, Innovation Body of Knowledge) [3] that remains as a strategic knowledge asset for the enterprise. Seen the complexity of knowledge management in any (non-trivial) business innovation project, the EasInnova methodology proposes a set of guidelines, organised according to a vertical and a horizontal dimension. Along the vertical dimension EasInnova adopts the Model-Driven Architecture (MDA) scheme [4] where enterprise knowledge, and the corresponding models, are organised according to three layers.  Computation Independent Models (CIM),  Platform Independent Models (PIM),  Platform Specific Models (PSM). Along the horizontal dimension, enterprise innovation take place following three stages: in the first stage, referred to as AsIs, the aim is to build models representing the existing business scenario. The second stage, business transformation (BTran), aims at identifying the issues, the possible solutions, and the activities necessary to move from AsIs to the new innovative scenario. The latter, referred to as ToBe scenario, aims at a full specification and modeling the innovative solution and the scenario resulting from its adoption. The three horizontal stages cut across the three MDA layers, giving place to the EasInnova matrix. The rest of the paper is organised as follows. The next section proposes an overview of the EasInnova Methodology, followed, in Section 3, by the related work in the area of business process innovation. Then, in Section 4, we illustrate the BPA methodology by means of a running example. Finally, Section 5 presents the conclusions and some ideas for a future work. 2. The EasInnova methodology As anticipated, the reference scheme of EasInnova is based on the matrix obtained by intersecting the two dimensions, i.e., the three vertical MDA layers and the three horizontal stages. In essence, we obtain the 3 x 3 EasInnova matrix defined as: (1) where ( ) represent the steps of the methodology, with . The methodology provides a set of guidelines that an innovation team can follow by traversing the EI matrix left to right and top down. The traversal is primarily, but not strictly, in a sequence, since the knowledge produced in one step can be later amended when in a successive step additional knowledge is collected, refining the overall picture. In this paper we focus on the first step, s1,1, corresponding to the AsIs stage in the CIM Layer. The first step is particularly critical since it is where the current scenario is carefully analysed and (hopefully) understood. In such a step, we aim at building conceptual models of the business with a structural (static) perspective. We will also tackle actions and processes but only from a structural standpoint, i.e., considering all the elements of a BP and their relationships with other relevant entities (actors, documents, etc.), avoiding to model the business logic (i.e., the process flow) that will be later detailed in the PIM layer (while in the PSM layer all the implementation details will be provided.) The EasInnova methodology is primarily addressed to business people, therefore we propose a set of knowledge artefacts sufficiently intuitive to be easily managed by people without a technical background. At the end, we will have a final step aimed at distilling the collected knowledge, essentially represented in an intuitive, informal way, into a business ontology. This last step, of a more technical nature, is an easily task for an ontology expert who will simply encode the knowledge into a formal representation, without altering the business models and the underlying vision. The achievement of a BP ontology presents a number of advantages, such as the possibility of revising the informal models from a more formal standpoint. Then, once the knowledge is represented in a formal way (e.g., by using OWL), with a support of an ontology platform (we used Protégé) it is possible to carry out a number of automatic services, e.g., checking its formal consistency or the business (terminological) coherence of the various models (essentially, the coherent adoption and representation of the different business terms). 3. Related works Business Process Innovation (BPI) includes, in its preliminarily phase, Business Analysis (BA) that is addressed in the first step of the EasInnova methodology: EI(AsIs, CIM). BA is a discipline with a long tradition rooted in the business culture. With the advent of enterprise information systems, BA become an important part of Requirement Engineering and a must for a successful project of BPI. It has been indicated as Business Process Analysis (BPA) [5]: a territory of research and practice that traditionally belongs to business people, but that progressively attracted the attention of technical IT people. In early times, IT people were involved only at the end of this analysis process, when business requirement specifications were released. Business people mainly addressed BPA following informal guidelines and producing informal process models [6]. Such approaches demonstrated a number of shortcomings in the development of enterprise information systems. One of the most severe is the Business/IT Alignment problem [7], i.e., the misalignment between business needs and services offered by an information system. Several efforts have been deployed to find a solution, but with a limited success [8]. One of the key causes is the separation between the BA performed by business experts and the successive analysis and specification carried out by IT experts. To solve this issue, the idea was to establish an early cooperation between business and IT experts, adopting rigorous and precise specifications in BP modeling. The expected advantage was to reduce the ambiguity of informal specifications, moving earlier the adoption of formal methods and the use of computer-supported services. Along this line, the adoption of a semantic approach started to emerge, with the proposal of knowledge-based solutions, business ontologies [9] and ontology-based enterprise models [10]. Ontology-based solutions for BPA, focused on business processes and their dynamic aspects, were proposed, like COBRA, a Core Ontology for Business pRocess Analysis [11], based on a Time Ontology. Another research line, with a wider scope, is represented by the adoption of ontologies and semantic web services for BP management, such as Semantic Business Process Management (SBPM) [12]. A different research line, rooted in the business culture, starts from a business standard, the Universal Business Language (UBL) [13] proposed by the international Organization for the Advancement of Structured Information Standards (OASIS). In essence, UBL is an open library of business components, such as Address, Price, Quantity, and business templates of the most common documents, such as Invoice, Order, Receipt, plus a number of standard process models (e.g., procurement). Roy et Al. [14] propose to associate a business ontology to UBL, modeling its components and templates, and the UBL process flow, with a logical formalism (essentially OWL). Another interesting proposal is represented by BPMO [15], a BP Modeling Ontology that besides UBL considers also other business representation standards, including ebXML, conceived to allow the exchange of information among cooperating enterprises. The literature is very rich and there are other important proposals that we omit for lack of space. But all the existing proposals had a limited practical impact, failing in the objective of convincing business people to adopt more rigorous and formal business modeling methods. We believe that there are several causes. The first is the clash of the business and the ontology cultures, with the pragmatism of the former and the formal approach of the latter. Then, the idea of building large, encompassing, enterprise ontologies turned out to be too complex, difficult to be built and to evolve over time. We believe that starting with a limited, local solution, e.g., a departmental or application ontology, would have more chances of success. Also, the idea of pushing extensive competencies of ontology principles and theories in the business world appears not practical. Then, there is a need for a methodology that supports business people in a progressive approach from informal to formal knowledge modeling. For these reasons, the paper presents a method that starts building simple intuitive models, in the form of textual specifications, progressively enriching such models producing structured, semantically tagged artefacts and, eventually, a first business ontology. 4. The CIM-AsIs step The first CIM-AsIs step, aimed at BPA, mainly consists in carrying out a comprehensive business analysis of the current state of play. Such an analysis goes beyond the given BP and considers also other business elements, such as the actors who operate or superintend on the process, the documents that are exchanged among the actors, the data and information that are managed during the process. As anticipated, this preliminary analysis avoids considering the actual business flow, typically represented by a BP diagram. The focus is on the structural elements of the BP, e.g., activities, operation, and the links with the other cited elements (document, actors, etc.) In this way, we will collect a significant amount of enterprise knowledge. Such a knowledge will be used in the successive steps, starting from the CIM-BTran that is aimed at identifying the critical issues to be addressed in achieving BP innovation, and the transformations necessary to reach the new CIM-ToBe scenario. Both are the successive steps, not addressed in this paper, for which the knowledge collected in this step is a necessary base. In this step the models that represent the enterprise knowledge can assume various forms, with different levels of details and formality. In particular, we have: (i) plain text, a narrative form of knowledge representation; (ii) structured text, e.g., itemised lists (bullet points, numbered lists, etc.) that collect and organise short statements; (iii) tabular structures, typically providing a matrix visualization of knowledge items; (iv) diagrams, where the knowledge is graphically represented, according to a given standard; (v) a formal representation of the business domain by means of a reference ontology. 4.1. The methodology presented with a running example This step is aimed at collecting the knowledge and building static (structural) models of the current business scenario, creating the following knowledge artefacts that contribute to the construction of the first CIM-AsIs knowledge asset. a) BP Signature. This is the first tabular artefact aimed at providing a synthetic description of the business process that we intend to innovate, gathering a few key information items about it. b) BP Statement. A preliminary plain text description of the business scenario and the business process to be innovated, described in general terms (i.e., at an intensional level). c) BP Case. A plain text description of an exemplar execution of the BP (i.e., at an extensional level). In essence, it represents one instance of the BP Statement. d) OPAALE Lexicon. This is a structured terminology that provides a first semantic tagging of the key terms used in the two previous structures. e) UML Class Diagram. The construction of the UML Class Diagram (CD) starts form the knowledge so far collected, modeling it in a graphical form. Such a graphical representation has a growing popularity, it is particularly useful to exchange the knowledge among people. f) CIM-AsIs ontology. This is a formal representation of the analysed business process. It is the final knowledge artefact of this step. Below we illustrate the details of the listed knowledge artefacts. To this end we adopt a running example concerning a pizza shop. The example will help to show the progression in complexity and formality in the acquisition of business knowledge to arrive, eventually, to the definition of the BP ontology. BP Signature. The Table 1 organizes the key knowledge aimed at providing the essential information about the BP. Table 1 BP Signature scheme Knowledge items Description Name Trigger Key Actors Key Objects Input Objectives < objectives that the BP intends to achieve> Output Then we apply the above scheme to provide the first description of the pizza shop BP. Table 2 PizzaShop BP Signature Knowledge items Description Name PizzaDelivery Trigger OrderArrived Key Actors Customer, Cook, DeliveryPerson Key Objects Order, Dough, Pizza, DeliveryVehicle Input Order Objectives Cook and deliver pizzas to customers Output Pizzas delivered BP Statement. The text of the BP Statement is the synthesis of an interview to a (fictitious) pizza shop owner, whose business has name PizzaPazza. My business, PizzaPazza, is a home delivery pizza shop. The customer fills in the order and then submits it to the shop, with the payment, by using our Web site. Making good pizzas requires good quality dough, produced in-house, and a careful baking of the pizza. To make clients happy, we need to quickly fulfil the order and the delivery person needs to know streets and how to speedily reach the customer’s address. BP Case. This text reports a specific execution of the BP, i.e., it represents an instance of the PizzaShop BP. John connects to the PizzaPazza Web site and places his order of two Napoli pizzas, providing also the payment. On the arrival of John’s order at PizzaPazza, July, the cook, puts the order on the worklist. When the John’s turn arrives, July prepares the ordered pizzas, cooks them, and alerts the delivery boy Ed to come and pick up the pizzas. Then, Ed takes the pizzas and starts his delivery trip, eventually achieving the delivery to John’s home. 4.2. Building a structured BP lexicon Here, we start introducing the first semantic elements, extracting the terminology from the first three knowledge artefacts and organising them according to six semantic categories. To this end, we propose a semantically structured lexicon, referred to as OPAALE. The name comes from the six semantic categories that form its structure that is an evolution of a pre-existing proposal: OPAL [16]. (i) Object: any passive entity with a lifecycle that follows to the CRUDA paradigm, i.e., the traditional Create, Read, Update, Delete (Martin, 1983 and Torim, 2012), to which we add Archive that is particularly relevant in business processes; (ii) Process: a partially ordered set of tasks aimed to enact CRUDA operations on one or more business objects; (iii) Actor: any active entity involved in one or more processes; (iv) Attribute: a property associated to one or more of the listed concepts; (v) Link: a relationship between two of the listed concepts; (vi) Event: a special object that causes the start of a BP instance, or that represents a milestone in its execution. In Table 3 we report the OPAALE Lexicon built with the knowledge extracted from the BP descriptions (Signature, Statement and Case). Please note that here we do not mean to be complete, since the reported structures have mainly an illustrative purpose. Furthermore, we use the term „lexicon‟ and not glossary since this structure collects the sole terminology without the description of terms. Table 3 OPAALE Lexicon of the PizzaPazza BP Categories Business terms Object Pizza, Dough, Topping, Address, … Cooking, MakingDough, PlacingOrder, AcceptingOrder, Process DeliveringPizza, Carrying, … Actor PizzaShop, Customer, DeliveryPerson, … Attribute Price, Quantity, PizzaKind, … Customer-Order, Order-Pizza, DeliveryPerson-Pizza, Customer- Link Address, … Event Order, DeliveredPizza, ... To better clarify the elements of the Table 3, we provide a formal account of its content. Assuming that we have the full application lexicon F that gathers all the terms used to describe a Pizza business, then we introduce six predicates and a set theoretic account of the table content. Firstly, we introduce the following predicates, each of which corresponds to a row in the above table: object(x), evaluate true if x is an object; process(x), evaluate true if x is an activity, an operation, a task, a process; actor(x), evaluate true if x is an actor; attribute(x), evaluate true if x is an attribute; linked(x,y), evaluate true if the concepts represented by x and y exhibit a form of relatedness in the application domain. event(x), evaluate true if x is an event. Then we define the following subsets of F: O = { o  F : object(o) } P = { p  F : process(p) } A = { a  F : actor(a) } AT = { t  F : attribute(t) } E = { e  F : event(e) } And the following relation: L = { (x,y)  F  F : linked(x,y) actor(x) actor(y)) object(x) object(y)) actor(x)object(y)) actor(x) process(y))  (event(x) process(y))) } Please note that the above formalization does not intend to be complete (for sake of simplicity we left out the attributes that can be associated to all the other concepts), but we believe that it can help in the next steps, when building the Class Diagram and then the ontology. In this respect, in the link category we listed only the domain dependent terms, giving for granted the general conceptual modeling constructs, such as partOf, ISA, etc. 4.3. Building the Pizza Shop Class Diagram Starting from the above knowledge artefacts, and in particular from the OPAALE Lexicon, we proceed in drawing the UML-Class Diagram (CD) of the Pizza Shop BP. The CD is built according to the following rules:  Class Boxes are labelled with one of the terms in the classes of Object or Actor, or Event  Attribute terms are listed within the box of the corresponding concept.  Pairs of terms in the Link section are represented by arrows connecting two boxes. Such arrows can be representative of: a. ISA, if linking an object or an actor with its more general concept. b. PartOf, if linking an object or an actor that is a component of a more complex assembly to which it is part of. c. Action, if linking an actor with another actor or an object. Or an event to an actor. The action name is one of those listed in the Process section (we recall that the term Process in OPAALE is more general than „business process‟, including various behavioural notions, such as task, operation, action, activity, function). d. An Action that goes from an Event (a special object) to the actor that is interested by such an event. It is important to emphasise that all the names used in the UML-CD need to be already identified and reported in the OPAALE Lexicon. The concept (class) names are preceded by a tag indicating the corresponding OPAALE category. For sake of space, in this paper we report a fragment of the Class Diagram where the boxes include only the concept names (i.e., class names, in UML-CD jargon.) Figure 1: Excerpt of PizzaShop Class Diagram Please note that in this CIM-AsIs step we need (possibly) to be precise, but we don‟t need to be neither formal nor complete. In fact, with EasInnova, we do not proceed linearly, but rather in a spiral way. For instance, when drawing a CD it may be the case that new terms, not yet identified, will emerge, then we go back to the OPAALE Lexicon adding the new terms to it, in order to keep the different models aligned. The next knowledge artefact, the application ontology, represents the final outcome of the CIM- AsIs step of the EasInnova methodology. 4.4. Pizza shop BPA ontology Adding an ontology to the knowledge artefacts already available presents various advantages. Firstly, the analyst need to revisit the knowledge collected so far to verify its consistency and (self) completeness. Then, the building of a formal representation, by means of a dedicated platform, such as Protégé, gives the possibility to apply a reasoner to prove the absence of (formal) inconsistencies. In building the PizzaShop ontology we start from the terminology reported in the OPAALE lexicon and adopted in the Class Diagram. Please consider that the whole method has been conceived to allow business experts (without specific technical competencies) to directly manage all the previous knowledge artefacts. Only this last artefact requires competencies on ontology principles, even if the following rules provide effective guidelines in the ontology building endeavour.  Object, Actor and Event terms are modelled as OWL classes  Attribute terms are modelled as datatype Properties  Processes are modelled as Object Properties, having Actor as Domain and Object or Actor as Range.  Links are modelled as Object Properties, where Domain and Range are defined by the pair of terms reported in the table. The property label is assigned according to the label reported in the Class Diagram, in particular: o If the domain (i.e., the origin of the arrow) is an Actor term, we assume that an actor performs an action on another Object or Actor. Therefore, the label will be selected in the Process class. o If the domain is an Object, we assume that the range is another object. Then the label will be, for instance, partOf. Or another relation among objects (e.g., nextTo). o If the domain is in Event, then we adopt the predefined Object property „triggering’ and the range is a Process. In the figure below we report a fragment of the PizzaShop ontology that has been built by using the Protégé platform. For sake of space, it is a small fragment, but we believe that it can provide at least an intuition of the knowledge artefact that concludes the BPA activities in the CIM-AsIs step. … rdf:type owl:Class ; rdfs:subClassOf ; rdfs:label "Customer"^^xsd:string. rdf:type owl:Class ; rdfs:subClassOf ; rdfs:label "Order"^^xsd:string . rdf:type owl:Class ; rdfs:subClassOf ; rdfs:label "Pizza"^^xsd:string. rdf:type owl:ObjectProperty ; rdfs:subPropertyOf ; rdfs:domain ; rdfs:range ; rdfs:label "PlacingOrder"^^xsd:string . rdf:type owl:ObjectProperty ; rdfs:subPropertyOf ; rdfs:domain ; rdfs:range ; rdfs:label "Including”^^xsd:string . … 5. Conclusions and future work In this paper we presented a method for BP analysis. This method is the first step, named CIM- AsIs, of the EasInnova methodology aimed at guiding business people in carrying out a business innovation project. The key objective of the methodology is to reduce to a minimum the role of technical experts providing to business people a central role in the whole innovation project, including the eventual development of a new software application. The proposed method is based on the idea that business analysis essentially consists in the acquisition and modeling of knowledge about the application domain. Therefore, the method indicates a sequence of knowledge artefacts to be progressively built, from simple to complex ones, from informal to formal ones. Such a progression has been conceived so that five out of six knowledge artefacts can be easily built by business experts without the need of specific technical competences. Only the final artefact, the BP ontology, requires technical competencies. We believe that giving a central role to business experts has a number of advantages, first of all it contributes to solve the long- standing Business / IT alignment problem. Then, the proposed knowledge management approach appears easy to be adopted also by SMEs that, traditionally, lack of competencies and resources for such a kind of projects. Our work will continue along two main lines. The first is to proceed with the next EasInnova steps. Firstly, CIM-BTran that, starting from the knowledge collected in the previous step, has the objective to identify the actual transformations needed to innovate the given business process. Then, the final step of the first EasInnova layer, CIM-ToBe aimed at providing a first sketch of the new scenario that will be built. The second line of activities is the development of the EasInnova platform, a knowledge management environment that will support the business experts in all the steps needed to innovate a business process. To speed up the development we adopted a Low Code platform (BonitaSoft). On the practical ground, the CIM steps are currently being experimented in a real world business context. It concerns an office of the central Italian Public Administration (Ragioneria Generale dello Stato). The first feedbacks that we are collecting encourage us to continue along the lines illustrated in this paper 6. References [1] Markic, M., 2006. Process innovation: a precondition for business excellence. International Journal of Innovation and Learning, Vol.3, Issue 5 (2006). https://doi.org/10.1504/IJIL.2006.010483. [2] Missikoff M., A Simple Methodology for Model-Driven Business Innovation and Low Code Implementation. ArXiv, Computer Science (2020). https://arxiv.org/abs/2010.11611. [3] Missikoff, M., Canducci, M., Maiden, N. (Eds). “Enterprise Innovation: from Creativity to Engineering”, Wiley-ISTE, 322 pages, August 2015. ISBN: 978-1-84821-851-2. DOI: 10.1002/9781119145622 (2015). [4] Kleppe A., Warmer J., Bast W.. MDA Explained - The Model Driven Architecture: Practice and Promise. Addison - Wesley (2003). [5] Carlos Pedrinaci, John Domingue, and Ana Karla Alves de Medeiros. A Core Ontology for Business Process Analysis. Proc. of ESWC: European Semantic Web Conference, LNCS 5021, Sproinger-Verlag, (2008). [6] Ruth Sara Aguilar-Savén. Business process modelling: Revie wand frame work. Int. J. Production Economics 90, Elsevier, (2004). [7] Wim Van Grembergen, Steven De Haes. a research Journey into Enterprise Governance of IT, Business/IT alignment and Value Creation. International Journal on IT/Business Alignment and Governance, 1(1), (2010). [8] Lerina Aversano, Carmine Grasso, Maria Tortorella. A literature review of Business/IT Alignment Strategies. In CENTERIS 2012 - Conference on ENTERprise Information Systems, Elsevier (2012). [9] Mark von Rosing and Wim Laurier. An Introduction to the Business Ontology. International Journal of Conceptual Structures and Smart Applications (IJCSSA), 3(1) (2015). [10] Andersson B. et al. (2006) Towards a Reference Ontology for Business Models. In: Embley D.W., Olivé A., Ram S. (eds) Conceptual Modeling - ER 2006. Lecture Notes in Computer Science, vol 4215. Springer, Berlin, Heidelberg. https://doi.org/10.1007/11901181_36. (2006). [11] Pedrinaci C., Domingue J., Alves de Medeiros A.K. (2008) A Core Ontology for Business Process Analysis. In: Bechhofer S., Hauswirth M., Hoffmann J., Koubarakis M. (eds) The Semantic Web: Research and Applications. ESWC 2008. LNCS 5021. Springer, Berlin, Heidelberg. [12] Hepp, M., Leymann, F., Domingue, J., Wahler, A., Fensel, D.: Semantic business process management: A vision towards using semantic web services for business process management. In: Lau, F.C.M., Lei, H., Meng, X., Wang, M. (eds.) ICEBE, pp. 535–540. IEEE Computer Society, Los Alamitos (2005). [13] W3C Recommendation. Universal Business Language v2.0. available at http://docs.oasis- open.org/ubl/cs-UBL-2.0/UBL-2.0.htm (2006). [14] Roy, S., Sawant, K. & Ghose, A. K. Ontology modeling of UBL process diagrams using OWL. 2010 International Conference on Computer Information Systems and Industrial Management Applications (CISIM) (pp. 535-540). Piscataway, New Jersey, USA: IEEE (2010). [15] Mark von Rosing, Wim Paul Remi Laurier, Simon Polovina. The BPM Ontology. In book: The Complete Business Process Handbook, Volume 1Publisher: Elsevier - Morgan Kaufmann (2015). [16] D'Antonio F., Missikoff M., Taglino F. Formalizing the OPAL eBusiness ontology design patterns with OWL. Proceedings of the 3th International Conference on Interoperability for Enterprise Software and Applications, IESA 2007.