基幹システム刷新プロジェクトでの業務標準化の典型例

まずは基幹システム刷新プロジェクトでの業務標準化の典型例から紹介しよう。
刷新プロジェクトの発端となるのは、長年の運用による基幹システムの老朽化だ。事業部門ごとに業務プロセスが分かれていることに伴い、基幹システムも事業ごとに構築されている。DXに関する機運の高まりから、これを機に基幹システムを統一／クラウド化して、全事業の業務標準化を進めようと考える。
そこで多くの企業が採用する手法が「Fit to standard」だ。この手法は、業務プロセスをパッケージシステムの標準にあわせることで、業務標準化を効率的に進めるものである。そして定めた方針に従い、RFP（提案依頼書）を作成してベンダーを選定、いよいよ基幹システム刷新プロジェクトがスタートする。
プロジェクト開始とともに要件定義を進めていく。ところが、要件定義の後半に差し掛かってベンダーから「業務が複雑で要件定義に時間がかかる」という理由で期間延長を求められる。仕方なく数カ月の延長を決定し、要件定義を進める。しかし今度は開発フェーズで「開発量が予想より多い」とベンダーより報告され、さらなる期間延長と費用追加を余儀なくされる。

システム構築が進むさなか、今度は「開発量が多くテストに十分な時間が必要」という理由でまたしても期間が延び、追加費用もかさむ。そしてどうにかシステム稼働を迎えるものの、度重なる期間延長と膨大な費用追加にも関わらず業務標準化は部分的なものに留まり、目指していた効果も現れていない。とはいえ基幹システム刷新により事業継続リスクは解消され、部分的とはいえ標準化も進んだため、一旦は良しとする——これが業務標準化を伴う基幹システム刷新プロジェクトの典型例だ。

Fit to standard手法に潜む課題

一般的な基幹システム刷新プロジェクトでは、まずプロジェクトの準備段階で「業務の標準化」を主目的として掲げることが多い。そしてFit to standardの手法を用いてプロジェクトを進めるが、ここにはいくつかの問題が潜んでいる。

問題点の一つ目は、「標準化」を安易にプロジェクト目的として掲げてしまう点である。標準化がどこまで可能かを、準備段階で十分に調査・検討しないまま進めてしまうことが多い。

二つ目は、Fit to standardが主に個別業務に対して焦点を当てている点だ。個別業務ごとにERPシステムの標準プロセスで実行可能かどうかという狭い範囲での検討に留まっており、結果として業務全体を見渡すアプローチに至らない。特に既存のERPシステムを刷新する場合では、すでに個別業務の標準化は済んでいるケースも多く、改めて業務プロセスを再考・標準化を進める余地は限られるだろう。

三つ目は、多くの根深い課題は個別業務の中ではなく、組織間や対顧客にまたがる業務プロセスの中に存在する可能性が高いことだ。特にサプライチェーンマネジメント（SCM）領域ではこの傾向が顕著である。特に3～6カ月程度の短期間で行われる要件定義では、システム構築に関して多くの作業が必要な中、全体の業務や組織間の課題を俯瞰して解決に導く工数も限られ非常に難しい。特に近年ではリモートワークの普及に伴い、業務担当者が自担当の狭い業務範囲しか知らないケースも増えている。この場合、業務背景や関連部門とのつながりなどを十分に理解していないため、組織間の課題を抽出して業務全体での標準化や効率化はより一層困難になると考えられる。
 
ただし例外もある。それは会計領域のみの基幹システム刷新だ。この場合は経理部門に閉じた課題がほとんどであり、組織間の課題が少なく自組織内での調整で業務変更ができるため、この方法でもうまくいくケースは多い。

日本企業の業務において頻発する課題の背景

基幹システム刷新プロジェクトでは、組織間や顧客との間で発生する業務課題を解決するために、関係する組織を巻き込んで業務改善を進めることが求められる。しかし組織間の調整は困難を伴うため、自部門内で解決しようとしがちである。その結果、より一層業務が複雑化してしまう。特に対顧客の業務においては、「顧客要求」という名の基に自社の業務手順やフローを変更することに違和感がない風潮があり、このような考え方が業務のさらなる複雑化を引き起こす要因となり得る。業務の標準化をするならば、これらの問題がある前提で進め方を考える必要がある。一般的な基幹システム刷新プロジェクトは、この問題に十分に向き合っていないことが一番の課題とも言える。組織内・対顧客間それぞれで業務が複雑化しやすいケースを紹介しよう。

