SAP-IT raus aus dem Maschinenraum

Wenn sich SAP-Partner bei neuen Themen zusammentun, kommen SAP-IT-Abteilungen schneller zu einer neuen Identität und Schlüsselrolle: als Enabler und Innovationspartner für die Fachbereiche im eigenen Unternehmen

Es ist eine durchaus komfortable Lage, in der sich SAP-Beratungshäuser derzeit befinden: Schon jetzt ist die Nachfrage immens und sie wird in den kommenden Jahren weiter rasant ansteigen: S/4HANA-Projekte und alle angrenzenden technischen Neuerungen im SAP-Umfeld  fordern bereits heute alles von der internen SAP-IT der Unternehmen. Um die Relevanz und den eigenen Stellenwert im Unternehmen auszubauen, benötigt die SAP-IT Unterstützung.

Consultinghäuser sollten hier zusammenarbeiten und ihre Kräfte bündeln, anstatt sich gegenseitig Konkurrenz zu machen. Der Markt an SAP-Kunden ist groß genug und wird weiter wachsen. Beispiel Application Lifecycle Management (ALM): Wenn in den nächsten Jahren immer mehr Unternehmen ihren bisherigen SAP Solution Manager durch das neue Tool Cloud ALM ablösen, braucht es Expert:innen, die sich damit auskennen. Solche findet man in Deutschland aber nicht an jeder Straßenecke. Ein weiteres Szenario ist der nächste Paradigmenwechsel für SAP-IT-Abteilungen, getrieben durch die SAP Business Technology Plattform (BTP). Welcher SAP-IT-Leiter hat schon die Zeit, Mittel und Nerven herauszufinden, was man damit alles bewerkstelligen kann? Und zwar sowohl fachlich als auch bezüglich dessen, wie das Thema organisatorisch im Unternehmen verortet werden sollte und welchen Impact das Ganze auf vorhandene Teamstrukturen und Rollen hat. Hier kommen auf Unternehmen auf einmal ganz andere Stakeholder und Zusammenarbeitsmodelle mit den Fachbereichen zu.

SAP-IT: Weg vom reinen Dienstleister-Image

IT-Abteilungen im SAP-Umfeld sind angesichts der neuen Herausforderungen also auf Unterstützung angewiesen. Gleichzeitig bietet sich in diesem Zuge die einmalige Gelegenheit, aus ihrem bisherigen Schattendasein, dem „IT Maschinenraum“, hinauszutreten. Auf der Kommandobrücke des Unternehmen angelangt, gewinnt die SAP-IT eine ganz neue Bedeutung, weg vom Dienstleister, hin zum Innovationspartner und Enabler des digitalen Wandels. In enger Zusammenarbeit mit den Fachbereichen lassen sich durch SAP-Lösungen neue Geschäftsmodelle umsetzen – die vielbeschworene digitale Transformation.

Mauer zwischen IT und Fachbereichen einreißen

Das Problem bislang: IT-Abteilungen (und hier speziell die SAP-IT) sind in den Unternehmen alles andere als sichtbar und stecken zu sehr im operativem „Sumpf“. Weder agieren sie auf Augenhöhe mit den Fachbereichen, noch sind sie in strategische Entscheidungen auf Management-Ebene involviert. Die SAP-IT ist häufig nichts weiter als ein Dienstleister, der sich um den stabilen und sicheren Systembetrieb kümmert. Sie hat oft das Image eines „Verhinderers“ und die Mauer zwischen ihr und den Fachbereichen ist hoch, je größer das Unternehmen, desto höher. Dies macht sich besonders in der Art und Weise der übergreifenden Zusammenarbeit bemerkbar und genau daran kranken auch S/4HANA-Projekte immer wieder.

Deshalb braucht die SAP-IT mehr Freiräume. Durch zunehmende Effizienzsteigerung im Tagesgeschäft hat sie mehr Zeit, über neue Themen nachdenken zu können. Dadurch gelingt schrittweise die eigene Transformation hin zum internen Berater für die Fachbereiche. Unterstützung dabei geben SAP-Partner, und zwar nicht einzeln, sondern mit vereinten Kräften. Synaworks praktiziert dieses Konzept seit seiner Gründung im Jahr 2018. Das Wort Synapsen (= Verknüpfungen) im Firmennamen sagt schon alles: Hier kämpft nicht jeder einzelne Dienstleister um Kundenprojekte und Marktgewinne, sondern es geht um Zusammenarbeit in Netzwerken und gegenseitige Unterstützung mit einem gemeinsamen Ziel.

Keine opportunistischen Partnerschaften

Die Idee von Synaworks: Unterschiedliche Player am Markt wachsen zusammen, um gemeinsam Ziele zu erreichen und sich gegenseitig zu unterstützen. Nicht opportunistische Partnerschaften für abgegrenzte Projekte sind angesagt, sondern eine langfristig vertrauensvolle Zusammenarbeit mit dem gemeinsamen Ziel, das volle Potenzial der SAP-IT zu entfalten.

Dass dieses Konzept auf fruchtbaren Boden stößt, hat der jüngste Synaworks-Partnertag im Herbst 2022 eindeutig gezeigt. SAP-Fachleute für die verschiedensten Themen von Tool-Set bis Mind-Set kamen in Heidelberg zusammen und tauschten sich darüber aus, wie man Projekte und Initiativen am besten gemeinsam angehen kann. So hat Synaworks in der jüngeren Vergangenheit bereits eine illustre Partner-Community aufgebaut. Für die Kunden bedeutet die Kräftebündelung gleichzeitig Planungssicherheit. Denn im Netzwerk ist auch in größeren Projekten oder zu Spitzenzeiten jederzeit Lieferfähigkeit sichergestellt.

Technologie als Mittel zum Zweck

Technologie alleine springt zu kurz. Connecting People and Technology, das ist unsere Überzeugung, aus der heraus wir Synaworks einst gegründet haben. Indem wir unsere Kompetenzen aus den Bereichen ALM Best Practises, Organisations- und Kompetenzentwicklung zu einem ganzheitlichen Beratungsansatz verbinden, befähigen wir die SAP-IT, ihr volles Potential zu entfalten. Gemeint ist: Wenn die Gruppe zum Team wird, steigert sich ihre Performance und damit die Wirksamkeit automatisch. Und durch die Kompetenzentwicklung über die reinen fachlichen Skills hinaus, also von der Person hin zur Persönlichkeit, sind künftige Erfolge und persönliche Entwicklung bereits mit angelegt. Die Technologie ist bei alldem nur Mittel zum Zweck, um Wachstum und vor allem den Wandel der SAP-IT hin zum Enabler der digitalen Transformation auf Augenhöhe mit den Fachbereichen zu ermöglichen.

Das Synaworks-Partnernetzwerk ist also weniger fachgetrieben – wenngleich natürlich auch im Netzwerk Spezialist:innen für jeweils konkrete Themen vorhanden sind, deren Fachgebiete sich überlappen. Synaworks unterscheidet zwischen sogenannten Delivery Partnern, die bei eigenen Projekten mit ins Boot geholt werden, und Sales-Partnerschaften (zum Beispiel mit MHP, CBS und Innflow). Hier integriert der Leadpartner die speziellen Services von Synaworks in sein eigenes Portfolio dem Endkunden gegenüber. Dafür hat Synaworks Small-, Medium- und Large-Pakete definiert, welche die Partner in ihre Angebote integrieren können.

Zahnräder im System einer Community

