Design Evaluation – The utility, quality, and efficacy of a design artifact must be rigorously demonstrated via well-executed evaluation methods (section 8);

0
0
27
6 months ago
Preview
Full text

  

A DEMO-based Service Mining approach

  67061 Pedro Luís Linares Pinto Orientador: Professor Miguel Mira da Silva

  Co-Orientador: Professor Artur Caetano Abstract. Presently services account for the biggest part of the world ’s economy. Nevertheless, organizations do not carry on real time organizational models that portray their business processes and services, which can lead to uninformed decisions. Services are complex mainly because an initial service execution can lead to other cross-departmental and cross-organizational service executions. However, all the transactions involved between the several actor roles share the same essential pattern described in the Enterprise Ontology theory. In this thesis

  we propose to use Design & Engineering Methodology for Organizations (DEMO) to discover the chain of service executions that take place in the field

  within the execution of the organizational business processes. In our research we use the Design Science Research Methodology and we plan to develop a web-based system that will be evaluated through interviews with Service Management experts and field studies in real organizations.

  

Keywords: Services, Business Processes, Enterprise Ontology, DEMO,

  Service Mining, Process Mining

1. Introduction

  Process orientation have proved to be an effective way of increasing organization performance by focusing on business processes instead of emphasizing organization’s functional and hierarchical structures [1]. Process orientation improves financial performance and delivery speed owing to the fact that by discovering and analyzing organization’s business processes it is easy to detect non-value activities which can be eliminated leading to cost reductions and time savings. Once that, in process orientation, business processes are aligned with customer requirements one can also expect that process orientation leads to higher customer satisfaction. Process performance measurement also relates positively with product quality. Besides, an organizational structure in line with organization’s business processes makes organizations faster at launching new products to the market [2].

  Recently, IEE Task Force on Process Mining group constituted by several software vendors, consultancy firms/end users and research institutes has even released the

  

Process Mining Manifesto. Process Mining aims at discovering, monitoring and

  improving real processes (not assumed ones) by extracting knowledge from information systems ’ logs [3]. Process Mining includes process discovery (extracting process models from an event log), conformance checking (monitoring deviations by comparing model and log) and enhancement (extension and improvement of existing process models, using information about the actual process recorded in some event log) [3]. However, there were evidences that the most efficiency gains can often only be achieved within the collaboration of different organizations [4] and by focusing only on a single process instance that implements a service one can be tempted to forget that two services can limit each o ther’s behavior as described in [5]. Besides, it has also been observed that within a single organization the departmental segmentations without an interdepartmental communication can have detrimental effects on the business processes [6]. Transforming isolated efforts into cross-functional activities also suggests the generation of business value [7]. The previous evidences suggest that it is useful to look at process instances as being correlated with other process instances from potentially different services [8]. The problem we want to tackle in this research is the absence of updated organizational models that are able to portray services and business processes. We do not want organizational leaders to make uninformed decisions based on assumed organizational models that does not match with the real ones. Our proposal intends to solve the absence of updated organizational models that are able to portray real time business processes and services. For that purpose we use DEMO (section 5.2) so we can get organizational models that have within them the Enterprise Ontology-based Service definition described in section 3.1. We use this definition because it is powerful enough to describe services executed by both humans and machines. The objectives of our solution, which can be matched with the “Define objectives of a Solution” step in the Design Science and Research Methodology, are: 1.

  To discover real time Enterprise Ontology-based services; 2. To discover real time processes that do happen when we compose services performed by several actor roles;

  We chose DEMO-based models mainly because their simplicity can help us to achieve a representation of the organization’s daily service executions without getting into implementation details, which is good for starting organizational analysis and reengineering. By representing service executions through the essence of those services, we believe that our system is a valuable tool for supporting the task of engineering and reengineering organizational processes.

  The evaluation of our proposal will be based on feedback gathered from both industry practitioners and academics related to the Service Management field and the demonstrations in several organizations, using for that purpose the software prototype we have implemented. Besides we will evaluate the proposal using the Osterle principles [9] and the feedback from the articles that we aim to submit at scientific conferences.

  The remaining of this document is structured in the following way: in section 2 we start by describing our research methodology, in section 3 we discuss the research problem; in section 4 we describe the theoretical Background for this research; in section 5 we provide an overview over the related work; in section 6 we explain our proposal in detail making clear how do we intend to solve the problem; in section 7 we introduce the demonstration step from our research methodology; in section 8 we explain how we plan to evaluate our proposal in terms of the evaluation process and evaluation criteria, and finally in section 9 we describe the communication step of our research methodology and we conclude in section 10 with the expected contributions of our work.

