緑が丘フードサービス株式会社様 業務フロー分析・AI社員配属提案書

サンプル(架空企業)。展示会のAX診断でお聞きした内容(業種・規模・使っているシステム・仕事の入口・困りごと・情報の置き場所・特定の人に頼っている業務・手順の文書化)から、この形式の提案書を作成します。2〜6章の現状の記述は、同業種・同規模・同じシステム構成の企業で最も多い姿の推定です。

目次

1. 企業概要・システム全体像
2. 人手が支えている箇所の一覧
3. As-Is: 発注・在庫ワークフロー
4. As-Is: 本部・店舗間の連絡とシフト・勤怠ワークフロー
5. As-Is: 業務知識の所在と属人性
6. As-Is: AI社員を受け入れる土台の現状
7. To-Be: 発注・在庫ワークフロー(AI社員配属後)
8. To-Be: 本部・店舗間の連絡とシフト・報告ワークフロー(AI社員配属後)
9. システム構成(To-Be)
10. 導入ステップ
11. セキュリティ設計
12. 提供体制
13. 御社版の作成にあたって 付録A. 実装項目 付録B. 試用期間(PoC)の検証計画

1. 企業概要・システム全体像

現行システム構成図

情報の置き場所を、システムとシステム外(紙・記憶・個人の手控え)まで含めて描きます。

flowchart TD
  denwa["電話<br>(精肉・鮮魚の仕入先とのやり取り)"] -->|"口頭"| shiire["仕入担当・店長"]
  fax["FAX複合機<br>(仕入先・本部連絡)"] -->|"紙"| shiire
  tehai["御用聞き・手書きの控え"] -->|"対面・紙"| shiire
  mail["メール<br>(本部連絡・一部仕入先)"] --> tencho["各店舗 店長・売場担当"]
  lw["LINE WORKS<br>(本部⇔店舗の連絡)"] --> tencho
  urib["売場の目視確認"] -->|"数量を書き取り"| zaiko["Excel 在庫表<br>(店舗ごとの様式)"]
  zaiko --> hacchu["Excel 発注リスト"]
  shiire --> hacchu
  tencho --> hacchu
  hacchu -->|"手入力"| aladdin["アラジンオフィス<br>(発注・在庫・仕入)"]
  hacchu -->|"一部の仕入先のみWeb発注"| hachimen["八面六臂"]
  smaregi["スマレジ<br>(POS・売上実績)"] -->|"実績を参照・手集計"| tencho
  aladdin -->|"CSV手動出力"| excel2["Excel 全店報告・棚卸差異の集計"]
  smaregi -->|"CSV手動出力"| excel2
  excel2 -->|"計上額を手で転記"| yayoi["弥生会計"]
  kot["KING OF TIME<br>(打刻・勤怠実績)"] --> tencho
  shift["Excel シフト表<br>(希望はチャット・紙で集まる)"] --> tencho
  memo["個人の手控え・記憶<br>(発注量の勘、仕入先ごとの癖、<br>催事の実績、棚卸差異の原因の当たり)"]

2. 人手が支えている箇所の一覧

御社の業務は、システムとシステムの間を店長・仕入担当・売場の方々が人手でつなぐことで、毎日回っています。この章では、その人手が支えている箇所を一覧にします。支えている箇所には負担が集中しやすく、担当の方の不在や催事・繁忙期に綻びやすいためです。展示会で伺った内容と、業種×規模×システム構成からの推定を並べ、出所の列で区別します。推定の行は「同じ構成の企業で最も多い姿」であり、御社に当てはまるかの確定は診断セッションで行います。

一覧を眺めると、人手が支えているのは、個々のシステムの中ではなく、システムとシステムの間、またはシステムと記憶の間です。支え方の型は3つに集約されます。電話・FAX・対面の紙で届く仕事を人が読み取って入力していること(電話発注、御用聞きの手書き控え、FAXの本部連絡)、判断に使う知識が記憶と個人の手控えにあること(発注量の勘、精肉・鮮魚の見極め、催事の実績、棚卸差異の当たり)、システム間の照合を人がまとめて行っていること(在庫表と売場、Excelと棚卸実数、スマレジと弥生会計、全店報告の集計)です。これは店長・仕入担当・売場の方々の工夫で10店舗超の運営が成立している姿であり、同時に、その方々に負担が集中する構造でもあります。

診断セッションで確認する点

