“Die und wir” … und leider oftmals wenig das gemeinsame Miteinander. Man kann buchstäblich sagen:

Zwei Welten treffen aufeinander.

Die Unterschiede zeigen sich in den Prozessen, den Tools, den Rollen und auch in der Sprache; dem Wortschatz, um genau zu sein.

RfC vs. Refinement und ChaRM vs. Confluence und Jira

Der Request for Change (RfC) stellt das Begehren nach Veränderung dar. In SAP. Der Product Owner ermittelt den Bedarf des Kunden – der Fachabteilungen – indem er Stakeholder Management betreibt und mit seinem Klientel spricht. In SAP-Welt entscheidet der Change Manager oder das Change Advisory Board (CAB) darüber, ob ein RfC umgesetzt werden soll. In Scrum ist es der Product Owner, der über seine Gespräche mit den Stakeholdern den dringendsten Bedarf ermittelt. SAP hat ChaRM, die Non-SAP’ler haben Confluence und Jira.

Test Suite vs. Zephyr oder Xray

In SAP sieht der Prozess eines sogenannten “normal Changes” vor, dass nach erfolgter Genehmigung des RfCs über ein oder mehrere Änderungsanträge die Umsetzung durch das Development erfolgt. Ein Statuswechsel wird das Testen anstoßen. Sowohl das manuelle Testen als auch die Testautomatisierung (via CBTA) wird über die Test Suite des SAP Solution Managers administriert. Scrum sagt, dass das Development Team dafür verantwortlich ist am Ende eines jeden Sprints ein qualitativ hochwertiges Increment zu liefern. Es obliegt also dem Development Team auch das Testen durchzuführen. Verwaltet wird es zumeist über Tools wie Zephyr oder Xray.

Continuous Irgendwas und wer gibt den Takt vor?

SAFe hätte gerne ein Release on Demand und in Scrum – oder besser gesagt in der Softwareentwicklung – wird das oftmals Continuous Integration / Continuous Delivery (CI / CD) genannt. Ein SAP Change Management tickt da ein wenig anders und das ist teilweise auch gesetzlichen Regularien und / oder dem Regelwerk einer internen Revision geschuldet. Die Vorstellung eine gerade umgesetzte Funktionalität (User Story) mal eben durch den Product Owner abnehmen zu lassen und es dann eine halbe Stunde später produktiv zu haben, lässt sich in der SAP-Welt oftmals nicht realisieren. Insofern wäre die Vorstellung eines CI / CD gänzlich für das gesamte Projekt umgesetzt zu haben manchmal weltfremd. Aber es muss bei weitem auch nicht heißen, dass man nur viermal im Jahr deployen kann.

Conclusio

Unterschiede in der Arbeitsweise der beiden Welten – SAP und Non-SAP – gibt es mehr als hier in unserem kurzen Blog aufgeführt sind und häufig liegt das größte Delta im Mindset der jeweiligen Spezialisten und Experten. Um vorhandene Differenzen zu überwinden, bedarf es der Fähigkeit beide Sprachen zu sprechen und die Prozesse, Methoden und Tools der SAP’ler wie auch der Non-SAP’ler zu kennen. Wir, die GesAPro – Gesellschaft für Arbeits- und Projektorganisation mbH & Co. KG, kennen beide Welten, sprechen deren jeweilige Sprache und kennen deren Gebräuche.