Tổng quan & định hướng hệ thống

ERP Nhân Hòa là hệ thống quản trị nội bộ hợp nhất nhân sự, công việc, khách hàng tiềm năng và đánh giá hiệu quả trên một nền dữ liệu duy nhất — có ứng dụng web, máy tính để bàn và di động, kèm một trợ lý AI trả lời câu hỏi trong đúng phạm vi quyền của người hỏi.

Vấn đề đang giải quyết

Công việc của Nhân Hòa hiện chạy trên một nền Bitrix24 (xerp.nhanhoa.com) và một vành đai công cụ vệ tinh được viết thêm để bù những chỗ nền đó không với tới. Cách bố trí này vẫn vận hành được, nhưng sinh ra năm khoản chi phí lặp lại hằng tuần:

• Phân công thủ công. Một lead hoặc một task vào hệ thống phải chờ người điều phối mở danh sách, ước lượng ai đang rảnh, rồi gán tay. Việc này chậm, phụ thuộc trí nhớ và tạo lệch tải giữa các nhân sự trong cùng nhóm.
• Đánh giá hiệu quả nằm ngoài hệ thống. KPI đang được tổng hợp qua công cụ riêng rồi kết xuất ra Excel. Số liệu không quay ngược lại được vào nơi ra quyết định, và mỗi kỳ đánh giá lại là một lần gom tay.
• Mỗi phòng ban đo một kiểu, nhưng không có chỗ khai báo cái kiểu đó. Team kỹ thuật đo đúng hạn và chất lượng xử lý; team kinh doanh đo doanh số và tốc độ chạm khách. Hệ thống hiện tại chỉ có một bộ tiêu chí, nên phần chênh được xử lý bằng thoả thuận miệng.
• Dữ liệu phân mảnh. Hồ sơ nhân sự, kỹ năng, lịch trực, đơn nghỉ, task, lead và kết quả đánh giá nằm ở bốn nơi khác nhau. Một câu hỏi đơn giản như “tháng vừa rồi nhóm Hạ tầng xử lý bao nhiêu việc quá hạn, ai là người tải nặng nhất” cần ba lần mở công cụ và một lần ghép tay.
• Không có kênh tra cứu bằng ngôn ngữ tự nhiên. Người cần số liệu phải biết trước số liệu nằm ở màn hình nào; ai không biết thì đi hỏi người khác, tạo tải cho chính những người đang bận nhất.

Định vị hệ thống

Ba điểm phân biệt so với việc tiếp tục dùng Bitrix24 nguyên trạng:

Phạm vi phiên bản đầu

Chỉ số thành công

Sáu chỉ số dưới đây là căn cứ nghiệm thu giá trị của hệ thống, đo sau sáu tháng kể từ khi phân hệ tương ứng vận hành thật. Cột hiện trạng là số ước lượng từ khảo sát, cần chốt lại bằng một đợt đo nền trong giai đoạn khởi động.

Nguyên tắc thiết kế

Năm nguyên tắc dưới đây được áp cho mọi quyết định kỹ thuật và nghiệp vụ trong hồ sơ này. Khi hai phương án cùng khả thi, phương án phù hợp nguyên tắc hơn được chọn.

1. Con người giữ quyền quyết định cuối

   Máy đề xuất, người duyệt. Mọi cơ chế tự động — phân công, chấm điểm, cảnh báo — đều phải kèm lý do đọc được và phải có đường để người dùng bác bỏ. Chế độ tự động hoàn toàn chỉ được bật sau khi đo đủ độ tin cậy trên dữ liệu thật.

2. Cấu hình là dữ liệu, không phải mã nguồn

   Trọng số chấm điểm, ngưỡng quá tải, quy tắc chia lead, bộ tiêu chí KPI, ngưỡng xếp loại — tất cả nằm trong bảng cấu hình và sửa được qua giao diện quản trị. Thêm một team mới với cách đo mới không được phép kéo theo một lần phát hành mã.

3. Quyền được kiểm ở tầng dữ liệu

   Phạm vi dữ liệu một người nhìn thấy được tính một lần ở tầng truy vấn và áp cho mọi lối vào: giao diện, API, kết xuất báo cáo và trợ lý AI. Không có lối nào bỏ qua được lớp này.

4. Mọi con số truy ngược được về nguồn

   Điểm KPI trỏ về các bản ghi đã tạo ra nó; đề xuất phân công trỏ về các thành phần điểm; câu trả lời của trợ lý AI trỏ về truy vấn đã chạy. Số liệu không truy ngược được thì không được hiển thị như một kết luận.

5. Độc lập hoàn toàn với hệ thống cũ

   ERP Nhân Hòa làm chủ dữ liệu của mình ngay từ dòng mã đầu tiên. Không đồng bộ, không ghi ngược, không vận hành song song. xerp.nhanhoa.com chỉ giữ hai vai trò: bản tham chiếu tính năng trong lúc xây, và nguồn của một đợt nhập dữ liệu duy nhất khi cắt chuyển. Xong việc thì tắt.

Bản đồ tài liệu

Hồ sơ gồm 14 tài liệu chia năm nhóm. Bảng dưới đây gợi ý thứ tự đọc theo vai trò để không phải đọc tuần tự từ đầu đến cuối.

Đường đọc rút gọn

Ban điều hành

Tài liệu 01 → 03 → 12 → phần đăng ký rủi ro trong 13. Khoảng 25 phút.

Trưởng phòng ban, trưởng nhóm

Tài liệu 01 → 05 → 06 → 07. Đây là bốn tài liệu quyết định trải nghiệm hằng ngày của đơn vị.

Kỹ thuật

Tài liệu 02 → 09 → 10 → 11 → 06, rồi quay lại 05 khi bắt tay vào từng phân hệ.

Nhân sự

Tài liệu 05 (phân hệ M01–M05) → 07 → 11.

Hiện trạng & kết quả khảo sát

Khảo sát năm hệ thống đang vận hành hoặc đang dựng dở của Nhân Hòa, để trả lời một câu hỏi duy nhất: hệ thống mới phải làm được những gì, và trong số mã nguồn đã có, cái gì mang sang được.

Vị trí của khảo sát trong dự án

Khảo sát vì vậy không nhằm thiết kế một lớp tích hợp, mà nhằm ba việc cụ thể:

• Lập danh mục tính năng phải có trước khi được phép tắt hệ thống cũ — kết quả nằm ở tài liệu 03.
• Tìm mã nguồn và logic nghiệp vụ đã kiểm chứng có thể mang thẳng sang, thay vì viết lại từ con số không.
• Hiểu cấu trúc dữ liệu cũ đủ để viết công cụ nhập dữ liệu ở giai đoạn cuối.

  ĐANG CHẠY, SẼ BỊ THAY THẾ                  MÃ NGUỒN MANG SANG ĐƯỢC
  ┌───────────────────────────┐              ┌──────────────────────────┐
  │  xerp.nhanhoa.com         │              │  xerp-4s                 │
  │  (nền Bitrix24)           │              │  engine phân công        │
  │  · nhân sự, phòng ban     │  đọc 1 lần   │  chấm KPI, chỉ tiêu      │
  │  · task, workgroup        │─ ─ ─ ─ ─ ─ ▶ │  lược đồ dữ liệu, RBAC   │
  │  · lead (CRM)             │  khi cắt     │                          │
  │  · đơn nghỉ (Lists)       │  chuyển      └──────────────────────────┘
  └───────────────────────────┘                          ▲ đã hấp thụ
        │ tham chiếu tính năng                ┌──────────────────────────┐
        ▼                                     │  report-web4s (PHP)      │
  ┌───────────────────────────┐               │  bộ tiêu chí KPI 100 đ   │
  │  ERP NHÂN HÒA             │               └──────────────────────────┘
  │  xây mới, độc lập,        │
  │  làm chủ dữ liệu từ đầu   │   ĐỘC LẬP, KHÔNG TRONG PHẠM VI v1
  └───────────────────────────┘   ┌──────────────┐  ┌──────────────────┐
                                  │meeting-report│  │  wiki-nhanhoa    │
                                  │họp → đầu việc│  │  chưa khởi tạo   │
                                  └──────────────┘  └──────────────────┘

Kiểm kê từng hệ thống

xerp.nhanhoa.com — nền Bitrix24

Vai trò trong dự án

Bản tham chiếu tính năng, và nguồn dữ liệu cho một đợt nhập duy nhất. Đây là hệ thống sẽ bị thay thế, không phải hệ thống sẽ được tích hợp.

Đang chứa gì

Nhân sự, phòng ban, công việc, nhóm làm việc, lead và đơn xin nghỉ. Đây là toàn bộ danh sách dữ liệu cần nhập sang hệ thống mới ở giai đoạn cuối.

Cách trích xuất dữ liệu

REST qua inbound webhook. Bí mật xác thực nằm ngay trong đường dẫn dạng /rest/{userId}/{code}/. Mỗi phạm vi (task, crm, user, lists) có mã webhook riêng. Công cụ di trú là nơi duy nhất trong hệ thống được phép dùng các mã này.

Điểm cần lưu ý khi nhập dữ liệu

Định danh nhân sự là mã người dùng Bitrix. Task dùng RESPONSIBLE_ID, lead dùng ASSIGNED_BY_ID. Phòng ban lấy từ UF_DEPARTMENT, một người có thể thuộc nhiều phòng. Trường tuỳ biến khu vực UF_CRM dùng mã số (194 Hà Nội, 196 Hồ Chí Minh) nên cần bảng quy đổi sang danh mục mới.

Ràng buộc kỹ thuật

Có giới hạn tần suất gọi, nên đợt trích xuất phải chạy theo lô và có cơ chế thử lại. Không có webhook báo sự kiện — điều này từng là vấn đề lớn với phương án tích hợp, nhưng không còn liên quan khi hệ thống mới xây độc lập.

xerp-4s — lớp điều phối viết bằng NestJS

Vai trò trong dự án

Kho mã nguồn để mang sang. Đây là tài sản kỹ thuật giá trị nhất của khảo sát — nó chứa phần lớn logic nghiệp vụ khó của hệ thống mới, đã chạy trên dữ liệu thật.

Công nghệ

NestJS · Prisma · PostgreSQL · Redis · Docker. Lược đồ dữ liệu 1.151 dòng với hơn 50 thực thể và 20 kiểu liệt kê.

Phân hệ đã có

Phân công, duyệt, nhân sự, đội nhóm, kỹ năng, công việc, lead, nghỉ phép, báo cáo ngày, báo cáo kỳ, đánh giá, chỉ tiêu, hoa hồng, thông báo, thư điện tử, phân quyền, cấu hình, AI.

Phân quyền

Đã chuyển từ vai trò cứng sang nhóm quyền có danh mục khoá quyền — khảo sát đếm được 53 khoá đang dùng, trải trên 18 miền nghiệp vụ.

Cấu hình động

Bảng khoá–giá trị JSON với hơn 50 khoá: trọng số chấm điểm, ngưỡng quá tải, quy tắc chia lead, bộ tiêu chí KPI, cấu hình AI, cấu hình thư.

Hạn chế cần loại bỏ khi mang sang

Toàn bộ hệ thống này được thiết kế như lớp phụ trợ đặt bên cạnh Bitrix24: nội dung công việc và lead luôn do Bitrix24 làm chủ và bị ghi đè mỗi lần đồng bộ; không có giao diện làm việc trực tiếp; không có ứng dụng máy tính hay di động. Phần mang sang là logic nghiệp vụ, không phải giả định kiến trúc.

report-web4s — công cụ chấm KPI viết bằng PHP

Vai trò trong dự án

Tham chiếu cho bộ tiêu chí KPI và mẫu kết xuất Excel mà các đơn vị đã quen dùng.

Trạng thái

Công thức chấm thang 100 điểm cho khối IT Dịch vụ Web đã được chuyển sang xerp-4s. Bản PHP còn giá trị như tài liệu về mẫu kết xuất và các trường hợp biên đã gặp trong thực tế.

Bài học rút ra

Bộ tiêu chí này chỉ đúng cho một khối. Việc phải viết hẳn một công cụ riêng cho một khối chính là bằng chứng cho yêu cầu “mỗi đơn vị một bộ tiêu chí” ở tài liệu 07.

meeting-report — hệ thống biên bản họp

Vai trò trong dự án

Hệ thống độc lập, không nằm trong phạm vi thay thế. Liên quan tới ERP ở một điểm: nó sinh ra đầu việc từ cuộc họp, nên ERP cần một đầu vào nhận đầu việc đó (yêu cầu BR-19, giai đoạn sau).

Công nghệ

Kho mã đơn khối dùng pnpm và Turborepo, chia thành ứng dụng API, web, worker, recorder và các gói dùng chung. ERP kế thừa trực tiếp cấu trúc và chuẩn kỹ thuật này.

wiki-nhanhoa

