Cách thiết kế quy trình làm việc từ yêu cầu đầu vào

Vì vậy, điểm bắt đầu của thiết kế quy trình làm việc không nên là câu hỏi “bước đầu tiên phải làm gì?”. Câu hỏi cần giải quyết trước là: “Khi nào quy trình được kích hoạt, nó nhận cái gì, phải tạo ra kết quả gì và trong phạm vi điều kiện nào?”. Khi những yếu tố này chưa rõ, một sơ đồ dù chi tiết vẫn có thể chỉ là danh sách công việc được nối bằng mũi tên, chứ chưa phải một cấu trúc quy trình có thể vận hành ổn định.

Bắt đầu từ yêu cầu đầu vào, không bắt đầu từ danh sách các bước

Sai lầm phổ biến khi thiết kế quy trình là hình dung ngay một chuỗi hành động: nhân viên tiếp nhận, trưởng bộ phận kiểm tra, quản lý phê duyệt, sau đó chuyển sang bộ phận tiếp theo. Cách làm này có vẻ trực quan nhưng đang ngầm giả định rằng người thiết kế đã biết chính xác thứ được tiếp nhận là gì, khi nào nó hợp lệ và kết quả cần tạo ra là gì.

Trong thực tế, chính những giả định chưa được làm rõ này tạo ra lỗi cấu trúc. Chẳng hạn, một quy trình phê duyệt có thể bắt đầu bằng bước “quản lý xem xét yêu cầu”, nhưng nếu chưa xác định thế nào là một yêu cầu đủ thông tin thì quy trình chưa biết phải xử lý trường hợp thiếu dữ liệu ở đâu. Nếu chưa biết loại yêu cầu nào cần phê duyệt, sơ đồ cũng chưa có cơ sở để đặt điểm ra quyết định. Nếu chưa xác định kết quả sau phê duyệt, điểm kết thúc của quy trình vẫn mơ hồ.

Do đó, bước đầu tiên hợp lý hơn là chuẩn hóa bộ yêu cầu đầu vào. Các bước xử lý chỉ được thiết kế sau khi biết quy trình đang chuyển đổi một trạng thái đầu vào thành trạng thái đầu ra nào.

Cách tiếp cận này cũng phù hợp với tư duy quản lý theo quá trình: một quá trình cần được nhìn thông qua đầu vào, đầu ra, trình tự tương tác, tiêu chí kiểm soát và trách nhiệm liên quan. Nói cách khác, luồng công việc là kết quả của các quan hệ đã được xác định, không phải điểm xuất phát để suy ngược lại yêu cầu.

Một yêu cầu đầu vào đủ để thiết kế quy trình cần chứa những gì?

“Có đầu vào” chưa đồng nghĩa với “đầu vào đã đủ để thiết kế”. Một biểu mẫu, một email yêu cầu hay một bộ hồ sơ chỉ mô tả vật được chuyển vào hệ thống. Người thiết kế còn phải hiểu sự kiện nào khiến quy trình bắt đầu, kết quả được mong đợi và những điều kiện nào có thể làm thay đổi cách xử lý.

Một bộ yêu cầu đầu vào có thể được kiểm tra qua sáu nhóm thông tin:

1.    Trigger: Sự kiện hoặc điều kiện làm quy trình chính thức bắt đầu

2.    Đối tượng đầu vào: Hồ sơ, dữ liệu, yêu cầu, vật phẩm hoặc trạng thái cần được xử lý

3.    Điều kiện hợp lệ: Thông tin tối thiểu phải có để đầu vào được tiếp nhận thay vì trả lại hoặc bổ sung

4.    Đầu ra mong đợi: Trạng thái hoặc kết quả phải tồn tại khi quy trình hoàn tất

5.    Vai trò liên quan: Ai chịu trách nhiệm xử lý, ai cung cấp thông tin và ai có quyền ra quyết định

6.    Quy tắc và giới hạn: Điều kiện nào làm luồng thay đổi, dừng, quay lại hoặc chuyển sang cách xử lý khác

Trigger và dữ liệu đầu vào không phải một thứ

Trigger trả lời câu hỏi “điều gì khiến quy trình phải chạy?”, còn dữ liệu đầu vào trả lời “quy trình nhận cái gì để xử lý?”.

Ví dụ, việc khách hàng gửi yêu cầu có thể là trigger. Nội dung yêu cầu, thông tin khách hàng và tài liệu kèm theo là đầu vào. Nếu hai khái niệm này bị nhập làm một, người thiết kế dễ bỏ sót tình huống trigger đã xảy ra nhưng dữ liệu chưa đủ điều kiện xử lý.

