Semantisches Prozessmanagement und E-Business

Transkript

1 explicit shared domain conceptualization semantics formal menatal model Semantisches Prozessmanagement und E-Business Lehrveranstaltung im SS 2013 Michael Fellmann Institut für Informationsmanagement und Unternehmensführung SBPM&EB SS 2013 Michael Fellmann

2 Agenda Vorstellung ausgewählter Standards Teil 2 Transaktionen: SAP IDoc, RosettaNet Prozesse Traditionelle Ansätze: BizTalk, ebxml Neuere Ansätze: Semantic Web Services, Enterprise Mashups Kataloge: BMEcat, cxml SBPM&EB SS 2013 Michael Fellmann 2

3 SAP IDoc SBPM&EB SS 2013 Michael Fellmann

4 SAP IDoc Grundidee und Komponenten IDoc steht für Intermediate Document Ein idoc ist ein Dokument, mit dem geschäftliche Nachrichten zwischen SAP- Systemen übertragen werden können. IDoc-Dokumente können mehrere Arten von Nachrichten zu einem Geschäftsprozess übertragen und können Bewegungs- Stamm- oder Steuerungsdaten enthalten. Komponenten Kontrollsatz, dieser besitzt ein einheitliches Format für alle IDoc-Typen. Datensätze, die aus einem fixen Verwaltungsteil und einem Datenteil bestehen. Statussätze, die Verarbeitungsstationen beschreiben, die ein IDoc durchlaufen kann. Die Statussätze haben für alle IDoc-Typen das gleiche Format. Beispiel Die Bestellung Nr wurde als IDoc Nr an einen Lieferanten versandt. IDoc Nr ist im IDoc-Typ ORDERS01 formatiert und besitzt u.a. die Statussätze "erzeugt" und "versandt". Der Bestellung entspricht die "logische" Nachricht ORDERS. Quelle: IDoc-Typ (SAP-Bibliothek - Glossar) SBPM&EB SS 2013 Michael Fellmann 4

5 Quelle: How-to Guide SAP NetWeaver 04 How To Sample IDoc-XI Scenarios Version 1.00 August SDN SAP E-Business-Standards SAP IDoc XML-Serialisierung als Alternative zu Tab-separiertem Text SBPM&EB SS 2013 Michael Fellmann 5

6 RosettaNet SBPM&EB SS 2013 Michael Fellmann

7 RosettaNet Einführung und Historie Entstehung Gründung 1998 als Non Profit Organisation in den USA. Anfangs 40 Unternehmen, heute ca. 600 Unternehmen. Die teilnehmenden Firmen kommen vornehmlich aus dem Bereich der Informationstechnologie. Mitglieder sind namhafte Firmen wie Microsoft oder Intel. Verbreitung Aufgrund der Struktur eher in den USA verbreitet. In Europa eher weniger verbreitet. SBPM&EB SS 2013 Michael Fellmann 7

8 RosettaNet Grundidee Standardisierung des Austausches von Geschäftsdokumenten zwischen den Mitgliedern zur Vermeidung von Medienbrüchen und Datenkonvertierungsproblemen. RosettaNet basiert auf offenen XML-Standards. Quelle: Nickull 2001 SBPM&EB SS 2013 Michael Fellmann 8

9 RosettaNet Partner Interface Processes (PIPs) Charakterisierung der PIPs PIPs sind ein Kernaspekt von RosettaNet. Mit den PIPs werden Geschäftsprozesse und damit verbundene Dokumente spezifiziert. PIPs sind XML-basierte System-zu-System-Dialoge, welche Geschäftsprozesse zwischen Handelspartnern unterstützen. PIP-Strukturierung Aktuell werden acht verschiedene Kernprozesse (Cluster) unterschieden, denen die einzelnen PIPs zugeordnet werden können. Die Cluster sind weiter unterteilt in Segmente, die mit Buchstaben gekennzeichnet werden und diese in Bereiche, die mit Nummern gekennzeichnet werden. Beispiel: PIP3A4 3 = Cluster 3, A = Quote and Order Entry, 4 = Request Purchase Order. SBPM&EB SS 2013 Michael Fellmann 9

