Bewährte Methoden für die Planungs-Phase

Während der Planungsphase einer Greenfield-SAP-Implementierung stößt das Projekt in der Regel auf verschiedene Herausforderungen und Chancen. In diesem Abschnitt werden fünf wichtige Erkenntnisse aus SAP bei Implementierungen auf der AWS grünen Wiese erörtert, an denen das AWS Professional Services-Team beteiligt war. Sie können einige dieser Empfehlungen umsetzen, noch bevor Ihr Projekt beginnt oder das Beratungsteam involviert wird. Die Bereitstellung von Dokumententwürfen wie der Rollen- und Zuständigkeitsmatrix oder der Kontaktliste des Teams trägt dazu bei, den Anlaufprozess zu beschleunigen.

Erstellen einer RACI-Matrix

Die Erstellung einer Matrix zur Zuweisung von Zuständigkeiten für das Infrastrukturteam ist für jedes Implementierungsprojekt von entscheidender Bedeutung. Diese Matrix hat die Form eines umfassenden Diagramms mit der Bezeichnung „Verantwortliche, Rechenschaftspflichtige, Konsultierte und Informierte“ (RACI). Das RACI wird verwendet, um Rollen, Aufgaben und Aufgaben in einer komplexen Teamstruktur zu klären. Es sollte in Zusammenarbeit mit dem AWS SAP Cloud-Team, dem SAP-Basis-Team, dem SAP-Systemintegrator (SI) und dem Kunden entwickelt werden. Dies kann von einer dieser Gruppen oder von einem Projektmanager gesteuert werden. Der Aufbau des RACI ohne den Beitrag dieser Stakeholder führt zu Inkonsistenzen, Lücken und manchmal sogar Konflikten. Es ist wichtig, alle Phasen des Projekts zu berücksichtigen. Das RACI im Voraus zu haben, stärkt die Partnerschaft zwischen allen Beteiligten und schafft Klarheit. Idealerweise sollte das RACI vor dem Projektstart abgeschlossen sein.

Hier ist ein Auszug aus einer RACI-Beispielmatrix für ein SAP-Implementierungsprojekt auf Greenfield.

Laden Sie die vollständige RACI-Matrix herunter

Überprüfen Sie die Leistungsbeschreibung

Machen Sie sich mit allen Elementen der Leistungsbeschreibung (Statement of Work, SoW) für AWS Beratungs- und Beratungsdienstleistungen vertraut und überprüfen Sie die Leistungsbeschreibung gemeinsam mit den wichtigsten Stakeholdern, sodass die Ergebnisse für alle verständlich sind. Wenn das Infrastrukturteam beabsichtigt, mehr als das zu tun, was in der Leistungsbeschreibung festgelegt ist, sollten Sie dies unbedingt im Protokoll „Risiken, Annahmen, Aktionen, Probleme, Abhängigkeiten und Entscheidungen“ (RAAIDD) dokumentieren. Bei einem SAP-Implementierungsprojekt auf der grünen Wiese ist es von größter Bedeutung, flexibel und agil zu bleiben. Daher ist es üblich, von der Leistungsbeschreibung abzuweichen. Erwartungen können jedoch in Vergessenheit geraten, wenn der AWS Implementierungspartner anfängt, über das hinaus zu liefern, was dokumentiert ist. Wenn Änderungen auftreten, sollten Sie eine fortlaufende Liste mit dem neuen Arbeitsumfang und den Kompromissen führen, die möglicherweise eingegangen werden müssen. Für einen Wasserfall-Projektansatz muss ein Prozess für das Umfangsänderungsmanagement definiert und implementiert werden. Für ein agiles Projekt ist ein Prozess zur Priorisierung von Backlogs besser geeignet, um den Umfang zu verwalten.

Überlegungen:

• Achten Sie im weiteren Verlauf des Projekts darauf, den neuen Umfang zu erfassen und alle neuen Ergebnisse zu definieren. Auf diese Weise können Sie Ihre Erwartungen besser in den Griff bekommen und Unterstützung bei der Priorisierung Ihres Backlogs in Anspruch nehmen.

• Identifizieren und priorisieren Sie Änderungen und Aufgaben an der Dokumentation sowie den bestehenden Lieferrückstand, sodass die Dokumentation während der gesamten Laufzeit des Projekts erstellt werden kann und nicht bis zum Ende verzögert werden muss.

