【IT分野での2025年問題の本質:step2】再構築対象範囲・現状課題の明確化

システム

2020年04月02日(木)掲載

この「ステップ2」の真の目的は?

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

しかし、再構築プロジェクトが始まってからいきなり要件定義を実施しようとしても、そもそも再構築の背景や目的や明確になっていなければ、その要件定義自体が狙いとズレてしまうでしょう。そして、最悪な場合は詳細の要件定義を実施したものの、その実現機能が導入予定のパッケージの標準機能では実現が難しいというようなことがわかり、再度パッケージの選定からやりなおさないといけないような自体も起こりかねません。
 
その理由としては、再構築プロジェクトの開始時点で、一番重要な再構築の目的やそれを踏まえた機能を支援ベンダー側も良く理解出来ていない、あるいは機能詳細の内容に支援ベンダーの誤解が潜在していると言うような可能性もあり、それ故に貴社の再構築目的に合致しないパッケージを適用してしまっているケースもあるからです。このことはERP導入のような大規模プロジェクトであればあるほど、実際良くあるケースです。

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

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

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

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


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

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


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


・再構築後の現場業務フロー(To-Beフロー)ドラフト(案)の作成
  
・この段階での予算感や費用感を元にした、課題の大分類


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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

執筆者H.K氏

大阪大学工学部卒業後、電機業界の大手企業に入社し、情報システム事業部門勤務。米国への社費留学にて、コンピュータサイエンス修士号取得後、米国・東南アジア・欧州の関連会社に出向駐在を経験。日系企業の基幹システム導入支援等を多数実施。定年後はIT顧問として活動中。英語・海外関連著書30冊以上あり

関連コラム

ページTOPへ戻る