BPMS là gì? Giải thích về quản lý quy trình nghiệp vụ

BPMS, viết tắt của business process management system, là phần mềm dùng để mô hình hóa và thực thi các quy trình đã xác định, sau đó theo dõi công việc mà hệ thống vận hành. BPMS làm tốt việc thực thi: hệ thống áp dụng trình tự, giao nhiệm vụ và ghi lại những gì đã xảy ra. Nhưng BPMS khó cho bạn thấy bức tranh rộng hơn, vì hệ thống chỉ có thể thực thi và báo cáo phần công việc bạn giao cho nó.

Hướng dẫn này giải thích BPMS làm gì, năm thành phần bạn thực sự mua và giới hạn của hệ thống. Sau đó, bài viết so sánh phần mềm thực thi với process intelligence. Process intelligence để các hệ thống vốn đã làm tốt việc thực thi tiếp tục đảm nhiệm công việc đó, đồng thời kết nối dữ liệu của chúng vào một nơi để nhân viên và các công cụ AI của bạn cùng sử dụng.

BPMS là gì?

BPMS là viết tắt của Business Process Management System, tức hệ thống quản lý quy trình nghiệp vụ. Một số nhà cung cấp dùng tên Business Process Management Suite. Dù gọi theo cách nào, đây vẫn là nhóm phần mềm giúp xác định quy trình, điều phối công việc qua các bước và theo dõi quá trình thực thi.

BPM, hay quản lý quy trình nghiệp vụ, là phương pháp tìm hiểu, thiết kế, đo lường và cải tiến cách công việc được thực hiện. BPMS là một loại phần mềm có thể hỗ trợ phương pháp này. Bạn có thể áp dụng BPM mà không cần mua BPMS. Ngược lại, mua BPMS cũng không đảm bảo bạn đang quản lý quy trình hiệu quả.

Nhóm phần mềm này đã thay đổi theo thời gian. Ban đầu là các workflow engine, sau đó phát triển thành những bộ giải pháp có thêm tính năng mô hình hóa, biểu mẫu và giám sát. Ngày nay, nhóm này còn bao gồm các nền tảng low-code cho phép đội ngũ ghép thành ứng dụng quy trình hoàn chỉnh. Vì vậy, mỗi nhà cung cấp có thể mô tả BPMS theo một cách khác nhau. Khi đánh giá phần mềm quản lý quy trình nghiệp vụ, đừng quá chú trọng tên gọi. Hãy hỏi bốn điều quan trọng: phần mềm có mô hình hóa quy trình, thực thi quy trình, kết nối với các hệ thống liên quan và cho bạn biết các trường hợp đang chạy ra sao không?

BPMS gồm những thành phần nào?

Mỗi sản phẩm kết hợp các khả năng này theo cách khác nhau, nhưng một hệ thống quản lý quy trình nghiệp vụ thường có năm thành phần:

1. Công cụ mô hình hóa. Bạn xác định quy trình, thường bằng BPMN 2.0. Mô hình có thể mô tả luồng công việc và, trong hệ thống có khả năng thực thi, làm cơ sở để vận hành quy trình. Tìm hiểu thêm về công cụ mô hình hóa BPMN để biết cách thiết kế mô hình quy trình.
2. Execution engine. Engine tạo các trường hợp quy trình, đánh giá điều kiện, giao nhiệm vụ, khởi chạy bộ hẹn giờ và chuyển cấp các công việc quá hạn.
3. Biểu mẫu, quy tắc và vai trò. Các thành phần này xác định thông tin người dùng cần cung cấp, nhiệm vụ họ nhìn thấy và quy tắc áp dụng cho bước tiếp theo.
4. Tích hợp. Hệ thống trao đổi dữ liệu với các ứng dụng như ERP, CRM, kho dữ liệu và API gateway. Công việc tích hợp có thể chiếm phần đáng kể trong quá trình triển khai.
5. Giám sát và kho lưu trữ. Dashboard hiển thị trạng thái các trường hợp đang chạy. Kho lưu trữ giúp bạn quản lý phiên bản quy trình và kiểm soát thay đổi.

Workflow engine là một phần của bức tranh này. BPMS kết hợp engine với các công cụ và cơ chế kiểm soát cần thiết để xác định, hỗ trợ và giám sát một quy trình rộng hơn.

BPMS làm được gì mà tài liệu quy trình không làm được?

Tài liệu quy trình mô tả cách công việc nên diễn ra. BPMS có thể điều phối và theo dõi công việc theo các quy tắc đã cấu hình. Ví dụ, hệ thống có thể:

