Einführung in Business Intelligence mit SAP NetWeaver 7.0

Einführung in Business Intelligence mit SAP NetWeaver 7.0

Jorge Marx Gómez · Claus Rautenstrauch Peter Cissek

Einführung in Business Intelligence mit SAP NetWeaver 7.0

123

Prof. Dr.-Ing. habil. Jorge Marx Gómez Peter Cissek Carl von Ossietzky Universität Oldenburg Fakultät II – Department für Informatik Abt. Wirtschaftsinformatik I Very Large Business Applications Ammerländer Heerstraße 114–118 26129 Oldenburg

Prof. Dr. rer. pol. habil. Claus Rautenstrauch Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut für Technische und Betriebliche Informationsssteme Arbeitsgruppe Wirtschaftsinformatik Universitätsplatz 2 39106 Magdeburg [email protected]

[email protected] [email protected]

ISBN 978-3-540-79536-0

e-ISBN 978-3-540-79537-7

DOI 10.1007/978-3-540-79537-7 Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. c 2009 Springer-Verlag Berlin Heidelberg  Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Herstellung: le-tex publishing services oHG, Leipzig Umschlaggestaltung: WMXDesign GmbH, Heidelberg Gedruckt auf säurefreiem Papier 987654321 springer.de

Vorwort Mit dem Abschluss der technologischen Transformation des unternehmensweiten Berichtswesens zum Data Warehouse basierten Reporting, strebt die Entwicklung nach der vollständigen Umsetzung von Business Intelligence im Unternehmen. Dabei sind die Herausforderungen in technologischer und fachlicher Hinsicht stark gestiegen und lassen die früheren Anstrengungen bei der Einführung eines Data Warehouse verblassen. Business Intelligence (BI) ist kein Schlagwort, es ist eine Strategie, welche die Informationssystemarchitektur der Unternehmen und deren Geschäftsprozesse auf Jahre nachhaltig gestaltet. Die Bedeutung der BI ist auch von der SAP AG erkannt worden. Als führender Anbieter von ERP-Software setzt sie im Rahmen ihrer SAP NetWeaver Integrationsplattform in der Version 7.0 eine integrierte Lösung zur Unterstützung der Business Intelligence ein. Studierende, Lehrende und Praktiker haben mit diesem Buch die Möglichkeit, hinter die Kulissen der Business Intelligence zu schauen. Ihnen werden sicheres Grundwissen und erste praktische Erfahrungen mit SAP NetWeaver 7.0 zuteil. Vom konzentrierten Wissen über die Grundlagen der BI und den praxisnahen, verständlichen Fallstudien mit SAP NetWeaver 7.0 profitiert der Leser beim Berufseinstieg und bei der individuellen Weiterbildung. Für die Lehre an Universitäten, Fachhochschulen, Berufsschulen und Berufsakademien ist die flächendeckende Versorgung mit SAP NetWeaver 7.0 durch die SAP Hochschulkompetenzzentren (SAP UCC) an der Otto-von-Guericke-Universität Magdeburg und der TU München sichergestellt. Die Fallstudien sind mit freundlicher Unterstützung der bi2b GmbH & Co. KG entstanden, einem kompetenten Beratungshaus mit langjähriger BI-Erfahrung. Unser Dank gilt ihm und seinen hochqualifizierten Mitarbeitern, ohne die das Vorhaben nicht erfolgreich gewesen wäre. Des Weiteren sind wir auch den Partnern auf der Seite des Verlags zu Dank verpflichtet, insbesondere Herrn Dr. Werner A. Mueller, Frau Alice Blank und Frau Ruth Milewski, die das Projekt mit Professionalität begleitet haben. Für die fleißige Korrekturarbeit möchten wir uns bei Jantje Halberstadt, Kerstin Lange, Moritz Grohmann, Andreas Solsbach und Daniel Süpke bedanken. Nicht zuletzt danken wir auch den Familien und Partnern, die den Autoren jede nur mögliche Unterstützung haben zukommen lassen. Ein Teil der Projektarbeit wurde von zwei Diplomanden getragen, deren Arbeiten die Grundlage für dieses Werk bilden. Dabei sind die Arbeiten „Konzeption und Entwicklung einer Fallstudie für das Potential einer Portaltechnologie am Beispiel von SAP NetWeaver Portal“ von Nils Giesen und „Entwicklung und Umsetzung eines Konzepts zur Einführung in die Module SAP BI Data Warehousing und SAP BI Integrierte Planung im Rahmen von SAP NetWeaver 7.0“ von Dirk Peters entstanden. Beiden Diplomanden sind wir ebenfalls zu sehr großem Dank verpflichtet.

VI

Vorwort

Der Kontakt zu unseren Lesern ist uns sehr wichtig. Für Anregungen, Kritik oder weitere Anmerkungen zu diesem Buch, die uns über die angegeben Kontaktmöglichkeiten erreichen, sind wir sehr dankbar.

Die Autoren

Oldenburg, im Oktober 2008

Inhalt Vorwort ................................................................................................................. V Verzeichnis der Abkürzungen und Akronyme ................................................ XI Rechtliche Bestimmungen............................................................................... XIII 1

Einleitung ..................................................................................................... 1 1.1 Ziele und Aufbau des Buches .................................................................. 1 1.2 Vorbereitung der Fallstudien ................................................................... 2 1.3 Einführung in die Benutzung von SAP Software .................................... 2

2

Business Intelligence ................................................................................... 7 2.1 Grundlagen der Business Intelligence ..................................................... 7 2.1.1 Nachrichtendienst des Unternehmens .............................................. 8 2.1.2 Vom MIS zum DIS ........................................................................ 14 2.1.3 Technologien der Business Intelligence ........................................ 19 2.1.4 BI-Anwender ................................................................................. 24 2.2 Informationsmanagement ...................................................................... 28 2.2.1 Konzeption und Steuerung der IT-Systemlandschaft .................... 30 2.2.2 Analyse der Informationsinfrastruktur........................................... 31 2.2.3 Planung der Informationsinfrastruktur........................................... 35 2.2.4 Projektmanagement ....................................................................... 37 2.3 Business Intelligence mit SAP NetWeaver 7.0...................................... 40 2.3.1 SAP NetWeaver Information Integration - BI ............................... 44 2.3.2 SAP NetWeaver People Integration - Portal.................................. 50

3

Data Warehouse-Architektur ................................................................... 59 3.1 Grundlagen zur Data Warehouse-Architektur ....................................... 59 3.1.1 Einführung ..................................................................................... 59 3.1.2 Einordnung und Abgrenzung ......................................................... 62 3.1.3 Architektur ..................................................................................... 67 3.1.4 Daten, Datenquellen und Datenqualität ......................................... 69 3.1.5 Datenmodell .................................................................................. 76 3.1.6 Phasen des ETL-Prozesses ............................................................ 89 3.2 SAP BI Data Warehousing .................................................................... 93 3.2.1 Data Warehousing Workbench ...................................................... 93 3.2.2 Datenflusskonzept ......................................................................... 96 3.2.3 Datenmodellierung ........................................................................ 98 3.2.4 Datenbereitstellung ...................................................................... 114 3.2.5 Transformation ............................................................................ 116

VIII

Inhalt

3.2.6 Datenweiterverarbeitung ............................................................. 117 3.2.7 Datenverteilung ........................................................................... 118 3.2.8 Data Warehouse Management ..................................................... 121 3.2.9 Real-Time Data Acquisition ........................................................ 127 3.3 SAP BW Reporting ............................................................................. 128 3.3.1 BEx Query Designer.................................................................... 129 3.3.2 BEx Web Application Designer .................................................. 135 3.3.3 BEx Report Designer ................................................................... 138 3.3.4 BEx Analyzer .............................................................................. 140 3.4 Fallstudie A: SAP BI Data Warehousing ............................................ 143 3.4.1 Teil I - Datenmodellierung .......................................................... 145 3.4.2 Teil II - Datenbeschaffung........................................................... 172 3.4.3 Teil III - Reporting ...................................................................... 211 4

Unternehmensplanung ............................................................................ 241 4.1 Grundlagen der Unternehmensplanung ............................................... 241 4.1.1 Unternehmensplanung als Querschnittsfunktion ......................... 242 4.2 Planungsmethoden............................................................................... 269 4.2.1 Erfahrungskurve .......................................................................... 269 4.2.2 Marktwachstum-Marktanteil-Matrix ........................................... 271 4.2.3 Branchenattraktivität-Wettbewerbsstärke-Matrix ....................... 276 4.2.4 Lebenszyklusanalyse ................................................................... 279 4.2.5 Balanced-Score-Card ................................................................... 282 4.3 SAP NetWeaver BI-Integrierte Planung.............................................. 285 4.3.1 Die Planungsumgebung ............................................................... 286 4.3.2 Modellieren von Planungsszenarien ............................................ 289 4.3.3 Erstellen von Planungsanwendungen .......................................... 298 4.3.4 Sperrkonzept und Sperrverwaltung ............................................. 303 4.4 Fallstudie B: BI-Integrierte Planung.................................................... 304 4.4.1 Teil I - Datenmodellierung .......................................................... 306 4.4.2 Teil II - Planungsmodellierung .................................................... 317 4.4.3 Teil III - Erstellen von Planungsanwendungen............................ 341

5

Portaltechnologie ..................................................................................... 377 5.1 Grundlagen der Portaltechnologie ....................................................... 377 5.1.1 Einführung ................................................................................... 377 5.1.2 Portale in der Informationstechnologie ....................................... 378 5.1.3 Unterscheidung Webportal und Unternehmensportal .................. 384 5.1.4 Eine Referenzarchitektur für ein Portal ....................................... 385 5.1.5 Zentrale Portalkonzepte und Funktionen ..................................... 388 5.1.6 Nicht funktionale Anforderungen an ein Portal ........................... 393 5.1.7 Überblick über den Portalsoftwaremarkt ..................................... 394 5.1.8 Verwandte Konzepte der Portaltechnologie ................................ 397 5.2 SAP NetWeaver Portal ........................................................................ 398

Inhalt

IX

5.2.1 Einführung SAP NetWeaver Portal ............................................. 399 5.2.2 Allgemeine Portalfunktionen ....................................................... 403 5.2.3 Knowledge Management ............................................................. 411 5.2.4 Kollaboration ............................................................................... 413 5.2.5 Entwicklung mit dem SAP NetWeaver Portal ............................. 417 5.3 Fallstudie C: SAP NetWeaver Portal ................................................... 424 5.3.1 Teil I - Login und Bedienung SAP NetWeaver Portal................. 426 5.3.2 Teil II - Arbeiten mit dem Portal Content Studio ........................ 444 5.3.3 Teil III - Analyse und Reporting im Portal .................................. 478 Literaturverzeichnis .......................................................................................... 491 Index ................................................................................................................... 497

Verzeichnis der Abkürzungen und Akronyme ABAP ADAPT API ARIS B2C BAPI BEx BI BPM BPS BSP BW CRM CSS CSV DB DSS DWB DWH EDW EIS ERP ETL GML DOM GUI HOLAP HR HTTP IATA IM J2EE JAAS JDBC KMU KVP LDAP MI6 MIS MDX MOLAP

Advanced Business Application Programming Application Design for Analytical Processing Technologies Application Programming Interface Architektur integrierter Informationssysteme Business-to-Consumer Business Application Programming Interface Business Explorer Business Intelligence Business Performance Management Business Planning and Simulation Business Server Pages Business Information Warehouse Customer Relationship Management Cascading Style Sheets Character Separated Values Datenbank Decision-Support-System Data Warehousing Workbench Data Warehouse Enterprise Data Warehouse Executive Information System Enterprise Resource Planning Extraktion Transformation Laden Generic Modeling Language Document Object Model Graphical User Interface Hybrid Online Analytical Processing Human Resources Hypertext Transfer Protocol International Air Transport Association Informationsmanagement Java 2 Enterprise Edition Java Authentication and Authorization Service Java Database Connectivity Kleine und mittlere Unternehmen Kontinuierlicher Verbesserungsprozess Lightweight Directory Access Protocol Military Intelligence, Section 6 Management Information System Multidimensional Expressions Multidimensional Online Analytical Processing

XII

Verzeichnis der Abkürzungen und Akronyme

NASA NTLM ODBO OLAP OLE OLTP PDA PSA RFC RFID RIA RSS SDC SEM SGE SIS SOAP SQL SSL SVG SWF T-ADAPT TREX UML UWL VBA VoIP VPN WAM XGL XHTML XML XMLA

National Aeronautics and Space Administration NT LAN Manager OLE Database for OLAP Online Analytical Processing Object Linking and Embedding Online Transaction Processing Personal Digital Assistant Persistent Staging Area Remote Function Call Radio Frequency Identification Rich Internet Application Really Simple Syndication System Development Corporation Strategic Enterprise Management Strategische Geschäftseinheit Secret Intelligence Service Service Oriented Application Programming Structured Query Language Secure Sockets Layer Scalable Vector Graphics Shockwave Flash Temporal Application Design for Analytical Processing Technologies SAP NetWeaver Search and Classification Uniform Modeling Language Universal Worklist Visual Basic for Applications Voice-over-Internet Protocol Virtual Private Network Web Access Management XGraph Language Extensible Hypertext Markup Language Extensible Markup Language XML for Analysis

Rechtliche Bestimmungen ADAPT® ist eine eingetragene Marke der Symmetry Corporation. Adobe Flex ist eine eingetragene Marke der Adobe Inc. AOL ist eine eingetragene Marke der AOL, Inc. BEA Systems und WebLogic Portal sind eingetragene Marken der BEA Systems. BroadVision ist eine eingetragene Marke der BroadVision, Inc. (IRD) Business Client ist eine eingetragene Marke der systema Informationstechnik GmbH. CA ist eine eingetragene Marke der Computer Associates Inc. Crystal Reports ist eine eingetragene Marke der Business Objects SA. Day Software ist eine eingetragene Marke der Day Software Holding AG. Firefox ist eine eingetragene Marke der Mozilla Foundation. Gartner Group ist eine eingetragene Marke der Gartner, Inc. GE ist eine eingetragene Marke von General Electric. HTML, XHTML und XML sind eingetragene Marken des W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Hummingbird ist eine eingetragene Marke der Hummingbird Ltd. IBM, Lotus Domino und WebSphere Portal sind eingetragene Marken der IBM. Java, J2EE, Sun Java Systems Portal Server und JavaScript sind eingetragene Marken von Sun Microsystems, Inc. Mac OS ist eine eingetragene Marke der Apple Inc. Microsoft®, Windows®, Dynamics AX®, SQL-Server®, SharePoint Server®, SharePoint Portal Sever®, Exchange®, Microsoft Internet Explorer-Logo (Gra-

XIV

Rechtliche Bestimmungen

fik)®, PowerPoint® und Excel® sind eingetragene Marken der Microsoft Corporation. Oracle und Oracle Portal sind eingetragene Marken der Oracle Corporation. SAP®, ABAP®, BAPI®, SAP iView®, SAP® R/3®, SAP ERP 6.0® und SAP NetWeaver®, SAP Visual Composer, TREX, Web Dynpro sowie Grafiken, entsprechende Logos und weitere im Text verwendete SAP-Produkte sind eingetragene Marken der SAP AG. Tibico Software und Portal Builder sind eingetragene Marken der Tibico Software. T-Online ist eine eingetragene Marke der T-Online AG. Vignette ist eine eingetragene Marke der Vignette Corporation. webMethods ist eine eingetragene Marke der Software AG. Sämtliche in diesem Werk abgedruckten Bildschirmfotos unterliegen dem Urheberrecht der SAP AG oder Microsoft Corporation.

1 Einleitung 1.1 Ziele und Aufbau des Buches Mit dem vorliegenden Werk über Business Intelligence werden zwei Ziele verfolgt. Zum einen soll dem Leser ein klares theoretisches Fundament zu diesem verschiedenartig interpretierbaren Begriff geliefert werden. Zum anderen soll das Grundwissen durch praktische Eindrücke von der Software SAP NetWeaver 7.0 in Form von eigenständig zu bearbeitenden Fallstudien gefestigt werden. Das Lehrbuch richtet sich in erster Linie an Lehrende und Studierende der Fachrichtungen Informatik, Wirtschaftsinformatik und der Wirtschaftswissenschaften. Nicht weniger können auch Anwender im Unternehmen Nutzen aus diesem Werk ziehen, die sich ein Bild von der Business Intelligence und den korrespondierenden Modulen von SAP NetWeaver 7.0 verschaffen möchten. Beginnend mit einer Gesamtsicht auf die Business Intelligence im zweiten Kapitel, gliedert sich der Aufbau des Buches anschließend in drei wesentliche Bereiche, die sich jeweils durch spezielles theoretisches Wissen und maßgeschneiderte praktische Fallstudien auszeichnen. Sämtliche für das Verständnis notwendigen Vorkenntnisse sind dabei den einzelnen Fallstudien vorangestellt, um das Wissen zielgerichtet und im Hinblick auf die aktive Auseinandersetzung mit dem jeweiligen Thema zu vermitteln. Die Fallstudien handeln von den zuvor präsentierten Inhalten und sind kapitelübergreifend integriert, um eine ganzheitliche Sicht auf die BI zu gewährleisten. Als Grundlage für die in den Fallstudien behandelten Auswertungen und Berichte wird das Data Warehouse genutzt, welches im dritten Kapitel Data Warehouse-Architektur behandelt wird. Aufgrund der gemeinsam genutzten Daten besteht eine enge Kopplung zum nachfolgenden vierten Kapitel Unternehmensplanung, das zwar die Data Warehouse-Technologie nutzt, jedoch fachlich ein in sich geschlossenes Thema bildet. Das letzte und fünfte Kapitel Portaltechnologie behandelt die Darstellung von Inhalten in einem Unternehmensportal und zeigt die Möglichkeit auf, wie die in den vorangegangenen Fallstudien erstellten Inhalte in das Portal integriert werden können. Die einzelnen Kapitel des Buches lassen sich unabhängig von einander durcharbeiten und verstehen. Dem Leser wird jedoch empfohlen, nach Möglichkeit den Kapiteln des Buches zu folgen, um dem komplexen Themengebiet sicher folgen zu können. Weil bei den Fallstudien insbesondere auf die Integration geachtet wurde, ist eine kontinuierliche Bearbeitung der praktischen Aufgaben von Vorteil. Die im Buch eingesetzte Formatierung hilft dem Leser dabei den Absichten der Autoren zu folgen. Zudem unterstützen zahlreiche Abbildungen beim Verständnis der Theorie und vor allem auch der Praxis, so dass die Notwendigkeit einer individuellen Instruktion am System entfällt.

2

Einleitung

1.2 Vorbereitung der Fallstudien Für eine Durchführung der Fallstudien ist ein vollständig konfiguriertes SAP NetWeaver 7.0 - System unabdingbare Voraussetzung. Insbesondere die Module SAP BI Data Warehousing, SAP BI-Integrierte Planung und das SAP NetWeaver Portal müssen einwandfrei arbeiten. Als Schnittstelle zu Quellsystemen muss im SAP BI Data Warehousing die PC-File-Schnittstelle eingerichtet sein. Auf diese Weise lassen sich die Daten der Fallstudien in das System hochladen. Die für die Durchführung der Fallstudien erforderlichen Dateien können unter folgender URL heruntergeladen werden. http://vlba.wi-ol.de/BI70_buch/dateien/ Den Anwendern muss im SAP-System ein Namensraum zugewiesen werden, innerhalb dessen sie Objekte im SAP BI Data Warehousing und im Portal anlegen können. Den Nutzern müssen zudem ausreichend Rechte vergeben werden, damit sie im SAP-System Entwicklungen tätigen können. Die Arbeitsplätze müssen über einen Webbrowser (empfohlen wird der Microsoft Internet Explorer ab Version 6.0) und Microsoft Excel ab Version 2003 verfügen.

1.3 Einführung in die Benutzung von SAP Software Der Zugriff auf ein SAP NetWeaver 7.0 - System erfolgt über zwei verschiedene Frontends. SAP GUI rührt von der Zeit der Client-Server-Architekturen her und wird für die Anmeldung und Arbeit am SAP BI Data Warehousing genutzt (siehe Abb. 1.1). SAP GUI wird ergänzt durch das Portal, das über einen Webbrowser erreicht wird. Obwohl das Portal mit Hilfe eines Standardprogramms aufgerufen wird, bietet es derart umfangreiche Funktionen zur Pflege und Entwicklung des Systems, dass es als eigenständige Benutzeroberfläche zu sehen ist.

Einführung in die Benutzung von SAP Software

3

Abb. 1.1 SAP Logon

SAP GUI stellt die Benutzeroberflächen der SAP-Software unter dem Betriebssystem Microsoft Windows dar. Um sich am System anzumelden, wird das Programm SAP Logon gestartet. Im Karteikartenreiter Systeme sind alle für eine Anmeldung konfigurierten SAP-Systeme aufgelistet. Durch das Markieren eines Eintrags und Betätigen der Schaltfläche Anmelden (1) versucht SAP Logon, eine Verbindung mit dem gewünschten System herzustellen. Konnte diese erfolgreich etabliert werden, öffnet sich die Oberfläche des SAP GUI, das sogenannte SAPFenster (vgl. SAP 2008c). Als Schnittstelle zwischen dem SAP-System und dem Anwender bietet das SAP-Fenster Funktionen zur Informationsdarstellung, Funktionsausführung und Dateneingabe. Programme oder Anwendungen werden im SAP-System als Transaktionen bezeichnet. Ausgeführt werden sie, indem die Transaktion im Anwendungsbaum selektiert wird oder über die Eingabe des Transaktionscodes im Befehlsfeld (vgl. SAP 2008c). ÄTransaktionen sind funktional zusammengehörige Verarbeitungseinheiten, die konsistente und betriebswirtschaftlich zulässige Datenbankänderungen durchführen³5DXtenstrauch 2003) Das SAP-Fenster gliedert sich in die Hauptbestandteile Menüleiste, Systemfunktionsleiste, Titelleiste, Anwendungsleiste sowie Dynprobereich und Statuszeile (siehe Abb. 1.2).

4

Einleitung

Abb. 1.2 SAP-Fenster

In der Menüleiste werden Standardfunktionen zu Transaktionen angeboten, zu denen beispielsweise die Hilfe und die benutzerspezifischen Einstellungen gehören. Ergänzt wird dieser Bereich durch die Systemfunktionsleiste, die Funktionen zur Navigation in Anwendungen bietet. Hervorzuheben sind Funktionen zum Beenden oder Abbrechen einer Transaktion, zum Navigieren durch verschiedene Seiten sowie die Möglichkeit, ein neues Fenster (in der SAP-Terminologie Modus genannt) zu öffnen. Titel und Anwendungsleiste sind von der ausgeführten Transaktion abhängig. Bei den Schaltflächen der Anwendungsleiste handelt es sich oft um die am häufigsten genutzten Funktionen zur Anwendung, auf die der Anwender direkt zugreifen kann. Der Dynprobereich nimmt im Fenster die größte Fläche ein und stellt die eigentliche Maske der Anwendung dar. Er enthält verschiedene Bildschirmobjekte, wie zum Beispiel Schaltflächen, Ausgabe- und Eingabefelder, über die der Anwender mit dem System interagieren und elementare Daten austauschen kann. Im unteren Bereich des SAP-Fensters befindet sich die Statusleiste, in der allgemeine Informationen über die aufgerufene Transaktion ausgegeben werden. So kann dort der aktuelle Verarbeitungsstatus abgelesen werden, der dem Anwender zusätzlich zum Text durch Symbole mitgeteilt wird (vgl. SAP 2008c). Anders als das SAP-Fenster wird das SAP NetWeaver Portal über den Webbrowser aufgerufen. Zu diesem Zweck benötigt der Anwender die Adresse der Eingangsseite zum Portal in Form eines Uniform Unif Resource Locator (URL). Diese

Einführung in die Benutzung von SAP Software

5

setzt sich oft aus der Adresse des Servers und dem Suffix Ä/irj/³ zusammen, beispielsweise Ähttp://sdn.sap.com/irj/portal/³.

Abb. 1.3 SAP NetWeaver Portal

Im Portal gleichen die Navigation und Darstellung einer herkömmlichen Webseite (siehe Abb. 1.3). Durch Zeigen mit dem Mauszeiger auf Felder, Wörter oder Symbole und Klicken mit der linken Maustaste werden Funktionen ausgeführt. Der Rechtsklick bietet zusätzlich zu den erkennbaren Funktionen ein Kontextmenü, wie es aus einer Desktop-Anwendung heraus bekannt ist. Hinzu kommt die Fähigkeit des Portals, Drag & Drop von Feldern zu unterstützen. Dadurch ist es beispielsweise möglich, die Gestaltung einer Tabelle interaktiv durch Markieren und Hinzuziehen von Feldern um Spalten oder Zeilen zu ergänzen. Die Funktionen im Portal sind jedoch stark vom verwendeten Webbrowser abhängig (vgl. SAP 2008a).

2 Business Intelligence 2.1

Grundlagen der Business Intelligence

Der Entschluss eines Unternehmens, seine Informationsinfrastuktur an den Anforderungen der Anwender auszurichten, ist in höchstem Maße strategisch und zudem oft geschäftskritisch. Eine neue Systemlandschaft aufzubauen oder eine existierende zu erweitern und zu modernisieren bedeutet bereits für kleine und mittlere Unternehmen (KMU) nicht nur eine enorme Ressourcenbindung. Mit der Entscheidung für eine Informationssystemstrategie steht und fällt oftmals das gesamte Unternehmen, denn die Informationstechnologie durchdringt in ihrer Querschnittsfunktion praktisch alle Bereiche des Unternehmens. Neben SAP sind auch andere große Softwarekonzerne in der BI aktiv. Ein Blick auf den Wettbewerber Microsoft lässt den enormen Investitionsaufwand und die Systemkomplexität der aktuellen BI-Lösung erahnen. Für Microsoft Dynamics AX, sind neben den Client-PCs auch sechs Server für die Datenbank, das System an sich, das Enterprise Portal, die Reporting / OLAP-Services und den Austausch von Geschäftsdaten (B2B) erforderlich (vgl. Microsoft 2008a). Will das Unternehmen auch bei der Bürokommunikation nicht zurückfallen, so fallen weitere Investitionen in Server für E-Mail, Dateiaustausch und Unternehmensüberwachung an (vgl. Microsoft 2008b). Es sind dabei nicht so sehr die Hardware- und Lizenzkosten, die das Investitionsvolumen in die Höhe treiben. Der größte Posten bei einem IT-Projekt dieser Art sind oftmals die Konfiguration und Anpassung des Systems an die Kundenwünsche sowie die anschließende Wartung der Systeme. Was an dem gewählten Beispiel des Anbieters Microsoft deutlich wird: den größten Teil der Informationstechnologie machen Systeme zur Unterstützung von Business Intelligence aus, die zurzeit auch massiv als möglicher Wettbewerbsfaktor beworben wird (vgl. Microsoft 2006, Saracus 2008, Siemens 2008). Tabelle 2.1 Business Intelligence in einem ERP-System Systembezeichnung

BI-relevante Zuordnung

ERP-System

Quellsystem für BI

Dateiaustausch

Stellt Funktionen für BI bereit

Datenbank

Datenquelle für BI

E-Mail und Kommunikation Stellt Funktionen für BI bereit Enterprise Portal

Stellt hauptsächlich Funktionen für BI bereit

Reporting Services

Business Intelligence

OLAP

Business Intelligence

B2B Datenaustausch

Quellsystem für BI und Datenlieferant für operative Systeme

Unternehmensüberwachung Business Intelligence

8

Business Intelligence

Die Auflistung in Tabelle 2.1 zeigt beispielhaft an einer Softwarelösung mittelgroßer Unternehmen, wie weit Business Intelligence in heutige Informationssystemlandschaften vorgedrungen ist. Dass große Unternehmen und Konzerne nicht minder davon betroffen sind, belegen circa 29.000 produktive SAP NetWeaver-Systeme (die SAP Technologie- und BI-Platform) bei einer Gesamtkundenzahl der SAP 46.100 (vgl. SAP 2007). Sich mit dem Thema BI umfassend auseinanderzusetzen, ist eine Pflicht der für die Informationssystemstrategie verantwortlichen Führungskräfte. Ebenso angesprochen sind aufgrund der heutigen Anforderungen an das Personal auch Fachkräfte, die mit der Entscheidungsvorbereitung betraut sind. Controller und Führungskräfte der unteren Ebene sind heutzutage nicht minder an einer Strategiefindung und Konzeption sowie der Einführung, Entwicklung und Pflege eines BI-Systems beteiligt. Es ist daher für alle Teilnehmer erforderlich, sich dem Thema Business Intelligence zu nähern und die grundlegenden Prinzipien und Leitgedanken nachzuvollziehen. Diese Erkenntnis hat sich mittlerweile in praktisch allen Unternehmen durchgesetzt, denn die Prognosen aus dem Jahre 2004, in denen vom „Wachstumsmarkt BI“ gesprochen wird (vgl. Meta Group 2004), haben sich als zutreffend erwiesen: das Interesse an BI ist seit Jahren ungebrochen und es wird die nächsten fünf Jahre ein konstanter Wachstumsmarkt bleiben (vgl. Gartner 2008). Die Welt der SAP stellt sich technisch noch komplexer als das zu Beginn genannte Beispiel dar, kann aber unter dem Oberbegriff SAP NetWeaver 7.0 als Technologie- und BI-Platform zusammengefasst werden. Die SAP bietet ihren Kunden mit diesem Produkt eine einheitliche BI-Lösung an, die nahtlos und mit vergleichsweise geringem Zeitaufwand in die SAP-Systemlandschaft integriert werden kann. Im nachfolgenden Kapitel sollen zunächst die Grundlagen für das Verständnis von Business Intelligence aus fachlicher wie technischer Sicht geschaffen werden, um anschließend die Lösung der SAP in Form von SAP NetWeaver 7.0 vorzustellen.

2.1.1 Nachrichtendienst des Unternehmens Mag die Übersetzung von Business Intelligence ins Deutsche verblüffend sein, ist sie dennoch zutreffend. So wie es den „Secret Intelligence Service“ (SIS, früher auch als MI6 bezeichnet) des britischen Auslandsgeheimdienstes gibt, so existiert in vielen Unternehmen auch eine Organisationseinheit mit dem Namen „Business Intelligence Department“. Neben dem Begriff Intelligence einen diese Institutionen die Aufgaben der Datenbeschaffung, Auswertung und Präsentation dieser vor den Entscheidungsträgern zum Zwecke der Entscheidungsunterstützung. Der Begriff Business Intelligence wird seit den frühen 90er Jahren verwendet und mal enger, mal weiter ausgelegt. Getrieben vom technologischen Feuerwerk der Softwarekonzerne und den steigenden Anforderungen an die Unternehmen,

Grundlagen der Business Intelligence

9

bedingt durch Stakeholder und in einem globalen Wettbewerb agierende Konkurrenten, wurde die Business Intelligence zu einem von vielen „Schlachtrufen“ deformiert. So wird BI je nach Bedarf mal von der fachlichen, mal von der technischen Seite betrachtet. Die korrekte Sicht jedoch verbindet Technologie und Methodik miteinander. Denn Business Intelligence ist nicht nur ein fachliches Vorgehensmodell und Konzept, wie zum Beispiel Lean Management, oder ein technischer Begriff, wie Service Oriented Application Programming (SOAP); es ist eine Verbindung aus beidem und erlaubt, wie ein Kaleidoskop, unterschiedliche Sichten mit individuellen, an den Anforderungen orientierten Schwerpunkten. Eine dieser Seiten vollständig zu ignorieren ist nicht zweckmäßig, da sie einer komplementären Beziehung zueinander stehen. Aufgrund der technischen und fachlichen Aspekte, die gleichermaßen wie eine Waage ihre Bedeutung für die BI einfordern, lassen sich dann auch unterschiedliche Definitionen der Business Intelligence in der Literatur finden. Eine am fachlichen Prozess der Entscheidungsunterstützung orientierte Interpretation liefern Grothe und Gentsch: Business Intelligence (BI) bezeichnet den analytischen Prozess, der - fragmentierte - Unternehmens- und Wettbewerbsdaten in handlungsgerichtetes Wissen über die Fähigkeiten, Positionen, Handlungen und Ziele der betrachteten internen oder externen Handlungsfelder (Akteure und Prozesse) transformiert. (Grothe und Gentsch 2000) Ebenso gibt es stärker auf die technisch/funktionale Realisierung bezogene Aussagen, deren Anspruch auf Deutung des Begriffs „Business Intelligence“ nicht minder legitimiert ist. Daher entschlossen sich Chamoni und Gluchowski, ganz auf den „durch inflationäre Verwendung verwässerten Begriff“ zu verzichten und stattdessen die bis dahin nicht belegte Bezeichnung „Analytische Informationssysteme“ zu verwenden. Analytische Informationssysteme dienen der Informationsversorgung und funktionalen Unterstützung betrieblicher Fach- und Führungskräfte zu Analysezwecken. Insbesondere zählen dazu drei Facetten analytischer Informationssysteme bestehend aus Data Warehouse (OLAP und Reporting), Data Mining und betriebswirtschaftlichen Anwendungen (Planung, Budgetierung, Konzernkonsolidierung und analytisches CRM) (vgl. Chamoni u. Gluchowski 2006). Das Vermeiden des Begriffs „BI“ erwies sich aber nicht als praktikabel, da er bereits etabliert war und von Forschung wie Wirtschaft intensiv genutzt wurde. Im Nachhinein verfolgten beide Autoren daher einen Ansatz, der die fachliche und technische Interpretation miteinander verbindet und eine viel breitere und situationsgerechtere Definition zulässt. Der Teilbegriff „Intelligence“ wird dabei als Einsicht oder Verständnis interpretiert. Diese Deutung weckt zu Recht Parallelen

10

Business Intelligence

zum Lernprozess „Lernen durch Einsicht“, der eine kognitive Leistung darstellt. Eine kognitive Leistung wird ebenfalls bei der Anwendung von Business Intelligence im Unternehmen erbracht. Bei Business Intelligence handelt es sich um Techniken und Anwendungen, die entscheidungsunterstützenden Charakter aufweisen und zum besseren Verständnis in die Mechanismen relevanter Wirkungsketten führen sollen (vgl. Chamoni u. Gluchowski 2008). Mit dieser Definition ist der Begriff „BI“ hinreichend erläutert. Er wirft jedoch zusätzlich die Frage auf, welche Techniken und Anwendungen zur Business Intelligence gezählt werden sollen. Dieser Einwand ist in soweit nachvollziehbar, als dass die Softwarekonzerne aus Gründen des Marketings ihre Produkte gerne mit dem Attribut „BI“ versehen und Unternehmen nur zu gerne behaupten, BI erfolgreich einzusetzen, um nicht als rückständig zu gelten. Aus wissenschaftlicher Perspektive ist es notwendig, das Untersuchungsobjekt zu präzisieren, weil sonst eine vergleichsweise hohe Abstraktionsebene nicht überwunden werden kann und der Bezug zu bereits gesicherten Erkenntnissen nicht herzustellen ist. Ein stark eingegrenztes Bild der Techniken und Anwendungen des Untersuchungsobjekts BI enthält neben einer für die Entscheidungsfindung relevanten Datenbasis lediglich Filtertechniken zur intuitiven Navigation im Datenbestand sowie das sogenannte „Exception Reporting“, das die farbliche Hervorhebung von Wertintervallen im Datenbestand umfasst. Diese Funktionen bietet aber auch schon das Tabellenkalkulationsprogramm Microsoft Excel seit der im Jahre 1997 erschienenen Version 97 an. Es stellt sich daher die Frage, ob ein Unternehmen, dessen Arbeitsplätze mit Microsoft-Excel ausgestattet sind, von sich behaupten darf, im Bereich BI aktiv zu sein. In Anbetracht der Tatsache, dass in einer Studie der Meta Group aus dem Jahre 2004 (vgl. Meta Group 2004) von den befragten Unternehmen Eigenentwicklungen als BI-Lösung an zweiter Stelle mit 18% hinter Lösungen der SAP (mit 36% an erster Stelle) genannt wurden, kann einer professionell ausgearbeiteten Microsoft Excel-Applikation auch das Prädikat „BI-tauglich“ vergeben werden. Ein Systemverbund aus einem Microsoft SQL-Server 2008 als Datenbasis und BI-Service-Dienstanbieter, Microsoft Excel 2007 als Frontend und dem Microsoft SharePoint Server zur Verbindungserstellung kann durchaus zu einem mächtigen Werkzeug aufsteigen. Auf dieser technologischen Basis lassen sich umfangreiche Applikationen erstellen, die Funktionalität und Leistung Standard-Lösungen in nichts nachstehen. Doch BI kann technologisch noch viel mehr bedeuten. Nicht erst seit Bill Inmons Definition des Data Warehouse (vgl. Inmon 1996) existiert der Begriff OLAP, der als „online analytical processing“ für eine intuitive, schnelle und präzise Navigation im Datenbestand steht. Filtertechniken werden ergänzt um eine dynamische Tabellenstruktur, wodurch sich Zeilen und Spalten mit einfachen, kurzen Befehlen des Anwenders individuell und verschieden anordnen lassen. Auf diese Weise erstellt der Anwender unmittelbar und in Eigenregie informationsbe-

Grundlagen der Business Intelligence

11

darfsgerechte Auswertungen, ohne dass zusätzliche Programmzeilen benötigt werden, um die Abfragen an die Datenbank zu erstellen und die Ausgabemaske anzupassen. All dies wird durch das BI-System im Verborgenen geleistet. Neben den OLAP-Techniken wird der Bereich „Data Mining“ gerne zur BI hinzugezählt, der ebenso wie OLAP oft in Verbindung mit dem Data Warehouse genannt wird. Data Mining beschäftigt sich mit der Erkennung von Mustern in großen Datenbeständen und erlaubt es, neue Hypothesen über die Strukturen im Datenpool zu generieren oder vorhandene zu bestätigen. Ein bekannter Vertreter des Data Mining ist der Entscheidungsbaum, der durch einen gleichnamigen Algorithmus Regeln erzeugt, die auf der Basis von Attributen einen Datensatz klassifizieren können. So wird zum Beispiel die Bonität eines Kunden oftmals durch Entscheidungsbäume bestimmt, indem dessen Stammdaten (z.B. Sitz der Gesellschaft, Branche, Betriebsgröße) und aus statistischen Analysen gewonnene Daten (durchschnittlich bestellte Menge, durchschnittliche Anzahl Tage bis Zahlungseingang) die erzeugten Regeln durchlaufen. So erfolgt an deren Ende beispielsweise die Einordnung in „bezahlt die Rechnung“ oder „bezahlt die Rechnung nicht“. In der Praxis allerdings wird eine Klassifikation niemals nur durch einen Data Mining Algorithmus durchgeführt. Es werden nicht nur weitere Algorithmen eingesetzt, zusätzlich werden unternehmensexterne Daten (wie z.B. SCHUFA-Einträge oder Daten der CreditReform) eingeholt, analysiert und mit unternehmensinternen Werten aus dem CRM-System abgeglichen, oder kurz: Business Intelligence wird eingesetzt, um den Kunden zu analysieren. Dieses kurze Szenario macht deutlich, dass sich zu Business Intelligence auch noch andere Systeme zählen lassen, die zusätzlich um Planungswerkzeuge, Kennzahlensysteme und Systeme zur Unternehmensüberwachung und -steuerung ergänzt werden können. So bildet sich ein analyseorientiertes oder ein weites Verständnis für BI heraus. Ohne wohl definierte Prozesse kommt seit Jahrzehnten kein Unternehmen mehr aus. Auch wenn die Prozesse oft nicht niedergeschrieben sind, so werden sie von den Teilnehmern bei der Abarbeitung der betrieblichen Aufgaben schon der Routine wegen meist eingehalten. Konnte in der Vergangenheit noch über mangelnde Sorgfalt und Kontinuität der am Prozess beteiligten Personen hinweggesehen werden, darf die Geschäftsleitung in der heutigen Wettbewerbssituation es nicht mehr zulassen, dass Prozessabläufe in Teilen oder in Gänze immer neu erfunden werden. Auch für die Business Intelligence existiert eine Prozessdefinition. Sie wurde 1997 von Bill Inmon in der Corporate Information Factory als „Operational Feedback Loop“ beschrieben (vgl. Inmon 2001). Business Intelligence ist nicht nur das Übertragen von Daten aus operativen Systemen heraus in spezielle, analytische Informationssysteme zum Zwecke des Reporting und Data Mining. Es ist auch die Anwendung der aus den Analysen neu gewonnenen Erkenntnisse in Form eines Rückflusses von Daten in die operativen Systeme. So ließen sich die aus dem Bonitätsszenario bekannten Klassifikationsdaten des Entscheidungsbaums in den operativen Systemen dazu nutzen, um auf das Wissen um die Bonität des Kunden unmittelbar im Alltagsgeschäft zugreifen zu können.

12

Business Intelligence

Um nun den Begriff Business Intelligence fassen zu können, ist es notwendig, alle Bereiche derart zu verbinden, dass die unterschiedlichen Sichtweisen nicht zu einer einzigen verwischt, aber auch nicht durch unüberwindbare Mauern voneinander getrennt werden. Wie die Abbildung 2.1 zeigt, ist es Chamoni und Gluchowski gelungen, die Technologien und Anwendungen gerecht aufzutrennen, sie mit der Prozessebene jedoch wieder zu verbinden und gleichzeitig eine Gruppierung zur Würdigung der Sichtweisen vorzunehmen. So ist das Data Warehouse, das oft als das BI-System schlechthin gilt, nicht im Mittelpunkt der Grafik zu finden. Die Technologie spielt an dieser Stelle eine geringere Rolle als die auf ihr aufsetzenden Anwendungen, die OLAP-Funktionen und das Management Information System. Objektiv betrachtet brauchen diese kein Date Warehouse als technologische Grundlage, obwohl es sich sehr gut dafür eignet. Nun kann eine allgemeingültige Definition nur schwer der BI-Softwarelösung eines speziellen Anbieters entsprechen. Schließlich sollte sich jeder Softwareanbieter primär an den Bedürfnissen seiner Kunden orientieren. Doch hat es eine Technologie in den vergangenen Jahren vollbracht, nahezu unbemerkt die Informationssystemlandschaft zu durchdringen: das Portal. Technisch relativ simpel bildet es in immer mehr Unternehmen den anwendergerechten, zentralen Zugangsknoten zu Anwendungen, Auswertungen und Dokumenten, die mit Geschäftsprozessen in Berührung stehen. So bieten mittlerweile die großen BIAnbieter das Portal an und verbinden darüber ihre Applikationen (vgl. SAP 2008a, Microsoft 2008c). Als fester Bestandteil der marktführenden BI-Lösungen hat das Portal die Berechtigung, um in die Gemeinschaft der BI-Technologien und Anwendungen aufgenommen zu werden. Selbstverständlich kann BI auch ohne die Portaltechnologie definiert werden; wirklichkeitsgetreuer ist aber eine Definition, die das Portal berücksichtigt. Denn ähnlich wie Standard-Reports lebt es von den Inhalten, die in ihm dargestellt werden. Eine analytische Fähigkeit kann nur dem Anwender des Portals nachgesagt werden, der Technologie jedoch nicht. Die Ausrichtung lässt sich keinem Schwerpunkt zuordnen, da die Technologie nicht so stark in den Vordergrund rückt wie bei einem Data Warehouse. Die Abbildung und Zusammenstellung der Inhalte sowie das System für die Benutzerberechtigungen belegen, das die Technologie des Portals dennoch von Bedeutung ist. Ebenso kann das Portal als Anwendung gesehen werden, die bereits verfügbare Technologien nutzbar macht. So werden mit dem Portal ein Einstieg in fast jede Applikation angeboten und die Inhalte abgebildet. Eine Zusammenfassung der Begriffe und ihrer Beziehung untereinander bietet Abbildung 2.1.

Grundlagen der Business Intelligence

13

Abb. 2.1 Einordnung unterschiedlicher Facetten und Abgrenzungen von Business Intelligence mit Enterprise Portal (vgl. Chamoni u. Gluchowski 2008).

Nun ist nicht jede unternehmerische Aktivität, die sich in beliebiger Tiefe mit BI befasst, auch repräsentativ genug, um von einer erfolgreichen BI-Einführung zu sprechen. Wenngleich auch zum Beispiel der Einsatz eines Data Warehouse die Umsetzung einer BI-Strategie begünstigt, kann es als einzelnes System nicht für eine BI-Lösung stehen. Angebrachter wäre es in diesem Fall, von einem Data Warehouse-basierten Enterprise Reporting zu sprechen. Denn Business Intelligence ist vor allem die Kombination bzw. Integration von verschiedenen Technologien und deren Einsatz zur gezielten Erfüllung der Anforderungen der Anwender. Insbesondere muss erkannt werden, dass BI nicht nur Technologien und Anwender miteinander verbindet. Die Anforderungen der Anwender richten sich nämlich nicht nur an die Funktionalität der Technologie, sondern auch an die Implementierung des Expertenwissens aus dem Fachbereich in die Anwendungen, das spätestens beim Reporting eingefordert wird. Das Fachwissen der Anwender und der IT muss bei der Erstellung eines BI-Systems in höchstem Maße genutzt werden, damit das BI-System nicht nur eine leere Hülle darstellt, sondern auch die geforderten Inhalte korrekt, übersichtlich und in stimmigem Zusammenhang darstellt. Abbildung 2.2 zeigt mit dem BI-Kreis einen Verbund der drei Hauptelemente bild Technologie, Anwender und Fachwissen, um den integrativen Charakter der BI hervorzuheben (siehe Abb. 2.2).

14

Business Intelligence

Abb. 2.2 BI-Kreis

2.1.2 Vom MIS zum DIS Business Intelligence ist nicht über Nacht entstanden. Anders als beispielsweise die Data Warehouse Technologie, kann BI auf eine lange Ahnenreihe verweisen. Bereits in den 60er Jahren des vergangenen Jahrhunderts entstand mit den ersten Computersystemen für den betrieblichen Nutzen nahezu zeitgleich auch die Reporting-Komponente. Nennenswert ist an dieser Stelle ein Beitrag von Leavitt und Whistler, die mit als die Ersten den Begriff der Informationstechnologie in der Fachpresse geprägt haben a : aben Die neue Technologie wurde noch nicht mit einem einheitlichen Namen verVHKHQ0DQVROOWHVLHÄ,QIRUPDWLRQVWHFKQRORJLH³QHQQHQ6LHLVWDXVPHKUeren Teilen aufgebaut. Einer dieser Teile beinhaltet die Techniken, um große Mengen an Daten schnell zu verarbeiten und wird durch die hohe Geschwindigkeit des Computers verkörpert. Ein zweiter Teil konzentriert sich auf die Anwendung statistischer und mathematischer Methoden für Entscheidungsprobleme. Er wird durch Technologien wie die mathematische Programmierung und Methoden des Operations Research dargestellt. Ein dritter Teil zeichnet sich schon aab, obwohl dessen Anwendungen noch nicht sehr klar zum Vorschein gekommen sind. Es besteht aus der Simulation von höherem Denken durch Computerprogramme (vgl. Leavitt u. Whistler 1958).

Grundlagen der Business Intelligence

15

In diesem Beitrag ist definitiv die Rede von Informationssystemen, auch wenn diese nicht explizit so benannt werden. Ein Jahr nach der Publikation wurden auf einem von der System Development Corporation (SDC) veranstalteten Symposium vom Direktor der Lockheed Aircraft Corporation erste Kriterien eines Management Information Systems genannt, das die vom Management geforderten Erkenntnisse liefern soll (vgl. Ream 1960):  Es erleichtert die Planung und Kontrolle und ermöglicht dem Top-Management ein vollständiges Verständnis der auf die Führung der Geschäfte wirkenden externen wie internen Faktoren  Es stellt für die Performance-Messung der operativen Verantwortung unternehmensweite, operationale Ergebnisse konsolidiert zur Verfügung und bietet gleichzeitig dem Top-Management eine allumfassende Übersicht  Es bietet allen Führungsbereichen die benötigten oder wertvollen Informationen für eine dynamische Steuerung der operativen Geschäfte  Es deckt den Informationsbedarf, der bei der kontinuierlichen Entwicklung und Anwendung fortschrittlicher, wissenschaftlicher Management-Methoden entsteht  Es ist von Natur aus dynamisch und fähig, sich den Anforderungen aus geänderten sozi-ökonomischen und politischen Umweltbedingungen, in denen der Betrieb überleben muss, anzupassen Auch wenn in den genannten Punkten das Top-Management als Nutzer angesprochen wird, so sind die zu bereitstellenden Daten noch stark operativ. Die damaligen Computersysteme waren darauf ausgelegt Geschäftsprozesse zu unterstützen, vergleichbar mit heutigen ERP-Systemen. Strategische Entscheidungsunterstützungs- und Planungsfunktionen standen bei den ersten ERP-Systemen nicht an erster Stelle im Lastenheft. Daher setzte sich in der Entwicklung der MIS die Erkenntnis durch, dass die Anforderungen an ein operatives und ein TopManagement-Entscheidungen unterstützendes System oft nicht vereinbar sind (vgl. Dearden 1964). Eine Einschätzung die bis heute Gültigkeit besitzt. Dieser Bruch in den Anforderungen hat zur Folge, dass der Standard-Bericht eines operativen Systems zumeist mit einer Liste von Datenzeilen aufwartet, die nicht oder nur wenig zweckgerichtet aufbereitet wurde. Mehr wurde von ERP-Systemen im Reporting zur damaligen Zeit nicht erwartet. Doch Auswertungen dieser Art sind viel zu unübersichtlich, als dass sie Entscheidungsträgern dienlich sein könnten. Dieser Schwachpunkt führt letztendlich dazu, dass nicht das Top-Management die Systeme bedient und Auswertungen erstellt, sondern die Controller und Entscheidungsvorbereiter (vgl. Oppelt 1995). Die Konzentration auf die Gruppe der Entscheidungsvorbereiter, bzw. die unteren Führungsebenen wurde in den nächsten Jahrzehnten der betrieblichen entscheidungsunterstützenden Informationssystementwicklung sogar noch gefestigt. Für das Top-Management hingegen wurde eine neue Art von System geschaffen, das entscheidungsunterstützende System (Decision Support System, DSS). Darin vereinten sich die Funktionen, die einem MIS bis dahin fehlten: interaktive Un-

16

Business Intelligence

terstützung des menschlichen Urteilsvermögens zur Verbesserung der Effektivität von Entscheidungsprozessen in einem interaktiven, anpassungsfähigen MenschMaschine-Dialog (vgl. Keen u. Scott Morton 1978). Jedoch konnten sich auch diese Systeme nicht im Top-Management durchsetzen und dienten daher mehr der Erkenntnis, dass die Nutzerseite stärker zu berücksichtigen ist, bevor ein weiterer Versuch in Richtung Top-Management-Unterstützung unternommen wird (vgl. Oppelt 1995). Eine Studie aus dem Jahre 1988 spiegelt die damalige Situation in den oberen Führungsetagen gut wider, bei der nur 29% der Führungskräfte der ersten Ebene in Deutschland angaben, den Computer selbständig nutzen. (vgl. Müller-Böling u. Ramme 1988). Ein System, das auf die Bedürfnisse der obersten Entscheidungsträger ausgerichtet ist, kam erst mit dem Executive Information System (EIS) auf. Wird von einem System der National Aeronautics and Space Administration (NASA) aus dem Jahre 1969 einmal abgesehen, so hat auch hier das Unternehmen Lockheed mit dem 1979 in Betrieb genommenen „Management Information and Decision Support System“ die Vorreiterrolle übernommen. In den 80er Jahren hat sich dann bis in die 90er hinein das EIS als das ein „auf die Informationsbedürfnisse der obersten Führungskräfte zugeschnittenes, computerbasiertes Informationssystem, das einen leichten, schnellen und direkten Zugang zu entscheidungsrelevanten externen wie internen Informationen ermöglicht und diese Informationen in präsentations- und nutzerorientierter Form darstellt“ (Oppelt 1995) etabliert. Das Konzept wurde so gut angenommen, dass EIS zur Mitte der 90er Jahre für „Enterprise Information System“ stand, wodurch sich die Zielgruppe erheblich erweiterte.  Integration interner und externer sowie quantitativer und qualitativer Daten aus verschiedensten Quellen  Schnellübersicht („Briefing Book“) mittels mehrdimensionaler, hierarchischer Datenaggregation und der Möglichkeit der flexiblen, schrittweisen und selektiven Detaillierung („Drill-Down“)  Ausnahmeberichtswesen („Exception Reporting“), zumeist mittels farbiger Hervorhebung („Color Coding“) kritischer, vordefinierter Schwellenwerte über- oder unterschreitender Variablen  Möglichkeit der Ad-hoc-Abfrage aktueller Variablenzustände im OnlineBetrieb („Status-Access“)  Einfache, leicht handhabbare statistische Tools (Trendanalyse, Prognose)  Individuelle Bildschirmgestaltung („Personal Views“) mit Kombination von Graphik, Tabelle und Text  Möglichkeit der Weiterverarbeitung der Bildschirminhalte, beispielsweise im Sinne einer automatisierten Präsentationsgraphiken-Erstellung oder Einbindung in ein Textobjekt  Kurze Einarbeitungszeiten - auch bei nur sporadischer Nutzung - unter anderem durch Verwendung von graphischen Benutzeroberflächen und selbsterklärenden Bildschirmmasken  Einfache, tastaturarme Bedienung mittels Maus oder „Touch-Screen“

Grundlagen der Business Intelligence

17

Die Erweiterung mündete in einer Verschiebung der Zielgruppe und sorgte dafür, dass eher das mittlere Management mit Informationen aus diesen Systemen versorgt wurde, als die zu Beginn anvisierte Zielgruppe des Top-Managements. Die Funktionen konnten allerdings überzeugen, sofern sie aus Rücksicht auf die technischen Möglichkeiten zu der Zeit und die Wünsche der Kunden implementiert wurden (vgl. Oppelt 1995). Anders als Anfang der 60er Jahre konnte bei der Implementierung von EIS auf eine breite Palette technologischer Errungenschaften zurückgegriffen werden, die eine Umsetzung der Anforderungen erst möglich machten. Relationale Datenbanken, graphische Benutzeroberflächen, der PC und Programmiersprachen der dritten Generation und, aufgrund der starken Rechnerleistung, fast unbegrenzte Systemressourcen machten es den Informatikern erheblich einfacher, die Systeme den Kundenwünschen entsprechend zu gestalten. Unglücklicherweise wurde in den Unternehmen nicht der ganzheitliche Ansatz gesucht. Nur eine Lösung für ein Problem zu finden, das in mehreren Abteilungen herrschte, ist selten praktiziert worden. Stattdessen wurde die jeweils am Besten geeignete Anwendung zur Lösung der betrieblichen Problemstellung eingekauft oder selbst entwickelt, ohne sich mit den anderen Abteilungen abzustimmen. Eine Integration der Systeme war zudem oftmals lediglich in der Theorie machbar, praktisch wurde dieses Ziel nur selten erreicht. Doch EIS sind auf eine Integration zwingend angewiesen, weil sonst der ganzheitliche Blick auf das Unternehmen und seinen Zustand nicht möglich ist. Die problembehaftete Integration ließ die Überlegung reifen, dass wenn schon nicht die Systemintegration machbar ist, so doch zumindest die Datenintegration erfolgen sollte. Die Vorbehalte gegen die wahrscheinliche Datenredundanz und die damit verbundene potentielle Inkonsistenz der Daten wurden überwunden. Die Trennung der operativen und für die Entscheidungsunterstützung notwendigen Daten und Systeme war erreicht. Auf dieser Grundlage ließen sich entscheidungsrelevante Daten aus den operativen Systemen extrahieren und in das EIS laden. Technisch operierten beide Systeme auf relationalen Datenbanken, was sehr schnell zu einem weiteren, ernsthaften Problem für die EIS wurde. Denn als die Systeme getrennt wurden, begann unabhängig davon nahezu zeitgleich die Datenmenge in den operativen Systemen sehr schnell anzuwachsen, wodurch die EIS technisch kaum mehr in der Lage waren, dem Rest der Informationssystemlandschaft zu folgen. Die EIS wurden zunehmend langsamer oder konnten nicht den gewünschten Detaillierungsgrad in den Berichten bieten. Eine scheinbare Lösung der Probleme kam informationstechnisch gesehen von ganz unten. Microsoft wurde mit seinem Paket für Bürosoftware an den Arbeitsplätzen der Controller und der unteren bis mittleren Führungsebene derart populär, dass es in einer Vielzahl von Unternehmen zum primären Reporting-System avancierte. Was in den großen ERP-Systemen im Reporting nicht oder nur mit einem unverhältnismäßig großen Aufwand möglich war, konnte mit Excel-Tabellen und PowerPoint-Folien mit einem Bruchteil der Ressourcen erreicht werden. Allerdings wurde bei der Ernennung von praktisch jedem im Unternehmen zum BI-

18

Business Intelligence

Experten der Koordinations- und Integrationsaufwand nicht ausreichend bedacht, so dass heute davon abgeraten wird, das Reporting-System durch die Fachabteilungen individuell auf Basis von Microsoft Office-Expertise zu errichten. Noch 2004 wurde ermittelt, dass Unternehmen, deren Unternehmensplanung mit Microsoft Excel ausgeführt wird, ca. 30% mehr Zeit für den Abstimmungsprozess benötigen, als Unternehmen, die eine integrierte Planungsapplikation einsetzen (vgl. IBI 2004). Dennoch zeigte sich anhand der Ressourcen, die in das Reporting investiert wurden, dass der Bedarf an einem Reporting-System nach wie vor erheblich war. Die tatsächliche, vor allem technisch weitsichtigere, Lösung war der Einsatz des Mitte der 90er Jahren konzipierten und implementierten Data Warehouse. Mit dieser Technologie wurde die Idee des EIS weiterverfolgt und letztendlich zu dem entwickelt, was als Business Intelligence verstanden wird. Einer der entscheidenden Nachteile des EIS war dessen technologische Basis: das relationale Datenmodell. So sehr es sich auch für transaktionale Systeme eignet, so leistungsunwillig ist es bei Operationen auf großen Datenmengen über mehrere Tabellen hinweg. Vom Konzept her kann das relationale Datenmodell einem EIS nicht dienlich sein. Normalisierung der Daten und redundanzfreie Speicherung in relationalen Tabellen ist vollkommen kontraproduktiv für ein System, das eine maximale Leseperformance auf Millionen von Datensätzen gleichzeitig bieten muss. Hier greift das Data Warehouse ein, indem es die Daten wie schon im EIS aus dem Quellsystem extrahiert, sie aber in eine für die Datenanalyse besser geeignete Datenstruktur hinein lädt. Diese Datenstruktur ist als das multidimensionale Datenmodell bekannt, dessen Aufbau der Vorstellung eines dreidimensionalen Würfels am Nächsten kommt. Auf derart gespeicherten Daten war nun endlich die leistungsstarke Analyse, Simulation und Planung möglich, die seit Beginn der MIS-Entwicklung gefordert war. Zudem wurden die Endanwenderwerkzeuge ausreichend intuitiv gestaltet, so dass ein Reporting von den Anwendern aufgebaut werden konnte, das ihren und damit den Anforderungen aller Führungsebenen gerecht wurde. Nicht zu unterschätzen ist hierbei die Gewöhnung der Anwender an bestimmte Navigationsfunktionen durch das Internet. Wer in der Lage ist, eine Suchanfrage im Internet auszuführen, wird mit einem Web-Reporting nicht überfordert sein. Schließlich sind die Grundfunktionen identisch mit denen, die im World Wide Web (WWW) eingesetzt werden. Eine Übersicht der historischen Entwicklung bietet Abbildung 2.3.

Grundlagen der Business Intelligence

19

Abb. 2.3 Unterstützungsniveau der Entscheidungsunterstützungssysteme

Auf die Frage, was nach der Business Intelligence entwickelt wird, lässt sich nicht ausreichend präzise antworten. Oft wird Business Performance Management (BPM) als Nachfolger der BI genannt. BPM verlagert den Schwerpunkt der BI in Richtung des Unternehmenswertes und versucht einen geschlossenen Kreislauf von Planung, Messung und Steuerung des Wertschöpfungsprozesses (vgl. Chamoni u. Gluchowski 2006, Fraunhofer 2008) zu ermöglichen. Eine Implementierung der Balanced Score Card für strategische Geschäftseinheiten ist ein früher Vertreter dieses Ansatzes. Business Intelligence sollte jedoch mehr eine Basis für das BPM darstellen und ein eigenständiger Begriff bleiben, als an Generalität einzubüßen und in BPM aufzugehen. Shareholder Value zu schaffen sollte nicht Hauptziel der BI sein. Ein mit BI verwandter Begriff ist die Competitive Intelligence. Auch sie ist ein systematischer Prozess der Informationserhebung und -analyse, sie ist jedoch stark auf Daten über Märkte, Wettbewerber und Technologien ausgerichtet (vgl. Michaeli 2006). Somit ist sie ein Spezialfall der BI, der nicht evolutionär die BI ablöst, sondern einen parallelen Strang bildet.

2.1.3 Technologien der Business Intelligence Wenn Interesse an BI besteht, so muss zwangsläufig die Konfrontation mit der damit verbundenen Technologie stattfinden. Letztendlich können die Anforderungen der BI-Anwender nicht erfüllt werden, wenn nicht auf aktuelle Technologien zurückgegriffen und die Entwicklung der IT aufmerksam beobachtet wird. Nun soll aber die Technologie nicht soweit im Vordergrund stehen, als dass sie alles überschattet und zum einzigen treibenden Faktor wird. Daher wird nun an dieser Stelle auf die wesentlichen technischen Komponenten der BI nur kurz eingegangen. Die aus Abbildung 2.1 bekannten Facetten und Einordnungen der Business

20

Business Intelligence

Intelligence werden in Abbildung 2.4 in einem Schema aus Datenflüssen und Daten verarbeitenden Technologien verbunden. Auf diese Weise ist es möglich, den Zweck der Technologien zu verdeutlichen und den Weg der Daten von der Datenquelle bis hin zu dem Moment, indem sie vom Anwender als Informationen aufgenommen werden, aufzuzeigen auf .

Abb. 2.4 Technologien und Datenflüsse

Die Datenbasis stellen externe Datenquellen und operative Informationssysteme eines Unternehmens dar. Dies sind die Quellsysteme, deren für die Entscheidungsunterstützung relevante Daten im nächsten Schritt in das Data Warehouse geladen werden. Das Data Warehouse ist die konsistente Datenbasis für das Reporting einerseits, für Anwendungen, welche die Daten weitestgehend automatisiert verarbeiten, zum Beispiel Data Mining Algorithmen, andererseits. Ebenso kann von hier aus die Rückkopplung des Datenflusses in die operativen Systeme erfolgen. In der letzten Stufe werden die Daten dem Berichtswesen zur Verfügung gestellt, letztlich also den Entscheidungsträgern der verschiedenen Führungsebenen.

Grundlagen der Business Intelligence

2.1.3.1

21

Data Warehouse

Das Data Warehouse stellt nicht nur die Datengrundlage für die Business Intelligence Anwendungen bereit, es ist oftmals auch das eigentliche Berichtssystem. Durch seine zentrale Rolle hat es die Aufgabe, reporting-relevante Daten aus den Quellsystemen zu extrahieren, zu transformieren und in die Datenbereitstellungsebene zu laden. Bei der Extraktion werden gezielt für die Entscheidungsfindung relevante Daten aus den Quellsystemen kopiert und in der Eingangsdatenbank des Data Warehouse abgelegt. Im nächsten Schritt werden die Daten qualitätsgesichert und konsolidiert, um sie anschließend historisiert im multidimensionalen Datenmodell abzuspeichern und den Anwendungen oder Berichten zur Verfügung zu stellen (vgl. Inmon 2001). Bekannt sind zum Beispiel die mehrere Terabyte umfassenden, in Data Warehouses gespeicherten Kunden- und Produktdaten des Online-Shops Amazon.com. Der Vorteil eines integrierten und qualitätsgesicherten Datenbestandes wird noch immer vom Entscheidungsträger unterschätzt, weil die Datenaufbereitungsprozesse für das Management häufig unsichtbar oder die Wege schon derart oft begangen worden sind, dass die zur Gewinnung von Informationen notwendigen Prozesse nicht mehr hinterfragt werden. Dabei ist eine verlässliche Datengrundlage ausschlaggebend für das gesamte Berichtswesen, ohne die jegliche datenbasierte Entscheidung zu einer Gefahr für den Fortbestand des Unternehmens wird. Oftmals wird erst durch den Einsatz eines Data Warehouse erkennbar, an welchen Stellen im Unternehmen bereits nahezu autarke Informationsinseln existieren und sich jedweden Integrationsbemühungen widersetzen. Zum Teil ist dies dadurch begründet, dass Daten von unternehmensexternen Dienstleistern stammen oder in den Abteilungen unterschiedliche Informationssysteme eingesetzt werden. Doch auch wenn ein einziger Systemanbieter die Informationsinfrastruktur im Unternehmen beherrscht und daher die Integration nicht notwendig sein sollte, sind die Daten oft nicht ohne weiteres über die Module hinweg miteinander kombinierbar. Der Wunsch der Kunden nach individueller Anpassung der Informationssysteme macht es möglich, dass ein riesiges System, wie zum Beispiel das SAP ERP 6.0 es erlaubt, die einzelnen Module unabhängig voneinander anzupassen. Mit der Einführung eines Data Warehouse als „single point of truth“ wird allerdings stillschweigend eine unternehmensweit gültige Richtlinie herausgegeben: Auswertungen jeglicher Art haben sich an den Daten des Data Warehouse zu orientieren. Eine Harmonisierung der Daten aus allen Bereichen ist daher weiter das vorrangige Ziel bei der Datenbeschaffung, um ohne langwierige und oftmals fehlerträchtige Abstimmungsprozesse die reibungslose und konsistente Auswertung der Daten von der Finanzbuchhaltung über die Kostenrechnung, das Personalwesen und die Warenwirtschaft bis hin zur Produktionsplanung sicherzustellen.

22

Business Intelligence

2.1.3.2

Enterprise Portal

Die Portaltechnologie ist sehr eng mit der Entwicklung des Internets, bzw. World Wide Web verbunden. Schon in den frühen Anfängen der Internets war es notwendig, die durch eine rasche Zunahme von Web-Inhalten aufkommende Informationsflut für den Anwender auf eine möglichst benutzerfreundliche Art zu bändigen. Ein erster Schritt bestand darin, einen geordneten Einstieg in die Welt der Informationen der HTML-Seiten zu ermöglichen. Dies wurde durch eine gezielte Zusammenstellung von Inhalten erreicht, die als Tor zum Internet fungierten. Dieses Tor bietet dem Anwender einen schnellen Zugriff auf die wichtigsten Inhalte des Internets oder des Service-Providers, etwa T-Online oder AOL. Die Dienste umfassen zum Beispiel E-Mail, Nachrichten, Shopping, Software und vor allem Wissen und die Suche danach. Diese Einstiegsseiten, die wie ein Zugangstor zum Internet wirken, werden als Portal bezeichnet (vgl. Großmann u. Koschek 2005). Wird in einem Portal der personalisierte Zugang zu allen relevanten Inhalten und Applikationen am Arbeitsplatz des Benutzers geboten, so wird von einem Unternehmensportal gesprochen. Hinter dem Portal verbirgt sich allerdings noch viel mehr als ein Zugang zum Inter- oder Intranet. Das Berichtswesen wird zunehmend auf die Web-Plattform übertragen und nutzt die Technologien, die im Internet breite Verwendung und vor allem Akzeptanz gefunden haben. So ist es heutzutage möglich, mit vergleichsweise geringem Erstellungsaufwand Berichte für das Web individuell zu gestalten. Reports, an deren Umsetzung im ERP-System Entwickler mehrere Tage beschäftigt waren, lassen sich heute durch Controller und Analytiker in wenigen Stunden erstellen und umgehend produktiv nutzen. Die Anbindung externer Daten, die Modellierung eines Analyseprozesses oder die Schaffung einer Planungsumgebung ist durch neue Softwarewerkzeuge und -technologien derart intuitiv geworden, dass sogar die gesamte Report-Entwicklung den Fachabteilungen übertragen wird. Maximale Flexibilität und geringer Erstellungsaufwand im Reporting sind die Zugpferde der BI geworden. 2.1.3.3

Planungsanwendung

Von Beginn an war die computergestützte Planung Teil der Anforderungen an ein Entscheidungsunterstützungssystem. Doch erst mit den jetzigen BI-Systemen ist es auch möglich, diese zu implementieren. So ergab eine Umfrage der deutschen SAP Anwendergruppe und des Institutes für Business Intelligence, dass hauptsächlich die Planungskomponente als nächste BI-Komponente in Zukunft realisiert werden soll (vgl. IBI 2003). Allerdings sollte beachtet werden, dass Ende 2004 noch immer circa 60% aller befragten Unternehmen weiterhin und hauptsächlich mit Hilfe von Microsoft Excel planen (vgl. IBI 2004). Die hierzu notwendigen Daten sind in ERP-Systemen verborgen und werden oft über das Data Warehouse für die Planung bereitgestellt. Auf diesen Daten werden letztendlich

Grundlagen der Business Intelligence

23

die Planungsszenarien aufgesetzt, ein Vorgang, der aufgrund der Datenmenge nicht ausschließlich manuell durchgeführt werden kann. Eine Lösung bietet hier eine Software, welche die Daten des Unternehmens verarbeitet und dem Anwender Planungsfunktionen anbietet, mit denen er ohne größeren manuellen Aufwand Plan-Werte und Szenarien aus einer Datenbasis heraus erstellten kann. Bei der Planungsanwendung muss beachtet werden, dass die Detaillierung eines Plans von der strategischen zur dispositiven Ebene zunimmt. Das TopManagement wird die strategischen Ziele in der Planung berücksichtigen und zum Beispiel Planwerte für den Absatz in einem Segment veröffentlichen, die im Vertrieb bis auf die Produktebene verteilt und damit stärker präzisiert werden. Ebenso ist das Management stärker an Simulationen interessiert als die Fachbereiche, die allerdings die Simulationsergebnisse erhalten müssen. Eine Planungsanwendung sollte daher ausreichend flexibel und doch vollkommen integriert sein, wenn sie den Anforderungen beider Anwendergruppen genügen soll (vgl. Heuser et al. 2003). 2.1.3.4

Data Mining

Der Begriff Data Mining wird übersetzt mit der Erkennung von Mustern und Regelmäßigkeiten in großen Datenbeständen. Erst mit dem Aufkommen von betrieblichen Massendaten wurden derartige Algorithmen auch für Unternehmen interessant. Daraus lassen sich zum Beispiel Entscheidungsbäume generieren, mit denen die Bonität eines Kunden aufgrund seiner Attribute wie Wohnort oder Lebensalter bewertet wird. Grundlage für die Entscheidungsregeln sind bereits gesammelte und nach Bonität klassifizierte Kundendaten. Für die Erstellung eines Data Mining Analysemodells ist ein sehr umfangreiches fachliches und technisches Expertenwissen notwendig. Das Verständnis für die Daten und deren wirtschaftliche Bedeutung für das Unternehmen entscheidet darüber, ob die Ergebnisse des Modells genau sind, oder zu Trugschlüssen führen. Zudem sollte immer mehr als ein Modell angewendet werden, um eine einseitige und damit von den Eigenschaften des Algorithmus abhängige Sichtweise zu vermeiden. 2.1.3.5

Analytische Anwendungen

Statistische Auswertungen und Kennzahlenanalysen wie die Balanced Score Card sind ein wesentlicher Faktor in der Business Intelligence. Auswertungen der Rohdaten bringen nur geringen Mehrwert und haben zumeist informativen Charakter. Erst eine analytische Aufbereitung der Daten bildet aus ihnen die Informationen heraus, die von Entscheidungsträgern verlangt werden. Die Daten im Data Warehouse bieten hervorragende Möglichkeiten für umfassende Analysen. Diese Ana-

24

Business Intelligence

lysen jedoch zu implementieren und regelmäßig zu deuten ist oftmals eine größere Herausforderung. Statistische und mathematische Verfahren finden im Zuge der Verbreitung der EDV und der stetig wachsenden elektronischen Datenmenge immer öfter Verwendung, weil sie eine zusammenfassende Sicht der Eigenschaften einer Datenmenge erlauben. Auch bündeln Kennzahlensysteme Daten zu aussagekräftigen Kennzahlen zusammen. Auf diese Weise lassen sich die großen Datenmengen mit relativ geringem Aufwand überblicken und deuten. Es darf jedoch nicht außer Acht gelassen werden, dass es sich bei analytischen Anwendungen zu einem beträchtlichen Teil um Expertensysteme handelt. Diese erfordern ein ausgeprägtes Fachwissen, das oft nur Spezialisten aufweisen können. Wenn ein Unternehmen die Absicht hat, analytische Anwendungen in der BI einzusetzen, dann muss es im Vorfeld für die notwendigen Fachkenntnisse bei den Mitarbeitern sorgen oder entsprechend ausgebildete und erfahrene Fachleute einstellen. 2.1.3.6

Operative Systeme

Als Datenquelle hinreichend bekannt sind operative Systeme auch Empfänger von Daten, wie in der Corporate Information Factory von Bill Inmon beschrieben (vgl. Inmon 2001). So lassen sich beispielsweise die durch analytische Anwendungen, durch Planungsfunktionen oder durch Data Mining generierten Daten in ein Customer Relationship Management (CRM)-System einspielen und dort im operativen Geschäft einsetzen. Dadurch kann Wissen direkt in den Geschäftsprozessen genutzt werden, was die Reaktionszeit erheblich verkürzt und Wettbewerbsvorteile schafft. Dennoch ist der so genannte „Closed-Loop Analytical Process“ mit Vorsicht zu genießen. Schleichen sich in die Auswertungsdaten unbemerkt Fehler ein, pflanzen sich diese in die Ergebnisse der analytischen Anwendungen fort und werden in das operative System eingespeist, wo der zyklische Prozess zu weiteren Fehlern führt und letztendlich das operative und das BISystem gleichzeitig zum Stillstand zwingt. Daher ist eine intensive Prüfung und Validierung, mitunter sogar eine Isolierung der zurückgeführten Daten ratsam.

2.1.4 BI-Anwender Wie aus den Kritikpunkten zum MIS zu entnehmen ist, wurde lange Zeit ein Aspekt der Systementwicklung nicht ausreichend gewürdigt: die Frage, für wen das System aufgebaut wird und wie diese Person mit dem System umzugehen gedenkt. Sind diese Fragen nicht ausreichend erörtert, schlägt ein jedes Informationssystem aufgrund falscher Annahmen in der Spezifikationsphase fehl. Es ist daher bedeutsam, insbesondere die Gruppe der Anwender zu untersuchen, wenn Business Intelligence zum Thema wird. Schon historisch bedingt hat die Business

Grundlagen der Business Intelligence

25

Intelligence einen entscheidungsorientierten Charakter. Die Aufbereitung von Daten zum Zwecke der Entscheidungsunterstützung ist nicht nur auf das TopManagement oder die Geschäftsführung beschränkt. Sie betrifft vor allem Mitarbeiter, die aufgrund der mit ihrer Tätigkeit im Unternehmen verbundenen Eigenschaften, Befugnisse und Verantwortungsbereiche als Führungskraft identifiziert werden. Nicht zu vergessen sind dabei auch die Mitarbeiter, die zwar keine Führungsaufgaben übernehmen, ihre Führungskräfte aber mit Hilfe von BI unterstützen, indem sie Entscheidungen vorbereitenden. Management oder die Führung im Unternehmen wird in einen institutionellen und einen funktionalen Begriff aufgeteilt. Der institutionelle Begriff des Managements umfasst organisatorisch die Gruppe von Führungskräften und Unternehmern, die mit Weisungs- und Entscheidungsrechten ausgestattet sind. Die funktionale Sicht ist mit dem Treffen von Führungsentscheidungen gleichzusetzen (vgl. Steinmann u. Schreyögg 1997). Führungsentscheidungen zeichnen sich durch folgende Eigenschaften aus (vgl. Gutenberg 1962):  Bedeutung für die Vermögens- und Ertragslage des Unternehmens  Besondere Verantwortung für das ganze Unternehmen  Delegierbare, aber nicht zu delegierende Entscheidungen Management umfasst dabei alle zur Bestimmung der Ziele, der Struktur und der Handlungsweisen des Unternehmens sowie zu deren Verwirklichung notwendigen Aufgaben, die nicht ausführender Art sind (vgl. Fluri u. Ulrich 1995). Ausführende Aufgaben werden dadurch abgegrenzt, dass maßgebliche Entscheidungen über die Ziele, die Maßnahmen und die zur Ausführung notwendigen Mittel bereits zuvor von Führungskräften bestimmt worden sind (vgl. Steinmann u. Schreyögg 1997). Anhand von Führungsfunktionen lassen sich die Aufgaben des Managements konkretisieren (vgl. Koontz u. O‘Donnel 1964):     

Planung Organisation / Koordination Personaleinsatz Führung Kontrolle und Steuerung

Praktisch alle Führungsaufgaben werden von der Führungskraft zu einem großen Teil in Besprechungen oder in der direkten Kommunikation mit anderen Führungskräften bzw. Untergebenen wahrgenommen. In Besprechungen selbst werden Ergebnisse diskutiert und Entscheidungen über Maßnahmen getroffen, während bei der direkten Kommunikation oft die Weitergabe von Ausführungshinweisen erfolgt (vgl. Oppelt 1995). Für den Einsatz eines betrieblichen Informationssystems sind diese vorherrschenden Bedingungen alles andere als optimal. Die Führungskraft hat fast den ganzen Tag keinen physischen Kontakt zu einem Informationssystem. Wenn Sie dennoch darauf zugreifen will, hat sie eine bestimmte Fragestellung im Kopf und erwartet eine schnelle und präzise Antwort vom System. Als Beispiel soll ein Meeting der Führungskräfte dienen, das allge-

26

Business Intelligence

meinen Charakter hat. Im Vorfeld der Besprechung hat sich jede Führungskraft von den ihr unterstellten Mitarbeitern gezielt über den zu diskutierenden Inhalt informieren lassen. In der Besprechung selbst werden die Analysen der Controller und Analytiker besprochen und Handlungsempfehlungen diskutiert. Letztendlich werden verbindliche Ziele und die Maßnahmen zur Erreichung dieser Ziele festgelegt. Anschließend werden dann die Vorgaben von der jeweils zuständigen Führungskraft an die Fachabteilung weitergereicht, wo dann die entsprechenden Maßnahmen zu veranlassen sind. Die Führungskräfte lassen sich im Nachlauf regelmäßig über den Status der Umsetzung der Maßnahmen informieren und steuern gegebenenfalls gegen. Ein betriebliches Informationssystem, das den Anforderungen der Controller oder Analysten sowie denen der Führungskräfte genügt, ist bis in die 90er Jahre hin technisch kaum realisierbar gewesen. Und so hält sich bis heute die Meinung, dass Führungskräfte nicht an der persönlichen Anwendung von BI interessiert sind, sondern dies an die ihnen unterstellten Mitarbeiter weiterleiten. Dabei kann die Wirklichkeit auch ganz anders aussehen, wie Abbildung 2.5 zeigt. Führungskräfte und Controller nutzen die BI-Systeme, um Entscheidungen durch Analysen vorzubereiten. Dabei sind Führungskräfte nicht von der Nutzung des Informationssystems ausgeschlossen, denn sie können über das Portal sofort auf StandardBerichte, OLAP- oder Ad-hoc Berichte, ein Management-Cockpit und eine Planungsanwendung zugreifen. Alle diese Elemente basieren auf der Internettechnologie und sind intuitiv zu bedienen.  Standardberichte brauchen nur angeklickt zu werden, um sie aufzurufen. Inhalte, die früher in Ordnerstrukturen auf einem Laufwerk gesichert waren, können nun direkt über das Portal aufgerufen werden  OLAP-Funktionen erfordern nicht mehr als drei Mausklicks, um zum Beispiel einen bestehenden Bericht kurzerhand umzugestalten  Das Management Cockpit bietet einen Überblick über die Kennzahlen des Unternehmens und wurde ohne enormen Anpassungsaufwand mit effizienten Technologien genau so gestaltet, wie die Führungskräfte es sich wünschen  Die Planungsanwendung ist mit wenigen, eingängigen Funktionen ausgestattet, die praktisch auf Mausklick Millionen von Datensätzen anpassen Sobald die Analysen in technisch anspruchsvollere Bereiche der BI vordringen, werden Controller und Analytiker mit diesen Aufgaben betraut. Auch sie nutzen das BI-System, um die geforderten Einschätzungen und Analysen liefern zu können. Im Gegensatz zu den Führungskräften verwenden sie nur wenige StandardReports, dafür aber mehr Ad-hoc Berichte, die Planungs- und Simulationsumgebung, Data Mining-Algorithmen sowie statistische und analytische Anwendungen. Letztendlich wird das gesamter Repertoire der BI intensiv genutzt (siehe Abb. 2.5).

Grundlagen der Business Intelligence

27

Abb. 2.5 BI-Unterstützung der Führungsaufgaben

In der Phase der Entscheidungsfindung stellen wiederum die Führungskräfte die meisten Nutzer des BI-Systems. In diesem Schritt ist es wichtig, alle relevanten Daten in Berichten verfügbar zu haben und mit Planungsanwendungen die Auswirkungen von Entscheidungen grob zu simulieren. x Führungskräfte sind bereits weitgehend mit dem BI-System vertraut, weil sie es bereits in der Vorbereitungsphase genutzt haben x Kurze Antwortzeiten des Systems und Single-Sign-On erlauben sogar den Einsatz der Systeme direkt in Besprechungen x Im Vorfeld erstellte Berichte lassen sich umgehend aufrufen und ggf. anpassen Sollte eine Bedienung der Informationssysteme nicht uneingeschränkt durch Entscheidungsträger möglich sein, dann könnten Mitarbeiter, die an der Vorbereitung

28

Business Intelligence

und Analyse des Handlungsfeldes maßgeblich mitgewirkt haben, an der Besprechung teilnehmen. Die Kontrolle und Steuerung der zur Umsetzung freigegebenen Maßnahmen übernehmen im Wesentlichen dann wieder Führungskräfte, die sich durch Standardberichte bzw. das Business Activity Monitoring selbständig über die Entwicklung informieren, sofern die Daten schon auswertbar sind. Bei Bedarf lassen sich auch statistische Auswertungen in Auftrag geben, die von den Controllern implementiert und ausgeführt werden. Die Ergebnisse lassen sich dann wiederum über das Portal und Reports den Entscheidungsträgern zur Verfügung stellen. Anwender profitieren ungemein von den neuen Technologien, die in der Business Intelligence eingesetzt werden. Aufgrund der Flexibilität der Werkzeuge zur Erstellung von Berichten lassen sich die Wünsche der Entscheidungsträger mit sehr geringem Aufwand erstellen. Die Integration innerhalb der BI fördert dabei die Akzeptanz und das Vertrauen in die Softwarewerkzeuge.

2.2

Informationsmanagement

Wichtige Voraussetzung für eine erfolgreiche BI-Einführung, den Betrieb der technischen Basis oder die Weiterentwicklung der in der Business Intelligence eingesetzten Informationssysteme ist ein wirksames Informationsmanagement (IM). Jede Entscheidungsabsicht bezüglich Business Intelligence ist direkt an das Informationsmanagement adressiert, denn hier liegt die Kompetenz und Verantwortung für die Informationssysteme des gesamten Unternehmens, zusammengefasst die Informationssystemarchitektur. Nach Heinrich ist das Informationsmanagement das „Leitungshandeln in einer Betriebswirtschaft bezogen auf Information und Kommunikation, deren Aufgaben zusammengefasst als Informationsfunktion bezeichnet werden“ (vgl. Heinrich 2005). Entscheidungen in Bezug auf die Business Intelligence werden daher primär durch das Informationsmanagement getroffen. Angeregt werden die Entscheidungen nicht ausschließlich durch das IM, sondern auch von den „Kunden“ der IT, den Fachabteilungen und der Geschäftsleitung. Wie andere Abteilungen auch muss sich das Informationsmanagement mit den strategischen Zielen des gesamten Unternehmens auseinandersetzen, wenn es die eigenen Handlungsalternativen bewertet. Dieser Sachverhalt wird in den Sachzielen des IM deutlich. Generelles Sachziel des Informationsmanagements ist es, das Leistungspotenzial der Informationsfunktion für die Erreichung der strategischen Unternehmensziele durch Schaffung und die Aufrechterhaltung einer geeigneten Informationsinfrastruktur in Unternehmenserfolg umzusetzen (Heinrich 2005).

Informationsmanagement

29

In der Regel wird auch das Informationsmanagement durch zeitlich und finanziell eingeschränkte Ressourcen dazu gezwungen, Aufgaben wirksam und effizient umzusetzen. Die Verantwortung des Top-Managements für das Informationsmanagement ist nicht ohne Grund entstanden. Einer aktuellen Studie von Capgemini zufolge werden bei 94% aller IT-Projekte das Budget überschritten, bei 97% die Laufzeit (vgl. Capgemini 2008). Bei geschäftskritischen IT-Projekten sind die Kennzahlen nicht wesentlich besser: 80% der Projekte haben die vorgegebene Zeit nicht eingehalten, 88% das Budget nicht. Dabei existieren die Formalziele des Informationsmanagements schon seit Beginn der Disziplin (vgl. Heinrich 2005). Krcmar ergänzt diese in einer Definition der Aufgaben im Informationsmanagement. Eine der wesentlichen Aufgaben des Informationsmanagements ist es, die erforderlichen Informationen zur richtigen Zeit und im richtigen Format zum Entscheider zu bringen. Ein Informationsmanager ist verantwortlich für die effiziente, effektive und ökonomische Behandlung aller Informationen und Informationswerkzeuge der Organisation (vgl. Krcmar 2004). Zur Erreichung der Sach- und Formalziele verfolgt das Informationsmanagement einen ganzheitlichen Ansatz. Schließlich ist es als Querschnittsfunktion für die Information und Kommunikation sowie die Informationssysteme der Informationsinfrastruktur und deren Zusammenarbeit untereinander des gesamten Unternehmens zuständig. Die Methodik des Informationsmanagements wird daher durch ganzheitliches Denken charakterisiert (vgl. Heinrich 2005).  Das Systemdenken befasst sich mit den Elementen der Informationsfunktion und der Informationsinfrastruktur sowie deren Beziehung untereinander  Indem an den Nutzen eines Informationssystems gedacht wird, kann der Beitrag der Informationsfunktion und der Informationsinfrastruktur zum Unternehmenserfolg berücksichtigt werden. Damit der Nutzen aus der Informationsfunktion und der Informationsinfrastruktur nicht unwirtschaftlich ist, gibt es das Wirtschaftlichkeitsdenken  Qualitätsdenken sichert die inhaltliche, zeitliche und örtliche Informationsversorgung  Durch Prozessdenken kann den Geschäftsprozessen Rechnung getragen werden

30

Business Intelligence

2.2.1 Konzeption und Steuerung der IT-Systemlandschaft Um den Anforderungen des Unternehmens an die Informationsinfrastruktur und der Bedeutung der Informationsfunktion gerecht zu werden, begleitet das IM deren Umsetzung von Beginn an. Dieser Ansatz ist notwendig, um schon so frühzeitig wie möglich Einfluss auf die Informationsinfrastruktur zu nehmen. Wenn kritische Entscheidungen zum Informationsmanagement von der Unternehmensleitung bereits getroffen worden sind, ist es sehr mühsam, diese rückgängig zu machen. Die Kanalisierung und Beschränkung der Top-Down Einflüsse ist jedoch nicht ausreichend. Das Informationsmanagement muss auch darum bemüht sein, die Umsetzung der beschlossenen Maßnahmen am Ende der Entscheidungskette sicherzustellen. Hier sind Eingriffe in das Projektmanagement ebenso erforderlich wie eine gezielte Betreuung der Anwender. Aufgrund dessen ist das Informationsmanagement nicht nur als Querschnittsfunktion zu sehen. Es hat zudem eine große vertikale Tiefe, die alle Entscheidungsebenen abdecken muss und die Verantwortung für die Umsetzung der Maßnahmen auf jeder Ebene übernimmt. Im Rahmen der Implementierung ergeben sich von der Analyse und strategischen Planung der Informationsinfrastruktur bis zur Abnahme der Entwicklung durch den Fachbereich verschiedene Aufgaben, die mehreren Ebenen zugeordnet werden (vgl. Heinrich 2005). Der Sachverhalt lässt sich aus der Abbildung 2.6 entnehmen.  Die strategische Aufgabenebene befasst sich mit der Planung, Überwachung und Steuerung der Informationsinfrastruktur als Ganzes und legt langfristig wirksame und bindende Vorgaben für nachgeordnete Aufgabenebenen fest. Nach Abschluss der strategischen Aufgaben ergeben sich eine Architektur der Informationsinfrastruktur und ein strategisches Projektportfolio, das laufend aktualisiert wird.  In der administrativen Aufgabenebene werden alle Komponenten der Informationsinfrastruktur geplant, überwacht und gesteuert, wodurch sie weniger abstrahiert als die strategische Ebene. In der Regel handelt es sich bei administrativen Aufgaben um die Vorbereitung und Ausführung von (IT-) Projekten, die dafür sorgen, dass die vom Unternehmen benötigten Systeme und Methoden bereitstehen, um das operative Geschäft zu unterstützen.  Auf der operativen Ebene fallen alle Aufgaben an, die mit der Nutzung der Informationsinfrastruktur verbunden sind. Nutzung ist oft gleichzusetzen mit der Schaffung, Verbreitung und Verwendung von Information.

Informationsmanagement

31

Abb. 2.6 Strategisches Informationsmanagement (vgl. Heinrich 2005)

2.2.2 Analyse der Informationsinfrastruktur Das Informationsmanagement ist als Dienstleister für andere Abteilungen tätig, indem es leitend ein Erfolgspotential in den betrieblichen Informationssystemen erschafft und anschließend das Leistungspotential zur Erreichung der strategischen Unternehmensziele bestimmt. Dieses gibt Aufschluss darüber, welchen Beitrag die Informationsfunktion zum Unternehmenserfolg gegenwärtig leistet und zukünftig leisten kann. Wie hoch dieser Beitrag der Informationsfunktion zum Unternehmenserfolg gegenwärtig ist, bestimmt die strategische Situationsanalyse. Erst wenn bekannt ist, welche Bedeutung der Informationsfunktion im Unternehmen zukommt und in welcher Verfassung sich die Informationsinfrastruktur eines Unternehmens befindet, lassen sich alle weiteren Schritte zur Verbesserung der Wettbewerbssituation unternehmen (vgl. Heinrich 2005).

32

Business Intelligence

Die gegenwärtige und zukünftige Bedeutung der Informationsfunktion für das Unternehmen wird in ihrer strategischen Rolle beschrieben. Sie kann in einer Matrix wie in Abbildung 2.7 dargestellt werden. Dient die Informationsfunktion dem Unternehmen nur als Werkzeug für alltäglich anfallende, geringwertige Arbeiten und hat sie kaum das Potential, um in der Zukunft stärker in die Wertschöpfung des Unternehmens einzugreifen, so wird von einer reinen Unterstützung der Geschäftsabläufe gesprochen. Das Informationsmanagement hat in dieser Situation nur administrative Aufgaben und bemüht sich in der Regel um das Lösen von Anwenderproblemen (vgl. Heinrich 2005). Stuft ein Unternehmen das gegenwärtige Leistungspotential der Informationsfunktion als hoch ein, so nutzt es diese sehr stark, um am Markt erfolgreich zu sein. In diesem Fall kann zum Beispiel ein ERP-System im Einsatz sein, welches das Unternehmen bei seinen Geschäftsprozessen unterstützt und damit erheblich zur Wertschöpfung beiträgt. Ein Verzicht auf die Informationssysteme ist für das Unternehmen gegenwärtig nicht im Geringsten tragbar. Jedoch kann es sein, dass die Informationsfunktion zukünftig nicht mehr in diesem Maße für das Unternehmen bedeutsam sein wird, weil zum Beispiel ein Bereich aus dem Unternehmen ausgegliedert werden soll. Die Rolle der Informationsfunktion wird dann als Fabrik bezeichnet, in der das Informationsmanagement für Wartung und Pflege sowie mit dem Betrieb verbundene administrative Aufgaben zuständig ist (vgl. Heinrich 2005). Im umgekehrten Fall steht die Informationsfunktion vor dem Durchbruch. Gegenwärtig wird sie zwar als nicht besonders wettbewerbsrelevant bezeichnet, für die Zukunft wird ihr jedoch ein viel höheres Leistungspotential prognostiziert. So kann zum Beispiel eine Veränderung der Marktsituation dazu führen, dass die Informationsfunktion für einen ganzen Geschäftszweig an Bedeutung gewinnt. Dies träfe dann zu, wenn beispielsweise Filial-Apotheken einen Online-Versand der Medikamente einführten, um gegen reine Online-Apotheken zu bestehen. Das Informationsmanagement hat an dieser Stelle eine strategische Bedeutung, nimmt gleichzeitig aber noch administrative Aufgaben wahr (vgl. Heinrich 2005). Zu einer Waffe wird die Informationsfunktion, wenn sie gegenwärtig und zukünftig eine hohe Bedeutung für das Unternehmen aufweisen kann. Unternehmensziele können in diesem Fall ohne das Informationsmanagement nicht realisiert werden. Dieser Fall kann zum Beispiel in einem Dienstleistungsunternehmen auftreten, einer Versicherungsgesellschaft beispielsweise. Ohne Informationsfunktion kann eine solches Unternehmen nicht bestehen, das Leistungspotential ist immens. Das Informationsmanagement hat dafür zu sorgen, dass die Strategie optimal ist, die Informationsinfrastruktur kontinuierlich weiterentwickelt und gepflegt sowie die Nutzung der Informationen gesichert wird (vgl. Heinrich 2005).

Informationsmanagement

33

Abb. 2.7 Strategische Rolle der Informationsfunktion (vgl. Heinrich 2005)

Neben der Bestimmung der strategischen Rolle der Informationsfunktion muss auch ihre Beziehung zur Informationsinfrastruktur bewertet werden, zusammenfassend strategische Schlagkraft genannt. Vor dem Hintergrund der Formalziele des Informationsmanagements werden die Wirksamkeit und die Wirtschaftlichkeit der Informationsinfrastruktur abgebildet. Die Wirksamkeit bezieht sich auf den Nutzungsgrad des Leistungspotentials der Informationsfunktion, die WirtschaftWirtschaf lichkeit auf den damit verbundenen monetären und zeitlichen Aufwand. Abbildung 2.8 verdeutlicht die strategische Schlagkraft in einer Matrix. Die Informationsinfrastruktur eines Unternehmens steckt in einer gravierenden Krise, wenn sowohl die Nutzung des Leistungspotentials der Informationsfunktion als auch die Wirtschaftlichkeit der Informationsinfrastruktur gering sind. In diesem Fall ist das eingesetzte Informationssystem nicht zweckmäßig und in Verbindung dazu noch teuer in Anschaffung und Betrieb. Bei einem solchen Zustand war das Informationsmanagement im Unternehmen in der Regel bis dato nicht existent und es hat keine verantwortungsvolle Steuerung der IT stattgefunden, so dass eine strategische Überdehnung eingetreten t treten ist. Sind sowohl der Aufwand für die Anschaffung, die Entwicklung und den Betrieb der Informationssysteme aber auch die Wirksamkeit gering, dann ist der Begriff der strategischen Vergeudung angebracht. Obwohl das Unternehmen starke Unterstützung durch die Informationsinfrastruktur erwartet, wird das Leistungspotential der Informationsfunktion nicht ausreichend ausgeschöpft. Allerdings wird die geringe Ausnutzung mit einer hohen Wirtschaftlichkeit erreicht. Verursacht worden kann dieser Zustand dadurch sein, dass dem Informationsmanagement nur

34

Business Intelligence

geringe finanzielle Mittel bereitgestellt worden sind. Die zur Verfügung stehenden Ressourcen wurden so gut wie möglich eingesetzt, jedoch reichten sie nicht aus, um die geforderte Leistung zu erbringen. Unter Umständen wäre jedoch ein professionelles Informationsmanagement in der Lage gewesen, auch bei geringem Budget eine höhere Leistung zu erzielen. Die Anforderungen an das Informationsmanagement sind in dieser Situation sehr hoch. Wie bei der strategischen Rolle der Informationsfunktion kann sich auch bei der strategischen Schlagkraft die entgegengesetzte Konstellation ergeben, in der das Leistungspotential zwar hervorragend genutzt wird, dies jedoch mit erheblichen Kosten verbunden ist. Im Vergleich mit den anderen Ungleichgewichten ist dies die am besten zu bewältigende Situation, weil das Informationsmanagement des Unternehmens wahrscheinlich noch in der Lage ist, zu reagieren. Das Leistungspotential der Informationsfunktion wurde erkannt und umgesetzt, der Fortbestand des Unternehmens ist damit zunächst gesichert. In den anderen Ungleichgewichten ist aufgrund der geringen Wirksamkeit der Informationsinfrastruktur die unternehmerische Tätigkeit stark gefährdet, bei der strategischen Verschwendung ist, relativ zu den andern Gefahren, im schlimmsten Fall lediglich die finanzielle Situation des Unternehmens angespannt. Befinden sich die Informationsfunktion und die Informationsinfrastruktur im strategischen Gleichgewicht, wird die Informationsinfrastruktur hochgradig wirksam und kostenminimal eingesetzt. Das Informationsmanagement muss dafür Sorge tragen, dass dieser Zustand in der Zukunft gehalten wird.

Abb. 2.8 Strategische Schlagkraft der Informationsinfrastruktur (vgl. Heinrich 2005)

Informationsmanagement

35

2.2.3 Planung der Informationsinfrastruktur Hat das Informationsmanagement die Situationsanalyse abgeschlossen und damit den Ist-Zustand der Informationsfunktion und der Informationsinfrastruktur bestimmt, kann es sich der strategischen Zielplanung für die Informationsinfrastruktur widmen. Empfohlen wird hierfür der interagierende Ansatz, bei dem zunächst die strategischen Ziele der Informationsinfrastruktur gebildet und anschließend mit den strategischen Unternehmenszielen abgestimmt werden, wobei die Unternehmensziele im Falle von Zielkonflikten ausschlaggebend sind. Bei der Harmonisierung der Ziele werden die strategischen Unternehmensziele bestimmt, welche die kritischen Wettbewerbsfaktoren beeinflussen. Anschließend wird ermittelt, welche der Ziele vom Leistungspotential der Informationsfunktion profitieren. Auf dieser Grundlage lässt sich schließlich das Erfolgspotential der Informationsinfrastruktur zur Umsetzung des Leistungspotentials der Informationsfunktion erarbeiten, das mit dem Soll-Zustand gleichzusetzen ist (vgl. Heinrich 2005). Diesen Prozess stellt Abbildung 2.9 grafisch dar. Sind Ist- und Soll-Zustand bekannt, lassen sich Strategien formulieren, um die Art und Weise der Umsetzung durch Leitlinien zu bestimmen. Eine InformatikStrategie bezeichnet das Konzept, die Perspektive oder die Art und Weise, wie strategische Maßnahmen zur Erreichung der strategischen Informatik-Ziele umgesetzt werden sollen (vgl. Heinrich 2005). Damit wird der Handlungsspielraum für den Entscheidungsträger durch die Brückenfunktion der Informatikstrategie zwischen Zielen und Maßnahmen festgelegt. Die Informatik-Strategie wirkt auf verschiedene Komponenten der Informationsinfrastruktur und unterscheidet sich zusätzlich durch ihren Charakter.  Eine defensive Strategie reduziert den Einfluss der IT auf das Unternehmen  Die Momentum-Strategie verändert die gegenwärtige Systemausstattung nicht  Die moderate Strategie traut sich im Vergleich zur Momentum-Strategie immerhin Pilotprojekte auf Basis strategischer Situationsanalysen zu  Eine aggressive Strategie setzt stets die neuesten Systementwicklungen ein Zu Beginn werden verschiedene Strategien entwickelt und miteinander verglichen, um diejenige Strategie mit dem größten Nutzen für die Zielerreichung zu bestimmen. Wurde die optimale Strategie identifiziert, hat sie mit der Unternehmens-, und besonders mit der Wettbewerbsstrategie noch abgeglichen zu werden, obwohl bereits durch eine Harmonisierung der strategischen Ziele Abweichungen mit der Unternehmensstrategie minimiert worden sind. Dennoch können sich Unterschiede in den Strategien ergeben, die möglichst zu vermeiden sind. Abschließend lassen sich aus der globalen Informatikstrategie Teil-Strategien ableiten, die präziser auf bestimmte Komponenten der Informationsinfrastruktur ausgerichtet sind (vgl. Heinrich 2005).

36

Business Intelligence

Abb. 2.9 Bestimmen einer Informatikstrategie

Anhand der Leitlinien der Informatikstrategie lassen sich strategische Maßnahmen planen, um mit deren Hilfe den Soll-Zustand in der Informationsinfrastruktur zu erreichen. Oftmals sind mehrere verschiedene Maßnahmen erforderlich, da es zu einer Informatikstrategie einen Gesamtplan und mehrere Teilpläne geben kann. Um die Informationsinfrastrukt Informationsinfrastruktur insgesamt zu planen, wird die strategische Infrastrukturplanung eingesetzt. Diese erfüllt die Rolle eines Technologieinnovators, der die gesamte Informationsinfrastruktur mit neuen Impulsen versorgt und so eine Nachfrage nach neuen Lösungen wecken kann. Eine auf die Komponenten einer Inf Informationsinfrastruktur bezogene Planung erfolgt durch die Informationssystemplanung. Diese untersucht und bewertet den Bestand an Informationssystemen, erörtert Verbesserungen und prüft Projektideen zur Weiterentwicklung oder Einführung von Informationssystemen (vgl. Heinrich 2005). Für beide Planungsaufgaben gilt die gleiche Vorgehensweise. Zunächst werden mit den Ergebnissen der strategischen Situationsanalyse strategische Lücken in der Informationsinfrastruktur identifiziert. Sind die Schwächen bekannt, lassen sich Projektideen entwerfen, um diese Lücken zu schließen. Die Ideen werden in der Projektplanung konkretisiert und damit bewertbar gemacht. Diejenigen Projekte, die der Bewertung standhalten, werden in das strategische Projektportfolio übernommen. r rnommen. Der fortgeführte Prozess ist in Abbildung 2.10 dargestellt.

Informationsmanagement

37

Abb. 2.10 Erarbeiten eines strategischen Projektportfolios

2.2.4 Projektmanagement Mit dem strategischen Projektportfolio beginnt die Umsetzung der strategischen Maßnahmen in Form von Projekten. Besonderes Augenmerk soll an dieser Stelle auf Projekte im BI-Umfeld geworfen werden, weil diese sich von anderen ITProjekten unterscheiden. Projektmanagement-Methoden, Organisationsformen, Projekt- und Notfallpläne sind weitgehend identisch mit anderen IT-Projekten. Doch in der Konzeptionsphase, also dem Punkt im Projekt, an dem weichenstellende Entscheidungen für die Realisierung getroffen werden, sind wesentliche Unterschiede zu verzeichnen. Während sich viele IT-Projekte auf Erfahrungswerte aus ähnlichen Projekten, auf gesetzliche Bestimmungen oder auf technische Vorgaben stützen können, kann ein BI-Projekt zunächst nur wenig mehr als die Informationssysteme, grobe Anforderungen des Kunden und ein Projektteam samt Budget und Zeitvorgabe vorweisen. Das Fachkonzept oder Pflichtenheft eines BIProjektes ist oftmals nur sehr vage formuliert und verändert sich laufend. Dieser ÄJUQH:LHVH³-Ansatz hat zur Konsequenz, dass ein BI-Projekt hochgradig dynamisch ist und zeitlich unbeschränkt sein kann, weil es während der Durchführung oft angepasst wird. Das BI-System erreicht selten langfristig einen abgeschlossenen Grad der Fertigstellung, sondern befindet sich in einer stetigen (Weiter-) Entwicklung (vgl. BARC 2005).

38

Business Intelligence

Die Ursache für häufig unzureichend definierte Anforderungen des Kunden liegt darin begründet, dass es einfach zu viele Optionen gibt. So lassen sich allein für den HR-Bereich mehr als 250 Kennzahlen definieren (vgl. DGFP 2008). Zudem hat die Business Intelligence eines Unternehmens selten Vorbilder, sie ist hochgradig individuell und muss in ihrer ganzen Komplexität bis ins kleinste Detail verstanden werden. Oft liegt auch gerade in der BI einer der wertvollsten Wettbewerbsvorteile, nämlich die Kunst, richtige Entscheidungen umfassend vorzubereiten und dann auf Grundlage der Informationen zu treffen. Die Konzeptionsphase in einem BI-Projekt ist daher durch mehrere Faktoren besonders gekennzeichnet.  Anforderungen des Kunden an das neue Berichtswesen / die BI sind höchst individuell und müssen trotz ihrer Komplexität verständlich definiert werden  Erfahrungswerte aus vorhergehenden Projekten sind nur bedingt einsetzbar  Alte Berichte sollen mit dem neuen BI-System weiterhin realisierbar sein  In den alten Berichten enthaltene Fehler oder Besonderheiten tauchen erst im Rahmen der Neuimplementierung auf und müssen oft kurzfristig gelöst werden  Für Neuentwicklungen liegen nur oberflächlich ausgearbeitete Konzepte vor  Ressourcen im Fachbereich sind knapp bemessen, so dass eine tiefgreifende fachliche Analyse des alten Berichtswesens und der neuen Anforderungen oft nicht durchführbar ist  BI-Fachwissen ist im Fachbereich teilweise nicht vorhanden (z.B. Data Mining), dennoch werden entsprechende Konzepte verlangt Unklare Anforderungen sind nicht die einzige Ursache für regelmäßig auftretenden Änderungen im BI-Projekt. Ein weiterer Grund für die Unstetigkeit ist das Projektmodell, das meistens dem Spiralmodell ähnelt. BI-Projekte werden nicht als eine Einheit zur Abnahme freigegeben, sondern in Teilen fertiggestellt. Das ist auch dadurch begründet, dass die Vorgaben zu Beginn des Projektes nur vage sind und dem Kunden die Möglichkeit gegeben werden muss, sich mit dem neuen System und seinen umgesetzten Anforderungen vertraut zu machen. Aus den Erfahrungen eines Teilprojektes ziehen alle nachfolgenden Teilprojekte Nutzen, denn die Vorstellungen des Kunden werden stetig präziser. So ist es nicht verwunderlich, wenn der Kunde zumeist schon einen Teil der Entwicklungen produktiv einsetzt, während ein anderer Teil sich noch in der Umsetzung befindet. Dies ist oft ohne weiteres möglich, weil die Abhängigkeiten in den Teilprojekten meist gering sind (vgl. Kemper et al. 2004). Einen Ausweg aus diesem Konflikt hat Chen (vgl. Chen 2008) mit der BIRoadmap erarbeitet (siehe Abb. 2.11). Neben der Forderung nach einem sehr gut ausgebildeten Projektteam, das technisch und fachlich hochgradig versiert sein sollte, werden der Einsatz eines Prototyps und parallele Entwicklungstätigkeit vorgeschlagen. Durch ein entsprechend gut zusammengestelltes und vorbereitetes Projektteam lassen sich fachliche Unklarheiten wirksam vermeiden. So können die Projektmitglieder unterschiedliche Rollen im Projekt übernehmen, wodurch sich die Fluktuation im Projekt reduziert. Ein Prototyp gibt allen Projektteilnehmern die Möglichkeit, die Anforderungen an das BI-System zu präzisieren, bevor das

Informationsmanagement

39

Hauptsystem implementiert wird. Auf diese Weise lassen sich im Vorfeld verschiedene Zustände evaluieren und Annahmen auf ihre Gültigkeit überprüfen. Paralleles Arbeiten im Projekt schafft ein Potential zur Reduzierung der Gesamtprojektlaufzeit, indem Aufgaben gleichzeitig ausgeführt werden, die keine oder nur sehr geringe Abhängigkeiten aufweisen. So kann zum Beispiel die Berichtsgestaltung im Portal bereits realisiert werden, während gleichzeitig noch das Datenmodell ergänzt wird. Ein BI-Projekt kann durchaus erfolgreich durchgeführt werden, wenn auf die Besonderheiten Rücksicht genommen wird.

Abb. 2.11 BI-Projektphasen (vgl. Chen 2008)

Der allgemein beschriebene Ablauf eines BI-Projektes wird in Anlehnung an Chen zusammengefasst (vgl. Chen 2008). Ein BI-Projekt beginnt mit der Studie des durch das Informationsmanagement freigegeben Projektantrages. Darauf aufbauend wird eine Machbarkeitsstudie durchgeführt, um die Rahmenparameter, wie Budget und Aufwand, festzulegen und mögliche technische oder rechtliche Restriktionen zu prüfen sowie Chancen und Risiken genauer abzuschätzen. Sind die Voraussetzungen für ein erfolgreiches Projekt gegeben, so wird das Projektteam gebildet, der Projektplan erstellt und die Projektarbeit offiziell mit einem Kick-off Meeting begonnen. Die wichtigste Phase in einem BI-Projekt ist die Business Analyse, denn hier werden die Weichen für das gesamte Projekt gestellt. Einer Anforderungsanalyse folgt der Abgleich mit dem vom BI-Softwareanbieter bereitgestellten Standard. Daraufhin wird ein erstes Datenmodell mit entsprechenden Datenflüssen konzipiert und in einem Prototyp umgesetzt. Der Prototyp dient dazu, die Entwicklungsrichtung zu prüfen und letztlich zu zementieren. Aus ihm werden wesentliche Erkenntnisse für das gesamte Projekt abgeleitet, daher kommt einer

40

Business Intelligence

Bewertung der Anforderungen und des Prototyps eine projektkritische Bedeutung zu. Aus dem Abgleich zwischen den Anforderungen und der Bewertung des Prototyps lässt sich das abschließende Konzept für das BI-System erarbeiten. Zusätzlich werden die Projektteammitglieder geschult, um Schwächen im Fachwissen oder technischen Verständnis vorzubeugen. Wenn die Konzeptionsphase abgeschlossen ist, werden die BI-Systeme konfiguriert und es wird mit der Umsetzung in Form eines Teilprojekts begonnen. Die einzelnen Teilprojekte werden vom Auftraggeber intensiv getestet, wobei das Projektcontrolling darauf zu achten hat, dass die Anforderungen keinen projektkritischen Änderungen unterzogen werden. Ist ein Teilprojekt abgeschlossen, wird die Produktivsetzung der Systeme vorbereitet. Dazu zählt die Untersuchung der Performance, die gegebenenfalls verbessert wird. Die Maßnahmen können dabei von der Parameterjustierung der BISoftware bis zu Anpassungen der Hardware reichen. Gleichzeitig werden die Anwender mit Schulungen auf den Einsatz des BI-Systems vorbereitet und es wird ein Help-Desk im Unternehmen eingerichtet, um den Anwendern eine geeignete Unterstützung anzubieten. Beim produktiven Einsatz des gesamten BI-Systems wird das Projekt bewertet und abgeschlossen. Dabei wird die Wartung in der ersten Zeit sehr intensiv betrieben, um auftretende Schwächen unverzüglich zu beseitigen. Ziel ist die reibungslose Überführung des gesamten BI-Systems in die Produktion und die Erreichung einer möglichst hohen Akzeptanz durch die Anwender. Wenn das Einführungsprojekt abgeschlossen ist, wird die Wartung mit den Anforderungen abgestimmt. In der Regel werden umgehend Folgeprojekte initiiert, da sich schon innerhalb kürzester Zeit bei den Anwendern neue Anforderungen ergeben. Die Anforderungen lassen sich gliedern und durch den Einsatz von KeyUsern, intensiver ausgebildeten Anwendern mit umfangreichen Kenntnissen im Reporting-Bereich, oft zu einem großen Teil erfüllen, ohne dass ein umfangreiches Projekt beantragt werden muss. Für anspruchsvolle Anforderungen sollte ein neues Projekt initiiert werden.

2.3

Business Intelligence mit SAP NetWeaver 7.0

Mit der Integrationsplattform SAP NetWeaver 7.0 bietet die SAP AG verschiedene Applikationen an, die zur Zusammenführung und Auswertung der Daten, Informationen und des Wissens im Unternehmen dienen. Gleichzeitig vernetzt SAP NetWeaver 7.0 die Anwender mit den Daten, um das im Unternehmen verborgene Erfolgspotential aus Daten und Mitarbeitern zugänglich zu machen. Zur Wertschöpfung gehört letztendlich auch die Verknüpfung von Anwendern und Daten mit den Anwendungen, die nahtlos mit verschiedenen Applikationen verbunden werden können. Die Ablaufsteuerung wird durch die Prozessunterstützung sichergestellt.

Business Intelligence mit SAP NetWeaver 7.0

41

Integration der Personen Der Bereich People Integration in SAP NetWeaver 7.0 ist geprägt von der Zusammenführung der Anwender. Hauptaugenmerk liegt auf dem SAP NetWeaver Portal, das Inhalte und Anwendungen für Anwender in einer zentralen Oberfläche bündelt und Funktionen zur Zusammenarbeit und Kommunikation mit anderen Anwendern zur Verfügung stellt. Neben der Web-Oberfläche bietet der SAP NetWeaver Business Client dem Anwender eine dem vertrauten Desktop nachempfundene Sicht auf die Inhalte der Portals und Applikationen, die als sogenannter WebDynpro auf SAP Systemen ausgeführt werden. Die als Transaktion bekannten SAP Programme sind so auch in der neuen Oberfläche des Portals nutzbar. Die Integration der Personen erfolgt auch durch die Unterstützung verschiedener Endgeräte. Synchronisation von Daten und die Kommunikation mit dem SAP NetWeaver 7.0 über verschiedene mobile Endgeräte sind besonders bei Arbeitsplätzen außerhalb des Büros sehr hilfreich. Zusammenarbeit ist ein Erfolgsfaktor des Personals, der aufgrund der forcierten Arbeitsteilung und gleichzeitigen hohen Mitarbeiterqualifikation zunehmend ein K.O.-Kriterium im Unternehmen darstellt. Ohne Zusammenarbeit stocken die Geschäftsprozesse, Ressourcen werden vergeudet und Unsicherheit schleicht sich in auf allen Ebenen des Unternehmens ein. Um die Zusammenarbeit der Angestellten zu fördern, bietet SAP NetWeaver 7.0 spezielle Funktionen an. Virtuelle Teamräume, in denen sich Mitarbeiter zusammenfinden und in Echtzeit miteinander kommunizieren, Dateien und Anwendungen für den gemeinsamen Zugriff ablegen können, sind eine enorme Stütze bei räumlich verteilt angeordneten Teammitgliedern. Ist das Team über Zeitzonen hinweg zusammengestellt worden, so kann durch Online-Foren, Sofortnachrichten und die Integration von Groupware zeitversetzt kommuniziert werden. Informationsintegration Grundlage für alle betrieblichen Aufgaben sind die zu ihrer Erfüllung notwendigen Daten. Um dem Anwender alle benötigten Daten zur Verfügung zu stellen, müssen sie aus oftmals unterschiedlichen Datenquellen bezogen, integriert und konsolidiert werden. Nur so lassen sie sich in Analysen einsetzen, die unternehmensweite Zusammenhänge abbilden. Der Informationintegration ist der Teilbereich Business Intelligence zugeordnet. Analysen auf integrierten Daten zur Entscheidungsunterstützung sind der Kern der Business Intelligence. Neben den Berichten auf historischen Daten ist auch die Erstellung von Plandaten und Planungsszenarien Teil der Business Intelligence. Der Business Content bietet für die Entwicklung von Datenmodellen, Berichten und weiteren Komponenten des Data Warehousing bereits vorgefertigte Objekte, die zumindest die Grundfunktionen bereitstellen, um BI zu betreiben. Sie lassen

42

Business Intelligence

sich auch hervorragend als Schablone nutzen, um kundenindividuelle Entwicklungen zu beschleunigen. Das Stammdatenmanagement sorgt für konsistente Stammdaten in allen Systemen des Unternehmens und fördert die Einhaltung von Standards. Auf diese Weise ist die Verknüpfung der Daten im Unternehmen leichter zu bewältigen, denn die wesentlichen Strukturen sind gefestigt und müssen nicht auf einer höheren Ebene erst noch bewerkstelligt werden. Zur Informationsintegration zählt unter SAP NetWeaver 7.0 auch das Wissensmanagement. Es ist stark an das SAP NetWeaver Portal gekoppelt, mit dessen Hilfe unstrukturierte Daten in Form von Dokumenten in das System geladen und aus ihm abgerufen werden können. Zudem ist die Bildung eines Diskussionsforums vorgesehen, über das die Anwender ihr Wissen austauschen können. Neben dem Check-In und Check-Out von Dokumenten und ihrer Versionierung bzw. Verteilung ist vor allem auch die Suche danach eine wesentliche Funktion des Knowledge Management, welche die TREX-Engine übernimmt. Durch Klassifikation von Dokumenten und den Aufbau von Taxonomien sind gängige Techniken des Wissensmanagements einsetzbar, die einer breiten und intensiven Nutzung des kodierten Wissens dienlich sind. Prozessintegration In der Vergangenheit hat die serviceorientierte Architektur bei der Anwendungsprogrammierung einen Durchbruch erzielt und hat sich in den Programmiertechniken etabliert. Der Datenaustausch über Dienste ist vorteilhaft, weil Schnittstellen nicht mehr ein notwendiges Übel darstellen, sondern von Beginn der Anwendungsentwicklung an gewollt sind. Programmmodule sind offen im Unternehmen zugänglich und nicht mehr auf ein System beschränkt. Die Übertragung von Daten über XML-Streams und die Bereitstellung von Diensten ist ein Paradigma, das durch den Integration Broker des SAP NetWeaver 7.0 gefördert wird. Prozesse sind nicht nur auf der interoperablen Ebene der Anwendungen zu suchen, sie existieren auch innerhalb der Programme als Teile von Geschäftsprozessen. Um die Ablaufsteuerung der Prozesse zu implementieren, wird das Business Process Management genutzt. Es bietet mit dem SAP Business Workflow, der Steuerung von Integrationsprozessen und der Steuerung von Ad-hoc Workflows über die Universal Worklist (UWL) des Portals die Möglichkeit zur Steuerung und Kontrolle der Geschäftsprozesse unter SAP NetWeaver 7.0. Anwendungsplattform Ohne Programme ist auch SAP NetWeaver nur eine leere Hülle. Die SAP bietet den Entwicklern zwei Programmiersprachen an: die Advanced Business Application Programming Sprache ABAP/4 und die von Sun entwickelte Programmier-

Business Intelligence mit SAP NetWeaver 7.0

43

sprache Java als Java 2 Enterprise Edition (J2EE). Beide werden im Rahmen von SAP NetWeaver 7.0 eingesetzt. Während JAVA vor allem im Portal eine Rolle spielt, ist ABAP im Data Warehousing und der Arbeit mit Datenbanken anzutreffen. Zusätzlich zu diesen beiden Programmiersprachen wird der Einsatz von Services unterstützt. Neben bereits voreingestellten Business Services kann der Entwickler auch individuelle Dienste in der SAP NetWeaver 7.0 Landschaft publizieren, die sich breit nutzen lassen. Dabei kann der Entwickler auch hier auf bereits bestehende Dienste zugreifen. Composite Application Framework Um aus den einzelnen Modulen eine funktionierende Einheit zu bilden, werden mit dem Composite Application Framework Methoden und Entwicklerwerkzeuge bereitgestellt. Mit diesen ist die Entwicklung von Services, Applikationen, Benutzerschnittstellen und Workflows innerhalb der SAP NetWeaver 7.0 Platform. Solution Life Cycle Management Wie andere Software aus dem SAP-Portfolio ist auch SAP NetWeaver 7.0 von regelmäßigen Updates und Releasewechseln in anderen SAP-Modulen betroffen. Das Solution Life Cycle Management beinhaltet verschiedene Werkzeuge, die mit der Steuerung der Softwareaktualisierung und der Anpassung der Standardeinstellungen und der Problemanalyse betraut sind. Mit dem SAP Solution Manager und dem SAP NetWeaver Administrator sind die beiden zentralen Werkzeuge für die Softwarewartung benannt. Verknüpfung von Business Intelligence und SAP NetWeaver 7.0 Weil sich die von der SAP vorgenommene Einteilung der Schlüsselbereiche in SAP NetWeaver 7.0 nicht mit den verschiedenen Sichten auf die Business Intelligence decken kann, wird nachfolgend der Bezug zur Theorie der BI und der praktischen Umsetzung in SAP NetWeaver 7.0 eingegangen. Im Schlüsselbereich Information Integration liegt der Teilbereich SAP NetWeaver BI. Mit einem Data Warehouse, einem integrierten Berichtswesen, Analysefunktionen und dem Planungspaket ist die Business Intelligence nahezu vollständig. Einzig das Portal fehlt in dieser Zusammenstellung, doch spielt es eine zu große Rolle in SAP NetWeaver 7.0, als dass es nur der BI zugeordnet werden sollte. Daher wird es dem Bereich People Integration zugeordnet und ist gleichzeitig ein unverzichtbarer Bestandteil für die SAP NetWeaver BI. Sämtliche Berichte und die SAP BI Integrierte Planung werden über das Portal ausgeführt. Daher wird es an dieser Stelle auch

44

Business Intelligence

zur SAP NetWeaver Business Intelligence gezählt. Der Zusammenhang zur Theorie der Business Intelligence wird in der Abbildung 2.12 deutlich. Sie ist Abbildung 2.1 ähnlich und stellt die korrespondierenden Bestandteile der Business Intelligence mit denen der SAP NetWeaver 7.0 Platform dar. Zunächst soll die Vorstellung des Data Warehouse erfolgen, das die Datenbasis für die BI bildet und zudem über die notwendigen Berichtsfunktionen verfügt. Anschließend wird die SAP BI Integrierte Planung behandelt, die Teil des SAP BI Data Warehousing ist. Das SAP NetWeaver Portal folgt im Anschluss.

Abb. 2.12 SAP NetWeaver 7.0 BI und die Facetten der Business Intelligence

2.3.1 SAP NetWeaver Information Integration - BI B Zur Ausgestaltung der kundenindividuellen Anforderungen an die Business Intelligence bietet die Integrationsplattform SAP NetWeaver 7.0 im Schlüsselbereich Business Intelligence ein Data Warehouse, eine technische Basis für BI und eine Vielzahl von Analyse- und Reportingwerkzeugen an. Mit diesen Werkzeugen lässt

Business Intelligence mit SAP NetWeaver 7.0

45

sich die zu Beginn leere Hülle des SAP NetWeaver BI ausgestalten, um sie mit Daten zu füllen und letztlich komplexe Auswertungen auf den Daten des gesamten Unternehmens zu realisieren, die an Anwender oder weiterführende Analysesysteme verteilt werden. Der Schlüsselbereich SAP NetWeaver BI zeichnet sich durch eine vollständige Integration der Funktionen aus und ist auch mit den verschiedensten Elementen der SAP NetWeaver 7.0 Integrationsplattform verbunden, so beispielsweise mit dem SAP NetWeaver Portal. Die Einordnung wird in der Abbildung 2.13 visualisiert und im nachfolgenden Abschnitt kurz beschrieben (vgl. SAP 2008c).

Abb. 2.13 Übersicht der Business Intelligence unter SAP NetWeaver 7.0 (vgl. SAP 2008c)

46

Business Intelligence

2.3.1.1

SAP BI Data Warehousing

Die Basis aller Auswertungen ist das Data Warehouse, unter SAP NetWeaver 7.0 als SAP BI Data Warehousing bezeichnet. Ohne Daten keine Business Intelligence, dies gilt auch unter SAP. Um den Anforderungen an eine unternehmensweit konsistente Datenbasis für strategisches Reporting zu erfüllen, hat die SAP ihr Data Warehouse mit einer Vielzahl Schnittstellen versehen. Neben SAP-Systemen und ERP-Systemen von Drittanbietern kommen als Datenquelle relationale oder multidimensionale Datenbanken, flache Dateien und Web-Services in Frage. Mittels verschiedener Schnittstellentechnologien werden die Daten in das SAP BI Data Warehousing geladen, um dort konsolidiert und in verschiedene datentragende Objekte transferiert zu werden. Datentragende Objekte werden in SAP BI Data Warehousing vollständig modellgetrieben angelegt. In Erfassungsmasken gegliedert lassen sich die technischen Eigenschaften bestimmen, Einstellungen zur Darstellung treffen und Objektbeziehungen definieren. Als elementare Objekte werden Kennzahlen und Merkmale unter dem Begriff InfoObject zusammengefasst. Aus ihnen werden stamm- und bewegungstragende Objekte aufgebaut, sogenannte InfoProvider. Dies können Stammdaten tragende Merkmale, relationalen Tabellen ähnelnde DataStoreObjekte oder multidimensionale Datenstrukturen sein, die InfoCube genannt werden. Neben diesen in der Regel physisch datentragenden Objekten existieren auch virtuelle InfoProvider, die verschiedene andere miteinander in einer UNION (MultiProvider) oder JOIN-Bedingung (InfoSet) verbinden. So lassen sich komplexe Auswertungsgrundlagen für Berichte erstellen. 2.3.1.2

BI-Suite: Business Explorer

Die wichtigsten Werkzeuge für den Aufbau eines professionellen Berichtswesens unter SAP NetWeaver 7.0 BI sind in der BI Suite enthalten, die als Anwendungen des Business Explorers zusammengefasst sind. Die Auswertung der im SAP BI Data Warehousing abgelegten Daten ist ein Kernbereich der Business Intelligence. Die Struktur der BI Suite gliedert sich in zwei Bereiche. Basis aller Tätigkeiten im Berichtswesen ist die BEx Query, die über den BEx Query Designer erstellt wird. Sie definiert eine Sicht auf den Datenbestand eines InfoProviders und stellt die grundlegenden InfoObjekte eines Berichts zur Verfügung und wird in den Berichtswerkzeugen als Data Provider bezeichnet. Berichte selbst lassen sich einerseits unter Microsoft Excel mit dem Add-In BEx Analyzer definieren und ausführen. Andererseits können Berichte auch für das Web erstellt werden. Als Beispiel lässt sich der BEx Web Analyzer betrachten, der über grundlegende Funktionen zur Navigation im Datenbestand und zur Ergebnisdarstellung verfügt. Erstellt werden Web Reports mit dem BEx Web Application Designer. Mit Hilfe modularer, vorgefertigter Berichtsobjekte (Web Items und BI Pattern) werden Berichte als Web Templates leicht zusammengestellt, ohne dass umfangreiche Kenntnisse

Business Intelligence mit SAP NetWeaver 7.0

47

der Programmierung vonnöten wären. Per Drag & Drop können unmittelbar Web Templates mit Tabellen, Diagrammen und Navigationselementen ausgestattet werden, so dass ein Bericht schon nach wenigen Schritten fertiggestellt sein kann. Für das formatierte Drucklayout steht zudem mit dem BEx Report Designer ein Werkzeug zur Verfügung, das die Berichte in ein druckfähiges Format wandelt. Abbildung 2.14 zeigt die Elemente der BI Suite (vgl. SAP 2006).

Abb. 2.14 BI Suite

2.3.1.3

BI Platform

Berichte bedienen sich der Technologien der BI Platform und der BI Suite. Die BI Platform arbeitet im Verborgenen und wird vom Anwender nicht so stark wahrgenommen wie die BI Suite. Zu ihren Funktionen gehört vor allem die Bereitstellung der Navigationsoperationen im Datenbestand. Das Online Analytical Processing (OLAP) ist der Fachterminus für die Veränderung des Aufbaus einer Ergebnistabelle und ihres Inhalts durch Hinzufügen oder Verschieben von Spalten und Zeilen, Setzen von Filtern, Sortieren und Aggregieren der Daten und Berechnen der Kennzahlen. Als Schnittstelle zwischen dem Bericht und dem InfoProvider verarbeitet diese Analytical Engine alle Befehle, die der Anwender über Berichtsmasken ausführt, ohne selbst für den Entwickler in Erscheinung zu treten. Die Arbeitsweise der BI Platform kann aus der Abbildung 2.15 entnommen werden (vgl. SAP 2008c).

48

Business Intelligence

Abb. 2.15 Integration der SAP NetWeaver BI Platform

Die BI Platform enthält zusätzlich zur OLAP-Engine auch Funktionen, die bei der BI-Integrierten Planung zum Einsatz kommen. Sie sollen jedoch in einem eigenen Absatz behandelt werden. Zusätzlich zu Planungsfunktionen bietet die BI Platform auch statistische Analysen und Data Mining Algorithmen an, um die im SAP BI Data Warehousing abgelegten Daten auf ihre Eigenschaften hin und nach verborgenen Mustern zu untersuchen. Der Analyseprozessdesigner bietet eine grafische Oberfläche, die zur Modellierung von Analyseprozessen dient. So lassen sich Datenanalysen strukturieren und transparent aufbereiten. Nachdem das Verständnis für die Daten geschaffen wurde, wird dann mit dem Data Mining ein Vorhersagemodell gelernt, das Regelmäßigkeiten im Datenbestand aufspürt und auf Grundlage der erstellten Hypothese Werte für neue Datensätze prognostizieren kann (vgl. SAP 2006).

Business Intelligence mit SAP NetWeaver 7.0

49

Neben den realen Objekten sind im SAP BI Data Warehousing auch viele Metadaten zu den Objekten abgelegt. Dies macht es den Entwicklern leichter, Zusammenhänge im Datenmodell zu erkennen, ohne seitenweise Dokumentationen durchsuchen zu müssen. Das Metadata Repository verknüpft alle technischen Informationen und fasst sie auf einen Blick überschaubar zusammen. Zusätzlich lassen sich einfache Dokumente als weiterführende Informationen zu den Objekten im SAP BI Data Warehousing anfügen. Auf die Dokumente kann sogar aus dem Berichtswesen heraus zugegriffen werden (vgl. SAP 2008c). 2.3.1.4

Entwicklertechnologien

Im Teilbereich Entwicklertechnologien finden sich verschiedene Möglichkeiten zur Entwicklung eigenständiger Anwendungen und Schnittstellen. Da SAP NetWeaver 7.0 eine Java-Programmumgebung bietet, lassen sich umfangreiche kundenindividuelle Analyseanwendungen erstellen. Durch die Verwendung von Java kann der Entwickler auf eine populäre Programmiersprache zurückgreifen, die auch die Kommunikation mit anderen Programmen und Datenquellen möglich macht (vgl. SAP 2008c). Ist die Funktionalität der BI Suite nicht ausreichend, so können auch SAPfremde Anwendungen genutzt werden, um die Daten im SAP BI Data Warehousing zu analysieren. Zu diesem Zweck existiert das Open Analysis Interface, das es Drittanbietern erlaubt, über OLE DB für OLAP, OLAP BAPI oder XML Daten aus dem SAP BI Data Warehousing zu beziehen (vgl. SAP 2008c). 2.3.1.5

SAP BI-Integrierte Planung

Als besonders hervorzuhebender Bestandteil der SAP NetWeaver 7.0 BI soll im Folgenden die BI-Integrierte Planung erläutert werden. Neben dem Berichtswesen auf aus den Quellsystemen bezogenen Daten ist das SAP BI Data Warehousing auch auf die Erstellung von neuen Daten ausgerichtet, die in die Zukunft reichen. Eingeordnet in die BI Platform ist die technologische Basis eng an die Analytic Engine gebunden, wodurch die vollständige Integration in die BI Suite im Speziellen und das SAP BI Data Warehousing insgesamt begründet ist. Dies bedeutet, dass über die Analytic Engine nicht nur Daten aus den InfoProvidern gelesen, sondern auch in sie hineingeschrieben werden. Für das Einfügen von neuen Datensätzen oder das Ändern von bestehenden wird nicht der konventionelle Ladeprozess der SAP BI Data Warehousing genutzt. Stattdessen sind Funktionen für das manuelle Eintragen von Werten und das automatische Generieren von Daten in der BI Platform integriert. Die Voraussetzung des Datenmodells ist mit einem virtuellen InfoProvider des Typs Aggregationsebene gegeben. Darin wird definiert, welche Daten in welcher Tiefe einer Planung unterzogen werden sollen. Je

50

Business Intelligence

mehr Merkmale in einer Aggregationsebene enthalten sind, desto tiefer und detaillierter, aber auch aufwändiger ist die Planung (vgl. SAP 2008b). Die SAP BI-Integrierte Planung gibt den Anwendern zwei Wege zur Auswahl, um Plan- oder Sollwerte zu generieren. Beide werden vom Planning Modeler und Planning Wizard unterstützt, um den Entwickler zu entlasten. Es lassen sich in den Berichten der BI Suite Daten manuell eintragen und sichern. Auf diese Weise kann höchstindividuell geplant werden, der Anwender hat volle Freiheit bei der Bewertung der Kennzahlen und Merkmale. Jedoch kann dies bei Massendaten ungewollt zu einem nicht vertretbaren Aufwand führen, so dass Daten auch mittels Planungsfunktionen automatisch erstellt und verändert werden können. Diese Planungsfunktionen bieten beispielsweise das Kopieren, Berechnen und Löschen der Werte. In Planungssequenzen zusammengefasst lassen sich so Planungsprozesse schaffen, die mit Berechtigungen hinterlegt als Top-Down und Bottom-Up Planung im gesamten Unternehmen etabliert werden könnten. In einem solchen Szenario könnte auch die manuelle Planung eingesetzt werden, um auf der Ebene der einzelnen Fachbereiche die von Planungsfunktionen generierten Werte manuell anzupassen (vgl. SAP 2008b).

2.3.2 SAP NetWeaver People Integration - Portal Über das SAP NetWeaver Portal wird ein zentraler Zugang zu den verschiedensten Inhalten bereitgestellt. Zu diesen Inhalten zählen Webseiten ebenso wie Dokumente im PDF-Format, Portal-Content als iView und Multimediadaten. Neben Inhalten sind auch Anwendungen über das Portal erreichbar. Hier sind portaleigene Anwendungen, wie Foren, Blogs, Suchfunktionen und Anwendungen zur Zusammenarbeit von Verbindungen zu anderen Systemen (SAP- und Fremdhersteller), zu unterscheiden, zu denen auch Berichte des SAP BI Data Warehousing zählen. Die vielfältigen Möglichkeiten zur Integration von Informationsquellen, Unternehmensanwendungen, Datenbanken und Diensten innerhalb und außerhalb des Unternehmens über eine einzige, integrierte Benutzeroberfläche machen das Portal zu einer Schlüsselanwendung der Business Intelligence. Die im Portal dargestellten Informationen können mit unterschiedlichen Werkzeugen verwaltet und zur Analyse und Präsentation bereitgestellt werden. Mittels einer rollenbasierten Zugangs- und Inhaltsverwaltung werden die vorhandenen Unternehmensstrukturen auf die Inhalte des Portals übertragen. So können sie sogar für den einzelnen Anwender individuell zusammengestellt werden (vgl. SAP 2008a). 2.3.2.1

Integration in SAP NetWeaver 7.0

Innerhalb der Integrationsplattform SAP NetWeaver 7.0 ist das Portal dem Schlüsselbereich People Integration zugeordnet. Neben seinem Einsatz in der Bu-

Business Intelligence mit SAP NetWeaver 7.0

51

siness Intelligence ist es eng mit der Zusammenarbeit (Collaboration) und dem Wissensmanagement (Knowledge Management) verbunden. Durch die dichte Vernetzung mit den wichtigsten Bereichen, wird eine prozessorientierte Arbeitsweise gefördert und die Möglichkeit zum Austausch von Informationen zwischen den am Geschäftsprozess beteiligten Personen eröffnet. Im Gegensatz zu den meisten bisherigen SAP-Anwendungen ist das Portal in der Programmiersprache Java geschrieben (vgl. SAP 2008a). Eine Übersicht ist in Abbildung 2.16 enthalten. Die Anbindung an den Schlüsselbereich Knowledge Management bietet den Zugriff auf Werkzeuge zur Verwaltung und Bereitstellung unstrukturierter Daten in Form von Dokumenten. Die Möglichkeiten umfassen im Wesentlichen die gemeinsame Erstellung, Versionierung und Bereitstellung eigener Dokumente, sowie die Bildung von Begriffshierarchien (Taxonomien) und Parametrisierung von Suchfunktionen. Innerhalb des Wissensmanagements lassen sich so auch Inhalte der SAP NetWeaver BI einsetzen (vgl. SAP 2008a). Der Schlüsselbereich der Collaboration stellt direkt in das Portal integrierte Werkzeuge zur Zusammenarbeit und Kooperation der Anwender bereit. Neben virtuellen Räumen für die Organisation von und den Datenaustausch in Projektgruppen und Teams existieren auch Werkzeuge zum direkten und indirekten Nachrichtenaustausch (Chat, Email, Instant Messaging, Diskussionsforen) oder zur Terminverwaltung und Aufgabenverteilung. Zusätzlich können bereits im Einsatz befindliche Groupware-Systeme integriert werden (vgl. SAP 2008a). Zusätzlich sind im Portal Workflows modular integriert, wodurch sich Geschäftsprozesse mit geringem Aufwand im Portal nachbilden lassen. Das Composite Application Framework for Guides Procedures ist das Framework, das zur Modellierung und Verwaltung von anwenderorientierten Workflows eingesetzt wird. Diese lassen sich aus Standard-Objekten zusammenfügen und mit kundenindividuellen Prozessschritten anreichern (vgl. SAP 2008a).

52

Business Intelligence

Abb. 2.16 Übersicht des Portals unter SAP NetWeaver 7.0 (vgl. SAP 2008a)

2.3.2.2

Architektur des Portals

Das Portal baut auf dem Portal Framework auf. Dieses Framework stellt sämtliche benötigten Anwendungen und Dienste bereit, die zur Ausführung oder Administration eines Inhaltes oder einer Anwendung innerhalb des Portals benötigt werden. Die verschiedenen Teile des Frameworks laufen dabei auf einem Java Application Server, woraus sich die hohe Plattform-Unabhängigkeit ergibt. Das SAP NetWeaver Portal kann auf unterschiedlichen Betriebssystemen ausgeführt werden, darunter Microsoft Windows oder verschiedene Linux- und Unix-Varianten (vgl. SAP 2008a). Zur Erhöhung der Leistung und Verfügbarkeit des Portals lassen sich Caching-Methoden einsetzen und das Portal in einer ClusterSystemlandschaft nutzen, wodurch die Last der verschiedenen Prozesse auf die Knoten des Clusters verteilt werden kann.

Business Intelligence mit SAP NetWeaver 7.0

53

Aufgerufen wird das SAP NetWeaver Portal in einem Web-Browser. Damit ist es auch auf der Seite des Front-Ends äußerst flexibel und gestattet eine unabhängige Anwendungsstruktur beim Client. Sämtliche Anwendungen des Portals werden vom Web-Browser als iView ausgeführt. Ein iView beschreibt Funktionen und Darstellung von Inhalten im SAP NetWeaver Portal. Über einen http-Request erfolgt der Aufruf eines iViews im Portal. Der Java Application Server verarbeitet diesen Request innerhalb der Portal Runtime Engine. Dies ist die Hauptanwendung des SAP NetWeaver Portals, die für die Verarbeitung der vom Anwender an das Portal gesendeten Requests und die Generierung von HTML-Webseiten für die Ausgabe von Inhalten zuständig ist. Bei der Verarbeitung kann beispielsweise auf in der Datenbank gespeicherte Portal-Inhalte zugegriffen werden, oder es werden Anwendungen in externen Systemen aufgerufen. Dies können beispielsweise andere SAP-Anwendungen, Datenbanken oder Web-Services sein. Die Verarbeitung eines Requests zeigt Abbildung 2.17. Neben dem zentralen Zugang dient das Portal auch als eine zentrale Stelle zur Vergabe und Verwaltung dieser Berechtigungen. Die vorgenerierten Inhalte dienen dabei zur Anpassung und Abbildung an die vorhandenen Strukturen im Unternehmen. Der Zugriff auf Inhalte und Funktionen wird über ein leistungsstarkes Rollen- und Berechtigungswesen gesteuert. Das in das Portal integrierte Sicherheitskonzept umfasst neben der Authentifizierung und dem Single Sign-On ein integriertes Berechtigungs-Management für die verschiedenen Objekte im Portal und abgesicherte Verbindungen zum Portal. Das Konzept für die verschiedenen Rollen der Anwender ist dabei das gleiche wie in der SAP NetWeaver BI, so dass sich die Zusammenstellung der Inhalte für die jeweiligen Anwender einheitlich gestalten lässt (vgl. SAP 2008a). Für die Erweiterung oder Entwicklung im Portal stehen neben den verschiedenen internen Werkzeugen zur Integration von Informationen und Diensten, wie dem Portal Content Studio oder dem Visual Composer, auch Portal Development Kits bereit, über die Entwickler in ihrer bevorzugten Entwicklungsumgebung Inhalte und Erweiterungen für das Portal entwerfen (vgl. SAP 2008a).

54

Business Intelligence

Abb. 2.17 SAP NetWeaver Portal Architektur (vgl. SAP 2008a)

2.3.2.3

Publikation von Inhalten

Neben der Möglichkeit, Inhalte über das Knowledge Management in das Portal zu integrieren, wird vor allem der Weg über iViews genutzt. Dadurch lassen sich die mit der SAP NetWeaver BI erstellten Web Applications, BEx Queries oder Reports einfügen. Ein iView stellt die SAP-Variante eines Portal-Portlets dar. Mittels dieser iViews lassen sich die Inhalte der SAP NetWeaver BI in das Layout und die Logik des SAP NetWeaver Portals integrieren, um dort von den Anwendern direkt zur Auswertung genutzt zu werden. Die Ergebnisse einer solchen Auswertung lassen sich über die verschiedenen Collaboration-Funktionen des Portals publizieren und weiteren Anwendern zur Verfügung stellen. Der Aufbau des Portals ermöglicht dabei die Kombination verschiedener iViews zu einer Seite, was die gleichzeitige Darstellung mehrerer Web Applications und anderer Inhalte, etwa von Dokumenten ermöglicht. Neben der Integration der Inhalte aus angebundenen SAPund Fremdherstellersystemen können über die iViews des SAP NetWeaver Portals auch externe Dienste eingebunden werden. Auf diesem Weg kann die Übernahme

Business Intelligence mit SAP NetWeaver 7.0

55

verschiedener Inter- und Intranet-Dienste in das SAP NetWeaver Portal erfolgen, die als Ergänzung zu den SAP NetWeaver BI-internen Informationen dienen. Das Portal ermöglicht dabei Anwendern aus verschiedenen Organisationsbereichen des Unternehmens die gemeinsame Arbeit auf den integrierten Informationen und gestattet damit eine Kombination der analytischen Fähigkeiten dieser Anwender (vgl. SAP 2008a). 2.3.2.4

Zentrale Funktionen

Um die Aufgabe des zentralen Einstiegspunktes zu allen Daten und Informationssystemen im Unternehmen erfüllen zu können, sind dem SAP NetWeaver Portal verschiedene Funktionen zugeordnet. Der bereits angesprochene Zugriff auf die Informationen aus verschiedenen Datenquellen, der unabhängig von der Art der hinterlegten Daten, dem physischen Ort oder dem Typ des Quellsystems erfolgt, stellt den wichtigsten Aufgabenbereich dar. Daneben existieren die Administration und Entwicklung des Portals, deren Bedeutung im Folgenden dargelegt wird. Abbildung 2.18 gibt einen Überblick über die administrativen Aufgaben (vgl. SAP 2008a).

Abb. 2.18 Administration des SAP Portals (vgl. SAP 2008a)

56

Business Intelligence

Die Verwaltung des Portals an sich betrifft die Verfügbarkeit und die Ressourcenzuweisung, ebenso wie die Aktivierung von Funktionen und die Pflege der Systemverbindungen. Diese ist bei SAP-Systemen vergleichsweise leicht zu realisieren, da die neuesten Versionen auf eine Koppelung an das SAP NetWeaver Portal vorbereitet sind (vgl. SAP 2008a). Die Integration von Inhalten und Anwendungen erfordert eine intensive Unterstützung von Administratoren und Endanwendern. Das Portal bietet daher umfangreiche Funktionen zur Verwaltung des Portals selbst und seiner Inhalte. Sie sind allesamt über die Web-Oberfläche zugänglich. Weitestgehend statische Inhalte werden in Form von iViews im Portal Content Studio erstellt und verwaltet, ohne dass es Kenntnisse der Programmierung bedarf. Abgelegt werden sie im Portal Content Directory. Zu Inhalten zählen jedoch auch Anwendungen im SAP NetWeaver Portal. Eine Portalanwendung ist ein in der Programmiersprache Java geschriebenes Programm, das von der Portal Runtime Engine ausgeführt wird. Programme erlauben es auf die Eingaben des Anwenders zur Laufzeit zu reagieren. Hierzu zählen auch BEx Web Applications, die in der SAP NetWeaver BI erstellt werden. Ebenfalls lassen sich auf diesem Wege Anwendungen auf der J2EEEngine ausführen. Hier können vom Portal unabhängige Java-Programme Daten verarbeiten, ohne dass sie sich den Bedingungen des Portals unterwerfen müssten. Komplexe Anwendungen mit Bildschirmmasken lassen sich durch Web Dynpros realisieren. Diese in Java oder ABAP geschriebenen Anwendungen dienen in erster Linie der Kommunikation mit dem Anwender und der Weiterleitung von Daten an andere Anwendungen (vgl. SAP 2008a). Über die Portaladministration kann das Portallayout an die Corporate Identity des Unternehmens angepasst werden, um eine einheitliche Darstellung der iViews sicherzustellen. Verschiedene Vorlagen und eine Fülle von beeinflussbaren Eigenschaften machen eine weitgehende Modifikation des Portalinhalts möglich. Ebenso kann die graphische Darstellung für technische Barrieren verringert werden, um eine bessere Barriere-Freiheit zu erreichen. Neben der graphischen Darstellung können auch Tastaturnavigation oder Screen Reader kompatible Ausgaben für einen barrierefreien Zugang zum Portal sorgen. Die Unterstützung von mehrsprachigen Portal-Interfaces ermöglicht die Verwendung des SAP NetWeaver Portals in internationalen Szenarien und erleichtert die Zusammenarbeit auf globaler Ebene (vgl. SAP 2008a). Die Masse an Inhalten und Applikationen im SAP NetWeaver Portal und deren Zuordnung zu Anwendern macht eine weitreichende Administration der Benutzer und deren Rechte notwendig. Durch die einmalige und systemübergreifende Authentifizierung im Portal erhält der Anwender durch die Verwendung von Single Sign-On den Zugriff auf alle ihm zustehenden Informationen, ohne weitere Systeme nutzen zu müssen. Dies verkompliziert jedoch die Arbeit des Administrators, der nicht nur die Berechtigungen auf der Portalseite, sondern auch auf der Seite der jeweiligen, mit dem Portal verbundenen Anwendung berücksichtigen muss. Um den Administrator zu unterstützen, erfolgt die Administration des Portals und seiner Anwender in SAP NetWeaver verteilt, so dass diese Aufgabe von mehreren

Business Intelligence mit SAP NetWeaver 7.0

57

Personen übernommen werden kann. Zu diesem Zweck lassen sich die verschiedenen administrativen Aufgaben mit Rollen und Berechtigungen präzise abgegrenzt und dennoch vollständig an die Anwender verteilen, so dass die Arbeitsteilung erleichtert wird. In diesem Zusammenhang helfen vorgenerierte Rollenkonzepte und Inhalte bei der Abbildung der Unternehmensstrukturen. Die verschiedenen Rollen können sowohl einzelnen Anwendern als auch ganzen Anwendergruppen zugeordnet werden, wodurch eine fein getrennte Steuerung der einzelnen Berechtigungen möglich ist. Ebenso kann der Zugang zu den verschiedenen Inhalten im Portal auf Rollen, Gruppen und auf den einzelnen Anwender bezogen festgesetzt werden. Als Konsequenz ergibt sich daraus, dass auch die Navigation im Portal komplett rollenbasiert erfolgt. Anwender sehen nur diejenigen Inhalte, die sie zum Ausführen bestimmter Funktionen benötigen. Alles andere wird unmerklich ausgeblendet. Auf diese Weise ist sichergestellt, dass Anwender nur diejenigen Funktionen ausführen dürfen, die über die Navigationsschritte zugänglich sind. In die unterschiedlichen Formen der Navigation, von einem Link in der Portalseite bis zum Kontextmenü, lassen sich vielfältige Funktionen einbinden. Ein Teil dieser Funktionen dient zur Benutzeradministration, dem Zuweisen von Berechtigungen und der Verwaltung von Sicherheitsfunktionen. Außerdem bietet das Portal Funktionen für Entwicklungsaufgaben und individuelle Anpassung, der sogenannten Personalisierung. Die Personalisierung ermöglicht die an den individuellen Möglichkeiten und Bedürfnissen des einzelnen Anwenders angepasste Präsentation der Inhalte. Zusätzlich können Anwender in einem vordefinierten Rahmen eigene Präferenzen für die Darstellung der Inhalte festlegen. Diese Anpassungen lassen sich auf das gesamte Portal aber auch nur auf einzelne Elemente übertragen und ermöglichen einen hohen Grad an Individualisierung für den einzelnen Anwender (vgl. SAP 2008a).

3 Data Warehouse-Architektur 3.1

Grundlagen zur Data Warehouse-Architektur

In diesem ersten Abschnitt des Data Warehouse-Kapitels soll zunächst einleitend auf die Grundlagen der Data Warehouse-Architektur eingegangen werden. Dazu sollen der Themenkomplex zunächst kurz einführend erläutert und die wichtigsten Begrifflichkeiten in diesem Zusammenhang definiert werden. Es folgt eine Einordnung der Data Warehouse-Architektur in die existierenden Technologien und eine Abgrenzung zu bisher bestehenden Systemen. Darauf aufbauend werden die eigentlichen Charakteristika eines Data Warehouse behandelt, indem die Architektur mit ihren dazugehörigen Komponenten detailliert dargestellt wird. Im Anschluss werden die Daten, als Teil des Data Warehouse, näher betrachtet. Dabei werden zunächst die unterschiedlichen Datentypen in einem Data Warehouse beschreiben, aber auch deren Quellsysteme, sowie die damit einhergehende Qualität der Daten erläutert. Es folgt eine Betrachtung des im Zusammenhang mit dem Thema Data Warehouse häufig genannten multidimensionalen Datenmodells und eine Beschreibung, auf welche Weise multidimensionale Datenstrukturen modelliert werden können. Mit einer daran anschließenden detaillierten Aufschlüsselung der unterschiedlichen Phasen, die im sogenannten Data Warehouse-Prozess bzw. ETL-Prozess durchschritten werden, findet dieser erste Abschnitt des Kapitels zur Data Warehouse-Architektur seinen Abschluss.

3.1.1 Einführung Es gibt nur wenige Begriffe im Bereich der Informationstechnologie, die in den letzten Jahren eine so häufige Erwähnung und damit einen so starken Fokus in der öffentlichen Diskussion erfahren haben, wie der Begriff des Data Warehouse. Aber trotz oder möglicher Weise gerade aufgrund dieser Tatsache ergibt sich durch die Vielzahl der existierenden Forschungsbeiträge und Veröffentlichungen die Notwendigkeit einer eindeutigen Definition zur Darstellung der tatsächlichen Charakteristika und des eigentlichen Nutzens eines Data Warehouse. Im Zuge der rasanten Entwicklung von Data Warehouse-Systemen zu einem der zentralen Themen in der Informationstechnologie drängt sich die Frage auf, aus welchem Grund dieser Bereich so stark in den Fokus geraten ist. Die Antwort darauf liegt in der noch jungen Erkenntnis über die Bedeutung von Information zur Entscheidungsunterstützung in Organisationen und vor allem in der damit einhergehenden, positiven Beeinflussung der Wettbewerbsposition eines Unternehmens (vgl. Gupta 1997). Die Abwicklung von Geschäftsprozessen hat heutzutage

60

Data Warehouse-Architektur

einen solch hohen Grad der Automatisierung erreicht (vgl. Fuller 2002), dass nur noch geringe Verbesserungen der Produktivität und Profitabilität durch weitere Investitionen in diesem Bereich zu erwarten sind (vgl. Anahory u. Murray 1997). Aufgrund dieser Argumente wird Information immer häufiger als vierte Säule zu den drei konventionellen Produktionsfaktoren Boden, Arbeit und Kapital hinzugezählt (vgl. Bauer u. Günzel 2004). Information ist nicht mehr ausschließlich konsumtiv, sondern kann durchaus als produktiv bezeichnet werden, da sie durch Einsatz anderer Produktionsfaktoren „produziert“ und extern zugekauft werden kann. Heinrich definiert den Begriff wie folgt: „Information ist handlungsbestimmendes Wissen über historische, gegenwärtige und zukünftige Zustände der Wirklichkeit und Vorgänge in der Wirklichkeit, mit anderen Worten: Information ist Reduktion von Ungewissheit.“ (Heinrich 1999) Auch die Anforderungen an Informationsintegration und -versorgung haben sich weiterentwickelt, wodurch Bereiche wie Flexibilität, Verfügbarkeit und Qualität von Information eine Veränderung erfahren haben. Durch neue Informationssysteme kann individuell auf die Bedürfnisse des Anwenders eingegangen werden, indem ihm die auf seine Person zugeschnittenen Daten in aufbereiteter Form zur Verfügung gestellt werden. Informationsqualität und -quantität hängen dagegen vom Prozess der Informationsgewinnung und dem Zustand der internen wie externen Daten ab. Diese Faktoren beeinflussen die Abwicklung von Geschäftsprozessen und sind somit auch indirekt für den Unternehmenserfolg verantwortlich (vgl. Holthuis 2002). Bei diesen Betrachtungen steht neben der Information auch die Bedeutung des Datums im Vordergrund. Rautenstrauch formuliert zu diesem zentralen Begriff die nachfolgende Definition: „Daten sind zum Zwecke der Verarbeitung zusammengefasste Zeichen.“ (Rautenstrauch 2001) Bevor nun der eigentliche Data Warehouse-Begriff genauer definiert werden kann, ist es ferner notwendig, seine Vielseitigkeit zu erläutern. Nach Bauer und Günzel wird der Data Warehouse-Begriff zum einen durch die technische Seite mit den Grundlagen der Datenbanksysteme, zum anderen aber auch durch die Anwendungsseite mit den betriebswirtschaftlichen Anforderungen geprägt (vgl. Bauer u. Günzel 2004). Somit ist es unerlässlich, diese oft gegensätzlichen Gebiete bei einer detaillierten Grundlagenbetrachtung gleichermaßen mit einzubeziehen. Eine umfassende Definition des Begriffs Data Warehouse verlangt demnach die Betrachtung des von den Autoren bezeichneten „Dualismus von Informatik und Betriebswirtschaft“. Die Vielseitigkeit besteht folglich darin, dass ein Data Warehouse eine Datenbank beschreibt, die auf technischer Ebene Daten aus operativen Systemen, also unterschiedlichen Datenquellen, integriert und diese Daten dann

Grundlagen zur Data Warehouse-Architektur

61

auf betriebswirtschaftlicher Ebene dem Anwender zu Analysezwecken aufbereitet zur Verfügung stellt (vgl. Bauer u. Günzel 2004). Die Vielseitigkeit rund um den Begriff Data Warehouse impliziert auch ein unterschiedliches Begriffsverständnis zwischen der Anwendungs- und der Informatikseite, welches durch eigene Fachtermini geprägt ist. Bisherige Bestrebungen von unterschiedlichen Normierungsgremien, die Begrifflichkeiten zu standardisieren, sind bislang ohne nennenswerten Erfolg geblieben (vgl. Bauer u. Günzel 2004). Eine der Ersten und somit auch die in der Literatur am häufigsten verwendete Definition des Begriffs Data Warehouse stammt von Bill Inmon: “A data warehouse is a subject oriented, integrated, non-volatile and timevariant collection of data in support of management’s decisions.” (Inmon 1996) Inmon beschreibt in seiner Definition vier Charakteristika, die ein Data Warehouse auszeichnen. Diese sollen an dieser Stelle kurz erläutert werden:  Fachorientierung (subject orientation): Der Zweck der Datenbasis liegt in der Modellierung eines bestimmten Anwendungsziels und dient nicht der Erfüllung einer speziellen Aufgabe im Unternehmen, wie beispielsweise der Lagerverwaltung.  Integrierte Datenbasis (integration): Die Datenbasis enthält integrierte Daten, die aus unterschiedlichen Datenbanken stammen.  Nicht flüchtige Datenbasis (non-volatile): Daten, die einmal in ein Data Warehouse geladen wurden, bleiben erhalten. Sie können weder entfernt noch geändert werden, wonach die Datenbasis auch als stabil bezeichnet werden kann.  Zeitvariante Datenbasis (time variance): Alle Daten im Data Warehouse werden anhand ihres Zeitbezugs identifiziert. Somit werden Vergleiche über die Zeit möglich, jedoch ist es dabei unumgänglich, Daten über einen längeren Zeitraum zu halten. Bauer und Günzel bewerten die Definition von Inmon als „einerseits nicht aussagekräftig genug, um sie in der Praxis oder der Theorie verwenden zu können, andererseits ist sie so einschränkend, dass viele Anwendungsgebiete und Ansätze herausfallen“ (Bauer u. Günzel 2004) und erweitern die Definition um die Aspekte der physischen Integration und der Analyse in folgender Aussage: „Ein Data Warehouse ist eine physische Datenbank, die eine integrierte Sicht auf beliebige Daten zu Analysenzwecken ermöglicht.“ (Bauer u. Günzel 2004) Die physische Integration befasst sich hierbei mit der Vereinigung von Daten aus verschiedenen, meist heterogenen Quellen. Ein Data Warehouse überwindet diese Heterogenität auf System-, Schema- und Datenebene (vgl. Sattler u. Saake 2004). Die Daten in einem Data Warehouse werden sowohl aus einer Vielzahl an unter-

62

Data Warehouse-Architektur

nehmensinternen operativen Systemen, als auch aus unternehmensexternen Quellen bezogen (Überwindung der Heterogenität auf Systemebene). Desweiteren enthalten die Quellsysteme eigene Schemata, in denen unterschiedliche Abhängigkeiten zwischen den Datensätzen deklariert sind. Dazu müssen die zu integrierenden Daten zunächst in ein einheitliches Format überführt und gegebenenfalls auftretende Duplikate entfernt werden (Überwindung der Heterogenität auf Schema- und Datenebene). Um sowohl der Anforderung an ein Data Warehouse in Form der physischen Integration gerecht zu werden, als auch den Analyseaspekt zu realisieren, bedarf es der Verwendung eines adäquaten Modellierungsansatzes. Dabei kommt häufig das multidimensionale Datenmodell nach Kimball et al. (2008) zum Einsatz, welches sich durch besondere Strukturen und Auswertemöglichkeiten auszeichnet und in Kapitel 3.1.5 näher erläutert wird. Die Sicht des Anwenders wird hierbei in Dimensionen und Klassenhierarchien widergespiegelt, wobei der Analysekontext stets im Vordergrund steht. Das Online Analytical Processing (OLAP) gilt in diesem Zusammenhang als eine wichtige Anwendung, da es eine Form der interaktiven Datenanalyse auf der Grundlage des multidimensionalen Datenmodells darstellt. Auch Methoden des Data Mining, die zum Auffinden von bestimmten Mustern oder Beziehungen zwischen den Daten im Datenbestand dienen, gehören zu den verwandten Themenkomplexen innerhalb dieser Domäne (vgl. Bauer u. Günzel 2004), auf die in den weiteren Abschnitten dieses Buches noch intensiver eingegangen wird. Eine weitere, wichtige Definition im Zusammenhang mit dem Begriff des Data Warehouse, ist die des Data Warehouse-Prozesses bzw. des Data Warehousing. Bauer und Günzel nähern sich dem besseren Verständnis dieses Wortpaares durch die folgende Formulierung: „Der Data-Warehouse-Prozess, der alle Schritte der Beschaffung, der Modellierung und der Analyse umfasst, wird als Data Warehousing bezeichnet.“ (Bauer u. Günzel 2004) Nach Klärung der wichtigsten Definitionen muss der Vollständigkeit halber noch erwähnt werden, dass in der Diskussion über diesen Themenkomplex neben dem Begriff des Data Warehouse gleichsam auch der Begriff Data Warehouse-Systems verwendet wird. Beide Begriffe werden im Fortlauf dieses Buches synonym verwendet.

3.1.2 Einordnung und Abgrenzung Nach dieser kurzen Einführung und der Definition der wichtigsten Begriffe aus diesem Bereich kann nun eine Einordnung der Data Warehouse-Architektur in die existierenden Technologien erfolgen. Dazu werden im ersten Abschnitt die beiden

Grundlagen zur Data Warehouse-Architektur

63

Typen von Anwendungssystemen kategorisiert, um die Position der Data Warehouse-Systeme in diesem Zusammenhang zu verdeutlichen. Im zweiten Abschnitt wird dann detailliert auf die Unterscheidungsmerkmale der identifizierten Anwendungssysteme eingegangen. 3.1.2.1

Einordnung von Data Warehouse-Systemen

Um eine Einordnung der Data Warehouse-Systeme in das Umfeld existierender Technologien vornehmen zu können, ist es zunächst hilfreich, die Menge aller Anwendungssysteme in zwei Kategorien zu unterteilen:  betriebswirtschaftlich administrative Systeme  entscheidungsunterstützende Systeme Die betriebswirtschaftlich administrativen Systeme (auch operative oder transaktionale Systeme genannt) unterstützen den Anwender bei der Erfassung, Verwaltung und Verarbeitung sämtlicher Daten, die während der Durchführung von geschäftlichen Transaktionen in einem Unternehmen anfallen. Als typische Beispiele für betriebswirtschaftlich administrative Systeme gelten Aufgaben wie Lagerverwaltung, Auftragserfassung und Personalverwaltung. Grundsätzlich werden diese operativen Systeme in den einzelnen Abteilungen eines Unternehmens unabhängig und eigenverantwortlich betrieben und eingesetzt. Häufig werden die betrieblichen Aufgaben jedoch durch sogenannte Enterprise Resource Planning-Systeme (ERPSysteme) unterstützt, so dass eine Integration über alle Bereiche eines Unternehmens und somit über alle Funktionen der betriebswirtschaftlichen Wertschöpfungskette erreicht werden kann. Neben den bereits synonym verwendeten Begriffen von betriebswirtschaftlich administrativen Systemen und operativen Systemen taucht in der Literatur häufig noch ein dritter Begriff auf: Die Bezeichnung der Online-Transaction-Processing-Systeme (OLTP-Systeme) wird oftmals verwendet, um das Charakteristikum hervorzuheben, dass die Funktionen von solchen Systemen meist auf einzelnen Transaktionen (Aufträge, Buchungssätze etc.) basieren (vgl. Mehrwald 2007, Marx Gómez et al. 2006). Für den Fortlauf dieses Buches soll der Begriff der operativen Systeme synonym für alle an dieser Stelle erwähnten Begriffe verwendet werden. Entscheidungsunterstützende Systeme (Decision-Support-Systeme, DSS) konzentrieren sich im Gegensatz zu operativen Systemen nicht auf einzelne Transaktionen, sondern dienen dazu, das Treffen von komplexen betriebswirtschaftlichen Entscheidungen in einem Unternehmen zu unterstützen. Das klassische Berichtswesen, die bereits angesprochene interaktive Datenanalyse (OnlineAnalytical Processing, OLAP) und Systeme zur Suche nach unbekannten Mustern oder Beziehungen im Datenbestand (Data Mining) gelten als Vertreter typischer entscheidungsunterstützender Systeme. Gemäß Abbildung 3.1 ergibt sich durch die Verwendung der unterschiedlichsten Analysewerkzeuge die Möglichkeit, tiefergehende Informationen über den Datenbestand der operativen Systeme zur Ent-

64

Data Warehouse-Architektur

scheidungsunterstützung für die unterschiedlichen Unternehmensbereiche (beispielsweise Finanzen & Controlling, Marketing & Kundenmanagement, Supply Chain Management und Performance Measurement) zu erhalten.

Abb. 3.1 Entscheidungsunterstützende Systeme (vgl. Mehrwald 2007)

Entscheidungsunterstützende Systeme verfügen meist über keine eigene Datenhaltung, so dass sie auf eine anderweitige Datenbasis als Grundlage zur Ausführung ihrer analytischen Aufgaben angewiesen sind. Operative Systeme eignen sich aufgrund ihrer originären Funktionen und vor allem aufgrund ihrer Datenstrukturen nicht als direkte Datenbasis. Aus diesem Grund werden Data Warehouse-Systeme als gemeinsame Datenbasis aller entscheidungsunterstützender Systeme eingesetzt. Dabei wird der Datenbestand eines Data Warehouse üblicherweise aus den operativen Systemen übernommen (extrahiert) und in Datenmodelle überführt, die für die Analyse optimiert sind. Auf diesem Wege kann sichergestellt werden, dass die Daten aus den Quellsystemen redundant im Data Warehouse vorgehalten werden, was wiederum positive Auswirkungen auf die Qualität des Datenbestands im Data Warehouse und somit auch auf die darauf aufbauenden Analysen hat (vgl. Mehrwald 2007). Ein Aspekt der häufig zur Verwirrung führt, ist die Tatsache, dass es sich beim Data Warehouse um eine Architektur und nicht um eine Technologie handelt. Ein Data Warehouse gilt demnach nicht als ein vollständiges entscheidungsunterstützendes System, sondern liefert lediglich die Grundlage (Architektur) für ein solches System und stellt die erforderlichen Schnittstellen zur Verfügung. Es kann festgehalten werden, dass die Data Warehouse-Architektur zweifelsohne auf vie-

Grundlagen zur Data Warehouse-Architektur

65

len unterschiedlichen Technologien (z.B. Datenbank-Technologie) basiert, aber in seiner Struktur selbst nur das Fundament für eine praktische Umsetzung eines Data Warehouse-Systems liefern kann (vgl. Inmon 2005). Auf die Data WarehouseArchitektur und seine verschiedenen Komponenten wird im Kapitel 3.1.3 ausgiebiger eingegangen. 3.1.2.2

Abgrenzung von operativen Systemen

Um die Abgrenzung zwischen den operativen und entscheidungsunterstützenden Systemen etwas deutlicher hervorzuheben und damit noch genauer auf die Unterschiede zwischen den beiden Arten von Anwendungssystemen einzugehen, werden in den nachfolgenden Abschnitten die Charakteristika aus den Bereichen Anfragen, Daten und Anwender anhand klassischer Unterscheidungsmerkmale gegenübergestellt (vgl. Bauer u. Günzel 2004). Anfragen Beginnend mit dem Charakteristikum der Anfragen unterscheiden sich beide Systemtypen vor allem in der Anfrageverarbeitung und der Speicherform von Daten (siehe Tab. 3.1). So liegt die Fokussierung von operativen Systemen eindeutig auf vielen und meist schnellen Lese- und Schreibvorgängen, da der Datenbestand häufig modifiziert werden muss. Dabei werden eher wenige Datensätze zeitgleich in Anspruch genommen, wodurch die Anfragestruktur als einfach klassifiziert werden kann. Analytische Systeme hingegen verlangen zeitlich aufwändigere Transaktionen (vornehmlich Lesetransaktionen), da meist komplexe Anfragen aus einer großen Menge an Datensätzen bewältigt werden müssen. Tabelle 3.1 Gegenüberstellung der Anfragecharakteristika von operativen und analytischen Systemen (vgl. Bauer u. Günzel 2004) Anfragen

operative Systeme

Fokus

Lesen, Schreiben, Modifizieren, Lesen, periodisches Hinzufügen Löschen

analytische Systeme

Transaktionsdauer

kurze Lese-/Schreiboperationen lange Lesetransaktionen

Anfragestruktur

einfach strukturiert

komplex

Datenvolumen einer Anfrage wenig Datensätze

viele Datensätze

Datenmodell

analysebezogenes Datenmodell

anfrageflexibles Datenmodell

66

Data Warehouse-Architektur

Daten Die Datencharakteristika weisen bei der Gegenüberstellung von operativen und analytischen Systemen ebenfalls sehr unterschiedliche Eigenschaften auf (siehe Tab. 3.2). So beziehen operative Systeme ihre Daten meist nur aus einer einzigen Datenquelle, wohingegen analytische Systeme ihrer Aufgabe überhaupt erst durch die Integration der Daten aus mehreren Datenquellen gerecht werden können. Dazu werden die Daten aus den Datenbanken der operativen Systeme – die dort entgegen der Bedingungen in analytischen Systemen in der Regel zeitaktuell und durch häufige Modifikationen in einer sehr dynamischen Form vorliegen – zur Verwendung in analytischen Systemen abgeleitet, konsolidiert und in die analytischen Systeme geladen. Dementsprechend verfügen die analytischen Systeme über weitaus größere Datenvolumina, als es bei den operativen Systemen der Fall ist. Für eine genauere Betrachtung der Daten sowie deren Datenquellen und Datenqualität wird an dieser Stelle auf Kapitel 3.1.4 verwiesen. Tabelle 3.2 Gegenüberstellung der Datencharakteristika von operativen und analytischen Systemen (vgl. Bauer u. Günzel 2004) Daten

operative Systeme

analytische Systeme

Datenquellen

meist eine

mehrere

Eigenschaften nicht abgeleitet, zeitaktuell, autonom, dynamisch

abgeleitet, konsolidiert, historisiert, integriert, stabil

Datenvolumen Megabyte - Gigabyte

Gigabyte - Terabyte

Zugriffe

Bereichsanfragen

Einzeltupelzugriff

Anwender Der typische Anwender eines Data Warehouse-Systems ist meist ein Entscheidungsträger, Controller oder Analyst eines Unternehmens, der die verdichteten Daten zur Entscheidungsunterstützung benötigt. Operative Systeme werden eher durch Sachbearbeiter bedient, die damit beschäftigt sind, Daten zu erfassen oder abzufragen (siehe Tab. 3.3). Außerdem unterscheidet sich auch die Anzahl der Anwender beider Systemarten. Tabelle 3.3 Gegenüberstellung der Anwendercharakteristika von operativen und analytischen Systemen (vgl. Bauer u. Günzel 2004) Anwender

operative Systeme

analytische Systeme

Anwendertyp Ein-/Ausgabe durch Sachbearbeiter Auswertungen durch Manager, Controller, Analysten Anwenderzahl sehr viele

wenige (bis einige Hundert)

Antwortzeit

Sekunden - Minuten

Millisekunden - Sekunden

Grundlagen zur Data Warehouse-Architektur

67

Neben den genannten Bereichen Anfragen, Daten und Anwender können außerdem noch technische Charakteristika in den Vergleich mit aufgenommen werden. So ist beispielsweise die Hardwarenutzung bzw. -auslastung bei operativen Systemen in etwa durchgehend gleichbleibend, während analytische Systeme in dieser Eigenschaft überwiegend als schwankend charakterisiert werden, da bei sehr komplexen Anfragen die technischen Anforderungen an das System punktuell besonders hoch sein können (vgl. Goeken 2006).

3.1.3 Architektur Ein Data Warehouse-System kann in drei Funktionsgruppen unterteilt werden. Da sind zunächst die Komponenten Arbeitsbereich, Basisdatenbank, Data Warehouse und Repositorium zu nennen, die ausschließlich der Datenhaltung dienen. Desweiteren unterstützen die Komponenten Extraktion, Transformation, Laden und Analysewerkzeuge den Anwender im Data Warehouse-Prozess. Zuletzt existieren Steuerungs- und Kontrollfunktionen, die durch die Komponenten Data Warehouse-Manager, Metadaten-Manager und Monitor bereitgestellt werden (vgl. Marx Gómez et al. 2006). Die nachfolgende Abbildung 3.2 zeigt die Architektur mit der Anordnung der verschiedenen Komponenten im Data Warehousing und deren Beziehungen. Alle Daten der Datenquellen, die für den Data Warehouse-Prozess relevant sind, werden durch Extraktion in den Arbeitsbereich (staging area) kopiert, um dort transformiert werden zu können. Die zur Konsolidierung notwendigen Operationen werden direkt in der Datenhaltungskomponente Arbeitsbereich ausgeführt. Dieser Arbeitsbereich dient somit ausschließlich der temporären Speicherung von Echtzeitdaten. Nach Abschluss der Transformation werden die Daten in integrierter Form in die Basisdatenbank geladen. Die Quelldaten innerhalb der Datenquellen bleiben durch diese Handhabung unverändert und die Übernahme fehlerhafter oder inkonsistenter Daten in das Data Warehouse wird vermieden. Der Monitor überwacht diesen Vorgang durch die Kontrolle des Prozesses, beispielsweise durch Aufzeichnung von Lauf- und Antwortzeiten. Die genannten Komponenten bilden gemäß Abbildung 3.2 den sogenannten Datenbeschaffungsbereich. Der beschriebene Vorgang wird analog als Datenbeschaffungsprozess bezeichnet. Die Basisdatenbank wiederum ist die Grundlage für die Bereitstellung detaillierter, historischer, konsistenter, modellierter und normalisierter Daten für die Weiterverarbeitung im Data Warehouse. Diese separate physische Ablage ist notwendig, um eine gewisse Auswertungsflexibilität und zeitliche Stabilität zu gewährleisten, anstatt an diesem Punkt einen Direktzugriff auf die Datenquellen innerhalb der Architektur vorzuschreiben. Letztlich liegen die abgeleiteten und auch meist zusammengeführten Daten im Data Warehouse vor und stehen dem Anwender von dort aus zu Analysezwecken bereit. Entsprechend des Begriffs des Daten-

68

Data Warehouse-Architektur

beschaffungsbereichs wird der Bereich mit den Komponenten Basisdatenbank, Data Warehouse und Analyse auch als Auswertebereich bezeichnet.

Abb. 3.2 Referenzmodell für die Architektur von Data Warehouse-Systemen (vgl. Bauer u. Günzel 2004)

Ferner existiert die Komponente des Repositoriums, welche Metadaten über den gesamten Data Warehouse-Prozess verwaltet und über den vorgeschalteten Metadaten-Manager bestückt und administriert wird. Über das Repositorium können alle anderen Komponenten des Data Warehouse-Systems mit Metadaten versorgt werden. Auf die unterschiedlichen Typen von Daten (wie z.B. Metadaten, Geschäftsdaten etc.) wird im folgenden Kapitel 3.1.4 ausgiebiger eingegangen. Als zentrale und somit wichtigste Komponente eines Data Warehouse-Systems gilt der Data Warehouse-Manager, der gemäß der Architektur den Ablauf des Data Warehouse-Prozesses durch diverse Kontrollflüsse steuert. Dabei ist er von der Initiierung, Steuerung und Kontrolle der einzelnen Prozesse beginnend mit der Extraktion der Daten aus Datenquellen in den Arbeitsbereich, über das ordnungsgemäße Laden der Daten in die Basisdatenbank, bis hin zur Analyse der integrierten Daten im Data Warehouse verantwortlich. Während dessen steuert der Data Ware-

Grundlagen zur Data Warehouse-Architektur

69

house-Manager beispielsweise die Initiierung des Datenbeschaffungsprozesses, indem er entweder in regelmäßigen Zeitintervallen, bei Datenänderungen oder auf explizites Verlangen des Anwenders den Prozess der Datenbeschaffung auslöst (vgl. Bauer u. Günzel 2004, Marx Gómez et al. 2006).

3.1.4 Daten, Datenquellen und Datenqualität In diesem Abschnitt geht es um die wichtigsten Aspekte rund um den Inhalt eines Data Warehouse. Dabei steht die Beantwortung der folgenden Fragestellungen im Vordergrund:  Was für Typen von Daten können in einem Data Warehouse abgelegt werden und welche Eigenschaften besitzen sie?  Welche Datenquellen kommen für die Verwendung in einem Data Warehouse zum Einsatz, nach welchen Kriterien werden diese ausgewählt und in welchem Zusammenhang stehen diese zur allgemeinen Datenqualität im Data Warehouse?  Anhand welcher Merkmale kann die Datenqualität der Daten in einem Data Warehouse gemessen werden? 3.1.4.1

Daten

In einem Unternehmen fallen unterschiedliche Typen von Daten an. Davon eignen sich jedoch nicht alle zur Weiterverarbeitung und Auswertung in einem Data Warehouse. Bei den verwendbaren Daten für ein solches System wird zwischen Geschäfts- und Metadaten unterschieden (vgl. Marx Gómez et al. 2006). Diese Datenarten werden im Folgenden kurz erläutert:  Bei Geschäftsdaten handelt es sich um alle Daten, die bei der Abarbeitung von Geschäftsprozessen verwendet werden, bzw. die bei der Ausführung von Geschäftsprozessen entstehen. Sie werden wiederum in drei Schichten unterteilt: –

Echtzeitdaten gelten als Datenbasis für operative Systeme. Sie werden im laufenden Betrieb häufig gelesen und manipuliert, wodurch sie als hochaktuell und sehr detailliert charakterisiert werden. Zwar werden die Echtzeitdaten in ihrer nicht konsolidierten Form nur indirekt zum Entscheidungsprozess herangezogen, d.h. sie werden nicht dauerhaft im Data Warehouse für Analysezwecke gespeichert, jedoch bilden sie die Grundlage für die beiden übergeordneten Schichten im Data Warehouse (vgl. Devlin 1997). Beispiele für Echtzeitdaten ist der Monatsumsatz eines Unternehmens in den Vereinigten Staaten von Amerika (in US-Dollar) oder der Quartalsumsatz seiner Außenstelle in Europa (in Euro).

70

Data Warehouse-Architektur

–

–

Konsolidierte Daten werden aus den Echtzeitdaten erzeugt und zeichnen sich durch einen historischen Charakter aus. Bei der Erzeugung ist es wichtig, eine hohe systemweite Konsistenz zu erreichen, indem Datentypen, Semantik und Zeitbezug vereinheitlicht werden. Durch die Verwendung eines passenden Datenmodells können so gegenwärtige und zukünftig mögliche Beziehungen zwischen den Daten abgebildet werden (vgl. Marx Gómez et al. 2006). In Anlehnung an das obige Beispiel resultiert dies in einer Vereinheitlichung der monatlichen Umsätze aus den Vereinigten Staaten von Amerika und Europa in Form einer Einheitswährung (z.B. US-Dollar) und eines einheitlichen Zeitbezuges in Quartalen. Abgeleitete Daten sind letztlich die Daten, die zur Entscheidungsunterstützung in einem Data Warehouse genutzt werden. Zu diesem Zweck werden sie über einen wohldefinierten Prozess aus den konsolidierten Daten generiert. Je nach Anforderung der Aufgabenstellung kann der Aggregationsgrad an dieser Stelle variieren (vgl. Lambert 1996). Ein Vorteil der Verwendung abgeleiteter Daten ist das verbesserte Antwortzeitverhalten, da zeitintensive Operationen bereits bei der Ableitung aus den konsolidierten Daten ausgeführt worden sind und somit spätere Analysen im Data Warehouse nicht unnötig verlangsamt werden (vgl. Marx Gómez et al. 2006). Im Beispiel ergibt eine Aufsummierung aller konsolidierten Quartalsumsätze auf Jahresumsätze für das gesamte Unternehmen. Dieser einzige Datensatz gilt dann als abgeleitetes Datum und steht dem Anwender unmittelbar für Analysezwecke bereit.

 Bei Metadaten handelt es sich um Daten über Daten. Erst in Verbindung mit Metadaten werden gespeicherte Daten aussagekräftig und durch Menschen und Maschinen interpretierbar. Die Ziffer 7 beispielsweise wird erst durch die Ergänzung der Einheit Euro als Geldbetrag verstanden. Grundsätzlich werden zwei Arten von Metadaten unterschieden: –

–

Technische Metadaten (technical metadata) enthalten Informationen, die auf der Informatikseite zur Administration der Datenbanksysteme benötigt werden. Dabei handelt es sich unter anderem um Informationen über Datenbanktabellen, deren Attributbezeichnungen und Datentypen (vgl. Inmon 2006). Betriebswirtschaftliche Metadaten (business metadata) sind im Gegensatz dazu für die Anwenderseite relevant. Sie geben Auskunft über den betriebswirtschaftlichen Kontext der gespeicherten Daten, wie etwa über die Terminologie betrieblicher Kommunikation oder über das zugrundeliegende Unternehmensmodell (vgl. Devlin 1997).

Grundlagen zur Data Warehouse-Architektur

3.1.4.2

71

Datenquellen

Gemäß der Data Warehouse-Architektur aus Abbildung 3.2 geht die datenflussorientierte Betrachtung eines solchen Systems von der Datenquelle aus. Der in der Architektur verwendete singuläre Ausdruck „Datenquelle“ soll in diesem Zusammenhang auch für eine Mehrzahl an zu integrierenden, meist heterogenen realen Datenquellen stehen. Die Datenquelle selbst ist zwar kein Bestandteil des Data Warehouse-Systems, jedoch gilt sie als Ausgangspunkt des Datenflusses beim Data Warehousing. Ziel der Auswahl geeigneter Datenquellen für das Data Warehouse ist es, eine möglichst hohe Datenqualität zu erreichen. Daher wird der Auswahl der Datenquellen bei der Modellierung von Data Warehouse-Systemen eine besondere Aufmerksamkeit zuteil. Dieser Aspekt wird auch durch die Begründung verstärkt, dass sich die Beschaffenheit der Daten innerhalb der Datenquellen unmittelbar auf die Beschaffenheit der späteren Analyseergebnisse auswirkt. Insofern kann es bei Problemen in Bezug auf die Qualität der Analyseergebnisse oftmals hilfreich sein, die Qualität der einbezogenen Datenquellen zu überprüfen, um auf diesem Wege eventuelle Ursachen aufzudecken (vgl. Bauer u. Günzel 2004). Bauer und Günzel stellen vier Faktoren bei der Betrachtung und Auswahl von relevanten Datenquellen in den Vordergrund (vgl. Bauer u. Günzel 2004):    

Der Zweck des Data Warehouse-Systems Die Qualität der Quelldaten Die Verfügbarkeit (rechtlich, sozial, organisatorisch, technisch) Der Preis für den Erwerb der Quelldaten

Jeder einzelne Faktor hat einen solch hohen Einfluss auf das Gelingen des Data Warehouse-Vorhabens, dass er bei unzureichender Berücksichtigung zum Scheitern der gesamten Umsetzung des Data Warehouse-Systems führen kann. Aufgrund dieser hohen Relevanz werden die einzelnen Faktoren im Folgenden noch etwas detaillierter beleuchtet. Zweck des Data Warehouse-Systems In erster Linie müssen die relevanten Datenquellen mit dem Verwendungszweck des Data Warehouse-Systems übereinstimmen. Dies kann nicht selten dazu führen, dass der bisherige, operative Datenbestand zur Erfüllung des Zwecks einer Data Warehouse-Anwendung erweitert werden muss. Somit kann die Einführung einer Data Warehouse-Anwendung auch Auswirkungen auf die originären Daten, sowie auf deren Strukturen haben. Dies wiederum kann unter Umständen soweit führen, dass sich Konsequenzen für die den Daten zugrunde liegenden Realobjekte ergeben. Ein Beispiel dafür gibt die Firma BASF, die den physischen Lagerbestand ihrer Produktpalette um 27% reduzieren konnte, indem Redundanzen und Datenanomalien innerhalb der Datenquellen beseitigt wurden (vgl. Soeffky 1998).

72

Data Warehouse-Architektur

Qualität der Quelldaten An die Beschaffenheit der Quelldaten innerhalb der relevanten Datenquellen werden von verschiedenen Seiten unterschiedliche qualitative Anforderungen gestellt. So haben beispielsweise Nutzer und Betreiber, aber auch Planer und Entwickler eines Data Warehouse-Systems, gewisse qualitative Ansprüche an die Beschaffenheit der Quelldaten. Typische Beispiele für Qualitätsmängel sind (vgl. Bauer u. Günzel 2004):        

fehlerhafte Daten, verursacht durch Eingabe-, Mess- und Verarbeitungsfehler logisch widersprüchliche Daten unvollständige, ungenaue bzw. zu grobe Daten Duplikate im Datenbestand uneinheitlich repräsentierte Daten veraltete Daten für den Verwendungszweck irrelevante Daten unverständliche Daten, bedingt durch qualitativ mangelhafte Metadaten

Wie bereits einleitend erwähnt kann eine mangelhafte Qualität der Quelldaten im schlimmsten Fall das Scheitern des gesamten Data Warehouse-Projekts zur Folge haben. Glücklicherweise ist es jedoch weitaus häufiger der Fall, dass „nur“ erhebliche Zusatzkosten entstehen und das Gesamtprojekt dennoch erfolgreich durchgeführt werden kann (vgl. Bauer u. Günzel 2004). Nach Helfert entstehen die Zusatzkosten dabei aus drei Gründen: Durch die nachträgliche Bereinigung von Qualitätsmängeln, durch die aus fehlerhaften Einschätzungen im Rahmen der Datenanalyse resultierenden taktischen und strategischen Fehlentscheidungen und durch die Unzufriedenheit sowie der daraus resultierenden Demotivation von Anwendern des Data Warehouse-Systems (vgl. Helfert 2000). Verfügbarkeit der Quelldaten Nach der Bestimmung geeigneter Datenquellen, deren Daten sowohl dem Zweck des Data Warehouse-Systems gerecht werden, als auch der gewünschten inhaltlichen Qualität entsprechen, muss im nächsten Schritt sichergestellt werden, dass diese Quelldaten für die Verwendung im Data Warehouse überhaupt verfügbar sind. Dazu müssen unter anderem folgende Fragestellungen beantwortet werden (vgl. Bauer u. Günzel 2004):  Organisatorische Voraussetzungen: – –

Dürfen die Daten der ausgewählten Datenquelle (E-Mail-Adressen, Telefonnummern etc.) im Data Warehouse von rechtlicher Seite überhaupt genutzt werden (Datenschutzgesetz)? Ist die Verwendung personenbezogener Daten mit dem Betriebsrat und/oder dem Datenschutzbeauftragen des Unternehmens abgesprochen?

Grundlagen zur Data Warehouse-Architektur

–

73

Sind die verwendeten Daten vertraulich zu behandeln (bei Bilanzen, Geschäftsberichten etc.) und kann diese Vertraulichkeit durch die Verwendung der Daten in einem Data Warehouse weiterhin sichergestellt werden?

 Technische Voraussetzungen: – – –

Ist die Zugriffsmöglichkeit auf die Daten auf technischer Ebene gegeben (geeigneter Softwareeinsatz, Rechner- und Netzwerkverfügbarkeit etc.)? Sind die Daten während der Übertragung vor unberechtigtem Zugriff geschützt? Ist die Datenübertragungsgeschwindigkeit zwischen Quellsystem und Data Warehouse hinreichend hoch?

Preis für den Erwerb der Quelldaten Beim Erwerb von externen Quelldaten entstehen in erster Linie direkte Kosten, deren Höhe je nach Dienstleistung stark variieren kann. Das Spektrum reicht dabei vom Erwerb kostenloser Daten (z.B. über das Internet) bis zur Inanspruchnahme kostenpflichtiger Datendienste, wie zum Beispiel Nachrichtendienste, Marktforschungsinstitute, Statistik- und Bundesämter etc. Doch auch durch die Verwendung von internen Daten können Kosten entstehen, deren Preis sich jedoch von der Unternehmenskultur abhängig gestaltet. Somit ist die Preisgestaltung für interne Daten eher eine unternehmensinterne Angelegenheit (vgl. Bauer u. Günzel 2004). 3.1.4.3

Datenqualität

Die Qualität der bereitgestellten Daten innerhalb eines Data Warehouse bestimmt, wie präzise und verlässlich analytische Aussagen über einen bestimmten Sachverhalt formuliert werden können. Das Ziel, möglichst genaue und sichere Entscheidungen für eine Unternehmung zu treffen, kann umso besser erreicht werden, je besser der Anwender informiert ist (vgl. Marx Gómez et al. 2006). Im Umkehrschluss formuliert, erhöht eine mangelhafte Datenqualität demnach das Risiko für Fehleinschätzungen (vgl. Devlin 1997). Die in der Fachliteratur häufig verwendete und durchaus prägnante Definition des Begriffs der (Daten-)Qualität „fitness for use“ (Wang 1998) ist in der Praxis nicht besonders hilfreich, so dass der Begriff Datenqualität in diesem Zusammenhang wie folgt definiert wird: „Grad, in dem ein Satz inhärenter Merkmale eines Datenprodukts Anforderungen erfüllt.“ (Hinrichs 2002)

74

Data Warehouse-Architektur

Um nun den Grad der Erfüllung von Anforderungen eines Datenprodukts (oder Datensatzes) zu messen, ist es notwendig, allgemein gültige (Qualitäts-)Merkmale von Daten zu identifizieren und – soweit möglich – zu klassifizieren. Die in Abbildung 3.3 skizzierte Taxonomie stellt dazu die wichtigsten Merkmale zur Spezifizierung der Qualitätsanforderungen von Daten zur Verfügung. Allerdings birgt diese Taxonomie das Problem der Quantifizierung des geforderten Erfüllungsgrades (vgl. Marx Gómez et al. 2006, Bauer u. Günzel 2004). Auf diese Problematik wird im weiteren Verlauf dieses Abschnitts noch tiefer eingegangen. Zunächst bedarf es einer kurzen Charakterisierung der in Abbildung 3.3 dargestellten Merkmale:

Abb. 3.3 Taxonomie von Datenqualitätsmerkmalen in UML-Notation (vgl. Hinrichs 2002)

Hinrichs unterscheidet in seiner Taxonomie zwischen den vier Kategorien Glaubwürdigkeit, Nützlichkeit, Interpretierbarkeit und Schlüsselintegrität, denen er die nachfolgend erläuterten verschiedenen Merkmale zugeordnet hat (vgl. Hinrichs 2002, Bauer u. Günzel 2004):  Glaubwürdigkeit – – –

Korrektheit: Die Attributwerte eines Datensatzes (im Informationssystem) sowie die zugehörigen Metadaten stimmen mit dem modellierten Sachverhalt in der realen Welt (in der Diskurswelt) überein. Konsistenz: Die Attributwerte eines Datensatzes weisen untereinander, zu anderen Datensätzen oder zu Metadaten keine logischen Widersprüche auf. Zuverlässigkeit: Die Attributwerte dürfen nicht mit einem Unsicherheitsfaktor belegt sein, d.h. sie dürfen nicht vage oder unsicher sein. Dies kann dadurch sichergestellt werden, wenn die Entstehung der Daten nachvoll-

Grundlagen zur Data Warehouse-Architektur

75

ziehbar ist (z.B. durch Festlegung eindeutiger Verfahrensvorschriften oder durch Ausschaltung objektiver Ermessensspielräume) und die Datenlieferanten als vertrauenswürdig eingestuft werden können (z.B. durch Einholen von Referenzen bei externen Datenquellen).  Nützlichkeit –

– – –

–

Vollständigkeit: Alle Attributwerte eines Datensatzes sind mit Werten belegt, die semantisch vom Wert NULL abweichen. Desweiteren beinhaltet diese Eigenschaft, dass alle im modellierten Weltausschnitt vorkommenden Entitäten im Informationssystem repräsentiert sind. Genauigkeit: Die Attributwerte eines Datensatzes liegen in dem „optimalen“ (jeweils vom Anwendungskontext abhängigen) Detaillierungsgrad vor. Zeitnähe: Die Attributwerte bzw. Datensätze sind nicht veraltet, so dass sie dem aktuellen Diskursweltzustand entsprechen. Redundanzfreiheit: Innerhalb einer Menge von Datensätzen kommen keine Duplikate vor. Duplikate gelten in diesem Zusammenhang als Datensätze, die dieselbe Entität der Diskurswelt beschreiben, aber – insbesondere aufgrund von Qualitätsmängeln – nicht notwendiger Weise in allen Attributwerten übereinstimmen. Relevanz: Der Informationsgehalt einer Menge von Datensätzen im Kontext einer gegebenen Anwendung deckt sich mit dem Informationsbedarf einer Anfrage bzw. Auswertung. Die Daten dienen folglich dem durch die Anwendung vorgesehenen Zweck.

 Interpretierbarkeit – –

–

Einheitlichkeit: Eine Menge von Datensätzen weist eine einheitliche Repräsentationsstruktur auf. Eindeutigkeit: Ein Datensatz kann eindeutig interpretiert werden, d.h. es müssen qualitativ hochwertige Metadaten vorliegen, die dessen Semantik festschreiben. Dabei ist wichtig, dass die Metadatenqualität wiederum im Hinblick auf die genannten Datenqualitätsmerkmale bewertet wird. Verständlichkeit: Ein Datensatz ist in seiner Begrifflichkeit und Struktur so repräsentiert, dass er mit der Vorstellungswelt eines Fachexperten übereinstimmt. Dies kann beispielsweise über eine ausführliche Dokumentation für alle kodierten Werte erfolgen.

 Schlüsselintegrität – –

Schlüsseleindeutigkeit: Die Primärschlüssel eines Datenbestands sind eindeutig. Referenzielle Integrität: Jeder Fremdschlüssel referenziert einen existierenden Primärschlüssel und die über die Metadaten spezifizierte Multiplizität der Beziehung (1:0..1, 1:1, 1:1..*, 1:* in UML-Notation) wird eingehalten (im relationalen Datenmodell).

76

Data Warehouse-Architektur

Diese Charakteristika gelten als Basis zur Definition der Qualitätsanforderungen an den Betrachtungsgegenstand. Der Erfüllungsgrad einer Anforderung an ein Qualitätsmerkmal eines gegebenen Datenbestands kann jedoch variieren und ein Erfüllungsgrad von 100% wird unter Praxisbedingungen sicherlich nicht erreicht. Dies wird bzw. darf jedoch von den aufsetzenden Auswertungsverfahren auch nicht gefordert werden. Vielmehr geht es bei dem vorliegenden Verfahren um die Spezifikation von Soll-Werten für das Analysevorhaben, die einer notwendigen „Mindestqualität“ entsprechen (vgl. Hinrichs 2002). Desweiteren ist anzumerken, dass die Qualitätsanforderungen an den Betrachtungsgegenstand und demzufolge auch das Ergebnis der Qualitätsprüfung sehr stark von subjektiven Einschätzungen abhängt. Dies verstärkt das allgemeine Problem der Quantifizierung des geforderten Erfüllungsgrades. Dementgegen sind die Ursachen für Datenqualitätsprobleme jedoch üblicherweise objektiv feststellbar. Sie lassen sich in der Regel durch eine systematische Analyse der beteiligten Datenquellen und der darauf arbeitenden Geschäftsprozesse und Softwarekomponenten identifizieren und beheben (vgl. Bauer u. Günzel 2004).

3.1.5 Datenmodell Dieser Abschnitt befasst sich mit der konzeptuellen Modellierung einer Datenbank für ein Data Warehouse-System, welche sehr stark durch das multidimensionale Datenmodell geprägt ist. Dieses multidimensionale Datenmodell erlaubt es, auswertungsorientierte Schemata für das Data Warehouse zu definieren. Zum besseren Verständnis sollen dazu einleitend zunächst die Begriffe Modell und Schema definiert werden: „Ein Modell ist ein abstraktes, immaterielles Abbild realer Strukturen bzw. des realen Verhaltens für Zwecke des Subjekts.“ (Rautenstrauch 2003) Durch die Modellierung eines zu behandelnden Phänomens in Form einer sprachlichen Darstellung ist es demnach möglich, für den Sachzusammenhang irrelevante Einflüsse zu ignorieren und die relevanten Größen hervorzuheben, um eine vereinfachte Sicht auf das Subjekt zu erhalten. Das Datenmodell wiederum enthält korrekte und aussagekräftige Definitionen der Unternehmensdaten und beschreibt, auf welche Art und Weise Daten in einem Datenbanksystem gespeichert und manipuliert werden können. Desweiteren enthält das Datenmodell gewisse Regeln zur Datenverwendung, damit Eigenschaften wie Konsistenz, Korrektheit und Vollständigkeit gewahrt bleiben. Ein Datenmodell bewegt sich immer auf konzeptueller Ebene, so dass es vom Zielsystem weitestgehend unabhängig ist (vgl. Holthuis 2002). Auch der Begriff des Schemas spielt an dieser Stelle eine wichtige Rolle: Ein Modell gibt ein Schema vor, von dem unterschiedliche Ausprägungen instanziiert

Grundlagen zur Data Warehouse-Architektur

77

werden. Ein Beispiel für ein Schema ist das der Flughafencodes der International Air Transport Assoziation (IATA). Der IATA-Flughafencode ist eine Kombination von jeweils drei alphabetischen Zeichen von A-Z. Es ergeben sich dadurch 26 · 26 · 26 = 263 = 17.576 mögliche Ausprägungen zu diesem Schema – in diesem Fall zur eindeutigen Kennzeichnung von Verkehrsflughäfen. Hat ein Schema entgegen diesem Beispiel keine Referenz auf Objekte der Realwelt, so wird das zugrundeliegende Modell auch als Metamodell bezeichnet. Aus diesem Grund handelt es bei allen Datenmodellen – wie beispielsweise das relationale oder multidimensionale Datenmodell – um Metamodelle (vgl. Bauer u. Günzel 2004). Ein Datenmodell dient in erster Linie der Kommunikation zwischen der ITAbteilung und den Entscheidungsträgern. Dabei ist es zum einen erforderlich, das Modell möglichst einfach und überschaubar zu halten, damit Entscheidungsträgern ohne Fachkenntnisse der Datenverarbeitung (DV) das Verständnis erleichtert wird. Zum anderen muss das Datenmodell eng an den Erfordernissen des Unternehmens orientiert sein, damit auch die Mitarbeiter der IT-Abteilung die Anforderungen verstehen, das Modell umsetzen und somit letztlich die geforderten Anwendungen entwickeln können. Eine hinreichende Detaillierung ist dabei von Vorteil, weil das Datenmodell als Grundlage zur Erstellung eines Datenbankschemas herangezogen wird. Aus dieser Überlegung resultiert, dass die Anforderungen von Entscheidungsträgern und der IT-Abteilung an das Datenmodell divergieren. Um dieses Problem zu lösen, bietet sich eine Unterteilung in drei Schichten an, in der zwischen Fach-, DV- und Implementierungskonzept unterschieden wird. Hierbei kann im Fachkonzept zunächst die betriebswirtschaftliche Problemstellung semiformal und damit implementierungsunabhängig festgehalten werden, worauf dann die Anforderungen und Restriktionen in Bezug auf die DVtechnische Umsetzung in Form des DV-Konzepts aufgesetzt werden, um die Umsetzung schließlich im Implementierungskonzept zu formulieren (vgl. Marx Gómez et al. 2006). Eine Umsetzung dieses Konzepts ist das sehr verbreitete ARIS-Konzept, das von August-Wilhelm Scheer entwickelt wurde. ARIS wird bei der Architektur integrierter Anwendungssysteme genutzt. Die darauf basierende Modellierungssoftware ARIS Toolset bildet über die Organisations-, Daten-, Funktions-, Steuerungs- und die später ergänzte Leistungssicht das gesamte Unternehmen ab, wobei das Datenmodell als ein Teil dieses umfassenden Unternehmensmodells gilt (vgl. Scheer u. Jost 2002). Die Verbindungen der einzelnen Sichten werden durch das gleichermaßen gebräuchliche ARIS Haus repräsentiert, worin alle Sichten mit Ausnahme der Leistungssicht jeweils in Fach-, DV- und Implementierungskonzept unterteilt werden. Somit bietet das ARIS Toolset sowohl für Fach-, als auch für Führungskräfte ein großes Nutzenpotential, da umfassende Modelle mit variablem Detaillierungsgrad erstellt werden können (vgl. Karcher 2005).

78

Data Warehouse-Architektur

3.1.5.1

Fakten, Kennzahlen, Merkmale und Dimensionen

Die im vorherigen Abschnitt angesprochenen Geschäftsdaten in einem Data Warehouse werden in Fakten, Kennzahlen und Merkmale unterteilt. Diese Begriffe sollen zunächst kurz definiert und erläutert werden. „Fakten sind numerische Messgrößen, die betriebliche Sachverhalte beschreiben.“ (Sattler u. Saake 2004) Fakten werden häufig auch als Basiskennzahlen bezeichnet, da aus ihnen durch arithmetische Operationen Kennzahlen abgeleitet werden. Demnach ergibt sich die folgende Definition für den Begriff der Kennzahlen: „Kennzahlen sind Fakten oder aus Fakten abgeleitete Größen. Sie haben informativen Charakter und dienen dazu, durch systematisches Vergleichen Ursachen und Trends ableiten zu können.“ (Rautenstrauch 2004) In einem Beispiel gelten Umsatz und Kosten als Fakten, aus denen die Kennzahl Gewinn berechnet wird. Kennzahlen erhalten jedoch erst durch die Zuordnung weiterer, beschreibender Attribute eine Aussagekraft. Diese Attribute werden in diesem Zusammenhang auch als Merkmale bezeichnet und definieren sich wie folgt: „Merkmale sind betriebswirtschaftliche Bezugsgrößen, nach denen eine sinnvolle Gruppierung von Kennzahlen möglich ist.“ (Mehrwald 2007) Das multidimensionale Datenmodell eines Data Warehouse kann anhand eines Würfels visualisiert werden (siehe Abb. 3.4). Streng betrachtet handelt es sich dabei um einen Quader, die Verwendung der Bezeichnung Würfel hat sich jedoch im Laufe der Zeit eingebürgert. Als weitere synonyme Termini finden sich in der Literatur auch die Begriffe Daten- und Hyperwürfel (Hypercube). Die Bezeichnung Hypercube rührt daher, dass der gesamte Würfel wiederum aus vielen kleinen Würfeln besteht, die auf elementarer Ebene einzelne Datensätze repräsentieren. Dabei werden die Achsen als Dimensionen bezeichnet, auf denen die Kriterien zur Einordnung der Daten abgetragen werden (vgl. Marx Gómez et al. 2006). „Dimensionen beschreiben die technische Struktur der Daten und so eine mögliche Sicht auf die assoziierte Kennzahl.“ (Sattler u. Saake 2004) Das in Abbildung 3.4 dargestellte Beispiel eines Datenwürfels beinhaltet die drei Dimensionen Studienfach, Studienabschnitt und Semester. Die Anzahl der Dimensionen in einem Hypercube kann jedoch in der Praxis über drei hinaus gehen, wodurch auch der Begriff der Multidimensionalität geprägt ist. Die Darstellung eines Hypercubes mit mehr als drei Dimensionen ist jedoch grafisch nicht möglich.

79

Studienabschnitt

Se

m

es

te r

Studienfach

Grundlagen zur Data Warehouse-Architektur

Abb. 3.4 Datenwürfel

Im multidimensionalen Datenmodell wird zwischen hierarchischen und nichthierarchischen Dimensionstypen unterschieden. Dabei ermöglichen Erstere aufgrund ihres hierarchischen Charakters unterschiedliche Verdichtungsstufen und Verdichtungsniveaus, welche über feste Regeln und Berechnungsvorschriften gebildet werden. So kann beispielsweise eine Produkthierarchie aus den Verdichtungsstufen Produkthauptgruppe und Produktgruppe bestehen, indem sich die Werte der Produkthauptgruppe aus der Summe der Werte der untergeordneten Produktgruppe ergeben. Nicht-hierarchische Dimensionen hingegen bieten diese Eigenschaft nicht, da sie eine einfache interne Struktur aufweisen, die keine vertikalen Beziehungen enthält und somit keine Aggregationen über mehrere Ausprägungen gebildet werden können. Ein Beispiel für eine nicht-hierarchische Dimensionen ist eine Dimension mit den Elementen Ist, Soll und Plan, da in diesem Fall unterschiedliche Szenarien des gleichen Sachverhalts einander gegenübergestellt werden (vgl. Marx Gómez et al. 2006). Als ein weiterer Typ von Dimensionen gilt der kategorische Dimensionstyp. Da zu Analysezwecken in unterschiedlichen Anwendungsfeldern oftmals Sachverhalte der realen Welt im Vordergrund stehen, werden deren Eigenschaften als eigenständige Dimensionen abgebildet. So sind zum Beispiel beim Marketing genaue Kundeninformationen, wie Geschlecht, Alter oder Familienstand, derart bedeutsam, weil sie die Analysebedürfnisse des Anwendungsfeldes sehr stark widerspiegeln, dass deren Ausprägungen in eigenen Dimensionen angeordnet werden (vgl. Holthuis 2002). Nach Holthuis können innerhalb von Dimensionen jedoch auch Strukturanomalien auftreten (vgl. Holthuis 2002). Sofern einer Dimension ein unausgeglichener Hierarchiebaum zugrunde liegt, ist die Durchführung von Aggregationsoperationen eingeschränkt. So ist zum Beispiel eine weltweite Datenanalyse nach Bundesländern nicht möglich. Ähnliche Einschränkungen ergeben sich weiterhin bei parallelen Hierarchien, bei denen die Kriterien für Dimensionspositionen einer Ebene nicht überschneidungsfrei formuliert werden können (Beispiel: Unterschiedliche Kundengruppen aus gleichen Elementarpositionen), oder auch bei multiplen Hierarchien, bei denen innerhalb des Hierarchiebaums nicht gewährleistet werden kann, dass jeder Knoten nur einen Vaterknoten besitzt (Beispiel: Er-

80

Data Warehouse-Architektur

mittlung von Personalkosten, wenn eine Rechnungslegungsabteilung für zwei oder mehr übergeordnete Abteilung tätig ist). 3.1.5.2

OLAP Operationen

Es existiert eine Vielzahl von Anfrageoperationen, die auf multidimensionalen Datenstrukturen zur Datenanalyse verwendet werden können. Entgegen der einleitend erwähnten Begriffsvielfalt im Bereich der Data Warehouse Technologie ergibt sich im Hinblick auf diese Operationen ein weitgehender inhaltlicher Konsens. Da die Anfrageoperationen der Unterstützung des OLAP-Konzepts dienen, werden sie auch als OLAP-Operationen bezeichnet. Die grundlegendsten OLAPOperationen sollen in diesem Abschnitt kurz vorgestellt werden. Die zum besseren Verständnis verwendeten Abbildungen skizzieren ein fiktives Szenario über die Studierendenanzahl an einer Universität. Die Dimension Studienfach umfasst dabei die Elemente SOZ (Soziologie), EuWi (Europäische Wirtschaft), VWL (Volkswirtschafslehre), BWL (Betriebswirtschaftslehre) und WI (Wirtschaftsinformatik). Die Dimension Studienabschnitt besteht aus den Elementen GS (Grundstudium) und HS (Hauptstudium), die Dimension Zeit enthält die einzelnen Semester (vgl. Böhnlein u. Ulbrich-vom Ende 2000). Rotate: Um verschiedene Sichten auf den betrachteten Datenbestand zu erhalten, wird der Datenwürfel durch diese Operation gedreht. Dieses Vertauschen der Dimensionen wird im Deutschen auch als Pivotierung oder Rotation bezeichnet (siehe Abb. 3.5).

Abb. 3.5 Rotate (vgl. Böhnlein u. Ulbrich-vom Ende 2000)

Drill-Down: Erlaubt das Durchlaufen von Verdichtungsebenen innerhalb einer Dimensionshierarchie, indem von einem bestimmten Aggregationsniveau auf die nächsttiefere und damit detailliertere Verdichtungsstufe gestiegen wird (siehe Abb. 3.6).

Grundlagen zur Data Warehouse-Architektur

81

Abb. 3.6 Drill-Down (vgl. Böhnlein u. Ulbrich-vom Ende 2000)

Roll-Up: Komplementär zum Drill-Down ermöglicht diese Operation den Wechsel eines Aggregationsniveaus zur jeweils höheren Verdichtungsebene innerhalb einer Dimensionshierarchie (siehe Abb. 3.7).

Abb. 3.7 Roll-Up (vgl. Böhnlein u. Ulbrich-vom Ende 2000)

Drill-Through: Ist im Zuge der Operation Drill-Down die höchste Detaillierungsstufe erreicht, kann die physische Datenquelle durch diese Operation gewechselt werden, um noch detaillierte Daten zur Verfügung stellen zu können. Dieser Rückgriff kann sowohl andere relationale Quellen (z.B. operative Basisdaten), als auch weitere Datenwürfel umfassen und findet für den Nutzer unbemerkt statt (vgl. Manhart 2008a). Drill-Across: Ermöglicht den Wechsel zwischen Datenwürfeln, um beispielsweise eine Kennzahl über mehrere Würfel zu verfolgen, wenn Ist- und Soll-Daten in separaten Würfeln gehalten werden. Wichtig ist hierbei, dass die Dimensionen der verwendeten Würfel die gleiche Granularität aufweisen (vgl. Manhart 2008a). Slice: Bei einem dreidimensionalen Datenwürfel bewirkt diese Operation das Herausschneiden einer Scheibe aus dem Datenbestand, woraus sich eine zweidimensionale Matrix ergibt. Es werden also individuelle Sichten erzeugt und die Dimensionalität verringert (siehe Abb. 3.8).

82

Data Warehouse-Architektur

Abb. 3.8 Slice (vgl. Böhnlein u. Ulbrich-vom Ende 2000)

Dice: Durch diese Operation können einzelne Teilwürfel aus dem gesamten Hypercube extrahiert werden. Die Anzahl der Dimensionen bleibt erhalten, während sich jedoch die Hierarchie einzelner Dimensionen verändern kann (siehe Abb. 3.9).

Abb. 3.9 Dice (vgl. Böhnlein u. Ulbrich-vom Ende 2000)

3.1.5.3

Modellierung multidimensionaler Datenstrukturen mit ADAPT

Als ein möglicher Ansatz zur Modellierung multidimensionaler Datenstrukturen gilt das von Bulos im Jahr 1996 vorgestellte Application Design for Processing Technologies (ADAPT). Bei der Entwicklung dieses Modellierungsansatzes wurde primär das Ziel verfolgt, einen unabhängigen Modellierungsstandard zur Verbesserung der Kommunikation zwischen Entwicklern und Anwendern zu schaffen und dabei den Fokus auf mehrdimensionale Datenstrukturen speziell für OLAPAnwendungen zu richten (vgl. Bulos u. Forsman 2001). Die zunächst in Amerika weit verbreitete Methode ist erst seit einigen Jahren auch in Deutschland in der Diskussion. Aufgrund seiner zahlreichen Objekttypen stand der Modellierungsansatz anfangs stark in der Kritik, wurde jedoch im Zuge weiterer Veröffentlichungen immer weiter verbessert, so dass heute nur noch die wesentlichen Objekttypen Teil der aktuellen ADAPT Notation sind. Durch diese

Grundlagen zur Data Warehouse-Architektur

83

Verbesserungen können leicht lesbare und somit verständliche Modelle zur Darstellung von Dimensionsstrukturen und hierarchischen Strukturen konstruiert werden. Weiterhin ergibt sich ein zusätzlicher praktischer Nutzen durch Bereitstellung der zugrunde liegenden Symbole der ADAPT Notation in Form einer Vorlage für Microsoft Visio wodurch Datenmodelle mit ADAPT für jedermann einfach zu generieren sind (vgl. Hahne 2005). ADAPT Notation Gemäß Abbildung 3.10 enthält die aktuelle Version der ADAPT Notation die Objekttypen Cube (Hyperwürfel), Dimension (Dimension), Member (Dimensionselement), Scope (Elementgruppe), Hierarchy (Hierarchie), Level (Hierarchiebene), Attribute (Attribut), Model (Berechnungsvorschrift) und Context (Kontextcube). Durch die Verwendung dieser Objekttypen ist es möglich, vielfältige Dimensionsstrukturen mit einem betriebswirtschaftlichen Bezug zu modellieren (vgl. Hahne 2005). Cube

Hierarchy

Dimension1 Dimension2

{ } Dimension

{ }

Member

{ }

Scope

Level

Attribute

Model

Context

Abb. 3.10 ADAPT Notation - Objekttypen (vgl. Bulos u. Forsmann 2001)

Um die genannten Objekttypen im Zuge einer Modellierung zu einem ganzheitlichen multidimensionalen Datenmodell miteinander verbinden zu können und somit die unterschiedlichen Anforderungen bezüglich der Beziehungen zwischen Ebenen und Objekttypen abbilden zu können, sieht die ADAPT Notation auch eine Reihe von Verbindungsobjekten vor (siehe Abb. 3.11).

84

Data Warehouse-Architektur

Lockere Beziehung zwischen Ebenen

Strenge Beziehung

Rekursive Beziehung

m:n-Beziehung

Abb. 3.11 ADAPT Notation - Verbindungsobjekte (vgl. Hahne 2005)

Zur Vervollständigung der Notation sind in Abbildung 3.12 die ebenfalls in ADAPT vorgesehenen Beziehungstypen dargestellt. Diese erlauben es dem Entwickler des Datenmodells, Beziehungen zwischen unterschiedlichen Dimensionen zu modellieren und auf diese Weise die sogenannten Dimensionsausschnitte – auch Dimensionssichten genannt – abzubilden, die eine logisch zusammenhängende Teilmenge einer Dimension darstellen (vgl. Hahne 2005). Umfassendes Exklusiv-Oder

Umfassendes Oder

Partielles Exklusiv-Oder

Partielles Oder

Abb. 3.12 ADAPT Notation - Beziehungstypen (vgl. Hahne 2005)

Um die Verwendung der wesentlichen Komponenten von ADAPT darzustellen und die Modellierung multidimensionaler Datenstrukturen praktisch nachzuvollziehen, werden im Folgenden zwei Ausschnitte eines exemplarischen Szenarios skizziert. In Abbildung 3.13 ist dazu zunächst die Dimension Produkt als eine von unterschiedlichen Dimensionen des Hypercube Produkt-Umsatz Ist dargestellt.

Grundlagen zur Data Warehouse-Architektur

Produkt-Umsatz Ist

85

Produkt

Produkt ... Produkthierarchie

{ }

Eigene Produkte

{ }

Fremdprodukte

{ }

Produkthauptgruppe

{ }

Produktgruppe

{ }

Herstellerhierarchie

{ }

Hersteller

Produkt

ProduktID

Beschreibung

...

Abb. 3.13 ADAPT Notation - Beispiel: Produktdimension (vgl. Hahne 2005)

Als eine von mehreren Dimensionen des Hypercube Produkt-Umsatz Ist unterliegt die Dimension Produkt in diesem Beispiel den parallelen Hierarchien Produkthierarchie und Herstellerhierarchie. Die feinste Granularität bildet dabei wiederum die gemeinsame Basisebene Produkt. Die durch den Doppelpfeil ausgedrückte strenge Beziehung zwischen den Hierarchieebenen Produkt und Hersteller signalisiert, dass ein Produkt genau einem Hersteller zugeordnet werden kann. Anders verhält es sich in der parallelen Produkthierarchie, zwar kann dort ein Produkt mehreren oder keinen Produktgruppen zugeordnet werden, eine Produktgruppe wiederum ist jedoch genau einer Produkthauptgruppe zugeordnet. Weiterhin können durch den Einsatz von Attributen den Objekttypen zusätzliche Eigenschaften im Datenmodell verliehen werden. So wird das Dimensionselement Produkt über die Attribute ProduktID, Beschreibung etc. genauer spezifiziert. Außerdem enthält das hier angeführte Beispiel Dimensionsausschnitte bzw. Dimensionssichten, wodurch ein Produkt über den Beziehungstyp umfassendes Exklusiv-Oder entweder in die Teilmenge Eigene Produkte oder in die Teilmenge Fremdprodukte eingeordnet wird (vgl. Hahne 2005). Abschließend ist in Abbildung 3.14 ein weiteres Beispiel skizziert, worin der Fokus auf die Objekttypen Hypercube, Berechnungsvorschrift und Kontextcube gerichtet ist. Über Berechnungsvorschriften, wie beispielweise einer hier verwendeten Prognosefunktion, können betriebswirtschaftliche Größen modelliert werden. Die auch als Ableitungsregel bezeichnete Vorschrift errechnet in diesem abstrakt ge-

86

Data Warehouse-Architektur

haltenen Beispiel den prognostizierten Umsatz aus den Hypercubes ProduktUmsatz Ist und Produkt-Umsatz Soll. Der hier verwendete Kontextcube dient der partiellen Betrachtung eines Datenbestands, da häufig nicht der gesamte Hypercube für eine Analyse benötigt wird (vgl. Bulos u. Forsman 2001). Produkt-Umsatz Ist Produkt Buchungskreis Zeit Prognose

Prognostizierter Umsatz

Produkt-Umsatz Soll Produkt Buchungskreis Zeit

Abb. 3.14 ADAPT Notation - Beispiel: Berechnungsvorschrift (vgl. Hahne 2004)

T-ADAPT Das von Hahne entwickelte T-ADAPT-Konzept dient der Modellierung von Zeitaspekten innerhalb eines multidimensionalen Datenmodells und stellt somit eine Erweiterung des bisherigen ADAPT-Konzepts dar. Im Mittelpunkt dieses Ansatzes steht dabei die komplette Historisierung von Dimensionshierarchien, indem Hierarchien Gültigkeitszeiträume zugewiesen werden können. Im Zuge dieser temporalen Erweiterung sind zur Integration in die vorhandene ADAPT Notation neue Objekttypen entwickelt worden, um die Aspekte einer kontinuierlichen Historisierung ebenfalls im Datenmodell abbilden zu können (vgl. Hahne 2004). 3.1.5.4

Speicherung multidimensionaler Daten

Zur Speicherung multidimensionaler Daten existieren im Allgemeinen zwei Ansätze. In einigen kommerziell verfügbaren Systemen ist der erste Ansatz implementiert, der das Ziel verfolgt, das multidimensionale Modell auch auf der Ebene der physischen Speicherstruktur umzusetzen. Im zweiten Ansatz basiert die Speicherstruktur hingegen auf relationalen Datenbanken, deren Struktur den multidimensionalen Daten angepasst wird. Zurzeit ist kein klarer Trend zu verzeichnen, um vorherzusagen, welcher dieser beiden Ansätze sich in Zukunft etablieren wird. Zudem existiert weder ein eindeutiger Standard zur Festlegung der Grundfunktionalitäten für ein multidimensionales Datenbanksystem, noch eine einheitliche Form des Zugriffs auf solche Systeme, wie es etwa SQL für relationale Datenban-

Grundlagen zur Data Warehouse-Architektur

87

ken ist (vgl. Marx Gómez et al. 2006). Beide Ansätze sollen nachfolgend kurz erläutert und am Ende gegenübergestellt werden. Multidimensionales OLAP Beim multidimensionalen OLAP (MOLAP) kommen proprietäre, herstellerspezifische, multidimensionale Datenbanken zum Einsatz, die sich besonders durch eine hohe Funktionalität zur Analyse und Auswertung von Daten auszeichnen. Auf physischer Ebene wird dabei der sogenannte Hypercube-Ansatz verfolgt, der die Speicherung der Daten in einer multidimensionalen Matrix im Hauptspeicher vorsieht. Dadurch ergeben sich für MOLAP-Systeme sehr gute Antwortzeiten und im Ergebnis eine hohe Flexibilität und Schnelligkeit. Der Nachteil dieses Ansatzes liegt jedoch in der begrenzten Kapazität des Hauptspeichers (vgl. Sattler u. Saake 2004, Manhart 2008a). Außerdem nehmen Zellen mit Initial- oder NULL-Werten bei diesem Prinzip ebenso viel Speicher- und Verarbeitungskapazität in Anspruch wie belegte Zellen, die mit relevanten Einträgen gefüllt sind. Zwar gibt es für diese Fälle spezielle Verfahren, die leere Zellen identifizieren und diese daraufhin komprimieren. Dennoch wächst der Speicherbedarf bei dünn besiedelten Matrizen und mit steigender Anzahl an Dimensionen überproportional an (vgl. Holthuis 2002). Relationales OLAP Das relationale OLAP (ROLAP) speichert die Daten für die verschiedenen Anwendungsgebiete in mehreren unterschiedlichen Matrizen bzw. Tabellen. Für diesen sogenannten Multicube-Ansatz hat sich das Star-Schema als Standard für OLAP-Anwendungen im Data Warehouse durchgesetzt. Abbildung 3.15 zeigt ein Beispiel einer möglichen Ausprägung des Star-Schemas. Dimension

Buchungskreis

Faktentabelle

BUCHUNGSKREIS-ID Filiale

Produkt-Umsatz Ist BUCHUNGSKREIS-ID PRODUKT-ID ZEIT-ID Umsatz

Produkt PRODUKT-ID Produktgruppe Bezeichnung Dimension

Abb. 3.15 Star-Schema: Beispiel

Dimension

Zeit ZEIT-ID Quartal Jahr

88

Data Warehouse-Architektur

Im Zentrum eines jeden Star-Schemas steht eine Faktentabelle, die als Attribute die Kennzahlen (hier: Umsatz), die Fakt-Beschreibungen und die Fremdschlüssel für jede Dimensionstabelle enthält. Diese Primärschlüssel der Dimensionstabellen ergeben zusammengesetzt den Primärschlüssel der Faktentabelle. Die Dimensionstabellen wiederum verfügen über die qualitativen Daten zur Visualisierung der Dimensionen und Dimensionshierarchien, wobei die Dimensionselemente denormalisiert vorliegen, da funktionale Abhängigkeiten zwischen Nicht-Schlüsselattributen bestehen. Die Dimensionstabellen sind nur mit den Faktentabellen und somit nicht untereinander verknüpft, wodurch die namensgebende sternförmige Anordnung entsteht. Durch die Datenstruktur des Star-Schemas ergibt sich eine hohe Verarbeitungsgeschwindigkeit zu Lasten der Datenintegrität (vgl. Manhart 2008b). Da das Star-Schema keine hierarchischen Strukturen innerhalb der Dimensionen zulässt, wie sie in der Realität sehr häufig vorkommen, hat sich das Snowflake-Schema etabliert, welches auch hinsichtlich der Normalisierung als Verbesserung des verwandten Star-Schemas gilt. Die Faktentabelle bleibt in diesem Fall unverändert, während die Dimensionstabellen durch Aufgliederung ihrer Hierarchiestufen (Dimensionselemente) normalisiert werden. Das bereits oben eingeführte Beispiel wird in Abbildung 3.16 fortgesetzt. Hierbei ist zu erkennen, dass jede Ausprägung einer Dimension in einer eigenen Tabelle dargestellt ist und eine Schneeflockenform entsteht (vgl. Humm u. Wietek 2005). Filiale

Dimension

Filial-ID Land-ID

Buchungskreis

Faktentabelle

Quartal

BUCHUNGSKREIS-ID Filial-ID

Produkt-Umsatz Ist

Quartal-ID Quartal

Land Land-ID Bezeichnung

Produkt

Produktgruppe Produktgruppe-ID Bezeichnung

PRODUKT-ID Produktgruppe-ID Bezeichnung

BUCHUNGSKREIS-ID PRODUKT-ID ZEIT-ID Umsatz

Dimension

Zeit ZEIT-ID Quartal-ID Jahr-ID

Jahr Jahr-ID Jahr

Dimension

Abb. 3.16 Snowflake-Schema: Beispiel

Die Dimensionstabellen enthalten nicht mehr sämtliche Dimensionselemente, sondern lediglich Beschreibungen der Dimensionshierarchien. Als Vorteil ergeben sich kleinere und besser strukturierte Datenmengen, die außerdem weniger Redundanzen aufweisen. Dementgegen steht jedoch der Nachteil, dass durch die erhöhte Komplexität zeitintensive Join-Abfragen notwendig sind, die wiederum zu längeren Abfragezeiten führen. Dennoch hat der Einsatz eines SnowflakeSchemas bei sehr großen Dimensionstabellen mit vielen Attributen und beschränkter Hierarchietiefe durchaus seine Berechtigung (vgl. Humm u. Wietek 2005, Manhart 2008b).

Grundlagen zur Data Warehouse-Architektur

89

MOLAP vs. ROLAP Die Verwendung von MOLAP zur physischen Speicherung multidimensionaler Datenstrukturen bietet besonders für komplexe analytische Auswertungen, denen nicht allzu große Datenbasen zugrunde liegen, eine sehr hohe Performanz und ein breites Funktionsspektrum. Allerdings wird derzeit nur ein begrenztes Datenvolumen unterstützt und es sind weitestgehend keine Standards vorhanden, so dass MOLAP meist nur in proprietären Produkten zum Einsatz kommt (vgl. Humm u. Wietek 2005). ROLAP hingegen bietet eine hohe Performanz und Stabilität auch für große Datenmengen und gilt nach Humm und Wietek „in der Regel [als] die einfachere, kompaktere, preisgünstigere und flexiblere Lösung“ (Humm u. Wietek 2005). Liegen jedoch sehr komplexe multidimensionale Anfragen vor, ist die Funktionalität von ROLAP teilweise noch eingeschränkt. Da der Ansatz jedoch mit Starund Snowflake-Schema auf relationalen Datenbanken aufbaut, profitiert die Technologie auch von einer Vielzahl von Werkzeugen auf dem Markt, einem großen Maß an Fachwissen in den Unternehmen und somit von einer hohen Akzeptanz (vgl. Marx Gómez et al. 2006). Das hybride OLAP (HOLAP) verfolgt als ein weiterer Ansatz die Verbindung der Vorteile von MOLAP und ROLAP. Dabei werden Detaildaten in einer relationalen und aggregierte Daten in einer multidimensionalen Datenbank gespeichert. (vgl. Sattler u. Saake 2004). Auch Galaxien, als Ansammlungen von StarSchemata, die Dimensionstabellen aus Konsistenzgründen mehrfach verwenden und somit eine geringere Anzahl an Join-Operationen benötigen, gelten als weiterer möglicher Ansatz (vgl. Manhart 2008b).

3.1.6 Phasen des ETL-Prozesses Gemäß der in Kapitel 3.1.3 vorgestellten Data Warehouse-Architektur gilt der Arbeitsbereich als die zentrale Datenhaltungskomponente des Datenbeschaffungsbereichs. Wie in Abbildung 3.2 zu erkennen, ist der Arbeitsbereich dabei funktional zwischen den Datenquellen und der Basisdatenbank angesiedelt. Die Hauptaufgabe des Datenbeschaffungsbereichs besteht folglich darin, die relevanten Daten aus heterogenen Datenquellen zu integrieren und sie der Basisdatenbank und daraufhin dem eigentlichen Data Warehouse zu Analysezwecken zur Verfügung zu stellen. Die Datenbeschaffung selbst kann dabei als ein Prozess bezeichnet werden, der periodisch durchgeführt wird. Dadurch wird sichergestellt, dass Analysen immer auf aktuellen Daten aus den unterschiedlichen Quellsystemen basieren. Die an den Arbeitsbereich angrenzenden Komponenten Extraktion (Replizieren der relevanten Daten in den Arbeitsbereich), Transformation (Konsolidierung der Daten) und Laden (Kopieren der Daten in die Basisdatenbank und in das Data Warehouse selbst) bilden den sogenannten ETL-Prozess, dessen Bezeichnung sich

90

Data Warehouse-Architektur

aus den jeweils ersten Buchstaben der drei Komponenten ergibt. Der Arbeitsbereich dient in diesem Zusammenhang der temporären Zwischenspeicherung beliebiger Daten auf dem Weg von den Datenquellen in die Basisdatenbank. Auf diese Weise können Datentransformationen direkt im Zwischenspeicher ausgeführt werden, wodurch keine Beeinträchtigung der Datenquellen oder der Basisdatenbank im laufenden Betrieb erfolgt. Sind alle Schritte des ETL-Prozesses durchgeführt, werden die aufbereiteten Daten vom Arbeitsbereich in die Basisdatenbank übertragen (vgl. Bauer u. Günzel 2004). In den nachfolgenden Abschnitten werden die drei Phasen des ETL-Prozesses näher erläutert. Vor Beginn der ersten Phase zur Extraktion der Daten aus den Datenquellen muss jedoch eine Reihe von administrativen Schritten ausgeführt werden, damit eine problemlose Durchführung des ETL-Prozesses gewährleistet ist. Dabei geht es sowohl um die Identifikation der inhaltlich relevanten Daten und deren Quellsysteme, die für eine Verwendung im Data Warehouse in Frage kommen, als auch um die Vorbereitung der ausgewählten Datenquellen für eine Replikation ins Data Warehouse. Letzteres umfasst beispielsweise die Aufhebung von Lesesperren oder die Minimalhaltung der Sperrzeiten auf den Daten der Quellsysteme, damit die Quelldaten den Anwendern auch weiterhin möglichst uneingeschränkt zur Verfügung stehen (vgl. Devlin 1997). 3.1.6.1

Extraktionsphase

In der ersten Phase des ETL-Prozesses werden die Regeln für die Verbindung des Quellsystems mit dem Data Warehouse und die Übertragung der Daten angelegt. Diese Regeln umfassen dabei Informationen darüber, wie und vor allem wann welche Daten vom Quell- in das Zielsystem übertragen werden. Als Beispiel ist die Komprimierung der zu extrahierenden Daten sinnvoll, sofern sehr große Datenvolumina in das Data Warehouse übertragen werden sollen. Die Festlegung eines geeigneten Zeitpunktes für die Extraktion hingegen hängt dabei entscheidend von der Semantik der Daten bzw. von den auf den Daten durchzuführenden Analysen ab (vgl. Bauer u. Günzel 2004). Bei der Wahl eines geeigneten Zeitpunkts für die Extraktion wird grundsätzlich zwischen einer zeitlich synchronen und einer zeitlich asynchronen Extraktion unterschieden. Die synchrone Extraktion zeichnet sich dadurch aus, dass jede Änderung am Quellsystem sofort an das Data Warehouse übermittelt wird, was zwar bei der Notwendigkeit einer hohen Aktualität von Daten für die Analyse äußerst sinnvoll ist, jedoch eine moderate Belastung der Netzverbindung und der betroffenen System zur Folge hat. Die asynchrone Extraktion hingegen sieht die Replikation der Daten vom Quell- ins Zielsystem in bestimmten Zeitfenstern vor, in denen ausreichende Ressourcen zur Ausführung des Extraktionsprozesses vorhanden sind (z.B. nachts oder am Wochenende). Eine asynchrone Extraktion erfolgt periodisch, ereignis- oder anfragegesteuert (vgl. Marx Gómez et al. 2006). Die prin-

Grundlagen zur Data Warehouse-Architektur

91

zipiellen Vorgehensweisen beider Typen einer Extraktion sind nachfolgend näher beschrieben (vgl. Kimball et al. 2008, Bauer u. Günzel 2004):  Sofort: Gemäß der Charakteristika einer synchronen Extraktion werden bei diesem Verfahren Änderungen an die Daten im Quellsystem sofort auch in das Data Warehouse-System propagiert. Auf diese Weise sind die Daten im Data Warehouse von gleicher Aktualität wie die Daten im Quellsystem. Ein Beispiel ist die Analyse von Börsenkursen.  Periodisch: Als eine Vorgehensweise der asynchronen Extraktion kann die Extraktion der Daten aus dem Quell- ins Zielsystem periodisch ausgeführt werden (zweimal pro Tag, einmal pro Monat etc.). Hierbei hängt die Periodendauer stark von der Dynamik der Daten ab. Börsenkurse oder Wetterdaten werden zum Beispiel täglich aktualisiert, während bei technischen Beschreibungen von Produkten hingegen eine längere Periodendauer ausreicht.  Anfragegesteuert: Ebenfalls asynchron verläuft die Auslösung einer Extraktion durch eine explizite Anfrage. In diesem Fall kann die Extraktionskomponente direkt angewiesen werden, die Daten aus den Quellsystemen in das Data Warehouse zu replizieren. Ein denkbares Szenario hierfür ist die Aktualisierung der Daten im Data Warehouse nach Einführung eines neuen Produkts.  Ereignisgesteuert: Weiterhin ist es denkbar, den Extraktionsvorgang durch ein Zeit-, Datenbank- oder externes Ereignis auszulösen. Beispiele für solche Ereignisse sind das Erreichen einer festgelegten Anzahl an Änderungen im Quellsystem (Datenbankereignis) oder das Über- bzw. Unterschreiten einer bestimmten Marke eines Börsenwerts (externes Ereignis). Bei genauerer Betrachtung können auch periodische und anfragegesteuerte Extraktionen als ereignisgesteuert bezeichnet werden, da auch Zeitpunkte oder eine durch einen Anwender ausgelöste Anfrage als Ereignis gewertet werden können. Ist die Entscheidung über den zeitlichen Aspekt des Extraktionsprozesses getroffen, bedarf es außerdem der Wahl zwischen einer statischen oder inkrementellen Extraktion (vgl. Devlin 1997). Unter einer statischen Extraktion ist das Erstellen eines Abbilds des gesamten Datenbestands des Quellsystems zu verstehen. Da das Erstellen eines solchen Abbilds einer vollständigen Quelldatenbank meist durch ein großes Datenvolumen geprägt ist, wird diese Form der Extraktion vornehmlich zur Erstbefüllung eines Data Warehouse verwendet. Für weitere Extraktionsschritte kann das Verfahren der inkrementellen Extraktion verwendet werden, bei der nur noch die Änderungen zwischen dem aktuellen und dem letzten Extraktionsschritt in das Data Warehouse übertragen werden (Beispiel: Delta-Update). Zwar wird auf diese Weise das Datenvolumen vermindert, doch besteht bei dieser Form der Extraktion auch die Gefahr, dass der Verlauf der Änderungen beim Auftreten von Fehlern nicht mehr vollständig zurückverfolgt werden kann. In einem solchen Fall bietet sich die Protokollierung der durchgeführten Änderungen an, wodurch über Log-Dateien jedwedes Ereignis und die damit einhergehenden Änderungen nachvollzogen werden können (vgl. Marx Gómez et al. 2006).

92

Data Warehouse-Architektur

3.1.6.2

Transformationsphase

Sobald die Extraktionsphase abgeschlossen und das Data Warehouse erfolgreich mit den Quellsystemen verbunden ist, müssen die nun im Arbeitsbereich vorliegenden Daten im Zuge der Transformationsphase in einen geeigneten Zustand gebracht werden. Dabei stehen sowohl strukturelle Aspekte (Schemaintegration), als auch inhaltliche Aspekte (Datenintegration und -reinigung) im Vordergrund (vgl. Bauer u. Günzel 2004). Da ein Data Warehouse seine Daten aus mehreren, meist heterogenen Quellen bezieht, bedarf es der Überführung der Daten in ein einheitliches internes Format. Dazu sind folgende Transformationen, die unter dem Begriff der Datenmigration (data migration) zusammengefasst werden können, erforderlich (vgl. Kimball et al. 2008):      

Anpassung von Datentypen Konvertierung von Kodierungen Vereinheitlichung von Zeichenketten Vereinheitlichung von Datumsangaben Umrechnung von Maßeinheiten Kombination bzw. Separierung von Attributwerten

Neben der Datenmigration ermöglicht die Datenbereinigung (engl. data cleaning) innerhalb der Transformationsphase die Korrektur von fehlerhaften, redundanten, veralteten oder fehlenden Werten im Datenbestand. Mit Hilfe von verschiedenen Softwarekomponenten können Unzulänglichkeiten in den Daten erkannt und – soweit möglich – beseitigt werden (vgl. Bauer u. Günzel 2004). Ist die Datenqualität anhand unterschiedlicher Indikatoren (z.B. Anwenderzufriedenheit) analysiert, kann der Datenbestand für die weitere Verarbeitung in Basisdatenbank und Data Warehouse freigegeben werden (vgl. Hinrichs 2002). 3.1.6.3

Ladephase

Sind die Daten in der Extraktionsphase aus den Quellsystemen repliziert und im Zuge der Transformationsphase migriert bzw. bereinigt, können die Daten in der Ladephase des ETL-Prozesses aus dem Arbeitsbereich in die Basisdatenbank geschrieben werden. Während in der Extraktionsphase weitestgehend die Quellsysteme einer Beeinflussung unterliegen, wirkt sich die Ladephase dabei im Wesentlichen auf den Betrieb des Data Warehouse aus: Ähnlich der Sperrung der Quellsysteme beim Extrahieren der Quelldaten, sind auch die betroffenen Tupel beim Laden der Daten in das Data Warehouse gesperrt, so dass während der Ladephase keine Auswertungen oder Analysen auf dem zu verändernden Datenbestand möglich sind. Bei der Aktualisierung bestehender Daten können die alten Werte entweder überschrieben, oder aber als neue Datensätze in die Basisdatenbank eingefügt werden (vgl. Marx Gómez et al. 2006).

SAP BI Data Warehousing

93

Der Ladevorgang wird in der Regel durch die Verwendung von speziellen Werkzeugen, die ein schnelles Laden der Daten ermöglichen, unterstützt. Durch das Sperren gesamter Tabellen ist keine transaktionale Sperrverwaltung notwendig und auch Indizes werden erst nach Abschluss des gesamten Ladevorgangs neu erstellt. Auf diese Weise lässt sich ein signifikanter Leistungsgewinn erzielen. Treten während des Ladeprozesses Komplikationen auf, kann der Vorgang an zuvor gesetzten Prüfpunkten fortgesetzt werden (vgl. Sattler u. Saake 2004).

3.2

SAP BI Data Warehousing

Ein Data Warehouse ist für die Ausführung, Überwachung und Steuerung der Integration, Transformation und Bereitstellung der für das Berichtswesen und analytische Aufgaben relevanten betrieblichen Daten verantwortlich. Neben der objektbasierten Modellierung der Datenstrukturen werden durch das Data Warehousing auch die Verwaltung des ETL-Prozesses sowie die Übergabe der Daten an weitere Systeme übernommen (vgl. SAP 2008c). Die aktuelle Data Warehouse-Lösung der SAP AG wird unter der Bezeichnung SAP BI Data Warehousing oder auch Enterprise Data Warehousing (EDW) geführt und bildet den Nachfolger des SAP Business Information Warehouse (BW) von SAP NetWeaver in der Version 2004/3.5. Nach Vermittlung der Grundlagen der Data Warehouse-Architektur im vorherigen Abschnitt, beginnt dieser Abschnitt mit einer Einführung in das zentrale Werkzeug zur Durchführung aller Aufgaben im Umfeld des SAP BI Data Warehousing, der Data Warehousing Workbench (DWB). Ein besonderer Fokus wird dabei auf den in der DWB enthaltenen Funktionsbereich der Modellierung gelegt. Um danach einen groben Überblick über das Datenflusskonzept des SAP BI Data Warehousing ab NetWeaver 7.0 zu erhalten, wird dieses anhand einer Abbildung zunächst verdeutlicht und die darin enthalten Bereiche kurz einleitend beschrieben. Diese einzelnen Bereiche werden daraufhin in den nachfolgenden Abschnitten detaillierter aufgegriffen. Angefangen bei der Datenmodellierung werden die Datenbereitstellung, die Transformation, die Datenweiterverarbeitung und die Datenverteilung im Rahmen des SAP BI Data Warehousing in eigenen Abschnitten genauer betrachtet. Mit einer Reflexion des Data Warehouse Managements und der Real-Time Data Acquisition findet diese Einführung in das SAP BI Data Warehousing ihren Abschluss.

3.2.1 Data Warehousing Workbench Die DWB stellt im Rahmen der SAP NetWeaver BI das zentrale Werkzeug zur Steuerung, Überwachung und Pflege aller Prozesse aus den Bereichen der Daten-

94

Data Warehouse-Architektur

modellierung, Datenbeschaffung, Datenhaltung und Datenverarbeitung dar. Sie gilt als Nachfolger der Administrator Workbench des SAP Business Information Warehouse und steht für eine grafische Oberfläche, welche dem Entwickler sämtliche zur Abarbeitung der Aufgaben notwendigen Funktionen über Schaltflächen und Kontextmenüs zu Objekten bereitstellt. Durch die Zusammenfassung einzelner Aufgabenschritte in Prozessen wird eine effiziente und schnelle Entwicklungsarbeit unterstützt (vgl. SAP 2008c). Der Aufbau der DWB ist in Abbildung 3.17 skizziert. Aus der Darstellung geht unter anderem hervor, dass sich im linken Bildbereich ein Navigationsfenster befindet, welches dem Entwickler über Drucktasten den Zugang zu den übergeordneten Funktionsbereichen wie Modellierung, Administration, Transportanschluss, Dokumente, Business Content, Übersetzung sowie dem Metadata Repository ermöglicht. Wird ein Funktionsbereich geöffnet, stehen dem Anwender in diesem Fenster zudem die untergeordneten Anwendungen bzw. Objektbäume des ausgewählten Funktionsbereichs zur Verfügung.

Abb. 3.17 Aufbau der Data Warehousing Workbench (vgl. SAP 2008c)

Wird eine Anwendung oder ein Objektbereich eines einzelnen Funktionsbereichs durch einen Einfachklick aufgerufen, so öffnet sich diese bzw. dieser im rechten Bildbereich für Sichten oder Anwendungen einzelner Funktionsbereiche. Dieses, auch als Dynprobereich bezeichnete Fenster, nimmt die größte Fläche der DWB ein und stellt somit die wichtigste Maske zur Interaktion des Benutzers mit dem

SAP BI Data Warehousing

95

System bereit. Desweiteren beinhaltet die Drucktastenleiste oberhalb des Dynprobereichs und des Navigationsfensters Drucktasten zum Ein- und Ausblenden des Navigationsfensters sowie vom Kontext der Anwendung abhängige Drucktasten. Oberhalb der Drucktastenleiste wiederum befindet sich die Menüleiste, welche ebenfalls weitere Funktionen in Abhängigkeit des jeweils aktiven Funktionsbereichs zur Verfügung stellt und zusätzlich den Zugriff auf allgemeine Funktionen gestattet, wie etwa den Aufruf der Hilfe. Am unteren Rand der DWB befindet sich weiterhin eine Statuszeile, in welcher Informationen, Warnungen und Fehlermeldungen als Hinweise für den Benutzer angezeigt werden (vgl. SAP 2008c). Data Warehousing Workbench: Modellierung Da der Funktionsbereich Modellierung ganz besonders im Rahmen der ersten Fallstudie zum SAP BI Data Warehousing (Kapitel 3.4), aber auch bei der Durchführung der zweiten Fallstudie zum Thema SAP BI-Integrierte Planung (Kapitel 4.4) ein zentrale Rolle spielt, wird dieser spezielle Funktionsbereich nachfolgend detaillierter behandelt. Die Einsatzmöglichkeiten des Funktionsbereichs Modellierung der DWB sind äußerst vielfältig. So können mit Hilfe dieses Werkzeugs BI-Objekte strukturiert in Objektbäumen gemäß des zuvor spezifizierten Datenmodells angelegt, angezeigt und geändert werden. Auf diese Weise kann der Datenfluss für die Objekte definiert und Anwendungen und Funktionen zu diesen Objekten aufgerufen werden. In Anlehnung an Abbildung 3.17 stellt Abbildung 3.18 den auf die Modellierung fokussierten Einblick in den Aufbau der DWB dar. Im linken Navigationsfenster der DWB Modellierung befinden sich die unterschiedlichen Objektbäume (InfoProvider, InfoObjects, InfoSources, DataSources, Quellsysteme etc.). Wird einer dieser Objektbäume mit einem einfachen Klick ausgewählt, so öffnet sich seine Baumstruktur im rechten bzw. bei geöffneter Anwendung im mittleren Bildbereich. Der Benutzer erhält auf diese Weise Zugriff auf die einzelnen Objekte des Objektbaums und kann durch Expandieren von Knoten durch diese Objekte navigieren. Mit einem Doppelklick auf ein Objekt öffnet sich die zugehörige Anwendung, wobei es sich in der Regel um die Anzeige der Objektpflege handelt. Diese Anwendung wird im rechten Bildbereich aufgerufen. Innerhalb der Drucktastenleiste stehen dem Benutzer zudem grundlegende Navigationsmöglichkeiten zur Verfügung. Sie umfassen das Springen zwischen geöffneten Anwendungen mittels zweier Navigationspfeile und das Ein- und Ausblenden des Navigationsfensters und der Baumanzeige. Menüleiste und Statuszeile bleiben in ihrer übergeordneten Funktionalität unverändert (vgl. SAP 2008c).

96

Data Warehouse-Architektur

Abb. 3.18 Aufbau der Data Warehousing Workbench: Modellierung (vgl. SAP 2008c)

3.2.2 Datenflusskonzept Bevor der Einblick in die einzelnen Bereiche des SAP BI Data Warehousing erfolgt, ist es zunächst sinnvoll, sich das Konzept des Datenflusses innerhalb des SAP BI-Systems vor Augen zu führen, um ein besseres Verständnis für das Zusammenspiel der einzelnen Objekte zu erhalten. Im Gegensatz zum alten Datenflusskonzept, welches im SAP BW von SAP NetWeaver 2004/3.5 zum Einsatz kommt und auch weiterhin in der Version 7.0 unterstützt wird, sind im neuen Datenflusskonzept einige grundlegende Konzepte und Technologien für bestimmte Elemente verändert worden. Aufgrund der Aktualität und der erweiterten Einsatzmöglichkeiten im Vergleich zum alten Konzept werden in diesem Abschnitt ausschließlich die Charakteristika des neuen Datenflusskonzepts behandelt und vorgestellt. Der Datenfluss im Data Warehouse definiert, über welche Objekte (zur Designzeit) und Prozesse (zur Laufzeit) Daten aus einem Quellsystem in das BISystem übertragen werden. Außerdem beschreibt der Datenfluss, wie diese Quelldaten bereinigt, konsolidiert und integriert werden, um sie später zur Analyse, zum Zwecke des Reporting oder möglicherweise zur Planung einzusetzen. Um dabei ein möglichst breites Spektrum von Anforderungen beliebiger Unternehmenspro-

SAP BI Data Warehousing

97

zesse abdecken zu können, unterstützt das Datenflusskonzept eine Vielzahl von Ausgestaltungsmöglichkeiten (vgl. SAP 2008c). Als Datenquellen können beispielsweise beliebige Typen von Quellsystemen herangezogen werden: Die Palette von Quellsystemgruppen reicht hierbei von flachen Dateien (Flat Files), über Datenbanken und weiteren SAP-Systemen (z.B. SAP R/3 Enterprise) bis hin zu Web Services (vgl. Egger et al. 2006). Das in Abbildung 3.19 dargestellte Datenflusskonzept zeigt den typischen Datenfluss und den Zusammenhang der darin enthaltenen BI-Objekte ab der SAP NetWeaver Version 7.0. Darin wird jedem einzelnen Quellsystem eine DataSource zugeordnet, welche die Metadatenbeschreibung der Quelldaten abbildet. Als eine Menge von Feldern hat die DataSource die Aufgabe, Daten aus einem Quellsystem zu extrahieren und in die Persistent Staging Area (PSA), der Eingangsschicht des BI-Systems, zu übertragen. Auch ein direkter Zugriff auf Quelldaten ist durch die Verwendung von DataSources möglich. Sobald die DataSource aktiviert ist, wird in der PSA zunächst eine Tabelle mit dessen Feldern erzeugt, wodurch die DataSource ein persistentes Objekt innerhalb des Datenflusses wird. SAP NetWeaver BI Datenziel, z.B.InfoCube

Transformation*

DTP

InfoSource* Transformation

PSA DataSource InfoPackage

* optional

Quellsystem

Abb. 3.19 Datenflusskonzept ab SAP NetWeaver 7.0 (vgl. Egger et al. 2006)

Mit Hilfe von InfoPackages werden die Daten daraufhin aus dem Quellsystem in die PSA geladen, bevor sie im BI-System weiterverarbeitet werden können. Die Weiterverarbeitung wird dabei zunächst durch eine Transformation beschrieben, in der Regeln zur Überführung der Daten aus dem Quellformat in das gewünschte Zielformat spezifiziert sind. Genauer betrachtet, umfasst die Transformation die Schritte zur Konsolidierung, Bereinigung und Integration der Daten. Im Vergleich

98

Data Warehouse-Architektur

zum alten Datenflusskonzept des SAP BW ersetzt die Transformation die Übertragungs- und Fortschreibungsregeln, sowie deren Transferstrukturpflege. Durch den Datentransferprozess (DTP) werden die Daten letzten Endes innerhalb des BI-Systems – unter Anwendung der zuvor definierten Transformationen und Filter – von einem persistenten Objekt in ein anderes fortgeschrieben. Als Quelle von Datentransferprozessen fungieren üblicherweise DataSources, aber auch InfoProvider können als Ursprung eines Datentransfers dienen. Mögliche Ziele von Datentransferprozessen wiederum sind typischerweise ebenfalls InfoProvider (z.B. InfoCubes) und Open Hub Destinationen, mittels derer sich die Daten in weitere Systeme verteilen lassen. Die Verwendung von InfoSources gilt im Datenflusskonzept als optional, da sie nur beim Hintereinanderschalten von mehreren Transformationen verwendet werden. Eine InfoSource kommt somit nur bei komplexeren Transformationen (sogenannten Mehrschrittverfahren) zum Einsatz (vgl. SAP 2008c). Der DTP und das InfoPackage sind in ihrer Funktion durchaus vergleichbar, werden aber nach Egger et al. getrennt voneinander betrachtet, „um eine saubere Trennung der einzelnen Ebenen des Staging-Prozesses sowie eine verbesserte Performance beim parallelen Datenladen zu erzielen“ (Egger et al. 2006).

3.2.3 Datenmodellierung Der Aufbau einer kundenindividuellen BI-Lösung beginnt mit der Definition und Umsetzung des Datenmodells. Das Datenmodell bestimmt, welche Daten in den Auswertungen bereitgestellt werden und legt somit die Grundstruktur der BI fest. Im SAP BI Data Warehousing wird dieses Datenmodell je nach Anforderung von Analyse und Reporting im Zuge der Datenmodellierung umgesetzt. Mit Hilfe des Funktionsbereichs Modellierung können dazu im Rahmen der DWB die erforderlichen BI-Objekte angelegt und deren Strukturen gepflegt werden. Im folgenden Abschnitt werden zunächst die zur Strukturierung verwendeten Elemente erklärt, wonach im Anschluss eine nähere Betrachtung der im System erfassten Elemente erfolgt. 3.2.3.1

InfoArea-Hierarchie und InfoObjekt-Kataloge

Um die im Zuge der Datenmodellierung erstellten Objekte strukturiert ablegen zu können, wird eine InfoArea-Hierarchie verwendet. In dieser Hierarchie können beliebig viele InfoAreas (z.B. Finanzbuchhaltung, Human Resources etc.) untereinander verschachtelt werden. Die Unterteilung zwischen einem InfoProvider- und einem InfoObjekt-Baum ist jedoch vom System vorgegeben und wird damit begründet, dass InfoProvider und InfoObjekte innerhalb der InfoArea-Hierarchie unterschiedliche Eigenschaften aufweisen. Diese Unterteilung ist innerhalb der

SAP BI Data Warehousing

99

DWB mittels zweier nachfolgend erläuterten Sichten umgesetzt (vgl. Mehrwald 2007). Die als Datenziele fungierenden Objekte werden in der DWB im InfoProviderBaum gehalten (siehe Abb. 3.20). Sie umfassen komplexe, betriebswirtschaftliche Zusammenhänge zwischen den InfoObjekten und sind durch Analysewerkzeuge auswertbar. Dabei ist jeder InfoProvider aufgrund seiner eindeutigen Dateninhalte genau einer InfoArea zugeordnet und kann weder direkt unter der Wurzel, noch mehrfach in der Hierarchie vorkommen (vgl. Mehrwald 2007).

Abb. 3.20 InfoProvider-Baum

Diese eindeutige Zuordnung eines Datenziels zu genau einem Knoten in der InfoArea-Hierarchie ist im InfoObjekt-Baum nicht möglich. InfoObjekte können im Gegensatz zu Datenzielen mehrfach in der InfoArea-Hierarchie vorkommen, da ein InfoObjekt (z.B. Kundennummer) in mehreren thematisch divergierenden Datenzielen (z.B. Auftragserfassung, Lieferung, Fakturierung etc.) auftreten kann. Um auch die InfoObjekte verwendungsorientiert untereinander strukturieren zu können, werden sie in sogenannten InfoObjekt-Katalogen (InfoObjectCatalogs) organisiert. Beim Anlegen muss dabei festgelegt werden, ob der InfoObjektKatalog entweder Merkmale oder Kennzahlen aufnehmen soll, wodurch sich eine übersichtliche Organisation ergibt (siehe Abb. 3.21). Genauso wie die Datenziele im InfoProvider-Baum, muss ein InfoObjekt-Katalog genau einem Knoten der InfoArea-Hierarchie zugewiesen sein, kann jedoch selbst beliebig viele InfoObjekte beinhalten. Darüber hinaus kann jedes InfoObjekt in beliebig vielen InfoObjektKatalogen enthalten sein, damit den Anforderungen des obig geschilderten Beispiels bezüglich der Verwendung der Kundennummer in verschiedenen Datenzielen gerecht werden kann (vgl. Mehrwald 2007).

100

Data Warehouse-Architektur

Abb. 3.21 InfoObjekt-Baum

3.2.3.2

InfoObjekte

InfoObjekte gelten als Basis für die Definition von Datenzielen. Sie bilden die kleinsten Einheiten im Umfeld der SAP BI und ermöglichen die Abbildung von Informationen in strukturierter Form, die zum Aufbau von InfoProvidern benötigt werden. Besitzt ein InfoObjekt Attribute oder Texte, kann es selbst auch als InfoProvider erfasst werden. InfoObjekte werden darüber hinaus als betriebswirtschaftliche Auswertungsobjekte bezeichnet und untergliedern sich in Merkmale, Zeitmerkmale, technische Merkmale, Kennzahlen und Einheiten (vgl. SAP 2008c). Diese einzelnen Typen von InfoObjekten werden im Folgenden erläutert. Merkmale Merkmale sind Objekte, die einen Geschäftsprozess beschreiben. Im SAP BI Data Warehousing handelt es sich um eine Gruppe von Tabellen, welche über Schlüsselwerte, beschreibende Texte und Eigenschaften des Objekts verfügen. Der Entwickler wird jedoch nicht mit der internen Darstellung konfrontiert, er definiert lediglich in verschiedenen Masken die Eigenschaften des Objekts wie Name, Beschreibung, Länge des Schlüssels, Texte zum Schlüssel und Abhängigkeiten zu anderen Merkmalen. Die Gesamtheit der Eigenschaften bildet letztendlich das Merkmal, welches in der gesamten SAP NetWeaver BI durchgängig gültig ist (vgl. SAP 2008c). In die Kategorie der Merkmale fallen Ordnungsbegriffe, wie beispielsweise Buchungskreis, Produkt, Kunde, Region, Geschäftsjahr oder Periode. Durch ihre

SAP BI Data Warehousing

101

Aufgabe, die erfassten Daten zu klassifizieren, gelten Merkmale als Bezugsobjekte für die Kennzahlen. Deutlich wird dies beim Ablegen von Merkmalen in den Dimensionen eines InfoCube. Hierbei werden die Merkmale über die DimensionsIDs mit den in der Faktentabelle vorliegenden Kennzahlen verknüpft. Über Merkmale kann weiterhin die Granularität (der Feinheitsgrad) der Kennzahlen im InfoCube festgelegt werden, wenn zum Beispiel der Umsatz statt anhand eines Geschäftsjahres, anhand eines einzigen Quartals analysiert werden soll (vgl. SAP 2008c). In der DWB Modellierung werden Merkmale über den in Abbildung 3.22 dargestellten Pflegebildschirm für Merkmale erstellt.

Abb. 3.22 Pflegebildschirm Merkmal

Die wichtigste Eigenschaft eines Merkmals – neben dem technischen Namen und der Beschreibung – ist der Datentyp, welcher über ein Mussfeld verpflichtend beim Anlegen eines jeden Merkmals definiert werden muss. Dabei stehen die in Tabelle 3.4 aufgelisteten Datentypen zur Auswahl. Tabelle 3.4 Datentypen von Merkmalen (vgl. Mehrwald 2007) Datentyp Beschreibung

Zulässige Länge

CHAR

Ziffern und Buchstaben Zeichenlänge 1 - 60

NUMC

nur Ziffern

Zeichenlänge 1 - 60

DATS

Datum

Zeichenlänge 8

TIMS

Zeit

Zeichenlänge 6

102

Data Warehouse-Architektur

Neben dem Datentyp kann beim Anlegen eines Merkmals noch eine Reihe weiterer Einstellungen vorgenommen werden. So besteht über Registerkarten im Pflegebildschirm die Möglichkeit, über die Zulässigkeit von Kleinbuchstaben zu bestimmen oder zwischen verschiedenen Konvertierungsroutinen zur Umrechnung zwischen der internen und externen Darstellung auszuwählen. Die interne Darstellung beschreibt dabei das Format zur Verarbeitung und Speicherung von Daten innerhalb des Systems. So wird beispielsweise ein Datum intern immer im Format JJJJMMTT (JJJJ für das Jahr, MM für den Monat und TT für den Tag) gespeichert oder Kostenstellen mit führenden Nullen gehalten. Die externe Darstellung hingegen legt das Format für Ein- und Ausgaben fest, da dieses zum Zwecke der optimierten Interaktion mit dem Benutzer oftmals abweicht (z.B. TT.MM.JJJJ). Zur Konvertierung zwischen beiden Darstellungsarten werden auf der einen Seite Input-Bausteine zur Umwandlung vom externen in das interne Format und auf der anderen Seite Output-Bausteine zur Konvertierung in entgegengesetzter Richtung bei der Definition von Merkmalen hinterlegt. Werden Konvertierungsroutinen zu einem stammdatentragenden Merkmal nachträglich geändert, muss deren internes Format auf die neue Konvertierungsroutine umgewandelt werden (vgl. Mehrwald 2007). Über weitere Registerkarten innerhalb der Merkmalspflege können darüber hinaus auch Einstellungen bezüglich der Zuweisung von Attributen, Texten und Hierarchien vorgenommen werden. Liegen solche Stammdaten zu einem Merkmal vor, wird dieses Merkmal auch als stammdatentragendes Merkmal bezeichnet. Stammdaten definieren sich in diesem Zusammenhang als Daten, die über einen längeren Zeitraum konstant bleiben und Informationen enthalten, die häufig in gleicher Weise benötigt werden (vgl. SAP 2008c). Referenzierende Merkmale zeichnen sich dadurch aus, dass sie die Attribute, Stammdaten, Texte, Hierarchien, Datentyp, Länge, Klammerungen, Kleinbuchstaben und Konvertierungsroutinen aus dem Referenzmerkmal beziehen (vgl. Mehrwald 2007). Zeitmerkmale In starker Anlehnung an die Aufgaben von Merkmalen existiert mit den Zeitmerkmalen ein weiterer InfoObjekt-Typ im BI-System. Die Zeit ist für betriebswirtschaftliche Ordnungsgrößen von großer Bedeutung. Im Gegensatz zu allen anderen InfoObjekt-Typen hat der Benutzer bei der Verwendung von Zeitmerkmalen nicht die Möglichkeit eigene Objekte zu definieren, sondern muss auf die im BI Content enthaltenen InfoObjekte zurückgreifen. Dies hat den Vorteil, dass weder eine Validierung der Objekte durchgeführt, noch Konvertierungsroutinen zur Zeitdimension erstellt werden müssen. Tabelle 3.5 zeigt die vorhandenen Zeitmerkmale im BI Content (vgl. Mehrwald 2007).

SAP BI Data Warehousing

103

Tabelle 3.5 Zeitmerkmale des BI Content (vgl. Mehrwald 2007) InfoObjekt

Beschreibung

Typ

Länge Format

0CALDAY

Kalendertag

DATS

8

JJJJMMTT

0CALMONTH

Kalenderjahr/Monat

NUMC

6

JJJJMM

0CALMONTH2

Kalendermonat

NUMC

2

MM

0CALQUART1

Quartal

NUMC

1

Q

0CAL_QUARTER Kalenderjahr/Quartal

NUMC

5

JJJJQ

0CALWEEK

Kalenderjahr/Woche

NUMC

6

JJJJWW

0CALYEAR

Kalenderjahr

NUMC

4

JJJJ

0FISCPER

Geschäftsjahr/Geschäftsmonat

NUMC

7

JJJJMMM

0FISCPER3

Geschäftsmonat

NUMC

3

MMM

0FISCVARNT

Geschäftsjahresvariante

CHAR

2

XX

0FISCYEAR

Geschäftsjahr

NUMC

4

JJJJ

0HALFYEAR1

Halbjahr

NUMC

1

H

0WEEKDAY1

Wochentag

NUMC

1

N

Entsprechen die angebotenen Zeitmerkmale nicht den Anforderungen des Benutzers, kann in einem ersten Schritt die Bezeichnung der Zeitmerkmale in der InfoObjekt-Pflege geändert werden. Dies führt weder beim laufenden System, noch bei einem späteren Release-Wechsel zu Problemen. Sollte der Funktionsumfang der im BI Content enthaltenen Zeitmerkmale den Anforderungen nicht gerecht werden, besteht grundsätzlich die Möglichkeit, normale Merkmale als Zeitmerkmale zu verwenden. In einem solchen Fall können jedoch die oben genannten Vorteile bezüglich der Validierung von Zeitmerkmalen und der Typkonvertierung im Staging nicht zur Geltung kommen (vgl. Mehrwald 2007). Technische Merkmale Zur Erfüllung organisatorischer Zwecke kann der Benutzer innerhalb des SAP BI Data Warehousing sogenannte technische Merkmale verwenden. Beispiele für technische Merkmale sind Versionsnummern in InfoCubes zur Nachverfolgung von Änderungen innerhalb einer Planungsumgebung, oder Request-Nummern, anhand derer die Anzahl an Datenladevorgängen dokumentiert und überprüft werden kann (vgl. SAP 2008c). Kennzahlen Ein weiterer InfoObjekt-Typ sind die Kennzahlen, die laut Definition quantifizierbare Größen darstellen, mit denen arithmetische Operationen möglich sind. Kennzahlen ergeben nur in Verbindung mit Merkmalen einen sinnvollen Bezug (vgl. Kapitel 3.1.5.1). Der Pflegebildschirm zum Anlegen und Ändern von Kennzahlen

104

Data Warehouse-Architektur

innerhalb der DWB Modellierung ist in Abbildung 3.23 dargestellt und unterscheidet sich in seinen Einstellungen grundlegend vom Pflegebildschirm der Merkmale.

Abb. 3.23 Pflegebildschirm Kennzahl

Ebenso wie für Merkmale stehen auch für Kennzahlen bestimmte Datentypen zur Verfügung, die in Tabelle 3.6 aufgelistet sind. Daraus geht hervor, dass im Gegensatz zu InfoObjekten vom Typ Merkmal, den Kennzahlen im SAP BI Data Warehousing Einheiten zugewiesen werden können. Kennzahlen vom Typ Zahl, Integer, Datum oder Zeit (nicht zu verwechseln mit Zeitmerkmalen) verfügen dabei über keine Einheit, während den Kennzahlen vom Typ Betrag (Währungseinheit) oder Menge (Mengeneinheit) stets eine feste oder variable Einheit zugeordnet werden muss. Diese Einheiten sind besonders in den Bereichen Extraktion, Staging und für die Datenanalyse von Bedeutung, da Kennzahlen in diesen Bereichen in Bezug zu ihrer Einheit gesetzt oder – sofern es sich um eine Kennzahl vom Typ Betrag handelt – in andere Einheiten umgerechnet werden (Währungsumrechnung).

SAP BI Data Warehousing

105

Tabelle 3.6 Datentypen von Kennzahlen (vgl. Mehrwald 2007) Typ

Datentyp mit Einheit Beschreibung

Betrag CURR

ja

Währungsfeld abgelegt als DEC

ja

Gleitpunktzahl mit 8 Byte Genauigkeit

ja

Mengenfeld, zeigt auf Einheiten mit Format UNIT

FLTP

ja

Gleitpunktzahl mit 8 Byte Genauigkeit

DEC

nein

Rechen- und Betragsfeld mit Komma und Vorzeichen

FLTP

nein

Gleitpunktzahl mit 8 Byte Genauigkeit

Integer INT4

nein

4-Byte-Integer, ganze Zahl mit Vorzeichen

Datum DEC

nein

Rechen- und Betragsfeld mit Komma und Vorzeichen

DATS

nein

Datumsfeld (JJJJMMTT), abgelegt als CHAR (8)

DEC

nein

Rechen- und Betragsfeld mit Komma und Vorzeichen

TIMS

nein

Zeitfeld (hhmmss), abgelegt als CHAR (6)

FLTP Menge QUAN Zahl

Zeit

Entscheidet sich der Benutzer für die Vergabe einer festen Währung bzw. Mengeneinheit zu einer Kennzahl, so wird dies über den Pflegebildschirm in der Definition der Kennzahl gespeichert. Dadurch ergibt sich der Vorteil, dass die Einheit nicht mehr explizit im Datenmodell gespeichert werden muss, da sie bereits in der Definition der Kennzahl enthalten ist. Der Nachteil allerdings liegt darin, dass beim Speichern der Daten gegebenenfalls eine Umrechnung erfolgen muss, sofern die gelieferten Daten nicht der zuvor definierten festen Einheit entsprechen. Bei einer variablen Einheit muss der Benutzer über den Pflegebildschirm ein zusätzliches Einheiten-InfoObjekt zur Kennzahl definieren, welches dann überall dort, wo die Kennzahl verwendet wird, zusätzlich abgelegt wird. Ein Beispiel für ein Einheiten-InfoObjekt aus dem BI Content ist der Währungsschlüssel 0CURRENCY (vgl. Mehrwald 2007). Kennzahlen können analog zu Merkmalen ebenfalls als referenzierende Kennzahlen definiert werden. Dabei wird die referenzierende Kennzahl mit dem Ausgangswert der referenzierten Kennzahl belegt. Weitere Berechnungen können danach unabhängig von der Referenzkennzahl erfolgen (vgl. SAP 2008c). Aggregationsverhalten von Kennzahlen Das Aggregationsverhalten von Kennzahlen bestimmt, ob und auf welche Weise Kennzahlenwerte auf ihrem Weg vom Quellsystem bis zur Datenanalyse über die verschiedenen Merkmale bzw. deren Merkmalswerte zusammengefasst (aggregiert) werden. Das System sieht dazu zwei mögliche Arten von Aggregationsverhalten vor (vgl. SAP 2008d, Mehrwald 2007):  Bei einer Standardaggregation werden Kennzahlen über alle Merkmale, die keine Zeitmerkmale sind, verdichtet. Dabei werden Kennzahlenwerte entweder aufsummiert oder deren MIN-/MAX-Werte ermittelt. Diese Art der Aggrega-

106

Data Warehouse-Architektur

tion kann aus Gründen der Performanz und Einfachheit bereits auf Datenbankebene durchgeführt werden.  Komplexe Aggregationsverfahren behandeln die Verdichtung von Kennzahlen über alle Merkmale. Sie stehen in einem Bezug zu anderen InfoObjekten (Ausnahmeaggregation), da ihre Operationen nur mit einer Bezugsgröße einen Sinn ergeben. Handelt es sich bei der Bezugsgröße um normale InfoObjekte, wird von einer sachlichen Aggregation gesprochen, werden hingegen Zeitmerkmale verwendet, liegt eine zeitliche Aggregation vor. Als Beispiele können in der Ausnahmeaggregation der Durchschnitt eines Lagerbestands pro Monat oder die Anzahl an Aufträgen pro Kunde berechnet werden. Einheiten InfoObjekte vom Typ Einheit werden immer als Zusatzinformation für einen Betrag oder eine Menge verwendet, da dies die einzigen Datentypen von Kennzahlen sind, die eine Einheit besitzen. Wird ein Einheiten-InfoObjekt angelegt, kann nur definiert werden, welche Bezeichnung es trägt und ob es sich um eine Mengenoder Währungseinheit handelt. Technisch gesehen basieren alle InfoObjekte vom Typ Einheit auf den im BI Content enthaltenen InfoObjekten 0UNIT und 0CURRENCY (vgl. Mehrwald 2007). Stammdaten - Texte, Attribute und Hierarchien Im SAP BI Data Warehousing dienen Stammdaten dem Zweck, Merkmale über ergänzende Eigenschaften aktuell oder stichtagsbezogen anhand von Gültigkeitszeiträumen näher zu beschreiben. Als das Antonym der Bewegungsdaten, die sich im Laufe eines Geschäftsprozesses häufig ändern und eine gewisse Dynamik aufweisen (z.B. Aufträge, Bestellungen etc.), erfahren Stammdaten nur selten Änderungen und werden meist langfristig gehalten (z.B. Produkt- und Kundendaten, Stücklisten etc.). Bei Stammdaten wird zwischen Texten, Attributen und Hierarchien unterschieden, deren Inhalte entweder aus Quellsystemen importiert, oder über die Stammdatenpflege direkt im System administriert werden (vgl. Marx Gómez et al. 2006). Texte Texte gelten als Beschreibungen zu den Ausprägungen von Merkmalen. Ist zum Beispiel die Produktbezeichnung AN03 für den Betrachter einer Umsatzanalyse zunächst nicht hinreichend aussagekräftig, kann die Verwendung des Produkttextes Flachbildschirm Plasma 32'' zum besseren Verständnis hinzugezogen werden. Wird in der InfoObjekt-Pflege eines Merkmals definiert, dass zu diesem Merkmal Texte vorhanden sind, muss ferner genauer spezifiziert werden, über welche ma-

SAP BI Data Warehousing

107

ximale Länge diese Texte verfügen (siehe Tab. 3.7). Um unterschiedlichen Anforderungen an das Erscheinungsbild von Auswertungen gerecht zu werden, ist die Verwendung unterschiedlicher Textlängen durchaus sinnvoll. Tabelle 3.7 Textarten (vgl. SAP 2008c) Textart

maximale Textlänge

Kurztext

20 Zeichen

Mittellanger Text 40 Zeichen Langtext

60 Zeichen

Neben der Auswahl einer Textart kann außerdem bestimmt werden, ob Texte über Abhängigkeiten verfügen (siehe Abb. 3.24). Sind Texte sprachabhängig, so erhält die Texttabelle eine zusätzliche Spalte für den Sprachschlüssel, wodurch das System je nach eingestellter Sprache auf den korrespondierenden Texteintrag in der Tabelle zurückgreift. Bei der Verwendung der Sprachabhängigkeit ist sicherzustellen, dass die verschiedenen Sprachen im Quellsystem zur Verfügung stehen und die Texte mit einem Sprachkennzeichen zur Identifikation versehen sind. Sind Texte zeitabhängig, wird die Texttabelle um eine zusätzliche Spalte für ein Datenfeld angereichert, dessen Eintrag einen Zeitraum beschreibt, für den der entsprechende Texteintrag gültig ist. Auf diese Weise lassen sich beim Reporting die für einen Analysezeitpunkt geltenden Einträge beziehen. Aus Gründen der Performanz wird empfohlen, beide Abhängigkeiten nur dann zu verwenden, wenn ihre Verwendung als besonders nützlich bewertet werden kann (vgl. Mehrwald 2007).

Abb. 3.24 Pflegebildschirm Texte

108

Data Warehouse-Architektur

Attribute Ebenso wie Texte liefern Attribute beschreibende Informationen zu Merkmalsausprägungen. Da es sich bei ihnen jedoch um bereits im System angelegte InfoObjekte handelt, können sie darüber hinaus zur Selektion und Navigation im Rahmen der Datenanalyse eingesetzt werden. Sie werden über die gleichnamige Registerkarte in der InfoObjekt-Pflege zu einem Merkmal gepflegt (siehe Abb. 3.25). Jedes InfoObjekt, welches über Stammdaten verfügt, kann beliebig viele weitere InfoObjekte aufnehmen. Dabei wird zwischen geklammerten, zeitkonstanten, zeitabhängigen Attributen sowie Navigationsattributen unterschieden (vgl. Mehrwald 2007).

Abb. 3.25 Pflegebildschirm Attribute

Über die Funktion der Klammerung, deren Modellierung über eine separate Registerkarte erfolgt, wird in allen relevanten Stammdatentabellen eines InfoObjekts das in der Klammerung enthaltene InfoObjekt als zusätzliches Feld in den Primärschlüssel aufgenommen. Die Verwendung einer Klammerung ist insbesondere dann hilfreich, wenn einige InfoObjekte für sich allein nicht eindeutig bestimmbar sind. Ist zum Beispiel das Lager A zu Werk B ungleich dem Lager A zu Werk C, kann das Merkmal Lager nur dann eindeutig bestimmt werden, wenn es über die Definition einer Merkmalsklammerung mit dem Merkmal Werk verknüpft wird. Analog zu den Texten muss auch bei der Verwendung von geklammerten InfoObjekten bedacht werden, dass sich die Funktion insbesondere bei sehr vielen InfoObjekten in einer Klammerung und bei extensivem Gebrauch negativ auf die Performanz auswirken kann (vgl. SAP 2008c, Marx Gómez et al. 2006). Grundsätzlich gelten Attribute als zeitkonstant, da sie jeweils in der aktuellen Form zu einem InfoObjekt vorliegen und keiner Zeitachse zugewiesen sind. Ähnlich der Speicherung von Texten können Attribute aber auch stichtagsbezogen in Form von Gültigkeitszeiträumen, also zeitabhängig abgelegt werden. Über diese Eigenschaft können die Attributwerte eines jeden Attributs individuell zugeschal-

SAP BI Data Warehousing

109

tet werden. Sie werden nicht global für sämtliche Attribute verwaltet, wie es bei der Zeitabhängigkeit von Texten der Fall ist (vgl. Mehrwald 2007). Ein Beispiel für zeitkonstante und zeitabhängige Attribute ist in Tabelle 3.8 bzw. 3.9 veranschaulicht. Tabelle 3.8 Zeitkonstante Attribute Merkmal: Produkt

Attribut: Währung

Merkmalswert: AN01 Attributwert: Euro Tabelle 3.9 Zeitabhängige Attribute Merkmal: Produkt

gültig von

gültig bis

Attribut: Preis

Merkmalswert: AN01 01.01.2008 30.06.2008 Attributwert: 789,50 01.07.2008 31.12.2008 Attributwert: 699,50

Beide Tabellen werden vom BI-System über einen View gelesen. Aus dem Grund des programmtechnisch einfacheren Lesezugriffs, ist die vom System automatisch angelegte, virtuelle Tabelle in an Anlehnung an das obige Beispiel in Tabelle 3.10 dargestellt. Tabelle 3.10 View der Verbindung beider Tabellen Produkt gültig von AN01

gültig bis

Preis

Währung

01.01.2008 30.06.2008 789,50 Euro 01.07.2008 31.12.2008 699,50 Euro

Alle bisher genannten Attributarten dienen ausschließlich der Anzeige ergänzender Eigenschaften von InfoObjekten und können weder als Filter, noch für DrillDown Operationen genutzt werden. Diese auch als Anzeigeattribute bezeichneten Elemente können nicht in Dimensionstabellen aufgenommen werden und selbst keine Attribute tragen. Zu diesem Zweck besteht die Möglichkeit Attribute als Navigationsattribut zu definieren, die demzufolge zur Definition der Sicht auf den Datenbestand und als Filter in Anfragen geeignet sind. Die zu einem Navigationsattribut zugeordneten Attribute stehen dabei auch dem übergeordneten, stammdatentragenden InfoObjekt zur Verfügung. Sowohl zeitkonstante als auch zeitunabhängige Attribute können als Navigationsattribut definiert werden (vgl. Mehrwald 2007). Hierarchien Um Merkmalsausprägungen nach bestimmten Kriterien zusammenzufassen und zu gliedern, werden Hierarchien verwendet. Die Definition einer Hierarchie erfolgt immer zu genau einem InfoObjekt. Dabei verfügt jede Hierarchie über genau einen obersten Hierarchieknoten (der Hierarchiewurzel) sowie über weitere, da-

110

Data Warehouse-Architektur

runterliegende Hierarchieknoten, die jeweils genau einen Vaterknoten besitzen. Je nach Entfernung der Hierarchieknoten zur Hierarchiewurzel wird von verschiedenen Hierarchieleveln oder auch Hierarchieebenen gesprochen. Während einer Datenanalyse können die Kennzahlenwerte aller Merkmale, die einem Hierarchieknoten zugeordnet sind, auf den darüber liegenden Hierarchieknoten aggregiert werden (vgl. Mehrwald 2007). 3.2.3.3

InfoProvider

InfoProvider werden aus InfoObjekten zusammengesetzt und sind datentragende Objekte. Der Aufbau eines InfoProvider wird definiert, indem seine Datenelemente vom Entwickler über die bereits angelegten InfoObjekte zusammengestellt werden. Ist die Struktur aktiviert worden, so lassen sich Stamm- und Bewegungsdaten in die InfoProvider laden. Es wird zwischen physisch datentragenden und virtuellen InfoProvidern unterschieden. Virtuelle InfoProvider enthalten keine Daten, sie stellen allein Sichten auf datentragende InfoProvider bereit, die sich im SAP BI Data Warehousing oder in anderen, an das SAP BI Data Warehousing angebundenen Systemen befinden (vgl. SAP 2008c). Neben den bereits bekannten Merkmalen mit Attributen gelten weiterhin InfoCubes und DataStore-Objekte zu den physisch datentragenden InfoProvidern. MultiProvider, VirtualProvider, InfoSets und Aggregationsebenen gehören hingegen zu der Kategorie der virtuellen InfoProvider. Aggregationsebenen werden ausschließlich im Umfeld von Planungsapplikationen eingesetzt und werden daher in Kapitel 4.3 tiefergehend behandelt. InfoCubes Über einen InfoCube wird eine Menge von relationalen Datenbanktabellen nach dem Starschema zusammengestellt. Im Zentrum befindet sich eine große Faktentabelle, die von mehreren Dimensionstabellen umgeben ist. In der Faktentabelle des InfoCube sind ausschließlich Kennzahlen enthalten. In den Dimensionen sind die Merkmale des InfoCube enthalten. Durch den InfoCube wird eine Sicht auf einen geschlossenen Datenbestand geboten. Erst durch die Zusammenstellung in einem InfoCube können die Daten im Rahmen einer Datenanalyse über den Business Explorer ausgewertet werden (vgl. SAP 2008c). Die Daten des InfoCube stammen aus InfoSources oder werden aus anderen InfoProvidern bezogen. In der Staging-Phase wird eine InfoObjekt-Menge mit Daten gefüllt. Neben dem Standard-InfoCube ist es auch möglich, einem InfoCube die Eigenschaft Realtime-fähig zu geben. Ein Standard-InfoCube ist auf Lesezugriffe optimiert, während ein Realtime-fähiger InfoCube parallele Schreibzugriffe unterstützt. So kann mit Hilfe von solchen InfoCubes die Erfassung von Plandaten durchgeführt werden. In einen Realtime-fähigen InfoCube werden die Daten auch

SAP BI Data Warehousing

111

von mehreren Nutzern gleichzeitig geschrieben, dabei gibt es zwei verschiedene Methoden Daten in den InfoCube zu führen. Zum einen über die Transaktion zur Erfassung von Plandaten, zum anderen über das Staging der SAP Business Intelligence. Es ist möglich einen normalen InfoCube in einen Realtime-fähigen InfoCube umzuwandeln, dabei müssen allerdings die Bewegungsdaten entfernt werden.

Abb. 3.26 Pflegebildschirm InfoCube

DataStore-Objekte Für die Aufnahme von bereinigten und konsolidierten Bewegungsdaten und zur Ablage von Stammdaten auf Belegebene werden DataStore-Objekte verwendet. Im Unterschied zur Speicherung der Daten im Starschema werden die Daten in DataStore-Objekten in flachen Datenbanktabellen abgelegt. Der Aufbau dieser Objekte enthält Schlüsselfelder und Datenfelder. DataStore-Objekte ermöglichen es nicht nur Kennzahlen zu aktualisieren, sondern auch die gesamten Datenfelder zu überschreiben. So können beispielsweise Rechnungen aktualisiert werden, bei denen neben den numerischen Werten, wie Endsumme, Materialmengen oder Stundensätze, auch nichtnumerische Werte, wie Adresse, Lieferstatus oder Lieferdatum aktualisiert werden müssen. Um eine solche Aktualisierung durchführen zu können, muss eine Aktualisierung und Überschreibung der Felder im DataStoreObjekt und des Change Log vorgenommen werden. Neben dem normalen DataStore-Objekt gibt es eine Variante für direktes Schreiben und eine schreiboptimierte Variante. Diese Varianten unterscheiden sich in der Art in der die Daten aufbereitet werden. Bei dem DataStore-Objekt für direktes Schreiben werden die Daten nicht versioniert, sondern werden unmittelbar ohne Verzögerung geschrieben. Die Daten eines solchen Objekts werden über eine API geschrieben oder gelöscht. Schreiboptimierte DataStore-Objekte bestehen nur aus der Tabelle der aktiven Daten. So entfällt die sonst benötigte Aktivie-

112

Data Warehouse-Architektur

rung und die Daten können schneller genutzt und weiterverarbeitet werden. Die Speicherung der Daten erfolgt ohne Aggregation, durch die Umwandlung in ein normales DataStore-Objekt kann diese allerdings nachgeholt werden. Schreiboptimierte DataStore-Objekte werden nicht über den Datentransferprozess mit Daten befüllt. Alle DataStore-Objekte lassen sich mit dem Business Explorer abfragen, allerdings erhalten nur normale DataStore-Objekte eine eindeutige Schlüssel ID. MultiProvider Ein MultiProvider ist ein aus mehreren InfoProvidern zusammengeführtes Objekt. Innerhalb des MultiProvider sind keine Daten enthalten, diese Daten liegen alleine in den jeweiligen InfoProvidern bzw. Datenquellen. Aus Sicht einer Datenbanklogik ist ein MultiProvider eine Union-Operation über die enthaltenen InfoProvider. Neben InfoObjekten, DataStore-Objekten und InfoCubes, welche alle Daten enthalten, können auch physisch datenlose InfoProvider wie VirtualProvider und InfoSets zu einem MultiProvider zusammengefasst werden. Über den Pflegebildschirm der DWB werden alle Einstellungen modelliert (siehe Abb. 3.27).

Abb. 3.27 Pflegebildschirm MultiProvider

Durch die Union-Operation werden die Daten aller im MultiProvider enthaltenen InfoProvider zusammengefasst, wodurch das entstehende Objekt die Vereinigungsmenge über den gewünschten Daten bildet. Da alle Werte zusammengeführt werden, muss jedes Merkmal des MultiProvider genau einem Merkmal in jedem

SAP BI Data Warehousing

113

enthaltenen InfoProvider entsprechen. Diese Zuordnung kann in der Definition des MultiProvider enthalten sein, um Mehrdeutigkeiten zu verhindern. Ebenso muss für die enthaltenen Kennzahlen des MultiProvider ein entsprechender InfoProvider gewählt werden. So können redundante Daten einzeln abgerufen und Fehlberechnungen vermieden werden. Da ein MultiProvider die Daten nicht physisch abspeichert und nur auf die jeweiligen InfoProvider verweist, werden die Anfragen an einen MultiProvider intern auf die jeweiligen Objekte aufgeteilt. Diese aufgeteilten Anfragen können dann parallel abgearbeitet werden. Zur Wahrung der Übersicht und um die erwähnte Zerlegung der Anfragen in einem produktiven Rahmen zu halten, sollten nicht mehr als zehn InfoProvider zu einem MultiProvider zusammengefasst werden. VirtualProvider In einem VirtualProvider werden die Daten nicht im Objekt selbst abgespeichert, sondern bei der Analyse oder Berichtserstellung direkt aus dem datentragenden System ausgelesen. Für einen solchen Prozess ist es irrelevant, ob die Daten dabei aus weiteren SAP-Systemen oder aus Fremdsystemen stammen. Da die Daten nur ausgelesen und dargestellt werden, ist ein Schreibzugriff auf diese Daten in einem VirtualProvider nicht möglich. Ein VirtualProvider, dessen Daten über einen InfoProvider oder ein DataStore-Objekt direkt aus einem angeschlossenen SAPSystem stammen, übernimmt Merkmale und Kennzahlen. Ein solcher auf dem Datentransferprozess basierender VirtualProvider sollte nicht verwendet werden, wenn die gesuchten Daten von vielen Nutzern gleichzeitig oder sehr oft angefragt werden und eignet sich ebenso wenig für große Datenmengen. Für das zeitnahe Auslesen einzelner Daten, die nur von wenigen Nutzern benötigt und nicht regelmäßig aufgerufen werden, kann ein solcher VirtualProvider genutzt werden. Eine weitere Variante eines VirtualProvider stellen InfoObjekte vom Typ Merkmal dar. Wenn ein InfoObjekt als InfoProvider gekennzeichnet wird, kann ein direkter Zugriff auf das Quellsystem ermöglicht werden. Wenn ein Merkmal für den direkten Zugriff auf die Stammdaten genutzt wird, entfällt das Laden dieser Daten. Ebenso wie bei den auf Datentransferprozessen basierenden VirtualProvidern ist ein solches Objekt nicht für stark genutzte und häufig angefragte Daten sinnvoll. Eine weitere Möglichkeit, VirtualProvider mit Daten zu verbinden, ist die Nutzung einer durch den Benutzer definierten Schnittstelle. Mit einem solchen Funktionsbaustein können Daten aus Fremdsystemen angezeigt werden. Die Gestaltung der Schnittstelle ist vom Nutzer zu implementieren, was sowohl mehr Möglichkeiten, als auch einen höheren Aufwand bedingt.

114

Data Warehouse-Architektur

InfoSets InfoSets sind Metadaten-Objekte ohne eine physische Datenbasis. In InfoSets sind Datenquellen beschrieben, die durch einen Join J von InfoCubes, InfoObjekten oder DataStore-Objekten Objekten definiert werden. So können Daten über mehrere Inf InfoProvider analysiert werden. Eine Verknüpfung durch eine Join-Operation mit zeitabhängigen Merkmalen wird als temporaler JJoin bezeichnet. InfoSets stellen eine semantische Schicht über Datenquellen dar. Durch die Join-Operation werden nur die Daten zusammengeführt, die in beiden Objekten vorhanden sind. InfoSets bilden somit, im Gegensatz zu MultiProvidern, eine Schnittmenge der zusammengefassten Objekte.

3.2.4 Datenbereitstellung Sind alle notwendigen Objekte im Zuge der Datenmodellierung angelegt, bedarf es der Datenbereitstellung der Stamm-, Bewegungs- und Metadaten aus verschiedenen Quellen. Innerhalb des SAP BI Data Warehousing existieren verschiedene Schichten zur Haltung von Daten, welche Teil eines polymeren Datenflusses sind. Jede der Datenschichten erfüllt dabei einen bestimmten Zweck und ist durch einzelne Glieder des Datenflusses mit einer anderen Schicht verbunden (vgl. SAP 2008c). Abbildung 3.28 zeigt die verschiedenen Schichten und ordnet sie den drei Phasen zu.

Abb. 3.28 Datenschichten im SAP BI Data Warehousing

SAP BI Data Warehousing

115

Das Quellsystem tritt nicht als Schicht innerhalb des SAP BI Data Warehousing auf, ist aber trotzdem in seiner Funktion als Datenquelle Teil der Datenbereitstellung. Als Quelle können verschiedene Systeme auftreten. Ihnen ist gemein, dass sie eine Schnittstelle zum SAP BI Data Warehousing bilden. Diese Schnittstelle wird als DataSource bezeichnet. In ihr sind alle Datenfelder definiert, die vom Quellsystem aus bedient und in das SAP BI Data Warehousing übertragen werden (vgl. SAP 2008c). Alle Systeme, aus denen Daten für das BI bereitgestellt werden, werden als Quellsysteme bezeichnet. Dies können sein (vgl. Egger et al. 2006, SAP 2008c): x x x x x x x

SAP Systeme (z.B. SAP R/3 Enterprise) BI-Systeme Systeme (z.B. das Myself Myself-System) fflache Dateien Datenbankmanagementsysteme relationale oder multidimensionale Quellen Fremdsysteme (z.B. Ascential Datastage) Web Services

Je nach verwendetem Quellsystem stehen im SAP BI Data Warehousing dazu unterschiedliche Mechanismen zur Verfügung, die in Abbildung 3.29 dargestellt sind. Die Übertragung der Daten erfolgt dabei zunächst in die Persistent Staging Area (PSA), in welche die Daten unverändert aus dem Quellsystem übernommen und für einen mittelfristigen Zeitraum gesichert werden. Sie sind nicht für Berichtszwecke gedacht, sondern fungieren als Pufferspeicher und werden im Fehlerfall analysiert (vgl. SAP 2008c).

Abb. 3.29 Datenbereitstellung im SAP BI Data Warehousing

116

Data Warehouse-Architektur

3.2.5 Transformation Gemäß dem in Abschnitt 3.2.2 beschriebenen Datenflusskonzept des SAP BI Data Warehousing dienen Transformationen der Konsolidierung, Bereinigung und Integration von Daten. Die Aufgabe einer Transformation kann ferner als Synchronisation von Daten aus heterogenen Quellen beschrieben werden. Damit die Konvertierung von Feldern einer Quelle in das Format eines Ziels realisiert werden kann, wird eine Transformation immer zwischen einer Quelle und einem Ziel angelegt. Mögliche Quellen sind die BI-Objekte DataSource, InfoSource, DataStoreObjekt, InfoCube, InfoObjekt und InfoSet, während als Ziele die BI-Objekte InfoSource, InfoObjekt, DataStore-Objekt und InfoCube in Frage kommen (vgl. SAP 2008c). Über den Pflegebildschirm zur Transformation, wie er beispielhaft in Abbildung 3.30 dargestellt ist, lassen sich verschiedene Regeln definieren. Jede Transformation besteht dabei aus mindestens einer Transformationsregel, die wiederum unterschiedliche Regeltypen, Transformationsarten und Routinen enthalten kann. Eine Transformationsregel bildet beliebig viele Felder der Quelle auf mindestens einem Feld des Ziels ab (vgl. SAP 2008c).  Regeltyp: Einer Transformationsregel kann ein Regeltyp zugeordnet werden. Dabei handelt es sich um eine Operation, die beim Anwenden der Transformationsregel auf die beteiligten Felder angewandt wird. Mögliche Typen sind die direkte Zuweisung, Konstante, Stammdaten nachlesen, Routine, Zeitfortschreibung, Initial, keine Transformation und Mengeneinheiten- bzw. Währungsumrechnungen.  Transformationsart: Zur Festlegung, wie die Felder der Quelle in die Felder des Ziels geschrieben werden, stehen mehrere Aggregationsarten zur Verfügung. Je nach Ausprägung des Ziel-InfoProvider kann zwischen den Optionen Überschreiben, Summation, Maximum und Minimum gewählt werden.  Regelgruppe: Um Transformationsregeln zu gruppieren, werden Regelgruppen verwendet. Dadurch ergibt sich die Möglichkeit, für ein Merkmal verschiedene Regeln für verschiedene Kennzahlen anzulegen und anzuwenden.  Routine: Zur Formulierung sehr komplexer Transformationen wird auf Routinen zurückgegriffen. Über InfoSources können mehrere Transformationen hintereinander ausgeführt werden, sofern das Datenmodell dies vorschreibt. Dies kann aus semantischen oder Komplexitätsgründen der Fall sein, sofern sehr viele, aufeinander aufbauende Regeln umgesetzt werden sollen oder eine gewisse Strukturierung der Transformationsregeln angestrebt wird. Auf diese Weise wird zudem vermieden, dass die Daten zwischendurch zusätzlich abgelegt werden müssen (vgl. SAP 2008c).

SAP BI Data Warehousing

117

Abb. 3.30 Pflegebildschirm Transformation

3.2.6 Datenweiterverarbeitung Die in den InfoProvider geladenen Daten können zur Weiterverarbeitung verwendet werden. Dabei ist zu unterscheiden, ob die Datenweiterverarbeitung in einem DataStore-Objekt oder in einem InfoCube erfolgt. 3.2.6.1

Datenweiterverarbeitung im DataStore-Objekt

Sind die weiterzuverarbeitenden Daten in ein DataStore-Objekt geladen, können sie als Quelle für weitere InfoProvider genutzt werden. Dazu müssen die Objekte der zu verwendenden Daten jedoch aktiviert sein. Die Integration eines DataStoreObjekts in eine Prozesskette ermöglicht ein problemloses Laden und Weiterverarbeiten der Daten (vgl. SAP 2008c). Die Vorbedingungen für eine solche Verwendung der Prozessketten umfasst die Existenz eines Datentransferprozesses zum Laden der Daten in das DataStore-Objekt und zum Fortschreiben in den InfoProvider. Ebenfalls muss ein InfoPackage existieren, aus dem die Daten der DataSource in das DataStore-Objekt geladen werden (vgl. SAP 2008c). Die Fortschreibung von Daten aus dem DataStore-Objekt erfolgt in zwei Schritten. Zuerst müssen die Daten des DataStore-Objekts aktiviert werden. Durch die Aktivierung der Daten werden diese aus der Aktivierungs-Queue in die Tabelle der aktiven Daten geschrieben und stehen zum Zwecke des Reporting zur Verfügung (vgl. SAP 2008c). Die Reihenfolge, in der die Daten in die Tabelle der aktiven Daten verbucht werden, wird durch die ID des jeweiligen Objekts und den zugehörigen Request bestimmt, um die Aktivierung in der korrekten Abfolge sicherzustellen. Bei Abhängigkeiten in der Reihenfolge wird diese mehrfach durchlaufen. Liegen die Daten in der Tabelle der aktiven Daten vor, kann die Fortschreibung der Daten in die angeschlossenen InfoProvider vorgenommen werden. In diesem

118

Data Warehouse-Architektur

Prozess werden die bereits bereinigten und konsolidierten Daten mit Hilfe der Transformationsregeln in die weiteren InfoProvider fortgeschrieben (vgl. SAP 2008c). Um fehlerhafte Datensätze innerhalb des DataStore-Objekts zu korrigieren, können einzelne Requests gelöscht werden. Neben dem Löschen einzelner Daten können zusätzlich alle Daten oder das gesamte DataStore-Objekt entfernt werden, falls dazu die Notwendigkeit besteht. Wird ein bereits aktivierter Request aus dem DataStore-Objekt entfernt, so wird ein Rollback durchgeführt. Dieser Rollback stellt den Status wieder her, der vor dem Buchen des gelöschten Request gültig war. Dies bedeutet, dass alle Requests, die nach dem gelöschten Request aktiv waren, ebenfalls entfernt werden müssen (vgl. SAP 2008c). Datenweiterverarbeitung im InfoCube Neben dem DataStore-Objekt können Daten auch aus einem InfoCube geladen und für verschiedene Folgefunktionen genutzt werden. So können die Inhalte eines InfoCube oder der gesamte InfoCube gelöscht werden. Das Löschen der Inhalte eines InfoCube kann auf die Daten der Faktentabelle beschränkt werden oder weiterhin das Löschen der Daten der Dimensionstabelle umfassen. So werden alle im InfoCube enthaltenen Daten gelöscht. Das Löschen des gesamten InfoCube entfernt nicht nur die Daten und die Struktur dieses InfoCube, es ermöglicht optional auch das Entfernen aller von diesem Objekt abhängigen Objekte wie Queries oder Transformationsregeln (vgl. SAP 2008c). Neben dem Entfernen können die Daten in einem InfoCube auch über Prozessketten zur Weiterverarbeitung genutzt werden. Dazu muss neben einem InfoPackage zum Laden der Daten aus der DataSource auch ein Datentransferprozess angelegt werden, der die Daten in den InfoCube lädt.

3.2.7 Datenverteilung Die DataStore-Objekte mit ihren konsolidierten Daten dienen als Quelle für eine Verteilung der Daten im SAP BI Data Warehousing und an andere Analysesysteme. Als Prozessdefinition steht wiederum ein Datentransferprozess bereit, der jedoch ohne eine DataSource auskommt. Die Daten lassen sich in die InfoCubes der Schicht Architected Data Marts übertragen oder über eine Open Hub Destination für nachgelagerte Systeme bereitstellen.

SAP BI Data Warehousing

3.2.7.1

119

Datentransferprozess

Über den Datentransferprozess (DTP) wird der Prozess definiert, der die Daten innerhalb des SAP BI überträgt. Diese Übertragung zwischen zwei persistenten Objekten erfolgt dabei unter Anwendung verschiedener Transformations- und Filteroperationen (vgl. SAP 2008c). Der DTP überträgt dabei die Daten aus der PSA und den DataSources in die verschiedenen InfoProvider, ermöglicht aber auch eine Übertragung der Daten in einen weiteren InfoProvider und das Data Mart Interface oder über die Open Hub Destination in nachgelagerte Systeme. In Abbildung 3.19 ist die Integration des Datentransferprozesses in den Datenfluss der SAP BI dargestellt. Die Datenverteilung innerhalb der SAP BI wird durch den DTP übernommen, nur die Übertragung in die DataSource wird vom InfoPackage gesteuert. Die verschiedenen Datentransferprozesse können parallel verarbeitet und die Deltaverfahren für verschiedene Ziele separat durchgeführt werden. Innerhalb des Datenflusses werden Datentransferprozesse für die Standard-Übertragung, Real-Time Data Acquisition und den Direktzugriff auf Daten verwendet (vgl. SAP 2008c). Die Definition eines solchen Datentransferprozesses kann sowohl über eine Prozesskette, als auch über den Objektbaum eines InfoProvider in der DWW vorgenommen werden. Durch die Definition über Prozessketten ergibt sich der Vorteil der automatischen Ausführung des Prozesses. Zur Laufzeit wird der DTP als Request behandelt. Über einen Monitor lassen sich für diesen Request der aktuelle Status und die (Fehler-)Meldungen der einzelnen Verarbeitungsschritte des Datentransferprozesses anzeigen. Diese Verarbeitungsschritte werden in der im DTP festgelegten Reihenfolge abgearbeitet und umfassen Funktionen, wie die einzelnen ETL-Prozesse oder Transformationen und Filterungen. Neben einer Übertragung des gesamten Datenbestands (FullExtraktionsmodus) können auch nur die Daten übertragen werden, die seit der letzten Übertragung aktualisiert wurden (Delta-Modus). Die Steuerung der Übertragungsweise aus dem DTP heraus ermöglicht die Übertragung an verschiedene Ziele mit unterschiedlichen Delta-Modi (vgl. SAP 2008c). Innerhalb der Datentransferprozesse kann auch die Fehlerbehandlung der Datensätze festgelegt werden, was durch einen gesonderten Fehler-DTP realisiert wird, aus dem die fehlgeschlagenen Übertragungen gerettet werden können. 3.2.7.2

Data Mart Interface

Das Data Markt Interface ermöglicht durch die Fortschreibung der Daten in einen weiteren Infoprovider eine weitere Transformation der Daten (vgl. SAP 2008c). Der Einsatz der Data Mart Interfaces kann dabei sowohl für den Datenaustausch zwischen mehreren SAP BI Systemen, als auch für den Datenaustausch zwischen einem BI-System und einem anderem SAP System genutzt werden. Zusätzlich lassen sich die Daten auch in ein anderes SAP BI Data Warehousing übertragen,

120

Data Warehouse-Architektur

um eine fachliche Konsolidierung oder Trennung zu erzielen (vgl. SAP 2008a). Dabei stellen die einzelnen Data Marts jeweils einen Teil der Daten des SAP BI Data Warehouse dar, die redundant in einer weiteren Datenbank oder einem anderen System abgelegt werden. Sie stellen einen Ausschnitt des Data Warehouse dar (vgl. SAP 2008c). Die über einen Data Mart bereitgestellten Daten werden von dem Zielsystem als DataSource genutzt und können sowohl in Form von Metadaten, als auch als Bewegungs- oder Stammdaten genutzt werden. Die Übertragung erfolgt über eine Export-DataSource, in der die jeweilig notwendigen Informationen enthalten sind. So enthalten die Export-DataSources für Bewegungs- und Stammdaten die Metadaten für alle Attribute, Texte und Hierarchien zu den enthaltenen Objekten und die Export-DataSource für Metadaten enthält die begleitenden Merkmale und Kennzahlen (vgl. SAP 2008c). Änderungen der Daten im Quellsystem der Übertragung lassen sich nur durch einen erneuten Export in das Zielsystem übertragen. Ebenso können aus dem Zielsystem heraus keine Daten im Quellsystem gelöscht werden. Bei einer solchen Fortschreibung muss beachtet werden, dass die gewünschten Objekte im Quellsystem aktiviert sind. 3.2.7.3

Open Hub Destination

Innerhalb der NetWeaver Plattform ist es möglich, die vorhandenen Daten aus dem BI-System in einen Fremdhersteller Data Mart oder eine vergleichbare Anwendung zu überführen. Dabei übernimmt die Open Hub Destination in den aktuellen Versionen die Aufgaben der InfoSpoke, die für den Open Hub Service verwendet wurde. Mittels der Open Hub Destination wird festgelegt, in welches Ziel die Daten weitergeleitet werden (vgl. SAP 2008c). Übertragen werden können sowohl Datenbanktabellen aus den Datenbanken der BI-Systeme, als auch flache Daten. Die Übertragung der Daten aus den Datenbanken in ein Fremdherstellersystem kann über eine API-Schnittstelle vorgenommen werden, auf die mit Drittanbieter-Werkzeugen zugegriffen werden kann. (vgl. SAP 2008c). Der Aufbau einer solchen Open Hub Destination enthält alle notwendigen Informationen, die über das Ziel der Datenverteilung benötigt werden. Dies umfasst die Art der Destination, der Name der Datenbanktabelle oder Datei, die übertragen werden soll, sowie die Eigenschaften und Feldliste samt Eigenschaften der zu übertragenden Daten (vgl. SAP 2008c). Zu den zulässigen Quellen, die für eine Open Hub Destination verwendet werden können, zählen die InfoProvider, InfoCubes, Data-Store-Objekte oder InfoObjekte. Auch InfoProvider die eine logische Sicht auf die Daten ermöglichen, können in Form der InfoSets genutzt werden. DataSources hingegen können nicht als Datenquelle für eine Open Hub Destination genutzt werden. Der Datenfluss mittels der Open Hub Destination erfolgt dabei gemäß Abbildung 3.31. Über den Datentransferprozess können die Daten fortgeschrieben werden und dabei einer Transformation unterliegen. Bei der Wahl der Transformation sind allerdings nicht alle Transformationsregeln gestattet, so kön-

SAP BI Data Warehousing

121

nen weder Stammdaten nachgelesen werden, noch Konvertierungen der Zeit oder eine Kennzahlumrechnung für die Typen Währung und Menge vorgenommen werden (vgl. SAP 2008c).

Abb.3.31 Datenverteilung mit Open Hub Destination

3.2.8 Data Warehouse Management Das Data Warehouse Management ist der Oberbegriff für administrative Tätigkeiten im SAP BI Data Warehousing. Diese fallen im regulären Betrieb des Systems an und werden bei der Betrachtung der BI oftmals gänzlich ausgeblendet. Denn diese Aufgaben werden im Hintergrund ausgeführt und sind erst dann erkennbar, wenn der Betrieb des SAP BI Data Warehousing gestört ist. Dabei sind sie genaugena so wie die Datenmodellierung oder das Berichtswesen Teil eines Ganzen. Im Regelbetrieb des SAP BI Data Warehousing fallen unterschiedliche Administrationsaufgaben an. Der wohl wichtigste Bereich ist die Überwachung und Steue-

122

Data Warehouse-Architektur

rung der Ladeprozesse, ohne die es keine Daten für Auswertungen im SAP BI Data Warehousing geben kann. Im Zusammenhang damit steht die Administration der Datenquellen und der Datenziele. Zusammengefasst werden die Überlegungen zur Datenbewirtschaftung unter dem Information Lifecycle Management und dem Information Quality Management. Daten unterliegen einem Lebenszyklus, der vom erstmaligen Laden der Daten bis zur Archivierung dieser in externen Speichersystemen reicht. Im Zuge dessen muss permanent die Sicherung der Datenqualität erfolgen, die primär beim Laden, aber auch bei der nachfolgenden Verarbeitung von Bedeutung ist. Neben den strukturierten Daten sind auch die Dokumente zu administrieren, die im SAP BI Data Warehousing genutzt werden. Außer der Verwaltung rund um die betriebswirtschaftlichen Daten sind auch die in einer SAP Systemlandschaft anfallenden generellen Tätigkeiten wahrzunehmen. Dies sind die Berechtigungs- und Nutzerverwaltung, der Transport von Entwicklungen in nachgelagerte Systeme und die Auswertung der Systemstatistiken (vgl. SAP 2008c). 3.2.8.1

Überwachung und Steuerung der Ladeprozesse

Ist der Datenfluss einmal entwickelt und getestet worden, muss das Konzept zur regelmäßigen und automatisierten Datenbefüllung umgesetzt werden. Schließlich soll das Data Warehouse die Daten selbständig beziehen, ohne dass die einzelnen Prozessschritte ein manuelles Eingreifen erfordern. Die Einplanung und Steuerung der Datenverarbeitung erfolgt im SAP BI Data Warehousing mit Hilfe von Prozessketten. Eine Prozesskette ist aus einer Abfolge von einzelnen Verarbeitungsschritten aufgebaut und wird durch Hintergrundprozesse gesteuert. Beginnend mit einem Start-Ereignis werden die einzelnen Prozessschritte in einer zeitlichen Abfolge angeordnet und mit logischen Operatoren verknüpft, bis der letzte Arbeitsschritt erreicht ist. Ein Beispiel für eine Prozesskette wird in Abbildung 3.32 gegeben (vgl. SAP 2008c). Die für die Verarbeitung der Daten zuständigen Prozessschritte werden Anwendungsprozesse genannt. Anwendungsprozesse werden in verschiedene Kategorien eingeteilt, um sie dem Zweck nach zusammenzufassen (vgl. SAP 2003).  Ladeprozesse und Nachverarbeitung – – – – – – –

InfoPackage ausführen PSA lesen und Datenziel verbuchen Hierarchie sichern DSO-Daten fortschreiben (Weiterverbuchung) Datenexport in Fremdsysteme überlappende Requests aus dem InfoCube löschen Event Datenänderung auslösen (für Broadcaster)

SAP BI Data Warehousing

123

 Datenziel-Administration – – – – – – – –

Index löschen Index aufbauen Datenbankstatistik aufbauen initiales Füllen neuer Aggregate Hochrollen gefüllter Aggregate Komprimieren des InfoCube DSO-Daten aktivieren vollständiges Löschen des Datenzielinhalts

 Reporting Agent – – – –

Exception Reporting Drucken im Hintergrund Vorberechnung von Web Templates Vorberechnung von Wertemengen

 Sonstige BI-Prozesse – – – –

Verhalten bei Stammdaten- und Hierarchieänderungen Anpassen zeitabhängiger Aggregate Löschen von Requests aus dem PSA Stammdatenattribute und -texte reorganisieren

 Allgemeine Services – – – – – –

ABAP-Programm Betriebssystemkommando Prozesskette lokal Prozesskette remote Workflow individuell implementierte Prozesse

Entsprechend der Abbildung 3.32 sollen die Anwendungsprozesse kurz erläutert werden. Die Prozesskette beginnt mit einem Startprozess, welcher den Beginn der Prozesskette darstellt. Er kann durch einen Hintergrundprozess oder direkt ausgelöst werden. Hintergrundprozesse haben den Vorteil, dass sie einmalig in regelmäßigen Intervallen eingeplant werden und keines weiteren Eingriffs bedürfen. An den Startprozess knüpft das Laden der Daten aus dem Quellsystem in die PSA an. Ein solcher Ladevorgang mit seinem Datenpaket wird als Request (Datenanforderung) bezeichnet. Sind die Daten in die PSA geladen worden, so werden sie in das DSO fortgeschrieben. Dort sind sie zunächst als neue Daten abgelegt, die noch aktiviert werden müssen. Nachdem die Daten aktiv gesetzt wurden, wird der InfoCube für die Befüllung mit neuen Daten vorbereitet. Für eine hohe Lade- und Leseperformanz ist das Löschen der bisherigen Indizes im InfoCube erforderlich. Anschließend werden die Daten aus dem DSO in den InfoCube geladen und die Indizes erneut aufgebaut. Zusätzlich zu den Indizes werden die Datenbankstatisti-

124

Data Warehouse-Architektur

ken aktualisiert, um die Leistung für das Berichtswesen zu optimieren. Zum Schluss werden Aggregate des InfoCube hochgerollt, damit die neuen Daten auch in den Aggregaten verfügbar sind (vgl. SAP 2003). Neben den im Beispiel genannten Anwendungsprozessen existieren auch verschiedene Prozesse zur Vorberechnung der Berichte, der Stammdatenreorganisation und dem Ausführen von ABAP-Programmen sowie anderer Prozessketten oder Betriebssystembefehlen. Hier wird die Mächtigkeit einer Prozesskette deutlich, welche sich ideal für die häufigsten Routineaufgaben im Data Warehouse Management eignet (vgl. SAP 2008c). Die Verarbeitung einer Prozesskette wird mit dem Monitor überwacht. Darin sind die wesentlichen Schritte in einem Log festgehalten, so dass die Arbeit der einzelnen Anwendungen detailliert nachvollzogen werden kann. An dieser Stelle ist das Etablieren eines Information Quality Managements sinnvoll. Zu Fehlern im Datenladeprozess kann es regelmäßig kommen. Deren Behandlung ist jedoch erforderlich, um auf der einen Seite die Datenqualität zu sichern und auf der anderen Seite die Datenladeprozesse vor falschen und den einwandfreien Prozessablauf gefährdenden Daten zu schützen (vgl. SAP 2003).

Abb. 3.32 Prozesskette (vgl. SAP 2003)

SAP BI Data Warehousing

3.2.8.2

125

Datenzieladministration

Über die Prozesskette werden nur regelmäßige, im Zusammenhang mit dem Laden der Daten stehende Arbeiten zur Datenadministration ausgeführt. Weitergehende Aufgaben werden direkt auf den Datenzielen ausgeführt. Hauptziel der Datenzieladministration ist die Sicherstellung der geforderten Leistung beim Laden der Daten in ein Datenziel und bei dessen Einsatz in Berichten. Mit zunehmendem Volumen im Datenbestand verlangsamen sich jedoch die Prozesse der Datenbewirtschaftung und des Lesens der Daten für Analysen. Um dem entgegenzuwirken und das Datenvolumen zu reduzieren, werden unterschiedliche Techniken eingesetzt. Zunächst muss die Leistung kontinuierlich anhand von Kennziffern überwacht werden. Wird eine Leistungseinbuße festgestellt, so kann das Datenvolumen eines InfoCube durch Partitionierung der Daten auf mehrere, vom Datenmodell her identisch aufgebaute InfoCubes verteilt werden. Ob die Zeitachse das Partitionierungsmerkmal ist oder ein anderes Merkmal gewählt wird, hängt davon ab, wie sich der Datenbestand langfristig in möglichst gleich große Bereiche aufteilen lässt. Bei der Partitionierung ist jedoch eine große Datenbankkapazität erforderlich. Eine einfachere und kostengünstige, wenn auch mit erheblichen Nachteilen verbundene Methode, ist die Bildung von Archiven. Dabei wird ein sehr selten genutzter Teil der Daten eines InfoCube gelöscht und in ein Archiv übertragen. Die Daten gehen dadurch nicht verloren, sondern können bei Bedarf hinzu gelesen werden. Allerdings kann dies wegen des Einsatzes von externen Speichersystemen (Nearline-Storage) oder Archivsystemen sehr langsam sein. Im Gegenzug ist der InfoCube selbst weiterhin leistungsstark und die Kosten für Datenspeicherung und Verwaltung sinken. Unterstützend können hier AggregatInfoCubes eingesetzt werden. In Aggregaten werden auf einer höheren Ebene zusammengefasste Daten gesichert, beispielsweise monatliche anstatt tägliche Daten. Fragt ein Bericht Monats- oder gar Jahreswerte ab, so greift die OLAP-Engine auf das Aggregat zu, anstatt die tagesgenauen Datensätze zu summieren. Wird das Aggregat nicht archiviert, so kann trotz Archivierung des ursprünglichen InfoCube weiterhin eine hohe Leistung im Berichtswesen durch den Datenbestand in den Aggregaten erbracht werden. In einem InfoCube kann der Datenbestand auch reduziert werden, indem Datenanomalien beseitigt werden. Sind viele einzelne Datensätze in den InfoCube geladen worden, die sich nur in den Kennzahlen unterscheiden und daher im Berichtswesen permanent aggregiert werden müssen, lassen sich diese einzelnen Datensätze zu einem einzigen komprimieren, ohne dass Informationen verloren gehen (vgl. SAP 2008c). Eine weitere Möglichkeit zur Steigerung der Systemleistung stellt der SAP NetWeaver BI Accelerator dar. Hier wird nicht das Datenmodell oder die Datenhaltungsstrategie verbessert, sondern die physische Hardware des SAP Servers um eine sehr große Menge RAM-Speicherbausteine ausgebaut, welche als riesiger Zwischenspeicher für die Inhalte der InfoCubes fungieren. Daten werden so nicht von den Festplatten, sondern aus dem viel schnelleren RAM gelesen (vgl. SAP 2008c).

126

Data Warehouse-Architektur

3.2.8.3

Dokumente

Die im SAP BI Data Warehousing eingesetzten Dokumente bedürfen einer regelmäßigen Pflege. Es werden laufend neue Dokumente erstellt, die zusätzliche Informationen zu Berichten und Kennzahlen liefern. Ebenso sind bestehende Dokumente zu pflegen oder aus dem System zu entfernen. Eine enge Zusammenarbeit mit dem Wissensmanagement ist für eine zielgerichtete Verwaltung der Dokumente erforderlich (vgl. SAP 2008c). 3.2.8.4

Transportwesen

Ein SAP NetWeaver 7.0 System wird in der Regel in einer Drei-Systemlandschaft aufgebaut. Alle drei Systeme sind voll funktionsfähig und unterscheiden sich lediglich im Entwicklungsstadium. Das für Entwicklungen genutzte System ist das Entwicklungssystem. Sind Entwicklungen fertiggestellt worden, so erfolgt ein Transport dieser in das Qualitätssicherungssystem. Ein Transport ist eine Menge von Datenbankeinträgen, welche die entwickelten Objekten beschreibt. Der Transport wird vom Entwicklungssystem zunächst in das Qualitätssicherungssystem und nach erfolgter Prüfung in das produktive System übertragen (vgl. SAP 2008c). Um die Entwicklungen im SAP NetWeaver BI System zu beschleunigen und eine Basis für kundenindividuelle Anpassungen zu schaffen, stehen dem Entwickler mit dem BI Content vorkonfigurierte Informationsmodelle zur Verfügung. Diese Objekte decken die Standards in den wesentlichen Bereichen des SAP BI Data Warehousing ab und sind gezielt für fachliche Bereiche, wie Controlling und Personalwirtschaft, erstellt worden sowie nach Branchen gegliedert. Auf diese Weise lassen sich umgehend Prototypen realisieren, welche vom Kunden evaluiert und weiterentwickelt werden können (vgl. SAP 2008c). 3.2.8.5

BI Statistiken

Im SAP BI Data Warehousing ist neben dem BI Content auch technischer Content enthalten. Dieser kann dem Systemadministrator dabei helfen, potentielle Probleme im Reporting zu erkennen. Das SAP BI Data Warehousing legt automatisiert Daten über die Leistung des Systems in den Objekten des technischen Contents ab und schreibt diese stetig fort. Auf diesem Wege wird eine systematische Überwachung der Leistung im Berichtswesen umgesetzt, ohne dass ein zusätzliches Monitoring-Werkzeug notwendig ist. Der Zugriff auf die Statistiken ist bequem über das Berichtswesen möglich (vgl. SAP 2008c).

SAP BI Data Warehousing

3.2.8.6

127

Sicherheitskonzepte

Ein integriertes Sicherheitskonzept ist für die unternehmensweite Business Intelligence hochkritisch. Da mit den Daten des Unternehmens auch viele sicherheitskritische und vom Datenschutz betroffene Informationen integriert und über das SAP BI Data Warehousing abgebildet werden, ist ein ausgeprägtes Sicherheitskonzept für den Zugriff auf die Daten Pflicht. Die erste Stufe im Sicherheitskonzept sind Standard-Berechtigungen. Jeder Benutzer, der mit einem Teil der SAP NetWeaver BI arbeiten will, benötigt eine Standard-Berechtigung, die auf dem SAP Berechtigungskonzept basiert. Diese Berechtigungen werden in Rollen zusammengefasst und einzelnen Benutzern zugewiesen (vgl. SAP 2008c). Das Sicherheitskonzept der zweiten Stufe betrifft Analyseberechtigungen. Sobald ein Nutzer die Daten eines berechtigungsrelevanten Merkmals in einer Query aufruft, prüft das System, ob er über die entsprechenden Analyseberechtigungen zu diesem InfoObjekt verfügt. Diese Berechtigungen unterscheiden sich von den Standard-Berechtigungen und verwenden ein eigenes Konzept, das die gesonderten Anforderungen von Entwicklung und Reporting berücksichtigt (vgl. SAP 2008c).

3.2.9 Real-Time Data Acquisition Ein Data Warehouse wird in der Regel für das strategische Reporting eingesetzt. Zu diesem Zweck werden Massendaten in regelmäßigen Abständen in das System geladen und konsolidiert. Der eingesetzte ETL-Prozess ist der zeitlich aufwändigste im Data Warehousing und kann mehrere Stunden pro Lauf in Anspruch nehmen. Dieser Umstand ist den an der Data Warehouse Entwicklung beteiligten Akteuren bekannt, wird aber von den Berichtsanwendern nicht immer akzeptiert. Denn anstatt das operative Berichtswesen weiterhin auf dem OLTP-System auszuführen, wird eine vollständige Übertragung aller Berichte auf das Data Warehouse gefordert. Die Vorteile sind gänzlich klar: Einheitliche Pflege der Berichte, zentraler Einstieg in das Berichtswesen ohne Systembrüche und voller Zugriff auf alle, vor allem neueste Informationen im Unternehmen, die von der jährlichen Verkaufsstatistik bis hin zum minutenaktuellen Lagerbestand reichen. Die technische Lösung der SAP für diese Anforderung ist das Real-Time Data Acquistion Konzept (vgl. SAP 2008c). Kernelement der Real-Time Data Acquisition ist die Verwaltung von Datenpaketen durch einen Dämon. Dabei handelt es sich um einen Hintergrundprozess, der die Anforderung der Daten regelmäßig (etwa jede Minute) anstößt und verwaltet. Basis hierfür ist ein Prozess im Quellsystem, der dort die Delta-Queue unmittelbar nach einer Datenänderung mit neuen Daten versorgt. Im SAP BI Data Warehousing öffnet der Dämon einen PSA-Request, der eine Verbindung zum Quellsystem darstellt. Wenn dieser PSA-Request Daten aus der Delta-Queue im

128

Data Warehouse-Architektur

Quellsystem liefert, öffnet der Dämon weitere Folge-Requests für die Datenübertragung im Data Warehouse. Die Folge-Requests sind dafür verantwortlich, dass die Daten letztendlich in ein DSO geschrieben werden und unmittelbar für das Berichtswesen bereitstehen. Dadurch kann ein operatives Reporting realisiert werden. Das Laden von Echtzeitdaten ist mit verschiedenen Nachteilen verbunden. Um dieses Konzept überhaupt umzusetzen, wird der PSA-Request nicht nach jeder Datenanforderung geschlossen, sondern bleibt bis zur Überschreitung eines Schwellwertes offen. Anschließend wird zeitgleich ein neuer PSA-Request geöffnet, um die Verbindung zum Quellsystem aufrecht zu erhalten. Auf diese Weise wird die Anzahl der durch das SAP BI Data Warehousing gleichzeitig zu verwaltenden Requests reduziert, was für das System von Vorteil ist. Dies führt dennoch zu einem erhöhten Ressourcenverbrauch im Quell- und Zielsystem, weil die Verbindung offen und der Prozess permanent aktiv ist. Neben der Systemlast sind auch verschiedene technische Restriktionen in Kauf zu nehmen. So können nur Bewegungsdaten über diesen speziellen Prozess übertragen werden. Im Gegensatz zu virtuellen InfoProvidern, die ihre Daten im Quellsystem belassen, sind die mit der Real-Time Data Acquisition geladenen Daten dafür auch physisch im SAP BI Data Warehousing abgelegt (vgl. SAP 2008c).

3.3

SAP BW Reporting

Das SAP BW bietet nicht nur Werkzeuge zur Datenmodellierung und Datenbewirtschaftung an, es besitzt zudem ein leistungsstarkes, anwenderfreundliches Paket an integrierten Funktionen zur Erstellung von flexiblen, in Layout und Funktionalität frei definierbaren Berichten. Grundlage für den Aufbau des Reporting sind ein komplettiertes Datenmodell und eingerichtete Datenflüsse, denn die Datenbankabfragen setzen auf den Objekten des Datenmodells auf und lesen zur Laufzeit die in das System geladenen Daten, um sie letztendlich auf dem Bildschirm ausgeben zu können. Sind die Voraussetzungen durch das Datenmodell und die Datenbewirtschaftung erfüllt, so kommen die Werkzeuge der Business Intelligence Suite zum Einsatz, die ein fester Bestandteil des SAP Business Information Warehouse ist. In der BI-Suite sind die Anwendungen des Business Explorer enthalten, welche die Berichtsfunktionen bereitstellen (siehe Abb. 3.33). Zur Erstellung von Abfragen auf den InfoProvidern im SAP BW dient der BEx Query Designer. Damit können die multidimensionalen Datenstrukturen in einer zweidimensionalen Tabelle angeordnet werden, damit sie sich in Auswertungen einbetten lassen. Auswertungen werden mit dem BEx Analyzer, einer in Microsoft Excel realisierten, analytischen Anwendung, oder im Web mittels des Webbrowsers betrachtet. Die Web-Anwendungen lassen sich im BEx Web Application Designer erstellen und in das SAP NetWeaver Portal publizieren. Die Darstellung im millimetergenauen Drucklayout übernimmt der BEx Report Designer. Die Vor-

SAP BW Reporting

129

stellung dieser vier, auf einem lokalen System zu installierenden Anwendungen, bildet den Inhalt dieses Abschnitts.

Abb. 3.33 BI Suite (vgl. SAP 2005)

3.3.1 BEx Query Designer Der erste Schritt hin zu einer mit der BI-Suite erstellten Auswertung wird über den BEx Query Designer vollzogen. Dieses Werkzeug bietet eine grafische Oberfläche zur Modellierung von Abfragen auf den InfoProvidern im SAP BW. Die sogenannten BEx Queries stellen das Datengerüst eines jeden Berichts im SAP BW dar und werden in allen anderen Anwendungen der BI-Suite verwendet (vgl. SAP 2006). Eine BEx Query ist die Definition der Anordnung von Merkmalen und Kennzahlen in den Zeilen oder Spalten einer tabellarischen Struktur. Die Merkmale und Kennzahlen sind als InfoObjekte in InfoProvidern enthalten, die für das Reporting freigegeben worden sind. Beim Anlegen einer neuen BEx Query wird daher zunächst der InfoProvider gewählt, dessen Struktur für eine Datenbankabfrage herangezogen werden soll. Wurde die Auswahl bestätigt, so zeigen sich im Feldvorrat der BEx Query in erster Linie alle Merkmale und Basiskennzahlen des InfoProvider. Aus diesem Vorrat an Feldern kann die BEx Query aufgebaut werden. Ist dieser InfoProvider bereits für einen Bericht eingesetzt worden, so können zu diesem InfoProvider zusätzlich auch im BEx Query Designer erstellte eingeschränkte oder berechnete Kennzahlen sowie Strukturen, die eine zweckgebundene, wiederverwendbare Anordnung von Merkmalen und Kenzahlen darstellen, verfügbar sein. Je weiter das Reporting auf einem InfoProvider ausgebaut wird,

130

Data Warehouse-Architektur

desto schneller werden aufgrund der hohen Wiederverwendbarkeit der BEx Query-Bestandteile Ergebnisse erzielt (vgl. SAP 2006). Die Definition einer BEx Query lässt sich in drei Aufgabenbereiche einteilen. Der erste Bereich behandelt die Bildung der Zeilen- und Spaltenstruktur aus den, im Feldvorrat verfügbaren InfoObjekte und aus neuen, noch zu erstellenden Kennzahlen und Strukturen. Per Drag & Drop lassen sich die im Feldvorrat angebotenen Objekte in die Bereiche Freie Merkmale, Zeilen und Spalten ziehen. In der Voransicht wird der zu erwartende Aufbau der Ergebnistabelle abgebildet (siehe Abb. 3.34). Sobald Kennzahlen in die Spalten oder Zeilen gezogen werden, bildet der BEx Query Designer eine ihnen übergeordnete Struktur. Nachdem der Aufbau der Ergebnistabelle bekannt ist, kann im zweiten Aufgabenbereich das Setzen von Filtern erfolgen. Filter schränken das Query-Ergebnis auf bestimmte Merkmalsausprägungen ein, um eine Sicht auf einen, für den Bericht und den Adressaten relevanten Teil der Daten zu gewähren. Nicht notwendige und womöglich das Verständnis erschwerende Informationen werden so wirksam ausgeblendet. Als letzter Aufgabenbereich stellen sich die Anpassung der Eigenschaften von Objekten und der BEx Query selbst sowie die Ausführung besonderen BEx Query Funktionen dar. Es lassen sich viele verschiedene Eigenschaften für die Objekte in der BEx Query und die Query insgesamt verändern, um das Verhalten der BEx Query zur Laufzeit zu beeinflussen. Als besondere Funktionen sind zum Beispiel die Definition von Ausnahmezellen, das Exception Reporting oder die Bedingungen zu sehen, welche die Berichte um zusätzliche Funktionen, wie das Hervorheben von Schwellwerten, erweitern. Als besondere Fähigkeit der BEx Query ist die Bericht-Bericht-Schnittstelle (BBS) zu nennen (vgl. SAP 2005). Ist die BEx Query fertiggestellt, so kann sie direkt aus dem BEx Query Designer im Portal aufgerufen und in der Ansicht des BEx Web Analyzer ausgeführt werden. Ebenso kann eine BEx Query als iView direkt in das SAP NetWeaver Portal geladen oder in eine Portalrolle bzw. den Portalcontent integriert werden (vgl. SAP 2005). 3.3.1.1

Anordnen von Merkmalen, Kennzahlen und Strukturen

Alle im InfoProvider verfügbaren InfoObjekte lassen sich im Aufriss der Zeilen oder Spalten sichtbar anordnen. Merkmale lassen sich zusätzlich im Aufriss unsichtbar als Freie Merkmale oder als Filter in einer BEx Query verwenden. Freie Merkmale lassen sich wie die Filter ebenfalls einschränken, haben gegenüber den Filtern allerdings den Vorteil, dass sie sich zur Laufzeit der BEx Query in die Tabellenstruktur integrieren lassen. Ebenso können alle Merkmale aus den Zeilen oder Spalten entfernt und in den Freien Merkmalen angeordnet werden. Diese Art des Aufbaus einer BEx Query bietet eine hohe Flexibilität bei der Datenanalyse. Neben den sichtbaren Merkmalen lassen sich zudem auch deren Attribute in der Query darstellen. Auf diese Weise kann auf Informationen zugegriffen werden, welche nicht explizit in den InfoProvider geladen wurden (vgl. SAP 2005).

SAP BW Reporting

131

Abb. 3.34 BEx Query Designer

Kennzahlen bilden als betriebswirtschaftliche Auswertungsobjekte Werte ab, die über die Merkmale hinweg aggregiert werden und den eigentlichen Kern der Tabellenstruktur bilden. Elementare Kennzahlen sind im InfoProvider enthalten, sie können aber zu eingeschränkten oder berechneten Kennzahlen entwickelt werden. Eingeschränkte Kennzahlen stellen komplexere Objekte als elementare Kennzahlen dar, denn sie sind bereits per Definition nur für bestimmte Merkmalsausprägungen gültig. Auf diese Weise ist es leichter, eine betriebswirtschaftliche Einheit zu bilden, die wiederverwendbar in BEx Queries eingesetzt werden kann. Mit eingeschränkten Kennzahlen lassen sich beispielsweise die Quartalsumsätze eines Buchungskreises abbilden und in jeder BEx Query hinzufügen, ohne dass die Kennzahl jedes Mal aufs Neue gebildet werden müsste. Berechnete Kennzahlen sind ebenfalls komplexere Kennzahlen, die durch Berechnungsvorschriften def definiert sind. Diese Formeln bieten arithmetische und logische Operationen an, um mehrere Kennzahlen mit einander zu verbinden und zur Laufzeit der BEx Query berechnen zu lassen. Oftmals wird der Differenzwert von zwei Kennzahlen durch Subtraktion dieser in einer berechneten Kennzahl ermittelt und in der BEx Query ausgegeben, um leichter einen Vergleich zwischen den beiden elementaren Kennzahlen ziehen zu können (vgl. SAP 2008c). Strukturen haben die Eigenschaft, dass sie in ihrer Form als eine definierte Anordnung von Selektionen und Formeln über mehrere BEx Queries hinweg wiederverwendbar eingesetzt werden können. Selektionen sind eingeschränkten Kennzahlen ähnlich, Formeln gleichen berechneten Kennzahlen. Auf diese Weise

132

Data Warehouse-Architektur

wird unnötiges, manuelles Übertragen von BEx Query-Elementen durch einfaches, konsistentes Wiederverwenden der Strukturen ersetzt. Auf diese Weise lässt sich eine ganze Gruppe von zueinander ähnlichen BEx Queries durch die Verwendung von einigen wenigen Strukturen in kürzester Zeit erstellen. Durch die optionale hierarchische Darstellung lässt sich sogar der Eindruck eines verschachtelten Aufbaus der Strukturelemente erwirken (vgl. SAP 2006). Selektionen und Formeln einer Struktur lassen sich aus Kennzahlen und Merkmalen aufbauen. Kennzahlstrukturen enthalten in den Selektionen und Formeln eine oder mehrere Kennzahlen. Sie werden in BEx Queries oft orthogonal zu Merkmalen oder merkmaltragenden Strukturen eingesetzt. Die Kennzahlen können entweder bereits als elementare, eingeschränkte oder berechnete Kennzahl vorliegen, oder sie werden durch Selektionen oder Formeln innerhalb der Struktur zu diesen umgeformt. Berechnungsformeln in Strukturen sind zum Beispiel als prozentuale Anteile einer Kennzahl an einer anderen zu finden. Befindet sich keine Kennzahl in der Struktur, wird von Merkmalsstrukturen gesprochen. Merkmalsstrukturen bieten neben Selektionen, die als Filter über Merkmale zu verstehen sind, ebenfalls Berechnungsformeln an, obwohl sie über keine Kennzahlen verfügen. Weil sie jedoch wie die Selektionen auf alle zu ihnen orthogonal liegenden Kennzahlen wirken, ist der Einsatz von Formeln zulässig. Vielmals genutzte selektive Strukturen sind Zeitreihen, in denen zum Beispiel die letzten vier Monate als eigene Selektion innerhalb der Struktur definiert sind. Die Formel bildet den Durchschnitt über die Selektionen. Auf diese Weise können zum Beispiel der Umsatz oder die Anzahl Kunden simultan über die letzten vier Monate betrachtet und als Durchschnitt ausgewiesen werden, ohne dass alle Kennzahlen einer individuellen Einschränkung und Berechnung unterzogen werden müssten. Es genügen die elementaren Kennzahlen Umsatz bzw. Anzahl Kunden. 3.3.1.2

Filterwerte für Merkmale

Mit Filtern wird der im InfoProvider verfügbare Datenbestand segmentiert. Dadurch wird dem Betrachter statt einer Informationsflut ein adressatengerechter Bericht zur Verfügung gestellt. Filter wirken auf Merkmale, indem ein oder mehrere Merkmalswerte in den Filter eingeschlossen oder aus der Menge der gewünschten Werte ausgeschlossen werden. Ist eine Hierarchie zu einem Merkmal verfügbar, so lassen sich sogar Filter auf Basis des Hierarchiebaums bilden, wodurch die gleichzeitige Filterung vieler Werte stark vereinfacht wird. Da Kennzahlen im InfoProvider in der Regel gemeinsam mit einem auswertbaren Merkmal gespeichert sind, lassen sich bestimmte Kennzahlwerte herausfiltern. Möchte der Anwender zum Beispiel nur den Umsatz eines einzigen Produkts in seiner Auswertung betrachten, so wird auf das Merkmal Produkt ein Filter mit dem eindeutigen Schlüsselwert des gewünschten Produkts gesetzt. Im Bericht sind daraufhin nur die Kennzahlwerte zu einem einzigen Produkt sichtbar (vgl. SAP 2008c).

SAP BW Reporting

133

Filter wirken zu einander ergänzend, indem die Datenmenge umso stärker eingeschränkt wird, je mehr verschiedene Filter gesetzt werden. Um dieses Verhalten zu unterbinden, kann eine Selektion in einer Struktur der BEx Query als konstant deklariert werden. Auf diese Werte haben Filter außerhalb der Selektion keine Wirkung. In der BEx Query werden neben statischen Filtern, welche sich zur Laufzeit nicht mehr ändern lassen, auch dynamische Filter eingesetzt. Statische Filter befinden sich im Filterbereich der BEx Query und sind Teil von Selektionen in Strukturen und eingeschränkten Kennzahlen. Dynamische Filter lassen sich als Vorschlagswerte in die BEx Query einfügen und sind an die Merkmale gebunden, die sich in den Freien Merkmalen, Spalten oder Zeilen befinden. Diese Filter lassen sich während der Laufzeit verändern (vgl. SAP 2008c). Zum Themenbereich der Filter gehören auch Merkmalswertvariablen. Variablen im Allgemeinen werden in BEx Queries eingesetzt, um zur Laufzeit einen Wert dynamisch durch das System zu ermitteln. Als Beispiel soll eine Variable auf den Kalendermonat dienen, die erst beim Ausführen der BEx Query manuell oder automatisch mit einem Wert belegt wird. Mittels Variablen erhält die BEx Query eine größere Flexibilität, ohne dass eine aufwändige Navigation oder zusätzliches manuelles Filtern notwendig sind. Variablen lassen sich auch mit Offsets belegen, wodurch sich eine Selektion auf die letzten vier Jahre abbilden lässt. Während in die Variable das Bezugsjahr einzutragen ist, werden die drei vorherigen Jahre durch die Subtraktion von einem, zwei oder drei Jahren von der ursprünglichen Variable ermittelt und in einer Selektion eingesetzt (vgl. SAP 2006). 3.3.1.3

Eigenschaften der BEx Query-Elemente und der BEx Query

Die Anordnung der Merkmale und Kennzahlen, das Anlegen von Strukturen sowie das Setzen von Filtern werden durch die Veränderung der Eigenschaften der BEx Query-Elemente und der BEx Query selbst verfeinert. Merkmale bieten im Wesentlichen Eigenschaften zur Darstellung. So lässt sich einstellen, ob ein Merkmal beispielsweise nur mit seinem Schlüssel oder stattdessen mit einem der zu ihm hinterlegten Texte zur Laufzeit sichtbar sein soll und ob eine Sortierung gewünscht ist. Ergebniszeilen, die je Merkmal die Summe der Kennzahlen zur Laufzeit enthalten, können unterdrückt werden, wenn der Anwender viele Merkmale nebeneinander darstellen möchte und nicht jedes Merkmal eine Gruppenstufe bilden soll. Ebenso kann eine zum Merkmal hinterlegte Hierarchie aktiviert werden, um die Merkmalsausprägungen in einer Baumstruktur abzubilden. Weiterhin lässt sich bestimmen, dass immer alle Stammdaten zum Merkmal ausgegeben werden, auch wenn es keine Kennzahl mit einem entsprechenden Wert im InfoProvider gibt. Mögliche Filter lassen sich ebenso auf die Stammdaten im Merkmal die Bewegungsdaten im InfoProvider einschränken. Ist eine Planung für die BEx Query gedacht, so kann eine Hierarchie genutzt werden, um Werte entlang des Baums zu budgetieren. Eigenschaften der Attribute eines Merkmals sind nicht so vielfältig und beeinflussen nur deren Darstellung (vgl. SAP 2006).

134

Data Warehouse-Architektur

Bei Kennzahlen stehen Eigenschaften zur Darstellung der Werte und zur Berechnung im Vordergrund. Hierzu werden Skalierungsfaktoren, die Anzahl der Dezimalstellen, das farbliche Hervorheben und der Vorzeichenwechsel gezählt. Eine Kennzahl kann auch ausgeblendet werden, wenn sie innerhalb einer Struktur nur zur Berechnung einer Formel benötigt wird und im Bericht ansonsten nicht von Interesse ist. Eigenschaften der Berechnung haben Einfluss auf die Aggregation der Kennzahl. So lassen sich zum Beispiel automatisch Durchschnittswerte bilden, ohne dass zu diesem Zweck mehrere Kennzahlen und Formeln notwendig wären. Bei Formeln kann die Priorität gesetzt werden, um unbeabsichtigte Ergebnisse bei einer Kollision von Formeln in Zeilen und Spalten zu vermeiden. Diese treten insbesondere bei der Berechnung von anteiligen Werten auf. Neben dem Kennzahlenwert selbst kann auch die Berechnungsart einer Ergebniszeile beeinflusst werden. Hinzu kommen Funktionen zur Währungs- und Einheitenumrechnung sowie die Eigenschaften in Verbindung mit der Planung. Die Eigenschaften der Kennzahlen sind auf alle Elemente einer Struktur übertragbar, auch wenn in der Struktur selbst keine Kennzahlen explizit verwendet werden (vgl. SAP 2006). Eigenschaften der BEx Query wirken global auf alle ihre Bestandteile. Meist werden BEx Queries mit einem zeitlichen Bezug ausgeführt. Dieser ist im Standard auf den Tag der Ausführung der Query gesetzt, kann aber in den Eigenschaften beispielsweise mit einer Variablen belegt werden, um historischen Gegebenheiten Rechnung zu tragen. Neben einer Vielzahl anderer Eigenschaften lassen sich auch wiederholende Schlüsselwerte unterdrücken, um eine klar gegliederte Tabellenansicht zu erreichen (vgl. SAP 2006). 3.3.1.4

Besondere Funktionen der BEx Query

Ausnahmezellen sind individuell bestimmte Zellen eines Berichts. Sie treten nur auf, wenn ausschließlich zwei orthogonale Strukturen in den Zeilen und Spalten einer BEx Query enthalten sind. Nur dann ist gewährleistet, dass die Anzahl der Zeilen und Spalten, ergo der Tabellenaufbau konstant sind. So kann jede Zelle durch einen individuell bestimmbaren Wert gefüllt werden. Dies ist hilfreich, wenn stets ein Wert in einer Zelle enthalten sein soll, um eine Konstante zu bilden (vgl. SAP 2008c). Zu den besonderen Funktionen einer BEx Query zählen Ausnahmeregeln und Bedingungen. Ausnahmeregeln sind geeignet, um Kennzahlen, deren Werte in einem bestimmten Intervall liegen, farblich hervorzuheben. Dabei kann eingestellt werden, ob die Datenzelle, ein Element der Struktur oder ein Merkmal farblich hervorgehoben wird (vgl. SAP 2008c). Ähnlich einem Filter, wirkt die Bedingung. Sie schränkt die Anzahl der Datenzeilen oder -spalten ein, indem sie diese in Abhängigkeit vom Wert der Kennzahlen ausblendet. Bedingungen können auf einige oder alle Merkmale der BEx Query bezogen werden und gelten für eine oder mehrere Kennzahlen. Als

SAP BW Reporting

135

Bedingungsoperatoren stehen unter anderem Top-N und Top-% zur Verfügung, um nur die höchsten Werte im Bericht auszuweisen (vgl. SAP 2006). Die Bericht-Bericht-Schnittstelle (BBS) ist eine Funktion, die bei anspruchsvollen Berichten zum Einsatz kommt. Sie definiert ein Sprungziel aus einem Bericht heraus, welches eine Webseite, eine BEx Web Application, eine BEx Query oder gar eine Transaktion in einem SAP System sein kann. Ist eine BEx Web Application oder BEx Query das Ziel, so werden die Selektionen der bei der Funktionsausführung markierten Zelle im Senderbericht beim Aufruf des Sprungziels berücksichtigt. Durch die Integration der Selektionsbedingungen können mehrere ber Berichte miteinander verbunden und zu einer umfassenden Anwendung ausgebaut werden (vgl. SAP 2008c).

3.3.2 BEx Web Application Designer Um Inhalte einer BEx Query im Web darstellen zu können, wird eine Web Applikation mit dem BEx Web Application Designer erstellt (siehe Abb. 3.35).

Abb. 3.35 BEx Web Application Designer

Mit diesem Werkzeug ist es möglich, BEx Queries in interaktive Webseiten einzubetten, deren Funktionsumfang vom einf einfachen Bericht bis hin zu einem komplexen Analyse- oder Managementcockpit reicht. Der BEx Web Application De-

136

Data Warehouse-Architektur

signer bietet neben einer grafischen Oberfläche mit einem Editor für Webseiten vor allem auch bereits vorgefertigte Objekte, welche die meisten Funktionen zur Navigation im Datenbestand und zur Darstellung der Inhalte bereitstellen, ohne dass der Entwickler Programmiertechniken beherrschen müsste. Dennoch kann auch eine HTML-Quellcodebearbeitung erfolgen (vgl. SAP 2008c). 3.3.2.1

Web Template

Eine Web Template ist technisch betrachtet eine besondere XHTML-Seite, die Informationen zur Gestaltung des Berichts und zur Datenquelle enthält. BEx Queries, die aus dem BEx Query Designer heraus im Web ausgeführt werden, zeigen sich im Web Template des BEx Web Analyzer. Er bietet einen ersten Eindruck von den Funktionen, die in einer Web Applikation möglich sind (vgl. SAP 2005). Auf Basis eines leeren XHTML-Dokuments werden statische und dynamische Bereiche gebildet, aus denen der Aufbau und die Inhalte des Berichts resultieren. Als Gestaltungshilfe wird dabei eine blinde, weil zur Laufzeit unsichtbare HTMLTabelle genutzt, welche die Seite in ein Raster verwandelt, mit dessen Hilfe die einzelnen Bausteine, wie Texte, Bilder und Ergebnistabellen, angeordnet und ausgerichtet werden. Statische Bereiche dienen der Anordnung aller Objekte und enthalten Inhalte, die zur Laufzeit des Berichts nicht verändert werden. Sie enthalten statischen HTML-Code. Dynamische Bereiche hingegen werden erst dann mit HTML-Code gefüllt, wenn die Web Applikation ausgeführt wird. Im Entwicklungsstadium sind lediglich beschreibende Tags im XHTML-Dokument enthalten. Erst beim Aufruf der Seite auf dem Server werden sie gegen HTML-Befehle ausgetauscht. Dynamische Bereiche eines Web Template sind auf Web Items zurückzuführen. Die Wiederverwendbarkeit eines Web Template ist durch sogenannte Pattern gegeben. Dieses sind vorgefertigte Schablonen, die funktionsfähige Bestandteile einer Web Applikation bilden. So lassen sich sehr schnell einheitliche Web Templates aus mehreren Pattern erschaffen, ohne dass der Quellcode eines Web Template in ein anderes kopiert werden muss (vgl. SAP 2006). Die Formatierung einer Web Applikation erfolgt durch Cascading Style Sheets (CSS). Dabei handelt es sich um eine spezielle Form der Kodierung von Formatierungsanweisungen in HTML-Seiten. Sie ist insbesondere auf Wiederverwendbarkeit ausgelegt, um eine einheitliche Formatierung über mehrere Webseiten hinweg sicherzustellen. Diese Style Sheets können automatisch vom Motiveditor des SAP NetWeaver Portals erzeugt werden, um ein einheitliches Aussehen der Berichte und des Portal-Contents zu gewährleisten. Diese Technologie wird als Unified Rendering Framework der SAP bezeichnet (vgl. SAP 2008c). Im Web Template besteht weiterhin die Möglichkeit, mit Java Script zu arbeiten. Das SAP BW bietet verschiedenste Java Script-Funktionen an, welche eine komplexe Ablauflogik erlauben. Der Entwickler kann den Funktionsaufruf in den Quellcode der XHTML-Seite eingeben und um weitere Java Script-Befehle erweitern. So lassen sich höchst individuelle Verarbeitungslogiken entwickeln und Be-

SAP BW Reporting

137

richte stärker an die Anforderungen des Kunden anpassen. Die speziellen vom SAP BW interpretierbaren Funktionen zur Kommunikation mit dem System sind in der Web Design API beschrieben. Sie zielen insbesondere darauf ab, die Eigenschaften von Web Template, Web Item und Data Provider zu verändern. So kann beispielswiese die Zuordnung einer BEx Query zu einem Data Provider im Web Template zur Laufzeit durch Java Script derart verändert werden, dass der Anwender zwischen zwei Berichten hin- und herschalten kann. Allerdings erfordert diese Art von Programmierung Grundkenntnisse in Java Script und HTML (vgl. SAP 2006). 3.3.2.2

Web Items

Dynamische Bereiche eines Web Template werden durch Web Items beschrieben. Web Items sind von der SAP bereitgestellte Objekte, welche in der Entwicklungsumgebung als Tags, zur Laufzeit der Query jedoch vom SAP BW dynamisch in HTML-Code übersetzt werden. Während dieses Vorgangs setzt sich das SAPSystem mit der Datenbank in Verbindung und liest die Daten aus dem InfoProvider, wie es die BEx Query vorgibt. Das Ergebnis wird in die XHTML-Seite als HTML-Code eingefügt und letztendlich im Webbrowser des Betrachters ausgegeben. Durch diese Technologie entfällt für den Entwickler eine aufwändige Programmierung. Stattdessen werden alle notwendigen Einstellungen zur Darstellung und dem Lesen der Daten über die Eigenschaften eines Web Item und den ihm zugeordneten Data Provider gesteuert. Wenn ein Web Template aktualisiert wird, so werden auch die Web Items vom SAP-Server neu erzeugt (vgl. SAP 2008c). Die meisten Web Items sind an einen Data Provider angeschlossen, damit sie dynamisch Daten ausgeben können. Wenn eines der an einen Data Provider angebundenen Web Items eine Navigations- oder Filteroperation auf diesem Data Provider vollzieht, hat dies auch Auswirkung auf alle anderen angebundenen Web Items. So führt die Filterung nach einer Merkmalsausprägung durch ein Web Item dazu, dass das Web Item für die Tabellendarstellung nur noch die gefilterten Daten ausgibt. Web Items sind daher nicht nur lesend aktiv, sondern auch sendend, indem sie die vom Anwender gewünschten Operationen an das SAP-System übergeben, welches diese ausführt (vgl. SAP 2008c). Im Folgenden soll auf die wesentlichen Web Items eingegangen werden, die zum Aufbau eines Web-Berichts eingesetzt werden (siehe Tabelle 3.11).

138

Data Warehouse-Architektur

Tabelle 3.11 Web Items (vgl. SAP 2008c) Web Item

Beschreibung

Analyse

Das mit am häufigsten eingesetzte Web Item ist das der Analyse. Es entspricht dem Ergebnisbereich einer BEx Query und stellt die gewünschten Daten in einer Tabelle dar.

Chart

Mit Hilfe des Diagramms ist der Anwender in der Lage, sich schnell einen Überblick über die Kennzahlen zu verschaffen. Der Einsatz eines Diagramms erfordert in der Regel einen von der Tabelle verschiedenen Aufriss, um den Anforderungen des Diagrammtyps gerecht zu werden.

Navigationsbereich

Der Navigationsbereich erlaubt es dem Anwender, den Aufriss des Reports bequem zu verändern. Meist ist diese beim Einsatz der Analysetabelle sinnvoll.

Dropdown-Box

Um Filter direkt anwählen zu können, eignen sich Web Items wie die Dropdown-Box.

Hierarchische Filterauswahl

Mit der hierarchischen Filterauswahl ist eine besondere Form der Dropdown-Box gegeben. Sie stellt die Filterwerte wie in einem Baum dar, sofern das dazugehörige Merkmal über eine Hierarchie verfügt.

Web Template

Oft wird innerhalb eines Web Template ein weiteres Web Template eingefügt. Dies erlaubt eine modulare Entwicklung.

Container

Der Container dient dazu, andere Web Items oder HTML-Code aufzunehmen. Er macht außerdem den Einsatz einer zusätzlichen HTMLTabelle zur Gestaltung überflüssig.

Registerkarten

Registerkarten haben die Eigenschaft dem Anwender viele Inhalte übersichtlich zur Verfügung zu stellen. Eine umständliche Programmierung ist nicht notwendig.

Karte

Die Landkarte ist ein besonderer Blickfang. Sie ist speziell für strategische Berichte eine wertvolle Ergänzung zum Zahlenmaterial.

Menüleiste

Die Menüleiste ist besonders bei Planungsanwendungen hilfreich, wenn viele Funktionen im Web-Bericht auszuführen sind.

3.3.3 BEx Report Designer Der BEx Report Designer dient der Erstellung von Berichten mit einem für das Ausdrucken optimierten Layout. Mit diesem Werkzeug wird die Forderung der Anwender nach einer komfortablen Möglichkeit des Druckens eines im Web ausgeführten Berichts erfüllt. Die gestalterischen und formatbedingten Anforderungen an einen Web-Bericht sind nur selten mit denen an einen druckbaren Bericht vereinbar. Es ist somit legitim, für das Drucken ein anderes Format zu wählen, als der Web-Bericht es bietet. Zudem ist der PDF-Druck eines formatierten Berichts um vieles sinnvoller, als der einer gewöhnlichen Webseite, die skaliert oder in ihrer Gestaltung stark zensiert werden müsste.

SAP BW Reporting

139

Der BEx Report Designer bietet viele Funktionen, die aus anderen, vergleichbaren Werkzeugen zur Publizierung bekannt sind. So ist die Anordnung der Objekte sogar pixelgenau möglich, Kopf Kopf- und Fußzeilen lassen sich beliebig gestalten, Seitenumbrüche definieren und Tabellen auf den nachfolgenden Seiten fortsetzen. Texte lassen sich individuell formatieren und können aus dem Data Provider entnommen oder direkt als statischer Text eingegeben werden. Außerdem lassen sich Grafiken, Diagramme und Tabellen einfügen. Alles in allem sind sämtliche Funktionen enthalten, um einen ansprechend formatierten Bericht zu erstellen (siehe Abb. 3.36). Zudem existiert eine Web-Ansicht, welche den Einsatz von Filtern zulässt (vgl. SAP 2006).

Abb. 3.36 BEx Report Designer

3.3.3.1

Aufbau eines formatierten Reports

Grundgerüst eines Berichts im BEx Report Designer ist eine Struktur aus Zeilen und Spalten, vergleichbar mit der im BEx Web Application Designer zur Anordnung der bei Web Items eingesetzten, blinden Ta Tabelle. Die tabellarische Struktur im BEx Report Designer beschreibt mit jeder Zelle und deren Eigenschaften den Inhalt und das Format, wobei jede Zelle eigenständig oder im Verbund gesehen werden kann. Während statische Bereiche dieser Tabelle sich zur Laufzeit nicht verändern, wie beispielsweise eine Grafik oder ein individueller Text, so werden

140

Data Warehouse-Architektur

dynamische Bereiche eines Reports erst zur Laufzeit gebildet. Hierzu zählen dynamischer Text, Diagramme und Ergebnistabellen. Insbesondere die Ergebnistabelle bildet so viele Zeilen, wie der Data Provider liefert (vgl. SAP 2006). Anders als statische bieten dynamische Reportabschnitte verschiedene Zeilenarten wie Kopfzeilen, Detailzeilen und Fuß- oder Ergebniszeilen. Sie bilden gemeinsam eine Gruppe, wobei eine Gruppe je Merkmal gebildet wird. Sind mehrere Merkmale vorhanden, so werden sie ineinander verschachtelt. Eine Detailzeile wird in einem dynamischen Reportabschnitt erst dann erzeugt, wenn der Aufriss nur noch nach Kennzahlen möglich ist (vgl. SAP 2006).

3.3.4 BEx Analyzer Um eine möglichst breite Gruppe von Anwendern anzusprechen, überlässt die SAP in der BI-Suite dem Anwender die Wahl, ob er sich mit dem webbasierten Reporting beschränken möchte, oder das zumeist in Controller- und AnalystenKreisen beliebte Werkzeug Microsoft Excel ebenfalls nutzen will. Das Add-in BEx Analyzer steht den Web-Berichten in nichts nach und bietet nahezu den gleichen Komfort bei der Bedienung. Drag & Drop ist bei der Navigation ebenso verfügbar wie eine individuelle Anordnung der Ergebnistabelle und Funktionsschaltflächen. Im Gegensatz zur Darstellung im Web kann der Anwender jedoch zusätzlich die Daten einer SAP BW-Auswertung unmittelbar mit den Daten in anderen, nicht-BW Arbeitsblättern verknüpfen, wodurch die Flexibilität ungleich größer ist, als im Web. Auf dieser Weise können die Daten im SAP BW direkt und hochflexibel weiterverarbeitet werden, um sie in das Microsoft Office-Paket zu integrieren und beispielsweise Serienbriefe zu verfassen (vgl. SAP 2007b). Die Arbeit mit dem BEx Analyzer ist in zwei Bereiche gegliedert. Im DesignModus wird die Oberfläche des Berichts gestaltet und die Funktionalität der Arbeitsmappe gebildet. Im Analyse-Modus bezieht der Bericht über den Data Provider Daten vom SAP BW und wird vom Anwender produktiv genutzt (siehe Abb. 3.37).

SAP BW Reporting

141

Abb. 3.37 BEx Analyzer

3.3.4.1

Design-Modus

Der Design-Modus kann auch als Entwicklungssicht auf einen Bericht im BEx Analyzer bezeichnet werden. In diesem Arbeitsschritt werden alle Einstellungen vorgenommen, um eine BEx Query in eine formatierte, mit verschiedenen Funktionen versehene BEx Analyzer-Arbeitsmappe unter Microsoft Excel zu integrieren. Als Hilfsmittel steht dem Entwickler dabei eine BEx AnalyzerWerkzeugleiste zur Verfügung, mit deren Hilfe er auf verschiedene Funktionen zurückgreifen kann, die bei der Implementierung eines Berichts hilfreich sind (vgl. SAP 2007b). Ähnlich wie im BEx Web Application Designer kann der Entwickler einen Bericht beschleunigt erstellen, indem er auf insgesamt elf verschiedene Design Items zurückgreift (siehe Tabelle 3.12). Diese stellen vorkonfigurierte Objekte innerhalb einer Arbeitsmappe dar, welche zur Navigation im Datenbestand oder zur Darstellung der BEx Query Ergebnisse genutzt und durch ihre Eigenschaften beschrieben werden. Alle sind mit einer BEx Query oder einem BEx Query View, dem so genannten Data Provider, verbunden. Auf diese Weise ist sichergestellt, dass auch bei der Verwendung von mehreren Data Providern eine eindeutige Zuordnung zum Design Item besteht. Ein Design Item wird in eine Microsoft Excel-Zelle des Arbeitsblatts eingefügt und zur Laufzeit durch Visual Basic for Applications Programme (VBA) in ein interaktives Objekt verwandelt. Im Design-Modus hingegen

142

Data Warehouse-Architektur

repräsentiert ein Symbol die Objekte. Eine wesentliche Funktion ist der Formelmodus, mit dessen Hilfe jede Zelle des Ergebnisbereichs mit einer Berechnungsformel, ähnlich wie im BEx Query Designer, versehen werden kann. So kann auf jede einzelne Zelle individuell Bezug genommen und die Funktionalität erweitert werden. Die Einstellungen bleiben auch nach einer Aktualisierung der Daten erhalten, während manuell eingetragene, reine Microsoft Excel-Funktionen in einem Design Item nicht von Dauer sind, weil sie nach der Auffrischung der Daten durch den BEx Analyzer überschrieben werden (vgl. SAP 2006). Tabelle 3.12 Design Items (vgl. SAP 2006) Design Item

Beschreibung

Analysetabelle

Die Analysetabelle ist mit dem Ergebnisbereich einer BEx Query gleichzusetzen. Navigationsfunktionen werden dem Anwender über das Kontextmenü bereitgestellt oder können durch Drag & Drop ausgeführt werden. Das Diagramm stellt kein eigenes Design Item dar, weil es ein Microsoft Excel-Objekt ist. Dennoch kann eine Tabelle mit einem Diagramm verbunden werden, so dass dieses die Werte aus der Tabelle entnimmt.

Navigationsbereich

Der Navigationsbereich bietet Filter- und Navigationsfunktionen für einen Data Provider. Auf diese Weise lassen sich der Aufbau und das Ergebnis in der Analysetabelle beeinflussen.

Liste der Filter

Wenn nur eine Darstellung der im Data Provider verwendeten Filter gewünscht ist, kann dieses Design Item verwendet werden.

Button

Hinter Schaltflächen verbergen sich Funktionen, die komplexe Operationen auf dem Data Provider ausführen. Es können alle Befehle der Web-API-Referenz verwendet werden, außer dem Export nach Excel.

Dropdown-Box

Die Dropdown-Box ist hervorragend dazu geeignet, um gezielt einzelne Filterwerte zu selektieren.

Checkbox-Group

Durch eine Checkbox-Group können mehrere Filter zur Auswahl bereitgestellt und gesetzt werden.

Radio-Button-Group

Wie die Checkbox-Group lassen sich mit Radio-Buttons ebenfalls mehrere Filterwerte anzeigen, es kann jedoch nur ein Wert zur gleichen Zeit gewählt werden.

Liste der Bedingungen

Bedingungen lassen sich über dieses Design Item verwalten. Jedoch wirken diese nur auf das letzte im Aufriss befindliche Merkmal.

Liste der Exceptions

Um alle verwendeten Ausnahmeregeln aufzurufen, kann die Liste der Exceptions eingesetzt werden. Eine Exception wirkt nur auf die Zelle, die den Schwellwert trägt.

Text

Zu einer BEx Arbeitsmappe ist eine Vielzahl von Informationen, wie die Aktualität der Daten, verfügbar. Zudem können die verwendeten globalen Filter ausgegeben werden.

Nachrichten

Der BEx Analyzer kommuniziert mit dem Anwender durch Nachrichten und informiert diesen durch Warnungen oder Erfolgsmeldungen über den Zustand der ausgeführten Funktion.

Fallstudie A: SAP BI Data Warehousing

3.3.4.2

143

Analyse-Modus

Ist ein Bericht entwickelt worden, so kann er im Analysemodus aufgerufen werden. Nach dem Öffnen einer Arbeitsmappe füllt der BEx Analyzer die Design Items mit Steuerelementen oder Werten von einem oder mehreren Data Providern und bildet so die BEx Arbeitsmappe. Der Anwender kann nun im Datenbestand navigieren und die Funktionen der Design Items ausführen. Es ist im BEx Analyzer auch möglich, eine manuelle Planung durchzuführen, sofern die BEx Query hierfür entsprechend erstellt wurde (vgl. SAP 2007b).

3.4

Fallstudie A: SAP BI Data Warehousing

Dieser Abschnitt dient der praktischen Einführung in das SAP BI Data Warehousing anhand einer durchgängigen Fallstudie. Mit Hilfe eines frei erfundenen Beispielszenarios wird zunächst ein betriebswirtschaftlicher Hintergrund geschaffen, anhand dessen sowohl das Datenmodell, als auch die Struktur der SAP BIObjekte erläutert werden. Entscheidungen, die aus der betriebswirtschaftlichen Aufgabenstellung resultieren, können von Beginn an praktisch am SAP-System nachvollzogen und verstanden werden. Die Fallstudie unterteilt sich dabei in drei Teile, die dem typischen Ablauf im Data Warehousing entsprechen: Im ersten Schritt der Datenmodellierung wird zunächst ein Datenmodell angelegt, dessen erforderliche Objekte inklusive Ihrer Abhängigkeiten es zu modellieren gilt. Im zweiten Schritt werden diese SAP BI-Objekte im Zuge der Datenbeschaffung mit Stamm- und Bewegungsdaten gefüllt, um auf diesen Datenbeständen letztlich im Rahmen des Reporting Abfragen und Analysen durchführen zu können. Die erforderlichen Schritte zur erfolgreichen Durchführung der Fallstudie sind in präzisen Anweisungen formuliert, deren Aussagen durch eine Vielzahl an Screenshots unterstützt werden. Dadurch wird ein enger Bezug zur Benutzeroberfläche hergestellt, der es dem Anwender erleichtert, die einzelnen Schritte nachzuvollziehen. Die Namenskonvention für alle erstellten Objekte sieht für das Szenario der vorliegenden Fallstudie das Präfix UO für Universität Oldenburg und das Suffix ## als Platzhalter für die Gruppennummer der bearbeitenden Gruppe oder Einzelperson vor (Gruppennummern 00 bis 99). Es bedarf der Beachtung der Namenskonventionen des verwendeten Systems und der eventuellen Anpassung des Präfixes gemäß den zugrundeliegenden Richtlinien des Systembetreibers. Durch die Verwendung der Gruppennummern wird die parallele Bearbeitung der Fallstudien durch mehrere Gruppen bzw. Personen am selben System ermöglicht.

144

Data Warehouse-Architektur

Beispielszenario und Aufgabenstellung Die 4INSTANCE AG ist eine große deutsche Elektronik-Einzelhandelskette, die deutschlandweit über vier große Filialen in den Städten Berlin, Oldenburg, Stuttgart und Hamburg verfügt. Die Entscheidungsträger der 4INSTANCE AG haben sich dazu entschlossen, Änderungen in der Informatikstrategie vorzunehmen, da das aktuelle Berichtswesen im Unternehmen vermehrt Probleme und Risiken mit sich bringt. Um die Beweggründe dieser Entscheidung noch etwas detaillierter darzustellen, soll zunächst die aktuell noch vorherrschende Reporting-Situation innerhalb des Unternehmens aufgezeigt werden. Das Reporting wird bisher überwiegend durch Microsoft (MS) Excel realisiert, indem die Daten manuell über eigens zu diesem Zweck formulierte SQL-Abfragen aus der Datenbank des operativen Systems beschafft und über eine ExportFunktion in eine CSV-Datei geschrieben werden. Diese CSV-Dateien werden dann über verschiedene Formeln und Makros in MS Excel importiert und der Inhalt dort in Tabellen farblich unterlegt und um Diagramme ergänzt. Die Daten werden somit insgesamt in MS Excel organisiert und visuell aufbereitet, damit relevante Information dem Betrachter schnell ins Auge fallen. Anschließend werden die Ergebnisse über das Intranet oder per E-Mail an die Entscheidungsträger übermittelt oder fließen in MS Powerpoint-Präsentationen ein. Der gesamte Prozess von der Datenbeschaffung, über die Datenaufbereitung bis hin zur Informationsverteilung im Unternehmen wird von mehreren Mitarbeitern in den unterschiedlichen Fachabteilungen periodisch wiederholt. Vor allem zu Quartalsabschlüssen entsteht dadurch ein erhöhter Arbeitsaufwand, jedoch halten auch bereits zunehmend kleinere Arbeiten im Wochenrhythmus eine Vielzahl an Mitarbeitern von der Durchführung ihrer eigentlichen Aufgaben ab. Dieser Zustand des Berichtswesens bringt eine Reihe von Nachteilen mit sich. Durch eine ständig anwachsende Menge an zu verwaltenden Daten steigt auch die Komplexität und damit der zeitliche Aufwand zur Aufbereitung und Interpretation dieser Daten. Desweiteren bergen die vielen, manuell durchgeführten Arbeitsschritte ein hohes Fehlerpotential und letztlich existiert ein zeitlicher und datenbezogener Mangel an Flexibilität. Aufgrund dieser nicht mehr zu tolerierenden Restriktionen und Risiken der dargestellten MS Office-basierten Lösung fiel die Entscheidung des Managements, das Reporting zukünftig durch ein SAP BISystem umzusetzen. Die Entscheidungsträger versprechen sich durch die Einführung von SAP eine Stärkung ihrer Position am Markt und erhoffen sich Vorteile gegenüber ihren Wettbewerbern, da sie insgesamt schneller und flexibler auf Veränderungen der Marktsituation reagieren können. Um einen ersten Einstieg in das SAP BI Data Warehousing zu bekommen, sollen die Umsätze der einzelnen Filialen im ersten Halbjahr des Jahres 2008 als praktisches Anwendungsbeispiel durch das SAP BI Data Warehouse aufbereitet und analysiert werden. Da für die 4INSTANCE AG das Jahr 2007 bezogen auf den Umsatz eher ernüchternd war, startete das Unternehmen Anfang 2008 eine groß angelegte Werbekampagne, wodurch der Umsatz wieder angekurbelt werden

Fallstudie A: SAP BI Data Warehousing

145

soll. Seit März 2008 laufen eine erhöhte Anzahl von Anzeigen in den örtlichen Tageszeitungen, werden Radiospots in den betroffenen Städten ausgestrahlt und desweiteren besondere Preisaktionen in den Filialen durchgeführt, um den Kunden fester an das Unternehmen zu binden. Die Informationssystemabteilung ist vom Management beauftragt worden, einen Prototyp mit Hilfe des SAP BI Data Warehousing umzusetzen, um die ersten Ergebnisse dieser Werbekampagne analysieren zu können. Das Management möchte dadurch erste Erfahrungen und Eindrücke über die Potentiale des Systems sammeln und dem betreuenden Fachpersonal die Möglichkeit geben, sich mit dem System vertraut zu machen. Als Mitarbeiter der Informationssystemabteilung wurden Sie damit beauftragt, den Prototyp gemäß den Anforderungen der Entscheidungsträger aufzubauen. Das oberste Ziel bei der Erstellung des Prototyps ist es, das SAP BI Data Warehouse derart einzurichten, dass Analysen auf den Umsätzen der Monate Januar bis Juni 2008 (1. Halbjahr 2008) über alle vier Buchungskreise (Filialen) möglich sind. Die Analysen sollen durch BEx Queries auf InfoProvidern des SAP BI Data Warehouse aufsetzen und dabei sowohl im Webbrowser, als auch in MS Excel dargestellt werden können. Dazu soll insbesondere der BEx Web Application Designer zum Einsatz kommen, um diesen auf seine Möglichkeiten zu untersuchen.

3.4.1 Teil I - Datenmodellierung Der erste Schritt zur Erstellung des gewünschten Prototyps bedarf einer gründlichen Modellierung der zur Lösung der Aufgabe erforderlichen Objekte. Das SAPSystem stellt dazu die bereits in Kapitel 3.2.1 vorgestellte Data Warehousing Workbench (DWB) zur Verfügung, die es ermöglicht, ein Datenmodell anzulegen und die Einstellungen für die Datenbeschaffung vorzunehmen. In diesem ersten Teil der Fallstudie wird als erstes Objekt eine InfoArea angelegt, um spätere InfoObjekte wie Kennzahlen oder Merkmale sowie InfoProvider strukturiert ablegen zu können. Ist diese InfoArea definiert, werden InfoObjectCatalogs angelegt, die wiederum der strukturierten Ablage der InfoObjekte dienen. Ein InfoObjectCatalog enthält entweder InfoObjekte vom Typ Kennzahl oder InfoObjekte vom Typ Merkmal. Durch InfoObjekte vom Typ Merkmal ist es möglich, Kennzahlen einem Sachverhalt zuzuordnen. So können beispielsweise durch das Merkmal Buchungskreis Aussagen über die Kennzahlen je Buchungskreis formuliert werden. Außerdem kann in der InfoObjekt-Pflege von Merkmalen festgelegt werden, ob das jeweilige Merkmal über Stammdaten verfügt, die im System hinterlegt werden sollen. Stammdaten sind meist Texte zu Merkmalswerten, die der Verständniserleichterung dienen, da sie dem Sprachgebrauch näher kommen, als die häufig für Merkmalswerte verwendeten alphanumerischen Zeichenfolgen. Im vorliegenden Szenario beispielsweise, repräsentiert der Buchungskreis mit der Ziffer 1 die Stadt Berlin.

146

Data Warehouse-Architektur

InfoObjekte vom Typ Kennzahl hingegen, stellen quantifizierbare Größen dar, mit denen mathematische Operationen möglich sind. Auch ist die Verbindung von Kennzahlen zu Merkmalen möglich. So kann zum Beispiel durch die Verbindung der Kennzahl Umsatz mit dem Merkmal Betrag inkl. Währungsschlüssel, der Umsatz in verschiedene Währungen umgerechnet werden. Auf diese Art wird eine gewisse Flexibilität sichergestellt. Als InfoProvider werden alle direkt für das Reporting verwendbaren Objekte bezeichnet. Diese müssen neben den bisherigen Objekten ebenfalls im Zuge der Datenmodellierung angelegt werden. Im Rahmen dieser Fallstudie wird ein InfoCube verwendet, in dem die Bewegungsdaten letztlich physisch enthalten sind und somit über den InfoCube für das spätere Reporting zur Verfügung stehen. Ein InfoCube ermöglicht es, effiziente OLAP-Operationen zur Navigation im Datenbestand durchzuführen, wobei sich das Modell eines solchen Datenwürfels aus den zuvor definierten InfoObjekten zusammensetzt. Dabei werden Merkmale in Dimensionen angeordnet, während Kennzahlen in die Faktentabelle des InfoCube geschrieben werden. In dieser Fallstudie werden für die Dimensionen die Merkmale Buchungskreis und Produkt zusammen mit den Zeitmerkmalen aus dem SAP Business Content verwendet. Diese vordefinierten Merkmale, wie etwa das Kalenderjahr oder die Kalenderwoche, sind aufgrund ihrer häufigen Verwendung bereits im System modelliert und können für die Fallstudie für die zeitliche Dimension verwendet werden. Sobald InfoArea, InfoObjectCatalogs mit den dazugehörigen InfoObjekten und der InfoCube angelegt wurden, sind die erforderlichen Schritte für die Datenmodellierung dieses ersten Teils der Fallstudie abgeschlossen.

Fallstudie A: SAP BI Data Warehousing

3.4.1.1

147

Anlegen der InfoArea

Starten Sie die Anwendung SAPLogon und melden Sie sich mittels Benutzername und Kennwort am SAP BI-System an. Sie gelangen zunächst auf den Startbildschirm, von wo aus Sie Zugriff auf die verschiedenen Anwendungen haben.

Abb. 3.38 SAP Easy Access - Modellierung

Klicken Sie im linken SAP Menü im Unterpunkt Modellierung doppelt auf Data Warehousing Workbench: Modellierung, um zur DWB zu gelangen (siehe Abb. 3.38 SAP Easy Access - Modellierung, Schritt 1). Alternativ können Sie die DWB auch über die Eingabe des Transaktionscodes RSA1 in das obige Befehlsfeld erreichen, sofern Sie Ihre Eingabe mit Enter bestätigen (gestrichelte Markierung).

148

Data Warehouse-Architektur

Abb. 3.39 Anlegen der InfoArea

Wechseln Sie im linken Menübaum zu InfoObjects (siehe Abb. 3.39 Anlegen der InfoArea, Schritt 1). Öffnen Sie mit einem Rechtsklick auf die InfoArea zur Fallstudie (hier: Uni Oldenburg) (Schritt 2) das kontextsensitive Menü und wählen InfoArea anlegen… aus (Schritt 3). Im folgenden Dialog geben Sie unter InfoArea den technischen Namen UO_IA_## der neuen InfoArea ein (Schritt 4), wobei die Zeichenkette ## Ihre Gruppennummer repräsentiert (im Folgenden wird diese Schreibweise als bekannt vorausgesetzt, die Zeichenfolge ## ist demnach für die weitere Durchführung dieser Fallstudie stets wie zuvor beschrieben zu ersetzen). Verwenden Sie als Beschreibung lang Fallstudie BW ## (Schritt 5) und bestätigen Sie Ihre Eingaben durch Enter oder durch einen Klick auf die Schaltfläche Weiter am unteren Rand des Dialogs (Schritt 6). Sie haben die InfoArea UO_IA_## unter der InfoArea zur Fallstudie angelegt.

Fallstudie A: SAP BI Data Warehousing

3.4.1.2

149

Anlegen der InfoObjectCatalogs und InfoObjects

Nachdem Sie die InfoArea angelegt haben, folgen nun die InfoObjectCatalogs und die darin enthaltenen InfoObjects für Kennzahlen bzw. Merkmale. Anlegen der Kennzahlen

Abb. 3.40 InfoObjectCatalog Kennzahlen anlegen

Klicken Sie mit der rechten Maustaste auf Ihre im vorherigen Schritt angelegte InfoArea Fallstudie BW ## (siehe Abb. 3.40 InfoObjectCatalog Kennzahlen anlegen, Schritt 1) und wählen Sie im kontextsensitiven Menü den Punkt InfoObjectCatalog anlegen (Schritt 2). Im sich daraufhin öffnenden Dialog geben Sie unter InfoObjCat den technischen Namen UO_IOCK_## (Schritt 3) und im Textfeld rechts daneben die Beschreibung Kennzahlen Fallstudie BW ## ein (Schritt 4). Stellen Sie desweiteren sicher, dass im Gruppierungsfeld InfoObjectTyp die Selektion Kennzahl getroffen ist (Schritt 5). Zum Abschluss klicken Sie auf die Schaltfläche Anlegen (Schritt 6).

150

Data Warehouse-Architektur

Abb. 3.41 InfoObjectCatalog Kennzahlen aktivieren

Als nächstes muss der soeben angelegte InfoObjectCatalog, wie alle neu angelegten Objekte im System, geprüft, gesichert und aktiviert werden. Rückmeldung über das Ergebnis des jeweiligen Schritts erhalten Sie über Meldungstexte (siehe Abb. 3.41 InfoObjectCatalog Kennzahlen aktivieren, gestrichelte Markierung). Klicken Sie innerhalb der Anwendungsleiste zuerst auf die Schaltfläche Prüfen (Schritt 1). Nach erfolgreicher Prüfung betätigen Sie die Schaltfläche Sichern (Schritt 2) und im Anschluss die Schaltfläche Aktivieren (Schritt 3). Der Vorgang der Aktivierung kann dabei eine gewisse Zeit in Anspruch nehmen. Wurden alle drei Schritte erfolgreich durchgeführt, steht das Objekt – in diesem Fall der InfoObjectCatalog für Kennzahlen – zur weiteren Verwendung im System zur Verfügung.

Fallstudie A: SAP BI Data Warehousing

151

Abb. 3.42 Kennzahl Umsatz anlegen I

Der InfoObjectCatalog Kennzahlen Fallstudie BW ## erscheint nun als Unterpunkt der InfoArea Fallstudie BW ## in der Liste aller InfoObjekte. Durch einen Rechtsklick auf Kennzahlen Fallstudie BW ## (siehe Abb. 3.42 Kennzahl Umsatz anlegen I, Schritt 1) öffnen Sie das kontextsensitive Menü des InfoObjectCatalog und wählen InfoObject anlegen… (Schritt 2). Vergeben Sie im Dialog Kennzahl anlegen unter Kennzahl den technischen Namen UO_KU_## und verwenden als Beschreibung lang Umsatz ## (Schritt 3), die Felder Referenzkennzahl und Template bleiben leer. Sobald Sie die Eingaben getätigt haben, klicken Sie auf die Schaltfläche Weiter (Schritt 4) oder bestätigen Ihre Eingaben mit Enter.

152

Data Warehouse-Architektur

Abb. 3.43 Kennzahl Umsatz anlegen II

Die Eigenschaften der neuen Kennzahl Umsatz werden in der Eingabemaske Kennzahl UO_KU_## anlegen: Details gepflegt. Tragen Sie hier als Beschreibung kurz Umsatz ein (siehe Abb. 3.43 Kennzahl Umsatz anlegen II, Schritt 1). Stellen Sie desweiteren sicher, dass als Typ/Datentyp Betrag ausgewählt (Schritt 2) und der Datentyp CURR - Währungsfeld, abgelegt als DEC gesetzt ist (Schritt 3). Im Gruppierungsfeld Währung/Mengeneinheit klicken Sie auf das kleine Symbol zur Wertehilfe (Schritt 4) und wählen durch einen Doppelklick das InfoObjekt 0CURRENCY aus der Liste des sich öffnenden Dialogs als Einheit/Währung aus (Schritt 5). Prüfen (Schritt 6), Sichern (Schritt 7) und Aktivieren (Schritt 8) Sie die Kennzahl und klicken auf Zurück (Schritt 9) um wieder zurück zur DWB zu gelangen.

Fallstudie A: SAP BI Data Warehousing

153

Abb. 3.44 Kennzahl Preis anlegen I

Neben der Kennzahl Umsatz soll außerdem die Kennzahl Preis im System hinterlegt werden. Klicken Sie dazu analog der vorherigen Beschreibung zum Anlegen der Kennzahl Umsatz erneut mit einem Rechtsklick auf den InfoObjectCatalog für Kennzahlen Kennzahlen Fallstudie BW ## und wählen ein weiteres Mal InfoObject anlegen… (siehe Abb. 3.44 Kennzahl Preis anlegen I, Schritt 1). Verwenden Sie UO_KP_## als technischen Namen und wählen in diesem Fall Preis ## als Beschreibung lang (Schritt 2), bevor Sie Ihre Eingaben mit Enter bestätigen (Schritt 3).

154

Data Warehouse-Architektur

Abb. 3.45 Kennzahl Preis anlegen II

Im nächsten Dialog tragen Sie Preis als Beschreibung kurz ein (siehe Abb. 3.45 Kennzahl Preis anlegen II, Schritt 1) und wählen als Typ/Datentyp Betrag (Schritt 2), sofern diese Eigenschaft nicht bereits ausgewählt ist. Der Datentyp lautet ebenfalls CURR - Währungsfeld, abgelegt als DEC (Schritt 3) und die Einheit/Währung ist analog zur Kennzahl Umsatz ebenfalls 0CURRENCY. Anstatt über die Wertehilfe können Sie den technischen Namen des Währungsschlüssels auch direkt in das dafür vorgesehene Feld eingeben (Schritt 4). Prüfen, Sichern und Aktivieren Sie die Kennzahl (Schritte 5 bis 7) und verlassen den Dialog über Zurück (Schritt 8). Zur Übersicht sind in Tabelle 3.13 alle Eigenschaften der soeben angelegten Kennzahlen zusammenfassend aufgelistet. Tabelle 3.13 Kennzahlen Details Feld

Umsatz

Preis

Kennzahl

UO_KU_##

UO_KP_##

Beschreibung lang Umsatz ##

Preis ##

Beschreibung kurz Umsatz

Preis

Typ/Datentyp

Betrag

Betrag

Datentyp

CURR - Währungsfeld, abgelegt als DEC

CURR - Währungsfeld, abgelegt als DEC

Einheit/Währung

0CURRENCY

0CURRENCY

Fallstudie A: SAP BI Data Warehousing

155

Anlegen der Merkmale

Abb. 3.46 InfoObjectCatalog Merkmale anlegen

Nachdem die Kennzahlen Umsatz und Preis nun vollständig angelegt wurden, müssen als nächstes die Merkmale im System hinterlegt werden. Legen Sie dazu zunächst einen weiteren InfoObjectCatalog für Merkmale mit dem technischen Namen UO_IOCM_## in Ihrer InfoArea Fallstudie BW ## an (siehe Abb. 3.46 InfoObjectCatalog Merkmale anlegen, Schritt 1) und verwenden die Beschreibung Merkmale Fallstudie BW ## (Schritt 2). Als InfoObjectTyp selektieren Sie nun Merkmal (Schritt 3) und klicken anschließend auf Anlegen (Schritt 4), um den Vorgang abzuschließen.

156

Data Warehouse-Architektur

Abb. 3.47 InfoObjectCatalog Merkmale aktivieren

Wie zuvor beim InfoObjectCatalog für Kennzahlen, muss der soeben angelegte InfoObjectCatalog für Merkmale ebenfalls geprüft, gesichert und aktiviert werden. Klicken Sie dazu nacheinander auf die Schaltflächen Prüfen, Sichern und Aktivieren innerhalb der Anwendungsleiste (siehe Abb. 3.47 InfoObjectCatalog Merkmale aktivieren, Schritte 1 bis 3) und überprüfen Sie den Erfolg der einzelnen Schritte anhand der Meldungstexte. Klicken Sie abschließend auf Zurück (Schritt 4).

Fallstudie A: SAP BI Data Warehousing

157

Abb. 3.48 Merkmal Buchungskreis anlegen I

Öffnen Sie mit einem Rechtsklick auf den InfoObjectCatalog Merkmale Fallstudie BW ## das kontextsensitive Menü und klicken Sie auf die Schaltfläche InfoObject anlegen… (siehe Abb. 3.48 Merkmal Buchungskreis anlegen I, Schritt 1). Im anschließenden Dialog Merkmal anlegen werden Sie aufgefordert, den technischen Namen und eine Beschreibung festzulegen. Tragen Sie hier unter Merkmal UO_MBK_## und unter Beschreibung lang Buchungskreis ## ein (Schritt 2). Die Felder Referenzmerkmal und Vorlage bleiben leer. Schließen Sie den Dialog mit Enter oder durch einen Klick auf Weiter ab (Schritt 3).

158

Data Warehouse-Architektur

Abb. 3.49 Merkmal Buchungskreis anlegen II

Geben Sie als Beschreibung kurz den Text Buchungskreis ein (siehe Abb. 3.49 Merkmal Buchungskreis anlegen II, Schritt 1). In der Registerkarte Allgemein besetzen Sie für das mit einem Häkchen gekennzeichnete Mussfeld Datentyp mit dem Eintrag CHAR - Zeichenfolge (Schritt 2), geben als Länge den Wert 4 ein (Schritt 3) und setzen ein Häkchen vor die Option Merkmal ist Dokumenteigenschaft (Schritt 4). Wechseln Sie in die Registerkarte Stammdaten/Texte (Schritt 5).

Fallstudie A: SAP BI Data Warehousing

159

Abb. 3.50 Merkmal Buchungskreis anlegen III

Markieren Sie hier die Ankreuzfelder vor der Option Mit Stammdaten (siehe Abb. 3.50 Merkmal Buchungskreis anlegen III, Schritt 1), sowie vor der Option Mit Texten (Schritt 2), sofern diese nicht bereits ausgewählt sind und vermerken mit UO_IA_## unter InfoArea den technischen Namen Ihrer InfoArea (Schritt 3). Sie können nun Ihre Eingaben vom System prüfen lassen, indem Sie die Schaltfläche Prüfen betätigen (Schritt 4). Nachdem in der Statuszeile die Meldung „Merkmale o.k.“ erscheint, Sichern (Schritt 5) und Aktivieren Sie das Merkmal (Schritt 6). Kehren Sie abschließend über die Schaltfläche Zurück zur DWB zurück (Schritt 7).

160

Data Warehouse-Architektur

Abb. 3.51 Merkmal Produkt anlegen I

Neben dem soeben angelegten Merkmal Buchungskreis bedarf es noch dem Anlegen eines weiteren Merkmals innerhalb der Datenmodellierung – dem Merkmal Produkt. Verfahren Sie dazu analog zum vorherigen Abschnitt und klicken auf InfoObject anlegen… im Kontextmenü des InfoObjectCatalog für Merkmale (siehe Abb. 3.51 Merkmal Produkt anlegen I, Schritt 1), verwenden jedoch den technischen Namen UO_MP_## und die Beschreibung lang Produkt ## (Schritt 2). Bestätigen Sie Ihre Eingaben erneut mit Enter (Schritt 3).

Fallstudie A: SAP BI Data Warehousing

161

Abb. 3.52 Merkmal Produkt anlegen II

Im darauffolgenden Dialog Merkmal UO_MP_## anlegen: Details vergeben Sie als Beschreibung kurz Produkt (siehe Abb. 3.52 Merkmal Produkt anlegen II, Schritt 1) und wählen in der ersten Registerkarte Allgemein als Datentyp den Eintrag CHAR - Zeichenfolge (Schritt 2) mit einer Länge von 10 (Schritt 3). Wechseln Sie in die Registerkarte Stammdaten/Texte (Schritt 4).

162

Data Warehouse-Architektur

Abb. 3.53 Merkmal Produkt anlegen III

In der Registerkarte Stammdaten/Texte stellen Sie sicher, dass die Optionen Mit Stammdaten und Mit Texten ausgewählt sind und geben analog zum Merkmal Buchungskreis ebenfalls den Namen der InfoArea UO_IA_## in dem dafür vorgesehenen Feld an (siehe Abb. 3.53 Merkmal Produkt anlegen III, Schritt 1). Desweiteren selektieren Sie die Texttabellen-Eigenschaft Mittellanger Text existiert und entfernen das Kreuz aus dem Ankreuzfeld der Option Kurztext existiert (Schritt 2). Wechseln Sie in die Registerkarte Attribute (Schritt 3).

Fallstudie A: SAP BI Data Warehousing

163

Abb. 3.54 Merkmal Produkt anlegen IV

In der Registerkarte Attribute geben Sie die InfoObjekte 0CURRENCY und UO_KP_## jeweils in eine Zeile der Spalte Attribut ein (siehe Abb. 3.54 Merkmal Produkt anlegen IV, Schritt 1) und bestätigen Ihre Eingaben mit Enter. Zum Abschluss Prüfen, Sichern und Aktivieren Sie auch dieses Merkmal (Schritte 2 bis 4) und verlassen den Dialog wie gewohnt über Zurück (Schritt 5). Analog zu den Details der angelegten Kennzahlen ist in Tabelle 3.14 eine Übersicht der soeben angelegten Merkmale im System dargestellt. Tabelle 3.14 Merkmale Details Feld

Buchungskreis

Produkt

Merkmal

UO_MBK_##

UO_MP_##

Beschreibung lang

Buchungskreis ##

Produkt ##

Beschreibung kurz

Buchungskreis

Produkt

Datentyp

CHAR - Zeichenfolge CHAR - Zeichenfolge

Länge

4

10

Merkmal ist Dokumenteigenschaft X

-

Mit Stammdaten

X

X

Mit Texten

X

X

Kurztext existiert

X

-

164

Data Warehouse-Architektur

Mittellanger Text existiert

-

X

InfoArea

UO_IA_##

UO_IA_##

Attribute

-

0CURRENCY UO_KP_##

3.4.1.3

Anlegen des InfoCube

Abb. 3.55 InfoCube Produkt-Umsatz anlegen

Wechseln Sie im linken Menübaum zum Eintrag InfoProvider (siehe Abb. 3.55 InfoCube Produkt-Umsatz anlegen, Schritt 1). Die soeben angelegte InfoArea Fallstudie BW ## ist auch hier sichtbar. Sollte dies nicht der Fall sein, aktualisieren Sie die Ansicht über die Schaltfläche Teilbaum auffrischen (Schritt 2). Klicken Sie mit rechts auf Ihre InfoArea Fallstudie BW ## (Schritt 3), um zu dem Menüpunkt InfoCube anlegen zu gelangen (Schritt 4). Im sich öffnenden Dialog InfoCube bearbeiten vergeben Sie im Gruppierungsfeld InfoCube bearbeiten unter InfoCube den technischen Namen UO_ICI_## und tippen in das nebenstehende Feld die Beschreibung Produkt-Umsatz Ist Fallstudie BW ## ein (Schritt 5). Desweiten stellen Sie sicher, dass im Gruppierungsfeld InfoProviderTyp lediglich Standard-InfoCube selektiert ist (Schritt 6) und schließen Ihre Eingaben durch einen Klick auf die Schaltfläche Anlegen ab (Schritt 7).

Fallstudie A: SAP BI Data Warehousing

165

Abb. 3.56 Dimensionen anlegen

Zum Übertragen der in den vorherigen Schritten angelegten Merkmale und Kennzahlen in den angelegten InfoCube Produkt-Umsatz Ist Fallstudie BW ## klicken Sie nun mit einem Rechtsklick auf Dimensionen und im sich öffnenden kontextsensitiven Menü auf den Eintrag Neue Dimensionen anlegen (siehe Abb. 3.56 Dimensionen anlegen, Schritt 1). Vergeben Sie die Beschreibung Produkt für die erste Dimension (Schritt 2) und klicken anschließend auf die Schaltfläche Weitere Dimension anlegen (Schritt 3), um eine zweite Dimension mit der Beschreibung Buchungskreis anzulegen. Schließen den Vorgang über Weiter ab (Schritt 4).

166

Data Warehouse-Architektur

Abb. 3.57 InfoCube Produkt-Umsatz bearbeiten I

In der Werkzeugleiste des linken Arbeitsbereichs klicken Sie auf die Schaltfläche InfoObjectsCatalog (siehe Abb. 3.57 InfoCube Produkt-Umsatz bearbeiten I, Schritt 1) und wählen im sich öffnenden Dialog durch einen Doppelklick mit der linken Maustaste den InfoObjectCatalog der Merkmale UO_IOCM_## aus (Schritt 2).

Fallstudie A: SAP BI Data Warehousing

167

Abb. 3.58 InfoCube Produkt-Umsatz bearbeiten II

Durch einen Klick auf den Pfeil vor dem Eintrag Merkmale öffnet sich die Baumstruktur und Sie bekommen alle im vorherigen Abschnitt angelegten Merkmale angezeigt (siehe Abb. 3.58 InfoCube Produkt-Umsatz bearbeiten II, Schritt 1). Ziehen Sie per Drag & Drop das Merkmal Produkt ## in die soeben angelegte Dimension Produkt (Schritt 2) und das Merkmal Buchungskreis ## in die Dimension Buchungskreis (Schritt 3).

168

Data Warehouse-Architektur

Abb. 3.59 InfoCube Produkt-Umsatz bearbeiten III

Im nächsten Schritt klicken Sie mit einem Rechtsklick auf die Dimension Zeit, um auf den Menüeintrag Direkteingabe InfoObjects zu gelangen (siehe Abb. 3.59 InfoCube Produkt-Umsatz bearbeiten III, Schritte 1 und 2). Dort tippen Sie im sich öffnenden Dialog InfoObjects einfügen in der Spalte InfoObject zeilenweise die technischen Namen der Merkmale 0CALMONTH und 0CALYEAR ein (Schritt 3) und bestätigen die Eingaben mit Weiter (Schritt 4).

Fallstudie A: SAP BI Data Warehousing

169

Abb. 3.60 InfoCube Produkt-Umsatz bearbeiten IV

Verfahren Sie beim Übertragen der Kennzahl Umsatz gleichermaßen, indem Sie erneut über die Direkteingabe InfoObjects der Kennzahlen des InfoCube (siehe Abb. 3.60 InfoCube Produkt-Umsatz bearbeiten IV, Schritte 1 und 2) den technischen Namen UO_KU_## in der Spalte InfoObject eingeben (Schritt 3) und mit Weiter bestätigen (Schritt 4).

170

Data Warehouse-Architektur

Abb. 3.61 InfoCube Produkt-Umsatz bearbeiten V

Zum Schluss können Sie die Dimension 1 über einen Rechtsklick und den Menüeintrag Löschen entfernen (siehe Abb. 3.61 InfoCube Produkt-Umsatz bearbeiten V, Schritte 1 und 2). Prüfen, Sichern und Aktivieren Sie den vollständigen InfoCube (Schritte 3 bis 5) und verlassen Sie den Dialog durch einen Klick auf Zurück (Schritt 6).

Fallstudie A: SAP BI Data Warehousing

171

Abb. 3.62 Objektübersicht InfoCube Produkt-Umsatz

Wurden alle Objekte im System korrekt hinterlegt, so liefert die Objektübersicht, die Sie über einen Rechtsklick auf den InfoCube Produkt-Umsatz Ist Fallstudie BW ## (siehe Abb. 3.62 Objektübersicht InfoCube Produkt-Umsatz, Schritt 1) und einen nachfolgenden Klick auf den Menüeintrag Objektübersicht erreichen (Schritt 2), die in der Abbildung dargestellte Struktur. Überprüfen Sie Ihre Eingaben und verlassen Sie den Dialog zum Abschluss dieses ersten Teils der Fallstudie über Beenden (Schritt 3). 3.4.1.4

Zusammenfassung

Dieser erste Teil der Fallstudie hat Ihnen einen Einblick in den Umgang mit InfoObjekten und InfoCubes im Rahmen der Datenmodellierung im SAP BI Data Warehousing vermittelt. Sie haben zur Strukturierung der Objekte zunächst die InfoArea Fallstudie BW ## und die InfoObjekte für Kennzahlen und Merkmale angelegt. Desweiteren sind Sie mit der Erstellung von Kennzahlen und Merkmalen vertraut gemacht worden. Sie haben die Kennzahlen Umsatz ## und Preis ## sowie die Merkmale Buchungskreis ## und Produkt ## in den jeweiligen InfoObjectCatalogs angelegt. Nach diesen Arbeitsschritten kam es zur Modellierung des InfoCube Produkt-Umsatz Ist Fallstudie BW ##, den Sie mit den zuvor angelegten InfoObjekten gefüllt haben. Dabei wurden die Dimensionen Buchungskreis und

172

Data Warehouse-Architektur

Produkt erstellt und diese mit den gleichnamigen Merkmalen Buchungskreis ## und Produkt ## versehen, sowie die Zeitdimension mit den gängigsten Zeitmerkmalen aus dem SAP Business Content belegt. Abschließend haben Sie dem InfoCube die Kennzahl Umsatz ## zugewiesen.

3.4.2 Teil II - Datenbeschaffung Im zweiten Teil dieser Fallstudie sollen die im Zuge der Datenmodellierung erstellen SAP BI-Objekte nun mit Stamm- und Bewegungsdaten befüllt werden. Dazu wird zunächst eine Anwendungskomponente angelegt, die eine strukturierte Ablage der dazu benötigten Objekte erlaubt. Da im Rahmen dieser Fallstudie Stammdatenattribute, -texte und Bewegungsdaten eingelesen werden sollen, werden in dieser Anwendungskomponente drei DataSources anlegt. Eine DataSource wird im Zusammenhang mit dem SAP BI Data Warehousing immer genau einem Quellsystem zugewiesen und liefert die Metadatenbeschreibung der zugrundeliegenden Quelldaten. Das SAP BI Data Warehousing bietet neben der Möglichkeit lokale, flache Dateien als Quellsystem zu verwenden, auch die Optionen SAP Systeme, relationale Datenbanken, XML-Datenströme über SOAP oder Fremdsysteme über BAPI anzubinden. In dieser Fallstudie soll aus Gründen der Übersichtlichkeit allerdings auf lokale, flache Dateien im CSV-Format zurückgegriffen werden, da diese leicht mit Texteditoren oder MS Excel bearbeitet werden können und in diesem Zusammenhang als Repräsentation eines komplexeren Quellsystems genügen. Bei periodischen oder sehr datenintensiven Übertragungen wird jedoch dringend empfohlen, andere Schnittstellen zu verwenden. Sobald die DataSources anlegt sind, können im nächsten Schritt die Transformationen aus den DataSources in die InfoObjekte (für Stammdatenattribute und -texte) bzw. in den InfoCube (für Bewegungsdaten) definiert werden. Durch Transformationen werden Übertragungs- und Fortschreibungsregeln mit Hilfe einer grafischen Benutzeroberfläche im SAP BI Data Warehousing erstellt. Im Rahmen dieser Fallstudie kommen dabei ausschließlich direkte Übertragungen zum Einsatz, wodurch die Datenquelle durch eine einzige Transformation (Einschrittverfahren) in das Format des Ziels überführt wird. Komplexe Transformationen, die den Einsatz von InfoSources verlangen, werden in dieser Fallstudie nicht behandelt. Neben dem Auslesen von Stammdaten aus unterschiedlichen Typen von Quellsystemen ist es weiterhin möglich, Stammdaten direkt im System zu pflegen. Diese manuelle Stammdatenpflege kommt immer dann zum Einsatz, sofern nur eine kleine Menge an Stammdaten zu einem Merkmal gepflegt werden muss und das Auslesen aus einem Quellsystem für einen solchen Fall zu zeitaufwändig ist, bzw. die Daten überhaupt nicht in Quellsystemen vorliegen. Die für den tatsächlichen Ladevorgang benötigten Informationen sind in InfoPackages zusammengefasst, welche nach den Transformationen und der manuelle

Fallstudie A: SAP BI Data Warehousing

173

Stammdatenpflege erstellt werden sollen. InfoPackages ermöglichen es, die Daten in die Persistant Staging Area (PSA) zu laden, von wo aus sie über Datentransferprozesse weiterverteilt werden können. Durch die Verwendung von InfoPackages können Fehler in den Daten oder in den getroffenen Einstellungen frühzeitig erkannt werden. Sind die InfoPackages angelegt und eingeplant können letztlich die Datentransferprozesse definiert werden, welche die Fortschreibung der Stammdatenattribute, der Stammdatentexte und der Bewegungsdaten in die tatsächlichen Datenziele bewerkstelligen. Anhand eines Monitors können beim Durchführen dieser Fallstudie eine Reihe der Schritte innerhalb der Datenbeschaffung überprüft werden. Zum Abschluss dieses zweiten Teils der Fallstudie soll ein abschließender Blick in den InfoCube vorgenommen werden, damit sichergestellt ist, dass die Daten korrekt im InfoCube vorliegen und die Fallstudie erfolgreich weitergeführt werden kann.

174

Data Warehouse-Architektur

3.4.2.1

Anlegen der Anwendungskomponente

Abb. 3.63 Anwendungskomponente anlegen

Wechseln Sie im linken Navigationsbereich der DWB in den Menüpunkt DataSources (siehe Abb. 3.63 Anwendungskomponente anlegen, Schritt 1). Öffnen Sie durch einen Rechtsklick auf die Ihnen zugewiesene Anwendungskomponente das kontextsensitive Menü (Schritt 2) und wählen Sie den Menüpunkt Anwendungskomponente anlegen… aus (Schritt 3). Im sich öffnenden Dialog Anwendungskomponente anlegen vergeben Sie unter Anwendungskomp. den technischen Namen UO_AK_## und die Beschreibung lang Fallstudie BW ## (Schritt 4). Beenden Sie diesen Vorgang über die Schaltfläche Weiter (Schritt 5).

Fallstudie A: SAP BI Data Warehousing

3.4.2.2

175

Anlegen der DataSources

In den folgenden drei Unterabschnitten werden die DataSources für die Stammdatenattribute, die Stammdatentexte sowie für die Bewegungsdaten angelegt. Anlegen der DataSource für Stammdatenattribute

Abb. 3.64 DataSource Stammdatenattribute anlegen

Die soeben angelegte Anwendungskomponente Fallstudie BW ## sollte nun im Baum der DataSources an gewünschter Stelle erscheinen. Ist dies nicht der Fall aktualisieren Sie die Ansicht über die Schaltfläche Teilbaum auffrischen (siehe Abb. 3.64 DataSource Stammdatenattribute anlegen, Schritt 1). Wählen Sie im nächsten Schritt nach einem Rechtsklick auf die neue Anwendungskomponente den Menüpunkt DataSource anlegen… (Schritte 2 und 3). Im Dialog DataSource anlegen vergeben Sie unter DataSource den technischen Namen UO_DS_PATTR_##, geben unter Quellsystem PCFILE001 und als Datentyp DataSource zunächst Stammdatenattribute an (Schritt 4). Beenden Sie den Dialog mit einem Klick auf Übernehmen (Schritt 5).

176

Data Warehouse-Architektur

Abb. 3.65 DataSource Stammdatenattribute ändern I

Im nachfolgenden Dialog DataSource UO_DS_PATTR_##(PCFILE001) ändern geben Sie in der geöffneten Registerkarte Allgemeines in die Textfelder Beschreibung kurz, mittel und lang jeweils Produkt-Attribute ein (siehe Abb. 3.65 DataSource Stammdatenattribute ändern I, Schritt 1). Wechseln Sie als nächstes in die Registerkarte Extraktion (Schritt 2).

Fallstudie A: SAP BI Data Warehousing

177

Abb. 3.66 DataSource Stammdatenattribute ändern II

Wählen Sie unter Dateiname das Flat File fallstudie_a-stammdatenattr.csv aus (siehe Abb. 3.66 DataSource Stammdatenattribute ändern II, Schritt 1), setzen den Wert der zu ignorierenden Kopfzeilen unter zu ignor. Kopfzeilen auf 1 (Schritt 2) und wählen als Datenformat durch Separator getrennt (z.B. CSV) (Schritt 3). Außerdem setzen Sie das Zahlenformat auf Direkte Eingabe (Schritt 4) und tippen einen Punkt (.) als Tausender-Trennzeichen und ein Komma (,) als Dezimalpunkttrennzeichen (Schritt 5). Begeben Sie sich in die nächste Registerkarte Vorschlag (Schritt 6).

178

Data Warehouse-Architektur

Abb. 3.67 DataSource Stammdatenattribute ändern III

In der Registerkarte Vorschlag klicken Sie auf die Schaltfläche Beispieldaten laden (siehe Abb. 3.67 DataSource Stammdatenattribute ändern III, Schritt 1), um einen Feldvorschlag für die DataSource zu erzeugen. Ändern Sie dann den Datentyp des Feldes Preis von DEC zu CURR (Schritt 2), betätigen Enter und geben weiterhin in der Spalte Einh als Einheit den Namen des Feldes Waehrung, also WAEHRUNG an (Schritt 3). Klicken Sie auf die Registerkarte Vorschau (Schritt 4).

Fallstudie A: SAP BI Data Warehousing

179

Abb. 3.68 Vorschau DataSource Stammdatenattribute

In der letzten Registerkarte Vorschau können Sie schließlich einen Einblick in die in der Datei enthaltenen Stammdatenattribute bekommen. Überprüfen Sie, ob die Struktur der Daten korrekt ist, indem Sie auf die Schaltfläche Vorschaudaten lesen klicken (siehe Abb. 3.68 Vorschau DataSource Stammdatenattribute, Schritt 1). Der Meldung zur vorherigen Aktivierung der DataSource, müssen Sie dazu über Aktivieren zustimmen. Wenn Sie die Daten ausreichend studiert haben, schließen Sie das Fenster mit Zurück (Schritt 2).

180

Data Warehouse-Architektur

Anlegen der DataSource für Stammdatentexte

Abb. 3.69 DataSource Stammdatentexte anlegen

Da das Verfahren zum Anlegen der DataSource für Stammdatentexte zum Verfahren des Anlegens der DataSource für Stammdatenattribute formal identisch ist, beschränkt sich die folgende Beschreibung nur auf die inhaltlichen Unterschiede zur Erstellung der DataSource für Stammdatentexte. Vergeben Sie für die neue DataSource den technischen Namen UO_DS_PTEXTE_##, wählen als Quellsystem ebenfalls PCFILE001 und selektieren als Datentyp DataSource für diesen Fall Stammdatentext (siehe Abb. 3.69 DataSource Stammdatentexte anlegen, Schritte 1 bis 4).

Fallstudie A: SAP BI Data Warehousing

181

Abb. 3.70 DataSource Stammdatentexte ändern I

In der Registerkarte Allgemeines vergeben Sie für Beschreibung kurz, mittel und lang den Text Produkt-Texte (siehe Abb. 3.70 DataSource Stammdatentexte ändern I, Markierung).

182

Data Warehouse-Architektur

Abb. 3.71 DataSource Stammdatentexte ändern II

Wählen Sie in der nächsten Registerkarte Extraktion diesmal die Datei fallstudie_a-stammdatentexte.csv aus, setzen die zu ignorierenden Kopfzeilen auf 1, wählen als Datenformat erneut durch Separator getrennt (z.B. CSV) und als Zahlenformat nun Benutzerstammsatz (siehe Abb. 3.71 DataSource Stammdatentexte ändern II, Schritte 1 bis 4).

Fallstudie A: SAP BI Data Warehousing

183

Abb. 3.72 DataSource Stammdatentexte ändern III

Nach dem Laden der Beispieldaten innerhalb der Registerkarte Vorschlag, wechseln Sie in die Registerkarte Felder und ändern dort den Datentyp des Feldes Sprache von CHAR zu LANG (siehe Abb. 3.72 DataSource Stammdatentexte ändern III, Schritt 1) und wählen in der Spalte Feldart für das Feld Sprache den Eintrag Sprachfeld aus (Schritt 2).

184

Data Warehouse-Architektur

Abb. 3.73 Vorschau DataSource Stammdatentexte

Abschließend Prüfen, Sichern und Aktivieren Sie auch diese DataSource und werfen in der Registerkarte Vorschau noch einen prüfenden Blick auf die Vorschaudaten. Sofern Ihre Vorschau mit der in der Abbildung 3.73 übereinstimmt, verlassen Sie den Dialog über Beenden. Zum Zwecke der besseren Übersicht sind in der nachfolgenden Tabelle 3.15 die wichtigsten Eigenschaften der beiden DataSources für Stammdatenattribute bzw. -texte zusammenfassend aufgelistet. Tabelle 3.15 Übersicht der Eigenschaften der DataSources für Stammdatenattribute bzw. -texte DataSource

UO_DS_PATTR_##

UO_DS_PTEXTE_##

Quellsystem

PCFILE001

PCFILE001

Datentyp DataSource

Stammdatenattribute

Stammdatentext

Registerkarte Allgemeines Beschreibung kurz/mittel/lang Produkt-Attribute ##

Produkt-Texte ##

Registerkarte Extraktion Dateiname

fallstudie_astammdatenattr.csv

fallstudie_astammdatentexte.csv

zu ignor. Kopfzeilen

1

1

Datenformat

durch Separator getrennt (z.B. CSV)

durch Separator getrennt (z.B. CSV)

Fallstudie A: SAP BI Data Warehousing

Datenseparator

;

;

Escape-Zeichen

„

„

Zahlenformat

Direkte Eingabe

Benutzerstammsatz

Tausender-Trennzeichen

.

nicht vorhanden

Dezimalpunkttrennzeichen

,

nicht vorhanden

185

Anlegen der DataSource für Bewegungsdaten

Abb. 3.74 DataSource Bewegungsdaten anlegen

Die dritte und letzte DataSource erhält den technischen Namen UO_DS_PUMSATZ_##. Sie basiert ebenfalls auf dem Quellsystem PCFILE001 und unterscheidet sich durch den Datentyp DataSource Bewegungsdaten von den beiden zuvor angelegten DataSources (siehe Abb. 3.74 DataSource Bewegungsdaten anlegen, Schritte 1 bis 4).

186

Data Warehouse-Architektur

Abb. 3.75 DataSource Bewegungsdaten ändern I

Vergeben Sie für Beschreibung kurz, mittel und lang den Text Produkt-Umsatz (siehe Abb. 3.75 DataSource Bewegungsdaten ändern I, Markierung).

Fallstudie A: SAP BI Data Warehousing

187

Abb. 3.76 DataSource Bewegungsdaten ändern II

In der Registerkarte Extraktion wählen Sie die Datei mit dem Dateinamen fallstudie_a-bewegungsdaten.csv aus, ignorieren entgegen bisheriger Einstellungen diesmal 2 Kopfzeilen und setzen das Datenformat erneut auf durch Separator getrennt (z.B. CSV). Beim Zahlenformat handelt es sich bei dieser DataSource wieder um eine Direkte Eingabe, deren Tausender-Trennzeichen ein Punkt (.) und deren Dezimalpunkttrennzeichen ein Komma (,) ist (siehe Abb. 3.76 DataSource Bewegungsdaten ändern II, Schritte 1 bis 5).

188

Data Warehouse-Architektur

Abb. 3.77 DataSource Bewegungsdaten ändern III

Laden Sie in der nächsten Registerkarte Vorschlag die Beispieldaten, um deren Struktur in der Registerkarte Felder zu bearbeiten. Ändern Sie dabei die angegeben CHAR-Datentypen der Felder Kalendertag, Umsatz und Waehrung in die Datentypen DATS, CURR und CUKY (siehe Abb. 3.77 DataSource Bewegungsdaten ändern III, Schritt 1) und bestätigen die Eingaben mit Enter. Desweiteren verwenden Sie für die Spalte Währ/Einh des Feldes Umsatz das InfoObject WAEHRUNG (Schritt 2) und setzen in derselben Zeile das Format auf extern (Schritt 3). Prüfen, Sichern und Aktivieren Sie die DataSource.

Fallstudie A: SAP BI Data Warehousing

189

Abb. 3.78 Vorschau DataSource Bewegungsdaten

Vergleichen Sie Ihre Daten über die Schaltfläche Vorschaudaten lesen innerhalb der Registerkarte Vorschau mit den Daten aus Abbildung 3.78. Stimmen diese überein verlassen Sie den Dialog über Beenden. Sie haben alle notwendigen DataSources erfolgreich im System hinterlegt. In Tabelle 3.16 sind die Eigenschaften der zuletzt angelegten DataSource für Bewegungsdaten aufgelistet. Tabelle 3.16 Übersicht der Eigenschaften der DataSource für Bewegungsdaten DataSource

UO_DS_PUMSATZ_##

Quellsystem

PCFILE001

Datentyp DataSource

Bewegungsdaten

Registerkarte Allgemeines Beschreibung kurz/mittel/lang Produkt-Umsatz ## Registerkarte Extraktion Dateiname

fallstudie_a-bewegungsdaten.csv

zu ignor. Kopfzeilen

2

Datenformat

durch Separator getrennt (z.B. CSV)

Datenseparator

;

Escape-Zeichen

„

190

Data Warehouse-Architektur

Zahlenformat

Direkte Eingabe

Tausender-Trennzeichen

.

Dezimalpunkttrennzeichen

,

3.4.2.3

Anlegen der Transformationen

In den folgenden drei Unterabschnitten werden die Transformationen für die Stammdatenattribute, die Stammdatentexte und die Bewegungsdaten angelegt. Anlegen der Transformation für Stammdatenattribute

Abb. 3.79 Transformation Stammdatenattribute anlegen I

Wechseln Sie im linken Navigationsbereich zunächst zurück in den Menüpunkt InfoProvider. Dort öffnen Sie die Baumstruktur für das InfoObjekt Produkt ##. Klicken Sie zunächst mit rechts auf den InfoProvider Produkt ## (Attribute) (siehe Abb. 3.79 Transformation Stammdatenattribute anlegen I, Schritt 1) und danach im Kontextmenü mit links auf den Menüpunkt Transformation anlegen… (Schritt 2), um als erstes eine Transformation der Stammdatenattribute vorzunehmen. Im sich öffnenden Dialog ist das Ziel der Transformation bereits mit

Fallstudie A: SAP BI Data Warehousing

191

den Eigenschafen des InfoObjekts festgelegt, Sie müssen nur noch im Gruppierungsfeld Quelle der Transformation als Objekttyp DataSource, unter DataSource den technischen Namen UO_DS_PATTR_## und als Quellsystem PCFILE001 eingeben (Schritt 3). Klicken Sie danach zur Bestätigung auf die Schaltfläche Transformation anlegen (Schritt 4). Es erscheint die Information „Es konnte kein Vorschlag erzeugt werden.“, die Sie ebenfalls durch Weiter bestätigen.

Abb. 3.80 Transformation Stammdatenattribute anlegen II

Im folgenden Dialog müssen Sie durch Verbinden der Elemente mittels Ziehen mit der linken Maustaste, die Transformationen zwischen DataSource und InfoObjekt abbilden. Klicken Sie dazu zunächst auf das Feld PRODUKTID der DataSource und halten dabei die linke Maustaste gedrückt. Ziehen Sie nun eine Verbindung zum InfoObjekt UO_MP_##, wonach die entsprechende Transformation durch einen Pfeil dargestellt wird. Verfahren Sie gleichermaßen bei der Verbindung des Feldes PREIS mit dem InfoObjekt UO_KP_##, sowie bei der Verbindung des Feldes WAEHRUNG mit dem InfoObjekt 0CURRENCY (siehe Abb. 3.80 Transformation Stammdatenattribute anlegen II, Markierung). Zum Abschluss Prüfen, Sichern und Aktivieren Sie die Transformation, bevor Sie den Dialog über Zurück verlassen.

192

Data Warehouse-Architektur

Anlegen der Transformation für Stammdatentexte

Abb. 3.81 Transformation Stammdatentexte anlegen I

Verfahren Sie beim Anlegen der Transformation für Stammdatentexte ähnlich der vorherigen Beschreibung für Stammdatenattribute, nur dass Sie in diesem Fall mit einem Rechtsklick auf den InfoProvider Produkt ## (Texte) mit dem Anlegen der Transformation beginnen (siehe Abb. 3.81 Transformation Stammdatentexte anlegen I, Schritte 1 und 2). Als Quelle der Transformation hinterlegen Sie als Objekttyp erneut DataSource, als DataSource diesmal jedoch UO_DS_PTEXTE_## und als Quellsystem erneut PCFILE001 (Schritt 3), bevor Sie mit Transformation anlegen fortfahren (Schritt 4). Nehmen Sie die nachfolgende Information zur Kenntnis.

Fallstudie A: SAP BI Data Warehousing

193

Abb. 3.82 Transformation Stammdatentexte anlegen II

Vervollständigen Sie die Transformation, indem Sie die drei Felder der DataSource Produkt-Texte ## mit den InfoObjekten des Merkmals Produkt ## gemäß der Abbildung (siehe Abb. 3.82 Transformation Stammdatentexte anlegen II, Markierung). Nach der Prüfung, Sicherung und Aktivierung der Transformation kehren Sie zur DWB zurück.

194

Data Warehouse-Architektur

Anlegen der Transformation für Bewegungsdaten

Abb. 3.83 Transformation Bewegungsdaten anlegen I

Die letzte Transformation stellt die Übertragung der Bewegungsdaten aus der DataSource in den InfoCube sicher. Klicken Sie zum Anlegen dieser Transaktion mit einem Rechtsklick auf den InfoCube Produkt-Umsatz Ist Fallstudie BW ## und wählen den bereits bekannten Menüpunkt Transaktion anlegen… (siehe Abb. 3.83 Transformation Bewegungsdaten anlegen I, Schritte 1 und 2). Im Gruppierungsfeld Quelle der Transformation tragen Sie die Informationen der letzten, noch nicht verwendeten DataSource ein: Objekttyp DataSource, DataSource UO_DS_PUMSATZ_## und Quellsystem PCFILE001 (Schritt 3). Schließen Sie Ihre Eingaben wie gewohnt über die Schaltfläche Transformation anlegen ab (Schritt 4) und bestätigen im Anschluss die Information mit Weiter.

Fallstudie A: SAP BI Data Warehousing

195

Abb. 3.84 Transformation Bewegungsdaten anlegen II

Verbinden Sie die Quellfelder der DataSource anhand der nachfolgenden Tabelle 3.17 oder gemäß der Abbildung 3.84 mit den Ziel-InfoObjekten (siehe Abb. 3.84 Transformation Bewegungsdaten anlegen II, Markierung). Das Feld Waehrung der DataSource wird dabei automatisch mit dem InfoObjekt UO_KU_## verbunden, sobald Sie die Verbindung zwischen dem Feld Umsatz der DataSource und dem InfoObjekt UO_KU_## herstellen. Nach dem Prüfen, Sichern und Aktivieren der Transformation beenden Sie den Dialog. Sie haben alle notwendigen Transformationen im System hinterlegt. Tabelle 3.17 Transformation der Bewegungsdaten UO_DS_PUMSATZ_## (Quelle)

UO_ICI_## (Ziel)

PRODUKT

UO_MP_##

KALENDERTAG

0CALMONTH

KALENDERTAG

0CALYEAR

BUCHUNGSKREIS

UO_MBK_##

UMSATZ

UO_KU_##

WAEHRUNG

UO_KU_##

196

Data Warehouse-Architektur

3.4.2.4

Manuelle Pflege der Stammdaten

Abb. 3.85 Stammdaten pflegen I

Wechseln Sie in der DWB in den Bereich der InfoObjects (siehe Abb. 3.85 Stammdaten pflegen I, Schritt 1) und öffnen Sie den Baum des InfoObjectCatalog der Merkmale Fallstudie BW ## (Schritt 2). Rufen Sie über einen Rechtsklick auf das Merkmal Buchungskreis ## das kontextsensitive Menü auf und klicken auf den Menüeintrag Stammdaten pflegen (Schritte 3 und 4). Im nachfolgenden Dialog Selektion klicken Sie auf die Schaltfläche Ausführen innerhalb der Anwendungsleiste (Schritt 5).

Fallstudie A: SAP BI Data Warehousing

197

Abb. 3.86 Stammdaten pflegen II

Betätigen Sie als nächstes die Schaltfläche Anlegen (siehe Abb. 3.86 Stammdaten pflegen II, Schritt 1), um einen neuen Stammdatensatz anzulegen. Im erscheinenden Dialog tragen Sie unter Buchungskreis den Wert 1 ein (Schritt 2) und tippen Berlin in das Feld Beschreibung kurz (Schritt 3). Bestätigen Sie Ihre Eingaben mit Enter (Schritt 4). Der soeben angelegte Stammdatensatz erscheint nun in der Liste, somit ist der Buchungskreis 1 nun dem Ort Berlin zugeordnet. Legen Sie durch obiges Verfahren (Schritte 1 bis 4) drei weitere Stammdatensätze an. Entnehmen Sie die Daten dazu aus folgender Tabelle 3.18: Tabelle 3.18 Merkmal Buchungskreis - Stammdaten pflegen Buchungskreis Beschreibung kurz 1

Berlin

2

Oldenburg

3

Stuttgart

4

Hamburg

198

Data Warehouse-Architektur

Abb. 3.87 Stammdaten pflegen III

Sobald Sie alle Stammdaten gepflegt haben, sollte Ihre Liste mit der aus Abbildung 3.87 übereinstimmen. Ist dies der Fall, verlassen Sie den Dialog über Beenden (siehe Abb. 3.87 Stammdaten pflegen III, Schritt 1) und bestätigen die folgende Nachfrage nach der Sicherung der Daten mit Ja (Schritt 2). Schließen Sie danach auch den Dialog der Selektion. Die Stammdaten für das Merkmal Buchungskreis sind nun gepflegt.

Fallstudie A: SAP BI Data Warehousing

3.4.2.5

199

Anlegen und Einplanen der InfoPackages

In den folgenden drei Unterabschnitten werden die InfoPackages für die Stammdatenattribute, die Stammdatentexte sowie für die Bewegungsdaten angelegt und eingeplant. Anlegen und Einplanen des InfoPackage für Stammdatenattribute

Abb. 3.88 InfoPackage Stammdatenattribute anlegen

Begeben Sie sich über den linken Navigationsbaum zurück zur Modellierung der InfoProvider (siehe Abb. 3.88 InfoPackage Stammdatenattribute anlegen, Schritt 1) und öffnen die Baumstruktur des InfoObjekts Produkt ## bis hinunter zur DataSource UO_DS_PATTR_##. Führen Sie einen Rechtsklick darauf aus und navigieren Sie zum Menüpunkt InfoPackage anlegen… (Schritte 2 und 3). Vergeben Sie im Dialog InfoPackage anlegen die InfoPackage-Bezeichnung UO_IP_PATTR_## (Schritt 4) und Sichern Ihre Angaben über die gleichnamige Schaltfläche (Schritt 5).

200

Data Warehouse-Architektur

Abb. 3.89 InfoPackage Stammdatenattribute einplanen

Im Scheduler (InfoPackage pflegen) klicken Sie auf die Registerkarte Einplanen (siehe Abb. 3.89 InfoPackage Stammdatenattribute einplanen, Schritt 1) und betätigen die Schaltfläche Start (Schritt 2). Sobald innerhalb der Statuszeile die Meldung „Daten wurden angefordert“ erscheint, klicken Sie auf den Monitor in der Anwendungsleiste (Schritt 3).

Fallstudie A: SAP BI Data Warehousing

201

Abb. 3.90 Monitor - Administrator Workbench

Über den Monitor erhalten Sie die Möglichkeit, einen Einblick in alle Details jeglicher Prozesse innerhalb des Systems zu erhalten, sich über eventuell auftretende Probleme zu informieren und deren Ursachen zu ergründen. Im rechten Fenster ist die Registerkarte Status geöffnet, über die Sie weitere, textuelle Informationen zum ausgewählten Request erhalten. Innerhalb der Registerkarte Detail (siehe Abb. 3.90 Monitor - Administrator Workbench, Schritt 1) sind alle einzelnen Schritte noch einmal detailliert aufgelistet. Sofern Sie die Inhalte ausreichend studiert haben, verlassen Sie den Monitor über die Schaltfläche Beenden (Schritt 2). Der Scheduler zum Pflegen des InfoPackages kann ebenfalls geschlossen werden.

202

Data Warehouse-Architektur

Anlegen und Einplanen des InfoPackages für Stammdatentexte

Abb. 3.91 InfoPackage Stammdatentexte anlegen

Führen Sie nach dem erfolgreichen Einplanen des InfoPackages für die Stammdatenattribute analog das Anlegen und Einplanen des InfoPackages für die Stammdatentexte durch. Klicken Sie dazu mit einem Rechtsklick auf die DataSource UO_DS_PTEXTE_## und wählen im kontextsensitiven Menü InfoPackage anlegen… (siehe Abb. 3.91 InfoPackage Stammdatentexte anlegen, Schritte 1 und 2). Wählen Sie UO_IP_PTEXTE_## als InfoPackage-Bezeichnung (Schritt 3) und fahren Sie über Sichern fort (Schritt 4). Wechseln Sie danach in die Registerkarte Einplanen und starten den Vorgang über die Start-Schaltfläche. Nachdem die Daten angefordert wurden, kontrollieren Sie den Datenfluss über den Monitor und verlassen den Scheduler des InfoPackages, sofern keine Probleme aufgetreten sind.

Fallstudie A: SAP BI Data Warehousing

203

Anlegen und Einplanen des InfoPackages für Bewegungsdaten

Abb. 3.92 InfoPackage Bewegungsdaten anlegen

Für das Anlegen des InfoPackages für die Bewegungsdaten begeben Sie sich zur DataSource UO_DS_PUMSATZ_## innerhalb der Struktur des InfoCube Produkt-Umsatz Ist Fallstudie BW ## und wählen auch hier den Menüpunkt InfoPackage anlegen… (siehe Abb. 3.92 InfoPackage Bewegungsdaten anlegen, Schritte 1 und 2). Das InfoPackage erhält die Bezeichnung UO_IP_PUMSATZ_## (Schritt 3) und kann nach dem Sichern (Schritt 4) ebenfalls über die Registerkarte Einplanen umgehend eingeplant werden.

204

Data Warehouse-Architektur

Abb. 3.93 InfoPackage Bewegungsdaten Monitor

Die anschließende Kontrolle mittels des Monitors, sollte gemäß der nachfolgenden Abbildung 3.93 die fehlerfreie Verbuchung von 77 Datensätzen ergeben. Ist dies der Fall, so haben Sie alle notwendigen InfoPackages für die Fallstudie modelliert und können den Monitor verlassen.

Fallstudie A: SAP BI Data Warehousing

3.4.2.6

205

Anlegen und Ausführen der Datentransferprozesse

Abb. 3.94 Datentransferprozess anlegen

Im letzten Beschaffungsschritt müssen Sie für jede der insgesamt drei DataSources (Stammdatenattribute, Stammdatentexte und Bewegungsdaten) einen Datentransferprozess (DTP) definieren, der gemäß der zuvor angelegten Transformation, die Fortschreibung der Daten aus der DataSource bzw. aus der Quelldatei in das Ziel (InfoObjekte für die Stammdatenattribute bzw. -texte und InfoCube für die Bewegungsdaten) vorschreibt und umsetzt. Da das Anlegen und Ausführen der DTPs durch wenige Mausklicks umgesetzt werden kann, führen Sie für die DataSources UO_DS_PATTR_##, UO_DS_PTEXTE_## und UO_DS_PUMSATZ_## jeweils folgende Schritte durch. Hinweis: Die Abbildungen beziehen sich auf das Anlegen und Ausführen des DTP für die DataSource UO_DS_PATTR_##, gelten aber beispielhaft auch für die beiden anderen DataSources.  Klicken Sie mit rechts auf das Ziel des DTP (Produkt ## (Attribute), Produkt ## (Texte) bzw. Produkt-Umsatz Ist Fallstudie BW ##) und wählen den Menüpunkt Datentransferprozess anlegen… aus (siehe Abb. 3.94 Datentransferprozess anlegen, Schritte 1 und 2).

206

Data Warehouse-Architektur

 Das System belegt alle Felder aufgrund der vorherigen Modellierung automatisch mit den korrekten Daten, so dass Sie den Dialog kurz studieren können, um dann mit Weiter fortzufahren (Schritt 3).

Abb. 3.95 Datentransferprozess ausführen

 Prüfen, Sichern und Aktivieren Sie den DTP (siehe Abb. 3.95 Datentransferprozess ausführen, Schritte 1 bis 3).  Wechseln Sie in die Registerkarte Ausführen (Schritt 4) und klicken Sie auf die Schaltfläche Ausführen (Schritt 5).  Bestätigen Sie den Dialog des Request-Status mit Ja (Schritt 6).

Fallstudie A: SAP BI Data Warehousing

207

Abb. 3.96 Monitor Datentransferprozess

 Überprüfen Sie die Requestverarbeitung anhand des Monitors zum Datentransferprozess im Kartenreiter Detail (siehe Abb. 3.96 Monitor Datentransferprozess, Schritt 1).  Sofern der Request korrekt verarbeitet wurde, verlassen Sie den Monitor über Beenden (Schritt 2). Schließen Sie danach den Dialog Anzeige Datentransferprozess.

208

Data Warehouse-Architektur

Abb. 3.97 Daten des InfoCube anzeigen I

Sie haben nun alle Schritte der Datenbeschaffung abgeschlossen. Die Daten, die im nächsten Abschnitt in das Reporting einfließen sollen liegen nun im InfoCube vor. Abschließend können Sie sich diese im InfoCube vorliegenden Daten anzeigen lassen. Klicken Sie dazu mit einem Rechtsklick auf den InfoCube ProduktUmsatz Ist Fallstudie BW ## und wählen im kontextsensitiven Menü den Eintrag Daten anzeigen (siehe Abb. 3.97 Daten des InfoCube anzeigen I, Schritte 1 und 2). Betätigen Sie im nächsten Dialog innerhalb der Anwendungsleiste die Schaltfläche Feldauswahl zur Ausgabe (Schritt 3).

Fallstudie A: SAP BI Data Warehousing

209

Abb. 3.98 Daten des InfoCube anzeigen II

Selektieren Sie die Optionen Produkt, Buchungskreis, KalJahr/Monat, Kalenderjahr, Währung und Umsatz über die entsprechenden Ankreuzfelder (siehe Abb. 3.98 Daten des InfoCube anzeigen II, Schritte 1 bis 6) und bestätigen Ihre Eingaben über die Schaltfläche Ausführen (Schritt 7). Zurück im Dialog UO_ICI_##, Selektionsbild betätigen Sie die Schaltfläche Ausführen erneut.

210

Data Warehouse-Architektur

Abb. 3.99 Daten des InfoCube anzeigen III

Das System generiert eine Liste mit den zuvor selektierten Feldern (siehe Abb. 3.99 Daten des InfoCube anzeigen III) und Sie erhalten einen Einblick in die im InfoCube vorliegenden Daten. Durch zweimaliges Beenden schließen Sie den zweiten Teil dieser ersten Fallstudie ab. Sie können die DWB verlassen. 3.4.2.7

Zusammenfassung

Im zweiten Teil der Fallstudie haben Sie sich mit der Datenbeschaffung aus flachen Dateien heraus vertraut gemacht. Nach dem Anlegen der Anwendungskomponente UO_AK_## haben Sie jeweils eine DataSource für die Stammdatenattribute und Stammdatentexte des InfoObjekts Produkt ##, sowieso eine DataSource zum Einlesen der Bewegungsdaten in den InfoCube UO_ICI_## angelegt. Alle Daten stammen dazu aus dem Quellsystem vom Typ PCFILE001, also aus einzelnen CSV-Dateien. Im Zuge dessen haben Sie die Eigenschaften zur Extraktion sowie die Eigenschaften der DataSource-Felder festgelegt. Darauf aufbauend haben Sie über eine grafische Benutzeroberfläche drei Transformationen angelegt, wodurch Sie die Übertragungs- und Fortschreibungsregeln aus den DataSources in die Ziele definiert haben. Dabei kam ausschließlich der Regeltyp zur direkten Übertragung zum Einsatz. Nach dem Anlegen und Einplanen der InfoPackages haben Sie zu jeder der drei Transformationen den Datentransferprozess angelegt

Fallstudie A: SAP BI Data Warehousing

211

und umgehend ausgeführt, so dass die Quelldaten letztlich in die Ziele geschrieben werden konnten. Die Stammdaten zum Merkmal Buchungskreis ## haben Sie manuell im System gepflegt. Abschließend haben Sie anhand des Monitors die korrekte Ausführung der Datentransferprozesse kontrolliert und die Bewegungsdaten auf ihre korrekte Verarbeitung anhand eines direkten Einblickes in die Daten des InfoCube UO_ICI_## überprüft.

3.4.3 Teil III - Reporting Nachdem im ersten Teil der Fallstudie im Rahmen der Datenmodellierung das Datenmodell angelegt und ferner die Einstellungen für die Datenbeschaffung vorgenommen wurden, ist das SAP BI Data Warehousing im zweiten Teil im Zuge der Datenbeschaffung mit Stamm- und Bewegungsdaten gefüllt worden. Auf Grundlage dieses Datenbestandes können nun - im dritten und letzten Teil dieser Fallstudie - Queries für Analysen formuliert werden. Diese Queries werden über den BEx Query Designer definiert und beziehen ihre Daten aus dem zuvor modellierten und bereits befüllten InfoCube. Eine Query ist in diesem Zusammenhang eine Datenbankabfrage, welche eine bestimmte Sicht auf den Datenbestand eines InfoProviders liefert. Bei der Definition einer Query können die Dimensionen eines InfoCube, also deren Merkmale und Kennzahlen beliebig in Zeilen oder Spalten angeordnet werden. Desweiteren ist es möglich, sogenannte freie Merkmale zu definieren, deren Inhalte von vornherein nicht in einer Zeile oder Spalte angeordnet sind, sondern erst zur Laufzeit der Query durch den Anwender in die Navigation eingebunden werden. Somit wird durch eine Query zunächst eine erste Sicht auf den Datenbestand generiert, deren Ausprägung jedoch vom Anwender manipuliert und auf seine Wünsche ausgerichtet werden kann, indem dieser zur Laufzeit der Query die Anordnung von Zeilen, Spalten und freien Merkmalen verändert. Außerdem besteht die Möglichkeit durch Filter, Bedingungen und Exceptions, zuvor festgelegte Datenbereiche oder Grenzwerte auszusortieren oder diese beispielsweise optisch besonders hervorzuheben. Sofern die Query definiert und gespeichert wurde, kann sie über den BEx Query Designer umgehend in einem beliebigen Webbrowser ausgeführt werden, um sie dort auf ihre Tauglichkeit und Korrektheit zu überprüfen. Dazu wird vom System ein Standard Web Template verwendet, welches SAP BI-spezifische Webelemente zur Verfügung stellt, worüber der Anwender Zugriff auf eine Vielzahl von Funktionen erhält. Über den Navigationsbereich beispielsweise ist es möglich, mittels eines Kontextmenüs die Sicht auf den Datenbestand zu ändern, indem die zuvor angesprochene Anordnung von Zeilen, Spalten und freien Merkmalen zur Laufzeit der Query variiert wird. Die gewählte Sicht auf die Daten ist in der ebenfalls im Standard Web Template enthaltenen Ergebnistabelle abgebildet. Deren Einträge verfügen gleichermaßen über Kontextmenüs, die verschiedene Operationen zur Navigation erlauben. Über die Werkzeugleiste wiederum kann die Sicht

212

Data Warehouse-Architektur

auf die Daten in Form eines Diagramms abgebildet werden. Dazu stehen unterschiedliche Diagrammtypen zur Verfügung, die sich je nach Anforderung und Datenbestand besonders gut, oder möglicherweise besonders schlecht für die gewählte Sicht eignen. Neben dem BEx Query Designer und dem Ad hoc-Reporting im Webbrowser soll in diesem Abschnitt ferner auf den BEx Analyzer eingegangen werden, der als eine Erweiterung von MS Excel bezeichnet werden kann. Da die Nutzung von MS Excel von einer Mehrheit von Controlling-Anwender/innen im Bereich des Data Warehousing favorisiert wird (vgl. Egger et al. 2006), soll auch diese Applikation im Rahmen der Fallstudie beleuchtet werden. Das Reporting über den BEx Analyzer wird dabei komplett in MS Excel integriert und kann über die Kommunikation mit dem SAP BI-System durch den Einsatz von Makros auf eine Reihe von Funktionalitäten zugreifen. Ähnlich dem Ad hoc-Reporting im Webbrowser stehen dem Anwender hier ebenfalls Kontextmenüs über Rechtsklicks auf die einzelnen Zellen zur Verfügung, über die die Anordnung von Zeilen, Spalten und freien Merkmalen festgelegt werden kann. Auch das Einfügen von Diagrammen mit den weiterführenden Funktionalitäten von MS Excel ist erlaubt. Folglich kann durch den Einsatz des BEx Analyzers die sehr umfangreiche Funktionalität des SAP BISystems mit dem für vielerlei Anwender bereits bekannten Funktionsumfang von MS Excel kombiniert werden. Abschließend soll auf den BEx Web Application Designer eingegangen werden, da dieser die Entwicklung individuell gestalteter Web Templates erlaubt. Beginnend mit einer leeren HTML-Seite, kann der Anwender sein Web Template ganz nach seinen Wünschen gestalten und dabei die SAP BI-spezifischen Objekte, die sogenannten Web Items, per Drag & Drop einbinden. Ein solches Web Item, wie beispielsweise ein Navigationsbereich oder eine Ergebnistabelle, kann über individuelle Einstellungen je nach Anforderung angepasst werden, bleibt jedoch in seiner Funktion weites gehend unverändert. Desweiteren können Buttons oder Dropdown-Boxen eingefügt und mit unterschiedlichen Aktionen oder Werten belegt werden. Über die Auswahl eines DataProvider wird die Verknüpfung zwischen dem erstellten Web Template und der Datenbankabfrage hergestellt. An dieser Stelle können auch zuvor definierte Sichten als Quelle für die spätere Web Anwendung verwendet werden. Ist die Web Applikation fertig gestellt, kann das fertige Web Template im Webbrowser ausgeführt und das Ergebnis betrachtet und getestet werden.

Fallstudie A: SAP BI Data Warehousing

3.4.3.1

213

Anlegen der Query

Starten Sie den Query Designer über das MS Windows Startmenü unter Programme  Business Explorer und melden Sie sich mit Ihrem Benutzernamen und Kennwort am SAP BI-System an.

Abb. 3.100 Auswahl des InfoProvider

Erstellen Sie zu Beginn eine Neue Query… über die gleichnamige Schaltfläche (siehe Abb. 3.100 Auswahl des InfoProvider, Schritt 1) und klicken anschließend auf die Schaltfläche InfoAreas im sich öffnenden Dialog Neue Query: InfoProvider auswählen (Schritt 2). Klicken Sie im Auswahlfenster doppelt auf die InfoArea (hier: Uni Oldenburg) und dann ebenfalls doppelt auf untergeordnete InfoArea Fallstudie BW ##, um schließlich den InfoCube Produkt-Umsatz Ist Fallstudie BW ## auswählen (Schritt 3) und Öffnen zu können (Schritt 4).

214

Data Warehouse-Architektur

Abb. 3.101 Query anlegen

Wechseln Sie in die Registerkarte Zeilen/Spalten (siehe Abb. 3.101 Query anlegen, Schritt 1) und ziehen Sie die Kennzahl Umsatz per Drag & Drop aus dem Bereich des InfoProvider in den Bereich Spalten (Schritt 2). Desweiteren expandieren Sie die Teilbäume unter Dimensionen und ziehen auf identische Art und Weise die Merkmale Produkt und Buchungskreis aus deren gleichnamigen Dimensionen in den Bereich Freie Merkmale (Schritte 3 und 4), ebenso wie die Zeitmerkmale Kalenderjahr und KalJahr/Monat aus der Zeitdimension (Schritte 5 und 6).

Fallstudie A: SAP BI Data Warehousing

215

Abb. 3.102 Query speichern

Betätigen Sie als nächstes die Schaltfläche Query speichern (siehe Abb. 3.102 Query speichern, Schritt 1) und klicken im sich öffnenden Dialog auf Neuen Ordner anlegen (Schritt 2). Vergeben Sie die Bezeichnung Fallstudie BW ## für den neuen Ordner und bestätigen Sie Ihre Eingabe mit Enter. Klicken Sie doppelt auf den neu angelegten Ordner, um Ihre Query darin zu speichern. Hier vergeben Sie die Beschreibung Produkt-Umsatz Ist ##, sowie den technischen Namen QUERY1_## (Schritt 3) und schließen den Speichervorgang über Sichern ab (Schritt 4).

216

Data Warehouse-Architektur

3.4.3.2

Ad hoc - Reporting im Webbrowser

Abb. 3.103 Query ausführen

Um die Daten und die Struktur der Query zu überprüfen besteht die Möglichkeit, die Query ad hoc über einen Webbrowser auszuführen. Verwenden Sie dazu im Query Designer die Schaltfläche Ausführen (siehe Abb. 3.103 Query ausführen, Schritt 1). Es öffnet sich Ihr Webbrowser und Sie werden erneut aufgefordert, sich mittels Benutzerkennung und Kennwort zu authentifizieren. Den nachfolgenden Dialog Variableneintrag zur Auswahl eines Stichtages können Sie mit einem Klick auf OK übergehen (Schritt 2).

Fallstudie A: SAP BI Data Warehousing

217

Abb. 3.104 OLAP im Ad-hoc Reporting I

Der Webbrowser zeigt nun Ihre Query Produkt-Umsatz Ist ## an. Da Sie beim Anlegen der Query zuvor nur die Kennzahl Umsatz als Spalte definiert haben, fällt das Reporting in der aktuellen Ansicht noch sehr einfach aus. Um jedoch ein komplexeres, aussagekräftigeres Reporting durchführen zu können, sollen zuerst die Umsätze aufgegliedert nach Buchungskreisen und in einem weiteren Schritt differenziert nach einzelnen Monaten betrachtet werden. Dazu haben Sie die Möglichkeit die freien Merkmale in Zeilen oder Spalten aufzureißen. Klicken Sie zu diesem Zweck zunächst mit einem Rechtsklick auf das freie Merkmal Buchungskreis und navigieren im Kontextmenü über die Einträge Aufriss verändern  Aufreißen nach zum Menüpunkt senkrecht (siehe Abb. 3.104 OLAP im Ad-hoc Reporting I, Schritte 1 und 2). Die tabellarische Darstellung der Ergebnisse Ihrer Query wird automatisch aktualisiert. Wechseln Sie in die Darstellungsform Tabelle und Grafik über das Selektionsfeld Anzeigen als (Schritt 3).

218

Data Warehouse-Architektur

Abb. 3.105 OLAP im Ad-hoc Reporting II

Um nun auch die Differenzierung nach einzelnen Monaten innerhalb des Reporting abbilden zu können, reißen Sie das freie Merkmal KalJahr/Monat über das Kontextmenü - gemäß obiger Beschreibung - waagerecht auf, so dass das Merkmal den Spalten zugeordnet wird (siehe Abb. 3.105 OLAP im Ad-hoc Reporting II, Schritte 1 und 2). Die tabellarische und grafische Darstellung werden erneut aktualisiert.

Fallstudie A: SAP BI Data Warehousing

219

Abb. 3.106 Analyse im Ad-hoc Reporting

Durch diese Art der Darstellung lassen sich bereits interessante Aussagen über die Analysedaten formulieren. Gemäß der Abbildung 3.106 ist so zum Beispiel ein deutlicher Anstieg des Umsatzes innerhalb aller Buchungskreise seit Anfang März 2008 zu verzeichnen. Hinweis: Über Einstellungen (siehe Abb. 3.106 Analyse im Ad-hoc Reporting, Markierung) oder auch direkt im Query Designer können Sie eine Vielzahl an Änderungen vornehmen oder Ihr Reporting mit weiteren Features anreichern. So können Sie unter anderem über die Registerkarte Grafik einen anderen Diagrammtypen (hier: Chart-Typ) wählen oder die Achsenbeschriftung nach Ihren Wünschen ausrichten. Desweiteren besteht die Möglichkeit über sogenannte Exceptions bestimmte Grenzwerte visuell hervorzuheben, also beispielsweise kritische Umsatzzahlen oder besonders große Abweichungen von Durchschnittswerten über auffallende Hintergrundfarben oder Symbole zu kennzeichnen.

220

Data Warehouse-Architektur

Abb. 3.107 View sichern

Über das Aufreißen der Merkmale Buchungskreis und KalJahr/Monat haben Sie eine spezielle Sicht auf die im vorherigen Schritt angelegte Query erstellt. Solche Sichten auf Queries werden in diesem Zusammenhang als Views bezeichnet und können für weitere Anwendungen als Navigationszustand gespeichert werden. Klicken Sie dazu mit einem Rechtsklick auf ein beliebiges Element im linken Navigationsbereich und wählen im Kontextmenü den Eintrag View sichern (siehe Abb. 3.107 View sichern, Schritt 1). Im erscheinenden Webseitendialog vergeben Sie die Beschreibung Produkt-Umsatz Ist View ## und den technischen Namen VIEW1_## (Schritt 2) und bestätigen Ihre Eingaben durch einen Klick auf OK (Schritt 3). Der View ist nun gesichert und Sie können den Browser verlassen. Der Query Designer kann ebenfalls geschlossen werden.

Fallstudie A: SAP BI Data Warehousing

3.4.3.3

221

Reporting mit dem BEx Analyser unter MS Excel

Starten Sie MS Excel über das MS Windows Startmenü, indem Sie über Programme  Business Explorer den Analyzer starten. Der möglichen Frage bezüglich der Aktivierung von Makros der SAP AG stimmen Sie mit Makros aktivieren zu.

Abb. 3.108 Öffnen der Query im BEx Analyser

Über den Menüeintrag Add-Ins (siehe Abb. 3.108 Öffnen der Query im BEx Analyser, Schritt 1) steht Ihnen nun eine neue Werkzeugleiste mit Elementen des Business Explorers zur Verfügung. Klicken Sie in dieser Werkzeugleiste auf Öffnen (Schritt 2) und anschließend auf den Menüpunkt Gespeicherte Views (Schritt 3). Melden Sie sich daraufhin am System an und wählen aus der Historie Ihren Query View Produkt-Umsatz Ist View ## (Schritt 4), wonach Sie diese über OK öffnen (Schritt 5).

222

Data Warehouse-Architektur

Abb. 3.109 Einbinden eines Diagramms im BEx Analyzer

Ähnlich dem im vorherigen Abschnitt beschriebenen Ad hoc Reporting im Webbrowser haben Sie in MS Excel ebenfalls die Möglichkeit, über Rechtsklicks auf die einzelnen Felder der Objekte unterschiedliche Sichten auf die Daten zu generieren und diese Views für spätere Arbeiten zu sichern. Da Sie jedoch bereits einen View erzeugt und dieser bereits geöffnet vorliegt, ist ein weiteres Aufreißen der Objekte nicht mehr nötig. Stattdessen können Sie über die Schaltfläche Layout (siehe Abb. 3.109 Einbinden eines Diagramms, Schritt 1) ein Diagramm anbinden (Schritt 2).

Fallstudie A: SAP BI Data Warehousing

223

Abb. 3.110 Bearbeiten eines Diagramms im BEx Analyzer I

Ziehen Sie das Diagramm unter die Ergebnistabelle. Sie können nun alle bekannten Funktionalitäten von MS Excel in Ihre Arbeit mit einfließen lassen. Sie können beispielsweise über den blauen Rahmen innerhalb der Ergebnistabelle den Diagrammdatenbereich verändern. Schließen Sie hierfür das Gesamtergebnis für die Darstellung im Diagramm aus, indem Sie zuerst mittig auf das Diagramm klicken (siehe Abb. 3.110 Bearbeiten eines Diagramms im BEx Analyzer I, Schritt 1) und dann den blauen Rahmen der Ergebnistabelle auf die Buchungskreise und die Kalendermonate durch Halten der linken Maustaste beschränken (Schritt 2).

224

Data Warehouse-Architektur

Abb. 3.111 Bearbeiten eines Diagramms im BEx Analyzer II

Betrachten Sie das Ergebnis der Korrektur der Datenquelle für das Diagramm (siehe Abb. 3.111 Bearbeiten eines Diagramms im BEx Analyzer II) und schliessen Sie MS Excel ohne zu speichern.

Fallstudie A: SAP BI Data Warehousing

3.4.3.4

225

Reporting mit dem BEx Web Application Designer

Starten Sie über das MS Windows Startmenü den Web Application Designer, der sich innerhalb der Programmgruppe Business Explorer befindet. Nach der Eingabe Ihrer Zugangsdaten öffnet sich das Programm.

Abb. 3.112 Web Template mit Data Provider anlegen

Beginnen Sie mit einem neuen, leeren Template, welches Sie über die Schaltfläche Neu in der Anwendungsleiste erzeugen (siehe Abb. 3.112 Web Template mit Data Provider anlegen, Schritt 1). Klicken mit einem Doppelklick auf Neuer Data Provider (Schritt 2), um die Web Applikation mit den bisher in der Fallstudie verwendeten Daten versorgen zu können. Im sich öffnenden Dialog ersetzen Sie den vorgeschlagenen Namen DP_1 durch UO_DP1_## (Schritt 3) und definieren als Data-Provider-Typ eine Query View (Schritt 4), die Sie über die Schaltfläche Query View auswählen festlegen (Schritt 5). Suchen Sie dazu unter InfoAreas (Schritt 6) und klicken sich über Ihre InfoArea (hier: Uni Oldenburg)  Fallstudie BW ##  Produkt-Umsatz Ist Fallstudie BW ##  Produkt-Umsatz Ist ## zum Produkt-Umsatz Ist View ## (Schritt 7), welchen Sie dann Öffnen (Schritt 8). Zurück im Dialog Neuer Data Provider bestätigen Sie Ihre Auswahl dann mit OK.

226

Data Warehouse-Architektur

Abb. 3.113 Überschrift einfügen

Beginnen Sie nun mit dem Design im dafür vorgesehenen Modellierungsbereich der Registerkarte Layout (siehe Abb. 3.113 Überschrift einfügen, Schritt 1). Vergeben in der ersten Zeile zunächst eine passende Überschrift (z.B. ProduktUmsatz 1. Halbjahr 2008) für die Web Applikation (Schritt 2) und heben diese über die gängigen Schrift-Formatierungs-Elemente in der Anwendungszeile hervor (Schritt 3).

Fallstudie A: SAP BI Data Warehousing

227

Abb. 3.114 Tabelle einfügen

In der nächsten Zeile wählen Sie in der Menüleiste den Eintrag Tabelle und selektieren im Untermenü Tabelle einfügen (siehe Abb. 3.114 Tabelle einfügen, Schritte 1 und 2). Setzen Sie die Anzahl der Zeilen auf 4, die Anzahl der Spalten auf 2 (Schritt 3) und bestätigen Sie mit OK (Schritt 4).

228

Data Warehouse-Architektur

Abb. 3.115 Web Items Button-Group und Dropdown-Box einfügen

Ziehen Sie nun aus der Liste der Web Items das Standard-Objekt Button-Group in die erste Zelle der Tabelle (siehe Abb. 3.115 Web Items Button-Group und Dropdown-Box einfügen, Schritt 1) und das Standard-Objekt Dropdown-Box in die Zelle rechts daneben (Schritt 2). Als nächstes sollen die Eigenschaften dieser beiden eingefügten Objekte bearbeitet werden. Klicken Sie dazu immer zuerst auf das Web Item im Modellierungsbereich, welches Sie bearbeiten wollen und wechseln Sie dann im Fenster Eigenschaften in den Reiter Web-Item-Parameter (Schritt 3). Beginnen Sie mit dem Web Item Button-Group und klicken Sie dazu auf die kleine Schaltfläche neben ??(Drucktaste) im Parameter Interne Anzeige (Schritt 4), um die Aktion für die erste Drucktaste zu definieren.

Fallstudie A: SAP BI Data Warehousing

229

Abb. 3.116 Eigenschaften Button-Group bearbeiten I

Im sich öffnenden Dialog Parameter bearbeiten vergeben Sie als Beschriftung PDF erstellen (siehe Abb. 3.116 Eigenschaften Button-Group bearbeiten I, Schritt 1). Danach klicken Sie auf die Schaltfläche neben dem Parameter Befehl (Schritt 2) und wechseln im nächsten Dialog in den Reiter Alle Befehle (Schritt 3), um dort unter Befehle für Web Templates den Befehl Web Application exportieren auswählen (Schritt 4) und mit Weiter bestätigen (Schritt 5).

230

Data Warehouse-Architektur

Abb. 3.117 Eigenschaften Button-Group bearbeiten II

Im nächsten Dialog haben Sie die Möglichkeit den soeben ausgewählten Befehl zu bearbeiten. An dieser Stelle müssen Sie nur sicherstellen, dass das Exportformat PDF als Befehlspezifischer Parameter gewählt ist (siehe Abb. 3.117 Eigenschaften Button-Group bearbeiten II, Schritt 1). Ist dies der Fall, verlassen Sie den Dialog über einen Klick auf OK (Schritt 2). Zurück im Dialog Parameter bearbeiten klicken Sie erneut auf OK, um das Erstellen der ersten Schaltfläche abzuschliessen. Legen Sie nach dem gleichen Verfahren eine weitere Drucktaste an, die Sie jedoch mit Schließen beschriften und entsprechend mit dem Befehl BrowserFenster schließen versehen.

Fallstudie A: SAP BI Data Warehousing

231

Abb. 3.118 Eigenschaften Dropdown-Box bearbeiten I

Zur Bearbeitung der Eigenschaften der Dropdown-Box, selektieren Sie diese über die Auswahlbox der Eigenschaften (siehe Abb. 3.118 Eigenschaften DropdownBox bearbeiten I, Schritt 1), begeben Sie sich zum Parameter Datenbindungstyp Datenbind innerhalb des Web-Item -Item -Parameter-Reiters der Eigenschaften für die DropdownBox und klicken auf die kleine Schaltfläche zur Merkmalsselektion (Schritt 2). Im folgenden Dialog wählen Sie den Data Provider UO_DP1_## und das Merkmal KalJahr/Monat aus und aktivieren den Parameter Bezeichnung sichtbar durch Setzen eines Häkchens in das dafür vorgesehene Ankreuzfeld (Schritt 3). Schliessen Sie den Dialog über OK (Schritt 4).

232

Data Warehouse-Architektur

Abb. 3.119 Web Item Checkbox-Group einfügen

In die zweite Zeile der ersten Spalte der Tabelle ziehen Sie das Web Item Checkbox-Group (siehe Abb. 3.119 Web Item Checkbox-Group einfügen, Schritt 1) und wählen in den Eigenschaften unter Datenbindung den Data Provider UO_DP1_##, sofern dieser nicht bereits ausgewählt ist (Schritt 2) und das Merkmal Produkt aus der Liste der Merkmale (Schritt 3).

Fallstudie A: SAP BI Data Warehousing

233

Abb. 3.120 Web Items Analyse und Chart einfügen

Neben Überschrift, Button-Group, Dropdown-Box und Checkbox-Group benötigen Sie für Ihre Web Applikation zusätzlich noch die Web Items Analyse und Chart, um die tatsächlichen Daten in die Web Applikation einfließen zu lassen bzw. sie in Form einer Tabelle und einer anschaulichen Grafik wiederzugeben. Ziehen Sie dazu das Web Item Analyse in die dritte (siehe Abb. 3.120 Web Items Analyse und Chart einfügen, Schritt 1), und das Web Item Chart in die vierte und letzte Zeile Ihrer Tabelle (Schritt 2). Für Letzteres verändern Sie unter Eigenschaften die Breite in Pixel auf 700 (Schritt 3). Das Layout ist nun fertiggestellt.

234

Data Warehouse-Architektur

Abb. 3.121 Web Applikation sichern

Um die Web Applikation zu sichern, klicken Sie innerhalb der Werkzeugleiste auf die Schaltfläche Speichern (siehe Abb. 3.121 Web Applikation sichern, Schritt 1). Platzieren Sie das Web Template im bereits vorhandenen Ordner Fallstudie BW ## mit der Beschreibung Produkt-Umsatz Ist Web Template ## und dem technischen Namen WEBTEMPLATE1_## (Schritt 2). Sichern Sie es (Schritt 3). Um sich nun die fertige Web Applikation im Webbrowser anzeigen zu lassen, betätigen Sie die Schaltfläche Ausführen… (Schritt 4).

Fallstudie A: SAP BI Data Warehousing

235

Abb. 3.122 Web Applikation im Webbrowser

Ihr Standardbrowser verlangt erneut nach Ihrem Benutzernamen und dem dazugehörigen Passwort, wonach Sie Ihre soeben erstellte Web Applikation im Browser betrachten können. Über das Web Item Button-Group haben Sie nun die Möglichkeit durch einen Klick auf die Schaltfläche PDF erstellen ein PDF aus der aktuellen Ansicht zu generieren (siehe Abb. 3.122 Web Applikation im Webbrowser, Schritt 1). Desweiteren können Sie über die Ankreuzfelder der Checkbox-Group und einem anschließenden Klick auf Übernehmen den Produkt-Umsatz auf die ausgewählten Produkte beschränken (Schritt 2). Gleiches gilt für die Einschränkung der Monate über die Dropdown-Box oben rechts im Browser (Schritt 3).

236

Data Warehouse-Architektur

Abb. 3.123 OLAP im Webbrowser

Um mit OLAP-Operationen im Webbrowser vertraut zu werden, schränken Sie die Ergebnistabelle auf die Plasma-Flachbildschirme ein (siehe Abb. 3.123 OLAP im Webbrowser, Schritt 1). Die Funktionalität der Erstellung unterschiedlicher Views, sowie deren Speicherung, wie Sie es bereits aus dem Abschnitt über das Ad hoc-Reporting im Webbrowser kennen, steht Ihnen hier über einen Rechtsklick auf Spalten bzw. Zeilen des Analyse-Web-Items ebenfalls zur Verfügung. Um die selektierten Produkte in der Ergebnistabelle sichtbar zu machen, klicken Sie mit rechts auf einen beliebigen Buchungskreis (hier: Hamburg) (Schritt 2) und reißen das Merkmal Produkt senkrecht auf (Schritt 3).

Fallstudie A: SAP BI Data Warehousing

237

Abb. 3.124 Produkt-Attribute anzeigen

Die ausgewählten Produkte der beiden Plasma-Flachbildschirme tauchen nun in der Ergebnistabelle auf. Um das Produkt-Attribut Preis ebenfalls in der Ergebnistabelle anzeigen zu lassen, klicken Sie mit einem Rechtsklick auf ein beliebiges Produkt und wählen Eigenschaften  Merkmal (siehe Abb. 3.124 ProduktAttribute anzeigen, Schritte 1 und 2). Im sich öffnenden Dialog wechseln Sie in den Kartenreiter Eigenschaften (Schritt 3), selektieren das verfügbare Attribut Preis (Schritt 4) und nehmen es über Hinzufügen in die Liste der ausgewählten Attribute auf (Schritt 5). Beenden Sie den Dialog über OK (Schritt 6). Der Preis zu dem jeweiligen Produkt wird nun in der Ergebnistabelle angezeigt.

238

Data Warehouse-Architektur

Abb. 3.125 Webbrowser schließen

Sofern Sie die Möglichkeiten der Web Applikation ausreichend studiert haben, schließen Sie sowohl den Webbrowser über die Schaltfläche Schließen (siehe Abb. 3.125 Webbrowser schließen, Markierung), als auch den Web Application Designer. Sie haben die erste Fallstudie zum SAP BI Data Warehousing erfolgreich abgeschlossen. 3.4.3.5

Zusammenfassung

Zu Beginn dieses dritten und letzten Teils der Fallstudie haben Sie mit Hilfe des BEx Query Designers die Query Produkt-Umsatz Ist ## erstellt. Die Daten für diese Query wurden dabei aus dem in den ersten beiden Teilen der Fallstudie gepflegten InfoCube Produkt-Umsatz Ist Fallstudie BW ## bezogen. Sie haben die Query über das Ad hoc-Reporting im Webbrowser ausgeführt und die damit verbundenen Funktionalitäten kennengelernt, um beispielsweise unterschiedliche Sichten auf den Datenbestand zu generieren und sie für spätere Arbeiten zu sichern. Im nächsten Schritt haben Sie die Query über den BEx Analyzer geöffnet und konnten durch OLAP-Operationen auch in der Umgebung von MS Excel einige Auswertungen des Datenbestandes vornehmen, indem Sie unter anderem ein Diagramm in der MS Excel-Arbeitsmappe erzeugt und dieses zu Analysezwecken aufbereitet haben. Im BEx Web Application Designer haben Sie letztlich den Auf-

Fallstudie A: SAP BI Data Warehousing

239

bau eines Web Template praktisch nachvollzogen. Auf Basis der zuvor gespeicherten Sicht auf den Datenbestand haben Sie die Web Items Button-Group, Dropdown-Box, Checkbox-Group, Analyse und Chart in Ihr eigenes Web Template eingefügt und die dazugehörigen Eigenschaften nach Ihren Bedürfnissen angepasst. Abschließend haben Sie das Web Template im Webbrowser ausgeführt und sich das Ergebnis Ihrer Arbeit angeschaut und deren Funktionalität getestet, sowie einige visuelle Veränderungen durchgeführt.

4 Unternehmensplanung 4.1

Grundlagen der Unternehmensplanung

Schon in frühen Definitionen des Managements oder der Unternehmensführung gehörte die Planung der Unternehmensaktivitäten zu den wesentlichen Aufgaben der Führungskräfte (vgl. Fayol 1916, Gulick u. Urwick 1937). Dementsprechend war seit Beginn der Konzeption einer Software zur Unterstützung der Führungskräfte die computergestützte Unternehmensplanung einer der Kernpunkte im Pflichtenheft (vgl. Ream 1960). Und auch heute wird von der Business Intelligence gefordert, das Potential des Erfolgsfaktors Unternehmensplanung in bester Weise nutzbar zu machen. Dadurch bedingt, dass Softwareunterstützung für eine strategische und unternehmensweite Planung in der Vergangenheit von nachrangiger Bedeutung war, ist keine eindeutige Zuordnung der Unternehmensplanung zu einem Element der Informationsinfrastruktur möglich gewesen. Anfangs sollte die Unternehmensplanung, wie ursprünglich vorgesehen, in entscheidungsunterstützenden Systemen implementiert sein, jedoch wurde dies nicht ausreichend realisiert. Deswegen wurden die Planungsfunktionen in den ERP-Systemen auf spezielle Aufgabenbereiche beschränkt, wo sie die Prognose und die Planung im operativen Betrieb unterstützten, etwa in der Warenwirtschaft oder der Produktionsplanung und -steuerung. Auf diese Weise entstanden voneinander unabhängige Planungsmodule, die auf ihr betriebliches Einsatzgebiet beschränkt waren. Mit der heutigen Interpretation einer erfolgreich implementierten Business-Intelligence-Lösung ist die Nutzung der zentral, etwa in einem Data Warehouse gespeicherten Daten zum Zwecke des Berichtswesens und der Entscheidungsfindung eine Best-Practice-Lösung. Planungsfunktionen müssen auf diesen Daten aufsetzen, um eine integrierte und vollständige Planung im Unternehmen zu ermöglichen. Die Theorie der Unternehmensplanung besitzt viele Facetten. Es existieren unterschiedliche Methoden und Empfehlungen zur Organisation und Durchführung der Planung. Deren Ausprägungen werden individuell an die Bedingungen eines Unternehmens und der betrieblichen Umwelt angepasst. Unter den gegebenen Bedingungen kann keine Standard-Software die Anforderungen eines Unternehmens an die Planung erfüllen. Als Folge dessen handelt es sich bei Software für die Unternehmensplanung in der Regel um eine kundenindividuelle Umsetzung bzw. Anpassung des durch den Software-Hersteller gegebenen Rahmens mittels der zur Verfügung stehenden Software-Werkzeuge. Es liegt in der Verantwortung der Führungsspitze eines jeden Unternehmens, die Planung zu organisieren, durchzuführen und zu kontrollieren. Business Intelligence stellt den Entscheidungsträgern die notwendige Unterstützung bereit, um den Planungsprozess effizient und wirksam durchzuführen.

242

Unternehmensplanung

4.1.1 Unternehmensplanung als Querschnittsfunktion Die Unternehmensplanung betrifft das gesamte Unternehmen und durchdringt es mit unterschiedlicher Intensität in allen seinen Bereichen. In diese Querschnittsfunktion sind die Führungsebenen aller Geschäfts- und Funktionsbereiche einbezogen. Hervorzuheben ist, dass die Planung im Sinne von zukunftsbezogenen Tätigkeiten verschiedener Planungsträger in einer Organisation eine kollektive Tätigkeit darstellt (vgl. Kreikebaum 1993). Die vollkommene, umfassende und gemeinsame Abstimmung ist ein wesentliches Merkmal der Planungsaktivitäten im Unternehmen. Die Planung als gedankliche Vorbereitung zielgerichteter Entscheidungen ist eng mit der Zielbildung und der Entscheidung verknüpft, indem sie von den Zielen ausgehend verschiedene Handlungsalternativen zur Entscheidung vorlegt und diese verfolgt (vgl. Wöhe 2002). Die Ausführung der Planung und die Selektion von Handlungsalternativen stehen unbestritten den Entscheidungsträgern eines Unternehmens zu. Entscheidungsträger sind in Hierarchiestrukturen eingeordnet, die ihnen einen Kompetenzbereich zuweisen. Oftmals orientiert sich die Planung an diesen Strukturen, die den Rahmen der Handlungsfelder und -alternativen für jeden Entscheider bzw. Planungsträger setzen. Die allgemeinen Aufgaben der Planung sind auf den Ebenen gleichermaßen vorzufinden, weil sie auf die Unternehmensplanung generell anwendbar sind und verdeutlichen, womit die Tätigkeit des Planens im Grundsatz verbunden ist (vgl. Wild 1974):  Minderung des Risikos von Fehlentscheidungen  Schaffung zukünftiger Handlungsspielräume zur Vermeidung von sogenannten Sach- und Zeitzwängen  Reduzierung von Komplexität durch Stabilisierung von Verhaltensweisen und Verhaltenserwartungen  Integration von Einzelentscheidungen in einen umfassenden Gesamtplan unter Berücksichtigung der vorhandenen Handlungsinterdependenzen Die Unternehmensplanung steht den Entscheidern als Werkzeug bereit, um ihre Absichten auf das Unternehmen zu übertragen. Dieser Sachverhalt wird als unternehmenspolitischer Willensbildungsprozess angesehen (vgl. Ulrich u. Fluri 1995). In ihrer Funktion als Vertreter des ganzen Unternehmens sehen sich die Entscheider und gleichzeitigen Planungsträger zunächst mit Bedingungen konfrontiert, die durch die eigenen Werte und Grundeinstellungen sowie die des Unternehmens geformt sind. Da moderne Unternehmen hochgradig mit ihrer Umwelt vernetzt sind, müssen auch die Erwartungen und das Wertesystem der unternehmensexternen Partner oder Akteure, der Stakeholder, ebenso berücksichtigt werden, wie die Erwartungen der Eigenkapitalgeber des Unternehmens, der Shareholder (vgl. Wöhe 2002). Aus diesem Spannungsfeld heraus wird das Selbstverständnis des Unternehmens als Unternehmenspolitik herausgebildet. In der Unternehmenspolitik sind die aktuellen Grundsätze des Unternehmens verankert. Zu diesen Grundsätzen ge-

Grundlagen der Unternehmensplanung

243

hört neben der Identifizierung der betrieblichen Leistungen und der Abgrenzung des Absatzmarktes, dem sozialen Verständnis des Unternehmens, den Verhaltensprinzipien der Mitarbeiter und dem Verhältnis zum Kapitalmarkt vor allem auch die Bestimmung der übergeordneten Ziele des Unternehmens. Obwohl als langfristig gültiger Orientierungspunkt für das Unternehmen ausgelegt, unterliegt die Unternehmenspolitik ständig wechselnden Einflüssen, die sich aus Analysen, Prognosen und Frühwarninformationen über das Unternehmen und seine Umwelt ergeben. Eingerahmt in die aus der Unternehmenspolitik entnommenen Werte und Normen sowie die Informationen zum Unternehmen und seiner Umwelt, findet die Unternehmensplanung statt (vgl. Welge u. Al-Laham 1999). Eine Übersicht zu diesem Sachverhalt kann Abbildung 4.1 entnommen werden.

Abb. 4.1 Unternehmenspolitischer Willensbildungsprozess

Die Planung soll an dieser Stelle als Bildung und Abstimmung von Zielen und den mit den Zielen verknüpften Handlungsalternativen verstanden werden. Ziele sind ein Endprodukt einer Planung, in dem sich der gewünschte zukünftige Zustand des Unternehmens widerspiegelt. Sie können normativ oder monetär sein, sind für sich selbst gesehen zunächst unabhängig, können untereinander aber mit Abhängigkeiten versehen sein. Ziele lassen sich in ein Rangverhältnis setzen, um ihre Beziehungen untereinander in einer zeitlichen Abfolge zu ordnen oder um eine Generalisierung bzw. Spezialisierung auszudrücken. Nicht alle Ziele können ungehindert durchgesetzt werden, häufig bestehen Konflikte zwischen den Zielen oder sie sind schlicht nicht realisierbar. Um eine Vergleichbarkeit der Ziele untereinander und die Erstellung einer Ordnung zu ermöglichen, müssen sie mit generellen Merkmalen versehen und beschrieben sein. Eine solche Konkretisierung der Ziele, bei der die Merkmale mit Ausprägungen belegt werden, ist auch als Operationalisierung bekannt (vgl. Welge u. Al-Laham 1999). Tabelle 4.1 geht auf die

244

Unternehmensplanung

Operationalisierung der Ziele ein, indem sie verschiedene Merkmale eines Ziels aufbereitet und mit Beispielen versieht. Tabelle 4.1 Operationalisierung der Ziele Merkmal

Beispiel

Zielinhalt (Was soll erreicht werden?)

Erhöhung des Marktanteils

Zielausmaß (Wie viel soll erreicht werden?)

5%

Zeitlicher Bezug (Wann soll etwas erreicht werden?) Ende des Geschäftsjahres 2009 Personeller Bezug (Wer ist verantwortlich?)

Geschäftsbereichsleiter Niedersachsen

Räumlicher Bezug (Wo soll die Zielerreichung statt- Regionalmarkt Bundesland Niedersachsen finden?)

Zur Veranschaulichung unternehmerischer Ziele lassen sich Marktleistungsziele (z.B. Kernprodukte), Rentabilitätsziele (z.B. Quartalsergebnis) sowie Sozialziele (z.B. Verhaltensweisen gegenüber Interessensgruppen) anführen (vgl. Ulrich u. Fluri 1995). Mit Zielen wird eine Reihe von Führungsfunktionen wirksam unterstützt. Ziele legen verbindlich fest, was für ein Zustand zu erreichen ist. Damit machen sie eine Bewertung und Auswahl der optimalen Handlungsalternativen möglich, haben einen motivierenden Charakter und eignen sich zur Steuerung und Kontrolle der Marschrichtung (vgl. Amshoff 1993). Für die Zielplanung hat Wild Anforderungen an ein Zielsystem gestellt, die Amshoffs Ansichten präzisieren (vgl. Wild 1974):  Realistik: Ziele sollten sich mit den zur Verfügung stehenden Ressourcen erfüllen lassen  Operationalität: Zielmerkmale müssen präzise bekannt sein  Ordnung: Die Beziehungen der Ziele untereinander sind zu identifizieren und münden in eine Priorisierung  Konsistenz: Widersprüche in den Zielen selbst sind auszuschließen  Aktualität: Es sind nur Ziele von Bedeutung, die zum gegebenen oder betrachteten Zeitpunkt relevant sind  Vollständigkeit: Nach Möglichkeit sollten alle Ziele erfasst werden, um unnötige Wiederholungen im Prozess zu vermeiden  Durchsetzbarkeit: Wenn Ziele nicht von den Entscheidern mitgetragen oder unterstützt werden, ist ihre Umsetzung stark gefährdet  Organisationskongruenz: Bei der Zielbildung muss Rücksicht auf die Organisation des Unternehmens genommen werden, um eine Umsetzung der Ziele einerseits, eine weitestmögliche Abdeckung der Unternehmensbereiche andererseits sicherzustellen  Transparenz und Überprüfbarkeit: Klarheit und Nachvollziehbarkeit sind eine Voraussetzung für gemeinsames Arbeiten, auch bei der Zielformulierung Die allgemeingültigen Aufgaben der Planung lassen sich konkretisieren und handlungsorientiert in einem Prozess implementieren. Dies erlaubt eine Strukturierung

Grundlagen der Unternehmensplanung

245

der Planung und macht sie für realweltliche Herausforderungen adaptierbar. Als Teil des Management-Prozesses hat Wild die Planung als Prozess der Willensbildung gesehen (vgl. Wild 1974). Im Management-Prozess werden einzelne Phasen hervorgehoben, die jedoch nicht unbedingt einer linearen Abfolge entsprechen müssen. Es kann sehr wohl zu Vor- oder Rückkopplungen der einzelnen Phasen kommen. Insbesondere die Phasen der Zielbildung und der Problemerkenntnis sowie der Problemanalyse können die Reihenfolge oft tauschen. Gegliedert wird der Managementprozess in die Gruppen der Willensbildung (Planung), der Willensdurchsetzung (Beschluss) und der Willenssicherung (Steuerung und Kontrolle). Hierzu liefert Abbildung 4.2 eine kompakte Darstellung.

Abb. 4.2 Planungsprozess (vgl. Wild 1997)

Die Willensbildung oder auch Planung wird aus der Betrachtung eines Prozesses heraus stets aufgrund eines auslösenden Ereignisses begonnen. Dieses Ereignis

246

Unternehmensplanung

kann zeitlich wiederkehrend oder bedingt durch einen bestimmten Zustand des Unternehmens und seiner Umwelt entstanden sein. Beispielsweise ist der Abschluss des ersten Quartals ein häufig in der Praxis anzutreffender Auslöser für die Planung der nächsten Periode. Eine nicht-reguläre Planungsaktivität hingegen kann zum Beispiel durch die Veränderung in der staatlichen Besteuerung eines Produkts begründet sein. Unterschiedliche Ausgangslagen können unterschiedliche Planungsarten erfordern, daher müssen im Vorfeld der Planung die groben Umstände, unter denen geplant werden soll, hinreichend bekannt sein. Weil die Planung den Anspruch der Ganzheitlichkeit verfolgt, sind die auslösenden Ereignisse nicht als alleiniger bestimmender Faktor während der Initiierung des Prozesses anzusehen. Ob in der Vergangenheit eingeschlagene Wege weiter betreten werden (kontinuierliche Fortschreibung ohne Zielveränderung) oder ob ein konzeptioneller Neuanfang auf dem Reißbrett (synoptischer Ansatz mit neuer Zielbildung) vorteilhafter ist, hängt neben dem auslösenden Ereignis zusätzlich von der Situation im Unternehmen und den Einflüssen von inneren und äußeren Faktoren ab (vgl. Kreikebaum 1993). Erst wenn die Planungsparameter gesetzt und die gedankliche sowie die organisatorische Vorbereitung abgeschlossen sind, kann mit einer der Phasen des Planungsprozesses begonnen werden. Die Formulierung von Planungszielen sowie die Analyse und Bewertung der Umwelt und ihres Einflusses auf die Zielbildung und die Realisierung der Ziele stellen oftmals den Beginn der Planung dar. Aufgeteilt in zwei Phasen innerhalb der Willensbildung wird von der Zielbildung einerseits und der Ist-Analyse der Umweltbedingungen sowie der Problemstellung andererseits gesprochen. Unter der Zielbildung werden die Aufgaben zur Zieldefinition zusammengefasst. Hierzu wird die Operationalisierung der Ziele ebenso gezählt wie die Ausformulierung und Ordnung der Ziele, eingefasst in ein Zielsystem. Zur Problemanalyse hingegen lassen sich die umfassende Sammlung, Aufbereitung und Analyse der zur Erreichung der Ziele benötigten Informationen nennen, die als Umwelt- und Unternehmensanalyse konkretisiert werden. Ebenso gilt es den aktuellen Zustand des Unternehmens und seiner Umwelt festzustellen, um eine Grundlage für die Erstellung von Planungszielen zu schaffen. Es bietet sich der SWOT-Ansatz an, der eine Stärken-Schwächen-Analyse (engl. Strengths and Weaknesses) und ChancenRisiken-Untersuchung (engl. Opportunities and Threats) der Umwelt und des Unternehmens vorschlägt. Methodisch wird dabei vor allem die Nutzwertanalyse zur Faktorgewichtung und -bewertung eingesetzt. Bei der Umweltanalyse, die sich in eine Analyse der Branche und der Konkurrenten verfeinert, gilt es kritische Faktoren zu ermitteln, die das betriebliche Umfeld des Unternehmens beschreiben. Bei der Untersuchung des Unternehmens hingegen wird ein Stärken-Schwächen-Profil genutzt, um ein möglichst vollständiges Bild vom Unternehmen zu erhalten. Die strategischen Stärken und Schwächen sind bestimmend dafür, was das Unternehmen zu leisten im Stande ist (vgl. Welge u. Al-Laham 1999). Erst wenn allen am Planungsprozess beteiligten Akteuren bewusst ist, mit welchen Herausforderungen das Unternehmen konfrontiert ist, kann die Entwicklung von Handlungsalternativen erfolgen. Im Rahmen dieser Konzeptionsphase werden

Grundlagen der Unternehmensplanung

247

verschiedene Planungsszenarien entworfen, die Lösungskonzepte für tatsächliche, aber auch für wahrscheinliche Problemstellungen beinhalten. Die Betrachtung wird so auf zukünftig auftretende Herausforderungen erweitert, was die Reaktionsfähigkeit des Unternehmens erhöht. Die möglichen Auswirkungen der modellierten Handlungsalternativen werden in die Zukunft prognostiziert, um ihren Einfluss auf die Zielerreichung abschätzen zu können. Ebenso wird auch das Unterlassen einer Handlung in die Prognose einbezogen, um Daten für einen Vergleich bereitzustellen. Hier wird deutlich, dass die Prognose nicht zwingend auf eine Zielbildung angewiesen ist, Ziele können auch aus einer Analyse der Prognosen entstehen. Das Wissen um die aktuelle Situation und mögliche Zustände des Unternehmens und seiner Umwelt in der Zukunft wird in der Phase der Bewertung dazu genutzt, um die Auswahl der für das Unternehmen vorteilhaftesten Ziele und Handlungsalternativen mit fundierten Kenntnissen zu unterstützen. Die Bewertung muss soweit wie möglich objektiv, einheitlich und nachvollziehbar sein. Die Willensdurchsetzung greift die Ergebnisse der Willensbildung auf und führt mit Hilfe der Bewertungen zu der Entscheidung, welche Ziele zu verfolgen sind und welche Handlungsalternativen zur Erreichung der Ziele genutzt werden. Der Beschluss allein genügt jedoch nicht, um die Umsetzung sicherzustellen. Während die inhaltliche Konkurrenz bei der Zielbildung abgeschwächt wurde, stehen die Ziele in dieser Phase bei der Zuteilung von Ressourcen in Konkurrenz zueinander. Es muss den Akteuren des Planungsprozesses bewusst sein, dass nicht jeder im Unternehmen ausreichend zufriedengestellt werden kann und eine bewusste Durchsetzung der Ziele erforderlich ist, um handlungsfähig zu sein. Hindernisse jeglicher Art sind daher so früh wie möglich auszumachen und zu nivellieren, um eine ungehinderte und mit breiter Unterstützung verbundene, gemeinschaftliche Arbeit auf die Ziele hin zu gewährleisten. Wenn dies nicht möglich ist, muss eine Rückkopplung zu einer der Phasen der Willensbildung erfolgen. Die Entscheidung und Durchsetzung der Ziele und Maßnahmen zu deren Erreichung ist mit der Freigabe der Planwerte und dem Beginn der Umsetzung der beschlossenen Maßnahmen auf allen Führungsebenen und den ihnen unterstellten Bereichen gleichzusetzen. Es finden nun die zur Willenssicherung erforderlichen Phasen statt, in denen die erzielten Ergebnisse im Zeitverlauf regelmäßig überprüft und mittels Abweichungsanalysen überwacht werden. Auch hier ist eine Rückkopplung nicht ausgeschlossen, wenn die im Vorfeld gemachten Annahmen und Prognosen nicht eintreffen. Um die Planung so effizient wie möglich auszuführen, ist der Prozess zu formalisieren, zu standardisieren und mit ausreichend Dokumentationen zu versehen. Die Formalisierung des Prozesses gewährleistet eine einheitliche und durchdachte Vorgehensweise, die von den Planungsträgern sicher angewendet werden kann. Dadurch erlangt der Prozess Unabhängigkeit vom Planungsgegenstand und ist übertragbar auf unterschiedliche Planungssituationen. Im Zuge der Formalisierung werden verbindliche Standards eingeführt, die den Prozess effizienter werden lassen und ihn robust machen, indem sie ihn gegen spontane Änderungen absichern.

248

Unternehmensplanung

Auf diese Weise wird die Verlässlichkeit gestärkt und die Durchlaufzeit verringert. Die Einbeziehung der Dokumentation in die Prozessunterstützung dient der nachhaltigen Informationsversorgung der Planungsträger und Entscheider. Plandaten der strategischen Ebene sind äußerst aggregierte Größen, deren Zusammensetzung und Herkunft selten aus den betrieblichen Kennzahlen des Berichtswesens abgeleitet werden können. Vielmehr muss auf unstrukturierte Daten, wie sie in Textdokumenten enthalten sind, zurückgegriffen werden, um die Ursachen und Grundlagen für in der Vergangenheit getroffene Entscheidungen zu belegen. Die Erstellung der Dokumente und die Anwendung der in ihnen enthaltenen Informationen ist bereits Teil einer anderen Disziplin, nämlich des Wissensmanagements (vgl. Kreikebaum 1993). 4.1.1.1

Strategische Planung

Die strategische Planung dient der Sicherung der Effektivität eines Unternehmens, indem Erfolgspotentiale geschaffen und erhalten werden. Die operative Planung hingegen strebt nach der Verbesserung der Effizienz eines Unternehmens, indem die vorhandenen Erfolgspotentiale genutzt werden (vgl. Gälweiler 1986). Strategische Unternehmensplanung ist in präskriptiver Sicht der Prozess, in dem eine rationale Analyse der gegenwärtigen Situation und der zukünftigen Möglichkeiten und Gefahren zur Formulierung von Absichten, Strategien, Maßnahmen und Zielen führt. Absichten, Strategien, Maßnahmen und Ziele geben an, wie das Unternehmen unter bestmöglicher Ausnutzung der vorhandenen Ressourcen die durch die Umwelt bedingten Chancen wahrnimmt und die Bedrohungen abwehrt (vgl. Kreikebaum u. Grimm 1978). Wenngleich die Unternehmensplanung zu Beginn nicht zwingend einen strategischen Charakter haben muss, wird in der Regel von der strategischen Planung auf die taktische bzw. operative Planung geschlossen (vgl. Wild 1974). Dennoch ist auch in einem gewissen Rahmen damit zu rechnen, dass die operative Planung die Umsetzung strategischer Ziele beeinflusst, weil sie durch den laufenden Produktionsprozess innerhalb eines kurzen bis mittelfristigen Zeitraums bestimmt ist und zur unmittelbaren Erhaltung der Wertschöpfung im Unternehmen dient. Bevor Aussagen zur Planung möglich sind, muss zunächst bestimmt werden, welche Planungsebene im Fokus der Betrachtung steht. Diese Gliederung der Planung stützt sich auf verschiedene Kriterien, an deren Gesamtheit sich bestimmen lässt, ob die Planung dem strategischen oder operativen Bereich zugeordnet werden kann (vgl. Steiner 1971).  Kreis der Planungsträger  Einflussgrößen  Reichweite

Grundlagen der Unternehmensplanung

    

249

Grad der Unsicherheit Informationsbezug Planungshorizont Spanne des Einflusses Detailgrad

Für die strategische Planung sind nur wenige Führungskräfte verantwortlich. Sie haben ihre Entscheidungen zwar vor den Kontrollgremien zu rechtfertigen, können diese im Grunde jedoch nach subjektiven Kriterien treffen. Die Reichweite ihrer Entscheidungen ist sehr groß, da sie das Geschehen im gesamten Unternehmen auf beliebiger Tiefe und über einen langen Zeitraum hinweg bestimmen. Dabei ist die Unsicherheit bei der strategischen Planung bedeutend, weil die Angaben über die zukünftigen Bedingungen oftmals nur sehr vage sein können. Der Grad der Unsicherheit wird auch dadurch verstärkt, dass die zur strategischen Planung notwendigen Daten zu einem Teil aus externen Quellen bezogen werden und auf langfristigen Prognosen beruhen. In gewissem Umfang jedoch wird die Unsicherheit vom hohen Detaillierungsgrad wieder kompensiert. Ihren Ursprung nimmt die strategische Planung aus der Entwicklung von Führungssystemen, die mit dem Aufkommen von Großunternehmen stattgefunden hat. Führungssysteme wurden notwendig, weil die Unternehmensgröße eine Planung und Steuerung des Wertschöpfungsprozesses durch nur eine Person zunehmend erschwerte und letztendlich unmöglich machte. Die Aufgaben mussten zunehmend auf mehrere Führungskräfte verteilt werden, wodurch sich die Notwendigkeit feiner Koordination der Tätigkeiten und einer Abstimmung der Ziele ergab. Die ersten Vertreter derartiger Führungssysteme waren die Budgetierung und das Controlling, die eine zuverlässige Verteilung der Ressourcen und Steuerung des Unternehmens anhand der wichtigsten Kennzahlen ermöglichten. In der Budgetierung werden alle Erträge und Kosten einer Periode vorweggenommen und fließen in ein Budget ein. Während eines budgetierten Geschäftsjahres wird das Budget auf einzelne Perioden heruntergebrochen und mit den IstWerten je Periode und kumuliert über die vergangenen Perioden verglichen. Durch eine Trendanalyse kann zusätzlich ausgesagt werden, ob das geplante Budget aufgrund der tatsächlichen Entwicklung eingehalten oder überschritten wird. Zur Budgetierung gehören die Planung und Kontrolle des Absatzes und der Fertigung, die Administration sowie Investitionsaktivitäten und die Liquiditätsplanung. Für die Budgetierung werden sowohl unternehmensinterne als auch -externe Daten eingesetzt, um ein möglichst vollständiges Bild der Lage vermitteln zu können. Die Budgetierung wurde im Laufe der Zeit ständig Verbesserungen unterzogen und ist bis heute ein wertvolles und in der Wirtschaft breitflächig eingesetztes Führungsinstrument (vgl. Hax und Majluf 1991). Das Controlling kommt der Notwendigkeit nach ständiger Kostenkontrolle und Kostensenkung nach. Mit diesem Führungsinstrument werden die Kennzahlen des Unternehmens laufend überwacht und ausgewertet, insbesondere jedoch die der Kostenrechnung. Darin wird das Unternehmen in eine Kostenstruktur nach Kos-

250

Unternehmensplanung

tenstellen, Kostenarten und Kostenträgern gegliedert. Die Maßnahmen des Controllings dienen jedoch auch der Überwachung der Leistung des Unternehmens und seiner Bereiche. Daher werden Kennzahlen nicht nur für die Kosten, sondern auch aus der Finanzbuchhaltung und dem Verkauf gebildet. Durch den Einsatz von Kennzahlen sind Vergleiche von Organisationseinheiten mit anderen sowohl innerhalb des eigenen Unternehmens als auch bei Konkurrenten möglich. Relevante Kennzahlen des Controllings lassen sich am Beispiel der United Technologies Corporation in Tabelle 4.2 aufzeigen (vgl. Hax u. Majluf 1991). Tabelle 4.2 Kennzahlen des Controllings der United Technologies Corporation Wachstumskennzahlen

Aktiva-Kennzahlen

Zusammengesetzte Kennzahlen

Umsatz

Gesamtkapital

Gesamtkapitalrendite

Aufträge

Außenstände

Umsatzrendite

Kosten der zu verkaufenden Waren

Bestände

Kapitalumschlag

Kosten Forschung und Entwicklung

Genehmigte und getätigte Investitionen

Inkassoperiode

Gewinn vor Steuern

Zahlungen der Abnehmer

Lagerumschlag

Die starke Kennzahlenfokussierung in der Budgetierung und im Controlling hat in den Unternehmen jedoch zu einer immer kurzfristiger werdenden Planung geführt, bei der die Gewinne der nächsten Periode im Vordergrund standen. Ein Ausweg aus der relativ kurzfristigen Budgetierung ist in den Jahren um 1950 in Form der langfristigen Planung gefunden worden. Bei diesem Führungsinstrument werden die Umweltbedingungen als relativ stabil angenommen und in die Zukunft fortgeschrieben. Darauf aufsetzend sind langfristige Ziele für das gesamte Unternehmen zu formulieren. Ausgehend von einer mehrjährigen, auf Vergangenheitswerten basierenden Prognose des Umsatzes werden alle Aktivitäten ebenfalls fortgeschrieben, um aus diesen Projektionen einen Finanzplan zu erstellen (vgl. Hax u. Majluf 1991). Der an die Prognose anschließende Planungsprozess wird Bottom-Up ausgeführt und mündet in langfristigen Budgets und einer zeitraumbezogenen Investitions- und Wirtschaftlichkeitsberechnung. Die Umsatzprognose erwies sich im Laufe der Jahre nicht als ausreichend zuverlässig, weil sie von der Annahme des stetig wachsenden Markts und einer wachsenden Nachfrage ausging. Daher wurde die Dynamik der Gesamtmärkte untersucht und der Marktanteil als Verbindung zum Umsatz identifiziert. Dieser Schritt bedeutete einen Umschwung vom unternehmensintern bestimmten Umsatz als Ausgangspunkt für die Ermittlung der Planwerte hin zur Einschätzung der äußeren Faktoren wie Marktentwicklung und Veränderungen im Marktanteil. Sie bekamen nun erhebliches Gewicht bei der Bildung von zukünftig zu erreichenden Zielen. Solange die Trendexploration aufgrund der kontinuierlich einheitlichen Vergangenheitsdaten leicht möglich war, konnte die langfristige Planung mit gutem Ergebnis eingesetzt werden. Als sich die Umweltbedingungen jedoch substantiell änderten, war es mit der langfristigen Planung nicht mehr möglich, Entscheidun-

Grundlagen der Unternehmensplanung

251

gen für die Zukunft vorzubereiten. Zudem hat auch die langfristige Planung die Unternehmensbereiche voneinander durch die beschränkend wirkende Investitions- und Wirtschaftlichkeitsberechnung einzelner Projekte isoliert. Um als Einheit in allen Bereichen gleichgesteuert zu werden, sind Unternehmen nach außen hin zu schwerfällig und nach innen zu vielfältig mit ihren bunt durcheinander gemischten Produkten und Absatzmärkten geworden. Aufgrund der veränderten Marktbedingungen, die statt einer zementierten Einheitlichkeit eine stärkere Unterscheidung und Individualisierung der Bereiche innerhalb der großen Mischkonzerne erforderte, hat General Electric (GE) ab 1970 das von McKinsey entworfene Konzept der Branchensegmentierung eingeführt, indem es strategische Geschäftseinheiten (SGE) bildete. Es war nun nicht mehr die Richtung des gesamten Unternehmens für alle Geschäftseinheiten gleichermaßen bindend. Stattdessen wurde für jede Geschäftseinheit eine eigene Strategie festgelegt, die den individuellen Bedingungen gerecht wurde (vgl. Hax u. Majluf 1991). Den Prozess der SGEPlanung zeigt Abbildung 4.3.

Abb. 4.3 Verfahren der Geschäftsstrategieplanung

Jede SGE bildet ein nahezu selbstständiges Unternehmen im Unternehmen, weil sie mit einem eigenen externen Markt für Güter und Dienstleistungen sowie unabhängigen Zielen und Strategien ausgestattet wird. Zur Bestimmung einer SGE werden insbesondere Kriterien hinzugezogen, die den Markt einer SGE charakterisieren. Dazu zählt auch die strategische Einheitlichkeit im Produkt- und Marktsegment (vgl. Kreikebaum 1993). Ausgehend von strukturellen Vorbedingungen, die im Geschäftsauftrag zur Geltung kommen, werden eine Geschäftsstrategie und allgemeine Aktionsprogramme zur Strategieumsetzung formuliert. Darauf aufbauend lassen sich strategische Programme für die SGE entwickeln und bewerten. Sie sind darauf ausgelegt, mittels geeigneter Maßnahmen die strategischen Vorteile einer SGE zu sichern und auszubauen. Die Unternehmensleitung versieht die Programme mit Ressourcen (Budgets) und legt Leistungsmaßstäbe an. Im Anschluss daran erfolgt die Budgetierung zunächst auf der Ebene der SGE, anschließend werden die Budgets aller SGE auf der Unternehmensebene konsolidiert. In den Budgets sind die strategischen und operativen Verpflichtungen festgehalten, um die derzeitige Position der SGE zu sichern und die Entwicklung voranzutreiben (vgl. Hax u. Majluf 1991). Eine jährliche Überprüfung der Strategien, Pro-

252

Unternehmensplanung

gramme und Budgets passt die Planung an Veränderungen der inneren und äußeren Faktoren an und sichert sie gegen die Gefahr der Starrheit ab. Mit der Strategiedefinition kamen erstmals Gedanken über langfristig gültige Absichten und Handlungsempfehlungen auf, um Wettbewerbsvorteile dauerhaft zu realisieren. Die Branchenstrukturanalyse nach Porter zählt mit ihrer Methodik zu den bekanntesten Vertretern der Wettbewerbsanalyse und Strategiedefinition. Porter legte drei Hauptstrategien fest, die ein Unternehmen verfolgen kann, um sich im Wettbewerb zu behaupten. Die Strategien gliedern sich in Kostenführerschaft, Differenzierung und Konzentration auf Schwerpunkte. Bei der Kostenführerschaft nutzt das Unternehmen die Präferenz der Kunden nach immer günstigeren Produkten. Dies trifft zum Beispiel auf den Vertrieb von Mineralwasser zu, das im Niedrigpreissegment angeboten wird und hochgradig substituierbar ist. Die Differenzierung bietet sich an, um den Kunden ein durch seine Eigenschaften aus der Masse herausragendes Produkt zu bieten, wie es zum Beispiel bei hochwertigen Küchenmessern der Fall ist. Die Spezialisierung hingegen nutzt Vorteile einer Nische und bietet höchst individuelle Produkte für bestimmte Käufergruppen an, Hersteller sportlicher Automobile sind dafür bekannte Vertreter. Strategien können differenzierter als die übergeordnet anzusehenden Wettbewerbsstrategien nach Porter ausfallen. Verschiedenen Kategorien zugeordnet, lässt sich ihr primärer Zweck für das Unternehmen oder die SGE hervorheben (vgl. Hax u. Majluf 1991). Je präziser die Strategien nach und nach ausgestaltet werden, desto klarer werden ihr Einflussbereich und die Reichweite der strategischen Entscheidungen. Im Grunde ließen sich strategische Entscheidungen durch alle nachfolgenden Ebenen fortschreiben, um die Ursache-Wirkung-Nutzenkette fortzuführen. Aus diesen Szenarien können die Tragweite und die Wirkung einer Strategie bis in feinste Unternehmensbereiche nachvollzogen werden. Der Vergleich von mehreren Szenarien gibt den Entscheidungsträgern die Möglichkeit, die Vor- und Nachteile einer strategischen Richtungsvorgabe klarer in die Strategiebestimmung einfließen zu lassen. Eine Grundlage hierfür ist jedoch ein wirksames Controlling. Nur dieses ist in der Lage, die für die Ausgestaltung notwendigen Daten zu liefern. Im Controlling sind Kennzahlensysteme etabliert, die eine breite und umfassende Einflussnahme auf Planwerte möglich machen. Schließlich sind es die Kennzahlen, die eine Aussage über den Nutzen einer Strategie erst möglich machen und die Entscheidungen der Unternehmensführung vor Gremien und Investoren legitimieren. Aufgrund der enormen Bedeutung der Daten des Controllings ist zwingend darauf zu achten, dass die im Controlling geschaffene Basis hochgradig verlässlich und sowohl bis in die kleinsten Betrachtungsobjekte hinein präzise ist, als auch vollständig harmonische, übergeordnete Sicht auf Aggregationsebenen zulässt (vgl. Lisges u. Schübbe 2007).

Grundlagen der Unternehmensplanung

253

 Marketingstrategien – – – – – –

Markterschließung Export vorhandener Produkte Marktdurchdringung Neue Produkte / Neue Märkte Neue Produkte / Vorhandene Märkte Vorhandene Produkte / Neue Märkte

 Integrationsstrategien – –

Rückwärtsintegration Vorwärtsintegration

 Auslandsstrategien – – –

Aufbau einer Geschäftseinheit im Ausland Ausbau von Produktionsanlagen im Ausland Lizenzvergaben ins Ausland

 Logistische Strategien – – – – –

Kapazitätsausweitung Rationalisierung des Marktes Rationalisierung der Produktion Rationalisierung der Produktlinie Rationalisierung des Vertriebs

 Effizienzstrategien – – –

Effizienz der Methoden und Funktionen Herkömmliche Kostensenkungseffizienz Technologische Effizienz

 Abschöpfungsstrategien – – – – –

Auflösen der Geschäftseinheit Aufrechterhalten Kleine Perle Reines Überleben Zögern

Die gravierendsten Nachteile der strategischen Geschäftseinheitenplanung ergeben sich durch eine unvollkommene Segmentierung der Unternehmensbereiche und auf der Unternehmensebene isoliert wirkende Aktionsprogramme. Die Schaffung einer SGE im Unternehmen ist nur in wenigen Fällen gelungen, weil ein präziser Schnitt durch die Bereiche des Unternehmens kaum durchzuführen ist. Die Tren-

254

Unternehmensplanung

nung eines Unternehmens in autonome Einheiten ist unternehmerisch dann nicht sinnvoll, wenn zwischen den Geschäftseinheiten durch die Ressourcennutzung und Leistungserbringung große Kontaktflächen bestehen. Diese werden mit der Bildung von SGE auseinandergerissen, ohne dass dies durch die Wertschöpfung im Unternehmen begründet ist. Versuche, die Organisationsstruktur eines Unternehmens an die SGE anzupassen, sind gescheitert oder haben die SGE von Beginn an in ihrer strategischen Ausrichtung geschwächt, weil die Organisationsstruktur nicht mit der Führung einer SGE zu vereinbaren gewesen ist. Als Folge dessen wurden Ressourcen nicht optimal verteilt, Synergien blieben ungenutzt und oft wurde die strategische Ausrichtung des gesamten Unternehmens bei der Strategiefindung einer SGE nicht ausreichend berücksichtigt. Weil den SGE dennoch viel Autonomie gewährt wurde, kam es zudem häufig zu Suboptima auf Unternehmensebene, denn ein für die SGE vorteilbringendes Aktionsprogramm muss nicht unbedingt auch dem gesamten Unternehmen dienen (vgl. Hax u. Majluf 1991). Der Autonomiegedanke ist bei der Schaffung der SGE leitend gewesen, doch ist die Eigenständigkeit aus heutiger Sicht zu weit in die Führung des gesamten Unternehmens vorgedrungen. Die Unternehmensleitung musste zu viel Kontrolle und Verantwortung an die Führung der SGE abgeben, wodurch die Ressourcenherrschaft an viele gleichberechtigte Einheiten abgegeben und Abstimmungsprozesse unterdrückt wurden. Zudem waren die Hierarchiestrukturen in den Unternehmen nicht auf die Bildung von SGE vorbereitet, wodurch sich Konfliktpotential ergab. Aufgrund dessen wurde oberhalb der strategischen Geschäftseinheitenplanung die übergreifende Konzernplanung eingesetzt und die Aufbauorganisation in die funktionale und in die strategische Organisationshierarchie unterteilt. Damit waren die Geschäftsprozessverantwortlichen weiterhin ihren organisatorischen Ebenen zugeordnet, hatten aber gleichzeitig die Aufgabe, die strategischen Vorhaben des Unternehmens und der SGE umzusetzen. Die Unternehmensstrategieplanung wurde in mehrere Ebenen untergliedert und förderte die Kommunikation zwischen der Konzernführung, der SGE und den Funktionsbereichen. Der Prozess spiegelt sich in Abbildung 4.4 wider.

Grundlagen der Unternehmensplanung

255

Abb. 4.4 Unternehmensstrategieplanung Unter

Obwohl die Unternehmensstrategieplanung Elemente der strategischen Geschäftseinheitenplanung aufweist und dieser im Zyklus sehr ähnelt, so ist in ihr die integrative Komponente viel stärker ausgebildet. Die Unternehmensleitung bildet parallel zu den strategischen Geschäftseinheiten eine übergreifende Vision des Unternehmens heraus, die im Unternehmensauftrag den zentralen Zweck des Unternehmens und seiner SGE bestimmt. In der Unternehmensphilosophie und Unternehmenspolitik kommen die Wertvorstellungen des Unternehmens und seiner Führung zum Ausdruck. Ist die allgemeine Grundhaltung des Unternehmens und seine gegenwärtige und zukünftige Position am Markt beschrieben, werden die strategische Grundhaltung des Unternehmens und die Planungsrichtlinien geformt. Dies geschieht unter der Zuhilfenahme von Analysen des Umfelds auf Konzernebene und unternehmensinterner Prüfungen. Dies äußert sich in strategischen Unternehmensstoßrichtungen, Planungsanforderungen und Leistungszielen sowie in Planungskalendern, Planungsformaten und der Bildung von Verantwortungsbereichen (vgl. Hax u. Majluf 1991). Auch bei der Unternehmensstrategieplanung wird der Geschäftsauftrag weiterhin auf der Ebene der strategischen Geschäftseinheiten formuliert, bei der Erarbeitung der Geschäftsstrategie jedoch fließen die Richtlinien aus dem Unternehmensauftrag und der strategischen Grundhaltung des Konzerns mit ein. Einer auf Abstimmung der Strategie der SGE mit den Funktionsbereichen folgt die Prüfung der Aktionsprogramme auf SGE- und Funktionsbereichsebene durch die Unternehmensführung. Alle von der Planungsaufgabe betroffenen Führungskräfte haben

256

Unternehmensplanung

in diesem Planungsschritt teilzunehmen, um die Entwicklungsrichtung gemeinsam mit allen Verantwortlichen zu erarbeiten, Widerstände abzubauen und Gemeinsamkeiten zu fördern (vgl. Hax u. Majluf 1991). Ist der Aktionsrahmen gesetzt, lassen sich anschließend durch die SGE und Funktionsbereiche gemeinsam strategische Programme formulieren. Auch hier ist die gemeinschaftliche Arbeit von SGE und Funktionsbereich hervorzuheben, der Konsens über die gemeinsame Wertschöpfung hat enorme Bedeutung. Auf Konzernebene werden die Programme bewertet, mit den strategischen Rollen verglichen und auf Überschneidungen oder Abhängigkeiten hin untersucht. Sind die Analysen abgeschlossen, können die strategischen Programme mit Ressourcen und Leistungsmaßstäben versehen werden. Genehmigte Programme werden im Rahmen des Finanzzyklus mit strategischen bzw. operationalen Budgets versehen und von der Unternehmensleitung überwacht (vgl. Hax u. Majluf 1991). Die Abbildung 4.5 visualisiert diesen Prozess.

Abb. 4.5 Integration des Führungs- und Kontrollprozesses (vgl. Hax u. Majluf 1991)

Doch auch die strategische Unternehmensplanung birgt Risiken. Durch die vielen Schnittstellen und intensiven Abstimmungsprozesse droht ein gigantisches Gebilde der Bürokratie zu entstehen, das die eigentliche Aufgabe zunehmend ver-

Grundlagen der Unternehmensplanung

257

schleiert und letztendlich den gesamten Planungsprozess hemmt. Auch besteht die Gefahr der Isolation der Planung im Unternehmen, wenn sie nicht mit anderen Führungsprozessen vereint und über alle Hierarchieebenen in der Organisation ausgebreitet wird. Daher ist die Integration der Planungs- und Führungsprozesse ein wichtiger Aspekt des strategischen Managements. Die Budgetierung stellt sich als Knoten der beiden Managementaufgaben dar, denn die im Planungsprozess definierten Leistungsmaßstäbe und Budgets sind im Rahmen des Führungsprozesses zu überwachen, zu analysieren und zu kontrollieren. Die kontinuierliche Ergänzung von Planung und Kontrolle zeigt sich auch im betrachteten Zeitraum. Während die Planung in die Zukunft schaut, bewertet die Führung die historischen Ergebnisse und lässt Rückschlüsse auf notwendige Veränderungen in den geplanten Aktionsprogrammen zu (vgl. Hax u. Majluf 1991). 4.1.1.2

Operative Planung

Im Gegensatz zur strategischen Planung kann die operative Planung auf klare Vorgaben verweisen, die sich für sie aus der operativen Tätigkeit selbst, zum Beispiel durch langfristige Kundenaufträge, Vorgaben des Systems im Bestellwesen und der Produktion oder durch Richtlinien aus der strategischen Planung ergeben. Die operative Planung hat stark ausführenden Charakter, denn es ist ihr in der Regel nicht vergönnt, selbständig weitreichende Planungsziele zu setzen. Steinmann spricht hier auch von der Vollzugsfunktion, in der die operative Planung zur strategischen Planung steht (vgl. Steinmann u. Schreyögg 1993). Ebenso sind die Handlungsalternativen stark eingegrenzt, weil sie einerseits über einen geringeren Einflussbereich verfügt, der das kurzfristige Überleben des Unternehmens zu sichern hat, sich andererseits aber auch hier nach strengen Vorgaben der strategischen Planung (z.B. dem Budget) richten muss, um die langfristigen Erfolgspotentiale abzusichern. Aufgabe der operativen Planung ist es letztlich, die strategischen Entscheidungen in operative Maßnahmen in den Teilbereichen des Unternehmens umzuwandeln (vgl. Kreikebaum 1993, Steinmann u. Schreyögg 1993). Ein Nachteil der operativen Planung ist darin bedingt, dass Ungenauigkeiten, die in der strategischen Planung akzeptiert wurden, spätestens in der operativen Planung konkretisiert werden müssen. Daher ist es zu vermeiden, Probleme an nachfolgende Einheiten weiterzugeben, in der Hoffnung, dass diese irgendwie gelöst werden. Die Kommunikation und gemeinschaftliche Erarbeitung einer Lösung ist zielführender. Als weiterer Punkt müssen Freiräume geschaffen werden, die es der operativen Planung erlauben, auf die aktuelle Handlungssituation zu reagieren und gleichzeitig Maßnahmen umzusetzen, die der Erfüllung der strategischen Programme dienen. Um unmittelbar auf der operativen Ebene Lösungen zu konzipieren, ohne dass ein bürokratischer Prozess begonnen wird, müssen Handlungsspielräume gewährt werden (vgl. Steinmann u. Schreyögg 1993). In der operativen Planung wird zwischen der Standard- und der Projektplanung unterschieden. Die Standardplanung dient der Aufrechterhaltung des Unterneh-

258

Unternehmensplanung

mens und äußert sich in der Planung des Realgüterprozesses (das Produktionsprogramm und seine Konsequenzen für die betrieblichen Funktionsbereiche) und des Wertgüterprozesses (monetäre Konsequenzen der Handlungsprogramme im Realgüterprozess). In Projekten wird auf die Änderungen eingegangen, die aus den strategischen Vorgaben resultieren. Alle Aktivitäten werden in Projektplänen erfasst und bis zur Handlungsreife konkretisiert (vgl. Steinmann u. Schreyögg 1993). Im Gegensatz zur strategischen Planung ist die operative Planung in ihrer Methodik stark geprägt vom Bereich, in dem sie eingesetzt wird. So wird in der Produktionsplanung gänzlich anders vorgegangen als in der Personalplanung. Gemein ist allen Planungsebenen und Planungsbereichen, dass sie von der Ergebnis- und Finanzplanung durchgängig unterstützt werden, um Wertziele zu formulieren und die monetären Wirkungen von strategischen und operativen Maßnahmen darzustellen (vgl. Hahn u. Taylor 2006). Eine Einordnung der Planungsebenen ist aus Abbildung 4.6 zu entnehmen.

Abb. 4.6 Unternehmensplanung

Als Beispiel für die operative Planung soll an dieser Stelle die Planung des Funktionsbereichs Personal angeführt werden. Das Personalmanagement wird von 6FKRO]DOVÄGLHV\VWHPDWLVFKH$QDO\VH%HZHUWXQJXQG*HVWDOWXQJDOOHU3HUVRQDlDVSHNWH HLQHV 8QWHUQHKPHQV³ 6FKRO]   JHVHKHQ $XIJDEe des Personalmanagements ist es, personalwirtschaftliche Handlungsziele aus den strategischen Zielen des Unternehmens abzuleiten und das Erreichen dieser Ziele sicherzustellen (vgl. Drumm 2006). Personalmanagement ist demnach weit mehr, als die Erfassung von mitarbeiterbezogenen Daten. Ebenso wenig darf es allein für sich be-

Grundlagen der Unternehmensplanung

259

trachtet werden, auch wenn Personaldaten in den Unternehmen wegen des Datenschutzes oft stark von den übrigen Daten des Unternehmens isoliert werden. Von der Art, wie ein Unternehmen mit seinen Mitarbeitern umgeht, lässt sich auf die Personalphilosophie schließen. Umgekehrt formuliert ist dies nicht weniger zutreffend: Die Leitlinie zum Personalmanagement wird von der Personalphilosophie bestimmt, in der die Bedeutung des Personals für ein Unternehmen enthalten ist (vgl. Müller-Christ 2005). Das Personalmanagement kann vor unterschiedlichen Aufgaben stehen, je nachdem ob Personal lediglich zu verwalten ist, das Personal als Mitarbeiter gesehen wird und damit zu gestalten ist, oder das Personal auch Mitunternehmer ist, demgegenüber es eine Dienstleistung zu erbringen gilt (vgl. Müller-Christ 2005). Beispielhaft lassen sich in diesem Zusammenhang zwei Unternehmenskonzepte anführen. Zum einen eine Bäckereikette mit einer großen Zahl an Bäckereifilialen und zum anderen ein Beratungshaus für Unternehmenssoftware. Die Bäckereikette wird hauptsächlich gering qualifiziertes Personal in großer Menge einstellen, das zu verwalten ist. Anders sind die Anforderungen an das Personalmanagement des Beratungshauses mit seinen hoch spezialisierten Mitarbeitern, die von der Personalabteilung eine Dienstleistung erwarten. Das Personal als die Gesamtheit der Arbeitnehmer eines Unternehmens hat sich, wie andere Bereiche eines Unternehmens auch, Zielen unterzuordnen (vgl. Schanz 2000). In Abstimmung mit der Personalphilosophie lassen sich die von Kosiol bekannten Sach- und Formalziele auch für die Personalwirtschaft aufstellen (vgl. Schanz 2000), die hauptsächlich aus der Personalphilosophie sowie wirtschaftlichen und sozialen Zielen abgeleitet werden (vgl. Olfert 2006). Auch wenn sich Unternehmen hinsichtlich ihrer Sach- und Formalziele unterscheiden mögen, so sind für sie dennoch die gleichen Primärprobleme der Personalwirtschaft zu lösen. Diese Primärprobleme lassen sich nach Kossbiel in die Verfügbarkeit und in die Wirksamkeit von Personal gliedern (vgl. Kossbiel 1994). Eine stark auf das operative Geschäft ausgerichtete Überlegung formulierte Freund, der die Hauptaufgabe des betrieblichen Personalwesens darin sieht, „das erforderliche Personal in allen Unternehmensbereichen, in erforderlicher Zahl, in fachlicher, menschlicher und gesundheitlicher Eignung, termingerecht am rechten Ort, unter Berücksichtigung langfristiger Wirtschaftlichkeit im Rahmen der unternehmerischen Zielsetzungen, d.h. unternehmensgemäß, und der menschlichen Erwartungen und Bedürfnisse der Mitarbeiter, d.h. mitarbeitergemäß zur Verfügung zu stellen, einzusetzen und zu erhalten“ (Freund 2003). Daraus wird ersichtlich, dass die Personalwirtschaft eine Querschnittsfunktion ist, die alle Bereiche eines Unternehmens tangiert. Gleichzeitig folgt das Personalmanagement dezentralen Tendenzen, so dass Gestaltungsfreiräume für untergeordnete Organisationseinheiten beim Abgleich der Zielvereinbarungen mit den strategischen Personalzielen geschaffen werden sollten (vgl. Reichard 2001). Ein wesentliches Teilgebiet des Personalmanagements ist die Personalplanung. Die Personalplanung umfasst alle Tätigkeiten, die von der Planung der Personalmenge, der Qualität des Personals und der Maßnahmen zur Beeinflussung der Per-

260

Unternehmensplanung

sonalstrukturen betroffen sind (vgl. Müller-Christ 2005). Nach Kolb ist es „das systematische Vorausdenken zukünftiger Handlungen zum Personalgeschehen im Unternehmen“ (Kolb 1998). Das Ziel ist die Übertragung der strategischen Unternehmensziele auf den Personalsektor und die systematische Vorbereitung des Personals auf zukünftige Anforderungen, so dass eine Umsetzung der aus den Zielen abgeleiteten Maßnahmen in bester Weise erfolgt (vgl. Schanz 2000). Dabei darf der vom Gesetzgeber festgelegte Rahmen nicht überschritten werden, wodurch die möglichen Handlungsalternativen eingeschränkt und einzuhaltende Parameter zementiert werden (vgl. Olfert 2006). Letztendlich ist aber unter den gegebenen Bedingungen die Wirksamkeit und Verfügbarkeit des Personals zu optimieren (vgl. Kossbiel 1994). Hinter dem Begriff Personalplanung verstecken sich weitere Segmente, die beispielsweise auf die Planung des Bedarfs, der Beschaffung, des Einsatzes, der Entwicklung, der Führung, der Freisetzung und der Kosten des Personals ausgerichtet sind (vgl. Reichard 2001). Die Verzahnung dieser Segmente ist sehr hoch und multilateral, weshalb nur eine integrierte und vollständige Betrachtung des Personalsektors zielführend sein kann (vgl. Albert 2002). Externe wie interne Einflussfaktoren sind konsequent im Planungsmodell zu berücksichtigen, um Ziele und Maßnahmen den Umweltbedingungen anzupassen (vgl. Drumm 2006). Ein Vorgehensmodell zur Personalplanung kann in Anlehnung an Müller-Christ gegeben werden und wird in Abbildung 4.7 dargestellt (vgl. Müller-Christ 2005). In Abhängigkeit von den personalpolitischen Leitlinien eines Unternehmens wird die Personalbestandsplanung vorbereitet. Anlass für die Personalplanung sind zumeist Veränderungen im Produktionsprogramm oder regelmäßig wiederkehrende Ereignisse wie beispielsweise der Abschluss des zweiten Quartals. Neben der Formulierung des Planungsanlasses gehört zur den vorbereitenden Aktivitäten die Identifikation von Determinanten des Planungsobjekts sowie der grundlegenden Planungsparameter, zum Beispiel des Planungshorizonts, der Einflussfaktoren, der Bezugsgrößen und der einzusetzenden Planungs- und Schätzverfahren (vgl. Springer 2006). Sind die Rahmenbedingungen für den Planungsprozess gesetzt, lassen sich die gegenwärtigen und zukünftigen Anforderungen an das Personal formulieren und in möglichst homogene Tätigkeitsgruppen zusammenfassen (vgl. Springer 2006). Im Idealfall kann jede Tätigkeit im Unternehmen durch einen Arbeitsplatz dargestellt werden, indem die Leistungsbeschreibung mit einer Stelle in der Organisationshierarchie verknüpft wird (vgl. Jetter 2003). Eine Betrachtung der Leistungsanforderungen ist im Regelfall dynamisch und muss mit der Zeitachse verknüpft sein, weil sie im Zeitverlauf signifikanten Veränderungen unterliegen können. Daher ist es sinnvoll, Leistungsanforderungen in Zeitscheiben zusammenzufassen und ihnen so einen Gültigkeitszeitraum zuzuweisen, in denen sie unverändert sind (vgl. Edinger et al. 2008).

Grundlagen der Unternehmensplanung

261

Abb. 4.7 Vorgehensmodell der Personalplanung

Aus den vorbereiteten Daten lassen sich sowohl qualitative als auch quantitative Soll-Werte ermitteln. Durch eine Kombination von Arbeitsplatzbeschreibung und statistischer Analyse lässt sich in Erfahrung bringen, welche Tätigkeiten von wievielen Personen in welchen Unternehmensbereichen wahrzunehmen sind. Die Anzahl der Personen wird üblicherweise in Arbeitszeitkapazitäten ausgedrückt, während die Qualität der zu erbringenden Leistung durch die möglichen Qualifikationen einer Person übereinstimmend beschrieben ist (vgl. Drumm 2006). Bei Personalstrukturen mit geringerer Individualität der Tätigkeiten wird die benötigte Menge an Arbeitskräften einer bestimmten Ausprägung durch statistische Verfahren geschätzt. Analog der Leistungsbeschreibung wird der SollPersonalbestand ebenfalls zu einem Zeitpunkt bzw. für einen Zeitraum ermittelt. Bei der Berechnung des Soll-Werts fließen neben der Leistungsbeschreibung auch Werte aus externen und internen Kontextfaktoren, beispielsweise von der Fehlzeitenanalyse oder dem Ar Arbeitsrecht ein (vgl. Scholz 2000). Die Art und Weise der Soll-Personalbestandsberechnung ist maßgeblich für die Bestimmung des Ist-Personalbestands. Es muss eine Vergleichbarkeit von Sollund Ist-Werten sichergestellt sein, damit es prinzipiell möglich ist, personalwirtschaftliche Maßnahmen zur Veränderung des Ist-Personalbestands zu entwickeln und die Wirksamkeit anhand eines Soll-Ist-Vergleichs zu überwachen. Der IstPersonalbestand stellt die gegenwärtige Personalstruktur dar und wird ebenfalls in die Zukunft fortgeschrieben, da auf den Ist-Personalbestand auch Faktoren einwirken und dessen Struktur im zeitlichen Verlauf verändern (vgl. Olfert 2006). Die Ursachen und Wirkungen der personalbestandsverändernden dernden Faktoren sind of oft-

262

Unternehmensplanung

mals bereits zum Erhebungszeitpunkt bekannt, so dass eine Fortschreibung des Ist-Personalbestands in die Zukunft möglich ist. Zu diesen Einflussfaktoren gehören zum Beispiel organisatorische Änderungen, demografische Einflüsse, Personalentwicklungsmaßnahmen, Arbeitszeitanpassungen, feststehende sowie unabsehbare Abwesenheiten, interne Versetzungen und Austritte (vgl. Schanz 2000). Neben der Bestimmung des gegenwärtigen Ist-Personalbestands ist daher die Prognose des zukünftigen Ist-Personalbestands durch entsprechende Berechnungen zum Ersatz- und Stellenbedarf für die quantitative Personalplanung erforderlich (vgl. Reichard 2001). Sind der Soll-Personalbestand ermittelt und der Ist-Personalbestand bestimmt worden, so kann durch einen Abgleich der Bestände der Personalbedarf berechnet werden. Die Personalbedarfsplanung legt fest, wie sich die Personalstruktur zu ändern hat, damit das Personal den Anforderungen des Unternehmens gerecht wird, also wie viele Mitarbeiter, mit welcher Qualifikation, zu welchen Zeitpunkten an welchen Orten zur Realisierung des geplanten Produktions- und Leistungsprogramms vorhanden sein müssen (vgl. Schanz 2000). Die Personalbedarfsplanung wird auch als das zentrale Element des Personalmanagements beschrieben (vgl. Müller-Christ 2005). Sie ist die Grundlage der gesamten Personalplanung, nach der sich alle übrigen personalwirtschaftlichen Teilbereiche auszurichten haben (vgl. Springer 2006). Die Personalbedarfsplanung ist auch das Bindeglied zwischen Produktions- und Absatzplanung und der Personaleinsatzplanung. Aus ihr geht hervor, ob der Bestand an Mitarbeitern erhöht, verringert oder konstant gehalten werden muss, damit der Zielzustand erreicht und die Personalkapazitäten des Unternehmens mittel- und langfristig optimal genutzt werden. Dabei wird nicht nur der Einsatzbedarf an Personal bestimmt, sondern auch zum Beispiel der Reservebedarf berechnet, der sich aus den Abwesenheiten der Mitarbeiter ergibt. Ebenso wird der Ersatz- oder Neubedarf an Mitarbeitern bzw. der Freistellungsbedarf bei einer Bestandsreduzierung geplant (vgl. Drumm 2006). Die Berechnung des Netto- oder Soll-Personalbedarfs kann der Abbildung 4.8 entnommen werden. Um auf einen zur Wertschöpfung im Unternehmen erforderlichen Bestand an Personal zurückgreifen zu können, müssen geeignete Maßnahmen zum Abgleich von Ist- und Soll-Werten beschlossen werden. Weder der Ist- noch der SollBestand sind als Festwerte anzunehmen, da beide durch Maßnahmen beeinflusst werden können (vgl. Drumm 2006). So kann zum Beispiel der Soll-Bestand durch optimierte Produktionsverfahren reduziert werden, während sich der Ist-Bestand durch Personalfreistellungen verringern lässt. Welche Maßnahme zur Personalbestandsveränderung eingesetzt wird, hängt einerseits vom zu erreichenden Ziel ab und wird andererseits von den Eigenschaften der Maßnahme selbst determiniert. Zu diesen Eigenschaften zählen beispielsweise die Art und Intensität der Maßnahme, die mit der Durchführung verbundenen Kosten und die zeitliche Verzögerung bis zum Einsetzen der Wirkung und der Zeitspanne ihrer Dauer. Auch sekundäre Effekte der Maßnahme sind zu beachten, die vielleicht nicht beabsichtigt sind, aber dennoch gleichzeitig auf das Personal einwirken (z.B. Motivationsverlust). Auf einer höheren Ebene kann eine Maßnahme sogar Einfluss auf das

Grundlagen der Unternehmensplanung

263

Human Capital Management nehmen und sich damit auf die Bilanzierung der Intangible Assets auswirken (vgl. Jochmann u. Gribig 2007). Darum ist im Vorfeld eine Simulation der Auswirkungen eines Maßnahmenpakets auf das Personal unbedingt erforderlich.

Abb. 4.8 Ermittlung des Soll-Personalbedarfs

Die Ergebnisse aus der Personalbedarfsplanung werden an die Personalbeschaffung weitergegeben (vgl. Springer 2006). Sämtliche beschlossenen Maßnahmen müssen permanent anhand von Kennzahlen überwacht werden. Nur so ist zeitnahes Reagieren auf Veränderungen möglich, da die Planung zu einem großen Teil auf Schätz- und Erfahrungswerten beruht und somit Abweichungen von der tatsächlichen Entwicklung unvermeidbar sind. Ausdrucksstarke, auf den zu überwachenden Bereich konzentrierte Kennzahlen müssen im Vorfeld bestimmt werden, damit der Kern eines Sachverhalts wirksam überwacht und gesteuert werden kann. Globale Kennzahlen ergänzen das Personalcontrolling, indem sie eine Sicht auf die gesamtpersonalwirtschaftliche Entwicklung im Unternehmen erlauben (vgl. Hentze u. Kammel 1993).

264

Unternehmensplanung

4.1.1.3

Organisation der Planung

Die Organisation der Planung ist zeitlich wie strukturell beeinflussbar. Unternehmensplanung findet in einem zeitlichen Rahmen statt, der im Gegensatz zum abgeschlossenen Planungshorizont durch regelmäßig wiederkehrende Aktivitäten der rollierenden Planung sowie Überprüfung und Kontrolle der Planwerte offen sein kann oder zeitlich und thematisch begrenzt ist. Welcher zeitlichen Linie die Planung folgt, ist daher von der aktuellen Planungsaufgabe determiniert und kann bedarfsgerecht verändert werden. Anders ist es mit den Strukturen des Unternehmens. Die Unternehmensplanung ist eng mit den Strukturen im Unternehmen und den Planungsträgern verwoben. Wie bereits bei der Zielplanung angemerkt wurde, sind die organisatorischen Gegebenheiten bei der Planung zu berücksichtigen, um verbindliche Entscheidungen für das gesamte Unternehmen zu treffen und die Umsetzung in allen Ebenen sicherzustellen (vgl. Wild 1974). Die Organisation der Planung resultiert in einem entsprechenden Planungssystem mit dem Ziel, die strategische und die operative Planung miteinander zu verbinden und in einer zeitlichen Abfolge zu organisieren. Teil dieses Systems sind die Entscheidungsträger und ihre Aufgaben, sowie die Strukturen des Unternehmens. Grundsätzlich lassen sich drei Hauptebenen im Unternehmen schaffen. Die Unternehmens- oder Geschäftsführung trägt die Verantwortung für den Konzern als Ganzes und ist so-wohl für die Ausrichtung des Unternehmens wie auch für die Konsolidierung der Unternehmensbereiche untereinander und mit der Führung zuständig. Während sich die Geschäftsbereiche an den Absatzmärkten des Unternehmens orientieren, treten Funktionsbereiche als Aufgabengruppen innerhalb des Unternehmens in Erscheinung. Als Funktionen werden beispielsweise der Vertrieb, die Forschung und Entwicklung oder das Informationsmanagement gesehen.  Unternehmens- oder Geschäftsführung  Geschäftsbereichsleiter oder Leiter einer strategischen Geschäftseinheit  Funktionsbereichsleiter Um einen Planungsprozess in einem Unternehmen zu etablieren, ist es zunächst notwendig, die betroffenen Akteure zu identifizieren. Im Einklang mit der Definition der Unternehmensführung werden hauptsächlich diejenigen Mitarbeiter mit Planungsaufgaben betraut, die im Unternehmen Aufgaben von besonderer Bedeutung für den Fortbestand des Unternehmens wahrnehmen. Diese Mitarbeiter zeichnen sich dadurch aus, dass sie als Führungskräfte die Kompetenz und Befugnis haben, um Entscheidungen zu treffen, die ihr Ressort oder gar das gesamte Unternehmen betreffen. Ein Mitarbeiter mit einer Planungsfunktion sollte immer auch die Entscheidungsbefugnis für sein Ressort haben, damit die Frage nach der Zuständigkeit und Verantwortung für Durchführung der Planung und Steuerung der Umsetzung der Planung nicht gestellt zu werden braucht. Die Distanz zwischen Planer und Entscheider darf keine spürbaren Auswirkungen auf das Unternehmen haben. Er kann sich jedoch durch sogenannte Planungsgremien fachlich unterstützen lassen, um eine Entlastung herbeizuführen. Erfolgen die methodische

Grundlagen der Unternehmensplanung

265

und situationsgerechte Vorbereitung der Planung durch Mitarbeiter, die nicht in der Verantwortung stehen, zugunsten oder zuwider einem Plan entscheiden zu müssen, lassen sich im Unternehmen Ressourcen schonen. Die Querschnittsfunktion der Unternehmensplanung macht es möglich, dass ein Planungsteam die Entscheidungsträger wirksam im Unternehmen unterstützt und den Planungsprozess vereinheitlicht, stabilisiert und transparenter gestaltet. Das Konzept der eigens zum Planungszweck geschaffenen Planungsabteilung hat sich nicht bewährt, weil die Balance zwischen der Planungsabteilung oder dem Stab zur Linie nur schwer zu finden ist (vgl. Kreikebaum 1993). Oftmals haben sich die Planungsaufgaben so stark zur Planungsabteilung hin verschoben, dass die Linie ihrer Verantwortung zur Erfüllung des Plans nicht mehr nachkommen wollte oder konnte. In Abhängigkeit von der organisatorischen Größe eines Unternehmens, wird die Verantwortung für die Erstellung und Umsetzung eines Plans meistens divisional, also verteilt über die Führungsstruktur des gesamten Unternehmens wahrgenommen. Begründet durch den begrenzten Detaillierungsgrad einer Planungsebene wird die Planung von der obersten Hierarchieebene nach unten hin immer stärker verfeinert. Während die Unternehmensleitung an der strategischen Planung mitwirkt, werden strategische Teilpläne und operative Pläne durch Führungskräfte auf nachfolgenden Hierarchieebenen bestimmt. Erfordert die Unternehmensstruktur die Einrichtung von Geschäftsbereichen oder gar strategischen Geschäftseinheiten, dann trägt der Geschäftsbereichsleiter oder der Leiter der SGE die Verantwortung für die Planung. Er übernimmt die strategischen Vorgaben der Unternehmensführung und berücksichtigt sie bei der Planung seines Verantwortungsbereichs. Obwohl ein Geschäftsbereich über teilweise sehr große Autonomie verfügt, besteht reger Informationsfluss zwischen den Geschäftsbereichen, den Funktionsbereichen und der Unternehmensführung. Pläne und Ziele werden mit den nächstniedrigeren Führungskräften abgestimmt, ehe sie verabschiedet werden. Schließlich sind die zumeist groben, aber bindenden Vorgaben der Geschäftsführung richtungsweisend für die Entscheidungen, die in den Geschäfts- und Funktionsbereichen getroffen werden. Die Abstimmung der Pläne erfolgt allerdings nicht nur vertikal in der Hierarchiestruktur, gleichzeitig ist die Vereinbarkeit der Teilpläne untereinander sicherzustellen. Durch die horizontale Abstimmung wird suboptimalen Entscheidungen entgegengewirkt, schließlich soll das Unternehmen insgesamt den größtmöglichen Erfolg erzielen und nicht nur in einigen Bereichen. Die Übertragung der strategischen Ziele hin zur operativen Ebene wird zwischen den beiden Extrempunkten der Loslösung und der Koppelung eingeordnet. Bei der Loslösung werden die strategische und die operative Planung getrennt, indem beispielsweise der operativen Planung ein strategischer Verbalteil vorangestellt wird, eine Diskussion der strategischen Fragen stattfindet oder im Vorfeld ein strategischer Planungsschritt erfolgt. Nachteilig ist die oft unklare Verbindung zwischen dem in dieser Konstellation relativ unbedeutendem strategischen Teil und der operativen Planung, sowie die fehlende Systematik. Daher hat die Koppelung als enge Verknüpfung zwischen Strategie und operativer Planung Vorrang. Dennoch sind auch bei der Koppelung verschiedene Nachteile zu überwinden. So

266

Unternehmensplanung

bringt das Top-Management oftmals nicht das notwendige Verständnis für das operative Geschäft an den Tag, so dass die Zusammenarbeit erheblich gestört wird. Oft werden strategische Maßnahmen nicht auf operativer Ebene umgesetzt, weil die notwendigen, bei der strategischen Planung vorausgesetzten Ressourcen, in Wahrheit nicht vorhanden sind oder die Inhalte auf dem Weg durch verschiedene Organisationsebenen verwässern und nur noch bruchstückhaft und stark modifiziert den Empfänger auf der operativen Ebene erreichen. Da diese Probleme häufig anzutreffen sind, ist bei der Formulierung der strategischen Ziele und Maßnahmen besonders auf Folgendes zu achten (vgl. Kreikebaum 1993):  Die Leistungsfähigkeit der operativen Organisationseinheiten ist zwingend zu berücksichtigen, um die Realisierbarkeit zu sichern  Strategien sollten auf die Organisationseinheiten zugeschnitten sein, statt pauschale Zielvorgaben an das gesamte Unternehmen zu senden  Koppelungsprobleme sind möglichst zu antizipieren  Den operativen Einheiten müssen neben den Strategien die wichtigsten Maßnahmen zu deren Umsetzung vorgegeben werden  Insgesamt gesehen muss es sich um eine partizipative Planung handeln, bei der die Kommunikation der für das operative Geschäft verantwortlichen Führungskräfte nach oben wie nach unten in der Organisationshierarchie wichtig ist Welge und Al-Laham formulierten für die Implementierung eine Strategie von einander abgrenzbaren Aufgabenbereichen, die die Umsetzung der strategischen Programme begünstigen. Durch die Einteilung fällt es leichter, die Aufgaben im Rahmen der Implementierung auszuarbeiten und im späteren Prozess mögliche Schwächen zu identifizieren. Sie berücksichtigen in der sachorientierten Strategieumsetzung sowohl die Konkretisierung der Strategie in operativen Plänen, Budgets und Ressourcenallokationen, als auch die Ausrichtung sämtlicher Erfolgsfaktoren auf die Strategie, zu denen die Organisationskultur, die Unternehmenskultur, das Managementsystem sowie Personal und Führungskräfte zählen. Gleichzeitig wird auf die verhaltensbezogenen Aufgaben Bezug genommen, die auf die Erreichung von Strategieakzeptanz zur Förderung des Implementierungsprozesses dienen (vgl. Welge u. Al-Laham 1999). 1. Strategieorientierte Gestaltung der Organisationsstruktur (Fähigkeiten, Ressourcen, Entscheidungskompetenzen) 2. Strategieorientierte Budgetierung und Ressourcenallokation 3. Strategieorientierte Erteilung von Anweisungen und Etablierung von Richtlinien (Policies) 4. Initiierung eines kontinuierlichen Veränderungsprozesses 5. Aufbau strategieunterstützender Kommunikations- und Informationssysteme 6. Gestaltung strategieorientierter Anreizsysteme 7. Gestaltung einer strategieunterstützenden Arbeitsumgebung und Organisationskultur 8. Aufbau von Führungskompetenz zur Förderung der Strategieumsetzung

Grundlagen der Unternehmensplanung

267

Es zeichnet sich im Planungsprozess letztendlich immer die Notwendigkeit einer Entscheidung ab, die sehr oft auf Kompromissen beruht. Konflikte sind kaum vermeidbar, denn die in jedem Unternehmen per Definition knappen Ressourcen sind im Planungsprozess zielgerichtet zu verteilen. Die Forderung nach einem möglichst großen Anteil an den Ressourcen ist mit der Einführung von SGE noch deutlicher geworden und bedarf einer Koordination. Für die Weitergabe der strategischen Ziele an nachgelagerte Einheiten sind verschiedene Modelle entwickelt worden, von denen sechs Vertreter nun vorgestellt werden. Das Prinzip des alleinigen Herrschers über das Unternehmen gibt vor, dass Strategien auf der Ebene der Unternehmensführung erstellt und an nachfolgende Einheiten zur unmittelbaren Realisierung weitergegeben werden. Dieses Modell funktioniert gut bei Unternehmen mit einer sehr flachen Struktur und einem einfachen Geschäftsmodell, das von der Führungsspitze gesteuert werden kann. Besteht ein Mehrbedarf an strategischer Kompetenz auf den oberen Ebenen, die nicht der Unternehmensführung direkt angehören, so kann das Veränderungsmodell oder das Partizipationsmodell angewandt werden. Im Erstgenannten ist es Aufgabe der Unternehmensführung, nicht nur die Strategie zu formulieren, sondern auch eine Implementierung dieser durch eine explizite Planung sicherzustellen. In der Rolle eines Architekten übernimmt die Unternehmensführung die Gestaltung der Erfolgsfaktoren des Unternehmens in Form der Organisationsstruktur, Planungs-, Kontroll- und Anreizsysteme zur Umsetzung seiner Strategie. Da die autoritäre Haltung beibehalten wird, ist nach wie vor mit geringer Akzeptanz seitens der ausführenden Einheiten zu rechnen. Anders beim Partizipationsmodell, denn hier nehmen die unteren Führungsebenen an der Strategieformulierung und Implementierung teil. Obwohl die kreativen Potentiale der Führungskräfte im Unternehmen freigesetzt und in Motivation umgewandelt werden, besteht die Gefahr einer im Vergleich zu den autoritär erlangten Strategien suboptimalen Entscheidung. Im Gegensatz zu den strikt vorgebenden Modellen bietet das Konvergenzmodell der Unternehmensführung zu wenig Einfluss auf die Strategiegestaltung und Implementierung, da sie nur die strategischen Ziele und die Ressourcen vorgibt. Die mittleren und unteren Führungsebenen müssen äußerst stark und untereinander kooperativ sein, damit die Strategien aus den unteren Ebenen erwachsen. Das Kulturmodell von McKinsey verfolgt einen ganzheitlichen Ansatz, der auch als sieben S-Modell bekannt ist (siehe Abb 4.9). Von der Unternehmensführung gehen mit den Strategien und Zielen Visionen aus, die an die nachgelagerten Führungsebenen weitergereicht werden. Die Unternehmensführung agiert in der Rolle eines Trainers, der die Vision an die Führungskräfte als Leitlinien einer Kultur weitergibt. Die Harmonisierung betrifft nicht nur die Strategie (engl. Strategy), die Unternehmens- und Organisationsstruktur (engl. Structure) und der Methoden und Prozesse (engl. Systems), sondern auch die Belegschaft (engl. Staff), der Führungsstil (engl. Style), die Qualifikation der zentralen Mitarbeiter (engl. Skills) und übergelarte Ziele (engl. Superordinate Goals). Die Ganzheitlichkeit begegnet dem Modell als große Herausforderung, denn ein Unternehmen komplett umzust-

268

Unternehmensplanung

rukturieren ist nur unter bestimmten Bedingungen möglich (vgl. Welge u. AlLaham 1999).

Abb. 4.9 Sieben-S-Kulturmodell (vgl. Welge u. Al-Laham 1999)

Als Abstimmungsprozess hat sich bei mehreren am Planungsprozess beteiligten Akteuren das Gegenstrom-Verfahren etabliert. Nachdem reine Top-Down (retrograde Planung) oder Bottom-Up (progressive Planung) Verfahren in der Praxis an Widerständen der unteren Ebenen bzw. mangelnder Zielkonkretisierung der oberen Führung gescheitert sind, hat sich ein ausgeglichenes, auf den Dialog zwischen den Hierarchieebenen konzentriertes Verfahren ausgebildet. Wie beim TopDown-Verfahren sind im Konfliktfall die Vorgaben der Unternehmensführung maßgeblich, jedoch erfolgt zuvor eine Abstimmung der von den oberen Hierarchieebenen gesetzten, strategischen Ziele mit den operativen Einheiten im Unternehmen, also dort, wo die operativen Ziele erfüllt werden. Die Unternehmensführung ist für eine übergeordnete Analyse der Möglichkeiten und Grenzen des Unternehmens und der Umweltsituation sowie die Formulierung der strategischen Ziele verantwortlich (vgl. Steinmann u. Schreyögg 1993). Nachfolgende Organisationseinheiten (z.B. Geschäftsbereiche) setzten ihre Fachkompetenz ein, um die strategischen Ziele zu prüfen und überführen diese in operative Ziele, soweit es die Bedingungen zulassen. Dabei erfolgt auch eine horizontale abteilungs-, fachbereichs- oder geschäftsbereichsübergreifende Abstimmung

Planungsmethoden

269

auf der Hierarchieebene. Ist eine Überführung nicht ohne Anpassung der strategischen Ziele möglich, so werden die Gegenvorschläge mit den oberen Planungsebenen erneut abgestimmt. Obwohl der Zeitaufwand nicht geringer ist als bei der Top-Down-Planung, ist die Glaubwürdigkeit, Präzision und Kommunikation der Planung und nicht zuletzt die Motivation der Mitarbeiter erheblich größer. Gleichzeitig werden auch hohe Anforderungen an die an der Planung beteiligten Führungsebenen gestellt, wodurch die Mitarbeiterqualifikation großes Gewicht bekommt (vgl. Jost 2000).

4.2

Planungsmethoden

Die Organisation, Durchführung und Kontrolle der Planung wird durch eine Vielzahl von Methoden unterstützt. Wie zum Beispiel die MarktwachstumMarktanteil-Matrix der Boston Consulting Group haben manche Methoden sogar Einfluss auf die Struktur der Unternehmensplanung genommen. Ihre große Bedeutung macht es unerlässlich, die Methoden im Rahmen der Unternehmensplanung vorzustellen.

4.2.1 Erfahrungskurve Seit Beginn der Massenproduktion konnte in der Wirtschaft ein Phänomen beobachten werden, dessen Existenz praktisch alle Produktionsunternehmen beobachten konnten. Mit zunehmender Produktionsmenge und Zeit haben sich die Kosten je ausgebrachter Einheit reduziert. Beschrieben wurde diese Beobachtung als die Erfahrungskurve, die in jeder Branche verschieden starke Kostenreduktion aufwies. Ende der 60er Jahre hat die Boston Consulting Group damit begonnen, den seit Längerem bekannten Effekt der Erfahrungskurve für konsequent strategische Entscheidungen zu nutzen (vgl. Hax u. Majluf 1991). Die Erfahrungskurve verläuft umgekehrt logarithmisch und lässt sich als Regel formulieren. Bei einer als Beispiel angenommenen 75%igen Erfahrungskurve sinken die Stückkosten von 100 auf 75 Geldeinheiten, wenn die Ausbringungsmenge von 200 auf 400 Einheiten gesteigert wird. Bei einer erneuten Produktionsverdopplung sinken die Stückkosten erneut um 75% auf 56,25 Geldeinheiten. Die Berechnungsformel kann aus Abbildung 4.10 entnommen werden.

Abb. 4.10 Berechnungsformel der Erfahrungskurve

270

Unternehmensplanung

Je nach Branche verändert sich der Exponent a, bietet so aber für die in diesem Sektor agierenden Unternehmen die Möglichkeit, ihre Position im Vergleich zum Wettbewerb aufzuzeichnen. Der Effekt der Erfahrungskurve stellt sich allerdings nicht automatisch ein, sondern muss von den Unternehmen erarbeitet werden. So resultiert eine Senkung der Stückkosten aus den Errungenschaften und Vorteilen, die in der gesamten Wertschöpfungskette erzielt werden. Vorteile werden geschaffen, indem das Unternehmen und seine Mitarbeiter kontinuierlich lernen und das Know-how steigern, die Fertigungsprozesse optimiert, Produkte normiert sowie Methoden und Systeme rationalisiert werden und aufgrund der Skalenerträge beim Einkauf von größeren Inputmengen. Ebenso Forschung und Entwicklung, Einkauf, Produktion, Marketing und Vertrieb, aber auch Querschnittsfunktionen wie Personalwesen und Informationsmanagement tragen dazu bei, dass die durch die Erfahrungskurve vorhergesagten Kostensenkungseffekte auch eintreffen. Die gemeinschaftliche Ausrichtung der Geschäftseinheiten und Funktionsbereiche obliegt der Unternehmensleitung und ist damit eine strategische Planungsaufgabe (vgl. Hax u. Majluf 1991). In Abbildung 4.11 ist die Erfahrungskurve in einem Grafen ffen abgebildet.

Abb. 4.11 Grafische Erfahrungskurve (logarithmische Skala)

Die Erfahrungskurve muss nicht immer bei strategischen Entscheidungen berücksichtigt werden. Ist der technologische Vorsprung eines Unternehmens im Vergleich zum Wettbewerb sehr hoch oder lernt dieses immens schnell, so gilt für dieses eine andere Erfahrungskurve als für die übrigen Unternehmen. Deutliche Wettbewerbsvorteile machen einen Vergleich der Unternehmen untereinander auf nur einer Erfahrungskurve unrealistisch. Eine große Gefahr bei der Interpretation der Erfahrungskurve ist die eingeschränkte Sicht, zu der die Kurve verleitet. Die

Planungsmethoden

271

Kostenvorteile werden nicht nur durch das Produktionsvolumen beeinflusst, sondern ergeben sich durch Verbesserungen im gesamten Wertschöpfungsprozess. Daraus ist auch abzuleiten, dass nicht nur die Stückkosten am Ende der Wertschöpfungskette auf einer Erfahrungskurve abgezeichnet werden, sondern die Notwendigkeit besteht, verschiedene Phasen zu untersuchen (vgl. Hax u. Majluf 1991). Der Marktpreis steht nicht immer im Zusammenhang mit der Erfahrungskurve, denn das Kostensenkungspotential muss nur unter bestimmten Bedingungen an den Kunden weitergegeben werden. So kann bei der Einführung eines neuen Produkts durch die Technologieführerschaft eines Unternehmens zunächst ein nahezu perfektes Monopol entstehen. Erst mit dem Eintreten von Wettbewerbern lassen die Unternehmen die realisierten Potentiale nach dem Erfahrungskurveneffekt auf die Preise wirken. Interessant ist die Antizipation der Stückkostensenkung bei der Angebotsformulierung. Kann ein Unternehmen seine Erfahrungskurve ausreichend präzise bestimmen, so kann es Kostensenkungspotentiale bereits in den Angebotspreis einfließen lassen und sich so Vorteile sichern (vgl. Hax u. Majluf 1991).

4.2.2 Marktwachstum-Marktanteil-Matrix Als Unternehmen damit begannen, ihr Geschäft in strategische Geschäftseinheiten zu gliedern, wurde eine Bestandsaufnahme des gesamten Unternehmens unter dem Gesichtspunkt seines SGE-Portfolios notwendig. Erst wenn der Beitrag aller SGE zum Unternehmenserfolg bekannt war, konnten auch Aussagen über die Position des darüberstehenden Unternehmens getroffen werden. Um diese Bestandsaufnahme möglichst kompakt darstellen zu können, hat die Boston Consulting Group die Marktwachstum-Marktanteil-Matrix entwickelt. Die Darstellung des Portfolios an SGE wird in einem Koordinatensystem aus Marktwachstumsrate auf der Ordinate und relativem Marktanteil auf der Abszisse abgetragen. Dem Beitrag zum Unternehmenserfolg wird durch die Fläche des Kreises einer SGE Rechnung getragen, der stellvertretend für den Anteil einer SGE am Gesamtumsatz steht. Der Umsatz stellt zudem eine Vergleichbarkeit mit dem Wettbewerb her, ohne dass Besonderheiten der Kostenrechnung Einfluss nehmen könnten. Die Marktwachstumsrate wird als prozentuale Veränderung zum Vorjahr definiert, während sich der relative Marktanteil durch das Vielfache am Marktanteil des Marktführers in der Branche berechnet. Somit ist gesichert, dass sich verschiedene Marktstrukturen gerecht widergegeben lassen. Zu beachten ist, dass diese Methode das Ziel der Kostenführerschaft als Hauptziel ansieht und sich alle Unterziele daran zu orientieren haben. Bei der Strategiefindung sollte dieser Umstand stets berücksichtigt werden (vgl. Hax u. Majluf 1991). Aus dem Koordinatensystem lässt sich eine Matrix erstellen, indem wesentliche Werte durch zwei Geraden im Zeichenbereich hervorgehoben werden. Im

272

Unter Unternehmensplanung

Marktwachstum ist dies der durchschnittliche Wachstumswert über alle abgebildeten Branchen, er kann aber auch die Zielformulierung der Unternehmensleitung entstehen. Im relativen Marktanteil ist die Gerade durch den Wert 1 und 1,5 zu ziehen. Diese Achsenabschnitte identifizieren den Marktführer einerseits, und einen den Markt dominierenden Marktanteil andererseits (siehe Abb. 4.12). Anhand der Umsätze und ihrer Position in der Matrix lassen sich SGE und ihre strategische Bedeutung für das Unternehmen einordnen. Wesentlich sind die geschickte Abgrenzung des Marktes und präzise Informationen, um die gewünschten Kennzahlen zu ermitteln (vgl. Hax u. Majluf 1991).

Abb. 4.12 Marktwachstum-Marktanteil-Matrix

Sind die SGE in ein Gefüge von Marktwachstum und relativem Marktanteil eingeordnet, so können bereits erste Aussagen über deren strategische Bedeutung gemacht werden. Auffällig ist, dass eine SGE umso bedeutsamer ist, je größer ihr relativer Marktanteil und das Marktwachstum sind. Weil davon ausgegangen wird, dass vom Unternehmen die Marktführerschaft angestrebt wird, sind SGE mit einem geringen relativen Marktanteil als stark gefährdet einzustufen. Durch die Marktmacht der Wettbewerber kann die SGE zu Fehlentscheidungen getrieben werden. Sind Branchen mit einem hohen Wachstum im Portfolio vertreten, so sind diese als zukunftsträchtige SGE zu klassifizieren, die auch in der Zukunft das Potential haben, um dem Unternehmen Erträge zu bringen. Umsätze einer SGE hingegen machen ihre aktuelle Bedeutung für das Unternehmen klar. Je höher ihr An-

Planungsmethoden

273

teil an den Gesamtumsätzen ist, umso wichtiger ist die SGE für den kurz- bis mittelfristigen Fortbestand des Unternehmens (vgl. Hax u. Majluf 1991). Werden die Inhalte der Matrix übernommen und die Achsenbeschriftungen verändert, so können auch der Kapitalbedarf und die Kapitalfreisetzung einer SGE abgelesen werden. Daran lassen sich die Kapitalflüsse zwischen den SGE im Unternehmen schlussfolgern und die möglichen Strategien bestimmen. Dieser Teil der Methode wurde aufgrund der prägnanten Benennung der Einordnungsbereiche in der Vier-Felder-Matrix bekannter als die eigentliche MarktwachstumMarktanteil-Matrix (siehe Abb. 4.13) (vgl. Hax u. Majluf 1991).

Abb. 4.13 Kapitalbedarfe und Kapitalfreisetzung in der Marktwachstum-Marktanteil-Matrix

Die Sternchen eines SGE-Portfolios gehören in einem stark wachsenden Markt den Marktführern an. Aufgrund des schnellen Wachstums am Markt ist mit einem starken Wettbewerb zu rechnen, da die Attraktivität der Branche nicht unbemerkt von der Konkurrenz bleiben dürfte. Um weiterhin zu den führenden Anbietern zu gehören, muss die SGE das erworbene Kapital reinvestieren, ggf. sogar Kapital aus dem Unternehmen beziehen. Die wichtigste Herkunft des Kapitals sind andere SGE, die sich in einem ruhigen oder gerade beruhigten Markt als starker Anbieter positioniert haben. Sie sind stark genug, um sich in einem langsam reduzierenden Markt ohne immense Investitionen zu behaupten und können daher die Erträge in diesem Segment freigeben. Da sie vergleichsweise wenig Aufmerksamkeit bedürfen, werden diese Nutztiere des Unternehmens als Cash-Kühe bezeichnet. Mit starker Unsicherheit belegt sind schwach aufgestellte SGE, die in einem stark

274

Unternehmensplanung

waschsenden Markt nur wenig Marktmacht besitzen. Wenn es möglich ist, zum Marktführer zu avancieren, dann sollte das Unternehmen diese Fragezeichen-SGE stark fördern. Wenn jedoch trotz hoher Investitionssummen keine nachhaltige Verbesserung in Aussicht gestellt werden kann, muss das Unternehmen über einen Rückzug nachdenken. Rückzug ist auch für die armen Hunde der Matrix eine Option, da sie kaum Marktanteile in einem unattraktiven Markt haben. Diese werden oft schnellstmöglich veräußert (vgl. Hax u. Majluf 1991). Wird die Marktwachstum-Marktanteil-Matrix zur Bewertung des SGEPortfolios und der gewünschten strategischen Richtungen genutzt, müssen die Annahmen bekannt sein, unter denen diese Methode entwickelt wurde. Ein Unternehmen, das seine SGE nach der Marktwachstum-Marktanteil-Matrix bewertet, hat als primäre Ziele einen hohen Marktanteil in stark wachsenden auszubauen, indem Kapital aus in stagnierenden Märkten aktiven SGE abgezogen und in zukunftsträchtige SGE investiert wird. SGE mit hohem Marktanteil werden als rentabler angesehen als solche, die nicht zu den Marktführern gehören. Die gewünschte Entwicklung kann auch innerhalb der Matrix leicht für jede Geschäftseinheit skizziert werden. Einen Zeitraumbezug wird hergestellt, indem die auf den Achsen des Koordinatensystems liegenden Durchschnittswerte über die Zeit abgetragen werden. Auf diesen Annahmen aufbauend lassen sich für die SGE je nach Segment folgende strategische Positionen formulieren (siehe Tab. 4.3) (vgl. Hax u. Majluf 1991): Tabelle 4.3 Implikationen der Marktwachstum-Marktanteil-Matrix für die strategische Positionierung Segment

Stoßrichtung bzgl. Marktanteil

Geschäftsrentabilität Erforderliche Investitionen

Netto-Cash-Flow

Sternchen

halten/steigern

hoch

hoch

etwa Null oder leicht negativ

Cash-Kühe

halten

hoch

gering

sehr positiv

Fragezeichen steigern

Null oder negativ

sehr hoch

sehr negativ

abschöpfen

gering oder negativ

liquidieren

positiv

Arme Hunde abschöpfen/ liquidieren

gering oder negativ

liquidieren

positiv

Werden die strategischen Empfehlungen und Positionen in einer zeitlichen Abfolge angeordnet, so beginnt eine neue SGE im Feld der Fragezeichen. Der Markt bietet noch sehr viel Potential, doch um dieses zu nutzen, muss in die SGE investiert werden. So kann sie durch optimale Entscheidungen getragen den relativen Marktanteil ausbauen und zu einem Sternchen werden. Hat die Marktdynamik abgenommen, läuft auch die Förderung der SGE langsam ab und sie wird zu einer Cash-Kuh, die für andere neue SGE das Investitionskapital stellt. Wenn die Umsätze im Markt schließlich sinken und die Gewinngrenze erreicht ist, wird die SGE liquidiert (vgl. Hax u. Majluf 1991).

Planungsmethoden

275

Die Boston Consulting Group hat die von ihr entwickelte Matrix weiterentwickelt und den Return on Invest (ROI) und den Marktanteil miteinander in Verbindung gebracht, um sie durch die Anzahl der Möglichkeiten zur Erzielung von Wettbewerbsvorteilen und die Bedeutung eines Wettbewerbsvorteils einzugruppieren. Damit wird die Matrix den Veränderungen in der Marktwirtschaft angepasst und löst sich von dem Dogma der Wettbewerbsstärke durch hohen Markanteil. So befinden sich in der neuen BCG-Matrix weiterhin vier Felder, die auf die Gegebenheiten im Markt eingehen. Bei einem zersplitterten Markt haben die Unternehmen viele Möglichkeiten, um Wettbewerbsvorteile zu erlangen. Ein einzelner Wettbewerbsvorteil ist jedoch nicht ausreichend, um sich die Marktführerschaft zu sichern. Bei der Spezialisierung hingegen kann es durchaus lohnenswert sein, aufgrund eines oder mehrerer Wettbewerbsvorteile einen geringen Marktanteil in Kauf zu nehmen und dennoch erfolgreich zu sein. Diese Strategie zu verfolgen kann den ROI signifikant steigern, wenn der Unterschied zum Wettbewerb nicht durch den Preis bzw. die Ausbringungsmenge möglich ist. Eine festgefahrene Situation zeigt sich bei wenigen möglichen und zugleich schwach wirkenden Wettbewerbsvorteilen, wie es in der Konsumgüterindustrie oft der Fall ist. Der ROI ist nicht vom Marktanteil abhängig. Umgekehrt werden die Kostenvorteile stark nutzbar gemacht, wenn der ROI proportional mit dem Marktanteil wächst. In dieser Situation ist das schon bei der klassischen Marktwachstum-Marktanteil-Matrix empfohlene Streben nach hohem Marktanteil bestimmend (vgl. Hax u. Majluf 1991). Der Zusammenhang wird in Abbildung 4.14 veranschaulicht.

Abb. 4.14 Grundlegende Beziehungen zwischen ROI und Marktanteil in der neuen BCG-Matrix

276

Unternehmensplanung

4.2.3 Branchenattraktivität-Wettbewerbsstärke-Matrix Einwänden gegen die Marktwachstum-Marktanteil-Matrix, sie basiere auf zu wenigen Parametern bzw. Kennzahlen, wurden mit der BranchenattraktivitätWettbewerbsstärke-Matrix begegnet. Auch hier ist es das Ziel, aufgrund der Position einer SGE oder gar des ganzen Unternehmens eine strategische Position zu finden und die zukünftige Strategie anhand der Zielposition in der Matrix zu beschreiben. Der Wert für beiden Achsen der Matrix wird jedoch von einer Vielzahl von qualitativen Faktoren bestimmt. So stehen hinter der Wettbewerbsstärke auf der Ordinate interne Faktoren, die von der SGE beeinflussbar sind. Die Branchenattraktivität auf der anderen Achse wird durch externe Faktoren bestimmt, die als gegeben anzusehen sind. Ohne eine Beschränkung auf Marktwachstum, relativen Marktanteil und Umsatz lassen sich jeder Geschäftseinheit viel differenzierter individuelle Prioritäten zuordnen (vgl. Hax u. Majluf 1991). In Tabelle 4.4 sind verschiedene interne wie externe Faktoren beispielhaft aufgeführt. Die Definition der Faktoren wird von den Funktionsträgern der SGE und der Unternehmensführung auf Grund von Erfahrung und durch Analysen des internen wie externen Umfelds gebildet. Haupteigenschaft der Faktoren ist ihre unbedingte Relevanz für strategische Entscheidungen in Bezug auf eine konkrete SGE. Die Faktoren können durch Kennzahlen gestützt sein, müssen es aber nicht. Dadurch wird ein sehr großes Maß an Flexibilität gepaart mit Vollständigkeit erlangt (vgl. Hax u. Majluf 1991). Tabelle 4.4 Beispiel für interne und externe Faktoren Interne Faktoren

Externe Faktoren

Marktanteil

Marktvolumen

Vertreterstab

Marktwachstumsrate

Marketing

Zyklizität

Kundendienst

Wettbewerbsstruktur

Forschung und Entwicklung

Eintrittsbarrieren

Herstellung und Vertrieb

Branchenstabilität

Finanzielle Ressourcen

Technologie

Image

Inflation

Breite der Produktionslinie

Gesetze

Qualität / Zuverlässigkeit

Personalangebot

Management-Kompetenz

Soziale Probleme

Organisationsstruktur

Umweltprobleme Politische Probleme Rechtliche Probleme Wertpapierhandel

Planungsmethoden

277

Die Definition der Faktoren ist jedoch nur der erste Schritt in der Bestimmung der aktuellen strategischen Situation einer SGE. Um als Kriterien Einfluss auf die Einschätzung auszuüben, sind die einzelnen Kriterien zu bewerten, indem sie gewichtet und mit einem Wert versehen werden. Bei der Bewertung wird unterschieden, ob die externen Faktoren in der Breite ihrer Wirkung für alle Unternehmen in der Branche oder speziell auf die SGE wirken. Im ersten Fall wird der mittlere Wert über alle Unternehmen als Beurteilung gewählt, im zweiten Fall muss bestimmt werden, ob die SGE im Vorteil oder im Nachteil zu ihren Konkurrenten steht. Die Bewertung wird in Form der Nutzwertanalyse vollzogen, indem die Beurteilung mit der Gewichtung eines jeden Wertes multipliziert und die Summe über alle Produkte gebildet wird. Die Summe kann dann im Intervall der Werte eingeordnet werden. Beim Bewertungsprozess werden die einzelnen Beurteilungsmaßstäbe und Gründe für die Beurteilung im Prozess aufgenommen und mit den Ergebnissen verknüpft. So lassen sich die gebildeten Kriterien auch in späteren Entscheidungsprozessen noch nachvollziehen (vgl. Hax u. Majluf 1991). Mit der abgeschlossenen Bewertung für die SGE kritischen internen und für die externen Faktoren ist die Grundlage für eine Einordnung der SGE in die Branchenattraktivitäts-Wettbewerbsstärke-Matrix geschaffen (siehe Abb. 4.15). Ob dabei eine strikte Einordnung in die einzelnen Felder der 3x3-Matrix erfolgt oder wie in der Marktwachstums-Marktanteil-Matrix eine präzise Positionierung mit zusätzlicher Darstellung des Anteils am Gesamtumsatz gewählt wird, hängt von den Anforderungen der Entscheidungsträger ab. Ausgehend von der aktuellen Position werden im nächsten Schritt die kritischen Faktoren in die Zukunft fortgeschrieben. Damit wird die Zeitachse als dritte Dimension in die Matrix eingeführt. Durch die Prognose der Faktorausprägungen unter ansonsten konstanten Bedingungen kann die zukünftige Position in der Matrix abgezeichnet werden. Damit wird dem Betrachter deutlich gemacht, wie sich bei gleichbleibender Strategie die Situation für die SGE entwickeln wird. Sind die potentiellen Chancen und Risiken bekannt, lassen sie sich mit der von den Entscheidungsträgern gewünschten Position der SGE in der Matrix abgleichen. Hierfür werden die kritischen Faktoren mit zukünftig zu realisierenden Werten belegt und gleichzeitig die gewünschte Position in der Matrix kenntlich gemacht. Mit dieser Szenariobildung beginnt bereits die Strategieformulierung für die SGE (vgl. Hax u. Majluf 1991). Das Hauptziel der Erstellung der Matrix und der Ermittlung der aktuellen und zukünftigen Positionen der SGE ist die Schaffung einer Entscheidungsgrundlage für die zukünftige Verteilung von Ressourcen und Investitionen. Aus den auf dieser Grundlage getroffenen Entscheidungen entstehen Strategien und es werden strategische Programme, Budgets und Leistungsmerkmale abgeleitet. Jedes der neun Felder in der Matrix impliziert je nach Ausprägung der beiden bestimmenden Stärken unterschiedliche Strategien, die sich teilweise mit denen der Marktwachstums-Marktanteil-Matrix decken. So ist bei hoher Wettbewerbsstärke und großer Branchenattraktivität Wachstum und Vorherrschaft anzustreben. Dies steht in direktem Zusammenhang mit der Investitionshöhe, die zur Förderung dieser SGE nötig ist. Ist die Branchenattraktivität nicht so hoch, so werden Ressourcen

278

Unternehmensplanung

stärker selektiv verteilt, um zukünftig wichtige Bereiche intensiv und Einheiten mit geringer Attraktivität in geringerem Maße zu unterstützen. In Branchen, die hochgradig interessant für die SGE sind, in denen sie aber keine starke Position angenommen hat, sind ebenfalls starke Investitionen vorgesehen, um Stärken zu fördern und Schwächen zu eliminieren. Bei mittlerer Attraktivität der Branche und gleichzeitig durchschnittlicher oder geringer Wettbewerbsstärke kann eine Spezialisierung auf Wachstumssegmente oder die Konzentration auf Nischen vorteilhaft sein. Bei geringer Branchenattraktivität und schwacher bis mäßiger Wettbewerbsstärke der SGE ist der Rückzug oder Verkauf der SGE vorzubereiten, wenn die Spezialisierung keine Vorteile bringen wird (vgl. Hax u. Majluf 1991).

Abb. 4.15 Branchenattraktivitäts-Wettbewerbsstärke-Matrix nach McKinsey und GE

Die völlige Offenheit bezüglich der Faktoren und ihrer Bewertung im Rahmen einer Nutzwertanalyse kann zu einer signifikanten Schwäche im Umgang mit der Branchenattraktivitäts-Wettbewerbsstärke-Matrix führen. Weil die Beurteilung der Faktoren sehr individuell gestaltet werden kann und sich oft nicht durch ein Zahlenwerk stützen lässt, ist eine Vergleichbarkeit einer SGE mit anderen SGE nur bei sehr strikten Vorgaben möglich, mit SGE der Konkurrenten praktisch nicht zu realisieren. Aus diesem Grund wird die Matrix für die Diagnose, Strategiefindung und die Impulssetzung für strategische Programme genutzt. Die Wettbewerbsanalyse wird mit Hilfe der Marktwachstums-Marktanteil-Matrix durchgeführt (vgl. Hax u. Majluf 1991).

Planungsmethoden

279

4.2.4 Lebenszyklusanalyse In Unternehmen, die ihren Gewinn aus dem Absatz ihrer Produkte beziehen, übt der Lebenszyklus des Produkts und der Branche einen starken Einfluss auf die Strategien aus. Der Lebenszyklus ist aus der Beobachtung entnommen, dass der Absatz zunächst erfolgreicher Produkte mit der Zeit immer schwächer wächst, einen flachen Punkt erreicht und letztlich zu sinken beginnt, wenn das Produkt veraltet ist, nicht mehr von den Kunden nachgefragt wird oder der Anbieter vom Markt ausscheidet. Daher muss rechtzeitig ein neues Produkt eingeführt werden, das den Lebenszyklus fortsetzt. Wird so die Nachfrage nach einem oder mehreren Produkten in Abhängigkeit von der Zeit in ein Diagramm gefasst, lassen sich die Phasen der Einführung, des Wachstums, der Reife und der Degeneration an der Steigung der Umsatzkurve abzeichnen (siehe Abb. 4.16).

Abb. 4.16 Lebenszykluskurve

Wird ein Produkt mit hohem Erfolgspotential auf den Markt gebracht, so bedarf es in der Regel großer Investitionen, um seinen Absatz signifikant in kurzer Zeit zu steigern und um mit den Wettbewerbern Schritt halten zu können bzw. die Branchenführerschaft zu übernehmen. Die Marktdurchdringung steht für das Unternehmen im Vordergrund. Das Marketing setzt seine Ressourcen ein, um das Produkt zu bewerben und ein Distributionsnetz aufzubauen. Die Produktion ist auf mögliche Kapazitätsausweitungen gefasst, belässt es aber bei einer geringen Produktbreite. Das Personal muss geschult werden, um auf die neuen Entwicklungen im Unternehmen vorbereitet zu sein. Gleichzeitig werden gezielt Mitarbeiter ge-

280

Unternehmensplanung

sucht, um neue Schlüsselstellen zu besetzen. In der Forschung und Entwicklung werden Neuerungen am Produkt konzipiert und anfängliche Fehler im Produkt und im Fertigungsprozess behoben. In der Wachstumsphase wird die zügige Expansion und Sicherung der Marktanteile durch weitere Investitionen finanziert. Der Umsatz steigt durch Anstrengungen des Marketings deutlich an. Das Markenimage hat sich gefestigt, Nischen sind belegt worden und die Vertriebskanäle sind stabil. In der Produktion wird über Produktvarianten nachgedacht und der Produktionsprozess auf Qualität und Kostensenkung optimiert. Dabei muss weiterhin qualifiziertes und loyales Personal zur Verfügung stehen. Die Forschung und Entwicklung führt Produktverbesserungen ein, bereitet aber gleichzeitig auch den Nachfolger vor. Die Phasen der Einführung und des Wachstums sind die kapitalintensivsten im gesamten Lebenszyklus. Die hohen Investitionskosten lassen sich damit rechtfertigen, dass in der nachfolgenden Reifephase die Erträge die Kosten bei weitem überschreiten. Diese Phase sollte daher die zeitlich längste und ertragreichste sein. Das Marketing sorgt sich um die Erschließung neuer Märkte, aggressive Werbung und Produktdifferenzierung, damit der Absatz konstant gehalten oder gesteigert wird. In der Produktion wird die von der Forschung und Entwicklung entworfene Produktverbesserung realisiert und die Kostensenkung vorangetrieben. Es wird aber auch die Möglichkeit der Kapazitätsverringerung geprüft. Das Personalwesen ist nun auch bemüht, die Kosten zu senken und die Effizienz der Mitarbeiter zu erhöhen. Von der Kostensenkung ist auch die Forschung und Entwicklung betroffen, die zwar noch Varianten des Produkts entwickelt, aber gleichzeitig versucht, die aktuellen Kosten zu senken. Der Niedergang des Produkts ist durch die Phase des Alterns vertreten, hier sinkt die Nachfrage, bis das Produkt schließlich erneuert oder vom Markt genommen wird. Analog kann der Lebenszyklus einer Branche formuliert werden. Ziel ist es hier, das maximale Kapital aus Branche oder Produkt herauszuholen. Das Marketing versucht, die positiven Aspekte des Produkts auf das Unternehmen zu übertragen und markentreue Kunden zu halten. In der Produktion wird das Programm bereinigt, ebenso im Personalsektor, der mit Kündigungen Kostenvorteile nutzt. Das Controlling ermittelt die gewinnoptimale Strategie und bereitet einen Verkauf des Bereichs oder die Schließung vor. Die Forschung überträgt das Wissen und die Erfahrung auf neue Bereiche. Vom Lebenszyklus betroffen sind nicht alle Produkte oder Branchen gleichermaßen. Die Nachfrage nach Grundnahrungsmitteln beispielsweise ist von einem Produktlebenszyklus nicht betroffen, Computer und Automobile unterliegen hingegen sehr stark den Annahmen über die Nachfragekurve im zeitlichen Verlauf. Durch bestimmte Markteinflüsse kann die Phase im Lebenszyklus beeinflusst werden (z.B. durch stark ansteigende Rohstoffpreise). Trifft das Konzept des Lebenszyklus auf ein Produkt oder eine Branche zu, so lassen sich daraus jedoch Handlungsempfehlungen für die Strategie ableiten. Wird der Lebenszyklus mit der Wettbewerbsposition in Verbindung gebracht, lassen sich strategische Aussagen zum Marktanteil, zum Investitionsvolumen und zur Rentabilität formulieren.

Planungsmethoden

281

Die Wettbewerbsposition einer SGE wird durch zumeist qualitative Kriterien bestimmt. Eine dominierende Position äußert sich durch ein Quasi-Monopol mit einem sicheren, technologischen Vorsprung. Diese Art der Position ist jedoch sehr selten anzutreffen. Ähnlich ist die starke Position einzuschätzen, bei der eine SGE nicht auf Wettbewerber Rücksicht nehmen muss, wenn sie ihre Strategie oder die strategischen Programme bestimmt. Bei relativ homogenen Branchen mit nur gering ausgeprägter Führung durch einen der Akteure wird von einer günstigen Position für diesen gesprochen. Oft tritt dies in zersplitterten Branchen auf. Eine mäßige Position wird durch SGE in Nischen eingenommen, die trotz einer schwierigen Lage einen positiven Beitrag leisten. Bei schwachen Positionen wird die SGE langfristig nicht ohne großzügige Hilfe überleben können, weil der Wettbewerb sehr viel stärker ist, oder weil eklatante Fehler in der Vergangenheit durch die Führung gemacht worden sind. Auch aus der Lebenszyklusanalyse lassen sich strategische tegische Empfehlungen aableiten. Die Stoßrichtungen geben das grundsätzliche Ziel und die zu erwartenden Handlungen vor, sie werden durch verschiedene Strategien ausgefüllt. Dabei können die gleichen Strategien in unterschiedlichen Stoßrichtungen zum Einsatz kommen, weil sich die unterstützten Ziele oftmals überschneiden. Um eine Anwendung der Strategien in Abhängigkeit des Lebenszyklus vorzubereiten, wird in Abhängigkeit von den Phasen der Entstehung, des Wachstums, der Reife und des Alters der Umsatz, das Investitionsvolumen und letztendlich der Cashflow abgetragen. Anhand dieser Matrizen ist es dem Planungsträger möglich, die Positionen unter unterschiedlichen Aspekten zu beurteilen (siehe Abb. 4.17, 4.18 und 4.19).

Abb. 4.17 Lebenszyklusphasen und Marktanteil

282

Unternehmensplanung

Abb. 4.18 Lebenszyklus und Investitionen

Abb. 4.19 Lebenszyklus und Rentabilität / Cashflow

4.2.5 BalancedBalanced-Score -Score-Card Eine Methode zur Umsetzung der Unternehmensstrategie stellt die Balanced Score Card (BSC) dar. Entstanden aus der Zusammenarbeit von Kaplan und Norton so-

Planungsmethoden

283

wie der Gemini Consulting und KPMG wurde das Konzept zur Übersetzung der Mission und Strategie einer Geschäftseinheit in spezifische Ziele und Kennzahlen entworfen, indem kritische Erfolgsfaktoren definiert und eine Balance zwischen den internen und externen Messgrößen gesucht wird. Es soll mit Hilfe der BSC möglich sein, das Unternehmen auf den Shareholder Value strategisch auszurichten und anhand von Kennzahlen die erreichten Ziele zu dokumentieren. Die Kennzahlen werden in vier Perspektiven um die Vision und Strategie angeordnet, die in einer Ursache-Wirkungsbeziehung zu einander stehen. In Abbildung 4.20 ist die BSC schematisch aufbereitet.

Abb. 4.20 Balanced Scorecard (vgl. Kaplan u. Norton 1997)

Grundlage für langfristige Veränderungen bietet in der BSC die Lern- und Entwicklungsperspektive, in der die Potentiale der Mitarbeiter, der Informationssysteme und das Arbeitsklima bzw. die Kultur berücksichtigt werden. Die Qualität der Geschäftsprozesse hat für die Kunden- und Anteilseigner Bedeutung und äußert sich in der internen Prozessperspektive, in der Innovationsprozesse ebenso identifiziert werden wie Betriebs- und Serviceprozesse. Kennzahlen werden in dieser Perspektive eingesetzt, um die Wertschöpfung im Unternehmen zu steuern und zu überwachen. Der Markt wird über die Kundenperspektive dargestellt. Wesentlich sind hier die Kennzahlen zur Kundenzufriedenheit, die in einer Erfolgskette als Kundentreue, Kundenrentabilität, Kundenakquisition und schließlich als Markanteil zur Geltung kommen. Führend ist die finanzielle Perspektive, die letztlich das Resultat einer Strategie in monetären Werten abbildet. Unterschieden in drei Lebenszyklusphasen (Wachstum, Reife und Ernte) sind spezielle finanzielle Kennzahlen zu wählen (siehe Abb. 4.21). Während beim Wachstum unter ande-

284

Unternehmensplanung

rem die Investitionsquote relevant ist, ist bei der Ernte auf Stückkosten und die Rentabilität der Kunden zu achten (vgl. Welge u. Al-Laham 1999).

Abb. 4.21 Messzahlen strategischer finanzwirtschaftlicher Themen (vgl. Kaplan u. Norton 1997)

Die BSC kann auf allen Ebenen vom Unternehmen bis hin zum einzelnen Mitarbeiter eingesetzt werden. Wie dabei die BSC der unteren Ebene von der BSC der oberen Ebene beeinflusst wird, hängt von der Methode des Kaskadierens ab. Sind strategische Vorgaben der Unternehmensführung oder der SGE für die Bildung einer BSC ausreichend, so wird diese weitestgehend eigenständig aufgestellt. Die BSC der oberen Ebene legt nur den strategischen Handlungsrahmen fest. Wenn eine intensivere Abstimmung erforderlich ist, so kommt es zu einer Kombination von gegebenen und individuellen Zielen. Aus der BSC der vorgelagerten Organisationseinheit werden diejenigen Ziele übernommen, die von der nachgelagerten unterstützt werden können. Zudem werden strategische Ziele formuliert, die sich nicht aus der BSC der übergeordneten Organisationseinheit ergeben, für den Bereich aber von großer Bedeutung sind. Ist das Definieren individueller Ziele nicht notwendig, so werden lediglich von der BSC der vorgelagerten Organisationseinheit strategische Ziele auf mögliche Unterstützung aus dem Bereich hin untersucht und Maßnahmen zur Erreichung der Ziele beschlossen. Eine Integration der BSC in Zielvereinbarungen der Mitarbeiter ist sinnvoll, um die langfristig gültigen Ziele der BSC an kurzfristig zu erfüllende Aufgaben des Zielvereinbarungs- und Anreizsystems des Unternehmens zu koppeln. Mögliche Konflikte zwischen den beiden Zielsystemen sind jedoch möglich, so dass hier eine intensive Steuerung notwendig ist.

SAP NetWeaver BI-Integrierte Planung

4.3

285

SAP NetWeaver BI-Integrierte Planung

Die BI-integrierte Planung (BI-IP) ist die aktuelle Lösung der SAP zur Realisierung und dem Betrieb von Planungsszenarien innerhalb eines Unternehmens oder einer Organisation. Seit dem SAP NetWeaver Release 2004s ist dieses Planungswerkzeug Teil der Komponente SAP NetWeaver Business Intelligence (BI) und zeichnet sich daher durch die vollständige Integration von Planungs- und BIFunktionalitäten aus. Vor der Marktfreigabe und Einführung von SAP NetWeaver 2004s wurde das Planungsmodul Business Planning and Simulation (BPS) als früherer Bestandteil des Strategic Enterprise Management (SEM) erstmals mit dem SAP Business Warehouse (BW) in der Version 3.5 ausgeliefert und ist neben der BI-IP auch weiterhin im neuen Release SAP NetWeaver 2004s enthalten. Diese parallele Auslieferung von beiden Planungskomponenten ist notwendig, da viele Kunden der SAP das „alte“ Planungsmodul BW-BPS noch in Betrieb haben und auf diese Weise nicht zwingend auf die BI-IP umsteigen müssen. Da die SAP jedoch zukünftig nur die BI-IP weiterentwickeln wird, ist den Anwendern geraten, neue Planungsszenarien auf Basis der neuen Komponente zu entwickeln und alte BW-BPS Planungsapplikationen in naher Zukunft auf die BI-IP zu migrieren (vgl. Egger et al. 2006). Die BI-IP zeichnet sich im Vergleich zum bisherigen Planungsmodul BW-BPS, aber auch bei alleiniger Betrachtung vor allem durch folgende Anforderungen aus (vgl. Egger et al. 2006):  einheitliche, grafische Benutzerschnittstelle für Planung und Analyse  einheitliche Prozess- und Modellierungslogik für Planung und Analyse (z.B. durch die Wiederverwendung von Hierarchien, Variablen, berechneten Kennzahlen etc.)  einheitliche und konsistente Design-Werkzeuge für Planung und Analyse (z.B. Query Designer, Analyzer, Web Application Designer etc.)  einheitliche und konsistente Datenbasis für Planung und Analyse  flexible Planungsmodellierung durch einfache oder komplexe multiple Aggregationsebenen, Versionierungskonzepte, Verwendung von Hierarchien etc.  webbasierte und systemtechnisch unterstützte Modellierungsumgebung für Planungsanwendungen (Planning Wizard und Planning Modeler)  manuelle oder mittels Planungsfunktionen durchgeführte Planung im Web und in MS Excel  Unterstützung der MS Excel-basierten Planung durch anwenderspezifische Nebenrechnungen in MS Excel-Workbooks, ohne die Verbindung zum zentralen Planungsmodell zu verlieren  Unterstützung der Planung durch ausgelieferte und kundenspezifische Planungsfunktionen

286

Unternehmensplanung

 Unterstützung des Planungsprozesses durch Single Point of Entry1, Information Broadcasting und Status- und Tracking-Systeme In den nachfolgenden Abschnitten werden die theoretischen Grundlagen der BI-IP erläutert und die wichtigsten Funktionalitäten in diesem Zusammenhang beschrieben. Mit dem Fokus auf die nachfolgende Fallstudie zum praktischen Einstieg in die Thematik wird dazu in der Theorie zunächst einführend auf die Planungsumgebung eingegangen (Kapitel 4.3.1). Im Anschluss sind die Objekte der Planungsumgebung, sowie die zur Modellierung von Planungsszenarien verwendeten Planungswerkzeuge Planning Wizard und Planning Modeler erläutert (Kapitel 4.3.2), wonach die Grundlagen für das Erstellen von Planungsanwendungen durch die im Business Explorer enthaltenen Design-Werkzeuge angeführt werden (Kapitel 4.3.3). Abschließend findet eine kurze Erläuterung des Sperrkonzepts bzw. der Sperrverwaltung innerhalb der BI-IP statt (Kapitel 4.3.4). Um eine eindeutige Terminologie zu schaffen, bedarf es einer genauen Festlegung der in diesem Abschnitt verwendeten Begrifflichkeiten. Als Planungsszenario wird im Folgenden das ganzheitliche Problem bezeichnet, das mit Hilfe des von SAP NetWeaver 2004s zur Verfügung gestellten Planungsmoduls bzw. der Planungskomponente BI-IP gelöst werden soll. Die Planungsapplikation ist dazu als technische Realisierung bzw. Umsetzung dieses Szenarios zu verstehen, die im Prozess der Planungsmodellierung vom Entwickler erstellt wird. Die daraus entstehende Anwendung zur Abbildung des Planungsszenarios wird hingegen als Planungsanwendung bezeichnet und bildet letztlich die Ebene, mit welcher der Anwender in Kontakt kommt.

4.3.1 Die Planungsumgebung Die BI-integrierte Planungsumgebung kann als die Architektur der BI-IP verstanden werden, anhand derer die Arbeitsumgebung zur Erstellung jeder Planungsapplikation abgeleitet werden kann. Anhand Abbildung 4.22 ist ersichtlich, dass die BI-integrierte Planungsumgebung in einer Grundbetrachtung aus drei Komponenten besteht. Es handelt sich dabei um das Enterprise Data Warehouse (EDW), die Business Planning & Analytic Services und die Komponente Enterprise Reporting, Query & Analysis. In einer erweiterten Betrachtung kann das SAP NetWeaver Portal als vierte Komponente zur Planungsumgebung der BI-IP hinzugezählt werden, da das Portal seit dem Release 2004s auch in Bezug auf die BI-IP eine große Rolle spielt.

1

Die zentrale Einstiegsstelle oder auch Steuereinheit.

SAP NetWeaver BI-Integrierte Planung

287

Abb. 4.22 Architektur der BI-integrierten Planung (vgl. Egger et al. 2006, SAP 2008b)

Die drei Grundkomponenten sowie die vierte Komponente des SAP NetWeaver Portals sollen im Folgenden näher erläutert werden. Dabei geht es in erster Linie um die konzeptuelle Betrachtung der vier Ebenen. Eine detaillierte Beschreibung der einzelnen Werkzeuge und der zur Verfügung stehenden, planungsspezifischen Objekte erfolgt im nachfolgenden Abschnitt im Rahmen der Modellierung von Planungsszenarien (Kapitel 4.3.2). Enterprise Data Warehouse Das Enterprise Data Warehouse (EDW), dass auch als SAP BI Data Warehousing bezeichnet wird, gilt als der Ausgangspunkt einer jeden Planungsapplikation, da es die Datenbasis für die BI-IP bildet. In Form von InfoProvidern liefert das EDW

288

Unternehmensplanung

die notwendigen Daten für das jeweilige Planungsszenario. Entgegen der Datenhaltung in Standard-InfoCubes, wie sie bei der Realisierung von Analyseszenarien verwendet werden, nehmen die in der BI-IP als Realtime-fähige InfoCubes2 bezeichneten InfoProvider die Plandaten auf. Das Planungsszenario selbst wird auf virtuellen InfoProvidern vom Typ Aggregationsebene aufgebaut, die auf solchen Realtime-fähigen InfoCubes oder aber auch MultiProvidern, die mindestens einen Realtime-fähigen InfoCube beinhalten, basieren. Die Modellierung sämtlicher planspezifischer Objekte – sind es Realtimefähige InfoCubes, MultiProvider oder die für die Planungsapplikation notwendigen InfoObjekte – wird aufgrund der einleitend beschriebenen, einheitlichen Prozess- und Modellierungslogik, ebenso wie die Modellierung von analysespezifischen Objekten, über die Data Warehousing Workbench realisiert (vgl. Egger et al. 2006). Business Planning & Analytical Services Die Komponente der Business Planning & Analytical Services stellt zum einen eine Reihe von OLAP-Services zur Verfügung, mittels derer die bereits aus der Datenanalyse bekannten Funktionalitäten wie Drilldown, Durchführung von Berechnungen über Formeln, Variablen, Hierarchien, Aggregationen, Sortierungen etc. auf dem Plandatenbestand ausgeführt werden können. Zum anderen werden auf dieser Ebene aber auch die bereits mehrfach angesprochenen Planungsfunktionen wie Kopieren, Löschen, Umwerten, Umbuchen, Umrechnung, Formel etc. bereitgestellt. Aufbauend auf dem Datenbestand des darunterliegenden Enterprise Data Warehouse, stellt die Ebene der Business Planning & Analytical Services somit die Services zur Verfügung, die notwendig sind, um die Planungsapplikation zu modellieren. Im Zuge der Planungsmodellierung, also der eigentlichen Erstellung der Backend-seitigen Planungsapplikation, stellt das System dem Anwender die webbasierten Planungswerkzeuge Planning Wizard und Planning Modeler zur Verfügung. Der Planning Wizard bietet dem Anwender in diesem Zusammenhang einen leichten Einstieg in die Modellierung, da er einen reduzierten Funktionsumfang zur Verfügung stellt, mit dem die gängigsten Planungsszenarien umgesetzt werden können. Der Planning Modeler hingegen bietet dem erfahrenen Entwickler die Möglichkeit, sämtliche Metadaten, die zu einem Planungsszenario gehören, zu modellieren, zu administrieren und zu testen. Der Planning Modeler kann demnach als das wichtigste Planungswerkzeug der Komponente Business Planning & Analytical Services bezeichnet werden.

2

Im Planungsmodul BW-BPS werden solche InfoProvider als transaktional bezeichnet.

SAP NetWeaver BI-Integrierte Planung

289

Enterprise Reporting, Query & Analysis Die dritte Komponente der BI-integrierten Planungsumgebung dient in erster Linie dem Erstellen von eingabebereiten Plan-Queries mit Hilfe des Query Designers. Der Unterschied zu einer Query, wie sie beispielsweise zur einfachen Datenanalyse verwendet wird, liegt vor allem darin, dass die Daten des zugrundeliegenden InfoProvider aufgrund ihres Planungscharakters manuell über Eingabefelder oder automatisch über Planungsfunktionen verändert werden dürfen. Durch das Einbinden von eingabebereiten Plan-Queries in weitere DesignWerkzeuge des Business Explorer (Analyzer, Web Application Designer etc.) ergibt sich für den Entwickler eine Vielzahl an Möglichkeiten zur praktischen Umsetzung von komplexen Planungsanwendungen. Über den Broadcaster können Web Templates, Queries, Query Views, Reports oder Arbeitsmappen schließlich den betreffenden Personen zugänglich gemacht werden. Dazu bietet das Werkzeug die Möglichkeit, die relevanten Informationen entweder per E-Mail zu versenden, ins Portal zu stellen oder auszudrucken. SAP NetWeaver Portal Das SAP NetWeaver Portal spielt im Kontext der BI-integrierten Planungsumgebung eine besondere Rolle. Durch die vollständige Integration der Planungs- und BI-Funktionalitäten im Zuge der Einführung von SAP NetWeaver 2004s ergibt sich zum einen die Möglichkeit, die Planwerkzeuge Planning Wizard und Planning Modeler direkt aus dem Portal aufzurufen. Da beide Werkzeuge auf dem SAP Java EE3 Server installiert sind und somit über ein Web Dynpro Interface zu erreichen sind, kann über Links oder iViews auf diese Funktionalitäten zugegriffen werden. Auf diese Weise ergibt sich der Vorteil, dass eine lokale Installation des SAP Frontend nicht mehr notwendig ist. Zum anderen bietet das Portal aber vor allem die Möglichkeit, auf fertiggestellte Planungsanwendungen, die über den Broadcaster im Portal veröffentlicht wurden, zuzugreifen und diese auszuführen.

4.3.2 Modellieren von Planungsszenarien Um nun die einzelnen Komponenten der BI-integrierten Planungsumgebung nach der konzeptuellen Betrachtung gleichermaßen auch von der technischen Seiten zu beleuchten, werden die einzelnen zum Einsatz kommenden Technologien und Objekte ausführlicher beschrieben. Dabei wird der Fokus in diesem Abschnitt auf die Planungsmodellierung, also der nach der Datenmodellierung folgende Prozess zur Umsetzung der Planungsapplikation, gelegt. 3

http://java.sun.com/javaee

290

Unternehmensplanung

Ist- und Plandaten in einem InfoCube halten Wie bereits im vorangegangenen Abschnitt kurz angesprochen, wird eine Aggregationsebene im einfachsten Fall auf einem Realtime-fähigen InfoCube entwickelt. Die Abbildung 4.23 veranschaulicht diese Art der Modellierung, in der die Ist- und Plandaten in einem Realtime-fähigen InfoCube gehalten werden. Über eine Query können sowohl die Ist-Daten analysiert als auch die Plandaten erfasst werden – sei es über eine manuelle Planung oder durch den Einsatz von Planungsfunktionen. Um zum Zwecke der Auswertung zwischen den Daten für das Reporting und denen für die Planung zu unterscheiden, ist es bei diesem Modellierungsszenario notwendig, das Merkmal 0VERSION (oder ein vergleichbares Merkmal) im Filter zu verwenden.

Abb. 4.23 Ist- und Plandaten in einem InfoCube halten (vgl. SAP 2008b)

In der Praxis sprechen jedoch zwei Nachteile gegen den Einsatz dieses Modellierungsszenarios. Es sind sehr viele Daten in einem InfoCube enthalten und die Istund Plandaten können nicht parallel geladen werden, da ein Realtime-fähiger InfoCube entweder im Modus zum Erfassen von Plandaten oder im Modus zum Laden von Daten via BI-Staging betrieben wird. Zwischen beiden Modi muss dazu manuell umgeschaltet werden. Von Seiten der SAP wird dieses Modellierungsszenario nicht empfohlen, da aufgrund der dargestellten Nachteile ein hoher, manueller Planungsaufwand entsteht und dies wiederum zu entsprechenden Ausfallzeiten in der Verfügbarkeit des InfoCube führen kann (vgl. SAP 2008b).

SAP NetWeaver BI-Integrierte Planung

291

Ist- und Plandaten in verschiedenen InfoCubes halten Ein durchaus gängigeres Modellierungsszenario spiegelt die Haltung von Ist- und Plandaten in separaten InfoCubes wider. In diesem Fall befinden sich die IstDaten in einem Standard-InfoCube, während die Plandaten in einem Realtimefähigen InfoCube gespeichert werden. Die in Abbildung 4.24 dargestellte Modellierung sieht hierbei die Verwendung eines MultiProvider vor, der die beiden InfoCubes miteinander verbindet. Um nun das Reporting, eine manuelle Planung oder Planungsfunkionen auf den Daten beider InfoCubes ausführen zu können, muss die Aggregationsebene auf diesem MultiProvider basieren. Um die Ist-Daten in den Plan-InfoCube zu kopieren, bietet sich die Standard-Planungsfunktion vom Typ Kopieren an. Diese kann entweder online aus einer Plan-Query gestartet oder als Teil einer Planungssequenz in eine Prozesskette aufgenommen werden. Bei dieser Modellierung wird die Prüfung auf Merkmalbeziehungen unterstützt.

Abb. 4.24 Ist- und Plandaten in verschiedenen InfoCubes halten I (vgl. SAP 2008b)

Eine weitere Möglichkeit zur Modellierung der Ist- und Plandaten in verschiedenen InfoCubes ist es, das Laden der Plandaten aus dem Standard-InfoCube in den Realtime-fähigen InfoCube über einen Datentransferprozess durchzuführen. Gemäß Abbildung 4.25 kann die Aggregationsebene in diesem Fall sowohl auf dem Plan-InfoCube als auch auf einem MultiProvider, der Ist- und Plan-InfoCube erhält, definiert werden. Im Gegensatz zum Einsatz der Planungsfunktion Kopieren bietet die Verwendung eines Datentransferprozesses die Vorteile, dass er einerseits schneller ist und andererseits das Delta-Handling unterstützt, das der Nach-

292

Unternehmensplanung

verfolgung der an den Datensätzen durchgeführten Änderungen dient. Zudem steht bei dieser Variante die Funktionalität der Transformation zur Verfügung. Ein Datentransferprozess kann ebenfalls in eine Prozesskette integriert werden. Bei dieser Modellierung wird die Prüfung auf Merkmalbeziehungen nicht unterstützt.

Abb. 4.25 Ist- und Plandaten in verschiedenen InfoCubes halten II (vgl. SAP 2008b)

Bei beiden dargestellten Vorgehensweisen zur Haltung der Ist- und Plandaten in verschiedenen InfoCubes wird den Nachteilen, die bei der Datenhaltung der Istund Plandaten in einem einzigen InfoCube auftreten, entgegengewirkt. So verteilt sich die Datenmenge auf mehrere InfoCubes und ein manuelles Umschalten der Modi des Realtime-fähigen InfoCube zwischen Datenladen via BI-Staging und dem Erfassen von Plandaten ist nicht mehr notwendig. Lediglich die Modellierung des Szenarios wird aufgrund einer erhöhten Anzahl an planungsspezifischen Objekten (MultiProvider etc.) komplexer. Um einen tieferen Einblick in komplexere Planungsszenarien zu erhalten, wird an dieser Stelle auf weiterführende Literatur verwiesen. Auch Aspekte der Planungsautomatisierung, die sich unter anderem mit der Integration von Planungssequenzen in Prozessketten befasst, würden den Rahmen dieses Buches sprengen. Insbesondere die SAP NetWeaver 7.0 Library bietet zu beiden Themen, aber auch zu anderen hier beschriebenen Konzepten, eine Vielzahl an weiterführenden Informationen.

SAP NetWeaver BI-Integrierte Planung

4.3.2.1

293

InfoProvider

Wie bereits auf konzeptueller Ebene im Rahmen der Planungsumgebung kennengelernt, bilden InfoProvider innerhalb der BI-IP die Datenbasis einer Planungsapplikation. Diese InfoProvider gelten, neben den darin enthaltenen InfoObjekten, als die kleinsten Einheiten einer Planungsapplikation. Ein InfoProvider kann dabei entweder vom Typ MultiProvider oder aber vom Typ Realtime-fähiger InfoCube sein. Letzterer zeichnet sich gegenüber einem Standard-InfoCube durch die Eignung zur Speicherung von Plandaten und damit zur Verwendung in Planungsapplikationen aus. Realtime-fähige InfoCubes sind dabei für Schreibprozesse optimiert, damit mehrere Benutzer gleichzeitig auf dem Realtime-fähigen InfoCube arbeiten und Daten in denselbigen schreiben können. Das Befüllen eines Realtime-fähigen InfoCube erfolgt üblicherweise durch das Anwenden von Planungsfunktionen oder über eine manuelle Planung, kann jedoch auch via BI-Staging erfolgen, sofern der Realtime-fähige InfoCube im Vorfeld dafür umgeschaltet wurde. Nach Egger et al. soll jedoch nach Möglichkeit ein solches Umschalten aufgrund von Modellierungsaspekten vermieden werden. „Besser sind immer ein Plan- und ein Lade-InfoProvider, so dass ein Umschalten eines Realtime-fähigen InfoCubes nicht notwendig ist“ (Egger et al. 2006). Im Zuge der Modellierung von Planungsszenarien können bei der InfoProvider-Auswahl eines Realtime-fähigen InfoCube, als Basis für die spätere Aggregationsebene, außerdem zulässige Kombinationen von Merkmalswerten in Form von Merkmalsbeziehungen und Datenscheiben zum Schutz ausgewählter Daten definiert werden. Beide Konzepte werden im Folgenden kurz erläutert. Merkmalsbeziehungen Bei der Auswahl eines InfoProvider für die Planungsapplikation können Merkmalsbeziehungen definiert werden, um inhaltlich ähnliche Merkmale eines Realtime-fähigen InfoCube miteinander in Beziehung zu setzen. Aus den daraus entstehenden Regeln kann das System aus Merkmalen Werte für weitere Merkmale ableiten. Dies ist beispielweise für die Verfügbarkeit weiterer Auswertungen der ableitbaren Merkmale sinnvoll. Es wird zwischen vier Typen von Merkmalsableitungen unterschieden (vgl. SAP 2008b):    

Attribut: Merkmalskombination basiert auf Stammdaten eines Merkmals Hierarchie: Merkmalskombination basiert auf einer Hierarchie DataStore: Merkmalskombination basiert auf einem DataStore-Objekt Exit: Merkmalskombination basiert auf einer Exit-Klasse

Als Resultat für die Integration von Merkmalsbeziehungen in das Planungsszenario ergibt sich eine Berücksichtigung der festgelegten Regeln, insbesondere für eingabebereite Plan-Queries und Planungsfunktionen. Dies bedeutet, dass die Zellen zu einer ungültigen Merkmalskombination in einer eingabebereiten Query zur

294

Unternehmensplanung

Laufzeit der Planungsanwendung nicht eingabebereit sind. Auch Planungsfunktionen überprüfen vor ihrer Ausführung, ob die Merkmalskombinationen entsprechend der Merkmalsbeziehungen gültig sind und geben im Fall einer ungültigen Kombination eine Fehlermeldung aus (vgl. SAP 2008b). Eine nähere Betrachtung von eingabebereiten Plan-Queries und Planungsfunktionen findet im Fortlauf dieses Abschnitts statt. Datenscheiben Um Daten eines Realtime-fähigen InfoCube gegen Änderungen zu schützen, stellt das System das Konzept der Datenscheiben zur Verfügung. Über die Definition dieser Datenscheiben lassen sich beispielweise bestimmte Planversionen ab einem bestimmten Zeitpunkt nicht mehr ändern. Der Schutz der Daten durch Datenscheiben gilt dabei, analog zu den Merkmalsbeziehungen, sowohl für eingabebereite Plan-Queries, als auch für alle Planungsfunktionen, die diesen Realtimefähigen InfoCube verwenden. Es gibt zwei verschiedene Typen von Datenscheiben (vgl. SAP 2008b):  Selektion: Die Datenscheibe basiert auf einer Selektion, so dass die Einschränkungen für die Merkmale festgelegt werden, die gegen Änderungen geschützt werden sollen  Exit-Klasse: Die Datenscheibe basiert auf einer Exit-Klasse, wodurch eine kundenspezifische Logik zum Schutz der Datensätze implementiert werden kann Somit sind alle Datensätze, die in eine Selektion einer Datenscheibe fallen, innerhalb eingabebereiter Plan-Queries und über Planungsfunktionen nicht änderbar. Sind hingegen keinerlei Datenscheiben definiert, können beliebige, gültige Merkmalkombinationen gebucht werden. Im umgekehrten Fall, in dem zwar Datenscheiben definiert sind, aber keine Merkmalsbeziehungen existieren, wirkt sich die Datenscheibe als Sperre für jegliche Buchungen im gesamten Realtime-fähigen InfoCube aus (vgl. SAP 2008b). 4.3.2.2

Aggregationsebenen

Eine Aggregationsebene definiert sich durch eine Menge von Kennzahlen und Merkmale des zugrunde liegenden InfoProvider und gilt innerhalb der BI-IP somit selbst als ein InfoProvider. Durch die Verwendung von Aggregationsebenen kann festgelegt werden, auf welcher Ebene die Plandaten – manuell über eingabebereite Queries oder automatisiert über Planungsfunkionen – verändert werden dürfen. Da die in der Aggregationsebene enthaltenen Kennzahlen über die nicht in der Aggregationsebene enthaltenen Merkmale verdichtet werden, kann der Entwickler die Granularität, mit der die Daten eingegeben und gespeichert werden, bestimmen.

SAP NetWeaver BI-Integrierte Planung

295

Sofern eine Aggregationsebene auf einem Realtime-fähigen InfoCube aufbaut, ist von einer einfachen Aggregationsebene die Rede. Liegt jedoch ein MultiProvider zugrunde, der mindestens einen Realtime-fähigen InfoCube und keine einfache Aggregationsebene enthält, handelt es sich um eine komplexe Aggregationsebene. 4.3.2.3

Filter

Filter gelten im Rahmen der BI-IP als mehrdimensionaler Ausschnitt von Daten aus einem Datenbestand. Die als Segmentierung bezeichnete Vorgehensweise der Definition eines Filters dient vor allem dazu, Daten für bestimmte Anwender oder Anwendergruppen einzuschränken, um ihnen speziell die relevanten Daten zur Ausführung ihrer Aufgaben innerhalb eines Anwendungsszenarios zur Verfügung zu stellen und sichtbar zu machen. Beispiele sind die Einschränkung der Daten auf bestimmte Geschäftsbereiche, Produktgruppen oder Zeiträume. Über die Definition eines Filters im Zusammenhang der BI-IP wird somit die Selektion von Daten festgelegt, auf der eine Planungsfunktion operiert. Im Falle einer eingabebereiten Plan-Query wird die Datenmenge für das weitere Filtern einer Planungsanwendung zur Laufzeit durch die Verwendung eines Filters eingeschränkt. Filter werden zu einem InfoProvider vom Typ Aggregationsebene anlegt. Als Werkzeuge kommen dabei der Planning Modeler bzw. der Planning Wizard zum Einsatz. Auch der Query Designer erlaubt es, weitere Filter zu einer eingabebereiten Plan-Query festzulegen. Ein Filter besteht dabei aus folgenden Bestandteilen (vgl. SAP 2008b):  Merkmalseinschränkungen: Einschränkungen der Merkmale über Einzelwerte, Wertebereiche, Hierarchieknoten und Variablen zur Bestimmung der Selektion eines Filters.  Vorschlagswerte: Festlegung eines initialen Filterzustands zur Ausführung einer Query. Die Definition der Vorschlagswerte wird analog zu den Merkmalseinschränkungen ausgeführt und ist nur in Queries relevant.

4.3.2.4

Planungsfunktionen

Im Umfeld der BI-IP dienen Planungsfunktionen der systemgestützten Erzeugung und Bearbeitung von Daten. Da eine Planungsfunktion immer auf einer Aggregationsebene definiert wird, beschreibt sie ferner, auf welche Weise die Bewegungsdaten zu dieser bestimmten Aggregationsebene verändert werden. Außerdem bedarf es neben der Festlegung einer Aggregationsebene auch der Definition eines Filters. Alle Arbeitsschritte zur Erstellung von Planungsfunktionen werden mit Hilfe des Planning Modeler bzw. des Planning Wizard durchgeführt. Dazu bietet die BI-IP eine Reihe von Standard-Planungsfunktionstypen an, die das Verfahren vorgeben, nach dem die Daten von einer Planungsfunktion verändert werden. Die

296

Unternehmensplanung

wichtigsten Standard-Planungsfunktionstypen werden im Folgenden kurz vorgestellt (vgl. SAP 2008b):  Kopieren: Die Kennzahlenwerte von bestehenden Merkmalskombinationen werden auf andere Merkmalskombinationen kopiert. Über Tabellen können sowohl die zu kopierenden Kennzahlen ausgewählt, als auch die einzelnen Von- und Nachwerte des Kopiervorgangs festgelegt werden. Dieser Funktionstyp schreibt Nullsätze.  Löschen: Es werden die Kennzahlenwerte der ausgewählten Datensätze gelöscht. Die Auswahl der zu löschenden Kennzahlen wird über eine Tabelle vorgenommen. Merkmalswerte hingegen können nicht verändert werden.  Umbuchen: Ähnlich dem Funktionstyp Kopieren werden beim Umbuchen die Kennzahlenwerte von bestehenden Merkmalskombinationen auf andere Kombinationen umgebucht. Entgegen dem Kopieren werden dabei jedoch die Kennzahlenwerte der Von-Werte gelöscht.  Umwerten: Es werden ausgewählte Kennzahlen um einen bestimmten Prozentsatz erhöht oder verringert. Dabei können alle Kennzahlen um einen gemeinsamen Prozentsatz oder beliebige Kennzahlen mit individuellen Prozentsätzen umgewertet werden. Merkmalswerte werden dabei nicht verändert.  Verteilung nach Schlüsseln: Merkmalskombinationen, auf die verteilt wird, können entsprechend der Stammdaten und Merkmalsbeziehungen erzeugt werden. Die Kennzahlenwerte werden dabei gemäß den ausdrücklich anzugebenen Verteilungsschlüsseln verteilt.  Verteilung nach Referenzdaten: Ähnlich der Verteilung nach Schlüsseln werden Merkmalskombinationen, auf die verteilt wird, entsprechend der Referenzdaten erzeugt. Dabei werden die Kennzahlenwerte auch prozentual entsprechend der Referenzdaten verteilt.  Währungsumrechnung: Währungen aus Kennzahlen werden in andere Kennzahlen umgerechnet.  Einheitenumrechnung: Bei der Einheitenumrechnung können Einheiten aus Kennzahlen über Einheitenrelationen in andere Kennzahlen umgerechnet werden.  Prognose: Über die Verwendung von Prognoseverfahren ist es möglich, Aussagen über die zukünftige Entwicklung von Kennzahlen zu treffen. Dabei wird eine Reihe von verschiedenen, statistischen Prognoseverfahren zur Verfügung gestellt, mittels derer aus historischen Daten Prognosewerte für die geplanten Kennzahlen in der Zukunft berechnet werden.  Löschen ungültiger Kombinationen: Für einfache Aggregationsebenen werden alle Kennzahlenwerte sämtlicher Datensätze auf Null gesetzt, deren Kombinationen von Merkmalswerten nicht mit den Merkmalskombinationen des zugrunde liegenden Realtime-fähigen InfoCube übereinstimmen.  Umbuchen nach Merkmalsbeziehungen: Ebenfalls nur für einfache Aggregationsebenen können Bewegungsdaten so umgebucht werden, dass sie wieder zu den Merkmalsbeziehungen des Realtime-fähigen InfoCube konsistent sind.

SAP NetWeaver BI-Integrierte Planung

297

 Formel: Über eine einfache Programmiersprache können Formeln definiert werden, die beliebige Manipulationen an den Bewegungsdaten zulassen. Die Formelsprache FOX bietet dem Anwender dazu eine umfangreiche Funktionalität.

4.3.2.5

Planungssequenzen

Durch das Erstellen einer Planungssequenz im Rahmen der BI-IP wird eine Gruppierung von Planungsfunktionen vorgenommen. Dabei können einzelne Planungsfunktionen in beliebiger Reihenfolge zu einer Planungssequenz zusammengesetzt und als eine solche gespeichert werden. Zu jeder Planungsfunktion innerhalb der Planungssequenz müssen eine Aggregationsebene, die Planungsfunktion selbst und ein dazugehöriger Filter festgelegt werden. Wird die Planungssequenz im Anschluss ausgeführt, so werden alle enthaltenen Planungsfunktionen sequentiell abgearbeitet. Planungssequenzen werden ausschließlich im Planning Modeler bearbeitet, gespeichert und getestet und können desweiteren als Schritt in Prozessketten eingebunden werden. 4.3.2.6

Variablen

Variablen dienen als Platzhalter für Merkmalswerte, Hierarchien, Hierarchieknoten, Texte und Formelelemente und können somit in Queries, Planungsfunktionen, Filtern, Merkmalsbeziehungen oder Datenscheiben zum Einsatz kommen. Erst bei der Ausführung von Queries, Planungsfunktionen oder Web Applikationen werden die Variablen mit festen Werten gefüllt. Der Vorgang der Definition von Variablen wird auch als Parametrisierung bezeichnet. Ein Beispiel für eine sinnvolle Verwendung von Variablen ist die Parametrisierung des Merkmals Version in den Vor-Parametern einer Planungsfunktion vom Typ Kopieren. Auf diese Weise kann erst direkt vor dem Ausführen der Planungsfunktion entschieden werden, aus welcher Version die Daten in die aktuelle Planungsanwendung kopiert werden sollen. Desweiteren sind Variablen nur vom jeweiligen InfoObjekt abhängig und nicht von einem InfoProvider. Allerdings steht die Variable in allen InfoProvidern zur Verfügung, die das InfoObjekt verwenden, für welches die Variable zuvor definiert wurde. Analog zum Erstellen von Filtern können auch Variablen sowohl im Planning Modeler bzw. Planning Wizard als auch im Query Designer definiert werden. Als Werkzeuge zum Definieren von Variablen stellt das System den sogenannten Variablen-Wizard sowie den Variablen-Editor bereit. Ersterer unterstützt den Entwickler in einer Schritt-für-Schritt-Abfolge beim Anlegen von Variablen, während der Variablen-Editor alle Möglichkeiten zum Ändern und Anzeigen von Variablen zur Verfügung stellt (vgl. SAP 2008b).

298

Unternehmensplanung

Um abschließend eine kurze Übersicht über die Einsatzmöglichkeiten von Variablen in Bezug auf deren Verwendung in unterschiedlichen Objekten zu geben, sind diese in der nachfolgenden Tabelle 4.5 aufgelistet. Tabelle 4.5 Einsatzmöglichkeiten von Variablen (vgl. SAP 2008b) Objekt

Verwendung von Variablen

Queries4

in Formeln, Bedingungen, Exceptions, als Platzhalter für Texte, sowie zur Parametrisierung von Merkmalseinschränkungen in der Query

Filter

zur Parametrisierung von Merkmalseinschränkungen, die den Filter beschreiben

Planungsfunktionen

abhängig vom jeweiligen Planungsfunktionstyp für die Parametrisierung von Bedingungen und Parametern (z.B. Parametrisierung des Umwertungsfaktors in der Planungsfunktion vom Typ Umwertung)

Merkmalsbeziehungen5 zur Parametrisierung der verwendeten Hierarchien oder der Selektion aus einem DataStore-Objekt Datenscheiben5

zur Parametrisierung von Merkmalseinschränkungen, die die Datenscheibe beschreiben

weitere Objekte

z.B. für die Parametrisierung der Präsentationshierarchie in der Query

4.3.3 Erstellen von Planungsanwendungen Planungsanwendungen dienen der Interaktion des eigentlichen Anwenders mit dem System. Bei Planungsanwendungen handelt es sich um Anwendungen der Business Intelligence, denen die im Zuge der Planungsmodellierung erstellte Planungsapplikation zugrunde liegt. Über die aus dem Reporting bekannten DesignWerkzeuge BEx Analyzer (für MS Excel-basierte Planungsanwendungen) und BEx Web Application Designer (für webbasierte Planungsanwendungen) werden die Objekte der Planungsumgebung zu einer interaktiven Anwendung verknüpft, um dem Anwender die manuelle und automatische Erfassung bzw. Manipulation von Daten zu ermöglichen. Neben den datentragenden InfoProvidern und den darauf aufbauenden Aggregationsebenen, die die Daten für die Datenerfassung und änderung verdichtet bereitstellen, bedarf es des Weiteren entweder einer eingabebereiten Plan-Query für die manuelle Eingabe von Plandaten, oder Planungsfunktionen, die die Änderungen der Daten in automatisierter Form vornehmen. Im letzten Fall können auch Planungssequenzen zum Einsatz kommen, um Teile des Datenflusses zu modellieren (vgl. SAP 2008b). Angefangen mit den eingabebereiten Plan-Queries, deren Erstellung mit Hilfe des BEx Query Designers erfolgt, werden in den nachfolgenden Abschnitten auch 4

Im Rahmen der BI-IP insbesondere eingabebereite Plan-Queries. Die Variablen müssen zum Ausführungszeitpunkt einen Wert besitzen und dürfen keinen Dialog für die manuelle Eingabe von Werten hervorrufen. 5

SAP NetWeaver BI-Integrierte Planung

299

die Erstellung einer Planungsanwendung mit dem BEx Analyzer und die Planung mit dem BEx Web Application Designer behandelt. 4.3.3.1

Eingabebereite Plan-Queries mit dem BEx Query Designer

Mit dem SAP NetWeaver Release 2004s ist im Gegensatz zur ursprünglichen BW-BPS eine Reihe von Vereinfachungen beim Erstellen von Planungsanwendungen realisiert worden. Der bereits mehrfach angesprochene, integrative Anspruch der BI-IP kommt dabei durch die Wiederverwendung der bekannten Reporting-Werkzeuge beim Erstellen von Planungslayouts ganz besonders zur Geltung. Neben der Wiederverwendung von InfoProvidern in Form von Realtime-fähigen InfoCubes können nun auch die Reporting-Queries in leicht veränderter Weise für Planungszwecke genutzt werden. Diese sogenannten eingabereiten Plan-Queries dienen dem Erstellen von Anwendungen für die manuelle Planung, deren Ausprägungen dabei von einer einfachen Datenerfassung bis hin zu komplexen Planungsanwendungen reichen kann. In der Praxis kommt dazu der bekannte Query Designer zum Einsatz, der die nachfolgenden Funktionen im Rahmen der Planung zur Verfügung stellt (vgl. Egger et al. 2006):        

Drill Down Hierarchische Strukturen in Zeilen und Spalten Berechnete Kennzahlen Strukturen Alerts Bedingungen Unterstützung des Planungsprozesses durch Grafiken und Tabellen Währungsumrechnungen etc.

Wie alle anderen Planungsfunktionen setzt eine eingabebereite Plan-Query auf einer Aggregationsebene auf, die zuvor über den Planning Modeler bzw. Planning Wizard modelliert wurde. Auch MultiProvider, in denen mindestens eine einfache Aggregationsebene vorhanden ist, können als Basis für eine eingabebereite PlanQuery dienen. Dabei ist zu beachten, dass über die Aggregationsebene die Granularität der im InfoProvider abgelegten, manuellen Planwerte bestimmt wird. Außerdem gilt es zu berücksichtigen, dass die Eingabebereitschaft einer Plan-Query nur gewährleistet ist, wenn die eingegebenen Planwerte eindeutig im Sinne einer konsistenten Datenhaltung sind, d.h. sofern die Planwerte einer eindeutigen Merkmalsausprägung zugeordnet werden können. Um festzulegen, welche der einzelnen Strukturbestandteile (Kennzahlen oder eingeschränkte Kennzahlen) zur Laufzeit einer Query eingabebereit, nicht eingabebereit oder nur durch Planungsfunktionen veränderbar sein sollen, bietet der Query Designer dem Entwickler die folgenden Eigenschaften zur Bestimmung der Eingabebereitschaft eines jeden Strukturbestandteils (vgl. SAP 2008b):

300

Unternehmensplanung

 Nicht eingabebereit (nicht sperrrelevant): Die Daten des Strukturbestandteils sind weder durch Eingaben des Benutzers, noch durch Planungsfunktionen veränderbar. Diese Einstellung ist standardmäßig für alle Elemente gewählt und ist beispielweise für Ist-Daten sinnvoll, die den Anwendern als Referenz dienen.  Nicht eingabebereit (sperrrelevant): Die Daten sind gegen manuelle Eingaben des Anwenders geschützt, können jedoch durch Planungsfunktionen verändert werden. Dies ist unter den Umständen denkbar, wenn eine Planungsfunktion mit angezeigten und nicht etwa mit mittlerweile vom Anwender veränderten Daten arbeiten soll.  Eingabebereit (sperrrelevant): Die Daten dürfen sowohl durch den Anwender als auch durch Planungsfunktionen verändert werden. Des Weiteren bietet der Query Designer die Möglichkeit, Resultatszeilen oder innere Hierarchieknoten als eingabebereit zu deklarieren. Diese aggregierten Werte müssen aufgrund der geforderten Eindeutigkeit, im Sinne der konsistenten Datenhaltung, in einem solchen Fall auf alle darunterliegenden Datensätze disaggregiert werden. Dazu bietet das System eine Reihe von Verteilungsarten an, nach denen die Datensätze, die zu dem aggregierten Wert beitragen, verteilt werden. Diese Disaggregation wird auch als Top-Down-Verteilung bezeichnet. Neben allen genannten Voraussetzungen kann zudem festgelegt werden, ob eine Query im Änderungsmodus oder im Anzeigemodus gestartet werden soll. 4.3.3.2

Planung mit dem BEx Web Application Designer

Über den Web Application Designer lassen sich nach Erstellung von Planungsfunktionen und eingabebereiten Plan-Queries nun die webfähigen Planungscockpits erstellen, die letztlich die Planungsanwendungen im Rahmen des umzusetzenden Planungsszenarios darstellen. Gegenüber den im nachfolgenden Abschnitt beschriebenen MS Excel-basierten Planungsanwendungen, die mit Hilfe des Analyzer erstellt werden, haben die webbasierten Planungsanwendungen den Vorteil, dass sie wesentlich schneller sind, bessere Gestaltungsmöglichkeiten bieten und vor allem zur Ausführung sehr flexibel über das Web erreichbar sind (vgl. Egger et al. 2006). Da die grundlegenden Funktionen dieses Werkzeugs bereits im dritten Kapitel im Zuge des SAP BI Reporting intensiv behandelt wurden, konzentriert sich dieser Abschnitt auf die neuen Funktionen des Web Application Designers im Zusammenhang mit der BI-IP. Um eine Planungsanwendung mit dem Web Application Designer zu realisieren, bedarf es der Verwendung einer eingabebereiten Plan-Query als Data Provider. Auf dieser Basis ist es möglich, eine Reihe von neuen Befehlen in das Web Template zu integrieren, die speziell für die Verwendung in Planungsanwendungen bestimmt sind. Die beispielsweise über Schaltflächen ausführbaren Befehle werden im Folgenden aufgezählt und kurz erläutert. Auf die technischen Bezeich-

SAP NetWeaver BI-Integrierte Planung

301

nungen der einzelnen Befehle wird an dieser Stelle aus Gründen der Übersichtlichkeit verzichtet (vgl. SAP 2008b):  Daten aktualisieren: Über diesen Befehl werden die geänderten Daten aus einer eingabebereiten Plan-Query zunächst auf ihre Korrektheit überprüft und bei erfolgreichem Ausgang dieser Überprüfung in den Planungspuffer übernommen, so dass sich die veränderten Daten auf die anderen Teile der Web Applikation auswirken. Insbesondere bei der manuellen Erfassung von Plandaten ist dies sinnvoll, um beispielweise die eingegeben Daten in ein in die Anwendung integriertes Diagramm einfließen zu lassen.  Geänderte Daten sichern: Sofern die Daten durch manuelle Eingaben oder mit Hilfe von automatischer Planungsfunktionen geändert wurden, können sie mittels dieses Befehls in den zugrundeliegenden InfoProvider geschrieben und somit gesichert werden. Es findet ebenfalls eine Überprüfung statt und es werden immer alle Daten innerhalb der gesamten Web Applikation gesichert.  Geänderte Daten zurücksetzen: Dieser Befehl dient dazu, den letzten gespeicherten Datenzustand einer Web Applikation wieder herzustellen und somit alle seitdem durchgeführten Änderungen rückgängig zu machen. Datenänderungen, die vor Ausführung des Befehls zum Sichern von geänderten Daten durchgeführt wurden, können nicht zurückgenommen werden.  Modus für Dateneintrag festlegen: Da eingabebereite Plan-Queries wie im vorherigen Abschnitt beschrieben entweder im Anzeigemodus oder im Änderungsmodus gestartet werden können, kann mit Hilfe dieses Befehls zwischen den Modi gewechselt werden. Zudem kann im Web Application Designer über Parameter eingestellt werden, auf welchen Data Provider sich der Befehl bezieht und welcher Modus beim Starten der Anwendung aktiv sein soll.  Planungsfunktion ausführen (einfach): Dieser Befehl wird zum Anstoßen der Ausführung einer Planungsfunktion verwendet. Hierbei werden alle Merkmalsselektionen durch die Angabe eines einzigen Data Providers bestimmt. Der Data Provider kann dazu vom Typ Filter oder vom Typ Query View sein.  Planungsfunktion ausführen: Um die Ausführung einer Planungsfunktion anzustoßen und entgegen des Befehls zur einfachen Ausführung einer Planungsfunktion dabei für jedes Merkmal einzeln anzugeben, wie die Selektion bestimmt werden soll, wird dieser Befehl verwendet.  Planungssequenz ausführen (einfach): Dieser Befehl dient dem Anstoßen der Ausführung einer Planungssequenz. Auch hier können über den BefehleWizard weitere Parameter bestimmt werden. So zum Beispiel die Datenanbindung von Varianten oder Variablen. Fertige Planungsanwendungen, die mit dem Web Application Designer erstellt wurden, können über eine Vielzahl an Möglichkeiten an die betreffenden Personen verteilt werden. Als Neuerung des aktuellen Releases von SAP NetWeaver bietet sich hier die Option, Planungsanwendungen über den Broadcaster als iViews oder Links ins Portal an das SAP NetWeaver Portal zu senden.

302

Unternehmensplanung

4.3.3.3

Planung mit dem BEx Analyzer

Neben dem Web Application Designer bietet auch der Analyzer die Möglichkeit, einfache bis komplexe Planungsanwendungen zu erstellen, in denen unter Verwendung von eingabebereiten Plan-Queries Daten manuell oder über den Einsatz von Planungsfunktionen erfasst werden können. Der Analyzer zeichnet sich dabei vor allem durch die Verbindung der Funktionalität der BI-IP mit dem für vielerlei Anwender bereits bekannten Funktionsumfang von MS Excel aus. Zwar ergeben sich im Gegensatz zum Web Application Designer gewisse Einschränkungen im Hinblick auf Schnelligkeit und Flexibilität, doch dementgegen steht der Vorteil, dass mit diesem Werkzeug sehr mächtige Planungsanwendungen für die manuelle Planung erstellt werden können, die unter Zuhilfenahme von Planungsfunktionen Datenänderungen auch automatisiert durchführen (vgl. SAP 2008b). Das Besondere dabei ist zudem, dass zusätzlich auf die breite Funktionalität der in vielen Unternehmen und Organisationen genutzten Software MS Excel zurückgegriffen werden kann. Da auch in diesem Abschnitt primär auf die Neuerungen, die im Rahmen der Einführung von SAP NetWeaver 2004s realisiert wurden, eingegangen wird, folgt zunächst eine Auflistung der wichtigsten Charakteristika, die den Analyzer als Design-Werkzeug der BI-IP ausmachen (vgl. Egger et al. 2006):  Erstellung komplexer Planungsanwendungen über den Designmodus, der es ähnlich dem Web Application Designer erlaubt, Funktionsbuttons zum Anstoßen von Planungsfunktionen und/oder Planungssequenzen zu integrieren, manuell erfasste Daten zurück in den InfoProvider zu schreiben etc.  lokale MS Excel-Arbeitsmappen können Erweiterungen und Nebenrechnungen beinhalten, die mit dem Auffrischen der Query synchron zum BI-System gehalten werden.  Single Point of Truth6 durch die Verbindung der MS Excel-Flexibilität zur zentralen Bereitstellung von MS Excel-Arbeitsmappen und der Integrität des BI-Systems.  bisher genutzte Planungsmappen in MS Excel können einfach mit Funktionen der BI-IP angereichert werden.  Verwendung reiner, MS Excel-basierter Funktionen in Planungsarbeitsmappen (z.B. Formeln, Grafiken, Pivot-Tabellen etc.).  Erweiterung der Planungsanwendung durch Visual-Basic-Programmierung. Insbesondere im Hinblick auf die Funktionalität der angestrebten Planungsanwendung stehen im Analyzer ähnliche Möglichkeiten zur Verfügung, die dem Ersteller auch bereits im Web Application Designer angeboten werden. Anhand des sogenannten Befehle-Wizard kann eine Reihe von planungsspezifischen und Data Provider-spezifischen Befehle in die Planungsanwendung integriert werden, die 6

Prinzip, bei dem ein Datenbestand als einzige Quelle der Wahrheit existiert, auf dessen Inhalt Verlass ist.

SAP NetWeaver BI-Integrierte Planung

303

über Funktionsbuttons zur Laufzeit der Planungsanwendung durch den Anwendern ausgeführt werden können. Da diese Befehle den bereits im vorherigen Abschnitt beschriebenen Befehlen für Planungsanwendungen im Web Application Designer sehr ähnlich sind, werden sie anhand der nachfolgenden Tabellen 4.6 (für die planungsspezifischen Befehle) und 4.7 (für die Data-Provider-spezifischen Befehle) des Befehle-Wizard nur tabellarisch aufgelistet und kurz beschrieben. Tabelle 4.6 Planungsspezifische Befehle des Befehle-Wizard (vgl. SAP 2008b) Wizard-Option

Beschreibung / Vergleich zum Web Application Designer

Sichern

Analog zum Befehl Geänderte Daten sichern werden die geänderten Daten in den InfoCube bzw. die InfoCubes geschrieben.

Werte übertragen

Analog zum Befehl Daten aktualisieren werden die geänderten Daten nach einer Überprüfung in den Planungspuffer geschrieben.

Planungsfunktion ausführen Analog zum Befehl Planungsfunktion ausführen wird eine ausgewählte Planungsfunktion angestoßen. Variablen können zuvor gesetzt werden. Planungssequenz ausführen

Analog zum Befehl Planungssequenz ausführen wird eine ausgewählte Planungssequenz angestoßen. Variablen können zuvor gesetzt werden.

Tabelle 4.7 Data-Provider-spezifische Befehle des Befehle-Wizard (vgl. SAP 2008b) Wizard-Option

Beschreibung / Vergleich zum Web Application Designer

Bearbeiten

Ähnlich dem Befehl Modus für Dateneintrag festlegen wird der Data Provider in den Änderungsmodus geschaltet.

Darst.

Ähnlich dem Befehl Modus für Dateneintrag festlegen wird der Data Provider in den Anzeigemodus geschaltet.

Filterbefehl

Es wird ein Dialogfenster zur Auswahl der Dimension geöffnet, sofern der gewählte Data Provider unterstützt wird.

Query/Query View zuordnen Auswahl von Query oder Query View, die bzw. der als Basis für den Data Provider gelten soll.

4.3.4 Sperrkonzept und Sperrverwaltung Sobald ein Anwender Bewegungsdaten im Änderungsmodus anfordert, muss sichergestellt sein, dass die Daten exklusiv für diesen Anwender gesperrt werden. Diesem Problem nähert sich das Sperrkonzept der BI-IP, das neben den in den vorherigen Abschnitten behandelten Konzepten ebenfalls einen wesentlichen Bestandteil einer Planungsapplikation darstellt. Da die Realtime-fähigen InfoCubes die Basis jeglicher Planungsanwendungen bilden und in ihnen Plandaten abgelegt und gespeichert werden, kommt diesen Objekten in der Sperrverwaltung ein besonderes Augenmerk zuteil. Es ist von erhöhter Wichtigkeit, in Abhängigkeit der

304

Unternehmensplanung

zu erwartenden Last, bei der insbesondere die Anzahl der parallelen Benutzer, aber auch die Komplexität der Selektionen im Vordergrund stehen, ein geeignetes Sperrverfahren aus einer Auswahl von angebotenen Sperrverfahren auszuwählen (vgl. Egger et al. 2006). Um verschiedene Sperrsituationen verwalten zu können, stellt die BI-IP die Transaktion RSPLSE zur Verfügung. Innerhalb dieser Transaktion hat der Anwender unter anderem die Möglichkeit, unterschiedliche Sperrmodi für ausgewählte Datensätze auszuwählen. So kennzeichnet beispielweise der Buchstabe E den Sperrmodus, bei dem nur der aktuelle Benutzer Änderungen an ausgewählten Datensätzen vornehmen darf. Eine sogenannte Shared-Sperre hingegen erlaubt es mehreren Benutzern gleichzeitig, lesend auf bestimmte Datensätze zuzugreifen (ein gleichzeitiges Schreiben ist nicht erlaubt) und wird in der Sperrverwaltung mit dem Buchstaben S gekennzeichnet. Weiterhin besteht die Möglichkeit, sich Informationen über bereits aufgetretene Sperrkonflikte anzeigen zu lassen, um festzustellen, warum ein Sperrkonflikt auslöst wurde und ob gegebenenfalls Anpassungen am Sperrkonzept vorgenommen werden müssen. Außerdem können in der Administration des Sperrservers Sperrmerkmale zu einem InfoCube definiert werden, da konstante Merkmale, wie zum Beispiel ein Geschäftsjahr, im Zuge eines Planungsvorgangs meist unverändert bleiben und somit keiner expliziten Sperrung bedürfen. Da die Anzahl der Sperrmerkmale als entscheidend für die Performance des Sperrservers gilt, hat diese Auswahl relevanter Sperrmerkmale für einen InfoCube durchaus seine Berechtigung (vgl. Kießwetter et al. 2008).

4.4

Fallstudie B: BI-Integrierte Planung

Aufbauend auf der ersten Fallstudie zum SAP BI Data Warehousing, erweitert diese zweite Fallstudie das bisherige Szenario um die Möglichkeiten der BIintegrierten Planung. Auf diesem Wege wird das Spektrum des Anwenders in Bezug auf die Funktionen des SAP BI erweitert. Die in der ersten Fallstudie modellierten BI-Objekte werden in dieser zweiten Fallstudie weiter verwendet und deren Inhalte somit als bekannt vorausgesetzt. Einfache Arbeitsschritte, die bereits in der ersten Fallstudie in ähnlicher Form erklärt sind, werden daher in dieser zweiten Fallstudie nicht weiter im Detail behandelt. Der inhaltliche Aufbau beginnt konsistent zur ersten Fallstudie mit dem Abschnitt der Datenmodellierung, in dem weitere, notwendige BI-Objekte modelliert werden. Im zweiten Abschnitt steht im Gegensatz zur Datenmodellierung in der ersten Fallstudie, die Planungsmodellierung im Vordergrund, in der der Fokus auf das Erstellen von Planungsfunktionen gerichtet ist. Im dritten und letzten Abschnitt dieses Kapitels wird abschließend das Erstellen von Planungsanwendungen beschrieben, das gewisse Ähnlichkeiten zum Reporting in der ersten Fallstudie aufweist, sich jedoch maßgeblich über die Planungsfunktionalitäten vom bisher Kennengelernten absetzt.

Fallstudie B: BI-Integrierte Planung

305

Bei der Durchführung bedarf es auch in dieser zweiten Fallstudie der Einhaltung der Richtlinien des verwendeten Systems und einer eventuellen Anpassung des Präfixes UO für Uni Oldenburg, das in der Fortführung des Szenarios weiterhin genutzt wird. Die zugrundeliegenden Namenkonventionen können vom Systembetreiber angefordert werden. Beispielszenario und Aufgabenstellung Aufgrund der besonders guten Ergebnisse, die der von Ihnen erstellte Prototyp im SAP BI Data Warehousing geliefert hat, möchte sich die 4INSTANCE AG nun auch mit den weiteren Funktionalitäten des SAP BI Data Warehousing vertraut machen und plant dazu insbesondere die Verwendung der mit dem BI ausgelieferten Komponente zur BI-integrierten Planung. Da diese Planungskomponente mittlerweile völlig in die SAP BI integriert ist, ergibt sich für die 4INSTANCE AG eine Menge von Vorteilen. Die BI-integrierte Planung liefert ein einheitliches User-Interface für Analyse und Planung, verwendet dabei eine einheitliche Prozess- und Modellierungslogik, bietet einheitliche und aus der ersten Fallstudie bereits bekannte Design-Tools, wie zum Beispiel den Query Designer oder auch den Web Application Designer und arbeitet vor allem auf einer einheitlichen und konsistenten Datenbasis für Analyse und Planung (vgl. Egger et al. 2006). Da Sie sich mittlerweile gut mit SAP BI auskennen, beauftragt die 4INSTANCE AG Sie mit der Erweiterung des bisherigen Prototyps um folgende Planungsfunktionalität: Die Entscheidungsträger möchten die Umsätze für das 2. Halbjahr 2008 planen und sich dabei zunächst grob an den guten Umsatzergebnissen aus dem Monat März 2008 orientieren. Desweiteren sollen die bisher nur in schriftlicher Form vorliegenden Planwerte für das 1. Halbjahr 2008 manuell in der Planungsanwendung nachgepflegt werden können, um so beispielweise die prozentuale Abweichung von einstigen Plan- zu tatsächlichen Ist-Daten anschaulich darzustellen. Die Entscheidungsträger wünschen sich eine übersichtliche Planungsanwendung im Web, die diese Anforderungen vereint und sich besonders durch Benutzerfreundlichkeit auszeichnet, damit die Akzeptanz beim späteren Anwender gegeben ist. Unter Benutzerfreundlichkeit verstehen die Entscheidungsträger eine klare Struktur, die Integration von Schaltflächen zur einfachen Handhabung und die Visualisierung der vorliegenden Daten über angemessene Diagramme sowie Tabellen. In enger Absprache mit der Planungsabteilung einigen Sie sich mit den dortigen Mitarbeitern auf die Verwendung eines Realtime-fähigen InfoCube, der die späteren Plandaten enthalten soll. Die Struktur dieses Plan-InfoCube soll gleich der Struktur des in der ersten Fallstudie angelegten Standard-InfoCube sein, der bereits die Ist-Daten enthält. Die Verbindung dieser beiden InfoCubes soll über einen MultiProvider realisiert werden, um eine sinnvolle Grundlage für die spätere Analyse und Planung zu schaffen.

306

Unternehmensplanung

Da die Entscheidungsträger die Umsätze des Monats März 2008 gerne als Richtwerte für das 2. Halbjahr 2008 verwenden möchten, verständigen Sie sich mit den erfahrenen Planern der 4INSTANCE AG darauf, die Ist-Daten des StandardInfoCube zur Initialisierung einer Planungsrunde als erstmalige Planwerte – unter Verwendung einer entsprechenden Planungsfunktion – in den Plan-Cube zu kopieren. Um weitere Planungsrunden durchführen zu können, ist auch die Realisierung einer Löschfunktion wünschenswert, die es ermöglicht, alle Datensätze aus dem Plan-InfoCube zu löschen. Sollte sich der Prototyp für die Planung als Erfolg erweisen, so besteht später die Möglichkeit, vorherige Planungsrunden in separate InfoProvider zu kopieren bzw. fortzuschreiben, dies soll jedoch nicht Teil des geplanten Prototyps sein. Nach der Daten- und Planungsmodellierung wird es Ihre letzte Aufgabe sein, mit dem BEx Web Application Designer eine umfangreiche Planungsanwendung zu erstellen. Diese Planungsanwendung soll es ermöglichen, sowohl die einzelnen Planungsfunktionen wie Löschen und Kopieren über entsprechende Schaltflächen auszuführen, aber auch eine manuelle Bearbeitung der Plandaten für das 2. Halbjahr 2008 direkt im Webbrowser vorzunehmen. Der Bericht soll desweiteren die Möglichkeit bieten, die Sicht auf die einzelnen Filialen durch die Verwendung einer Dropdown-Box einzuschränken. Die Darstellung der Plan- und Ist-Daten sowie deren prozentuale Abweichung sollen dabei sowohl in einer Ergebnistabelle, als auch in einem übersichtlichen Diagramm erfolgen.

4.4.1 Teil I - Datenmodellierung Die erste Aufgabe dieses Kapitels lautet, die für die angestrebte Planungsanwendung benötigten Objekte, aufbauend auf den bereits erstellen SAP BI-Objekten, zu modellieren. Dazu kommt die schon in der ersten Fallstudie kennengelernte Data Warehousing Workbench zum Einsatz, anhand derer das Datenmodell um die gewünschte Funktionalität erweitert wird. Im ersten Teil dieses Abschnitts steht die Modellierung eines sogenannten Realtime-fähigen InfoCube im Vordergrund. Die BI-integrierte Planung sieht vor, Plandaten in dieser speziellen Form eines InfoCube abzulegen. Realtime-fähige InfoCubes sind im Gegensatz zu den Standard-InfoCubes für Schreibprozesse optimiert, so dass mehrere Benutzer parallel Daten in den Realtime-fähigen InfoCube schreiben können. Dies erweist sich insbesondere für Planungsanwendungen als äußerst nützlich. Der in dieser Fallstudie zu erstellende Realtime-fähige InfoCube wird angelegt, indem der bereits im System vorhandene Standard-InfoCube zur Speicherung der Ist-Daten als Vorlage verwendet wird. Auf diese Weise wird zum einen der Modellierungsaufwand reduziert, da keine InfoObjekte per Hand in die Struktur des InfoCube eingefügt werden müssen. Zum anderen kann durch die Verwendung der Vorlage des Standard-InfoCube für den Realtime-fähigen InfoCube sichergestellt werden, dass die Datenmodelle beider Cubes identisch und

Fallstudie B: BI-Integrierte Planung

307

somit voll integriert sind. Dadurch ergibt sich eine vollkommende Vergleichbarkeit der ebenfalls identischen Kennzahlen, auch wenn sich die beiden InfoCubes in ihren Ausprägungen in Form von Ist- bzw. Plandaten unterscheiden. Im zweiten Teil dieses Abschnitts werden beide InfoCubes durch einen MultiProvider zusammengeführt. Auf diese Weise werden die Ist-Daten des StandardInfoCube und die Plandaten des Realtime-fähigen InfoCube als eine ganzheitliche Datenquelle behandelt. Der MultiProvider selbst enthält keine Daten, sondern bezieht diese ausschließlich aus den zugrundeliegenden InfoProvidern. Da beide InfoCubes in dieser Fallstudie identisch aufgebaut sind, können alle Merkmale und Kennzahlen im MultiProvider ohne Einschränkungen vernetzt werden. Dies wirkt sich unter anderem vorteilhaft auf die Erstellung einer Query aus, da nicht auf unterschiedliche Ausprägungen von Merkmalen oder die speziellen Eigenschaften von Kennzahlen geachtet werden muss. Zum Abschluss der Datenmodellierung wird im System eine Dokumentation zu dem MultiProvider erstellt, die in Form eines Textdokuments Aufschluss über die Verwendung dieses InfoProviders gibt. Dadurch wird es dem Anwender ermöglicht, über die Hilfe zu diesem Objekt, einen Einblick in die Metadaten und somit auch in die vom Ersteller verfasste Dokumentation zu erhalten.

308

Unternehmensplanung

4.4.1.1

Anlegen des Realtime-fähigen InfoCube

Melden Sie sich über die Anwendung SAPLogon am SAP System an und starten Sie über die Transaktion RSA1 die DWB Modellierung.

Abb. 4.26 Realtime-fähigen InfoCube anlegen I

Klicken Sie in der Sicht InfoProvider (siehe Abb. 4.26 Realtime-fähigen InfoCube anlegen I, Schritt 1) mit einem Rechtsklick auf Ihre InfoArea Fallstudie BW ##, um das kontextsensitive Menü zu öffnen (Schritt 2). Wählen Sie den Eintrag InfoCube anlegen (Schritt 3) und vergeben Sie im darauffolgenden Dialog unter InfoCube den technischen Namen UO_ICP_## (Schritt 4) und die Beschreibung Produkt-Umsatz Planung Fallstudie BW ## an (Schritt 5). Als Vorlage soll der in der ersten Fallstudie erstellte Ist-Daten InfoCube Produkt-Umsatz Ist Fallstudie BW ## dienen. Geben Sie dazu den technischen Namen UO_ICI_## im dafür vorgesehenen Feld ein (Schritt 6). Da es sich bei dem anzulegenden InfoCube um einen Realtime-fähigen InfoCube handeln soll, selektieren Sie außerdem die Option real-time im Gruppierungsfeld InfoProviderTyp (Schritt 7). Um fortzufahren, klicken Sie auf die Schaltfläche Anlegen (Schritt 8).

Fallstudie B: BI-Integrierte Planung

309

Abb. 4.27 Realtime-fähigen InfoCube anlegen II

Die Einstellungen im nachfolgenden Dialog InfoCube bearbeiten sind aufgrund der Auswahl des Ist-Daten InfoCube als Vorlage für den neuen Realtime-fähigen InfoCube bereits gepflegt. Es bedarf an dieser Stelle somit nur noch dem Prüfen, Sichern und Aktivieren des InfoCube (siehe Abb. 4.27 Realtime-fähigen InfoCube anlegen II, Schritte 1 bis 3). Betätigen Sie anschließend die Schaltfläche Zurück (Schritt 4).

310

Unternehmensplanung

4.4.1.2

Anlegen des MultiProvider

Abb. 4.28 MultiProvider anlegen I

Klicken Sie mit der rechten Maustaste auf Ihre InfoArea UO_IA_## (siehe Abb. 4.28 MultiProvider anlegen I, Schritt 1) und wählen im Kontextmenü diesmal den Eintrag MultiProvider anlegen (Schritt 2). Unter Multiprov. geben Sie den Namen UO_ICM_## an (Schritt 3) und vergeben die Beschreibung ProduktUmsatz Soll-Ist Planung Fallstudie BW ## (Schritt 4). In diesem Fall bleibt das Feld Vorlage leer, so dass Sie Ihre Eingaben durch einen Klick auf die Schaltfläche Anlegen bestätigen (Schritt 5).

Fallstudie B: BI-Integrierte Planung

311

Abb. 4.29 MultiProvider anlegen II

Im sich öffnenden Dialog MultiProvider: Beteiligte InfoProvider setzen Sie in der geöffneten Registerkarte InfoCubes in der Spalte Beteiligt jeweils einen Haken vor Ihre InfoCubes UO_ICI_## und UO_ICP_## (siehe Abb. 4.29 MultiProvider anlegen II, Schritt 1). Fahren Sie durch einen Klick auf die Schaltfläche Weiter fort (Schritt 2).

312

Unternehmensplanung

Abb. 4.30 MultiProvider bearbeiten I

Im nächsten Dialog MultiProvider bearbeiten öffnen Sie zunächst die Baumstruktur von einem der beiden beteiligten InfoProvider (siehe Abb. 4.30 MultiProvider bearbeiten I, Schritt 1). Öffnen Sie darin weiterhin den Ordner Dimensionen und ziehen die enthaltene Dimension Produkt per Drag & Drop hinüber in die Dimensionen des MultiProvider (Schritt 2). Nehmen Sie die Information „Dimensionen wurden umbenannt (aufsteigende Namen)“ zur Kenntnis und klicken Sie auf Weiter. Verfahren Sie mit der Dimension Buchungskreis gleichermaßen (Schritt 3).

Fallstudie B: BI-Integrierte Planung

313

Abb. 4.31 MultiProvider bearbeiten II

Um die einzelnen Zeitmerkmale in den MultiProvider zu übertragen, müssen Sie die InfoObjekte einzeln herüberziehen. Öffnen Sie dazu die Dimension Zeit und ziehen die beiden darin enthaltenen InfoObjekte ebenfalls per Drag & Drop direkt in die Dimension Zeit des MultiProvider (siehe Abb. 4.31 MultiProvider bearbeiten II, Schritte 1 und 2). Als letztes übertragen Sie die Kennzahl Umsatz vom beteiligten InfoProvider in den MultiProvider (Schritt 3), dabei wird die Dimension Einheit des MultiProvider automatisch mit dem Merkmal 0CURRENCY gefüllt. Löschen Sie die nicht verwendete Dimension 1, indem Sie mit rechts darauf klicken und anschließend den Menüeintrag Löschen wählen (Schritte 4 und 5). Klicken Sie als nächstes auf die Schaltfläche Merkmale identifizieren (Schritt 6).

314

Unternehmensplanung

Abb. 4.32 MultiProvider - Merkmale identifizieren

Um die Zuordnung aller InfoObjekte zwischen dem MultiProvider und den InfoProvidern (hier: InfoCubes) durchzuführen, klicken Sie im Dialog auf die Schaltfläche Alle (siehe Abb. 4.32 MultiProvider - Merkmale identifizieren, Schritt 1). Sie erhalten die Information „Es wurde ein Vorschlag für ALLE InfoObjects erstellt“, die Sie über Weiter schließen (Schritt 2). Über die Navigationsschaltflächen Nächstes Objekt bzw. Voriges Objekt können Sie alle InfoObjekte vom Typ Merkmal identifizieren (Schritt 3). Sind alle Markierungen ordnungsgemäß gesetzt, verlassen Sie den Dialog über einen Klick auf Weiter (Schritt 4).

Fallstudie B: BI-Integrierte Planung

315

Abb. 4.33 MultiProvider - Kennzahlen selektieren

Zur Auswahl der beteiligten Kennzahlen betätigen Sie die Schaltfläche Kennzahlen selektieren (siehe Abb. 4.33 MultiProvider - Kennzahlen selektieren, Schritt 1) und setzen auch hier die Markierungen für die Kennzahlen der jeweiligen InfoProvider (Schritt 2). Alternativ können Sie auch erneut die Schaltfläche Alle betätigen (gestrichelte Markierung). Da die Kennzahl Umsatz das einzige InfoObjekt vom Typ Kennzahl ist, ist ein navigieren zwischen den InfoObjekten an dieser Stelle nicht möglich. Bestätigen Sie Ihre Auswahl ebenfalls mit Weiter (Schritt 3) und schließen Sie den Vorgang durch Prüfen, Sichern und Aktivieren des MultiProvider ab (Schritte 4 bis 6). Nach erfolgreicher Aktivierung betätigen Sie die Schaltfläche Zurück (Schritt 7).

316

Unternehmensplanung

Abb. 4.34 Dokumentation zum MultiProvider erstellen

Zum Abschluss der Datenmodellierung soll zu dem soeben erstellten MultiProvider nun noch ein Dokument hinterlegt werden, das die Eigenschaften des MultiProviders textuell beschreibt. Navigieren Sie dazu in die Sicht Dokumente (siehe Abb. 4.34 Dokumentation zum MultiProvider erstellen, Schritt 1) und wählen dort zunächst den Objekttyp MPRO (Schritt 2) sowie den Objektnamen UO_ICM_## (Schritt 3). Anschließend klicken Sie auf die Schaltfläche Anlegen… (Schritt 4), um im sich öffnenden Dialog unter Name UO_ICM_##_Doc und die Beschreibung Dokumentation UO_ICM_## einzutragen (Schritt 5). Danach betätigen Sie die Schaltfläche Editor starten (Schritt 6). Über den Texteditor können Sie nun eine kurze Dokumentation verfassen und diese im Anschluss über die Menüleiste des Editors über Datei  Speichern sichern (Schritt 7). Schließen Sie den Texteditor (Schritt 8). Zurück im Pflegebildschirm Data Warehouse Workbench: Dokumente sehen Sie, dass die Dokumentation in die Tabelle aufgenommen wurde. Kehren Sie zurück in die Sicht Modellierung, klicken dort mit der linken Maustaste auf den soeben dokumentieren MultiProvider UO_ICM_## und betätigen die Taste F1 auf Ihrer Tastatur. Melden Sie sich mit Ihrem Benutzernamen und Passwort innerhalb des sich öffnenden Webbrowsers an und Sie erhalten einen Einblick in die Metadaten des MultiProvider. In den Abschnitten Dokumentation und Weitere Dokumente finden Sie nun die zuvor angelegte Dokumentation. Schließen Sie den Webbrowser.

Fallstudie B: BI-Integrierte Planung

4.4.1.3

317

Zusammenfassung

Im ersten Teil der zweiten Fallstudie haben Sie auf der Vorlage des in der ersten Fallstudie modellierten Standard-InfoCube UO_ICI_## Produkt-Umsatz Ist Fallstudie BW ## zunächst den Realtime-fähigen InfoCube UO_ICP_## ProduktUmsatz Planung Fallstudie BW ## angelegt, welcher der Speicherung der im weiteren Verlauf der Fallstudie anfallenden Plandaten dient. Im nächsten Schritt haben Sie diese beiden InfoCubes über einen MultiProvider miteinander verbunden und deren gemeinsamen Merkmale und Kennzahlen identifiziert bzw. selektiert. Außerdem haben Sie zum Abschluss des Modellierungsabschnitts erfahren, wie InfoProvider mit einer Dokumentation versehen werden, um den späteren Anwender über die Hilfefunktion mit Metadaten zu versorgen.

4.4.2 Teil II - Planungsmodellierung Nachdem die notwendigen Objekte im Zuge der Datenmodellierung im System hinterlegt wurden, kann nun mit der Modellierung der planungsspezifischen Objekte für das Szenario begonnen werden. Die BI-integrierte Planung gibt dem Benutzer zwei Werkzeuge zur Modellierung an die Hand. Für einen einfachen Einstieg in die Planungsmodellierung stellt das System den Planning Wizard zur Verfügung, der den Benutzer Schritt für Schritt durch die einzelnen Stufen des Planungsprozesses führt. Als zentrales Modellierungswerkzeug im Rahmen der BI-integrierten Planung gilt jedoch der Planning Modeler, über den sämtliche Metadaten zu einem Planungsszenario modelliert, administriert und getestet und somit sehr komplexe Planungsfunktionen generiert werden können. Im Rahmen dieser Fallstudie sind zwei Planungsfunktionen zu erstellen, die am Ende dieses Abschnitts zu einer Planungssequenz zusammengeführt werden. Damit zunächst ein einfacher Einstieg in die Planungsmodellierung gegeben ist, wird die erste Planungsfunktion mit Hilfe des Planning Wizard umgesetzt. Bei der Planungsfunktion handelt es sich um eine Löschfunktion, die auf dem zuvor erstellten Realtime-fähigen InfoCube basiert und alle darin enthaltenen Daten zur Initialisierung einer neuen Planungsrunde löscht. Ausgehend von diesem InfoProvider wird über den Planning Wizard eine einfache Aggregationsebene definiert, die wiederum alle Merkmale und Kennzahlen enthält, die von der Löschfunktion verändert werden dürfen. In den weiteren Schritten des Planning Wizard werden außerdem noch ein Filter angelegt und die Charakteristika der Löschfunktion definiert. Bei der zweiten Planungsfunktion handelt es sich um eine Kopierfunktion, die mit Hilfe des Planning Modeler erstellt wird und auf dem MultiProvider basiert, der die beiden InfoCubes für Ist- und Plandaten verbindet. Die Ist-Daten sollen dabei als Grundlage für eine Planungsrunde in den Plan-InfoCube kopiert werden. Neben der Definition einer komplexen Aggregationsebene, die alle InfoObjekte enthält, die durch die Kopierfunktion verändert werden dürfen, bedarf es erneut

318

Unternehmensplanung

der Definition eines Filters. Im letzten Schritt werden die genaue Kopiervorschrift sowie weitere Eigenschaften der Planungsfunktion spezifiziert. Um die beiden angelegten Planungsfunktionen zu testen, wird mittels des Planning Modeler abschließend eine Planungssequenz definiert, die zuerst die Löschund dann die Kopierfunktion ausführt, ohne dass eine Interaktion des Benutzers notwendig ist. 4.4.2.1

Anlegen der Löschfunktion im Planning Wizard

Verlassen Sie die DWB und begeben Sie sich zurück zum Startbildschirm des SAP Easy Access.

Abb. 4.35 SAP Easy Access - Business Planning and Simulation

Im SAP Menü öffnen Sie den Unterpunkt Business Planning and Simulation und klicken doppelt auf den Eintrag BI Integrierte Planung (siehe Abb. 4.35 SAP Easy Access - Business Planning and Simulation, Schritt 1). Alternativ erreichen Sie die Anwendung auch über die Eingabe des Transaktionscodes RSPLAN im obigen Befehlsfeld (gestrichelte Markierung).

Fallstudie B: BI-Integrierte Planung

319

Abb. 4.36 Planning Wizard starten

Zum Erstellen der Planungsfunktion zum Löschen der Plandaten soll der Planning Wizard verwendet werden. Klicken Sie dazu auf die Schaltfläche Wizard starten (siehe Abb. 4.36 Planning Wizard starten, Markierung). Der Webbrowser wird gestartet.

320

Unternehmensplanung

Abb. 4.37 Planning Wizard: InfoProvider auswählen

Der Planning Wizard führt Sie schrittweise durch den Planungsprozess. Ihre aktuelle Position können Sie über die Navigationshilfe einsehen (siehe Abb. 4.37 Planning Wizard: InfoProvider auswählen, Schritt 1). Im ersten Schritt InfoProvider müssen Sie einen InfoProvider auswählen, auf dem die nachfolgende Aggregationsebene angelegt werden soll. Schränken Sie die Suche über alle im System vorhandenen InfoProvider durch den Suchstring UO* ein (Schritt 2) und klicken Sie anschließend auf Start (Schritt 3), um sich nur die InfoProvider anzeigen zu lassen, die sich in Ihrer InfoArea befinden. Selektieren Sie den InfoCube Produkt-Umsatz Planung Fallstudie BW ## aus der Liste, indem Sie auf das voranstehende Selektionsfeld klicken (Schritt 4). Schreiten Sie über einen Klick auf Weiter zum nächsten Schritt in der Navigation (Schritt 5).

Fallstudie B: BI-Integrierte Planung

321

Abb. 4.38 Planning Wizard: Aggregationsebene anlegen

Im zweiten Schritt Aggregationsebene betätigen Sie die Schaltfläche Anlegen (siehe Abb. 4.38 Planning Wizard: Aggregationsebene anlegen, Schritt 1), um eine neue Aggregationsebene anzulegen. Vergeben Sie für die Aggregationsebene den technischen Namen UO_AEL_## (Schritt 2) und die Beschreibung AE zum Löschen der Plandaten Fallstudie BW ## (Schritt 3) und klicken auf Übernehmen (Schritt 4). Im sich öffnenden Tray zum Ändern der Aggregationsebene betätigen Sie zur automatischen Selektion aller InfoObjekte die Schaltfläche Alle auswählen (Schritt 5). Nun sind alle InfoObjekte in der Aggregationsebene enthalten. Um den Vorgang abzuschließen, klicken Sie nacheinander auf die Schaltflächen Prüfen, Sichern und Aktivieren (Schritt 6). Sie werden über Meldungstexte unterhalb der Navigation über die Ergebnisse von Prüfung, Aktivierung und Sicherung informiert. Begeben Sie sich über Weiter zum dritten Schritt (Schritt 7).

322

Unternehmensplanung

Abb. 4.39 Planning Wizard: Filter anlegen

Zum Anlegen eines Filters für die Löschfunktion klicken Sie im Schritt Filter auf die Schaltfläche Anlegen (siehe Abb. 4.39 Planning Wizard: Filter anlegen, Schritt 1). Der neue Filter erhält den technischen Namen UO_FL_## (Schritt 2) und die Beschreibung Filter zum Löschen der Plandaten Fallstudie BW ## (Schritt 3). Nach einem Klick auf Übernehmen (Schritt 4) betätigen Sie die Schaltflächen Prüfen und Sichern ohne weitere Einstellungen vorzunehmen (Schritt 5). Klicken Sie erneut auf Weiter, um zum vorletzen Schritt innerhalb des Planning Wizard zu gelangen (Schritt 6).

Fallstudie B: BI-Integrierte Planung

323

Abb. 4.40 Planning Wizard: Planungsfunktion anlegen

Im vorletzten Schritt Planungsfunktion legen Sie nun die eigentlichen Eigenschaften zur Planungsfunktion fest. Klicken Sie auf Anlegen (siehe Abb. 4.40 Planning Wizard: Planungsfunktion anlegen, Schritt 1), selektieren aus dem DropdownMenü Typ den Eintrag Löschen (Schritt 2) und vergeben den technischen Namen UO_PFL_## (Schritt 3) sowie die dazugehörige Beschreibung PF zum Löschen der Plandaten Fallstudie BW ## (Schritt 4). Bestätigen Sie Ihre Eingaben durch einen Klick auf Übernehmen (Schritt 5). Im sich öffnenden Tray zum Ändern der Planungsfunktion bedarf es nun noch der Auswahl der zu löschenden Kennzahlen. Setzen Sie dazu einen Haken in das Ankreuzfeld vor der Option Alle Kennzahlen auswählen (Schritt 6), Prüfen und Sichern (Schritt 7) die Planungsfunktion und begeben Sie sich über Weiter zum letzten Schritt (Schritt 8).

324

Unternehmensplanung

Abb. 4.41 Planning Wizard: Planungsfunktion testen

Im Testrahmen, dem fünften und letzten Schritt des Planning Wizard, haben Sie die Möglichkeit, Ihre angelegte Planungsfunktion zu testen. Klicken Sie dazu auf das Selektionsfeld der gewünschten Planungsfunktion (siehe Abb. 4.41 Planning Wizard: Planungsfunktion testen, Schritt 1) und starten Sie den Test über die Schaltfläche Ausführen (Schritt 2). Sofern Sie die Erstellung der Planungsfunktion ordnungsgemäß durchgeführt haben, erscheinen die Statusmeldungen „Planungsfunktion UO_PFL_## wurde fehlerfrei ausgeführt“ und „0 Sätze gelesen 0 Sätze erzeugt 0 Sätze geändert 0 Sätze gelöscht“ (Schritt 3). Schließen Sie den Webbrowser. Sie haben Ihre erste Planungsfunktion erfolgreich erstellt.

Fallstudie B: BI-Integrierte Planung

4.4.2.2

325

Anlegen der Kopierfunktion im Planning Modeler

Abb. 4.42 Planning Modeler starten

Der Planungsprozess soll nun dahingehend unterstützt werden, dass die Ist-Daten aus dem Standard-InfoCube Produkt-Umsatz Ist Fallstudie BW ## als Grundlage für eine Planungsrunde in den Realtime-fähigen InfoCube Produkt-Umsatz Planung Fallstudie BW ## kopiert werden können. Die dazu notwendige Planungsfunktion Kopieren soll dabei entgegen der vorherigen Löschfunktion mit dem Planning Modeler erstellt werden. Klicken Sie dazu auf die Schaltfläche Modeler starten (siehe Abb. 4.42 Planning Modeler starten, Markierung).

326

Unternehmensplanung

Abb. 4.43 Planning Modeler: InfoProvider auswählen

Im Planning Modeler erfolgt die Navigation über Registerkarten, die zwar ähnliche Bezeichnungen wie der Navigationsblock im Planning Wizard besitzen, jedoch einen Zugriff auf umfangreichere Funktionen bieten (siehe Abb. 4.43 Planning Modeler: InfoProvider auswählen, gestrichelte Markierung). In der ersten Registerkarte InfoProvider geben Sie den Suchstring UO* in das Suchfeld ein (Schritt 1) und beginnen Ihre Suche erneut über die Schaltfläche Start (Schritt 2). Da die Daten aus dem Ist-Daten InfoCube im Plandaten InfoCube abgelegt werden sollen, muss die Kopierfunktion auf einer Aggregationsebene aufgebaut werden, die sich auf dem MultiProvider Produkt-Umsatz Soll-Ist Planung Fallstudie BW ## befindet. Selektieren Sie diesen MultiProvider (Schritt 3) und fahren durch einen Klick auf die Registerkarte Aggregationsebenen fort (Schritt 4).

Fallstudie B: BI-Integrierte Planung

327

Abb. 4.44 Planning Modeler: Aggregationsebene anlegen

Legen Sie über die Schaltfläche Anlegen eine neue Aggregationsebene an (siehe Abb. 4.44 Planning Modeler: Aggregationsebene anlegen, Schritt 1). Geben Sie dieser den technischen Namen UO_AEK_## (Schritt 2) und die Beschreibung AE zum Kopieren der Ist-Daten zu Plandaten Fallstudie BW ## (Schritt 3), bevor Sie die Schaltfläche Übernehmen betätigen (Schritt 4).

328

Unternehmensplanung

Abb. 4.45 Planning Modeler: Einstellungen ändern

Im Tray Ändern Aggregationsebene klicken Sie zunächst auf Einstellungen (siehe Abb. 4.45 Planning Modeler: Einstellungen ändern, Schritt 1). Ändern Sie in der Registerkarte Darstellung (Schritt 2) die Anzahl der angezeigten Zeilen auf 9 (Schritt 3) und bestätigen Ihre Eingabe mit OK (Schritt 4).

Fallstudie B: BI-Integrierte Planung

329

Abb. 4.46 Planning Modeler: Aggregationsebene ändern

Selektieren Sie die InfoObjekte Kalenderjahr/Monat, Buchungskreis ##, Umsatz ## und Währungsschlüssel, indem Sie jeweils einen Haken vor das entsprechende InfoObjekt in die Spalte Verwendet setzen (siehe Abb. 4.46 Planning Modeler: Aggregationsebene ändern, Schritt 1). Die Selektion des InfoObjekts InfoProvider ist bereits fest vom System vorgegeben. Abschließend Prüfen, Sichern und Aktivieren Sie die neue Aggregationsebene (Schritt 2) und begeben sich in die dritte Registerkarte Filter (Schritt 3).

330

Unternehmensplanung

Abb. 4.47 Planning Modeler: Filter anlegen

Im Bereich Filter klicken Sie auf Anlegen (siehe Abb. 4.47 Planning Modeler: Filter anlegen, Schritt 1), vergeben den technischen Namen UO_FK_## (Schritt 2) und die Beschreibung Filter zum Kopieren der Ist-Daten zu Plandaten Fallstudie BW ## (Schritt 3). Klicken Sie weiterhin auf die Schaltfläche Übernehmen (Schritt 4).

Fallstudie B: BI-Integrierte Planung

331

Abb. 4.48 Planning Modeler: Filter ändern

Im unteren Tray Ändern Filter betätigen Sie die Schaltfläche Alle hinzufügen (siehe Abb. 4.48 Planning Modeler: Filter ändern, Schritt 1), um zunächst alle in der Aggregationsebene enthaltenen Merkmale zum Filter hinzuzufügen. Das System teilt Ihnen mit, dass für jedes Merkmal Werte in den Merkmalseinschränkungen ausgewählt werden müssen, oder diese einer Markierung als Änderbar bei Ausführung bedürfen. Klicken Sie dazu auf das jeweilige Symbol zur Wertehilfe (Schritt 2). Für das Merkmal Buchungskreis selektieren Sie in der Eingabehilfe des Merkmals – einzeln oder unter Zuhilfenahme der SHIFT-Taste – die Werte Berlin, Oldenburg, Stuttgart und Hamburg (Schritt 3) und fügen diese über die Schaltfläche Hinzufügen (Schritt 4) aus der Werteliste in die ausgewählten Selektionen. Beenden Sie die Eingabehilfe über OK (Schritt 5).

332

Unternehmensplanung

Abb. 4.49 Planning Modeler: Filter sichern

Schränken Sie die weiteren drei Merkmale analog zum obigen Verfahren und inhaltlich gemäß der Tabelle 4.8 ein (siehe Abb. 4.49 Planning Modeler: Filter sichern). Sobald Sie alle Merkmalseinschränkungen vorgenommen haben, Prüfen und Sichern (Schritt 1) Sie den neuen Filter und begeben sich anschließend in die vorletzte Registerkarte Planungsfunktionen (Schritt 2). Tabelle 4.8 Filter anlegen - Merkmalseinschränkungen Merkmalsbeschreibung

Merkmalseinschränkungen (Text)

Buchungskreis

Berlin; Oldenburg; Stuttgart; Hamburg

KalJahr/Monat

Januar 2008 - Dezember 2008 (Wertebereich)

InfoProvider

Produkt-Umsatz Ist Fallstudie BW ##; Produkt-Umsatz Planung Fallstudie BW ##

Währung

Euro

Fallstudie B: BI-Integrierte Planung

333

Abb. 4.50 Planning Modeler: Planungsfunktion anlegen I

In der Registerkarte Planungsfunktionen wird nun die Kopierfunktion angelegt. Klicken Sie auf Anlegen (siehe Abb. 4.50 Planning Modeler: Planungsfunktion anlegen I, Schritt 1) und wählen im sich öffnenden Dialog den Typ Kopieren aus (Schritt 2). Nennen Sie die Planungsfunktion UO_PFK_## (Schritt 3) und beschreiben sie mit PF zum Kopieren der Ist-Daten zu Plandaten Fallstudie BW ## (Schritt 4). Klicken Sie auf Übernehmen (Schritt 5).

334

Unternehmensplanung

Abb. 4.51 Planning Modeler: Planungsfunktion anlegen II

Im Tray Ändern Planungsfunktion zur Merkmalsverwendung vergeben Sie jeweils einen Haken in der Spalte wird verändert für das Zeitmerkmal Kalenderjahr/Monat sowie für das Merkmal InfoProvider (siehe Abb. 4.51 Planning Modeler: Planungsfunktion anlegen II, Schritt 1). Wechseln Sie als nächstes Zu den Parametern (Schritt 2).

Fallstudie B: BI-Integrierte Planung

335

Abb. 4.52 Planning Modeler: Planungsfunktion anlegen III

Setzen Sie hier einen Haken in das Ankreuzfeld der Option Alle Kennzahlen auswählen (siehe Abb. 4.52 Planning Modeler: Planungsfunktion anlegen III, Schritt 1). Um nun den genauen Kopiervorgang zu spezifizieren, klicken Sie zuerst auf die Schaltfläche Zeile anlegen (Schritt 2) und danach auf die erscheinende Schaltfläche Von Ändern (Schritt 3). Nun bestimmen Sie zunächst die Von-Werte des Kopiervorgangs. Wählen Sie die Merkmalseinschränkungen März 2008 für das Merkmal Kalenderjahr/Monat sowie Produkt-Umsatz Ist Fallstudie BW ## als InfoProvider über die Wertehilfe, wie Sie es bereits aus dem Schritt zum Anlegen des Filters kennen (Schritt 4). Bestätigen Sie Ihre Auswahl mit OK (Schritt 5). Die Daten des Kalenderjahr/Monats März 2008 aus dem InfoProvider Produkt-Umsatz Ist Fallstudie BW ## sind nun gemäß der Anforderung als VonWerte für den Kopiervorgang festgelegt.

336

Unternehmensplanung

Abb. 4.53 Planning Modeler: Planungsfunktion anlegen IV

Zur Festlegung der Nach-Werte des Kopiervorgangs klicken Sie auf Nach Ändern (siehe Abb. 4.53 Planning Modeler: Planungsfunktion anlegen IV, Schritt 1). Hier sollen die Merkmale Kalenderjahr/Monat auf den Wertebereich von 07.2008 - 12.2008, also den Zeitraum Juli bis Dezember 2008 und die InfoProvider auf Produkt-Umsatz Planung Fallstudie BW ## einschränkt werden (Schritt 2). Klicken Sie auf OK (Schritt 3). Die Ist-Umsätze des Monats März 2008 werden nun als Plan-Umsätze auf die Monate Juli bis Dezember 2008 kopiert. Prüfen und Sichern Sie die Planungsfunktion (Schritt 4), bevor Sie zur letzten Registerkarte Planungssequenzen schreiten (Schritt 5).

Fallstudie B: BI-Integrierte Planung

337

Abb. 4.54 Planning Modeler: Planungssequenz anlegen I

Legen Sie über Anlegen eine neue Planungssequenz an (siehe Abb. 4.54 Planning Modeler: Planungssequenz anlegen I, Schritt 1). Nennen Sie die Planungssequenz UO_PS_## (Schritt 2) und beschreiben diese mit Löschen und Kopieren der Plandaten Fallstudie BW ## (Schritt 3). Bestätigen Sie Ihre Eingaben über Übernehmen (Schritt 4).

338

Unternehmensplanung

Abb. 4.55 Planning Modeler: Planungssequenz anlegen II

Im Tray Ändern Planungssequenz klicken Sie nun auf die Schaltfläche Schritt für Planungsfunktion hinzufügen (siehe Abb. 4.55 Planning Modeler: Planungssequenz anlegen II, Schritt 1) und anschließend auf das Symbol zur Auswahl der Aggregationsebene (Schritt 2). Da im ersten Schritt der Planungssequenz die Daten des Realtime-fähigen InfoCube über die Löschfunktion gelöscht werden sollen, selektieren Sie nach Eingabe des Suchstring UO* (Schritt 3) und einem anschließenden Klick auf Start (Schritt 4) die AE zum Löschen der Plandaten Fallstudie BW ## aus der Ergebnisliste (Schritt 5). Bestätigen Sie Ihre Auswahl mit Übernehmen (Schritt 6).

Fallstudie B: BI-Integrierte Planung

339

Abb. 4.56 Planning Modeler: Planungssequenz anlegen III

Danach wählen Sie den dazugehörigen Filter UO_FL_## (siehe Abb. 4.56 Planning Modeler: Planungssequenz anlegen III, Schritt 1) und die Planungsfunktion UO_PFL_## (Schritt 2) aus den jeweiligen Selektionsmenüs. Das erste Element der Planungssequenz ist nun definiert.

340

Unternehmensplanung

Abb. 4.57 Planning Modeler: Planungssequenz anlegen IV

Fügen Sie nach dem nun bekannten Verfahren einen weiteren Schritt in die Planungssequenz ein (siehe Abb. 4.57 Planning Modeler: Planungssequenz anlegen IV, Schritt 1), der auf Basis der AE zum Kopieren der Ist-Daten zu Plandaten Fallstudie BW ## (Schritt 2) und dem Filter zum Kopieren der Ist-Daten zu Plandaten Fallstudie BW ## (Schritt 3) die PF zum Kopieren der Ist-Daten zu Plandaten Fallstudie BW ## (Schritt 4) in die Planungssequenz aufnimmt. Durch die nun fertiggestellte Planungssequenz werden im ersten Schritt alle Plandaten aus dem Realtime-fähigen InfoCube gelöscht und danach im zweiten Schritt mit den Ist-Daten des Monats März 2008 initialisiert. Sichern Sie die Planungssequenz (Schritt 5) und führen Sie sie über die Schaltfläche Ausführen aus (Schritt 6). Sie erhalten die Information „Sequenz UO_PS_## wurde ohne Fehler ausgeführt“ und einige weitere Details zu den gelesenen, erzeugten, geänderten bzw. gelöschten Datensätzen (Schritt 7). Sie haben den Teil der Planungsmodellierung erfolgreich abgeschlossen. Schließen Sie den Webbrowser. 4.4.2.3

Zusammenfassung

Mit Hilfe des Planning Wizard haben Sie im zweiten Teil der zweiten Fallstudie auf Basis des Realtime-fähigen InfoCube Produkt-Umsatz Planung Fallstudie BW ## und einer eigens dazu angelegten Aggregationsebene sowie einem Filter zu-

Fallstudie B: BI-Integrierte Planung

341

nächst eine Löschfunktion erstellt, die alle im Planungs-InfoCube enthaltenen Daten zur Initialisierung einer neuen Planungsrunde löscht. Im Planning Modeler haben Sie weiterhin eine komplexere Planungsfunktion vom Typ Kopieren entwickelt, die entgegen der Löschfunktion auf dem MultiProvider Produkt-Umsatz Soll-Ist Planung Fallstudie BW ## basiert, da sie die Ist-Daten des StandardInfoCube Produkt-Umsatz Ist Fallstudie BW ## als initiale Planwerte in den Realtime-fähigen InfoCube Produkt-Umsatz Planung Fallstudie BW ## kopiert. Dabei haben Sie den Umsatz aus dem Monat März 2008 als Planwert für die einzelnen Monate im zweiten Quartal des Jahres 2008 verwendet. In einem weiteren Schritt haben Sie kennengelernt, wie die erstellten Planungsfunktionen zu einer Planungssequenz zusammengeschlossen werden und so zur Initialisierung einer neuen Planungsrunde direkt hintereinander ausgeführt werden können.

4.4.3 Teil III - Erstellen von Planungsanwendungen Basierend auf der zur Kopierfunktion erstellten Aggregationsebene, wird im dritten und letzten Teil dieser Fallstudie eine eingabebereite Plan-Query erstellt, die die Ist- und Plandaten gegenüberstellt. Das Besondere an dieser Plan-Query im Gegensatz zu einer einfachen Query – wie sie beispielsweise in der ersten Fallstudie erstellt wurde – ist, dass der Benutzer während der Ausführung der Plan-Query die Planwerte manuell editieren kann. Eine manuelle Planung reicht hierbei von einer einfachen Datenerfassung per Hand bis hin zur Ausführung komplexer Planungsanwendungen zur Laufzeit. Bei der Erstellung der eingabebereiten Plan-Query werden analog zu den aus der ersten Fallstudie bekannten Arbeitsschritten im BEx Query Designer, zunächst die Merkmale und Kennzahlen in Zeilen und Spalten angeordnet. Neu in dieser zweiten Fallstudie ist die Definition zweier eingeschränkter Kennzahlen, die durch die Selektion der Kennzahl Umsatz und anhand des technischen Merkmals InfoProvider aus dem MultiProvider ausgelesen werden können. Da die hier verwendete Aggregationsebene auf dem MultiProvider aufbaut, der die Daten aus dem Standard- und Realtime-fähigen InfoCube verbindet, ist dies problemlos möglich. Weiterhin wird die eingeschränkte Kennzahl für den Planumsatz über den BEx Query Designer als eingabebereit deklariert, damit die Werte der Kennzahl in der späteren Ausführung der Query veränderbar sind. Desweiteren wird eine Formel in der Struktur der Kennzahlen spezifiziert, die zwischen den beiden verwendeten, eingeschränkten Kennzahlen – also den Ist- und Planwerten – die prozentuale Abweichung berechnet. Während der Durchführung einer Überprüfung im Webbrowser soll zum Abschluss der Erstellung der Plan-Query noch eine spezielle Sicht auf den Datenbestand generiert und gesichert werden, die die prozentuale Abweichung aus der Ergebnistabelle ausblendet. Dieser Schritt liegt darin begründet, dass die im Fortlauf dieses Abschnitts zu entwickelnde Planungsumgebung

342

Unternehmensplanung

ein Diagramm enthalten soll, das die prozentuale Abweichung ausblendet und somit ausschließlich die Ist- und Planumsätze visualisiert. Die Erstellung der Planungsanwendung bildet den Abschluss dieser zweiten Fallstudie. Mit Hilfe des BEx Web Application Designers werden aufbauend auf der ersten Fallstudie weitere Web Items in das Web Template eingefügt. So werden Registerkarten in das Web Template aufgenommen, wodurch die Inhalte der Planungsanwendung strukturiert abgelegt werden können. Desweiteren werden tiefergehende Einstellungen zur besseren Visualisierung der Daten am Diagramm vorgenommen. Im Vordergrund steht jedoch die Integration weiterer Schaltflächen, die es dem Anwender erlauben, die in den vorherigen Schritten angelegten Planungsfunktionen zum Löschen und Kopieren über das Web Template auszuführen. Da die Planungsanwendung ihre Daten über die Plan-Query bezieht, ist außerdem die manuelle Eingabe von Planwerten erlaubt. So kann zur Initialisierung einer Planungsrunde zunächst der Inhalt des Plan-InfoCube gelöscht werden, wonach die Übernahme der Ist-Daten als angestrebte Planwerte erfolgt, die weiterhin manuell überarbeitet und letztlich im Plan-InfoCube gesichert werden können.

Fallstudie B: BI-Integrierte Planung

4.4.3.1

343

Erstellen der eingabebereiten Plan-Query

Zum Erstellen einer eingabebereiten Plan-Query starten Sie den aus der ersten Fallstudie bekannten Query Designer über das MS Windows Startmenü. Unter Programme  Business Explorer finden Sie die Anwendung, an der Sie sich wie gewohnt mit Benutzername und Passwort anmelden.

Abb. 4.58 Auswahl des InfoProvider

Klicken Sie auf die Schaltfläche Neue Query… (siehe Abb. 4.58 Auswahl des InfoProvider, Schritt 1), um zunächst einen InfoProvider auszuwählen. Sie gelangen über InfoAreas (Schritt 2)  Name Ihrer InfoArea (hier: Uni Oldenburg)  Fallstudie BW ## auf die Aggregationsebene AE zum Kopieren der Ist-Daten zu Plandaten Fallstudie BW ## (Schritt 3), die Sie auswählen und Öffnen (Schritt 4).

344

Unternehmensplanung

Abb. 4.59 Query anlegen I

Da der zugrundeliegende InfoProvider in diesem Fall die Aggregationsebene der Kopierfunktion ist, kann der darin enthaltene Filter auch für die anzulegende, eingabebereite Query verwendet werden. Öffnen Sie dazu die Baumstruktur des Ordners Filter (siehe Abb. 4.59 Query anlegen I, Schritt 1) und ziehen Sie den darin enthaltenen Filter zum Kopieren der Ist-Daten zu Plandaten Fallstudie BW ## per Drag & Drop aus dem Feld InfoProvider in den Bereich Filter (Schritt 2).

Fallstudie B: BI-Integrierte Planung

345

Abb. 4.60 Eingeschränkte Kennzahl Umsatz Ist anlegen

Für den Ist- und Planumsatz sollen nun zwei eingeschränkte Kennzahlen erstellt werden. Klicken Sie im Feld InfoProvider mit einem Rechtsklick auf Kennzahlen (siehe Abb. 4.60 Eingeschränkte Kennzahl Umsatz Ist anlegen, Schritt 1) und im sich öffnenden kontextsensitiven Menü weiterhin auf den Eintrag Neue eingeschränkte Kennzahl (Schritt 2). Die neue eingeschränkte Kennzahl erhält vom System zunächst den Namen Neue eingeschränkte Kennzahl. Durch einen Doppelklick auf diesen Namen haben Sie die Möglichkeit, die Kennzahl genauer zu spezifizieren. Im Dialog Eingeschränkte Kennzahl ändern vergeben Sie in der geöffneten Registerkarte Allgemein zunächst die Beschreibung Umsatz Ist (Schritt 3) und den technischen Namen UO_EKUI_## (Schritt 4). Im Gruppierungsfeld Detailansicht ziehen Sie außerdem die Kennzahl Umsatz (Schritt 5) sowie den in der Dimension Datenpaket  InfoProvider enthaltenen Merkmalswert Produkt-Umsatz Ist Fallstudie BW ## hinüber in die Details der Selektion (Schritt 6). Wechseln Sie in die Registerkarte Planung (Schritt 7) und stellen Sie sicher, dass die Markierung im Gruppierungsfeld Daten ändern vor Daten können nicht geändert werden gesetzt ist. Beenden Sie die Änderungen an der eingeschränkten Kennzahl über einen Klick auf OK (Schritt 8).

346

Unternehmensplanung

Abb. 4.61 Eingeschränkte Kennzahl Umsatz Plan anlegen

Wiederholen Sie die Schritte 1 bis 7 der vorherigen Anweisung zum Anlegen der zweiten eingeschränkten Kennzahl Umsatz Plan und verwenden dazu die in Tabelle 4.9 eingetragenen Werte bzw. Eigenschaften. Die Werte der bereits angelegten eingeschränkten Kennzahl Umsatz Ist sind zum Vergleich ebenfalls in der Tabelle hinterlegt. Tabelle 4.9 Eingeschränkte Kennzahlen Kennzahl

Umsatz Ist

Umsatz Plan

Beschreibung

Umsatz Ist

Umsatz Plan

Technischer Name

UO_EKUI_##

UO_EKUP_##

Details der Selektion

Kennzahlen  Umsatz

Kennzahlen  Umsatz

Dimensionen  InfoProvider  Merkmalswerte  ProduktUmsatz Ist Fallstudie BW ##

Dimensionen  InfoProvider  Merkmalswerte  ProduktUmsatz Planung Fallstudie BW ##

Daten können nicht geändert werden

Daten können durch Benutzereingaben oder Planungsfunktionen geändert werden

Registerkarte Allgemein

Registerkarte Planung Daten ändern

Fallstudie B: BI-Integrierte Planung

347

Bitte beachten Sie, dass für die eingeschränkte Kennzahl Umsatz Plan eine Änderung gemäß der Tabelle 4.9 in der Registerkarte Planung durchgeführt werden muss. Im Gruppierungsfeld Daten ändern muss die Markierung vor Daten können durch Benutzereingaben oder Planungsfunktionen geändert werden (siehe Abb. 4.61 Eingeschränkte Kennzahl Umsatz Plan anlegen, Markierung) gesetzt sein.

Abb. 4.62 Query anlegen II

Wechseln Sie in die Registerkarte Zeilen/Spalten (siehe Abb. 4.62 Query anlegen II, Schritt 1) und ziehen Sie die Merkmale Buchungskreis und KalJahr/Monat per Drag & Drop nacheinander in den Bereich der Zeilen (Schritte 2 und 3). Die neuen eingeschränkten Kennzahlen Umsatz Ist und Umsatz Plan verschieben Sie außerdem in den Bereich der Spalten (Schritte 4 und 5), wobei darauf zu achten ist, dass der Ist-Umsatz über dem Plan-Umsatz steht.

348

Unternehmensplanung

Abb. 4.63 Formel anlegen

Zusätzlich soll nun noch eine Formel anlegt werden, die die prozentuale Abweichung zwischen dem Ist- und dem Planumsatz darstellt. Zu diesem Zweck klicken Sie mit rechts auf die Struktur Kennzahlen (siehe Abb. 4.63 Formel anlegen, Schritt 1) und wählen im Kontextmenü den Eintrag Neue Formel (Schritt 2). Die neue Formel wird vom System in die Struktur aufgenommen und Sie erhalten im Meldungsfenster eine Meldung zu der aktuellen Query, dass die Formel genauer definiert werden muss. Dies erledigen Sie über einen Doppelklick auf die neue Formel, wonach sich der Dialog Formel ändern öffnet. Ändern Sie die Beschreibung in Proz. Abweichung (Schritt 3) und ziehen zuerst die Kennzahl Umsatz Ist aus den verfügbaren Operanden (Schritt 4), dann den Operator prozentuale Abweichung aus den Prozentfunktionen (Schritt 5) und abschließend die Kennzahl Umsatz Plan (Schritt 6) in das Gruppierungsfeld der Detailansicht. Optional können Sie in der Registerkarte Darstellung (Schritt 7) die Anzahl der Dezimalstellen auf den Wert 0.0 reduzieren. Ihre Formel ist nun definiert und Sie können den Dialog über OK (Schritt 8) schließen. Stellen Sie desweiteren sicher, dass die neue Formel in der Struktur Kennzahlen aus Gründen der besseren Übersicht an letzter Stelle steht.

Fallstudie B: BI-Integrierte Planung

349

Abb. 4.64 Query speichern

Nach einem Klick auf die Schaltfläche Query speichern (siehe Abb. 4.64 Query speichern, Schritt 1) wechseln Sie in den im Rahmen der ersten Fallstudie erstellten Ordner Fallstudie BW ##. Versehen Sie die Query mit der Beschreibung Produkt-Umsatz Plan ## sowie dem technischen Namen QUERY2_## (Schritt 2) und sichern Sie die Query über OK (Schritt 3).

350

Unternehmensplanung

Abb. 4.65 Query Eigenschaften

Stellen Sie vor dem Ausführen der Query noch einmal sicher, dass die eingeschränkte Kennzahl Umsatz Plan tatsächlich eingabebereit ist. Klicken Sie dazu direkt auf die Kennzahl Umsatz Plan in der Struktur der Kennzahlen (siehe Abb. 4.65 Query Eigenschaften, Schritt 1), wechseln unter Eigenschaften in den Reiter Planung (Schritt 2) und überprüfen, ob die Markierung bei Daten können durch Benutzereingaben oder Planungsfunktionen geändert werden gesetzt ist (Schritt 3).

Fallstudie B: BI-Integrierte Planung

351

Abb. 4.66 Query Ausführen

Weiterhin überprüfen Sie in den Eigenschaften der gesamten Query, ob diese beim Ausführen auch tatsächlich im Änderungsmodus gestartet wird, damit die Eingabebereitschaft gewährleistet ist. Wählen Sie dazu aus dem Auswahlmenü im Feld Eigenschaften den Eintrag Produkt-Umsatz Plan ## (Query) (siehe Abb. 4.66 Query Ausführen, Schritt 1), wechseln darin in den Reiter Planung (Schritt 2) und stellen sicher, dass die Option Query im Änderungsmodus starten ausgewählt ist (Schritt 3). Ist dies der Fall, Sichern Sie die Query nochmals (Schritt 4) und betätigen die Schaltfläche Ausführen… (Schritt 5), um die Query ad-hoc im Webbrowser zu testen.

352

Unternehmensplanung

Abb. 4.67 Query im Webbrowser überprüfen

Nachdem Sie sich mittels Benutzerkennung und Kennwort am System angemeldet haben, erhalten Sie einen ersten Einblick in die ausgeführte, eingabebereite Query (siehe Abb. 4.67 Query im Webbrowser überprüfen). Dieser Schritt dient zur einfachen Überprüfung der Zeilen- und Spaltenanordnungen, aber auch der Eingabebereitschaft der Query. Testen Sie, ob die Spalte der Kennzahl Umsatz Plan eingabebereit ist. Aktualisieren oder gar Speichern der Daten ist im Ad-hoc Reporting über den Webbrowser nicht möglich. Daher kann auch noch keine prozentuale Abweichung errechnet werden. Aufgrund dieser eingeschränkten Funktionalität bedarf es im dritten und letzten Teil dieser zweiten Fallstudie der Entwicklung einer adäquaten Planungsumgebung mit Hilfe des Web Application Designers.

Fallstudie B: BI-Integrierte Planung

353

Abb. 4.68 View erstellen

Im letzten Schritt soll noch ein View auf den Datenbestand erstellt werden, auf dem das Diagramm in der späteren Planungsanwendung basieren soll. Klicken Sie dazu mit einem Rechtsklick auf Abweichung (siehe Abb. 4.68 View erstellen, Schritt 1) und im Kontextmenü auf Filter  Filterwert auswählen (Schritt 2). Innerhalb des sich öffnenden Webseitendialogs selektieren Sie die Kennzahlen Umsatz Ist und Umsatz Plan (Schritt 3) und fügen diese über die Schaltfläche Hinzufügen (Schritt 4) dem Filter hinzu. Beenden Sie den Vorgang über OK (Schritt 5). Die prozentuale Abweichung wird nun ausgeblendet.

354

Unternehmensplanung

Abb. 4.69 View sichern

Um die erstellte Sicht zu speichern, klicken Sie auf einen beliebigen Eintrag in der Ergebnistabelle und im sich öffnenden kontextsensitiven Menü auf den Eintrag View sichern (siehe Abb. 4.69 View sichern, Schritt 1). Vergeben im sich öffnenden Webseitendialog die Beschreibung Produkt-Umsatz Plan View ## und den technischen Namen VIEW2_## (Schritt 2), bevor Sie die Eingaben über OK bestätigen (Schritt 3). Schließen Sie sowohl den Webbrowser, als auch den Query Designer.

Fallstudie B: BI-Integrierte Planung

4.4.3.2

355

Planung mit dem BEx Web Application Designer

Starten Sie den Web Application Designer über das MS Windows Startmenü.

Abb. 4.70 Web Template öffnen

Das im Rahmen der ersten Fallstudie erstellte Web Template soll in diesem Schritt als Vorlage für das zu erstellende, neue Web Template dienen. Klicken Sie dazu auf den Eintrag Produkt-Umsatz Ist Web Template ## [WEBTEMPLATE1_01] im Begrüßungsbildschirm unter Zuletzt verwendete Web Templates öffnen (siehe Abb. 4.70 Web Template öffnen, Schritt 1). Alternativ können Sie das alte Web Template auch wie gewohnt über die Schaltfläche Öffnen… (gestrichelte Markierung) und der Auswahl des Web Template Produkt-Umsatz Ist Web Template ## aus der Historie öffnen.

356

Unternehmensplanung

Abb. 4.71 Web Template sichern

Um sicherzustellen, dass das alte Web Template im Zuge der weiteren Arbeitsschritte nicht aus Versehen überschrieben wird, sichern Sie das neue Web Template zu Anfang über den Eintrag Speichern unter… aus dem Menü des Eintrags Web Template in der Menüzeile (siehe Abb. 4.71 Web Template sichern, Schritt 1). Begeben Sie sich dazu in den zuvor erstellten Ordner Fallstudie BW ## und verwenden die Beschreibung Produkt-Umsatz Plan Web Template ## und den technischen Namen WEBTEMPLATE2_## (Schritt 2). Bestätigen Sie Ihre Eingaben über Sichern (Schritt 3).

Fallstudie B: BI-Integrierte Planung

357

Abb. 4.72 Data Provider anpassen

Als Erstes muss der Data Provider für das Web Template angepasst werden. Klicken Sie dazu doppelt auf den einzigen bisher vorhandenen Data Provider UO_DP1_## (siehe Abb. 4.72 Data Provider anpassen, Schritt 1), um den Data Provider zu pflegen. Benennen Sie den Data Provider in UO_DP2_## um (Schritt 2), selektieren als Data-Provider-Typ Query (Schritt 3) und tippen den Namen der eingabebereiten Plan-Query QUERY2_## in das danebenstehende Feld (Schritt 4). Klicken Sie anschließend auf OK (Schritt 5). Definieren Sie zudem über einen Doppelklick auf das Icon Neuer Data Provider (Schritt 6) einen weiteren Data Provider mit dem Namen UO_DP3_## und dem Data-ProviderTyp Query View mit der Bezeichnung VIEW2_##.

358

Unternehmensplanung

Abb. 4.73 Web Template prüfen

Da die Data Provider im vergangenen Schritt geändert worden sind, die bereits im Web Template vorhandenen Web Items ihre Daten jedoch noch aus dem alten, nicht mehr vorhandenen Data Provider beziehen, bedarf es der Prüfung des Web Template über den Server. Dadurch wird sichergestellt, dass die Daten für die Web Items zukünftig aus den neuen Data Providern bezogen werden. Klicken Sie dazu in der Menüleiste auf den Eintrag Web Template (siehe Abb. 4.73 Web Template prüfen, Schritt 1) und wählen im Menü Auf Server prüfen (Schritt 2). Im Fenster Fehler und Warnungen erscheint die Meldung, dass das Merkmal UO_MP_## im neuen Data Provider UO_DP2_## nicht gefunden werden kann (Schritt 3). Da das Merkmal jedoch während der Durchführung der nachfolgenden Schritte seinen Bezug zum Web Template verliert, können Sie diese Warnung ignorieren.

Fallstudie B: BI-Integrierte Planung

359

Abb. 4.74 Web Item Container einfügen

Ändern Sie die Überschrift des Web Template (z.B. in Produkt-Umsatz Planung 2. Halbjahr 2008) (siehe Abb. 4.74 Web Item Container einfügen, Schritt 1) und klicken Sie auf das Web Item CHECKBOX_GROUP_ITEM_1, um es über die ENTF-Taste auf Ihrer Tastatur zu löschen. Fügen Sie als nächstes das Web Item Container aus der Kategorie Erweitert per Drag & Drop zwischen Überschrift und Tabelle ein (Schritt 2). In diesen neuen Container verschieben Sie nun die bereits im Web Template vorhandenen Web Items BUTTON_GROUP_ITEM_1 (Schritt 3), DROPDOWN_ITEM_1 (Schritt 4), ANALYSIS_ITEM_1 (Schritt 5) und CHART_ITEM_1 (Schritt 6).

360

Unternehmensplanung

Abb. 4.75 Web Item Registerkarten einfügen

Oberhalb des soeben eingefügten Containers platzieren Sie das Web Item Registerkarten (siehe Abb. 4.75 Web Item Registerkarten einfügen, Schritt 1) und bringen darin den mit allen weiteren Web Items gefüllten Container CONTAINER_ITEM_1 unter (Schritt 2).

Fallstudie B: BI-Integrierte Planung

361

Abb. 4.76 Web Item Text einfügen

Als letztes Web Item übernehmen Sie das in der Kategorie Diverse enthaltene Web Item Text in das Layout. Platzieren Sie es ebenfalls innerhalb der Registerkarte TABSTRIP_CONTAINER_ITEM_1, achten Sie jedoch darauf, dass es sich außerhalb des darin bereits enthaltenen Containers CONTAINER_ITEM_1 befindet (siehe Abb. 4.76 Web Item Text einfügen, Schritt 1). Desweiteren löschen Sie die nun nicht mehr benötigte Tabelle unterhalb der neuen Objekte. Dies erreichen Sie über einen Rechtsklick auf die Tabelle und einem anschließenden Linksklick auf den Eintrag 7DEHOOH«Æ Æ /|VFKHQ«Æ Æ Tabelle (Schritt 2).

362

Unternehmensplanung

Abb. 4.77 Web Item Registerkarten bearbeiten

Um die Inhalte des Web Item Registerkarte den einzelnen Registerkarten zuzuweisen, klicken Sie auf das Web Item TABSTRIP_CONTAINER_ITEM_1 (siehe Abb. 4.77 Web Item Registerkarten bearbeiten, Schritt 1) und anschließend unter Eigenschaften auf den Reiter Web-Item-Parameter (Schritt 2). Dort betätigen Sie die kleine Schaltfläche neben dem Eintrag Register-Panel im Parameter Interne Anzeige (Schritt 3). Im folgenden Dialog vergeben Sie die Beschriftung Planung (Schritt 4) und wählen als Untergeordnetes Web Item den Eintrag CONTAINER_ITEM_1 aus dem Selektionsmenü (Schritt 5). Klicken Sie auf OK (Schritt 6). Wiederholen Sie die Aktion für das zweite Register-Panel (Schritt 7), vergeben dafür jedoch die Beschriftung Dokumentation und selektieren das TEXT_ITEM_1 als Untergeordnetes Web Item. Die Registerkarten sind nun vollständig angelegt.

Fallstudie B: BI-Integrierte Planung

363

Abb. 4.78 Web Item Button-Group bearbeiten I

Die Planungsanwendung soll eine Reihe von Schaltflächen beinhalten. Daher bedarf es einer Erweiterung des Web Item Button-Group. Selektieren Sie das BUTTON_GROUP_ITEM_1 (siehe Abb. 4.78 Web Item Button-Group bearbeiten I, Schritt 1), klicken auf die dritte kleine Schaltfläche unter den bereits vorhandenen Drucktasten (Schritt 2) und vergeben im nächsten Dialog die Beschriftung Löschen (Schritt 3). Klicken Sie auf die Schaltfläche des Parameters Befehl (Schritt 4), um die Drucktaste mit einem Befehl zu belegen. Wählen Sie aus dem Reiter Alle Befehle (Schritt 5) und dem Ordner Befehle für Planungsanwendungen den Befehl Planungsfunktion ausführen (Einfach) (Schritt 6) und bestätigen Ihre Auswahl mit Weiter.

364

Unternehmensplanung

Abb. 4.79 Web Item Button-Group bearbeiten II

Im nachfolgenden Dialog wählen Sie als Referenz auf Data Provider vom Typ Filter UO_DP2_## aus (siehe Abb. 4.79 Web Item Button-Group bearbeiten II, Schritt 1) und selektieren über die Schaltfläche des befehlsspezifischen Parameters Planungsfunktion (Schritt 2) die Planungsfunktion PF zum Löschen der Plandaten Fallstudie BW ##, die Sie unter InfoAreas Æ Name Ihrer InfoArea (hier: Uni Oldenburg) Æ Fallstudie BW ## Æ UO_AEL_## finden (Schritt 3). ÖffÖf nen Sie diese (Schritt 4). Schließen Sie die beiden noch geöffneten Dialoge nacheinander über die Schaltfläche OK. Legen Sie gemäß Tabelle 4.10 noch drei weitere Drucktasten für die Button-Group an. Tabelle 4.10 Drucktasten der Planungsanwendung Drucktaste

Sichern

Aktualisieren

Plandaten übernehmen

Beschriftung

Sichern

Aktualisieren

Plandaten übernehmen

Befehl

Geänderte Daten sichern Daten aktualisieren Planungsfunktion ausführen (Einfach)

Referenz auf Data Pro- vider vom Typ Filter

-

UO_DP2_##

Planungsfunktion

-

-

UO_PFK_##

Design

Hervorgehoben

Standard

Standard

Fallstudie B: BI-Integrierte Planung

365

Abb. 4.80 Schaltflächen der Button-Group anordnen

Ordnen Sie abschließend alle sechs Drucktasten über einen Klick auf die voranstehenden Nummern und über die Navigationsschaltflächen links neben der Drucktastenliste in folgender Reihenfolge an: 1 Sichern, 2 PDF erstellen, 3 Aktualisieren, 4 Löschen, 5 Plandaten übernehmen, 6 Schließen (siehe Abb. 4.80 Schaltflächen der Button-Group anordnen, Markierung).

366

Unternehmensplanung

Abb. 4.81 Web Item Dropdown-Box bearbeiten

Aktivieren Sie das Web Item DROPDOWN_ITEM_1 durch einen Klick darauf bzw. durch die Auswahl aus dem Selektionsmenü (siehe Abb. 4.81 Web Item Dropdown-Box bearbeiten, Schritt 1) und ändern Sie die Web-Item-Parameter bezüglich der Datenbindung über die dazugehörige Schaltfläche (Schritt 2) dahingehend, dass statt des bisher ausgewählten Merkmals KalJahr/Monat das Merkmal Buchungskreis in der Merkmalsselektion ausgewählt ist (Schritt 3). Stellen Sie zudem sicher, dass der Parameter Bezeichnung sichtbar durch einen Haken auf On gesetzt ist (Schritt 4). Desweiteren selektieren Sie den Eintrag UO_DP3_## aus dem Selektionsmenü des Parameters Beeinflusste Data Provider (Schritt 5). Auf diese Weise stellen Sie sicher, dass beide Data Provider von der Selektion des Anwenders in der Planungsanwendung beeinflusst werden. Verlassen Sie den Dialog über OK (Schritt 6).

Fallstudie B: BI-Integrierte Planung

367

Abb. 4.82 Web Item Analyse bearbeiten

Die Interaktionen des Anwenders innerhalb des Web Item ANALYSIS_ITEM_1 sollen neben dem Data Provider UO_DP2_## auch den Data Provider UO_DP3_## beeinflussen. Nach dem Selektieren des Web Item (siehe Abb. 4.82 Web Item Analyse bearbeiten, Schritt 1) wählen Sie aus dem Selektionsmenü des Parameters Beeinflusste Data Provider unter Datenbindung den Eintrag UO_DP3_## (Schritt 2).

368

Unternehmensplanung

Abb. 4.83 Web Item Chart bearbeiten I

Selektieren Sie als nächstes das Web Item CHART_ITEM_1 (siehe Abb. 4.83 Web Item Chart bearbeiten I, Schritt 1) und verändern im Parameter Anzeigen die Höhe in Pixel auf 400 (Schritt 2), wählen im Parameter Datenbindung als Data Provider UO_DP3_## (Schritt 3) und setzen den Parameter Achsen zu Anzeige vertauschen unter Interne Anzeige auf On (Schritt 4). Klicken Sie anschließend auf die Schaltfläche Chart bearbeiten (Schritt 5).

Fallstudie B: BI-Integrierte Planung

369

Abb. 4.84 Web Item Chart bearbeiten II

Im sich öffnenden Dialog Grafik bearbeiten klicken Sie dreimal auf die Schaltfläche Weiter (siehe Abb. 4.84 Web Item Chart bearbeiten II, Schritt 1), um in Schritt 4 von 6 - Elementeigenschaften auf die Schaltfläche verfeinern zu gelangen (Schritt 2).

370

Unternehmensplanung

Abb. 4.85 Web Item Chart bearbeiten III

Öffnen Sie im Gruppierungsfeld Übersicht die Baumstruktur des Eintrags Kategorieachse und klicken darin auf den Eintrag Linie (siehe Abb. 4.85 Web Item Chart bearbeiten III, Schritt 1). Im Gruppierungsfeld Linie wiederum wählen unter Texteigenschaften als Richtung den Eintrag Aufw. für Aufwärts aus (Schritt 2). Durch diese Änderung wird die Achsenbeschriftung der Kategorienachse vertikal angeordnet. Dadurch wird bei einer Vielzahl an Textelementen an dieser Stelle die Lesbarkeit sichergestellt. Verlassen Sie den Dialog über Fertigstellen (Schritt 3).

Fallstudie B: BI-Integrierte Planung

371

Abb. 4.86 Web Item Text bearbeiten

Zum Schluss soll das neu hinzugefügte Web Item TEXT_ITEM_1 mit Inhalt gefüllt werden. In vorangegangen Schritten haben Sie dieses Web Item der Registerkarte Dokumentation zugeordnet. Dies liegt darin begründet, dass dem Anwender die Planungsanwendung mittels einer kurzen Beschreibung erklärt werden soll. Selektieren Sie das Web Item (siehe Abb. 4.86 Web Item Text bearbeiten, Schritt 1), setzen den Parameter Zeilenumbruch auf On (Schritt 2) und klicken anschließend auf die Schaltfläche neben dem Parameter Text im Bereich Datenbindung (Schritt 3). Verfassen Sie im dafür vorgesehenen Textfeld eine kurze Dokumentation zu der bereitgestellten Planungsanwendung (Schritt 4) und bestätigen Sie Ihre Eingaben über OK (Schritt 5). Das Plan-Web Template ist somit fertiggestellt. Speichern Sie Ihre Arbeit über die gleichnamige Schaltfläche (Schritt 6) und werfen nach einem Klick auf Ausführen… einen ersten Blick auf das Ergebnis (Schritt 7).

372

Unternehmensplanung

Abb. 4.87 Manuelle Planung im Webbrowser

Nach der Anmeldung am System wird das von Ihnen erstellte Web Template im Webbrowser dargestellt. Beschränken Sie zunächst den Buchungskreis aus Gründen der Übersichtlichkeit auf die Filiale Berlin (siehe Abb. 4.87 Manuelle Planung im Webbrowser, Schritt 1). Geben Sie einen manuellen Planwert von 5500,00 für die Monate 01.2008 bis 06.2008, also Januar bis Juni 2008 ein (Schritt 2) und betätigen anschließend die Schaltfläche Aktualisieren (Schritt 3), um die Änderungen zu übernehmen.

Fallstudie B: BI-Integrierte Planung

373

Abb. 4.88 Planungsfunktion im Webbrowser

Betrachten Sie das Ergebnis (siehe Abb. 4.88 Planungsfunktion im Webbrowser). Über die Schaltfläche Plandaten übernehmen (Schritt 1) kann nun der IstUmsatz des Monats März 2008 als Planwert für alle Monate des zweiten Halbjahres 2008 übernommen werden. Diese Planwerte können ebenfalls manuell editiert werden. Sind Sie mit den Plandaten zufrieden, können Sie die Planwerte über die Schaltfläche Sichern dauerhaft in den Realtime-fähigen InfoCube schreiben (Schritt 2). Möchten Sie hingegen jedoch eine neue Planungsrunde starten und alle bisherigen Planwerte aus dem Plan-InfoCube löschen, betätigen Sie die Schaltfläche Löschen (Schritt 3).

374

Unternehmensplanung

Abb. 4.89 Dokumentation im Webbrowser

Durch einen Klick auf die Registerkarte Dokumentation (siehe Abb. 4.89 Dokumentation im Webbrowser, Markierung) bekommen Sie vom System den von Ihnen hinterlegten Text angezeigt. Zurück in der Registerkarte Planung testen Sie auch die anderen Funktionalitäten der Web Applikation (z.B. PDF erstellen). Haben Sie das Web Template ausreichend studiert, verlassen Sie sowohl den Webbrowser, als auch den Web Application Designer. Sie haben die zweite Fallstudie erfolgreich abgeschlossen. 4.4.3.3

Zusammenfassung

Zur Beginn dieses dritten und letzten Abschnitts der zweiten Fallstudie haben Sie eine eingabebereite Plan-Query Produkt-Umsatz Plan ## erstellt, die dem Anwender bei der Erstellung von Planungsanwendungen zur manuellen Planung, aber auch zur Anwendung von Planungsfunktionen, als Grundlage dient. Aufbauend auf der Aggregationsebene zur Kopierfunktion haben Sie dabei die eingeschränkten Kennzahlen UO_KUI_## für den Umsatz Ist und UO_KUP_## für den Umsatz Plan erstellt und eine Formel zur prozentualen Abweichung zwischen diesen Istund Planwerten spezifiziert. Die Ist-Daten der eingeschränkte Kennzahl Umsatz Ist werden dabei allein aus dem InfoProvider Produkt-Umsatz Ist Fallstudie BW ## bezogen, die Plandaten der eingeschränkten Kennzahl Umsatz Plan hingegen

Fallstudie B: BI-Integrierte Planung

375

stammen aus dem Realtime-fähigen InfoCube Produkt-Umsatz Planung Fallstudie BW ##. Außerdem haben Sie die eingabebereite Plan-Query zur Überprüfung Ihrer Angaben im Webbrowser ausgeführt, um einen ersten Eindruck von der PlanQuery zur Laufzeit zu erhalten und einen View auf den Datenbestand für die spätere Planungsanwendung zu erstellen. Diese Planungsanwendung haben Sie über den Web Application Designer, aufbauend auf dem Web Template der ersten Fallstudie, erstellt und um einige maßgebliche Erweiterungen angereichert. So haben Sie das neue Produkt-Umsatz Plan Web Template ## um Registerkarten und ein Textfeld ergänzt. Außerdem haben Sie kennengelernt, wie die zuvor modellierten Planungsfunktionen über Schaltflächen im Web Application Designer integriert und somit in der Planungsanwendung ausführbar gemacht werden. Da das neue WEBTEMPLATE2_## auf der Plan-Query QUERY2_## als Data Provider aufsetzt, haben Sie desweiteren erfahren, welche Eigenschaften eine eingabebereite Plan-Query mit sich bringt und wie Plandaten manuell über den Webbrowser editiert und im Realtime-fähigen InfoCube abgespeichert werden können.

5 Portaltechnologie 5.1

Grundlagen der Portaltechnologie

In diesem Kapitel werden die theoretischen Grundlagen der Portaltechnologie erläutert. Der erste Abschnitt behandelt den Aufbau und die Konzeption eines Portals aus informationstechnologischer Sicht. Neben den elementaren Bestandteilen eines Portals und der Abgrenzung von mit dem Portal verwandten Technologien wird eine Übersicht der aktuellen Software-Lösungen gegeben und eine allgemeine Referenzarchitektur aufgezeigt, die in verallgemeinerter Form für jede PortalLösung gilt. Der zweite Abschnitt dieses Kapitels widmet sich der UnternehmensportalLösung der SAP AG. Das SAP NetWeaver Portal ist ein in die SAP Platform integriertes Unternehmensportal, das sowohl in reinen SAP-Systemlandschaften als auch in Verbindung mit Fremdherstellersystemen eingesetzt werden kann. Neben einer Vorstellung der allgemeinen Portalelemente und der damit eng verbundenen Bereiche Knowledge Management und Collaboration wird auch auf die Charakteristika der Entwicklung mit dem SAP NetWeaver Portal eingegangen. Der dritte Abschnitt enthält eine praktische Fallstudie, durch welche der Leser erste Erfahrungen im Umgang mit dem SAP NetWeaver Portal sammeln kann und sowohl die allgemeine Bedienung als auch die Integration von Inhalten und deren Darstellung anhand einer Schritt-für-Schritt Anleitung erlernt. Im folgenden Abschnitt wird dem Leser ein allgemeiner Überblick über verschiedene Portaltechnologien gegeben. Die unterschiedlichen Arten von Portalen werden klassifiziert und voneinander abgegrenzt. Anschließend werden sowohl eine Referenzarchitektur für Unternehmensportale als auch die zentralen Bestandteile eines solchen Portals vorgestellt. Weiterhin werden die funktionalen und nicht-funktionalen Anforderungen und Erwartungen an Portale aufgeführt. Die Eigenschaften von Portalen im Vergleich zu ähnlichen Konzepten werden dem Leser vorgestellt, um ihm ein klares Bild der Technologie zu vermitteln.

5.1.1 Einführung In der Einführung soll zunächst die Terminologie genauer definiert werden. Unter dem Begriff Portal wird im Allgemeinen ein Zugang verstanden, wie auch der Ursprung des Wortes porta, aus der lateinischen Sprache übersetzt die Pforte, erkennen lässt. Ein Portal ermöglicht es dem Anwender, eine Struktur zu betreten und die Funktionen im Inneren der Struktur zu nutzen. Es wird ohne weiteres vom Anwender als Zugang wahrgenommen und wirft keine Unklarheiten über die be-

378

Portaltechnologie

reitgestellten Funktionen auf: Der Zweck und die Arbeitsweise des Portals sind eindeutig, auf Anhieb für den Anwender zu erkennen und selbsterklärend, so dass von ihm kein Vorwissen abverlangt werden muss. Diese allgemeinen Eigenschaften eines Portals lassen sich auch auf den Portalbegriff in der Informationstechnologie übertragen. Die Bedienung eines Portals ist eindeutig und die Funktionen sowie der Zweck des Portals sind unmittelbar zu erkennen. Die Eigenschaften eines Portals in der Informationstechnologie lassen sich von den Eigenschaften eines Portals im architektonischen Sinne ableiten. So bietet ein Portal einen zentralen Zugang zu einem Bereich. Dieser besteht aus verschiedenen Informationen und Diensten, er kann individualisiert und personalisiert werden. Der Zugriff auf und die Bereitstellung der Informationen sind dabei über verschiedene Wege möglich. Sehr oft wird der Begriff des Portals synonym für ein Webportal verwendet, wobei es hier jedoch Unterschiede geben kann. Gemeinsam ist diesen die Tatsache, dass Sie den Benutzern individuellen Zugang zu komplexeren Systemen geben. „Ein Portal ist definiert als eine Applikation, welche basierend auf Webtechnologien einen zentralen Zugriff auf personalisierte Inhalte sowie bedarfsgerecht auf Prozesse bereitstellt...“ (Gurzki 2001). In der Informationstechnologie gibt es verschiedene Ausprägungen und Klassifizierungen von Portalen, die im folgenden Kapitel präziser unterschieden werden. So definieren Großmann und Koschek ein Portal als den „zentralen und persönlichen Einstieg (Single Point of Access) in die Informationswelt des Internets oder Intranets, von dem aus Verbindungen zu den relevanten Informationen und Diensten hergestellt werden können.“ (Großmann u. Koschek 2005). Als allgemeine Definition eines Portals in der Informationstechnologie kann folgendes gelten: Ein Portal ist ein in sich geschlossenes System, mittels dem durch Integration Dienste, Daten und Anwendungen weiterer Systeme über einen zentralen Einstiegspunkt angeboten werden. Das Portal übernimmt die Aspekte Personalisierung, Benutzerverwaltung, Individualisierung, Sicherheit, Suche und Darstellung für die integrierten Systeme.

5.1.2 Portale in der Informationstechnologie Innerhalb der Informationstechnologie gibt es verschiedene Ansätze und Konzepte für Portale. Neben individuellen Speziallösungen, die für genau einen Einsatzzweck entworfen wurden, finden sich auch Portal-Lösungen, die eine Vielzahl von unterschiedlichen Aufgaben bewältigen müssen. Portale unterscheiden sich nicht nur in der verwendeten Technologie, sondern auch im angebotenen Funktionsumfang, den notwendigen Vorbedingungen oder der erforderlichen Systemumge-

Grundlagen der Portaltechnologie

379

bung. Da verschiedene Portal-Lösungen generell eine vergleichbare Architektur besitzen, werden im Folgenden konzeptionelle Aspekte aufgeführt, anhand derer eine Unterscheidung möglich ist. Zur besseren Einordnung lassen sich Portale nach den Aspekten Benutzer, Thema und Erreichbarkeit charakterisieren. Zu Bedenken ist, dass Portale nicht in jedem Aspekt eindeutig zu beschreiben sind. Insbesondere umfangreiche Lösungen können mehrere Facetten aufweisen, die nachfolgend vorgestellt werden sollen. Einordnung nach Zugangsbeschränkung Für die Einordnung von Portalen nach der Beschränkung des Einlasses für ihre Nutzer gibt es zwei zentrale Bereiche: Offene Portale, die jedem Nutzer zugänglich sind, und geschlossene Portale, die nur einem limitierten, festgelegten Nutzerkreis zur Verfügung stehen (siehe Abb. 5.1). Zu beachten ist, dass offene Portale auch bei einer obligatorischen Registrierung der Nutzer weiterhin als offen bezeichnet werden können. Die Unterscheidung in der jeweiligen Zielgruppe wird vielmehr über die zugelassenen Nutzer vollzogen: In einem offenen Portal kann sich jeder beliebige Nutzer anmelden und auf die Dienste des Portals zugreifen. Ein geschlossenes Portal hingegen dient einer stark begrenzten Gruppe und erlaubt keine eigenständige Anmeldung am und Nutzung des Systems durch Dritte. Ein Beispiel für ein offenes Portal stellt ein Webportal dar, bei dem sich grundsätzlich jeder interessierte Nutzer anmelden und somit die Funktionalität des Portals verwenden kann. Solch ein Zugang ist normalerweise weder zeitlich noch funktionell befristet. Auch hat der Zeitpunkt der Registrierung keine Auswirkungen auf Berechtigungen.

Nutzergruppe

Festgelegter Nutzerkreis

Nutzergruppe Nutzergruppe

Offenes Portal

Geschlossenes Portal

Abb. 5.1 Unterschiedliche Nutzergruppen bei Portalen

380

Portaltechnologie

Ein geschlossenes Portal kann hingegen nur von Nutzern verwendet werden, die einer bestimmten Gruppe angehören, so zum Beispiel von Angestellten eines Unternehmens oder Mitgliedern einer einzelnen Abteilung. Die Nutzung eines geschlossenen Portals setzt damit die Mitgliedschaft in einer bestimmten Gruppe voraus, die vom Portal profitieren soll. Bei einem geschlossenen Portal wird die Anmeldung somit nicht vom Nutzer selbst vorgenommen, sondern von einer dazu befugten Stelle. Die Berechtigung im Portal ist nicht an den Nutzer selbst gebunden, sondern an seine momentane Position oder Stelle innerhalb der Gruppe. Somit besteht eine inhaltliche und zeitliche Beschränkung der Nutzung. Sollte der Nutzer die Organisationseinheit verlassen, die ihn zur Nutzung des Portals berechtigt hat, so wird ihm sein Zugang zum Portal in der Regel entzogen. Diese recht einfach wirkende Tatsache tritt dann in den Vordergrund, wenn es bestehende Objekte oder Daten gibt, die der Nutzer exklusiv zur Verfügung gestellt bekommen oder über das System bereitgestellt hat. Aber auch bei einem offenen Portal muss die logische Trennung von Inhalten und Inhaltsproduzenten berücksichtigt werden, um eine Kontinuität der vorhandenen Inhalte zu wahren. Die Entscheidung, ob ein Portal für eine offene oder geschlossene Nutzergruppe ausgelegt ist, kann bei Portalen schwer getroffen werden, die beide Möglichkeiten der Nutzeranmeldung auf einer Plattform realisieren. Ein solches Portal dient allen Nutzern als Eingang, stellt der geschlossenen Gruppe aber zum Teil andere und detailliertere Informationen bereit als der offenen Gruppe. Ebenfalls zu überlegen ist, ob ein spezieller Gastzugang in einem geschlossenen Portal aus diesem ein offenes Portal macht. Einordnung nach Thematik Eine thematische Klassifizierung eines Portals erfolgt durch die inhaltliche Ausrichtung des Portals. Dabei gibt es zwei Vertiefungsrichtungen, die ein Portal einschlagen kann: Deckt ein Portal die gesamte Bandbreite verschiedener Themen ab, nimmt es eine horizontale Ausbreitung an. Konzentriert sich ein Portal hingegen thematisch auf einen besonderen Bereich und vertieft diesen, wird von einer vertikalen Ausrichtung des Portals gesprochen (siehe Abb. 5.2). Horizontal ausgerichtete Portale sprechen eine breitere Nutzergruppe an als vertikale. Bei vertikal ausgerichteten Portalen ist es hingegen wahrscheinlicher, dass die Nutzer über einen gewissen Grad an Expertenwissen zum enthaltenen Thema verfügen. Eine Einordnung über die Thematik ist nicht immer eindeutig, da es auch bei einem zentralen Oberthema zu einer horizontalen Ausbreitung des Portals kommen kann, dieses Thema aber nicht unbedingt mit größerer Tiefe behandelt wird (z.B. allgemeines Musikportal, Nachrichtenportal für eine Region).

Grundlagen der Portaltechnologie

Horizontales Portal

381

Vertikales Portal Thema

Thema 1 Vertiefung 1 Thema 2 Vertiefung 2 Thema 3 Vertiefung 3 Thema 4

Vertiefung 4 Thema 5

Thema 6

Vertiefung 5

... Abb. 5.2 Thematischer Unterschied horizontales und vertikales Portal

Die thematische Einordnung hilft aber dabei, eindeutig vertikal ausgerichtete Portale zu identifizieren. Thematisch vertikale Portale können somit auch als Experten-Portale bezeichnet werden. Solche Portale verzichten oft auf einen offenen Nutzerkreis, ohne diesen explizit einzuschränken. Durch die Vertiefung in eine Thematik beschränkt sich der Nutzerkreis automatisch, da die Nutzer ohne Bezug zu der Thematik kein Interesse an der Nutzung des Portals haben. Vertikale Portale bieten oft eine große Menge an Informationen von relativ hoher Qualität an, bei horizontalen Portalen ist das quantitative Angebot der bereitgestellten Informationen insgesamt größer. Einordnung nach Erreichbarkeit Unter dem Aspekt der Erreichbarkeit bilden sich interne und externe Portale heraus. Interne Portale sind nur von einem geschlossenen System aus erreichbar und bieten externen Nutzern nur in Ausnahmefällen Zugangsmöglichkeiten, wohin-

382

Portaltechnologie

gegen externe Portale oft über das gesamte Internet erreichbar sind und ihre Nutzer nicht nur aus einer einzigen Systemlandschaft heraus zulassen. Zwischen dem Zugang zu einem Portal und der zugelassenen Nutzergruppe gibt es keine Abhängigkeiten. So kann es durchaus Portale geben, die zwar einen externen Zugang ermöglichen, aber ihre Nutzergruppe auf einen bestimmten Kreis begrenzen. Als Beispiel sei hier ein über das gesamte Internet erreichbares Portal eines Unternehmens gegeben, das Mitarbeitern Zugriff auf interne Daten gibt. Technisch ist dieses Portal somit einer sehr breiten Nutzerschicht zugänglich, der zugelassene Nutzerkreis beschränkt sich aber auf eine sehr kleine Gruppe aus dieser Nutzerschicht, nämlich den Mitarbeiter des Unternehmens. Diese Konstellation tritt häufig dann auf, wenn die über das Portal erreichbaren Informationen für die Erfüllung externer Dienstleistungen notwendig sind. So können beispielsweise Außendienstmitarbeiter mittels eines solchen Portals beim Kunden vor Ort den direkten Zugriff auf die gesammelten Informationen des Unternehmens haben, ohne dort persönlich anwesend oder in dessen lokalem Netzwerk angemeldet zu sein. Eine Kombination zur Einordnung eines Unternehmensportals anhand der Thematik und des Nutzerkreises ermöglicht eine Einteilung wie in Abbildung 5.3 (vgl. Großmann u. Koschek 2005). Thematik horizontal

Prozessorientiertes Unternehmensportal

Konsumentenportal

vertikal

Anwendungsorientiertes Unternehmensportal

Themenportal

geschlossen

offen Zugangsbeschränkung

Abb. 5.3 Einordnung von Portalen nach Kategorien (vgl. Großmann u. Koschek 2005)

Grundlagen der Portaltechnologie

383

Einordnung nach Benutzerrollen Eine weitere Möglichkeit für eine Einordnung von Portalen ergibt sich, wenn die Gruppen oder Rollenzugehörigkeit der Nutzer als Kategorie verwendet werden. Auf diese Weise können die vom Portal angebotenen Dienste speziell auf Mitarbeiter oder Kunden des Unternehmens ausgerichtet sein. Mitarbeitern werden Informationen und Dienste bereitgestellt, die sie bei der Erfüllung ihrer alltäglichen Arbeit benötigen. Kunden hingegen erhalten Servicedienste oder Einsicht in für sie interessante Vertriebsprozesse. Diese Kategorie kann wiederum in Businessto-Business (B2B) oder Business-to-Consumer (B2C) unterteilt werden, um zwischen Groß- oder Privatkunden zu unterscheiden. Eine dritte Möglichkeit zur Differenzierung ist die Ausrichtung des Portals auf Anlieferung, Produktion und Einkauf aus anderen Unternehmen. Diese Dienste und Informationen überschneiden sich mit einem auf B2B ausgerichteten Portal und unterstützen sehr stark eine externe Rolle, und nicht die eigentliche Unternehmensaufgabe. Die Einordnung nach Gruppen- oder Rollenzugehörigkeit soll im Folgenden nicht näher betrachtet werden, da die gängigen großen Portal-Lösungen und auch allgemeine Portalkonzepte in dieser Kategorie allumfassend sind. Zum einen ermöglichen Portale eine weitläufige Rollen- und Benutzererfassung. Zum anderen ist eine solche Einordnung gleichzusetzen mit einer Einschränkung der für die Nutzer zugänglichen Funktionalität eines Unternehmensportals. All diese Aufgaben können von einem gängigen Portal relativ leicht erfüllt werden. Somit lassen sich nur vereinzelte Portale eindeutig einer dieser Kategorien zuordnen. Als Beispiel sei ein Serviceportal im B2C Bereich genannt, dessen zentrale Funktionalität die Erfassung und Bearbeitung von Reklamationsfällen ist. Die zentralen Kriterien ermöglichen eine generelle Unterscheidung und Einordnung verschiedener Portale in Aufgabenbereiche. Tabelle 5.1 zeigt beispielhaft eine Einordnung gängiger Portalarten nach diesen Kriterien. Tabelle 5.1 Beispielhafte Einordnung verschiedener Portale Benutzer

Thema

Zugang Rolle

Intranet 1

offen

horizontal intern

Intranet 2

geschlossen horizontal intern

unklar

Expertenportal

offen

vertikal

extern

unklar

Webportal

offen

horizontal extern

unklar

Unternehmensportal

geschlossen horizontal extern

unklar

Konsumentenportal

offen

vertikal

extern

B2C

Lieferantenportal

geschlossen vertikal

extern

B2B

Mitarbeiter

384

Portaltechnologie

5.1.3 Unterscheidung Webportal und Unternehmensportal Die bekannteste und am weitesten verbreitete Form des Portals stellt das Webportal dar. Der Aspekt der Zugänglichkeit ist hierfür allerdings kein Ausschlusskriterium. So sind zwar alle Webportale durchgängig extern, also ohne weitere Vorrausetzungen vom gesamten Internet aus erreichbar, dies gilt aber auch für viele Unternehmensportale. Ebenso bieten Webportale wie auch Unternehmensportale dem Nutzer einen hohen Grad an Individualisierung bei der Nutzung des Portals. So ist die Berücksichtigung der persönlichen Einstellungen zur Nutzung der jeweiligen Systeme sowohl bei Webportalen als auch bei Unternehmensportalen gängige Praxis. Ein deutliches Unterscheidungskriterium für diese beiden Arten von Portalen bietet der jeweilige Nutzerkreis. So stehen Webportale jedem Nutzer offen, der bereit ist, die notwendigen Schritte zur Registrierung zu erfüllen. Sehr oft stellt die Nutzung des Webportals auch die einzige Gemeinsamkeit der Nutzer dar. Unternehmensportale hingegen erlauben nur einer stark begrenzten Nutzergruppe die Nutzung der angebotenen Dienste. Diese Nutzergruppe ist zu einem großen Teil aus Angestellten des Unternehmens zusammengestellt. Ebenso spiegelt sich die Organisationsstruktur des Unternehmens in den Gruppen und Rollen der Portalnutzer wider. So können Unternehmensportale auch als geschlossene Portale definiert werden, die lediglich aus einem Intra- bzw. Extranet heraus erreichbar sind (vgl. Stelzer 2004). Webportale bieten dem Nutzer den Zugriff auf verschiedene Informationen, die er zu seinem persönlichen Gebrauch benötigt. Sie stellen ihm sowohl allgemeine Informationen wie aktuelle Nachrichten oder Wetterberichte zur Verfügung, als auch persönliche Informationen wie E-Mail oder den Zugang zu Diskussionsforen und -gruppen. Ein Unternehmensportal hingegen stellt dem Nutzer zwar ebenfalls solche Informationen bereit, bietet ihm aber darüber hinaus noch Informationen zu Geschäftsprozessen und die Einsicht in Unternehmensdaten, die er zur Erfüllung seiner betrieblichen Aufgabe benötigt. Der Nutzer erhält zudem den Vorteil, sich nicht zusätzlich noch an den einzelnen Systemen des Unternehmens anmelden zu müssen, um sich dort die benötigten Daten zusammenzustellen. Das Unternehmen hingegen hat den Vorteil, dass die Zugangsmöglichkeiten des Nutzers an einer zentralen Stelle kontrolliert und verwaltet werden. Ziel eines Webportals ist es, den Nutzern eine reibungslose Kommunikation zu ermöglichen und die gewünschten Informationen bereitzustellen. Dabei greifen Webportale nicht immer nur auf in ihnen abgelegte Informationen zu, es werden auch Dienste externer Anbieter eingebunden, wie beispielsweise Suchmaschinen. Somit werden die vom Nutzer erwünschten Informationen um externe Daten ergänzt. Ziel eines Unternehmensportals hingegen ist es, die internen Abläufe und Prozesse zu optimieren und den Angestellten bzw. Nutzern die zur Abarbeitung des Geschäftsprozesses notwendigen Daten bereitzustellen (vgl. Stelzer 2004). Zwar

Grundlagen der Portaltechnologie

385

haben die Nutzer in einem Unternehmensportal auch die Möglichkeit zur Suche auf den vorhandenen Datenbeständen, diese Daten werden aber tendenziell nicht durch externe Dienste erweitert oder mit externen Suchmaschinen durchsucht. Auch schlägt ein Unternehmensportal selten der Suchanfrage ähnliche Daten vor, denn dies würde die gewünschte Informationsmenge verfälschen. Der Nutzer eines Unternehmensportals kann somit eher als Experte für seinen Bereich der Informationen angesehen werden. Die automatische Zuordnung oder Erweiterung der benötigten Daten würden den Arbeitsablauf eher behindern. Relativ leicht lassen sich Webportale und Unternehmensportale an ihrer Organisationsform unterscheiden: Ein Webportal steht für sich allein als Dienstleister. Das Geschäftsmodell beruht auf einer möglichst hohen Anzahl an Nutzern. Einnahmen werden durch Werbeeinblendungen oder sogenannte Premiumfunktionen erzielt, die für den Nutzer kostenpflichtig sind. Die ständige Gewinnung von neuen Nutzern ist ein Kernaspekt in diesem Modell. Weitere Einnahmequellen liegen in dem Verkauf von (anonymisierten) Nutzerdaten, der Analyse der Nutzer nach Zielgruppen oder der Kopplung an kostenpflichtige Zusatzdienste. Aus technischer Sicht bestehen Webportale oft aus Eigenentwicklungen, die mit Fremdentwicklungen kombiniert werden. Ein Unternehmensportal hingegen steht als ein Werkzeug für die Mitarbeiter des Unternehmens bereit. Das Unternehmensportal steht nicht im Mittelpunkt des Geschäftsprozesses, sondern ergänzt vorhandene Prozesse und Abläufe durch seine Funktionalität. Der Betrieb eines Unternehmensportals muss nicht gesondert organsiert werden, sondern wird in die vorhandene (technische) Informationsinfrastruktur integriert. Unternehmensportale bestehen oft aus standardisierten Lösungen, die an die Struktur des Unternehmens angepasst werden. Ein Unternehmensportal kann ohne weiteres optisch und von der Bedienführung her wie ein Webportal aufgebaut sein. Ebenso kann für den normalen Nutzer die Integration externer Dienste, wie einer Webseite oder eines RSS-Feed ermöglicht werden. Diese Kernbereiche eines Webportals sind jedoch nur von nachrangiger Bedeutung in der Fülle der angebotenen Portalfunktionen. Die hauptsächlich von einem Unternehmensportal angebotenen Funktionen, wie beispielsweise die Integration der vorhandenen Systeme und deren Datenbestände oder die Möglichkeit zu einer Zusammenarbeit der Nutzer über das Portal sind in einem Webportal nicht präsent.

5.1.4 Eine Referenzarchitektur für ein Portal In diesem Abschnitt wird eine Referenzarchitektur für Software zur Realisierung von Unternehmensportalen vorgestellt. Der Aufbau der Software soll die elementaren Bestandteile eines Unternehmensportals aufzeigen, unabhängig vom Produkt eines beliebigen Herstellers.

386

Portaltechnologie

Abb. 5.4 Referenzarchitektur für Portal-Software nach Gurzki und Hinderer (Gurzki 2003)

Mit Hilfe einer solchen Referenzarchitektur kann der allgemeine Aufbau eines Unternehmensportals anschaulich erklärt werden. Die Referenzarchitektur orientiert sich an dem von Gurzki verwendeten Aufbau in Form von Abbildung 5.4 (vgl. Gurzki 2003). Diese Referenzarchitektur ist unabhängig von den konkreten Ausprägungen gängiger Unternehmensportal-Lösungen der bekannten Anbieter.

Grundlagen der Portaltechnologie

387

Mit dieser Architektur kann nicht nur eine unabhängige Auswahl eines Portals zur Integration in eine vorhandene Systemlandschaft erfolgen. Ebenso dient sie dazu, die zentralen Bestanteile eines Unternehmensportals anschaulich zu erklären und aufzugliedern. Dabei geht diese Referenzarchitektur auf die verschiedenen Aspekte einzelner Hersteller ein und vereint sie in einem abstrakten Modell. Weiterer Vorteil einer solchen allgemeinen Architektur ist die problemlose Integration in bestehende Konzepte für betriebliche Informationssysteme (vgl. Gurzki 2003). Aufbau Die grobe Gliederung der Referenzarchitektur teilt sich in die Präsentationsschicht (View), die Anwendungslogik (Model & Controller) und das Backend (externe Systeme). In der Präsentationsschicht sind die möglichen Endgeräte dargestellt. So ist ein Zugriff auf das Portal nicht nur über den Webbrowser möglich, auch für mobile Endgeräte, wie ein WAP-fähiges Mobiltelefon oder PDAs, stehen die Dienste des Portals bereit. Die Arten des Zugriffs sind dabei unterschiedlich gestaltet, um die verschiedenen technischen Möglichkeiten und Restriktionen zu berücksichtigen, die durch die Endgeräte vorgegeben werden. In der Anwendungslogik befindet sich die Funktionalität des eigentlichen Portals. Als Verbindung zur Präsentationsschicht findet sich ein Application Server, der den Zugriff auf die Funktionalität des Portals technisch sicherstellt. Auf diesem Server wird die eigentliche Portalsoftware ausgeführt. Das Konzept der Portalsoftware sieht zwei zentrale Bereiche vor: die Portal-Basisdienste und die Portal-Anwendungen. Unter die Basisdienste fallen allgemeine Aufgaben wie die Rechte- und Benutzerverwaltung, eine Suche, Single Sign-On-Module oder das Management für Struktur, Inhalte und Layout. Die Rechte- und Benutzerverwaltung kann komplett durch das Portal übernommen werden. Ebenso ist es aber möglich, die Benutzerverwaltung durch einen externen Dienst verwalten zu lassen. Angebunden an diese Funktionalität ist ein Single-Sign-On Dienst. Hiermit wird die Berechtigung des Nutzers an die verschiedenen, an das Portal angebundenen Systeme übermittelt. Der Dienst Suche ermöglicht eine Integration der einzelnen Suchergebnisse der verschiedenen Backend-Systeme. So wird die gesamte Suche innerhalb der Systemlandschaft durch die Funktionalität des Portals organisiert. Intern nutzt das Portal vorhandene Suchfunktionalitäten der einzelnen Systeme und bereitet das Ergebnis der Suche entsprechend auf. Mittels des Struktur-Management können personalisierte Darstellungen für den jeweiligen Nutzer ermöglicht werden. Das Layout-Management übernimmt die Darstellungs-Funktionalität für die vom Nutzer angeforderten Dienste und Anwendungen. Dabei werden die Besonderheiten des jeweiligen Endgeräts sowie die Vorgaben und Berechtigungen des Nutzers berücksichtigt. Durch den Basisdienst Content-Management können verschiedene Möglichkeiten zur Erstellung und Verwaltung eigener Inhalte bereitgestellt werden, bis hin zur Funktionalität von

388

Portaltechnologie

eigenständigen Content-Management-Systemen. Weitere Basisdienste des Portals bieten Groupware-Funktionalität, Mail- oder Chat-Dienste oder Arbeitsablaufunterstützung. Portalanwendungen sind individuelle Dienste, deren Funktionen von der jeweiligen Portalsoftware angeboten werden. Im SAP NetWeaver Portal werden diese über eine API aufrufbaren Dienste iView genannt. Diese Portal-Anwendungen können über die API auch die Basisfunktionen des Portals nutzen. Eine weitere Verbindung der Portalsoftware besteht zum Backend. Hier werden mittels Transaktions- und Integrationsdiensten die vorhandenen externen Systeme an das Portal angebunden. Ebenso gibt es mit diesen Diensten die Möglichkeit, externe Systeme als Portaldienste einzufügen (z.B. eine externe Benutzerverwaltung durch einen LDAP-Server oder eine externe Webseite). Die Integration der Systeme in das Backend des Portals ist dabei meist nicht auf die Lösungen des jeweiligen Portal-Herstellers beschränkt, durch verschiedene Integrationsdienste und anpassbaren Schnittstellen wird ermöglicht eine Vielzahl von Informationen und Diensten in das Portal zu integrieren.

5.1.5 Zentrale Portalkonzepte und Funktionen Im folgenden Abschnitt werden die zentralen Funktionen und Konzepte eines Unternehmensportals vorgestellt. Diese Konzepte und Funktionen bilden bei weitem nicht alle Möglichkeiten eines solchen Portals ab. Sie bilden aber den Kern an Funktionalität, der einen unternehmensweiten Einsatz eines solchen Portals ermöglicht. Folgende Funktionalitäten sind die Anforderungen, die von einem Portal erfüllt werden müssen um einen umfassenden Einsatz in einem Unternehmen zu ermöglichen: Single Sign-On Der Begriff Single Sign-On bezeichnet ein Authentifizierungs-Konzept, dies dem Nutzer nach einer einmaligen Identitätsprüfung Zugriff auf alle angeschlossenen Dienste und Rechner ermöglicht (pro Sitzung). Der Nutzer meldet sich dabei an einer zentralen Stelle, in diesem Fall dem Unternehmensportal, an. Seine Berechtigungen werden dabei über das Portal verwaltet und an die entsprechenden Dienste und Systeme weitergegeben oder vererbt. Für den Nutzer hat ein solches Konzept den Vorteil, dass er direkt ohne weitere Anmeldungen alle Dienste und Daten im Portal nutzen kann. Weitere Authentifizierungen von Diensten oder Systemen werden nicht an den Nutzer weitergegeben sondern direkt vom Portal erledigt. Die jeweiligen Berechtigungen des Nutzers werden dabei über eine Rechte- und Benutzerverwaltung kontrolliert. Neben dem dadurch entstehenden Zeitgewinn werden alle weiteren Authentifizierungen intern

Grundlagen der Portaltechnologie

389

durch das Portal vorgenommen, was einen weiteren Schutz gegen Angriffe bietet. Zudem können an den jeweiligen Zugang zum Single Sign-On höhere Anforderungen gestellt werden, (z.B. für die Struktur des Passwortes, eine RFID- oder Chipkartenlösung) da alle Zugriffe auf das Portal und die Systeme nur über dieses Login möglich sind. Für den Betreiber eines Portals ist ein sicheres Login sehr wichtig, da eben über diese zentrale Stelle alle internen Dienste und Systeme verfügbar sind. Sollte nun ein Angreifer den Zugang eines Nutzers übernehmen können, besitzt er automatisch alle Rechte und Möglichkeiten des jeweiligen Nutzers. Dieser Nachteil wird dadurch wieder relativiert, dass der zentrale Zugang schneller und einfacher deaktiviert werden kann als einzelne verteilte Zugangsmöglichkeiten. Personalisierung Unter Personalisierbarkeit oder Personalisierung im Bezug zu einem Portal ist eine Vorauswahl der für den Benutzer verfügbaren Dienste und Informationen zu verstehen. So werden die beim Single Sign-On erhaltenen Berechtigungen dafür verwendet, dem Benutzer nur Zugang zu den Funktionen zu geben, zu denen er berechtigt ist. Mit der Personalisierbarkeit ist eine weitere Möglichkeit gegeben, die Auswahl dieser Dienste anzupassen. So können, je nach Rolle des Nutzers, die verfügbaren Dienste zusammengestellt werden, um seinen Arbeitsablauf zu erleichtern. Diese Rollen-Informationen sind ebenfalls in der Rechte- und Benutzerverwaltung hinterlegt. Somit können gesonderten Rollen auch spezielle Sichten vorgegeben werden, die dann nicht für jeden einzelnen Nutzer erstellt werden müssen sondern als Vorgabe für alle Nutzer dieser Gruppe gelten. Weiterhin besteht bei einer Personalisierung die Möglichkeit, indirekt Vorgänge und Verhaltensweisen des einzelnen Nutzers zu analysieren und ihm mittels Data- und Web-Mining zusätzliche Informationen zu präsentieren. Dabei sollten die angeforderten und die zusätzlichen Informationen formal getrennt werden, um den Nutzer nicht indirekt mit falschen Informationen zu versorgen. Individualisierung Unter Individualisierung oder Individualisierbarkeit wird eine aktiv vom Nutzer ausgehende Personalisierung des Portals verstanden. Dies kann die Auswahl der verfügbaren Dienste betreffen, die ein einzelner Nutzer für sich ausblenden oder gesondert darstellen lassen kann. So können einzelne Dienste deaktiviert werden, wenn sie von dem Nutzer nur selten oder gar nicht genutzt werden. Die benötigten Dienste und Funktionen des Portals rücken somit noch mehr in den Mittelpunkt der Betrachtung des Nutzers. Neben dieser inhaltlichen Gestaltung kann ein Nutzer auch die optische Gestaltung eines Portals für sich anpassen, wenn dies vom Betreiber vorgesehen ist. Zu-

390

Portaltechnologie

sätzlich zur Auswahl verschiedener optischer Gestaltungsthemen kann hier auch eine Anpassung der Schriftgröße oder eine besonders kontrastreiche Darstellung gewählt werden. Damit werden die individuellen Möglichkeiten und Fähigkeiten einzelner Nutzer berücksichtigt. Eine solche Individualisierung ermöglicht einzelnen Nutzern einen barrierefreien Zugang zum Portal. Auch können Nutzer mittels Individualisierung das Portal über verschiedene Endgeräte nutzen und ihre persönlichen Vorlieben für Nutzerführung oder Dialoge hinterlegen. Ebenfalls zur Individualisierbarkeit zählen Möglichkeiten wie Lesezeichen oder Markierungsfunktionen, die das Auffinden häufig genutzter Dienste erleichtern. Mittels Single Sign-On, Personalisierung und Individualisierung können somit sowohl für ganze Nutzergruppen als auch für einzelne Nutzer die Dienste des Portals getrennt bereitgestellt werden und ein kontrollierter Zugriff auf die verschiedenen Dienste und Systeme des Portals ermöglicht werden. Neben der inhaltlichen Bestimmung der Dienste durch den Betreiber ist es dem Nutzer damit auch möglich, seinen eigenen Vorlieben und Fähigkeiten entsprechend, die Dienste des Portals in einer für ihn sinnvollen Weise zu nutzen. Dabei kann sowohl auf verschiedene Barrieren als auch Endgeräte eingewirkt werden und eine jeweils angepasste optimale Nutzung des Portals ermöglicht werden. Kollaboration und Groupware Die gemeinsame Arbeit einzelner Nutzer oder Gruppen rückt vermehrt in das Aufgabengebiet eines Unternehmensportals. So soll die Zusammenarbeit einzelner Nutzer oder einer Gruppe von Nutzern durch technische Hilfsmittel erleichtert werden. Auch über die räumliche Trennung hinweg soll eine Zusammenarbeit an einer Aufgabe ermöglicht werden. So werden immer häufiger die Funktionen von Groupware-Anwendungen in Portale integriert. Elementar ist die Möglichkeit, den Zugriff auf und das Versenden von E-Mails über das Portal vornehmen zu können. Zusätzlich lassen sich im Portal Adressbücher, Notizen oder Terminkalender aufrufen und bearbeiten. Diese Informationen können zudem an weitere Nutzer übermittelt werden. So können Kontaktdaten direkt in der Form weitergegeben werden, in der sie vorliegen und benötigt werden. Neben dem Zugriff auf E-Mails oder der Terminverwaltung kann auch eine Aufgabenverwaltung in das Portal integriert werden. Die Einteilung der Aufgaben und der jeweilige Status lassen sich dann von jedem Nutzer der Gruppe an einer zentralen Stelle einsehen. Bietet ein Portal diese Groupware-Funktionen, wird es dem Nutzer ermöglicht sich bei seiner Arbeit vollständig auf das Portal als elementares Werkzeug zu konzentrieren. So werden alltäglich genutzte Mittel wie E-Mails oder die Terminverwaltung innerhalb des Portals abgewickelt ohne dass ein externes Programm notwendig ist. Ebenso können klassische Meetings, Telefonkonferenzen oder Ar-

Grundlagen der Portaltechnologie

391

beitstreffen durch das Portal ergänzt oder gegebenenfalls ersetzt werden. Bei einem sehr verteilten Nutzerkreis bieten solche Funktionen den Vorteil von enger Zusammenarbeit über weite Distanzen. Zusätzlich zu den bisher genannten Funktionen ist für die Durchführung von virtuellen Meetings, die Integration eines Chat, Instant Messaging oder VoIPModuls möglich, um so eine Kommunikation in Echtzeit zu realisieren. Dokumentenverwaltung und Content-Management Mit der Dokumentenverwaltung wird den Nutzern das gemeinsame Erstellen und Verwalten von Dokumenten ermöglicht. Neben der Integration externer Dokumente können Dokumente auch direkt im Portal erstellt werden. Die jeweiligen Dokumente sind an einer zentralen Stelle (dem Portal) verfügbar und damit für jeden einbezogenen Nutzer erreichbar. Durch Versionierung und Archivierung können verschiedene Autoren, mitunter gleichzeitig, ein Dokument bearbeiten. Veränderungen und Aktualisierungen an den Dokumenten können so auch über einen längeren Zeitraum beobachtet werden. Im Zusammenspiel mit der Rechte- und Benutzerverwaltung des Portals können für jedes Dokument die Bearbeitungsrechte der Nutzer einzeln festgelegt werden. Die durch das Portal verfügbaren Daten können in die entstehenden Dokumente integriert werden. Somit lassen sich Vorlagen für verschiedene Berichte, Präsentationsschriften oder Protokolle schnell mit aktuellen Daten hinterlegen. Zusätzlich können die erstellten und verwalteten Dokumente mit Hilfe des Portals in verschiedenen Formen exportiert und so Nutzern zur Verfügung gestellt werden. Damit können auch Nutzer auf die finalen Versionen der Dokumente zugreifen die nicht als Autor tätig waren. Ebenso können mit dem Export Dokumente außerhalb des Portals verfügbar gemacht werden, beispielsweise als PDFDokument oder als Webseite. Auch nicht als Autor tätige Nutzer können über ein Benachrichtigungssystem von Aktualisierungen und Änderungen in den Dokumenten informiert werden. Wissensmanagement Wissens- oder auch Knowledge Management wird innerhalb des Portals durch mehrere Dienste unterstützt. Zum einen dienen die verschiedenen Kollaborationsdienste neben der Kommunikation der Nutzer untereinander auch dem Austausch von Wissen und unterstützen die Arbeitsabläufe innerhalb des Portals. Durch die Integration verschiedener Systeme und Dienste in das Portal wird allgemein der Zugang zu Informationen erleichtert. So ist die Darstellung der verschiedenen Dienste und der verfügbaren Informationen durch das Portal stets gleichmäßig. Mittels der Dokumentenverwaltung können aggregierte und zusammenhängende Informationen präsentiert werden.

392

Portaltechnologie

Ebenso werden Änderungen an Dokumenten übermittelt oder andere Benachrichtigungen und Notizen hinzugefügt. Auch Diskussionsmöglichkeiten wie Foren, Umfragen oder Ticketsysteme erlauben Austausch und Präsentation von Wissen. Daneben dient die Integration von gemeinsam bearbeiteten Diensten, wie einem Wiki, der Unterstützung des Wissensmanagements. Neben der reinen Identifikation und Authentifizierung kann mit einer Rechteund Benutzerverwaltung jeder Nutzer mit einem Profil verbunden werden, das über die Suchfunktion des Portals auffindbar ist. In einem solchen Profil können neben dem Tätigkeitsbereich oder der Spezialisierung auch Qualifikationen eingetragen werden, die den jeweiligen Wissensbereich des Nutzers widerspiegeln. Prozessmanagement Durch die Integration aller wichtigen Systeme des Unternehmens wird eine Analyse der Geschäftsprozesse vereinfacht. Ebenso wie das Wissensmanagement helfen die verschiedenen Dienste des Portals bei dieser Aufgabe. So lassen sich Kennzahlen durch die verfügbare Datenbasis gut ermitteln. Auch die Dokumentation der Prozesse kann mit den portaleigenen Diensten unterstützt werden. Gleichfalls werden Modelle wie der kontinuierliche Verbesserungsprozess (KVP) durch die Dienste des Portals unterstützt. Die Umsetzung eines solchen Prozesses wird durch die automatisierte Bereitstellung der Informationen im Portal und die gute Vernetzung und Kommunikationsbasis für die Nutzer erleichtert. So arbeitet ein Nutzer, der in einen KVP integriert ist, ausschließlich an einem zentralen System, was bereits eine Optimierung darstellt. Ein Wechsel zwischen verschiedenen Systemen ist nicht mehr nötig und auch das jeweilige Authentifizieren wird dem Nutzer erleichtert. Verschiedene Teilprozesse können halb- oder vollautomatisiert aufeinander folgend ablaufen und benötigen keine zusätzlichen Eingriffe. Suche Die enormen Informationsmengen, die in einem Portal verfügbar gemacht werden können, stammen aus vielen heterogenen Systemen. Dabei sind sowohl die Form und Gestaltung der Daten, als auch eine bereits vorhandene Indizierung oft von unterschiedlicher Qualität. Um das Auffinden von Informationen zu erleichtern, verfügen bereits die einzelnen Systeme über Suchfunktionen. Ebenso wie die einzelnen angebundenen Systeme und Dienste bietet das Portal eigene Suchfunktionalitäten. Die Suchfunktionen des Portals nutzen dabei auch die vorhandenen Funktionen der eingebundenen Dienste und reichen die Suchanfragen weiter. Die Ergebnisse werden durch das Portal präsentiert und fügen sich nahtlos in dessen Gestaltung ein.

Grundlagen der Portaltechnologie

393

Neben diesen vorhandenen externen Möglichkeiten bietet das Portal auch eigene Suchfunktionen, mit denen die im Portal vorhandenen Inhalte durchsucht werden. Dabei können verschiedene Kriterien vom Nutzer festgelegt werden und auch externe Informationen außerhalb des Portals einbezogen werden. So können Suchergebnisse aus dem Internet mit den Ergebnissen des Portals verbunden werden, falls der Nutzer das wünscht. Eine Indexierung bei der Erstellung von Dokumenten ist ebenso möglich wie Web-Mining-Konzepte bei der Präsentation der Suchergebnisse. Auch das Abspeichern von Suchergebnissen in einem eigenen Bereich oder individuell einstellbare Suchmasken für Nutzergruppen schaffen einen Mehrwert für die Nutzung des Portals.

5.1.6 Nicht funktionale Anforderungen an ein Portal Auch an ein Portal gibt es nicht funktionale Anforderungen, die erfüllt werden sollten. Wie bei vielen umfangreichen Softwaresystemen ist die Menge der nicht funktionalen Anforderungen sehr groß, daher wird im Folgenden nur auf einige Aspekte eingegangen. Da in einem Portal die Funktionalität und die Informationen vieler verschiedener Systeme integriert werden, sollten die nicht funktionalen Anforderungen nicht unterschätzt werden. Das Portal bietet den (einzigen) zentralen Zugang für eine (neu entstehende) Struktur von Informationssystemen und stellt somit ein zentrales Element dar. So muss das Portal eine sehr hohe Zuverlässigkeit bieten. Das eingesetzte Produkt muss neben einer hohen Fehlertoleranz auch eine hohe Verfügbarkeit bieten, denn ein technischer Ausfall hätte einen Totalausfall des Zugangs für die meisten Nutzer zur Folge. Durch eine ergonomisch durchdachte Gestaltung des Portals wird die Akzeptanz des Systems bei den Nutzern erhöht. So müssen die optische Gestaltung und die Benutzerführung, das Look and Feel, den Nutzern nicht nur Spielraum für individuelle Vorlieben geben. Auch eine durchdachte Benutzerführung sorgt für eine Zustimmung der Nutzer. So sollte dem Nutzer nicht sofort der gesamte Funktionsumfang zur Verfügung gestellt werden. Besser ist es, die verfügbaren Funktionen entsprechend zum verwendeten Dienst einzublenden oder dem Nutzer eine Unterscheidung zwischen einem normalen und einem Expertenmodus zu gestatten. Die Bedienung und Benutzbarkeit des Portals muss leicht zu erlernen sein, da die Nutzer unterschiedliche Vorkenntnisse besitzen. Neben der technischen Zuverlässigkeit ist für den laufenden Betrieb eine gute Wartbarkeit erstrebenswert. Lange Wartungspausen senken die Produktivität des Systems, eine Wartung zur Laufzeit ist daher von Vorteil. Da ein Portal nicht in regelmäßigen Zügen angeschafft oder erneuert wird, sollte ein Portal plattformunabhängig, skalierbar und leicht erweiterbar sein. Auch eine Übertragbarkeit der Daten oder einen Export des gesamten Portals auf ein anderes Medium sollte berücksichtigt werden. Dies ermöglicht zum einen das Erstellen von Datensicherun-

394

Portaltechnologie

gen, zum anderen bietet es auch einen Weg die vorhandenen Daten später in ein neues System zu überführen. Zusätzlich zu den technischen Anforderungen sind Sicherheitsanforderungen zu berücksichtigen. Neben den erwähnten Datensicherungen ist auch die Zugangssicherung des Systems essentiell. Da der Zugang zum Portal auch Zugang zu allen weiteren Systemen ermöglicht, ist eine hohe Absicherung des Systems die Basis für ein Sicherheitskonzept. Eher sekundär von Bedeutung, aber auch zu Bedenken, sind rechtliche Anforderungen an das System. Eine Frage die sich stellt ist, ob die integrierten Daten so genutzt werden dürfen wie es vorgesehen und geplant ist. Entsprechende Datenschutzgesetze und Richtlinien sollten vor Integration eines Portals berücksichtigt werden. Auch der Leistungsbedarf des Portals als elementarer Bestandteil sollte nicht als wichtigstes Kriterium gelten. Eher sollte die benötigte Hardware nach den Anforderungen des Portals ausgewählt werden. Da ein Portal stark genutzt wird, ist eine entsprechende technische Basis für einen effizienten Betrieb notwendig. Wichtige nichtfunktionale Anforderungen an die einzelnen Portalkomponenten und das gesamte Portal die einen wesentlichen Einfluss auf die Qualität des Portals haben sind Akzeptanz, Zukunftsfähigkeit, Betriebssicherheit und Investitionssicherheit des Systems (vgl. Hasselbring, Koschel und Mester 2001).

5.1.7 Überblick über den Portalsoftwaremarkt Folgend wird ein kurzer Überblick über einige Anbieter für Unternehmensportale gegeben. Im späteren Verlauf wird das Produkt der SAP AG, SAP NetWeaver Portal in der Version 7.0 genauer vorgestellt. Auch die im Buch vorliegende Fallstudie ist für diese Unternehmensportal-Software gedacht. Die Übersicht orientiert sich am Magischen Quadrat der Gartner Group wie in Abbildung 5.5 dargestellt (vgl. Gartner 2006). Mit diesem Quadrat werden kommerzielle Portalsoftware-Anbieter anhand von zwei Merkmalen in je zwei Quadranten eingeordnet. Zum einen die ability to execute, welche die Handlungsfähigkeit und Möglichkeit zur Umsetzung darstellt. Die Einstufung der Anbieter in diesem Merkmal wurde anhand von sieben verschiedenen Kriterien vorgenommen:       

Produkt gesamte Durchführbarkeit Erlös Marketingwirkung Marktreaktionen Kundenerfahrung Geschäftstätigkeit

Grundlagen der Portaltechnologie

395

Die Punkte Produkt, Durchführbarkeit und Marktreaktionen wurden dabei stärker bewertet als die übrigen Kriterien. Anhand dieser Punkte wurde die Handlungsfähigkeit des Anbieters festgelegt. Das andere Merkmal ist die completeness of vision welche die Vollständigkeit der Vision und die erreichte Abdeckung des Produktes darstellt. Die Einstufung in diesem Merkmal wurde diesmal anhand von acht Kriterien vorgenommen:        

Markt Verständnis Marketingstrategie Verkaufsstrategie Angebotsstrategie für das Produkt Geschäftsmodel Vertikale Sparten Strategie Innovationen Geographische Strategie

Die Kriterien Angebotsstrategie für das Produkt, vertikale Sparten Strategie und Innovationen wurden dabei stärker bewertet als die restlichen Kriterien. Die vier Quadranten gliedern sich in challengers, leaders, niche players und visionaries (vgl. Gardner 2006). Challengers oder auch Herausforderer sind Anbieter die eine hohe Handlungsfähigkeit besitzen und über gute Möglichkeiten zur Umsetzung ihrer Produkte besitzen. Die Produkte dieser Anbieter decken mit ihren angebotenen Leistungen allerdings nur einen kleinen Teil der Anforderungen ab. So besitzen die Produkte dieser Anbieter keine innovativen oder neuen Funktionalitäten. Leaders bzw. Marktführer sind Anbieter die über eine hohe Handlungsfähigkeit verfügen und deren Produkte viele der Anforderungen des Marktes abdecken. Die Produkte dieser Anbieter prägen den Markt und sind auf langfristige Nutzung ausgerichtet. Die Marktführer bestimmen mit ihren Entwicklungen die Ausrichtung des Portalmarktes.

396

Portaltechnologie

Abb. 5.5 Magisches Quadrat der Gartner Group (Gartner 2006)

Niche players oder auch Nischenanbieter verfügen über keine starke Handlungsfähigkeit und konzentrieren sich mit ihren Portal-Produkten auf einzelne Märkte. Die Funktionalität der Produkte beschränkt sich auf spezielle Anwendungen oder dient als Zugang zur Produktfamilie des Herstellers. Visionaries sind Visionäre, deren Produkte mit sehr innovativen neuen Funktionalitäten aufwarten. Allerdings besitzen die Anbieter dieser Produkte (noch) keine großen Fähigkeiten zur Umsetzung oder sind nur bedingt handlungsfähig. Einziger Herausforderer zum Zeitpunkt der Studie war Fujitsu (Interstage Portal), dessen Produkt bisher nur auf dem heimischen Markt verbreitet ist. Der Quadrant der Marktführer hingegen war umkämpft, unter anderem mit Anbietern wie der SAP AG (NetWeaver Portal), Microsoft (SharePoint Portal Server 2003) und IBM (WebSphere Portal). Auch Oracle (Oracle Portal) und BEA Systems (WebLogic Portal) sind in diesen Bereich einzuordnen. Sun Microsystems (Sun Java System Portal Server) und Vignette vervollständigen die Gruppe der Marktführer dieser Studie. Die Produkte dieser Anbieter zielen auf Unternehmen als Abnehmer ihrer Produkte. Langfristige Ausrichtung und umfangreiche Funktionalitäten zeichnen die Produkte aus.

Grundlagen der Portaltechnologie

397

Alleiniger Anbieter in der Einstufung als Visionär ist Tibco Software mit PortalBuilder. Im Vergleich mit den Marktführern fehlt es dem Anbieter noch an der Fähigkeit zum starken Marketing und Verkaufsstrategie ihrer Produkte, die aber über innovative Ansätze in der Portalfunktionalität verfügen. Stärker besetzt ist der Bereich der Nischenanbieter mit Anbietern wie CA, Hummingbird, webMethods, BroadVision und Day Software. Die Produkte dieser Anbieter verfügen nur über begrenzte Funktionalitäten oder die Anbieter nicht die notwendigen Fähigkeiten die vorhandenen Funktionalitäten zu vermarkten.

5.1.8 Verwandte Konzepte der Portaltechnologie Neben einem Unternehmensportal gibt es Konzepte, die von ihren Funktionalitäten einen Teil der Aufgaben eines solchen Portals übernehmen können. So besteht bei den folgenden Konzepten zwar ein gewisser Zusammenhang zu einem Portal, doch lassen sich diese Systeme auch deutlich abgrenzen. Ein Intranet(-Portal) wirkt durch die hinterlegten Informationen und die Art der Gestaltung auf den ersten Blick wie ein Unternehmensportal. Die dargestellten Informationen stammen dabei aber nicht aus den verschiedenen Systemen des Unternehmens sondern werden eigens im Intranet hinterlegt. Auch ist ein Zugriff von außerhalb des Unternehmens nicht oder nur unter Umständen (VPN) möglich. Der Zugriff auf interne Systeme wird nicht unterstützt und es wird auch keine Verbindung zwischen diesen Systemen hergestellt. Weiterhin fehlt einem Intranet oft die ausgeprägte Rechte- und Benutzerverwaltung eines Portals. Die Nutzer melden sich zwar an einem zentralen Punkt an, es existiert aber kein individueller oder personalisierter Zugang zu den entsprechenden Informationen. Ein Intranet ist von seinen angebotenen Funktionalitäten eher ein Vorgänger der aktuellen Unternehmensportale. Content-Management-Systeme wirken durch die zentrale Generierung, Verwaltung und Bearbeitung von Inhalten ebenfalls verwandt mit Portalen. Bei ContentManagement-Systemen liegt dabei der Schwerpunkt auf diesen Funktionen. Auch die vorhandene Nutzerverwaltung oder die Kommunikationsmöglichkeiten sind auf den jeweiligen Inhalt ausgerichtet. Bei einem Portal hingegen ist zwar die Funktionalität eines Content-Management-System enthalten, doch dient dies nur als ein Mittel von vielen um die Abläufe und Prozesse des Unternehmens abzubilden und umzusetzen. Auch eine Integration der internen Systeme ist in ein Content-Management-System kaum oder gar nicht möglich. Ebenso können Groupware-Anwendungen nur einen Teil der Funktionalität eines Portals abbilden. Zwar werden die notwendige Kommunikation und Interaktion der Nutzer bereitgestellt, aber weite Aspekte des Portalkonzepts lassen sich mit diesen Mitteln nicht darstellen. Auch die inhaltliche Tiefe der Nutzerprofile lässt sich nicht mit den Profilen innerhalb eines Portals vergleichen.

398

Portaltechnologie

Die Verteilung der zentral gelagerten Daten der internen Struktur an eine hohe Anzahl externer Nutzer kann auch mittels eines Client-Server Konzepts realisiert werden. Dabei wird das eigentliche Frontend des Portals in den Client ausgelagert. Eine Zugriffskontrolle wird neben der eigentlichen Authentifizierung auch von der Verfügbarkeit des Client abhängig gemacht. Über den Client können dann die auf dem Server gelagerten Daten genutzt und bearbeitet werden. Im direkten Vergleich mit einem webbasierten Unternehmensportal gibt es aber mehrere Nachteile für ein Client-Server Konzept. So ist es beim Portal sehr schnell und sehr leicht möglich Portalinhalte anzupassen oder zu verändern. Die Gestaltung des Portals kann direkt geändert werden und es ist sichergestellt, dass alle Nutzer die aktuell geforderten Änderungen erkennen. Bei einer solchen Änderung müssten alle Clients erneuert oder aktualisiert werden, was neben dem zeitlichen und technischen Aufwand auch Probleme im Ablauf mit sich bringt. Die Bereitstellung eigens erstellter Inhalte an weitere Nutzer kann mittels eines Client auch nicht ohne weiteres erfolgen, da diese Änderungen zumeist nur lokal vorliegen und getrennt von den übrigen Clients erstellt wurden. Werden diese Änderungen nun wieder in einer anderen, vereinfachten Form (Webanwendung, Dokument) exportiert so geht ein Vorteil des Client-Server Konzepts direkt verloren: Der Client ermöglicht rechenintensive und aufwendige Bearbeitung der Daten und kann dabei auf die Ressourcen des Nutzerrechners zurückgreifen, ohne eine Last auf dem Server zu erzeugen.

5.2

SAP NetWeaver Portal

Das SAP NetWeaver Portal stellt die Unternehmensportal-Lösung der SAP AG dar und ist Teil der SAP NetWeaver Platform. Innerhalb der SAP NetWeaver Platform ist das Portal der Integrationsschicht der People Integration zugeordnet (siehe Abb. 5.6). Diese Schicht enthält neben dem Portal die Funktionsbereiche Collaboration, SAP NetWeaver Business Client und Multi-Channel Access. Gemeinsam ist diesen Bereichen die Verbindung von Funktionen und Informationen mit den Nutzern der Lösungen. So bietet der Business Client die Möglichkeit Portal Services zu nutzen und die Collaboration ist mit dem gesamten Funktionsumfang innerhalb des Portals eingebunden.

SAP NetWeaver Portal

399

Abb. 5.6 Integrationsschicht People Integration (SAP 2008a)

Innerhalb dieser Integrationsschicht bietet das SAP NetWeaver Portal ein Frontend und einen zentralen Zugang für die SAP NetWeaver Platform. Das Portal bietet Zugriff sowohl auf die internen Informationen der in die Plattform integrierten Systeme als auch auf externe Informationen. Ebenso ist ein Zugriff auf die Anwendungen und Services der angebundenen Systeme aus dem Portal möglich. Somit wird ein zentraler Einstiegspunkt für den Zugriff auf die Informationen aus diesen verschiedenen Quellen gegeben.

5.2.1 Einführung SAP NetWeaver Portal Die wichtigste Eigenschaft eines Unternehmensportals ist es, einen zentralen Einstiegspunkt zu allen Anwendungen und Informationen zu schaffen, die der Nutzer für die Erfüllung seiner täglichen Aufgaben benötigt.

400

Portaltechnologie

Das Portal ermöglicht diesen Zugriff unter Berücksichtigung einiger zentraler Konzepte. Der Zugriff auf die Anwendungen, Informationen und Dienste der an das Portal angeschlossenen Systeme erfolgt:  webbasiert  abgesichert  rollenbasiert Dadurch können Nutzer aus den verschiedenen Bereichen eines Unternehmens mit einem einzigen Zugang ihre verschiedenen Aufgaben erledigen. Der webbasierte Zugang ermöglicht einen Zugriff auf die Daten unabhängig vom aktuellen Standort, des verwendeten Computers und dem Zeitpunkt des Zugriffes. Die Plattformunabhängigkeit ermöglicht den Zugriff auf das Portal mit verschiedenen Betriebssystemen und das mehrsprachige Interface unterstützt einen globalen Einsatz des Portals für mehrere Unternehmensniederlassungen. In Abbildung 5.7 wird die Position des SAP NetWeaver Portals als zentraler Einstiegspunkt in die Systemlandschaft des Unternehmens verdeutlicht. Die Zugangsberechtigung wird durch ein Rollenkonzept unterstützt. Nach der Authentifizierung bekommt der Nutzer abhängig von seiner Position im Unternehmen und der damit verbundenen Rolle im Portal Zugang zu den für ihn bedeutsamen Informationen und Anwendungen. Der Zugang ist dabei nicht auf Nutzer beschränkt die auch lokal Zugang zu den angeschlossenen Systemen bekommen könnten. So können auch Mitarbeiter im Außendienst oder die Nutzung des Portals vom privaten Anschluss realisiert werden.

SAP NetWeaver Portal

401

SAP NetWeaver Portal Entscheidungsträger

HR-Mitarbeiter

Authentifizierung

Systemsupport Mitarbeiter

Außendienst

SAP NetWeaver Portal

Knowledge Management

Angeschlossene Fremdysteme

Single Sign On

SAP ERP

Collaboration

SAP NetWeaver Business Intelligence

Abb. 5.7 SAP NetWeaver Portal als zentraler Einstieg in die SAP NetWeaver Platform

Der Nutzer meldet sich einmal im SAP NetWeaver Portal an, der Zugriff und die Berechtigungsprüfung zu den Informationen, Anwendungen und angeschlossenen (Fremd-)Systemen in der SAP NetWeaver Umgebung werden vom Portal übernommen. So muss der Nutzer nur einmal pro Sitzung die Authentifizierung durchzuführen. Das weitere Sicherheitskonzept des Portals umfasst neben der Authentifizierung der Nutzer und der Single-Sign-On Lösung ein integriertes User Management und die technische Verschlüsselung der Kommunikation (vgl. SAP 2008a). Der webbasierte Zugriff ermöglicht den Zugang zum Portal unabhängig vom verwendeten Betriebssystem und Internetbrowser. Dennoch gibt es Einschränkungen je nach Release der Portal-Version. Für das Release 7.0 wird der Internet Explorer unter der Windowsplattform vollständig unterstützt. Für Version 7 des Internet Explorers sollte das Service Pack 10 von SAP NetWeaver installiert sein. Für Windows, Mac OS und Linux-Derivate wird der Firefox-Browser unterstützt. Hier sind allerdings Einschränkungen bei der Benutzung des Visual Composer sowie der Portaladministration vorhanden, die nur teilweise durch die Service Pack Stacks behoben wurden (vgl. SAP 2008a).

402

Portaltechnologie

Das Portal enthält bereits vordefinierte Inhalte, die bei der Integration und Nutzung des Portals eine Zeitersparnis ermöglichen. Ebenso sind die SAP NetWeaver Komponenten Knowledge Management und Collaboration eng an das Portal angebunden und erlauben die Integration der angebotenen Funktionen und Informationen. Die zentrale Darstellung von Anwendungen und Informationen wird von Portal-Diensten übernommen, den SAP iViews. Mit Hilfe dieser iViews können die Daten aus den angebundenen Systemen aufgerufen werden und dargestellt werden. Ebenso besteht die Möglichkeit Informationen und Daten aus dem Internet über einen iView in das Portal einzubinden. Die gesamte Oberfläche des Portals kann an die individuellen Anforderungen des Unternehmens angepasst werden und unterstützt eine Vielzahl von Anwendungsszenarien mit einem offenen und flexiblen Navigationskonzept. Neben der bereits erwähnten Unterstützung der Mehrsprachigkeit wird die Flexibilität auch durch Personalisierungsmöglichkeiten für den einzelnen Nutzer gegeben. So kann der Nutzer für sich das kompletten „Look and Feel“ des Portals anpassen, beispielsweise mit verschiedenen graphischen Themen oder über die Wahl der angezeigten iViews. Somit kann das Portal auch für eine barrierefreie Nutzung eingerichtet werden, indem etwa Themen mit einem starken Kontrast bereitgestellt werden. Weitere Möglichkeiten für eine barrierefreie Nutzung des Portals stellen variable Schriftarten, die Möglichkeit zur Tastaturnavigation innerhalb des Portals oder die Kompatibilität für Screen Reader dar. Die Administration des Portals erlaubt die Verwaltung der Nutzer und der Rollen, des Portal Inhalts und eine Anpassung der Portalgestaltung. Über das Portal Content Studio können der Inhalt und die Objekte des Portals verwaltet werden. Die Verwaltung läuft rein graphisch ab und trennt den Nutzer von der programmiertechnischen Ebene der Administration (vgl. SAP 2008a). Die RollenVerwaltung ermöglicht die Anpassung der Standardbenutzerrollen und die Generierung eigener Rollen. Durch diese Rollen kann die Hierarchie und Struktur des Unternehmens auf die Nutzer des Portals abgebildet werden. Über die Administration kann die Gestaltung des Portals der Corporate Identity angepasst werden. Ebenso kann hier bestimmt werden, inwieweit die einzelnen Nutzer Anpassungen an der Gestaltung ihrer Sicht des Portals vornehmen dürfen. Auch die verfügbaren Themen und Sprachen können hier festgelegt werden. Die Verwaltung der Nutzer kann sowohl losgelöst im Portal, als auch in Verbindung mit einem hinterlegten Verzeichnisdienst erfolgen (vgl. SAP 2008a). Die Anbindung an ein Verzeichnis mit Nutzerdaten erlaubt die Integration der vorhandenen Berechtigungen aus den bestehenden SAP-Systemen. Die Integration der Informationen aus verschiedenen heterogenen Systemen innerhalb des Portals wird durch vordefinierte Inhalte in Form von Business Packages unterstützt. Diese Inhalte können direkt genutzt werden und stammen aus dem SAP Portal Content Portfolio.

SAP NetWeaver Portal

403

5.2.2 Allgemeine Portalfunktionen In diesem Abschnitt werden nun die zentralen Funktionen des Portals vorgestellt. Authentifizierung Die erste Funktion, die einem Nutzer begegnet, ist die Authentifizierung, denn ohne ein gültiges Login ist keine individuelle Nutzung des Portals möglich. Der Zugang zum SAP NetWeaver Portal erfolgt dabei über eine URL in der Form: http://:<port>/irj/portal Der Port definiert sich nach der Systemnummer der Portalinstallation und baut auf dem Muster 50000 plus (Systemnummer)×100 auf. Die Standard-Methode der Authentifizierung erfordert vom Nutzer die User ID und sein Passwort. Bei der ersten Anmeldung an das Portal verfällt das initial bestimmte Passwort und vom Nutzer muss ein eigenes Passwort gewählt werden. Die Bedingungen für dieses Passwort bestimmen minimale Länge und Zusammenstellung des Passwortes. So wird beispielsweise durch eine Kombination von vier Ziffern und vier Zahlen ein Passwort mit einer minimalen Länge von acht Zeichen vorgegeben. Bei erfolgreicher Authentifizierung erhält der Nutzer ein zeitlich beschränktes SAP Login-Ticket in Form eines Cookies. Neben der individuell festzulegenden Gültigkeitsdauer enthält dieser Cookie auch die User ID und die Signatur des austellenden Systems. Dieses Ticket wird auch für weitere Authentifizierungen genutzt und ermöglicht somit den Zugriff auf die verschiedenen Bereiche des Portals und die angebundenen Systeme (siehe Single Sign-On). Diese HTTP-basierte Methode kann durch die Verwendung von SSL stärker abgesichert werden. Die Gültigkeit einer solchen Authentifizierung hängt vom Cookie ab. Wird beispielsweise das Browserfenster geschlossen in dem das Portal enthalten ist, kann der Logout-Prozess angestoßen werden. Weitere Authentifizierungsmethoden beruhen auf der Verwendung von Zertifikaten (x.509) oder externe Authentifizierungen (NTLM, WAM oder JAAS). Zusätzlich lässt sich ein anonymer Zugang zum Portal realisieren, der Nutzer ruft dafür eine leicht abgeänderte Adresse auf: http://:<port>/irj/portal/anonymous Unter dieser Adresse sind die öffentlich freigegebenen Inhalte des Portals erreichbar. Die Inhalte für anonyme Nutzer müssen gesondert freigegeben werden, zusätzlich sollte die Rolle eines Nutzers zum anonymen Zugang erstellt werden. Für mehrsprachige Portale kann ein gesonderter Benutzer für jede Sprache der Inhalte notwendig sein. Einzelne Gast-Nutzer können unterschiedliche Ansichten erhal-

404

Portaltechnologie

ten, dies erfolgt über einen Anhang in der Form ?guest_user=<username> an die obige Adresse. Auf diese Weise können mehrere anonyme Nutzer Zugriff auf für sie vorbereitete Inhalte erlangen, ohne diesen Nutzern ein eigenständiges Profil zu erstellen. Die Inhalte werden allein über die Berechtigung der anonymen Nutzer identifiziert und angezeigt. Single Sign-On Eng verbunden mit der Authentifizierung ist die Single Sign-On Funktion des Portals. Die Möglichkeit, einem entsprechend berechtigten Nutzer nach einmaliger Authentifizierung, der Anmeldung im Portal, den Zugriff auf alle Systeme zu gestatten wird auch im SAP NetWeaver Portal realisiert. So wird es einem Nutzer des Portals ermöglicht, sich zu Beginn der Arbeit im Portal anzumelden und über das Portal auf alle benötigten Systeme zugreifen zu können, ohne eine gesonderte Anmeldung auf diesen Systemen durchführen zu müssen. Neben der Erleichterung für den Benutzer, der sich nur noch eine Kombination von Login und Passwort merken muss, wird auch aus Sicht der Systemverwaltung eine einfachere und sichere Zugriffsregelung ermöglicht. Die Realisierung des Single Sign-On innerhalb von SAP NetWeaver Portal lässt sich mit den meisten der Authentifizierungsmethoden durchführen. Es ist offensichtlich, dass ein Zugriff auf angebundene Systeme oder Anwendungen nicht ohne besondere Voreinstellungen für den anonymen Zugang vorgesehen ist. Für jeden Nutzer des Portals muss die Single Sign-On Konfiguration einmalig vorgenommen werden, um diese Funktion nutzen zu können. Die häufigste Anwendung von Single Sign-On stellt die Verbindung zu einem an das SAP NetWeaver Portal angeschlossenen SAP-System dar. Bei dieser Anwendung gibt es drei mögliche Szenarien, wie der Zugriff aus dem Portal über Single Sign-On auf ein angeschlossenes SAP-System realisiert werden kann:  Single Sign-On über die SAP Logon-Tickets  Single Sign-On über Logon-Tickets und Usermapping  Single Sign-On über Usermapping Die erste Variante stellt Single Sign-On über die bei der Authentifizierung erstellten Logon-Tickets dar. Diese Möglichkeit kann dann genutzt werden, wenn der Nutzer im Portal und im angeschlossenen System die gleiche UserID besitzt. In diesem Fall muss das Logon-Ticket-Zertifikat des Portals exportiert und in das Ziel-System importiert werden. Sobald das Zertifikat des Portals in das angeschlossene SAP-System importiert wurde, kann sich der Nutzer ohne Authentifizierung im System anmelden, da er sich mit seiner UserID bereits im Portal als berechtigter Nutzer angemeldet hat (vgl. SAP 2008a). Sollte der Nutzer eine andere UserID im angebundenen System führen, so ist neben dem Import des Logon-Ticket-Zertifikats des Portals ein User Mapping anzulegen. Diese zweite Version des Single Sign-On ist eine Erweiterung der ersten

SAP NetWeaver Portal

405

Variante. Für das User Mapping wird ein Referenzsystem angegeben, das den IDVergleich beinhaltet. Sollte eine Nutzung der Logon-Tickets nicht möglich sein, so kann in der dritten Variante allein auf das User Mapping zurückgegriffen werden. Diese Lösung ist nur für die Versionen älterer SAP-Systeme vorgesehen, die kein Logon-Ticket unterstützen (vgl. SAP 2008a). In diesem Fall werden das entsprechende Passwort und die UserID übertragen, daher sollte aufgrund von Bedenken zur Systemsicherheit diese Möglichkeit nur selten genutzt werden. Nach Anpassung der Systemdefiniton wird das User Mapping erstellt und die Werte für den zu übertragenden User werden im Identity Management des Portals hinterlegt. Diese Funktionen ermöglichen dem Nutzer nach der Anmeldung im Portal alle Systeme, Anwendungen und Informationen zu verwenden, auf die er in den einzelnen Systemen berechtigten Zugriff hat. Auch benötigt der Nutzer keine weiteren Maßnahmen zur Authentifizierung vorzunehmen, da diese Aufgabe vom Portal übernommen wird. Rollen, Gruppen und Nutzer im Portal Zu den vorgenerierten Inhalten des Portals gehören verschiedene Standardbenutzerrollen, die verschiedene Aufgaben enthalten und direkt nach Installation des Portals genutzt oder an die eigenen Anforderungen angepasst werden können (vgl. SAP 2008a). Für die administrativen Aufgaben im Portal gibt es mehrere Rollen:     

Super Administrator System Administrator Content Administrator User Administrator Delegated User Administrator

Die Rolle des Super Administrator stellt die maximale Menge an möglichen Zugriffsrechten dar. In dieser Rolle sind alle administrativen Aufgaben des Portals integriert. Somit ist ein Nutzer, der die Rolle des Super Administrator hat, automatisch auch Content Administrator, User Administrator und System Administrator. Er besitzt ebenfalls ein Zugriffsrecht auf alle vorgenerierten Objekte des Portals. Die Rolle des Super Administrator ist sehr mächtig und spiegelt den Hauptverantwortlichen des Portals wieder. Diese Rolle kann die anderen Administratorentätigkeiten ausführen und eine Koordination über dem gesamten System ermöglichen. Für die tägliche Arbeit im Portal sollte jedoch eher eine der spezialisierten Administratorenrollen verwendet werden. Ein Nutzer der Rolle System Administrator besitzt die Rechte für alle Aufgaben die in den Bereich der Systemkonfiguration, der Überwachung des Portalbetriebs oder der Installation gehen. Nutzer dieser Rolle sind für die Einrichtung des Systems verantwortlich, überwachen den allgemeinen Systemablauf oder integrieren die verschiedenen vorhandenen Systeme der Systemlandschaft in die SAP NetWeaver Platform und in das Portal. Die allgemeine Systempflege, wie Aktuali-

406

Portaltechnologie

sierungsverwaltung oder die Lösung technischer Probleme werden ebenfalls vom System Administrator übernommen. Ein Content Administrator besitzt in seiner Rolle alle für die Erstellung und Bearbeitung von Inhalten notwendigen Rechte. So kann er die verschiedenen Inhalte wie iViews, Seiten, Worksets oder Rollen erstellen und diese den anderen Nutzern bereitstellen. Zusätzlich kann ein Content Administrator Informationen in die einzelnen Elemente des Portal-Desktop einfügen. Die Rolle User Administrator besitzt alle Rechte um die Aufgaben der Benutzerverwaltung durchführen zu können. So können neue Nutzer angelegt, vorhandene überarbeitet oder gelöscht und mit Rollen versehen werden. Der User Administrator übernimmt auch die notwendigen Einstellungen zum User Mapping, sobald dieses für das Single Sign-On benötigt wird. Eine vererbte Rolle des User Administrator ist der Delegated User Administrator (vgl. SAP 2008a). Diese Rolle hat zwar die gleichen Aufgaben und Berechtigungen wie der User Administrator, ist allerdings auf einen kleineren Teil der Nutzer beschränkt. Dieses Konzept kann bei größeren Nutzergruppen sinnvoll sein, wenn die Koordination und Administration der einzelnen Nutzer von verschiedenen Administratoren übernommen werden soll. Für normale Nutzer im System gibt es eine Standarduser-Rolle (ControlCenter-User), die aus zwei weiteren vorgenerierten Rollen aufgebaut ist. Hiermit kann er auf allgemeine Inhalte wie einen QuickPoll oder E-Mail-iView zugreifen. Die Standarduser-Rolle enthält ebenfalls die Stammrolle für jeden Nutzer, in der grundlegende Funktionen wie die Portalpersonalisierung enthalten sind. Diese Rolle kann als Vorlage für eigene Rollen dienen. Die Inhalte, die mit der Standarduser-Rolle verfügbar sind, dienen der allgemeinen Arbeit im Portal, ohne auf einen Aufgabenbereich spezialisiert zu sein. So kann ein solcher Nutzer auf seinem Portal-Desktop QuickPolls beantworten oder die über das News-Workset bereitgestellten Informationen einsehen. Er kann seine eigenen Dokumente über eine Universal Worklist verwalten und auch Aufgaben im Collaboration-Umfeld anlegen und bearbeiten. Für die verschiedenen Anwendungsfälle im Portal bestehen weitere Rollenvorlagen, die dem jeweiligen Nutzer die Funktionen bereitstellen. So besteht bei den Elementen Guided Procedures (Workflow-Modellierung), Knowledge Management und Collaboration die Möglichkeit, aus verschiedenen abgestuften Administrator- und Nutzerrollen die benötigte Rolle an den jeweiligen Nutzer zu vergeben. Die Vergabe und Kontrolle der jeweiligen Rolle an den Nutzer wird vom User Administrator übernommen. Werden die Daten der Nutzer aus einem bestehenden System importiert, so können die vorhandenen Portalnutzerdaten erweitert oder überschrieben werden. Die Einteilung der Nutzer in Gruppen ermöglicht die Abbildung von vorhandenen Strukturen und die einfache Kontrolle von Rechten. So werden die Rollen einer Gruppe zugeordnet, woraufhin ein Nutzer seine Berechtigungen über die Gruppe erhält. Wird ein Nutzer in mehreren Gruppen eingeordnet, erhält er alle Berechtigungen dieser Gruppen.

SAP NetWeaver Portal

407

Portal-Desktop und Personalisierung Nach erfolgreicher Anmeldung am Portal sieht der Nutzer den Startbildschirm des Portals, dessen Aufbau immer konstant ist. Dieser Portal-Desktop wird aus mehreren kleinen Elementen des Portals zusammengesetzt, den iViews. Der PortalDesktop setzt sich aus vier verschiedenen Bereichen zusammen, in denen unterschiedliche iViews dargestellt werden: Header Area, Page Title Bar, Navigation Panel und Content Area (siehe Abb. 5.8). SAP NetWeaver Portal Desktop Header Area Portalkopf iView Tools iView Top Level Navigation iView

Page Title Bar iView

Navigation Panel Portal Favorites iView

Content Area Seite Seite

Related Links iView

Portal iView Portal iView

Detailed Navigation iView

Portal iView

Dynamic Navigation iView Drag & Relate Targets iView

Portal iView

Portal iView Portal iView Portal iView

Abb. 5.8 Aufbau des Portal Desktop (vgl. SAP 2008a)

Der obere Bereich wird von der Header Area gestaltet. Innerhalb dieses Bereichs wird die Gestaltung der Portaloberfläche von drei verschiedenen iView-Objekten übernommen. Der Portalkopf stellt den Namen des angemeldeten Nutzers und die allgemeinen Funktionen Hilfe und Abmelden dar. In diesem Bereich können die Corporate Identity gepflegt werden und das Logo sowie eine Grafik des Unternehmens eingesetzt werden. Unterhalb des Portalkopfs ist im Headerbereich der iView Tools angeordnet. Dort befinden sich der Link zum Collaboration Launch Pad und ein Suchfeld so-

408

Portaltechnologie

wie die Option zur erweiterten Suche. Innerhalb dieses iView können Benachrichtigungen an den Nutzer ausgegeben werden. Unterhalb des iView Tools befindet sich der markanteste iView der HeaderArea. Im Top Level Navigation iView sind alle für die Rolle des Nutzers notwendigen Funktionen enthalten. Die Aufteilung der Funktionen erfolgt dabei in zwei Reihen von Tabs. In der oberen Reihe der Tabs finden sich rollenabhängige Funktionsbereiche wie Content-Administration oder Benutzer-Administration. Unterhalb dieser Reihe finden sich die einzelnen Funktionen des jeweils gewählten Tabs der oberen Reihe wie Portal Content, KM-Content oder Identitätsverwaltung. Der nächste Bereich des Portal Desktop wird im Page Title Bar iView erstellt. Innerhalb dieses iView finden sich die Überschrift der aktuell gewählten Funktion sowie weitere Navigationsmöglichkeiten. Mit der Historie können bereits besuchte Seiten wieder aufgerufen werden, die Links Zurück und Vorwärts ermöglichen eine schrittweise Navigation durch die zuletzt besuchten Seiten und Funktionen des Portals. Neben diesen Navigationshilfen befindet sich eine Box, über die mehrere Optionen auf den angezeigten iView durchgeführt werden können. So kann der iView aktualisiert, die Details des iView angezeigt werden oder die Sicht auf diesen iView personalisiert werden. Ebenfalls ist es mit diesen Optionen möglich ein Lesezeichen auf den gewählten iView zu sichern, sowohl im Browser als auch über die Portal Favorites Funktion. Der linke Bereich des Portal Desktop wird durch das Navigation Panel dargestellt, der in mehrere iViews aufgeteilt ist. Je nach Kontext erscheinen einer oder mehrere dieser iViews. Eigene Favoriten können im iView Portal Favorites abgelegt und angezeigt werden. Für die aktuelle Funktion werden über den iView Related Links sinnvolle Links angezeigt, die direkt vom Inhalt abhängigen Links werden über die Detailed Navigation angeboten. Über die iViews der Dynamic Navigation werden Objekte dargestellt, die direkten Zugriff auf den Inhalt der Content Area besitzen und diesen Inhalt entsprechend verändern können. Für Drag & Relate Operationen stehen ebenfalls gesonderte iViews im Navigation Panel zur Verfügung. Der restliche Bereich des Portal Desktop wird von der Content Area definiert. In der Content Area werden die eigentlichen Inhalte der aktuellen Funktion angezeigt. Der Aufbau der Content Area als Seite kann aus mehreren einzelnen iViews bestehen oder aus weiteren Seiten die ihrerseits iViews enthalten. Das Portal bietet dem Nutzer eine Reihe von Funktionen, mit deren Hilfe er die allgemeine Gestaltung und die Darstellung des Portals seinen Wünschen anpassen kann. Jeder Nutzer hat so die Möglichkeit die Arbeitsumgebung des Portals im Rahmen der möglichen Vorgaben anzupassen (vgl. SAP 2008a). Über den Punkt Personalisierung werden die möglichen Optionen bereitgestellt. So kann über das Portal-Motiv ein alternatives Motiv zum aktuellen Portalschema gewählt werden. Dabei gibt es keine Beschränkungen auf die vorgefertigten Layouts, auch eigene können erstellt werden. Dies kann ein weiteres Mittel sein, die Corporate Identity auch im Portal zu verwenden. Die mitgelieferten Motive bieten neben einer Farbvariation auch die Möglichkeit, das Portal mit starkem

SAP NetWeaver Portal

409

Kontrast oder invertiert darzustellen. Diese Portal-Motive können zur Darstellung auf monochromen Bildschirmen oder gesonderten Lesegeräten verwendet werden. Über den Punkt Benutzerprofil sind die über den Nutzer hinterlegten Daten im System einsehbar und mit den entsprechenden Rechten auch änderbar. Dies umfasst neben den Kontaktinformationen auch Angaben wie Vorname und Name. Die Anpassung bzw. Änderung dieser Informationen ist nur dann möglich, wenn die Benutzerverwaltung für die Systemlandschaft über das Portal erfolgt und nicht über eines der angeschlossenen Systeme. Ein mögliches User Mapping kann vom Nutzer ebenfalls über die Personalisierung vorgenommen werden. Über den Menüpunkt können die Nutzerzuordnungen für Remote-Anmeldungen vorgenommen werden, die ein User Mapping benötigen. Der WorkProtect-Modus stellt Optionen bereit, mit denen sich festlegen lässt, wie ungesicherte Eingaben behandelt werden sollen, wenn diese Seite verlassen wird. So kann der Verlust ungesicherter Daten verhindert werden, wenn von einem iView auf einen anderen navigiert wird. Neben der individuellen Gestaltung des Portals durch die Auswahl eines Motivs kann der Nutzer jeden einzelnen iView in seine Individualisierung des Portals einbeziehen. In der rechten oberen Ecke eines iView findet sich ein Optionsfeld, das über das Kontextmenü geöffnet werden kann. Innerhalb dieses Feldes kann ein Nutzer den einzelnen iView neu laden oder ihn aus der aktuellen Seite entfernen. Je nach Typ des angezeigten iView sind noch weitere Optionen möglich. So kann der iView sowohl im Portal, als auch im Browser als Lesezeichen gesetzt werden in dem er in den Favoriten verlinkt wird. Weitere Optionen sind die Funktion, den iView in einem neuen Fenster/Tab des Browsers zu öffnen oder die Möglichkeit sich über die Details des Objekts zu informieren. Hier können die Objekt-ID und der Pfad des Objekts im Portal Content Directory eingesehen werden. Portlets im SAP NetWeaver Portal: iViews Das für die Portlets oder Portaldienste verwendete Konzept innerhalb der SAP NetWeaver Platform wird iView genannt. Innerhalb des Portals integrieren diese iViews die verschiedenen Anwendungen, Inhalte der angebundenen Systeme und Funktionen unter einer einheitlichen zusammenhängenden Oberfläche. Jede Sicht auf das SAP NetWeaver Portal stellt sich aus einem oder mehreren iViews zusammen (vgl. SAP 2008a). Ein iView basiert dabei immer auf einer Portalkomponente, die über eine Nutzeranfrage aufgerufen wird und die gewünschten Ausgaben erzeugt. Ein iView kann auch einen weiteren iView als Template nutzen, wobei dieser Template-iView wiederum auf einer Portalkomponente beruhen kann. Durch diese Vorlagen kann ein neu anzulegender iView aus dem Portal Catalog kopiert und in den eigenen Arbeitsordner eingefügt werden. Dieser iView besitzt eine neue ID und kann angepasst oder überarbeitet werden. Neben der Möglichkeit einen iView auf Basis einer Portalkomponente oder eines anderen iView zu erzeugen, kann ein iView auch auf Basis einer Web Dynpro Anwendung

410

Portaltechnologie

erzeug werden. Der vorgenerierte Inhalt des Portals und damit die vorhandenen Vorlagen für iViews stellen bereits eine Vielzahl von möglichen Anwendungen bereit. Zu den vorgenerierten Templates, die im Folgenden kurz beschrieben werden, gehören unter anderem:      

BEx Web Application Crystal Enterprise Report Portal Activity Report BSP URL XML

Diese iView-Templates ermöglichen die Erstellung eines Portal-Elements für fast alle benötigten Vorgänge. Das BEx Web Application iView-Template ermöglicht die Anzeige von BI-Inhalten im Portal. Zu den benötigten Angaben bei der Erstellung gehören der Typ des hinterlegten Systems und der Query String der Web Application, der mit Parametern versehen werden kann. Das Template für Crystal Enterprise-iViews ermöglicht die Integration von Crystal Reports. Crystal Reports stellen Berichte auf einer weiten Basis von Daten zusammen und erlauben die Erstellung von Berichten auf Basis von Datenbankabfragen. Der Report wird durch die Angabe seiner ID und des eingebundenen Systems integriert. Auch dieser iView kann Parameter übergeben und ermöglicht die Wahl verschiedener Optionen bezüglich der Art der Integration (OnDemand, LastInstance) sowie der Darstellung (HTML, ActiveX, Applet etc.). Für die Integration von SAP NetWeaver Portal eigenen Berichten, wie die Anzahl der aktiven Nutzer, existiert ebenfalls eine iView-Vorlage. Das BSP-iViewTemplate ermöglicht die einfache Integration von Business Server Pages als iView. Die Einbindung kann auch über eine Alias erfolgen, wodurch sich die Angabe des angebundenen Systems und der verschiedenen Namensräume erübrigt. Das URL-iView-Template ermöglicht die Integration einer externen Webseite in das Erscheinungsbild des Portal-Desktop. Dies ermöglicht beispielsweise die Integration der unternehmenseigenen Webseite in das Unternehmensportal, aber auch die Anbindung externer Dienste wie einer Suchmaschine, Wetterberichten oder einem Webportal. Optional kann auch nur ein Teil der Webseite eingebunden werden, wie ein Suchfeld oder eine angezeigte Tabelle. Ähnlich flexible Gestaltungen erlaubt das XML-iView-Template. Mit diesem Template können Dienste und Informationen, die über eine XML-Quelle angeboten werden, in das Portal integriert werden. So lassen sich beispielsweise RSS-Feeds integrieren oder die im XML-Format vorliegenden Daten in HTML ausgeben. Für die Bereiche Knowledge Management und Collaboration existiert ebenfalls eine Reihe von iViewTemplates, mit der die verschiedenen Funktionen (QuickPolls, Subskription, Dokumente, Collaboration Rooms) dieser Bereiche in individueller Form gestaltet und integriert werden können.

SAP NetWeaver Portal

411

Weitere Portalelemente Neben diesen Basis-Elementen des Portals gibt es eine Vielzahl weiterer möglicher Funktionen und Verwendungen. So ermöglichen die Guided Procedures die Modellierung von Arbeitsabläufen und Geschäftsprozessen, die innerhalb des Portals von allen betroffenen Nutzern eingesehen und genutzt werden können. Die Universal Work List (UWL) fasst für jeden Nutzer seine persönlichen Aufgaben zusammen. Dies umfasst die verschiedenen Knowledge Management und Collaboration-Dienste, Abonnements, Benachrichtigungen oder Workflows von denen der Nutzer betroffen ist. Der Persönliche-Dokumente-Ordner erlaubt das Erstellen, Ändern und Löschen eigener Dokumente. Zu diesem Ordner haben andere Nutzer (ausser den Administratoren) keinen Zugang und können keine Einsicht in diese Dokumente nehmen.

5.2.3 Knowledge Management Das Knowledge Management ist eine direkt in das Portal integrierte Komponente der SAP NetWeaver Platform und ermöglicht die Nutzung des kompletten Funktionsumfangs innerhalb des Portals. Ebenso kann über das Portal die Konfiguration der Knowledge Management Komponente vorgenommen werden. So kann die Menge an unstrukturierten Informationen über einen zentralen Zugang genutzt, erfasst und strukturiert werden. Das Knowledge Management des SAP NetWeaver Portals bietet für diese Aufgabe Funktionen wie eine Suche, Verwaltung, Rating, öffentliche Bewertungen, Feedback oder im Verbund mit der Collaboration Diskussionen oder Chats an. Um alle Funktionen des Knowledge Management in vollem Umfang nutzen zu können, ist die Standalone-Engine Search and Classification (TREX) notwendig (vgl. 2008a). Im Folgenden werden einige der elementaren Funktionen des Knowledge Management vorgestellt, die im Zusammenspiel mit dem Portal für die Integration der Informationen und Dokumente sorgen. Integration von Repositories Innerhalb von Unternehmen werden unstrukturierte Informationen häufig in verschiedenen Repositories verteilt abgelegt. Durch das Knowledge Management können diese Repositories über bereits vorkonfigurierte Repository Manager integriert werden und die enthaltenen Informationen über das Portal zugänglich gemacht werden. Die Ablage der gesammelten Informationen kann in einem eigenen zentralen Repository erfolgen. Zusätzlich können über APIs weitere Repository Manager an das Knowledge Management angebunden werden.

412

Portaltechnologie

Navigation in Ordnern Diese Funktion ermöglicht Nutzern des Portals einen geordneten Zugriff auf die aus den verschiedenen Repositories gesammelten Informationen. Die in Ordnern abgelegten Informationen können mit Zugriffskontrollen versehen werden, die über die Ordner bis zu einzelnen Dokumenten reichen. Die Gestaltung der Navigation auf den Ordnern kann rollenabhängig gestaltet werden und zusätzlich von jedem Nutzer individuell angepasst werden. Über offene APIs können die Oberflächen angepasst und erweitert werden. Suche Die enthaltene Suchfunktion wirkt über alle integrierten Repositories und filtert die Ergebnisse je nach Berechtigung des Nutzers. Insbesondere die Suchfunktion profitiert von der Installation der TREX-Engine. Mit Hilfe eines Webcrawlers können die Inhalte von Webseiten in die eigenen Indizes aufgenommen werden und stehen daraufhin über die Suchfunktion im Portal bereit. Taxonomien und Klassifikation Mit Hilfe dieser Funktion kann eine hierarchische Struktur von Kategorien erstellt werden, innerhalb der die Informationen nach verschiedenen Kriterien klassifiziert werden können. Die Klassifikation der Dokumente kann dabei über verschiedene Repositories hinweg erfolgen und wird nach der initialen Konfiguration für neue oder aktualisierte Informationen eigenständig aktualisiert. Durch eine Taxonomie wird die heterogene Informationsmenge in eine einheitliche Struktur transformiert und erlaubt über das Portal eine geordnete Navigation auf den gesamten Informationen. Weitere Funktionen Zusätzlich zu diesen Funktionen werden durch die Knowledge Management Services weitere Möglichkeiten zur Verwaltung, Bearbeitung und dem Austausch der unstrukturierten Informationen gegeben. So können je nach Art der Information öffentliche Bewertungen, Ratings, Kommentare oder Notizen zu diesen hinzugefügt werden. Ebenso können Subskriptionen der verschiedenen Informationen angelegt werden.

SAP NetWeaver Portal

413

Erstellen und Publizieren Durch die Integration ins Portal können diese Informationen von jedem Nutzer mit den entsprechenden Berechtigungen integriert werden. So können Dokumente in die Ordner des Knowledge Management integriert werden oder die Informationen direkt über ein Formular im Webbrowser eingegeben werden. Die vorhandenen Informationen können mit Metadaten versehen werden, um die unstrukturierten Objekte in die Organisation und die Abläufe des Unternehmens besser einfügen zu können.

5.2.4 Kollaboration Der Bereich Collaboration bietet eine Reihe von Möglichkeiten, um die Kommunikation und die Zusammenarbeit im SAP NetWeaver Portal zu optimieren. Durch die im Bereich Collaboration bereitgestellten Tools wird es auch Nutzern ermöglicht in einem Team- oder einer Projektgruppe zu arbeiten, die in großer räumlicher Distanz zueinander stehen und in unterschiedlichen Zeitzonen leben. Wie auch das Knowledge Management kann auf die Funktionen der Collaboration direkt über das Portal zugegriffen werden, ebenso ist eine Konfiguration durch das Portal möglich. Die Unterstützung umfasst dabei sowohl Real-Time fähige Funktionen wie Instant-Messaging oder Application Sharing als auch asynchrone Methoden wie Diskussionsforen oder Aufgabenlisten. Unter der Collaboration werden verschiedene Funktionen im Portal bereitgestellt, die vom Anwender konfigurierbar und in verschiedenen Bereichen des Portals nutzbar sind. So bietet das Collaboration Launch Pad im Portalheader einen zentralen Zugriff auf die Kontakte und die Dienste der Collaboration. Über die Mitgliederliste von einzelnen Collaboration Rooms ist die Nutzung der Funktionen ebenso möglich wie über das Kontextmenü zu Benutzernamen oder über den Benutzerdetail-iView. Das Collaboration Launch Pad Im Portalheader befindet sich der Zugang zum Collaboration Launch Pad. Das Launch Pad erscheint als eigenständiges Fenster und beinhaltet eine Liste mit den Kontakten des Nutzers. Oberhalb der Kontaktliste befinden sich die Menüpunkte Collaboration und Kontakte sowie einen Button zur Aktualisierung der Liste. Ebenfalls im oberen Bereich des Launch Pads findet sich die Möglichkeit, die Verfügbarkeit im System über den Online-Status einzustellen. Die Einstellung Status automatisch ermitteln zeigt anderen Nutzern an, ob ein Nutzer eingeloggt ist oder nicht. Neben verschiedenen Status-Einstellungen wie nicht verfügbar lässt sich diese Option auch ganz deaktivieren indem der Status unterdrückt wird.

414

Portaltechnologie

Über das Menü Collaboration kann auf die verschiedenen CollaborationFunktionen des Portals zugegriffen werden, wie das Versenden einer E-Mail, die Einteilung zu einer Aufgabe oder die Einladung zum Application Sharing. Der Inhalt dieses Menüs kann individuell über die Portal Administration festgelegt werden. Das Menü Kontakte organisiert den Inhalt der Kontaktliste und die Pflege der Kontakte. So können mehrere Kontaktlisten erstellt werden, mit der die Kontakte der Hauptkontaktliste unterteilt werden können. Kontakte können dabei sowohl in der Hauptkontaktliste und in der erstellten Kontaktliste stehen. Über eine Suchfunktion können neue Kontakte hinzugefügt werden. Dabei ist es möglich, direkt die UserID des Nutzers einzugeben oder nach dem entsprechenden Nutzer zu suchen. Über einen gesonderten Punkt können die Mitglieder eines Collaboration Rooms in die eigene Kontaktliste eingefügt werden. Ebenso können Kontakte von den verschiedenen Kontaktlisten entfernt werden. Über einen Klick auf den Namen des Nutzers öffnet sich eine Detailansicht der Benutzerinformationen in einem neuen Fenster. Hier werden die Informationen zu dem Kontakt angezeigt und die möglichen Optionen der Collaboration zu diesem Nutzer angezeigt. Die Funktionen der Collaboration teilen sich auf die folgenden Bereiche auf: Virtuelle Räume Die Virtuellen Räume oder Collaboration Rooms unterstützen Teams bei der Zusammenarbeit im Portal. Unabhängig vom Aufenthaltsort der einzelnen Teammitglieder können hier gemeinsam Dokumente, Informationen und Dienste verwaltet werden. Die Ausgestaltung der Räume wird dabei von vordefinierten Vorlagen übernommen. Die Ausgestaltung eines Collaboration Room ist dabei immer gleich strukturiert. Jedem Collaboration Raum stehen Room Applications (Anwendungen), Room Services (Dienste) und Room Documents (Dokumente) zur Verfügung. Die Vorlagen gestalten die verfügbaren Dienste und Funktionen der Collaboration Rooms je nach Verwendungszweck. Für Besprechungsräume werden Funktionen wie Aufgaben, Raumbearbeitung, die Besprechung inklusive der Verwaltung der Besprechungsmaterialien angeboten. Die Teammitglieder nehmen dabei Rollen wie Protokollführer, Organisator, Verantwortlicher oder Teilnehmer an. Der erweiterte Besprechungsraum unterstützt zusätzlich die parallele Durchführung mehrerer Besprechungen (vgl. 2008a). Die Vorlage des Projektraums dient der Verwaltung der internen Informationen einer Projektgruppe. Die hier angebotenen Funktionen beziehen sich auf Raumbearbeitung, Verwaltung der Mitglieder und Raumbeziehungen, Suche im Raum sowie auf Aufgaben, Dokumente und Links, Kalender und Sitzungen oder die Verwaltung der Projektmitglieder. Dabei wird zwischen Projektgruppenleiter, Projektgruppenmitglied und einem Administrator unterschieden. Eine schwächere Version des Projektraums stellt die Vorlage des Teamraums dar. Die Anzahl der

SAP NetWeaver Portal

415

angebotenen Funktionen ist geringer und dienen der regelmäßigen Arbeit. So sind Dokumente und Links ebenfalls vorhanden wie Aufgaben oder Teammitglieder sowie Suche und Raumbearbeitungsfunktionen. Die Vorlage Präsentationsraum ermöglicht die Publikation von Informationen nach außen über den Collaboration Room. Die Zugangsberechtigung zu den virtuellen Räumen wird über zwei Methoden abgewickelt. Jeder Nutzer der Zugang zu einem Collaboration Room will, muss die Rolle Collaboration besitzen. Zusätzlich lassen sich die Räume noch als öffentlich, als zugangsbeschränkt oder als privat einstufen. Um einen öffentlichen Raum zu betreten genügt die Rolle Collaboration. Zugangsbeschränke Räume werden zwar allen Collaboration-Nutzern angezeigt, können aber nur von den Nutzern betreten werden, die vom Raumverantwortlichen registriert wurden. Private Räume erlauben nur registrierten Nutzern den Zugang und sind auch nur für die Mitglieder dieses Raums zu sehen. Groupware-Integration Die im Unternehmen genutzte Groupware-Lösung kann in das Portal integriert werden. Somit können die bisher eingesetzten E-Mail und Terminplaner auch aus dem Kontext des Portals genutzt werden. Diese Funktion ist allerdings nicht für alle Groupware-Lösungen vorhanden und beschränkt sich in der aktuellen SAP NetWeaver Portal Version (7.0) auf die Groupware-Lösungen Lotus Domino und MS Exchange (vgl. SAP 2008a). Real-time Zusammenarbeit Um die Real-time Kommunikation und Zusammenarbeit eines Teams zu verbessern, werden der Austausch von Instant Messaging Nachrichten sowie die Möglichkeit, gemeinsam mit einer Anwendung zu arbeiten, angeboten. Dieses Application Sharing teilt beispielsweise die Anwendung die auf dem eigenen Rechner liegt mit anderen Nutzern. Um ein Application Sharing durchzuführen muss ein Nutzer seinen Desktop oder seine Anwendung mit den anderen Nutzern teilen. Er lädt dazu die anderen Nutzer zu einer Sitzung ein. Innerhalb dieser Sitzung können die eingeladenen Nutzer die Kontrolle über den Desktop oder die Anwendung anfragen und erteilt oder verweigert bekommen. Zeitgleich können sich diese Nutzer per Instant Messaging verständigen. Diese 1-zu-1 Verbindungen erlauben den direkten Versand von Sofortnachrichten über das Portal. Um eine Instant Message mit dem Portal zu versenden, muss die Funktion für den jeweiligen Kontakt aus der Collaboration ausgewählt werden. Der Vorteil des Instant Messaging gegenüber der E-Mail liegt in der direkten Erreichbarkeit und einer sofortigen Rückmeldung des Gegenübers. Die Integration ins Portal gibt jedem angemeldeten Nutzer Zugang zu diesem Dienst, es gibt keine

416

Portaltechnologie

Unstimmigkeiten über die verwendeten Protokolle oder Abhängigkeiten von externen Instant Messaging Diensten. Asynchrone Zusammenarbeit Um zeitversetzte Zusammenarbeit zu unterstützen, werden in der Portal Collaboration Foren zur Online-Diskussion und die Online-Verwaltung von Aufgaben und Sitzungen angeboten. Diskussionen können sowohl aus einem virtuellen Raum als auch auf einem Dokument oder Ordner basierend (im Knowledge Management) eröffnet werden. Diskussionen in einem Collaboration Room sind in Diskussionsgruppen und in Diskussionen unterteilt. Mit Diskussionsgruppen ist das Sammeln einer Menge von (thematisch verwandten) Diskussionen möglich. In einer Diskussionsgruppe können aber auch eine oder mehrere Diskussionsgruppen vorkommen, so dass ein Forum in einer Baumstruktur für die Diskussionskomponente realisiert wird. Eine einzelne Diskussion ist dann ein Topic dieses Forums, auf den geantwortet werden kann. Bei längeren Diskussionen und umfangreichen Diskussionsgruppen können die Beiträge zur Diskussion vom Nutzer zeitlich gefiltert werden. Neben einer Antwort auf einen Diskussionsbeitrag kann auch eine Benachrichtigung über neue Antworten erstellt werden. Eine Diskussion zu einem Ordner oder einem Dokument ist vergleichbar aufgebaut und bietet die gleichen Möglichkeiten. Die Diskussionsgruppe wird dabei von dem zu diskutierenden Objekt gebildet. Eine Alternative zu Diskussionen bei der Meinungsfindung stellen die Umfragen mit einem Quick Poll dar. Hier werden dem Nutzer eine Frage und eine Reihe von möglichen Antworten gegeben. Die Ergebnisse dieser Umfragen werden graphisch aufbereitet dargestellt und können so eine schnelle Entscheidungsfindung fördern. Die Organisation von Umfragen erfolgt in Kampagnen, über die bestimmt wird, in welchem iView die Umfrage gezeigt wird (vgl. SAP 2008a). So können mehrere Umfragen in einer Kampagne gesammelt werden und nacheinander im selben iView eintreffen. Die Präsentation des Ergebnisses der Umfrage kann direkt nach der Teilnahme eines Nutzers oder nach Abschluss der Umfrage erfolgen. Die direkte Präsentation zeigt dabei den momentanen Umfragestand, das Gesamtergebnis ist erst nach Abschluss verfügbar. Einschränkungen über den teilnehmenden Nutzerkreis können bei der Generierung des Quick Polls getroffen werden, dies ist unter dem Tab Teilnehmer möglich. Im Zusammenspiel mit dem Knowledge Management können auch Dokumente online verwaltet werden und Kommentare, Bewertungen oder sonstiges Feedback online erfasst und dem Team zur Verfügung gestellt werden. Diese Möglichkeit besteht dabei sowohl für Dokumente, als auch für Ordner des Knowledge Management. Im Unterschied zu Notizen, die nur der Nutzer selber einsehen kann, sind Feedback, Review und Bewertungen von allen Nutzern mit Zugriff auf die Information einsehbar. Die Funktionen sind bei dem jeweiligen Objekt über die Detailansicht und den Menüpunkt Collaboration erreichbar. Die Dienste der Collabora-

SAP NetWeaver Portal

417

tion können um weitere Dienste von Fremdherstellersoftware erweitert werden, die in das Portal integriert werden können.

5.2.5 Entwicklung mit dem SAP NetWeaver Portal Im folgenden Abschnitt soll auf einige Möglichkeiten eingegangen werden, mit dem SAP NetWeaver Portal Inhalte zu erzeugen. Neben dem Portal Content Studio wird auch die Visual Composer-Komponente vorgestellt sowie ein kurzer Überblick über weitere Entwicklungsmöglichkeiten gegeben. Die Entwicklungsmöglichkeiten lassen sich anhand der benötigten Kenntnisse der Nutzer und der möglichen Komplexität des zu erstellenden Inhalts aufteilen. Die erste Möglichkeit neben den Business Packages Inhalt im Portal zu erstellen ist das Portal Content Studio. Das Portal Content Studio erlaubt den Nutzern die Erstellung einer Anwendung auf Basis verschiedener iViews. 5.2.5.1

Portal Content Studio

Im folgenden Abschnitt wird auf das Portal Content Studio eingegangen, das die zentrale Entwicklungsumgebung für Inhalte im SAP NetWeaver Portal darstellt. Innerhalb des Portal Content Studios können eigene Inhalte entwickelt und vorhandene Inhalte integriert werden. Das Portal Content Studio findet sich im Menü der Content Administration unter dem Punkt Portal Content. Zur Anwendung muss der Nutzer die Rechte der Content Administrator Rolle besitzen. Die Darstellung des Portal Content Studios beinhaltet auf der linken Seite den Portal Catalog. Innerhalb dieser Ordner Struktur erfolgt die Verwaltung des Portal Content. Hier sind alle Inhalte des Portals abgebildet und können angezeigt, verwaltet und durchsucht werden. Für die Suche steht neben dem Browse Tab ein Suchen Tab zur Verfügung, hier kann nach speziellen Inhalten innerhalb des Portal Catalog gesucht werden. Bei der Suche kann der Objekttyp und die durchsuchte Struktur eingeschränkt werden. Suchkriterien können neben der Objekt-ID auch der Name oder die Beschreibung des Objektes sein. Die Suchergebnisse werden Case-Sensitiv behandelt, bei der Suche muss die Groß- und Kleinschreibung beachtet werden. Unter der Ordnerstruktur und dem Suchfeld befindet sich ein Quick-Info iView. Innerhalb dieses iView werden die Objekt-ID, die Beschreibung des Objekts und die Berechtigungen des Nutzers auf diesem Objekt angezeigt. Die restliche Fläche des Browserfensters wird von der Editing Area eingenommen, in der die einzelnen Objekte bearbeitet werden können. Die einzelnen geöffneten Objekte können über die Tabs getrennt bearbeitet werden, unter Übersicht findet sich die Einleitung und eine kurze Erklärung zum Portal Content Studio. Oberhalb des Portal Content Studio findet sich die Header Area, in der die

418

Portaltechnologie

verschiedenen dauerhaft sichtbaren iViews untergebracht sind, mit denen die grundlegenden Funktionen des Portals bedient werden. Bei dem Bearbeiten einiger Objekte öffnet sich am rechten Rand ein Bereich für den Eigenschaftseditor. In diesem Bereich können die Eigenschaften und Attribute der Portalobjekte angesehen und bearbeitet werden.

Elemente im Portal iView Workset Zugriff

Ordner Seite

Struktur

Rolle Layout

Gestaltung

Abb. 5.9 Beziehung der verschiedenen Elemente im Portal

Die Inhalte des SAP NetWeaver Portals werden aus einem Framework zusammengesetzt. Die verschiedenen Elemente dieses Frameworks werden genutzt um die Inhalte des Portals zu erstellen (siehe Abb. 5.9):      

iView Seite Rolle Workset Layout Ordner

Die Basis der verschiedenen im Portal dargestellten Seiten und Objekte ist der iView. Aus diesen verschiedenen iViews sind die weiteren Objekte des Portals zusammengesetzt, so beruht eine Seite auf einem Layout und den dazugehörigen Inhalten, die auf iViews oder weiteren (gekapselten) Seiten beruhen können. Eine Rolle ist eine Sammlung von Aufgaben, Informationen und Diensten die für eine Gruppe von Nutzern zusammengefasst wird. Durch die Rolle wird festgelegt, welche Möglichkeiten der Nutzer im System hat und wie diese Inhalte und Dienste dem Nutzer dargestellt werden. Rollen können andere Rollen enthalten, womit eine Hierarchie abgebildet werden kann und die Struktur der Aufgaben und

SAP NetWeaver Portal

419

Verantwortungen aus dem Unternehmen im Portal abgebildet werden kann. Auch Spezialisierungen oder Anpassungen der vorgenerierten Rollen können über die Zuordnung zu einer weiteren Rolle realisiert werden. Worksets enthalten eine Sammlung von Aufgaben, Diensten und Informationen, die für eine Rolle benötigt werden. Sie bilden das Arbeitswerkzeug oder Arbeitsset, das für die Erfüllung der Aufgabe einer Rolle (Portal Administration, Knowledge Management, Content Management etc.) benötigt wird. Die Layouts bestimmen die optische Gestaltung der erstellten Seiten. Im vorgenerierten Inhalt des Portals befinden sich mehrere Layout-Templates, die definieren, wie die Inhalte auf der Seite angeordnet werden. Neben den vorgenerierten Layouts können auch eigene Layouts erstellt werden, um die eigenen Anforderungen bezüglich der Gestaltung des Portals umzusetzen. Ordner dienen zur hierarchischen Strukturierung der erstellten Objekte. Innerhalb eines Ordners können weitere Ordner erstellt werden, wobei jeder Ordner die Berechtigungen des übergeordneten Ordners erbt. Jedes Objekt, das mit dem Portal Content Designer erstellt wird, besitzt eine eindeutige Objekt-ID, über die es identifiziert werden kann. Das Erstellen von Inhalten mit dem Portal Content Studio ermöglicht erfahrenen Nutzern eigene interaktive iViews zu generieren. Dabei werden sie von geführten Dialogen und Vorlagen unterstützt. Diese vorgenerierten Inhalte können kopiert und in einen eigenen Ordnerbereich eingefügt werden, um sie als Vorlage für die eigenen Objekte zu verwenden. Grundsätzlich sollten die eigenen Objekte in einem eigenen Ordner abgelegt und unter Berücksichtigung der Namenskonventionen benannt werden. Neben der Möglichkeit ein Objekt zu kopieren und die Kopie in der eigenen Entwicklung zu verwenden, kann auch ein Delta-Link verwendet werden. Dieses Konzept ermöglicht es, einen Link auf das Originalobjekt zu setzen und diese Verlinkung im eigenen Objekt zu nutzen. Diese Methode, vorhandenen Inhalt in die eigenen Entwicklungen einzubeziehen, hat den Vorteil, dass alle Änderungen am Originalobjekt automatisch im eigenen Objekt aktualisiert werden, da die Eigenschaften des Originalobjekts vererbt werden. Gleichzeitig können Änderungen am eigenen Objekt durchgeführt werden, ohne die Eigenschaften des Originalobjekts zu überschreiben (vgl. SAP 2008a). Die Zugriffsteuerung auf die Objekte im Portal Content Studio erfolgt über mehrere Ebenen der Rechtevergabe und über Vererbung. Über das Kontextmenü im Portal Content Studio können die Berechtigungen eines Objekts gesetzt werden. Unter dem Punkt Öffnen Berechtigungen befindet sich der Berechtigungseditor. Ein Objekt erbt seine Berechtigungen automatisch von seinem übergeordneten Element. Sollten manuelle Berechtigungen gewählt werden, so werden diese automatisch vererbten Berechtigungen nicht mehr aktualisiert. Die Administratorberechtigung betrifft Objekte, die im Portal Catalog angelegt, bearbeitet oder gelöscht werden. Der Zugriff auf diese Objekte kann zur Entwicklungszeit erfolgen. Mögliche Abstufungen dieses Zugriffs auf einen reinen Lese-Modus, einen LeseSchreibe-Modus und den Vollzugriff sind möglich. Zusätzlich gibt es den Berechtigungseigner, der neben dem Vollzugriff, die Berechtigungen auf das gewählte

420

Portaltechnologie

Objekt vergeben oder entziehen kann. Die Endanwenderberechtigung erlaubt dem Nutzer die Objekte zur Laufzeit zu sehen. Neben der logischen und inhaltlichen Gestaltung der erstellten Objekte besteht im Portal Content Studio auch die Möglichkeit, die Lage des Objekts in den Navigationsmenüs des Portals zu definieren, über den die Eigenschaften des Objekts als Einstiegspunkt gewählt werden kann. Durch die Wahl dieser Option wird der Name des Objekts in die erste Ebene des Menüs im Portal Desktop integriert. Die diesem Objekt untergeordneten Objekte erscheinen dann als zweite Ebene. Um die Reihenfolge solcher Objekte zu bestimmen kann unter der Option Sortierpriorität ein Wert zwischen 0 und 100 gesetzt werden. Je niedriger der gewählte Wert, desto höher ist die Priorität des gewählten Objekts. Komplexere Inhalte lassen sich mit dem Visual Composer erstellen, er ermöglicht die Erstellung von interaktiven Anwendungen innerhalb des Portals mittels Drag & Drop-Bedienung. 5.2.5.2

SAP NetWeaver Visual Composer

Der Visual Composer ermöglicht dem Nutzer die Entwicklung und Gestaltung von Anwendungen ohne umfangreiche Programmierkenntnisse vorweisen zu müssen. So muss sich der Nutzer des Visual Composers nicht um den generierten Code kümmern oder diesen anpassen um Änderungen in seiner Anwendung zu erhalten. Eine verwendete Technologie der erstellten Anwendungen ist Adobe Flex, ein Entwicklungswerkzeug für komplexe Internetanwendungen (Rich Internet Application). Ebenso ist es möglich die erstellten Anwendungen mit Web Dynpro zu realisieren. Um mit dem Visual Composer Anwendungen entwickeln zu können, benötigt der Nutzer neben einem aktuellen Webbrowser mit installierter SVG- und FlashUnterstützung die Rolle des Visual Composer (VCRole). Die Erstellung mit dem Visual Composer ist losgelöst von der Ebene des Programmiercodes und erfolgt rein auf einer graphischen Ebene. Die notwendige Qualifikation ergibt sich aus dem Verständnis der zu modellierenden Prozesse und ist nicht von einer Programmiersprache abhängig, was die Entwicklung mit dem Visual Composer insbesondere für fortgeschrittene Nutzer ohne Programmiererfahrung erleichtert. Die Entwicklungsumgebung des Visual Composer ist ebenso wie das Portal webbasiert. Durch die Integration des Visual Composer in das Portal und die Anbindung an den Portal Server wird die Entwicklung eigener Inhalte gegenüber externen Entwicklungsframeworks deutlich erleichtert. Innerhalb des Storyboard finden sich alle Tools, die für die Modellierung der Anwendungen erforderlich sind. Der Aufbau des Visual Composers setzt sich aus einer zentralen Modellierungsoberfläche, dem Storyboard, dem Seitenbereich, dem Task Panel und der zentralen Menüleiste, dem Header, zusammen. Das Storyboard ist aufgeteilt in einen Header, das eigentliche Storyboard und einen Footer. Innerhalb des Header ist

SAP NetWeaver Portal

421

eine Navigation durch die verschiedenen Inhalte des Modells möglich, deren Bezeichnung über der Modellierungsfläche erscheint. Ebenso kann im Header der angezeigte Bereich auf die Größe der Modellierungsfläche angepasst oder im eigentlichen Maßstab angezeigt werden. In eigentlichen Storyboard stehen mehrere Tabs zur Verfügung, über die verschiedene Modellierungsebenen erreichbar sind. Die Ebene des Designs realisiert den Zugriff auf die graphische Modellierungsebene. Hier können die gewünschten Inhalte per Drag & Drop integriert und gestaltet werden. Über einen Doppelklick auf ein Objekt kann in dieses „hinein“ navigiert werden um dort die gewünschten Änderungen vornehmen zu können. Der Tab Layout stellt die Gestaltungsoptionen bereit, die innerhalb des Modells verfügbar sind. Innerhalb der einzelnen Bestandteile kann deren Einteilung eingesehen und angepasst werden. Über das Tab Source kann der Sourcecode des erstellten Modells eingesehen werden. Der Footer des Storyboards ermöglicht eine Anpassung der Anzeige. Neben üblichen Funktionen wie Zoom-In und Zoom-Out können auch verschiedene Layer ausgewählt werden oder Kommentare zu dem entstehenden Model eingefügt werden. Rechts vom Storyboard findet sich das Task Panel. In diesem Seitenbereich finden sich sechs Schaltflächen, die zu verschiedenen Funktionsbereichen führen, die je nach Bereich unterschiedliche Optionen im Task Panel bereitstellen. Ist noch kein Modell geöffnet, so erscheint in diesem Bereich die Möglichkeit ein vorhandenes oder ein neues Modell zu öffnen. Der Inhalt der einzelnen Bereiche wird dynamisch und kontextabhängig dargestellt, es werden nur die relevanten und möglichen Operationen für den jeweiligen Modellabschnitt angezeigt. Die einzelnen Bereiche des Task Panels sind:      

Browse Compose Configure Inspect Find Data Deploy

Über den Bereich Browse Model ist eine hierarchische Baumstruktur einsehbar, die das Modell wiedergibt. Auf dieser modifizierbaren Baumstruktur kann durch das Modell navigiert werden, eine Suche ist ebenfalls möglich. Die Compose Model Ebene ermöglicht das Erweitern des vorhandenen Modells. Hier sind alle Objekte vorhanden, die auf dem entsprechenden Modellierungslevel eingefügt werden können. Für die Sicht auf das gesamte Modell sind dies Seiten, Business Packages oder iViews, bei einem einzelnen iView können hier Anzeige- und Navigationselemente gewählt werden. Unter der Ebene Configure Element können die Eigenschaften und Details der verschiedenen Modellelemente angepasst werden. Dies umfasst sowohl die Designumgebung befassenden Daten als auch die Darstellungs- und Nutzungsmöglichkeiten des Objekts. Die Inspect Formulas Ebene stellt Möglichkeiten zur Ansicht und Bearbeitung von Formeln bereit, die

422

Portaltechnologie

an verschiedenen Stellen der Modellkomponenten die Realisierung von Funktionen ermöglichen. Auf der Find Data Services Ebene können Datenquellen aus den angeschlossenen Systemen, die über das Portal bereitgestellt werden, gesucht und in das Modell eingefügt werden. Die letzte Ebene, Deploy to Portal, kontrolliert die Kompilierung und Veröffentlichung des Modells in das Portal. Der Header des Visual Composer beinhaltet die zentrale Menüleiste und Toolbar. Über diese Leiste können alle notwendigen Funktionen direkt erreicht werden. Unter dem Punkt Model finden sich die Funktionen zum Erstellen, Speichern und Verwalten eines Modells. Ebenso kann ein Modell in einem von den Laufzeitumgebungen unabhängigen Format importiert und exportiert oder die momentane Sicht auf die Modellierung ausgedruckt werden. Der Punkt Edit bietet die von Desktop-Anwendungen bekannten Bearbeitungsfunktionen für die Objekte. Neben Copy, Cut und Paste wird auch eine Undo/Redo-Funktion bereitgestellt. Unter dem Punkt Search kann nach einzelnen Elementen des Modells gesucht werden und der Aufbau des Modells eingesehen werden. Ebenso kann über diesen Menüpunkt eine Navigation über die verschiedenen Modellebenen erfolgen. Der Menüpunkt Tools ermöglicht Zugriff auf die Funktionen zum Kompilieren und Veröffentlichen des Modells. Zusätzlich können verschiedene Zusatzfunktionen, wie das Generieren einer Dokumentation oder Image- und Alias-Manager in diesem Menü erreicht werden. Eine Anpassung des Layouts des Visual Composer ist ebenfalls über dieses Menü möglich. Die Integration von BI Inhalten mit Hilfe eines Assistenten sowie ein MDX- und SQL-Editor sind unter dem Punkt BI eingeordnet. Die Punkte Window und Help ermöglichen wie bei klassischen DesktopAnwendungen die Anordnung der verschiedenen offenen Fenster oder einen Zugriff auf verschiedene Anleitungen und Hilfsinformationen. Die graphische Entwicklung mit dem Visual Composer beginnt mit der Erstellung eines Modells, in dem die Abläufe der bestehenden und zu integrierenden Inhalte abgebildet werden. Innerhalb dieses Modells können ein Zugriff auf Systemdaten wie die Nutzerdaten erfolgen oder einfache Bedingungen für die Abläufe definiert werden. Die Phase der Modellierung erfolgt innerhalb des Webbrowsers und benötigt einen eingebundenen SVG-Viewer. Die Anbindung an die verschiedenen Quellen für die Modelle kann über Remote Function Calls (RFC), Web Services oder JDBC erfolgen, sie werden im Modell als Connectors bezeichnet. Gesondert betrachtet werden muss die Anbindung innerhalb der Plattform an SAP NetWeaver Business Intelligence. Die Integration der BI-Inhalte erfolgt über einen gesonderten BI-Connector, eine Query. Mit der Datenbankschnittstelle JDBC oder den OLAP-Schnittstellen ODBO oder XMLA kann ebenfalls ein Zugriff auf die BI Inhalte erfolgen. Das fertige Modell wird in einem eigenen Format, dem GML DOM (Generalized Modeling Language Document Object Model) abgelegt. Ein fertiges Modell dient als Vorlage für die verschiedenen Realisierungs-Technologien und muss für jede gewünschte Laufzeitumgebung kompiliert werden. Die derzeit unterstützten Laufzeitumgebungen sind neben den bereits erwähnten Adobe Flex und Web Dynpro die XGraph Language (XGL). Für die Verwendung

SAP NetWeaver Portal

423

von Adobe Flex als Anwendungsbasis ist eine Anbindung an einen Adobe Flex Server notwendig, die Web Dynpro Anwendungen hingegen lassen sich ohne weitere Schritte innerhalb des Portals nutzen. Für den Anwender der generierten Anwendungen wird bei diesen Lösungen nur der Webbrowser benötigt, bei den mit Adobe Flex erstellten Anwendungen kommt hier noch ein aktuelles Flash-Plug-In hinzu, das von den meisten Nutzern ohnehin verwendet wird. Die Entwicklung mit Adobe Flex ermöglicht die Generierung von Rich Internet Applications (RIA). Diese Webanwendungen bieten dem Nutzer einen an Desktop-Anwendungen orientierten Bedienkomfort und sind von ihrer Ausführungsgeschwindigkeit ebenfalls mit einer eigenständigen Desktopanwendung vergleichbar. Die lauffähigen Anwendungen werden im Shockwave-Format SWF erstellt und sind in den SAP-Umgebungen zertifiziert. Die Visualisierung und Ausführung der SWF-Dateien wird dabei vom Webbrowser übernommen, der ein entsprechendes Plug-In oder die Fähigkeit Flash und Shockwave-Dateien interpretieren zu können besitzen muss. Der Unterschied einer solchen SWF-Anwendung gegenüber einer normalen Webanwendung aus dem Portal Content Studio liegt in der Art der Verarbeitung der behandelten Inhalte in der Anwendung. So ermöglichen die auf Adobe Flex basierenden Anwendungen die Speicherung der Zustände oder die clientseitige Manipulation der Daten ohne direkt auf die Datenbasis und den Server zuzugreifen, was die Anzahl der Anfragen an die Datenbasis verringern kann. Operationen wie das Filtern oder das Navigieren auf den bereits übertragen Daten können ohne ein Reload der Daten vom Server abgewickelt werden, ein neues Laden des Inhalts entfällt bei dieser Art von Anwendung. Diesen Vorteilen stehen allerdings auch einige Nachteile gegenüber, die in der Verwendung mit Flash auftreten können. So ist eine mit Adobe Flex entwickelte Anwendung auf die Verwendung von Flash angewiesen, für Nutzer oder Plattformen die nicht über ein Flash-Plug-In verfügen muss eine Alternative bereitgestellt werden, wenn ihnen der Zugriff auf die Daten ermöglicht werden soll. Für das Sicherheitskonzept des Unternehmen ist zu bedenken, das die in Flash verwendeten Quellcodes durch Dekompilierung offen gelegt werden können, was bei Anwendungen für einen offenen Nutzerkreis ungewünschte Einblicke in die Struktur des Unternehmens gestatten kann. Mit der Verwendung der Adobe Flex Technologie können zudem Desktopähnliche Bedienungen wie ein Drag & Drop der Inhalte und verschiedene graphische Gestaltungen für Tabellen, Charts und die Bedienoberfläche genutzt werden. Innerhalb einer Bibliothek sind viele der Anzeige- und Bedienelemente in Form von Widgets hinterlegt.

424

Portaltechnologie

5.2.5.3

Weitere Entwicklungsmöglichkeiten

Neben dem Portal Content Studio und dem Visual Composer gibt es weitere Möglichkeiten zur Entwicklung einer Portalanwendung, die im Folgenden kurz vorgestellt werden. Über Business Server Pages (BSP) können Web-Anwendungen generiert werden, die in das Portal integriert werden. Bei der Integration gibt es die Möglichkeit die BSP über eine iView-Vorlage (SAP BSP iView) einzubinden. Die BSP können in ihrem bisherigen Framework bleiben, innerhalb des iView werden dann unter anderem der Pfad und der AS ABAP-Server angegeben. Optional kann ein User Mapping zum System des BSP vorgenommen werden. Die Integration von Web Dynpro Anwendungen in das SAP NetWeaver Portal erfolgt ähnlich, die zu integrierende Web Dynpro Anwendung wird über einen iView eingebunden, was eine Einbindung der Quellsysteme in die Platform und das Portal erfordert. Je nach Art des Quellsystems kann ebenfalls ein User Mapping eingerichtet werden. Auch Java-basierte Web Dynpro Anwendungen oder klassische J2EEAnwendungen können in das Portal integriert werden. Die Integration von Javabasierenden Web Dynpro gestaltet sich durch die angebotenen Schnittstellen zum Portal problemlos, auch die Portal-Dienste können aus einer solchen Anwendung heraus genutzt werden. Neben auf Java basierenden Entwicklungsmöglichkeiten, können auch mit .NET entworfene Anwendungen über das Portal aufgerufen werden. Ein solcher .NET-basierter iView wird intern an die Portal Runtime for .NET weitergeleitet und dort der eventuelle Zugriff auf die angeschlossenen Systeme vollzogen und benötigte Daten ermittelt. Die Portal Runtime überträgt dieses Ergebnis dann wieder zurück zum Portal, in dem es in den .Net-iView dargestellt wird.

5.3

Fallstudie C: SAP NetWeaver Portal

Der folgende Abschnitt führt in die verschiedenen Anwendungsmöglichkeiten des SAP NetWeaver Portal ein. In Form einer illustrierten Schritt-für-Schritt Anleitung wird dem Nutzer der praktische Umgang mit dem Portal näher gebracht. Aufbauend auf die bereits absolvierten Fallstudien wird anhand der erstellten Daten die Einbindung und Präsentation von Informationen in das Portal erklärt. Die einzelnen Schritte und zu befolgenden Anweisungen werden durch detailierte Screenshots illustrativ unterstützt. Die Aufteilung der Fallstudie in mehrere Teile ermöglicht deren getrennte Bearbeitung.

Fallstudie C: SAP NetWeaver Portal

425

Einleitung Der erste Teil der Fallstudie richtet sich insbesondere an Nutzer, die bisher noch keinen Umgang mit dem SAP NetWeaver Portal hatten und begleitet Sie vom Login bis zum Übergang zum Portal Content Studio. Neben dem Aufbau des Portaldesktops werden das Collaboration Launch Pad als zentrales Mittel zur Kommunikation und die Portalfavoriten als Navigations- und Strukturierungshilfe behandelt. Der zweite Teil der Fallstudie führt den Benutzer in das Portal Content Studio ein und verdeutlicht ihm die Generierung von Inhalten in das SAP NetWeaver Portal. Aufbauend auf den Ergebnissen der bisherigen Fallstudien kann das Beispielszenario fortgesetzt werden sowie die dort erzeugten Inhalte im Portal genutzt und weiter verarbeitet werden. Neben der Integration dieser Inhalte wird auch die Integration externer Inhalte in das Portal praktisch durchgeführt. Im letzten Teil der Fallstudie werden dem Nutzer die Möglichkeiten zur Nutzung und Analyse der integrierten Informationen dargestellt. Nach Abschluss der Fallstudie ist der Nutzer in der Lage eigenständig im Portal zu navigieren, Inhalte zu generieren und diese Ergebnisse zu präsentieren. Vorrausetzung für die Bearbeitung dieses Abschnitts sind für einen Teil der Aufgaben die erfolgreiche Bewältigung der Fallstudien zum SAP BI Data Warehousing. Sollte diese Fallstudie noch nicht bearbeitet worden sein, so sollten zumindest vergleichbare Objekte verfügbar sein, die in das Portal integriert werden können. Der Nutzer muss im Portal die entsprechenden Berechtigungen und Rollen besitzen, um das Portal Content Studio nutzen zu können. Der Zugang zum Portal erfolgt über einen aktuellen Webbrowser. Da einige der administrativen Funktionen teilweise nur unter dem Microsoft Internet Explorer zugänglich sind und viele der erforderlichen Funktionen über das Kontextmenü des Browsers aufgerufen werden, sollte dieser Browser verwendet werden. Zusätzlich sollten PopUp-Blocker deaktiviert oder zumindest Popups für den Adressraum des Portals erlaubt werden, da viele elementare Funktionen zusätzliche Fenster öffnen. Ebenfalls werden offene Sessions im Portal durch PopUps geschlossen. Sollte ein solcher Abmeldevorgang unterbrochen werden, so ist mit längeren Wartezeiten zu rechnen. Beenden sie daher jede Sitzung im Portal, indem sie sich korrekt Abmelden und nicht nur das Browserfenster des Portals schließen. Die Namenskonvention für erstellte Objekte in den verwendeten Beispielen nutzt das Präfix UO_ für die Objekte und eine Nummerierung _XX als Suffix. Die Nummerierung stellt dabei die Gruppenzugehörigkeit fest. Wurde in den vorherigen Fallstudien beispielsweise das Suffix _07 genutzt, so ist es auch innerhalb dieses Abschnitts zu verwenden. Die jeweiligen Schaltflächen, Eingabefelder oder Menüpunkte, die gewählt oder gedrückt werden müssen, werden in kursiver Schrift dargestellt. Einzugebende Informationen und Daten werden in fettgedruckter Schrift dargestellt.

426

Portaltechnologie

Beispielszenario Auf Grund der positiven Erfahrungen mit den SAP BI Komponente überlegt die 4INSTANCE AG, zusätzlich zur Einführung des SAP BI Systems weitere Komponenten aus der Platform zu verwenden. Insbesondere die Portal Komponente aus der SAP NetWeaver Platform soll verwendet werden. Um die verschiedenen Vorteile eines zentralen Unternehmensportals zu erproben und die Möglichkeiten einer Portalsoftware kennenzulernen, soll die Informationssystemabteilung sich mit einigen zentralen Funktionen des SAP NetWeaver Portal befassen und die Möglichkeiten dieser Portal-Lösung erproben. Da durch die Plattform das SAP NetWeaver Portal mit den weiteren Komponenten verbunden ist ergeben sich verschiedene Vorteile für die Verwendung eines solchen Portals. Das Management möchte insbesondere die Integration und Präsentation von Inhalten der angebundenen und externen Systeme im Portal erprobt wissen, ferner sollen die elementaren Möglichkeiten zur Kommunikation und Zusammenarbeit erprobt werden. Zusätzlich zu den bereits erstellten Prototypen in den vorherigen Fallstudien, sollen sie nun neben einer Einführung in die Portalsoftware auch die Integration der Ergebnisse der vorherigen Fallstudien in das Portal umsetzen. Die Unternehmensführung ist an einer solchen Präsentation der Resultate interessiert, da die Ergebnisse der Werbekampagne somit innerhalb des gesamten Unternehmens genutzt werden können, ohne speziell Zugriff auf das SAP NetWeaver BI Data Warehousing zu benötigen. Zusätzlich soll überprüft werden, ob auch direkt aus dem Portal eine Analyse und Planung auf den Ergebnissen möglich ist und eine Präsentation und Weitergabe dieser Ergebnisse aus dem Umfeld des Portals möglich ist. Neben der Integration der internen Informationen soll auch eine Integration externer Informationen überprüft werden, da die 4INSTANCE AG das eigene Intranet durch das Portal ersetzen möchte. So sollen den Mitarbeitern zusätzliche externe Dienste bereitgestellt werden, die durch die vorhandenen Systeme nicht abgedeckt werden können. Zusätzlich möchte das Management eine Übersicht erhalten, in welchem Rahmen die neu angebotenen Möglichkeiten des Portals genutzt werden und welche Form der Umsetzung am häufigsten genutzt wird, um die zukünftige Entwicklung in diesen Bereichen zu verstärken.

5.3.1 Teil I - Login und Bedienung SAP NetWeaver Portal In diesem Teil der Fallstudie werden Sie die ersten Bedienschritte innerhalb des Portals kennen lernen und es werden Ihnen die wichtigsten Komponenten des Portal-Desktops vorgestellt, die in den folgenden Aufgaben benötigt werden.

Fallstudie C: SAP NetWeaver Portal

5.3.1.1

427

Anmelden am Portal

Um das Portal aufzurufen; geben Sie die Ihnen vorgegebene Adresse des Portals in ihrem Webbrowser ein. Die Adresse sollte in folgender Form vorliegen: http(s)://:<port>/irj Eine gültige Adresse ist beispielsweise: https://www.meinportal.url:50100/irj. Nun erscheint der Startbildschirm des Portals. Geben Sie hier bitte ihre Benutzerkennung sowie ihr Kennwort für das Portal ein (1) und drücken auf Anmelden (2).

Abb. 5.10 Startbildschirm SAP NetWeaver Portal

Ist dies ihre erste Anmeldung im Portal, so werden Sie aufgefordert ein neues Kennwort einzugeben. Achten Sie bei der Eingabe auf die Formalbedingungen, die zu erfüllen sind. So enthält ein Kennwort normalerweise mindestens eine Zahl und besteht aus wenigstens sechs Zeichen. Nach der Anmeldung werden sie auf den Portal Desktop weitergeleitet. Dieser Aufbau enthält die verschiedenen Elemente des Portals, wie die Portalfavoriten, die zentrale Menüleiste sowie der jeweils dargestellte Portal Content.

428

Portaltechnologie

Sie befinden sich nun auf ihrem persönlichen Portal-Desktop.

Abb. 5.11 Portal-Desktop mit Sicht des Content Administrator

Da ihr Nutzer die Berechtigung zum Content Administrator besitzt, sehen Sie als erstes das Portal Content Studio. Sollten während der Fallstudie Fragen zur allgemeinen Bedienung des Portals auftreten, so finden Sie unter den Link Hilfe (1) eine allgemeine Dokumentation über das Portal, in der erste Fragen beantwortet werden. Unter (2) finden sie neben dem Zugang zum Collaboration Launch Pad ein Suchfeld, über das sie die Inhalte des Portals durchsuchen können. Auf der linken Seite sehen Sie ihre noch leeren Portalfavoriten (3), direkt daneben den Portal Content Catalog (4). Falls Sie im Verlauf der Fallstudie eine Unterbrechung einlegen möchten, so melden Sie sich vom Portal ab. Dies können Sie bei (1) über den Link Abmelden. Um die Ergebnisse der aktuellen Arbeit zu sichern und ihre Session korrekt zu beenden, sollte das Portal immer zuerst verlassen werden bevor der Browser geschlossen wird. Wird eine Session nicht abgemeldet, kann es zu längeren Wartezeiten kommen bevor die zuletzt bearbeiteten Objekte im Portal erneut genutzt werden können. Melden Sie sich vom Portal ab und mit ihrem neu erstellten Passwort wieder an. Die Nutzung des Portals wird von verschiedenen Popups unterstützt, Sie müssen die Verwendung von Popups zulassen, um alle Funktionen des Portals nutzen zu können. Das erste Popup sollte Ihnen bereits beim ersten Abmelden begegnet sein.

Fallstudie C: SAP NetWeaver Portal

5.3.1.2

429

Collaboration Launch Pad

Unter (2) finden Sie die wichtigsten Collaboration-Funktionen. Klicken Sie auf Collaboration. Nun erscheint in einem Popup das Collaboration Launch Pad.

Abb. 5.12 Collaboration Launch Pad

Klicken Sie nun auf Kontakte hinzufügen (1), um den ersten Kontakt in ihre Kontaktliste einzufügen. Im folgenden Fenster können Sie direkt die Benutzerkennung des Kontakts eingeben, wenn Sie Ihnen bekannt ist. Über Auswählen können Sie nach Nutzern des Systems suchen, wenn Ihnen nur ein Teil des Namens oder die Benutzerkennung nicht bekannt ist.

430

Portaltechnologie

Suchen Sie nun einige Kontakte. Sie können sowohl über Auswählen (1) als auch über die direkte Eingabe der Benutzerkennung Kontakte hinzufügen.

Abb. 5.13 Hinzufügen von Kontakten im Portal

Haben Sie die gewünschten Kontakte über die Funktion Auswählen gefunden oder die Benutzerkennungen eingegeben, klicken Sie auf Hinzufügen (2). Sollten Sie bei der direkten Eingabe der Benutzerkennung einen Fehler gemacht haben, können Sie ihn noch korrigieren. Falls Sie keine Benutzerkennungen kennen oder keinen Benutzer im System finden können Sie zu Testzwecken auch ihren eigenen Nutzer hinzufügen.

Fallstudie C: SAP NetWeaver Portal

431

Nun finden Sie in ihrem Collaboration Launch Pad die ersten Kontakte.

Abb. 5.14 Collaboration Launch Pad mit Kontakten

Mit diesen Kontakten können Sie nun innerhalb des Portals kommunizieren und ihnen verschiedene Collaboration-Aufgaben zuordnen. Über Kontakte können Sie weitere Kontakte hinzufügen, die vorhandenen Kontakte in neue Listen sortieren und selbsterstellte Listen und Kontakte aus dem Collaboration Launch Pad entfernen. Über den Punkt Collaboration können Sie verfügbaren CollaborationFunktionen bei den gewählten Kontakten nutzen.

432

Portaltechnologie

Klicken Sie auf einen beliebigen Nutzernamen, um sich die Details des Nutzers anzusehen.

Abb. 5.15 Profil eines Nutzers

Die verschiedenen Collaboration-Funktionen stehen Ihnen oberhalb der allgemeinen Daten zur Verfügung. So können Sie hier beispielsweise dem Nutzer eine EMail über das Portal senden oder ihn einer neuen Aufgabe zuordnen.

Fallstudie C: SAP NetWeaver Portal

433

Der E-Mail-Versand ermöglicht Ihnen Nachrichten und Dateien an ihre Kontakte zu versenden.

Abb. 5.16 Versenden einer E-Mail über das Portal

Klicken Sie auf E-Mail senden… um einen Ihrer Kontakte eine E-Mail zu senden. Probieren Sie dabei die verschiedenen Formatierungsmöglichkeiten in dieser EMail aus. Schließen Sie das Popup, nachdem Sie die E-Mail versendet haben.

434

Portaltechnologie

Sie können einem Ihrer Kontakte über die Funktion CommandNewTask / Neue Aufgabe zuweisen eine Aufgabe zuweisen. Klicken Sie auf diese Funktion und weisen Sie dem gewählten Kontakt eine beispielhafte Aufgabe zu.

Abb. 5.17 Zuweisen einer Aufgabe über das Collaboration Launch Pad

Schließen Sie danach das Popup. Schließen Sie ebenfalls die Popups des offenen Profils und des Collaboration Launch Pads.

Fallstudie C: SAP NetWeaver Portal

5.3.1.3

435

Portalfavoriten

Über die Portalfavoriten können Sie schnell auf häufig genutzte Portalinhalte zugreifen. Um die Favoriten übersichtlich zu verwalten, werden Sie nun einen Ordner in den Favoriten erstellen. Wählen Sie dazu über das Optionsfeld (1) im Portalfavoritenbereich den Punkt Einträge ordnen (2).

Abb. 5.18 Portal Content Studio iView

Im folgenden PopUp können die Einträge hierarchisch sortiert werden. Da bisher noch keine Einträge vorhanden sind, beginnen wir mit einer Ordnerstruktur für die Favoriten.

436

Portaltechnologie

Klicken Sie nun auf den kleinen Pfeil am Hauptordner Favorites/Favoriten (1). Wählen Sie in diesem Menü zuerst den Punkt Neu (2) und im Untermenü den Punkt Ordner… (3).

Abb. 5.19 Verwalten der Portalfavoriten (a)

Sie können diesen Punkt auch über das Kontextmenü (rechte Maustaste) erreichen, wenn ihr Browser die Verwendung des Kontextmenüs durch das Portal erlaubt.

Fallstudie C: SAP NetWeaver Portal

437

Im folgenden Dialog geben Sie einen Namen und eine kurze Beschreibung für ihren Ordner an. Wählen Sie als Namen (1) Portaleinführung und fügen Sie einen kurzen beschreibenden Text (2) hinzu.

Abb. 5.20 Verwalten der Portalfavoriten (b)

Klicken Sie dann auf Sichern (3). Sie gelangen wieder in die Übersicht der Portalfavoriten. Fügen Sie zwei weitere Ordner in die Struktur der Portalfavoriten hinzu: Integrierte Inhalte und Analyse. Sichern Sie jeweils diese Ordner und vergessen Sie nicht, einen kurzen deskriptiven Text hinzuzufügen. Beenden Sie die Bearbeitung der Favoriten, in dem Sie die Schaltfläche Schließen drücken.

438

Portaltechnologie

Nun sollte innerhalb ihrer Portalfavoriten folgende Struktur zu sehen sein:

Abb. 5.21 Portalfavoriten mit erstellter Ordnerstruktur

Diese Ordner (1) werden im Verlauf der Fallstudie wiederverwendet und mit Inhalten gefüllt werden. Sie können die Verwaltung einzelner Einträge in vergleichbarer Weise durchführen. Innerhalb des Portals können die Verknüpfungen der Inhalte über die Optionen in den einzelnen iViews (2) gesteuert werden.

Fallstudie C: SAP NetWeaver Portal

439

Nun fügen Sie das Portal Content Studio als Favorit in den Ordner Portaleinführung ein. Dazu wählen Sie innerhalb der Optionen (1) im Portal Content Studio iView den Punkt Zu Portalfavoriten hinzufügen (2).

Abb.5.22 Optionen des Portal Content Studio iView

Klicken Sie auf Zu Portalfavoriten hinzufügen (2). Nun taucht der Punkt Portal Content direkt in den Portalfavoriten auf. Um diesen Eintrag in den Ordner Portaleinführung zu verschieben, öffnen Sie erneut den Punkt Einträge ordnen im Optionsmenü (3) der Portalfavoriten.

440

Portaltechnologie

Nun sehen Sie neben den von Ihnen erstellten Ordnern den Portal-Content iView des Portal Content Studio. Die Optionen zum Verschieben des Eintrags finden sich über das Kontextmenü. Alternativ können Sie dieses Menü auch über das kleine Dreieck bei Portal-Content erreichen.

Abb. 5.23 Verschieben eines Eintrags in den Portalfavoriten (a)

Öffnen Sie mit einem Rechtsklick das Kontextmenü des Eintrags Portal-Content (1). Klicken Sie nun auf Verschieben (2).

Fallstudie C: SAP NetWeaver Portal

441

Im folgenden Dialog wählen Sie den Ordner in den das Lesezeichen PortalContent verschoben werden soll. In diesem Falle wählen Sie den Ordner Portaleinführung (1).

Abb. 5.24 Verschieben eines Eintrags in den Portalfavoriten (b)

Klicken Sie auf den Ordner Portaleinführung (1) und klicken Sie dann auf OK (2).

442

Portaltechnologie

Unterhalb der Symbole sehen Sie den Pfad (1) in den das gewählte Lesezeichen verschoben werden soll. Überprüfen Sie ob dieser Pfad korrekt ist. Der Pfad sollte wie folgt lauten: Root > userhome > NUTZERKENNUNG >Favorites > Portaleinführung

Abb. 5.25 Verschieben eines Eintrags in den Portalfavoriten (c)

Bestätigen Sie den Dialog mit OK (2) und beenden Sie die Bearbeitung der Favoriten im folgenden Fenster über die Schaltfläche Schließen. Der Eintrag PortalContent sollte nun innerhalb des Ordners Portaleinführung zu finden sein.

Fallstudie C: SAP NetWeaver Portal

5.3.1.4

443

Zusammenfassung

Nach diesem Teil der Fallstudie verfügen Sie über die Fähigkeit die grundlegenden Funktionen des Portals zu nutzen. Sie sind nun in der Lage eigenständig ihre Portalfavoriten zu verwalten, neue Einträge hinzuzufügen und diese zu sortieren. Ein Entfernen der Einträge erfolgt auf vergleichbare Weise, wie der Eintrag im Kontextmenü erahnen lässt. Die Ergebnisse der Arbeit mit dem Portal Content Studio lässt sich über die Favoriten deutlich einfacher auffinden, als dies über den Portal Content Catalog möglich wär, der alle vorhandenen Inhalte umfasst. Zudem können über die Favoriten verschiedene Sichten auf ein Objekt abgelegt werden. Sie sind nun in der Lage, innerhalb des Portals Kontakte in ihrem Collaboration Launch Pad sammeln und diesen Kontakten Aufgaben zuweisen, sowie Nachrichten und Dateien zusenden. Sie können diese Funktionen nun während der Fallstudie zur Kommunikation und Aufgabenplanung verwenden.

444

Portaltechnologie

5.3.2 Teil II - Arbeiten mit dem Portal Content Studio Die folgenden Aufgaben werden Ihnen die Arbeit mit dem Portal Content Studio näher bringen. Sie werden lernen die Inhalte in das Portal zu integrieren, die Sie in den vorherigen Fallstudien erzeugt haben. Da die Portalfavoriten momentan nicht benötigt werden, können Sie über den Pfeil in der rechten oberen Ecke minimiert werden, was die angezeigte Fläche für das Portal Content Studio vergrößert. Das Portal Content Studio findet sich unter dem Tab Content Administration und dem Unterpunkt Portal-Content.

Abb. 5.26 Übersicht des Portal Content Studio mit Portal Content Catalog

Die erste Aufgabe wird das Erstellen eines eigenen Ordners im Portal-Content sein. Innerhalb dieses Ordners werden dann unter anderem die zu erstellenden iViews und Seiten abgelegt werden. Navigieren Sie auf das Tab Content-Administration (1) und den Unterpunkt Portal-Content (2) um zum Portal Content Studio zu gelangen.

Fallstudie C: SAP NetWeaver Portal

5.3.2.1

445

Erstellen eines Ordners im Portal Content Catalog

Öffnen Sie den Ordner Portal-Content und navigieren Sie zu dem Ordner, innerhalb dessen Sie ihren eigenen Ordner erstellen dürfen. Auf der Grafik wird der Ordner UO_Portalordner (1)verwendet.

Abb. 5.27 Navigation im Portal Content Catalog

Wählen Sie diesen Ordner per Linksklick. In der Quick-Info (2) unterhalb des Portal-Content Ordners sehen Sie zusätzliche Informationen zu diesem Ordner. Dieser Ordner ist die Basis für die zu erstellenden Objekte. Um die Bearbeitung der Fallstudie mehreren Nutzern oder Gruppen gleichzeitig zu ermöglichen, wird ein eigener Ordner innerhalb dieses Ordners angelegt.

446

Portaltechnologie

Öffnen Sie zum Erstellen eines eigenen Ordners das Kontextmenü des Referenzordners (1; hier der Ordner UO_Portalordner). Nun sehen Sie die möglichen Optionen, die Sie auf diesem Ordner besitzen.

Abb. 5.28 Kontextmenü eines Objektes im Portal Content Catalog

Wählen Sie aus dem Kontextmenü den Punkt Neu (2) und aus dem sich öffnenden Untermenü den Punkt Ordner (3). Nun öffnet sich im Portal Content Studio ein Assistent, der Sie bei der Erstellung des Ordners unterstützt.

Fallstudie C: SAP NetWeaver Portal

447

Im ersten Schritt geben Sie die allgemeinen Eigenschaften für ihren Ordner an. Da alle von nun an erstellten Objekte öffentlich und somit im gesamten System sichtbar sind, denken Sie bei der Benennung der Objekte an eventuelle Prä- und Suffixvorschriften. Es sollten die bisher verwendeten Vorgaben aus den ersten Fallstudien weiterverwendet werden.

Abb. 5.29 Erstellen eines Ordners im Portal Content Studio (a)

Wählen Sie als Ordnernamen (1)und als Ordner-ID (2) jeweils die Bezeichnung UO_Gruppe_XX, wobei XX ihre Gruppennummer darstellt. Geben Sie einen kurzen beschreibenden Text (3) ein und setzen Sie die Originalsprache auf Deutsch (4), falls hier eine andere Sprache vorgewählt sein sollte. Klicken Sie nun auf Fertig Stellen (5).

448

Portaltechnologie

Nun haben Sie die Wahl, ob Sie das Objekt weiter bearbeiten wollen, ein neues Objekt mit dem Assistenten anlegen wollen oder den Assistenten beenden wollen. Da momentan keine weiteren Ordner erstellt werden sollen und der vorhandene Ordner noch nicht geändert werden muss, wählen Sie den Punkt Assistent schließen (1) und klicken auf OK (2).

Abb. 5.30 Erstellen eines Ordners im Portal Content Studio (b)

Sie gelangen wieder zur Portal Content Studio Übersicht. In dem Ordner UO_Portalordner sind nun ein oder mehrere neue Ordner zu sehen, wählen Sie dort ihren Ordner mit der Bezeichnung UO_Gruppe_XX. Wählen Sie diesen Ordner nun aus, indem Sie mit der linken Maustaste auf ihn klicken. Im Quick-Info Feld sehen Sie nun die ID ihres Ordners, die gewählte Beschreibung, den Namen sowie die Berechtigungen die Sie auf diesem Objekte haben. Inhalte im Portal Content Studio erstellen Sie nur innerhalb dieses Ordners.

Fallstudie C: SAP NetWeaver Portal

5.3.2.2

449

Erstellen eines iView

Nun erstellen Sie einen ersten iView innerhalb dieses Ordners. Dieser iView ermöglicht die Darstellung der Inhalte, die in den vorherigen Fallstudien erstellt wurden.

Abb. 5.31 Erstellen eines iView im Portal Content Studio (a)

Wählen Sie dazu im Kontextmenü ihres Ordners (1) den Punkt Neu (2) und in dem Untermenü den Punkt iView (3), um einen neuen iView zu erstellen. Die folgenden Schritte werden vom iView-Assistenten begleitet.

450

Portaltechnologie

Der erste iView der erstellt wird, greift auf die Produkt-Umsatz ist XX Query zu, die in der vorherigen Fallstudie erstellt wurde. Dafür benötigen Sie einen iView, der die Inhalte einer BEx Web Application darstellen und in das Portal integrieren kann.

Abb. 5.32 Erstellen eines iView im Portal Content Studio (b)

Wählen Sie im ersten Schritt des iView-Assistenten als Grundlage des zu erstellenden iView den Punkt iView-Vorlage (1) und klicken Sie auf Weiter (2).

Fallstudie C: SAP NetWeaver Portal

451

Nun erhalten Sie eine Übersicht über die verfügbaren Vorlagen des Systems. Sie benötigen eine Vorlage zur Integration der Informationen einer BEx Web Application.

Abb. 5.33 Erstellen eines iView im Portal Content Studio (c)

Wählen Sie die Vorlage BEx Web Application iView (1) aus und klicken Sie auf Weiter (2). Sind nur wenige oder gar keine Vorlagen vorhanden, klicken Sie auf Aktualisieren (3) um die Übersicht auf die Vorlagen neu einzulesen.

452

Portaltechnologie

Nun geben Sie die allgemeinen Eigenschaften ihres iView an.

Abb. 5.34 Erstellen eines iView im Portal Content Studio (d)

Wählen Sie für die Namen (1) und die ID (2) des iView die Bezeichnung UO_iView01_Gruppe_XX und geben Sie einen kurzen beschreibenden Text (3) an. Setzen Sie die Originalsprache auf Deutsch (4). Klicken Sie dann auf Weiter (5).

Fallstudie C: SAP NetWeaver Portal

453

Nun wählen Sie die Version des Data Warehouse, mit dem die BEx Web Application erstellt wurde.

Abb. 5.35 Erstellen eines iView im Portal Content Studio (e)

Für die Fallstudie wurde SAP NetWeaver in der Version 7.0 verwendet, daher wählen Sie SAP NetWeaver BI (1). Klicken Sie auf Weiter (2). Wenn Sie eine BEx Web Application integrieren wollen, die mit dem SAP Business Information Warehouse erstellt wurde, wählen Sie den Punkt SAP BW 2.x/3.x.

454

Portaltechnologie

Nun geben Sie den technischen Namen ihrer Web Application an. Sie können diese Query mit Parametern versehen.

Abb. 5.36 Erstellen eines iView im Portal Content Studio (f)

Für den Query-String (1) geben Sie QUERY=QUERY1_XX ein, um die erste erstellte Query zu integrieren. Das Feld Anwendungsparameter lassen Sie frei. Klicken Sie auf Weiter (2).

Fallstudie C: SAP NetWeaver Portal

455

Nun sehen Sie eine Zusammenfassung der von Ihnen vorgenommenen Einstellungen.

Abb. 5.37 Erstellen eines iView im Portal Content Studio (g)

Kontrollieren Sie ihre Eingaben (1). Der Name und die ID des iView sollten ihre Gruppennummer enthalten, ebenso die eingebundene Web Application. Sind alle Eingaben korrekt, können Sie mit Fertig stellen (2) die Bearbeitung des iView schließen. Innerhalb des Ordners UO_Gruppe_XX sollte nun der iView UO_iView01_Gruppe_XX vorhanden sein. Erstellen Sie auf diese Weise einen weiteren iView für die zweite Query, die Sie erstellt haben. Nennen Sie diesen iView UO_iView02_Gruppe_XX. Der technische Name der zu integrierenden Query lautet QUERY2_XX.

456

Portaltechnologie

Über das Kontextmenü können Sie mit dem Punkt Vorschau einen ersten Blick auf die integrierten Informationen werfen. Zu einem späteren Zeitpunkt wird auf die Art der Darstellung genauer eingegangen.

Abb. 5.38 Vorschau auf einen BEx Web Application iView

Die Vorschau wird in einem Popup geöffnet. Die bereits bekannten Operationen auf der Web Application können auch aus dem Portal heraus ausgeführt werden. In einem späterem Teil der Fallstudie werden die Analysemöglichkeiten im Portal genauer vorgestellt. Schließen Sie die Vorschau um fortzufahren.

Fallstudie C: SAP NetWeaver Portal

5.3.2.3

457

Erstellung einer Seite

Nun befinden sich in dem Ordner UO_Gruppe_XX zwei Einträge für die erstellten iViews. Über diese iViews können die jeweiligen Informationen der Querys dargestellt werden. Um die Anzeige dieser Querys strukturiert zu gestalten, werden Sie nun eine Seite erstellen, innerhalb derer die verschiedenen iViews angezeigt werden können.

Abb. 5.39 Erstellen einer Seite über das Kontextmenü

Wählen Sie dazu aus dem Kontextmenü des Ordners UO_Gruppe_XX (1) den Punkt Neu (2) und im Untermenü den Punkt Seite (3). Die Erstellung einer Seite wird ebenfalls von einem Assistenten begleitet.

458

Portaltechnologie

Der erste Schritt zur Erstellung einer Seite besteht aus der Angabe der allgemeinen Eigenschaften der Seite.

Abb. 5.40 Allgemeine Eigenschaften einer Seite

Geben Sie für den Seiten Namen (1) und die Seiten ID (2) den Wert UO_Seite01_Gruppe_XX ein. Setzen Sie die Originalsprache auf Deutsch (3) falls diese einen anderen Wert trägt und geben Sie einen kurzen beschreibenden Text in das Feld Beschreibung (4) ein. Klicken Sie auf Weiter (5).

Fallstudie C: SAP NetWeaver Portal

459

Nun ist die Vorlage zu wählen, auf der die neue Seite aufbauen soll. In diesem Fall genügt die Standard-Seitenvorlage bzw. das Default Page Template.

Abb. 5.41 Wahl der Seitenvorlage

Wählen Sie als Vorlage den Punkt Standard-Seitenvorlage (1) und klicken Sie auf Weiter (2). Sollte bei den Vorlagen die Standard-Seitenvorlage nicht zu sehen sein, klicken Sie auf Aktualisieren (3) um die Liste der Vorlagen neu einzulesen.

460

Portaltechnologie

Der dritte Schritt der Seitenerstellung bestimmt das Layout der Seite. Grundsätzlich liegt eine Reihe von verfügbaren Layouts im Portal, aus denen gewählt werden kann.

Abb. 5.42 Wahl des Seitenlayouts

Wählen Sie aus den verfügbaren Layouts (1) jeweils die Vorgaben 1 Spalte (ganze Breite) und 2 Spalten (gleiche Breite) aus und fügen Sie diese nacheinander mit Hinzufügen (2) zu ihren ausgewählten Layouts (3) hinzu. Wählen Sie 1 Spalte (ganze Breite) als Standardlayout (4) und bestätigen Sie erst dann die Eingaben mit Weiter (5).

Fallstudie C: SAP NetWeaver Portal

461

Im letzten Schritt des Assistenten zur Seitenerstellung sehen Sie eine Übersicht über die erstellte Seite und die von Ihnen vorgenommenen Angaben.

Abb. 5.43 Zusammenfassung der Informationen zur Seite

Vergewissern Sie sich das ihre Angaben (1) korrekt sind. Der Name und die ID der Seite sollten UO_Seite1_Gruppe_XX lauten und im Ordner UO_Gruppe_XX angelegt werden. Als Standardlayout sollte 1 Spalte (ganze Breite) vorgegeben werden. Wenn die Eingaben korrekt sind, schließen Sie die Zusammenfassung durch einen Klick auf Fertig stellen (2). Im Folgenden Dialog wählen Sie Schließen Sie den Assistenten und klicken auf OK. Nun befindet sich in ihrem Ordner UO_Gruppe_XX neben den bereits erstellten iViews eine leere Seite. Diese Seite wird im späteren Verlauf der Strukturierung der iViews dienen.

462

Portaltechnologie

5.3.2.4

Integration von externen Informationen mit einem iView

Neben der Integration von Informationen und Anwendungen aus Systemen die an das Portal angeschlossen sind, lassen sich auch externe Informationen und Dienste in das Portal integrieren. Zusätzlich zu den beiden iViews erstellen Sie nun zwei iViews, die ihre Informationen aus externen Diensten holen. Als erstes wird ein URL-iView erstellt, der die Integration einer externen Webseite in die eigene Seite ermöglicht.

Abb. 5.44 Auswahl der URL-iView-Vorlage

Wählen Sie im Kontextmenü ihres Ordners UO_Gruppe_XX den Eintrag Neu und dort den Punkt iView. Als Quelltyp für den iView wählen Sie iView-Vorlage und klicken auf Weiter. Aus den verfügbaren Vorlagen wählen Sie den Punkt URL-iView (1). Scrollen Sie die Liste der Vorlagen herab, falls der Eintrag nicht zu sehen ist. Wenn Sie den Punkt URL-iView angewählt haben, klicken Sie auf Weiter (2).

Fallstudie C: SAP NetWeaver Portal

463

Nun geben Sie die allgemeinen Eigenschaften des URL-iView an.

Abb. 5.45 Allgemeine Eigenschaften eines URL-iView

Wählen Sie für den Namen (1) und für die ID (2) des iView UO_iView03_Gruppe_XX. Geben Sie eine kurzen beschreibenden Text (3) für ihren iView an und setzen Sie die Originalsprache auf Deutsch (4). Kontrollieren Sie ihre Eingaben und klicken Sie dann auf Weiter (5).

464

Portaltechnologie

Nun wird die Adresse der Webseite benötigt, die integriert werden soll. Optional kann auch nur ein Bereich der Webseite eingebunden werden.

Abb. 5.46 Angabe der Quell-URL zur Integration externer Webseiten

Geben Sie als URL http://www.uni-oldenburg.de ein (1), um eine externe Webseite in ihren iView zu integrieren. Klicken Sie dann auf Weiter (2). Über den Button Durchsuchen/Einbinden (3) können Sie optional nur einen Teilbereich der zu integrierenden Webseite auswählen. In diesem Falle, und zur Erhaltung der Funktionalität der in die Seite integrierten Funktionen, wird jedoch die gesamte Seite integriert. Der letzte Schritt des Assistenten zeigt eine Zusammenfassung der eingegebenen allgemeinen Eigenschaften des iView. Falls bei dem Feld Nach Beenden des Assistenten für Bearbeitung öffnen ein Haken gesetzt sein sollte, entfernen Sie diesen. Klicken Sie dann auf Fertig stellen. Sie werden zurück auf die Übersichtseite des Portal Content Studio geführt. Innerhalb ihres Ordners sollte nun ein weiterer iView aufgelistet werden.

Fallstudie C: SAP NetWeaver Portal

465

Neben der Integration einer Webseite können Sie über einen iView auch Datenströme in Form eines RSS-Dienstes integrieren. Wählen Sie dazu erneut aus dem Kontextmenü Ihres Ordners den Eintrag Neu und dort den Punkt iView. Als Quelltyp für den iView wählen Sie iView-Vorlage und klicken auf Weiter. Aus den verfügbaren Vorlagen wählen Sie den Punkt XML-iView und bestätigen diese Eingabe.

Abb. 5.47 Allgemeine Angaben eines XML-iView

Wählen Sie als Namen (1) und als ID (2) für diesen iView UO_iView04_Gruppe_XX. Achten Sie darauf die Originalsprache auf Deutsch zu stellen (3) und geben Sie eine kurze Beschreibung im Feld Beschreibung (4) an. Klicken Sie dann auf Weiter (5).

466

Portaltechnologie

Nun geben Sie die Quelle der zu integrierenden XML-Daten an. Neben der Integration von RSS-Diensten können die Daten auch aus dem Format BUSDOC umgewandelt werden.

Abb. 5.48 Integration einer XML-Quelle in den XML-iView

Geben Sie für eine XML-Quelle die Adresse http://www.unioldenburg.de/presse/mit/pressedienst.rdf ein (1), um den RSS-Feed dieser Seite einzubinden. Mit einem Klick auf Durchsuchen… (2) können Sie überprüfen, ob die angegebene Quelle XML-konforme Daten liefert. In dem sich öffnenden Browserfenster können Sie gegebenenfalls Korrekturen vornehmen oder zur XML-Quelle navigieren. Haben Sie eine korrekte XML-Quelle angegeben, klicken Sie auf Weiter (3) um die Erstellung des iView fortzusetzen. Nun wählen Sie das XML-Transformationsformat, um die Daten aus dem Eingabeformat in ein entsprechendes Ausgabeformat umwandeln.

Fallstudie C: SAP NetWeaver Portal

467

Abb. 5.49 XML-Transformationsformat für einen XML-iView

Wählen Sie den XML-Transformator RSS_TO_XHTMLB (1) um den RSS Feed entsprechend darstellen zu können. Klicken Sie dann auf Weiter (2). Weitere Optionen sind die Transformation aus dem BUSDOC-Format in XHTMLB sowie die Umwandlung aus dem XMHTMLB in HTML-Format. Innerhalb des fertigen iView können mehrere Transformationen verkettet werden, in dem mehrere XML-Transformer gewählt werden.

468

Portaltechnologie

Die nächste Seite zeigt Ihnen die Zusammenfassung (1) ihrer Angaben.

Abb. 5.50 Zusammenfassung der Informationen zum XML-iView

Kontrollieren Sie ob der Name, die ID und der gewählte XML-Transformator korrekt gewählt wurden und klicken Sie dann auf Fertig stellen (2). Wählen Sie im darauf folgenden Dialog Assistent schließen und klicken Sie auf OK. Nun haben Sie zwei verschiedene Formen von externen Inhalten in das Portal integriert. Über den URL-iView können Sie eine komplette Webseite in ihre eigenen Portal-Objekte einfügen. Mit dem XML-iView können Sie Datendienste wie einen RSS-Feed integrieren. Eine weitere Nutzungsmöglichkeit für einen iView bietet die Integration von Portalfunktionen und Objekten. Erstellen Sie nun einen neuen iView, der auf der iView-Vorlage iView für die Auswertung von Portalaktivitäten aufbaut. Nennen Sie diesen iView UO_iView05_Gruppe_XX. Schließen Sie den Assistenten nach der Erstellung des iView. Mit Hilfe dieses iView können Sie die Aktivität der Nutzer im Portal analysieren und protokollieren.

Fallstudie C: SAP NetWeaver Portal

5.3.2.5

469

Organisation von Inhalten

Mit den erstellten iViews können nun externe und interne Informationsquellen genutzt und im Portal angezeigt werden. Die erstellte Seite dient dabei als Mittel, die vorhandenen Informationen insgesamt in ein Objekt zu integrieren und verfügbar zu machen. Bevor die integrierten Inhalte für eine Analyse genutzt werden können, werden Sie nun in die erstellte Seite integriert. Öffnen Sie dazu die Objekteigenschaften der erstellten Seite.

Abb. 5.51 Öffnen der Objekteigenschaften aus dem Portal Content Catalog

Wählen Sie im Kontextmenü des Objektes UO_Seite1_Gruppe_XX (1) den Menüpunkt Öffnen (2) und im Untermenü den Eintrag Objekt (3). Im Portal Content Studio öffnet sich nun die Objektansicht der erstellten Seite.

470

Portaltechnologie

Nun können Sie ihre erstellten iViews in den Seiteninhalt integrieren. Um einen iView der Seite hinzuzufügen wählen Sie ihn über den Portal Content Catalog (1) aus.

Abb. 5.52 Einfügen eines iView in eine Seite als Deltalink

Öffnen Sie das Kontextmenü (2) des zu integrierenden iView und wählen Sie den das Untermenü iView zu Seite hinzufügen (3) und den Eintrag Deltalink (4). Fügen Sie nun alle ihre erstellten iViews zur Seite hinzu. Wenn Sie alle fünf iViews in die Seite integriert haben, sichern Sie ihre Änderungen an der Seite mit der Schaltfläche Sichern (5) im oberen Bereich der Objektansicht. Das hinzufügen über den Deltalink erzeugt in der Seite einen Verweis auf den iView. Änderungen am iView werden somit automatisch in der Seite übernommen. Nun befinden sich ihre erstellten iViews in der Seite. Wechseln Sie die Ansicht vom Seiten-Content auf das Seitenlayout, um die Anordnung der iViews einzustellen. Setzen Sie die Auswahl nun auf Seitenlayout (6), um in die Layoutansicht der Seite zu wechseln.

Fallstudie C: SAP NetWeaver Portal

471

In der Layoutansicht sehen Sie die Anordnung des Inhalts im aktuell gewählten Layout. Da Sie als Standardlayout 1 Spalte (ganze Breite) (1) gewählt haben, werden alle iViews in einer einzelnen Spalte untereinander angeordnet.

Abb. 5.53 Ansicht des Seitenlayout für die erstellte Seite

Sortieren Sie die iViews in aufsteigender nummerischer Reihenfolge. Sie können die Position eines iView per Drag&Drop (2) verschieben. Wählen Sie den zu verschiebenden iView und halten Sie die linke Maustaste gedrückt. Ziehen Sie nun in den gewünschten Freiraum ober oder unterhalb eines anderen iView um das gewählte Objekt zu verschieben. Achten Sie darauf wie der Mauszeiger sich verändert, wenn Sie den iView verschieben. Befindet sich der iView an der gewünschten Position lassen Sie die linke Maustaste los. Haben Sie alle iViews in die gewünschte Reihenfolge verschoben, sichern Sie die Änderungen an der Seite durch die entsprechende Schaltfläche Sichern (3) im Kopf der Seitenansicht. Über die Schaltfläche Vorschau (4) können Sie nun die Seite anzeigen lassen. In dieser Ansicht fällt auf, dass die Größe der einzelnen iViews unterschiedlich bemessen ist und nicht alle Inhalte vollständig zu sehen sind. Schließen Sie die Vorschau um dieses Problem zu beheben.

472

Portaltechnologie

Wählen Sie in der Ansicht Seitenlayout das erste Element der Seite, UO_iView01_Gruppe_XX (1). Klicken Sie dazu auf das Objekt, es wird mit einem farbigen Rand optisch hervorgehoben. Klicken Sie nun auf die Schaltfläche Eigenschaften (2) unterhalb des Seitenlayout.

Abb. 5.54 Eigenschafteneditor für ein Element einer Seite

Der Eigenschafteneditor am rechten Rand (3) zeigt nun alle Informationen zu dem iView UO_iView01_Gruppe_XX an. Über das Drop-Down Menü (4) oberhalb der Eigenschaften können Sie die Anzeige der Informationen wählen. Wählen Sie in diesem Menü nun den Punkt Darstellung – Größe, um nur die relevanten Informationen anzuzeigen.

Fallstudie C: SAP NetWeaver Portal

473

Ändern Sie die Eigenschaften zur Darstellung entsprechend, um den Inhalt des iView komplett anzeigen zu können.

Abb. 5.55 Anpassung der Darstellung und Größe eines iView innerhalb einer Seite

Dafür verändern Sie folgende Eigenschaften. Die Art der Höhe wird auf Automatic (1) gesetzt und der Wert für die Feste Höhe wird auf 0 (2) gesetzt. Die Minimale automatische Höhe setzen Sie auf 300 (3). Sichern Sie die Einstellungen (4) der Seite und sehen sich die vorgenommenen Änderungen in der Vorschau (5) an. Wie Sie sehen, wird die Größe des ersten iView automatisch an die angezeigten Inhalte angepasst. Passen Sie die Einstellungen für den iView UO_iView02_Gruppe_XX ebenfalls mit diesen Darstellungswerten an. Nun können Sie diese beiden iView auf der Seite in vollständiger Größe sehen. Für den iView UO_iView03_Gruppe_XX setzen Sie die Werte für die Feste Höhe und die Minimale automatische Höhe jeweils auf 300. Die Art der Höhe wird für diesen iView nicht verändert. Die letzten beiden iViews haben bereits eine für die Nutzung ausreichend große Fläche zur Darstellung zugeweisen. Sichern (4) Sie ihre Änderungen an der Seite.

474

Portaltechnologie

Zusätzlich zu der Layoutvorgabe 1 Spalte (ganze Breite) verfügt die Seite über die Möglichkeit, die Inhalte auf 2 Spalten aufzuteilen.

Abb. 5.56 Wechsel des zu bearbeitenden Layouts

Wählen Sie über das Drop-Down-Menü (1) oberhalb der Layoutansicht die Layoutvorgabe 2 Spalten (gleiche Breite). Die Layout Ansicht wird automatisch aktualisiert. Nun können Sie die Anordnung der einzelnen iViews in zwei Spalten vornehmen.

Fallstudie C: SAP NetWeaver Portal

475

Ordnen Sie die einzelnen iViews in die zwei Spalten des Layouts ein.

Abb. 5.57 Einordnung der iViews in ein 2 Spalten Layout

In die linke Spalte (1) ordnen Sie die iViews UO_iView01_Gruppe_XX und UO_iView02_Gruppe_XX ein. In die rechte Spalte der Seite (2) ordnen Sie nacheinander die restlichen iViews UO_iView03_Gruppe_XX, UO_iView04_Gruppe_XX sowie den iView UO_iView05_Gruppe_XX ein. Sichern Sie anschließend die Änderungen an der Seite (3). Wenn Sie sich nun die Vorschau (4) anzeigen lassen, werden Sie bemerken, dass obwohl Sie eine Vorgabe für ein 2 Spalten Layout getroffen haben, weiterhin das Standardlayout angezeigt wird. Schließen Sie die Vorschau.

476

Portaltechnologie

Um die Anzeige auf ein zweispaltiges Layout zu ändern sind weitere Veränderungen notwendig. Drücken Sie die Schaltfläche Layouts definieren, um die Layouts der aktuellen Seite zu verwalten.

Abb. 5.58 Wechsel des Seitenlayouts

Wählen Sie nun als Standardlayout (1) den Eintrag 2 Spalten (gleiche Breite) und bestätigen Sie Ihre Wahl mit OK (2). Lassen Sie sich nun die Vorschau auf die Seite anzeigen (3). Ihre iViews werden nun sowohl untereinander als auch nebeneinander angezeigt. Schließen Sie die Vorschau. Suchen Sie sich nun eine der beiden Layoutvorgaben für ihre Seite aus.

Fallstudie C: SAP NetWeaver Portal

5.3.2.6

477

Zusammenfassung

Sie können nun die verschiedenen Objekte im Portal Content Studio erstellen und die integrierten Informationen zusammenführen und darstellen. Mittels der verschiedenen iView Vorlagen sind Sie in der Lage, verschiedene Informationen im Portal zu integrieren und diese entsprechend darzustellen. So können Sie nun sowohl die Informationen aus erstellten BEx Web Application integrieren als auch externe Informationen wie die Inhalte einer Webseite oder einen den Datenstrom einer XML-Quelle. Zusätzlich können Sie technische Informationen aus dem Portal darstellen und nutzen. Mit diesen Informationen können Sie verschiedene Aufgaben gestalten. So erlaubt die Integration der Web Applications den Nutzern die Analyse aus dem Portal, die Einbindung externer Quellen ermöglicht die Anwendung verschiedener Dienste zur Ergänzung der vorhandenen internen Systeme. Die Verwendung von Portal-eigenen Informationen wie der Nutzungsdauer oder der Systemauslastung, erlauben eine zusätzliche Unterstützung bei den jeweiligen Aufgaben. Durch die Gestaltung einer Portal-Seite können Sie diese Daten kombinieren und die Darstellung der Inhalte anpassen. Dabei sind verschiedene Layoutvorgaben angewandt worden und die Unterschiede zwischen den jeweiligen Varianten dargestellt worden.

478

Portaltechnologie

5.3.3 Teil III - Analyse und Reporting im Portal In diesem Teil der Fallstudie werden die Analyse und Reporting Möglichkeiten der im zweiten Teil erstellten Inhalte vorgestellt. Neben der Analyse der integrierten Daten werden auch die portaleigenen Berichte genutzt. 5.3.3.1

Analyse auf integrierten Daten über einen iView

Mit Hilfe der integrierten Queries können nun die ersten Analysen im Portal durchgeführt werden. Dazu ist keine weitere Authentifizierung oder die Verwendung eines weiteren Programmes notwendig. Öffnen Sie nun die Vorschau auf den iView UO_iView01_Gruppe_XX.

Abb. 5.59 Vorschau auf die Query Produkt-Umsatz Ist XX

Die Darstellung der Analyse Produkt-Umsatz Ist XX ist in der vorliegenden Form sehr schlicht aufgebaut. So ist als Spaltenwert nur die Kennzahl Umsatz angegeben. Um den Zugriff auf die unveränderte Form der Query zu vereinfachen, erstellen Sie nun einen Eintrag in den Favoriten für diese Ansicht.

Fallstudie C: SAP NetWeaver Portal

479

Um einen Eintrag in den Favoriten aus der Query heraus zu erstellen, wählen Sie im Menü über der Tabelle die Schaltfläche Sichern als…

Abb. 5.60 Anlegen eines Favoriten im Ordner Integrierte Inhalte

Der sich nun öffnende Dialog zeigt die angelegte Struktur der Portalfavoriten. Wählen Sie den Ordner Integrierte Inhalte (1) und legen Sie einen Favoriten mit der Beschreibung Produkt-Umsatz Ist XX – Original (2) an. Bestätigen Sie die Eingabe mit OK (3). Sie kehren automatisch zur geöffneten Query zurück.

480

Portaltechnologie

Erweitern Sie die angezeigten Informationen, indem Sie mit Hilfe der freien Merkmale weitere Informationen in der Darstellung aufreißen. So können komplexere und detailliertere Aussagen getroffen werden.

Abb. 5.61 Erweitern der dargestellten Informationen

Öffnen Sie das Kontextmenü (1) des freien Merkmals Buchungskreis und wählen Sie innerhalb des Menüs den Eintrag Aufriss verändern (2) und im Untermenü die Einträge Aufreißen nach (3) und senkrecht (4). Die Darstellung der Tabelle wird automatisch erweitert um die Zeilen Buchungskreis. Nun können Sie die Angaben zur Kennzahl Umsatz für die einzelnen Buchungskreise betrachten und sortieren. Erweitern Sie die angezeigten Informationen erneut, indem Sie das freie Merkmal KalJahr/Monat als Spalte hinzufügen. Klicken Sie dazu mit der rechten Maustaste auf das freie Merkmal KalJahr/Monat und wählen Aufriss verändern und in den Untermenüs die Einträge Aufreißen nach und waagerecht.

Fallstudie C: SAP NetWeaver Portal

481

Sichern Sie diese Sicht auf die Daten als Favoriten in ihren Portal Favoriten.

Abb. 5.62 Erweiterte Ansicht auf die Query (a)

Sichern Sie den Favoriten im Ordner Analyse und wählen Sie für die Beschreibung den Text Produkt-Umsatz Ist XX – Buchungskreis und Monat. Über den Eintrag in den Portalfavoriten kann die gewählte Sicht direkt im Portal geöffnet werden.

482

Portaltechnologie

Verändern Sie nun die Anzeige der Query und fügen Sie einen Kommentar hinzu, um weitere Informationen zu den vorhandenen Daten anzufügen.

Abb. 5.63 Erweiterte Ansicht auf die Query (b)

Wählen Sie aus der Dropdown-Box (1) im oberen Menü den Eintrag Tabelle und Grafik. Die Ansicht wird automatisch um eine Säulengrafik ergänzt. Klicken Sie dann auf Kommentare (2), um zusätzliche Informationen hinzufügen zu können.

Fallstudie C: SAP NetWeaver Portal

483

Für die Kommentare öffnet sich ein weiteres Popup, in dem die Art der ergänzenden Information gewählt werden kann.

Abb. 5.64 Hinzufügen von Informationen zu einer Query

Klicken Sie in der Kommentarbox auf Neu (1) und Bemerkungen (2), um einen Text an die Query Produkt-Umsatz ist XX anzufügen.

484

Portaltechnologie

In diesem Feld können Sie einen Text angeben, der weiterführende oder analysierende Informationen hinzufügt.

Abb. 5.65 Angabe von weiteren Informationen zu einer Query

Geben Sie einen Namen (1), eine Beschreibung (2) und einen kurzen Text (3) ein, der die vorhandenen Daten analysiert. Gehen Sie auf die Umsatzzahlen in den einzelnen Monaten ein und vergleichen Sie die verschiedenen Buchungskreise. Sichern (4) Sie den eingegebenen Text und schließen Sie das aktuelle Popup.

Fallstudie C: SAP NetWeaver Portal

485

Nun erscheint in der Kommentarbox ihre kurze Analyse der Umsatzzahlen. Schließen und aktualisieren Sie die Kommentarbox. Öffnen Sie erneut die Kommentare.

Abb. 5.66 Kommentare zu einer Query

Nun sehen Sie alle vorhandenen Kommentare zu dieser Query. Den Inhalt der Kommentare können Sie in einem gesonderten Textfeld sehen, das sich auch von der Kommentarbox abtrennen lässt. Zusätzlich werden die ersten Sätze in einem Feld gezeigt, das erscheint wenn mit der Maus auf den Namen des Kommentars gezeigt wird. Schließen Sie die Kommentaranzeige und kehren Sie zu der Anzeige der Query zurück. Sichern Sie diese Sicht auf die Query in ihren Favoriten. Speichern Sie die Sicht im Ordner Analyse ab und wählen Sie als Beschreibung Produkt-Umsatz Ist XX – Grafik. Schließen Sie diese Sicht auf die Query Produkt-Umsatz Ist XX.

486

Portaltechnologie

In ihren Portalfavoriten sind nun mehrere neue Einträge aufgeführt. Wählen Sie den Eintrag Produkt-Umsatz Ist XX – Grafik (1), indem Sie mit der linken Maustaste auf ihn klicken.

Abb. 5.67 Darstellung einer Query im Portal-Desktop

Die von Ihnen gewählte Sicht auf die Query (2) lässt sich nun innerhalb des Portal-Desktop ansehen und bearbeiten. Die dargestellte Sicht ist jederzeit über die Favoriten aufrufbar und lässt sich mit verschiedenen Methoden aus dem Portal exportieren (Excel, Druck, CSV etc.). Schließen Sie die geöffneten Popups und kehren Sie zum Portal Content Studio zurück.

Fallstudie C: SAP NetWeaver Portal

487

Erstellen Sie nun eine weitere Analyse aus ihrem ersten iView. Verwenden Sie dazu die bereits vorgestellten Wege um die Query zu öffnen.

Abb. 5.68 Darstellung einer weiteren Analyse

Erweitern Sie dabei die Darstellung um eine Grafik und reißen die Umsätze nach den Produkten getrennt auf. Zusätzlich fügen Sie als Zeilenaufteilung das freie Merkmal KalJahr/Monat ein. Sichern Sie diese Sicht auf die Query als Portalfavorit mit der Bezeichnung Produkt-Umsatz Ist XX - Grafik Produkte in dem Ordner Analyse. Schließen Sie die Sicht auf die Query und aktualisieren Sie ihre Portalfavoriten.

488

Portaltechnologie

5.3.3.2

Reporting über die portaleigenen Vorgänge

Innerhalb des Portals können die Aktivitäten der Nutzer festgehalten und als Bericht ausgegeben werden. Mit dem iView UO_iView05_Gruppe_XX ist ein solcher Report möglich.

Abb.5.69 Portalaktivitätsbericht – Zahl der angemeldeten Nutzer

Öffnen Sie über das Kontextmenü im Portal Catalog die Vorschau auf den iView UO_iView05_Gruppe_XX.

Fallstudie C: SAP NetWeaver Portal

489

Sie sehen den Portalaktivitätsbericht über die zuletzt angemeldeten Nutzer. Sie können die Ergebnisse des Berichts direkt als CSV-Datei herunterladen. Schließen Sie den Aktivitätsbericht und kehren Sie zum Portal Desktop zurück. Neben der Portalaktivität der angemeldeten Nutzer, können Sie auch die Aktivität auf den einzelnen Seiten und iViews protokollieren lassen. Öffnen Sie über das Kontextmenü im Portal Content Catalog die Objekteigenschaften des iView UO_iView05_Gruppe_XX.

Abb. 5.70 Auswahl des zu überwachenden Contents

Wählen Sie die Berichtsart Seiten/iView-Aktivität (1). Die Ansicht auf das Objekt wird automatisch erneuert. Wählen Sie dann aus dem Portal Content Catalog im Kontextmenü ihres Gruppenordners den Eintrag Alle Objekte zur ausgewählten Content-Liste hinzufügen. (2). Sichern Sie die Änderungen am Objekt (3). Da Sie alle Objekte aus ihrem Ordner hinzugefügt haben, werden die einzelnen iViews nun doppelt aufgeführt. Diese iViews sind sowohl einzeln, als auch durch ihre Beziehung zur erstellten Seite gewählt worden. Die Einträge müssen jedoch nicht entfernt werden, sondern ermöglichen eine getrennte Betrachtung der Zugriffe für den einzelnen iView und den in die Seite integrierten iView.

490

Portaltechnologie

Sehen Sie sich nun den neuen Bericht an, den Sie erstellt haben. Öffnen Sie die Vorschau des aktuellen iView.

Abb. 5.71 Portalaktivitätsbericht für Seiten und iViews

Dieser Bericht ist anders gestaltet als der vorherige Portalaktivitätsbericht. Die verschiedenen iViews und Seiten lassen sich für die Tage getrennt auf Zugriffe analysieren. Ein Export der Daten in Form einer CSV-Datei ist ebenfalls möglich. Die praktische Anwendung eines solchen Berichtes kann selten oder häufig genutzte Portalelemente identifizieren und Raum für Optimierung geben. So kann ein selten bis nicht genutzter iView zur Entfernung vorbereitet werden oder analysiert werden, warum dieser iView nicht genutzt wird. Die vorhandenen Optionen ermöglichen zudem Einschränkungen auf eine festzulegende Anzahl der am meisten besuchten Seiten und iViews. 5.3.3.3

Zusammenfassung

Auf den erstellten Inhalten können über das Portal direkt verschiedene Analyse und Reporting-Funktionen genutzt werden. Die bei der Analyse gewonnenen Erkenntnisse können in Form von Bemerkungen oder Texten an die Objekte angefügt werden. Ebenso können die erstellten Analysen und Berichte individuell abgelegt und in verschiedenen Formen exportiert werden.

Literaturverzeichnis Albert G (2002) Betriebliche Personalwirtschaft. Kiehl Verlag, Ludwigshafen Amshoff B (1993) Controlling in deutschen Unternehmungen. In: Welge M, Al-Laham A (1999) Strategisches Management. Gabler Verlag, Wiesbaden Anahory S, Murray D (1997) Data Warehouse – Planung, Implementierung und Administration. Addison-Wesley, Bonn BARC (2005) Was macht Business Intelligence Projekte erfolgreich? Business Application Research Center, Würzburg Bauer A, Günzel H (2004) Data Warehouse Systeme – Architektur, Entwicklung, Anwendung. dpunkt, Heidelberg Böhnlein M, Ulbrich-vom Ende A (2000) Grundlagen des Data Warehousing: Modellierung und Architektur. Bamberger Beiträge zur Wirtschaftsinformatik Nr. 55. Bamberg Bulos D, Forsman S (1998) Getting Started with ADAPT. Symmetry Corporation. San Rafael, CA, USA Capgemini (2008) Studie IT-Trends 2008. Capgemini Deutschland GmbH, Berlin Chamoni P, Gluchowski P (2006) Analytische Informationssysteme: Business IntelligenceTechnologien und -Anwendungen. Springer Verlag, Berlin Chamoni P, Gluchowski P (2008) Management Support Systeme und Business Intelligence. Springer Verlag, Berlin Chen L (2008) Konzeption eines Vorgehensmodells für SAP BW Projekte unter besonderer Berücksichtigung der Projektkosten. Carl-von-Ossietzky Universität Oldenburg, Oldenburg Dearden J (1964) Can Management Information Be Automated? In: Oppelt U (1995) Computerunterstützung für das Management. Oldenbourg Verlag, München Devlin B (1997) Data Warehouse: From Architecture to Implementation. Reading, MA, USA DGFP (2008) Personalwirtschaftliche Kennziffern 2008. Deutsche Gesellschaft für Personalführung mbH, Düsseldorf Drumm H (2006) Personalwirtschaft. Springer Verlag, Berlin Edinger J, Krämer C, Lübke C, Ringling S (2008) Personalwirtschaft mit SAP ERP HCM. Galileo Press, Bonn Egger N, Fiechter J-M R, Rohlf C, Rose J, Weber S (2005) SAP BW – Planung und Simulation. Galileo Press, Bonn Egger N, Fiechter J-M R, Kramer S, Sawicki R P, Straub P, Weber S (2006) SAP Business Intelligence. Galileo Press, Bonn Fayol H (1916) Administration Industrielle et Générale. Dunod Verlag, Paris Fluri E, Ulrich P (1995) Management. UTB, Stuttgart Fraunhofer (2008) Business Performance Management. Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V., München. Freund F (2003) Praxisorientierte Personalwirtschaftslehre. Kohlhammer Verlag, Stuttgart Fuller D (2002) The fundamentals of Data Warehousing: What is a Data Warehouse? DM Review Magazine Gälweiler A (1986) Unternehmensplanung. In: Kreikebaum H (1993) Strategische Unternehmensplanung. Kohlhammer Verlag, Stuttgart Gartner (2006) Magic Quadrant for Horizontal Portal Products, 2006, http://mediaproducts.gartner.com/gc/reprints/ibm/external/article12/article12.html Aufgerufen am 21.08.2008 Gartner (2008) Magic Quadrant for Business Intelligence Platforms. Gartner Inc, Stamford Goeken M (2006) Entwicklung von Data-Warehouse-Systemen - Anforderungsmanagement, Modellierung, Implementierung. DUV, Wiesbaden

492

Literaturverzeichnis

Großmann M, Koschek H (2005) Unternehmensportale: Grundlagen, Architekturen, Technologien. Springer Verlag, Berlin Grothe M, Gentsch P (2000) Business Intelligence. Addison-Wesley, München Gulick L, Urwick L (1937) Papers on the Science of Administration. Institute of Public Administration, New York Gutenberg E (1962) Unternehmensführung. Gabler Verlag, Wiesbaden Gupta V (1997) An Introduction to Data Warehousing. System Service corporation. Chicago, IL, USA Gurzki T (2001) Was ist ein Portal? - Definition und Einsatz von Unternehmensportalen. In: Fraunhofer (2004) Effiziente Portalprojekte in der Unternehmenspraxis. Fraunhofer Institut Arbeitswissenschaft und Organisation, Stuttgart Gurzki T, Hinderer H (2003) Eine Referenzarchitektur für Software zur Realisierung von Unternehmensportalen. In: Stumme G (Hrsg.) (2003) WM2003: Professionelles Wissensmanagement - Erfahrungen und Visionen. Gesellschaft für Informatik, Luzern Hahn D, Taylor B (2006) Strategische Unternehmensplanung - Strategische Unternehmensführung. Springer Verlag, Berlin Hahne M (2004) Datenmodellierung für BI-Systeme. Vortrag auf der TDWI Konferenz. München Hahne M (2005) SAP Business Information Warehouse – Mehrdimensionale Datenmodellierung. Springer Verlag, Berlin Hasselbring W, Koschel A, Mester, A(2001) Basistechnologien für die Entwicklung von Internet-Portalen, In: Datenbanksysteme in Büro, Technik und Wissenschaft (BTW), 9. GIFachtagung, Oldenburg, 7.-9. März 2001, Proceedings. Informatik Aktuell Springer 2001 Hax A, Majluf N (1991) Strategisches Management. Campus Verlag, Frankfurt am Main Heinrich L J (2005) Informationsmanagement: Planung, Überwachung und Steuerung der Informationsinfrastruktur. Oldenbourg Verlag, München Helfert M (2000) Maßnahmen und Konzepte zur Sicherung der Datenqualität. In: Jung R, Winter R (2000), S 61-77 Hentze J, Kammel A (1993) Personalcontrolling. UTB Verlag. Stuttgart Heuser R, Günther F, Hatzfeld O (2003) Integrierte Planung mit SAP. Galileo-Press, Bonn Hinrichs H (2002) Datenqualitätsmanagement in Data Warehouse-Systemen. Dissertation, Carl von Ossietzky Universität, Oldenburg Holthuis J (2002) Der Aufbau von Data Warehouse-Systemen. Konzeption – Datenmodellierung – Vorgehen. Gabler, Wiesbaden Humm B, Wietek F (2005) Architektur von Data Warehouses und Business Intelligence Systemen. Informatik Spektrum 3/05. Springer, Berlin IBI (2003) Business Intelligence SAP Anwenderbefragung. Institut für Business Intelligence, Rielasingen IBI (2004) Empirische Studie: Integrierte Unternehmensplanung. Institut für Business Intelligence, Rielasingen Inmon W H (1996) Building the Data Warehouse. 2nd Edition, John Wiley & Sons, New York Inmon W H (2001) Corporate Information Factory. John Wiley & Sons, New York Inmon W H (2005) Building the Data Warehouse. 4th Edition, John Wiley & Sons, New York Inmon W H (2006) Metadata - Centralized and distributed in DW2.0 Jetter W (2003) Effiziente Personalauswahl. Schäffer-Poeschel Verlag, Stuttgart Jochmann W, Gribig R (2007) Personalcontrolling als Unterstützung eines strategischen HRManagements. In: Personalcontrolling Jost P J (2000) Organisation und Koordination. Gabler Verlag, Wiesbaden Jung R, Winter R (Hrsg) (2000) Data Warehousing Strategie - Erfahrungen, Methoden, Visionen. Springer, Berlin Kaplan R S, Norton D P (1997) Balanced Scorecard: Strategien erfolgreich umsetzen. SchäfferPoeschel Verlag, Stuttgart

Literaturverzeichnis

493

Karcher A (2005) Einführung in die Wirtschaftsinformatik 1. Manuskript zur Vorlesung, Universität der Bundeswehr. München Keen P, Scott-Morton M (1978) Decision Support Systems: An Organizational Perspective. In: Oppelt U (1995) Computerunterstützung für das Management. Oldenbourg Verlag, München Kemper H-G, Mehanna W, Unger C (2004) Business Intelligence - Grundlagen und praktische Anwendungen. Vieweg Verlag. Wiesbaden Kießwetter M, Berkenkamp S, Vahlkamp D (2008) Integrierte Planungsanwendungen mit SAP NetWeaver BI 7.0 entwickeln. SAP-Heft 38, Galileo Press, Bonn Kimball R, Ross M, Thornwaite W, Mundy J, Becker B (2008) The Data Warehouse Lifecycle Toolkit. Second Edition, John Wiley & Sons, New York Kolb M (1998) Personalmanagement. Berliner Wissenschafts Verlag, Berlin Koontz H, O'Donnel C (1964) Principles of Management: An Analysis of Management Functions. McGraw-Hill, New York Kossbiel H (1994) Überlegungen zur Effizienz betrieblicher Anreizsysteme. In: Die Betriebswirtschaft, 54. Jg., Nr. 1/1994, S. 75-93 Kreikebaum H (1993) Strategische Unternehmensplanung. Kohlhammer Verlag, Stuttgart Kreikebaum H, Grimm U (1978) Strategische Unternehmensplanung. Ergebnisse einer empirischen Untersuchung. Seminar für Industriewirtschaft an der Johann Wolfgang GoetheUniversität, Frankfurt am Main Krcmar H (2004) Informationsmanagement. Springer Verlag, Berlin Lambert B (1996) Data Warehousing Fundamentals: What You Need To Know To Succeed. DM Review Magazine Leavitt H, Whistler T (1958) Management in the 1980's: New Information Flows Cut New Organizational Channels. In: Oppelt U (1995) Computerunterstützung für das Management. Oldenbourg Verlag, München Lisges G, Schübbe F (2007) Personalcontrolling. Rudolf Haufe Verlag, München Manhart K (2008a) Grundlagenserie Business Intelligence. BI-Methoden (Teil 1): Ad-hoc Analysen mit OLAP. http://www.tecchannel.de/server/sql/1751285/ Aufgerufen am 19.08.2008. IDG Business Media GmbH, München Manhart K (2008b) Grundlagenserie Business Intelligence. Business Intelligence (Teil 3): Datenmodellierung – Relationale und Multidimensionale Modelle. http://www.tecchannel.de/ server/sql/1744994/ Aufgerufen am 19.08.2008. IDG Business Media GmbH, München Marx Gómez J, Rautenstrauch C, Cissek P, Grahler B (2006) Einführung in SAP Business Information Warehouse. Springer, Berlin McDonald K, Wilmsmeier A, Dixon D C, Inmon W H (2006) Mastering the SAP Business Information Warehouse. Second Edition, Wiley Mehrwald C (2007) Datawarehousing mit SAP BW 7. BI in SAP NetWeaver 2004s – Architektur, Konzeption, Implementierung. dpunkt, Heidelberg Meta Group (2004) Business Intelligence Marktanalyse und Markttrends. META Group Deutschland GmbH, Essen Michaeli R (2006) Competitive Intelligence. Springer Verlag, Berlin Microsoft (2006) Erfolgreicher mit Geschäftskennzahlen und Microsoft Business IntelligenceTechnologien. http://www.microsoft.com/germany/mittelstand/ziele/optimierung/kennzahlen1.mspx. Aufgerufen am 12.05.2008. Microsoft Corporation, Redmont Microsoft (2008a) Microsoft Dynamics AX - Systemanforderungen. http://www.microsoft.com/austria/dynamics/ax/systemanforderungen.mspx. Aufgerufen am 11.05.2008. Microsoft Corporation, Redmont Microsoft (2008b) Microsoft Windows Server - Lösungen für mittelständische Unternehmen. http://www.microsoft.com/germany/mittelstand/produkte/server/serversystem.mspx. Aufgerufen am 11.05.2008. Microsoft Corporation, Redmont

494

Literaturverzeichnis

Microsoft (2008c) Bereitstellung von Business Intelligence über Microsoft Office SharePoint Server 2007. http://office.microsoft.com/de-de/sharepointserver/HA101747701031.aspx. Aufgerufen am 14.05.2008. Microsoft Corporation, Redmont Müller-Böling D, Ramme I (1988) Informations- und Kommunikationstechniken für Führungskräfte: Top-Manager zwischen Technikeuphorie und Tastaturphobie. In: Oppelt U (1995) Computerunterstützung für das Management. Oldenbourg Verlag, München Müller-Christ G (2005) Skript zur Vorlesung Personalmanagement. Universität Bremen, Bremen Olfert K (2006) Personalwirtschaft. Kiehl Verlag, Ludwigshafen Oppelt U (1995) Computerunterstützung für das Management. Oldenbourg Verlag, München Rautenstrauch C (2001) Einführung in die Wirtschaftsinformatik. Manuskript zur Vorlesung, Otto-von-Guericke Universität, Magdeburg Rautenstrauch C (2003) Prozessmodellierung. Manuskript zur Vorlesung, Otto-von-Guericke Universität, Magdeburg Rautenstrauch C (2004) Strategisches Informationsmanagement. Manuskript zur Vorlesung, Otto-von-Guericke Universität, Magdeburg Ream N (1960) The Need for Compact Management Intelligence. In: Oppelt U (1995) Computerunterstützung für das Management. Oldenbourg Verlag, München Reichard C (2001) Personalmanagement. In: Handbuch zur Verwaltungsreform, Opladen SAP (2003) Using Process Chains in SAP Business Information Warehouse. SAP AG, Walldorf SAP (2005) Enterprise Reporting, Query & Analysis in NetWeaver7.0. SAP AG, Walldorf SAP (2006) Enterprise Reporting, Query and Analysis. SAP AG, Walldorf SAP (2007) SAP-Geschäftsbericht 2007. SAP AG, Walldorf SAP (2008a) SAP-Bibliothek – People Integration - Portal. http://help.sap.com/saphelp_nw70/ helpdata/de/30/c4461ff69d5a438f1286e344b545fa/frameset.htm Aufgerufen am 21.08.2008. SAP AG, Walldorf SAP (2008b) SAP-Bibliothek – BI Integrierte Planung. http://help.sap.com/saphelp_nw70/ helpdata/de/43/0c033316cd2bc4e10000000a114cbd/frameset.htm. Aufgerufen am 11.08.2008. SAP AG, Walldorf SAP (2008c) SAP-Bibliothek – Data Warehousing. http://help.sap.com/saphelp_nw70/ helpdata/de/a8/6b023b6069d22ee10000000a11402f/frameset.htm. Aufgerufen am 28.08.2008. SAP AG, Walldorf SAP (2008d) SAP-Bibliothek – Performance-Optimierung. http://help.sap.com/saphelp_nw04/ helpdata/de/80/1a62f8e07211d2acb80000e829fbfe/frameset.htm. Aufgerufen am 31.08.2008. SAP AG, Walldorf Saracus (2008) Business Intelligence. http://www.saracus.com/saracus_22_business_intelligence.html. Aufgerufen am 12.05.2008. saracus consulting AG, Baden-Dättwil Sattler K, Saake G (2004) Data Warehouse Technologien. Manuskript zur Vorlesung, Otto-vonGuericke Universität. Magdeburg Schanz G (2000) Personalwirtschaftslehre. Vahlen Verlag, München Scheer A W, Jost W (2002) ARIS in der Praxis. Springer, Berlin Scholz C (2000) Personalmanagement. Verlag Vahlen, München Soeffky M (1998) Data Warehouse: Prozeß- und Systemmanagement. it-research Springer J (2006) Skript zur Vorlesung Personalmanagement. Rheinisch-Westfälische Technische Universität Aachen, Aachen Steiner G A (1971) Top Management Planung. In: Kreikebaum H (1993) Strategische Unternehmensplanung. Kohlhammer Verlag, Stuttgart Steinmann H, Schreyögg G (1997) Management. Gabler Verlag, Wiesbaden Stelzer D (2004) Portale – Einführung und Überblick. In: Gentsch P (Hrsg.) Praxishandbuch Portalmanagement - profitable Strategien für Internetportale. Gabler Verlag, Wiesbaden Siemens (2008) Enterprise Business Intelligence. Siemens AG, München

Literaturverzeichnis

495

Wang R Y (1998) A Product Perspective on Total Data Quality Management. In: Communications of the ACM 41(2), S. 59-65 Welge M, Al-Laham A (1999) Strategisches Management. Gabler Verlag, Wiesbaden Wild J (1974) Grundlagen der Unternehmensplanung. In: Kreikebaum H (1993) Strategische Unternehmensplanung. Kohlhammer Verlag, Stuttgart Wöhe G (2002) Einführung in die Allgemeine Betriebswirtschaftslehre. Vahlen Verlag, München

Index A Abgeleitete Daten 70 ADAPT 82 Aggregat-InfoCube 125 Aggregation (Kennzahlen) 105 Aggregationsebene 294 Analytische Anwendungen 23 Anwendungsplattform 43 Archivierung 125 ARIS 77 Authentifizierung 403 B Balanced-Scorecard 282 Bedingungen 130 Berechtigungskonzept (SAP BI) 127 Berechtigungskonzept (SAP Portal) 405 Bericht-Bericht-Schnittstelle 135 Betriebswirtschaftlich Administrative Systeme 63 Betriebswirtschaftliche Metadaten 70 BEx Analyzer 140 BEx Query Designer 129 BEx Query 129 BEx Report Designer 138 BEx Web Application Designer 135 BI Acclerator 125 BI Projekt 37 BI-Roadmap 38 Business Planning and Simulation 285 Branchenattraktivität-WettbewerbsstärkeMatrix 276 Branchensegmentierung 251 Budgetierung 249 Business Intelligence 9 Business Performance Management 19 Business Server Pages 424 C Cascading Style Sheets 136 Collaboration 413 Composite Application Framework 43 Content Area 408 Content-Management-Systeme 397 D Data Mart 120 Data Mart Interface 119

Data Mining 23 Data Provider 46 Data-Store Objekt 111 DataSource 115 Data Warehouse 61 Data Warehouse Architektur 67 Data Warehousing 62 Data Warehousing Workbench 93 Daten 60 Datenfluss 96 Datenmodell 76 Datenquelle 71 Datenqualität 74 Datenscheiben 294 Datentransferprozess 119 Datentyp (Merkmal) 102 Datentyp (Kennzahl) 104 Delta-Laden 119 Dice 82 Dimensionen 79 Dokumentenverwaltung 391 Drill-Across 81 Drill-Down 80 Drill-Through 81 DSS 15 E Echtzeitdaten 69 EIS 16 Einheit 106 Enterprise Data Warehouse 287 Entscheider 264 Entscheidungsunterstützende Systeme 63 Erfahrungskurve 268 ETL 89 Exception Reporting 130 Extraktion 90 F Fakten 78 Filter (BEx Query) 132 Filter (BI-Integrierte Planung) 295 Fortschreibung 117 G Gegenstromverfahren 268 Geschäftsdaten 69 Groupware 390 H Header Area 407

498

Index

I Info-Area 98 InfoCube 110 InfoObject-Katalog 99 InfoObject 100 Information 60 Information Integration 41 Informationsfunktion 31 Informationsinfrastruktur 28 Informationsmanagement 28 Informationstechnologie 14 InfoSet 114 InfoSource 116 InfoSpoke 120 Ist-Personalbestand 261 iView 409 K Kennzahlen 78 Kollaboration 390 Komprimierung 125 Konsolidierte Daten 70 L Laden 92 Langfristige Planung 250 Lebenszyklus 279 Leistungspotential 31 M Management-Prozess 245 Marktwachstum-Marktanteil-Matrix 271 Metadaten 70 Merkmale 78 Merkmalsbeziehungen 293 MIS 15 Modell 76 MOLAP 87 MultiProvider 112 N Navigation Panel 408 O OLAP 63 OLTP 63 Open Hub Destination 120 Operative Planung 257 Operative Systeme 24 P Partitionierung 125 People Integration 41

Personalisierung 389 Personalmanagement 258 Personalplanung 260 Plan-Query 299 Planer 264 Planning Modeler 288 Planning Wizard 288 Planungsanwendung 299 Planungsfunktionen 295 Planungssequenz 297 Planungsszenario 289 Portal 378 Portal Content Studio 417 Portaldesktop 407 Portalsoftwaremarkt 394 Prozessintegration 42 Prozessketten 122 PSA 97 Q Quellsysteme 115 R Real-Time Data Acquisition 127 Referenzierendes Merkmal 102 Referenzierende Kennzahl 105 Repository 411 ROLAP 87 Roll-Up 81 Rotate 80 S SAP GUI 2 SAP Fenster 3 SAP NetWeaver 7.0 40 SAP NetWeaver Business Intelligence 45 SAP NetWeaver BI-Integrierte Planung 285 SAP NetWeaver Portal 398 Schema 77 Single Sign-On 404 Slice 81 Snowflake-Schema 88 Soll-Personalbestand 261 Solution Life Cycle Management 43 Stammdaten 106 Star-Schema 87 Strategiebestimmung 252 Strategische Planung 248 Strategische Rolle 32 Strategische Schlagkraft 33 Struktur 131 Suche 392

Index T T-ADAPT 86 Technische Merkmale 103 Technische Metadaten 70 Transformation 116 Transport 126 TREX 412 U Unternehmensplanung 242 Unternehmenspolitischer Willensbildungsprozess 242 Unternehmensportal 384 Unternehmensstrategieplanung 254

V Variablen (BEx Query Designer) 133 Variablen (BI-Integrierte Planung) 297 Virtual Provider 113 Visual Composer 420 W Web Item 137 Webportal 384 Web Template 136 Wissensmanagement 411 Workset 419 Z Zeitmerkmale 86 Zielsystem 244

499