DSAG-Leitfaden SAP HANA Praktische Tipps zur Strategie und Einführung im Rahmen einer BI-Strategie Deutschsprachige SAP-Anwendergruppe e.v.

Transkript

1 DSAG-Leitfaden SAP Praktische Tipps zur Strategie und Einführung im Rahmen einer BI-Strategie Deutschsprachige SAP-Anwendergruppe e.v. VERSION 1.0 STAND

2 2 DSAG-Leitfaden SAP Praktische Tipps zur Strategie und Einführung im Rahmen einer BI-Strategie VERSION 1.0 STAND DSAG e. V. Deutschsprachige SAP-Anwendergruppe

3 3 COPYRIGHT 2015 DSAG E.V. HINWEIS: Die vorliegende Publikation ist urheberrechtlich geschützt (Copyright). Alle Rechte liegen, soweit nicht ausdrücklich anders gekennzeichnet, bei: DEUTSCHSPRACHIGE SAP ANWENDERGRUPPE E.V. Altrottstraße 34 a Walldorf Deutschland Fon +49 (0) Fax +49 (0) I info@dsag.de Jede Verwertung außerhalb der engen Grenzen des Urheberrechts ist ohne Zustimmung der Urheber unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen/digitalen Medien. Die Autoren des vorliegenden Leitfadens sind für Verbesserungs- sowie Änderungs- und Ergänzungswünsche dankbar. Dies gilt sowohl für Vorschläge zur Vertiefung der einzelnen Kapitel als auch für die Nennung von Beispielen aus konkreten Projekterfahrungen. DSAG-LEITFADEN SAP : PRAKTISCHE TIPPS ZUR STRATEGIE UND EINFÜHRUNG IM RAHMEN EINER BI-STRATEGIE VERSION 1.0, DSAG e. V.

4 4 PRODUKTBEZEICHNUNGEN Im Interesse einer besseren Lesbarkeit des Leitfadens wird im Text in der Regel nur beim ersten Auftreten der vollständige Produktname inklusive SAP verwendet. Bei weiteren Verwendungen wird auf diesen Präfix verzichtet (z.b., statt SAP ). FEEDBACK Feedback, Kommentare, konstruktive Kritik und besonders auch weitere Szenarien zur Ergänzung des Kapitels 8 sind herzlich willkommen. Bitte im Mitgliederportal DSAGNet unter AG-Hana-Analytics im Forum veröffentlichen. Alternativ - für interessierte SAP-Anwender, die noch keine Mitglieder sind - gerne eine an info@dsag.de. AUTOREN Neben vielen anderen, die mit ihren Ideen, Kommentaren mit Beispielszenarien und nicht zuletzt mit konstruktiver Kritik zu diesem Leitfaden beigetragen haben, danken wir den unten aufgeführten Mitgliedern der AG Analytics für ihre Arbeit an diesem Leitfaden: Holger Born ITML GmbH Dr. Ralf Finger Information Works GmbH Gesa Fuchs Ferrero MSC GmbH & Co. KG Tobias Sánchez Bergmann Information Works GmbH Georg Schukat Schukat electronic Vertriebs GmbH Andreas Wilmsmeier TekLink International AG SPRECHERTEAM DER AG ANALYTICS: Gesa Fuchs Ferrero MSC GmbH & Co. KG Andreas Wilmsmeier TekLink International AG Weitere Informationen unter:

5 INHALTSVERZEICHNIS 5 1. MANAGEMENT SUMMARY / KERNAUSSAGE 7 2. AUSGANGSSITUATION (VOR ) Veränderte Anforderungen und Möglichkeiten IT-Organisation und Prozesse BI-STRATEGIE MIT IT-ORGANISATION MIT Richtlinien für Architektur und Design von Anwendungen IT-Sicherheit / Berechtigungen / Rollen Rahmenbedingungen / Abhängigkeiten / Lizenzen Kostenfaktoren Frontends Systemlandschaften ARCHITEKTURSZENARIEN Verwendungstypen als Accelerator als Plattform für SAP-Lösungen als Plattform für Anwendungsentwicklung als Virtualisierungsplattform Architekturbausteine Baustein 1: als Applikationsdatenbank und -plattform Baustein 2: als Rechenkern Baustein 3: als SAP Accelerator Baustein 4: als Data Mart zur Business Suite Baustein 5: als Data Warehouse Baustein 6: BW on Baustein 7: als integrierende Realtime-Plattform Baustein 8: als Plattform für SAP S/ Zuordnung Bausteine und Verwendungstypen Rollen & Aufgaben mit Der Weg zum Einsatz von Implementierungsstrategie SAP on Implementierungsstrategie DWH on Implementierungsstrategie Hybride -Lösung ZUSAMMENFASSUNG UND EMPFEHLUNGEN Empfehlung für jetzt Empfehlung für Perspektivisch ANHANG A WEITERFÜHRENDE INFORMATIONEN ANHANG B BEISPIELSZENARIEN Predictive Maintenance Windkraft Konditionenmanagement Plan-/Ist-Szenario auf einer nativen -Umgebung Distributionsanalyse Mehrfach-Stichtagsauswertung Prozessmining Monitoring und Realtime Reporting im Contact Center 56 DSAG-LEITFADEN SAP : PRAKTISCHE TIPPS ZUR STRATEGIE UND EINFÜHRUNG IM RAHMEN EINER BI-STRATEGIE VERSION 1.0, DSAG e. V.

6 6 ABBILDUNGSVERZEICHNIS Abbildung 1: Data Warehousing auf der -Plattform 7 Abbildung 2: BW als DWH-Anwendung im Vergleich zu 11 Abbildung 3: Prinzipskizze - Organisatorische Aufstellung eines BICC für 14 Abbildung 4: als Accelerator 20 Abbildung 5: als Plattform für SAP-Lösungen 21 Abbildung 6: als Plattform für Anwendungsentwicklung 21 Abbildung 7: als Virtualisierungsplattform 22 Abbildung 8: Übersicht der 8 -Bausteine 23 Abbildung 9: Strategie für Szenario SAP on 41 Abbildung 10: Strategie für Szenario DWH on 42 Abbildung 11: Strategie für Hybrides -Szenario 43

7 1. MANAGEMENT SUMMARY / KERNAUSSAGE 7 SAP ( ) als Datenbank- und Entwicklungsplattform ist eines der zentralen Diskussionsthemen in der SAP Community. Die neuen Möglichkeiten des Einsatzes von sind komplex und vielfältig. Ziel dieses Leitfadens ist es, die wesentlichen Entscheidungspunkte für den Einsatz von im Rahmen einer Business Intelligence & Analytics-Strategie aufzuzeigen. Der Fokus liegt dabei auf der Fragestellung, wie ein sinnvoller Einstieg in erfolgen kann und welche Faktoren dabei zu berücksichtigen sind. Mögliche Zielbilder der -Einführung und jeweils geeignete Ausbaupfade werden vorgestellt. Im Fokus steht dabei stets die SAP-Vision der integrierten Datenbankplattform als Zielbild (vgl. Abbildung 1). Abbildung 1: Data Warehousing auf der -Plattform (Quelle: SAP AG) Das Dokument behandelt zunächst typische Aspekte der Ausgangssituation vor einer -Einführung (s. Kapitel 2). Da jedoch nicht nur eine technologische BI-Komponente, sondern auch Multi-Purpose In-Memory-Datenbank sowie Anwendungs- und Softwareentwicklungsplattform ist, muss die BI-Strategie im Gesamtkontext von aktualisiert werden. Kapitel 3 sensibilisiert für dieses Thema. Kapitel 4 befasst sich dann mit der Auswirkung der -Einführung auf die IT-Organisation. In Kapitel 5 werden schließlich -Szenarien anhand von 8 Bausteinen entwickelt und deren Kombinationsmöglichkeiten dargelegt. Übergreifende Handlungsempfehlungen in Kapitel 6 runden den Leitfaden ab. DSAG-LEITFADEN SAP : PRAKTISCHE TIPPS ZUR STRATEGIE UND EINFÜHRUNG IM RAHMEN EINER BI-STRATEGIE VERSION 1.0, DSAG e. V.

