このレッスンでは、SAP S/4HANA オンプレミス導入の詳細について説明します。これは、既存の顧客ベースでの導入プロジェクトの最も一般的な例です。また、すでに SAP ERP を実行している顧客の場合、最初の質問は、新規導入とシステム変換です。
SAP Readiness Check では、最も影響を受ける領域を特定することができ、新規導入のメリットと比較して変換のコストを見積もるのに役立つ場合があります。
SAP Readiness Check for SAP S/4HANA では、以下のような概要レベルの発見事項に焦点を当てています。
シンプル化項目関連
カスタムコード
推奨される SAP Fiori アプリ
SAP S/4HANA サイジング
アドオン互換性
ビジネス機能
SAP S/4HANA などの製品に対して SAP オンプレミス実装を実行する場合、さまざまな移行パスがあります (詳細については、第 5 章を参照してください)。可能な移行の中に、グリーンフィールド（新規）導入とシステム変換があります。
システム変換は、開発およびコードレビューアクティビティが基本的な役割を果たす例の 1 つであり、組織内の SAP システムの履歴が古いほど、より関連性が高くなります。
この例について考えてみてください。SAP ERP ソリューションがまだ SAP R/3 と呼ばれていた90年代半ばに、ERP の導入を開始しました。後で SAP ERP にアップグレードし、システムを SAP S/4HANA に変換しています。ここには約 30 年の開発履歴があり、現在見られる機能は 30 年前とはかなり異なることを考慮してください。多くのプロセスが存在しないか、組織のニーズに対して十分な範囲が提供されていませんでした。SAP ソリューションは時間の経過とともに成熟しました。この 30 年間に主要なコードオーバーリングが実行されなかった場合、システム変換プロジェクトの最も重要なタスクの 1 つがカスタムコードに関連していることがわかります。カスタムコードの影響を評価し、その品質にアクセスし、無効なコードを段階的に廃止し、可能な場合は非標準コードを標準機能に置き換える必要があります。
これまで、カスタムコードのレビューの重要性は、評価フェーズから始まり、保持、非推奨化、または削除の量を把握し、実現化フェーズで後で調整を実行することで、長く集中的なタスクを持つことができます。図で、CC: カスタム品質タスクを確認します。
過去 30 年間の SAP の歴史に精通している人にとっては、大きな変更が行われた例を簡単に見つけることができます。たとえば、不動産や財務/資金管理などが考えられます。人事管理であっても、以前の SAP R/3 エディションで提供されていたものとはまったく異なります。
現状分析：本稼動 SAP ECC でカスタムコードの状況を完全に透明化します。
未使用のカスタムコードの廃止: 使用されていないカスタムコードを廃止します。このアクティビティは、システム変換前、変換時に長時間開始される場合があり、その後続行する必要があります。
可能な場合は標準に戻す：カスタムコードを SAP またはパートナーコードに置き換えてみてください。これは、モディフィケーション、クローンなど、およびシンプル化の影響を受けるカスタムコード領域に当てはまります。
SAP S/4HANA に合わせたカスタムコードの調整（再設計/再プラットフォーム）：既存の多くのカスタムコードオブジェクトは、調整なしで SAP S/4HANA 上で実行されます。ただし、一部のコードオブジェクトは調整する必要があります。(たとえば、'クイックフィックス' を使用)、一部は SAP S/4HANA の拡張性コンセプト (アプリ内、並列) に従って調整する必要があります。
SAP S/4HANA の拡張コンセプトについて理解します。アクセラレータセクションの 'Custom Extensions in SAP S/4HANA Implementations - A Practical Guide for Senior IT Leadership' 文書を参照してください。
カスタムコード移行のトピックについても理解します。SAP では、以下の情報ソースをお奨めします。
SAP ブログ "SAP S/4HANA System Conversion – Custom code adaptation process"、"Semi-automatic custom code adaptation after SAP S/4HANA system conversion"、および "FAQ document on custom code adaptation" から開始する必要があります。
このトピックのもう 1 つの適切な開始ポイントは、SAP ホワイトペーパー 'Custom Extensions in SAP S/4HANA Implementations' に記載されています。このホワイトペーパーでは、最新のエンタープライズアプリケーションの拡張性に不可欠なコンセプトについて説明し、システム変換時にカスタムコードを処理する主な側面をガイドします。また、SAP S/4HANA の新規導入を実行したり、新しい SAP テクノロジーを起動したりする顧客向けの実践的なアドバイスを提供します。
もう 1 つの適切な概要文書 (多数のリンクを含む) は、'SAP S/4HANA 変換中のカスタムコード管理' です。
オンプレミスシステムで存在感の大きいもう 1 つのワークストリームは、運用とサポートです。古い SAP ERP システムから変換するだけであっても、新しいソリューションに移行すると、新しい課題が生じ、新しいスキルが必要になります。この例では、SAP ERP は SAP ASE データベースで実行されており、開発者は ABAP WebDynpro テクノロジーを使用していました。SAP S/4HANA に移行すると、SAP HANA および SAP Fiori をサポートおよびトラブルシューティングするための新しいテクノロジーが提供されます。コードがデータベースに移動され、OData サービスが Web サービスと並列表示されます。1 つの重要なタスクは、操作への影響へのアクセスに関連します。
運用影響評価アクティビティ中に、SAP S/4HANA プロジェクト範囲が分析され、本稼働開始前に調査して修正または導入する必要がある、サポートフレームワーク内の潜在的な運用リスクおよび領域が評価されます。この目的は、以下の業務活動の一覧を定義することです。
新たに設定する必要があります。たとえば、SAP Fiori アプリが新たに導入された場合は、フロントエンドサーバの管理と運用を定義し、設定を行い、関連するシステムとその設定についてリソースをトレーニングする必要があります。さらに、インシデント管理などのサポートプロセスで、新しいコンポーネントを処理できる必要があります。
存在しますが、変更する必要があります。たとえば、日次バックアップルーチンは、新しい SAP S/4HANA ソリューションに適切に適合するように調整する必要があります。監視、トラブルシューティング、ソフトウェアロジスティクスツールなどのサポートツールを導入する必要があります。マスタデータ管理などのプロセスは、マスタデータ構造の主要な変更によって必要とされる新しい保険契約を定義するために再検討する必要があります。
廃止することができます。たとえば、任意の DB の DB ルーチンおよびスクリプトは廃止することができます。任意の DB 監視設定も廃止する必要があります。
関連するすべてのサポート領域を包括的に分析する必要があります。これにより、SAP S/4HANA ソリューションのサポート、プロセスと手順、運用文書、および有効化サポートツールに必要なすべてのロールとスキルが分析されます。
SAP は、運用アクティビティに対する体系的なアプローチにより、これらすべてのアクティビティをサポートすることができます。これにより、新しいソリューションに起因する IT 運用アクティビティのすべての変更を分析することができます。
影響を受けるサポート領域が体系的に分析されると、ギャップを埋め、将来の IT サポートフレームワークを準備するための IT の主要アクティビティを含むロードマップが定義されます。必要な主なアクティビティは多数あり、以下が含まれます。
新しい役割のソーシング方針を定義します。運用へのプロジェクトリソースの移動、新しいソリューションをサポートするための現在のリソースのランプアップ、採用、またはパートナーへの活動の引き渡し。
ツールの設定、及び SAP がサポートに従事する場所。
プロジェクトリソースまたは運用リソースによる運用手順の文書化。
将来の運用リソースに必要な知識とスキルを確保するための、ナレッジトランスファーの編成。これには、現在の運用リソースの正式な教育、トレーニング、新しいソリューションへの実践とシャドウイングが含まれます。また、サービスデスクなどの新しいソリューションのサポートに関与するすべての IT サポートリソースのトレーニングも含まれます。
運用カットオーバーアクティビティ (チームアクセス、未処理不具合のロールオーバーなど)。
現在のサポートフレームワークの一部の廃止。