Deel

2) Mô hình tư duy (các lớp truy cập)

Hãy nghĩ theo lớp: admin toàn tổ chức, admin theo nhóm, và quản lý con người. Bắt đầu rộng (Org Admin), rồi thu hẹp (Group Admin), rồi chỉ gán manager đúng chỗ cần.

1. Xác định bộ admin tối thiểu.
2. Phân tách theo group khi có thể (giảm rủi ro).
3. Gán managers cho approvals và direct reports.
4. Rà soát quyền định kỳ (đặc biệt sau thay đổi tổ chức).

3) Đối tượng & thuật ngữ

Các thuật ngữ này xuất hiện trong các bài chính thức về roles. Dùng như “từ vựng chung” khi trao đổi với stakeholders.

• Org Admin: quyền quản trị toàn tổ chức (phạm vi rộng).
• Group Admin: quyền admin theo group (phạm vi hẹp hơn).
• Vai trò Manager: trách nhiệm và quyền truy cập của quản lý với team của họ.
• Direct reports: nhân sự thuộc mối quan hệ báo cáo trực tiếp với manager.
• Luồng phê duyệt: các hành động (vd: time off) được chuyển tới managers/admins.

5) Các việc cốt lõi cần làm

Đây là các việc bạn sẽ lặp lại khi công ty lớn dần.

• Gán vai trò manager cho các team.
• Giải thích managers có thể làm gì trên Deel (và không thể).
• Cấp quyền group-admin để uỷ quyền vận hành HR.
• Giữ danh sách Org Admin tối thiểu và luôn cập nhật.
• Xử lý escalations: “thiếu quyền” vs “cấp sai quyền”.
• Chuẩn bị scale bằng SSO/SCIM (nếu áp dụng).

6) Luồng chuẩn #1 — Gán vai trò manager

Dùng khi một quản lý mới cần phê duyệt yêu cầu hoặc quản lý team trong Deel.

1. Xác nhận người đó đã có user account trong đúng organization.
2. Xác định ai là direct reports của họ (quan hệ/structure).
3. Gán vai trò manager theo luồng cài đặt organization.
4. Yêu cầu manager đăng nhập và xác nhận họ thấy team view.
5. Chạy test: một direct report gửi một request (vd: time off).
6. Kiểm tra manager approve/decline được và bạn nhận đúng notification.

8) Điểm quyết định (A/B)

Các quyết định quyền phổ biến nhất ảnh hưởng trực tiếp tới bảo mật và tốc độ vận hành.

9) Lỗi thường gặp + guardrails

Hầu hết sự cố quyền là do vô tình. Coi đây như các “luật không tái phạm”.

• Lỗi: quá nhiều Org Admin → Tránh: giới hạn 1–3 owners.
• Lỗi: manager không duyệt được → Tránh: kiểm tra role + mapping direct reports.
• Lỗi: ranh giới group mơ hồ → Tránh: định nghĩa groups trước khi uỷ quyền.
• Lỗi: không có audit trail → Tránh: log thay đổi role (ai/khi nào/tại sao).
• Lỗi: không gỡ quyền → Tránh: thu hồi khi đổi vai trò/offboarding.

2) Mô hình tư duy (People như hệ thống hành động)

Hãy coi People là “nguồn tạo hành động” ngay cả khi nó chưa phải nguồn dữ liệu duy nhất. Profiles giữ dữ liệu; tasks và workflows tạo việc; structure/relations quyết định phạm vi hiển thị và luồng manager.

1. Tạo hoặc import hồ sơ nhân sự.
2. Thu thập thông tin bắt buộc (fields, forms, documents).
3. Gán tasks / checklist onboarding.
4. Tự động hoá follow-up bằng Workflow Builder.
5. Duy trì structure và relationships để báo cáo/phê duyệt chạy đúng.

3) Đối tượng & thuật ngữ

Các thuật ngữ này xuất hiện thường xuyên trong People Management và là “gạch nền” cho workflows HR.

• Worker profile: hồ sơ của một nhân sự trong Deel.
• Hợp đồng nhân viên trực tiếp (HRIS): luồng thiết lập cho direct employees.
• Import hàng loạt: tạo nhiều direct employees cùng lúc.
• Tasks / checklist onboarding: các bước vận hành được giao.
• Workflow Builder: automation cho workflow tasks.
• Cấu trúc tổ chức & quan hệ nhân sự: grouping và relationships dùng cho directory và org chart.

