引き続き、『ERPの導入プロセス』を説明する。頑張って理解しよう。
プロジェクト運用ルールの策定
プロジェクトの運用ルールとは、なんだろう？
例えば、
- 進捗会議の開催ルール
- 課題の管理方法
などがある。
ご存知のように、プロジェクトでは、決めた期間で決めた目標を達成することが求められる。
ERP導入のように基幹業務システムを再構築する場合、プロジェクトの進め方も、成功と失敗を左右する要因の一つになる。
“失敗する要因は、いくつぐらいあるんですか？” ⇒ たぶん ∞ （無限大）だ。
進捗会議の開催ルールの例を、書いてみる。
- 日時 － 毎月１回、最初の木曜日、時間は15～17時
- 場所 － 本社ＸＸ会議室
- 出席者 － プロジェクト推進関係者 Ａさん、Ｂさん、…
- 議題 － 進捗状況の確認、前回までの課題への取組状況、など
開催の日時をあらかじめ決めておくことで、参加者のスケジュールを確保する。
（参加者の出席できない言い訳を防ぐ意味も込められている。）
場所は、出席者の勘違いを防ぐ意味でも、同じ場所を使うことになる。
私は、社内の会議室ではなく、近くのホテルの会議室を長期間契約して開催したことがある。
確実に、同じ会議室を確保するためだった。
会議中の参加者への割り込みを防ぐためにも有効な方法だった。
（スマホも留守電にしたいところだ。営業担当者以外は...）
参加者は、次の方々で構成される。
- プロジェクト・オーナー（経営者）
- ERPの導入で影響を受ける部門の責任者 （意思決定機関のメンバー）
- プロジェクト・リーダー
- 事務局
- プロジェクト・メンバー（各部門の現場のキーパーソン）
- ERPコンサルタント（全員）
2. は、 “ステアリング・コミッティー” とも呼ばれている。
尚、できるだけプロジェクト・オーナー（役員以上の役職者）の参加を求めるべきだ。
但し、オーナーが出席しないと会議の運営に支障が出るようでは、リーダーの力量が疑われる。
リーダーは、会議までに資料を準備しておく必要がある。
最近では、紙で印刷した資料は配らずにプロジェクターだけで済ますことがあるかもしれない。
だが、それでは、出席者は思いついたことを書き留めることができない。
なので、資料は紙でも準備することを、お勧めする。
ここで注意しないといけないのは、資料の準備には思ったよりも時間がかかるということだ。
私の実体験だが、前日の夕方の時点で資料が１ページもできていなかった。
（もちろん、材料は、頭の中にはそれなりにあった。）
私： 資料が全然できてないので、明日の進捗会議は延期しようかな～
物流の責任者： 延期したらいいヨ ← 無責任… 本当は思いやり！
実際には、前日の夕方から３０ページくらいの報告書を日本語と英語で作成し、当日は、参加者を２０分位お待たせして... 開催したことがある。
人数分の資料の印刷に３０分以上もかかってしまった。 反省...
ちなみに、ERPコンサルタントの一人は、びっくりしていた。
なぜなら、前日の夕方の時点で、資料が全くできていないことを知っていたからだ。
解決すべき課題は、エクセルなどで管理して全員で共有化する必要がある。
期限までに対処しているのかアクションが遅れているのかが一目でわかるようなレイアウトする。
“実行待ち”、“ＸＸまで終了”、“完了” などと、進捗状況を把握する。
“ＹＹ％ 終了” と ％で管理すると、いつまでたっても “９０％ 終了” から進まないことになる。
９９％、９９.９％、９９.９９％、… ウサギは、亀に永遠に追いつけなくなってしまう。
なので、どこまで終わったのかがはっきりわかるように、タスクを進捗管理に適したレベルまでブレイクダウンすることが肝心でだ。いわゆる、WBS（Work Breakdown Structure）だ。
マスタースケジュールの策定
マスタースケジュールは、毎月の進捗会議までに更新することになる。
全体の進捗が進んでいるのか（めったにない！）遅れているのかを、関係者全員に報告することになる。
マスタースケジュールには、以下の項目を含める。
- タスク（仕事）名
必要な仕事を、進捗管理ができるレベルまで分解して名前を付ける。 - タスク毎の日程（開始日と終了日）
無理な日程は、結局プロジェクトを失敗に導く要因になる。 - 担当者
複数の担当者が関わる場合があるが、責任者を決める必要がある。 - マイルストーン
プロジェクトの節目を、マイルストーンとして設定する。
マイルストーンの期日を決めてから、タスクの日程を割り振ることになる。 - クリティカルパス
これは、PERT(Program Evaluation and Review Techniqueの頭文字) で使われる概念だが、そのタスクが遅れるとプロジェクト全体のスケジュールが遅れることになると言う意味で、重点的に進捗を管理する必要があるタスクのことだ。
以上の内容は、マイクロソフトの “MSプロジェクト” というソフトで一元管理できる。
プロジェクトリーダーは、プロジェクトを管理するために、MSプロジェクトなどのプロジェクト管理ソフトに習熟する必要がある。
採用するERPの理解
プロジェクトリーダー、事務局、部門の代表であるキーユーザーは、ERPのメーカーが開催する講習会に参加する。
まずは、プロジェクトリーダーと事務局のメンバーが参加する。
事前に参加することで、キーユーザーが参加する前に講習会の内容を評価する。
評価結果に基づいて、講習会の講師に自社のキーユーザーが参加する際の留意点などを、あらかじめお願いする。
次に、キーユーザーが参加する。
ERPを使うことになるユーザー全員が参加することが望ましいのは、言うまでもないが...
ERPの外部講習会は、結構な値段する。５日間で３０万円とか...
ここで大事なことがある。
ERPの外部講習会に参加して、参加後の復習を通して講習内容をきちんとものにするには、その講習に関する業務知識を “事前” に身につけていることが肝心だ。
リーダーが会計モジュールの講習会を受講しても、簿記の知識がないと習得できない。
生産管理のキーユーザーが生産管理モジュールの講習会を受講しても、MRPの知識がないと習得できない。
つまり、ERPベンダーの講習会は、受講者が、その分野の業務知識を十分に持っていることを前提にしているのだ。
尚、リーダーや事務局のメンバーは、販売管理などの業務アプリケーション向けの講習以外に、システム管理、外部とのインタフェースの仕組みなど、ERPの運用管理者向けの講習会にも参加することになる。
ところで、IT部門の責任者ではなく現場の責任者がリーダーになることがある。 IT部門には任せておけないというわけだ。
IT部門の責任者が、業務を理解していない場合は、その選択肢もありと思うが、ERPはITの塊であることを、忘れないでください。
ERPの経営への活用は、ERPを導入して本番稼動した時点から始まることにも留意してください。
ERPの本番稼動を持ってプロジェクトが終わるERP導入プロジェクトは、その後のERPの経営の活用に必要な継続的な業務改革が必要であることを踏まえると、リーダーは、IT全般に精通しているIT部門の責任者が最適、が私の見解だ。
上記の内容は、『ERPの導入プロセス（１）』 の “プロジェクトリーダーの任命” で説明した方がよかったのかもしれない。
閑話休題、『ERPの導入プロセス』 に含まれる項目だ。
現状の業務分析
- 使っている伝票や帳票類の洗い出し
ERPに切り替える際に、それまでの伝票類は使えなくなる。
帳票類は、全面的に作り変えることになる。
なので、使っている伝票や帳票類の事前の洗い出し作業が必要だ。
顧客向けの伝票と社内使用だけの帳票類は、仕分けする必要がある。
顧客向けには、自社の都合だけでは変更できない伝票（指定伝票）がある。
指定伝票の場合には、それに合わせたフォーマットでデータを出力するプログラムを（ERP以外のソフトを使って）作る必要がある。
社内使用だけの伝票や帳票は、データで伝達する方式に切り替える必要がある。
データだと一元管理できるので、業務の生産性が向上することになる。
ついでに、紙を保管するスペースもいらなくなる。
コード体系などの変更が必要な項目の洗い出し
ERPへの切り替えは、勘定科目や品目マスターなどのコード体系の見直しや、各種リードタイムの精度向上を行う絶好のチャンスだ。
桁数が多い勘定科目コードを使っている場合は、ERP側の桁数の制限で全面的に見直すことになるかもしれない。
品目マスターの桁数が多い場合にも、見直し作業が必要になる。
マスターファイルの再設計は相当の作業量になるが、この機会を逃すと後で後悔することになる。
突然だが、ここで Attention！
これらの作業を手抜きすると、業務改善の絶好の機会を失うことになる。
マスターファイルの整備に取り組まなかったために、出力されるデータが信頼できず、本来のERPの力を活用できていない企業が多いのは、残念なことだ。
私の実体験だが、その企業では、導入したERPを、８年間使っていた。
ところが、品目の調達リードタイムや製造リードタイムのデータを、前のシステムから持ってきて、そのまま使っていたのだ。
古いシステムと新しいシステムの製造リードタイムが同じとは...
お客様からの納期の問合わせに、一体どうやって回答するのだろうか...
ERP稼働環境の構築
ERPを導入する場合、ERPを動かす環境が必要になる。当たり前だが...
- ハードウェア機器の選定／調達／設置
設置場所の確保、電源の供給など、IT部門の仕事だ。
※ 今どきは、AWSなどのクラウドを採用すると思う。 - ソフトウェアの選定／調達／設置
ＯＳやデータベースなど、採用するERPで決まる。 - 情報ネットワークの整備
IT部門の仕事だ。 - ERPの調達／インストール
ERPの稼働環境は、最低でも３つ必要だ。本番用、開発／検証用、トレーニング用。
ユーザー毎／部門毎に使える機能を制限する必要がある。
いわゆる “セキュリティーの設定” だ。 内部統制には、必須の機能だ。
ユーザーは、トレーニング環境を使ってERPの使い方に習熟することになる。
プロジェクト予算の確保
プロジェクト予算は、会社の方針に関係するが、売上のＸ％という指標で予算を決めている場合もある。プロジェクトを推進するプロジェクトリーダーの仕事だ。
ちなみに、プロジェクト管理では、QCD（品質、コスト、納期）が管理ポイントになる。
現実には、プロジェクトメンバーの動機付けの方が、よほど重要だ。
QCDは、メンバー全員が頑張った結果でしかないからだ。
予算確保での留意点は、２つある。
- ERPの保守費用
（割引前の）定価のＸＸ％という決め方をする。 - ERPのバージョンアップコスト
ERP選定時の評価項目に含める必要がある。
これらは、ERPを導入した企業が不満を持つ代表的な項目だ。
毎月の進捗会議
進捗確認では、
- その時点での進捗状況や課題をプロジェクトリーダーが報告
- 前回までの課題への取り組み結果の報告
- 新たに発生した課題を取り上げて対策を議論
- 次回までに行う行動の確認
などが、議案になる。
時々紛糾することがあるだろうが、そんな時こそプロジェクトリーダーの腕の見せ所だ。
私、リーダーとして工夫した点に “危機意識を発信する” という仕組みがある。
カードを３枚準備して、会議の最後に、リーダーとしての本音での現状認識を提示した。
・緑色 － 順調、成功を確信している
・黄色 － 問題あり、早急な対策が必要
・赤色 － 問題が解決されておらず失敗に向かっている
ちなみに、赤が２回続くとプロジェクトが頓挫する可能性を意味する。
私には、そのような実体験は、ない。（念のため記載する。）
フィット＆ギャップ分析
フィット＆ギャップ分析では、次の作業を行う。
- 現状の業務の仕組みとERPでの仕組みの相違点を明らかにする。
- 違い（ギャップ）がある業務については、ERPの標準機能に合わせるのか、追加開発して業務に合わせるのかを決める。
尚、ERPの導入方法論 を適用する場合には、F&G分析は行わない。
Attention Please！
ERPコンサルタントがERPに精通していないと、パラメータの設定、またはオプションモジュールで実現できる機能なのに “このERPではできません” という判断をしてしまい、顧客側に追加開発を提案することが、結構あるようだ。
予算超過の典型的な原因で、お金をどぶに捨てることになる。
この点は、２つ後の “追加開発ソフトの開発” で、もう一度説明する。
ところで、ユーザーからは、今までの仕事のやり方を変えたくないので、たくさんの追加開発を要求してくる。特に、画面のレイアウト回りで数多く発生する。
その場合、“追加開発は行わない” という方針に戻り、追加開発しないと、どこにどのような問題が生じることになるのか検証する、というスタンスで対処することだ。
- 法的に問題になるようなら外せない。
- 商習慣は、検討の余地がある。（※）
※ 手形を廃止した実例がある。 - 重要なお客様からの要求の場合も受け入れざるを得ない可能性が高い。
- 他社との競争上、省けない機能があるかもしれない。
【部分最適ではなく全体最適】、【仕組みの柔軟な変更】 の視点が必要だ。
尚、ギャップがある業務処理をERPの標準機能に変える場合、部門責任者との十分な協議・承認、関係者への事前連絡が大切だ。
関係者全員からサインをもらうくらいのつもりで、事前の合意形成を行う必要がある。
ちなみに、私は、フィット＆ギャップ分析を短時間かつ的確に行うために、会社全体の業務プロセスを可視（見える）化した業務フロー（※）をあらかじめ作成しておき、ERPコンサルタントが現状の業務の流れを短時間で理解できるやり方にしている。
あるべき（失敗を少しでも避けて、迅速な）ERP導入の進め方を、自分で考えた結果だ。
とは言っても、ERP自体が持っている業務プロセスの全体を理解していないERPコンサルには、猫に小判だが...
※ 業務フローの作成方法については、 『ERPと業務改革との関係』 で説明している。
パラメータの選択／設定
ERPを導入する際は、採用したERPが提供している多数の選択肢から自社向けの選択をするという作業がある。
その作業を通じて、業務のルール決めや業務フローの決定を行う。
例えば、減価償却の方法として “定額法” にするのか、“定率法” にするのか選択する。
この作業を、“パラメータの設定” と呼んでいる。
システム開発に例えれば、現場のキーユーザーと話し合いながら仕様を設計する工程に相当する。
前項のフィット＆ギャップ分析を行う際に、ERPコンサルタントと現場のキーパソンが、協同作業でパラメータの意味を確認しながら選択していく作業だ。
パラメータを選択する際のキーユーザーの仕事は、
- 一つひとつのパラメータの意味（機能）の理解
その結果として、そのパラメータの要／不要の判断
選択したパラメータで、現実的に運用できるのかどうかの判断 - 業務改善／業務ルールの変更が必要かどうかの判断
などを、時間をかけて慎重に行う必要がある。
この辺の内容は、もろにERPの導入方法論（メソドロジー）になるので、少しわかりにくいかもしれない。
このパラメータの設定作業には、パラメータの数が多いERPの場合、膨大な時間がかかることになる。
なので、業界や業種に応じてパラメータをあらかじめ選択しておいて、“テンプレート” として提供しているERPベンダーが増えている。
追加開発ソフトの開発
☆ 帳票の作成
帳票は、ERPが提供している帳票作成ソフトは使わない方が無難だ。
なぜなら、融通が利かないし、少しの手直しでも外部業者に修正を依頼することになり、コスト高になるからだ。
帳票作成は、帳票作成専用のソフトを別途購入して、そのソフトで開発する方が、早く、安く開発でき、開発後の修正も、早く、安くできる。
追加開発で注意しなくてはならないことの一つに、“ERPが持っている機能を、わざわざ追加開発しない” ことがある。
“そんなことってあるの？” はい。 あります。
ちょっとわかりにくいでしょうから、少し説明する。
ERPコンサルが、そのERPについて経験が少ないと、元々ERPにある機能なのに “追加開発する必要がある” と判断してしまうのだ。
特に、大規模なERPの場合、一人のERPコンサルが熟知している範囲は限られており、どうしてもこのようなことが起きてしまう。
どうすれば、こうした無駄な投資を避けることができるのだろうか？
- できるだけ広い範囲をカバーしているERPコンサルタントを選ぶ
確かに... でも、そんなERPコンサルを見つけられますか？ - プロジェクトリーダーが、ERPと他のシステムとのインタフェースまで含めて幅広く講習会に参加して、ERPコンサルタントの間違った提案を指摘できるくらいの知識を獲得しておく。
確かに... でも、そこまで理解できる力量のある社内人材（※）がいますか？
※ そのために『ERP管理者 養成講座』を製作した。
- ERPコンサルが追加開発を提案してきたら、メーカーに問い合わせてERPでその機能をサポートしていないかどうかを確認する。
なるほど！ ERPコンサルの顔をつぶさないように注意してください。 - そもそも、一人の人間ではカバーできないようなERPは選択しない。
なるほど。一考に値する考え方だ。
☆ 他システムとのインターフェースソフトの開発
- ERPのモジュールを段階的に導入しようとすると、インターフェースソフトを大量に作ることになる。（なので、段階的導入は、お勧めしない。）
- ERPの特長の一つは、リアルタイム処理だ。
なので、ERP以外のシステムとの連携では、できるだけリアルタイム処理に近づけるような仕組みにする必要がある。
製造業の場合、技術部門からのBOM（部品表）とのデータ連携が遅れるとMRP（資材所要量計画）の計算結果が、使えない（信頼できない）ことになる。
テスト
テストが始まるまでに、マスターデータの整備（一元管理化）を終えておく必要がある。
言い換えれば、マスターデータの整備が終わっていなければ、テストは始めてはいけない。混乱を助長させるだけなので...
テストには、次のような段階がある。
- 機能毎の動きを確認する単体テスト ⇒ CRP１（※）
- 他の機能との連携を確認する結合テスト ⇒ CRP２（※）
- 他のシステムとのインターフェースまで含む総合テスト ⇒ CRP３（※）
- 本番データを使って最終的な検証をする運用（負荷）テスト ⇒ CRP４（※）
※ CRP１～４は、弊社のERP導入方法で適用する用語だ。
まずは、モジュール毎の動きを確認する。
例えば、
- 品目マスターに製品データを入力して、照会画面で確認する
- 顧客マスターに顧客データを入力して、照会画面で確認する
- 購買データを入力して、照会画面で確認する
- 従業員マスターに従業員データを入力して、照会画面で確認する
次に、サンプルデータを使って業務処理のつながりを確認する。
例えば、次のような業務処理を、テストデータを使って検証する。
- 取引の発生から財務諸表の作成までの処理
- 購買オーダーの発行から納品までの処理
- 既存客からの見積りの作成依頼から出荷までの処理
- 循環棚卸の業務処理
- MRPを実行して製造オーダー／購買オーダーを発行する処理
- 製造オーダーの発行から製品入庫までの処理
そこまでの処理をキーユーザーが納得できたら、いよいよERP以外のシステムとのつなぎを検証する。
例えば、
- 技術情報システムからのBOM更新データを取り込んで生産管理モジュールのBOMを更新する
- 取引先とのEDI経由でのデータの受発信を行う
最後に、実際のデータを使って、ユーザーが業務処理の流れに沿ってデータを流して、結果を検証することになる。
ここまで終わったら、大量のデータを使った負荷テストを行う。
システムからのレスポンス（応答速度）が遅くないか検証するためだ。
私が、ERP導入まもない外資系企業に、情報システム部長として入社した時のことだ。
売掛金の消し込み処理に45分、総勘定元帳の印刷に至っては６時間もかかっていた。
現場のユーザーがどれほど困っていたことか...
ERPのハードの導入業者が、その時点で使っていた業務システムのデータを使ったシミュレーションを行い、その結果に基づいてハードを選定していたにもかかわらずだ。
テストデータの準備は、思ったよりも時間がかかる。
例えば、マスターファイルにテストデータを登録しようとして、初めて既存のマスターファイルには存在していないデータを登録する必要があることがわかったりする。
少し専門的になるが、ERPのデータは正規化されているため、手作りのシステムでよくあるような “異なったデータベースにも同じデータがある” というようなことは起こらない。
マスターデータが一元管理され、正規化されているからだ。
いずれにせよ、このテストを通じで、ユーザーは個別の業務処理や業務処理の連携の仕組みなど、ERPを使った業務処理の流れを理解して納得することになる。
新システムへの移行（計画書の作成）
新システムに移行するには、次のような仕事が必要になる。
- トランザクションデータなどの移行方針の決定
- ユーザー教育訓練計画の作成
- 新システムの運用管理方法の検討
マスターデータの移行は、比較的簡単だ。
なぜなら、マスターデータは、頻繁に変更することがないからだ。
尚、トランザクションデータは、最低２回に分けて移行することになる。
例えば、
- １回目は、本番の１週間前までのデータの移行
- ２回目は、それ以降に発生したデータの移行
ユーザー教育については、ユーザーにどうやって時間を割いてもらえるかがポイントになる。
１回のトレーニングだけで習得するようなことは、ありえない。
現状の仕事のやり方とERP環境下での仕事のやり方の違いを、丁寧に、繰り返し、説明する必要がある。
ここが不十分だと、導入しても使ってもらえなくなる。
ユーザーからしてみれば、データを入力したら自分の責任になると思うからだ。
もちろん、ユーザーの責任ではない。
新システムの運用管理は、ERPの場合には、ERPの導入そのものを行ったERPコンサルタントが運用管理を支援することは、期待できない。
なぜなら、ERPコンサルタントの単価は高く、運用が安定してくればコスト的に割に合わないからだ。
簡単な不具合なら社内の人材で対応できるような体制にしておかないと、ユーザーにストレスがたまることになる。
運用管理を外部に委託する場合には、追加開発したソフトのドキュメントをしっかり整備しておく必要がある。
ユーザーマニュアルの作成
マニュアルは、２種類作る場合が多いと思う。
- 操作マニュアル
操作マニュアルは、各ユーザーが自分の仕事をERPで行う場合に必要になる情報を記載したマニュアルだ。
例えば、入力画面とその画面の各項目へのデータの入力の仕方などだ。
ちなみに、操作マニュアルの作成者は、部門のキーユーザーだ。
- 運用マニュアル
運用マニュアルには、不具合が起きた時の連絡先、マスターデータを変更する際の変更ルール、データのバックアップのためにシステムを停止させる時間帯など、全てのユーザーに関係する運用上の情報を記載することになり、IＴ部門のERP管理者が作成する。
マニュアル以外に、現状のシステムとERPシステムでの用語の違いや、ERPシステム特有の用語などを整理すると、勘違いによる操作ミスを少しでも減らすことができる。
尚、上記のマニュアルをイントラネットで管理すると、内容を変更した際に関係者に迅速に通知できる仕組みができる。
『ERPの導入プロセス ３』 は避けたいので、もう少しだけお付き合い下さい...
ユーザートレーニング
キーユーザーには、ERPメーカーが主催する講習会に参加してもらう必要がある。
“なんとしても” だ。
たまには、読者に質問してみよう...
- ユーザーは、マスターファールの画面を見ると、入力項目の多さにたじろぐ。
“こんなに入力する項目が多いの～ 勘弁してヨ～ ”
さて、どうするか？
- ユーザーは、画面の全ての項目を理解しようとする。
すると、全ての項目の意味を理解してもらうのに、膨大な時間がかかることになる。
さて、どうするか？
データのコンバージョンソフトの開発
新旧のマスターデータとトランザクションデータのマッピング（対応付け）が必要だ。
ところで、データのコンバージョンには、思ったよりも費用がかかる。
１回だけしか使わないのに、もったいない...
お気持ちは察するが、ケチると後悔することになる。
本番稼動判定会議の開催
この仕事の主役は、プロジェクトのオーナーだ。
もちろん、プロジェクト・オーナーは、自分では判断できないので、全ての関係者に一人ずつ意見を求めることになる。
特に、現場のキーユーザーの意見を参考にするはずだ。
当然だ。失敗して困るのは、現場のユーザーなので。
でも、プロジェクトリーダーの意見を、最も尊重する。
なぜなら、全体の状況を把握しているのは、リーダーしかいないからだ。
本番稼動！
お疲れ様でした！
レスポンス（応答時間）が遅くないことをお祈りします...
さ～て、ようやく “ERPの導入” まで終わった。
ERPを経営に効果的に活用する 目的の、ようやく50％位が終わったことになる。
“エッ？” はい。 導入 と 活用 は、残念ながら相伴わないのだ。
以前使っていた『まだERPを経営に効果的に活用していないのですか？』 という標語は、既にERPは導入して使っているのだけれど、なんらかの導入ミスや導入後の継続的な努力を怠ったために、経営に効果的に活用できていないケースを想定していた。
そういう意味では、ERPを上手に “導入” できた企業の場合だけ、50％終わったと言えることになる。
ということは、ERPの導入ミスをしてしまっている企業の場合、稼動した時点では20％しか終わっていないのかもしれない。
- マスターファイルの整備は、きちんと行いましたか？
- ユーザーは、“新” 業務フローの流れをしっかり理解していますか？
- 追加開発したソフトは、お客様の指定伝票やインタフェース機能向け以外は、少ないですか？
- 運用管理の体制は、ちゃんとできていますか？
お疲れ様でした！