Suppose phase one of your AI roadmap is an enterprise-wide task and skills inventory. Every job broken into tasks. Every task scored for automation. A heat map to drive investment and reskilling.
It looks like diligence. Nobody wants to be the executive who funded automation without understanding the work.
But two things have arrived stapled together: understanding the work and cataloging all of it before making a decision.
I'd separate them. Fund detailed mapping where it can change an investment or workforce decision. Keep enough of an enterprise view to spot shared dependencies and overlooked opportunities. Don't require every job to be decomposed before useful AI work can begin.
A map needs a decision
Before approving the mapping budget, ask what choice the map will help you make, and when.
Improving productivity is a goal, not a scope. Choosing which invoice workflow to assess for automation is a decision. So is deciding which employees need training before a planned rollout. Each calls for different information.
Breaking today's jobs into tasks gives you a baseline. It can also lock your attention onto today's division of labor, when the better answer may involve different work. The task map should inform the design, not settle it.
Nor does being able to describe a process establish that AI can perform it reliably or at an acceptable cost. That needs testing.
There are good reasons to buy a broader map. If acquisitions have left you with incompatible job structures and no reliable way to compare work, a broader inventory may be justified. Consolidation is a legitimate purpose, and the findings may also inform your AI roadmap. Name both purposes rather than making automation carry the entire business case.
Skills inventories can help with hiring, learning and succession. Detailed task documentation can support capacity planning and work with required safety or compliance steps. Have the relevant specialists specify the coverage those obligations require. A preference for smaller projects doesn't override them.
Keep a different inventory separate: the register of AI systems already in use. You need visibility into those systems and their permissions even if you deliberately limit how much employee work you map. Knowing what AI is running and cataloging every employee task are different assignments.
Separate breadth from depth
Keep an enterprise view of proposed AI work, shared systems and risk constraints while going deeper on selected workflows. A narrow project still needs to fit the company around it.
For an initial scan, I'd ask teams for short descriptions of candidate workflows, the systems they depend on and the business problem worth investigating. Use existing records where they're useful. Compare enough candidates to avoid simply funding the most enthusiastic team's idea, then put the detailed analysis where the decision requires it.
Keep the findings in a shared place so teams can reuse what others have learned rather than commission the same analysis again.
Consider a hypothetical invoice project. Finance wants to decide whether to test AI extraction of invoice fields into its accounting system. Mapping intake, validation and exception handling is relevant. Listing everything done by everyone with accountant in their title isn't.
But if the business case assumes the same approach will work across acquired divisions, one finance team is an inadequate sample. Include materially different systems and local requirements before extrapolating. A narrow map that hides the variation your decision depends on is not good scoping.
A small map can still be wrong. A task list may leave out the expert everyone consults, the time needed to check an answer or the work that appears only when something goes wrong.
Before accepting it, have people who do the work walk ordinary and difficult cases through the map. Mark what is observed, what is estimated and what remains unresolved. Expand the inquiry when a missing dependency could change the investment or risk decision.
The same title can hide different work across business units. Agree in advance how the team will handle that discovery: record the differences, establish why they exist and bring consequential choices back to the sponsor. Don't pre-commit to standardizing everything. Different customer needs or local rules may justify different work.
Use the workforce map to choose training
Job titles alone don't tell you what AI-related training someone needs. People with the same title can have different responsibilities and different levels of AI fluency.
For reskilling, I'd start with job families facing the earliest material changes to their work. Identify the responsibilities expected to change and what people will need to be able to do afterward. Check those expectations with managers and employees before buying a curriculum.
Then separate the role's requirements from the individual's ability. A role may require someone to review an AI-produced reconciliation. Their confidence with the tool doesn't establish that they can catch an incorrect match. Assess that through relevant work and use the result to target support.
An impact map tells you where to look. It doesn't tell you who is capable.
If you collect individual assessments, explain their purpose, who can see them and how people can correct errors. A development exercise should not quietly become a redundancy ranking.
Price the map you plan to keep
Skills and tasks change as tools and workflows change. An inventory can be useful and still need maintenance.
Require any map intended for continuing use to name who keeps it current, when it gets refreshed and which decision it feeds. Without those three lines, you've bought a photograph of the company taken during the interviews.
Put maintenance in the budget alongside the initial work. Count employees' interview and validation time, not just the vendor's fee. If the map serves a one-time decision, date it and archive it when that decision is finished rather than leaving it around as current guidance.
At the first review, ask what the next layer of detail would change. If another business unit could alter the platform choice, include it. If an unresolved exception could overturn the savings case, investigate it. If the remaining work only makes the inventory look more complete, ask why you need it.
That doesn't mean stopping at the first convenient answer. Required coverage still has to be met, and material uncertainty about cost, people or risk still needs attention. It means distinguishing evidence needed for a decision from detail collected because the project hasn't run out of categories.
My AI Readiness Assessment: A Checklist That Ends in a Plan describes how to assess and rank workloads. The question here comes before that work expands into a census: how much analysis does this decision justify?
This is a proposed scoping practice, not a tested method for increasing AI returns. A well-bounded assessment can still produce a no.
The next time a team asks for another month of mapping, ask which decision the extra detail could change. If the proposal can't name one, send back the scope before you sign the budget.
Deciding where AI pays in your company?