8 8 Dieser Leitfaden konzentriert sich auf die dargestellten Aspekte der -Einführung im Rahmen einer SAP BI-Strategie gemäß Positionierung der DSAG-Arbeitsgruppe Analytics ( AG Analytics ). Themen rund um neue Frontends sowie technologische Grundlagenthemen (z.b. übergreifende Infrastrukturmaßnahmen, Data Center Readiness) werden in anderen DSAG-Arbeitskreisen/Arbeitsgruppen betrachtet. Angestrebt wird ausgehend von dieser ersten Ausgabe des Leitfadens systematisch - Einsatzszenarien aus der Praxis aufzunehmen. Hierfür hat die AG Analytics einen Erhebungsprozess initiiert, zu dem alle interessierten DSAG-Mitgliederunternehmen eingeladen sind. Die bereits vorhandenen Beispielszenarien, jeweils mit Zuordnung zu Verwendungstypen und Architekturbausteinen, finden sich im Anhang B Beispielszenarien. Es ist geplant, den Leitfaden laufend durch weitere, von den DSAG-Mitgliedern zur Verfügung gestellte Einsatzszenarien zu ergänzen und an neue technologische Entwicklungen und Erkenntnisse anzupassen. Sofern Sie selbst ein Beispielszenario beitragen können oder Ideen für die Weiterentwicklung des Leitfadens haben, nehmen Sie bitte über das DSAGNet oder die -Homepage Kontakt mit den Sprechern der AG Analytics auf.

9 2. AUSGANGSSITUATION (VOR ) VERÄNDERTE ANFORDERUNGEN UND MÖGLICHKEITEN In vielen Unternehmen wird die BI-Strategie verfolgt, Reporting, Analyse und Planung über ein zentrales Data Warehouse und möglichst zentrale und einheitliche BI-Tools bereitzustellen. In Unternehmen mit einer SAP BI-Strategie wird dafür häufig SAP BW ( BW ) und SAP Business Objects ( BOBJ ) eingesetzt. Der langjährig erfolgreiche Betrieb dieser SAP-Plattformen gibt den Anwenderunternehmen recht, die sich für dieses Vorgehen entschieden haben. Dennoch beobachten viele Anwenderunternehmen typische Herausforderungen, die insbesondere zu Akzeptanzproblemen in den Fachbereichen führen. Dazu gehört z.b.: Neue Anwendungen können oft nicht schnell genug bereitgestellt werden Auch kleine Änderungen führen oft zu Durchlaufzeiten von mehreren Wochen Die Kosten von Projekten und Änderungen erscheinen relativ hoch Fachbereiche fühlen sich von der IT abhängig, Self-Service-Prinzipien sind zu gering ausgeprägt. Fachbereiche extrahieren deshalb immer noch Teilmengen des Datenhaushalts aus dem Data Warehouse und bauen Schatten-ITs auf Zeitkritische Informationen und große Datenmengen können oft nicht in geeigneter Form oder ausreichend schnell bereitgestellt werden Es besteht also die Anforderung nach mehr Agilität, Flexibilität und kostengünstigeren Lösungen, unabhängig von der technischen Lösung. Mit steht nun ein Werkzeug zur Verfügung, mit dem die Anforderungen der Fachbereiche an Data Warehouse, Reporting und Analyse besser abgedeckt werden können, das gleichzeitig aber auch eine Reihe von architektonischen, organisatorischen und funktionalen Erweiterungen und Veränderungen bietet, sodass für eine geordnete Einführung die BI-Strategie überarbeitet werden sollte. Hierzu sollte auch die zukünftige Rolle des Data Warehouse überdacht und eindeutig positioniert werden. Dazu gehört z.b. die Nutzung neuer Möglichkeiten im Rahmen des operativen Reportings in Realtime direkt auf Tabellen der SAP Business Suite zur Vermeidung doppelter Datenhaltung oder die Integration anspruchsvoller analytischer Anwendungen, die bisher durch andere Lösungen abgedeckt werden und häufig sowohl technisch als auch organisatorisch getrennt betrieben werden. Weiterhin gehören dazu auch die heutigen Replikationsszenarien, insbesondere im Fall von heterogenen Systemlandschaften. Dazu bietet eine Gesamtarchitektur auf Basis von neue technische Möglichkeiten bis hin zu hybriden Szenarien aus Replikation und direkten Zugriffen auf entfernte Datenbanken. DSAG-LEITFADEN SAP : PRAKTISCHE TIPPS ZUR STRATEGIE UND EINFÜHRUNG IM RAHMEN EINER BI-STRATEGIE VERSION 1.0, DSAG e. V.

10 IT-ORGANISATION UND PROZESSE Integrierte Data-Warehouse-Infrastrukturen sind aus fachlicher und technischer Sicht komplexe Gebilde. Um diese Komplexität zu beherrschen, haben heute viele Unternehmen auf Seiten der IT zentrale Funktionen eingerichtet mit der Aufgabe, sämtliche BI-Umsetzungen gesamthaft zu steuern. Trotzdem ist eine zentrale, fachliche BI-Governance heute in vielen Organisationen noch nicht etabliert. Umso wichtiger ist die Rolle, die den technischen BI-Verantwortlichen in den Organisationen im Bereich der Konsistenzsicherung zufällt. So werden zahlreiche inhaltliche Themen (z.b. einheitliche Kennzahlendefinitionen, konsistente Grunddaten, Datenhoheiten) durch die technischen BI- Verantwortlichen an einer zentralen Stelle koordiniert. Wichtige Zielsetzung sollte es daher sein, diese zentrale fachliche und technische Koordination für BI aufrechtzuerhalten. Durch ergeben sich zahlreiche erweiterte Möglichkeiten, die unter 2.1 genannten Anforderungen zu adressieren. Wichtig ist dabei jedoch, dass diese neuen Potenziale im Rahmen einer bewussten BI-Strategie eingeführt werden. Grundaspekte ergeben sich aus dem Zielanspruch heutiger SAP BI-Infrastrukturen. Beispiele dafür sind: Bereitstellung konsistenter Grunddaten mittels durchgängiger Modellierung Klare Architekturen und Entwicklungsrichtlinien (vgl. LSA, LSA++) Durchgängiges Berechtigungswesen Hohe Betriebssicherheit, stabile Verfahren zur Inbetriebnahme neuer Anwendungen Diese Aspekte sind jedoch durch wichtige Potenziale zu komplettieren, die speziell mit besser unterstützt werden können: Kürzere Time-to-Market bei Neuentwicklungen und Änderungen Einführung von Realtime-Fähigkeiten in BI sowohl für operatives Reporting als auch für neue Use-Cases Verbesserung der Self-Service-Fähigkeiten im Fachbereich, ohne die dadurch entstehenden Datenhaushalte vollständig von der zentralen Infrastruktur zu entkoppeln Um das Erreichte in etablierten SAP BI-Strategien zu erhalten und in die Zukunft zu führen, ist es erforderlich, IT-Organisation und Prozesse parallel zur Einführung von zu überdenken. BI-Verantwortlichen wird dringend empfohlen, diese Bereiche aktiv zu gestalten.