5) Các việc cốt lõi cần làm

Dùng như playbook chuẩn cho People Ops hằng ngày trong Deel.

• Tạo hợp đồng/profile nhân viên trực tiếp (HRIS) khi cần.
• Import hàng loạt direct employees.
• Thu thập thông tin nhân sự và field bắt buộc.
• Tạo và quản lý tasks cho nhân sự.
• Thiết lập automation workflows / Workflow Builder tasks.
• Duy trì org structure và worker relations.
• Chỉnh sửa hàng loạt thông tin worker và payroll contract (khi cần).

6) Luồng chuẩn #1 — Thêm nhân sự (thủ công → sẵn sàng)

Dùng khi bạn thêm ít nhân sự và muốn kết quả “sẵn sàng vận hành” đồng nhất.

1. Tạo worker profile / direct employee setup theo nhu cầu.
2. Thu thập thông tin (fields bắt buộc và demographics nếu bật).
3. Gán tasks và/hoặc checklist onboarding tuỳ biến.
4. Set manager roles và worker relations (để approvals route đúng).
5. Chạy thử 1 tác vụ tự động với Workflow Builder (vd: reminder hoặc yêu cầu tài liệu).
6. Xác nhận worker làm được các bước được giao và bạn theo dõi được trạng thái.

8) Điểm quyết định (A/B)

Chọn phương án phù hợp với quy mô và độ “chín” dữ liệu của bạn.

9) Lỗi thường gặp + guardrails

Các vấn đề này hay gặp khi build People hub nhanh. Dùng guardrails để giữ dữ liệu ổn định.

• Lỗi: thiếu mapping manager → Tránh: set relations ngay trong onboarding.
• Lỗi: trùng profile sau import → Tránh: định danh nhất quán + gộp sớm.
• Lỗi: tasks không rõ owner → Tránh: định nghĩa ownership trong checklist.
• Lỗi: automation chưa test → Tránh: pilot Workflow Builder cho 1 team.
• Lỗi: bulk edits không có audit → Tránh: dùng lý do chỉnh sửa/change log (nếu bật).

2) Mô hình tư duy (chính sách → phê duyệt → số dư)

Nghỉ phép là một vòng lặp: chính sách định nghĩa quyền lợi; quy tắc phê duyệt định tuyến yêu cầu; yêu cầu được duyệt sẽ cập nhật số dư. Giữ vòng lặp chặt chẽ để tránh tranh chấp.

1. Tạo hoặc tùy biến chính sách nghỉ phép.
2. Thiết lập chính sách phê duyệt (ai duyệt, thứ tự duyệt).
3. Nhân sự gửi yêu cầu.
4. Người phê duyệt xem xét và quyết định.
5. Số dư cập nhật; admin chỉ điều chỉnh khi thật sự cần.

3) Đối tượng & thuật ngữ

Đây là các thành phần chính được nhắc nhiều trong các bài hướng dẫn chính thức về nghỉ phép.

• Chính sách nghỉ phép: định nghĩa quyền lợi và quy tắc.
• Chính sách phê duyệt: định nghĩa ai có quyền phê duyệt nghỉ phép.
• Yêu cầu: một mục nghỉ phép đã gửi và đang chờ xử lý.
• Số dư: quyền lợi còn lại sau khi sử dụng/điều chỉnh.
• Nghỉ phép cho nhân viên trực tiếp: luồng quản lý nghỉ phép cho direct employees.
• Kỳ vọng nghỉ phép cho contractor: có thể khác; cần xác nhận cách tiếp cận chính sách.

5) Các công việc cốt lõi (JTBD)

Đây là các thao tác lặp lại nhiều nhất của admin/quản lý trong Nghỉ phép.

• Tạo chính sách nghỉ phép tùy biến cho nhân sự.
• Cấu hình các chính sách phê duyệt nghỉ phép.
• Xem xét và quản lý yêu cầu nghỉ phép của nhân viên.
• Quản lý yêu cầu nghỉ phép của direct employees (nếu áp dụng).
• Điều chỉnh số dư nghỉ phép khi cần sửa sai.
• Làm rõ quan điểm/chính sách cho contractor (khi liên quan).

