When an L&D director asks "what skills does our workforce actually have right now?", the honest answer is usually: "we have data, but it's not in a shape we can use." The HRIS has job titles, hire dates, department codes, performance review scores. The LMS has completion records. LinkedIn profiles float somewhere between those two. None of it adds up to a skill graph without deliberate transformation work.
This post walks through what that transformation pipeline looks like — concretely, not abstractly. Not because every L&D team should build it themselves from scratch, but because understanding the architecture helps you ask the right questions when evaluating tools or scoping an integration project.
What the HRIS Export Actually Contains (And What It Doesn't)
A typical HRIS export — whether from Workday, SAP SuccessFactors, or a mid-market system like BambooHR — contains structured employee data: employee ID, legal name, job title, department, manager, hire date, location, compensation band, performance rating history. Some systems also export job grade or career level.
What HRIS exports almost never contain: validated skill data. Job titles are proxies for skills, not inventories of them. "Senior Software Engineer" could map to a Python specialist with no cloud experience or a DevOps generalist with deep Kubernetes knowledge. The title doesn't distinguish. Performance ratings tell you something about outputs but almost nothing about which specific capabilities produced those outputs.
The gap between "job title" and "skill profile" is the central data problem for workforce analytics. Closing it requires pulling from at least two or three additional data sources and then doing normalization work before anything useful emerges.
The Four Data Sources Worth Integrating
In order of signal quality for skill inference:
1. LMS completion records. Course completions are weak skill signals — finishing a course doesn't mean capability acquisition — but they're structured, timestamped, and already in a digital system. When normalized against a skill taxonomy (course X maps to skill Y at proficiency level Z), LMS data becomes a reasonable first-pass indicator of where skill development has been attempted. The key word is "attempted." LMS data tells you what employees have been exposed to, not what they can do.
2. Assessment and certification records. Vendor certifications (AWS, GCP, Azure, Salesforce, PMP, etc.) are the highest-quality skill signals most organizations have access to. They're externally validated, they have defined expiration dates, and they map clearly to specific capability domains. If your HRIS or a credentialing system tracks these, they should be the first thing you pull into a skill graph. The limitation is coverage — certifications exist primarily in technical and compliance-heavy roles. Most of the workforce won't have them.
3. Project assignment history. If your project management tooling (Jira, Asana, ServiceNow) tracks who worked on what, project history is a useful implicit skill signal. An engineer assigned repeatedly to microservices architecture projects has probably developed those skills, even without a certificate. This data requires more inference and is harder to normalize, but it's real behavioral evidence rather than declared self-assessment.
4. Manager attestations and self-assessments. Periodic skill attestation — either manager-rated or self-reported — can fill coverage gaps where no automated signal exists. The catch is that self-assessments are systematically biased: people in expanding roles tend to underrate emerging skills; people in stable roles tend to overrate established ones. Manager attestations are more reliable but require structured prompting (rate proficiency on a 1–4 scale against defined behavioral anchors, not "how good is this person at Python").
The Normalization Problem: Getting to a Common Skill Taxonomy
Here's where most DIY skill graph projects stall. You have data from four sources, each describing skills differently:
- LMS vendor tags a course as "cloud computing"
- AWS certification maps to "Amazon Web Services — Solutions Architect"
- A manager attestation says the employee is "strong in infrastructure"
- A LinkedIn profile lists "Kubernetes, Terraform, AWS"
Are these the same skill? Overlapping? Hierarchically related? Without a taxonomy that defines the skill universe and its internal relationships, you can't aggregate across sources or compute gaps against role requirements.
Building a skill taxonomy from scratch is expensive and goes stale quickly as job markets evolve. The more practical approach is to adopt or license an existing taxonomy — EMSI/Lightcast, O*NET, or a vendor-provided one — and then map your internal source data to it. The mapping isn't perfect; it requires ongoing curation as new skills emerge. But it gets you to a common vocabulary faster than building from first principles.
One practical consideration: taxonomy granularity. "Data analysis" is too broad to be actionable. "SQL query optimization for datasets over 50M rows" is so specific it becomes unmanageable. The sweet spot for most L&D analytics use cases is skill nodes that correspond to distinct training paths — specific enough that a gap implies a defined intervention, general enough that a meaningful number of employees have the gap.
Building the Graph: Nodes, Edges, and Proficiency Weights
Once you have normalized skill data per employee, you're ready to construct the graph. The structure is conceptually simple:
- Nodes: employees, skills, roles, and learning resources
- Edges: "employee X has skill Y at proficiency level Z", "role A requires skill Y at proficiency level W", "learning resource R develops skill Y"
Proficiency levels matter. A gap between an employee at level 2 ("working familiarity") and a role requiring level 4 ("can lead others") is qualitatively different from a gap at level 0 ("no exposure"). The training intervention for each is different: the former might be two to three project assignments plus a practitioner workshop; the latter requires a full learning path from fundamentals.
Skill adjacency edges add the layer that makes the graph useful for path recommendations. If skill A is a prerequisite for skill B, or if employees who have skill A tend to acquire skill B faster than those who don't, that relationship should be encoded. This is where collaborative filtering techniques from recommendation systems become applicable: you can infer adjacency from aggregate patterns in employee skill profiles, not just from domain expert declarations. An employee who knows Terraform almost always also has Python fundamentals — that's an empirical edge in the graph, useful for estimating learning velocity for path assignment.
A Concrete Example: 350-Person Logistics Technology Company
A growing logistics technology company was preparing to migrate a core dispatch system from on-premise infrastructure to a multi-cloud architecture. The VP of Engineering identified 14 specific skills the migration required: GCP Pub/Sub integration, Terraform module authoring, Kubernetes pod scheduling, data pipeline orchestration with Airflow, and nine others.
Their HRIS had no skill data. Their LMS had 18 months of completion records. Five engineers had cloud certifications on file in their HR records.
We helped them build a basic pipeline: extract LMS completions → map to skill taxonomy → pull certification records → run manager attestation for the 23 engineers on the affected teams → compute current skill state per person → compute gap against the 14 required skills → rank employees by gap size and adjacency score.
The output showed that 8 of the 23 engineers had sufficient existing skill coverage for the migration with targeted supplemental training. 11 had specific, closable gaps (Terraform knowledge at level 1, need level 3 — a defined learning path exists). Four had gaps in areas where no existing employee had adjacency, flagging them as genuine hire-or-contract needs. That last group was the important finding: they had been planning to train everyone, which would have left the truly unclosable gaps unaddressed until the project actually started slipping.
What This Pipeline Does Not Solve
It's worth being direct about limitations. A skill graph built from HRIS, LMS, certifications, and attestations is a model of your workforce, not a measurement of it. The data is noisy, the taxonomy is imperfect, and the proficiency levels are estimates. If you use this graph to make high-stakes individual decisions — promotions, terminations, specific project exclusions — you're over-interpreting it.
The right use is population-level decisions: which roles have the highest gap concentration, which learning paths will close the most gaps most efficiently, which departments need an assessment cohort before a specific deadline. At that level, the model's noise averages out and the signal is real.
The pipeline also requires ongoing maintenance. Skill taxonomies evolve. New data sources become available. Role requirements shift as business strategy changes. A skill graph built once and left static degrades to noise within 12–18 months. The investment isn't a project; it's ongoing infrastructure — which is part of why organizations that have built it once tend to want to externalize the maintenance rather than rebuild it every cycle.
