Số hóa hay thiết kế lại quy trình? Một khung quyết định đơn giản

Tại sao quyết định này khó hơn vẻ bề ngoài

Khi một đội phát hiện một quy trình thủ công, phản ứng dễ thấy là đưa nó vào phần mềm để chạy nhanh hơn. Nghe có vẻ hợp lý, nhưng điều đó có thể cố định những quyết định không tốt. Phần mềm lặp lại đúng những gì bạn bảo nó lặp. Nếu quy trình có các bước phê duyệt thừa, nhập dữ liệu trùng lặp, hoặc các thủ thuật cũ, công cụ có thể biến những vấn đề đó thành chuyện chính thức.

Vì vậy câu hỏi thực sự không chỉ là có nên tự động hóa hay không. Mà là có nên số hóa quy trình nguyên trạng, hay nên thiết kế lại trước.

Các đội thường bỏ qua bước dừng lại đó vì quy trình hiện tại đã tồn tại nhiều năm, nên cảm thấy đã được thử nghiệm. Thực tế, thời gian che giấu cả những kiểm soát hữu ích lẫn thói quen lỗi thời. Một quy trình tồn tại lâu có thể chứa một bước bảo vệ chất lượng và một bước chỉ tồn tại vì hệ thống cũ khó dùng.

Công việc thủ công khó xử đúng vì lý do đó. Một bước có thể chứa cả giá trị lẫn lãng phí. Một quản lý xem xét mọi hoàn tiền khách hàng có thể phát hiện trường hợp bất thường — điều đó có ích. Nhưng nếu cùng quản lý đó còn sao chép ghi chú vào một hệ thống thứ hai thì phần đó không thêm gì cả. Nếu bạn biến toàn bộ bước thành phần mềm nguyên trạng, bạn sẽ giữ cả phần tốt lẫn phần xấu cùng nhau.

Thời điểm cũng quan trọng. Trước khi công cụ được xây, thay đổi quy trình chủ yếu là một cuộc trò chuyện. Sau khi công cụ có mặt, thay đổi ảnh hưởng đến biểu mẫu, quy tắc, quyền hạn, báo cáo, đào tạo và thói quen hàng ngày. Một sửa nhỏ có thể biến thành thử nghiệm, họp hành và làm lại tốn kém.

Nhanh hơn không phải lúc nào cũng tốt hơn. Tốc độ chỉ hữu ích khi quy trình đã đưa ra các quyết định đúng. Nếu một quy tắc phê duyệt tồi được tự động hoá, bạn chỉ có được các phê duyệt tồi sớm hơn. Đội có thể cảm thấy hiệu quả hơn trong khi lỗi, chậm trễ và khách hàng bực bội vẫn tăng ngầm.

Điều này càng quan trọng hơn khi phần mềm có thể được xây nhanh. Các công cụ nhanh hữu ích, nhưng chúng làm tăng chi phí của việc bỏ qua bước suy nghĩ. Một bản dựng nhanh quanh một luồng lộn xộn vẫn là một luồng lộn xộn, chỉ có giao diện đẹp hơn.

Giữ lại, đơn giản hóa, hay loại bỏ

Không phải mọi bước thủ công đều là lãng phí. Một số bước bảo vệ chất lượng, phát hiện rủi ro, hoặc xây dựng niềm tin. Trước khi bạn số hóa hay thiết kế lại, hãy tách công việc cần phán đoán con người ra khỏi công việc chỉ tồn tại vì hệ thống yếu kém.

Một quy tắc đơn giản hữu ích: giữ các bước nơi con người thêm ý nghĩa, không chỉ chuyển động. Nếu một quản lý xem một hoàn tiền bất thường thì việc giữ lại có thể đúng vì bối cảnh quan trọng. Nếu ba người sao chép cùng thông tin hoàn tiền từ email sang bảng tính rồi sang form, đó chỉ là di chuyển thông tin.

Hầu hết các bước rơi vào một trong bốn loại:

• Giữ lại nếu ai đó đang đưa ra một quyết định thực sự.
• Đơn giản hóa nếu mục tiêu quan trọng nhưng kiểm tra diễn ra quá thường xuyên.
• Loại bỏ nếu nó chỉ sao chép, chuyển tiếp, hoặc định dạng lại dữ liệu.
• Cần đặt câu hỏi nghiêm túc nếu không ai nhớ lý do nó tồn tại.

Nhiều đội mang theo các tác vụ phụ vì công cụ hiện tại kém. Người ta mò tìm phê duyệt trong chat, cập nhật hai bảng theo dõi, hoặc lưu file với tên đặc biệt để người khác tìm sau. Đó không phải nhu cầu kinh doanh. Đó là các thủ thuật.

Nếu bạn nhét mọi thủ thuật vào hệ thống mới, bạn sẽ khóa nỗi đau cũ vào một màn hình sạch hơn. Đó là lý do một số dự án phần mềm cảm thấy chậm và khó chịu ngay từ ngày đầu.

Thói quen cũ là một cái bẫy khác. Một số quy tắc được tạo ra cho biểu mẫu giấy, lo ngại kiểm toán xưa, hoặc một quản lý đã nghỉ việc từ lâu. Việc ký duyệt hàng tuần, báo cáo trùng lặp, hoặc in bắt buộc có thể từng có ý nghĩa. Nếu rủi ro đã hết thì quy tắc cũng nên biến mất.

Hãy hình dung đội bán hàng nhập thông tin lead vào CRM, sau đó gửi cùng thông tin đó cho tài chính qua email, rồi chờ phê duyệt thủ công trước khi gửi báo giá. Phê duyệt có thể vẫn cần khi giá bất thường. Việc nhập trùng và gửi email thì nên biến mất.

Nếu bạn định xây luồng trong một công cụ như Koder.ai, bước phân loại này sẽ tiết kiệm thời gian. Phần mềm nên hỗ trợ phần có giá trị của quy trình, không phải bảo tồn phần mà mọi người chỉ chịu đựng.

Một khung đơn giản để quyết định

Đừng bắt đầu với sơ đồ luồng hiện tại. Hãy bắt đầu với mục đích của từng bước. Một quy trình có thể có nhiều bước nhưng vẫn làm rất ít. Một bước khác có thể cảm thấy chậm, nhưng đó có thể là thứ ngăn ngừa lỗi tốn kém.

Một cách thực tế để đánh giá từng bước là hỏi bốn câu:

• Bước này đang bảo vệ kết quả gì?
• Ai sử dụng kết quả, và họ dùng nó để làm gì?
• Bao lâu thì nó thay đổi một quyết định thực sự?
• Nó giảm rủi ro hay chủ yếu tạo ra thời gian chờ?

Câu trả lời thường hướng tới một trong bốn lựa chọn. Giữ lại nếu nó rõ ràng bảo vệ chất lượng, tiền bạc, tuân thủ, hoặc niềm tin khách hàng. Đơn giản hóa nếu mục tiêu quan trọng nhưng phương pháp hiện tại vụng về. Loại bỏ nếu không ai thật sự dùng đầu ra hoặc nếu nó hiếm khi thay đổi điều gì tiếp theo. Thiết kế lại nếu mục đích còn hợp lý nhưng toàn bộ chuỗi được dựng quanh các giới hạn cũ.

Một dấu hiệu cảnh báo mạnh là chậm trễ mà không có bảo vệ. Nếu một bước thêm một ngày chờ nhưng không bắt lỗi, ngăn gian lận, hay cải thiện kết quả, nó yếu. Nó có thể cảm thấy quan trọng vì nhiều người chạm vào nó, chứ không phải vì nó thay đổi gì.

Lấy ví dụ hoàn tiền khách hàng. Nếu mọi hoàn tiền nhỏ đều cần phê duyệt quản lý và quản lý chấp nhận 99/100 không thay đổi gì, bước đó không cải thiện quyết định. Nó chủ yếu thêm thời gian chờ. Quy tắc tốt hơn có thể là phê duyệt tự động dưới một mức nhất định, chỉ xem xét các trường hợp bất thường.

