LỜI CẢM ƠN

Đầu tiên tôi xin gửi lời cảm ơn sâu sắc tới PGS.TS Hà Quang Thụy, bộ môn Hệ

thống thông tin, khoa Công nghệ thông tin, trường Đại học Công nghệ, Đại học Quốc

gia Hà Nội. Thầy là người thầy dạy, là cố vấn học tập đã luôn quan tâm giúp đỡ, dạy

dỗ và định hướng cho tôi trong suốt những năm tôi theo học ở trường. Thầy cũng

chính là giảng viên hướng dẫn, đã tận tình chỉ dẫn tôi trong suốt quá trình thực hiện

khóa luận tốt nghiệp này.

Tôi xin cảm ơn NCS. Vũ Ngọc Trình đã có những giúp đỡ, góp ý trong quá

trình tôi thực hiện khóa luận này.

Tôi chân thành cảm ơn quý thầy cô trường Đại học Công nghệ, Đại học Quốc

Gia Hà Nội đã tận tình giảng dạy, truyền đạt những kiến thức quý báu trong suốt bốn

năm học làm nền tảng cho tôi thực hiện khóa luận tốt nghiệp này cũng như cho nghiên

cứu và nghề nghiệp tương lai.

Tôi cũng xin gửi lời cảm ơn tới các thầy, các anh, chị, em và các bạn trong

Phòng thí nghiệm công nghệ tri thức (KTLab) – khoa Công nghệ thông tin, trường Đại

học Công nghệ đã đóng góp những ý kiến quý báu để tôi hoàn thành khóa luận này.

Cuối cùng xin được cảm ơn gia đình, người thân và bạn bè tôi đã luôn bên cạnh

động viên và ủng hộ tôi suốt thời gian qua.

Một lần nữa tôi xin chân thành cảm ơn!

Hà Nội ngày 10 tháng 5 năm 2014

Sinh viên

Phan Văn Chương

TÓM TẮT

Tóm tắt: Các tổ chức doanh nghiệp đều ứng dụng công nghệ thông tin vào hoạt động

của họ bởi vì “máy tính có thể tính toán bất cứ thứ gì miễn là người dùng cung cấp đủ dữ liệu

để nó làm việc” (Joop de Jong [11]). Để có được một hệ thống thông tin hỗ trợ doanh nghiệp

mang lại hiệu suất cao nhất thì ta cần có một mô hình đặc tả hệ thống doanh nghiệp chặt chẽ,

logic, toàn diện, chi tiết làm rõ mối tương quan giữa các yếu tố trong một tổ chức doanh

nghiệp và các yếu tổ trong mô hình hệ thống doanh nghiệp và được gọi là mô hình ontology

doanh nghiệp (Enterprise Ontology).

Khóa luận này tập trung nghiên cứu lý thuyết về mô hình tổ chức với ba mức là mức B

(Business: kinh doanh), mức I (Information: thông tin) và mức D (Data: dữ liệu) và ứng dụng

của lý thuyết này để xây dựng ontology của tổ chức. Khóa luận cũng đề nghị một mô hình áp

dụng phương pháp vào hệ thống quản lý ngữ nghĩa khách hàng của FPT Telecom. Trên cơ sở

nghiên cứu của Joop de Jong, 2013 [11], khóa luận thi hành ba mô đun chương trình chuyển

hóa giữa các tác nhân thuộc mô hình tổ chức mức I với tác nhân thuộc mô hình tổ chức mức

D. Thực nghiệm trên hai mô đun chương trình nói trên cho kết quả phù hợp.

Từ khóa: ontology, doanh nghiệp, tổ chức, hệ thống thông tin, mô hình.

Lời cam đoan

Tôi xin cam đoan khóa luận này là do chính tôi thực hiện dưới sự hướng dẫn

của giảng viên hướng dẫn PGS.TS Hà Quang Thụy và giảng viên đồng hướng dẫn

NCS. Vũ Ngọc Trình.

Tất cả những tham khảo từ các nghiên cứu liên quan đều được nêu nguồn gốc

một cách rõ ràng từ danh mục tài liệu tham khảo trong khóa luận. Trong khóa luận,

không có việc sử dụng tài liệu, công trình nghiên cứu của người khác mà không chỉ rõ

về tài liệu tham khảo. Các chương trình thực nghiệm đều là do tôi thực hiện mà có

được, không sao chép từ bất cứ nguồn nào.

Hà Nội ngày 10 tháng 5 năm 2014

Sinh viên

Phan Văn Chương

MỤC LỤC

MỞ ĐẦU ......................................................................................................................... 1

CHƯƠNG 1. ONTOLOGY TRONG DOANH NGHIỆP ...................................... 3

1.1. Tổng quan về ontology ..................................................................................... 3

1.1.1. Khái niệm .................................................................................................... 3

1.1.2. Các thành phần của ontology ..................................................................... 4

1.1.3. Các bước xây dựng ontology ...................................................................... 5

1.2. Hệ thống thông tin trong doanh nghiệp ......................................................... 6

1.2.1. Điều khiển quy trình kinh doanh trong doanh nghiệp ................................ 6

1.2.2. Mối quan hệ giữa kinh doanh và CNTT ...................................................... 7

1.2.3. Vai trò của hệ thống thông tin..................................................................... 8

1.3. Ontology doanh nghiệp .................................................................................... 9

1.3.1. Khái quát ..................................................................................................... 9

1.3.2. Vai trò của ontology doanh nghiệp ............................................................. 9

CHƯƠNG 2. PHƯƠNG PHÁP XÂY DỰNG ONTOLOGY DOANH NGHIỆP

DỰA TRÊN CÁC LÝ THUYẾT VỀ TỔ CHỨC .............................................. 11

2.1. Các lý thuyết về tổ chức ................................................................................. 11

2.1.1. Lý thuyết � ................................................................................................ 11

2.1.2. Lý thuyết � ................................................................................................. 13

2.1.3. Lý thuyết � ................................................................................................ 16

2.2. Mô hình hóa tổ chức dựa trên các lý thuyết về tổ chức.............................. 19

2.2.1. Giới thiệu ................................................................................................... 19

2.2.2. Mô hình tổ chức......................................................................................... 20

2.2.3. Mô hình hóa tổ chức B .............................................................................. 25

2.2.4. Xây dựng mô hình tổ chức I từ tổ chức B.................................................. 26

2.2.4.1. Áp dụng mô hình GSDP .........................................................................................26

2.2.4.2. Các loại giao dịch giữa tổ chức B và tổ chức I .......................................................28

2.2.4.3. Mô hình IAM của tổ chức I ....................................................................................30

2.2.4.3.1. Ghi nhớ sự các sự kiện ........................................................................................30

2.2.4.3.2. Tái tạo các sự kiện...............................................................................................31

2.2.5. Xây dựng mô hình tổ chức D từ tổ chức I ................................................. 32

2.2.5.1. Áp dụng mô hình GSDP .........................................................................................32

2.2.5.2. Các loại giao dịch giữa tổ chức I và tổ chức D ......................................................34

2.2.5.3. Mô hình IAM của tổ chức D ..................................................................................35

CHƯƠNG 3. ÁP DỤNG MÔ HÌNH VỚI DỊCH VỤ TIẾP NHẬN VÀ GIẢI

QUYẾT KHIẾU NẠI CỦA FPT TELECOM .......................................................... 40

3.1. Giới thiệu tổ chức ........................................................................................... 40

3.2. Ngữ cảnh của dịch vụ khiếu nại.................................................................... 41

3.3. Xây dựng mô hình tổ chức I .......................................................................... 42

3.3.1. Tác nhân OA-01 ........................................................................................ 43

3.3.2. Tác nhân OA-02 ........................................................................................ 44

3.4. Xây dựng tổ chức D ....................................................................................... 45

CHƯƠNG 4. THỰC NGHIỆM .............................................................................. 48

4.1. Giới thiệu ........................................................................................................ 48

4.2. Chương trình hỗ trợ tác nhân I .................................................................... 48

4.3. Chương trình hỗ trợ tác nhân D ................................................................... 50

KẾT LUẬN .................................................................................................................. 58

BẢNG CÁC KÝ HIỆU VIẾT TẮT

CNTT Công nghệ thông tin

EIS Enterprise Information System

US Using System

OS Object System

TRT Transaction Result Table

BCT Bank Content Table

FM Fact Model

AM Action Model

IAM Interaction Action Model

CM Construction Model

RAC Rent A Car

DANH SÁCH CÁC BẢNG

Bảng 2-1: Bảng kết quả giao dịch (TRT) .................................................................... 22

Bảng 2-2: Bảng nội dung ngân hàng (BCT) ................................................................ 22

Bảng 3-1: Quy trình tiếp nhận và giải quyết khiếu nại của FPT Telecom [15]. .......... 41

DANH SÁCH HÌNH VẼ

Hình 1.1: Phân tích ý nghĩa của khái niệm về ontology [2]. .......................................... 3

Hình 1.2: Mô phỏng quan hệ giữa các thành viên trong một công ty [1]. ...................... 4

Hình 2.1: Tam giác ký hiệu học [5]. ............................................................................. 11

Hình 2.2: Hình bình hành ontology [5][11]. ................................................................. 12

Hình 2.3: Tam giác mô hình [11] ................................................................................. 13

Hình 2.4: Quy trình phát triển một tổ chức tổng quát (GSDP) [5]. .............................. 15

Hình 2.5: Mẫu giao dịch chuẩn (Dietz) [5][6][11] ....................................................... 17

Hình 2.6: Kí hiệu giao dịch chuẩn trong mô hình DEMO [11]. ................................... 18

Hình 2.7: Ba tổ chức khía cạnh của một tổ chức [7] .................................................... 19

Hình 2.8: Mô hình CM của RAC [7] ............................................................................ 21

Hình 2.9: Mô hình PM của RAC [7] ............................................................................ 23

Hình 2.10: Mô hình sự kiện (FM) của RAC [7] ........................................................... 24

Hình 2.11: Mô hình CM của quầy bán bánh pizza [11]. .............................................. 25

Hình 2.12: Mô hình CM của tổ chức B của quầy bán bánh pizza [11] ........................ 26

Hình 2.13: Xây dựng tổ chức I từ tổ chức B [11]. ........................................................ 27

Hình 2.14: Các loại tác nhân kết hợp giữa tổ chức B và tổ chức I [8] ......................... 29

Hình 2.15: Mô hình IAM ghi nhớ sự kiện của tổ chức I [11] ...................................... 30

Hình 2.16: Mô hình IAM tái tạo sự kiện ...................................................................... 32

Hình 2.17: Xây dựng tổ chức D từ tổ chức I [11]. ........................................................ 33

Hình 2.18: Các loại tác nhân kết hợp giữa tổ chức I và tổ chức D [8]. ........................ 34

Hình 2.19: Lưu trữ sự kiện P [8]. .................................................................................. 36

Hình 2.20: Cung cấp các sự kiện có nguồn gốc [8]. ..................................................... 37

Hình 2.21: Cung cấp các sự kiện bên ngoài [8]. ........................................................... 39

Hình 3.1: Mô hình cấu trúc tổ chức giải quyết khiếu nại. ............................................ 42

Hình 3.2: Tổ chức I cho việc thực hiện vai trò tác nhân O-A01. ................................. 43

Hình 3.3: Tổ chức I cho việc thực hiện vai trò của tác nhân O-A02. ........................... 45

Hình 3.4: Mô hình tổ chức D cho việc lưu trữ và cung cấp dữ liệu sự kiện................. 46

Hình 4.1: Một mẫu sự kiện ........................................................................................... 48

Hình 4.2: Chức năng ghi nhớ và gửi dữ liệu sự kiện đi lưu trữ. ................................... 49

Hình 4.3: Chức năng yêu cầu tái tạo một sự kiện biết trước các tham số. ................... 50

Hình 4.4: Gửi lại sự kiện cho tác nhân I. ...................................................................... 51

Hình 4.5: Dữ liệu về sự kiện được lưu trữ trong cơ sở dữ liệu ..................................... 52

Hình 4.6: Chức năng lưu dữ liệu sự kiện. ..................................................................... 53

Hình 4.7: Văn bản gốc trước khi được mã hóa. ............................................................ 54

Hình 4.8: Giao diện của chức năng mã hóa văn bản .................................................... 55

Hình 4.9: Thông báo mã hóa thành công của chương trình ......................................... 55

Hình 4.10: Văn bản sau khi được mã hóa ..................................................................... 56

Hình 4.11: Chọn file cần giải mã và lưu vào file mới .................................................. 56

Hình 4.12: Giải mã thành công ..................................................................................... 57

Hình 4.13: Kết quả giải mã ........................................................................................... 57

1

MỞ ĐẦU

Hệ thống thông tin đã là một trong các tài nguyên cốt lõi của mọi tổ chức trong

kỷ nguyên thông tin của nhân loại. Tuy nhiên, không ít các dự án triển khai hệ thống

thông tin cho doanh nghiệp đã gặp phải thất bại. Có nhiều nguyên nhân được các nhà

nghiên cứu tìm ra, chẳng hạn là do thiếu sự liên kết giữa các hoạt động kinh doanh và

CNTT (Henderson và Venkatraman), hoặc việc mô hình hóa quy trình kinh doanh vào

mô hình hóa hệ thống thông tin chưa chính xác (Reijswoud van và Mulder),… [11].

Tóm lại là việc ánh xạ tổ chức doanh nghiệp vào hệ thống thông tin còn nhiều bất cập

do chưa đầy đủ, chưa đúng bản chất,…

Ontology cho phép chúng ta mô hình hóa thế giới tổ chức vào một mô hình hệ

thống tổ chức với đầy đủ các thành phần và quan hệ giữa chúng, qua đó ta có một cái

nhìn tổng quan nhưng đầy đủ về tổ chức. Và dựa trên mô hình tổ chức đó, việc thiết

kế, xây dựng hệ thống thông tin doanh nghiệp sẽ trở nên dễ dàng và chính xác hơn.

Dựa trên các kết quả nghiên cứu liên quan tới chủ đề này [5,6,7,8,11], đặc biệt