Thư mục đã tạo nhưng chưa có nội dung. Trong hồ sơ này, wiki được coi là hệ thống tri thức tương lai — nguồn tài liệu cho trợ lý AI trả lời câu hỏi quy trình, và là nơi đặt hướng dẫn sử dụng ERP. Không nằm trong phạm vi v1.

Tài sản mang sang được

Đây là kết quả có giá trị nhất của khảo sát. Bảng dưới liệt kê những gì mang thẳng sang ERP mới được, kèm mức độ phải sửa. Tổng cộng, phần dùng lại được rút ngắn khoảng ba đến bốn tháng so với dựng mới hoàn toàn.

Khoảng trống phải bù

So danh mục chức năng mong muốn với những gì đã có mã, chín khoảng trống dưới đây là phần phải làm mới. Cột công sức phản ánh khối lượng ước lượng, không phải độ ưu tiên nghiệp vụ.

Kết luận khảo sát

Ba lý do dẫn tới lựa chọn này:

• Không viết lại cái đã đúng. Công thức chấm điểm, mô hình xoay vòng lead và mô hình nhóm quyền đã chạy trên dữ liệu thật và có bộ kiểm thử. Viết lại chúng chỉ thêm rủi ro mà không thêm giá trị.
• Không mang theo ràng buộc đã hết hiệu lực. Phần lớn độ phức tạp của xerp-4s sinh ra từ việc nó không được phép làm chủ dữ liệu. Bỏ ràng buộc đó là bỏ được lớp đồng bộ, quy tắc xử lý xung đột và toàn bộ nhóm lỗi đi kèm — ước tính rút được khoảng sáu tuần công việc và ba rủi ro mức nghiêm trọng.
• Đổi lại, phải trả giá ở khâu kiểm chứng. Xây độc lập nghĩa là hệ thống không có dữ liệu vận hành thật để tự chứng minh cho tới ngày cắt chuyển. Bù lại bằng một giai đoạn chạy thử có kiểm soát dài sáu tuần với người dùng thật trên dữ liệu thật đã nhập — chi tiết ở tài liệu 12 và 13. Đây là đánh đổi có ý thức, không phải điểm bị bỏ sót.

Đối chiếu năng lực với Bitrix24

Hệ thống mới phải làm được mọi việc Nhân Hòa đang thực sự dùng ở Bitrix24 trước khi được phép tắt nó. Tài liệu này là danh sách đối chiếu đó — kèm phần trả lời thẳng: bỏ Bitrix24 thì mất gì, được gì, và những gì cố tình không làm.

Bảng đối chiếu năng lực

Cột mức độ dùng bốn nhãn: Vượt làm tốt hơn đáng kể, Bằng đáp ứng ngang mức dùng thực tế, Rút gọn làm ít hơn nhưng đủ dùng cho Nhân Hòa, Không làm chủ động bỏ trong v1.

Nhân sự & cơ cấu tổ chức

Công việc & cộng tác

Khách hàng tiềm năng & bán hàng

Báo cáo, đánh giá & quản trị

Nền tảng & ứng dụng

Ba điểm vượt lên đáng để đầu tư

Phần lớn bảng trên là ngang bằng hoặc rút gọn. Toàn bộ luận điểm đầu tư nằm ở ba năng lực dưới đây — đây cũng là ba tài liệu chuyên sâu 06, 07 và 08.

Ba điểm chủ động không làm

Ghi rõ ở đây để tránh kỳ vọng sai. Vì cắt chuyển một lần, ba hạng mục này phải được các đơn vị liên quan chấp nhận bằng văn bản ngay trong tháng 9/2026 — không có cơ hội thương lượng lại sau khi Bitrix24 đã tắt.

1. Tổng đài và ghi âm cuộc gọi

   Đây là hạ tầng viễn thông, không phải bài toán quản trị. Nếu cần, hướng đi là tích hợp với tổng đài chuyên dụng qua giao diện lập trình ở giai đoạn sau, không phải tự dựng.

2. Tài chính, kế toán và tính lương

   Ràng buộc pháp lý và quy định thay đổi thường xuyên. Phần mềm chuyên ngành làm tốt hơn. ERP chỉ cung cấp dữ liệu đầu vào là ngày công và kết quả đánh giá.

3. Trò chuyện và mạng nội bộ

   Nhân Hòa đã có công cụ trao đổi đang dùng ổn định. Dựng thêm một kênh trò chuyện nữa chỉ làm phân mảnh giao tiếp. ERP gửi thông báo sang kênh sẵn có thay vì thay thế nó.

So sánh chi phí sở hữu

So sánh dưới đây mang tính định hướng, chưa phải bài toán tài chính chi tiết. Điểm cần lưu ý là chi phí của hệ thống tự xây dồn vào giai đoạn đầu, còn chi phí của giải pháp đóng gói trải đều và tăng theo số người dùng.

Danh sách phải có trước khi tắt Bitrix24

Vì hệ thống mới xây độc lập và chỉ cắt chuyển một lần, không có cơ hội “thiếu thì bổ sung sau”. Bảng đối chiếu ở trên được rút thành một danh sách kiểm tra bắt buộc: mọi dòng phải ở trạng thái đạt thì mới được phép ấn nút tắt.

Cách rời khỏi Bitrix24

  THÁNG 1 → 8        Bitrix24  ██████████████████  chạy bình thường
                     ERP mới   ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  đang xây, chưa ai dùng thật
                                    ↑ chỉ đọc để tham chiếu tính năng

  THÁNG 8 → 9,5      Bitrix24  ██████████████████  vẫn chạy bình thường
                     ERP mới   ░░░░░░░░░░░░░░░░░░  CHẠY THỬ có kiểm soát
                                                   người dùng thật · dữ liệu thật
                                                   trên môi trường tiền vận hành

  CUỐI TUẦN CẮT      Bitrix24  ─── chuyển sang CHỈ ĐỌC ───────────────
  CHUYỂN             ERP mới   ─── nhập dữ liệu lần cuối · kiểm tra ──

  SAU ĐÓ             Bitrix24  ▓▓▓▓  chỉ đọc, giữ 90 ngày làm lưới an toàn
                     ERP mới   ██████████████████  hệ thống duy nhất
                               ↓ sau 90 ngày
                     Bitrix24  ✕ TẮT HẲN

1. Xây kín, không chạm vào hệ thống cũ

   Suốt các giai đoạn phát triển, ERP chỉ đọc Bitrix24 đúng hai lần: một lần cuối tháng 9/2026 để đo khối lượng dữ liệu, và các lần chạy thử công cụ nhập ở giai đoạn 9. Không có kết nối thường trực nào.

2. Chạy thử có kiểm soát

   Sáu tuần trước khi cắt, nhập bản sao dữ liệu thật vào môi trường tiền vận hành và cho người dùng thật làm việc trên đó song song với công việc hằng ngày của họ. Đây không phải vận hành song song — dữ liệu tạo ra trong lúc chạy thử bị bỏ đi; mục đích duy nhất là tìm lỗi và đo phản ứng người dùng.

3. Cắt chuyển trong một cuối tuần

   Chiều thứ Sáu chuyển Bitrix24 sang chỉ đọc. Chạy đợt nhập dữ liệu cuối cùng, đối soát, kiểm tra khói. Sáng thứ Hai toàn bộ nhân sự vào hệ thống mới. Thông báo trước hai tuần, kèm hướng dẫn và đầu mối hỗ trợ.

4. Giữ lưới an toàn 90 ngày

   Bitrix24 ở chế độ chỉ đọc thêm 90 ngày để tra cứu khi nghi ngờ dữ liệu nhập sai. Đây là tra cứu, không phải làm việc — không ai được ghi vào đó nữa.

5. Tắt hẳn và lưu trữ

   Hết 90 ngày, xuất một bản sao lưu toàn bộ theo chính sách lưu trữ dài hạn, rồi ngừng dịch vụ. Gỡ công cụ di trú và các trường ma_nguon_cu khỏi ERP.

Điều kiện quay lui

Vì sao chọn cách này

Yêu cầu nghiệp vụ & phi chức năng

Tập hợp đầy đủ các yêu cầu mà hệ thống phải đáp ứng, viết ở mức có thể kiểm chứng được. Mỗi yêu cầu có mã riêng để tài liệu đặc tả, kế hoạch kiểm thử và biên bản nghiệm thu trỏ ngược về.

Vai trò người dùng

Bảy vai trò dưới đây là các nhóm quyền mặc định của hệ thống. Một người có thể mang nhiều vai trò; quyền hiệu lực là hợp của các nhóm cộng với phạm vi dữ liệu tính theo vị trí trong cây đơn vị (tài liệu 11).

Yêu cầu nghiệp vụ

Độ ưu tiên theo thang bốn mức: Bắt buộc không có thì hệ thống vô nghĩa, Nên có ảnh hưởng lớn tới giá trị nhưng lùi được, Có thì tốt làm khi còn dư địa, Sau v1 đã xác định nhưng không nằm trong phạm vi hiện tại.

Câu chuyện người dùng tiêu biểu

Danh sách dưới đây không nhằm liệt kê đủ mọi thao tác — đặc tả chi tiết nằm ở tài liệu 05. Đây là các câu chuyện định hình trải nghiệm, dùng làm căn cứ thiết kế giao diện và làm kịch bản nghiệm thu người dùng.

Nhân viên

• Là nhân viên, tôi mở ứng dụng và thấy ngay việc hôm nay của tôi xếp theo mức khẩn, để không phải tự lọc từ một danh sách dài. BR-04
• Là nhân viên, tôi ghi giờ làm cho một việc ngay khi vừa xong, để số liệu khối lượng trong kỳ đánh giá phản ánh đúng công sức bỏ ra. BR-04 BR-12
• Là nhân viên, tôi nộp đơn xin nghỉ trên điện thoại và thấy trạng thái duyệt, để không phải nhắn hỏi từng cấp. BR-10 BR-16
• Là nhân viên, tôi xem lịch trực của mình trong tháng và xin đổi ca với đồng nghiệp, để chủ động sắp xếp việc cá nhân. BR-09
• Là nhân viên, tôi tự khai kỹ năng và mức thành thạo để hệ thống giao đúng loại việc; quản lý xác nhận lại phần tôi khai. BR-02
• Là nhân viên, tôi xem điểm KPI kỳ vừa rồi kèm số liệu tạo ra từng phần điểm, để biết cần cải thiện chỗ nào thay vì chỉ nhận một con số. BR-12

Trưởng nhóm & điều phối

• Là trưởng nhóm, tôi mở hộp duyệt phân công và thấy từng đề xuất kèm điểm và lý do, duyệt hoặc đổi người trong một chạm. BR-05 BR-06
• Là trưởng nhóm, tôi xem bảng tải của nhóm để biết ai đang quá tải trước khi giao thêm việc. BR-05
• Là trưởng nhóm, tôi tạm dừng nhận việc cho một thành viên đang tập trung vào một dự án gấp, và hệ thống tự bỏ qua người đó trong các vòng chia tiếp theo. BR-08
• Là điều phối, tôi thấy danh sách việc chưa có người phụ trách quá ngưỡng thời gian để xử lý tồn đọng trước khi nó thành vấn đề. BR-06
• Là trưởng nhóm, tôi xếp lịch trực cả tháng từ một mẫu lặp rồi chỉnh vài ngày ngoại lệ, thay vì điền thủ công từng ô. BR-09

Kinh doanh

• Là nhân viên kinh doanh, tôi nhận lead ngay khi nó vào hệ thống theo đúng lượt của mình, và biết được vì sao lead đó đến tay tôi. BR-08
• Là nhân viên kinh doanh, tôi báo một lead là dữ liệu không dùng được và được ưu tiên nhận lead mới, để không bị thiệt vì rủi ro nguồn dữ liệu. BR-08
• Là trưởng phòng kinh doanh, tôi khai báo quy tắc chia lead cho team mình: nhận nguồn nào, thứ tự ai trước, ai nhận trọng số bao nhiêu. BR-08
• Là trưởng phòng kinh doanh, tôi theo dõi tiến độ chỉ tiêu doanh số của từng nhân sự trong kỳ. BR-20

Quản lý & nhân sự

• Là trưởng phòng ban, tôi khai báo bộ tiêu chí đánh giá riêng cho khối mình: chọn chỉ số, đặt trọng số, đặt ngưỡng xếp loại — và áp dụng từ kỳ tiếp theo. BR-11
• Là trưởng phòng ban, tôi mở một kỳ đánh giá, hệ thống đã điền sẵn phần điểm tính được, tôi chỉ chấm phần nhận định và viết nhận xét. BR-12
• Là nhân sự, tôi kết xuất kết quả đánh giá toàn công ty ra Excel theo mẫu đã dùng lâu nay. BR-13
• Là nhân sự, tôi xem quỹ phép còn lại của từng người và lịch sử nghỉ trong năm. BR-10

