Variantenmanagement in transaktions- und objektorientierten Geschäftsprozeßmodellen

Transkript

1 Variantenmanagement in transaktions- und objektorientierten Geschäftsprozeßmodellen Dipl.-Inform. Michael Schlitt Otto-Friedrich-Universität Bamberg Lehrstuhl für Wirtschaftsinformatik, insb. Industrielle Anwendungssysteme Feldkirchenstr. 21, D Bamberg Tel.: (0951) , Fax: (0951) ABSTRACT Eine wesentliche Anforderung an Modelle betrieblicher Informationssysteme besteht in der konsistenten und vollständigen Erfassung von Varianten. Die Art der darstellbaren Varianten hängt von der gewählten Modellierungsmethode ab. Unter Verwendung eines transaktions- und objektorientierten Ansatzes zur Modellierung von Geschäftsprozessen werden Protokollvarianten beschrieben, die auf dem Begriff der betrieblichen Transaktion aufbauen. Dabei werden zwei besondere Probleme des Variantenmanagements behandelt. Erstens wird die Komplexität von Geschäftsprozeßmodellen durch die explizite Erfassung von Varianten deutlich erhöht. Durch Verwendung generischer Beschreibungsmittel in Form von konfigurierbaren Protokollen kann die Komplexitätsbeherrschung effizient unterstützt werden. Zweitens muß die in Geschäftsprozeßmodellen gegebene Verteilung von Geschäftsprozessen berücksichtigt werden. Im allgemeinen werden konfigurierbare Protokolle durch mehrere Geschäftsprozesse kooperativ abgewickelt. Daraus folgt die Notwendigkeit, das Konfigurationswissen so zu verteilen, daß konkrete Protokolle konsistent und vollständig durchgeführt werden können. Der Ansatz ist auf andere Variantenarten übertragbar und kann u.a. für die Ableitung von Business Rules im Rahmen einer Anwendungssystem-Spezifikation genutzt werden. 1 Einführung Wesentliches Merkmal betrieblicher Systeme ist die Vielfalt in Struktur und Verhalten [Ling94], die sowohl Chancen als auch Risiken beinhaltet [Rath93]. Gestaltung und Lenkung von Varianten zusammengefaßt unter dem Begriff Variantenmanagement stellen hohe Anforderungen an das informationsverarbeitende Teilsystem eines betrieblichen Systems. Für das Management von Erzeugnisvarianten werden verschiedene Lösungsansätze diskutiert [Ling94, Rath93] sowie Gestaltungsvorschläge für Anwendungssysteme gemacht [Bart95, VBSJ96]. Um eine möglichst vollständige Grundlage für die Entwicklung von Anwendungssystemen zu erhalten, müssen weitere Arten

2 von Varianz berücksichtigt werden. Dies kann durch die Erfassung von Varianz in Geschäftsprozeßmodellen [Raue95], die gleichzeitig die Verteilung betrieblicher Systeme berücksichtigen [FeSi96], ermöglicht werden. 2 Geschäftsprozeßmodelle in der SOM-Methodik Der Methodik des Semantischen Objektmodells (SOM) liegt eine Unternehmensarchitektur auf drei Ebenen zugrunde: der Unternehmensplan beschreibt das betriebliche System in seiner Außensicht, Geschäftsprozeßmodelle repräsentieren die Innensicht des Systems und das Ressourcenmodell beinhaltet die Beschreibung der personellen und maschinellen Aufgabenträger zur Durchführung der Geschäftsprozesse [FeSi95, FeSi96, FeSi97]. 2.1 Objekt- und Transaktionsorientierung Geschäftsprozeßmodelle beschreiben Lösungsverfahren für einen Unternehmensplan. Dabei kommen die Paradigmen der Objekt- und Transaktionsorientierung zum Einsatz [FeSi+97]: Betriebliche Objekte kapseln Struktur und Verhalten. Sie sind über betriebliche Transaktionen zur Übertragung von Leistungs- und Nachrichtenpaketen lose gekoppelt. Betriebliche Objekte und Transaktionen sind hierarchisch zerlegbar. Die Struktursicht eines Geschäftsprozeßmodells besteht aus betrieblichen Objekten, die Transaktionen als Interaktionskanäle nutzen [FeSi97]. Dabei können Diskursweltobjekte als gestaltbare Systembestandteile und Umweltobjekte als Schnittstellen zur relevanten Systemumwelt unterschieden werden. Die Struktursicht wird durch das Interaktionsschema (IS) repräsentiert. Die Zerlegung eines Objekts in neue Objekte und verbindende Transaktionen ermöglicht die Betrachtung seiner Innensicht. Die Typen der bearbeiteten Objekte und die Art der Verrichtungen kommen einzeln oder kombiniert als Zerlegungskriterium zum Einsatz [FeMa95]. Eine Transaktion beschreibt ein Protokoll, das durch Zerlegung der ursprünglichen in neue Transaktionen aufgedeckt werden kann. Unter Verwendung des Regelprinzips können Protokolle aus Steuer- und Kontrolltransaktionen (S- und K-Transaktionen) aufgebaut sein. In diesem Fall stehen die beteiligten Objekte in einer hierarchischen Beziehung und werden als Regler und Regelstrecke interpretiert. Das Verhandlungsprinzip führt zur Zerlegung in Transaktionen für Anbahnung, Verein-

