Input(s) – PROCESS – Output(s)
When called to investigate Performance Issues – for Performance Improvement (PI) efforts or for Instructional Systems Design (ISD) efforts – my mental models for Enterprise Process Performance kick in.
I backwards chains quickly to try to understand the Output(s) from the Process – and what the Process Input Requirements are. And then I move back to the Output(s) – each as an Input downstream – if not waste/scrap – to determine what their Requirements are.
I try to see a Process within a set of Processes, within a hierarchy of Processes, such as on the left side of the next graphic. Think: branches on the Enterprise Tree. This is an example of but one branch…
That helps me organize my understanding into some framework – the LCS framework – as I cannot think of a system as some messy collection of Processes all tangled up like spaghetti on a plate. I need to compartmentalize the Process I am looking at – and all others that come into play in my assessment/analysis efforts into some scheme. Some framework.
No Process Is An Island
Processes interface with at least two other Processes – one or more upstream and one or more downstream. I need an inkling of a clue about that.
Has the Process “been designed” to meet the Requirements – all of the Requirements from all of the Stakeholders?
Those Requirements that are for the Products – the Outputs – of the Process.
And those Requirements that are for the Process itself.
There are Performance Competence Requirements at the:
- Individual Level – The Worker
- Process Level – The Work
- Organizational/Enterprise Level – The Workplace
- Societal/Mega Level – The World
Whatever Level… the Performance Competence Requirements can be stated in exactly the same framework, per this next graphic…
Back to Process
A Process may involve many others outside the organizational unit (I start with Department – an arbitrary choice that I might change – situation depending) – some “owner” of the Process.
If that is not clear then that is a problem.
But the first problem about Process is when there is none – meaning that “different Day – different Process” – may be the rule.
A bunch of “whatever, whenever, however” nonsense – IMO.
An Informal Process – if you will.
An Informal Process that should be Formalized ONLY if it is a problem – where the value of the Problem (or Opportunity) is worthy of addressing. In an ROI sense. Otherwise – let it be.
My mental models owe a lot to the work of both Dale Brethower PhD and the late Geary A. Rummler PhD.
Brethower-Rummler: General Systems Model
It’s the Stakeholders’ Requirements That Govern – Or Should
The first example above places Social Responsibility at the top – over the Needs/Requirements of “the laws of the land” via The Government. Perhaps that is too idealistic for your context.
And a third example…
Obviously – in this third example – there is no “Law of the Land” to govern the Enterprise – or there is – but it’s not part of the Business Model, etc.
Stakeholders – Beyond Customers – Is Key.
Other Past Posts On This
I’ve written about this many times in the past.
Some of my Blog Posts on this – Stakeholders – may be found – here.
My 1995 Article On This
An article of mine on this was published by The Journal for Quality & Participation – March 1995
Here is what was sent to the publisher…
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).
The publisher – of course – published something a little bit different.
ASQ members and others can get The Journal for Quality & Participation’s published article – here.
Note: the article is $10.00 to non-members. And it is $5 for ASQ members.
Performance – Exists Within A System
At every Level – The Stakeholder Requirements – are key to any improvement effort.
It’s a System!
And how you and your stakeholders “frame it” – is also key.
# # #