SAP Marketing hat eine lange Tradition aktuelle Schlagworte konsequent für sich zu nutzen. SAP Cloud Computing ist in, also redet SAP von Cloud Computing. Um jedoch SAP als Cloud Offering zur Verfügung zu stellen, bedeutet das sämtliche SAP Funktionen via Web Browser anzubieten. Doch es gehört noch mehr dazu. Wenn einzelne Benutzer SAP Funktionalität in der Cloud konsumieren wollen, muss dafür auch vorgängig die Datenhaltung und die Parametrisierung der Systeme und der SAP Business Prozesse für den individuellen Kunden vorgenommen werden. Meiner Meinung nach ist dies für SAP viel schneller gesagt als getan. Aber warum? Andere Paketsoftwarehersteller bieten solche Cloudleistungen schon längstens an. Um die Frage zu beantworten, ist es nützlich, zu verstehen, wie SAP technisch aufgebaut ist. SAP ist nämlich eine Software, die über viele, teils dramatische Evolutionen zu dem geworden ist, was wir heute locker als „SAP“ bezeichnen. Eine kurze Einführung in die SAP R/3 Softwarearchitektur lässt schnell tiefer blicken.

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.

Seit mehr als 15 Jahren beschäftige ich mich mit dem Thema SAP Change- und Konfigurationsmanagement. Immer wieder treffe ich auf SAP Konsolidierungsprojekte von SAP R3- nach SAP R3. Die Motivation für solche Projekte ist allen bekannt – Kosten für den SAP Betrieb reduzieren. Leider zeigt sich, dass SAP aus ihren Erfahrungen kaum gelernt haben. Denn schon nach dem Liveschalten der ersten Konzerntochter steht man vor dem Dilemma, weitere Konzerntöchter live zu schalten und die erste Liveschaltung konkurrierend zu betreiben.

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.

ALM für SAP. Da haben wir doch den Solution Manager!?

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.

Unternehmen verpassen den Anschluss an die Entwicklung von Märkten und Kunden. Die Absatzkrise ist nicht allein Folge von Finanz- und Wirtschaftskrise. Fehlsteuerungen sind Veränderungsdefizite: Unternehmen warten auf Nachfrage, statt diese aktiv zu führen und neue Märkte zu schaffen. Gewinne werden auf die Bank getragen, statt in Innovation, Forschung und Entwicklung investiert. Gesundheitseinrichtungen vermehren ihre bürokratische Apparate, statt etwas Neues zu verwirklichen. Klagen statt Nachdenken auf der Höhe unserer Zeit. Innovation von Produkten, soziale Innovationen, Innovation unserer Organisationen, Innovation der Kultur(en) bleiben aus. (Und Sie wissen ja, wie diese Aspekte zusammenhängen.) Besonders der Standort Deutschland fällt im weltweiten Vergleich zurück.

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.

Firmen führen einen ständigen Kampf gegen die Inkonsistenzen in den Einstellungen dezentraler SAP-Systeme. Der SAP Solution Manager sorgt für Ordnung.

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 (Information Technology Infrastructure Library) ist der de-facto Standard für IT-Service Management. ITIL wurde und wird laufend von OGC (Office of Government Commerce) beschrieben ITIL ist verbreitet und anerkannt in der Definition der Strukturen und Prozessen von IT-Operation-Services. 1999 wurde ITIL v2 eingeführt und 2007 folgte die neue Version ITIL v3.

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.

Wie erstelle ich einheitliche Testberichte für das Projektmanagement? Wie ist es möglich, den Status von Projekten oder Applikationen, welche in mehreren verschiedenen Quality Center (QC)-Projekten abgebildet sind, zu rapportieren? Herausforderungen wie diese gehören zum Alltag jedes erfahrenen QC- Benutzers.

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.

«Green Change» hört sich seltsam an. Wir verstehen aber in etwa, was damit gemeint ist. Einiges, was wir schon kennen, anderes, was noch undeutlich ist.

• Zum Bekannten zuerst: (a) Nachhaltigkeit bedeutet, dass eine Veränderung neue Veränderungen möglich macht. In der Metapher des nachhaltigen Waldbaus: wir verändern so viel und so schnell, das Resultate so lange Zeit wirksam bleiben, dass sie genügend Gestaltungsspielraum für neue Veränderungen mit neuen Wertschöpfungsmöglichkeiten bieten. (b) Ökologisch im Verhältnis zur Umwelt. Erhaltung und Entwicklung der Vielfalt möglicher Organisationsformen, Schaffen von geschützten Organisationsräumen für Experimente und Innovationen. (c) Soziale Verantwortung übernehmen Unternehmen, die helfen negative Auswirkungen von Veränderungen wie Entlassungen oder Standortverlagerungen für das Gemeinwesen abzufedern.

