Lưu Đồ ISO 5807 và Bộ Giải Pháp Vận Hành Số cho Trường Đại Học Ngoại thương

1. Tại Sao Cần Chuẩn Hóa Lưu Đồ?

Lưu đồ (flowchart) là ngôn ngữ hình ảnh phổ biến nhất để mô tả giải thuật, quy trình nghiệp vụ, và luồng dữ liệu. Tuy nhiên, nếu mỗi người tự ý chọn hình dạng và ký hiệu, người đọc sẽ không thể hiểu được lưu đồ do người khác vẽ — hoàn toàn mất đi lợi thế giao tiếp của công cụ này.

Chính vì vậy, Tổ chức Tiêu chuẩn hóa Quốc tế (ISO) ban hành tiêu chuẩn ISO 5807:1985 — Information processing: Documentation symbols and conventions for data, program and system flowcharts, program network charts and system resources charts — quy định thống nhất toàn bộ ký hiệu dùng trong lưu đồ phần mềm và hệ thống thông tin. Tiêu chuẩn này được áp dụng rộng rãi trong giáo dục tin học, kỹ thuật phần mềm, quản lý quy trình và thiết kế hệ thống trên toàn thế giới.

International Organization for Standardization. (1985). ISO 5807:1985 — Information processing — Documentation symbols and conventions for data, program and system flowcharts, program network charts and system resources charts. ISO.

Nghiên cứu về dạy lập trình nhập môn khẳng định lưu đồ là một trong những công cụ hình ảnh hiệu quả nhất giúp người học hiểu cấu trúc giải thuật trước khi tiếp cận cú pháp ngôn ngữ lập trình (Luxton-Reilly et al., 2018). Sử dụng ký hiệu chuẩn hóa giúp sinh viên hình thành tư duy thuật toán hệ thống và giảm thiểu sai lầm do hiểu nhầm cấu trúc điều kiện hay vòng lặp (Yulianto et al., 2018).

Luxton-Reilly, A., Simon, Albluwi, I., Becker, B. A., & Giannakos, M. (2018). Introductory programming: A systematic literature review. Proceedings Companion of the 23rd Annual ACM Conference on Innovation and Technology in Computer Science Education. ACM.
DOI: 10.1145/3293881.3295779

Yulianto, B., Prabowo, H., Kosala, R., & Hapsara, M. (2018). Novice programmer = (Sourcecode) (Pseudocode) Algorithm. Journal of Computer Science, 14(4), 477–484.
DOI: 10.3844/jcssp.2018.477.484

2. Cấu Trúc của Một Lưu Đồ

Mọi lưu đồ theo chuẩn ISO 5807 đều gồm ba thành phần chính:

1. Ký hiệu (Symbols): Các hình hình học đặc trưng, mỗi hình mang một ý nghĩa xác định
2. Đường luồng (Flow lines): Các đường kẻ nối giữa các ký hiệu
3. Mũi tên (Arrowheads): Chỉ chiều di chuyển của luồng xử lý

Một lưu đồ chuẩn luôn có đúng một điểm bắt đầu (START) nhưng có thể có nhiều điểm kết thúc (END). Luồng di chuyển mặc định là từ trên xuống dưới và từ trái sang phải.

3. Ký Hiệu Cơ Bản (Nhóm 1)

Đây là nhóm ký hiệu bắt buộc phải nắm vững — xuất hiện trong hầu hết mọi lưu đồ.

3.1. Ký Hiệu Đầu Cuối — Terminal (Hình Oval / Bo Tròn)

Hình dạng: Hình chữ nhật với hai đầu bo tròn (stadium shape), hoặc hình oval.
Ý nghĩa: Đánh dấu điểm bắt đầu hoặc điểm kết thúc của lưu đồ.
Nội dung bên trong: Thường ghi "BẮT ĐẦU" / "KẾT THÚC" (hoặc "START" / "END" / "STOP").
Quy tắc: Mỗi lưu đồ có đúng một ký hiệu START; có thể có nhiều ký hiệu END.

3.2. Ký Hiệu Tiến Trình — Process (Hình Chữ Nhật)

Hình dạng: Hình chữ nhật thông thường.
Ý nghĩa: Mô tả một bước xử lý, phép tính, hoặc hành động cụ thể.
Nội dung bên trong: Câu lệnh ngắn gọn, rõ ràng, chỉ nêu đúng một hành động.
Quy tắc: Mỗi ô Process có đúng một đầu vào và đúng một đầu ra. Không dùng ô này cho quyết định.

3.3. Ký Hiệu Quyết Định — Decision (Hình Thoi)

Hình dạng: Hình thoi (rhombus/diamond).
Ý nghĩa: Đặt ra một điều kiện và rẽ luồng thành hai (hoặc nhiều) hướng dựa trên kết quả.
Nội dung bên trong: Câu hỏi đóng, có thể trả lời Có/Không hoặc Đúng/Sai.
Quy tắc: Mỗi nhánh ra phải được gán nhãn rõ ràng (Có/Không, True/False, Y/N). Ký hiệu này có thể có nhiều đầu ra nhưng chỉ có một đầu vào.

