要件定義には十分に時間をかける

　要件定義とは単純にいうと、業務のやり方（業務要件）を洗い出し、その業務を行うために必要なシステムの機能（システム要件）を特定する作業である。既に計画フェーズにおいても要件定義が行われているが、計画フェーズの要件定義はパッケージ選定のための概括的な内容である。それに対して導入フェーズにおける要件定義は、選定されたERPパッケージを前提とした詳細かつ具体的な内容となる。

（1）要件定義は業務改革とセットで行う

　要件定義はあくまでERPを使って実現する新しい業務の要件を定義することであり、現行業務の要件を定義するものではない。ERPを使った新業務の要件を定義するということは、業務をERPに合わせて全社的に標準化することであり、可視化することである。結果として、業務プロセスの全体最適化が実現できる（もちろん、現実の導入において話はそれほど単純でないことも多い）。すなわち、要件定義と業務改革はセットで実施することになる。現行業務を前提とした要件定義ではERPを導入する意義が半減する。業務改革にならないからである。

（2）時間をかけて徹底的に議論する

　これは、当たり前のようで実は行われていないことがよくある。議論がまとまらず時間切れで次の作業フェーズに移ったり、社内で発言力の大きい部門の考えが優先的に通ったりといったことが現実にはある。しかし、要件定義で徹底的に議論してユーザー部門の合意を得ないと、次フェーズ以降で多くの手戻り工数が発生する。

　極端な事例だが、運用テストの段階になって初めて真剣な議論が始まったというプロジェクトもあるのである。そのケースでは、運用テストをしながら要件定義の見直しをすることになり、本番稼働は大幅に遅れ、全社的に大きな混乱が発生した。これは極端な事例だが、要件定義の議論が生煮えのまま次フェーズに進むのは大変危険なことである。

　逆に、十分に時間をかけて徹底的に議論することで、ユーザー部門から良いアイデアが出始めたら、しめたものである。導入スケジュールを作成するときには、要件定義に十分な時間を設定するように心掛けてほしい。

（3）早期にプロトタイプを設定して繰り返し要件を確認する

　ERP導入においては、テスト環境でプロトタイプを作り、実際にユーザーがそれを操作することで、要件定義で意図したように業務が実行できるか確認することが一般的である。その場合、要件が固まってからプロトタイプ開発のフェーズに入るというよりは、個別の要件を検討する段階で並行して部分的にプロトタイプを設定し、要件を確認しつつ、順次関連する要件を検討していくやり方をお勧めする。当然、要件が固まらない段階からプロトタイプを設定し始めるので、要件が固まるまで何度も設定をやり直すことになり、その分の工数は膨らむ。しかし筆者は、経験的にこの方法の方が、結果として少ない工数で効率的に要件定義を完結できると考える。

　なぜなら、ユーザーは要件定義フェーズの早期からプロトタイプで実際の入力や出力を確認できるので、その要件で業務が実現できるかどうかを容易に判断でき、机上で検討するより早く結論が出るからである。

プロジェクトメンバーがパッケージを知ることの重要性

　業務要件を洗い出した後、ERPパッケージでの実現方法を探りシステム要件を確定させるのはシステムインテグレーターなどの導入コンサルタントの役割と考えがちである。しかし、全てをコンサルタントに任せるのではなく、プロジェクトメンバーも積極的にERPパッケージの操作方法や機能、設定方法を習得し、システム要件の検討に加わるべきである。

　パッケージを知らなければ、ERPで何ができて、何ができないかが理解できず、結局、導入コンサルタント依存のプロジェクトになってしまう。もちろん、ERPの全ての機能に習熟する必要はなく、導入範囲にかかわる部分で、かつ導入のキーになる部分を中心にトレーニングを受ければよい。導入フェーズの早い段階でプロジェクトメンバーがERPに精通すれば、要件定義はもちろん、運用テストや移行をスムーズに進められる。さらには、社内にERPを理解したメンバーがいることで、本番稼働後の円滑な運用が見込まれる。

　筆者は、ERP導入フェーズの短い期間に、どれだけERPを自分たちのものにできるかが、ERP成功の鍵を握っていると考える。実際に、導入フェーズでプロジェクトメンバーが積極的にERPを習得し、その結果としてERPの機能を有効に活用した基幹システム構築や業務改革を実現できた例を多く知っているからである。

現場をどうやって巻き込むか

　ERP導入においては、ユーザー部門が業務要件を出し、運用テストを行う。すなわち、プロジェクト推進においてはユーザー部門の主体的な参画が必須になる。しかし、ユーザー部門から参画するメンバーは、得てしてERP導入を「IT部門の仕事」と位置付け、「ユーザー部門は協力者」といったスタンスを取りがちである。IT部門としては、ユーザー部門に当事者意識を持ってもらい、あくまでもユーザー部門がERP導入の主役で、IT部門は取りまとめ役であり推進役であるというスタンスを堅持すべきである。

　では、ユーザー部門に「その気になってもらう」にはどうしたらよいであろうか？　筆者が事業会社でERP導入プロジェクトのリーダーとしてプロジェクトを推進した際には、以下のようなことに留意して、ユーザー部門の積極的な参画を働きかけた。

（1）ERP導入が全社で取り組むべき重要案件であることを認識してもらう

　ユーザー部門の部門長らに、ERPの導入目的や、会社の成長に不可欠であることなどをよく説明し、ERPの導入が全社で取り組むべき重要案件あることを認識してもらう。また、ユーザー部門の部門長に何らかの形で導入プロジェクトのメンバーに入ってもらうことも重要である。

（2）ユーザー部門の利益になることを認識してもらう

　ユーザー部門は、業務をERPパッケージに合わせることで業務が非効率になることを危惧したり、ERP導入によってこれまでの業務のやり方が変わること自体に抵抗感を持つことが多い。このような心配に対しては、ERP導入によって業務プロセスが標準化され、関連する部門の業務の流れが見えやすくなること、情報が全社で共有されることで自分たちの業務がやりやすくなること、その結果として業務が効率化することなどをよく説明し理解してもらう必要がある。

（3）エース級を投入してもらう

　現場業務によく精通し、現場の人を動かすことができる人望の厚い人をプロジェクトメンバーに加えることが重要である。そういう人は、現業業務で多忙なことが多いが、ユーザー部門のトップによく趣旨を話して、エース級の人にメンバーとして参画してもらうことにこだわるべきである。

（4）経営トップの影響力を利用する

　ユーザー部門に積極的に取り組んでもらうには、やはり経営トップからERP導入について積極的なメッセージを発信してもらう必要がある。そのためには、定期的に進捗状況や課題などを経営トップに報告し、理解を得ることが重要である。社長や役員などにプロジェクトのステアリングコミッティのメンバーに就いてもらったり、各作業フェーズの区切りごとに経営トップへの報告会を行ったり、定期的に開催される経営会議や全社会議などで議題に乗せてもらうよう働きかけたりといった活動が重要である。

　こういった地道な活動が、「ERPプロジェクトはトップが認めてトップが後押ししている全社的プロジェクトである」という認識を社内に浸透させ、ユーザー部門の積極的な参画を促すことになる。

ERP導入はコンサルタントの支援が不可欠

　以上、ERPの導入フェーズにおける重要ポイントを幾つか解説した。前項で述べた通り、あくまでもユーザー部門が主役でIT部門は取りまとめ役としてERP導入を推進することになる。しかし、ERPの導入はパッケージに対する深い知識と導入の経験がないとなかなかまとめきれないし、推進するのも大変である。そこで、導入コンサルタントが重要な役割を果たすことになる。次回は、その導入コンサルタントとの付き合い方について解説する。