※本記事は、Neil Ramsayによる”Phasing Your Journey to Cloud“を翻訳したものです。
通常、大規模な組織や複雑な組織は、クラウドへの移行を2つ以上のステップに分けて実装します。目的は次のとおりです。
- 実装の複雑さを軽減し、その結果リスクを抑えます。
- 得られた教訓をその後のロールアウトに反映できるようにします。
- スケジュール設定と金銭的コミットメントの両方において柔軟性を提供します。
- Oracle Cloudのメリットを早期に享受できるようにします。
- ユーザーおよび実装チームに十分な時間的(能力的・労力的)余地があることを確認します。
Oracleではクラウド実装全体について、パイロットと後続のロールアウトという2つのフェーズを考慮します。
パイロット実装
パイロット実装は、子会社またはビジネスユニットにおける最初のOracle Cloudアプリケーションの導入です。企業標準を確立して共有参照データを定義し、共通の統合/拡張を開発します。後続のロールアウトでは、パイロット実装の多くの要素が再利用されます。
グローバルなビジネスプラクティス
パイロット実装は、企業のビジネス慣行を改善し促進する機会を提供します。ビジネスプロセスの標準化は、データ品質の向上と解釈のしやすさを向上させることで、企業の可視性と統制を強化します。また、シェアードサービスを導入するための基礎も築くことができます。
レガシープロセス、特にカスタマイズされたものをクラウドへリフト・アンド・シフトする誘惑に負けないようにしましょう。その代わり、従来の手順が根本的なビジネス要件にどのように対処するかを慎重に検討してください。
例えば、既存の手順の多くが不要になったり、従来の制限を回避したり、ほとんど使用されないことが分かるかもしれません。クラウドERPの構成およびパーソナライズ機能をできるかぎり最大限に活用してください。
Oracle Cloud構成は安全にアップグレードできるため、ベスト・プラクティスを採用すると大きなメリットが得られます。アップグレードのコストとリスクに制約されることはなくなります。
ただし、現地の規制により、グローバルな企業基準に対する限定的な例外が必要になる場合があることにご留意ください。例えば、一部の国では、請求書は時系列、かつ欠番なしで並べる必要があります。この要件へ準拠することは、ビジネスの観点からは負担が大きいです。したがって、欠番なし連番は、必要とする国に対してのみ構成することをお薦めします。
該当する企業のビジネス慣行、および手順を文書化することをお薦めします。後続のロールアウトで例外を評価し承認する手順を確立してください。
企業体系および参照データ
企業の商習慣をサポートするために、パイロット実装では、子会社と事業部門間で共有される企業体系および参照データを定義します。
例えば、各元帳またはビジネスユニットで再利用する予定の企業の勘定体系(COA)やその他の設定などです。参照データを共有することで、メンテナンスの削減、不一致の最小化、統合の加速化、企業のレポート作成の容易さを実現します。
パイロット実装の範囲は限られていますが、意思決定がグローバルに与える影響を考慮する必要があります。次に例を示します。
- 企業のCOAはすべての地域および事業部門に適していますか?
- 元帳設計では、規制の厳しい国のセカンダリ元帳を許容していますか？
- すべての地域にわたって企業通貨で報告するための要件は何ですか？
- 支払方法は、グローバル、地域別、またはローカル別のいずれで定義するべきですか？
- その他
ここでも、各国の例外を考慮したグローバルな設計を定義して文書化することをお勧めします。例えば、ヨーロッパの一部の国では、特定の勘定体系を使用して財務諸表で提出するために、現地に登録された法的エンティティを必要としています。これらの国のために補助元帳レベルのセカンダリ元帳を用意することも選択肢の１つです。
企業体系のベストプラクティスとピラー間の依存関係について検討します。My Oracle Support (MOS)で入手可能なホワイト・ペーパー「Cloud ERP Enterprise Structures White Paper (Doc ID 2415848.1)」では、企業体系のベスト・プラクティスがまとめられ、ピラー間の依存関係が明らかにされています。
例えば、Cloud HCMをCloud Financial Managementの前に実装する場合、またはその逆の場合の考慮事項について、詳しく説明されています。また、企業体系のベスト・プラクティスについてもERP ACEのブログ投稿で紹介されています。
エンドユーザーの参加
パイロット実装の初期段階で、エンドユーザーを関与させることをお薦めします。エンドユーザーの参加により、基盤となるビジネス要件が正しく理解され、提案されたソリューションがそれらに対応できるようになります。
参加することで、設計上の決定事項の理解と納得感が高まります。ユーザー受け入れテスト(UAT)の前に包括的な意見を求められなかった場合、ソリューションが最適化されず、ユーザーがクラウドを採用することをためらうリスクがあります。
システム・インテグレーションと拡張
パイロット実装をサポートするために構築されたインテグレーションおよび拡張は、再利用したり、後続のロールアウトの基礎としたりすることができます。企業全体でインテグレーションと拡張を再利用できるかどうかは、共有参照データと共通のビジネスプラクティスに依存します。
この場合も、後続のロールアウトで発生する要件を予測してください。例えば、インテグレーションと拡張の変換と検証ロジックを分離します。
データ移行
子会社は、多くの場合、同じレガシーERPを使用しています。パイロット実装のデータ移行で得た教訓やツールは、後続のロールアウトにも適用されます。
一部の子会社で異なるERPソリューションが使用されている場合でも、パイロット実装の知見を活用することができます。データ移行ロジックを検証ロジックから分離します。検証ロジックの多くは、後続のロールアウトで再利用することができます。
トレーニングとサポート
エンドユーザーとサポートデスクへのトレーニングを準備し、後続のロールアウトでそちらを再利用することができます。地域の例外や言語に対応する必要があることに注意してください。
パイロット・エンティティの選択
最初の子会社またはビジネス・ユニット(あるいはその両方)の選択に影響を与える要因には、以下のものがあります。
- 緊急を要する課題やその他のITインフラストラクチャの圧力。例えば、企業のITシステムやポリシーをまだ採用していない最近の買収企業が、パイロット・エンティティとして選択されることがあります。
- ユーザー数。ユーザーが少ないとトレーニングが簡素化され、稼働開始後の問題への対応がしやすくなります。
- トランザクション量。ボリュームが少ないと俊敏性が向上し、実装やデータ移行の課題に対応できるようになります。
- 組織のビジネスプロセスの企業全体への適用性。非典型的なビジネスユニットや子会社を選択してしまうと、パイロット版の標準を他の事業部に適用できなくなります。
- エグゼクティブ・スポンサーシップ。権限とコミットのあるエグゼクティブ・スポンサーがいるかどうかが鍵となります。
- 複雑な規制制度。そのような国は、準備する時間を確保するために、後のロールアウトに割り当てます。
Neil Ramsay
クラウドERP開発担当シニアディレクター
E-Business Suiteまでさかのぼり、30年にわたるOracle ERPアプリケーションの経験を持ちます。製品戦略に参加する前は、OracleのRedwood Shoresキャンパスでアプリケーション開発担当のシニアディレクターを務めていました。ACE ERPチームのメンバーとして、戦略的なお客様のクラウドトランスフォーメーション ジャーニーに協力しています。現在、スペインのマドリッドを拠点に活動しています。
–関連投稿–