• Chuyển cấp nhiệm vụ đã chờ quá thời hạn quy định.
• Chuyển một trường hợp để phê duyệt khi đạt ngưỡng đã cấu hình.
• Ghi lại lộ trình của từng trường hợp.
• Cho phép bạn cập nhật luồng bằng cấu hình, thay vì phải sửa nhiều ứng dụng liên quan.

Các khả năng này hữu ích khi bạn cần điều phối nhất quán, phân định rõ người chịu trách nhiệm và theo dõi các trường hợp hệ thống vận hành. Tuy nhiên, điều đó không có nghĩa mọi phần của quy trình thực tế đều diễn ra trong BPMS. Nếu trước hết bạn cần ghi lại quy trình hoặc tìm hiểu cách quy trình đang vận hành, phần mềm thực thi có thể chưa phải lựa chọn phù hợp.

BPMS, workflow engine, RPA, process mining và process intelligence khác nhau thế nào?

Năm công nghệ này giải quyết những phần khác nhau trong quản lý quy trình. Bảng dưới đây cho biết mỗi công nghệ làm gì và giúp bạn trả lời câu hỏi nào.

RPA và BPMS tiếp cận việc thay đổi quy trình theo những cách khác nhau. RPA tự động hóa các nhiệm vụ trong quy trình hiện có. BPMS vận hành quy trình bạn đã xác định, qua đó có thể thay đổi cách điều phối công việc. Trước khi tự động hóa một nhiệm vụ, hãy xem liệu thiết kế lại quy trình có thể loại bỏ nhiệm vụ đó không. Tìm hiểu thêm về cách tìm cơ hội tự động hóa bằng process mining.

Process mining và BPMS cũng trả lời những câu hỏi khác nhau. Process mining phân tích dữ liệu sự kiện để cho thấy công việc thực sự đi qua các hệ thống như thế nào. BPMS thực thi luồng đã thiết kế và báo cáo về các trường hợp hệ thống xử lý. Sự khác biệt này rất quan trọng khi bạn cần kiểm tra mô hình có khớp với công việc thực tế hay không.

Process intelligence là hàng cuối trong bảng, đồng thời kết nối các công nghệ còn lại. Công nghệ này để hệ thống phù hợp nhất đảm nhiệm việc thực thi, đọc dữ liệu từ mọi hệ thống và duy trì một mô hình quy trình chung để đối chiếu với tất cả. BPMS báo cáo về các trường hợp của chính nó. Process intelligence báo cáo về toàn bộ quy trình, kể cả phần công việc không do một nền tảng riêng lẻ nào vận hành.

Vì sao một BPMS không thể vận hành mọi quy trình?

BPMS có vẻ như lời giải cho bài toán quản lý quy trình, cho đến khi bạn tính đến những hệ thống mà nó không kiểm soát. Một quy trình thực tế có thể đi qua ERP, CRM, công cụ quản lý yêu cầu, cổng thông tin nhà cung cấp, bảng tính và một vài hộp thư. Nền tảng chỉ vận hành phần bạn mô hình hóa bên trong nó. Phần còn lại vẫn diễn ra ở nơi khác.

Khoảng trống đó dẫn đến ba hệ quả bạn nên biết trước khi mua.

Bạn phải tự tạo workflow thay vì dùng lại chuẩn có sẵn. BPMS là một bộ công cụ, nên mỗi quy trình lại thành một dự án: bạn mô hình hóa biến thể riêng, tự đặt tên các bước và tự duy trì phiên bản luồng của mình, dù hàng nghìn tổ chức khác cũng vận hành quy trình tương tự. Thay vì dùng lại mô hình tham chiếu theo chuẩn ngành cho quy trình từ đơn hàng đến thu tiền, từ mua hàng đến thanh toán hoặc quản lý sự cố, mỗi tổ chức lại dựng lại chúng trong nền tảng riêng. Ngay cả hai phòng ban dùng chung một hệ thống cũng có thể tạo ra hai phiên bản khác nhau của cùng một quy trình.

Nền tảng ưu tiên thực thi dễ bỏ qua bức tranh rộng hơn. BPMS được đánh giá dựa trên những gì nó vận hành, nên sự chú ý và ngân sách thường dồn vào các luồng bên trong hệ thống. Những quy trình BPMS không vận hành, đặc biệt là quy trình đi qua nhiều nhóm, hệ thống và quốc gia, thường là những quy trình không ai chịu trách nhiệm. Tăng tốc phần việc được thực thi không đồng nghĩa với hiểu cách cả tổ chức vận hành.

