忙しい方向けに、全体像を1画面で。
アパレル特化型ERPの DPシステム を新しい中核に据え、企画→受注→生産→発注→在庫→出荷→請求を1本につなぐ。 周辺システムは残したままAPI等で自動連携し、手コピペを廃止。マスタ（品番・取引先・顧客など）は「正本を1つに決めて参照する」形へ。
要件定義書v0.1が整理した「9つの現状課題（I-1〜I-9）」。これが全ての出発点。
| 課題 | 症状（現状で起きていること） | 根本原因 | 影響度 |
|---|---|---|---|
| I-1 システム間の手動連携 | AO⇄倉庫⇄スマレジ⇄Shopify をCSV手取込・手コピペで接続。「〜貼り付け(週次更新)」タブが集計簿に多数。倉庫連携は毎回エラー。 | API連携の欠如／マスタ非同期 | 最大該当20帳票+ |
| I-2 マスタの二重管理 | PLM(FUKU296)へ移行途中で不明点多数。GROUP MAP原本を全下流へ手動転記（1回の変更が11箇所へ波及）。 | 正本(SoT)未確定・移行未完 | 大15帳票+ |
| I-3 帳票の重複・版乱立 | 「VOL別在庫上代」が4コピー並存。変換マスタもCSVとスプレッドシートが二重。どれが原本か不明。 | 命名・版管理ルールの不在 | 大7帳票+ |
| I-4 帳票の所有者が曖昧 | 「リペア・初期不良管理表」が生産/物流/店舗/小売の4部門共有。オーナー未定義。 | 部門跨ぎ帳票の責任未定義 | 中8帳票+ |
| I-5 巨大集計簿の手作業BI | Season sales review（1.9万行×215列）等がAOの5テーブルを人手で取り込み週次更新。属人化。 | BI/レポート基盤の不在 | 大6帳票+ |
| I-6 マクロ／旧形式依存 | 見積FM（.xlsm・3,483列）・混率マクロが脆い。店頭日次売上が旧.xls。 | 脆い手組みツールの温存 | 中4帳票+ |
| I-7 データ品質・障害の未解決 | 商品マスタ登録エラーが常態化。未受入の積送在庫が調査中で未解決（担当者が原因特定中／盗難の可能性も指摘）。 | マスタ整備・連携検証の不足 | 中4帳票+ |
| I-8 会計・経費の手インポート | API未連携の銀行入出金を会計(MF)へ手インポート。経費(バクラク)も月次で手集計。 | 銀行/経費と会計の未連携 | 中3帳票+ |
| I-9 ヒアリング精度の濃淡 | MDは帳票名が空欄、BizDevは機密で2行のみ等、部門で棚卸しの粒度が不揃い。 | ヒアリング様式の統制不足 | 小— |
出典：As-Is帳票マスタ突合表「As-Is課題マップ」／要件定義書v0.1「00_概要・02_To-Be全体像」
8部門の業務メモ（会議文字起こし）から、各部門が「何をどう回しているか」と「痛点」を抜き出しました。共通するのはスプレッドシート属人化・二重入力・基幹システムとの非連携です。
| 部門 | 担っている業務 | 主なツール | 痛点（現場の声） |
|---|---|---|---|
| Design （企画） |
デザインデータ作成、サンプル発注（糸・付属）、約300色のカラーチャート選定、品質データ収集、インボイス／出荷書類作成。生産管理業務（糸発注）を生産チームへ移管予定。 | Procreate(iPad)、PDF/PSD、Excel、カラーチャート用スプレッドシート | デザインアプリが「PDFしか出力できずExcel化できない」。糸在庫がないとアップに間に合わないリードタイム問題。出荷書類・納品順ソートが「1個1個手動」で負荷大。 |
| MD （商品計画） |
週次の在庫・売上レポート作成、SKU別消化状況の追跡、在庫消化シミュレーション、価格改定、受注確認、店舗別発注分析。感覚発注→データ主導への移行を推進。 | Excel／スプレッドシート多数、Aladdin(AO)、スマレジ | 担当者が手動で全部作り「配信しても誰も見ない」。「AOとスマレジのデータ形式が合わず手作業で足し上げ」。受注確認ファイルで「毎シーズン数量の相違が発生」。 |
| Production （生産） |
工場見積の回収・原価算出、品質表／ケアラベル、下げ札・資材発注、納期管理、量産スペック更新。2名体制。 | 見積FM(.xlsm)、FUKU296、Aladdin(AO)、スプレッドシート(納期管理・リペア) | 「受注明細と実際の発注数が不一致、展示会発注とEC個人受注が混在し合計が合わない＝誰も正しい数がわからない」。「AOが活用されず無数のスプレッドシートが生成される」。速報後に数量が半減し工場が混乱。 |
| Factory （工場管理） |
量産の生産計画・進捗管理。機械の日産枚数から納期逆算でライン計画。原料発注、外注（検品・リンキング）手配、SHISEIDO Signature等の受注積上げ。 | ファクトリーライン表、入庫予定表、原料発注スプシ（個人管理）、AO、バクラク、マネーフォワード | 原料納期管理が「完全にメールのやり取り」でリスト化不十分。納品書を「誰も確認せず受け入れるだけ」。原価に個人ロジックが混入。業務フロー全体が未構築で、案件管理漏れから25万円の損害が発生した例も。 |
| Logistics （物流） |
倉庫WMS(ロジザード)とAOの在庫・売上・入荷連携（毎朝手動）、店舗/EC出荷指示、店舗間移動、不良・返品処理、卸売上申請・入金照合、百貨店伝票発行。 | ロジザード(LZ)、Aladdin(AO)、クロスモール、Excel多数、バクラク | AO⇄倉庫連携が「毎日手動でやらないとつながらない」。分納をAOが「全入荷と誤認」しエラー→手動Excel管理へ。「受け入れられていない／浮いている在庫」を担当者が調査中（8月末棚卸に向け原因未特定）。百貨店伝票・出荷メールが全て手作業。 |
| Retail Sales Operation （小売運営） |
EC・店舗・卸のCS横断管理、EC売上/返品集計、リペア集計、顧客アンケート、ポップアップPL管理、リテール全体のシフト・スケジュール管理。 | スマレジ、Googleフォーム、スプレッドシート、CRM/SFAは検討中 | 「店舗の日次入力と経営層向け集計で二重入力」。顧客連絡先をスプレッドシートで複数人が編集でき「誤送信リスクが高い」（過去に事例あり）。名刺も各部署で個別管理。 |
| Store （店舗） |
閉店時の日次売上入力、入店客数集計、顧客カルテ入力、在庫確認・フォロー発注、月次報告、棚卸、社販の給与天引き、小口現金・備品管理。 | スマレジ、Aladdin(棚卸Excel)、Shopify、紙の売上明細・連絡ノート | 「スマレジと紙のアナログ数字を突き合わせて手入力」。「在庫データがAladdinと連携しておらず乖離が発生」。連絡ノート・売上フォーマットが店舗ごとにバラバラ。 |
| International （海外卸） |
海外卸の価格決定（現地売価×掛け率）、顧客別予算/実績管理、消化率ヒアリング、セールスレポート／ラインシート作成、リオーダー運用。XW→DDP取引条件への移行が成長の要。 | JOOR（海外卸受注）、スプレッドシート多数、基幹システムのローデータ、AI(Claude等) | 「価格管理データ不足で手作業入力・集計」。SFA未活用で「500万回言っても入力してくれない」。PLシートが「複雑すぎて誰も触れず結局担当者がやる」属人化。ローデータにカテゴリ列がなく前加工が「超だるい」。 |
出典：8本のWorkflowメモ（Design/MD/Production/Factory/Logistics/Retail Sales Operation/Store/International）。※文字起こしのため固有名詞に一部揺れあり。
なぜ「手作業だらけ」になっているのか。棚卸しした79帳票の内訳と、散在の実態です。
| 種類 | 帳票の例 | 規模・実態 |
|---|---|---|
| 巨大な手集計簿 | Season sales review sheet | Item master 19,319行×215列。AOの5テーブルを人手で取込 |
| 巨大な手集計簿 | 【VOL.8】総在庫リスト | アイテムマスター 約104万行。全タブが「〜貼り付け」手コピペ層 |
| 重複・版乱立 | VOL別在庫上代 | 同じ帳票が4コピー（全社版/更新/全店結果/既存店結果）・各19タブ |
| 脆いマクロ依存 | 見積FM (Master_VOL13) | .xlsm・3,483列。マクロ依存で壊れやすい。原価管理の中核 |
| CSV手取込（エラー多発） | NOHSK / SHK / SNK / TOKSK（AO→倉庫LZ） | 得意先・出荷指示・積送入荷をCSVで手取込。倉庫連携の主戦場 |
| マスタ登録エラー常態化 | HIN_（商品マスタエラー）＋エラー内容CSV | 商品マスタ登録エラーがシーズン毎に発生（要根治） |
| マスタの二重持ち | 変換マスタ取り込みフォーマット | 同じ内容がCSVとGoogleスプシで並存 |
| 未取得の実体スプシ | Factoryライン表／入庫予定表／海外卸トラッカー等 | 7点はGoogleスプシ実体（今回フォルダにコピー無し・要別途取得） |
下表の「●」が、人手でデータを貼り付けている接続点。Aladdin(AO)・倉庫WMS・スマレジの列に集中しており、ここが統合の主戦場です。DP（新）はまだほぼ空欄＝これから受け皿になります。
| 部門＼システム | Aladdin(AO) | 倉庫WMS(LZ) | スマレジ | Shopify | FUKU296 | JOOR | 会計(MF) |
|---|---|---|---|---|---|---|---|
| Design | ● | ||||||
| MD | ● | ● | ○ | ||||
| Production | ● | ● | |||||
| Logistics | ● | ● | ○ | ||||
| Store/Retail | ● | ● | ○ | ||||
| International | ○ | ● | |||||
| Finance | ○ | ● |
●=手作業連携ホットスポット／○=利用。出典：As-Is帳票突合表「システム連携マトリクス」「サマリ」。
新中核「DPシステム」＝アパレル特化ERP。企画から卸請求までを1本でつなぐ9つの機能領域を持ちます。要件定義はv0.1（ドラフト）まで到達。
| 現行システム | 役割 | 新方針 |
|---|---|---|
| Aladdin / AO | 基幹（受発注・在庫・仕入・売上） | DPへ移行し廃止（現状の“手貼り付け”の発生源） |
| FUKU296 (PLM) | 商品/品質マスタ | 正本(SoT)として残置 → DPが参照連携 |
| 倉庫WMS(ロジザード) | 入出庫・在庫 | 残置 → API連携（現状“毎回エラー”を解消） |
| スマレジ / Shopify | 店頭POS / EC | 残置 → API連携で在庫・売上を自動同期 |
| JOOR | 海外卸受注 | 【要判断】残して連携 or DP注文管理へ集約 |
| MF会計 / バクラク / 銀行 | 会計・経費・入出金 | 残置 → DPは請求(AR)まで、GL/決算はMF。連携で手インポート廃止 |
| フェーズ | 狙い | 主な対象課題 | Go-Live試算 |
|---|---|---|---|
| Phase1 基盤・最大課題 | マスタ正本化＋DPコア立上げ（企画〜受注）＋手作業連携の廃止 | I-1, I-2, I-3 | 2026/12/14 |
| Phase2 出荷・請求 | 在庫/出荷/請求・入金をDPで運用しMF会計へ連携 | I-7, I-8 | 2027/03/22 |
| Phase3 高度化 | Sell-ThroughのBI自動化、銀行・経費の会計連携 | I-5, I-8 | 2027/04/26 |
出典：要件定義書v0.1「07_フェーズ計画」／WBS_Gantt_v0（開始2026-08-03・最短試算）。体制：要件統括=大野氏、実装=MCF(中原氏)、承認=松浦氏。
コンサル側（CEO）が7/17のベンダー確認MTGで押さえるべきポイントを、重要度順に整理しました。
| リスク | 内容 | 示唆 |
|---|---|---|
| 連携の技術的実現性 | 倉庫WMS連携が現状エラー多発。API化の可否・工数が未知 | 7/17でベンダーに実現可否と概算を持ち帰らせる。不可なら計画全体の見直し |
| データ品質（移行の足かせ） | 商品マスタ登録エラー(HIN)が常態化。未受入の積送在庫が未解決（原因特定中） | 移行前にデータクレンジングと8月末棚卸での実在庫確定が必須 |
| マスタ名寄せの負荷 | 品番・取引先・生地・顧客が複数の所に重複。正本確定に部門横断の作業が必要 | Phase1のクリティカルパス。部門別に名寄せ担当を割り当て済（WBS 4章） |
| 現場の定着（人の問題） | 「配信しても誰も見ない」「SFAに入力してくれない」等、ツール以前の運用課題 | 技術導入と並行して部門別教育・運用ルール定着（横断タスク）が必要 |
| 棚卸し精度の濃淡 | MD・BizDevはヒアリングが手薄（I-9） | 要件v1.0確定前に追加ヒアリングで台帳を均質化（8月） |
| ベンダー依存の集中 | 実装がMCF(中原氏)中心。要件統括も少人数 | 保守体制・オーナー定義を早期に。属人化の再生産を避ける |