Principle-DPM-DPS

Decrypt history, Encrypt future™

Principle-DPM-DPS

全体工程表:企画、受注、調達、設計から出荷まで

プロダクト企画から出荷までを一つの「標準工程」として繋げると、世界中に分散化された直売所付き工場としてバリューチェーンを分解できる。

DPM-DPS工程区分番号工程名称主な成果物・データキーストーン京都自社京都OEMベトナム泉佐野館林HI1館林HT2館林HT3Lecien Global
PDMSプロダクト企画01商品企画・デッサンコンセプト、ラフスケッチ○○
02デザイン・配色確定カラーチャート、図案データ○○
03CAD・パターン作成CADデータ、型紙データ○○
04仕様書・BOM確定部材レシピ、加工手順書○○
05知財の取得商標、特許、意匠○○
06Brand Statement Verificatorブランドスケーラビリティテスト◎
プロトタイプ作成11サンプル品の仕様書提出○○
12部品発注○○
13サンプル品の完成○○
14商談会の実施○○
15モデルのネーミング、ロゴ、ドメイン取得製品ネーミング、ドメインなど○○
OMS量産品受注21サンプル品の提示○○
22エンタープライズのアカウントセリングSalesforce Pipeline○○
22必要SKUの特定○○
23客先からの受注予約○○
24客先からの本受注○○
25共通受注テーブルによるデータ整形○
26総数契約または発注計画受領発注ロットIDの確定(種別、色、サイズ)BOM製造原価確定のトリガー◎
OMS社内発注31発注稟議○
32発注決定○
33社内ASN作成ROIC決定◎
BOM調達指示41調達稟議発注書、生産スケジュール○○
42調達指示○○
43原材料調達○○
44入荷予定登録入荷予定データ(ASN)◎◎
IMS在庫搬入45原材料の荷受・検収実績受入データ○○
46外注部品の荷受・検収○○○○○
MES生産指示51生産指示受領○○
52原材料の加工場移動○○
MES製造準備61原材料受け入れ、検反○
62生産指示受領○
63生産計画○
64放反○
65延反○
66型入れ、パターン作成○
67CAMデータ作成
68裁断○
69パーツ検品○
MES製造71縫製○
72アイロンプレス○
732次検品○
74包装○
75出荷準備○
MES製造81原材料受け入れ、検反○
82糸繰り(かせとり)加工済の糸束○
83裁断裁断済パーツ○
84品質検査○
WMS流通加工91流通加工指示受領(ASN)○○○○
92流通加工作業場への移動○○○○
93たたみ、値札、タグ付け、包装○○○○
94梱包○○○○
95出荷先別ダンボール充填○○○○
96出荷承認待機○○○○
WMS出荷指示101出荷承認○○○○
102輸送
103卸顧客確認
HDCフルフィルメントセンター201着荷確認○
202在庫同期ツールに在庫登録○
203Shopifyによるワンアドミン、マルチカントリー、マルチウェアハウスのシステム○
204各国受注管理(OMS)と倉庫管理(WMS)による処理○
205SEO/SNSコンテンツ作成○
206商品発送○
207返品対応○
208問い合わせ対応○
Aura価格指針301コスト集計○○
302PLOG Extractor○○
303プライシングパワーレビュー稟議事項○○
304パーチェシングパワーレビュ
305Law of Scaleの定義

DPM Distributed Production ModelのSaaS一覧

DPM-HDCまでの分散型生産システムからプライシングパワーディスカバリーのできるハイブリッドダイレクトトゥコンシューマーを実現するデジタルバリューチェーンは以下のコンポーネント(DPS)に分解できる。

  1. Principles
    • PLOG, PcLOG, LAP, Operating Leverage
  2. Distributed Production Model
    • Law of Scale Verificator
    • ZKP secret procedure
      • 3. Distributed Production Systems
        • 3.1. PDMS:Product Design Management System
        • 3.2. Enterprise Purchace Pipeline Management: Salesforce
        • 3.3. OMS:Order Management System
        • 3.4. BOM:Bill of Material System
        • 3.5. IMS:Inventory Management System
        • 3.6. MES:Manufacturing Execution System
        • 3.7. QCS: Quality Controlling System
        • 3.8. WMS:Warehouse Management System
        • 3.9. TMS:Transportation Management System
        • 3.10. HDS:Hybrid Direct to Consumer Platform
      • 4.Accounting
        • Bookkeeping
        • Revenue/Cost Input-Gross Margin Output System
        • Work Rules
        • Salary Policy
        • Insurance
        • Travel & Expense Policy
        • Maternity & Leave
        • International Work/Holiday Calender
        • Expense Claim Management
        • Tax Reporting
        • Audit
        • 5.Security
          • Office Security
          • Plant Security
          • Vehicle Security
          • Device Security
          • Apps Security
          • IAM/SSO
        • 6. Aura:Product Led Organic Growth Extractor

