１．はじめに?
本稿は、筆者が経験したERP導入を振り返ってその成功要因（CSF）をまとめたものです。今回は「その２」として、導入するERP製品が確定した後のフェーズ、つまり実際に導入に取り掛かるフェーズから、仕様決定フェーズまでを扱います。?
２．構築プロジェクトの立上げ 〜再びプロジェクトとその方針を周知させる〜?
ERPを納めるベンダーと契約を取り交わし、いよいよERP導入プロジェクトがスタートしました。改めてプロジェクト立上げを社内で宣言し発信しました。宣言にはERP選定フェーズの開始時と同様に次の項目を含めました。
１） ERP導入の目的（原価管理の精度改善、仕掛り品の減少、など）
２） 導入方針（システムを導入して自社の業務プロセスを改善する、など）
３）社長をトップに置いたプロジェクト体制と実務メンバーの明示と周知
４） カットオーバー日を明示した工程
５）概略の予算
このような宣言の目的は、言うまでもなくプロジェクトを全社員に認知させ、その目的や方針を周知しておくことです。プロジェクトが進んでいってシステムの使い方が説明されると、社員が行わなければならない業務への直接影響が明らかになってきます。その段階では、「そんな面倒くさいことになるの？」といった声が必ず上がってきます。その前に、あらかじめ目的や方針を繰り返し何度も発信しておきます。
例えば正式な受注書面を客からもらう前に何かの資材を先行して発注する、といったルール無視が散見されているとします。それに対してERPという仕組みを嵌めてしまうことで、ルール違反をできなくする訳です。ERPによって「プロセス改善（適正化というべきか）」という目的に沿い、業務の進め方を変えさせることを実現していくわけです。いずれ実務者からはいろいろな例外処理に対応するよう要求が出てきます。その多くはYesともNoとも言える事項です。その事態に備えて、導入目的や方針という原理原則を繰り返し明示します。無理な要求に対してはプロジェクトとの目的との不整合を理由に拒否することができるよう、プロジェクトの開始時から繰り返し周知しておきます。
プロジェクトメンバーは専任者と各部門から出された兼務者で構成し、だれがプロジェクトメンバーかも様々な機会を用いて社内に周知しました。これは選定フェーズと同じです。カットオーバーの目標日も大きく掲げます。いくらの費用をかけてERPを導入するかも概算額を周知しました。「失敗するとこれだけの費用が無駄になるよ。」ということを社員に知ってもらうためです。?
３．プロジェクト全体の工程 〜関与させたい人に逃げられないように仕組む〜?
これから、フィット＆ギャップ分析、仕様決定、製作、データ移行準備、教育、システム切替試行、システム切替、切替後のサポート、の順序で工程が進みます。
最初のフィット＆ギャップ分析では、各部門からの兼務者に対してデモを見させるなどして意見を出してもらうことが必要です。「わたしが仕様を決めた訳ではない。」と、あとになって逃げ口上を言わせてはなりません。デモを見てもらうために、短期間でもプロジェクトに専念してほしい時期や日数をあらかじめ要求しました。役員などを含めて兼務者の上長にもこの件を依頼しておきます。プロジェクトでは短期間で仕様を固めるために、限られた日程でデモなどの日程を組まざるを得ません。他の業務によって結果的にデモに出席しないメンバーが出てこないよう、前もって布石を打つことは重要です。?
４．ギャップの把握（フィット＆ギャップ分析（１））
〜ストーリーを作り操作イメージをチェックする〜?
フィット＆ギャップ分析を行ってシステムの仕様を決めていきました。今回のプロジェクトではERPベンダー選定の段階でも一度粗いフィット＆ギャップ分析を行いました。再度、ベンダーにデモをしてもらうに際して、以前にスキップしたこと、現実に業務で生じる異常ケースなどを社内各部門から来ている兼務者（プロジェクトメンバー）に出してもらいます。それをもとにデモを行うときのストーリーを作りベンダーでストーリーどおりのデモを準備します。その上でプロジェクトメンバーを集め、ストーリーに沿って、オリジナル仕様のERP上でどのような動きになるか、実務でどれほどの業務作業になるかを関係者に見させます。その結果、「画面が複数になって作業性が悪い」とか「その数値を入力するときには同じ画面にこの情報が必要」、といった声が出されるわけです。
分析の結果は、次のように分類しました。
１）ERPオリジナルの仕様で導入するもの
２）ERPの中にアドオンで開発して組み入れるもの
３）ERPとは別のソフトウェアで画面や機能を作るもの?
もちろん、できる限り１）で対処して社員に使ってもらうのが望ましいです。当初からの目的と方針に沿って判断しても、どうしてもオリジナル仕様では不都合な場合や煩雑さが我慢できない場合のみ、２）もしくは３）での解決を図ります。
例として、「月次の経理作業を行う際に、旧システムでは1画面で済んでいた作業が多数の画面にまたがってしまう、しかも処理すべき件数は毎月多数発生する。」というコメントに対して、オリジナルを我慢して使ってもらうべきでないと判断しました。アドオンで対処しました。
別の例として、部署ごとに異なる複雑な上長承認の流れがありました。普通に組織ツリーに従って順に上位者の承認を取る部署もあれば、途中で工務部門のチェックを通す部署もあります。これらにいちいち対応させてシステムのワークフローを組むことは面倒で、いつまた組織変更などで手を加える必要が出るとも限りません。この問題に対しては、指定用紙を準備するなどしてペーパーで承認ルールを補うこととし、システムでの対応は行いませんでした。
１）、２）、３）に分類した結果はまとめてプロジェクトメンバー全体で協議し、その結論に対して一人ひとりに責任意識を持ってもらいました。これは、兼務者が自部署のメンバーから「使いにくい」とクレームを受けたときに、兼務者自ら仕様を決めた過程を相手に説明し、自部署を納得させてもらうためです。このあたりもプロジェクトの統制を維持するために大切なステップです。
?５．ギャップ対策あれこれ（フィット＆ギャップ分析（２）） 〜安く安全にギャップを埋める〜
ギャップ対策は千差万別です。ここでは、そのテクニックを取り上げます。
対策として取りうる方法は上記のように、２）アドオンか３）別ソフトウェアを利用する、です。一般に費用を考えると一般に２）は高くつきます。アドオンで画面を増やすことは、単純な画面であっても高額の変な費用を通常ベンダーは要求してきます。また、ERPがバージョンアップされるたびにアドオン機能への影響を考慮しなければなりません。
一方、ERPにはたいていの場合、標準機能で外部システムとのデータ送受機能が備えられています。そのインターフェイス機能を利用して、別のソフトにERP内部の数値を書き出したり、別のソフトからERPへデータを書き込んだりすることができます。この方法は、ソフトを製作するプログラマがそのERPに詳しくなくとも製作に携わることができ、一般に２）よりも安く多くの画面/機能を作りこむことができます。筆者の経験したプロジェクトの場合、このやり方でギャップを相当部分クリアすることができました。ERP標準の外部インターフェイス機能だけを使っておくならば、ERP本体がバージョンアップされる場合でも影響は少ないでしょう。つまり、将来出てくるであろう改造が必要な場合でも、費用も抑えられると考えられます。ERPを導入したが、数年後バージョンアップに際して多額の費用を請求されて困った企業も多いはずです。
止むを得ず２）を実施する場合ですが、そこでも内部機能的なアドオンはできるだけ避けます。単純なアドオン、画面など目に見えるアドオンに絞ります。これも費用追加と後々のトラブルを少なくするためのテクニックです。
これらの検討を行うために、当然ベンダー技術者との綿密な相談、調整が必要となります。フィット＆ギャップ分析で抽出したギャップを、このフェーズでは一つひとつ丁寧に解決策を決めていきます。?
６．仕様決定まで?
フィット＆ギャップ分析の結果を分類し、ギャップ対策には具体的な処置方法を用意して、仕様を決定しました。繰り返しになりますが、決定された仕様についてメンバー１人ひとりに「自分が決めた」と言う意識付けを要求します。決定仕様を元にベンダーとの最終価格を決定することができます。この時点で、予算に対して実際いくらでERPが導入できるか確定します。社内承認を経て、いよいよシステムの製作に入ります。?
７．仕様決定までの結び?
以上が、仕様決定までのフェーズでの経験です。ベンダーとの契約後、再度プロジェクトの立上げを宣言してから仕様決定まで２ヶ月を要しました。このあと、専任者を中心にシステム製作の期間に入ります。
本稿（その２）で扱ったフェーズにおいて大切なことは、
１）使う場面をストーリーにし、
２）それに沿ったデモをERPのオリジナル仕様で行わせ、
３）そのデモをプロジェクトメンバー全員で評価させること、
４）目的/方針を固守しつつアドオンを最少化すること、
５）安価なギャップ対策に知恵を絞ること、 です。
プロジェクトの目的や方針を振れさせたりせず、当たり前の手順や行動を着実に実行することがプロジェクトを成功裏に完遂するために必要であることを、ここでも強調しておきたいと思います。
以上
