Zoltan VAJNA

LEAN Tools in the IT Sector

Nowadays the LEAN tools with their proven efficiency are indispensable parts of the production management. I think there is no producing enterprise that cannot utilize a wide variety of these LEAN tools. The question now is how these tools can support companies in increasing the efficiency of their supporting IT processes. In this study I will demonstrate how these well-known LEAN tools from production management can be used in IT management to create more cost-effective, efficient and transparent solutions during the IT system development and IT operation activities. I will show respectively without attempting to be comprehensive the most important tools of the LEAN management and I will analyse how these tools can be used in the IT sector. At the end of this study I will demonstrate what the IT managers think about the practical use of these tools.
JEL Classification M15
Full Article

1. Introduction

We cannot really study local markets nowadays, since major international corporations are present in every market segment, it is thus safe to say then even small local producers have to compete in an international competition. Different professional organisations constantly aim to formulate new recommendations, which include principles that enable the corporations to more successfully compete in their specific market segment. This is how the LEAN approach spread from the automobile manufacturing industry a few decades ago. The most important elements of LEAN include flexibility, the identification of customer demands, providing values and eliminating losses.

Without the appropriate IT support and IT systems, no corporation can meet the modern market challenges in the 21st century. IT plays a dual role in business: we use it as a controlling tool and as a supporting tool as well. Considering the fact that IT is intertwined in everyday lives, it is safe to say that IT operation, IT system development and the results thereof are very important factors in the efficient operation of a corporation. In my view, in order to enable IT the play the largest role possible in our business results, we need to eliminate losses.

2. Eliminating Losses

In the competitive market there is a specific price the customers are willing to pay for a product. Therefore LEAN methods aim to raise profit through decreasing the losses of the specific processes, instead of increasing prices. Toyota’s Production System distinguishes between a total of seven losses (Ohno, 1988), which was later supplemented by Liker with an eighth (Liker, 2008).

These losses are the following:

Overproduction: overproducing is the result of the manufacturing process that produced to the inventory, without actual orders. The costs of overproduction appear in multiple fields of the manufacturing process, including HR, storage, energy consumption and even transportation. In order to limit overproduction, JIT transportation, application of the Kanban or “pull” principle, and one-piece flow were invented. In my opinion, overproduction in the IT field means that more functions are developed to a specific system than what is required. In such cases, the loss is apparent in the time spent, in operating and maintenance costs, but if the system’s complexity increases, it will have a direct impact on the work performance of the users and the Support activity generated during operation.

Waiting: when material flow is not continuous on the line, waiting takes place. Waiting may be caused by unbalanced manufacturing, loss due to changeovers, or it may be due to the lack of materials. When reserves of the system run out, the first apparent consequence is waiting, which may be eliminated by techniques such as SMED, balanced manufacturing or KANBAN baskets of the appropriate size. In the field of IT, waiting should be divided into two separate parts: losses during development and operational time. Waiting during development can be caused by the lack of available environments, during the time of testing or re-testing, or by the non-conformity of distributing authorisations. In the development period, it is probably the lack of information or its accuracy that causes the major and frequent problems, since it affects all the other losses as well. During operation, waiting can be caused by maintenance times or slow response times.

Unnecessary movement of goods: the loss of the movement of goods occurs when the product is moved more than what is necessary for the specific process. In such cases, unnecessary expenses occur on both the HR and the logistics side. In production, this type of loss may be reduced for example by the plant layout (U-shape) and by rethinking outsourced activities. In the field of IT, the unnecessary movement of goods may apply when specific applications do not produce the required result for the first time, since this involves fixing and re-testing. The previously mentioned quality and quantity of information also leads here, since if the customer has to be visited again, it is classified as a loss. This attached loss can be eliminated most easily, if the infrastructure required for development is established at the customer (Poppendieck & Poppendieck, 2003).