3 barung und Durchführung (A-, V- und D-Transaktionen). Die beteiligten Objekte stehen in einer nicht-hierarchischen Beziehung zueinander. In der Verhaltenssicht werden Aufgaben und Ereignisse betrieblicher Objekte sichtbar: jede Transaktion wird durch genau zwei Aufgaben der beteiligten Objekte abgewickelt. Aufgaben werden in Form von Vorgängen durchgeführt, die durch Vor- und Nachereignisse verknüpft sind. Die Verhaltenssicht wird durch das Vorgangs-Ereignis-Schema (VES) repräsentiert. 2.2 Verteilung in Geschäftsprozeßmodellen Auf der Ebene der Geschäftsprozeßmodelle wird ein betriebliches System als verteiltes System kooperierender Geschäftsprozesse abgebildet [Sinz97]. Ein Geschäftsprozeß wird durch ein betriebliches Objekt einschließlich der zugehörigen Transaktionen repräsentiert. Der Leistungsaustausch mit anderen Objekten erfolgt ausschließlich nicht-hierarchisch unter Verwendung von A-, V- und D- Transaktionen. Innerhalb eines Geschäftsprozesses ist die Anwendung des Regelprinzips möglich [FeMa95]. In Anlehnung an [Diet94] ist ein verteiltes System insbesondere durch folgende Eigenschaften charakterisiert: 1. In der Außensicht ist das System eine Black Box. Es verfolgt eine Menge von Sach- und Formalzielen. 2. In der Innensicht besteht das System aus einer Anzahl von autonomen Komponenten, die zur Verfolgung der gemeinsamen Ziele kooperieren. Keine Komponente hat die Kontrolle über das gesamte System. Diese Eigenschaften treffen für die Geschäftsprozeßmodelle der SOM-Methodik zu [FeSi96]. Ausgangspunkt der Modellierung ist ein Geschäftsprozeß (-verbund), der die im Unternehmensplan festgelegten Ziele verfolgt (1). Der Wechsel in die Innensicht erfolgt durch Zerlegung in weitere Prozesse, die nicht-hierarchisch interagieren, um die genannten Ziele zu erreichen (2). Durch die Kapselung von Struktur und Verhalten innerhalb der betrieblichen Objekte sowie durch deren lose Kopplung ist keine Gesamtkontrolle möglich (2).

