{"id":33743,"date":"2023-09-29T15:21:13","date_gmt":"2023-09-29T13:21:13","guid":{"rendered":"https:\/\/www.blue.works\/?p=33743"},"modified":"2026-02-17T13:00:45","modified_gmt":"2026-02-17T12:00:45","slug":"sap-releasemanagement-und-die-agilitaet","status":"publish","type":"post","link":"https:\/\/www.blue.works\/de\/sap-releasemanagement-und-die-agilitaet\/","title":{"rendered":"SAP-Releasemanagement und die Agilit\u00e4t"},"content":{"rendered":"\n

In der dynamischen IT-Welt h\u00f6ren wir oft von unseren Kunden, dass durch die Agilit\u00e4t das Releasemanagement<\/a> obsolet geworden sei. Der Trend zur sofortigen Produktivsetzung abgeschlossener Features scheint diesen Glauben zu best\u00e4rken. Doch ist das wirklich der Fall? Oder handelt es sich hierbei um eine R\u00fcckkehr zu alten Gewohnheiten? Alte Hasen werden sich erinnern, wie man fr\u00fcher \u00c4nderungen einfach auf Zuruf in die Produktion (unkoordiniert) \u00fcbertragen hatte. Waren die Anf\u00e4nge also nicht hyper-agil und warum sollten sie es heute nicht mehr sein?<\/p>\n\n\n\n

Continuous Delivery im Kontext von SA<\/strong>P<\/h2>\n\n\n\n

Parallel zur Agilit\u00e4t hat sich das Konzept der kontinuierlichen Lieferung, auch bekannt als Continuous Delivery oder Feature Delivery, etabliert. Dieses Modell zielt darauf ab, in regelm\u00e4\u00dfigen Abst\u00e4nden, beispielsweise alle zwei Wochen, neue Features oder Updates produktiv zu setzen. Aber wie passt Continuous Delivery in das SAP-Releasemanagement?<\/p>\n\n\n\n

In der SAP-Welt, die oft durch komplexe und integrierte Systeme gekennzeichnet ist, k\u00f6nnte man annehmen, dass Continuous Delivery eine Herausforderung darstellt. Aber mit den richtigen Werkzeugen und Prozessen kann es durchaus implementiert werden:<\/p>\n\n\n\n

1. Automatisierte Tests: Ein Schl\u00fcsselaspekt von Continuous Delivery ist die F\u00e4higkeit, schnell und zuverl\u00e4ssig zu liefern. Dies erfordert eine starke Betonung von automatisierten Tests, um sicherzustellen, dass neue Features oder \u00c4nderungen keine bestehenden Funktionen beeintr\u00e4chtigen. Warum automatisiertes Testing unabdingbar sein sollte, haben wir bereits in diesem Artikel beschrieben Testautomatisierung f\u00fcr SAP-Kunden: Warum sie unabdingbar sein sollte \u203a blue.works<\/a><\/p>\n\n\n\n

2. Feedback-Schleifen: Kurze Feedback-Schleifen zwischen Entwicklungs-, Test- und Betriebsteams sind entscheidend. Dies stellt sicher, dass Probleme schnell erkannt und behoben werden k\u00f6nnen, bevor sie in die Produktion gelangen (vgl. DevOps<\/a>).<\/p>\n\n\n\n

3. Flexibles Deployment: W\u00e4hrend einige Features f\u00fcr eine schnelle Auslieferung geeignet sein k\u00f6nnten, erfordern andere, insbesondere in einem SAP-Kontext, m\u00f6glicherweise l\u00e4ngere Test- und Validierungsphasen. Ein orchestriertes Deployment, das sowohl Continuous Delivery als auch traditionelle Release-Zyklen unterst\u00fctzt, ist daher unerl\u00e4sslich und genau hier, spielt das Releasemanagement ein tragende Rolle – n\u00e4mlich bei der Orchestrierung von \u00c4nderungen aus verschiedenen Projekten und Erweiterungen mit unterschiedlichen Change-Geschwindigkeiten. Dies kommt vor allem auch zum Tragen, wenn es darum geht, ein schnelles Continuous Delivery auf neuen Mikroservice-Architekturen, z.B. der SAP BTP, mit einem Unternehmenskern (z.B. einem integrierten ERP-System) mit langsameren Change-Geschwindigkeiten zu kombinieren.<\/p>\n\n\n\n

Warum SAP S\/4HANA kein Mikroservicesystem ist und zahlreiche Abh\u00e4ngigkeiten aufweist<\/strong><\/h2>\n\n\n\n

SAP S\/4HANA und auch der Vorg\u00e4nger SAP ERP sind, wie die Abk\u00fcrzung schon verr\u00e4t, ein integriertes Enterprise Resource Planning-System, das dazu entwickelt wurde, Gesch\u00e4ftsprozesse in Unternehmen zu unterst\u00fctzen und zu optimieren. Es ist kein Mikroservicesystem, sondern ein umfangreiches und komplexes System, das viele verschiedene Gesch\u00e4ftsfunktionen abdeckt. Anbei einige Gr\u00fcnde, warum es kein Mirkoservice-System:<\/p>\n\n\n\n

    \n
  • SAP ERP\/SAP S\/4HANA wurde entwickelt, um eine Vielzahl von Gesch\u00e4ftsprozessen zu unterst\u00fctzen, von Finanzen und Controlling \u00fcber Beschaffung und Produktion bis hin zu Vertrieb und Service. Diese Prozesse sind oft miteinander verkn\u00fcpft und erfordern eine enge Integration, um effizient zu funktionieren.<\/li>\n<\/ul>\n\n\n\n
      \n
    • Da S\/4HANA ein integriertes System ist, m\u00fcssen Daten konsistent und in Echtzeit \u00fcber verschiedene Module hinweg verf\u00fcgbar sein. Dies erfordert eine enge Verkn\u00fcpfung und Abh\u00e4ngigkeit zwischen den verschiedenen Modulen.<\/li>\n<\/ul>\n\n\n\n
        \n
      • Zudem hat SAP hat mit Fiori eine einheitliche Benutzeroberfl\u00e4che f\u00fcr S\/4HANA entwickelt. Dies erfordert eine enge Integration zwischen den verschiedenen Modulen, um eine konsistente Benutzererfahrung zu gew\u00e4hrleisten.<\/li>\n<\/ul>\n\n\n\n
          \n
        • Viele Unternehmen passen S\/4HANA an ihre spezifischen Gesch\u00e4ftsanforderungen an. Diese Anpassungen k\u00f6nnen zu zus\u00e4tzlichen Abh\u00e4ngigkeiten zwischen den Modulen f\u00fchren.<\/li>\n<\/ul>\n\n\n\n
            \n
          • Viele Unternehmen integrieren S\/4HANA mit anderen Systemen, sei es innerhalb des SAP-\u00d6kosystems (wie SAP Ariba, SAP SuccessFactors usw.) oder mit Drittanbietersystemen. Diese Integrationen erzeugen zus\u00e4tzliche Abh\u00e4ngigkeiten.<\/li>\n<\/ul>\n\n\n\n

            Es l\u00e4sst sich also sagen, dass die Komplexit\u00e4t und der integrierte Charakter von S\/4HANA zu vielen Abh\u00e4ngigkeiten zwischen den verschiedenen Modulen und Funktionen f\u00fchren. Dies ist sowohl eine St\u00e4rke als auch eine Herausforderung des Systems, da es Unternehmen erm\u00f6glicht, ihre Gesch\u00e4ftsprozesse umfassend zu optimieren, aber auch eine sorgf\u00e4ltige Planung und Implementierung erfordert.<\/p>\n\n\n\n

            B\u00fcndelung von \u00c4nderungen macht das Change- und Testmanagement effizienter<\/strong><\/h2>\n\n\n\n

            Aus dem o.g. Gr\u00fcnden sollte \u00c4nderungen orchestriert und geb\u00fcndelt werden. Damit reduziert man den Overhead bei Tests und Deployments erheblich. Eine organisierte und strukturierte B\u00fcndelung von \u00c4nderungen f\u00fcr den effizienten Betrieb von solch integrierten Systemen ist unerl\u00e4sslich. So k\u00f6nnen Test-Szenarien einmal erstellt und f\u00fcr mehrere \u00c4nderungen gleichzeitig verwendet werden. Dadurch wird der Testumfang viel gr\u00f6sser als bei Einzel\u00e4nderungen, und die Wahrscheinlichkeit, dass Fehler und unerw\u00fcnschte Seiteneffekte in Regressionstest unentdeckt bleiben, verringert sich stark.<\/p>\n\n\n\n

            Man kann also sagen, dass prinzipiell jede \u00c4nderung die Produktion stresst und durch die B\u00fcndelung der \u00c4nderungen dieser Stress vermindert wird.
             <\/p>\n\n\n\n

            Releasekalender mit verschiedenen Takten zum flexiblen Deployment – aber geplant!<\/strong><\/h2>\n\n\n\n

            Ein vorhersehbarer Release-Zyklus stellt sicher, dass alle Teams im Unternehmen synchron arbeiten. Dies ist insbesondere in gro\u00dfen Organisationen wichtig, in denen Projekte oft interdependente Elemente aufweisen. Ein fester Kalender erm\u00f6glicht es den Teams, ihre Ressourcen effektiv zu allokieren und sicherzustellen, dass ihre Arbeit nicht durch externe Faktoren beeintr\u00e4chtigt wird. Haben die Takte der Releases einen festen Rhythmus, so k\u00f6nnen sich die Anwender aus dem Business besser darauf einstellen.
            <\/p>\n\n\n\n

            \"\"<\/figure>\n\n\n\n

            SAP Best Practice ist es, zwischen drei verschiedenen Changes Paces zu unterscheiden.<\/p>\n\n\n\n

              \n
            1. Innovation Pace – f\u00fcr die grossen Projekte<\/strong>
               Der «Innovation Pace» ist f\u00fcr die grossen Projekte gedacht. \u00c4nderungen aus diesen Projekten haben signifikaten Prozessimpact. D.h. solche Projekte werden sorgf\u00e4ltig geplant, k\u00f6nnen in mehrere Schritten (Waves) produktiv gesetzt werden oder in einem grossen Schritt.
              <\/li>\n\n\n\n
            2. Enhance Pace – f\u00fcr flexiblere Deployments (und Continuous Delivery)<\/strong>
              Der «Enhance Pace» ist dagegen daf\u00fcr da, kleinen Erweiterungen und Verbesserungen ins System zu bringen. Der Prozessimpact sollte minimal sein und jede jede sollte innerhalb eines Changeboard-Komites analysiert und genehmigt werden.
              Hier kommt jedem Betrieb ein gutes Anforderungsmanagement zu Gute: Der Fachbereich darf all seine W\u00fcnsche und Anforderungen aufnehmen. Diese werden bewertet und analysiert. Das spannende ist nun, dass aus einer Anforderung – je nach Analyseergebnis – entweder nur ein Enhance Change entsteht, oder aber gar ein ganzes Projekt. Oder man erkennt, dass viele Anforderungen thematisch geclustert werden k\u00f6nnten und innerhalb eines Erweiterungsprojektes umgesetzt werden.
              Schafft man es nun, viele dieser Arbeiten transparent zu koordinieren und Schritte f\u00fcr das Testing- und Deployment zu automatisieren (vgl. Piplines), ist man wohl schon beim Continuous Delivery angekommen.
              <\/li>\n\n\n\n
            3. (Bug)fixing Pace: Ja, der Produktivstillstand darf direkt behoben werden<\/strong>
              Es gibt Zeiten, in denen sofortiges Handeln erforderlich ist, insbesondere bei kritischen Produktionsfehlern. Der «Fix Pace» bietet genau diese Flexibilit\u00e4t. Besteht ein Fehler in der Produktion, soll dieser so schnell wie m\u00f6glich behoben werden – ohne lange auf das n\u00e4chste Deploymentfenster warten zu m\u00fcssen.
              <\/li>\n<\/ol>\n\n\n\n

              Macht meine Mikroservicesarchitektur nun dann ein Releasemanagement obsolet<\/strong><\/h2>\n\n\n\n

              Gekapselte Mikroservices w\u00fcrden in der Tat eine h\u00f6here Flexibilit\u00e4t bieten und es Organisationen erlauben, schneller und h\u00e4ufiger zu deployen. Dies ist einer der Hauptvorteile des Mikroservice-Designs. Dennoch bedeutet das Vorhandensein von Mikroservices nicht zwangsl\u00e4ufig, dass das traditionelle Releasemanagement vollst\u00e4ndig \u00fcberfl\u00fcssig wird. Hier sind einige \u00dcberlegungen dazu:<\/p>\n\n\n\n

                \n
              • Komplexit\u00e4t: Trotz der Vorteile der Unabh\u00e4ngigkeit k\u00f6nnen Mikroservices komplex sein, insbesondere in einem \u00d6kosystem und im Zusammenspiel mit SAP S\/4HANA mit vielen miteinander interagierenden Diensten. Ein effektives Releasemanagement kann also noch immer helfen, diese Komplexit\u00e4t zu steuern und sicherzustellen, dass es bei der Einf\u00fchrung neuer Funktionen oder \u00c4nderungen zu keinen unbeabsichtigten Nebenwirkungen kommt.<\/li>\n<\/ul>\n\n\n\n
                  \n
                • Abh\u00e4ngigkeiten: Selbst wenn Mikroservices gut gekapselt sind, k\u00f6nnen dennoch Abh\u00e4ngigkeiten zwischen ihnen bestehen. \u00c4nderungen in einem Service k\u00f6nnten Auswirkungen auf andere haben, insbesondere wenn sie gemeinsam genutzte APIs oder Datenbanken verwenden. Zum Beispiel: F\u00e4llt ein Mikroservices f\u00fcr die Authentifizierung aus, k\u00f6nnen alle anderen Mikroservices davon betroffen sein – auch eine kleine \u00c4nderung (wie z.B. der Austausch der Zertifikatskette bzw. der Trusted CA) die gekapselt funktionert, kann grosse negative Seiteneffekte f\u00fcr alle anderen Webserivces haben.<\/li>\n<\/ul>\n\n\n\n
                    \n
                  • Qualit\u00e4tssicherung: Unabh\u00e4ngig von der Architektur ist eine gr\u00fcndliche Qualit\u00e4tssicherung unerl\u00e4sslich. Bei h\u00e4ufigen Deployments kann die Qualit\u00e4tssicherung eine Herausforderung darstellen, insbesondere wenn keine ausreichenden automatisierten Tests vorhanden sind.<\/li>\n<\/ul>\n\n\n\n
                      \n
                    • Stakeholder-Kommunikation: Bei gro\u00dfen Organisationen kann es sinnvoll sein, ein Releasemanagement beizubehalten, um sicherzustellen, dass alle relevanten Stakeholder \u00fcber bevorstehende \u00c4nderungen informiert sind und um Feedback zu sammeln.<\/li>\n<\/ul>\n\n\n\n

                      Letztendlich bringen Mikroservices tats\u00e4chlich die M\u00f6glichkeit, Features h\u00e4ufiger und unabh\u00e4ngig voneinander zu deployen (Continuous Delivery). Es bleibt aber wichtig, Deployments zu orchestrieren, zu \u00fcberwachen und sicherzustellen, dass sie den Erwartungen der Stakeholder und den Qualit\u00e4tsstandards des Unternehmens entsprechen und vor allem: \u00c4nderungen mit allf\u00e4lligen langsameren Change-Pace Systemen abzustimmen.<\/p>\n\n\n\n

                      Eine gesamthafte Vorausplanung macht das Deployment sogar schneller<\/strong><\/h2>\n\n\n\n

                      Jeder, der in einem gro\u00dfen Unternehmen gearbeitet hat, kennt die Herausforderungen, die mit der Koordination verschiedener Abteilungen einhergehen. Hier bietet das Releasemanagement einen sehr guten Koordinationspunkt. Wenn beispielsweise die Finanzabteilung eine Jahresendverarbeitung plant, kann das IT-Team sicherstellen, dass dies im Releasekalender ber\u00fccksichtigt wird, um potenzielle Konflikte zu vermeiden.<\/p>\n\n\n\n

                      Weiterhin nehmen Cyber-Bedrohungen st\u00e4ndig zu und Sicherheitspatches sind unerl\u00e4sslich. Mit einem festen Releasemanagement werden Zeitslots f\u00fcr Securityupdates bereits im Voraus definiert. Das bedeutet, dass der zeitraubende Prozess, diese Slots mit Stakeholdern abzustimmen, entf\u00e4llt. Dies f\u00f6rdert nicht nur die Effizienz, sondern stellt auch sicher, dass kritische Sicherheitsupdates nicht aufgrund von Planungskonflikten verz\u00f6gert werden.<\/p>\n\n\n\n

                      Die Notwendigkeit, schnell und agil zu sein, steht ausser Frage. Doch in komplexen IT-Umgebungen, insbesondere in solchen, die von integrierten SAP-Systemen unterst\u00fctzt werden, ist ein ausgewogenes Releasemanagement (derzeit noch) unerl\u00e4sslich. Es l\u00e4sst sich sagen, dass, w\u00e4hrend Agilit\u00e4t und Continuous Delivery ihre eigenen Vorteile bieten, das traditionelle Releasemanagement, insbesondere in komplexen Systemen wie SAP, immer noch seinen Platz hat. Es geht darum, das Beste aus beiden Welten zu kombinieren, um sowohl schnell als auch sicher zu liefern.<\/p>\n\n\n\n

                      Fragen Sie uns doch einfach, wie Sie die Vorteile der Agilit\u00e4t als auch des strukturierten Releasemanagements nutzen und technisch abbilden k\u00f6nnen.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"

                      In der dynamischen IT-Welt bekommen wir von unseren Kunden oft zu h\u00f6ren, dass mit der Agilit\u00e4t das Releasemanagement obsolet geworden sei. Der Trend zur sofortigen Produktivsetzung abgeschlossener Features scheint diesen Glauben zu best\u00e4rken. Doch ist das wirklich der Fall? Oder ist das eine R\u00fcckkehr alter Gewohnheiten? Alte Hasen werden sich erinnern, wie man anno dazumal \u00c4nderungen einfach auf Zuruf in die Produktion geschossen hatte. Waren die Anf\u00e4nge also nicht hyper-agil und warum sollten sie es heute nicht mehr sein?<\/p>\n","protected":false},"author":8,"featured_media":33744,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[96],"tags":[261,233,251,252],"class_list":["post-33743","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sap-alm-insights","tag-alm360-de","tag-focused-build-de","tag-sap-cloud-alm-de","tag-sap-solution-manager-de"],"acf":[],"aioseo_notices":[],"jetpack_featured_media_url":"https:\/\/www.blue.works\/wp-content\/uploads\/2023\/09\/Screenshot-2023-09-29-at-151053.png","_links":{"self":[{"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts\/33743","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/comments?post=33743"}],"version-history":[{"count":7,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts\/33743\/revisions"}],"predecessor-version":[{"id":45169,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts\/33743\/revisions\/45169"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/media\/33744"}],"wp:attachment":[{"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/media?parent=33743"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/categories?post=33743"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/tags?post=33743"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}