Đây là cốt lõi của số hóa quy trình. Đừng hỏi, "Phần mềm có sao chép được cái này không?" Hãy hỏi, "Cái này có nên tồn tại khi phần mềm làm cho thay đổi dễ hơn không?" Sự chuyển tư duy này giúp tránh khoá thói quen cũ vào hệ thống mới.

Cách xem xét quy trình bước một

Bắt đầu với quy trình thực tế, không phải phiên bản chính sách. Quan sát công việc diễn ra hôm nay, ai chạm vào nó, họ dùng công cụ gì, và nơi nào mọi người dừng lại, chờ, hoặc sửa lỗi. Một bảng trắng, tài liệu chia sẻ, hoặc bảng đơn giản là đủ.

Giữ bản đồ rõ ràng. Với mỗi bước, ghi bốn điều: điều gì khởi tạo nó, ai làm nó, đầu vào cần gì, và đầu ra tạo ra là gì. Nếu hai người mô tả cùng một bước khác nhau, đó thường là dấu hiệu quy trình đã chệch.

Sau đó hỏi một câu cho mỗi bước: tại sao bước này tồn tại?

Hầu hết câu trả lời rơi vào ba nhóm:

1. Giá trị - nó giúp tạo ra kết quả khách hàng hoặc đội thực sự cần.
2. Kiểm soát - nó giảm rủi ro, kiểm tra chất lượng, hoặc lưu trữ hồ sơ.
3. Lãng phí - nó thêm chậm trễ, trùng lặp, hoặc làm việc bận rộn mà không có lợi rõ ràng.

Nhiều bước thủ công chỉ cảm thấy quan trọng vì mọi người đã quen. Sao chép dữ liệu từ bảng tính này sang bảng tính khác có thể trông như công việc cẩn thận, nhưng thường chỉ là thủ thuật cho hệ thống thiếu thốn.

Khi mỗi bước đã được gắn nhãn, thử xem chuyện gì xảy ra nếu bạn gộp, rút ngắn, hoặc loại bỏ nó. Nếu không có gì hỏng, bước đó có lẽ không cần. Nếu một bước kiểm soát quan trọng, xem liệu nó có thể xảy ra sau, chỉ một lần thay vì hai lần, hoặc chỉ kích hoạt cho ngoại lệ.

Cũng hữu ích khi quyết định bước nào nên giữ thủ công trước mắt. Không phải mọi phán đoán đều nên trở thành phần mềm ngay ngày đầu. Nếu một bước phụ thuộc vào bối cảnh, niềm tin, hoặc các trường hợp hiếm, giữ thủ công cho đến khi quy trình mới ổn định.

Trước khi bất kỳ xây dựng nào bắt đầu, viết ra luồng mới bằng ngôn ngữ đơn giản. Bao gồm đường chính, ngoại lệ, ai phê duyệt gì, và tiêu chí hoàn thành. Phiên bản một trang thường là đủ. Nó trở thành nguồn sự thật cho mọi người.

Bản phác thảo ngôn ngữ đơn giản đó cũng hoạt động tốt khi bạn dùng công cụ tạo trong chat. Nó cho công cụ thứ gì rõ ràng để xây, thay vì buộc nó mô phỏng một quy trình lộn xộn.

Một ví dụ thực tế: công việc phê duyệt trước phần mềm

Một đội bán hàng xử lý phê duyệt khách hàng qua email. Nhân viên lập báo giá, gửi cho quản lý, chờ trả lời, rồi chuyển cùng báo giá cho tài chính. Đôi khi báo giá còn tới giám đốc bán hàng trước khi tới khách hàng.

Trên giấy tờ, điều đó có vẻ cẩn thận. Thực tế, nó tạo ra chậm trễ, hộp thư lộn xộn, và việc kiểm tra lặp lại.

Phần hữu ích là tài chính. Phần xem xét đó bắt lỗi giá thực sự, đặc biệt khi giảm giá được nhập tay hoặc nhân viên dùng bảng giá cũ. Tài chính cũng phát hiện khi điều khoản thanh toán không phù hợp chính sách. Bước đó bảo vệ biên lợi nhuận và tránh sửa sai xấu hổ sau này.

