Handed off
Integrated Vehicle Configurator (OTD)
What it was
Make sales configuration and the buildable per-vehicle BOM follow the same rules, so high-customization orders can move downstream.
What was stuck
Sales can configure a vehicle that engineering cannot resolve into a buildable per-vehicle BOM. Two configuration languages, one order: it stalls as sellable-but-unbuildable—lead times cannot be promised, inventory and supply–demand stay misaligned.
What I did
- 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.
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.
Outcomes
A configuration can reach order BOM and scheduling checks. Sellable and buildable are the same car.
- 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.
How I talk with engineering
Talk with engineering in three domains—sales, R&D, production. The configurator sits at sales-config truth ↔ engineering data; BOM resolution is application-layer rules; manufacturing execution stays outside the integration edge.
How I saw it: Sellable but unbuildable means sales and engineering are not talking about the same car
Appendix
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
Expanded against checkable industry practice. Findings are marked; 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.
Verifiable signals
- Business goals aligned: free configuration, shorter lead time, lower inventory, balanced supply–demand (OTD’s four strategy themes).
- Covered multi-channel sales-config touchpoints (app / mini program / web, etc.) supporting domestic and overseas order entry.
- Configuration-data capabilities 0→1: sales/engineering configs, materials and rules—serving per-vehicle / order BOM generation validation.
- OTD validation spine: order-flow continuity in C→M (sales config/order → scheduling → manufacturing), coordinated with fund-flow and physical-flow tracks.
How we split the layers (no stack picks)
- Access: admin portal with role-based menus and permissions—not one UI for every role.
- Application: modules by domain (master data, process, rules, documents)—bound the domains before splitting services.
- Data: master data separate from operational documents, plus audit/logs for traceability.
- Integration: connect to existing ERP / MES / production or commerce systems—do not rewrite shop-floor control or core ledgers.
How to size a separately deployed module
If sales config, orders, and config master data ship as separate deployables, size them with the method below. Core/RAM are an engineering load-test call—not invented here.
- Stateless apps: size instances by admin-seat count and peak concurrency; scale out. Ask “who is on at once” before asking for a machine SKU.
- Database: document volume and whether reporting contends with writes decide read replicas or a separate reporting store.
- Files and logs: attachments, exports, and audit trails should not live only in the OLTP database.
- A separately deployed mid-size admin module is usually app instances + database + needed middleware. Spine vs edge modules differ by a tier. Core/RAM are an engineering load-test call; product states availability, permissions, audit, and order-of-magnitude volume.