2. Research Methodology

  Our research was conducted using the Design Science Research Methodology (DSRM) that aims to create and evaluate IT artifacts intended to solve identified organizational problems [10]. These artifacts include constructs (vocabulary and symbols), models (abstractions and representations), methods (algorithms and practices) and instantiations (implemented and prototype systems). Additionally, DSRM established seven guidelines [10]:

   Design as an Artifact – Produce a viable artifact in the form of a construct, a model, a method, or an instantiation. The artifacts to be developed in this thesis are described in section 6 (Proposal);  Problem Relevance – Develop technology-based solutions to important and relevant business problems. The relevance of this thesis problem is described in section 3.  Design Evaluation – The utility, quality, and efficacy of a design artifact must be rigorously demonstrated via well-executed evaluation methods (section 8);  Research Contributions – Provide clear and verifiable contributions (section 10).  Design as a Search Process – The search for an effective artifact requires utilizing available means to reach desired ends while satisfying laws in the problem environment. Progress is made iteratively as the scope of the design problem is expanded. As means, ends, and laws are refined and made more realistic, the design artifact becomes more relevant and valuable.

   Communication of Research – The research must be presented effectively to technology-oriented as well as management-oriented audiences (section 9). DSRM includes the following phases [11]:  Problem Identification – Define the specific research problem and justify the value of a solution (section 3);

   Objectives Definition – Infer the objectives of a solution from the problem definition and knowledge of what is possible and feasible. The objectives can be quantitative, e.g., terms in which a desirable solution would be better than current ones, or qualitative, e.g., a description of how a new artifact is expected to support solutions to problems not hitherto addressed (section 1).

   Design and Development – Create the artifact. Such artifacts are potentially constructs, models, methods, or instantiations (each defined broadly) or “new properties of technical, social, and/or informational resources”. Conceptually, a design research artifact can be any designed object in which a research contribution is embedded in the design. This activity includes determining the artifact’s desired functionality and its architecture, and then creating the actual artifact (section 6);  Demonstration – Demonstrate the use of the artefact to solve one or more instances of the problem. This could involve its use in experimentation, simulation, case study, proof, or other appropriate activity (section 7).  Evaluation – Observe and measure how well the artefact supports a solution to the problem. This activity involves comparing the objectives of a solution to the actual observed results from using the artefact in the demonstration (section 8):  Communication – Communicate the problem and its importance, the artifact, its utility and novelty, the rigor of its design, and its effectiveness to researchers and other relevant audiences, such as practicing professionals, when appropriate (section 9).

  In figure 1 we adapted the generic phases of DSRM to this particular thesis context.

  

Figure 1. Design Science Research Methodology Process Model (adapted to this thesis) [11]

  This research methodology has been chosen because DSRM is appropriate for research that seeks to extend the boundaries of human and organizational capabilities by creating new and innovative artifacts. DSRM is also active with respect to technology, engaging in the creation of technological artifacts that impact people and organizations [10].

3. Research Problem

  This section covers the "Identify problem & motivate" step of the DSRM process [11], where we recognize that the absence of updated organizational models focused on

  the real time discovery of services and processes constitutes an important business problem that must be addressed.

  It’s usual that within the execution of a service we need to execute several other services either between different departments within the same organization or between different organizations, as we can see illustrated in figure2.

  

Figure 2. Cross-departmental and cross-organizational services can be performed

  within the execution of a service from the organizational catalogue of services We can see portrayed at figure 2 a vision of a business process as a sequence of

  

services that several actors perform to each other in order to accomplish a final goal

  that is the final result of the process. Those services can be executed by actors from different departments within the same organization or from different organizations. Our research problem is to discover those business processes and get real time organizational models that can portray them.

  We know from the industry that discover the processes in an organization has some challenges. In several cases people don’t know in each part of a process they are inserted in and it’s common to have ad-hoc methodologies for process elicitation. Interviews with workers for process discovery can also not portray what is really performed in their daily work.

  The problem of not having real time organizational models representing processes and all the cross-departmental and cross-organizational interactions necessary to carry on those processes is supported in [4] where the author presents the concept of Service Mining based on the evidences that cross-organizational event data cannot be easily shared, messages exchanged between services tend to be structured, service-orientation continues to be the predominant implementation paradigm and that the most substantial efficiency gains can often only be achieved across different organizations [4].

  By understanding in real time the way services are executed by actor roles one can discover not only the organizational catalogue of services but also find out an updated model that states for each service, the other cross-departmental and cross- organizational services that must also be performed (figure 5), preventing management to make uninformed decisions based on models that does not portray reality. On the other hand, if organizations have already a model for the executions of their services there is an opportunity to perform conformance checking and verify if the service executions are or are not following the model, which can alert management in real time of possible deviations from the previously designed model, avoiding potentially harmful situations for the organization. Besides, if we register in the real time model the times and other measures related to service executions we can enhance services that reveal weaknesses, which cannot be properly performed if we do not have real time organizational models.

