Keywords

1 Introduction

In the last decade the economic system underwent a significant transformation, due to several factors: from the globalization to the digital revolution, to the fight against the climate change with the green transition. In addition, the advent of the Covid-19 pandemic and the post-pandemic phase, that (hopefully) is ready to start, are further increasing the speed at which enterprises need to change, redesign their processes and organizations.

Within enterprise innovation, Business Process (BP) [1] innovation plays a central role, in fact a BP 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 business process, we need to consider other related business elements, such as documents, enterprise structure and organization, 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 the above reasons, BP innovation is one of the most strategic field of a dynamic enterprise [10]. It consists in the transformation of an existing BP from its current configuration (AsIs) to a future, improved configuration (ToBe). Business Process Analysis (BPA) [2] represents the first phase of any digital transformation: it requires a deep understanding of the target business processes and the building a set of models.

Business Process Analysis is a territory of research and practice that traditionally belongs to business experts, who are supported by methodologies that provide, mainly in an informal mode, schemes and guidelines for their activities. Such methodologies lack of a formal grounding and the absence of a formal approach concerns also the documents to be released at the end of the analysis process [3]. Due to the informal nature of the produced documents, often containing imprecise statements or missing information, traditional methodologies demonstrated a number of shortcomings that are often propagated in the successive development of enterprise information systems. One consequence is the well-known Business/IT Alignment problem [4], i.e., the misalignment between business needs and the services offered by the information system. Several efforts have been deployed to find a solution, but yet with a limited success [5].

To solve the issue, one idea was to establish an early cooperation between business and IT experts and the adoption of a rigorous approach in BPA. Moving earlier the adoption of formal methods would improve the quality and the reliability of the released business models. Along this line, the adoption of a semantic approach started to emerge, proposing knowledge-based solutions centered on business ontologies [6], yielding to ontology-based enterprise models [7]. However, such solutions appeared too complex and were not well received by the business community, and today there is not yet a winning solution for business experts to build and manage formal specifications of a business scenario.

This paper proposes a knowledge-driven approach to business process analysis consisting in a progressive construction of knowledge artefacts, in a sequence that starts from simple, narrative models, and then proceeds building semantically richer models, eventually achieving an ontology of the business scenario. All the models, except the final ontology, can be built without specific knowledge engineering competences. To improve its effectiveness and further ease the BPA process, the proposed methodology adopts an Agile approach [8], therefore we named this methodology ABPA (Agile Business Process Analysis).

One of the main characteristics of ABPA is the paradigm shift that moves the focus of the business process analysis from the ‘how’ to the ‘what’. In essence, the traditional methods are focussed on how to carry out the analysis, providing a number of best practices, rules, recipes to be followed (the ‘how’). Conversely, we consider business analysis as a ‘knowledge management affair’, therefore we put at the center of the stage the knowledge artefacts that are produced during the analysis (the ‘what’), leaving a great freedom on how to proceed in building them.

In essence, the ABPA methodology is based on three main pillars: (i) the adoption of an Agile philosophy [9], characterised by an iterative, incremental approach and frequent delivery, in the construction the of knowledge artefacts; (ii) the progressive introduction of a formal approach in the creation of an Agile Business Process Ontology (ABPO); (iii) the positioning of business experts at the center of the whole business analysis process, giving them full control on the business models that are built and relegating technical expert tasks to the final coding of the ontology.

Now we introduce three research questions that have guided our work, the answers are reported in the last section.

  • RQ1 - Research question 1: Is it convenient to adopt an Agile approach for the analysis of business processes?

  • RQ2 - Research question 2: Is it handy for business experts to adopt a systematic knowledge management method in the construction of business process models?

  • RQ3 - Research question 3: What are the advantages of involving business experts in a systematic, formal business process analysis?

The rest of the paper is organized as follows. In the next section we provide a short review of the literature in the area of agile methodologies and knowledge management for business process analysis. Section 3 describes the proposed methodology, by means of a running example. In Sect. 4 some conclusions are reported.

2 Related Work

As anticipated, the paper is rooted in two key scientific areas, Agile methodology and knowledge-based business process analysis. At the intersection of these two areas we have agile business analysis, with a further focus on business processes.

