Tile Procurement — Chuyển Specification thành Order
Mục lục — 40 mục trong 6 nhóm
01 — Nền tảng và khái niệm cốt lõiMục 01–07
02 — Các yếu tố và tiêu chí cần đọcMục 08–14
03 — Đánh giá và ra quyết địnhMục 15–21
04 — Phối hợp trong bối cảnh dự ánMục 22–28
05 — Kiểm soát triển khaiMục 29–35
06 — Framework, checklist và kết luậnMục 36–40
01. Tile Procurement là gì?
Tile Procurement — Cung ứng / mua sắm gạch cho dự án là quá trình chuyển một lựa chọn gạch đã được xác định và kiểm tra khả năng đáp ứng thành một yêu cầu mua hàng / Order có thể thực hiện được.
Tile Procurement nằm sau:
Specification → Sample → Approval → Sourcing → Availability
và trước:
Tile Supply → Delivery → Handover
Procurement phải bảo đảm:
Đúng gạch → Đúng số lượng → Đúng source → Đúng điều kiện → Đúng Order
02. Availability chưa phải Procurement
Một sản phẩm có thể đã:
Available
nhưng chưa đồng nghĩa:
Ordered
Availability trả lời:
Có thể đáp ứng không?
Procurement trả lời:
Cần mua / đặt sản phẩm gì, số lượng bao nhiêu và theo điều kiện nào?
Vì vậy:
Availability ≠ Procurement
03. Procurement bắt đầu từ Specification
Procurement không nên bắt đầu bằng:
“Anh/chị lấy giúp mã này.”
Mà bắt đầu từ dữ liệu đã được xác định:
- Product Code
- Product Name
- Collection
- Color
- Format
- Surface
- Area / Application
- Required Quantity
- Source
- Revision / current version khi cần
Specification là nền tảng để Order không bị mơ hồ.
04. Approved Tile trước, Order sau
Chuỗi logic:
Design Intent
→
Material Selection
→
Tile Specification
→
Material Sample
→
Sample Approval
→
Tile Sourcing
→
Tile Availability
→
Tile Procurement
Approval xác định:
Được mua sản phẩm nào.
Procurement xác định:
Mua sản phẩm đó theo yêu cầu nào.
05. Product Identity là điểm neo của Order
Một Order phải quay về đúng:
Product Identity
bao gồm những thông tin cần thiết để xác định chính xác sản phẩm.
Không chỉ ghi:
“Gạch đá màu beige.”
Mà cần có nhận diện rõ ràng theo Specification.
Không được tự đổi:
- Product Code
- Format
- Surface
- Color
- Collection
chỉ vì nguồn cung đề xuất sản phẩm khác.
06. Product Code là Order Anchor
Product Code — Mã sản phẩm là điểm neo quan trọng trong Procurement.
Một Order có thể có nhiều line item, nhưng mỗi line item phải có Product Identity đủ rõ để tránh nhầm.
Không dùng:
- nickname
- tên nội bộ không kiểm soát
- tên cảm tính
- hình ảnh thay cho Product Code
làm Product Identity chính thức nếu đã có mã sản phẩm.
07. Order Line là gì?
Mỗi Order Line — Dòng hàng nên đại diện cho một lựa chọn sản phẩm cụ thể.
Có thể bao gồm:
- Product Code
- Product Name
- Color
- Format
- Surface
- Quantity
- Unit
- Notes / configuration khi cần
Một Order Line rõ giúp hạn chế:
- nhầm mã
- nhầm format
- nhầm surface
- nhầm quantity
08. Quantity trong Procurement
Quantity phải được đọc từ:
Project Requirement
và Availability đã được xác nhận.
Cần phân biệt:
Required Quantity
với:
Order Quantity
Hai con số này có thể không hoàn toàn giống nhau tùy commercial / installation / project condition.
Không tự thêm:
- hao hụt
- dự phòng
- contingency
nếu chưa có cơ sở hoặc chưa được xác nhận.
09. Unit cần được thống nhất
Quantity phải đi cùng:
Unit — Đơn vị tính
Có thể là:
- m²
- viên
- thùng
- kiện
- pallet
Tùy cách sản phẩm được commercialized.
Không trộn:
m²
với:
box
mà không có quy đổi rõ ràng.
Không tự suy luận số viên / thùng nếu dữ liệu đóng gói chưa được xác nhận.
10. Pack Size và Conversion
Một sản phẩm có thể được báo theo:
m²
nhưng được đóng gói theo:
box
hoặc đơn vị khác.
Nếu cần chuyển đổi:
Order Quantity ↔ Packing Unit
phải dựa trên dữ liệu đóng gói đã xác minh.
Không tự tạo:
- số viên / box
- m² / box
- box / pallet
- pallet / container
11. Order Quantity và Packing Quantity
Có thể xảy ra:
Required Quantity
khác:
Packable Quantity
khi sản phẩm chỉ được bán theo đơn vị đóng gói nhất định.
Procurement cần thể hiện rõ:
- yêu cầu dự án
- đơn vị đặt hàng
- đơn vị đóng gói
để tránh hiểu nhầm số lượng.
12. Procurement không tự thay đổi Specification
Nếu Quantity hoặc Packing Condition tạo ra chênh lệch nhỏ so với nhu cầu:
không tự sửa Specification.
Không tự đổi:
- Product Code
- Format
- Surface
- Collection
để “cho đủ thùng”.
Bất kỳ Product Change nào cần quay lại quy trình thay đổi phù hợp.
13. Source trong Procurement
Procurement phải sử dụng Source đã được xác định / xác minh trong bước Tile Sourcing.
Không tự chuyển sang một supplier khác chỉ vì:
- giá thấp hơn
- trả lời nhanh hơn
- có vẻ sẵn hàng hơn
nếu điều đó làm thay đổi source condition hoặc Product Identity đã được xác lập.
Source Change cần được kiểm soát.
14. Availability phải được kiểm tra trước Order
Procurement không nên đặt hàng dựa trên một Availability Record đã quá cũ nếu tình trạng cung ứng có thể đã thay đổi.
Trước Order cần kiểm tra lại những thông tin quan trọng khi cần:
- Product
- Source
- Quantity
- Availability
- Timing
Procurement dựa trên:
Current Information
không chỉ:
Historical Information
15. Procurement Brief
Một Procurement Brief — Brief đặt hàng có thể bao gồm:
- Project
- Client / Project Reference khi phù hợp
- Product Identity
- Quantity
- Unit
- Source
- Required Date / Window
- Commercial condition
- Documentation requirement
- Notes
- Revision
Mục tiêu:
Order-ready information
16. Procurement Request
Procurement Request — Yêu cầu mua / đặt hàng là bước chuyển từ:
Need
sang:
Request
Request cần đủ rõ để người thực hiện không phải tự đoán.
Một Request tốt trả lời:
Mua gì?
Bao nhiêu?
Từ source nào?
Cho dự án nào?
Theo revision nào?
Khi nào cần?
17. Procurement Request ≠ Purchase Order
Cần phân biệt:
Procurement Request
với:
Purchase Order / Order
Request là yêu cầu nội bộ / đầu vào.
Order là giao dịch / chỉ thị mua hàng đã được xác nhận theo quy trình phù hợp.
Không dùng hai thuật ngữ như đồng nghĩa.
18. Purchase Order là gì?
Purchase Order — PO / Đơn đặt hàng là tài liệu thể hiện các nội dung đặt mua đã được xác nhận theo quy trình của bên mua và / hoặc bên bán.
Tùy doanh nghiệp, PO có thể chứa:
- buyer
- supplier
- project
- product
- quantity
- unit
- price
- currency
- delivery terms
- payment terms
- required date
- reference
- notes
Không tự tạo commercial terms nếu chưa được xác nhận.
19. Commercial Information
Procurement có thể liên quan đến:
- Unit Price
- Currency
- Payment Terms
- Commercial Terms
- Tax treatment
- Freight condition
- Incoterm nếu có
Đây là commercial data.
Không được tự suy luận hoặc lấy giá cũ làm giá hiện hành.
20. Price không phải Product Identity
Một sản phẩm có thể có:
- cùng Product Code
- nhưng giá khác theo:
- quantity
- source
- timing
- commercial condition
Ngược lại:
hai sản phẩm khác Product Code có thể có giá tương tự.
Do đó:
Price ≠ Product Identity
21. Procurement Revision
Order cần có khả năng xác định:
Revision — Phiên bản
khi một yêu cầu đã được thay đổi.
Ví dụ logic:
Rev.01
→
Rev.02
Mỗi revision phải cho biết phiên bản nào đang được sử dụng.
Không để nhiều Order Draft / Request khác nhau cùng tồn tại mà không xác định bản hiện hành.
22. Change Before Order
Nếu thay đổi xảy ra trước khi Order chính thức:
cần cập nhật Procurement Request / Draft / Revision phù hợp.
Không tiếp tục dùng một Request cũ nếu:
- Product Code thay đổi
- Quantity thay đổi
- Source thay đổi
- Timing thay đổi
- Commercial condition thay đổi
khi các thay đổi đó ảnh hưởng Order.
23. Change After Order
Nếu thay đổi xảy ra sau khi Order đã được xác nhận:
đây không còn là một thay đổi Draft đơn giản.
Có thể cần:
- Order Amendment
- Change Confirmation
- Re-confirmation
- Cancellation / Re-order
tùy quy trình thực tế.
Không tự thay đổi một Order đã xác nhận mà không để lại trace.
24. Procurement và Documentation
Tùy dự án, Procurement có thể cần phối hợp với:
- Datasheet
- Catalogue
- Test Documentation
- Origin documentation
- Packing information
- Commercial documents
Nhưng:
Procurement ≠ Technical Approval
Procurement ≠ Test Report Approval
Procurement ≠ Handover
Procurement đảm bảo dữ liệu cần thiết cho quá trình đặt mua được rõ ràng.
25. Procurement và Project Area
Một Product Code có thể được sử dụng ở nhiều area.
Order cần có cách xác định khi cần:
- Project
- Building / Block
- Floor
- Area
- Application
để tránh trường hợp tổng Quantity đúng nhưng phân bổ sai context.
26. Order Consolidation
Một dự án có thể có nhiều area cùng sử dụng một Product Code.
Có thể:
- gộp Order Line
- hoặc tách Order Line
tùy yêu cầu quản lý.
Điều quan trọng là:
Product Identity không được mất.
Gộp Quantity không được làm mất:
- area
- application
- project reference
khi các thông tin đó cần cho Supply và Handover.
27. Procurement và MOQ / Pack Constraint
Một source có thể có:
- MOQ
- packing constraint
- production batch condition
- commercial minimum
Nếu có:
Availability phải được phản ánh thành Procurement Requirement.
Không tự bỏ qua MOQ.
Không tự thay sản phẩm để tránh MOQ.
Nếu MOQ dẫn tới thay đổi quyết định, cần quay lại bước review phù hợp.
28. Procurement và Reservation
Cần phân biệt:
Available
Reserved
Ordered
Confirmed
Đây là các trạng thái khác nhau.
Không được viết:
“Đã có hàng nên xem như đã đặt.”
Availability không tự tạo Order.
29. Procurement Status
Một hệ thống status có thể dùng:
- Draft
- Requested
- Quoted
- PO Pending
- Ordered
- Confirmed
- Amended
- Cancelled
- Closed
Không biến status Procurement thành Quality Ranking.
Mỗi status phải phản ánh trạng thái giao dịch / quy trình.
30. Order Confirmation
Order Confirmation — Xác nhận đơn hàng cần được đối chiếu với Order / Request ban đầu.
Kiểm tra:
- Product Code
- Product Name
- Quantity
- Unit
- Price
- Commercial Terms
- Required Date
- Source
- Notes
Không mặc định:
Supplier Confirmation = tất cả thông tin đều chính xác.
Cần đối chiếu trước khi chuyển sang Supply.
31. Procurement và Supply
Procurement tạo:
Order
Supply thực hiện:
Fulfilment
Có thể hình dung:
Procurement
↓
Order Confirmed
↓
Supply
↓
Delivery
Vì vậy:
Ordered ≠ Delivered
32. Procurement và Delivery
Ngày cần hàng trong Procurement không tự động là:
Delivery Date
Required Date có thể là một project requirement.
Delivery Date cần được xác nhận theo Supply / commercial condition phù hợp.
Không tự biến Required Date thành Delivery Commitment.
33. Procurement Change Control
Một thay đổi trong Order cần được ghi nhận:
- What changed?
- Why?
- When?
- By whom / who confirmed?
- Which revision?
- Which Order?
Mục tiêu:
Traceable Procurement
không phải paperwork nhiều hơn mức cần thiết.
34. Moongres trong Tile Procurement
Moongres có thể đóng vai trò:
Tile Material Consultant
Tile Specification Partner
Tile Supplier
Trong Procurement, Moongres có thể:
- kiểm tra Approved Tile
- đối chiếu Availability
- chuẩn hóa Order Line
- kiểm tra Quantity / Unit
- đối chiếu Source
- ghi nhận Revision
- phối hợp commercial confirmation
- chuyển Order sang bước Supply
Moongres không tự bỏ qua Approval / Availability chỉ để chốt Order nhanh hơn.
35. Procurement Checklist
Một Procurement Request / Order cần kiểm tra:
[ ] Đúng Project
[ ] Đúng Approved Tile
[ ] Đúng Product Code
[ ] Đúng Product Name
[ ] Đúng Collection
[ ] Đúng Color
[ ] Đúng Format
[ ] Đúng Surface
[ ] Đúng Quantity
[ ] Đúng Unit
[ ] Packing condition đã xác minh khi cần
[ ] Source đúng
[ ] Availability đã được xác nhận
[ ] Required Date rõ
[ ] Commercial condition rõ
[ ] Revision rõ
[ ] Order status rõ
[ ] Không silent substitution
36. Procurement Shortlist
Trong một số trường hợp có thể có nhiều:
- Supplier Quote
- Commercial Option
- Source Option
Nhưng Procurement cần quay về:
Approved Product + Valid Source + Current Commercial Information
Shortlist không phải Supplier Ranking.
Mục tiêu là đưa ra:
Order-ready Option
không phải:
Best Supplier
37. Tile Procurement Framework của Moongres
Framework:
Approved Tile
↓
Source
↓
Availability
↓
Procurement Brief
↓
Procurement Request
↓
Order Line
↓
Commercial Confirmation
↓
Purchase Order / Order
↓
Order Confirmation
↓
Supply
MMS.05.08 dừng ở:
Order Confirmation / Ready for Supply
38. Procurement Decision Framework
Có thể kiểm tra theo logic:
A. Product + Quantity + Source + Availability rõ
→ Procurement Ready
B. Product rõ nhưng Quantity chưa rõ
→ Pending Procurement Information
C. Product + Quantity rõ nhưng Availability chưa xác nhận
→ Do Not Order Yet
D. Commercial condition chưa xác nhận
→ Commercial Confirmation Pending
E. Product Identity thay đổi
→ Return to Review / Approval
F. Order đã thay đổi sau confirmation
→ Controlled Order Change
Không tự nhảy qua các trạng thái.
39. Checklist trước khi chuyển sang Supply
[ ] Product Identity được xác nhận
[ ] Approved status phù hợp
[ ] Source phù hợp
[ ] Availability hiện hành đã được kiểm tra
[ ] Quantity đã xác nhận
[ ] Unit đã xác nhận
[ ] Packing / MOQ được xử lý khi cần
[ ] Commercial condition rõ
[ ] Required Date rõ
[ ] Procurement Revision rõ
[ ] Order / PO được xác nhận
[ ] Order Confirmation đã được đối chiếu
[ ] Không còn Product Identity conflict
[ ] Không còn silent substitution
[ ] Change sau Order được kiểm soát
[ ] Dữ liệu đủ rõ để chuyển sang Supply
40. Từ Specification đến Order
Tile Procurement là bước chuyển từ:
“Đây là lựa chọn gạch đã được xác định và có thể đáp ứng.”
sang:
“Đây là Order rõ ràng để nguồn cung có thể thực hiện.”
Logic:
Design Intent
→
Material Selection
→
Tile Specification
→
Material Sample
→
Sample Approval
→
Tile Sourcing
→
Tile Availability
→
Procurement Brief
→
Procurement Request
→
Order Line
→
Commercial Confirmation
→
Purchase Order / Order
→
Order Confirmation
→
Tile Supply
Tile Procurement không tự thay đổi Approved Tile.
Tile Procurement không phải Availability.
Tile Procurement không phải Supply.
Tile Procurement không phải Delivery.
Tile Procurement là bước biến:
Approved + Sourced + Available Tile
thành:
Controlled Order
với đúng:
Product → Quantity → Unit → Source → Commercial Condition → Revision → Confirmation
Đúng gạch → Đúng số lượng → Đúng nguồn → Đúng điều kiện → Đúng Order.
