↓ Chuyển đến nội dung chính
Sơ đồ BPMN với các lane và task trên bàn làm việc
  1. Bài viết/

BPMN cho người mới: vẽ as-is/to-be từ ghi chú workshop

·
Đặng Đức Quân
Tác giả
Đặng Đức Quân
Chuyện nghề BA trong lĩnh vực sản xuất. Viết cho mình, và cho cả những ai đang muốn dấn thân vào con đường này.

Cập nhật lần cuối:

Giả sử bạn vừa bước ra khỏi buổi workshop hai tiếng với phòng mua hàng, cầm về tờ giấy chi chít chữ, ai gửi yêu cầu, ai duyệt, mức nào phải lên giám đốc, lúc nào thì chạy Excel ngoài, giờ phải vẽ lại thành một sơ đồ cho cả team nhìn chung một bức tranh, mở công cụ lên rồi đứng hình. Bài này đi từ đúng tờ giấy đó ra một sơ đồ BPMN dùng được, kèm mấy lỗi hay biến sơ đồ thành tranh treo tường.

BPMN trong một đoạn
#

BPMN (Business Process Model and Notation) là chuẩn ký hiệu để vẽ quy trình nghiệp vụ, khác flowchart ở chỗ có quy ước rõ ràng, ai làm thì đặt vào lane, rẽ nhánh dùng gateway, sự kiện dùng hình tròn, nhờ vậy hai người cùng nhìn một sơ đồ sẽ hiểu giống nhau mà không phải đoán. Trong BABOK Guide v3 việc này thuộc kỹ thuật Process Modelling (10.35), còn BPMN là một ký pháp phổ biến để làm kỹ thuật đó.

Bạn không cần thuộc cả trăm ký hiệu, với phần lớn sơ đồ chừng này là đủ:

  • Pool: ranh giới một quy trình hoặc một tổ chức, thường cả sơ đồ nằm trong một pool lớn.
  • Lane: một vai trò hoặc phòng ban bên trong pool, ví dụ “Phòng mua hàng”, “Kế toán”.
  • Start event: hình tròn rỗng, điểm bắt đầu.
  • End event: hình tròn viền dày, điểm kết thúc.
  • Task: hình chữ nhật bo góc, một bước công việc cụ thể.
  • Gateway độc quyền: hình thoi có dấu X, chỉ một nhánh được đi tiếp tùy điều kiện.
  • Gateway song song: hình thoi có dấu cộng, nhiều nhánh chạy cùng lúc.
  • Sequence flow: mũi tên liền, thứ tự thực hiện giữa các task.
  • Message flow: mũi tên đứt, trao đổi thông tin giữa các pool.
  • Intermediate event: hình tròn viền đôi, sự kiện xảy ra giữa luồng như nhận tin nhắn hay hẹn giờ.

Theo mình nắm mười ký hiệu này là vẽ được phần lớn quy trình nghiệp vụ thường gặp.

as-is trước, to-be sau
#

As-is là quy trình đang chạy, to-be là quy trình mong muốn sau khi cải tiến hoặc lên hệ thống mới, và luôn vẽ as-is trước, vì chưa hiểu hiện trạng thì to-be chỉ là mơ ước. Bạn rất dễ vẽ ra một quy trình sạch đẹp trên giấy mà bỏ qua cái Excel ngoài luồng cả phòng đang ngầm dùng, tới lúc triển khai cái Excel đó lại hiện ra và phá mọi thứ. Vẽ as-is còn là cách phát hiện điểm đau, chỗ nào đang chờ tay, chỗ nào nhập trùng dữ liệu, chỗ nào một người duyệt mà chẳng ai biết tiêu chí là gì.

từ workshop ra sơ đồ trong năm bước
#

Bước một là chuẩn bị câu hỏi trước khi vào họp, bạn cần biết ai bắt đầu quy trình, quy trình đi qua những bước nào, ai duyệt ở mỗi bước, và ngoại lệ là gì, riêng câu “khi nào thì quy trình này không chạy như bình thường” thường khai thác được nhiều nhất.

Bước hai là ghi theo lane ngay trên giấy hoặc sticky, chia cột theo vai trò, bước nào dán vào cột người làm bước đó, nhìn vào là thấy ngay ai đang ôm quá nhiều việc.

Bước ba là vẽ happy path trước, nối các bước chính thành một luồng từ start tới end, chưa lo ngoại lệ, xong luồng chính rồi mới thêm gateway cho các nhánh rẽ.

Bước bốn là đánh dấu điểm đau bằng một ký hiệu riêng, màu khác hay icon gì cũng được, cho chỗ chờ tay, chỗ nhập tay, chỗ dùng Excel trung gian, đây là nguyên liệu cho bước to-be.

Bước năm là review lại với người làm thật, đưa sơ đồ cho chính người vận hành xem và hỏi có đúng không, có chỗ nào em vẽ sai không, đừng chỉ duyệt với trưởng phòng, người bấm nút mỗi ngày mới là người bắt được chỗ sai.

ví dụ đề nghị mua hàng trong nhà máy
#

Đây là ví dụ giả định để bạn dễ hình dung, không phải quy trình của công ty cụ thể nào.

