Quy trình trên tài liệu thường rất gọn: tiếp nhận yêu cầu, kiểm tra, phê duyệt rồi thực hiện.
Khi bước vào công việc thực tế, mọi thứ phức tạp hơn nhiều. Yêu cầu có thể thiếu thông tin. Người phê duyệt đang nghỉ. Một trường hợp cần xử lý gấp. Hai bộ phận hiểu khác nhau về trách nhiệm. Trạng thái mới nhất nằm trong một đoạn chat mà chỉ vài người biết.
Người làm Operations (vận hành) thường đứng ngay giữa những tình huống đó. Sau một thời gian, họ hiểu khá rõ:
- Công việc thường bắt đầu từ đâu.
- Thông tin nào hay bị thiếu.
- Bước nào thường mất nhiều thời gian nhất.
- Ai có quyền quyết định ở từng giai đoạn.
- Trường hợp nào cần trả lại, bỏ qua hoặc chuyển hướng.
- Người quản lý cần nhìn thấy số liệu gì.
Đây là những đầu vào quan trọng khi xây một giải pháp số.
Một người có thể học cách tạo form, thiết lập workflow hoặc cấu hình automation trong thời gian tương đối ngắn. Việc hiểu vì sao một bước tồn tại, dữ liệu nào thật sự cần thiết và ngoại lệ nào sẽ xuất hiện đòi hỏi trải nghiệm sâu hơn với công việc.
Người làm Operations thường đã tích lũy trải nghiệm đó qua hàng trăm lần xử lý yêu cầu, sửa lỗi, hỏi tiến độ và giải quyết tình huống phát sinh.
Vấn đề xuất hiện khi toàn bộ hiểu biết vẫn nằm trong đầu một vài người. Team tiếp tục phụ thuộc vào tin nhắn, trí nhớ và những lần nhắc thủ công. Khi người phụ trách nghỉ, công việc dễ chậm lại vì những người còn lại chưa biết bước tiếp theo là gì.
Từ một quy trình mua hàng đến giải pháp có thể chạy
Giả sử một nhân sự Operations đang phụ trách quy trình đề xuất mua hàng nội bộ.
Các phòng ban gửi nhu cầu qua nhiều kênh khác nhau. Có người nhắn trực tiếp, có người điền vào file, có người gửi email. Nhân sự Operations phải kiểm tra lại tên hàng, số lượng, thời hạn cần, ngân sách và người phê duyệt.
Sau khi đề xuất được duyệt, thông tin tiếp tục được nhập sang một file theo dõi khác để bộ phận thu mua thực hiện. Muốn biết tiến độ, người đề xuất thường phải nhắn hỏi.
Nhìn từ bề mặt, vấn đề nằm ở việc mọi người hay gửi thiếu thông tin hoặc quên cập nhật.
Quan sát kỹ hơn sẽ thấy một số nguyên nhân vận hành:
- Chưa có một điểm tiếp nhận yêu cầu thống nhất.
- Trường thông tin bắt buộc chưa được xác định rõ.
- Trạng thái của đề xuất chưa được chuẩn hóa.
- Điều kiện chuyển sang bước phê duyệt hoặc thu mua vẫn phụ thuộc vào người nhớ việc.
- Dữ liệu phải nhập lại khi chuyển từ đề xuất sang thực thi.
- Ngoại lệ như yêu cầu gấp, bị từ chối hoặc cần bổ sung chưa có cách xử lý chung.
Người làm Operations thường nhận ra những điểm này khá nhanh vì họ đã trực tiếp xử lý chúng.
Một Solution Builder sẽ đưa hiểu biết đó thành cấu trúc cụ thể trước khi chọn công cụ:
- Form tiếp nhận: Quy định rõ thông tin bắt buộc như mặt hàng, số lượng, mục đích, ngân sách dự kiến và thời hạn cần.
- Dữ liệu: Mỗi đề xuất có một mã riêng và được lưu tại một nơi để các bước sau sử dụng lại.
- Trạng thái: Có thể gồm Bản nháp, Chờ kiểm tra, Cần bổ sung, Chờ phê duyệt, Đang thu mua, Hoàn thành và Đã hủy.
- Vai trò và phân quyền: Người đề xuất được xem và bổ sung yêu cầu của mình. Quản lý có quyền phê duyệt. Bộ phận thu mua cập nhật tiến độ thực hiện.
- Quy tắc xử lý: Đề xuất vượt một mức ngân sách nhất định có thể cần thêm cấp phê duyệt. Hồ sơ thiếu thông tin sẽ được trả lại đúng người.
- Tự động hóa: Khi đề xuất được duyệt, hệ thống tự tạo việc cho bộ phận thu mua và gửi thông báo cho người phụ trách.
- Báo cáo: Người quản lý có thể xem số lượng đề xuất đang chờ, thời gian xử lý và những bước thường bị chậm.
Giá trị của giải pháp thể hiện qua những thay đổi rất cụ thể: dữ liệu bớt phải nhập lại, người dùng biết yêu cầu đang ở đâu, người phụ trách nhìn thấy việc cần xử lý và quản lý có dữ liệu để cải tiến quy trình.
Khoảng trống người làm Operations cần lấp
Kinh nghiệm vận hành tạo ra một điểm xuất phát tốt. Tuy vậy, sự quen thuộc với quy trình hiện tại cũng có thể khiến người xây bê nguyên những bước cũ lên một công cụ mới.
Ví dụ, team đang chuyển thông tin qua ba file vì lịch sử để lại. Nếu giữ nguyên cách làm đó trong ứng dụng, quy trình vẫn phức tạp dù giao diện đã thay đổi.
Người làm Operations cần phát triển thêm ba năng lực:
1. Mô hình hóa quy trình
Kinh nghiệm cá nhân cần được diễn đạt thành những thành phần mà người khác có thể hiểu và thực hiện: đầu vào, đầu ra, vai trò, dữ liệu, trạng thái, điều kiện chuyển bước và ngoại lệ.
2. Kiểm tra lý do của từng bước
Với mỗi thao tác, hãy hỏi: Bước này tạo ra giá trị gì? Quy định nào yêu cầu bước này? Điều gì xảy ra nếu rút gọn hoặc tự động hóa nó?
Các câu hỏi này giúp phân biệt yêu cầu thực sự với thói quen hình thành qua thời gian.
3. Kiểm chứng bằng tình huống thật
Một workflow nhìn hợp lý trên sơ đồ vẫn có thể gặp lỗi khi đưa vào sử dụng. Hãy thử ít nhất ba tình huống: luồng thông thường, trường hợp thiếu thông tin và một ngoại lệ thường gặp.
Cách kiểm chứng này giúp phát hiện sớm những điểm chưa rõ về dữ liệu, quyền xử lý và điều kiện chuyển trạng thái.
Bản đồ 5 lớp để bắt đầu xây giải pháp
Bạn có thể chọn một quy trình đang lặp lại mỗi tuần và mô tả nó qua năm lớp sau:
Lớp 1: Công việc
- Sự kiện nào khiến quy trình bắt đầu?
- Kết quả cuối cùng cần tạo ra là gì?
- Tiêu chí nào cho biết công việc đã hoàn thành?
Lớp 2: Vai trò
- Ai tạo yêu cầu?
- Ai chịu trách nhiệm ở từng bước?
- Ai có quyền xem, sửa, duyệt hoặc từ chối?
Lớp 3: Dữ liệu
- Người thực hiện cần thông tin gì để ra quyết định?
- Trường nào bắt buộc?
- Dữ liệu nào đang được nhập lại?
- Thông tin nào cần lưu để tra cứu hoặc báo cáo?
Lớp 4: Trạng thái
- Một công việc đi qua những trạng thái nào?
- Điều kiện để chuyển sang trạng thái tiếp theo là gì?
- Ai chịu trách nhiệm khi công việc nằm ở mỗi trạng thái?
Lớp 5: Ngoại lệ
- Điều gì xảy ra khi thông tin bị thiếu?
- Xử lý thế nào khi yêu cầu bị từ chối hoặc quá hạn?
- Ai thay thế khi người phụ trách vắng mặt?
- Dữ liệu nào giúp tìm ra bước đang gây chậm?
Sau khi hoàn thành bản đồ, hãy dựng một phiên bản nhỏ cho một nhóm người dùng hoặc một loại yêu cầu. Quan sát cách họ sử dụng, ghi lại nơi họ dừng lại rồi tiếp tục điều chỉnh.
Người làm Operations đã có sẵn chất liệu từ công việc hằng ngày. Khi những hiểu biết đó được chuyển thành dữ liệu, trạng thái và quy tắc rõ ràng, họ bắt đầu tiến gần hơn đến cách một Solution Builder xây và cải tiến giải pháp.
Trong công việc hiện tại, quy trình nào bạn hiểu rõ đến mức có thể chỉ ra điểm kẹt, người giữ bước tiếp theo và ngoại lệ thường gặp?