là nghiên cứu của Joop de Jong [11, khóa luận này trình bày các cơ sở lý thuyết dựa

trên đó sẽ đưa ra cách để ánh xạ thế giới thực của một tổ chức vào mô hình ontology

của nó. Đồng thời, khóa luận cũng đưa ra mô hình áp dụng một trường hợp thực tiễn

tại FPT Telecom để minh chứng cho phương pháp.

Nội dung khóa luận này gồm 4 chương

Chương 1. Ontology trong doanh nghiệp. Chương này sẽ trình bày các khái niệm về

ontology, về hệ thống thông tin trong doanh nghiệp và mối quan hệ giữa chúng, và tại

sao chúng ta cần xây dựng ontology doanh nghiệp.

Chương 2. Phương pháp xây dựng ontology doanh nghiệp dựa trên các lý thuyết

về tổ chức. Chương này sẽ đi tìm hiểu các lý thuyết về tổ chức để khảo sát mối liên

quan hệ giữa các thành phần trong một tổ chức và trên cơ sở đó sẽ xây dựng phương

pháp.

Chương 3. Áp dụng mô hình với tổ chức tiếp nhận và giải quyết khiếu nại của

FPT Telecom. Trên cơ sở quy trình tiếp nhận tổ chức khiếu nai của FPT Telecom

[15], dựa trên phương pháp đã xây dựng ở các chương trước, chương này trình bày

một áp dụng thực tiễn dựa trên một quy trình kinh doanh sẵn có. Khóa luận đề nghị

một mô hình cấu trúc tổ chức giải quyết khiếu nại với các mô hình thành phần liên

quan tới các mô hình tổ chức I và D cho các tác nhân A01 và A02 trong quy trình kinh

doanh nói trên.

2

Chương 4. Thực nghiệm và đánh giá. Chương 4 tiến hành xây dựng ba mô đun

chương trình hỗ trợ hai tác nhân OA1 và OA2 thực hiện vai trò của mình trong việc

lưu trữ và cung cấp dữ liệu.

3

Chương 1. Ontology trong doanh nghiệp

1.1. Tổng quan về ontology

1.1.1. Khái niệm

Trên phương diện khoa học máy tính, Ontology được nhắc đến như một kiểu đặc

biệt của các đối tượng thông tin. Theo thời gian, nhiều định nghĩa về Ontology được

các nhà khoa học đưa ra dựa trên những đặc trưng mà nó biểu thị. Năm 1993, Gruber

định nghĩa khái niệm một Ontology như một “đặc tả rõ ràng của một khái niệm”. Còn

theo Borst, ông định nghĩa một Ontology như là một “đặc tả hình thức của một khái

niệm được chia sẻ”. Khái niệm này mở rộng hơn một điều là các khái niệm phải được

trình bày với mức chia sẻ giữa các thành phần tham gia. Năm 1998, Studer cùng các

cộng sự trong một nghiên cứu đã gộp hai định nghĩa này lại thành định nghĩa: “Một

Ontology là một hình thức, đặc tả rõ ràng của một khái niệm được chia sẻ” [1]. Trong

một nghiên cứu khác, B. Swartout và các cộng sự định nghĩa “Một Ontology là một

cấu trúc phân cấp của một tập các thuật ngữ mô tả một miền mà có thể được sử dụng

như một nền tảng khung xương cho cơ sở tri thức” [2]. Hình 1.1 phân tích ý nghĩa của

khái niệm về Ontology của Studer:

Hình 1.1: Phân tích ý nghĩa của khái niệm về ontology [2].

Nói tóm lại, đứng trên góc độ khoa học máy tính và trí tuệ nhân tạo, ta có thể

hiểu một Ontology là một mô tả về một miền ứng dụng nhất định, nó bao gồm các

khái niệm, thuộc tính, các thực thể, các mối quan hệ giữa khái niệm, thực thể; ngoài ra

nó còn giải thích ý nghĩa của các khái niệm, mô tả chi tiết về các đặc điểm, tính chất

4

cũng như mối quan hệ giữa các khái niệm trong miền ứng dụng đó. Ontology thể hiện

một góc nhìn về thế giới.

Kỹ thuật Ontology phân tích các thực thể có liên quan trong một miền thế giới

thực và tổ chức chúng vào các khái niệm và các mối quan hệ. Hay nói cách khác là kỹ

thuật Ontology mô hình hóa, trừu tượng hóa thế giới thực vào một mô hình bao gồm

các thành phần phân cấp có liên quan và các mối quan hệ giữa chúng. Có thể xét một

ví dụ về tổ chức con người trong một công ty. Trong miền này có các khái niệm là con

người, quản lý, chuyên gia là các thành phần có liên quan. Trong đó khái niệm thứ

nhất là khái niệm cha của hai khái niệm còn lại. Và cộng tác với có thể xem xét là một

quan hệ có liên quan giữa những con người này [1]. Hình 1.2 mô phỏng mối quan hệ

giữa các thể hiện trong miền này.

Hình 1.2: Mô phỏng quan hệ giữa các thành viên trong một công ty [1].

1.1.2. Các thành phần của ontology

Ontology bao gồm các thành phần chính: lớp (class), thực thể (individual) hay

thể hiện (instance), thuộc tính (property) và quan hệ (relation).

Lớp (class) là tập các đối tượng cùng loại. Trong mỗi lớp có thể chứa các lớp con

hoặc các thực thể (thể hiện) hoặc chứa đồng thời cả hai. Khi một lớp có chứa một lớp

khác thì ta nói các lớp có quan hệ cha – con và hệ thống có tính phân cấp. Chẳng hạn

trong phân lớp về các loài sinh vật ta phân sinh vật thành hai lớp lớn là Động vật và

Thực vật. Mỗi lớp này có chứa các lớp con nhỏ hơn và các thực thể trong đó.

5

Thể hiện (instance) có thể xem là đại diện của một lớp. Thể hiện làm rõ hơn về

một lớp và nó là một đối tượng thực nào đó trong tự nhiên. Ví dụ Obama, bệnh ung

thư,…

Thuộc tính (property) mô tả các khía cạnh, đặc điểm của các lớp và các thể hiện

[3]. Chẳng hạn như một “bệnh” có thuộc tính là “triệu chứng”, một “người” có các

thuộc tính là “năm sinh”, “giới tính”, “quê quán”,… Thuộc tính biểu thị quan hệ nhị

phân giữa thể hiện với thể hiện hoặc thể hiện với giá trị.

Quan hệ (relation) trong Ontology biểu thị mối quan hệ giữa các lớp hoặc giữa

lớp với các thể hiện. Có các quan hệ như: “lớp cha của”, “lớp con của”, “một phần

của”,…

1.1.3. Các bước xây dựng ontology

Bước 1: Xác định miền và phạm vi của Ontology.

Trong bước này cần giải đáp được các câu hỏi chính: “Ontology sẽ bao phủ miền

nào?”, “Ontology phục vụ cho những mục đích nào?”, “Những kiểu câu hỏi thông tin

mà ontology có thể cung cấp câu trả lời?”, “Ai là người sử dụng và bảo trì ontology?”.

Mặc dù câu trả lời có thể thay đổi trong suốt quá trình xây dựng ontology nhưng chúng

sẽ giúp việc phát triển luôn nằm trong phạm vi, không đi quá xa miền cần làm việc [3].

Bước 2: Xem xét việc tái sử dụng các ontology có sẵn.

Đây là một bước quan trọng. Việc tái sử dụng các ontology có sẵn có liên quan

đến miền đang xét giúp người phát triển tiết kiệm thời gian, công sức và chi phí.

Bước 3: Liệt kê các thuật ngữ quan trọng trong ontology.

Ở bước này cần xác định các thuật ngữ chính và các thể hiện của chúng. Việc

viết ra danh sách các thuật ngữ ta muốn đưa vào ontology là rất hữu ích và có thể sử

dụng để giải thích với người dùng. Chẳng hạn trong ontology về rượu ta có các thuật

ngữ chính: wine, grape, winery, location, a wine’s color, body, flavor, sugar

content…

Bước 4: Tạo các lớp và phân cấp các lớp.

Ở bước này, ta có ba cách tiếp cận khi thực hiện phân cấp các lớp sau khi định

nghĩa chúng: hướng tiếp cận top – down, hướng tiếp cận bottom – up, hướng tiếp cận

middle – out.

6

Hướng tiếp cận top – down được thực hiện bằng việc định nghĩa khái niệm tổng

quan nhất của miền và sau đó chuyên biệt hóa (làm mịn) khái niệm này. Chẳng hạn

ban đầu ta xác định hai lớp tổng quát nhất cho ontology bao gồm Wine và Food. Sau

đó, lớp Wine được chuyên biệt bằng cách tạo ra các lớp con của nó: White wine, Red

wine, Rosé wine [3]…

Ngược lại với hướng tiếp cận top – down, hướng tiếp cận bottom – up được thực

hiện bằng việc thiết lập các lớp cụ thể nhất, sau đó xây dựng các lớp cha của các lớp

này bằng cách nhóm các lớp nhỏ này thành các lớp lớn hơn dựa theo đặc điểm chung.

Kết hợp hai hướng tiếp cận top – down và bottom – up ta có một hướng tiếp cận

khác là middle – out. Hướng này được thực hiện bằng cách định nghĩa các các thuật

ngữ có cấp độ trung tâm, sau đó tiến hành tổng quát hóa và chuyên biệt hóa chúng

bằng cách gộp thành các lớp cha và định nghĩa các lớp con của chúng.

Bước 5: Định nghĩa các thuộc tính cho lớp.

Ở bước này công việc chính là mô tả cấu trúc nội tại của các khái niệm. Hay nói

các khác là cung cấp đầy đủ thông tin để trả lời các câu hỏi năng lực trong bước 1 [3].

Bước 6: Định nghĩa các khía cạnh cho các thuộc tính.

Thuộc tính có các khía cạnh khác nhau mô tả kiểu giá trị (xâu, số nguyên, số

thực,…), giá trị cho phép, số lượng của giá trị,... Chẳng hạn thuộc tính “name” trong

ontology về rượu có kiểu là String [3].

Bước 7: Định nghĩa các thể hiện

Bước cuối cùng của việc phát triển ontology là việc tạo các thực thể thể hiện

trong cây phân cấp. Để thực hiện được điều này, ta cần làm theo ba bước: (1) chọn

một lớp, (2) tạo các thực thể thể hiện cho lớp, (3) điền các giá trị thuộc tính [3]. Chẳng

hạn như trong ontology về rượu ta tạo ra một thể hiện có tên là A, màu Trắng, giá

90$,…

1.2. Hệ thống thông tin trong doanh nghiệp

1.2.1. Điều khiển quy trình kinh doanh trong doanh nghiệp

Trong quá trình hoạt động, các doanh nghiệp có thể tiết kiệm được cho mình

nhiều tiền thông qua một vài cải tiến nhỏ trong tổ chức [11].

Trong nghiên cứu kinh điển về quản lý có tính khoa học của mình, Taylor đã lập

luận để phản bác quan điểm cho rằng các nhà quản lý không phải lo lắng về động cơ

7

thúc đẩy nhân viên, và chỉ đơn thuần là nhắc nhở nhân viên của mình về nhiệm vụ của

họ là đủ. Theo Taylor, nhà tuyển dụng chỉ có thể tìm cách nâng cao hiệu quả công việc

nếu chắc chắn được nhân viên của họ được đào tạo thích hợp và có điều kiện làm việc

tốt. Trong khi đó, theo nghiên cứu cùng thời gian của Fayol, ông đánh giá cao về vai

trò của “thiết bị điều khiển”. Fayol định nghĩa một thiết bị điều khiển như là một hệ

thống quan sát bao gồm hiện tại, quá khứ và tương lai, trong đó sự đóng góp của các

thành viên giàu kinh nghiệm của đội ngũ nhân viên, cùng với thông tin từ các nguồn

bên ngoài, tạo cơ hội tốt nhất cho hội đồng quản trị để ước lượng những hậu quả có thể

có của quyết định của mình.

Trên một phương diện khác, chúng ta biết rằng máy tính có thể tính toán bất cứ

thứ gì miễn là người dùng cung cấp đủ dữ liệu để nó làm việc [11]. Và máy tính ngày

càng đóng vai trò quan trọng trong hoạt động của các tổ chức nói chung và các doanh

nghiệp nói riêng. Việc tận dựng sự ưu việt của máy tính nói chung và các hệ thống nói

riêng đã góp phần nâng cao chất lượng hoạt động cho doanh nghiệp (giải quyết nhanh,

tiết kiệm thời gian, nhân lực, chi phí,…).

Đó là lý do vì sao các doanh nghiệp thường mua một ứng dụng phần mềm gọi là

hệ thống thông tin doanh nghiệp (viết tắt là EIS) như lựa chọn cho mình một cách hoạt

động nhằm mang lại hiệu quả cao nhất.

1.2.2. Mối quan hệ giữa kinh doanh và CNTT

Mặc dù chúng ta thấy rõ vai trò quan trọng của máy tính và công nghệ thông tin

đối với hoạt động của doanh nghiệp, nhưng không phải bài toán áp dụng công nghệ

thông tin cho doanh nghiệp nào cũng có lời giải thỏa đáng. Henderson và

Venkatraman cho rằng sự thiếu liên kết giữa các hoạt động kinh doanh và CNTT gây

ra nhiều khoản đầu tư CNTT thất bại. Còn theo Dietz, hiệu quả của các hoạt động của

các doanh nghiệp chính là kết quả của việc thiết kế các tổ chức. Cũng nghiên cứu về

vấn đề này, Reijswoud van và Mulder đánh giá rằng, hiện nay có một khoảng cách

giữa cách tiếp cận cho việc mô hình hóa quy trình kinh doanh vào mô hình hóa hệ

thống thông tin. Do khoảng cách này, các bản dịch của các quy trình kinh doanh vào

một hệ thống thông tin (và ngược lại) không chính xác, và do đó sự liên kết của các

doanh nghiệp và CNTT đã trở nên khó khăn [11].

Như vậy, cần có một phương pháp luận cho việc tạo ra một hệ thống thông tin hỗ

trợ dựa trên thiết kế của việc xây dựng một tổ chức. Barjis nhấn mạnh rằng việc thực

hành hai thập kỷ qua cho thấy sự thất bại của hệ thống phần mềm, bên cạnh đó ông

8

còn nhấn mạnh nguyên nhân là do sự nghèo nàn của mô hình. Các hệ thống này không

phải do lỗi kỹ thuật, mà vì họ không hỗ trợ đầy đủ các quy trình kinh doanh cơ bản.

Ông đề cập đến một cuộc khảo sát do Tập đoàn Standish tiến hành trong quản trị

CNTT chỉ ra rằng chỉ có 29% các dự án phần mềm thành công, trong khi 53% bị kiện

và 18% hoàn toàn thất bại. Theo các nhà quản trị CNTT, lý do chính cho các dự án

phần mềm bị thách thức hoặc thất bại là mô hình khái niệm nghèo [11].

Dietz lập luận rằng một phương pháp để thiết kế một hệ thống thông tin hỗ trợ từ

việc thiết kế tổ chức phải đáp ứng các tiêu chuẩn chất lượng C4E, tức là, nó phải được

chặt chẽ, toàn diện, phù hợp, ngắn gọn và thiết yếu [9]. Chặt chẽ có nghĩa là quá trình

làm việc trong phương pháp này phải tạo thành một tổng thể hợp lý và không thể tách

rời. Toàn diện là nó phải bao gồm tất cả các khía cạnh liên quan cần thiết để chuyển từ

một mô hình tổ chức kinh doanh sang một mô hình tổ chức thông tin và sau đó vào

một mô hình của một hệ thống thông tin thực hiện được. Phù hợp ở đây được hiểu là

phương pháp tiếp cận không được có các bất thường. Thiết yếu tức là phương pháp

phải được áp dụng phổ biến.

1.2.3. Vai trò của hệ thống thông tin

Như mục 2.1 đã nói, hệ thống thông tin doanh nghiệp thường được các tổ chức

lựa chọn như một cách hoạt động của mình. Tuy nhiên, phải chấp nhận một điều là khi

phát triển hệ thống, nhà phát triển ngoài tổ chức ban đầu sẽ không biết được doanh

nghiệp hoạt động như thế nào. Và vấn đề này được hai bên thống nhất giải quyết trong

quá trình triển khai hệ thống. Do đó trong quá trình phát triển, hệ thống đôi lúc phải

thay đổi nhiều cho phụ hợp với tổ chức. Điều này cần hạn chế để đảm bảo về thời gian

và chi phí.

Các nhà nghiên cứu thường tự hỏi rằng liệu các công ty có mua đúng phần mềm

mà họ cần thiết hay không. Nghĩa là các phần mềm không chỉ cần cho hiện tại, mà còn

cần cho tương lai gần. Câu hỏi này xuất phát từ thực tế là các doanh nghiệp chỉ thực

hiện một phần ứng dụng của phần mềm mà họ đã mua; các doanh nghiệp thi thoảng

cũng băn khoăn liệu tổ chức của họ có bị lệch khỏi hệ thống mà họ đã triển khai; và

các doanh nghiệp đôi khi thấy rằng hệ thống chính là rào cản đối với sự thay đổi [11].

Vậy mối quan hệ giữa một tổ chức với một hệ thống thông tin được hiểu như thế

nào? Rõ ràng là một hệ thống thông tin doanh nghiệp sẽ hỗ trợ các nhân viên của công

ty cải thiện hiệu suất làm việc của họ. Hệ thống xuất hiện trong tổ chức cho biết cách

thức vận hành của tổ chức đến mức độ nào đó tùy thuộc vào việc xây dựng hệ thống.

9

Theo Joop de Jong, một hệ thống có các mức độ khác nhau: nó được xem như là một

công cụ để vận hành một phần tổ chức kinh doanh. Trong doanh nghiệp, hệ thống

ngầm xác định mối quan hệ hoạt động của con người trong một tổ chức. Nó hỗ trợ các

thông tin mà con người cần và ghi nhớ các công việc mới được tạo để làm cho chúng

trở thành thông tin sẵn có sau này.

Như vậy, điều quan trọng cần xác định khi triển khai hệ thống đó là làm thế nào

để phát triển một hệ thống thông tin doanh nghiệp phù hợp với tổ chức và làm thế nào

để ta có thể biết được một hệ thống thông tin doanh nghiệp cần có những gì mà tổ

chức cần?

1.3. Ontology doanh nghiệp

1.3.1. Khái quát

Theo định nghĩa của Dietz, một ontology doanh nghiệp là một đặc tả chính quy

và rõ ràng của một khái niệm hoá chia sẻ giữa một cộng đồng người của một doanh

nghiệp (hoặc một phần của nó) [4]. Nói cách khác, ontology cung cấp một hiểu biết

chung về một miền, tạo điều kiện thông tin liên lạc giữa con người và hệ thống [10].

Nói chung, các hoạt động phát triển ontology bao gồm đặc tả, khái niệm, hình

thức hóa, thực thi và bảo trì. Khái niệm hóa là một trong những hoạt động chính trong

quá trình phát triển ontology. Các cấu trúc hoạt động khái niệm hóa tri thức miền với

các mô hình có ý nghĩa ở mức độ tri thức. Mục tiêu của một quá trình khái niệm hóa là

để cung cấp một mô hình miền ít chính thức hơn so với mô hình thực hiện nhưng hơn

định nghĩa của mô hình trong ngôn ngữ tự nhiên [10].Trong khóa luận này, ontology

được trình bày ở mức mô hình đặc tả.

1.3.2. Vai trò của ontology doanh nghiệp

Đối với một doanh nghiệp nói riêng và các tổ chức nói chung, mô hình ontology

về tổ chức có vai trò quan trọng. Ontology doanh nghiệp tập trung vào bản chất của

các hoạt động của một tổ chức, tức là nó hoàn toàn độc lập với sự thực hiện và triển

khai của tổ chức. Nó cung cấp một góc nhìn khách quan về tổ chức và hỗ trợ doanh

nghiệp phân tích, thiết kế và xây dựng hệ thống thông tin cho mình. Hay nói cách

khác, ontology cung cấp một mô hình khung xương cho việc phân tích, thiết kế và xây

dựng một hệ thống thông tin doanh nghiệp.

Theo Mike Uschold và các cộng sự [14], Ontology doanh nghiệp như là một

phương tiện truyền thông, đặc biệt là giữa:

10

- Những con người với nhau, bao gồm cả người dùng và nhà phát triển.

- Con người và các hệ thống tính toán được thực thi.

- Các hệ thống khác nhau.

Các tác giả cũng nhận định thêm là, tầm quan trọng của ontology doanh nghiệp

còn được mở rộng để hỗ trợ:

- Tiếp nhận, biểu diễn và thao tác với tri thức doanh nghiệp;

- Cấu trúc hóa và tổ chức các thư viện của tri thức;

- Giải thích các lý do, đầu vào, đầu ra của các mô-đun của bộ công cụ doanh

nghiệp.

Trong nghiên cứu của mình, Joop de Jong có nói đến một số vai trò quan trọng

của ontology doanh nghiệp. Trong đó đáng lưu ý là ba chi tiết sau: Thứ nhất, mô hình

ontology của tổ chức thông tin cung cấp một mô hình độc lập với thực hiện để ghi nhớ,

phát sinh và cung cấp các sự kiện phối hợp và các sự kiện sản xuất. Thứ hai, mô hình

ontology của tổ chức dữ liệu cung cấp một mô hình độc lập thực hiện để lưu trữ,

chuyển và lấy tài liệu. Thứ ba, mô hình ontology của tổ chức vật lý cung cấp mô hình

độc lập thực hiện để lưu trữ, sao chép, hủy, truyền tải và lấy các tập tin (tài liệu in)

[11].

Tóm lại, sự sẵn có của một mô hình ontology mở rộng của doanh nghiệp là yêu

cầu cần thiết cho sự phát triển hoặc lựa chọn một hệ thống thông tin. Mô hình

ontology cung cấp một góc nhìn khách quan về tổ chức và hỗ trợ chúng ta phân tích,

thiết kế và xây dựng hệ thống thông tin cho doanh nghiệp. Theo quan điểm của Joop

de Jong, mô hình ontology này phải được coi là điểm khởi đầu cho việc thiết kế các

tình huống khác nhau cho hệ thống thông tin được phát triển hoặc lựa chọn.

11

Chương 2. Phương pháp xây dựng ontology doanh nghiệp dựa trên

các lý thuyết về tổ chức

2.1. Các lý thuyết về tổ chức

2.1.1. Lý thuyết �

Lý thuyết φ là một lý thuyết về khái niệm hóa của tri thức thực tế. Lý thuyết này

có nguồn gốc từ ký hiệu học, ontology và logic. Trong ký hiệu học, tam giác ký hiệu

học được biểu diễn trong hình 2.1 [11]:

Hình 2.1: Tam giác ký hiệu học [5].

Trong sơ đồ trên, các biểu tượng được sử dụng như đại diện của các đối tượng để

có thể giao tiếp về các đối tượng mà không cần đến sự hiện diện của đối tượng. Các ký

hiệu cơ bản trong sơ đồ là dấu hiệu, đối tượng và khái niệm. Trong đó, một khái niệm

có trong tâm trí của một đối tượng con người, dấu hiệu (thuật ngữ hoặc biểu tượng)

chỉ định các khái niệm, đối tượng (những thứ thực tế) được gọi bởi các khái niệm và

biểu thị bằng dấu hiệu. Đối tượng là một thứ có thể nhận biết được. Chẳng hạn như

một người, một chiếc xe hơi, hợp đồng cho thuê,…

Joop de Jong nhận định rằng đối tượng không phải lúc nào cũng là một cái gì đó

mà ta có thể nhìn thấy (ta không thể thấy “một hợp đồng cho thuê”). Đối tượng hiện

diện trong thế giới chủ quan. Nó có thể được phát hiện thông qua thuộc tính của nó.

Nhưng không có sự hiện diện trong thế giới khách quan, một hình ảnh của đối tượng

tồn tại trong tâm trí của người quan sát. Hầu hết các giao tiếp giữa con người đề cập

12

đến hình ảnh chung của các đối tượng. Một hình ảnh của một đối tượng được lưu giữ

trong tâm trí được gọi là khái niệm [11].

Vấn đề cần xem xét ở đây là mối quan hệ giữa các đối tượng và thông tin. Thông

tin đề cập đến một đối tượng. Thông tin có thể được xem như là tính hai mặt không thể

tách rời của một dấu hiệu và khái niệm nó chỉ định. Các dấu hiệu được gọi là hình thức

thông tin và khái niệm được gọi là nội dung của thông tin.

Vấn đề thứ hai được đề cập liên quan đến các đối tượng là thuật ngữ “đối tượng”

được định nghĩa rất rộng rãi. Nó không chỉ bao gồm các đối tượng vật lý (một cây,

máy móc, một đồng hồ, một mảnh đồ nội thất,…), mà còn là các đối tượng trừu tượng

(hợp đồng thuê, một dự án, một khoản vay, một cuộc hôn nhân,…)

Tam giác ký hiệu học không chỉ áp dụng cho các khái niệm cụ thể mà còn cho

những trường hợp tổng quát. Theo Dietz: “Một khái niệm tổng quát được gọi là một

loại và một đối tượng tổng quát được gọi là một lớp. Một lớp là phần mở rộng của một

loại, và một loại là nội hàm của một lớp”. Mối quan hệ giữa các thành phần này được

biểu thị như hình bình hành ontology (hình 2.2).

Hình 2.2: Hình bình hành ontology [5][11].

Hình bình hành ontology sẽ là cơ sở để phát triển các ontology. Tại mọi thời

điểm, thế giới luôn ở trong một trạng thái đặc biệt và được xác định là một tập hợp các

đối tượng. Thế giới một tổ chức cũng như thế. Và hoạt động của một tổ chức dẫn đến

một quá trình chuyển đổi của “thế giới của tổ chức”. Một quá trình chuyển đổi được

định nghĩa là một sự thay đổi trạng thái của thế giới tại một điểm cụ thể trong thời

13

gian. Dietz lập luận, “trạng thái của thế giới đối tượng” phản ánh sự ảnh hưởng của

các hành vi sản xuất được hình thành bởi các yếu tố của hệ thống.

Chúng ta đều biết rằng một tổ chức là rất phức tạp. Do đó cách tốt nhất để kiểm

tra một hệ thống phức tạp là xây dựng một mô hình của hệ thống này. Theo Apostel thì

bất kỳ đối tượng nào sử dụng một hệ thống A trực tiếp hoặc gián tiếp tương tác với

một hệ thống B, để có được thông tin về hệ thống B, thì sử dụng A như một mô hình

cho B [11]. Theo định nghĩa này, một hệ thống được coi là một mô hình nếu hệ thống

được sử dụng như một mô hình. Dietz phân chia hệ thống thành ba loại: hệ thống cụ

thể, hệ thống biểu tượng, và hệ thống khái niệm. Mối quan hệ giữa các loại này được

thể hiện trong hình 2.3. Hệ thống khái niệm được coi là một mô hình khái niệm của hệ

thống cụ thể bằng cách khái niệm hóa. Các hệ thống khái niệm được coi là một mô

hình khái niệm của hệ thống biểu tượng bằng cách giải thích. Ngược lại, hệ thống cụ

thể được xem là một mô hình cụ thể của hệ thống khái niệm thông qua việc thực hiện

các hệ thống khái niệm. Hệ thống biểu tượng được coi là một mô hình biểu tượng của

hệ thống khái niệm sau khi xây dựng hệ thống khái niệm.

Hình 2.3: Tam giác mô hình [11]

2.1.2. Lý thuyết �

Trong nghiên cứu của mình, Dietz nói rằng, lý thuyết � bắt nguồn từ hệ thống

học, ontology và lý thuyết thiết kế. Theo Joop de Jong, lý thuyết này mô tả quy trình

chung của việc phát sinh một hệ thống đối tượng từ một hệ thống đang sử dụng. Chẳng

hạn, nguồn gốc của các tổ chức thông tin là từ các tổ chức kinh doanh. Từ hệ thống

đang dùng, các mô hình chức năng của hệ thống đối tượng sẽ được xác định. Sau đó

14

mô hình cấu trúc độc lập thực hiện của hệ thống đối tượng, cũng được biết đến như mô

hình ontology, được thiết kế từ mô hình chức năng của hệ thống đối tượng. Nhiều mô

hình thực hiện thay thế có thể được tạo ra từ mô hình ontology.

Chúng ta có thể xem đây là một lý thuyết cho phát triển các tổ chức mà đại diện

là các hệ thống. Ở đây, phát triển hệ thống được hiểu là việc sinh ra một hệ thống mới

hoặc thay đổi hệ thống hiện có. Mọi quá trình phát triển đều liên quan đến hai hệ

thống, đó là hệ thống đang sử dụng (US) và hệ thống đối tượng (OS). Kể từ đây, hai hệ

thống này lần lượt được viết tắt là hệ thống US và hệ thống OS. Hệ thống OS là hệ

thống sẽ được phát triển. Hệ thống US là hệ thống sẽ sử dụng dịch vụ (chức năng) của

hệ thống đối tượng [11].

De Jong chia quá trình phát triển một hệ thống hoàn chỉnh thành ba đoạn lớn:

thiết kế, chế tạo và thực hiện.

Đầu tiên là giai đoạn thiết kế. Giai đoạn này có hai công việc chính là “thiết

kế chức năng” và “thiết kế cấu trúc”. Thiết kế chức năng bắt đầu từ cấu trúc của US và

kết thúc với chức năng của OS. Trong đó chức năng của OS phải được xác định đầy đủ

và chỉ về mặt cấu trúc của US. Thiết kế cấu trúc thì ngược lại hoàn toàn. Nó bắt đầu

với chức năng cụ thể của OS và nó kết thúc với cấu trúc của OS.

Đầu vào chính cho việc thiết kế chức năng là tập hợp các yêu cầu chức năng

được cung cấp bởi US. Các yêu cầu này không nhất thiết phải giống với các đặc tả

chức năng như trong mô hình chức năng của OS. Thứ nhất, các yêu cầu có thể là

không có cơ sở. Thứ hai, cả chức năng và đặc biệt là các đặc tả cấu trúc phải có tính

khả thi để thực hiện (với công nghệ có sẵn và ngân sách).

Theo De Jong, thiết kế tổng thể của một hệ thống được hiểu là một quá trình các

bước phân tích và tổng hợp xen kẽ. Trong một bước phân tích, vấn đề được hiểu rõ

hơn; một bước tổng hợp là một trong đó giải pháp trở nên rõ ràng hơn. Trong “Ghi chú

về các Tổng hợp các mẫu” của mình, Alexander nói rằng quá trình thiết kế thực tế

không phải là một bước (lớn) thiết kế chức năng, tiếp theo là một bước (lớn) thiết kế

cấu trúc, mà là một chuỗi (nhỏ) các bước phân tích và tổng hợp xen kẽ. Trong một

bước phân tích, một sự hiểu biết tốt hơn chính là đạt được các yêu cầu của hệ thống

người dùng. Trong một bước tổng hợp, một sự hiểu biết tốt hơn là đạt được cách mà

hệ thống có thể được tạo ra [11].

Nói chung, việc thiết kế bao hàm đàm phán, để đi đến quả cuối cùng là một sự

thỏa hiệp cân bằng giữa yêu cầu (hợp lý) và đặc tả (khả thi). Các yêu cầu cấu trúc

15

được cung cấp bởi US phải được hiểu là đầu vào chính cho giai đoạn này. Chúng

thường được gọi là yêu cầu phi chức năng.

Tiếp theo sẽ thảo luận về chế tạo và thực hiện. Trong phần này, Ontology và

công nghệ đóng vai trò quan trọng. Sau đó, ontology hoặc mô hình ontology của một

hệ thống là một mô hình cấu trúc của nó độc lập hoàn toàn với cách mà hệ thống được

được thực hiện. Đây chính là mô hình cấu trúc cấp cao nhất của hệ thống [11].

Hình 2.4: Quy trình phát triển một tổ chức tổng quát (GSDP) [5].

Việc chế tạo một hệ thống là hoạt động trong đó một loạt các mô hình cấu trúc

được sinh ra. Mỗi mô hình hoàn toàn có thể suy ra từ một mô hình trước đó và các đặc

tả có sẵn. Trái với thiết kế, kỹ nghệ có đặc tính thủ công hơn là sáng tạo. Kỹ nghệ bắt

đầu từ mô hình ontology và kết thúc với mô hình thực hiện. Do đó, kỹ nghệ cũng được

gọi là thiết kế thực thi. Việc thực thi một hệ thống được hiểu là sự phân bổ phương

tiện kỹ thuật vào các thành phần cấu trúc trong mô hình thực thi. Sau khi thực thi một

cách chính xác, hệ thống có thể được đưa vào hoạt động.

Hình 2.4 trình bày quá trình phát triển một tổ chức tổng quát của Dietz. Các tổ

chức tồn tại nhằm đóng góp vào mục tiêu của các bên liên quan. Sự đóng góp vào mục

tiêu của các bên liên quan có thể được tìm thấy trong các mô hình chức năng của OS.

Thiết kế của mô hình cấu trúc của tổ chức bắt đầu với mô hình chức năng và kết thúc

với mô hình cấu trúc độc lập thực thi ở mức cao nhất của tổ chức. Từ mô hình

16

ontology này, mô hình thực thi có thể được thiết kế thông qua quá trình thiết kế thực

thi.

2.1.3. Lý thuyết �

Dietz là một nhà nghiên cứu tập trung vào các công trình liên quan đến hệ thống

thông tin doanh nghiệp nói chung và ontology doanh nghiệp nói riêng. Trong đó ông

sử dụng lý thuyết ψ làm nền tảng cho khái niệm ontology doanh nghiệp. Dietz sử dụng

lý thuyết này để xây dựng một phương pháp cung cấp một mô hình ontology của một

tổ chức, đó là một mô hình chặt chẽ, toàn diện, nhất quán và chính xác, và nó chỉ cho

thấy bản chất của các hoạt động của một mô hình tổ chức [7].

Theo Diezt thì lý thuyết ψ là một lý thuyết về bản chất của các tổ chức. Nó làm

rõ và giải thích việc xây dựng và hoạt động của tổ chức. Theo đó, nguyên tắc hoạt

động của các doang nghiệp là các tác nhân (nhân viên, khách hàng, nhà cung cấp)

nhập vào và thực hiện các cam kết liên quan đến các sản phẩm (dịch vụ) mà họ sản

xuất trong sự hợp tác với nhau. Trên lý thuyết này, có thể hiểu doanh nghiệp như một

hệ thống xã hội, trong đó các thành phần con người đóng vai trò như các cá nhân xã

hội, có các thẩm quyền thích hợp và các trách nhiệm tương ứng. Từ đây, chúng ta có

một ý niệm hiệu quả về ontology doanh nghiệp [11].

Như vậy, lý thuyết � xem tổ chức như một hệ thống xã hội mà các phần tử và

các liên kết tác động giữa các phần tử đại diện cho vai trò của người thực hiện và các

giao dịch tương ứng. Trong một nghiên cứu năm 2006 của mình, Dietz nói rằng lý

thuyết � bao gồm bốn tiên đề, đó là tiên đề hoạt động, tiên đề giao dịch, tiên đề thành

phần, và các tiên đề phân biệt. Bốn tiên đề này cũng như là các định lý về tổ chức.

Tiên đề hoạt động nói rằng các hoạt động của tổ chức được thiết lập bởi các hoạt

động của những người thực hiện trong tổ chức. Họ thực hiện hai loại hành vi: hành vi

sản xuất, viết tắt là hành vi P, và hành vi phối hợp, viết tắt là hành vi C. Những hành

động này có kết quả nhất định, đó là sự kiện P và sự kiện C tương ứng. Bằng cách thực

hiện hành vi P, người thực hiện giúp tạo ra hàng hóa hoặc dịch vụ hoặc thông tin hoặc

dữ liệu và những kết quả này được gửi đến người khác. Một hành động P có thể là

hành động vật chất hoặc phi vật chất. Chẳng hạn như hành động sản xuất ra một hàng

hóa là hành động vật chất, trong khi đó hành động ra quyết định của ban giám đốc là

một hành động phi vật chất.

Tiên đề giao dịch cho biết hành vi phối hợp được thực hiện như các bước trong

mô hình phổ quát. Các giao dịch này lúc nào cũng liên quan đến hai tác nhân. Họ đều

17

nhằm mục đích là đạt được một kết quả cụ thể, đó là sự kiện P. Hình 2.5 và 2.6 cho

thấy các mô hình giao dịch chuẩn. Một giao dịch phát triển theo ba giai đoạn: giai

đoạn ra lệnh (giai đoạn O), giai đoạn thực hiện (giai đoạn E), và giai đoạn kết quả (giai

đoạn R). Một trong hai tác nhân được gọi là người khởi xướng còn người kia chấp

hành của các giao dịch. Trong giai đoạn ra lệnh, người khởi xướng và người thực hiện

thảo luận để đạt được sự đồng thuận về sự kiện P mà người thực hiện sẽ tạo ra cũng

như thời gian dự kiến của công việc này. Ở đoạn thực hiện, người thực hiện tạo sự

kiện P đã được thảo luận trước đó. Trong giai đoạn kết quả, người khởi xướng và

người thực hiện thảo luận để đạt được sự đồng thuận về sự kiện P đã thực sự được tạo

ra cũng như thời gian thực tế để làm điều đó. Chỉ khi đạt đươc thỏa thuận này thì sự

kiện P mới tồn tại. Chi tiết về giao dịch giữa hai tác nhân được mô tả như hình dưới

bởi Dietz.

Hình 2.5: Mẫu giao dịch chuẩn (Dietz) [5][6][11]

18

Hình 2.6: Kí hiệu giao dịch chuẩn trong mô hình DEMO [11].

Trong hình 2.5, trên cùng là giai đoạn ra lệnh. Ở giai đoạn này, đầu tiên người

khởi xướng sẽ ra một yêu cầu tới người thực hiện (rq). Sau đó người thực hiện xem xét

và có hai hướng giải quyết, một là từ chối (dc) nếu cảm thấy không khả thi, hai là cam

kết sẽ làm. Nếu người thực hiện từ chối, hai người sẽ thương thảo lại (dc hai vòng

tròn) và người ra yêu cầu có hai hướng đi, hoặc là ra yêu cầu lại hoặc là không ra yêu

cầu nữa. Trong trường hợp người thực hiện cam kết sẽ thực hiện (pm) thì hai người sẽ

đi đến thỏa thuận về lời hứa trên. Sau khi cam kết sẽ thực hiện, quy trình chuyển sang

giai đoạn xử lý (giai đoạn O). Khi giai đoạn xử lý kết thúc, quy trình chuyển sang giai

đoạn kết quả. Ở đầu giai đoạn này, người thực hiện tuyên bố về công việc mà mình đã

thực hiện (st) với người ra yêu cầu. Người ra yêu cầu có hai hướng, một là chấp nhận

(ac) kết quả, khi đó quy trình kết thúc, ngược lại là chối bỏ (rj), hai người thảo luận lại

(rj hai vòng tròn) về vấn đề và người thực hiện có thể tuyên bố lại hoặc kết thúc (sp).

Tiên đề thành phần nói về mối quan hệ của các giao dịch và các sự kiện tạo ra kết

quả của chúng. Tiên đề này có nội dung là mọi giao dịch đều được bao bọc trong một

số giao dịch khác. Có một ví dụ kinh điển được các nhà khoa học lấy làm ví dụ cho

tiên đề này đó là xem xét quá trình lắp ráp một chiếc xe đạp. Việc tạo nên một chiếc xe

đạp không phải chỉ do một hành động mà là sự lắp ráp của một số phần (nguyên tử).

Một phần nguyên tử không thể được lắp ráp từ các thành phần khác. Một chiếc xe có

thể xem xét như là một cấu trúc cây của các phần, cả các phần nguyên tử và các cụm

lắp ghép. Việc tạo ra mỗi phần là kết quả của một giao dịch hoàn chỉnh. Trình tự logic

của cấu trúc thành phần sẽ thiết đặt trình tự mà các giao dịch sẽ được thực hiện.

Tiền đề khác biệt cho biết có ba khả năng khác nhau của con người trong vai trò

người thực hiện công việc, đó là trình diễn, thông tin và theo mẫu. Những khả năng

này được ghi nhận vào trong cả hai loại hành động mà họ thực hiện.

19

Cuối cùng là định lý tổ chức. Định lý này phát biểu rằng tổ chức của doanh

nghiệp là một hệ thống xã hội được hình thành như là sự tích hợp của ba hệ thống

đồng nhất: tổ chức B, tổ chức I và tổ chức D. Tác nhân D trong tổ chức D hỗ trợ tác

nhân I trong tổ chức I trong khi tác nhân I trong tổ chức I hỗ trợ tác nhân B trong tổ

chức B.

Trước đây ta chưa từng nói đến một tác nhân B là một tác nhân O, một tác nhân I

hay là một tác nhân D. Các nhà nghiên cứu xem xét trong nghiên cứu của mình tổ

chức B là tổ chức chỉ chứa tác nhân O. Cả ba hệ thống được gọi là các hệ thống khía

cạnh của tổ chức tổng thể của doanh nghiệp. Một hệ thống có thể được nhìn nhận từ

hai quan điểm khác nhau, đó là quan điểm chức năng hoặc quan điểm cấu trúc. Do đó

chức năng của hệ thống hỗ trợ (chẳng hạn tổ chức I) là cung cấp cấu trúc của hệ thống

được hỗ trợ (chẳng hạn tổ chức B). Sự tích hợp giữa ba tổ chức được hình thành thông

qua sự gắn kết thống nhất của con người. Cụ thể, lấy tổ chức I làm điểm khởi đầu, theo

quan điểm chức năng, tổ chức I cung cấp dịch vụ thông tin cho tổ chức B, tức là các

tác nhân O. Tuy nhiên, làm thế nào để một tác nhân O thực sự nhận được thông tin từ

một tác nhân I? Điều này cần đến tiên đề khác biệt [11].

2.2. Mô hình hóa tổ chức dựa trên các lý thuyết về tổ chức

2.2.1. Giới thiệu

Phần này tập trung vào cách thông thường để mô hình hóa bản chất của một tổ

chức trong miền kỹ thuật doanh nghiệp. Phương pháp được sử dụng ở đây là DEMO,

viết tắt của Design and Engineering Methodology for Organization. Tổ chức của một

doanh nghiệp được hiểu như là một tổ chức xã hội và được tích hợp từ ba tổ chức khía

cạnh là tổ chức B, tổ chức I và tổ chức D [7].

Hình 2.7: Ba tổ chức khía cạnh của một tổ chức [7]

20

Ba tổ chức khía cạnh của một tổ chức được Dietz mô hình hóa như tháp tam giác

trong hình 2.7. Trong tháp này, các tổ chức tầng dưới hỗ trợ cho tầng trên. Việc xây

dựng các mô hình ontology cho tổ chức I và tổ chức D được gọi là nhận thức rõ về tổ

chức [11]. Phần tiếp theo sẽ tập trung vào vấn đề nhận thức rõ về tổ chức (realizing the

organization). Trong đó tổ chức có thể hiểu là một doanh nghiệp, một phần của doanh

nghiệp hoặc vượt quá phạm vi của một doanh nghiệp.

2.2.2. Mô hình tổ chức

Dietz phân biệt 4 loại mô hình khía cạnh khác nhau cho ontology của một doanh

nghiệp, được gọi là mô hình bản chất của nó. Phần này sẽ trình bày chi tiết về bốn loại

mô hình khía cạnh này. Và trong quá trình trình bày, một ví dụ cụ thể sẽ được đưa vào

để làm rõ hơn vấn đề này.

Đầu tiên xin được mô tả sơ lược về tổ chức được đưa vào làm ví dụ, là công ty

Ren–A–Car (RAC). Đây là một công ty cho thuê xe ô tô, bao gồm các chi nhánh phân

tán theo địa lý. Những chiếc xe của RAC được chia thành các nhóm xe (các thương

hiệu và mẫu); với mỗi nhóm xe có một tỷ lệ cho thuê cụ thể của mỗi ngày. Một chiếc

xe có thể được thuê bởi một người đặt hàng trước hoặc bởi một người vào thuê đột

xuất. Một hợp đồng cho thuê ghi rõ ngày bắt đầu và kết thúc của dịch vụ cho thuê. Chi

nhánh nơi bắt đầu cho thuê được gọi là chi nhánh pick-up, chi nhánh nơi kết thúc dịch

vụ thuê gọi là chi nhánh drop-off. Một dịch vụ cho thuê có thời hạn cho thuê rõ ràng.

Người thuê xe được gọi là người thuê. Người sẽ lái xe được gọi là lái xe. Một dịch vụ

thuê chỉ được bắt đầu nếu người lái xe có bằng lái xe hợp lệ. Ngoài ra, một chiếc xe

của loại được yêu cầu (hoặc một sự thay thế) phải có sẵn. Ngay sau khi xe của một

dịch vụ thuê được đưa đến chi nhánh drop-off, việc cho thuê có thể được kết thúc, với

điều kiện là phí phát sinh đã được thanh toán. Khoản phí này có thể bao gồm một số

yếu tố. Trước tiên, có phí cơ bản (số lần ngày tỷ lệ mỗi ngày). Tiếp theo, có thể có một

khoản phí phạt vì vượt quá thời gian này (số ngày thêm lần mức hình phạt trở lại

muộn). Cuối cùng, một phí khác phải trả nếu xe được trả tại một chi nhánh khác so với

thoả thuận (phí này phụ thuộc vào khoảng cách giữa các chi nhánh).

Mô hình thứ nhất là mô hình cấu trúc (Construction Model – CM), quy định cụ

thể các loại giao dịch được định nghĩa và các vai trò tác nhân được kết hợp, cũng như

các đường liên kết thông tin giữa các vai trò tác nhân và các ngân hàng thông tin;

nghĩa là, CM quy định cụ thể cấu trúc của một tổ chức. Đây là mô hình súc tích nhất.

Mô hình CM được chia thành hai phần: IAM (Interaction Model) và ISM

(Interstriction Model). IAM mô tả các loại giao dịch và các vai trò tác nhân được thừa

21

nhận tham gia vào như là người khởi tạo hoặc người thực thi. Các loại giao dịch cùng

với các loại kết quả được kết hợp được định nghĩa trong bảng kết quả giao dịch

(Transaction Result Table – TRT). ISM thì khác, nó cho biết các liên kết thông tin

giữa các vai trò tác nhân và các ngân hàng. Nội dung của các ngân hàng được định

nghĩa bởi các bảng nội dung ngân hàng (Bank Contents Table – BCT).

Hình 2.8: Mô hình CM của RAC [7]

Hình trên mô tả về mô hình CM của tổ chức thực hiện dịch vụ cho thuê xe RAC

nói trên. Đầu tiên tác nhân B-CA01 khởi tạo một dịch vụ và yêu cầu đến quản lý B-

A01. Hai người này thực hiện giao dịch B-T01. B-A01 sử dụng hai ngân hàng là ngân

hàng dữ liệu RAC (B-APB01) và ngân hàng về dữ liệu khách hàng (B-APB02) để

kiểm tra điều kiện cho dịch vụ. Nếu các thông tin và tài nguyên đáp ứng được yêu cầu

thì tác nhân B-AC03 yêu cầu đến B-CA03 để xử lý cho thuê xe (nhận xe tại chi nhánh

này) và hai người thực hiện giao dịch B-T03. Tương tự thì các tác nhân B-CA04 và B-

CA05 cũng được yêu cầu để thực hiện các giao dịch B-T04 và B-T05 tương ứng. Đó là

nhận xe và thanh toán. Cuối cùng, B-A01 và A-CA02 thực hiện giao dịch B-T02 để

kết thúc dịch vụ.

Dưới đây là bảng kết quả của các giao dịch được thực hiện trong mô hình và

bảng nội dung ngân hàng (BCT) [7].

22

Bảng 2-1: Bảng kết quả giao dịch (TRT)

Bảng 2-2: Bảng nội dung ngân hàng (BCT)

Mô hình khía cạnh thứ hai là mô hình quy trình (PM). PM đặc tả không gian

trạng thái và không gian giao dịch của sự kết hợp trong tổ chức. Ngoài ra PM còn chứa

nguyên nhân và các mối quan hệ điều kiện giữa các giao dịch. Một tập các giao dịch

có liên quan đến nguyên nhân được gọi là một quy trình kinh doanh. Hình dưới đây

mô tả mô hình PM của dịch vụ cho thuê xe của công ty RAC. Mô hình PM như một

cấu trúc cây của quy trình thực hiện dịch vụ cho thuê. Trong đó có thể hiện rằng có thể

có giao dịch nằm trong một giao dịch khác. Chẳng hạn như giao dịch rental payment

nằm trong giao dịch rental end. Các đường nét đứt biểu thị sự chờ đợi thông tin. Các ô

23

vuông nhỏ màu xám thể hiện sự phối hợp. Những hình đĩa kéo dài thể hiện có một

khoảng thời gian ở các trạng thái.

Hình 2.9: Mô hình PM của RAC [7]

Mô hình khía cạnh thứ ba, mô hình hoạt động (AM), quy định cụ thể các quy tắc

hoạt động có trách nhiệm như là hướng dẫn cho các tác nhân trong việc giải quyết

công việc cần phải làm của họ. AM chứa một hoặc nhiều quy tắc hoạt động cho tất cả

các loại công việc phải làm. AM là mô hình khía cạnh toàn diện nhất và chi tiết nhất.

Ở mức ontology của sự trừu tượng hóa, không có gì bên dưới mô hình hoạt động nữa.

Nghĩa là, đây là mô hình chi tiết nhất. Dưới đây là mô hình AM của tác nhân B-A01

[7].

24

Mô hình khía cạnh thứ tư là mô hình sự kiện (FM). Dưới đây là FM của RAC

[7].

Hình 2.10: Mô hình sự kiện (FM) của RAC [7]

25

Mô hình sự kiện quy định không gian trạng thái và không gian giao dịch của một

thế giới sản xuất: các lớp đối tượng và các loại sự kiện, các loại kết quả, và các quy tắc

cùng tồn tại của ontology. FM có thể xem như là chi tiết hóa của một phần của CM, cụ

thể là nội dung của ngân hàng thông tin (đặc biệt là các ngân hàng sản xuất).

2.2.3. Mô hình hóa tổ chức B

Theo Joop de Jong, từ mô hình CM của tổ chức, phần tương tác của mô hình CM

của tổ chức B được suy ra. Theo đó, mô hình mới không chứa các đường liên kết

thông tin. Các đường liên kết thông tin được thể hiện trong mô hình được tích hợp từ

tổ chức B và tổ chức I như các giao dịch thông tin. Bên cạnh đó, mô hình PM và mô

hình FM cũng không có sự thay đổi giữa mô hình bản chất tổ chức và mô hình tổ chức

B. Chẳng hạn, ta có mô hình CM của một quầy bán pizza như sau [11]:

Hình 2.11: Mô hình CM của quầy bán bánh pizza [11].

Từ mô hình CM trên, mô hình CM của tổ chức B được sinh ra như hình dưới.

trong đó các đường liên kết thông tin đã được bỏ đi (hình 2.12).

26

Hình 2.12: Mô hình CM của tổ chức B của quầy bán bánh pizza [11]

2.2.4. Xây dựng mô hình tổ chức I từ tổ chức B

Việc xây dựng tổ chức I bao gồm các bước: sử dụng mô hình GSDP để phát triển

một tổ chức I, xác định các giao dịch thông tin và cuối cùng là mô hình hóa tổ chức I

[11].

2.2.4.1. Áp dụng mô hình GSDP

Theo mô hình quy trình phát triển hệ thống tổng quát, gọi tắt là GSDP, hệ thống

đối tượng (OS) được thiết kế và chế tạo từ hệ thống đang dùng (US). Quy trình phát

triển tổ chức I có thể được xem như là một thể hiện của mô hình GSDP, tổ chức B

được hiểu như là US còn tổ chức I được hiểu như là OS (hình 2.13).

Sau đây sẽ thảo luận chi tiết hơn. Trong mô hình GSDP, OS là hệ thống được

thiết kế, chế tạo và thực hiện. US là hệ thống sẽ sử dụng các chức năng hoặc dịch vụ

được cung cấp bởi OS. Một hệ thống có thể hỗ trợ một số hệ thống khác thông qua các

chức năng của nó. Chức năng của OS không chứa bất cứ thông tin nào về cấu trúc của

nó. Việc phát triển một OS bao gồm ba pha: thiết kế, chế tạo và thực hiện [8].

Bước thứ nhất, các yêu cầu chức năng sẽ được xác định. Bước này bắt đầu từ cấu

trúc của US và kết thúc với các chức năng của OS. Có thể xem như là một mô hình

hộp đen làm rõ hành vi của OS rút ra từ các mối quan hệ chức năng giữa đầu vào và

27

đầu ra của OS. Trong bước này, toàn bộ dịch vụ được yêu cầu bởi các tác nhân của US

sẽ được phân tích. Các dịch vụ được yêu cầu bởi mô hình cấu trúc của tổ chức B bao

gồm hai phần. Thứ nhất, các dịch vụ để ghi nhớ các sự kiện C và sự kiện P được tạo

mới và dịch vụ thứ hai cho việc phân phối (cung cấp) các sự kiện và các sự kiện gốc

để hỗ trợ thông tin cho các tác nhân B từ US [8][11].

Hình 2.13: Xây dựng tổ chức I từ tổ chức B [11].

Trong bước thứ hai, các đặc tả sẽ được đưa ra. Bắt đầu với chức năng được đặc tả

của hệ thống US và kết thúc với mô hình cấu trúc cao nhất của hệ thống OS. Ở đây là

mô hình cấu trúc cao nhất của tổ chức I. Toàn bộ thiết kế của một hệ thống được hiểu

là một quá trình phân tích xen kẽ và các bước tổng hợp. Phân tích là bước làm cho vấn

đề được hiểu rõ hơn, tổng hợp là bước mà làm cho giải pháp rõ ràng hơn. Mô hình cấu

trúc của tổ chức I bao gồm cấu trúc của cả hai loại dịch vụ được xác định (cụ thể là

cấu trúc cho việc ghi nhớ các sự kiện C và các sự kiện P) và cấu trúc cho việc tái tạo

các sự kiện gốc. Các sự kiện có nguồn gốc chính là các sự kiện được xác định bởi việc

thực hiện các hành động trí tuệ, như là lý luận, tính toán,…trên các sự kiện gốc. Các

hành động trí tuệ có thể được hiểu như là các hành động được tiến hành theo các giải

thuật hoặc thủ tục đã biết. Các sự kiện gốc không hề được sinh ra bởi hoạt động này.

Trong bước thứ ba, việc chế tạo hệ thống đã được thiết kế sẽ diễn ra. Việc chế

tạo của một hệ thống là quy trình mà một số của các mô hình hộp trắng, hoặc các mô

hình cấu trúc được sinh ra. Việc chế tạo bắt đầu từ mô hình ontology và kết thúc với

mô hình thực hiện cuối cùng. Trái ngược với thiết kế, chế tạo không mang tính chất trí

tuệ mà mang ý nghĩa thủ công hơn. Mô hình hộp trắng này làm rõ cấu trúc nội bộ và

28

hoạt động của OS về sự hợp tác giữa các thành phần để cung cấp các sản phẩm với

môi trường của nó.

Trong bước thứ tư, việc thực hiện của mô hình đã được chế tạo sẽ được tiến

hành. Việc thực hiện được hiểu là việc phân bổ các phương tiện kỹ thuật đến các phần

tử trong mô hình thực hiện, do đó hệ thống có thể được đưa vào hoạt động.

2.2.4.2. Các loại giao dịch giữa tổ chức B và tổ chức I

Mô hình cấu trúc cao nhất của tổ chức I chứa cấu trúc của hai loại hình dịch vụ.

Một là, các loại dịch vụ để ghi nhớ sự kiện C và sự kiện P. Hai là, các loại dịch vụ để

cung cấp các sự kiện ban đầu cũng như để cung cấp sự kiện có nguồn gốc, được định

nghĩa cả bên trong và bên ngoài tổ chức, nhằm hỗ trợ thông tin cho tác nhân B [8]. Ở

đây sự cần phân biệt hai loại sự kiện. Thứ nhất, sự kiện có nguồn gốc (derived fact) là

loại sự kiện có liên quan đến (được hợp thành từ) các sự kiện nguyên tử. Thứ hai, sự

kiện gốc (original fact) là các sự kiện nguyên tử, được sinh ra và lưu trữ trước đó.

Vấn đề quan trọng chúng ta cần xem xét là “các giao dịch giữa tổ chức B và tổ

chức I hình thành như thế nào”. Thứ nhất, theo tiền đề khác biệt của lý thuyết �, một

chủ thể hoàn thành vai trò tác nhân luôn hoạt động với một trong ba khả năng là trình

diễn, thông tin hoặc theo mẫu. Thứ hai, theo thuyết hệ thống cả Bunge thì các giao

dịch giữa các tác nhân chỉ có thể xảy ra giữa các tác nhân cùng loại. Như vậy, trên

thực tế, một giao dịch giữa một tác nhân B và một tác nhân I là không tồn tại. Tuy

nhiên, trong trường hợp mà một tác nhân B nhận thông tin được yêu cầu thì sao? Thứ

nhất, chủ thể đảm nhiệm vai trò tác nhân B cần phải hình thành khả năng thông tin.

Thứ hai, một chủ thể với khả năng thông tin của nó có thể khởi tạo một giao dịch với

một tác nhân I như là một tác nhân I bên ngoài.

29

Hình 2.14: Các loại tác nhân kết hợp giữa tổ chức B và tổ chức I [8]

Hình 2.14 trình bày các loại giao dịch có thể xảy ra trong việc thực hiện các dịch

vụ từ cả hai loại dịch vụ. Hình 1) liên quan đến loại dịch vụ thứ nhất. Các giao dịch

