Blog

  • Testmanagement – Viel Qualität für wenig Geld

    Aus meiner Sicht gibt es drei Schlüsselkomponenten, um das Ziel «hohe Qualität zu geringen Kosten» im Testmanagement zu erreichen: adäquate Methoden, adäquate Personalbesetzung und adäquate Tools – jeweils zum richtigen Zeitpunkt. Wird einer dieser Faktoren vernachlässigt, droht das Projekt zu scheitern.

    Glücklicherweise bringt das Tool die adäquate Methode mit, ohne einen zu sehr einzuschränken, und ermöglicht die Planung von Ressourcen und Testphasen. Ich habe einige Erfahrungen mit Projekten gemacht, bei denen alle Teammitglieder hochmotiviert starteten, gut durchdachte Methoden anwendeten, aber bald nicht mit den Tools umgehen konnten – der schlimmste Fall im Allgemeinen ist ein tabellenkalkulations-gesteuertes Projekt, in dem Dinge passieren wie: «Haben Sie keinen Test durchgeführt? Ich habe einen Eintrag im Excel-Sheet gemacht, dass Sie … oh, Entschuldigung, es ist noch auf meinem Computer, vergessen hochzuladen…»

    Was soll ein Tool leisten können, das einen konsistenten Qualitätsmanagementprozess abbilden und für alle Beteiligten transparent machen soll? Aus meiner Sicht sollte dieses Tool:

    • eine einfache und intuitive Oberfläche bieten,
    • globale Nutzung ermöglichen, d.h. webbasiert sein, ohne grossen Installationsaufwand,
    • das Erfassen, Kategorisieren und Bewerten von Anforderungen erlauben,
    • Risikoabschätzung ermöglichen,
    • Rechte- und Rollenverwaltung erlauben,
    • die Zuweisung von Aufgaben ermöglichen,
    • Testfälle erfassen, verwalten und ausführen können,
    • einfaches Release-Management ermöglichen,
    • das Erfassen und Verfolgen von Fehlern in einem Workflow erlauben,
    • die Auswertung der verschiedenen Phasen sowie des Gesamtprojekts ermöglichen,
    • alle Entitäten verknüpfen und das Zuweisen erkannter Fehler zu einem Testfall oder einer Anforderung erlauben,
    • Testautomatisierung ermöglichen,
    • offene Schnittstellen zu anderen Tools haben.

    Meiner Meinung nach gibt es ein Tool, das diese Anforderungen erfüllt: Quality Center by HP, ursprünglich von Mercury Interactive eingeführt.

    Und das Beste: Nicht nur kann ich beobachten, dass es meine Qualitäts- und Testmanagementprojekte zum Erfolg macht, ich arbeite auch sehr gerne damit.

    Über den Autor:
    Gerd Fladrich ist Testmanagement-Experte bei Fladrich Consulting, Pliening bei München, einem beteo-Partner im Bereich Qualitätsmanagement und Testing.

    🇬🇧 Read this post in English

  • ITIL, PRINCE2, PMI – Nur Papiertiger?

    Historisch gewachsene IT-Struktur
    In ihren IT-Organisationen unterscheiden Unternehmen historisch zwischen Projektgeschäft, IT-Betrieb und IT-Entwicklung. Neben diesen getrennten Bereichen gibt es verschiedene Prozesse und Systeme für Projektanfragen, Störungsmeldungen und Problemmanagement.

    ITIL, PRINCE2 und PMI werden getrennt in ihren Silos eingesetzt?
    Für diese Prozesse gibt es Standards wie die IT Infrastructure Library (ITIL), PRINCE2 und das PMBOK des Project Management Institute (PMI). Das Project Management Office (PMO) und das Change Advisory Board (CAB) führen ihre Anfragen und Analysen jedoch getrennt durch. Diese Denkweise in getrennten Kategorien schafft Redundanzen und ignoriert das Synergiepotenzial.

    Eine isolierende Sichtweise hat negative Auswirkungen
    Es gibt keine Grundlage, auf der Entscheidungsträger eine Prioritätenreihenfolge für die Aktivitäten zwischen Projektgeschäft und IT-Betrieb festlegen könnten. Typische Problembeispiele:

    • Wiederholte Bearbeitung der gleichen Objekte
    • Intransparente Abhängigkeiten schaffen höhere Risiken
    • Fehlerbehebung und Projektimplementierung verzögern sich
    • Ungenaue Planung aufgrund fehlender Informationen
    • Kritische Ressourcen können nicht optimal genutzt werden
    • Service Level Agreements (SLA) werden nur selektiv definiert
    • Änderungen können nicht umfassend getestet werden

    Die Lösung: Problemportfolio als Teil des Service Portfolios
    Folgendes Vorgehen hilft, die Effizienz von IT-Organisationen deutlich zu verbessern:

    1. Aufbau eines Problemportfolios

    • Situationsanalyse von Incident-, Problem- und Change-Management
    • Definition der Anforderungen an ein ganzheitliches Problemmanagement
    • Definition eines integrativen Problemmanagementprozesses
    • Harmonisierung mit Incident- und Change-Management

    2. Erweiterung und Integration des Service-Portfolio-Managements

    • Definition standardisierter Bewertungskriterien und Gewichtungsskalen
    • Synchronisierung von Events mit dem Project Portfolio Management
    • Aufbau umfassender Analyse-, Release-, Planungs- und Implementierungsprozesse
    • Erweiterung des Projektportfolios zu einem umfassenden Service Portfolio

    Zusammenfassung
    ITIL, PRINCE2 und PMI sind äusserst nützliche Frameworks, die das Fundament einer IT-Organisation legen können. Um jedoch die «Silo-Mentalität» zu überwinden und sie angemessen zu nutzen, müssen sie miteinander zu einem ganzheitlichen Service Portfolio & Projektmanagement integriert werden. Andernfalls bleiben sie nichts weiter als Papiertiger.

    🇬🇧 Read this post in English

  • Hungrig nach Veränderung

    Wie hungrig sind Sie nach Veränderung? – Klar, «Veränderung» ist an sich kein ernsthafter Managementansatz. Ohne Inhalt und Umsetzung bleibt Veränderung leeres Gerede. Erfolgreiche Führungskräfte verbinden daher inhaltsvolle Vorstellung mit Umsetzung. In der jüngsten Studie «Enterprise of the Future» von IBM beschreiben weltweit ausgewählte Führungskräfte ihre Vorstellungen vom Unternehmen der Zukunft:

    • Märkte werden aktiv gestaltet. Innovationen gehen über die Wünsche und Bedürfnisse der Kunden hinaus.
    • Das Unternehmen ist global integriert, eingebettet in die globalen Wirtschaftsaustauschbeziehungen.
    • Der innere Motor ist die Transformation von Geschäftsmodellen – mit neuen Partnern, Kunden, mit veränderten Leistungsprozessen werden neue Wertschöpfungspotenziale realisiert.
    • Unternehmen übernehmen mehr Verantwortung für ihre Beiträge zur globalen Gesellschaft – «Corporate Social Responsibility» als ökologische, finanzielle und soziale Nachhaltigkeit.

    Dies rückt Menschen in den Fokus, ihren Willen und ihre Fähigkeiten, sich selbst und andere zu verändern, die an der Veränderung teilnehmen:

    • «Hungrig nach Veränderung» steht daher an erster Stelle in der Studie. Wer in der Vergangenheit Veränderungen erfolgreich geführt und gemanagt hat, wagt dies auch in Zukunft. «Der Schlüssel für erfolgreiche Transformation ist die Veränderung des Denkens.» Die Lust auf Veränderung ist Teil der Veränderung selbst, Mut zur Nutzung von Verbesserungspotenzialen und Neuem. Es geht um eine Kultur der Veränderung: Morgen erfolgreiche Unternehmen haben Veränderung bereits verinnerlicht und sind selbst ein Akteur der Veränderung in der Welt.

    Das macht zumindest Appetit, oder?

    Über den Autor:
    Dr. Michael Loebbert ist Coach und Managementberater sowie Autor der monatlichen Publikation «Change Management Short Cut».

  • Lohnt sich Tool-gestütztes Testmanagement?

    Jedes Softwareprojekt zielt darauf ab, qualitativ hochwertige Software im Rahmen eines Kosten- und Zeitplans bereitzustellen. Tool-basiertes IT-Testmanagement begleitet in der Regel den gesamten Softwareentwicklungsprozess und trägt teilweise zur Erreichung dieses Ziels bei. Dies umfasst Aufgaben wie Requirements Management, Testplanung, Testdesign, Testdurchführung, Testauswertung sowie ein übergeordnetes Defect Management.

    Praktische Erfahrung
    Erratisches und unsystematisches Testen ist jedoch in vielen Unternehmen gängige Praxis. Eine Vielzahl manueller Schritte, Redundanzen und inkonsistente Dokumentationen sind an der Tagesordnung und verursachen Mehrkosten. Andererseits kann durch den Einsatz eines Tool-basierten Testmanagements ein hoher Nutzen erzielt werden. Die Einführung der notwendigen Testmanagement-Tools, zusammen mit geeigneten Methoden und Prozessen, verbessert sowohl den Testprozess als auch die Softwarequalität.

    Testing wird:

    • standardisierter (Tool statt Freitext in Word/Excel), systematischer, zuverlässiger,
    • weniger zeitaufwändig, einfacher durchzuführen,
    • nachweisbar (Inhalt und Abdeckung), effektiver und umfassender,
    • nachvollziehbar,
    • wiederverwendbar, schulbar,
    • automatisierbar und planbar.

    Potenzielle Rentabilität des Tool-basierten Testmanagements
    Potenzielle Verbesserungen lassen sich nicht einfach quantifizieren. Erfahrungen aus erfolgreichen Implementierungen des Testmanagement-Tools HP Quality Center haben jedoch gezeigt, dass echte Verbesserungen möglich sind:

    • Verbesserte Produktqualität: Weniger Verzögerungen durch schlechte Produktqualität, Vermeidung häufiger Notfall-Implementierungen in der Produktion, höhere Kundenzufriedenheit, Kosteneinsparungen durch weniger Nacharbeit und reduzierte Supportkosten.
    • Verbesserter Testprozess: Geringere Kosten pro Testzyklus durch Standardisierung und Wiederverwendung, weniger Zeit- und Kostenaufwand für die Vorbereitung dank Wiederverwendung von Anforderungen und Testfällen, schnelle Testdurchführung durch automatisierte Regressionstests.
    • Verbesserter Einsatz von Testressourcen: Einsparungen durch zentralen Einsatz von HP Quality Center, automatisiertes Testabdeckungsmanagement vermeidet die Notwendigkeit von Nachtests.
    • Verbesserte Projektlieferung: Besser planbarerer und optimierter Liefertermin, Testautomatisierung und reduzierter Ressourceneinsatz, optimierte Nutzung von Projektressourcen.

    Zusammenfassung
    Testmanagement ist notwendig und verbessert die Qualität von Softwareprojekten deutlich. Die Vorteile des Tool-basierten Testmanagements liegen auf der Hand. Erfolgreiche Implementierungen des Testmanagement-Tools HP Quality Center haben gezeigt, dass praktische Verbesserungen definitiv realisiert werden können und der de facto Gewinn im Voraus berechnet werden kann. Tool-gestütztes Testmanagement rechnet sich nicht nur, sondern der Nutzen kann auch quantifiziert werden.

    🇬🇧 Read this post in English

  • Poker – Die Fruchtfliege des Change Managements

    Wie viele andere unter meinen Freunden bin ich dem Poker verfallen. Wenn ich Poker sage, meine ich das allgegenwärtige Texas Hold’em Poker und nicht eine der Draw-Poker-Varianten, die meiner Meinung nach zu den reinen Glücksspielen gehören.

    In meiner 2-jährigen Poker-Karriere habe ich folgende Phasen durchlaufen:

    Phase Beschreibung Bemerkungen
    Anfänger So beschäftigt mit dem Regelwerk, dass nichts vorhersehbar erscheint Die Spieler sind die anderen, nicht ich selbst
    Kenner der Regeln Nachdem ich ein paar Anleitungen gelesen habe, verstehe ich das Grundprinzip Ich bin ein aktiver Spieler. Erstaunlich oft ende ich als Gewinner, sonst ist meine Niederlage oft dramatisch
    Erfahrener Spieler Früher verborgene Mechanismen und «Soft Factors» entdeckt, versuche sie anzuwenden Gelegentlicher Erfolg beim «Lesen» meines Gegners, dramatische Verluste werden vermieden
    Unbesiegbar Gut ausgestattet mit allen «Werkzeugen» Einige ausserordentliche Erfolge, aber noch vermeidbare Fehler
    Weise Nutze ich wirklich alle verfügbaren Werkzeuge? Um langfristig erfolgreich zu sein, müssen ständig neue Erkenntnisse eingebracht werden

    Jede neue Erkenntnis liess mich besser für den Umgang mit meinen Gegnern vorbereitet fühlen. Aber ich verstand auch, dass jede neue Erkenntnis meine grundlegende Spielidee auf den Kopf stellen könnte.

    Change Management
    Der kurze Lebenszyklus eines Pokerspiels ist ein perfektes Experimentierfeld, um die Mechanismen des Change Managements zu verstehen. Während es einem IT-Change-Manager einige Wochen oder Monate dauert, ein Projekt mehr oder weniger erfolgreich abzuschliessen und daraus zu lernen, dauert der Zyklus in einem Pokerspiel nicht länger als ein paar Minuten.
    Wie die Fruchtfliege mit ihrem kurzen Generationszyklus für die Genetiker kann Poker mit seinen kurzen Spielzyklen das ideale Forschungsobjekt für Change Manager sein.

    Erkenntnisse

    • Geduld; Erfolg kann nicht erzwungen werden. Die Entwicklung von Change-Management-Kompetenz ist ein Prozess in mehreren Phasen.
    • Man kann scheitern, auch wenn alle Bedingungen optimal sind (AA).
    • Als Anfänger scheint das Spielen einfach zu sein. Der eigene Spielstil ist ungewöhnlich (für andere), mutig, unberechenbar und aggressiv.
    • Den Sieg im Poker zu planen, lässt sich mit einem Baum vergleichen. Der Ausgangspunkt sind die Wurzeln, von dort folgt man den Ästen. Die meisten Spieler schneiden zuerst die Äste ab, anstatt zu den Wurzeln zurückzugehen.
    • Was für einen Spieler entscheidend ist, um ein erfolgreiches Spiel zu spielen, ist weder gutes Mathematikwissen, die Fähigkeit, den Gegner zu analysieren, noch eine fundierte Spielstrategie. Es ist Selbstkontrolle.

    Es gibt jedoch einen wesentlichen Unterschied zwischen Poker und Change Management. Im Pokerspiel kann man alles richtig machen und trotzdem verlieren. Im Change Management müssen Karten und Gegner erst ausgehandelt werden.

  • Wie man ein Geheimnis nicht enthüllt – HPs ERP4IT

    Während ERP ein Synonym für softwaregestützte Unternehmensplanung und -steuerung ist, steht ERP4IT für softwaregestützte IT-Planung und -steuerung (ITPC).

    Wer nach Lösungen sucht, wird ohne grossen Zweifel die ERP4IT-Angebote des führenden ERP-Systemherstellers SAP prüfen. SAP scheint der einzige ERP-Software-Anbieter zu sein, der über den SAP Solution Manager die eigene Kunden-IT-Organisation und IT-Produkte verwaltet. Theoretisch, angesichts der speziellen Anforderungen von IT-Planungs- und Steuerungs-Frameworks und -Standards, schneidet SAP durchaus gut ab. Aber wenn man den Flickenteppich des SAP Solution Managers aus der realen ERP4IT-Anforderungsperspektive beurteilt – die ein umfassendes Application Lifecycle Management einschliesst –, wird der SAP Solution Manager bestenfalls zur Unterstützung der Verwaltung des SAP-Customizing geeignet sein.

    Während sich der Markt im Allgemeinen darauf konzentriert, IT-Prozesse hauptsächlich durch Frameworks und Standards zu definieren, haben bereits mehr als zehn Jahre alte Managementplattformen für SAP Change und Configuration Management mit ABAP und Workflows den Grundstein gelegt. Mercury-Produkte haben im Kontext der Digitalisierung und Automatisierung von IT-Prozessen einschliesslich Testing das logische Ergänzungsprodukt geliefert. HP hat diese Produkte übernommen und in sein Portfolio integriert.

    HP ist heute in der Lage, eine umfassende Lösung «HP Best Technology for Optimization» (HP BTO) anzubieten. HP BTO ist eine sehr nützliche Zusammenstellung von Software-Komponenten. In geeigneten Kombinationen kann es sowohl die Anforderungen für eine echte Solution-Management-Lösung – d.h. ein umfassendes Application Lifecycle Management System – als auch die eines SAP-ERP4IT-Systems vollständig erfüllen, insbesondere in Kombination mit einigen Grundfunktionalitäten des SAP Solution Managers.

    HP scheint seine Software jedoch hauptsächlich in Form von Einzelprodukten zu vermarkten und versäumt es, die integrierte Lösung als HP BTO ERP4IT den Kunden nachhaltiger anzubieten. Schade für die IT-Organisationen, denen dieses enorme Wertpotenzial (noch) vorenthalten wird.

  • Kann eine klassische CMDB mit Business Service Management umgehen?

    Die heutige IT in ihrer Rolle als Dienstleister für das Unternehmen erfordert ein sofortiges Umdenken bei der Verwaltung von Ressourcen und Konfigurationsdaten.

    Wenn der Datenspeicher nicht flexibel genug ist, können die aus dem Service-Lifecycle-Management (SLM) resultierenden Anforderungen möglicherweise nicht in ausreichendem Mass erfüllt werden, und die Bereitstellung der CMDB-Services könnte nicht wie erwartet oder so effizient wie gewünscht sein.

    Heutzutage verwendete Konfigurationsmanagement-Datenbanken (CMDB) dienen als rudimentäre Datenpools und drohen, hauptsächlich aus Marketinggründen zu existieren.

    Eine fundierte Datenerfassung – weit über den heutigen Standard hinaus – ist notwendig!
    Ein nützliches, effizientes und aktives Service-Lifecycle-Management (SLM) erfordert eine umfassende unternehmensweite Serviceorientierung und ein unternehmensübergreifendes Service-Management.

    Um dieses Ziel zu erreichen, ist eine homogene und fundierte Service-Datenbank mit Schwerpunkt auf «Service» grundlegend. Beim Aufbau dieser Datenbank ist der erste Schritt die Definition eines Service-Katalogs, der es ermöglicht, alle Services einschliesslich ihrer Beziehungen zu identifizieren. Dabei ist es besonders wichtig, dass alle IT-Services Business-Services zugeordnet werden. Dies ermöglicht dem Business Service Management (BSM) die Durchführung von Impact-Analysen in einem bisher undenkbaren Ausmass.

    Eine Service-CMDB (S-CMDB) bietet mehr
    Die für den Service-Katalog gesammelten Daten müssen zusammen mit den üblichen Daten aus anderen IT-Bereichen wie Project Portfolio Management (PPM), IT-Entwicklung und IT-Service-Management (ITSM) gespeichert werden.

    Enabler für umfassendes Service-Portfolio-Management
    Die für PPM, IT-Entwicklung und ITSM erstellte gemeinsame Datenerfassung ermöglicht eine effiziente ganzheitliche Sicht auf alle IT- und sonstigen Projekte und dient wiederum als Grundlage für das gezielte Service-Portfolio-Management.

    Herkömmliche CMDBs müssen erweitert werden, wenn sie den Anforderungen von S-CMDBs gerecht werden und den erwarteten hohen Nutzen für die IT erzielen wollen.

    Über den Autor:
    Andreas Schegg, ITIL- und Configuration-Management-Experte, ist Senior Consultant bei Ontrex AG, Winterthur, Schweiz.

    🇬🇧 Read this post in English

  • E2E SAP Testing – Halbwegs unter Kontrolle?

    In vielen Blog-Beiträgen haben wir die Defizite im SAP Testing diskutiert. Änderungen an einem bestehenden System sind an der Tagesordnung. Immer wieder werden Fehler korrigiert, Customizing und Programme müssen angepasst, neue Funktionen ausgerollt werden. Auch technische Änderungen wie Hot Fixes und Service Packs müssen installiert sowie Upgrades durchgeführt werden. Angesichts der grossen Anzahl von Änderungen sind Testing-Probleme das Letzte, was man sich wünscht. Die meisten SAP-Kunden haben sich damit jedoch arrangiert und beheben die Probleme im Zusammenhang mit unzureichend oder unvollständig getesteten Änderungen reaktiv – inmitten des Applauses des Business.

    Spezialisierte Beratungsunternehmen wie FocusFrame sowie Hersteller von Testing-Software wie HP, Panaya, IntelliCorp, IBIS und vor allem SAP haben sich dieses Themas angenommen.

    Was bedeutet das im Detail?

    • Der erste Schritt besteht darin, zu analysieren, welche SAP-Transaktionen und Programme von der Änderung betroffen sind. Dieser Schritt wird meist als Change Impact Testing bezeichnet und wird durch spezialisierte Produkte wie HP Change Impact Testing (CIT) for SAP, SAP Test Automation and Optimization (SAP TAO) sowie IntelliCorp LiveCompare unterstützt.
    • Sobald die betroffenen Transaktionen bekannt sind, muss festgestellt werden, welche Testing-Szenarien notwendig sind. Die Testing-Szenarien werden identifiziert und dem Test-Management-Tool zur Verfügung gestellt.
    • Trotz der Systemunterstützung und Testszenarienreduktion sollten die Testing-Szenarien aufgrund ihrer Vielzahl einen weiteren Filter durchlaufen. Dieser Schritt wird weithin als Risk Based Testing bezeichnet.
    • Dann führt das Test-Management-Tool die gefilterten Tests automatisch aus. Die Ergebnisse werden ausgewertet und bei Bedarf wird der Defect-Management-Prozess gestartet und überwacht.

    Von Transport-Paket-Testing bis zum echten E2E-Testing
    All das klingt recht einfach und logisch. In der Praxis ist die Einrichtung und der Betrieb einer solchen Umgebung jedoch durchaus eine Herausforderung. SAP ist sich dessen bewusst und arbeitet an einer Lösung mit dem neuen Business Process Change Analyzer (SAP BPCA), um echtes E2E-Qualitätsmanagement zu ermöglichen.

    Die korrekte Implementierung von SAP E2E Testing wird das bisher schwache SAP-E2E-Qualitätsmanagement zum Vorzeigemodell für andere Unternehmenssoftware-Lösungen machen. Der Nutzen eines konsequenten, umfassenden Testings für SAP-Landschaften kann kaum überschätzt werden.

    🇬🇧 Read this post in English

  • SAP Solution Manager – Mehr als nur SAP-Marketing?

    Wie der Name vermuten lässt, soll der SAP Solution Manager die Verwaltung von SAP-Kundenimplementierungen unterstützen. Erfüllt er diese Aufgabe? Oder ist er lediglich eines der Marketing-Instrumente von SAP?

    Fehlende Funktionen für komplexe Systemlandschaften
    Bei der Diskussion der Vor- und Nachteile des SAP Solution Manager muss zunächst anerkannt werden, dass SAP einer der wenigen Anbieter ist, der überhaupt eine Solution-Management-Plattform bereitstellt.

    Betrachtet man jedoch die verschiedenen Komponenten des SAP Solution Managers genauer, ergibt sich ein eher heterogenes Bild. Es scheint, als wären viele Funktionen nur pro forma integriert worden, um typische Marktanforderungen aus RFPs (Request for Proposal) zu erfüllen.

    Einige Komponenten sind zwar vorhanden, aber nur teilweise oder unzureichend integriert. Für eine effiziente Verwaltung von Kundenimplementierungen werden zusätzliche Office-Lösungen benötigt. Dies scheint jedoch nur für kleinere SAP-Implementierungen sinnvoll zu sein. Komplexere Organisationsstrukturen oder heterogene SAP-Landschaften implizieren zusätzliche Abhängigkeiten, die verhindern, dass diese Lösungen ihren Zweck erfüllen.

    Erwartungen an eine effizient funktionierende SAP-Solution-Management-Plattform
    Vieles, was wir von einem SAP-Solution-Management erwarten, ist vergleichbar mit dem, was eine umfassende Application-Lifecycle-Plattform bieten würde. Besonders wichtig ist, dass der vollständige Service-Lebenszyklus der SAP-Implementierung verwaltet werden kann – einschliesslich aller dokumentarischen, organisatorischen und technischen Interdependenzen, über alle Phasen von der ersten Prozessimplementierung bis zu Erweiterungen, Fehlerbehebung und Prozessdeaktivierung.

    Auch die vollständige Kosten- und Aktivitätenabrechnung (integriertes Finanzmanagement) sollte über den gesamten Lebenszyklus der Lösung transparent gemacht werden. Nur so lässt sich eine Kosten-Nutzen-Rechnung für eine Kundenimplementierung aufstellen.

    Die Struktur der Lösung sollte Unterteilungen entsprechend den von ihr unterstützten Business Services (BS) vorsehen, damit diese Services mit dem übergeordneten Unternehmensziel ausgerichtet werden können. Dies führt zu einem effektiven Service-Portfolio-Management (SPM) und stellt den angestrebten Wert der Implementierung sicher.

    Zusammenfassung
    Entscheidend für den Erfolg ist, dass der Kunde ein klares Bild aller relevanten IT-Prozesse im SAP-Solution-Management hat. Das bedeutet, dass der Fokus nicht auf dem Solution-Management-Tool liegen darf, sondern auf den Risiken, die durch den Solution Manager adressiert und minimiert werden. Daraus lassen sich direkt die Anforderungen ableiten, die an das Solution Management zu stellen sind.

    🇬🇧 Read this post in English

  • OC Oerlikon – Wie SAP Roll-in-Projekte scheitern können

    Am Freitag, dem 26. Oktober 2007, berichtete inside-it.ch, dass OC Oerlikon sein Super-SAP-Projekt einstellen wird. Der neue Ansatz soll eine «intelligentere, flexiblere und günstigere Lösung bieten, die alle ERP-Systeme der Geschäftsbereiche über ein zentrales SAP-Konsolidierungstool integriert».

    Das klingt nach einer Vereinfachung – aber warum scheitern SAP-Roll-in-Projekte eines nach dem anderen? Als Lösungsarchitekt und interessierter Beobachter solcher Projekte wage ich einige einfache Erklärungen:
    Der ursprünglich pragmatische Plan, eine Reihe verschiedener ERP-Umgebungen technisch zu vermeiden, ist in den meisten Fällen nicht das eigentliche Primärziel. Oft zielt das Roll-in-Projekt darauf ab, einen Betrieb mit identischen Prozessen im gesamten Unternehmen zu implementieren und von Best Practices zu profitieren. Äusserst anspruchsvolle Ziele!

    Leider wird die Zielorganisation des Projekts und die Prozesse für das Gesamtunternehmen oft unzureichend auf SAP abgestimmt. Darüber hinaus erfordert die organisatorische und kulturelle Komplexität eines solchen ursprünglich technischen Projekts, dass alle qualitätssichernden Massnahmen von Anfang an klar definiert und konsequent eingehalten werden. Sehr oft geschieht dies in solchen Initiativen deutlich später – wenn überhaupt.

    Natürlich sind dies nicht die einzigen Aspekte, die für den Erfolg eines SAP R/3 Roll-in-Projekts oder eines anderen Super-Projekts zu beachten sind. Aber zunächst ist jedem Projektleiter zu empfehlen, auf die oben beschriebenen Stolpersteine in SAP-Roll-in-Projekten aufmerksam zu sein.