Nghe đến “xây giải pháp”, nhiều người thường hình dung một màn hình app hoặc một workflow chạy tự động.
Nhưng nếu giao một bài toán vận hành cho Solution Builder, sau dự án họ sẽ tạo ra và bàn giao những gì?
Hãy thử đi qua một tình huống cụ thể.
Giả sử một công ty đang xử lý đề xuất mua thiết bị qua chat, email và Excel. Nhân viên gửi yêu cầu ở một nơi, báo giá nằm ở nơi khác, quản lý duyệt qua tin nhắn, còn người phụ trách phải tự cập nhật trạng thái vào bảng tính.
Mỗi lần có người hỏi “Yêu cầu của mình tới đâu rồi?”, team lại phải lục lại nhiều nguồn để trả lời.
Với bài toán này, bộ đầu ra của Solution Builder có thể gồm sáu phần.
1. Problem statement: Phát biểu vấn đề
Đây là bản mô tả ngắn giúp mọi người thống nhất vấn đề đang cần giải quyết.
Các đề xuất mua hàng đang được tiếp nhận và theo dõi trên nhiều kênh. Thông tin thường thiếu, trạng thái chưa thống nhất và người gửi khó tự kiểm tra tiến độ. Team vận hành phải tổng hợp dữ liệu và nhắc việc thủ công.
Mục tiêu của pilot là đưa yêu cầu về một luồng tập trung, xác định rõ người đang xử lý và giảm số lần hỏi lại trạng thái.
Problem statement cũng cần chỉ rõ phạm vi. Ví dụ, pilot tập trung vào tiếp nhận và phê duyệt đề xuất. Quản lý nhà cung cấp và thanh toán sẽ được xử lý ở giai đoạn sau.
2. Workflow: Luồng xử lý công việc
Sau khi hiểu vấn đề, Solution Builder chuyển cách làm hiện tại thành một luồng rõ ràng:
Tạo yêu cầu → Kiểm tra thông tin → Quản lý phê duyệt → Tài chính kiểm tra → Mua hàng xử lý → Hoàn tất
Workflow cần thể hiện cả những tình huống phát sinh:
- Thiếu thông tin: trả lại cho người gửi và ghi rõ nội dung cần bổ sung.
- Bị từ chối: bắt buộc nhập lý do và thông báo cho người gửi.
- Vượt ngưỡng ngân sách: chuyển thêm một cấp phê duyệt.
- Quá hạn xử lý: nhắc đúng người đang giữ bước hiện tại.
- Thay đổi sau phê duyệt: lưu lại lịch sử chỉnh sửa.
Nhìn vào workflow, team có thể biết công việc đang ở đâu, ai phụ trách và điều kiện nào khiến yêu cầu chuyển bước.
3. Data structure: Cấu trúc dữ liệu
Solution Builder xác định những dữ liệu hệ thống cần lưu và mối quan hệ giữa chúng.
| Nhóm dữ liệu | Trường thông tin mẫu |
|---|---|
| Yêu cầu mua hàng | Mã yêu cầu, người gửi, phòng ban, sản phẩm, số lượng, ngân sách, lý do, trạng thái, hạn xử lý |
| Lịch sử phê duyệt | Người phê duyệt, kết quả, ghi chú, thời gian thao tác |
| Người dùng và quyền | Nhân viên, quản lý, tài chính, mua hàng |
| Tệp đính kèm | Báo giá, hình ảnh, tài liệu liên quan |
Cấu trúc dữ liệu tốt giúp tìm kiếm, báo cáo và tự động hóa dễ hơn. Nó cũng hạn chế tình trạng cùng một thông tin được nhập lại nhiều lần.
4. Prototype: Bản mẫu giải pháp
Từ workflow và dữ liệu, Solution Builder tạo prototype để người dùng trải nghiệm sớm.
Một prototype cho bài toán này có thể gồm:
- Form tạo đề xuất mua hàng.
- Trang “Yêu cầu của tôi” để theo dõi trạng thái.
- Danh sách việc đang chờ từng người phê duyệt.
- Trang chi tiết có lịch sử xử lý.
- Dashboard theo dõi số lượng, thời gian và yêu cầu quá hạn.
Người dùng có thể bấm thử, đi qua từng bước và chỉ ra điểm chưa phù hợp trước khi giải pháp được cấu hình sâu hơn.
5. Test case: Kịch bản kiểm thử
Mỗi quy tắc quan trọng cần có tình huống kiểm thử và kết quả mong đợi.
| Tình huống | Kết quả mong đợi |
|---|---|
| Gửi yêu cầu thiếu báo giá bắt buộc | Hệ thống yêu cầu bổ sung trước khi gửi |
| Quản lý từ chối yêu cầu | Phải nhập lý do, trạng thái được cập nhật và người gửi nhận thông báo |
| Yêu cầu vượt ngưỡng ngân sách | Tự động chuyển thêm cấp duyệt |
| Người không có quyền mở tác vụ duyệt | Không thể thực hiện thao tác |
| Một bước bị quá hạn | Hệ thống nhắc người đang phụ trách |
Test case giúp team kiểm tra cả luồng chính, ngoại lệ, phân quyền và thông báo trước khi đưa giải pháp vào sử dụng.
6. Kết quả đo sau pilot
Sau khi pilot chạy, Solution Builder so sánh dữ liệu trước và sau triển khai.
Ví dụ minh họa cách báo cáo bằng số liệu giả định:
| Chỉ số | Trước pilot | Sau pilot |
|---|---|---|
| Thời gian phê duyệt trung bình | 2,6 ngày | 1,4 ngày |
| Yêu cầu phải bổ sung thông tin | 31% | 9% |
| Số lần nhắc thủ công mỗi tuần | 22 | 7 |
| Số câu hỏi về trạng thái mỗi tuần | 16 | 3 |
Các con số trên dùng để minh họa cấu trúc báo cáo. Mỗi dự án thực tế cần thu thập baseline và kết quả pilot riêng.
Vậy Solution Builder thực sự tạo ra điều gì?
Qua sáu đầu ra trên, team nhận được:
- Một vấn đề được mô tả rõ.
- Một workflow có bước, người phụ trách và điều kiện chuyển trạng thái.
- Một cấu trúc dữ liệu đủ để vận hành và báo cáo.
- Một prototype để kiểm chứng với người dùng.
- Một bộ test case cho luồng chính và ngoại lệ.
- Một bảng kết quả cho thấy giải pháp tạo ra thay đổi gì.
Đó là cách giá trị của Solution Builder được thể hiện qua sản phẩm công việc cụ thể.