Sales-Partnern zum Beispiel fehlt oft das spezielle Wissen darüber, wie man ein integriertes Application Lifecycle Management etabliert. Hier kann Synaworks  aufzeigen, welche Veränderungen ein ganzheitliches ALM mit sich bringt und welche Auswirkungen auf vorhandene Organisations- und Teamstrukturen zu berücksichtigen sind. Auf dieser Basis wird dann entschieden, wie man beispielsweise die passenden Tools implementiert und den daraus resultierenden Veränderungsprozess auf Rollen, Teams und Zusammenarbeit in der Organisation initiiert und begleitet.

Jeder involvierte Partner ist Zahnrad im System einer Community, die sich vernetzt und ihre Erfahrungen austauscht, um die SAP-IT zu stärken und in eine neue Schlüsselrolle im Unternehmen zu transformieren. Das ist der Grundgedanke. Wenn er funktioniert, dürften sich auf den Kommandobrücken der Unternehmen schon bald sehr viel mehr SAP-Teams zeigen als bisher.

Wenn Sie mit uns #ZusammenWachsen und auch Teil der Partner Community werden wollen, dann kontaktieren Sie uns unter: info@synaworks.com.

Interview von Helge Sanden mit Nicolas Crisand zu der Frage, wie die Neupositionierung der IT gelingen kann.

Herr Crisand, mit welchen Herausforderungen sehen sich IT-Organisationen aktuell konfrontiert?

Nicolas Crisand: Intern sind es vor allem die steigenden Anforderungen aus dem Business – hier müssen in immer kürzeren Zeitabständen neue Mehrwerte geschaffen werden. Gleichzeitig muss die IT im Tagesgeschäft deutlich effizienter werden. Dieser Spagat zwischen Innovation und Effizienz ist sehr herausfordernd.

Extern besteht die Herausforderung vor allem darin, mit der steigenden Komplexität besser umzugehen und die für die jeweilige Organisation relevanten technologischen Entwicklungen zu identifizieren und zu integrieren. Und über allem steht die Notwendigkeit, dass IT und Business enger und besser zusammenarbeiten.

Wie kann die Zusammenarbeit zwischen IT und Business verbessert werden?

Das erfordert neue Rollen und Gremien auf beiden Seiten und viel Kommunikations- und Methodenkompetenz. Auf diese Aspekte sollte ein größerer Fokus gelegt werden. Zwar redet die IT viel von „Rollen“, wir erleben aber häufig, dass diese nicht klar spezifiziert sind — nach Zweck, Aufgaben und Entscheidungshoheiten.

Viele notwendige Rollen existieren häufig auch gar nicht, wie beispielsweise ein „Digital Entrepreneur“. Dann können auch keine guten Kommunikationswege zwischen IT und Business entstehen.

Und wie kann die IT auf die steigende Komplexität und Unvorhersehbarkeit reagieren?

Dafür ist mehr „sense & response“ und weniger „plan & control“ notwendig. In einer VUCA-Welt stößt die klassische Hierarchie schnell an ihre Grenzen. Das bedeutet wieder einen größeren Fokus auf eine verbesserte Zusammenarbeit und eine eindeutige Rollenausgestaltung.

Mitarbeiter müssen lernen, mehrere Rollen gleichzeitig auszufüllen. Und sie müssen bezüglich der anstehenden Herausforderungen sensibilisiert werden. Das ist eine wichtige Voraussetzung, damit eine höhere Agilität und damit mehr „sense & response“ im Team entstehen kann.

Wann ist eine Neupositionierung der SAP-IT-Organisation sinnvoll oder sogar notwendig?

Wenn die IT-Verantwortlichen nicht in „strategische“ Business-Entscheidungen involviert werden. Wenn neue Geschäftsmodelle ohne die IT entwickelt werden. Wenn die IT merkt, dass sie die an sie gestellten Anforderungen nicht erfüllen kann. Wenn die IT den Spagat zwischen Innovationen für morgen und Effizienz für das Tagesgeschäft nicht gut ausbalancieren kann.
Kurz gesagt: wenn die IT nicht das Gewicht oder das Standing innerhalb der Organisation hat, die ihr im 21. Jahrhundert zukommen sollte.

Was muss in der Regel verändert werden?

Es beginnt mit dem eigenen Selbstverständnis. Also die Klarheit der Verantwortlichen über die eigene Daseinsberechtigung: Was ist der Zweck der IT-Organisation? Und wo wollen wir als IT-Organisation in drei Jahren stehen?

Wenn das klar ist, kann eine Roadmap entwickelt werden was zu tun ist, um die IT-Organisation entsprechend zu positionieren.

Wie sieht so eine Roadmap einer neuen IT-Positionierung aus?

Die Inhalte unterscheiden sich von Organisation zu Organisation. Aber die großen Spielfelder, die bespielt werden müssen und der rote Faden ist übertragbar.

Ein Spielfeld ist zum Beispiel der eigene „Maschinenraum“ der IT. Hier geht es darum, über ein geeignetes Application Lifecycle Management (ALM) effizientere Change-, Release- und Testprozesse aufzubauen, um die eigene Effizienz zu steigern.

Ein anderes Spielfeld ist die angesprochene Zusammenarbeit mit dem Business. Hier geht es darum, neue Kommunikations- und Entscheidungswege zu etablieren die zwei Zwecke erfüllen: die Schnelligkeit erhöhen und die Möglichkeit schaffen, die wirklichen Bedürfnisse des Business identifizieren zu können.

Das führt häufig zu dem Spielfeld der Kompetenzen: Welche Kompetenzen werden benötigt, um die Kundenbedürfnisse identifizieren zu können?

Ein weiteres Spielfeld ist beispielsweise die Neugestaltung der Strukturen innerhalb der IT. Diese müssen zum Teil intensiv angepasst werden, um den heutigen Anforderungen gerecht zu werden.


Wie steuert man einen derartigen Veränderungsprozess und wie überwindet man Widerstände?

Durch Erfahrung, ein funktionierendes Framework und eine gute Change-Architektur. Darüber hinaus braucht es Klarheit über die Richtung und die Leitplanken. Die Beteiligten müssen involviert werden und brauchen Gestaltungsmöglichkeiten.

Zu den Widerständen: Es gibt keine echte Veränderung ohne Widerstand. Widerstand ist also erst einmal ein gutes Zeichen. Und dann geht es nicht darum, Widerstände zu überwinden. Es geht vielmehr darum zu verstehen, warum die Widerstände existieren. Was sind die Gründe, die den Widerstand hervorrufen? Die müssen von den Führungskräften erkannt und ernst genommen werden und gemeinsam mit den Beteiligten reflektiert werden.

Am Ende dieses Prozesses ist es dann häufig möglich, die Skepsis zu reduzieren und die notwendige Aufbruchstimmung zu initiieren.

Working @ Synaworks – Die Synaworks SAP ALM Portfolio Pakete

In Teil 2 unserer Beitragsserie haben wir bereits die Synaworks Customer Journey und ihre drei Anknüpfungspunkte angesprochen. Lass uns hier nochmal einsteigen und das konkrete Leistungsportfolio beleuchten: Was machen wir als Synaworks eigentlich im Bereich ALM? Und was machen wir dabei anders als andere?

Mit 6 Schritten die Veränderung in der IT-Organisation erfolgreich gestalten

Auf die Frage: „Was verhindert in Ihrer Organisation, notwendige Veränderungen zu initiieren?“ haben 65 IT-Verantwortliche wie folgt geantwortet:

Knapp die Hälfte der Befragten IT-Manager sind demnach der Meinung, dass es an der fehlenden „Vision“ liege, was mit einer Veränderung bezweckt werden solle. Diesen Aspekt können wir aus unserer Beratungspraxis bestätigen – ist für die MitarbeiterInnen das „wozu“ nicht klar, werden sie auch den Aufwand und die Mühe der Veränderung nicht auf sich nehmen.