Ở as-is, công nhân phát hiện thiếu vật tư, viết yêu cầu mua ra giấy, đưa tổ trưởng ký, rồi phòng mua nhập lại vào một bảng Excel để theo dõi, đơn trên một mức nào đó thì phải trình giám đốc duyệt. Vấn đề là dữ liệu nằm ở hai nơi, giấy và Excel, nên hay lệch, mà phòng mua cũng chẳng biết đơn nào đang chờ ai duyệt.

Ở to-be trên ERP, công nhân tạo yêu cầu mua ngay trên hệ thống, hệ thống tự chuyển cho người duyệt theo mức giá trị, phòng mua chỉ việc xem danh sách đã duyệt để tạo đơn mua, không còn giấy, cũng không còn Excel trung gian.

Trên sơ đồ, as-is hiện rõ ba lane (Công nhân, Tổ trưởng, Phòng mua) với hai chỗ gãy là chỗ nhập tay vào Excel và chỗ chờ ký giấy, còn to-be gọn lại, rẽ nhánh bằng gateway độc quyền theo mức tiền. Vẽ cả hai thì mọi người thấy khác biệt bằng mắt thay vì cãi nhau bằng lời, và bản to-be này chính là đầu vào cho bước so với sản phẩm chuẩn, mình viết ở bài Fit-gap analysis ERP.

năm lỗi người mới hay mắc
#

Lỗi đầu tiên là chia lane sai, hay gộp hai vai trò vào một lane vì cùng phòng, trong khi hai vai đó làm hai việc khác nhau, tách lane ra mới thấy bàn giao nằm ở đâu. Lỗi thứ hai là gateway không ghi điều kiện, hình thoi rẽ nhánh mà không ghi đi nhánh này khi nào thì người đọc chịu chết. Lỗi thứ ba là vẽ quá chi tiết, tới từng cú click chuột thì sơ đồ thành hướng dẫn sử dụng, chẳng ai đọc nổi, BPMN nên dừng ở mức quy trình chứ không phải thao tác. Lỗi thứ tư là quên start event hoặc end event, người đọc không biết quy trình trôi về đâu. Lỗi thứ năm, cũng là lỗi tốn công nhất, là vẽ to-be trước khi hiểu as-is.

công cụ nên dùng
#

Không cần phần mềm đắt tiền, draw.io (app.diagrams.net) miễn phí, chạy trên trình duyệt, có sẵn bộ ký hiệu BPMN, đủ cho hầu hết nhu cầu, công ty có Visio thì dùng Visio, Bizagi Modeler cũng miễn phí và chuyên BPMN nhưng hơi nặng nếu bạn chỉ vẽ sơ đồ đơn giản. Công cụ nào cũng được, miễn ký hiệu đúng chuẩn để người khác đọc được, vẽ bằng gì mà sai ký hiệu thì vẫn khó hiểu như thường.

sơ đồ để cãi nhau đúng chỗ
#

Sơ đồ BPMN là để nói chuyện chứ không phải để nộp cho đẹp, giá trị của nó nằm ở chỗ cả team nhìn vào cùng một bức tranh và cãi nhau trên đúng vấn đề, thay vì mỗi người hiểu một kiểu. Chưa có dự án thật để vẽ thì làm một case simulation trong portfolio, cách làm có trong bài Portfolio BA khi chưa có dự án, còn muốn lấy yêu cầu cho đúng trước khi vẽ thì đọc 3 nguyên tắc sống còn để lấy yêu cầu hiệu quả.

Bạn hay vẽ quy trình bằng công cụ gì, và có mẹo nào khi ngồi workshop không? Kể mình nghe qua Facebook hoặc LinkedIn nhé.

Bài viết liên quan

BRD, SRS, FS khác nhau thế nào? Dự án thật dùng cái nào

·
Lỗi hay gặp của fresher với BRD, SRS, FS là thuộc lòng ba định nghĩa mà vẫn viết sai tài liệu. Giả sử ngày đầu đi làm bạn được giao viết SRS cho module này, trong khi tuần trước có người vừa gửi BRD, cả team thì cứ nói FS, ba cái tên mà câu hỏi thật chỉ có một, tài liệu này ai đọc và để quyết định việc gì.

ERD cho BA: đọc được sơ đồ dữ liệu mà không cần là dev

·
Lỗi hay gặp của BA mới với ERD là lướt qua luôn, coi đó là việc của dev, mà hậu quả thì tới muộn, viết yêu cầu xem lịch sử mua hàng của khách mà không biết dữ liệu nằm ở bảng nào, nên chẳng hỏi được mấy câu quan trọng kiểu một khách có thể có mấy địa chỉ giao hàng. Đọc ERD ở mức BA không cần biết code, chỉ cần bốn bước và một ví dụ.

Non-functional requirement: những yêu cầu BA hay quên

·
Giả sử bạn viết xong mọi yêu cầu chức năng cho màn hình báo cáo tồn kho, chạy test ngon lành, ai cũng khen, rồi tới ngày go-live dữ liệu thật đổ vào mấy chục nghìn dòng, báo cáo mất hơn một phút mới load xong, khách đứng bên cạnh nhìn bạn. Đó là lúc bạn nhận ra mình đã quên một thứ tên là non-functional requirement, yêu cầu phi chức năng.