6) Quy trình “happy path” #1 — Thiết lập Nghỉ phép (admin)

Dùng khi bạn bật Nghỉ phép lần đầu và muốn một cấu hình mặc định an toàn.

1. Chọn cách tiếp cận chính sách (chuẩn vs tùy biến).
2. Tạo chính sách nghỉ phép và xác nhận logic quyền lợi.
3. Cấu hình chính sách phê duyệt (quản lý, HR, hoặc cả hai).
4. Xác nhận manager được gán đúng trong People/cấu trúc.
5. Chạy một yêu cầu thử với một nhân sự pilot.
6. Kiểm tra yêu cầu đi đúng tuyến phê duyệt và cập nhật số dư khi được duyệt.

8) Điểm quyết định (A/B)

Các quyết định này kiểm soát mức độ “chặt” của quy trình nghỉ phép.

9) Lỗi thường gặp + guardrails

Sự cố nghỉ phép thường do định tuyến sai hoặc chính sách mơ hồ. Sửa sớm thì mọi thứ dễ hơn.

• Lỗi: định tuyến sai người duyệt → Tránh: kiểm tra manager mapping và chính sách phê duyệt.
• Lỗi: không tài liệu hóa chính sách nội bộ → Tránh: phát hành bản tóm tắt 1 trang.
• Lỗi: điều chỉnh số dư không có bối cảnh → Tránh: ghi rõ lý do nội bộ và truyền thông khi cần.
• Lỗi: bỏ qua yêu cầu bị kẹt → Tránh: rà soát hàng tuần + quy tắc escalation.
• Lỗi: kỳ vọng contractor không rõ → Tránh: quyết định và truyền thông quan điểm.

2) Mô hình tư duy (chương trình + chu kỳ)

Hãy coi Engage là một tập các “chu kỳ”: định nghĩa một chương trình (ví dụ: mục tiêu hoặc khảo sát nhanh), triển khai cho một nhóm, thu thập cập nhật, rồi đánh giá kết quả và cải tiến.

1. Chọn 1 module (Mục tiêu hoặc Khảo sát) để làm pilot.
2. Xác định ai tham gia và ai chịu trách nhiệm follow-up.
3. Chạy một chu kỳ ngắn (2–4 tuần) trước khi mở rộng.
4. Xem kết quả và điều chỉnh câu hỏi/quy trình.

3) Đối tượng & thuật ngữ

Engage được tổ chức theo các mảng con trong điều hướng chính thức. Dùng chúng như “các tab con trong một tab”.

• Mục tiêu (Goals): nhịp đặt mục tiêu và theo dõi.
• Học tập (Learning): chương trình/khu vực theo dõi học tập.
• Lộ trình nghề nghiệp (Career): khu vực lập kế hoạch phát triển nghề nghiệp.
• Khảo sát (Surveys): thu thập phản hồi (pulse/engagement surveys).
• Quản trị Engage & quản lý người dùng: ai có thể tạo/quản lý chương trình.

5) Các công việc cốt lõi (JTBD)

Đây là các việc “thực sự làm gì?” phổ biến nhất khi dùng Engage.

• Khởi chạy một chu kỳ mục tiêu cơ bản cho một team.
• Thu thập phản hồi bằng một khảo sát đơn giản.
• Xác định trọng tâm học tập cho một quý.
• Hỗ trợ trao đổi nghề nghiệp bằng template/quy trình gọn nhẹ.
• Thiết lập ai có quyền quản trị chương trình Engage và ai được tham gia.
• Chạy cadence định kỳ (tháng/quý) với nhắc nhở nhất quán.

6) Quy trình “happy path” #1 — Chạy một chu kỳ khảo sát pilot

Dùng khi bạn muốn bắt đầu Engage theo cách rủi ro thấp và chứng minh giá trị nhanh.

1. Chọn nhóm pilot (một team hoặc một phòng ban).
2. Xác định mục tiêu khảo sát (ví dụ: phản hồi onboarding, pulse hàng tuần).
3. Quyết định ai review kết quả và ai chịu trách nhiệm hành động follow-up.
4. Phát hành khảo sát và đặt hạn chót.
5. Theo dõi tỷ lệ phản hồi và gửi nhắc (nếu quy trình của bạn có hỗ trợ).
6. Xem kết quả và chọn 1–2 hành động để thực hiện.
7. Thông báo kết quả lại cho người tham gia (khép vòng phản hồi).