4. Theoretical Background

  Stated the problem of not having real time organizational models for dealing with services and processes, in this section we introduce the theoretical tools that support our approach to face the problem..

4.1 Enterprise Ontology

  This section describes the Enterprise Ontology (EO) concepts that will be used throughout the thesis. EO provides us an interesting approach to organizations that allows us to have a powerful insight about the essence of their operations. In other words, EO provides an insight that is completely independent of the organization’s realization and implementation [15]. Being an ontology, EO supply a basis for the common understanding of an area that has interest to a community of people who may have a different cultural backgrounds and who may not know each other at all [15]. EO is supported by a theory named Ψ (PSI) Theory.

  4 .1.1 Ψ (PSI) Theory

  The Ψ-theory is the theory that underlines the notion of enterprise ontology [15]. It has 4 axioms namely the Operation Axiom, the Transaction Axiom, the Composition Axiom and the Distinction Axiom and 1 theorem which is the Organization Theorem.

  Operation Axiom

  The first axiom of the Ψ-theory states that the operation of an enterprise is constituted by the activities of actor roles, which are elementary chunks of authority and responsibility, fulfilled by subjects [15]. In doing so, these subjects perform two kinds of acts: production acts and coordination acts. These acts have definite results: production facts and coordination facts, respectively [15]. By performing production acts (P-acts for short) the subjects contribute to bringing about the goods and/or services that are delivered to the environment of the enterprise [15]. The realization of a production act is inherently either material or immaterial. Examples of material acts are all manufacturing acts, as well as storage and transportation acts. Examples of immaterial acts are the judgment by a court to sentence someone, the decision to grant an insurance claim, and the appointment of someone as president [15]. By performing coordination acts (C-acts for short) subjects enter into and comply with commitments towards each other regarding the performance of production acts [15]. A subject in its fulfilment of an actor role is called an actor.

  Figure 3. Graphical representation of the Operation Axiom

  Figure 3 exhibits the operation axiom graphically. The symbol for coordination is the disc, the symbol for actor roles is the box, and the symbol for production is the diamond [15] .

  The plain arrow from the actor’s box to the C-world disc expresses that actors perform C-acts. The dashed arrow from the C- world disc to the actor’s box expresses that actors take account of the state of the C-world when being active [15]. Likewise, the plain arrow from the actors box to the P-world diamond expresses that actors perform P-acts, and the dashed arrow from the P-world diamond to the actors box expresses that actors take account of the state of the P-world when active [15]. Using the notions of actor roles, C-acts/facts, and P-acts/facts, a full abstraction is made from theirs particular implementations. In this way, the particular subjects that fulfil the actor roles at a particular time, the particular way in which C-acts are performed, and the particularly way in which P-acts are performed are all abstracted [15].

  Transaction Axiom

  The Transaction Axiom makes clear how the coordination acts and the production acts mentioned in the Operation Axiom relate with each other. The Transaction Axiom states that coordination acts are performed as steps in universal patterns [15]. These patterns, also called transactions, always involve two actor roles and are aimed at achieving a particular result [15] . A transaction evolves in three phases: the order phase (O-phase for short), the execution phase (E-phase for short), and the result phase (R- phase for short) [15]. One of the two partaking actor roles is called the initiator, and the other is called the executor of the transaction. In the order phase, the initiator and the executor work to reach an agreement about the intended result of the transaction, i.e., the production fact that the executor is going to create as well as the intended time of creation [15]. In the execution phase, this production fact is actually brought about by the executor. In the result phase, the initiator and the executor work to reach an agreement about the production fact that is actually produced, as well as the actual time of creation (both of which may differ from what was originally requested) [15]. Only if this agreement is reached will the production fact come into existence. The moment at which it starts to exist is agreed upon in the result phase by the two actor roles (to be precise, between the two subjects that play the role of initiator and executor, respectively) [15]. Every Transaction is an instance of a particular transaction type: this transaction type corresponds with the type of the production fact that is the target or result of the transaction [15]. The notion of actor role introduced in the Operation Axiom can now be defined more precisely: an (elementary) actor role has the authority to be the executor of exactly one transaction type.

  Figure 4. The Basic Transaction Pattern marked with red within the Universal

  Transaction Pattern Figure 4 illustrates the Universal Transaction Pattern that represents the relations between the coordination acts (request, promise, state, accept, decline, quit, reject, stop, cancel, allow and refuse). The Basic Transaction Type is represented within the red line of the same figure. That Basic Transaction Pattern is constituted by a request act in which the initiator declares the intention of receiving some result from the executor; a promise in which the executor compromises himself to deliver the requested result, a state where the executor states that he has finished the production of the requested good/service (P-fact) and an accept whenever the initiator agrees with the executor’s produced fact. The Standard Transaction Pattern is an extension of the Basic Transaction Pattern that takes into account that an executor can decline by some reason the request of an initiator. Besides, it also covers the situations in which a state is rejected by the initiator whenever the produced fact doesn’t fulfil the initiator expectations. After a decline act the initiator can send a new request or simply quit the transaction. In a similar way, after a reject act the executor can state a new produced fact or can stop the transaction. However, we just achieve the Universal Transaction Pattern (figure 4) when we consider that a request, a promise, a state and an accept act can be cancelled at any time. In order to illustrate this cancellation patterns we can think for example in a situation in which a customer (initiator) goes to a bakery and requests a loaf to the baker (executor). Cancellation of the request can occur when the customer sees in the shop a new kind of loaf that looks more pleasant to him or her. Normally the baker will be inclined to please the customer and thus will allow the cancellation. From the state “allowed” that is then reached, the customer quits the transaction. After that she or he can start immediately a new one. The baker may, however, refuse if the transaction has already took place two days ago. The state “refused” is a terminal state for the cancellation meaning that the C-fact requested remains the case [15]. A similar reasoning apply for the cancellation of a promise act, state act and accept act.

  Composition Axiom

  The Composition Axiom of the Ψ-theory states that every transaction is enclosed in some other transaction [15]. This axiom provides the basis of a well-founded definition of the notion of business process, stating that a business process is a collection of causally related transaction types, such that the starting step is either a request performed by an actor role in the environment (external activation) or a request by an internal actor role to itself (self-activation) [15]. Every transaction type is represented by the complete transaction pattern [15].

  Distinction Axiom

  The Distiction Axiom of the Ψ-theory states that there are three distinct human abilities playing a role in the operation of actors, called performa, informa and forma. These abilities regard communication, creating things, reasoning, and information processing [15] .

  Figure 5. Distinction Axiom The ability that deals with the form aspects of communication and information is called forma like uttering and perceiving of sentences in some language, the syntathical analysis of such sentences, coding schemes, transmission of data, storage and retrieval of data or documents. The informa ability abstracts the form aspects and is concerned with the content aspects of communication and information as sharing of thoughts between people, the remembering and recalling of knowledge and reasoning [15]. The performa ability concerns the bringing about of new, original things, directly or indirectly by communication as commitments, decisions and judgements.

  Organization Theorem

  The Organization Theorem states that the organization of an enterprise is a heterogeneous systems that is constituted as the layered integration of three homogeneous systems: the B-organization (from Business), the I-organization (from Intellect) and the D-organization (from Document) [15]. Each one of the layers supports the other, namely the D-organization supports the I-organization and the I-organization supports the B-organization [15]. All these three homogeneous systems are in the category of social systems, which means that they are similar in what regards coordination, differing only in the kind of production: the production in the B- organization is ontological, the production in the I-organization is infological, and the production in the D-organization is datalogical [15]. Examples of datalogical production acts are storing, copying, transmitting of documents or data. Acts such as reasoning, computing, deriving, or reproducing knowledge are examples of infological production acts and the acts concerning the creation of original new things, such as creating material products or making judgments are examples of ontological production acts [15].

  Figure 6. Representation of the Organizational Theorem

