Building-Block-Konzept

SAP Best Practices Building-Block-Konzept
Die flexible, innovative Methode zur Wiederverwendung betriebswirtschaftlicher Inhalte
Dieses Dokument enthält Hintergrundinformationen zum Building Block Konzept, das allen SAP Best Practices Versionen
einschließlich der Baseline Packages zu Grunde liegt. Ergänzend zur übrigen Dokumentation auf dieser DVD soll es
Ihnen dazu dienen, den Building Block Ansatz als neue und flexible Methode zur Wiederverwendung von
betriebswirtschaftlichen Inhalten zu verstehen und auch selbst zu nutzen.
Die Idee
Vorkonfigurierte Lösungen sind üblicherweise das Resultat eines nicht geringen Zeit- und Kostenaufwands. Es ist ein
Gebot der Wirtschaftlichkeit, diese Investition durch zumindest teilweise Wiederverwendung der Ergebnisse in anderen
Lösungen wirksam einzusetzen.
Aufgrund sehr individueller Einstellungen wie beispielsweise der Organisationsstruktur oder Stammdaten ist dabei
einerseits die komplette Übernahme einer bestehenden Lösung schwierig. Andererseits ist es wegen Abhängigkeiten
mit den verbleibenden Einstellungen und/oder Stammdaten oft genau so problematisch, nicht benötigte Teile
(Szenarios, Prozesse) aus einer Gesamtlösung zu entfernen.
Mit dem SAP Best Practices Building Block Konzept versuchen wir, diese Problematik zu lösen. Basierend auf unserer
langjährigen Erfahrung mit vorkonfigurierten Branchen- und branchenübergreifenden Lösungen haben wir Gleichteile,
die in vielen Lösungen nahezu unverändert vorkommen, identifiziert und entsprechend der nachfolgend beschriebenen
Standardmethode in Building Blocks gekapselt.
Wo es möglich war, wurde dieser methodische Ansatz begleitet von der konsequenten Anwendung von
Standardwerkzeugen wie BC-Sets, CATT- und eCATT Prozeduren sowie LSMW Projekten, durch die eine beschleunigte
Installation sowie die Modifizierung der mitgelieferten Beispieldaten während der Installation ermöglicht werden.
Das Ergebnis sind die vorliegenden SAP Best Practices Szenarios: Jedes dieser Szenarios (die selbst Building-BlockCharakter haben) werden aus kleineren Einheiten (Building Blocks) zusammengesetzt, die flexibel auch im Rahmen
Ihrer Projekte für andere Lösungen/Szenarios wieder verwendet werden können. Jeder dieser Building Blocks enthält
dabei alle nötigen Informationen sowie Auslieferungsbestandteile, die eine unabhängige Aktivierung im jeweiligen
Kontext erlauben.
Die Methode: Bestimmung des inhaltlichen Umfanges
Betriebswirtschaftlicher Inhalt von Building Blocks
Eine herausfordernde Aufgabe bei der Erstellung von Building Blocks ist die Bestimmung seines
betriebswirtschaftlichen, technischen oder sonstigen Informationsinhaltes. Hier kann keine explizite Regel aufgestellt
werden, weil eine Vielzahl von unterschiedlichen Einflussfaktoren zu berücksichtigen sind. Diese erstrecken sich von der
Art der jeweiligen Anwendung im ERP-System, der Integration mit anderen Unternehmensbereichen und den
technischen Rahmenbedingungen bis hin zu einer sehr sorgfältigen Definition der Zielgruppe der Building Blocks und
den organisatorischen Rahmenbedingungen der Entwicklungsgruppe.
Wie bereits erwähnt, ist das Hauptkriterium zur Bestimmung des Inhaltes des SAP Best Practices Building Blocks ihre
Wiederverwendbarkeit aus dem Blickwinkel der Implementierung. Basierend auf unserer langjährigen Erfahrung haben
wir uns strikt am Sollkonzept der Lösung orientiert und die dafür notwendigen Einstellungen so in Building Blocks
gekapselt, dass diese in möglichst vielen anderen Projekten unverändert übernommen werden konnten. Ergebnisse
einer Geschäftsprozessmodellierung waren dabei sekundär.
Größe und Schachtelung von Building Blocks
Ähnlich wie für den betriebswirtschaftlichen Inhalt lässt sich auch für die Größe eines Building Blocks keine explizite
Regel angeben, da die genannten Einflussfaktoren auch hier gelten.
Da größere Building Blocks üblicherweise spezifischer und damit weniger wieder verwendbar sind als kleine, versuchen
wir, Building Blocks möglichst klein zu halten. Dies wird limitiert einerseits durch die Anforderung, einen in sich
abgeschlossenen (betriebswirtschaftlichen) Inhalt darzustellen. Andererseits muss aber anhand der individuellen
Situation entschieden werden, ob der mit der Building-Block-Erstellung verbundene zusätzliche Aufwand durch die
gesteigerte Wiederverwendung auch gerechtfertigt wird.
Größere Einheiten wie beispielsweise Szenarios oder Prozessgruppen erstellen wir durch die Schachtelung
(Referenzierung) von kleineren Building Blocks.
Es liegt auf der Hand, dass mit einer tieferen Schachtelung der Building Blocks zwar Wiederverwendbarkeit und
funktionale Transparenz zunehmen, andererseits aber auch Komplexität und Verwaltungsaufwand für die Lösung
steigen. In Abwägung dieser beiden gegenläufigen Faktoren muss jedes Entwicklungsteam den in der jeweiligen
Situation (Qualifikation, Organisation des Teams) optimalen Weg finden.
Building-Block-Bibliothek
Zur Orientierung bezüglich der inhaltlichen Definition von Building Blocks werfen Sie bitte einen Blick auf unsere
Building Block Bibliothek auf dieser DVD. Hier sind hunderte von Building Blocks mit Referenz zur Branche/zum Land
aufgeführt. Von der Bibliothek aus haben Sie direkten Zugriff auf die Building-Block-Beschreibung, die sehr kurz
gehalten die wesentlichen Funktionen zusammenfasst. Obwohl es sich auch um Building Blocks handelt, haben wir dort
aber in der Regel keine Szenarios aufgeführt. Diese bilden die zentrale Auslieferungsebene der Versionen von SAP Best
Practices Versionen und werden daher auf der jeweiligen HTML-Dokumentations-DVD zentral positioniert.
Verwenden Sie die Building-Block-Bibliothek auch als zentralen Einstiegspunkt, wenn Sie existierende Inhalte wieder
verwenden wollen, die nicht im Umfang der jeweiligen SAP Best Practices Version sind.
Die Methode: Erstellung von Building Blocks
Sobald der Inhalt eines Building Blocks wie oben beschrieben definiert wurde, erfolgt seine Erstellung nach klaren und
einfachen Regeln. Eine der wichtigsten ist, dass der Building Block prinzipiell alle Auslieferungsbestandteile hat, die
auch Bestandteil der endgültigen SAP Best Practices Version sind, diese sich aber strikt nur auf den inhaltlichen Umfang
des Building Blocks beziehen. Abhängig vom Umfang des Building Blocks machen natürlich nicht alle
Auslieferungsbestandteile Sinn und sind damit optional. Während also praktisch alle Building Blocks eine Building-Block
Beschreibung, Installationsrollen und –leitfäden sowie Konfigurationsrollen und –leitfäden haben, sind
Ablaufbeschreibungen nicht immer sinnvoll (wie z.B. für die Organisationsstruktur).
Die meisten Bestandteile des Lieferumfangs sind dabei nach Unterschiedlichen Schwerpunkten zusammenfasste Teile
einer aus einzelnen Schritten und Aktivitäten zusammengesetzten Struktur. Pro Building Block gibt es genau eine dieser
Strukturen, deren Erstellung nachfolgend beschrieben wird.
Interne Struktur eines Building Blocks
In den bisherigen Abschnitten dieses Dokuments haben Sie erfahren, dass sich ein Building Block primär auf die
Implementierung bezieht und sich seine Bestandteile nicht über den inhaltlichen Umfang eines Building Blocks hinaus
beziehen sollten. Um sicherzustellen, dass alle Building Blocks dabei einer einfachen und reproduzierbaren Struktur
folgen, haben wir drei „Phasen“ definiert, denen alle Aktivitäten rund um Installation und Verwendung eines Building
Blocks eindeutig zugeordnet werden können:
1.
Preparation (Voraussetzungen und vorbereitende Schritte)
In dieser Phase sind alle Aktivitäten, die Voraussetzung zur Installation und Nutzung des Building Blocks sind,
entsprechend ihrer chronologischen Reihenfolge aufgelistet. Hier können bereits auch existierende Building
Blocks referenziert werden, sofern sie eine Voraussetzung des Building Blocks sind (beispielsweise die
Installation der Organisationsstruktur). Die in dieser Phase aufgeführten Schritte sind also Voraussetzungen
für den Building Block, umfassen aber keine Schritte, die für die Funktionalität des Building Blocks spezifisch
sind. Ein typisches Beispiel hierfür ist die Organisationsstruktur, die zwar eine Voraussetzung für eine große
Anzahl von Building Blocks mit betriebswirtschaftlichem Inhalt ist, aber nicht für ihre Funktionalität spezifisch
ist, d. h. den grundsätzlichen Ablauf einer Chargenverwaltung oder Retourenabwicklung nicht beeinflusst. Die
Unterscheidung zwischen spezifischen und unspezifischen Schritten ist wichtig, um die Komplexität bei
Kombinationen mehrerer Building Blocks wirksam reduzieren zu können (wie später noch beschrieben wird).
2.
Installation (Installationsaktivitäten)
Für diese Phase gilt praktisch dasselbe wie für die oben beschriebene Phase Preparation, natürlich mit der
Ausnahme, dass die hier aufgeführten (Installations-)Schritte spezifisch für den Inhalt des jeweiligen Building
Blocks sind. So wäre beispielsweise die Definition einer Chargenebene ein spezifischer Installationsschritt in
einem Building Block zur Chargenverwaltung. Innerhalb jeder Phase sollte eine klare Strukturierung der
einzelnen Schritte eine möglichst hohe Transparenz erzeugen und damit auch die einzelnen Schritte zur
Konfiguration des Inhalts des Building Blocks verständlich und nachvollziehbar machen. Auch in dieser Phase
können Building Blocks referenziert werden, sofern sie in diesem Sinne einen Installationsschritt darstellen.
3.
Test & use (Test und Verwendung)
Alle Aktivitäten in dieser Phase beziehen sich auf den Test oder die produktive Verwendung des Building
Blocks, also Schritte, die in der Regel erst nach der vollständigen Installation des Building Blocks durchgeführt
werden (können). Die hier aufgeführten Aktivitäten beziehen sich also auf den inhaltlichen Prozessfluss oder
überprüfen die ordnungsgemäße Installation und Funktion des Building Blocks.
Das Ergebnis ist also eine baumartige Struktur mit den Oberknoten Preparation, Installation, Test & Use, die alle
Aktivitäten eines Building Blocks enthält in der aus Implementierungssicht einzig sinnvollen Reihenfolge. Damit ist die
Struktur einigermaßen reproduzierbar und gemeinsames Prinzip aller Building Blocks.
Zuordnung von Dokumenten, technischen Objekten und anderen Informationen zur Struktur
Die gerade beschriebene Struktur enthält also sämtliche Aktivitäten, die im Rahmen der Installation oder der Nutzung
des Building Blocks erforderlich sind. Zu jedem dieser Schritte kann nun ein zugehöriges Objekt zugeordnet werden,
zum Beispiel für eine Konfigurationsaktivität die Beschreibung als Dokument, ein BC-Set, das die beschriebenen
Einstellungen enthält, eine Installationsdokumentation die beschreibt, wie und mit welchen variablen Parametern dieses
BC-Set zu aktivieren ist, etc. Auch Objekte, die sich auf eine Anzahl von Schritten beziehen, lassen sich leicht
referenzieren, indem man sie den entsprechenden höheren Hierarchieknoten zuordnet, so zum Beispiel ein
hierarchisches BC-Set.
Das Ergebnis einer solchen Struktur mit zugeordneten Objekten ist die so genannte Development Master List, ein
Auslieferungsbestandteil, der für jeden SAP Best Practices Building Blocks obligatorisch ist.
Zusammenhang zwischen der Building Block Struktur und den (Building Block)
Auslieferungsbestandteilen
Mit der oben beschriebenen Vorgehensweise stellen wir sicher, dass jegliche auf den Building Block und seinen Inhalt
bezogene Information verfügbar ist.
Die Auslieferungsbestandteile, die Sie mit SAP Best Practices erhalten, sind nach ihren jeweiligen Kriterien
zusammengefasste Sichten dieser Development Master List.
Beispiele:
Die Installationsrolle ist die Zusammenfassung aller Aktivitäten zur Installation, und ihre Struktur ergibt sich aus der
Struktur der Development Master List.
Der Installationsleitfaden ist die sequenzielle Zusammenfassung aller Installationsdokumente, die den
Installationsaktivitäten zugeordnet sind (er beinhaltet auch die Installationsaktivitäten der Preparation Phase)
Die Struktur dieses Dokuments (Inhaltsverzeichnis) ergibt sich dabei ebenfalls aus der Struktur der Development
Master List.
Genau das gleiche gilt für Konfigurationsrollen und den Konfigurationsleitfaden als Zusammenfassungen der
Konfigurationsschritte (die den Installationsaktivitäten entsprechen, allerdings durchgehend die manuelle Erstellung
beschreiben).
Die Ablaufbeschreibungen fassen die einzelnen Aktivitäten der Phase Test & Use der Development Master List
zusammen. Dieselbe Struktur findet sich im Testkatalog (sofern existent) des Building Blocks wieder.
Diese Beispiele sind nicht vollständig. Es ist jetzt aber leicht zu verstehen, in wieweit die Auslieferungsbestandteile der
Building Blocks die im Rahmen der Development Master List entwickelte Struktur ganz oder teilweise repräsentieren.
Die Wiederverwendung von Building Blocks
Die Überlegungen, wie Building Blocks wieder verwendet werden können und wie Building Blocks zu Lösungen
kombiniert werden können, lassen sich nicht losgelöst zu den vorherigen Kapiteln dieses Dokuments anstellen. So kann
die Entwicklung einer großen Zahl kleiner Building Blocks mit jeweils unterschiedlichen Installationsvoraussetzungen
schnell zu einer nicht mehr handhabbaren Komplexität führen, wenn kein übergeordnetes Konzept existiert. Für die
SAP Best Practices benutzen wir dabei eine einfache Form des Schichtenmodells, das im Folgenden erläutert wird.
Andere Ansätze sind auch möglich, werden aber hier nicht behandelt.
Schichtenmodell
Eine Voraussetzung für das Schichtenmodell ist, dass Schritte zur Vorbereitung und zur Installation sauber getrennt
sind in unspezifische Schritte (Phase Preparation) und spezifische Schritte bezüglich der Building Block Funktionalität
(Phase Installation). Dies wurde in diesem Dokument bereits weiter oben ausführlicher beschrieben.
Building Blocks können nun nach identischen oder weitgehend identischen Voraussetzungen gruppiert werden. Diese
gemeinsamen Voraussetzungen können zu einer Schicht zusammengefasst werden (kann selbst einem Building Block
entsprechen), die bei diesen Building Blocks eine große Zahl einzelner Schritte ersetzt. Nach der Installation eines
dieser Building Blocks sind die durch diese Schicht repräsentierten Voraussetzungen bereits installiert und können dann
bei den jeweils anderen Building Blocks direkt übersprungen werden. Auf diese Art und Weise lassen sich Building
Blocks leicht kombinieren und noch auszuführende Installationsschritte können leicht identifiziert werden, ohne jeweils
einen Abgleich gegen die Gesamtheit der Schritte durchzuführen.
In den SAP Best Practices Baseline Packages findet dieser Ansatz beispielsweise durch die Verwendung des „Layers 0“
Verwendung, einer Schicht, die allen Best Practices Szenarios zugrunde liegt. Es liegt auch auf der Hand, dass aus
Gründen der leichteren und übersichtlicheren Anwendung Layer 0 auch einzelne Einstellungen enthalten kann, die für
ein bestimmtes Szenario keine zwingende Voraussetzung sind. Der damit verbundene Mehraufwand ist aber gering im
Vergleich zum Aufwand, hunderte einzelner Einstellungen jedes Mal neu abgleichen zu müssen.
Weitere, auf Layer 0 aufsetzende Schichten könnten beispielsweise gemeinsame Voraussetzungen für
Produktionsszenarios oder Service-Szenarios beinhalten. Die Anzahl der Schichten im Schichtenmodell ist grundsätzlich
nicht begrenzt, die Schichten sollten aber durch die Komplexität der Lösung gerechtfertigt und durch das
Entwicklungsteam handhabbar sein.
Schlußfolgerung
Das Building-Block-Konzept ist eine flexible und leicht verständliche Methode, um für andere Implementierungsprojekte
wieder verwendbare Teile von betriebswirtschaftlichen Inhalten, technischen Einstellungen und Informationen zu
erstellen. Der Schwerpunkt liegt dabei mehr auf der Implementierung als auf den Ergebnissen einer
Geschäftsprozessmodellierung, trotzdem oder gerade deshalb kann der mit SAP Best Practices ausgelieferte Inhalt
vollständig mit Building Blocks aufgebaut werden.
Auch wenn die Methodik recht einfach ist, hängt die Qualität der Building Blocks von der Erfahrung und Qualifikation
des Entwicklungsteams genau so ab wie von der Existenz eines Gesamtkonzeptes (Verwendungsszenarios der Building
Blocks) und der Fähigkeit, Muster zu erkennen, die mehreren Projekten unabhängig vom Inhalt gemeinsam sind.
Da das Building Block Konzept auch für das SAP Best Practices Team einen neuen Ansatz darstellt, zweifeln wir nicht
daran, dass eine große Zahl der hier ausgelieferten Building Blocks noch verbessert werden kann und mit Sicherheit in
zukünftigen Auslieferungen auch verbessert werden wird.

Download Report