11 3. BI-STRATEGIE MIT 11 Durch die Einführung von als Plattform bietet sich die Chance, die Positionierung von Business Intelligence und Analytics weiter zu stärken und die zugehörige BI-Strategie zu überarbeiten und zu aktualisieren. Nur so lassen sich die Potenziale einer solchen Einführung umfassend nutzen. Startpunkt für die Überarbeitung der BI-Strategie ist die genaue Definition der Aufgabe von Analytics im Unternehmen: Wer sind die Anspruchsgruppen? Was sind deren Anforderungen? Welche Prozesse sollen mit Analytics unterstützt werden? Teil der BI-Strategie ist ein langfristiger Plan, wie BI in der Organisation aufgebaut und betrieben werden soll. Dazu muss das BI-Verständnis geklärt werden. Einheiten in Unternehmen, die SAP BI betreiben, sollten sich zunächst in ihrem Selbstverständnis positionieren. Im Kontext von SAPzentrierten Ansätzen sind die folgenden Positionen denkbar: 1. BW-bezogenes BI-Verständnis BI- ist BW: aus Sicht von gehört BW on dazu. Alle anderen Einsatzfälle von werden hier nicht betrachtet. 2. SAP BI-bezogenes BI-Verständnis Alle BI-Systeme gehören zum BI-Verständnis, sofern SAP-Technologie genutzt wird. 3. Fachlich getriebenes BI-Verständnis (non-sap/mischszenario) Alle Systeme zur Datenanalyse sind BI. Das bedeutet, BI-Einsatzszenarien von gehören stets mit dazu. Aber auch alle non-sap BI-Technologien. Je nachdem, welche Positionierung eine BI-Organisation in einem Anwenderunternehmen hat, ergeben sich unterschiedliche, grundlegende Herausforderungen für die -Adoption. DSAG-LEITFADEN SAP : PRAKTISCHE TIPPS ZUR STRATEGIE UND EINFÜHRUNG IM RAHMEN EINER BI-STRATEGIE VERSION 1.0, DSAG e. V. Abbildung 2: BW als DWH-Anwendung im Vergleich zu (Quelle: Marc Hartz, Ulrich Christ, open SAP Education 2014)

12 12 Beschränkt man sich auf die Betrachtung von SAP-basierten Szenarien, sind technologisch die beiden Optionen in Abbildung 2 zu unterscheiden. Option 1 fokussiert dabei lediglich BW mit als mögliche Datenbank. Die Data-Warehouse-Logik verbleibt dabei in weiten Teilen auf der BW- Plattform. Option 2 Database unterstellt den Aufbau einer als Data Warehouse. Eine Kombination dieser beiden Varianten wird allgemein als Hybridlösung bezeichnet und erfreut sich zunehmender Beliebtheit. Die Option darüber hinaus non-sap BI-Technologien zu betrachten, ist nicht Bestandteil dieses Leitfadens. BW-bezogenes BI-Verständnis Die Einheit im Unternehmen konzentriert sich auf BW. spielt nur eine nachgelagerte Rolle. Studio wird als Entwicklungswerkzeug für BW oder als Datenbankadministrationstool genutzt. -Anwendungsszenarien werden von anderen Unternehmenseinheiten autonom vorangetrieben. Eine technische Bebauungsplanung erübrigt sich oder ist vergleichsweise einfach. Allerdings sollten neue Möglichkeiten durch BW on systematisch betrachtet werden wie z.b. die Nutzung von BW Workspaces, die Nutzung neuer BW-Objekte, wie CompositeProvider und die Auswirkung dieser Neuerungen auf die Gesamtarchitektur. Ziel ist ein zentrales BW oder ein koordinierter Verbund von BW-Systemen. SAP BI-bezogenes BI-Verständnis Die Einheit muss originär alle wichtigen -Einsatzszenarien im Kontext von BI und Analytics antizipieren. Die Einheit definiert sich über technologische Kompetenz. Eine Bebauungsplanung im Kontext verfügbarer SAP-Technologien ist zu erstellen und umfasst die systematische Betrachtung aller neuen Möglichkeiten mit, inklusive der erweiterten Möglichkeiten zur Datenanalyse. Dazu gehört z.b. die Arbeitsteilung des Reporting zwischen BW und SAP Business Suite on ( Suite on ), da sich durch den -Einsatz vielfältige Optionen zur besseren Unterstützung des operativen Reportings ergeben. Fachlich getriebenes BI-Verständnis BI wird als gesamthafte Funktion der Informationsversorgung für Entscheidungsunterstützung verstanden, Gegenstand der Diskussion sind fachliche Steuerungsthemen und wie diese über eine Vielfalt von Systemen konsistent ausgestaltet werden können. BI ist als Thema in der Unternehmensleitung verankert. Eine übergreifende Bebauungsplanung wird verantwortet, dabei sind explizit fachbereichseigene autonome BI-Hoheitsbereiche benannt, gleiches gilt für Hoheitsbereiche, die non-sap Technologien betreiben. Idealerweise ist eine übergreifende fachliche BI-Governance etabliert und wird gelebt. Bei dieser Positionierung sind zusätzlich die Funktionen von mit dem vorhandenen non-sap Technologieportfolio abzugleichen (z.b. Frontends, Datenbanken). Hier ist insbesondere zu prüfen, ob durch eine konsequente -Adoption das Portfolio z.b. durch die Nutzung des Smart Data Access homogenisiert werden kann.

13 13 Unabhängig davon, wie das BI-Verständnis jeweils definiert und gelebt wird, sind insbesondere auch Realtime-Szenarien und operatives Reporting zu betrachten. Lösungen wie Live oder S/4 bieten hier neue Möglichkeiten. Während in der Vergangenheit das operative Reporting oft außerhalb der BI-Strategie angesiedelt und umgesetzt wurde, verstärkt sich mittlerweile der Trend, eine umfassendere, das operative Reporting einbeziehende Sicht auf Business Intelligence einzunehmen. Nachdem eine BI-Einheit ihr heutiges BI-Verständnis formuliert hat, sind eine BI-Strategie und eine geeignete Roadmap vom Ist zum Soll zu entwickeln. Wenn das BI-Verständnis nicht explizit geklärt wird, ist die Positionierung implizit über Systeme und Systemeigentümerschaften gegeben. Ein spezifisches BI-Verständnis existiert dann in diesem Sinne nicht. Erfahrungsgemäß ist es auf diese Weise schwierig, konsistente Steuerungsinformationen für das Unternehmen zu produzieren. DSAG-LEITFADEN SAP : PRAKTISCHE TIPPS ZUR STRATEGIE UND EINFÜHRUNG IM RAHMEN EINER BI-STRATEGIE VERSION 1.0, DSAG e. V.