A literary review highlights a lively scientific and practical activities in the area of Business Process Management (BPM), however, little results are focused on knowledge-based BPA that is the focus of this paper. BPA can be seen as a supporting activity for BPM, considering that the former is more focussed and the latter has a wider scope. In particular BPM includes the operational aspects, the monitoring, improvement and redesign of business processes. All these activities require a solid knowledge about the business context where the BP takes place. Here we briefly review some of the key principles of the Agile philosophy, then its adoption in the BPA and, finally, some of the proposals for knowledge-based BPA, yielding to an BPA ontology.

2.1 Agile Methodologies for Business Analysis

The Agile philosophy [11] continues to attract the attention of scientists and practitioners, for the advantages it presents when developing software systems in a fast and ever changing world. It started in the software development area, then its popularity expanded beyond the software development. One promising area is represented by business analysis. However, the existing proposals tend to address the topic in an informal way, mainly providing good practices, advices and guidelines [12]. There are some contributions towards a more systematic approach, such as the Agile Modeling Method Engineering (AMME) proposal [13]. This proposal, that has a wider scope than ABPA being targeted to enterprise modeling, provides some interesting indications but its four stages organization remains at a descriptive level, failing to provide precise directions for business experts.

Another interesting proposal is the agile methodology referred to as Integrated BPM (IBPM) [14]. Within its wide scope, IBPM proposes a very rich framework based on the idea of combining process-oriented and service-oriented approaches. The framework proposes five project phases: Planning, Analysis, Business Design, Implementation Design and Implementation, with best practices and modeling guidelines. The key result is represented by BPMN (Business Process Modeling and Notation) process diagrams. The key difference between the ABPA and IBPM is that the later focuses on the ‘traditional’ Agile principles concerning the management of the projects, i.e., the ‘how’, while ABPA has the primary focus on the deliverables, i.e., on ‘what’ the project should produce, in terms of business models.

2.2 Knowledge-Based Business Process Analysis

The quest for a systematic method for BPA produced a relevant literature where, in particular, several ontology-based solutions for BPA have been proposed. Among them, we may recall COBRA, a Core Ontology for Business pRocess Analysis [15], that is 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) [16]. All such proposals appear to be more inclined towards the formal aspects than the ease of use by business experts.

A different research line, rooted in the business culture, starts from a business standard, the Universal Business Language (UBL) [17]. In essence, UBL is an open library of business data 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. An interesting proposal [18] is based on the association of a business ontology to UBL. It proposes a formal modeling the UBL components and templates, including the UBL process flow, with an ontological formalism (essentially OWL: Web Ontology Language). Probably due to an excessive formalization, the proposal was not accepted by the business community.

Another interesting proposal is represented by BPMO [19], a Business Process Modeling Ontology that besides UBL considers also other business modeling standards, including ebXMLFootnote 1. BPMO has been mainly conceived to allow the exchange of information among cooperating enterprises rather than to support BPA.

It is widely recognised that the existing proposals had a limited practical impact, failing in the objective of convincing business experts 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 achieved and to be maintained over time. We believe that starting with local solutions, e.g., a departmental or an 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 ‘soft’ methodology that supports business experts with a progressive approach, from informal to formal, to knowledge modeling. For these reasons, the ABPA method starts by building simple intuitive models, in the form of textual descriptions, that are progressively enriched producing structured, semantically tagged artefacts and, eventually, a business ontology. Only the last step, prepared and supported by the previous ones, requires ontology engineering competences.

3 An Agile Method for Business Process Analysis

BPA requires a thorough understanding of the business domain, achieved by a comprehensive analysis and modeling of the current state of play. As anticipated, 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, documents that are exchanged among the actors, data and information that are managed during the process. ABPA proposes seven models, with a preliminary (informal) analysis of the static facets of the business scenario (i.e., without considering the actual business flow), and then a progressive formalization. ABPA is a preparatory work for the full-fledged Business Process Reengineering (BPR) that includes the diagrammatic modeling of the business flow, yielding detailed BP diagrams. In essence, ABPA focuses on the structural elements of the BP, including activities, operation, and the links with the other cited elements (document, actors, etc.), avoiding the formal modeling of temporal sequencing.

In ABPA, 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) tables, typically providing a systematic 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.