Vấn đề là các vòng phê duyệt khác. Quản lý và giám đốc bán hàng thường kiểm tra cùng các trường mà tài chính đã kiểm: mức giảm giá, tổng giá trị, và thông tin khách hàng cơ bản. Họ hiếm khi thêm quyết định khác. Phần lớn thời gian, họ chỉ trả lời "approved" sau khi đọc cùng những con số.

Những gì đã thay đổi

Thay vì sao chép chuỗi email cũ vào phần mềm, đội vẽ lại luồng xung quanh một kiểm soát thật sự:

• Báo giá chuẩn trong khung giá đi ra mà không cần phê duyệt thêm.
• Báo giá có giảm giá hay điều khoản lạ sẽ đi tới tài chính.
• Tài chính phê duyệt, sửa, hoặc gửi lại một lần.

Điều đó giữ được kiểm tra quan trọng và loại bỏ các vòng lặp chỉ làm chậm.

Phần mềm nên phản ánh luồng sạch hơn đó, không phải mớ hỗn độn cũ. Nếu đội xây trong một công cụ nội bộ, form báo giá có thể kiểm tra giá tự động, gắn cờ ngoại lệ, và chỉ định duyệt cho các trường hợp rủi ro. Nhân viên thấy trạng thái ở một chỗ thay vì tìm trong chuỗi email.

Đó là bài kiểm tra chính: một bước có thay đổi kết quả không, hay nó chỉ lặp lại kiểm tra người khác đã làm?

Trong ví dụ này, một kiểm duyệt thủ công giữ lại vì nó ngăn lỗi tốn kém. Các phê duyệt còn lại biến mất vì chúng không thêm phán đoán mới. Làm tốt công việc quy trình là giữ kiểm soát, loại bỏ tiếng ồn, rồi xây phần mềm theo con đường đơn giản hơn.

Sai lầm phổ biến gây làm lại tốn kém

Những sai lầm tốn kém nhất thường xảy ra trước khi chọn công cụ. Một đội vẽ quy trình hiện tại, thấy danh sách dài các bước, và quyết định sao chép tất cả vào phần mềm vì đó là cách mọi người làm hôm nay. Nhưng thói quen không đồng nghĩa với giá trị. Nếu một bước tồn tại chỉ vì biểu mẫu giấy hay một lỗi năm năm trước, nhồi nó vào hệ thống chỉ làm cho lãng phí nhanh hơn.

Sai lầm ngược lại cũng nguy hiểm. Một đội thấy chậm và bỏ các phê duyệt hay kiểm tra mà không hỏi rủi ro mà các kiểm soát đó đang quản lý. Một số kiểm soát thừa, nhưng có những kiểm soát bảo vệ tiền bạc, tuân thủ, dữ liệu khách hàng, hoặc chất lượng dịch vụ. Khi những bảo vệ đó biến mất, quy trình có thể trông gọn hơn một tuần nhưng sau đó gây ra vấn đề lớn hơn.

Một cái bẫy khác là tự động hóa ngoại lệ trước khi sửa đường chính. Các trường hợp bất thường đau đầu và đáng nhớ, nên đội tập trung vào chúng trước. Kết quả là một luồng phức tạp được dựng quanh các trường hợp biên, trong khi 80% công việc thường ngày vẫn chậm và rối. Hãy thiết kế cho trường hợp bình thường trước. Rồi thêm xử lý ngoại lệ đơn giản khi thực sự cần.

Đội cũng rơi vào rắc rối khi một bên liên quan ồn ào trở thành tiếng nói duy nhất của cả quy trình. Quản lý có thể quan tâm báo cáo, lãnh đạo tài chính quan tâm quy tắc phê duyệt, còn nhân viên tuyến đầu quan tâm tốc độ. Nếu chỉ một trong những góc nhìn đó định hình thiết kế, phần mềm chỉ phù hợp với một người và làm mọi người khác khó chịu.

