Rippling

Rippling là nền tảng quản lý nhân sự tất cả trong một (all-in-one): tích hợp HR, payroll, IT và quyền truy cập hệ thống vào một nơi. Giúp doanh nghiệp onboarding/offboarding nhân viên nhanh chóng, trả lương – thuế chuẩn, quản lý thiết bị và ứng dụng, tự động hóa quy trình trên cùng một hệ thống.

Lưu yêu thích

Mã giảm giá

So sánh

Đến trang Rippling

Nền tảng (Workflow Studio, Tích hợp, App Studio, Chính sách, Phân quyền, Phân tích)

Onboarding thân thiện cho người mới, được cấu trúc theo điều hướng sản phẩm chính thức của Rippling.

1) Đọc nhanh + Định hướng

Mục đích / Kết quả

Hiểu cách các mảnh ghép nền tảng của Rippling khớp với nhau để bạn tự động hoá việc lặp lại, kiểm soát quyền truy cập và giữ dữ liệu nhất quán giữa HR/IT/Payroll/Spend.

Dành cho ai + Khi nào nên dùng

Admin thiết lập Rippling lần đầu (hoặc đang dọn một cấu hình bị rối).
Bất kỳ ai xây workflow, chính sách, tích hợp hoặc app tuỳ chỉnh.
Nên đọc tab này trước khi mở rộng sang nhiều module (Payroll, IT, Spend, Global).

Trong điều hướng + Tab liên quan

Vị trí: Khu vực sản phẩm cấp cao: The Rippling Platform → Năng lực lõi (Workflow Studio, Analytics, Policies, Permissions, Integrations, App Studio).
Liên quan: HRIS/Core HR, IT, Payroll, Spend, Security & Data Protection.

3–5 việc bạn sẽ làm nhiều nhất

Chuẩn hoá dữ liệu lõi (nhân sự, cơ cấu tổ chức) để các phần khác tham chiếu được.
Đặt phân quyền trước, rồi mới thêm chính sách và tự động hoá.
Kết nối các tích hợp quan trọng (IdP, kế toán, ATS, expense, …) sớm.
Xây 1–2 workflow để bỏ các khâu bàn giao thủ công (onboarding/offboarding là lý tưởng).
Tạo một dashboard/report gọn nhẹ để xem hàng tuần.

2) Mô hình tư duy / Luồng

Hãy xem Rippling như một lớp dữ liệu dùng chung cộng với các “động cơ” vận hành trên dữ liệu đó: phân quyền quyết định ai làm được gì, chính sách quyết định điều gì nên xảy ra, workflow tự động hoá cách nó xảy ra, và tích hợp/app mở rộng hệ thống.

Xác định các trường “nguồn chuẩn” (thuộc tính nhân sự, phòng ban, địa điểm).
Thiết lập quyền theo vai trò (ai được xem/sửa từng khu vực).
Mã hoá quy tắc thành chính sách (ví dụ: phê duyệt, điều kiện đủ, kiểm soát).
Tự động hoá việc lặp lại bằng workflow (trigger → điều kiện → hành động).
Kết nối hệ thống bên thứ ba qua tích hợp (đồng bộ dữ liệu + hành động).
Dùng phân tích để kiểm chứng kết quả và phát hiện “trôi” (thiếu dữ liệu, ngoại lệ, pending approvals).

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

Đây là các “viên gạch” nền tảng bạn sẽ gặp trong các tab khác.

Workflow Studio: Trình xây workflow theo dữ liệu và sự kiện trong Rippling.

Chính sách (Policy): Bộ quy tắc để đảm bảo cách vận hành (thường dùng cho approvals/controls).

Phân quyền (Permissions): Kiểm soát mức truy cập phù hợp cho từng người/nhóm.

Tích hợp (Integration): Kết nối để đồng bộ dữ liệu hoặc thực thi hành động với app bên thứ ba.

App Studio: Cách no-code để xây app tuỳ chỉnh chạy ngay trong nền tảng.

Phân tích (Analytics): Báo cáo/insight xuyên lực lượng lao động và các hệ thống đã kết nối.

4) Vòng đời (state machine / lifecycle)

Các thành phần nền tảng thường đi theo chu trình: thiết kế → thử nghiệm → rollout → theo dõi.

Vòng đời workflow (thường gặp)

Draft: dựng trigger/step và giới hạn phạm vi nhỏ.
Test: chạy với nhóm nhỏ hoặc dữ liệu sandbox (nếu có thể).
Publish: mở rộng phạm vi và bật notification/approval.
Monitor: theo dõi ngoại lệ, tinh chỉnh điều kiện, cập nhật theo thay đổi tổ chức.

Vòng đời tích hợp (thường gặp)

Connect: xác thực và chọn hướng/phạm vi đồng bộ.
Map: ánh xạ field (phòng ban, địa điểm, chức danh, IDs).
Validate: kiểm tra bản ghi mẫu và các edge case.
Operate: theo dõi lỗi sync và xử lý thay đổi theo thời gian.

5) Các việc cốt lõi (jobs-to-be-done)

Bắt đầu với vài việc “đòn bẩy cao” giúp ích cho mọi team.

Thiết kế mô hình dữ liệu tối thiểu (các field nhân sự bắt buộc và ai sở hữu).
Tạo phân quyền theo vai trò cho admin, manager, nhân viên, finance, IT.
Đặt chính sách nền tảng (phê duyệt, điều kiện đủ, kiểm soát) cho các hành động quan trọng.
Xây workflow onboarding để tự cấp tài khoản/nhiệm vụ.
Kết nối 1–3 tích hợp tác động cao (IdP/SSO, kế toán, ATS/công cụ HR).
Tạo báo cáo sức khoẻ hàng tuần (thiếu field, ngoại lệ, pending approvals).

6) Luồng chuẩn #1

Workflow: dựng tự động hoá “kickoff nhân sự mới” đơn giản để giảm việc nhắc tay.

Xác định trigger: hồ sơ nhân sự mới chuyển sang trạng thái ‘sẵn sàng onboarding’.
Chọn dữ liệu tối thiểu bắt buộc (ngày bắt đầu, quản lý, phòng ban, địa điểm).
Thêm nhánh điều kiện (ví dụ: task khác nhau theo phòng ban/địa điểm).
Tạo task cho HR/IT/Manager với owner và due date rõ ràng.
Thêm thông báo (email/Slack) cho owner khi task được tạo.
Test với 1–2 hồ sơ giả; kiểm tra task + notification chỉ chạy đúng 1 lần.

Kết quả mong đợi: Một kickoff onboarding lặp lại được, tạo đúng task và cảnh báo với ownership nhất quán.

7) Luồng chuẩn #2

Workflow: tạo luồng “yêu cầu thay đổi quyền truy cập” gọn nhẹ (phê duyệt + audit).

Xác định loại yêu cầu (quyền app, đổi role, yêu cầu thiết bị, …).
Tạo form yêu cầu (field: người yêu cầu, người bị tác động, lý do, mức khẩn).
Thiết lập logic phê duyệt (manager duyệt, rồi đến chủ hệ thống/IT duyệt).
Thêm kiểm tra theo policy (chặn nếu thiếu training/thuộc tính bắt buộc).
Sau khi duyệt, route sang bước xử lý (ticket, task, hoặc hành động qua tích hợp).
Ghi nhận hoàn tất và giữ report đơn giản phục vụ audit/review.

Kết quả mong đợi: Yêu cầu trở nên theo dõi được, được phê duyệt và audit được—không phải đuổi theo người khác trong chat.

8) Điểm quyết định

Các lựa chọn này ảnh hưởng mạnh đến khả năng bảo trì về lâu dài.

Quyết định	Nếu A…	Nếu B…
Chủ sở hữu dữ liệu	HR sở hữu dữ liệu nhân sự lõi; khoá quyền sửa về HR/admin.	Chia ownership: HR sở hữu people fields; Finance/IT sở hữu field của họ với phạm vi chặt.
Mô hình phân quyền	Bắt đầu đơn giản: 3–5 vai trò, rồi mở rộng sau.	Bắt đầu chi tiết: nhiều role/group nếu org cần tách biệt nghiêm ngặt từ ngày 1.
Tích hợp	Kết nối ít nhưng “đánh mạnh” trước; ổn định rồi mới thêm.	Kết nối nhiều sớm nếu Rippling là control plane trung tâm (cần governance mạnh).
Phạm vi tự động hoá	Chỉ tự động hoá ‘happy path’ trước; edge case xử lý tay.	Tự động cả edge case (phức tạp hơn; cần monitoring và tinh chỉnh liên tục).

9) Rào chắn: Nên / Không nên & Lỗi hay gặp

Quyết định nền tảng sẽ “lãi kép” theo thời gian—hãy chọn thứ nhàm chán, nhất quán và có review định kỳ.

Nên / Không nên

Nên: xác định một bộ field chuẩn và ghi rõ ai sở hữu từng field.
Nên: dùng phân quyền theo vai trò, rồi thêm policy cho hành động nhạy cảm.
Nên: test workflow/tích hợp trên phạm vi nhỏ trước khi rollout rộng.
Không nên: để ai cũng tự tạo field (sẽ bị trùng và “trôi” chuẩn).
Không nên: hardcode logic phụ thuộc tên dễ vỡ (ưu tiên ID/thuộc tính ổn định).
Không nên: thêm hàng chục tích hợp nếu không có kế hoạch ownership/monitoring.

Lỗi hay gặp + Cách tránh

Xây workflow khi dữ liệu chưa sạch → sửa: bắt đầu bằng required fields + validation.
Phân quyền quá vụn ngay ngày 1 → sửa: bắt đầu thô, rồi tách role khi nhu cầu rõ.
Không theo dõi ngoại lệ → sửa: tạo routine review hàng tuần cho “errors/failed runs”.
Đặt tên không nhất quán (phòng ban/địa điểm) → sửa: chuẩn hoá danh sách và khoá quyền sửa.
Tích hợp sync sai hướng → sửa: quyết định hệ thống nào là nguồn chuẩn cho từng field.

10) “Tốt” trông như thế nào + Checklist

Dùng phần này như checklist “sức khoẻ nền tảng”.

“Tốt” trông như thế nào (mini rubric)

Thuộc tính nhân sự lõi đầy đủ cho >95% nhân sự (phần còn lại có owner xử lý rõ).
Vai trò dễ hiểu và được review hàng quý (không có “admin bí ẩn”).
Workflow có trigger rõ, có owner và có kế hoạch xử lý lỗi.
Tích hợp chính có tài liệu mapping field và được giám sát.
Analytics hiển thị ngoại lệ và thật sự được dùng (không phải dựng xong để đó).

Pre-check (trước khi chạy)

Xác nhận các field bắt buộc có trên bản ghi mục tiêu.
Xác nhận quyền/role đúng cho người test và người phê duyệt.
Kiểm tra policy cho edge case (chuyển bộ phận, contractor, intern).
Đảm bảo xác thực tích hợp chưa hết hạn.
Định nghĩa cách rollback/disable workflow trước khi bật rộng.
Thông báo khung thời gian thay đổi cho admin/team liên quan.

Post-check (sau khi chạy)

Review các lần chạy workflow: thành công, thất bại, và step bị bỏ qua.
Spot-check 3–5 bản ghi để xác nhận dữ liệu và quyền truy cập đúng.
Kiểm tra log sync tích hợp: lỗi hoặc overwrite field ngoài ý muốn.
Xác nhận approver nhận được thông báo và hoàn tất hành động được.
Ghi lại: đã thay đổi gì + ai sở hữu bảo trì về sau.
Đặt nhắc định kỳ để xem lại policy/role theo thay đổi tổ chức.

11) Bài thực hành (5–15 phút) + Link tài liệu chính thức

Thực hành: tạo một workflow nhỏ để gắn tag cho bản ghi và gửi thông báo cho owner (an toàn, dễ hoàn tác).

Chọn một trigger có thể mô phỏng an toàn (ví dụ: thay đổi một field trong hồ sơ).
Tạo field/tag “Test” và áp nó trong action của workflow.
Thêm 1 bước thông báo duy nhất tới bạn (hoặc admin test).
Giới hạn scope cho 1–2 user test.
Chạy 1 lần; kiểm tra tag được áp và bạn nhận được thông báo.
Tắt workflow và xoá tag/field test nếu không cần nữa.

Kiểm chứng bạn làm đúng

Workflow chỉ chạy cho đúng user test đã scope.
Bạn thấy run log với từng bước được đánh dấu hoàn tất.
Không có field không liên quan bị overwrite bởi sync của tích hợp.
Tắt workflow thì các lần chạy về sau dừng ngay.

Phân quyền & Vai trò

Dùng năng lực Permissions để cấp quyền “ít nhất cần thiết” theo vai trò (admin, HR, IT, finance, manager, employee). Bắt đầu ít, rồi tinh chỉnh khi trách nhiệm rõ hơn.

Dữ liệu & Tích hợp

Dùng Integrations để kết nối app bên thứ ba; xem mỗi kết nối như một hạng mục có owner (team chịu trách nhiệm) và theo dõi sức khoẻ sync.

Link tài liệu chính thức (tiêu đề)

Rippling Platform (tổng quan)
Workflow Studio
Integrations
App Studio
Rippling+ → Cổng vào Help Center

HRIS (HR cốt lõi / Hệ thống nguồn dữ liệu chuẩn)

Onboarding thân thiện cho người mới, được cấu trúc theo điều hướng sản phẩm chính thức của Rippling.

1) Đọc nhanh + Định hướng

Mục đích / Kết quả

Thiết lập nền tảng HR: dữ liệu nhân sự chính xác, cơ cấu tổ chức, và đầu vào onboarding/offboarding lặp lại được—đây là thứ các module Rippling khác phụ thuộc vào.

Dành cho ai + Khi nào nên dùng

Admin HR xây “hệ thống ghi nhận chuẩn” cho dữ liệu nhân sự của công ty.
Quản lý cần cơ cấu tổ chức sạch (team, tuyến báo cáo) để phê duyệt chạy trơn tru.
Lead IT/Payroll/Finance cần dữ liệu HR để tự động hoá các việc phía sau.

Trong điều hướng + Tab liên quan

Vị trí: Products → HCM → HRIS.
Liên quan: Platform (Permissions/Policies/Workflows), Payroll, Time & Attendance, IT, Recruiting, Benefits.

3–5 việc bạn sẽ làm nhiều nhất

Chốt các field nhân sự bắt buộc (ngày bắt đầu, quản lý, địa điểm, loại hình làm việc).
Chuẩn hoá danh sách (phòng ban, địa điểm, cấp bậc) trước khi import dữ liệu.
Import/nhập nhân sự và kiểm tra ngẫu nhiên để xác nhận đúng.
Thiết lập intake onboarding để tạo dữ liệu “sạch” cho các bước downstream.
Tạo một góc nhìn org/report đơn giản để bắt lỗi thiếu hoặc không nhất quán.

