Dieter SteigerDieter Steiger SAP Template, die Grundregeln für den erfolgreichen Rollout im Konzern

14.04.10 by Dieter Steiger

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. Sphere: Related Content

Kommentar schreiben

XHTML: Sie können diese Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>