Biến các yêu cầu trên Slack thành một sản phẩm nội bộ bằng cách nhận diện các yêu cầu lặp lại, tạo một hàng đợi duy nhất và chỉ thêm tự động hóa khi quy trình đã ổn.
Một vài yêu cầu trên Slack không có vẻ to tát. Rồi cùng những câu hỏi đó bắt đầu xuất hiện mỗi ngày: "Bạn có thể cấp quyền không?" "Bạn sửa báo cáo này được không?" "Bạn tạo workspace mới cho tôi được không?" Những việc trông như giúp nhanh trở thành một hệ thống không chính thức, không có cấu trúc.
Vấn đề đầu tiên là phân tán. Yêu cầu đến qua tin nhắn trực tiếp, kênh nhóm, nhóm riêng tư và luồng phụ. Có cái có bối cảnh, có cái không. Mọi người nhớ lờ mờ là đã thấy một yêu cầu nhưng không nhớ nó ở đâu hoặc có ai nhận chưa. Công việc bị thất lạc vì nó không vào một hàng đợi rõ ràng.
Vấn đề thứ hai là thiếu chi tiết. Mọi người hỏi vội, thường trước khi biết thông tin nào quan trọng. Vì vậy người làm việc phải truy hỏi các cơ bản như ai cần quyền, hệ thống nào liên quan, hoặc khi nào cần thay đổi. Một nhiệm vụ năm phút dễ biến thành trao đổi dài.
Sự khẩn cấp làm mọi thứ tệ hơn. Tin nhắn ồn ào nhất nhảy lên hàng đầu, dù không phải quan trọng nhất. Các yêu cầu quan trọng nhưng lặng lẽ nằm ở nền. Theo thời gian, nhóm ngừng làm theo thứ tự ưu tiên và bắt đầu phản ứng với người đăng bài gần nhất gây áp lực nhiều nhất.
Rồi là vấn đề trạng thái. Không có hàng đợi chung, các câu hỏi đơn giản trở nên khó trả lời:
Sự thiếu minh bạch đó tạo ra công việc lặp lại, chậm trễ và bực bội cả hai phía. Người gửi yêu cầu cảm thấy bị phớt lờ. Nhóm xử lý cảm thấy bị gián đoạn cả ngày. Vấn đề trông như chat thực ra là vấn đề quy trình.
Bắt đầu với những yêu cầu xuất hiện đi xuất hiện lại. Đừng đoán. Xem lại các tin nhắn thực tế trong 2–4 tuần gần nhất và nhìn vào những gì mọi người thực sự yêu cầu.
Một khoảng thời gian xem ngắn thường là đủ. Nó cho thấy những yêu cầu xảy ra hàng tuần mà không kéo vào những ngoại lệ cũ không còn quan trọng.
Khi rà tin nhắn, nhóm các yêu cầu theo loại. Bạn không cần phân loại hoàn hảo. Bạn chỉ cần một cái nhìn thực tế về những gì lặp lại: yêu cầu quyền truy cập, kéo báo cáo, kiểm tra phê duyệt, cập nhật dữ liệu nhỏ, thiết lập workspace mới và các nhiệm vụ tương tự.
Một bảng đơn giản là đủ. Với mỗi yêu cầu, ghi lại:
Điểm cuối cùng quan trọng hơn nhiều đội nghĩ. Nếu cùng vài người liên tục thực hiện cùng loại yêu cầu, bạn có thể đã có phác thảo của một sản phẩm nội bộ. Bạn sẽ thấy kiến thức nằm ở đâu, chỗ nào xảy ra chậm trễ, và quy trình phụ thuộc quá nhiều vào một người.
Mẫu xuất hiện nhanh. Bán hàng có thể liên tục hỏi tài chính về cùng một ngoại lệ giá. Nhân viên mới có thể liên tục nhắn IT về cùng một quyền truy cập ứng dụng. Quản lý có thể yêu cầu ops báo cáo trạng thái tuần theo những từ hơi khác nhau.
Bỏ qua các trường hợp hiếm trước mắt. Nếu một yêu cầu chỉ xuất hiện một lần trong tháng và cần xử lý đặc biệt, bỏ ra. Mục tiêu là tìm công việc phổ biến, nhàm chán và dễ mô tả. Đó là điểm khởi đầu tốt nhất vì các yêu cầu lặp lại dễ chuẩn hóa hơn, dễ đo lường hơn và có khả năng hưởng lợi từ một quy trình tiếp nhận rõ ràng.
Bắt đầu nhỏ hơn cảm giác ấn tượng. Trường hợp dùng đầu tiên tốt nhất không phải là vấn đề ồn ào nhất trong công ty. Nó là thứ xảy ra thường xuyên, theo vài bước rõ ràng và kết thúc bằng một kết quả mà mọi người có thể đồng ý.
Một lựa chọn mạnh thường có đường phê duyệt đơn giản. Một người yêu cầu, một người kiểm tra và một người hoàn tất. Nếu năm đội cần góp ý, bạn chưa xây được luồng yêu cầu sạch sẽ. Bạn đang vẽ một quy trình lộn xộn.
Cố gắng mô tả kết quả trong một câu. Nếu câu đó mơ hồ, yêu cầu có lẽ quá rộng.
"Phê duyệt và tạo hộp thư chia sẻ mới cho một đội" là điểm khởi đầu tốt. "Giúp chúng tôi cải thiện giao tiếp với khách hàng" thì không. Cái đầu có điểm kết thúc rõ. Cái sau có thể là mười thứ khác nhau.
Một loại yêu cầu thường đủ nhỏ nếu:
Khi bạn chọn trường hợp, hãy chọn một chỉ số để theo dõi. Giữ đơn giản. Thời gian chờ là lựa chọn mạnh vì ai cũng hiểu. Nếu vấn đề lớn hơn là sai sót, theo dõi làm lại thay vì thời gian, ví dụ bao nhiêu lần nhóm phải quay lại vì thiếu chi tiết.
Trường hợp dùng đầu tiên không cần chứng minh mọi thứ. Nó chỉ cần cho thấy quy trình tiếp nhận có cấu trúc tốt hơn tin nhắn rải rác trên Slack. Nếu phiên bản nhỏ hiệu quả, bạn có dữ liệu thực, bớt ý kiến và con đường dễ dàng hơn để tự động hóa sau này.
Sửa đầu tiên đơn giản: cho mọi người một cửa vào. Họ không nên phải đoán gửi DM, đăng kênh đội hay thả thẻ ai đó trông rảnh. Một biểu mẫu, một kênh tiếp nhận hoặc một hộp yêu cầu là đủ. Công cụ ít quan trọng hơn tính nhất quán.
Hàng đợi đó nên hỏi cùng các chi tiết cơ bản mỗi lần. Giữ ngắn nhưng hữu ích: người yêu cầu cần gì, tại sao cần, khi nào cần và ai phê duyệt nếu cần. Khi thiếu những chi tiết đó, trao đổi lại bắt đầu.
Nhãn trạng thái cũng hữu ích, nhưng chỉ khi rõ ràng. Hầu hết đội không cần hệ thống phức tạp. Họ chỉ cần biết điều gì đang xảy ra:
Dùng từ đơn giản để ai cũng nhìn hàng đợi là hiểu. Nếu một yêu cầu nằm quá lâu, trạng thái nên cho biết lý do.
Cũng quan trọng là chỉ định một người hoặc một đội để phân loại hàng đợi. Không có nghĩa là họ làm hết mọi việc. Nghĩa là họ chịu trách nhiệm phản hồi đầu tiên, kiểm tra yêu cầu đã hoàn chỉnh chưa và chuyển đến nơi phù hợp. Không có chủ rõ ràng, một hàng đợi chung sẽ nhanh thành đống mà không ai cảm thấy chịu trách nhiệm.
Một bài kiểm tra tốt: nếu ngày mai có nhân viên mới, họ có thể gửi yêu cầu mà không hỏi nên gửi đâu hay cần gì không? Nếu câu trả lời là không, sửa trước khi tự động hóa. Một quy trình tiếp nhận lộn xộn chỉ trở thành quy trình lộn xộn nhanh hơn khi bạn tự động hóa nó.
Trước khi tự động hóa, chạy quy trình thủ công trong một hoặc hai tuần. Điều đó cho thấy yêu cầu thực trông thế nào, chỗ nào vướng và phần nào thực sự đáng để biến thành hệ thống.
Bắt đầu với một định dạng tiếp nhận. Có thể là một biểu mẫu ngắn, mẫu cố định ghim, hoặc một tin nhắn chuẩn để mọi người sao chép và điền. Quan trọng là tính nhất quán: tên người yêu cầu, họ cần gì, lý do, hạn chót và phê duyệt nếu cần.
Rồi kiểm tra yêu cầu vào các thời điểm cố định thay vì phản ứng suốt ngày. Ví dụ, rà hàng đợi lúc 10:00 và 15:00. Điều đó bảo vệ sự tập trung và dạy nhóm rằng yêu cầu đi theo quy trình chứ không phải ping ngẫu nhiên.
Dùng cùng một đường dẫn mọi lần:
Khi làm, ghi lại các bước bạn thực sự làm. Giữ đơn giản. Nếu bạn luôn kiểm tra phê duyệt quản lý, sao chép dữ liệu từ công cụ này sang công cụ khác, hoặc hỏi cùng một câu bổ sung, hãy ghi lại. Những hành động lặp lại đó là nguyên liệu thô để cải thiện quy trình sau này.
Cũng theo dõi điểm ma sát bằng ngôn ngữ đơn giản. Ghi lại thiếu chi tiết, chậm phê duyệt, sở hữu không rõ ràng và câu hỏi lặp lại. Sau một đợt nhỏ, các mẫu hiện ra nhanh.
Dấu hiệu tốt để sẵn sàng tự động hóa là khi các bước ngừng thay đổi. Nếu hầu hết yêu cầu đi theo cùng một đường, bạn có đủ ổn định để xây. Cho đến khi đó, làm thủ công không vô ích. Đó là cách bạn học hệ thống thực sự cần gì.
Nếu cùng một yêu cầu liên tục xuất hiện, quyết định phía sau nó không nên nằm trong đầu một người. Ghi lại các kiểm tra bạn làm mỗi lần, theo thứ tự bạn dùng. Điều đó biến thói quen thành quy trình để người khác làm theo.
Bắt đầu với các câu hỏi thay đổi kết quả. Yêu cầu đã hoàn chỉnh chưa? Người đó có phê duyệt không? Hạn chót liên quan đến onboarding, lương hay công việc khách hàng không? Nếu các kiểm tra đó xảy ra hầu hết các yêu cầu, chúng thuộc tập quy tắc.
Một cách tổ chức quy tắc đơn giản là tách:
Điều này tránh việc quy trình bị tắc vì thiếu chi tiết nhỏ. Nếu quản lý quên thêm một chi tiết hữu ích nhưng đã có nhân viên, đội và mức quyền, yêu cầu có thể vẫn sẵn sàng tiến hành.
Tiếp theo, viết các trả lời chuẩn cho các kết quả thường gặp. Thường là: chấp thuận, thiếu thông tin, gửi sai kênh, trùng lặp hoặc cần xem xét. Giữ mỗi trả lời ngắn và cụ thể để người gửi biết bước tiếp theo.
Ví dụ, thay vì viết trả lời mới mỗi lần, dùng các tin nhắn như "Đã chấp thuận. Quyền truy cập sẽ được thiết lập hôm nay" hoặc "Cần thêm một chi tiết trước khi bắt đầu: phê duyệt của quản lý."
Không phải bước nào cũng nên thành quy tắc. Giữ phán đoán con người ở nơi cần: ngoại lệ, quyền truy cập nhạy cảm, hạn chót bất thường hoặc yêu cầu phá vỡ chính sách. Các quy tắc tốt không loại con người khỏi quy trình. Chúng loại bỏ trao đổi thừa.
Quyền truy cập cho nhân viên mới thường là sản phẩm nội bộ đầu tiên tốt. Hầu hết công ty đều gặp, các bước lặp lại, và chi phí thiếu sót rõ ràng ngay ngày đầu.
Hình dung phiên bản cũ. Một quản lý nhắn Slack: "Sam bắt đầu thứ Hai. Có thể set up cho họ không?" Rồi ba đội khác hỏi những câu bổ sung, ai đó quên một hệ thống, và Sam dành sáng đầu tiên chờ quyền truy cập.
Thiết lập tốt hơn bắt đầu với một hàng đợi duy nhất. Quản lý nộp yêu cầu cùng chỗ mọi lần, và form chỉ hỏi các chi tiết cần: vai trò, ngày bắt đầu và hệ thống cần truy cập.
Thay đổi nhỏ đó mang hai lợi ích. Nó loại bỏ trao đổi vòng vo làm chậm mọi người, và tạo hồ sơ rõ ràng về yêu cầu và thời điểm yêu cầu.
Với các vai trò chuẩn, đường đi nên nhàm chán theo cách tốt. Nếu là sales, designer hay support, cùng một gói phê duyệt và truy cập có thể theo cùng các bước mỗi lần. Ví dụ:
Lúc này quy trình bắt đầu giống một sản phẩm hơn là một ân huệ. Mọi người biết nộp yêu cầu ở đâu, cần gì và thời gian trung bình.
Không phải mọi yêu cầu nên tự động. Nhà thầu tạm thời, vai trò liên phòng ban và quyền truy cập hệ thống nhạy cảm vẫn cần người làm chủ. Nếu hầu hết yêu cầu theo một đường và chỉ ngoại lệ cần xử lý đặc biệt, bạn đã sẵn sàng để cải thiện hơn nữa.
Tự động hóa hữu ích nhất khi công việc đã theo mẫu rõ ràng. Nếu đội vẫn thay đổi bước, tranh luận về chủ sở hữu, hoặc xử lý mỗi yêu cầu khác nhau, tự động hóa chỉ khoá sự rối rắm.
Quy tắc đơn giản: chạy thủ công cho đến khi mọi người có thể giải thích cùng một cách mỗi lần. Khi luồng cảm thấy nhàm chán, dự đoán được và dễ dạy, thường là sẵn sàng để tự động hóa.
Điều đầu tiên nên tự động là các tác vụ ít rủi ro tốn thời gian nhưng không cần phán đoán. Trong quy trình yêu cầu, thường là nhắc nhở, xác nhận và cập nhật trạng thái.
Khi ai đó gửi yêu cầu, hệ thống có thể gửi biên nhận, ghi thời gian xử lý dự kiến và đăng cập nhật khi yêu cầu chuyển từ mới sang đang xử lý rồi hoàn tất. Điều đó tiết kiệm tin nhắn theo dõi mà không thay đổi cách quyết định được đưa ra.
Tự động hóa ban đầu tốt thường bao gồm:
Định tuyến nên đến sau. Nếu yêu cầu vẫn bị trả giữa người nọ người kia, hoặc đội thay đổi ai phê duyệt gì, định tuyến tự động chỉ tạo thêm việc sửa. Đợi tới khi đường đi thủ công ổn định và hầu hết yêu cầu theo cùng một trao tay.
Giữ một tùy chọn ghi đè thủ công từ ngày đầu. Một số yêu cầu luôn lằng nhằng, khẩn cấp hoặc bất thường. Mọi người cần cách đơn giản để ra ngoài quy tắc, sửa vấn đề và tiếp tục. Nếu hệ thống không xử lý ngoại lệ, người dùng sẽ mất niềm tin.
Trước khi mở rộng tự động hóa, rà các lỗi. Xem các yêu cầu bị định tuyến sai, chậm trễ hoặc đóng với câu trả lời không đúng. Những sai sót đó cho thấy chỗ quy trình vẫn chưa rõ. Tự động hóa nên hỗ trợ một workflow đã hoạt động, không sáng tạo ra một cái mới.
Hầu hết đội bị kẹt không phải vì yêu cầu quá phức tạp mà vì cố gắng sửa hết mọi thứ cùng lúc.
Một lỗi phổ biến là mở rộng quá nhanh. Các đội gộp yêu cầu quyền truy cập, yêu cầu thiết kế, phê duyệt mua sắm và báo lỗi vào một quy trình. Nghe có vẻ hiệu quả, nhưng mỗi loại có quy tắc, chủ sở hữu và thời gian khác nhau.
Lỗi khác là chấp nhận yêu cầu từ khắp nơi. Nếu mọi người có thể hỏi trong DM, kênh ngẫu nhiên và nhóm, sẽ luôn có người phải đi tìm chi tiết sau đó.
Tự động hóa quá sớm là bẫy khác. Nếu phê duyệt vẫn phụ thuộc phán đoán từng trường hợp, tự động hóa chỉ đẩy nhanh quyết định xấu. Và khi trạng thái không hiển thị, người ta hỏi lại vì họ không biết yêu cầu đã được nhìn thấy, phê duyệt hay đang bị chặn.
Một ví dụ đơn giản cho thấy sự sụp đổ. Giả sử một nhân viên mới cần truy cập app, laptop và mời vào kênh Slack. Nếu mỗi phần đến từ một tin nhắn khác nhau, nhóm mất thời gian ghép yêu cầu hơn là thực hiện công việc. Nếu quy tắc phê duyệt mơ hồ, bước tự động có thể gửi nhầm cho người hoặc phê duyệt thứ lẽ ra cần xem xét.
Cách sửa thường nhàm chán, và đó là điều tốt. Bắt đầu với một loại yêu cầu. Dùng một đường tiếp nhận. Hỏi cùng các chi tiết quan trọng mỗi lần. Giữ quy tắc phê duyệt đủ đơn giản để người mới có thể làm theo mà không đoán.
Cũng quan trọng là hiện tiến độ rõ ràng. Ngay cả trạng thái cơ bản như đã nhận, đang xem, hoặc xong cũng giảm các tin nhắn theo dõi và xây dựng niềm tin.
Nếu một quy trình vẫn cần nhiều ngoại lệ, nó chưa sẵn sàng cho tự động hóa mạnh. Dọn dẹp quy tắc trước. Rồi tự động những phần đã hoạt động giống nhau mỗi lần.
Trước khi thêm nhiều đội, nhiều loại yêu cầu hay tự động hóa sâu, dừng lại và kiểm tra cơ bản. Một quy trình hoạt động với người tạo ra nó vẫn có thể làm người khác bối rối.
Kiểm vài điều đơn giản:
Điểm đầu tiên quan trọng hơn nhiều đội nghĩ. Nếu nhân viên mới hoặc quản lý bận không thể theo quy trình một mình, hệ thống chưa sẵn sàng để mở rộng. Workflow nên rõ ràng ngay cả với người lần đầu thấy.
Giữ form ngắn. Mọi người có nhiều khả năng dùng quy trình khi biểu mẫu chỉ hỏi các chi tiết hữu ích thay vì năm câu hỏi thừa.
Sở hữu là nơi nhiều hệ thống sụp. "Đang xem" vô nghĩa nếu không có một người hay đội chịu trách nhiệm đẩy nó tiếp. Không ai sở hữu trạng thái thì yêu cầu sẽ nằm yên.
Ngoại lệ cũng cần quan tâm. Luôn có trường hợp lạ, yêu cầu khẩn hoặc người thiếu ngữ cảnh. Cho những trường hợp đó con đường dự phòng để chúng không khởi động lại cuộc trò chuyện trong Slack.
Và bảo vệ những bước vẫn cần quyết định con người. Ép tự động quá sớm thường tạo ra làm lại chứ không phải tốc độ.
Khi workflow hoạt động thủ công, đừng nhảy thẳng vào một hệ thống lớn. Giữ một hàng đợi và một yêu cầu lặp, làm cho đường đó mượt trước. Đó là cách an toàn nhất để biến công việc Slack lặp lại thành thứ đáng tin cậy.
Dùng chính các yêu cầu bạn đã nhận làm hướng dẫn. Nếu mọi người thường bỏ sót cùng một chi tiết, thêm một trường cho nó. Nếu người kiểm duyệt thường chọn cùng một phương án, biến phương án đó thành quy tắc đơn giản. Lưu lượng thực cho bạn biết gì nên vào quy trình và gì chỉ là nhiễu.
Phiên bản tiếp theo tốt thường chỉ thêm vài thứ:
Thêm tự động từng phần nhỏ. Nếu yêu cầu quyền truy cập luôn cần phê duyệt quản lý trước, tự động bước đó. Nếu một số yêu cầu vẫn cần phán đoán, giữ thủ công chúng. Mục tiêu không phải tự động mọi thứ mà là loại bỏ các bước lặp lại và giữ ngoại lệ rõ ràng.
Nếu workflow tiếp tục phát triển, nó có thể xứng đáng một ứng dụng nội bộ. Công cụ như Koder.ai có thể giúp ở giai đoạn này. Các đội có thể dùng chat để tạo một ứng dụng web, server hoặc di động cho quy trình, rồi tinh chỉnh khi mẫu yêu cầu mới xuất hiện thay vì chất thêm công việc lên Slack.
Những sản phẩm nội bộ tốt nhất thường bắt đầu nhỏ: một hàng đợi, một loại yêu cầu, sử dụng thực tế rồi mở rộng cẩn trọng. Có thể cảm thấy chậm trong một tuần, nhưng nhanh hơn nhiều trong cả năm sau đó.
Vì chat che khuất công việc. Yêu cầu xuất hiện trong tin nhắn trực tiếp, kênh và luồng phụ, nên quyền sở hữu, trạng thái và độ ưu tiên không rõ ràng. Một hàng đợi duy nhất giúp theo dõi, hoàn thành và đo lường yêu cầu dễ dàng hơn.
Chọn thứ gì thường xuyên, đơn giản và lặp lại. Trường hợp dùng đầu tiên tốt có điểm bắt đầu rõ ràng, kết thúc rõ ràng và đường phê duyệt nhỏ, ví dụ quyền truy cập nhân viên mới hoặc tạo hộp thư chia sẻ.
Xem lại các tin nhắn thực tế trong 2–4 tuần gần nhất và gom nhóm theo loại. Tập trung vào các yêu cầu phổ biến, dễ mô tả và bỏ qua các trường hợp hiếm gặp.
Ngắn nhưng đầy đủ. Hỏi người dùng cần gì, tại sao cần, khi nào cần và ai phê duyệt nếu cần. Mục tiêu là thu đủ thông tin để tránh trao đổi thêm.
Không cần công cụ đặc biệt. Bạn có thể bắt đầu với một form, một kênh tiếp nhận, hoặc một hộp thư chung. Quan trọng là mọi người đều dùng cùng một cửa vào và cùng định dạng yêu cầu.
Chạy thủ công trong một hoặc hai tuần trước. Điều đó cung cấp ví dụ thực tế, cho thấy điểm nghẽn và giúp bạn thấy bước nào ổn định để tự động hóa.
Bắt đầu với các phần ít rủi ro và lặp lại: xác nhận đã nhận yêu cầu, nhắc nhở, và cập nhật trạng thái rõ ràng. Để phê duyệt và định tuyến cho phần sau khi quy trình ổn định.
Mọi thứ vẫn cần phán đoán nên để thủ công. Thường là quyền truy cập nhạy cảm, thời hạn bất thường, ngoại lệ chính sách và các yêu cầu không theo đường chuẩn.
Khi quy trình trở nên nhàm chán theo cách tốt: người mới có thể nộp yêu cầu mà không cần trợ giúp, mọi trạng thái có chủ sở hữu rõ ràng, và hầu hết yêu cầu đi theo cùng một đường dẫn.
Khi khối lượng yêu cầu tăng và quy tắc ổn định, một ứng dụng nội bộ chuyên dụng có thể tiết kiệm thời gian. Koder.ai có thể giúp xây ứng dụng web, server hoặc di động từ chat và tinh chỉnh khi cần.