trong hình 2) đến hình 4) liên quan đến loại dịch vụ thứ hai. Kí tự đầu tiên của mã tác

nhân đại diện cho loại tác nhân (B – tác nhân B, I – tác nhân I, D – tác nhân D). Chi

tiết hóa nội dung hình 2.14 như sau:

1) Chủ thể đảm nhiệm tác nhân B (B-A01) từ khả năng trình diễn của nó sang

khả năng thông tin của nó. Nó trình bày một sự kiện C hoặc sự kiện P và

khởi tạo, như là một tác nhân I bên ngoài, một giao dịch với tác nhân I có mã

I-A01. Kết quả của giao dịch sẽ là sự ghi nhớ của sự kiện gốc C hoặc P.

2) Chủ thể đảm nhiệm tác nhân B (B-A01) từ khả năng trình diễn của nó sang

khả năng thông tin của nó trình bày và khởi tạo như một tác nhân I bên ngoài

một giao dịch với tác nhân I có mã I-A02. Chủ thể khởi tạo yêu cầu phát sinh

một sự kiện gốc.

30

3) Chủ thể đảm nhiệm tác nhân B (B-A01) từ khả năng trình diễn của nó sang

khả năng thông tin của nó trình bày và khởi tạo như một tác nhân I bên ngoài

