Nhìn một Solution Builder build workflow, tạo form, cấu hình automation hay dashboard rất dễ khiến người mới sẽ nghĩ:
“Chắc phải giỏi công cụ trước.”
Thực tế, công cụ chỉ là một phần.
Một Solution Builder cần hiểu công việc đang diễn ra thế nào, tìm ra điểm đang gây tốn thời gian, biến nó thành một quy trình rõ ràng rồi mới dùng công cụ để xây giải pháp.
Nếu muốn bắt đầu, đây là 6 kỹ năng đáng học trước.
1. Biết đặt câu hỏi để hiểu đúng vấn đề
Một yêu cầu thường bắt đầu rất ngắn:
“Team cần một app để quản lý các yêu cầu hỗ trợ nội bộ.”
Nếu nhận yêu cầu rồi build ngay, rất dễ làm ra một hệ thống đúng theo câu chữ nhưng sai với cách team thực sự vận hành.
Solution Builder cần hỏi sâu hơn:
-
Ai là người gửi yêu cầu?
-
Những loại yêu cầu nào thường phát sinh?
-
Hiện tại yêu cầu được gửi qua đâu?
-
Ai tiếp nhận và phân công xử lý?
-
Bước nào đang mất nhiều thời gian?
-
Trường hợp nào thường bị bỏ sót hoặc xử lý chậm?
-
Kết quả cuối cùng team muốn cải thiện là gì?
Đây là kỹ năng khá gần với Business Analysis.
Điểm Solution Builder cần đi tiếp là hiểu đủ sâu để chuyển những gì mình tìm được thành một giải pháp có thể chạy.
2. Biết chia một quy trình lớn thành các bước nhỏ
Giả sử quy trình hiện tại là:
Gửi yêu cầu → Xử lý → Hoàn tất
Nghe khá đơn giản.
Nhưng khi đi sâu hơn, bạn có thể thấy:
Tạo yêu cầu → Phân loại → Phân công người xử lý → Tiếp nhận → Xử lý → Xác nhận kết quả → Đóng yêu cầu
Chia đúng bước giúp bạn nhìn rõ:
-
Ai đang giữ việc
-
Công việc đang ở trạng thái nào
-
Khi nào được chuyển bước
-
Điểm nào có thể tự động
-
Điểm nào cần xử lý ngoại lệ
Một Solution Builder giỏi thường có khả năng nhìn một quy trình khá rối và biến nó thành những phần đủ nhỏ để thiết kế.
3. Biết tư duy về dữ liệu
Workflow chạy bằng dữ liệu.
Bạn cần biết mỗi bước cần thông tin gì và dữ liệu đó được tạo ra ở đâu.
Ví dụ với yêu cầu hỗ trợ nội bộ:
-
Người gửi yêu cầu
-
Phòng ban
-
Loại yêu cầu
-
Nội dung cần hỗ trợ
-
Mức độ ưu tiên
-
Người phụ trách
-
Deadline dự kiến
-
Kết quả xử lý
-
Trạng thái
Sau đó tiếp tục hỏi:
Trường nào bắt buộc?
Ai được xem?
Ai được sửa?
Khi nào dữ liệu cần được khóa?
Thiết kế dữ liệu không tốt thường khiến workflow càng chạy càng rối.
4. Biết thiết kế rule và xử lý ngoại lệ
Quy trình thực tế hiếm khi chạy đúng một đường thẳng.
Ví dụ:
-
Yêu cầu khẩn cần được ưu tiên xử lý trước
-
Yêu cầu thuộc IT tự động chuyển cho team IT
-
Thiếu thông tin thì trả lại người gửi bổ sung
-
Người phụ trách nghỉ thì chuyển sang người thay thế
-
Quá thời hạn mà chưa xử lý thì gửi thông báo nhắc
-
Người gửi chưa xác nhận kết quả thì chưa đóng yêu cầu
Đây là lúc Solution Builder bắt đầu tư duy bằng:
If → Then → Else
Không cần biết code mới có thể làm được điều này.
Bạn cần tập nhìn công việc dưới dạng điều kiện và hành động.
5. Biết dùng công cụ no-code/low-code để build
Khi đã hiểu bài toán, đây mới là lúc công cụ phát huy giá trị.
Một Solution Builder thường cần làm quen với các thành phần như:
-
Form
-
Data
-
Workflow
-
Status
-
Permission
-
Notification
-
Reminder
-
Automation
-
Dashboard
Bạn chưa cần biết hết mọi nền tảng.
Điều quan trọng hơn là hiểu:
“Mình đang muốn giải quyết vấn đề gì bằng tính năng này?”
Ví dụ:
Team phải nhập lại dữ liệu nhiều lần?
→ Automation.
Sếp liên tục hỏi tiến độ?
→ Status + dashboard.
Yêu cầu thường bị quên?
→ Reminder.
Thông tin nằm rải rác trong chat và email?
→ Form + data tập trung.
6. Biết test, nhận feedback và cải tiến
Một workflow chạy được chưa chắc đã dùng tốt.
Sau khi build, Solution Builder cần đưa cho người dùng thử.
Và đây thường là lúc xuất hiện những câu:
“Ngoài đời bên em còn một bước nữa.”
“Đoạn này chỉ áp dụng cho một số loại yêu cầu.”
“Nếu người phụ trách nghỉ thì request này không biết chuyển cho ai.”
Đó chính là dữ liệu để cải tiến giải pháp.
Một vòng làm việc phổ biến sẽ là:
Build → Dùng thử → Nhận feedback → Chỉnh → Đo lại
Một Solution Builder hiếm khi làm đúng ngay từ phiên bản đầu tiên.
Vậy nên bắt đầu từ kỹ năng nào?
Nếu chưa từng build hệ thống, bạn có thể đi theo thứ tự:
Hiểu vấn đề → Vẽ workflow → Thiết kế dữ liệu → Viết rule → Build → Test
Đừng cố học hết công cụ trước.
Hãy chọn một vấn đề thật trong công việc của bạn.
Ví dụ:
-
Quy trình xin nghỉ phép
-
Xử lý yêu cầu hỗ trợ nội bộ
-
Theo dõi yêu cầu từ các phòng ban
-
Bàn giao công việc
-
Theo dõi deadline
Sau đó thử biến nó thành một workflow có thể chạy.
Đó là cách nhanh nhất để bắt đầu hình thành tư duy của một Solution Builder.