14 14 4. IT-ORGANISATION MIT IT-Organisationen sind heute typischerweise entlang ITIL (IT Infrastructure Library) ausgerichtet. Auch wenn dieser Referenzrahmen nicht immer dogmatisch etabliert ist, orientieren sich doch zahlreiche Prozesse des IT-Managements hieran. Einige wichtige Komponenten sind in Abbildung 3 beispielhaft für ein BI Competence Center (BICC) wiedergegeben. Fachbereiche Sevice Level Requirement (SLR) Sevice Level Requirement (SLR) Sevice Level Requirement (SLR) Business Intelligence Competence Center Sevice Level Agreement (SLA) Sevice Level Agreement (SLA) Sevice Level Agreement (SLA) BI Service 1 BI Service 2 BI Service 3 Service Level Management Operational Level Agreements (OLA) IT Mittel Underpinning Contracts (UC) Andere interene Einheiten Externe Einheiten Abbildung 3: Prinzipskizze - Organisatorische Aufstellung eines BICC für Grundprinzip ist dabei die Bereitstellung von IT-Leistungen als Services. Dies folgt der Idee, dass Anwender keinen Bedarf haben, die zugrundeliegenden IT-Mittel einer Leistung im Einzelnen und in ihrem Zusammenspiel zu verstehen. Vielmehr geben diese die Merkmale eines Services vor (z.b. Realtime Reporting) und formulieren diese gemeinsam mit einer liefernden Einheit (hier: BICC) in Form eines Service Level Agreements (SLA). Welche IT-Mittel sinnvollerweise einzusetzen sind, um das verabredete SLA zu halten, ist Aufgabe der liefernden Einheit (hier: BICC). Bei der Bereitstellung des Services kann die liefernde Einheit auf andere Einheiten (intern oder extern) zurückgreifen. Damit dies geordnet geschieht, ist zu empfehlen, dass die liefernde Einheit auch mit diesen anderen Einheiten geeignete Leistungsverabredungen definiert und formalisiert.

15 15 Es würde den Umfang dieses Leitfadens sprengen, alle organisatorischen Gestaltungsoptionen und Implikationen zu erörtern. Aus diesem Grund sollen hier lediglich einige wichtige Entscheidungspunkte aufgezeigt werden, die bei der individuellen Ausgestaltung der IT-Organisation zu betrachten sind: bietet zahlreiche Potenziale im Bereich BI, wie etwa Realtime Reporting oder Predictive Analysis. Wie wirken sich diese Möglichkeiten auf die Definition von Services und die Abgrenzung von anderen, ggf. überlappenden Services aus Anwendersicht aus? SAP-Betreuungsorganisationen sind häufig nach Modulen aufgestellt. Dies greift im Kontext von als Querschnittsthema zu kurz und sollte auf den Prüfstand gestellt werden. Wie können die zahlreichen Innovationen (Apps, Hana Live, S/4, neue Entwicklungsprinzipien mit Studio etc.) systematisch bewertet werden, wenn es keine zentrale IT-Einheit BI & Analytics gibt? In welcher organisatorischen Einheit ist das Know-how zu Bewertung und Einsatz von Datenbanken am besten ausgeprägt? Welche -spezifische Ausbildung ist systematisch zu planen? Soll auch die Verarbeitung unstrukturierter Daten in der Organisation einheitlich erfolgen? Wenn eine Durchdringung in der Organisation erreichen soll, ist zu prüfen, ob die Zuständigkeit bei den Datenbankexperten des Unternehmens angesiedelt werden sollte. Wie kann sichergestellt werden, dass die Innovation durch dann nicht durch die Beharrung etablierter Technologien gebremst wird? Welche Prinzipien der Anwendungsentwicklung sind im Unternehmen etabliert und wie können die neuen Möglichkeiten der Entwicklungsplattform für Anwendungen mittels sinnvoll angegangen werden? Wie angedeutet, sind diese und weitere Fragen organisationsindividuell zu diskutieren. Es erscheint aber naheliegend, dies entlang den angestrebten Architekturszenarien (vgl. Kapitel 5) und der beabsichtigten Ausbauplanung zu tun. So ist ein organisatorischer Big Bang sicher nicht sinnvoll, wenn mittelfristig lediglich BW on eingesetzt wird. Wird aber eine Solution on angestrebt, ist eine weitgehende organisatorische Umgestaltung erforderlich RICHTLINIEN FÜR ARCHITEKTUR UND DESIGN VON ANWENDUNGEN Durch die neuen technischen Möglichkeiten in gerät die bisher wohlgeordnete Welt der Arbeitsteilung der SAP-Business-Suite-Module und BW als zentraler Data-Warehouse-Plattform ins Wanken. Es ist daher zu empfehlen, organisationsindividuelle Architekturrichtlinien zu erarbeiten, die z.b. regeln, in welchen Szenarien BW weiterhin als zentrales Data Warehouse im Sinne eines Single Point of Truth (mit Datenintegration, Nachvollziehbarkeit, Historie...) genutzt werden soll und in welchen Bereichen durch geeignete Architekturbausteine die Analytics-Infrastruktur ergänzt oder möglicherweise ersetzt. DSAG-LEITFADEN SAP : PRAKTISCHE TIPPS ZUR STRATEGIE UND EINFÜHRUNG IM RAHMEN EINER BI-STRATEGIE VERSION 1.0, DSAG e. V.

16 16 Einige wichtige Bereiche, die in diesem Kontext zu überarbeiten und an den neuen Realitäten auszurichten sind: Welche Rolle spielt das zentrale Data Warehouse auf Basis von BW als integriertes Reporting, als Planungsplattform, als Stammdatenhub oder im Near Realtime Reporting? Professionelle BW-Architekturen folgen heute typischerweise den Prinzipien der Layered Scalable Architecture (LSA). Mittels LSA++ liegen bereits erweiterte Richtlinien vor. Diese sind zu bewerten und deren Umsetzung zu planen. Eng mit dem Thema LSA verbunden ist die Frage der Namenskonventionen. Durch ergeben sich sowohl innerhalb des BW als auch außerhalb neue Entwicklungsmöglichkeiten. Daraus ergibt sich ein dringender Bedarf, Namenskonventionen zu überarbeiten. Aufgrund der aktuellen Dynamik der Weiterentwicklung empfiehlt sich, diese mit jeder neuen -Version auf Aktualität zu prüfen. Wie können Berechtigungen sinnvoll ausgestaltet werden? In welchen Szenarien erfolgt ein Direktzugriff auf, in welchen ist die Datenbank unterhalb der SAP-Anwendungsebene? Wie kann ein übergreifendes Berechtigungskonzept aussehen? Große SAP-Infrastrukturen bieten eine hohe Stabilität, können den Bedarf von Endanwendern an Agilität und Self Service jedoch nicht immer bedienen. Wie können die neuen Möglichkeiten mit eingesetzt werden, um diese Anwender wieder für SAP zu begeistern? Welcher Grad an Heterogenität findet sich in der Systemlandschaft und wie werden Probleme der Datenintegration aktuell und zukünftig gelöst? 4.2. IT-SICHERHEIT / BERECHTIGUNGEN / ROLLEN hat ein eigenes Rechtemanagement, das relevant wird, sobald Reporting und Analyse nicht mehr ausschließlich über Applikationsserver wie die Suite oder BW erfolgen wie in typischen gemischten Szenarien. Ein technischer Lösungsweg zu einem über die gesamte Systemlandschaft abgestimmten Rechtemanagement kann der Einsatz von SAP Identity Management ( IdM ) sein. Ab Version 7.2 auf NetWeaver 7.4x des IdM wird das Rechtemanagement von -Systemen über einen - Connector unterstützt. Ohne IdM sind die Rechte in den 3 prinzipiell verschiedenen Typen des Rechtemanagements Business Suite, BW und manuell abzustimmen. Es ist zu empfehlen, das daraus resultierende Risiko z.b. eines unbefugten Zugriffs dokumentiert zu bewerten. Geeignete Security-Konzepte sind für personalisierte DB-User/DB-Benutzergruppen zu entwerfen. Diese werden üblicherweise in enger Zusammenarbeit von Entwicklung, Administration und Fachbereichen erstellt. In jedem Fall ist es wesentlich, ein klares, übergreifendes, fachliches Konzept für Rollen und Berechtigungen zu entwickeln, aus diesem dann konsequent entsprechende Rollen und Berechtigungen abzuleiten und diese mit den in der jeweiligen Ebene zur Verfügung stehenden technischen Möglichkeiten strukturiert umzusetzen. Hierzu können die vorgefertigten Rollen in, in der Business Suite oder auch im BW als Referenz dienen.