4 3 Variantenmanagement am Beispiel von Protokollvarianten Geschäftsprozeßvarianten können struktur- und verhaltensorientierte Aspekte eines Geschäftsprozeßmodells betreffen [Raue95]. In der SOM-Methodik können Varianten bezüglich Leistung, Lenkung und Ablauf unterschieden werden. Lenkungsvarianten entstehen durch variante Zerlegung von betrieblichen Objekten oder Transaktionen (Protokollvarianten). Für Geschäftsprozeßvarianten sind vielfältige Gestaltungsziele zu berücksichtigen: Die Redundanz in der Variantenbeschreibung sollte minimal sein. Die kombinatorische Komplexität der Variantenvielfalt muß durch die gewählten Darstellungsmittel beherrschbar sein. Die Beschreibung muß intuitiv verständlich und gleichzeitig hinreichend formal sein, um Konsistenzprüfungen zu erleichtern. Invariante Teile sollten einfach wiederzuverwenden sein. Um die hohe Komplexität der Vielfalt [Kest95] in beherrschbarer Form in ein Geschäftsprozeßmodell einfließen zu lassen, werden generische Gestaltungsmittel vorgeschlagen. Dies ist insbesondere im Hinblick auf die Entwicklung generischer Referenzmodelle vorteilhaft [Sinz97]. 3.1 Generische Gestaltungsmittel für Varianten Der generische Ansatz wird exemplarisch für Protokollvarianten gezeigt. Transaktionen kapseln Protokolle, die von den Aufgaben der beteiligten Objekten abgewickelt werden, um die Übergabe eines Leistungs- oder Nachrichtenpakets zu realisieren. Die variante Zerlegung von Transaktionen deckt Protokollvarianten auf, wie das folgende Beispiel zeigt. Ausgangspunkt des Beispiels ist die Übergabe von Waren zwischen den betrieblichen Objekten Lieferant (Umwelt) und Beschaffung (Diskurswelt). Im initialen Interaktionsschema wird diese Beziehung durch eine D-Transaktion Warenlieferung dargestellt (vgl. Abbildung 1). Lieferant D:Warenlieferung Beschaffung Abbildung 1: Initiales Interaktionsschema Beschaffung

5 Zur Abwicklung der Warenlieferung sind die Protokolle Rahmenvertrag und Lieferplan vorgesehen. Durch eine Rahmenbestellung kann die Bereitstellung einer bestimmten Warenmenge über einen festgelegten Zeitraum vereinbart werden. Die Beschaffung kann dann Teillieferungen nach Bedarf abrufen. Alternativ können in einer Lieferplanvereinbarung Teillieferungen a priori terminiert werden. Abrufe sind dann nicht erforderlich. Im Protokoll Rahmenvertrag werden entweder Einzelrechnungen für jede Teillieferung erstellt und bezahlt oder eine Gesamtrechnung ist nach der letzten Lieferung zu begleichen. Im Protokoll Lieferplan sind nur Einzelrechnungen zulässig. Die Protokollbeschreibungen sind in der Transaktionszerlegung für die D-Transaktion Warenlieferung in Form eines konfigurierbaren Protokolls dargestellt (Abbildung 2). Die Generik dieser Form liegt in der Ableitbarkeit der konkreten Protokolle Rahmenvertrag und Lieferplan. Warenlieferung V Bestellung V Lieferplanvereinbarung V Rahmenbestellung D Warenlieferung V Warenabruf D Warenlieferung D1 Ware D2 Zahlung V Rechnung V Einzelabrechnung V Gesamtabrechnung D Zahlung Abbildung 2: Konfigurierbares Protokoll für die Warenlieferung Wenn alle Produkte einer Zerlegung mit gekennzeichnet sind, sind die betreffenden Transaktionen alternativ verwendbar. Beispielsweise kann die V-Transaktion Bestellung entweder in Form einer Lieferplanvereinbarung oder durch eine Rahmenbestellung realisiert werden. Einzelne mit markierte Transaktionen sind optionale Bausteine eines konkreten Protokolls. Im Beispiel muß die Transaktion Warenabruf in Protokollen für den Lieferplan entfallen. Neben den Beziehungstypen Alternative und Option sind weitere Abhängigkeiten zwischen varianten Bausteinen zu berücksichtigen. Für das Beispiel in Abbildung 2 gelten zusätzliche Bedingungen: 1. Warenabruf Rahmenbestellung 2. Gesamtabrechnung Rahmenbestellung