10 RosettaNet Partner Interface Processes (PIPs) Bezeichnung Beschreibung Cluster 0 Support Administrative Funktionen von RosettaNet Cluster 1 Partner Product and Service Review Sammlung, Wartung und Distribution von Daten über Geschäftspartner Cluster 2 Product Information Produktbeschreibungen, Änderungsnachweise und Synchronisation mit Produktkatalogen Cluster 3 Order Management Bestellung, Konfiguration, Versand, finanzielle Abwicklung Cluster 4 Inventory Management Nachbestellungen, Auswertungen SBPM&EB SS 2013 Michael Fellmann 10

11 RosettaNet Partner Interface Processes (PIPs) Cluster 5 Bezeichnung Marketing Information Management Beschreibung Vermittlung von Marketinginformationen, wie Aktionen oder Sonderverkäufe Cluster 6 Service and Support After-Sales-Services: Garantieleistungen, Technischer Support Cluster 7 Manufacturing Austausch von Daten zu Produktdesigns, Konfigurationen, Qualitätsmaßstäbe SBPM&EB SS 2013 Michael Fellmann 11

12 Quelle: E-Business-Standards RosettaNet Beispiel-DTD für PIP3A1 SBPM&EB SS 2013 Michael Fellmann 12

13 RosettaNet Beispiel-DTD für PIP3A1 SBPM&EB SS 2013 Michael Fellmann 13

14 RosettaNet Beispiel-DTD für PIP3A1 SBPM&EB SS 2013 Michael Fellmann 14

16 BizTalk SBPM&EB SS 2013 Michael Fellmann

17 BizTalk Einführung und Komponenten BizTalk ist eine EAI-Integrationsplattform zum Aufbau einer (zentralistischen) Integrationsarchitektur. XML- und Webservice-Technologien spielen eine zentrale Rolle, wobei zur externen Kommunikation auch klassische EDI-Standards unterstützt werden (EDI, ANSI X12, ) Zentrale Komponenten Ports und Adapter: Logische Abstraktion zum Senden/Empfangen von Nachrichten Pipelines: Bearbeiten, modifizieren und verifizieren der Nachrichten Messaging Engine: Nachrichtenempfang und -verarbeitung, Auslieferung an den Empfänger, Konsistenzprüfungen, Error-Handling Orchestration Engine: Graphische Modellierung von Workflow-Logik und Kontrolle der Ausführung im Zusammenspiel mit der Messaging Engine Business Rules: Werden von der Orchestration Engine aufgerufen und erlauben eine flexible Änderung von Prozessen (bspw. Rabattbedingungen) Business Activity Monitoring: Protokollierung von Daten, Reporting SBPM&EB SS 2013 Michael Fellmann 17

18 BizTalk Abstrakte Darstellung einer (idealen) Architektur Quelle: SBPM&EB SS 2013 Michael Fellmann 18

19 BizTalk Zusammenhang der Komponenten Quelle: Dunphy, G. et al. (2009): Pro BizTalk. Springer : New York, S. 272 SBPM&EB SS 2013 Michael Fellmann 19

20 BizTalk Mapping zwischen verschiedenen Schemata Weitere Matching-Arten per Kontextmenü: Automatischer Vorschlag von relevanten Elementen, Definition von Transformationsregeln etc. Quelle: Splunteren, R. (2010); Mapping in BizTalk 2010: My favorite new features. Online: biztalkmessages.vansplunteren.net SBPM&EB SS 2013 Michael Fellmann 20

21 ebxml SBPM&EB SS 2013 Michael Fellmann

22 ebxml Einführung ebxml steht für Electronic Business using extensible Markup Language. ebxml wurde im Jahre 1999 als eine gemeinsame Initiative von UN/CEFACT und OASIS ins Leben gerufen. Grundgedanken von ebxml Schaffung technischer Spezifikationen, die einen einheitlichen, weltweiten, konsistenten Austausch elektronischer Geschäftsdaten auf der Grundlage von XML ermöglichen. Senkung der Eintrittsbarrieren für das E-Business insbesondere für KMU (kleine und mittlere Unternehmen) sowie Entwicklungsländer. SBPM&EB SS 2013 Michael Fellmann 22 22

23 ebxml Komponenten Komponente BPSS CC CPP CPA ebms Repository/Registry Nutzen / Zweck Modellieren von Geschäftsprozessen Semantische Bausteine für Datenformate im Geschäftsbereich Darstellung von Unternehmen und Organisationen Vereinbarungen zwischen Geschäftspartnern Format für Botschaften zwischen Geschäftspartnern Speicherung und Publikation von geschäftlich relevanten Informationen SBPM&EB SS 2013 Michael Fellmann 23