một giao dịch với tác nhân I có mã I-A03. Chủ thể khởi tạo yêu cầu một sự

kiện có nguồn gốc được định nghĩa trong mô hình trạng thái của tổ chức hiện

tại.

4) Chủ thể đảm nhiệm tác nhân B (B-A01) từ khả năng trình diễn của nó sang

khả năng thông tin của nó trình bày và khởi tạo như một tác nhân I bên ngoài

một giao dịch với tác nhân I có mã I-A04. Chủ thể khởi tạo yêu cầu một sự

kiện có nguồn gốc được định nghĩa bên ngoài mô hình trạng thái của tổ chức

hiện tại.

2.2.4.3. Mô hình IAM của tổ chức I

2.2.4.3.1. Ghi nhớ sự các sự kiện

Tiếp tục sử dụng ví dụ về quầy pizza đã giới thiệu trong phần trước, đầu tiên

là việc ghi nhớ các sự kiện trong tổ chức I.

Hình 2.15: Mô hình IAM ghi nhớ sự kiện của tổ chức I [11]

Các sự kiện C và sự kiện P được tạo ra bởi các tác nhân O và được ghi nhớ

bởi các tác nhân I. Việc ghi nhớ một sự kiện có thể hiểu như là các hoạt động sản

xuất thông tin để gọi lại sự kiện có liên quan sau này (hình 2.15).