Wollen Führungskräfte Veränderungen initiieren, empfehlen wir 6 konkrete Schritte, die in dem Synaworks Changerad skizziert sind:

  1. Das Wissen – Gründe und Auswirkungen
    Das Wissen, warum ein Change erforderlich ist, ist die Ausgangsbasis für jeden Changeprozess. Sind die Gründe unklar, werden MitarbeiterInnen die Mühe der Veränderung nicht auf sich nehmen. Der persönliche Einsatz erscheint nur dann gerechtfertigt, wenn klar ist, warum er notwendig ist. Die Aufgabe der Führungskräfte besteht darin, gemeinsam mit den MitarbeiterInnen diese Gründe zu reflektieren und die Konsequenzen aufzuzeigen, die sich für die Organisation, die Abteilung und jeden Einzelnen ergeben, wenn die Veränderungen ausbleiben. Gleichzeitig müssen die MitarbeiterInnen Transparenz darüber erhalten, welche Auswirkungen die anstehenden Veränderungen für sie persönlich, ihre Rolle, Verantwortlichkeiten, Arbeitsweisen und Abläufe haben. 

  2. Zweck der Veränderung
    Der Zweck der Veränderung sagt aus, was mit der Veränderung erreicht werden soll. Er ist also nach vorne, in die Zukunft gerichtet: Was soll nach der Veränderung anders, besser sein als vorher? Die Veränderung muss für die Organisation und die MitarbeiterInnen einen Sinn ergeben, dieser muss transparent gemacht und mit den Beteiligten reflektiert werden. Das bedeutet nicht automatisch, dass alle MitarbeiterInnen durch die Veränderung einen Vorteil haben. Um so wichtiger ist die Führungsaufgabe, die Sinnhaftigkeit der Veränderung mit den Beteiligten zu diskutieren. Erst mit dem Blick auf das „große Ganze“ können wir etwaige individuelle Nachteile akzeptieren.

  3. Kompetenzen 
    Häufig verfügen wir nicht über die notwendigen Kompetenzen, um mit Veränderungen erfolgreich umgehen zu können. Es sind vor allem Selbst-, Sozial- und Methodenkompetenzen, die uns in Veränderungsprozessen helfen – und diese Kompetenzen können erlernt und trainiert werden. „Changekompetente“ MitarbeiterInnen erhöhen die Erfolgswahrscheinlichkeit von Veränderungsprojekten erheblich. Gleichzeitig steigt die Wahrscheinlichkeit, dass mit einer erhöhten Changekompetenz auch die Akzeptanz der Veränderung steigt. Eine wichtige Führungsaufgabe besteht darin, zu erkennen, welche Kompetenzerweiterungen bei welchen MitarbeiterInnen sinnvoll erscheinen. 

  4. Kultur und Werte
    Bei Werten gibt es kein gut oder schlecht, sondern nur ein fit bzw. misfit zu einer spezifischen Situation. So werden für einen erfolgreichen Change einige Werte der Organisation hilfreich, andere dagegen eher hinderlich sein. Essentiell für den Change Prozess ist es, ein realistisches Bild über die tatsächlichen (!) Ist-Werte der Organisationskultur zu haben. Durch Evaluationen lassen sich diese relativ einfach erheben. Die Transparenz über die individuelle Werteausprägung einer Abteilung oder Organisation hilft maßgeblich, den Change Prozess erfolgreich zu gestalten. Gary Hamel, einer der bedeutendsten Management Experten unserer Zeit, sagt: „Es ist unmöglich, in einem Unternehmen Veränderungen zu bewirken, ohne zuerst dessen Kultur verstanden zu haben.“

  5. Kommunikation
    Die offene und stete Kommunikation ist ein weiterer wichtiger Erfolgsfaktor in einem Veränderungsprozess. Dabei können sich die Verantwortlichen an der Maxime orientieren: es kann nicht zu viel kommuniziert werden. Entscheidend dabei ist, dass sich die Mitarbeiter darauf verlassen können, dass von den Verantwortlichen Positives wie Negatives gleichermaßen transparent und zeitnah kommuniziert wird. Haben die MitarbeiterInnen den Eindruck, dass wichtige Aspekte nicht transparent gemacht werden, sind „Flurfunk“ und Gerüchte die Folge – ein „Super-Gau“ für den Veränderungsprozess. 

  6. Gestaltungsmöglichkeiten
    Wir entwickeln erst dann Motivation und Engagement für eine Sache, wenn wir uns mit dem Vorhaben verbunden fühlen. Die Voraussetzung dafür ist, dass MitarbeiterInnen an dem Change Projekt mitwirken und sich einbringen können. Die reine Kommunikation über das Projekt reicht nicht aus, um die berühmte „Anschlussfähigkeit“ herzustellen. Entscheidend ist, die Betroffenen zu aktiv Mitwirkenden zu machen, die – innerhalb definierter Leitplanken – Gestaltungsspielräume am anstehenden Veränderungsprozess haben. 

Werden diese sechs Handlungsfelder von den Verantwortlichen gut „bespielt“, sind wichtige Voraussetzungen geschaffen, dass MitarbeiterInnen durch ihre Haltung und ihr Verhalten zu aktiven Treibern der Veränderung werden.

Sprechen Sie uns gerne an, wenn Sie weiterführende Informationen zum Thema Change und SAP S/4HANA-Transformation wünschen: https://synaworks.com/kontakt/

Neu bei Synaworks Teil 2: 3 Portfoliobereiche – 3 Anknüpfungspunkte beim Kunden

Letztes Mal sprachen wir über das Synaworks Portfolio. Heute möchte ich erfahren wie Synaworks dabei vorgeht! Daniel, was ist denn die Synaworks Customer Journey?

Unsere Synaworks Customer Journey hat aktuell drei Anknüpfungspunkte beim Kunden. Als wir gegründet haben, sind wir mit dem ersten Anknüpfungspunkt gestartet: mit einem starken Fokus auf die Technologie. Dabei haben wir gesagt „Technologie alleine springt zu kurz“ und entwickeln uns vom Technologie-Portfolio über den IT-Prozess – in der Interaktion mit den Rollen, die in diesem IT-Prozess arbeiten – rüber auf das Strategieportfolio. Dann sind wir im Strategieportfolio bei dem Wozu und dem wünschenswerten Zustand und können das runterbrechen auf das Thema Veränderungsinitiierung / -begleitung bis hin zur Academy. Das wäre das Synaworks Portfolio einmal von links nach rechts entwickelt. Also ein Einstieg beim Kunden, über die Technologie hinaus, speziell mit dem Thema ALM mit Fokus auf IT Prozess.

Der zweite Anknüpfungspunkt beginnt auf strategischer Ebene im Portfoliobereich „Strategie“. Es stellt sich die Frage: Wie kann sich die IT als adäquater Partner für die Fachbereiche positionieren? Das ist die Überleitung zu unserem IT-TOM, dem Target-Operating-Modell für die IT-Organisation. Wir machen uns dabei Gedanken, welche Handlungsfelder die IT-Organisation bespielen und adressieren sollte, um bestimmte Ableitungen zu treffen. Dabei hilft das IT-TOM, sich in einer Designphase erstmal eine gewisse Klarheit zu verschaffen, bevor wir später zielgerichtet in die Umsetzung gehen.

