Đánh giá các ngôn ngữ mô hình hóa quy trình nghiệp vụ và đề xuất việc sử dụng ngôn ngữ BPMN trong ngân hàng

Hiện nay, có rất nhiều ngôn ngữ mô hình hoá được nghiên cứu và sử dụng trong thực tế. Mỗi ngôn ngữ mô hình hoá có đặc điểm, vai trò và mục đích sử dụng khác nhau. Trong bài báo này chúng tôi nghiên cứu các ngôn ngữ mô hình hoá quy trình nghiệp vụ dựa trên các tiêu chí về mặt kiến tạo và hiểu các mô hình cùng mức độ ứng dụng như tính rõ ràng của ký hiệu, tính phân biệt, khả năng hiểu ký hiệu, biểu diễn trực quan, tính phức tạp đồ họa và mức độ phù hợp để mô hình hoá quy trình nghiệp vụ ngân hàng. Chúng tôi nghiên cứu sự khác nhau giữa các ngôn ngữ mô hình hoá tiêu biểu: EPCs, Petri Net, UML và BPMN với các tiêu chí trên. Kết quả đánh giá cho thấy, ngôn ngữ BPMN là phù hợp hơn cả với việc mô hình hoá các quy trình nghiệp vụ trong lĩnh vực ngân hàng.

ThS. Phan Thanh Đức, Chủ nhiệm khoa Hệ thống thông tin quản lý, Học viện Ngân hàng

Thạc sỹ Phan Thanh ĐứcThạc sỹ Phan Thanh Đức hiện đang là giảng viên chính, chủ nhiệm khoa Hệ thống thông tin quản lý tại Học viện Ngân Hàng. Các lĩnh vực ông quan tâm bao gồm: Chính sách tiền tệ, Chính sách kinh tế, Dân số và phát triển, Dự án đầu tư, Dự án kinh tế, Toán cơ sở, Tin học ứng dụng, Tin học kinh tế. Bạn có thể tìm hiểu về ông qua website cá nhân: http://www.phanthanhduc.com



ThS. Lê Quý Tài, Giảng viên, Học viện Ngân hàng

Ảnh của Thạc sỹ Lê Quý TàiThạc sỹ Lê Quý Tài hiện đang là giảng viên khoa Hệ thống thông tin quản lý, Học viện Ngân hàng. Ông đảm nhiệm các môn học: Cơ sở lập trình, lập trình hướng đối tượng. Bạn có thể liên lạc và tìm hiểu thêm về ông qua trang web cá nhân: http://quytai.tk/



24 10 2013

Giới thiệu

Mô hình hoá quy trình nghiệp vụ có vai trò quan trọng trong việc tài liệu hoá và tổ chức các quy trình trong một hệ thống thông tin. Để thực hiện mô hình hoá các quy trình nghiệp vụ thì ngôn ngữ mô hình hoá là một thành phần thiết yếu. Ngôn ngữ mô hình hoá là ngôn ngữ được sử dụng để thể hiện thông tin hoặc một hệ thống trong một cấu trúc được xác định bởi một tập các quy tắc (xem phần Tài nguyên), các quy tắc này được sử dụng để giải thích ý nghĩa của các thành phần trong cấu trúc. Ngôn ngữ mô hình hoá có thể là ở dạng văn bản hoặc đồ họa. Có thể kể đến các ngôn ngữ như Petri Net, EPCs, UML, EEML hay gần đây là ngôn ngữ YAWL hay BPMN. Để thực hiện mô hình hoá quy trình nghiệp vụ cho một doanh nghiệp cụ thể thì lựa chọn ngôn ngữ mô hình hoá là một vấn đề hết sức quan trọng. Việc lựa chọn ngôn ngữ mô hình hoá nào hoàn toàn phụ thuộc vào bài toán cụ thể hay những khả năng của ngôn ngữ đó, từ việc hỗ trợ biểu diễn các trạng thái, các công việc, đồng bộ hoá v.v... đến việc sinh ra mã thực thi BPEL hay mức độ hỗ trợ cho các hệ quản trị quy trình nghiệp vụ như thế nào?

