Aarti T

Feature TOC Lean Focus Constraint: Identifying and maximizing the output of the single bottleneck in the system. Maximizing value for customers while minimizing waste: Eliminating any activity that doesn't directly add value to the customer. Approach Targeted: Focuses on specific interventions to improve the constraint. Holistic: Aims to continuously improve the entire system by eliminating waste. Popular Methods: 5 Focusing Steps: 1) Identify the Constraint 2) Exploit Constraint 3) Subordinating Everything Else to the Constraint 4) Elevate the Constraint 5) Avoid inertia by going back to Kaizen Kanban boards Value Stream Mapping (VSM) 5S Just-in-Time (JIT) Mindset Breakthrough: Aims for dramatic improvements by removing the constraint. Incremental: Focuses on small, continuous improvements over time. Suitable for Situations with a clear bottleneck: Manufacturing, project management. Environments with pervasive waste: Any industry, service sector. Benefits Rapid improvement, increased throughput, ROI focus. Reduced costs, improved efficiency, customer satisfaction, continuous improvement culture. E-commerce example For e-commerce retailers, fulfillment of orders is a major factor in customer satisfaction. However, distribution centers are usually far away from densely populated cities because they require a lot of warehouse space that is not available in cities, also cities offer congested circulation for large trucks and shipment fleets. Close proximity to warehouse space is a bottleneck to distribution and fast delivery. A solution to this constraint is the set up of micro-fulfillment centers (MFC) in cities and even in stores. Expanding the e-commerce example, let us consider a warehouse where waste exists in the product-picking process. Picker are spending a lot of time and effort moving around the warehouse to find items. By optimizing the warehouse layout, products can be stored by order frequency (the MFC is usually optimized with these products too). Using Kanban and 5S, the warehouse can be divided into zones, and pickers be assigned to each zone to improve their efficiency. Picking lists can be improved with hand-held technology as well.

The Risk Register and FMEA (Failure Mode and Effects Analysis) are both risk management tools for different purposes. Risk Register The risk register takes a holistic or broader view, listing each risk, its potential impact, and mitigation strategies. Advantages of Risk Register: It helps to identify and document a wide range of risks. This documentation is often saved as a project artifact during project or organization reviews. Communication of risks: It allows all stakeholders to have the same understanding of the risk, thus reducing subjectivity. Living document: Risks are constantly tracked and adjusted as the drivers change or evolve. Disadvantages of Risk Register: Prioritization is challenging: Because of the broad nature of the tool, it does not provide information on specific issues. This can make it difficult to focus on the critical Xs. It takes a qualitative approach that provides inadequate information for detailed analysis. Maintaining the risk register: If there are many risks to track, it can be challenging to keep the document current. Use Cases of Risk Register: Project management: Monitoring risks and keeping projects on track. Business continuity planning: Preparing for a variety of potential disruptions e.g. cyclones in areas where this is likelihood. Regulatory compliance: Ensure that all necessary compliance meets the requirements e.g. GDPR compliance. FMEA This dives deeper into issues in the process to identify specific system, product, or process failures. It dissects failure modes, their consequences, and the likelihood of their occurrence, calculating a risk priority number (RPN). Advantages of FMEA: Quantification of risks: A risk priority number (RPN) score helps prioritize the most critical failures for mitigation. Mitigation planning: Targeted solutions can be tailored to address specific failure modes and root causes. Prevention-oriented: Proactive approach to minimizing failure impact. Disadvantages of FMEA: Narrow scope: Limited to specific systems and may miss broader risks, especially those outside the process or outside the team's knowledge. Resource-intensive: Requires detailed knowledge of how to use the tool and effort to complete. Complexity: FMEA can produce a lot of information for the team to sift through and it can be difficult to assign “mutually exclusive” causes in the exercise because systems can be affected by multiple factors simultaneously. Use Cases for FMEA: Service improvement: Identifying and mitigating potential service failures e.g. long call times resulting in customers leaving a service. Complex systems: Ensuring safety and reliability in aerospace or medical equipment. Design FMEAs are a powerful tool in anticipating potential failure modes at the design stage. Conclusion: One can consider using both tools i.e. use a risk register to find broadly understood risks and then apply FMEA to do a more targeted analysis.