17 RAHMENBEDINGUNGEN / ABHÄNGIGKEITEN / LIZENZEN Die aktuellen Lizenzmodelle der SAP für die -Plattform differenzieren die Preise nach Daten-' volumen (in GB-Hauptspeicher) und nach funktionalen Kriterien. Als Einstieg in die Nutzung von kann hierbei aktuell die -Runtime-Lizenz gelten, die den Betrieb von SAP-Lösungen wie die Business Suite oder BW auf der -Plattform sowie unmittelbar damit zusammenhängende Erweiterungen ermöglicht. Für die Entwicklungen eigener Lösungen oder Anwendungen wird die -Enterprise-Lizenz benötigt, die durch zusätzliche Lizenzen für bestimmte Komponenten (wie z.b. die Predictive Analysis Library) erweitert werden kann. Für die Umsetzung einer einheitlichen BI-Strategie ist die Frage der Lizenzen bzgl. der vorgesehenen Szenarien zu klären. Fachlich sehr überzeugende Nutzungsmöglichkeiten können durch fehlende Lizenzrechte wirtschaftlich uninteressant oder undurchführbar werden. Auch wenn die Lizenzmodelle im Lauf der letzten Jahre etwas transparenter geworden sind, ist es jenseits der Runtime- oder Enterprise-Lizenz für Kunden in frühen Phasen der Projektplanung oft nicht kalkulierbar, welche -Komponenten für eine bestimmte Lösung zu lizenzieren sind. Darüber hinaus ist nach wie vor ein insgesamt sehr hohes Preisniveau für einen großen Teil der Funktionalität zu beobachten. Beides veranlasst viele Anwender dazu, am Markt nach Alternativen zu suchen oder ggf. auch zunächst auf bestimmte Lösungen zu verzichten. Die AG Analytics empfiehlt der SAP, die Transparenz der Lizenzmodelle noch einmal deutlich zu erhöhen und den Einstieg in die erweiterten Funktionalitäten der -Plattform durch dafür maßgeschneiderte Lizenzpakete zu erleichtern. DSAG-LEITFADEN SAP : PRAKTISCHE TIPPS ZUR STRATEGIE UND EINFÜHRUNG IM RAHMEN EINER BI-STRATEGIE VERSION 1.0, DSAG e. V.

18 KOSTENFAKTOREN Neben Lizenzen gibt es eine Reihe weiterer Kostenfaktoren, die im Rahmen der Planung eines Einsatzes von zu berücksichtigen sind. Da sich die technischen Möglichkeiten in Bezug auf Hardware, Software, Integration in das Data Center etc. ständig weiterentwickeln und die Marktpreise für solche Systeme sich ständig ändern, vermitteln wir an dieser Stelle nur einen Überblick über einige der wichtigsten Kostenfaktoren: Server Single Node oder Scale-Out? Multi Database, Multi Tenancy oder mehrere Server? Vorkonfigurierte Appliance oder eigene Installation auf zertifizierter Hardware?... Storage-Systeme Anbindung an vorhandenes SAN? -spezifisches SAN?... Frontends Weiterverwendung vorhandener Frontends oder Migration bzw. Neuentwicklung? Nutzung von SAP Fiori zur Eigenentwicklung?... Know-how Betriebssysteme SUSE Linux Enterprise Server, Red Hat Enterprise Linux? Betrieb von und Entwicklung in : - Auf Datenbankebene? - Auf Ebene der -Plattform? - Als Runtime-Umgebung? - Neue, erweiterte Funktionalitäten? Welcher Mix von Know-how-Aufbau und Zukauf von Know-how?...

19 FRONT ENDS Frond-End-Anwendungen sind das, was der Anwender bei der Nutzung der Systeme unmittelbar wahrnimmt, damit stehen diese unmittelbar auch im Fokus strategischer Überlegungen. Folgende Punkte beschreiben ein ideales analytisches Arbeiten aus der Benutzerperspektive: Dem Benutzer steht (genau) ein Portal für den Zugriff auf alle analytischen Funktionen zur Verfügung. Diese Vereinheitlichung wird unabhängig davon sein, ob die Daten dafür in BW, BW on, Suite, Suite on, stand-alone oder wo auch immer liegen. Für die Analysen steht eine systemlandschaftsübergreifende Datenbasis zur Verfügung. Jede Analyse könnte dadurch auf eine beliebige Zusammenstellung von verschiedensten Datenquellen über alle in 1) genannten Systeme über alle Systemgrenzen der Einzelsysteme hinweg zurückgreifen. Mit jedem beliebigen Front-End-Tool ist Zugriff auf jede Analysedatenquelle möglich SYSTEMLANDSCHAFTEN Ebenso sollten Systemlandschaften immer vom Anwender und von den Sollprozessen ausgehend entwickelt werden: Es gibt eine landschaftsweite Datendefinition: BW, Business Suite und -Datenstrukturen werden in einem gemeinsamen Pool verwaltet. Die Rollen- und Benutzerdefinition ist in der gesamten Landschaft einheitlich: Über alle Systeme hinweg werden Rollen ebenso wie der Organisationsaufbau nur einmal definiert. Zugriffsrechte können dann übergreifend oder systemspezifisch an diese Rollen und Benutzer gebunden werden. Analysen und Berichte können gegen die landschaftsweite Datendefinition entwickelt werden, ohne auf Besonderheiten der Systeme Rücksicht nehmen zu müssen, welche die Daten liefern. Das Systemmanagement ist durchgängig und stringent für alle Systeme nutzbar. Potenziell alle Systeme greifen auf eine gemeinsam genutzte -Plattform zu. DSAG-LEITFADEN SAP : PRAKTISCHE TIPPS ZUR STRATEGIE UND EINFÜHRUNG IM RAHMEN EINER BI-STRATEGIE VERSION 1.0, DSAG e. V.

20 20 5. ARCHITEKTURSZENARIEN VERWENDUNGSTYPEN Mit seiner Positionierung als Anwendungsplattform erlaubt eine Vielfalt von Anwendungen. Für die Zwecke dieses Leitfadens betrachten wir diese Anwendungen vornehmlich aus der Perspektive analytischer Anwendungen und differenzieren die folgenden grundlegenden Verwendungstypen: ALS ACCELERATOR Im Wesentlichen dient die hier als Service-Provider für die Beschleunigung komplexer Berechnungen auf der Grundlage größerer und großer Datenmengen. Die entscheidenden Vorteile dieses Verwendungstyps sind die schnellen Datenbankzugriffe und der hohe Grad an Parallelität bei der Verarbeitung der Daten. Dieser Verwendungstyp wird auch als Sidecar-Lösung bezeichnet. SAP / Non- SAP Lösung DB Abbildung 4: als Accelerator Aufwand und Risiko der Umsetzung einer Lösung dieses Verwendungstyps sind gering, Eingriffe in die eigentliche Anwendungslogik sind in der Regel begrenzt. Frühe Anwendungsfälle sind SAP- Lösungen zur Optimierung der Performance z.b. von CO-PA oder auch als Ersatz des BW Accelerator im BW- Umfeld. Darüber hinaus sind kundenspezifische Lösungen dieses Verwendungstyps denkbar ALS PLATTFORM FÜR SAP-LÖSUNGEN Bekanntlich wird als Basis für den Betrieb der bekannten SAP-Lösungen wie die Business Suite (inklusive SCM, HCM oder CRM), SAP BW und anderen verwendet. Die spezifischen Funktionen der -Plattform werden von SAP genutzt, um diese Lösungen zu optimieren (beispielsweise durch Auslagerung von Anwendungsfunktionen in die Plattform) und gezielt zu erweitern.