Điểm quan trọng trong việc nghiên cứu, sử dụng ngôn ngữ mô hình hoá chính là nghiên cứu quá trình nhận thức (xem phần Tài nguyên số 5), cụ thể là quá trình con người xử lý thông tin, tạo ra tri thức và giải quyết vấn đề. Bởi lẽ ngôn ngữ mô hình hoá sử dụng rất nhiều đến các ký tự đồ họa - nhân tố ảnh hưởng lớn đến khả năng nhận thức thông qua hình ảnh của con người. Đồng thời, các khái niệm được các biểu tượng đó diễn tả cũng có tác động không nhỏ đến cả khả năng nhớ ngắn hạn và dài hạn của con người. Mặt khác, khả năng mô hình hoá quy trình nghiệp vụ của mỗi ngôn ngữ còn phụ thuộc vào tập các ký tự và các khái niệm mà nó có thể biểu diễn. Đây chính là những điểm quan trọng cần xem xét khi đánh giá một ngôn ngữ mô hình hoá quy trình nghiệp vụ.

Có nhiều khung đánh giá các ngôn ngữ mô hình hoá quy trình nghiệp vụ. Anna Gunhild Nysetvold và John Krogstie (xem phần Tài nguyên số 2) đã phát triển một khung đánh giá chất lượng các ngôn ngữ mô hình hoá với 6 nhóm lĩnh vực với 32 tiêu chí đánh giá. Tác giả đã tiến hành chấm điểm các ngôn ngữ UML, BPMN, EEML. Kết quả cho thấy, về tổng thể BPMN có điểm số cao nhất. Jan Mendling và Jan Recker (xem phần Tài nguyên số 4) thì lại đánh giá các ngôn ngữ mô hình hoá với độ hữu dụng ngữ nghĩa của nhãn (label) và các biểu tượng (icon) có trong mô hình. K. Figl , J. Mendling , M. Strembeck (xem phần Tài nguyên số 5) thì lại đánh giá hiệu quả của các ngôn ngữ dựa trên việc hiểu mô hình bằng các ký hiệu trực quan. Bài viết này cũng dựa trên phương pháp và khung đánh giá của K. Figl và cộng sự (xem phần Tài nguyên số 5), bên cạnh đó, chúng tôi phát triển thêm tiêu chí đánh giá về độ phù hợp của ngôn ngữ mô hình hoá với việc mô hình hoá các quy trình nghiệp vụ trong lĩnh vực ngân hàng. Đóng góp chính của bài báo là việc nghiên cứu khung đánh giá và bình luận về ưu nhược điểm của các ngôn ngữ EPCs, UML, Petri Net, BPMN và đưa ra khuyến nghị về vấn đề nên sử dụng ngôn ngữ nào để mô hình hoá các quy trình nghiệp vụ ngân hàng.


Khung đánh giá các ngôn ngữ mô hình hoá quy trình nghiệp vụ

Các hình thức biểu diễn thông tin có ảnh hưởng lớn đến việc hiệu quả của vấn đề hiểu biết thông tin đó, tìm kiếm hay giải quyết vấn đề (xem phần Tài nguyên số 5). Do đó, một trong những mục tiêu thiết kế hình ảnh trực quan là làm cho người xem chú ý đến các thành phần quan trọng. Theo Moody và Hillersberg (xem phần Tài nguyên số 3) có 5 nguyên tắc về hiệu quả hiểu mô hình của các ký hiệu trực quan là: Tính rõ ràng của các ký hiệu, tính phân biệt của các ký hiệu, khả năng hiểu ký hiệu, biểu diễn trực quan và tính phức tạp đồ họa. Bên cạnh các tiêu chí này, chúng tôi cũng xem xét các ngôn ngữ cùng với độ phù hợp khi sử dụng khi mô hình hoá các quy trình nghiệp vụ trong lĩnh vực tài chính-ngân hàng.