3.4. Ký Hiệu Nhập / Xuất — Input/Output (Hình Bình Hành)

Hình dạng: Hình bình hành (parallelogram) — hình chữ nhật nghiêng.
Ý nghĩa: Đại diện cho thao tác nhập dữ liệu vào hệ thống (Input) hoặc xuất dữ liệu ra từ hệ thống (Output).
Quy tắc: Dùng chung cho cả nhập và xuất. ISO 5807 sử dụng cùng một ký hiệu bình hành cho cả hai chiều.

Nhập: Nhập a, b từ bàn phím  |  Xuất: In ra: "Tổng = " + tổng

3.5. Ký Hiệu Kết Nối Trong Trang — On-Page Connector (Hình Tròn Nhỏ)

Hình dạng: Hình tròn nhỏ, thường chứa một chữ cái hoặc số.
Ý nghĩa: Kết nối hai phần của lưu đồ trên cùng một trang mà không cần kéo đường dài gây rối.
Quy tắc: Hai ký hiệu Connector có cùng nhãn (ví dụ: cùng ký tự "A") là hai đầu của một kết nối. Thường dùng khi lưu đồ phức tạp, nhiều đường chéo nhau.

4. Ký Hiệu Nâng Cao (Nhóm 2)

Nhóm ký hiệu này xuất hiện trong các lưu đồ hệ thống, thiết kế phần mềm và mô tả quy trình phức tạp.

4.1. Tiến Trình Định Sẵn — Predefined Process (Hình Chữ Nhật Có Gạch Đôi)

Hình dạng: Hình chữ nhật với hai đường kẻ dọc ở hai bên (double vertical bars).
Ý nghĩa: Gọi một hàm, thủ tục, hoặc chương trình con đã được định nghĩa ở nơi khác.
Ứng dụng: Cho phép tái sử dụng logic mà không cần vẽ lại toàn bộ. Ví dụ: Gọi hàm TínhMax(a, b) — chi tiết hàm TínhMax được vẽ ở lưu đồ riêng.

4.2. Tài Liệu — Document (Hình Chữ Nhật Đáy Sóng)

Hình dạng: Hình chữ nhật nhưng cạnh đáy là đường cong gợn sóng.
Ý nghĩa: Đại diện cho một tài liệu in ra hoặc báo cáo được tạo ra trong quy trình. Ví dụ: in hóa đơn, in báo cáo, xuất file PDF.

4.3. Lưu Trữ Dữ Liệu — Database/Storage (Hình Trụ)

Hình dạng: Hình trụ (cylinder) — biểu trưng quen thuộc cho cơ sở dữ liệu.
Ý nghĩa: Đại diện cho dữ liệu được lưu trữ lâu dài — cơ sở dữ liệu, file, đĩa cứng.

4.4. Nhập Thủ Công — Manual Input (Hình Thang Lệch)

Hình dạng: Hình tứ giác với cạnh trên nghiêng (từ trái thấp đến phải cao).
Ý nghĩa: Dữ liệu được nhập bằng tay, điển hình là qua bàn phím hoặc biểu mẫu.
Phân biệt với I/O: Ký hiệu I/O (bình hành) chung cho cả nhập lẫn xuất; Manual Input nhấn mạnh đây là thao tác người dùng thực hiện thủ công.

4.5. Thao Tác Thủ Công — Manual Operation (Hình Thang Ngược)

Hình dạng: Hình thang, cạnh trên rộng hơn cạnh dưới.
Ý nghĩa: Một bước trong quy trình được thực hiện bởi con người, không phải máy tính. Ví dụ: nhân viên kiểm tra hóa đơn, người dùng ký duyệt hồ sơ.

4.6. Kết Nối Ngoài Trang — Off-Page Connector (Hình Ngũ Giác Nhọn)

Hình dạng: Hình ngũ giác với một cạnh nhọn về phía dưới.
Ý nghĩa: Kết nối luồng sang trang khác của tài liệu lưu đồ.
Quy tắc: Cặp đôi với một ký hiệu tương đương ở trang đích, cùng nhãn.

4.7. Hiển Thị — Display (Hình Màn Hình)

Hình dạng: Hình dạng giống màn hình máy tính — cạnh trái và phải cong, cạnh trên phẳng.
Ý nghĩa: Thông tin được hiển thị cho người dùng xem trên màn hình hoặc bảng điều khiển.

5. Đường Luồng và Mũi Tên

Đường luồng là "xương sống" của lưu đồ — chúng kết nối các ký hiệu và truyền đạt trình tự thực hiện.

5.1. Hướng Mặc Định