Stichwort Umsetzung und Agilität: das wäre dann der Anknüpfungspunkt an unsere Customer Journey. Unter anderem aufgrund der vielen Technologien im SAP-Umfeld, aufgrund der zunehmen Cloudifizierung, steigt die Komplexität massiv. Durch technologische Abhängigkeiten und durch immer mehr Skills, die man benötigt, um in eine andere Art und Weise der Zusammenarbeit zu kommen. Das ist dann auch der Kern: Wenn wir uns in der Umsetzung befinden, gehen wir diese sehr häufig mit agilen Vorgehensweisen an. Was wir darunter verstehen ist, dass Agilität erstmal mehr ist, als die Einführung eines Tools. Agilität ist auch mehr als ein Framework namens Scrum oder Kanban. In unserem Verständnis geht es bei Agilität mehr um das Thema einer anderen Art und Weise der Zusammenarbeit – bis hin, dass wir Agilität als soziale Innovation verstehen. Diese Innovation kann super fruchtbar sein kann, bedeutet aber gleichzeitig eine sehr große Veränderung für die Organisation. Man kann in diesem Prozess nicht sagen: morgen sind wir agil – das ist ein stetiger Lernprozess. Und der ist nicht ohne Energieaufwand und ein agiles Mindset zu haben!

Danke für die Ausführungen, Daniel. Die Orientierung an den drei Anknüpfungspunkten an die Customer Journeys macht es mir schon heute leichter, die verschiedenen Projekte einzusortieren, die mir im Synaworks Alltag begegnen. Lass uns beim nächsten Mal darüber sprechen, wie wir Projekte angehen und was das Besondere an der Synaworks Methodik ist!

Effizientes und standardisiertes Test Management mit SAP Solution Manager und Focused Build für das SAP S/4HANA Projekt bei der WWZ AG

WWZ hat es zum Jahresstart 2021 geschafft: Mit dem neuen Jahr startete das Zuger Versorgungsunternehmen mit über 470 Mitarbeitenden in ihr erstes Jahr auf SAP S/4HANA. Synaworks durfte das Schweizer Unternehmen im SAP S/4HANA Projekt im Bereich Test Management begleiten und unterstützte bei einem risikominimierten Go-Live. Geknallt haben daher zum Glück nur noch die Silvesterböller. Mehr zum Projektverlauf und welche Erkenntnisse sich auch auf andere Branchen übertragen lassen, lesen Sie im Folgenden:

Der Auftrag: standardisiertes und toolgestütztes SAP Test Management „plus“

Testen ist ein wichtiger Teil jedes SAP Implementierungs- und Migrationsprojekts. WWZ hat sich bei ihrem SAP S/4HANA Transformationsprojekt für einen standardisierten und tool-gestützten Ansatz entschieden. Das Synaworks Team begleitete das Projekt vom Testkonzept und dessen Implementierung im SAP Solution Manager bis zur Befähigung und Begleitung der Projektorganisation, die für das Test Management verantwortlich ist. Der eingeführte Standard definiert, wie die erarbeiteten Inhalte und Testfälle auch zukünftig in wiederverwendbarer und strukturierter Form zur Verfügung stehen – denn nach dem Projekt ist immer vor dem (nächsten) Projekt.

SAP ALM Beratung. Connecting People & Technology.

Mit Synaworks die digitale Transformation erfolgreich gestalten.

Kontakt

Die Ausgangslage: Einzeltestfälle in Excel-Format

Der SAP Solution Manager als Test Management Tool ist bei WWZ nicht neu. Infolge eines Releasewechsels auf die Version 7.2 mussten Einzelfunktionstestfälle jedoch zwischenzeitlich in Excel gesammelt werden. Die Testfälle wiesen starke Unterschiede in Qualität, Beschreibungstiefe und Aktualität auf. Daraufhin kam es bei der Testdurchführung stark auf die Verfügbarkeit, Erfahrung und Gewissenhaftigkeit einzelner Tester an. Zudem ergab eine Verwendungsanalyse der regelmäßig genutzten Transaktionen im SAP ERP System, dass viele der Top 100 Transaktionen nicht durch die Excel-Testfälle abgedeckt waren. Die geringe Testabdeckung führte zu zusätzlichen Herausforderungen. Ein standardisiertes und damit qualitativ hochwertiges SAP Test Management war unter diesen Umständen nicht möglich.

Für die SAP S/4HANA Einführung bestand daher Handlungsbedarf: „Ein Projekt dieser Größe verlangt nicht nur nach einer klaren Teststrategie, sondern auch nach qualitativ hochwertigen Fällen, die unabhängig und realistisch getestet werden. Für uns war ein klares und umfassendes Test Management absolut essentiell.“, erläutert Andreas Affeltranger, Test Manager des Projekts und IT-Mitarbeiter von WWZ. In den angesetzten 10 Testphasen im Rahmen des gesamten SAP S/4HANA Transformationsprojektes sollten außerdem erstmalig integrative Prozesse bis hin zu ganzen End-to-End-Szenarien getestet werden – ein ambitionierter Anspruch.

Das Vorgehen: von der Prozessstruktur bis zum integrativen End-to-End Test

Pragmatisch und schnell ans Ziel kommen und dabei den Zeit- und Ressourcenaufwand für die beteiligten Teams so gering wie möglich halten – unter dieser Maßgabe starteten die Experten von WWZ und Synaworks in das gemeinsame Projekt.

Im ersten Schritt galt es, die Business-Prozessstruktur bei WWZ transparent zu machen. Dies geschah Bottom-Up über eine Verwendungsanalyse der genutzten SAP ERP Transaktionen aus den letzten 10 Monaten. In kurzen iterativen Schleifen mit den Fachbereichen wurden die miteinander in Verbindung stehenden Transaktionen erst zu Prozessen und dann Schritt für Schritt zu bereichsübergreifenden Prozessszenarien verknüpft. Das Projektteam identifizierte in kurzer Zeit mehr als 250 Prozesse für 16 Fachbereiche und dokumentierte sie in einer umfassenden Prozessstruktur.

Parallel dazu wurden grundlegende Rahmenbedingungen zum Testvorgehen in einem Testkonzept gesetzt und festgehalten. Daraufhin folgte die Implementierung der Test Suite mit den funktionalen Erweiterungen von SAP Focused Build im SAP Solution Manager.

An anderer Stelle arbeiteten die Experten von WWZ und Synaworks am Thema SAP ERP Schnittstellen: Alle Schnittstellen sollten klar den zugehörigen Prozessen zugeordnet sein und durch eigene Testfälle abgedeckt werden. Mittels halbautomatisierter Generierung von Testfällen auf Basis der Prozessstruktur konnte bereits ein Grundstock an essenziellen Testfällen geschaffen werden, die dann durch die Teams nur noch angereichert und priorisiert werden mussten – ein wichtiger Schritt, um risikooptimiertes Testen zu ermöglichen.

Vor Beginn der ersten integrativen Testphase wurden alle beteiligten Teams gemäß ihrer Rolle im Testprozess geschult. Im weiteren Prozess begleitete das Synaworks Team WWZ in der Rolle des Tool- und Methoden-Coachs durch das Projekt. Bereits während der folgenden Testphasen wurden außerdem End-to-End-Testszenarien aufgebaut und von cross-funktionalen Teams grafisch modelliert und im SAP Solution Manager dokumentiert.

Das Ergebnis: signifikant erhöhte Testabdeckung, Risikominimierung und zukunftssichere Testvorgehensweise

Einem professionellen, tool-gestützten Test Management sowie der erstmaligen strukturierten Testdurchführung ganzer integrativer Prozesse und End-to-End-Szenarien folgte im Januar 2021 der erfolgreiche Go-Live von SAP S/4HANA bei WWZ. Die signifikant höhere Testabdeckung minimierte potenzielle Risiken für das Transformationsprojekt und ein Echtzeit-Reporting erleichterte die aktive Steuerung der Testphasen und die Nachverfolgung von Fehlern.