21 21 Business Suite Abbildung 5: als Plattform für SAP-Lösungen Jüngere Entwicklungen ermöglichen grundsätzlich auch den Betrieb mehrerer Lösungen auf einer Plattform und ermöglichen so neue, erweiterte Anwendungen innerhalb dieses Verwendungstyps ALS PLATTFORM FÜR ANWENDUNGSENTWICKLUNG Neben umfangreichen integrierten Services und deren APIs beinhaltet die -Plattform auch eine eigene Entwicklungsumgebung und erlaubt die Nutzung externer Entwicklungsumgebungen, um umfangreiche analytische oder auch operative Anwendungen zu entwickeln. Neben kundenspezifischen Entwicklungen beginnen auch Dritthersteller mit der Entwicklung von sogenannten 3rd-Party- Lösungen auf der -Plattform. Kundenanwendung BW 3rd-Party- Anwendung Abbildung 6: als Plattform für Anwendungsentwicklung DSAG-LEITFADEN SAP : PRAKTISCHE TIPPS ZUR STRATEGIE UND EINFÜHRUNG IM RAHMEN EINER BI-STRATEGIE VERSION 1.0, DSAG e. V.

22 ALS VIRTUALISIERUNGSPLATTFORM Durch Nutzung der Smart-Data-Access-Technologie lassen sich insbesondere in Kombination mit den anderen Verwendungstypen komplexe analytische Szenarien entwickeln, die auf eine Replikation der Daten teilweise und in einzelnen Fällen ggf. ganz verzichten kann. Dabei ist nicht nur ein Zugriff auf traditionelle Datenbanken, sondern z.b. auch auf Hadoop-Datenbanken möglich. Anwendung DB DB DB Hadoop Abbildung 7: als Virtualisierungsplattform 5.2. ARCHITEKTURBAUSTEINE Durch die verschiedenen möglichen Ausprägungen der grundlegenden Verwendungstypen und durch deren Kombination miteinander werden mit zahlreiche neue Architekturszenarien und Roadmaps zur Implementierung möglich. Alle Szenarien vollständig zu beschreiben, sprengt den Rahmen des hier vorliegenden Leitfadens. Aus diesem Grund werden hier exemplarisch Architekturbausteine beschrieben und in den Kontext der Verwendungstypen gestellt, aus denen sich eine konkrete Bebauung im Unternehmen zusammensetzen kann (s. Kapitel 5.4). Neben der architektonischen Sicht liegt ein weiterer Schwerpunkt der Betrachtung in diesem Abschnitt auf den durch die Einführung und den Betrieb dieser Bausteine notwendigen Rollen in der SAP BI-Organisation, deren wichtigsten Aufgaben sowie den dafür erforderlichen Tools. Hierdurch wird ein Überblick über die zu erwartenden organisatorischen Veränderungen für SAP BI-Organisationen gegeben. Folgende 8 Bausteine sollen betrachtet werden:

23 als Appl.DB Any Appl. -Appl. SAP Business Suite DB Abbildung 8: Übersicht der 8 -Bausteine Die nachfolgenden Ausführungen sind so zu verstehen, dass die benannten Rollen mit dem jeweiligen Aufgabenspektrum zusätzlich erwartet werden. Bei Kombination mehrerer Bausteine in einer Bebauungsplanung ist die Obermenge der Rollen, Aufgaben und Werkzeuge zu erwarten BAUSTEIN 1: ALS APPLIKATIONSDATENBANK UND -PLATTFORM Durch Nutzung der Smart-Data-Access-Technologie lassen sich insbesondere in Kombination mit den anderen Verwendungstypen - komplexe analytische Szenarien entwickeln, die auf eine Replikation der Daten teilweise und in einzelnen Fällen ggf. ganz verzichten kann. Dabei ist nicht nur ein Zugriff auf traditionelle Datenbanken, sondern z.b. auch auf Hadoop-Datenbanken möglich. Any Appl. Andere DBs als DWH/DB -Appl. 2 6 als Rechenkern Any Appl. DB BW SAP Business Suite DBs BW on 3 7 als Accelerator SAP Business Suite DB SAP Business Suite BW als Realtime- Plattform als ERP Data Mart SAP Business Suite Kurzbeschreibung In diesem Baustein dient die In-Memory-Engine von der Beschleunigung rechenintensiver Prozesse im Sinne einer Serviceorientierten Architektur meist ergänzend zu einer klassischen relationalen Datenbank. -Verarbeitungen werden aus der Applikation gestartet, Ergebnisse werden von wieder an die aufrufende Applikation zurückgegeben. Als Frontend dient daher die Oberfläche der rufenden Anwendung. 3 DB S/4 8 S/4 DSAG-LEITFADEN SAP : PRAKTISCHE TIPPS ZUR STRATEGIE UND EINFÜHRUNG IM RAHMEN EINER BI-STRATEGIE VERSION 1.0, DSAG e. V.

24 24 Details In diesem Baustein können bestehende Anwendungen ohne Datenbankmigration von der erhöhten Rechenleistung aktueller -Systeme profitieren. Ein weiterer typischer Anwendungsfall ist die Nutzung von als Analytics Engine. Dabei werden Daten aus vorgelagerten Datenbanken in eine analytische -Applikation (z.b. SAP Predictive Analysis) geladen und dort verarbeitet. Welche analytischen Fähigkeiten der -Datenbank genutzt werden, hängt von den jeweiligen Anforderungen ab. Durch offene Schnittstellen ist ein Zugriff auf die Datenbank, z.b. für Reportingzwecke, mit allen marktüblichen Werkzeugen möglich. Bezug zu Verwendungstypen Dieser Baustein leitet sich direkt aus dem Verwendungstyp 1 ( Accelerator ) ab. Im Fall von kundeneigenen Anwendungen kombiniert dieser Baustein diesen Verwendungstyp mit dem Verwendungstyp 3 Anwendungsentwicklung. Bezug zu Beispielszenarien Aktuell liegt noch kein Kundenszenario mit diesem Baustein vor BAUSTEIN 2: ALS RECHENKERN Any Appl. Kurzbeschreibung In diesem Baustein dient die In-Memory-Engine von der Beschleunigung rechenintensiver Prozesse im Sinne einer Service-orientierten Architektur meist ergänzend zu einer klassischen relationalen Datenbank. -Verarbeitungen werden aus der Applikation gestartet, Ergebnisse werden von wieder an die aufrufende Applikation zurückgegeben. Als Frontend dient daher die Oberfläche der rufenden Anwendung. DB Details In diesem Baustein können bestehende Anwendungen ohne Datenbankmigration von der erhöhten Rechenleistung aktueller -Systeme profitieren. Ein weiterer typischer Anwendungsfall ist die Nutzung von als Analytics Engine. Dabei werden Daten aus vorgelagerten Datenbanken in eine analytische -Applikation (z.b. SAP Predictive Analysis) geladen und dort verarbeitet. Welche analytischen Fähigkeiten der -Datenbank genutzt werden, hängt von den jeweiligen Anforderungen ab. Durch offene Schnittstellen ist ein Zugriff auf die Datenbank, z.b. für Reportingzwecke, mit allen marktüblichen Werkzeugen möglich.