• Luồng chuẩn: Từ trên xuống dưới, từ trái sang phải — không cần mũi tên nếu đi đúng hướng này.
• Luồng ngược hoặc sang ngang: Bắt buộc phải có mũi tên chỉ hướng.

5.2. Quy Tắc Dùng Mũi Tên

• Mũi tên chỉ đặt ở một đầu của đường (đầu đến), không đặt ở cả hai đầu.
• Đường luồng nên là đường thẳng hoặc đường gẫy khúc vuông góc; tránh đường cong và đường chéo.

5.3. Tránh Giao Nhau

Khi lưu đồ phức tạp, các đường luồng có thể giao nhau. ISO 5807 khuyến nghị:

• Ưu tiên bố trí lại ký hiệu để tránh giao nhau.
• Nếu bắt buộc phải giao: dùng ký hiệu "bắc cầu" (hình cầu nhỏ trên đường).
• Dùng ký hiệu Connector (hình tròn) là giải pháp được khuyến nghị để tắt đường dài.

5.4. Gán Nhãn Nhánh Quyết Định

Tại ký hiệu Decision, mỗi đường luồng ra phải được gán nhãn rõ ràng:

• Nhánh điều kiện đúng: "Có", "Yes", "True", "Y", hoặc "T"
• Nhánh điều kiện sai: "Không", "No", "False", "N", hoặc "F"
• Nhãn đặt gần mũi tên, không đặt ở giữa đường.

6. Quy Tắc Xây Dựng Lưu Đồ Chuẩn ISO

Việc sử dụng đúng ký hiệu chưa đủ — lưu đồ phải được xây dựng theo các nguyên tắc cấu trúc để đảm bảo tính đúng đắn và dễ đọc. Nghiên cứu về dạy thuật toán cho học sinh phổ thông cho thấy học sinh thường mắc lỗi ở phần cấu trúc luồng hơn là phần ký hiệu (Nijenhuis-Voogt et al., 2021) — do đó nắm vững quy tắc cấu trúc quan trọng không kém nắm vững ký hiệu.

Nijenhuis-Voogt, J., Bayram-Jacobs, D., Meijer, P. C., & Barendsen, E. (2021). Teaching algorithms in upper secondary education: A study of teachers' pedagogical content knowledge. Computer Science Education, 31(4), 428–455.
DOI: 10.1080/08993408.2021.1935554

• Quy tắc 1 — Một đầu vào, một đầu ra: Trừ Decision (nhiều đầu ra) và Connector (nơi hội tụ nhiều luồng), mỗi ký hiệu có đúng một đường luồng vào và một đường luồng ra.
• Quy tắc 2 — Tính rõ ràng và hoàn chỉnh: Mọi nhánh quyết định phải được xử lý — không có nhánh nào bỏ lửng. Nếu nhánh "Không" không làm gì, vẽ đường luồng thẳng đến ký hiệu tiếp theo hoặc đến END.
• Quy tắc 3 — Mỗi ô chỉ mô tả một hành động: Ô Process không được chứa nhiều bước xử lý không liên quan.
• Quy tắc 4 — Vòng lặp phải có điều kiện thoát: Mọi vòng lặp phải có một ký hiệu Decision với nhánh thoát ra ngoài vòng. Vòng lặp không có điều kiện thoát là lỗi logic nghiêm trọng.
• Quy tắc 5 — Dùng Connector khi cần: Lưu đồ dài hoặc có đường luồng phức tạp nên dùng ký hiệu Connector để giữ sự gọn gàng.

7. Ví Dụ Thực Tế: Lưu Đồ Tìm Số Lớn Nhất Trong Ba Số

Bài toán: Nhập ba số a, b, c; in ra số lớn nhất.

Lưu đồ dưới đây sử dụng đủ bốn ký hiệu cơ bản: Terminal, Input/Output, Decision, và Process. Mọi nhánh quyết định đều có nhãn rõ ràng; mọi nhánh đều dẫn đến điểm kết thúc.

flowchart TD
    A([BẮT ĐẦU]) --> B[/Nhập a, b, c/]
    B --> C{a > b?}
    C -->|Có| D{a > c?}
    C -->|Không| E{b > c?}
    D -->|Có| F[max = a]
    D -->|Không| G[max = c]
    E -->|Có| H[max = b]
    E -->|Không| I[max = c]
    F --> J[/In ra: max/]
    G --> J
    H --> J
    I --> J
    J --> K([KẾT THÚC])

Cách tiếp cận này phù hợp với phát hiện của Threekunprapa và Yasri (2020): học sinh hiểu và lập luận tốt hơn về giải thuật khi được trình bày dưới dạng lưu đồ chuẩn hóa so với dạng mã nguồn thuần túy — đặc biệt với người học chưa có kinh nghiệm lập trình.

Threekunprapa, A., & Yasri, P. (2020). Unplugged coding using flowblocks for promoting computational thinking and programming among secondary school students. International Journal of Instruction, 13(3), 25–44.
DOI: 10.29333/iji.2020.13314a