24 ebxml Komponenten Business Process Specification Schema (BPSS) Das BPSS dient als Schema zur Spezifikation von Geschäftsprozessen. BPSS bietet einige Muster zur Beschreibung logischer Abläufe, die aus dem Bereich des Workflow Managements bekannt sind (z.b. Sequence, Parallel Split, Synchronization, Exclusive Choice, Simple Merge, Multi Choice). Kollaborationen zwischen verschiedenen Parteien werden als globale Choreographien beschrieben. Core Components (CC) Wiederverwendbare, semantisch wohldefinierte Bausteine, aus denen Geschäftsdokumente zusammengestellt werden können. Diese Bausteine sind unabhängig von einer konkreten Syntax, die Spezifikation beinhaltet auch methodische Aspekte zur Schaffung dieser Bausteine. SBPM&EB SS 2013 Michael Fellmann 24

25 ebxml Komponenten Collaboration Protocol Profile (CPP) Ein CPP beinhaltet eine Beschreibung eines Unternehmens bezüglich seiner Eigenschaften im E-Business. Beispiele für Informationen sind Adressdaten, aber auch unterstützte Protokolle. Repository/Registry Die grundlegenden Komponenten einer ebxml-implementierung sind jedoch die Registratur (Registry) und der Speicher (Repository). Das Repository dient als zentraler Speicher für sämtliche Informationen, die bei der Abwicklung von Geschäften zwischen Unternehmen notwendig sind. Die in der Registry enthaltenen Objekte sind Metadaten in Bezug auf die Inhalte des Repository. Die Registry dient der Verwaltung dieser Daten und bietet zusätzliche Services an. SBPM&EB SS 2013 Michael Fellmann 25

26 ebxml Komponenten E-Business Messaging Service (ebms) Der ebxml- Messaging Service (ebms) dient dem Austausch von Nachrichten und Dokumenten zwischen den Geschäftspartnern unabhängig vom Kommunikationsprotokoll. Er lediglich die Verpackung der Nachricht, nicht deren Inhalt. Collaboration Protocol Agreement (CPA) CPAs bauen auf den CPPs der Geschäftspartner auf. Sie stellen im Allgemeinen eine Schnittmenge der formulierten CPPs dar. In ihnen werden vereinbarte Transaktionen für bestimmte Geschäftsprozesse festgelegt. CPAs können als Verträge zwischen zwei Geschäftspartnern verstanden werden. SBPM&EB SS 2013 Michael Fellmann 26

27 ebxml Ablauf einer Kooperation Quelle: IBM SBPM&EB SS 2013 Michael Fellmann 27

28 ebxml Anwendungsbeispiel Beschreibung einer Transaktion innerhalb einer Prozessspezifikation <BusinessTransaction name="request Purchase Order" nameid="requestpurchaseorder_bt"> <RequestingBusinessActivity name="purchase Order Request Action" 1. Aktivität im Rahmen der Transaktion nameid="purchaseorderrequestaction" isauthorizationrequired="true" isnonrepudiationrequired="true" timetoacknowledgereceipt="p0y0m0dt2h0m0s"> Sicherheitsrelevante Attribute <DocumentEnvelope businessdocument="purchase OrderRequest" Beschreibung der Dokumente businessdocumentidref="pip3a4purchaseorderrequest" /> </RequestingBusinessActivity> SBPM&EB SS 2013 Michael Fellmann 28

29 ebxml Anwendungsbeispiel Beschreibung einer Transaktion innerhalb einer Prozessspezifikation <RespondingBusinessActivity name="purchase Order Confirmation Action" nameid="purchaseorderconfirmationaction" 2. Aktivität im Rahmen der Transaktion, die als Antwort auf die Erste definiert ist. isauthorizationrequired="true" isnonrepudiationrequired="true" timetoacknowledgereceipt="p0y0m0dt2h0m0s"> <DocumentEnvelope businessdocument="purchase Order Confirmation" businessdocumentidref="pip3a4purchaseorderconfirmation" /> </RespondingBusinessActivity> </BusinessTransaction> SBPM&EB SS 2013 Michael Fellmann 29

