計画段階のベストプラクティス

SAP グリーンフィールド導入の計画段階では、通常、プロジェクトの最中にさまざまな課題や機会が生じます。このセクションでは、 AWS プロフェッショナルサービスチームが関与した SAP on AWS グリーンフィールド実装に基づく 5 つの重要な学習事項について説明します。以下の推奨事項の中には、プロジェクトを開始する前やコンサルティングチームが参加する前でも、実践に生かせるものがあります。役割と責任を記したマトリックスや、チームの連絡先リストなどの文書の下書きは、計画立案のプロセスを迅速化するのに役立ちます。

RACI マトリックスを作成する

インフラストラクチャチームの役割分担を示すマトリックスの作成は、あらゆる導入プロジェクトに欠かせません。このマトリックスは、責任 (Responsible)、説明責任 (Accountable)、相談先 (Consulted)、報告先 (Informed ) (RACI) を示した包括的な表です。RACI は、複雑なチーム構造の役割、割り当て、タスクを明確にするために使用されます。これは、 AWS SAP クラウドチーム、SAP Basis チーム、SAP システムインテグレータ (SI)、および のお客様と共同で開発する必要があります。作成を主導するのはどのグループでも構いませんし、プロジェクトマネージャーが主導しても構いません。利害関係者から意見を求めることなく RACI を作成すると、矛盾やギャップ、ときには対立なども生じます。プロジェクトのすべての段階を考慮に入れることが重要です。事前に RACI を作成しておけば、関係者全員の連携を強化し、透明性を確保することができます。RACI は、プロジェクトの開始前に作成しておくのが理想的です。

以下は、SAP グリーンフィールド導入プロジェクトの、RACI マトリックスのサンプルから一部を抜粋したものです。

RACI マトリックスの完全版をダウンロード

SoW を確認する

AWS コンサルティングおよびアドバイザリサービスの作業明細書 (SoW) のすべての要素を理解し、主要な利害関係者と SoW を共同でレビューして、成果物がすべての人が明確に理解できるようにします。インフラストラクチャチームが SoW で定義されている以上のことを行う場合は、リスク、前提、アクション、問題、依存関係、決定 (RAAIDD) ログにそのことを必ず文書化してください。グリーンフィールド SAP 実装プロジェクトでは、機敏かつ俊敏性を維持することが最も重要であるため、SoW からの逸脱は一般的なシナリオです。ただし、 AWS 実装パートナーが文書化された内容を超えて提供し始めた場合、期待が不明瞭になる可能性があります。変更が生じた場合は、新しい作業範囲とそれによって生じる可能性のあるトレードオフとを記した最新のリストを作成しておく必要があります。ウォーターフォール型のプロジェクトでは、作業範囲の変更管理プロセスを規定し実行に移すことが不可欠です。アジャイル型のプロジェクトでは、作業範囲の管理にはバックログの優先順位付けプロセスの方が適しています。

考慮事項:

• プロジェクトの進行中は最新の作業範囲を把握し、新しい成果物があれば明記します。そうすることで、予測事項を管理でき、バックログの優先付けを行う際は支援を求めることができます。

• ドキュメントの変更やタスクを既存のデリバリーのバックログと共に特定して優先付けすれば、ドキュメントをプロジェクトの終了時まで遅らせることなく、期間中随時作成することができます。

• 成果物と優先順位を常に把握するために、プロジェクト全体で定期的な SoW ウォークスルーを実施します。

• 本番稼働カットオーバーでは、ハイパーケアのサポートに役立つように、少なくとも 12 か月前に読み取り専用アクセスが承認された SoW を用意してください。

チームの組織図と連絡先リストを作成する

チームとリーダーシップ構造とを示す、組織の概略図を作成します。さらに掘り下げるときは、インフラストラクチャチームのメンバーと、各種機能 (セキュリティ、ネットワークとファイアウォールのオペレーション、Microsoft Active Directory、インハウスのクラウドオペレーション、サーバーオペレーションなど) の主要連絡先を含めた全員の氏名、肩書、役割が載ったチーム横断的な連絡先リストを作成します。誰がどのような役割でそのプロジェクトに関わっているのかを、全員が把握している必要があります。チーム内でこうした情報が共有されていないと、遅延や誤解が起きることは避けられないためです。また、利害関係者の肩書きを把握しておくことも同様に重要です。例えば、設計の分科会や日々の簡単な打ち合わせに、話し合いの主要メンバーでもない限りディレクターレベルの利害関係者を招こうと考える人はいないはずです。肩書や役割を把握していれば、適切な人物を関連する会合に呼ぶことができます。組織図を使ってチームが視覚化されていると、チーム内の構造を理解したうえで、プロジェクトに共に取り組むことができます。

次の図は、一般的な SAP on AWS インフラストラクチャの組織図の例を示しています。

インハウスのクラウドチームのエンゲージメントモデルを作成する