4.2 The DEMO Methodology The DEMO methodology describes a systematic way to develop enterprise ontologies.

  The ontological knowledge of the organization is expressed through aspect models namely the Construction Model, the Process Model, the Action Model, the State Model.

  Figure 7. The ontological aspect models Construction Model

  The Construction Model (CM) specifies the identified transaction types and the associated actor roles, as well as the information links between the actor roles, as well as the information links between the actor roles and the information banks (the collective name for production banks and coordination banks) [15].

  Process Model

  The Process Model (PM) contains the specific transaction pattern of the transaction type, for every transaction type in the CM [15]. The PM is put just below the CM in the triangle because it is the first level of detailing of the CM, namely the detailing of the identified transaction types [15].

  Action Model

  The Action Model (AM) specifies the action rules that serve as guidelines for the actors in dealing with their agenda. It contains one or more action rules for every agendum type. These rules are grouped according to the actor roles that are distinguished types [15].

  State Model

  The State Model (SM) is on top of the AM because it is directly based on the AM in a way that is specifies all object classes, fact types and ontological coexistence rules that are contained in the AM [15]. Besides that it is put just below the CM because it may also be viewed as the detailing of a part of the CM, namely the contents of the information banks (coordination and production banks) [15].

5. Related Work

  In this section we start by describing the definition of service that is going to be used throughout our research. We continue with a summary of some approaches presented in the lately literature that try to tackle the problem of discovering organizational models with a focus on processes and services, namely process mining, service mining and DEMO Engine.

5.1 Enterprise Ontology Based Service Definition

  In this research we will adopt the definition of service that is based on Enterprise Ontology. This definition, purposed in [12] states that a service is a universal pattern

  

of coordination (c-acts) and production acts (p-acts), performed by the executor of a

transaction for the benefit of its initiator, in the order as stated in the standard of a