31

Trong hình trên, một tác nhân O, được gọi là O-Ai trong phạm vi tổ chức B

tạo ra các sự kiện mới (sự kiện C và sự kiện P). Những sự kiện này được ghi nhớ

bởi các tác nhân I có mã I-Aij[0,1] (‘i’ là số rol, ‘j’ là kiểu dịch vụ, ‘0’ là sự kiện

C còn ‘1’ là sự kiện P). Khách hàng O-CA10 là một tác nhân bên ngoài tổ chức.

Các tác nhân bên ngoài I-CA1010 và I-CA1011 ghi nhớ tất cả các sự kiện C và

sự kiện P tương ứng, được tạo ra bởi O-CA10.

2.2.4.3.2. Tái tạo các sự kiện

Chúng ta sẽ đi mô hình hóa tổ chức I trong trường hợp dịch vụ là tái tạo sự

kiện. Như trên đã nói, có hai loại sự kiện được tái tạo đó là sự kiện có nguồn gốc

và sự kiện gốc. Hình 2.16 thể hiện các giao dịch giữa các tác nhân B và tác nhân

I cũng như giữa các tác nhân I với nhau để cung cấp dịch vụ. Như hình 2.14 đã

trình bày, đối với dịch vụ tái tạo sự kiện thì có ba loại: tái tạo sự kiện gốc, tái tạo

sự kiện có nguồn gốc nội bộ và tái tạo các sự kiện có nguồn gốc bên ngoài

(phòng ban khác). Chẳng hạn ta có ba tác nhân của tổ chức B với ba yêu cầu

khác nhau tới tổ chức I như hình 2.16. Thứ nhất, tác nhân B-A01 yêu cầu tác

nhân I-A01 của tổ chức I tái tạo sự kiện gốc, I-A01 thực hiện giao dịch I-T01 để

đáp ứng yêu cầu này của B-A01 (giả sử điều kiện lý tưởng là yêu cầu được đáp

ứng). Thứ hai, tác nhân B-A02 yêu cầu tác nhân I-A02 tái tạo sự kiện có nguồn

gốc. Nếu tác nhân I-A02 có thể cung cấp đầy đủ thông tin được yêu cầu (nó biết

chính xác các sự kiện gốc để hình thành nên sự kiện này) thì nó phản hồi trực

tiếp cho B-A02. Ngược lại thì I-A02 phải thực hiện các giao dịch I-T021 và I-

T022 tương ứng với các tác nhân I-A021 và I-A022 để thu thập các sự kiện gốc

sau đó cung cấp sự kiện có nguồn gốc được B-A02 yêu cầu. Giao dịch giữa B-

A02 và I-A02 là I-T02. Cuối cùng ta xét đến tác nhân B-A03. Tác nhân này yêu

cầu I-A03 cung cấp sự kiện có nguồn gốc bên ngoài. Trong trường hợp này, I-

A03 cần phải giao dịch với tổ chức ngoài để lấy các sự kiện gốc và cung cấp cho

B-A03 qua giao dịch I-T03. Hình 2.16 biểu diễn trong phạm vi của một tổ chức

nên không biểu thị sự tương tác của I-A03 với tổ chức ngoài.

32

Hình 2.16: Mô hình IAM tái tạo sự kiện [8]

2.2.5. Xây dựng mô hình tổ chức D từ tổ chức I

Phần này chúng ta sẽ xem xét việc xây dựng mô hình tổ chức D từ mô hình tổ

chức I. Một tác nhân B với khả năng trình diễn của nó không thể khởi tạo một giao

dịch với bất cứ tác nhân D nào như giữa các tác nhân D với nhau [8]. Thứ nhất, không

thể trực tiếp đặt thẳng một tài liệu vào một ngân hàng. Theo Dietz, một số hành động

thông minh cần được xử lý trước, chẳng hạn như xác định nơi lưu trữ. Việc này cần

được thực hiện bởi tác nhân I. Thứ hai, lấy một tài liệu trực tiếp ra ngoài một ngân

hàng cũng là không khả thi. Trước khi lấy tài liệu, cần phải biết nơi nó được lưu trữ.

Việc tìm kiếm nơi lưu trữ nó chỉ có thể được thực hiện bởi một hành động thông minh

và được xử lý bởi tác nhân I. Tóm lại, việc ghi nhớ và tái tạo các tài liệu luôn phải

được thực hiện bởi tổ chức I. Không có một liên kết trực tiếp nào giữa tổ chức B và tổ

chức D. Đây chính là lý do cho việc xây dựng tổ chức D từ tổ chức I.

2.2.5.1. Áp dụng mô hình GSDP

33

Tương tự như việc phát triển tổ chức I từ tổ chức B, quy trình phát triển của tổ

chức D có thể được xem như là một thể hiện của GSDP. Ở đây tổ chức I được hiểu

như là US còn tổ chức D được hiểu như là OS (hình 2.17).

Hình 2.17: Xây dựng tổ chức D từ tổ chức I [11].

Bước thứ nhất, các yêu cầu chức năng sẽ được xác định. Bước này bắt đầu từ cấu

trúc của US và kết thúc với các chức năng của OS. Trong bước này, toàn bộ dịch vụ

được yêu cầu bởi các tác nhân được của US sẽ được phân tích. Các dịch vụ được yêu

cầu bởi mô hình cấu trúc của tổ chức I bao gồm hai phần. Thứ nhất, các dịch vụ để lưu

trữ các sự kiện C và sự kiện P để ghi nhớ và thứ hai là các dịch vụ cho việc thu thập dữ

liệu sự kiện tương ứng với sự kiện để tái tạo.

Trong bước thứ hai, các đặc tả sẽ được đưa ra. Bắt đầu với chức năng được đặc tả

của hệ thống US và kết thúc với mô hình cấu trúc cao nhất của hệ thống OS. Mô hình

cấu trúc của tổ chức D bao gồm cấu trúc của cả hai loại dịch vụ đó là lưu trữ các sự