25 25 Bezug zu Verwendungstypen Dieser Baustein leitet sich direkt aus dem Verwendungstyp 1 ( Accelerator ) ab. Im Fall von kundeneigenen Anwendungen kombiniert dieser Baustein diesen Verwendungstyp mit dem Verwendungstyp 3 Anwendungsentwicklung. Bezug zu Beispielszenarien Aktuell liegt noch kein Kundenszenario mit diesem Baustein vor BAUSTEIN 3: ALS SAP ACCELERATOR SAP Business Suite DB Details Basis für diese Funktionalität bildet die Fähigkeit der Business Suite, auf mehrere Datenbanken gleichzeitig zuzugreifen. Ergebnisse aus dem -Rechenkern werden dabei nicht in die Business Suite zurückgeschrieben, sondern entweder in der laufenden Anwendung weiterverarbeitet oder über das SAP GUI an den Endanwender durchgereicht. Die -Nutzung ist dabei für den Business Suite User transparent. Typischer Einsatzbereich dieses Bausteins sind Sidecar-Ansätze z.b. im Rahmen von Rapid Deployment Solutions oder auch frühe Anwendungen wie der CO-PA Accelerator. Bezug zu Verwendungstypen Dieser Baustein stellt eine Kombination der Verwendungstypen 1 ( Accelerator ) und 3 ( Anwendungsentwicklung ) für kundeneigene Anwendungen dar. Bezug zu Beispielszenarien CO-PA Accelerator (nicht in diesem Leitfaden beschrieben) Andere RDS-Szenarien Kurzbeschreibung In diesem Baustein wird genutzt, um rechenintensive Vorgänge in der SAP Business Suite besser zu unterstützen, indem diese an ausgelagert werden. Ergebnisse werden der Business Suite von bereitgestellt. Darüber hinaus kann die -Tabelle für weitere -Zugriffe zur Verfügung gestellt werden. DSAG-LEITFADEN SAP : PRAKTISCHE TIPPS ZUR STRATEGIE UND EINFÜHRUNG IM RAHMEN EINER BI-STRATEGIE VERSION 1.0, DSAG e. V.

26 BAUSTEIN 4: ALS DATA MART ZUR BUSINESS SUITE SAP Business Suite Kurzbeschreibung In diesem Baustein dient als ergänzendes Reporting auf SAP-Business-Suite-Tabellen. Dazu werden SAP- Business-Suite-Tabellen nach gespiegelt und dort relational durch ergänzende Frontends ausgewertet. DB Details Typischer Einsatzbereich für diesen Baustein ist der Sidecar für Live für operatives Reporting. Hier ist zu beachten, dass die SAP ergänzenden Content ausliefert, der die Auswertung erleichtert. Eine Variante ist die Aktualisierung von -Tabellen im Batch (bzw. über die SAP-Standardtools ETL und SLT). Diese kann z.b. mittels SAP BO Data Services ( BODS ) auch ergänzende Datentransformationen beinhalten. Auf diesem Wege sind auch Unternehmen, in denen die SAP Suite nicht auf betrieben wird, in der Lage, ein operatives Reporting auf Basis von Live umzusetzen. Bezug zu Verwendungstypen Dieser Baustein stellt eine Kombination der Verwendungstypen 1 ( Accelerator ) und 2 ( SAP- Lösung ) dar. Bezug zu Beispielszenarien Dieser Baustein stellt eine Kombination der Verwendungstypen 1 ( Accelerator ) und 2 ( SAP-Lösung ) dar.

27 BAUSTEIN 5: ALS DATA WAREHOUSE SAP Business Suite DB Andere DBs Kurzbeschreibung In diesem Baustein wird als Datenbank für ein relationales Data Warehouse eingesetzt. Dazu werden zum einen Quelldaten aus einer oder mehreren Instanzen der SAP Business Suite geladen. Meist werden darüber hinaus Daten aus non-sap Systemen ergänzt, um systemübergreifende Auswertungssichten im DWH zu erlauben. Details Die Datenintegration in das Data Warehouse erfolgt in diesem Szenario mit Hilfe von ETL- Werkzeugen wie BODS, die in der Lage sind, sowohl klassische SAP-Datenquellen als auch eine Vielzahl non-sap Datenbanken und Systemen als Datenquellen mit zu verknüpfen. Alternativ können Daten mit Hilfe der SLT-Dienste zeit- oder eventgesteuert aus der Business Suite in das Data Warehouse repliziert werden. Im Unterschied zu klassischen Beladungsprozessen mit Hilfe von ETL-Werkzeugen stellt die SLT-Lösung Informationen quasi in Echtzeit zur Verfügung und empfiehlt sich damit für alle Berichtsszenarien mit hohem Aktualitätsbedarf oder das laufende Monitoring und Auswerten von Prozessen. Darüber hinaus gibt es eine Reihe von ETL-Werkzeugen von Drittanbietern, wie z.b. Informatica, die eine ähnliche Funktionalität bieten. Mit Live stellt SAP vorkonfigurierte Daten- und Abfragestrukturen für operatives Reporting zur Verfügung. Im Mittelpunkt steht dabei ein virtuelles Datenmodell, das auf Grundlage von Standardtabellen der Business Suite mit Hilfe von Attribute Views, Calculation Views und Analytical Views die Basis für ein operationales Reporting mit schafft. Live darf dabei nicht mit dem BW Business Content (BCT) gleichgesetzt oder verglichen werden, auch wenn beiden die Idee zugrunde liegt, die in der Business Suite verwendete Geschäftslogik zu kapseln und so einen einfacheren Zugriff auf komplexe Datenmodell zu ermöglichen. Die beiden Komponenten sind technologisch grundlegend unterschiedlich und haben jeweils eigenständige Zielsetzungen: DSAG-LEITFADEN SAP : PRAKTISCHE TIPPS ZUR STRATEGIE UND EINFÜHRUNG IM RAHMEN EINER BI-STRATEGIE VERSION 1.0, DSAG e. V. Live setzt eine -Datenbank voraus, während der SAP Business Content unabhängig von der verwendeten Datenbank ist.

28 28 Live bietet komplexe, wiederverwendbare Datenbankviews, die direkt für (meist operative, real-time) Analysen und Berichte oder auch für Anwendungsentwicklung verwendet werden können. Ein Nebeneffekt ist, dass diese Datenbankviews auch für die Datenextraktion durch ETL-Tools oder für generische Extraktion genutzt werden können. Der Business Content dient dagegen dazu, Daten für die Verwendung im BW zu extrahieren, wo sie dann für das Reporting aufbereitet werden und in der Regel nicht mehr real-time zur Verfügung stehen. Bezug zu Verwendungstypen Dieser Baustein ist eine Kombination der Verwendungstypen 2 ( SAP-Lösungen ) und 3 ( Anwendungsentwicklung ) mit der Option, auch den Verwendungstyp 4 ( Virtualisierung ) zu nutzen. Bezug zu Beispielszenarien Predictive Maintenance (8.1) Plan-/Ist-Szenario (8.3) Prozessmining (8.6) Monitoring und Realtime-Reporting im Contact Center (8.7) BAUSTEIN 6: BW ON BW SAP Business Suite DBs Kurzbeschreibung In diesem Baustein wird als primäre Datenbank von BW eingesetzt. Wichtige Verarbeitungsprozesse werden schneller, Modellierungsebenen können eingespart werden. Die Arbeit mit dem BW erfolgt weiterhin in der RSA1 bzw. mit der neuen Eclipse-Umgebung, wenn neue Objekte oder Funktionen ab BW 7.4 genutzt werden sollen. Aus Benutzersicht ist der Datenbankwechsel transparent. Das BW-Rechtekonzept bleibt erhalten und ist weiterführend. -Tabellen können auch von anderen -Anwendungen genutzt werden (z.b. Reporting-Tools). Details Für die Einführung von BW on bietet SAP Leitfäden und Best-Practice-Vorgehen für die Migration an (vgl. hierzu die Aktivitäten in der DSAG AG BW Migration). In technischer Hinsicht wird damit ein Upgrade der BW-Plattform bei gleichzeitiger Datenbankmigration durchgeführt. Das Verfahren inkl. DMO (Database Migration Option) wird vom SAP Standardwerkzeug Software Update Manager (SUM) unterstützt. Dabei wird die bisher in BW implementierte Business-Logik mit allen Datenflüssen, Transformationsregeln und Info-Provider-Strukturen vollständig erhalten und steht unmittelbar nach dem Upgrade in gewohnter Form für die bestehenden Berichtsapplikationen zur Verfügung. Vorgehen und Aufwand für die -Einführung sind in diesem Szenario in etwa mit dem Upgrade der Plattform vergleichbar.

