大事故の元凶「ERPのアドオン開発」は避けろ──では、どうすれば？：ファイナンス組織「3つのジレンマ」とデジタル活用

[山岡正房，ITmedia]

連載：ファイナンス組織「3つのジレンマ」とデジタル活用

　現在のファイナンス組織は、前例のない環境変化と不確実性の渦中で、3つのジレンマを抱えている。1つ目は、人材不足で従来業務の遂行すら難しい中で、ビジネス・パートナーとしての役割高度化にも並行して取り組まなければならないこと。2つ目は、既存事業の深化と新規事業の探索、あるいは求心力と遠心力といった背反するテーマを扱わなければならないこと。3つ目は、短期的な株主価値を求めるアクティビストと対峙する一方で、マルチ・ステークホルダー経営を推進しなければならないことである。

図表はEYストラテジー・アンド・コンサルティング作成、以下同

　本連載では、これらのジレンマの解消に向けて、最新のデジタル技術をどのように活用すべきかを解説する。第3回となる今回は、再びデジタルに焦点を当て、レジリエントなオペレーションモデルを支えるための、疎結合なシステム・アーキテクチャおよびデジタル活用の要諦について論じたい。

ERPのアドオン開発は「システム負債」

　「ERPシステムへのアドオン開発は避けるべき」「Fit to Standardの考え方で、業務にシステムを合わせるのではなく、システムの標準プロセス、標準機能に業務を合わせるべき」──こうした考え方は20年以上繰り返し言われ続けている。

　また、前回記事「システム導入で起きる“深刻な部門対立”どう解決？　あの部署の効率化で、こっちの部署から不満噴出」で述べたように、プロセスオーナーが中心となって、経営環境・事業環境の変化に合わせてしなやかに、エンドツーエンドプロセスを間断なく見直していくためには、それを支えるシステムも柔軟性・拡張性を担保しておく必要がある。その際、アドオンプログラムは大きな足かせとなる。システム資産ではなくシステム負債と言っても過言ではない。

　ただ現実としては、事業固有、会社特有の業務要件がある中で、全ての業務をERPシステムの仕様に合わせることは難しく、アドオン開発が避けられない局面もあった。特に単一のERPシステムの中に全てのシステム機能を密結合な形で実現する、以前のモノシリックな（一枚岩の）システム・アーキテクチャにおいては、この傾向が顕著であった。

疎結合なシステム・アーキテクチャの可能性

　時代が下り、現在のシステム・アーキテクチャは疎結合型のものが主流になりつつある。このアーキテクチャでは、システムは3層に大別される（図1）。

（図1）疎結合型のシステム・アーキテクチャは大きく3層に分けられる

　1つ目は業務システム層。これは会計システムやERPシステムなど、SoR（System of Record）と呼ばれるシステム群を含む層で、業務要件が頻繁に変更されることはなく、それよりも確実性や堅牢性が重視される領域である。またその性質から、導入アプローチとしてはウオーターフォール型が適している。

　2つ目は個別サービスシステム層。例えば請求書発行ツールや入金消込ツールなどの個別業務に特化したシステム・ソリューションや、AI-OCRなどの個別機能、RPAなどのEUC（End User Computing）ツールを指す。これらのツールはローコード、ノーコードで導入できるものも多く、変化の大きい要件に対してPoCを通じてアジャイル型で導入するアプローチが採択されることが多い。

　3つ目はデカップリング層。これは1つ目の業務システム層と2つ目の個別サービスシステム層が独立性を保ちながら、業務プロセスやデータの観点で疎結合の状態で連携させる層である。

2つの失敗ケース

（提供：ゲッティイメージズ）

　こうした疎結合なシステム・アーキテクチャを理解すると、これまで生じてきた2つの失敗ケースの原因が見えてくる。

　1つ目の失敗ケースは、ERPシステムへのアドオン開発である。前述の通り、要件の変化が少なく、また確実性や堅牢性が求められる業務システムは、ウオーターフォール型で導入プロジェクトが遂行される。一方で、ERPではカバーできない業務要件は、さまざまな環境変化によって業務要件自体も頻繁に変化することが多い。

　従ってこうした業務要件は、ERPの外側の個別機能として、アジャイル型で導入すべきである。しかしながらモノシリックなシステム・アーキテクチャを引きずったままだと、こうした固有機能をERPにアドオンしてしまう。つまり、本来アジャイル型で対応すべき要件を、ウオーターフォール型のプロジェクトで無理やり吸収してしまうことになり、結果として柔軟性や拡張性の乏しいシステムを構築してしまったという失敗が多かった。