8. Lưu Đồ trong Môi Trường Học Tập và Nghề Nghiệp

Lưu đồ theo chuẩn ISO không chỉ xuất hiện trong lập trình. Phạm vi ứng dụng trải rộng:

• Giáo dục: Dạy tư duy giải thuật và lập trình nhập môn. Kuhail et al. (2021) chỉ ra rằng các công cụ lập trình trực quan dựa trên lưu đồ giúp người học tiếp cận lập trình dễ dàng hơn đáng kể so với học ngôn ngữ lập trình văn bản ngay từ đầu.
• Quản lý quy trình: Mô tả quy trình nghiệp vụ trong doanh nghiệp, đặc biệt theo chuẩn ISO 9001 về quản lý chất lượng.
• Kỹ thuật phần mềm: Thiết kế giải thuật trước khi viết code, tài liệu hóa logic hệ thống.
• Y tế và an toàn: Mô tả quy trình khám chữa bệnh, quy trình xử lý sự cố.

Kuhail, M. A., Farooq, S., Hammad, R., & Bahja, M. (2021). Characterizing visual programming approaches for end-user developers: A systematic review. IEEE Access, 9, 14181–14202.
DOI: 10.1109/access.2021.3051043

Scherer et al. (2020) trong nghiên cứu tổng hợp về dạy và học lập trình khẳng định rằng kết hợp công cụ trực quan — trong đó có lưu đồ — với dạy học tích cực cho kết quả tốt hơn đáng kể so với dạy học thụ động thuần túy mã nguồn.

Scherer, R., Siddiq, F., & Sanchez Viveros, B. (2020). A meta-analysis of teaching and learning computer programming: Effective instructional approaches and conditions. Computers in Human Behavior, 109, Article 106349.
DOI: 10.1016/j.chb.2020.106349

9. Những Lỗi Thường Gặp Khi Vẽ Lưu Đồ

1. Không có ký hiệu START/END: Lưu đồ không rõ điểm bắt đầu và kết thúc.
2. Nhầm ký hiệu: Dùng hình chữ nhật cho câu hỏi (phải dùng hình thoi), hoặc hình thoi cho phép tính (phải dùng hình chữ nhật).
3. Không gán nhãn nhánh: Ký hiệu Decision có đường ra nhưng không ghi Có/Không → người đọc không biết nhánh nào ứng với điều kiện nào.
4. Nhánh quyết định bỏ lửng: Một nhánh "Không" không dẫn đến đâu.
5. Vòng lặp không có điều kiện thoát: Luồng quay lại mãi không kết thúc.
6. Dùng mũi tên hai chiều: Đường luồng chỉ chạy theo một chiều tại mỗi thời điểm.
7. Một ô Process chứa quá nhiều hành động: Gây khó đọc và khó kiểm tra.

Mathew et al. (2019) cho thấy khi học sinh hiểu rõ từng loại ký hiệu và được thực hành vẽ lưu đồ với phản hồi kịp thời, khả năng giải quyết vấn đề lập trình cải thiện đáng kể và số lỗi cấu trúc giảm rõ rệt.

Mathew, R., Malik, S. I., & Tawafak, R. M. (2019). Teaching problem solving skills using an educational game in a computer programming course. Informatics in Education, 18(2), 331–348.
DOI: 10.15388/infedu.2019.17

10. Bảng Tổng Hợp Ký Hiệu ISO 5807

Hình	Ký hiệu (EN)	Tên tiếng Việt	Hình dạng	Ý nghĩa chính
	Terminal	Đầu cuối	Oval / Bo tròn	START hoặc END
	Process	Tiến trình	Hình chữ nhật đơn	Bước xử lý, phép tính, phép gán
	Decision	Quyết định	Hình thoi	Điều kiện phân nhánh
	Input/Output	Nhập/Xuất	Hình bình hành	Dữ liệu vào hoặc ra
	On-Page Connector	Kết nối trong trang	Hình tròn nhỏ	Nối hai điểm cùng trang
	Predefined Process	Tiến trình định sẵn	HCN + gạch đôi	Gọi chương trình con / hàm
	Document	Tài liệu	HCN đáy sóng	Tài liệu in ra
	Database	Lưu trữ	Hình trụ	Cơ sở dữ liệu, file
	Manual Input	Nhập thủ công	Hình thang lệch trên	Người dùng nhập tay
	Manual Operation	Thao tác thủ công	Hình thang lệch dưới	Bước thực hiện thủ công
	Off-Page Connector	Kết nối ngoài trang	Ngũ giác nhọn	Nối sang trang khác
	Display	Hiển thị	Hình màn hình	Xuất ra màn hình
	Flow Line	Đường luồng	Đường + mũi tên	Hướng di chuyển

11. Công Cụ Vẽ Lưu Đồ Hiện Đại

