Lean IT

Matthew Smith, Jason Tice

Supporting Manufacturing

IT supports lean manufacturing by facilitating communication, providing access to information, maintaining hardware, supporting software, and creating technology that enables lean processes. In terms of facilitating communication, IT allows manufacturing to better communicate a signal. Signals are an important part of lean. They indicate real time demand, provide feedback on quality measurements, and help facilitate kanbans. In order for a signal to be effective it must be communicated rapidly, accurately, and efficiently. In addition, signals must be communicated both internally (on the shop floor) and externally to partners and suppliers. IT becomes involved in signaling when it is done using an electronic medium. Common examples are email, instant messages, and integrated systems (databases and web services). A signal sent electronically is often faster than other methods. This helps to eliminate waste and increase the flow of the production process.

Lean manufacturing emphasizes transparency in process. IT supports this effort by providing open access to information. Two common barriers to open access are file compatibility issues and security constraints. A good practice to reduce these issues is to use common tools such as Microsoft Word and Excel. These tools are familiar to users and are more widely accessible. To reduce security constraints, file permissions should only be set to prevent corruption of data rather than limiting access. This makes all data accessible throughout the company and helps to build a "culture of trust".

IT also supports manufacturing by maintaining the hardware and software used in daily activities. Because most of this hardware and software are integrated into the production process, care should be taken to reduce quality issues and prevent downtime. This can be accomplished by centralizing purchasing decisions to limit the variety of hardware and software configurations. Limited configurations reduce the complexity of support and make machines easily interchangeable. This reduces the support costs necessary for maintenance and also reduces the downtime required when the machine breaks.

Another important way IT supports manufacturing is by creating and supporting technology that enables lean processes. Two important examples of technology in manufacturing are Enterprise Resource Planning (ERP) and Material Resource Planning (MRP) applications.

An ERP system integrates all data and processes for the company into a single system. The key component of the ERP system is the unified database. Common examples of ERP systems are PeopleSoft and SAP. For a lean system, the ERP must be configured to shift focus from shipped orders to new orders. This is because lean thinking places emphasis on pull from customer demand rather than forecasting demand. To obtain realistic customer demand, the system must also be modified to allow for pre-orders. Pre-orders are purchases that have been made but have not necessarily cleared the purchasing demand. By focusing on new orders and enabling pre-orders, the ERP system can be configured to communicate real-time demand to the production process helping to improve flow through the process.

The MRP system is a subset of the ERP system that focuses on material procurement and scheduling for the company. Traditionally, the MRP system purchases material based on forecasted demand. However, in lean manufacturing material procurement is based on actual demand via kanbans. As a result, this function of the MRP is no longer necessary. In addition, scheduling is simplified in lean manufacturing by aligning actual demand with worker hours needed to produce a unit of product. This also reduces the relevancy of the traditional MRP. Despite these incompatabilities, the MRP system can still be relevant if it is modified to work with lean manufacturing. It still provides good reporting utilities, handles material procurement for non-kanban materials, and provides antipated demand to suppliers.

Implementing Lean in IT

To understand how to implement lean in an IT environment, it is important to first consider the overall role IT plays in the organization. From an external perspective, IT acts as a supplier of technology to the business or manufacturing process. To be a lean supplier, IT must assist in product design and provide reliable, high quality components to the business. From an internal perspective, IT acts as a manufacturing process. It produces software that is consumed by the business and consumers. To be a lean producer, IT must follow principles outlined in lean thinking: value, value stream, flow, pull, and perfection.

The traditional approach to IT consists of three facets: developing software via the waterfall model, producing technology to satisfy a specific need, and doing quality checks prior to the release of software. The waterfall model of software development is a phased approach. It consists of five stages: requirements analysis, design, implementation, verification, and maintenance. These steps are performed consecutively with little overlap. A major feature of the waterfall model is big upfront design (BFUD). This means that a lot of time is taken early in the process to ensure that the initial requirements and design are complete. BFUD is primarily done by the business sponsors of the project with little involvement from the IT department. Once the BFUD is complete, the business decreases involvement in the process until the verification phase.

