Problem management foundation - Continious improvement

Editor's Notes

• #2: Continuous improvement
• #3: Learnings from TPS Training and certification Assessments
• #4: Continuous improvement through Professional data centre training and certification
• #5: Deming wheel: Made popular by Dr W. Edwards Deming, based on work by Shewhart. Concepts originate from scientific method and the works of Bacon. Plan to improve service management by determining what is going wrong (that is identify the problems), and then suggest resolutions. Do changes designed to solve the problems on a small and incremental scale first. This minimises disruption to Live while testing whether the changes are workable.
• #6: Check whether the small and incremental changes are achieving the desired result. Also, continuously monitor nominated key activities to ensure that you know what the quality of the output is at all times to identify any new problems when they crop up. Act to implement changes on a larger scale if the small changes are successful. This means scheduling the changes a part of the standard maintenance and administrative tasks. Also Act to involve resources (people, partners, products and process) affected by the changes and obtain buy-in to implement them successfully. Be sure to share the knowledge learned.
• #7: Kaizen is the practice of continuous improvement. Kaizen was originally a Japanese concept introduced into the west by Masaaki Imai in his book Kaizen: The Key to Japan’s Competitive Success in 1986. Kaizen is continuous improvement that is based on certain guiding principles: Good processes bring good results Go see for yourself to grasp the current situation Speak with data, manage by facts Take action to contain and correct root causes of problems Work as a team Kaizen is all inclusive of everyone
• #8: hansei is a philosophy of problem solving that emphasizes thorough understanding of consensus-based solutions that are swiftly implemented. In the hansei process, the emphasis is on what went wrong and on creating clear plans for ensuring that it does not reoccur; this is done constantly and consistently. At Toyota, even if you do a project successfully, there is still a hansei-kai (reflection meeting) to review what went wrong. If a manager or engineer claims that there were not any problems with the project, they will be reminded that “no problem is a problem” – in other words, you have not objectively and critically evaluated the project tofind opportunities for improvement. No problemsindicate that you did not stretch to meet (or exceed) your expected capacity.
• #9: TPS Refer https://en.wikipedia.org/wiki/Toyota_Production_System
• #10: It is possible to set targets for reducing the impact of major incidents using the Pareto principle, also known as the 80-20 rule. The principle states that with just 20% effort, correctly applied, you can achieve 80% of the desired effect. Vilfredo Pareto made several important contributions in the study of income distribution and in the analysis of individuals' choices. His concepts helped develop the field of microeconomics and the Pareto Principle has become gospel. The 80-20 rule developed when Pareto noted that 80% of income in Italy went to 20% of the population. The above principle is relevant to Information Technology (IT) as it is an important tool to use when prioritizing effort, as effort applied correctly can achieve a far higher proportionate effect. The relevance to of Pareto as applied to major incidents, is that the principle can be applied to resource optimization by observing that optimally 80% of the resources are typically used by 20% of the operations. Thus we need to prioritize our effort to work on an identified 20% of possible causes. These possible causes are often based upon lessons learnt which is dealt with in a separate article. When it is applied to outages and incidents it means that 80% of major incidents are as a result of 20% of the causes. Knowledge of the identified 20% of these causes, will then result in a substantial reduction in major incidents! As an example, when troubleshooting a network problem using a checklist, the first checks should be those that are identified by lessons learnt as the ones that occur most often, such as Ethernet duplex/speed mismatches or power related issues. As an example with the later, the implementation of secondary power sources at customer premises can potential eliminate some major incidents from even happening. Pareto’s observations have been around since the early 1900’s and applied practically it would mean that if you had 87 major incidents per month, it would be possible to reduce these to 18 major incidents per month if the correct identifiable 20% of causes were addressed. This allows these incidents to be reduced to a negligible and manageable level. Although these 20% of causes account for 80% of the major incidents, when setting a target you can only reduce it proportionally so the ultimate goal can only be achieved incrementally over time. It might be argued that the setting of targets needs to be researched in more detail, but Pareto's observations have been proved so many times that it is close to gospel. I'll provide an example, and it often makes me see red about vendors or service providers. Many service providers are not transparent. If they have a major issue with their services then they clam up about it. You can be the tenth customer that day where the problem has occurred, with an exact duplicate of an issue, and they'll pretend they have never heard of it before. Network Operations Centre Managers (NOC) seem to be hired with their primary skill being plausible deniability, often referred to as being Teflon coated.   Typically we have all encountered this issue. Even though it would be possible to research suggested resolutions in the vendor's knowledge base, the support structures are focused on limiting marketing damage and not resolving problems. After the fact a marketing disaster occurs where the service provider deals with having to acknowledge an outage. They are on the back foot apologizing for an outage, and not explaining how efficiently and effectively they are dealing with an outage. Now why don't service providers publish these limited set of causes in a dashboard on their support sites in real time? This by itself would so dramatically improve efficiencies that in no time most would be running optimally. The reluctance by service providers who are falsely influenced by marketers to be less than transparent is problematic. A detailed analysis of outages and proactive measures display technical competence and is in itself a great tool to showcase the service provider’s proficiency!
• #11: Escalation and grading When working on problems there needs to be a communications channel to which escalations of the status and resolution occurs. It is beneficial if this communications is handled separately by resources who aren't directly involved in resolving the problem as it will make more optimal utilization of resources. Just as important, once the problem is resolved the resources involved in the problem need to be reviewed and graded. Without this you will not assign resources optimally to problem solving such as assigning your best resources to a Tiger Team or recommending those with insufficient skills for Kepner-Tregoe training. Refer to the Appendix for the tool, Rating of resources involved in a Major Incident
• #12: Video refer https://lnkd.in/exAG9dP
• #13: Review