Bài 18 — BPMS comparison — Camunda, Bizagi, Flowable

Mở đầu — vì sao bài này quan trọng

Trong các bài trước, bạn đã làm quen với các công cụ automation nhẹ nhàng như Zapier, Make, n8n, và bạn cũng đã nghe nhắc tới khái niệm orchestration. Nhưng khi một doanh nghiệp lớn lên — một ngân hàng phải xử lý quy trình phê duyệt khoản vay qua bảy phòng ban, một công ty bảo hiểm phải điều phối quy trình bồi thường kéo dài nhiều tuần với hàng chục bước con người và hệ thống đan xen — thì những công cụ "kết nối ứng dụng" đơn giản không còn đủ. Lúc này bạn cần một nền tảng quản lý quy trình nghiệp vụ thực thụ: BPMS (Business Process Management System).

BPMS không chỉ là automation. Nó là nơi bạn mô hình hóa quy trình bằng một ngôn ngữ chuẩn (BPMN), giao việc cho con người qua các task list, áp dụng luật nghiệp vụ phức tạp, theo dõi từng instance đang chạy, và đo lường hiệu suất quy trình theo thời gian. Đây là xương sống số hóa của những tổ chức nghiêm túc về chuyển đổi số.

Vấn đề là: thị trường BPMS có hàng chục nền tảng, và việc chọn sai có thể khiến doanh nghiệp tốn hàng tỷ đồng license cùng nhiều tháng triển khai mà vẫn không phù hợp. Bài này tập trung so sánh ba nền tảng tiêu biểu, đại diện cho ba triết lý khác nhau: Camunda (developer-centric, open-source mạnh), Bizagi (low-code, nghiệp vụ dẫn dắt), và Flowable (open-source, nhẹ và linh hoạt). Hiểu rõ ba cái này, bạn sẽ có khung tư duy để đánh giá bất kỳ BPMS nào khác.

Khái niệm cốt lõi

BPMS là gì và khác gì với RPA/iPaaS

Trước khi so sánh, hãy định vị cho rõ. RPA (như UiPath) tự động hóa thao tác giao diện — bot bắt chước con người click chuột, gõ phím. iPaaS (như Zapier, Make) kết nối ứng dụng qua API. Còn BPMS điều phối toàn bộ quy trình end-to-end, bao gồm cả bước con người (human task) lẫn bước hệ thống (service task), với khả năng theo dõi trạng thái của từng quy trình đang chạy.

Trái tim của mọi BPMS hiện đại là hai chuẩn:

• BPMN 2.0 (Business Process Model and Notation): ngôn ngữ đồ họa chuẩn quốc tế để vẽ quy trình. Các hình tròn (event), hình thoi (gateway — điểm rẽ nhánh), hình chữ nhật bo góc (task) tạo nên một sơ đồ mà cả người nghiệp vụ lẫn lập trình viên đều đọc được. Quan trọng hơn, sơ đồ này chạy được — engine đọc file XML BPMN và thực thi đúng theo đó.
• DMN (Decision Model and Notation): chuẩn để mô hình hóa các quyết định nghiệp vụ dưới dạng bảng (decision table). Ví dụ "nếu thu nhập > 30 triệu VÀ điểm tín dụng > 600 thì duyệt" — thay vì viết cứng trong code, bạn để trong một bảng DMN mà chuyên viên nghiệp vụ có thể chỉnh.

Camunda — sức mạnh dành cho developer

Camunda khởi nguồn từ dự án Activiti và tách ra năm 2013, nhanh chóng trở thành BPMS open-source được giới lập trình viên yêu thích nhất. Triết lý của Camunda là "process orchestration cho developer": cung cấp một engine BPMN/DMN cực mạnh, mã nguồn mở, để developer nhúng vào ứng dụng Java/Spring của họ.