8) Điểm quyết định (A/B)

Các quyết định này chi phối mức độ áp dụng và “gánh nặng cho quản lý”.

9) Lỗi thường gặp + guardrails

Engage thất bại khi mọi người không thấy kết quả. Giữ vòng phản hồi “khép kín”.

• Lỗi: chạy quá nhiều chương trình → Tránh: mỗi lần chỉ 1 pilot.
• Lỗi: không có owner cho follow-up → Tránh: gán owner hành động trước khi launch.
• Lỗi: thu phản hồi rồi im lặng → Tránh: luôn chia sẻ kết quả.
• Lỗi: quá tải cho quản lý → Tránh: chu kỳ đơn giản, time-box rõ ràng.
• Lỗi: quyền admin không rõ → Tránh: định nghĩa quy tắc quản trị/QL người dùng Engage.

2) Mô hình tư duy (khung → dải lương → chu kỳ)

Một chương trình lương thưởng “ổn” thường bắt đầu từ cấu trúc, rồi mới chạy chu kỳ. Khung vị trí tạo bản đồ role/level; dải lương tạo khoảng; chu kỳ là nơi thực thi quyết định với ngân sách và phê duyệt.

1. Thêm khung vị trí (role/level).
2. Thiết lập dải lương theo role/level đó.
3. Thêm tiền tệ nếu bạn vận hành toàn cầu.
4. Tạo chu kỳ xét lương kèm ngân sách.
5. Gán admin và chạy chu kỳ.

3) Đối tượng & thuật ngữ

Các thuật ngữ này lấy trực tiếp từ tiêu đề bài viết chính thức của phần Compensation và giúp bạn định hướng nhanh tính năng.

• Dải lương (Compensation bands): các khoảng lương có cấu trúc cho role/level.
• Chu kỳ xét lương (Compensation cycles): quy trình review theo kỳ.
• Khung vị trí (Job architectures): khung role/level dùng cho lương.
• Ngân sách (Budgets): các kiểu ngân sách của chu kỳ để kiểm soát chi tiêu.
• Tiền tệ (Currencies): hỗ trợ đa tiền tệ để lập kế hoạch.
• Admin lương thưởng (Compensation admins): quản trị viên quản lý tính năng lương thưởng.

5) Các công việc cốt lõi (JTBD)

Dùng các việc này như kế hoạch triển khai cho chu kỳ xét lương đầu tiên.

• Thêm khung vị trí cho Deel Compensation.
• Thiết lập dải lương.
• Tạo và quản lý các chu kỳ xét lương.
• Chọn kiểu ngân sách cho chu kỳ.
• Thêm tiền tệ cho kế hoạch lương toàn cầu.
• Thêm admin cho Compensation (kiểm soát ai được quản lý chu kỳ).

6) Quy trình “happy path” #1 — Thiết lập nền tảng

Dùng khi bạn chuẩn bị cho chu kỳ đầu tiên và muốn có cấu trúc vững trước khi mời các bên tham gia.

1. Định nghĩa khung vị trí (level, role, family) trong tài liệu nội bộ về lương.
2. Cấu hình khung vị trí trong Deel Compensation.
3. Tạo dải lương tương ứng cho từng level/role.
4. Thêm các tiền tệ bạn dự định dùng trong chu kỳ.
5. Thêm admin lương thưởng (nhóm owner nhỏ).
6. Spot-check: chọn 1 nhân sự mẫu, map vào job/level và band đúng.

8) Điểm quyết định (A/B)

Các quyết định này sẽ quyết định độ phức tạp và tốc độ áp dụng.

9) Lỗi thường gặp + guardrails

Phần lớn vấn đề đến từ cấu trúc yếu hoặc quá nhiều admin. Giữ kỷ luật triển khai.

• Lỗi: chạy chu kỳ trước khi có khung vị trí → Tránh: set khung và dải lương trước.
• Lỗi: phân bậc không nhất quán → Tránh: định nghĩa rule leveling nội bộ.
• Lỗi: quá nhiều admin → Tránh: giữ nhóm owner nhỏ.
• Lỗi: ngân sách không rõ → Tránh: thống nhất kiểu ngân sách và ràng buộc từ đầu.
• Lỗi: rối tiền tệ → Tránh: ghi rõ giả định FX và cách dùng tiền tệ.

