Sơ đồ hóa quy trình: BPMN hay Flowchart

Do đó câu hỏi mở đầu của bài này nên dùng BPMN hay Flowchart? Thật ra không phải câu quan trọng nhất, nhưng nó là câu ai cũng hỏi trước, nên hãy trả lời nó trước rồi đi tới phần quan trọng hơn.

Người đọc thật của lưu đồ

Trước khi chọn chuẩn thì phải rõ tài liệu này phục vụ ai, bởi tiêu chí chọn nằm ở đó chứ không nằm ở đặc tả kỹ thuật của chuẩn.

Trong năm nhóm người đọc lưu đồ gồm người viết tài liệu đặc tả, đội phát triển, người kiểm thử, người đi đào tạo, và khách hàng. Bốn nhóm đầu đều là người trong nghề và họ đọc được gần như mọi ký hiệu. Nhóm thứ năm mới là nhóm quyết định tiêu chí chọn chuẩn, bởi họ là người ký xác nhận, và chữ ký của họ chỉ có giá trị nếu họ thật sự hiểu thứ mình ký.

Trong tài liệu quy trình triển khai mà tôi tự viết cho công việc của mình, nguyên tắc ở chỗ này được ghi rất ngắn:

Không nhất thiết phải theo một framework nào, hãy chọn cái phù hợp, vì kết quả mới là thứ quan trọng nhất.

Tiêu chí chọn chuẩn

Từ nguyên tắc trên thì việc chọn trở thành một quyết định có tiêu chí rõ ràng chứ không còn là chuyện sở thích.

Bạn dùng flowchart trong ba tình huống. Đầu tiên là khi doanh nghiệp đã quy định dùng nó, chuyện này gặp nhiều hơn bạn nghĩ, nhất là ở những nơi đã có sẵn bộ quy trình nội bộ. Bên cạnh đó là khi nghiệp vụ không quá phức tạp, tức luồng đi tương đối thẳng và số nhánh rẽ ít. Tình huống còn lại, và cũng là tình huống phổ biến nhất, là khi người đọc chính của bạn là người dùng cơ bản, không có nền tảng phân tích và không quen ký hiệu.

Ngược lại, bạn dùng BPMN khi nghiệp vụ chi tiết tới mức flowchart không thể hiện nổi, đặc biệt khi cần phân biệt bước nào làm tay bước nào chạy tự động, hoặc khi cần thể hiện luồng thông tin song song với luồng công việc.

Tuy nhiên, nếu chọn BPMN thì có một việc bắt buộc phải làm mà rất nhiều đội bỏ qua, đó là dành hẳn một buổi hoặc một tài liệu ngắn để giải thích ký hiệu cho khách trước khi trình bày sơ đồ. Bỏ qua bước này thì bạn quay lại đúng cảnh mở đầu bài viết, tức là nhận được một cái gật đầu không có nội dung bên trong.

Năm ký hiệu và chỗ hay nhầm

Flowchart chỉ có năm ký hiệu cơ bản, và đó chính là lý do nó dễ đọc.

Trong năm ký hiệu này, cái tôi phải giải thích lại nhiều lần nhất là hình bình hành, và nguyên nhân là người vẽ hiểu nó thành bước nhập liệu.

Hình bình hành chỉ biểu thị dữ liệu, nó không thực hiện tác vụ nào.

Ví dụ dễ hình dung nhất là quy trình tiếp nhận đơn hàng từ sàn thương mại điện tử: đơn đặt hàng đổ về từ sàn là dữ liệu đầu vào, sau khi xử lý xong thì mã đơn đã phân là dữ liệu đầu ra, và cả hai đều không phải là việc do ai đó làm. Còn thao tác nhân viên mở đơn lên kiểm tra thông tin khách hàng thì đó là một bước công việc, nên nó phải là hình chữ nhật.

Phân biệt được hai cái này thì sơ đồ của bạn đọc lên nghe như một câu chuyện có chủ ngữ rõ ràng; ngược lại, nhầm lẫn giữa chúng thì người đọc không biết chỗ nào có người làm chỗ nào không.