Hiểu ký hiệu ISO 5807 là nền tảng — nhưng để thực hành ngay, bạn cần một công cụ cụ thể. Dưới đây là 9 công cụ phổ biến, đều hỗ trợ ký hiệu chuẩn ISO 5807. [Phân tích của tác giả]

Gợi Ý Chọn Công Cụ Theo Nhu Cầu

• Học lập trình / sinh viên: Draw.io (miễn phí, không đăng ký) hoặc yEd (desktop mạnh)
• Tài liệu kỹ thuật trong dự án phần mềm: Mermaid.js hoặc PlantUML (nhúng vào Git repository)
• Cộng tác nhóm trên đám mây: Lucidchart hoặc Creately
• Kỹ thuật phần mềm chuyên sâu (UML + flowchart): Visual Paradigm Community
• Brainstorm nhanh, phác thảo ý tưởng: Whimsical
• Môi trường doanh nghiệp Microsoft: Microsoft Visio

11.1. Ví Dụ: Code Mermaid.js & PlantUML Cho Bài Toán Mẫu

Cùng bài toán tìm số lớn nhất trong 3 số đã minh họa bằng lưu đồ ISO ở Mục 7 — viết lại bằng code để chạy trực tiếp. Developer/Tech Writer có thể copy-paste và chỉnh sửa tức thì.

▶ Mermaid.js

Dán vào mermaid.live, GitHub Markdown, hoặc Notion để xem render ngay:

flowchart TD
    A([BẮT ĐẦU]) --> B[/Nhập a, b, c/]
    B --> C{a > b?}
    C -->|Có| D{a > c?}
    C -->|Không| E{b > c?}
    D -->|Có| F[max = a]
    D -->|Không| G[max = c]
    E -->|Có| H[max = b]
    E -->|Không| I[max = c]
    F --> J[/In ra: max/]
    G --> J
    H --> J
    I --> J
    J --> K([KẾT THÚC])

Cú pháp: ([...]) = Terminal · {...} = Decision · [/..../] = Input/Output · [...] = Process · -->|nhãn| = mũi tên có nhãn

▶ PlantUML

Dán vào plantuml.com, VS Code (extension PlantUML), hoặc IntelliJ:

@startuml
start
:Nhập a, b, c;
if (a > b?) then (Có)
  if (a > c?) then (Có)
    :max = a;
  else (Không)
    :max = c;
  endif
else (Không)
  if (b > c?) then (Có)
    :max = b;
  else (Không)
    :max = c;
  endif
endif
:In ra: max;
stop
@enduml

Cú pháp: start/stop = Terminal · :...; = Process/I/O · if (...) then (...) else (...) endif = Decision (có thể lồng nhau)

11.2. Hướng Dẫn Sử Dụng AI Khi Soạn Lưu Đồ

Ngoài các công cụ vẽ trực quan, cán bộ và giảng viên có thể dùng trợ lý AI (Claude, ChatGPT, Gemini, Copilot…) để soạn thảo cấu trúc lưu đồ trước, sau đó hoàn thiện bằng Draw.io, Mermaid.js hoặc PlantUML. Quy trình "AI-assisted flowcharting" này rút ngắn đáng kể thời gian cho lưu đồ quy trình phức tạp. [Phân tích của tác giả]

AI có thể hỗ trợ những việc gì?

• Gợi ý cấu trúc quy trình: Từ mô tả bằng văn bản, AI đề xuất các bước, điểm quyết định và luồng ngoại lệ cần có trong lưu đồ.
• Tạo code Mermaid.js / PlantUML: AI tạo trực tiếp code lưu đồ sẵn sàng copy-paste vào công cụ render — tiết kiệm thời gian kéo thả.
• Kiểm tra logic quy trình: AI có thể phát hiện nhánh thiếu, vòng lặp vô tận, hoặc bước quyết định chưa có nhánh "Không".
• Chuẩn hóa ngôn ngữ nhãn: Đặt tên nhất quán cho các ô theo chuẩn (động từ + tân ngữ, không quá 5 từ mỗi ô) theo quy tắc ISO 5807.

Cấu Trúc Prompt 4 Thành Phần

Theo hướng dẫn sử dụng AI tại môi trường giáo dục và hành chính, prompt hiệu quả cần có đủ 4 thành phần sau:

"[Quy định Điều 7] Khuyến nghị cán bộ, giảng viên sử dụng cấu trúc prompt gồm các thành phần: (a) Xác định vai trò của AI; (b) Mô tả rõ nhiệm vụ cần AI hỗ trợ; (c) Nêu bối cảnh/quy định liên quan; (d) Quy định định dạng đầu ra."

— Quy định về việc sử dụng Trí tuệ nhân tạo (AI) trong lập và chuẩn hóa quy trình công việc nội bộ tại Trường Đại học Ngoại thương (Điều 7, Khoản 1)

Ví dụ prompt soạn lưu đồ theo chuẩn ISO 5807:

Vai trò: Bạn là chuyên gia soạn lưu đồ quy trình theo chuẩn ISO 5807.

