【ホワイトペーパー】生産管理DX ー 成功への6つの掟

生産管理 ＤＸ 成功への ❻つの掟

不良資産にしない！ システム導入の効果を最大化させ 失敗を防ぐポイント 日本の製造業の場合、売上高に対するIT投資の割合は 1～2％程度といわれているが、その大半は義務 的IT投資である。それに比して、欧米でのIT投資は売上高比の 7～8%といわれており、日本に比べて 創造的IT投資の比率が高いのが特徴である。 日本では業務に対してIT投資を行うが、欧米では製品に対してIT投資が行われる。つまり、日本では 工程管理システム、原価管理システム、品質管理システムなどの業務システムへの投資（業務軸）が 中心であるが、欧米では新製品が開発される場合の開発プロジェクト管理や新製品の告知、専用ECな どへ投資（製品軸）される割合が高いとされている。この場合、新製品が市場で当たるか当たらない かは事前に確約できないので、投資というよりも投機的側面があることも否定できない。 しかし総論でいえば、日本はIT投資に対して保守的なのである。その是非を断ずる事はできないが、 当面この流れは続くものと考えられるだろう。しかし保守的な投資であったとしても、異常を標準に 引き上げるための最低の効果創出を行えないシステムはIT不良資産である。 自社内にIT不良資産を持たないためには、そのシステム導入の方向性やプロセスを再考する必要があ る。最近でこそ、ベンダーに丸投げのシステム導入は減り、RFPを作成して、正規の競合を行わせ、 より良いシステム導入を行う場合が増えてきた。しかしそのRFPの内容は残念ながら稚拙なものが多 く、目的（創出すべき効果）と手段（システムのアプローチ）の区別がつかないものが多いように思 われる。 この中では生産管理システムに限定し、「ベンダーの提案との向き合いかたにおける留意点」を列挙 してみたい。 Page 1 IT導入効果は、業務改善の手段であり目的になりえない 1年以上のスケジュールは範囲に問題あり

１： IT導入効果は業務改善の手段であり、目的になりえない ベンダーの提案書を見ると、導入効果として「業務の見える化」「データ資産の一元管理」「BIによるデータ資 産の活用」などをあげている場合が多い。これが間違っているとは断言できないが、少なくとも見える 化やデータの一元管理、再活用は、業務改善の手段であって目的ではない。 見える化を具体例にとって説明すると、本来の「見える化」とは「可視化＋自律的改善」のセットのことであり、 PDCAのサイクルを回し、業務において改善効果を創出させるべき仕組みである。ITでは「見える化＝可視化 （PD）」であり、重要な自律的改善（CA）の提案が忘れられている。見える化とはITを利用して、在庫・工 程・原価・計画・負荷などを可視化するのだが、本当の勝負は見えた後にある。もっと簡単に言えば、見えただ けでは何も変わらないので、可視化だけでは傾向を察知できても、具体的な改善効果には繋がらない。可視化を 利用して「在庫を減らし、原価を低減し、品質を向上させ、納期を短縮する」のが本当の目的である。しかしベ ンダーの大半は、「可視化の先」（＝自律的改善）が分からない（そうした概念は持ち合わせていない）ので、 可視化を最終の効果（目的）として提案する。本当の効果とは見えた後の対策にあるのだが、ベンダーには分か らない。そして本当に分からないユーザも、何となくベンダーの提案を受け入れてしまう。 こうしたIT寄りに偏った提案は、ソリューションという概念とは程遠いところにあるものであると認識しな ければならない。真の提案とは、業務改善を通した効果を狙うべきものである。 ２： 1年以上のスケジュールは範囲に問題あり 昨今の経営を取り巻く環境の変化は著しく速度を増している。これは製品のプロダクト・ライフサイクルの短縮 を指し、同様に生産管理システムのライフサイクルの短縮を表している。中堅・中小製造業において、システム 開発期間が1年を超えるものには、原則として、計画の見直しをお願いしている。現在抱えているシステムが解 決すべき経営課題も1年単位で変わっていく現在で、システム構築に2年も3年も掛かっているのでは、出来上 がった瞬間から仕様の陳腐化は免れない。こうした場合は解決すべき課題（システムの範囲）をABC分析し、喫 緊の効果が高い範囲から1年分だけを抽出して、再計画を行って頂いている。開発期間が長いほど、それに伴う リスクは肥大し、ユーザ側の投入工数を増大させる原因となる。せっかくのシステム導入であるから、いろいろ な事を盛り込みたいのは理解できるが、システムの範囲を徒に大きくすれば、ユーザ側の負担も増大し、ある時 点で費用対効果という損益分岐点が手の届かぬ上方に転ずることになる。俗にいう、「管理倒れ」という現象で ある。 まずは1年で一番大きな課題を解決し、次年度以降にシステム化計画をローリングさせるべきである。 Page 2 同じ目的を、より小規模の体制で実現しているところに教えを請うべき