3.1 A Running Example

The methodology proposes the acquisition, modeling and management of structural knowledge concerning the current business process scenario, building the following knowledge artefacts.

  1. a)

    BP Signature. The first knowledge artefact, in the form of a table, aimed at providing a synthetic description of the business process, gathering key information about it.

  2. b)

    BP Statement. A preliminary plain text description of the business scenario and the business process, described in general terms (i.e., at an intensional level).

  3. c)

    BP User Story. A plain text description of an exemplar execution of the BP (i.e., at an extensional level). In essence, it represents an instance of the BP Statement.

  4. d)

    PB Glossary. A collection of terms, with their descriptions, that characterise the BP domain.

  5. e)

    OPAAL Lexicon. This is a structured terminology that provides a first semantic tagging of the key terms used in the previous structures.

  6. f)

    UML Class Diagram. The construction of the UML Class Diagram (CD) starts form the knowledge collected so far, modeling it in a graphical form. Such a graphical representation is particularly useful to exchange the knowledge among people.

  7. g)

    BPA Ontology. This is a formal representation of the analysed business process. It is the final knowledge artefact of the methodology.

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 of the business knowledge artefacts to arrive, eventually, to the definition of the BPA (Business Process Analysis) ontology.

BP Signature.

The Table 1 gathers the key knowledge aimed at providing the essential information about the BP.

Table 1. BP signature scheme.
Full size table

Then we provide the first description of the pizza shop BP (Table 2).

Table 2. Pizza shop BP signature.
Full size table

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 (Fig. 1).

Fig. 1.
figure 1

BP statement text box

Full size image

BP User Story.

This text reports a specific execution of the BP, i.e., it represents an instance of the PizzaShop BP (Fig. 2).

Fig. 2.
figure 2

BP user story text box

Full size image

3.2 Building the BP Glossary

This knowledge artefact is built starting from the textual models that have been produced so far. It is created extracting from the BP Signature, the BP Statement and the BP User Story the relevant terminology, i.e., the terms that represents entities, attributes, and activities that are representative of the analysed business context. For each term, a short description is provided. Below an excerpt of the Pizza Shop Glossary (note: the descriptions have been derived from The Free Dictionary) (Table 3).

Table 3. PizzaShop glossary.
Full size table

3.3 Building the BP Semantic Lexicon

Here, we start introducing the first semantic elements, organising the terms of the Glossary according to five semantic categories. Then, we build a lexicon structured following the OPAAL scheme.

  1. (i)

    Object: any passive entity with a lifecycle that follows to the CRUDA paradigm, i.e., the traditional Create, Read, Update, Delete [20], to which we add Archive that is particularly relevant in business processes;

  2. (ii)

    Process: a partially ordered set of tasks aimed to enact CRUDA operations on one or more business objects;

  3. (iii)

    Actor: any active entity involved in one or more processes;

  4. (iv)

    Attribute: a property (simple or complex) associated to one of the former concepts;

  5. (v)

    Link: a relationship between two of the above listed items.

Table 4 reports an excerpt of OPAAL Lexicon. Please note that here we do not mean to be complete, the reported structures have mainly an illustrative purpose.

Table 4. The OPAAL Lexicon of Pizza shop.
Full size table

To better clarify the elements of the Table 4, we provide a formal account of its content, introducing five predicates, each of which corresponds to a row of the table, and a set theoretic notation for the content.

  • 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.

Assuming that we have the full application lexicon L that gathers all the terms used to describe a Pizza business, then we define the four subsets of L:

$$\begin{array}{*{20}l} {O\, = \,\{ o\,\epsilon \,L:object\left( o \right)\} ;} \hfill \\ {P\, = \,\{ p\,\epsilon \,L: \, process\left( p \right)\} ;} \hfill \\ {A\, = \,\{ a\,\epsilon \,L:actor\left( a \right)\} ;} \hfill \\ {AT\, = \,\{ t\,\epsilon \,L:attribute\left( t \right)\} } \hfill \\ \end{array}$$

and the relation L:

$$\begin{aligned} & L\, = \,\{ \left( {x,y} \right)~\epsilon~L\, \times \,L: \, linked\left( {x,y} \right)~{\wedge}~( (actor\left( x \right)~{\wedge}~actor\left( y \right)) \\ & {\vee}~(object\left( x \right)~{\wedge}~object\left( y \right))~{ \vee}~(actor\left( x \right)~{\wedge}~object\left( y \right)))\} \\ \end{aligned}$$

Please note that the above formalization does not intend to be complete, for sake of brevity we left out the attributes that can be associated to all the entities. In the Link category we listed only the domain dependent terms, giving for granted the general conceptual modeling constructs, such as partOf, ISA (the generalization operator), etc.

3.4 Building the Pizza Shop Class Diagram

Starting from the above knowledge artefacts, and in particular from the semantic OPAAL Lexicon, we proceed in drawing the UML-Class Diagram (CD) [21] 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 Object or Actor sections.

    • Attribute terms are listed within the box of the corresponding concept (not reported in the figure).

    • Pairs of terms in the Link section are represented by arrows (with or without head) connecting two boxes. Such arrows can be representative of:

        • ISA, if linking an object, an actor or a process with its more general concept.

        • PartOf, if linking an object, an actor or a process that is a component of a more complex assembly to which it is part of.

        • Action, if linking an actor with another actor or an object. The action name is one of those listed in the Process section (we recall that the term Process in OPAAL is more general than ‘business process’, including various behavioral notions, such as task, operation, action, activity, function) (Fig. 3).

Fig. 3.
figure 3

Excerpt of PizzaShop class diagram

Full size image

Please note that the knowledge artefacts have been described in a sequence, but in building them we proceed back and forth, and in a spiral way. For instance, all the labels used in the UML-CD need to be already identified and reported in the Glossary. In the case that, when drawing a UML-CD, new labels not yet identified should emerge, we go back to the Glossary and the semantic OPAAL Lexicon adding the new labels to them, in order to keep the different models aligned. Then, when we involve the stakeholders of the business process for a validation, their comments and observations may cause the models to be updated and a new version of the knowledge artefacts is achieved.

The next knowledge artefact, the BPA ontology, represents the final outcome of the ABPA methodology.

3.5 PizzaShop BPA Ontology

To build the BPA ontology we revisit the knowledge collected so far encoding it in the Turtle formalisms (a jargon of OWL). A formal representation offers various advantages, from the ease of querying the knowledge artefact (e.g., to discover which actors perform what actions) to the possibility to apply a reasoner (we adopted Protégé) to prove the absence of (formal) inconsistencies.

The Pizza shop BPA ontology is built starting from the Class Diagram. As anticipated, only this last step requires an ontology engineer, who will be supported by the following rules for ontology building.

    • Object and Actor terms are modelled as OWL classes

    • Attribute terms are modelled as datatype Properties (not reported in the example)

    • 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 boxes reported in the CD and the property name is the label of the link connecting the two boxes. Then (assuming that the actions are not in a passive form):

        • If the domain (i.e., the source of the arrow) is an Actor, the link represents an action on another Actor or Object (i.e., the range).

        • If the domain is an Object, than the range is another object and the label will be, for instance, partOf, subClassOf, or another relation among objects (e.g., nextTo).

Fig. 4.
figure 4

An excerpt of the Pizza shop BPA ontology encoded with the Turtle notation

Full size image

Figure 4 reports a fragment of the Pizza shop ABPA ontology, 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 such a knowledge artefact that concludes the ABPA activities.

4 Conclusions and Discussion

In this paper we presented ABPA, an agile methodology for business process analysis based on the acquisition, modeling and management of business knowledge. With respect to previous proposals, this methodology has three main innovations: (i) it is based on the Agile approach; (ii) it is rooted in the knowledge management discipline, modeling BP knowledge with a focus on ‘what’ rather than ‘how’; (iii) its progression of model building, from informal to formal, has been conceived to facilitate business experts in assuming a central role.

In brief, the ABPA methodology proposes a set of knowledge artefacts represented by models to be progressively built, from simple to complex ones, from informal to formal ones. Such a progression has been conceived so that the first six out of seven models can be easily built by business experts without the need of specific technical competences. Only the final artefact, the ABPA ontology, requires ontology engineering competencies. We believe that giving to business experts a central role has a number of advantages, first of all it contributes to solve the long-standing Business/IT alignment problem [5]. Then, the proposed knowledge management approach appears easy to be adopted also by SMEs that, traditionally, lack competencies and resources required to carrying out BP innovation, supported by advanced methodologies [22]. On a more technical ground, the ABPA ontology, and the associated semantic services (e.g., semantic search, automatic reasoning, etc.), are fundamental to achieve a high quality business process analysis.