Processing or quality loss: every action that is beyond the identified required values, causing loss. Re-processing or scrap (rejects) due to quality problems also mean a loss for the corporation. This loss may be reduced, if value stream mapping is performed and quality is installed into the product (SIX SIGMA). It is important to develop systems that can indicate failures and automatically stop the process, if necessary. During the course of the IT development, quality may be implemented in the process by performing continuous interaction with the customer or applying automatic testing systems. We build modular systems, and design development in a manner that disassembles it to the smallest operational elements, which are then tested and delivered. The most obvious choice is using a more iterative and agile methodology instead of the waterfall model, which would enable us to produce an adequate quality in a relatively swiftly changing environment as well (Qusef & Lucia, 2010).

Inventory: the costs of maintaining the inventory are apparent in multiple areas. Such incurred costs include the maintenance of buildings, HR, the costs of certain tools and materials, depreciation, and therefore we face a problem that is easy to grasp and calculate from a production point of view. Another disadvantage of accumulating the inventory, is that it hides the operative problems of the organisation. Therefore, in case inventory is reduced, waiting may occur on the production line. In such cases, the tasks is not to reload the inventory, but to investigate and eliminate the root causes of waiting. During system development, inventory can be interpreted the following way: if the specific development activity is ready sooner than it could be received by the customer for testing, we have unused capacities created. During operation, inventory may also be interpreted through the aspects of unnecessary storage space and server accumulation. Today’s modern virtualization techniques can provide an answer to this, and balance the usage peaks of the unbalanced use of the specific services.

Unnecessary motion: all activities including movements that supplement our value-creating activity, shall be considered losses. The loss can be reduced by activity analysis. The lack of the previously mentioned information also leads to such loss, since if the customer has to be visited again, it is also classified as unnecessary motion. This attached loss can be eliminated most easily, if the infrastructure required for development is established at the customer (Poppendieck & Poppendieck, 2003). If it is not possible, then creating certain workgroup pages may reduce the time spent with acquiring information. During operation, the time spent on solving the repeated failure can be classified as this type of loss.

Scrap: in case we produce scrap (rejects), then the whole production process is questionable and almost everything invested in the specific product is lost. Failures and faults may also arise during development from inaccurate specifications, or obviously from simple coding errors as well.

Inappropriate utilisation of HR: if we cannot utilise the skills of our colleagues, we may easily lose new business ideas (Liker, 2008). IT is unimaginable without the appropriate knowledge, and therefore I think that this type of loss may be the most severe to an IT service provider, since this is a knowledge intensive sector, in which the “half-life” of knowledge is 1-1.5 years. I believe that trainings may solve the problem, if the operative staff lets the knowledge gained through them unfold. The availability of HR may for example be best visualised and controlled through a strategic map (Kaplan & Norton, 2005).

In the paragraphs above, I have presented the seven sources of loss identified by Taiichi Ohno, which served as the basis for Toyota’s manufacturing system.

3. Establishing a Pull System

The basic principle of pull systems is that production shall always be generated by demand. By establishing an operable pull system, most of the previously presented problems can be avoided. Pull systems within a plant are realised through KANBAN cards, while in the IT sector they take the shape of closing the order or a testing round. The following figure shows the execution of a pull system IT development work. Figure 1 is based on the works of Bell and Orzen (201).

Figure 1. Development in a pull system
Source: Bell & Orzen, 2010

The above figure clearly shows the development is only commenced if a customer demand is generated, which is assessed by the management, and then it launches the development work.

During the course of operation, the pull system is much harder to interpret. But if we look a bit further, and assemble an infrastructure for which the undertaken SLAs (Service Level Agreements) comply with the values targeted in the BCP (Business Continuity Plan), then the expected pull system is already realised. The prepared BCP may not only contribute to the implementation of the pull system, but it may play an important role in value analysis as well, since clients always want everything as soon as possible, with ~100 % availability, but this can decrease competitiveness, as we form excess reserves.

4. Balancing Production

A corporation that fails to think about LEAN methods as one system and only manufactures strictly according to the customer demands, will soon discover the loss called 3M (Muda, Muri, Mura). The reason is the following: the unexpected nature of customer demands sometimes causes overload, or unused capacities in our systems. This is caused by the “ad hoc” nature of production, which has to be balanced. This practically means than in case of three A and three B products, the production order will be ABABAB, instead of AAABBB (Liker, 2008). Due to changing the product, losses occur at every changeover, which can be reduced by the SMED (Single Minute Exchange of Die), which means a single-digit minute changeover ability. The SMED is a four-step technique which enables reducing the changeover time to less than 10 minutes. (Shingo, 1985)