Một thử nghiệm ngắn bắt nhiều vấn đề sớm, nhưng nhiều đội bỏ qua vì muốn nhanh. Ngay cả một thử nghiệm đơn giản với người dùng thực cũng thường lộ ra vấn đề như các bước sai thứ tự, thiếu thông tin tại điểm chuyển giao, phê duyệt gây chậm nhưng không bảo vệ, trường hợp hiếm không thực sự phổ biến, và màn hình chỉ có ý nghĩa với nhóm dự án.

Điều này càng quan trọng hơn trong môi trường xây dựng nhanh. Koder.ai, ví dụ, cho phép đội tạo web, server, và app di động qua giao diện chat. Tốc độ đó hữu ích, nhưng chỉ khi luồng đã được thách thức và dọn dẹp trước.

Danh sách kiểm tra nhanh trước khi số hóa

Trước khi quyết định số hóa hay thiết kế lại quy trình, dừng lại và chạy một đánh giá ngắn. Một quy trình có thể cảm thấy quan trọng vì có nhiều bước, bàn giao, và phê duyệt. Điều đó không có nghĩa mỗi phần đều hữu ích.

Dùng danh sách kiểm tra này với những người làm công việc hàng ngày. Đi qua một trường hợp thực tế từ đầu đến cuối, không phải phiên bản lý tưởng trong tài liệu chính sách.

• Có ai đó giải thích được mục đích của bước trong một câu rõ ràng không?
• Bước này thực sự thay đổi kết quả, giảm rủi ro, hay cải thiện chất lượng không?
• Nếu bước này biến mất ngày mai, quy trình còn vận hành không?
• Nếu bước tạo thời gian chờ, sự bảo vệ nào mà sự chờ đợi đó tạo ra?
• Phiên bản đơn giản hơn đã được thử trên một trường hợp nhỏ, ít rủi ro chưa?

Một ví dụ nhỏ giúp điều này trở nên cụ thể. Hãy tưởng tượng mọi hoàn tiền nhỏ cần chữ ký quản lý. Nếu hầu hết hoàn tiền đều được chấp thuận, bước đó có thể chỉ ghi lại quyền hạn thay vì cải thiện quyết định. Trong trường hợp đó, mức giới hạn hoàn tiền kèm kiểm tra mẫu có thể bảo vệ doanh nghiệp tốt như vậy với ít chậm trễ hơn.

Quy tắc đơn giản: giữ các bước thay đổi kết quả, đơn giản hóa những bước bảo vệ chất lượng, và loại bỏ những bước chỉ làm cho công việc có vẻ chính thức. Nếu một bước không thể biện minh cho thời gian của nó, nó không nên bị khóa vào phần mềm.

Cách biến quy trình mới thành phần mềm

Khi bạn đã dọn sạch quy trình, đừng nhảy thẳng vào màn hình, biểu mẫu và tự động hóa. Bắt đầu bằng việc viết quy trình như một tập hợp quy tắc rõ ràng: điều gì khởi động công việc, ai chịu trách nhiệm mỗi bước, thông tin gì phải chuyển, và điều gì được tính là hoàn thành.

Một bài kiểm tra hữu ích: một đồng nghiệp mới có thể theo luồng mà không phải dừng lại hỏi thêm không? Nếu không, phần mềm sẽ gây bối rối.

Viết đường mặc định trước

Phần lớn công việc theo cùng một lộ trình cơ bản. Xây lộ trình đó trước tiên. Với mỗi bàn giao, xác định:

• điều gì kích hoạt bước
• ai chịu trách nhiệm
• thông tin cần thiết
• khi nào phải phản hồi
• chuyện gì xảy ra sau khi phê duyệt, từ chối, hoặc không có phản hồi

Điều này giữ hệ thống tập trung vào công việc thường ngày thay vì các ngoại lệ hiếm.

Rồi đánh dấu những điểm nơi phán đoán con người vẫn cần thiết. Một quy tắc có thể điều hướng yêu cầu, gửi nhắc, hoặc kiểm tra trường còn thiếu. Nhưng một số quyết định vẫn cần người. Có thể quản lý xem chi tiêu bất thường, hoặc trưởng hỗ trợ quyết định một yêu cầu có phá vỡ chính sách hay không. Ghi rõ những khoảnh khắc đó để chúng không bị chôn trong các nhãn mơ hồ như "xem xét đặc biệt."

