CCPM+（日本語版）ホーム
TOCの概要
No.001　手動によるDBRインプリメンテーションとソフトウエアによるDBRインプリメンテーション

TOC資料

No.001　テーマ「手動によるDBRインプリメンテーションとソフトウエアによるDBRインプリメンテーションの良い点、悪い点」（2001年3月－CMSIGでのメール交換）

日時 : 2001年3月10日 8:16

CMSIGの識者にお伺い致します。今、私は、DBRのインプリメンテーションを行う際、手動でDBRのインプリメンテーションを行うのと、いわゆるHaystack Compatible Systemを使ってDBRのインプリメンテーションを行うことの、それぞれの良い点と悪い点がなんであるかと思案しています。

理屈から考えて、DBRのインプリメンテーションには三つのシナリオが考えられます。すなわち、

手動でDBRをインプリメンテーションする。ピリオッド。
最初に、手動でインプリメンテーションを行い、その後、システムの運用を、いわゆるHaystack Compatible Systemを使う運用に切り替える。
最初から、Haystack Compatible Systemを使って、DBRのインプリメンテーションを行う。

この問題についての、お考えを、どなたかお教え頂ければ幸甚です。

また、どなたか、いわゆるHaystack Compatible Systemを定義してくださり、それに該当する製品を教えて下されば有難いと存じます。

小林　英三

日時 : 2001年3月10日 9:38

過去の個人的な経験によれば、手動プロセスで（DBRのインプリメンテーションを）開始し、経験を積んだら、ソフトウエアによる「エンハンスメント」にお金と労力を使ったらよいと考えます。その主な理由は下記の理由です。

手動システムにより、低いところになっている果物を取れます。すなわち、ほんの小さな投資か、殆ど投資なしで、金銭的な利得がえられる。
手動でインプルメントすることで、ドラム・バッファ・ロープによるアプローチをどのように展開したらよいかについて、理解し、考えざるを得ないように仕向けられる。このことについての適切な理解がなかったので、ドラム・バッファ・ロープによるアプローチを「ソフトウエアによるソリューション」と見なす過ちをたくさんの会社が犯し、行動や組織風土などを（ドラム・バッファ・ロープシステムが成功するように）適切に変更することに失敗し、その失敗を「悪いソフトウエア」のせいにしている。
社内ポリティックスによっては、ドラム・バッファ・ロープ・ソフトウエアが成功するためには、乗り越えなければならない二つの障害がある。すなわち、組織風土、カルチャーを変えること、および、ソフトウエアの導入によって発生するIT関連の変更（新しいソフトウエア、レポートの作成、データの統合など）です。手動でインプルメントすることで、この二つの障害を（当面）切り離すことで、問題の解決が容易になる。

また、個人的な経験ですが、静かに、こっそりと、DBRを手動でインプルメントすることで、上層部の「レーダースクリーン」に見えないようにして展開できた経験があります。そして、それが上手く動き出した後、結果を上層部に示し、「見慣れない、変な考え方」を彼らが拒否できないようにすることができました（許可を得るより、許しを得るほうが易しい）。新しいソフトウエアを、こそこそ導入することは、非常に難しいことです。

チャン・スチーブンス

日時 : 2001年3月10日 11:37

私の考えでは、もし、手動で簡単にできるなら、どうしてそうしないのですか。

トニー・リゾ

日時 : 2001年3月10日 20:44

よい、ご指摘です。しかし、トニーさんは、「もし、手動で出来ないなら、それだけが理由で、ソフトウエアを購入して、そのソフトウエアの助けを借りて、DBRをインプルメントしなさい」と言っているのですか。

私が知りたいのは、Haystack Compatible Systemのようなソフトウエアが、リアルタイムATP、素早くできるwhat-ifスタディ、より短時間でできる生産計画の作成などの、手動では出来ない追加機能のことです。私の考えでは、これらの追加的に利用できる機能が、もし、存在するなら、これらの機能性を欲しくなり、それによって得られる利益、利得で、このようなソフトウエアの購入のジャスティフィケーションを行うと思うのです。

私は、チャン・スティーブンスが言っているように、DBRのインプリメンテーションは、まず、手動で行い、考え方の理解を身に付け、それから、必要に応じて、ソフトウエアを使うモードに移行したらよいと思うのですが。

小林　英三

日時 : 2001年3月10日 23:17

小林さん

同意です。DBRに基づく（手動）システムがコントロールできる状態になったら、業績を、一層、最適化するために、いろいろなことができます。あなたが言ったようなアクティビティ（リアルタイムATP、素早くできるwhat-ifスタディ、より短時間でできる生産計画の作成など）により、そのシステムの完成の度合いを高めて、制約資源の利用のレベルを高めて資源を浮かせ、この浮かせたキャパシティを、新しいビジネスに向けられるようになるでしょう。これは、継続的にプロセスを改善するという、TOCの考え方に沿ったものです。しかし、このアプローチは、本当に、優れたリーダーシップの下に行われることが必要です。このアプローチは、組織を指導するリーダーシップが、TOCの考え方に沿ったものでなく、システムに始終干渉するようなものだと、実行できません。

トニー・リゾ

日時 : 2001年3月10日 21:47

前のメールに付け加えます。