2) Mô hình tư duy / Luồng

HRIS là “nguồn chuẩn” cho dữ liệu con người và tổ chức. Nếu các field HRIS thiếu hoặc không đồng nhất, workflow, payroll, cấp quyền và báo cáo sẽ bị nhiễu và dễ lỗi.

Xác định mô hình dữ liệu lõi (field + danh sách chuẩn/controlled vocabularies).
Chuyển dữ liệu nhân sự (import hoặc nhập tay) và kiểm tra độ chính xác.
Chốt ownership và quy tắc chỉnh sửa cho từng field (ai được đổi cái gì).
Thiết lập đầu vào onboarding (form/task) để hồ sơ mới “đủ” ngay từ lúc tạo.
Dùng workflow/policy để cưỡng chế quy tắc và giảm dọn dữ liệu thủ công.
Theo dõi chất lượng dữ liệu bằng report/check định kỳ.

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

Các thuật ngữ HRIS cốt lõi bạn sẽ dùng xuyên Rippling.

Hồ sơ nhân viên (Employee record): Profile chuẩn chứa các thuộc tính mà module khác sẽ dùng.

Loại hình làm việc (Employment type): Thường là nhân viên vs contractor; có thể quyết định rule payroll/benefits/cấp quyền.

Cơ cấu tổ chức (Org structure): Team/phòng ban/địa điểm và tuyến báo cáo dùng cho phê duyệt và báo cáo.

Thuộc tính (Attribute): Một field trên hồ sơ nhân viên (vd: vai trò, cấp bậc, cost center).

Intake onboarding: Cách bạn thu thập thông tin bắt buộc trước khi các hành động khác diễn ra.

4) Vòng đời (state machine / lifecycle)

Phần lớn việc trong HRIS bám theo vòng đời nhân sự; hãy làm các chuyển trạng thái rõ ràng.

Vòng đời nhân sự (tổng quan)

Trước ngày vào làm: tạo hồ sơ với ngày bắt đầu dự kiến và thuộc tính vai trò.
Đang làm: duy trì profile khi có thay đổi (vai trò, quản lý, địa điểm).
Sự kiện thay đổi: thăng chức, chuyển bộ phận, nghỉ phép—được theo dõi và kiểm tra.
Offboarding: ghi nhận ngày kết thúc; kích hoạt thu hồi quyền và các bước lương cuối.

5) Các việc cốt lõi (jobs-to-be-done)

Ưu tiên các việc giúp tăng chất lượng dữ liệu và giảm làm lại.

Định nghĩa field bắt buộc và danh sách chuẩn (phòng ban, địa điểm, cấp bậc).
Import nhân sự và xử lý trùng hoặc thiếu field quan trọng.
Tạo intake onboarding nhất quán (ai cung cấp gì, trước thời điểm nào).
Thiết lập tuyến quản lý/cơ cấu báo cáo để hỗ trợ phê duyệt và kiểm soát truy cập.
Chuẩn hoá quy ước đặt tên cho chức danh, team, địa điểm.
Tạo routine review chất lượng dữ liệu định kỳ (hàng tuần hoặc hàng tháng).

6) Luồng chuẩn #1

Workflow: dựng routine “đủ dữ liệu hồ sơ nhân sự mới” (trước khi onboarding bắt đầu).

Chọn bộ field tối thiểu để kích hoạt (ngày bắt đầu, quản lý, địa điểm, loại hình).
Tạo checklist các field còn thiếu theo từng người.
Thông báo cho owner (HR admin hoặc recruiter) khi thiếu bất kỳ field bắt buộc nào.
Chặn bước downstream (vd: cấp quyền truy cập) cho đến khi field đầy đủ.
Thêm bước quản lý xác nhận tuyến báo cáo và phòng ban.
Chạy thử trên nhóm nhỏ các nhân sự sắp vào; ổn rồi mới mở rộng.

Kết quả mong đợi: Hồ sơ nhân sự mới đạt trạng thái ‘sẵn sàng’ với dữ liệu bắt buộc, tránh lỗi dây chuyền phía sau.

7) Luồng chuẩn #2

Workflow: xử lý chuyển nội bộ (phòng ban/quản lý/địa điểm) theo cách có kiểm soát.

Tạo form yêu cầu chuyển (nhân sự, ngày hiệu lực, quản lý/team/địa điểm mới).
Route phê duyệt: quản lý hiện tại → quản lý mới → HR.
Cập nhật thuộc tính nhân sự đúng vào ngày hiệu lực (không đổi ngay lập tức).
Kích hoạt task downstream (review quyền IT, cập nhật payroll/thuế, thay đổi báo cáo).
Thông báo stakeholders (nhân sự, quản lý, payroll, IT) kèm ngày hiệu lực.
Sau ngày hiệu lực: kiểm tra lại quyền truy cập/payroll khớp với thuộc tính mới.

Kết quả mong đợi: Chuyển nội bộ diễn ra đúng ngày hiệu lực, cập nhật đồng bộ giữa các team.

8) Điểm quyết định

Chọn “mẫu hình” giúp HRIS sạch khi bạn mở rộng.

Quyết định	Nếu A…	Nếu B…
Thiết kế field	Giữ field đơn giản và tái dùng được (phòng ban, địa điểm, cấp bậc).	Tạo nhiều custom field nếu cần báo cáo/kiểm soát chặt (cần governance).
Danh sách chuẩn	Dùng picklist khoá cho field quan trọng để tránh lỗi gõ.	Cho phép free-text chỉ với field ít rủi ro (ghi chú, comment nội bộ).
Quản lý thay đổi	Dùng ngày hiệu lực cho thay đổi tổ chức để tránh rối giữa kỳ.	Chỉ áp dụng thay đổi ngay khi quy trình nghiệp vụ bắt buộc.
Ownership	Mỗi field quan trọng có 1 owner (trách nhiệm rõ).	Chia ownership kèm rule (cần quyền rõ và routine audit).

9) Rào chắn: Nên / Không nên & Lỗi hay gặp

Hãy coi HRIS như một cơ sở dữ liệu: đầu vào sạch, chỉnh sửa có kiểm soát, đầu ra dự đoán được.

Nên / Không nên

Nên: chốt hệ thống nào là “nguồn chuẩn” cho từng field trước khi tích hợp.
Nên: chuẩn hoá phòng ban/địa điểm/cấp bậc sớm và khoá quyền sửa.
Nên: dùng phê duyệt/ngày hiệu lực cho thay đổi lớn (quản lý, địa điểm, loại hình).
Không nên: để nhiều team cùng sửa các field quan trọng mà không có ownership rõ.
Không nên: import dữ liệu mà không spot-check đối chiếu với nguồn tin cậy.
Không nên: nhét logic nghiệp vụ vào field dạng free-text (khó tự động hoá và báo cáo).

Lỗi hay gặp + Cách tránh

Thiếu quản lý hoặc địa điểm ở nhân sự mới → sửa: bắt buộc trước khi ‘ready’.
Trùng hồ sơ nhân sự → sửa: dedupe trước khi import; dùng unique ID ổn định.
Tên phòng ban không nhất quán → sửa: picklist có kiểm soát + owner governance.
Đổi thuộc tính giữa kỳ trả lương → sửa: dùng ngày hiệu lực theo chu kỳ.
Không có dấu vết thay đổi → sửa: route thay đổi qua request/approval.

10) “Tốt” trông như thế nào + Checklist

Khi HRIS “khoẻ”, các module khác sẽ dễ đi rõ rệt.

“Tốt” trông như thế nào (mini rubric)

Field bắt buộc đầy đủ cho gần như toàn bộ nhân sự đang active.
Phòng ban/địa điểm nhất quán và thay đổi qua quy trình có kiểm soát.
Chuyển bộ phận/thăng chức dùng ngày hiệu lực và có phê duyệt rõ.
Các team downstream (payroll/IT/finance) tin cậy thuộc tính HRIS để đặt rule.
Báo cáo phát hiện vấn đề chất lượng dữ liệu sớm (trước khi workflow bị gãy).

Pre-check (trước khi chạy)

Xác nhận danh sách chuẩn (phòng ban/địa điểm/cấp bậc) đã chốt tạm thời.
Chuẩn bị file dữ liệu nguồn và quyết định phần nào import vs nhập tay.
Chốt unique identifier và cách xử lý bản ghi trùng.
Định nghĩa ai được chỉnh sửa từng field quan trọng (ownership).
Chọn nhóm pilot nhỏ để validate trước khi import toàn bộ.
Lên kế hoạch “cutover” (khi HRIS trở thành nguồn chuẩn).

Post-check (sau khi chạy)

Spot-check nhân sự ngẫu nhiên đối chiếu nguồn chuẩn (ít nhất 10 người).
Chạy report “thiếu field bắt buộc” và xử lý các khoảng trống.
Xác minh tuyến báo cáo/quản lý cho các team quan trọng.
Đảm bảo các module downstream đang tham chiếu đúng field.
Ghi lại định nghĩa field và owner ở một nơi duy nhất.
Lên lịch audit định kỳ (bắt đầu hàng tháng là ổn).

11) Bài thực hành (5–15 phút) + Link tài liệu chính thức

Thực hành: tạo một mini audit chất lượng dữ liệu cho một team nhỏ (nhanh và an toàn).

Chọn 5–10 nhân sự làm nhóm test.
Chọn 4 field bắt buộc để audit (quản lý, địa điểm, phòng ban, loại hình).
Kiểm tra từng hồ sơ và ghi chú giá trị thiếu/sai.
Sửa giá trị và ghi lại ai đã sửa (trách nhiệm rõ).
Tạo checklist “chất lượng dữ liệu” đơn giản để tái dùng hàng tháng.
Chia sẻ checklist cho các bên sở hữu các field đó.

Kiểm chứng bạn làm đúng

Nhóm test không còn thiếu giá trị ở các field bắt buộc đã chọn.
Danh sách chuẩn khớp với dữ liệu hồ sơ (không có typo/biến thể).
Bạn giải thích được ai sở hữu từng field và cách yêu cầu thay đổi.
Các team downstream xác nhận dữ liệu dùng được cho rule của họ.

Phân quyền & Vai trò

Dùng Permissions để chỉ vai trò phù hợp mới sửa được các field HRIS lõi; bắt đầu theo nguyên tắc “ít nhất cần thiết” và chỉ mở rộng khi thật sự cần.

Dữ liệu & Tích hợp

Nếu đồng bộ từ HRIS/ATS khác, hãy xác định “nguồn chuẩn theo từng field” trước khi kết nối, để tránh overwrite dữ liệu tốt bằng dữ liệu cũ.

Link tài liệu chính thức (tiêu đề)

HRIS (tổng quan sản phẩm)
Rippling Platform (ngữ cảnh permissions/policies/workflows)
Rippling+ → Cổng vào Help Center

Recruiting (Pipeline tuyển dụng & bàn giao cho onboarding)

Onboarding thân thiện cho người mới, được cấu trúc theo điều hướng sản phẩm chính thức của Rippling.

1) Đọc nhanh + Định hướng

Mục đích / Kết quả

Vận hành pipeline tuyển dụng gọn sạch và bàn giao dữ liệu nhân sự mới một cách có cấu trúc sang HRIS để onboarding, cấp phát IT và thiết lập payroll bắt đầu từ đầu vào chính xác.

Dành cho ai + Khi nào nên dùng

Recruiter và hiring manager vận hành pipeline cho các vị trí.
Admin HR cần quy trình bàn giao nhất quán từ ứng viên → hồ sơ nhân viên.
Team muốn giảm các tin nhắn “thiếu thông tin” trong quá trình onboarding.

Trong điều hướng + Tab liên quan

Vị trí: Products → HCM → Recruiting.
Liên quan: HRIS, Platform (Workflows/Permissions), IT (cấp phát), Payroll, Global (nếu tuyển quốc tế).

3–5 việc bạn sẽ làm nhiều nhất

Chuẩn hoá requisition (yêu cầu tuyển dụng) và các field bắt buộc trước khi mở role.
Định nghĩa các stage trong pipeline và tiêu chí “qua stage” (ready nghĩa là gì).
Thu thập thông tin quan trọng cho onboarding trong hoặc ngay sau khi ứng viên nhận offer.
Tự động hoá các việc bàn giao (background check, yêu cầu thiết bị, setup payroll).
Theo dõi nút thắt: ứng viên bị kẹt ở đâu và vì sao.

2) Mô hình tư duy / Luồng

Recruiting là một phễu: requisition → ứng viên → các stage → offer → hire. “Thắng nhanh” cho người mới là dựng bàn giao có thể dự đoán được, để mỗi nhân sự mới vào HRIS với dữ liệu đầy đủ và dùng được.

Mở requisition với yêu cầu vai trò rõ ràng và owner(s).
Đưa ứng viên vào pipeline và thu thập dữ liệu có cấu trúc.
Chuyển ứng viên qua các stage theo tiêu chí đánh giá nhất quán.
Tạo offer và xác nhận ngày bắt đầu + các thông tin onboarding thiết yếu.
Chuyển ứng viên đã nhận thành bản ghi “sẵn sàng cho HRIS” (handoff).
Kích hoạt workflow/task onboarding (IT, payroll, chuẩn bị của quản lý).

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

Các đối tượng trong Recruiting thường “map” khá thẳng sang HRIS sau khi hire.

Requisition (Yêu cầu tuyển dụng): Một yêu cầu đã được duyệt để tuyển cho một vai trò (liên quan headcount + ngân sách).

Pipeline stage (Giai đoạn pipeline): Một bước trong quy trình tuyển (sàng lọc, phỏng vấn, offer, …).

Stage criteria (Tiêu chí qua stage): Điều kiện phải đúng để đẩy ứng viên đi tiếp (tín hiệu + bằng chứng).

Offer (Đề nghị nhận việc): Các điều khoản làm việc—sẽ trở thành đầu vào cho HRIS/payroll.

Handoff packet (Gói bàn giao): Bộ field tối thiểu có cấu trúc cần có để onboarding chạy được.

4) Vòng đời (state machine / lifecycle)

Nếu tài liệu không nêu lifecycle chính thức, dùng lifecycle đơn giản này.

Vòng đời ứng viên (thực dụng)

Lead → Ứng viên active: được đưa vào pipeline của một requisition.
Đang đánh giá: đi qua các stage kèm ghi chú/quyết định.
Offer: đề xuất và thương lượng điều khoản.
Hired / Not hired: ghi nhận kết quả; nếu hired thì chuyển sang onboarding.

