SAP-HANA-Strategie: Vorgehen, Inhalte und · PDF fileSAP-HANA-Strategie: Vorgehen, Inhalte und Erfahrungswerte 3 Mögliche Business Cases Die Einführung neuer Technologien ist kein

1

4958

.01.

01 –

© S

ympo

sion

Pub

lishi

ng

SAP-HANA-Strategie: Vorgehen, Inhalte und Erfahrungswerte

Seit SAP 2012 für das Business Warehouse »SAP BW

powered by SAP HANA« vorstellte, sind die Vorteile von

SAP HANA im analytischen Bereich oft gezeigt worden.

Mit der Präsentation der Suite 4 SAP HANA als Nach-

folger der NetWeaver-Plattform im Februar 2015 richtet

SAP seine Strategie voll auf SAP HANA aus.

In diesem Beitrag erfahren Sie: � warum eine Einführung von SAP-HANA-Techno-logie umfassende Analysen vor der Entscheidung erfordert,

� inwiefern allgemeingültige Dimensionen die Analyse unterstützen sowie

� welche Themen häufig behandelt werden.

SAP HANA – die neue Applikationsplattform von SAP SAP HANA ist ein Applikationsserver, dessen zentrales Element eine integrierte, hauptspeicherbasierte Datenbank ist. Damit ist im Ge-gensatz zur SAP-NetWeaver-Plattform keine zusätzliche relationale Datenbank erforderlich. Die tiefe Integration der Datenbank in den Applikationsserver, eine neu geschaffene Programmiersprache namens »SQL-Script« sowie NoSQL-Elemente wie »calculated views« ermög-lichen Verarbeitungsgeschwindigkeiten, die mit der NetWeaver-Platt-form nicht möglich waren.

Die Anbieter von relationalen Datenbanken, die bisher den »Unter-bau« für die SAP-NetWeaver-Plattform geliefert haben, bieten inzwi-schen ebenfalls Produkte an, die durch Verarbeitung im Hauptspeicher oder andere Optimierungsmaßnahmen auf Datenbankebene vergleich-bare Geschwindigkeiten erzielen (z. B. IBM Blu, Microsoft SQL-

Nikolaus kasper, aNdré laNdefeld


2

Server 2014, Oracle Database In-Memory). Eine mit SAP HANA vergleichbare Unterstützung durch SAP erfahren diese Produkte jedoch nicht. Dadurch kann deren Potenzial im Zusammenhang mit der NetWeaver-Plattform nur zu einem kleinen Teil genutzt werden. »SAP Business Suite 4 SAP HANA (S/4 HANA)« ist die Bezeichnung für die neue Business Suite, die auf SAP HANA basiert. Eine Unterstützung von alternativen Datenbanken durch SAP HANA ist aktuell nicht vor-gesehen.

Die Autoren begleiten seit 2012 Unternehmen bei der Einführung von SAP HANA. Die in diesem Beitrag dargelegten Überlegungen und Empfehlungen beruhen auf den praktischen Erfahrungen aus diesen Projekten sowie zahlreichen Gesprächen und Workshops zu diesem Thema. Daraus haben sich drei zentrale Themen ergeben, die entschei-dend für ein erfolgreiches Einführungsprojekt sind:

Ö Strategie: Eine Entscheidung für oder gegen eine Einführung von S/4 HANA ist eine IT-strategische Entscheidung, die nicht auf die SAP-Landschaft beschränkt ist, sondern die über die gesamte bestehende bzw. geplante IT-Landschaft betrachtet werden muss. Eine Entscheidung für S/4 HANA bedeutet in der Regel eine umfangreiche Investition und eine enge Bindung an SAP als Soft-warelieferant. Eine Entscheidung gegen S/4 HANA wird langfristig den Umstieg auf ein alternatives Produkt eines anderen Herstellers bedeuten.

Ö Analysemethode: Wir haben beobachtet, dass allgemeingültige Ana-lysedimensionen existieren, die die strategische Entscheidung unter-stützen. Erfolgreich waren prozessorientierte Untersuchungen, die sich an Mehrwerten ausrichten.

Ö Stufenweises Vorgehen: Im Falle einer Entscheidung zugunsten S/4 HANA hat es sich bewährt, die Systemlandschaft nach einem vor-her festgelegten Plan in mehreren Schritten über einen längeren Zeitraum umzustellen. Auf diese Weise können die gefundenen Mehrwerte frühzeitig wirksam werden.


3

Mögliche Business CasesDie Einführung neuer Technologien ist kein Selbstzweck. Aus unserer Projekterfahrung stellen wir beispielhaft einige Szenarien vor, auf deren Basis das Potenzial von SAP HANA untersucht wurde.

Analyse aktueller Transaktionsdaten

In vielen Unternehmen ist die Datenbasis für BI zweigeteilt: Operative Reports und einfache Analysen zu aktuellen Daten erfolgen direkt im Transaktionssystem. Für komplexe Analysen über mehrere Systeme oder längere Zeiträume werden umfangreiche Datenbestände aus dem Transaktionssystem in die BI-Applikation kopiert. Damit verbunden ist notwendigerweise ein Zeitversatz (in der Praxis mindestens mehrere Stunden, manchmal Tage) bei der Bereitstellung der Daten. Wir finden bei unseren Analysen oft fachliche Anforderungen, die nicht erfüllt werden können, weil sie zu komplex und ressourcenhungrig für Analy-sen direkt aus dem Transaktionssystem sind, aber eine Datenaktualität erfordern, die die BI-Applikation nicht liefern kann.Ein leistungsfähiges Analysewerkzeug auf aktuellen Transaktionsdaten würde die Anforderungen erfüllen.