30 Semantic Web Services SBPM&EB SS 2013 Michael Fellmann

31 Web Services Erste Annäherung Was ist ein Web Service? A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. (Quelle: W3C Web Services Architecture Group) Unter Web Services wird eine Sammlung von Standards verstanden, die zum plattform- und sprachunabhängigen Datenaustausch verwendet werden SBPM&EB SS 2013 Michael Fellmann 31

32 Web Services Kommunikationsmodell Ein Web-Service-Client (SOAP-Client) findet über ein UDDI-Repository einen geeigneten Web Service (SOAP-Server), mit dem er anschließend kommuniziert. SBPM&EB SS 2013 Michael Fellmann 32

33 Semantic Web Services Motivation und Begriff Probleme der Standard-Web-Services-Technologien: Heterogene Dienste verschiedener Anbieter Zeitaufwendige Auswahl von Web Services Schwieriger Vergleich Problematik der unterschiedlichen Datenformate Diese und weitere Probleme haben zur Entwicklung von Semantic Web Services geführt Unter Semantic Web Services (SWS) versteht man Webservices, die in geeigneter Weise semantisch beschrieben werden, sodass das Auffinden (Discovery), das Auswählen (Selection), der Aufruf (Invocation) und das Zusammenschalten zu Prozessen erleichtert wird. SBPM&EB SS 2013 Michael Fellmann 33

34 Semantic Web Services SWS als evolutionäre Entwicklung SBPM&EB SS 2013 Michael Fellmann 34

35 WSMO Überblick Grundlegendes WSMO (Web Service Modeling Ontology) Neben standardisierten Ontologien zur Service-Beschreibung sind weitere Bestandteile eine eigene Beschreibungssprache sowie Mediatorenkonzepte und eine Ausführungsumgebung. Ontologiesprache Mit der WSML (Web Services Modeling Language) wurde eine eigene Sprache entwickelt. WSML baut ebenfalls wie OWL auf der Prädikatenlogik erster Stufe auf und es existieren unterschiedliche Sprachprofilen. WSML-Beschreibungen sind (verlustbehaftet) auf OWL abbildbar. Ausführungsumgebung WSMX (Web Service Modelling execution environment) SBPM&EB SS 2013 Michael Fellmann 35

36 WSMO Werkzeugunterstützung Weitere Besonderheiten Die Mediation im Sinne einer Vermittlung zwischen heterogenen SWS spielt eine zentrale Rolle. Mit WSMO-Studio existiert ein Werkzeug, mit dem Prozesse modelliert und annotiert werden können, um diese dann in WSMX, der Ausführungsumgebung, auszuführen. WSMO-Studio gestattet die Annotation von Funktionen mit Zielen und darauf aufbauend die automatische Auswahl von Services. SBPM&EB SS 2013 Michael Fellmann 36

37 OWL-S Überblick Grundlegendes OWL-S (Web Ontology Language for Web Services) Es handelt sich um eine Mitglieder-Einreichung beim W3C. OWL-S beinhaltet keine Software, sondern soll vielmehr eine Grundlage für neuartige Anwendungen schaffen. Submission/OWL-S Ontologiesprache OWL-S als Ontologiesprache stellt eine Anwendung von OWL dar. Die Beschreibungen sollen die Entdeckung, den Aufruf, die Komposition und das Monitoring von Services zu erleichtern. Struktur der OWL-S-Ontologien Das Serviceprofil dient der Bewerbung und Auffindung von Services. Das Prozessmodell beinhaltet eine Beschreibung dessen, was ein Service bewirkt. Das sog. Grounding spezifiziert Details zur Interaktion mit dem Service. SBPM&EB SS 2013 Michael Fellmann 37

38 OWL-S Ausgewählte Klassen und Properties des Service-Profils Quelle: SBPM&EB SS 2013 Michael Fellmann 38

39 OWL-S Ausgewählte Klassen und Properties des Prozessmodells Quelle: SBPM&EB SS 2013 Michael Fellmann 39