３： 同じ目的を、より小規模の体制で実現しているところに教えを請うべき 最近はシステム提案の段階で、ベンダーを決定する条件の1つとして、当該パッケージが導入されているユーザ の見学を求められる事が多い。弊社も生産管理システムの商談の中では、毎年、何度か求められる事である。し かしその時のユーザ側の担当者から発せられる「うちよりも企業規模の大きなところに導入されている例を見た い」という言葉には、いつも疑問を感じざるを得ない。もちろんユーザ担当者はこれから益々自社が成長し、相 応の規模に達した場合を想定して、自社よりも規模の大きなユーザで稼動している実証が欲 しいのだろう。 だがよく考えてみて欲しい。自社よりも数段大きな企業は、自社に無い前提条件をたくさん兼ね備えている。豊 富な人的資源、システム運用・開発専任の情報システム部、潤沢なシステム投資、完成された分業制、強固な内 部統制など、例を挙げれば切りが無い。すなわち求める見学先には、自社に無いもの持ってシステムを稼動させ ているのである。言い換えれば、自社よりもはるかに多くのヒト・モノ・カネを投じてシステム構築や運用を 行っているのであり、それを持たないユーザが見学をしたところで、刺激にはなっても教訓に はならないといえる。 であるので、「ユーザ見学に行くのであれば、同じ目的をより小規模の体制で実現しているところに教えを請う べきである」。自社よりもシステム導入や運用に投下できるリソースが少ないところが、自社の目的としている 事を実現しているならば、そこには「自社でも実現できる確証」があり、「その為のノウハウ」があるはずであ り、そうした確証やノウハウを得る事こそが、真のユーザ見学であり、それをサポートしているベンダーの能力 を評価できるポイントなのである。より大きなユーザへの見学は、まずは自社のシステム 構築をベースラインまで完成させ、それを次のステップに発展させる時にこそ活用すべきである。 大手製造業への導入実績をちらつかせ、目の前のユーザに目くらましばかりを行うベンダーには、真のソリュー ションを提供するノウハウは無いと断言してもよいであろう。またユーザ担当者もつまらない見栄を 張っては全く形式化したユーザ見学となってしまうことに留意すべきである。 Page 3 導入計画よりも、研修計画を重視する