Juan Janse von der Innflow AG, Projektleiter des SAP S/4HANA Transformationsprojektes bei WWZ, ist zufrieden: „Synaworks für das SAP Test Management ins Boot zu holen war die richtige Entscheidung. Ihre fachliche Expertise kombiniert mit der methodischen Vorgehensweise und dem richtigen Blick für pragmatische Lösungsansätze war für uns sehr wertvoll. So konnten wir uns auf das Wesentliche konzentrieren – nämlich die SAP S/4HANA Transformation selbst.“

Das Projekt zeigt auch die großen Möglichkeiten, die sich über ein innovatives und ganzheitliches Application Lifecycle Management (ALM) erschließen können: Der Einführung von Change Impact Analysen (BPCA), SAP Testautomatisierung und einer weiteren Integration der ALM Prozesse Change- und Release Management stehen nun alle Türen offen. Nicht zuletzt ergab sich dadurch eine bessere Transparenz und eine Optimierung der Zusammenarbeit, indem die Unternehmens-IT und Business-Anwender den SAP Solution Manager als zentrale ALM Plattform gemeinsam nutzen.

Die 4 Top Erkenntnisse aus dem Projekt bei WWZ im Überblick

1. Fachbereiche müssen die Hintergründe des Testprozesses verstehen.

Die Gründe für eine hohe Anzahl an Testphasen sowie der notwendige Ressourcen-Einsatz für den Aufbau der Prozessstruktur muss transparent kommuniziert und überzeugend erklärt werden, da es sich hierbei vielfach um zusätzliche Aufwände für alle Beteiligten handelt. Ein frühes Einbinden, eine Kommunikation in der „Sprache des Fachbereiches“, ein pragmatischer und zeitschonender Ansatz sowie viel Teamwork führten zu einer durchgehend hohen Akzeptanz.

2. Wiederverwendbarkeit der Testfälle ist ein Muss.

In Zeiten von immer schneller aufeinander folgenden SAP Releases und immer kürzerer Zeit zum Testen können Testfälle nicht mehr für jedes Projekt angepasst oder gar neu erstellt werden. Ein Konzept für die Wiederverwendbarkeit von Testfällen, das bestenfalls das Prozess- und Dokumentationsmanagement mit dem SAP Change- und Release Management verbindet, ist essenziell. So gehört die Aktualisierung der Dokumentation und der Testfälle zum kontinuierlichen ALM Prozess.

3. Usability und Transparenz lebe hoch!

Für das Projekt bei WWZ nutzte Synaworks den SAP Solution Manager und das Add-On SAP Focused Build. Die Akzeptanz und Usability des Test Step Designers in SAP Focused Build, welcher Excel-basierte Testfälle überflüssig macht, war durchgehend hoch. Der hohe Standardisierungsgrad der Lösung ermöglicht außerdem eine schnelle Einführung. Durch das Echtzeit Reporting mit dem SAP Test Suite Dashboard ist eine unkomplizierte Steuerung der Testphase und eine aktive Fehlerverfolgung umsetzbar.

4. End-to-End wird zur Normalität.

Testen in End-to-End Szenarien ab dem ersten Test fördert die Qualität der Testphase signifikant. Prozessübergänge und Schnittstellen sind besonders fehleranfällig, wohingegen die wertschöpfenden Prozesse eines Unternehmens häufig bereichsübergreifend organisiert sind. Wenn integratives End-to-End Testen von Beginn an Bestandteil der Teststrategie ist, kann hier viel Zeit und Geld gespart werden.

Schluss mit veralteter Prozessdokumentation – Entdecken Sie die Funktion Change Control im SAP Solution Manager 7.2

Seit dem Solution Manager 7.2 gibt es innerhalb der Lösungsdokumentation nicht mehr nur die eine „Version“ der Prozessstruktur und der dazugehörigen Objekte und Dokumente, sondern mehrere. Im Zuge dessen ist es möglich das Design der Prozesse, Dokumente etc. in einer separaten Umgebung durchzuführen, während die aktuelle produktive Version der Prozesse und Dokumentation jedoch geschützt bleibt.

Ähnlich zu Entwicklungen in einer SAP Systemlandschaft stellt sich dann die Frage, wie die Änderungen aus der Design in die Produktive Umgebung gelangen, im besten Fall synchronisiert zu der technischen Implementierung. Hier kann die „Change Control“ Option das Bindeglied zwischen der Lösungsdokumentation und Ihrem Change Control Management Prozess sein.

Wie sind die Versionen im Solution Manager abgebildet?

Bei den verschiedenen „Versionen“ der Lösungsdokumenten spricht man von sogenannten Branches. Mit der Analogie zu einer SAP Systemlandschaft lässt sich das Prinzip der Branches gut erklären. Hier werden verschiedene Tätigkeiten in den dafür vorgesehenen Branches durchgeführt – ähnlich wie in einem Entwicklungs- und Produktivsystem. Im Entwicklungssystem führt man die Anpassungen an Objekten durch. Sind sie final angepasst, werden die Änderungen in das produktive System überführt. Solange die neue Version noch nicht komplett abgeschlossen ist, ist im produktiven System die „alte“ Version noch immer aktiv.

Dieses Prinzip lässt sich über die Branches auch auf die Inhalte der Lösungsdokumentation übertragen. Hier spricht man dann beispielsweise von der sogenannten Maintenance Branch (entspricht dem „Entwicklungssystem“) und der Production Branch (entspricht dem „Produktivsystem“),  in welcher sich keine Änderungen durchführen lassen. Verglichen mit der alten Business Blueprint aus den vorherigen Solution Manager Versionen ergibt sich folgender Vorteil: es lassen sich alle Inhalte in der Maintenance Branch anpassen, ohne dass die Änderungen direkt in der Production Branch sichtbar sind. In der Production Branch findet der Support beispielsweise immer die aktuell gültige Dokumentation zu den produktiv genutzten Prozessen.

Wie findet der „Transport“ statt?

Damit eine solche Umgebung funktioniert und die Stände aktuell gehalten werden, muss man sich – analog zum SAP Transportwesen – eine Vorgehensweise erarbeiten, wie die fertiggestellten Anpassungen am Ende in die Production Branch gelangen. Um Änderungen in die nächste Branch zu überführen, müssen sie manuell innerhalb der Lösungsdokumentation freigegeben werden.

In diesem manuellen Verfahren verliert man, insbesondere bei großen Organisationen und vielen Änderungen leicht den Überblick. Die Aktivierung der sogenannten Change Control Option schafft hier eine Erweiterung. Hiermit kann die Lösungsdokumentation in das Change Request Management eingebunden werden.

Integration in das Change Request Management

Wird die Change Control Option für eine Branch über die Lösungsverwaltung aktiviert, können innerhalb dieser Branch nur noch Änderungen im Rahmen der Lösungsdokumentation vorgenommen werden, nachdem ein entsprechendes Änderungsdokument (z.B. Normal, Urgent Change etc.) ausgewählt wurde. Das Änderungsdokument dient in diesen Fall als „Transportauftrag“, um die Änderungen kontrolliert in die Production Branch zu überführen.

Die Zuordnung zu einem Änderungsdokument lässt sich dann entweder direkt aus der Lösungsdokumentation oder im Änderungsdokument (im Reiter Lösungsdokumentation) durchführen. Im Änderungsdokument sind später entsprechende Aktionen und Prüfungen integriert, welche die Änderungen beim Live-setzen automatisch in die Production Branch „transportieren“.

So lassen sich neben den technischen Anpassungen – sprich Transporte, die im Änderungsdokument enthalten sind – auch die Dokumentenänderungen und strukturellen Änderungen in der Lösungsdokumentation gemeinsam transferieren. Auf diese Weise wird sichergestellt, dass sowohl die Anpassung eines Objektes, als auch die zugehörige Dokumentation sauber in der jeweiligen produktiven Umgebung ankommen.

