What Is An Enterprise Process Performance Architecture?
It’s a framework to capture all of the processes – so that they can be named and numbered – as needed.
An Enterprise Process Performance Architecture intends to have the capability to capture a model of all of the processes of an entire Enterprise.
Thus you’d want naming and numbering conventions. To enable greater efficiency in current and future Search – and finding others to be Social with (in an Enterprise sense versus a Personal sense) – or whatever thingy/thingies the next few waves of technology advances brings to us.
Capturing All of the Process/ Performance Data
Not that you’d necessarily want to… capture all the detailed data on “all” of the processes of your Enterprise that is – but you might want to for specific targets – and they might lead you to the Other Processes that enable the targets.
You want only placeholders for some areas of the business/ of the Enterprise… for areas to be deferred or left Informal forever.
And you would want “a frame/an architecture” that minimizes if not eliminates any and all gaps in your details data capture attempts.
You’d want to capture detailed data on your targeted improvement area(s).
But again, each of those are probably connected to a myriad of “other” processes. Those that Enable.
Targeting on some ROI targeting basis. So you go after the Root Issues – and don’t skip the important enabler systems that get all of the right stuff to the right process at the right quality, time, and cost.
So, it’s complex.
What would you do with all that data – organized by the Business Architecture?
My business partners and I in 1993-4, when we wrote our book The Quality Roadmap, saw it this way:
The graphic above is from our newsletter in 1994 – about the recently released book: The Quality Roadmap.
Begin with the end or further in mind.
What would you do with all of that data on all of the processes?
We would use that data and other data to target the biggest lever of ROI – or RONA, or Top Line Revenue, whatever the metrics are in your world.
Data such as the enablers for all of those processes – and the gaps – and then the R for the I for addressing any of those gaps?
For not all gaps are valued equally.
Here is a newer view of the enabler data framework, architecture, configuration…from my EPPI set of models and stuff. This is EPPI (the methodologies) 3rd Tier of data. Process data. Performance data.
Is that even necessary? Getting all of the process data for all of the processes? Of the entire Enterprise?
But if so, if yes, it being worth it that is, then how would you structure a department’s view of all of its processes? One step up from all of the existing Process Modeling/Mapping conventions? Those of my Tier 2.
How about for the management of a department – and all of it’s processes and those from elsewhere?
Here is my view at what I call the 2nd Tier, or Tier 2 View.
Your views might vary.
Is this data collection – organized by a Business Architecture – something to be Desired or simply Required?
As always, it depends.
Are you in a highly regulated industry?
Which of your Processes cannot affect your Core Processes, your Value Stream, your Revenue Stream, etc.?
Whatever the percentage is – of your “Very Critical Processes” (and their enablers – IMO) compared to “All Processes” is only one way to look at it.
A very narrow look at it. Unfortunately.
What one should look at is the “costs for non-conformance” (CONC) to standards, to expectations, to whatever.
That’s a measure of the value – of the R in ROI.
Use that to target – after getting organized by some architecture of all of your Processes if need be, or a subset that helps position/portray the critical from the less critical… Process wise.
The architecture of my EPPI Tier One – is followed by the more convention methods to capture – and help others somehow visualize this in some common manner IMO – so that shared understanding occurs and increases, as well as the lubricant of that, communications occur and increases. Not with more meetings, but from more exchanges of value.
Just because you can – collect data to the nth degree – doesn’t mean you should.
But maybe you should.
Collect detailed data about performance and all of the processes interconnects, whether in the top tier of Processes… the Value Chain, or Supply Chain – or it’s just one of many and necessary other Support Processes that have been in-sourced, doled-out carefully – or not – to the functions and departments of the enterprise – or out-sourced to others.
What Can You Do With An Enterprise Process Performance Architecture?
Indeed. It’s all about what you might do with the data.
Those with an ERP background, or an MRPII background, or those with a way-back-in-the-day MRP background will know.
This structure, the architecture frames the detailing of what I call the enablers – everything necessary to enabling all of the processes – is something best managed in a dB – a database.
You would use it – after framing or architecting all of the processes – without necessarily naming them all or detailing them all – for performance improvement. Closing gaps to achieve measured results – measured after the fact when the dust settles and is compared to a baseline/starting point, and it is also compared to the predicated results from way back in the likely, earlier competition for those limited enterprise resources of people and money, which is I know redundant.
First identifying the ideal, future state of the processes necessary now and/or in the future. And of course that is all within the context of customers and other stakeholders’ requirements. More on that Stakeholder thingy.
That’s why your Enterprise exists, or continues to exist to meet the of customers’s needs while meeting the Requirements (or Constraints) of all other stakeholders’ requirements. It’s complex.
Your Enterprise, any Enterprise, exists to provide customers products and/or services that they determine are worthy investments on their part. For their own operations and/or their own improvement.
And their are of course other stakeholders, including customers, who have requirements to be met, or not.
It is complex.
And then there are those other stakeholders.
How To Think About Your Stakeholders?
Here is an example stakeholder hierarchy where Social Responsibility is depicted as the ultimate stakeholder.
What Roger Kaufman might allow me to call this Mega.
Your hierarchy might include Unions. Your Shareholders/Owners might include pension funds, or be a single individual.
It varies there – and all over the map.
Because you could eventually get down to individual differences and preferences.
That may be too far. Maybe not.
What are the risks and what are the rewards?
How About Some Examples Of An Enterprise Process Performance Architecture?
Sure. The first example that follows is from back-in-the-day, in the late 1990s, and are from one of my former firms (where I was a partner/owner/founder), CADDI – The Curriculum Architecture Design & Development Institute.
We were 15 to 25 people serving F500 firms in the Instructional; Design and Performance Testing space.
This is an example for a T&D Organization’s Tier One View – modeled on CADDI and following the model of my 2001 book: T&D Systems View (the clockface) – where the 3 segments labeled Leadership, Core and Support enable a common approach to Leadership and Support – plus enable much greater free-wheeling – one Department to another – as they have unique (but shared) ultimate end goals at the enterprise level – that need to tie in a rationale logical fashion – some call this ALIGNMENT.:
Theoretically – this template could be applied likewise to Finance and any other department in any other function – and only the Core area needs to change – from a business perspective and it’s ability to share systems, processes, tools, training/learning, etc., etc.
Here are some additional examples for an Enterprise, for a Function and for a Department…
Enterprise: Auto Maker
How Might I Go About Adapting Any Of This To My Context?
Start with mapping the Enterprise a former organization for each of the Tiers/levels you are familiar with.
Second, tackle your current organization/enterprise via its current functional organizational structure, architecture.
- Look at the organization chart.
- The one with all the white spaces.
- Then map out, in some priority order, the 3 tiered views for your Enterprise, Function and Department chain…
Build Performance Models and Process Maps for any one of the processes in a Tier 3 Map.
Create a Tier 3 View by identifying all of the enablers for the Tier 2 Process.
This book, from 1994, covers – Business Architectures – and was written in conjunction with the Council for Continuous Improvement…
Quality/Performance Improvement – complex.
How well do your models and methods scale with that complexity?
Scale horizontally as well as vertically?
Or are you applying simple models that don’t scale well?
Yes, at some level it must be simple. For entry into the complexity.
Something I would call an Advanced Organizer… which others would say that’s simply…
“Telling ’em what you’re going to tell ’em, before you tell ’em.”
At a high level.
Then you wade into the deep end.
But – IMO – it would be a disservice to let anyone think that that top level view – is all the understanding that is needed – as if it was really that simple. And not complex.
Because in reality – it is not.
# # #