One of the big mistakes teams make with capturing supply chains when they’re using reference frameworks is to make sincere attempts to force business process ‘subject experts’ to use their reference language to describe their processes. Imagine going to a doctor, and the doctor handing you a list of ailments, and asking you to describe your problem in medical language – “hey doc, I’ve got mild diffuse neuralgia in the upper left gluteus”.
And, if you fail to do so, the doctor begins coaching you on medical terminology and seeing if you get it right. Well, you get another doctor then. So supply chain teams who take this approach frequently get disappearing subject experts. The approach simultaneously creates a huge overhead on modeling work – you have to teach subjects the framework – terminology, metrics, definitions, coding – and reduces the quality of the information – subjects guess about processes.
A point of a supply chain frameworks is to accelerate change. In a capture workshop, as
I’ve written in the past, frameworks make an excellent guide for the
facilitator to ask participants how they do particular pre-defined processes,
but the information should be left in the language of the subject expert. In
our example, the doctor asks “do you have pain anywhere”, and “can you point
to where it hurts”. She then translates this to medical language, and then
sees what it might correlate to. The process leader may ask “how do you
generate a purchase order for raw material”, and “how do you receive, and
store material”, rather than asking the participants to define their models
using S1.1, S1.2 etc. processes from SCOR. The information is captured (on
paper), and then a special step ensues.
The process leader then translates the information into a standard process
language, or a framework language. So when the subject participant speaks of
how a requisition is generated when safety stock falls below a % level, and
then talks about how pallet id’s are scanned at receiving and so forth, the
modeler takes the “raw” information, and correctly classifies it (using SCOR)
as “S1.1, S1.2…” processes, builds the model, links the activities to standard
inputs and outputs, and looks at the key metrics, and also best practices. The
subject is speaking “natural language”, and it’s translated into ‘standard
language’. The end result is what I call a more or less “Normal Form”, though
it’s not quite the same as relational data model “normal form”. Once in the
normal form, the process can be measured using standard instruments, shared
with others using the same process frameworks, and can be analyzed using
What advantages does this convey? First, information gathering is guided by
the framework, but doesn’t force translation to the framework by the subject
expert so communication is rapid and smooth. Second, the expert “owns” the
definitions which are communicated, from the perspective of defining and
owning future change – they are not describing things which they don’t fully
understand or buy into. Third, gathering is quite rapid because you can
harvest and classify exiting information. We’ve seen over and over that many
groups have some sort of process documentation though not everyone may
understand it. A good process team can ‘pre-normalize’ or pre-digest the data,
and create models in advance of workshops which the subject experts can then
read and contribute to – straw man models. Lastly, in the ideal world,
everyone in a business has had training on process and is comfortable in
describing their processes using the ‘company standard’ framework, but in
practice this takes quite some time investment. You can get the same net
effect by simply having the process team do the translation work outside of
the meeting with the subject experts. This is a very low-cost alternative.
How does process normalization work? Process model/framework experts take user
definitions and match them up with process definitions from a framework. As an
example, as users discuss ways they store materials – for instance high value
materials may be stored in a special cage, ordinary materials are stored in
coded racks, and large materials stored in special floor locations. For the
subject expert, they may have three processes names – high value cage process,
the putaway process, and the oversize process. The modeler recognizes the
‘storage’ activity by match up with process step definitions, and then embeds
the description in three instances of a SCOR sourcing process, and stores this
as model data. There are now three S1 processes, with slightly different
descriptions, and each of which has a different metric, but share the same
measures, practices, and inputs/outputs. The storage process has been
‘normalized’ and can be manipulated using standard tools.
More on three instances of the source-receive process. Our team initially,
when normalizing, made a fatal flaw of grouping all process flows into single
process steps – in this case, having one “putaway” process with three
decision-driven sub-workflows. This never worked well in practice, because it
hid the complexity of the process (looks like there’s only one putaway when
there were three), and didn’t allow for differentiation of the metrics by type
of putaway – time to perform high-value putaway, was quite different from
standard putaway. If there were problems, and you only measured putaway issues
at the grouped level, you may fail on 50% of high-value putaways, which is a
serious issue, but if the volume of high-value putaway is low, you may never
see the effect at the grouped level. More on these best practices of modeling
in future articles.
So you’re a process professional, what does all this mean, what are the
takeaways? In summary:
- Focus on detailed, natural descriptions of supply chain process from your subjects, guided by frameworks but not dictated by framework nomenclature.
- Pre-load process modeling workshops with data already gathered from informal discussions and documentation, normalized to a ‘strawman’ form which further guides the discussion.
- Translate processes to ‘normal form’ by correlating descriptions to standard process steps.
- Allow no more than one major process activity per standard step; expose complexity, as much as practical
- Retain natural names of processes, but as descriptions of the process step not as category or “code” form.
With this you have rapidly developed supply chain model capture, models for which
standardization doesn’t hide complexity, but can still be communicated,
stored, measured and controlled using standard tools throughout a company.