デモで映らない業務の例外——システム導入前に確かめるべき検証の視点

システムの導入を決める前に、ベンダーのデモを受ける機会がある。画面はきれいに整理され、担当者はスムーズに操作してみせる。「こんな業務が実現できますか」と聞けば「はい、こちらをご覧ください」と答えが返ってくる。

しかしそのデモは、多くの場合「正常系」しか映していない。

デモが映さない「例外」の現実

ベンダーが用意するデモデータは、業務が理想的に流れる場面を前提としている。注文は一件ずつ入り、在庫は常にあり、顧客情報は正確に登録されている。返品も訂正も発生しない。

現実の業務はそうではない。たとえば次のようなケースを思い浮かべてほしい。

• 同一顧客から同日に同じ商品の注文が重複して届いた
• 一部だけ出荷し、残りを翌週に分けて送る必要がある
• 受注確定後に担当者の手で単価の訂正が入った
• 伝票が存在しない、または手書きしか残っていない返品対応を求められた

これらは「例外的な」業務に見えるが、現場では週に何度も起きる。デモではスルーされ、稼働後に初めて「このシステムでどうやるの」という話になる。

デモの理想フローと、現場の日常的な「イレギュラー」の間にある距離こそが、導入後のトラブルを生む。

例外検証を発注側が設計する

デモを受け身で見るだけでは、例外処理の実態は明らかにならない。確認するのは発注側の仕事だ。

準備の手順として、次の流れが実践的だ。

1. 現場担当者へのヒアリング：「月に何回かある、ちょっと面倒な処理」を聞き取る。担当者が口頭で伝えてきた手順や、エクセルで管理してきた補完業務がそこに出てくる。
2. 例外シナリオのリスト化：10件前後を箇条書きにまとめ、「このケースではシステムはどう動くか」という問いに変換する。
3. デモへの持ち込み：ベンダーに事前共有するか、当日の質問シートとして活用する。説明を求めるのではなく、実際に画面を操作して見せてもらう。

発注側が握り続けるべき3つの決定でも議論されているとおり、例外シナリオの洗い出しは外注できない。現場の業務を知るのは自社だけだからだ。デモは答え合わせの場ではなく、この問いを持ち込む場として設計する必要がある。

対応できなかった例外への向き合い方

検証の結果、すべての例外をシステムが吸収できるとは限らない。「この操作は手動で補完が必要」「このケースはシステム外で処理する」という答えが返ってくることもある。

それ自体は問題ではない。問題は、そうした限界を把握せずに稼働してしまうことだ。

対応できない例外が見つかったとき、確認すべき点は次の三つだ。

• その例外は月にどのくらいの頻度で発生するか
• 手動補完にかかる時間とコストはどの程度か
• 担当者が変わったときに引き継げる手順として整理できるか

頻度が低く手順が明確なら、許容範囲に収まることが多い。しかし高頻度で属人的な対応が必要なら、それはシステム選定のやり直しか、仕様の変更交渉が必要な話になる。

ITベンダーが「業務課題」を解けない構造的な理由でも触れているとおり、ベンダーは現場の例外処理の全容を把握していない。デモ後に「こんなケースがあったのに伝えていなかった」という展開は、発注側の準備不足が起点になっていることが多い。

システムの選定を本格化させる前に、現場の例外業務を整理することに時間をかけてほしい。その一覧が、デモを本当の検証の場に変える。業務の実態を整理するところから一緒に取り組みたい場合は、DX伴走支援「しぼる」も参照いただきたい。