Concept & Design
Concept & System DesignTrình bày ý tưởng KMS Technical RequirementsNestJS · Next.js · MongoDB
Business + System Design

Company
Knowledge Base

Một Knowledge Management System (KMS) tập trung toàn bộ tri thức nội bộ của công ty — giải quyết trọn vẹn bài toán knowledge ownership và knowledge governance, không chỉ lưu trữ mà còn kiểm duyệt, phân quyền và cập nhật tài liệu một cách có hệ thống.

Tri thức tập trung Governance & Review Ownership rõ ràng AI-ready

01 Overview

Trong quá trình phát triển, tài liệu của công ty thường bị phân tán ở nhiều nơi: Google Drive, Notion, Word, PDF, tin nhắn, email, hoặc nằm trên máy tính cá nhân. Điều này dẫn đến nhiều vấn đề cốt lõi.

🔎

Khó tìm kiếm

Tài liệu nằm rải rác, không thể tìm khi cần.

🧍

Knowledge Silos

Kiến thức phụ thuộc vào từng cá nhân.

⏳

Onboarding chậm

Nhân viên mới mất nhiều thời gian bắt nhịp.

🔀

Quy trình không chuẩn

Giữa các phòng ban thiếu chuẩn hóa.

🗑️

Trùng lặp & lỗi thời

Không còn ai chịu trách nhiệm cập nhật.

🚪

Khó kiểm soát

Quyền truy cập & lịch sử thay đổi mờ mịt.

Hệ thống Company Knowledge Base tập trung toàn bộ tri thức nội bộ vào một nền tảng duy nhất — giúp lưu trữ, quản lý, tìm kiếm và chia sẻ hiệu quả, đồng thời đảm bảo tài liệu chính thức luôn được kiểm duyệt và cập nhật.

02 Objectives

Kho tri thức tập trung

Một điểm truy cập duy nhất cho toàn công ty.

Chuẩn hóa quy trình

Thống nhất cách làm việc giữa các phòng ban.

Onboarding nhanh

Rút ngắn thời gian đào tạo nhân viên mới.

Dễ chia sẻ kiến thức

Mọi thành viên đóng góp và cộng tác thuận lợi.

Chống thất thoát tri thức

Giữ lại kiến thức khi nhân sự nghỉ việc.

Tài liệu được kiểm duyệt

Bản chính thức luôn qua review & approval.

Tìm kiếm nhanh

Full-text trên toàn bộ tài liệu.

Sẵn sàng mở rộng AI

Kiến trúc dữ liệu chuẩn để tích hợp AI sau này.

03 Knowledge Structure

Trong một KMS, tri thức không để rải rác thành một "đống thư mục" phẳng mà được tổ chức thành bốn tầng đi từ tổng quát đến chi tiết. Mỗi tầng có một vai trò riêng:

1Company

Tầng gốc — đại diện toàn công ty, chứa tất cả các phòng ban.

2Knowledge Space

Không gian tri thức của một phòng ban (Department) như Engineering, HR, Marketing… Mỗi phòng ban tự sở hữu và quản lý Space của mình.

3Folder

Cách nhóm tài liệu theo mảng nghiệp vụ / chủ đề / quy trình bên trong một Space — ví dụ trong Engineering có Backend, DevOps, API. Đây không đơn thuần là "thư mục" cơ học mà là cách gom các tài liệu cùng một lĩnh vực lại với nhau, và có thể tạo sub-folder lồng nhiều cấp nếu cần chia nhỏ hơn.

4Article

Tài liệu thực tế nằm trong Folder: SOP, hướng dẫn, quy trình, tài liệu kỹ thuật, ghi chú… — soạn bằng Markdown hoặc upload HTML/PDF.

Tóm lại, thay vì chỉ có một cấp thư mục: Department sở hữu Knowledge Space → trong Space có nhiều Folder (và sub-folder lồng nhau) → trong mỗi Folder là các Article.

Company General Engineering Marketing HR Finance DEPARTMENTS = KNOWLEDGE SPACES Folders Company PoliciesEmployee HandbookIT Guideline · FAQTemplates Folders BackendFrontendDevOpsDatabaseAPI Folders Brand GuidelineCampaign SOPSEOContent Folders RecruitmentOnboardingBenefits Folders ReportsPayroll SOP
Company → Departments (Knowledge Spaces) → Folders → Articles. Customer Support & Sales cũng là Space riêng.

04 Knowledge Space

Mỗi Department sở hữu một Knowledge Space (General, Engineering, Marketing, HR, Finance, Sales, Support). Mỗi Space có 4 vai trò nội bộ — phân quyền theo từng không gian tri thức, không chỉ là role hệ thống đơn thuần.

Owner

Chịu trách nhiệm cao nhất về Space, quản lý cấu trúc & phân quyền.

Administrators

Quản trị vận hành: duyệt, cấu hình, quản lý thành viên.

Contributors

Tạo & chỉnh sửa tài liệu, gửi review để publish.

Readers

Chỉ đọc tài liệu đã publish trong Space.

05 Roles

Tách System Role (toàn hệ thống) khỏi Knowledge Role (trong từng Space). Nhờ đó một người có thể là Lead của Marketing nhưng chỉ là Member ở Engineering.

SYSTEM ROLES Super Admin Admin User KNOWLEDGE ROLES (per Space) Engineering Engineering Lead Senior Member Marketing Marketing Lead Marketing Member HR HR Lead HR Member Ví dụ · John Cùng một người, khác vai trò theo từng Space: Marketing Lead Engineering Member
System Role định nghĩa quyền hệ thống · Knowledge Role định nghĩa quyền theo từng Space (độc lập nhau).

06 Knowledge Lifecycle

Không phải tài liệu nào cũng được publish ngay. Tài liệu chính thức luôn phải đi qua bước Review.

Draft Pending Review Approved Published Archived
Draft → Pending Review → Approved → Published → Archived

07 Content Ownership

Mỗi thành viên có một không gian làm việc riêng (My Notes: My Research, My Learning, Draft SOP, Meeting Notes). Tại đây họ tự do viết markdown, upload HTML/PDF, ghi chú — không cần ai duyệt.

Khi muốn chuyển thành tài liệu chính thức, mới cần Lead/Admin duyệt — tách bạch rõ giữa tri thức cá nhân và tri thức chính thức của tổ chức.

My Notespersonal · no review Submit Engineering Space Review Published
Personal workspace → Submit → Space → Review → Approved → Published

08 Publishing Workflow

Member Create Draft Submit For Review Reviewerdecision Approve Publish Visible to Department Request Changes Revise reject resubmit ↺
Admin/Reviewer có thể Approve · Request Changes · Reject

09 Visibility

Tách bạch hai khái niệm độc lập: Ownership (ai sở hữu tài liệu) và Visibility (ai được xem). Một tài liệu do John sở hữu vẫn có thể có nhiều mức hiển thị khác nhau.

Ownership

Ai chịu trách nhiệm về tài liệu.

OwnerJohn

Visibility

Ai được phép xem — 5 cấp độ.

  • Private — chỉ mình owner
  • Specific Users — chọn từng người
  • Department — cả phòng ban
  • Company Internal — nội bộ toàn công ty
  • Public Link — link chia sẻ ra ngoài
Hai trục Ownership và Visibility hoàn toàn độc lập — quyền sở hữu không quyết định phạm vi hiển thị, và ngược lại.

10 Official Documents

Tài liệu chia thành hai loại rõ ràng — Personal Knowledge và Official Knowledge.

Thuộc tínhPersonal KnowledgeOfficial Knowledge
Review / kiểm duyệtKhông cầnCó
Owner rõ ràng—Có
Versioning—Có
Audit log—Có
Approval—Có
Đại diện công tyKhôngCó
Chỉ Official Knowledge mới là tài liệu chính thức của công ty. Personal Knowledge là bản nháp/ghi chú cá nhân, không đại diện tổ chức.

11 Versioning

Không chỉ lưu version — mỗi version cần đầy đủ metadata để truy vết.

Version

Số hiệu phiên bản (v1, v2…).

Author

Người tạo/chỉnh sửa phiên bản.

Reviewer

Người duyệt phiên bản.

Publish Date

Thời điểm publish.

Change Summary

Tóm tắt thay đổi so với bản trước.

Rollback

Khôi phục về phiên bản cũ bất kỳ.

13 Future AI

Cần chuẩn bị ngay từ đầu. Ví dụ, người dùng hỏi "Làm sao deploy production?" — AI sẽ truy vết đúng tài liệu và trả lời.

AI Query Engineering DevOps Deployment SOP → Answer
Tài liệu tổ chức tốt = AI/RAG truy xuất chính xác. Đây là lý do kiến trúc dữ liệu phải chuẩn từ đầu.

14 Data Architecture

Kiến trúc dữ liệu xoay quanh Knowledge Article làm trung tâm — nền tảng để hệ thống mở rộng linh hoạt. Các entity chính và quan hệ giữa chúng:

Department (Space) Folder Knowledge Articlemarkdown / html / pdf User Article Version Attachment Comment Tag Category Review Approval CROSS-CUTTING · áp cho mọi entity Permission Notification Activity Log 1 — N1 — N owns1 — N (history) hasworkflow
Entities: User · Department (Space) · Folder · Knowledge Article · Article Version · Attachment · Comment · Tag · Category · Review · Approval · Permission · Notification · Activity Log
Thiết kế quanh Knowledge Article + Version + Permission giúp hệ thống mở rộng dễ dàng: thêm AI embeddings, workflow phức tạp, hay multi-tenant về sau đều không phải đập đi làm lại.
↑