• Was noch undeutlich ist: (a) Veränderungen in der Organisation sind der Normalfall, sind eingebunden in die operativen Regelprozesse. (b) D.h. sie verlieren ihre teilweise bedrohliche Projekt- und Hauruckform, sondern emergieren quasi organisch mit den Kunden und Interessensgruppen eines Geschäftes oder eines Leistungsprozesses. (c) Menschen, die Gewinner sowohl als auch die Verlierer von Veränderungen, sind in ihren sozialen Rollen miteinander verbunden. Da jeder Mensch mal auf der einen oder auch auf der anderen Seite steht, können die unterschiedlichen Beiträge von Gewinnern und Verlierern wechselseitig gewürdigt werden. Aktuelle Nachteile oder Vorteile werden solidarisch ausgeglichen. (d) Und die «grünen» Inhalte stehen auf der Tagesordnung: «grüne» Technologien, «grüne» Produkte, «grüne» Dienstleistungen, «grünes» Management.

Romantischer Idealismus? – Zumindest das Bekannte rechnet sich, wie mehrfach nachgewiesen, betriebswirtschaftlich. Senkung der Transaktionskosten für Veränderung. Und das Neue, das sich erst ankündigt, überlasse ich gerne Ihrer Vorstellungskraft: Wie grün ist Ihre Veränderung?

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

Mobile Computing für SAP-Anwender wäre eigentlich ganz einfach. Doch die hochkomplexe SAP-Umgebung ist für Unterhalt und Betrieb eine sehr grosse Herausforderung.

SAP erschliesst dem Anwender und sich selbst mit SAP Netweaver Mobile mobile Geräte als Frontend. Damit wird der SAP-Nutzerkreis im Unternehmen und darüber hinaus ausgeweitet. Über mobile Geräte können Teilmengen der SAP Funktionen und Daten Nutzern zur Verfügung gestellt werden, die unterwegs sind oder aufgrund ihrer Tätigkeit und Umgebung nicht auf einem normalen Computer arbeiten können. Beispielsweise können Verkäufer unterwegs CRM-Daten einsehen und aktualisieren, Fahrer auf einer Baustelle Produkt- und Lieferinformationen erfassen oder Mitarbeiter jede Art von Inventar überall aufnehmen. Dank der Netweaver-Technologie kann SAP auch von der technologischen Architektur heraus dem Vollen schöpfen. Gleichzeitig ermöglicht die serviceorientierte Architektur der SAP-Anwendungen, die notwendigen Business-Services aus den unterschiedlichen SAP-Standardapplikationen wie ERP und CRM in Form von Webservices zur Verfügung zu stellen. Bei Bedarf können so Funktionen und Daten aus allen Bereichen der SAP-Business-Suite-Applikationen auf mobilen Geräten zur Verfügung gestellt werden.

Die Bereiche der SAP Business Suite sind:

• Finanzwesen
• Fertigung
• Beschaffung
• Produktentwicklung
• Marketing
• Vertrieb
• Service
• Personalwesen
• Logistikabwicklung
• IT-Management

So überzeugend dies für das Geschäft ist, gilt es, die Herausforderungen der Einführung für Anwender und Informatik von SAP Mobile Computing im Unternehmen zu beachten. Es sind dies, wie generell für alle Mobile-Computing-Anwendungen, zu niedrige Datenübertragungsgeschwindigkeiten und die unterschiedlichen Anforderungen der nicht standardisierten mobilen Geräte von Smartphones bis Notebooks. Hinzu kommt im Fall von SAP, dass sich sowohl Entwicklung wie auch Betrieb um diezugehörigen Entwicklungswerkzeuge und die benötigte Middleware-Plattform kümmern müssen. Dies nicht nur bei der Entwicklung und Einführung, sondern vor allem für sämtliche Änderungen über den ganzen Lebenszyklus der mobilen Applikationen hinweg.

Herausforderungen für Entwicklung, Lifecycle-Management und Betrieb

Für die Entwicklung stellt SAP Netweaver eine umfassende Entwicklungsplattform zur Verfügung – auch für die Entwicklung der Anwendungen mit mobilen Geräten als Frontend. Was auf dem Papier ganz einfach und überzeugend aussieht, sollte man in der Praxis betreffend der Konsequenzen dennoch genau überprüfen. Von Entwicklung und Einsatz mobiler Anwendungen und Geräte ist beim SAP-System nämlich nicht nur das mobile Frontend betroffen. Vielmehr sind in verschiedensten Bereichen Auswirkungen auf des ganze System und seinen Unterhalt zu erwarten. Aus technologischer und vor allem Software-logistischer Sicht bedarf SAP Netweaver Mobile bereits zweier unabhängiger Umgebungen!

SAP Netweaver Mobile benötigt die Installation

• eines ABAP-Application-Servers
• wie auch eines Java-Application-Servers

Auf diesen Application-Servern sind zusätzlich jeweils die von den Applikationen benötigten ABAP- oder Java-Add-Ins zu installieren. Das Zusammenspiel der Komponenten zeigt die Grafik “Komponenten der SAP Netweaver Mobile Platform”.

