SAP SuccessFactors skills management: The participation gap your agents can't close alone

SAP has spent the past year expanding Joule – its AI copilot – from a single assistant into a network of purpose-built agents embedded across SuccessFactors. The Performance and Goals Agent went live in November 2025. Four more – Career and Talent Development, HR Service, Payroll, and People Intelligence – followed in the 1H 2026 release. Joule now sits across recruiting, workforce administration, payroll, learning, and talent development, anticipating next steps instead of waiting to be asked.

Every one of those agents runs on the same fuel: what SAP SuccessFactors actually knows about each employee. The problem is that at most organisations, that picture is thin. While job titles, tenure, and org position are typically well maintained because payroll and reporting lines depend on them, skills – the field every one of these agents needs most – are not.

This is not a criticism of Joule. It is a description of where the gap sits, and why SAP cannot close it from inside SuccessFactors alone.

What SAP's agents are actually built on

SAP's skills foundation lives in the Talent Intelligence Hub – the Skills Ontology, Attributes Library, and Growth Portfolio that feed job profiles, the Opportunity Marketplace, learning recommendations, and now the Joule agents themselves. It is a well-designed architecture. The Growth Portfolio updates from job profiles, completed learning, performance reviews, and project history, and Joule can infer some of it without asking an employee to type anything.

But inference has a ceiling. It can tell you what a role implies or what a course covered. It cannot tell you that someone is three years into unofficial Python fluency picked up outside any formal SAP-tracked activity, or that a consultant has let a skill lapse since their last project. The Career and Talent Development Agent is only as good at identifying future leaders as the skills data attached to the candidates it's scanning. The People Intelligence Agent is only as sharp as the Business Data Cloud inputs feeding it. Every agent inherits the completeness of the record underneath it.

Daniel Nilsson, co-founder of MuchSkills, puts it plainly: "Agents trained on 30% data make 30% decisions."

The number most SAP customers aren't tracking

Across enterprise SuccessFactors deployments, employee skills profiles typically sit at 20%-40% completion, with three to five skills declared per employee. This is an industry observation drawn from MuchSkills' own enterprise deployment work, not a third-party study – but it matches what Programme Leads and HRIS teams describe when they talk about their own SuccessFactors instance: partial profiles, stale entries, and skills fields that were populated once during rollout and never touched again.

The reason has little to do with how SAP built the system, and a lot to do with who has a reason to use it. Core HR fields – legal name, payroll bank details, reporting line – run at 90%–95% completion because the system enforces them; an employee won't get paid without them. Skills are a voluntary field, and voluntary fields are rarely completed unless the person filling them in gets something in return. SuccessFactors was built as a system of record. It was never designed to give an individual employee a reason to keep their own skills profile current. 

That is exactly the layer SAP's five new agents now depend on – and exactly the layer SAP does not own.

What the same SAP stack looks like with a participation layer added

Höegh Autoliners runs SAP SuccessFactors across 1,400+ employees, multi-region, HQ in Norway with operations extending to Manila. Their skills data now runs through MuchSkills alongside SuccessFactors – same HCM, same org chart, same underlying system of record. The difference shows up entirely in the participation layer:

What changed with the addition of MuchSkills as a participation layer is that employees had incentive to keep their profiles current – seeing their own skills mapped against roles they might grow into, rather than filling in a field that disappears into an HR system they never look at again.

Agreed, holding a profile completion level above 90% isn't a switch-it-on-and-walk-away outcome – it still takes active manager engagement to keep pace with new joiners and role changes. But that lift is lighter than most enterprise rollouts. This is because the platform is designed for the person filling it in, not just the team reporting on it. MuchSkills has a Red Dot Award-winning user interface, a profile that takes 15-30 minutes to fill and doesn't read like a compliance form, and a unique metric called Skill Will, which lets employees flag what they want to grow into alongside what they already know. So updating profiles is more of a maintenance ask, not an adoption-from-zero ask.

That same participation effect carries through to learning: Höegh's learning data, synced through Skillsoft Percipio and mapped against the resulting skills picture, now feeds directly into the company's annual strategy reporting.

Where MuchSkills sits – and doesn't sit

MuchSkills is not replacing SAP SuccessFactors. It is the skills intelligence layer on top. SuccessFactors administers; MuchSkills generates participation; both feed the agents. Your HCM knows your org chart. MuchSkills knows your capabilities.

MuchSkills is also a listed SAP partner, integrated via API. MuchSkills has its own AI, but how that stacks up against Joule isn't the point here. What MuchSkills brings to a SAP stack is the input: skills data that's granular because of its high completion rates. Joule's agents will only ever be as accurate as that skills data input. Without participation, the inference agents starve. 

What this means if you're the one building the business case

If you're the Head of Workforce Planning trying to explain to your CHRO why Joule's talent recommendations feel generic, or the HRIS lead fielding the question of why the AI workforce planning initiative the board approved isn't producing sharper answers, the honest diagnosis usually isn't the agent. It's the input. SAP built genuinely capable agents. What most SuccessFactors customers haven't built yet is a reason for their own people to keep their skills data current – and that's a separate project from anything on SAP's roadmap.

The fix doesn't require ripping anything out, and it isn't a weekend project either – like any enterprise rollout, it starts with a pilot division, not a big-bang launch. What it adds is the layer that makes what's already there work as intended.

Frequently Asked Questions

What is SAP SuccessFactors skills management? 

SAP SuccessFactors manages skills through its Talent Intelligence Hub – a Skills Ontology, Attributes Library, and Growth Portfolio that store and update employee skills data. This data feeds job profiles, the Opportunity Marketplace, learning recommendations, and SAP's Joule AI agents across the SuccessFactors suite.

Why do SAP's Joule agents need accurate employee skills data? 

Agents like the Career and Talent Development Agent and the People Intelligence Agent make recommendations – succession candidates, development paths, workforce insights – based on the skills data attached to each employee. If that data is sparse or outdated, the agent's output is sparse or outdated too, regardless of how capable the underlying AI is.

Does MuchSkills replace SAP SuccessFactors? 

No. MuchSkills integrates alongside SAP SuccessFactors as a skills intelligence layer, not a replacement for it. SuccessFactors remains the system of record for HR data; MuchSkills is the employee-facing layer that generates the current, detailed skills data SuccessFactors and its agents depend on.

How does MuchSkills integrate with SAP SuccessFactors? 

MuchSkills connects to SAP SuccessFactors via API, syncing employee master data, reporting structure, and profile information automatically. MuchSkills is a listed partner on the SAP Store, and organisations including Höegh Autoliners run MuchSkills alongside their existing SAP SuccessFactors deployment.

The data underneath the stack

SAP has built the agents. What determines whether they're useful is the same question it's always been: does the organisation actually know what its people can do? See what your SAP data looks like with a participation layer added →

‍