6 Die logische Äquvalenz in Bedingung 1 besagt, daß jedes abgeleitete Protokoll entweder die beiden Transaktionen Warenabruf und Rahmenbestellung enthält oder aber keine von beiden. In Bedingung 2 wird die Zulässigkeit des Abrechnungsmodus Gesamtabrechnung durch eine logische Implikation von einer Rahmenbestellung abhängig gemacht. In Zusammenhang mit dem gegenseitigen Ausschluß von Rahmenbestellung und Lieferplanvereinbarung (Alternative) wird dieser Rechnungstyp gleichzeitig für Lieferpläne verboten. Als Alternative verbleibt nur die Einzelabrechnung. In den Bedingungen werden also die Bezeichner der varianten Transaktionen als aussagenlogische Variablen verwendet und zu logischen Formeln verknüpft. Die Wahrheitswerte der Variablen (wahr/falsch) korrespondieren mit Existenzaussagen für die entsprechenden Transaktionen (existiert/existiert nicht). Damit beschreibt jede im Sinne der Bedingungen gültige Belegung aller Variablen ein korrektes und vollständiges Protokoll und kann als Operator auf einem konfigurierbaren Protokoll interpretiert werden. Die gültigen Belegungen für das konfigurierbare Protokoll aus Abbildung 2 sind in einer Konfigurationstabelle (Tabelle 1) zusammengestellt. Gültige Belegungen Variable / Transaktion Rahmenvertrag mit Rahmenvertrag mit Lieferplan mit Gesamtabrechnung Einzelabrechnung Einzelabrechnung Rahmenbestellung wahr wahr falsch Lieferplanvereinbarung falsch falsch wahr Warenabruf wahr wahr falsch Einzelabrechnung falsch wahr wahr Gesamtabrechnung wahr falsch falsch Tabelle 1: Konfigurationstabelle für das konfigurierbare Protokoll Warenlieferung 3.2 Verteilte Lenkung von Varianten Die eingangs von Kapitel 3 genannten Gestaltungsziele werden durch konfigurierbare Protokolle und Konfigurationstabellen für Protokollvarianten erreicht. Für die Lenkung dieser Varianten in einem System von Geschäftsprozessen muß zusätzlich der Aspekt der Verteilung berücksichtigt werden. In Fortführung des Beispiels (vgl. Abbildung 1) wird das Objekt Beschaffung in Bestelldisposition, Bestandsmanagement, Rechnungsprüfung und Zahlungsabwicklung zerlegt. Anschließend wird das

7 konfigurierbare Protokoll (vgl. Abbildung 2) auf die neuen Objekte verteilt: die Vereinbarungen mit dem Lieferanten werden von der Bestelldisposition durchgeführt, das Bestandsmanagement führt eventuelle Warenabrufe durch und nimmt die Ware an, die Rechnungsprüfung empfängt die Rechnungen, die durch die Zahlungsabwicklung beglichen werden (Abbildung 3). V: Lieferplanvereinbarung V: Rahmenbestellung V: Warenabruf D: Ware D: Vertragsdaten V: Bestellanforderung V: Vertragsdaten / Lieferschein D: Rechnungsbeleg Lieferant V: Einzelabrechnung V: Gesamtabrechnung S: Zahlungsanweisung K: Zahlungsbeleg D: Zahlung Bestandsmanagement Rechnungsprüfung Bestelldisposition Zahlungsabwicklung Abbildung 3: Verteilte Durchführung des konfigurierbaren Protokolls (Interaktionsschema) Die Verteilung varianter Transaktionen eines Protokolls auf mehrere Objekte schafft neuen Koordinationsbedarf. Die Objekte im Beispiel verwenden nicht-hierarchische und hierarchische Formen der Koordination, um Informationen über bereits durchgeführte Transaktionen auszutauschen. Z.B. entscheidet die Bestelldisposition autonom über die zu wählende Vertragsform (Rahmenbestellung oder Lieferplanvereinbarung) und benachrichtigt das Bestandsmanagement mittels der Transaktion Vertragsdaten. Neben der Kenntnis über bereits durchgeführte Transaktionen müssen den betrieblichen Objekten Inhalte der Konfigurationstabelle bekannt sein, um die konsistente Durchführung eines konkreten Protokolls sicherzustellen. Da die Objekte aufgrund der Verteilung nicht an allen varianten Transaktionen eines Protokolls beteiligt sind, benötigen sie jeweils nur einen geeigneten Ausschnitt der Konfigurationstabelle. Um sowohl die Informationen über bereits durchgeführte Transaktionen als auch das jeweils notwendige Konfigurationswissen verwalten zu können, werden Variantenselektoren vorgeschlagen. Ein Variantenselektor (VS) beschreibt in Form einer Variable und ihres Wertebereichs ein Unterscheidungsmerkmal für variante Transaktionen eines Protokolls. Für die Bestellung (Rahmenbestellung oder Lieferplanvereinbarung) wird beispielsweise der VS Liefertyp mit den Ausprägungen Lieferplan und Rahmen verwendet, der gleichzeitig für den Warenabruf relevant ist. Das Merkmal

