- HOME >
- Q&A >
- 生産スケジューラの導入方法
生産スケジューラの導入方法
- 生産計画システムを導入するのに、どんな手順で進めればよいでしょうか？一覧へ戻る
-
例を示します。もちろん、これが絶対唯一というわけではありません。
１．会社や工場の置かれている状況、課題を整理します。
２．生産スケジューラがどのようなものなのかを調べます。
それには、
・体験セミナー・紹介セミナーへの参加
・導入事例記事を収集
・書籍やWebページから情報収集
・パッケージの評価版を試してみる
などの手段があります。
３．１、２を踏まえて、会社や工場の「あるべき姿」の案を作ります。また導入プロジェクトのメンバーを選定します。
４．導入プロジェクトを立ち上げます。
状況・課題・あるべき姿について意思統一し、プロジェクトの目的とゴール、概略の実行計画を定めます。
また、プロジェクトおよびメンバーの役割・責任・権限・各種手続きを明確化します。
５．運用方案を描きます。
どんなシステムをどんな風に使用するのか、誰が何にどのように関与するか、どんな役割を果たすか、のおおよその案を作成します。
６．要求項目を明確化します。
運用方案を実現するために必要な項目を洗い出し、要求項目として明確化します。
要求項目は、RFP（Request for Proposal）とも呼ばれます。
RFPの作成をコンサルタントに手伝ってもらうこともあります。
７．要求項目を実現する手段を決定します。
通常、システムインテグレーターに提案させ、その中から選択します。パッケージもこのときに選定することになります。
場合によっては、その妥当性を検証するために、プロトタイプを作成して評価します。そのために生産スケジューラパッケージを特定期間レンタルすることもできます。
８．システム構築を行います。
実現すべきもの・実施すべきものとしては、
・運用手順書およびマニュアル（の作成）
・既存システムとのインターフェイス（の開発）
・生産スケジューラのために必要となるデータ（の整備）
・生産スケジューラ（の購入、カスタマイズ、設置）
・スケジューリングルール（の調整）
・作業指示システム（の開発）
・実績収集システム（の開発）
・インフラ（PC、サーバ、ネットワーク、携帯端末等）の整備
・システム動作テスト
・利用者教育
などがあります。
９．実運用を行います。
・データのメンテナンス
・課題の抽出、検討
・システムのバージョンアップ
これらは永久に続きます。
運用で手を抜くと、せっかく作ったシステムがあっという間に埃をかぶってしまいます。逆に言うと、無理なく実行できるような運用方法を、あらかじめデザインしておくことが大切です。
- 生産スケジューラを動かすのに、どんなデータが必要ですか？一覧へ戻る
-
一言で言えば、「モノと時間に関する全ての情報」が必要です。
具体的には、下の通りです。どのパッケージでも本質的には同様です。
１．工場の稼動データ
どんな機械や設備があり、いつ稼動するか
どんな人がいて、各日の勤務時間は、いつからいつまでか
２．製品の作り方
各製品を作るのに、どんな工程を通るか、どんな材料をどれだけ使うか
各工程では、どの資源を使って、どれだけ時間がかかるか（正味の作業時間）
工程と工程の間にはどれだけ時間がかかるか
３．注文、オーダー
どの製品を、いくつ、いつまでに
４．現在の状況
各作業はどこまで進捗しているか
各品目の在庫はどれだけあるか
５．その他の操業制約
前後の組合せに依存する段取り替え、搬送時間、・・・
なお、FLEXSCHEの場合、データを視覚的に編集するための製品 FLEXSCHE Editor があります。入門ガイドなどに従って操作しているうちに、おおよそのところは把握できてくるのではないでしょうか。
FLEXSCHE Editor オートデモ
- データを整備するのが大変です。何かいい方法はありませんか？一覧へ戻る
-
確かにいろんなデータが必要になります。あれもこれもと考えると、あまりに膨大で気が遠くなるかもしれません。
しかし、コツがあります。
１．データの精度
全体に大きく影響するデータと、そうでないデータがあります。影響の大きいデータの整備には力を注ぎ、そうでないものについてはそれなりで十分です。
例えば、「工程毎の所要時間」の精度は、（意外かもしれませんが）まずは「それなり」で構いません。
というのは、データと実際でそれほど大きくズレません。せいぜい倍・半分程度でしょう。
また、ズレたとしても、資源毎に効率を設定してまとめて補正してしまうという方法があります。工程での滞留時間を現実に近くすることができるので、結果としてオーダー毎のリードタイムの精度もそれほど悪くはなりません。
それよりも重要なのは、「工程毎の利用可能資源」です。
よくあるのが、基幹システムには各工程の代表的な利用資源しかデータがないものの、実際には他の資源でも作業できる、というケースです。
もし他に利用できる資源が５つあったとしたら、６倍の違いとなります。
これは、たとえて言えば「高速道路の最高速度と車線数」の関係です。車の速度が違うといっても２倍まで変わりませんが、車線が１本なのか６本なのかによって通過時間は大きく変わってきます。
また、作業指示を出す際には、利用できない資源を利用するような計画は許されません。その意味でも、「工程毎の利用可能資源」は重要です。
２．まずは簡単に得られるものから
ただし、慣れないうちは何が大きく影響するかわからないでしょう。最初は、精度よりも得やすさを優先すればよいです。
既に利用できるデータがあるなら、もちろん、それを流用します。
データがない場合は、いきなり精度の高いデータを整備しようとするのではなく、まずは、簡単にやれる範囲でデータを用意します。
スケジュール結果を調べてズレの大きい部分を抽出し、その部分の精度を上げる方法を考案します。それを繰り返し、徐々に精度を上げていくことをお勧めします。
３．パッケージ非依存にする
整備するデータは、なるべく、スケジューラーに依存したデータではなく、工場に依存した、本質的なデータ形式とすることをお勧めします。
というのは、スケジューラーはあくまでも手段なので、将来変更する可能性もあります。スケジューラー自身、将来のバージョンアップで、簡単な設定で実現できるようになるかもしれません。
また、整備する前のデータは、様々なところに散在しているのが普通です。それらを集約する際には、多くの方々が関与する必要があります。それらの方々に、データを整備する時点で、パッケージのデータ形式を正確に伝授するのは困難です。
したがって、工場の情報を本質的に表せるような形式にして、パッケージに対しては、データを変換するコンバータを用意するのが良いでしょう。
ただし、規模の小さな工場の場合や、データ設計に慣れていない場合、基幹システムにデータがない場合などは、スケジューラー固有のデータモデルに合わせて、データを構築していくのも１つの策ではあります。
４．片手間ではなく正式業務とすること
データの整備・保守は、かなりの労力を必要とし、また、稼動後も永久に続きます。
したがって、担当者に片手間でやらせるなどというのは論外です。非常に重要な業務であると組織全体が認識して、妨げられることがないように配慮しなければなりません。
- 生産計画システム導入プロジェクトを進めていくと、実現したいことが次から次へと膨らんで困ってしまいます。どうしたらいいでしょう？一覧へ戻る
-
システムの安定性に問題がある等の致命的な不具合を除いて、通常は、「次のステップ」で実現する方が良いです（「段階的導入」といいます）。
というのは、ちょっとした機能でも、積み重ねれば工数は膨らみます。完成時期を遅らせると、段々と士気を保つのが大変になりますし、成果を得るタイミングが遅れることによる損害も忘れてはなりません。また、システムインテグレーターを困らせることはＷｉｎ＆Ｗｉｎの関係を保つためにもなるべく避ける方がよい（「情けは人のためならず」）です。
なお、システムインテグレーターに対して、当初の契約にない作業を強要するのは、違法となるおそれがあり、企業統治の上でも問題です。
ただし、どうしても必要な項目が発覚したときには、やらないわけにはいきません。その場合は、優先度を決めます。
具体的には、「実現したいこと」の１つ１つについて、本当に必要なのか、いつ必要なのか、誰にとって必要なのか、それによってどんな効果が得られるのか、それがないとどんな損害があるのか、他に手段はないのか、を確認して、それらを比較し、優先度を決めます。優先度が低くなったものは後回しにします。
プロジェクトを進める上では、様々な優先判断が必要になります。あらかじめ、そのための仕組み・手順・権限・責任を明確にしておきましょう。ことが起きる前にルールを決めておくと、後々スムーズです。
- 日程計画システム導入プロジェクトの会議では、なかなか意見がまとまりません。どうしたらいいでしょうか？一覧へ戻る
-
なかなか難しい問題です。
生産スケジューラの導入の特徴として、様々な部署が関与することが挙げられます。
しかも、生産スケジューラの導入前の段階では、仲がそれほど良くないことも珍しくありません。
たとえば、製造と営業とでは意見が真っ向から対立して、生産計画担当がその板挟みで苦しんでおり、その解消のためにこそスケジューラーの導入が必要、というケースも多々あります。
ここで重要になるのは、「目的は何か？」という考え方です。言い換えると、視野を広げて、大義を確認し、末節に固執するのを防ぐのです。
生産計画システムの構築は、「会社の利益のため」にやっているはずです。
各部署の利害関係が絡んでもめやすいところですが、「会社のためになるのはどちらか」を考えるようにしましょう。
議論は、「勝ち負けの争い（ディベート）」ではありません。「より良い方法を探す営み」です。
多くの場合、漠然と見れば対立しているように見えても、「その目的は？」を掘り下げて細かく分析していくと、本当に対立しているわけではないことがわかり、したがって、何らかの方法が見つかるものです。
そのためにも、導入プロジェクトの立ち上げのときに、プロジェクト自体の目的を明確にし、かつ同意しておくことが重要です。
また、案ずるより産むが易し、という面もあります。議論だけで明確になるものは限られています。やってみてダメなら変える、ということが許される項目については、やってみるのも手です。
とはいえ、身内だけだと「小田原評定」になりがちなのも事実です。経験豊富なコンサルタントやシステムインテグレーターの助言が役立ちます。
日本ではまだまだそのような場面でコンサルティング費用を惜しむ傾向が強いようですが、システム完成が未来に延びる、あるいは失敗に終わり頓挫することによる逸失利益を考えると、通常は、はるかに安くつきます。
ただし、問題は、どこに優秀なコンサルタントがいるのかが、わかりにくいことかもしれませんね。
優秀なコンサルタントがどこにいるのかはわかりにくくても、コンサルタントが優秀かどうかは、かなりの場合は、「明解さ」「わかりやすさ」で判断できるのではないかと思います。というのは、コンサルタントは、実際に行動するのではなく、どういう行動をすればよいかの指針を与えるという役割を担うわけですから、実行者に対して、むずかしい問題をかんたんにとらえるための見方を提供できることが、実際に必要だからです。むずかしい問題をむずかしく解説するのは凡人でもできます。知識や経歴をひけらかすのは論外です。
その見極めのためには、「なぜ？」「なぜ？」を繰り返し投げかけることをお勧めします。これにより、以前の発言の根拠がどのくらいしっかりしているのかを確認できます。優秀なコンサルでも全智全能ではありませんから即答できないこともあるでしょうが、その場合でも顧客のことを第一に考えて、誠実な回答をするはずです。
- 生産スケジューラ導入に成功するためのポイントは？一覧へ戻る
-
この質問に対する回答は、このQ&A全体のまとめにもなります。
１．適切な生産スケジューラパッケージ
２．パッケージ利用技術
３．導入の体制・進め方
これが導入成功のための三本柱です。
【１．適切な生産スケジューラパッケージ】
「生産スケジューラはどれも同じ」と思われるかもしれませんが、実際にはそうではありません。したがって、選定の際には、慎重に検討すべきです。
やりたいことに合わないパッケージを選んでしまうと悲惨なことになります。
失敗に終わった場合、もちろんパッケージの費用が無駄になってしまいますが、それだけではありません。
労力が無駄になります。
適切なパッケージを選べば効果を出していたはずだとすれば、それに比べて利益を逸失していることになります。
失敗体験を積んでしまうことによるトラウマも無視できません。
もしかすると、合わないと分かった時点でパッケージを選び直す方が良いかもしれません。それくらい失うものは大きいのです。
その一方で、合わないとわかるのが、導入プロジェクトがかなり進んで、本稼働直前になってから、ということも少なくありません。パッケージの真価は深く使ってみて初めてわかるものなのかもしれません。
失敗しないためには、パッケージに詳しい人や生産スケジューラ導入の経験が豊富な人に手伝ってもらうのがよいでしょう。
やりたいことを整理して、そのパッケージでできるかどうか、どう実現すればよいかを尋ねるのです。
導入の経験を積んでいれば、この辺があやしそうだな、といった勘が働くものです。その辺りを各パッケージではどうなのかを確認していくことで、選定ミスのリスクはかなり減らすことができるはずです。
なお、「やりたいこと」「やるべきこと」が導入推進中にも変わっていくこともよくあります。
というのは、生産スケジューラというものがどういうものなのか、導入開始時点ではよくわかっておらず、進めていくにつれてイメージが掴めてきて、その時点になって初めて「ああ、そういうことなら、こういうことを実現したい」と具体的な要望が出てくることが多いからです。
また操業上のルールや制約が、最初から全て洗い出せているとは限りません。当初は軽視していたものが実は重要であると判明することもあります。
これらはある意味自然なことで、完全に回避するのはなかなか難しいものです。
テクニックとしては、本当にやりたいこと＆やるべきことを確認するために、また、そのパッケージで実現できるのかを確認するために、プロトタイプを作って感触を掴んでみる、という方法があります。
実際問題としては、選定前に複数のパッケージで並行してプロトタイプを作成するというのは、なかなか大変な作業ではあります。とはいえ、最低でも事前調査で最も有望となったパッケージについては、プロトタイプを作成するべきでしょう。
ただし、繰り返しになりますが、パッケージ選定前に全てを見通すことは、やはり難しいものです。
また、実際にシステムが稼働して運用を続けていく中で、状況が変化し、新たな要望が発生することもあります。というよりむしろそれが普通だと認識しておくべきです。
したがって、パッケージを選ぶ際には、その時点では判明していないような将来の要望にも対応できるように、「懐の広い」パッケージを選んでおくのが安全です。
【２．パッケージ利用技術】
パッケージに機能があっても、それをうまく使えるかどうかはまた別の話です。
実際、以前、ある生産スケジューラパッケージ（FLEXSCHEではありません）のユーザー会に、ユーザーとして参加したことがあります。その際に他の参加者に稼動状況を尋ねてみたところ、稼動していないという返事が多く驚きました。稼動していないという方に詳しく話を聞くと、確かにそれは当時のそのパッケージでは難しい、というものと、いやそれはうまく使えばできるはず、というのが、およそ半々でした。
導入の際には、現実世界の要求とパッケージの機能をマッチングさせる必要があります。場合によっては、パッケージの様々な機能を深く知っておき、それらを組み合わせることも必要になります。ある種のパズルを解くような、そんな感覚に近いものがあります。
とはいえ、何事にもコツはあります。頑張ってそういうコツを見つけ出すか、あるいは、それを知っている人に手伝ってもらうか。どちらかを選ぶことになるでしょう。
ただし、独自にパッケージの利用のコツを見出すのは、実際にはなかなか大変かもしれません。普通は、導入をいくつか経験した上で、なんとなくわかってくる、といったところでしょう。
だから、一を聞いて十を知ることができる人が社内にいるなら別ですが、そうでなければ経験豊富なインテグレーターに手伝ってもらうのがお薦めです。方法を自分で見つけ出すのは難しくても、誰かが見つけたものを理解するのは比較的易しいものです。
【３．導入の体制・進め方】
システム導入プロジェクトの成功率は約３割、という調査結果があります。アメリカでは１６％だったという報告もあります。
ネットで「システム構築 プロジェクト 成功率」というキーワードで検索してみると、いろいろと出てきます。調べてみてください。
さらに厄介なことに、生産スケジューラの場合、関与する部署が多岐にわたるという特徴があります。ざっと挙げてみても、生産管理、製造、販売、調達、生産技術、システム部門、などなどです。
プロジェクトの推進中、それらの担当者は、それぞれの立場で意見を主張することでしょう。担っている役割が違えば考え方も違います。それらの意見をまとめていくのは、なかなか大変なことです。
また、導入においては、議論だけでなく、かなりの手間・工数・労力を必要とする色々な作業が必要になります。本来の業務を抱えている中でそれらの作業を行っていくのは大変なことで、周囲の理解と支援が必要です。それがないとモチベーションを維持することが難しく、プロジェクトの遅延や停滞につながってしまいます。
また、生産スケジューラで効果を得るためには、多かれ少なかれ、今までやってきたことを変えることが必要になります。人間は誰しも、慣れ親しんだものを捨てるのには抵抗を感じます。また自分の立場が脅かされそうだと感じれば、防衛しようとするのは自然なことです。
そのような場合、すなわち、議論で意見がまとまらなかったり、作業が進まなかったりしたときには、本来の目的を再確認し、何が重要かを判断し、優先順位を明確にし、各担当者を納得させ、前向きに取り組んでいけるようにするリーダーシップが必要になります。関与する部署が多岐にわたるわけですから、必然的に、それらの部署の担当者を納得させることのできる立場にいる方がリーダーを務める必要があります。間違っても、入社数年目の新しいモノ好きの若手に任せておけば大丈夫、などと考えてはいけません。
また、導入に失敗するリスクは、そこらじゅうに転がっています。じゃあそんな危険なスケジューラ導入なんてやめちまえ、となるかというと、ライバル会社が導入に成功しているとなったら、そういうわけにもいきません。なんとかして成功させるよりありません。
どういうリスクが潜在しているのか。それを事前に回避するためにどういう手段を講じるのか。そこではやはり経験がものを言います。その点でもやはり経験豊富なインテグレーターに手伝ってもらうことをお勧めします。
参考：測る企業は成功率が2倍に
参考：プロジェクトは失敗するのが当たり前！？
PAGETOP