Überwindung technologischer Einschränkungen

Die SAP-NetWeaver-Applikationsplattform basiert auf Konzepten aus den 1990er-Jahren. Damals getroffene Designentscheidungen machen es z. B. nicht leicht, die Anforderungen mobiler Endgeräte zu erfüllen. Im Mobilbereich verwendete Standards für Protokolle und Schnittstel-len erfordern den Einsatz von zusätzlicher Middleware. Das erhöht die Komplexität und verlängert die Antwortzeiten.

Eine Applikationsplattform, die aktuelle Protokolle und Schnitt-stellen von sich aus unterstützt, reduziert die Komplexität und verkürzt die Antwortzeiten.


4

Abbilden neuer Geschäftsprozesse

Viele heute erfolgreiche Unternehmen bemerken, dass bestehende und potenzielle Kunden über Kanäle mit ihnen in Kontakt treten, die ihre bestehende Softwarelandschaft nur unzureichend abdeckt. Die Daten, die Kunden auf diese Weise über sich selbst zugänglich machen, kön-nen nicht verwertet werden.

Eine Integration von live entstehenden Zusatzinformationen (z. B. Verweildauer) kann zielgerichtete Angebote und mehr Abschlüsse er-möglichen.

Praxisbeispiel 1: Information in Echtzeit

Bei einem Paketdienstleister werden mit Großkunden Verträge vereinbart, die als Kalkulationsgrundlage einen vereinbarten »Mix« von Paketen haben. Auf Veränderungen der Zusammensetzung kann der Dienstleister erst reagieren, wenn er Kenntnis davon hat. Aufgrund der großen Datenmenge, die analysiert werden muss, bis eine signifikante Abweichung entdeckt werden kann, benötigt die Aufbereitung in einem »herkömmlichen« SAP BW mehrere Tage und kann auch nur einmal monatlich stattfinden. Der Einsatz von SAP HANA ermöglicht eine raschere Verarbeitung, womit wesentlich schneller auf Veränderungen reagiert werden kann.

Praxisbeispiel 2: Effiziente Entwicklung von komplexen Analysen

Für die Ermittlung des Kundenwertes soll das Kaufverhalten in Bezug auf wie-derkehrende Käufe nach Zeitraum, Kauf unterschiedlicher Produkte, Kauf über unterschiedliche Channels etc. ermittelt werden. Je nach Kontext der Analyse muss dazu nach unterschiedlichen Aspekten aggregiert werden. Im SAP BW kann diese Analyse nicht allein über eine Query abgebildet werden, sondern erfordert ein speziell angepasstes Datenmodell. Mit SAP HANA kann dieses Datenmodell inklusive der erforderlichen Berechnungen virtuell angelegt werden und wird zum Zeitpunkt der Auswertung aus den einzelnen Transaktionen berechnet. Neu hinzukommende Transaktionen können so unmittelbar berück-sichtigt werden – ebenso können Varianten der Analyse rasch und einfach durch Kopie und Abwandlung erzeugt und auch unmittelbar getestet werden, da die Beladung entfällt.


5

ZwischenfazitAus den Beispielen wird klar, dass eine Beschleunigung für sich allein selten wesentlichen Nutzen stiftet. Entscheidend ist, dass der gewon-nene Informationsvorsprung im Unternehmen gewinnbringend oder kostensenkend umgesetzt werden kann. Das erfordert in der Regel auch die Anpassung von Prozessen und weiteren IT-Systemen.

Eine Einführung der SAP-HANA-Technologie muss daher immer im Kontext der Unternehmensprozesse und deren möglicher Verände-rung betrachtet werden.

Der Weg zum ZielDa eine Veränderung von Unternehmensprozessen im besten Fall das Resultat einer Unternehmensstrategie ist, ist es sinnvoll, für die Ein-führung von SAP HANA eine Strategie zu entwickeln. Ausgehend davon können dann die erforderlichen Einzelschritte ermittelt werden. In diesem Abschnitt wird die BI- und HANA-Strategie in die Unter-nehmensstrategie eingeordnet und es wird eine in der Praxis erprobte Methodik zur Strategieformulierung vorgestellt.

Einordnung der BI-/HANA-Strategie in die Unternehmensstrategie

Aus der Praxis heraus ist zu beobachten, dass SAP HANA und BI sowohl fachliche als auch IT-Bestandteile in sich tragen, die sich teil-weise überschneiden (vgl. dazu Abb. 1). Ob nun eine eigene BI- und HANA-Strategie definiert werden soll oder ob die eine als Bestandteil in der anderen aufgeht, muss individuell beantwortet werden. Wesent-lich für den Erfolg ist, dass die getroffenen Festlegungen zur Unterneh-mensstrategie passen.

Wichtig ist auch, auf welcher organisatorischen Ebene die Ausfor-mulierung der Strategie stattfindet (vgl. dazu Abb. 1). Eine Formulie-rung auf untergeordneter Ebene muss Vorgaben aus übergeordneten Ebenen einhalten. Ein Beispiel sind konzernweit vorgegebene Appli-kationen für das Rechnungswesen und das zugehörige Reporting. Soll die Einführung von SAP HANA für das Rechnungswesen untersucht


6

werden, muss das Thema in diesem Fall auf Konzernebene behandelt werden, um erfolgreich zu sein.

Abb. 1: Einordnung der BI- und HANA-Strategie in den stra-tegischen Gesamtkontext von Unternehmen in Anlehnung an Müller-Stewens und Lechner [1]

