成功した業務改善を他部署へ横展開できない理由｜完成品ではなく判断基準を移す

一つの部署で工数削減に成功したシステムを、他部署へ展開したところ使われないことがあります。「成功事例なのだから同じように使えばよい」と説明しても、独自Excelや従来手順が残ります。

横展開で移すべきなのは完成した画面だけではありません。なぜその仕組みが成立したかという判断基準と前提条件です。

成功には見えない前提がある

• 協力的な管理者がいた
• 元データの品質が高かった
• 顧客ごとの例外が少なかった
• 担当者に改善時間があった
• 旧運用を廃止できる権限があった
• 繁忙期を避けて導入した

これらを除いて機能だけ移すと、別部署では負担が増える場合があります。

「自分たちが作っていない」が拒否につながる

KatzとAllenは50の研究開発プロジェクトを調べ、長く続く集団で外部とのコミュニケーションが減り、性能が低下する傾向を報告しました。Not Invented Here症候群を扱った代表的研究です。Investigating the Not Invented Here Syndrome

この研究は業務システムの横展開を直接検証したものではありませんが、長く独自の方法を築いた部署が、外部や他部署の方法を受け入れにくくなる視点を与えます。

拒否を「頑固」と扱わず、既存方法が守っている価値を確認します。

成功事例を4層に分解する

目的

何を改善したかったか。転記削減、締め短縮、根拠確認などです。

共通原則

正本、ID、状態、承認、履歴など、部署が変わっても必要なルールです。

現地設定

担当者、期限、通知、表示、顧客別条件など、部署ごとに変える内容です。

成立条件

必要なデータ、権限、時間、協力者、旧運用の扱いです。

横展開先では、同じ目的を別の方法で達成しても構いません。

差分確認を先に行う

確認項目	元部署	横展開先
業務量と繁忙期
顧客・案件の種類
承認者
元データ
例外条件
変更権限
利用者の便益

差分がある箇所だけ現地で決め直します。

横展開先を共同設計者にする

• 実案件を提供する
• 失敗条件を挙げる
• 表示や通知を選ぶ
• 試行結果を評価する
• 例外ルールを決める
• 導入後の変更担当を持つ

元部署の仕組みを受け取る側ではなく、自部署版を作る側へ移します。

横展開の成果を統一率で測らない

• 共通ID・状態定義の採用率
• 部署境界での転記削減
• 現地設定だけで対応できた割合
• 独自改修の件数と理由
• 旧運用の終了率
• 横展開先が自分で変更できた件数

画面を完全統一できたかより、会社全体でデータと判断をつなげられたかを確認します。

まとめ

成功した改善を他部署へ横展開できないのは、成功事例を理解していないからだけではありません。元部署の前提、非公式な協力、独自の例外が一緒に移されていないためです。

目的、共通原則、現地設定、成立条件へ分解し、横展開先を共同設計者にします。

担当者の心理的所有感は属人化をなくそうとすると反発される理由、現場から改善案が出る運用は現場から改善提案が出るチームの作り方で解説しています。