BPMS luôn có giới hạn và dần phát sinh thêm ngoại lệ. Quy trình nào cũng có ngoại lệ: đơn hàng cần xử lý gấp, khách hàng VIP hay nhà cung cấp chỉ nhận email. Trong BPMS, mỗi ngoại lệ lại thành một nhánh cấu hình, một biểu mẫu, một tích hợp và một workflow cần duy trì. Nền tảng vốn được kỳ vọng giúp chuẩn hóa công việc dần chất đầy các trường hợp đặc biệt mà chỉ đội ngũ phụ trách hệ thống mới hiểu.

Những điều đó không có nghĩa BPMS là công cụ tệ. Nhưng BPMS không phù hợp để làm nguồn thông tin chuẩn duy nhất về các quy trình của bạn.

Quản lý quy trình nghiệp vụ trong IT và trong hoạt động kinh doanh

Khoảng trống lớn nhất nằm ở quản lý quy trình nghiệp vụ trong IT, nơi một công việc có thể đi qua hàng đợi yêu cầu, lịch thay đổi, nhiều ứng dụng và các bước phê duyệt giữa chúng. Không một phần mềm quản lý quy trình nghiệp vụ nào nhìn thấy đầy đủ cả bốn phần.

Trong hoạt động kinh doanh, khoảng trống tương tự xuất hiện dưới hình thức khác. Quy trình từ đơn hàng đến thu tiền, từ mua hàng đến thanh toán hay tiếp nhận nhân viên mới cũng đi qua nhiều hệ thống. Nhưng các bước thuộc về bộ phận vận hành chứ không phải bộ phận hỗ trợ dịch vụ, nên thời gian chờ được tính bằng ngày thay vì số yêu cầu. Lộ trình giữa các hệ thống cũng hiếm khi được ghi lại từ đầu đến cuối.

Sự khác biệt này ảnh hưởng đến lựa chọn phần mềm. Nền tảng quản lý dịch vụ được đánh giá dựa trên các yêu cầu nó xử lý, nên thời gian báo cáo chỉ tính đến ranh giới của chính nền tảng. Những phần quy trình diễn ra bên ngoài, như chờ nhà cung cấp phản hồi, kiểm tra tín dụng hay phê duyệt qua email, sẽ không thể thấy được từ bên trong. Dù bộ phận nào phụ trách quy trình, cách làm vẫn như nhau: dựng lại lộ trình từ dữ liệu sự kiện trong mọi hệ thống ghi nhận từng bước, rồi so sánh với luồng đã được ghi lại.

Có nên giữ BPMS dù hầu như không dùng?

Nhiều tổ chức mua BPMS vì execution engine nhưng rồi không dùng đến. Việc triển khai kéo dài hơn dự kiến, đối tác cấu hình những luồng đầu tiên, còn bộ phận kinh doanh vẫn làm việc trên các hệ thống sẵn có. Cuối cùng, chỉ còn vài người mở công cụ mô hình hóa đã mua giấy phép để vẽ sơ đồ, trong khi tổ chức vẫn trả phí duy trì cho một môi trường thực thi không ai khởi chạy.

Đây là lúc cần tách riêng hai nhiệm vụ mà nền tảng gộp chung. Workflow engine được thiết kế để thực thi công việc, còn kho mô hình dùng để lưu kiến thức quy trình. Nếu chỉ có nhiệm vụ thứ hai được thực hiện, bạn đang trả tiền cho một nền tảng thực thi để dùng làm công cụ tài liệu. Cách này vừa cồng kềnh, vừa đòi hỏi chuyên môn kỹ thuật, lại tốn kém.

Nếu phần lớn điều trên đúng, bạn đang yêu cầu nền tảng thực thi làm công việc quản lý kiến thức mà nó vốn không được thiết kế để đảm nhiệm. Giải pháp không phải là tăng thêm tài nguyên thực thi. Hãy chuyển kiến thức sang một công cụ chuyên làm trung tâm lưu trữ: một nơi tập hợp mọi quy trình, kết nối dữ liệu từ mọi hệ thống và giúp người dùng cùng các trợ lý AI dễ dàng tra cứu, mà không cần vận hành môi trường thực thi.

Giữ BPMS cho những quy trình mà nó thực sự vận hành. Chuyển kiến thức quy trình sang nơi có thể phát triển mà không phải chờ mỗi đợt phát hành.

Process intelligence khác BPMS như thế nào?

Việc không có chức năng thực thi là lựa chọn có chủ đích, không phải thiếu sót. Process intelligence không thực thi vì có nhiều hệ thống có thể đảm nhiệm việc đó, và nền tảng bạn đang sở hữu hiếm khi là lựa chọn tốt nhất. RPA, AI agent, hệ thống quản lý workflow, workflow tích hợp trong ERP và cả những đội ngũ trực tiếp làm việc đều phù hợp với những phần khác nhau. Công cụ vận hành công việc nên được chọn riêng cho nhiệm vụ đó.

