Business Understanding: Nền Tảng Quản Lý, Quản Trị Dữ Liệu Thành Phố¶

Phiên bản: 1.1 Ngày tạo: 2026-03-24 Cập nhật: 2026-03-31 – Làm rõ Discovery & Mapping (chức năng cốt lõi) Trạng thái: Verified

1. Mục Tiêu & Mục Đích (Goals & Objectives)¶

1.1 Bối cảnh & Vấn đề hiện tại¶

Hiện nay, dữ liệu của Thành phố đang ở tình trạng phân tán, thiếu kiểm soát và chưa được tổ chức có hệ thống:

Dữ liệu rời rạc: Mỗi Sở/Ban/Ngành lưu trữ dữ liệu độc lập, không có tiêu chuẩn chung.
Trùng lặp & chồng chéo: Cùng một thông tin (ví dụ: số CCCD, tên công dân) được lưu trữ tại nhiều đơn vị khác nhau, dẫn đến mâu thuẫn dữ liệu.
Phân mảnh: Một số dữ liệu chỉ tồn tại tại một đơn vị duy nhất nhưng chưa được chia sẻ, gây khó khăn cho các đơn vị cần sử dụng.
Thiếu kiểm soát & an toàn: Không có cơ chế xác định ai là chủ quản dữ liệu, không có chính sách quản lý quyền truy cập nhất quán.
Không có nguồn sự thật duy nhất (Single Source of Truth): Các hệ thống ứng dụng không biết phải lấy dữ liệu từ đâu là chính xác.

1.2 Mục tiêu dự án¶

Dự án xây dựng Nền tảng Quản lý, Quản trị Dữ liệu Thành phố nhằm:

Quy hoạch dữ liệu toàn Thành phố: Xây dựng bộ metadata chuẩn mô tả toàn bộ tài nguyên dữ liệu của các cơ quan thuộc Thành phố theo cấu trúc Domain – Sub Domain – Data Element. Hệ thống không lưu trữ data thực tế, chỉ lưu định nghĩa, cấu trúc và thông tin quản trị.
Xác lập chủ quản dữ liệu (Data Ownership): Mỗi Data Element chỉ có một đơn vị chủ quản duy nhất đến cấp Phòng/Ban theo nguyên tắc 1:1 (mã IDxx.xx.xx), loại bỏ tình trạng chồng chéo trách nhiệm.
Xây dựng bản đồ dữ liệu hiện trạng: Tạo bức tranh toàn cảnh về dữ liệu hiện có tại các Sở/Ban/Ngành, xác định trùng lặp và phân mảnh.
Tạo nền tảng tra cứu và quản trị metadata hiệu quả: Metadata được quy hoạch và công bố là tiền đề để các hệ thống downstream triển khai AI, phân tích dự báo và cải cách hành chính chuyên sâu.
Hỗ trợ ra quyết định dựa trên dữ liệu: Lãnh đạo Thành phố có thể chỉ đạo điều hành dựa trên dữ liệu chuẩn xác, nhất quán.

1.3 Kết quả kỳ vọng (Success Criteria)¶

KPI	Mô tả
100% đơn vị sử dụng nền tảng	Toàn bộ Sở/Ban/Ngành/Phòng thuộc Thành phố đều tham gia và sử dụng hệ thống
Dữ liệu toàn Thành phố thống nhất đầu mối	Mỗi Data Element chỉ có một đơn vị chủ quản duy nhất – không còn tình trạng chồng chéo trách nhiệm
Độ chính xác mapping dữ liệu cao	Quá trình xây dựng bản đồ dữ liệu hiện trạng phải đạt độ chính xác cao thông qua nhiều bước kết hợp: rule-based matching và AI. Mỗi gợi ý mapping phải có confident score và mỗi gợi ý phải được con người xem xét trước khi chốt (giai đoạn hiện tại không auto-accept). Tương lai có thể enable auto-accept khi vượt ngưỡng threshold
Bức tranh dữ liệu toàn TP	Nhìn rõ toàn bộ tài nguyên dữ liệu của Thành phố
Loại bỏ trùng lặp phần mềm	Nhà thầu tra cứu từ điển dữ liệu trước khi phát triển, tránh xây dựng hệ thống thu thập dữ liệu đã tồn tại
Tối ưu hóa chi phí	Dữ liệu tạo lập 1 lần, sử dụng nhiều lần trên nhiều hệ thống
Sẵn sàng cho AI	Dữ liệu sạch, có cấu trúc phục vụ triển khai AI và dự báo