Unternehmensnetzwerk

Konzern/Teilkonzern

Unternehmen

Unternehmensbereich

Betrachtungsebenen

Fachbereichsstrategien

IT-Strategie

Gesamtstrategie

Strategien je Ebene

BI-Strat.

HANA-Strat.

Vorgehensmodell

Für die Erstellung von IT-Strategien gibt es zahlreiche Vorgehensmo-delle. Wir greifen hier auf ein Modell zurück, das sich in zahlreichen Projekten bei Q_PERIOR bewährt hat. Vom Ansatz her ist es an Tom Gansor et al. [2] angelehnt. Das Modell besteht aus vier Phasen:

Ö Initialisierung Ö Analyse Ö Strategie definieren Ö Umsetzung planen


7

Die Phasen werden sequenziell durchlaufen, definieren Teilergebnisse und legen Inhalte und Werkzeuge nahe. Parallel dazu definieren wir aus unserer Praxiserfahrung vier Themencluster:

Ö strategische Integration Ö Fachlichkeit Ö Technologie Ö Personal und Organisation

Die Themencluster stehen für unterschiedliche Betrachtungswinkel und dienen als Gerüst für eine umfassende Bearbeitung. Die Inhalte der Themencluster werden in allen Phasen behandelt. Abbildung 2 gibt einen schematischen Überblick über das Vorgehensmodell.

Zunächst wollen wir noch kurz auf zwei wichtige Aspekte eingehen:

Ö Das Vorgehensmodell ist offen mit Blick auf Projektmanagement-ansätze und -methoden. Aus unserer Erfahrung ist für die Erstel-lung der Strategie ein klassisches Wasserfallmodell am effizientesten, da das Projekt eine kurze Laufzeit von wenigen Monaten haben wird. Für die nachfolgende Umsetzung sind sowohl klassische als auch agile Methoden gut vorstellbar.

Ö Strategieprozesse werden regelmäßig durchlaufen, die formulierten Strategien und zugehörigen Initiativen zur Umsetzung sollten im-mer wieder überprüft werden. Das Vorgehensmodell kann entspre-chend auch zur Überarbeitung, Qualitätssicherung und für Reviews bestehender Strategien und Umsetzungspläne verwendet werden.


8

Phasen Bei den Projektphasen konzentrieren wir uns auf wesentliche Inhalte und bewährte Werkzeuge, die für alle Themencluster verwendbar sind.

InitialisierungDie Phase »Initialisierung« dient dem Aufsetzen des Projekts und stößt die Vorbereitungen für die Folgephasen an. Wichtige Elemente sind:

Ö Eine präzise Formulierung der Projektziele. Der Projektumfang lässt sich z. B. auf Basis der aktuellen Anwendungslandschaft ent-wickeln. Es sind alle bestehenden und geplanten Anwendungen relevant, für die SAP HANA als Datenbank oder als Anwendungs-plattform infrage kommt. Daraus lassen sich dann die Umfänge aus Sicht von Integration, Fachlichkeit, Technologie sowie Personal und Organisation ableiten.

Ö Erzeugen eines gleichmäßigen und ausreichenden Wissensstands im Projektteam zu SAP HANA und auch den im Projekt vorgesehenen Werkzeugen und Methoden.

Abb. 2: Vorgehensmodell zur HANA-Strategiedefinition

Projektphasen und Ergebnisse je Phase

- Projektdefinition- Kick-off- Wissensaufbau

Projektteam- Kernfragen und

Hypothesen

- Situationsanalyse- Umfeldanalyse- SWOT-Analyse

- Langfristiges HANA-Zielbild

- Business Case- Alternativszenarien

- HANA-Projekt-Programm

Analyse Strategie definieren

Umsetzung planenInitialisierung

Phasenübergreifende Themencluster

Integration Fachlichkeit Technologie Personal u.Organisation


9

Ö Sicherstellen, dass die vorgesehenen Schlüsselpersonen verfügbar sind.

Ö Formulierung von Kernfragen und Hypothesen für die Inhalte der Folgephasen.

Die Erwartungshaltung an das Zielbild sollte zu Projektbeginn bewusst nicht auf ein »Wunschbild« beschränkt werden.

AnalyseZiel der Analysephase ist es, eine Bewertung der derzeitigen Ist-Situati-on des Unternehmens und der IT vorzunehmen. Der Ausgangspunkt ist die Unternehmensstrategie und daraus abgeleitete strategische Er-folgsfaktoren. Aus unserer Erfahrung bietet sich eine SWOT-Analyse an. Die nachfolgenden Tabellen zeigen Beispiele zu Stärken, Schwä-chen, Potenzialen und Risiken einzelner Themen. Im Rahmen eines konkreten Projekts sind die Tabellen natürlich spezifisch zu befüllen.


10

Tabelle 1: Typische Schwächen bestehender Anwendungen und HANA-Potenziale

Themenfeld Typische Schwächen Nutzen-Potenziale der HANA-Einführung

Geschäftsprozesse Eigenentwickelte Pro-zesse oder Erweiterungen müssen neu entwickelt werden.

Beschleunigung, höhere Industrialisierung der BI-Wertschöpfung

(Fach-)Anforderungen Möglicher Verzicht auf gewohnte Erweiterungen und Speziallösungen

Chance, bisher nicht rea-lisierbare Anforderungen zu erfüllen; Nutzungs-möglichkeit von neuem Content

Front-End Zusätzlicher Schulungs- und Supportbedarf

Einsatz mobiler Endgeräte