Auch in kundeneigenen ChaRM-Vorgangsarten können die Aktivitäten mit aufgenommen werden, wenn sie nicht ohnehin bereits aus dem SAP Standard Vorgangsarten überführt wurden. An dieser Stelle ist es im Übrigen auch möglich den Zeitpunkt anzupassen, beispielsweise wann ein Dokument in die Production Branch überführt werden soll.

Was sind die Konsequenzen?

Man muss sich bewusst sein, dass nach der Aktivierung der Change Control für jede Änderung, in der spezifischen Branch, ein Änderungsdokument notwendig ist. Beispielsweise auch für die Freigabe von Dokumenten – das entspricht einer Statusänderung oder der Anpassung von Testfällen. Die Change Control ist nicht auf verschiedene Objekttypen einzuschränken, sondern ist für alle Elemente gültig. Falls reine Änderungen an der Lösungsdokumentation übertragen werden sollen, macht es im folgenden Schritt Sinn eine Vorgangsart im ChaRM ohne Transportanbindung einzurichten – wie etwa den General oder Admin Change.

Darüber hinaus ist eine Rollenzuweisung (Partnerfunktion) im zugehörigen Änderungsdokument zwingend notwendig. Nur so steht das Änderungsdokument in der Branch auch zur Verfügung. Hier lässt sich wieder die Analogie zum Transportauftrag herstellen: nur wer dort als Mitarbeiter hinterlegt ist, kann auch dem Transport bzw. der Aufgabe Änderungen zuordnen.

Zuletzt sollte nicht unerwähnt bleiben, dass die Aktivierung bzw. Deaktivierung der Change Control nur möglich ist, wenn alle Änderungen aus dieser spezifischen Branch in die Production Branch überführt wurden. Das bedeutet, dass beispielsweise die Maintenance und Production Branch den gleichen Stand benötigen.

Fazit

Mit der Change Control Option bietet die SAP eine sinnvolle Integration für die Änderungskontrolle innerhalb der Lösungsdokumentation in das Change Request Management. Hierdurch kann sichergestellt werden, dass sowohl technische Änderungen als auch die dazugehörige Dokumentation gemeinsam live gesetzt werden und so auch keine Inhalte in der Maintenance Branch „vergessen“ werden.

Speziell in großen Organisationen ist es kaum möglich ohne Change Control die Aktualität der Dokumente zu gewährleisten. Ohne die Funktion ist hier mit alten, inkonsistenten Ständen von Prozessen und Dokumentationen zu kämpfen, welche nie dem produktiven Stand entsprechen – oder sich nur schwer eindeutig identifizieren lassen. Genau hier setzt die Change Control an, um die sonst aufwändige, manuelle Organisation, durch einen Automatismus zu unterstützen.

Wenn Sie bereits mit dem Change Request Management arbeiten und die Dokumentation mit in diesen Prozess aufnehmen wollen, empfehlen wir Ihnen einen Blick auf die Funktion zu werfen. Die zuvor genannten Konsequenzen ergeben sich aus dem dann strengeren Prozess, durch welchen Sie jedoch im Endeffekt mehr Sicherheit und Konsistenz über Ihre Dokumentation erlangen.

Wie können wir Sie unterstützen?

Wir beraten und begleiten Sie bei der Konzeption, Implementierung und Umsetzung einer ALM Plattform – auf prozessualer, technischer und organisationaler Ebene und erarbeiten mit Ihnen gemeinsam die beste Strategie, wie die Funktionen in Ihrer aktuellen Situation bestmöglich eingesetzt werden können.

Wenn Sie sich einen ersten Überblick verschaffen wollen, dann empfehlen wir Ihnen unsere Synaworks Academy Trainings „Application Lifecycle Management mit SAP Solution Manager 7.2 für SAP S/4HANA“ .

Natürlich stehen wir Ihnen als Beratung jederzeit zur Verfügung. Wir sind gespannt und freuen uns sehr auf Ihre Kontaktaufnahme!

Focused Insights – Eine neue Ära für das Reporting mit dem SAP Solution Manager 7.2

Es ist keineswegs übertrieben zu behaupten, dass die enorme Menge an Daten, die im SAP Solution Manager durch verschiedenste Szenarien und angebunden Systemen zusammenlaufen, einer Goldmiene gleichen. Um aus diesem vergrabenen Potenzial aber auch tatsächliche Mehrwerte zu ziehen, braucht es handhabbare und primär flexible Möglichkeiten die Daten darzustellen. Vor allem der Aspekt Daten aus verschiedenen Szenarien miteinander in Beziehung zu setzen und gemeinsam darstellen zu können, ist unseren Kunden wichtig.

Nun ist es so, dass Reporting und vor allem Dashboards bisher nicht gerade die Themen sind, für welche der Solution Manager bekannt ist. Große Fortschritte wurden hier schon mit den Focused Build Funktionalitäten, beispielsweise durch das Solution Readiness oder Test Suite Dashboard, realisiert. Aber ein wahrer Schlüssel zum Datenschatz ist die neue Lösung rund um Focused Insights! Und darüber hinaus ist diese – wohlgemerkt – kostenlos!

Focused Insights ist neben Focused Build und Focused Run in die Gruppe der Focused Solutions einzuordnen. Mit dem Ansatz der Focused Solutions hat die SAP einen intelligenten Weg gefunden, Kunden die Art von Innovation zu bieten, um moderne und agile Arbeitsweisen mit Hilfe des Solution Managers zu etablieren. Während Focused Build sich mit der Umsetzung agiler Projekt-Methodiken innerhalb von SAP-Projekten am Markt bereits einen Namen gemacht hat (im Fokus liegen hier S/4 Einführungen), ist Focused Insights der noch unbekannte kleine Bruder. Unserer Meinung nach wird sich der Bekanntheitsgrad aber in naher Zukunft ändern.

Natürlich gibt es zahlreiche Reporting-Anwendungen in den reinen Standard-Funktionalitäten. Die einzelnen Szenarien bieten teilweise sogar sehr umfangreiche Möglichkeiten. Man denke hier beispielsweise an Test Suite Analytics. In unseren Projekten haben wir allerdings hinsichtlich den Punkten Flexibilität und Integration zwischen verschiedenen Szenarien immer wieder Grenzen feststellen müssen. Eigenentwicklungen oder Excel sind zwar eine Möglichkeit, aber führen zu hohen Instandhaltungskosten und oft unzureichender Verlässlichkeit bezüglich Konsistenz und vor allem Aktualität.

Die Nachricht, dass mit Focused Insights nun ein Add-on verfügbar sein soll, welches „ready-to-use“ Dashboards bietet, die ohne Programmierkenntnisse auf individuelle Kundenwünsche angepasst werden können, hat uns – zugegeben nicht frei von Skepsis – aufhorchen lassen. Nach einigen Monaten der Nutzung ist die anfängliche Skepsis allerdings großem Enthusiasmus gewichen. Die Einrichtung ging deutlich schneller als wir das sonst von SAP-Lösungen gewohnt sind. Insbesondere wenn Sie Focused Build schon im Einsatz haben, reduziert sich der Aufwand deutlich. Grund hierfür ist, dass beide Lösungen auf der ST-OST Komponente basieren.

Nun aber zu den Kronjuwelen in Focused Insights: den Dashboards.

Abbildung 1: Focused Insights Startseite: Dashboard Kategorien