• 推定の行は、御社にも当てはまりますか。すでに運用や仕組みでカバーされている行はどれですか。
• この一覧に載っていない箇所で、現場の負担になっているものはありますか。
• この中で、時間または金額の影響が最も大きいのはどれですか。

3. As-Is: 発注・在庫ワークフロー

10店舗超の各店で、毎日、部門ごとに翌日分の発注が立てられていると推定します。青果・精肉・鮮魚・惣菜は日次、加工食品・日用品は週数回の発注サイクルが混在する前提で描きます。発注の入口は、八面六臂などのWeb発注が一部、残りは電話・FAX・御用聞きの対面が中心です。

3-1. 店舗の発注業務の1日

ヒアリングでは「仕入先さんとのやり取りは、いまだに電話とFAXが多いです。特に精肉と鮮魚は」とのことでした。

3-2. 発注判断のフロー

flowchart TD
  mokushi["売場の目視確認"] --> zaikohyo["Excel在庫表と照合<br>(現在庫の把握)"]
  smaregi["スマレジの前日実績"] --> mitsumori["必要量の見積もり<br>(天候・曜日・催事を加味)"]
  zaikohyo --> mitsumori
  mitsumori -->|"店長が在席・通常商材"| kettei["発注量の決定"]
  mitsumori -->|"精肉・鮮魚"| shiire["仕入担当の判断を仰ぐ"]
  shiire -->|"在席"| kettei
  shiire -->|"不在"| horyu["前回踏襲、または発注を翌日へ送る"]
  mitsumori -->|"店長不在・催事や季節商材"| horyu2["経験のある方に電話で相談<br>相談できない場合は前回踏襲"]
  horyu2 --> kettei
  kettei -->|"Web発注可の仕入先"| web["八面六臂などで発注"]
  kettei -->|"それ以外"| denwa["電話・FAX・御用聞きに手書き控え"]
  web --> nyuryoku["アラジンオフィスへ入力"]
  denwa --> nyuryoku
  nyuryoku --> nohin["翌朝の検品で納品と突合"]
  nohin -->|"相違あり"| chosei["仕入先へ連絡し、返品・追加を調整"]

3-3. 棚卸差異の調査

Excel在庫表と実数が合わない場合、原因の候補は複数に分かれ、どれから当たるかの見当が人の経験に依存すると推定します。

3-4. 診断セッションで確認する点

• Excel在庫表の様式は、店舗ごとに分かれていますか。共通の様式がありますか。
• 発注量の目安(曜日別・天候別・催事の係数など)は、文書として存在しますか。個人の手控えに分かれていますか。
• 電話・FAX・御用聞きで発注している仕入先は、何社ぶんありますか。Web発注に寄せられそうな先はどれですか。
• 廃棄・見切り・原料転用の記録は、どこに残っていますか。

4. As-Is: 本部・店舗間の連絡とシフト・勤怠ワークフロー

本部から10店舗超へ、販促・売価・商品情報・提出依頼が日々流れ、店舗から本部へ日報・在庫・売上・勤怠の報告が返る前提で推定します。

4-1. 連絡と報告の経路

ヒアリングでは「本部からの連絡がFAXとメールとLINE WORKSに分かれてるんで、店舗によっては見落としが起きます」とのことでした。3経路それぞれに未読・未対応の状態があり、どれが自店に来ているかを突き合わせる作業が店舗側に残ります。

4-2. 連絡・報告のデータフロー

flowchart LR
  honbu["本部(商品部・管理部)"] -->|"FAX"| tenpo_fax["店舗の複合機・紙"]
  honbu -->|"メール"| tenpo_mail["店舗のメール"]
  honbu -->|"LINE WORKS"| tenpo_lw["店舗のトークルーム"]
  tenpo_fax --> tencho["店長が拾い集める"]
  tenpo_mail --> tencho
  tenpo_lw --> tencho
  tencho -->|"見落ちがあると<br>売価・販促の反映漏れ"| uriba["売場での実施"]
  tencho -->|"日報・在庫・報告"| shukei["本部でExcelに転記・全店集計"]
  kibo["シフト希望<br>(紙・チャット・口頭)"] --> shifthyo["Excelシフト表<br>店長が手作業で作成"]
  shifthyo --> kot["KING OF TIME"]
  kesseki["急な欠勤"] -->|"電話・チャットで打診"| help["ヘルプの調整(店長)"]
  help --> shifthyo

4-3. シフト作成の流れ