Datenbereitstellung Geringe Unterstützung durch Dritthersteller

Realtime-Szenarien werden möglich.

Anwendungslogik/ Datentransformation

Noch wenige Standards etabliert

Integration von Simula-tionen und Vorhersagen mit nativer Ausführung auf SAP HANA (PAL, PAK …)

Datenhaltung Weniger Möglichkeit zur Gegenprüfung oder Ar-chivierung, da vieles on the fly berechnet wird

Reduktion der Redundanz

Datenqualität Unklarer, wann Daten-bestände geprüft und freigegeben sind, und ob alle Zwischenstände on-line verfügbar sind

Unmittelbare Sichtbarkeit ermöglicht rasche Kor-rekturen innerhalb des Regelprozesses.

Schnittstellen/ Extraktion/Retraktion

Anbindungen müssen neu eingerichtet werden.

Weniger Schnittstellen/Extraktion

Datenquellen Weniger Datenquellen aufgrund integrierter Datenhaltung

Personal und Organisation

Wenig vorhandenes Know-how im Bereich SQL Script, HANA-Betrieb

Motivation für Mitarbeiter, mit aktuellen Technolo-gien arbeiten zu können


11

Tabelle 2: Typische Stärken bestehender Anwendungen und Risiken einer HANA-Einführung

Themenfeld Typische Stärken Risiken der HANA-Einführung

Geschäftsprozesse Integration von Analysen in Geschäftsprozesse statt starrer Vorgaben

Standardprozesse ändern sich, da Software noch nicht final

(Fach-)Anforderungen Einfache Datenmodelle sind für Fachanwender besser verständlich.

Unterschätzung des Auf-wandes und des Projekt-risikos durch mangelnde Erfahrung

Front-End Kein Ausrollen eines GUI erforderlich, neues Front-End entspricht den An-wendererwartungen

Der Browser wird zentrale Oberfläche; potenzielle Probleme mit unter-schiedlichen Browser-versionen, die für ver-schiedene Applikationen benötigt werden

Datenbereitstellung Berechnungen on the fly und Online-Anbindung ermöglichen Analysen unmittelbar nach Daten-verfügbarkeit im Quell-system.

Bei Ausfall einer on-line angebundenen Datenquelle sind keine Auswertungen möglich; Fehlfunktionen und Insta-bilität bei ungenügender RAM-Ausstattung


Native Ausführung auf SAP HANA (PAL, PAK, BW-Standardtransforma-tionen …)

Fehler durch junges Produkt

Datenhaltung Weniger Persistenz, an-wendungsübergreifende Datenbestände, viele op-timierte Datenhaltungen (für Texte, Graphen …); stark reduzierter Aufwand für Performanceoptimie-rung

Instabilität bei ungenü-gender RAM-Ausstattung

Datenqualität Höhere Granularität, Aktualität, breitere Da-tenbasis


12

Tabelle 2: Typische Stärken bestehender Anwendungen und Risiken einer HANA-Einführung (Fortsetzung)

Themenfeld Typische Stärken Risiken der HANA-Einführung


Nach Störungen: Wieder-anlauf bei online ange-bundenen Quellen pro-blemlos; Verwendung von aktuellen Standards (z. B. HTML5, JavaScript)

Fehler durch junges Produkt. Quellsystem-belastung in geringerem Maße planbar

Datenquellen Verarbeitung von Mas-sendaten (strukturiert und unstrukturiert)

Mehr inkompatible Schnittstellen, da Uni-code verpflichtend ist

Personal und Organisation

Know-how-Aufbau und Anpassung der Organisa-tion gelingen nicht.

Die in den vorhergehenden Tabellen vorgestellten Themenfelder kön-nen auch als Grundlage für die Beschreibung des Ist-Zustandes je An-wendung verwendet werden.

Zielbild und Strategie definierenIn dieser Phase wird das Zielbild für den SAP-HANA-Einsatz erarbei-tet und mit einem Business Case unterlegt. Die in den Themenclustern »Fachlichkeit« und »Technologie« vorgestellten Tabellen helfen, die relevanten Kosten- und Nutzenbestandteile zu ermitteln. Es hat sich bewährt, auch alternative Zielbilder mit einzubeziehen und zu bewer-ten, um flexibel gegenüber Veränderungen in den Randbedingungen zu sein.

Grundsätzlich sind Zielbilder von keiner SAP-HANA-Einführung bis hin zu einer vollumfänglichen Einführung denkbar. Ganz allgemein kann ein mögliches Zielbild anhand von drei Eigenschaften der Ziel-Anwendungslandschaft beschrieben werden:

Ö Die Breite beschreibt, wie viele Anwendungen betroffen sind – un-abhängig von der Art der Einführung, also ob nur die Datenbank migriert wird oder umfangreiche Optimierungen vorgenommen werden.


13

Ö Die Tiefe beschreibt, in welchem Umfang Optimierungsmöglich-keiten (fachlich und technisch) genutzt werden: Das kann von einer rein technischen Migration über eine selektive Optimierung bis zu einer Neukonzeption der Anwendungen gehen.

Ö Wenn die betrachtete Organisation aus mehreren Organisations-einheiten besteht, beschreibt die Reichweite, wie viele Gesellschaften betroffen sind.

Initiativen definieren Nachdem nun neben dem Ist-Zustand auch der Zielzustand beschrie-ben wurde, befasst sich diese Phase mit der Planung der notwendigen Schritte, um vom Ist-Zustand zum Ziel zu kommen. In der Praxis ent-steht ein Mehrstufenplan über mehrere Jahre. Die Gründe dafür sind:1. Monetäre und kapazitative Engpässe für eine Umsetzung mit einem

