Aufgrund unserer Erfahrung haben wir die folgenden drei Hauptthemen als Kostentreiber identifiziert:

SAP Architektur

Leider zeigt sich aus der Erfahrung, dass häufig schon mit dem ersten SAP R3 Projekt grundlegende Architekturfehler begangen werden. Diese Fehler werden dann mit jedem weiteren Projekt noch weiter ausgebaut und die Nachfolgekosten steigen und steigen. Hier spielt leider auch der gesamte SAP Beratungsmarkt mit. Von Aussen als Nicht-SAP-Berater im SAP Umfeld Beratungsleistungen anzubieten ist ein Ding der Unmöglichkeit. Spricht ein Berater nicht im SAP Dialekt, hat er von Anfang an keine Chance. So schützt sich die SAP Community gegen Einflüsse von aussen.

Als CC-Leiter ist es wichtig mit einem kritischen Blick die Optimierung gezielt und nachhaltig zu steuern. Oft fehlt es allerdings an ausreichend Erfahrung und Ressourcen. Die Komplexität von SAP R3 hat  dazu geführt, dass die meisten Kunden bezüglich Nutzung der Technologie  und Architektur eigentlich bei SAP R3 Release 3.0 (von vor  13 Jahren) stehen geblieben sind. Die Evolution von SAP R3 aber ist enorm. Die Frage ist, ob die Firmen gut daran taten, der Entwicklung zu folgen – denn die hohe Komplexität führt zu einer gutgläubigen Abhängigkeit der Kunden. Es ist bekannt, dass auch SAP selbst mit der Komplexität zu kämpfen hat – SAP ABAP versus SAP Java, Strategiewechsel des Topmanagements etc.

Dabei ist es eigentlich ganz einfach. Wir als Optimierungsspeziallisten haben eine Methode entwickelt, um die Potenziale zu identifizieren. Wir analysieren die Architektur und das Konzept, die Implementierung und den Betrieb. Haben wir erst einmal die neuralgischen, zu optimierenden SAP Architektur Punkte identifiziert, können wir in die darunterliegende Ebene der SAP Infrastruktur und in die darüberliegende Ebene SAP ALM (SAP Application Lifecycle Management) eintauchen.

SAP Infrastruktur

Es ist immer wieder eindrücklich zu sehen, wie sich die SAP-Komplexität über die Jahre entwickelt hat. Wir analysieren alle Server, die für SAP im Einsatz stehen und hinterfragen auch wie diese Server genau genutzt werden. Nach unserer langjährigen Erfahrung wird in fast allen Fällen die SAP Infrastruktur zu aufwendig aufgebaut und in der Konsequenz zu teuer betrieben. Zusätzlich haben wir festgestellt, dass sich gezielte Optimierungen bei den SAP-Lizenzen, der Wartung und beim SAP Betrieb ebenfalls lohnen.

SAP Application Lifecycle Management

Es ist für unsere Kunden eine echte Herausforderung, neben dem laufenden Betrieb parallel noch Implementierungsprojekte und Upgrades zu managen. Auch hier agiert SAP geschickt und lanciert entsprechende Methodik-Initiativen wie in der Vergangenheit Accelerated SAP (ASAP), und aktuell mittels Run SAP. Aus unserer Erfahrung sind es aber oft genau diese Werkzeuge, die mehr der SAP als dem Kunden nützen und die für wieder höhere Kosten verantwortlich sind. Hier lohnt es sich, genau zu analysieren, welche Tools tatsächlich dem Kunden helfen, und deren Einsatz gezielt zu optimieren um die externen Beratungskosten und Wartungskosten zu managen.

SAP Kurzanalyse / SAP Quick-Check – bis zu 30% Kosten sparen

Während unserer langjährigen Erfahrung in der Beratung von SAP Betrieben und SAP Projekten haben wir gelernt, wo die neuralgischen Punkte liegen und können diese mit einer Kurzanalyse bzw. einem Quick-Check identifizieren. Erfahrungsgemäss können wir ohne viel Aufwand für SAP Kunden eine Kostenreduktion von 10-30% erzielen. Wir analysieren aber nicht bloss, sondern unterstützen unsere Kunden bei der Umsetzung der erkannten Potenziale. Da wir voll und ganz für den Erfolg unserer Kunden einstehen, sind für uns auf Wunsch auch erfolgsorientierte Vereinbarungen ein Thema.

All diese Systeme führen tendenziell zu Kostensteigerungen bei den SAP Gesamtlösungen. Aber in vielen Fällen müsste der Kunde die empfohlenen Lösungen gar nicht implementieren, da er sie nicht voll, bzw. oft überhaupt nicht nutzt. Genau hier liegt das grösste Potential in der gesamtheitlichen SAP Optimierung, nämlich in der allem zu Grunde liegenden SAP Architektur.

Gegen die Erhöhung von SAP Wartungskosten gab es vor zwei Jahren heftige Proteste. Die Wartung ist aber nur ein kleiner Kostenanteil im Gesamten. Warum wehren sich Firmen oder Vereinigungen nicht systematisch und konsequent gegen den ständigen und massiven Kostenanstieg bei SAP-Systemen? Wahrscheinlich sind sich die meisten Kunden der Optimierungsmöglichkeiten von SAP gar nicht bewusst. In der Optimierung von SAP Systemen steckt ein gewaltiges Sparpotenzial. Man muss es nur aufspüren und die neuralgischen Punkte identifizieren. Interessant ist, dass sich niemand den Themen SAP Optimierung und SAP Kostenregulierung so richtig annehmen will. User-Gruppen tauschen primär fachliche Erfahrungen aus und sind meist wenig auf die betriebswirtschaftliche und unternehmerische Optimierung von SAP-Systemen fokussiert.

Die Interessen innerhalb der SAP Community ermöglichen es, die Kosten hoch zu halten. Dem Softwarehersteller und den SAP Dienstleistern kann das nur recht sein. Unter dem Vorwand der Kostenregulierung liefert SAP immer weitere Produkte und Methoden zur „SAP Optimierung“. Oft wird leider genau das Gegenteil erreicht – die SAP Betriebskosten schnellen zusätzlich in die Höhe. Das Hauptproblem liegt im Vorhandensein des „SAP Ökosystems“. Die verschiedenen Player stehen in regelmässiger Wechselwirkung zueinander. Sie generieren gegenseitig neue Aufträge und sichern so ihre Existenz. Alle wollen auf den Zug aufspringen. Je mehr Konzepte und Lösungen SAP auf den Markt bringt, desto mehr Arbeit gibt es für die Nutzniesser des Ökosystems. Aber ist das auch das Beste für den Kunden? Fakt ist, die Investitions- und Betriebskosten von SAP werden immer weiter gesteigert. Bei einer Kostenanalyse wird SAP  sozusagen mit SAP verglichen, womit auch sonst. Auf diese Weise können neue Kostentreiber generiert werden. Aufgrund der Komplexität der SAP Systeme haben viele Kunden den Überblick verloren und geraten in eine immer grösser werdende Abhängigkeit von SAP. Den Empfehlungen der SAP Community hat man als Nicht-Experte sowieso nicht viel entgegenzusetzen. Teilweise begegnet man in der SAP Beratungswelt sogar einer gewissen Arroganz. Viele schützen ihr Knowhow dadurch, dass sie z.B. für Customization keinerlei Spezifikationen / Dokumentation liefern.  Diese Praxis ist im SAP Beratungsumfeld anscheinend Gang und Gebe. Im Non-SAP Bereich sind solche Arbeitspraktiken schlicht unprofessionell!

