東京部長倶楽部の山木のぼるです。
新しい業務システムを導入する時、機能一覧、価格、導入日程には多くの時間を使います。ところが、実際に利用が始まった後、案内が窓口ごとに違う、担当が変わるたびに同じ説明が必要になる、例外が起きると相談先がなくなる、といった問題が業務を止めます。2020年にあるシステム移行の過程を記録した際、私は、DXの成否を決めるのは機能だけではなく、利用者を支える組織のつながりだと改めて感じました。
機能が動いても、移行は完了していない
システムが仕様どおりに稼働していることと、利用者が仕事を続けられることは別です。旧システムからデータを移し、初期設定を終え、ログインできても、日常業務には標準手順に収まらない場面があります。以前のデータとの不一致、入力方法の迷い、権限の不足、締切直前のエラーなどです。
導入側が「システムは正常です」と答えても、利用者の仕事が止まっていれば、組織としての導入は終わっていません。技術の問題、データの問題、業務手順の問題、教育の問題を切り分け、解決までつなぐ運用が必要です。
同じ説明を繰り返すことも、立派な業務ロスである
相談窓口が分かれていると、利用者は担当が変わるたびに、背景、これまで試したこと、現在の状態を最初から説明します。この再説明は時間を使うだけではありません。情報が少しずつ欠け、案内の一貫性が失われ、利用者の不安も増やします。
大切なのは、相談履歴を残すことだけではありません。次の担当者が、何が起き、何を確認し、何が未解決で、次に誰が動くかを理解できる形で引き継ぐことです。記録があっても、読む責任と次の行動が決まっていなければ、情報はつながりません。
例外が起きた時に、仕組みの質が見える
標準的な問い合わせへ回答できるだけなら、手順書や自動応答でも対応できます。仕組みの実力が表れるのは、手順にない問題が起きた時です。誰が状況を判断し、別部門へつなぎ、暫定対応を決め、利用者へ途中経過を伝えるのか。例外の扱いが決まっていなければ、担当者は自分の範囲だけを守り、問題は窓口の間に落ちます。
すべての例外を事前に予測することはできません。だからこそ、判断の基準、エスカレーション先、回答期限、最終責任者を決めます。解決後には、同じ問題を標準手順へ取り込むか、利用者への説明を変えるかを振り返ります。
サポートを、担当者個人の親切に依存させない
優れた担当者が問題を拾い、関係部署へ働きかけてくれると、利用者は救われます。しかし、その人が休む、異動する、担当外になると支援が途切れるなら、組織の能力にはなっていません。
部長が見るべきなのは、応対の丁寧さだけではありません。窓口間の引継ぎ、回答の根拠、責任の所在、例外処理、利用者が解決を確認できるまでの流れです。個人の善意を、再現できる仕組みへ変えることが必要です。
新しいシステムでも、運用設計はなくならない
SaaSや自動応答を導入すれば、問い合わせの受付、内容の分類、よくある質問への案内を効率化できます。しかし、誤った案内の影響を判断し、例外に責任を持ち、利用者の仕事が再開したかを確かめる役割まで、仕組み任せにはできません。
むしろ自動化が進むほど、人へ引き継ぐ条件、扱うデータ、案内内容を確認する方法、最終判断者を明確にする必要があります。技術、人、データ、業務手順を一つの支援体験として設計してこそ、DXは成果につながります。
最初の一歩
導入中または利用中のシステムを一つ選び、利用者が困った時の入口、状況の記録先、次に引き継ぐ相手、例外時の責任者、解決を確認する人を一枚に書いてください。空欄や担当の重複があれば、そこが機能改善より先に直すべき運用の断絶です。
編集注：本稿は、2020年から記録した業務システムの移行・利用支援に関する改善要望メモをもとに、サービス名、担当者、設定情報、個別のやり取りを特定できない形に一般化し、2026年に運用設計の実践知として再構成したものです。特定企業や現在のサービス品質を評価するものではありません。
