CFCL IT統合プロジェクト
小売部門(リテール)現状業務フロー(As-Is)
作成日: 2026-07-14 | 読み取り専用の元資料(Retail Sales Operation Workflow メモ・分析レポート)に基づく
この資料について
小売部門(リテールオペレーションチーム)の現状業務を、担当者・部門・システムごとにレーンを分けたスイムレーン図で可視化しています。
左から右へ時間が流れる形で表示し、手作業・二重入力・システム分断・属人化が起きている箇所を赤系でハイライトしています。
未確定・要確認の箇所は黄土色で示します。
通常の業務ステップ
痛点(手作業・二重入力・属人化・分断)
未確認・推定(会議内で確定していない事項)
①日次売上 〜 月次集計フロー(二重入力)
EC・各店舗の日次売上を、月次で経営層向け「事業計画範囲」シートへ集約するまでの流れ。店舗側の入力が二重になっている点が最大の痛点です。
- 各店舗が閉店時にスマレジへ日次売上・KPIを入力する。
- ECの売上はCSチームが全体を確認し、0円計上などの不整合が無いか監視する。
- 店舗側は、①でスマレジへ入力した数字を、経営層向けの「リテール売上表」へあらためて手動で再入力している。二重入力
- EC返品・入金の不整合はCSが確認したうえで経理が処理する。
- リテールオペレーション(長谷川氏)が月次でEC・各店舗のデータを集計する。
- 集計結果は、あらかじめ組まれた数式により「事業計画範囲」シートのトップページへ自動反映される(この部分は自動化済み)。
- 経営層へ共有し、分析に活用する。
⚠ 痛点:店舗の日次入力と経営層向け集計シートの二重入力
現状、店舗での日次入力と経営層向け集計シートで二重入力が発生しており、作業負担が大きい。スマレジ等のデータから自動的に分析・抽出できる仕組みの導入・連携強化が今後の検討課題とされている。
ℹ️ 参考:週次売上報告は廃止予定
これまで運用していた週次売上報告は今後廃止され、該当情報はマーチャンダイジングカレンダーへ集約される方針(会議時点での決定事項)。
出典: Retail Sales Operation Workflow メモ(2026-07-01)詳細セクション「EC売上および決済の確認プロセス」「データ集計の効率化と将来展望」「週次売上報告の廃止」、文字起こし 00:39:41〜00:44、01:09:34
②リペアサービス集計フロー(属人化・シート分散)
お客様リペア案件の集計が、特定個人の空き時間に依存する運用になっている例です。
- 各店舗のリペア案件はスプレッドシートへ入力されるが、シートが3枚に分かれていた。シート分散
- もともとは大阪のスタッフが10日ごとに集計していた。
- 引き継いだ店舗スタッフが対応できなくなり、CS本来の業務ではないにもかかわらず一時的にCSへ集計が回ってきた。最終的にリテールオペレーション(長谷川氏)が3枚のシートを1枚にまとめ直した。属人化・引き継ぎ不全
- 現在は店舗スタッフ兼務の「前信さん」が、時短勤務の朝の空き時間を使って10日ごとに集計し、下げ札を作る会社へメールを送付している。会議では「本来はプロダクション(生産)業務では」という指摘もあったが、プロダクションチームも2名体制で手が回らず、現状の運用が続いている。属人化・手作業
⚠ 痛点:特定個人の空き時間に依存した運用
集計対象の担当者が異動・退職するたびに引き継ぎが破綻し、都度別の担当者(CS→リテールオペレーション→店舗スタッフ兼務者)へ業務が転々としている。自動化・業務移管(プロダクションチームへ等)が今後の検討事項とされている。
出典: Retail Sales Operation Workflow メモ(2026-07-01)詳細セクション「リペアサービス業務の運用」、文字起こし 00:15:52〜00:18:22
③顧客アンケート・データ管理フロー(セキュリティリスク)
顧客アンケートの集計フローと、その先で顧客連絡先データの管理体制に生じているセキュリティ上の懸念です。
- 会員登録後の自動メールに含まれるGoogleフォームで、購入者にアンケートを回答してもらう。
- 回答はスプレッドシートへ自動的に集約される。
- CSチームが随時確認し、気になる内容(不良品関連など)はすぐに社内共有・改善につなげている。アンケート件数自体はそれほど多くない。
- 長谷川氏がシーズンごと(半期に1度程度)にまとめて全社共有している。顧客連絡先の管理リスク
⚠ 痛点:顧客連絡先データの管理体制によるセキュリティリスク
顧客リストや連絡先情報は現状スプレッドシートで管理されており、複数の担当者が編集可能な状態にある。人的ミスによる誤送信のリスクが高く、過去に実際の誤送信事例も発生している。取引先・個人の名刺情報も各部署でそれぞれ個別に(名刺ベースで)管理されており、全社的な名寄せ・重複確認ができていない。CRM・SFA等の専門ツール導入が提案され、調査・提案を進める方針となった。
出典: Retail Sales Operation Workflow メモ(2026-07-01)詳細セクション「顧客アンケートの管理」「スプレッドシート管理におけるセキュリティリスク」「名刺管理と顧客データの現状」「システム化に向けた検討」、文字起こし 00:18:22〜00:22、00:57:36〜01:03:28
④ポップアップストア PL管理フロー(システム分断)
直営店とホールセールとで、実績データの取得方法が分かれている例です。
- シーズンが始まる前に、大枠の計画(日程・場所)だけを先に入力しておく。
- ポップアップの開催が決定し、条件が確定次第、担当プロマネ(自分・藤さん・高取さんの3人のいずれか)が計画値PLを記入する。
- 直営店で実施するポップアップは、終了後にスマレジの対象期間データから実績を自動的に抽出して入力する(表示上は青字)。
- ホールセールチームの国内ポップアップ(先方の店舗内で行う買い取り商品のポップアップ等)は、先方から受け取った実績データをもとに手作業で入力している(表示上は赤字)。手作業・外部依存
- 実績値を入力して完了させると、その結果が全社のPL(損益計画)に連動する仕組みになっている。
⚠ 痛点:直営店とホールセールでデータ取得方法が分断
直営店分はスマレジと連動して自動抽出できるが、ホールセール分は先方からのデータ受領に依存しており、取得方法が統一されていない。現状、ホールセールチームの体制が不安定でリテールチームがポップアップのプロマネ業務を支援しており、今後リテールとホールセールは「ジャパンビジネス」という一つの大きな組織に統合される方針(組織再編の過渡期)。
出典: Retail Sales Operation Workflow メモ(2026-07-01)詳細セクション「ポップアップストアのPL管理」「ホールセールとリテールのポップアップ運営」、文字起こし 00:23:13〜00:29:07
現状の主な課題
- 二重入力:店舗が日次売上・KPIをスマレジへ入力した後、同じ数字を経営層向けの「リテール売上表」へ手動で再入力しており、作業負担が大きい。
- 属人化:リペアサービスの集計は、大阪スタッフの10日ごとの集計 → リテールオペレーション(長谷川氏)による手動統合 → 前信さん(店舗スタッフ兼務・時短勤務の朝の空き時間を利用)というように、特定個人の空き時間に依存した運用になっている。
- システム間の分断:ポップアップの実績データは、直営店はスマレジから自動抽出できるが、ホールセールは先方から受領したデータをもとに手作業で入力しており、取得方法が統一されていない。
- 情報セキュリティリスク:顧客連絡先データは複数の担当者が編集可能なスプレッドシートで管理されており、誤送信のリスクが高い(過去に実際の事例あり)。名刺情報も部署ごとに個別管理されている。
- 帳票の所有者が曖昧:リペア・初期不良管理表は生産・物流・店舗・小売の4部門で共有されているが、オーナーが未定義(As-Is帳票マスタ突合表 I-4)。
- 組織再編の過渡期:ホールセールとリテールは「ジャパンビジネス」という一つの大きな組織に統合される方針だが、現時点ではポップアップ管理など一部業務の役割分担が流動的。
- 今後の変更予定:週次売上報告は廃止され、マーチャンダイジングカレンダーへ集約される方針(会議時点での決定事項)。
(推定・要確認)EC売上データの入力方法
EC売上データがShopifyから自動的に取り出されているのか、都度手入力されているのかは会議内で確認が取れておらず、担当者(長谷川氏)が「確認する」としたまま結論が出ていない。(推定:一部手入力の可能性あり/要確認事項)