Organizations have long understood the value of comparing themselves to industry leaders through benchmarking. This practice allows them to assess their position and identify areas of opportunity. While traditional benchmarking looks at products and performance, process benchmarking takes a more detailed approach by examining the internal processes that drive success. For example, imagine examining your procurement process and comparing its efficiency and effectiveness with those of other performing companies. Process benchmarking helps uncover comparable metrics e.g. in cycle times, cost structures, or even policies. This analysis not only reveals gaps but also helps in identifying impactful projects that can propel an organization toward its goals of business excellence. Now lets delve into how process benchmarking aids in project identification: Identifying Processes with Gaps: Benchmarking serves as a tool that highlights performance differences between your processes and those of industry leaders. These gaps/opportunities for improvement prompt projects aimed at addressing inefficiencies and achieving gains. For instance, if it is discovered that your procurement process is falling behind competitors, it could spark a project to streamline it, potentially saving resources and strengthening supplier relationships. Prioritizing Projects: The data obtained from benchmarking goes beyond being informative – it becomes strategic, in nature. When comparing the advantages of improvement projects (e.g. savings, efficiencies and customer satisfaction) with the necessary resources you can prioritize initiatives that bring the most significant value. Establishing Goals and Objectives: Benchmarking data provides a foundation for setting attainable project goals. By studying how industry leaders define success in processes you can establish targets for key performance indicators (KPIs) and align your project objectives with the pursuit of excellence and what is realistically achievable. Promoting Innovation and Best Practices: Examining benchmarked processes goes beyond identifying problems; it also involves discovering solutions. Analyzing how industry leaders tackle challenges exposes you to innovative approaches, tools and techniques. You can directly incorporate this knowledge into your projects to inspire creativity and drive improvement initiatives. Cross-industry examples also hold great potential when looking at process methods. Developing a Solid Business Case for Excellence: Securing buy-in and resources for improvement projects can sometimes be challenging. Again, benchmarking data comes to the rescue. By demonstrating the benefits of proposed projects and their alignment with strategy/best practices, you can build a compelling argument for allocating resources and gaining support to bring your improvement initiatives to fruition. Benchmarking processes is not a fix that happens once; it is a journey of continuous improvement, for your organization. When you systematically compare your processes to industry peers you can strategically identify areas that need improvement, define projects, stay competitive, and drive your organization towards achieving business excellence.

Honestly, I've seen both ends of good and bad deployment of LSS. Culture is what makes or breaks it! If Leadership understands the impact, they empower LSS skills & projects. It's tough for the deployment to be effective when Leaders do not support the methodology. Reasons for failure: Leadership lacks awareness of the potential of LSS and when to use it. Lean deployment leaders set unreasonable expectations or do not understand how to build a strong foundation for LSS in the organization. Process maturity also affects the effectiveness of LSS. Low maturity should aim for lean & standard work, while high maturity can aim for LSS.

Lean deployment needs strong leadership champions. If this is already in place, a lean deployment can begin, but be careful to have and set realistic expectations. Don't start all at once across the organization; start with the most enthusiastic champions/processes and build a strong LSS team. Many operational leads are good LSS candidates because they seek ways to improve their processes, and lean is a powerful way for them! Train them! Vet which projects could use LSS. Also, vet who the LSS project managers will be and mentor them as an MBB. Build a proof of concept using these initially. Scale the deployment once you have a good combination of skills across teams and champions in the culture.

A little more context would be helpful. Have you considered the mean time to resolve as a metric? This way, you can compare productivity levels. Practically, though, all the time the agent spends attempting to resolve a complaint is productive time for them so available time vs time on calls can be compared. But you may have varying skill levels and complexity in issues. Over a period of time, your best agents would have a lower mean time to resolve complaints.

I'd suggest mapping the process activities first. Then analyzing value-added and non-value-added activities and time studies for these activities. Value stream mapping also comes to mind.

