SAP ALM Lösungsansatz hat grosse Lücken – eine kritische Analyse. Der SAP Solution Manager deckt zwar viele ALM-Bereiche ab, lässt aber wesentliche Lücken offen. Die grössten Defizite: fehlende durchgängige Traceability von Anforderungen bis zur Implementierung, mangelhafte Customizing-Versionierung, unzureichendes Abhängigkeitsmanagement in heterogenen Landschaften. beteo empfiehlt eine ergänzende ALM-Toollandschaft, die diese Lücken schliesst und eine echte End-to-End Transparenz über den SAP Lebenszyklus ermöglicht.
Kategorie: SAP ALM
SAP Application Lifecycle Management – Change Control, Solution Manager, Transport, Upgrades
-
SAP – bis zu 30% zu teuer!
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
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
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
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.
-
Aufbau ALM Basis Testing
Aufbau ALM Basis Testing – SAP Application Lifecycle Management Grundlagen. ALM beinhaltet die Verwaltung und Optimierung aller Phasen des Software-Lebenszyklus. Für SAP-Umgebungen bedeutet dies eine besondere Herausforderung aufgrund der Komplexität und Heterogenität des Systems.
-
SAP Solution-Manager die Checklistensoftware?
SAP Solution-Manager die Checklistensoftware? ALM für SAP? Da haben wir doch den Solution Manager!? In der Tat: Nehmen Sie sich eine Checkliste zum 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 des SAP Solution Manager das Thema Application Lifecycle Management vollständig abgedeckt.
Sie ahnen bereits, dass ich mich nicht so schnell zurücklehnen möchte. Eine ALM-Lösung hat ihr Nutzenoptimum, wenn alle Teile ineinandergreifen und sich zu einem geschlossenen Prozess verbinden lassen.
Der SAP Solution Manager bietet inzwischen für viele Bereiche des ALM gute Einzellösungen – bei dem von mir skizzierten voll integriertem ALM sind jedoch noch einige Lücken zu schließen – da die Integration der einzelnen Lifecycle-Phasen noch nicht sehr weit vorangeschritten ist.
Fazit: Es gibt bereits erfolgreiche Referenzprojekte, in denen unter Zuhilfenahme der richtigen Werkzeuge und Methoden integrierte ALM-Lösungen für SAP-Umgebungen geschaffen wurden.
-
SAP Enhancement Packages: Doch kein Allheilmittel
Das neue Konzept der Enhancement Packages (EhPs) von SAP ist aus technischer Perspektive genial. Es ist eigentlich schade, dass SAP, der Anbieter par excellence für Unternehmenssoftware, so lange gebraucht hat, um dieses Software-Logistics-Konzept zu entwickeln.
Dennoch ist die Sache nicht so einfach, wie man hoffen könnte. Enhancement Packages versprechen die selektive Übernahme neuer Funktionalität ohne vollständige System-Upgrades. In der Theorie können Kunden neue Features aus einem EhP implementieren, ohne alle darin enthaltenen Änderungen aktivieren zu müssen.
Die Realität ist jedoch komplexer. Die Abhängigkeiten zwischen verschiedenen Funktionsbereichen in SAP bedeuten, dass die Aktivierung einer Funktion oft die Aktivierung anderer erfordert. Der Testaufwand bleibt erheblich, da selbst eine ’selektive‘ Aktivierung unerwartete Auswirkungen auf bestehendes Customizing und Eigenentwicklungen haben kann.
beteos Erfahrung mit Enhancement Package-Projekten zeigt, dass der Erfolg erfordert: gründliche Pre-Aktivierungs-Impact-Analyse mit spezialisierten Tools, sorgfältige Teststrategie, erfahrenes Projektmanagement und einen schrittweisen Ansatz, der Risiken managt und gleichzeitig Mehrwert liefert.
Enhancement Packages sind ein Schritt in die richtige Richtung, aber kein Allheilmittel. Kunden sollten mit realistischen Erwartungen an sie herangehen.
-
Ist das SAP Enhancement-Package Framework das erhoffte „Alle“?
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. -
Ist das SAP Enhancement-Package Framework das erhoffte „Allerheilmittel“?
Ist das SAP Enhancement-Package Framework das erhoffte „Allerheilmittel“?
Das Konzept der Erweiterungspakete (Enhancement Packages Framework, kurz EhPs) ist schlichtweg genial. Betrachtet man aber wie lange SAP als der Standardsoftwarelieferant für Business-Software schlechthin, gebraucht hat diese Softwarelogistik Disziplin zu etablieren, kann nicht mehr von Genialität die Rede sein. Was das Fehlen dieses Frameworks bis anhin die Kunden gekostet hat, sollte jeder Kunde für sich selbst beziffern. Aus softwarelogistischer Sicht hat SAP endlich seine Hausaufgaben gemacht, jedoch auch hier wiederum (verweis auf meinen Blog solman nur für standard nicht für kundenen impl) nur den Fokus auf die Standardsoftware bezogen. Das EhPs bezieht sich leider auch weiterhin nicht auf die Kundenimplementierungen, Impact-Analysen wie sie Intellicopr und Panaya für die grössten Investiontionen einer SAP Implementierung zur Verfügung stellen sind inexistent. Über Lösungsansätze von SAP selbst habe ich mich schon in blog… ausgelassen.
Was bedeutet dies nun für SAP Kunden welche bereits den Schritt auf EhPs (Voraussetzung SAP NetWeaver 7.0 http://help.sap.com/saphelp_smehp1/helpdata/de/12/2d88848a62446181ce2c1bbafcc8c9/content.htm) gemacht haben. Für solche die noch nicht auf SAP NW 7.0 sind ist leider immer noch der konventionelle SAP Upgrade Voraussetzung.
Basistechnisch: Die entsprechenden EhPs können zeitneutral eingespielt werden, d.h. der physische Aufwand bleibt nach wie vor, jedoch ist die direkte zeitliche Abhängigkeit der betriebswirtschaftlichen Nacharbeiten (businesstechnisches Einspielen EhPs)losgelöst.
Businesstechnisch: In einem ersten Schritt (Vorbereitung) müssen alle zusätzlichen Anforderungen an neue von SAP im EhP gelieferten Funktionalitäten gesammelt werden. Basierend auf diesen muss unbedingt eine konkurrierende Analyse zur konfigurierten Basis (ALM – Investitionsschutz), als auch das Evaluieren der neuen Funktionalität auf von SAP im Internet zur verfügbaren Systemen geprüft werden. Mittels dieser Analyse kann erst der Auswirkungsgrad eines businesstechnischen Einspielens von EhPs bestimmt werden. Das Aktivieren der einzelnen Business-Switches fordert die Auswirkungsanalyse umso mehr heraus, denn nun muss wirklich evaluiert werden, welche „Transaktionsbereiche“ nun wirklich auch in der Unternehmung genutzt werden. D.h. Auswirkungsanalyse auf logische (verweis auf blogs) und technische Objekte ist unabdingbar. Die Auswirkungen haben sie vermutlich schon selbst erfahren, wie die meisten mir bekannten Kunden, mit jedem Upgrade oder nun „businesstechnisches Einspielen von EhPs“ wird das ganze implementierte Applikationsportfolio immer wieder neu aufgebaut, damit die neuen technischen Funktionen auf Basis der alten technischen Funktionsweise sichergestellt werden können, anstatt aktiv nur noch das Delta zwischen alter und neuer Funktionalität zu bewirtschaften (Dokumentationen / Test / etc.). Ganz zu schweigen davon, dass auf Informationen von vorhergehenden Applikations-Changes zurückgegriffen werden kann. Wann werden SAP Kunden endlich aktiv, ihr Investitionen in die konkurrierende Umsetzung von SAP Initiativen und SAP-Betrieb in Form eines nachhaltigen SAP Applikations-Lifecycle-Management (kurz SAP ALM) zu unterstützen, ein solches Projekt ist der ideale Aufhänger für eine nachhaltiges SAP ALM.
Fazit: Das zeitaufwendige bestimmen, umsetzen und testen von neuen in Business bleibt immer noch der selbe, wenn nicht erhöht durch die zusätzliche Komplexität. Bedingt durch die neu zur Verfügung gestellte Business-Funktionalität wird konkurrierende Auswirkungsanalyse immer komplexer und deshalb auch zeitaufwendiger. Durch die zeitliche Entkoppelung des technischen Einspielens von EhPs, kann wohl Zeit gewonnen werden. Diese Zeitersparnis sollte aber mindestens bei der Auswirkungsanalyse reinvestiert werden, um nicht das Risiko von Produktionsstillständen einzugehen.