40 SAWSDL Überblick Grundlegendes SAWSDL (Semantic Annotations for WSDL and XML Schema) Der Standard sieht keine eigenen Ontologien vor, es handelt sich daher um eine abwärtskompatible Lösung (Bottom-up-Ansatz) zur Verknüpfung von Web Services mit semantischen Beschreibungen /ws/sawsdl Zur semantischen Beschreibung wird eine Erweiterung der WSDL um zusätzliche Attribute vorgehen, mit denen WSDL-Beschreibungen annotiert werden können. WSDL wird somit semantisch aufgerüstet Erweiterungsattribute modelreference: Erlaubt die Festlegung einer Beziehung zwischen einer WSDLoder XML-Schemakomponente und einem Konzept in einem semantischen Modell. liftingschemamapping und loweringschemamapping: Diese Attribute können zu XML-Schema-Elementen hinzugefügt werden, um bidirektionale Transformationen zwischen den semantischen Daten und XML zu realisieren. SBPM&EB SS 2013 Michael Fellmann 40

41 SAWSDL Beispiel Weitere Beschreibung und ein Beispiel Die SAWSDL-Spezifikation beschreibt Möglichkeiten zur Mediation und wie traditionelle Web Services mit semantischen Technologien zusammenspielen können. SAWSDL ist kompatibel zu WSDL 1.1 und 2.0, zu XML Schema und Namespaces. Beispiel für eine erweiterte WSDL-Beschreibung: <xs:element name="orderresponse" type="confirmation" /> <xs:simpletype name="confirmation" sawsdl:modelreference=" sawsdl:liftingschemamapping=" <xs:restriction base="xs:string"> <xs:enumeration value="confirmed" /> <xs:enumeration value="pending" /> <xs:enumeration value="rejected" /> </xs:restriction> </xs:simpletype> SBPM&EB SS 2013 Michael Fellmann 41

42 Vergleich der vorgestellten Ansätze Kurzvergleich WSMO, OWL-S und SAWSDL Unterstützungsansätze Entdeckung geeigneter Services Automatischer Aufruf Automatische Komposition Sprachen WSML OWL-S Unterstützung von Mediation SBPM&EB SS 2013 Michael Fellmann 42

43 Vergleich der vorgestellten Ansätze Kurzvergleich WSMO, OWL-S und SAWSDL Vor- und Nachteile der Ansätze WSMO OWL-S Pro: Bereitstellung von Mediatoren, umfangreiche Werkzeugunterstützung. Contra: Eigene Modellierungssprache WSML. Pro: OWL-S baut auf der standardisierten OWL-Sprache auf, die sich in vielen Bereichen des Semantic Web etabliert hat. Contra: Mediation hat untergeordnete Priorität, es existieren nur wenige Werkzeuge. SAWSDL Pro: Keine eigenen Technologien, Standard basiert weitestgehend auf der Nutzung vorhandener Infrastrukturen. Contra: Es findet keine inhaltliche Standardisierung statt, d.h. die semantische Beschreibung kann individuell erfolgen. SBPM&EB SS 2013 Michael Fellmann 43

44 Enterprise Mashups SBPM&EB SS 2013 Michael Fellmann