Beispiel eines von SAP angeheizten Kostentreibers ist die Run SAP Methodik, eine der neueren Initiativen von SAP. Zertifizierte Beratungsleistungen, meist auf Basis von SAP Technologien, werden hier an die SAP Kunden gebracht. Geschickt bringt SAP den Kunden dazu, die Run SAP Methodik zum Einsatz zu bringen und Investitionen zu tätigen. Betrachtet man die Run SAP Methodik jedoch kritisch, kann man relativ schnell erkennen, dass Run SAP primär SAP selbst (SAP als dem ERP-Standardsoftwarehersteller schlechthin) hilft, ihre Kundenbasis in Bezug auf SAP Standard Changes im Griff zu behalten. SAP integriert neue Konzepte für die Verwaltung und Steuerung von Eigenentwicklungen (natürlich nur ABAP) in den SAP Solution Manager. Unserer Meinung nach wären jedoch Impact-Analysen des SAP Customizing viel wichtiger. Bekanntlicherweise wird ja der grösste Teil einer SAP Umsetzung  mittels SAP Customizing vollzogen.

Fazit

Das Optimierungspotential in SAP-Umfeldern ist enorm. 10 – 30 % Kostensenkung sind bei den meisten SAP Anwendern realistisch. Die SAP Community schützt sich gegenseitig und ist an einer Optimierung oft gar nicht interessiert.

Die SAP Evolution von SAP R/3

1. Paketsoftware: Vier IBM Softwarespezialisten gründen SAP mit einem der ersten transaktionalen Modelle auf Mainframebasis,  SAP R/2 ist geboren. Anfänglich ausschliesslich mit Modulen für das Rechnungswesen, sukzessive werden Module für neue Bereichen wie Logistik  in der von SAP selbst entwickelten Programmiersprache ABAP entwickelt.

2. Client Server: Die Client-Server Welle schwappt über zu SAP. SAP portiert R/2 zunächst auf IBM AS/400. Das System läuft allerdings nie zufriedenstellend. In einem 2. Schnellversuch wird erfolgreich auf HP Unix portiert. Daraus ergibt sich die ABAP-basierte Client Server Applikation SAP R/3. Diese verfügt gegenüber R/2 über eine grafische Benutzeroberfläche.
Wie schon für R/2 werden sukzessive neue Business-Funktionalitäten dazu entwickelt und es entstehen weitere Releases bis SAP R/3- Release 3.0. SAP R/3 besteht mittlerweile aus einer Vielzahl von Modulen, die in die drei Hauptmodule Rechnungswesen, Logistik und Human Resources zusammengefasst werden können.

3. Redundante Systeme: Mit SAP R/3 Rel. 3.0 hat es SAP geschafft, Markttrendsetter zu sein. Der Begriff ERP wird schon fast ausschliesslich ein Synonym für SAP R/3. Grossfirmen setzen immer mehr auf SAP R/3. Durch das Wachstum und den Grosseinsatz und die damit die hohen Anforderungen an die Skalierbarkeit wachsen die Herausforderungen an die grundlegende Technologie und Business-Funktionalität. Um den gestiegenen Erwartungen gerecht zu werden, lanciert SAP ALE (Application Link Enabling). Somit hat SAP als einer der ersten Paketsoftwarehersteller das Konzept der kontrollierten Redundanz in seiner Software-Suite institutionalisiert.

4. Internet: Es herrscht Internet-Euphorie und SAP hat auch eine technologische Antwort auf diesen Trend: SAP R/3 Rel. 3.1 mit SAP ITS (Internet Transaction Server). SAP ITS ist in der Lage, das SAP interne SAP GUI-Protokoll in http zu konvertieren und umgekehrt. So kann von einfachen HTML-Seiten direkt in die Business-Applikation SAP R/3 gesprungen werden.

5. SAP Komponentenarchitektur: Um neue, trendy Applikationen in die Plattform integrieren zu können, versucht SAP mit SAP R/3 – Release 4.0 den starken SAP Basis-Kernel vom SAP Applikations-Kernel zu trennen. Ebenso wird auf der Ebene der Applikationen eine Trennung vorgenommen. Das gesamte HR-Modul wird ABAP-technisch vom Rest der Hauptmodule Rechnungswesen und Logisik abgekoppelt. Die Kommunikation zwischen den Applikationen basiert ab diesem Zeitpunkt nur noch auf SAP ALE.
Die Trennung der SAP Basis ist dann auch die Grundlage für weitere nicht mehr rein als Enterprise Resource Planning einzustufende Business-Funktionalität: SAP BW (Business-Warehouse) und SAP CRM (Customer Relationship Management). SAP ist nun zwar immer noch auf ABAP basierend, aber bestehend aus verschiedenen ABAP-Applikations Komponenten – ABAP heterogen!

6. Single Sign On: SAP erkennt schnell, dass das Anmelden der Benutzer an nunmehr verschiedenen Systemen als Konsequenz der ABAP-Heterogenität beseitigt werden musste. So lancierte SAP mit SAP R/3 – Release 4.5 einen ABAP-basierenden Workplace. Dieser stellt auf Basis SAP GUI einen Single-Sign-On zur Verfügung, welcher die Absprünge in die unterschiedlichen ABAP-Produktivsysteme steuert.

7. SAP Portal: Der gesamte Markt spricht von Portalen und SAP kann mit seinem „ABAP-basierenden Portal Workplace“ den modernen Ansprüchen an Portalen absolut nicht genügen.
So kauft SAP Top-Tier, welche zum Zeitpunkt bereits eine auf dem SAP HTML-GUI basierende Schnittstelle entwickelt hat.
Mit dieser Akquisition übernimmt SAP zum ersten Mal eine nicht ABAP-basierende Technologie. SAP Java und ABAP gehen eine folgenschwere Verbindung ein.

8. SAP Application Server: Mit der nun auch technologischen Java/ABAP-Heterogenität der Komponenten lanciert SAP das Marketingkonstrukt SAP NetWeaver, mit dem Ziel, die beiden äusserst unterschiedlichen Technologien über eine gemeinsame Plattform zu nutzen. Unter SAP NetWeaver werden die folgenden sieben kaufbaren Produkt-Suiten zusammengefasst:
• SAP NetWeaver Application-Server ABAP – hierauf werden die ABAP-basierenden Business-Systeme zur Verfügung gestellt.
• SAP NetWeaver Application-Server Java – hierauf werden die Java-basierenden Systeme zur Verfügung gestellt.
• SAP NetWeaver BI (Business-Intelligence – vormals BW)
• SAP NetWeaver PI (Process-Execution, zunächst XI genannt)
• SAP NetWeaver Portal
• SAP NetWeaver MDM (Master-Data-Management)
• SAP NetWeaver Mobile

9. Service Oriented Architecture: SAP Marketing springt nun nach Client/Server auf die nächste grosse IT-Architekturwelle auf: Service-Orientierte-Architektur (SOA). So lanciert die Firma SAP ESOA, mittlerweile nur noch SAP SOA genannt. Unter anderem erfüllt SAP damit vermeintlich eine der Voraussetzungen für ein Cloud Computing-Angebot.

Datenhaltung der Business-Prozesse

