ITコーディネータとしての職務上、顧客企業からERP導入の支援を求められることは珍しくはないはずです。そのときみなさんはどのように顧客企業を支援していかれるでしょうか。もちろん、企業規模、導入目的、企業文化、業種、予算規模など背景の相違により、その進め方はさまざまでしょう。
筆者は、最近自社におけるERP導入を統括し、幸い成功裏にかつこの種のシステム導入としては短期間に完成させることができました。このプロジェクトの成功要因（ITC的に表現すると“CSF”）を振り返って考えてみますと、一つひとつは「当たり前のことを実行する」に尽きます。しかしながら、実際の多くのERP導入は、当たり前のことを当たり前にできなかったために失敗したのではないでしょうか。当たり前のことを行って、あるいは行わせて、プロジェクトをリードする手腕こそITコーディネータにまず求められる責務であると筆者は考えています。
類似した業務に取り組まれるみなさんの参考となれば幸いです。
なお、本稿では、具体的な名称や数値、商品名などは可能な限り伏せさせていただきました。より具体的な情報を求められる方は「まいど！フォーラム」を通してご遠慮なくお問い合わせください。
２．本稿で扱うフェーズ
本稿では、まずERP導入プロジェクトの立上げからERP選定までのフェーズ進め方を述べます。その後、社内承認を経て実際の導入へと進むわけですが、後のフェーズに関しては続編に記述します。
３．事例対象とした企業とプロジェクトの概要
以下は、筆者が取り組んだERP導入について、規模観をもっていただくための情報です。
（企業概要）
企業規模： 年間売上げ 約600億円、 従業員数 1,500名、
業種：
製造業（工場設備）対象のエンジニアリングと建設工事、システム開発/保守
（プロジェクト概要）
期間： プロジェクト立上げ から ERP選定 まで ４ヶ月
ERP発注 から システム稼動 まで ９ヶ月
対象業務：
事業の原価管理、調達、営業、経理、および決裁にかかわるワークフロー
（付帯状況）
システムの専門部署を除いて、社内全般にITリテラシーは非常に低い。
２社合併に伴う基幹システムの統合を兼ねる。
合併前の２社ではそれぞれオフィスコンピュータで原価管理、調達、経理などを
処理していた。
４．プロジェクトの立上げ ・・・・・ プロジェクトとその方針を徹底的に周知する ・・・・・
システム再構築の意思表明がトップから出されたのを受けて、対象、構築期間、進め方の手順など、企画書を作成しました。そして、社長が企画書を承認しプロジェクトをスタートさせました。
プロジェクト立上げの宣言には次の項目を含めました。
１） ERP導入の目的（原価管理の精度改善、仕掛り品の減少、など）
２） 導入方針
（ベストプラクティスを導入し自社の業務プロセスを改善する、など）
３） 社長をトップに置いたプロジェクト体制と実務メンバーの明示と周知
４） カットオーバー日を明示した工程
５） 概略の予算
プロジェクトの周知について： プロジェクトの立上げは社長自ら経営会議など社内で公式に宣言します。当該プロジェクトを知らないことが企業内では職務怠慢と見られるまでに、徹底したプロジェクトへの認知を、役員や幹部社員にしてもらう必要があるからです。ERP導入はトップダウンで扱うべき性格を本質的に持っています。なぜなら、多くの社員にとって業務の仕方は変わらないことが心地よく、変えることは個々の社員から必ず抵抗を受けるからです。ITCにとって社長以下の役員や幹部からの支持を得続けることがプロジェクトの成功に必須です。企業幹部にも、当然ですが、プロジェクトに対する義務感と責務感を持ってもらわなければなりません。プロジェクトへの協力義務について、社長や役員の口から折に触れて全社員に繰り返し発言されるようにITコーディネータが仕掛けることも大切です。
１）と２）について： プロジェクトの目的と方針はプロジェクト完遂まで絶対にぐらつかせてはなりません。事前に十分な議論と意識合わせをITコーディネータが社長および担当役員と行っておくことが大切です。またプロジェクトの途中でも目的と方針の再確認を社長以下と繰り返し行います。プロジェクト遂行の途中で必ず抵抗勢力が現れます。それをはねつける力を推進者はあらかじめ用意しておく必要があります。目的と方針の固守はそのための非常に重要な要素です。プロジェクトへの非協力的な姿勢、非協力社員は個人の人事的評価に悪影響を受けることをさえ社員と管理職に認識させる場合もあってよいと思います。
３）について： プロジェクトに直接参加する実務メンバーは社内で広く認知されるようにします。核となるプロジェクトメンバーは社内各部署の実務キーマンとうまくコミュニケーションの取れる専任者であるべきです。企業内各部署からも、兼任でよいから、部署要求を整理しまとめる責任を負う担当者をプロジェクトに加えてもらいます。
４）について： 工程はリーズナブルである限り厳しい短期工程を設定し、かつプロジェクトメンバーで工程厳守の高い認識を共有します。これによりプロジェクトは常に緊張感を保って進められます。また、短期間であることは導入予算低減させるためにも非常に有効です。
５）について： 概略予算は、調査により同規模他企業の事例を参考にセットします。他社事例を調べることは、ここで示す予算に説得力を持たすために必要なことです。プロジェクトに用意できる金額が他社事例の金額と比べて桁違いに合わなければ、計画を白紙に戻して組みなおすことが賢明です。
５．対象業務の分析 ・・・・・ ERPで何をさせるのか把握する ・・・・・
このフェーズではERPでカバーされるべき社内業務を分析し文書化しました。これをここでは「業務プロセス分析書」と呼びます。今回の場合、プロジェクト立上げ後1ヶ月をかけて業務プロセス分析書を作りました。
業務プロセス分析書では、現状の業務とあるべき業務をフロー図などに図式化します。この目的は、ERPで何を行わなければならないか、行わせたいか、ERPで何をさせるのかをプロジェクトメンバー全員が知るためです。ERPを導入し始めたものの、何をさせたいか具体的要求を表現できず、一方で「使いにくい」の大合唱に遭遇し、結局ERP導入が途中頓挫することはよく起こります。社内業務のどこをERPというツールに頼るのか、メンバーが認識を共有する必要があります。そのための図書が「業務プロセス分析書」です。ITコーディネータはこの文書作成を指導し、監査し、まとめさせます。フローは、通常多部門間にまたがる形になるため、部門それぞれがどのタイミングでどのような処理をするか記述させます。一例として、受注から設計、製作、納入、調整、完成検査、検収、売上げにいたる一連の社内業務プロセスがありました。
業務プロセス分析書に対しては、自らが作った要求という意識を対象全部門とプロジェクトメンバーに持ってもらいます。業務プロセス分析書をITコーディネータが勝手に作ったとか、自分たちは内容をよく理解していない、などと言わせてはなりません。自分の責任で作った自分たちのための分析であるという意識を企業の全部署に持たせるよう誘導します。
なお、業務プロセス分析書において、いくつかよくある異常処理（例： 返品、紛失、クレーム処理、受注前の先行処置、など）にも触れておきます。この時点ですべてを記述する必要はありませんが、不完全でも異常処理を認識しておくことが重要です。
６．RFP作成とベンダー評価 ・・・・・ ERPベンダーの知恵をフルに使う ・・・・・
次にERPベンダーに対してRFP(Request For Proposal)を提示しました。ここでRFPの内容とは、前フェーズで作成した企業の業務プロセス分析書です。ERPベンダーの中から企業規模や実績、知名度からいくつかの候補を抽出し、そこに対して業務プロセス分析書を説明します。ERPベンダーには、当社が説明した業務を自社製品を使ってどう実現するか提案させました。このフェーズに2ヶ月を要しました。
これは非常に重要な進め方です。一言にERPといっても多くの製品が市場に溢れており、その中のどれが自社の業務に合うか使う側（顧客企業）やITコーディネータが自分で判断することは非常に困難です。業務分析書をERPベンダーに提示してベンダー側に考えてもらうことが時間の節約と正しい評価に非常に有効です。
このフェーズでは次のようにプロジェクトを進めました。
１） ERPベンダーからの提案書と見積書の提出
２） 1次評価をして選考対象を絞ること
３） 選考に残ったERPベンダーの製品を用いたデモ
４） ERPベンダーの製品を既に導入した企業への訪問調査
５） 予算と社内事情を考慮してERPでカバーする業務範囲の見直し
６） ERPベンダーへの追加質問、見積範囲のレベルあわせ
７） ERP評価表作成
１）について： ERPベンダーからの提案書には、どの範囲が当該ERPの標準機能によってカバーされ、どの範囲にアドオン（＝追加開発）が必要かを明示させます。いわば荒いフィット／ギャップ分析をここで行っていることになります。言うまでも無く、アドオンが多ければ多いほど初期導入の費用が増加します。期間も余分に必要となります。アドオンされた部分でのバグ検証などシステムの信頼性も落ちます。導入後のメンテナンス、バージョンアップにも手間と時間と費用が余分にかかります。したがって、可能ならばアドオンなして導入できることが望ましいはずです。
２）について： 選考対象を絞るのは、これ以降のフェーズでの評価の手間と日数を少しでも少なくするためです。
３）について： デモでは業務プロセス分析書に沿った業務イメージを各ERPベンダーに製品を使って実際に示してもらいます。各部署から派遣された兼務のメンバーも必ずデモに出席させます。このERP製品の評価のフェーズにおいても、限られたプロジェクト専任メンバーだけでなく、各部署からプロジェクトに入ったすべてのメンバーに参加意識を持たせる必要があります。そしてそれぞれのメンバーに判断を示させます。後のフェーズで、「自分の知らないところでERPを選んだ」と言わせないための重要な手順です。
４）について： 導入企業訪問では、ERPの評判、導入時に生じた問題、問題に対する対策の工夫など、後フェーズで有効な情報を集めることができます。オリジナルのERPに問題があるとして、それをどのようにクリアできるのか目処を立てることも製品評価の項目の一つとなります。
５）について： ERPベンダーのデモや仕様、価格など総合的に判断して、本プロジェクトでどこまでの業務範囲をERPでカバーするか決断します。予算、期間、業務プロセス分析書とのギャップ、などを考えます。すべてのERPベンダーの提案で「業務プロセス分析書」とのギャップが大きいプロセスがあれば、今回の対象業務範囲から思い切って除外する決断も必要です。
６）について： 見積範囲の精査など細かな詰めは専任メンバーとITコーディネータの連携で処理します。レベル合わせのための見積範囲調整、追加質問などを行って公平さを確保し、また技術課題の対処方法も提出してもらいます。
そして、７）のERP評価表を作成します。
７．ERP評価表とベンダー決定 ・・・・・ 目的/方針を固守しつつ決める ・・・・・
いよいよ導入するERPの選択について意思決定を行う段階となりなます。
評価項目は次のようなポイントとしました。
１） 価格
２） 当該ERPの特徴と今回の導入方針や目的との合致度当該ERPを選ぶことが、固持すべき当初方針や目的に合致した選択となるかどうか。
３） アドオンのソフト製作量の大小、およびフィット／ギャップの評価。ERPの仕様や機能に要求との差異や問題がある場合にはその解決方策と費用・工期の概要
４） 製品デモに対するプロジェクトメンバーからの評価
５） ベンダー技術者の経験、資質と人数（＝人的動員力）。ERP構築時に万一問題が発生した場合、要員を増強してリカバリーできるポテンシャルを評価する。
６） ベンダー企業とERP製品の継続性。ベンダーが倒産する、ERP製品へのサポートを止める、などのリスク評価。
これらの評価表を作成し、まずプロジェクトメンバー内での意識統一を行います。これも、「他のだれかが勝手に決めた。」という意識を持たせないためです。プロジェクトメンバーその意識合わせに基づいて書面にし、社内承認手続きを行います。
８．ERP選定までの結び
以上が、ERP選定までに踏んできた各フェーズと進め方のポイントです。筆者の場合には、プロジェクトの立上げを宣言してから社内承認まで4ヶ月を要しました。選考対象としたベンダーは、当初6社程度。本格的な提案要請は3社に対して行い、最終選考は2社に絞りました。
内容を見ていただくとわかるように、プロジェクトの立上げ、業務の分析、RFPの作成、ベンダー決定、それぞれに若干の工夫をしつつも、当たり前のことを手順を踏んで行ったに過ぎません。冒頭に述べたとおりです。目的や方針を振れさせたりせず、プロジェクトメンバー全員の当事者意識を維持しつつ、当たり前の手順や行動を着実に実行することがプロジェクトを成功裏に完遂するために必要であることを、改めて強調しておきたいと思います。
ITコーディネータ 松下 悟 （まいど！フォーラム メンバー）
