Blog

  • SAP-Testing mit HP-Produkten ein Widerspruch und HP eine Zweckgemeinschaft?

    SAP-Testing mit HP-Produkten ein Widerspruch und HP eine Zweckgemeinschaft?

    Es ist auffallend wie schwer sich SAP in der Positionierung als Wiederverkäufer der HP Softwarekomponenten tut.

    Betrachtet man die Komplexität und Heterogenität von SAP würde es eigentlich auf der Hand liegen, dass die HP Softwaresuite das ideale Instrument für das Managen von SAP ist.

    Fazit SAP und HP sollten unbedingt gemeinsam eine Strategie erarbeiten wie sie eine gemeinsame xApps für das managen komplexer IT’s zur Verfügung stellen können.

  • 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.

  • Sap positionierung solution management

    Sap positionierung solution management

    Statt solution management als protukt für it als business funktionalität um die it zu management

    Business Impact Analyzer

    Was versteht beteo unter SAP Impact-Management. Beteo hat zu diesem Thema schon diverseste blogs geschrieben, hier nur einen Auszug. Auch führt beteo eine Beteo hat sich SAP Impact-Management zum Solution-Ziel gemacht, wir leben für SAP Impact-Management.

    SAP’s Business Process Change Analyzer

    Mit grossem TamTam wurde an der diesjärigen Teched in Berlin von coCEO Leo Apotheker der SAP „Business Process Change Analyzer“ (nachfolgend BPCA genannt) angekündigt. Doch was steckt dahinter, resp. kann der Business Process Change Analyzer die Erwartungen die er mit seinem Namen weckt überhaupt erfüllen? http://www.computerwelt.at/detailArticle.asp?a=117835&n=2

    Das SAP den BPCA überhaupt ankündigt, zeigt welchen Stellenwert SAP der Impact-Analyse für die Zukunft zuordnet. In diversen Blogs haben wir bereits über Impact-Analyse geschrieben, SAP bezieht sich mit „seinem“ BPCA leider nur auf die technische Analyse von Transaktionen / Programmen, eine Analyse die bis in die logischen Bereiche rein geht, lässt SAP nach wie vor offen.

    Leider konnte ich bis anhin die Technologie die hinter dem BPCA von SAP noch nicht genau eruierten, jedoch lassen entsprechende Screen-Shots schon jetzt technologische Schlüsse erahnen. So wie es aussieht basiert BPCA auf der Laufzeitanalyse (Runtime Analysies) was einem ja bekanntlich verunmöglich direkt in der entsprechenden Produktion direkt Impact-Analysen auszuführen. Dies bedeutet für BPCA konkret, dass nur entsprechende vordefinierte Szenarien analysiert werden können – „hand aufs Herz“ wer arbeitet heutet noch so

    Es ist wirklich fraglich, wieso SAP sich nicht entsprechende „Standard“ Analyse-Tools wie RBE von IBIS, Panaya und/oder Intellicorp zu Hilfe genommen hat, den diese basieren auf „smarteren“ Impact-Management-Methoden und sind auch schon vielfach in der Praxis erprobt.

    Fazit Einmal mehr holt sich SAP mit dem BPCA die entsprechenden „Checklisten“-Punkte, jedoch werden beim genaueren Hinschauen die Erwartungen an ein BPCA absolut nicht erfüllt.

    Der Widerspruch „SAP Lifecycle Management“ SAP LCM

    Mit viel Interesse habe ich an der diesjährigen Teched in Berlin (sapteched.com/emea) den unterschiedlichen Vorträgen zum Thema SAP Lifecycle Management (kurz LCM) zugehört. Meiner Erwartung, dass SAP sich auch dem SAP „Kunden“ Lifecycle Management annimmt wurde leider nur teils entsprochen.

    Die Teched konnte mich leider nicht davon überzeugen, dass der SAP Solution Manager für das Solution Management der Kundenimplementierung geschaffen wurde. Vielmehr ist der Solution Manager dafür da, dass SAP einen Gateway in die Kundeninfrastruktur hat um damit optimiert das Lifecycle-Management der SAP Standardsoftware sicherzustellen. Geschickt verpackt SAP das SAP „Standard-Software Lifecycle-Management“ als SAP „Kunden Lifecycle-Management“. Grundlegende Anforderungen an „Software Lifecycle Management“ nämlich die Versionierung (es gibt bis dato noch kein Customizing-Versionierung im Standard) und Abhängigkeitsmanagement zwischen den einzelnen Softwarekomponenten, sind für das SAP „Kunden Lifecycle Management“ inexistent. Für das SAP „Standardsoftware“ Lifecycle Management ist es umfassend im CIM-Modell enthalten, was genau den voran aufgeführten Anforderung an Standardsoftware – LCM entspricht. Funktionalitäten wie SAP ChaRM / SAP CTS+ werden geschickt in Marketing hüllen gepackt, so dass die Kunden die eigentlichen Herausforderungen an konkurrierendes Change-Request-Management (SAP ChaRM) und heterogenes Deployment (SAP CTS+) aufgrund der Marketing-Messages gar nicht mehr beachten. Dies sind nur zwei Beispiele von vielen Punktfunktionalitäten in welchen SAP mittels vorgibt sich umfassend um die Herausfordungen von konkurrierendem Betrieb- und Projekt-Geschäft zu kümmern.

    Hand aufs Herz, wo gibt es noch das SAP „grüne Wiese“-Projekt, in welchem man noch der SAP Pioneer innerhalb der Kundenorganisation ist. Aber genau da werden schon die Weichen für das SAP „Kunden LCM“ gelegt, denn die erste Veränderung der produktiv gestellten SAP Standard-Software kommt bestimmt und somit beginnt das SAP „Kunden LCM“ zu leben!

    Fazit Es ist enttäuschend, dass SAP das Thema SAP Lifecycle Management immer noch nicht auf 75’000 unterschiedliche Kundenimplementierungen focusiert, sondern auf die Softwarelogistik ihrer eigenen Standardardsoftware! Dabei liegt es auf der Hand, dass jede dieser Kundenumsetzung in sich einzigartig ist und nach Standardverfahren für das Managen eben dieses Kundenindividuellen SAP Lifecycle-Managements Backup In diversen Kundenimplementierungen haben wir bereits bewiesen, dass SAP „Kundenimplementierungen“ Lifecycle Management eine erreichbare Herausforderung darstellt. Die Herausforderung Software oder eben SAP Lifecycle Management beinhaltet sämtliche Wie SOX oder generell Compliant-Themen mit dem Thema Customizing-Versionierung umgehen, den dies ist im Standard eine nicht vorhandene Funktionalität

    Die Vision hinter SAP Impact-Management sollte eigentlich die unabhängigkeit von entsprechenden KnowHow-Trägern innerhalb der firma sein

    Impact-Analysen beziehen sich primär auf die Implementierung (Customizing welches die unterschiedlichen Verzweigungen innerhalb der Programme beinhaltet und deshalb für jeden der mehr als 75’000 Kunden von SAP, deren Einzigartigkeit ausmachen).

    SAP CTS+ soll nun alles richten (CTS+ = Enhanced Change and Transport System). Gerne verweise ich hier auf meinen blog http://blog.beteo.ch/2008/06/04/sap-change-transport-management-effizient-und-sicher/ in welchem ich ausführlich auf horizontale und vertikale konsistenzsichernde Massnahmen hinweise. Zum Glück nimmt sich SAP dieser Herausforderung nicht an und überlässt dieses Lösungsfeld den Beratungshäusern.

    Als Beispiel möchte ich hier nur kurz die Herausforderung der Überholerthematik erwähnen, die leider mit den Standard CTS (ohne +) oder auch ABAP Transport-Management immer noch nicht gelöst ist (horizontale konsistenzsichernde Massnahme). Also wie sieht es dann mit vertikalen konsistenzsicherenden Massnahmen aus, hier ist nur schon innerhalb der ABAP – Systeme die Herausforderung geschweige den wenn es auch noch Nicht-ABAP-Heterogenität zu beachten gilt.

    Fazit Das konventionelle Transportmanagemement (neuzeitlich CTS genannt) konnte in komplexen organisatorischen und technischen Systemumgebungen schon nicht mithalten und musste über entsprechenden externen Toolsupport (Referenz zu TRP-Tools). Kommen nun noch SAP NW Java Entwicklungs- und Konfigurations-Objekte hinzu wird die gesamte Herausforderung mehrdimensional. Dank an SAP, dass es nach wie vor soviel Spielraum für Beratung offen lässt.

    Positionierung von SAP und ARIS