2. Người Dùng Hệ Thống (Actors / Personas)¶

Vai trò	Mô tả	Trách nhiệm chính
Data Owner – Quản trị dữ liệu đơn vị	Cán bộ quản trị dữ liệu tại các Sở/Ban/Ngành, đăng nhập qua SSO	Đưa cấu trúc dữ liệu của đơn vị vào hệ thống; rà soát và xác nhận bản đồ dữ liệu hiện trạng; chủ trì quản trị và chủ sở hữu dữ liệu được phân công
Manager – Quản trị dữ liệu kỹ thuật	Cán bộ kỹ thuật thuộc Ban Quản trị Dữ liệu Tỉnh/Thành phố hoặc Sở KHCN	Thiết lập khung dữ liệu định vị (Anchored Data); chạy công cụ khám phá cấu trúc CSDL; xây dựng bản đồ dữ liệu hiện trạng
Approver – Người phê duyệt	Thành viên Ban Quản trị Dữ liệu Tỉnh/Thành phố	Thẩm định và chốt bản đồ dữ liệu hiện trạng; quyết định đơn vị chủ quản khi chưa đồng thuận; ban hành bảng quy hoạch dữ liệu
Staff – Người tra cứu	Cán bộ các đơn vị có nhu cầu tra cứu thông tin dữ liệu (nhà thầu phần mềm, chuyên viên)	Tra cứu, tìm kiếm thông tin Data Element đã quy hoạch qua từ điển dữ liệu
Admin – Quản trị hệ thống	Cán bộ vận hành hệ thống	Quản lý tài khoản người dùng; phân quyền theo vai trò; quản lý cây tổ chức; import Master Data & Seed dữ liệu ban đầu

3. Quy Trình & Tính Năng Chính (High-level Flows)¶

Hệ thống hỗ trợ lộ trình quy hoạch dữ liệu theo quy trình có trạng thái vòng đời rõ ràng:

⚠️ Lưu ý: Quy trình dưới đây là đề xuất tham khảo, chưa được chốt chính thức. Cần xác nhận lại với stakeholder trước khi thiết kế chi tiết.

Vòng đời trạng thái đề xuất: DRAFT → IN_REVIEW → APPROVED → PUBLISHED

Main Flow

3.1 (01) Thiết lập dữ liệu định vị – Anchored Data¶

Người thực hiện: Manager (thiết lập khung cốt lõi), Data Owner (đề xuất mở rộng)
Manager khai báo khung dữ liệu chuẩn cho Thành phố gồm: Domain → Sub Domain → Data Element.
Khung này dựa trên quy định từ Chính phủ, Bộ, Ngành và thực tiễn địa phương.
Mã tự động sinh: Mã Domain, Sub Domain, Data Element được hệ thống sinh tự động theo định dạng [DM{N}], [DM{N}.{M}], [DE{NNN}-DM{N}.{M}]. Không cho phép chỉnh sửa thủ công sau khi tạo.
Cơ chế đề xuất mở rộng: Sau khi Manager tạo khung cốt lõi, các Sở ngành (Data Owner) có thể đề xuất bổ sung Sub Domain hoặc Data Element đặc thù chuyên ngành. Đề xuất ở trạng thái PENDING → Manager rà soát và phê duyệt/từ chối. Sở ngành chỉ đề xuất trong Domain đã có — không tạo Domain cấp cao mới.
Trạng thái: DRAFT
Đầu ra: Bảng dữ liệu định vị (Anchored Data Table).

Ví dụ cấu trúc (mã tự động sinh):
[DM1]: Con người
  └── [DM1.1]: Định danh
        ├── [DE001-DM1.1]: Số CCCD
        └── [DE002-DM1.1]: Họ và tên
  └── [DM1.2]: Y tế & Sức khỏe
        ├── [DE001-DM1.2]: Số BHYT
        └── [DE002-DM1.2]: Nhóm máu

3.2 (02) Khám phá dữ liệu – Data Discovery¶

Đây là chức năng cốt lõi của hệ thống, yêu cầu chất lượng cao.

