Bỏ qua

Business Process Flow: Vòng đời Quy hoạch Dữ liệu Thành phố

Phiên bản: 1.2 Ngày tạo: 2026-03-31 Cập nhật: 2026-04-07 – Bổ sung DISPUTED workflow, trạng thái ô Bảng C, chủ quản cấp Phòng, guard phê duyệt Trạng thái: Draft – Chờ xác nhận từ stakeholder Nguồn: Business Understanding, Use Case Overview

Quy Trình: Vòng đời Quy hoạch Dữ liệu Thành phố

Mã Quy Trình: BPF-01 Use Cases Liên Quan: UC-ANCHOR-001, UC-ANCHOR-002, UC-DISC-001, UC-MAP-001, UC-MAP-002, UC-CONFIRM-001, UC-CONFIRM-002, UC-CONFIRM-003, UC-CONFIRM-004, UC-CONFIRM-005, UC-PLAN-001, UC-PLAN-002, UC-DICT-001, UC-DICT-002 Màn Hình Liên Quan: TBD (sẽ cập nhật sau khi có Screen Flow)


Mô Tả

Quy trình quy hoạch dữ liệu toàn Thành phố, từ khi Manager thiết lập khung dữ liệu định vị đến khi Approver ban hành Từ điển Dữ liệu chính thức và Staff khai thác thông tin. Đây là luồng nghiệp vụ cốt lõi của hệ thống, đi xuyên qua 4 vai trò (Manager → Data Owner → Approver → Staff) với vòng đời trạng thái: DRAFT → IN_REVIEW → APPROVED → PUBLISHED.


Các Vai Trò Tham Gia

Vai Trò Trách Nhiệm Trong Quy Trình
Manager Thiết lập khung dữ liệu định vị; thu thập metadata; xây dựng bản đồ hiện trạng (AI mapping + rà soát); đề xuất chủ quản
Data Owner Rà soát và xác nhận dữ liệu hiện trạng thuộc phạm vi đơn vị mình
Approver Thẩm định toàn bộ bản đồ hiện trạng; chốt chủ quản; ban hành Từ điển Dữ liệu
Staff Khai thác thông tin từ Từ điển Dữ liệu đã ban hành

Sơ Đồ PlantUML Swimlane

Kroki


Chi Tiết Các Bước

