Deep dive
Integrated Vehicle Configurator (OTD)
Capability theme Data continuity & configuration
For Geely’s luxury brand Lotus high-customization / OTD: multi-channel sales configuration and orders, connected to config master data and per-vehicle BOM resolution—supporting C→M (configure/order to delivery).
Verifiable signals
Business goals aligned: free configuration, shorter lead time, lower inventory, balanced supply–demand (OTD’s four strategy themes).
Verifiable signals
Covered multi-channel sales-config touchpoints (app / mini program / web, etc.) supporting domestic and overseas order entry.
Verifiable signals
Configuration-data capabilities 0→1: sales/engineering configs, materials and rules—serving per-vehicle / order BOM generation validation.
Verifiable signals
OTD validation spine: order-flow continuity in C→M (sales config/order → scheduling → manufacturing), coordinated with fund-flow and physical-flow tracks.
Problem
High-customization must make free configuration manufacturable at scale: consumer configuration UX, order management, config/BOM accuracy, scheduling and supply must share one truth—or configs won’t build, lead times can’t be promised, and inventory/supply-demand stay unstable.
My role
Led five PMs on the integrated configurator and related configuration-data capabilities; in an OTD / high-customization validation context, covering multi-channel sales-config UX, content/master data, and the configuration & rules needed for customized / per-vehicle BOM generation—coordinating partners for on-time global launch.
What I owned
- Multi-channel sales-configuration UX: web / app / mini-program flows, constraint feedback, and order capture (domestic and overseas sales configurators in the OTD sales domain).
- Configuration content and master data: dynamic configs, menus, assets; sales↔engineering mapping, materials and rules for sellable→buildable.
- Custom / per-vehicle BOM collaboration: feature families, product structure/filters, and configuration rules needed for order-BOM generation (validated with R&D PMS / scheduling).
- Support OTD’s core mission—C→M order-to-delivery—by productizing sales configuration and configuration-data truth.
What I did not own
- Plant scheduling rule internals, MES execution, TMS/WMS physical-flow execution (OTD collaboration scope—not the configurator product core).
- Payment-rail integration and treasury reconciliation (fund-flow track in OTD’s three-flow validation).
Collaboration
- Product: led five PMs on configurator and configuration-data capabilities.
- Business & R&D: co-defined vehicle config / BOM resolution; validated order-BOM generation with PMS custom BOM and scheduling (JIS).
- OTD program: aligned sales-config, order, and BOM interfaces across order / fund / physical-flow validation tracks.
Requirements analysis
The following expands resume scope against public industry methods (OTD/configurable BOM or MLOps). Findings are checkable; unconfirmed internal details are not invented.
1. Business goals & the one big mission
OTD’s mission is C→M (order to delivery). In Lotus high-customization, strategy centers on customer satisfaction and cost—free configuration, shorter lead time, lower inventory, balanced supply–demand. Product requirements must serve both “can configure” and “can build on time.”
- Free configuration is not a frontend checklist—it is a prerequisite for runnable batch production and delivery.
- Lead-time and inventory goals force manageable option forecasts, order cadence, and config/BOM accuracy.
2. Stakeholder map: sales / R&D / production
OTD is end-to-end across sales, production, and R&D. Requirements split interfaces by domain: sales (configurator, orders, forecast), R&D (configuration management, EBOM/MBOM/rules), production (scheduling, MES, logistics). The configurator sits at sales-config truth ↔ R&D configuration data.
- Consumer and store/overseas touchpoints are order entry points needing shared configuration semantics and order fields.
- R&D supplies part master data and engineering rules; scheduling consumes orders and order BOMs.
3. Turn worry-list into requirement themes
Pre-validation worries become requirement themes: can customers fully configure? how are orders managed/transmitted after configure? how are order/forecast BOMs accurately generated under high customization? how are orders scheduled and exploded to parts?—configurator and BOM accuracy are the hub.
- Theme A: high-customization completeness and constraints (including special config scenarios).
- Theme B: cross-system transmission and state consistency after order creation.
- Theme C: generate complete per-vehicle / order BOM from configuration string and validate into scheduling.
4. Requirement layers: UX / order / master data / BOM / integration validation
UX: multi-channel configure-and-order; orders: order center and domestic/overseas coordination; master data: sales↔engineering features/rules; BOM: custom/order BOM generation; integration: order-flow validation with scheduling and manufacturing ERP. Fund-flow and physical-flow are parallel tracks—not mixed into the configurator core.
- Common architecture split: commerce platform (sales configurator/order center) ↔ vehicle R&D platform (config & BOM) ↔ scheduling/manufacturing execution.
- Acceptance emphasizes continuity: e.g. order release → order BOM → successful scheduling—not page availability alone.
5. Acceptance: order-flow hub inside three flows
OTD validation runs order, fund, and physical flows. The configurator hub is order flow: after sales config/order creation, can BOM generation and scheduling be driven; a per-vehicle BOM workstream validates “complete accurate BOM after configure.”
- Order-flow acceptance: consistent order fields (e.g. configuration string) across domains, successful BOM generation, entry to scheduling.
- Per-vehicle BOM validation needs multi-role collaboration across R&D EBOM/MBOM, plant materials/tech, platform, and IT.
Flows & architecture schematics
Diagrams/copy integrate resume scope with Lotus OTD/high-customization validation materials’ public business structure; integration credentials, unfinished items, and sensitive system dumps are omitted—no internal UI screenshots.
OTD three validation tracks
From Lotus OTD/high-customization materials: the mission is C→M; validation runs order, fund, and physical flows. The configurator hub is order flow and BOM accuracy.
Capability domains from Lotus OTD/high-customization validation materials: commerce config/orders ↔ vehicle R&D BOM ↔ scheduling/manufacturing; internal system dumps and integration minutiae omitted.
Approach
- Build multi-channel sales-config UX and order entry with scenario-specific flows, constraints, and commerce-related paths for high-customization orders.
- Build configuration content and master data: dynamic configs/menus/assets, sales↔engineering mapping and rules so configuration stays operable and resolvable.
- Collaborate with R&D PMS custom BOM and scheduling to validate configuration-string → order BOM → schedule/manufacturing for OTD C→M.
Outcomes
- Established sales-configuration and configuration-data product capabilities that support high-customization / OTD free configuration and delivery cadence.
- In order-flow validation, aligned critical semantics/interfaces among sales config/orders, BOM generation, and scheduling.
- Connected sales–R&D–manufacturing expressions of “the same vehicle,” reducing sellable-but-unbuildable risk.