| 5S is often perceived by managers as just being about good housekeeping. However, Hirano had larger objectives in mind when he developed this system. He strongly believed that in the absence of a system like 5S, JIT did not have much chance of succeeding. In a manufacturing environment, 5S plays a critical role in eliminating various waste related to excess inventory, unnecessary motion, and unproductive processes. Furthermore, by reducing complexity, it also helps reduce product and process defects. Thus, 5S has become an integral part of JIT management in manufacturing industries. It can similarly play a crucial role in a DFTS initiative by helping address the following issues: Streamlining documentation: Multiple and outdated copies of documents are a great source of risk and can adversely affect software cost, quality, and delivery schedule. This must be addressed such that one electronic copy is kept in a central repository. Someone from the team should be assigned to update and inform the necessary people about changes if and when they occur. Similarly, someone should be responsible for managing memory on C and C++ projects (Java does this automatically). Sorting customer orders: Much programming time is lost as more program development code is discarded than is ever used. This has a severe effect on cost, schedule, and developer morale. A streamlined process to sort customer orders eliminates all whimsy from the development environment. All the managers who say "I don't know what I want, but I'll know it when I see it" should be reassigned. Sorting current and old development software: All software should be sorted. The current versions should be separated from the old versions, which are archived. This ensures that the development staff uses the latest standards. Avoiding "feature multiplication": This is a serious problem in software development. Needed and unneeded features should be clearly earmarked so that development time is not lost on developing unneeded features. Optimizing supply costs: A systematic analysis of the development process provides information about supply needs for the required software development tools. Thus, only needed development tools are licensed. Furthermore, such analysis identifies the need to license a second copy, if needed, for developers working from home. Thus, supply costs for software development tools are optimized. Standardizing processes and practices: 5S when implemented properly invariably results in simplified procedures and processes, thus reducing complexity. This is of huge importance in mistake-proofing (see Chapter 9). Creating an orderly development process: Process analysis also helps build a program development environment that can maintain catalogs of current and prior project builds. Managing a technology repository: Often, you have versions of software and technology that are no longer used but that need to be preserved as a backup and as support for customers who may not have updated. Housekeeping: 5S provides a system that keeps all software versions current during development using a database-oriented grandfather/father/son system. Using a UML-based flowchart system can help you keep high-level documentation current. A specialist could be assigned to each programming team to maintain this documentation. Improving productivity: The preceding practices result in improved overall productivity. They also provide an opportunity for optimum planning of space requirements for programmers, including those who work at home. This may, in turn, reduce space requirements. Improving the work environment: A streamlined, clutter-free environment is a useful by-product of a 5S system. It should be further strengthened to encourage communication within and between programming teams. It also releases space for meetings and other group activities.
Sidebar 10.1: From 5S to the Lean DFTS Process The word "lean" is at the heart of the Toyota Production System (TPS). It was first used by Womack and Jones in their 1991 book The Machine That Changed the World.[2] The authors surveyed and benchmarked manufacturing companies around the world and concluded that Japanese manufacturing companies were typically much more productive and efficient than their Western counterparts. A few years before this book, Taiichi Ohno, the man behind TPS, had published Toyota Production System, which explained the foundations of "lean manufacturing."[3] Ohno devised seven categories of muda ("waste" in Japanese) that cover virtually all the various ways in which manufacturing organizations waste or lose money. These came to be known as the "The Seven Wastes." The purpose of JIT management, a key component of TPS, is to identify and eliminate waste by making it visible and measurable. Organizations that have a relatively small proportion of wasteful activities are lean enterprises. What is waste? Ohno defined waste as the use of all resources that do not produce the product as defined by the customer. If the customer does not need it or will not pay for it, it is waste. This includes material, machines, energy, and labor. He classified waste into the following seven categories: Overproduction Waiting Transportation Inventory Motion Overprocessing Defective products
Ohno reasoned that anything that does not create value for the customer, even items that are needed by the producer to meet production or regulatory requirements, is waste from the customer's perspective. The producer cannot do without meeting regulatory or other service requirements of a business, but the waste associated with them must be contained to the absolute minimum. Ideally, the waste must be eliminated, not just reduced. Even in highly efficient Japanese organizations, the true value added is often less than 3 to 4%, which means 96 to 97% is mudaa chilling revelation. Identifying waste is not enough. TPS consists of a range of tools that are used to identify and eliminate waste. Some of the most important tools are JIT, jidoka (autonomation), poka yoke (mistake-proofing), and kaizen (continuous improvement). Hirano believed that such unprecedented and unrelenting effort to identify and eliminate waste at every level in an enterprise would hardly stand a chance without the workplace discipline that a 5S system provides. Lean production is beyond the scope of this book, but a DFTS system embraces the TPS philosophy of identifying and eliminating waste. A wasteful enterprise cannot deliver quality products. Table 10.1 compares seven major categories of waste in both manufacturing and enterprise software development. It reveals the striking similarities in challenges regarding elimination of waste in manufacturing and the software development process. A lean software development process is a natural progression for an enterprise that has embraced DFTS. It is also possible to deploy lean and DFTS processes in tandem. All such enterprises (those going for DFTS and Lean DFTS) would be well advised to build a solid organizational foundation for such ventures by implementing a 5S system first. |
Table 10.1. A Comparison of Seven Wastes in Manufacturing and Software DevelopmentManufacturing | | |
|---|
Type of Waste | Cause of Waste | Basic Corrective Tool(s) |
|---|
Overproduction | Quality problems cause loss along the way | Voice of the customer (VOC)
Quality Function Deployment (QFD)
Improved design
Poka yoke (Mistake-proofing)
Statistical Process Control (SPC)
Complexity reduction
Just-in-time (JIT)
Single-Minute Exchange of Dies (SMED) | Waiting | Need for work-in-progress (WIP) finished goods due to large batch size | Theory of Constraints (TOC)
Cellular layout
SMED | Unnecessary transportation | Due to functional layout | Cellular layout | Excess inventory | Quantity discount
Quality issues | True-cost analysis
Cellular layout
JIT
Root-cause analysis
SPC
Poka yoke | Unnecessary motion | Cluttered and untidy workplace | 5S | Overprocessing | Rework because of quality issues | Root-cause analysis
SPC
Poka yoke | Defective units | Rework because of quality issues | Root-cause analysis
SPC
Poka yoke | Software Development | Type of Waste | Cause of Waste | Basic Corrective Tool(s) | Too many program modules rewritten
Too many unasked features | Poor planning and design | VOC
QFD
Improved design
Poka yoke
Complexity reduction | Waitingunable to complete next build | One or more program modules are not ready | Better program planning
Support for overloaded team (TOC) | Too much movement of code and/or personnel | Dispersed development team | Improve locality of effort as needed (cellular layout) | More development tools licensed than needed Wrong module development | Poor planning and design | Maintain tighter controls on development tool licensing Better program planning 5S | Too much team communication | Too many programmers on team | Clarify relationships 5S | Overprocessing due to faults | Too much rework due to poor design or implementation | Better design and improved testing criteria
Root-cause analysis
Poka yoke | Defective modules in development | Inadequate software development tools | Better design and improved testing criteria
Root-cause analysis
Poka yoke |
|