5) Các việc cốt lõi (jobs-to-be-done)

Tập trung vào các việc giúp giảm thời gian tuyển và tăng chất lượng bàn giao.

Tạo template requisition tái sử dụng theo phòng ban/nhóm vai trò.
Định nghĩa stage trong pipeline và thông tin bắt buộc ở mỗi stage.
Theo dõi trạng thái ứng viên và đảm bảo vòng phản hồi đúng hạn.
Tạo “handoff packet” đầy đủ cho HRIS (ngày bắt đầu, quản lý, địa điểm, loại hình).
Tự động hoá việc sau-offer (kiểm tra, form, yêu cầu thiết bị, điều kiện trước payroll).
Đo chuyển đổi theo phễu và xác định nút thắt.

6) Luồng chuẩn #1

Workflow: mở một requisition mới với phê duyệt và đầu vào nhất quán.

Dùng template requisition (vai trò, phòng ban, địa điểm, hiring manager).
Xác nhận owner ngân sách/headcount và route phê duyệt tới họ.
Định nghĩa các stage cho requisition này (giữ nhất quán).
Đặt tiêu chí qua stage (cần ghi nhận gì để đi tiếp).
Đăng role và phân công task/owner cho tuyển dụng.
Bắt đầu check-in hàng tuần: sức khoẻ pipeline, blockers, hành động tiếp theo.

Kết quả mong đợi: Requisition mở với phê duyệt, cấu trúc và owner đúng—không mơ hồ.

7) Luồng chuẩn #2

Workflow: chuyển offer đã nhận thành “bàn giao sẵn sàng onboarding”.

Xác nhận ứng viên chấp nhận offer và chốt ngày bắt đầu.
Thu thập các field của handoff packet (quản lý, phòng ban, địa điểm, loại hình làm việc).
Kích hoạt kickoff onboarding: task HR + task quản lý + yêu cầu IT.
Thông báo payroll/finance các đầu vào lương/đãi ngộ cần để setup.
Đặt deadline nội bộ (vd: 3–5 ngày làm việc trước ngày bắt đầu) để hoàn tất.
Chạy kiểm tra đầy đủ lần cuối trước ngày 1.

Kết quả mong đợi: Mỗi nhân sự mới có dữ liệu có cấu trúc để các team downstream xử lý ngay lập tức.

8) Điểm quyết định

Những lựa chọn nhỏ trong tuyển dụng có thể gây đau lớn (hoặc tiết kiệm lớn) ở downstream.

Quyết định	Nếu A…	Nếu B…
Thiết kế pipeline	Dùng pipeline chuẩn giữa các team để nhất quán.	Tuỳ biến pipeline mạnh theo từng role (fit hơn, nhưng tăng overhead vận hành).
Thời điểm thu dữ liệu	Thu thông tin quan trọng cho onboarding ngay lúc nhận offer.	Thu sau (rủi ro: thiếu thông tin làm trễ onboarding).
Phê duyệt	Bắt buộc phê duyệt headcount mới để tránh tuyển “bất ngờ”.	Cho phép mở requisition tự do (nhanh hơn nhưng dễ lệch ngân sách/quy trình).
Tuyển quốc tế	Đi đường Global/EOR sớm nếu tuyển ngoài nước.	Coi như tuyển nội địa rồi chỉnh sau (rủi ro: chậm do compliance).

9) Rào chắn: Nên / Không nên & Lỗi hay gặp

Hệ tuyển dụng tốt nhất là “nhàm chán”: stage nhất quán, ownership rõ, bàn giao sạch.

Nên / Không nên

Nên: chuẩn hoá tên stage và tiêu chí qua stage để báo cáo có ý nghĩa.
Nên: định nghĩa handoff packet và bắt buộc nó cho trạng thái ‘sẵn sàng onboarding’.
Nên: ownership chặt—mỗi ứng viên có “next action” và người chịu trách nhiệm.
Không nên: chuyển ứng viên mà không ghi lại lý do (mất tín hiệu và trách nhiệm).
Không nên: thương lượng offer mà không ghi nhận các điều khoản quan trọng bằng field có cấu trúc.
Không nên: bắt đầu việc onboarding khi chưa chốt ngày bắt đầu và quản lý.

Lỗi hay gặp + Cách tránh

Quá nhiều stage → sửa: gộp stage; chỉ giữ bước tạo quyết định.
Thiếu quản lý/địa điểm khi bàn giao → sửa: bắt buộc trước khi chuyển sang hired.
Không có SLA phản hồi → sửa: chốt thời gian phản hồi mặc định cho feedback phỏng vấn.
Tạo requisition kiểu tuỳ hứng → sửa: template + approvals.
Tuyển quốc tế nhưng xử lý như nội địa → sửa: kéo Global/EOR vào sớm.

10) “Tốt” trông như thế nào + Checklist

Recruiting “tốt” khi pipeline dễ dự đoán và bàn giao đầy đủ.

“Tốt” trông như thế nào (mini rubric)

Mỗi requisition đang mở có owner, phê duyệt và stage rõ ràng.
Ứng viên luôn có bước tiếp theo được lên lịch hoặc quyết định được ghi rõ.
Điều khoản offer được lưu bằng field có cấu trúc, không chỉ nằm trong ghi chú.
Ứng viên hired tạo ra handoff packet đầy đủ sang HRIS.
Cycle time và bottleneck giải thích được bằng dữ liệu thật.

Pre-check (trước khi chạy)

Xác nhận ai phê duyệt headcount mới và họ cần thông tin gì.
Chốt pipeline chuẩn và stage nào bắt buộc có field có cấu trúc.
Tạo checklist handoff packet dùng chung cho recruiting + HR + IT + payroll.
Thống nhất timeline phản hồi phỏng vấn và ownership.
Chốt nơi lưu JD và scorecard (một nguồn duy nhất).
Lên phương án xử lý đường tuyển quốc tế.

Post-check (sau khi chạy)

Review tỷ lệ chuyển đổi theo stage và chọn 1 bottleneck để sửa.
Audit 5 hire gần nhất: field handoff packet có đủ không?
Kiểm tra time-in-stage cho ứng viên bị kẹt và gán next action.
Cập nhật template nếu team cứ lặp lại việc thêm cùng một nhóm “field phụ”.
Canh với data owner của HRIS về bất kỳ field bắt buộc mới nào.
Ghi lại định nghĩa ‘sẵn sàng onboarding’ và enforce nó.

11) Bài thực hành (5–15 phút) + Link tài liệu chính thức

Thực hành: thiết kế handoff packet và test với 1 nhân sự mới gần đây (hoặc mock hire).

Viết bộ field handoff packet tối thiểu (ngày bắt đầu, quản lý, địa điểm, loại hình, chức danh).
Chọn 1 requisition và map mỗi field được thu ở đâu.
Tìm 1 field hay bị thiếu và thêm bước bắt buộc để thu nó.
Chạy kịch bản mock “offer accepted” và điền packet end-to-end.
Nhờ HR/IT/payroll review packet có dùng được không.
Chỉnh packet và chia sẻ checklist cuối cho các hiring manager.

Kiểm chứng bạn làm đúng

Các team downstream xác nhận họ có thể bắt đầu onboarding mà không cần hỏi thêm.
Handoff packet được ghi bằng field có cấu trúc (không chỉ nằm trong note).
Bạn chỉ ra được mỗi field được thu ở bước nào trong quy trình tuyển.
Có “cổng” ‘sẵn sàng onboarding’ để chặn bàn giao thiếu.

Phân quyền & Vai trò

Giới hạn ai được mở requisition, chuyển stage ứng viên và tạo offer bằng quyền theo vai trò để pipeline luôn đáng tin.

Dữ liệu & Tích hợp

Nếu kết nối job board hoặc công cụ ATS bên ngoài, hãy chốt hệ thống nào là nguồn chuẩn cho trạng thái ứng viên và điều khoản offer để tránh trùng lặp.

Link tài liệu chính thức (tiêu đề)

Recruiting (tổng quan sản phẩm)
HRIS (điểm đến bàn giao)
Rippling+ → Cổng vào Help Center

Benefits Administration (Quản trị phúc lợi & bối cảnh PEO)

Onboarding thân thiện cho người mới, được cấu trúc theo điều hướng sản phẩm chính thức của Rippling.

1) Đọc nhanh + Định hướng

Mục đích / Kết quả

Thiết lập phúc lợi theo cách có kiểm soát để dữ liệu đăng ký (enrollment) luôn chính xác và các thay đổi (nhân sự mới, sự kiện đời sống) chạy trơn tru, không biến thành “mớ Excel” thủ công.

Dành cho ai + Khi nào nên dùng

Admin HR/People Ops quản lý đăng ký bảo hiểm y tế và các phúc lợi khác.
Team chuẩn bị open enrollment hoặc onboarding có quy tắc đủ điều kiện phúc lợi.
Nếu công ty dùng PEO, tab này giúp bạn định hình các điểm cần kiểm tra/đối soát trong cấu hình.

Trong điều hướng + Tab liên quan

Vị trí: Products → HCM → Benefits Administration (PEO thường xuất hiện như một sản phẩm HCM riêng trong điều hướng Rippling).
Liên quan: HRIS (thuộc tính đủ điều kiện), Payroll (khấu trừ), Platform (policies/workflows), Global Benefits (nếu vận hành đa quốc gia).

3–5 việc bạn sẽ làm nhiều nhất

Xác định quy tắc đủ điều kiện (ai được gì, khi nào).
Chuẩn bị thông tin gói phúc lợi và các “cửa sổ” đăng ký (open enrollment + đăng ký cho nhân sự mới).
Đặt workflow chuẩn cho sự kiện đời sống đủ điều kiện (qualifying life events) và thay đổi giữa năm.
Kiểm tra mapping khấu trừ payroll (phúc lợi ↔ payroll) trước khi go-live.
Chạy pilot nhỏ (hoặc dry run) trước open enrollment toàn công ty.

2) Mô hình tư duy / Luồng

Quản trị phúc lợi là tập hợp các “cửa sổ thời gian” và các “sự kiện thay đổi”. Bạn quản lý: (1) đủ điều kiện, (2) lựa chọn gói, (3) lựa chọn đăng ký của nhân viên, và (4) khấu trừ payroll/thuế—tất cả phải khớp nhau.

Xác nhận các thuộc tính HRIS quyết định đủ điều kiện (địa điểm, loại hình, số giờ).
Thiết lập các lựa chọn gói và ai đủ điều kiện cho từng lựa chọn.
Định nghĩa các cửa sổ đăng ký và hành động bắt buộc của nhân viên.
Thu thập lựa chọn (elections) và kiểm tra tính đầy đủ (người phụ thuộc, từ chối, …).
Đồng bộ khấu trừ và xác minh payroll phản ánh đúng lựa chọn.
Xử lý các sự kiện thay đổi (nhân sự mới, life events) bằng một quy trình nhất quán.

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

Giữ các thuật ngữ này nhất quán khi truyền thông và làm báo cáo.

Eligibility (Đủ điều kiện): Quy tắc xác định ai được đăng ký (thường dựa trên thuộc tính HRIS).

Open enrollment (Mở đăng ký): Khoảng thời gian nhân viên có thể thay đổi lựa chọn.

Election (Lựa chọn): Lựa chọn phúc lợi của nhân viên (gói + mức coverage).

Qualifying life event (Sự kiện đời sống đủ điều kiện): Thay đổi cho phép cập nhật lựa chọn giữa năm theo quy định.

Deduction mapping (Mapping khấu trừ): Cách “election” được chuyển thành khoản khấu trừ trong payroll.

4) Vòng đời (state machine / lifecycle)

Phúc lợi vốn dĩ vận hành theo vòng đời (cửa sổ + sự kiện).

Vòng đời phúc lợi (thực dụng)

Setup: định nghĩa gói và quy tắc đủ điều kiện.
Cửa sổ đăng ký: nhân viên chọn (hoặc từ chối) phúc lợi.
Ngày hiệu lực: lựa chọn có hiệu lực; khấu trừ phải khớp.
Sự kiện thay đổi: xử lý đăng ký cho nhân sự mới / life events.

5) Các việc cốt lõi (jobs-to-be-done)

Ưu tiên các việc giúp tránh “bất ngờ” ở payroll.

Định nghĩa eligibility bằng thuộc tính HRIS ổn định (tránh logic dựa vào free-text).
Công bố lựa chọn gói và hướng dẫn đăng ký rõ ràng.
Chạy open enrollment với nhắc nhở và theo dõi hoàn tất.
Xử lý đăng ký cho nhân sự mới theo lịch đều đặn, dễ đoán.
Xử lý thay đổi giữa năm qua workflow “event” nhất quán.
Đối soát khấu trừ payroll trước và sau ngày hiệu lực.

6) Luồng chuẩn #1

Workflow: chạy open enrollment như một “chiến dịch” có cấu trúc (không phải chạy nước rút).

Chốt eligibility và lựa chọn gói trước khi công bố ngày.
Đặt ngày mở/đóng cửa sổ đăng ký và truyền thông kỳ vọng tới nhân viên.
Mở đăng ký và gửi nhắc nhở cho người chưa hoàn tất.
Tạo kênh hỗ trợ/office hours để hỏi đáp (giữ một “nguồn chuẩn” duy nhất).
Đóng cửa sổ và chạy kiểm tra đầy đủ (thiếu election/waiver).
Đối soát mapping khấu trừ payroll bằng một nhóm mẫu trước ngày hiệu lực.

Kết quả mong đợi: Mọi người hoàn tất đúng hạn và lựa chọn sẵn sàng để payroll phản ánh chính xác.

7) Luồng chuẩn #2

Workflow: xử lý “qualifying life event” (thay đổi giữa năm) có rào chắn.

Nhân viên gửi yêu cầu sự kiện kèm loại sự kiện và ngày xảy ra.
Thu thập giấy tờ cần thiết (nếu chính sách yêu cầu).
Duyệt/từ chối dựa trên quy tắc đủ điều kiện và thời hạn.
Mở một cửa sổ thay đổi giới hạn chỉ cho nhân viên đó.
Cập nhật lựa chọn và xác nhận ngày hiệu lực của thay đổi.
Kiểm tra payroll kỳ gần nhất phản ánh đúng khấu trừ mới.

Kết quả mong đợi: Thay đổi giữa năm được xử lý nhất quán, có dấu vết audit và tác động payroll đúng.

8) Điểm quyết định

Các quyết định này sẽ quyết định mùa phúc lợi “nhẹ nhàng” hay “hỗn loạn”.