• Hai thế hệ song song. Camunda 7 (Platform) là engine truyền thống, nhúng vào ứng dụng Java, dùng database quan hệ, rất phổ biến và ổn định — nhưng đã bước vào giai đoạn cuối vòng đời (end-of-life dự kiến 2025–2027 tùy phiên bản). Camunda 8 là kiến trúc cloud-native hoàn toàn mới, dựa trên engine Zeebe — một workflow engine phân tán, không dùng database quan hệ truyền thống mà dùng event streaming, cho phép scale ngang để xử lý hàng triệu instance.
• BPMN 2.0 + DMN 1.3 được hỗ trợ đầy đủ, chuẩn mực. Camunda nổi tiếng vì độ "đúng chuẩn" và bộ công cụ modeler (Camunda Modeler) miễn phí, mạnh.
• Mô hình open-source + commercial. Engine core mở, nhưng các tính năng vận hành cấp doanh nghiệp (Operate, Tasklist, Optimize, connectors quản lý) nằm trong bản thương mại. Camunda 8 chủ yếu hướng tới SaaS và self-managed có license.
• Điểm mạnh: linh hoạt tối đa, kiểm soát code, cộng đồng developer lớn, phù hợp khi quy trình cần tích hợp sâu với microservices.
• Điểm yếu: đòi hỏi năng lực kỹ thuật cao; người nghiệp vụ thuần túy khó tự xây ứng dụng end-to-end mà không có developer đi kèm.

Bizagi — low-code cho người nghiệp vụ

Bizagi đến từ một góc tiếp cận ngược lại: lấy người nghiệp vụ làm trung tâm. Trên thị trường, Bizagi nổi tiếng với bộ Bizagi Modeler miễn phí (rất nhiều doanh nghiệp Việt dùng chỉ để vẽ BPMN), và nền tảng Bizagi Platform low-code để biến sơ đồ thành ứng dụng chạy được mà ít phải viết code.

• Low-code thực thụ. Bạn vẽ quy trình, định nghĩa form bằng giao diện kéo thả, gắn business rule qua expression builder, và Bizagi tự sinh ra ứng dụng web có giao diện cho người dùng cuối. Một business analyst có thể tự làm được phần lớn công việc.
• Mạnh về form và data model. Bizagi quản lý một data model trung tâm, gắn chặt với quy trình — phù hợp các quy trình "heavy" về biểu mẫu và phê duyệt nhiều cấp (đặc trưng của ngân hàng, bảo hiểm, khu vực công).
• Mô hình thương mại đóng. Bizagi không open-source; bạn mua license theo người dùng/quy trình. Modeler thì miễn phí nhưng engine (Studio + Automation) là sản phẩm thương mại.
• Điểm mạnh: thời gian triển khai nhanh cho quy trình phê duyệt, ít phụ thuộc developer, hỗ trợ doanh nghiệp tốt.
• Điểm yếu: kém linh hoạt khi cần logic tùy biến sâu hoặc tích hợp microservices phức tạp; chi phí license có thể cao; bị "khóa" vào hệ sinh thái Bizagi.

Flowable — open-source nhẹ, linh hoạt

Flowable là một nhánh fork từ Activiti (cùng gốc với Camunda thuở ban đầu), ra đời năm 2016 do chính nhóm core developer của Activiti lập nên. Flowable định vị mình là nền tảng open-source toàn diện nhưng gọn nhẹ, dễ nhúng.

• Ba chuẩn trong một engine: BPMN (quy trình), DMN (quyết định) và CMMN (Case Management Model and Notation — dành cho quy trình "không xác định trước", linh hoạt theo tình huống, ví dụ xử lý hồ sơ điều tra hay khiếu nại). Khả năng CMMN là điểm phân biệt đáng giá của Flowable.
• Apache 2.0 license cho phần core — rất "thoáng", doanh nghiệp có thể tự host miễn phí. Có thêm Flowable Enterprise với các module quản trị, form builder, modeling work cấp doanh nghiệp.
• Nhẹ và dễ nhúng vào ứng dụng Spring Boot, footprint nhỏ, khởi động nhanh — phù hợp cả startup lẫn nhúng vào sản phẩm SaaS.
• Điểm mạnh: miễn phí thực sự cho phần lớn nhu cầu, hỗ trợ case management, linh hoạt như Camunda nhưng license dễ chịu hơn.
• Điểm yếu: cộng đồng nhỏ hơn Camunda, tài liệu và hệ sinh thái connector chưa phong phú bằng; bản enterprise ít "tên tuổi" trên thị trường lớn.