8 Rechnungstyp mit den Werten Einzel und Gesamt beschreibt die Varietät der Transaktion Rechnung (Einzel- oder Gesamtabrechnung). Wenn konfigurierbare Protokolle mit VS attributiert werden, ist eine bestimmte Ausprägung eines VS (z.b. Liefertyp=Rahmen) gleichbedeutend mit der Existenz der korrespondierenden Transaktionen im Protokoll (z.b. Rahmenbestellung und Warenabruf). Geeignete VS werden betrieblichen Objekten für die Verwaltung ihrer Varianteninformationen zur Verfügung gestellt. So ist der VS Liefertyp für die Objekte Bestelldisposition, Bestandsmanagement und Rechnungsprüfung erforderlich. Letzteres benötigt zusätzlich den VS Rechnungstyp. Trans. VS Liefertyp VS Trans. Rechnungstyp Liefertyp Lieferplanvereinbarung Lieferplan Trans. VS Liefertyp Einzelabrechnung Einzel Rahmen Rahmenbestellung Warenabruf Rahmen Gesamtabrechnung Gesamt Rahmen Bestelldisposition Bestandsmanagement Rechnungsprüfung Abbildung 4 Entscheidungstabellen für die Geschäftsprozesse im Beispiel Aus den VS und aus der Konfigurationstabelle können nun Entscheidungstabellen als geeignete Projektionen auf das gesamte Konfigurationswissen abgeleitet und den jeweiligen Objekten zugewiesen werden. Im Beispiel verwaltet die Rechnungsprüfung Informationen zur Realisierungsform der Transaktion Rechnung, die von den VS Liefertyp und Rechnungstyp abhängig ist (Abbildung 4 rechts). Deren zulässige Wertekombinationen sind in den Zeilen der Entscheidungstabelle eingetragen, wobei ein eine beliebige Ausprägung kennzeichnet. In der ersten Spalte der Tabelle steht die zu einer Ausprägung oder Ausprägungsmenge gehörige Transaktion. So korrespondiert die Gesamtabrechnung mit den Ausprägungen Gesamt für Rechnungstyp und Rahmen für Liefertyp. Ein VS kann in Abhängigkeit von der Verteilung der Transaktionen auf betriebliche Objekte und von deren Koordinationsform als Entscheidungsvariable interpretiert werden. Im Beispiel entscheidet die Bestelldisposition über die Ausprägung des VS Liefertyp, während das Bestandsmanagement und die Rechnungsprüfung diesen VS als vorgegebenen Parameter in ihre Entscheidungen einbeziehen.