2) Mô hình tư duy (intake → sourcing → selection)

Giữ mô hình tư duy đơn giản: mô tả vị trí thật rõ, quyết định nguồn ứng viên, rồi chạy quy trình đánh giá nhất quán. Quá phức tạp sẽ làm chậm tốc độ và giảm chất lượng khi mới áp dụng.

1. Intake vị trí: yêu cầu, tiêu chí bắt buộc, timeline.
2. Sourcing ứng viên: ứng viên đến từ đâu (Deel Talent/partners/kênh khác).
3. Sàng lọc & phỏng vấn: các vòng/stage nhất quán.
4. Offer & bàn giao: chuyển sang onboarding/People.

3) Đối tượng & thuật ngữ

Các thuật ngữ này đến từ danh sách mục trong phần Talent Management chính thức.

• Deel Talent (dành cho Khách hàng): phần tổng quan theo góc nhìn client.
• Deel Talent (dành cho Đối tác nhân tài): phần tổng quan theo góc nhìn partner.
• Tuyển dụng với Deel Talent: điểm vào các hướng dẫn tuyển dụng thực tế.
• Trang FAQ: nơi tra cứu các tình huống và làm rõ điểm dễ hiểu nhầm.

5) Các công việc cốt lõi (JTBD)

Dùng các việc này để lập kế hoạch cho vị trí “thật” đầu tiên tuyển theo luồng này.

• Đọc tổng quan cho khách hàng và thống nhất phạm vi với stakeholders.
• Tạo template intake tuyển dụng (yêu cầu, ngân sách, timeline).
• Chạy thử một quy trình tuyển dụng end-to-end.
• Quyết định dùng tích hợp ATS hay theo dõi thủ công.
• Thiết lập quy tắc phối hợp với partner (nếu dùng).
• Định nghĩa bước bàn giao từ “đã tuyển” sang onboarding trong People.

6) Quy trình “happy path” #1 — Tuyển với Deel Talent (tối giản)

Dùng như một blueprint đơn giản cho 1 vị trí để bạn có thể cải tiến nhanh.

1. Xác nhận yêu cầu vị trí và timeline tuyển.
2. Xem tổng quan Deel Talent (client) để stakeholders hiểu kỳ vọng.
3. Chốt cách sourcing và “ai làm gì” (HR vs manager vs partner).
4. Đặt 2–4 stage pipeline (screen → interview → decision).
5. Sàng lọc ứng viên theo tiêu chí nhất quán.
6. Ra quyết định và ghi lại lý do.
7. Bàn giao ứng viên trúng tuyển sang các bước onboarding trong People.

8) Điểm quyết định (A/B)

Các quyết định này ảnh hưởng tốc độ và tính nhất quán.

9) Lỗi thường gặp + guardrails

Tuyển dụng hay “gãy” khi tốc độ và ownership không rõ.

• Lỗi: intake mơ hồ → Tránh: chốt must-have và timeline.
• Lỗi: quá nhiều vòng từ sớm → Tránh: giữ pipeline gọn.
• Lỗi: phản hồi chậm → Tránh: đặt SLA phản hồi.
• Lỗi: không có bước bàn giao onboarding → Tránh: định nghĩa rõ “hired → People”.
• Lỗi: ranh giới partner không rõ → Tránh: ghi rõ trách nhiệm.

2) Mô hình tư duy (inputs → scenarios → decisions)

Xem hoạch định như một vòng lặp: gom đầu vào, dựng kịch bản, chốt kế hoạch, rồi đối chiếu kết quả. Bắt đầu nhỏ—một phòng ban hoặc một quý.

1. Đầu vào: dữ liệu nhân sự hiện tại, vị trí đang mở, ràng buộc ngân sách.
2. Kịch bản: tuyển mới, backfill, tái cơ cấu, hoặc đóng băng tuyển dụng.
3. Quyết định: phê duyệt kế hoạch và người chịu trách nhiệm.
4. Rà soát: so sánh kế hoạch vs thực tế và lặp lại cải tiến.

3) Đối tượng & thuật ngữ

Phần chính thức có liên kết Workforce Planning với Engage, nên nên thống nhất thuật ngữ giữa hai khu vực này.

