業務ボトルネック診断
WHEN TO USE
課題は見えるが、時間の内訳と原因が分からないときに使う
リードタイムが長い、属人化している、ミスが多いという課題認識だけでは、解決策を決められません。実作業が重いのか、情報待ちなのか、判断が難しいのかで、必要な打ち手は変わります。
時間の内訳がない／原因が関係者の推測／例外・手戻りが多い／AI・自動化案が先行している
対象業務そのものが未特定／課題の事業影響が不明／すでに実測と原因検証が完了している
TIME CATEGORIES
リードタイムを8つに分ける
分類の目的は精密な原価計算ではなく、どこへ介入すれば全体時間が変わるかを見つけることです。一つの工程に複数の時間が混ざる場合は分けて記録します。
実作業成果物そのものを作る時間＋
- 確認すること
- 何を入力し、何を作り、正味何分かかるか
- 例
- 仕様確認、見積計算、資料作成
探索必要な情報・資料・過去事例を探す時間＋
- 確認すること
- どこを探し、見つからないとき誰に聞くか
- 例
- 類似見積、部品表、単価表の検索
判断基準を照合し、選択・推定する時間＋
- 確認すること
- 何を根拠に決め、経験者との差はどこに出るか
- 例
- 部品選定、工数推定、例外判定
転記同じ情報を別の帳票・システムへ移す時間＋
- 確認すること
- 入力元と入力先、件数、二重入力の理由は何か
- 例
- Excelから基幹システムへの入力
他部署待ち別担当・別部署の回答や処理を待つ時間＋
- 確認すること
- 誰の何を待ち、依頼から回答まで何日か
- 例
- 設計回答、仕入先見積、営業確認
承認待ち権限者の確認・決裁を待つ時間＋
- 確認すること
- 承認条件、差し戻し理由、承認者の滞留は何か
- 例
- 金額承認、値引き判断、例外承認
手戻り誤り・情報不足・認識差でやり直す時間＋
- 確認すること
- どの工程へ戻り、原因別に何件・何時間あるか
- 例
- 仕様変更、入力漏れ、確認不足
例外対応通常ルールで処理できない案件への時間＋
- 確認すること
- 例外の種類、頻度、判断者、暫定対応は何か
- 例
- 新規部品、一品一様品、特殊契約
DIAGNOSTIC PROCESS
業務説明ではなく、実案件の時系列をたどる
- 01範囲を決める
開始と終了を明確にする。『依頼受領から見積提出まで』のように境界を置く。
- 02実例を一本たどる
平均的な説明だけでなく、直近案件の時系列を担当者と再現する。
- 03時間を分類する
処理時間・待ち時間・手戻りを分け、8分類へ割り当てる。
- 04頻度とばらつきを測る
通常・繁忙・例外で、件数、中央値、最大値、発生条件を見る。
- 05根拠と原因を確かめる
計測、ログ、帳票、観察で裏付け、原因仮説と分けて記録する。
- 06改善レバーを選ぶ
削減可能な時間と、システム・ルール・体制のどれで変えるかを決める。
RECORD FIELDS
工程ごとに残す項目
誰が実行し、誰が判断・承認するか
何を受け取ると始まり、情報は揃っているか
何を作り、次の誰へ渡すか
日次・月次件数、繁忙、案件差
手を動かしている正味時間
誰の何を、どのくらい待つか
参照情報、ルール、暗黙知、判断者
種類、頻度、戻り先、発生理由
ログ、帳票、計測、観察、発言の確認状態
WORKED EXAMPLE
「見積に約1週間」を仮分解する
以下は診断前の仮説例です。実測値ではなく、次に確かめる場所を共有するための可視化として使います。
AIで部品判断を短縮しても、最大の時間が他部署待ちなら全体リードタイムは大きく縮みません。まず依頼・回答の時系列と、手戻りの発生理由を実案件3〜5件で確認します。
OUTPUT
診断の出口は「作る機能」ではなく「変える時間」
- 対象業務の開始・終了と、実例ベースの工程
- 実作業・探索・判断・転記・待ち・手戻り・例外の時間構造
- 主要ボトルネックと根拠、未確認の原因仮説
- システム、ルール、体制、データ整備の改善候補
- 期待効果の測定方法と、次の提案タイプ