Cùng một ký hiệu, hai chuẩn hiểu khác nhau

Khác biệt giữa hai chuẩn không nằm ở chỗ BPMN có nhiều ký hiệu hơn, mà nằm ở chỗ cùng một ký hiệu nhưng BPMN đòi bạn nói thêm thông tin.

Với hình chữ nhật, flowchart chỉ hiểu đơn giản là một bước công việc, còn BPMN thì phân biệt tiếp rằng bước này do người làm hay hệ thống tự chạy, có lặp đi lặp lại hay không, hay là bước được thực hiện sau một khoảng thời gian nhất định. Đây chính là lý do BPMN hữu ích khi bạn cần chỉ ra chỗ nào hệ thống sẽ tự động hóa, bởi trong dự án ERP thì phần giá trị nhất thường nằm đúng ở chỗ chuyển một bước từ làm tay sang tự động.

Với mũi tên thì khác biệt còn rõ hơn. Flowchart chỉ thể hiện hướng đi, trong khi BPMN phân ba loại:

• mũi tên thường nghĩa là đi tiếp bước sau
• mũi tên có gạch nghĩa là phải thỏa điều kiện mới đi đường này
• còn nét đứt nghĩa là luồng thông tin chứ không phải bước thực hiện

Loại thứ ba là loại mà flowchart không diễn đạt được, nên nếu quy trình của bạn có nhiều chỗ trao đổi thông tin giữa các bộ phận mà không kéo theo hành động thì BPMN sẽ gọn hơn hẳn.

Từ đó rút ra một cách chọn thực dụng. Hãy liệt kê trước những thông tin bắt buộc phải thể hiện trên sơ đồ, rồi xem flowchart có diễn đạt hết không; nếu hết thì dùng flowchart, còn nếu thiếu thì mới cần tới BPMN, và lúc đó nhớ dạy khách đọc ký hiệu.

Năm quy tắc vẽ

Đây mới là phần quyết định lưu đồ của bạn có dùng được hay không, và nó không phụ thuộc vào chuẩn nào cả.

Quy tắc đầu tiên nghe hiển nhiên nhất và bị vi phạm ngay từ sơ đồ thứ hai, đó là giữ nó tối giản. Một sơ đồ tốt là sơ đồ mà người đọc lần đầu vẫn theo được mạch từ đầu tới cuối mà không phải quay lại, do đó nếu một quy trình dài tới mức không vừa một trang thì hãy tách ra thành các quy trình con rồi tham chiếu qua lại, thay vì nhồi tất cả vào một bức tranh khổng lồ.

Tiếp theo là chuyện đồng nhất ký hiệu, và đây là quy tắc bị vi phạm nhiều nhất. Cùng một loại bước thì phải cùng kích thước, cùng màu, cùng font chữ, cùng kiểu đường viền, và phải giữ như vậy trên toàn bộ các quy trình của dự án chứ không chỉ trong một sơ đồ. Lý do không dừng ở thẩm mỹ: khi người không có chuyên môn nhìn thấy một hộp màu xanh đứng cạnh một hộp màu đỏ, họ sẽ tự suy ra rằng hai hộp đó khác nhau về bản chất và sẽ đi hỏi bạn cái khác nhau đó là gì, tức là bạn vừa tạo ra một ý nghĩa không tồn tại rồi mất thời gian giải thích rằng nó không tồn tại.

Sau đó là chuyện ghi chú, và nguyên tắc ở đây gọn tới mức một câu là đủ, rằng mọi quy tắc và điều kiện rẽ nhánh phải nằm ngay trên sơ đồ. Đừng bắt người đọc tham chiếu sang tài liệu khác để biết khi nào thì đi nhánh trái khi nào đi nhánh phải, bởi tại đúng thời điểm họ đọc sơ đồ thì họ không có tài liệu kia trong tay; đặc biệt ở những chỗ rẽ nhiều hướng thì điều kiện của từng nhánh phải được ghi thẳng lên mũi tên.

