Chuẩn hóa quy trình trước khi số hóa: cần rõ đến mức nào?

I. Tại sao số hóa làm điểm rối lộ rõ hơn?

Trong cách làm giấy/Excel, người có kinh nghiệm thường “lấp khoảng trống” bằng trao đổi miệng. Phần mềm buộc nhà máy trả lời:

Ai có quyền tạo?
Ai nhận việc?
Trạng thái nào đi tiếp được?
Trường nào bắt buộc?
Khi nào được đóng?
Ai được sửa sau khi đóng?
Ngoại lệ đi đường nào?

Đây là điều tốt nếu dự án dùng các câu hỏi này để cải tiến. Nhưng nếu chỉ cấu hình theo thói quen cũ, hệ thống có thể làm quy trình cứng và rối hơn.

II. Tám yếu tố tối thiểu phải rõ

1. Trigger - điều gì bắt đầu quy trình?

Ví dụ: máy dừng, đến hạn PM, nhận lệnh, phát hiện lỗi, tồn kho xuống ngưỡng. Trigger phải đủ rõ để tránh tạo trùng hoặc bỏ sót.

2. Đầu ra mong đợi

Quy trình kết thúc với kết quả gì: máy được bàn giao, lệnh hoàn thành, lỗi được disposition, CAPA được xác nhận hiệu lực hay vật tư đã cấp?

3. Các bước chính

Chỉ cần 5-10 bước cấp cao trước, không vẽ mọi thao tác nhỏ. Mỗi bước nên có động từ và output.

4. Vai trò và quyền

Ai tạo, phân loại, duyệt, thực hiện, xác nhận, xem và sửa? Nên dùng vai trò thay vì tên cá nhân.

5. Dữ liệu tối thiểu

Mỗi bước tạo hoặc cập nhật dữ liệu gì? Trường nào bắt buộc để bước sau ra quyết định?

6. Quy tắc quyết định

Ví dụ mức ưu tiên nào cần duyệt, lỗi nào phải dừng máy, work order nào cần nghiệm thu, thay đổi nào cần escalation.

7. Ngoại lệ

Thiếu phụ tùng, mất mạng, người duyệt vắng, dữ liệu sai, công việc không thể hoàn thành hoặc sản xuất không cho dừng được xử lý thế nào?

8. KPI và điều kiện hoàn thành

Khi nào quy trình được coi là hoàn thành và đo bằng gì? Đóng trạng thái không đồng nghĩa kết quả đạt.

III. Mẫu process canvas một trang

Hạng mục	Câu hỏi
Mục tiêu	Vấn đề và KPI nào cần cải thiện?
Phạm vi	Bắt đầu/kết thúc ở đâu, loại trừ gì?
Trigger	Sự kiện nào khởi tạo?
Vai trò	Ai tạo, làm, duyệt, xác nhận?
Các bước	5-10 bước chính và trạng thái
Dữ liệu	Trường bắt buộc, danh mục, nguồn
Quy tắc	Ưu tiên, ngưỡng, SLA, phê duyệt
Ngoại lệ	Đường xử lý khác chuẩn
Đầu ra	Bằng chứng và tiêu chí hoàn thành
KPI	Thời gian, chất lượng, backlog, adoption

Một trang đủ để các bên thống nhất trước khi đi vào cấu hình chi tiết.

IV. Ai quyết định quy trình chuẩn?

Bộ phận nghiệp vụ phải làm chủ. IT và nhà cung cấp hỗ trợ thiết kế, khả năng hệ thống, tích hợp và kiểm soát.

Ví dụ:

Quy trình bảo trì: bảo trì làm owner, sản xuất tham gia vì ảnh hưởng dừng máy.
Dừng máy: sản xuất làm owner, bảo trì/chất lượng/kế hoạch tham gia nguyên nhân.
CAPA: chất lượng làm owner, process owner chịu trách nhiệm action.
Cấp phụ tùng: kho/ERP owner và bảo trì phối hợp.

Ban lãnh đạo cần bảo trợ và quyết định khi xung đột liên phòng ban không giải quyết được. Nhà cung cấp không nên tự quyết cách nhà máy vận hành chỉ vì phần mềm có workflow mặc định.

V. Ví dụ quy trình work order phiên bản 1.0

Bước	Vai trò	Dữ liệu chính	Quy tắc
Tạo yêu cầu	Vận hành/người yêu cầu	Máy, triệu chứng, ảnh, thời gian	Critical event có escalation
Phân loại	Planner/trưởng bảo trì	Priority, loại việc, kỹ năng	Priority theo impact/urgency
Duyệt/lập lịch	Owner phù hợp	Thời gian dừng, nguồn lực	Công việc lớn/chi phí cần duyệt
Giao việc	Planner	Người, due date, job plan	Không giao nếu thiếu điều kiện an toàn
Thực hiện	Kỹ thuật viên	Time, action, part, finding	Ghi trạng thái chờ và lý do
Xác nhận	Sản xuất/giám sát	Test result, bàn giao	Không đạt thì mở lại
Đóng	Trưởng/CMMS rule	Cause, completion data	Trường bắt buộc và audit trail

Phiên bản đầu có thể đơn giản hơn. Sau pilot, nhà máy sẽ biết bước duyệt nào thừa, trường nào thiếu và priority có hợp lý không.