45 EMML Überblick Grundlegendes EMML (Enterprise Mashup Markup Language) Die Sprache wird von der OMA (Open Mashup Alliance) entwickelt, in der Unternehmen wie Adobe und HP Mitglied sind. Charakteristika von EMML Die Sprache wurde als domänenspezifische Sprache entwickelt, um Enterprise Mashups portabler zu gestalten. Sie ist komplementär zu anderen Sprachen wie JavaScript, Java, Groovy, Ruby und erlaubt durch ihre XML-basiertheit die Nutzung von XQuery, XPath und XSLT. Prozesse können über Konstrukte wie if, for, foreach, while, break, parallel sowie SQL-Transaktionen gesteuert werden. Ausführungsumgebung EMML Reference Runtime Engine (frei verfügbar, SBPM&EB SS 2013 Michael Fellmann 45

46 EMML Beispiel Abruf und Selektion von Nachriten, die das Wort Business enthalten <?xml version="1.0"?> <mashup name="newsstories" xmlns=" xsi:schemalocation=" xmlns:xsi=" > <variables> <variable name="stories" type="document"/> </variable> <output name="result" type="document"/> <directinvoke endpoint=" method="get" outputvariable="stories"/> <filter inputvariable="stories" filterexpr="matches($stories/rss/channel/item/description,'business')" outputvariable="result"/> </mashup> Abruf der resultierenden XML-Daten von Anwendungen über einen URI Quelle: SBPM&EB SS 2013 Michael Fellmann 46

48 BMEcat SBPM&EB SS 2013 Michael Fellmann

49 BMEcat Einführung BMEcat beinhaltet neben cat den Namen des ihn herausgebenden Gremiums, des Bundesverband Materialwirtschaft, Einkauf und Logistik e. V. (BME) XML-basierter Standard zum Austausch von Katalogdaten. Definiert Elemente, um elektronische Kataloge zu strukturieren und zu beschreiben. Gegenstand der Beschreibung durch BMEcat sind Produkte und Dienstleistungen an sich sowie mit diesen verbundenen kaufmännischen und Marketing-Daten. Wird von großen deutschen Firmen eingesetzt (Lufthansa, Siemens, EON etc.). Besonderheiten BMEcat kann zur Produktbeschreibung externe Klassifikationen integrieren, wie etwa Es sind verschiedene Sprachen verfügbar, bisher Deutsch, Englisch und Chinesisch. SBPM&EB SS 2013 Michael Fellmann 49

50 BMEcat Struktur der Kataloge Dokumentstruktur (aktuelle Version von 2005) Logische Struktur XML-Struktur Quelle: BME (2006): BMEcat der richtige Katalogstandard für ihr E-Business. BMEcat Flyer, S. 5 SBPM&EB SS 2013 Michael Fellmann Quelle: Berlecon Research

51 Quelle: BME (2006): BMEcat der richtige Katalogstandard für ihr E-Business. BMEcat Flyer, S. 3 E-Business-Standards BMEcat Beispiel einer Produktbeschreibung SBPM&EB SS 2013 Michael Fellmann 51

52 cxml SBPM&EB SS 2013 Michael Fellmann

53 cxml Einführung Entstehung Im Jahre 1999 von der Firma Ariba entwickelt. Mit cxml.org existiert zwar eine Art Organisation, die Weiterentwicklung wird jedoch von Ariba kontrolliert. Grundidee cxml konzentriert sich auf die Optimierung der Beschaffungsprozesse von Unternehmen. Schwerpunkt ist die Ausgestaltung von Geschäftsdokumenten, die Prozesse in den Bereichen Instandhaltung und Wartung, Dienstleistungen und Handel unterstützen. cxml-transaktionen werden über Dokumente abgewickelt, bei denen es sich um einfache Textdaten mit klar definierten Formaten und Inhalten handelt. Beispiele für Dokumente sind: Kataloge, Punchouts (entfernte Katalogaufrufe), Bestellaufträge SBPM&EB SS 2013 Michael Fellmann 53

54 cxml Kommunikation Kataloge Dateien, in denen Produkt- und Dienstleistungsinhalte sowie deren Preise für Käuferunternehmen beschrieben werden. Kataloge stellen den wichtigsten Kommunikationskanal zwischen Verkäufer und Kunde dar. Quelle: cxml Handbuch SBPM&EB SS 2013 Michael Fellmann 54

55 cxml Kommunikation Punchout (entfernter Katalogaufruf) Punchouts stellen als dynamische, interaktive Kataloge auf der Homepage des Verkäufers eine alternative zum Katalog dar. Die Beschaffungsanwendung auf Seiten des Käufers kann mit einer Punchout-fähigen Webseite des Anbieters direkt Preis- und Konfigurationsoptionen abrufen und dynamisch in die eigene Webseite einbinden. Quelle: cxml Handbuch SBPM&EB SS 2013 Michael Fellmann 55

56 cxml Kommunikation Bestellungen Ein Bestellauftrag kann durch ein Punchout oder eine Auftragserfassung in einem statischen Katalog ausgelöst werden. Der Bestellauftrag wird im cxml-format an den Lieferanten gesendet und dort im Auftragsverwaltungssystem gespeichert. Quelle: cxml Handbuch SBPM&EB SS 2013 Michael Fellmann 56

57 cxml Anwendungsbeispiel: Punchoutindexkatalog Beispiel eines Anbieters: Quelle: cxml Handbuch SBPM&EB SS 2013 Michael Fellmann 57

58 explicit shared domain conceptualization semantics formal menatal model Semantisches Prozessmanagement und E-Business Lehrveranstaltung im SS 2013 Michael Fellmann Institut für Informationsmanagement und Unternehmensführung SBPM&EB SS 2013 Michael Fellmann