Quyết định	Nếu A…	Nếu B…
Quy tắc đủ điều kiện	Dùng thuộc tính HRIS ổn định; giữ quy tắc đơn giản.	Quy tắc phức tạp với nhiều edge case (cần governance dữ liệu mạnh).
Trách nhiệm đăng ký	Bắt buộc mỗi người đủ điều kiện phải chọn hoặc từ chối (waive) rõ ràng.	Cho phép mặc định im lặng (nhanh hơn nhưng rủi ro tranh chấp cao).
Sự kiện thay đổi	Tập trung qua workflow yêu cầu + phê duyệt.	Cho phép thay đổi tuỳ hứng qua email (không scale, khó audit).
PEO vs không PEO	Nếu dùng PEO: xác nhận quy trình/bản ghi nằm ở đâu, ai chịu trách nhiệm.	Nếu không dùng PEO: giữ toàn quyền vận hành enrollment và khấu trừ nội bộ.

9) Rào chắn: Nên / Không nên & Lỗi hay gặp

Sai sót phúc lợi thường “lộ” ra bằng lỗi payroll hoặc mất niềm tin của nhân viên—hãy chặn từ sớm.

Nên / Không nên

Nên: canh chỉnh các field đủ điều kiện trong HRIS trước khi cấu hình rules phúc lợi.
Nên: chạy dry run cho truyền thông open enrollment và các bước kiểm tra.
Nên: kiểm tra mẫu khấu trừ sau khi election có hiệu lực.
Không nên: đổi lựa chọn gói giữa cửa sổ mà không truyền thông lại rõ ràng.
Không nên: xử lý life events mà không có quy trình yêu cầu/audit nhất quán.
Không nên: để nhiều nguồn sự thật cùng tồn tại (Excel + hệ thống + email).

Lỗi hay gặp + Cách tránh

Field đủ điều kiện thiếu → sửa: bắt buộc và validate thuộc tính HRIS trước.
Nhân viên quên waive/đăng ký → sửa: nhắc nhở + theo dõi hoàn tất + deadline rõ.
Khấu trừ sai ở kỳ payroll đầu tiên → sửa: chạy kiểm tra sample trước ngày hiệu lực.
Life events xử lý không nhất quán → sửa: chuẩn hoá yêu cầu + phê duyệt.
Trách nhiệm PEO mơ hồ → sửa: viết 1 trang RACI (ai làm gì) trước go-live.

10) “Tốt” trông như thế nào + Checklist

Phúc lợi “tốt” khi nhân viên đăng ký dễ và payroll luôn khớp với lựa chọn.

“Tốt” trông như thế nào (mini rubric)

Eligibility giải thích được và dựa trên thuộc tính HRIS ổn định.
Mỗi nhân viên đủ điều kiện có election hoặc waiver rõ ràng.
Ngày hiệu lực rõ và khấu trừ payroll khớp.
Life events xử lý theo quy trình lặp lại được và có audit trail.
Câu hỏi hỗ trợ giảm vì hướng dẫn và timeline nhất quán.

Pre-check (trước khi chạy)

Xác nhận các thuộc tính HRIS dùng cho eligibility đầy đủ và có kiểm soát.
Thu thập chi tiết gói và định nghĩa cửa sổ đăng ký + deadline.
Chốt cách nhân viên nhận hỗ trợ (một kênh duy nhất + office hours).
Định nghĩa quy trình yêu cầu và phê duyệt life-event.
Chốt cách mapping khấu trừ payroll và ai chịu trách nhiệm.
Nếu có thể: pilot nhóm nhỏ (hoặc dry run).

Post-check (sau khi chạy)

Chạy kiểm tra đầy đủ: thiếu election/waiver, thiếu thông tin dependents.
Kiểm tra mẫu khấu trừ payroll cho một nhóm nhân viên.
Ghi lại câu hỏi phổ biến và cập nhật hướng dẫn cho kỳ sau.
Review thời gian xử lý life events và tinh chỉnh quy trình.
Xác nhận roles/permissions đúng (ai được sửa plan/elections).
Làm retrospective sau kỳ payroll đầu tiên có hiệu lực.

11) Bài thực hành (5–15 phút) + Link tài liệu chính thức

Thực hành: chạy audit “benefits readiness” mini cho 10 nhân viên trước open enrollment.

Chọn 10 nhân viên ở nhiều địa điểm/loại hình khác nhau (để test eligibility).
Kiểm tra mỗi người có đủ field eligibility trong HRIS chưa.
Mô phỏng mỗi người sẽ thấy gói nào (viết ra kết quả kỳ vọng).
Tìm mismatch và sửa thuộc tính HRIS hoặc rule gây ra.
Viết 1 trang checklist cho ngày mở open enrollment.
Chia sẻ checklist cho stakeholders HR + payroll.

Kiểm chứng bạn làm đúng

Với mỗi người test, bạn giải thích được vì sao họ đủ điều kiện (hoặc không).
Không có người test nào thiếu thuộc tính HRIS cần cho eligibility.
Bạn có checklist launch và owner cho bước đối soát khấu trừ payroll.
Bạn mô tả được workflow life-event trong 30 giây cho một quản lý.

Phân quyền & Vai trò

Nếu môi trường có PEO hoặc yêu cầu truy cập phúc lợi chặt, dùng Permissions để chỉ đúng vai trò HR được cấu hình plan và quản lý thay đổi.

Dữ liệu & Tích hợp

Phúc lợi thường phụ thuộc khấu trừ payroll; hãy chốt owner và bước đối soát cho mọi sync/mapping giữa lựa chọn phúc lợi và kỳ payroll. (Chi tiết có thể khác theo cấu hình.)

Link tài liệu chính thức (tiêu đề)

Benefits Administration (tổng quan sản phẩm)
Điều hướng Rippling hiển thị Benefits Administration + PEO
Rippling+ → Cổng vào Help Center

Time & Attendance (Chấm công → duyệt → sẵn sàng cho payroll)

Onboarding thân thiện cho người mới, được cấu trúc theo điều hướng sản phẩm chính thức của Rippling.

1) Đọc nhanh + Định hướng

Mục đích / Kết quả

Ghi nhận thời gian làm việc nhất quán, duyệt đúng luồng và tạo dữ liệu chấm công “sẵn sàng cho payroll” (để không phải dí quản lý hay sửa timesheet sát giờ chốt lương).

Dành cho ai + Khi nào nên dùng

Admin HR/payroll điều phối thu thập thời gian và duyệt chấm công.
Quản lý duyệt thời gian cho team.
Ops cần dữ liệu lao động đáng tin (giờ làm, tăng ca, mã công việc/job codes).

Trong điều hướng + Tab liên quan

Vị trí: Products → HCM → Time & Attendance.
Liên quan: Payroll (chi trả), Platform (policies/phê duyệt), Scheduling (nếu dùng), HRIS (đủ điều kiện và loại lao động).

3–5 việc bạn sẽ làm nhiều nhất

Xác định ai cần chấm công và các quy tắc áp dụng (theo giờ vs lương tháng, tăng ca, nghỉ giữa ca).
Chọn chu kỳ chấm công và lịch “cutoff/chốt kỳ” chuẩn.
Thiết lập luồng duyệt (quản lý, trưởng bộ phận) và deadline.
Chạy kiểm tra trước payroll để bắt thiếu/sai bất thường.
Đồng bộ giờ đã duyệt sang payroll và xác minh chi trả khớp kỳ vọng.

2) Mô hình tư duy / Luồng

Chấm công là một “pipeline”: ghi nhận → kiểm tra → duyệt → đẩy sang payroll. Nếu hỏng ở đầu (ghi nhận/kiểm tra), hậu quả sẽ bùng ở lúc chốt payroll.

Định nghĩa time policies (ai chấm công, quy tắc, kỳ vọng làm tròn/giờ nghỉ).
Thu thập time entries (chấm vào/ra hoặc nộp timesheet).
Kiểm tra hợp lệ (thiếu ca, chồng lấn, ngoại lệ bất thường).
Chạy luồng duyệt (quản lý duyệt trước deadline).
Khoá kỳ và đánh dấu “payroll-ready”.
Gửi giờ đã duyệt sang payroll và đối soát chi trả.

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

Các thuật ngữ này giúp bạn giải thích quy trình cho quản lý và nhân viên.

Time entry (Bản ghi thời gian): Đơn vị thời gian làm việc được ghi lại (chấm vào/ra hoặc nhập tay).

Timesheet (Bảng công): Tập hợp các time entries của một kỳ trả lương.

Approval cutoff (Hạn duyệt): Deadline quản lý phải duyệt bảng công.

Time policy (Chính sách chấm công): Quy tắc về cách ghi nhận và duyệt thời gian.

Payroll-ready (Sẵn sàng cho payroll): Dữ liệu thời gian đã duyệt và khoá, đủ điều kiện để xử lý payroll.

4) Vòng đời (state machine / lifecycle)

Chấm công lặp theo chu kỳ khớp với kỳ payroll.

Vòng đời một kỳ chấm công

Open (Mở): nhân viên nộp công cho kỳ hiện tại.
Pending approval (Chờ duyệt): kỳ kết thúc; quản lý review và duyệt.
Locked (Khoá): duyệt xong; hạn chế sửa, chỉ xử lý qua ngoại lệ.
Exported (Đã xuất): giờ đã duyệt được gửi sang payroll; kỳ được lưu để audit.

5) Các việc cốt lõi (jobs-to-be-done)

Tập trung vào việc tránh “cháy” lúc chốt payroll.

Thiết lập time policies và truyền thông rõ cho nhân viên/quản lý.
Thu thập công nhất quán và giảm sửa tay.
Điều phối duyệt với deadline rõ và nhắc nhở.
Bắt ngoại lệ sớm (thiếu công, bất thường, chồng lấn).
Tạo dữ liệu payroll-ready và đối soát với số giờ kỳ vọng.
Duy trì audit trail cho mọi thay đổi và phê duyệt.

6) Luồng chuẩn #1

Workflow: thu thập và duyệt công theo tuần (đơn giản, lặp lại được).

Nhắc chính sách tuần (deadline + kỳ vọng).
Nhân viên nộp công trước ngày/giờ cố định (vd: cuối ca cuối cùng hoặc cutoff tuần).
Hệ thống gắn cờ timesheet thiếu và nhắc nhân viên sớm.
Quản lý duyệt hoặc yêu cầu chỉnh sửa trước hạn duyệt (approval cutoff).
Chạy báo cáo ngoại lệ cuối (thiếu duyệt, bất thường) trước khi khoá.
Khoá tuần và đánh dấu payroll-ready.

Kết quả mong đợi: Công đã duyệt và khoá cho kỳ, ít phải sửa phút chót.

7) Luồng chuẩn #2

Workflow: xử lý chỉnh công sau khi khoá (luồng ngoại lệ).

Nhân viên gửi yêu cầu chỉnh sửa kèm ngày/giờ và lý do.
Quản lý review và duyệt/từ chối yêu cầu chỉnh công.
Admin chỉ mở khoá đúng phần cần thiết (hoặc tạo một bút toán điều chỉnh).
Áp dụng chỉnh sửa kèm ghi chú/audit trail.
Quản lý duyệt lại bản ghi cập nhật nếu policy yêu cầu.
Cập nhật đối soát payroll và lưu lại thay đổi.

Kết quả mong đợi: Chỉnh sửa có kiểm soát, audit được, không âm thầm làm lệch lịch sử payroll.

8) Điểm quyết định

Chọn cách phù hợp nhất với thực tế vận hành.

Quyết định	Nếu A…	Nếu B…
Cách ghi nhận thời gian	Dùng chấm vào/ra cho nhân sự theo giờ/ca.	Dùng timesheet nhập tay cho khối tri thức (kèm quy tắc kiểm tra).
Luồng duyệt	Một cấp duyệt bởi quản lý để nhanh.	Nhiều cấp duyệt cho môi trường cần kiểm soát chặt (chậm hơn nhưng nghiêm hơn).
Chính sách khoá	Khoá kỳ sau khi duyệt để bảo vệ tính toàn vẹn payroll.	Để kỳ luôn sửa được (ít bước admin hơn, rủi ro “sửa âm thầm” cao).
Xử lý ngoại lệ	Dùng quy trình yêu cầu chỉnh sửa chính thức.	Cho phép sửa tuỳ hứng (nhanh nhưng audit kém).

9) Rào chắn: Nên / Không nên & Lỗi hay gặp

Dữ liệu chấm công = tiền — hãy bảo vệ bằng vài kiểm soát đơn giản.

Nên / Không nên

Nên: đặt cutoff nộp công và cutoff duyệt rõ ràng, nhắc từ sớm.
Nên: chạy kiểm tra ngoại lệ trước khi chốt payroll (thiếu công, bất thường).
Nên: khoá kỳ đã duyệt để tránh thay đổi âm thầm.
Không nên: duyệt công mà không spot-check các bất thường hiển nhiên.
Không nên: đổi policy giữa kỳ mà không có truyền thông và kế hoạch chuyển tiếp.
Không nên: dựa vào Excel để track ngoại lệ khi đã scale.

Lỗi hay gặp + Cách tránh

Quản lý duyệt trễ → sửa: nhắc nhở + escalations sau cutoff.
Nhân viên nộp công thiếu → sửa: validation checks + nhắc sớm.
Không có đường chỉnh sửa rõ → sửa: flow yêu cầu chỉnh công chính thức.
Bỏ sót outliers (giờ cực lớn) → sửa: ngưỡng ngoại lệ và báo cáo.
Không đối soát sang payroll → sửa: quy trình reconciliation sau khi export.

10) “Tốt” trông như thế nào + Checklist

Bạn sẽ biết nó chạy ổn khi payroll không còn là “chữa cháy”.

“Tốt” trông như thế nào (mini rubric)

Deadline nộp và duyệt đạt phần lớn các kỳ.
Ngoại lệ được bắt trước cutoff payroll, không phải sau khi đã trả.
Kỳ khoá ổn định (chỉ thay đổi qua chỉnh sửa có kiểm soát).
Quản lý hiểu mình đang duyệt gì và vì sao quan trọng.
Chi trả payroll khớp giờ đã duyệt với rất ít điều chỉnh.

Pre-check (trước khi chạy)

Xác định nhóm nào phải chấm công và policy áp dụng cho từng nhóm.
Thiết lập lịch kỳ công, hạn nộp và hạn duyệt.
Training quản lý cách review và các điểm cần gắn cờ.
Đặt ngưỡng ngoại lệ (thiếu công, >X giờ/ngày, chồng lấn).
Chốt quy tắc khoá/chỉnh sửa và truyền thông rõ.
Nếu cần: căn time categories khớp earning codes của payroll.

Post-check (sau khi chạy)

