Or … Processes
Yeah. Focus on many processes, or just one process.
Note: This is a variation on my themes of:
- Focus on the Performance Requirements – and Enable Them
- Focus on the Process Performance Requirements – and Enable Them
This is all “scale-able.” From one to many.
These are some of my many models … for Performance Improvement Consultant … operating out of some L&D operation.
You know who you are.
Your title may vary.
Your models may vary.
Mine starts by looking at 3 sets of data: Process, and then if appropriate the Environmental Assets (everything non-people themselves) – and – human assets (the stuff people bring to the Process Performance party.
- Environmental Assets
- Human Assets
Next – the Big Picture of EPPI.
The Big Picture of Enterprise Process Performance Improvement (EPPI)
Here is my big picture graphic… as an “advanced organizer” for those of you who actually look this over…
… and side 2: To the next level of depth … for your Advanced Organizer …
… any questions …?
Processes exist at many levels. Processes are either routine or non-routine. They are either predictable or they are not. They are either internal to one department (for execution of the process) or they involve other people from other departments – or whatever the organizational unit it at the lowest level.
But somebody should be in charge – and own it.
If you see each organizational entity as a set of owned and supported Processes – you can begin to get your arms around them all – with minimum gaps and overlaps.
And then you can describe them and their relationships to other Processes (and departments/functions etc.) and determine if they are formal enough or need some tightening – given all the other needs for the human and non-human resources that might be called upon to do this improvement – formalizing the Process to the level needed – not necessarily the level possible.
Once you pin down your Processes to the extent needed for your purposes you can begin to define them in terms of Requirements of the Process and end Products…
But who establishes the Requirements?
Is it the Customer … downstream … and suppliers upstream … and the employees in the Process Box … and, and, and …?
All of the Stakeholders – including the Customers.
But the Customer is not King.
Note: Even your Stakeholders have Customers – and other Stakeholders.
So this is really quite complex … in just getting the Requirements for the Process and the Products clear – and balanced … because what if the Stakeholders disagree and are in direct conflict with each other … oh my.
Lions and Tigers and Bears – oh my.
They are different – and over-generalizing gives you mush. Beware.
Here is an article I published on this:
The Customer Is King – Not! – 15 page PDF – the original version of the article published in the Journal for Quality and Participation in March 1995 – address Balancing Conflicting Stakeholder Requirements, and suggests that the Customer is Not the King of Stakeholders (despite the unfortunate slogans from the Quality movement despite Deming’s admonitions about slogans).
Next – once the Requirements are clear enough (always “enough” and never “perfectly”) then you should start on understanding the enablers required and any gaps in their adequacy – in terms of quantity, quality, timely availability and cost – your model may differ – and then you can fix ’em – using the 20/80 Rule (or so).
If gaps are found in the enablers of Processes – then the ownership for those Enabling Processes (which when bundled I call a System FYI) can be identified and then you can fix their wagons (Processes). Using the same thinking, models and tools that let you diagnose and address the original target – maybe something in a Main Value Chain Process – or in a Supporting Value Chain Process (like any part of HR or Finance or Building & grounds, etc.).
Here is my starter model – that I use to identify the enabler systems and functions in my client’s Enterprise’s overall Process-set.
The division of this into 2 – is somewhat but not totally arbitrary. It’s a reconfiguration and adaptation of the Ishikawa Diagram (from Japan in the 1950s).
You model may vary.
Here is a closer look at the EAMS – and some intervention types that may or may not be appropriate.
Here is a closer look at the HAMS – and some intervention types that may or may not be appropriate.
Here in one graph (again) are your considerations as a Performance Improvement Consultant.
Your title may vary.
But as we all know – it’s not often that Learning Content – or Performance Support – is going to be the only solution to addressing a Performance Gap.
# # #