Hế lô anh em. Cuối cùng mình cũng đã hoàn thiện một bài nằm trong “kho” nhiều tháng. Đây sẽ là bài “đập hộp” trong chuỗi bài viết về hộp đồ nghề của BA. Đồ nghề đầu tiên, đó là BPMN ?

Bài này mình sẽ đi sơ lược cho anh em: BPMN là gì, tại sao nó ra đời, dành cho đối tượng nào. Và quan trọng hơn hết, BPMN được dùng cho mục đích gì?

Okay, let’s gooooo!!!

1. BPMN là gì?

BPMN là viết tắt của Business Process Modeling Notation. “Notation” nghĩa là ký hiệu. Tức BPMN là tập hợp các ký hiệu chuẩn để mô tả quy trình của doanh nghiệp. Hay để mô hình hóa quy trình của doanh nghiệp.

Để hiểu chi tiết hơn thì anh em bấm vào hình dưới đây để xem ví dụ.

Anh em chờ xíu, hình nó sẽ từ từ load ra rõ hơn. Nếu chưa rõ, nhấn vào nút View Full Size để xem full HD (nguồn: giai Bách Khoa)

À nhầm, không phải hình đó, hình dưới này nha anh em ?

Quy trình từ lúc khách hàng đặt bánh pizza đến khi ăn bánh pizza. (Nguồn ảnh: BusinessProcessIncubator.com)

2. Tại sao nó quan trọng?

BPMN là một trong những vũ khí tối quan trọng của anh em nào làm BA. Vì sao? Vì trong công việc, mình phải tiếp cận và lắng nghe rất nhiều quy trình nghiệp vụ của khách hàng. 

Lắng nghe xong, nhiệm vụ của anh em là phải document lại. Mà mỗi khách hàng mỗi khác nhau, mỗi quy trình mỗi phức tạp. Document sao cho gọn, cho dễ đọc mà vẫn đảm bảo được nội dung gốc ban đầu? BPMN chính là câu trả lời.

Chỉ khi anh em thật sự hiểu được khách hàng, hiểu được quy trình họ làm hằng ngày. Thì mình mới nhìn nhận ra được, đâu là điểm chưa tối ưu trong quy trình của họ.

Và không chỉ có một mình mình cần hiểu, BA phải truyền đạt lại những “hiện trạng” và yêu cầu của khách hàng cho cả team cùng hiểu. Khi đó, BPMN là phương pháp tối ưu nhất để truyền đạt lại mớ bồng bông các quy trình này.

Có lần mình làm dự án cho khách hàng là 1 công ty nhà nước. Phải nói quy trình của khách hàng này là mother of lộn xộn, tuầy huầy, tùm lum tùm la hết. Một mớ công văn, một mớ giấy tờ. Mà bản nào cũng 5-6 trang A4.

Quy trình của họ thể hiện bằng chữ trong văn bản. Đọc thì cũng hiểu thôi. Nhưng khi số lượng quy trình ngày một tăng thì càng đọc càng rối ?

Chưa kể các quy trình không bao giờ đứng riêng lẻ, mà luôn kết nối với nhau. Output của thằng này sẽ luôn là input của thằng tiếp theo.

Một khi quy trình thể hiện bằng văn bản, thì phải nói là rất khó cho team để mapping các quy trình lại với nhau. Vì đọc chữ sẽ tốn sức hơn nhiều so với xem hình ảnh. Chưa kể đọc xong phải mường tượng luồng đi của quy trình, rồi từ đó mới mapping được.

Thế là team mất gần cả tháng trời để tổng hợp, phân loại và sắp xếp nó cho ra hồn, rồi mới modeling bằng BPMN được. Giờ nghĩ lại vẫn còn thấy ớn ớn…

3. BPMN dành cho những ai?

Nói theo kiểu ba láp ba xàm thì già trẻ, lớn bé, đẹp chai, đẹp gái gì cũng dùng BPMN được hết, vì nó khá là dễ. Còn nói theo kiểu đàng quàng thì BPMN dành cho cả người dùng high level lẫn lower level đọc.

