Nếu bạn hỏi một Solution Builder làm gì cả ngày, câu trả lời thường không nằm ở một công cụ cụ thể.
Có ngày họ ngồi nói chuyện với người dùng để hiểu vì sao một quy trình đang bị kẹt.
Có ngày họ dành phần lớn thời gian vẽ lại workflow, chỉnh form, đặt rule, test notification và xử lý những trường hợp mà lúc đầu chưa ai nghĩ tới.
Và cũng có ngày họ chỉ làm một việc: nhìn một quy trình đang rối và tìm cách khiến nó chạy gọn hơn.
Vậy một ngày điển hình của Solution Builder có thể diễn ra như thế nào?
9:00 | Bắt đầu từ một vấn đề vận hành
Một yêu cầu có thể đến rất đơn giản:
“Team mình cần một hệ thống để quản lý đề xuất mua hàng.”
Solution Builder thường chưa mở công cụ lên build ngay.
Việc đầu tiên là làm rõ:
- Ai đang gửi đề xuất?
- Hiện tại gửi bằng cách nào?
- Ai cần kiểm tra?
- Trường hợp nào cần duyệt thêm?
- Sau khi duyệt thì ai đi mua?
- Nếu bị từ chối thì chuyện gì xảy ra?
- Team đang mất thời gian ở đoạn nào?
Một câu “cần hệ thống quản lý mua hàng” có thể ẩn phía sau 5 đến 10 bước vận hành khác nhau.
10:00 | Chuyển cách team đang làm việc thành workflow
Sau khi hiểu quy trình hiện tại, Solution Builder bắt đầu chia nó thành các bước rõ ràng.
Ví dụ:
Tạo đề xuất → Kiểm tra thông tin → Phê duyệt → Tìm nhà cung cấp → Mua hàng → Xác nhận hoàn tất
Ở đây, câu hỏi không chỉ là “có những bước nào”.
Solution Builder còn phải xác định:
- Ai chịu trách nhiệm ở từng bước?
- Khi nào công việc được chuyển sang bước tiếp theo?
- Dữ liệu nào cần được giữ lại?
- Trạng thái nào cần theo dõi?
- Điều gì xảy ra nếu quy trình đi lệch khỏi luồng bình thường?
Đây là lúc một quy trình vốn nằm trong đầu mọi người bắt đầu trở thành một hệ thống có cấu trúc.
11:00 | Thiết kế dữ liệu, form và quyền truy cập
Workflow đã rõ, tiếp theo là câu chuyện dữ liệu.
Một đề xuất mua hàng cần những thông tin gì?
Có thể gồm:
- Người đề xuất
- Bộ phận
- Sản phẩm cần mua
- Số lượng
- Lý do
- Ngân sách dự kiến
- Người phê duyệt
- Nhà cung cấp
- Giá thực tế
- Trạng thái xử lý
Solution Builder cần quyết định trường nào bắt buộc, trường nào có thể chỉnh sửa, ai được xem và ai được thay đổi thông tin.
Nếu thiết kế dữ liệu không tốt, workflow phía sau rất dễ trở nên rối.
13:30 | Build phiên bản đầu tiên
Đến lúc này mới bắt đầu build.
Tùy nền tảng, Solution Builder có thể cấu hình:
- Form nhập liệu
- Bảng dữ liệu
- Workflow
- Trạng thái
- Phân quyền
- Notification
- Reminder
- Automation
- Dashboard hoặc báo cáo
Ví dụ:
Khi đề xuất được duyệt, hệ thống tự tạo một công việc cho người phụ trách mua hàng.
Người phụ trách nhận thông báo ngay.
Thông tin từ đề xuất được chuyển sang bước thực thi, không cần nhập lại.
Một thao tác nhỏ như vậy có thể loại bỏ khá nhiều việc copy dữ liệu và nhắc nhau thủ công.
15:00 | Test những tình huống không đẹp như trên sơ đồ
Workflow trên giấy thường rất gọn.
Thực tế thì không.
Người duyệt nghỉ phép thì sao?
Người đề xuất nhập thiếu thông tin thì sao?
Giá mua thực tế vượt ngân sách thì sao?
Đã duyệt rồi nhưng muốn hủy thì sao?
Một bước bị treo ba ngày thì ai biết?
Solution Builder cần test cả luồng chính lẫn những tình huống ngoại lệ như vậy.
Đây thường là phần khiến một giải pháp “trông có vẻ chạy được” trở thành một giải pháp thực sự dùng được.
16:00 | Đưa cho người dùng thử
Solution Builder cho người thực sự làm công việc đó sử dụng phiên bản đầu tiên.
Sau vài phút, rất có thể sẽ nghe:
“Chỗ này ngoài đời bên em không làm như vậy.”
Hoặc:
“Bước này đáng ra kế toán phải xem trước.”
Hoặc:
“Nếu đơn trên 50 triệu thì phải có thêm một người duyệt.”
Những phản hồi này rất quan trọng.
Solution Builder cập nhật lại workflow, dữ liệu hoặc rule dựa trên cách công việc thực tế đang diễn ra.
17:00 | Nhìn lại quy trình bằng dữ liệu
Khi hệ thống bắt đầu chạy, công việc chưa kết thúc.
Solution Builder tiếp tục xem:
- Bước nào đang mất nhiều thời gian?
- Có task nào thường xuyên bị treo?
- Bao nhiêu đề xuất bị từ chối?
- Bao nhiêu lần phải làm lại?
- Automation nào có thể bổ sung?
- Người dùng đang gặp khó ở đâu?
Từ đó, phiên bản tiếp theo của giải pháp tiếp tục được cải thiện.
Vậy Solution Builder thực sự làm gì?
Một ngày của Solution Builder thường xoay quanh 5 hoạt động:
Hiểu vấn đề → Thiết kế quy trình → Build giải pháp → Test với người dùng → Cải tiến
Bạn sẽ phải nói chuyện với con người, làm việc với quy trình, dữ liệu và công cụ.
Có lúc giống Business Analyst.
Có lúc giống người thiết kế hệ thống.
Có lúc lại đang trực tiếp build workflow bằng no-code, low-code và automation.
Điểm chung là bạn luôn bắt đầu từ một câu hỏi:
“Công việc này có thể được thiết kế tốt hơn không?”
Nếu bạn từng tự làm một file theo dõi tiến độ, tạo form để gom yêu cầu, đặt rule nhắc deadline hoặc tìm cách giảm những việc team phải làm thủ công, bạn đã khá gần với cách một Solution Builder làm việc rồi đó!