kiện C và sự kiện P, và thu thập dữ liệu sự kiện để hỗ trợ các tác nhân I thực hiện việc

tái tạo với các sự kiện tương ứng. Các tác nhân D làm việc với nhau để hỗ trợ các tác

nhân I với các hành động liên quan đến tài liệu như là lưu trữ, triệu hồi và chuyển đổi.

Chúng ta biết rằng, sự kiện có nguồn gốc không chỉ có ý nghĩa mà nó còn có

hình thức. Ví dụ, một văn bản viết, một hình ảnh, một âm thanh, một cử chỉ, một liên

lạc. Tóm lại, thông tin liên lạc giữa mọi người có thể được thực hiện bằng tất cả các

giác quan của chúng ta. Nó có thể được thực hiện bằng một số loại tài liệu. Tổ chức D

trong một tổ chức bao gồm tất cả các tác nhân hành động sản xuất trên các tài liệu để

34

hỗ trợ các tác nhân từ tổ chức I. Những hành động được gọi là hành động datalogical

[8].

2.2.5.2. Các loại giao dịch giữa tổ chức I và tổ chức D

Mô hình cấu trúc của tổ chức D bao gồm cấu trúc của hai loại dịch vụ. Thứ nhất

là loại dịch vụ lưu trữ các sự kiện C và sự kiện P mới được tạo để ghi nhớ và thứ hai là

loại dịch vụ thu thập dữ liệu sự kiện tương ứng với các sự kiện để tái tạo. Rõ ràng một

tác nhân I và một tác nhân D không thể tạo ra một giao dịch như giữa hai tác nhân D

với nhau. Do đó người khởi tạo giao dịch trước hết phải hình thành khả năng theo mẫu

trước khi tạo một giao dịch như là một tác nhân D bên ngoài với một tác nhân D bên

trong tổ chức D [8].

Hình 2.18: Các loại tác nhân kết hợp giữa tổ chức I và tổ chức D [8].

Hình 2.18 mô tả các loại giao dịch của cả hai loại dịch vụ là lưu trữ dữ liệu và thu

thập dữ liệu. Kí hiệu đầu tiên trong mã tác nhân xác định loại tác nhân, cụ thể là I là

tác nhân I, D là tác nhân D.

1) Chủ thể hoàn thành vai trò tác nhân I (I-A01) hình thành từ khả năng thông

tin của nó vào khả năng trình diễn của nó và khởi tạo (như là một tác nhân D

bên ngoài) một giao dịch với tác nhân D D-A01. Chủ thể khởi tạo yêu cầu

cho việc lưu trữ một gói dữ liệu tương ứng với sự kiện để ghi nhớ.

2) Chủ thể hoàn thành vai trò tác nhân I (I-A02) hình thành từ khả năng thông

tin của nó vào khả năng trình diễn của nó và khởi tạo (như là một tác nhân D

bên ngoài) một giao dịch với tác nhân D D-A02. Chủ thể khởi tạo yêu cầu

cho việc thu thập một gói dữ liệu tương ứng với sự kiện để tái tạo.

35

2.2.5.3. Mô hình IAM của tổ chức D

Trước tiên ta sẽ đi làm rõ hai loại dịch vụ nói trên. Chuỗi cung cấp thông tin có

thể có hai loại. Loại thứ nhất bao gồm các bước mà một sự kiện bắt đầu tồn tại đến khi

nó được lưu vào một ngân hàng sự kiện.

Loại thứ nhất của chuỗi cung cấp thông tin bắt đầu với tác nhân B B-A02. Tác

nhân này tạo một sự kiện gốc mới, chẳng hạn như việc mua một chiếc xe. Sau sự chấp

nhận sự kiện P bởi B-A01 thì sự kiện P mới thực sự bắt đầu tồn tại. Sự kiện P này phải

được lưu trữ trong ngân hàng sự kiện tương ứng với B-T02. B-A02 hình thành khả

năng thông tin của nó, xây dựng sự kiện P và khởi tạo (giống như một tác nhân I ở bên

ngoài tổ chức I) giao dịch I-T01 với tác nhân I-A01 bên trong tổ chức I cho việc ghi

nhớ sự kiện P. Tác nhân I hoàn thành hành động thông tin theo giải thuật hoặc thủ tục.

I-A01 (người ghi nhớ) thêm một định danh cho sự kiện P và xác định nơi lưu trữ nó.

Mặc dù sự kiện P được hiểu là mang ý nghĩa ngữ nghĩa, nó luôn phải có một giá (ngăn

lưu trữ). Giá của sự kiện P không liên quan tới các tác nhân I. Nó có thể là một tài liệu

tạp chí, một tài liệu số, một hình ảnh hoặc bất cứ một thứ gì khác. Các tác nhân bên

trong tổ chức I và giữa tổ chức B với tổ chức I chỉ chuyển đổi ý nghĩa ngữ nghĩa. Hơn

nữa những tác nhân này hoạt động trên khả năng thông tin của họ.

Thực tế việc ghi nhớ sự kiện P, người ghi nhớ I-A01 hình thành trong khả năng

trình diễn của nó và yêu cầu (như một tác nhân D bên ngoài của tổ chức D) người lưu

trữ D-A01 để lưu trữ dữ liệu sự kiện tương ứng của sự kiện P. Trong suốt những bước

này, ngữ nghĩa của tài liệu là không liên quan, chỉ có mẫu của tài liệu là quan trọng.

Sau đó, D-A01 khởi tạo giao dịch và kích hoạt người truyền cho việc chuyển tài liệu

tới đích của nó và kích hoạt người lưu trữ cho việc lưu trữ tài liệu.

Chúng ta hãy xem xét hai ví dụ cho trường hợp này. Ví dụ đầu tiên là ví dụ mà

các vai trò tác nhân trong hình 2.19 được thực hiện bởi các chủ thể khác nhau.

Đầu tiên, một thành viên có mong muốn tên John (B-A01) yêu cầu Bill (B-A02)

cho một thành viên của thư viện. Bill hứa với Jonh sẽ đăng kí thành viên cho anh ấy.

Bill hình thành đăng kí dựa trên một số thông tin mà anh ấy lấy được từ John. Sau đó

anh ấy yêu cầu Tom (I-A01) cho việc ghi nhớ sự đăng kí này. Tom hứa rằng anh ấy sẽ

ghi nhớ đăng kí thành viên được yêu cầu. Mặc dù anh ấy biết rằng một đăng kí hoàn

chỉnh là một sự kiện gốc được tạo mới, anh ấy cần một định danh cho việc tìm lại đăng

kí này về sau trong nơi lưu dữ liệu. Tom xác định định danh và liên kết nó tới đăng kí.

Từ đây, đăng kí đã được định danh bởi một định danh và được bảo quản một nơi an

36

toàn. Tiếp theo, dựa trên định danh Tom xác định một nơi lưu trữ an toàn và yêu cầu

Jim cho việc lưu trữ gói dữ liệu được xác định duy nhất vào trong kho lưu trữ. Jim sẽ

hoàn thành yêu cầu này và yêu cầu một người chuyển đổi và một người lưu trữ mang

nó vào kho lưu trữ đã xác định trước. Sau khi việc lưu trữ được hoàn thành, Tom nhận

một tuyên bố từ Jim. Tom ghi nhận rằng việc lưu trữ đã được thực hiện và gửi một

tuyên bố tới Bill rằng việc ghi nhớ đã được sắp xếp một cách chính xác. Sau khi ghi

nhận tuyên bố này, Bill gửi một tuyên bố cho John rằng đăng kí đã được thực hiện.

Sau khi được xác nhận bởi John, đăng kí đã tồn tại. Nếu John từ chối đăng kí thì cần

thực hiện các bước ngược lại các bước đã thực hiện trước đó.

Hình 2.19: Lưu trữ sự kiện P [8].

Ví dụ thứ hai là ví dụ mà các vai trò tác nhân trong hình 2.19 được thực hiện bởi

cùng một chủ thể. Giả sử rằng tất cả các bước của đăng kí được thực hiện bởi Bill. Bill

hình thành đăng kí và nhớ rằng đăng kí trong tâm trí anh ấy hoặc được lưu trữ một nơi

an toàn. Đó có thể là một chỉ số thẻ trên bàn anh ấy, và việc truyền tải là không cần,

nhưng nếu là một chỉ số thẻ ở một phòng khác thì việc truyền tải là cần thiết.

Loại thứ hai mô tả chiều ngược lại từ việc triệu hồi dữ liệu sự kiện tương ứng từ

ngân hàng sự kiện, tái tạo sự kiện có nguồn gốc dựa trên dữ liệu sự kiện gốc và cuối

cùng cung cấp sự kiện có nguồn gốc như là thông tin cho tác nhân B đã yêu cầu nó.

Hình 2.20 cho biết loại thứ hai của chuỗi. Khởi đầu cho việc triệu hồi gián tiếp được

thực hiện bởi tác nhân B, người mà cần thông tin cho hoạt động trong giao dịch với tác

nhân B được kết nối với nó. Nó được bắt đầu với một tác nhân B là B-A02. B-A02

37

hình thành khả năng thông tin và yêu cầu thông tin cần thiết. Hai loại quy trình thông

tin sự kiện được phân biệt. Thứ nhất, quy trình của việc xác định một sự kiện có nguồn

gốc được nhận thức. Sự kiện có nguồn gốc này bắt nguồn từ các hoạt động thông tin từ

các sự kiện cơ bản. Quy trình này tương ứng với một liên kết thông tin nội bộ bên

trong mô hình cấu trúc DEMO của tổ chức. Thứ hai, quá trình xác định một sự kiện

bên ngoài được phân biệt. Sự kiện bên ngài này được xác định bên ngoài ranh giới tổ

chức. Nó có thể là một sự kiện cơ bản hoặc một sự kiện có nguồn gốc. Quá trình này

tương ứng với một liên kết thông tin bên ngoài trong mô hình cấu trúc DEMO của tổ

chức.

Hình 2.20: Cung cấp các sự kiện có nguồn gốc [8].

Đầu tiên xin được thảo luận về loại quy trình thông tin phân phối các sự kiện có

nguồn gốc. B-A02 khởi tạo một giao dịch (như một tác nhân I bên ngoài của tổ chức I)

với người sản xuất của một sự kiện có nguồn gốc là I-A01. Dựa trên các sự kiện gốc

(được ghi nhớ trong tổ chức I), I-A01 sẽ cung cấp một sự kiện mới (được định nghĩa

trong Object Property List của mô hình trạng thái DEMO của tổ chức). I-A01 yêu cầu

I-A02 tái tạo các sự kiện gốc. Tuy nhiên, I-A02 chỉ có thể tái tạo nếu người này biết

định danh duy nhất và nơi lưu trữ của tài liệu tương ứng trong kho lưu trữ dữ liệu. Nếu

tác nhân I yêu cầu tác nhân D, ví dụ như yêu cầu về một hợp đồng cụ thể liên quan đến

việc phân phối các sản phẩm X của nhà cung cấp Y thì giao dịch này sẽ không thành

công bởi vì hai tác nhân sẽ không hiểu nhau. Giao dịch chỉ có thể thành công nếu tác

nhân I yêu cầu tài liệu có định danh duy nhất được lưu trữ tại nơi lưu trữ duy nhất. Câu

38

hỏi đặt ra là: làm thế nào I-A02 biết được định danh của gói dữ liệu tương ứng và định

danh của nơi lưu trữ? Trong phần trước ta đã thảo luận về người ghi nhớ (hình 2.19)

trong tổ chức I xác định định danh duy nhất và nơi lưu trữ của các sự kiện mới. Liên

quan đến câu hỏi này, chỉ có một câu trả lời khả thi: chủ thể hoàn thành vai trò tác

nhân I-A02 trong hình 2.20 phải ngang bằng với chủ thể ghi nhớ các sự kiện có liên

quan trong hình 2.18. Để lựa chọn các sự kiện cần thiết, I-A02 hình thành khả năng

theo mẫu của nó (như một tác nhân D bên ngoài của tổ chức D) và yêu cầu người thu

thập dữ liệu sự kiện D-A01 để thu thập các gói dữ liệu đã được xác định trong kho lưu

trữ cho trước. Trên thực tế, D-A01 thu thập các gói dữ liệu cần thiết bằng cách khởi

tạo một sự truyền tải và một giao dịch triệu hổi với người truyền tải D-A02 và người

triệu hồi D-A03 tương ứng.

Chúng ta hãy xem xét hai ví dụ cho trường hợp này. Ví dụ đầu tiên là ví dụ mà

các vai trò tác nhân trong hình 2.20 được thực hiện bởi các chủ thể khác nhau. Ví dụ

thứ hai là trường hợp tất cả các vai trò được thực hiện bởi cùng một chủ thể.

Ví dụ thứ nhất [8]. Marry (B-A02) đăng kí mượn sách của thư viện. Khi một số

người yêu cầu cô ấy bản đăng kí mượn, đầu tiên cô ấy sẽ kiểm tra xem số sách (những

người khác cũng đã mượn loại này) không được vượt quá số sách cho phép. Marry yêu

cầu Kim (I-A01) cung cấp cho cô ấy thông tin này. Kim hứa với Marry là sẽ cung cấp

thông tin mà cô ấy yêu cầu và cô ấy có thể thực hiện lời hứa đó bởi vì tính sẵn sàng

của giải thuật cho việc tính toán dữ liệu có nguồn gốc tương ứng. Giải thuật làm việc

trên các sự kiện gốc đã được tạo bởi các hoạt động sản xuất trước đó và được ghi nhớ

trong tổ chức I. Trước khi tính toán giải thuật đã được đề cập, Kim yêu cầu Tom (I-

A03) một hoặc nhiều lần tái tạo sự kiện gốc. Và Tom hứa là sẽ tái tạo sự kiện được

yêu cầu. Anh ấy biết định danh duy nhất cũng như nơi lưu trữ dữ liệu sự kiện tương

ứng với sự kiện bởi vì anh ấy đã xác định định danh và nơi lưu trữ cho việc ghi nhớ sự

kiện này trước đó. Tiếp theo Tom yêu cầu Jim thu thập gói dữ liệu đã được xác định

duy nhất. Jim sẽ hoàn thành yêu cầu này và yêu cầu người chuyển đổi và người triệu

hổi để nhận dữ liệu sự kiện. Sau khi việc lựa chọn được hoàn thành, Tom nhận một

tuyên bố từ Jim. Sau đó, Tom gửi cho Kim một tuyên bố rằng sự kiện được yêu cầu đã

được tái tạo. Khi tất cả các sự kiện được yêu cầu đã sẵn có thì Kim tính toán giải thuật

và gửi tuyên bố cho Marry là thông tin yêu cầu đã được tái ra.

Ví dụ thứ hai [8]. Giả sử rằng tất cả các bước của việc đăng kí được thực hiện bởi

Marry. Marry tính toán thông tin mà cô ấy cần. Cô ấy lựa chọn tất cả các sự kiện gốc

từ nơi mà cô ấy đã lưu những sự kiện này trước đó.

39

Trong hình 2.20 chỉ thể hiện một tác nhân I cho việc tính toán sự kiện có nguồn

gốc. Tuy nhiên trong thực tế sự kiện có nguồn gốc có thể được tính bởi một số tác

nhân I, mỗi người có trách nhiệm và quyền hạn riêng của mình. Khóa luận này không

đi sâu về vấn đề này.

Loại thứ hai của quy trình thông tin là phân phối thông tin bên ngoài được thể

hiện trong hình 2.21. B-A02 khởi tạo một giao dịch (như một tác nhân I bên ngoài của

tổ chức I) với người phân phối sự kiện ngoài là I-A01. Sự kiện ngoài này được xác

định bên ngoài phạm vi của tổ chức. Quy trình thông tin thuộc về một tổ chức khác.

Hoạt động giữa hai tổ chức được nói đến chi tiết trong mô hình thực hiện của tổ chức

mà trong phạm vi khóa luận này không đề cập tới.

Hình 2.21: Cung cấp các sự kiện bên ngoài [8].

40

Chương 3. Áp dụng mô hình với dịch vụ tiếp nhận và giải quyết khiếu nại

của FPT Telecom

3.1. Giới thiệu tổ chức