Diese SAP Evolutionen geben einen Eindruck davon, wie komplex und umfangreich mittlerweile ein SAP-System aus Komponenten aufgebaut ist. Bei SAP Enterprise-Installationen, in welchen die gesamte Business-Suite von SAP eingesetzt wird, kommt aus historischen Gründen und aufgrund von Kundenanforderungen schnell ein SAP System mit einer Architektur zustande, die eine Anzahl produktiver Systeme mit Datenbanken im grossen zweistelligen Bereich umfassen. Dies noch ohne die der Produktion vorgelagerten Entwicklungs-, Test-, Staging, Prototyp- und Schulungssysteme. Diese SAP Komplexität für einen Kunden zu managen, kann sehr aufwändig werden. Und nun soll mit der nächsten Marketingwelle – SAP Cloud Computing – ein solches System für die Anforderungen von einzelnen Anwendern on Demand aufgebaut werden? On Demand in der Wolke für Nutzer von Hunderten von verschiedenen Kunden mit unterschiedlichen Anforderungen in Bezug auf Systemeinrichtung. Bekannterweise und mit Kenntnis der Vorgeschichte und der SAP Softwarearchitektur verständlich, basiert „SAP Business by Design“ für jeden Kunden auf einer logisch eigenen Installation von SAP! Wie will SAP die Individualität jeder einzelner dieser Installationen managen, geschweige denn bei Änderungen mit vernünftigem Aufwand verstehen, was diese für die einzelnen Systeme bedeuten? Das Lifecycle Management über die Cloud hinweg ist eine zu gewaltige Herausforderung.
Aus dem aufgezeigte„SAP Evolutionsmodell“ kann man schliessen, was es für SAP bedeutet, SAP Business-Funktionalität eines SAP-Backend-Moduls in einem Browser benutzergerecht rollenbasiert zur Verfügung zu stellen. Deshalb erweitert SAP seine R/3 Client-Server-Welt um weitere Architekturebenen als Unterstützung für die Internet-Technologie. SAP selbst muss nun im Infrastrukturbereich noch weitere zusätzliche, produktiver Server-Ebenen hinzufügen, was die Komplexität des Systems und Unterhalts noch mehr in die Höhe schraubt.

SAP Funktionalität mitsamt Daten in die „Wolke“

Dank der letzten Technologie-Evolution von SAP, nämlich SAP SOA, werden SAP Business-Funktionen im Web zur Verfügung gestellt, im SAP Standard allerdings bloss ein einstelliger Prozentsatz der SAP-Business-Funktionalität. Hierbei ist auch zu beachten, dass Webfunktionalität von SAP oft nicht 1:1 bei Kunden installierter SAP Funktionalität entspricht. In SAP’s Brust schlagen zwei Herzen, eines für die alteingesessenen „ABAPeure“ und eines für die „neuen Java-Freaks“. Diese schlagen noch nicht immer synchron.

Fazit SAP Cloud Computing

Kann nun eine auf einem 20 Jahre alten Konzept basierende Business-Funktionalität und das zugehörige Systemumfeld den im ersten Absatz aufgeführten Ansprüchen von modernem Cloud Computing Rechnung tragen? Aus meiner Sicht ist die von Cloud Computing geforderte Virtualisierung und Skalierbarkeit von Systemwelt und Datenhaltung für eine dermassen auf individuellen Einstellungen basierende, transaktionale Verarbeitung von Geschäftsdaten im grossen Umfang nicht mit vernünftigem Aufwand machbar. SAP versucht ein weiteres Mal von Anfang an auf einer Marketing-Welle mitzureiten – „auf der Wolke mitzufliegen“. Ob es sich bei dieser Wolke für SAP um eine gefährliche Gewitterwolke für SAP handelt?
Bisher kümmerte sich SAP in erster Linie darum, die Veränderungen am eigenen Code im Griff zu haben und die Kunden beim Software-Upgrade zu unterstützen. Mit SAP als Cloud Computing Angebot ist das vorbei. Hiermit muss SAP individuelle Kundenumgebungen aufsetzen und sie über den Lebenszyklus unterhalten – nicht nur den SAP Code, auch die gesamte Konfiguration und alle Systeme. Werkzeuge wie SAP Solution Manager sind für diese umfassende SAP Change Management Aufgabe nicht geschaffen und können nur punktuell helfen. Problemstellungen, mit denen sich bisher in erster Linie die Kunden herumgeschlagen haben, werden zur Herausforderung für SAP selbst.

Ob dies wohl der Grund ist, warum SAP’s „Cloud“-Angebot Business byDesign scheinbar nur schleppend vorankommt? Ein schnelles Anwachsen von Business byDesign Anwendern ohne eine entsprechend ausgeklügelte, individuelle SAP Kundenprovisionierungs- und SAP Lifecycle Management – Lösung wäre auf jeden Fall fatal für SAP.
Für den SAP Business byDesign-Kunden ist dies im Prinzip kein Problem, solange das Cloud-Angebot von SAP preislich und technisch stimmt. Aber ist SAP wirklich in der Lage, über Marketing-Messages hinaus ein solches Offering im grossen Stil kostengünstig zu liefern? Es ist an SAP, dies zu beweisen. Gelingt dies nicht, werden entweder SAP oder die SAP Cloud-Computing Anwender teuer dafür bezahlen.

Diese konkurrierende Situation von SAP Projekten bekommt man nur mit SAP Application Lifecycle Management (kurz SAP ALM) in den Griff.

Beteo definiert folgende Leitsätze hierfür:
Business-Prozess-Management für SAP Template (SAP BPM for Template)
Mit der Identifikation der „idealen“ Geschäftsprozesse  fängt das „SAP BPM for Template“ erst an. Sind einmal die SAP Template Geschäftsprozesse definiert, müssen diese auf ihre SAP Roll In Fähigkeit geprüft werden. Hier geht es darum, festzustellen, welche Prozessbestandteile für den globalen Gebrauch gelten (zentrale Objekte), bzw. ob Prozessbestandteile in den einzelnen Konzernbereichen „lokalisiert“ werden können (lokale Objekte). Diese Spezifikationen müssen dann für die Operationalisierung im komponentenorientierten Softwareentwicklungsansatz umgesetzt werden, welcher aus der Softwareentwicklung bekannt ist.

SAP Single-Client Architektur
Durch die konkurrierende Situation von mehreren Firmen, Produktionen, etc. auf demselben SAP Mandant werden Geschäftsprozessfehler bereits in der Entwicklungsumgebung erkannt.

Digitalisierte Change-Prozesse
Die digitalisierten Prozesse stellen ein proaktives Momentum sicher und verknüpfen die an den SAP Change-Prozessen beteiligten unterschiedlichen Support-Systeme (Kontrolle über die Redundanz)

Konsistenzsicherung durch SAP Solution Manager mit SAP Customizing Synchronisation
Hiermit wird eine Autonomität von dezentralen Entwicklungen (Primär SAP Customizing) ermöglicht. Eigenentwicklungen mittels komponentenorientiertem Software Engineering Komponentenorientiertes Software Engineering in Entwicklung und Customizing ermöglicht langlebige, dynamisch an geänderte Geschäftsumfelder anpassbare Software-Systeme.

Strikte Namenskonventionen für alle Entwicklungsobjekte (SAP und non SAP), auch SAP Customizing
Damit wird jedes zu entwickelnde Objekt (auch SAP Customizing Einträge) auf seine logische Komponente referenzierbar.

