Triển khai CPQ sản xuất: RFP từ báo giá đến sản xuất

Mục tiêu thực sự của triển khai CPQ trong sản xuất không chỉ là lập báo giá nhanh hơn. Với doanh nghiệp sản xuất theo đơn hàng và nhiều biến thể, thành công phụ thuộc vào việc cấu hình do kinh doanh chọn, tổ hợp được kỹ thuật chấp thuận, giả định về giá thành và giá bán, cùng điều kiện giao hàng đã cam kết có được chuyển nguyên nghĩa sang đơn hàng, BOM, routing và hướng dẫn sản xuất hay không. Nếu báo giá đúng trên màn hình nhưng nhà máy vẫn phải diễn giải lại, số hóa chỉ dời điểm bắt đầu của sai sót và làm lại.

Bài viết dành cho người phụ trách tại các nhà sản xuất máy móc, thiết bị điện, linh kiện và vật liệu công nghiệp ở Thái Lan và ASEAN. Nội dung trình bày theo trình tự thực tế: phạm vi CPQ (Configure, Price, Quote), rule của configurator, bàn giao variant BOM và routing, phê duyệt và audit, RFP, PoC có giới hạn 90 ngày và acceptance gate. Đây không phải bảng xếp hạng nhà cung cấp mà là khung mua sắm để đặt cùng câu hỏi cho mọi ứng viên và đánh giá bằng cùng loại bằng chứng.

Kết luận: CPQ sản xuất phải tạo “hợp đồng cấu hình có thể thực thi”

Có thể định nghĩa kết quả CPQ như sau:

Một cơ chế đóng băng cấu hình sản phẩm, rule đã áp dụng, giả định giá bán, giá thành và lead time, trạng thái phê duyệt và revision, để ERP, PLM và MES sử dụng báo giá đã được chấp nhận mà không phải diễn giải thủ công.

“Hợp đồng” ở đây không chỉ là văn bản pháp lý. Đó là thỏa thuận dữ liệu để kinh doanh, thiết kế, kỹ thuật sản xuất, mua hàng và nhà máy cùng tham chiếu một configuration ID và revision, đồng thời truy ngược được sản xuất cái gì, theo điều kiện nào và bằng quy trình nào. PDF gửi khách hàng chỉ là một cách hiển thị dữ liệu đó.

Trước khi triển khai, cần chốt ít nhất năm quyết định:

1. Hệ thống nào—CPQ, PLM hay ERP—là nguồn chuẩn của configuration rule?
2. Configuration ID, revision và effective date sẽ nhận diện chính xác cấu hình đã báo giá như thế nào?
3. Tính năng được chọn sẽ trở thành variant BOM, routing, vật tư mua và yêu cầu kiểm tra ra sao?
4. Dịch vụ nào tính giá, chi phí và ngày hứa giao; ai phê duyệt từng ngoại lệ?
5. Thay đổi sau đơn hàng, báo giá thua, báo giá lại và engineering change sẽ được lưu dấu vết thế nào?

Nếu bắt đầu bằng mục tiêu “làm báo giá nhanh” khi năm câu hỏi này còn mở, giao diện kinh doanh có thể đẹp hơn nhưng email hỏi kỹ thuật, bảng Excel thông số và nhập lại ERP vẫn còn. CPQ không phải dự án thay màn hình báo giá; đó là thiết kế các quyết định Quote-to-Order thành dữ liệu được quản trị.

Hiểu hệ thống CPQ trong doanh nghiệp sản xuất

CPQ là Configure, Price và Quote. Trong sản xuất, ba phần phải chạy như một chuỗi.

• Configure: dùng attribute, option, constraint, calculation và dependency để xác định cấu hình có thể bán và có thể sản xuất.
• Price: áp dụng điều kiện về option, số lượng, khách hàng, khu vực, tiền tệ, dịch vụ, chiết khấu và khi cần là giả định cost/margin.
• Quote: trình bày cấu hình và giá cùng revision, trạng thái phê duyệt, điều khoản, hiệu lực và tài liệu thông số.

Tài liệu chính thức của Microsoft mô tả model cấu hình gồm attribute, constraint, calculation, BOM line và route operation, đồng thời nêu trường hợp một product variant có BOM và route riêng. Tài liệu Configure-to-Order của Oracle cũng mô tả model, option class, lựa chọn tại thời điểm đặt hàng và work definition sản xuất được tạo từ các lựa chọn. Điều cần học không phải là bắt buộc mua một sản phẩm cụ thể, mà là không tách lựa chọn của kinh doanh khỏi tính khả thi sản xuất.

