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.

beteo AG befördert Marco Gerussi (31) per 1. Juni 2009 zum Chief Operating Officer. Damit löst er Peter Helfenstein ab, der während eineinhalb Jahren erfolgreich als COO tätig war. Gerussi war bisher als Leiter Consulting massgeblich am Aufbau des Unternehmens beteiligt.

Gerussi, studierter Betriebswirtschafter und Wirtschaftsinformatiker, war während der letzten zwei Jahre entscheidend am Aufbau der Geschäftsfelder Project and Portfolio Management, Application Change and Release Management sowie Application Quality Management beteiligt. Diese Dienstleistungen erbringt beteo hauptsächlich in den Ländern Schweiz, Deutschland und Österreich. Namhafte Kunden sind unter anderem Adidas, Daimler, HP Consulting, Roche Diagnostics, die SBB, SwissLife, Thyssen Krupp und das österreichische Bundesfinanzministerium.

„Mit Marco Gerussi konnten wir einen hervorragenden und erfahrenen Mitarbeiter zum COO befördern. Er verfügt über Führungserfahrung und kennt aus seiner bisherigen Tätigkeit als Leiter Consulting die Geschäftsfelder des Unternehmens bestens. Sein Erfolg bei unseren wichtigsten Kunden hat unsere Kompetenz bewiesen und unser Unternehmen nachhaltig gestärkt. Mit seiner Ernennung stellen wir sicher, dass die Ausrichtung der beteo AG auf Application Lifecycle Management (ALM) und die Kerngeschäftsfelder kontinuierlich weiterverfolgt wird, ” so Dieter Steiger, CEO und Gründer der beteo AG.

In den Medien:

• iTReseller
• ITnewsbyte
• Computerworld
• inside-channels.ch
• Netzwoche
• ICT News

Link zur Pressemitteilung:

Die Qualitätskontrolle darf nicht erst am Ende eines Projekts einsetzen. Um Irrwege frühzeitig erkennen zu können, sind Abschnittskontrollen nötig.  AXA Winterthur hat dazu das Modell der Quality Gates eingeführt.

Unzufriedene Kunden, überzogene Terminpläne, ein gescheitertes Projekt: Wenn der Ernstfall eintritt, wird es für Entwicklungsteam und Projektleiter unangenehm – Rettungsmassnahmen in letzter Minute sind teuer. Oft ist an solchen Misserfolgen eine mangelhafte Qualitätskontrolle schuld. Quality Gates können Abhilfe schaffen: Sie bringen nicht nur Nutzen für die Projektteams und -sponsoren, sondern auch für die Kunden.

CHECKPOINTS FÜR PROJEKTE

Quality Gates sind spezielle Projektmeilensteine, die sich beim Übergang zwischen zwei Projektphasen befinden. Sie werden speziell dort eingesetzt, wo die nachfolgende Phase auf besondere Weise von den Ergebnissen der Vorphase abhängig ist. Dies trifft beispielsweise auf den Übergang von der Konzeptions- zur Entwicklungsphase zu oder nach Projektabschluss bei der Überführung der Lösung in den Betrieb. Quality Gates dienen insbesondere zur

• Sicherstellung der Qualität in der Projektabwicklung
• Schaffen von Transparenz und Objektivität der Projektarbeit in der Organisation
• Verbesserung der Wirtschaftlichkeit durch frühzeitige Fehlererkennung.

Spätestens bis zur Erreichung der Quality Gates müssen ausgewählte Lieferobjekte, die in der Vorphase des Projekts erstellt wurden, anhand von definierten Erfüllungskriterien durch eine projektexterne Fachstelle auf ihre formale und inhaltliche Qualität überprüft werden. Welche Projektergebnisse der Prüfung zu unterziehen sind, wird im besten Fall zu Beginn des Projekts, spätestens aber in der Vorbereitung der entsprechenden Projektphase durch das Erstellen einer Tailoring-Vereinbarung festgelegt. Die Ergebnisse der Quality Reviews bilden die Grundlage für die Steuerung des Projekts. Wurden keine schwerwiegenden Mängel festgestellt, so erhält das Projekt die Freigabe für die nächste Phase (grüne Ampel). Bei befunden, die ein geringes Projektrisiko mit sich bringen, kann das Projekt im Normalfall unter Einhaltung von Auflagen weitergeführt werden (orange Ampel). Weist das Projekt hingegen schwerwiegende Mängel auf, die den Projekterfolg nachhaltig gefährden, wird das Projekt gestoppt (rote Ampel). Die Freigabe für die Weiterführung wird erst dann erteilt, wenn die Mängel behoben sind und dies durch einen weiteren Review bestätigt wurde.