4-4. 診断セッションで確認する点

• 本部からの連絡のうち、実施の確認(既読・完了)を取っているものはどれですか。
• 全店から集める報告は、何種類・どの頻度で、どなたがまとめていますか。
• シフト作成の制約(部門別の必要人数、技能、時間の上限)は、文書として存在しますか。
• KING OF TIMEの実績は、シフト表とどのタイミングで突き合わせていますか。

5. As-Is: 業務知識の所在と属人性

発注・在庫・店舗運営を成立させている知識の置き場所を整理します。ヒアリングでは「発注の基本的な流れはマニュアルにしてあるんですけど、実際にどれだけ頼むかの判断とか、仕入先さんごとの癖みたいなものは、ほぼ口伝えですね」とのことでした。文書化は一部まで進んでおり、判断の部分が記憶に残っている姿と推定します。

属人性は、担当者が抜けたときに何が止まるかを並べると、そのまま見えてきます。止まるものの一覧は、文書に起こすべき知識の目次でもあります。

発注の判断が店長と仕入担当に集約されているため、休みの調整そのものが業務の制約になっています。文書化の対象は、手順ではなく「判断の材料と、その使い方」に絞られます。

6. As-Is: AI社員を受け入れる土台の現状

2〜5章は業務の流れと知識の姿でした。この章は、AI社員を配属するために必要な土台が現時点でどこまで揃っているか、いわばAI ready度を整理します。まず全体を一覧で示し、システム別の接続の詳細と、◯に変わるまでの道のりを続けます。判定はシステム構成からの推定で、確定は診断セッションで行います。判定の根拠を埋める作業は、付録Aの実装項目に対応づけています。

判定は4値です。◯ 足りている / △ 一部足りている・版による / ✕ これから整える / ? 診断セッションで確認。

✕と△が並びますが、いずれも第一・第二工程で埋まる種類のもので、どの工程で◯に変わるかは6-2に対応表があります。

6-1. 接続手段

接続のしやすさの列は、当社カタログの一般情報(◎ 公式APIが充実 / ○ APIあり / △ 版・契約による / ✕ 手作業前提)で、確定は導入時に版・契約を確認して行います。

6-2. AI readyまでの道のり

冒頭の一覧で✕と△が付いた観点は、10章の導入ステップの中で次の順に◯へ変わります。

6-3. この章の読み方

足りない項目が並びますが、いずれも第一工程(10章)の中で当社が主導して埋める種類の作業で、御社の業務を止めるものはありません。埋める作業の中身と順序は、業務の実物を拝見しないと確定できないため、診断セッションの議題とします。

スマレジ・KING OF TIME・LINE WORKSに公式のAPIがあり、売上実績・勤怠・連絡の3つがデータで取れることは、この規模の小売業では恵まれた条件です。発注量の判断に使う材料(売れ方・在庫・天候・催事)のうち、売れ方はすでにデータで存在します。整備の中心は、電話・FAX・対面の入口のデータ化と、Excelと記憶に散らばる在庫・発注判断の辞書化の2つに絞られます。

7. To-Be: 発注・在庫ワークフロー(AI社員配属後)

配属後の姿は、御社固有の情報(商品と仕入先の対応、店舗ごとの在庫表の読み方、部門別の発注量の目安、催事の実績、シフトの制約)を整理したうえに成り立ちます。この章の直前に差し込んだ立体の地図は、その整理の成果物の姿です。下段が情報の置き場所(接続に導入時の確認が要るものは接続候補と表示)、中段が御社の業務で共通に扱う実体とその関係、上段がAI社員に任せる仕事です。上段の仕事を選ぶとその仕事が使う実体・元データ・読み替えが光り、実体を選ぶと判断材料がどこから来てどの仕事につながるかをたどれます。実体をつなぐ線は、システムに記録済みのつながり、導入で整理して作るつながり、合っているかを照合するつながりの3種に分かれます。

そのうえで、2章で挙げた人手の支えを、それぞれどこでAI社員が引き継ぐかを対応づけます。

7-1. 配属案

7-2. 発注担当AIの職務定義

7-3. 配属後の発注フロー