Được thành lập ngày 31/01/1997, Công ty Cổ phần Viễn thông FPT (FPT

Telecom) khởi đầu từ Trung tâm Dịch vụ Trực tuyến với 4 thành viên sáng lập cùng

sản phẩm mạng Intranet đầu tiên của Việt Nam mang tên “Trí tuệ Việt Nam – TTVN”.

Sau hơn 15 năm hoạt động, FPT Telecom đã trở thành một trong những nhà cung cấp

dịch vụ viễn thông và Internet hàng đầu khu vực với trên 3.500 nhân viên, 45 chi

nhánh trong và ngoài nước. Hiện nay, FPT Telecom đang cung cấp các sản phẩm, dịch

vụ chính bao gồm:

Internet băng rộng: ADSL/VDSL, TriplePlay, FTTH

Kênh thuê riêng, Tên miền, Email, Lưu trữ web, Trung tâm dữ liệu

Các dịch vụ giá trị gia tăng trên Internet: Truyền hình trực tuyến (OneTV),

Điện thoại cố định (VoIP), Giám sát từ xa (IP Camera), Chứng thực chữ ký

số (CA), Điện toán đám mây (Cloud computing),... [15].

FPT Telecom là một doanh nghiệp tạo được uy tín nhờ các chính sách hỗ trợ,

chăm sóc khách hàng chu đáo. Trong đó có tổ chức bộ phận chuyên tiếp nhận và giải

quyết khiếu nại của khách hàng. Tổ chức này chịu trách nhiệm tiếp nhận, xem xét,

kiểm tra và giải quyết một cách thõa đáng nhất cho người đến khiếu nại. Có thể sơ

lược quy trình xử lý như sau: Đầu tiên khách hàng mang hồ sơ khiếu nại tới gặp bộ

phận tiếp nhận khiếu nại. Nhiên viên tiếp nhận khiếu nại có trách nhiệm tiếp nhận và

chuyển cho cán bộ xử lý khiếu nại. Đồng thời người này cần phải ghi sự kiện này (giao

dịch khiếu nại) vào nhật ký theo dõi xử lý và báo cáo theo dõi. Công việc của cán bộ

giải quyết khiếu nại là kiểm tra tính xác thực của thông tin và phạm vi của khiếu nại

sau đó giải đáp thắc cho khách hàng. Trong trường hợp khiếu nại vượt quá phạm vi

quyền hạn và chức năng của mình thì cán bộ này phải cần đến sự hỗ trợ của các ban

ngành và các bộ phận liên quan khác để cùng thảo luận và giải quyết.

41

3.2. Ngữ cảnh của dịch vụ khiếu nại

Tổ chức tiếp nhận và giải quyết khiếu nại của khách hàng của FPT Telecom có

ngữ cảnh hoạt động như bảng 3.1.

Bảng 3-1: Quy trình tiếp nhận và giải quyết khiếu nại của FPT Telecom [15].

Sơ đồ ngữ cảnh hoạt động trên được FPT Telecom công bố trên trang chính thức

của họ và có hiệu lực chính thức từ ngày 10/06/2013. Và đây chính là ngữ cảnh hoạt

động của tổ chức B được thảo luận trong chương 2.

42

Từ bảng ngữ cảnh 3.1 ta có thể mô hình hóa tổ chức này sử dụng các ký hiệu của

mô hình DEMO (chương 2) như hình 3.1:

Hình 3.1: Mô hình cấu trúc tổ chức giải quyết khiếu nại.

Hình 3.1 trình bày mô hình hoạt động của các tác nhân O trong tổ chức để tiếp

nhận và giải quyết khiếu nại của khách hàng. Ta có thể hiểu nội dung mô hình như

sau: đầu tiên khách hàng C-A01 mang đơn (hoặc hồ sơ tương đương) tới và yêu cầu

được giải quyết. Tác nhân O-A01 (nhân viên tiếp nhận hồ sơ) tiếp nhận và hứa là sẽ

giải quyết cho C-A01. Hai người này thực hiện giao dịch O-T01. Sau đó tác nhân O-

A01 chuyển hồ sơ khiếu nại cho O-A02 (cán bộ giải quyết khiếu nại) qua giao dịch O-

T02 và yêu cầu tác nhân này giải quyết. Nếu vấn đề có thể giải quyết được ngay thì O-

A02 sẽ phản hồi ngay cho O-A01, ngược lại thì O-A02 sẽ phải giao dịch với các tác

nhân O-A03 (cán bộ kỹ thuật/dịch vụ khách hàng), O-A04 (lãnh đạo), O-A05 (Ban

giám đốc, Ban chất lượng) thông qua các giao dịch tương ứng là O-T03, O-T04 và O-

T05. Trong đó các tác nhân O-A03, O-A04, O-A05 nằm bên ngoài tổ chức và đóng vai

trò là người hỗ trợ (supplier). Trong quá trình giải quyết khiếu nại, cán bộ giải quyết

khiếu nại O-A02 cần phải sử dụng đến các dữ liệu hỗ trợ và dữ liệu về khách hàng

được lưu trong các ngân hàng APB01 và APB02. Trong đó APB01 chứa dữ liệu hỗ trợ

(sản phẩm, dịch vụ) còn APB02 chứa dữ liệu về khách hàng.

3.3. Xây dựng mô hình tổ chức I

43

Ta sẽ lần lượt đi xác định các tác nhân I cần thiết để hỗ trợ cho các tác nhân O-

A01 và O-A02.

3.3.1. Tác nhân OA-01

Một thắc mắc khiếu nại được khách hàng đưa đến và O-A01 có trách nhiệm tiếp

nhận, cho khách hàng biết về quy trình giải quyết khiếu nại đồng thời ghi vào hồ sơ

theo dõi xử lý và nhập vào báo cáo để theo dõi. O-A01 yêu cầu đến các tác nhân hỗ trợ

để thực hiện các dịch vụ sau:

Ghi nhớ sự kiện, được thực hiện bởi các tác nhân I tương ứng (hình 3.2).

Tái tạo sự kiện, được thực hiện bởi các tác nhân I tương ứng (hình 3.2).

Hình 3.2: Tổ chức I cho việc thực hiện vai trò tác nhân O-A01.

Đối với O-A01, yêu cầu ghi nhớ sự kiện được thực hiện khi tác nhân này tạo ra

một sự kiện mới, chẳng hạn một sự kiện giải quyết khiếu nại mới của khách hàng. Còn

44

dịch vụ tái tạo sự kiện sẽ được gọi đến khi cần xem xét lại sự kiện trước đó, chẳng hạn

khách hàng đến khiếu nại lần thứ hai vì chưa hài lòng với giải đáp trước đó. Tái tạo sự

kiện có hai loại là tái tạo sự kiện gốc và tái tạo sự kiện có nguồn gốc. Hình 3.2 mô tả

các tác nhân I hỗ trợ tác nhân O-A01. Trong đó, thông qua giao dịch I-T0110, O-A01

yêu cầu I-A0110 ghi nhớ sự kiện C và tác nhân I này sẽ phải đáp ứng. Tương tự thì tác

nhân I-T0111 sẽ ghi nhớ sự kiện P cho O-A01 thông qua giao dịch I-T0111. Loại công

việc thứ hai là tái tạo sự kiện cho O-A01 thì sẽ được thực hiện bởi I-A0120 và I-

A0121 thông qua các giao dịch I-T0120 và I-T0121 tương ứng. Trong đó I-T0121 tái

tạo sự kiện gốc cho O-A01 qua giao dịch I-T0120 còn I-T0121 cần thực hiện các giao

dịch I-T01210 và I-T01211 tương ứng với các tác nhân I-A01210 và I-A01211 để tái

tạo sự kiện có nguồn gốc cho I-A01 thông qua giao dịch I-T0121.

3.3.2. Tác nhân OA-02

Tương tự như tác nhân O-A01, O-A02 cũng cần đến hai loại dịch vụ là ghi nhớ

sự kiện và tái tạo sự kiện. So với tác nhân O-A01 thì tác nhân O-A02 hoạt động phức

tạp hơn một chút là có thêm phần giao dịch với các tác nhân của tổ chức ngoài (hình

3.3). Điều này cũng dễ hiểu bởi trong trường hợp khiếu nại không thể giải quyết trực

tiếp mà phải cần đến sự hỗ trợ các thông tin liên quan từ bên ngoài thì các giao dịch

với tổ chức ngoài cần được thực hiện.

Hình 3.3 trình bày các tương tác giữa tác nhân O-A02 với các tác nhân I trong tổ

chức I để yêu cầu các tác nhân này hỗ trợ. Khi một khiếu nại cần được giải quyết được

O-A01 chuyển đến, có hai xu hướng mà O-A02 cần giải quyết. Thứ nhất, nếu với kinh

nghiệm và hiểu biết cũng như sự hỗ trợ của ngân hàng dữ liệu mà O-A02 có thể giải

quyết được ngay thì tác nhân này sẽ giải quyết. Ngược lại, O-A02 sẽ phải cần đến các

tài liệu cũng như sự hỗ trợ từ các tác nhân ngoài tổ chức.

Dịch vụ ghi nhớ sự kiện mà O-A02 yêu cầu I-A0210 và I-A0211 thực hiện thông

qua các giao dịch dịch I-T0210 và I-T0211 xuất hiện khi O-A02 tạo ra các sự kiện C

và P và cần được ghi nhớ lại để hỗ trợ việc tái tạo sau này khi cần đến. Chẳng hạn O-

A02 tạo ra một sự kiện P là kiểm tra thông tin về khiếu nại, hoặc một sự kiện C là thảo

luận với các tác nhân hỗ trợ để giải quyết khiếu nại.

Dịch vụ tái tạo sự kiện mà O-A02 yêu cầu I-A0220 và I-A0221 thực hiện thông

qua các giao dịch dịch I-T0220 và I-T0221 xuất hiện khi O-A02 cần đến các sự kiện

cũ (chương 2 gọi là sự kiện gốc) để hỗ trợ các thông tin cho việc giải quyết khiếu nại.

Chẳng hạn cần đến thông tin về sự kiện mua hàng (từ tổ chức ngoài) của người đến

45

khiếu nại, hoặc sự kiện khiếu nại đã được thực hiện trước đó mà được kết hợp từ nhiều

sự kiện khác (chương 2 gọi là sự kiện có nguồn gốc). Việc tái tạo sự kiện đôi khi còn

liên quan đến tổ chức ngoài, đó là lý do vì sao O-A02 cũng phải giao dịch với I-A0222

qua giao dịch I-T0222 để nhận thông tin hỗ trợ từ tổ chức ngoài. I-A0222 là tác nhân

trực tiếp nhận thông tin từ các tác nhân ngoài qua các giao dịch và cung cấp những

thông tin cần thiết cho O-A02.

Hình 3.3: Tổ chức I cho việc thực hiện vai trò của tác nhân O-A02.

3.4. Xây dựng tổ chức D

Như phần 3.3 đã trình bày, để hỗ trợ hai tác nhân O-A01 (nhân viên tiếp nhận

khiếu nại) và O-A02 (cán bộ giải quyết khiếu nại) ta cần đến các tác nhân I tương ứng

để ghi nhớ sự kiện và tái tạo sự kiện. Phần này sẽ xác định các tác nhân D cần xây

dựng để hỗ trợ cho các tác nhân trong tổ chức I với hai dịch vụ là lưu trữ dữ liệu sự

kiện và cung cấp dữ liệu sự kiện. Xem xét hình 3.2 và 3.3 ta sẽ thấy chỉ cần đến hai

loại tác nhân của tổ chức D trực tiếp giao dịch với hai loại tác nhân I để hỗ trợ việc ghi

46

nhớ và tái tạo. Hai tác nhân I-A0110 và I-A0120 trong tổ chức I ở hình 3.2 nhận hai

nhiệm vụ là ghi nhớ sự kiện và tái tạo sự kiện gốc. Các sự kiện có nguồn gốc cũng

hình thành từ các sự kiện gốc nên ta chỉ cần xét trường hợp tái tạo sự kiện gốc. Ta cần

hai tác nhân là D-A0110 hỗ trợ việc ghi nhớ sự kiện của I-A0110 và tác nhân D-

A0120 hỗ trợ việc tái tạo sự kiện của I-A0120 thông qua các giao dịch lưu trữ dữ liệu

sự kiện (D-T0110) và thu thập dữ liệu sự kiện (D-T0120) tương ứng. Như chương 2 đã

trình bày thì dữ liệu sự kiện có thể tồn tại ở các dạng khác nhau (văn bản, hình ảnh, âm

thanh,…), do đó, việc chuyển đổi trước khi lưu trữ là cần thiết. Đó là lý do tác nhân D-

A0110 cần giao dịch với các tác nhân D-A01110 và D-A01111 qua các giao dịch D-

T01110 và D-T01111.

Hình 3.4: Mô hình tổ chức D cho việc lưu trữ và cung cấp dữ liệu sự kiện.

Nếu trước khi lưu trữ ta đã chuyển đổi định dạng dữ liệu cho phù hợp với việc

lưu trữ thì khi tái tạo sự kiện ta cũng cần phải cần chuyển đổi định dạng dữ liệu sự

kiện ngược trở lại. Do đó tác nhân D-A0120 phải giao dịch với tác nhân D-A01210 để

47

triệu hồi dữ liệu, sau đó giao dịch với D-A01211 để chuyển đổi dữ liệu về dạng cần

thiết.

Như vậy, chương này đã trình bày cơ bản và đầy đủ việc áp dụng mô hình vào

một ví dụ thực tiễn để xây dựng mô hình ontology doanh nghiệp cho tổ chức tiếp nhận

và giải quyết khiếu nại của FPT Telecom.

48

Chương 4. Thực nghiệm

4.1. Giới thiệu

Chương này sẽ tiến hành một thực nghiệm để thấy rõ hơn vai trò của tác nhân I

và tác nhân D trong giao dịch lưu trữ dữ liệu sự kiện và giao dịch tái tạo dữ liệu sự

kiện với tổ chức tiếp nhận và giải quyết khiếu nại đã trình bày ở chương 3. Thực

nghiệm tiến hành xây dựng các chương trình hỗ trợ các tác nhân I và D thực hiện

nhiệm vụ, cụ thể là việc lưu trữ và cung cấp dữ liệu sự kiện trong hình 3.4. Giả sử tác

nhân OA-02 (cán bộ thực hiện giải quyết khiếu nại) tạo ra một sự kiện có đặc điểm

như hình 4.1 và sự kiện này sẽ được tác nhân I ghi nhớ.

Hình 4.1: Một mẫu sự kiện

Các chương trình trong chương 4 này được xây dựng bằng ngôn ngữ Java.

4.2. Chương trình hỗ trợ tác nhân I

Theo chương 2, tác nhân ghi nhớ sự kiện trong tổ chức I thực hiện việc ghi nhớ

sự kiện nghĩa là người này chỉ cần ghi nhớ hai thông tin để yêu cầu nhân viên dữ liệu

sau này, đó là định danh sự kiện và định danh nơi lưu trữ. Trong đó có thể lấy mã sự

kiện làm định danh sự kiện. Giả sử định danh nơi lưu trữ là ST8888, khi đó đối với tác

nhân I, anh ta chỉ cần đến lưu EV8888 và ST8888 trên máy tính cá nhân của mình. Sau

này khi cần gọi lại sự kiện, người này sẽ dùng hai tham số này để yêu cầu dữ liệu từ

49

tác nhân D. Hình 4-2 và 4-3 mô tả giao diện phần mềm hỗ trợ làm việc cho tác nhân I

với các chức năng là ghi nhớ một sự kiện, gửi dữ liệu cần lưu trữ cho tác nhân D và

yêu cầu tác nhân I tái tạo sự kiện. Khi tác nhân I cung cấp đầy đủ thông tin gồm định

danh sự kiện (Event ID), định danh nơi lưu trữ (Store ID) và nội dung của sự kiện

(Event) và nhấn phím chức năng thì hai định danh sẽ được ghi nhớ ở tác nhân I, phần

nội dung còn lại sẽ được chuyển cho tác nhân D để lưu trữ phù hợp (mục 4.3 sẽ nói rõ

hơn về vấn đề này). Ngay sau khi thao tác thành công, danh sách sự kiện bên trái cũng