IT 組織に社内 AWS クラウドチームがある場合は、そのチームとのエンゲージメントモデルを確立し、 AWS 実装パートナー ( AWS Professional Services や AWS Partner など) が実行する作業と比較して、そのチームが実行する作業を明確にする必要があります。考慮すべき主な役割の 1 つに、チームが構築して引き渡した環境に対するサポートがあります。例えば、多数の AWS SAP アプリケーション用にマルチランドスケープおよびマルチ環境インフラストラクチャを構築している SAP クラウドアーキテクトが 2 人しかいない場合、同時に新しい環境の構築と構築を完了する環境をサポートする帯域幅はありません。その場合は、完成後の環境のサポートをインハウスのクラウドチームに引き継いでもらうことが 1 つの方法となります。そうすれば、インハウスのチームはその環境を理解し、環境の責任を負う機会が得られます。プロジェクトが進行し、新しい作業範囲が決まれば、チームは最終的にその環境のメンテナンスと拡張に対する責任を負うことになります。

社内クラウドインフラストラクチャとクラウド DevOps チームは、使用するオートメーションソフトウェアのタイプについても合意する必要があります。例えば、 AWS CloudFormation または Terraform をコードとしてのインフラストラクチャ (IaC) ツールとして使用するかどうかなどです。同様に、ブートストラップボリュームや SAP インストールなどの設定タスクに AWS Systems Manager または Ansible を使用することにしたかもしれません。このような決定事項は文書に記録しておきます。さらに、サードパーティーのモニタリングおよびオブザーバビリティダッシュボードの要件があるが、SoW では配信可能ではない場合は、その間に Amazon CloudWatch と Amazon Simple Notification Service (Amazon SNS) を使用してモニタリングおよびログ記録フックを配置することを検討してください。インハウスのクラウドチームは、サードパーティーのモニタリングソリューションの統合を後から実行することができます。

エンゲージメントモデルまたはサポート契約も RACI マトリックスの一部であり、SoW で明記されている必要があります。 AWS サービスを使用すると、かなりのレベルの自動化を実現できます。SoW と RACI マトリックスは、グリーンフィールド SAP 実装プロジェクトの一環として達成する必要があるものと、運用チームに委任できるものを特定する必要があります。

エンゲージメントモデルを確立するときは、ウォーターフォール、アジャイル、または混合アプローチが前進するための主要な方法かどうかを判断する必要があります。 AWS Professional Services では、ウォーターフォールアプローチと比較して、アジャイルまたは混合アプローチを実装したエンゲージメントの計画時間が 300% 増加し、94% 短縮されました。計画段階では、顧客の助けを借りてコミュニケーション計画とツールアプローチを選択する必要があります。次の表は、コミュニケーションプランの例を示しています。

最後に、プロジェクトを早期にサポートする顧客と SAP Basis チームを特定してください。新しいソリューションを実装して移行するときにトレーニングすることは、ナレッジ転送セッションを早期に開始するための鍵です。

クラウドの構築およびデプロイのプロセスを記録する

自社の IT 組織にインハウスのクラウドチームがあるときは、そのチームがフロー図 (ダイアグラム) を使ってクラウドの構築とデプロイのプロセスを記録し、チーム全体にこの図を配布します。主要な利害関係者が、プロセス内の障害や非効率な要素をすぐに特定し、既存の内部プロセスが、非効率性や遅延の発生に関してどのような役割を果たしているのかを把握できるようにします。以下の例では、Active Directory の参加 (join) とドメインネームシステム (DNS) の更新 (update) のプロセスに、完了まで最も長い時間がかかっていることがわかります。このようなビジュアルがあれば、プロセス内の特定のステップにかかる時間をどうすれば短縮できるかといった問題を、チームが協力して解決する際のモチベーションになります。

考慮事項:

• ヘルプデスクのプロセスとワークフローとを分けて記録し、この情報をインフラストラクチャチームに配布して、1 人の担当者に頼らなくても済むよう、全員がヘルプデスクツールにアクセスできるようにします。Active Directory の参加、DNS の更新、ファイアウォールの開放、暗号化キーのリクエストを行う場合、複雑で時間のかかるチケットプロセスが発生することがよくあります。プロジェクトの計画段階で、これらのプロセスを記録し、各チームのサービスレベルアグリーメント (SLA) を検討することが重要です。これは、削除する際に特に注意が必要な、遅延や障害の理由を説明するときにも役立ちます。

• Active Directory とファイアウォール、またはネットワークタスクに、指定された連絡先を割り当てます。これらの専用リソースは、プロジェクトに含める必要があります。サービスチケットに頼らねばならない場合は、サービス SLA を管理することはできません。

プロジェクトロードマップとマイルストーントラッカー

次のグラフは、複数年にわたる SAP on AWS グリーンフィールドプロジェクトのロードマップの例を示しています。

次の図は、同じプロジェクトの AWS プロフェッショナルサービスを使用したエンゲージメントタイムラインの例を示しています。

次の図は、このプロジェクトの本番稼働用マイルストーントラッカーを示しています。