Review tỷ lệ hoàn tất (đã nộp vs thiếu) và follow-up.
Review duyệt trễ và tinh chỉnh logic escalations.
Spot-check một mẫu timesheet đã duyệt để bắt bất thường.
Xác nhận export sang payroll thành công và tổng số đối soát khớp.
Ghi lại các chỉnh sửa sau khi khoá và lý do.
Cập nhật tài liệu training theo các lỗi lặp lại.

11) Bài thực hành (5–15 phút) + Link tài liệu chính thức

Thực hành: tạo checklist ngoại lệ và chạy nó trên một kỳ công (thật hoặc test).

Chọn một kỳ payroll gần đây (hoặc một nhóm test nhỏ).
Liệt kê 5 rule ngoại lệ (thiếu nộp, thiếu duyệt, >12h/ngày, chồng lấn, làm cuối tuần).
Kiểm tra ai vi phạm rule nào và vì sao.
Chốt hành động cho từng loại ngoại lệ (sửa, duyệt kèm note, từ chối).
Chạy lại checklist sau khi sửa để xác nhận ngoại lệ giảm.
Lưu checklist và đưa vào bước chuẩn trước khi chốt payroll.

Kiểm chứng bạn làm đúng

Bạn bắt và xử lý được ngoại lệ phổ biến trước cutoff payroll.
Quản lý hiểu bất thường nào cần escalations vs có thể duyệt.
Kỳ khoá giữ ổn định trừ khi có chỉnh sửa có ghi nhận.
Tổng giờ đã duyệt đối soát khớp với kỳ vọng chi trả của payroll.

Phân quyền & Vai trò

Giới hạn ai được sửa kỳ đã khoá hoặc duyệt công; phạm vi duyệt của quản lý nên khớp với cấu trúc báo cáo. (Thiết kế role cụ thể tuỳ tổ chức.)

Dữ liệu & Tích hợp

Time & Attendance thường đổ sang Payroll; hãy đối soát mapping và tổng số trước chu kỳ payroll live đầu tiên.

Link tài liệu chính thức (tiêu đề)

Time & Attendance (tổng quan sản phẩm)
Payroll (đích chi trả)
Rippling+ → Cổng vào Help Center

IT (Danh tính & Truy cập, Quản lý thiết bị, Kho thiết bị)

Onboarding thân thiện cho người mới, được cấu trúc theo điều hướng sản phẩm chính thức của Rippling.

1) Đọc nhanh + Định hướng

Mục đích / Kết quả

Quản lý toàn bộ vòng đời người dùng + thiết bị — cấp quyền nhanh khi nhân sự vào, siết bảo mật mặc định, và thu hồi quyền gọn gàng khi họ rời đi.

Dành cho ai + Khi nào nên dùng

Admin IT xử lý danh tính, quyền truy cập ứng dụng, thiết bị và bảo mật khi offboarding.
Admin HR phối hợp onboarding/offboarding với các việc IT.
Team ưu tiên bảo mật cần “vệ sinh truy cập” và quan sát tình trạng tuân thủ của thiết bị.

Trong điều hướng + Tab liên quan

Vị trí: Products → IT → Identity & Access / Device Management / Inventory Management.
Liên quan: Platform (Workflows, Policies, Permissions, Integrations), HRIS (sự kiện vào/ra), Security & Data Protection.

3–5 việc bạn sẽ làm nhiều nhất

Định nghĩa nhóm quyền theo vai trò/phòng ban và map ứng dụng vào từng nhóm.
Thiết lập tự động hoá onboarding: tài khoản + yêu cầu thiết bị + các bước bảo mật nền.
Tập trung hoá kho thiết bị và các bước vòng đời (gán, gửi, thu hồi).
Tạo checklist offboarding để gỡ quyền và thu thiết bị đúng hạn.
Chạy review “vệ sinh truy cập” hằng tuần (tài khoản cũ, quyền đặc quyền).

2) Mô hình tư duy / Luồng

IT trong Rippling là một “động cơ vòng đời”: dùng thuộc tính HRIS (người này là ai) để cấp quyền ứng dụng và quản lý thiết bị. Mục tiêu là onboarding nhanh nhưng có rào chắn—và offboarding sạch, giảm rủi ro tối đa.

Định nghĩa mô hình danh tính & truy cập (roles/groups → apps/permissions).
Kết nối các ứng dụng quan trọng và nhà cung cấp danh tính qua integrations.
Chuẩn hoá thiết bị (model, policy) và theo dõi tồn kho.
Tự động hoá onboarding: tạo tài khoản, gán group, yêu cầu/gán thiết bị.
Tự động hoá offboarding: khoá tài khoản, thu hồi quyền, thu hồi thiết bị.
Giám sát trạng thái: vệ sinh truy cập, tuân thủ thiết bị và các ngoại lệ.

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

Các thuật ngữ này giúp HR, IT và bảo mật dùng chung một “ngôn ngữ”.

Identity (Danh tính): Tài khoản người dùng đại diện cho nhân viên/CTV trong các hệ thống.

Access group (Nhóm quyền): Gói quyền truy cập ứng dụng theo vai trò hoặc theo team.

Provisioning (Cấp quyền/tạo tài khoản): Tự động tạo account và cấp quyền truy cập.

Deprovisioning (Thu hồi quyền): Gỡ quyền khi ai đó đổi vai trò hoặc rời công ty.

Device lifecycle (Vòng đời thiết bị): Gán → quản lý → bảo mật → thu hồi/thanh lý.

4) Vòng đời (state machine / lifecycle)

Phần lớn vận hành IT map theo sự kiện vào/đổi/ra.

Vòng đời user + thiết bị (thực tế)

Join (Vào): tạo tài khoản, gán access groups, cấp thiết bị.
Change (Thay đổi): chỉnh quyền khi đổi vai trò/phòng ban/địa điểm.
Leave (Rời): thu hồi quyền, vô hiệu hoá tài khoản, thu hồi thiết bị.
Inventory (Kho): theo dõi gán thiết bị, tình trạng tuân thủ và vòng đời/khấu hao.

5) Các việc cốt lõi (jobs-to-be-done)

Bắt đầu từ các việc giúp giảm rủi ro bảo mật và giảm ticket thủ công.

Tạo access groups cho các vai trò phổ biến và map ứng dụng cần thiết vào từng group.
Kết nối các ứng dụng quan trọng để provisioning tự động.
Chuẩn hoá tồn kho thiết bị và quy trình gán thiết bị.
Tự động hoá onboarding: cấp quyền + yêu cầu thiết bị + routing tasks.
Tự động hoá offboarding: gỡ quyền ngay + các bước thu hồi thiết bị.
Chạy kiểm tra vệ sinh truy cập và “posture” thiết bị theo lịch.

6) Luồng chuẩn #1

Workflow: onboarding tự động (tài khoản + quyền + thiết bị).

Đảm bảo HRIS có đủ trường onboarding bắt buộc (ngày bắt đầu, vai trò, phòng ban, quản lý).
Map vai trò/phòng ban vào một access group (gói apps + permissions).
Kích hoạt provisioning tại một điểm nhất quán (vd: khi đạt trạng thái ‘ready-to-onboard’).
Tạo tasks: yêu cầu/gán thiết bị và các bước setup bắt buộc.
Thông báo cho quản lý checklist ngày-1 (nhân viên cần gì).
Xác minh quyền truy cập hoạt động bằng checklist test (các app quan trọng).

Kết quả mong đợi: Nhân sự mới có đúng quyền và quy trình thiết bị đã chạy—không còn “ping-pong ticket” thủ công.

7) Luồng chuẩn #2

Workflow: offboarding an toàn (gỡ quyền trước, thu tài sản sau).

Ghi nhận ngày kết thúc và xác định các hệ thống có quyền đặc quyền.
Gỡ access groups và vô hiệu hoá tài khoản đúng ngày/giờ kết thúc.
Hủy phiên đăng nhập và gỡ truy cập ứng dụng (nếu integrations hỗ trợ).
Tạo tasks thu hồi thiết bị kèm hướng dẫn gửi/hoàn trả và người phụ trách.
Thông báo trạng thái hoàn tất cho các bên liên quan (quản lý, HR, security).
Chạy audit sau offboarding: xác nhận không còn quyền truy cập đang hoạt động.

Kết quả mong đợi: Quyền được gỡ kịp thời, tài sản được theo dõi, và bạn có thể chứng minh offboarding đã hoàn tất.

8) Điểm quyết định

Chốt rõ các lựa chọn này để onboarding/offboarding luôn dự đoán được.

Quyết định	Nếu A…	Nếu B…
Chiến lược group	Group theo vai trò (đơn giản, dễ scale).	Cấp quyền theo từng app (linh hoạt, nhưng tốn công quản trị).
Thời điểm provisioning	Provision khi ‘ready-to-onboard’ đúng (dữ liệu đầy đủ).	Provision ngay khi tạo record (nhanh hơn, rủi ro cấp sai quyền cao).
Chiến lược thiết bị	Chuẩn hoá model/policy theo vai trò.	Cho team tự chọn thiết bị (đa dạng hơn, khó quản lý hơn).
Ưu tiên offboarding	Gỡ quyền trước, rồi thu hồi tài sản.	Thu thiết bị trước (rủi ro: còn quyền truy cập/bị lộ bảo mật).

9) Rào chắn: Nên / Không nên & Lỗi hay gặp

Rào chắn IT chủ yếu là “least privilege” và ownership rõ ràng.

Nên / Không nên

Nên: map quyền theo roles/groups để thay đổi “lan truyền” tự động.
Nên: coi quyền đặc quyền là case riêng có review chặt hơn.
Nên: giữ kho thiết bị chính xác và có owner rõ cho việc thu hồi.
Không nên: cấp quyền vĩnh viễn cho nhu cầu tạm thời (dùng quy trình có thời hạn).
Không nên: để offboarding phụ thuộc trí nhớ — dùng checklist/workflow.
Không nên: bỏ qua lỗi sync/integration; nó gây “trôi quyền” âm thầm.

Lỗi hay gặp + Cách tránh

Cấp quyền ad hoc không theo group → sửa: định nghĩa role-based groups trước.
Provisioning trước khi HR data chốt → sửa: chặn bằng điều kiện ‘ready-to-onboard’ đầy đủ.
Offboarding bị trễ → sửa: tự động thu hồi đúng ngày/giờ kết thúc.
Thiết bị không thu hồi → sửa: quản lý inventory + tasks thu hồi + đường escalations.
Không review vệ sinh truy cập → sửa: review weekly các account cũ/đặc quyền.

10) “Tốt” trông như thế nào + Checklist

IT “tốt” khi onboarding nhanh và offboarding chứng minh được là đã xong.

“Tốt” trông như thế nào (mini rubric)

Phần lớn onboarding được tự động hoá và lặp lại được (ít ticket thủ công).
Quyền mặc định là “least privilege” và dễ review theo vai trò.
Offboarding gỡ quyền nhanh và nhất quán trên các hệ thống.
Kho thiết bị chính xác, thể hiện rõ đang gán cho ai/ai chịu trách nhiệm.
Bạn chạy báo cáo vệ sinh truy cập định kỳ và có hành động rõ.

Pre-check (trước khi chạy)

Định nghĩa roles/groups và tối thiểu các app cần cho từng role.
Xác định các app đặc quyền và thêm bước duyệt/kiểm soát.
Kết nối app/IdP chính để provisioning tự động.
Chuẩn hoá model thiết bị và quy tắc gán theo role.
Chốt checklist offboarding và quy trình thu hồi thiết bị.
Đặt lịch review vệ sinh truy cập (hàng tuần hoặc 2 tuần/lần).

Post-check (sau khi chạy)

Test một luồng onboarding end-to-end (apps + task thiết bị).
Audit một case offboarding để xác nhận gỡ quyền trên các hệ thống.
Review sync logs của integrations để bắt “trôi quyền” hoặc lỗi.
Đối soát inventory vs thực tế (spot-check một mẫu).
Ghi lại định nghĩa group và owner của từng app quan trọng.
Lên lịch review quyền đặc quyền định kỳ.

11) Bài thực hành (5–15 phút) + Link tài liệu chính thức

Thực hành: tạo access group cho một role và kiểm chứng hành vi onboarding/offboarding.

Chọn một role phổ biến (vd: Sales Rep) và liệt kê 5 app bắt buộc.
Tạo định nghĩa access group và ghi rõ ai duyệt thay đổi membership.
Kết nối (hoặc mô phỏng) các app cần cho hành động provisioning.
Gán một user test vào group và xác minh truy cập trong các app đó.
Gỡ user test khỏi group và xác minh quyền bị thu hồi.
Viết runbook 1 trang: cách add/remove và cách troubleshoot.

Kiểm chứng bạn làm đúng

Membership group điều khiển quyền ổn định (thêm thì cấp, gỡ thì thu hồi).
Bạn giải thích được ai duyệt quyền và log nằm ở đâu.
Provisioning/deprovisioning nhất quán và lặp lại được.
Có bước troubleshoot cho lỗi integration/sync.

Phân quyền & Vai trò

Dùng Permissions của platform cộng với các IT admin roles để ép least privilege—đặc biệt với cài app và thay đổi quyền đặc quyền.

Dữ liệu & Tích hợp

Integrations là nền cho provisioning/deprovisioning; coi mỗi integration như một “hạng mục có owner” và cần được giám sát để tránh trôi quyền.

Link tài liệu chính thức (tiêu đề)

Identity & Access Management (tổng quan sản phẩm)
Device Management (trang sản phẩm chính thức)
Rippling IT (tổng quan)
Điều hướng Rippling hiển thị các sản phẩm con của IT
Rippling+ → Cổng vào Help Center

Payroll (Bảng lương US + bối cảnh CTV)

Onboarding thân thiện cho người mới, được cấu trúc theo điều hướng sản phẩm chính thức của Rippling.

1) Đọc nhanh + Định hướng

Mục đích / Kết quả

Chạy payroll tự tin: đồng bộ dữ liệu HRIS và time, thực hiện pay run có kiểm tra, và giữ một routine chốt sổ lặp lại được để lỗi không lan sang các kỳ sau.

Dành cho ai + Khi nào nên dùng

Payroll admin chạy chu kỳ trả lương định kỳ.
HR admin cung cấp dữ liệu đầu vào (nhân sự mới, thay đổi, nghỉ việc).
Finance đối soát tổng payroll và lập kế hoạch dòng tiền.

Trong điều hướng + Tab liên quan

Vị trí: Products → Payroll → Payroll (và liên quan: Contractors, Global Payroll, EOR, v.v.).
Liên quan: HRIS, Time & Attendance, Benefits (khấu trừ), Spend (hoàn ứng), Global (quốc tế).

