Kategorie: SAP

SAP – bis zu 30% zu teuer! Warum SAP-Betrieb so teuer ist und was man dagegen tun kann. Viele Unternehmen zahlen für ihren SAP-Betrieb 20-30% mehr als nötig. Die Ursachen: zu viele manuelle Prozesse, fehlende Automatisierung im Transportmanagement, unstrukturiertes Change Management und hoher Testaufwand durch mangelnde Impact-Analyse. beteo zeigt konkrete Hebel zur Kostensenkung: Automatisiertes Transport-Management reduziert Fehler und Aufwände. Professionelles ALM vermeidet teure Feuerwehreinsätze. Impact-Analysen vor Änderungen senken Testaufwände um bis zu 40%. Klare Governance-Strukturen eliminieren Doppelarbeiten.

SAP Architektur und Kostenoptimierung – beteo Analyse. Die SAP-Architektur hat direkte Auswirkungen auf die Betriebskosten. Eine sauber strukturierte, komponentenbasierte Architektur reduziert Wartungsaufwände und ermöglicht selektive Updates. beteo empfiehlt regelmässige Architektur-Reviews als Teil des SAP ALM.

SAP Template, die Grundregeln für den erfolgreichen Konzernrollout. Ein SAP Template definiert die unternehmensweit einheitliche Grundkonfiguration des SAP-Systems. Klare Governance, Versionsmanagement und ein strukturiertes Change Management sind die Grundpfeiler für einen erfolgreichen Konzernrollout. beteo empfiehlt: Template-Ownership klar definieren, Customizing-Änderungen strikt versionieren und vor jedem Rollout impact-analysieren.

SAP Transport-Maturitätsmodell – beteo hat ein Reifegradmodell für SAP Transport-Management entwickelt. Das Modell unterteilt die Transportreife in 5 Stufen: von manuellen, fehleranfälligen Prozessen bis hin zu vollautomatisierten, compliance-konformen Abläufen. Unternehmen können damit ihren aktuellen Reifegrad bestimmen und gezielte Massnahmen zur Verbesserung ableiten.

SAP Change & Transport Management – effizient und sicher 04.06.08 by Dieter Steiger Statt laufend für viel Geld mit Feuerwehreinsätzen Probleme nach dem Einspielen von Änderungen in die SAP Landschaft zu bekämpfen, kann eine werkzeugunterstützte, automatisierte SAP Change und Transportmanagementumgebung, mit eingebauten konsistenzsichernden Massnahmen die Ursachen der Probleme ein für alle mal beseitigen. Die zu treffenden Massnahmen lassen sich in organisatorische Massnahmen, technische Transportvalidierung, Konsistenzsicherungsmassnahmen mit horizontaler und vertikaler Wirkung unterteilen.

Fazit Mit einem gewissen Fatalismus lösen viele grosse SAP Organisationen immer noch die durch Transporte von Änderungen entstehenden Probleme reaktiv. Die so entstehenden Kosten werden als systembedingt einfach akzeptiert. Dabei können mit einem sauberen, automatisierten Prozess und eingebetteten Konsistenzsicherungsmassnahmen viele dieser Aufwände ein für allemal eliminiert werden.

Ist das SAP Enhancement-Package Framework das erhoffte „Alle“?

Oft werde ich von Kunden gefragt, ob SAP Enhancement-Packages (SAP EHP) entsprechend einfach eingespielt werden können. Denn die Erwartung, die hinter SAP EHP steht, ist sehr hoch: SAP Enhancement-Packages sollen die von Kunden geliebte Anpassungsfähigkeit des SAP-Standards bei Upgrades gewährleisten und dabei gleichzeitig den Aufwand reduzieren.

Diese Erwartung widerspiegelt sich in der SAP-Marketing-Botschaft, welche Enhancement-Packages als die Lösung schlechthin für alle Kunden versteht, die auf SAP upgrades verzichten können wollen.

Doch lassen wir besser einmal die Fakten sprechen: Was können Enhancement-Packages, und was können sie nicht?

SAP Enhancement-Packages sind Funktionalitätspakete. Ihre Vorteile liegen vor allem in den Bereichen:

Upgrades ausgelieferter Funktionalitäten (Business Functions) – mit weniger Aufwand und tieferen Unterhaltskosten als klassische SAP-Upgrades

Diese Vorteile kann ein SAP Enhancement-Package allerdings nur in einem begrenzten Kontext einlösen: wenn keine oder nur wenig Kundenentwicklungen/-anpassungen vorhanden sind. Mit Kundenentwicklungen/-anpassungen meine ich ABAP-Änderungen, Anpassungen an Modulen/Klassen, kundeneigene Transaktionen/-programme etc. usw. – alles, was dem entsprechend im CIM-Modell als kundeneigene Software-Artefakte verwaltet werden muss. Was Enhancement-Packages explizit nicht können:

Klare Verantwortlichkeiten zurück zu den kundeneigenen Softwareartefakten herzustellen („Separation of Concerns“ zügeln)

Kundeneigene Softwareartefakte (Customizing und Entwicklungen), welche im klassischen Quell-SAP-Objekte sind, zu identifizieren/versionsverwalten und insbesondere auf korrekte „Wirkung“ zu testen

Fazit: Wenn wir die bestehenden Kundenimplementierungen zum SAP Standard ins Verhältnis setzen – welcher Kunde kann ernsthaft auf sein kundeneigenes, gewachsenes SAP-„Customizing“ resp. „Enhancements“ verzichten? In der Praxis ist das wirklich nicht einfach. Somit wird klar: die technischen Möglichkeiten von Enhancement-Packages setzen in Sachen Flexibilität und Kundenspezifizierung klare Grenzen.
Dennoch, SAP Enhancement-Packages sind für SAP-Kunden die gehen wollen, eine reelle Option. Sie müssen aber als das verstanden werden was sie sind – eine Upgrade Option aus einer Vielzahl von Optionen.