Tính rõ ràng của các ký hiệu: Nguyên tắc này chỉ ra tầm quan trọng về sự phù hợp giữa các biểu tượng đồ họa được sử dụng trong mô hình và các khái niệm ngữ nghĩa mà chúng biểu diễn. Sẽ là bất bình thường nếu như có tình trạng nhiều biểu tượng cùng đại diện cho một khái niệm (dư thừa) hay một biểu tượng đại diện cho nhiều khái niệm (quá tải) hoặc có biểu tượng đồ họa mà lại không có khái niệm ngữ nghĩa tương ứng (thiếu hụt). Nên tránh tình trạng dư thừa hay thiếu hụt bởi sẽ gây nhập nhằng và khó hiểu không cần thiết cho người sử dụng. Do vậy, các ràng buộc của các ký tự đồ họa sẽ là mục tiêu số một của các ngôn ngữ mô hình hoá trực quan, bởi lẽ ký tự đồ họa sẽ làm nổi bật những mặt riêng có của thông tin trong mối quan hệ với các khía cạnh khác.

Tính phân biệt của các ký hiệu: Giúp người dùng nhận biết các ký hiệu và phân biệt sự khác nhau giữa các ký hiệu của ngôn ngữ. Đặc tính này chịu sự ảnh hưởng lớn bởi số lượng các ký hiệu khác nhau được sử dụng và “độ phân biệt” giữa các ký hiệu đó (khoảng cách trực quan - visual distance). Do vậy, nếu một ký hiệu thực sự khác biệt với các ký hiệu khác thì có thể dễ dàng được nhận ra trong mô hình. Nếu các ký hiệu có tính phân biệt thấp thì rất dễ đẫn đến việc hiểu nhầm ký hiệu. Chẳng hạn, nghiên cứu cho thấy ký hiệu hình chữ nhật và hình kim cương trong sơ đồ ER rất dễ bị nhầm lẫn. Hay nói cách khác, nếu các ký hiệu có các thuộc tính tương tự nhau như màu sắc, hình dạng thì được coi là có liên quan đến nhau. Theo luật Gestalt (xem phần Tài nguyên số 6) về độ tương tự thì các phần tử sẽ được nhóm với nhau nếu chúng có các thuộc tính tương tự nhau. Do đó, các ký hiệu trong các ngôn ngữ mô hình hoá cần có độ phân biệt cao, tránh sự nhầm lẫn hay nhập nhằng.

Khả năng hiểu ký hiệu: Đặc tính này giúp người dùng hiểu ý nghĩa và đại diện của các ký hiệu cùng các khái niệm liên quan và có thể gắn kết ký hiệu với khái niệm liên quan trong thực tế. Các ngôn ngữ mô hình hoá có thể sử dụng các ký hiệu khác nhau để biểu diễn các khái niệm trong thế giới thực. Theo nghiên cứu của Rockwell và Bajaj, mô hình biểu diễn sẽ có hiệu quả cao hơn nếu các biểu tượng sử dụng trong mô hình giống với “khái niệm cung mô tả nốt-mối quan hệ (node-relationship) trong biểu diễn thông tin” (xem phần Tài nguyên số 1).

Biểu diễn trực quan: Các ký hiệu được sử dụng trong các ngôn ngữ mô hình hoá thường sử dụng rất nhiều các đặc tính trực quan (như hình dạng, kích thước, màu sắc, độ sáng, kết cấu v.v...). Do vậy, để đánh giá một ngôn ngữ mô hình hoá thì việc đánh giá các ký hiệu biểu diễn cũng rất quan trọng.

Tính phức tạp đồ họa: Độ "phức tạp" của một mô hình phụ thuộc vào việc sử dụng các ký tự và sự khác biệt giữa các ký tự đó. Tuy nhiên, đôi khi sự phức tạp của các ký tự đồ họa lại làm giảm khả năng hiểu sơ đồ của người dùng. Hay nói cách khác, cần có sự cân bằng nhất định giữa độ phức tạp đồ họa và khả năng hiểu ký hiệu.