Bước Mô Tả Vai Trò Đầu Vào Đầu Ra Quy Tắc Nghiệp Vụ
01 Thiết lập dữ liệu định vị – Anchored Data: khai báo khung Domain → Sub Domain → Data Element Manager Quy định Chính phủ/Bộ/Ngành; thực tiễn địa phương Bảng dữ liệu định vị (Anchored Data Table) – trạng thái DRAFT Cấu trúc phân cấp 3 lớp; mỗi Data Element có mã định danh duy nhất (VD: DE001-DM1.1)
02 Khám phá dữ liệu (Discovery): thu thập metadata cấu trúc (tên bảng, tên cột, kiểu dữ liệu) từ CSDL các đơn vị Manager CSDL của Sở/Ban/Ngành Bảng metadata cấu trúc đã bổ sung Phương thức: import DDL, CSV/Excel, hoặc khai báo thủ công (TBD). Chỉ lấy metadata, không lấy data thực tế
03a Xây dựng bản đồ dữ liệu hiện trạng – AI gợi ý: hệ thống tự động khớp metadata đã khám phá vào khung dữ liệu định vị, xử lý gợi ý Manager + Hệ thống Metadata cấu trúc + Anchored Data Danh sách gợi ý mapping với confident score – trạng thái IN_REVIEW Kết hợp rule-based matching + AI. Giai đoạn này: mọi gợi ý phải Manager xem xét (không auto-accept). Mọi quyết định ACCEPT/REJECT/MODIFY ghi vào ai_feedback_log
03b Xây dựng bản đồ dữ liệu hiện trạng – Rà soát: Manager xem xét, xử lý các ý kiến, chỉnh sửa nếu cần. Đề xuất đơn vị chủ quản cho từng Data Element Manager Danh sách mapping + confident score Bản đồ dữ liệu hiện trạng (bản đề xuất) với đề xuất chủ quản Nếu Approver từ chối (bước sau), quay lại 03b để điều chỉnh
04a Xem hiện trạng (read-only): Data Owner xem kết quả matching của đơn vị mình – field nào match với Data Element nào. Không có quyền chỉnh sửa Data Owner Bản đồ hiện trạng (phần thuộc đơn vị) Data Owner đã xem và hiểu kết quả matching Data Owner chỉ nhìn thấy dữ liệu của đơn vị mình, chế độ read-only
04b Xác nhận: Data Owner xác nhận đồng ý, góp ý thông thường, hoặc đánh dấu DISPUTED Data Owner Kết quả matching đã xem Nếu đồng ý → chuyển bước tiếp. Nếu góp ý → trả về Manager (03b). Nếu tranh chấp → đánh dấu DISPUTED (04c) Góp ý thông thường: Manager điều chỉnh theo góp ý. Tranh chấp nghiêm trọng: chuyển 04c
04c Đánh dấu DISPUTED: Data Owner hoặc Manager đánh dấu ô Bảng C là DISPUTED kèm ghi chú lý do Data Owner / Manager Ô Bảng C có bất đồng Ô chuyển sang trạng thái DISPUTED; Approver nhận thông báo Bắt buộc nhập ghi chú lý do ≥ 20 ký tự. Data Owner chỉ đánh dấu ô thuộc đơn vị mình
04d Giải quyết DISPUTED: Approver xem xét các ô đang DISPUTED, tổ chức họp kỹ thuật nếu cần, quyết định kết quả Approver Ô Bảng C ở trạng thái DISPUTED + ghi chú lý do Ô chuyển sang CONFIRMED / REJECTED / DATABASE (DE mới) Lý do quyết định bắt buộc. Sau khi giải quyết, Data Owner nhận thông báo kết quả. 3 hướng: (a) xác nhận ánh xạ gốc → CONFIRMED, (b) bác bỏ → REJECTED, (c) điều chỉnh sang DE khác
04e Phê duyệt Bảng C tổng thể: Approver chốt bản đồ hiện trạng toàn TP khi đạt tiền điều kiện Approver Bảng C đã đủ điều kiện phê duyệt Bảng C được đánh dấu "Đã chốt" Tiền điều kiện cứng: > 70% Sở đã xác nhận VÀ 0 ô DISPUTED còn tồn tại. Sở quá deadline chưa xác nhận → Approver chốt đơn phương
05a Thực hiện quy hoạch – Chốt quyền sở hữu: Approver xem xét toàn bộ, chốt đơn vị chủ quản duy nhất cho mỗi Data Element đến cấp Phòng/Ban Approver Bản đồ hiện trạng tổng hợp (tất cả đơn vị đã xác nhận, Bảng C đã chốt) Bảng dữ liệu quy hoạch – trạng thái APPROVED Quy tắc 1:1: mỗi Data Element chỉ có một chủ quản cấp Phòng/Ban (mã IDxx.xx.xx). DE không có Sở nào → ghi nhận "Dữ liệu cần xây dựng mới" (owner = NULL). Nếu không đồng ý → trả về Manager (03b)
05b Thực hiện quy hoạch – Ban hành: Approver công bố chính thức Từ điển Dữ liệu chuẩn của Thành phố Approver Bảng dữ liệu quy hoạch (APPROVED) Từ điển Dữ liệu – trạng thái PUBLISHED Sau khi PUBLISHED, Staff có thể tra cứu. Cần quy trình riêng để cập nhật/thu hồi
06 Khai thác thông tin: Staff sử dụng dữ liệu quy hoạch đã ban hành cho nghiệp vụ Staff Từ điển Dữ liệu (PUBLISHED) Thông tin tra cứu phục vụ nghiệp vụ Nhà thầu phần mềm tra cứu trước khi phát triển mới, tránh trùng lắp

