SAP Solution Manager 7.2 – Funktionalität versus Content


Steine und Asphalt machen noch lange keine Straße, aber über einen Plan kann man auch nicht fahren

Mit der Etablierung des SAP Solution Managers 7.2 und seinen innovativen Funktionalitäten stellt sich erneut die Frage nach der Gestaltung des Contents. Denn aussagekräftiger Content ist entscheidend für die Nutzbarkeit der Neuerungen und dies betrifft vor allem die Abbildung der Prozessabläufe und Abwicklungsroutinen im Rahmen des Process Managements bzw. der Lösungsdokumentation. Wenn man eine Straße baut, dann hat das zwar auch mit Steinen, Asphalt und jeder Menge Arbeitskraft zu tun. Aber wenn man einen Ingenieur fragt, dann wird er sofort anmerken dass es auf die richtige Planung ankommt. Und die kann man gerne mit der Bereitstellung ausgeklügelter Funktionen vergleichen. Nur, ohne die Bestandteile der Straße geht es auch nicht, es sei denn man fährt gerne Offroad.

Eine vergleichbare Diskussion ergibt sich auch bei der Betrachtung eines neuen Application Lifecycle Management Systems (ALM). Denn jedes noch so funktionale ALM braucht vor allem eines – die richtigen Inhalte, die zur jeweiligen Geschäftstätigkeit passen und die alle Stakeholder verstehen. Zwar herrscht im Grunde ein Konsens darüber, dass aussagekräftige Prozessstrukturen als fixer Bestandteil einer Lösungs- bzw. Prozessdokumentation gebraucht werden. Denn eine technisch fokussierte Sichtweise des funktionalen Repertoires eines Unternehmens mag der IT Abteilung genügen, doch liefert sie keinerlei Einsichten in die betriebswirtschaftlichen Abläufe. Aber die Erstellung und vor allem die Pflege einer umfassenden Dokumentation der Geschäftstätigkeiten – basierend auf den verwendeten Programmen, Schnittstellen und Systemen – ist aufwändig und somit auch kostspielig. Dennoch ist dieses Hilfsmittel unerlässlich für die Unterstützung umfassender ALM-Funktionalitäten wie dem Testmanagement, dem Prozessmonitoring oder dem Change Management.

Insofern stellt der Übergang auf den SAP Solution Manager 7.2 einen echten Fortschritt dar. Dank einiger Innovationen, wie dem Branch-Konzept, der unbeschränkten Ebenendefinition im Process Management, dem Library-Ansatz für Objekte aller Art, die integrierte Modellierungsfunktion auf BPMN Basis sowie die Fähigkeit, Prozessvarianten zu definieren, werden viele Anwenderwünsche erfüllt. Zumindest theoretisch. Denn all diese Funktionalitäten sind nur so gut wie ihr Content und genau dies ist die Schwachstelle des „neuen“ SAP Solution Managers. Auch wenn aktuelle Zahlen belegen, dass immer mehr Unternehmen die Migration auf die Version 7.2. des SAP Solution Managers durchführen. Es darf bezweifelt werden, ob dieser Übergang dann auch in jedem Fall eine inhaltliche Innovation mit sich bringt oder ob diese Migrationen primär technischer Natur sind mit einer Priorisierung der Service-Funktionen.

Drei aktuelle Einsatzszenarien

Drei auf den ersten Blick unterschiedliche Diskussionen aus unseren aktuellen Kundenprojekten belegen dies. Dabei kommt es weniger auf die Größe des jeweiligen Unternehmens an, noch auf den letztendlichen Fortschrittsgrad in punkto ALM Umsetzung. Der entscheidende Aspekt ist die gemeinsame Forderung nach aussagekräftigem Content, der nicht nur zu den funktionalen Möglichkeiten der im Einsatz befindlichen ERP-Systeme passen, sondern eben auch zur Unternehmensrealität der Kundenprozesse.

  1. Bei einem Mittelständler mit zwei ERP Systemen für weitgehend unabhängige Gesellschaften waren wir gefordert, eine umfassende Dokumentation für zukünftige Change-Projekte und die damit verbundenen Testszenarien aufzubauen. Neben der Anpassung der SAP Standardprozesse an individuelle Abläufe war es entscheidend, die historisch gewachsenen Programme und Modifikationen zu validieren und auf ihre tatsächliche Nutzung zu überprüfen.
  2. Ein internationales Großunternehmen mit Wachstumsplänen bat uns um eine Abschätzung der Machbarkeit und Umsetzung ihres geplanten ALM Konzeptes. Dieses sollte nicht nur auf einem integrativen Dokumentationskonzept basieren, sondern die über die Jahre gesammelten heterogenen Dokumentationsbestände mit einbeziehen. Auch an dieser Stelle galt aus unserer Sicht, dass die tatsächliche Systemnutzung im Vordergrund stehen sollte und damit den Umsetzungsumfang – sowie den -grad vorgeben muss.
  3. In UK wurden wir hinzugezogen, um die ALM gestützte Harmonisierung und Standardisierung in einem Konzern voranzutreiben. Für diesen Rollout haben wir den nutzungsbasierten Abgleich mit Hilfe von Prozesstemplates empfohlen, der mit umfassender Analytik die Prozessidentifikation, Konfigurationsvalidierung sowie die Ausnahmenfindung hinterlegt war.