High level là sao? Họ là những người quản lý tầng trên, họ chỉ cần care đến bức tranh tổng quan, và nắm được trong đó có những quy trình nào là chủ yếu.

High Level chỉ cần quan tâm, để ra được báo giá thì cần có mấy bước, tương tác với những đối tượng nào, hoặc có những document nào liên quan…

Còn lower level là những người dùng trực tiếp, họ follow theo quy trình để làm. Do đó, BPMN cho những đối tượng này thường rất chi tiết và cover được toàn bộ các trường hợp có thể xảy ra.

4. Bà con với UML?

Mình thấy có nhiều anh em hay nhầm BPMN với UML. Hồi xưa mình cũng hay nhầm, nhưng giờ chịu khó google nên cũng phân biệt được hai anh này.

UML là Unified Modeling Language – ngôn ngữ mô hình thống nhất. Tên tiếng Việt dịch ra nghe hơi chuối, nên thôi anh em cứ đọc là UML cho chắc. Nôm na, UML là tập hợp các diagram và các ký hiệu để mô tả phần mềm. Nôm na là như vậy.

Anh em nghe có thấy nó giống với BPMN hông. Cơ bản cũng là mấy cái hình vẽ thôi, nhưng mục đích của nó lại khác nhau.

Trong khi BPMN hướng tới quy trình nghiệp vụ,

thì UML hướng tới việc xây dựng phần mềm.

Cụ thể, BPMN tiếp cận theo hướng process-oriented, còn UML thì tiếp cận theo hướng object-oriented.

• Process-oriented là tập trung trả lời cho câu hỏi: khách hàng phải làm bao nhiêu bước, đó là những bước gì, trong thời gian bao lâu để hoàn thành được công việc, mục tiêu.
• Còn Object-oriented tập trung cho việc mổ xẻ một đối tượng theo nhiều góc nhìn, chiều kích khác nhau để rõ ràng hơn cho việc thiết kế và xây dựng hệ thống.

Do đó, để có nhiều góc nhìn khác nhau, thì UML có hẳn một bộ các diagram khác nhau. Mỗi diagram có một chức năng riêng. Ví dụ lấy đối tượng Customer ra mổ xẻ. Anh em có thể mô hình hóa được đối tượng Customer này (bằng UML) ở nhiều khía cạnh khác nhau:

• Customer có những thuộc tính gì, mối quan hệ giữa đối tượng Customer và các đối tượng khác ra sao (Class Diagram).
• Customer có thể làm được những tính năng gì, tương tác với hệ thống và các đối tượng khác ra sao (Use Case Diagram).
• Hoạt động của Customer theo trình tự thời gian là như thế nào (Sequence Diagram).
• Và còn rất nhiều khía cạnh với nhiều diagram khác nữa, mình sẽ nói ở bài sau nhé anh em.

Còn BPMN, như anh em thấy chỉ có 1 diagram duy nhất. Bởi vì nó chỉ có 1 mục đích duy nhất: thể hiện được quy trình nghiệp vụ.

Tóm lại, UML và BPMN là hai khái niệm hoàn toàn khác nhau. Nó không tương phản mà lại ăn nhậu rất hợp rơ với nhau. Trong dự án, anh em vừa phải dùng UML, vừa phải dùng BPMN thì document mới đầy đủ, và cover hết các khía cạnh được 🙂

Kể cho anh em chuyện này nghe mất hồn chơi.

Hồi xưa mình làm 1 dự án theo kiểu Agile… hơi nửa vời chút xíu :v Document làm toàn BPMN, và mình thề là nguyên bộ Solution Design không quá… 100 chữ. Vì chỉ toàn hình là hình. Nghĩ thế là khỏe, vì document quá tiện và gọn nhẹ.

Tuy nhiên vấn đề bắt đầu xuất hiện khi có change request, mà toàn liên quan tới những cái vặt vặt mới ghê. Ví dụ như message thông báo, nội dung email template, status của record…