In project and process management, navigating potential risks is critical for successful implementation. The risk register is a powerful tool that empowers project managers to identify, assess, and manage risks before these derail project efforts. Adding or removing a risk item from the risk register requires careful consideration. Here are some critical criteria: Adding a Risk: Likelihood: Is it likely to happen? Even low-probability risks can be significant if their impact is high. Impact: Would the consequences be severe? Consider financial, reputational, or operational effects. Uncertainty: Is there enough information to understand the risk and its potential impact? Monitor it before adding if unsure. Controllability: Can you mitigate it? If not, it might be an unavoidable circumstance. Project Alignment: Does it directly affect project goals? If not, its relevance might be limited. Removing a Risk: Reduced Likelihood: Has the probability significantly decreased due to changes? Reduced Impact: Have mitigation efforts or developments lessened the potential consequences? Irrelevance: Has it become irrelevant to project goals or the context? Duplication: Does another entry cover the same information? Avoid redundancy. Mitigated to Insignificance: Have mitigation strategies effectively reduced the risk to a negligible level? If yes, then remove the risk. Beyond Projects - Risk Registers for Process Management: The benefits of a risk register extend far beyond project management. It can be a valuable tool for process management as well. Here's how: Identify Process Risks: Brainstorm potential threats, map the process to pinpoint vulnerable areas, and analyze historical data for recurring issues. Even lessons learned can identify potential risks to manage in processes. Assess Risks: Assign likelihood and impact scores, calculate a risk score to prioritize, and develop mitigation strategies like prevention, containment, or transference. Track and Manage: Assign risk owners, track progress, and regularly review the register to update mitigation efforts and communicate risks to stakeholders. Example: Consider a risk register for a software development process. A potential risk might be "system downtime during deployment leading to revenue loss." The likelihood could be medium, and the impact high. Mitigation strategies include thorough testing, backups, and a rollback plan. This risk would be monitored closely and removed once the deployment is completed. By applying these criteria and utilizing risk registers effectively, one can navigate project risks and optimize processes, ensuring smoother workflows and fewer disruptions, with more success. A proactive approach to risk management is key to unlocking the full potential of projects and processes.

Traditional risk assessment can be reactive, especially if problems are identified only after they arise. Project Premortem is a proactive technique that forces project managers to simulate a failed project and dissect why, uncovering hidden vulnerabilities that might otherwise go unnoticed. Benefits: Improved Risk Awareness: Teams better understand threats and their impact by playing out potential failures. Better Decisions: Premortem insights inform better project planning and proactive risk mitigation. Stronger Collaboration: The shared experience fosters trust and communication, leading to a more united team. The team may also identify which other SME’s or other teams that are needed for a successful project. Reduced Risk of Failure: Identifying and addressing risks early helps projects stay on track and achieve goals. Example: When teams consider rolling out new products to new markets, holding a pre-mortem with a diverse team can help identify key threats and risks in the landscape that must be overcome. Tesco's entry into the USA with Fresh & Easy stores might have benefitted from a detailed post-mortem with a diverse team of both UK as well as USA-based retail experts and consumers. These stores were unsuccessful for many reasons ranging from store formats to store placement along highways. [Reference article] Limitations: False Positives: Identifying non-existent risks can lead to wasted time and resources. Limited Scope: Premortems can only identify risks known to the team at the outset. Groupthink: Lack of diversity or a dominant team member can lead to overlooking crucial risks. Time Commitment: Conducting a thorough premortem requires time and effort. Psychological Safety: Team members might hesitate to share concerns due to fear of blame or judgment. Despite its limitations, Project Premortem offers a powerful way to assess risks and improve project outcomes proactively. Encouraging teams to think critically and anticipate challenges empowers them to develop effective mitigation strategies and increase their chances of success.

In the 80/20 Pareto concept, only a small portion (20%) of causes are responsible, for a portion (80%) of effects. To gain an understanding of these causes we can use a tool called the Pareto chart. When working on improvement projects following this rule helps us prioritize issues that have the most impact on the outcome i.e looking for the critical Xs. Pareto charts prove useful when identifying issues from a list in an FMEA (Failure Mode and Effects Analysis). It's important to note that for effectiveness we should ensure that these issues don't overlap and that our sample size is adequately large. However, it's essential to acknowledge that the 80/20 rule is a theoretical concept. It may oversimplify business situations and does not apply universally in all contexts. There are instances where this principle may not be applicable as a tool; Projects with more than 20% of important issues Issues with varying levels of importance where not all issues carry the same weightage. Different outcomes are possible ie. effort and impact may differ across issues. Because of the limitation of any one tool, when it comes to improvement projects, it's recommended to assess the best approach to prioritization and not rely solely on the 80/20 rule.

Hi Puneet, I wish I had more context on what you are trying to solve but I agree with Mayank on data collection planning and the matrix. In addition, I thought about structuring an FMEA exercise to get RPNs to prioritize, or you could take an SME group through an NGT session.

Process improvements do not lead to changes in specification boundaries because these boundaries are fixed and determined by the requirements of customers. However, when employing a Quality Function Deployment (QFD) model, business improvements necessitate process owners to assess how the new attributes of the product or service align with customer requirements, particularly if process improvements result in a shift in the mean of process data (e.g. call resolution times) or when measurement systems are changed (e.g. during localization processes involving unit changes). As a result, if process improvements impact product or service attributes like the mean or units of measurement, then it may be necessary for process owners to review and update the specification limits within the QFD model.