Nhưng không thể để năm hệ thống tự quản lý kiến thức quy trình theo cách riêng. Nếu mỗi hệ thống thực thi giữ một sơ đồ quy trình khác nhau, sẽ không ai biết quy trình thực sự là gì, khách hàng đã trải qua biến thể nào hay nên tự động hóa bước nào tiếp theo. Tập trung kiến thức quy trình cho những người vận hành công việc và các trợ lý AI đang được giao xử lý công việc quan trọng hơn việc tự mình vận hành công việc đó.

Lợi thế nằm ở dữ liệu. BPMS báo cáo về các trường hợp của chính nó, còn nền tảng process intelligence kết nối dữ liệu sự kiện từ mọi hệ thống, kể cả công việc BPMS chưa từng thấy. Nền tảng này cũng có thể lưu một mô hình chung để đối chiếu BPMS, ERP và các công cụ tự động hóa.

Vì sao cần process mining để mô hình phản ánh thực tế?

BPMS có thể báo cáo về các trường hợp chạy bên trong hệ thống. Nhưng điều đó không có nghĩa hệ thống ghi lại mọi lộ trình mọi người đi qua để hoàn thành quy trình. Ba khoảng trống thường gặp là:

• Công việc diễn ra bên ngoài engine. Có người xử lý ngoại lệ qua email rồi cập nhật hệ thống sau. Trường hợp đó có thể trông như vẫn tuân thủ, dù công việc mất nhiều thời gian hơn mô hình thể hiện.
• Cùng một kết quả được tạo ra qua hệ thống khác. Các nhóm có thể dùng ERP, bảng tính hoặc cổng thông tin nhà cung cấp. Nếu công việc không được ghi vào BPMS, dashboard của hệ thống không thể cho thấy toàn bộ quy trình.
• Mô hình không theo kịp thực tế. Quy trình có thể chính xác khi mới được công bố, rồi dần thay đổi khi các nhóm áp dụng cách làm riêng. Nếu mất nhiều thời gian để cập nhật mô hình, những biến thể đó có thể tồn tại lâu dài.

Kết quả là một mô hình được quản lý tốt nhưng không còn phản ánh cách mọi người làm việc. Process mining giúp mô hình bám sát thực tế trở lại: công nghệ này đọc dữ liệu sự kiện mà các hệ thống vốn đã ghi lại, rồi dựng lại những lộ trình thực sự đã diễn ra, kể cả lộ trình chưa ai mô hình hóa.

Kiểm tra mức độ phù hợp so sánh mô hình quy trình với dữ liệu sự kiện để cho thấy điểm khác biệt giữa thiết kế và thực thi. Trong khi đó, process mining cho thấy các biến thể, độ trễ và công việc phải làm lại trong chính dữ liệu của bạn. Bài viết Vì sao nên kết hợp mô hình hóa quy trình với process mining giải thích vì sao không nên tách rời hai phần: điều bạn dự định và điều thực sự đã xảy ra.

Vì sao chúng tôi quyết định không xây dựng tính năng thực thi?

Đây là câu hỏi hợp lý dành cho một nền tảng quy trình: nếu bạn có thể mô hình hóa và theo dõi quy trình, sao không thực thi luôn? BPMS ra đời vì câu trả lời hiển nhiên là có thể. Chúng tôi chọn hướng khác, và đó là quyết định có chủ ý chứ không phải thiếu sót.

Trên thực tế, ProcessMind không bao giờ yêu cầu bạn giao quyền kiểm soát workflow. Các hệ thống bạn đang dùng vẫn tiếp tục thực thi, còn kiến thức về những gì chúng thực thi được tập trung và cập nhật thường xuyên. Nếu sau này bạn thay hệ thống thực thi, chẳng hạn đổi bot RPA sang AI agent hoặc thay workflow cũ bằng workflow mới, mô hình, lịch sử và số liệu đo lường vẫn được giữ nguyên. Vì sao chúng tôi tạo ra ProcessMind trình bày thêm về lý do đó.

ProcessMind kết hợp với BPMS như thế nào?

ProcessMind không phải BPMS và không thực thi công việc. BPMS, ERP hoặc nền tảng tự động hóa của bạn vẫn đảm nhiệm việc vận hành quy trình. Đó chính là mục tiêu: dùng hệ thống phù hợp nhất cho từng quy trình, đồng thời tập trung kiến thức về tất cả quy trình ở một nơi.