Softwaregestützes SAP Impact-Management
Ein SAP Impact-Management bringt nur einen Nutzen, wenn es von den logischen Komponenten bis zu den technischen Komponenten dynamisch aufgesetzt ist.

Konsistentes SAP Transport-Management
Systemgestützte Lösungsansätze für das Sicherstellen von vertikaler und horizontaler Konsistenz sind ein absolutes Muss, idealerweise direkt mit dem Komponentenmanagement gekoppelt.

SAP Architekturmanagement
Nicht alles, was SAP kommuniziert, funktioniert auch so in der Praxis. Ein kritisches Hinterfragen der Lösungsansätze von SAP ist angesagt oder noch besser seine eigene Meinung, d.h. seine eigenen Anforderungen für das Managen von SAP Template zu haben.

Multiprogrammfähiges Projekt-Management.
Die Abhängigkeiten und Schnittmengen zwischen mehreren SAP-Projekten müssen übergreifend gemanagt werden.

Fazit

Alle diese Leitsätze zusammen und wirklich nur alle zusammen ermöglichen erst ein konsistentes SAP Template Management. Dies klingt nach grossem, technischen Aufwand. Die Praxis zeigt aber, dass bei komplexen SAP Systemen der Nutzen den Aufwand ein Vielfaches übersteigt – wenn nicht gar erst den Nutzen eines konzernweiten SAP-Systems nachhaltig sicherstellt.

In der Tat: Nehmen Sie sich eine Checkliste zum SAP Application Lifecycle Management, so können Sie sich sicher sein, dass der SAP Solution Manager in jedem Bereich sein grünes Häkchen gesetzt hat. Also können Sie sich zurücklehnen und haben mit der Implementierung SAP Solution Manager das Thema SAP Application Lifecycle Management vollständig abgedeckt. Und das noch mit einer kostenlosen Software.

Sie ahnen bereits, dass ich mich nicht so schnell zurücklehnen möchte…

Eine SAP ALM-Lösung hat ihr Nutzenoptimum, wenn alle Teile ineinandergreifen und sich zu einem geschlossenen Prozess bzw. sogar zu einem geschlossenen Kreislauf (ein Systementwicklungszyklus im gesamten Lebenszyklus) verbinden lassen. Während der Spezifikation erfasste SAP Anforderungen müssen beispielsweise spätestens beim Testen, aber natürlich auch vorher im Design und der Entwicklung von Software zur Verfügung stehen. Sie müssen in Beziehung gesetzt werden zumindest zu den Testfällen und damit auch indirekt zu bestimmten SAP Komponenten des Softwaresystems. Alle im Entwicklungsprozess erstellten Dokumentationen sind ebenfalls den jeweiligen Software-Komponenten zugeordnet (genauer gesagt sogar bestimmten Versionen von Software-Komponenten, aber das führt hier vielleicht etwas zu weit).

Jeder am SAP Systementwicklungsprozess beteiligte Mitarbeiter sollte alle Informationen im schnellen Zugriff haben, welche er für die Erledigung seiner Aufgaben bzw. Rollen braucht. Erleichtert wird dies, wenn sämtliche bearbeiteten Objekte entsprechend strukturiert und in Beziehung gesetzt sind. Optimal geeignet für eine solche Strukturierung ist eine komponentenorientierte Vorgehensweise bei der Softwareentwicklung, wie sie bei Service-orientierten Architekturen (SOA, oder SAP SOA) typischerweise verwendet wird. Meines Erachtens sollte unter SAP SOA dabei mehr verstanden werden als nur Java-Entwicklung und Web Services. Auch für „herkömmliche“ Softwaresysteme eignet sich die komponentenorientierte Vorgehensweise hervorragend – insbesondere wenn man dabei langlebige Systeme vor Augen hat, wie es SAP Implementierungen meist sind.

Konventionelle SAP Entwickler sind mit der Aussage, bei ABAP-Entwicklungen oder gar SAP Customizing komponentenorientiert vorzugehen, völlig überfordert. Gerne wird dann in der SAP ABAP Welt behauptet, dass ein SAP ABAP basierendes ERP-System nicht in Komponenten zerlegbar ist: „Im SAP IMG gibt es keine Komponenten!“. Unsere Erfahrung ist eine ganz andere, denn natürlich lassen sich einzelne funktionale Bereiche des SAP IMG zu logisch zusammengehörigen Komponenten zuordnen – und nicht zuletzt ist das SAP Customizing an sich eine technische Komponente. Nachfolgende Grafik illustriert das komponentenorientierte Vorgehen bezogen auf eine heterogene SAP Welt.

SAP Komponente

Vor allem in komplexen SAP SOA Projekten ist das Managen der Abhängigkeiten zwischen den unterschiedlichen technischen Komponenten mittels konventionellen SAP Solution Manager basierenden Ansätzen nicht gelöst und auch nicht absehbar. Das nachfolgende Beispiel illustriert die Komplexität in einer typischen SAP Entwicklungslandschaft.

SAP Systemlandschaft

Um die volle Funktionalität einer logischen Komponente, die sich aus technischen Teilen aus allen Ebenen zusammensetzen kann, testen (SAP Testing) zu können, müssen alle ihre technischen Teile in jeweils zueinander passenden Versionen gleichzeitig auf der entsprechenden Teststufe ausgeliefert sein. Für SAP Customizing und ABAP-Entwicklungen sind dies ein oder mehrere Transportaufträge, für JEE-Entwicklungen die entsprechende(n) Softwarekomponente(n) usw. Erst dann kann im Portal eine Funktionalität verwendet werden, die auf Webservices und damit indirekt JEE-Funktionalität sowie Teilen von ABAP-Funktionen und entsprechendem Customizing basiert.

Zusammengefasst sind schon hier mindestens fünf technische Komponenten über mindestens vier logische Systeme enthalten. Dies noch ohne die Abhängigkeit logischer Komponenten untereinander, die es natürlich auch noch gibt! Was dies für das Managen der Abhängigkeiten von Transportaufträgen bedeutet, haben wir bereits in diversen Blogs aufgezeigt.

Eine integrierte SAP ALM-Lösung erfasst alle Abhängigkeiten und sorgt dafür, dass der Überblick in einer solch komplexen Landschaft erhalten bleibt. Sowohl die Softwarelogistik kann dann aus dem ALM heraus gesteuert werden als auch die (Weiter-)Entwicklung der Softwarelösung. Alle Anforderungen, Designdokumente, Schulungsunterlagen, sonstigen Dokumente und technischen Artefakte sind zentral verfügbar. Entwicklungsprozess und Releases werden zentral gesteuert.

Der SAP Solution Manager bietet inzwischen für viele ALM-Aufgaben gute Einzellösungen – für das von mir skizzierte voll integrierte ALM sind jedoch noch einige Lücken zu schliessen – da die Integration und damit das Ineinandergreifen der einzelnen Lifecycle-Phasen noch nicht sehr weit vorangeschritten ist.

Dass die Integration der richtige Weg ist, machen die Hersteller von ALM-Software für reine Java-Entwicklungsprojekte vor: Deren Lösungen bieten in zweiter Generation die Integration zwischen den einzelnen Phasen im Application Lifecycle-Management (z. B. Orcanos ALM 2.0). Diese Tools sind jedoch leider nicht für eine heterogene SAP-Lösung, wie sie in typischen Grossunternehmen vorzufinden ist, geeignet.