Mà BPMN thì không thần thánh tới mức… cover được hết những tiểu tiết này. Nên hồi đó mình phải note chi chít các chi tiết nhỏ này vào quy trình BPMN. Khiến cho nó rối, sai quy tắc notation, và đặc biệt là rất… oải để đọc nó.

Và khi có change request, thì rất khó để anh em trace lại được những sự thay đổi. Những sự thay đổi mà BPMN không ghi nhận được, như những chi tiết nhỏ mình nói ở trên. Do đó, không phải cứ dùng BPMN là hay, cái gì lạm dụng quá cũng sẽ bị phản dam. Cũng may dự án đã Go-Live thành công, chứ không cả đám ăn cám hết.

Thường thì software implementation ít dùng UML nhiều như software development. Nhưng khi nảy sinh một yêu cầu mới cần phải build từ đầu, thì lấy UML ra dùng cũng là một sự lựa chọn không tồi. Đừng khư khư mãi vào BPMN nhé anh em.

BPMN tập trung vào quy trình, còn UML tập trung vào từng đối tượng cụ thể để phục vụ cho việc build phần mềm (Nguồn ảnh: bonkersworld.net)

5. BPMN cứu rỗi đời mình như thế nào?

Trước khi kết thúc bài này thì mình sẽ kể cho anh em nghe một câu chuyện hư cấu có thật.

Đó là lần team dự án mình gặp phải một kèo chua cay như gói mì hảo hảo.

Đây là một khách hàng B2B, vừa sản xuất vừa bán B2B luôn. Mà bán B2B thì quy trình duyệt giá cho một đơn hàng khá phức tạp. Vì giá trị đơn hàng là rất lớn, và phải luôn đảm bảo giá tốt nhất cho khách mua hàng.

Lần đó team mình qua phải 3, 4 lần gì mới lấy được requirement cụ thể cho quy trình làm báo giá này. Nó qua rất nhiều bước.

Từ lúc Salesperson nhận một yêu cầu hỏi hàng, sau đó sẽ làm báo giá cho khách hàng. Đa phần các báo giá đều sẽ được áp các mức chiết khấu mặc định, phụ thuộc vào khách hàng và số lượng sản phẩm khác nhau.

Nếu Salesperson không muốn giảm giá gì thêm thì họ sẽ gửi báo giá cho khách hàng duyệt. Nếu khách hàng đồng ý thì nhập ngày giao hàng (mà khách yêu cầu), rồi kiểm tồn kho (check on hand), và cuối cùng là làm Order. Nếu không đồng ý thì Salesperson phải deal lại ngày giao hàng.

Còn nếu Salesperson muốn có một mức giá tốt hơn mức giá chuẩn (tức là discount nhiều hơn mức discount chuẩn cho phép), thì Salesperson phải xin giá. Mà để xin giá thì phải raise yêu cầu cho Team Leader.

Tức là Salesperson sẽ nhập mức discount họ mong muốn. Sau đó chuyển qua Team Leader để duyệt giá chặng một. Team Leader sẽ dựa vào mức discount mà Salesperson đề xuất để duyệt giá.

Nếu mức discount làm cho giá trị của từng line sản phẩm vẫn cao hơn hoặc bằng giá vốn hàng bán (COGS), Team Leader sẽ tự cân đối revenue trong quý mà duyệt hoặc không.

Nếu mức discount mà Salesperson yêu cầu cao quá, làm cho giá trị của từng line sản phẩm thấp hơn cả giá vốn hàng bán (tức là bán chịu lỗ, không để mất khách) thì Team Leader không có quyền duyệt, mà phải đẩy lên Sales Manager để duyệt giá chặng hai. Anh sếp ảnh cho thì bán, không thì phải xin giá lại từ đầu.

Đó chỉ mới là bán hàng OBL (Own Brand Labelling), tức là hàng chuẩn, hàng mình tự sản xuất rồi bán. Còn bán hàng OEM thì phức tạp hơn. OEM là Orginal Equipment Manufacturing, tức là mình sản xuất theo thiết kế, yêu cầu đặc thù của khách hàng.

Ví dụ sản xuất 5000 cái bô dài 50 cm, rộng 40 cm, cao 30 cm, có in hình mặt cười nham nhở chẳng hạn.