transaction. When implemented it has the ability to:

  Get to know the coordination facts produced by the initiator;

  • To make available to the initiator the coordination facts produced by itself.

  

Figure 8. The Standard Transaction Pattern (Service elements are inside the green

  line) [12] The provided service definition is generic enough to hold for two kinds of actor, human actors and IT systems and three kinds of productions acts, namely datalogical, infological and ontological [12] . For both human actors and IT systems, we can distinguish between communication acts and production acts on the datalogical, infological, and ontological level as described in the Organization Theorem. The Enterprise Ontology based service definition allows us to distinguish between six types of services:

   Ontological human service;  Infological human service;  Datalogical human service;  Ontological IT service;  Infological IT service;  Datalogical IT service;

  5.2 DEMO-based SLA

  Mendes & Mira da Silva defined an SLA using EO terms [13]. They stated that a service level agreement is the proposition that two actors (initiator and executor) build together in the O-phase of any ontological transaction. This proposition is clarified by informative acts.

  Also these SLAs have five elements, entity responsible for achieving the SLA, service, target, price and penalty. These elements can be all retrieved by using the correct DEMO models. Figure 9 illustrates the connection between SLA elements and DEMO models.

  

Figure 9. Service Level Agreement proposal and relation to Enterprise Ontology

  [13] The correlation is possible because, in one hand the EO theory describes, very formally, the interactions that happen between customer and provider and in the other hand Service Level Management acts as the interface between customer and provider. And by using the solid basis of EO we can formalize the SLA definition and achieve better representations of the SLA.

  5.3 Process Mining

  Recently, IEE Task Force on Process Mining group constituted by several software vendors, consultancy firms/end users and research has released the Process Mining

  

Manifesto. Process Mining main goal is to discover, monitor and improve real processes

(not assumed ones) by extracting knowledge from information systems’ logs [3].

  Process Mining includes process discovery (extracting process models from an event log), conformance checking (monitoring deviations by comparing model and log) and enhancement (extension and improvement of existing process models, using information about the actual process recorded in some event log) [3].

  Figure 10. The three basic types of process mining explained in terms of input and output.

5.4 Service Mining

  Web services are an established paradigm for architecting and implementing business collaborations within and across organizational boundaries [14]. Web Services provided by different organizations can be inter-connected in order to implement business collaborations, leading to composite web services. Plus, the autonomous nature of and the fact that they are loosely coupled makes it important to monitor and analyse their behaviour. This is called Service Mining [8].

  Service Mining deals with the application of process mining techniques to services [8]. The distributed nature of services makes the design and analysis of service oriented systems that support end-to-end business processes harder [8].

  The Service Mining challenges are highlighted with two questions: 1.

  How to correlate process instances? [8]; 2. How to analyse services out of context? [8];

  The first question emphasizes the problem that arises when instances from different services need to be related, for instance when one customer order may relate to several deliveries in another service [8]. The second issue deals with the fact that one can only observe services running in a particular environment. Service behaviour can change when a service is contextualized within a chain of service executions. The performance or correctness of a service in one context may differ from the performance and correctness of the same service in another context [8].

  5.5 DEMO Engine

  In a recent research Pedro Matos de Carvalho proposed the DEMO Engine, which is a web-based software that registers all the coordination acts involved in a service exchange and make them visible at any time to the stakeholders. The system was proposed for improving service quality but it has the ability to discover the organizational catalogue of services as well [20].

  5.6 Critical analysis

  In this section we provide a critical analysis to the approaches that we early introduced, namely process mining, service mining and the DEMO Engine. Process mining by having a kind of process tunnelling vision is not aware that besides individual processes can have no problems when analysed in isolation, deadlocks can occur when we consider all the services involved within a process instance [8] . In our research we plan to discover the chain of service executions that take place as consequence of an initial service request, taking into account the different process instances that although belonging to possibly different service, share a common execution path. Besides, by having just one common system for executing the business processes it is expected that our software prototype presents more accurate results than process mining once that all the necessary process information is registered in just one shared platform which can be used by different organizations, leading to the discover of accurate cross- organizational business processes. Our research is focused on the concept of Enterprise Ontology-based services which means that the focus is not just on web services as traditionally is the case of Service Mining. By considering Enterprise Ontology-based services we are stating that we are interested in those services performed by both humans and machines. We also are interested in services that can have as result an ontological production (as a decision), an infological production (as a calculation result) and a datalogical production (as data storage). DEMO Engine allowed us to discover the organizational catalogue of services but it did not supported business processes. Business processes that needed to be carry on by a chain of several service executions were not supported by that system. Our system is ready to register both the organizational catalogue of services and the organizational business processes.

6. Research Proposal

  This section corresponds to the “Design & Development” step of the Design Science Research Methodology (DSRM). To solve the problem of not having real time organizational models focused on services and processes, that was described in section 3 we propose to use DEMO to simplify the discovery of the chain of Enterprise

  