• Führen Sie während des gesamten Projekts regelmäßig eine ausführliche Beschreibung der Leistungsbeschreibung durch, um die Ergebnisse und Prioritäten im Auge zu behalten.

• Stellen Sie bei einer Produktionsumstellung sicher, dass eine Leistungsbeschreibung mit Lesezugriff mindestens 12 Monate im Voraus genehmigt wurde, um den Hypercare-Support zu unterstützen.

Erstellen Sie ein Team-Organigramm und eine Kontaktliste

Erstellen Sie ein übergeordnetes Organigramm, das die Teams und die Führungsstruktur darstellt. Gehen Sie tiefer, indem Sie eine teamübergreifende Kontaktliste entwickeln, die den Namen, den Titel und die Rolle aller Mitglieder des Infrastrukturteams sowie wichtige Ansprechpartner für verschiedene Funktionen wie Sicherheit, Netzwerk- und Firewall-Betrieb, Microsoft Active Directory, internen Cloud-Betrieb und Serverbetrieb enthält. Jeder sollte wissen, wer beteiligt ist und welche Rolle er im Projekt spielt. Verzögerungen und Missverständnisse treten unweigerlich auf, wenn das Team nicht über diese Informationen verfügt. Es ist auch wichtig, die Titel der Stakeholder zu verstehen. Beispielsweise möchten Sie Stakeholder auf Direktorenebene nicht zu Arbeitsdesignsitzungen oder täglichen Stand-Ups einladen, es sei denn, sie sind maßgeblich an den Diskussionen beteiligt. Wenn Sie Titel und Rollen kennen, können Sie die richtigen Personen zu den entsprechenden Besprechungen einladen. Wenn Sie die Teams in einem Organigramm visualisieren können, können Sie besser verstehen, wie die Teams strukturiert sind und gemeinsam an dem Projekt arbeiten.

Das folgende Diagramm zeigt ein Beispiel für ein typisches Organigramm von SAP in der AWS Infrastruktur.

Richten Sie ein Kooperationsmodell mit Ihrem internen Cloud-Team ein

Wenn Ihre IT-Organisation über ein internes AWS Cloud-Team verfügt, sollten Sie ein Modell für die Zusammenarbeit mit diesem Team festlegen und die Aufgaben, die das Team ausführen wird, im Vergleich zu den Aufgaben des AWS Implementierungspartners (z. B. AWS Professional Services oder AWS Partner) klären. Eine wichtige Verantwortung, die es zu berücksichtigen gilt, ist die Unterstützung von Umgebungen nach deren Bau und Übergabe. Wenn es beispielsweise nur zwei AWS SAP-Cloud-Architekten gibt, die eine Infrastruktur mit mehreren Landschaften und mehreren Umgebungen für ein Dutzend SAP-Anwendungen aufbauen, verfügen sie nicht über die Bandbreite, um die Umgebung zu unterstützen, die sie abschließen und gleichzeitig neue Umgebungen aufbauen. Eine Möglichkeit besteht darin, das interne Cloud-Team zu bitten, den Support der fertigen Umgebungen zu übernehmen. Dies gibt dem internen Team die Möglichkeit, zu lernen und Verantwortung für die Umgebungen zu übernehmen. Sie werden irgendwann für die Wartung und Erweiterung dieser Umgebungen verantwortlich sein, sobald das Projekt voranschreitet und ein neuer Arbeitsumfang festgelegt ist.

Die internen Cloud-Infrastruktur- und DevOps Cloud-Teams sollten sich auch auf die Art der zu verwendenden Automatisierungssoftware einigen — zum Beispiel, ob Terraform als Infrastructure-as-Code-Tool (IaC) verwendet AWS CloudFormation werden soll. In ähnlicher Weise könnten sie sich dafür entscheiden, AWS Systems Manager oder Ansible für Konfigurationsaufgaben wie das Bootstrapping von Volumes und möglicherweise SAP-Installationen zu verwenden. Diese Entscheidungen sollten dokumentiert werden. Wenn außerdem ein Überwachungs- und Beobachtbarkeits-Dashboard eines Drittanbieters erforderlich ist, dies jedoch in der Leistungsbeschreibung nicht enthalten war, sollten Sie in der Zwischenzeit die Einrichtung von Überwachungs- und Protokollierungs-Hooks mithilfe von Amazon CloudWatch und Amazon Simple Notification Service (Amazon SNS) in Betracht ziehen. Das interne Cloud-Team kann zu einem späteren Zeitpunkt die Integration mit einer Überwachungslösung eines Drittanbieters implementieren.

