[ERP導入に失敗しない3つの条件、ベンダーの言いなりにならない真の活用に向けて]
【条件1】ERP導入の掟─「人・もの・金」の体制作りを軽視しない
2015年3月17日(火)京セラコミュニケーションシステム(KCCS)ERP導入支援チーム
ERP(Enterprise Resource Planning)パッケージの導入に向けて、RFP(Request for Proposal:提案依頼書)を提示すれば、パッケージベンダーやITサービス会社からは、必要なプロジェクト体制や、スキルセットを有するコンサルタントや技術者が提案される。最近では、最終フェーズでプロジェクトマネジャーによるプレゼンテーションを必須にするなど、ユーザー企業は、ITサービス会社の力量を十分に吟味/選定し、プロジェクトをスタートさせている。にもかかわらず、開始1カ月で混乱をきたすような例もある。どこにボタンの掛け違えがあるのだろうか?
ERP(Enterprise Resource Planning)パッケージの導入に向けては、以下のような魅力的な効果が一般に強調され、導入側も期待している。
(1)統合パッケージとしての全体最適化
(2)業務プロセスのグローバルスタンダード/各国制度会計への対応
(3)標準で提供される豊富で実績のある機能群
(4)短期間での立ち上げ
しかし、これらは、あくまでも「既製服に合わせる」という原則が大前提になる。そこでは、既製服に合わせることを逆手に取ったパッケージベンダーやITサービス会社の論理にも注意が必要だ。「現場の業務負荷が上がるシステムを渋々受け入れる」か「高額なアドオン費用を支払う」かの“究極の選択”を、引くに引けないタイミングで突き付けられることもある。
「そんなことは百も承知」と思われるだろうが、実際のプロジェクトでは期待が膨らみ、プロジェクトの舵を失うことがしばしば起こってしまう。アドオン開発については次回に譲るが、舵を失う最大の原因は、ユーザー企業がプロジェクト体制を軽視しているからだ。失敗しないERP導入の第1ステップは、自社でのプロジェクト体制である。乗り越えるべき壁は、まず社内にあるわけだ。
自身の体型を知らずに適不適は分からない
ERPパッケージの選択/導入を、一般の既製服と対比して、プロジェクト体制のあり方を考えてみてほしい。
例えば、スーツを買う場合、さっとデパートなどに行き、店頭にある吊るしのスーツを試着する。ズボン丈のほかに、ちょっとお腹周りがきつければ、裾直しとウエストサイズの調整程度で済む。だが、自社の業務がERPパッケージにフィットするかどうかは、そう簡単には判断できない。
そのため、パッケージベンダーやITサービス会社が用意する導入コンサルティングサービスを受け、「Fit & Gap」と呼ばれる工程をプロジェクトの序盤で実施し、ERPパッケージが自社業務に、どれくらいフィットしているかを確認する。しかし、そもそも自分の体型が分かっていなければ、フィッティングなどできるはずもない。
Fit & Gapを実施するにあたっては、まずは自社のことを隅々まで分かったプロジェクト体制が重要になる。そこを疎かにしては絶対にプロジェクトは成功しない。もちろん、今の体型にただ合わせるだけではなく、「理想の体型」を求める場合には、理想像を描ける体制が必要になる。
提案時に苦言を呈するベンダーは少ない
プロジェクト体制の重要性が分かっていても、「業務が忙しく、キーパーソンをプロジェクトにアサインできない」「どうせ自社業務の全貌が分かる人なんていない」という状況は、プロジェクト開始時点では良くある状況だ。
しかし、受注を得たい提供者の立場からすれば、ユーザー側に厳しい要求は出しにくい。結果、「標準テンプレートや導入手法があるので、打ち合わせは最小限で済みます」とか「標準業務フローに合わせていけば要件はスムーズに決まります」といった提案が出てくる。こうしたパッケージベンダーやITサービス会社の提案文句を鵜呑みにすることは非常に危険な場合もある。
ERPパッケージの導入には様々な課題が立ちはだかることが予想される。であれば、経営的視点と現場を巻き込んだ視点から、しっかりとした判断が下せる体制の整備を求めるパッケージベンダーやITサービス会社のほうが信頼感は高い。十分な人材がアサインできるまでは、プロジェクトはスタートすべきではないだろう。
ユーザー側プロジェクト体制の問題点
では、どのような体制が組めればスタートできるのか。図1は、よく見られるプロジェクト体制のイメージを表している。錚々たるメンバーが名を連ねたプロジェクト体制だ。
拡大画像表示
しかし、重要なのは、表面的な体制ではなく、次のようなチェックポイントがクリアされていなければならないことだ。
チェックポイント1:マネジメントの役割と権限が明確になっているか
プロジェクトオーナー、プロジェクトマネジャー、プロジェクトリーダー、プロジェクト支援、そしてアドバイザー−−。マネジメント役を担うポジションが多数存在したとしても、それぞれが、どのような役割で、どれだけプロジェクトに参画するかが不明確な体制が少なくない。
古株で業務にはとても詳しいものの、「口は出すが責任は取らない」といったメンバーが組み込まれる例も散見される。とりあえず名前を入れておくだけの意味のないメンバーが増えれば増えるほど、「船頭多くして船山に登る」の例え通り、プロジェクトは舵を失っていく。
チェックポイント2:少数精鋭のチームか
プロジェクトリーダー配下の体制にも注意が必要だ。図1では、販売/計画チームからインフラチームまで、非常に多くの人が関わっている。これだけのメンバーがベクトルを合わせ、プロジェクトの目的を完遂することは難しい。チーム間の溝や畦道を作ることにもなる。
プロジェクトは、多少無理をしてでも、少数精鋭で立ち上げるべきだ。そのチームで、全体業務やシステム化の範囲などを大まかに決めてプロジェクトオーナーの承認を得る。そこから各チームに展開するのが望ましい。
当然、少数精鋭チームを作ることは大変だ。その場合は、ERP導入以前に自社業務を分析するためのビジネスコンサルティングを受けることも有効だろう。ただし、その際も当然、主体は自社のプロジェクトメンバーであることが非常に重要になる。
チェックポイント3:システムの要求部門と費用負担部門は同じか
「要求は出すが、費用は別の部門が支払ってくれる」−−。これは最も質が悪いプロジェクトの体制だ。スーツの購入でも、選ぶのは奥さん、支払いは旦那さんともなれば、奥さんは値札を見ずに選び、あれもこれもと金額は膨らむことだろう。現場の事業部門が要求を出し、費用はIT部門が支払うという形態が、まさにこの構図である。結果、現場の要求は「言わなきゃ損」といった状況になってくる。
何を要求するか、そのためにどれだけの費用をかけられるのか、などを正しく判断するためには、費用負担部門が要求事項を判断できるような体制を作ることも重要になる。
チェックポイント4:プロジェクトオーナーを巻き込んでいるか
ERPの導入プロジェクトは全社・全グループ会社にまたがる場合が多い。部門間の調整が成功へのキーファクターになる。そこでの調整をプロジェクトマネジャーやプロジェクト支援メンバーが担当することになるが、プロジェクトオーナーの全面的な支援があることが不可欠だ。この理由については、第3回で説明する。
会員登録(無料)が必要です
- 1
- 2
- 次へ >