Blog

16. Jahrhundert. Die Augen eines Archäologen durchsuchen ein Feld. Er fragt sich, wo er anfangen soll zu graben. In seinem Leben hat er noch einige Jahre. Welcher Bereich würde aus seiner Erfahrung heraus die Chance einer Entdeckung bieten? Dann bemerkt er einen Baum. Zum Wachsen braucht er Nährstoffe, also könnte darunter etwas sein. Das weiss er aus Erfahrung.

Als er zu graben beginnt, stösst er auf ein kleines Haus einer eher armen Familie. Enttäuscht gibt er auf.
200 Jahre später wird ein grösseres Ausgrabungsprojekt gestartet. Die Siedlung erweist sich als wichtigste Informationsquelle über vergangene Zeiten.

SAP
Wer mich kennt, weiss meinen Schreibstil, der zur Übertreibung neigt. Nehmen wir ein typisches SAP-Projekt, zum Beispiel ein Release-Upgrade. Unterscheidet sich gar nicht so sehr von der Geschichte des unglücklichen Archäologen. Am Anfang weiss man oft wenig über ein System. Alles scheint unter der Erde zu liegen. Man fragt sich, wie man den Release-Wechsel angehen soll, und auf Basis welcher Informationen man eine Prognose wagen kann. Was wird während des Projekts passieren? Wenn man Glück hat, haben die Berater fundierte Kenntnisse des Systems und der darauf implementierten Prozesse. Wenn nicht, überschreitet das Projekt fast typischerweise seinen Umfang in den zwei Achsen Zeit und Budget. Da wichtige Projektphasen wie Testing und Endbenutzer-Schulung zugunsten der Implementierungsphase vernachlässigt werden, entsteht ein Qualitätsproblem. Dies wiederum hat Auswirkungen auf die dritte Achse: die Benutzerakzeptanz.

Der Ausweg
Typische SAP-Projekte wie Upgrades werden nach dem Wasserfallprinzip geplant. Dabei wird ein wichtiger Schritt dieser Methode massiv vernachlässigt: die Anforderungsanalyse, auch als Gap-Analyse bekannt – mit anderen Worten die Frage: «Wie hat SAP UNSEREN spezifischen Standard beeinflusst?» Wenn man diese einfache Frage bezogen auf eine SAP-Landschaft umfassend beantworten will, ist die einzige Lösung des «Problems» einer so umfangreichen Analyse ihre Automatisierung.

Wie gelangt man in kürzester Zeit zu qualitativ hochwertigen und vollständigen Informationen?
Es gibt eine Reihe von Anbietern, die Analysetools anbieten, von SAP Consulting über RBE bis zu IntelliCorp. Jedes dieser Tools fokussiert auf einen bestimmten Aspekt und hat daher seine individuelle Stärke.

IntelliCorps Assessor Template für SAP Upgrades adressiert das Problem auf einer breiten Basis. Das Tool bietet eine Vielzahl von vollautomatisierten Analyse-Workflows. Innerhalb weniger Tage – durchschnittlich drei – liefert es umfangreiches Material für eine detaillierte Planung des Upgrade-Projekts. Als Nebeneffekt bietet das Ergebnis der Implementierungsmannschaft eine solide Grundlage. Die hohe Flexibilität macht es zu einem geeigneten Tool für alle SAP-Anwendungen, einschliesslich kommerzieller Lösungen, Integration von Drittanbieter-Software oder eigener Namensräume in der Workbench.

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

Konfigurationsmanagement für SAP Customizing? Ein kritisch unterschätztes Thema in der SAP-Welt.

In Standard-Software-Entwicklungsumgebungen ist Konfigurationsmanagement – die systematische Verwaltung von Konfigurationseinstellungen mit Versionierung, Abhängigkeitsmanagement und Change-History – selbstverständlich. Im SAP-Customizing ist dies bis heute nicht der Standard.

Was fehlt im SAP Customizing-Management:

• Fehlende Versionierung: Es gibt kein Standard-SAP-Werkzeug, das eine granulare Versionshistorie für Customizing-Einstellungen bereitstellt
• Fehlende Abhängigkeitsverwaltung: Die Abhängigkeiten zwischen verschiedenen Customizing-Tabellen sind nicht transparent
• Mangelhafte Dokumentation: Wer hat wann welche Einstellung aus welchem Grund verändert?

Lösungsansätze:

• Drittanbieter-Werkzeuge (z.B. Intellicorp LCA) für Customizing-Versionierung
• Strukturierter Change-Request-Prozess mit Pflichtfeldern für Begründung und Impact
• Regelmässige Customizing-Audits

Proof of Concept – weniger Risiko bei Systemimplementierungen. Ein gut durchgeführter Proof of Concept (PoC) ist eine der wirksamsten Risikominderungsmassnahmen bei SAP-Projekten.

Wann ist ein PoC sinnvoll?

• Bei der Einführung neuer SAP-Module oder Technologien
• Bei der Integration von SAP mit Non-SAP-Systemen
• Bei der Implementierung neuer ALM-Werkzeuge
• Wenn grundlegende technische oder prozessuale Fragen ungeklärt sind

Erfolgsfaktoren für einen PoC:

• Klare Abgrenzung: Was soll bewiesen werden?
• Echte Daten und realistische Szenarien verwenden
• Feste Erfolgskriterien vorab definieren
• Zeitlimit setzen (typisch 2-4 Wochen)
• Ergebnisse dokumentieren und kommunizieren

Fazit: Ein PoC kostet Zeit und Geld – aber deutlich weniger als ein gescheitertes Vollprojekt. Für alle komplexen SAP-Implementierungen empfiehlt beteo einen strukturierten PoC.

Proaktives Impact Management – die Basis für Business Technology Optimization. Ohne systematisches Impact Management bleibt BTO eine Absichtserklärung.

Was ist proaktives Impact Management?

Proaktives Impact Management bedeutet: Auswirkungen von Änderungen werden analysiert und gesteuert, bevor die Änderung umgesetzt wird – nicht erst nach einem Produktionsproblem.

Die drei Dimensionen des Impact Managements:

• Technischer Impact: Welche Programme, Datenbanktabellen und Schnittstellen sind betroffen?
• Business-Impact: Welche Business-Prozesse, Transaktionen und Benutzerrollen sind betroffen?
• Organisatorischer Impact: Welche Teams müssen informiert, einbezogen oder geschult werden?

Werkzeuge für proaktives Impact Management:

• ABAP-Analysewerkzeuge (z.B. Panaya, Intellicorp) für technischen Impact
• Business Process Change Analyzer (BPCA) für Business-Impact
• SAP Solution Manager für orchestrierte Verwaltung des gesamten Prozesses

Lifecycle Management – kein Schmerz, kein Gewinn! Die Einführung von Application Lifecycle Management erfordert Veränderungen – und Veränderungen sind nie schmerzlos.

Die Einführung von ALM verändert Arbeitsweisen fundamental: Entwickler müssen Transport-Requests vollständiger dokumentieren, Tester müssen Impact-Analysen durchführen bevor sie testen, Projektleiter müssen Change Requests formal genehmigen.

Typische Widerstände:

• „Das haben wir früher auch ohne diese Prozesse geschafft“
• „Zu bürokratisch“
• „Wir haben keine Zeit für das alles“

Der Gewinn nach dem Schmerz:

• Deutlich weniger Produktionskrisen und Notfalleinsätze
• Transparenz über alle Änderungen im System
• Reduzierter Testaufwand durch bessere Selektivität
• Compliance-Sicherheit ohne Mehraufwand

Fazit: Der kurzfristige Schmerz der Veränderung ist der Preis für den langfristigen Gewinn. Organisationen, die diesen Schritt nicht wagen, zahlen einen anderen Preis: laufende Krisen, hohe Kosten und ständige Unsicherheit.

Lifecycle Management – ein Albtraum? Für viele SAP-Organisationen ist Application Lifecycle Management noch immer mit negativen Assoziationen verbunden: komplex, teuer, bürokratisch. Warum – und wie ändert man das?