During the course of IT development continuous production is realised through the development of modular systems and the cycles created for the testing thereof, which also ensures that quality becomes a part of the product and the results will comply with customer demands. During operation the balancing of production is implemented through virtualization technologies. This means that the system is provided with the virtual availability of resources that it does not actually possess, and thus the irregularities caused by usage can be balanced. For example the HR system runs at full capacity during payroll management, so if we find a system that is used at some other time, then the two systems can share the resources.

5. Including Quality in the Process

If we ensure that appropriate quality production can be realised at the first attempt, then we are relieved of a loss identified in one of the previous chapters. In mass production the most important goal is the operation of the lines, while according to the LEAN approach, in case of a failure, the process has to stop and shall be repaired, in order to prevent the failure from occurring again. Practically any employee is authorised to stop the line, when he faces a problem. Switches are placed along the production line, and in case of a problem the employee can use them to indicate the foreman that he faced a problem and requires help (Liker, 2008). These lights are called “andons” and they are means of visual control.

Quality can be included in the product through continuous improvement. In order to enable this, we need analysis techniques like 5W (5 Whys), RCA (Root cause analysis), FMEA (Failure mode and effects analysis), FMECA (Failure mode, effects, and criticality analysis) or FTA (Fault tree analysis).

The different monitoring systems fulfil the role of the previously explained “andon” in IT operation. In these systems, the entire analysed infrastructure is constructed based on the tree structure (in the required depth) and the specific service is located at the root of the tree. The system continuously tests the different branches of the tree, and signals to the operator if any algorithm faces an error, if there is no response, or – if applicable – when the response time is too long. In case of a failure, the specific service part is indicated in a flashy manner on the operator’s screen, and he may decide whether it is necessary to intervene in the process. If the problem can be solved without shutting down, providing a continuous service is practically ensured.

By developing modular systems, not only the workloads between specification-development-testing can be distributed, but we also receive quicker feedback regarding the qualities of the completed elements, enabling faster intervention in the process and reaching the optimal result. The methodology of “fragmented” system development complies with the principle of one-piece material flow. The services of thus created system components provide a foundation of appropriate quality for satisfying further business demands.

6. Standardization

According to Henry Ford, standardization is the basis of development (Liker, 2008). He argued that the optimum of the current stage shall be reached first, and then we shall continue to work to develop it. Standardization is also an important element of the LEAN approach, which is reflected in the 5S (Seiri, Seiton, Seiso, Seiketsu, Shitsuke). The fourth and fifth S can be introduced, if the target results are already reach in the three first areas, i.e. we defined what is required for work, placed them properly and maintain them as well. The fourth and fifth S is about measurement and training.

Standardization in the IT service is primarily reflected in the ITIL or CMML SVC recommendations. This includes how our IT services should be structured in order to be able to provide high level services.

During the course of development, standardization is included in planning and system development approach according to the SOA (Service Oriented Architecture). But what is SOA? It is hard to define. Not because there was no definition, but because there are so many definitions that it is hard to decide which one is appropriate. According to the approach I find the most appropriate, the SOA is a paradigm and planning method approach that should be applied in order to get the description of a business or IT architecture. (Nicolai M., 2007) In the SOA-based philosophy, stand-alone systems cease to exist and we discuss the internal structure of the components. In the SOA maturity model of “The Open Group”, the companies at the top level possess such IT infrastructure that is suitable for dynamic application development, has a reconfigurable architecture, models business processes and its control is based on an appropriate set of rules (The Open Group, 2013).

7. Continuous Learning, Development

Continuous learning is based on looking in the mirror from time to time, and analysing our deficiencies. If we know where our deficiencies lie, we can execute continuous learning, the KAIZEN (Liker, 2008). In the LEAN approach, continuous learning has four levels: the corporate, the management, the operative and the controlling level. According to Licker, development is performed based on the Deming cycle. This relation is presented in the figure below.