Đầu ra phải được xác định cùng lúc với đầu vào

Chỉ biết điểm bắt đầu mà chưa biết điểm kết thúc khiến người thiết kế không có tiêu chí để quyết định bước nào thực sự cần thiết.

Nếu đầu vào là “yêu cầu mua hàng” nhưng đầu ra chỉ được mô tả mơ hồ là “xử lý xong yêu cầu”, rất khó xác định quy trình cần dừng ở phê duyệt, phát hành đơn mua hàng hay xác nhận với người yêu cầu. Ngược lại, khi đầu ra được định nghĩa rõ, mỗi bước trung gian có thể được kiểm tra bằng một câu hỏi đơn giản: bước này có cần thiết để biến đầu vào thành đầu ra đã xác định hay không?

Chuyển yêu cầu đầu vào thành ranh giới của quy trình

Sau khi làm rõ đầu vào và đầu ra, việc tiếp theo chưa phải là vẽ toàn bộ luồng. Trước hết cần khóa ranh giới quy trình.

Ranh giới xác định quy trình bắt đầu chịu trách nhiệm từ thời điểm nào và chấm dứt trách nhiệm ở đâu. Đây là yếu tố ngăn một sơ đồ phình ra thành toàn bộ hoạt động của nhiều phòng ban chỉ vì các hoạt động đó có liên quan với nhau.

Giả sử một bộ phận thiết kế quy trình xử lý yêu cầu mua hàng. Nếu phạm vi bắt đầu khi nhân viên phát sinh nhu cầu và kết thúc khi hàng hóa được giao, quy trình sẽ rất khác với trường hợp phạm vi bắt đầu khi bộ phận mua hàng nhận một yêu cầu đã được phê duyệt và kết thúc khi đơn đặt hàng được phát hành. Cùng một chủ đề “mua hàng” nhưng khác đầu vào và đầu ra sẽ tạo thành hai cấu trúc khác nhau.

Ranh giới vì thế phải được suy ra từ trách nhiệm xử lý, không phải từ mong muốn đưa mọi hoạt động liên quan vào một sơ đồ.

Một phép thử hữu ích là diễn đạt quy trình thành một câu hoàn chỉnh: “Khi [trigger] xảy ra, [vai trò chịu trách nhiệm] tiếp nhận [đầu vào hợp lệ] để tạo ra [đầu ra] trong [phạm vi và điều kiện đã xác định].” Nếu câu này vẫn chứa những khái niệm mơ hồ như “xử lý phù hợp”, “kiểm tra đầy đủ” hay “chuyển cho bên liên quan”, yêu cầu đầu vào chưa đủ rõ để khóa cấu trúc.

Xác định vai trò và điều kiện trước khi nối các bước thành luồng

Khi ranh giới đã rõ, cấu trúc quy trình bắt đầu hình thành từ hai loại quan hệ: trách nhiệm và điều kiện chuyển trạng thái.

Trách nhiệm cho biết ai có quyền hoặc nghĩa vụ thực hiện một hành động. Điều kiện cho biết khi nào luồng được phép đi tiếp, phải quay lại, bị từ chối hoặc chuyển sang một nhánh khác. Nếu bỏ qua hai lớp này và chỉ ghi tên hoạt động, sơ đồ có thể đúng về thứ tự nhưng vẫn không đủ để vận hành.

Chẳng hạn, “kiểm tra hồ sơ” chưa phải một bước được định nghĩa tốt nếu không biết ai kiểm tra, kiểm tra điều kiện nào và điều gì xảy ra khi hồ sơ không đạt. Ba thông tin đó quyết định cấu trúc tiếp theo: hồ sơ được chuyển tiếp, trả về để bổ sung hay kết thúc quy trình.

Đây cũng là lý do điểm ra quyết định không nên được thêm vào sơ đồ chỉ vì người thiết kế cảm thấy “ở đây có thể có nhiều trường hợp”. Mỗi nhánh cần xuất phát từ một điều kiện đã tồn tại trong yêu cầu. Nếu chưa mô tả được điều kiện bằng một quy tắc đủ rõ, việc vẽ thêm nhánh chỉ chuyển sự mơ hồ từ tài liệu yêu cầu sang sơ đồ.

Ngược lại, không phải quy trình nào cũng cần nhiều điểm quyết định. Với một công việc đơn giản, ổn định, chỉ có một loại đầu vào và một cách xử lý, cấu trúc tuyến tính có thể là đủ. Điều quan trọng vẫn là điểm bắt đầu, điểm kết thúc và trách nhiệm đã được xác định trước khi viết chuỗi hành động.

Dựng luồng chính trước, sau đó mới xử lý các ngoại lệ