Quality Gates: Kontrollpunkte beim Übergang von einer Projektphase in die nächste

BEISPIEL AXA WINTERTHUR

Mitte 2008 bekam ein Projektteam der AXA Winterthur den Auftrag, Quality Gates für die Projektabwicklung einzuführen. Da damit auch ein organisatorischer Kulturwandel verbunden war, wurde speziell darauf geachtet, das Modell stufenweise zu etablieren.

1. Konzept & Prozess: In einer ersten Phase wurde das Konzept der Quality Gates erarbeitet. Anschliessend folgten die Erstellung von Prozessen und der daran beteiligten Rollen und die Bereitstellung von Hilfsmitteln zur Durchführung der Quality Gates. Zur Lösungsfindung bei der Modellentwicklung hat sich der Einsatz eines «Morphologischen Kastens» sehr bewährt. Das so entwickelte Modell weist dabei folgende Hauptmerkmale auf:

• Quality Gates jeweils nach Abschluss der Projektinitialisierung, des Grobkonzepts und des Detailkonzepts Prüfung der Lieferobjekte mit Schwergewicht auf Projektmanagement und Anforderungsdefinition (Requirements Engineering)
• Zentrale Koordinationsstelle für die formale Prüfung der Lieferobjekte und zur Erstellung des Qualitätsberichts zu Händen des Projektsponsors
• Methodenkompetenz-Center für die inhaltliche Prüfung der Lieferobjekte und Erstellung eines Review-Protokolls

2. Einführungsphase: Um die aus der Praxis gewonnenen Erkenntnisse für die Optimierung des Modells nutzen zu können und die Organisation schrittweise darauf vorzubereiten, wählte das Management für die erste Phase sechs Projekte aus. Anschliessend fanden Kurzschulungen (ca. 60 Minuten) für Projektsponsoren, Projektleiter, Koordinationsstelle und Methodenkompetenz- Center statt. Zur Durchführung und Dokumentation der Quality Gates war zudem Infrastruktur nötig. Auf die Automatisierung des Prozesses wurde dabei bewusst verzichtet und einzig mit Ablageverzeichnissen und unpersönlichen Mailkonten gearbeitet. Den Abschluss der Einführung bildete die «Einphasung »: Dabei galt es, zu definieren, in welcher Phase sich die Projekte aktuell befinden und welche Lieferobjekte erstellt und geprüft werden sollten (Tailoring-Vereinbarung).

3. Optimierung: Aus den gesammelten Erfahrungen soll in einem nächsten Schritt das Modell optimiert und ausgebaut werden. Dabei gilt es, zu klären, welche weiteren Quality Gates eingeführt werden sollen (z. B. am Projektende) und welche Lieferobjekte dabei zu prüfen sind. Zudem geht es darum, das Modell weiter zu standardisieren und in der Organisation zu verankern. Dazu gehört die Auswahl weiterer Projektkandidaten für die zweite Einführungsphase. Als weiterer Ausbauschritt wird die workflowunterstützte Automatisierung des Prozesses in Betracht gezogen.

ERFOLGSFAKTOREN

Zur erfolgreichen Einführung sind folgende Faktoren wichtig:

• Commitment der Geschäftsleitung und Einbezug der Organisation zur Sicherstellung des organisatorischen Wandels
• Ausweisung des Nutzens der Quality Gates
• Stufenweise, organisationsverträgliche Einführung
• Unterstützung und Begleitung aller Beteiligten in der ersten Einführungsphase
• Sammeln von Erfahrungen und Umsetzen von Verbesserungen zur Modelloptimierung.

Vor kurzer Zeit konnte ich im Rahmen einer DSAG Veranstaltung einer einstündigen Präsentation mit Live-Demo zum Thema Business Process Change Analyzer lauschen. Das Tool ist ja brandneu, und im SAP SolutionManager Enterprise Edition enthalten.