Figure 1. Division of the strategic goals of the Corporation
Source: Liker, 2008

In the world of IT, the continuous service development process is implemented by the ITIL (IT Information Library) in a seven-step model, presented in the below figure.

Figure 3. Service development PDCA cycle according to the ITIL
Source: ITIL, ITIL V3 Foundation, 2013

Considering the half-life of knowledge in the IT sector, it is not enough to just think about KAIZEN as a process, but the workers shall also continuously renew, otherwise their knowledge will be rendered useless. Naturally, this is true for every segment, but probably the half-life of knowledge is the most apparent in this sector.

8. Why is it worth LEAN-ifying IT?

Throughout the last few pages I summarised the LEAN tools of production management and IT services, and I tried to prove that the techniques that are able to provide competitive advantage for a corporation in a specific sector, may also bring about success to another company applying them in a different sector. Considering the fact the IT has a supporting role in the economy, the application of the previously listed methods may face problems. If these smaller battles are won, the value of IT can be increased. I think that the hardest job is to provide services as an external service provider.

In order to try to answer how the managers of the company’s suppliers view the opportunities of introducing certain tools and their applicability, the Development Management of MVMI Informatika Zrt. conducted an opinion poll. The answer sheet was returned by 25 top managers and project managers of more than 10 IT service providers.

Table 1 presents the arguments and opinions submitted by managers participating in the survey, which show why it is worth going forward with this hard and conflict-filled process.

Table 1. Managers’ opinions on LEAN-ifying IT

Solution Production management IT services Managers’ opinions What do we gain?
Value analysis Value analysis Analysis of business and implementation processes There is a clear consensus that the contractor shall not only emulate any of the processes, but he shall proactively participate in its analysis as well. In order to complete this process, they need information, but they cannot receive it in the adequate quality and quantity. The complexity of the systems could be decreased, but this would also require flexibility on the customer’s side. During implementing developments we can spare time, which also means cost-savings.

Less complex systems, decreasing operational costs

Eliminating losses JIT KANBAN SMED U-shape manufacturing line SCRUM KANBAN Outsources project team The current contracting customs and options support agreements of a fixed scope, even in rapidly changing environments. On the customer’s side, the application of iterative methods is hindered by planning problems, and therefore it is not preferred. Change-management of the projects is typically performed. Cost-savings Quicker response ability Systems better tailored to the demands More accurate planning and delivery
Establishing a pull system KANBAN Customised software Iterative development techniques Change-management is the most effective from the contractor’s point of view, if iterative development methodology is applied during the introduction, but this does not necessarily involve the more accurate keeping of deadlines. The customer’s side is typically not mature enough to manage iterativeness. It supports the process if partners are already involved at the beginning of the process. There is a clear demand for this. Higher profit Returning client for inclusion in the system
Including quality in the process SIX SIGMA SPC Monitoring systems Modular development, reuse, SOA Different types of monitoring systems are not the privileges of the rich, so their application opens new horizons in the field of proactivity. If possible, the application of standard solutions is preferred to custom development, which also affects competitiveness. Faster systems with less failures A system better fulfilling demands Cost-savings, agility (Bieberstein, Sanjay, Fiammante, Keith, & Shah, 2009)
Continuous improvement, learning KAIZEN ITIL or CMMI SVC recommendations Training costs are proportionate to the expected result. The gained knowledge shall be shared, but its inclusion in the processes of the organisation faces cultural limitations. Innovation Cost-savings Sharing knowledge

During the survey we applied the 6-level Likert scale, and we ignored the answers with a variation exceeding the value of 1.5 or those that did not lean to any direction on the scale. The composition of the research sample is shown in the below figures.


Figure 4. Profile of managers participating in the research

9. Summary

In the above paper I have briefly presented the applicability of LEAN tools – which are widely used in production management – in the field of IT services, highlighting the specific field of development. The undertaken research clearly shows that our main suppliers would increase iterativeness during their operation, but it is sometimes hindered by certain limitations.