組織間課題の典型的な例
通常フローではまず営業部門で販売計画を立て、それを基に生産計画を立てる。しかし実際には販売計画の精度が低いため、製造部門が独自で生産計画を立てている。これにより販売側の販売計画の精度は一向に上がらないまま、販売計画を達成するミッションも曖昧になる。本来は営業部門の販売計画の精度向上を考えるべきだが、製造部門側としても営業部門との関係悪化は避けたく、問題提起に踏み込まない。これにより生産計画において独自業務が発生し、結果として基幹システムの独自開発を要する。

対顧客課題の典型的な例
請求書を顧客ごとのリクエストを組み込んだフォームにしている。ある顧客の在庫引き当てなどに特別なルールがあれば、その仕様に沿って対応する。これにより社内業務は煩雑化するものの、営業側の受注獲得を優先するため問題視はせず受け入れる。そして顧客ごとの仕様変更に係る業務作業量の負荷軽減を目指し、基幹システムに独自開発する。
 
業務の標準化を目指す場合、このような根本的な問題にも焦点を当てて見直すことが欠かせない。
なお、これらの問題について検討する際のポイントとしては「この業務処理は自社の強みと関係があるのか」「実施が必須かどうか」「今の業務内容でよいのか」を考慮することが重要である。これらを十分に考慮できれば適切な標準化の可能性も高まり、実現できた時の効果も大きい。

基幹システム刷新を成功に導く5つのステップ

これまで、組織間や対顧客の課題に対して向き合うことが業務標準化にとって重要であることを説明してきた。これらを踏まえた上で、ここからは具体的な標準化プロジェクトの進め方を解説していこう。
標準化を推進する基幹システム刷新のプロジェクトを進める際は、以下の①から⑤のステップを踏むことで業務標準化可能な範囲がより明確になり、従来型の基幹システム刷新の進め方よりも標準化範囲を広げられる可能性が高い。また、自社独自の業務範囲も明確になることで開発量を想定しやすくなる。その結果、プロジェクト計画の精度・期待効果をあげる可能性を高め、不要な期間延長やコスト増大のリスク低減につなげられる。

①組織間課題抽出
まずは、現行の組織間や対顧客の問題を洗い出す。問題の抽出の方法としては、既存基幹システムがパッケージの場合、アドオン開発の内容を基に、どのような業務が標準から外れているのかを想定する。次に現行業務フローを確認する。これにより情報連携ができていない部分や対顧客に対する処理、対仕入れ先に対する処理における課題が明らかになり、潜在的な問題の抽出につながると考えられる。

②基幹システム刷新の目的を決める
課題の抽出後、自社の方針を踏まえて基幹システム刷新の目的を設定する。そして関係者と合意のうえ、「課題検討プロジェクト」を社内に立ち上げる。これにより、組織の壁を越えて協力するための基盤を構築できる。

③組織間課題検討
課題検討プロジェクトにおいて提起された課題の本質を関係者含めて探る。主に「提起された課題は本質的なものか」「課題の重要度はどのくらいか」「そもそもこの業務処理は自社の強みであり必要不可欠な業務なのか」「基幹システム刷新で検討すべき課題か」などを検討するとよい。業務担当者が業務を俯瞰できない場合は、第三者や関係者共同での業務整理なども検討する。このプロセスにおいて、システム刷新プロジェクトの推進課題、特に現行業務を全体俯瞰して理解している人がいないといった人材面での課題抽出にも役立つ。

④施策検討（標準化）
課題解決に向けた施策検討の中で、「経営管理の観点から必要な施策か」「全体最適すべき内容か」といった点を考慮のうえ、手法のひとつとして業務標準化を検討する。そして基幹システム刷新の対象とする課題と施策を最終確定する。

⑤基幹システム刷新プロジェクトを立ち上げる
標準化すべき業務や解決の方向性を確定させ、プロジェクトの計画を立案し基幹システム刷新プロジェクトを立ち上げる。
 
これらのステップを着実に進めることにより、プロジェクトが抱えるリスクを低減しながら基幹システム刷新プロジェクトによる全社的な効果が期待できる。

おわりに

基幹システム刷新での組織内の業務標準化は、Fit to standardアプローチによって比較的実現しやすいと考える。しかし、これだけでは効果は限定的になってしまうことが多い。繰り返しになるが、業務標準化の効果を最大化するためにはある程度時間を割いて、準備段階で組織や顧客との間に潜む根本課題にしっかり向き合うことが肝要だ。
本稿が、皆さまの基幹システム刷新の業務標準化プロジェクトの成功の一助となれば幸甚である。