3–5 việc bạn sẽ làm nhiều nhất

Chốt pay groups/pay schedules và phân rõ trách nhiệm dữ liệu upstream.
Audit trước kỳ lương (new hires, thay đổi, nghỉ việc, thiếu field).
Chạy payroll theo checklist rõ ràng + approvals (nếu có).
Chạy off-cycle chỉ khi có lý do rõ + tài liệu kèm theo.
Đối soát totals sau payroll và theo dõi lỗi lặp lại.

2) Mô hình tư duy / Luồng

Payroll là một pipeline “thực thi” phụ thuộc dữ liệu đầu vào sạch. Mẹo cho người mới: biến nó thành routine lặp lại (pre-check → run → post-check), để payroll là một quy trình — không phải một cuộc chữa cháy.

Xác nhận lịch trả lương và ai thuộc pay group nào.
Audit các thay đổi upstream (nhân sự mới, thay đổi lương, nghỉ việc).
Kiểm tra time/benefits inputs ảnh hưởng đến net pay.
Preview totals và điều tra outliers.
Submit/pay payroll (kèm approvals nếu tổ chức yêu cầu).
Đối soát kết quả và ghi lại issue cho kỳ sau.

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

Từ vựng payroll dùng trong mọi kỳ lương.

Pay group: Nhóm người lao động chung lịch trả lương và quy tắc áp dụng.

Pay period: Khoảng ngày mà payroll chi trả.

Earnings: Thành phần thu nhập (giờ thường, OT, bonus, v.v.).

Deductions: Khoản khấu trừ (phúc lợi, khấu trừ theo lệnh, v.v.).

Off-cycle payroll: Kỳ chạy ngoài lịch thường (hạn chế dùng).

4) Vòng đời (state machine / lifecycle)

Payroll lặp lại theo chu kỳ; tính nhất quán là bạn thân.

Vòng đời pay cycle (thực tế)

Inputs open: thời gian làm việc và thay đổi HR phát sinh trong kỳ.
Pre-check: audit tất cả thay đổi trước khi preview.
Preview: xem totals/outliers và sửa lỗi.
Submit: chốt kỳ; ghi lại approvals và ngoại lệ.
Post-check: đối soát và ghi issue cho kỳ sau.

5) Các việc cốt lõi (jobs-to-be-done)

Giữ payroll “nhàm chán”: ít bất ngờ, nhiều kiểm tra lặp lại được.

Thiết lập pay schedules và định nghĩa pay groups rõ ràng.
Đảm bảo new hires và terminations ghi nhận đúng effective dates.
Kiểm tra time và deductions inputs trước khi preview payroll.
Preview payroll và điều tra bất thường (net pay thay đổi lớn, thiếu earnings).
Thực thi payroll và giữ audit trail sạch cho mọi thay đổi.
Đối soát và báo cáo totals sau khi hoàn tất.

6) Luồng chuẩn #1

Workflow: chạy payroll theo chu kỳ chuẩn với checklist và review bất thường.

Chốt cutoff của pay period cho nộp time và approvals.
Audit thay đổi HR: hires, comp changes, transfers, terminations (effective dates).
Xác thực benefits/deductions cập nhật ảnh hưởng kỳ này.
Chạy preview payroll và quét outliers (delta lớn, thiếu entry).
Xử lý anomalies và preview lại đến khi totals hợp lý.
Submit payroll và ghi chú/approval cho mọi ngoại lệ.

Kết quả mong đợi: Một pay run hoàn tất, totals được review và ngoại lệ có tài liệu kèm theo.

7) Luồng chuẩn #2

Workflow: chạy off-cycle payroll (cẩn thận và có thể audit).

Xác định lý do (sửa sai, bonus, payout khi nghỉ việc, v.v.) và phạm vi.
Xác định nhân sự bị ảnh hưởng và khoản điều chỉnh cụ thể.
Xác nhận approvals (finance/HR) trước khi chạy off-cycle.
Preview off-cycle và đảm bảo điều chỉnh chỉ áp dụng đúng nhóm đã khoanh.
Submit off-cycle và ghi lại sự kiện để audit/đối soát.
Cập nhật quy trình để tránh tái diễn (sửa root-cause upstream).

Kết quả mong đợi: Off-cycle được kiểm soát và truy vết được, không làm “hỏng” chu kỳ bình thường.

8) Điểm quyết định

Các lựa chọn này quyết định payroll có phải “đánh hero” mỗi kỳ không.

Quyết định	Nếu A…	Nếu B…
Độ cứng cutoff	Cutoff cứng cho time/changes; item trễ sang kỳ sau.	Cutoff mềm; nhận late changes (nhiều bất ngờ, dễ lỗi).
Approvals	Cần finance/HR duyệt trước khi submit payroll.	Payroll admin tự submit (nhanh hơn, rủi ro cao hơn).
Chính sách off-cycle	Chỉ off-cycle cho case đã định nghĩa + có tài liệu.	Off-cycle vì tiện (tạo hỗn loạn và rủi ro audit).
Ownership upstream	HR sở hữu people data; manager sở hữu time approvals; payroll sở hữu execution.	Ownership “chia chung” mơ hồ (dẫn tới đổ lỗi và sửa phút chót).

9) Rào chắn: Nên / Không nên & Lỗi hay gặp

Sai payroll làm mất niềm tin rất nhanh—dùng rào chắn để chặn lỗi tránh được.

Nên / Không nên

Nên: định nghĩa pay group và lịch trả lương rõ ràng, có tài liệu.
Nên: review outliers mỗi kỳ (cách nhanh nhất để bắt lỗi).
Nên: yêu cầu tài liệu cho mọi điều chỉnh off-cycle.
Không nên: đổi effective dates giữa kỳ mà không hiểu tác động.
Không nên: chạy payroll khi chưa reconcile time và deductions inputs.
Không nên: sửa thủ công mà không sửa luôn root-cause upstream.

Lỗi hay gặp + Cách tránh

New hire thiếu pay data → sửa: gate “onboarding completeness” ở HRIS.
Termination không phản ánh → sửa: checklist offboarding + effective date chuẩn.
Time approvals trễ → sửa: reminders + escalation trong Time & Attendance.
Khấu trừ benefits lệch → sửa: sample-check trước payroll sau khi đổi enrollment.
Quá nhiều off-cycle → sửa: cutoff chặt hơn + fix nguyên nhân gốc.

10) “Tốt” trông như thế nào + Checklist

Payroll “tốt” khi pay runs dự đoán được và giải thích được.

“Tốt” trông như thế nào (mini rubric)

Mỗi kỳ có routine pre-check và post-check có tài liệu.
Outliers được review và giải thích trước khi submit.
Off-cycle hiếm và luôn có documentation.
Team upstream hiểu rõ trách nhiệm và deadline của mình.
Reconciliation totals khớp kỳ vọng và được báo cáo nhất quán.

Pre-check (trước khi chạy)

Xác nhận ngày kỳ lương và deadline (nộp time, approvals, thay đổi).
Audit thay đổi HR theo effective dates (hires, comp, transfers, terminations).
Xác nhận benefits/deductions áp đúng cho kỳ này.
Đảm bảo time đã được duyệt và “payroll-ready” (nếu dùng time).
Chuẩn bị checklist outlier (ai/cái gì cần điều tra).
Chốt ai phải approve trước khi submit payroll.

Post-check (sau khi chạy)

Đối soát totals với kỳ vọng và chênh lệch so với kỳ trước.
Ghi log exceptions và lý do (nhóm lỗi + owner).
Xác minh reimbursements/special payments vào/ra đúng.
Đảm bảo mọi retro adjustments có tài liệu và được review.
Gửi note chốt sổ ngắn (có gì thay đổi, kỳ sau cần để ý gì).
Cập nhật checklist upstream dựa trên lỗi lặp lại.

11) Bài thực hành (5–15 phút) + Link tài liệu chính thức

Thực hành: chạy “payroll readiness” audit với đúng 10 người (nhanh, an toàn).

Chọn 10 nhân sự có kịch bản trả lương khác nhau (hourly/salaried, new hire, v.v.).
Check HRIS: title, manager, location, employment type, effective dates.
Check Time & Attendance: đã nộp và đã duyệt (nếu dùng).
Check benefits/deductions: thay đổi gần đây ảnh hưởng kỳ này.
Liệt kê anomalies và gán owner (HR vs manager vs payroll).
Re-check sau khi fix và ghi lại “điều gì đã ngăn lỗi này”.

Kiểm chứng bạn làm đúng

Bạn gọi tên được top 3 nguyên nhân upstream gây payroll anomalies trong org của bạn.
Một checklist readiness nhỏ bắt được vấn đề trước payroll preview.
Owner rõ cho từng loại anomaly (không phải “payroll sửa hết”).
Bạn giải thích được chênh lệch so với kỳ trước bằng bằng chứng.

Phân quyền & Vai trò

Hạn chế ai được submit payroll và ai được đổi các input nhạy cảm bằng phân quyền theo vai trò và approvals phù hợp với kiểm soát nội bộ của bạn.

Dữ liệu & Tích hợp

Payroll phụ thuộc upstream (HRIS, time, benefits). Hãy coi mỗi phụ thuộc như một integration: có owner, có cutoff, và có bước validate.

Link tài liệu chính thức (tiêu đề)

Payroll (tổng quan sản phẩm)
Rippling: How to process payroll (khung quy trình)
Điều hướng Rippling hiển thị “họ Payroll” (contractors/global/EOR)
Rippling+ → Cổng vào Help Center

Spend / Finance (Quản lý chi phí, thẻ công ty, thanh toán hoá đơn, du lịch)

Onboarding thân thiện cho người mới, được cấu trúc theo điều hướng sản phẩm chính thức của Rippling.

1) Đọc nhanh + Định hướng

Mục đích / Kết quả

Kiểm soát chi tiêu bằng chính sách rõ ràng và hoàn tiền nhanh: ghi nhận chi phí, ép luồng phê duyệt, và giữ dữ liệu tài chính nhất quán mà không phải “ping-pong” thủ công.

Dành cho ai + Khi nào nên dùng

Finance admin quản lý expense, corporate cards, bill pay, hoặc kiểm soát travel.
Manager phê duyệt chi tiêu và enforce policy.
Nhân viên submit expense và hoàn ứng.

Trong điều hướng + Tab liên quan

Vị trí: Products → Finance/Spend → Expense Management (liên quan: Corporate Cards, Bill Pay, Travel).
Liên quan: Platform (policies/approvals/workflows), HRIS (thuộc tính nhân sự), Payroll (hoàn ứng nếu áp dụng), Integrations (kế toán).

3–5 việc bạn sẽ làm nhiều nhất

Định nghĩa spend policy: cái gì được phép, hạn mức, và chứng từ bắt buộc.
Thiết lập approval routing (manager, budget owner, finance) và SLA.
Chuẩn hoá categories/codes để báo cáo và bàn giao sang kế toán.
Review ngoại lệ hàng tuần (thiếu hoá đơn, duyệt trễ, vi phạm policy).
Chốt tháng với checklist đối soát lặp lại được.

2) Mô hình tư duy / Luồng

Spend management là “vòng điều khiển”: policy đặt luật, capture thu bằng chứng, approvals enforce luật, và reporting/reconcile chốt kết quả. Win lớn nhất: nhất quán + ít ma sát.

Định nghĩa policy (hạn mức, danh mục, rule yêu cầu hoá đơn/chứng từ).
Ghi nhận chi tiêu (expense submissions và card transactions).
Route approvals dựa trên thuộc tính nhân sự và ngưỡng tiền.
Enforce policy (flag vi phạm và yêu cầu bổ sung/sửa).
Hoàn ứng/settle chi tiêu và hạch toán sang kế toán.
Đối soát và báo cáo (routine chốt tháng).

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

Thuật ngữ khi bạn truyền thông policy.

Spend policy: Luật mua sắm/chi tiêu, hạn mức, và yêu cầu chứng từ.

Receipt requirement: Khi nào bắt buộc có hoá đơn/chứng từ (theo số tiền/danh mục).

Approval threshold: Ngưỡng tiền làm thay đổi người phải phê duyệt.

Category / code: Nhãn dùng cho báo cáo và mapping hạch toán.

Exception: Phiếu chi vi phạm rule hoặc thiếu thông tin bắt buộc.

4) Vòng đời (state machine / lifecycle)

Chi tiêu đi từ capture đến close; giữ vòng lặp dự đoán được.

Vòng đời expense (thực tế)

Draft: nhân viên nhập thông tin và đính kèm chứng từ.
Submitted: vào luồng phê duyệt.
Approved/Rejected: áp kiểm soát tài chính.
Settled: hoàn ứng hoặc hạch toán hoàn tất.
Reconciled: vào báo cáo/chốt tháng với audit trail đầy đủ.

5) Các việc cốt lõi (jobs-to-be-done)

Làm tốt các việc này để tránh “chạy sấp mặt” cuối tháng.

Định nghĩa policy rõ ràng: hạn mức, danh mục, rule hoá đơn/chứng từ.
Thiết lập approval routing khớp org structure và các ngưỡng tiền.
Đảm bảo submissions đủ thông tin (chứng từ, category, business purpose).
Xử lý hoàn ứng/settlement nhanh theo SLA dự đoán được.
Tích hợp kế toán khi cần và giữ mapping có tài liệu + owner.
Chạy checklist chốt tháng và theo dõi exceptions.

6) Luồng chuẩn #1

Workflow: nhân viên submit expense và được duyệt nhanh (happy path).

Nhân viên nhập chi tiết expense và đính kèm chứng từ bắt buộc.
Hệ thống validate field bắt buộc (category, amount, date, business purpose).
Approval route tới manager (và finance nếu vượt ngưỡng).
Approver kiểm policy và approve/return để bổ sung.
Finance check cuối (nếu cần) và đánh dấu settled.
Expense sẵn sàng cho reporting/kế toán với coding nhất quán.

Kết quả mong đợi: Expense đi đúng luồng phê duyệt và kết thúc ở trạng thái “phân loại đúng + audit được”.

7) Luồng chuẩn #2

Workflow: xử lý ngoại lệ policy (thiếu hoá đơn / out-of-policy).

Submission bị flag exception (thiếu chứng từ hoặc vi phạm policy).
Nhân viên nhận thông báo rõ “thiếu gì” hoặc “vi phạm rule nào”.
Nhân viên bổ sung chứng từ hoặc xin duyệt ngoại lệ.
Approver quyết định (duyệt ngoại lệ kèm note, hoặc từ chối).
Finance ghi lại cách xử lý (lý do + người duyệt) để audit.
Review xu hướng exception để cập nhật policy/đào tạo.