Nhiệm vụ: Xây dựng lưu đồ cho quy trình tiếp nhận và xử lý đơn xin miễn,
giảm học phí dành cho sinh viên.

Bối cảnh: Quy trình nội bộ tại Phòng Công tác Sinh viên, áp dụng theo
quy chế tài chính hiện hành. Hồ sơ có thể được phê duyệt hoặc yêu cầu
bổ sung, hoặc từ chối nếu không đủ điều kiện.

Định dạng đầu ra: Code Mermaid.js sử dụng đúng ký hiệu ISO 5807
(oval=Terminal, parallelogram=I/O, diamond=Decision, rectangle=Process).
Mỗi nhãn không quá 5 từ, dùng tiếng Việt.

Nguyên Tắc Sử Dụng AI Có Trách Nhiệm

Lưu ý thực tế: Nắm vững công cụ vẽ chỉ là bước đầu — việc triển khai lưu đồ vào quy trình thực tế của nhà trường đòi hỏi thêm lớp quản trị về phê duyệt, lưu trữ và kiểm soát phiên bản. Xem chi tiết tại Mục 12: Triển Khai tại FTU →

<mxGraphModel>
  <root>
    <mxCell id="0"/>
    <mxCell id="1" parent="0"/>
    <!-- Terminal START -->
    <mxCell id="2" value="BẮT ĐẦU" style="ellipse;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" vertex="1" parent="1">
      <mxGeometry x="160" y="40" width="120" height="50" as="geometry"/>
    </mxCell>
    <!-- Process -->
    <mxCell id="3" value="[Tên bước]" style="rounded=0;whiteSpace=wrap;html=1;" vertex="1" parent="1">
      <mxGeometry x="160" y="140" width="120" height="50" as="geometry"/>
    </mxCell>
    <!-- Decision -->
    <mxCell id="4" value="[Điều kiện?]" style="rhombus;whiteSpace=wrap;html=1;" vertex="1" parent="1">
      <mxGeometry x="140" y="240" width="160" height="80" as="geometry"/>
    </mxCell>
    <!-- Terminal END -->
    <mxCell id="5" value="KẾT THÚC" style="ellipse;whiteSpace=wrap;html=1;fillColor=#f8cecc;strokeColor=#b85450;" vertex="1" parent="1">
      <mxGeometry x="160" y="380" width="120" height="50" as="geometry"/>
    </mxCell>
    <mxCell id="6" edge="1" source="2" target="3" parent="1"><mxGeometry relative="1" as="geometry"/></mxCell>
    <mxCell id="7" edge="1" source="3" target="4" parent="1"><mxGeometry relative="1" as="geometry"/></mxCell>
    <mxCell id="8" edge="1" source="4" target="5" parent="1"><mxGeometry relative="1" as="geometry"/></mxCell>
  </root>
</mxGraphModel>

12. Triển Khai ISO 5807 Trong Bộ Giải Pháp Số Tại FTU

ISO 5807 là chuẩn quốc tế về ký hiệu lưu đồ, nhưng giá trị thực tiễn nằm ở khả năng ứng dụng ngay vào vận hành số tại Trường Đại học Ngoại thương. Phần này tổng hợp bốn nhóm giải pháp để chuyển hóa các đề xuất lý thuyết thành bộ công cụ vận hành có thể triển khai ngay lập tức. [Phân tích của tác giả — dựa trên Quy định AI FTU, Hướng dẫn mã số tài liệu FTU, và Nghị định 13/2023/NĐ-CP về BVDLCN]

12.1. Tích Hợp Kỹ Thuật: ESB, RESTful API & GraphQL

Ví dụ quen thuộc: khi sinh viên đăng ký học phần, thông tin di chuyển qua ít nhất ba hệ thống — cổng đăng ký, hệ thống học vụ, và hệ thống tài chính. Lưu đồ ISO 5807 là ngôn ngữ chung để đội IT và cán bộ vận hành cùng nhìn thấy chính xác điểm nào dữ liệu có thể thất lạc hoặc xử lý sai.

Lưu đồ ISO 5807 không chỉ dùng để mô tả quy trình nghiệp vụ — chúng còn là bản thiết kế giao tiếp giữa các hệ thống. Khi đội CNTT FTU triển khai tích hợp SIS (Student Information System), LMS, ERP và HRM thành một hạ tầng thống nhất, có ba mô hình kỹ thuật phù hợp:

Cách đọc lưu đồ ISO 5807 như một đặc tả API

Mỗi ký hiệu ISO 5807 trong lưu đồ quy trình ánh xạ trực tiếp sang một thành phần trong luồng API:

Ví dụ: Lưu đồ tích hợp đồng bộ điểm SIS → HEMIS

Quy trình tự động đồng bộ kết quả học tập từ SIS nội bộ sang hệ thống HEMIS (Bộ GD&ĐT) theo chuẩn RESTful API có thể mô tả bằng lưu đồ ISO 5807 với các bước sau:

1. Terminal — Scheduler kích hoạt lúc 23:00 hàng ngày
2. Process — SIS truy vấn điểm sinh viên trong ngày
3. Decision — Có bản ghi mới/thay đổi không?
4. Process — Transform dữ liệu sang chuẩn JSON HEMIS
5. Process — Gọi HEMIS API: POST /api/v1/grades
6. Decision — HTTP 200 OK? → Ghi log thành công;
   HTTP 4xx/5xx? → Ghi log lỗi → Retry tối đa 3 lần → Cảnh báo CNTT
7. Terminal — Job kết thúc, gửi báo cáo email tóm tắt

Bảng Tiêu Chuẩn Giao Thức — Tài liệu Tham chiếu cho Hội đồng Mời Thầu & Đội Kỹ thuật

Bảng dưới đây xác định rõ giao thức đề xuất cho từng loại tích hợp tại FTU, có thể dùng trực tiếp làm yêu cầu kỹ thuật tối thiểu trong hồ sơ mời thầu (RFP) hoặc đặc tả phần mềm nội bộ:

12.2. An Toàn Thông Tin, Phân Quyền RBAC & Luật BVDLCN 2023

Phân loại dữ liệu trong đại học số

Mô hình RBAC (Role-Based Access Control) cho đại học

Ranh giới Public AI vs. Private AI

Luật Bảo vệ Dữ liệu Cá nhân 2023 — Nghĩa vụ của FTU với tư cách Bên kiểm soát dữ liệu

Theo Nghị định 13/2023/NĐ-CP về Bảo vệ dữ liệu cá nhân, FTU với tư cách "Bên kiểm soát và xử lý dữ liệu cá nhân" có các nghĩa vụ cụ thể:

• Lấy sự đồng ý rõ ràng từ sinh viên/cán bộ trước khi thu thập và xử lý PII (áp dụng cho cả dữ liệu đưa vào hệ thống AI).
• Thông báo vi phạm trong 72 giờ cho Cục An ninh mạng (Bộ Công an) khi phát hiện rò rỉ dữ liệu cá nhân.
• Quyền xóa dữ liệu: Cá nhân có quyền yêu cầu xóa dữ liệu — hệ thống số của FTU phải hỗ trợ tính năng này.
• Không chuyển dữ liệu ra nước ngoài khi chưa được Bộ Công an phê duyệt — đây là rào cản khi dùng Cloud AI nước ngoài với dữ liệu nhạy cảm.
• Lưu trữ tối thiểu: Chỉ lưu dữ liệu cá nhân trong thời gian cần thiết, sau đó ẩn danh hoặc xóa theo quy trình đã ban hành.

Cơ Chế Mã Hóa & Ẩn Danh Dữ Liệu

Để tuân thủ Luật BVDLCN 2023 và đảm bảo an toàn khi chia sẻ dữ liệu liên phòng ban, FTU cần áp dụng các cơ chế mã hóa và ẩn danh theo từng lớp:

Quy trình Xử lý Sự cố An toàn Thông tin (Incident Response)

12.3. Thể Chế Hóa & Chuẩn Hóa Vận Hành (SOP)

Ghi chú về mã tài liệu: Theo Hướng dẫn đặt mã số tài liệu quy trình tại FTU (cấu trúc FTU.[đơn vị].[loại][số], ví dụ: FTU.QLDT.QT01), khi lưu đồ được tạo cho quy trình trong hệ thống Quản lý Chất lượng, mã tài liệu cần ghi rõ trên ô Terminal (START) và ở chú thích hình để dễ tra cứu và kiểm soát phiên bản.

Ma trận Phân công Trách nhiệm theo Bộ máy FTU

Phiếu Khai báo Sử dụng AI (Phụ lục B.1) — Mẫu đính kèm Tờ trình

Bộ Chỉ tiêu SLA — Cam kết Chất lượng Dịch vụ

12.4. Lộ Trình Thí Điểm 03 Tháng & Bộ Chỉ Số KPI

Thay vì triển khai đại trà ngay, FTU nên áp dụng mô hình thí điểm tại 2 đơn vị trong 03 tháng trước khi nhân rộng toàn trường. [Phân tích của tác giả]

Bộ Chỉ Số Đo lường Hiệu quả (KPIs) — Đánh giá sau thí điểm

Chỉ Số Đo lường Hiệu quả Hạ tầng Dữ liệu (Infrastructure KPIs)

Bổ sung vào bộ KPI vận hành ở trên, các chỉ số sau đây đo lường chất lượng kỹ thuật của hạ tầng dữ liệu — thường được đội SRE/DevOps theo dõi qua monitoring dashboard:

13. Kết Luận

