Scenario-based analysis describes customer needs and focuses on di erent aspects of information systems. A scenario typically has several metrics which compute speci c information about transaction data, organizational structures and con guration settings. The selection and con guration of metrics is not a trivial task and normally cannot be reused over di erent information systems. Therefore, this paper shows how semantics can aid in this process. In fact, the proposed semantically aided analysis approach supports the ve phases of the scenario-based analysis process: (i) selection of metrics relevant to a given scenario, (ii) their con guration and (iii) execution, (iv) evaluation of returned results and (v) reporting of results. Our approach is illustrated by applying it to Reverse Business Engineering, a method for scenario-based analysis commonly used by commercial ERP systems. However, the proposed approach is general enough to also be applied to other analysis techniques.
Currently most companies use information systems to support the execution of
their business processes. Examples of such information systems are ERP, CRM
or Work ow Management Systems. These information systems store and manage
transactional data. In work ow-oriented systems events which are generated
during the execution of business processes can be recorded in so-called event
logs [
Scenario-based analysis describes customer needs and focuses on di erent
aspects within an information system. An analysis scenario is constituted by a
multiplicity of prede ned metrics, which will provide speci c information with
respect to transaction data, master data, organizational structures, and
conguration settings. These metrics extract information from data sources, for
example event logs. An example of a tool using scenario based analysis is the
Reverse Business Engineering tool [
This paper shows a framework where ontologies are used to facilitate
scenariobased analysis. The idea of using semantics to improve the analysis of business
processes is not new [
The remainder of this paper is organized as follows. Section 2 motivates the use of semantics in analyzing data and introduces the approach de ned in this work. Section 3 proposes a concrete scenario to apply this approach to Reverse Business Engineering analysis technique. Section 4 contains an overview of related work in the eld of semantic process analysis, and Section 5 has the conclusions and future directions of our research. 5 See Section 4 for more details.
Scenario-based analysis is characterized by a complex methodology where each step has its own peculiarities. Figure 1 gives an overview of the modelling stack and the analysis phases at the base of our approach.
The rst step in the methodology is the selection of the metrics that have to be evaluated in order to ful ll a certain analysis need. Then, selected metrics have to be fed with input elements that represent its execution constraints; data returned from the execution of analysis metrics are again processed by evaluation metrics that perform further transformations to clean and lter results. Finally results returned by evaluation metrics are transformed into the correct reporting template. This procedure traditionally features a massive use of implicit knowledge in all of its steps, and this knowledge has to be provided by the user. We will now explain how adding semantics can improve these steps, and so the overall analysis process, by using explicit, formal and shared knowledge.
In order to select the proper analysis metrics for a given domain scenario, analysts have to exploit any possible knowledge (usually implicit) linking the metrics with the analysis scenario. This knowledge, in current systems, derives from an extensive usage of the system and from studying the documentation that speci es which task is performed by each of the metrics provided by the system and in which context each metrics can be performed. Formally de ning analysis metrics using semantic technologies enables to link explicitly and automatically metrics to their execution context. Explicit links help analysts in the selection of metrics to be executed according to a set of constraints posed by the data domain and analysis scenario. Semantics can support this selection in two ways: rstly, the analyst may restrict the set of analysis metrics he may apply on the data by selecting a set of concepts he considers relevant for the analysis scenario; secondly, given a set of instance data, it is possible to trace back which metrics may be applied to such data, and the analysis scenario to which the obtained metrics belong.
Once a metric has been successfully selected, it still only represents a relation between a set of input elements and the expected resulting products. To be executed, such a metric still needs to be properly con gured with the right input data. Semantics may provide a great support to automate this con guration step: it can lter data present in the knowledge base to identify possible parameter instances; or it may support the analyst in the creation of the correct instance leveraging on the formalized data model of the metric inputs.
Then, after con guration, an analysis metric is ready to be executed. Currently, the logic of a metric is described using a programming language, thus embedding the logic into a particular implementation choice; therefore, every time a new metrics has to be executed, a programmer must code the corresponding business logic. Semantics can be adopted to explicitly express the logic of an analysis metric in a formal language, thus completely decoupling the logical part from the code that performs the execution. Moreover, in this way, the results of a metrics's execution are directly expressed using the same ontological model adopted to describe the input data, thus removing any need for grounding mechanism, to lift results from the code level to the data model level. In this way also the de nition of post processing metrics is easier: the output of a metrics can be used to feed another select-con gure-execute loop. In particular the selection of a possible following metrics can directly selected according to the output of the preceding one.
The nal step in the analysis process is reporting the results: the user, according to the kind of data and the analysis context, selects the best way of visualizing the results. The same modeling principles used on the analysis metrics to ease selection can also be used to suggest the best reporting strategy for a given context. Moreover, the linkage to concepts expressed in external ontologies eases the task of transforming the results into data directly suitable for existing reporting systems.
The remainder of this section introduces and discusses our approach in more details. 2.1
As introduced in Section 1, our scenario-based analysis approach relies on the
usage of semantic technologies. The overall idea is not bounded to any peculiar
semantic framework; the only requirement is the support for de nition not only
of data models but also of rules/axioms. Although ontologies provide the basis
for some forms of reasoning, ontologies by themselves do not support the range
of knowledge-based services that are required to ful ll the complexity of the
common analysis metrics. For example, the model can be de ned using OWL [
In the rest of the section we describe how adopting semantic technologies enables the support and provision of better automation for the whole analysis process. The key factor to enable the whole analysis process using semantic technologies is to provide a conceptual model that formalizes all of its relevant aspects and covers all of its fundamental steps. In particular, we devise an ontological model that comprises the two main aspects of the analysis process: the analysis metrics to be applied on the data to generate intermediate results and evaluation templates to be applied on the intermediate results to generated nal reports.
The abstractions used to model the analysis metrics should support analysts in their selection, con guration and execution, while models of the evaluation templates should support the ltering of templates according to the chosen analysis scenario, the aggregation/ ltering of results and their presentation. 2.2
To model analysis metrics, we have to keep into account the three fundamental goals we want to achieve: (i) an easy way to allow categorization and thus selection of metrics according to analyst needs and a particular scenario; (ii) support for assisted con guration of the required parameters for selected metrics, enabling, if needed, the assisted creation of complex parameters values; and, nally, (iii) a speci cation of how to compute the metrics, based on (i) and (ii) and on the model of the data under analysis.
Given such objectives, the natural modeling abstraction that ts the categorization of metrics, is the use of a taxonomy. Thus, we formalize metrics as ontological concepts. In more details, we de ne a generic Metric concept that is described by a set of attributes. The attributes are de ned over an ontology, thus enabling a ne grained categorization of metrics; e.g., an attribute may be linked to a concept Scenario, to allow metrics categorization according to an ontology of scenarios. Then, each particular metric is de ned as sub concept of the generic Metric concept and its attributes are de ned over sub concepts of the original attribute type; e.g., an attribute may be linked to a particular analysis scenario de ned by a concept belonging to a branch of the same ontology used at the previous step. The choice for not modeling metrics as instances of the metric concept is fundamental to allow the de nition of sub-metrics using the inheritance mechanism provided by ontologies. In this way it is possible to de ne a well formalized ontology of metrics, where also the attribute ranges of metric concept belong to ontologies enabling e cient and powerful metrics categorization. This enables the analysts to easily select the most suitable metrics, among a huge variety of them, by simply specifying a set of possible values for the range of their attributes (i.e. ltering them by the attributes values). At this stage of the modeling process there is still no need of any connection with the actual model of the data to be analysed.
The modelling abstraction just introduced, while being suitable for the scope of classifying analysis metrics, is not suitable for the speci cation of the metrics themselves and their parameters. This aspect is crucial to enable the assisted con guration of metrics. For this scope we select as abstraction n-ary relations. Relations are used to de ne the metric and its possible parameters, i.e., each relation is a metric and its terms represent the parameters for the metric. Terms are constrained to a type range, thus specifying the expected input types for a given metric. The analyst con gures the metrics by coupling the terms in the relation de nition with the actual instances in the range of the terms type. Con gured parameters (i.e. bound terms) act as input parameters, while free parameters (i.e. unbound terms) act as output parameters. Parameters may be de ned in terms of the model of the data to be analysed (e.g. a given concept in the analysed data), or may be generic and not grounded to the actual data model (e.g. temporal constraints). Such modeling abstraction solves the problem of parameter de nition and their expected order.
The relation itself speci es how to con gure the metric in order to enable its evaluation. It does not contain any information about the way the relation, and hence the metric evaluation results, are actually computed. To formalize such fundamental requirements that enable the metric execution, we use axioms. Axioms (or rules), are logical expression that de ne how a relation is actually computed, enabling its evaluation thanks to the support of a reasoning engine. In particular, logical expressions, given the parameters de ned in the relation and the model of the analysed data, de ne how the terms of the relation instances, which represent the results of the metric execution, are correlated. 2.3
The post processing of the analysis results includes calculation, data ltering/aggregation and data reporting. Post processing metrics can be viewed as the dual of the analysis metrics and are formalized in a similar way. In particular, we de ne a generic Function concept that is described by a set of attributes. The attributes are de ned over an ontology, thus enabling a ne grained categorization of metrics. Among the attributes, it is possible to include the type of post processing metrics, and the analysis metrics to which the metrics may be applied. Then, each peculiar metrics is de ned as sub concept of the generic Function concept and its attributes are de ned over sub concepts of the original attribute type. In this way, we can de ne a well formalized ontology of post processing metrics, that can be automatically selected according to the analysis metric used in the previous steps of the analysis process.
The Function concept ontology enables only the selection and ltering of
existing metrics, as it does not describe the behaviour of such metrics. The
modeling support provided by semantic languages to describe such kind of metrics
is still incomplete. The enactment post processing of the analysis results may
require the use of aggregated metrics (like count, sum, etc.) which, while are
well de ned and supported in the relational world, are not still included in any
semantic query or rule language. Current research e orts within the European
integrated project SUPER are leading to the design of such a language, thus
enabling the formal de nition of post processing metrics over analysis results
[
Finally, the reporting templates, that specify how the results of the post processing step are visualized or reported to analysts, are de ned as an ontology of presentation concepts. Such ontology de nes the possible types of reporting templates and their con guration parameters. Then each peculiar template may be linked to its implementation (e.g. a proper XSLT stylesheet), that given a con gured evaluation template, uses input data to generate the visual rendering for the analyst. The implementation of an evaluation template may be intended in a broader way and include actions like triggering alarms or sending e-mails. This last reporting step is still being studied and not included in our current implementation. 3
The basic methods behind Reverse Business Engineering (RBE) were developed
at the University of Wuerzburg, Germany [
In the process of an RBE analysis the customer chooses one or several analysis scenarios according to his/her needs. Based on the scenarios the relevant business questions are selected and composed to an RBE extractor. The results from the extractor are then imported into the RBE tool for evaluation purposes. Various analytical methods are used to evaluate the extracted data, e.g. to determine average cycle times or calculate Key Performance Indicators (KPIs). Finally, the customer is provided with the outputs in form of reports.
Reverse Business Engineering enables the analysis and improvement of existing business processes and system settings. As explained before, it gives great bene ts by supporting various analysis scenarios according to user needs. However, RBE has some limitations regarding the degree of automation and the reuse of RBE contents. The key elements in the RBE analysis process are the business questions, which are used to collect details about the current implementation of a process and its usage. So far RBE is only applied to SAP systems, thus every business question contains proprietary patterns to query the SAP database. To use RBE for analysing other information systems the patterns of the business questions have to be adapted manually because of the peculiarity of each single system and the absence of a middle layer that hides these di erences to the system. Hence modelling new business questions involves a lot of manual work and requires a substantiated knowledge about the data structure of the respective information systems. Currently the selection of business questions is performed solely according to the chosen analysis scenario. Moreover, business questions are assigned to a standard process model for the purpose of evaluation, so if a company has individual processes that should be evaluated, it causes a lot of manual work to assign the business questions to the corresponding elements in those individual processes.
The remainder of this section describes how our approach has been applied to RBE, yielding a prototype to perform semantic RBE (sRBE). 3.1
sRBE Analysis Process The research activities of Semantic Reverse Business Engineering (sRBE) aim at introducing semantic technologies in the RBE process to augment its degree of automation and its exibility. The goal is to provide a model to describe the sRBE content (i.e. business questions and business metrics) at an abstract level so that they can be de ned and categorised regardless of the underlying technology in the adopted system. In line with the approach described in Section 2, the sRBE analysis process is also composed of the ve phases (selection, con guration, execution, evaluation, and reporting).
At the beginning of an sRBE analysis the customer de nes his/her aims. Generally companies have concrete problems they want to resolve with sRBE, for example the sales manager is interested in all business exceptions that occurred in sales order processing in order to avoid those costly deviations from the standard sales processes. According to this goal the relevant business questions are selected. This selection is done automatically by choosing the corresponding concepts of the ontologies, e.g. analysis scenario and business area.
The second phase in the analysis process is the con guration of the selected business questions. The business analyst can specify various parameters. For example by entering an analysis period the analysis results can be restricted in a way that only those instances are considered whose timestamp is between the start date and the end date. Subsequently, the selected and con gured business questions are executed to retrieve the analysis results. Generally a reasoner is used to query the repository that contains the instances.
The evaluation phase deals with operating the results of the executed semantic business questions. Operating means to compute business metrics, generate statistical information and benchmark the relevant processes. Finally the evaluated values have to be presented to the business analyst. This can be done by using spreadsheets and charts or by displaying the results in the context of the executed process model.
Semantic business questions have to be derived from existing RBE business questions and described using ontological concepts. The semantic annotation of RBE content is performed by linking it to ontological concepts. On the one hand, this allows for mapping generic questions to domain speci c ontologies and, hence, to consider speci c issues and terminologies of the selected domain. On the other hand, the semantic business questions and metrics can be assigned to any customer-speci c process model which is also described semantically and, thus, the individual processes of a company can be easily evaluated. The main concepts to classify the business questions are the following: { Question Type: Each business question belongs to one of the question types \List", \Count", or \Sum", which determine the extraction and presentation of their answer. { Activity : Every business question refers to an executed activity. For example the business question \How many sales o ers were approved?" refers to the activity \approve sales o er". { Analysis Scenario: This concept classi es business questions according to the analysis scenarios they support, e.g. as-is analysis or exception analysis. { Analysis Period : By assigning this concept to business questions the result values can be constrained by a time slice.
Note that the rst three items support the actual classi cation of analysis metrics while the last one can be considered as an execution parameter. According to this distinction, we have modelled classi cation concepts inside the concept Business Question as reported in Listing 1.1 using the method explained in Section 2.2. 1 concept BusinessQuestion 2 hasDataCategory impliesType DataCategory 3 hasScenario impliesType AnalysisScenario 4 belongsToBusinessFunction impliesType UPO#BusinessFunction 5 6 concept DataCategory 7 concept Con gurationData subConceptOf DataCategory 8 concept MasterData subConceptOf DataCategory 9 concept OrganisationData subConceptOf DataCategory 10 concept TransactionData subConceptOf DataCategory 11 12 concept AnalysisScenario 13 concept AnalysisOfExceptions subConceptOf AnalysisScenario 14 concept AsIsAnalysis subConceptOf AnalysisScenario 15 concept HarmonisationAndStandardisation subConceptOf AnalysisScenario
Listing 1.1. The BusinessQuestion concept
Listing 1.2 shows an example of a business question, namely the question \Which sales orders were processed?", that has been modelled in the sRBE ontology. Since this question is classi ed as a part of an as-is analysis scenario, belonging to an order processing business function and to a transaction data category (lines 5{8), the corresponding concepts in the ontology have been linked to the business question, thus allowing selection. The relation \WhichSalesOrdersWereProcessed" instead models the execution parameters, such as the analysis period and the function of the successfully executed event. Listing 1.2. Example of a semantic business question: selection-oriented concept and result-oriented relation
As explained in Section 2.2, according to our modeling abstraction, the execution of each business question is performed by an axiom which is executed onto a reasoner, as reported in Listing 1.3, while querying the results is accomplished by using the con gured relation.
1 axiom WhichSalesOrdersWereProcessed X 2 de nedBy 3 ?pe[hasCreationTimeStamp hasValue ?date, occurredDuringProcessExecution hasValue ?proc, GeneratedBy hasValue ?actor] memberOf EVO#
SuccessfulExecutionEvent 4 and ?proc memberOf BFO#OrderProcessing 5 and ?role[playedBy hasValue ?actor] memberOf BRO#MarketingAndSalesRole 6 and ?period[hasStartValue hasValue ?start, hasEndValue hasValue ?end] memberOf RBEO#
AnalysisPeriod 7 and ?date > ?start 8 and ?date < ?end 9 implies 10 WhichSalesOrdersWereProcessed(?pe,?proc,?role,?period).
Listing 1.3. Example of an execution axiom
The obtained results are the basis for further calculations, therefore metrics
have to be de ned and described semantically. A classi cation criteria is the
concept Dimension with its speci cations Time, Cost and Quality. An example
of a metrics is \cancellation rate of sales orders", which is calculated by dividing
the results of the business questions \How many sales orders were cancelled?"
by \How many sales orders were created?" [
To test our approach, we have developed within the SUPER project an sRBE engine prototype and integrated it with the SUPER architecture. Figure 2 illustrates the overall architecture of the sRBE engine including its connection with the SUPER architecture. The sRBE engine itself is composed by three layers, the reasoning engine (based on IRIS reasoner for WSML6) that provides support for querying and inferring over semantic data; the business logic that includes a set of prede ned functions to support the analysis work ow as introduced in Section 2 and provides access to the reasoner; a Graphical User Interface (presented in Figure 3) that, using the functionalities provided by the business logic, allows the users to performs the sRBE process.
sRBE Toolkit
sRBE GUI sRBE Business
Logic Reasoner Engine
s u B e c i v r e S c it n a m e S r e p p a r W c it n a emExternal Datasources
The sRBE engine includes a Business Question Repository, where the modelled questions and a set of other ontologies that are used to de ne the Business Question taxonomy are stored.
Analysis data are imported from the Semantic Service Bus provided by SUPER architecture, which includes the access to: the Business Process Library, which contains all the model of the deployed and logged processes; the Execution 6 http://iris-reasoner.org History, which has all the log of the processes executions; and nally, any other repository (also non semantic) with data needed to analyze business processes (e.g. ERP data).
Data exposed by the Semantic Service Bus are seamless integrated through the IRIS reasoner engine, making it possible to perform queries over distributed data. 4
The idea of using semantics to perform process analysis is not new. In 2002,
Casati et al. [
This paper presented an approach towards the adoption of semantics to support scenario-based analysis. The proposed semantic meta-model is suitable for any scenario-based analysis because it encompasses all the phases necessary for the selection, con guration and execution of scenario-based metrics, as well as the evaluation and reporting of results. The immediate gain is the leverage of the scenario-based analysis techniques to the expressive power o ered by semantic languages, which allows not only to describe data models but also functionalities and their execution logic.
The major strengths of our approach are related to the \lifting" of the analysis to the conceptual level: the results of the analysis are more precise (because they don't rely on syntactic or ad hoc data extractors); there are extended possibilities to reuse models at various levels (e.g. ontologies, business questions); we can get a larger automation of data processing and analysis. On the other hand, the weaknesses of our approach are related to the need for reliable models and ontologies in the whole process, thus requiring the e ort to develop and maintain them. Moreover, our approach, even if very promising, is still a bit immature to be applied to large-scale and complex real-world scenarios.
However, we can see several opportunities to achieving the objective of an improved system analysis: semantic technologies are gaining momentum in the community, numerous supporting tools are becoming available and stable; nally, there is an increasing awareness of the need for semantics in business scenarios.
Additionally, the presented approach has been applied to the Reverse Business Engineering technique, one of the most important scenario-based analysis techniques in the context of business process analysis. This application emphasized the bene ts that the introduction of semantics brings to RBE, such as a greater level of automation, generation of system-independent analysis, better reuse of sRBE content and better administration of sRBE content.
Finally, as our approach is database independent, wider spread business questions can also be used as extractors to get and semantically annotate service based transaction data, e.g. for Business Intelligence (BI) purposes (like extractors for data warehouses). Future work will focus on re ning our prototype and developing more domain ontologies for the support of semantic-based analysis scenarios, so that it can be tested on a real-life use case scenario.
This research has been supported by the EU co-funded IST project SUPER (FP6-026850). We would like to thank the whole SUPER Consortium for their valuable contribution.