A skills framework can give an organisation structure, consistency and a common language. But adopting one does not automatically give you a skills model that reflects how work is actually done.

Its usefulness depends on what the organisation expects that model to help it understand or decide. Before getting to that question, though, it helps to start one step earlier: why look beneath jobs and roles at all?

Skills offer organisations another level of detail. The challenge is making that detail clear and consistent enough to be useful.

The appeal of looking beneath the job title

Job titles are useful. They give organisations a manageable way to group work, assign responsibility and define accountability. But they only tell us so much about what people actually need to be able to do.

Two people can hold the same title while working with different customers, systems or levels of responsibility, and therefore require different skills. At the same time, people in very different roles may rely on some of the same underlying skills. A team leader and a sales consultant may both need to listen carefully, interpret information and make sound judgements, even though they apply those skills in very different work.

Looking at skills gives organisations another level of resolution. It can make visible what sits beneath a role and what may cut across several roles, functions or levels of the organisation.

That does not make jobs obsolete, nor does it mean that a skills-based view is automatically more useful. It does, however, create a different problem.

Once we start looking beneath job titles, we need to decide what we actually mean by a skill. Different parts of an organisation may use different terms for similar things, or the same term for quite different things. Before a skills model can add clarity, the skills themselves need sufficiently clear and consistent meaning.

A list of skills is not yet a model

The difficulty is that a skill is less stable as a unit than it first appears.

Consider some of the language an organisation might already use: communication, active listening, product knowledge, customer service, complaint resolution, judgement and problem solving. These may all appear together in a job profile or skills library, but they are not necessarily the same kind of thing. Product knowledge is knowledge. Judgement may cut across several areas of work. Customer service might describe something much broader than a single skill.

Mature occupational models recognise these distinctions. O*NET, for example, treats skills, knowledge, abilities, tasks, work activities and work context as separate concepts rather than placing everything someone needs for work into one undifferentiated skills list.

Even once we agree that something is a skill, another problem appears: granularity. Communication, customer communication, handling difficult customer conversations and de-escalating an angry customer could all reasonably appear in a skills model. The issue is not that one label is correct and the others are wrong. They describe work at different levels of specificity.

Language creates a similar problem. One part of an organisation might refer to customer needs analysis, another to needs identification, and another to customer discovery. Those labels may describe the same underlying concept, closely related concepts or genuinely different requirements. The label alone does not tell us which.

Simply adding more skills to a library does not necessarily create greater precision. It may simply create more labels.

If skills are going to be used across recruitment, development, mobility or workforce planning, the organisation needs enough shared meaning to know when people are talking about the same thing. The question becomes less about how many skills we can identify and more about what the model needs to help the organisation do.

A skills model has to be designed for something

Once that ambiguity becomes visible, the problem shifts. The organisation is no longer only asking which skills exist. It also needs to decide what it expects the model to help it understand or do.

Different uses place different demands on the structure. A skills model used mainly to organise learning content can often work with broader categories. If the same model is expected to inform recruitment, development, internal mobility or workforce planning, those categories may no longer be sufficient. Definitions may need to be clearer, granularity may need to differ, and relationships between skills may become more important.

This does not mean every function needs its own framework. It means there is no single level of detail or sophistication that is automatically right for every organisation or every use case.

A relatively simple skills structure may be entirely appropriate where the requirement is narrow. A more complex model becomes justified when the organisation expects it to support more consequential or varied workforce decisions.

That matters because it prevents the architecture itself from becoming the objective.

A better question is not, “How sophisticated can we make this model?” but, “What does this model need to make possible?”

Once that purpose is clear, it becomes easier to judge what needs to be defined, how much structure is necessary and where greater precision actually adds value. It also gives the organisation a basis for deciding whether an existing framework already provides enough, or whether further modelling is required.

What established frameworks can, and cannot, give you

None of this means organisations need to invent a skills language from scratch.

Established frameworks already contain a great deal of useful structure. ESCO, for example, classifies occupations, skills and knowledge for the European labour market and education and training environment, while O*NET organises information about US occupations through distinct concepts such as skills, knowledge, abilities, work activities and work context. These frameworks provide more than lists. They offer definitions, classifications and relationships that organisations can draw on rather than recreate independently.

But they were also designed to do particular jobs.

ESCO aims to provide a common language across the European labour market. O*NET describes occupations and work in the United States. In South Africa, the Organising Framework for Occupations provides the occupational structure used in national skills planning. The 2024 National List of Occupations in High Demand, for example, identifies occupations at the six-digit OFO level and uses that structure to support wider skills-planning decisions.

That distinction matters. An international framework is not necessarily less useful because it originated elsewhere, and a South African framework will not automatically describe the needs of a particular South African organisation more accurately. These frameworks are designed for purposes broader than the circumstances of any single organisation.