Khi đầu vào, đầu ra, ranh giới, vai trò và điều kiện đã được khóa, lúc này mới nên dựng trình tự các bước.

Luồng chính phải mô tả trường hợp xử lý bình thường

Luồng chính là con đường mà một đầu vào hợp lệ đi qua để đạt đầu ra mong đợi khi không xuất hiện điều kiện bất thường. Thiết kế luồng này trước giúp người làm quy trình nhìn được cơ chế chuyển đổi cốt lõi mà không bị phân tán bởi hàng loạt trường hợp phụ.

Mỗi bước nên tạo ra một thay đổi có ý nghĩa: bổ sung thông tin, xác nhận điều kiện, tạo quyết định, chuyển trách nhiệm hoặc tạo ra một trạng thái mới. Nếu bỏ một bước mà đầu vào vẫn có thể đi đến đầu ra đúng yêu cầu, cần xem lại liệu bước đó có thực sự thuộc quy trình hay chỉ là thói quen vận hành hiện tại.

Ngoại lệ phải quay về điều kiện đầu vào

Sau khi luồng chính ổn định, các trường hợp ngoại lệ mới được đưa vào: thiếu dữ liệu, không đạt điều kiện, vượt thẩm quyền, cần bổ sung thông tin hoặc không thể hoàn thành bước tiếp theo.

Điểm quan trọng là ngoại lệ phải có nguyên nhân xác định. Không nên tạo một nhánh chung kiểu “trường hợp khác” rồi để người thực hiện tự suy đoán.

Nếu quá nhiều ngoại lệ xuất hiện ngay khi bắt đầu vẽ, đó có thể là dấu hiệu yêu cầu đầu vào chưa được phân loại đủ rõ. Trong trường hợp này, thêm nhiều nhánh không giải quyết được nguyên nhân; cần quay lại kiểm tra điều kiện hợp lệ, quy tắc xử lý hoặc ranh giới của quy trình.

Kiểm tra cấu trúc trước khi chuẩn hóa thành quy trình chính thức

Một sơ đồ hoàn chỉnh về hình thức vẫn có thể chứa lỗi logic. Vì vậy, trước khi xem cấu trúc là hoàn tất, nên kiểm tra bằng cách đưa các tình huống cụ thể đi xuyên qua toàn bộ luồng.

Trường hợp đầu tiên là một đầu vào hợp lệ và bình thường. Nó phải đi từ trigger đến đầu ra mà không gặp bước thừa hoặc điểm quyết định không có cơ sở. Sau đó thử một đầu vào thiếu thông tin để xác định quy trình biết trả về đâu, ai chịu trách nhiệm và điều kiện nào cho phép quay lại. Cuối cùng, thử một trường hợp chạm vào giới hạn hoặc ngoại lệ quan trọng để kiểm tra xem cấu trúc có điểm xử lý rõ ràng hay đang dựa vào phán đoán ngầm của người thực hiện.

Cách kiểm tra này đặc biệt hữu ích vì nó buộc từng mũi tên trong sơ đồ phải có lý do. Một bước phải tồn tại vì nó tạo ra giá trị xử lý cần thiết; một điểm quyết định phải tồn tại vì có điều kiện làm thay đổi luồng; một lần bàn giao phải tồn tại vì trách nhiệm chuyển từ vai trò này sang vai trò khác.

Nếu kiểm thử làm xuất hiện hàng loạt câu hỏi chưa thể trả lời, không nên tiếp tục làm sơ đồ chi tiết hơn. Cần quay lại bộ yêu cầu đầu vào. Sửa yêu cầu ở thời điểm này thường đơn giản hơn nhiều so với cố vá một cấu trúc đã được xây dựng trên các giả định không rõ ràng.

Thiết kế quy trình làm việc nên bắt đầu từ yêu cầu đầu vào đã được làm rõ, chứ không phải từ việc liệt kê các bước mà mọi người đang thực hiện. Đầu vào cần được đặt trong quan hệ với trigger, đầu ra mong đợi, phạm vi trách nhiệm, vai trò và các điều kiện có thể làm thay đổi cách xử lý.

Khi những yếu tố này đã rõ, cấu trúc quy trình gần như được suy ra theo logic: xác lập ranh giới, xác định trách nhiệm, đặt các điều kiện quyết định, dựng luồng chính, bổ sung ngoại lệ và kiểm tra lại bằng các tình huống thực tế. Nếu cấu trúc liên tục phải sửa bằng cách thêm bước và thêm nhánh, vấn đề cần kiểm tra trước tiên không phải sơ đồ, mà là chất lượng của yêu cầu đầu vào đã dùng để thiết kế nó.