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.
"The best solution."
Just my tuppence.
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.
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"?
[*] When it has been reported to the help desk?
[*] When it has been investigated and found to be a bug?
[*] When the user has been told that it is a bug and it will be in the next release?
[*] When the new release has been delivered?
[*] When the user has implemented the new release?
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.
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.
- 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.
Process Result = Destination (e.g. Amsterdam)
Goal = What you promise about the result (e.g. I want to be there at 6 pm and not spend more than 70 Euro's and don't wanna break the law)
Process = How to reach that result and goal
Process characteristics = Aspects of the process needed (e.g. I travel by car, I take this road etc, have to keep that speed)
And you can imagine that a satnav/gps can be seen as a BPM system.
Scott's opinions only. Logo provided for identification purposes only.
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.
- Page :
However, you are not allowed to reply to this post.