South African labour-market research makes the importance of context visible at another level. In 2024, the Department of Higher Education and Training published province-specific lists of occupations in high demand for Mpumalanga and the Western Cape. The Department noted that provinces had previously relied on the national list to infer their own demand, even though provincial demand can have its own particular characteristics.

The organisational implication is an inference rather than a conclusion drawn by DHET, but it is a useful one: a framework can remain valid and valuable at the level for which it was designed while still requiring interpretation when applied in a more specific context.

An established framework can provide a strong reference point. The remaining question is how that reference should be interpreted when an organisation wants to use it for decisions about its own people and work.

Standardisation and context are not opposing choices

Standardisation has real value. A common framework can give different parts of the organisation a shared language, make roles and skills easier to compare, support interoperability between systems and preserve a connection to wider occupational or professional structures. SFIA, for example, provides consistent skill definitions, guidance notes and levels of responsibility while placing those skills in the context of professional application.

Context matters for a different reason. The same skill may be applied under different conditions, with different responsibilities, customers, technologies or consequences. South African skills research also cautions against treating skills as isolated attributes, emphasising the wider institutional, socio-economic and relational contexts in which they are developed and used.

Organisational context should not simply override the standard. And contextualisation is not a matter of replacing established terminology with local labels and calling the job done. If an organisation renames “customer needs analysis” as “customer discovery” without examining whether the underlying work is actually the same, it has localised the language, not necessarily improved the model.

This is where the distinction between a reference framework and an organisational skills model becomes useful.

The reference framework provides reusable concepts, definitions and relationships. The organisational skills model is the representation the organisation actually uses: those concepts interpreted, mapped and, where necessary, adapted to the work they are intended to describe.

This matters when the same representation is expected to support decisions across recruitment, development, mobility or workforce planning. Common reference points support consistency and comparability. Organisational interpretation makes those concepts meaningful enough to use in practice. The balance between the two depends on what the organisation is trying to achieve.

At that point, the practical problem becomes more specific: what needs to happen between selecting a useful reference framework and having a skills model the organisation can actually use?

From reference framework to organisational skills model

Once an organisation has selected a useful reference framework, the real work is deciding how that framework should operate inside the organisation.

A practical way to think about that work is:

Purpose → Model → Structure → Map → Test → Refine

This is a LATERAL synthesis rather than an established methodology in its own right. The individual activities are already visible in mature skills and occupational frameworks, but bringing them together in this sequence helps make the organisational modelling task more explicit.

It begins with Purpose. Before deciding how detailed the model should be, the organisation needs to be clear about what it expects the model to support. A structure used mainly to organise learning content may not need the same level of precision as one intended to inform recruitment, development, mobility and workforce planning. Purpose therefore gives the rest of the modelling work something to work towards.

From there, Model is about deciding what concepts are being represented and what they mean. If the organisation is using terms such as skill, knowledge, behaviour, task or capability, it needs enough clarity to avoid treating unlike things as if they were equivalent. This is also where questions of naming, definition and boundaries start to matter.

Structure then deals with how those concepts are organised and related. Some skills may sit within broader categories. Others may support one another, appear across several roles or be relevant in different parts of the organisation. The point is not to create complexity for its own sake, but to make the relationships useful enough for the decisions the model is intended to support.

Map connects that structure to actual work. This is where the organisation tests whether the model reflects the roles, responsibilities and work activities it is supposed to describe. A skill that looks sensible in a reference framework may prove too broad once it is mapped to real work, while two apparently different skills may turn out to represent the same underlying requirement.

That is why Test and Refine matter. Testing asks whether the model is actually useful for the purposes established at the beginning. Refinement responds to what the organisation learns through use: concepts that are too broad, too narrow, duplicated, missing or poorly matched to the way work is done.

The process is therefore iterative rather than strictly linear. Mapping may expose a definition that needs to change. Testing may reveal that the structure is too detailed for one purpose and not detailed enough for another. Refinement may send the organisation back to modelling or structure before it moves forward again.

The aim is not to produce the most elaborate skills architecture possible. It is to create enough structure, meaning and connection to work for the organisation to use skills consistently and meaningfully.

Seen this way, selecting a framework is only one part of the process. The organisational modelling work lies in turning that reference point into something that can actually support the workforce decisions the organisation needs to make.

Framework selection is a starting point, not the modelling decision

Organisations do not need to choose between the consistency of an established framework and the relevance of something built entirely for their own context.

A recognised framework can provide a strong foundation. What matters is whether that foundation is sufficient for the way the organisation intends to use it.

For some organisations, relatively light contextualisation may be enough. For others, especially where the same model is expected to support several workforce decisions, more deliberate definition, mapping and refinement may be justified.

The decision is therefore not simply which framework to adopt. It is how far that framework already represents the work the organisation needs to understand, and what still needs to be added or adapted before it becomes useful in practice.

Framework selection matters. But it is the beginning of the modelling work, not the end of it.

References