Không phải CPQ nào cũng tự động sinh production BOM hoặc routing hoàn chỉnh. Một kiến trúc có thể để CPQ giữ sales configuration, PLM giữ engineering BOM, còn ERP giữ manufacturing BOM và route. Kiến trúc khác cho CPQ gọi variant configurator trong ERP. Vì vậy RFP phải hỏi hệ thống nào sở hữu từng rule và deliverable, thay vì chỉ hỏi tên sản phẩm.

Vẽ ranh giới trước khi chọn chức năng

Bảng ranh giới ngăn trách nhiệm rơi giữa các nhà thầu. Thay “có tích hợp ERP” bằng hành vi create, change, approve, invalidate, retry và reconcile cho từng dữ liệu. Với thiết kế interface nói chung, xem hướng dẫn đặt hàng phát triển API integration cho nhà máy. Bài này tập trung vào ý nghĩa cấu hình và version control đặc thù của CPQ.

Những gì cần model trước cho báo giá Make-to-Order

Công việc đầu tiên không phải đưa nguyên mẫu báo giá hiện tại lên màn hình. Hãy tách thành “câu hỏi kinh doanh hỏi,” “rule kỹ thuật quyết định” và “deliverable sản xuất cần.”

Chuyển ngôn ngữ khách hàng thành product attribute

Khách hàng nói “dùng ở nhiệt độ cao,” “dễ vệ sinh,” “vừa dây chuyền hiện có” hoặc “đạt throughput này.” Phía sản phẩm phải quyết định qua vật liệu, nguồn điện, capacity, kích thước, protection class, chuẩn kết nối, kiểu điều khiển, inspection và ngôn ngữ tài liệu. Chia câu hỏi thành ba lớp:

1. Mục đích và môi trường: vật liệu xử lý, nhiệt độ, độ ẩm, bụi, washdown, hazardous area và quốc gia lắp đặt.
2. Năng lực cần thiết: throughput, độ chính xác, tốc độ, tải, phạm vi chuyển động và giờ vận hành.
3. Điều kiện triển khai: điện, khí, truyền thông, không gian, đường đưa máy vào, tích hợp upstream và ngôn ngữ.

Giá trị phải có đơn vị. “100” không phải dữ liệu kỹ thuật nếu chưa biết là 100 kg/h hay 100 pieces/min. Nhãn có thể hiển thị tiếng Nhật, Anh, Thái hoặc Việt, nhưng attribute ID, unit và enumeration ID phải dùng chung. Không dùng text đã dịch làm integration key.

Tách hard constraint, soft constraint và calculation

• Hard constraint: điều kiện vật lý, an toàn, pháp lý hoặc interface bắt buộc; cấu hình vi phạm không được xác nhận.
• Soft constraint: khuyến nghị về tiêu chuẩn, margin, stock hoặc lead time; có thể đi tiếp bằng phê duyệt ngoại lệ.
• Derived calculation: công thức tạo capacity, số lượng, kích thước, giờ công hoặc thành phần giá.
• Completeness rule: không cho submit khi câu hỏi, bản vẽ hoặc xác nhận bắt buộc còn thiếu.

Nếu mọi thứ đều bị cấm, đơn đặc biệt sẽ chạy ra email và Excel. Nếu mọi thứ chỉ là warning, CPQ chỉ còn là checklist. Với rule cho phép override, lưu lý do, người duyệt, thời hạn, ảnh hưởng tới BOM/routing và quyết định ngoại lệ có được tái sử dụng hay không.

Mỗi rule phải có evidence và Owner

“Motor này phải dùng inverter này” chưa đủ để bảo trì. Hãy lưu rule ID, mô tả, expression, result, tài liệu nguồn, product family, khu vực, ngày bắt đầu/kết thúc, tác giả, người duyệt kỹ thuật và test case cùng nhau.

Khi thu nhận kinh nghiệm ngầm của người bán hoặc kỹ sư, không công bố nguyên trạng điều truyền miệng. Đối chiếu với design standard, lỗi quá khứ, cost condition và supply constraint. CPQ làm tacit knowledge nhìn thấy được, nhưng không tự chứng minh kiến thức đó đúng.

Kết nối Configurator với Variant BOM và Routing

Acceptance scenario quan trọng nhất không phải “PDF đã tạo.” Đó là “deliverable sản xuất được tái tạo từ đúng cấu hình khách hàng chấp thuận.”

