Governance Is Not the Slow Part of a Skills Strategy. It Is the Part That Makes Scale Possible

Cracking the Skills Code, Part 4

In Part 1, I argued that a skills strategy is not fundamentally a technology project. 

In Part 2, I argued that most skills strategies fail from a lack of coherence or internal alignment. 

In Part 3, we got practical: role architecture, skills-to-role mapping, and skill identification. 

As a follow-up to Part 3, we know many clients are unclear about the role Open Skills Ecosystem Partners play in a skills-based strategy within SuccessFactors. These partners can accelerate the development of foundational data elements in one of the following four main ways:

1. They add value by providing market- and industry-relevant skill ontologies,

2. Accelerating research-based role-to-skill mapping for Job Profile Builder,

3. Supporting the design of an organization-level job architecture framework and finally,

4. Generating meaningful insights into inferred and, in some cases, validated skills for the employee Growth Portfolio. 

No single partner is likely to meet every one of the 4 value components in the same fashion, but each brings distinct strengths.

Part 4 is what comes next.

Because once those three elements exist, the question changes.  It’s no longer:

Can we define skills for jobs and people as a one-time effort?

It becomes:

Can we keep skills alive and well as they move across the organization over time?

Where Most Skills Strategies Actually Break

At the beginning, everything looks aligned:

• roles are defined

• skills are mapped

• profiles are launched

But then the system starts to move.

• Learning adds new signals

• Recruiting introduces variations

• AI starts inferring capability

• Employees update profiles

• External sources push new skills

And very quickly:

• duplicate skills appear

• definitions drift

• proficiency levels conflict

• matching becomes inconsistent

At that point, the issue is not architecture.

It’s system behavior.

Governance Is Not Policy. It Is System Design

Most organizations still treat governance as:

• approval workflows

• ownership models

• documentation

But those don’t determine whether a skills strategy scales.  What determines success is:

How the system(s) behave when multiple inputs, applications, and users interact at the same time, over time.

The Shift: From Governance as Rules → Governance as Systems

One of the most useful frameworks we use with clients at Blue Crab comes from our global skills transformation leader, Sally Elstad.  Instead of treating governance only as a layer on top of a skills strategy, Sally reframes a core consideration as:

A system of interconnected components that define how skills behave at scale.

The Skills Systems Architecture @ BCC

At its core, the model defines five systems:

• System(s) of Creation (SoC) → where skills originate

• System of Record (SoR) → where skills are standardized

• System(s) of Engagement (SoE) → where people interact with skills

• System(s) of Validation (SoV) → where skills become trusted

• System(s) of Intelligence (SoI) → where skills drive decisions

This model didn’t come from theory.  It came from repeated client patterns and post launch engagement:  We see increased pressure and breaking points post go live on how skills systemically connect and behave over time.

We now map these interconnected systems in the context of each client. At the start, each category often includes multiple applications—sometimes dozens, both large and small. When aligning them within a SuccessFactors framework, our goal is to identify opportunities for consolidation and create clarity for the role of each of the core SuccessFactors components.

Why This Model Matters in Enterprise Reality

Every large organization already has these systems.  They’re just not aligned.

• Skills are created in multiple places

• Stored in multiple systems

• Validated inconsistently

• Used differently across processes

That’s why you see:

• one definition of “fit” in recruiting

• another in talent management

• another in learning

This is exactly the coherence problem from Part 2—now showing up in execution.

Why SAP Now Matters More Than It Did Two Years Ago

SAP SuccessFactors has crossed an important threshold.  It’s no longer just enabling skills features.  It’s enabling execution of a governed skills system.

And that aligns directly to the model:

• OSE Partner Skill Ontology → System of Creation

• TIH → System of Record (skills governance + standardization)

• Growth Portfolio → System of Engagement + Validation

• AI / Talent/ Analytics modules → System of Intelligence

• JPB → the anchor that connects skills to work

The Biggest Shift in 1H 2026: Governance Becomes Executable

The most important change in the latest SAP release is not new features.  It is control.  SAP now explicitly enables clients to manage how multiple data sources interact in skill profiles.

For example: Clients can decide whether proficiency levels from different data sources can overwrite or reduce proficiency levels in employees’ Growth Portfolio.

This is a fundamental shift.  Because skills are no longer updated in one place.  They are updated by:

• learning activity

• manager input

• certifications

• external systems

• AI inference

And the system must answer:

What happens when those signals disagree?

This Is Where Governance Becomes Real

This is no longer theoretical.  Clients now have to define:

• Which sources are trusted (TIH governance)

• Which signals can:

  • increase proficiency

  • decrease proficiency

  • overwrite existing values

• How frequently skills update

• Which skills are visible and usable

• Where skill expectations are defined (JPB)

These are not configuration details.  They are operating model decisions.

Why Validation Is the Hardest Part

Part 3 made this clear:  Validation is not a binary problem.  It is a reliability problem.

• Manager ratings are inconsistent

• Self-assessments are incomplete

• AI inference is probabilistic

• Learning signals are indirect

So the real challenge becomes:  How do you combine signals in a way that is credible enough to act on?

SAP is now giving you basic tools to manage that.  But it is still up to the organization to define:

• signal hierarchy

• confidence levels

• validation pathways

JPB Is Finally No Longer Just a Flat Job Architecture

With recent enhancements, JPB now supports:

• multi-level job families 

• cascading skill requirements across roles 

That has material impact because now you can:

• define baseline skills once

• cascade them across roles

• adjust proficiency expectations by level

This is not just structure.  It is governance of how skills scale across work.

Without it:

• every role gets defined independently

• duplication increases

• consistency disappears

With it:

• skill expectations scale logically

• career paths become clearer

• matching improves

Although we love the new governance capabilities in the 1H 2026 release, we are looking forward to future releases that help drive increased automation of the TIH governance layer, reliable signal hierarchy choices and overall AI based enhancements to the flow and insight of the core skill and role data. 

What Most Organizations Still Get Wrong

Even with better tools, we know the same patterns often show up:

• treating all signals equally

• over-relying on manager ratings

• ignoring role-level skill expectations

• allowing uncontrolled skill creation

• separating governance across HR functions

Which leads back to the same outcome:  The system exists, but no one trusts it.

The Bottom Line

Part 3 created the bridge between:

• work (roles)

• skills (capability)

• people (profiles)

Part 4 defines what allows that bridge to hold.

The BCC Skills Systems Architecture makes it clear:

A skills strategy is not one system.

It is a system of systems.

SAP now provides the platform to help execute it:

• TIH → governs what skills exist

• JPB → governs how skills apply to work

• Growth Portfolio → governs how skills evolve in people

But the platform does not define the model.  The organization does.  And the organizations that succeed will not be the ones that launch fastest or define the most skills.

They will be the ones that define:

• where skills are created

• where truth lives

• how validation works

• how signals interact

Because that is what allows a skills strategy to do the one thing most organizations are still trying to achieve:

Scale without breaking.