kurzen Umsetzungshorizont.2. Unsicherheit über den aktuellen Reifegrad des Zielportfolios an

Soft- und Hardware. 3. Bestehende Projekte müssen noch finalisiert werden.4. Wenig oder keine Erfahrung der Beteiligten mit dem Hard- und

Softwarezielportfolio. 5. Unsicherheit, ob die angedachte Zielorganisation und die neuen

Rollen und Verantwortlichkeiten »funktionieren«.

Im Fall einer HANA-Einführung sind die Punkte 2 und 4 besonders häufig anzutreffen. Tabelle 3 zeigt beispielhaft eine Analyse zu Punkt 4, wie mit unterschiedlichen Konstellationen umgegangen werden kann.


14

Tabelle 3: Matrix Reifegrad Soft-/Hardware zu Erfahrung in der eigenen Organisation

Reifegrad Soft-/Hardware

Erfahrung in der eigenen Organisation

Niedrig Hoch

Hoch Ö Größere Einzelprojekte Ö Projektmanagement und Lösungsverantwortung extern Ö Interner Wissensaufbau

Ö Größere Einzelprojekte Ö Projektmanagement und Lösungsverantwortung intern Ö Externe Skills bei Engpässen

Niedrig Ö Kleine Einzelprojekte, ggf. mit agilem Vorgehen kom-biniert Ö Projektmanagement und Lösungsverantwortung extern Ö Interner Wissensaufbau

Ö Kleine Einzelprojekte ggf. mit agilem Vorgehen kom-biniert Ö Lösungsverantwortung intern Ö Externe Skills bei Engpässen

Unbekannt Ö Kleine, agile »Forschungs-projekte«. Ziel: Unsicherheit eliminieren und Erfahrung sammeln. Ö Projektmanagement und Lösungsverantwortung extern Ö Interner Wissensaufbau

Aus dem Umfang der zu erwartenden Projekte stellt sich die Frage, wie die einzelnen Initiativen der HANA-Roadmap gesteuert werden sollen. Möglichkeiten sind:

Ö Ein HANA-Großprojekt – die Initiativen sind Teilprojekte. Ö Ein HANA-Projektprogramm – die Initiativen sind einzelne Pro-jekte des Programms.

Ö Die HANA-Initiativen sind autarke Projekte des (IT-)Projektport-folios des Unternehmens.

Aus unserer Erfahrung ist es vorteilhaft, ab einer gewissen Größe ein Projektprogramm zu entwerfen. Zielkonflikte, Abhängigkeiten und Synergien können so am besten gesteuert werden. Im Rahmen des Pro-jektprogramms kann zudem früh Erfahrung mit der Zielorganisation,


15

neuen Rollen und Verantwortlichkeiten gesammelt werden. Potenzielle Führungskräfte können sich in Schlüsselpositionen des Programms beweisen.

ThemenclusterDie Themencluster umfassen verschiedene Teilbereiche. Abbildung 1 dient als Anhaltspunkt für die Teilbereiche des Clusters Integration, Abbildung 3 ist der Ausgangspunkt für die Gliederung der Gebiete

Abb. 3: Schema-tische Darstellung zur Struktu-rierung der Themenclu-ster

bestimmen/fordern

ermöglichen/ gewährleisten

Legende:

Kunden Technologie, SAP, HANA

Gesetzgeber Aktionäre/ KapitalmarktWettbewerber

Unternehmensumwelt (Teilausschnitt)

Personalmarkt(IT-)Lieferanten Kooperations-partner

Über-/untergeordnete Unternehmen

Strategie

Unternehmen (IT-Perspektive)

Personal u. Organisation

Geschäfts-prozesse

(Fach-)Anforderungen

Anwendungen

Systeme/Infrastruktur

Front-End/ Datenbereitstellung


Datenhaltung/-qualität/-architektur


Datenquellen

beeinflusst


16

Fachlichkeit, Technologie sowie Personal und Organisation. In welcher Tiefe die Teilbereiche behandelt werden, wird im Rahmen der Projekt-initialisierung festgelegt werden.

Strategische IntegrationDer Themencluster »Strategische Integration« soll sicherstellen, dass die Durchführung des SAP-HANA-Strategieprojekts hinreichend in die bestehenden Strategieprozesse eingebettet ist. Ebenso soll gewähr-leistet werden, dass die Projektergebnisse konsistent mit der Unterneh-mensstrategie sind.

Wesentliche Punkte sind: Ö Integration der SAP-HANA-Strategie in die Unternehmensstrategie (»horizontal«)

Ö Integration der SAP-HANA-Strategie in die über-/untergeordneten Ebenen (»vertikal«)

Ö Stimmigkeit des HANA-Projektprogramms mit weiteren Vorhaben und geplanten Projekten im Unternehmen

FachlichkeitDer Themencluster »Fachlichkeit« setzt auf den Geschäftsprozessen auf. Es wird untersucht, wie gut die Anforderungen durch die IT-Anwendungen abgedeckt werden. Durch die spezifischen Stärken von SAP HANA liegt der Schwerpunkt auf den Prozessen, die mit der Informationsversorgung im Unternehmen einhergehen. Ansatzpunkte sind:

Ö Die Verkürzung von Durchlaufzeiten und die Verminderung von nicht werthaltigen manuellen Tätigkeiten wie etwa Datenbeschaf-fung oder Datenabgleich.

