Your SlideShare is downloading. ×
0
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
My view on Lean IT
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

My view on Lean IT

2,604

Published on

These slides I used for internal seminar describing Lean IT

These slides I used for internal seminar describing Lean IT

Published in: Technology, Business
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,604
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
181
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Scientists distinguish three kinds of activity:Repeatable activity targeted to achieve a results of consistent characteristics and quality is called “Production”One time activity targeted to achieve a unique result is called “Project”An activity which goal is the activity itself is called“Game”IT is a mixture of “Production” and “Project” activities and value-adding activities in IT are usually in projects. They cannot be optimised usingjust Traditional Lean Six Sigma methods because they designed to handle thousands or millions of similar delivery cycles, and not few unique projects.In addition to famous Toyota Production System, they used Product Development System to run projects. This methodology is now evolved in Lean Product Development
  • You cannot approve and fix content of A3
  • Transcript

    • 1. Organization Name | Group NameLean IT:Separates Added Value from WasteEvgeny Nedelko, April 2012
    • 2. Lean IT: Separates Added Value from Waste Lean IT provides a clear connection between Value All widely recognized for end customer  and day IT frameworks (ITIL, RUP, Agile, CMM to day work and it is I, ADM) say HOW to designed to handle deliver IT projects, but don’t say WHY uncertainty of individual The goal of any projects organization is to bring more value for its customers Lean IT is based on 13 at less costs Lean Six Sigma says principles of Toyota Product WHY, but most of its Development system and tools are not applicable for project bounds together Lean Six activities, which are Sigma tools with traditional highly variable in their nature Agile development and Service delivery (ITIL) methodologies Copyright © 2011-2012 Accenture All rights reserved. 2
    • 3. What is Lean Six Sigma? Lean Six Sigma Focus on capabilities of Statistically proven the people in the process capability process Definition of strategic areas for continuous improvement of business operations Common principles and scientific foundation A toolset and methodology for individual process improvements Joseph M. Juran W. Edwards Deming Copyright © 2011-2012 Accenture All rights reserved. 3
    • 4. History of Lean IT- 1890’s Frederick W. Taylor – Scientific Management— 1910’s Henry Ford and Charles Sorensen – Ford System (Mass Production)- 1920’s Walter Shewhart (Bell Laboratories)– Statistical Process Control- 1950’s W. Edwards Deming teaches Statistics in Japan- 1950’s Joseph M. Juran teaches Management in Japan- 1948-75 Taichii Ohno and Shigeo Shingo – Toyota Production System– 1984 Eliyahu M. Goldratt – Theory of Constraints- 1986 W. Edwards Deming – Total Quality Management- 1987 Mikel Harry (Motorola) – Six Sigma- 1991 James P. Womack, Daniel T. Jones, Daniel Roos- – Lean Production— 2003 Mary and Tom Poppendieck – Lean Software Development- 2011 Steve Bell and Mike Orzen – Lean IT
    • 5. Agenda· Recognise the Customer Value · Build the Culture of Learning · Just-in-Time Delivery · Other Tools – Appendix: Thirteen LPD Principles Copyright © 2011-2012 Accenture All rights reserved. 5
    • 6. Recognise the Customer Value
    • 7. Two kinds of IT ServicesEnterprise Systems: Infrastructure and Telecoms:• Have a purpose to improve business • Required to support current business operations operations without clear business value• Usually are delivered and maintained by • If there is no infrastructure – there are IT department no business operations• Product specification is driven by • Procured with minimal customisation business users from a vendor• Customised to company needs or • Product specification is driven by custom built by request Vendor’s marketing or product development department The main focus of this presentation Copyright © 2011-2012 Accenture All rights reserved. 7
    • 8. “Step 0” – Identify Your CustomerPurpose of Lean – To maximise value for customer while minimising thecosts, thus the cornerstone of Lean is Customer In IT there is a hierarchy of customers with their own needs – Other IT Units – Business Users – End Customers of the company Example Voice of Customer*: – End customers want a stable quality service provided by the company, with no interruptions during business hours – Business users need a stable system, that would not require a support from IT and all potential problems foreseen and prevented. – Many users want to be able to solve simple incidents by themselves with guidance of FAQ and Knowledge base, and look for a friendly guidance from Service Desk on more complex issues – They want their issues to be solved after first call at clear timeframe, without need to push or spend their own time on technical decisions – “Don’t get me to help you, I want you to help me!” *Adapted from Lean IT (Mike Orzen, Steve Bell), Lean Solutions (Jim Womack and Don Jones) and Sense and Response (Stephen Parry) Copyright © 2011-2012 Accenture All rights reserved. 8
    • 9. Costs and Benefits of an Enterprise System Below are the typical costs and benefits for an business IT system Original Estimation Propagated Errors Benefits Actual of Benefits Business Benefits Demand Improvement Specify Functional Gaps, Defects need Gaps, Defects Incident RequestBusiness Request Release Technical Debt Release around Work Fix IT Implement Implement Diagnose Solution Solution Solve problem Preventive Maintenance Cost reduction Legend Benefits / Value Costs / Waste Copyright © 2011-2012 Accenture All rights reserved. 9
    • 10. Examples of BenefitsThere are direct benefits: and indirect benefits:• automation of work reduces need • appealing user interface expands for manual operation the customer loyalty• improving quality of manufacturing • better control of risks reduces process reduces scrape and use of potential loss and reputation materials • better information management• better control of finances reduces improves quality of overall write-offs and other loss management in organisation The result of process automation should not be staff reduction, but more time to think how to serve clients better Copyright © 2011-2012 Accenture All rights reserved. 10
    • 11. Examples of CostsIn most of the cases the cost of system implementation can be reduced,but an impact on operational (running) costs is inevitableTechnical debt is costs that are imposed by the systemThese could be direct costs: and indirect costs:• business outage due to system • impact on reputation unavailability • operational risks• loss due to incorrect system • human errors that could be behaviour prevented by software• extra costs required for system • training costs required for new users modification due to complicated design• cost of regression testing Copyright © 2011-2012 Accenture All rights reserved. 11
    • 12. Build the Culture of Learning
    • 13. Relentless Learning and Improvement System implementation projects are unique in their nature. Even when you have a plan, you cannot say whether you run it in the most efficient way before you try. That is why it is so important to build learning cycles into your delivery.Make sure you not only “Plan what you do Planand Do what you plan” Act DoYou should also Check the resultsand Act accordingly Check To err is human, but not to learn from mistakes is a crime Vivek Nayer Copyright © 2011-2012 Accenture All rights reserved. 13
    • 14. Front-load the Development ProcessThe main waste in any process is rework – developing systemthat needs to be corrected due to error or design flaw• To prevent this - all alternatives should be identified as soon as possible to allow enough time for evaluation of options and to identify possible constraints before completing dependent tasks• Work on alternatives – as SOON as possible• Make a choice – as LATE as possible Copyright © 2011-2012 Accenture All rights reserved. 14
    • 15. Short IterationsIn quickly developing organisation requirements and priorities change quicklydue to changing market conditions and learning process and betterunderstanding overtime• 30% of change requests lose their priority and 10% can get new requirements after one quarter– This means that 25-65% of original system features become irrelevant for client after one year of implementation– This is probably one of the main reason why so many long term projects fail to deliver satisfactory results• Therefore it’s important to present the system to client as often as it is possible and to adjust plans according to the feedback Copyright © 2011-2012 Accenture All rights reserved. 15
    • 16. Standardise Work Items and Steps • Always plan a projectIt is impossible to distinguish waste • Define a workflow for user requestsfrom value in the process before you • There are standard steps even for casual tasks (define what needs to beidentify the sequence of steps done, assign the responsible, do the task, validate theperformed to achieve expected results result) • In Agile development, ProjectWhen you split your project delivery iterations (sprints) take 1 or 2 weeksinto a set of similar steps it becomes permitting to collect lessons learned often enough to identify issues longpossible to compare results of before they become a real problem • In Scrum, daily meetings permit toindividual iterations and identify reduce learning cycle to one dayrepeatable problems Copyright © 2011-2012 Accenture All rights reserved. 16
    • 17. Knowledge Management Tools– Supplier technology demonstrations– Competitor teardown analysis– Checklists and quality matrices– Learning focused problem solving– Know-how database– Lessons learned events (Hansei)– Program manager conferences– Business Revolution Teams– On the job trainings skill matrix, learning focused career paths– Resident Engineers (RE)Adapted from The Toyota Product Development System, (James M. Morgan and Jeffrey K. Liker) Copyright © 2011-2012 Accenture All rights reserved. 17
    • 18. Just-in-Time Delivery
    • 19. Kanban Whatever planning technique is used to forecast workload of functional groups in the project, there are inevitable variation causing delays, when one group waits for output from another, and when a group has not enough capacity to handle all incoming tasksKanban (看板), is the concept of Just-In-Time production, when centralizedend-to-end planning is replaced with individual tasks flowing through theprocess, and controlled centrally Project Manager / Chief Engineer Customers Group Support pull Designers pull Developers pull Testers pull Engineers Pulling knowledge through the process flow Copyright © 2011-2012 Accenture All rights reserved. 19
    • 20. Alignment through Visual CommunicationVisual communication is much more effective than verbalcommunication, even though it takes more efforts• Visual boards are used– To define and demonstrate tasks and their priorities– To present current results (plan/fact)– To promote overall goals– To provide feedback to team members Copyright © 2011-2012 Accenture All rights reserved. 20
    • 21. Leveled Process FlowWhen you have your process flow defined you can see the bottlenecksand remove them (i.e. level the process) Uneven load on functional groups can be identified and then mitigated by a bench of temporary resources (contractors) preselected, but not hired until actual need for extra people Copyright © 2011-2012 Accenture All rights reserved. 21
    • 22. Integrate Suppliers into the Quality System If you take look on the end-to-end value stream for IT you see that it starts from suppliers and finishes at the end customer of the companyTo remove waste from the flow you need to start from the wastedelivered by supplier, which means that you cannot improve yourprocess excluding suppliers from scope Value Value Value Business End Suppliers Waste IT Waste Waste Departments Customer Copyright © 2011-2012 Accenture All rights reserved. 22
    • 23. Organisational Matrix Analysis Lead Development Lead Testing Lead Support Lead Project Manager / Chief Engineer Customers Group Designers Developers Testers Support Engineers Project Manager / Chief Engineer Customers Group Designers Developers Testers Support Engineers Project Manager / Chief Engineer Customers Group Designers Developers Testers Support EngineersWhile functional teams balance resources, take care of their people and best results foreach process step, the Project manager as a Customer’s advocate pulls all requestedchanges through the process flowThis matrix create two career paths – for Experts in functional teams and Managers serving customer groups Copyright © 2011-2012 Accenture All rights reserved. 23
    • 24. Organise to Balance the Matrix One of the most typical problem in IT organisations is silo thinking. There are Developers who don’t care of User support, there are User support who ignore Business Analysts, Testers don’t talk to Analysts. Similarly the CRM implementation project doesn’t take care of the ERP implementation project, and IT Security don’t care of anyone at all Lean IT says that IT management should constantly balance the project management matrix …there should be people responsible for alignment of individual projects and… …there should be people responsible for alignment of end-to- end delivery flow Copyright © 2011-2012 Accenture All rights reserved. 24
    • 25. Other Lean Tools
    • 26. Other Lean Tools• Flow chart• Projects Prioritisation• Cause & Effect "Fishbone" Diagram, 5-Why Analysis• Set-Based concurrent Engineering• Decision Analysis and Resolution Copyright © 2011-2012 Accenture All rights reserved. 26
    • 27. A3 ThinkingA3 Report is a Project Charter covering the following topics: Principles of the A3 system: Objectivity• Problem side (left half of a page): Distillation and visualization– Background Results and Process– Voice of Customer Alignment– Current State (metrics, VSM)– Root Cause Analysis A3 Reports cannot be drafted in isolation by a person working alone in their room• Solution side (right half of a page):– Project Team It’s essential that the A3 Report– Action Plan should be updated throughout the– Project Targets vs. Actuals project life as long as– Effect Confirmation / Value Delivered understanding of the facts changes Copyright © 2011-2012 Accenture All rights reserved. 27
    • 28. Poka-YokePoka-yoke (ポカヨケ) is a Japanese term that means "mistake-proofing". Its purpose is to eliminate product defects bypreventing, correcting, or drawing attention to human errors as theyoccur– Checklists– Standard, detailed test plans– Part quality matrices– Architecture patterns– Reusable components– Standardized execution processes– Test driven development Copyright © 2011-2012 Accenture All rights reserved. 28
    • 29. Adapt Technology to the Problem, not the opposite“The biggest epidemic in IT is that we routinely pick solutions that are bigger & more complex than our problems.” Torbjörn Gyllebring– Technologies must be seamlessly integrated– Technologies should support the process, not drive it– Technologies should enhance people, not replace them– Specific solution oriented: not a silver bullet– Right size – not king sized Copyright © 2011-2012 Accenture All rights reserved. 29
    • 30. Appendix: Thirteen LPD PrinciplesLean Product Development is driven by thirteen principles originating from Toyota PDS1. Establish customer-defined value to integration. separate value-added from waste. 7. Develop towering competence in all2. Front-load the product development engineers. process to explore thoroughly alternative 8. Fully integrate suppliers into the solutions while there is maximum design product development system. space. 9. Build in learning and continuous3. Create a level product development improvement. process flow. 10. Build a culture to support excellence and4. Utilize rigorous standardization to relentless improvement. reduce variation, and create flexibility 11. Adapt technologies to fit your people and predictable outcomes. and process.5. Develop a chief engineer system to 12. Align your organization through simple integrate development from start to visual communication. finish. 13. Use powerful tools for standardization6. Organise to balance functional and organizational learning. expertise and cross-functional As per James M. Morgan and Jeffrey K. Liker, authors of The Toyota Product Development System, Integrating People, Process and Technology (2006, Productivity Press)
    • 31. Learn moreLean Six Sigma CBT training on myLearning• https://mylearning.accenture.com/accenture/lang- en/management/LMS_ActDetails.asp?ActId=546942“Lean IT: Enabling and Sustaining Your Lean Transformation”by Steve Bell, and Mike Orzen (available online)• http://skillport.books24x7.com/toc.aspx?bkid=36963“Sense and Respond: The Journey to Customer Purpose”by Stephen Parry, Sue Barlow, and Mike Faulkner• http://www.amazon.co.uk/dp/140394573X Copyright © 2011-2012 Accenture All rights reserved. 31
    • 32. Your questions?

    ×