flowchart TD
  smaregi["スマレジの販売実績"] --> ai["発注担当AIが理論在庫を算出"]
  nyuka["入荷・検品の記録"] --> ai
  haiki["廃棄・見切り・原料転用の記録"] --> ai
  ai --> an["発注案の作成<br>(部門別の目安・曜日・天候・催事を参照)"]
  an -->|"辞書の目安の範囲内"| teiji["店長・仕入担当へ発注案を提示<br>(根拠つき)"]
  teiji -->|"承認"| kihyo["アラジンオフィスへ発注を起票<br>Web発注可の先は八面六臂へ"]
  teiji -->|"修正"| shusei["数量を修正して承認"]
  shusei --> kihyo
  shusei --> tsuiki["修正の理由を意味辞書に追記<br>(版管理)"]
  an -->|"目安の範囲外<br>(相場変動・新商品・催事の初回)"| hokoku["例外としてLINE WORKSで報告<br>(論点と過去の実績を整理して提示)"]
  hokoku --> handan["店長・仕入担当が判断"]
  handan --> tsuiki
  tsuiki -.->|"以後、同型の判断はAIが案に反映"| ai
  kihyo --> denwa["電話・対面の発注は<br>AIが作った発注控えを人が読み上げ・提示"]
  denwa --> nohin["翌朝、納品をAIが発注内容と突合"]
  nohin -->|"相違あり"| renraku["相違一覧と連絡文の下書きを提示"]
  ai --> sai["棚卸差異の候補を日次で検知<br>(入力漏れ・値引き・転用・検品相違の別に整理)"]

発注はAIが決めるのではなく、AIが根拠のある案を出し、人が確定する形にします。電話・対面の発注は当面人が行い、AIが読み上げ用の発注控えを作って記録を残すところから始めます。これにより、聞き間違いがあった場合も、発注時点の内容が文字で残ります。

7-4. 配属後の店舗の1日

例外の比率は導入初期が最も高く、店長や仕入担当が修正した理由が辞書へ追記されるため、運用とともに下がる構造です。店長が休んだ日も、発注案と根拠が残っている状態から始められます。

8. To-Be: 本部・店舗間の連絡とシフト・報告ワークフロー(AI社員配属後)

8-1. 店舗運営AIの職務定義

8-2. 本部連絡の一元化

flowchart LR
  fax["FAX(PDF化)"] --> ai["店舗運営AIが読み取り・分類"]
  mail["メール"] --> ai
  lw_in["LINE WORKS"] --> ai
  ai --> ichiran["店舗別の未対応一覧<br>(依頼内容・期限・対象部門)"]
  ichiran --> lw_out["LINE WORKS の店舗トークルームへ通知"]
  lw_out --> jissi["店舗での実施"]
  jissi -->|"完了の記録"| ai
  ai -->|"期限が近い・未完了"| saikoku["リマインドと本部への状況報告"]
  ai -->|"売価変更の依頼"| baika["スマレジの売価との照合<br>未反映を検知"]

3経路に分かれて届く連絡が、店舗ごとに一本の未対応一覧に集約されます。店舗側は経路を追う作業から、一覧を消していく作業に変わります。

8-3. シフトと勤怠

8-4. 全店報告と会計のつなぎ

8-5. 時間の変化(推定)

実数の測定は、試用期間中に御社の店舗と帳票で行います(付録B)。

9. システム構成(To-Be)

flowchart TD
  aladdin["アラジンオフィス"] --> madoguchi
  smaregi["スマレジ"] --> madoguchi
  kot["KING OF TIME"] --> madoguchi
  yayoi["弥生会計"] --> madoguchi
  excel["Excel<br>在庫表・発注リスト・シフト表"] --> madoguchi
  hachimen["八面六臂<br>発注控え・帳票"] --> madoguchi
  faxin["FAX受信 / メール"] --> madoguchi
  madoguchi["各システムとAIの間の窓口(システムごとに設置)<br>・アクセスできる範囲の制御(権限)<br>・全操作の記録(監査ログ)<br>・意味辞書(商品コードの対応、発注量の目安、仕入先ごとの癖、正となる数字の定義)"]
  madoguchi --> hacchuAI["発注担当AI"]
  madoguchi --> tenpoAI["店舗運営AI"]
  hacchuAI -->|"発注案・差異報告・例外照会"| lw["LINE WORKS"]
  tenpoAI -->|"未対応一覧・シフト案・全店報告"| lw
  lw <-->|"判断・承認"| hito["店長・仕入担当・本部"]