Dùng Configuration Snapshot làm Order Baseline

Khi phát hành báo giá, đóng băng thành một snapshot:

• Opportunity ID, quote ID và quote revision.
• Configuration ID, model revision và rule revision.
• Tất cả input, selection, derived value, exclusion và override.
• Price-list revision, tiền tệ, cách xử lý tỷ giá, discount và ngày tham chiếu cost.
• Specification, quantity, giả định giao hàng, warranty và service đã hứa.
• Trạng thái và thời gian phê duyệt kỹ thuật, kinh doanh, tài chính.
• Revision của quote, specification và drawing được tạo.

Tài liệu giao dịch bán hàng của Microsoft nêu ví dụ trạng thái Draft, Active, Revised và revision ID. RFP nên yêu cầu hành vi không phụ thuộc thuật ngữ hãng: bản đã gửi khách không tự đổi khi rule hoặc price list cập nhật, và bản revise phải thể hiện khác biệt.

Tạo bảng chuyển từ Sales Configuration sang Manufacturing Configuration

Sales option không luôn tương ứng một part. Một lựa chọn có thể thêm nhiều component, machining, inspection và document. Nhiều lựa chọn khách hàng cũng có thể cùng quyết định một subassembly.

Kiểm routing, resource và inspection chứ không chỉ BOM. Oracle mô tả ví dụ work definition của configured item được tạo từ model, selected option và attribute giao dịch. Điều này không áp đặt một kiến trúc, nhưng cho thấy nghiệm thu không được dừng ở parts list.

Năm kiểm tra để tránh “cấu hình hợp lệ nhưng không sản xuất được”

1. Completeness: đủ attribute, document và customer response bắt buộc.
2. Consistency: không có lựa chọn loại trừ nhau, thiếu capacity hoặc chuẩn không tương thích.
3. Master existence: item, operation, resource, supplier và document tồn tại ở plant mục tiêu.
4. Revision validity: revision có hiệu lực tại ngày dự kiến order và production.
5. Executability: lộ rõ long-lead item, capacity, special engineering và test facility.

Nếu CPQ không tự tính feasibility, nhận kết quả kiểm từ ERP, PLM, planning hoặc MES. Quy định khi service không trả lời thì chỉ cho save, cho warning có kiểm soát hay block gửi khách. Nguy hiểm nhất là âm thầm dùng stale value như giá trị hợp lệ.

Trách nhiệm dữ liệu giữa ERP, MES, CRM và PLM

CPQ thường nằm giữa nhiều hệ thống, vì vậy ownership quan trọng hơn số connector.

Dữ liệu nhận và trả CRM

CRM thường là nguồn chuẩn của customer, opportunity, activity và probability, nhưng không nhất thiết của configuration rule. CPQ nhận opportunity ID và trả quote number, configuration status, amount, margin band, approval state, expiry và document link. Xác định idempotency key và cách xử lý opportunity merge, copy hoặc đổi account.

Ranh giới với PLM

Khi PLM quản lý product structure và engineering change, CPQ nên dùng sellable view đã duyệt. Development part và rule chưa duyệt không được lộ cho sales. Đơn đặc biệt có thể tạo engineering task từ CPQ; PLM trả kết quả đã duyệt vào configuration revision. Việc nâng một special solution thành standard option phải là change process riêng.

Siemens mô tả variant-management backbone chung giữa nhiều bộ phận. Không phụ thuộc nền tảng, nguyên tắc là sales và engineering không duy trì tên option, rule và revision khác nhau cho cùng quyết định.

Ranh giới với ERP

ERP có thể sở hữu item, customer condition, price, inventory, procurement, cost, order và production. Tài liệu SAP mô tả đồng bộ product data từ back office, dùng configuration/pricing service và kết hợp quote data với configuration data khi chuyển cấu hình sang S/4HANA. Bài học là không tùy tiện xây lại tri thức sẵn có trong CPQ; phải xác định nơi bảo trì và revision được gọi.

Interface phải bao gồm cả tình huống không bình thường:

• Create, revise, cancel, reopen, lose và convert-to-order.
• Idempotent khi nhận lại cùng request.
• Conflict detection cho configuration/price revision cũ.
• Retry và reconciliation sau partial failure.
• Unit, currency, tax, rounding và time zone.
• Lý do, thẩm quyền và audit evidence khi sửa bằng tay.

Bàn giao sang MES