ポイント

  • 現在:企画から販売までのリードタイムの課題は何か?と聞くと、染色工場(BOM)、生産歩留、社内発注稟議など、各人全体を把握せず、どこに本当のボトルネックがあるかがわからない。
    • to be→ボトルネックはスケールに伴いバリューチェーンの各工程を動き回るものであるから、わざわざ地球中を飛び回らなくても、インターネットにデジタルツインを構築し、事業のボトルネックがどこにあるのかの議論の前提条件を揃える
  • 現在:たとえば、北米で商品を売りたいと思っても、上記10以上の各DPSモジュールについて各担当者を探さないと着荷までの工程が進捗しているかがわからない
    • to be→わざわざ人に聞かなくてもログインすれば主要なインジケータが取れており、必要があればテレメトリや映像で状況がわかるように。
  • 現在:全社会議に同席していても、各担当者がどのプロセスのことを話しているかがわからない。
    • to be→事業の前提を明確化する。
  • 現在:ボリュームの小さい発注から、大きい発注まで、システムが更新されないことによって人力で回しているタスクが多くある
    • to be→ほとんどの業務をソフトウェアにオフバランス、オフロードし、人間の脳のメモリを空ける
  • 現在:顧客から発注がくるOEMについては営業から納品までの業務が回るが、自社商品の製造小売業ではプロアクティブに在庫拡張するためのLaw of Scaleルールやトリガーがない。完全社内D2Cを生産するためのビジネスフローが現在のところシステムで整備されていないので、実はどんなに頑張ろうとしても増収増益させるためのシステマチックな社内稟議フローがない
    • to be→計画的に資本を投下するDCF的判断ができるように。ROICハードルとオペレーティングレバレッジを維持しながら増収増益できるLaw of Scaleを実務面で確立。

共通UI/UXプリンシパル: 汎用モダン・ライトクリーン

