※本記事は、Neil Ramsayによる”Phasing Your Journey to Cloud“を翻訳したものです。
Oracleではクラウド実装全体について、パイロットと後続のロールアウトという2つのフェーズを考慮します。
前編はこちら
パイロットの実装手順
パイロット実装では、後続のロールアウトよりも多くの時間とリソースが必要とされます。これは本稼働が開始される時期が異なる個別のステップに分割することが一般的です。
一時的なインテグレーションを構築しないようにするには、相互に関連性の高いビジネスプロセスを1つのステップで実装します。例えば、調達、請求書処理および支払は、調達から支払までのフロー内で相互に関連しています。したがって、通常は同時に実装されます。Cloud Procurementを実装せずに、POマッチング請求書フローが実装されることはほとんどありません。
一般的なアプリケーションのグループ分けは、以下のものがあります。
- 一般会計。オプションで、Financial Close (FCCS)、Enterprise Data Management (EDMCS)、Profitability and Cost Management (PBMCS)などのEnterprise Performance Management (EPM)アプリケーションを拡張することができます。
- 調達。オプションで、経費、ソーシングまたは調達契約を拡張できます。
- 資産
- 外部請求システムと統合された売掛/未収金およびAdvanced Collections。
- 受注から入金まで。必要に応じて、Subscription ManagementまたはRevenue Management (RMCS)を拡張できます。
- Supply Chain Management (SCM)
- 製造
- Human Capital Management (HCM)
- プロジェクト管理、および調達と財務管理の関連機能
- Account Reconciliation (ARCS)
- Accounting Hub (AHCS)
上記のグループ分けによって、必ずしも実装順序が決まるとはかぎりません。HCMは財務管理の前後に実装することが一般的ですが、パラレルで実装されることはほとんどありません。
複数の個別のビジネスプロセスでOracle Cloud機能を使用できるため、異なるタイミングで本番稼働を開始できます。例えば、Cloud Procurementでは、直接購買と間接購買の両方がサポートされています。両社はサプライヤや購買ポリシーを共有することはほとんどないため、別々の実装フェーズに分けられます。
パイロットの実装手順の順序
ビジネスプロセスをクラウドに移行する順序は、依存関係や労力を最小限に抑えることでも決まります。その他の要因には、短期で成果を上げたいという要望や、緊急を要する課題を置き換える必要があることなどがあります。
一般会計は、一般的には最初の実装プロジェクトとなります。なぜなら仕訳データ構造は顧客やサプライヤの請求書とは異なり、ソースシステム間で類似しているからです。Oracle General Ledgerの仕訳、および残高をBI Cloud Connect(BICC)を使用して企業GLおよびレポートプラットフォームに抽出するのは簡単です。
間接購買から支払いまでのフローが次に来ることがよくあります。業界によっては、プロジェクト管理および資産が一緒に実装される場合があります。コミュニケーションと銀行取引明細書の照合を容易にするため、直接購買のための支払いが含まれることがよくあります。
レガシーERPからOracle Cloudへの移行の簡素化サンプル
最初の実装ステップで、次の手順を実行します。
- レガシーERP補助元帳(買掛管理など)で計上し、仕訳をCloud General Ledgerに統合します。従来の勘定体系(COA)を変換するために非常に複雑な変換が必要な場合は、Accounting Hub Cloud Service(AHCS)を検討できます。
- 上流のアプリケーションから流入する仕訳をレガシー総勘定元帳からクラウド総勘定元帳に出力先を変更します。必要に応じて、これらの移行を別々のプロジェクトにずらして行うことができます。
- 外部フィードの出力先がCloud General Ledgerに変更されることで、その外部フィードは当該エンティティの総勘定元帳のレコードになります。
- ユーザーは、クラウドERPの総勘定元帳および財務レポート機能を利用できます。
- すべての手動仕訳、配賦およびその他の財務処理が一般会計で実行されます。
2番目の実装ステップで、次の手順を実行します。
- クラウドERPで最初のエンドツーエンドの補助元帳ビジネスプロセスを実装します。例えば、調達から支払までです。
- レガシー総勘定元帳から流れてくるフィードを廃止します。
3番目の実装ステップでは、次の手順を実行します。
- 残りの補助元帳ビジネスプロセスをCloud ERPに実装します。
- レガシーERPを廃止します。
ビジネスプロセスおよびアプリケーションがクラウドに移行される順序は、クラウドアプリケーションのフットプリント、業界、トランザクション量および内部の優先順位によって大きく異なります。
Enterprise Performance Management (EPM)
EPMは、連結、財務レポート、計画、予算編成など、一元化されたビジネス機能に対応しています。EPMは、レガシーERPおよび子会社のERPから残高を取り込み、COAおよびカレンダのマッピングを実行するように最適化されています。したがって、EPMアプリケーションは、クラウドへの移行期間中にレガシーERPとクラウドERPの間で一貫した集中処理およびレポート作成プラットフォームを提供するのに適しています。
後続のロールアウト
パイロットの実装中に多くの基礎作業が準備されているため、後続のロールアウトでは少ない時間と労力で済むはずです。パイロット実装ステップは、後続のロールアウトに着手する前に、かなりの機能範囲のステップを確立させます。
外部アプリケーションとの一時的なインテグレーションが少なくて済みます。例えば、一般会計が子会社のレコードのGLになると、レガシーGLからのアウトバウンドインテグレーションを廃止することができます。また、パイロット実装での機能範囲が広いということは、本番稼働開始に関連するビジネスの混乱が少なくなることを意味します。
後続のロールアウトの典型的な範囲としては、すべてのERP、HRまたはSCM関連のビジネスプロセスがあります。
パイロット実装エンティティの選択と同様に、他の子会社や事業部門に導入を拡張する順序は多くの要因に依存します。
最後に、後続のロールアウトをサポートするために、別のシステム・インテグレータ(SI)を選択することがよくあります。パイロット実装の決定が適切に文書化されていることを確認してください。新規に参画するSIおよび影響を受けるユーザーコミュニティへの整然とした引継ぎを計画します。
継続的なイノベーション
複数の子会社およびビジネスユニットを持つ複雑な企業は、継続的に実装範囲を拡張していくことがよくあります。新規の買収は、企業のクラウドソリューションに組み込まれます。機能追加またはアプリケーションの追加により、機能範囲が拡張されます。
クラウドに内在する継続的なイノベーションには、新機能について評価や適用に向けて継続確認していくための恒久的なビジネスプロセスが必要です。そうすることによって、エンドユーザーが、自分の担当範囲に影響を与える機能拡張を認識できるようにします。
詳細は、ERP ACEのブログ「Harness the Business Value of Quarterly Updates (四半期アップデートでビジネス価値を高める)」を参照してください。
結論
大規模または複雑な組織では、クラウド実装を複数の実装ステップに分割するべきという確固たる理由があります。パイロット実装で後続のロールアウトで遭遇する主要な要件を予期することで、最も大きな利点を得ることができます。
Neil Ramsay
クラウドERP開発担当シニアディレクター
E-Business Suiteまでさかのぼり、30年にわたるOracle ERPアプリケーションの経験を持ちます。製品戦略に参加する前は、OracleのRedwood Shoresキャンパスでアプリケーション開発担当のシニアディレクターを務めていました。ACE ERPチームのメンバーとして、戦略的なお客様のクラウドトランスフォーメーション ジャーニーに協力しています。現在、スペインのマドリッドを拠点に活動しています。
–関連投稿–