４： 導入計画よりも、研修計画を重視する どんなに高価で素晴しい車を購入しても、縦列駐車ができない、地図が読めない、交通ルールが守れないドライ バーには高級車は無用の長物である。場合によっては凶器となり、社会に大きな害をもたらせる場合もある。残 念ながらシステムも同様である。世間にはIT不良資産といってもよいシステムが数多く存在するが、それらの導 入失敗の原因を突き詰めると、「人」に突き当たる場合が大半である。所詮、ITは経営計画を実現するための ツール（道具）であり、計画を達成するのは「人」なのである。どんなに高機能な先進の技術を導入しても、判 断を下すのは人であり、システムではありえない。システムは脇役であり、主役はあくまでも人なのである。し かしこの簡単でありながら重要な前提条件は、なかなかクリアされない場合が多い。組織を成長させることは、 組織に属する人を成長させることが不可避である事が忘れられたシステム構築が多すぎる。 要は「人」なのである。生産管理システム導入においても、ベンダーが提示する計画の大半は、導入スケジュー ル（導入計画）であり、システムを利用する人の研修計画に踏み込んで提案を行うケースは稀である。よく考え てみると、システムは使いこなす側の力量が成否の鍵を握っている。低レベルな運用担当者の下では、低レベル な運用しか実現しない。いつまで経っても所期の高邁な目的が達成される事はない。故に、生産管理システムの 導入を検討されるであれば、導入計画と合わせて、人員の育成計画（研修）をしっかりと吟味すべきと思う。シ ステム導入はいろいろな変化の動機になる。組織や企業の定量的変化の動機になる場合もあれば、定性的変化の 主たる要因になる場合もある。つまり、システムは人の変化（成長）を助長する事も、また革新的な現場作りを 推し進めることも可能なのである。 高レベルの組織は、目的意識を強く持った運用で自らを成長させながら、システムをも成長させていく。そして より高度なシステム運用が、より高いレベルへと組織を押し上げる。この「正の連鎖」こそが、システム導入の 目的の一つであると考えてよい。もちろん導入スケジュールが一つの大きなキーワードであることは間違いでは ないが、ここは高度なシステム運用に耐えうる人材の育成計画に注目して頂きたい。システムの構築に合わせて、 それに携わる人の成長の姿がイメージできているだろうか。これは非常に重要な事である。 生産管理システムを効果的に運用するために、システムを道具として駆使する「生産管理」の知識が必要である。 生産管理の知識とは、生産計画立案のノウハウ、工程管理、資材管理、在庫管理、原価計算などはもちろん、コ ストダウンや在庫削減、リードタイム短縮についての具体的なノウハウである。システムは、現状をシステム化 するのでない。現状をBPRした数年後の姿をシステム化するのである。その数年後の姿を想像するためには、現 状の適切な理解と前述したようなノウハウが必要であり、それを保持していないのであれば、学ばなければなら ない。 ぜひ提案する側のベンダーもよく考えて頂きたい。生産管理システム構築の成否の要諦は、ユーザにおける人の 育成であり、迂遠なアプローチに見えるが、実はユーザの中に高いレベルの運用者を作ることが最終的には一番 高い確率でシステム運用が成功し、ベンダーとしてのリスクは解消されるのである。成功の原理はここにある。 研修計画は導入計画よりも重いのである。 Page 4 費用対効果を見極める