29 29 Grundlegende Vorteile der In-Memory-Technologie stehen schon unmittelbar nach dem Upgrade zur Verfügung. Neben einer erhöhten Performance der Datenbankplattform als solcher gehört dazu auch die Reduktion des Speicherplatzbedarfs. Die spaltenbasierte Datenorganisation der - Datenbank ermöglicht erfahrungsgemäß ein mindestens um den Faktor 4 reduziertes Datenvolumen, ohne hierbei zusätzliche Komprimierungsverfahren einzusetzen. Dies ist schon beim Sizing der Hardware BW on zu berücksichtigen. Darüber hinaus beschleunigen sich alle Datenladeund Aktivierungsprozesse. Die Algorithmen für die Aktivierung von DSOs werden nicht mehr auf Ebene des Applikationsservers, sondern unmittelbar in der Datenbank ausgeführt. Neben der Option, das bestehende BW einfach weitgehend unverändert, aber mit höherer Performance auf Basis von zu betreiben, bieten die neueren BW-Releases insbesondere eben in Verbindung mit der -Datenbank eine Reihe neuer Modellierungsoptionen, die den Betrieb und die Entwicklung im BW verschlanken helfen. Empfehlenswert ist mindestens die Umstellung der bestehenden DSO und InfoCubes auf das neue -Format durch Setzen des entsprechenden Flags und Aktivierung des Objekts. Für InfoCubes entfallen dadurch die Dimensionstabellen mit Dimensions-IDs, da SIDs der Stammdaten unmittelbar in die Faktentabellen geschrieben werden. Insbesondere die neuen Advanced DSOs (ADSO), die im Kern die Funktionen von DSO und InfoCube in einem Objekt verbinden, vereinfachen den Modellierungsprozess und unterstützen eine Reduktion des Entwicklungsaufwands, der Datenredundanz und letztlich der Betriebskosten, indem persistente Datenschichten eingespart werden können. Eine bedeutende Rolle kommt dabei dem neuen Composite InfoProvider zu. Dieser bietet die Möglichkeit, andere InfoProvider analog zu den aus SQL bekannten Inner oder Outer Joins sowie Unions zu verknüpfen, und trägt dabei selbst keine Daten. Im Unterschied zu bisherigen InfoProvidern wie dem InfoSet oder dem MultiProvider werden die Operationen auf Datenbankebene ausgeführt. Aufgrund seiner Eigenschaften und seiner höheren Flexibilität bietet sich der Composite InfoProvider daher zur Ablösung der bisherigen virtuellen InfoProvider an. Die Möglichkeit feldbasierter Modellierung in den ADSO und in Open DSO Views erlaubt eine schnelle Entwicklung von Prototypen oder Ad-hoc-Anwendungen. In Kombination mit der Option, Datenbankviews zu BW-Objekten zu generieren und darauf über Standardschnittstellen zuzugreifen, wird das BW noch einmal offener. Zu guter Letzt sei hier noch das Stichwort Data Temperature -Konzept erwähnt. Angesichts der Lizenz- und Hardwarekosten für große -Installationen wird die Reduktion des Volumens heißer Daten und die effiziente Verwaltung von Daten auf mehreren Zugriffsebenen (Archivierung, NLS, ILM) zu einem immer wichtigeren Thema. Es wird unterschieden zwischen heißen Daten, die permanent für Analysezwecke zur Verfügung stehen müssen. Warme Daten unterliegen regelmäßigen Änderungen, sind aber weniger für direkte OLAP-Auswertungen relevant, sondern werden eher in vorgelagerten Datenflüssen verarbeitet. Kalte Daten werden nur noch in Ausnahmefällen verändert und eher sporadisch für Auswertungen verwendet. BW bietet ab Release 7.4 Funktionen wie Dynamic Tiering und Near-Line Storage auf Basis von SAP IQ. DSAG-LEITFADEN SAP : PRAKTISCHE TIPPS ZUR STRATEGIE UND EINFÜHRUNG IM RAHMEN EINER BI-STRATEGIE VERSION 1.0, DSAG e. V. Anmerkung: Weitere Funktionalität ergibt sich laufend aus neuen Systemversionen und Support Packages. Dieser Leitfaden erhebt nicht den Anspruch, diese Möglichkeiten lückenlos vorzustellen.

30 30 Das Management des BW-Datenbankschemas in der -Datenbank wird vollständig vom BW- Applikationsserver übernommen, sodass sich die Rolle des -Datenbankadministrators vor allem auf Basisbetrieb, Monitoring und Backup-Prozesse beschränkt. Dennoch sind Mischszenarien in der Nutzung der -Datenbank denkbar, in denen Datenstrukturen aus nicht BW-verwalteten Datenbankschemata mit Hilfe von Composite InfoProvidern mit BW InfoProvidern verknüpft werden. Ggfs. ist die -Lizenz auf die Anwendbarkeit dieses Bausteins zu prüfen. In diesem Szenario ist es relativ einfach möglich, operatives Reporting mit strategischem Reporting im BW zu kombinieren. Die Daten der SAP Business Suite können über den SAP Landscape Transformator (SLT) in Realtime in die DB des BW repliziert werden, sodass im Studio in eigenen Schemata auf diesen replizierten Daten eigene Information Views (Calculation View, Analytical View) auch in Verbindung mit BW InfoProvidern aus dem BW-Schema ausgewertet werden können. Da die Nutzung der OLAP Engine entfällt, sind derartige Auswertungen vergleichsweise schneller als mit BEx Queries. Planungsanwendungen können mittels Planning Application Kit (PAK) optimiert werden. Bezug zu Verwendungstypen Dieser Baustein ist eine Umsetzung des Verwendungstyps 2 ( SAP-Lösungen ). Bezug zu Beispielszenarien Konditionenmanagement (8.2) Distributionsanalyse (8.4) Mehrfach-Stichtagsanalyse (8.5) Prozessmining (8.6) BAUSTEIN 7: ALS INTEGRIERENDE REALTIME-PLATTFORM SAP Business Suite BW Kurzbeschreibung In diesem Baustein wird als primäre Datenbank für die gesamte SAP-Landschaft genutzt. Verschiedene technische Szenarien wie MCOD ( Multiple Components in One Database ), MCOS ( Multiple Components in One System ), MDC ( Multitenant Database Containers ) oder auch einfach der Bündelung aller nötigen Funktionalität in einer Business- Suite-Instanz sind denkbar im letzten Fall stellt das BW nur noch eine semantische Modellierungsebene dar. - Tabellen können bei diesem Baustein auch von anderen -Anwendungen genutzt werden (z.b. Reporting-Tools).