1. カラーシステム (Light Mode Base)

  • Background: Pure White (#FFFFFF) または極めて薄い Gray (#F9FAFB) をベースにする。
  • Primary: 信頼感のある Blue (#3B82F6) またはブランドカラー1色に絞る。
  • Text: – メイン: #111827 (Almost Black)
    • サブ: #6B7280 (Muted Gray)
  • Border: #E5E7EB (薄いグレー) で、シャドウよりもラインで境界を表現する。

2. タイポグラフィ (Universal Sans)

  • Font Family: システム標準フォントを優先(Inter, system-ui, sans-serif)。
  • Hierarchy: – Title: Bold, 1.25rem以上
    • Body: Normal, 0.875rem ~ 1rem
    • Line Height: 1.5 ~ 1.6 で可読性を確保。

3. アイコン・コンポーネント (Universal Design)

  • Library: Lucide React または Heroicons を使用(線が細く、クリーンなもの)。
  • Radius: 角丸は 8px (rounded-lg) を基本とし、柔らかすぎず硬すぎない印象にする。
  • Clickable: ボタンやリスト項目は、モバイルでの操作性を考慮し最小 44x44px のタップ領域を確保する。

4. コーディング制約

  • Framework: React / Next.js / Tailwind CSS を前提とする。
  • Consistency: 新しいコンポーネントを作成する際は、既存の shadcn/ui 等のパーツとデザイントークンを統一すること。
  • Accessibility: 常に aria-label や適切なセマンティックHTML(nav, main, section)を使用する。

dpsスーパーアプリの切り替え(ヘッダー)

1.dps-oms.lecien.com  (PDMS, BoMを機能に含む)
2.dps-mes.lecien.com (縫製QCS、IMSを含む)
3.dps-wms.lecien.com  (流通加工QCS、IMSを含む)
4.dps-aura.lecien.com (売上と製造原価の集計をしてMoMのOperatingLeverage分析)

PDMS,BoMはOMSに統合され、QCS, IMSはクロスファンクションとしてmesやwmsに統合される

ユニバーサルなキーとなるデータの種別について

  • UTC カレンダー、時刻
  • 通貨:USD, EUR, CNY, JPY, VND
  • Global Organization ID (Tax IDなど)
  • GTIN (Global Trade Item Number):JAN, EAN, UPC
  • カラーコード(Pantoneなど)
呼称正式名称主な利用地域桁数互換性
JANJapanese Article Number日本13桁 (45/49から開始)あり
EANEuropean Article Number欧州・アジア・全世界13桁あり
UPCUniversal Product Code北米(米国・カナダ)12桁あり
GTINGlobal Trade Item Number共通規格(システム上の呼称)14桁(最大)総称

1. 単位の国際標準(UOM: Unit of Measure)

「1個(Piece)」なら良いですが、原材料(BOM)や物流(WMS)では単位の解釈がボトルネックになります。

  • 内容: PCS (個), MTR (メートル), KGM (キログラム), LBR (ポンド) など。
  • 規格: UN/CEFACT (Rec 20)。
  • 理由: ベトナム工場で「1本」と管理しているレースが、日本では「100メートル」だった場合、在庫数と原価計算が狂います。これを世界共通の単位コードで固定します。

2. インコタームズ(貿易条件)

「どこからが誰の責任か」をシステムが自動判定するために不可欠です。

  • 内容: FOB (本船渡し), CIF (運賃保険料込み), DDP (関税込み持ち込み渡し) など。
  • 規格: Incoterms 2020。
  • 理由: 通貨(USD/JPY)が決まっていても、関税や運賃が「原価(Cost)」に含まれるのか「経費(Expense)」になるのかは、このコード一つで決まります。

3. HSコード(統計品目番号)

国境を越える際の「商品の身分証明書」です。

  • 内容: 6桁〜10桁の数字コード。
  • 規格: HS (Harmonized System) Code。
  • 理由: これが共通化されていないと、ベトナムから米国へ送る際の関税率が自動計算できず、HDS(Shopify等)での正確な販売価格設定や、Auraでの正確なPL予測が不可能になります。

4. サイズ・フィッティングの「正規化キー」

インナーウェア特有の「国ごとのサイズ呼称の違い」を吸収する物理的なキーです。

  • 内容: Under_Bust_CM, Top_Bust_CM といった「物理的な寸法(ミリ・センチ)」をベースにした基準値。
  • 理由: 日本の「70B」は米国の「32A」に相当する、といった変換ロジックを全DPSで共有します。商品名(ラベル)はローカライズしても、マスターデータは物理寸法で持ちます。

5. ステータス・イベントコード(Logistics Milestone)

「今どこか」を言葉ではなく数値で定義します。

  • 内容: Event_Code (例: 10 = Order, 50 = Production_Start, 90 = Shipped)。
  • 規格: EPCIS (GS1標準)。
  • 理由: 「出荷準備」という言葉が、WMS(梱包完了)とMES(最終検品完了)で食い違うのを防ぎます。

6. 言語・地域コード

UIの表示だけでなく、納品書やラベルの印字ロジックに使用します。

  • 規格: ISO 639-1 (言語), ISO 3166-1 alpha-2 (国)。
  • 例: ja-JP, vi-VN, en-US。

工程間を流れる「意志」と「状態」を定義するデータ。

  • Universal_Order_ID: 受注から出荷までを紐付けるキー。
  • Event_Status_Code: 01〜303の工程区分番号。
  • UTC_Timestamp: 全世界共通の時刻記録。
  • Incoterms_Code: 貿易条件(FOB/DDP等)。
  • UOM_Code: 単位コード(UN/CEFACT)。

2. データ連携の「看板(共通スキーマ)」定義

各DPSがAPIでやり取りする際の標準的なJSONオブジェクト(看板)のイメージです。

JSON

{
  "header": {
    "trace_id": "UUID-550e8400",
    "timestamp": "2026-02-21T12:00:00Z", // UTC固定
    "origin_entity": "LEI-12345678"      // 発注主体
  },
  "payload": {
    "order_context": {
      "order_id": "PO-2026-001",
      "incoterms": "DDP",
      "currency": "USD"
    },
    "item_context": {
      "gtin": "04512345678901",
      "qty": 1000,
      "uom": "PCS",
      "hs_code": "621210",               // ブラジャーのHSコード
      "color": "PANTONE-19-4052"
    },
    "location_context": {
      "source_gln": "8931234567890",     // ベトナム工場
      "dest_gln": "4912345678904"        // 日本のWMS
    }
  },
  "status": {
    "step_no": "71",                     // MES: 縫製
    "is_completed": true
  }
}

3. このデータモデルがもたらす効果

  1. 「言葉の壁」の消滅: ベトナム工場の作業者が「縫製完了」と入力しても、システムは step_no: 71 として処理し、北米の販売担当者のダッシュボードには英語で Sewing Completed と表示されます。
  2. ボトルネックの自動算出: 71 (縫製) から 75 (出荷準備) までの UTC_Timestamp の差分を計算するだけで、どの工場のどのラインで停滞が起きているか、人間が報告書を作る前にシステムが検知します。
  3. 原価のリアルタイム把握: Incoterms と Currency が固定されているため、為替変動(Auraによる為替レート取得)と関税率を掛け合わせるだけで、着荷時の予測原価が常に最新化されます。

各DPS内での組織の選択、切り替え(ヘッダー)

国 USA, Singapore, HK, Japan, Vietnam

事業部
インナーウェア事業部 NB
インナーウェア事業部 PB
ハンドメイド事業部
レース事業部 アトリエ
レース事業部 アミュレット

権限
全権保有者
管理者
承認者
入力者
閲覧者
協力会社 管理者
協力会社 承認者
協力会社 作業者
外部企業 閲覧者