Nhà phân phối dược phẩm doanh thu khoảng 5 tỷ USD mỗi năm mua SAP R/3 năm 1993 và tự động hoá kho, kỳ vọng giảm chi phí. Hệ thống mới chỉ xử lý khoảng 10.000 đơn mỗi đêm, so với 420.000 đơn của máy chủ cũ. Công ty phá sản năm 1996. Bài học về yêu cầu phi chức năng và Validate Scope.
Thay ERP lõi và tự động hoá kho cùng lúc, với nhiều nhà cung cấp và một bên tích hợp, khiến phạm vi tích hợp rất lớn. Mỗi giao diện giữa SAP, hệ thống kho và quy trình hiện hữu là một nguồn rủi ro phạm vi.
Năng lực xử lý thực tế chỉ lộ ra khi hệ thống đã chạy. Nếu có kiểm thử tải với khối lượng thật và tiêu chí nghiệm thu từ sớm, khoảng cách 10.000 so với 420.000 đơn đã được phát hiện trước mọi cam kết kinh doanh.
Lấy số liệu của hệ thống cũ (số đơn mỗi đêm, giờ cao điểm, số kho) làm đường sàn bắt buộc; ghi vào tài liệu yêu cầu với tiêu chí nghiệm thu đo được.
Chạy thử nghiệm chứng minh khái niệm (proof of concept) với khối lượng tương đương thực tế, trước khi ký hợp đồng kinh doanh phụ thuộc vào hệ thống.
Quy định ngưỡng rõ ràng để quyết định có chuyển đổi hay không:
Kiểm thử tải đạt hoặc vượt khối lượng cao điểm của hệ thống cũ, có biên an toàn.
Đạt ở một số kho; chỉ chuyển các kho đó, giữ hệ thống cũ cho phần còn lại.
Năng lực thấp hơn nhiều so với yêu cầu tối thiểu; giữ hệ thống cũ và khắc phục.
Triển khai từng kho, từng nhóm chức năng; không thay ERP và tự động hoá kho đồng thời trên toàn mạng lưới.
PM cần cảnh báo lãnh đạo khi một cam kết với khách hàng dựa vào giả định dự án; ghi vào sổ giả định (assumption log) và nhật ký rủi ro, kèm điều kiện kích hoạt kế hoạch dự phòng.
Phạm vi không chỉ là "hệ thống làm được gì" mà còn là "làm được bao nhiêu, nhanh đến đâu". Yêu cầu phi chức năng bị bỏ sót có thể biến một dự án đúng chức năng thành thảm hoạ của cả doanh nghiệp.
Bạn chọn phương án nào?