- Toyota's productivity is "consistently four times that of its competitors, and quality is twelve times better", says Jeff Sutherland in the forward.
- The book begins with a 2-page history of the industrial revolution. Starting with the late 18th century French invention to use standard, interchangeable parts for firearms, the US ran with the idea to create mass manufacturing and economies of scale that had never been precedented. Then in the early 20th century Taylor applied the idea to people--making the work of automobile assembly line workers so easy they could be trained in 10 minutes, and therefore be easily replaced. This was in strong divergence with what happened in the loom industry in Japan, where the automated looms required a lot of expertise to maintain and tune--here, individual skill was highly valued and teams were preserved, even as companies were torn down and restarted.
- Just after WWII, the Toyoda family (future creators of Toyota) felt the need to catch up with American mass manufacturing, but they did not have access to the wealth of resources required to benefit from economies of scale. Instead, they aimed for "just-in-time flow", which gave them the advantage of driving down the cost of variety in their products. The Poppendiecks say that this is "the only industrial model we have that effectively manages complexity".
- Jidoka -- autonomation -- "Toyoda automated looms... detected when anything went wrong and shut down automatically". This sets the stage for a "stop the line" mentality, mindfulness, safety and quality.
- When there are mistakes, it's not the worker's fault--it's the process which has room for error. Fix the process so we can't make mistakes.
- Plant managers were all expected to spend some time on the line.
- It is the creativity and practical knowledge of the line workers themselves that drives continuous process improvement
- Lean is infectious--Toyota and Dell have extensive supplier networks, and freely exchange information and training to support the supply chain. They define contracts in a way that align the interests of both companies.
- Peter Drucker states that "a company that maintains a single management system throughout the entire value stream will see a 25 to 30 percent cost advantage over competitors"
- BAA built terminal 5 at Heathrow airport with a novel kind of contract, including target cost and a risk/incentive pool. Whenever a subcontract finished, contractors got paid the target cost plus anything that was left over in the incentive pool. This aligned the interests of both parties, and work went more smoothly.
- the Toyota Product Development System is designed for "generating and preserving knowledge for future use"
- in product development, it is not waste to explore multiple options/technologies--they call this "set-based concurrent engineering"--these options allow us to evaluate trade-offs appropriately when the time comes to make a decision
- "repeatable and reliable speed is impossible without superb quality"
- the Kano model states that to impress customers, we need to satisfy basic needs, as well solve problems they weren't even aware of
- "behind every great product there is a person with great empathy for the customer, insight into what is possible, and the ability to see what is essential and what is incidental"--Martin Cagan of the Silicon Valley Product Group
- chief engineers at Toyota play a product owner role--they are responsible for the business success of their vehicle family, and they do first-hand research (genchi-genbutsu "go, see and confirm") of their potential customers as well as pay attention to marketing research and dealers
- inspection to prevent defects is necessary; checking to catch defects is waste
- just-in-time decision making is critical to effective risk management. The longer we wait to commit to a particular path, the more we know about our options--but if we wait too long, some options vanish. Establish, up-front, when key decisions need to be made, and then adhere strictly to those timeboxes. See set-based design.
- "above all, team members must be mutually committed to achieving a common purpose"
- "unused features are the worst kind of waste in software development". Justify every feature!
- "great software grows out of a mind-meld between a person who really understands the business and a person who really understands the technology"
- simplify--both the product and its implementation
- part of the design must incorporate the concerns of operations staff--people that will support and maintain the application
- seek a "product" funding model, rather than a "project". Products are funded incrementally, evaluated on their return on investment, and are released incrementally. Like landscaping or gardening, custom projects are never done. When a "product" is championed by business leaders, it is more likely to have business value.
- Don't automate a complex process. Simplify the process, then code it.
- When a lot of work needs to happen quickly, we need "self-dispatching" work--that is, remaining work items need to be evident to everyone on the team, and people need to see the overall status of the group
- a discussion often changes once a "decider" has been selected. Make it clear who that decider will be, and then watch the arguments unfold.
- it's important that proposed changes in a system are done scientifically--so we can evaluate the old against the new (PDCA)
A value stream represents the work we do starting with a customer order and ending with delivery of that value. The map needs to be detailed enough to uncover problems, but should also abstract sufficiently so we can see the big picture
- long delays indicate queues--we want to get rid of queues because they represent an unfulfilled need, a warehouse of undelivered value that wastes money to sustain, and they inhibit feedback from the customer
- process loop-backs indicate churn--if you're re-prioritizing, re-checking, re-designing, re-doing, it's waste!
- balance the workload
- minimize the items in process
- minimize the size of work items
- release regularly
- limit work to capacity
- use pull scheduling
- Lean can only be realized when there is true respect for people in the workplace. At Boeing in 1988, the 777 project started with the premise of "working together"--and this fundamental respect for people ended up creating a work environment that shares many attributes with Toyota's lean process.
- Deming wrote about how to use people's full potential in the workplace: "appreciation for a system (synergy of parts), knowledge about variation (problems come from the system itself), theory of knowledge (Plan Do Check Act), psychology (skill, pride, expertise, confidence, cooperation)".
- Also see Deming's 14 points to increase quality.
- Deming said that a company's purpose is to create products that please the customer so much that they'll keep buying more products--that is, to make a sustainable system, focused on long-term relationships
- In a lean organization, problems aren't recurrent--they aren't systematic--because as soon as a problem is detected as systematic, the system is changed
- "standards are viewed as the current best way to do a job, so they are always followed"--anyone who finds a better way is expected to change the standard documentation
No comments:
Post a Comment