Ö Eine Verbesserung der Datenqualität durch eine höhere Datenak-tualität, eine höhere Detaillierung oder eine breitere Datenbasis durch eine höhere Integration von bis dato separat vorgehaltenen Datenquellen.


17

Ö Die Vereinfachung von Prozessen: Durch SAP HANA kann eine höhere Einheitlichkeit der Datenbasis erreicht werden und oft ent-fallen Schnittstellen sowie redundante Datenhaltung. In der Folge gibt es für die darauf aufbauenden Prozesse weniger Fehlerquellen.

Aus den konkreten Prozessverbesserungen gehen neue Anforderun-gen an die IT-Anwendungen hervor. Dabei werden zwei Situationen verglichen – der Status quo ohne SAP HANA und die Abdeckung im Zielbild mit SAP HANA. Tabelle 4 zeigt eine Matrix zur kombinierten Betrachtung des Status quo mit dem Zielbild. Den einzelnen Feldern können fachliche Kosten- und Nutzeneffekte zugeordnet werden:1. Nutzenneutral2. Nutzeneffekt durch eine bessere Erfüllung der Anforderungen,

durch mehr umgesetzte Anforderungen oder durch Einsparung ob-soleter Anforderungen

3. Nutzeneffekt durch eine qualitative Verbesserung der Umsetzung 4. Nutzeneffekt durch eine Verschlankung der Anwendungen5. Kosten für die Umstellung auf HANA (Migrationskosten bzw. Ko-

sten zur Anpassung in Umsetzung befindlicher/geplanter Projekte).

Die Matrix liefert damit auch Input für die fachlichen Positionen der Kosten-Nutzen-Rechnung.

Tabelle 4: Gruppierung von Anforderungen

Anforderung im Status quo ohne HANA

Anforderung im Zielbild mit HANA

Keine Umsetzung mit HANA

Anforde-rung ohne qualitative Verbesserung mit HANA umgesetzt

Anforderung mit qualita-tiver Verbes-serung mit HANA umge-setzt

Anforderung obsolet durch HANA

Umgesetzte Anforderun-gen

1) 5) 3), 5) 4)


18

Tabelle 4: Gruppierung von Anforderungen (Fortsetzung)

Anforderung im Status quo ohne HANA

Anforderung im Zielbild mit HANA

Keine Umsetzung mit HANA

Anforde-rung ohne qualitative Verbesserung mit HANA umgesetzt

Anforderung mit qualita-tiver Verbes-serung mit HANA umge-setzt

Anforderung obsolet durch HANA

Nicht umge-setzte Anfor-derungen. (technisch nicht umsetz-bar)

1) 2) 2), 3) 2)

Nicht um-gesetzte Anforderun-gen (nicht wirtschaftlich, da Kosten > Nutzen)

1) 2) 2), 3) 2)

TechnologieDer Cluster »Technologie« befasst sich mit allen Aspekten auf der Ebe-ne der Applikationen und den darunter liegenden Systemen bzw. der unterliegenden Infrastruktur. Für die technische Perspektive werden die Anwendungen nun auf der Ebene ihrer Komponenten betrachtet. Kern ist die Frage, in welcher Art die Komponenten im Zielbild imple-mentiert werden sollen. Die Skala reicht von keinem Einsatz über eine technische 1:1-Migration bis hin zu einer optimierten Reimplemen-tierung. Möglich ist auch, dass es Situationen gibt, in denen Anwen-dungsbestandteile obsolet werden. Tabelle 5 zeigt ein Beispiel für eine Strukturierung. In den Zeilen werden die Anwendungskomponenten aufgelistet – sowohl bereits umgesetzte Bestandteile als auch geplante und neue Komponenten. In den Spalten sind verschiedene Möglich-keiten zur Umsetzung angeführt.


19

Den einzelnen Feldern der Tabelle können technische Kosten- und Nutzeneffekte zugeordnet werden: 1. Nutzenneutral2. Technischer Nutzen durch die Optimierung3. Nutzen durch entfallende Anwendungskomponenten

(»Konsolidierungseffekt«)4. Kosten für die Migration auf HANA5. Kosten für die Optimierung auf HANA

Die Matrix liefert Anhaltspunkte für die technischen Positionen der Kosten-Nutzen-Rechnung der HANA-Einführung. Bei einer gesamt-haften Kosten-Nutzen-Betrachtung gemeinsam mit der fachlichen Perspektive müssen doppelte Posten – etwa Migrationskosten – heraus-gerechnet werden.

Tabelle 5: Gruppierung der Anwendungen/Anwendungskomponenten

Anwendungskompo-nente

Anwendungskomponente im Zielbild

Kein Einsatz von HANA

1:1- Migration auf HANA

Optimierung auf HANA

Obsolet durch HANA

Auf Nicht-HANA-System umgesetzt

Front-End 1) 1), 4) 2), 5) 3)

… … … … …


1) 1), 4) 2), 5) 3)

Umsetzung auf Nicht-HANA-System in Durchführung/in Planung

1) 1), 4) 2), 5) 1)

Front-End 1) 1), 4) 2), 5) 1)

… … … … …


20

Personal und OrganisationDer Themencluster »Personal und Organisation« betrachtet Rollen und Verantwortlichkeiten sowie die dazu benötigten Kompetenzen. Daraus können sich auch neue Anforderungen an die Organisation er-geben. Werden neue Prozesse oder fachliche Anforderungen umgesetzt, können auch personelle und organisatorische Änderungen erforderlich sein.