５： 費用対効果を見極める 生産管理システムの構築はもちろん情報化投資であり、投資である限りは、投資した金額以上のメリットを創出 しなければならないのは当然であるが、ここで気をつけなければいけないことは、投資額の大きさに比例して、 その損益分岐点も上がるということである。すなわち過剰な投資を行えば、費用対効果のバランスは崩れて、投 資としての態をなさなくなる危険性があるということをご理解頂きたい。まず費用対効果の「費用」であるが、 ベンダーはよく「次期システム導入費用は3,000万円であり、月額リースにすれば55万程度、月額の保守料を入 れてもプラス5万で月額総費用は60万円程度です。これ以上のメリットが出れば成功です。」などという主旨の 発言をする。ユーザもこの発言に対し疑問を持たない場合が多いが、本当にそうなのであろうか。 ここでいう月額60万円は、対外的に発生する経費である。すなわちベンダーの言い分は「ハードウェア＋ソフト ウェア＋保守料＝システム投資額」という算式の上に成り立っている。しかし本当にこれは正しいのだろうか。 上記の投資額を表す公式に大きな要素が欠落しているように感じられる。欠落している要素とは「ユーザの工 数」である。システムを立ち上げるためにはマスター入力、操作研修、新業務フローの作成などユーザ作業が必 要であり、これを金額に換算するとかなり大きな金額になる場合がある。システム導入後にあまりメリットが感 じられないという場合は、得てしてこのユーザの投下工数が必要以上に増大している場合が多いと感じている。 我々の考えるシステムの原価とは、「1．ハードウェア＋2．ソフトウェア＋3．保守料＋4．ユーザの投下工 数」であり、システム設計によっては、1＋2＋3よりも4が金額的に大きく上回る場合がある。システムを構築 するに当たっては、ベンダーに支払う費用を予算化するのは当然であるが、システムを稼動させるために投下す る「社内工数計画」も明確化しておくことも重要であろう。 また、費用対効果の「効果」についても「5W1H」を明確にし、計数的・定量的な効果測定を行わなければなら ない。生産管理システムの導入によって、「いつ、誰が（どの部門）、どこで（どの業務）、何の（どの課題）、 なぜ（どのような改善行為によって）、どのくらい（金額的メリット）を目標として全社共有しておかねばなら ない。漠然とした定性的目標（在庫を削減する、リードタイムを短縮するなど）ではなく、5W1Hが明確な定量 的目標（何の在庫をどれくらい削減する、どの製品のリードタイムを何日短縮するなど）を掲げ、常に改善を訴 求することによって、初めて生産管理システム導入の効果を明確化し、情報化投資の成否の判断を行う事ができ るのではないだろうか。このあたりについてはRFP（提案依頼書）に明記し、ベンダーにも広く対応策 を求めるべきである。 このRFPの作成を適当に作成したり、コンサルタントに任せきりにしたシステム導入に、成功した事例を見 た事がない。 Page 5 提案要求書（RFP）の重要性

６： 提案要求書（RFP）の重要性 通常、生産管理システムの導入は生産管理プロジェクトを通して行われる。プロジェクトというのは、特定の目 的達成のために編成された有期限のチームであるので、期限内に所定の成果物を残さなければならない。 生産管理プロジェクトの場合、この最終的な成果物がいくつかあるが、最も重要なもののひとつが「RFP」であ る。20年ほど前にはシステム導入の商談フェーズにおいて、RFPが出てくることは殆どなかった。ユーザの窓口 担当者がベンダーと個別交渉をして、システムを導入するというパターンが大半であったからだ。しかし生産管 理システムが単に製造部のシステムではなく、ERP（企業資源計画）の一部として認識され始めてから、導入検 討は窓口担当者からプロジェクトへと移行していき、プロジェクトの合議制の中で決定されるようになってきた が、その合議制の重要な成果物が「RFP」になる。 「RFP」の本来の目的は複数ある。 1．プロジェクトの方向性とゴールを明確にし、社内で共有する 2．ベンダーの提案の範囲や方法の要求基準を明確にする 3．成文化することにより、口約束などの曖昧さを排除し、開発の混乱を避ける 4．ベンダーへの合理的な情報提供を行う 5．公正な手続きをもってシステム導入を図る などであり、全て重要な目的であるが、ここでは特に2．を重視したい。 先日、製造業のシステム担当者から、「一体、生産管理システムの値頃感はどうなっているんでしょうね？見積 の基準もよく分かりません。」という愚痴を聞いた。この会社ではこのシステム担当者が窓口になって、システ ム導入を検討してきたらしい。最終的には、この担当者が適当と考えたベンダー3社に見積提出を依頼したが、 結果、A社は2,000万円、B社は5,000万円、C社は9,000万円だったそうだ。担当者はあまりの見積金額の差に唖然 としてしまい、未だにベンダーを決めることができないでいる。この話は決して、この製造業 に限った話ではなく、また生産管理システムに限った話でもなく、世間一般、IT一般にありがちな話である。 この担当者に「RFPは作成しましたか？」と尋ねたところ、答えは「NO」だった。この担当者が言うには、ま ず情報収集をして、実績豊富なパッケージをピックアップし、5社のベンダーのデモンストレーションを見た上 で、自社に適合しそうなパッケージを3社選択。その上で選んだ3社から個別のヒアリングを受け、ベンダーの質 問に答え、見積の提出依頼をしたとのこと。一般的にありがちな手順である。 しかしこのありがちな導入パターンには2つの問題がある。第一に「プロジェクトが編成されずに、担当者が主 体となりシステムの検討を行っている」ことである。端的に言うと、この手順では新しいシステムの導入が「全 社的な命題」として捉えられていない状態であり、限りなく「担当者の業務命題」になっているということであ る。もちろん担当者は経営者の指示を受けて、窓口を担当しているのであろうが、生産管理システムの導入は、 あくまでも全社的命題として、全部門を代表する「プロジェクト」で検討するべきである。一担当者が分かりう る範疇だけで決めるほど、小さなことではないのである。企業としての解決すべき課題やあるべき姿がぼんやり とした状態でシステム導入を行っても、大きな効果は出ない。システム導入に取り組むのは企業であり、担当者 ではないのである。 Page 6 提案要求書（RFP）の重要性