Hi Dheeraj, Leadership is responsible for culture and strategy for problem-solving. I would look for projects under champions who are open to your suggestions to bring visibility to the potential of cross-functional / technology solutions. If you get a few wins, then may be you can shift the way other leaders approach the projects too. Within LSS, for example in DMAIC, I would suggest asking for SME's from the needed verticals (e.g. RPA specialists) to become part of the project by the time you reach the "Define Phase Gate". This will be part of your stakeholder analysis as you scope your project. If these SME's cannot be engaged, then I suggest making recommendations at each Phase Gate or Leadership meeting where you ask for their support on issue resolution so that they can understand the barriers and that the solution requires more resources to be most effective. Also, show the potential with RPA and without RPA as soon as possible. Alternatively, you can categorize your recommendations by effort and impact, it may strengthen your business case to get the collaboration/solutions you seek. Discuss the issues you raised with your management and leadership to get their attention on the wasted opportunities. Lastly, there are organizations where the prevailing culture does not help the kind of problem-solving that matches & values your talent.

The measurement known as the z score is used to determine how a particular value varies, from the average of a group of values. It helps us understand the number of times the variation within the group can fit between that value and the average. The standard deviation represents this variation while the average is referred to as the mean. To calculate a z score for a value we use this formula; z score = (value - mean) / standard deviation. When we may not have access to all values in a group and we only have a sample of them, we can utilize the standard deviation of that sample instead of considering the entire group. The sample average is called the sample mean, while its standard deviation is referred to as the sample standard deviation. The formula for determining a z score using these values would be; z-score = (value - sample mean) / sample standard deviation. We can assess how a process performs using Zoverall and Zwithin measurements, which indicate how closely an average result aligns with our desired outcome. Zoverall examines variations, across all results over time, regardless of when or how they were obtained. When analyzing the results of conditions, such, as those obtained on the day or using the same machine Zwithin provides insights into the variation within the sample (usually much shorter than the overall time period). It's important to keep in mind that process changes can be normal or abnormal. When evaluating process performance for baselining anticipating before and after making improvements, the choice between Zoverall and Zwithin depends on two factors; 1. The type of data available i.e. whether it is continuous or discrete. 2. The stability of the process i.e. whether it remains consistent over time or undergoes changes. If we have continuous data like measuring weight or length and the process is stable with less variations over time using Zwithin might be more suitable. This metric reveals variations within the process itself. On the other hand if we have data, such as counting good or bad outcomes or if the process is unstable and experiences significant changes over time then using Zoverall could be more appropriate. This metric captures variations, in the process that may impact customers. Using both data and comparing them can provide an understanding of the effectiveness of the process and identify areas for improvement. It's beneficial to maintain these numbers as records for our DMAIC project.

Total Productive Maintenance (TPM) refers to initiatives that aim for plant and equipment maintenance and effectiveness. The ideality for TPM is that equipment is maintained so well that it is always available for production, it never fails, is never defective, and produces no safety incidents. The Pillars of TPM are: Autonomous Maintenance: focused on improving maintenance/operator skills. Kaizen: continuous improvement by elimination of waste & improved productivity. Planned Maintenance: preventative maintenance planning. Quality Maintenance: reduction of defects, root causes, and quality programs. Development (Early Equipment) Management: TPM can be very helpful in using the operators' knowledge to reduce maintenance issues and improve maintenance planning as well as auditing. Training and Education: training, upskilling, and change management training are needed in good maintenance & quality programs. TPM in Administration: aligning with administrative and non-maintenance-focused parts of the organization. Safety, Health, and Environment: safety standardization and tracking. TPM often ends up being the responsibility of the maintenance department; however, it should be an organization-wide initiative that gains involvement from all employees. This is why TPM should be a part of the overall Total Quality Maintenance (TQM) strategy of a customer-focused and continuously improving organization with employees involved at all levels. TQM is an organization-wide quality management program focused on customer satisfaction, continuous improvement, and employee engagement. TQM aims to attain quality and productivity, while TPM focuses on the organization's optimal use of plant and equipment.

A design scorecard helps present and evaluate how a given process is performing against its CTQ. It can be used for parts and/or performance levels for each CTQ criterion. Metrics can be input using defects (or performance level) data and CTQ criteria. In a DMADV project, the scorecard allows the team to evaluate if the new design (or process) will likely meet design criteria. CTQ can be taken from the Quality function deployment activities when designing a new process. In a DMAIC project, the scorecard can be a valuable tool, like a dashboard, to evaluate how current processes perform against performance criteria.