Purpose
目的と背景
「この1年で会社のDXをある程度完成させる」——その実現に向けたご提案です。
現状は、顧客対応は Zoho CRM、販売伝票は手書き、在庫・製造は業界専用システム（GEM）と、ツールごとに情報が分断しています。さらに GEM は Windows 11 に対応するには実質的な買い替え相当の費用がかかり、クラウド非対応・他システムと連動できないという制約があります。本ご提案は、この分断を解消し、業務を一気通貫でつなぐ仕組みを示すものです。
御社が定めた優先順位
PRIORITY 1
販売管理 × 顧客管理の連動
全チャネルでデータを一本化。
PRIORITY 2
在庫連動
売れたら在庫が自動で減る「売り消し」。
PRIORITY 3
組立・製造加工管理
素材＋加工費を足し上げ1製品へ。当面は後段で。
システム化はあくまで「お客様と向き合う時間」と「一人当たりの生産性」を増やすための手段です。御社の強みである人間的なコミュニケーションとコンテンツ発信を守りながら、作業だけを効率化することを基本姿勢とします。
Current Issues
現状の課題
ツールは揃いつつあるものの、情報が「バラバラ」に分断している——これが核心です。
| 課題 | 現状 | 影響 |
|---|---|---|
| ① 二重入力で記録が定着しない | 手書きの販売・預り伝票を起票し、さらに Zoho CRM へ再入力。手間ゆえ全販売・修理履歴の入力が徹底できない。 | 入力ハードルが高く、データの網羅性が欠ける → 追客・分析が成り立たない。 |
| ② 情報の分断 | 顧客＝Zoho／商品・在庫・組立＝GEM／販売＝手書き／会計＝みろく／接点＝LINE・クラブバール・DG1・Shopify。 | 「あのお客様が昔何を買ったか」が一瞬で出てこない。横断できない。 |
| ③ 購買履歴がCRMにない | Zoho は「やり取り」中心で、売上が入っていない。 | 顧客台帳としての価値が出ず、追客の土台がない。 |
| ④ GEMの老朽化 | Windows11対応は買い替え相当の費用。クラウド不可・連動不可。顧客約1,000名・在庫・組立加工を管理。 | 続けるのも乗り換えるのもコスト。動けない状態。 |
| ⑤ 属人化・紙資産の死蔵 | 過去の購買履歴やオーダーのデザイン画は紙ファイルで、検索性がない。 | 担当者でないと分からず、少人数で量が増える中で情報共有が回らない。 |
| ⑥ 経営の可視化が弱い | 売上・点数・目標対比を示すダッシュボードがない。 | 数値で確認・共有できず、判断が感覚に依存しがち。 |
| ⑦ セキュリティ | 免許証など機密情報を LINE の写真で受け取る運用が残る。県外取引・高額品が増加。 | 事故時のリスクが大きい。信頼商売の根幹に関わる。 |
| ⑧ 販売チャネルの多様化 | サロン手書き／DG1（EC）／Shopify と入口が複数。 | どの入口で売れても、データを一本化したい。 |
Our Approach
解決の全体方針
顧客・取引（需要側）は Zoho CRM、仕入れ・製造・在庫（供給側）は Webアプリ で持ち、両者をデータ連携でひとつなぎに。
1. 顧客・商談・履歴は Zoho CRM に集約
既存の商談・オーダー進捗のカスタマイズはそのまま活かし、ゼロからやり直しません。売上・接客記録を顧客に紐づけ、カルテを「台帳」として機能させます。
2. 仕入れ・在庫・組立はWebアプリで構築
宝飾特有で癖のある業務は、業務フローに合わせて作成し CRM と連携。現場の二重入力をゼロにします。
3. Zoho は CRM のみを利用
在庫・仕入れ・原価は Webアプリ側で持ち、会計は既存の「みろく」を継続。CRM に業務を詰め込み過ぎず、役割を明確に分けます。
4. 守るのは「人」、効率化するのは「作業」
入力ハードルを下げ（起票＝記録／音声入力）、ダッシュボードで情報を集約。セキュリティ・法令対応（機密情報の安全な扱い、古物・本人確認）は設計に内包します。
なぜこの構成か（CRM のみで完結しない理由）
| 観点 | CRM だけで構築 | CRM ＋ Webアプリ連携（本提案） |
|---|---|---|
| 顧客・履歴 | ◎ | ◎ |
| 仕入・在庫・原価・組立 | △ 標準機能には非常に乗せにくく、柔軟性に欠ける | ◎ 業務フローどおりに自然に持てる |
| 業務フィット | 宝飾固有UIを作り込み続けて頭打ち | 癖のある部分を業務に合わせて作れる／二重入力をゼロにしやすい |
| 役割分担 | 1つに詰め込み過ぎる | CRM＝顧客・取引、Webアプリ＝供給・製造で明確 |
顧客・商談・受注伝票だけなら CRM で足りますが、仕入れ・在庫・組立まで含めると CRM＋Webアプリ連携が現実解です。
課題 → 打ち手の対応
| 課題 | 打ち手 |
|---|---|
| ① 二重入力 | 受注伝票を Web/タブレットで起票し、同時にCRMへ記録。音声入力で接客記録を省力化。 |
| ② 分断 | 顧客＝CRM に集約、仕入・在庫・製造＝Webアプリ、データ連携で横串。1顧客ビューに統合。 |
| ③ 履歴なし | 売上を必ずCRMに残す設計。過去3年分の伝票を移行入力。 |
| ④ GEM老朽化 | クラウドWeb＋スマホ/タブレットで脱オンプレ。顧客約1,000名はCSVで移行。 |
| ⑤ 属人化 | 接客記録・デザイン画を顧客に紐づけ検索可能に。担当引き継ぎができる状態へ。 |
| ⑥ 可視化 | 売上KPI・カテゴリ別・目標対比のダッシュボード。 |
| ⑦ セキュリティ | 機密情報の安全な収集経路、権限／操作ログ、古物・本人確認の運用設計。 |
| ⑧ チャネル | まずサロン販売の売上＋顧客をCRMに一本化。DG1・Shopifyは連携方式（API/CSV取込）を要件定義で確認のうえ、段階的に取込を目指す。 |
Architecture
システム全体像
「需要・取引」と「供給・製造」で正データを分け、受注伝票と製品で紐づけます。
構築の進め方（大枠フロー）
① 現状ヒアリング現行システム（GEM・CRM）の概要と業務フローを現場で確認
② 要件定義画面・項目・帳票・連携方式を確定（動くモックを土台に）
③ 構築Phase単位でAI駆動開発
④ 試験運用実データでトライアル・現場フィードバック反映
⑤ 受け入れ・本稼働チェックリストで検収 → 本稼働
以下のシステム概要は現時点の構成案です。①現状ヒアリング・②要件定義を経てモジュール構成・項目・連携方式の詳細を確定したうえで構築に入り、各Phaseとも試験運用→受け入れ（検収）を経て本稼働します。
システム概要（構成案）
Zoho CRM
需要・取引の正（顧客が見える）- 顧客マスタ／記念日・好み
- 接客・相談記録／商談
- 受注伝票（ウィジェットで起票）
- 納品（売上）伝票／購買履歴
▲▼ データ連携（API）：顧客は CRM を参照 ／ 受注 ⇄ 製品を紐付け ／ 製造データは CRM画面にウィジェットで表示
新Webアプリ
供給・製造・在庫の正（業務に合わせて作る）- 発注（資材＝モノ＋外注加工費）→ 入庫
- 組立・製造加工管理（BOM・原価積上げ）
- 個別番号の発番・来歴・バーコード
- 資材在庫 ／ 製品在庫
CRM の受注伝票画面から、Webアプリの製造データ（発注・入庫・組立進捗・原価）をウィジェットで参照できます。CRM に居ながら製造状況が見えます。
Business Flow
業務フロー：受注 → 製造 → 納品
オーダーメイドの基本形です（例：山田様のフルオーダー1件が①→⑦を流れます）。CRM と Webアプリ で役割を分け、各ステップに現場で触れる画面イメージを添えています。動くモックあり ↗ を押すと該当画面のモックが別タブで開きます。
1
受注CRM 動くモックあり ↗
商談から受注伝票を起票（現行の紙伝票に近い入力画面）。顧客はCRMから呼び出して自動入力し、起票がそのまま顧客の記録になります。データはCRMに保存。「どの製品を作るか」を選定し、受注フェーズで一旦確定。同じ画面のタブ切り替えで「加工依頼書」「お預り引換証」も起票できます。
商談から受注伝票を起票（現行の紙伝票に近い入力画面）。顧客はCRMから呼び出して自動入力し、起票がそのまま顧客の記録になります。データはCRMに保存。「どの製品を作るか」を選定し、受注フェーズで一旦確定。同じ画面のタブ切り替えで「加工依頼書」「お預り引換証」も起票できます。
CRMから顧客を呼び出す：山田 ✓ 山田 花子 様（CST-00123）を呼び出しました
お名前山田 花子 様担当嶋
ご住所〒930-0001 富山市新富町…TEL076-441-****
お誕生日1975/04/12結婚記念日1999/06/20
| 商品番号 | 品名 | ご購入額（税込） |
|---|---|---|
| （受注時に発番） | Pt ダイヤリング 0.32ct（フルオーダー） | ¥418,000 |
内金 ¥100,000（受注時）合計 ¥418,000（内税）
🖨 伝票を印刷CRMへ受注データを保存
※ 既製品の販売時は、バーコードをスキャンすると明細が自動入力（自動起票）されます。
2
発注Webアプリ 動くモックあり ↗
資材（ダイヤ／ルース／地金／原型）＋外注加工費（役務）を同じ発注に登録し、原価の元データにします。外注依頼の加工伝票はここから生成します。
発注を登録🖨 加工伝票を出力
資材（ダイヤ／ルース／地金／原型）＋外注加工費（役務）を同じ発注に登録し、原価の元データにします。外注依頼の加工伝票はここから生成します。
受注No.113100（山田様・CRM連携）目的顧客向け（受注紐付けあり）
発注先提携工房A弊社納期2026/07/15
| 区分 | 内容 | 金額（原価） |
|---|---|---|
| 資材 | ダイヤ 0.32ct | ¥＊＊＊,＊＊＊ |
| 資材 | Pt900 地金 | ¥＊＊,＊＊＊ |
| 外注加工費 | キャスト・石留め | ¥＊＊,＊＊＊ |
※ デザイン指示書は従来通り紙で添付（システム非依存）。
3
入庫Webアプリ 動くモックあり ↗
発注に対し資材が入庫 → 資材在庫へ。「頼んだのに届いていないもの」も一覧できます。
発注に対し資材が入庫 → 資材在庫へ。「頼んだのに届いていないもの」も一覧できます。
| 発注No. | 内容 | 状態 | |
|---|---|---|---|
| PO-0245 | ダイヤ 0.32ct | 未入庫 | 入庫 |
| PO-0246 | Pt900 地金 | 入庫済 ✓ | |
| PO-0247 | 外注加工（キャスト・石留め） | 作業中 |
入庫を確定すると資材在庫に計上され、組立（STEP 4）で使えるようになります。未入庫の残がひと目で分かります。
4
組立・製造加工管理Webアプリ 動くモックあり ↗
入庫資材＋外注加工費を足し上げ（BOM・原価積上げ）→ 完成品に個別番号を発番。売上（CRM）との突合で1点ごとの粗利が見えます。進捗は 受付→デザイン→見積承認→製作（自社/外注）→検品→納品 をボードで可視化（下の組立カンバン参照）。
入庫資材＋外注加工費を足し上げ（BOM・原価積上げ）→ 完成品に個別番号を発番。売上（CRM）との突合で1点ごとの粗利が見えます。進捗は 受付→デザイン→見積承認→製作（自社/外注）→検品→納品 をボードで可視化（下の組立カンバン参照）。
製造案件山田様 Pt ダイヤリング（受注 113100）工程検品 → 完成
| 構成（BOM） | 原価 |
|---|---|
| ダイヤ 0.32ct（PO-0245） | ¥＊＊＊,＊＊＊ |
| Pt900 地金（PO-0246） | ¥＊＊,＊＊＊ |
| 外注加工費（PO-0247） | ¥＊＊,＊＊＊ |
原価合計¥＊＊＊,＊＊＊
完成 → 個別番号を発番（J-210712）
5
製品在庫Webアプリ 動くモックあり ↗
販売用の製品在庫ができ、バーコードを払い出し。完成品は個別番号＋バーコードで管理します。
販売用の製品在庫ができ、バーコードを払い出し。完成品は個別番号＋バーコードで管理します。
| 個別番号 | 品名 | 状態 | 受注紐付け |
|---|---|---|---|
| J-210712 | Pt ダイヤリング 0.32ct | 売約 | 113100（山田様） |
| J-173061 | トラピッチェエメラルド 1.53ct | 在庫 | —（販売時に引き当て） |
バーコード払い出し：▮▮▯▮▮▯▮▮▮▯▮▮ J-210712
受注に紐付け来歴を見る
6
紐付け
製品 ⇄ 受注伝票（受注に紐付ける／在庫として後で引き当ても可）。オーダー品は受注に紐付け、店頭在庫品は販売時のスキャンで自動起票・引き当て（売り消し）します。画面はSTEP 5の製品在庫画面に含まれます（「受注紐付け」列・「受注に紐付け」ボタン）。
製品 ⇄ 受注伝票（受注に紐付ける／在庫として後で引き当ても可）。オーダー品は受注に紐付け、店頭在庫品は販売時のスキャンで自動起票・引き当て（売り消し）します。画面はSTEP 5の製品在庫画面に含まれます（「受注紐付け」列・「受注に紐付け」ボタン）。
7
納品CRM 動くモックあり ↗
製品をお客様へ納品し、残金を決済して売上計上 → 納品（売上）伝票。受注伝票・製品（個別番号）と紐づき、そのまま顧客の購買履歴に残ります。
製品をお客様へ納品し、残金を決済して売上計上 → 納品（売上）伝票。受注伝票・製品（個別番号）と紐づき、そのまま顧客の購買履歴に残ります。
受注No.113100 山田 花子 様納品日2026/07/10
品目Pt ダイヤリング 0.32ct（J-210712）
お支払い内金 ¥100,000（受注時）／ 残金 ¥318,000 カード・現金・掛・ローン・分割
売上計上¥418,000（内税）→ みろくへ仕訳連携
納品（売上）を確定🖨 ご請求明細書
確定と同時に：購買履歴へ記録（CRM）／製品在庫を売り消し（Webアプリ）。
デモできる画面：①の受注伝票（＋加工依頼書・お預り引換証）は帳票入力モックで、顧客呼び出し → 明細入力（バーコードスキャン）→ 保存までを実演できます。②〜⑦は業務モック（CRM＋Webアプリ）で、入庫 → 組立完成（個別番号発番）→ 納品確定（購買履歴へ記録・在庫の売り消し）までの画面間の連動を実際に操作いただけます。本開発では、これらのモックを土台に要件をすり合わせながら作り込みます。
仕入れの実体：宝飾では 資材（モノ）＋外注加工費（役務）の両方を「仕入れ」として登録し、組立で足し上げて1つの完成品（個別番号）にします。
製造の有無は2通り：オーダーメイドは受注に紐づけて製造／既製品・委託品・見込み生産は先に製品在庫を作り後で引き当て。どちらにも対応します。
在庫は2層：未完成の「資材在庫」と、完成した「製品在庫」を分けて管理します。
発注先は基本1箇所：1件の受注に対し発注先（提携工房）は多くの場合1箇所。材料も多くは提携先が用意し、リフォーム等の持ち込み・自社コレクション充当時のみ自社在庫から送付します。
加工依頼の書類：外注依頼は「加工伝票」で行い デザイン指示書を併せて送付。加工伝票はWebアプリから生成しますが、デザイン指示書は個別性が高く従来通り紙運用（システム非依存）とします。
発注の目的を区別：同じ発注・入庫でも「顧客向け（受注紐付けあり）」か「在庫補充向け（受注紐付けなし）」かを区別して登録し、顧客向けはそのまま売上に紐付けます。
製造の有無は2通り：オーダーメイドは受注に紐づけて製造／既製品・委託品・見込み生産は先に製品在庫を作り後で引き当て。どちらにも対応します。
在庫は2層：未完成の「資材在庫」と、完成した「製品在庫」を分けて管理します。
発注先は基本1箇所：1件の受注に対し発注先（提携工房）は多くの場合1箇所。材料も多くは提携先が用意し、リフォーム等の持ち込み・自社コレクション充当時のみ自社在庫から送付します。
加工依頼の書類：外注依頼は「加工伝票」で行い デザイン指示書を併せて送付。加工伝票はWebアプリから生成しますが、デザイン指示書は個別性が高く従来通り紙運用（システム非依存）とします。
発注の目的を区別：同じ発注・入庫でも「顧客向け（受注紐付けあり）」か「在庫補充向け（受注紐付けなし）」かを区別して登録し、顧客向けはそのまま売上に紐付けます。
受注以外の業務フロー（修理・買取・店頭在庫品）
オーダーメイドの基本形とは別に、入口の異なる3つのフローに対応します。いずれも最終的に CRM の受注・納品（売上）伝票へ集約し、顧客の購買履歴に残します。
| フロー | 流れ | 仕入れ／在庫 | 売上の立て方 |
|---|---|---|---|
| 修理 | お預かり → 内容決定 →（必要時のみ）発注 → 作業 → 納品 | 仕入れが発生しない場合あり。物（在庫）は増えない | 作業発生に伴い「修理」伝票で売上計上（例：チェーンつなぎ合わせ） |
| 買取 | 査定・買い取り → 自社在庫／素材コレクションへ受け入れ | 在庫・素材として受け入れ。後の製造・リフォームに充当可 | 買取として記録（リフォーム併用時は基本フローへ） |
| 店頭在庫品の販売 | 本社で製造・発注した在庫を店頭に積み上げ → 販売 | 受注紐付けなしで先に製品在庫化 → 販売時に引き当て | バーコード自動起票で受注伝票を起票・引き当て |
修理は「先にお預かり・発注 → 作業 → 売上」という製造とは順序の異なるフローです。仕入れの有無に関わらず、伝票入力を通じて売上を必ず記録します。リフォームで複数点を預かり、一部はオーダー・残りは買取という複合ケースも、上記フローの組み合わせで扱います。
受注伝票の起票は2経路
| 経路 | 場面 | 起票UI | 顧客マスタ | 受注データ |
|---|---|---|---|---|
| (a) 手入力 | 商談からの受注（オーダー等） | CRM ウィジェット（紙伝票に近いUI） | CRM を参照 | CRM が正 |
| (b) バーコード自動起票 | 完成品の販売時 | WebアプリのスキャンUI（スマホ可） | CRM を参照 | CRM が正 |
製造完了で製品にバーコードを払い出し。販売時にスマホ等でスキャンすると、受注伝票が自動起票（顧客は CRM を参照）され、同時に製品在庫から引き当て（売り消し）。製造した製品が「在庫 ⇄ 受注伝票」に一気通貫で紐づきます。
現行帳票3種の電子化
現行の手書き帳票3種を、項目・体裁を踏襲して電子化します。起票がそのまま記録になります。
| 現行帳票 | 内容 | 保持側 | 出力タイミング |
|---|---|---|---|
| ① ご請求明細書 | 受注・納品（売上）：明細・決済・ポイント | CRM（ウィジェット起票） | 納品/会計確定時 |
| ② 加工依頼書（控） ※デザイン指示書は従来通り紙運用 | 製造指図：加工区分・使用地金・ルース・原型番号 | Webアプリ（受注から生成） | 受注後の製造手配時 |
| ③ お預り引換証（控） | 預り品：受付日・返却予定日・品目 | 要確認（CRM/Webアプリ） | 預り受付時 |
組立・製造加工管理のカンバン（イメージ）
受注した製造案件を工程ごとのカードで可視化。自社／外注の別・担当・納期がひと目で分かります。Webアプリ
受付 2
田中 様K18 リング（フルオーダー）担当: 専務納期 7/20
小林 様ルース → ペンダント加工担当: 山田
デザイン・CAD 1
佐藤 様ファンシーカラー ペンダントCAD: デザイナー納期 7/28
見積・承認 1
鈴木 様リフォーム（指輪→ペンダント）見積 ¥180,000承認待ち
製作 2
山本 様Pt ダイヤリング外注: 鋳造納期 7/15
伊藤 様真珠ネックレス 修理自社納期 7/10
検品 1
渡辺 様K18 ピアス検品: 良
完成・納品 1
中村 様エメラルド リング個別番号 発番済7/8 納品
各カードは「受注伝票（CRM）」と紐づき、素材＋外注加工費の積み上げ（原価）を保持します。完成（最終列）で個別番号を発番・バーコードを払い出し、製品在庫へ。納期超過はダッシュボードの「やること」に表示します。
現状も CRM 上で個別案件の進捗は確認できますが、一覧で全案件を見渡せず停滞の把握が難しいのが課題です。本ボードは週1回のオーダーミーティング（申し送り）を補完し、「どこで止まっているか」を一覧化して取りこぼしを防ぎます。
現状も CRM 上で個別案件の進捗は確認できますが、一覧で全案件を見渡せず停滞の把握が難しいのが課題です。本ボードは週1回のオーダーミーティング（申し送り）を補完し、「どこで止まっているか」を一覧化して取りこぼしを防ぎます。
Function Mapping
GEM機能の振り分け
全機能を移植するのではなく、実際に使っている中核を再構築します。
| GEM の機能 | 内容 | 振り分け |
|---|---|---|
| 仕入れ管理 | 資材（モノ）＋外注加工費の入荷・原価記録 | Webアプリ |
| 在庫管理 | 個別番号・来歴（在庫/加工中/売約/販売済）・売り消し・棚卸 | Webアプリ（優先2） |
| 販売管理 | 受注・納品（売上）・帳票 | 受注/納品＝CRM（ウィジェット）、付帯帳票＝テンプレ出力 |
| 顧客の購買履歴 | 顧客に売上・オーダー・修理を紐づけ | CRM |
| 組立・製造加工管理 | 素材＋加工費を1製品に足し上げ | Webアプリ（優先3） |
| 商品マスタ・個別番号 | 在庫・売上・オーダー・組立を貫く軸 | Webアプリ（GEMから移行） |
顧客約1,000名・在庫データは CSV で移行可能です。委託・催事・買掛/売掛・上代改定・RFID など GEM の上位機能は、現状の運用規模では当面対象外とし、必要になった時点で追加します。
実装のポイント
帳票
HTML/CSS ＋ PDF
現物に合わせたテンプレートでPDF生成・店頭印刷。控えの2部運用を踏襲し、発行PDFは顧客カルテに添付して紙の死蔵を解消。署名が要る預りはタブレット署名／印刷サインに対応。
バーコード
既存資産を起点に
GEMの個別番号をそのまま主キーに引き継ぎ、既存タグは貼り替え不要。読取はリーダー＋スマホカメラ、発行はラベルプリンターで2面タグ（プライス＋管理）。点数増加時はRFIDを将来オプションに。期末棚卸（タグを1点ずつスキャン）も現行運用のまま継続し、システム在庫と自動突合して差異を一覧化。
組立
BOM＋進捗ボード
部材（地金・ルース・原型）＋外注加工費を1製品に足し上げ原価を集計。加工依頼書を入口に進捗をボードで管理し、完成時に個別番号を発番・バーコード発行。
技術構成
| レイヤ | 構成 | 用途 |
|---|---|---|
| フロント | React / Next.js（PWAでスマホ対応） | タブレット入力・進捗ボード・帳票プレビュー・スキャン |
| バック / DB | API ＋ PostgreSQL（クラウド） | 商品・在庫・仕入・製造・受注の管理 |
| 帳票 | HTML/CSS ＋ PDF 生成 | 帳票発行・店頭印刷 |
| バーコード | 生成ライブラリ＋リーダー（カメラ併用） | 払い出し・スキャン起票 |
| 連携 | Zoho CRM REST API | 顧客参照・受注/売上/履歴の記録 |
| 基盤 | 認証・権限・操作ログ | セキュリティ／古物・本人確認 |
Roadmap
実装の進め方・スケジュール
御社の優先順位に沿って段階的に進め、2027年4月（30周年イヤー）に受注→製造→納品の一気通貫を完成させます。
PHASE 0
要件定義・Zoho課題の棚卸し
2026年8〜9月｜5人日業務密着ヒアリングをもとに画面・項目・帳票・連携方式を確定し、既存Zoho CRMの設定・運用課題を総点検。構築の土台を固め、後工程の手戻りをなくします。
PHASE 1
受注伝票の電子化 ×「売上↔顧客」連動 ＜最優先＞
2026年9月末〜12月 開発・試験 → 12月 本稼働｜17人日Phase 0 の前半で要件を確定し、9月末から開発を並行開始。まずサロン販売の売上＋顧客をCRMに一本化（DG1・Shopifyは要件定義で連携方式を確認のうえ段階的に取込）。顧客カルテ／購買・接客履歴を整備。過去3年分の伝票移行入力を並行。古物・本人確認も設計。12月から手書き伝票を卒業し、サロンの販売がCRMに記録され始めます。
PHASE 2
在庫管理 × 販売連動 ＋ 仕入れ
2026年12月〜2027年2月 → 3月 本稼働｜18人日バーコード自動起票による売り消し・個別番号来歴。仕入れ（発注・入庫）を含む。GEMからCSV移行。期末棚卸に突合機能の実地検証を合わせます。ここでGEM卒業の目処。
PHASE 3
組立・製造加工管理
2027年2〜3月 → 4月 本稼働｜10人日素材＋加工費を1製品へ足し上げる工程（BOM・原価積上げ・工程カンバン）。GEM固有機能を再現し、一気通貫が完成。5〜6月は定着支援。
マイルストーン
| 時期 | マイルストーン | 内容 |
|---|---|---|
| 2026年7月 | 要件確定・補助金申請 | 業務密着ヒアリング（1〜2日）→ 費用確定 → 7/30までに富山県DX申請 → ご契約 |
| 2026年8〜9月 | Phase 0（要件定義・Zoho課題の棚卸し） | 要件・Zoho総点検。Phase 1の要件は前半で確定し、9月末からPhase 1開発を並行開始 |
| 2026年12月 | Phase 1 本稼働 | 手書き卒業。移行入力（過去3年分）はここまでに完了が理想 |
| 2027年3月 | Phase 2 本稼働 | 「売れたら在庫が減る」実現。GEM卒業 |
| 2027年4月 | Phase 3 本稼働＝全体完成 | 受注→発注→入庫→組立→在庫→納品の一気通貫。30周年に間に合わせる |
大切な設計判断：Phase1の段階で、将来の在庫・組立連動を見越した商品マスタ／個別番号（品番・バーコード）の持ち方を決めておきます。後付けでの手戻りを最小化するためです。
試験運用（トライアル）：本システムは新規に構築するものであるため、各Phaseの本稼働前に実データを使った試験運用期間を設けます。「実際に運用してみないと分からない」部分を試験運用で洗い出し、現場のフィードバックを反映してから本稼働へ切り替えます。
スケジュールの要：①7/30の富山県DX申請期限から逆算し、7月中旬までのヒアリング実施が必須。②補助金は交付決定前の着手分が対象外となる制度が多いため、Phase 0のみ先行着手（補助対象外）とし、Phase 1以降を補助対象に切り分ける進め方を推奨します。
Investment
費用・お支払い・補助金（概算）
全体50人日・350万円（税別）の概算です。※モックを仕様として確定する「進め方の条件」つきの価格です（下記）。
概算お見積り（税別）
| Phase | 内容 | 工数 | 金額 |
|---|---|---|---|
| Phase 0 | 要件定義・Zoho課題の棚卸し | 5人日 | ¥350,000 |
| Phase 1 | 帳票3種の電子化（CRMウィジェット）・購買履歴・移行基盤・試験運用（Shopify/DG1はCSV取込まで） | 17人日 | ¥1,190,000 |
| Phase 2 | Webアプリ基盤・発注入庫・在庫2層・バーコード・GEM移行・試験運用 | 18人日 | ¥1,260,000 |
| Phase 3 | 組立BOM原価積上げ・工程カンバン・加工伝票・試験運用 | 10人日 | ¥700,000 |
| 合計 | 50人日 | ¥3,500,000（税込 ¥3,850,000） |
概算の前提：①Shopify・DG1の自動連携（API）は要件定義で仕様確認のうえ別途見積（本概算は両方ともCSV/手動取込まで。月100件未満の件数規模ではCSV取込で運用上十分と判断）。②過去3年分の伝票入力作業は御社実施（入力画面・CSV一括取込・手順書は開発費に含む）。③Zoho CRMライセンスは御社の現行契約を継続。④帳票は現行様式の踏襲を前提。正式なお見積りは業務密着ヒアリング後に確定します。
本価格の前提（進め方のお願い）：①帳票は現行様式の完全踏襲で1回確定（デザインの往復をなくします）。②モック＝仕様とし、画面合意後の変更は変更管理。③基盤は実績ある既製クラウド部品を採用。④フィードバック窓口を1名に一本化し、確認事項は48時間以内にご回答いただく。——この進め方により価格を圧縮しています。前提が難しい場合は標準体制（96人日・¥6,720,000 税別）でのお見積りとなります。
別途費用（実費・ランニング）
| 項目 | 金額目安 | 備考 |
|---|---|---|
| 保守費用（年額） | 構築費用の15%／年 ＝¥525,000／年（税別） | 障害対応・軽微改修・バージョン追従。開発費350万円の場合の年額（月額換算 約¥44,000）。Phase 1 本稼働月から |
| サーバー費用（月額） | ¥10,000〜20,000／月 | ホスティング・DB・PDF生成（実費） |
お支払いプラン
補助金活用プラン
富山県の補助金で実質負担を圧縮
富山県中小企業トランスフォーメーション補助金（DX枠・補助率1/2〜3/4）の活用を前提とします。採択された場合、開発費350万円の実質負担は約114万〜193万円（下記パターン参照）。お支払いは各Phase 着手時50%・検収時50%を基本とし、詳細はご契約時に取り決めます。
補助金活用のパターン
前提：補助対象経費＝Phase 1以降の開発費315万円（Phase 0は先行着手のため補助対象外・35万円）。制度は富山県中小企業トランスフォーメーション補助金 DX枠（補助上限500万円・申請期限 2026年7月末）を想定。
| パターン | 適用条件 | 補助率 | 補助額 | 実質負担（全体350万円） |
|---|---|---|---|---|
| A：小規模＋賃上げ | 小規模企業者（従業員5人以下）＋給与支給総額3%以上引上げ | 3/4 | 約236万円 | 約114万円 |
| B：小規模（通常） | 小規模企業者 | 2/3 | 210万円 | 140万円 |
| C：中小（通常） | 中小企業者（従業員6人以上） | 1/2 | 約158万円 | 約193万円 |
| D：補助金なし | 不採択・申請見送りの場合 | ー | ー | 350万円（Phase分割払いで平準化） |
小規模事業者の判定（従業員5人以下）：「常時使用する従業員」には、正社員のほか、正社員の4分の3以上の労働時間で継続勤務するパート・アルバイトも含みます。一方、①週の所定労働時間が正社員の4分の3未満の短時間労働者、②2か月以内の期間雇用者、③日雇いはカウントから除外されるため、シフトが少なめの一般的なアルバイトや短時間パートは多くの場合含めません。
共通要件・留意点：①とやまDXパートナー登録ベンダー（当社・受付申請中）の支援を受けた申請が必須。②事業実施期間中に事業場内賃金（時給単価）を平均10円以上引上げ、労働生産性3%以上向上の計画が必要。③実績報告期限（2027年1月8日）までに完了・支払した分が補助対象のため、Phase 2以降の対象範囲は申請時に事務局へ確認。④商談録音→文字起こし等のAI活用を柱に据える場合はAI導入枠（小規模3/4・中小2/3、賃上げによる引上げ不要）も選択肢（労働生産性4%以上向上が要件）。⑤IT導入補助金（国・1/2）は採択時期により着手が後ろ倒しになる可能性があり、スケジュール優先なら富山県制度を第一候補とします。
補助金は交付決定前の着手分が対象外となる制度が多いため、Phase 0のみ先行着手（補助対象外・35万円）とし、Phase 1以降を補助対象に切り分ける進め方を推奨します。採択されなかった場合の進め方（Phase分割・スコープ調整）も併せてご提示します。
Next Steps
今後の進め方
1
本ご提案のご確認（画面イメージ・帳票デジタル化・音声入力・費用と補助金の考え方）
2
資料のご共有 GEMの帳票・マニュアル、現状の受注／預り伝票、業務フロー。必要に応じてGEM画面の共有。
3
業務密着ヒアリング（1〜2日） 現場で、毎日触る画面・必要項目・見たい指標を定義。受注伝票の明細・在庫フローを実画面で確認。
4
要件確定 → 規模・費用・補助金スケジュールの確定 → ご契約
5
各Phase：開発 → 実データでの試験運用（トライアル）→ フィードバック反映 → 本稼働
次回までに確認させていただきたい事項
2026/6/24 の打ち合わせで、役割分担（CRM＝顧客・取引／Webアプリ＝供給・製造・在庫）と受注→製造→納品の業務フローはおおむね現状と整合することを確認いただきました。以下は実装に向けて引き続き詰める事項です。
- 受注伝票ウィジェットで再現する入力項目・画面遷移（現行の紙伝票に合わせる範囲）
- バーコードの体系（桁数・各コードの意味）と、完成品への払い出し単位・タイミング
- 外注加工費を含む原価の積み上げ方法
- オーダーメイド（受注紐付けあり）と既製品/委託品（受注紐付けなし）の割合
- 資材在庫と製品在庫の持ち方・棚卸単位
- 修理・買取の伝票項目と、店頭在庫品販売の運用の詳細
- 帳票の採番ルール、お預り引換証の保持側、納品伝票の有無・様式
- DG1・Shopify・LINE公式・クラブバール（フォーム）の連携要件と、既存顧客のLINE紐付け方法
- セキュリティ要件の範囲（機密情報の収集経路、権限、操作ログ、古物・本人確認）
- 過去3年分の伝票移行入力の作業量・体制
- 富山県DX補助金：当社の富山県DXパートナー登録可否・申請要件・スケジュール（期限7/30）の確認
この1年で、宝飾業界のDX成功事例を、ご一緒に。