Bảng so sánh nhanh

Tình huống thực tế

Tình huống 1 — Ngân hàng số tại TP.HCM chọn Camunda 8 cho luồng mở tài khoản

Một ngân hàng số (neobank) tại Việt Nam, giả định tên VietDigi Bank, đang xây luồng eKYC mở tài khoản online. Quy trình gồm: khách nộp giấy tờ → OCR trích xuất → đối chiếu khuôn mặt → kiểm tra danh sách đen → phê duyệt tự động hoặc chuyển nhân viên review. Họ kỳ vọng 50.000 hồ sơ mỗi ngày vào mùa cao điểm.

Đội kỹ thuật của VietDigi đã có sẵn hệ thống microservices viết bằng Java Spring Boot, mỗi service (OCR, face-match, AML check) là một API riêng. Họ chọn Camunda 8 vì hai lý do: engine Zeebe scale ngang được để chịu tải hàng chục nghìn instance đồng thời, và mô hình orchestration của Camunda khớp tự nhiên với kiến trúc microservices — mỗi service task trong BPMN gọi tới một microservice qua connector. Sau ba tháng, họ vận hành luồng với khả năng theo dõi từng hồ sơ qua công cụ Operate, và khi một bước fail (ví dụ OCR timeout), engine tự retry theo cấu hình.

Bài học: khi tổ chức đã trưởng thành về kỹ thuật và cần điều phối microservices ở quy mô lớn, một engine cloud-native developer-centric như Camunda 8 là lựa chọn hợp lý — đổi lại bạn phải có đội developer đủ mạnh.

Tình huống 2 — Công ty bảo hiểm chọn Bizagi cho quy trình bồi thường

Một công ty bảo hiểm tầm trung, giả định An Phúc Insurance, muốn số hóa quy trình bồi thường (claim) vốn đang chạy bằng email và Excel. Quy trình có 12 bước phê duyệt qua nhiều phòng (giám định, y tế, tài chính, pháp lý), nhiều biểu mẫu, và các luật nghiệp vụ thay đổi liên tục theo sản phẩm bảo hiểm.

Đội IT của họ chỉ có 4 người, nhưng phòng nghiệp vụ có nhiều business analyst giỏi. Họ chọn Bizagi vì các BA tự vẽ được quy trình, tự thiết kế form phê duyệt, tự cấu hình rule "claim dưới 20 triệu thì giám định viên duyệt thẳng, trên 20 triệu phải qua trưởng phòng" — mà không cần chờ developer. Trong 6 tuần, họ đưa được luồng claim cơ bản lên production. Khi chính sách thay đổi, BA tự sửa decision table thay vì mở ticket cho IT.

Bài học: khi quy trình nặng về biểu mẫu, phê duyệt nhiều cấp và logic nghiệp vụ thay đổi thường xuyên, trong khi đội IT mỏng, một nền tảng low-code như Bizagi giúp rút ngắn thời gian và giảm phụ thuộc vào lập trình viên. Đánh đổi là chi phí license và sự ràng buộc vào hệ sinh thái đóng.

Tình huống 3 — Startup logistics chọn Flowable để tiết kiệm và nhúng vào sản phẩm

Một startup logistics tại Singapore phục vụ thị trường Đông Nam Á, giả định SwiftCargo, đang xây nền tảng SaaS quản lý giao nhận. Họ cần một workflow engine để khách hàng (các công ty vận tải) tự định nghĩa quy trình duyệt đơn hàng của riêng mình, đồng thời có những hồ sơ "case" linh hoạt như xử lý sự cố hàng hỏng — không theo luồng cố định.

