Kategorie: Business & Kultur

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.

🇬🇧 Read this post in English

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

🇬🇧 Read this post in English

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.

🇬🇧 Read this post in English

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.

🇬🇧 Read this post in English

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.

🇬🇧 Read this post in English

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

🇬🇧 Read this post in English

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.

🇬🇧 Read this post in English

Management als Kulturarbeit. Die Organisationskultur ist der unsichtbare Rahmen, der Erfolg oder Misserfolg von IT-Projekten massgeblich beeinflusst.

SAP-Projekte scheitern selten an technischen Problemen – häufiger an kulturellen: mangelnde Bereitschaft zur Standardisierung, fehlendes Vertrauen zwischen Business und IT, Silodenken in Abteilungen.

Management als Kulturarbeit bedeutet:

• Aktive Gestaltung der Zusammenarbeitskultur zwischen Business und IT
• Vorbildfunktion in der Nutzung neuer Tools und Prozesse
• Konsequentes Einfordern von Standards und Compliance
• Schaffung psychologischer Sicherheit für die Benennung von Problemen

Fazit: Wer SAP-ALM-Projekte erfolgreich führen will, muss zuallererst als Kulturführer agieren – nicht nur als technischer Projektleiter.

🇬🇧 Read this post in English

Fetische des Wandels. Change Management ist in vielen Organisationen zu einem Selbstzweck geworden – losgelöst von konkreten Ergebnissen.

Typische „Change-Fetische“ in IT-Projekten:

• Der Methoden-Fetisch: Die Methode (ITIL, PRINCE2, SAFe) wird zur Religion, statt pragmatisch eingesetzt zu werden
• Der Tool-Fetisch: Neue Software soll Change von selbst ermöglichen – ohne Prozess- und Kulturarbeit
• Der Workshop-Fetisch: Endlose Workshops ersetzen Entscheidungen
• Der Konsens-Fetisch: Nichts wird entschieden, bis alle zustimmen – was bedeutet, dass nichts entschieden wird

Fazit: Effektiver Wandel erfordert klare Ziele, mutige Entscheidungen und konsequente Umsetzung – nicht mehr Methoden, Tools oder Workshops.

🇬🇧 Read this post in English

HP PPM Best Practices – Von der Idee zur Spezifikation. Wie aus einer Geschäftsidee ein vollständig spezifizierter, genehmigter Projektauftrag wird – mit HP PPM als Rückgrat des Prozesses.

Der Weg von der Idee zur Spezifikation:

1. Ideenerfassung (Demand Management): Strukturierte Erfassung aller Initiativen mit Business-Kontext, Priorität und erwartetem Nutzen
2. Erstbewertung: Schnellcheck auf strategische Relevanz und grundsätzliche Machbarkeit
3. Business Case Erstellung: Detaillierte Kosten-Nutzen-Analyse mit Impact-Abschätzung
4. Genehmigungsprozess: Formeller Review durch Portfolio-Board mit definierten Entscheidungskriterien
5. Spezifikationsphase: Detaillierte Anforderungserhebung mit direkter Verknüpfung zum späteren SAP-Change-Request

Fazit: HP PPM ermöglicht es, diesen Prozess vollständig zu digitalisieren und zu automatisieren – von der ersten Idee bis zum genehmigten Projekt in einem durchgängigen System.

🇬🇧 Read this post in English