エグゼクティブ・サマリー
- PoCが止まる場所は技術ではない。「1拠点目が成功した」という事実が、2拠点目の意思決定を助けないという構造にある。
- 横展開のコストは1拠点目の単純な倍数ではない。初回に払った設計費は再利用でき、逆に拠点差分の吸収コストが新たに乗る。この構造を先に示せないと予算が通らない。
- 展開単位は「拠点」ではなく「業務パターン」で切る。同じ工程・同じ荷姿・同じ人員構成の拠点をひとまとめにするほうが、地理的な近さで束ねるより速い。
- 標準化すべきは機種ではなく、要件定義書・運用手順書・教育カリキュラムなど7つの成果物である。機種の統一を先に決めると、現場に合わない導入が量産される。
- 横展開は「一斉」ではなくウェーブ(波)で進める。2拠点目を検証拠点、3〜5拠点目を型づくり、それ以降を量産と位置づけると、失敗の傷が浅い。
なぜPoCの次に進めないのか
多くの企業で、PoCの報告会は成功裏に終わる。動画が流れ、削減工数が示され、経営層はうなずく。そして半年後、その取り組みは1拠点にとどまったままになっている。
原因を現場で聞くと、返ってくる答えはたいてい次の3つである。
ひとつめは、予算の出どころが変わること。PoCは多くの場合、本社の企画部門や情報システム部門の実証予算で走る。しかし全社展開の費用は各拠点の設備予算から出る。決裁者が変わり、判断基準も変わる。本社にとっての「成功」は、拠点長にとっては「本社が持ってきた話」でしかない。
ふたつめは、1拠点目の成果が他拠点の言葉に翻訳されていないこと。「A工場で年間1,200時間削減」という数字は、B工場の拠点長には自分ごとにならない。B工場は荷姿が違い、人員構成が違い、繁閑差が違う。翻訳の仕組みがなければ、各拠点はゼロから検討し直すことになる。
みっつめは、誰も横展開の担当者ではないこと。PoCのプロジェクトチームは、報告会をもって解散する。次の拠点を口説き、要件差分を吸収し、ベンダーと交渉する役割が、組織図のどこにも存在しない。
いずれも技術の問題ではない。横展開は、導入プロジェクトの延長ではなく、別の設計対象である。
1拠点目と2拠点目で何が変わるか
横展開の設計は、「2拠点目で何が変わり、何が変わらないか」を正確に把握するところから始まる。
| 項目 | 1拠点目 | 2拠点目以降 | 含意 |
|---|---|---|---|
| 構想・目的設定 | ゼロから | 再利用可(拠点KPIの読み替えのみ) | 大幅に短縮できる |
| 要件定義 | ゼロから | 標準要件+差分定義 | 差分の抽出手順が要る |
| 機種選定 | 比較検討 | 原則踏襲(適合しなければ再選定) | 適合判定の基準が要る |
| システム設計・連携 | 個別設計 | 標準構成の適用 | 標準構成の維持者が要る |
| 現場調整・教育 | ゼロから | 削減できない | 拠点数に比例して工数が乗る |
| 定着化支援 | ゼロから | 削減できない | 同上 |
| ベンダー交渉 | 単発 | 複数拠点前提の条件へ | 単価は下げられる |
重要なのは、下の2行は圧縮できないという点である。ハードもソフトも標準化できるが、人は標準化できない。拠点の人が納得し、手を動かし、習慣を変える工数は、拠点数だけ必ず発生する。
横展開の計画で最も多い失敗は、この「圧縮できない部分」を圧縮できる前提で予算とスケジュールを組むことである。結果として、3拠点目あたりで現場支援が薄くなり、定着せず、「やっぱり本社の押し付けだった」という評価が確定する。詳しくは定着化・運用設計を参照してほしい。
展開単位は「業務パターン」で切る
拠点を束ねる軸は、地理ではなく業務パターンで取る。
判断に使う軸は次の4つである。
- 工程の同一性:同じ作業をしているか。ピッキングなら、ケース単位かピース単位か
- 対象物の同一性:荷姿・重量・材質・ばらつきの幅が近いか
- 物理環境の同一性:床、通路幅、段差、温度、天井高、Wi-Fi環境
- 人員構成の同一性:常勤/派遣の比率、シフト、平均勤続年数
このうち対象物と物理環境が近ければ、地理的に離れていても同一グループとして扱ってよい。逆に、隣接する2つの倉庫でも荷姿が違えば別グループである。
グループを定義したら、各グループに1つずつ「型」をつくる。型とは、後述する7つの標準成果物のセットである。型が3つできれば、残りの拠点はそのいずれかに当てはめて短期間で立ち上がる。
標準化すべき7つの成果物
標準化の対象を「機種」だと考えると、たいてい失敗する。機種は現場条件で変わりうるし、数年で世代交代する。標準化すべきは、意思決定と運用を再現するための成果物である。
- 標準要件定義書:必須要件と拠点差分欄を分けた雛形。差分欄が空欄のまま出てきたら差分抽出をしていない証拠になる
- 拠点適合チェックリスト:床・通路幅・電源・通信・段差・保管什器など、事前調査項目を1枚に
- 標準システム構成図:上位システムとの連携方式、データ項目、責任分界点
- 標準運用手順書:起動停止、エラー一次対応、業務継続手順、日常点検
- 教育カリキュラム:オペレーター/管理者/保全担当の3層別。所要時間つき
- KPI定義と測定手順:測り方まで固定する。拠点ごとに定義が揺れると比較できない
- 導入スケジュール雛形:調査から本稼働までの標準日程と、拠点側の必要工数
これらは1拠点目のプロジェクトの副産物として自然に生まれるものではない。「横展開用の成果物をつくる」というタスクを1拠点目の計画に明示的に入れておく必要がある。PoCの段階から意識しておくとよい点はPoC(実証実験)の設計と評価にまとめている。
ウェーブ設計——一斉展開をしない
全拠点を同時に立ち上げようとすると、問題が同時多発し、支援リソースが分散し、どの拠点も中途半端になる。展開は波で分ける。
| ウェーブ | 拠点数の目安 | 目的 | この段階で確定させるもの |
|---|---|---|---|
| 第0波 | 1(PoC拠点) | 成立性の証明 | 効果の実測値、技術的成立性 |
| 第1波 | 1〜2 | 差分の発見 | 拠点適合チェックリスト、差分の型 |
| 第2波 | 3〜5 | 型の確定 | 7つの標準成果物、標準日程 |
| 第3波以降 | 残り全部 | 量産 | 単価、内製化した支援体制 |
最も設計上重要なのは第1波である。ここは「もう1拠点増やす」ためではなく、「1拠点目のやり方のどこが特殊解だったかを暴く」ために実施する。したがって第1波の拠点は、あえて条件が少し違う拠点を選ぶ。条件が近い拠点を選ぶと、うまくいってしまい、差分が見つからないまま第3波に進んで破綻する。
第1波の評価軸は削減効果ではなく、「1拠点目の成果物のうち、何%をそのまま使えたか」で置く。この数字が7割を超えていれば型づくりに進める。5割を切るなら、展開単位の切り方を見直す。
横展開の予算をどう説明するか
拠点展開の予算は、1拠点あたりの単価で説明すると必ず高く見える。次のように分けて示す。
- 初期投資(再利用可):構想・標準設計・システム連携の初期開発。1拠点目に計上済みで、2拠点目以降は発生しない
- 拠点変動費:機体、周辺設備、現地工事、拠点別の設定調整
- 拠点固定費:教育、現場調整、立ち上げ支援。拠点数に比例、圧縮不可
- 運用費:保守、消耗品、監視。台数に比例
この分解を示すと、拠点数が増えるほど1拠点あたりの平均コストが下がる曲線が描ける。経営層に対しては、単年度のコストではなくこの逓減曲線と損益分岐拠点数を示すのが最も通りやすい。投資対効果の組み立て方はロボット導入の投資対効果(ROI)の語り方に詳しい。
あわせて、やめる基準も同時に置く。「第1波で標準成果物の再利用率が5割を切ったら、第2波の前に設計を見直す」といった撤退・見直し条件を先に決めておくと、経営層は最初の承認を出しやすくなる。
横展開のKPI——拠点KPIと展開KPIを分ける
拠点ごとの効果KPI(削減時間、稼働率、エラー率)はロボット導入のKPI設計と効果測定のとおりに設計すればよい。横展開ではこれに加えて、展開そのもののKPIを持つ。
| 展開KPI | 定義 | 目安 |
|---|---|---|
| 標準成果物再利用率 | 拠点導入で修正なく使えた成果物の割合 | 第2波以降で70%以上 |
| 立ち上げリードタイム | 拠点決定から本稼働までの日数 | 波ごとに短縮していること |
| 拠点あたり本社支援工数 | 本社/推進チームが投入した人日 | 波ごとに減少していること |
| 90日定着率 | 稼働90日後も計画稼働率を維持している拠点の割合 | 80%以上 |
このうち90日定着率を必ず入れる。立ち上げ拠点数だけを追うと、「立ち上げたが使われていない拠点」が積み上がる。展開の速度と定着の質は、必ず両方を見る。
失速の兆候と打ち手
横展開が止まるとき、事前に必ず兆候が出る。
- 兆候1:拠点の要件差分リストが長くなり続ける——展開単位の切り方が粗い。グループを分割し直す
- 兆候2:本社支援工数が波を追うごとに減らない——標準成果物が実務に耐えていない。手順書の粒度を現場目線に落とす
- 兆候3:拠点長が「うちは特殊だ」と言う——多くは事実であり、同時に交渉の言葉でもある。適合チェックリストで特殊性を項目化し、本当に特殊な項目だけを議論の対象にする
- 兆候4:ベンダーの対応が遅くなる——複数拠点前提の体制と要員が契約に入っていない。台数増を前提とした保守体制を契約段階で握る
- 兆候5:推進担当者が異動した——最も致命的。推進機能を個人ではなく役割として定義し、引き継ぎ資料を標準成果物に含める
兆候3への向き合い方が横展開の実力を分ける。拠点の「特殊だ」は拒否ではなく、要件の未整理であることが多い。項目化して分解すれば、8割は標準で対応でき、残り2割が本当の差分になる。
RobiZyの立場から
RobiZyはロボットを売らないNPO法人である。したがって横展開の設計で、特定メーカーの機種を増やす方向へ誘導する動機を持たない。
横展開のフェーズでは、利害が交錯する。ベンダーは台数を伸ばしたい。本社は標準化したい。拠点は自分の現場に合うものを入れたい。この三者の間に、どの立場にも属さない調整役がいるかどうかで、展開の質は大きく変わる。RobiZyは導入7工程——①RXビジョン/構想策定 ②要件定義・PoC・選定・組成 ③構築スケジュール/ToBe業務設計 ④システム設計 ⑤開発・導入 ⑥定着化 ⑦運用——のフレームに沿って、中立のコーディネーターとして伴走している。
まとめ
PoCから全社展開への断絶は、技術ではなく設計の欠落によって生じる。要点は5つである。
- 2拠点目で圧縮できるのは設計、圧縮できないのは人の工数である。この非対称を予算に織り込む
- 展開単位は地理ではなく業務パターンで切る
- 標準化するのは機種ではなく7つの成果物である
- 一斉展開ではなくウェーブで進め、第1波は差分を暴くために使う
- 拠点KPIと展開KPIを分け、90日定着率を必ず見る
RobiZyはロボットを売らない中立のコーディネーターとして、構想段階から横展開の設計まで伴走している。「1拠点目は動いたが、その先の絵が描けていない」という段階でのご相談を歓迎する。むしろ、投資が確定する前の構想段階でご相談いただくほうが、選択肢を広く取れる。無料の相談から始められるので、まずは現状をお聞かせいただきたい。