Building-Blocks Selection based on Business Processes Semantics for SAP R/3

Abstract

We present a semantic-based toolkit for the automated selection of Building-Blocks in SAP R/3, aimed at easing and improving Best Practices reusability. The automated selection process exploits Abduction-based Concept Covering in Description Logics to select Building Blocks and provides, if necessary, logic-based information on what remains unavailable.

Introduction

of their reuse from an implementation point of view. Basically, the BB content is de¯ned by the identi¯cation of which Business Process parts can be reused within a prede¯ned solution. The BB Library 4 provided by SAP in fact aims at sharing SAP knowledge. It is also possible to develop speci¯c BBs able to provide particular solutions within a company context. Nevertheless, because of the rapid growth of the BBs number, choosing the correct BB in order to satisfy part of a speci¯c Business Process, is expensive in terms of time, as the selection is driven only by the developer experience. In this paper we show how technologies borrowed from the Semantic Web initiative can help in both modeling using semantics BB descriptions and business processes, and supporting consultants sharing their knowledge, by allowing automated selection of BBs from available business processes. 2

Formal Framework

Our framework adopts a subset of OWL-DL as ontology language and Description Logics (DLs) [ 2 ] as formal framework. We assume the reader be familiar with basics of both of them. Here we just brie°y recall some standard and nonstandard inference services in DLs. For the sake of conciseness, in the rest of the paper we will use DL syntax instead of OWL-DL one. DL-based systems usually provide two basic reasoning services: Concept Satis¯ability : given an ontology T and a concept C, does there exist at least one model of T assigning a non-empty extension to C? Subsumption: given an ontology T and two concepts C and D, is C more general than D in any model of T ? Given an ontology T modeling the investigated knowledge domain, a request description C and a resource description D, using subsumption it is possible to evaluate either (1)if the resource completely ful¯lls the request { T j= D v C, full match { or (2)if they are at least compatible with each other { T j= C u D 6´ ?, potential match { or (3)not { T j= C u D ´ ?, partial match [ 9 ].

It is easy to see that in case of full match all the information speci¯ed on C is expressed, explicitly or by means of the ontology T , also in D. Unfortunately full matches are very rare and typically, potential matches occur. Hence, there is the need to go beyond subsumption in order to manage these frequent situations. A non-standard inference service is needed to formulate some explanation hypotheses H on why a full match does not occur, that is what is not expressed in D and is requested in C, and how it can be exploited in order to ¯nd other available resources exposing among their characteristics the ones modeled on H. This non-standard inference has been named Concept Abduction [ 5 ]. Given an ontology T and two concept descriptions C and D satis¯able w.r.t. T such that T j= C u D 6´ ?, using Concept Abduction it is possible, to compute a concept description H such that T j= D u H v C.

When several available resources Di exist, potentially matching the request C, if a single resource does not completely ful¯ll the request, is it possible to 4 http://help.sap.com/bestpractices/BBLibrary/bblibrary start.htm ¯nd a pool of available resources such that the conjunction of their description ful¯lls the request description?

In other words, is it possible to compute a Concept Covering (CC) of D using some Ci? Concept covering was initially introduced in [ 7 ] and then extended and reformulated in terms of Concept Abduction problems in [ 4 ]. In [ 4 ] also a greedy algorithm { GREEDYsolveCCoP { computing a Concept Covering is proposed. Using GREEDYsolveCCoP, a fast, though approximate, solution can be computed in case the algorithm is not able to ¯nd an exact one, if it exists. In case of non-exact solution, an explanation on why the solution in not exact is provided.

Given an ontology T , a request description C and a set of available resource descriptions R = fD1; D2; :::; Dng, where C and each Di 2 R are satis¯able w.r.t. T , a solution to a concept covering problem is ¯nding a subset RC = fDj g µ R and a concept description H such that for each Dj 2 RC : i. T 6j= uDj ´?; ii. uDj u H v C Notice that if a full cover is found then both uDj v C and H ´ >. Also notice that a CC is not trivially a di®erent formulation of a classical minimal set covering (SC) problem, as an exact solution to a Concept Covering may not exist. Furthermore in SC elements are not related with each other, while in CC elements are related with each other through axioms within the ontology, and while the aim of an SC is to minimize the cardinality of RC the aim of a CC is to maximize the covering. 3

A semantic-based toolkit to improve best practices reusability

The framework and toolkit we propose is able to select the BBs to be installed with respect to a given business process and it allows a developer community to share the knowledge they acquire, together with the one provided by SAP documentation. The approach is based on an architecture comprising: { a Knowledge Base Repository composed by an Ontology Repository (OR) and Instance Repository (IR). In OR all the ontologies shared within the system are stored in OWL ¯les { we use di®erent ontologies interacting with each other via the owl:imports TAG. IR contains all the concept descriptions representing both BBs capability descriptions and Business Processes. IR is a DB-based repository for e±ciency reasons. IR and OR can be stored on di®erent machines. The idea behind this decentralized structure is based on the observation that di®erent consultants and companies may refer to the same ontologies in order to describe their own BBs or Business Processes. Hence, the companies share the ontologies on a single OR but there are di®erent IRs, one for each company. { a Client GUI: a user friendly interface allowing the user to interact with the system in order to query, tell new knowledge, examine the available modeled knowledge. By mean of this graphical interface it is possible then to: a) browse the ontology b) describe a new BB and store its ontology-based description within IR c) query the system and compose the request using the knowledge modeled with the ontology { a Reasoner { MAMAS5 { to perform inferences based on formal semantics of the language used to model both the ontologies and the individuals.

Semantic modeling of Building Blocks

By means of OR, a common terminology can be shared by the community of SAP consultants. We modeled all the ontologies used within the system using the ALN subset of OWL DL, thus allowing to exploit the Concept Abduction [ 5 ] inference service via MAMAS and perform a Concept Covering of the user request. 5 MAMAS is a DL-based inference engine performing Concept Abduction and Concept Contraction[ 3 ]. It exposes a DIG-based interface and is available via HTTP at http://dee227.poliba.it:8080/MAMAS-devel/

The main competency questions for the ontologies we developed are basically related to BB functionalities and Business Process activities. Some of them are: { Which are the activities a Business Process must perform? { Which scenario better approximate a given Business Process and which are the BBs used to implement it? { Which are the BBs needed in order to manage a particular Business Process?

In order to satisfy the needed prerequisites, a BP description will contain the list of the activities to be performed by such process. Notice that in a BP, from the application point of view, only activities requiring particular functionalities from R/3 are relevant and then modeled.

As an example, let us consider we want to compose BBs in order to model the Business Process described in the following 6:

The process creates a service contract, which would re°ect the terms of service agreed upon with the customer. A vendor contract is set up to de¯ne the agreement for external services. The service order is then used for planning and executing the work to be performed by both internal and external resources. A purchase requisition is automatically generated from the service order for the external service requirement and a purchase order is created from it. The Cross-Application Time Sheet (CATS) is used for recording employee hours and the service entry sheet captures contracted labor. The costs associated with internal work are transferred to the service order. Resource-related billing, results analysis, and pro¯tability analysis can be performed on a periodic basis or at the end of the project.

Now suppose that such BP belongs to a services provider and that transactions needed in order to complete all the activities belong to FI, MM, CATS, SD and CS modules provided by R/3 7. Using DL syntax, with respect to the reference ontology, we can formulate the previous BP as follows: BusinessProcess u 8generatesDocument:(CustomerContract u VendorContractForService u ServiceOrder u Quote u 8refersToDocument:PurcaseRequisition u ServiceOrder u 8refersToData:Time) u 8recordsTime:InternalEmployeeTime u 8recordsTime:ExternalEmployeeTime u 8generatesDocument:(BillingDocument u 8refersToDocument:(ServiceOrder u VendorContract) u 8refersToData:Cost) u 8analyzesDocument:BillingDocument u 8hasIndustry:ServicesProvider u 8hasSAPModule:(FI u SD u CATS u CS u MM) The above description is easily understandable even by an inexperienced user. This is very important in order to increase the friendliness during the query 6 http://help.sap.com/bestpractices/industry/serviceindustries/v346c it/html/R3/ContrbasedSO.htm 7 For conciseness we straightforwardly adopt SAP naming conventions [ 8 ] formulation. To this aim they are graphically represented using a tree structure where BusinessProcess is the root node and its children represent the BP activities (see Fig. 2). The GUI also simply allows the user to communicate with the KB and use the knowledge modeled and stored within it. In an equivalent way, a BB is described with respect to the functionalities it provides, representing the set of activities which can be performed using the BB itself with respect to a BP.

Textual requirements description: a natural language translation of the OWL DL expression

Tooltip content is loaded on the fly, taken from the owl:comment TAG within the ontology.

Visual representation of the OWL DL based request

Used to set R/3 available modules (e.g. SD, FI,...)

Exploits domain/range definitions within the ontology and presents such relations to the end user

Query editor (dockable panel)

Building Blocks Selection via Concept Covering

Given a BP description, it is possible to perform either a search based on already known business scenarios or a fully automated search of a set of BBs that can implement the BP described in R/3. In order to ¯nd a set of BBs whose composition satis¯es the requested BP, their description are retrieved from the KB/repository where they are stored. Notice that, since a BB description represents the functionalities it provides w.r.t. a BP, the structure of such description is similar to the BP request one. Given an ontology T , a set of BB descriptions in a repository, R = fBB1; BB2; :::; BBng, and a Business Process request BPd, where T 2 BBi ´ ? and T 2 BPd ´ ? { both each BBi 2 R and BPd are consistent w.r.t. to an ontology T { we compute a Concept Covering of BPd w.r.t. R. In other words, given a set of BB descriptions and a BP request BPd, we ¯nd a subset of the available BBs, such that their conjunction is a cover of BPd, that is they are able to perform the task required within BPd.

Results of the concept covering process

Explanation on the uncovered part of the user request in the proposed solution

Now we show the proposed approach with the aid of an example using as a request the BP described in the previous section. Now suppose to have BBs ZCS42, ZMM3, ZMM37, ZSD23, YB3 8 as in the following: ZCS42 = BuildingBlock u 8generatesDocument:ServiceOrder u 8updatesDocument:ServiceOrder u 8closesDocument:ServiceOrder u 8hasSAPModule:CS u 8hasIndustry:ServicesProvider ZMM 3 = BuildingBlock u 8generatesDocument:VendorContractForService u 8generatesDocument:(Quote u 8refersToDocument:PurchaseRequisition) u 8recordsTime:ExternalEmployeeTime u 8hasSAPModule:MM u 8hasIndustry:ServicesProvider ZMM 37 = BuildingBlock u 8generatesDocument(RequestForQuotation u 8refersToPhysicalResource:Material) u 8evaluatesDocument(RequestForQuotation u 8refersToData:Cost u 8refersToPhysicalResource:Material) u 8generatesDocument(VendorContract u 8refersToPhysicalResource:Material) u 8generatesDocument(PurcaseOrder u 8refersToDocument:RequestForQuotation) u8submitDocument(ResourcesRelatedBillingDocumentu8refersToPhysicalResource:Material) u8generatesDocument:MaterialDocumentu8hasSAPModule:MMu8hasIndustry:ServicesProvider 8 again we adopt R/3 naming conventions ZSD23 = BuildingBlock u 8generatesDocument:CustomerContract u 8generatesDocument(BillingDocument u 8refersToDocument:ServiceOrder u 8refersToData:Cost u 8refersToDocument:VendorContract) u 8hasSAPModule:SD u 8hasIndustry:ServicesProvider

The result obtained shows that, in the computed set of BBs, it is not speci¯ed if the generated document is speci¯cally a CustomerContract and the proposed solution refers to the SD SAP module. In Fig. 3 it is depicted how results are presented to the user. 6

Discussion and Conclusions

The practical use of our approach depends on two major elements. The ¯rst one is the consultants evaluation. To this end the toolkit is being evaluated in the framework of a large italian consultants company. The second one is the computational e±ciency of the CC process, to allow practical on-line usability of the selection process. It is well known that basic set covering is NP-Hard; our greedy Concept Covering can be proved, for the ALN OWL-DL subset we currently adopt, to be polynomial. Nevertheless we evaluated system performances, generating a set of 7000 concept descriptions. The depth (see [ 9 ]) of the descriptions follows a Gauss distribution with ¹ = 10 and ¾ = 20. Then we performed an automated search of BBs considering di®erent BB repositories and di®erent BP requests. Each repository contained a variable number of BB description, randomly selected from the initial set of 7000 descriptions as well as BP descriptions. Results are plotted in Fig. 4. The graph shows how t=jDj (time per BP depth) changes w.r.t. the number of BB descriptions in the repository, while performing a Concept Covering of a description BP and con¯rms the polynomial behavior of the algorithm.

References

1. SAP AG . Contract-based Service Order with Third-Party Services and Time & Material Billing, SAP Best Practices for Service Providers . http://help.sap.com/bestpractices/industry/serviceindustries/v346c it/html/ index.htm, 2003 .

2. F. Baader , D. Calvanese , D. Mc Guinness , D. Nardi , and P. Patel-Schneider, editors. The Description Logic Handbook . Cambridge University Press, 2002 .

3. S. Colucci , T. Di Noia , E. Di Sciascio , F.M. Donini , and M. Mongiello . Concept Abduction and Contraction for Semantic-based Discovery of Matches and Negotiation Spaces in an E-Marketplace . Electronic Commerce Research and Applications , 4 ( 4 ), 2005 .

4. T. Di Noia , E. Di Sciascio , and F. M. Donini . Extending and Computing the Concept Covering for the Semantic Web . Technical report, DEE Tech-Rep n. 21 /04/S, http://sisin°ab.poliba. it/PDF/TECH-REP-21-04-2 .pdf, 2004 .

5. T. Di Noia , E. Di Sciascio , F. M. Donini , and M. Mongiello . Abductive matchmaking using description logics . In IJCAI-03 , pages 337 { 342 , 2003 .

6. R/3 Simpli¯cation Group. Best Practices for mySAP All-in-One, BUILDING BLOCKS CONCEPT , June 2003 .

7. M-S. Hacid , A. Leger , C. Rey , and F. Toumani . Computing Concept Covers: a Preliminary Report . In DL' 02 , volume 53 of CEUR Workshop Proceedings , 2002 .

8. J. A. Hern ¶andez . SAP R/3 Handbook. 2nd edition , 2000 .

9. T.Di Noia , E. Di Sciascio , F. M. Donini , and M. Mongiello . A system for Principled Matchmaking in an Electronic Marketplace . International Journal of Electronic Commerce , 8 ( 4 ):9{ 37 , 2004 .