Wir beobachten, dass manche relevanten Fertigkeiten am Arbeits-markt schwer zu bekommen sind. Daraus kann sich ergeben, dass be-stimmte Kompetenzen im Unternehmen strategisch aufgebaut werden oder gezielt mit externen Ressourcen abgedeckt werden müssen.

Themen und Erfahrungswerte zu Technologie, Personal und OrganisationIm vorherigen Kapitel wurde eine Methodik zur Definition und Um-setzung einer Einführungsstrategie vorgestellt. In unseren Projekten begegnen wir Themen im Bereich Fachlichkeit, Technologie sowie Personal und Organisation, die oft ein hohes Gewicht in der Entschei-dungsfindung haben. Einige dieser Themen stellen wir hier vor.

Themencluster »Fachlichkeit«

Nutzung von zusätzlichen OptimierungenRund um die Kernfunktionalität werden von SAP einige Zusatzpro-gramme oder Erweiterungen angeboten. Diese sind z. T. kostenpflich-tig und werden im »Paket« mit anderen Funktionalitäten vertrieben. Für Anwender, die die »Integrierte Planung« (IP) verwenden, wird beispielsweise das »Planning Applications Kit« (PAK) angeboten, das zusammen mit »Business Planning and Consolidation« (BPC, aktuell in der Version 10.1) gebündelt wird. Durch die lizenztechnische Bün-delung mit anderen Funktionen ist es interessant, sich auch diese als »Zusatznutzen« genauer anzusehen.


21

Optimierung der DatenhaltungSAP HANA ermöglicht es, über »Smart Data Access« mehrere In-stanzen bzw. Installationen sehr effizient miteinander zu verbinden. In manchen Fällen kann man damit eine Replikation von großen Da-tenmengen zwischen ERP und BW verhindern, was die Kosten senkt. Parallel ist es sinnvoll, auch andere Replikationstechnologien oder ETL-Werkzeuge zu betrachten, die eine Loslösung von bisher verwen-deten, klassischen Extraktionstechnologien ermöglichen, z. B. »SAP Landscape Transformation Replication Server« (SLT).

Änderungen in der BI-Architektur – Berechnung »on the fly«Im Vergleich zu traditionellen Datenbanken kann in SAP HANA auch mit umfangreichen Datenmengen »on the fly« gerechnet werden. Eine vielschichtige Layerarchitektur ist nicht mehr erforderlich. Selten ge-brauchte große Tabellen müssen nicht mehr repliziert werden, sondern können mit »Smart Data Access« eingebunden werden.

Reporting im OLTP-SystemEine sehr interessante Architekturvariante ist es, operatives Reporting direkt aus dem Transaktionssystem durchzuführen, wenn dieses mit SAP HANA läuft. Für den Anwender ergibt sich der Vorteil, dass alle Buchungen sofort im Reporting sichtbar sind, und er kann – je nach gewählter Oberfläche – den vollen Komfort eines analytischen Werk-zeugs nutzen. In einigen Fällen wird das »eingebettete« BW ein sepa-rates BW-System vollständig ersetzen können.

Themencluster »Technologie«

Für viele Unternehmen ist die Einführung von SAP HANA der Ein-stieg in »große« In-Memory-Datenbanken. Diese verhalten sich anders als konventionelle Datenbanken und der Betrieb muss gelernt werden.


22

Neue Prozesse durch neue LieferantenEs besteht die Möglichkeit, SAP HANA als Appliance zu beziehen. Der gewählte Hardwarelieferant stellt ein fertig vorkonfiguriertes Sys-tem bereit und übernimmt gegebenenfalls auch die Wartung. Es kann sein, dass der Lieferant zum ersten Mal im Unternehmen tätig ist und die Prozesse z. B. rund um eine vollständige Ersatzteilversorgung neu sind. Da SAP HANA oft als systemkritische Ressource eingesetzt wird, ist es notwendig, im Problemfall gut laufende Prozesse zur Problembe-hebung zu haben.

Bereitstellung temporärer RessourcenBei SAP HANA bestimmt die erforderliche Größe des Hauptspeichers weitgehend die anderen Systemparameter, wie die Anzahl der CPUs, den benötigten Platz im Storage etc. Wird z. B. im Zuge der Migration oder von Systemkopien temporär mehr Platz benötigt, kann Haupt-speicher in der Regel nicht so einfach »dazugehängt« werden, sondern es müssen Server aufgerüstet bzw. der Cluster muss erweitert werden. Das erfordert Vorausplanung bei der zur Verfügung stehenden Infra-struktur.

Leistungsfähiges StorageAls In-Memory-Technologie ist SAP HANA darauf angewiesen, kon-tinuierlich alle Änderungen auf SSD oder Festplatte abzulegen, damit ein Stromausfall keinen Datenverlust bedeutet. Das stellt hohe An-forderungen an die Leistungsfähigkeit des Storage, die die Appliance selbst oder das Rechenzentrum als Infrastruktur zur Verfügung stellen muss.

Bereitstellung von NetzwerkbandbreiteAufgrund der Leistungsfähigkeit kann SAP HANA in kurzer Zeit große Datenmengen aufnehmen. Für eine Point-in-Time-Rücksiche-rung bei Hardwareversagen müssen die Online-Voll- und Log-Siche-rungen zeitnah erfolgen. Je nach Frequenz der Vollsicherungen (ein 12-Stunden-Rhythmus ist nicht unüblich) und Ladeaktivität müssen mehrere Terabyte pro Tag transferiert werden.


23