The waterfall model has several problems. The first is that it is difficult to get each stage perfect. As the project is tested, problems often surface that requires the entire process to restart. This causes the timeline for the project to expand proportionate to the size of the problem. Often this occurs because of the fundamental problem that knowledge is not effectively transferred upstream in the waterfall model. The last major problem in the waterfall model is the lack of feedback from the customer. Because verification does not occur until the end of the project, it is often difficult to gauge the success of the project. This is a major reason many new applications are not successful.

The lean approach to IT consists of three facets that juxtapose those discussed in the traditional model: agile development, simplified product design with reusable, components, and built-in quality controls. Agile development is a lean approach to software development. Like lean, agile contains small, self-contained teams. The teams are cross functional containing all participants needed to complete a project (developers, customers, and testers). The focus of an agile system is on building working software. The primary tenants of agile are embracing change, connecting with the business needs, empowering individuals, and shortening releases. Like the traditional model, agile follows the five stages: requirements analysis, design, implementation, verification, and maintenance. The difference is that agile performs these iterations more often and with smaller requirement sets. This is akin to lean development, where batch sizes and lead times are reduced. After each release, agile also involves the business (or customers) in the design process by getting immediate feedback on the production. The implications of agile design are that agile acts as a lean supplier by involving IT in the design of the system and by providing high quality components due to the constant feedback from the business. Agile also enables the production process to act as a lean producer by empowering individuals to become more involved in the value stream of the product, by having more releases to reduce variability in the system, and by testing more often to reduce the defect rate of the product.

