← Latest reporting

A task map needs a measurement layer before it becomes a workforce plan

Workday’s early-access Work Intelligence connects jobs, tasks and skills. Buyers still need to separate inferred activity, worker confirmation and observed time.

Skills Systems and HR TechWork and Role Change
Conceptual AI illustration, hand-painted in gouache, of a worn apron holding different task tools in separate pockets.
Conceptual illustration generated with AI under editorial direction; it does not depict a real event.

What happened

Workday introduced Work Intelligence on 13 October, available to early-access HCM customers, to connect tasks within jobs to required skills and workforce decisions.

Why it matters

A task description, a confirmed task and a measured share of working time are different records. Conflating them can turn a useful planning hypothesis into an unsupported staffing assumption.

The product is a task view, not a time study by default

On 13 October, Workday introduced Work Intelligence, available to early-access Human Capital Management customers. The company says it decomposes jobs into tasks, links those tasks with skills and supports decisions about learning, hiring and role redesign. Its quoted scale of more than 3,450 customers and 75,000 canonical skills belongs to Skills Cloud, not demonstrated adoption or accuracy of the new product.

Workday says people retain the decisions. That is a meaningful statement of intended use, but it does not explain what evidence supports each task or time estimate. A useful procurement conversation should therefore begin below the dashboard: which observations created this record, what was inferred, and what did a worker actually confirm?

Confirmation is a distinct layer

There is relevant counterevidence to a claim that Workday describes no validation process. Its internal Sana account describes a Work Insights Agent that infers tasks from employee-approved connections, then asks employees to validate the list conversationally. It says validated data informs workforce planning. This is an internal, vendor-authored example; it should not be assumed to define every early-access customer configuration.

The distinction matters. Confirming that a task occurs does not necessarily confirm its frequency, importance, time share or exposure to automation. A worker may recognise an accurate task label while disagreeing with the amount of effort assigned to it. Equally, an activity visible in a connected application may omit an important decision made away from that application. These are measurement questions to test, not observed defects established in Workday’s system.

An independent methodological reference makes the separation concrete. The O*NET 31.0 Task Ratings dictionary distinguishes importance, relevance and frequency. It also describes fields for sample size, uncertainty, update date and source. O*NET is a US occupational reference, not a time diary for a particular employer and not a validation of Workday. Its value here is showing why one task label need not carry every measurement.

Ask for the record behind one decision

For a pilot, select one recurring process with a named owner. Ask the supplier to export the proposed tasks and their evidence types. Separate job-description statements, inferred workflow activity, employee-confirmed tasks and directly observed timings. Preserve disagreements rather than replacing them with a single confidence score. The following is an editorial acceptance test, not a procedure validated by either source.

Have a small group of employees and process experts independently describe the work before seeing the inferred map. Compare missing tasks, false matches and granularity: one system’s single task may contain several distinct decisions. Sample a normal period and an exception-heavy period. Report who participated and which teams or activities were absent; do not treat a convenient group as representative of the organisation.

Only then attach time observations, using a separately stated collection method. Keep estimates separate from measurements and account for review, rework, coordination and waiting. Do not multiply an inferred automation share by headcount to declare a saving. A tool’s technical capability, a task’s local frequency and the organisation’s ability to redesign work are separate uncertainties.

Agree how employees can correct a record and how changed evidence reaches the planning team. Limit access and use to the agreed pilot purpose, with the required employment and privacy review. A task profile assembled for learning should not silently become an individual performance judgement.

The skills-visibility evidence question remains useful context. The next buying decision is narrower: can the supplier preserve the distinction between a plausible task map and a measured account of work, and can the employer stop a budget decision when that distinction is unresolved?