Es zeigt sich, dass die entscheidende Forderung nach aussagekräftigem Content in allen Kundenszenarien bestand. Um diesen erstellen zu können bedarf es solider Standards, umfassender funktionaler Templates, bereichsübergreifende Projekterfahrungen sowie anwendungsfallbezogener Analyse-Werkzeuge.

Funktionalität versus Content

Vor diesem Hintergrund beschäftigen wir uns nicht erst seit heute mit der Frage, wie geeigneter Prozesscontent aussehen muss und wie dieser, vor allem im Hinblick auf die zukünftige Pflege, sinnstiftend und bezahlbar entwickelt werden kann. Dabei folgt der Aufbau von Prozessinhalten bei allen Unterschieden von Unternehmen zu Unternehmen ganz vergleichbaren Fragestellungen:

  • Welche Prozessschritte machen einen Prozess aus?
  • Welche Programme und Objekte werden in einem Prozess genutzt?
  • Wie oft werden diese Executables überhaupt genutzt und in welchem Zusammenhang?
  • Wie viele User sind in einem Prozess aktiv?
  • Wie viele Belege oder Datensätze werden in den verschiedenen Prozessen generiert und bearbeitet?
  • Welche organisatorischen oder regionalen Unterschiede gibt es?
  • Welche Prozessvarianten existieren und was unterscheidet sie?
  • Welche Konfiguration liegt den Prozessen zugrunde?
  • Welche Ausnahmen und Fehler treten auf?
Determinanten der Prozessdarstellung

Determinanten der Prozessdarstellung

Um Antworten auf diese Fragen zu finden, benötigt man vor allem eine umfassende Informationsbasis. Dabei ist es nicht ausreichend, sich ausschließlich auf die doch eher subjektiv geprägten Erfahrungen der Mitarbeiter zu verlassen. Diese spielen zwar eine entscheidende Rolle bei jedem Projekt zur Prozessdokumentation, doch stellen sie nur eine mögliche Inputquelle dar. Eine umfassende Analyse aller Prozessdeterminanten muss alle Aspekte berücksichtigen, die einen betriebswirtschaftlichen Ablauf prägen.

Vor dem Hintergrund dieser Prozessdeterminanten erscheint es alles andere als leicht, sinnvollen Dokumentationscontent für eine ALM-Umgebung zu definieren. Einmal mehr zeigt sich dabei, dass seine eingeschränkte Sichtweise der Prozesswelt eines Unternehmens den gestellten Anforderungen nicht gerecht werden kann. So verliert sich beispielsweise bei einer einseitigen Fokussierung auf die Executables in Form von Transaktionen und Programmen der betriebswirtschaftliche Kontext nahezu vollständig. Insbesondere um bestehende Dokumentationen sinnvoll in das Konzept einzubeziehen, den verschiedensten Stakeholdern einen zielgerichteten View oder gar Workflow auf die Inhalte zu liefern und klare Abgrenzungen wie Gleichläufigkeiten von Prozessen – global wie lokal – zu schaffen, empfiehlt sich der Einsatz objektiver Analytik, die in hunderten Kundenprojekten gereift ist. Die RBE Plus Analyseprodukte liefern genau das, umfassende Systemnutzungsanalysen, die eine Identifikation und Verifikation von Prozessinhalten ermöglichen und damit den schnellen und leichten Einstieg in eine individuelle Prozessdokumentation ermöglichen. Dabei hilft ein toolorientierter Definitionsprozess, der mittels bestehender Schnittstellen den gewünschten Content in den eigenen SAP Solution Manager übertragen lässt, ausgehend von der tatsächlichen Verwendung der eigenen SAP Systeme.

 

Fazit

Zusammenfassend lässt sich feststellen, dass eine Prozessdokumentation je nach geplantem Anwendungsszenario den folgenden Richtlinien entsprechen sollte:
Sie sollte
  • umfassend und realitätsbezogen sein,
  • alle prozessrelevanten Systeme enthalten,
  • auf Standardinhalten und Templates basieren,
  • fokussiert sein auf die ALM Ziele und Nutzung,
  • verständlich und nachvollziehbar sein und
  • offen für Veränderungen und leicht zu pflegen sein.
Gemessen an diesen Kriterien ist auch der zielgerichtete Ausbau einer „Prozess-Straße“ für jeden Ingenieur möglich. Und mit den richtigen Hilfsmitteln, beispielsweise in Form umfassender Systemanalysen, ist dies dann auch effizient und effektiv leistbar. Ohne Angst haben zu müssen vor den Änderungen und Herausforderungen der Zukunft.

Kommentar erstellen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

1 × 4 =