Business Process Analysis (BPA) is a strategic activity, necessary for enterprises to model their business operations. It is a central activity in information system development, but also for business process design and reengineering. Despite several decades of research, the efectiveness of available methods is still questionable. The majority of methodologies adopted by enterprises are rather qualitative and lack a formal basis, often yielding inadequate specifications. On the other hand, there are methodologies with a solid theoretical background, but they appear too cumbersome for the majority of enterprises. This paper proposes a knowledge framework, referred to as BPA Canvas, conceived to be easily mastered by business people and, at the same time, based on a sound formal theory. The methodology starts with the construction of natural language knowledge artifacts and, then, progressively guides the user toward more rigorous structures. The formal approach of the methodology allows us to prove the correctness of the resulting knowledge base while maintaining the centrality of business people in the whole knowledge construction process.
© 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 tions that hold diferent kinds of knowledge artifacts, i.e., International (CC BY 4.0).
Business Process Analysis (BPA) is a strategic activity
for an enterprise, used for instance for organizational
changes, Business Process (BP) reengineering, and
information system development. BPA [1] is positioned in
the preliminary phase of a software project. Software
projects are among the most dificult engineering
undertakings. Despite the significant advances in Software
software projects still face a number of shortcomings.
One of the major causes of software project failure is
represented by the problem of business/IT misalignment [2],
i.e., the services ofered by the information system do not
fully correspond to the business needs. Such a problem
is mainly caused by dificulties in the communications
between business people and IT specialists, yielding poor
requirement specifications [ 3]. In this paper, we propose
an evolution of the knowledge-driven BPA methodology,
referred to as BPA Canvas, presented in its preliminary
version in [
0000-0001-8364-4407 (F. Taglino) 2. The Business Process Analysis
In this section, we introduce the main ideas of the BPA Canvas and the related methodology. It includes a set of knowledge artifacts and a procedure aimed at guiding business experts in collecting and organizing the knowledge of a business process.
With respect to the business process modeling methods available in the literature, the BPA Canvas has not the objective of drawing process diagrams, an activity that is postponed to the BP design phase. BPA Canvas is aimed at the careful collection of the knowledge necessary to build a first static model of a business process. The idea is that a rigorous and detailed knowledge base about the BP will substantially support the subsequent design task and improve the quality of the process flow diagrams. Improving then the quality of the produced information system.
The BPA Canvas is organized into eight knowledge secmodels of the given business process. The models can assume various forms, with diferent levels of details and formality. In particular, we have: (i) plain text, a narrative form of knowledge representation; (ii) structured text, e.g., itemized lists (bullet points) that collect and organize short statements; (iii) tables, typically providing a systematic visualization of knowledge items; (iv) diagrams, where the knowledge is graphically represented, according to a given standard; (v) formal representation of the business domain by means of a BP Ontology. Figure 1 shows the layout of the eight sections of the BPA Canvas that are listed below.
• BP Signature. The first knowledge artifact, in the form of a list, aimed at providing a synthetic profile of the business process. • BP Statement. This is a preliminary plain text description of the business process and its business scenario, described in general terms (i.e., at an intentional level). • User Stories. One or more plain text descriptions of exemplar executions of the BP (i.e., at an extensional level). In essence, it represents one or more instances of the BP Statement. • APO Tasks. This is a set of triples representing a ifrst operational account of the business process, abstracting the actual sequencing of the tasks. • BP Glossary. A collection of terms, with their descriptions, that characterize the BP domain. • OPAAL Kinds & Links. This structure is composed of two parts. The first part, , provides a semantic tagging of the terms (concept) names used in the construction of the knowledge artifacts, according to the following categories: Object, Process, Actor, and Attribute. The second part, , represents semantic relations among concept names, i.e., ISA for subsumption relation, PartOf for composition relation, and HasA to relate a noun with an attribute. • UML Class Diagram. A set of diagrams providing a static view of the BP. The Class Diagrams are built by using tasks and links in APO Tasks and sections, respectively. • BP Ontology. An encompassing representation of the knowledge collected in the previous sections, encoded in formal terms by using an ontology language (e.g., OWL).
Then, the methodology indicates how to proceed in building the above knowledge structures.
The example illustrates the construction of the BPKB for a home delivery pizza shop, called , achieved following the BPA Canvas methodology. We show how the knowledge artifacts are first built in a step-wise fashion, omitting, for sake of space, the successive refinement cycles.
BP Signature. Table 1 represents the first knowledge artifact of the pizza shop BP. This is a structure of eight labeled elements with a meaning explained by the labels.
BP Name Trigger Key Actors Key Objects Input Objective
Output BP Statement. The BP Statement is the synthesis of an interview with a (fictitious) pizza shop owner, who describes how a customer order is handled by the shop.
My business, PizzaPazza, is a home-delivery pizza shop. The customer fills in the order, by using our Web site, and then submits it to the shop, together with the payment. Making good pizzas requires good quality dough, produced in-house, and careful baking of the pizza. To make clients happy, we need to quickly fulfill the order and the delivery boy needs to know the streets and how to speedily reach the customer’s address.
User Story. Here, the text reports a specific execution of the BP, i.e., it represents an instance of the BP. If necessary, more user stories are reported, to represent various use cases and the corresponding process instances.
Mary connects to the PizzaPazza Web site and places her order of two Napoli pizzas, providing also the payment. Upon the arrival of Mary’s order at PizzaPazza, John, the cook, puts the order on the worklist.
When Mary’s turn arrives, John prepares the ordered pizzas, bakes them, and then alerts the delivery boy Ed to come and pick up the pizzas. Thus, Ed collects the pizzas and starts his delivery trip, eventually achieving the delivery to Mary’s home.
Actor Customer Customer PizzaShop
Cook Cook
Cook DeliveryBoy DeliveryBoy Customer Customer The first three knowledge artifacts, Signature, Statement, Table 4 and User Story, represent an important, but informal, OPAAL Links of the BP starting point easily managed by a business expert. The following BPA Canvas sections are built starting from the textual artifacts, moving toward the semantic analysis of the business scenario. 4. A Formal Account of a Business
Process Knowledge Base 3.1. Analysis of the BP Statement and The formal grounding of the BPA Canvas methodology User stories aims at guaranteeing the quality of the released knowledge base, avoiding missing information, redundancy, The analysis starts from the above free-form texts to ex- and contradictions. In this section we first present the tract the structured knowledge artifacts: the APO Tasks formal structure of the Business Process Knowledge Base, section (see Table 2) that contains actionable triples (ac- with its components. Then we present the consistency tor, process, object), the OPAAL Kinds & Links section rules. that indicates concept categories (Object, Process, Actor, Attribute) and binary relations among them (ISA, PartOf, 4.1. The Business Process Knowledge Base HasA) (see Table 3 and 4, respectively) and, then, we have the Glossary. Given a terminology (i.e., a set of terms), a Business
The two final sections, the UML Class Diagram and Process Knowledge Base (BPKB) is a complex structure the BP Ontology can be derived from the three central organized according to the layout of the BPA Canvas, sections of the BPA Canvas. Again, for sake of space, where the OPAAL section has been decomposed into two they will not be reported here. parts: and , yielding a 9-tuple defined as follows: • is the BP Profile ; • is the BP Statement; • is the set of User stories; • is the set of pairs representing the categoriza
tion of terms, referred to as Kinds; • is the set of structural Links; • is the set of triples representing the APO Tasks
belonging to the BP; • is the Glossary in the form of a set of pairs
(conceptName, description); • is a UML Class Diagram; • is the Ontology of the BP.
The following formalization focuses on the of the BPKB represented by the four central components, i.e., K, L, T, and G, whereas the first three sections consist of unstructured knowledge artifacts expressed in natural language. The last two sections, the UML Class Diagram and the Ontology, are derived from the core and their formalization falls outside the scope of the paper. Below, we report the formalization of the Kinds, Links, and APO Tasks sections, omitting the other ones in this short paper.
Kinds. This component of the is used to define the categories of the diferent terms. Given a terminology , is a set of pairs:
⊆ {(, ) ∣ ∈ , ∈ {, , , }} where , , , represent the categories a term can belong to, and: • stands for Object; • stands for Process (or activity); • stands for Actor ; • stands for Attribute.
(, ) , ( , ) state that the terms Cook and Pizza represent an Actor and an Object, respectively. Similarly, the other components of a BPKB are formally defined.
Structural Links. Given a terminology , is a set of triples: ⊆ {( 1, , 2) ∣ 1, 2 ∈ , ∈ , 1 ≠ 2} where = { ISA, PartOf, HasA} defines the structural relations (links) used in the . A triple ( 1, , 2) is in if 1 and 2 are related according to .
(, , ) (ℎ, , ) , .
APO Tasks. This component of the represents the tasks of the BP as a set of 3-tuple, defined as follows: = {(, , ) ∣ (, ), (, ), (, ) ∈ , (, ) ∈ ,
(, ) ∈ ℎ} where: = {(, ) ∣ (, ), (, ) ∈ and is involved in } ℎ = {(, ) ∣ (, ), (, ) ∈ and achieves } contains all the ordered pairs of terms formed by an actor, , involved in an activity, , and ℎ includes all the pairs whose first element is an activity, , achieving or producing the second element that is an object, o.
(, , ) is a possible task.
ordered pairs defined as follows: is a set of = {(, ) ∣ ∈ , ∈ } where is the set of all possible strings, standing for natural language descriptions.
(Pizza, “Italian open pie made of thin bread dough spread with a spiced mixture of e.g. tomato sauce and cheese”) is a possible element belonging to the glossary.
Although in this paper we do not elaborate on the UML Class Diagram and the details, we anticipate that the UML Class Diagram can be built starting from the APO Tasks and the structural Links. In particular, the built UML Class Diagram will consist of boxes (i.e., classes), named with or names, connected by two types of arcs: functional and structural. The functional arcs (i.e., associations) will be labeled with names connecting the actors with the objects, as reported in the APO Tasks triples. The structural arcs will be created from the triples in the structural Links where the label of the arc is the second element. For the and relations, the arc will connect two boxes labeled with the first and third elements. In the case of the relation, the first element will be a box name and the third element one of its attributes that will be listed within the box (according to the UML Class Diagram syntax).
At this point, the Ontology can be derived from the knowledge so far collected. Note that the construction of the knowledge base does not follow a ’waterfall’ approach, but the Agile philosophy [5]. Therefore, its construction is achieved in a spiral fashion, and, at each cycle, it is possible to check and correct it, while enriching the overall content. Now we introduce consistency rules that will be used to accomplish the formal verification of the BPKB. Below, the rules are presented in an informal fashion, omitting their formal specification. as the completeness of the BPKB (under the Closed World Assumption). In the most popular BPA methodologies, such properties need to be checked manually.
Our work will continue along two main lines. The first consists of the development of a number of services to support the BPKB construction. We will start with NLP services that analyze the first three canvas sections (BP Signature, Statement, and User Stories) to start populating the core of the BPKB. Then, we will provide semantic services aimed at enriching the BPKB by exploring existing terminological resources, such as DBpedia, Wikidata, WordNet, available on the Internet.
R5 – Structural completeness. All the concept names need to participate in at least one triple in .
R1 – Definedness. All concept names in need to have a description in .
R2 – Uniqueness. Each concept name must be present only once in .
R3 – Categorization. All concept names need to have a kind, i.e., to be categorized according to the set of categories. The work presented in this paper is the continuation R4 – Disjointness. Each concept name needs to be of the work carried out in the context of the European associated with only one kind. Project BIVEE (Business Innovation in Virtual Enterprise Environment) where a first proposal of knowledge-based enterprise analysis has been proposed [6].
R6 – Functional completeness. All the actor, object, and process names need to participate in at least one task, References i.e., a triple in . If a concept does not appear in a task, at least one of its subsumees or components or attributes [1] K. Vergidis, A. Tiwari, B. Maieed, Business process (as declared in ) needs to participate. analysis and optimization: Beyond reengineering, R7 – Pragmatics. For all triples in , the concept names IEEE Transactions on Systems, Man and Cybernetics need to belong to their respective categories, i.e., in Part C: Applications and Reviews 38 (2008) 69 – 82. the first place, in the second place, and in the third doi:10.1109/TSMCC.2007.905812. place. [2] W. van Grembergen, S. De Haes, A Research Jour
Each time a BPKB is released, it can be checked for its ney into Enterprise Governance of IT, Business/IT
correctness. To this end, the above rules are triggered Alignment and Value Creation, 2010, pp. 1–13. doi:10.
and, in case of failure, a diagnostic message will indicate 4018/jitbag.2010120401.
what is wrong, suggesting also where to intervene to [3] L. Aversano, C. Grasso, M. Tortorella, A literature
mend the knowledge base. review of business/it alignment strategies,
Procedia Technology 5 (2012) 462–474. doi:https://doi.
org/10.1016/j.protcy.2012.09.051, 4th
Confer5. Conclusion ence of ENTERprise Information Systems – aligning
technology, organizations and people (CENTERIS
In this short paper, we presented the BPA Canvas, a 2012).
methodology for the acquisition, modeling, and man- [
Currently, we are working on a platform that, based on the formal part of the methodology, supports the knowledge acquisition task and checks the consistency as well