Ngân sách startup eo hẹp, không muốn trả license đắt, và cần nhúng engine thẳng vào ứng dụng Spring Boot của mình. Họ chọn Flowable vì: license Apache 2.0 miễn phí, footprint nhẹ nên nhúng dễ, và đặc biệt hỗ trợ CMMN cho các case xử lý sự cố không theo trình tự cứng. Họ tự host trên cluster Kubernetes của mình, không tốn phí bản quyền nào ngoài hạ tầng.

Bài học: với startup hoặc nhà cung cấp SaaS cần nhúng engine, ưu tiên chi phí và cần case management linh hoạt, Flowable cho cân bằng tốt giữa sức mạnh và tính kinh tế — đánh đổi là hệ sinh thái và cộng đồng nhỏ hơn.

Hướng dẫn từng bước

Đây là quy trình tư duy để chọn BPMS cho một tình huống thực tế:

• Phân loại bản chất quy trình. Quy trình của bạn là structured (cố định, lặp lại như mở tài khoản) hay unstructured/case-based (linh hoạt như xử lý khiếu nại)? Nếu nhiều case linh hoạt, ưu tiên nền tảng có CMMN (Flowable).

• Đánh giá năng lực đội ngũ. Bạn có đội developer mạnh hay chủ yếu là business analyst? Developer mạnh → Camunda/Flowable. BA dẫn dắt, IT mỏng → Bizagi hoặc các low-code khác.

• Xác định quy mô và mô hình tải. Hàng chục nghìn instance đồng thời, cần scale ngang → kiến trúc cloud-native như Camunda 8 (Zeebe). Quy mô vừa, nội bộ → engine truyền thống là đủ.

• Cân nhắc mô hình license và ngân sách. Ngân sách hạn chế, muốn tự host miễn phí → Flowable (Apache 2.0) hoặc Camunda 7 community. Sẵn sàng trả để có hỗ trợ và tốc độ → Bizagi hoặc Camunda enterprise.

• Kiểm tra mức độ tích hợp. Cần điều phối nhiều microservices/API → Camunda mạnh nhất ở mảng orchestration. Quy trình chủ yếu nội bộ với form → Bizagi tiện hơn.

• Làm Proof of Concept (PoC). Đừng chọn trên giấy. Lấy MỘT quy trình thật, vừa phải, dựng thử trên 1–2 nền tảng trong 2–3 tuần. Đo thời gian xây, độ khó vận hành, và phản hồi của người dùng cuối.

• Đánh giá tổng chi phí sở hữu (TCO). Cộng cả license, hạ tầng, chi phí nhân sự vận hành và đào tạo trong 3 năm — không chỉ nhìn giá license năm đầu.

Lỗi thường gặp & mẹo

• Lỗi: chọn theo "thương hiệu" hoặc theo lời chào hàng. Nhiều doanh nghiệp mua nền tảng đắt tiền chỉ vì vendor thuyết phục giỏi, rồi nhận ra đội ngũ không đủ năng lực dùng. Mẹo: luôn làm PoC với quy trình thật trước khi ký hợp đồng.

• Lỗi: nhầm Modeler với Platform. Cả Bizagi Modeler lẫn Camunda Modeler đều miễn phí và chỉ để vẽ BPMN. Engine thực thi mới là phần tốn tiền và công sức. Đừng nghĩ "dùng Bizagi Modeler miễn phí được rồi" mà quên rằng chạy production cần license platform.

• Lỗi: dùng BPMS cho việc mà RPA/iPaaS làm tốt hơn. Nếu bạn chỉ cần đồng bộ dữ liệu giữa hai app, một Zap đơn giản là đủ — đừng kéo cả một BPMS nặng nề vào. BPMS dành cho quy trình end-to-end có human task và cần theo dõi state.