Người thực hiện: Manager
Mục đích: Xác định đơn vị nào đang lưu trữ những Data Element nào bằng cách đối chiếu dữ liệu thực tế của đơn vị với khung Anchored Data đã thiết lập. Từ đó xây dựng bản đồ hiện trạng: ai đang giữ gì, ở đâu bị chồng chéo, ở đâu bị phân mảnh.

Quy trình chi tiết:

Thu thập metadata từ đơn vị: Manager liên hệ từng Sở/Ban/Ngành, xin cung cấp thông tin về cấu trúc dữ liệu mà đơn vị đang quản lý. Đơn vị cung cấp dưới dạng:
File CSV có header chứa tên các field (field name)
File SQL DDL mô tả database schema (CREATE TABLE, tên cột, kiểu dữ liệu)
Khai báo thủ công cho các nguồn chưa có file
Upload & Parse tự động: Manager upload file lên hệ thống. Hệ thống tự động parse/trích xuất:
Danh sách field names từ CSV header hoặc DDL
Kiểu dữ liệu (nếu có trong DDL)
Nhóm theo bảng/entity (nếu DDL có nhiều bảng)
Kết quả: Danh sách field names của đơn vị, sẵn sàng cho bước mapping (03a).
Đầu ra: Bảng metadata cấu trúc theo đơn vị – danh sách tất cả field names đã trích xuất, phân loại theo nguồn file.

3.3 (03a + 03b) Xây dựng bản đồ dữ liệu hiện trạng¶

Đây là chức năng quan trọng nhất – đối chiếu field thực tế của đơn vị với Anchored Data để xác định đơn vị đang lưu trữ những Data Element nào.

Người thực hiện: Manager + Hệ thống (AI)

Bước 03a – AI đối chiếu (matching) field với Anchored Data: - Hệ thống lấy danh sách field names đã trích xuất từ bước 02, đối chiếu với các Data Element trong khung Anchored Data. - Phương pháp matching kết hợp nhiều bước: rule-based matching (tên trường, kiểu dữ liệu) và AI (ngữ nghĩa, pattern recognition). - Mỗi gợi ý matching được gán confident score. - Kết quả matching cho mỗi field: - Match → Field này tương ứng Data Element X trong Anchored Data → đơn vị đang lưu trữ DE đó → đánh dấu trên bản đồ hiện trạng. Nếu DE đó đã có đơn vị khác lưu trữ → phát hiện chồng chéo. - Không match → Field chưa có trong Anchored Data → có thể là field nội bộ của đơn vị, hoặc cần bổ sung Data Element mới vào khung Anchored Data. - Giai đoạn hiện tại: mọi gợi ý matching phải Manager rà soát (không auto-accept — xem Q9). Giai đoạn sau có thể enable auto-accept khi confident score vượt ngưỡng threshold. Các trường hợp dưới ngưỡng luôn chuyển sang Manager xử lý thủ công. - Trạng thái: IN_REVIEW

Bước 03b – Manager rà soát & đề xuất quyền sở hữu: - Manager xem xét kết quả matching từ AI, xác nhận hoặc chỉnh sửa. - Xử lý các field không match: quyết định bỏ qua (field nội bộ) hoặc đề xuất bổ sung Data Element mới. - Đề xuất đơn vị chủ quản cho từng Data Element dựa trên bản đồ hiện trạng. - Nếu Approver từ chối (bước sau), quay lại 03b để điều chỉnh. - Đầu ra: Bản đồ dữ liệu hiện trạng (bản đề xuất) – ma trận Data Element × Đơn vị, chỉ rõ chồng chéo và phân mảnh.

3.4 (04a + 04b) Xác nhận dữ liệu hiện trạng¶

Người thực hiện: Data Owner (từng đơn vị)

Bước 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 trong Anchored Data. - Chế độ read-only — Data Owner không có quyền chỉnh sửa kết quả matching hay metadata.

Bước 04b – Xác nhận: - Data Owner xác nhận đồng ý hoặc không đồng ý. - Nếu không đồng ý → Data Owner ghi góp ý chỉnh sửa (comment), trả về Manager (03b) để điều chỉnh matching. - Nếu đồng ý → chuyển lên Approver phê duyệt.

3.5 (05a + 05b) Thực hiện quy hoạch & Ban hành¶

