We should work on our process, not the outcome of our processes, is a famous quote from Deming. Do you think it still holds true?
Most of us in the business process world have moved beyond Deming. If you accept that the "outside in" approach is appropriate for business process, process and outcome are a simultaneous focus.
If you're attempting to drive out variation, Deming's approach is workable because the goal, i.e. less variation, is known beforehand.
Personally, I don't understand how anyone can work on a process without considering three kinds of outcomes -- customer delight, internal controls, and efficiency.
Salut, the latter part of that statement does not hold true. Processes transition across the organizational domain, internally and externally, each one having an outcome. You cannot improve on how work is done or how information flows if you do not take into thought the outcome. In working to improve the process (es) for customer fulfillment you have to ensure the logistics partner can receive the information facilitating them to deliver to the customer within the time frame committed with the product in factory condition, as well as many other pieces to such a puzzle. This is end-to-end process management – outcomes are part of a process and in many scenarios are processes. In the past forum members have had issues with e-2-e processes, as being over rated so to speak.
Could've swore there's been a lot of opinions here and elsewhere in recent times talking about "managing to outcomes." That being said, I'm a fan of both - process automation and managing to outcomes, as the two entail a bottom-up and top-down approach both. Doing both and meeting in the middle usually yields the best solution for outside-in and inside-out both. Makes sure you plumb the depth of what the client knows and applies your own expertise to the problem domain as well.
"The best solution."
Just my tuppence.
A process is a means to deliver a result. So outcomes first. If you work on useless outcomes, the process is useless.
If you know what your useful results are, there is a process needed to deliver that. And probably the process is already there. It might not perform so well, but it is there, otherwise your company would produce nothing.
So when take a look at a process? I would say when someone is not happy with what the process delivers.
So to answer the question: outcomes first; process when unhappy about outcomes. Sorry Deming (although he probably meant the same)
A good process starts at the end, so don't become very good in executing useless processes.
When running live process mapping workshops, when we define the top level of the map (which could be Quote to Cash or Recruit to Retire or even the entire company) we always start with the final outcome. And often a significant amount of the time is spent debating and getting agreement on exactly what the outcome is.
What is the definition of "satisfied customer" for your organisation. Everyone had better be clear, because that will drive the processes you have in place. Or let us take an even more common process, which seems so simple.
"When is a software support call resolved"?
Until we get agreement on this simple question, we cannot build the processes.
So define outcomes which allows you to design process that have the roles and responsibilities. Simple really.
All processes have an outcome which may from time to time change. It is how the process works which will require detailed attention as empowered users think of better ways to achieve the desired outcomes.
In my opinion, the essence of the business processes is to realize business goals, previously defined in business strategy. It's a serious fail If we try to manage business processes without this alignment. So, first define the goals and related KPI's, then design and implement the business processes strictly to respond to the goals. To close the cycle, evaluate the outcomes of business processes comparing with the goals, then identify and implement the required improvements If were detected deviations between the goals and real outcomes of processes.
Thanks to Enron, this is still true.
Imagine the goal can be achieved only by breaking a law/compliance/policy/etc. (i.e. part of the process). What is your choice? I hope you know the answer.
I look at it this way:
- Processes are like journeys
- Outcomes are like destinations
If your goal is to go somewhere in particular, then you need to keep both in mind when planning a route. Otherwise, you're simply on a recreational jaunt that may or may not take you someplace interesting.
It's the same as in accountability: you don't manage your company watching the final profit line. You manage what need to be done in order to get profits.
Deming means that. Of course you always watch the outcomes, and without customer satisfaction, internal controls and efficiency you don't get profit. But you should focus on optimizing the process, including measuring and improving it continuosly.
I agree with most of the other commenters that it is important to work on both the process and the outcome. The outcome needs to be named, defined, and then measured - both from the customer perspective and from an internal perspective (volume, throughput, defects. etc.) Then the process defines how we get there today (current process) and a new process could define a better method of getting there. We need to know and measure outcomes, and we need to model and improve the process.
Peter, to answer your question in one word: Yes. Deming said it for processes due to his area of expertise, but the quote can be extrapolated to any other area. For me, the message is: do not try to "re-define" the expected outcome to fit the weak process. Instead, improve the process to fit the outcome. It stays true and it will stay forever because once you find out the right thing to do, you need to also do it right.