SAP の世界では、誰もがよく話すよく知られた恐怖があります。それは、1 つの変更で生産システムが壊れるかもしれないという恐怖です。しかし、この懸念の背後には、別の個人的な恐怖があります。それは、変更がその管理や実装を担当する個人に悪影響を与えるかもしれないという心配です。
したがって、変更管理には、技術的な要素と組織的な要素（人への影響）という二重の性質があります。この二重性は、S/4HANA への移行時に重要になります。成功は、両方の側面を管理することにかかっています。つまり、システムが機能することを保証しながら、新しい働き方に人々を準備させるということです。
このブログでは、アップグレードにブラウンフィールド、グリーンフィールド、ハイブリッドのどのアプローチを選択するかに関係なく、S/4HANA 移行における変更管理の重要性について説明します。
S/4HANA、単なるアップグレードですか?
An S/4HANA移行 技術的には「単なる別の」アップグレードです。しかし同時に、以前の SAP アップグレードよりもはるかに複雑です。
これは、さまざまなレベルが関係する複雑なプロジェクトです。移行は、インメモリ データベースをサポートする新しいハードウェアの候補から始まり、ビジネス機能を評価し、カスタム コードが S/4HANA と互換性があることを確認します。
SAP カーネルの潜在的な変更は重大です。多くの場合、既存のレガシー ECC コードをそのまま実行することは不可能です。さらに、SAP はクラウド サービスへの移行を推奨しており、ハイブリッド ランドスケープがより一般的になり、S/4HANA の移行がさらに複雑になる可能性があります。
その結果、プロジェクト開始から稼働開始まで 2 年かかる長期にわたる移行プロジェクトが一般的になります。この期間中、組織は停止せず、日常業務が継続されます。本番環境でのサポート パッケージなど、その他の SAP アプリケーション ライフサイクル イベントも並行して処理する必要があり、従来の ECC システムで新機能の作業を停止することは不可能です。
移行には、技術運用とビジネス運用の両方を同時に慎重に計画し、管理することが必要です。
SAPの変更を合理化
変更管理は、技術的な変更と組織的な変更という 2 つの要素を組み合わせたものです。ここでは技術的な変更に焦点を当てますが、組織的な要素の重要性を過小評価することはできず、両者を別々に扱うことはできません。
S/4HANA に移行する際には、次の点を考慮する必要があります。
- 変更プロセス
- 変更プロセスを監視する方法
- 技術チームへの継続的な指導と監督
- 可能な限り自動化
- 上級管理職の全面的なサポートがあるかどうか
明確に定義された変更プロセスは重要です。万能のアプローチは存在しないことを覚えておくことが重要です。変更ワークフローは組織の状況に固有のものですが、次のプロセスと要件が含まれる場合があります。
- 承認プロセス
- S/4HANA DEVシステムのすべての開発者は、変更をテストのためにQAに迅速に移動（転送）できる必要があります。
- リリース管理を実装する
- メンテナンス ランドスケープのすべてのビジネス要件、変更、修正がプロジェクト ランドスケープでも考慮されるようにする (レトロフィット)
- 効果的なプロセス導入を可能にするユーザーフレンドリーなツールで自動化
- 対応する変更チケットなしでの移動や変更ができないことを確認してください（したがって、必須です）。
これが 完全なリストではありませんが、計画段階の開始時に特定のプロセスを考慮しないと、スムーズな S/4HANA 移行が妨げられる可能性があります。
a. 組み込む
通常は開発システムから始まる並列 S/4HANA ランドスケープの構築の最初からレトロフィットを実装することが重要です。レトロフィット (またはリクエストのクローン作成) により、メンテナンス ランドスケープ (古い ECC 開発から本番サポート ランドスケープ) のすべての変更が新しい S/4HANA 環境でも考慮されるようになります。
変更をレトロフィットする場合、技術的なオブジェクトではなく要件を実装することが重要です。S/4HANA では、変更する必要がある技術的なオブジェクトはまったく異なる可能性がありますが、要件はそのまま残り、対処する必要があります。
私の 20 年以上の経験から、ランドスケープの同期をリアルタイムで実行することが最善です。新しい変更が本番環境に到達したら、理想的には同じ開発者/カスタマイザーによって、並列の S/4HANA DEV システムに再実装する必要があります。
なぜ同じ人々を巻き込むのでしょうか? なぜなら、変更がなぜ必要だったのか、どのように実行されたのかを最もよく知っているのは彼らだからです。 なぜリアルタイムなのか? 要件とその実装の詳細がまだ記憶に新しいからです。
b. ツール選択
私たちはアジャイルな世界に生きています。アジャイルではないと主張する組織でさえ、日々のより迅速な変更の要求に対処しなければなりません。ツールセットを選択するときは、新しい要件に適応できるほど柔軟で、実績のある SAP 経験を持つベンダーによってサポートされ、チームが簡単に習得して使用できるツールセットを探してください。
– 柔軟性 – たとえば、ワークフローの変更を実施する 何百日も外部コンサルタントを雇う必要はない
– 接続性と自動化 – ツールは、ツール環境全体にわたってシームレスな統合と自動化を可能にするために、柔軟で簡単に構成できるインターフェースを提供する必要があります。
– 実績のあるテクノロジーとベンダー – 実際のSAPシナリオで信頼性が高く、テストされ、成功していることが証明されているテクノロジーとベンダーを選択します。
– になると 変更の自動化では、選択したツールがその使用を強制できる必要があります。SAPの用語では、特定の要件に割り当てられない限り、トランスポートは実行されません。
c. プロセス定義
プロセスについて熟考することは不可欠ですが、できるだけ早く始めることがさらに重要です。実装を開始し、必要に応じて途中で調整します。従来のウォーターフォールアプローチはもはや効果的ではありません。計画は重要ですが、 数か月かかるべきではありません。代わりにサイクルを短縮し、 利用可能なものを活用して、プロセスを成熟させ、時間の経過とともに改善できるようにします。
2. 変更プロセスの監視
KPI を定義し、プロジェクト期間中に監視します。トランスポート/変更リクエスト、メンテナンス変更のリードタイムと改修時間、開発者ごとのオープン リクエスト、リクエスト タイプに関する統計などの KPI は、プロセスがどのように機能しているかに関する貴重な洞察を提供します。
さらに、ユーザーからのフィードバックを収集します。関係者と定期的に（たとえば毎月）会議を開き、KPI を確認して継続的な改善のための実用的なアイデアを提案します。
3. エンドユーザーへの継続的な指導
KPI を監視し、ユーザーからのフィードバックを積極的に聞くことで、変更管理者はツールの効率とユーザー導入を高める機会を特定できます。理解を深め、的を絞ったトレーニングを行うことで、導入に対する抵抗を克服し、スムーズな移行をサポートできます。
4. 可能な限り自動化する
自動化と統合により、作業がより簡単かつ効率的になります。複数のチケット ツールやスプレッドシートで情報を重複させる代わりに、統合ツールを使用してタスクを自動的に処理できます。これにより、時間が節約され、エラーが発生しやすい手動の変更タスクが排除され、チームはより重要な活動に集中できるようになり、生産性と品質が向上します。
5. トップレベルの経営サポート
S/4HANA への移行を検討する場合、(技術的な) 変更管理の自動化に対するトップレベルの管理サポートが重要です。これにより、組織の調整、リソースの割り当て、明確な方向性が確保されます。これがないと、重要なプロセスが停滞し、移行の成功と変更を効果的に管理する能力に影響する可能性があります。
