Frameworks, I love them – let’s have lots of them. We have TOGAF and DODAF and MODAF and PEAF. We have BIAN and ACORD and APQC… one of the industry specific ones is called SCOR – Supply Chain Operations Framework. It’s actually an excellent and very mature standard within the scope of what it does, and it offers several ideas that an organization could borrow to expand the TOGAF skills framework.
Summary: The Supply Chain Operations Framework is not very well known outside of its specific market, which is a pity, as it’s a rather nicely put together framework, albeit with a limited scope. One of the various things it does well is the skills framework, which we look at in this post.
The key point about SCOR is that it is based around processes. This shouldn’t be surprising given that it’s a standard that focuses on operational excellence in supply chains. Processes are defined for 5 major level 1 process areas – Plan, Source, Make, Deliver and Return. Within each of these areas, SCOR defines a set of subprocesses.
What that means in terms of the SCOR skills framework, is that each process is mapped to a number of skills that support that process. The mapping is many to many; a given skill supports multiple processes, each of which relies on several skills. Each skill is described and should be rated for a given person or role on a scale of 1 to 5:
- Novice – Untrained beginner, no experience, requires and follows detailed documentation to be able to perform the work.
- Experienced beginner – Performs the work; limited situational perception.
- Competent – Understands the work and can determine priorities to reach organizational goals.
- Proficient – Oversees all aspects of the work and can prioritize based on situational aspects.
- Expert – Intuitive understanding. Experts can apply experience patterns to new situations.
However, the SCOR framework does not simply stop there. Each skill is mapped to three elements that affect the skill level.
Aptitudes represent an innate affinity to a particular activity. For example, some people have a natural ability with arithmetic; this affinity can be useful in applying the skill of stock checking.
Experiences represent time spent engaging in an activity, so that the person with that experience is familiar with the expected situation and the unexpected contingencies that can occur.
Last of all comes training – specific knowledge transfer that the person has undergone. This could be formal or informal – the specification does not make any distinction in this regard.
In each case, there can be a many to many relationship. A given skill can be affected by several aptitudes, several experiences and several forms of training. Likewise, each aptitude can affect several skills.
What this means in practice is that for a given business process, you can walk a notional graph to derive a specification for the profile of the person performing the process – what skills, and hence, what aptitudes, experiences and training that they should have. Used within a modeling tool that supports analysis, it is possible to derive this list automatically.
Now, this doesn't solve the objectives that we examined in the first post. First of all, there are arguably some noticeable gaps in the SCOR skills framework; also, it is only concerned with process modeling for supply chains – so its applicability to Enterprise Architecture is... shall we say... limited. But it does at least offer some ideas for how we could expand the work done by the TOGAF authors.
Steve Jobs used to love to quote Picasso - “Good artists copy, great artists steal.” SCOR's approach to skills modeling seems eminently steal-able for our purposes.