パッケージソフトであるERPを例に基幹システム導入の手順を説明します。種業態が同じであれば企業によって大きく違わない基幹業務においては、導入企業の要望に従ってイチからシステムを設計・構築する、いわゆるスクラッチ開発は選択肢にならず、多くのシステム導入に関して参考になるはずです。
ここでは、システム構築プロジェクトの実施手順のほか、その前段 階に行う 「基幹システム構築計画の策定」とシステムを構築し本番稼 動した後の「基幹システムの運用保守」 も合わせて取り上げます。
計画策定～業務改革について
ERP導入に合せて業務改革を実施する企業は少なくありません。 ソフト/ハードの保守切れを機にERPを導入することを起案したいが、大きな投資を伴うため保守切れ”が理由では説得力に欠けるため、 業務改革を併せて実施する例がもっとも多いでしょう。しかし、業務改革とは何かを明確にしておかないと、業務は改革できず、ERP導入プロジェクトは混乱し、多大な費用を無駄にする可能性があります。
務改革は広い概念で、経営戦略に合わせた事業の組み換え、グループ会社や仕入先との役割の見直し、抜本的な組織の見直しや人員配置の見直しなど、多岐にわたります。 IT関連では業務プロセスの改革という意味で使うことが多いでしょう。 BPR (Business Process Re-engineering) と同義で使われることが多いのですが、本来の意味においては、 BPRはあるべき業務プロセスをゼロベースで考えることを指します。
さて、ERP導入に関連して、業務改革をどう考えればいいでしょうか? まず、業務改革を大きく2つに分けてみます。
① 本来の意味におけるBPR
②業務プロセスの若返り
まず、 ① 本来の意味におけるBPRについて考えます。 「あるべき業務プロセスをゼロベースで考えることだと述べましたが、 Wikipediaに記載されている定義では、「高度に専門化され、プロセスが分断された分業型組織を改革するため、組織やビジネスルールや 手順を根本的に見直し、ビジネスプロセスに視点を置き、組織、職務、業務フロー、管理機構、情報システムを再設計し、最終的顧客に対す る価値を生み出す一連の改革」 となります。企業としてのビジネスモデルを改め、業務のあり方を抜本的に見直すようなケースが該当します。重要な経営的意思決定であり、ERP導入を契機に考える類のテーマではありません。 BPRの検討を進めるうえで、業務プロセスを大幅に変更する必要性が生じ、情報システムの刷新が有効だと判断されるケースはあり得るでしょう。この検討結果にもとづいて業務プロセ スを設計し、それに対して適合度の高いERP選定を行うことは極めて合理的です。
次に、②業務プロセスの若返りについて考えます。ERPを導入する際に、なるべくERPパッケージの機能に業務プロセスを合せるアプローチが該当します。後ほど詳述しますが、私の経験では、
- 標準機能の上に特有の機能を作り込んだテンプレートを使って、ユーザ向けにトレーニングを実施
- ユーザにテンプレートを評価してもらう
- 支障がなければその機能をそのまま使って業務プロセスを再設計してもらう
というアプローチを採ってきました。
上述した本来の意味でのBPRを行う場合には齟齬を 生じますが、そうでなければ、低コスト・短期間でERPを導入するために最も適した方法です。 この場合、業務プロセスは改善されない と感じるかも知れませんが、必ずしもそうではありません。多くの場 合、導入しようとするERPの先代のシステムがあります。長年利用 する過程で、必要に応じてさまざまな機能を追加し、さまざまな例外 処理をこなせるようになっているのが一般的です。 それらの中には、もはや必要ないものが少なくありません。業務上必要な結果やデータを得るための方法が幾通りもあるうち、システム導入時の担当者が、たまたまひとつを選んだだけかもしれません。
例外処理の場合、自動化によって得られる業務効率向上をコスト換算すると、機能追加の費用を回収するために10年以上を要するといった事態が起こりえます。 既存システムで機能を追加したときとはビジネス状況が変わっているため、当時は不可欠であった例外処理が、今も必要か見定める必要があります。業務プロセスをERPに合せようとする過程で、これらのいわばメタボ状態の現行プロセスからぜい肉をそぎ落とすことが期待できます。すなわち、業務プロセスを、筋肉質でシンプルに“若返らせる”ことを狙うわけです。
この点について理解を深めるため、ERPではなく、スクラッチ開発でシステムを構築する場合に何が発生するか考えてみましょう。スクラッチ開発では、通常現行業務を洗い出して、 開発対象とする機能を決めていきます。この時、業務フローを記述するのが一般的です。このアプローチでは、現行業務プロセスに則って業務をこなしている現場の担当者に対して、プロセスを改めるための対案を示すことが難しくなります。
ERP導入では、ERPの標準機能またはテンプレートが備えている業務プロセスで、業務を実行できないのはなぜか、担当者に理由を説明させることができます。しかし、スクラッチ開発のアプローチでは、 社内IT部門や社外のSI会社またはコンサルファームが、対案として の業務プロセスを提示せざるを得なくなります。業務についての理解は現場担当者に劣るため、なかなかうまくいきません。
また、スクラッチ開発アプローチで要件定義を行うと、“現行通り”とする圧力が大きくなります。私の経験でも、要件の詳細については、現場担当者に尋ねても把握しておらず、 「現行通り作ってほしい。 詳細は現行システムを解析すれば分かるはずだ」といった回答しか得られないことがあります。長期間に渡って運用してきたシステム では、担当者は世代交代しており、当初の担当者はすでに退職または 異動、当初要件を決めた経緯を誰も知らないことが少なくありません。このような場合、必要性が不明な要件は作らないアプローチを採りコ スト肥大化を抑えたいところです。しかし、そのためのリーダシップはERP導入に比べてはるかに強くないと機能しません。結果として、現状と大差ないシステムを、膨大なコストを使って構築することになりがちです。
さて、ここまで前稿では業務改革の2通りのアプローチ:
① 本来の意味に おけるBPR
② 業務プロセスの若返り
について述べました。
ERPを導入する企業が、 “業務は改革せず、ERP導入プロジェクトは 大な費用を無駄にする”事態に陥る原因として、この2つのアプローチを混同してしまうことが多いのです。典型的な例をストーリ仕立てにして、この構造をつまびらかにしましょう。
ストーリーで腑に落ちる導入アプローチ
中堅製造業A社(架空の企業ですが、 ストーリは現実に発生した例をもとに再構成しています)は、スクラッチ開発で構築して10年以上稼動している現行基幹システムのハード保守期限が迫ってきたた め、再構築を検討しています。IT部門では、スクラッチ開発と複数のERPに関して、概算で見積を取り、予算を確保しようとします。しかし、いずれにしても大きな投資であるのに、効果は何か、ROIについて考えているのか、といった経営者の問いに答えられません。関係部門と協議した結果、コンサルを入れて業務改革を行い、その結果として導かれる“あるべき業務プロセス”を、低コストで着実に実現 できる手段を採用することになりました。
中堅企業向けに実績が多く、業務に詳しいと評判のコンサルファー ムB社に依頼して、業務改革プロジェクトを立ち上げました。プロジェクトの冒頭で、コンサルファームの責任者から、業務改革で何を実現したいか尋ねられます。明確に定義していなかったのですが、『基幹システム刷新を機に、業務プロセスを改善し、企業としての競争力を向上させること」 を挙げ、「ROI を示して投資の妥当性を示したい」と伝えました。
コンサルファームでは、現行業務フローを描いて、業務上の課題 洗い出すとともに、あるべき業務フローを導くアプローチを提示し、A社は了承しました。2ヶ月で数百万円のプロジェクトです。プロジェクトの成果として現行業務フローを概要レベルで まとめ、システム導入ペンダに対するRFP(提案依頼書)ができあがりました。現場担当者との議論を踏まえ、要望も聞いているので、要件はかなり膨らんでいます。業務プロセスの削減や簡素化については、「To-Be業務フローが概要レベルなので、それで業務が回るか判断できない」との現場部門の意見を踏まえ、可能性だけを提示するにとどめています。
できあがったRFPにもとづく各社の提案内容は、以下の通りパター ン化できます。
ERPパターン1:
要件をすべて実現しようとするとギャップが多く、とても現実的な 予算には収まらない。 ERPに合せて要件定義からやり直し、要件を 抑えて妥当なコストでのERP導入を提案。
ERPパターン2:
ERPによって低コストで導入可能としているが、具体的な根拠が 示されない。「本当に大丈夫か?」との問いかけにも 「大丈夫」と繰り返すばかりで不安が尽きない。
スクラッチ開発:
すべての要件に対応することをコミットしているが、ERPに比べ費用がかさんでしまう。既存システムの構築ベンダによる提案であり期待していたが、内情を聞くと、当時を知るエンジニアは残っていないとのこと。
結局、ERPパッケージの選定を含め、半年に及ぶ社内検討を経て、 ERPパターン1の提案を採用して、ERPを導入することにしました。
いかがでしょうか? ストーリ仕立てにすると、「こんなやり方じゃだめだな」との感想をもつと思います。しかし、このような混迷を経験する企業は少なくありません。
問題の根幹は、業務改革で何を目指すのかはっきりしないままに、ERPの導入に合せて業務改革プロジェクトをスタートさせてしまったことにあります。ERPに合せるアプローチに徹するのであれば、そもそも現行業務を整理する必要さえありません。企業としての競争力を高めるために業務改革を断行するのであれば、現行システムの保守切れが迫ったタイミングではなく、もっと早い段階で、しかるべき 部門を巻き込んで実施する必要があります。そうでなければ、ERP 導入によって、業務プロセスの若返りを図ることに徹する方が賢明で しょう。
中途半端に業務改革を行って得られた業務フローや業務要件定義にもとづいてERPパッケージのFit & Gap 分析を行っても、あまり意味がありません。後からERPに合せて業務のあり方を見直す以上、その時点での業務要件は仮でしかないからです。また、導入ペンダが適合していると判断した要件であっても、詳しく分析すると適合していないケースもあります。この時点、つまり営業段階での適合/不適合 はあいまいな要素が多いことは留意すべきでしょう。 ユーザ企業としての私の経験では、導入ペンダよりもパッケージ・ベンダが提示するFit率は高くなる傾向があります。ライセンス販売がビジネスゴールとして重要であることを考えれば致し方ないかもしれません。しかし、複数企業に分析を依頼して、導入ペンダとパッケージ・ベンダが混在している場合には注意が必要です。
コメント