9 4 Zusammenfassung und Ausblick Die Gestaltungsziele für Geschäftsprozeßvarianten beziehen sich auf das Merkmal der Komplexität. Die vorgeschlagenen generischen Beschreibungsformen für Protokollvarianten dienen der Beherrschung der Variantenkomplexität und unterstützen so die Erreichung der genannten Ziele. Die Grundidee besteht in der Aufteilung der Komplexität auf eine übersichtliche Zerlegungsstruktur und auf eine Menge von Konfigurationsbedingungen. Für letztere stehen flexible Repräsentationsformen zur Verfügung, die unterschiedlichen Anforderungen genügen. So ermöglicht die Verwendung von Variantenselektoren eine einfache Verteilung des Konfigurationswissens auf Geschäftsprozesse, die ein Protokoll kooperativ abwickeln. Der am Beispiel der Protokollvarianten gezeigte generische Ansatz zur Komplexitätsbeherrschung läßt sich auf andere Variantenarten der Geschäftsprozeßmodellierung übertragen. Dies ist u.a. Gegenstand der Forschungsarbeit im Projekt WEGA (Wiederverwendbare und erweiterbare Geschäftsprozeß- und Anwendungssystem-Architekturen) an der Universität Bamberg [FeHa+96]. Weiter wird im Projekt WEGA eine umfassende Unterstützung des Variantenmanagements durch ein Modellierungswerkzeug angestrebt. Die semiformale Beschreibung von Protokollvarianten erlaubt Konsistenzprüfungen und Modellierungshilfen. Dazu zählen die automatische Ableitung von Bedingungen bei der Erweiterung eines Protokolls um neue Varianten, die Verwaltung unterschiedlicher Sichten auf konfigurierbare Protokolle und Konfigurationstabellen sowie die werkzeuggestützte Wiederverwendung häufig benötigter Entwurfsschritte für die Entwicklung konfigurierbarer Protokolle. Mögliche Nutzungsformen für solche Variantenbeschreibungen finden sich in der Anwendungssystem-Spezifikation, insbesondere zur Ableitung von Business Rules [KnHe93], sowie im Bereich der Geschäftsprozeßoptimierung als Grundlage für die Erfassung aller Alternativen eines Lösungsraums. Aufgrund ihrer Generik sind die Variantenbeschreibungen als Bausteine generischer Referenzmodelle [Sinz97] geeignet. 5 Literatur [Bart95] [Diet94] Bartuschat M.: Beitrag zur Beherrschung der Variantenvielfalt in der Serienfertigung. Essen 1995 Dietsch H.: Physische Eigenschaften Verteilter Rechensysteme: Beiwerk oder Basis? In: Wedekind H. (Hrsg.): Verteilte Systeme. Mannheim 1994, S. 3-16

10 [FeHa+96] [FeMa95] [FeSi95] [FeSi96] [FeSi97] [FeSi+97] [Kest95] [KnHe93] Ferstl O.K, Hammel C., Keller G., Pfister A., Popp K., Schlitt M., Sinz E.J., Wolf St., Zencke P.: Verbundprojekt WEGA Wiederverwendbare und erweiterbare Geschäftsprozeß- und Anwendungssystem-Architekturen. In: Statusband des BMBF Softwaretechnologie Berlin 1996, S Ferstl O.K., Mannmeusel Th.: Gestaltung industrieller Geschäftsprozesse. In Wirtschaftsinformatik 37 (1995) 5, S Ferstl O.K., Sinz E.J.: Der Ansatz des Semantischen Objektmodells (SOM) zur Modellierung von Geschäftsprozessen. In: Wirtschaftsinformatik 37 (1995) 3, S Ferstl O.K., Sinz E.J.: Multi-Layered Development of Business Process Models and Distributed Business Application Systems An Object-Oriented Approach. In: König W., Kurbel K., Mertens P., Preßmar D. (Hrsg.): Distributed Information Systems in Business. Berlin 1996, S Ferstl O.K., Sinz E.J.: Modeling of Business Systems Using the Semantic Object Model (SOM) A Methodological Framework. Accepted for: Bernus P., Mertins K., Schmidt G. (Hrsg.): Handbook on Architectures of Information Systems. International Handbook on Information Systems. Vol. I, Berlin 1997 Ferstl O.K., Sinz E.J., Hammel C., Schlitt M., Wolf St.: Bausteine komponentenbasierter Anwendungssysteme. Erscheint in: HMD Theorie und Praxis der Wirtschaftsinformatik Nr. 197 September 1997 Kestel R.: Variantenvielfalt und Logistiksysteme: Ursachen, Auswirkungen, Lösungen. Wiesbaden 1995 Knolmayer G., Herbst H.: Business Rules. In: Wirtschaftsinformatik 35 (1993) 4, S [Ling94] Lingnau V.: Variantenmanagement. Berlin 1994 [Rath93] Rathnow P.J.: Integriertes Variantenmanagement. Göttingen 1993 [Raue95] [Sinz97] Raue H.: Wiederverwendung in Geschäftsprozeßmodellen. In: Informationssystem-Architekturen, 2. Jg. Nr. 2/95 S Sinz E.J.: Architektur betrieblicher Informationssysteme. In: Rechenberg P., Pomberger G. (Hrsg.): Handbuch der Informatik. München 1997 [VBSJ96] Von Bergen A., Steiner A., John T.: Produktvarianten strategisch planen. In: SAP Info Nr.50 6/96, S.31-33