Thông thường CPQ không nên ra lệnh trực tiếp cho máy. ERP và PLM xác nhận order cùng manufacturing definition, rồi MES triển khai xuống thực thi. Nếu thông số khách hàng từ CPQ ảnh hưởng work instruction, inspection hoặc traceability, hãy mang configuration ID và requirement ID vào production order. Điều kiện nghiệm thu là hiển thị đúng giá trị và tài liệu tại đúng operation, không buộc operator diễn giải PDF free text.

Phần kế hoạch, tiến độ và kiểm soát thay đổi sau order được trình bày trong hướng dẫn quản lý sản xuất Make-to-Order. Dùng cùng bài này để làm rõ điểm kết thúc CPQ và điểm bắt đầu production management.

Phê duyệt và Audit rộng hơn duyệt chiết khấu

Approval CPQ kiểm soát rủi ro kỹ thuật và giao hàng cùng với giá.

Trigger có thể kết hợp amount, rule override, margin band, promise date, region, family và contract condition. Quy định self-approval, delegation, overdue, request change và edit sau phê duyệt. Tài liệu workflow Microsoft có ví dụ approve, reject, request-change, delegate, final approver và disallow self-approval. Viết thành control cần có thay vì tên feature.

Audit log phải giữ ai đổi giá trị nào, lúc nào, trước/sau ra sao; rule revision, price revision và cost reference đã dùng; giá trị tính tự động hay override cùng lý do; approval trigger nào chạy; customer document liên kết snapshot nào; quote revision nào thành order. Màn hình chỉ thấy giá trị mới nhất không phải audit trail. Business user cần tìm kiếm và export với retention, privacy, access và deletion rõ ràng.

15 mục trong RFP CPQ sản xuất

1. Product family và phạm vi loại trừ: mô tả option, complexity, special order, tác động BOM/routing và region.
2. As-Is/To-Be scenario: copy, revise, customer change, reopen, post-order change và chuyển special thành standard.
3. Attribute/term/unit dictionary: ID, label, type, unit, enumeration, translation, Owner, source.
4. Rule lifecycle: type, revision, effective date, source, author, review, approval, release, retirement, test, impact.
5. Configuration session: save/resume, collaboration, lock, copy, compare, difference, expiry, re-evaluation.
6. Price/cost/margin: nguồn chuẩn, refresh, currency, tax, rounding, plant, quantity, service, discount, override, failure.
7. Promise date: phân biệt fixed lead time, item LT, stock, capacity, outsource và engineering effort.
8. Document generation: quote, spec, condition, drawing, approval, language, template revision, e-signature.
9. Variant BOM/routing: mapping selection sang part, quantity, operation, inspection, document và special task.
10. ERP/PLM/CRM/MES integration: direction, timing, key, revision, retry, conflict, reconciliation, monitoring, Owner.
11. Approval/segregation: commercial, technical, supply, risk, delegation, timeout, escalation, self-approval, post-edit.
12. Security: role, site, product, account, SSO, admin, API credential, backup, log, leaver process.
13. Performance/availability: rule evaluation, document, concurrency, external wait, timeout, degraded mode với điều kiện đo.
14. Migration/quality: dữ liệu Excel/legacy, rule equivalence, Golden Configuration, regression test.
15. Handover/exit: editable model, setting, code, API, test, training, licence, data export, successor migration.

Ma trận trả lời RFP có thể so sánh

“Standard,” “custom” và “integration” có thể mang nghĩa khác nhau. Yêu cầu mỗi requirement có:

Demo phải dùng representative configuration do bên mua cung cấp, không chỉ happy path của bên bán. Hãy demo thiếu option bắt buộc, prohibited combination, old revision, pricing service lỗi, approval bị trả lại, thiếu BOM mapping và duplicate transmission.

PoC 90 ngày có giới hạn: chứng minh một Product Family từ đầu đến cuối

Đây là ví dụ kế hoạch của TOMAS TECH, không bảo đảm mọi enterprise rollout hoàn thành trong 90 ngày. Giới hạn một product family, representative configuration và một số interface để tạo bằng chứng Go/No-Go.

Sản phẩm quá đơn giản che rủi ro; sản phẩm khó nhất biến đánh giá platform thành dự án custom. Chọn family trung bình có standard option, dependent rule, price variation, approval, BOM/routing difference và một ít exception. Nếu không đưa dữ liệu thật vào PoC, hãy ẩn danh nhưng giữ hierarchy, unit, missing-data pattern và revision behaviour. Không nghiệm thu bằng sample data hoàn hảo.

Acceptance Gate: đánh giá Evidence nghiệp vụ, không đánh dấu Function List