Ontology-based services that take place as consequence of the execution of a

particular service from the service catalogue, in the cases that the accomplishment

  of a service is dependent on the execution of other internal services like cross- departmental services, or other cross-organizational services (see the example stated in figure 11). We will develop a web-based system for keeping real time organizational models of the organizational business processes and services. We also support our instantiation with DEMO-based SLAs (described in section 5.2) once that by having a Service Level Agreement for each service, we are able to collect measures specified in those SLAs so that we can enhance services that reveal weaknesses.

  Figure 11. DEMO Process Model that shows the services (in green) that constitute the process for getting a program admission.

  In figure 11 we can see that the business process for having a program admission is built in a chain of two services. The first one is executed by an actor role A01

  • – the admitter and the second one is executed by the actor role CA02 – the admission approver. In a situation like the one portrayed, our web-based system is expected to register all the coordination and production acts presented in those two services and is also expected to update in real time the business process in the case that for example
we just need the service executed by the admitter role and we do not need the involvement of the admission approver anymore. We implemented in our software prototype the universal transaction patterns described within Enterprise Ontology because they can show us the chain of Enterprise Ontology- based services that are executed among actor roles when a given service from the catalogue of services is requested, as well as the state of each of those services. Performing service mining on those Enterprise Ontology-based services allow us to discover services that can be executed by both humans and machines. Besides, those Enterprise Ontology-based services are able to support ontological (as decisions), infological (as calculations) and datalogical (as storing data) acts. By registering in our web-based system the way services are executed in real time by actor roles one can easily discover both the organizational service catalogue and an updated organizational model that portrays for each service from the catalogue of services, the other services that must also be executed in order to finish with success the first one. In other words, our web-based system allow us to keep real time organizational models of processes and services. In those cases where organizations already have a model of the way their services are executed, there is clear opportunity to perform conformance checking and verify if the service executions are or are not following the model. Besides, by registering the times and other measures related to service executions we can enhance services that reveal weaknesses. Summing up, the proposed web-based system, which is considered an instantiation by our research methodology, will allow us to:

   Discover the updated organizational catalogue of services;  Discover real time organizational business processes that implement the services from the catalogue of services;  Discover which coordination acts and production acts have been performed so far within a service execution;  Discover opportunities for service improvement using gathered data from the web-based system and negotiated in the DEMO-based Service Level Agreements;

  Our proposal can be seen as an approach based on the strong theoretical background of Enterprise Ontology & DEMO to deal with the complexity of discovering the chain of services that must be performed between the several actor roles involved, in the context of organizational business processes.

  We believe that the communicative component of the Enterprise Ontology theory enriches our proposal in a time where it has been observed that within a single organization the departmental segmentations without an interdepartmental communication can have detrimental effects on the business processes [6] and that the most efficiency gains can often only be achieved within the collaboration of different organizations [4]

