Workday HCM
Workday HCM là nền tảng quản lý nhân sự doanh nghiệp (Human Capital Management). Hỗ trợ quản lý nhân sự toàn diện, tuyển dụng, lương thưởng, hiệu suất, phân tích dữ liệu, phù hợp doanh nghiệp lớn & tập đoàn.
- Tổng quan & Cơ bản về điều hướng
- Core HCM (Dữ liệu nhân sự, Tổ chức, Công việc)
- Tuyển dụng & Nhận việc
- Năng lực & Hiệu suất
- Nghỉ phép & Quản lý vắng mặt
- Bảo mật & Phân quyền
- Quy trình nghiệp vụ & Phê duyệt (BPF)
- Báo cáo & Phân tích lực lượng lao động
- Tích hợp & API
- Di động
Tổng quan & Cơ bản về điều hướng
- Hiểu Workday HCM bao phủ những gì trong hành trình nhân sự (lập kế hoạch tuyển dụng → nghỉ hưu).
- Nắm 3 thói quen điều hướng giúp Workday “dễ đoán”: Tìm kiếm, Worklets/Apps, và tác vụ trong Inbox.
- Nhận biết “business processes” và phê duyệt xuất hiện ở đâu trong các thao tác hằng ngày.
- Biết việc nào có thể làm an toàn vs. khi nào nên dừng lại và hỏi HR/Bảo mật.
1) Mục đích / Kết quả
Workday HCM là nền tảng đám mây để quản lý vòng đời nhân sự và vận hành HR trong một nơi. Kết quả bạn cần đạt ở tab này: điều hướng tự tin, làm được các tác vụ cơ bản, và hiểu vì sao có phê duyệt.
- Dùng Tìm kiếm toàn cục để tìm tác vụ (ví dụ: “Thay đổi thông tin cá nhân”, “Xin nghỉ phép”).
- Dùng worklets/apps ở Home để vào các khu vực hay dùng (Con người/Nhóm, Nghỉ phép, Tuyển dụng, v.v.).
- Mở Inbox mỗi ngày để xử lý tác vụ và phê duyệt (hàng đợi công việc của bạn).
- Dùng “Related Actions” (thường là nút/menu gần tên/đối tượng) để thao tác theo ngữ cảnh.
- Dùng bộ lọc trên danh sách (ngày, trạng thái, tổ chức) trước khi xuất dữ liệu hoặc báo cáo.
2) Dành cho ai + Khi nào nên dùng
Dành cho bất kỳ ai mới dùng Workday HCM: nhân viên (tự phục vụ), quản lý (thao tác cho team), và HR partners (giao dịch). Dùng khi bạn không chắc tác vụ nằm ở đâu hoặc vì sao Workday yêu cầu phê duyệt.
- Nhân viên: cập nhật hồ sơ, nghỉ phép, xem lương/phúc lợi (nếu bật).
- Quản lý: yêu cầu tuyển dụng, thay đổi job/comp, phê duyệt, báo cáo team.
- HR: sự kiện vòng đời nhân sự, quản trị dữ liệu, luồng business process.
- Dùng trước khi thực hiện thay đổi ảnh hưởng đến lương, vị trí, hoặc quyền truy cập bảo mật.
3) Vị trí trên điều hướng + Tab liên quan
Workday HCM thường được tổ chức quanh worklets/apps và tìm kiếm tác vụ. Các tab học liên quan trong guide này: Core HCM Recruiting & Hiring Absence Security Business Processes.
- Bắt đầu từ: Home → Worklets/Apps (điểm vào phổ biến).
- Dự phòng: Search (tốt nhất khi “biết tên tác vụ”).
- Hàng đợi: Inbox (tốt nhất cho phê duyệt + tác vụ follow-up).
- Menu ngữ cảnh: Related Actions (tốt nhất khi “đang ở record của worker rồi”).
4) Mô hình tư duy / Luồng
Hầu hết thao tác trong Workday kích hoạt một business process (BPF) tích hợp: sự kiện bắt đầu workflow, các bước được route đúng người, và hoàn tất sẽ cập nhật record. Nếu bạn thấy phê duyệt, thường là do rule của business process đang hoạt động đúng.
- Kích hoạt: bạn gửi một tác vụ (ví dụ: xin nghỉ phép).
- Kiểm tra: kiểm tra trường bắt buộc & quy tắc đủ điều kiện.
- Điều phối: phê duyệt/tác vụ được gửi đến các vai trò (quản lý, HR, bảo mật).
- Hoàn tất: record được cập nhật; audit trail được lưu.
5) Đối tượng & Thuật ngữ
Workday dùng các “đối tượng” nhất quán xuyên suốt module. Biết tên giúp bạn tìm kiếm và hiểu màn hình nhanh hơn.
- Worker: hồ sơ nhân viên/nhân sự hợp đồng.
- Organization: supervisory orgs, cost centers, companies (tuỳ tenant).
- Position / Job: mô hình quản lý theo vị trí vs theo job (tuỳ tenant chọn).
- Business Process: engine workflow/phê duyệt.
- Security Group/Role: kiểm soát bạn xem/làm được gì.
- Inbox: hàng đợi tác vụ/phê duyệt của bạn.
6) Máy trạng thái / Vòng đời
Nhiều thao tác có trạng thái (Draft → Submitted → In Progress → Completed/Denied). Nhãn cụ thể có thể khác tuỳ cấu hình tenant.
- Draft: chưa gửi; an toàn để huỷ/sửa.
- Submitted: đã vào luồng phê duyệt; có thể recall tuỳ rule.
- In Progress: đang chờ một hoặc nhiều bước trong Inbox của ai đó.
- Completed: đã áp dụng cập nhật; xuất hiện trong lịch sử/audit.
- Denied/Cancelled: không áp dụng thay đổi (hoặc một phần, nếu tenant cấu hình).
7) Các việc cốt lõi cần làm
Đây là các việc “tuần đầu” phổ biến nhất cho người mới.
- Tìm tác vụ theo tên bằng Search và chạy an toàn.
- Hoàn thành một Inbox task và xác nhận bước/owner tiếp theo.
- Đi tới worker record và dùng Related Actions.
- Kiểm tra trạng thái/lịch sử của một yêu cầu đã gửi.
- Xuất danh sách/báo cáo một cách có trách nhiệm (không chia sẻ quá mức).
8) Luồng chuẩn #1: Hoàn tất một phê duyệt trong Inbox
Dùng khi bạn nhận được yêu cầu phê duyệt (tuyển dụng, nghỉ phép, yêu cầu thay đổi). Mục tiêu: duyệt/từ chối tự tin và để lại audit trail rõ ràng.
- Mở Inbox từ Home.
- Chọn mục ưu tiên cao nhất (xem hạn xử lý/độ gấp).
- Đọc tóm tắt và mở chi tiết (đính kèm/bình luận).
- Kiểm tra thông tin bắt buộc (ngày, worker, org, lương nếu liên quan).
- Nếu chưa rõ, thêm bình luận hoặc trả lại theo luồng tenant.
- Bấm Approve hoặc Deny (từ chối thì ghi lý do).
- Xác nhận mục đó biến mất hoặc hiển thị đã hoàn tất.
9) Luồng chuẩn #2: Tìm và chạy một tác vụ phổ biến
Dùng khi bạn biết muốn làm gì nhưng không biết nó nằm ở đâu. Mục tiêu: tìm đúng tác vụ và gửi không lỗi.
- Dùng Search toàn cục và gõ tên tác vụ (bắt đầu rộng).
- Chọn kết quả được gắn nhãn Task (không phải report/object).
- Đọc mô tả tác vụ (nếu có) và các trường bắt buộc.
- Điền các trường bắt buộc trước; sau đó mới đến trường tuỳ chọn.
- Rà soát dữ liệu nhạy cảm (đặc biệt với tác vụ của manager/HR).
- Gửi và ghi nhận thông báo xác nhận/trạng thái.
- Kiểm tra Inbox hoặc status/history để biết bước tiếp theo.
10) Điểm quyết định
Dùng bảng này để quyết định bước tiếp theo khi Workday “hành xử lạ”.
| Tình huống | Nếu A… | Nếu B… |
|---|---|---|
| Kết quả Search có nhiều tác vụ giống nhau | Chọn cái gắn nhãn Task + đúng phạm vi vai trò của bạn. | Mở từng cái tab mới; so trường bắt buộc; hỏi HR nếu không chắc. |
| Bạn không thấy nút/hành động | Thường do security: xác nhận bạn có đúng role. | Hoặc bạn đang ở sai trang object; dùng Related Actions trên đúng record. |
| Yêu cầu bị “kẹt” | Kiểm tra ai là owner bước Inbox tiếp theo (nếu thấy) và nhắc họ. | Nếu không thấy, hỏi HR/Support để xem trạng thái process. |
| Cần đổi thứ nhạy cảm (lương/org/security) | Nếu có quyền, dùng đúng tác vụ giao dịch chính thức. | Nếu không có quyền, dừng lại và liên hệ HR/Bảo mật. |
11) Lỗi thường gặp (và cách tránh)
- Lỗi: Duyệt mà không xem đính kèm. Tránh: mở chi tiết và kiểm tra trường quan trọng trước khi duyệt.
- Lỗi: Dùng nhầm tác vụ “na ná”. Tránh: ưu tiên kết quả Task + đúng phạm vi role.
- Lỗi: Nghĩ rằng không cần phê duyệt. Tránh: mặc định nhiều thay đổi sẽ được route theo business process.
- Lỗi: Xuất dữ liệu và chia sẻ rộng. Tránh: theo nguyên tắc tối thiểu quyền và chỉ chia sẻ cái cần thiết.
- Lỗi: Sửa từ sai record. Tránh: dùng Related Actions từ đúng worker/position/org object.
12) Quyền hạn & Vai trò
Workday dùng phân quyền theo vai trò; những gì bạn thấy phụ thuộc security roles và org assignments. (Chi tiết phụ thuộc tenant.)
13) Dữ liệu & Tích hợp
Nếu tenant của bạn có API/tích hợp, chúng thường theo các dịch vụ Workday (REST/SOAP) và vẫn áp cùng mô hình bảo mật.
14) Thế nào là “làm tốt”
- Bạn tìm được tác vụ bằng Search và làm xong không phải thử-sai.
- Bạn giải thích được vì sao có phê duyệt (do business process route).
- Bạn kiểm tra được status/history và biết bước/owner tiếp theo.
- Bạn không xuất/chia sẻ dữ liệu HR nhạy cảm khi không cần.
15) Checklist: Trước khi làm + Sau khi làm
Pre-check
- Mình đang ở đúng worker/org record.
- Mình biết đúng tác vụ (task, không phải report) cần chạy.
- Mình có đủ thông tin bắt buộc (ngày, org, reason codes nếu dùng).
- Mình hiểu ai sẽ phê duyệt tiếp theo.
- Mình không đổi lương/security nếu không được uỷ quyền.
Post-check
- Mình nhận được thông báo xác nhận/trạng thái.
- Mình thêm comment/đính kèm khi cần.
- Mình kiểm tra Inbox để xem có tác vụ follow-up không.
- Mình xác nhận record đã cập nhật (hoặc đang chờ duyệt).
- Mình nói được ai đang giữ bước tiếp theo.
16) Bài lab (5–15 phút)
Mục tiêu: luyện “cơ bắp điều hướng” mà không làm thay đổi rủi ro.
- Dùng Search tìm một report/task dạng “View” vô hại mà bạn có thể truy cập.
- Mở hồ sơ worker của chính bạn và tìm các trường cơ bản (liên hệ, org, manager).
- Mở Inbox và xem lại một mục đã hoàn tất (nếu có).
- Dùng Related Actions trên chính bạn để xem các hành động được phép.
- Tìm link trợ giúp/support mà tenant cung cấp (nếu có).
17) Link tài liệu chính thức
- Tổng quan Workday HCM & các khu vực cốt lõi (Core HCM, Talent, Workforce Management, v.v.).
- Workday business process framework (cơ chế phê duyệt/workflow tích hợp).
- Workday REST API directory (ví dụ danh mục dịch vụ chính thức).
Core HCM (Dữ liệu nhân sự, Tổ chức, Công việc)
- Hiểu “Core HCM” thường bao gồm gì: hồ sơ nhân sự, tổ chức, dữ liệu job/position, và các thay đổi theo vòng đời.
- Phân biệt chỉnh sửa an toàn vs rủi ro (tự phục vụ vs giao dịch HR).
- Luyện cách kiểm tra trạng thái/lịch sử và xác nhận dữ liệu nhất quán.
- Hiểu phê duyệt đến từ đâu (điều phối theo business process).
1) Mục đích / Kết quả
Core HCM là nơi lưu dữ liệu nền tảng về worker và tổ chức. Kết quả cần đạt: cập nhật đúng (hoặc yêu cầu thay đổi đúng cách) và tránh làm hỏng các quy trình downstream như tuyển dụng, nghỉ phép, hoặc báo cáo.
- Biết dữ liệu nào “thuộc quyền” cập nhật của nhân viên vs quản lý vs HR.
- Dùng đúng tác vụ giao dịch (transaction task) cho thay đổi (không dùng cách làm tắt thủ công).
- Kiểm tra trường bắt buộc và effective date trước khi gửi.
- Hiểu thay đổi được route qua business process như thế nào.
2) Dành cho ai + Khi nào nên dùng
Nhân viên dùng Core HCM để xem/cập nhật hồ sơ và dữ liệu cá nhân (nếu tenant bật). Quản lý và HR dùng để thay đổi job/tổ chức và các sự kiện vòng đời nhân sự.
- Nhân viên: xem/cập nhật thông tin liên hệ và chi tiết cá nhân (tuỳ tenant).
- Quản lý: khởi tạo thay đổi cho team, xem dữ liệu tổ chức/nhóm.
- HR: xử lý giao dịch vòng đời nhân sự và quản trị dữ liệu.
- Dùng tab này trước khi thay đổi bất cứ thứ gì ảnh hưởng đến điều kiện hưởng quyền lợi, cơ cấu tổ chức, hoặc báo cáo.
3) Vị trí trên điều hướng + Tab liên quan
Các điểm vào phổ biến: Search → tác vụ worker; Home → worklet People/Team; Hồ sơ worker → Related Actions. Tab liên quan: Recruiting & Hiring Security Business Processes Reporting.
- Tìm tác vụ theo “ý định”: “Change”, “Request”, “View”.
- Mở worker record trước khi cần thao tác theo ngữ cảnh.
- Dùng Inbox cho các bước follow-up (tài liệu, phê duyệt, xác nhận).
- Kiểm tra màn hình process/status khi thấy bị chậm.
4) Mô hình tư duy / Luồng
Thay đổi trong Core HCM thường có effective-dated và được kiểm soát bởi business processes. Bạn gửi giao dịch, Workday route phê duyệt/tác vụ, rồi cập nhật hồ sơ worker/org.
- Xác định đúng đối tượng (worker, org, position/job).
- Chạy đúng tác vụ thay đổi và đặt effective date.
- Điền reason codes/bình luận theo yêu cầu tenant.
- Gửi → route phê duyệt/tác vụ → hoàn tất cập nhật record.
5) Đối tượng & Thuật ngữ
Core HCM dựa trên các “đối tượng” nhất quán xuất hiện ở khắp nơi.
- Worker: hồ sơ trung tâm của một người (nhân viên/nhân sự hợp đồng).
- Supervisory Organization: cấu trúc tổ chức theo tuyến quản lý (phổ biến trong Workday).
- Company / Cost Center: thành phần tổ chức tài chính/hành chính (do tenant định nghĩa).
- Job Profile: định nghĩa chuẩn hoá vai trò (kỹ năng/yêu cầu).
- Position: một “slot” trong tổ chức (position management) hoặc Job (job management).
- Effective Date: ngày thay đổi bắt đầu có hiệu lực.
6) Máy trạng thái / Vòng đời
Vòng đời worker khác nhau theo tenant nhưng thường có các sự kiện vòng đời với trạng thái do business processes quản lý.
- Pre-hire/Candidate → Hire → Active.
- Các sự kiện thay đổi (job/comp/org) → chờ phê duyệt → hoàn tất.
- Các trạng thái leave/absence có thể tương tác với trạng thái worker.
- Termination/retire → inactive; lịch sử vẫn được lưu.
- Lưu ý: Nhãn cụ thể phụ thuộc cấu hình.
7) Các việc cốt lõi cần làm
Đây là các việc “core” thực tế mà hầu hết tenant hỗ trợ.
- Xem hồ sơ worker và các phân bổ tổ chức quan trọng.
- Yêu cầu/cập nhật thông tin cá nhân (nếu bật cho nhân viên).
- Khởi tạo thay đổi job/tổ chức (quản lý/HR).
- Đính kèm tài liệu hỗ trợ cho một giao dịch.
- Theo dõi thay đổi đã gửi từ phê duyệt đến hoàn tất.
8) Luồng chuẩn #1: Cập nhật thông tin cá nhân/liên hệ (nhân viên)
Dùng khi bạn cần cập nhật thông tin của chính mình mà tenant cho phép tự phục vụ.
- Tìm tác vụ liên quan (ví dụ: “Change Contact Information”).
- Xác nhận bạn đang sửa hồ sơ của chính mình (không phải người khác).
- Nhập các trường cập nhật; giữ định dạng nhất quán (điện thoại, địa chỉ).
- Đính kèm giấy tờ nếu tenant yêu cầu (hiếm; tuỳ tenant).
- Gửi và đọc thông báo xác nhận.
- Kiểm tra Inbox để xem có tác vụ follow-up không.
- Xác minh thông tin mới hiển thị trên hồ sơ của bạn.
9) Luồng chuẩn #2: Khởi tạo thay đổi cho team (quản lý)
Dùng khi bạn cần một thay đổi chuẩn (chuyển org, đổi job) với vai trò quản lý và được cấp quyền.
- Mở worker record (thành viên trong team).
- Dùng Related Actions → chọn tác vụ phù hợp kiểu “Change Job/Move Worker” (tên tuỳ tenant).
- Đặt effective date và lý do.
- Điền kỹ các trường org/position/job bắt buộc.
- Xem lại các tác động (comp, location, costing) nếu hệ thống hiển thị.
- Gửi và xác nhận route/luồng phê duyệt.
- Theo dõi Inbox để xử lý các tác vụ follow-up bạn sở hữu.
10) Điểm quyết định
| Tình huống | Nếu A… | Nếu B… |
|---|---|---|
| Mô hình Position vs Job | Nếu tenant quản lý theo position, chọn đúng position và kiểm tra còn “trống/khả dụng”. | Nếu quản lý theo job, đảm bảo job profile + phân bổ org là đúng. |
| Lẫn lộn effective date | Nếu change có hiệu lực tương lai, xác nhận các hệ thống downstream hiểu đúng mốc thời gian. | Nếu hiệu lực ngay, đảm bảo phê duyệt kịp (hoặc điều chỉnh effective date). |
| Thiếu trường bắt buộc | Tìm help text/gợi ý trong UI; điền trường bắt buộc trước. | Nếu bạn không có dữ liệu, dừng lại và yêu cầu HR/admin cung cấp. |
| Bị chặn do bảo mật | Nếu đúng kỳ vọng, escalte tới HR/chủ sở hữu security role. | Nếu bất thường, xác minh bạn đang ở đúng worker/org và đúng tác vụ. |
11) Lỗi thường gặp (và cách tránh)
- Lỗi: Bỏ qua effective date. Tránh: luôn xác nhận khi nào thay đổi có hiệu lực.
- Lỗi: Chọn sai org. Tránh: đối chiếu supervisory org và tuyến quản lý.
- Lỗi: Gửi thiếu lý do/bình luận. Tránh: dùng reason codes bắt buộc để phục vụ audit/báo cáo.
- Lỗi: Coi Workday như bảng tính. Tránh: dùng giao dịch + phê duyệt (BPF), không chỉnh tay.
- Lỗi: Chia sẻ rộng dữ liệu worker đã xuất. Tránh: theo nguyên tắc tối thiểu quyền và chính sách.
12) Quyền hạn & Vai trò
Các thao tác Core HCM được kiểm soát rất chặt theo vai trò; quản lý/HR có thể thấy các tác vụ khác nhau trên cùng một worker record.
13) Dữ liệu & Tích hợp
Dữ liệu worker/org nền tảng thường cấp cho báo cáo và tích hợp; nếu tenant có mở, hãy dùng API/dịch vụ chính thức.
14) Thế nào là “làm tốt”
- Thay đổi được gửi qua đúng tác vụ và được route đúng.
- Effective dates và lý do nhất quán, truy vết được.
- Record nhất quán giữa các module liên quan (absence, recruiting, analytics).
- Tôn trọng ranh giới security/quyền truy cập.
15) Checklist: Trước khi làm + Sau khi làm
Pre-check
- Mình biết đang đổi đối tượng nào (worker/org/position).
- Mình có đúng effective date + lý do.
- Mình xác minh có quyền thực hiện hành động này.
- Mình đã thu thập đủ trường/tài liệu bắt buộc.
- Mình hiểu luồng phê duyệt/owner khả dĩ.
Post-check
- Mình nhận được xác nhận và/hoặc trạng thái process.
- Mình hoàn thành các tác vụ follow-up trong Inbox.
- Mình xác minh worker record phản ánh đúng thay đổi.
- Mình ghi chú/bình luận đủ rõ cho audit.
- Mình thông báo stakeholders (nếu chính sách yêu cầu).
16) Bài lab (5–15 phút)
Mục tiêu: nắm layout worker record và các hành động an toàn.
- Mở worker record của bạn và tìm org/manager và thông tin liên hệ.
- Dùng Related Actions và liệt kê hành động nào thấy/không thấy (được phép vs bị ẩn).
- Tìm một report “View” cho org/team của bạn và thử áp bộ lọc.
- Nếu được phép xuất (export), thực hành xử lý an toàn: lưu/xoá theo chính sách.
17) Link tài liệu chính thức
- Tổng quan Workday HCM (các khu vực cốt lõi trong HCM).
- Workday business process framework (cơ chế route giao dịch).
Tuyển dụng & Nhận việc
- Hiểu luồng tuyển dụng phổ biến: lập kế hoạch/yêu cầu tuyển → ứng viên → offer → hire.
- Nắm vai trò quản lý vs HR thường làm gì trong các bước tuyển dụng của Workday.
- Luyện kiểm tra an toàn trước khi phê duyệt (org, lương/đãi ngộ, tài liệu).
- Biết business process framework điều khiển phê duyệt và tác vụ như thế nào.
1) Mục đích / Kết quả
Tuyển dụng & Nhận việc bao quát quy trình đưa một nhân sự mới vào tổ chức—từ mở vị trí đến chuyển đổi ứng viên thành worker record. Kết quả cần đạt: thực hiện các bước hire gọn gàng, có đủ phê duyệt và tài liệu đúng.
- Khởi tạo hoặc rà soát yêu cầu tuyển với thông tin vai trò chính xác.
- Theo dõi ứng viên qua các giai đoạn (giai đoạn tuỳ tenant).
- Chuẩn bị/soát xét offer và ghi nhận việc chấp nhận.
- Hire ứng viên đã chấp nhận vào job/position với dữ liệu đúng.
2) Dành cho ai + Khi nào nên dùng
Quản lý thường khởi tạo nhu cầu tuyển và phê duyệt; HR thường quản lý offer và các bước tuân thủ. Dùng tab này khi bạn cần chuyển ứng viên sang hire mà không làm vỡ phê duyệt hoặc chất lượng dữ liệu.
- Quản lý tuyển dụng: phê duyệt requisition, phản hồi phỏng vấn, phê duyệt cuối.
- Recruiter/HR: tạo offer, bàn giao onboarding, các bước tuân thủ.
- Người phê duyệt: lãnh đạo tổ chức, chủ ngân sách (tuỳ tenant).
- Dùng trước khi phê duyệt offer/hire để kiểm tra lương và ngày bắt đầu.
3) Vị trí trên điều hướng + Tab liên quan
Điểm vào thường gặp: worklet/app Recruiting/Hiring, Search các tác vụ “Hire”, phê duyệt trong Inbox. Tab liên quan: Core HCM Business Processes Security.
- Dùng pipeline tuyển dụng/danh sách ứng viên (nếu bật).
- Mở requisition/candidate record, sau đó dùng Related Actions.
- Dùng Inbox để phê duyệt offer/các bước hire.
- Kiểm tra process status/history nếu bị kẹt ở khâu bàn giao.
4) Mô hình tư duy / Luồng
Tuyển dụng thường bắt đầu bằng một yêu cầu và kết thúc ở worker record—được điều khiển bởi business processes. Ứng viên thường trở thành pre-hire (thường gặp) rồi được hire vào position/job với effective dates.
- Tạo/phê duyệt requisition hoặc yêu cầu tuyển (tuỳ tenant).
- Đẩy ứng viên qua các giai đoạn; ghi nhận feedback phỏng vấn.
- Chuẩn bị offer → review → gửi ký điện tử/chấp nhận.
- Hire nhân sự vào position/job; kích hoạt các tác vụ onboarding.
5) Đối tượng & Thuật ngữ
- Job Requisition: yêu cầu tuyển đã được phê duyệt.
- Candidate: hồ sơ ứng viên trong pipeline.
- Pre-hire: hồ sơ tiền nhân viên dùng trước khi hire (khái niệm phổ biến).
- Offer: lương và điều khoản cần review/phê duyệt.
- Hire: giao dịch tạo/kích hoạt một worker.
- Business Process: bộ máy điều phối phê duyệt/tác vụ.
6) Máy trạng thái / Vòng đời
Tuyển dụng dựa trên các giai đoạn. Giai đoạn cụ thể tuỳ tenant, nhưng ý tưởng nhất quán: ứng viên tiến dần tới chấp nhận, rồi hire hoàn tất.
- Các giai đoạn pipeline: applied → screening → interview → offer → accepted (nhãn có thể khác).
- Trạng thái offer: draft → review → sent → accepted/declined.
- Trạng thái hire: initiated → approvals → completed (worker active vào ngày bắt đầu).
- Nếu bị từ chối: ứng viên có thể quay lại giai đoạn trước hoặc đóng theo quy tắc process.
7) Các việc cốt lõi cần làm
- Khởi tạo yêu cầu tuyển/requisition (quản lý/HR tuỳ tenant).
- Đẩy giai đoạn ứng viên và ghi nhận feedback.
- Chuẩn bị và route offer để review và ký.
- Hire ứng viên vào vị trí/job đang mở.
- Xác nhận các tác vụ onboarding và đồng bộ ngày bắt đầu.
8) Luồng chuẩn #1: Offer → chấp nhận (quản lý + HR)
Luồng này phù hợp với thực hành phổ biến: HR chuẩn bị offer và quản lý review trước khi gửi.
- HR chuẩn bị chi tiết offer (lương, ngày bắt đầu, địa điểm).
- Quản lý review offer trong Workday và thêm bình luận nếu cần.
- HR route offer cho các phê duyệt bắt buộc (ngân sách/lãnh đạo).
- Thư mời được tạo và gửi ký điện tử (tuỳ tenant).
- Ứng viên chấp nhận; trạng thái cập nhật trong Workday.
- HR thông báo quản lý và chuyển sang bước hire.
9) Luồng chuẩn #2: Hire một nhân sự vào position/job
Tập trung vào “giao dịch hire” để worker record active với dữ liệu org và vai trò đúng.
- Mở hồ sơ candidate/pre-hire đã được chấp nhận.
- Bắt đầu tác vụ “Hire” (tên tác vụ tuỳ tenant).
- Chọn position/job opening (hoặc job profile) và supervisory org.
- Nhập start date/effective date và các thông tin chính (location, time type).
- Review chi tiết compensation nếu có trong luồng.
- Đính kèm tài liệu bắt buộc (nếu tenant yêu cầu).
- Gửi và theo dõi phê duyệt qua Inbox/status.
10) Điểm quyết định
| Tình huống | Nếu A… | Nếu B… |
|---|---|---|
| Yêu cầu background check | Nếu bắt buộc, đảm bảo đã khởi tạo và theo dõi trước khi hire cuối. | Nếu tuỳ chọn, ghi nhận quyết định theo chính sách và tiếp tục. |
| Chưa chắc về compensation | Nếu đã chốt, “khoá” chi tiết trong bước offer/hire. | Nếu chưa, tạm dừng và thống nhất với HR/đội comp trước khi gửi offer. |
| Position có sẵn? | Nếu position đang mở, gán ứng viên vào position đó khi hire. | Nếu chưa có, phối hợp tạo/mở position hoặc dùng luồng job-managed. |
| Phê duyệt bị chậm | Nếu thấy được người sở hữu bước tiếp theo, nhắc nhẹ kèm ngữ cảnh. | Nếu không thấy, nhờ HR/support truy vết owner của bước trong business process. |
11) Lỗi thường gặp (và cách tránh)
- Lỗi: Gửi offer khi chưa xong phê duyệt. Tránh: xác nhận các bước phê duyệt đã hoàn tất trước khi gửi.
- Lỗi: Gán sai supervisory org/manager. Tránh: kiểm tra tuyến báo cáo trước khi hire hoàn tất.
- Lỗi: Ngày bắt đầu lệch giữa các bước. Tránh: dùng một start date “chuẩn” và tái sử dụng.
- Lỗi: Thiếu file đính kèm/tài liệu chính sách. Tránh: dùng checklist theo vai trò/quốc gia.
- Lỗi: Hire vào sai position/job profile. Tránh: đối chiếu mã requisition/position.
12) Quyền hạn & Vai trò
Các tác vụ và phê duyệt tuyển dụng phụ thuộc phân quyền (manager, recruiter, HR partner, leadership). Security của tenant quyết định ai được khởi tạo vs ai được phê duyệt.
13) Dữ liệu & Tích hợp
Tuyển dụng thường tích hợp với background check và công cụ ký điện tử (tuỳ tenant). Nếu tenant mở API, dịch vụ sẽ nằm trong các thư mục chính thức.
14) Thế nào là “làm tốt”
- Dữ liệu offer và hire khớp nhau (start date, location, comp).
- Phê duyệt đầy đủ và truy vết được.
- Chuyển đổi candidate → worker sạch, ít phải sửa lại.
- Bàn giao onboarding tự động bắt đầu (hoặc được kích hoạt rõ ràng).
15) Checklist: Trước khi làm + Sau khi làm
Pre-check
- Requisition/position đã được phê duyệt và đang mở.
- Chi tiết offer đầy đủ và đã được review.
- Đã xác định người phê duyệt và họ sẵn sàng.
- Start date và manager/org đã được xác nhận.
- Các mục tuân thủ (tài liệu/kiểm tra) đã rõ.
Post-check
- Offer hiển thị trạng thái accepted (hoặc đã ký).
- Giao dịch hire đã được gửi và được route.
- Worker record được tạo/active vào ngày bắt đầu.
- Tác vụ onboarding đã được khởi chạy/gán.
- Stakeholders được thông báo theo quy trình.
16) Bài lab (5–15 phút)
Mục tiêu: học luồng tuyển dụng mà không tạo thay đổi thật (dùng sandbox nếu có).
- Xem một demo tuyển dụng chính thống/ngắn để nắm thuật ngữ.
- Trong tenant (hoặc training tenant), tìm tác vụ “Hire” và mở để xem trường bắt buộc (không gửi).
- Mở một hồ sơ candidate/pre-hire mẫu (nếu có dữ liệu training) và khám phá Related Actions.
- Liệt kê những phê duyệt có khả năng xảy ra trong tổ chức của bạn.
17) Link tài liệu chính thức
- Khung “employee journey” của Workday HCM (plan to hire → retire).
- Các demo quy trình tuyển dụng (tổng quan giao dịch hire).
- Business process framework (bộ máy phê duyệt/luồng công việc).
Năng lực & Hiệu suất (Tổng quan)
- Talent Management thường bao gồm gì: mục tiêu, hiệu suất, phát triển, kế nhiệm (tuỳ tenant).
- Cách tiếp cận các chu kỳ nhân tài bằng checklist và mục tiêu đầu ra rõ ràng.
- Phê duyệt và vai trò có thể áp dụng thế nào (quản lý vs nhân viên vs HR).
- Nếu tenant của bạn không bật một tính năng con: đánh dấu là N/A.
1) Mục đích / Kết quả
Các tính năng nhân tài và hiệu suất giúp tổ chức phát triển, đánh giá và giữ chân con người. Kết quả cần đạt: hoàn thành một chu kỳ nhân tài (đặt mục tiêu, check-in, review) với dữ liệu nhất quán và tài liệu hoá rõ ràng.
- Đặt/đồng bộ mục tiêu (nếu bật) và giữ mục tiêu đo lường được.
- Ghi nhận feedback và check-in nhất quán.
- Hoàn thành tác vụ review đúng hạn qua Inbox.
- Dùng báo cáo để theo dõi mức độ hoàn tất và chất lượng.
2) Dành cho ai + Khi nào nên dùng
Quản lý và nhân viên dùng các tính năng nhân tài trong các chu kỳ mục tiêu và review. HR/People thiết lập chu kỳ và theo dõi tỷ lệ hoàn tất.
- Nhân viên: mục tiêu, tự đánh giá, kế hoạch phát triển (nếu bật).
- Quản lý: check-in, đánh giá, dữ liệu cho hiệu chỉnh (calibration) (nếu bật).
- HR: thiết lập chu kỳ, tiêu chí đủ điều kiện, nhắc hạn, báo cáo.
- Dùng tab này ở đầu chu kỳ và trước các deadline.
3) Vị trí trên điều hướng + Tab liên quan
Điểm vào thường gặp: worklet/app Talent/Performance, tác vụ trong Inbox, và trang worker/team. Liên quan: Core HCM Reporting & Analytics Business Processes.
- Tìm bằng Search các tác vụ “Goals”, “Performance Review”, “Feedback” (tên có thể khác).
- Dùng Inbox cho tác vụ review và phê duyệt.
- Dùng dashboard đội nhóm (nếu có) để theo dõi tiến độ.
- Dùng báo cáo để tìm các mục chưa nộp.
4) Mô hình tư duy / Luồng
Chu kỳ nhân tài là luồng công việc có khung thời gian: tác vụ được giao cho nhân viên/quản lý, được route phê duyệt khi cần, rồi đóng để phục vụ báo cáo.
- Chu kỳ mở → tác vụ xuất hiện trong Inbox.
- Nhân viên/quản lý hoàn thành biểu mẫu và thêm bình luận.
- Các bước phê duyệt/calibration (tuỳ chọn) được route theo vai trò.
- Chu kỳ đóng → bắt đầu báo cáo và lập kế hoạch chu kỳ tiếp theo.
5) Đối tượng & Thuật ngữ
- Mục tiêu (Goal): kết quả đo lường được; có thể roll-up lên mục tiêu đội (nếu bật).
- Đánh giá (Review): tài liệu/tác vụ đánh giá có điểm/bình luận (nếu bật).
- Phản hồi (Feedback): ghi chú trong suốt chu kỳ (nếu bật).
- Kế hoạch phát triển (Development Plan): kế hoạch học tập/phát triển (nếu bật).
- Business Process: bộ máy điều phối tác vụ/phê duyệt.
6) Máy trạng thái / Vòng đời
Các artefact của chu kỳ thường đi từ draft → submitted → completed, có thể có bước phê duyệt của quản lý hoặc calibration.
- Draft: đang làm dở.
- Submitted: chờ quản lý/bước tiếp theo.
- In progress: đang route qua các tác vụ phê duyệt/calibration.
- Completed: đã đóng và có thể báo cáo.
- Nếu tenant không bật: Không áp dụng cho tool/tab này
7) Các việc cốt lõi cần làm
- Tạo/cập nhật mục tiêu (nếu bật).
- Hoàn thành tự đánh giá (nếu bật) kèm bằng chứng và ví dụ.
- Hoàn thành đánh giá của quản lý và nộp đúng hạn.
- Chạy báo cáo hoàn tất và nhắc các mục còn thiếu.
- Ghi nhận quyết định và bước tiếp theo (kế hoạch phát triển).
8) Luồng chuẩn #1: Nhân viên hoàn thành tự đánh giá
Dùng khi chu kỳ mở và bạn nhận tác vụ tự đánh giá.
- Mở Inbox và bắt đầu tác vụ self-review.
- Xem lại mục tiêu/kỳ vọng vai trò (nếu hiển thị).
- Viết 3–5 bullet bằng chứng (dự án, chỉ số, kết quả).
- Nêu phần học được và điểm cần cải thiện kèm hành động.
- Lưu nháp, đọc lại cho rõ ràng, rồi submit.
- Xác nhận trạng thái đã nộp và người sở hữu bước tiếp theo.
9) Luồng chuẩn #2: Quản lý hoàn thành đánh giá + nộp
Dùng khi bạn nhận tác vụ đánh giá cho nhân sự báo cáo trực tiếp.
- Mở Inbox và chọn review của một nhân sự.
- Đọc self-review và ghi chú hỗ trợ.
- Thêm rating/bình luận theo rubric của tổ chức (nếu bật).
- Ghi nhận điểm mạnh bằng ví dụ cụ thể.
- Ghi nhận điểm cần phát triển kèm kế hoạch cụ thể.
- Submit và xác nhận bước tiếp theo (calibration/acknowledgement).
10) Điểm quyết định
| Tình huống | Nếu A… | Nếu B… |
|---|---|---|
| Tenant có rating | Dùng rubric; đảm bảo bình luận nhất quán với điểm. | Nếu không có điểm, dùng mô tả có cấu trúc + kết quả đo lường được. |
| Có bước calibration | Chỉ nộp khi bạn đã sẵn sàng cho trao đổi calibration. | Nếu không có, nộp sớm và tập trung rõ ràng + bằng chứng. |
| Nộp trễ | Chạy báo cáo hoàn tất và nhắc kèm hạn. | Nếu có blocker, escalate cho HR/People Ops để xử lý deadline. |
| Tính năng không bật | Dùng quy trình HR thay thế (tài liệu/biểu mẫu ngoài Workday). | Đánh dấu Không áp dụng và không tự bịa bước. |
11) Lỗi thường gặp (và cách tránh)
- Lỗi: Bình luận mơ hồ. Tránh: dùng bằng chứng + kết quả + hành động tiếp theo.
- Lỗi: Điểm không khớp với nội dung. Tránh: đối chiếu rubric và ví dụ.
- Lỗi: Dồn hết vào ngày deadline. Tránh: nháp sớm, rồi tinh chỉnh.
- Lỗi: “Bất ngờ” trong review. Tránh: ghi feedback xuyên suốt chu kỳ.
- Lỗi: Dùng Workday khi tính năng chưa bật. Tránh: xác nhận khả năng tenant trước.
12) Quyền hạn & Vai trò
Quyền truy cập phụ thuộc vai trò (nhân viên/quản lý/HR) và phạm vi tổ chức; tác vụ được route qua business processes.
13) Dữ liệu & Tích hợp
Không áp dụng cho tool/tab này (nguồn chính thức công khai trong lần chạy này không nêu chi tiết tích hợp Talent; phụ thuộc tenant).
14) Thế nào là “làm tốt”
- Bài nộp đầy đủ, dựa trên bằng chứng, nhất quán trong đội.
- Quản lý nộp đúng hạn; ít phải sửa sau calibration.
- Hành động phát triển rõ ràng và theo dõi được.
15) Checklist: Trước khi làm + Sau khi làm
Pre-check
- Tôi biết hạn nộp và các phần bắt buộc.
- Tôi đã gom bằng chứng (dự án/chỉ số/feedback).
- Tôi hiểu rubric (nếu có).
- Tôi biết ai review/phê duyệt bước tiếp theo.
- Tôi đã xác nhận tính năng đang bật trong tenant.
Post-check
- Trạng thái hiển thị submitted/completed.
- Bình luận cụ thể và mang tính xây dựng.
- Bước tiếp theo được ghi lại (hành động phát triển).
- Báo cáo hoàn tất của đội “ổn”.
- Audit trail rõ ràng (không thiếu ngữ cảnh).
16) Bài lab (5–15 phút)
Mục tiêu: luyện viết feedback dựa trên bằng chứng thật nhanh.
- Nháp 3 mục tiêu đo lường được cho vai trò của bạn (kể cả viết offline).
- Viết 1 đoạn self-review cho mỗi mục tiêu: kết quả + bằng chứng + bài học.
- Viết 1 ghi chú feedback kiểu quản lý: điểm mạnh + gợi ý + hành động.
- Nếu tenant có tác vụ Talent, mở tác vụ và map các trường với bản nháp (không submit).
17) Link tài liệu chính thức
- Tổng quan Workday HCM thường bao gồm Talent Management như một mảng cốt lõi.
- Business process framework (cách tác vụ/phê duyệt được route).
Nghỉ phép & Quản lý vắng mặt
- Tìm hiểu Absence Management hỗ trợ gì: yêu cầu nghỉ phép/nghỉ dài hạn, số dư, tích lũy, phê duyệt.
- Luyện luồng nhân viên gửi yêu cầu và luồng quản lý phê duyệt.
- Hiểu các quy tắc theo chính sách (điều kiện, kiểm tra trùng lịch) là tuỳ tenant.
- Biết nơi kiểm tra số dư và trạng thái yêu cầu.
1) Mục đích / Kết quả
Workday Absence Management giúp quản lý nghỉ phép và nghỉ dài hạn với phê duyệt, theo dõi và báo cáo. Kết quả cần đạt: gửi yêu cầu đúng, phê duyệt có trách nhiệm, và giữ số dư chính xác.
- Nhân viên gửi yêu cầu nghỉ theo cách nhất quán, đúng chính sách.
- Quản lý duyệt/từ chối dựa trên bối cảnh và khả năng bố trí nhân sự.
- Nhóm có thể xem số dư và tránh xung đột lịch.
- Phê duyệt và lịch sử kiểm toán rõ ràng.
2) Dành cho ai + Khi nào nên dùng
Nhân viên dùng để xin nghỉ và xem số dư. Quản lý dùng để duyệt yêu cầu và quản lý “coverage”. HR/People cấu hình chính sách và theo dõi tuân thủ.
- Nhân viên: xin nghỉ, xem số dư/tích lũy.
- Quản lý: duyệt yêu cầu, theo dõi trùng lịch, xem dashboard (nếu bật).
- HR: định nghĩa chính sách/kế hoạch nghỉ (cấu hình tenant).
- Dùng tab này trước các mùa cao điểm nghỉ lễ để giảm xung đột.
3) Vị trí trên điều hướng + Tab liên quan
Điểm vào thường gặp: worklet/app Absence/Time Off, Search “Request Time Off”, phê duyệt trong Inbox. Liên quan: Business Processes Reporting Security.
- Nhân viên: Home → Time Off/Absence.
- Quản lý: phê duyệt trong Inbox + dashboard đội nhóm (nếu có).
- Dùng lịch (nếu tích hợp) để kiểm tra trùng lịch khi duyệt.
- Dùng báo cáo để phát hiện xu hướng và rủi ro tuân thủ.
4) Mô hình tư duy / Luồng
Các thao tác vắng mặt là luồng theo chính sách. Bạn gửi yêu cầu, Workday kiểm tra điều kiện và số dư, route phê duyệt, rồi cập nhật số dư và lịch.
- Nhân viên gửi yêu cầu nghỉ với ngày và loại nghỉ.
- Hệ thống kiểm tra quy tắc (số dư, điều kiện, trùng lịch).
- Phê duyệt được route đến quản lý/vai trò theo chính sách.
- Hoàn tất sẽ cập nhật số dư và hiển thị cho việc lập kế hoạch.
5) Đối tượng & Thuật ngữ
- Nghỉ phép (Time Off): các vắng mặt ngắn (phép năm, ốm) tuỳ chính sách.
- Nghỉ dài hạn (Leave of Absence): loại nghỉ dài hoặc theo quy định.
- Số dư (Balance): thời gian nghỉ còn lại theo tích lũy/chính sách.
- Tích lũy (Accrual): quy tắc cộng dồn ngày/giờ nghỉ.
- Phê duyệt (Approval): được route qua các bước business process.
6) Máy trạng thái / Vòng đời
- Draft → Submitted → Chờ phê duyệt → Approved/Denied.
- Yêu cầu đã duyệt có thể hủy theo chính sách.
- Hồ sơ nghỉ dài hạn có thể có bước nộp tài liệu bổ sung (tuỳ tenant).
- Trạng thái và thuật ngữ có thể khác nhau theo cấu hình tenant.
7) Các việc cốt lõi cần làm
- Gửi yêu cầu nghỉ với đúng loại và đúng ngày.
- Kiểm tra số dư và tránh xin vượt số dư.
- Quản lý xem trùng lịch và duyệt/từ chối.
- Hủy hoặc chỉnh sửa yêu cầu khi kế hoạch thay đổi.
- Báo cáo xu hướng nghỉ để lập kế hoạch (nếu bật).
8) Luồng chuẩn #1: Nhân viên xin nghỉ
Dùng khi bạn cần xin nghỉ phép hoặc một loại nghỉ mà tenant của bạn hỗ trợ.
- Mở khu vực Absence/Time Off hoặc tìm “Request Time Off”.
- Chọn đúng loại nghỉ (phép năm/ốm/...).
- Nhập ngày bắt đầu/kết thúc và thông tin nghỉ nửa ngày/1 phần ngày nếu cần.
- Xem tác động lên số dư (nếu có hiển thị).
- Thêm ghi chú giúp quản lý hiểu bối cảnh (tuỳ chọn nhưng hữu ích).
- Submit và đọc thông báo trạng thái.
- Kiểm tra trạng thái yêu cầu và màn hình số dư sau đó.
9) Luồng chuẩn #2: Quản lý duyệt nghỉ
Dùng khi bạn nhận phê duyệt nghỉ trong Inbox.
- Mở Inbox và chọn yêu cầu nghỉ.
- Xem ngày, loại nghỉ, và ghi chú của nhân viên.
- Kiểm tra coverage/trùng lịch đội nhóm (lịch/dashboard nếu có).
- Xác nhận dấu hiệu tuân thủ chính sách (gợi ý số dư/điều kiện).
- Duyệt hoặc từ chối; nếu từ chối thì nêu lý do.
- Xác nhận hoàn tất và thông báo cho nhân viên nếu cần.
10) Điểm quyết định
| Tình huống | Nếu A… | Nếu B… |
|---|---|---|
| Không đủ số dư | Nếu chính sách cho phép âm/ứng trước, tiếp tục kèm hướng dẫn. | Nếu không cho phép, chỉnh ngày/loại hoặc từ chối kèm lý do. |
| Trùng lịch nghỉ | Nếu coverage ổn, duyệt và ghi rõ kỳ vọng. | Nếu coverage rủi ro, thỏa thuận ngày khác trước khi duyệt. |
| Nghỉ dài hạn cần tài liệu | Nếu bắt buộc, yêu cầu/tải lên tài liệu và theo đúng bước chính sách. | Nếu không bắt buộc, xử lý như phê duyệt bình thường. |
| Cần đổi yêu cầu sau khi đã duyệt | Nếu chính sách cho phép, hủy/chỉnh và gửi lại. | Nếu chính sách hạn chế, liên hệ HR/admin để xử lý quy trình chỉnh sửa. |
11) Lỗi thường gặp (và cách tránh)
- Lỗi: Chọn sai loại nghỉ. Tránh: xác nhận định nghĩa loại nghỉ trong danh mục chính sách.
- Lỗi: Quên thiết lập nghỉ nửa ngày/1 phần ngày. Tránh: kiểm tra tuỳ chọn giờ/nửa ngày nếu áp dụng.
- Lỗi: Duyệt mà không kiểm tra trùng lịch. Tránh: xem nhanh lịch đội nhóm hoặc dashboard.
- Lỗi: Không ghi chú ngoại lệ. Tránh: thêm comment để rõ ràng cho audit.
- Lỗi: Nghĩ số dư cập nhật ngay lập tức. Tránh: kiểm tra lại sau khi phê duyệt hoàn tất.
12) Quyền hạn & Vai trò
Phê duyệt và khả năng nhìn thấy phụ thuộc vai trò bảo mật (nhân viên vs quản lý vs HR) và phạm vi tổ chức.
13) Dữ liệu & Tích hợp
Workday cung cấp dịch vụ Absence Management để truy cập thông tin nghỉ của nhân sự và gửi yêu cầu nghỉ (khả năng API tuỳ tenant).
- Dùng service/API chính thức khi tổ chức bạn hỗ trợ tích hợp.
- Đảm bảo tuân thủ bảo mật và quy tắc chia sẻ dữ liệu.
- Xác thực hành động qua API khớp với chính sách và phê duyệt trong UI.
- Ghi log và giám sát yêu cầu để audit và xử lý sự cố.
14) Thế nào là “làm tốt”
- Yêu cầu chính xác (loại/ngày) và được duyệt có bối cảnh.
- Số dư và lịch luôn nhất quán.
- Quản lý chủ động coverage nhờ công cụ hiển thị.
- Audit trail có lý do rõ ràng cho ngoại lệ/từ chối.
15) Checklist: Trước khi làm + Sau khi làm
Pre-check
- Tôi đã chọn đúng loại nghỉ.
- Tôi đã xác nhận ngày/nửa ngày.
- Tôi đã kiểm tra tác động số dư (nếu hiển thị).
- Tôi đã cân nhắc trùng lịch/coverage.
- Tôi đã thêm ghi chú nếu cần để người duyệt hiểu rõ.
Post-check
- Trạng thái đúng như kỳ vọng (duyệt/từ chối/đang chờ).
- Số dư phản ánh kết quả.
- Quản lý/nhân viên thấy yêu cầu trong lịch sử.
- Lịch/hiển thị được cập nhật (nếu bật).
- Các tác vụ follow-up (nếu có) đã hoàn thành.
16) Bài lab (5–15 phút)
Mục tiêu: quen tay với việc gửi yêu cầu và theo dõi trạng thái.
- Mở màn hình số dư và ghi lại số nghỉ hiện có.
- Bắt đầu một yêu cầu nghỉ và điền đến bước xem lại (đừng submit nếu không nên).
- Tìm vị trí hiển thị lịch sử/trạng thái yêu cầu trong tenant của bạn.
- Nếu bạn là quản lý, mở một mục phê duyệt và xem các dấu hiệu coverage.
17) Link tài liệu chính thức
- Khả năng Workday Absence Management (các chức năng chính và trải nghiệm).
- Workday REST API directory (danh mục dịch vụ Absence Management).
Bảo mật & Phân quyền
- Hiểu mô hình truy cập theo vai trò (role-based): bạn nhìn thấy/làm được gì phụ thuộc vào vai trò bảo mật và phạm vi tổ chức được gán.
- Nắm 2 vùng kiểm soát bảo mật thường gặp: quyền theo domain (dữ liệu) và quyền theo business process (hành động/phê duyệt).
- Luyện luồng xử lý an toàn khi thiếu nút/hành động trong UI.
- Biết bảo mật ảnh hưởng thế nào đến tích hợp và quyền API.
1) Mục đích / Kết quả
Bảo mật đảm bảo mỗi người chỉ thấy và chỉ làm những gì họ được phép trong Workday. Kết quả bạn cần đạt: hiểu vì sao quyền khác nhau theo người dùng, yêu cầu cấp quyền đúng cách, và tránh “lách” rủi ro.
- Nhận biết vai trò bảo mật và phạm vi của vai trò (thường gắn theo tổ chức).
- Chẩn đoán lỗi “thiếu nút” mà không đoán mò.
- Yêu cầu thay đổi quyền qua kênh đúng (HRIS/security admin).
- Duy trì nguyên tắc tối thiểu quyền cho dữ liệu HR nhạy cảm.
2) Dành cho ai + Khi nào nên dùng
Dành cho HRIS/security admin, HR partner, và quản lý xử lý phê duyệt hoặc dữ liệu nhạy cảm. Dùng khi quyền có vẻ “sai” hoặc khi onboarding vai trò/người dùng mới.
- HRIS/Security: cấu hình vai trò/nhóm và chính sách.
- HR/Quản lý: hiểu route phê duyệt và giới hạn truy cập.
- Nhân viên: hiểu vì sao bạn không thấy một số dữ liệu/hành động.
- Dùng sau khi đổi vai trò, chuyển tổ chức, hoặc triển khai quy trình mới.
3) Vị trí trên điều hướng + Tab liên quan
Cấu hình bảo mật thường chỉ dành cho admin thông qua các tác vụ security. Tab liên quan: Business Processes Integrations & APIs Core HCM.
- Admin dùng các tác vụ như tạo/cấu hình security groups (tên tác vụ tuỳ tenant).
- Người dùng “cảm” bảo mật qua việc họ thấy gì trên record và thấy được task nào.
- Phê duyệt phụ thuộc vai trò trong business process và cách gán phạm vi.
- Quyền API cũng theo cùng mô hình bảo mật này.
4) Mô hình tư duy / Luồng
Bảo mật = “ai + phạm vi + quyền”. Vai trò/nhóm cấp quyền, phạm vi thường định nghĩa theo tổ chức, và chính sách áp vào domain (dữ liệu) và business process (hành động/phê duyệt).
- Gán người dùng vào security group/role.
- Định nghĩa phạm vi (áp lên org/worker/data nào).
- Cấp domain access (xem/sửa dữ liệu).
- Cấp quyền theo business process policy (khởi tạo/duyệt các bước).
5) Đối tượng & Thuật ngữ
- Vai trò bảo mật (Security Role): vai trò được gán cho người dùng để thực hiện/duyệt/hỗ trợ theo phạm vi tổ chức.
- Nhóm bảo mật (Security Group): cấu trúc nhóm dùng cho phân quyền (tuỳ tenant).
- Bảo mật theo domain (Domain Security): kiểm soát quyền dữ liệu (xem/sửa).
- Chính sách business process (Business Process Policy): ai được khởi tạo/duyệt từng bước.
- Nguyên tắc tối thiểu quyền (Least Privilege): chỉ cấp đúng cái cần thiết.
6) Máy trạng thái / Vòng đời
Thay đổi bảo mật thường theo luồng: yêu cầu → phê duyệt → gán quyền → có hiệu lực (đôi khi có thời điểm/effective date). Vòng đời cụ thể tuỳ tenant.
- Requested: người dùng cần quyền do đổi vai trò.
- Approved: chủ sở hữu bảo mật xác nhận lý do.
- Assigned: áp roles/groups kèm phạm vi.
- Validated: người dùng test quyền; lỗi được chỉnh.
7) Các việc cốt lõi cần làm
- Giải thích vì sao 2 người thấy hành động khác nhau trên cùng một record.
- Yêu cầu/gán vai trò với phạm vi đúng (theo org).
- Xử lý an toàn lỗi thiếu task/nút.
- Đảm bảo phê duyệt route đến vai trò dự kiến.
- Đồng bộ quyền API/tích hợp với chính sách bảo mật.
8) Luồng chuẩn #1: Xử lý “thiếu hành động/nút”
Dùng khi ai đó nói “mình không thấy hành động mà người khác có.” Mục tiêu: tách bạch đó là vấn đề điều hướng, ngữ cảnh object, hay bảo mật.
- Xác nhận người dùng đang ở đúng object (worker vs position vs org).
- Xác nhận họ dùng đúng tenant/môi trường (prod vs sandbox).
- Yêu cầu họ tìm trực tiếp tên task bằng Search để loại trừ vấn đề vị trí UI.
- So sánh với người dùng “chuẩn”: cùng phạm vi org và cùng role không?
- Kiểm tra hành động đó có gắn với một bước trong business process policy không.
- Escalate lên security admin kèm chi tiết: user, object, task, org, thời điểm.
9) Luồng chuẩn #2: Onboard vai trò mới (admin)
Dùng khi một team/chức năng mới cần quyền Workday.
- Xác định trách nhiệm và danh sách task tối thiểu cần có.
- Ánh xạ trách nhiệm → roles/groups (ưu tiên dùng cái có sẵn).
- Định nghĩa phạm vi (org/worker nào) cho việc gán vai trò.
- Test với 1 người dùng pilot trên sandbox/training tenant.
- Xác minh quyền nhìn thấy dữ liệu theo domain và quyền thực hiện task.
- Xác minh route/phê duyệt business process với vai trò đó.
- Rollout rộng và tài liệu hoá quy trình “request access”.
10) Điểm quyết định
| Tình huống | Nếu A… | Nếu B… |
|---|---|---|
| Người dùng xem được dữ liệu nhưng không làm được hành động | Thường thiếu quyền trong business process policy. | Hoặc đang ở sai object/ngữ cảnh; kiểm tra lại loại record. |
| Người dùng làm được hành động nhưng không thấy các field cần thiết | Thường thiếu domain security cho các field bắt buộc. | Hoặc field bị ẩn theo điều kiện; kiểm tra điều kiện hiển thị/đủ điều kiện. |
| Tích hợp/API bị lỗi | Kiểm tra quyền service và security group của user tích hợp. | Hoặc service chưa bật cho tenant; xác nhận API được expose trước. |
| Rủi ro cấp quyền quá rộng | Giảm phạm vi hoặc tách vai trò thành nhóm nhỏ, an toàn hơn. | Dùng cơ chế phê duyệt/audit để bù (nhưng ưu tiên least privilege). |
11) Lỗi thường gặp (và cách tránh)
- Lỗi: Cấp quyền rộng “cho nhanh hết lỗi”. Tránh: least privilege + phạm vi đúng.
- Lỗi: Xử lý sự cố mà không có thông tin cụ thể. Tránh: ghi user, task, object, org, thời điểm.
- Lỗi: Nhầm domain security với business process security. Tránh: chẩn đoán theo câu hỏi: xem dữ liệu hay thực hiện hành động.
- Lỗi: Không test trên sandbox. Tránh: pilot và xác minh trước khi rollout.
- Lỗi: Quên rằng user tích hợp cũng cần phân quyền. Tránh: coi tích hợp như một user và cấp quyền có phạm vi.
12) Quyền hạn & Vai trò
Vai trò bảo mật cho phép người dùng xem xét, thực hiện hoặc phê duyệt tác vụ và hỗ trợ các tổ chức mà vai trò đó được gán.
- Duy trì catalog vai trò: vai trò nào dành cho công việc nào.
- Tài liệu hoá quy tắc phạm vi (role bao phủ org nào).
- Rà soát vai trò định kỳ (gỡ quyền không dùng).
- Tách nhiệm vụ (separation of duties) cho hành động nhạy cảm.
13) Dữ liệu & Tích hợp
API/service luôn áp dụng bảo mật; quyền của user tích hợp cần khớp với chính sách domain và business process.
14) Thế nào là “làm tốt”
- Người dùng chỉ có quyền cần thiết, được scope đúng.
- Phê duyệt route ổn định theo vai trò, không phụ thuộc cá nhân.
- Thay đổi bảo mật có thể audit và có lý do rõ ràng.
- Tích hợp cũng theo cùng nguyên tắc tối thiểu quyền.
15) Checklist: Trước khi làm + Sau khi làm
Pre-check
- Đã định nghĩa task cần thiết và phạm vi dữ liệu.
- Đã chọn đúng roles/groups hiện có.
- Đã xác nhận quy tắc phạm vi org.
- Đã xác nhận yêu cầu route phê duyệt.
- Đã lên kế hoạch test trên sandbox.
Post-check
- Người dùng làm được tác vụ end-to-end.
- Người dùng không truy cập được dữ liệu nhạy cảm không liên quan.
- Phê duyệt Inbox xuất hiện đúng người/đúng vai trò.
- Audit trail và tài liệu được cập nhật.
- User tích hợp được xác minh (nếu có).
16) Bài lab (5–15 phút)
Mục tiêu: luyện chẩn đoán bảo mật mà không cấp quyền quá tay.
- Chọn 1 task phổ biến (vd: duyệt nghỉ) và liệt kê vai trò cần thiết.
- Mô phỏng case “thiếu hành động” và điền template: user/task/object/org/time.
- Đề xuất thay đổi quyền tối thiểu (role + phạm vi) để sửa.
- Viết kế hoạch rollback ngắn (gỡ role nếu cấp quá rộng).
17) Link tài liệu chính thức
- Tổng quan vai trò bảo mật Workday (ví dụ: tài liệu hướng dẫn cấp tổ chức).
- Business process framework (vai trò và logic route trong workflow).
Quy trình nghiệp vụ & Phê duyệt (BPF)
- Hiểu Business Process Framework (BPF) của Workday như cơ chế tự động hoá workflow có sẵn.
- Nắm cách sự kiện (event) kích hoạt các bước, routing và phê duyệt.
- Luyện đọc một tác vụ phê duyệt và dự đoán bước tiếp theo.
- Áp dụng rào chắn an toàn: không bypass kiểm soát; cấu hình đúng cách.
1) Mục đích / Kết quả
Business Process Framework (BPF) là “động cơ workflow” chạy các quy trình end-to-end và tác vụ hằng ngày trong Workday. Kết quả bạn cần đạt: hiểu quy trình được kích hoạt, được route và hoàn tất như thế nào—để bạn có thể xử lý sự cố và thiết kế luồng an toàn hơn.
- Giải thích phê duyệt như routing theo luật (rules-based) được kích hoạt bởi sự kiện.
- Xác định vai trò (role) “sở hữu” từng bước (không chỉ cá nhân).
- Dự đoán điều gì xảy ra sau khi bấm Submit/Approve.
- Giảm quy trình bị “kẹt” bằng cách thiết kế đường routing rõ ràng.
2) Dành cho ai + Khi nào nên dùng
Dành cho HRIS admin, chủ sở hữu quy trình, và power users quản lý phê duyệt/workflow. Dùng khi phê duyệt gây khó hiểu, quy trình bị kẹt, hoặc bạn đang rollout giao dịch (transaction) mới.
- Admin: cấu hình bước, điều kiện và routing theo vai trò.
- Quản lý: hiểu vì sao phê duyệt route đến bạn và bạn đang duyệt cái gì.
- HR: đảm bảo các bước tuân thủ (compliance) có mặt và audit được.
- Dùng sau khi đổi chính sách (lương, nghỉ phép, tuyển dụng) làm workflow phải cập nhật.
3) Vị trí trên điều hướng + Tab liên quan
BPF thường được truy cập qua các tác vụ admin và được “trải nghiệm” qua các tác vụ trong Inbox. Tab liên quan: Security Core HCM Recruiting Absence.
- Người dùng: các item trong Inbox chính là các bước đang hoạt động của business process.
- Admin: các tác vụ cấu hình (tên tuỳ tenant) định nghĩa luật routing.
- Màn hình trạng thái/lịch sử giúp truy vết bước nào đang chờ.
- Việc gán vai trò và phạm vi org ảnh hưởng ai sẽ nhận bước.
4) Mô hình tư duy / Luồng
Hãy coi BPF là một bộ máy “nếu thế này thì làm thế kia” được kích hoạt bởi các sự kiện trong tổ chức, nơi bạn chọn luật và logic.
- Sự kiện kích hoạt một business process (vd: bắt đầu hire).
- Quy trình chạy các bước (review, approvals, docs, notifications).
- Các bước được route đến vai trò dựa trên điều kiện và phạm vi tổ chức.
- Hoàn tất sẽ cập nhật record và ghi lại audit trail.
5) Đối tượng & Thuật ngữ
- Business Process: định nghĩa workflow cho một sự kiện.
- Step: bước con trong quy trình (duyệt/review/hành động).
- Condition Rule: logic để thêm/bỏ bước dựa trên dữ liệu.
- Routing: cách công việc đi đến vai trò/người dùng.
- Notifications: thông báo/tin nhắn được kích hoạt theo bước.
- Audit Trail: lịch sử ai làm gì, khi nào.
6) Máy trạng thái / Vòng đời
Một quy trình thường đi qua các trạng thái khi các bước hoàn tất.
- Initiated: được tạo bởi sự kiện/nộp task.
- In progress: một hoặc nhiều bước đang chờ trong Inbox.
- On hold: bị chặn do thiếu dữ liệu hoặc phụ thuộc bên ngoài (tuỳ tenant).
- Completed: mọi bước bắt buộc xong; cập nhật record được áp dụng.
- Cancelled/Denied: dừng; kết quả phụ thuộc cấu hình.
7) Các việc cốt lõi cần làm
- Truy vết vì sao một quy trình route đến một approver cụ thể.
- Xác định quy trình đang kẹt ở đâu và ai sở hữu bước tiếp theo.
- Thiết kế điều kiện để route theo org/số tiền/loại giao dịch.
- Đảm bảo tách nhiệm vụ (separation of duties) cho hành động nhạy cảm.
- Cải thiện trải nghiệm người dùng bằng cách giảm bước không cần thiết.
8) Luồng chuẩn #1: Truy vết quy trình bị kẹt (power user)
Dùng khi một yêu cầu “pending mãi không xong”. Mục tiêu: xác định người/vai trò đang giữ bước và input còn thiếu.
- Mở record của yêu cầu đã nộp (hoặc dùng Search để tìm).
- Tìm màn hình trạng thái/lịch sử quy trình (nếu tenant bật).
- Xác định bước đang chờ và vai trò/người được gán.
- Kiểm tra thiếu file đính kèm/field hoặc lỗi validation.
- Nhắn cho owner với ngữ cảnh rõ: cái gì, vì sao, hạn xử lý.
- Nếu routing có vẻ sai, escalte cho admin kèm bằng chứng.
9) Luồng chuẩn #2: Giảm “ồn” phê duyệt (admin)
Dùng khi người dùng than “quá nhiều approval”. Mục tiêu: giữ kiểm soát nhưng giảm ma sát không cần thiết.
- Chọn một business process (vd: nghỉ phép, hire, đổi lương).
- Liệt kê các kiểm soát/compliance bắt buộc phải giữ.
- Rà soát điều kiện của các bước: bước nào đang kích hoạt quá thường xuyên?
- Chỉnh điều kiện routing để chỉ nhắm đúng case liên quan.
- Test trên sandbox với kịch bản thực tế (so sánh A/B).
- Rollout và theo dõi thời gian hoàn tất + tỉ lệ lỗi.
10) Điểm quyết định
| Tình huống | Nếu A… | Nếu B… |
|---|---|---|
| Routing nên theo vai trò | Dùng roles gắn với phạm vi org để tránh nghẽn ở một người. | Nếu bắt buộc theo cá nhân, định nghĩa backup/delegation (tuỳ tenant). |
| Phê duyệt theo điều kiện | Nếu theo ngưỡng (số tiền/rủi ro), thêm điều kiện rõ ràng. | Nếu không theo ngưỡng, giữ routing tối thiểu ổn định để nhất quán. |
| Cần bước tuân thủ | Giữ bước bắt buộc; thêm hướng dẫn để giảm lỗi. | Nếu không bắt buộc, bỏ hoặc chuyển thành điều kiện để giảm ồn. |
| Đổi quy trình ảnh hưởng nhiều team | Thông báo release notes và training cho các bước thay đổi. | Nếu thay đổi nhỏ, vẫn pilot và theo dõi metric sau khi phát hành. |
11) Lỗi thường gặp (và cách tránh)
- Lỗi: Hard-code cá nhân trong routing. Tránh: route theo role kèm phạm vi org.
- Lỗi: Duyệt quá nhiều thứ. Tránh: thêm điều kiện để bước chỉ chạy khi cần.
- Lỗi: Không pilot test. Tránh: test sandbox với cả edge cases.
- Lỗi: Bỏ kiểm soát để nhanh hơn. Tránh: giữ compliance; tối ưu điều kiện thay vì xoá bước.
- Lỗi: Hướng dẫn người dùng kém. Tránh: thêm instruction/checklist ở các bước hay sai.
12) Quyền hạn & Vai trò
Các bước BPF route dựa trên vai trò và bảo mật; cấu hình đúng phụ thuộc vào việc gán vai trò và chính sách truy cập.
13) Dữ liệu & Tích hợp
Tích hợp thường kích hoạt hoặc phụ thuộc business process; cần đồng bộ hành động service/API với phê duyệt workflow để tránh bypass kiểm soát.
14) Thế nào là “làm tốt”
- Người dùng hiểu vì sao có phê duyệt và họ đang duyệt gì.
- Quy trình hiếm khi bị kẹt; owner rõ ràng.
- Routing theo vai trò có backup, không phụ thuộc cá nhân.
- Audit trail đầy đủ và hỗ trợ tuân thủ.
15) Checklist: Trước khi làm + Sau khi làm
Pre-check
- Xác định trigger event và kết quả cần đạt.
- Xác định các bước compliance bắt buộc.
- Cấu hình role routing và phạm vi org.
- Thêm hướng dẫn rõ ràng ở từng bước.
- Chuẩn bị kịch bản test sandbox (happy + edge cases).
Post-check
- Metric tốt hơn (cycle time, ít lỗi hơn).
- Phê duyệt route đúng owner.
- Không phát sinh lỗ hổng bảo mật mới.
- Training/notes người dùng đã được cập nhật.
- Audit trail đúng ở các case đã hoàn tất.
16) Bài lab (5–15 phút)
Mục tiêu: luyện mô tả một thay đổi workflow thật rõ ràng.
- Chọn 1 quy trình bạn hay gặp trong Inbox (nghỉ phép, hire, change request).
- Viết các bước của nó thành 6–8 gạch đầu dòng (ai làm gì, theo thứ tự).
- Xác định 2 điểm đau (delay, khó hiểu, làm lại).
- Đề xuất 1 cải tiến theo điều kiện và 1 cải tiến theo hướng dẫn.
17) Link tài liệu chính thức
- Datasheet Business Process Framework của Workday (tổng quan chính thức).
- PDF “HCM can do what” có nhắc tới business processes linh hoạt và trực quan hoá workflow.
Báo cáo & Phân tích lực lượng lao động (Tổng quan)
- Hiểu vì sao reporting là trung tâm: quyết định xuyên suốt hành trình nhân sự (plan-to-hire → retire) phụ thuộc dữ liệu tin cậy.
- Phân biệt “danh sách/báo cáo” và “giao dịch” (đừng chỉnh dữ liệu qua file export).
- Luyện dùng bộ lọc, kiểm chứng (validation) và quy tắc chia sẻ an toàn.
- Biết khi nào cần HRIS/analytics hỗ trợ vs tự phục vụ (self-service).
1) Mục đích / Kết quả
Báo cáo và phân tích giúp bạn ra quyết định nhanh và tốt hơn về kế hoạch nhân sự và kết quả HR. Kết quả bạn cần đạt là tạo báo cáo chính xác, tuân thủ chính sách và sử dụng một cách có trách nhiệm.
- Tìm đúng báo cáo (không nhầm với báo cáo “na ná”) và áp đúng bộ lọc.
- Kiểm chứng kết quả bằng tổng số (totals) hoặc mẫu kiểm tra (samples) đã biết.
- Chỉ chia sẻ những gì người nhận được phép xem.
- Dùng báo cáo để kích hoạt hành động (tác vụ follow-up, phê duyệt, kế hoạch).
2) Dành cho ai + Khi nào nên dùng
Quản lý dùng reporting để xem chỉ số team; HR dùng cho tuân thủ và lập kế hoạch; lãnh đạo dùng cho quyết định workforce. Dùng khi lập kế hoạch, theo dõi hoàn thành chu kỳ, hoặc kiểm tra sau thay đổi.
- Manager: headcount, xu hướng nghỉ phép, theo dõi thay đổi team.
- HR: funnel tuyển dụng, tuân thủ chính sách, audit chất lượng dữ liệu.
- Lãnh đạo: chỉ báo và xu hướng kế hoạch lực lượng lao động.
- Dùng sau các thay đổi lớn (tái cơ cấu, đẩy tuyển dụng, cập nhật chính sách).
3) Vị trí trên điều hướng + Tab liên quan
Điểm vào thường gặp: worklet/app Reports, Search theo tên báo cáo, dashboards (tuỳ tenant). Liên quan: Core HCM Absence Business Processes Security.
- Dùng Search với từ khoá như “Headcount”, “Time Off”, “Hiring”.
- Lưu bộ lọc (nếu được phép) để báo cáo lặp lại.
- Ưu tiên dashboards cho các buổi review định kỳ (nếu bật).
- Xuất file cẩn thận và lưu/chia sẻ an toàn theo chính sách.
4) Mô hình tư duy / Luồng
Báo cáo là lớp “đọc” trên dữ liệu đã được quản trị. Giao dịch (transactions) thay đổi dữ liệu thông qua business processes; báo cáo đo lường/giám sát kết quả.
- Xác định câu hỏi (quyết định nào sẽ dựa vào báo cáo này?).
- Chọn đúng báo cáo và áp bộ lọc phạm vi (scope).
- Kiểm chứng độ chính xác bằng spot-check và tổng số.
- Hành động theo phát hiện (tác vụ follow-up, phê duyệt, hành động kế hoạch).
5) Đối tượng & Thuật ngữ
- Report: đầu ra có cấu trúc dựa trên nguồn dữ liệu (tuỳ tenant).
- Dashboard: tập chỉ số được “curate” (tuỳ tenant).
- Prompt/Filter: tham số để giới hạn đầu ra báo cáo.
- Export: trích xuất ra file; làm tăng rủi ro rò rỉ dữ liệu.
- Security: kiểm soát dữ liệu nào xuất hiện trong báo cáo.
6) Máy trạng thái / Vòng đời
Không áp dụng cho tool/tab này (báo cáo không có vòng đời chung trong nguồn chính thức công khai; phụ thuộc tenant).
7) Các việc cốt lõi cần làm
- Chạy báo cáo headcount hoặc org với đúng phạm vi.
- Theo dõi mức độ hoàn thành của một quy trình/chu kỳ (tuyển dụng, duyệt nghỉ phép).
- Phát hiện bất thường (thiếu dữ liệu, xu hướng lạ).
- Xuất và chia sẻ an toàn (chỉ người nhận được phép).
- Cung cấp bằng chứng cho audit/tuân thủ (khi cần).
8) Luồng chuẩn #1: Chạy báo cáo team có phạm vi (manager)
Dùng khi bạn cần thông tin team chính xác nhanh.
- Search một báo cáo team/org (vd: “My Team”, “Headcount”).
- Xác nhận prompt phạm vi khớp supervisory org của bạn.
- Áp bộ lọc ngày/effective nếu báo cáo hỗ trợ.
- Kiểm tra tổng số và rà nhanh các outlier rõ ràng.
- Spot-check 2–3 dòng so với hồ sơ worker.
- Chỉ export khi cần; lưu trữ an toàn theo chính sách.
9) Luồng chuẩn #2: Theo dõi kết quả workflow (HR/ops)
Dùng khi bạn cần đảm bảo quy trình đang chạy (vd: duyệt nghỉ phép hoặc các bước tuyển dụng).
- Chọn một chỉ số quy trình (pending approvals, aged requests).
- Chạy report/dashboard liên quan (tuỳ tenant).
- Lọc theo “pending” và sort theo tuổi/ưu tiên.
- Xác định owner (role/user) của bước tiếp theo.
- Gửi nhắc nhở có mục tiêu kèm ngữ cảnh và hạn xử lý.
- Chạy lại báo cáo để xác nhận backlog giảm.
10) Điểm quyết định
| Tình huống | Nếu A… | Nếu B… |
|---|---|---|
| Báo cáo ra số liệu “lạ” | Kiểm tra lại prompts/filters; xem effective dates. | Nếu vẫn lệch, escalte cho HRIS/analytics kèm ví dụ cụ thể. |
| Cần chia sẻ dữ liệu | Nếu người nhận được phép, chỉ chia sẻ các trường tối thiểu cần thiết. | Nếu không được phép, cung cấp số liệu tổng hợp (aggregate) thay thế. |
| Có cần export không? | Nếu có, export và lưu trữ an toàn theo quy tắc retention. | Nếu không, giữ trong Workday để giảm rủi ro rò rỉ. |
| Dùng báo cáo để ra quyết định | Nếu quyết định “high-stakes”, cần kiểm chứng lần 2. | Nếu “low-stakes”, tiến hành với giả định được ghi rõ. |
11) Lỗi thường gặp (và cách tránh)
- Lỗi: Chạy báo cáo với prompt mặc định. Tránh: đặt scope có chủ đích.
- Lỗi: Coi file export là “source of truth”. Tránh: Workday là system of record; cần dữ liệu mới thì chạy lại.
- Lỗi: Chia sẻ dữ liệu nhạy cảm quá rộng. Tránh: tuân thủ security và least-privilege.
- Lỗi: Không kiểm chứng các điểm bất thường. Tránh: spot-check với worker records.
- Lỗi: Nhầm giao dịch với báo cáo. Tránh: chỉnh sửa phải qua tasks + business processes.
12) Quyền hạn & Vai trò
Khả năng xem báo cáo bị chi phối bởi security roles và phạm vi. Nếu bạn không thấy báo cáo, có thể là vấn đề quyền chứ không phải thiếu tính năng.
13) Dữ liệu & Tích hợp
Nếu tổ chức dùng API để kéo số liệu, hãy bám service catalog chính thức và quy tắc security.
14) Thế nào là “làm tốt”
- Báo cáo lặp lại được (saved prompts) và đã được kiểm chứng.
- Quyết định tham chiếu phạm vi và effective dates rõ ràng.
- Chia sẻ dữ liệu đúng quyền và giảm lộ lọt tối đa.
- Reporting kéo theo hành động (không chỉ chụp màn hình).
15) Checklist: Trước khi làm + Sau khi làm
Pre-check
- Đã xác định câu hỏi ra quyết định.
- Đã chọn đúng report/dashboard.
- Đã set scope prompts (org/time/status).
- Đã lên kế hoạch spot-check kiểm chứng.
- Đã xác nhận yêu cầu chia sẻ.
Post-check
- Đã kiểm chứng totals và mẫu record.
- Đã ghi lại giả định và bộ lọc đã dùng.
- Đã chia sẻ đúng đối tượng được phép.
- Đã tạo hành động follow-up từ kết quả.
- Đã lưu export an toàn (nếu có).
16) Bài lab (5–15 phút)
Mục tiêu: luyện reporting an toàn kèm kiểm chứng.
- Chọn một báo cáo bạn truy cập được (vd: “My Team”).
- Chạy với 2 scope khác nhau và so sánh kết quả.
- Spot-check 3 dòng so với worker profiles.
- Viết 1 đoạn tóm tắt: phạm vi, phát hiện, hành động.
17) Link tài liệu chính thức
- Tổng quan Workday HCM có nhắc tới workforce planning & analytics như một mảng sản phẩm.
- Cách Workday mô tả hành trình nhân viên end-to-end (plan to hire → retire).
Tích hợp & API (Danh mục REST)
- Học cách dùng REST Directory chính thức để hiểu các dịch vụ có sẵn.
- Ánh xạ nhu cầu nghiệp vụ vào đúng service (vd: dịch vụ Absence Management).
- Hiểu tác động bảo mật: tích hợp cũng phải tuân theo nguyên tắc least privilege.
- Xây quy trình tích hợp an toàn: thiết kế → test → giám sát.
1) Mục đích / Kết quả
Tích hợp giúp Workday kết nối với hệ thống khác (time, payroll, identity, analytics). Kết quả bạn cần đạt là xác định đúng API/service chính thức, triển khai an toàn, và tránh “lách” các kiểm soát của Workday.
- Tìm service trong danh mục chính thức và đọc mục đích của nó.
- Xác nhận những hành động được hỗ trợ (đọc vs gửi yêu cầu vs cập nhật).
- Thiết kế yêu cầu bảo mật và audit ngay từ đầu.
- Test end-to-end với dữ liệu thực tế và các tình huống lỗi.
2) Dành cho ai + Khi nào nên dùng
Dành cho dev tích hợp, HRIS, và chủ sở hữu nền tảng/bảo mật. Dùng khi bạn cần kéo dữ liệu, đẩy yêu cầu (như xin nghỉ), hoặc tích hợp công cụ bên thứ ba.
- Developer: gọi API và xử lý lỗi.
- HRIS: đảm bảo quản trị dữ liệu và đồng bộ với business processes.
- Security: áp least privilege cho user tích hợp.
- Dùng trước khi bắt đầu tích hợp mới để xác nhận service có tồn tại/khả dụng.
3) Vị trí trên điều hướng + Tab liên quan
REST Directory chính thức là danh mục dịch vụ truy cập công khai; nhưng tenant cấu hình sẽ quyết định bạn dùng được gì thực sự. Liên quan: Security Business Processes Absence Reporting.
- Bắt đầu từ directory để tìm đúng service domain.
- Xác nhận service khớp module (vd: Absence Management).
- Xác nhận cách auth/authorization trong tổ chức (tuỳ tenant).
- Đồng bộ hành động API với luồng phê duyệt business process (không bypass policy).
4) Mô hình tư duy / Luồng
Một tích hợp an toàn là một “sản phẩm”: xác định kết quả, map vào services, ép bảo mật, test, và giám sát. Service có thể cho phép đọc dữ liệu và trong một số trường hợp cho phép gửi request tương tự thao tác UI.
- Xác định use-case nghiệp vụ và các đối tượng cần thiết.
- Tìm đúng Workday service trong REST Directory.
- Thiết kế auth/bảo mật cho integration user (least privilege).
- Triển khai + test trên sandbox, rồi giám sát ở production.
5) Đối tượng & Thuật ngữ
- Service: một mảng chức năng API (vd: Absence Management).
- Endpoint: URL/phương thức cụ thể cho một thao tác.
- Integration User: tài khoản không phải người dùng thật để truy cập API.
- Scope/Permissions: dữ liệu và hành động được phép.
- Monitoring: log, retry, cảnh báo, và audit.
- Directory: danh mục chính thức các REST services.
6) Máy trạng thái / Vòng đời
Tích hợp nên có vòng đời như mọi thành phần hệ thống.
- Thiết kế → Triển khai → Kiểm thử → Phát hành → Giám sát → Cải tiến.
- Cần lên kế hoạch versioning và tương thích ngược.
- Lỗi cần xử lý bằng retry và cơ chế dead-letter.
- Vòng đời/versioning API cụ thể phụ thuộc tenant và lịch phát hành của Workday.
7) Các việc cốt lõi cần làm
- Tìm đúng service cho nhu cầu domain (absence, worker, ...).
- Xác nhận thao tác hỗ trợ (đọc vs gửi request).
- Thiết kế truy cập an toàn cho integration user.
- Xây xử lý lỗi và giám sát vững.
- Đáp ứng yêu cầu tuân thủ/audit.
8) Luồng chuẩn #1: Tìm service và xác nhận phù hợp
Dùng khi bạn bắt đầu tích hợp và cần xác nhận Workday có hỗ trợ không.
- Mở REST Directory và tìm theo domain (vd: “Absence”).
- Đọc mô tả service để xác nhận hành động hỗ trợ.
- Liệt kê object/field cần dùng và map vào khái niệm của service.
- Xác định rủi ro bảo mật (dữ liệu nhạy cảm, phê duyệt).
- Xác nhận với HRIS/admin rằng service được bật/có thể dùng trong tenant.
- Viết API contract: input, output, lỗi, kỳ vọng audit.
9) Luồng chuẩn #2: Tích hợp “xin nghỉ” (ví dụ)
Chỉ là ví dụ: bám theo cách làm được duyệt trong tenant của bạn. Mục tiêu: gửi request qua service chính thức mà không bypass policy.
- Xác nhận tenant cho phép tạo yêu cầu nghỉ phép qua API.
- Tạo/gán integration user với least privilege.
- Dùng service Absence Management để gửi thao tác tạo request.
- Đảm bảo workflow phê duyệt chạy như trên UI (nếu áp dụng).
- Ghi log request ID/status và trả về cho hệ thống gọi.
- Xử lý lỗi bằng retry và cơ chế idempotency.
- Giám sát kết quả và đối soát trạng thái định kỳ.
10) Điểm quyết định
| Tình huống | Nếu A… | Nếu B… |
|---|---|---|
| Cần ghi dữ liệu hay chỉ đọc? | Nếu có hỗ trợ ghi, đảm bảo phê duyệt/chính sách vẫn áp dụng. | Nếu không hỗ trợ, thiết kế lại theo read-only hoặc dùng UI/cơ chế khác. |
| Mức rủi ro bảo mật | Nếu nhạy cảm, thu hẹp scope và thêm monitoring/cảnh báo. | Nếu ít rủi ro, vẫn áp least privilege và logging. |
| Real-time hay batch | Nếu cần real-time, thiết kế theo rate limit và tính chịu lỗi. | Nếu batch được, lên lịch job và đối soát định kỳ. |
| Nhu cầu audit/tuân thủ | Nếu nghiêm ngặt, lưu log bất biến và correlation IDs. | Nếu tiêu chuẩn, giữ log có cấu trúc và chính sách lưu trữ. |
11) Lỗi thường gặp (và cách tránh)
- Lỗi: Coi integration user như admin. Tránh: least privilege và role có phạm vi rõ ràng.
- Lỗi: Bypass phê duyệt. Tránh: đồng bộ hành động API với business processes và policy.
- Lỗi: Không có idempotency. Tránh: thiết kế tránh tạo trùng khi retry.
- Lỗi: Monitoring yếu. Tránh: cảnh báo, dashboard, và cơ chế đối soát.
- Lỗi: Không kéo HRIS/security vào sớm. Tránh: đồng thiết kế security và data governance.
12) Quyền hạn & Vai trò
Truy cập API nên được quản trị bằng security roles/groups như mọi user. Integration user chỉ nên có domain và process permissions cần thiết.
13) Dữ liệu & Tích hợp
REST Directory liệt kê rõ các services, bao gồm năng lực của Absence Management như truy cập chi tiết nghỉ phép và gửi yêu cầu nghỉ/leave.
- Dùng mô tả trong directory để map tính năng vào services.
- Xác nhận tenant enablement và cách xác thực.
- Tài liệu hoá phân loại dữ liệu và đối tượng được phép dùng.
- Thiết lập retention và audit logging cho các API calls.
14) Thế nào là “làm tốt”
- Tích hợp bền bỉ (retry, idempotency, monitoring).
- Bảo mật tối thiểu và có phạm vi; không lộ dữ liệu ngoài ý muốn.
- Tôn trọng phê duyệt/chính sách; audit trail rõ ràng.
- Có chủ sở hữu và runbook xử lý sự cố.
15) Checklist: Trước khi làm + Sau khi làm
Pre-check
- Đã xác nhận có service chính thức cho use-case.
- Đã xác nhận tenant enablement và các ràng buộc.
- Đã định nghĩa security scope cho integration user.
- Đã thiết kế idempotency và chiến lược retry.
- Đã định nghĩa logging, monitoring, và nhu cầu audit.
Post-check
- Test pass (happy + edge cases).
- Phê duyệt/chính sách chạy đúng kỳ vọng.
- Monitoring/cảnh báo đã bật và có ý nghĩa.
- Runbook và ownership đã được tài liệu hoá.
- Đối soát định kỳ xác nhận dữ liệu nhất quán.
16) Bài lab (5–15 phút)
Mục tiêu: luyện map yêu cầu vào service contract.
- Chọn 1 nhu cầu: “xin nghỉ” hoặc “kéo số dư nghỉ phép”.
- Tìm service liên quan trong REST Directory và chép các mô tả năng lực chính vào ghi chú.
- Soạn API contract: input, output, lỗi, trường audit.
- Liệt kê quyền tối thiểu bạn nghĩ là cần.
17) Link tài liệu chính thức
- Workday REST Directory (danh mục chính thức các REST services).
- Năng lực Workday Absence Management (tổng quan sản phẩm).
Di động & Tự phục vụ của nhân viên (Tổng quan)
- Tìm hiểu self-service thường bao gồm gì: tác vụ Inbox, hồ sơ, xin nghỉ (tuỳ tenant).
- Tạo “danh sách an toàn trên mobile” các hành động bạn làm tự tin.
- Biết khi nào cần chuyển sang desktop (giao dịch phức tạp, cần kiểm tra kỹ).
- Áp dụng vệ sinh bảo mật: truy cập thiết bị và dữ liệu nhạy cảm.
1) Mục đích / Kết quả
Mobile và self-service giúp các tác vụ phổ biến trở nên nhanh và dễ tiếp cận. Kết quả bạn cần đạt là xử lý các việc thường ngày (phê duyệt, xin nghỉ, cập nhật hồ sơ) mà không sai sót hoặc tạo rủi ro bảo mật.
- Dùng Inbox để xử lý phê duyệt nhanh.
- Gửi các yêu cầu đơn giản (xin nghỉ) đúng cách.
- Xem trạng thái và thông báo mà không phải mò menu.
- Giữ an toàn dữ liệu nhạy cảm trên thiết bị cá nhân.
2) Dành cho ai + Khi nào nên dùng
Dành cho nhân viên và quản lý cần xử lý nhanh khi không ngồi desktop. Dùng cho tác vụ thường ngày, không dùng cho cấu hình phức tạp hoặc thay đổi rủi ro cao.
- Nhân viên: xin nghỉ, cập nhật liên hệ (nếu được phép).
- Quản lý: duyệt nghỉ/duyệt bước tuyển dụng (nếu được phép).
- Dùng khi đi công tác/di chuyển hoặc cần duyệt nhanh.
- Chuyển sang desktop khi cần xem kỹ, xử lý file đính kèm, hoặc kiểm tra dữ liệu lớn.
3) Vị trí trên điều hướng + Tab liên quan
Mobile thường phản chiếu các worklets chính và Inbox. Liên quan: Overview Absence Security.
- Bắt đầu: Inbox cho tác vụ/phê duyệt.
- Dùng Search (nếu có) để tìm tác vụ.
- Dùng khu vực Time Off/Absence để xin nghỉ và xem số dư.
- Dùng trang hồ sơ/self-service để cập nhật các mục được phép.
4) Mô hình tư duy / Luồng
Mobile phù hợp cho workflow ngắn: mở tác vụ → kiểm tra trường quan trọng → phê duyệt/gửi → xác nhận trạng thái. Các kiểm tra phức tạp nên làm trên desktop.
- Mở item trong Inbox hoặc bắt đầu một yêu cầu đơn giản.
- Kiểm tra các điểm cốt lõi (ngày, người, loại, số tiền nếu có).
- Thực hiện (Approve/Submit) và thêm comment ngắn nếu cần.
- Xác nhận trạng thái và các tác vụ follow-up.
5) Đối tượng & Thuật ngữ
- Inbox: hàng đợi tác vụ/phê duyệt.
- Notifications: nhắc nhở hành động hoặc cần xem.
- Self-service: các thay đổi nhân viên được phép tự làm.
- Bảo mật mobile: khoá máy, lưu trữ an toàn, timeout phiên (theo chính sách công ty).
- Yêu cầu nghỉ phép: workflow phổ biến trên mobile.
6) Máy trạng thái / Vòng đời
Không áp dụng cho tool/tab này (UX mobile thay đổi theo tenant và thiết bị; nguồn chính thức công khai trong lần chạy này không định nghĩa một vòng đời mobile chuẩn chung).
7) Các việc cốt lõi cần làm
- Duyệt/từ chối một item trong Inbox nhanh.
- Xin nghỉ và kiểm tra số dư.
- Xem thông tin hồ sơ cá nhân và trạng thái yêu cầu.
- Nhận thông báo và xử lý trước hạn.
- Chuyển vấn đề phức tạp sang desktop/support.
8) Luồng chuẩn #1: Duyệt trên mobile (quản lý)
Dùng khi bạn cần duyệt nghỉ phép hoặc các phê duyệt routine tương tự.
- Mở Inbox trên mobile.
- Chọn item phê duyệt và mở chi tiết.
- Kiểm tra trường chính (ngày/loại/người/ghi chú).
- Kiểm tra trùng lịch/coverage nếu thấy (không thấy thì chuyển desktop).
- Approve hoặc Deny và thêm comment ngắn nếu cần.
- Xác nhận trạng thái hoàn tất.
9) Luồng chuẩn #2: Xin nghỉ (nhân viên)
Dùng khi bạn cần tạo yêu cầu nghỉ nhanh.
- Mở khu vực Time Off/Absence.
- Chọn loại nghỉ và ngày.
- Xem tác động lên số dư (nếu có hiển thị).
- Thêm ghi chú để quản lý có ngữ cảnh.
- Submit và xác nhận trạng thái.
- Xem lại lịch sử/trạng thái yêu cầu sau.
10) Điểm quyết định
| Tình huống | Nếu A… | Nếu B… |
|---|---|---|
| Cần xem file đính kèm | Nếu đọc được rõ trên mobile, xem rồi mới xử lý. | Nếu không, chuyển sang desktop trước khi duyệt. |
| Phê duyệt comp/tuyển dụng phức tạp | Nếu bạn kiểm tra được số liệu và ngữ cảnh chính, làm cẩn trọng. | Nếu không, hoãn và xem trên desktop với đầy đủ thông tin. |
| Thiết bị công cộng / Wi-Fi chia sẻ | Nếu bắt buộc, tránh hành động nhạy cảm và đăng xuất ngay. | Nếu có thể, chờ mạng an toàn hoặc dùng desktop an toàn. |
| Thiếu hành động trên mobile | Nếu desktop có, dùng desktop (mobile có thể giới hạn UI). | Nếu thiếu ở mọi nơi, xử lý như vấn đề security/role. |
11) Lỗi thường gặp (và cách tránh)
- Lỗi: Duyệt việc phức tạp trên màn hình nhỏ. Tránh: chuyển desktop cho phê duyệt rủi ro cao.
- Lỗi: Dùng mobile mà không khoá thiết bị. Tránh: bật khoá mạnh và theo chính sách công ty.
- Lỗi: Bỏ qua xác nhận trạng thái. Tránh: luôn kiểm tra đã submit/approve thành công.
- Lỗi: Duyệt nhầm người/yêu cầu. Tránh: kiểm tra lại tên/đối tượng trước khi duyệt.
- Lỗi: Lưu export/screenshot. Tránh: tránh chụp/lưu dữ liệu nhạy cảm trên thiết bị.
12) Quyền hạn & Vai trò
Trên mobile, dữ liệu hiển thị vẫn phụ thuộc cùng security roles và scope như desktop.
13) Dữ liệu & Tích hợp
Không áp dụng cho tool/tab này (chi tiết tích hợp mobile tuỳ tenant; không được nêu rõ trong nguồn chính thức công khai của lần chạy này).
14) Thế nào là “làm tốt”
- Tác vụ thường ngày được xử lý nhanh và đúng trên mobile.
- Hành động rủi ro cao được chuyển sang desktop để xem kỹ.
- Người dùng giữ vệ sinh bảo mật (khoá máy, đăng xuất, giảm lộ dữ liệu).
- Luôn xác nhận trạng thái và bước tiếp theo.
15) Checklist: Trước khi làm + Sau khi làm
Pre-check
- Thiết bị đã khoá và an toàn.
- Mạng đủ an toàn cho hành động này.
- Hành động là routine (rủi ro thấp) và đọc rõ trên mobile.
- Tôi kiểm tra được các trường quan trọng.
- Tôi biết bước tiếp theo cần xảy ra là gì.
Post-check
- Trạng thái hiển thị đã approved/submitted.
- Không lưu screenshot/file nhạy cảm.
- Đã ghi nhớ các tác vụ follow-up (Inbox).
- Đã đăng xuất nếu dùng thiết bị/mạng chia sẻ.
- Tôi có thể làm lại thao tác này sau nếu cần.
16) Bài lab (5–15 phút)
Mục tiêu: xây thói quen mobile an toàn.
- Mở Inbox và chọn 1 tác vụ rủi ro thấp có thể xử lý trên mobile.
- Tìm Time Off/Absence và xác định chỗ xem số dư/trạng thái.
- Viết “mobile safe list” (3 hành động) và “desktop only list” (3 hành động).
- Xác nhận bạn tìm được link help/support trong app (nếu có).
17) Link tài liệu chính thức
- Workday Absence Management nhấn mạnh mobile self-service là một năng lực quan trọng.