Điểm Ra Quyết Định

Quyết Định 1a: Data Owner xác nhận thông thường (Bước 04b)

  • Điều Kiện: Data Owner có đồng ý với dữ liệu hiện trạng của đơn vị không?
  • Nếu Đồng ý: Xác nhận → chờ đủ > 70% Sở → Approver xét tổng thể
  • Nếu Góp ý thông thường: Data Owner ghi góp ý chỉnh sửa (comment), trả về Manager (03b) để điều chỉnh matching
  • Quy Tắc Nghiệp Vụ: Data Owner chỉ xem (read-only) + góp ý, không trực tiếp chỉnh sửa dữ liệu. Manager điều chỉnh theo góp ý rồi gửi lại Data Owner.

Quyết Định 1b: Data Owner đánh dấu DISPUTED (Bước 04c)

  • Điều Kiện: Data Owner có tranh chấp nghiêm trọng với kết quả matching không?
  • Nếu Có: Data Owner đánh dấu ô Bảng C là DISPUTED + ghi chú lý do (≥ 20 ký tự). Approver nhận thông báo
  • Xử lý (04d): Approver giải quyết theo 3 hướng: (a) xác nhận ánh xạ gốc → CONFIRMED, (b) bác bỏ hoàn toàn → REJECTED, (c) điều chỉnh sang DE khác
  • Guard cứng: Không thể tiến lên Bước 05 khi còn ô DISPUTED

Quyết Định 2: Approver phê duyệt bản đồ hiện trạng (Bước 04e, trước Bước 05a)

  • Tiền điều kiện cứng:
  • > 70% Sở đã xác nhận (hoặc hết deadline → Approver chốt đơn phương)
  • 0 ô DISPUTED còn tồn tại — hệ thống block nếu vi phạm
  • Nếu Đồng ý: Chốt chủ quản theo quy tắc 1:1 đến cấp Phòng/Ban (05a)
  • Nếu Không: Trả về Manager rà soát lại (quay về 03b)
  • Quy Tắc Nghiệp Vụ: Approver quyết định cuối cùng về đơn vị chủ quản khi các bên chưa đồng thuận.

Trạng Thái Ô Bản Đồ Hiện Trạng (Bảng C)

Mỗi ô trong ma trận Data Element × Đơn vị có một trạng thái riêng, phản ánh tình trạng dữ liệu tại đơn vị đó.

Trạng thái Ý nghĩa Ai set Quy ước màu
DATABASE Có trong CSDL cấu trúc Discovery tự động hoặc khai báo
DATABASE_OVERLAP Cùng DE lưu ở nhiều bảng/CSDL trong cùng đơn vị Discovery tự động
FRAGMENTED Dữ liệu rải rác, chưa cấu trúc Sở khai báo
READY Có CSDL + API, sẵn sàng kết nối Sở khai báo
EMPTY Sở không có DE này Discovery hoặc Sở xác nhận Xám
DISPUTED Sở không đồng ý với gợi ý mapping Data Owner hoặc Manager Đỏ
CONFIRMED Đã xác nhận đúng Sở xác nhận hoặc Approver Xanh lá
REJECTED Bác bỏ ánh xạ (Approver quyết định) Approver

Quy ước màu trên giao diện Bảng C: - Xanh lá: Ô đã được Sở xác nhận (CONFIRMED) - Vàng: Có gợi ý AI, chưa xác nhận - Đỏ: Đang DISPUTED - Xám: Sở không có DE này (EMPTY)


Xử Lý Ngoại Lệ

