Technical Proposal cho pilot công nghiệp: viết phạm vi có thể nghiệm thu

01

Viết problem statement có thể kiểm chứng

Mô tả quyết định hiện đang chậm hoặc sai, người ra quyết định, tần suất, chi phí của hiện trạng và dữ liệu đang có. Tránh bắt đầu bằng tên sản phẩm. Ví dụ: đội reliability mất nhiều thời gian ghép dữ liệu Work Order và historian trước khi xác minh một cảnh báo.

02

Khoanh use case và ranh giới

Nêu site, asset class, số thiết bị, nguồn dữ liệu, khoảng thời gian, nhóm người dùng và việc nằm ngoài phạm vi. Liệt kê integration ở mức đọc hay ghi. Một pilot chỉ đọc dữ liệu khác rất nhiều với pilot tạo Work Order trên hệ thống thật.

03

Gắn deliverable với trách nhiệm

Mỗi deliverable cần định dạng, người cung cấp input, người làm, người review và điều kiện bàn giao. Data mapping, solution design, test report, training material và runbook không nên nằm trong một dòng “documentation”.

04

Định nghĩa acceptance và go/no-go

Chọn baseline và chỉ số phù hợp use case: chất lượng dữ liệu, thời gian xử lý, false alarm burden, adoption hoặc độ chính xác của mapping. Ghi phương pháp đo, cỡ mẫu và giới hạn. Nếu chưa có baseline, giai đoạn đầu của pilot phải tạo nó.

05

Ghi assumptions và change control

Tách giả định về truy cập, bảo mật, licence, sự tham gia của SME và thời gian cung cấp dữ liệu. Quy định điều gì làm thay đổi timeline hoặc scope, cách phê duyệt change request và dữ liệu nào không được đưa vào demo công cộng.

06

Viết scope bằng ranh giới và khối lượng đo được

Một pilot EAM/APM nên xác định số site, asset class, số Asset, nguồn dữ liệu, thời gian lịch sử, số interface, vai trò người dùng và môi trường triển khai. Mỗi phạm vi cần chỉ rõ read-only hay write-back, batch hay near-real-time, dữ liệu production hay đã ẩn danh. Viết out-of-scope cụ thể: ví dụ chưa tối ưu toàn bộ PM, chưa thay CMMS hoặc chưa tự động phê duyệt Work Order. Câu “triển khai giải pháp APM” quá rộng để định giá và nghiệm thu.

Đưa một sample journey vào proposal: dữ liệu đi từ nguồn nào, được kiểm tra thế nào, ai review insight, hành động nào được tạo trong EAM và evidence nào chứng minh kết quả. Journey giúp các bên nhìn thấy dependency thật như tag mapping, quyền truy cập, kỹ sư xác nhận failure event và lịch shutdown. Đây cũng là cơ sở để cắt scope nếu dữ liệu không đủ.

07

Tách deliverable, acceptance và outcome

Deliverable là thứ bàn giao: data assessment, mapping, cấu hình, test script, training và runbook. Acceptance là điều kiện để nhận từng deliverable: đủ trường, chạy qua test case, có người review và lưu issue log. Outcome là thay đổi kỳ vọng ở nghiệp vụ, như giảm thời gian tổng hợp dữ liệu hoặc nâng tỷ lệ Work Order gắn đúng Asset. Không nên trộn ba lớp này rồi bắt nhà cung cấp cam kết ROI khi baseline và yếu tố vận hành chưa được xác nhận.

Lập acceptance matrix theo từng hạng mục với phương pháp đo, cỡ mẫu, nguồn bằng chứng, tolerance và người ký. Ví dụ, kiểm tra mapping trên mẫu Asset có cả trường hợp trùng mã và thay thế; đo thời gian phân tích trước và sau trên cùng loại case. Với AI, ghi thêm lỗi nghiêm trọng, tỷ lệ câu trả lời có bằng chứng và khối lượng review. Chỉ số phải phù hợp use case chứ không lấy một benchmark chung cho mọi pilot.

08

Quản lý assumptions và stage gate

Assumption register cần ghi người chịu trách nhiệm xác nhận, ngày cần có và tác động nếu không đúng: quyền truy cập historian, chất lượng tag, dữ liệu Work Order, SME availability, licence và security review. Gắn mỗi assumption trọng yếu với một decision gate. Sau discovery, hai bên có thể giữ scope, điều chỉnh approach, kéo dài data preparation hoặc dừng pilot nếu không còn khả năng kiểm chứng mục tiêu.

Proposal nên có RACI, timeline theo dependency và change-control route. Dự phòng thời gian cho UAT và xử lý lỗi dữ liệu; đừng trình bày toàn bộ thời gian như công việc cấu hình phần mềm. Cuối pilot, quyết định scale phải dựa trên evidence package: baseline, kết quả test, hạn chế, chi phí vận hành và backlog kỹ thuật. Một demo trơn tru là bằng chứng về khả năng trình diễn, chưa phải điều kiện đủ cho triển khai diện rộng.

09

Ví dụ minh họa: một pilot cảnh báo bảo trì

Proposal giả định pilot trên 20 Asset, một site, sáu tháng dữ liệu historian và Work Order, tích hợp chỉ đọc. Giai đoạn discovery tạo asset/tag mapping và xác minh failure event; nếu không đủ dữ liệu, hai bên quyết định chuyển mục tiêu từ dự báo hư hỏng sang phát hiện bất thường có người review. Deliverable gồm data assessment, kiến trúc, pipeline, case review, test report và runbook. Acceptance matrix ghi số Asset ánh xạ được, cách chọn mẫu, tỷ lệ alert có disposition, thời gian review và lỗi nghiêm trọng; các giá trị mục tiêu được chốt sau baseline. Out-of-scope nêu rõ không tự tạo Work Order, không mở rộng nhiều site và không cam kết giảm downtime trước khi có bằng chứng. Gate cuối xem kết quả kỹ thuật, effort vận hành và chi phí duy trì để quyết định scale.