Lưu đồ theo chuẩn ISO 5807 là công cụ giao tiếp hình ảnh mạnh mẽ và phổ quát — bất kỳ ai, ở bất kỳ quốc gia nào, đều có thể đọc và hiểu được một lưu đồ được vẽ đúng chuẩn. Điều này đặc biệt có giá trị trong thời đại hợp tác quốc tế và phát triển phần mềm toàn cầu.

Nắm vững năm ký hiệu cơ bản (Terminal, Process, Decision, Input/Output, Connector) cùng các quy tắc về đường luồng và mũi tên là nền tảng để thiết kế giải thuật, tài liệu hóa hệ thống, và giao tiếp kỹ thuật hiệu quả. Các ký hiệu nâng cao mở rộng khả năng mô tả cho các hệ thống phức tạp hơn. Dù bạn là sinh viên học lập trình nhập môn, kỹ sư phần mềm, hay nhà quản lý quy trình — một lưu đồ chuẩn ISO được vẽ đúng là bước đầu tiên và thiết yếu để tư duy rõ ràng trước khi thực thi.

Với sinh viên và kỹ sư phần mềm, bài kiểm tra thực sự nhất không nằm ở lý thuyết. Hãy vẽ lại một thuật toán hoặc quy trình bất kỳ bằng lưu đồ ISO 5807, sau đó đưa cho một người chưa biết vấn đề đó đọc — không giải thích gì thêm. Nếu họ hiểu được luồng logic chỉ từ các ký hiệu, lưu đồ đó đã đạt mục tiêu giao tiếp. Nếu họ phải hỏi lại, đó chính là manh mối để cải thiện: thiếu nhãn nhánh, quy trình bị bỏ lửng, hay ký hiệu dùng chưa đúng.

Với cán bộ và giảng viên Trường Đại học Ngoại thương, bốn nhóm giải pháp trong bài — tích hợp kỹ thuật, quản lý dữ liệu, đào tạo năng lực số, và quản trị tài liệu — không cần triển khai đồng loạt. Điểm khởi đầu thực tế nhất là một quy trình hiện có: xét tuyển đại học, cấp học bổng, hoặc đăng ký học phần. Vẽ lưu đồ ISO 5807 cho quy trình đó, thu thập phản hồi từ người trực tiếp thực thi, rồi lặp lại. Một lưu đồ được phê duyệt và lưu trữ đúng cách tạo ra nhiều giá trị hơn mười tài liệu hướng dẫn chưa qua kiểm tra thực tế.

ISO 5807:1985 được ban hành năm 1985 — nhưng hình thoi Decision, hình chữ nhật Process, và hình oval Terminal vẫn xuất hiện nguyên vẹn trong mọi công cụ lưu đồ hiện đại, từ Draw.io đến Mermaid.js đến PlantUML. Sự bền bỉ đó không phải ngẫu nhiên: một ký hiệu tốt không cần cập nhật vì nó mô tả cách tư duy, không mô tả công nghệ cụ thể nào.

Tài Liệu Tham Khảo

International Organization for Standardization. (1985). ISO 5807:1985 — Information processing — Documentation symbols and conventions for data, program and system flowcharts, program network charts and system resources charts. ISO.

Kuhail, M. A., Farooq, S., Hammad, R., & Bahja, M. (2021). Characterizing visual programming approaches for end-user developers: A systematic review. IEEE Access, 9, 14181–14202.
DOI: 10.1109/access.2021.3051043

Luxton-Reilly, A., Simon, Albluwi, I., Becker, B. A., & Giannakos, M. (2018). Introductory programming: A systematic literature review. Proceedings Companion of the 23rd Annual ACM Conference on Innovation and Technology in Computer Science Education. ACM.
DOI: 10.1145/3293881.3295779

Mathew, R., Malik, S. I., & Tawafak, R. M. (2019). Teaching problem solving skills using an educational game in a computer programming course. Informatics in Education, 18(2), 331–348.
DOI: 10.15388/infedu.2019.17

Nijenhuis-Voogt, J., Bayram-Jacobs, D., Meijer, P. C., & Barendsen, E. (2021). Teaching algorithms in upper secondary education: A study of teachers' pedagogical content knowledge. Computer Science Education, 31(4), 428–455.
DOI: 10.1080/08993408.2021.1935554

Scherer, R., Siddiq, F., & Sanchez Viveros, B. (2020). A meta-analysis of teaching and learning computer programming: Effective instructional approaches and conditions. Computers in Human Behavior, 109, Article 106349.
DOI: 10.1016/j.chb.2020.106349

Threekunprapa, A., & Yasri, P. (2020). Unplugged coding using flowblocks for promoting computational thinking and programming among secondary school students. International Journal of Instruction, 13(3), 25–44.
DOI: 10.29333/iji.2020.13314a

Yulianto, B., Prabowo, H., Kosala, R., & Hapsara, M. (2018). Novice programmer = (Sourcecode) (Pseudocode) Algorithm. Journal of Computer Science, 14(4), 477–484.
DOI: 10.3844/jcssp.2018.477.484