Độ phù hợp với lĩnh vực tài chính - ngân hàng: Xem xét ngôn ngữ có phù hợp với việc mô hình hoá các quy trình nghiệp vụ trong lĩnh vực tài chính - ngân hàng hay không? Cụ thể: Ngôn ngữ có được bổ sung các ký hiệu đặc thù để xây dựng các mô hình trong lĩnh vực này hay không? Mức độ hỗ trợ của ngôn ngữ?


Sự khác nhau giữa các ngôn ngữ mô hình hoá quy trình nghiệp vụ

Mỗi ngôn ngữ mô hình hoá bao gồm các thành phần cơ bản giúp người dùng định nghĩa các quy trình nghiệp vụ, các thành phần cơ bản thường là:

  • Start: Nút xác định điểm bắt đầu của một quy trình. Nút start có thể có một hoặc nhiều cạnh ra.
  • End: Nút xác định điểm kết thúc của một quy trình hoặc quy trình con (sub-process). Mỗi nút end chỉ có duy nhất một cạnh vào.
  • Tasks (tác vụ): Biểu diễn các tác vụ khác nhau của quy trình. Mỗi nút task thường xác định một hành động (action) hoặc một bước trong quy trình. Các nút task có thể do người dùng hoặc các tác nhân (agent) trong phần mềm điều khiển.
  • Decision (lựa chọn quyết định): Thể hiện các lựa chọn có trong quy trình.
  • Merge (tổng hợp): Nút tổng hợp những đường khác nhau là kết quả của các nút lựa chọn.
  • Split (tách): Có tác dụng chia quy trình thành các nhánh song song. Các quy trình con được tách ra sẽ hoạt động đồng thời.
  • Join (nối): Nối các quy trình con hoạt động song song, thông thường nút Join sẽ thực hiện đồng bộ các quy trình con được tách ra từ nút Split.
  • Event (sự kiện): Xác định sự xuất hiện của các sự kiện trong quy trình. Trong mô hình, các event thường dùng để kích hoạt các tác vụ, ngoài ra, trong mỗi tác vụ cũng có thể tạo ra các event để kích hoạt các tác vụ khác.

Petri Nets

Petri Nets là ngôn ngữ có ít ký hiệu nhất trong số các ngôn ngữ được so sánh trong bài viết này. Do đó, ngôn ngữ này gặp phải một vấn đề lớn về tính rõ ràng của các ký hiệu. Các thành phần lại biểu thị các hành vi khác nhau tuỳ thuộc vào số lượng cung vào và ra của thành phần đó. Ngôn ngữ này sử dụng 2 ký hiệu: hình chữ nhật cho các chuyển đổi (transition) và hình tròn dành cho các địa điểm (place).

Hình 1. Các ký hiệu cơ bản của Petri Nets
Các kí hiệu cơ bản của Petri Nets
Hình 2. Ví dụ mô hình quy trình nghiệp vụ với Petri Nets
Ví dụ mô hình quy trình nghiệp vụ với Petri Nets

Nhấp vào để xem ảnh lớn

Hình 2. Ví dụ mô hình quy trình nghiệp vụ với Petri Nets

Ví dụ mô hình quy trình nghiệp vụ với Petri Nets

EPCs

EPC chứa 3 loại biểu tượng: vòng tròn dành cho các kết nối, hình chữ nhật bo tròn cạnh cho các chức năng, và hình lục giác cho các sự kiện. Tuy nhiên, các sự kiện các khác nhau lại không có các ký hiệu khác nhau để biểu diễn, trong khi đó, EPC sử dụng các ký hiệu khác nhau dành cho các kết nối khác nhau. Chẳng hạn, ký hiệu × dành cho phép XOR, ˄ dành cho phép AND, ˅ dành cho phép OR. Ngoài ra, EPC có 2 cách để xác định các quy trình con, có thể bằng ký hiệu quy trình con ở góc dưới bên phải ký hiệu chức năng hoặc bằng các giao diện quy trình để bắt đầu các quá trình tiếp theo.