Das Einsatzmodell oder die Supportvereinbarung sollten ebenfalls Teil der RACI-Matrix sein und in der Leistungsbeschreibung dargelegt werden. Durch die Nutzung AWS von Diensten kann ein erheblicher Automatisierungsgrad erreicht werden. In der SoW- und RACI-Matrix sollte festgelegt werden, was im Rahmen des SAP-Implementierungsprojekts auf der grünen Wiese erreicht werden muss und was an das Betriebsteam delegiert werden kann.

Wenn Sie ein Engagement-Modell einrichten, legen Sie fest, ob ein Wasserfall-, ein agiler oder ein gemischter Ansatz die wichtigste Methode für die weitere Entwicklung sein wird. AWS Professional Services beobachtete bei Projekten, bei denen ein agiler oder gemischter Ansatz implementiert wurde, im Vergleich zu einem Wasserfallansatz eine Steigerung der Aufgabenerfüllung um 300 Prozent und eine Verkürzung der Planungszeit um 94 Prozent. In der Planungsphase sollten Sie außerdem gemeinsam mit dem Kunden einen Kommunikationsplan und einen Tooling-Ansatz wählen. Die folgende Tabelle zeigt ein Beispiel für einen Kommunikationsplan.

Stellen Sie abschließend sicher, dass Sie frühzeitig den Kunden und das SAP-Basis-Team identifizieren, die das Projekt unterstützen werden. Sie bei der Implementierung und Migration neuer Lösungen zu schulen, ist der Schlüssel zu einem frühen Start von Wissenstransfersitzungen.

Dokumentieren des Aufbau- und Bereitstellungsprozesses für die Cloud

Wenn Ihre IT-Organisation über ein internes Cloud-Team verfügt, sollte dieses Team den Aufbau- und Bereitstellungsprozess der Cloud anhand von Prozessablaufdiagrammen dokumentieren und diese Diagramme mit dem gesamten Team teilen. Sie möchten, dass Ihre wichtigsten Stakeholder Engpässe oder Ineffizienzen im Prozess leicht erkennen und verstehen, welche Rolle Ihre bestehenden internen Prozesse bei der Entstehung von Ineffizienzen oder Verzögerungen spielen. Im folgenden Beispiel können Sie sehen, dass der Active-Directory-Beitritt und die Aktualisierung des Domain Name System (DNS) am längsten dauern. Dieses Bild könnte die Teams dazu motivieren, zusammenzuarbeiten und herauszufinden, wie der Zeitaufwand für diesen Prozessschritt reduziert werden kann.

Überlegungen:

• Dokumentieren Sie den Helpdesk-Prozess und den Workflow getrennt, geben Sie diese Informationen an das Infrastrukturteam weiter und stellen Sie sicher, dass jeder Zugriff auf die Helpdesk-Tools hat, sodass Sie sich nicht auf eine Person verlassen müssen. Oftmals kann es zu einem komplizierten und zeitaufwändigen Ticketprozess für Active-Directory-Verknüpfungen, DNS-Updates, das Öffnen von Firewalls und das Anfordern von Verschlüsselungsschlüsseln kommen. Es ist wichtig, diese Prozesse zu dokumentieren und das Service Level Agreement (SLA) jedes Teams in der Projektplanungsphase zu berücksichtigen. Es hilft auch dabei, die Gründe für eine Verzögerung oder einen Engpass zu erklären, dessen Beseitigung besondere Aufmerksamkeit erfordert.

• Weisen Sie einen benannten Ansprechpartner für Active-Directory- und Firewall- oder Netzwerkaufgaben zu. Diese speziellen Ressourcen sollten Teil Ihres Projekts sein. Wenn Sie sich auf Servicetickets verlassen müssen, können Sie die Service-SLA nicht kontrollieren.

Projekt-Roadmaps und Meilenstein-Tracker

Die folgenden Diagramme enthalten ein Beispiel für eine Roadmap für ein mehrjähriges SAP-Projekt auf AWS der grünen Wiese.

Die folgende Tabelle zeigt beispielhafte Zeitpläne für die Zusammenarbeit mit AWS Professional Services für dasselbe Projekt.

Die folgende Tabelle zeigt einen Meilenstein-Tracker für die Inbetriebnahme dieses Projekts.