Người thực hiện: Approver

Bước 05a – Chốt quyền sở hữu: - Approver xem xét toàn bộ bản đồ hiện trạng đã được Data Owner xác nhận và Bảng C đã chốt (> 70% Sở xác nhận, 0 ô DISPUTED). - Nếu không đồng ý → trả về Manager (03b) để rà soát lại. - Nếu đồng ý → chốt đơn vị chủ quản duy nhất cho mỗi Data Element đến cấp Phòng/Ban (mã IDxx.xx.xx) theo Quy tắc 1:1. Data Element không có Sở nào lưu trữ → ghi nhận "Dữ liệu cần xây dựng mới" (owner = NULL). - Trạng thái: APPROVED - Đầu ra: Bảng dữ liệu quy hoạch (Bảng D) — mỗi DE gán chủ quản cấp Phòng/Ban.

Bước 05b – Ban hành: - Approver công bố Từ điển Dữ liệu chuẩn của Thành phố. - Trạng thái: PUBLISHED - Đầu ra: Từ điển Dữ liệu chính thức.

3.5 Từ điển Dữ liệu & Giám quản Phần mềm (Data Dictionary / Software Governance)¶

Cung cấp chức năng tra cứu (search) toàn bộ Data Element, Domain, Sub Domain đã được quy hoạch.
Hỗ trợ tra cứu theo domain, theo cây tổ chức đơn vị, hoặc tìm kiếm bằng từ khóa.
Cho phép nhà thầu phần mềm và cán bộ tra cứu xem loại dữ liệu nào đã có định nghĩa và đơn vị chủ quản trước khi phát triển mới, tránh xây dựng trùng lắp các hệ thống thu thập dữ liệu.
Đóng vai trò Từ điển Dữ liệu (Data Dictionary) của Thành phố: mỗi Data Element có mô tả rõ ràng về ý nghĩa, định dạng, đơn vị chủ quản và hệ thống chứa dữ liệu.
Người dùng: Staff (tra cứu), Data Owner/Manager (xem thông tin quy hoạch).
Đầu ra: Giao diện tra cứu từ điển dữ liệu cho nhà thầu và cán bộ kỹ thuật.

3.6 Quản trị hệ thống (System Administration)¶

Quản lý tài khoản người dùng: tạo mới, sửa, xóa, tạm dừng.
Gán vai trò (Data Owner, Manager, Approver, Staff) cho từng người dùng tương ứng với đơn vị.
Người dùng: Admin.
Đầu ra: Danh sách người dùng và phân quyền.

3.7 Hoạch định dữ liệu tương lai (Future Data Planning)¶

Cho phép Manager đánh dấu (flag) một Data Element là "Dữ liệu tương lai" – tức là loại dữ liệu mà Thành phố hoạch định sẽ thu thập trong tương lai nhưng hiện tại chưa có đơn vị nào cung cấp.
Quản lý danh sách các Data Element tương lai gắn với nhu cầu quản lý, điều hành và mục tiêu phát triển kinh tế – xã hội.
Approver xem xét và phê duyệt danh sách hoạch định.
Đầu ra: Bảng dữ liệu tương lai (Future Data Table) – danh sách Data Element được hoạch định thu thập trong tương lai.

3.8 Quy trình Cập nhật Từ điển Sau Ban hành (Giai đoạn sau)¶

Trạng thái: Ghi nhận — chưa triển khai trong giai đoạn hiện tại. Mô tả để định hướng thiết kế và chuẩn bị cho phase sau.

Sau khi Từ điển được ban hành (PUBLISHED), cần có quy trình chuẩn để cập nhật nội dung Data Element — sửa định nghĩa, thay đổi kiểu dữ liệu, cập nhật chủ quản, bổ sung thuộc tính. Nếu không có quy trình này, Từ điển sẽ lỗi thời hoặc bị sửa không kiểm soát.

Luồng dự kiến:

Data Owner tạo yêu cầu thay đổi → hệ thống tự động phân loại mức độ ảnh hưởng (Minor / Major / Critical) dựa trên: field nào bị thay đổi, Data Element thuộc domain cốt lõi hay mở rộng, bao nhiêu Sở đang sử dụng → Manager rà soát → phê duyệt hoặc trả về → Admin phát hành phiên bản mới.

