ファイナンス業務の圧倒的な効率化を実現するプロセス・オーケストレーションとは
2021年10月21日
ERPの導入により会社全体のプロセス・データが統合管理されるはずだが、いまだアナログプロセスが残っている企業が多い。ERPの機能で対応しきれない機能をマクロやRPAで補う形でデジタル化が進んでいるものの、全体を通してみると効率化の効果は限定的である。
昨今注目されているNo-Code/Low-Code PlatformやiPaaSの活用を起点に、個々の業務プロセスやデータをEnd-to-endにデジタルでつなぐこと（プロセス・オーケストレーション）によって、圧倒的な工数削減を実現できる。
本稿では、Ridgelinez内での実践事例をもとに、プロセス・オーケストレーションのアプローチについて解説する。
ファイナンス業務に求められる圧倒的な業務効率化
事業環境が激しく変化する中で、企業は自己変革する能力が求められている。
ファイナンス組織は、事業環境の変化を感知し、経営資源を再配分できる経営管理の仕組みと体制を整え、これを実行していかなければいけない。
しかし、伝票処理／出納／固定資産登録といった大量定型処理や月次決算などの定常業務に追われているのが実態だ。
最近では、ファイナンス組織の要員の高齢化や減少の傾向が強まっており、定常業務の遂行自体に危機意識を持つCFOも少なくない。
このような状況において、企業の自己変革能力を支える経営管理にリソースを確保するためにはファイナンスプロセスの限定的な効率化にとどまることなく、プロセス全体を見直して労働集約的な定常業務を圧倒的に効率化することが、ファイナンス組織に求められている。
テクノロジー活用を起点としたプロセス・オーケストレーション
ファイナンス組織は、会社組織においても特に変革を求められ続けている組織と言える。
会計制度の変更（決算早期化／連結決算／内部統制／IFRS、等）や新たなテクノロジー（ERPパッケージ／連結パッケージ、等）の登場の都度、これに対応し、業務・システムの変革を行ってきた。
従来、紙ベースでの作業、スプレッドシートのやり取り、特定個人の頭の中にしか存在しない業務知識に頼るなど、労働集約的な業務が多く存在していたが、昨今では、大量処理が必要な業務、自動化可能な業務に、マクロ・RPA（Robotic Process Automation）・機能特化型SaaSを活用して一部のプロセスのデジタル化が進んできている。
このように変革を続けてきているファイナンス組織であるが、個々の業務プロセスがつながっておらず、その間では手作業、（二重）入力、印刷・押印などアナログプロセスがいまだに存在し、全体を通してみると、効率化の効果は限定的と言わざるを得ない。
最近では、(1)No-code/Low-code Platformや(2)iPaaS（Integration Platform as a Service）が注目されており、このようなテクノロジー活用を起点に、個々の業務プロセスやデータをEnd-to-endにデジタルでつなぐこと（プロセス・オーケストレーション）によって、圧倒的な工数削減を実現することができる。
(1)No-code/Low-code Platform
「手作業によるコーディングを最小限に抑え、SoE（Systems of Engagement）のための迅速なアプリケーション構築を可能にするプラットフォーム」と定義され、レゴのブロックのように予め用意されたプログラムを組み合わせることによって、短期間でアプリケーションを構築できる（図表1参照）
図表1 従来の開発とLow-code Platformによる開発の違い
(2)iPaaS（Integration Platform as a Service）とは
「異なるアプリケーション同士をつなげ、データの統合やシステムの連携を実現できるクラウドサービス」を指し、最小限のコーディングでシステム間連携を構築できる（図表2参照）
図表2 iPaaSのイメージ
ERPは魔法の杖ではないことを証明した3つの落とし穴
読者の中には、ERPによって会社全体のプロセス・データが統合管理されるはずだが、いまだアナログプロセスが残っていることに疑問を持たれる方も多いのではないだろうか。マクロ・RPAもERPの機能で対応しきれない隙間を埋めるツールとして重宝されている面もある。
まずはERPの3つの落とし穴について解説したい。
＜ERP3つの落とし穴とは＞
- 日本の商習慣や事業特性に非対応
機能改善が進んでいるとはいえ、海外発のERPパッケージを中心に、日本の会計制度や商習慣、事業特性にERPの機能が対応しきれていないことが多い。機能一覧のレベルでは問題なさそうに見えても、業務処理レベルまで落とし込んでいくとGAPが露になる。
一般的にグローバルスタンダードやベストプラクティスの名の下に、ERPの機能に業務を合わせることが推奨されてきた。確かにERPを基準に業務を見直すことによって過剰品質や非効率となっている業務を改善できるのも事実である。しかし、実務としては不十分な標準機能（例：請求書は出力できるが、表示項目／内容が不足（≒実務では使えない））をそのまま利用しようとするあまり、システム外での手作業を残してしまっているケースは多い。 - 使いづらいUI（User Interface）
これはERPの宿命とも言える部分であるが、ユーザー部門にとってわかりにくい項目や不必要な項目が画面に残ってしまう。
ERPパッケージは世界中のあらゆる業種業態に対応できる仕組みになっており、様々な機能や項目が具備されているのだが、裏を返せばユーザー部門にとって不必要な項目や機能がついてきてしまうことになる。結果、非常に使いづらいUIを現場に提供することになるため、利用頻度の低いユーザー部門からの問い合わせや入力ミスが多発する事態となる。ERP導入側も予めその事態を想定するため、ERP外でデータを作ってアップロードするといったオペレーションを構築しがちである。 - 全社最適の欠落
ERPが本来の価値を発揮するためには、全社最適の観点で構築できるかがカギになる。
ユーザー部門ごとに独自にERPパッケージやSaaSを採用している企業は多い。対象業務やユーザー部門が抱える課題によってFitするサービス・プロダクトが異なるため、その選定自体に問題はないのだが、ユーザー部門主導で導入を進めることによって、全社最適の観点が欠落してしまうことがある。
二重入力やデータの加工・編集作業を最小化するためには、発生源（ユーザー部門）で後工程（会計処理、経営分析、等）にて使用する情報を入力することが重要である。しかし、これらのデータはユーザー部門が直接活用するものではないため、検討の蚊帳の外に置かれてしまうことが多い。
また、全社最適の観点が欠落し、ユーザー部門の独自要件で開発されてしまうと、システム間でデータの粒度や構造が異なってしまい、データ結合が困難な状況に陥る。そうなると、システム間のデータをつなげるために人手による作業が発生してしまう。
アナログプロセスを撤廃するためには、これら３つの落とし穴を回避するシステム構成とアプローチがカギとなる。Ridgelinezの実践事例をもとに解説していきたい。
Ridgelinez がアプリケーション構成で採用したBest of Breedの考え方
Ridgelinezでは、Best of Breed（各分野でそれぞれ最適なサービス・プロダクトを選定し組み合わせる）の考え方で、アプリケーションを構成し、iPaaSでプロセス・データをつなぐことによって、プロセス・オーケストレーションを実現している。（図表3参照）
図表3 Ridgelinez社内のシステム構成
Ridgelinezが導入したアプリケーション構成
Ridgelinezコンサルティングビジネスの根幹に関わり、ユーザー部門の利便性を徹底的に追求する領域（いわゆるSoE（Systems of Engagement）の思想で設計する領域）は、Low-Code PlatformやUIに優れたSaaSを採用した。
一方で、正確に記録することを重視すべき領域（いわゆるSoR（Systems of Record）の思想で設計する領域）はERPを採用している。ちなみにERPはカスタマイズなしで導入しており、バージョンアップにも最小限の工数で対応できるようにしている。ERPで実装しきれなかった業務要件は、Low-Code Platformや周辺のSaaSで吸収するという考え方だ。
一般的に、Low-Codeによる開発は、従来の開発手法と比較して、1/3～1/5の工数で済むと言われている。この圧倒的な開発スピードはアジャイル開発との相性が良い。業務ユーザーと開発者が実際の開発画面を見ながら仕様を確認できるため、関係者間で認識齟齬があっても、すぐに軌道修正が可能である。業務視点と開発視点の両面から仕様を議論することによって、高品質な画面や機能を開発することができる。
Ridgelinezがユーザー部門に提供するUIにこだわった背景として、発生源での情報入力を徹底し、後工程で余計な作業をさせないという狙いもある。現場にとって快適なUX（User Experience）を提供することで、彼らにとって直接関係ない情報もストレスなく登録してもらうという作戦である。
iPaaSの活用
Ridgelinezのシステム構成において重要な役割を果たしているのが、iPaaSである。
業務アプリケーション間をiPaaSでつなぐことによって、プロセス・データをEnd to endでつなぐ。iPaaSもNo-Code/Low-Codeを志向しており、短期間でデータ連携を構築することが可能だ。
iPaaSの登場により、Best of Breedの考え方でアプリケーションを構成しやすくなっている。
Ridgelinezは、業務アプリケーションだけでなく、コミュニケーションツール（Slack/Outlook）とも連携させることによって、ユーザー部門の日常業務の中で自然に必要な業務処理が行われることを目指している。例えば、経費承認において、承認者のSlackに承認依頼通知が届き、そのSlack上で承認ボタンを押せば手続きが完了するといった具合だ。承認者は経費精算のアプリケーションを開かなくても業務を完結でき、本業であるコンサルティングサービスに集中することができる。
Ridgelinezが採用した高速開発を実現するアジャイルアプローチ
Low-Code PlatformやSaaSの開発においては、アジャイルアプローチを採用している。体制作りと推進方法において注意を払っているため、そちらを紹介したい。
アジャイルアプローチの体制
Ridgelinezでは、業務ユーザーと開発者（社内のテクノロジーコンサルタント）をアサインするが、それに加えて必ず業務コンサルタントをアサインしている。（図表4参照）
図表4 アジャイル開発体制のイメージ
業務ユーザーと開発者だけでも開発自体は進められるのだが、業務ユーザーは担当領域の視点に偏る傾向があり、開発者も業務ユーザーが受け持つ範囲での提案にとどまってしまうことが多い。業務コンサルが入って、全社最適の観点であるべき姿を議論することによって、抜本的なプロセス改革につなげることができる。
プロセス・オーケストレーションを実現するためには、全社最適の観点でプロセスを設計することが重要になるため、読者の組織においても、会社全体を俯瞰して議論をリードできる人員をアサインできるかがポイントになる。
社内の第三者的立場の人員（例：DX推進部門）をアサインできればよいが、該当する人員が社内に見つからない場合は、外部コンサルの活用も有効な手段だ。
アジャイルアプローチの効率的な推進方法
プロジェクト企画段階で野心的な青写真を描き、関係者全員の意識を合わせたうえで、開発に着手する。
この青写真の検討は、時間をかける価値がある。アジャイル開発が本格化すると、つい目先の議論にフォーカスしてしまい、方向性を見失うケースがあるためだ。
一方で、従来の開発手法のように業務フローや要件定義書の作成に時間をかけない。業務ユーザーと開発者の認識が合えばよいため、場合によっては箇条書きのメモやホワイトボードの板書で十分である。
スプリント（業務と開発が集まって、開発物のレビューと次スプリントまでの計画を立てるミーティング）は1週間サイクルで開催し、業務と開発が活発な意見交換をしながら、その場で仕様を固めていく。
次のスプリントまでに、業務側は業務要件の整理や要求仕様を具体化し、開発側はスプリント計画に基づいて開発を進める。
この間も、必要があれば業務側と開発側は会話をすべきである。何よりも開発のパフォーマンスを最大化するため、業務側は可能な限り開発側の疑問に速やかに答えることが重要である。
従来の開発のように発注者と受託者の関係性のままでは成功は覚束ない。業務側・開発側の双方が同じ方向を向いて、スピード感をもってタスクを推進することがアジャイルアプローチのパフォーマンスを最大化する。
アジャイルアプローチの付随効果
アジャイルアプローチを推進するうえで意識しておくべき点は、参画者の意識変革・スキルアップを促す有効な機会であるという点だ。
目の前でプロセス・システムが構築されていく様を体感するのは、参画者の行動変容を促すきっかけとなる。DX人材の育成に課題を持っている企業においては、アジャイル開発を人材育成の手段の1つに据えてみるのもよいかもしれない。
プロセス・データのデジタル化を追求し、プロセス・オーケストレーションの実現へ
ERPによって会社全体のプロセス・データが統合管理できるはずであったが、本稿で解説したとおり、現実にはアナログプロセスが残っている企業が多い。 No-Code/Low-code PlatformやiPaaSの活用を起点としたプロセス・データの徹底したデジタル化の追求が、圧倒的な工数削減につながる。（図表5参照）
図表5 ERPの落とし穴とその対策
SAPの保守期限切れ（2027年まで）を契機に、SAP採用企業では、システム刷新の動きが盛んになっている。
これからERPの導入・刷新を検討されている企業においては、ぜひプロセス変革の好機と捉え、プロセス・オーケストレーションの実現を目指していただきたい。
ERPの導入・刷新の予定がない企業においても、No- Code/Low-Code PlatformやiPaaSを活用することで大幅な業務効率化を図ることができる可能性があるため、ぜひ検討してみていただきたい。
執筆者
- 島田 裕士Director
Competency Group
※所属・役職は掲載時点のものです