Gate 1 — Configuration Quality

• Không submit khi thiếu mandatory condition.
• Prohibited combination bị block với lý do hiểu được.
• Exception cần reason và approval.
• Cùng input và model revision tạo cùng result.
• Mở quote cũ không âm thầm đổi model revision.

Gate 2 — Price và Promise Control

• Truy được price, cost, currency, quantity, tax, rounding.
• Manual override có authority, reason, difference, approval.
• Service lỗi không được coi stale answer là thành công.
• Bản gửi khách không đổi sau master update.

Gate 3 — Manufacturing Handoff

• Configuration ID/revision đã order được đăng downstream đúng một lần.
• BOM line, quantity, operation, inspection, document khớp expected result.
• Phát hiện item, route hoặc mapping thiếu và trả về Owner.
• Phát hiện xung đột giữa revised quote và production instruction cũ.

Gate 4 — Approval và Audit

• Đúng luồng cho technical, commercial và supply trigger.
• Tái hiện originator, delegate, overdue, return và resubmit.
• Post-approval edit phải reapprove hoặc theo rule công bố.
• Truy user, rule, price, document và integration từ một opportunity.

Gate 5 — Operability

• Admin khách hàng quản trị attribute, translation, rule, effective date.
• Regression test tự động hoặc có quy trình lặp lại.
• Demo monitoring, retry, reconciliation, backup, restore.
• Có Owner cho training, access, incident và change request.

Acceptance record cần requirement ID, precondition, action, expected, actual, evidence link, defect ID, retest và approver. “Đã chạy trong demo” không phải bằng chứng.

Yêu cầu địa phương cho cơ sở tại Thái Lan

Đa ngôn ngữ là Master Governance, không chỉ dịch màn hình

Sales có thể dùng tiếng Anh, trụ sở Nhật dùng tiếng Nhật và nhà máy dùng tiếng Thái. Product name, attribute, option, warning, quote term và work instruction đi qua nhiều ngôn ngữ. Giữ technical ID chung, xác định Owner dịch, review, effective date và fallback, đồng thời duy trì glossary đã duyệt.

Làm rõ Currency, Tax và Rounding

Với THB, JPY, USD, hãy tách nguồn và ngày tỷ giá, price-list currency, display currency, cost currency và rounding. Chuyên gia địa phương cùng finance quyết định thuế; CPQ tái tạo rule đã duyệt và giữ dấu vết rule đã dùng.

Hài hòa Rule trụ sở với Supply địa phương

Cấu hình chuẩn toàn cầu có thể gặp part, certification, lead time và service khác tại Thái Lan. Tách global rule khỏi plant/market overlay và tránh copy toàn bộ rule để từng cơ sở tự sửa.

Xác nhận BOI thay vì suy đoán

BOI Thái Lan công bố thông tin chính thức về Smart and Sustainable Industry, nhưng dự án CPQ không tự động đủ điều kiện ưu đãi. Nếu đưa vào kế hoạch đầu tư, hãy xác nhận announcement, activity, deadline và eligible investment hiện hành với BOI hoặc chuyên gia.

Tám lỗi phổ biến khi triển khai CPQ

1. Kết thúc ở PDF tự động: nếu BOM/routing/order entry còn thủ công, bottleneck chính vẫn còn.
2. Tách Sales Rule và Engineering Rule: revision sẽ drift; cần một record và một cơ chế phân phối.
3. Cấm quá nhiều Exception: đơn đặc biệt chạy về email; hãy cấu trúc approval, impact và reuse.
4. Giá mới nhưng Cost cũ: hiển thị timestamp và xác định lúc phải recalculation.
5. Có BOM nhưng không có Routing/Inspection: nghiệm thu part, operation, inspection, document và engineering task.
6. Không Regression sau đổi Rule: duy trì Golden Configuration cho valid, prohibited, boundary và override.
7. Coi “có API” là tích hợp xong: test ID, revision, idempotency, conflict và error Owner.
8. Định nghĩa thành công PoC sau Demo: chốt gate, defect cho phép, open condition và quyền Go/No-Go trước.

FAQ: Hệ thống CPQ, chi phí, tích hợp ERP và PoC

CPQ cho sản xuất là gì?

Đó là hệ thống chuyển yêu cầu khách hàng thành cấu hình có thể sản xuất, tính giá và điều kiện, rồi tạo báo giá được duyệt. Giá trị sản xuất là tái sử dụng cấu hình trong BOM, routing, inspection và order.

CPQ khác hệ thống báo giá thế nào?