Đối với hàng OEM thì phải đưa yêu cầu thiết kế qua bên R&D, rã ra BOM (bill of materials), rồi chạy Pilot (làm hàng mẫu). Nếu fail ở bước nào, thì quy trình trả về Salesperson, yêu cầu trao đổi lại với khách hàng.

Chạy Pilot xong mà khách hàng ok mẫu mã này nọ xong xuôi, thì tiếp tục tới phần giá như ở trên. Nhưng đâu dễ ăn của ngoại.

Vì là hàng OEM, nên cần phải phân rã BOM ra và đưa qua bộ kế toán để xin giá vốn hàng bán (vì là sản phẩm mới toanh nên đâu biết giá gốc bao nhiêu đâu mà bán).

Kể mệt quá, nghỉ xíu anh em.

Tức là cái bô có thành bô, miệng bô, thân bô. Mỗi bộ phân bao nhiêu tiền, ghép lại thành một cái bô, sẽ ra được giá gốc là bao nhiêu tiền. Rồi gom góp các loại chi phí sản xuất, môi trường, nhân công, điện nước này nọ. Ra được một mức giá, gọi là giá vốn hàng bán (COGS). Rồi mới đưa cái cục giá đó cho ông Salesperson, ổng sẽ lấy mức giá này để bắt đầu deal với khách hàng. Rồi đoạn deal phía sau, sẽ tiếp tục quy trình báo giá cho sản phẩm OBL như phía trên.

Đó là tóm tắt quy trình của khách hàng, bằng chữ. Anh em thấy quá mệt đúng không. Đưa một mớ này vô document chắc chả ai thèm đọc hết.

Khi đó, BPMN xuất hiện như một vị cứu tinh. Những notation của BPMN đều cover được hết quy trình bên trên.

Bấm hình dưới đây xem chi tiết nhé anh em.

Anh em thông cảm, hình hơi mờ. Chờ xíu cho nó load đủ >> bấm vào nút View Full Size để xem full HD.

Do đó, không có BPMN, mình cũng chả biết transfer lại quy trình này cho team như thế nào cho hiệu quả. Mặc dù mình vẫn có thể chế ra các ký hiệu để vẽ vời, miễn đáp ứng được yêu cầu trên.

Nhưng khi deliver tài liệu cho bất kỳ một stakeholders nào khác, chẳng lẽ lại phải mất công giải thích: cái ô vuông nghĩa là A, cái hình chữ nhật nghĩa là B. Như vậy rất tốn thời gian. Trong khi BPMN đã là một cái chuẩn, vẽ con mèo là mọi người hiểu ngay con mèo, không thể nào hiểu ra con chó được.

Do đó, in BPMN, we trust ?

6. Tạm kết

Mình sẽ tạm dừng bài 1 về BPMN ở đây. Qua bài này hi vọng anh em nắm được:

• BPMN là gì? (Business Process Modeling Notation)
• Tại sao nó lại quan trọng? (giúp BA document và transfer thông tin hiệu quả hơn)
• Dành cho đối tượng nào? (hầu hết là mọi người)
• BPMN khác với UML ra sao? (một ông làm về process, còn một ông làm về software)

Ở bài sau chúng ta sẽ đi chi tiết vào “BPMN in action”. BPMN gồm những thành phần gì và các nguyên tắc khi vẽ BPMN.

Nếu cảm thấy “con hàng” BPMN này có thể giúp ích nhiều được cho mình trong công việc, thì anh em có thể mạnh dạn tham khảo các khoá học BPMN ngắn hạn nhé.

Nó sẽ giúp anh em luyện cách nắm bắt thông tin và tạo điều kiện để có thể luyện tập vẽ ngày vẽ đêm, hết quy trình này đến quy trình khác. Phải luyện từ các quy trình thực tế, bài toán thực tế, mô hình thực tế như vầy thì mới lên tay được. Anh em có thể tham khảo khoá học BPMN từ Trung tâm BAC như mình đã có review ở đây nhé.

Hẹn gặp lại anh em ở note tiếp theo!