TOBE業務フロー設計

TOBEは「絵」で描く

TOBEは文章で書くと曖昧になる。ASISと同じロール×時系列フォーマットで、変わるステップに「変更」「新規」「廃止」のマークを付けて描く。これで現場・経営・ベンダーの3者が同じものを見て議論できる。

解決策の3層

ソリューションは次の3層で考える。システムだけで解決しようとして失敗するパターンを避けるための型。

• ─① ルール変更 — そもそも業務ルールを変える（最も効くが合意が要る）
• ─② オペレーション変更 — 手順や役割の組み替え
• ─③ システム化 — ①②で残った定型業務をシステム化

「ステップに付けるマーク」の使い分け

TOBEはASISと同じフォーマットに次のマークを足す。差分が一目で分かる。

スコープ線引き（やる／やらない）

TOBEを描いた瞬間、何でもやりたくなる。スコープは「やる側」だけ決めてもダメで、「やらない側」を業務フロー上に明示する。やらない理由（コスト／合意難易度／優先度）も併記しておくと、Ph.6要件定義で「あれもやって」と言われたときに同じ議論を繰り返さずに済む。

ソリューション選定の判断軸

「システム化が解」とは限らない。判断軸は次の4つ。

• ─頻度：高頻度ならシステム化、月1回ならルール変更で十分
• ─再現性：定型ならシステム化、判断要ならAI＋人の確認
• ─合意難易度：ルール変更は合意が重い、システム化はベンダー次第
• ─ROI：開発コスト × 運用コスト × 削減工数で逆算

ロール境界に潜むリスクを洗う

TOBE業務フローを描いた瞬間に発生する罠が「ロール境界（矢印が異なるレーンを跨ぐ箇所）」のリスク見落とし。ハンディ端末→システム取込／仕入先EDI→倉庫といった、媒体や所有者が変わる線分は、必ず別途リスク分析する。

• ─境界：どのロール → どのロール（または、どの媒体 → どの媒体）か
• ─失敗：そこで起きうる失敗を具体的に書く（通信断／読取ミス／フォーマット差異等）
• ─影響：その失敗が業務にどう波及するか（在庫不整合／出荷停止／顧客クレーム）

失敗時の代替フローを4要素で設計

「正常系」だけ描いた TOBE は、現場で必ず詰まる。最も影響の大きい境界1つについては、失敗時の代替フローを4要素で設計しておく。これで運用設計が「机上の空論」から「現場で動く」になる。

• ─検知：失敗を誰が／どうやって検知するか（自動アラート／日次レビュー／現場の気付き）
• ─行動：検知後、誰が／何分以内に行動するか
• ─代替：どのような代替手段で業務を継続するか（手動入力／前日締め値／別ロール代行）
• ─判断基準：代替に切り替える判断基準（30分以上復旧不可なら切替、等）

案比較は「4つの問い」で

改良案A・案Bを比較するとき、「機能の好み」で議論すると合意できない。次の4問で機械的に並べると、判断軸が「境界リスクの比較」に揃う。

• ─① 新たに発生するリスクは？
• ─② 新たに強要する事項は？（現場・取引先に何を求めるか）
• ─③ 失敗するとどうなるか？
• ─④ 失敗時の代替フローはどう走るか？