Ban điều hành

• Là thành viên ban điều hành, tôi hỏi trợ lý bằng tiếng Việt: “tháng trước khối kỹ thuật xử lý bao nhiêu việc quá hạn, ai tải nặng nhất” và nhận câu trả lời kèm số liệu nguồn. BR-14
• Là thành viên ban điều hành, tôi tin rằng trợ lý không trả lời quá phạm vi quyền của người hỏi, và kiểm tra được điều đó bằng nhật ký truy vấn. BR-15
• Là thành viên ban điều hành, tôi xem bảng điều khiển tổng hợp cập nhật theo thời gian thực thay vì chờ báo cáo cuối tháng. BR-13

Yêu cầu phi chức năng

Mỗi yêu cầu dưới đây có một chỉ tiêu đo được và một cách đo. Yêu cầu phi chức năng không có cách đo thì không được coi là yêu cầu.

Ràng buộc & giả định

Ràng buộc

• Hệ thống cũ vẫn chạy bình thường trong suốt thời gian xây. ERP không được chạm vào nó dưới bất kỳ hình thức nào ngoài việc đọc để trích xuất dữ liệu ở đợt di trú. Hệ quả: hệ thống mới không có dữ liệu vận hành thật để kiểm chứng cho tới giai đoạn chạy thử, nên giai đoạn đó phải được thiết kế nghiêm túc chứ không phải làm cho có.
• Trích xuất dữ liệu từ hệ thống cũ dùng bí mật nằm trong đường dẫn. Bí mật này phải được đối xử như mật khẩu: chỉ nằm trong kho bí mật, không bao giờ trả về giao diện. Công cụ di trú là nơi duy nhất trong hệ thống được phép dùng nó, và bị gỡ bỏ sau khi cắt chuyển.
• Dữ liệu cá nhân của người lao động chịu điều chỉnh của Nghị định 13/2023/NĐ-CP. Kéo theo yêu cầu về mục đích xử lý, thời hạn lưu trữ, quyền truy cập và nhật ký.
• Cắt chuyển gói gọn trong một cuối tuần. Nhân viên nghỉ chiều thứ Sáu trên hệ thống cũ và sáng thứ Hai vào hệ thống mới. Không chấp nhận phương án bắt người dùng nhập liệu vào hai nơi trong bất kỳ khoảng thời gian nào.
• Đội phát triển đồng thời duy trì các hệ thống hiện có. Kế hoạch nguồn lực ở tài liệu 12 phải trừ phần công sức duy trì này.

Giả định

• Quy mô nhân sự dùng hệ thống trong 24 tháng tới nằm trong khoảng 150–300 người.
• Số đơn vị cần bộ tiêu chí đánh giá riêng nằm trong khoảng 5–12.
• Nhân sự đã quen thao tác trên hệ thống nội bộ, nên chi phí đào tạo tập trung vào cái mới (phân công tự động, đánh giá, trợ lý) chứ không phải kiến thức cơ bản.
• Hạ tầng máy chủ do Nhân Hòa tự vận hành, không phụ thuộc nhà cung cấp đám mây bên ngoài cho dữ liệu nghiệp vụ.
• Mô hình AI được gọi qua giao diện lập trình bên ngoài; dữ liệu gửi đi là kết quả truy vấn đã lọc quyền chứ không phải bản sao cơ sở dữ liệu.

Tiêu chí chấp nhận tổng thể

Hệ thống được coi là đạt khi đồng thời thoả sáu điều kiện dưới đây. Tiêu chí nghiệm thu chi tiết theo từng giai đoạn nằm ở tài liệu 13.

Đặc tả chức năng theo phân hệ

Mô tả chi tiết mười hai phân hệ của hệ thống: mục tiêu, màn hình, quy tắc nghiệp vụ, dữ liệu, quyền và tiêu chí nghiệm thu. Ba phân hệ có độ phức tạp cao — phân công, đánh giá và trợ lý AI — được tách riêng sang các tài liệu 06, 07 và 08.

Bản đồ phân hệ

M01 · Nhân sự & hồ sơ

M02 · Kỹ năng & ma trận năng lực

M03 · Phòng ban & cây đơn vị

M04 · Nhóm làm việc & dự án

M05 · Lịch trực & đơn xin nghỉ

M06 · Quản lý công việc

M07 · Phân công công việc tự động

Đặc tả đầy đủ nằm ở tài liệu 06. Tóm tắt phạm vi: engine sinh đề xuất người phụ trách cho công việc mới hoặc công việc đang nằm ở tài khoản gom, chấm điểm theo kỹ năng khớp, tải hiện tại, áp lực hạn và tín hiệu AI; hộp duyệt cho quản lý; ghi nhận mọi quyết định làm dữ liệu hiệu chỉnh.

M08 · Quản lý lead

M09 · Chia lead tự động

Đặc tả đầy đủ nằm ở tài liệu 06. Tóm tắt phạm vi: định tuyến lead tới đơn vị phù hợp theo quy tắc nhiều chiều, xoay vòng trong đơn vị theo vị trí và trọng số, hàng ưu tiên cho các trường hợp bù lượt và báo dữ liệu rác, cùng toàn bộ cấu hình theo từng team.

M10 · Báo cáo kỳ & đánh giá KPI

Đặc tả đầy đủ nằm ở tài liệu 07. Tóm tắt phạm vi: thư viện chỉ số dùng chung, bộ tiêu chí khai báo riêng cho từng đơn vị, quy trình mở kỳ, thu thập tự động, chấm, chốt và kết xuất.

M11 · Trợ lý AI

Đặc tả đầy đủ nằm ở tài liệu 08. Tóm tắt phạm vi: cổng hỏi đáp tiếng Việt, bộ công cụ truy vấn bị ràng buộc phạm vi quyền, cơ chế chống rò rỉ dữ liệu, nhật ký kiểm toán và định tuyến mô hình theo độ khó câu hỏi.

M12 · Quản trị hệ thống & cấu hình

Engine phân công tự động

Đặc tả cơ chế đưa công việc và lead đến đúng người: định nghĩa tải, công thức chấm điểm, luồng định tuyến và xoay vòng, các trường hợp biên bắt buộc xử lý, và toàn bộ tham số khai báo được cho từng đơn vị.

Nguyên tắc vận hành

  việc mới ────▶ HÀNG CHỜ ────▶ ENGINE ────▶ ĐỀ XUẤT ────▶ HỘP DUYỆT
                    │              │          người        ├─ Duyệt      ─▶ gán
                    │              │          điểm         ├─ Đổi người  ─▶ gán + ghi nhận lệch
                    │              │          lý do        └─ Bỏ qua     ─▶ trả lại hàng chờ
                    │              │
                    │              └── đọc: kỹ năng · tải · hạn · ưu tiên · tín hiệu AI
                    │
                    └── lọc: đang mở · chưa có người thật · đơn vị nhận việc

Bốn nguyên tắc ràng buộc mọi quyết định thiết kế trong tài liệu này:

• Luôn có lý do đọc được. Mỗi đề xuất kèm câu giải thích bằng tiếng Việt liệt kê các thành phần điểm. Một đề xuất không giải thích được thì không được hiển thị.
• Luôn chạy được khi tắt AI. Tín hiệu AI là một thành phần cộng thêm với trọng số riêng. Đặt trọng số đó về 0, engine vẫn hoạt động đầy đủ bằng quy tắc.
• Công bằng có thể đo. Mục tiêu không phải là chia đều tuyệt đối mà là giữ độ lệch tải trong ngưỡng. Độ lệch được đo và hiển thị, không phải giả định.
• Không giành việc đã có chủ. Việc đã có người phụ trách thật thì engine không đề xuất lại, trừ khi có yêu cầu phân công lại tường minh. Quyết định của con người luôn thắng quyết định của engine.

Ba định nghĩa nền

Ba khái niệm dưới đây phải được chốt trước mọi công thức, vì mọi tranh cãi về “engine chia sai” trong thực tế đều quy về việc hai bên hiểu khác nhau ba khái niệm này.

Việc cần phân công

Một công việc được đưa vào hàng chờ phân công khi thoả đồng thời ba điều kiện:

1. Trạng thái thuộc tập đang mở (khai báo trong cấu hình).
2. Người phụ trách hiện tại là tài khoản gom — nghĩa là chưa có người thật. Trong ERP, tài khoản gom mặc định là trưởng đơn vị tiếp nhận; với lead, danh sách tài khoản gom khai báo riêng.
3. Đơn vị tiếp nhận có cờ nhận công việc (hoặc nhận lead) đang bật.

Việc đã gán cho một người thật không quay lại hàng chờ. Đây là quy tắc chống vòng lặp quan trọng nhất: nếu bỏ qua nó, engine sẽ liên tục đề xuất lại những việc quản lý vừa gán tay.

Đang mở

Tập trạng thái coi là đang mở là dữ liệu cấu hình, không viết cứng trong mã. Mặc định gồm mọi trạng thái chưa kết thúc: Mới, Đang làm, Chờ kiểm tra, Tạm hoãn. Không gồm Hoàn thành và Huỷ. Lý do để cấu hình: các đơn vị dùng vòng đời khác nhau, và tập này thay đổi khi quy trình thay đổi.

Tải

Tải không phải là số việc. Tải là số việc đang mở cộng với áp lực từ các hạn sắp tới, vì một người đang giữ ba việc đến hạn ngày mai chịu áp lực lớn hơn người giữ năm việc đến hạn tháng sau.

tải(người) = số_việc_đang_mở
           + Σ  trọng_số_áp_lực(việc)   với mỗi việc đang mở

trọng_số_áp_lực(việc) =
    2,0   nếu đã quá hạn
    1,0   nếu còn ≤ 1 ngày tới hạn
    0,5   nếu còn ≤ 3 ngày tới hạn
    0,0   nếu còn > 3 ngày tới hạn hoặc không có hạn

Các mốc ngày và hệ số trên là giá trị mặc định, khai báo được trong cấu hình duePressure. Người có tải vượt ngưỡng quá tải bị loại khỏi vòng phân công; ngưỡng đặt chung cho toàn hệ thống và ghi đè được cho từng người.

Phân công công việc — công thức chấm điểm

Với mỗi công việc trong hàng chờ, engine lập danh sách ứng viên đủ điều kiện rồi chấm điểm từng người. Người điểm cao nhất được đề xuất; hoà điểm thì ưu tiên người tải thấp hơn.

Điều kiện lọc ứng viên

1. Thuộc ít nhất một đơn vị có cờ nhận công việc và đơn vị đó phù hợp với bối cảnh của việc (nhóm làm việc, phòng ban).
2. Đang hoạt động và ở trạng thái sẵn sàng nhận việc.
3. Không nằm trong danh sách tạm dừng nhận việc của đơn vị.
4. Không có đơn nghỉ đã duyệt phủ ngày hiện tại.
5. Tải chưa vượt ngưỡng quá tải.

Công thức

điểm = w_kỹnăng × điểm_kỹ_năng
     + w_tải     × thành_phần_tải
     + w_ưutiên  × thành_phần_ưu_tiên
     + w_ai      × tín_hiệu_ai

điểm_kỹ_năng    = trung bình( mức_thành_thạo / 5 ) trên các kỹ năng việc yêu cầu
                  (bằng 0 nếu việc không khai báo kỹ năng yêu cầu)

thành_phần_tải  = 1 / (1 + tải)          → tải nhẹ cho điểm cao, giảm dần

thành_phần_ưu_tiên = 1,0 nếu ưu tiên Cao
                     0,6 nếu ưu tiên Thường
                     0,3 nếu ưu tiên Thấp

tín_hiệu_ai     ∈ [0; 1]  — độ phù hợp do mô hình ước lượng từ nội dung việc
                  (bằng 0 khi tắt AI)

Vai trò của AI trong phân công công việc

Mô hình đọc tiêu đề và mô tả để trả về một cấu trúc gồm: danh sách kỹ năng suy ra được, ước lượng độ phức tạp, và mức khẩn cảm nhận từ ngôn ngữ. Kết quả được quy về một giá trị trong khoảng 0 đến 1 cho từng ứng viên.

• Khi tắt AI, hệ thống dùng so khớp từ khoá giữa mô tả việc và tên kỹ năng trong danh mục. Kém tinh tế hơn nhưng đủ dùng.
• Mọi lần gọi mô hình đều ghi nhật ký số token để kiểm soát chi phí.
• Mô hình phải trả về dữ liệu có cấu trúc kèm lý do; kết quả không đúng cấu trúc bị bỏ qua và engine chạy tiếp bằng quy tắc.

Ví dụ chấm điểm một công việc

Công việc: “Cài chứng chỉ SSL cho tên miền khách hàng, khách báo lỗi trình duyệt cảnh báo” — ưu tiên Cao, kỹ năng yêu cầu: SSL và Hosting. Trọng số dùng giá trị mặc định.

