【ブログVol.85】よく知られたTOCのアプリケーションでTOCの熟練者が犯しやすい間違い

TOCのアプリケーションはどれも、ただレシピに従ってやればえばいい段階にはないと私は思います。確かに、SDBR、アベイラビリティ保証の見込生産(MTA: Make-to-availability)、消費同期の多頻度補充、CCPMにはそれぞれレシピがありますが、現実には、そのレシピから外れないといけないケースがあまりにも多いのです。

TOCのインプリメントを成功させるためのレシピの裏には、時に目に見えない2種類のTOCの基本的な仮定(前提条件)があります。

  1. 組織自身の現実に当てはまらない前提条件
  2. 顧客に当てはまらない仮定

どのTOCのアプリケーションにも、そのアプリケーションが有効に機能する境界を定義した前提条件がいくつかあります。現実に当てはまらない前提条件があるのに気づかず、インプリメントで問題を起こす例をいくつか挙げておきましょう。

SDBRの基本的な仮定:タッチタイムの合計がリードタイムの10%未満。この前提が当てはまらないと、主にバッファ管理で問題が起きる。つまり、まだ督促が効く適切なタイミングでレッドゾーンへの食込みを知らせる警告がでないかもしれない。その場合は、残りのタッチタイムを考慮した何らかの変更がバッファ管理に必要である。また、タッチタイムがリードタイムの50%を超える場合は、問題はバッファ管理だけに留まらない。そういう環境では、非常に大きな余剰キャパシティを確保するか、CCPMを使わないといけなくなる。

注釈: 乾燥のような絶対必要な待ち時間があるなら、リソースのキャパシティを全く使わなくても、その時間をタッチタイムに含めます。

SDBRの基本的な仮定: オーダーは、材料の投入から完了まで、組織の完全なコントロール下にある。これは、外部委託する工程が1つでもあれば正しくない。委託された業者は、バッファ管理の優先順位に従うという約束はしないのが普通。バッチ全体が委託した業者に入って出て来る。ある意味、これは長いタッチタイムの工程だが、その間コントロール下にない事が問題を大きくする。そういう状況では、外部の業者にオーダーを渡す中間納期を守らなければならなくなる。それは、背中合わせの2つのタイムバッファを持つということ。1つは業者に渡るまでのバッファ、もう1つは渡してから出てくるまでを保護するバッファ。

製造組織に対するTOC共通の仮定: オーダーを可能な限り早く投入しているのが普通である。ある極端なケースで、このほぼ無意識の仮定が間違っていた! その工場は非常に注意深く、実際慎重すぎるくらいオーダーの投入に慎重で、工場のどこにもごく僅かしか仕掛り(WIP)が無かった。製造リードタイムを半分にした上に、オーダーを今までより早く投入するのが許されなかったら、いったいどうなるのか?

CCPMの基本的な仮定: プロジェクトは、速く終えれば大きく儲かり、終えるのが遅いと大きく損する。この仮定が当てはまらないと、「クリティカルチェーン」(あるいは「クリティカルパス」)という概念が丸ごと効力を失う。プロジェクトを速く終えるのは価値があり、遅ければその分ダメージがあるのは常に本当だが、果たして、速く終える価値か遅い損失かということが、プロジェクトを速く終えるために組織が喜んで労力とお金を注ぐような重要な問題なのか! 製造でクリティカルチェーンの考え方があまり知られていないのは、プロジェクトを速く終えることは、高価なリソースの効率を高く維持するより価値が低いからだ。負荷が高いリソースがあれば、そのリソースが空くのをタスクが待たないといけない。非制約の効率の価値に異論を唱えるTOCも、制約はもちろん、負荷の高いリソースが空くまで製造オーダーの方が待つという、製造の考え方には異議を唱えない。そういうわけで、プロジェクトでは遊びが出ないように特別な労力を払わないといけないが、製造ではリードタイムがタッチタイムよりはるかに長いからそうはしない。したがって、CCPMを使って計画を立てる「プロジェクト」の定義には、速い完了がどういう時にクリティカルなのかを入れるべきだ。

CCPMの一般的仮定: プロは、約束した納期を常に守るために、仕事の所要時間の見積もりを意図的に水増しする。この仮定は、仕事のプロは納期を守れるかどうか悩む必要はなく、新しくエキサイティングなものの開発に承認をもらう方に強い関心があるような、高度なソフトウェアや技術を開発する組織には当てはまらないかもしれない。なんとしても承認を得ようと、彼らはむしろ所要時間を意図的に短く見積もるかもしれない!  そういう見積りまで半分にカットするのは大きな間違いだ!