第二に「RFPが作成されていないこと」が大きな問題である。担当者はA・B・Cのベンダーから個別のアプロー チを受けた。各ベンダーに問われるままに回答を行った。もちろんベンダーから受ける質問は、各社で内容が異 なっていたし、面談した時間にも長短があった。この状態において、システム提案の主導権は既にベンダーに あったといえる。担当者にすれば、ベンダーの提案に主体性を持たせるためにも、自社からの強力なアピールを 行わなかったのであるが、最終的に、強い押し出しのない提案要求は各ベンダーの提案に対する温度差（誤解） を生じさせた。 「面談した時間が多いベンダーほど、見積価格が高かったのではないでしょうか。」という質問に対して、この 担当者は肯いた。ベンダーはヒアリングの中に出てきた要求に対しては、基本的に全て対応しよ うとする。ヒアリングする時間が多ければ多いほど、対応すべき仕様は増える。これは話を聞いたベンダーが 「深読み」をするからであり、深読みは「赤字プロジェクトを回避したい」とのベンダーの深層心理であるとい えるからだ。だから話を聞けば聞くほど、見積もる範疇は肥大化するのである。今回、C社が一番深読みをした ということだが、実はこうした深読みの類の大半は「担当者個人の思いや想像」であり、「全社的な共通認識化 された要望」であると言い切れないものが多いのである。 また「あるべき姿」でなく、「現状」の説明に終始している場合も多い。こうした問題を解決するためには、ベ ンダーとの交渉の主導権をユーザ側が握らなければならない。そのためには個別のアプローチはできるだけ排除 し、ベンダーに対して等距離で接するべきである。そのためのツールが「RFP」であると思う。「RFP」を作成 する段階で目的や規模、仕様の核をユーザ側で共有し、その結果を「RFP説明会」でベンダーに伝える。非常に 分かりやすい手続きである。 ベンダーにも寝技が得意な（寝技しかできない）営業は「RFP」を嫌がるが、こんなベンダーは排除して構わな い。全社的命題を解決するためのシステムは、より公平に、より合理的に、そして堂々と検討しなければならな いのである。「RFP」＋「正しい提案評価の基準」があれば、システム導入は半分成功したのと同じである。 「RFP」という聞きなれない言葉に惑わされるユーザもいるが、「RFP」の作成は決して難しいことではない。 プロジェクトが「RFP」の作成を1つのKGIとしていれば、自ずと完成する。書き方などのテクニカルな部分は、 事例などを参照すればよい。インターネットで「RFP（提案依頼書）」で検索すると多数ヒットするし、ITコー ディネータ協会のホームページにもサンプルが掲載されているので利用すればよいだろう。 要はベンダー任せにせず、ユーザが主体性を発揮しながらのシステム導入が成功への近い道であるという事であ る。「近道」と「近い道」は似て非なるものであり、システム導入という大事業は、力を尽くして「近い道」を 選ばなければならない。 Page 7

www.xeex.co.jp 株式会社エクス 〒531-0072 大阪市北区豊崎3-19-3 ピアスタワー20F TEL:06－7711－1161 © EXcorporation. All rights reserved.