IT can also become lean by simplifying product design through design patterns and libraries. Design patterns are optimal solutions to common problems. An example of a design pattern is in the design of a calendar for the front-end of web applications. A calendar is not natively defined in Hypertext Markup Language (HTML). As a result, it has been implemented in different ways across web interfaces. This is why when visiting the Orbitz web site (http://www.orbitz.com/), you retrieve the calendar by clicking in the date field and on the Travelocity web site (http://www.travelocity.com/), you retrieve the calendar by clicking on the calendar icon. Design patterns attempt to unify designs by specifying the best case scenarios for using non-standard items. A good example of design patterns is those posted by Yahoo! (http://developer.yahoo.com/ypatterns/). They attempt to provide a resource to unify and simplify product design.

Development libraries provide another abstraction to simplify product design. These are common code grouped as a resource to developers. Development libraries facilitate simpler product design by abstracting complex code, reducing incompatibility issues, reducing testing, and shortening development time. Development libraries are often produced internally and externally. Libraries often act as a best-case implementation of design patterns. The combination of the two allows IT to build solutions to meet multiple needs and reduce the length of development time necessary to bring a product to market.

Maintaining High Quality Within IT Environments

One of the greatest challenges facing organizations in the information age is maintaining high levels of quality within the Information Technology applications that support their activities. There is a common belief that IT applications have low barriers to change. When new functionality is needed, a new screen, report or calculation can be added with a few quick keystrokes and modifications to existing programs. Based on this statement, one might think that the traditional rules from Lean Production about taking measures to minimize change are not applicable when applying Lean Production rules to IT applications. If it really is possible to enhance and customize IT applications with a few quick keystrokes, then processes to control and minimize requests for changes (one of the core elements of Lean Production) will provide no benefit with regard to insuring high quality output through the minimization of change requests.

While the thought that IT applications can be easily changed without introducing additional risk sounds plausible, there is much evidence that maintaining high quality in IT applications is more challenging than originally thought. In particular, a large percentage of IT projects are considered failures, the long term support costs for IT systems frequently exceed the development costs, and there is a common belief among high level management that it is better to replace systems instead of enhancing existing systems (Schwartz, 2004). Based on these statements, design, development and management of IT applications can benefit from Lean Production methodologies in similar ways to a typical production process. In particular each of the statements above that relate to challenges within an IT environment can be addressed with traditional Lean Production techniques.

Working to Reduce Project Failures

One of the greatest challenges within IT environments is taking measures to insure project success. As previously mentioned, a large percentage of IT projects are considered failures. Upon closer examination, one determines that part of the reason for such a high failure rate is that there is no standard definition for a project about what 'success' is. As an example, a business needs to write a new program to calculate and process loans. The business analysts do a poor job of documenting the loan process and communicating it to IT. Hence the IT department develops a valid program for the requirements they were given; however, the problem is that the requirements were incorrect due to the poor work of the business analysts. In this example, the IT department was actually successful as they delivered a program that completed the needed calculations; however, the project is ultimately considered a failure because the requirements were incorrect in the first place. The problem going on in such scenarios is ineffective communication. Applying Lean Production to improve such a scenario would call for the integration of open communication between all stakeholders. Specifically, IT developers would be involved in the requirements gathering process from Day 1. IT could ask questions and insure that they understand what needs to be done. The process of IT asking questions about the implementation would help to insure that the business analysts had considered all necessary requirements before turning things over to IT for development. Finally, open communication between all stakeholders would insure that all involved in a project have a clear definition of what is necessary for the entire project (not just their component) to be considered a success. Providing a single definition for 'success' for all parties involved will help to insure that the correct questions are asked to insure that the application being developed or supported meets the needs of the business.

Another possible reason for the high degree of failures in IT related projects is the minimization of required testing until the final phase of the application development just prior to release. In the traditional waterfall development process, testing is not completed until near the end of the project life cycle just before the new IT application is released. If problems are found when testing during this late stage of the project, many times it is difficult to modify the application to address the problem conditions within the time and budget available. The Lean Solution here is to again integrate more open communication in the project life cycle between all parties involved. Specifically, as developers are working on implementing required features, these features should be made available to testers as soon as possible so they can be tested and feedback can be given to developers about changes that need to be made early in the development process. Such a practice is called 'iterative development' as the required work is divided into small chunks (called iterations) and each chunk represents a collection of functionality that can be delivered to testers and tested during the development phase of the project life cycle. The benefit of iterative development and ongoing testing is that problems will be identified sooner, making it easier to address them prior to completion of the project. One of the greatest challenges associated with waiting until the end of development to identify problems is that sometimes issues are identified that may require a major redesign of the entire system. As mentioned earlier, when such shortcomings are discovered late in the project life cycle, there may not be sufficient time and money to address them prior to the conclusion of the project. Hence by testing earlier, problems can be identified sooner allowing for additional time to fix them. In summary, open communication between all parties involved, and implementing continuous testing and feedback are Lean Production techniques that will serve to effectively reduce the number of IT projects that are considered failures.

Reducing Long Term Support Costs

Another area where Information Systems could benefit from Lean Production techniques is working to reduce application support costs. It is frequent that the long term support costs for an application frequently exceed its development costs. There are several factors that drive the support costs for IT applications significantly higher. Many IT systems have complicated designs and are poorly documented. These two factors are complicated by the high rates of employee churn within the IT industry. A common scenario within IT is a system is developed, and then the employees who were responsible for the development of the system move to other jobs. Several years after the system was built, it becomes necessary to enhance the system. At this point, the current IT staff (who were not involved with the initial design and coding of the system) have to figure out how the system works so that enhancements can be made. As can be imagined, with limited documentation, the process of figuring out how a system works is time consuming. Additionally, there is a high risk of creating system errors when enhancing a system whose operation is not fully understood. Usually what happens is developers are able to make requested changes to a system, such as screen or calculation enhancements, but what happens, is that after requested changes are made, it is discovered that the changes had an unintended ripple effect. Consider a payment system, where the system is enhanced to include new taxes and fees in the payment calculations. In this scenario, a developer goes in and makes the changes to that the new taxes and fees are calculated. Later on it is discovered that the values that were updated are also used in a credit application, where the taxes and fees should not be included in the calculation. So in the process of enhancing one application, a different application was broken. Several elements of Lean Production can help to improve the outcome in this scenario. First, steps should be taken to use common components and simplify product design. Instead of writing original code to perform system operations, are common libraries available to perform the same function. Since many technical staff members are familiar with common libraries, and common libraries have good documentation, integrating a common library into the system makes it easier for new staff to understand how a system functions and what it does even if they were not involved in the original product design. Another element of Lean Production that would aid in reducing support costs is taking steps to involve multiple stakeholders in the development of each component. Instead of having a single developer write each module of a program, have developers work together on the development of all modules. This will serve to enhance communication and share knowledge on how the system works and what each component does within the work group. With such information sharing in place, loss of an employee from the project or company will not result in a significant loss of project expertise. Finally, one of the most important elements needed to reduce support costs is continuous feedback and testing. In the scenario described above, the required change was made; however, the ripple effect of the change was not immediately discovered. IT support costs can be reduced by taking steps to automate the process of receiving feedback. Relating to the example from above, automated testing / feedback could have altered the developer that the change they made to include the taxes and fees on the screen broke the credit report on another screen. Creating such automated technical tests will be discussed later.

Reducing system replacement and waste in IT

One of the greatest sources of waste seen in IT environments, is replacement of previously developed systems with new systems, when it could be possible to enhance an existing system to perform new functions instead of simply discarding it. This is directly related to the principle of 'Muda' (waste), and represents one of the areas where Information Technology could benefit significantly from Lean Production. Several reasons are cited from it is more common to replace existing IT systems instead of enhancing them. The first reason cited is the high support costs and risks of ripple effects from making enhancements as discussed above. As previously discussed, Lean Production can effective reduce support costs and risks associated with making enhancements through effective communication, information sharing, and implementing measures to receive automated feedback. Next, IT systems are replaced so companies can benefit from the latest and greatest technologies available. Relating to Lean Production, the question to ask here, is what value upgrading to the latest and greatest technology will provide an organization. When faced with the decision to upgrade, organizations should perform a Value Stream Analysis to determine the costs of performing an upgrade and the benefit it would provide. If the upgrade will not generate significant benefit for the organization, such as an increase in sales or reduction in costs, is the upgrade necessary? Consider a company that wants to overhaul their e-commerce system, so it can handle increased capacity. Does the company have plans to take strategic actions to increase their sales volume, which would require a more robust e-commerce system? If strategic actions are planned to increase sales, then the upgrade is justified, but if there are no plans for a big change, the expense of a complete upgrade cannot be justified. Instead in such a situation, how can the organization leverage its existing e-commerce site into what it wants to do? Maybe instead of replacing the entire system, the existing system can be given a facelift with new graphics and menus to enhance the user experience at minimal cost to the organization.

An additional possible reason for frequent system replacement in IT, is the lack of a strategic vision within many IT departments. Most IT departments are driven by a 'mission' statement that focuses on the current functions of the IT operation, such as providing 99% uptime, etc. What many IT departments are lacking is a strategic vision, and how that strategic vision can tie into the organization's strategic vision. Without a strategic vision statement, many IT departments simply focus on upgrading to and integrating the latest technology as that's is what they think the role of their department is, since how IT could specific help the organization achieve its strategic goals has not been documented. Since IT is usually considered an internal supplier to an organization, many IT vision statements are driven by goals to increase efficiency and reduce costs, such as, reduce IT operating costs by 5% annually, reduce the average time needed to implement a new enhancement by 5%, etc. Once an IT department implements a vision that ties into the vision of the organization, they will realize that they have a greater purpose than simply providing the latest technology to the organization, and the focus of IT will shift away from upgrades, to using the existing resources and systems within their department to support the company mission. A strong IT vision statement can be one of the most effective means to reduce waste within IT operations.

Effective testing to insure high quality in Lean IT systems

One of the concepts from Lean Production that has the most application with IT is integrating measures to obtain continuous feedback regarding the quality of system / software being produced. High quality in IT applications is only achieved through effective and complete testing to insure that the application satisfies all requirements. Despite this statement, the important of testing to insure high quality, almost seems minimized in a traditional (non-Lean) IT environment. Within the 'waterfall' development model, business analysts document system requirements, then IT writes the application code from the requirements, then testers write tests from the requirements, and finally testers execute their tests on the application when the coding of the application is complete. With this traditional model, everything flows down from the original requirements documented by the business; however, the drawback to this model it is high inflexible, and there is a great chance of error as a result of miscommunication. As an example, suppose that development finds the need to change a requirement and discusses it with the business, and the business agrees to the change. But the business then forgets to tell the testers about the change. When the testers run their tests, they will document a bug in the software, when in reality it is not a bug and the system is doing what it is supposed to do as a result of the discussion between IT and the business.

The other obvious drawback to traditional testing under the waterfall development methodology is that it is solely dependent on human testing. Not to say that human testers cannot be effective; however, IT systems potentially have hundreds of thousands of line of code, and given such complexity and all of the possible combinations and logic in a system, is human testing effective enough to insure that the system does what it is supposed to do. Clearly, given this high degree of complexity, there is a need for some type of automated testing to insure the quality of the system and add additional credibility to the results of the human testing.

As has been previously discussed, one of the core elements of Lean Production that is highly applicable in IT is taking measures to insure open communication between all stakeholders involved in the production of product or process. Implementing Lean in IT would call for an organization to step away from traditional waterfall development and involve all parties in the testing process. In a Lean implementation, the business would first document the requirements for the system. Then developers would write technical tests to insure the code does what it is supposed to do, prior to writing the code (see Test Driven Development below), based on the requirements from the business. Then at the same time, testers would work with developers to review the requirements and write functional tests based on the implementation. All parties would perform these duties within the same physical space to insure that all were aware of any changes that were made. Finally, execution of tests would begin earlier in the process. For the automated tests written by developers, those tests will be written prior to writing any application code, so developers can run the technical tests as they are writing their code to insure it does what it is supposed to do. Also, in a Lean IT implementation, work will be completed in iterations / chunks, making pieces of the new system available to testers earlier in the project life cycle. As discussed earlier, testers will be able to start testing components of the system as soon as they become available. This will allow for more testing to be completed (as compared to waiting until all development was complete) and also provide the opportunity for testers to make recommendations early on as to how a system can be improved.

Test Driven Development

As computers have become more powerful, IT developers have been allowed to develop extremely complicated programs to perform advanced functions. It is common that modern business applications will have more than 100,000 lines of code. As stated before, with this high degree of complexity automated testing is necessary to insure the components / sub-routines within a program are doing what they are supposed to do, and also that when components are put together, they will produce the desired results. Hence to control these elements, Lean IT environments require the use of Test Driven Development.

Test Driven Development (TDD) involves writing a technical (code based) test, to confirm that a component does what it is supposed to do, before the component is written. The key element of TDD is the fact that the test is written before the actual code. There are several reasons for this practice. First, by writing the test first, the developer will get immediate feedback as to when the component is performing the correct operation, and they can move onto the next component. Writing the test first, insures that new components will not have unintended ripple effects on existing components (as discussed earlier). Hence when a new component is added to the system, it should not break any tests for any other components. If a new component has ripple effects to other parts of the system, the broken tests will identify the other areas that need to be addressed as a result of introducing the new component. The final reason why the tests must be written first, is that typically if developers write the code first, they may forget to write the test for a component after the code is done. In order for TDD to provide a high level of feedback on a system (such as automatically detecting ripple effects) it is necessary for all code to have tests. If a lazy developer writes code without tests, then the quality of the system is put at risk as the feedback available from the tests does not cover all of the application code. Hence it's necessary to write the tests first, to insure that all code within a system has technical tests to confirm its proper operation. Requiring tests to be written before code is one of the most effective means to maintain this requirement for high quality in Lean IT.

So how to get started in TDD, let's consider a simple example. Suppose you are going to write a sorter that sorts input into ascending numerical order. What tests should be written before writing the sorter to insure it does what it is supposed to do. First, the sorter needs to confirm it can sort numbers, so we would write a test where we give the sorter a set of numbers and confirm that we get sorted results back. Say input {3,4,2,1} and the sorter should return {1,2,3,4}. So the primary test has been written, but there are still more things that need to be tested. Ideally tests need to be written to handle what happens when we have special conditions. So what if we have repeated numbers in the input. If we input {3,5,3,2,1}, the sorter should return {1,2,3,3,5} - it still sorts even with the duplicate entries. Next what if for some reason, the sort gets no input, it should do nothing, that test looks like, we input { } and we get back { }. Next what if we just put in one number, no sorting needs to happen so we should get that same number back, that test looks like, we input {3} and we get back {3}. Finally, we need to consider error condition, such as sorting a non-numeric input. If the sorter gets a non-numeric input, it should throw an error, that test would look like, we input {3,G,1}, and we get an error message. So in conclusion, we would write 5 tests first. Then we can start to work on writing the code for the sorter, once all 5 tests pass for the sorter, we know that the sorter is done and we can move onto implementing other elements of the system.

TDD allows for an additional small element of Lean Production to be integrated into IT. Many Lean Production methodologies incorporate simple visual cues to provide feedback on the production system, examples include Kanban cards, inventory tickets, etc. Using TDD, it is now possible to provide visual feedback on the health of an IT application. Development tools exist, such as the Eclipse development framework and CruiseControl that automatically run tests as code is being written. If all tests pass, then developers see a green bar on their workstation desktop. If any of the tests fail, the developers are alerted with a red bar and can take actions to resolve the problems in the system. In addition to providing visual feedback to developers with red/green bar on their workstation, the status of tests can be used to send emails and instant messages, etc. Hence project managers or other developers can be automatically notified as soon as there is a problem with the system that needs to be addressed. TDD insures that focus is placed on quality when developing software through its requirement of writing tests first and the feedback it provides regarding the overall health / quality of an IT application / project.

Integrating Six Sigma with TDD and Lean IT to insure high quality

Once an IT department adopts TDD practices to support converting their IT operations into Lean IT operations, high quality within IT can be insured through the use of a quality management system such as Six Sigma. TDD can provide can provide metrics upon which metrics can be calculated and tracked over time. TDD metrics are computed through the use of code coverage tools. Such tools examine the technical tests written as part of the TDD process and compare them the application code. The tools can determine how much of the code is covered by the technical tests, such an analysis yields what is called a 'test coverage' metric. Once the 'test coverage' metric is determined, the results should be examined in two parts. First, what is the overall 'test coverage' for the application. Second, what is the 'test coverage' for element of the application that are critical to quality (CTQ)? Once the 'test coverage' for these two elements has been determined, it is possible to perform a DMAIC analysis using the data from the 'test coverage' within the Six Sigma framework. The following is a discussion of how DMAIC can be applied to an IT department that wishes to improve their quality by enhancing test coverage of their application code using TDD.

Suppose you work for an organization that wants to improve the quality their IT applications by converting to Lean IT and TDD. You decide to perform a DMAIC analysis to improve quality. For the 'Define' step, your goal is to reduce the risk of error by improving test coverage within the department's applications. Next for 'Measure', you determine the current test coverage rates using a code coverage tool as discussed above. For 'Analyze' you review the test coverage data and look for areas that need to be improved. Decisions about what needs to be improved can be based on areas that have a low percentage of test coverage, or areas that are CTQ and need to have 100% test coverage. For 'Improvement', begin to add and enhance test coverage in the identified areas from the Analyze step. Finally for 'Control' establish test coverage minimums (such as 80% of all code must have full test coverage and 100% of all CTQ must have full test coverage) and improvement rates to be followed in the future (improve test coverage by 10% per month until minimum coverage levels are met). Using a process such as Six Sigma, can be extremely helpful in assisting an IT department with setting its strategic vision. As mentioned earlier, many IT departments struggle and waste resources due to their lack of a strategic vision so using an established methodology to insure high quality can be beneficial to insure that maintaining high quality becomes a core component of all IT strategies.

Conclusions about maintaining high quality in Lean IT

In retrospect, while many think that IT applications may have low barriers to change, in reality introducing change to IT applications can cause support difficulties and unintended ripple effects. Although it may be easy to make a change to an application and see it come up on the screen, one of the greatest challenges for non Lean IT departments is knowing what the full impact of a change made will be. The methodologies of Lean IT that have been discussed here provide several means by which the risk of making changes in IT can be reduced. First, integration of libraries and components into IT application simplifies product design and makes application support by parties other than those who initially wrote the application less complex. Finally the risk of change in IT application is reduced by taking multiple measures to insure effective testing of the application and any changes made. Measures to insure high quality testing used in Lean IT include: test driven development, on-going testing by test staff (not waiting until development is complete), and involving multiple stakeholders (tester, developers, and business staff) in the testing process.

Sources

Beck, Kent, Beedle, Mike et all. (2001) Manifesto for Agile Software Development. Retrieved from: http://agilemanifesto.org/.

Cunningham, Jean, Jones, Duane. (2007). Easier, Simpler, Faster: Systems Strategy for Lean IT. Productivity Press.

Greenbaum, Joshua. The Lean IT Revolution: Going Lean Means Starting Lean. April 29, 2005. Retrieved from http://www.managingautomation.com/maonline/member/exclusive/read/ The_Lean_IT_Revolution_Going_Lean_Means_Starting_Lean_3571742; jsessionid=FD3A6AD427E65EC7B486F45255CBFD2E?page=2.

Schwartz, Ephraim. "Most IT Projects Fail", InfoWorld, August 13, 2004. Womack, James, Jones, Daniel (2003). Lean Thinking. Free Press.

< Return to Portfolio