Einführung

Ziel der Modellierung ist es, betriebswirtschaftliche Abläufe zu modellieren. Das Modell hilft dabei, die Abläufe zu verstehen und sie später zu implementieren beziehungsweise eine bereits vorhandene Implementation zu erweitern.

Obwohl die Software in einem Unternehmen auf die Anforderungen dieses Unternehmens zugeschnitten ist, unterscheiden sich die grundlegenden betriebswirtschaftlichen Abläufe kaum. Es kann sogar sein, dass es verschiedene Implementierungen zu einem Ablauf innerhalb eines Unternehmens gibt; für den gleichen Geschäftsbereich, aber eben mit einem anderen Fokus. Die Daten und die grundlegenden Abläufe sind hingegen oft die gleichen.

Aus diesem Grund macht es Sinn, in der Modellierung von Anfang an eine Abstraktionsebene einzuführen, die von den Details der Implementierung abhebt. Für den gleichen betriebswirtschaftlichen Ablauf wird immer das gleiche Modellierungsobjekt verwendet (die sogenannte „Prozesskomponente“), unabhängig davon wie viele unterschiedliche Implementierungen in einer konkreten Systemlandschaft es dazu geben wird. Die Daten zum jeweiligen Ablauf werden über „Business-Objekte“ modelliert. Die folgenden Abschnitte gehen genauer darauf ein.

Abstraktion von den Daten über Business-Objekte (BOs)

SAP verwendet BOs, um die Daten einer Anwendung zu beschreiben. Der Grundgedanke ist, dass eine saubere Abgrenzung der Daten verschiedener Geschäftsbereiche zu einer guten Modellierung der Geschäftsabläufe führt. Viele Fragen der Modellierung lassen sich daher immer wieder auf die Modellierung von Business-Objekten reduzieren oder klären. Die Business-Objekte sind daher der Dreh- und Angelpunkt der bei SAP angewendeten Methodik und bilden die Grundlage für die Definition von Services.

Um BOs für mehrere Anwendungsfälle effektiv einsetzen zu können, müssen Sie so modelliert werden, dass Überschneidungen mit anderen BOs vermieden werden. Beispielsweise sollten Produktdaten nicht Teil einer Bestellung sein, sondern in einem getrennten BO modelliert werden. Auf diese Weise kann das BO für die Produktdaten auch für andere Anwendungsfälle eingesetzt werden.

Natürlich spielt der Charakter der Daten, die durch ein BO beschrieben werden, eine große Rolle für die Modellierung. Eine wichtige Charakterisierung ist die Unterscheidung von Bewegungsdaten und Stammdaten:

Neben dieser Charakterisierung von BOs gibt es auch den Ansatz, ein BO als Vorlage für eine ganze Reihe von BOs zu verwenden. Beispielsweise kann ein Geschäftspartner sowohl ein Kunde als auch ein Lieferant sein und die Daten, mit denen sowohl Kunde als auch Lieferant beschrieben werden, sind ähnlich. Wenn man sich vorher eine „BO-Vorlage“ (business object template) überlegt, aus der sich Kunde und Lieferant projizieren lassen, vermeidet man inkonsistente Definition der gleichen Daten.

Zusammenfassend betrachtet sind die Daten, auf die zugegriffen werden muss (und damit die BOs), Dreh- und Angelpunkt der Modellierung: Services greifen immer auf Daten zu, daher ist die Modellierung von Services unmittelbar mit der Modellierung von Business-Objekten verbunden. Eine gut überlegte und konsistente Identifizierung von BOs führt daher auch zu einer guten Modellierung von Services.

Abstraktion von der Implementation über Prozesskomponenten

In ARIS-Modellen arbeitet SAP mit Prozesskomponenten, um einen in sich geschlossenen Teil einer Wertschöpfungskette zu identifizieren. Die betriebswirtschaftliche Bedeutung einer Prozesskomponente ist nicht auf SAP zugeschnitten, sondern wird unternehmensübergreifend verstanden. Dies ist insbesondere für eine spätere Implementation von B2B-Prozessen unabdingbar.

Aus Modellierungssicht ist eine Prozesskomponente eine Hülle, um Daten und Services für den Zugriff auf diese Daten zu kapseln. Da Daten über Business-Objekte modelliert werden, gehören ein oder mehrere Business-Objekte zu genau einer Prozesskomponente und bestimmen so die Daten eines Geschäftsbereichs. Auf diese Art bilden Prozesskomponenten wiederverwendbare Module von (möglicherweise mehreren) größeren Anwendungen.

Eine Schwierigkeit bei der Definition von Prozesskomponenten besteht darin, auf welcher Granularität man sie einführt. Mit anderen Worten: Mit Blick auf die Daten und den zu modellierenden Ablauf muss entschieden werden, ob ein oder mehrere Prozesskomponenten einzuführen sind. Tatsächlich ist es so, dass die Modellierung der Daten durch ein oder mehrere BOs und die Modellierung der Prozesskomponenten eng zusammengehören. Wenn beispielsweise verschiedene Abteilungen auf unterschiedliche Daten eines BOs zugreifen, ist dies ein Hinweis dafür, dass das BO keinen in sich geschlossenen Geschäftsbereich umfasst, man also eigentlich zwei getrennte BOs braucht. Zugleich kann es Sinn machen, in solchen Fällen auch die zugehörige Prozesskomponente in zwei Prozesskomponenten aufzuteilen. Aber es kann auch Fälle geben in denen eine Prozesskomponente zwei BOs umfasst, etwa wenn das eine BO jeweils die komplementären Daten des anderen BOs beschreibt.

Zugriff auf die Daten einer Prozesskomponente

Ist die Granularität der Daten und die Aufteilung des zu modellierenden Ablaufs der Wertschöpfungskette in Prozesskomponenten geklärt, können Sie in der Modellierung den Zugriff auf diese Daten ableiten. Es gibt zwei Arten von Zugriffen:

Die Zugriffe werden über Service-Interfaces und Operationen modelliert, die synchron oder asynchron auf BOs zugreifen.

Die für einen Zugriff notwendigen Service-Interfaces und Operationen leiten Sie von der Art des Zugriffs ab. Es gibt einige Standardvarianten für synchrone und asynchrone Zugriffe, die die meisten Anwendungsfälle abdecken. SAP arbeitet pro Variante mit einem Interface-Pattern, mit dem sich in der Modellierung direkt Service-Interfaces, Operationen und Message-Typen ableiten und immer auf die gleiche Weise modellieren lassen: