Cách thiết kế cấu trúc SharePoint Site để không rối sau một năm
SharePoint có thể trở thành một trong những nền tảng quản lý tài liệu và cộng tác mạnh nhất trong Microsoft 365. Nhưng nếu cấu trúc ban đầu được thiết kế thiếu nguyên tắc, chỉ sau vài tháng doanh nghiệp có thể rơi vào tình trạng rất quen thuộc:
Không biết nên tạo site mới hay dùng site cũ.
Tài liệu phòng ban nằm ở nhiều nơi.
Folder lồng quá sâu.
Permission khó kiểm soát.
Tên site không thống nhất.
Project đã kết thúc nhưng site vẫn tồn tại.
Người dùng phải hỏi nhau “file này nằm ở đâu?”
Vấn đề thường không nằm ở SharePoint, mà nằm ở information architecture.
Microsoft định nghĩa information architecture trong SharePoint là cách doanh nghiệp tổ chức và đặt tên cho nội dung, site, navigation, metadata, search và security để người dùng có thể tìm thấy đúng thông tin khi cần. Microsoft cũng nhấn mạnh rằng một information architecture được thiết kế tốt giúp cải thiện adoption, productivity và giảm rủi ro về compliance hoặc security.
Vì vậy, nếu muốn SharePoint vẫn dễ quản lý sau một năm, doanh nghiệp nên thiết kế cấu trúc ngay từ đầu dựa trên cách người dùng tìm và sử dụng thông tin, không chỉ dựa trên sơ đồ tổ chức.
Đừng bắt đầu bằng câu hỏi “nên tạo bao nhiêu site?”
Một lỗi rất phổ biến là doanh nghiệp bắt đầu bằng việc đếm phòng ban.
Có 6 phòng ban thì tạo 6 site.
Có 10 dự án thì tạo thêm 10 site.
Cách này có thể đúng trong một số trường hợp, nhưng chưa đủ.
Microsoft hiện khuyến nghị mô hình SharePoint hiện đại theo hướng flat architecture thay vì phụ thuộc quá nhiều vào subsite. Trong mô hình này, mỗi chủ đề, đơn vị công việc hoặc phạm vi cộng tác đủ rõ ràng có thể có một site riêng, sau đó các site được kết nối thông qua hub, navigation và search.
Điều này giúp site linh hoạt hơn, dễ đổi vị trí trong kiến trúc và dễ archive hoặc delete khi không còn cần thiết.
Một câu hỏi tốt hơn là:
Site này đại diện cho một đơn vị công việc, một nhóm người hay một nhóm nội dung nào?
Nếu chưa trả lời được, có thể chưa cần tạo site.
Khi nào nên tạo site theo phòng ban?
Site theo phòng ban phù hợp với nội dung ổn định và dài hạn.
Ví dụ:
HR
Finance
Sales
Marketing
Operations
Mỗi site có thể chứa tài liệu, page, list và các nội dung phục vụ riêng cho phòng ban đó.
Microsoft cũng xem cấu trúc theo department là một trong những mô hình information architecture phổ biến vì người dùng thường đã quen với sơ đồ tổ chức và dễ tìm thông tin theo mental model này.
Ví dụ, nhân viên muốn tìm leave policy thì nghĩ đến HR.
Muốn tìm sales template thì nghĩ đến Sales.
Muốn tìm finance procedure thì nghĩ đến Finance.
Cấu trúc theo phòng ban phù hợp với nội dung vận hành lâu dài.
Khi nào nên tạo site theo dự án?
Project có đặc điểm khác phòng ban.
Nó thường có:
Mục tiêu rõ.
Nhóm thành viên riêng.
Thời gian bắt đầu và kết thúc.
Tài liệu chuyên biệt.
Vì vậy, một project lớn có thể cần site riêng.
Ví dụ:
ERP Implementation
Office Relocation
Website Redesign
Microsoft 365 Migration
Customer A Deployment
Microsoft cũng khuyến nghị trong SharePoint hiện đại nên xem mỗi unit of work như một site riêng khi điều đó giúp phân quyền, ownership và lifecycle rõ hơn.
Điểm quan trọng là project site phải có lifecycle.
Khi project kết thúc, cần xác định site sẽ archive, giữ read-only hay xóa theo policy.
Nếu không, sau một năm SharePoint sẽ chứa rất nhiều project đã kết thúc nhưng vẫn hiển thị như đang hoạt động.
Hub Site nên được dùng để làm gì?
Khi số lượng site tăng, doanh nghiệp cần một lớp tổ chức cao hơn.
Đó là lúc Hub Site trở nên hữu ích.
Microsoft mô tả hub site như “connective tissue” kết nối các site liên quan với nhau. Hub có thể nhóm site theo department, project, division, region hoặc một concept chung, đồng thời cung cấp navigation, branding và khả năng tổng hợp nội dung/search trên các site liên kết.
Ví dụ:
HR Hub
có thể kết nối:
HR Policies
Recruitment
Learning & Development
Performance Management
Employee Resources
Hoặc:
Sales Hub
kết nối:
Sales Operations
Regional Sales
Product Resources
Key Account Projects
Như vậy doanh nghiệp không cần ép tất cả nội dung vào một site khổng lồ.
Hub đóng vai trò điều hướng và kết nối các site liên quan.
Không nên tạo một site khổng lồ cho toàn công ty
Một sai lầm thường gặp là tạo một site duy nhất:
Company Documents
Sau đó bên trong có hàng trăm folder:
HR
Finance
Sales
Marketing
Operations
Projects
Customers
Policies
2025
2026
Cách này có vẻ đơn giản lúc đầu, nhưng sau một năm sẽ rất khó quản trị.
Permission bắt đầu phức tạp.
Folder sâu hơn.
Search khó hiểu.
Ownership không rõ.
Microsoft hiện khuyến nghị mô hình hiện đại tránh cấu trúc quá sâu và ưu tiên nhiều site ngang hàng, sau đó kết nối bằng hub và navigation.
Một site nên có một mục tiêu đủ rõ.
Nếu site đang chứa quá nhiều nhóm nội dung không liên quan, đó là dấu hiệu nên tách.
Document Library quan trọng hơn folder
Một lỗi khác là doanh nghiệp mang nguyên cấu trúc file server cũ sang SharePoint.
Ví dụ:
Documents
→ Department
→ Year
→ Project
→ Customer
→ Contract
→ Final
→ Updated
Sau vài cấp folder, người dùng rất khó tìm lại tài liệu.
Microsoft khuyến nghị tránh folder hierarchy quá sâu; hơn một hoặc hai cấp nesting có thể tạo gánh nặng lớn về khả năng tìm kiếm và khám phá nội dung. Microsoft cũng đề xuất tạo các library theo chủ đề và sử dụng metadata/site columns thay vì chỉ dựa vào folder.
Ví dụ thay vì một Documents library chứa mọi thứ, HR có thể có:
Policies
Templates
Onboarding
Training Materials
Employee Communication
Mỗi library phục vụ một nhóm tài liệu rõ ràng.
Metadata giúp SharePoint không biến thành file server mới
Folder trả lời câu hỏi:
File nằm ở đâu?
Metadata trả lời:
File này là gì?
Ví dụ, một contract có thể được gắn các metadata như:
Customer
Document Type
Effective Date
Owner
Status
Confidentiality Level
Nhờ vậy người dùng có thể filter, search và tạo view mà không cần di chuyển file vào nhiều folder khác nhau.
Microsoft xem metadata architecture là một phần quan trọng của SharePoint information architecture vì nó ảnh hưởng trực tiếp đến search, browsing và compliance.
Doanh nghiệp không cần metadata quá phức tạp.
Chỉ nên dùng những field thực sự giúp người dùng tìm hoặc quản lý tài liệu.
Permission nên quản lý ở cấp site hoặc group khi có thể
Permission là một trong những nguyên nhân lớn nhất khiến SharePoint trở nên khó quản lý.
Một lỗi phổ biến là:
Folder A chia sẻ cho User 1.
Folder B chia sẻ cho User 2.
File C chia sẻ riêng cho User 3.
Sau vài tháng, không ai biết chính xác ai có quyền gì.
Microsoft khuyến nghị team site permissions nên được quản lý thông qua Microsoft 365 Group hoặc Team tương ứng khi có thể, thay vì tạo quá nhiều permission riêng lẻ.
Một nguyên tắc tốt là:
Site membership trước, item-level permission sau.
Nếu một nhóm người cần truy cập hầu hết nội dung của site, hãy quản lý họ ở cấp site/group.
Chỉ sử dụng permission đặc biệt cho những trường hợp thực sự cần.
Hub không tự động thay đổi permission của site
Đây là một điểm rất quan trọng.
Khi một site được associate vào Hub, permission của site đó không tự động bị thay đổi.
Microsoft xác nhận rằng hub association chủ yếu mang lại shared navigation, branding, search và content roll-up; quyền truy cập của từng site vẫn được giữ riêng.
Điều này giúp doanh nghiệp có thể có:
HR Hub
nhưng Payroll site vẫn chỉ cho nhóm HR/Finance phù hợp truy cập.
Người dùng không có quyền sẽ không thấy nội dung restricted được roll up.
Naming convention giúp giảm rối rất nhiều
Một site nên có tên rõ ràng ngay từ đầu.
Ví dụ:
HR – Policies
HR – Recruitment
Project – ERP Implementation
Region – HCMC
tốt hơn những tên như:
New Site
Project 1
Documents
Team Site
Tên tốt giúp người dùng hiểu nội dung trước khi click.
Microsoft cũng nhấn mạnh rằng label và navigation cần rõ ràng, trực quan và được thiết kế theo cách người dùng thực sự tìm thông tin.
Naming convention càng quan trọng khi số site tăng lên hàng chục hoặc hàng trăm.
Navigation không nên phản ánh hoàn toàn sơ đồ tổ chức
Sơ đồ tổ chức hữu ích, nhưng không phải lúc nào cũng là cách người dùng tìm thông tin.
Ví dụ, nhân viên muốn tìm:
Travel Policy
Expense Claim
IT Support
Training
Employee Benefits
Họ có thể không biết các nội dung này thuộc phòng ban nào.
Microsoft khuyến nghị navigation nên được thiết kế theo nhu cầu và cách người dùng tìm nội dung, có thể theo service, activity, audience, product hoặc function tùy ngữ cảnh.
Do đó, một intranet tốt có thể kết hợp:
Navigation theo department
và
Navigation theo task/service.
Site Owner cần được xác định rõ
Mỗi site nên có người chịu trách nhiệm.
IT không nên là owner nội dung của tất cả site.
Ví dụ:
HR site → HR Manager hoặc HR content owner
Finance site → Finance Manager
Project site → Project Manager
Microsoft phân biệt rõ các vai trò như hub owner, site owner, content creator và IT Admin trong quá trình quản lý information architecture. Site owner chịu trách nhiệm nội dung, navigation và quyền ở cấp site, trong khi IT hỗ trợ governance và cấu trúc tổng thể.
Nếu không có owner, site rất dễ trở thành nơi chứa nội dung cũ mà không ai dám xóa.
Site cần có lifecycle
Một site không nên tồn tại mãi chỉ vì đã được tạo.
Doanh nghiệp nên xác định:
Ngày tạo.
Owner.
Mục đích.
Review date.
Archive rule.
Delete rule.
Ví dụ, project site có thể được review sau 3 tháng kể từ ngày project kết thúc.
Department site có thể review mỗi 6 hoặc 12 tháng.
Nếu không có lifecycle, SharePoint sẽ ngày càng phình to.
Khi nào nên tạo site mới thay vì library mới?
Một rule thực tế là:
Nếu cùng ownership, cùng membership và cùng mục tiêu → có thể dùng cùng site nhưng tách library.
Nếu membership khác rõ rệt, ownership khác hoặc lifecycle khác → nên cân nhắc site riêng.
Ví dụ, HR Policies và HR Templates có thể ở cùng HR site nhưng khác library.
Nhưng Payroll có permission rất khác và dữ liệu nhạy cảm hơn, nên có thể phù hợp với site riêng.
Khi nào nên dùng Team Site?
Team Site phù hợp với collaboration.
Nó thường dành cho một nhóm người cùng làm việc trên nội dung, file, list và task.
Microsoft 365 Group có thể cung cấp membership cho Team Site và đồng thời kết nối với các tài nguyên khác như Planner hoặc Teams.
Ví dụ:
Project Team
Marketing Team
Operations Team
Khi nào nên dùng Communication Site?
Communication Site phù hợp hơn khi mục tiêu là publish nội dung cho nhiều người đọc nhưng ít người chỉnh sửa.
Ví dụ:
Company Policies
Employee Portal
Corporate News
IT Service Information
Microsoft mô tả communication site là loại site phù hợp để broadcast news và status rộng trong tổ chức, với permission thường được quản lý qua Owners, Members và Visitors.
Một lỗi phổ biến là dùng Team Site cho mọi loại nội dung kể cả những site chỉ dùng để publish.
Lỗi thường gặp: copy nguyên cấu trúc file server sang SharePoint
Đây là lỗi rất phổ biến trong migration.
Doanh nghiệp chuyển:
Shared Drive → SharePoint
nhưng giữ nguyên hàng trăm folder và permission.
Kết quả là SharePoint chỉ trở thành “file server trên Cloud”.
Cách tốt hơn là dùng migration như một cơ hội để thiết kế lại.
Xóa file không cần thiết.
Archive dữ liệu cũ.
Chuẩn hóa permission.
Tách nội dung theo site/library.
Thêm metadata khi cần.
Lỗi thường gặp: tạo quá nhiều site
Flat architecture không có nghĩa là mỗi folder cũ trở thành một site.
Một site nên đủ lớn để có giá trị quản trị riêng.
Nếu doanh nghiệp tạo site cho từng loại tài liệu nhỏ, người dùng lại gặp vấn đề ngược lại: quá nhiều site.
Hãy ưu tiên site theo:
Business unit.
Project lớn.
Audience rõ.
Security boundary rõ.
Lifecycle riêng.
Lỗi thường gặp: không review sau khi triển khai
Information architecture không phải thiết kế một lần rồi giữ nguyên mãi.
Microsoft nhấn mạnh rằng cấu trúc thông tin cần được điều chỉnh theo thời gian vì organization, người dùng và project đều thay đổi.
Sau 6 tháng hoặc 1 năm, doanh nghiệp nên review:
Site nào không còn dùng?
Site nào có quá nhiều nội dung?
Library nào quá lớn?
User có tìm thấy tài liệu không?
Navigation có còn phù hợp không?
Permission có dư không?
Đây là cách giữ SharePoint “sạch” lâu dài.
Một cấu trúc mẫu cho doanh nghiệp 50–100 người
Có thể tham khảo mô hình:
Company Hub
→ HR Site
→ Finance Site
→ Sales Site
→ Marketing Site
→ Operations Site
Bên cạnh đó có các project site:
→ Project – ERP
→ Project – Office Relocation
→ Project – Website
Các project site có thể được liên kết vào hub phù hợp hoặc một Project Hub riêng tùy quy mô.
Trong HR Site có thể có:
Policies library
Templates library
Training library
Lists cho onboarding hoặc request
Như vậy cấu trúc đủ tách biệt nhưng không bị phân mảnh quá mức.
Checklist thiết kế SharePoint Site Structure
Trước khi tạo hoặc redesign SharePoint, doanh nghiệp nên kiểm tra:
Mỗi site có mục tiêu rõ ràng
Mỗi site có owner
Đã phân biệt site theo phòng ban và project
Không phụ thuộc vào subsite hierarchy quá sâu
Hub được dùng để kết nối nhóm site liên quan
Không tạo một site khổng lồ cho toàn công ty
Document library được chia theo nội dung hợp lý
Folder nesting được giữ ở mức tối thiểu
Metadata được dùng khi thực sự giúp search/filter
Permission ưu tiên group/site-level
Có naming convention
Có rule cho external sharing
Có review date và lifecycle
Project site có kế hoạch archive
Navigation được test với người dùng thực tế
Kết luận
SharePoint trở nên rối không phải vì doanh nghiệp có quá nhiều file.
Nó thường trở nên rối vì site structure, navigation, permission và lifecycle không được thiết kế rõ từ đầu.
Microsoft hiện khuyến nghị SharePoint hiện đại theo mô hình flat architecture, trong đó các site độc lập được kết nối thông qua hub, navigation và search thay vì dựa vào một cây subsite sâu. Hub Site giúp kết nối các nhóm site liên quan, trong khi permission vẫn được giữ độc lập ở từng site.
Một nguyên tắc đơn giản có thể là:
Site cho một mục tiêu rõ ràng.
Hub để kết nối các site liên quan.
Library để tổ chức nhóm tài liệu.
Metadata để giúp tìm và lọc.
Group để quản lý quyền.
Lifecycle để SharePoint không ngày càng phình to.
Nếu doanh nghiệp thiết kế được sáu lớp này ngay từ đầu, SharePoint sẽ dễ quản lý hơn rất nhiều sau 6 tháng, một năm hoặc khi quy mô nhân sự tăng lên.
Liên hệ F-Tech để được tư vấn cấu trúc SharePoint phù hợp với doanh nghiệp của bạn.