Đề xuất là Trần B, hơn Nguyễn A đúng 0,007 điểm. Lý do hiển thị cho quản lý:

Ví dụ này minh hoạ đúng hành vi mong muốn: engine không mù quáng chọn người giỏi nhất, mà cân bằng giữa năng lực và khả năng thực sự nhận thêm việc. Nếu tổ chức muốn nghiêng hẳn về năng lực, chỉ cần nâng weights.skill lên 0,60 và hạ weights.load xuống 0,15 — khi đó Nguyễn A thắng với 0,690 so với 0,630.

Chia lead — định tuyến và xoay vòng

Lead khác công việc ở chỗ nội dung thường ngắn và ít cần hiểu sâu, nhưng tính công bằng lại quan trọng hơn nhiều vì lead gắn trực tiếp với thu nhập của nhân viên kinh doanh. Vì vậy cơ chế là xoay vòng có quy tắc chứ không phải chấm điểm.

  lead mới
     │
     ▼
  ① ĐỊNH TUYẾN ─── đối chiếu quy tắc: khu vực × nguồn × loại lead
     │             ↳ ra danh sách đơn vị đủ điều kiện + trọng số đơn vị
     ▼
  ② HÀNG ƯU TIÊN ── có ai đang chờ lượt ưu tiên trong đơn vị này?
     │              ├─ CÓ  → cấp lead cho người đó, kết thúc
     │              └─ KHÔNG → sang bước ③
     ▼
  ③ XOAY VÒNG ──── trong đơn vị: theo thứ tự vị trí đã khai báo,
     │              bỏ qua người tạm dừng / nghỉ / quá tải,
     │              áp trọng số cá nhân
     ▼
  ④ GHI NHẬN ───── lưu: ai nhận, đơn vị nào, quy tắc nào khớp,
                   vị trí thứ mấy, vòng thứ mấy, lý do

Bước ① — Định tuyến theo quy tắc

Một quy tắc định tuyến gồm năm phần: nhãn, tập khu vực, tập nguồn hoặc loại lead, danh sách đơn vị nhận kèm trọng số, và cờ bật/tắt. Quy tắc được duyệt theo thứ tự; quy tắc đầu tiên khớp sẽ thắng.

Quy tắc mặc định ở cuối danh sách là bắt buộc: nó bảo đảm không lead nào rơi ra ngoài mọi quy tắc và bị bỏ quên.

Bước ② — Hàng ưu tiên

Hàng ưu tiên xử lý hai tình huống mà xoay vòng thuần không giải quyết được:

Giãn cách giữa các lượt bù là chi tiết quan trọng: nếu trả hết nợ một lúc, người đó nhận dồn năm lead trong một phút và không kịp chăm sóc lead nào. Mặc định giãn cách là 5 phút mỗi lượt.

Bước ③ — Xoay vòng theo vị trí và trọng số

Mỗi đơn vị khai báo thứ tự vị trí nhận lead (danh sách người theo thứ tự) và trọng số nhận cho từng người. Con trỏ xoay vòng lưu bền vững theo đơn vị, nên khởi động lại hệ thống không làm lệch vòng.

• Trọng số 1,0 nghĩa là nhận đủ mỗi vòng một lead. Trọng số 0,5 nghĩa là hai vòng mới nhận một lead — dùng cho nhân viên mới hoặc nhân viên kiêm nhiệm.
• Người không có trong danh sách vị trí được xếp cuối theo thứ tự tên, với trọng số 1,0.
• Người bị bỏ qua vì tạm dừng, nghỉ hoặc quá tải không làm dịch chuyển con trỏ — vòng tiếp theo họ vẫn đứng đúng chỗ cũ.

Ví dụ chia lead một vòng

Đơn vị Kinh doanh HN có bốn người. Thứ tự vị trí: Nguyễn A → Trần B → Lê C → Phạm D. Trọng số: A 1,0 · B 1,0 · C 0,5 · D 1,0. Lê C đang tạm dừng nhận lead từ lead thứ tư. Phạm D có một lượt bù đang chờ.

Sau tám lead: A nhận 2, B nhận 2, C nhận 1, D nhận 3 (trong đó 1 là lượt bù). Tỉ lệ khớp với trọng số đã khai báo. Nếu Lê C chuyển sang tạm dừng hoàn toàn từ lead thứ 9, con trỏ vẫn giữ vị trí của C và những lượt bị bỏ sẽ được ghi nợ để bù khi C quay lại.

Trường hợp biên bắt buộc xử lý

Bảng cấu hình engine

Đo lường & hiệu chỉnh

Engine phải tự chứng minh nó đang hoạt động tốt. Bốn chỉ số dưới đây hiển thị trên bảng điều khiển vận hành và được xem xét hằng tháng.

Quy trình hiệu chỉnh trọng số

1. Thu thập lệch

   Mỗi lần quản lý đổi người, hệ thống lưu người được đề xuất, người thực nhận và chênh lệch điểm giữa hai người. Đây là dữ liệu duy nhất cần để hiệu chỉnh.

2. Xem xét hằng tháng theo đơn vị

   Nếu một đơn vị có tỉ lệ đổi người vượt 20%, xem xét mẫu lệch: đổi sang người khớp kỹ năng hơn thì tăng trọng số kỹ năng; đổi sang người rảnh hơn thì tăng trọng số tải.

3. Thử trên bản sao trước khi áp

   Chạy lại engine với trọng số mới trên dữ liệu 30 ngày gần nhất và so tỉ lệ trùng khớp với quyết định thực tế của quản lý. Chỉ áp khi tỉ lệ trùng tăng.

4. Bật tự động duyệt theo từng đơn vị

   Khi một đơn vị giữ tỉ lệ duyệt không đổi người trên 90% liên tục ba tháng, bật chế độ gán thẳng cho các đề xuất vượt ngưỡng điểm, giữ hộp duyệt cho phần còn lại.

Khung KPI & báo cáo theo team

Mỗi đơn vị ở Nhân Hòa đo hiệu quả bằng một thước khác nhau, và đó là điều đúng đắn. Tài liệu này đặc tả cấu trúc cho phép khai báo thước đo riêng của từng đơn vị như dữ liệu, đồng thời giữ được khả năng so sánh ở cấp công ty.

Vấn đề cần giải

Hệ thống hiện tại có đúng một bộ tiêu chí, xây cho khối IT Dịch vụ Web, thang 100 điểm. Bộ này đo tỉ lệ đúng hạn, mức độ hài lòng, lỗi nội dung, khối lượng và tỉ số giờ thực tế trên giờ ước lượng. Nó hoạt động tốt cho khối đó.

Nó không hoạt động cho các khối khác, vì lý do rất đơn giản:

• Nhân viên kinh doanh không có “tỉ lệ đúng hạn công việc” theo nghĩa có ý nghĩa. Thứ họ được đo là doanh số, tỉ lệ chuyển đổi và tốc độ chạm khách hàng.
• Nhân viên hạ tầng có thể cả tháng không đóng việc nào đáng kể nhưng giữ hệ thống chạy liên tục. Thước đo của họ là mức sẵn sàng dịch vụ, thời gian khôi phục sự cố và tuân thủ cam kết dịch vụ.
• Nhân viên hỗ trợ khách hàng được đo bằng thời gian phản hồi đầu tiên và tỉ lệ giải quyết ngay ở lần chạm đầu, chứ không phải số giờ ghi nhận.

Cách xử lý hiện nay là viết công cụ riêng cho từng khối, hoặc dùng chung bộ tiêu chí rồi bù trừ bằng nhận định của quản lý. Cách thứ nhất tốn kém; cách thứ hai làm điểm số mất ý nghĩa.

Mô hình ba tầng

  ┌─ TẦNG 1 ─ THƯ VIỆN CHỈ SỐ ────────────────────────────────────────┐
  │  Định nghĩa và công thức tính, dùng chung toàn công ty.           │
  │  MT-01 tỉ lệ đúng hạn · MT-09 tỉ lệ chuyển đổi · MT-15 mức sẵn    │
  │  sàng dịch vụ · … · mỗi chỉ số có nguồn dữ liệu và cách chuẩn hoá │
  └──────────────────────────┬────────────────────────────────────────┘
                             │  chọn + đặt trọng số + đặt ngưỡng
  ┌─ TẦNG 2 ─ BỘ TIÊU CHÍ ───▼────────────────────────────────────────┐
  │  Gắn với MỘT đơn vị và có hiệu lực từ MỘT kỳ.                     │
  │  Nhóm → Mục → Tiêu chí (điểm tối đa, tự chấm hay chấm tay)        │
  │  Ví dụ: "KPI Kinh doanh 2027" · "KPI Hạ tầng 2027"                │
  └──────────────────────────┬────────────────────────────────────────┘
                             │  áp cho một kỳ cụ thể
  ┌─ TẦNG 3 ─ KỲ ĐÁNH GIÁ ───▼────────────────────────────────────────┐
  │  Tuần / tháng / quý × đơn vị hoặc nhóm dự án.                     │
  │  Chứa: danh sách nhân sự, số liệu đã chốt, điểm từng người,       │
  │  nhận xét, xếp loại, bản chụp bộ tiêu chí tại thời điểm chốt      │
  └───────────────────────────────────────────────────────────────────┘

Tách ba tầng giải quyết ba vấn đề khác nhau:

• Tầng 1 giữ tính so sánh được. “Tỉ lệ đúng hạn” chỉ có một định nghĩa trong toàn công ty. Hai đơn vị dùng cùng chỉ số thì con số của họ so sánh được, kể cả khi trọng số khác nhau.
• Tầng 2 giữ tính đặc thù. Đơn vị toàn quyền chọn đo gì và nặng nhẹ ra sao.
• Tầng 3 giữ tính bất biến của lịch sử. Kỳ đã chốt lưu bản chụp bộ tiêu chí, nên đổi tiêu chí năm nay không làm thay đổi điểm năm ngoái.

Thư viện chỉ số

Hai mươi hai chỉ số dưới đây là bộ khởi đầu, đủ phủ các khối hiện có. Thư viện mở rộng được qua giao diện quản trị. Cột chuẩn hoá cho biết cách quy giá trị thô về thang điểm.

Nhóm công việc

Nhóm khách hàng tiềm năng & bán hàng

Nhóm vận hành & dịch vụ

Nhóm kỷ luật & đóng góp

Cấu trúc một bộ tiêu chí

Bộ tiêu chí là một cây ba cấp: nhóm → mục → tiêu chí. Điểm tối đa của mục là tổng điểm tối đa của các tiêu chí trong mục, tương tự với nhóm.

Ba nguồn điểm của một tiêu chí

Ba bộ tiêu chí mẫu

Ba bộ dưới đây minh hoạ mức độ khác biệt mà cấu trúc phải chịu được. Cả ba đều dùng thang 100 điểm để so sánh được ở cấp công ty, nhưng thành phần hoàn toàn khác nhau.

Bộ A · Khối kỹ thuật dịch vụ web

Kế thừa bộ tiêu chí đang dùng, giữ nguyên công thức để kết quả liên tục với lịch sử.

Bộ B · Khối kinh doanh

Bộ C · Khối hạ tầng & vận hành

Quy trình một kỳ đánh giá

1. Mở kỳ

   Chọn loại kỳ (tuần, tháng, quý), phạm vi (đơn vị hoặc nhóm dự án) và khoảng thời gian. Hệ thống sinh nhãn kỳ tự động và nạp bộ tiêu chí đang hiệu lực của đơn vị. Danh sách nhân sự được điền sẵn từ thành viên đơn vị, cho phép loại trừ người không thuộc phạm vi đánh giá kỳ này.

2. Thu thập tự động

   Hệ thống chạy toàn bộ chỉ số của bộ tiêu chí trên dữ liệu trong khoảng thời gian kỳ và điền điểm cho các tiêu chí tự chấm. Mỗi con số kèm đường dẫn tới danh sách bản ghi tạo ra nó.

3. Nhân sự tự nhìn lại

   Trước khi quản lý chấm, mỗi người xem số liệu của mình và có quyền ghi phản hồi: bổ sung bối cảnh, chỉ ra số liệu sai. Bước này là tuỳ chọn theo cấu hình đơn vị, nhưng khuyến nghị bật vì nó bắt được phần lớn lỗi dữ liệu trước khi thành tranh cãi.

4. Quản lý chấm

   Quản lý điền các tiêu chí chấm tay, sửa các tiêu chí tự chấm nếu cần (bắt buộc kèm lý do), viết nhận xét. Bảng chấm hiển thị đồng thời số liệu nguồn và phản hồi của nhân sự.

5. Duyệt

   Trưởng phòng ban xem toàn bộ kỳ, đối chiếu phân bố điểm giữa các nhóm trong khối, yêu cầu chấm lại nếu thấy lệch chuẩn bất thường.

6. Chốt kỳ

   Khoá số liệu, lưu bản chụp bộ tiêu chí, tính xếp loại và mức thưởng theo ngưỡng. Sau khi chốt, số liệu không thay đổi kể cả khi dữ liệu gốc thay đổi.

7. Công bố & kết xuất

   Nhân sự xem được điểm và nhận xét của mình. Kết xuất Excel hoặc PDF theo mẫu cho các mục đích ngoài hệ thống.

Xếp loại & mức thưởng

Ngưỡng xếp loại khai báo theo từng đơn vị, vì phân bố điểm tự nhiên của các bộ tiêu chí không giống nhau. Bảng dưới là giá trị mặc định đề xuất.

Bảo đảm công bằng giữa các đơn vị

Cho phép mỗi đơn vị tự đặt thước đo mở ra một rủi ro rõ ràng: đơn vị đặt tiêu chí dễ sẽ có điểm cao hơn. Bốn cơ chế dưới đây kiểm soát rủi ro đó mà không lấy lại quyền tự chủ của đơn vị.

Báo cáo & kết xuất

Các loại báo cáo

Kết xuất

• Excel theo mẫu đang dùng, để bảo đảm liên tục với thói quen hiện tại của các đơn vị. Mẫu khai báo được, không viết cứng.
• PDF cho bản chốt cần lưu trữ hoặc gửi ra ngoài hệ thống.
• Giao diện lập trình cho các hệ thống khác lấy dữ liệu điểm đã chốt, chịu cùng lớp kiểm soát quyền.

Vai trò của AI trong báo cáo

AI tham gia ở ba chỗ, tất cả đều ở vị trí gợi ý, không quyết định:

• Soạn nháp báo cáo cuối ngày từ hoạt động thực tế của nhân sự trong ngày. Người dùng sửa và xác nhận trước khi nộp.
• Tóm tắt kỳ — viết đoạn nhận xét tổng quan cho một kỳ dựa trên số liệu đã chốt, để quản lý sửa lại thay vì viết từ đầu.
• Phát hiện điểm bất thường — chỉ ra những trường hợp số liệu lệch mạnh so với kỳ trước để người chấm chú ý, không tự điều chỉnh điểm.

Nhận xét do AI sinh ra luôn được đánh dấu là nháp cho tới khi người chấm xác nhận, và bản đã xác nhận lưu lại nội dung cuối cùng chứ không lưu bản gốc của mô hình.

Trợ lý AI & kiểm soát truy xuất

Một trợ lý trả lời được mọi câu hỏi về dữ liệu nội bộ chỉ có giá trị nếu tổ chức tin rằng nó không trả lời quá phạm vi quyền của người hỏi. Tài liệu này đặc tả kiến trúc bảo đảm điều đó ở tầng dữ liệu, không phải ở tầng câu lệnh.

Nguyên tắc số một

Cách diễn đạt khác của cùng nguyên tắc: trợ lý không được biết nhiều hơn thứ người dùng tự mở màn hình ra xem được. Nếu một câu trả lời chứa thông tin mà người hỏi không thể tự tra cứu trong giao diện, đó là một lỗi bảo mật, không phải một tính năng.

Kiến trúc năm lớp

  Người dùng hỏi bằng tiếng Việt
        │
        ▼
  ① CỔNG HỎI ĐÁP ────────────── xác thực phiên, giới hạn tần suất,
        │                        lọc nội dung độc hại
        ▼
  ② BỘ ĐỊNH PHẠM VI ─────────── từ danh tính → tập khoá quyền
        │                        + tập đơn vị nhìn thấy được
        │                        + tập nhân sự nhìn thấy được
        │                        (tính một lần, không nhận từ mô hình)
        ▼
  ③ MÔ HÌNH + BỘ CÔNG CỤ ────── mô hình CHỌN công cụ và tham số,
        │                        nhưng phạm vi bị TIÊM CỐ ĐỊNH ở tầng
        │                        thực thi, không lấy từ tham số mô hình
        ▼
  ④ TỔNG HỢP CÂU TRẢ LỜI ────── diễn giải kết quả, dẫn nguồn số liệu,
        │                        từ chối khi không đủ quyền
        ▼
  ⑤ NHẬT KÝ KIỂM TOÁN ───────── ai hỏi gì, gọi công cụ nào, chạm dữ liệu
                                 nào, trả về bao nhiêu bản ghi, chi phí

Lớp ② — Bộ định phạm vi

Đây là lớp quan trọng nhất. Với mỗi phiên hỏi đáp, hệ thống tính một lần và giữ nguyên trong suốt phiên:

Lớp ③ — Tiêm phạm vi ở tầng thực thi

Mô hình được mô tả các công cụ với tham số nghiệp vụ (khoảng thời gian, đơn vị, trạng thái). Nó không có tham số nào để chỉ định người hỏi hay phạm vi. Khi tầng thực thi nhận lời gọi công cụ, nó ghép phạm vi đã tính ở lớp ② vào truy vấn:

// mô hình gọi:
đếm_công_việc({ khoảng: "tháng trước", trạng_thái: "quá hạn", đơn_vị: "Hạ tầng" })

// tầng thực thi chạy:
SELECT ... FROM công_việc
WHERE khoảng thời gian ∈ (tháng trước)
  AND trạng thái ∈ (quá hạn)
  AND đơn_vị_id = (giải nghĩa "Hạ tầng")
  AND đơn_vị_id ∈ ⟨tập đơn vị nhìn thấy của phiên⟩   ← tiêm cố định
  AND người_phụ_trách ∈ ⟨tập nhân sự nhìn thấy⟩       ← tiêm cố định

Nếu đơn vị người dùng yêu cầu nằm ngoài tập nhìn thấy, truy vấn không trả về tập rỗng — nó trả về một mã từ chối rõ ràng, để trợ lý nói “bạn không có quyền xem dữ liệu của đơn vị này” thay vì nói “không có dữ liệu”. Phân biệt này quan trọng: một câu trả lời “không có dữ liệu” cũng là một rò rỉ thông tin, vì nó khẳng định đơn vị đó tồn tại và đang rỗng.

Vì sao không nhúng toàn bộ dữ liệu vào một kho vector

Cách làm phổ biến cho trợ lý dữ liệu nội bộ là chuyển toàn bộ dữ liệu thành vector rồi tìm kiếm theo ngữ nghĩa. Cách đó không phù hợp với bài toán này, vì ba lý do:

Bộ công cụ truy vấn

Mỗi công cụ tương ứng với một loại câu hỏi và một khoá quyền. Không có khoá quyền tương ứng thì công cụ không được nạp vào phiên — mô hình thậm chí không biết công cụ đó tồn tại.

Ràng buộc kỹ thuật của mọi công cụ

• Chỉ thao tác đọc. Không công cụ nào ghi dữ liệu trong phiên bản này (xem lộ trình cuối tài liệu).
• Có trần số bản ghi trả về (mặc định 200). Vượt trần thì trả tóm tắt kèm gợi ý thu hẹp câu hỏi, không trả toàn bộ.
• Có sàn ẩn danh: kết quả tổng hợp tính trên dưới 5 bản ghi bị từ chối, tránh suy ngược về cá nhân.
• Trả về dữ liệu có cấu trúc, không trả về văn bản tự do lấy nguyên từ cơ sở dữ liệu — giảm bề mặt tấn công tiêm lệnh qua nội dung.
• Mỗi lần gọi ghi một dòng nhật ký kiểm toán, kể cả lần gọi bị từ chối vì thiếu quyền.

Bảy cơ chế chống rò rỉ

1. Tiêm phạm vi bắt buộc

   Phạm vi không phải tham số mà mô hình điền, mà là điều kiện tầng thực thi ghép vào mọi truy vấn. Không có đường nào để lời nhắc thay đổi nó.

2. Từ chối mặc định

   Công cụ không được khai báo tường minh cho một khoá quyền thì không tồn tại trong phiên. Trường không nằm trong danh sách cho phép thì không được trả về. Mọi thứ không được phép rõ ràng đều bị chặn.

3. Che trường nhạy cảm

   Danh sách trường nhạy cảm khai báo trong cấu hình. Chúng bị loại bỏ khỏi kết quả trước khi dữ liệu rời khỏi tầng truy vấn, nên không bao giờ nằm trong ngữ cảnh gửi tới mô hình.

4. Sàn ẩn danh cho số liệu tổng hợp

   Chặn kiểu tấn công gộp: hỏi “trung bình điểm của nhóm 6 người” rồi hỏi “trung bình của 5 người trừ anh A” để suy ra điểm anh A. Kết quả tính trên dưới ngưỡng bản ghi bị từ chối.

5. Chống tiêm lệnh qua dữ liệu

   Nội dung do người dùng nhập (mô tả việc, bình luận, tên khách hàng) có thể chứa câu lệnh giả dạng. Toàn bộ dữ liệu trả về từ công cụ được đánh dấu rõ là dữ liệu, không phải chỉ dẫn, và trợ lý được hướng dẫn tường minh không thực hiện chỉ dẫn xuất hiện bên trong dữ liệu.

6. Giới hạn tần suất và hạn mức

   Mỗi người có trần số câu hỏi mỗi giờ và trần chi phí mỗi tháng. Chặn cả việc lạm dụng lẫn việc dò dữ liệu bằng cách hỏi hàng loạt câu hỏi hẹp.

7. Nhật ký kiểm toán đầy đủ

   Mỗi phiên lưu: câu hỏi, các công cụ đã gọi kèm tham số, số bản ghi trả về, câu trả lời cuối, số token và chi phí. Nhật ký này là bằng chứng để trả lời câu hỏi “trợ lý đã đọc gì của ai”, và giữ tối thiểu 24 tháng.

Ví dụ hỏi đáp theo vai trò

Cùng một câu hỏi, ba người hỏi khác nhau, ba câu trả lời khác nhau — đó là hành vi đúng.

Mô hình & chi phí

Định tuyến theo độ khó

Không phải câu hỏi nào cũng cần mô hình mạnh nhất. Hệ thống phân loại ý định trước rồi định tuyến, giúp giữ chi phí ở mức chấp nhận được mà không hạ chất lượng ở những câu thực sự khó.

Ước lượng chi phí hằng tháng

Tính trên giả định 150 người dùng hoạt động, mỗi người 8 câu hỏi mỗi ngày làm việc, 22 ngày mỗi tháng — tương đương 26.400 câu hỏi mỗi tháng. Mỗi câu tiêu tốn khoảng 9.000 token đầu vào (trong đó 6.000 là phần tiền tố ổn định được lưu đệm) và 700 token đầu ra.

Quy đổi khoảng 10 triệu đồng mỗi tháng, nằm dưới ngưỡng NFR-19. Ba yếu tố ảnh hưởng mạnh nhất tới con số này, theo thứ tự:

• Lưu đệm phần tiền tố ổn định. Mô tả công cụ và câu lệnh hệ thống không đổi giữa các câu hỏi, nên phần này đọc từ bộ đệm với giá bằng khoảng một phần mười. Bỏ lưu đệm làm chi phí tăng khoảng 60%.
• Tỉ lệ định tuyến. Đẩy tỉ trọng câu dùng mô hình mạnh từ 20% lên 50% làm chi phí gần gấp đôi.
• Kích thước kết quả truy vấn. Trần 200 bản ghi giữ phần đầu vào không phình. Bỏ trần là nguyên nhân phổ biến nhất khiến chi phí vượt dự toán.

Cơ chế kiểm soát chi phí

• Ghi số token và chi phí ước tính cho từng lần gọi, gom theo người dùng và theo đơn vị.
• Hạn mức tháng cấu hình được ở ba cấp: toàn hệ thống, đơn vị, cá nhân. Chạm 80% hạn mức thì cảnh báo, chạm 100% thì chuyển toàn bộ về mô hình rẻ và thông báo cho quản trị.
• Bảng theo dõi chi phí theo ngày, tách theo loại tác vụ (hỏi đáp, gợi ý phân công, soạn báo cáo).

Khi tắt AI

Toàn bộ chức năng nghiệp vụ vẫn hoạt động. Cụ thể, khi cờ AI tắt:

• Trợ lý hỏi đáp chuyển sang chế độ tra cứu theo mẫu: người dùng chọn loại câu hỏi từ danh sách và điền tham số. Kém tiện hơn nhưng vẫn lấy được số liệu.
• Engine phân công dùng so khớp từ khoá thay cho suy luận nội dung; trọng số tín hiệu AI về 0.
• Gợi ý soạn báo cáo cuối ngày biến mất; người dùng tự viết như trước.

Lộ trình năng lực

Bộ kiểm chuẩn

Điều kiện mở từng mức là vượt một bộ câu hỏi kiểm chuẩn, không phải cảm nhận chủ quan. Bộ này gồm 200 câu hỏi thật thu thập từ các đơn vị, mỗi câu có đáp án đúng đã xác minh bằng truy vấn tay, và được chấm lại mỗi quý. Ba tiêu chí chấm:

• Đúng — con số trả về khớp đáp án. Mục tiêu từ 85%.
• Đủ — trả lời trọn vẹn câu hỏi, không bỏ sót phần nào. Mục tiêu từ 80%.
• Không vượt quyền — không câu nào trả về dữ liệu ngoài phạm vi. Mục tiêu 100%, và đây là tiêu chí duy nhất không có ngưỡng chấp nhận thấp hơn.

Kiến trúc & phương án đa nền tảng

Chọn kiến trúc theo quy mô thật của bài toán chứ không theo xu hướng: một khối ứng dụng có ranh giới phân hệ rõ ràng, một lõi giao diện dùng chung cho bốn nền tảng, và một công cụ di trú tách hẳn khỏi ứng dụng để hệ thống cũ không để lại dấu vết nào trong phần lõi.

Sơ đồ tổng thể

 ┌─ ỨNG DỤNG ────────────────────────────────────────────────────────────┐
 │  Web (trình duyệt)   Desktop (Windows/macOS)   Di động (iOS/Android)  │
 │         └──────────────────┬──────────────────────────┘               │
 │                   LÕI GIAO DIỆN DÙNG CHUNG                            │
 │              (thành phần · trạng thái · client API)                   │
 └────────────────────────────┬──────────────────────────────────────────┘
                              │ HTTPS · REST v1 · JWT
 ┌─ DỊCH VỤ ỨNG DỤNG ─────────▼──────────────────────────────────────────┐
 │  Cổng vào: xác thực · giới hạn tần suất · nhật ký · phiên bản API     │
 │  ┌──────────────────────────────────────────────────────────────────┐ │
 │  │ LỚP KIỂM SOÁT PHẠM VI  ← mọi truy vấn bắt buộc đi qua            │ │
 │  └──────────────────────────────────────────────────────────────────┘ │
 │  Nhân sự │ Tổ chức │ Công việc │ Lead │ Phân công │ Trực-Nghỉ         │
 │  Đánh giá │ Báo cáo │ Trợ lý AI │ Cấu hình │ Thông báo                │
 └──────┬──────────────────┬───────────────────┬─────────────────────────┘
        │                  │                   │
 ┌──────▼─────┐   ┌────────▼────────┐   ┌──────▼──────────────────────┐
 │ PostgreSQL │   │ Redis + hàng đợi│   │ Lưu trữ đối tượng (tệp)     │
 │ dữ liệu    │   │ việc nền, đệm   │   │ đính kèm, kết xuất báo cáo  │
 └────────────┘   └─────────────────┘   └─────────────────────────────┘
                           │
                  ┌────────▼───────────────────────────────────────┐
                  │ TIẾN TRÌNH NỀN                                 │
                  │ sinh đề xuất phân công · chia lead ·           │
                  │ tính chỉ số kỳ · gửi thông báo · cảnh báo      │
                  └────────┬───────────────────────────────────────┘
                           │
                  ┌────────▼───────────────┐
                  │ Mô hình ngôn ngữ       │
                  │ (Claude API)           │
                  └────────────────────────┘

  Không có kết nối thường trực nào tới hệ thống cũ. Công cụ di trú nằm
  ngoài sơ đồ này — chạy tay vài lần rồi bị gỡ khỏi kho mã.
  ngoài sơ đồ này, chạy tay vài lần rồi bị gỡ bỏ.

Chọn kiến trúc

Ba mô-đun được giữ ranh giới đặc biệt sạch để tách ra thành dịch vụ riêng nếu tải tăng: tiến trình nền (phân công, chia lead, tính chỉ số), trợ lý AI (đặc tính tải và chi phí khác hẳn phần còn lại), và kết xuất báo cáo (tác vụ nặng, chạy theo đợt).

Công nghệ theo lớp

Chiến lược đa nền tảng

So sánh các phương án đã cân nhắc

Phương án được chọn: Web + Tauri + Capacitor. Lý do quyết định là bản chất của các luồng cần dùng trên di động: xem việc của tôi, duyệt đề xuất, nộp và duyệt đơn nghỉ, xem lịch trực, nhận thông báo. Đây đều là luồng đọc và thao tác đơn giản, không đòi hỏi đồ hoạ nặng hay tương tác phức tạp — chính là vùng mà giải pháp đóng gói web đáp ứng tốt.

Phân bổ chức năng theo nền tảng

Nguyên tắc phân bổ: di động phục vụ người đang di chuyển (xem, duyệt, cập nhật nhanh); máy tính và web phục vụ người đang làm việc tập trung (cấu hình, chấm điểm, phân tích). Không cố ép mọi màn hình lên mọi nền tảng.

Thông báo & chế độ ngoại tuyến

Thông báo

Mỗi loại sự kiện có cấu hình riêng cho từng kênh, và người dùng tự bật tắt trong phần cài đặt cá nhân. Nguyên tắc chống nhiễu: gộp thông báo cùng loại trong cửa sổ 15 phút, và không đẩy ngoài khung giờ người dùng khai báo, trừ nhóm sự kiện khẩn.

Ngoại tuyến

Không đặt mục tiêu hoạt động ngoại tuyến hoàn toàn — đó là bài toán đồng bộ hai chiều phức tạp và không tương xứng với nhu cầu thực. Mức hỗ trợ:

• Đọc ngoại tuyến — dữ liệu đã tải được giữ trong bộ đệm cục bộ; mở ứng dụng khi mất mạng vẫn xem được việc của mình và lịch trực, kèm nhãn ghi rõ thời điểm cập nhật gần nhất.
• Ghi có hàng đợi — các thao tác đơn giản (đổi trạng thái việc, ghi giờ, ghi nhận tương tác lead) xếp vào hàng đợi cục bộ và gửi lại khi có mạng. Xung đột được phát hiện bằng phiên bản bản ghi và hiển thị cho người dùng quyết định.
• Không hỗ trợ ngoại tuyến cho các thao tác cần tính toán phía máy chủ: chấm điểm kỳ, cấu hình, trợ lý AI.

Công cụ di trú một lần

  ┌─ CÔNG CỤ DI TRÚ (chạy tay, gỡ sau khi cắt chuyển) ────────────┐
  │                                                                │
  │  ① TRÍCH XUẤT ──▶ ② QUY ĐỔI ──▶ ③ NẠP ──▶ ④ ĐỐI SOÁT          │
  │     REST theo lô    bảng map      ghi vào    so số lượng       │
  │     ghi ra tệp      danh mục      CSDL       và giá trị tổng   │
  │     trung gian      + làm sạch    ERP        → báo cáo lệch    │
  │                                                                │
  └────────────────────────────────────────────────────────────────┘
        ▲                                          │
        │ đọc, không bao giờ ghi                   ▼
  ┌──────────────┐                        ┌────────────────────┐
  │  Bitrix24    │                        │  ERP NHÂN HÒA      │
  │  (hệ thống   │                        │  không hề biết tới │
  │   sẽ bị tắt) │                        │  Bitrix24 tồn tại  │
  └──────────────┘                        └────────────────────┘

Bốn bước

1. Trích xuất ra tệp trung gian

   Gọi REST theo lô, xử lý phân trang và giới hạn tần suất, ghi kết quả thô ra tệp. Tách hẳn bước này khỏi các bước sau để chạy lại phần quy đổi và nạp mà không phải gọi lại hệ thống nguồn — điều này rút mỗi lần chạy thử từ nhiều giờ xuống vài phút.

2. Quy đổi và làm sạch

   Ánh xạ trạng thái, độ ưu tiên, mã khu vực, mã nguồn lead sang danh mục của hệ thống mới theo bảng quy đổi khai báo được. Chuẩn hoá số điện thoại và thư điện tử. Bản ghi không quy đổi được không bị bỏ im lặng — chúng vào danh sách ngoại lệ để người xử lý tay.

3. Nạp

   Ghi vào cơ sở dữ liệu ERP theo đúng thứ tự phụ thuộc: nhân sự → phòng ban → đơn vị → nhóm làm việc → công việc → ghi giờ → lead → tương tác. Bất biến theo khoá nguồn, nên chạy lại không sinh bản ghi trùng.

4. Đối soát

   So số lượng bản ghi và các giá trị tổng hợp giữa hai hệ thống theo từng chiều (trạng thái, người phụ trách, khoảng thời gian). Kết quả là một báo cáo lệch — đây là bằng chứng nghiệm thu ở mốc M3.

Ràng buộc bắt buộc

• Chỉ đọc. Công cụ không có bất kỳ đường ghi nào tới Bitrix24. Đây là ràng buộc kiểm chứng được bằng rà soát mã: mã webhook cấp cho công cụ chỉ có phạm vi đọc.
• Nằm ngoài ứng dụng. Chạy như một tiến trình riêng, không nằm trong dịch vụ ứng dụng, không có điểm cuối nào gọi được từ giao diện người dùng ngoài trang quản trị di trú.
• Có ngày hết hạn. Toàn bộ mã của công cụ, các trường ma_nguon_cu, du_lieu_goc và bảng nhật ký di trú bị xoá khỏi kho mã sau khi cắt chuyển được nghiệm thu. Việc gỡ này là một hạng mục công việc có người chịu trách nhiệm, không phải lời hứa.
• Bí mật kết nối tách riêng. Mã webhook của Bitrix24 chỉ nằm trong cấu hình của công cụ di trú, không nằm trong cấu hình ứng dụng.

Nhận dữ liệu từ nguồn ngoài sau khi cắt chuyển

Sau khi Bitrix24 tắt, ERP vẫn cần nhận dữ liệu từ bên ngoài ở hai chỗ. Hai chỗ này là giao diện lập trình của ERP, không phải tích hợp ngược:

Cả hai đều là luồng một chiều đi vào, dùng đúng giao diện lập trình công khai, chịu đúng lớp kiểm soát quyền. Không có ngoại lệ kiến trúc nào cho chúng.

Hạ tầng & quy trình phát hành

Môi trường

Quy trình phát hành

• Tích hợp liên tục — mỗi lần gộp mã chạy kiểm tra kiểu, kiểm tra định dạng, kiểm thử đơn vị và kiểm thử tích hợp; không đạt thì không gộp được.
• Triển khai xanh–lam — chạy song song hai bản, chuyển lưu lượng sau khi bản mới qua kiểm tra sức khoẻ; quay lui bằng cách chuyển lưu lượng ngược, mất dưới 10 phút.
• Di trú cơ sở dữ liệu tương thích ngược — mọi thay đổi lược đồ phải chạy được với cả bản mã cũ và mới, để quay lui không kẹt ở tầng dữ liệu. Thay đổi phá vỡ tương thích được tách thành hai lần phát hành.
• Cờ tính năng — tính năng lớn phát hành ở trạng thái tắt, bật dần theo đơn vị. Cách này khớp với chiến lược chuyển đổi bốn trạng thái ở tài liệu 03.

Sao lưu

• Sao lưu toàn phần cơ sở dữ liệu hằng ngày, giữ 30 ngày; sao lưu nhật ký giao dịch liên tục cho phép khôi phục về một thời điểm bất kỳ với sai số dưới 15 phút.
• Sao lưu tệp đính kèm hằng ngày sang vị trí lưu trữ tách biệt về mặt vật lý.
• Diễn tập khôi phục mỗi quý trên môi trường tiền vận hành, có ghi biên bản thời gian thực tế.

Mô hình dữ liệu & giao diện lập trình

Cấu trúc dữ liệu theo miền nghiệp vụ, quy ước chung áp cho mọi bảng, nguyên tắc thiết kế giao diện lập trình, danh mục sự kiện nội bộ, và kế hoạch di trú dữ liệu từ hệ thống hiện tại.