Fazit – SAP Solution Manager als Checklistensoftware

Also alles noch graue Theorie und Zukunftsmusik? Nicht ganz: Es gibt bereits erfolgreiche Referenzprojekte, in denen unter Zuhilfenahme der richtigen Werkzeuge und Methoden integrierte ALM-Lösungen für SAP-Umgebungen geschaffen wurden.

Die grösseren Entwicklungstrends werden verschlafen.
(a) Personalisierung von Leistungen und Produkten statt bloss Varianten.
(b) Kooperationen und Netzwerke statt Unternehmenswachstum und Kontrolle der Zulieferer.
(c) Enterprise 2.0 statt Marketingunterstützung.
(d) Nachhaltigkeit in allen Dimensionen der Unternehmensführung, Produkte und Leistungen, Finanzen, Mitarbeiter und Kundenbeziehungen statt Sprüche Klopfen.
(e) Kultur Unternehmen statt Unternehmenskultur: Welche Kultur will ich in und mit meinem Unternehmen, mit meinen Wertbeiträgen verwirklichen?

Und auch einfache Anstrengungen sind zurückgestellt. Was sind Ihre Veränderungsdefizite? Wollen Sie selbst die Trends gestalten oder erst hinterher laufen, wenn alle rennen? Change Management heute geht auch um die Inhalte. Die Inhalte müssen überzeugend sein, damit Menschen mitmachen. Ein Sparring dazu jeder Zeit. – ”Smart consulting.”

Über den Autor:
Dr. Michael Loebbert ist Coach und Management-Berater und Autor der monatlichen Publikation “Change Management Short Cut“.

Mit seiner serviceorientierten Architektur (SOA) erlaubt SAP den Kunden Applikationen in neuer Form zu erstellen. Flexible Business Prozesse rufen dabei granulare, vom SAP System zur Verfügung gestellte oder vom Kunden geschaffene SAP Services auf. Die Entwicklung solcher Lösungen ist allerdings ein Bruch mit der herkömmlichen Art und Weise SAP zu customizen und ABAP Funktionen zu bauen und einzuführen. Und genau damit tun sich die traditionellen SAP Entwickler und Integratoren doch ziemlich schwer.

Ausgereifte, und passende konventionelle Software-Engineeringverfahren, wie sie in der Individualentwicklung in der nicht-SAP Informatik zum Einsatz kommen, werden von der SAP-Community allzu einfach als nicht passend abgetan. Dabei verwendet selbst SAP für das Managen der Standardsoftware-Komponenten ein komponentenorientiertes Softwareentwicklungverfahren. Dies lässt sich leicht daran erkennen, wie alle Komponenten der Standardsoftware und deren Abhängigkeiten systemtechnisch sauber im System Landscape Directory, unter Zuhilfenahme des CIM-Modells abgelegt und verwaltet werden.

SAP Kundeneinführungen werden meist noch nach der bewährten, angelehnt an die von SAP selbst propagierte Accelerated SAP- (ASAP-) Einführungsmethodik umgesetzt – sofern diese überhaupt methodisch eingeführt werden. Schliesslich handelte es sich bei SAP Einführungen nicht in erster Linie um Entwicklungsprojekte, sondern um die reine Einführung und Anpassung eines Softwarepakets. Doch spätestens mit SOA hat sich die Welt verändert. Für die SAP Community scheint es schwierig, mit diesen rasanten Veränderungen von SAP Schritt zu halten.

Was den im SAP Umfeld eingesetzten Methoden wie ASAP und BPM Methodology fehlt, ist das Managen der unterschiedlichen Artefakte, der logischen und technischen Komponenten und deren Beziehungen untereinander. So ist schon bei simplem Customizing und reiner ABAP-Entwicklung eine effektive Auswirkungsanalyse von Änderungen auf die Systemkomponenten in den verschiedenen Phasen der Entwicklung kaum möglich! Falls nur die Einführung des Projekts für die SAP-Initiative im Vordergrund steht, braucht man sich hierüber nicht weiter den Kopf zu zerbrechen. Doch wer irgendwann sein System erweitern muss, ist darauf angewiesen, zu wissen, wie beschreibende, logische und technische Lieferobjekte von  Business Blueprints, über ABAP Programme und SAP Customizing zusammenhängen und sich über die Zeit verändern.

Werden nun die Möglichkeiten der serviceorientierten Architektur von SAP genutzt, ist es unabdingbar, die Objekte der SAP Landschaft und Ihre Zusammenhänge konsequent zu verwalten. Die SAP „ Business Process Management Methodology“ für die Einführung von Systemen mit flexibel gestaltbaren Business Prozessen, welche SAP und andere Services konsumieren, hilft in dieser Beziehung kaum weiter. Sollten hier nicht noch geschrieben werden warum Die BPM Methodology hilft primär bei der Abstrahierung von Business Prozessen ins BPM – Tool von SAP, macht aber keine Aussage darüber wie konsequent die Software-Engingeering hinsichtlich des Komponentenmodells umgesetzt werden sollte.

SOA ist ein starkes Architekturkonzept für SAP selbst, um die eigenen Systeme flexibel und attraktiv weiter zu entwickeln und um Kunden Services zur Verfügung zu stellen. Kunden zeigt SAP jedoch nicht auf, wie und womit sie selbst serviceorientierte Systeme mit SAP Funktionalität bauen sollen.

Wie schon erwähnt setzt selbst SAP beim Entwickeln von SOA basierten Bestandteilen seiner Software nicht mehr auf die Methoden und Werkzeuge der guten alten ABAP-Zeiten. SAP hat im Bereich des Lebenszyklus-Management seiner Standardapplikation die Hausaufgaben gemacht und setzt auf moderne komponentenbasierte Methoden und Werkzeuge. Es ist nun an der SAP Kunden- und Berater-Community dies für Ihre eigenen Umsetzungen zu tun, um analog professionellem, modernem Software-Engingeering andernorts in Unternehmen, nachhaltig SAP-Anwendungen warten und weiterentwickeln zu können. Wäre es nicht bemühend, könnte es fast amüsieren, zu sehen, wie schwer sich erfahrene SAP Berater tun, wenn einmal von SAP keine Methoden und Werkzeuge angeboten werden und alte Ansätze nicht mehr genügen.

Fazit

Damit eine, wie von SAP Marketing suggerierte, Unternehmens-Applikationslandschaft basierend auf SAP-Services und entsprechender SAP SOA Architektur überhaupt erst zum Einsatz kommen kann, muss sich der SAP Kunde erst recht im Klaren sein, wie er die Versionen und die Abhängigkeiten zwischen den unterschiedlichen Systemkomponenten – also technischen und beschreibenden, logischen Komponenten der Entwicklung und auch den verschiedenen Services in der Produktion verwaltet.

Er muss seine gesamten SAP Entwicklungsverfahren so ausrichten, dass er „morgen“ jeden einzelnen „Service“ als eigenständige Komponente mit allen Abhängigkeiten unterhalten kann. Dies war auch in der Vergangenheit schon ein Bedürfnis, mit zusätzlichem, eigentlich unnötigem Aufwand allerdings noch im Griff zu behalten. Spätestens mit der aktiven Nutzung einer serviceorientierten Architektur, muss eine typische komponentenorientierte Softwareentwicklung auch im SAP-Umfeld Einzug halten: Nur so kann ein effektives Impact-Management als Voraussetzung für eine effektive Entwicklung und ein zielgerichtetes Testing zur Verfügung gestellt werden.

