Business Process Reengineering(BPR)

Cải tiến từng bước là chỉnh cái đang có cho chạy mượt hơn. BPR đặt một câu hỏi khó chịu hơn nhiều: nếu hôm nay mới lập công ty, quy trình này có tồn tại không. Nếu câu trả lời là không, thì bỏ hẳn chứ đừng ngồi tối ưu nó.

BPR là thiết kế lại quy trình từ gốc để đạt bước nhảy về chi phí, tốc độ hoặc chất lượng, không phải cải thiện vài phần trăm.

Gốc gác và mức độ đáng tin

Khái niệm do Michael Hammer và James Champy đưa ra đầu thập niên 1990, gắn với cuốn Reengineering the Corporation. Giai đoạn đó rất nhiều doanh nghiệp làm theo và một tỷ lệ lớn thất bại, phần vì BPR bị dùng như cái tên đẹp cho việc cắt giảm nhân sự, phần vì làm quá tay: đập hết rồi dựng lại trong khi công ty vẫn phải bán hàng mỗi ngày.

Ở VN hiện nay hiếm dự án nào làm BPR nguyên bản, cứ nói trước cho đỡ ảo tưởng. Phần lớn là dự án ERP hoặc chuyển đổi số làm phiên bản nhẹ, có nắn lại quy trình theo chuẩn phần mềm, và vẫn được gọi là BPR trong tài liệu bán hàng.

Khác gì cải tiến liên tục

Vai trò của BA ở đây

BA hiếm khi là người quyết định có tái thiết kế hay không. Việc của BA là cung cấp bằng chứng để người ra quyết định không quyết định bằng cảm tính: as-is có số liệu, chi phí và thời gian từng bước, điểm tắc, và một hai phương án to-be kèm điều kiện triển khai.

Có một ranh giới cần giữ. Khi thay đổi chạm tới cơ cấu phòng ban và công việc của con người cụ thể, đó là quyết định của lãnh đạo. BA đưa dữ liệu và phương án, không đứng ra hứa với nhân viên rằng "không ai mất việc đâu". Câu hứa đó không thuộc thẩm quyền của bạn, và nếu sai thì mọi buổi khảo sát sau này sẽ chẳng ai nói thật nữa.

Ví dụ thực tế

Cuối ngày, quản lý mỗi cửa hàng đi một vòng đếm tồn, chụp màn hình rồi gửi vào nhóm chat của vùng. Quản lý vùng gom lại thành file Excel, chuyển phòng mua hàng, mua hàng mới đặt nhà cung cấp.

Chuỗi bán lẻ đó có 87 cửa hàng. Một đề nghị bổ sung đi hết bốn tầng mất hai tới ba ngày, sai số cao vì đếm tay.

Hướng cải tiến từng bước sẽ là: làm một cái form thay cho nhóm chat. Nhanh, rẻ, và giữ nguyên bốn tầng.

Hướng tái thiết kế thì bỏ hẳn bước cửa hàng đề nghị: hệ thống tự sinh đề nghị bổ sung dựa trên tồn kho và tốc độ bán bảy ngày, cửa hàng chỉ xác nhận hoặc điều chỉnh, quản lý vùng chuyển từ việc tổng hợp sang xử lý ngoại lệ. Đổi luôn nội dung công việc của mười hai nhân sự vùng.

Phần khó nhất không phải phần mềm. Là bốn tháng chạy song song hai cách làm, và là việc thuyết phục đội vùng rằng vai trò mới của họ không phải bị hạ cấp.

Khi nào đừng đề xuất

• Chưa có as-is kèm số liệu. Không có gốc thì mọi lời hứa cải thiện đều là đoán.
• Lãnh đạo chưa đứng tên. BPR do phòng IT khởi xướng gần như luôn chết giữa đường.
• Công ty đang chạy doanh số gấp, hoặc vừa qua một đợt biến động nhân sự. Không ai còn đầu óc cho chuyện đổi cách làm việc.
• Hoặc đơn giản là vấn đề thật ra chỉ nằm ở một cái nút bấm đặt sai chỗ. Chuyện đó sửa trong một sprint, đừng gọi tên nó to lên.

Trước khi dùng từ BPR trong tài liệu, thử hỏi người bảo trợ dự án: nếu phương án tốt nhất là xoá bỏ một phòng ban, anh chị có ký không. Câu trả lời cho biết đây là dự án tái thiết kế thật hay chỉ là cải tiến mang tên khác.