Our own experience also supports the above statement. As a service provider, we would also require more flexibility and iterativeness in our development processes, however as a customer it is hard to accept. Obviously, we also understand that during the application of the waterfall model, it is quite a challenge to manage risks, observe budget limitations and to deliver quality products (Nabil Mohammed Ali & A., 2010), yet the change is still to come. In our opinion, the most reliable results during the introduction of a system can be introduced, if the minimum contents of allowing the live start of the system with a fixed scope are successfully defined, and further demands are included later, based on a more flexible approach, through continuous development. The application of virtualization techniques and monitoring systems is widely popular, but the advantages of the SOA are yet to be seen. In this field, the biggest challenge is having to teach participants not to think in IT systems, but in corporate, business and IT architectures.

  1. Bell, S. C., and Orzen, M. A., 2010. Lean IT: Enabling and Sustaining Your Lean Transformation. New York: Productivity Press.
  2. Bieberstein, N., Sanjay, B., Fiammante, M., Keith, J., and Shah, R., 2009. Szolgáltatásorientált Architektúra. Budapest: Panem Könyvkiadó Kft.
  3. Carr, N., 2003. IT Doesn’t Matter. Harward Buisness Review.
  4. Ho Ha , S., and Chan Park , S., 2006. Service Quality Improvement through Business Process Management based on Data Mining. SIGKDD Explorations , 8(1), pp.49-56. Available online: http://www.kdd.org/newsletter/explorations-june-2006-8-1 [Accessed 19 February 2015]
  5. ITIL., 2013. ITIL alapszintű oktatás. Sarkadi-Nagy István, Paks.
  6. ITIL., 2013. ITIL V3 Foundation. Sarkadi-Nagy István, Paks.
  7. Kaplan, R., and Norton, D., 2005. Stratégiai térképek. Budapest: Panem Kft.
  8. Liker, J. K., 2008. A Toyota Módszer: 14 Vállalatirányítási alapelv. Budapest: HVG Kiadó Zrt.
  9. Martin, K., and Osterling, M., 2013. Walue Stream Mapping. Mc Graw Hill.
  10. Nabil Mohammed A.M. and Govardhan, A., 2010. A Comparison Between Five Models Of Software Engineering. International Journal of Computer Science Issues , 7(5), pp.94-101.
  11. Nicolai M., J., 2007. SOA in Practice: The Art of Distributed System Design. Sebastopol: O’Reilly Media Inc.
  12. Ohno, T., 1988. Toyota Production System – Beyond Large-Scale Production. Portland: Productivity Inc.
  13. Poppendieck, M., and Poppendieck, T., 2003. Lean Software Development – An Agile Toolkit. Crawfordswille: Addison-Wesley.
  14. Qusef , A., and Lucia, A. D., 2010. Requirements Engineering in Agile Software Development. Journal of Emerging Technologies in Web Intelligence, 2(3), pp.212-220.
  15. Rother, M., and Shook, J., 1999. Learning to See: Value Stream Mapping to Add Value and Eliminate MUDA. Cambridge: Lean Enterprise Institute Inc.
  16. Shingo, S., 1985. A Revolution in Manufacturing: The SMED System. Cambridge: Productivity Press.
  17. The Open Group, 2013. Retrieved from OSIMM Version 2 Technical Standard. Available online:  http://www.opengroup.org/soa/source-book/osimmv2/model.htm#fig1 [Accessed 19 February 2015]
  18. Wikipedia., 2013.  Lean IT. Available online: http://en.wikipedia.org/wiki/Lean_IT [Accessed online 06 June 2013]
  19. Womack, J. P., and Jones, D. T., 2009. Lean szemlélet. Budapest: HVG Kiadó Zrt.

Article Rights and License
© 2015 The Author. Published by Sprint Investify. ISSN 2359-7712. This article is licensed under a Creative Commons Attribution 4.0 International License. Creative Commons License
Corresponding Author
Zoltan Vajna, MVMI Informatics Ltd., Hungary
Download PDF


Zoltan VAJNA
MVMI Informatics Ltd., Hungary