Can the value of a process be defined by its output?

5
4

Something happened this morning that caused me to start thinking about this and it's been hanging around with me all day. Outputs, in my case today quality documents, can certainly provide value. But should we rank this value based on the conclusions presented in the document, or rather by the inputs employed to generate the knowledge?

How do we know if the conclusions to an investigation are valid if there is no understanding of the process followed? In reviewing such a document, would a ‘Lean Thinker' ask, “What are your results?” or would the correct first question be, “how did your team come to these results?”

Following the Toyota example, some processes should actually take more time and resources to complete, not less. Decide slowly, execute quickly. But then again, it all comes down to how value is defined. Truth is, I think a lot of value is lost if the goal is the output and processes are not followed. One such pitfall is in comparing results with similar, or complimentary functions or systems. How can such a comparison have any validity without a strong basis in the process for arriving at conclusions?

If shortcuts are available and easy to take, the process likely needs to be reviewed for opportunities to eliminate wasted steps and standardize. Looks like I found myself another assignment…

Please check out my main blog page at www.leanblog.org

The RSS feed content you are reading is copyrighted by the author, Mark Graban.

, , , on the author's copyright.


What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn – and follow me or connect with me there.

Did you like this post? Make sure you don't miss a post or podcast — Subscribe to get notified about posts via email daily or weekly.


Check out my latest book, The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation:

Get New Posts Sent To You

Select list(s):
Previous articleGetting Xbox 360 to market requires coordination
Next articleQuelling Command and Control Thinking
Luke Van Dongen
Luke, an auto industry engineering veteran, blogged here from 2005 to 2006.

4 COMMENTS

  1. A few thoughts:

    1) sometimes, Toyota seems to think forever and consider all alteratives (and then acting quickly). but lean/TPS also involves a certain bias for action — try something and decide/work/evaluate quickly. I guess the key is knowing when each is appropriate

    2) yes, process is vital. i used to work on productivity benchmarks/comparisons across auto engine plants. we spent so much time tweaking the numbers to try to make it apples to apples, and also spent so much time justifying our problems and why the numbers “had” to look that bad, what was the real value of the exercise? none, I would argue. benchmark against perfection and you don’t have to waste all that time on the benchmarking/justification process.

    But, if you looked at the chart, without realizing the work (valid or dubious) that went into it, you were getting a really skewed picture of reality. When you’re not in the gemba, and relying on reports, that’s bound to happen.

  2. Isn’t the answer in the value perceived by the customer independent of the process or the time? If all value is defined from the customer’s point of view then the rest is just argument.

    The answer must be honest, as that is the basis for all value, and it must fill some need for the customer. If I have a way of coming to a valid answer and you can come to an equally valid answer with less work, isn’t your answer inherently better?

  3. Thanks for the discussion and comments.

    I certainly agree that a ‘valid’ answer derived from a lesser amount of work is better than an equally valid answer that took more effort to determine. But how is the validity of the answer, from the customer’s perspective evaluated?

    As an example, 2 activities may be asked to complete an 8D or go through a similar investigative quality process. The first activity follows the process of forming a team and sets out to see and experience the defect or issue. They work to define and verify root cause, escape points and corrective actions.

    A second activity assigns responsibility for completing the document to an individual who is told to ‘get it done’. That person sits at their desk, reviews available information and completes the report including root cause and corrective actions.

    Assuming both activities arrive at the same conclusions and prevent recurrence both can be said to be valid. However, I would have much more confidence that the results from the first activity are based on true understanding and data, and I would contend that their activities brought them closer to experiencing the problem from a customer’s perspective. Conversely, I would worry that the results of the second activity are based solely on the opinion or understanding of one individual.

    The above example provides 2 opportunities to create value. The first is in correctly identifying and eliminating a specific issue. The second is the individual and organizational learning and understanding that occurs when the process is followed completely and when communication takes place throughout the process to share not only the results, but also the investigative iterations. To me this knowledge and experience is vital in the effort to transform into a proactive, rather than a reactive organization.

  4. The first, longer, solution process might be better if it taught others in the team something. The problem with lone wolf problem solving is that knowledge is kept within that single person’s head. Team problem solving can not just solve the problem, but also forces people to share ideas and work together.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.