Cơ chế nhắc nhở và escalation:

Nhắc nhở 1 ngày trước deadline, cảnh báo khi quá hạn, escalate lên Ban Chỉ đạo khi quá hạn 3 ngày (workflow Critical).

Phiên bản hoá:

Từ điển có nhiều phiên bản (Minor release / Major release). Staff có thể tra cứu theo phiên bản cũ (backward compatibility).

Chi tiết đầy đủ: xem Backlog "Quy trình Vận hành Sau Ban hành" trong Epic Document.

4. Dữ Liệu & Báo Cáo (Data & Reporting)¶

4.1 Loại metadata hệ thống quản lý¶

Hệ thống chỉ lưu trữ metadata – tức là thông tin mô tả, định nghĩa và quản trị về dữ liệu – không lưu data thực tế.

Loại metadata	Mô tả
Domain / Sub Domain	Nhóm và phân nhóm để phân loại Data Element
Data Element	Định nghĩa một trường dữ liệu: tên, mô tả, kiểu dữ liệu, mã định danh (VD: DE001-DM1.1)
Metadata cấu trúc CSDL	Thông tin về bảng, cột từ CSDL của các Sở/Ban/Ngành (tên bảng, tên cột, kiểu dữ liệu – không phải data bên trong)
Bản đồ hiện trạng	Ma trận Data Element × đơn vị với trạng thái (chồng chéo, phân mảnh, sẵn sàng kết nối)
Thông tin chủ quản	Mỗi Data Element → một đơn vị chịu trách nhiệm chính
Sơ đồ tổ chức	Danh sách tất cả đơn vị thuộc Thành phố với mã định danh

4.2 Báo cáo cần thiết¶

Báo cáo	Mô tả	Vai trò sử dụng
Bảng dữ liệu định vị	Toàn bộ khung Anchored Data	Manager
Bảng dữ liệu hiện trạng	Ma trận tất cả Data Element × Sở/Ban/Ngành	Manager, Approver, Data Owner
Bảng dữ liệu quy hoạch	Data Element + đơn vị chủ quản	Approver, Manager, Staff
Báo cáo chồng chéo	Các Data Element đang bị lưu trùng nhiều nơi	Manager, Approver
Báo cáo phân mảnh	Các Data Element chỉ có ở một số ít đơn vị	Manager, Approver
Bảng dữ liệu tương lai	Định nghĩa các Data Element cần tạo lập trong tương lai	Manager, Approver

5. Phi Chức Năng (Non-functional Requirements)¶

⚠️ Lưu ý: Các mục dưới đây là giả định ban đầu dựa trên bối cảnh hệ thống công quyền. Cần xác nhận với stakeholder – xem Section 8.

5.1 Bảo mật (Security)¶

Xác thực tập trung: Người dùng từ các Sở/Ban/Ngành đăng nhập qua hệ thống SSO (Single Sign-On) của Tỉnh/Thành phố.
Phân quyền theo vai trò: Mỗi vai trò (Data Owner, Manager, Approver, Staff, Admin) có quyền truy cập và thao tác riêng biệt.
Kiểm soát metadata theo đơn vị: Data Owner chỉ xem và xác nhận metadata thuộc phạm vi đơn vị mình quản lý.
Audit log: Ghi lại mọi thao tác thay đổi dữ liệu (ai, khi nào, thay đổi gì).
Tuân thủ Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân: Hệ thống phải đảm bảo tuân thủ. Tuy nhiên, trong giai đoạn này hệ thống chỉ lưu trữ metadata cấu trúc (tên trường, kiểu dữ liệu, đơn vị chủ quản) – không lưu dữ liệu cá nhân thực tế (VD: không lưu số CCCD cụ thể, chỉ lưu định nghĩa "trường Số CCCD"). Do đó rủi ro vi phạm dữ liệu cá nhân trong giai đoạn này là thấp.

5.2 Hiệu năng (Performance)¶

Quy mô đơn vị: Vài trăm đơn vị (Sở/Ban/Ngành/Phòng) tham gia hệ thống.
Người dùng đồng thời: Hàng nghìn user sử dụng cùng lúc – hệ thống cần thiết kế để chịu tải cao.
Chức năng Discovery (đọc cấu trúc CSDL) có thể mất thời gian dài – cần cơ chế xử lý nền (background job) để không ảnh hưởng trải nghiệm người dùng.