• Hoạch định lực lượng lao động: quyết định headcount và cấu trúc theo thời gian.
• Liên kết Engage: hoạch định được nhắc như “with Engage”.
• Đầu vào dữ liệu workforce: thường lấy từ People directory/cấu trúc tổ chức.
• Kịch bản (scenarios): các phương án so sánh để ra quyết định.

5) Các công việc cốt lõi (JTBD)

Dùng các việc này làm backlog triển khai ban đầu.

• Xác định phạm vi (team nào, trong khoảng thời gian nào).
• Xác định owner (HR, finance, business lead).
• Thu thập baseline từ People/cấu trúc tổ chức.
• Tạo 2–3 kịch bản và so sánh tác động.
• Chuyển kế hoạch đã duyệt thành hành động tuyển dụng/onboarding.
• Rà soát kế hoạch vs thực tế hàng tháng và cập nhật.

6) Quy trình “happy path” #1 — Chạy một kế hoạch quý mini

Dùng khi bạn mới áp dụng và muốn có “thắng lợi” đầu tiên an toàn.

1. Chọn 1 phòng ban và 1 quý làm phạm vi pilot.
2. Lấy headcount hiện tại và dữ liệu cấu trúc từ People.
3. Định nghĩa ràng buộc (ngân sách, vai trò trọng yếu, timeline).
4. Tạo 2 kịch bản: baseline vs tăng trưởng (hoặc baseline vs đóng băng).
5. Review kịch bản với stakeholders và chọn 1 kế hoạch.
6. Chuyển kế hoạch thành hành động: role cần tuyển, backfill, thời điểm.
7. Đặt checkpoint rà soát hàng tháng.

8) Điểm quyết định (A/B)

Các lựa chọn này quyết định tốc độ áp dụng và độ chính xác.

9) Lỗi thường gặp + guardrails

Hoạch định thất bại khi giả định bị “ẩn” và không ai sở hữu việc theo sát triển khai.

• Lỗi: phạm vi không rõ → Tránh: chốt team và thời gian thật cụ thể.
• Lỗi: không có owner duy nhất → Tránh: chỉ định 1 người chịu trách nhiệm cuối.
• Lỗi: quá nhiều kịch bản → Tránh: giữ 2–3 kịch bản.
• Lỗi: không review plan-vs-actual → Tránh: checkpoint hàng tháng.
• Lỗi: dữ liệu People không được duy trì → Tránh: gán người “sở hữu dữ liệu People”.

2) Mô hình tư duy (dashboard vs report)

Dashboard dùng để theo dõi liên tục; report dùng để trả lời một câu hỏi cụ thể và dễ chia sẻ/xuất dữ liệu. Bắt đầu với 1 dashboard, rồi thêm 1 report cho mỗi câu hỏi lặp lại.

1. Chọn một câu hỏi hay gặp (vd: “Tình trạng workforce hiện tại?”).
2. Tạo dashboard để giám sát nhanh.
3. Tạo report chi tiết để drill-down.
4. Lưu và chia sẻ với quyền truy cập được kiểm soát.

3) Đối tượng & thuật ngữ

Các thuật ngữ này bám trực tiếp theo bài viết Reports.

• Analytics 2.0: năng lực báo cáo được nhắc trong tài liệu.
• Dashboard: màn hình theo dõi đã lưu.
• Report: truy vấn/màn hình đã lưu có thể chia sẻ.
• Custom report: report do bạn tự thiết kế và chia sẻ.
• Total Payroll Summary Report: báo cáo tổng hợp payroll có thể tải xuống.

5) Các công việc cốt lõi (JTBD)

Các việc này khớp bài viết chính thức và nhu cầu phổ biến lúc mới triển khai.

• Nắm kiến thức cơ bản về Analytics 2.0.
• Tạo và lưu dashboards.
• Tạo và lưu reports.
• Quyết định các loại report bạn cần.
• Tạo và chia sẻ một custom report.
• Xem và tải Total Payroll Summary Report.

6) Quy trình “happy path” #1 — Tạo dashboard đầu tiên

Dùng khi bạn muốn có một nơi duy nhất để theo dõi tín hiệu HR/ops hàng tuần.