手動でDBRをインプルメントすることは、ソフトウエアを使うよりも、安価で、容易です。しかし、得られる（スループットの）改善には限界があります。私の個人的な経験ですが、私は、大きな、高価な製品（30,000ポンドの重量）を、少量（一日当り10-15個）生産している鋳物工場で、DBRを手動でインプルメントできました。生産数量が少量なので、私のような単純な男でも、DBRによる計算をできました。こうして、（仕掛品在庫が60万ドル以上減少し、サイクルタイムが半分になったという）容易に得られる利得（低いところになっている果物）を得てしまうと、（それ以上の業務改善を行うには）手動で出来ない生産システムの微調整を行うために、ソフトウエアが必要になりました。このソフトウエアの導入は、6桁のインプリメンテーション費用が掛かりましたが、追加的な仕掛品の減少は、5万ドル-7.5万ドル、サイクルタイムの追加的な短縮は、1-2日でした。

同じ鋳物工場にもう一つ生産ラインがあり、そこでは、上で話した製品よりも軽いけれども、一日当り60-90個生産していました。このラインは、上で話したラインでの、手動によるDBRの成功を聞いて、彼らも同じことをやりたくなり、その手動によるDBRをインプルメントしました。しかし、一日当り60-90個を生産し、それなりに複雑さが増してくると、別のラインでの私の経験をしても、手動システムは正しい意思決定を上手くできませんでした。そして、得られた成果も、別のラインのそれとは、まったく、比較のできないものでした。このラインでは、利得を得るには、ソフトウエアに頼らざるを得ませんでした。

チャン・スティーブンス

日時 : 2001年3月11日 3:06

以下に、

手動でDBRをインプリメンテーションする。ピリオッド。
最初に、手動でインプリメンテーションを行い、その後、システムの運用を、いわゆるHaystack Compatible Systemを使う運用に切り替える。
最初から、Haystack Compatible Systemを使って、DBRのインプリメンテーションを行う。

の三つのシナリオの良い点、悪い点を比較します。

I　手動によるDBRインプリメンテーション

手動のインプリメンテーションの良い点

インプリメンテーションを行うのにかかる投資が低い
インプリメンテーションの焦点が、技術問題ではなく、業務プロセスや、（生産システム、ものの考え方の）変更に合わされる。
インプリメンテーション時間が短く、結果が早く出る。

手動のインプリメンテーションの悪い点

インプリメンテーションの永続性が、マネジメント（インプリメンテーション・チーム）の継続性に依存する。
手動による計算が重い。
手動アルゴリズムによるスケジューリングの近似が粗く、したがって、より大きいタイムバッファが必要となる。その結果、
1. 理論的に可能なリードタイムより、リードタイムが長くなる。
2. 大きな防護キャパシティが必要となる。

II　ソフトウエアを使うDBRインプリメンテーション

ソフトウエアを使うインプリメンテーションの良い点

より厳密なスケジューリングができ、そのため、良い結果が得られる（手動システムよりも、100%も良い場合もある）。
1. はるかにたくさんのオプションを考慮して意思決定ができるので、制約資源の「徹底的活用」の度合いが高まる。
2. シンクロナイゼーションの度合いが高まり、キャパシティ制約と考えられかねない資源のスケジューリングが綿密に行える。
回収すべき投資額を所与として、DBRプロジェクトへのマネジメントの支持が大きくなる。
組織風土変更の重要性の強調度合いが低くなり、DBRインプリメンテーションへの抵抗が小さくなる（インプリメンテーションに必要な時間のスピードが早くなる）。
ソフトウエアが錨となり、組織内での、TOCの永続性が長くなる。
最初の「よいところ」までのインプリメンテーションが早く行える（こういうと、議論が沸くことを承知の上での発言）。

ソフトウエアを使うインプリメンテーションの悪い点

時間、および、お金の初期投資が大きくなる可能性がある。
市場にあるソフトウエアのすべてが、必ずしも、すべての工場タイプに適してはいない（自社の環境で、機能しない製品を買う可能性がある）。
技術だけに焦点を合わせたソフトウエアだけのインプリメンテーションは、最良の結果を生まない。
1. TOCのプロセスの理解を欠いたインプリメンテーション（継続的改善の意識なし）。
2. 人々は、なぜ、スケジュールが、働くなというか理解できないので、スケジュールに従わない。
3. 相互に衝突する新旧の業績測定尺度が混在し、DBRインプリメンテーションから得られる筈のものを台無しにしてしまう。

III　最初に手動のインプリメンテーション、次いで、ソフトウエアを使う方式に移行

最初に手動のインプリメンテーション、次いで、ソフトウエアを使う方式に移行というやり方の良い点

手動のインプリメンテーションの良い点を、手動のインプリメンテーションの悪い点なしにできる。
（必ずしも、すべての場合ではないが）手動により確立された業務プロセスをソフトウエアが自動化するので、業務プロセスを定着させる「錨」として機能する。

最初に手動のインプリメンテーション、次いで、ソフトウエアを使う方式に移行というやり方の悪い点

インプリメンテーションに時間が掛かる。
場合によっては、インプリメンテーションの初期に皆が、DBRのインプリメンテーション・プロジェクトに持っていた情熱が、手動のインプリメンテーションの期待以下の結果で失われる。

マーク・ウオッペル

日時 : 2001年3月11日 3:12

市場で販売されている Haystack スケジューラーは、たった、一つしかないです。それは、MAPICS Inc.社のThru-Putという製品です。