⤵️

How to Determine a CI Project Based on Downtime Reasons

Once you start labeling downtime reasons in Amper, you can quantify how much each reason is costing you. This will help you identify which CI projects are worth it based on impact.

  1. To start, have your team begin labeling downtime reasons if they aren't already. Check out this article to learn tips for getting your operators to log downtime reasons.
  2. After you collect 3-4 weeks of data, determine what your top reasons for downtime are.
  3. Use an Impact/Effort Matrix to help you determine what projects will take the least amount of effort, for the biggest impact.
  4. Examples of things that contribute to "effort":

    -Is the solution of the project known or unknown? Project with unknown solutions are generally more effort.

    -Number of different departments the project will touch. The more departments that will need to be involved in the solution, the more effort the project will take.

    -Costs associated to the project - more cost could be considered more effort if capex is required.

    -Time the projects might take - more time is more effort to do the project.

image

Th Plan-Do-Check-Act Cycle

Once you identify which project will have the least amount of effort for the biggest impact, you should follow the a project management cycle to execute the project. Plan-Do-Check-Act (PDCA) cycle or A3 are examples of this.

  • Plan your project: Use downtime data to justify doing a CI project.
    • Understand current state.
    • Figure out what you want your future state to look like. What does "done" look like?
    • Perform Root Cause Analysis and identify possible improvement ideas.
  • Do improvement changes: Implement the solutions - experiment! We suggest you test out your solutions across just couple of machines or areas first to keep your experiment as controlled as possible.
  • Check to see if the change is working: Audit the change to make sure all involved participants are adhering to the change. Monitor the results for at least 30 days, and check your utilization to see if it increased after implementing the change. You may repeat the "do" and "check" stages multiple times until the right combination of solutions are known. The "plan", "do", "check" cycles should take up 80% of your project time.
  • Act on the proven solution: Implement the change across more or all areas. Document the new process and standardize it across all machines.