Kế đó là chuyện chính xác, và trong đó chi tiết đáng kiểm nhất lại là thứ nhỏ nhất, tức hướng của mũi tên. Sơ đồ vẽ đi vẽ lại nhiều lần thì rất dễ còn sót một mũi tên chỉ ngược, mà một mũi tên ngược ở chỗ rẽ nhánh đủ để đội phát triển hiểu sai toàn bộ điều kiện. Vì vậy trước khi gửi đi, hãy review toàn bộ sơ đồ từ điểm bắt đầu tới từng điểm kết thúc, đúng theo hướng mũi tên, xem có đường nào cụt hoặc quay vòng vô tận không.

Cuối cùng, đừng biến mỗi hộp thành một đoạn văn. Trong hộp chỉ ghi một câu ngắn thể hiện hành động, còn chi tiết thì đưa xuống ghi chú, bởi một hộp chứa năm dòng chữ buộc người đọc phải dừng lại đọc thay vì lướt theo luồng, và khi phải dừng ở mỗi hộp thì họ mất cảm giác về toàn cảnh quy trình, tức là mất đúng thứ mà sơ đồ sinh ra để mang lại.

Hai bộ lưu đồ

Mỗi dự án cần hai bộ, một bộ mô tả quy trình hiện tại và một bộ mô tả quy trình sau khi lên hệ thống, trong đó bộ tương lai là bộ được xây và được khách xác nhận áp dụng trên hệ thống mới.

Vậy còn bộ hiện tại, có bỏ được không. Theo cách tôi làm thì không nên bỏ, dù nó không được dùng để xây gì cả, và lý do nằm ở hai chỗ.

Chỗ thứ nhất là nó buộc bạn phải hiểu doanh nghiệp trước khi thiết kế lại. Khi ngồi vẽ ra cách họ đang làm, bạn phát hiện những bước tồn tại vì một lý do lịch sử nào đó mà không ai nhắc tới trong buổi khảo sát, và những bước như vậy nếu bỏ đi mà không hỏi thì tới lúc vận hành sẽ vỡ ra.

Chỗ còn lại là nó giúp khách hàng thấy được cái họ được lợi. Đặt hai sơ đồ cạnh nhau, một bên là quy trình hiện tại còn vài chỗ nhập liệu lặp, một bên là quy trình mới đã bỏ được những chỗ đó, thì phần giá trị của dự án hiện ra rõ hơn mọi lời giải thích. Đồng thời đây cũng là công cụ hữu ích khi bạn cần thuyết phục người dùng thay đổi thói quen, vì thứ thuyết phục họ là nhìn thấy việc của chính mình ngắn đi.

Chốt bằng email

Cuối cùng là bước không liên quan gì tới cách vẽ nhưng lại quyết định giá trị của toàn bộ công sức ở trên.

Lưu đồ quy trình phải được gửi cho khách hàng qua email, kèm thời hạn phản hồi, và phải nhận được xác nhận bằng văn bản trước khi đội phát triển bắt đầu. Vì sao lưu đồ là tài liệu không được cắt dù dự án gấp tới đâu thì tôi đã nói ở bài về bộ tài liệu dự án ERP; điều đáng nói ở đây là chuyện xác nhận thế nào cho có giá trị, bởi một chữ ký vào bản vẽ mà người ký không đọc được thì nó không bảo vệ được ai cả.

Do đó đừng chỉ gửi file rồi chờ. Cách hiệu quả hơn là trình bày sơ đồ trong một buổi họp, đi từng bước một và hỏi lại ở từng nhánh rẽ, chốt xong quy trình nào thì mới sang quy trình sau, rồi sau buổi họp mới gửi email tổng hợp lại những gì đã chốt.

Người đọc một mình một file thường gật cho xong, còn người phải trả lời từng câu hỏi thì buộc phải nghĩ.

Khi bộ lưu đồ đã được chốt, công việc tiếp theo là đi vào bên trong từng bước để mô tả chi tiết cách người dùng thao tác, và ở đó bạn sẽ gặp ba loại luồng.