Kết quả mong đợi: Ngoại lệ được xử lý có tài liệu, không “duyệt chui” hoặc kéo dài email vô tận.

8) Điểm quyết định

Chốt trade-off giữa “kiểm soát” và “tốc độ” ngay từ đầu.

Quyết định	Nếu A…	Nếu B…
Độ sâu phê duyệt	Low amount: manager duyệt; high amount: thêm finance.	Luôn cần finance duyệt (kiểm soát cao hơn, chậm hơn).
Rule hoá đơn	Yêu cầu hoá đơn theo ngưỡng tiền và/hoặc danh mục.	Yêu cầu hoá đơn cho mọi khoản (chặt, nhưng ma sát cao).
Chiến lược category	Danh sách category nhỏ, ổn định để báo cáo nhất quán.	Nhiều category nhỏ (chi tiết hơn, khó tuân thủ hơn).
Tích hợp kế toán	Chỉ tích hợp khi mapping đã ổn định.	Trì hoãn tích hợp tới khi process chín (manual nhiều hơn, ít rủi ro sync).

9) Rào chắn: Nên / Không nên & Lỗi hay gặp

Hệ thống chi tiêu “fail” khi rule mơ hồ hoặc enforcement thiếu nhất quán.

Nên / Không nên

Nên: giữ policy đơn giản và viết bằng ngôn ngữ dễ hiểu.
Nên: đặt SLA cho approvals và có escalation khi trễ.
Nên: theo dõi tỷ lệ exceptions theo team để nhắm đào tạo.
Không nên: approve ngoại lệ mà không có note (mất auditability).
Không nên: để category “trôi” (vỡ báo cáo và mapping kế toán).
Không nên: chốt tháng khi không có checklist đối soát.

Lỗi hay gặp + Cách tránh

Policy mơ hồ → sửa: ví dụ + ngưỡng tiền + yêu cầu chứng từ cụ thể.
Manager duyệt “cho có” → sửa: training + audit sampling định kỳ.
Đuổi hoá đơn qua email → sửa: notification + gate ngay trong hệ thống.
Category nở quá nhanh → sửa: governance owner + controlled updates.
Bất ngờ cuối tháng → sửa: review ngoại lệ hàng tuần + báo cáo aging.

10) “Tốt” trông như thế nào + Checklist

Spend “tốt” khi nhanh cho nhân viên và dự đoán được cho finance.

“Tốt” trông như thế nào (mini rubric)

Phần lớn expense được duyệt trong SLA (ví dụ 2–5 ngày làm việc).
Exceptions được xử lý có note và ownership rõ ràng.
Categories/codes nhất quán, hỗ trợ reporting và hạch toán.
Đối soát chốt tháng lặp lại được và audit được.
Vi phạm policy giảm dần theo thời gian (training + enforcement hiệu quả).

Pre-check (trước khi chạy)

Viết policy: categories cho phép, ngưỡng tiền, rule hoá đơn, ví dụ.
Định nghĩa approval routing và thresholds (ai duyệt cái gì).
Tạo danh sách category/coding và chỉ định owner thay đổi.
Chốt cách hoàn ứng/settle và ai sở hữu timeline.
Chốt cách xử lý exceptions và cách ghi nhận approvals.
Nếu tích hợp kế toán: chốt mappings và owners.

Post-check (sau khi chạy)

Review approval aging và xử lý bottleneck approvers.
Review exception rate và chốt top 2 nguyên nhân để fix.
Audit một mẫu nhỏ các expense đã duyệt để kiểm compliance.
Đối soát totals và xác nhận coding đúng cho reporting.
Cập nhật policy guidance dựa trên câu hỏi lặp lại.
Ghi lại mọi thay đổi thresholds/categories cho tháng sau.

11) Bài thực hành (5–15 phút) + Link tài liệu chính thức

Thực hành: viết policy đơn giản và chạy review ngoại lệ trên một tập expense nhỏ.

Viết policy 1 trang với 3 ngưỡng tiền và 5 categories.
Chọn 10 expense gần đây (hoặc mock) và phân loại theo policy.
Flag khoản nào cần hoá đơn và khoản nào out-of-policy.
Viết template nhắn “thiếu gì cần bổ sung” (message mẫu).
Tóm tắt exception rate và top 1–2 nguyên nhân.
Cập nhật policy doc hoặc training note để giảm nguyên nhân đó.

Kiểm chứng bạn làm đúng

Bạn quyết định rõ được expense nào in-policy vs out-of-policy.
Exceptions được xử lý theo một quy trình nhất quán và có tài liệu.
Categories/codes giữ nhất quán xuyên suốt submissions.
Review ngoại lệ hàng tuần sẽ bắt lỗi trước khi chốt tháng.

Phân quyền & Vai trò

Dùng permissions để chỉ đúng người được đổi policies/thresholds và các hành động settlement nhạy cảm; scope của approver nên khớp org structure.

Dữ liệu & Tích hợp

Spend thường tích hợp sang hệ kế toán và dùng thuộc tính HRIS để route approvals; hãy chốt mappings và “system of record” trước khi bật sync rộng.

Link tài liệu chính thức (tiêu đề)

Expense Management (tổng quan sản phẩm)
Điều hướng Rippling hiển thị các sản phẩm con của Spend (Corporate Cards, Bill Pay, Travel)
Rippling+ → Cổng vào Help Center

Global (EOR, Global Payroll, Global Contractors)

Onboarding cho người mới, bám theo điều hướng sản phẩm chính thức của Rippling.

1) Đọc nhanh + Định hướng

Mục đích / Kết quả

Tuyển và trả lương quốc tế ít “bất ngờ compliance” hơn bằng cách chọn đúng đường đi (EOR vs global payroll vs contractors) và thiết lập handoff sạch về hệ thống lõi.

Dành cho ai + Khi nào dùng

HR/People Ops tuyển dụng ngoài quốc gia “home”.
Finance/payroll phối hợp pay cycle quốc tế.
Founder/ops quyết định giữa entity, EOR, hay contractor model.

Trong điều hướng + Tab liên quan

Vị trí: Products → Global (và nhóm Payroll: Employer of Record, Global Payroll, Global Contractors, Contractor of Record).
Liên quan: HRIS (global data), Payroll (domestic), Recruiting (tuyển quốc tế), Security (data handling), Platform (integrations/workflows).

3–5 việc bạn sẽ làm nhiều nhất

Chọn mô hình engagement theo từng quốc gia (employee vs contractor; EOR vs entity).
Thu thập thông tin/bằng chứng bắt buộc theo quốc gia từ sớm (tránh block phút chót).
Chuẩn hoá checklist onboarding cho global hires.
Căn pay schedule + currency/bank details theo timeline payroll.
Lưu tài liệu phục vụ audit (hợp đồng, quyết định phân loại).

2) Mô hình tư duy / Luồng

Global chủ yếu là: chọn đúng “mô hình pháp lý/lao động”, rồi vận hành quy trình dữ liệu + trả lương dự đoán được. Cách fail nhanh nhất: coi global như domestic và “tính sau”.

Chọn mô hình theo quốc gia (EOR, entity payroll, contractor).
Thu thập thông tin + tài liệu bắt buộc theo mô hình.
Tạo worker record trong hệ thống lõi với đầy đủ thuộc tính.
Kick off onboarding tasks + access provisioning qua workflows.
Chạy pay cycles bằng checklist chặt + validation theo quốc gia.
Review compliance và quyết định phân loại định kỳ.

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

Dùng nhất quán các từ này khi nói về tuyển dụng toàn cầu.

Employer of Record (EOR): Thuê nhân viên tại một quốc gia mà không cần công ty có entity tại đó.

Global Payroll: Vận hành trả lương cho nhân viên ở nhiều quốc gia (phụ thuộc setup).

Contractor: Lao động không phải nhân viên; phân loại cần cẩn trọng theo từng jurisdiction.

Contractor of Record: Mô hình nhằm giảm rủi ro misclassification cho contractor.

Entity: Hiện diện pháp lý của công ty tại quốc gia đó (thường cần nếu tuyển employee trực tiếp).

4) Vòng đời (state machine / lifecycle)

Global thêm nhiều trạng thái vì compliance khác nhau theo quốc gia.

Vòng đời global worker (thực tế)

Model decision: chọn đường employee (EOR/entity) hoặc contractor.
Documentation: thu thập hợp đồng + thông tin bắt buộc.
Onboarding: identity/access + yêu cầu địa phương hoàn tất.
Pay cycles: chạy payroll/contractor payments định kỳ với checks.
Offboarding: end date + final payments + gỡ access.

5) Các việc cốt lõi (jobs-to-be-done)

Các việc “đáng tiền” nhất thường là quyết định đúng + checklist chuẩn.

Chọn đúng mô hình theo từng quốc gia bằng tiêu chí rõ ràng.
Chuẩn hoá input onboarding toàn cầu (bank, address, tax details khi cần).
Căn pay calendars + cutoffs toàn cầu (tránh “urgent” phút chót).
Theo dõi và review quyết định phân loại contractor vs employee.
Tự động hoá onboarding/offboarding bằng workflow nhất quán.
Giữ tài liệu compliance và audit trail sẵn sàng.

6) Luồng chuẩn #1

Workflow: thuê 1 nhân viên quốc tế theo đường EOR (happy path).

Chốt quốc gia và xác nhận công ty có entity ở đó hay không.
Chọn EOR nếu cần thuê employee mà chưa có entity.
Thu thập thông tin + điều khoản lao động bắt buộc từ sớm.
Tạo worker record với đủ HRIS attributes để tự động hoá downstream.
Kick off onboarding tasks (access, thiết bị, checklist cho manager).
Xác nhận pay schedule và ngày trả lương đầu tiên.

Kết quả mong đợi: Nhân viên quốc tế được onboard theo đúng mô hình đã chọn, timeline rõ, input đầy đủ.

7) Luồng chuẩn #2

Workflow: trả tiền contractor quốc tế ổn định (giảm “surprise” phân loại).

Xác nhận classification và tài liệu bắt buộc theo jurisdiction.
Thu payout details (bank, cách invoice, kỳ vọng currency).
Thiết lập cadence trả tiền + cutoff schedule lặp lại được.
Thu/duyệt invoice hoặc xác nhận công việc trước khi trả.
Thực hiện payment và lưu hồ sơ phục vụ audit/finance.
Review mối quan hệ contractor định kỳ để giảm rủi ro misclassification.

Kết quả mong đợi: Payment đúng hạn, có tài liệu, và có routine review rủi ro theo thời gian.

8) Điểm quyết định

Global “thắng” hay “thua” nằm ở quyết định mô hình ban đầu.

Quyết định	Nếu A…	Nếu B…
Hiện diện ở quốc gia	Chưa có entity: cân nhắc EOR cho employee.	Đã có entity: chạy payroll trực tiếp theo entity setup.
Loại worker	Employee: chọn EOR/entity payroll theo hiện diện.	Contractor: quy trình rõ + review misclassification định kỳ.
Tốc độ vs kiểm soát	EOR thường nhanh hơn để bắt đầu ở quốc gia mới.	Entity payroll kiểm soát trực tiếp hơn nhưng cần entity + process.
Ownership compliance	Gán owner global (HR/ops) cho từng đường theo quốc gia.	Ownership mơ hồ (rủi ro thiếu yêu cầu và bị delay).

9) Rào chắn: Nên / Không nên & Lỗi hay gặp

Guardrails global = quyết định rõ + checklist lặp lại được + tài liệu hoá.

Nên / Không nên

Nên: chốt mô hình theo quốc gia trước khi ra offer.
Nên: thu tài liệu bắt buộc sớm (đừng chờ tới day 1).
Nên: lưu quyết định phân loại contractor có lý do rõ.
Không nên: giả định rule payroll trong nước áp dụng cho quốc tế.
Không nên: đổi worker type (contractor ↔ employee) nếu không có quy trình review.
Không nên: chạy payment khi chưa có cutoffs + approvals (đau audit sau này).

Lỗi hay gặp + Cách tránh

Ra offer trước khi chốt model → sửa: bắt buộc model decision trong recruiting workflow.
Thiếu info địa phương → sửa: checklist onboarding theo từng quốc gia.
Bỏ qua rủi ro misclassification → sửa: review định kỳ + rationale bằng văn bản.
Không có pay calendar rõ → sửa: publish global cutoffs + owners.
Offboarding global không đồng bộ → sửa: gỡ access cùng ngày + checklist final pay.

10) “Tốt” trông như thế nào + Checklist

Global “tốt” khi tuyển dụng dự đoán được và hiếm compliance surprises.

“Tốt” trông như thế nào (mini rubric)

Mỗi quốc gia có model engagement được tài liệu hoá và lặp lại được.
Checklist onboarding global cover đủ inputs địa phương trước start date.
Pay cycles chạy theo lịch công bố với cutoffs + approvals rõ.
Quyết định phân loại contractor được review định kỳ.
Có thể xuất hồ sơ audit-ready: tài liệu + quyết định chính.

Pre-check (trước khi chạy)

Chốt model theo quốc gia (EOR/entity/contractor) và ghi rõ “vì sao”.
Tạo checklist onboarding theo quốc gia và gán owner.
Căn global pay calendars + cutoffs với vận hành finance.
Chốt nơi lưu tài liệu và convention đặt tên.
Thiết lập offboarding steps (gỡ access + final payments).
Đặt cadence review rủi ro contractor classification.

Post-check (sau khi chạy)

Review pay cycle đầu và các exceptions.
Audit các field onboarding hay thiếu và fix “intake process”.
Check access provisioning/deprovisioning có đúng planned dates không.
Cập nhật checklist theo quốc gia dựa trên “cái làm bạn bất ngờ”.
Review contractor relationships xem có scope creep hay “giống employee” không.
Chuẩn hoá bài học rút ra thành workflow mới.

11) Bài thực hành (5–15 phút) + Link tài liệu chính thức

Thực hành: tạo “bảng quyết định tuyển global” cho 1 quốc gia và chạy thử 1 mock hire.

Chọn 1 quốc gia mục tiêu bạn có thể tuyển.
Viết tiêu chí quyết định: entity vs EOR vs contractor (rule A/B đơn giản).
Liệt kê bộ field + tài liệu tối thiểu cần thu khi onboarding.
Draft pay calendar + cutoffs cho 2 pay cycles đầu tiên.
Chạy mock scenario end-to-end và note chỗ thiếu thông tin.
Biến notes thành checklist cập nhật và gán owner.

Kiểm chứng bạn làm đúng

Bạn giải thích được model choice bằng 1 đoạn ngắn có thể audit.
Input onboarding được biết trước start date (không scramble phút chót).
Pay cutoffs + owners rõ ràng cho các kỳ đầu.
Có routine review rủi ro contractor classification.

