Change Control — Kiểm soát thay đổi và Substitution của gạch
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. Change Control là gì?
Change Control — Kiểm soát thay đổi là quá trình nhận diện, đánh giá, xác nhận và ghi nhận những thay đổi có thể ảnh hưởng đến lựa chọn gạch, Specification, Approval, Procurement hoặc Supply của dự án.
Trong Tile Management, Change Control giúp trả lời:
Điều gì đã thay đổi?
Vì sao thay đổi?
Ảnh hưởng đến lựa chọn gạch ở mức nào?
Ai cần xem xét / xác nhận?
Phiên bản nào hiện hành?
Change Control không nhằm ngăn mọi thay đổi.
Mục tiêu là:
Change rõ → Review đúng → Approval đúng → Supply đúng
02. Vì sao Tile cần Change Control?
Một lựa chọn gạch có thể đã đi qua:
Specification
→
Sample
→
Approval
→
Sourcing
→
Availability
→
Procurement
→
Supply
Trong quá trình đó, dự án vẫn có thể thay đổi.
Ví dụ:
- Product Code thay đổi
- Format thay đổi
- Surface thay đổi
- Color thay đổi
- Quantity thay đổi
- Source thay đổi
- Required Date thay đổi
- Area thay đổi
Nếu không kiểm soát, một thay đổi nhỏ có thể tạo ra:
Specification không còn khớp Approval
hoặc:
Order không còn khớp Product được duyệt
hoặc:
Supply không còn khớp Order
03. Change không đồng nghĩa với Substitution
Đây là nguyên tắc quan trọng.
Change — Thay đổi là khái niệm rộng.
Substitution — Thay thế là một loại thay đổi cụ thể khi sản phẩm được thay bằng một lựa chọn khác.
Ví dụ:
Quantity Change
không nhất thiết là:
Tile Substitution
Trong khi:
Product Code Change
có thể là:
Tile Substitution
Không dùng hai khái niệm như đồng nghĩa.
04. Approved Tile là điểm tham chiếu
Change Control phải quay về:
Current Approved Tile
Đây là lựa chọn đã được xác định trong:
- Product Identity
- Configuration
- Project Context
- Approval Status
- Revision
Khi có thay đổi, trước tiên cần xác định:
Current Approved Choice là gì?
Sau đó mới xác định:
Change ảnh hưởng đến lựa chọn đó như thế nào?
05. Current State trước Change
Trước khi kiểm soát thay đổi cần xác định:
- Current Product Code
- Current Product Name
- Current Collection
- Current Color
- Current Format
- Current Surface
- Current Project Area
- Current Approval
- Current Revision
- Current Supply / Procurement status khi relevant
Không thể kiểm soát Change nếu không biết:
Current State
06. Change Request là gì?
Change Request — Yêu cầu thay đổi là đề xuất rằng một thông tin, sản phẩm, điều kiện hoặc cách cung ứng đã được xác định trước đó cần được thay đổi.
Change Request có thể xuất phát từ:
- Design
- Client / Developer
- Contractor
- Supplier
- Site
- Availability
- Procurement
- Commercial condition
Không phải mọi Change Request đều được chấp thuận.
Request ≠ Approved Change
07. Change Trigger
Một Change Trigger — Tác nhân thay đổi có thể là:
- Product không còn phù hợp
- Source không còn đáp ứng
- Availability thay đổi
- Quantity thay đổi
- Design thay đổi
- Area thay đổi
- Specification thay đổi
- Commercial condition thay đổi
- Site condition thay đổi
Trigger chỉ giải thích:
Why Change?
Không tự xác định:
What should replace it?
08. Change Reason
Mọi thay đổi quan trọng nên có:
Change Reason — Lý do thay đổi
Có thể thuộc các nhóm:
- Design
- Commercial
- Availability
- Supply
- Site
- Client Request
- Specification Revision
Không tự tạo lý do.
Nếu chưa rõ:
Reason Pending Confirmation
09. Change Scope
Không phải thay đổi nào cũng có cùng mức ảnh hưởng.
Một Change có thể ảnh hưởng đến:
Level 1
Documentation only
Level 2
Quantity / timing
Level 3
Source
Level 4
Product Configuration
Level 5
Product Identity / Approved Tile
Mức ảnh hưởng quyết định bước review tiếp theo.
Không đánh đồng mọi thay đổi với Substitution.
10. Product Identity Change
Nếu thay đổi:
- Product Code
- Product Name khi gắn với identity khác
- Collection
- Color
- Format
- Surface
- Configuration có tính nhận diện sản phẩm
thì cần kiểm tra liệu:
Product Identity có thay đổi hay không?
Nếu Product Identity thay đổi:
Không được coi là chỉ một Order Amendment đơn giản.
Cần quay lại quy trình review phù hợp.
11. Product Code Change
Product Code Change là một trong những thay đổi cần kiểm soát chặt nhất.
Không được:
đổi mã trong Order rồi tiếp tục như thể vẫn là cùng lựa chọn.
Nếu Product Code thay đổi:
Current Approved Tile
có thể không còn là:
New Product
Cần:
Review → Approval khi required → Specification Update → Procurement / Supply Update
12. Format Change
Ví dụ:
600 × 600
→
600 × 1200
đây không chỉ là thay đổi về cách đóng gói.
Format có thể ảnh hưởng:
- Design Intent
- Layout
- Joint
- Quantity
- Installation
- Procurement
- Supply
Vì vậy Format Change phải được đánh giá theo Project Context.
Không tự thay Format để “cho tiện hàng”.
13. Surface Change
Ví dụ:
Matt
→
Polished
hoặc:
Matt
→
Mould / Structured
có thể tạo ra khác biệt về:
- Visual
- Light response
- Tactility
- Cleaning / use context
- Specification
Không coi Surface Change là cosmetic change mặc định.
14. Color Change
Color Change có thể ảnh hưởng:
- Design Intent
- Material Language
- Material Dialogue
- Approval
- Project Experience
Nếu Color là một phần của Approved Configuration:
Color Change cần review phù hợp.
Không tự đổi màu vì source đang có màu khác.
15. Pattern / Character Change
Một sản phẩm có thể thay đổi:
- Pattern
- Veining
- Character
- Variation
Nếu những yếu tố này là một phần quan trọng của lựa chọn đã duyệt:
cần xác định:
đây có còn là cùng Product Configuration không?
Không dùng:
“Nhìn cũng gần giống.”
thay cho đánh giá có kiểm soát.
16. Variation Change
Variation là một phần của trải nghiệm bề mặt.
Nếu thay sản phẩm hoặc Configuration làm thay đổi:
Variation
thì cần đánh giá ảnh hưởng đến:
- Design Intent
- Sample
- Approval
- Installed Appearance
Không tự coi:
Variation khác = cùng lựa chọn
17. Face Count Change
Face Count có thể liên quan đến khả năng thể hiện variation.
Nhưng:
Face Count Change không tự động = Product Change
Cần xác định:
- Product Code có đổi không?
- Configuration có đổi không?
- Product Identity có đổi không?
Không suy luận chỉ từ Face Count.
18. Source Change
Source Change xảy ra khi nguồn cung thay đổi nhưng Product Identity có thể vẫn giữ nguyên.
Ví dụ:
Source A
→
Source B
với:
Same Product Identity
Trong trường hợp này:
Source Change ≠ Automatically Tile Substitution
Nhưng cần kiểm soát lại:
- Source Verification
- Availability
- Commercial condition
- Supply condition
19. Supplier Change không phải luôn là Tile Change
Một supplier khác có thể cung cấp cùng Product Identity.
Nếu đã xác minh:
Same Product
thì thay supplier không nhất thiết là thay tile.
Ngược lại:
nếu supplier mới đề xuất:
Product Code khác
thì đó có thể là:
Tile Alternative / Substitution
Phải phân biệt rõ.
20. Quantity Change
Quantity Change có thể xảy ra mà Product Identity không thay đổi.
Ví dụ:
100 m² → 120 m²
Đây là:
Quantity Change
không nhất thiết là:
Tile Substitution
Tuy nhiên Quantity Change có thể ảnh hưởng:
- Availability
- Procurement
- Supply
- Commercial condition
nên cần được cập nhật ở các bước liên quan.
21. Area / Application Change
Một Product có thể được duyệt cho:
Area A
nhưng sau đó được đề xuất dùng cho:
Area B
Đây không nhất thiết là Product Change.
Nhưng Project Context đã thay đổi.
Cần kiểm tra:
- Application
- Design Intent
- Specification
- Approval
- Technical context khi relevant
22. Design Intent Change
Nếu Design Intent thay đổi:
Product có thể không còn phù hợp dù:
Availability vẫn tốt
hoặc:
Price vẫn tốt
Change Control phải quay lại câu hỏi:
Approved Tile có còn phục vụ Design Intent hiện tại không?
Không để Availability quyết định Design Intent.
23. Availability-Driven Change
Có thể xảy ra:
Approved Tile
nhưng:
Availability không đáp ứng
Khi đó không được tự substitution.
Có thể xem xét:
Source Change
hoặc:
Alternative Tile
Nhưng hai hướng này có quy trình khác nhau.
24. Substitution là gì?
Substitution — Thay thế gạch là việc sử dụng một Product / Configuration khác thay cho lựa chọn đã được xác định trước đó.
Nếu:
Product Identity thay đổi
thì cần xem xét đây có phải:
Substitution
hay không.
Không gọi một sản phẩm khác là:
“same tile”
chỉ vì ngoại quan gần giống.
25. Similar ≠ Equivalent
Đây là nguyên tắc bắt buộc.
Similar Appearance
không đồng nghĩa:
Equivalent Product
Các điểm có thể khác:
- Product Code
- Format
- Surface
- Color
- Pattern
- Variation
- Performance
- Source
- Availability
- Commercial Condition
Không dùng “equivalent” nếu chưa có cơ sở phù hợp.
26. Alternative Proposal
Alternative Proposal — Đề xuất phương án thay thế là bước trước Approval.
Một Alternative có thể được đề xuất vì:
- Availability
- Commercial
- Design
- Supply
- Product Discontinuation
Nhưng:
Alternative Proposal ≠ Approved Alternative
27. New Approval
Nếu Alternative thay đổi Product Identity hoặc Configuration có ảnh hưởng đến lựa chọn đã duyệt:
cần có:
New Review
và khi cần:
New Approval
Không:
Old Approval → Automatically Apply to New Tile
28. Change không xóa lịch sử
Một nguyên tắc quan trọng:
Current State
không được thay thế đến mức:
Historical State biến mất.
Cần giữ:
- Old Product
- New Product
- Old Revision
- New Revision
- Change Date
- Change Reason
- Approval status
- Effective status
Đây là nền tảng cho Traceability ở bước tiếp theo.
29. Effective Date
Một Change cần có:
Effective Date — Ngày bắt đầu có hiệu lực
đặc biệt khi dự án có:
- nhiều delivery
- nhiều revision
- nhiều order
- nhiều area
Không tự coi một Change có hiệu lực cho toàn bộ lịch sử.
30. Revision Control
Change phải tạo hoặc liên kết với:
Revision
Ví dụ:
Rev.01
↓
Change Request
↓
Review
↓
Rev.02
Revision giúp trả lời:
Phiên bản nào đang được áp dụng?
Không dùng nhiều file / document khác nhau mà không xác định Current Revision.
31. Change Status
Có thể sử dụng:
- Draft
- Requested
- Under Review
- Approved
- Rejected
- Superseded
- Cancelled
Đây là:
Change Status
không phải:
Product Quality Status
Không dùng status để ranking.
32. Change Approval
Approved Change phải được phân biệt với:
Change Request
và:
Proposed Alternative
Không được coi:
“Đã gửi đề xuất”
là:
“Đã được duyệt.”
33. Multiple Approvers
Một Change có thể liên quan đến:
- Designer / Architect
- Client / Developer
- Contractor
- Technical team
- Procurement
- Supplier
Không mặc định chỉ có một người phê duyệt.
Quan trọng là xác định:
ai có quyền xác nhận loại thay đổi nào trong Project Context hiện tại.
Không tự tạo tên người duyệt.
34. Change Impact Assessment
Một Change nên được đánh giá ảnh hưởng đến:
- Design Intent
- Material Language
- Product Identity
- Specification
- Sample
- Approval
- Availability
- Procurement
- Supply
Không phải Change nào cũng ảnh hưởng tất cả.
Mục tiêu:
đánh giá đúng phạm vi, không overreact cũng không bỏ sót.
35. Change Impact Matrix
Có thể dùng framework:
| Change | Specification | Approval | Availability | Procurement | Supply |
|---|---|---|---|---|---|
| Quantity | ✓ | — | ✓ | ✓ | ✓ |
| Source | — | — / Review | ✓ | ✓ | ✓ |
| Format | ✓ | ✓ | ✓ | ✓ | ✓ |
| Surface | ✓ | ✓ | ✓ | ✓ | ✓ |
| Product Code | ✓ | ✓ | ✓ | ✓ | ✓ |
Đây là framework minh họa.
Không xem mọi Project đều phải áp dụng giống nhau.
36. Change Control và Supply
Một Change xảy ra sau Procurement hoặc Supply có thể ảnh hưởng:
- Order
- Delivery
- Remaining Quantity
- Next Delivery
- Site Stock
Không tự áp dụng Change mới cho hàng đã giao nếu chưa có quyết định phù hợp.
Đây là lý do Current State và Effective Date quan trọng.
37. Change Control và Batch / Lot
Nếu Change liên quan đến:
- Product
- Format
- Surface
- Batch
- Supply period
cần xác định Change áp dụng cho:
từ thời điểm nào / delivery nào / area nào.
Không mặc định Change áp dụng ngược cho hàng đã giao.
38. Moongres Change Control Framework
Framework:
Current Approved Tile
↓
Change Trigger
↓
Change Request
↓
Impact Assessment
↓
Review
↓
Decision
↓
Approval / Rejection
↓
Revision
↓
Update Specification / Procurement / Supply
MMS.05.10 tập trung vào:
Change Decision + Controlled Update
Không đi sâu vào Traceability Record và Handover.
39. Checklist trước khi xác nhận Change
[ ] Current Product được xác định
[ ] Current Revision được xác định
[ ] Change Reason rõ
[ ] Change Scope rõ
[ ] Product Identity có thay đổi hay không
[ ] Quantity có thay đổi hay không
[ ] Source có thay đổi hay không
[ ] Format có thay đổi hay không
[ ] Surface có thay đổi hay không
[ ] Color có thay đổi hay không
[ ] Project Area có thay đổi hay không
[ ] Approval ảnh hưởng hay không
[ ] Availability ảnh hưởng hay không
[ ] Procurement ảnh hưởng hay không
[ ] Supply ảnh hưởng hay không
[ ] Alternative / Substitution được xác định rõ
[ ] Review đã thực hiện khi cần
[ ] Approval đã được xác nhận khi cần
[ ] Revision mới đã được xác định
[ ] Effective Date rõ
[ ] Current State đã được cập nhật
[ ] Historical State không bị xóa
40. Từ Change đến một lựa chọn được kiểm soát
Change Control giúp dự án đi từ:
“Có một thay đổi xảy ra.”
đến:
“Đã xác định thay đổi đó là gì, ảnh hưởng thế nào, được ai xem xét, phiên bản nào có hiệu lực và các bước tiếp theo phải cập nhật ra sao.”
Logic:
Current Approved Tile
→
Change Trigger
→
Change Request
→
Impact Assessment
→
Review
→
Decision
→
Approval / Rejection
→
Revision
→
Specification Update
→
Procurement / Supply Update
Và nguyên tắc quan trọng nhất:
Không tự đổi gạch chỉ vì nguồn thay đổi.
Không tự đổi mã chỉ vì hàng khác dễ mua hơn.
Không tự coi sản phẩm tương tự là sản phẩm tương đương.
Không tự áp dụng Approval cũ cho Product mới.
Không xóa lịch sử thay đổi.
Change Control không làm dự án “cứng” hơn.
Nó giúp bảo đảm:
Đúng thay đổi → Đúng người xem xét → Đúng Approval → Đúng Revision → Đúng gạch được cung ứng.