On the practical ground, the ABPA methodology is currently being experimented in a real world business context, an office of the central Italian Public Administration, Ministry of Economics and Finance, State General Accounting Department (Ragioneria Generale dello Stato). The first feedbacks encourage us to continue along the lines illustrated in this paper.

Below we provide the answers to the research questions reported in the introduction.

  • (RQ1) Is it convenient to adopt the Agile approach for the analysis of business processes?

  • The answer is positive and we believe that a complex endeavor like business process analysis, and the corresponding construction of business models, need incremental achievements with frequent deliveries to involve users and stakeholders in the validation of the produced knowledge artefacts. This is further facilitated by the ABPA philosophy that focuses on the ‘what’ (structural business models) and not on the ‘how’ (behavioral knowledge) in carrying out the analysis activities.

  • (RQ2) Is it handy for business experts to adopt a rigorous knowledge management method in the construction of business process models?

  • Despite the failure of previous attempt to bring formal modeling methods in the business community, ABPA is primarily based on the production of a set of intuitive business models. It starts from simple intuitive models, using natural language specification and tabular organization of the collected knowledge, progressively evolving towards more complex and semantically rich ones. Only the last of the seven models requires specific ontology engineering competences. ABPA proved to be largely manageable by business experts without a specific education in formal knowledge management and, from the first experiment on the field, it appears to be well accepted by business experts.

  • (RQ3) What are the advantages of involving business experts in a systematic, formal business process analysis?

  • In developing an information system, business analysis is a fundamental phase and ABPA offers to business experts the possibility to thoroughly manage it. Furthermore, the business reality is a ‘moving target’ since it constantly evolves, therefore, information systems, starting from their underlying business models, need to be periodically revised, updated, and improved. With ABPA, such operations remain under the control of business experts, with the advantage that, seen the tight connection between formal business models and the enterprise information systems, ABPA guarantees a timely update of the information systems and a substantial reduction of the Business/IT misalignment. On a more technical ground, the availability of a computational knowledge base (in particular, and ontology encoded in OWL) provides several advantages, such as the possibility of exploring, navigating and querying the business process models; another important advantage is the possibility of running a semantic checker to prove its consistency. Last but not least, the adoption of a Low-Code platform [23], an emerging technology capable of transforming business models into running software, will provide a progressive control of business experts also on the development of the software implementing an enterprise information system.

Our work will continue along two main lines. The first intends to continue the development of the ABPA methodology to include the temporal sequencing of activities and tasks in the form of BP diagrams. In particular, we are experimenting the adoption of the international standard BPMN (BP Modeling and Notation) [24].

The second line is represented by the development of a digital platform aimed at supporting business experts in building the ABPA knowledge artefacts. The platform will be primarily based on Natural Language Processing services, aimed at analyzing the first three artefacts (BP Signature, Statement, and User Story) to automatically extract the terminology, proposing a first semantic tagging in accordance to OPAAL. A second set of services will be devoted to the (semi) automatic construction of the UML-CD diagram starting from the OPAAL Lexicon. Another set of services will be devoted to an automatic support of ontology building guided by the UML-CD, eventually extending the participation of ontology experts in the ontology management tasks. The ultimate objective is the interoperability of the ABPA platform with a Low-Code platform, for the seamless generation of enterprise information systems software. A preliminary study, adopting the BonitaSoft Low-Code platform [25], is on the way.

The absence of a supporting platform currently represents one of the main obstacle for the adoption ABPA, since today the consistency of the different business models needs to be achieved manually. Another obstacle may be represented by the resistance of enterprises to embrace the new Low-Code technology, pushing business experts to assume a higher responsibility in the development of an enterprise information system.

The work presented in this paper is the continuation of the work carried out in the context of the European Project BIVEE (Business Innovation in Virtual Enterprise Environment) where a first proposal of knowledge-based enterprise analysis has been proposed [26].