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 bạn bè : BPMN là gì, tại sao nó sinh ra, dành cho đối tượng người tiêu dùng nào. Và quan trọng hơn hết, BPMN được dùng cho mục tiêu 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 cụ thể hơn thì bạn bè 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 bạn bè 😄
Quy trình từ lúc người mua đặ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 Bất Động Sản cho người mua là 1 công ty nhà nước. Phải nói tiến trình của người mua 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ớ sách vở. 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ể những quy trình tiến độ không khi nào đứng riêng không liên quan gì đến nhau, mà luôn liên kết 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 tiến độ bộc lộ bằng văn bản, thì phải nói là rất khó cho team để mapping những quá 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 tiến độ, 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 trị tầng trên, họ chỉ cần care đến bức tranh tổng quan, và nắm được trong đó có những quá trình nào là hầu hết .
High Level chỉ cần chăm sóc, để ra được làm giá thì cần có mấy bước, tương tác với những đối tượng người dùng nào, hoặc có những document nào tương quan … Còn lower level là những người dùng trực tiếp, họ follow theo quá trình để làm. Do đó, BPMN cho những đối tượng người dùng này thường rất cụ thể và cover được hàng loạt những trường hợp hoàn toàn có thể xảy ra .

4. Bà con với UML ?

Mình thấy có nhiều đồng đội 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 tiêu 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 bạn bè 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 yếu tố mở màn Open khi có change request, mà toàn tương quan tới những cái vặt vặt mới ghê. Ví dụ như message thông tin, 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 những cụ thể nhỏ này vào tiến trình BPMN. Khiến cho nó rối, sai quy tắc notation, và đặc biệt quan trọng là rất … oải để đọc nó .
Và khi có change request, thì rất khó để đồng đội trace lại được những sự đổi khác. Những sự biến hóa mà BPMN không ghi nhận được, như những chi tiết cụ thể 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 Bất Động Sản đã Go-Live thành công xuất sắc, 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 phát sinh một nhu yế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é bạn bè .

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 bạn bè nghe một câu truyện hư cấu có thật .
Đó là lần team dự án Bất Động Sả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 người mua B2B, vừa sản xuất vừa bán B2B luôn. Mà bán B2B thì quy trình tiến độ 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 bảo vệ 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 đơn cử cho quá trình làm làm 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 phong cách thiết kế, nhu yếu đặc trưng của người mua .
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ở ví dụ điển hình .

Đố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à người mua ok mẫu mã này nọ xong xuôi, thì liên 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).

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 cụ thể nhé bạn bè .
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 tiến độ này cho team như thế nào cho hiệu suất cao. Mặc dù mình vẫn hoàn toàn có thể chế ra những ký hiệu để vẽ vời, miễn cung ứng được nhu yế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 lý giải : 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 hạn. 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 hy vọng đồng đội 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)

Okayyy, hẹn anh em 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. Bái baiii.

Like this:

Like

Loading…

Bài viết liên quan