システム導入の社内説明を進める順序と納得を得る資料の作り方

システム導入の社内説明は、製品の画面を見せるだけでは進みません。使う人が知りたいのは、自分の仕事がどう変わり、困ったときに誰へ聞けるかです。導入目的、変更点、試行範囲、支援方法を一つの流れで説明できる資料を用意します。

説明の出発点を現場の困りごとに置く

「DXを進めるため」だけでは、日々の作業との関係が伝わりません。注文情報を転記している、最新版を探せない、承認状況が見えないなど、確認できた場面を挙げます。特定の人のやり方を責める説明にせず、手順や情報の置き方にある課題として扱います。

現状の証拠には、業務の流れ、実際の書類、問い合わせ記録、待ちが発生する場面が使えます。まだ確認できていない効果は期待として分けて書きます。導入後に必ず負担が減ると約束するより、試して判断する条件を示すほうが実態とずれにくくなります。

人数が少ない職場では一人が複数の役割を持ちます。組織図に合わせて説明会を分けるより、確認してほしい論点を資料に明示して、必要な人へ届けます。

最初に困りごとを示し、次に仕事の流れがどう変わるかを書きます。現状の「紙へ記入してから一覧へ転記」が、新しい運用では「受付時に共通画面へ入力」に変わるなら、その一工程を具体的に比較します。なくなる作業に加え、新しく必要になる確認も示します。

記入例は「対象業務」「現在の手順」「変更する手順」「変えない手順」「開始対象」「質問先」です。すべての機能を網羅する操作説明書は別にし、説明資料では判断に必要な情報へ絞ります。画面が未完成なら、試作であることを明記します。

「現場で使えない」という意見が出たら、どの場面で何ができなくなるかを尋ねます。外出先で通信できない、顧客を待たせる、既存帳票へ出力できないなどの具体的条件が分かれば、対処の必要性を判断できます。賛否を数えるだけでは、解消すべき障害を見失います。

意見の管理表には、指摘した場面、業務への影響、確認する人、対応案、回答予定、結論を記録します。その場で解決できない点は保留理由と次の確認方法を伝えます。聞いた意見を無言で落とすと、試行への協力を得にくくなります。

想定例として、受付業務だけを試す場合、受付担当が入力できても後続の確認役が内容を受け取れなければ完了ではありません。情報の入口から受け渡しまでを一続きで試し、説明資料にもその結果を反映します。

本番開始前に、いつからどの記録を新システムへ入れるか、古い資料はどこを参照するか、処理途中の案件はどう扱うかを決めます。両方へ入力する暫定運用をする場合は、終了条件を置かないと二重作業が定着します。

説明後は参加の有無だけで理解を判断せず、利用者に実際の仕事を一つ進めてもらいます。手順を読んでも迷う箇所は、本人の注意力の問題にせず、表記、画面、説明順を調整します。導入後の質問も次の説明資料へ戻します。

全員一致を一律の条件にする必要はありません。ただし業務が止まる懸念や利用条件の問題は、開始前に具体的な対応を確認します。

変更点を短い資料にまとめ、代表的な操作を業務の流れで確認します。質問先と後から参照できる手順を用意しましょう。

質問の収集方法も一本化します。口頭だけで回答すると同じ疑問が繰り返されるため、業務名と困った画面を添えて連絡できる窓口を用意します。回答を共通の手順へ反映し、変更した箇所と適用日を利用者へ知らせることで、説明内容の食い違いを減らせます。