ngay lập tức được cập nhật để thuận tiện cho việc kiểm tra.

Hình 4.2: Chức năng ghi nhớ và gửi dữ liệu sự kiện đi lưu trữ.

Khi cung cấp thông tin cho tác nhân D lưu trữ, tác nhân I cũng không cần quan

tâm cách thể hiện một sự kiện (gồm các thuộc tính nào, định dạng ra làm sao). Tất cả

những thông tin này được gói chung vào trường nội dung (content) và gửi cho tác nhân

D. Nhiệm vụ của tác nhân D là dựa vào các quy tắc lưu trữ của cơ sở dữ liệu để chia

sự kiện thành các trường thôn tin và đúng với định dạng của chúng.

Khóa luận này không tập trung vào cơ chế các tác nhân ở hai mức khác nhau

truyền dữ liệu cho nhau mà chỉ tập trung vào bài toán là họ có trao đổi dữ liệu là được.

Do hạn hẹp về thời gian, chương trình cũng chưa bao gồm các thành phần về phương

thức truyền dữ liệu giữa các tác nhân. Thành phần đã thi hành được trong khóa luận

50

cho biết tổ chức cần triển khai những gì và nên triển khai như thế nào cho phù hợp.

Đây cũng là một vấn đề có ý nghĩa.

Theo chương 2, tác nhân I chỉ cần ghi nhớ định danh của sự kiện cũng như định

danh nơi lưu trữ. Một ngày nào đó, tác nhân này cần đến một sự kiện thì chỉ cần cung

cấp hai định danh cho tổ chức dữ liệu và yêu cầu tổ này cung cấp sự kiện. Hình 4-3 là

giao diện của chức năng yêu cầu sự kiện. Sau khi cung cấp đầy đủ thông tin và nhấn

nút chức năng, thông tin sẽ được gửi đến tác nhân D theo một cách nào đó. Và ngược

lại, tác nhân I này chắc chắn cũng sẽ nhận được phản hồi từ người được yêu cầu theo

cách nào đó. Vấn đề này sẽ được tôi nghiên cứu và tiếp tục phát triển.

Hình 4.3: Chức năng yêu cầu tái tạo một sự kiện biết trước các tham số.

4.3. Chương trình hỗ trợ tác nhân D

Khác với tác nhân I, nhiệm vụ của các tác nhân D là khó khăn và nặng nề hơn.

Như đã trình bày trong chương trước, dữ liệu tồn tại không phải ở một dạng duy nhất

mà là ở nhiều hình thái khác nhau. Chẳng một văn bản về sự kiện có thể là một tập tài

liệu được viết tay hay đánh máy đã in ra mà ta gọi là bản cứng, cũng có thể là một văn

bản dưới dạng tệp (bản mềm) gửi qua đường email,… Do đó, dữ liệu sự kiện cần được

chuyển đổi để phù hợp với mẫu dữ liệu có thể lưu được trong máy tính hoặc cơ sở dữ

51

liệu. Chẳng hạn, trong mẫu sự kiện ví dụ trong mục 4-1, vì được viết bằng tay theo

cách hiểu thông thường nên thời gian của sự kiện được ghi là 9h05, tuy nhiên trong cơ

sở dữ liệu sẽ không thể lưu thời gian dưới định dạng này. Vậy nên, việc chuyển đổi dữ

liệu là tất yếu. Một ví dụ khác, chẳng hạn để đảm bảo an toàn hoặc phù hợp với cách

lưu trữ của tổ chức, nội dung của sự kiện trên có thể được mã hóa theo một thuật toán

nào đó, sau đó mới đem lưu trữ. Mặt khác, trước khi lưu trữ, dữ liệu đã được chuyển

đổi nên khi tác nhân D muốn cung cấp lại sự kiện cho tác nhân I khi được yêu cầu thì

cùng phải khôi phục lại theo mẫu ban đầu. Ngoài ra tác nhân này đôi khi còn phải lắp

ghép các sự kiện gốc để có được các sự kiện có nguồn gốc theo yêu cầu của tác nhân I.

Chương trình hỗ trợ tác nhân D được xây dựng với ba chức năng là lưu trữ tài liệu vào

kho, cung cấp sự kiện cho tác nhân I khi được yêu cầu, mã hóa dữ liệu trước khi lưu

trữ cũng như giải mã khi lấy dữ liệu ra để tái tạo sự kiện.

Đầu tiên là chức năng phục hồi sự kiện, tái tạo và gửi đi cho tác nhân I.

Hình 4.4: Gửi lại sự kiện cho tác nhân I.

52

Sau khi lấy dữ liệu sự kiện trước đây đã chuyển đổi theo một cách thức nào đó

thì bây giờ tác nhân D cần phải chuyển đổi lại về dạng giống hoặc gần giống như mẫu

sự kiện ban đầu sao cho ngữ nghĩa của nó không đổi. Chẳng hạn sự kiện được phục

hồi cần đầy đủ và đúng các thông tin nhưng có thể viết dưới dạng khác. Ví dụ sự kiện

ban đầu được I chuyển cho D ghi là 9h05 nhưng khi D chuyển ngược lại cho D thì có

thể ghi là từ 9 giờ 05 phút . Rõ ràng ngữ nghĩa trong hai cách viết là như nhau.

Hình 4-4 là giao diện chức năng gửi sự kiện đã được phục hồi từ tác nhân D đến

tác nhân I. Trong những trường hợp gửi dữ liệu trên đây, sẽ có câu hỏi đặt ra là làm thế

nào để tác nhân I biết nên gửi yêu cầu cho tác nhân D nào. Vấn đề này có thể giải

quyết bằng cách cung cấp định danh của người nhận cho trong thao tác gửi và đợi

người đó phản hồi. Tuy nhiên rõ ràng đó là một giải pháp chưa tối ưu. Thông minh

hơn, chúng ta có thể cho hệ thống tự xác định xem tác nhân D nào đang ở trạng thái

“rảnh” thì sẽ gửi yêu cầu tới đó và nhờ giải quyết. Trong trường hợp ngược lại là tác

nhân D gửi cho tác nhân I thì dĩ nhiên là phải biết ai yêu cầu nó gửi đến địa chỉ phù

hợp.

Tiếp theo là chức năng lưu trữ dữ liệu sự kiện. Giả sử cơ sở dữ liệu lưu trữ dữ

liệu về sự kiện được thiết kế với các trường: id (định danh sự kiện), name (lưu tên sự

kiện), date (lưu ngày sự kiện được tạo ra), time (lưu thời gian sống của sự kiện),

content (lưu nội dung của sự kiện). Hình 4-6 cho thấy giao diện của chức lưu trữ dữ

liệu sự kiện với các trường tương ứng và có thêm trường Store ID để xác định nơi cần

lưu. Từ một văn bản sự kiện, các thông tin cần thiết đã được tách chọn và bỏ đi những

phần thừa không cần thiết và được lưu lại làm dữ liệu sự kiện với định danh sự kiện và

định danh nơi lưu trữ là duy nhất. Chẳng hạn thông tin về ngày xảy ra sự kiện

10/04/2014 đã được chuyển thành định dạng đúng cho phép lưu trữ trong cơ sở dữ liệu

là 2014-04-10. Hoặc, thời gian xảy ra sự kiện được chuyển đổi từ 9h05 sang định dạng

09:05:00 để đúng với kiểu dữ liệu là time được lưu trong cơ sở dữ liệu (hình 4-5).

Hình 4.5: Dữ liệu về sự kiện được lưu trữ trong cơ sở dữ liệu

53

Hình 4.6: Chức năng lưu dữ liệu sự kiện.

Cuối cùng là chương trình mã hóa dữ liệu trước khi lưu trữ và giải mã dữ liệu

trước khi tái tạo sự kiện. Để mã hóa dữ liệu, ta có thể sử dụng rất nhiều hệ mã hóa từ

đơn giản đến phức tạp, chẳng hạn: dịch chuyển, thay thế, hoán vị, Affine, Vigenere,

Hill, RSA, Elgamal, Rabin, DES. Để đơn giản, chương trình mã hóa trong phạm vi

khóa luận được thực hiện với hệ mã hóa Vigenere. Hệ mã hóa này được mô tả như sau

[16]:

Đặt P = C = K = (Z26)m, với m là số nguyên dương, các phép toán thực hiện trong

Z26.

Bản mã Y và bản rõ X ∈ (Z26)m.

Khóa k = (k1, k2,… km) gồm m phân tử;

Công thức mã hóa:

54

Y = (y1, y2,… ym) = ek(x1, x2,… xm) = (x1 + k1, x2 + k2,… xm + km) mod 26.

Công thức giải mã:

X = (x1, x2,… xm) = dk(y1, y2,… ym) = (y1 – k1, y2 – k2,… ym – km) mod 26.

Giả sử ta có một đoạn văn bản với bản rõ chữ: MANCHESTER

Chọn khóa: SIR = {18, 8, 17} có độ dài m = 3.

Ta có bản rõ số tương ứng:

M A N C H E S T E R 12 0 13 2 7 4 18 19 4 17

Chia bản rõ thành các đoạn, mỗi đoạn có m = 3 phần tử.

Với mỗi đoạn, áp dụng công thức mã hóa, ta nhận được bản mã số (hàng số 3

trong bảng):

12 0 13 2 7 4 18 19 4 17 18 8 17 18 8 17 18 8 17 18 4 8 4 4 15 21 10 1 21 9

Bản mã số là: 4 8 4 4 15 21 10 1 21 9.

Từ bản mã số ta có bản mã chữ: EIEEPVKBVJ.

Để rõ hơn về hệ mã hóa trên, sau đây sẽ giới thiệu một chương trình nhỏ được

lập trình bằng ngôn ngữ Java sử dụng hệ mã hóa Vigenere nói trên. Chẳng hạn ta có

một đoạn văn bản cần được mã hóa chứa trong file file_goc.txt như hình 4-7.

Hình 4.7: Văn bản gốc trước khi được mã hóa.

55

Hình 4-8 trình bày giao diện của chức năng mã hóa hóa văn bản. Đầu tiên, ta

chọn file cần mã hóa (file_goc.txt) và file sẽ lưu trữ văn bản sau khi mã hóa

(file_mahoa.txt). Tiếp theo điền khóa vào trường khóa và nhấn nút “Mã hóa”.

Hình 4.8: Giao diện của chức năng mã hóa văn bản

Sau khi mã hóa xong, chương trình sẽ báo mã hóa thành công như hình 4-9 và

kết quả mã hóa như hình 4-10.

Hình 4.9: Thông báo mã hóa thành công của chương trình

56

Hình 4.10: Văn bản sau khi được mã hóa

Bây giờ, nếu muốn có được văn bản ban đầu, ta sử dụng chức năng giải mã của

chương trình. Hình 4-11 và 4-12 lần lượt trình bày giao diện giải mã và giải mã thành

công của chương trình.

Hình 4.11: Chọn file cần giải mã và lưu vào file mới

Ta chọn file cần giải mã là file_mahoa.txt, sau đó chọn một file khác để lưu lại

kết quả mã hóa như hình 4-11. Hình 4-12 cho biết công việc giải mã thành công và nó

cho kết quả như hình 4-13.

Kết quả sau khi giải mã hoàn toàn khớp với văn bản gốc ban đầu cho thấy tính

đúng đắn của thuật toán được cài đặt trong chương trình. Tuy nhiên, hệ mã hóa

Vigenere chỉ có độ an toàn ở mức “tương đối cao”, do đó chỉ phù hợp cho việc thử

57

nghiệm. Trong thực tiễn, để nâng cao độ an toàn cho dữ liệu, người ta thường dùng các

hệ mã hóa có độ an toàn cao hơn như RSA, Elgamal hay DES,…

Hình 4.12: Giải mã thành công

Hình 4.13: Kết quả giải mã

Như vậy, chương này đã trình bày ba mô đun chương trình hỗ trợ tác nhân I và D

trong việc ghi nhớ sự kiện, lưu trữ sự kiện, cung cấp sự kiện, và mã hóa dữ liệu trước

khi lưu trữ cũng như giải mã dữ liệu trước khi phục hồi. Qua đó ta thấy rõ hơn vai trò

của các tác nhân I và D trong mô hình tổ chức được phân tích trước đó.

58

KẾT LUẬN

Khóa luận này tập trung nghiên cứu lý thuyết về mô hình tổ chức với ba mức là

mức B (Business: kinh doanh), mức I (Information: thông tin) và mức D (Data: dữ

liệu) và ứng dụng của lý thuyết này để xây dựng ontology của tổ chức. Khóa luận cũng

đề nghị một mô hình áp dụng phương pháp vào hệ thống quản lý ngữ nghĩa khách

hàng của FPT Telecom. Trên cơ sở nghiên cứu của Joop de Jong, 2013 [11], khóa luận

thi hành hai mô đun chương trình chuyển hóa giữa các tác nhân thuộc mô hình tổ chức

mức I với tác nhân thuộc mô hình tổ chức mức D. Thực nghiệm trên hai mô đun

chương trình nói trên cho kết quả phù hợp.

Tuy nhiên, do hạn chế về thời gian và kiến thức, khóa luận chưa đi sâu vào một

số vấn đề như các tổ chức ngoài tổ chức đang xét, cách thức truyền dữ liệu giữa các

thành phần trong tổ chức, chuyển đổi dữ liệu,…Mặt khác, chương trình thực nghiệm

cũng chưa hỗ trợ đầy đủ các nhiệm vụ cần thực hiện của một tác nhân.

Do vậy, hướng nghiên cứu tiếp theo là khảo sát chuyên sâu về cách thức truyền

dữ liệu, chuyển đổi dữ liệu, giữa các thành phần trong tổ chức và thi hành các chương

trình tương ứng.

Tài liệu tham khảo

Tiếng Anh

[1] S.Staab, R. Studer, “Handbook on ontologies”, Springer, 2009.

[2] Asunción Gómez–Pérez, Mariano Fernández-López, Oscar Corcho, “Ontological

Engineering”, Tutorial on Ontological Engineering: IJCAI’99, 2004.

[3] Natalya F. Noy, Deborah L. McGuinness, “Ontology Development 101: A Guide

to Creating Your First Ontology”, Stanford Knowledge Systems Laboratory

Technical Report KSL-01-05 and Stanford Medical Informatics Technical

Report SMI-2001-0880, March 2001.

[4] Jan L.G. Dietz, “Enterprise Engineering, Enterprise Ontology”, Delft University of

Technology, 2006.

[5] Jan L.G. Dietz, “Enterprise Ontology - Theory and Methodology”, Springer-Verlag

Berlin Heidelberg, 2006, ISBN 3-540-29169-5

[6] Jan L.G. Dietz, “The deep structure of business processes”, Communications of the

ACM 49(5), p59–64, 2006.

[7] Johan Den Haan, “Modeling an organization using Enterprise Ontology”,

http://www.theenterprisearchitect.eu/, 2009

[8] Joop de Jong, Jan L. G. Dietz, “Understanding the Realization of Organizations”, Enterprise Engineering IV Lecture Notes in Business Information Processing Volume 49, 2010, pp 31-49.

[9] Steven J. H. van Kervel, Jan L. G. Dietz, John Hintzen, Tycho van Meeuwen, Bob

Zijlstra, “Enterprise Ontology Driven Software Engineering”, ICSOFT 2012:

205-210.

[10] Zeinab Rajabi, Behrouz Minaei, Mir Ali Seyyedi, “Enterprise Architecture

Development Based on Enterprise Ontology”, Journal of Theoretical and Applied

Electronic Commerce Research ISSN 0718–1876 Electronic Version VOL 8 /

ISSUE 2 / AUGUST 2013 / 85-95 © 2013 Universidad de Talca – Chile.

[11] Joop de Jong, “A Method for Enterprise Ontology based Design of Enterprise

Information Systems”, PhD Thesis, Delft University of Technology, 2013.

[12] Jan L.G Dietz, “The discipline of enterprise engineering”, Int. J. Organisational

Design and Engineering, Vol. 3, No. 1, 2013

[13] Mike Uschold, Martin King, Stuart Moralee and Yannis Zorgios, “The Enterprise

Ontology”, AIAI-TR-195 August 1996.

[15] http://www.fpt.vn/