• 既存システムの入れ替えは行いません。アラジンオフィス・スマレジ・KING OF TIME・弥生会計・八面六臂は現行のまま、AI専用の窓口を追加します。
• Excelで管理している在庫表・発注リスト・シフト表は、様式を突き合わせて共通の項目を定めたうえで窓口から参照します。運用中の帳票をそのまま使えるようにします。
• AIがシステムに触れる経路は窓口だけに限定され、窓口を通らないアクセスはできません。

意味辞書に登録する内容の一覧は、付録A-2にまとめています。

10. 導入ステップ

第一工程の内容は、6章で足りないとした項目にそのまま対応します。10店舗超あるため、まず1〜2店舗で始め、店舗を広げる形を取ります。

導入後に社内に残るものは次の3点で、いずれもファイルの形を持ちます。

1. 業務マニュアル。発注判断の材料と例外対応の追記を含む、版管理された手順書
2. 意味辞書。商品コードの対応、部門別の発注量の目安、仕入先ごとの癖などのデータの読み方の登録集
3. 監査ログ。AIがいつ何を参照しどの操作をしたかの全記録

新人への発注の指導が店舗に一人の方に集まっている状況に対しては、この1と2がそのまま教材になります。利用をやめた場合も、この3点は読める形式のファイルとして手元に残ります。

他の手段との比較

導入後も続く運用

業務は変わり続けます。新規出店、仕入先の入れ替え、季節と催事の巡り、使用システムの更新。月額利用の中では、例外判断のマニュアル・辞書への反映、接続先の変化への追従、対象店舗と任せる業務の拡張が続きます。AI社員の仕事の範囲は、配属時の定義から運用の中で広がっていきます。

実装項目の一覧は付録A、試用期間の検証計画は付録Bにまとめています。

11. セキュリティ設計

11-1. データの経路と実行の条件

• システム操作の実行は、依頼した本人・その場に同席する全員・AI社員自身の3者すべてに権限がある場合に限られ、未登録の操作・身元不明の参加者は拒否が既定値です。
• 発注の確定・売価の変更・シフトの確定などの重要操作には人の承認が必ず挟まり、許可・拒否を問わずすべての実行が監査ログに残ります。
• 店舗ごとの参照範囲を設定でき、自店のデータと本部が許可した範囲に限定できます。
• 提供環境は1社ごとに独立し、他社とデータベースを共有しません。

11-2. 導入時によく確認される事項

12. 提供体制

導入から運用まで、技術担当と導入支援担当が付きます。問い合わせは担当窓口に一本化します。

13. 御社版の作成にあたって

本書は架空企業のサンプルです。2〜6章のAs-Isはシステム構成からの推定であり、御社の実際の業務・数字・例外ルールを反映していません。

御社版の作成は、30分の診断セッションから始めます。セッションでは次の3点を持ち帰っていただけます。

1. 2章の一覧を御社の実際に合わせて確定した、人手が支えている箇所の一覧表
2. お使いのシステムの版に応じた、接続方式と可否の回答(アラジンオフィス・弥生会計の版、八面六臂の発注控えの形式を含む)
3. どの店舗・どの部門から、どんな体制で、どの程度の規模感で始められるかの初期見立て

セッションは技術担当が同席し、ご希望に応じてNDA締結後に実施します。議題は事前にお送りする内容に固定します。お申し込みは、ブースの担当者にお声がけください。

(セッションを予約されない場合、こちらからの営業連絡は行いません。)

付録A. 実装項目

実装の中心は、各システムとAIの間の窓口(標準規格MCPによる接続)の構築と、業務ナレッジ(意味辞書・業務マニュアル)の整備の2つです。項目をID付きで整理します。

A-1. 窓口の接続

すべての窓口に、アクセス範囲の制御と全操作の記録が標準で備わります。既製の接続部品がある接続先はそれを使い、ない接続先は個別に開発して納品します。

A-2. 意味辞書の整備

A-3. 業務マニュアルの整備

A-4. AI社員の設定

A-5. 開始前に一緒に確認する事項

いずれも第一工程の中で当社が主導して進めます。御社に単独でお願いする作業はありません。

A-6. 非機能要件

環境の独立と監査ログの扱いは11章のとおりです(保持期間は導入時に取り決めます)。

付録B. 試用期間(PoC)の検証計画

導入は試用期間として小さく始め、開始前に合意した水準で本番化を判定します。

B-1. 試用期間の範囲

B-2. 検証項目と指標

本番化の水準は試用期間の開始前に合意し、文書に残します。表の水準は例です。