Hình 3. Các ký hiệu cơ bản của EPCs
Các kí hiệu cơ bản của EPCs

Nhấp vào để xem ảnh lớn

Hình 3. Các ký hiệu cơ bản của EPCs

Các kí hiệu cơ bản của EPCs

Tuy nhiên, EPC chỉ chứa một số ít các biểu tượng và có vấn đề trong việc sử dụng với nhiều điều kiện và tiêu chí khác nhau. Biểu tượng sự kiện (event) bị quá tải (overload) do biểu tượng này đại diện cho nhiều khái niệm, do đó gây ra vấn đề không rõ ràng; biểu tượng kết nối AND và OR khó phân biệt do cả hai đều dùng chung một biểu tượng và chỉ phản ánh theo chiều dọc. Nhìn chung, các ký hiệu của EPC rất trừu tượng, hơn nữa tính biểu diễn trực quan cũng rất hạn chế, do đó gây hạn chế về mặt nhận thức trực giác của người dùng (tuy cũng có một số công cụ thiết kế cho phép sử dụng màu để phân biệt các biểu tượng - như màu đỏ dành cho các chức năng, màu xanh lá cây dành cho các sự kiện v.v...

Hình 4. Ví dụ mô hình quy trình nghiệp vụ với EPC
Ví dụ mô hình quy trình nghiệp vụ với EPC

Ngôn ngữ mô hình hoạt động UML

Thành phần chính trong một mô hình hoạt động là các hoạt động (Activity). Hoạt động là một quá trình bao gồm các hành động (action) và các nút điều khiển (control node). Các hành động diễn tả các nhiệm vụ (task) hay các bước (step) được thực hiện khi thi hành Hoạt động tương ứng. Chẳng hạn, để mô hình (đồng bộ hay không đồng bộ các quá trình khác từ một hoạt động, ta có thể sử dụng biểu tượng hành động (action - hình chữ nhật bo tròn 4 góc) và biểu tượng Fork node hoặc join node (hình 3). Về bản chất, các thành phần mô hình hoá này giúp xác định sự tương tác lẫn nhau giữa các quy trình trong một mô hình hoạt động.

Các mô hình hoạt động thể hiện một mạng ngữ nghĩa (tương tự - nhưng không bằng Petri nets). Mỗi hoạt động có thể có một hoặc nhiều nút khởi tạo (Initial node) và một hoặc nhiều nút kết thúc (final node). Trong trường hợp luồng quy trình đạt đến nút kết thúc thì nó sẽ làm ngừng ngay lập tức việc thi hành các hành động và chấm dứt hoạt động tương ứng. Ngược lại nút kết thúc luồng (Flow Final) thì chỉ làm chấm dứt các luồng vào nó mà không kết thúc cả hoạt động. Nút lựa chọn điều kiện (Decision node) biểu diễn bằng một hình thoi có một đầu vào và nhiều đầu ra. Nút Merge thì ngược lại, có nhiều đầu vào và chỉ có duy nhất một đầu ra. Nút Fork được biểu diễn bằng một gạch thẳng đậm nét với một đầu vào và nhiều đầu ra, nút Join thì ngược lại với nhiều đầu vào và một đầu ra. Nút gửi tín hiệu (Send Signal) biểu diễn bằng ngũ giác lồi. Nút Accept Event Action được biểu diễn bằng 2 loại ký hiệu. ký hiệu ngũ giác lõm là dành để biểu diễn việc chờ một sự kiện cụ thể nào đó xuất hiện. Sự kiện ấy có thể là kết quả từ tín hiệu phát ra từ nút Send Signal. Trong khi đó, ký hiệu đồng hồ cát là biểu diễn của Accept Time Event Action.

Hình 5. Các thành phần cơ bản của ngôn ngữ hoạt động UML
Các thành phần cơ bản của ngôn ngữ hoạt động UML

Tuy nhiên, ngôn ngữ UML vi phạm một số tiêu chí do Moody đưa ra. Mặc dù các nút kết thúc (kết thúc hoạt động và kết thúc luồng trong hoạt động) có tự khác biệt rõ rệt nhưng các nút bắt đầu và kết thúc hoạt động lại có nét giống nhau. Điểm mạnh của UML là phân biệt tốt giữa các quyết định (decision) và đồng thời (concurrency), các thành phần định hướng này có sự khác nhau rõ rệt. Các nút Send Signal và Accept Event có sự gắn kết khá tốt, nhưng các nút còn lại thì vẫn còn tương đối trừu tượng.

Hình 6. Ví dụ mô hình quy trình nghiệp vụ với UML
Ví dụ mô hình quy trình nghiệp vụ với UML

Bất lợi lớn nhất của biểu đồ hoạt động là nó không thể hiện rõ ràng các mối quan hệ giữa các hoạt động và các đối tượng, điều này được thể hiện tốt hơn ở biểu đồ tương tác hoặc biểu đồ trạng thái.

Trong biểu đồ hoạt động, các đối tượng bị tác động bởi hành động của đối tượng khác không được chỉ ra rõ ràng. Bên cạnh đó, biểu đồ hoạt động cũng không chỉ ra được trường hợp các đối tượng khác nhau có thể thực hiện cùng một hành động (hoặc đối tượng này thực hiện hoặc đối tượng kia thực hiện) và trường hợp cùng một đối tượng có thể thực hiện một trong nhiều hành động (hoặc thực hiện điều này hoặc thực hiện điều kia).


BPMN

Hình dưới đây là các ký hiệu cơ bản của BPMN. BPMN sử dụng các loại sự kiện khác nhau để xác định điểm đầu và điểm cuối của một quy trình. Các kí tự cơ bản này có thể được mô tả mở rộng bằng nhiều ký hiệu khác. BPMN cũng sử dụng các ký hiệu khác nhau cho sự kiện kết thúc. Nút kết thúc (Terminal) sẽ chấm dứt toàn bộ các phần đang thực hiện (nếu có) trong quy trình. Nút thể hiện sự kiện Gửi (Send) và Nhận (Receive) được biểu diễn bằng các ký hiệu rỗng và đặc trong các hình tròn. Các nút này sử dụng hình phong bì thư khá trực quan. Các bước khác nhau trong một quy trình được gọi là các nhiệm vụ (task): chẳng hạn quy trình con nhúng (embedded sub-process) hoặc quy trình con thu gọn (collapsed sub-proccess). BPMN sử dụng các cổng (gateway) để thể hiện các ràng buộc. Các nút Join và Split của các cổng này đều sử dụng ký hiệu hình thoi để biểu diễn. Cổng XOR thì có thể được có hoặc không có dấu X còn cổng AND thì có dấu + ở bên trong.

Hình 7. Các thành phần cơ bản của BPMN
Các thành phần cơ bản của BPMN

Tuy vậy, BPMN cũng có một số điểm yếu, đôi khi gây lầm lẫn cho người đọc. Chẳng hạn, cổng XOR có thể được biểu diễn bằng nhiều ký hiệu (hình thoi rỗng hoặc hình thoi và dấu X. Hơn nữa, giữa các ký hiệu đôi khi có ít sự phân biệt rõ. Chẳng hạn, ký hiệu Start và End chỉ khác nhau ở viền của hình tròn (độ dày, đậm); cổng XOR có dấu X tương đối khó phân biệt với cổng AND có dấu +. Nhiều ký hiệu trong BPMN sử dụng độ sáng khác nhau để diễn tả các sự kiện khác nhau (chẳng hạn hình rỗng hay hình đặc v.v...). Hoa văn và màu sắc tuy không được sử dụng trong bộ ký hiệu chuẩn, nhưng các công cụ thiết kế vẫn thường đưa vào để làm nổi bật các nhiệm vụ. Các ký hiệu của BPMN không có sự phức tạp, cầu kỳ, trau chuốt về mặt đồ họa, nhưng BMPN lại có rất nhiều các biểu tượng và hàng loạt các biểu tượng phụ kèm theo, chính điều này có thể làm cho người dùng khó học.

Hình 8. Ví dụ mô hình quy trình nghiệp vụ với BPMN
Ví dụ mô hình quy trình nghiệp vụ với BPMN

Đánh giá

Dựa trên những phân tích cụ thể về các ngôn ngữ trong phần trên, có thể tổng hợp sự khác biệt của các ngôn ngữ mô hình hoá xét cả về mặt xây dựng mô hình và hiểu mô hình trong Bảng 1 dưới đây.

Bảng 1. So sánh các ngôn ngữ mô hình hoá
Petri NetsEPCsUMLBPMN
Tính rõ ràng của ký hiệu
  • Các ký hiệu thiếu tính rõ ràng.
  • Ký hiệu rất trừu tượng, không rõ ràng.
  • Một số ký hiệu bị quá tải.
  • Gây hạn chế về nhận thức cho người dùng.
  • Nhiều nút vẫn còn tương đối trừu tượng.
  • Biểu đồ hoạt động chưa thể hiện rõ mối quan hệ giữa hoạt động và các đối tượng.
  • Hệ thống ký hiệu phong phú, các ký hiệu được biểu diễn trực quan.
  • Một số ký hiệu chưa thực sự khác biệt.
Tính phân biệt của ký hiệu
  • Khó khăn khi phân biệt ký hiệu function và event.
  • Ký hiệu OR và AND khó phân biệt.
  • Các nút có tính phân biệt khá tốt.
  • Khó khi phân biệt nút start và end.
  • Khó khi phân biệt nút start và end.
  • Ký hiệu X và + khá giống nhau trong một số biểu tượng.
Khả năng hiểu ký hiệu
  • Dễ gây nhầm lẫn do sử dụng quá ít ký hiệu.
  • Nhiều ký hiệu trừu tượng, khó hiểu.
  • Nhiều nút vẫn còn tương đối trừu tượng.
  • Một số ký hiệu trừu tượng, khó hiểu.
Biểu diễn trực quan
  • Khả năng biểu diễn trực quan rất hạn chế.
  • Khả năng biểu diễn trực quan bị hạn chế.
  • Hầu hết biểu tượng phân biệt hình dáng và kích thước.
  • Khả năng biểu diễn trực quan bị hạn chế.
  • Khả năng biểu diễn trực quan bị hạn chế.
Tính phức tạp đồ họa
  • Ký hiệu đơn giản, nghèo nàn.
  • Số lượng ký hiệu ít, dễ học.
  • Số lượng ký hiệu phong phú .
  • Số lượng ký hiệu phong phú nhất.
  • Mất nhiều thời gian để học hơn.
Độ phù hợp với lĩnh vực tài chính - ngân hàng
  • Có quá ít ký hiệu.
  • Không phù hợp mô hình hoá quy trình nghiệp vụ ngân hàng.
  • Có khả năng biểu diễn, tuy nhiên rất hạn chế.
  • Có khả năng biểu diễn, tuy nhiên khá hạn chế.
  • Tiếp cận theo hướng quy trình.
  • Có khả năng mở rộng thêm các ký hiệu.
  • Đã được bổ sung thêm các biểu tượng về ngân hàng.
  • Phù hợp để mô hình hoá các quy trình nghiệp vụ ngân hàng.

Kết luận

Mô hình hoá quy trình nghiệp vụ là một công việc quan trọng, có ý nghĩa lớn đối với việc tổ chức, xây dựng và quản lý doanh nghiệp. Việc sử dụng các ngôn ngữ mô hình hoá để biểu diễn, mô phỏng và đánh giá các quy trình nghiệp vụ trong thực tế ngày càng tăng lên trong các ngân hàng. Vấn đề đặt ra là nên lựa chọn ngôn ngữ nào để phù hợp với hoạt động tin học hóa, phát triển sản phẩm dịch vụ trong lĩnh vực ngân hàng vốn đòi hỏi sự linh hoạt, ổn định và khả năng tích hợp với các hệ thống sẵn có.

Kết quả đánh giá các ngôn ngữ cho thấy, ngôn ngữ BPMN là một ngôn ngữ được tiếp cận theo hướng quy trình, có hệ thống ký hiệu phong phú nhất, có khả năng mở rộng thêm các ký hiệu. Ngôn ngữ này còn có các kỹ thuật sinh tự động mã BPEL thực thi dưới dạng các Web-services nhằm tích hợp giữa tầng nghiệp vụ với các hệ thống nghiệp vụ ngân hàng lõi core banking. Các công cụ mô hình hóa sử dụng BPMN đều được trang bị các chức năng tạo báo cáo và đánh giá hiệu quả, chỉ có khác là mức độ tiện dụng và sự thân thiện. BPMN có thể được sử dụng bởi cả người làm công nghệ và người làm nghiệp vụ, nhưng chắc chắn người làm nghiệp vụ sẽ dễ dàng làm quen với BPMN hơn so với các ngôn ngữ mô hình hóa khác. Việc sử dụng bộ ngôn ngữ BPMN – vốn được thiết kế theo hướng quy trình cho người làm nghiệp vụ – chắc chắn sẽ đáp ứng được các yêu cầu trong quá trình mô tả các sản phẩm dịch vụ ngân hàng về sự linh hoạt, ổn định, dễ sử dụng và khả năng tích hợp với các hệ thống thông tin khác tại ngân hàng.

Tài nguyên

  • Tài liệu tham khảo:
    • [1] Akhilesh Bajaj và Stephen Rockwell. Advanced Topics in Database Research, Kapitel COGEVAL: Khung mệnh đề Dựa trên lý thuyết nhận thức để đánh giá Mô hình khái niệm, trang 255–282. Nhà xuất bản Idea Group, 2005.
    • [2] Anna Gunhild Nysetvold và John Krogstie, đánh giá ngôn ngữ Business Processing Modeling sử dụng Generic Quality Framework, Advanced Topics in Database Research: Vol. 5, Đại học khoa học và công nghệ Na Uy, Viện khoa học máy tính, thông tin và truyền thông SINTEF , Na Uy, 2006, trang 79-91.
    • [3] Daniel Moody và Jos Hillegersberg. Evaluating the Visual Syntax of UML An Analysisof the Cognitive Effectiveness of the UML Family of Diagrams. Springer-Verlag, Berlin, Heidelberg, 2008
    • [4] Jan Mendling và Jan Recker. Hướng tới việc sử dụng các nhãn (Labels) và biểu tượng (Icons) trong Business Process Models. Trong Terry Halpin, Hendrik Alexander Proper and John Krogstie, Hrsg., 12th International Workshop on Exploring Modeling Methods in Systems Analysis and Design, CEUR Workshop Proceedings Series, trang 1–13, Montpellier, France, 2008.
    • [5] K. Figl , J. Mendling , M. Strembeck, hướng đến việc đánh giá khả năng sử dụng của ngôn ngữ Process Modeling, 8. GI-Workshop EPK 2009: Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten. CEUR-WS: Berlin, 2009.
    • [6] M. Wertheimer. A sourcebook of Gestalt psychology, Kapitel Laws của tổ chức các hình thái tri giác, trang. 7188. Routledge và Kegan Paul, London, Anh, 1938. Được in lại từ Psychologische Forschung, 4, trang 301350, 1923.
    • [7] http://en.wikipedia.org/wiki/Modeling_language

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Rational
ArticleID=949880
ArticleTitle=Đánh giá các ngôn ngữ mô hình hóa quy trình nghiệp vụ và đề xuất việc sử dụng ngôn ngữ BPMN trong ngân hàng
publish-date=10242013