Hệ thống báo giá thông thường tập trung item, quantity, unit price và document. CPQ quản lý option dependency, prohibited combination, derived value và conditional pricing. Vì phạm vi sản phẩm khác nhau, hãy so bằng acceptance scenario.

Nên đặt Product Rule ở CPQ hay ERP?

Không có đáp án chung. Quyết định dựa trên variant configurator hiện có, PLM, pricing architecture và năng lực tổ chức. Tránh ownership trùng và giữ rule revision mỗi quote đã dùng.

CPQ có tự động tạo Variant BOM không?

Tùy sản phẩm và kiến trúc. CPQ có thể giữ conditional BOM, gọi ERP/PLM configurator hoặc gửi sales configuration xuống hệ thống dưới để tạo BOM. Test quantity, operation, inspection và document cùng part.

So sánh chi phí triển khai CPQ thế nào?

So sánh licence, modelling, rule preparation, migration, ERP/PLM/CRM integration, document, language, test, training, operation, change, upgrade và exit data trong cùng thời gian và scope. Chốt product family và số interface trước khi xin giá.

PoC CPQ 90 ngày cần chứng minh gì?

Với một family đại diện, chứng minh requirement input, rule, price, approval, document, configuration revision, order, BOM/routing handoff, negative case và audit từ đầu đến cuối. Mục đích là Go/No-Go về phương pháp và data quality, không phải rollout toàn doanh nghiệp.

RFP CPQ nên bắt đầu bằng yêu cầu nào?

Target family, rule ownership, configuration ID/revision, downstream deliverable, approval responsibility và acceptance scenario. Bắt đầu từ danh sách màn hình sẽ trì hoãn quyết định ownership khó nhất.

Nhiều hàng đặt riêng có dùng CPQ được không?

Có, nếu phân biệt standard selection, parametric variation, exception cần engineering approval và true custom engineering. Quản lý custom work thành task và deliverable, không giả vờ mọi yêu cầu đã là standard option.

Có nên để Generative AI tự tạo Product Rule?

AI có thể giúp trích candidate rule và test từ tài liệu, nhưng con người vẫn chịu trách nhiệm cho rule liên quan physics, safety, cost và supply. Không publish nếu thiếu evidence, Owner, revision control và regression test.

Tổng kết: ký hợp đồng để không phải diễn giải lại sau Order, không chỉ để Quote nhanh hơn

Triển khai CPQ sản xuất không chỉ là dự án nhập liệu bán hàng nhanh hơn. Nó tạo dòng dữ liệu truy vết từ customer requirement qua product rule, pricing, approval và configuration revision vào variant BOM, routing, inspection và production instruction, để nhà máy thực hiện đúng lời hứa khách hàng đã chấp thuận.

RFP nên yêu cầu scenario và evidence cho representative configuration, exception, revision, service failure, rejected approval và missing manufacturing mapping, thay vì danh sách tên chức năng. PoC 90 ngày có giới hạn cần đưa một family đi từ đầu đến cuối và đánh giá qua năm gate: configuration quality, price/promise, manufacturing handoff, audit và operability.

TOMAS TECH có thể hỗ trợ xây dựng concept CPQ cho nhà máy và hoạt động bán hàng tại Thái Lan, chọn product family đại diện, inventory rule, chuẩn bị RFP response matrix, vẽ ranh giới ERP/PLM/MES, tổ chức PoC 90 ngày và acceptance case. Doanh nghiệp có thể trao đổi ngay cả khi chưa chọn sản phẩm qua trang liên hệ.

Tài liệu tham khảo

• Microsoft Learn: Product configuration models overview
• SAP Help Portal: SAP CPQ Integration Guide — Technical Overview
• SAP: S/4HANA Sales Order Integration for Quote 2.0
• Oracle: Overview of Configure-to-Order
• Oracle: How You Create a Configured Item Work Definition
• Microsoft Learn: Manage quote, order, and invoice
• Microsoft Learn: Configure approval processes in a workflow
• Siemens: Teamcenter Product Configurator
• Thailand BOI: Smart and Sustainable Industry guide

Lưu ý: PoC 90 ngày, các mục RFP và acceptance gate là ví dụ lập kế hoạch của TOMAS TECH, không bảo đảm thời gian hoặc kết quả giống nhau cho mọi doanh nghiệp. Cần xác nhận pháp lý, thuế, điều kiện BOI và hợp đồng theo sản phẩm, quốc gia và khách hàng với chuyên gia phù hợp.