CloudSAP HANA und speziell S/4 HANA ist auf einen Betrieb in der Cloud ausgerichtet, ein Betrieb on premise ist aber auch möglich. Da aber wie oben angeführt, einige Herausforderungen an die Infrastruktur entste-hen, ist es gut, wenn die Nutzung einer Cloudlösung mit in Betracht gezogen wird. Infrastrukturthemen könnten so vollständig an den Clouddienstleister delegiert werden.

Themencluster »Personal und Organisation«

Wir haben bei unseren Projekten beobachtet, dass es für einen er-folgreichen Start wichtig ist, sich mit den Folgen einer möglichen Einführung von SAP HANA im Bereich Personal und Organisation von Beginn an zu beschäftigen, noch bevor Vorentscheidungen zu den Themengebieten Outsourcing oder Cloud gefallen sind.

Know-howDer Betrieb von SAP HANA und die Entwicklung von optimierten Anwendungen erfordern anderes Wissen als bisher in einem »klas-sischen« SAP Competence Center (SAP CC). Neben dem Betrieb einer In-Memory-Datenbank sind Kenntnisse in Programmiersprachen (SQL Script, Java Script) und Standards (HTML5) erforderlich, die in einem SAP CC oft nicht vorhanden sind. Diese Kenntnisse sind aber durchaus in anderen Abteilungen oder Bereichen der IT zu finden. Ist das nicht der Fall, dann könnte auch ein gezieltes Outsourcing einzel-ner Rollen sinnvoll sein.

Organisation des BetriebsBedingt durch die Vorgaben der IT-Revision ist heute eine konsequente Aufteilung der Berechtigungen und der Verantwortung im Betrieb in Applikationsbetreuer, SAP-Basisbetreuer und Datenbankbetreuer notwendig. Bei traditionellen Systemen funktioniert dies gut und man kann auch Effizienzsteigerungen durch Synergieeffekte erzielen.


24

Mit der engen Verzahnung von Applikationslogik in Front-End, Back-End und Datenbank müssen alle diese Bereiche überwacht und bei einer möglichen Fehlfunktion analysiert werden. Das erfordert eine gut funktionierende Zusammenarbeit und auch ein gemeinsames technisches Verständnis. Je nach Applikation ist dieses Zusammenspiel durchaus komplex, sodass ein »Universalist«, der für viele Applikati-onen verantwortlich ist, das kaum leisten kann. Wir raten daher dazu, rechtzeitig bei Problemen im Betrieb einen Applikationsanalysten hin-zuzuziehen.

Organisation der EntwicklungMit SAP HANA gleicht sich auch der Entwicklungsprozess dem üblichen »Standardprozess« an. Dass ein ABAP-Entwickler allein sämtliche Aspekte einer Applikation (Front-End, Applikations-Back-End, Datenbank) im Alleingang entwickeln kann, ist außerhalb der SAP-Welt eher unüblich. Üblich ist vielmehr die Zusammenarbeit von Front-End-Designern und -Entwicklern mit spezialisierten Back-End- und Datenbankspezialisten.

In diesem Zusammenhang raten wir, speziell agile Management-methoden in Betracht zu ziehen. Diese sind im SAP-CC-Umfeld noch vergleichsweise wenig üblich, an anderen Stellen jedoch oft schon jah-relang erfolgreich im Einsatz.

Rolle des BW-KoordinatorsDurch die vielen Möglichkeiten, die eine Applikationsentwicklung mit SAP HANA hat (Logik im Front-End, Back-End und Datenbanknä-he, Reporting direkt auf Transaktionstabellen statt in einem separaten DWH etc.), besteht die Gefahr, dass statt eines konsistenten und koor-dinierten Vorgehens das Reporting in einzelne Applikationen zerfällt, die zwar für sich selbst fachlich in Ordnung sind, aber übergreifende Analysen mehr zufällig als geplant ermöglichen.

Die Koordination und Konsistenz der Abbildung sollte daher mit organisatorischen Mitteln durch einen BW-Koordinator durchgesetzt werden. Mit sorgfältig durchdachten Nutzungskonzepten und Projekt-vorgehen können die Zusatzaufwendungen klein gehalten werden.


25

Literatur[1] Müller-steweNs; lechNer: Strategisches Management – Wie strategische Initiativen zu

Wandel führen. 4. Aufl. Stuttgart: Schäffer-Pöschel, 2011, S. 32–34

[2] GaNsor, toM et al.: Von der Strategie zum Business Intelligence Competency Center (BICC): Konzeption – Betrieb – Praxis. TDWI, The Data Warehousing Institute. 1. Aufl. München: Hanser, 2010, S. 75


26

ZusammenfassungDie Entscheidung über eine Einführung von SAP HANA hat viele beeinflussende Faktoren. Wir ha-ben gezeigt, dass etablierte Vorgehensmodelle zur Entscheidungsfindung gut geeignet sind, wenn sie umfassend genug angewendet werden. Die Analyse-dimensionen Integration, Fachlichkeit, Personal und Organisation sowie Integration ermöglichen es, die Aufgabe zu strukturieren. Zahlreiche Praxisbeispiele für Einflussgrößen einer SWOT-Analyse helfen, die richtigen Analysekriterien auszuwählen und einen vollständigen Blick zu erhalten.

Als Resultat dieser Vorgehensweise steht – im Fall einer positiven Entscheidung – eine Roadmap bzw. ein Programm für eine ökonomische und Nutzen bringende Einführung von HANA zur Verfügung.

Documents

SAP-HANA-Strategie: Vorgehen, Inhalte und · PDF fileSAP-HANA-Strategie: Vorgehen, Inhalte und Erfahrungswerte 3 Mögliche Business Cases Die Einführung neuer Technologien ist kein