Auf dem Focused Insights Startbildschirm sehen Sie zunächst acht verschiedene Gruppierungen von Dashboards (siehe Abbildung 1). Diese umfassen die Best Practices für bestimmte Zielgruppen. Beispielsweise werden im Strategic Dashboards Daten so konsolidiert, dass sie Managementzwecke erfüllen. Im Tactical und Operations liegt der Fokus auf Monitoring-Daten. im Rahmen von ALM sind die die Operations Control Center (OCC) Dashboards am interessantesten. Denn hiermit können wir die entsprechenden Anforderungen am besten bedienen. Ein Dashboard besteht aus sogenannten Gadgets – eine der 12 Grafiken in Abbildung 2.

Innerhalb der Gadgets können Sie als Dashboard-Ersteller Queries definieren, welche die Daten über eine Vielzahl an verfügbaren Data Providern aus dem oben erwähnten Solution Manager Datenschatz abgreifen. Je nach ausgewähltem Data Provider stehen Ihnen verschiedenste Möglichkeiten für die Aufbereitung oder bedingter Formatierung zur Verfügung.

Sie sehen schon, ganz ohne neue Vokabeln und Strukturen kommt auch Focused Insights nicht aus. Dennoch: Eine Darstellung von Daten aus dem Solution Manager auf derartig hohem Niveau kombiniert mit einer Flexibilität für sehr spezifische Anforderungen war noch nie so einfach!

Eine gute Nachricht ist, dass SAP bereits einige Gadgets lauffähig zur Verfügung stellt. Diese lassen sich entweder genauso übernehmen, oder je nach Anforderung anpassen. Ein Dashboard für die alltäglichen Reporting Anforderungen ist also tatsächlich schnell gebaut. Aber auch bei anspruchsvollen und komplexeren Sachverhalten, wie beispielsweise einer Akkumulierung von noch nicht abgeschlossenen Tickets einer bestimmten Support-Gruppe oder komplexen Berechnungen über den „Calculation“ Data Provider ist einiges möglich. Darüber hinaus lassen sich über Berechtigungen und / oder über einen Expertenmodus für Befehle Einschränkungen der Dashboards steuern. Ein, im Vergleich zu den bisherigen Reporting-Lösungen, gewaltiger Mehrwert ist aber die Integration von verschiedenen Szenarien.

Es ist beispielsweise möglich, Zusammenhänge zwischen Ergebnissen aus der Test Suite mit dem ITSM darzustellen und darauf basierend ein Business Process Monitoring auszuwerten. Sie als Dashboard-Ersteller allein entscheiden welche Informationen in einem Dashboard gemeinsam dargestellt werden. Ständige Wechsel zwischen Szenarien und Oberflächen sind durch diesen zentralen Aspekt nicht mehr notwendig. Ein Absprung aus einem Dashboard in die tatsächlichen Tickets/Objekte in den Solution Manager Szenarien lässt sich ohne Weiteres in den Drilldown-Möglichkeiten eines Gadgets definieren.

Abbildung 2: Beispiel für ein Dashboard mit 12 Gadgets

Unzählige weitere Möglichkeiten gibt es noch zu entdecken. Beispielsweise ein Dark-Mode oder automatische Dashboard-Wechsel im Cockpit Style, die sich gut auf einem großen Flatscreen in Ihrem OCC-Office machen würden.

Fazit

Neben den knackigen Dashboards in SAP UI5 Gewand – übrigens auch schön auf mobilen Endgeräten wie Tablet oder Smartphone – besticht Focused Insights vor allem durch seine Einfachheit und Flexibilität. Natürlich auch durch die nicht zusätzlich anfallenden Lizenzkosten.

Da Focused Insights bereits unzählige Möglichkeiten bietet und diese momentan kontinuierlich sehr stark ausgebaut werden, ist unser Rat: Werden Sie sich zunächst klar welche Informationen Sie aus Ihren Prozessen im Rahmen eines Reportings darstellen wollen. Erst im darauffolgenden Schritt sollten Sie die Umsetzbarkeit in Focused Insights evaluieren. Grundsätzlich ist ein geeigneter Zeitpunkt, um über den Einsatz nachzudenken, wenn Sie mit Ihren Reporting-Anforderungen innerhalb der Standard- oder auch Focused Build Funktionalitäten an Grenzen stoßen.

Im Zusammenhang mit SAP Activate lassen sich durch Focused Insights in jeder Phase Ihres SAP S/4 HANA Projekts Mehrwerte erreichen. Am ehesten ist es aber in die Phase „Run“ einzuordnen. Prinzipiell ist im Zusammenhang mit einer S/4 Einführung ein leistungsfähiges Application Lifecycle Management mit aussagekräftigem Reporting als ein entscheidender Erfolgsfaktor einzustufen. Hierbei ist es essenziell, frühzeitig – am besten parallel zum S/4 Kickoff– eine ALM Roadmap aufzubauen, so dass das S/4 Projekt in jeder Phase optimal unterstützt werden kann. Mehr Informationen dazu finden Sie in unserem Beitrag SAP Solution Manager 7.2 – der Weggefährte des S/4HANA Projekts.

Wie können wir Sie unterstützen?

Wir beraten und begleiten Sie bei der Konzeption, Implementierung und Umsetzung einer ALM Plattform – auf prozessualer, technischer und organisatorischer Ebene – um Ihre S/4 Reise zu einem Erfolg zu machen. Wir unterstützen Sie mit unserer langjährigen Praxiserfahrung und gesammelten Best Practices vieler Umsetzungsprojekte dabei, Ihren „wünschenswerten Zustand“ zu erarbeiten, umzusetzen und in der Organisation langfristig zu etablieren. Für einen ersten Einblick in das Thema möchten wir Ihnen unsere Discovery Workshops für den SAP Solution Manager und Focused Build empfehlen. Wenn Sie sich einen ersten Überblick verschaffen wollen, dann empfehlen wir Ihnen unsere Synaworks Academy Trainings „Application Lifecycle Management mit SAP Solution Manager 7.2 für SAP S/4HANA“ und „SAP S/4HANA mit Focused Build agil umsetzen“. Natürlich stehen wir Ihnen als Berater in jeder Phase Ihrer S/4HANA Reise zur Verfügung. Wir sind gespannt und freuen uns sehr auf Ihre Kontaktaufnahme!

Mit automatisierten SAP Tests den Testaufwand reduzieren und Agilität ermöglichen

Die heutige IT steht vor der Herausforderung, immer kürzere Release-Zyklen bei gleichzeitig steigenden manuellen Testaufwänden für Regressionstests zu managen. Für Key User wird die Durchführung von SAP Tests „neben“ dem Projekt- bzw. Tagesgeschäft zu einer zunehmenden zeitlichen Mehrbelastung.

Um den SAP-Anwendern im Projekt als auch im Betrieb eine hohe Agilität zu ermöglichen und neue Funktionalitäten schnell zur Verfügung stellen zu können, müssen im Monat mehrere Releases geplant werden. Ein integriertes Test Management und die regelmäßige Durchführung von Testzyklen ist hier ein absolutes Muss. Viele Organisationen haben jedoch keine eigenständige Testorganisation bzw. eindeutig festgelegte Rollen, die für diese Aufgaben verantwortlich sind. In diesen Fällen wird die Verantwortung über das Testen oftmals den Key Usern aus den Fachbereichen übertragen. Diese zusätzliche Verantwortung führt nicht selten zur Überlastung der Teams und kann schnell zur Frustration bei den Beteiligten führen. Es steigt die Wahrscheinlichkeit, dass Fehler übersehen, technische Abhängigkeiten nicht erkannt bzw. Änderungen nicht ausreichend getestet werden. Das alles kann negative Konsequenzen zur Folge haben: die Produktqualität sinkt, die Zufriedenheit sowie Akzeptanz der Anwender leidet und im Worst Case kommt es zu Funktionsstörungen im Betrieb.