流通におけるTOCの仮定: TOCのソリューションは在庫を劇的に削減する。これが共通の認識であり、インプリメント成功の根拠を在庫の削減量にすることさえある。TOCのソリューションの真の狙いは、卓越したアベイラビリティの保証である。そのTOCの知見を知らずにそれを試みると、ほとんどの場合、過剰な在庫を抱えるはめになる。というわけで、TOCは、ほとんどの場合、期待に応えてくれる。しかし、TOCのモデルに従って、完璧なアベイラビリティを保証しようとして、多くの売行きの悪い品物の在庫まで抱えると、在庫水準は従来のやり方より高くなるだろう。そもそも、売行きの悪い品物まで完璧なアベイラビリティを約束しないといけないのか? この疑問が、我々に、2番目の種類の正しくない前提に気付かせてくれる。

では、顧客を誤解している、よく見かける例をいくつか挙げておきます。

MTAと流通における一般的仮定: 市場は、どんな品物であれ、欲しい時に欲しいものが手に入らないことが多いという問題を抱えている。この仮定から出てくる壊滅的な結論は2つある:

  1. アベイラビリティを確保するのに大きな在庫バッファが必要な売れ行きの悪い品物も含めて、手に入るまで顧客が少々待つ気があっても、アベイラビリティを保証するためにすべての商品の在庫を持つ。同様なもう一つの問題は、供給が不安定な品物のアベイラビリティである。
  2. どの顧客も、完璧なアベイラビリティを保証してもらえると嬉しい。まあ、完璧なアベイラビリティはいつでも歓迎するとして:

そもそもその顧客は入手が困難な事に困っているのか?

実際、何度もそういう目に会っており、顧客にとって頼りになる完璧な信頼性を保障してくれると都合がいいには違いない。しかし、目当ての品物が無くても、すぐ分かる代替品があることも多く、損害は小さく抑えられる。そうでなくても、顧客が十分な在庫を持っていて、短期間なら手に入らなくても困らないことも多い。顧客にとって価値が低いなら、完璧なアベイラビリティの保証は「あるに越したことはない」程度のものに過ぎない。たとえば、低価格が強みで、特定の商品にアベイラビリティを保証しない卸売業者に、完璧なアベイラビリティを提案しても失敗する運命にある。

CCPMの隠れた仮定: 当初の納期は顧客にとって重要で変更されない。CCPMの計画で重要な原則は、計画はそのままにしておけである。しかし、時にはその重要な納期が顧客側の別の事情で後ろにスライドするかもしれない。そうなれば、当初の期日どおりプロジェクトを終えても価値を高めることにはならない。待っても顧客に問題がないのに、プロジェクトを赤く表示すれば、無用なプレッシャーと緊張が加わる。また、プロジェクトが赤でも、実はそうでないと知っていると、プロジェクトマネージャーがバッファ管理を信用しなくなる恐れがある。納期の変更が小さいときは、プロジェクトバッファに新しい納期までの余裕をその分追加して、遅れていたチェーンへのプレッシャーを下げればよい。相当大きな変更なら、計画を組み直すのが望ましい。要は、まだ納期が元のままか、時々顧客に確認するのが肝要なのだ。

誰でも間違いを犯します。私たちは自分が犯した間違いから学ばないといけません。他人の過ちから学べばなお良い。間違いから学べる重要なものは、事例や問題を一般化する能力であり、それが再び新しい知見をもたらすのです。私が気掛かりなのは、TOCICOの事例発表のほとんどは、あたかも間違いを恥じないといけないみたいに、間違いや途中で遭遇した障害を暴露せずに、成功した結果を見せるだけの変わり映えしないものになっていることです。そのせいで、間違いを見つけて正したことによる成果まで隠れてしまいます。私は、インプリメントの間違いから学んだ教訓を発表した、カナダのCMSグループの素晴らしいプレゼンテーションを今も覚えています。そのインプリメントは、新しい理解を得たからこそうまくいったに違いありません。私たちは皆、自分と他人が犯した間違いから教訓を学ぶべきだと思います。


著者:エリ・シュラーゲンハイム
飽くなき挑戦心こそが私の人生をより興味深いものにしてくれます。私は組織が不確実性を無視しているのを見ると心配でたまりませんし、またそのようなリーダーに盲目的に従っている人々を理解することができません。

この記事の原文: Common mistakes of TOC practitioners in well-known TOC applications

全ての記事: http://japan-toc-association.org/blog/