Đó là cách process intelligence được áp dụng trong thực tế:

• Trước khi xây dựng: Khai thác dữ liệu sự kiện từ các hệ thống liên quan để xem lộ trình thực tế, các biến thể và ngoại lệ. Mô hình hóa quy trình mục tiêu bằng BPMN 2.0, sau đó dùng mô phỏng quy trình để thử nghiệm thay đổi trước khi cấu hình workflow.
• Sau khi xây dựng: Tiếp tục khai thác dữ liệu để xem quá trình thực thi còn khớp với thiết kế không, và liệu cách xử lý tạm thời ở một nhóm có âm thầm trở thành quy trình mà mọi người đều làm theo hay không.

BPMS vận hành công việc. Process intelligence giúp xác định việc gì đáng để vận hành, đồng thời kiểm tra kết quả có khớp với quy trình mọi người thực sự làm theo không.

Khi nào nên chọn BPMS, RPA hoặc process intelligence?

Điểm khởi đầu phù hợp tùy thuộc vào những gì bạn đã biết và vấn đề cần giải quyết.

Bắt đầu với process intelligence khi:

• Mọi người không thống nhất về cách quy trình đang vận hành.
• Quy trình đi qua nhiều hệ thống và một phần công việc có thể diễn ra bên ngoài workflow chính.
• Bạn biết quy trình chậm nhưng chưa rõ lý do.
• Bạn đang có BPMS nhưng workflow engine không hoạt động, và muốn lưu kiến thức quy trình ở nơi hữu ích hơn.

Cân nhắc BPMS khi:

• Bạn đã hiểu quy trình và quy trình đủ ổn định để chuẩn hóa.
• Công việc đi qua nhiều nhóm và cần điều phối hoặc phân định trách nhiệm rõ ràng hơn khi bàn giao.
• Bạn cần áp dụng quy tắc và quản lý thay đổi mà không phải sửa nhiều ứng dụng cùng lúc.

Cân nhắc RPA khi:

• Quy trình ổn định và lặp đi lặp lại.
• Nhiệm vụ diễn ra đủ thường xuyên để xứng đáng được tự động hóa.
• Không thể thay đổi các ứng dụng, nhưng có thể tự động hóa bước đó thông qua giao diện của chúng.

Hai thói quen giúp bạn chọn đúng thứ tự: đo lường quy trình trước khi mua phần mềm thực thi, và kiểm tra xem thiết kế lại có thể loại bỏ nhiệm vụ trước khi tự động hóa hay không.

Làm sao đánh giá BPMS trước khi mua?

Bắt đầu với một quy trình có tên gọi rõ ràng và người chịu trách nhiệm cụ thể: từ đơn hàng đến thu tiền, từ mua hàng đến thanh toán, tiếp nhận nhân viên mới hoặc xử lý sự cố. Đừng đánh giá một lĩnh vực rộng như “vận hành” nếu chưa xác định quy trình cụ thể. Sau đó, thực hiện bốn bước.

1. Tìm dữ liệu sự kiện

   Kiểm tra hệ thống nào ghi lại quy trình và dữ liệu của chúng có mã trường hợp, hoạt động và dấu thời gian hay không. Công cụ quản lý quy trình nghiệp vụ mô tả luồng bạn dự định thực hiện, còn nhật ký sự kiện cho biết quy trình có thực sự diễn ra hay không.

2. So sánh thiết kế với những gì đã diễn ra

   Tìm các lộ trình, độ trễ và ngoại lệ mà mô hình chưa thể hiện. Thử ứng viên BPMS phù hợp nhất trên dữ liệu của chính bạn sẽ hữu ích hơn việc xem bảng tính năng, vì cách này cho thấy nền tảng thực sự kiểm soát được phần nào của quy trình.

3. Dựa vào bằng chứng để quyết định

   Kết quả có thể là BPMS, thiết kế lại quy trình, thay đổi một bước hoặc không cần làm gì cả. Hãy để kết quả tìm được quyết định công cụ, thay vì làm ngược lại.

4. Tiếp tục đo lường sau khi triển khai

   Nền tảng có thể báo cáo về các nhiệm vụ nó vận hành. Dữ liệu sự kiện từ các hệ thống cho bạn biết quy trình còn khớp với công việc thực tế hay không sau khi workflow đi vào hoạt động.

Nếu quy trình đi qua các hệ thống mà BPMS không kết nối được, những số liệu đầu tiên sẽ cho thấy điều đó. Đây là cơ sở để bạn quyết định có nên mua phần mềm thực thi hay không.