Jump to content
Click here to know about Lean Six Sigma Training by the Pioneers in India

All Activity

This stream auto-updates     

  1. Today
  2. R Rajesh
    When 'Bench' does not know or show interest on Lean, Six Sigma principles, he should try to make a 'Mark' in his field, by joining Benchmark Six Sigma and gain the extra knowledge in Business excellence that Lean , Six Sigma approaches can provide
  3. ChristianBaker ChristianBaker joined the community
  4. Vishwadeep Khatri
    Q. 204 The quality of questions and interactions in Toll Gate reviews is crucial for success of any gated process (not just Lean Six Sigma projects). It is seen that poorly planed or administered Toll Gate reviews are one of the biggest reasons for project failure in the Lean Six Sigma world. How should one plan toll gate reviews to ensure their effectiveness? The question will remain open for responses till 22nd October 2019, Tuesday, 5:00 PM IST/ 11:30 AM GMT/ 4:30 AM PST. You may use any sources to frame your answer, however, the answer must be written in your own language. Mention your information and image source, where applicable. Plagiarized responses will not be approved. Answers submitted as images will not be approved either.The approved responses will be visible after the question is locked on 22nd October 2019, Tuesday, 5:00 PM IST/ 11:30 AM GMT/ 4:30 AM PST. The best answer will be selected and points added to the Excellence Scoreboard- https://www.benchmarksixsigma.com/forum/excellence-scoreboard/ All questions so far can be seen here - https://www.benchmarksixsigma.com/forum/lean-six-sigma-business-excellence-questions/
  5. Vishwadeep Khatri
    While Neeraja Killi has provided valuable thoughts on how such a problem can be addressed, the winner for this question is R Rajesh who has comprehensively addressed the modus operandi specifically used for IT Infrastructure. It should be noted that the suggested ideas for IT Infra are useful for several other scenarios of a similar kind.
  6. Rajiv. Rajiv. changed their profile photo
  7. Guest
    Nice to see ... Hope Mark can change the Bench.
  8. Yesterday
  9. R Rajesh
    Normally when an issue happen in an IT Infrastructure, an assessment is made to see the kind of impact it can have for the business and ultimately to the customer. Accordingly fix for the issue will be put in by the respective teams. So even though there can be multiple issues that might happen and for which there may be root causes which are distinct or isolated, each of the issue needs to be tackled in terms of its severity or priority level(decided on the basis of the business impact and the resultant effect on the key customers that the business has). Some organisations address the tickets (called as Incidents in IT Infrastructure projects) in terms of Priority and some organisations, in Severity. Sample Classification of Priority tickets denoted by P1,P2,P3,P4 where P1 and P2 are critical/High respectively and P3-Medium and P4-Low or Sample Classification of Severity tickets denoted by Sev1, Sev2, Sev3 and Sev4 ; where Sev1-Critical; Sev2-High, Sev 3-Medium ; Sev4- Low Now if the issue is of a critical/high nature then we need to put a quick fix. Often the fix would be a workaround. Permanent fix might be later. But if the issue is of a lower nature(priority or severity) then those incidents (issues) are pushed to 'Problem Records' which is used for providing Permanent fixes. This is because the Service Level Agreement(SLA) for Resolution time for Sev1/Sev2 or P1/P2 is very short(in minutes to few hours) and for Sev3/Sev4 or P3/P4 , it can be mostly(in a single day to few days or so). Therefore, it is the severity/priority of the issue that decides the best way to handle the given issue. Accordingly it is decided to have the issue either to be incident managed and needs to be addressed immediately with some sort of fix, or it can be marked as a problem record and moved to 'Problem Management ' category, for a permanent fix. However there are few things that can be done: 1. Maintain a Known Error Database (KEDB). This is an industry standard. Since we talk about issues with isolated root causes, it becomes difficult to track things as we don't have a standard cause to provide a fix. So what happens when an issue happens again for the 2nd time say after a month (from the 1st time when it occurred). Imagine, the person(say a Subject Matter Expert) who provided the fix is not available on that day (when the issue happens or reoccurs), for whatever reasons(assume he/she is resigned). Whoever is working on the issue may have to go through the issue all over again. It would unnecessarily take time to fix the issue. The knowledge therefore would have been lost. Imagine if we have multiple issues with different root causes and how difficult it would be to address each one. For such scenarios, KEDB can be used - which is primarily serves as a log of issues with solutions captured(it can be workaround or permanent fix). It can be a customized tool, excel sheet or any other file. 2. When there are multiple issues and if an issue is repetitively occurring, whether it is high or low priority(severity) issue, then the issue can be tagged as a 'Problem Record' as part of Problem Management. 3. While many teams goto Problem Management based, on getting repetitive issues , which is reactive Problem Management , some wise teams - look for patterns and trends in their project/applications and based on that do a proactive problem management (by basically finding out potential problems) and have problem records created and proactively do a permanent fix avoiding in the process , potential problems (which can avoid even disasters). There are tools like Kepner Tregoe method which can help Problem Management. Conclusion: IT Infrastructure projects will have different type of issues with different priority/severity level. Each may have different or distinct root causes. But as we saw, based on the severity/priority of the issue, the issue is dealt with. It is always a good practice to have a KEDB to ensure that workaround solutions or solutions for permanent fix is available. For instance, an error in a page can happen and which may be a critical or high issue, but for which the workaround solution might be say restarting a server(just a crude example but using here to drive home the point). So this can be mentioned in KEDB for that issue Also there could be cases where issues can be created as Problem records so as to provide permanent fixes. In such cases, for recurring issues, records are created reactively (issues have happened as incidents - be it critical/high or medium/low) and proactively also records can be created. The more proactive potential issues we find and provide upfront fixes, better would be stability of the applications in production, better customer satisfaction and minimal adverse impact for the business.
  10. Mayank Gupta started following Quality Month
  11. Mayank Gupta
    Hi Sandeep Below are certain things that you could do 1. Kaizen roadshows / Kaizen events / Kaizen week 2. Crossword and small quiz competitions on quality concepts 3. 5S activities in the bay 4. R&R for processes where good process documentation exists 5. Daily email containing - Quality term of the day, Quality person of the day etc. 6. Interviews with HODs or CXOs on how quality concepts could help the organization 7. Wall of Fame for good projects or initiatives
  12. Last week
  13. Saumik Bose Saumik Bose joined the community
  14. Franklin Franklin joined the community
  15. Vijay Chaudhary Vijay Chaudhary joined the community
  16. Sahil J Sahil J joined the community
  17. Amith Pawar Amith Pawar joined the community
  18. Poornesh Poornesh joined the community
  19. Neeraja Killi
    While I didn't personally work on a similar improvisation project, I did witness my organisation deploy a permanent solution to this kind of IT ticketing issues. While working with a 3rd party logistics company, ensuring the availability of all systems is key given that all the warehouses were spread across various countries across the world and the key IT administration teams were located at major offices. Even when someone from the IT admin team is always available given their global presence covering the global time zone, the company adapted a process to analyse the types of tickets, time taken for issue resolution and the trend of these parameters across the company every quarter. This helped them identify the most common occurrences for the major tickets and find a resolution for this and implement it immediately, which resulted in the decrease of total number of IT infrastructure related tickets by a whopping 25% in the next quarter. This approach also, made the company switch to a different service provider after identifying the root cause of major issues was due to the lack of proper SLA establishment with the previous service provider and also the previous provider not agreeing to the new requirement. This eventually showed a constant decreasing trend in the IT admin related tickets each quarter and improved the system availability drastically.
  20. Guest
    It gives us the difference between non six sigma applied approach and six sigma applied benefits. It encourages us to promote six sigma in every problem solving steps.
  21. Guest
    Great, cartoons are a great way to deliver messages!
  22. Vivek Vivek joined the community
  23. Vishwadeep Khatri
    Q. 203 How do you tackle a situation (as commonly found in IT Infrastructure) where you find that large volumes of IT Tickets points to different isolated root causes most of the time? Do you think that fixing issues quickly as they occur is the best way to handle such a situation? What other similar situations have you faced? Note for website visitors - Two questions are asked every week on this platform. One on Tuesday and the other on Friday. All questions so far can be seen here - https://www.benchmarksixsigma.com/forum/lean-six-sigma-business-excellence-questions/ Please visit the forum home page at https://www.benchmarksixsigma.com/forum/ to respond to the latest question open till the next Tuesday/ Friday evening as per Indian Standard Time. The best answer is always shown at the top among responses and the author finds honorable mention in our Business Excellence dictionary at https://www.benchmarksixsigma.com/forum/business-excellence-dictionary-glossary/ along with the related term.
  24. Vishwadeep Khatri started following The Bench and Mark Excellence Series!, DMAIC vs DMADV and Bench and Mark 1 - Six Sigma Evolution
  25. Vishwadeep Khatri
    Correct answers provided by Mohamed Asif and Koteswararao Darnasi. The winner this time is Mohamed Asif for providing more details of each phase and highlighting in a comparative format. Please go through Venugopal's anwer as well, considering a flexible approach whereby we decide if we want to redesign the process or improve existing process at a later stage.
  26. Vishwadeep Khatri
    Bench still thinks of Six Sigma as a measure of process performance and struggles with the defects per million concept. Mark has continued to learn with evolution of Lean Six Sigma into a strategy driven Business Result Improvement Program. Are you ready to take your program to the next level? Do provide your comments on where do you think different organizations exist in this journey. This is a very important discussion board for all Lean Six Sigma practitioners.
  27. Guest
    Looking foward to toon journey... visual display is always a fun to learning method..
  28. Guest
  29. Guest
    Interesting topic. Eagerly waiting of diffrent opinions of Bench & Mark. The clash of mindsets, thoughts etc. Would be hoping positive takeaways from the upcoming episodes.
  30. Guest
    Mark is built on the platform of Bench . It is a stable parameter on the basis of which Mark can move . But definitely Mark can be more dynamic
  31. Guest
    Bench & Mark are following their own wisdom. Bench & Mark should swap their roles for a day and then see the difference!
  32. Venugopal R
    Benchmark Six Sigma Expert View by Venugopal R We all would have learned about DMAIC and DMADV during our Six Sigma courses and many of us have used these approaches in our projects. Hence there may not be a need for any introductory explanation for these acronyms. However, I wish to provide my view point based on my experiences through handling projects under various circumstances. DMAIC (Define, Measure, Analyse, Improve, Control) is more commonly seen as the methodology used in most Six Sigma Projects. The usage of DMADV (Define, Measure, Analyse, Design, Validate) is usually seen less often. In general, it has been explained that DMAIC is used for ‘Improving’ a process and DMADV is used when a process needs to be designed. Projects are taken up to address some pain points or to improvement opportunities. Do we know every time we take up a project, whether a process has to be improved or designed? If no process exists, then of course, we will have to design a process; however if there is an existing process, we may have to either improve it or re-design it. Some times only after completing the Analyse phase, we would be able to take a decision whether it is worth improving the existing process or it needs to be re-designed. In the above situation the DMA phases are common and our decision to improve or (re)Design the process is taken only after doing some analysis. For example, we have a problem relating to Supplier Quality and we find that parts supplied by certified suppliers are defective. We go through the Define and Measure phase and collect sufficient and relevant data. Once we analyse the data, and if we find our problem to be confined to very few suppliers or most of the issues are relating to one or two parameters of the process, then we may decide that the existing supplier selection and certification process is by-and-large successful, but needs improvement only on a few areas and parameters. On the other hand, if after our Analyse phase we are convinced that majority of the suppliers certified through the process have issues or we see issues across many parameters, then we may conclude that it may not be worthwhile fixing the existing process, but rather go for re-designing the process. In such a case, if we may want to trace back on our DMA phases and to re-define our objective and goals. If we are using DMA as part of DMADV, some of the tools would be same as we would have used in DMAIC, but the intent may be different. For example, Process FMEA may be a common tool. For DMAIC we might use it for specific steps of the process that are identified for improvement, whereas in DMADV, we would use it for the entire process. There would be some tools that may be more applicable in DMADV, such as Customer surveys and QFD. It may also be noted that mostly, when we are clear about our need to design a process, we may straight away go for DFSS (Design For Six Sigma). IDOV (Identify, Design, Optimize, Verify) is one of the popular approaches for DFSS.
  33. Guest
    Delta has to be there for progress to happen and betterment. Even if the gap closes between Bench and Mark some new thought will take birth and lead the way.
  34. Guest
    Would be nice if, at some point, Bench & Mark get to be on the same team.
  35. Guest
    Bench forms the base for Mark to kick start any initiative. Though being bench is definitely a safe play...Mark is the path to success!
  36. Koteswararao Darnasi
    DMAIC is a one of the continuous improvement methodology , this is focusing on the identifying and elimination of waste and reduce the variation in the process. (Define, Measure, Analyse,Improve, control). DMADV: (Define, measure,Analyse,Design, verify): Which is focused on the new process product designing, service/process. That is the reason it is completely different of DMA from DMAIC, & DMA of DMADV... let me explain in detail For DMA of DMAIC: D: define problem, M: Collect the data & data stratify ,A: Analyse the data & identify the Root cause. For DMA of DMADV: D: Define the process and design goals, M: Measure and identify the critical quality characteristics, A: Analyse the data to find the best design Regds Koteswaararao
  37. Mohamed Asif
    There is of course, substantial difference between DMA of DMAIC and DMADV. I have briefly tabulated the difference, common tools and deliverables used in each of the phases in both the methodologies.
  38. Hemant P. Singh

    Oct-Dec 2019

    Hemant P. Singh added images to a gallery album in 2019

    This album contains Benchmark Six Sigma Training Photographs from October to December 2019.
  39. Vishwadeep Khatri
  1. Load more activity
×
×
  • Create New...