基幹システムの再構築対象範囲・現状課題の明確化、ERP導入の要件定義の仕方は？

システム

2020年04月02日（木）掲載

このコラムは、IT分野での2025年問題について書かれた第三稿です。第一稿と第二稿はこちらにありますので、ご興味のある方はご覧ください。2025年問題と基幹システムにおける課題・海外比較を解説しています。

人気の関連コラムを読む

IＴ分野での2025年問題の本質～基幹システムの再構築検討の前に～

基幹システムの入れ替え・再構築・刷新に向けて、準備からベンダー及びパッケージ選定計画の立案

本コラムでは、基幹システムを再構築する際のハウツーと要件定義なども含めて解説します。

■「ステップ2」の真の目的は？
■「ステップ2」でなすべき内容及び成果物は？
■「ステップ2」実施上の勘所
■最後にもうひとつ重要なポイント

この「ステップ２」の真の目的は？

要件定義

通常、基幹システムの再構築プロジェクトが始まると、最初に実行すべき重要なステップは、皆さんよくご存じのフェーズである「要件定義」です。このステップは時間を掛けてしっかり行っておかないと、後のフェーズで手戻りが発生する、あるいは業務満足度が実現出来ない等の品質の低下にもつながるほど重要なステップとなります。

しかし、再構築プロジェクトが始まってからいきなり要件定義を実施しようとしても、そもそも再構築の背景や目的や明確になっていなければ、その要件定義自体が狙いとズレてしまうでしょう。そして、最悪な場合は詳細の要件定義を実施したものの、その実現機能が導入予定のパッケージの標準機能では実現が難しいというようなことがわかり、再度パッケージの選定からやりなおさないといけないような自体も起こりかねません。

その理由としては、再構築プロジェクトの開始時点で、一番重要な再構築の目的やそれを踏まえた機能を支援ベンダー側もよく理解出来ていない、あるいは機能詳細の内容に支援ベンダーの誤解が潜在していると言うような可能性もあり、それ故に貴社の再構築目的に合致しないパッケージを適用してしまっているケースもあるからです。このことはERP導入のような大規模プロジェクトであればあるほど、実際よくあるケースです。

POINT

・基幹システムの再構築の目的を明確にすることが非常に重要である。
・実際に、再構築プロジェクトの開始時点で、再構築の目的やそれを踏まえた機能を支援ベンダー側も理解出来ていない場合が見受けられるので、プロジェクトのメンバーで、目的設計を行うことが非常に重要である。

そこで、準備フェーズにおける、この「ステップ２」が重要になってきます。

「ステップ２」でなすべき内容及び成果物は？

この準備フェーズの「ステップ２」でなすべき「再構築目的・課題等々の明確化」が凄く重要なのはお分かりいただけたかと思います。では、この準備段階でまだ何も決まっていない場合、どのようなことをすれば良いのでしょうか。
それは、既に「ステップ１」のところで解説しましたように、提案依頼書（以下、RFP）や、プロジェクトマネージメント計画書（以下、PMP）にも関連するタスクとなります。つまり、この準備「ステップ２」でのアウトプットが、次の「ステップ３」で作成しますRFPや「ステップ６」で作成しますPMPの重要なインプットとなるのです。

詳細内容は、再構築プロジェクトの内容や規模によっても多少異なりますが、通常は以下がタスク及びその成果物となります。

・再構築対象となる業務の、現状業務フロー（As-Isフロー）の整理

・As-Isフローをもとに、現状の現場業務課題の洗い出し整理

上記は、各業務メンバーの支援を得れば、比較的容易に実現出来るタスクです。そしてここからが少し大変ですが、更に以下のタスクも必要です。
（現状業務課題の解決や業務改善（BPR: Business Process Engineering)をする、しないに関わらず、下記のタスクは、RFPやPMPのインプットとして重要です。）

・再構築後の現場業務フロー（To-Beフロー）ドラフト（案）の作成

・この段階での予算感や費用感を元にした、課題の大分類

上記は、貴社として必ず再構築にて実現すべき機能要件（Must to　Have：必須）と、できれば実現させたい機能要件（Nice to have：あれば良い）にできる限り分類することです。そのためにも、上記の二つのタスクのアプトプットが必要となります。