Was ist der SAP Business Process Change Analyzer?

Mithilfe des SAP Business Process Change Analyzer soll der Einfluss von technischen Änderungen auf die laufenden Geschäftsprozesse ermittelt werden können. Dabei können sowohl eigene Transporte, als auch SAP-Transporte (z.B. Support Packages) analysiert werden.

Vorraussetzungen für den Einsatz

• Grundvorraussetzung ist ein gepflegtes Business Process Repository. Also die, zumindest rudimentäre Dokumentation aller Geschäftsprozesse im Solution Manager, bis auf Transaktionsebene hinunter.
• Zweite Vorraussetzung ist, dass für jede einzelne, dokumentierte Transaktion die sog. T-BOM (Technical Bill of Material) aufgezeichnet wird.

Wie funktioniert der SAP Business Process Change Analyzer?

Die Analyse wird gestartet, indem man dem Tool die Liste der zu überprüfenden Tranporte mitgibt. Der Schlüssel der Analyse ist die T-BOM. Die Liste der darin enthaltenen Objekte wird mit den Objektlisten in den zu prüfenden Transporten verglichen und anschließend als Trefferliste ausgegeben.

Warum das Konzept des SAP Business Process Change Analyzer nicht aufgehen kann

Die notwendige Dokumentation der Prozesse und der dazugehörigen T-BOMs wird nie im notwendigen Umfang und der nötigen Aktualität vorhanden sein. SAP selbst “empfiehlt” diese für die Kernprozesse zu erstellen. An diesem Punkt stellt sich für mich die Frage, wozu überhaupt für Kernprozesse eine Impact Analyse gemacht wird.

Prozess ABC-Analyse

Kernprozesse definiere ich gerne, als die Prozesse, die wenn sie auch nur kurz stillstehen, einen erheblichen finanziellen und Image- Schaden herrvorrufen. Meiner Erfahrung nach beinhalten diese Prozesse bei den meisten Unternehmen nicht mehr als 10-30 SAP Transaktionen. Umgekehrt werden durchschnittlich rund 2.000-6.000 SAP Transaktionen von allen Benutzern pro Monat genutzt.

Allein diese Zahlen belegen, dass sich hier eine große Kluft ergibt. Bei meinen Kunden empfehle ich, immer eine ABC Analyse der genutzen Transaktionen vorzunehmen. Wobei Transaktionen, die die A-Kategorie hineinfallen, auf jeden Fall getestet werden sollten, ganz egal was eine etwaige Analyse auch immer empfiehlt. Kategorie A sind auch genau die Prozesse, bei denen es Sinn macht an ein Test-Automatisierung zu denken.

Kategorie B Transaktionen sind jene, die bei Stillstand erheblichen Reibungsverlust intern verursachen und damit zu teilweise nicht unbeträchtlichen Kosten führen. Hierbei handelt es sich aber sehr oft um Objekte, die wenig Aufmerksamkeit erhalten, da sie eben nicht in den Kernprozessen verankert sind. Aus diesem Grund, und weil es sich um  ca. 400 bis 1200 Transaktionen (20% nach der 80/20 Regel) handelt, existiert für diese Klasse auch nur wenig Dokumentation, meist gar keine. Die T-BOMs für 400 bis 1200 (oder mehr) Transaktionen aktuell zu halten, ist praktisch unmöglich. Dabei würde es gerade in dieser Klasse Sinn machen, eine Risikoabschätzung mittels Impact Analyse durchzuführen, um im Anschluss daran eben nur die riskantesten Objekte zu testen zu müssen.

Kategorie C ist schnell abgehandelt. Hierunter sind Objekte zu verstehen, die auch im Stillstand zu keinen großen Störungen führen, und deren Behebung durchaus länger dauern darf. In dieser Kategorie kann auf proaktive Tests verzichtet werden.

Neben diesen aus meiner Sicht prinzipiellen Konzeptmängeln gibt es noch einige technische Details, z.B. bei der Erstellung der T-BOMS, wo ich eine Art deja-vu erlebe und ich SAP hier am Beginn einer Reise sehe, wo IntelliCorp schon vor 5 Jahren war.

Über den Autor: Fritz Mosonyi ist Senior-Berater und Bereichsleiter für SAP-Tools beim beteo Partner SPP Wien.