Ngoại Lệ Khi Nào Xảy Ra Cách Xử Lý Vai Trò Chịu Trách Nhiệm
Không có metadata cấu trúc để Discovery Bước 02 – Đơn vị chưa có CSDL hoặc không cung cấp được file Manager khai báo thủ công dựa trên thông tin từ Data Owner đơn vị Manager + Data Owner
Confident score toàn bộ dưới ngưỡng Bước 03a – AI không thể matching hiệu quả Manager thực hiện mapping thủ công toàn bộ tại bước 03b Manager
Xung đột chủ quản – nhiều đơn vị tranh chấp Bước 03b – Nhiều đơn vị cùng cho rằng mình là chủ quản Chuyển lên Approver quyết định; áp dụng nguyên tắc "đơn vị tạo lập dữ liệu gốc" Approver
Data Owner không phản hồi xác nhận Bước 04a/04b – Data Owner không rà soát trong thời hạn Gửi nhắc nhở; nếu quá hạn, escalate lên Approver để quyết định Manager → Approver
Approver từ chối nhiều lần Trước bước 05a – Bản đồ hiện trạng bị trả về lặp lại Manager tổ chức họp trực tiếp với Data Owner và Approver để thống nhất Manager
Sở đánh dấu DISPUTED nhiều ô Bước 04c – Sở không đồng ý nhiều ánh xạ Approver xử lý từng ô; guard block Bước 05 đến khi hết DISPUTED Approver

Điều Kiện Tiên Quyết

  • Người dùng (Manager, Data Owner, Approver, Staff) đã đăng nhập hệ thống qua SSO
  • Admin đã thiết lập cây tổ chức các Sở/Ban/Ngành và phân quyền cho từng vai trò
  • Có ít nhất một nguồn dữ liệu (CSDL, DDL, CSV/Excel) hoặc thông tin đơn vị để khai báo thủ công

Điều Kiện Sau Khi Hoàn Thành

  • Mỗi Data Element trong hệ thống có đúng một đơn vị chủ quản (quy tắc 1:1)
  • Từ điển Dữ liệu ở trạng thái PUBLISHED, Staff có thể tra cứu và khai thác
  • Bảng dữ liệu quy hoạch ghi nhận đầy đủ: Data Element, đơn vị chủ quản, hệ thống nguồn

Sơ Đồ Chuyển Trạng Thái

Sơ đồ trạng thái quy trình tổng

Kroki

Sơ đồ trạng thái ô Bảng C

Kroki


Ghi Chú

  • Đánh số bước (01–06) khớp với sơ đồ gốc trong Business Understanding. Bước 04c/04d/04e là bổ sung mới (v1.2) cho DISPUTED workflow.
  • SLA cho bước xác nhận của Data Owner (04a/04b) chưa được xác định (TBD). Tham khảo SRS v1.3: 10 ngày làm việc.
  • Quy trình cập nhật/thu hồi Từ điển Dữ liệu sau khi PUBLISHED chưa được định nghĩa trong giai đoạn này.
  • Phương thức thu thập metadata cấu trúc (bước 02): Giai đoạn 1 hỗ trợ CSV, SQL DDL, khai báo thủ công. Các phương thức LDOP API và PostgreSQL Direct được ghi nhận cho giai đoạn sau.

Câu hỏi mở chờ xác nhận

# Câu hỏi Trạng thái Nguồn
BPF-Q1 Tên vai trò: dùng tên BU (Manager/Data Owner/Approver) hay tên SRS (Data Steward/Data Owner/Survey Approver)? ✅ Đã chốt: Dùng tên BU — Manager, Data Owner, Approver, Staff, Admin. Không dùng Data Steward (role Manager thay thế) GAP 2
BPF-Q2 Anchored Data: Manager toàn quyền CRUD hay phân Core/Extension với workflow đề xuất-phê duyệt? ✅ Đã chốt: Manager toàn quyền CRUD Anchored Data. Data Owner đề xuất mở rộng, Manager phê duyệt GAP 3