・上記を踏まえての基幹システム再構築の対象業務、対象範囲等の明確化
　
・再構築プロジェクト全体の概要スケジュール（自社メンバーや想定ベンダーメンバーの人月（工数概算）も含む）を策定
　
・最後に、上記のスケジュールをもとに、概算費用の算出・明確化

というように、準備フェーズとはいえ、多くのタスクがあることから業務メンバーの協力も必要とし、人月工数がかかるのがこの「ステップ２」となります。

ここで、少し疑問が湧くと思います。本当に、準備フェーズでそこまでやらなければいけないのか、これはプロジェクトのキックオフ後にやればよいのではないかと言う疑問です。このコラムをお読みの方の中にもそのように思われる方が恐らくいらっしゃるでしょう。確かに、IT部門の方々からも良く出る疑問です。
しかし、実はこの準備フェーズをないがしろにするが故に、あとで手戻りが出る、あるいは失敗に至るプロジェクトが多いのが昨今の実態です。

準備フェーズ、特にこのステップを重要視するか否かで、その後のRFPやPMPのアウトプット、更には、キックオフ後のメインの「基幹システム再構築プロジェクト」の成否のみでなく、再構築プロジェクト全体の費用の低減可否（品質、納期、予算という面で）にも影響するのです。

POINT

・以下がタスクとして生じてくる。
①再構築対象となる業務の、現状業務フロー（As-Isフロー）の整理
②As-Isフローをもとに、現状の現場業務課題の洗い出し整理
③この段階での予算感や費用感を元にした、課題の大分類
・準備フェーズでのタスクをしっかりこなすことが大事である。

「ステップ２」実施上の勘所

既に述べましたように、「基幹システムの再構築」は規模の差はありますが、大変なプロジェクトです。企業によっては、時間的あるいは費用的な制約により、この「準備フェーズ」をできる限り短くし、再構築プロジェクト全体の開発期間や費用も最小限にしたいと言うニーズも当然出てくるでしょう。

