Resolved
3 votes

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?

Thursday, January 22 2015, 09:44 AM
Share this post:
Responses (14)
  • Accepted Answer

    Thursday, January 22 2015, 10:10 AM - #Permalink
    Resolved
    7 votes

    My $0.02

    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.

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 22 2015, 10:24 AM - #Permalink
    Resolved
    3 votes

    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 reply is currently minimized Show
  • Accepted Answer

    Thursday, January 22 2015, 10:24 AM - #Permalink
    Resolved
    7 votes

    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.

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 22 2015, 10:38 AM - #Permalink
    Resolved
    2 votes

    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. 

    The reply is currently minimized Show
  • Accepted Answer

    Ian Gotts
    Ian Gotts
    Offline
    Thursday, January 22 2015, 11:29 AM - #Permalink
    Resolved
    2 votes

    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"?

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

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 22 2015, 11:31 AM - #Permalink
    Resolved
    1 votes

    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. 

    • Lloyd Dugan
      more than a month ago
      Extremely well said and concise. I would add that most top-level examinations of so-called end-to-end processes tend to gloss over this point because it implies definitional granularities that can be difficult to resolve with respect to the operational models likely necessary to provide the "detailed attention" cited here.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 22 2015, 12:30 PM - #Permalink
    Resolved
    1 votes

    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.

    BR,

    José Camacho

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 22 2015, 12:35 PM - #Permalink
    Resolved
    1 votes

    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.

    Thanks,
    AS

     

     

    • Jose Camacho
      more than a month ago
      The compliance with regulations, external and/or internal, should be part of the of the process goals.
      Anyway, the cost of compliance should be managed with the risk of non compliance.

      Thanks,
      JC
    • Dr Alexander Samarin
      more than a month ago
      I consider that "compliance with regulations, external and/or internal" as the enterprise policy, i.e. global scope, while a process goal has, usually, local scope.

      Thanks,
      AS
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 22 2015, 01:37 PM - #Permalink
    Resolved
    5 votes

    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.

    • Emiel Kelly
      more than a month ago
      I always use the same metaphor, but use some different term.

      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.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 22 2015, 02:22 PM - #Permalink
    Resolved
    2 votes

    As in life, both the journey and the destination are important. One should be wary of sacrificing one for the other.

    The reply is currently minimized Show
  • Accepted Answer

    gB
    gB
    Offline
    Thursday, January 22 2015, 04:00 PM - #Permalink
    Resolved
    1 votes

    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.

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 22 2015, 04:11 PM - #Permalink
    Resolved
    2 votes

    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.

    The reply is currently minimized Show
  • Accepted Answer

    BPM Mentor
    BPM Mentor
    Offline
    Sunday, January 25 2015, 08:28 AM - #Permalink
    Resolved
    1 votes

    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.

     

    • Emiel Kelly
      more than a month ago
      True, but the weird thing is that I bought a Porsche 918 last week, paid with money earned by helping companies who had no clue what were the right things to do.
    • BPM Mentor
      more than a month ago
      Sounds great Emiel ! It means you did the right things and helped them find the right way. Isn't it?
    The reply is currently minimized Show
  • Accepted Answer

    Joe Cooper
    Joe Cooper
    Offline
    Sunday, May 10 2015, 12:21 PM - #Permalink
    Resolved
    1 votes

    Could it be that Deming was saying "treat the cause, not the symptom"? If so, do most think this still holds true?

    The reply is currently minimized Show
Your Reply

Join the Discussion

Want to join the discussion?

Login, or create an account to participate in the forum.

Top Participants

Dr Alexander Samarin
277 Replies
28/09/2016
David Chassels
270 Replies
29/09/2016
Emiel Kelly
222 Replies
29/09/2016
Bogdan Nafornita
209 Replies
29/09/2016
E Scott Menter
182 Replies
28/09/2016