Which Comes First – The Processes or the Metrics?

With Apologies to all the Chickens and the Eggs as to which comes first

Doesn’t Matter As Long As They Align

A Need is determined and some Process or set of Processes evolves to meet that need, formally or most likely informally. And the metrics measure how well that was done, how effective and efficient.

People do things with things to produce things… Products. Alone or in groups, People and Assets and Products that is.

Those things that People produce, the Assets that they consume doing so, and those Products and/or Services that they render to the targeted marketplace of the Marketing Plan within the Business Plan… are either acceptable, or they are not.

They either serve their intended purpose, cost an appropriate amount, and are available just in time – or they don’t.

That’s what it’s all about… with apologies to The Hokey Pokey… in my approach to Performance Improvement.

Which are based on many, many models and methods and tools and techniques. Many.

Starting with…

Brethower’s & Rummler’s General Systems Model

This model goes back to 1963 – when Brethower and Rummler were both at the University of Michigan. Became aware of a version of this in 1979.

I also like this next, which I ran into back in 1981…

Ishikawa’s Diagram

This goes back to the mid-1950s in Japan…

Gilbert’s BEM

I showed colleagues and clients this – the BEM – from Gilbert… from his 1979 book… which I had in 1979…

But I always showed my colleagues and clients this page of Human Competence first…

This view of the anti-BEM, resonated with people.

So I used that view to orient them to Gilbert’s version of the 6 Boxes… the BEM.

All of these and more, especially from the world of TQM, Total Quality Management and then Six Sigma and Lean, all informed my practice of Performance Improvement.

So that came first.

But did my Own Processes come first or did my Own Metrics?

Hmm.

Neither, not the current view of them.

But again, I don’t think it matters as long as they align.

In the Big Picture.

Wallace’s EPPI Big Picture

This BIG PICTURE of EPPI – a summation of my views and how some level of my “starting place” models, methods, tools and techniques.

I start with processes – in my analysis/assessment efforts – in looking for gaps from ideal, or possible other states, in the current state. Gap Analysis.

Wallace’s Stakeholder Hierarchy & Requirements Matrix

Doesn’t matter what your customer insists on if the government forbids it.

Does it?

Or if it would bankrupt the Owners.

The Customer is not King.

You can then matrix each of YOUR specific Stakeholder’s Requirements against each other to look for conflicts.

Then the hierarchy kicks in. For resolving conflicts.

Because not everyone’s needs, when they are in conflict with other stakeholders, can be met. So whose ge tme tand whose don’t can be made less tricky.

Doesn’t necessarily make explaining that to your Stakeholder easy, but it could help you help them see the why.

This is more complex the higher in the organization chart that you go. And it’s already very complex at the job level, let alone at the department level.

But at the Enterprise it is simply the summation of all of the individual needs (and desires) of the individual individual, the individual departments, the individual functions, the individual business units, of the individual divisions of the individual enterprise – who exists as but one Source/Resource in one industry of one marketplace in a complex global marketplace.

Wallace’s L-C-S Enterprise Process Architecture Framework

I like using the Department as a cornerstone for my many starting points, for it almost always exists.

This is how I break it into systems and processes and tasks, etc. By Areas of Performance of 3 types: Leadership, Core and Support. Your model may vary.

This department level ties back to the fishbone view of the enterprise in a typical organization chart view of enterprise divisions, business units, functions and departments… and cross-functional teams, right on down to the individual Human and their unique job, despite the shared job description.

And their unique Performance Context.

And their enablers. Or their dis-ablers.

Wallace’s EPPI Fishbone

What’s it all about – this enabler thing? What are the enablers?

I divide my Systems View of this – the enabling assets (or capital, or resources) into two types of Assets – Human and Environmental. Human and Non-Human. Assets that is.

There are many sub-types within the 11 types of enablers of this diagram. Think of all of the data and information that you use in your job and how they might be classified for an inventory and tracking system… to manage the availability and quality of them… and the cost of having them… those data and information… your your job, and everybody elses’ – across the entire enterprise.

Your going to need a bigger boat, er, database, to manage this data, the enabler data, for it will invariably change. The frequency and costs of that change would be good to understand when designing your own system and processes to Provide those to your downstream customers, meeting the Requirements (and Desires?) of the Stakeholders for you and them…and their customers/stakeholders.

Wallace’s Process Assets Enabler Provisioning Systems Analysis Framework

Whatcha gonna fix to make your Enterprise Process Performance Improvement?

My framework for looking at the specifics of the Performance Context I am focused on in terms of which enabling systems internal and external to the Enterprise’s Processes and Functions/Departments – or Functions/Departments and their Processes – again it doesn’t matter which came first as long as they align.

My Process Performance & Enabler Analysis – showed us the gaps in Process – caused by gaps in Assets and thus pointed to gaps in upstream Provisioning Systems that brought both Human and Environmental Assets to the Process, an indictment for their own Processes, and their own enabling Human and Environmental Assets.

Here’s my starting framework, something that I probably started to adapt into the reality of the Performance Context that I am looking into back during earlier analysis, to be completed and adapted and tested prior to use…

Which doesn’t mean that I am not cognizant of the larger Contexts… macro, and the smaller Contexts… micro and the need to be able to see them also in my Systems View.

The use, uses, are the Fix or Fixes?

My fixes, your fixes, are known by many names, but in essence are overlapping versions of each others’ root methods, tools and techniques.

Working in the diagram below right to left… we do the Fix to impact an Enabling System’s Processes, by performing an Analysis on it’s L-C-S Processes to look for gaps in their Products and Processes in meeting their Stakeholders’ Requirements… and desires?

The Fixes to the enabling systems of any Process are to enable that Process to be both effective and then efficient in producing the Products/Services to their downstream Receiving Systems and their Requirements – and Desires – of their Stakeholders.

Yep. Complex.

Meaning – IMO – that simplistic models, methods, tools and techniques – in isolation – are not sufficient to the task of affecting improvement and getting it to stick.

The overall model of the reality is always more complex than the pictures used to depict it for some purpose.

The data involved in capturing the specifics of your own downstream Receiving Systems and their Requirements – and Desires – of themselves and their Stakeholders should be at the front end of any ERP system. IMO.

Including those Desires – especially for mature marketplaces. Emerging marketplaces are just evolving to meet the most critical of the Needs if not all the Needs. Desires will come later for them.

Meet the Marketplaces’ Desires?

Beyond Requirements?

Their Wants on top of their Needs? Those too?

Yep. Sometimes. It’s situational. As always.

As Always – It Depends.

How mature is your marketplace? Are you and your competitors at parity on meeting the Requirements of your marketplaces’ customers?

Have others started shifting to Desires?

Is it time to add that to the list of your Requirements – to provide for your customers’ Requirements and Desires – in order to differentiate yourself in a mature marketplace?

This is a question for all organizational entities, ideally answered from top to bottom, and not bottom to top.

But if the top isn’t doing it, do it for yourself, for your own organizational entity.

Even at the department level – the team level.

My book 6-Pack from 2011 cover most of my models, methods, tools and techniques.