Sau đó, xác định vài ngoại lệ xứng đáng xử lý đặc biệt ngay bây giờ. Giữ danh sách ngắn. Nếu chuyện gì đó xảy ra vài tháng một lần, có thể giữ thủ công lúc đầu. Thông thường điều đó tốt hơn là xây logic thêm mà chẳng ai dùng.

Giữ ghi chú phiên bản từ đầu. Một bản ngắn về thay đổi, khi nào và vì sao làm cho việc cập nhật sau này dễ hơn. Nó cũng hữu ích khi đội hỏi vì sao hệ thống hành xử một cách nào đó.

Nếu bạn dùng nền tảng như Koder.ai, những ghi chú đó có thể đồng thời là đặc tả ngôn ngữ đơn giản. Quy tắc càng rõ, bản dựng đầu càng sạch.

Hãy coi phiên bản đầu như đường phổ biến được làm tốt. Đừng xây quá nhiều cho các trường hợp hiếm. Bắt đầu với luồng mọi người dùng hàng ngày, giữ phán đoán con người hiển nhiên, và chỉ thêm khi sử dụng thực tế chứng minh cần.

Bước tiếp theo: triển khai nhỏ và an toàn

Bắt đầu nhỏ. Chọn một quy trình đủ gây khó chịu để quan trọng, nhưng đủ gọn để một sai sót không làm gián đoạn toàn bộ doanh nghiệp.

Một thử nghiệm tốt thường có chủ sở hữu rõ, nhóm người dùng nhỏ, và nhiều công việc thủ công lặp. Phê duyệt chi phí cho một phòng ban, chuyển giao lead cho một đội bán hàng, hoặc thu hồ sơ khách hàng cho một dòng dịch vụ là ví dụ phù hợp.

Nếu bạn vẫn phân vân giữa số hóa hay thiết kế lại, bước an toàn nhất là không triển khai toàn công ty. Thử phiên bản đã dọn với nhóm hẹp và quan sát cách nó hoạt động trong công việc thực.

Kiểm tra điều gì trước

Chạy một pilot ngắn với vài người dùng thực. Cho thời gian cố định, ví dụ hai đến bốn tuần, để mọi người biết đó là thử nghiệm chứ không phải phiên bản cuối.

Tập trung vào vài chỉ số đơn giản:

• thời gian tiết kiệm mỗi nhiệm vụ hoặc trường hợp
• lỗi, làm lại, hoặc chuyển giao bị bỏ sót
• phản hồi người dùng về chỗ bối rối hoặc cản trở
• ngoại lệ vẫn cần xử lý thủ công
• liệu quản lý có thấy trạng thái rõ hơn không

Đừng coi phiên bản đầu là hoàn chỉnh. Phản hồi sớm là mục đích. Nếu mọi người tiếp tục làm việc quanh một bước, điều đó thường có nghĩa bước đó không rõ, không cần thiết, hoặc thiếu điều quan trọng.

Ví dụ, một đội chuyển luồng phê duyệt bằng giấy vào một ứng dụng đơn giản. Pilot cho thấy phê duyệt nhanh hơn, nhưng nhân viên vẫn gọi nhau để giải thích chi tiết thiếu. Đó là kết quả hữu ích. Nó cho biết luồng cần một form yêu cầu tốt hơn trước khi triển khai rộng.

Khi quy trình hoạt động với nhóm pilot, mở rộng theo giai đoạn. Thêm một đội, rồi thêm đội khác. Giữ đo lường cùng vài con số để so sánh kết quả thay vì dựa vào cảm nhận.

Nếu bạn muốn thử ý tưởng nhanh, Koder.ai có thể là lựa chọn thực tế để biến luồng đã dọn thành app web hoặc di động từ ngôn ngữ tự nhiên. Phần quan trọng là thứ tự: sửa quy trình trước, chứng minh trên quy mô nhỏ, rồi mới triển khai rộng.