Chỉ số hiệu năng mục tiêu:

Chỉ số	Mục tiêu	Cách đo
API search P95	< 2 giây	Prometheus histogram
API write P95	< 500ms	Prometheus histogram
Throughput	> 200 req/s concurrent	Load test
Availability	99.5% / tháng	Synthetic monitoring 5 phút/lần
RTO (Recovery Time Objective)	< 4 giờ sau sự cố	Restore drill hàng tháng
RPO (Recovery Point Objective)	< 15 phút	WAL replication lag
Security	0 Critical, < 5 High vulnerability	Trivy + OWASP ZAP trong CI
Code coverage	> 95% unit test	JaCoCo / Pytest coverage
Audit trail	100% write operations có audit log	Integration test
Notification delivery	Gửi trong vòng 5 phút sau trigger	Log monitoring

SLA nghiệp vụ:

Quy trình	SLA	Ghi chú
Xác nhận hiện trạng đơn vị (Bước 04a/04b)	10 ngày làm việc	Survey workflow — Data Owner phải phản hồi trong thời hạn
Quy hoạch chủ quản (Bước 05a)	5 ngày làm việc	Sau khi Bảng C đã chốt

5.3 Nền tảng (Platform)¶

Ứng dụng Web (truy cập qua trình duyệt, không cần cài đặt phần mềm phía client).
Triển khai On-premise tại hạ tầng của Thành phố (Data Center nội bộ).
Tích hợp với hệ thống SSO hiện có của Tỉnh/Thành phố.

6. Tích Hợp & Phụ Thuộc (Integrations & Dependencies)¶

Hệ thống	Loại tích hợp	Mục đích
Hệ thống SSO Thành phố	Xác thực người dùng	Đăng nhập tập trung cho người dùng từ các Sở/Ban/Ngành (cụ thể hệ thống SSO nào – TBD)
CSDL của các Sở/Ban/Ngành	Đọc cấu trúc (Discovery)	Thu thập metadata cấu trúc bảng/cột để xây dựng bản đồ dữ liệu
Nguồn metadata cấu trúc (CSDL / file DDL / CSV/Excel / khai báo thủ công)	Đầu vào cho Discovery	Cung cấp metadata cấu trúc (schema) để xây dựng bản đồ hiện trạng. Phương thức kết nối cụ thể chưa được chốt – TBD
Hệ thống AI	Công cụ hỗ trợ	Hỗ trợ xác định Data Element tương tự khi xây dựng bản đồ hiện trạng
Từ điển Dữ liệu (Data Dictionary)	Module nội bộ (trong scope)	Tra cứu dữ liệu đã có, giúp nhà thầu phần mềm tránh phát triển trùng lắp
Nền tảng phân tích, xử lý dữ liệu tổng hợp	Downstream	Sử dụng kết quả metadata đã quy hoạch (thông tin chủ quản, cấu trúc chuẩn) để định hướng thu thập và phân tích data thực tế

7. Ngoại Vi (Out of Scope)¶

Dự án không bao gồm các hạng mục sau:

Xây dựng hay sửa đổi CSDL tác nghiệp của các Sở/Ban/Ngành – hệ thống chỉ đọc cấu trúc (metadata), không can thiệp vào dữ liệu gốc.
Di chuyển hoặc đồng bộ dữ liệu thực tế giữa các hệ thống (ETL dữ liệu thực tế).
Lưu trữ dữ liệu cá nhân thực tế (CCCD, BHYT, v.v.) – chỉ lưu metadata cấu trúc.
Xây dựng Nền tảng phân tích, xử lý dữ liệu tổng hợp – hệ thống này là downstream consumer.
Triển khai AI/ML models – hệ thống sử dụng AI như công cụ hỗ trợ nhưng không xây dựng model.
Hệ thống quản lý quy trình hành chính (e-Government workflows).

8. Tiêu Chuẩn & Khung Pháp Lý Áp Dụng (Regulatory & Standards Compliance)¶

⚠️ Lưu ý: Danh sách dưới đây là các văn bản/tiêu chuẩn cần nghiên cứu kỹ và đối chiếu trong quá trình thiết kế chi tiết. Mức độ ảnh hưởng cụ thể sẽ được làm rõ ở các phase sau.