Quan hệ chính

                       ┌──────────────┐
                       │  PHÒNG BAN   │
                       └──────┬───────┘
                              │ nhiều–nhiều
   ┌──────────────┐    ┌──────▼───────┐    ┌──────────────┐
   │  NHÓM QUYỀN  │───▶│   NHÂN SỰ    │◀──▶│   ĐƠN VỊ     │──┐ cha–con
   └──────────────┘ 1:n└──┬───┬───┬───┘n:m └──────┬───────┘◀─┘
                          │   │   │               │
             ┌────────────┘   │   └──────────┐    │ nhận việc / nhận lead
             │                │              │    │
      ┌──────▼──────┐  ┌──────▼──────┐ ┌─────▼────▼──┐
      │  KỸ NĂNG    │  │  CÔNG VIỆC  │ │    LEAD     │
      │  (n:m mức)  │  └──────┬──────┘ └──────┬──────┘
      └─────────────┘         │               │
                       ┌──────▼───────────────▼──────┐
                       │  PHÂN CÔNG · ĐỀ XUẤT · LỊCH │
                       │  SỬ CHIA — bất biến, có lý do│
                       └─────────────────────────────┘

   ┌──────────────┐   ┌──────────────┐   ┌──────────────┐
   │  LỊCH TRỰC   │   │  ĐƠN NGHỈ    │   │ NHÓM LÀM VIỆC│
   └──────┬───────┘   └──────┬───────┘   └──────┬───────┘
          └──────────────────┼──────────────────┘
                             │  đầu vào chỉ số
                      ┌──────▼───────┐      ┌──────────────┐
                      │   KỲ ĐÁNH    │─────▶│  ĐIỂM ĐÁNH   │
                      │     GIÁ      │      │   GIÁ /NGƯỜI │
                      └──────┬───────┘      └──────────────┘
                             │ dùng
                      ┌──────▼───────┐
                      │ BỘ TIÊU CHÍ  │◀── gắn với ĐƠN VỊ
                      │ (bản chụp khi│
                      │  chốt kỳ)    │
                      └──────────────┘

Danh mục thực thể

Miền tổ chức

Miền công việc

Miền khách hàng tiềm năng

Miền phân công

Miền lịch trực & nghỉ phép

Miền đo lường

Miền hệ thống

Quy ước chung

Giao diện lập trình

Nguyên tắc

• REST theo tài nguyên, đường dẫn dạng /api/v1/<tài-nguyên>. Phiên bản nằm trong đường dẫn để hai phiên bản chạy song song trong giai đoạn chuyển đổi ứng dụng.
• Phân trang bằng con trỏ cho danh sách lớn, phân trang bằng số trang cho danh sách nhỏ có tổng số cố định. Trần mặc định 100 bản ghi mỗi trang, tối đa 500.
• Lọc, sắp xếp, chọn trường qua tham số truy vấn chuẩn hoá, dùng chung cú pháp cho mọi tài nguyên.
• Bất biến theo khoá cho mọi thao tác ghi có thể bị lặp: yêu cầu mang khoá bất biến, gọi lại cùng khoá trả về kết quả cũ thay vì tạo bản ghi mới.
• Mã lỗi có cấu trúc: mã máy đọc được, thông điệp tiếng Việt cho người dùng, và mã truy vết để đối chiếu với nhật ký.
• Giới hạn tần suất theo tài khoản và theo địa chỉ, trả về thông tin hạn mức còn lại trong đầu mục phản hồi.

Nhóm điểm cuối chính

Sự kiện nội bộ

Các mô-đun trao đổi qua một kênh sự kiện nội bộ thay vì gọi thẳng nhau. Cách này giữ ranh giới mô-đun sạch và cho phép thêm người tiêu thụ mới mà không sửa nơi phát.

Di trú dữ liệu

Quy trình di trú

1. Chạy thử trên môi trường tiền vận hành

   Ít nhất ba lần, lần cuối cách mốc chuyển thật không quá một tuần. Mỗi lần đo thời gian thực tế của từng bước để lập lịch cho lần chạy thật.

2. Đối soát tự động

   Kịch bản so sánh số lượng và tổng giá trị theo từng chiều (trạng thái, người phụ trách, khoảng thời gian) giữa hai hệ thống. Ngưỡng sai số chấp nhận được thoả thuận trước với từng đơn vị nghiệp vụ.

3. Rà soát mẫu bằng người

   Mỗi đối tượng lấy ngẫu nhiên 50 bản ghi, đại diện đơn vị nghiệp vụ mở song song hai hệ thống và xác nhận khớp từng trường.

4. Chuyển thật ngoài giờ

   Thực hiện vào cuối tuần. Bitrix24 chuyển sang chỉ đọc trong thời gian chuyển, có thông báo trước ba ngày.

5. Giữ lưới an toàn

   Giữ Bitrix24 ở chế độ chỉ đọc tối thiểu 90 ngày sau khi chuyển, và giữ bản sao dữ liệu gốc theo chính sách lưu trữ dài hạn.

Phân quyền & bảo mật

Mô hình quyền hai chiều — làm được gì nhân với làm được trên dữ liệu của ai — cùng danh mục khoá quyền, ma trận vai trò, và các biện pháp bảo vệ dữ liệu tương ứng với quy định hiện hành về dữ liệu cá nhân.

Mô hình hai chiều

  Yêu cầu vào
      │
      ▼
  ① Xác thực ─────────── phiên hợp lệ? → không thì 401
      │
      ▼
  ② Kiểm khoá quyền ──── điểm cuối này cần khoá gì?
      │                   tập khoá của người dùng có chứa không?
      │                   → không thì 403, ghi nhật ký
      ▼
  ③ Tính phạm vi ─────── tập đơn vị nhìn thấy
      │                   tập nhân sự nhìn thấy
      │                   (đọc từ bộ đệm, làm mới khi cơ cấu đổi)
      ▼
  ④ Ghép vào truy vấn ── điều kiện phạm vi TIÊM CỐ ĐỊNH
      │                   không có đường bỏ qua
      ▼
  ⑤ Lọc trường ───────── loại trường nhạy cảm khỏi kết quả
      │
      ▼
  ⑥ Nhật ký ──────────── ghi truy cập nếu chạm dữ liệu nhạy cảm

Ba lý do chọn mô hình này thay vì phân quyền theo vai trò cứng:

• Vai trò cứng không mô tả được thực tế. Một người có thể vừa là trưởng nhóm của đơn vị A vừa là thành viên đơn vị B. Với vai trò cứng, phải sinh ra vai trò lai cho từng tổ hợp.
• Cơ cấu tổ chức thay đổi thường xuyên hơn danh mục quyền. Tách phạm vi ra khỏi khoá quyền nghĩa là chuyển người sang đơn vị khác tự động thay đổi phạm vi mà không phải sửa nhóm quyền.
• Chứng minh được không có lối vòng. Vì phạm vi tính ở một chỗ và ghép ở một chỗ, việc rà soát an toàn quy về rà soát một mô-đun thay vì rà soát toàn bộ truy vấn trong hệ thống.

Danh mục khoá quyền

Khoá quyền đặt theo dạng miền.hành_động. Danh mục kế thừa và mở rộng từ hệ thống hiện có, tổ chức theo 14 miền.

Ma trận vai trò mặc định

Bảy nhóm quyền dựng sẵn, có thể sửa và nhân bản. Ký hiệu: ✓ có quyền, ◐ có quyền hạn chế (chỉ bản thân hoặc chỉ một phần), ô trống là không có quyền.

Tính phạm vi dữ liệu

Phạm vi tính từ vị trí của người dùng trong cây đơn vị, theo bốn mức:

Thuật toán

tập_đơn_vị(người) =
    ⋃ { nhánh_con_cháu(đv) : đv ∈ đơn_vị_người_này_làm_trưởng }
  ∪   { đv                 : đv ∈ đơn_vị_người_này_là_thành_viên }

tập_nhân_sự(người) =
    { thành viên của mọi đv ∈ tập_đơn_vị(người) }
  ∪ { chính người đó }

Ba chi tiết triển khai quan trọng:

• Đệm kết quả. Phạm vi tính một lần mỗi phiên và lưu đệm. Bộ đệm bị xoá khi cơ cấu tổ chức thay đổi, khi thành viên đơn vị thay đổi, hoặc khi nhóm quyền của người dùng thay đổi.
• Ngoại lệ quyền cá nhân. Người phụ trách và người theo dõi luôn xem được bản ghi của mình, kể cả khi bản ghi nằm ngoài phạm vi (ví dụ một việc thuộc dự án ở đơn vị khác). Ngoại lệ này khai báo tường minh cho từng loại thực thể, không suy diễn ngầm.
• Không kế thừa ngang. Trưởng đơn vị A không thấy dữ liệu đơn vị B chỉ vì hai đơn vị cùng cấp. Phạm vi chỉ mở rộng xuống, không mở rộng ngang.

Che trường nhạy cảm

Trường nhạy cảm bị loại bỏ ở tầng truy vấn, trước khi dữ liệu rời khỏi tầng dịch vụ. Hệ quả: chúng không bao giờ nằm trong phản hồi giao diện lập trình, không nằm trong tệp kết xuất, và không nằm trong ngữ cảnh gửi tới mô hình AI.

Biện pháp bảo mật

Xác thực & phiên

• Mật khẩu băm bằng thuật toán chậm có muối riêng; chính sách độ mạnh tối thiểu và chặn mật khẩu phổ biến.
• Người dùng mới nhận mật khẩu khởi tạo và bị buộc đổi ở lần đăng nhập đầu.
• Phiên dùng thẻ truy cập ngắn hạn (15 phút) và thẻ làm mới dài hạn có thể thu hồi. Đăng xuất thu hồi thẻ làm mới ở phía máy chủ, không chỉ xoá phía máy khách.
• Xác thực hai yếu tố tuỳ chọn cho các nhóm quyền cao; bắt buộc cho nhóm Quản trị.
• Khoá tài khoản tạm thời sau số lần đăng nhập sai liên tiếp; đếm theo cả tài khoản và địa chỉ nguồn.
• Chuẩn bị sẵn điểm nối cho đăng nhập một lần ở giai đoạn sau, không triển khai trong v1.

Bảo vệ dữ liệu

• Toàn tuyến mã hoá; chuyển hướng bắt buộc và bật cơ chế yêu cầu trình duyệt chỉ dùng kênh an toàn.
• Mã hoá ổ đĩa cho máy chủ cơ sở dữ liệu và lưu trữ tệp; mã hoá ở tầng ứng dụng cho nhóm trường định danh cá nhân và tài chính.
• Bí mật cấu hình nằm trong kho bí mật, không nằm trong mã nguồn, không nằm trong biến môi trường hiển thị được qua giao diện.
• Bản sao dữ liệu dùng cho môi trường tiền vận hành bắt buộc che thông tin cá nhân trước khi nạp.

An toàn ứng dụng

• Kiểm tra dữ liệu đầu vào theo lược đồ ở biên; không tin dữ liệu từ máy khách trong bất kỳ hoàn cảnh nào.
• Truy vấn tham số hoá toàn bộ; không ghép chuỗi truy vấn.
• Chính sách nguồn nội dung nghiêm ngặt; thoát nội dung do người dùng nhập ở tầng hiển thị.
• Bảo vệ chống giả mạo yêu cầu liên trang cho các thao tác ghi dựa trên phiên.
• Giới hạn tần suất theo tài khoản và theo địa chỉ trên toàn bộ điểm cuối, ngưỡng chặt hơn cho đăng nhập và cho trợ lý AI.
• Quét phụ thuộc tự động trong quy trình tích hợp liên tục; lỗ hổng mức nghiêm trọng chặn phát hành.
• Tệp tải lên: kiểm tra kiểu thật theo nội dung chứ không theo phần mở rộng, giới hạn dung lượng, quét mã độc, lưu ngoài thư mục phục vụ web.

Kiểm toán

Nhật ký kiểm toán ghi hai loại sự kiện với mức chi tiết khác nhau:

Nhật ký kiểm toán là bảng chỉ ghi thêm. Không có điểm cuối nào cho phép sửa hoặc xoá; việc dọn dẹp theo chính sách lưu trữ thực hiện bằng tác vụ vận hành có phê duyệt riêng.

Dữ liệu cá nhân

Hệ thống xử lý dữ liệu cá nhân của người lao động, thuộc phạm vi điều chỉnh của Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân. Bốn nghĩa vụ có ảnh hưởng trực tiếp tới thiết kế:

1. Xác định mục đích và phạm vi xử lý

   Mỗi nhóm trường dữ liệu cá nhân được gắn mục đích sử dụng rõ ràng trong tài liệu nội bộ. Trường không phục vụ mục đích nào trong danh sách thì không thu thập.

2. Bảo đảm quyền của chủ thể dữ liệu

   Người lao động xem được toàn bộ dữ liệu cá nhân của mình trong hệ thống, biết được ai đã truy cập (qua nhật ký), và yêu cầu chỉnh sửa được phần thông tin tự khai.

3. Hạn chế thời gian lưu trữ

   Chính sách lưu trữ khai báo theo từng nhóm dữ liệu. Hồ sơ nhân sự đã nghỉ việc chuyển sang trạng thái lưu trữ và bị che phần lớn trường sau thời hạn quy định, giữ lại phần tối thiểu cần cho nghĩa vụ pháp lý.

4. Ghi nhận và thông báo sự cố

   Có quy trình phát hiện, đánh giá và báo cáo sự cố lộ lọt dữ liệu, kèm mốc thời gian và người chịu trách nhiệm. Quy trình này là một phần của tài liệu vận hành ở tài liệu 13.

Kiểm thử phân quyền

Phân quyền là hạng mục duy nhất trong hồ sơ này có tiêu chí đạt tuyệt đối. Ba lớp kiểm thử:

Lộ trình triển khai & ước lượng

Mười giai đoạn chia hai luồng chạy song song. Bản chạy được đầu tiên — đăng nhập, nhân sự, phòng ban, nhóm làm việc và quản lý công việc — hoàn tất trong tháng 9/2026. Toàn bộ tính năng đóng băng ngày 25/04/2027. Cắt chuyển cuối tháng 6/2027.

Hai mốc chốt của lộ trình

Nguyên tắc phân kỳ

1. Xây kín, cắt một lần

   Bitrix24 chạy bình thường suốt thời gian phát triển và không bị chạm vào. ERP chỉ đọc nó ở tuần đầu để đo dữ liệu, và ở giai đoạn 9 để chạy thử công cụ nhập. Không đồng bộ, không ghi ngược, không giai đoạn nào bắt nhân viên nhập liệu vào hai nơi.

2. Cơ bản trước, đầy đủ sau — nhưng nền móng thì không

   Tháng 9 làm bản cơ bản của năm phân hệ, lùi phần đầy đủ sang tháng 10. Ngoại lệ duy nhất là lớp kiểm soát phạm vi dữ liệu: phải có ngay từ tuần đầu, vì gắn nó vào sau là viết lại toàn bộ tầng truy vấn.

3. Hai luồng song song ngay sau tháng 9

   Từ 01/10, luồng thứ hai tách ra làm các phân hệ ít phụ thuộc: lịch trực, ứng dụng đa nền tảng, trợ lý AI. Cách này là điều kiện để kịp mốc đóng băng tính năng tháng 4.

4. Chạy thử thay cho vận hành thật

   Xây độc lập có một cái giá: hệ thống không tự chứng minh được bằng dữ liệu vận hành thật cho tới ngày cắt. Bù lại bằng sáu tuần chạy thử có kiểm soát — người dùng thật, dữ liệu thật đã nhập, môi trường tiền vận hành. Đây là giai đoạn không được rút ngắn khi tiến độ căng.

5. Nghỉ Tết nằm trong ước lượng

   Tết Nguyên Đán 2027 rơi vào khoảng 03–11/02/2027. Giai đoạn 6 và giai đoạn 7 đã được cộng thêm một tuần để hấp thụ kỳ nghỉ này. Không có giai đoạn nào đặt mốc bàn giao trong tháng 2.

Sơ đồ tiến độ

Chi tiết tháng 9 — bản chạy được đầu tiên

Phạm vi tháng 9 — làm gì

Phạm vi tháng 9 — lùi gì sang giai đoạn 2

Danh sách này quan trọng ngang danh sách trên. Không chốt nó thì phạm vi tháng 9 sẽ tự phình ra và mốc trượt.

Năm điều kiện bắt buộc để mốc tháng 9 không trượt

1. Đội đủ quân từ ngày 01/09, không tuyển giữa chừng

   Tối thiểu 1 kiến trúc, 3 lập trình máy chủ, 2 lập trình giao diện làm toàn thời gian ngay tuần đầu. Nếu tới giữa tháng mới đủ người thì mốc mất khoảng hai tuần và không cứu được.

2. Lược đồ dữ liệu mang thẳng, không thiết kế lại

   Lấy nguyên các thực thể đã có ở xerp-4s và chỉ cắt bớt. Mọi đề xuất “thiết kế lại cho đẹp hơn” trong tháng 9 đều bị hoãn sang giai đoạn sau.

3. Danh sách nhân sự và cây đơn vị có sẵn trong tuần 1

   Phòng Nhân sự và các trưởng đơn vị phải bàn giao dữ liệu tổ chức ngay tuần đầu. Nếu phải phỏng vấn từng đơn vị trong lúc làm thì tuần 3 và 4 sẽ tắc.

4. Không thiết kế giao diện từ đầu

   Dùng thư viện thành phần sẵn có, thống nhất một bảng màu và một thang chữ. Phần trau chuốt giao diện để giai đoạn 2.

5. Bản tháng 9 là bản nội bộ, không phải bản cho toàn công ty

   Người dùng của nó là đội dự án và nhóm thí điểm (khoảng 10–15 người), chạy trên môi trường kiểm thử. Nếu kỳ vọng là toàn bộ 200 nhân sự dùng thật từ 01/10 thì mốc này không khả thi.

Các giai đoạn sau

Mốc bàn giao chính

Nhân sự & công sức

Phụ thuộc & điều kiện tiên quyết

Phương án nén & giãn tiến độ

Vận hành, rủi ro & nghiệm thu

Cách hệ thống được giám sát và giữ ổn định sau khi lên vận hành, danh mục rủi ro kèm biện pháp ứng phó, chiến lược kiểm thử, kế hoạch quản lý thay đổi, và tiêu chí nghiệm thu cụ thể cho từng giai đoạn.

Mô hình vận hành

Giám sát

Bảng theo dõi chia hai tầng: chỉ số kỹ thuật cho đội vận hành, chỉ số nghiệp vụ cho đội dự án và các trưởng đơn vị.

Nhật ký

• Nhật ký ứng dụng — có cấu trúc, mỗi dòng mang mã truy vết để nối các thao tác trong cùng một yêu cầu. Giữ 90 ngày.
• Nhật ký kiểm toán — tách riêng, chỉ ghi thêm, giữ 24 tới 36 tháng theo loại (xem tài liệu 11).
• Nhật ký di trú — mỗi lần chạy công cụ nhập dữ liệu ghi số bản ghi đọc và nạp, số lỗi, thời lượng, sai lệch đối soát. Là công cụ chẩn đoán chính ở giai đoạn 9 và 10, gỡ bỏ cùng công cụ di trú.
• Không ghi dữ liệu cá nhân hay bí mật vào nhật ký ứng dụng; các trường nhạy cảm bị che ở tầng ghi.

Cam kết dịch vụ nội bộ

Xử lý sự cố

Quy trình sự cố lộ lọt dữ liệu

Đây là loại sự cố duy nhất có quy trình riêng, vì nó kéo theo nghĩa vụ pháp lý:

1. Chặn ngay

   Thu hồi phiên và khoá kết nối liên quan, tạm khoá tài khoản nghi ngờ. Ưu tiên chặn trước, điều tra sau.

2. Xác định phạm vi

   Dùng nhật ký kiểm toán trả lời ba câu: dữ liệu nào bị chạm, của bao nhiêu người, qua lối vào nào. Nhật ký kiểm toán tồn tại chính là để trả lời được ba câu này.

3. Báo cáo nội bộ

   Thông báo ban điều hành và bộ phận pháp chế trong vòng 24 giờ kể từ khi xác định được phạm vi.

4. Thực hiện nghĩa vụ thông báo

   Theo hướng dẫn của bộ phận pháp chế, phù hợp quy định hiện hành về bảo vệ dữ liệu cá nhân.

5. Khắc phục gốc và rà soát

   Vá lỗ hổng, bổ sung kịch bản vào bộ kiểm thử phân quyền để lỗi cùng loại không tái diễn.

Đăng ký rủi ro

Mức rủi ro tính từ khả năng xảy ra nhân với mức tác động. Cột theo dõi chỉ ra ai kích hoạt biện pháp, không phải ai có lỗi khi rủi ro xảy ra.

Chiến lược kiểm thử

Quản lý thay đổi & đào tạo

Rủi ro R-03 và R-15 đều là rủi ro con người, không phải rủi ro kỹ thuật. Kế hoạch dưới đây là biện pháp chính đối phó với chúng.

Nguyên tắc

• Mỗi đơn vị có một người dùng chủ chốt tham gia từ giai đoạn thiết kế phân hệ liên quan tới đơn vị mình. Người này là kênh phản hồi và là người hướng dẫn lại cho đồng nghiệp.
• Không đào tạo trước quá lâu. Buổi đào tạo diễn ra trong vòng một tuần trước khi đơn vị bắt đầu dùng thật; đào tạo sớm hơn thì người học quên.
• Đào tạo theo việc, không theo màn hình. Nội dung tổ chức quanh các việc người ta thực sự làm hằng ngày, không phải quanh menu của hệ thống.

Kế hoạch đào tạo

Tài liệu bàn giao

• Hướng dẫn sử dụng theo vai trò, đặt trong hệ thống và tìm được bằng trợ lý AI.
• Tài liệu vận hành: kiến trúc triển khai, quy trình phát hành, quy trình sự cố, danh sách cảnh báo và cách xử lý từng loại.
• Tài liệu quyết định kiến trúc, cập nhật liên tục trong suốt dự án.
• Hồ sơ này, cập nhật theo những gì thực sự được xây.

Tiêu chí nghiệm thu từng giai đoạn

Vì hệ thống chỉ vận hành thật từ ngày cắt chuyển, nghiệm thu các giai đoạn trước đó dựa trên dữ liệu mô phỏng quy mô thật và trên đợt chạy thử có kiểm soát ở giai đoạn 9. Hai giai đoạn là cổng chặn: giai đoạn 1 vì nó quyết định cả chuỗi phía sau có giữ được nhịp không, và giai đoạn 9 vì nó quyết định có cắt chuyển hay không.

Kế hoạch cắt chuyển

Toàn bộ tổ chức chuyển sang hệ thống mới trong một cuối tuần. Vì không có giai đoạn chạy song song, kế hoạch này phải chi tiết tới mức từng giờ và phải được diễn tập trước.

Trước ngày cắt

Cuối tuần cắt chuyển

1. Thứ Sáu 18/06/2027, 17:00 — đóng băng hệ thống cũ

   Chuyển Bitrix24 sang chế độ chỉ đọc. Thông báo lại một lần nữa. Từ giờ phút này không ai ghi được vào hệ thống cũ, nên không còn nguy cơ dữ liệu phát sinh sau khi trích xuất.

2. Thứ Sáu 18/06, 17:30 – 22:00 — nhập phần dữ liệu đang mở

   Trích xuất và nạp toàn bộ dữ liệu còn đang hoạt động: công việc đang mở, lead đang mở, đơn nghỉ chờ duyệt, nhân sự, đơn vị, nhóm làm việc. Phần lịch sử đã nhập từ D − 5 nên khối lượng ở bước này nhỏ.

3. Thứ Bảy 19/06 sáng — đối soát

   Chạy kịch bản đối soát tự động theo từng đối tượng và từng chiều. Đại diện nghiệp vụ của mỗi đơn vị rà mẫu 50 bản ghi. Sai lệch ngoài ngưỡng thì xử lý ngay, không để sang chiều.

4. Thứ Bảy 19/06 chiều — kiểm tra khói

   Chạy 10 thao tác tiêu biểu trên môi trường vận hành thật: đăng nhập, tạo việc, phân công, duyệt, ghi giờ, nhận lead, ghi tương tác, nộp đơn nghỉ, xem lịch trực, hỏi trợ lý. Mỗi thao tác có người xác nhận.

5. Chủ nhật 20/06 — điểm quyết định

   Ban điều hành họp và ra một trong hai quyết định: mở cửa hoặc quay lui. Không có lựa chọn thứ ba là “mở cửa nhưng còn vấn đề”. Nếu quay lui, mở lại quyền ghi trên Bitrix24 và thông báo trước sáng thứ Hai.

6. Thứ Hai 21/06 sáng — mở cửa

   Toàn bộ nhân sự vào hệ thống mới. Người dùng chủ chốt của mỗi đơn vị có mặt tại chỗ. Đội dự án trực với thời gian phản hồi 30 phút.

72 giờ đầu — cửa sổ quay lui

Sau khi mở cửa

Thuật ngữ & quy ước

Mỗi khái niệm có đúng một định nghĩa và một danh sách từ không được dùng thay thế. Mã nguồn, giao diện lập trình và màn hình phải dùng đúng những từ này. Một tên xuất hiện trong mã mà không có ở đây thì hoặc từ điển thiếu, hoặc tên đặt sai.

Tổ chức & nhân sự

Công việc

Khách hàng tiềm năng

Phân công

Đo lường

Quyền & bảo mật

Quy ước đặt tên

Ba từ bị cấm dùng trong toàn bộ hệ thống

• “Team” — vì nó vừa được dùng để chỉ phòng ban, vừa chỉ đơn vị, vừa chỉ nhóm làm việc. Ba khái niệm này có ý nghĩa khác nhau về phạm vi dữ liệu và phải gọi tên riêng.
• “Task” trong chuỗi hiển thị và tên bảng — dùng công việc. Giữ lại trong khoá quyền và tên biến kỹ thuật vì đã là quy ước của hệ sinh thái.
• “KPI” khi nói về một chỉ số đơn lẻ — KPI là tên gọi của cả bộ tiêu chí và điểm tổng, không phải tên của một chỉ số. Nói “chỉ số tỉ lệ đúng hạn”, không nói “KPI đúng hạn”.