PoCから全社展開へ——横展開の設計

Scale-Up·導入プロセス·約14分·全6ページ

エグゼクティブ・サマリー

  • PoCが止まる場所は技術ではない。「1拠点目が成功した」という事実が、2拠点目の意思決定を助けないという構造にある。
  • 横展開のコストは1拠点目の単純な倍数ではない。初回に払った設計費は再利用でき、逆に拠点差分の吸収コストが新たに乗る。この構造を先に示せないと予算が通らない。
  • 展開単位は「拠点」ではなく「業務パターン」で切る。同じ工程・同じ荷姿・同じ人員構成の拠点をひとまとめにするほうが、地理的な近さで束ねるより速い。
  • 標準化すべきは機種ではなく、要件定義書・運用手順書・教育カリキュラムなど7つの成果物である。機種の統一を先に決めると、現場に合わない導入が量産される。
  • 横展開は「一斉」ではなくウェーブ(波)で進める。2拠点目を検証拠点、3〜5拠点目を型づくり、それ以降を量産と位置づけると、失敗の傷が浅い。

なぜPoCの次に進めないのか

多くの企業で、PoCの報告会は成功裏に終わる。動画が流れ、削減工数が示され、経営層はうなずく。そして半年後、その取り組みは1拠点にとどまったままになっている。

原因を現場で聞くと、返ってくる答えはたいてい次の3つである。

ひとつめは、予算の出どころが変わること。PoCは多くの場合、本社の企画部門や情報システム部門の実証予算で走る。しかし全社展開の費用は各拠点の設備予算から出る。決裁者が変わり、判断基準も変わる。本社にとっての「成功」は、拠点長にとっては「本社が持ってきた話」でしかない。

ふたつめは、1拠点目の成果が他拠点の言葉に翻訳されていないこと。「A工場で年間1,200時間削減」という数字は、B工場の拠点長には自分ごとにならない。B工場は荷姿が違い、人員構成が違い、繁閑差が違う。翻訳の仕組みがなければ、各拠点はゼロから検討し直すことになる。

みっつめは、誰も横展開の担当者ではないこと。PoCのプロジェクトチームは、報告会をもって解散する。次の拠点を口説き、要件差分を吸収し、ベンダーと交渉する役割が、組織図のどこにも存在しない。

いずれも技術の問題ではない。横展開は、導入プロジェクトの延長ではなく、別の設計対象である。

— 続きはこの先。全文を無料でお読みいただけます —

More関連ホワイトペーパー