Văn bản / Tiêu chuẩn	Loại	Mô tả	Nguồn
Luật Dữ liệu số 60/2024/QH15 (hiệu lực 01/07/2025)	Pháp lý – Bắt buộc	Văn bản nền tảng, quy định trực tiếp nghĩa vụ xây dựng Danh mục Dữ liệu và Từ điển Dữ liệu cấp địa phương	vanban.chinhphu.vn
Khung Quản trị Dữ liệu Quốc gia – QĐ 2439/QĐ-TTg (2025)	Pháp lý – Bắt buộc	Hướng dẫn triển khai Luật Dữ liệu; định nghĩa các trụ cột quản trị, tiêu chuẩn metadata và cơ chế kết nối quốc gia	vanban.chinhphu.vn
Nghị định 13/2023/NĐ-CP	Pháp lý – Bắt buộc	Bảo vệ dữ liệu cá nhân (rủi ro thấp ở giai đoạn này – xem Section 5.1)
DAMA-DMBOK	Tiêu chuẩn quốc tế – Tham chiếu	Khung quản trị dữ liệu de facto; tham chiếu cho thiết kế vai trò, quy trình, Data Catalog, Data Dictionary và Data Quality	dama.org
ISO/IEC 11179 – Metadata Registry	Tiêu chuẩn quốc tế – Tham chiếu	Tiêu chuẩn thiết kế Metadata Registry; định nghĩa mô hình Data Element, vòng đời, naming convention và classification scheme	fmit.vn
ISO/IEC 27001 – Information Security Management	Tiêu chuẩn quốc tế – Tham chiếu	Tiêu chuẩn an toàn thông tin; áp dụng cho kiểm soát truy cập, mã hóa, audit log và liên tục hoạt động

9. Câu Hỏi Cần Làm Rõ (Questions for Clarification)¶

#	Câu hỏi	Trạng thái	Ảnh hưởng đến
Q1	Nền tảng Web hay Desktop? On-premise hay Cloud?	✅ Web / On-premise	Non-functional
Q2	Quy mô đơn vị và user đồng thời?	✅ Vài trăm đơn vị / hàng nghìn user	Performance
Q3	Hệ thống SSO là hệ thống nào?	⏳ TBD – làm rõ ở giai đoạn kỹ thuật	Integration
Q4	"Hệ thống giám quản phần mềm" là gì?	✅ Module Từ điển Dữ liệu – trong scope	Scope
Q5	KPIs thành công cụ thể?	✅ 100% đơn vị sử dụng, dữ liệu thống nhất đầu mối	Success Criteria
Q6	SLA xác nhận của người quản trị đơn vị?	✅ 10 ngày làm việc cho xác nhận hiện trạng; 5 ngày cho quy hoạch chủ quản	Business Rules
Q7	Tuân thủ Nghị định 13/2023/NĐ-CP?	✅ Bắt buộc tuân thủ; giai đoạn này không lưu dữ liệu cá nhân thực tế	Security
Q8	Bổ sung Out of Scope?	⏳ TBD – giữ nguyên danh sách hiện tại, cập nhật khi có thêm thông tin	Scope
Q9	AI matching: auto-accept hay human review?	✅ Đã chốt: Giai đoạn này không auto-accept — mọi gợi ý phải human review. Tương lai có thể enable auto-accept lại. Mọi quyết định ghi vào ai_feedback_log	Matching / UX
Q10	Tên vai trò: dùng tên BU hay tên SRS?	✅ Đã chốt: Owner → Data Owner. Các tên khác giữ nguyên (Manager, Approver, Staff, Admin). Data Steward dùng role Manager. Agent System chưa cần GĐ này	Toàn bộ tài liệu
Q11	Anchored Data: Manager toàn quyền CRUD hay phân Core/Extension với workflow đề xuất-phê duyệt từ Sở ngành?	✅ Đã chốt: Không dùng role Data Steward — Manager đảm nhận toàn bộ quản trị Anchored Data. Data Owner có thể đề xuất mở rộng (EP-02-004), Manager phê duyệt (EP-02-005)	Phân quyền / Use Cases

Lưu ý: Q3, Q6, Q8 còn mở nhưng không chặn Phase 2. Q9, Q10, Q11 đã chốt (2026-04-08).