Phân quyền & Vai trò

Global cần rõ role: ai duyệt offer, ai xử lý bước compliance địa phương, ai chạy pay cycles. Dùng permissions để enforce “separation of duties”.

Dữ liệu & Tích hợp

Global processes có thể nối HRIS, finance, và identity workflows; hãy chốt system-of-record cho từng field và theo dõi sync health.

Link tài liệu chính thức (tiêu đề)

Employer of Record (tổng quan sản phẩm)
Global Payroll (tổng quan sản phẩm)
Điều hướng Rippling hiển thị nhóm Global
Rippling+ → Cổng vào Help Center

Bảo mật & Bảo vệ dữ liệu (Niềm tin, kiểm soát, và vệ sinh vận hành)

Onboarding cho người mới, bám theo điều hướng sản phẩm chính thức của Rippling.

1) Đọc nhanh + Định hướng

Mục đích / Kết quả

Thiết lập “baseline” bảo mật để quyền truy cập theo nguyên tắc tối thiểu (least privilege), dữ liệu nhạy cảm được bảo vệ, và bạn có thể chứng minh kiểm soát khi audit (mà không khóa nhầm mọi người).

Dành cho ai + Khi nào dùng

Admin chịu trách nhiệm posture bảo mật và quản trị quyền truy cập.
Đội IT/security triển khai vệ sinh identity & access.
Lãnh đạo chuẩn bị cho audit hoặc vendor security review.

Trong điều hướng + Tab liên quan

Vị trí: Resources → Bảo mật & Bảo vệ dữ liệu (ngoài ra các kiểm soát bảo mật nằm rải trên Platform + IT modules).
Liên quan: Platform (Permissions/Policies), IT (Identity & Access), HRIS (ai đang có trong hệ thống), Integrations (rủi ro bên thứ ba).

3–5 việc bạn sẽ làm nhiều nhất

Định nghĩa role theo least-privilege và review quyền đặc quyền định kỳ.
Chuẩn hoá workflow cấp/đổi/thu hồi quyền (đặc biệt offboarding).
Bảo vệ các field dữ liệu nhạy cảm bằng quyền chặt hơn + audit trail.
Theo dõi ngoại lệ: workflow fail, lỗi đồng bộ, thay đổi quyền bất thường.
Chuẩn bị “audit packet” (cần show gì, tìm ở đâu, ai sở hữu).

2) Mô hình tư duy / Luồng

Bảo mật không phải 1 nút bật/tắt—mà là các routine vận hành, được “chạy bằng” permissions, policies, identity controls và monitoring. Bảo mật tốt là lặp lại được và review được, không dựa vào “anh hùng”.

Định nghĩa roles và ranh giới least-privilege.
Siết identity & access management (routine join/change/leave).
Bảo vệ dữ liệu nhạy cảm bằng quyền theo phạm vi + kiểm soát thay đổi.
Thiết lập theo dõi ngoại lệ và pattern đáng ngờ.
Chạy review định kỳ (privileged access, stale accounts, integrations).
Tài liệu hoá kiểm soát và nguồn bằng chứng phục vụ audit.

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

Giao tiếp về bảo mật nhanh hơn khi mọi người dùng chung “từ điển”.

Least privilege: Mỗi người chỉ có đúng quyền cần cho công việc—không hơn.

Privileged access (quyền đặc quyền): Quyền tác động lớn (admin rights, finance controls, dữ liệu nhạy cảm).

Access review: Rà soát định kỳ để xác nhận quyền vẫn phù hợp.

Data protection: Kiểm soát để hạn chế lộ/tiếp cận thông tin nhạy cảm.

Audit evidence (bằng chứng audit): Log/report/record chứng minh quy trình kiểm soát được tuân thủ.

4) Vòng đời (state machine / lifecycle)

Công việc bảo mật lặp theo nhịp (tuần/tháng/quý).

Vòng đời vận hành bảo mật

Baseline: định nghĩa roles, policies, và identity setup.
Operate: onboard/offboard và xử lý thay đổi qua workflows.
Monitor: xem ngoại lệ và pattern đáng ngờ.
Review: access review định kỳ và audit integrations.
Improve: siết kiểm soát dựa trên incident và phát hiện.

5) Các việc cốt lõi (jobs-to-be-done)

Đây là những việc tạo ra phần lớn “giá trị bảo mật”.

Định nghĩa admin roles và loại bỏ mô hình “ai cũng là admin”.
Bảo vệ onboarding/offboarding để thay đổi quyền tự động và đúng thời điểm.
Bảo vệ field dữ liệu nhạy cảm bằng quyền hạn chế và ghi log.
Review privileged access thường xuyên và gỡ quyền “stale” nhanh.
Audit integrations và đảm bảo tuân theo system-of-record rules.
Duy trì evidence artifacts cho audit và security questionnaires.

6) Luồng chuẩn #1

Workflow: rà soát quyền truy cập theo quý (đơn giản, tác động lớn).

Liệt kê các privileged roles (admins, finance control roles, IT superusers).
Xuất danh sách hiện tại ai đang giữ mỗi privileged role.
Chủ sở hữu role xác nhận từng người còn cần quyền không (giữ/gỡ).
Gỡ quyền cho người nghỉ, đổi role, hoặc user không còn hoạt động.
Ghi lại quyết định và lý do (notes thân thiện với audit).
Lên lịch review lần sau và theo dõi hoàn thành.

Kết quả mong đợi: Quyền đặc quyền luôn “đúng người đúng việc”, giảm rủi ro do permission bị bỏ quên.

7) Luồng chuẩn #2

Workflow: vệ sinh xử lý incident liên quan thay đổi quyền (cô lập nhanh).

Xác định phạm vi: user nào, role nào, integration/app nào liên quan.
Gỡ hoặc tạm khóa quyền truy cập ngay cho account bị ảnh hưởng (containment).
Kiểm tra hoạt động thay đổi quyền gần đây và các sự kiện sync của integration.
Reset credentials/keys và re-auth integrations nếu cần.
Khôi phục quyền theo least-privilege và xác nhận vận hành bình thường.
Post-incident review và cập nhật kiểm soát để tránh lặp lại.

Kết quả mong đợi: Cô lập quyền nhanh, thu thập bằng chứng đủ, và kiểm soát được cải thiện sau sự cố.

8) Điểm quyết định

Bảo mật luôn có tradeoff; hãy làm rõ từ đầu.

Quyết định	Nếu A…	Nếu B…
Mô hình admin	Ít admins + đường escalation rõ.	Nhiều admins để nhanh (rủi ro cao hơn; cần monitoring mạnh).
Thay đổi quyền	Mọi thay đổi qua request/approval/workflow.	Ad hoc (nhanh nhưng auditability kém).
Quản trị integrations	Mỗi integration có owner + monitoring + reviews.	Không owner rõ (rủi ro drift âm thầm và credential “stale”).
Sẵn sàng audit	Duy trì checklist bằng chứng liên tục.	Chạy nước rút mùa audit (stress cao và nhiều lỗ hổng).

9) Rào chắn: Nên / Không nên & Lỗi hay gặp

Nhiều thất bại bảo mật là thất bại quy trình—hãy “rào” quy trình.

Nên / Không nên

Nên: review privileged access theo lịch (tối thiểu mỗi quý).
Nên: tự động hoá offboarding để thu hồi quyền đúng thời điểm.
Nên: bảo vệ field nhạy cảm bằng role scopes chặt hơn.
Không nên: dùng chung admin account hoặc bỏ qua tài liệu hoá thay đổi.
Không nên: để integration “treo” không monitoring/ownership.
Không nên: coi audit là sự kiện 1 lần—hãy build bằng chứng ngay khi vận hành.

Lỗi hay gặp + Cách tránh

Quá nhiều admins → sửa: giảm admin set; dùng approvals cho hành động nâng quyền.
Offboarding không tức thời → sửa: tự động revoke access theo end date/time.
Không có owner cho integration → sửa: gán owner + lịch review cho từng integration.
Dữ liệu nhạy cảm bị lộ quá rộng → sửa: hạn chế field access và ghi rõ lý do.
Không có evidence trail → sửa: checklist audit “sống” + nơi lưu artifacts.

10) “Tốt” trông như thế nào + Checklist

Bảo mật “tốt” khi kiểm soát lặp lại được và bằng chứng dễ xuất.

“Tốt” trông như thế nào (mini rubric)

Admin/privileged roles ít, được review, và có owner rõ.
Thay đổi quyền được theo dõi và có phê duyệt cho hành động nhạy cảm.
Offboarding thu hồi quyền ổn định và nhanh.
Integrations được theo dõi và tái xác nhận định kỳ.
Audit evidence (rosters, logs, reviews) có sẵn, không phải “chạy nước rút”.

Pre-check (trước khi chạy)

Định nghĩa privileged roles và ai có quyền cấp.
Lập lịch access review theo quý và gán owners.
Tài liệu hoá bước offboarding thu hồi quyền và timing.
Xác định field dữ liệu nhạy cảm và siết phạm vi truy cập.
Gán owner cho mỗi integration quan trọng và vòng đời credential.
Tạo checklist bằng chứng audit (mỗi artifact nằm ở đâu).

Post-check (sau khi chạy)

Xác nhận access review đã xong và quyền cần gỡ đã được áp dụng.
Review ngoại lệ: workflow fail, bất thường đổi quyền, lỗi sync.
Rotate credentials/keys nếu policy yêu cầu.
Cập nhật tài liệu nếu có roles/integrations/controls mới.
Spot audit: bạn có xuất được bằng chứng như đã cam kết không?
Lên lịch review tiếp theo và theo dõi hoàn thành.

11) Bài thực hành (5–15 phút) + Link tài liệu chính thức

Thực hành: tạo một “audit packet” mini cho quản trị quyền truy cập (10 phút).

Liệt kê top 5 privileged roles/groups và owner của từng cái.
Chụp/ghi danh sách ai đang có mỗi role đó.
Viết câu hỏi review: “Người này còn cần quyền này không?”
Ghi 1 ví dụ quyết định (giữ/gỡ) kèm lý do.
Ghi cadence đơn giản (theo quý) và nơi lưu bằng chứng.
Chia sẻ packet cho stakeholder và xin sign-off quy trình.

Kiểm chứng bạn làm đúng

Bạn chỉ ra được ai có privileged access và “vì sao”.
Có cadence review và owner (không phải “để sau”).
Nơi lưu bằng chứng rõ và tái dùng được.
Thu hồi quyền khi offboarding là một phần workflow chuẩn.

Phân quyền & Vai trò

Posture bảo mật phụ thuộc mạnh vào Permissions (ai làm được gì) và kiểm soát identity của IT; hãy thiết kế roles có chủ đích và review theo cadence.

Dữ liệu & Tích hợp

Integrations mở rộng “attack surface”; gán owner và theo dõi auth/sync health để tránh credential “stale” và access drift.

Link tài liệu chính thức (tiêu đề)

Security & Data Protection (trang chính thức)
Rippling Platform (ngữ cảnh permissions/policies)
Identity & Access Management (IT)

Your favorites

Nền tảng (Workflow Studio, Tích hợp, App Studio, Chính sách, Phân quyền, Phân tích)

1) Đọc nhanh + Định hướng

Dành cho ai + Khi nào nên dùng

Trong điều hướng + Tab liên quan

3–5 việc bạn sẽ làm nhiều nhất

2) Mô hình tư duy / Luồng

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

4) Vòng đời (state machine / lifecycle)

5) Các việc cốt lõi (jobs-to-be-done)

6) Luồng chuẩn #1

7) Luồng chuẩn #2

8) Điểm quyết định

9) Rào chắn: Nên / Không nên & Lỗi hay gặp

Nên / Không nên

Lỗi hay gặp + Cách tránh

10) “Tốt” trông như thế nào + Checklist

“Tốt” trông như thế nào (mini rubric)

Pre-check (trước khi chạy)

Post-check (sau khi chạy)

11) Bài thực hành (5–15 phút) + Link tài liệu chính thức

Phân quyền & Vai trò

Dữ liệu & Tích hợp

Link tài liệu chính thức (tiêu đề)

HRIS (HR cốt lõi / Hệ thống nguồn dữ liệu chuẩn)

1) Đọc nhanh + Định hướng

Dành cho ai + Khi nào nên dùng

Trong điều hướng + Tab liên quan

3–5 việc bạn sẽ làm nhiều nhất

2) Mô hình tư duy / Luồng

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

4) Vòng đời (state machine / lifecycle)

5) Các việc cốt lõi (jobs-to-be-done)

6) Luồng chuẩn #1

7) Luồng chuẩn #2

8) Điểm quyết định

9) Rào chắn: Nên / Không nên & Lỗi hay gặp

Nên / Không nên

Lỗi hay gặp + Cách tránh

10) “Tốt” trông như thế nào + Checklist

“Tốt” trông như thế nào (mini rubric)

Pre-check (trước khi chạy)

Post-check (sau khi chạy)

11) Bài thực hành (5–15 phút) + Link tài liệu chính thức

Phân quyền & Vai trò

Dữ liệu & Tích hợp

Link tài liệu chính thức (tiêu đề)

Recruiting (Pipeline tuyển dụng & bàn giao cho onboarding)

1) Đọc nhanh + Định hướng

Dành cho ai + Khi nào nên dùng

Trong điều hướng + Tab liên quan

3–5 việc bạn sẽ làm nhiều nhất

2) Mô hình tư duy / Luồng

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

4) Vòng đời (state machine / lifecycle)

5) Các việc cốt lõi (jobs-to-be-done)

6) Luồng chuẩn #1

7) Luồng chuẩn #2

8) Điểm quyết định

9) Rào chắn: Nên / Không nên & Lỗi hay gặp

Nên / Không nên

Lỗi hay gặp + Cách tránh

10) “Tốt” trông như thế nào + Checklist

“Tốt” trông như thế nào (mini rubric)

Pre-check (trước khi chạy)

Post-check (sau khi chạy)

11) Bài thực hành (5–15 phút) + Link tài liệu chính thức

Phân quyền & Vai trò

Dữ liệu & Tích hợp

Link tài liệu chính thức (tiêu đề)

Benefits Administration (Quản trị phúc lợi & bối cảnh PEO)

1) Đọc nhanh + Định hướng

Dành cho ai + Khi nào nên dùng

Trong điều hướng + Tab liên quan

3–5 việc bạn sẽ làm nhiều nhất

2) Mô hình tư duy / Luồng

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

4) Vòng đời (state machine / lifecycle)

5) Các việc cốt lõi (jobs-to-be-done)

6) Luồng chuẩn #1