VI. Ví dụ quy trình ghi nhận dừng máy

Hệ thống hoặc người vận hành tạo event start/stop.
Người vận hành chọn nhóm nguyên nhân sơ bộ.
Trưởng ca xác nhận hoặc chuyển đúng bộ phận.
Sự cố thiết bị liên kết work order.
Bảo trì ghi nguyên nhân xác nhận và hành động.
Sản xuất xác nhận thời điểm chạy lại.
Event được khóa theo cutoff, sửa sau đó có lịch sử.
Dashboard cập nhật Pareto và action.

Điểm cần thống nhất là ai có quyền đổi nguyên nhân, dừng ngắn xử lý thế nào và event qua ca thuộc trách nhiệm ai.

VII. Nên sửa quy trình trước hay vừa làm vừa sửa?

Câu trả lời là cả hai theo vòng lặp có kiểm soát.

Trước pilot

Chốt process canvas.
Giải quyết mâu thuẫn lớn.
Định nghĩa trạng thái, vai trò và dữ liệu tối thiểu.
Chọn KPI và phạm vi.

Trong pilot

Ghi issue theo ngày.
Phân biệt lỗi cấu hình, thiếu đào tạo và bất hợp lý quy trình.
Không thay đổi liên tục từng yêu cầu nhỏ; gom vào cadence review.

Sau 4-8 tuần

Review dữ liệu sử dụng, thời gian và điểm tắc.
Loại trường/bước không tạo giá trị.
Bổ sung ngoại lệ cần thiết.
Ban hành version 1.1 và thông báo thay đổi.

Quy trình số cũng cần version control.

VIII. Thiết kế trạng thái và workflow vừa đủ

Quá ít trạng thái làm mất kiểm soát; quá nhiều trạng thái làm người dùng bối rối.

Một nguyên tắc:

Mỗi trạng thái phải có ý nghĩa nghiệp vụ và owner.
Chuyển trạng thái phải phản ánh một sự kiện hoặc quyết định.
Trạng thái chờ cần lý do và SLA.
Không tạo trạng thái chỉ để “theo dõi cho đẹp”.
Người dùng chỉ thấy hành động phù hợp vai trò.
Workflow ngoại lệ phải rõ nhưng không làm luồng chuẩn nặng nề.

IX. Dữ liệu tối thiểu, không phải dữ liệu tối đa

Với mỗi trường, hỏi:

Ai dùng?
Quyết định nào thay đổi?
Có thể lấy tự động không?
Có cần tại bước này không?
Nếu thiếu, hậu quả gì?

Nếu không có câu trả lời, trường đó có thể bỏ, chuyển sang tùy chọn hoặc tính tự động. Form càng dài không đồng nghĩa dữ liệu càng tốt.

X. Xử lý ngoại lệ trước khi go-live

Tối thiểu mô phỏng:

Người duyệt vắng.
Thiếu vật tư.
Mất internet/thiết bị nhập.
Nhập sai mã máy hoặc lệnh.
Công việc qua ca.
Work order không sửa được lỗi.
Lệnh sản xuất thay đổi giữa ca.
Sự cố an toàn/chất lượng cần dừng ngay.

Nếu không thiết kế ngoại lệ, người dùng sẽ quay lại điện thoại, giấy và Excel khi sự việc thật xảy ra.

XI. KPI cho quy trình số hóa

Lead time từ trigger đến hoàn thành.
Thời gian chờ theo trạng thái.
Tỷ lệ hồ sơ đủ dữ liệu.
Tỷ lệ mở lại/rework.
SLA compliance.
Backlog và tuổi backlog.
Số bước/biểu mẫu cũ được loại bỏ.
Adoption theo vai trò.
KPI vận hành mà quy trình phục vụ.

Không nên chỉ đo số giao dịch trên hệ thống.

XII. Những sai lầm thường gặp

Copy nguyên quy trình giấy vào phần mềm.
Cố chuẩn hóa toàn bộ trước khi pilot.
Để nhà cung cấp quyết định workflow.
Có quá nhiều cấp duyệt để “an toàn”.
Không định nghĩa hoàn thành.
Trạng thái chờ không có lý do.
Form quá dài và nhiều nhập tự do.
Không quản lý version quy trình.
Thay đổi cấu hình liên tục mà không đào tạo lại.
Giữ quy trình cũ song song không có ngày kết thúc.

XIII. Câu hỏi thường gặp

Có cần viết SOP đầy đủ trước khi cấu hình không?

Cần đủ khung, vai trò và quy tắc để cấu hình. SOP chi tiết có thể hoàn thiện qua pilot, nhưng những nội dung an toàn/chất lượng bắt buộc phải rõ trước.

Quy trình hiện tại mỗi ca làm khác nhau thì bắt đầu thế nào?

Tổ chức workshop với tình huống thật, chọn một cách chuẩn phiên bản 1.0 và ghi ngoại lệ. Sau pilot, điều chỉnh dựa trên bằng chứng.

Phần mềm chuẩn có nên buộc nhà máy theo quy trình mặc định?

Quy trình chuẩn của phần mềm là tham khảo tốt, nhưng cần đối chiếu với mục tiêu, rủi ro và hiện trường. Tránh tùy biến vô hạn cũng như áp dụng máy móc.