DX提案書で導入するシステムだけを並べても、利用者の何が変わり、誰が運用するのかは伝わりません。顧客に届けたい価値から、業務の変更、必要なデータ、担当、試行の条件までをつなぐ構成を考えます。
この記事では、データを使って受付や提供方法を変える提案の整理手順を扱います。作業時間の改善を中心に説明する場合は業務改善提案、機能や提供範囲を紹介する場合はサービス紹介資料も参考になります。
Roneoのスライドテンプレート
この図解、メールアドレスだけで使えます。
伝えたい内容に合う型を選んで、あなたの資料に。
顧客の困りごとから変更の範囲を決める
「情報を一元化する」は手段の説明です。その先で利用者が何を確認できるか、待つ場面がどう変わるかを一文にします。現場への聞き取りや記録で分かった事実と、改善できると考えている仮説は別に書きます。
現状の業務を、入力、確認、判断、連絡、記録に分けて整理します。そのうえで今回変える工程と残す工程を決めます。対象を広げすぎると、導入の可否を判断するために必要な検証も曖昧になります。提案の冒頭には対象者、対象業務、試行期間を置きます。
3つの図解で変更をつなぐ
見本は架空企業の購買業務や遠隔監視の設定です。実際に接続や導入効果を検証した結果ではありません。後半の記入例も別の架空ケースです。
1．現状と変更後を同じ工程で比べる
AOBA-386は購買申請の9工程と変更案6工程を上下に並べ、統合する作業と差戻しを示しています。どこをまとめ、どこに人の判断を残すかを説明できる見本です。図中の90分から60分への変化は目標設定です。自分の提案で同じ削減量を約束する根拠には使いません。
このテンプレートを、自分の資料に。
この図解のZIPを無料で受け取る →2．データと判断の流れを分ける
AOBA-482は拠点から基盤へ上がる計測値と、現場へ戻す通知・履歴を分けています。既存の安全制御は独立しています。データが集まることと、自動で制御することは別です。提案でも、システムが処理する範囲、人が判断する範囲、接続しない範囲を明示します。
このテンプレートを、自分の資料に。
この図解のZIPを無料で受け取る →3．試行を経て展開する条件を示す
AOBA-460は棚卸し、接続検証、試行、展開、移管を工程表とガントで示しています。M6の試行判定を通過してから対象を広げる構成です。最初から全体導入を決定した資料に見せず、判定する人と必要な証拠を置く使い方ができます。
このテンプレートを、自分の資料に。
この図解のZIPを無料で受け取る →記入例：問い合わせ受付を変える提案
架空の「みずき保守」が、一拠点で4週間の試行を行う設定です。顧客が修理依頼の状況を電話で問い合わせないと確認できない、という仮説から始めます。電話が何件減るかは未確認です。まず「受付状況と次の連絡予定を顧客が確認できる」状態を検討します。
| 観点 | 現状の設定 | 試行で変えること |
|---|---|---|
| 受付 | 電話を受け担当者がメモ | 共通の受付番号で記録 |
| 確認 | 担当者へ個別に問い合わせ | 受付番号から状況を確認 |
| 判断 | 現場責任者が訪問の要否を決める | 判断は現場責任者に残す |
| 連絡 | 担当者が都度電話する | 確認済みの状態と連絡予定を表示 |
| 例外 | 急ぐ場合は個別対応 | 急ぎの連絡先を明示して既存対応を残す |
対象は試行拠点の受付で、故障を自動判定する機能は含めません。利用者に見せる状態は「受付済み」「確認中」「連絡予定」のように定義し、誰がいつ更新するかを決めます。情報が古いまま表示されると別の困りごとになるため、更新責任も提案に含めます。
データ一覧と運用を対応させる
必要な情報は、受付番号、対象設備、受付日時、状態、次の連絡予定、担当です。各項目について入力元、更新者、閲覧する人、保存先を整理します。顧客に見せる情報と社内の作業メモを同じ表示範囲へ入れないようにします。
既存の台帳と連携する場合は、同じ設備を識別する番号があるかを先に確認します。番号が一致しない状態を、資料上の一本の矢印で解決したことにしません。照合方法が未定なら未確認事項として示し、接続検証の完了条件へ含めます。
担当不在、通信できない状態、誤入力なども試行で確認する対象です。すべてを自動化する前提にせず、手作業へ戻す条件と復旧後の記録方法を決めます。具体的な制御や情報保護の設計は、この提案資料だけで完了するものとして扱いません。
効果の仮説と試行の結果を分ける
この例では、問い合わせ件数、状態の未更新件数、更新に使った時間を記録します。件数の増減だけでなく、試行対象の受付件数や営業日数も残し、比べる条件をそろえます。電話が減っても更新作業が大幅に増えていれば、運用全体を点検する必要があります。
判定条件は開始前に決めます。「状態の更新を担当者が継続できる」「誤った表示を訂正できる」「例外時の連絡先を利用者が確認できる」といった観点を置き、確認方法と判断者を対応させます。未計測の効果を金額へ換算して、投資回収を確定したように示さないようにします。
試行後は、続ける、条件を変えて試す、範囲を戻すという選択肢を用意します。システムの完成と運用の定着を同じ完了条件にせず、担当者への引継ぎと更新記録の確認も工程へ含めます。
提案書のページ順
冒頭に顧客の困りごとと確認状況を置き、現状と変更案、データと役割、試行範囲、判定条件、次の依頼の順に並べます。機能一覧はこの対応を説明する位置に置きます。読み手が判断する段階では、機能の数よりも対象と条件を追えることを優先します。
Claudeに渡す指示文
現状と変更後の比較見本ZIPを受け取るときは、次のように範囲を指定します。
架空の保守受付を一拠点で4週間試すDX提案の原稿を作る。
狙い：顧客が受付状況と次の連絡予定を確認できるようにする。
現状は電話と個別メモ。変更案は共通受付番号と状態の共有。
訪問要否は現場責任者が判断し、自動故障判定は含めない。
顧客価値、業務変更、データ項目、更新担当を対応させる。
試行では問い合わせ件数、未更新件数、更新時間を記録する。
効果は仮説とし、未計測の削減額や回収期間を作らない。
接続、例外対応、引継ぎの未確認事項と判定条件も示す。
共有前の確認
- 顧客の変化とシステムの機能がつながっているか。
- 人の判断と自動処理の範囲を分けたか。
- データの入力元、更新者、閲覧範囲が分かるか。
- 試行の結果を何で確認するか決めたか。
- 例外時と試行後の運用担当を残したか。
テンプレートは、Claudeで再現するためのプロンプトZIPで提供します。完成したPowerPointファイルの配布ではありません。