　もう1つの失敗ケースは、RPAが流行した際に多く見られた。ERPへのアドオンは避けたい一方で、ERPの標準機能では業務要件を充足できない部分がある、そうした痒い所にERPの外側で手が届くRPAは、10年ほど前に日本でも爆発的に普及した。

　その反面、当時の多くの日本企業ではRPAに対するガバナンスが脆弱であったため、あまたの「野良RPA」が誕生することとなり、ERPシステムと野良RPAの間を業務プロセスが行ったり来たりすることが多かった。そしてRPA部分がブラックボックス化、属人化してしまい、結果として業務プロセスをエンドツーエンドで可視化できない、という事態を招いてしまった、というケースである。

　特に第2の失敗ケースを回避するために着目すべきなのが、（図1）のデカップリング層である。デカップリング層は大きく2つの観点に分けられ、１つ目はプロセス観点で疎結合な連携を実現するBPMS（Business Process Management System）、2つ目はデータ観点で疎結合な連携を実現するETL（Extract/Transform/Load）とMDM（Master Data Management）である。

　前回記事で詳説したプロセス・オーナーは、前者のBPMSの主管者としてBPMS上でエンドツーエンドプロセスを俯瞰的にデザインし、メンテナンスする必要がある。また後者のデータ観点を含むデジタル・アーキテクチャ全体を十分に理解した上で、システム部門との連携も求められる。

レジリエントな業務システムを構築する勘所

　（図1）をプロセス・オーナーが主管者となるBPMSを主軸に表現し直したのが、（図2）である。この図上で、レジリエントなオペレーティングモデルを構築する上での、デジタル活用のポイントについて最後に言及したい。

（図2）プロセス・オーナーが主管者となるBPMSを主軸とした場合のシステム・アーキテクチャ

　1つ目のポイントは、BPMSの活用方法である。プロセス・オーナーが業務プロセスの設計をBPMS上で行うとともに、業務実行の際のシステム連携やユーザーインターフェースもBPMSで一元管理すること。また、新業務プロセスが稼働した後においても、プロセス・マイニングによる業務の可視化やモニタリング、およびプロセス課題の把握を通じて、状況変化に応じた柔軟なプロセス・メンテナンスをBPMS上で行うことが必要となる。

　2つ目のポイントは、ERPシステムやピンポイント・ソリューションなどを、BPMSを通じて疎結合な状態に保つことで、経営環境・事業環境の変化に際して、システム・ソリューションの組み合わせ変更で柔軟に対応できるようにすることである。

　3つ目のポイントは、頻繁に業務要件、システム要件が変化する事象については、無理に基幹システムにアドオンするのではなく、かといって「使いにくい」を我慢するのでもなく、AIなどの最新のデジタル・テクノロジーも含め、特定要件に対応できる専門ソリューションを適宜選択・採用することである。

　最後の4つ目のポイントは、ERPへのアドオンは極力回避し、クリーンコアの状態を保つことである。これによりバージョンアップ機能などをスムーズに享受できる上、アドオンプログラムが柔軟なプロセス変更の阻害要因になる事態も回避できる。また、クラウド移行による構築・保守費用の削減も期待できる。

　レジリエントなオペレーションモデルを構築・維持していくためには、プロセス・オーナーとIT主管部門がこのような共通理解を醸成の上、組織の文化として根付かせることが重要であると言える。

　今回はレジリエントなオペレーティングモデルを支えるシステムを、デジタル・アーキテクチャの観点から論述した。最終回となる次回は、デジタル技術の中でも、近年注目が高まっているAIについて焦点を絞り、ファイナンス業務でどのように活用すべきかについて論述する。

著者紹介：山岡正房

EYストラテジー・アンド・コンサルティング株式会社ファイナンスパートナー

2014年に入社後、クライアント企業のCFO部門向けに制度対応から業務プロセス改革、組織体制の見直し、グループ経営管理の強化、デジタルの活用など、さまざまな変革支援をリード。近年はファイナンスDXおよびトレジャリー領域にフォーカスし、関連プロジェクトの責任者を務めると共に、新たなコンセプトやソリューションの開発に取り組む。