Wesentliche Auswirkungen von der Einführung mobiler Anwendungen sind im SAP System auf drei Systemkomponenten zu erwarten:

1. auf dem Netweaver- Java-Application-Server,
2. dem Netweaver-ABAP-Application-Server
3. ebenfalls auf dem SAP-Backend-System.

SAP-Netweaver-Java-Application-Server

Auf dem Java-Application-Server werden die Frontend-Applikationen entwickelt. Für die Entwicklung dient das SAP NWDS (SAP Netweaver Development Studio). Zur Ausführung kommt der Java Code auf dem SAP-NWJava-Application-Server. In der professionellen Entwicklungsumgebung wird die Java Softwareversionierung über die SAP NWDI (SAPNetweaver-Development- Infrastruktur) vorgenommen.

SAP-Netweaver-ABAP-Application-Server

Der ABAP-AS stellt entsprechend dem Business-Szenario der mobilen Frontend-Anwendung die Teildatenmengen bereit, die für den End-Nutzer direkt vor und nach dem Mobile-Device repliziert werden. Voraussetzung hierfür ist ein direkter Zugriff auf die SAP-Backend-Systeme. Der von SAP hierfür zur Verfügung gestellte Mechanismus ist die “Data Orchestration Engine”.

Konventionelle SAP-Datenhaltung im SAP-Backend

In der Praxis sind die Anforderungen von mobilen Lösungen so, dass die bereits definierte, entwickelte und durch Customizing erstellte SAP-Business-Logik meist nicht genügt. So müssen auch am SAP-Backend für die mobilen Applikationen Code-Änderungen vorgenommen und Einstellungen angepasst werden.

Achtung beim Einsatz mobiler SAP-Anwendungen von SAP …

SAP selbst bietet vorgefertigte mobile Anwendungen, sogenannte “SAP xApps for Mobile Business” an. Aufgrund der systemübergreifenden Zusammenhänge innerhalb der SAP Umgebung bedingt eine Einführung eine umfassende Voranalyse. In der Praxis zeigt sich, dass aufgrund der Geschäftsanforderungen an solche Anwendungen, der von SAP ausgelieferte Standard umfassend erweitert werden muss. Anforderungen an mobile Erweiterungen müssen deshalb genauso schriftlich formuliert sein und zu jeder Anforderung muss der Lösungsansatz konzipiert sein.

… und SAP-Partnern

SAP-Entwicklungspartner und SAP-Beratungshäuser bieten diverse Produkte an. Oft sind dies ursprünglich spezifische Kundenimplementierungen, die so generisch auf den Markt gebracht werden. Hierbei ist zu beachten, inwieweit diese Produkte wirklich dem generellen Anspruch von SAP Mobile Computing standhalten. Es ist zu prüfen, ob solche Produkte auf SAP Netweaver Mobile 7.1 basieren und die zur Verfügung stehenden SAP-Architekturkomponenten wirklich nutzen. Leider enthalten die ursprünglich kundenimplementierungsbasierten Lösungen oft Architekturabhängigkeiten des ersten Auftraggebers, was aus Sicht des damaligen Auftraggebers Sinn machte, jedoch zusätzliche Bedingungen und Komplexität bei Einführung und Unterhalt mit sich bringen kann.

Herausforderungen Beim Unterhalt von Mobile Solutions für SAP

Aus Software-logistischer Sicht stellt sich die komplexe, mehrstufige Umgebung als grosse Herausforderung dar. Es kommen Software-Komponenten zum Einsatz mit bis mindestens je drei unabhängigen Software-Entwicklungswerkzeugen, Systemumgebungen und ihren zugehörigen Einstellungen. Diese sind laufend synchron zu managen, was einen nicht zu unterschätzenden zusätzlichen Aufwand bedeutet. Wenn im Unternehmen einzelne dieser Komponenten noch nicht intensiv genutzt wurden, bedeutet dies unter Umständen einen massiv grösseren Bedarf an Ressourcen und Mitteln in der SAP-Informatik.

Fazit

Für SAP-Anwender ist die Versuchung gross, der Vorstellung zu verfallen, dass alles, was von SAP ausgeliefert wird, auch direkt die eigenen Anforderungen erfüllt. Ein umfassendes, Software-neutrales Pflichtenheft zeigt sofort Lücken auf und ist deshalb ein absolutes Muss für die erfolgreiche Einführung von Mobile Computing für SAP. Es ist fatal, wenn man erst spät feststellt, dass die scheinbar einfachen, oft unausgesprochenen Erwartungen von Business und IT an Mobile Computing grosse Aufwendungen für Entwicklung, Betrieb und vor allem Unterhalt nach sich ziehen. SAP stellt eine gute Basis für mobile Computing zur Verfügung, trotzdem ist bei der Implementierung von Mobile-Frontends ein äusserst professionelles Vorgehen gefragt.