Das zentrale Customizing, welches die Integrität der übergreifenden SAP-Firmenstruktur sicherstellen soll, wird in den meisten Firmen im zentralen SAPTemplate-Customizing-Mandant erstellt und gepflegt. Von hier wird es mittels BC-Set und Transportmanagementsystem zu den dezentralen Customizing-Entwicklungssystemen transportiert. Allerdings ist es nicht einfach, die SAP-Customizing-Einstellungen firmenübergreifend konsistent zu halten, gerade für SAP-Anwender, die mit mehreren dezentralen Systemlandschaften arbeiten.

Denn bereits mit dem ersten dezentralen Customizing werden oft bewusst, aber auch unbewusst Änderungen am vorgängig verteilten, zentral unterhaltenen SAP Company Template vorgenommen. Die Folge davon ist, dass das dezentrale Customizing nicht dem zentral gemanagten SAP Company Template entspricht. Die entstehenden Inkonsistenzen müssen immer wieder teuer und mit viel Aufwand beseitigt werden. Organisatorische Massnahmen, um diese Widersprüchlichkeiten zu verhindern, zeigen bislang kaum Wirkung, denn die autonom handelnde dezentrale Entwicklung wird nicht technisch überwacht und kann vom System nicht gewarnt werden. Updates am zentralen SAP Company Template können folglich nach dem Transport zu den dezentralen Systemlandschaften nicht mehr aktiviert werden, da sie möglicherweise das vorgenommene dezentrale Customizing wieder überschreiben. Um trotzdem geänderte zentrale SAP Company Templates dezentral aktivieren zu können, bedarf es sehr grosser Abstimmaufwände.

SAP-company-Template-Schutz mit SAP Solution-Manager

Template Roll-out kann man systemtechnisch mit dem SAP Solution Manager in den Griff bekommen. Mittels Einstellungen verhindert dieser, dass die Modifikationen für das Company Template in dezentralen Systemlandschaften überschrieben werden können – eine wirksame, systemtechnische Qualitätssicherungsmassnahme. Das zentrale Customizing ist damit dezentral sichergestellt. Der SAP Solution Manager kann auch dann noch eingeführt werden, wenn diverse zentrale und dezentrale Anpassungen und Roll-outs bei einem Anwender bereits durchlaufen wurden.

Aus der Praxis

Ein weltweit operierender Konzern mit Dutzenden von SAP-ERP-Systemen, davon mehrere Produktivsysteme, definierte vor Jahren ein globales Template. Damit wurden für das Customizing globale Einstellungen definiert, die in allen Produktivumgebungen identisch sein mussten. Die Einhaltung der Einstellungen sollte mittels organisatorischer Massnahmen erreicht werden, deren Umsetzung erwies sich aber als schwierig. Die Vorgaben konnten zu einfach umgangen werden. So nahmen Entwickler Änderungen zum Teil nur auf ihren Entwicklungsmandanten vor, die restlichen wurden «vergessen». Die Situation spitzte sich zu, als sich das Unternehmen und damit auch die Systemumgebung, unter anderem durch Übernahmen, vergrösserte und komplexer wurde. Nach einer Weile entwickelte sich ein massives Delta der wichtigsten 5-Customizing-Mandanten. In einem ersten Versuch probierte das Unternehmen, die Situation durch die zentrale Zusammenlegung der Entwicklungsmandanten zu verbessern. Dieser Ansatz scheiterte aber auf Grund der Komplexität. Ausserdem benötigte ein neues Geschäft in Nordamerika zwingend einen eigenen Mandanten.

Auf Lösungssuche

So machte man sich auf die Suche nach einer anderen Lösung. Dabei kristallisierten sich Fragen heraus, die für die Definition und spätere Umsetzung zwingend berücksichtigt werden mussten:

• Wie kann erreicht werden, dass die Einstellungen des Global Template auf allen Entwicklungsmandanten konsistent sind?

• Wie wird sichergestellt, dass Einstellung am Global Template in einem dedizierten Mandanten durch das Template vorgenommen werden können?

• Wie kann durchgesetzt werden, dass Einstellungen des Global Template auf den Entwicklungsmandanten nicht verändert werden können?

• Wie kann gewährleistet werden, dass bestimmte Schlüsselbereiche in Customizing-Tabellen gesperrt werden?

• Wie kann bewerkstelligt werden, dass nur ausgewählte Schlüsselbereiche in Customizing-Tabellen verteilt werden?

Zur Diskussion standen schliesslich mehrere Lösungsansätze:

1. Single-Client-Strategie (Erstellen eines zentralen Customizing-Mandanten)

Hierbei wird das Abgleichen und dann Zusammenführen der fünf bestehenden Customizing-Mandanten in einen zentralen Customizing-Mandanten angestrebt. Die grosse Komplexität und das grosse Delta zwischen den bestehenden Mandanten könnten zu Problemen führen. Zudem sind die Anforderungen des Geschäfts aus Nordamerika wegen Benutzung des New Ledger mit diesem Ansatz nicht zu erfüllen.

2. Organisatorische Regelung und manuelle Verteilung durch Transporte

Im Zentrum dieses Ansatzes steht das erneute Aufstellen von organisatorischen Regelungen in Form von Richtlinien. Diese sehen vor, dass Einstellungen am globalen Template auf einem Entwicklungsmandanten vorgenommen werden, die restlichen Mandanten werden dann mittels manuell angelegten Transporten beliefert. Dieser Ansatz bietet jedoch keine Möglichkeit, Customizing-Einstellungen auf anderen Mandanten zu sperren. Zudem ist diese Lösung mit der grossen Anzahl von Entwicklern kaum umsetzbar beziehungsweise sehr umständlich in einer möglichen späteren Anwendung.

3. Customizing Synchronisation mit SAP Solution Manager

Mit der Customizing Synchronisation werden globale Einstellungen in den lokalen Mandanten gesperrt beziehungsweise zentral verändert und in die Zielmandanten verteilt. Lokale Einstellungen können weiterhin dezentral in den Zielmandanten vorgenommen werden. Customizing-Einstellungen, die zu einer Synchronisationsgruppe gehören, werden über mehrere Customizing-Mandanten synchron gehalten. Damit entsteht die Möglichkeit, Customizing-Einstellungen zentral vorzunehmen und gleichzeitig in weiteren Mandanten oder gar Systemen synchron zu halten. Gleichzeitig können diese Einstellungen auf den Zielmandanten oder Systemen für Änderungen gesperrt werden. Die grösste Herausforderung dieser Variante besteht darin, das bestehende Global Template in Synchronisationsgruppen zu «verpacken», die Zielmandanten vorgängig abzugleichen und Objekte als global oder lokal zu definieren. Auf Grund der Fragestellungen, der Anforderungen sowie den bereits in früheren Versuchen gemachten Erfahrungen mit organisatorischen Richtlinien und der Single-Client-Strategie wurde Variante 3 ausgewählt und eine Umsetzungsplanung erstellt.

Umsetzung in Teilschritten