„Sie führen Ihr SAP S/4HANA Projekt agil durch und möchten nach einem erfolgreichen Go-Live die schnellen, kontinuierlichen Release-Zyklen auch im Tagesgeschäft beibehalten?“

Einen Teil der Lösung bietet Ihnen hier die Test Automatisierung im SAP-Umfeld. Mit einer gut integrierten Testautomatisierung planen Sie die automatisierte Durchführung von Regressionstests über Nacht ein und kümmern sich am nächsten Tag direkt um die Analyse und mögliche Fehlerkorrektur. Dadurch erreichen Sie eine deutlich bessere Testabdeckung und eine höhere Softwarequalität zu einem frühen Zeitpunkt im Entwicklungsprozess. Automatisch steigen damit auch die Motivation und Akzeptanz der Tester aus den Fachbereichen.

Profitieren Sie von einer geeigneten Testautomatisierung mit dem SAP Solution Manager! Wir unterstützen unsere Kunden bei der Einführung der notwendigen Testmethodik, bei der Auswahl und Implementierung des passenden Test-Werkzeugs als auch bei der Etablierung der zugehörigen Testorganisation. Mit den Synaworks Best Practices begleiten wir Unternehmen durch den gesamten Automatisierungsprozess und leisten somit einen Betrag, um Agilität im SAP-Umfeld zu ermöglichen.

Erfahren Sie mehr über unsere Leistungen zum Thema SAP Test Management.

Standardisiertes und systemübergreifendes Release Management. Warum es sexier ist als es sich anhört

„Und dann hat er gesagt, wir müssen unser Projekt diesem vorgegebenen Releasezyklus unterordnen!“ – So oder so ähnlich stelle ich mir einen aufgebrachten Projektleiter an der Kaffeemaschine vor, dem gerade gesagt wurde, dass er nicht mehr machen kann was er will. Zugegeben – nicht mehr live zu gehen, wann man es selbst für richtig hält, ist erst einmal lästig, aber warum streben Organisationen dennoch ein standardisiertes und systemübergreifendes Release Management an? Welche Vorteile stehen dem Gefühl gegenüber nicht mehr unabhängig zu sein oder sich gar mehr abstimmen zu müssen?

Finden wir es heraus: Die TOP 5 Gründe

1. Die technischen Abhängigkeiten werden nicht weniger

Unabhängige Systemlandschaften sind Schnee von gestern. Heute sind es ganze Systemverbünde, die abgestimmt aufeinander bespielt werden müssen – auch unter Einbezug von einer steigenden Anzahl an Cloud Systemen. Gleichzeitig steigt auch die Zahl parallel laufender IT-Projekte immer weiter, Anforderungen aus den Fachbereichen müssen immer öfter und schneller realisiert werden. Unter solchen Rahmenbedingungen noch heterogene und isolierte Vorgehensweisen zuzulassen wird zunehmend zum Risiko.

2. Ich will aber auch schnell sein

Schnelligkeit und Flexibilität vs. Sicherheit und Stabilität ist wohl der klassischste aller Konflikte in der IT. Doch genau das wird von den Fachbereichen gefordert. Sie müssen sich auf die Stabilität der Systeme verlassen und gleichzeitig in der Lage sein, schnell auf neue Rahmenbedingungen reagieren zu können. Ein Release Management mit einer hohen Releasefrequenz bei gleichzeitiger Standardisierung und Qualitätskontrolle kann agile Arbeitsweisen unterstützen und die Stabilität der Systeme sichern. Ein guter Weg, um diese zwei konfliktären Zielvorstellungen doch noch zu managen.

3. Sie wissen wann und wie Sie beim Business anklopfen müssen

Auch für das Business ist Zeit kostbar. Zeitliche Planbarkeit und Klarheit über Interaktions- und Entscheidungspunkte in der Zusammenarbeit zwischen IT und Business zu schaffen, ist für alle Beteiligten von hohem Stellenwert.

Mit einem standardisierten Release Management ist dies möglich: Zeitfenster für integrative Testphasen sind weit im Voraus bekannt und die benötigte Zuarbeit ist definiert und transparent – sei es die Identifikation der betroffenen Geschäftsprozesse und zugehöriger Dokumentationen oder das Durchführen von Tests durch die Fachbereiche.

4. Wer mag schon Testen?

An jeder Front wird implementiert, jeder testet für sich so viel oder so wenig wie er es für richtig hält. Seiteneffekte auf andere und repetitives Testen werden dabei wie selbstverständlich hingenommen. Sind allerdings klare Effizienzkiller. Ein standardisiertes und systemübergreifendes Release Management führt zu einer stabileren Testbasis, als auch zu einer erhöhten Effizienz und gesteigerten Qualität. Denn es wird in Summe einmal und integrativ das getestet, was tatsächlich mit dem nächsten Release in die Produktion gespielt wird. Seiteneffekte auf andere werden früh identifiziert und vor dem Einspielen in die Produktion behoben.

5. Mehr was und weniger wann und wie

Stellen Sie sich vor, jeder könnte sich sofort auf die eigentlichen Inhalte des Projekts konzentrieren und würde nicht jedes Mal aufs Neue definieren, wie die Vorgehensweise ist und welche Qualitätskriterien bzw. Quality Gates einzuhalten sind. Stattdessen sind gemeinsame Standards, klare Verantwortlichkeiten, definierte Spielregeln und ein transparenter Prozess die Basis für alle Beteiligten – sowohl Business als auch IT. Die Pipeline steht also da – ready-to-use – und Sie müssen sie nur noch nutzen.

Einen Überblick über einige Mehrwerte konnten Sie bereits gewinnen. Doch jetzt stellt sich die Frage: Wo fängt man an?

Wie die kleine Anekdote über den Projektleiter bereits erkennen lässt, ist die Herausforderung bei der Etablierung eines systemübergreifenden und standardisierten Release Managements nicht unbedingt die Technologie.

Die Umsetzung eines solchen Vorhabens benötigt einen ganzheitlichen Blick auf der Tool-, Prozess- und Organisationsebene. Neben der Etablierung eines standardisiertem Prozesses mit definierten Spielregeln, bedarf es auch der Berücksichtigung von Organisationsstrukturen im Unternehmen und vor allem ein professionelles Vorgehen bei der Etablierung in der Organisation: Das Release Management umfasst in der Regel eine hohe Anzahl an Stakeholdern und betroffenen Mitarbeitern.

Wie können wir Sie unterstützen?

Wir beraten und begleiten Sie bei der Konzeption, Implementierung und Umsetzung eines systemübergreifenden SAP Release Managements – auf prozessualer, technischer und organisatorischer Ebene. Wir unterstützen Sie mit unserer langjährigen Praxiserfahrung und gesammelten Best Practices vieler Umsetzungsprojekte dabei, ihren „wünschenswerten Zustand“ zu erarbeiten, umzusetzen und in der Organisation langfristig zu etablieren. Dazu gehört die nahtlose Integration des Release Managements in weitere davon abhängige IT-Prozesse wie das Demand Management, Change Control Management und Test Management.

Für einen ersten Einblick in das Thema möchten wir Ihnen unser Modul ST04 „SAP Release Management“ aus der Synaworks Academy empfehlen. In einem Tag gewinnen Sie ein Grundverständnis über den Umfang und die Komplexität des Themas Release Management. Erfahren Sie unter anderem warum ein gutes Demand und Test Management signifikante Treiber für das Release Management sind und welche Arbeitspakete auf Sie warten, sofern Sie sich für die Umsetzung eines standardisierten und systemübergreifenden Release Management entscheiden. Wir teilen mit Ihnen gerne unsere Do’s und Don’t aus unserem Berateralltag.

Kontaktieren Sie uns gerne persönlich!