1. Mở Analytics 2.0 và chốt mục đích dashboard (ops, payroll, people).
2. Chọn 3–5 chỉ số trả lời câu hỏi tuần của bạn.
3. Tạo dashboard và sắp xếp để nhìn là hiểu.
4. Lưu dashboard với tên rõ ràng và chỉ định owner.
5. Chia sẻ với nhóm tối thiểu cần thiết.
6. Review trong họp tuần và tinh chỉnh.

8) Điểm quyết định (A/B)

Các lựa chọn này ảnh hưởng mức độ tin cậy và chi phí bảo trì.

9) Lỗi thường gặp + guardrails

Đau khổ reporting thường đến từ định nghĩa mơ hồ và “sprawl” quá nhiều báo cáo.

• Lỗi: định nghĩa metric không rõ → Tránh: ghi định nghĩa trong mô tả report.
• Lỗi: quá nhiều dashboard giống nhau → Tránh: chỉ định owner và archive bản trùng.
• Lỗi: chia sẻ dữ liệu nhạy cảm quá rộng → Tránh: chia sẻ theo nguyên tắc least-privilege và kiểm tra role.
• Lỗi: không kiểm chứng → Tránh: spot-check trước khi publish.
• Lỗi: quên nhu cầu payroll summary → Tránh: chuẩn hoá cách tải và lưu trữ bản tổng hợp.

2) Mô hình tư duy (hệ thống + quy tắc đồng bộ)

Mọi tích hợp đều cần quyết định “nguồn sự thật” (source of truth). Hãy chốt hệ thống nào làm chủ từng field, rồi định nghĩa hướng đồng bộ và nhịp đồng bộ.

1. Chọn hệ thống master cho dữ liệu worker cốt lõi.
2. Quyết định Deel sẽ đẩy (push) hay kéo (pull) dữ liệu nào.
3. Định nghĩa ai chịu trách nhiệm khi lỗi và cách đối soát.
4. Rollout theo pilot trước khi mở cho toàn bộ org.

3) Đối tượng & thuật ngữ (nhóm tích hợp)

Các nhóm này được liệt kê trực tiếp dưới Integrations & API trong navigation chính thức.

• Tích hợp HRIS
• Tích hợp ATS (Applicant Tracking System)
• Tích hợp SSO
• Tích hợp SCIM
• Tích hợp SFTP
• Tích hợp Quản lý người dùng
• Tích hợp Kế toán
• Deel API

5) Các công việc cốt lõi (JTBD)

Dùng các việc này làm “kế hoạch triển khai tích hợp”.

• Chọn nhóm tích hợp (HRIS, ATS, SSO, ...).
• Định nghĩa dữ liệu nào sync và sync theo hướng nào.
• Thiết lập identity (SSO/SCIM) để scale quản trị truy cập (nếu cần).
• Kết nối ATS nếu cần đồng bộ pipeline tuyển dụng.
• Dùng SFTP cho luồng dựa trên file nếu bắt buộc.
• Dùng Deel API cho nhu cầu tuỳ biến.

6) Quy trình “happy path” #1 — Kết nối HRIS (pilot)

Dùng khi bạn muốn dữ liệu worker nhất quán giữa các hệ thống.

1. Chọn luồng tích hợp HRIS trong Integrations & API.
2. Chốt source-of-truth cho các field (name, email, manager, ...).
3. Kiểm tra Roles & Permissions để đúng admin có thể cấu hình tích hợp.
4. Pilot với một nhóm worker nhỏ.
5. Kiểm chứng: worker khớp giữa hai hệ thống và quan hệ manager đúng.
6. Ghi tài liệu quy tắc sync và cách xử lý khi lệch dữ liệu.
7. Mở rộng cho phần còn lại của org.

8) Điểm quyết định (A/B)

Các lựa chọn này định hình kiến trúc tích hợp.

9) Lỗi thường gặp + guardrails

Sai lầm tích hợp rất “đắt” vì tạo ra drift âm thầm.

• Lỗi: tích hợp trước khi dọn dữ liệu → Tránh: xử lý duplicates và structure trước.
• Lỗi: source-of-truth mơ hồ → Tránh: ghi rõ ownership theo field.
• Lỗi: cấp quyền admin quá rộng để setup → Tránh: least-privilege và giới hạn thời gian.
• Lỗi: bỏ qua pilot → Tránh: pilot nhóm nhỏ.
• Lỗi: không có owner xử lý lỗi → Tránh: chỉ định ai monitor và fix sync issues.