Wegen der komplexen Systemumgebung und der Auswirkungen auf die Organisation musste die Umsetzung in kontrollierbaren Teilschritten vorgenommen werden. In einer ersten Phase wurden die Systeme zudem auf zwei produktive Entwicklungsmandanten reduziert. Dies auf Basis des grössten gemeinsamen Nenners und auf Grund der grossen Deltas zwischen den Systemen. So sollte das neue Produktivsystem für Nordamerika mit kleinstmöglichem Aufwand aus dem Template erstellt werden können. Gleichzeitig konnte man alle Template-Einstellungen sperren. Die weiteren Mandanten sollten dann im Anschluss in einer zweiten Phase abgeglichen und das Template entsprechend angepasst werden.

Meilensteine der Umsetzung

Die wichtigsten Meilensteine der Umsetzung:

• Projekt Set up: Unterteilung in Phasen und Iterationen, Definition der Lieferobjekte, Festlegung der Projekt-Organisation, Vereinbarung über Vorgehen betreffend Kommunikation/Risiken/Pendenzen/Entscheidungen/Projektumfang sowie Änderungen daran/Fortschritts-Reporting, Kontrollpunkte für Qualitätssicherung, Rollen und Verantwortlichkeiten
• Definition: Dokumentierte Richtlinien, Namenskonventionen und dokumentierte SAP-Unternehmensstruktur,Verteil-Strategie, Mandanten-Strategie, Locking-Strategie
• SAP Solution Manager: Einrichten von SAP Solution Manager in produktiver Umgebung, Konfiguration für den Einsatz der Customizing Synchronisation
• Definition Einstellungen Global Template: Einstellungen, die im Global Template gehalten werden, zusammen mit Fachbereich erarbeiten, definieren und dokumentieren
• Delta der Mandanten: Sicherstellen der Systemvoraussetzungen für die Vergleichsläufe, Durchführung der Vergleichsläufe zwischen den Mandanten, Erstellen einer Differenzanalyse, Eruieren von Altlasten
• Erfassen der Einstellungen in Synchronisationsgruppen: Aufteilung der Synchronisationsgruppen anhand der eingesetzten SAP-Module, im Bereich Logistik entstanden so zum Beispiel über 25 Synchronisationsgruppen mit ungefähr 1500 einzelnen Synchronisationsobjekten
• Definieren von Filterbedingungen für die Sperren: Definition von Bereichen, das heisst Einstellungen, die nicht synchronisiert, aber dennoch in Zielmandanten gesperrt werden, Zuteilung der Bereiche auf Synchronisationsgruppen
• Aufbau des «Global-Template-Mandanten»: Aufbau des Mandanten durch Abgleich und Zusammenführung der fünf bestehenden Customizing-Mandanten, Synchronisation der Objekte auf den Zielmandanten, Aktivierung der Synchronisation
• Vorbereitung «go live»: Testen, Schulung
• Aktivierung: Aktivierung der Sperren auf den Zielmandanten, Aktivierung der Verteilung

Laufende Aktivitäten

In einem weiteren Schritt sollen nun Finanz und Controlling (FI/CO) erweitert sowie die Templates verfeinert werden. Nachdem nun also im Logistikbereich sämtliche Objekte des Template synchronisiert werden, wird die Lösung nun auf den Bereich Finanz und Controlling ausgeweitet. Des weiteren werden Objekte, die in der ersten Phase nicht oder nur teilweise synchronisiert werden konnten, nun einzeln betrachtet, analysiert, abgeglichen und nach Möglichkeit ins globale Template aufgenommen.

Nutzen

Die Gründe, wieso Unternehmen ähnliche Ansätze verfolgen sollten, sind vielfältig. So werden beispielsweise die Einstellungen der globalen Templates geschützt und können nur durch ein entsprechend autorisiertes und geschultes Template-Team angepasst werden. In der Standard-Version des Customizing-Mandanten sind die Einstellungen des globalen Template gesperrt und können nicht verändert werden. Ungewollte Einstellungen führen also nicht mehr zu Fehlern in der Produktion. Ausserdem erfolgt die Verteilung automatisiert, Deltas zwischen den Mandanten werden proaktiv unterbunden. Ebenso können neue Produktivmandanten mit minimalem Aufwand erstellt und gleichzeitig in die Verteilung angebunden werden.

ITIL v3 im Vergleich zu ITIL v2

Der Hauptunterschied zwischen ITIL v3 und ITIL v2 ist die Abbildung des Lebenszykluses für IT-Services. Die Hauptprozesse (Service Support und Service Delivery) von ITIL v2 wurden abgelöst durch die 5 Hauptprozesse in ITIL v3: Service Strategy, Service Design, Service Transition, Service Operation und Continual Service Improvement. Die Unterprozesse bleiben weitgehend gleich, wobei aber wegen der neuen Gesamtstruktur die Schnittstellen zwischen den Prozessen angepasst werden mussten. Zu den Unterprozessen gehören zum Beispiel: Incident Management, Problem Management, Release Management, Configuration Management, Capacity Mangement oder Service Level Management.

ITIL v3 Prozesse

Mängel von ITIL

Es muss dabei beachtet werden, dass ITIL nur ein Vorschlag (best practice) ist, wie die Prozesse idealerweise ausschauen können. Die eigentliche praktische Ausführung der Prozesse kann aber im Kontext der betroffenen Unternehmung logischerweise davon abweichen. ITIL ist sehr allgemein definiert, so wird z.B. wird immer von Services gesprochen wobei die Art von Services nicht konkretisiert werden und es je nach Service-Typ grössere Unterschiede in den Prozess-Definitionen geben kann.

Ressourcen-Planung

ITIL fokussiert sehr stark auf das Gebiet des Betriebes von Lösungen und nicht auf neue, aus dem Business gestellte Anforderungen, die über Projekte abgewickelt werden. Diese Bereiche sind somit nicht nur organisatorisch, sondern auch methodisch voneinander getrennt. Denn auf der Projekt-Seite gibt es durchaus ausgereifte Projektmanagement-Methoden, wie z.B. der ebenfalls von OGC definierte PRINCE2-Standard, der schweizerische Projektführungsmethode HERMES oder das amerikanische PMI . Das Problem ist die Schnittstelle zwischen den zwei Gebieten und die fehlende übergreifende Methode, um die gesamten Projekt- und Betriebs-Prozesse zu verwalten. Denn schlussendlich greifen beide „Seiten“ auf die gleichen Ressourcen und Systeme zu. Meistens versuchen sie das auch gleichzeitig.

Service- und Project-Management

 CoBIT und BSM könnten allenfalls die Brücke zwischen dem ITILv3- und Projekt Management-Standard bilden und als întegrierte Kontroll-Methoden dienen. Sie sind jedoch noch nicht völlig ausgereift, nicht ganz einfach in der Handhabung und lassen den nachhaltigen Fokus auf ein umfassenden Application Lifecycle Management aussen vor. Ergo gibt es  aktuell keinen praktikablen Standard, der die verschiedenen Prozesse vollumfänglich integriert und Applikationen sowie Systemlandschaften ganzheitlich betrachtet.

Weiterführende Links:

• beteo – ITIL, PRINCE2, PMI – Futter für Papiertiger?
• BSM – ITSM Done Right?

Configuration Database

Eine Möglichkeit für eine ganzheitliche Betrachtung ist das Configuration Management. Aber auch hier werden nach ITIL nur Infrastrukturelemente in einer CMDB (Configuration Management Database) verwaltet. Diese sind zudem ist sehr allgemein definiert. Für die sinnvolle und multidimensionale Verwaltung von technischen Software-Komponenten aber auch der betroffenen Business Services reicht die CMDB nach ITIL nicht aus.