• Lỗi: bỏ qua giai đoạn cuối vòng đời (EOL). Nhiều dự án mới vẫn chọn Camunda 7 vì quen thuộc, mà quên nó đang tiến tới EOL. Mẹo: với dự án dài hạn, ưu tiên kiến trúc còn được đầu tư lâu dài (Camunda 8).

• Mẹo: tách quyết định ra DMN ngay từ đầu. Đừng nhúng luật nghiệp vụ (lãi suất, hạn mức, điều kiện duyệt) vào code. Đặt trong decision table DMN để người nghiệp vụ tự chỉnh — đây là một trong những lợi ích lớn nhất của BPMS hiện đại.

• Mẹo: chuẩn hóa bằng BPMN dù chọn nền tảng nào. Vì cả ba đều theo chuẩn BPMN 2.0, sơ đồ quy trình của bạn có tính khả chuyển nhất định. Đầu tư vào việc mô hình hóa đúng chuẩn giúp giảm rủi ro khóa nhà cung cấp (vendor lock-in).

Bài tập thực hành

• Lập ma trận quyết định. Chọn một quy trình thật trong tổ chức bạn (hoặc giả định: quy trình phê duyệt nghỉ phép). Cho điểm Camunda, Bizagi, Flowable trên 5 tiêu chí: năng lực đội ngũ, ngân sách, độ phức tạp tích hợp, quy mô tải, nhu cầu case management. Kết luận nên chọn nền tảng nào và giải thích.

• Vẽ một sơ đồ BPMN. Tải Camunda Modeler hoặc Bizagi Modeler (đều miễn phí) và mô hình hóa quy trình "duyệt đơn hàng": nhận đơn → kiểm tra tồn kho (gateway: còn hàng / hết hàng) → nếu còn thì xác nhận, nếu hết thì thông báo khách. Lưu file .bpmn và quan sát XML sinh ra.

• Thiết kế một decision table (DMN). Tạo bảng quyết định duyệt khoản vay với hai input (thu nhập, điểm tín dụng) và một output (duyệt / từ chối / review thủ công). Liệt kê ít nhất 4 dòng quy tắc.

• Phân tích đánh đổi. Viết một đoạn 200 từ trả lời: "Vì sao một startup nhúng workflow vào sản phẩm SaaS thường chọn Flowable thay vì Bizagi?" — dựa trên license, kiến trúc và mô hình kinh doanh.

Tóm tắt

BPMS là nền tảng điều phối quy trình nghiệp vụ end-to-end, dựa trên hai chuẩn cốt lõi BPMN (quy trình) và DMN (quyết định), khác hẳn với RPA hay iPaaS về phạm vi và mục tiêu. Ba nền tảng tiêu biểu đại diện cho ba triết lý: Camunda mạnh về developer và orchestration microservices, với Camunda 8 cloud-native dựa trên engine Zeebe scale ngang; Bizagi là low-code lấy người nghiệp vụ làm trung tâm, lý tưởng cho quy trình phê duyệt nặng biểu mẫu khi đội IT mỏng; Flowable là open-source nhẹ với license Apache 2.0 thoáng, hỗ trợ thêm CMMN cho case management, phù hợp startup và nhà cung cấp SaaS.

Không có nền tảng "tốt nhất" tuyệt đối — chỉ có nền tảng phù hợp nhất với bản chất quy trình, năng lực đội ngũ, quy mô tải và ngân sách của bạn. Hãy luôn phân loại quy trình, đánh giá đội ngũ, làm PoC với quy trình thật, và tính TCO 3 năm trước khi quyết định. Và dù chọn nền tảng nào, hãy mô hình hóa đúng chuẩn BPMN và tách luật nghiệp vụ ra DMN — đó là cách bảo vệ khoản đầu tư của bạn khỏi rủi ro vendor lock-in và giúp quy trình dễ tiến hóa theo thời gian.