7. Demonstration

  This section corresponds to the “Demonstration” step of Design Science Research Methodology (DSRM). To demonstrate our proposal we plan to apply the proposed prototype to a real world organization. Using real world actors, services and Service Level Agreements we expect to contribute positively to a better understanding of how the execution of the services from the service’s catalogue are correlated with other cross-departmental and cross-organizational services.

  7.1 Prototype

  In order to demonstrate our proposal in a real organization, we are developing a web- based prototype that implements the universal transaction patterns (the standard transaction patterns plus the cancellation patterns) described in Enterprise Ontology. Our software prototype also implements SLA and mines the Enterprise Ontology-based services that are carried on within the execution of organizational business processes. This prototype is being developed using the OutSystems Agile Platform (http://www.outsystems.com).

  At this moment, as we try to find a company where we can demonstrate our proposal and as we keep developing some aspects of our web-based prototype we already have implemented some functionality that allow us to simulate a fictional scenario.

  7.2 Fictional scenario

  The fictional case takes place in a bank and describes a situation where a client goes to his bank and asks for credit. In this situation we assume that we have two actor roles involved in the bank, namely the bank teller role that is implemented by an actor who faces the customer and asks him for specific documentation, and the credit approver role which is the responsible for evaluating and deciding about the credit requests. When facing the client’s credit request, the actor implementing the bank teller role uses our web-based system and selects the credit service from the several services presented in the catalogue of services (see figure 12).

  Figure 12. Screenshot of the Service Catalogue for the fictional bank

  Then, after attaching the documentation to the client’s process the bank teller requests a credit approval internal service. The actor who implements the credit approver role then promises that credit approval service (see figure 13) and states his final decision. At this moment the actor that implements the bank teller role can state the bank’s decision to the customer finishing in this mode that business process.

  Figure 13. Screenshot after the promise of a Credit Service Request

8. Evaluation

  This section explains how we’ll proceed in the “Evaluation” step of DSRM. With this assessment we intend to evaluate how well our proposal supports the solution of the problem stated. Our evaluation method has several steps. We will start by implement our theoretical proposal in a web-based software prototype capable of discovering real time business processes and services using the Enterprise Ontology and DEMO concepts, and evaluate whether we can or cannot implement our theoretical proposal in software logic; afterwards we will interview both service managers and business process managers to assert the proposal utility and to improve our web-based system with the provided feedback; we will then perform field studies where we intend to apply the prototype in real organizations; finally we will submit papers at international conferences and journals for peer review and additionally we will use the Osterle et al. principles [9] to evaluate our research.

8.1 Implementation of our theoretical proposal in a web-based system

  We plan to evaluate how possible it is to implement our theoretical proposal in a web- based system that is able to discover the Enterprise Ontology-based services that are carried on within the organizational business processes. In fact, we already have iterated once over the implementation and it is already possible to discover the chain of services that are needed to carry on the organizational business processes. It is also possible to check the state of those services within the universal transaction pattern, as it is possible to see in figure 13 (section 7). However it is clear that we need to make more iterations over the implementation so we can get an acceptable final result.

  8.2 Interviews

  We intend to interview experts from the business process and service areas so we can use their feedback to improve our web-based system. In fact we have already interviewed a business process manager at a portuguese private company with more than 170 IT consultants. He provided us feedback that will be used to improve our system and even commented that his company developed recently a system similar to ours to create models for document what he called “random processes” within their client companies with the goal of automating those processes later. The fictional demonstration described in section 7 was already made in front of that business process manager. We have already arranged other interviews for the beginning of 2014 and we plan to do more within the year.

  8.3 Field studies

  In order to solve the problem of the absence of real time organizational models that portray services and business processes for specific real life contexts, we plan to evaluate our web-based system in real organizations. The expected results for those organizations can be different according to their own features. For those organizations that are not used to monitor and analyse their business processes and services our intervention can lead to the initiation of works in what concerns business processes and services analysis. For the other organizations that already have thought and applied strategies for improving their models regarding business processes, we can perform conformance checking and verify if the pre-established models are actually used in the daily operations.

  8.4 Paper submission

  We also plan to evaluate our work with feedback gathered from the reviews of our submissions at international conferences and journals. At the moment we have already submitted an article at a conference (section 9).

  8.5 Osterle et al. principles

  In order to evaluate the research Osterle et al. proposed four principles [9]: Abstraction: the artifact must be applicable to a class of problems.

  • Originality: the artifact must substantially contribute to the advancement of
  • the body of knowledge;
  • must allow validation;

  Justification: the artifact must be justified in a comprehensible manner and

  • the respective stakeholder groups.

  Benefit: the artifact must yield benefit, either immediately or in the future for

  Those principles are fundamental to evaluate researches that use DSRM. Next, we will present the evaluation of the proposed artifact using this framework. This evaluation is based on the feedback received with academics and practitioners.

  • of services, may they be ontological, infological or datalogical. The artifact can also be applied to any business process of both public and private organizations.

  Abstraction: the artifact we propose can be applied to discover all the types

  • research of Pedro Matos de Carvalho (section 5). Besides the author’s proposed system can discover the organizational catalogue of services, it was not able to discover the organizational business processes, that is the chain of Enterprise Ontology-based services that take place as consequence of the execution of a particular service from the catalogue of services.

  Originality: the artifact we propose can be contextualized with the recent

  • described in this section. The related work and theoretical background we present in sections 4 and 5 further contribute to the relevance of this principle;

  Justification: the artifact will be justified by all the evaluation process

  • models regarding services and business processes. Consequently, it is expected to enhance organizational performance and awareness as well as to contribute to business process reengineering initiatives.

  Benefit: the artifact provides a way to discover real time organizational

  9. Communication

  This section describes the "Communication" step of the DSRM process, where we will communicate our proposal, its demonstration and evaluation. Hence, besides the thesis, we will submit articles to international conferences and journals where our work will be subjected to peer evaluation.

  In fact, we have already written and submitted to the 4th Enterprise Engineering Working Conference (EEWC 2014) 1 paper with the title “Improving Service Quality using DEMO” that addresses the functionality of our prototype dealing with the record and visibility of the state of each service execution.

  10. Conclusion

  The service sector is the largest economy sector and is the driver for value creation in modern organizations. In order to gain competitive advantages over their competitors, organizations collaborate performing services to each other. There is also collaboration between the different actor roles inside the same organization. In order to attend customer requests for services presented in the catalogue of services, the actor roles perform services between them. Those services are described within Enterprise Ontology theory, and they all share the same theoretical foundation either they are executed by humans or machines. The evidence of the importance of services makes necessary to know how they are implemented in the field by organizations in terms of other cross-departmental and cross-organizational services. We are convinced that by discovering real time organizational business processes, organizations can not only perform conformance checking on the models they have as well as, in the cases they do not have any models at all, to discover them. By collecting measures from the field regarding those business processes, organizations can also decide to take initiatives to enhance their performance.

  In this research we present a proposal to solve the absence of real time organizational models regarding organizational business processes and services. We aim at developing a web-based prototype that is able to mine the chain of Enterprise Ontology-based services that take place as consequence of the execution of a particular service from the service catalogue. We use DEMO so we can show simplified but conceptually strong models that portray organizational business processes. We also use the Enterprise Ontology-based service definition to support our proposal once that all the services share the same essence independently of their concrete implementation. Service Level Agreements are also part of the implementation so that we can gather measures like time to check for opportunities for service enhancement.

  The expected contributions of our research are the implementation of a web-based prototype that is able to discover real time organizational business processes and services as well as an approach to service mining focused on the interactions between the several actors.

  This research follows the Design Science Research Methodology since it can be applied in the context of Information Systems through the creation of IT artifacts that solve real-world organization problems. In the near future we intend to apply and validate our proposal in a private company as well as submit more articles so that we can get appraisal from the scientific community.

  References

  [1] MCCORMACK, Kevin P.; JOHNSON, William C. Business process orientation: gaining the e-business competitive advantage. CRC Press, 2010. [2] KOHLBACHER, Markus; REIJERS, Hajo A. The effects of process-

  oriented organizational design on firm performance. Business Process Management Journal, 2013, 19.2: 245-262.

  [3]

  VAN DER AALST, Wil, et al. Process mining manifesto. In: Business process management workshops. Springer Berlin Heidelberg, 2012. p. 169- 194.

  [4]

  VAN DER AALST, Wil MP. Challenges in service mining: record, check,

discover. In: Web Engineering. Springer Berlin Heidelberg, 2013. p. 1-4.

  [5] ZHENG, George; BOUGUETTAYA, Athman. Service mining on the Web.Services Computing, IEEE Transactions on, 2009, 2.1: 65-78. [6]

  VERGIDIS, K.; TURNER, C. J.; TIWARI, A. Business process perspectives: Theoretical developments vs. real-world practice. International Journal of Production Economics, 2008, 114.1: 91-104.

  [7] ANTONUCCI, Yvonne Lederer; GOEKE, Richard J. Identification of

  appropriate responsibilities and positions for business process management success: Seeking a valid and reliable framework. Business process management Journal, 2011, 17.1: 127-146.

  [8]

  VAN DER AALST, Wil. Service mining: Using process mining to discover, check, and improve service behavior. 2012.

  [9] ÖSTERLE, Hubert, et al. Memorandum on design-oriented information systems research. European Journal of Information Systems, 2010, 20.1: 7-10. [10] HEVNER, Alan R., et al. Design science in information systems research. MIS quarterly, 2004, 28.1: 75-105. [11] PEFFERS, Ken, et al. A design science research methodology for

  information systems research. Journal of management information systems, 2007, 24.3: 45-77.

  [12] ALBANI, Antonia, et al. Enterprise ontology based service definition.

  In: 4th International Workshop on Value Modeling and Business Ontologies (VMBO), The Netherlands. 2009.

  [13] MENDES, Carlos; MIRA DA SILVA, Miguel. DEMO-Based Service

  Level Agreements. In: Exploring Services Science. Springer Berlin Heidelberg, 2012. p. 227-242.

  [14] ALONSO, Gustavo, et al. Web Services: Concepts, Architectures and Applications. Springer Publishing Company, Incorporated, 2010. [15] DIETZ, J. L. G. Enterprise Ontology-Theory and Methodology. 2006. [16] JOHN W. CRESWELL. Research design: Qualitative, quantitative, and mixed methods approaches. Sage, 2009. [17] PRIES-HEJE, Jan; BASKERVILLE, Richard; VENABLE, John R.

  Strategies for design science research evaluation. 2008.

  [18] ÖSTERLE, Hubert, et al. Memorandum on design-oriented information systems research. European Journal of Information Systems, 2010, 20.1: 7-10. [19] HEVNER, Alan R., et al. Design science in information systems research. MIS quarterly, 2004, 28.1: 75-105. [20] CARVALHO, P., et al. Improving Service Quality using DEMO, Master thesis,

  2013

  Appendix.

  As future work, we will iterate again over our web-based protorype so we can perform bug fixes and improve its look & feel. Then we plan to demonstrate the system in a traditional DEMO fictional scenario – the Pizzeria and in a field study. After that we will interviews experts and evaluate our prototype using the gathered feedback. Finally we will write a paper and conclude the dissertation. All the planed start and finish dates or the activities mentioned in figure 14 can vary because some of them rely upon external participants.

  

Figure 14. Project schedule

Novo documento