Weiterführende Links:

• beteo – Proaktives Impact Management – die Basis für BTO
• beteo – Business & IT – Change Impact will gemanaged sein
• beteo – Klassische CMDB – vom Business Service Management überfordert?

Fazit

ITIL ist als de-facto Standard auf das IT Management im Betrieb beschränkt. Und dort ist ITIL richtig gut. Im übergreifenden Application Lifecycle Management sind die notwendigen Prozesse jedoch weit schwieriger zu definieren. Zum einen weil der gesamte Lebenszyklus von Applikationen und der zugrunde liegenden Komponenten verwaltet werden müssen, zum anderen weil die Komplexität stark zunimmt und je nach Organisations-Umfeld grosse Unterschiede bestehen. ITIL ist etabliert im Bereich der Operation und ist hervorragend für diesen Teil vom gesamten Application Lifecycle Management geeignet. Dafür werden  zum Beispiel das Projekt Portfolio Management für die Priorisierung von Ideen und das Erkennen von Auswirkungen auf laufende Aktivitäten, wie auch das Change und Transport Management für das Planen und Transportieren von Änderungen über mehrere Systemlandschaften hinweg völlig ausser acht gelassen. Entsprechend fehlt es bis heute an guten, ausgereiften und standardisierten Schnittstellen zu den verschiedenen Prozessen der anderen Disziplinen von ALM.

Jedes Unternehmen hat im Testing ähnliche Rapportierungs-Bedürfnisse, die von den QC-Standardfunktionen nie ganz erfüllt werden. Aus diesem Grund wurde bislang viel Aufwand für die Entwicklung und Instandhaltung von aussagereifen Quality Center Reports betrieben. Die Standardfunktionalität von QC bietet verschieden gute Möglichkeiten, Daten aus einem Projekt auszuwerten. Die meisten Anwender, welche ein wenig Visual Basic Know-how besitzen, neigen dazu, Daten in Excel zu konsolidieren, diese mit Scripts und Makros zu hinterlegen und dann per Knopfdruck aktuelle, benutzerdefinierte Reports zu generieren. Andere Benutzer verwenden hingegen direkte Datenbank- Zugriffsmöglichkeiten, um zu ihren Daten zu gelangen.

Mit QC 8.6 lieferte HP das lange erwartete „QC Dashboard“ und für die nahe Zukunft verspricht der „QC 10 Dashboard Release“ noch einiges mehr.

Die Herausforderung

Der erste Schritt besteht darin, die projekteigenen Reporting-Bedürfnisse zu erkennen. Deren Komplexität wird häufig unterschätzt und führt dazu, dass Berichte mühsam zusammengestellt werden müssen und für Projekt- oder Programmleiter oft kaum lesbar sind. Für das Management von Testorganisationen sind solche Reports oft nicht oder nur beschränkt brauchbar. Das höhere Management steht häufig vor dem Rätsel, für das Testing messbare KPI’s zu allozieren. Eine sorgfältig ausgewählte und den konkreten Kontext der Umgebung angepasste Reportinglösung kann solche Bedürfnisse effizient abdecken und messbaren Mehrwert schaffen.

Die Lösungsvarianten

1.       QC-Standardfunktionen

Quality Center bietet einige Möglichkeiten ( z.b. „Analysis“, „Document Generator“ und „Excel Reports“), Daten der Applikation auszuwerten.  Für kleinere Projekte sind die vorhandenen Auswertungsfunktionen  meist genügend.  So oder so braucht es zur Erstellung der Templates aber einige Erfahrung und die Reports müssen meistens nacharbeitet werden.

2.       Excel mit VB Scripts

Als Schnittstelle zu QC bietet die API Library von QC eine gute Möglichkeit, Projektdaten darüber zu lesen und zu beziehen. Parameterbasiert können so bezogene Daten im Auswertungstool auf Knopfdruck aktualisiert werden. Die API bietet dadurch auch die Möglichkeit, mehrere Quality Center Projekte gleichzeitig anzusprechen oder auszuwerten.

Eine Vorraussetzung der Benutzung und Anwendung genannter VB- Scripts sind Administrationsrechte auf den zu bearbeitenden Projekten. Viele Hindernisse können mit Scripts umgangen werden, allerdings steigt mit der Komplexität der Scripts auch deren Verwaltungsaufwand. Es kommt auch immer wieder vor, dass fehlerhafte Scripts zu fehlerhaften Daten führen. Deswegen müssen Extraktionsscripts immer wieder getestet und überprüft werden, je komplexer desto aufwändiger kann das dann logischerweise werden.

3.       Direkter Datenbankzugriff

Mit direktem Datenbankzugriff können verschiedene Werkzeuge für das Reporting benutzt werden. Java, Hyperion, Crystal Reports und Actuate können unabhängig dazu eingesetzt werden um nur einige Beispiele zu nennen. Für diese Lösung werden nur Leseberechtigungen auf den QC-Projekt-Datenbanken benötigt. Auch mit dieser Variante ist es möglich, Daten aus mehreren QC-Projekten auszulesen und allenfalls zu konsolidieren. Dafür ist jedoch auch entsprechende Know-how der Werkzeuge für die Wartung und Weiterentwicklung der Reports nötig.

4.       HP Dashboard

Das standardmässig mitgelieferte Dashboard ist ein flexibles Web-Werkzeug. Es besteht aus einem Framework, das viele verschiedene Anpassungsmöglichkeiten bietet. Ein ‚Multi-Project‘ Reporting ist möglich, aber nur anhand von Vergleichen von verschiedenen Projekten.  Eine Aggregation von Werten zwischen Projekten ist nur durch aufwändige (Eigen-)Entwicklung möglich.

5.       KPI Datenbank

Ein Datenbank speichert ‚Snapshots‘ (Datenauszüge) der wichtigsten Kennzahlen in QC.  Diese Daten können dann mittels direktem Datenbankzugriff abgelesen und ausgewertet werden. Die produktive QC-Datenbank kann aber nur anhand zentraler Datenbankprozeduren angesprochen werden.

Unterstützung für die Lösungsfindung

Abhängig von Anforderungen und Rahmenbedingungen findet man die optimale Lösung für das Projekt meist in einer Kombination der verschiedenen Varianten. Folgende Auflistung kann helfen, den optimalen Lösungsansatz zu finden bzw. auszuwählen.

a) Funktionalität

b) Kosten

Fazit (oder der optimale Ansatz)

Eine „all-in-one“ – Standard Lösung mit geringen Wartungskosten und hoher Aussagekraft gibt es leider (noch) nicht. Der beste Weg sämtliche Anforderungen eines Grosskonzerns und/oder komplexer Umgebungen zufriedenzustellen, ohne jeden Kostenrahmen zu sprengen, ist eine Kombination der QC-Standard-Reports und einer eigenen KPI Datenbank.  Das ist sich in der Praxis bewährt. Denn damit sehen die Testmanagern den täglichen Fortschritt, Programmleiter haben eine Übersicht über ihre Programme und Projekte, die Testorganisation kann ihre Gesamtleistung nachweisen und auch mögliche Prozessverbesserungen identifizieren. Eine wichtige Rolle bei der Evaluation beschriebener Varianten spielen immer auch die Aspekte der Datensicherheit, welche nicht bei allen Varianten gleich gut ausgeprägt sind. Das Gleiche gilt für die in der Organisation zur Verfügung stehenden Skills und Tools.