mcpField
B
biz-toc

biz-toc

github.com/asgard-ai-platform生産性24336 回インストール21 週間前に更新
リポジトリ

biz-toc について

biz-tocは、制約理論を業務や運用システムに適用するスキルです。5つの集中ステップとドラム・バッファ・ロープを用い、処理量を制限するボトルネックの特定・改善と、他の工程の調整を支援します。

主な機能

  1. 015つの集中ステップの適用
  2. 02待ち行列と稼働率による制約特定
  3. 03ドラム・バッファ・ロープ方式の説明
  4. 04スループット会計指標の定義
  5. 05体系的なTOC分析の作成

活用シーン

  1. 01生産工程のボトルネック特定
  2. 02制約工程に合わせた仕掛品の管理
  3. 03スループットと運用費用の評価
  4. 04能力変更後の制約再評価

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/asgard-ai-platform/skills --skill biz-toc

インストール後、Claude Code で/biz-tocを入力して読み込まれたか確認します。

同梱ファイルexamples/sample_scenario.mdreferences/dbr-scheduling.md

詳細

制約理論(TOC)

概要

TOCでは、すべてのシステムには総スループットを制限する制約(ボトルネック)が少なくとも1つ存在するとされています。ボトルネックではないプロセスを改善しても、システムの出力は向上しません。ボトルネックを改善した場合にのみ向上します。5つの集中ステップは、制約を特定して管理するための体系的な方法です。

フレームワーク

IRON LAW: The System Is Only as Strong as Its Weakest Link

Improving a non-bottleneck process is a WASTE of resources — it produces
more work-in-progress that piles up at the bottleneck. Before optimizing
any process, verify it IS the bottleneck. If it's not, stop.
5つの集中ステップ
  1. 特定する — ボトルネックを見つけます(稼働率が最も高い、待ち行列が最も長い、仕掛品(WIP)の蓄積が最も多い工程)。
  2. 最大限に活用する — リソースを追加せずに、ボトルネックのスループットを最大化します(ダウンタイムを減らし、この工程の無駄を排除し、入力が途切れないようにします)。
  3. 他のすべてを従属させる — 他のすべてのプロセスのペースを、ボトルネックのリズムに合わせます。ボトルネックではない工程を最大能力で稼働させてはいけません。
  4. 制約を強化する — 最大限に活用しても不十分な場合、ボトルネックの能力を高めるために投資します(設備の追加、採用、外部委託)。
  5. 繰り返す — 強化後、制約が別の工程に移ることがあります。ステップ1に戻ります。
ドラム・バッファ・ロープ(DBR)スケジューリング
要素内容目的
ドラムボトルネックのペースシステム全体のリズムを決めます
バッファボトルネックの手前に設ける時間バッファボトルネックの作業が途切れないようにします
ロープ始点で作業の投入を指示するシグナル投入速度をボトルネックのペースに結び付け、WIPを制御します
スループット会計(TOCの財務指標)
指標定義
スループット(T)売上高 - 真に変動するコスト(材料費のみ)
投資(I)システム内に拘束されている資金(在庫、設備)
営業費用(OE)システムの運用にかかるその他すべてのコスト
純利益T - OE
ROI(T - OE) / I

出力形式

# TOC Analysis: {System/Process}

## System Map
{Process A} → {Process B} → {**Process C (bottleneck)**} → {Process D} → Output

## Constraint Identification
- Bottleneck: {process step}
- Evidence: {utilization %, queue length, WIP accumulation}
- Current throughput: {units/period}

## Five Focusing Steps
| Step | Action | Expected Impact |
|------|--------|----------------|
| 1. Identify | {bottleneck location} | — |
| 2. Exploit | {optimize without investment} | +X% throughput |
| 3. Subordinate | {pace other processes} | Reduce WIP by X% |
| 4. Elevate | {investment if needed} | +X% throughput |
| 5. Repeat | {new constraint location} | — |

## DBR Implementation
- Drum: {bottleneck pace = X units/hour}
- Buffer: {X hours of WIP before bottleneck}
- Rope: {release new work every X minutes}

例

正しい適用例

シナリオ: PCB組み立てライン(5つの工程)にTOCを適用

  • 工程ごとのスループット:はんだペースト印刷(100個/時)→ ピックアンドプレース(80個/時)→ リフロー炉(50個/時) → 検査(90個/時)→ 梱包(120個/時)
  • ボトルネック:リフロー炉(50個/時)— スループットが最も低く、稼働率が最も高い工程
  • 最大限に活用する: 炉の段取り替え時間を30分から10分に短縮 → 実効能力が15%向上
  • 従属させる: ピックアンドプレースを55個/時に減速します(炉の前でWIPを過剰に生産しないようにします)
  • 強化する: 必要に応じて、2台目のリフロー炉を追加します → 能力が2倍になります
誤った適用例
  • より高速なピックアンドプレース機を購入(80→120個/時) → リフロー炉(50個/時)が依然としてボトルネックのため、システムのスループットは変わりません。投資が無駄になりました。鉄則に反しています。

注意点

  • 制約は物理的なものとは限りません: 市場の需要、方針、経営陣の注意が真の制約である場合があります。工場が1,000個生産できても、販売数が500個にとどまるなら、市場が制約です。
  • ボトルネックの移動: 1つの制約を強化すると、ボトルネックが移動します。チームはステップ5(繰り返す)を忘れて、達成を祝ってしまいがちです。
  • 従属させることは直感に反します: ボトルネックではない機械を最大能力未満で稼働させるのは、無駄に感じられます。しかし、そうではありません。ボトルネックではない工程での過剰生産は、システムを滞らせるWIPを生み出します。
  • TOCとリーンの違い: リーンはあらゆる場所の無駄を排除します。TOCは制約のみに焦点を当てます。この2つは互いを補完します。TOCで注力すべき場所を見つけ、リーンでその方法を最適化します。

参考資料

  • ドラム・バッファ・ロープの実装の詳細については、references/dbr-scheduling.mdを参照してください。

コメント