Purpose
目的と背景
「この1年で会社のDXをある程度完成させる」——その実現に向けたご提案です。
現状は、顧客対応は Zoho CRM、販売伝票は手書き、在庫・製造は業界専用システム（GEM）と、ツールごとに情報が分断しています。さらに GEM は Windows 11 に対応するには実質的な買い替え相当の費用がかかり、クラウド非対応・他システムと連動できないという制約があります。本ご提案は、この分断を解消し、業務を一気通貫でつなぐ仕組みを示すものです。
御社が定めた優先順位
販売管理 × 顧客管理の連動
全チャネルでデータを一本化。
在庫連動
売れたら在庫が自動で減る「売り消し」。
組立・製造加工管理
素材＋加工費を足し上げ1製品へ。当面は後段で。
Understanding
私たちが理解している、御社の事業
効率化は目的ではなく、この強みを伸ばすための手段だと考えています。
ファブレスのオートクチュール
宝石の買い付けから自社デザイン（3D CAD＋3Dプリンター原型）まで内製し、製造は外部工房へ。オーダーメイド／リフォーム／修理／ルース／ファンシーカラーダイヤが主力。創業29年、来年30周年。
高単価・少人数・濃い接客
伝票はオンライン含め月100件未満。1組の商談に約2時間、1品目＝1商談で丁寧に記録。富山中心に、静岡・小田原など全国からの来店も。
人間的なつながりと発信力
YouTube・ブログ毎日更新・Podcastという独自コンテンツが、AI検索経由の来店に結実。「20年前のお客様」も大切にする関係性の深さ。
コツコツ内製・両立主義
大きな資本投下を避け、積み重ねで前進。システム化は人間的な接客とコンテンツ制作の時間を生むため。「人もシステムも、両方ちゃんと」。
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アプリ連携（本提案） |
|---|---|---|
| 顧客・履歴 | ◎ | ◎ |
| 仕入・在庫・原価・組立 | ✕ CRM の守備範囲外。無理に載せると破綻 | ◎ 業務フローどおりに自然に持てる |
| 業務フィット | 宝飾固有UIを作り込み続けて頭打ち | 癖のある部分を業務に合わせて作れる／二重入力をゼロにしやすい |
| 役割分担 | 1つに詰め込み過ぎる | CRM＝顧客・取引、Webアプリ＝供給・製造で明確 |
課題 → 打ち手の対応
| 課題 | 打ち手 |
|---|---|
| ① 二重入力 | 受注伝票を Web/タブレットで起票し、同時にCRMへ記録。音声入力で接客記録を省力化。 |
| ② 分断 | 顧客＝CRM に集約、仕入・在庫・製造＝Webアプリ、データ連携で横串。1顧客ビューに統合。 |
| ③ 履歴なし | 売上を必ずCRMに残す設計。過去3年分の伝票を移行入力。 |
| ④ GEM老朽化 | クラウドWeb＋スマホ/タブレットで脱オンプレ。顧客約1,000名はCSVで移行。 |
| ⑤ 属人化 | 接客記録・デザイン画を顧客に紐づけ検索可能に。担当引き継ぎができる状態へ。 |
| ⑥ 可視化 | 売上KPI・カテゴリ別・目標対比のダッシュボード。 |
| ⑦ セキュリティ | 機密情報の安全な収集経路、権限／操作ログ、古物・本人確認の運用設計。 |
| ⑧ チャネル | サロン/DG1/Shopify どこで売れても、売上＋顧客を一本化して蓄積。 |
Architecture
システム全体像
「需要・取引」と「供給・製造」で正データを分け、受注伝票と製品で紐づけます。
Zoho CRM
需要・取引の正（顧客が見える）- 顧客マスタ／記念日・好み
- 接客・相談記録／商談
- 受注伝票（ウィジェットで起票）
- 納品（売上）伝票／購買履歴
新Webアプリ
供給・製造・在庫の正（業務に合わせて作る）- 発注（資材＝モノ＋外注加工費）→ 入庫
- 組立・製造加工管理（BOM・原価積上げ）
- 個別番号の発番・来歴・バーコード
- 資材在庫 ／ 製品在庫
Flow of Goods & Money
モノ（在庫）とお金の流れ
仕入れから販売まで、それぞれの流れを「どこが担うか」とともに示します。
モノ（在庫）の流れ：仕入れ → 販売
お金の流れ：仕入れコスト → 売上入金
モノの流れとは別に、お金は「出ていく（原価）」と「入ってくる（売上）」の2方向で動きます。
① 出ていくお金（原価）
② 入ってくるお金（売上）
粗利が見える：製品ごとの原価（Webアプリ）と売上（CRM）を突合すれば、1点ごとの粗利を把握できます。※リフォーム時の地金充当（持込金の充当）も金額に反映。
Business Flow
業務フロー：受注 → 製造 → 納品
オーダーメイドの基本形です。CRM と Webアプリ で役割を分けています。
商談から受注伝票を起票（現行の紙伝票に近い入力画面）。データはCRMに保存。「どの製品を作るか」を選定し、受注フェーズで一旦確定。
資材（ダイヤ／ルース／地金／原型）＋外注加工費を発注。
発注に対し資材が入庫 → 資材在庫へ。
入庫資材＋外注加工費を足し上げ（BOM・原価積上げ）→ 完成品に個別番号を発番。進捗は 受付→デザイン→見積承認→製作（自社/外注）→検品→納品 をボードで可視化。
販売用の製品在庫ができ、バーコードを払い出し。
製品 ⇄ 受注伝票（受注に紐付ける／在庫として後で引き当ても可）。
製品をお客様へ納品 → 納品（売上）伝票。受注伝票に紐付け → 購買履歴へ。
製造の有無は2通り：オーダーメイドは受注に紐づけて製造／既製品・委託品・見込み生産は先に製品在庫を作り後で引き当て。どちらにも対応します。
在庫は2層：未完成の「資材在庫」と、完成した「製品在庫」を分けて管理します。
受注伝票の起票は2経路
| 経路 | 場面 | 起票UI | 顧客マスタ | 受注データ |
|---|---|---|---|---|
| (a) 手入力 | 商談からの受注（オーダー等） | CRM ウィジェット（紙伝票に近いUI） | CRM を参照 | CRM が正 |
| (b) バーコード自動起票 | 完成品の販売時 | WebアプリのスキャンUI（スマホ可） | CRM を参照 | CRM が正 |
製造完了で製品にバーコードを払い出し。販売時にスマホ等でスキャンすると、受注伝票が自動起票（顧客は CRM を参照）され、同時に製品在庫から引き当て（売り消し）。製造した製品が「在庫 ⇄ 受注伝票」に一気通貫で紐づきます。
現行帳票3種の電子化
現行の手書き帳票3種を、項目・体裁を踏襲して電子化します。起票がそのまま記録になります。
| 現行帳票 | 内容 | 保持側 | 出力タイミング |
|---|---|---|---|
| ① ご請求明細書 | 受注・納品（売上）：明細・決済・ポイント | CRM（ウィジェット起票） | 納品/会計確定時 |
| ② 加工依頼書（控） | 製造指図：加工区分・使用地金・ルース・原型番号 | Webアプリ（受注から生成） | 受注後の製造手配時 |
| ③ お預り引換証（控） | 預り品：受付日・返却予定日・品目 | 要確認（CRM/Webアプリ） | 預り受付時 |
組立・製造加工管理のカンバン（イメージ）
受注した製造案件を工程ごとのカードで可視化。自社／外注の別・担当・納期がひと目で分かります。Webアプリ
受付 2
デザイン・CAD 1
見積・承認 1
製作 2
検品 1
完成・納品 1
Function Mapping
GEM機能の振り分け
全機能を移植するのではなく、実際に使っている中核を再構築します。
| GEM の機能 | 内容 | 振り分け |
|---|---|---|
| 仕入れ管理 | 資材（モノ）＋外注加工費の入荷・原価記録 | Webアプリ |
| 在庫管理 | 個別番号・来歴（在庫/加工中/売約/販売済）・売り消し | Webアプリ（優先2） |
| 販売管理 | 受注・納品（売上）・帳票 | 受注/納品＝CRM（ウィジェット）、付帯帳票＝テンプレ出力 |
| 顧客の購買履歴 | 顧客に売上・オーダー・修理を紐づけ | CRM |
| 組立・製造加工管理 | 素材＋加工費を1製品に足し上げ | Webアプリ（優先3） |
| 商品マスタ・個別番号 | 在庫・売上・オーダー・組立を貫く軸 | Webアプリ（GEMから移行） |
実装のポイント
HTML/CSS ＋ PDF
現物に合わせたテンプレートでPDF生成・店頭印刷。控えの2部運用を踏襲し、発行PDFは顧客カルテに添付して紙の死蔵を解消。署名が要る預りはタブレット署名／印刷サインに対応。
既存資産を起点に
GEMの個別番号をそのまま主キーに引き継ぎ、既存タグは貼り替え不要。読取はリーダー＋スマホカメラ、発行はラベルプリンターで2面タグ（プライス＋管理）。点数増加時はRFIDを将来オプションに。
BOM＋進捗ボード
部材（地金・ルース・原型）＋外注加工費を1製品に足し上げ原価を集計。加工依頼書を入口に進捗をボードで管理し、完成時に個別番号を発番・バーコード発行。
技術構成
| レイヤ | 構成 | 用途 |
|---|---|---|
| フロント | React / Next.js（PWAでスマホ対応） | タブレット入力・進捗ボード・帳票プレビュー・スキャン |
| バック / DB | API ＋ PostgreSQL（クラウド） | 商品・在庫・仕入・製造・受注の管理 |
| 帳票 | HTML/CSS ＋ PDF 生成 | 帳票発行・店頭印刷 |
| バーコード | 生成ライブラリ＋リーダー（カメラ併用） | 払い出し・スキャン起票 |
| 連携 | Zoho CRM REST API | 顧客参照・受注/売上/履歴の記録 |
| 基盤 | 認証・権限・操作ログ | セキュリティ／古物・本人確認 |
Roadmap
実装の進め方
御社の優先順位に沿って、無理なく段階的に。
クイックウィン
商談録音→文字起こし→CRM記録／ダッシュボード整備／フォーム整理。既存Zohoの活用度を上げ、二重入力の痛みをすぐ緩和。
受注伝票の電子化 ×「売上↔顧客」連動 ＜最優先＞
サロン＋DG1＋Shopify を一本化。顧客カルテ／購買・接客履歴を整備。過去3年分の伝票移行入力を並行。古物・本人確認も設計。
在庫管理 × 販売連動
バーコード自動起票による売り消し・個別番号来歴。仕入れ（発注・入庫）を含む。GEMからCSV移行。
組立・製造加工管理
素材＋加工費を1製品へ足し上げる工程。GEM固有機能を再現。
Investment
費用・お支払い・補助金の考え方
お支払い方法
初期一括だけでなく、サブスク型／分割の選択肢をご用意。Phase分割は費用の山を平準化する観点でも有効です。
補助金の活用
IT導入補助金など国ベースを軸に、活用可能な制度・補助率・採択されなかった場合の進め方をセットでご提示します（富山県の制度も確認）。
投資の考え方
「無理のない投資範囲」で実現できるプランに整理。段階導入により、効果を確かめながら投資判断いただけます。
Next Steps
今後の進め方
次回までに確認させていただきたい事項
- 受注伝票ウィジェットで再現する入力項目・画面遷移（現行の紙伝票に合わせる範囲）
- バーコードの体系（桁数・各コードの意味）と、完成品への払い出し単位・タイミング
- 外注加工費を含む原価の積み上げ方法
- オーダーメイド（受注紐付けあり）と既製品/委託品（受注紐付けなし）の割合
- 資材在庫と製品在庫の持ち方・棚卸単位
- 帳票の採番ルール、お預り引換証の保持側、納品伝票の有無・様式
- DG1・Shopify・LINE公式・クラブバール（フォーム）の連携要件と、既存顧客のLINE紐付け方法
- セキュリティ要件の範囲（機密情報の収集経路、権限、操作ログ、古物・本人確認）
- 過去3年分の伝票移行入力の作業量・体制
この1年で、宝飾業界のDX成功事例を、ご一緒に。