Warum ALM als Albtraum wahrgenommen wird:

• Schlechte frühere Erfahrungen mit Tools, die mehr Overhead als Nutzen gebracht haben
• Zu viele Prozessschritte ohne erkennbaren Mehrwert
• ALM als isolierte IT-Disziplin ohne Business-Beteiligung
• Fehlende Executive-Unterstützung

Wie man den Albtraum beendet:

• Mit Quick Wins starten: Automatisiertes Transport-Management liefert sofort messbare Ergebnisse
• Business-Nutzen in den Vordergrund stellen, nicht technische Prozesse
• Schrittweise einführen: lieber wenige Prozesse gut als viele schlecht
• Erfolge kommunizieren und feiern

Fazit: Gut implementiertes ALM ist kein Albtraum, sondern eine Erleichterung – wenn man es mit dem richtigen Ansatz angeht.

Lifecycle Management – was es braucht. Was sind die notwendigen Voraussetzungen für ein erfolgreiches Application Lifecycle Management in SAP-Umgebungen?

Technische Voraussetzungen:

• Umfassende CMDB (Configuration Management Database) als Datenbasis
• Integriertes Transportmanagementsystem mit Konsistenzprüfung
• Testmanagementsystem mit direkter Anbindung an Change Requests
• Impact-Analyse-Werkzeuge für technische und Business-Objekte

Prozessuale Voraussetzungen:

• Definierter Change-Request-Prozess mit klaren Genehmigungsworkflows
• Verbindliche Qualitätsgates vor Produktivsetzungen
• Regelmässige Architektur-Reviews

Organisatorische Voraussetzungen:

• Klare Ownership für ALM-Prozesse und -Werkzeuge
• Top-Management-Commitment
• Dedizierte ALM-Kompetenzstelle im Unternehmen

Business Technology Optimization (BTO) – Anwendungsentwicklung als Lifecycle-Prozess. HP’s BTO-Konzept positioniert Anwendungsentwicklung nicht als einmaligen Akt, sondern als kontinuierlichen Verbesserungsprozess.

BTO integriert Anforderungsmanagement, Entwicklung, Testing und Betrieb in einem durchgängigen Prozess. Im SAP-Kontext bedeutet dies:

• Jede SAP-Änderung wird im Kontext des gesamten Anwendungsportfolios betrachtet
• Impact-Analysen erfolgen über Systemgrenzen hinweg (ABAP, Java, Non-SAP)
• Qualitätssicherung ist in jeden Prozessschritt integriert, nicht nur am Ende
• Betriebsdaten fliessen zurück in die Planung neuer Entwicklungen

Fazit: BTO ist die Antwort auf die zunehmende Komplexität moderner SAP-Landschaften. Es liefert den Rahmen für ein wirklich integriertes Application Lifecycle Management.

Der Zyklus über dem Entwicklungszyklus. Application Lifecycle Management ist mehr als Entwicklungsmanagement – es ist der übergeordnete Rahmen, der alle Phasen des Software-Lebenszyklusses steuert.

Typische Entwicklungszyklen konzentrieren sich auf: Anforderung → Design → Entwicklung → Test → Deployment. Was dabei fehlt: der übergeordnete Managementzyklus, der sicherstellt, dass jede dieser Phasen in einem grösseren Kontext stattfindet.

Der übergeordnete ALM-Zyklus umfasst:

• Strategische Planung und Portfolio-Management (welche Initiativen werden umgesetzt?)
• Impact-Analyse (welche Auswirkungen haben Änderungen auf das bestehende System?)
• Qualitätssicherung über den gesamten Lebenszyklus (nicht nur in der Testphase)
• Wissensmanagement und Dokumentation (Lernen aus jedem Zyklus)
• Kontinuierliche Verbesserung des Prozesses selbst

Fazit: Ohne diesen übergeordneten Zyklus bleibt Application Lifecycle Management ein Schlagwort. Mit ihm wird es zum Motor kontinuierlicher Qualitätsverbesserung.