My 12 Boxes for Leveraging Enterprise Process Performance Improvement – Part 1 of 12

Introduction to the Series

In this 12 part, monthly series I will explain my starting mental template for conducting analysis of a organization, function, department, process, practice, team, job, role, etc.

At some point it’s all about the Process – whether you call the ones you’re looking at part of the Value Chain, Supply Chain or Support Chain – there are interlinked processes in a unique, complex and both overt and covert web. It’s the real world, and it’s complex baby.

To get a handle on it all, I have one mental model, that itself is at one level in my analysis and design mental templates that I might need to adapt one application to the next. Here it is.

The EPPI 12 Box Model

EPPI Fishbone v2012 - 1- The Process

Part 1 – The Process Itself

Or Processes. Most likely Processes. And their Requirements? Are the human and non-human Resources required by the Process adequate?

Yes or no.

And then there are their Stakeholders’ Requirements.

Of the Process.

And their Stakeholders’ Stakeholder Requirements. To the Stakeholders in a bit. Back to the Process – or more appropriately, the Processes. A single Process never exists all by itself. But what’s important about the Process is why it exists in the first place.

Picture2

Has the Process been designed to meet the needs – the requirements and the desired aspects of product, place, price and service… and anything else they demand or just want … of the customers?

Have the sets of Processes that any department might be required to address been designed to meet those needs, in a balanced manner when there is conflict in the Requirements?

Conflicts in the Requirements?

Yep.

Inevitable.

In the Process? Yes.

Does a Process Map or Performance Model show this? Show the Stakeholder Requirements?

No and Yes.

EPPI Tier 2

Does the Performance Model reflect Requirements in the Measures portion of the Outputs column?

Look at this example – tweaked from the real Performance Model from a project back in the mid-1980s…

ABC Sales PM Chart Example

Yes. Stakeholder Requirements can be reflected in the Measures.

Which is why I prefer that format of the Performance Model to that of the Process Maps, Swim Lane or otherwise.

And I always prefer PERT charts to Gantt charts – but that’s another Blog Post.

Of course, it’s helpful to see the Context for a Performance Model chart – one page or more – for one chunk – one Area of Performance of a job, process, team, department, function, enterprise or industry horizontally and/or vertically. Scalable.

AoPs Sales Rep

And it helps to see that job context within a larger context.

EPPI Tier 1 View

What is a department or team? A collection of People Resources and non-People Resources, adequate or not, to the Requirement of the Processes which reflect the Requirements of the Stakeholders.

You can’t design a Process properly without knowing the Requirements of the Stakeholders – for both your Products/Services and the Processes that deliver them, until you know the Stakeholders Requirements. IMO.

EPPA - Building Block View - Department

Has the Process been designed to meet the needs – the requirements and the desired aspects of product, place, price and service… and anything else they demand or just want … of the customers – and all of the other customer’s customers?

Oh, and it’s beyond customers. It’s all of the stakeholders. And don’t forget that they have stakeholders too.

Slide12

Yeah. Complex.

 Stakeholders

Why are stakeholders important to consider in the name of Process or Processes?

They determine your metrics – for both Product and Process, or one or the other. Mapping a Process is just one thing. Gives you that understanding.

But what’s Ok or not OK about all of it, some of it, are determined by others. Upstream, downstream and in the moment of THE FLOW – it’s “all about” who is measuring whom and what against what measures and standards.

And how that compares with any competition, that exists, or could.

Here is one potential view of a Stakeholder Hierarchy…

Stakeholder Hierachy Example 1

Why a Hierarchy you might ask?

Because if any Stakeholder has a requirement that is in direct conflict with another, there must be a way to sort them out quickly and see who wins and who loses and what might need to be done to mollify or mitigate or avoid totally – that situation where push comes to shove and some Stakeholder doesn’t win. Doesn’t get their Requirements or Desires, met.

And they may not be happy about it.

And maybe there is nothing that you can, or should, do.

But maybe you should do, something, that is. Because of Risks and Rewards. The stakes.

But how to tell?

Determine all of your stakeholders.

Maybe you are not so Socially Responsible, not so Mega (per Roger Kaufman). Then your would start with this… and modify it as needed…

Stakeholder Hierachy Example 3

But wait! These aren’t single Stakeholders in a stack. They are categories of Stakeholder and there may be more in that Sub Process Box than you can shake a stick at. Delving in to understand the Risks and Rewards for meeting or not the Requirements in that Category is a business decision.

With an R for the I.

Then…After Determining Which Stakeholder to Focus On…

Then Matrix their needs/desires/ the requirements against one another – and see where they all co-exist peacefully, and where they do not. Knowing where issues exist problems that are opportunities, or opportunities that are problems, each have their own R for the I.

Be a Good Steward.

Stakeholder Requirements Matrix Example 2002

That understanding of issues – leads to Strategies based on Value of the Risk and/or Reward at Stake. Then Tactics and Tactical Plans and allocation of Resources.

After all, your stakes are tied to your Stakeholders’ stakes.

Get aligned. Both on the requirements, and the issues, strategies, tactics and resources that are required to meet others’ requirements. That’s just the way it is, isn’t it?

For more, see my 1995 article, which includes additional potential Stakeholder Categories.:

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).

That article is available directly from ASQ – for $10 – but for only $5 for ASQ members – here.

Next Month, on the 15th, we’ll cover another of the 12 Boxes of EPPI. On the EPPI Fishbone, with hats off to The Ishikawa Diagram.

EPPI Fishbone v2012 - 1- The Process

# # #

Advertisements

3 comments on “My 12 Boxes for Leveraging Enterprise Process Performance Improvement – Part 1 of 12

  1. Pingback: Part 13 of 12 – My 12 Boxes for Leveraging Enterprise Process Performance Improvement | EPPIC - Pursuing Performance

  2. Pingback: Part 3 of 12 – My 12 Boxes for Leveraging Enterprise Process Performance Improvement | EPPIC - Pursuing Performance

  3. Pingback: Part 2 of 12 – My 12 Boxes for Leveraging Enterprise Process Performance Improvement | EPPIC - Pursuing Performance

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s