必要なタスクの全体像としては同じですが、その中身は、貴社の状況により多少は省略することも可能です。
例えば、現状の業務フロー(As-Isフロー）が既にあれば、業務メンバーにそれが最新版かどうかだけを見直していただき、その際に現状の課題もヒアリングし、それをもとに一挙に再構築を意識した業務フロー（To-Beフロー）も作ってしまうと言うタスクの進め方もあります。そうすれば、かなり時間や工数の節約にもなります。

また、この「ステップ２」で重要なのは、「個別最適」でなく「全体最適」を常に意識して作業を進めるということです。そもそもERPは全体最適を実現するのがメインのパッケージであるが故に、現場の細かいところの機能サポートまでは十分出来ないというような面も当然あります。

そして、その際に参考になるのが、既にタスクの解説の中で触れましたように、その課題は現場がどうしても譲れない必須要件・課題かどうかということです。もしもそれが全体最適化を損なう場合には、全体を見て調整・判断をしなければいけないケースもありますので一概には言えませんが、その業務対応工数が多少かかっても運用でカバーできる機能であれば、全社的な全体最適機能の実現を優先すべきというのが私の考えです。そうでないと、ERPパッケージの標準機能が使えなくなり、作り込み（いわゆるアドオン）が多くなり、ERPパッケージ適用の再構築の意味がなくなります。

このあたりは最初の検討段階で一番悩むところですが、ここでのひとつのアドバイスがあります。もしその現場業務部門で実現したい機能要件が、貴社が他社に比べての優位性をだしているような機能であれば、たとえその分の予算や工数を掛けてでも、その機能を実現する為に多少のアドオンで従来の業務システムの活用・連携や、WMS（Warehouse Management System：倉庫管理ステム）のような細かいところまでのサポートが実現出来るような外付けパッケージとの活用は十分あり得るでしょう。

よって、この段階でもしそのような可能性があれば、これは大変重要ですので、流用すべき既存のパッケージや新規に使いたいパッケージの候補案や、その適用に対しての工数や費用感も予算に含めて整理しておくべきでしょう。

あくまでも、この「準備フェーズ」の段階ではドラフト（案）レベルですが、貴社にとって重要なところが漏れては意味がありません。このような作業を事前に実施しておくこと自体が重要であり、これにより、その後のRFPやPMPの品質・精度も向上するのです。

POINT

・準備フェーズを縮小することも可能。その際、なにが優先的に実現したいことなのかを明確にし、それに対しては投資を惜しまない。

最後にもうひとつ重要なポイント

このステップの解説が長くなってきましたが、それだけこのステップは重要だということを意味します。最後に、ここでもうひとつ重要なポイントについて触れさせていただきます。こちらの重要ポイントをもって「ステップ２」の解説を終えることとしましょう。

実は、基幹システム再構築を行うにあたり、何が「貴社にとっての真の（重要な）再構築課題」なのかが明確になっていない企業が多く、結果としてビジネス効果に結び付かない基幹システム再構築を行っているケースも見受けられます。　こうした「課題の不明確さ」は、準備フェーズをしっかり実行せずに、場当たりな基幹システム開発を行ってしまっていることにも大きく起因するのです。

これを避けるひとつの重要な方法としては、既存システム環境のアセスメント(現状評価)があります。アセスメントとしては、組織をまたがる業務とそれを遂行するためのシステムのつながりなどを洗い出しますので、業務プロセスを業務フローとして可視化するタスク実行の際に、各業務フロー間の連携や関連に着目することです。

つまり、各業務システムが貴社の業務の効率化（利益の創出）にどういった役割を担っているのかを、改めて整理するのです。これが、統合業務パッケージであるERPを導入する際のひとつのポイントにもなります。その観点から、どこに問題があって何を改善、解決すべきかを整理するのです。つまり、ここで最も重要なポイントは、貴社の業務プロセス全体を可視化することとも言えるでしょう。

業務プロセスというのはいくつもの作業の連なりです。さらに、複数の業務プロセスが互いに絡み合って一覧の業務アウトプットを生み出します。このため、業務プロセス全体の可視化を行わずに基幹システムの再構築を行ってしまうと、一部の業務は効率アップに成功したものの、それに関連する他の業務に悪影響を及ぼしてしまうというような失敗も少なくありません。

つまり、このことが、私が既にふれました「全体最適」が重要ということなのです。このことを念頭において「ステップ２」を実行されてください。このことを意識するだけでも、貴社の再構築プロジェクトは更に一歩成功に近づきます。

POINT

・各業務のプロセスを可視化することで、有益な基幹システムの再構築ができる。

まとめ

本コラムのまとめを以下で説明します。

導入フェーズの注意点

最初に実行すべき重要なステップは、「要件定義」です。時間を掛けてしっかり行うことで、後のフェーズで手戻りが発生しません。再構築プロジェクトが始まってからいきなり要件定義を実施しようとしても、そもそも再構築の背景や目的や明確になっていなければ、その要件定義自体が狙いとズレてしまうため非常に重要です。また、ベンダーを巻き込むタイミングでも、改めて要件定義は行った方がいいでしょう。

プロジェクトの進め方

タスクの整理を行うことが必須です。

・再構築対象となる業務の、現状業務フロー（As-Isフロー）の整理

・As-Isフローをもとに、現状の現場業務課題の洗い出し整理

などを通して、プロジェクト達成のためにどういった業務が必要なのかをまずは洗い出しましょう。例としてステップを以下に示します。

1.経営・事業戦略から見る基幹システムの重要性、意味を確認する。

2.プロジェクトの要件定義を行う、目的を明確化し、ベンダーを込みしたプロジェクトメンバーで認識をきちんと行う。この際、現状の課題が何で、このプロジェクトを達成した時にその課題が解決されるのかはきちんと確認しておくことが必要である。

3.システムの適用範囲や規模の決定などを決める、ベンダーにアドバイスは貰いつつ自社で決定を行う。

4.導入する時の計画を立てる。

5.完成した基幹システムを自社で活用する体制を整える。

5に関しては、次のコラムで解説していきます。

HiPro Bizでは、さまざまな企業の経営課題を解決できる経営プロ人材を紹介しています。最近お問い合わせで多いのが、こういったIT課題の解決、また、ITベンダーとのやり取りの中での客観的な意見を言えるようなセカンドオピニオンとしての依頼です。
基幹システムをはじめとした社内DXに課題があるためプロ人材にDX戦略を指南してほしい場合、また、ベンダーとのやり取りの中で課題が生じておりベンダーコントロールをしてくれる存在が欲しい場合、そういった場合にHiPro Bizに登録しているプロ人材が非常に力強い味方になります。
ぜひお問い合わせください。