The Process – and the Enablers of That Process
I’ve seen a lot of references to architecture in my professional spaces lately.
As one who has been using the term since 1982 – and published on it in 1984 in an Instructional Design context in Training Magazine – and in 1994 in a Business Process/TQM context in The Quality Roadmap (book) – I see weak architectural depths – a lack of real architectural thinking – engineering-like thinking in the descriptions and models presented. Perhaps the authors are just teasing us with what they are willing to share – and that there is a lot more behind the curtain.
Just as real architecture has BIG Picture views – you know the artist rendering for skyscrapers – and LITTLE picture view – you know the tensile strength of the bolts and nails to be used – so too does my view of architecture – in an Enterprise Process Performance context.
Here is my version of the Ishikawa Diagram (a.k.ka.: as the Cause & Effect Diagram or the Fishbone Diagram). I use this mental framework in my Instructional Analysis efforts to help my clients see where formal Instruction would be helpful – and where it would not. More on that later.
The Big Picture of EPPI – Enterprise Process Performance Improvement
There are 3 major variable-sets in my model:
- The Process Itself or the Processes Themselves
- The Environmental Assets (required by the Processes) that Enable the Processes
- The Human Assets (required by the Processes) that Enable the Processes
Your model(s) may differ.
More on these Enablers Provisioning Systems later, too. But here is your first glimpse of the Enablers.
But to be clear – it’s all about the Process or Processes.
Start with the Process. If the Process itself isn’t capable of meeting the requirements of the Stakeholders (including but beyond the Customers and the Customer’s Customers, etc.) – then messing with/ improving the systems that provide the Enabling Assets is putting the proverbial cart before the horse.
Such as a focus on Learning/ Training/ Instruction – or Performance Support – is premature until the “Processes are OK As Is” box has been checked.
Once the Process is – by design – determined of being capable of meeting the Stakeholders’ Requirements for both the Output (Product) and the Process – then it’s time to figure out which of the Enabling Variables might need to be addressed – for an I, for an R.
An Investment for a Return.
ROI. That itself can be positive or not; significant or not. Or nil.
Scaling Up – To The Enterprise
This next graphic – excerpted from the prior graphic – is intended to show the scalability of this approach. That single Processes can be rolled up into the entire set of Processes of any Enterprise – and can be done so using a Departmental Framework as one key organizing unit – as well as others.
If one is to “architect” the Processes of an Enterprise – there must be some organizing scheme being used that eventually account for them all – formally recognized or not.
And if Budgets rolling up and down (visualize THAT) can work using a Departmental framework – then it can also work for Processes. Architecting Budgets for Finance and Processes using a common Department framework creates one key alignment. This next diagram shows one branch of the complex tree that is the hierarchy of Processes – and Budgets – in an Enterprise of any complexity.
Just as most Learning is Informal (and has been since the dawn of time for man), so too with Processes. It’s difficult – but not impossible – to nail them all down, Jello-like that some may be.
And the Processes can be captured/documented using a Process Map – and/or a Performance Model.
Let’s look closer at a Departmental framework.
Scaling Down – To Departmental Processes
I use the Department as a key “framing” device. I use it despite the exhortations from back in the day – of TQM – in the 1980s – to organize the Enterprise by it’s Processes.
But that I saw might lead from Functional Silos to Process Silos – neither a good thing with their loss of shareability and interconnectedness.
I prefer using whatever is the prevailing method that an Enterprise looks at itself – and launching into a Process perspective from there – so as to not lose most everyone on those initial steps in their Process/Quality Journey.
And to help with the later effort of determining what might be sharable across the enterprise – I use the segmentation of scheme of 3 types of Processes that are Management’s – and one that is Individual Contributor’s.
- Leadership (Management) Processes
- Core (Management) Processes
- Support (Management) Processes
- Individual Contributors Process
Note that the order and numbering is quite arbitrary.
Change THAT if needed – in keeping with my philosophy of:
“Adopt what you can – and Adapt the rest”
Going Down – To Individual Processes
Some a simple – relatively simple that is. Such as my EPPI Stage I – Targeting EPPI – Process – as represented by this next graphic.
And some are complex.
This next isn’t really that complex as many Process Mappers can attest.
Another view of the colorful (if blue and white can be called colorful) EPPI Stage II Process.
Once One Knows What a Capable Process Requires as Enablers – One Can Assess Those and The Upstream Provisioning Systems
If – and this is a big “IF” – as many believe that this variable is only a contributing factor in poor performing Processes in less than 20% of the cases (see this article about that) – that Knowledge & Skills is a cause – then one needs to look upstream at the Provisioning Systems to see what’s broken up there.
Perhaps the Training & Development System needs to be addressed – and/or the Tools & Equipment System. One provides the formal Learning that might be needed – and the other provides the Social Media tools that might be used to facilitate organic Communities of Practice, etc. And perhaps the Data & Information System needs to be tweaked to change policies & procedures for use of Social Media and acquisition of such.
When is it not?
That’s why I created and use, and share these frameworks – to help me Take a Systems View – or as Roger Kaufman would argue: a System View – but I go with the flow of whatever the client thinks about such language.
As I learned long ago, “it’s not just semantics – it’s always semantics” (author unknown – but that phrase was taught to me back in the mid 1990s by a colleague who could not attribute it to anyone that they could remember – so credit for that astute statement – like so many others – is lost to time).
I use these mental frameworks in my Instructional Design consulting work – and in my Performance Improvement consulting work. I usually get the latter when the former concludes that the cause – and therefore the Solutions – to Performance Issues (opportunities as well as Problems) lie outside the K/S realm.
Hopefully, you can too.
About That 20% Figure
From the article mentioned earlier…
If we accept Stolovitch’s proposition that a consensus has emerged from the work of the most prevalent leaders in the field, then the statement “80 to 94 percent of performance problems are related to the environment” can be linked back first to Deming who said “In my experience…” and then Rummler and Brache who wrote “We have found that about….” We have not been able to locate any specific research to demonstrate that these claims are evidence based, only assumptions.
Of greater significance are the points raised by our peer reviewers:
Every performance problem is situation specific (Pearlstein);
Our task is to identify and manage the variables necessary to improve performance (Brethower);
It is almost certain that both workplace variables and performer variables will be involved so we should consider both categories (Brethower);
Solutions will not always involve training (since for example, motivation is a largely unexplored cause and a key component of the solution to many performance problems) it is essential that we put people in the forefront of all performance issues (Clark).
Dr. Farrington summed it up eloquently stating, “In the world of solution choices, it doesn’t matter, really, what causes the highest average percentage of performance problems (if such an average number were really available to us outside of educated estimates). What matters is, for this particular issue that we are trying to fix, we are looking past pre-determined notions about what’s causing said issue. We’ll apply the set of solutions that get us to where we need to go—whether that’s training, or not.”
# # #