How to Prioritize Projects

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.
Impact/Effort Matrix

When using an impact/effort matrix, you will start with a list of potential opportunities to work on and prioritize them by plotting out how much impact a project might have vs. how much effort it will take.

Projects that take low effort for high impact ("easy wins") are the first priority. Then projects with higher effort, and high impact ("Big bets") or lower impact and lower effort ("Incremental") are next. Lastly, it's best to identify if a project will be low impact and high effort ("money pits'"), and avoid them altogether.



But how do you define these categories?

How to measure "impact".

Impact can be determined in a number of ways that generally fall within reducing cost, increasing quality, or improving safety. With Amper data, you can easily quantify the impact through downtime hours.

Here is an article that shows how to determine your cost of production and correlate downtime hours to a general opportunity cost.

📊

Use Utilization Data to Justify CI Projects

Additionally, if you are labeling downtime, each "bucket" in your pareto will represent a cost as well. See the downtime breakdown example below.



In this example, Tool Change accounts for 432 hours over the last quarter for these machines. 432 hours at the $40/hour cost of production is worth $17,280. Extrapolated out to 1 year, this opportunity is worth $69,120. 432 hours/quarter x $40/hour x 4 quarters/year = $69,120.

Each "bucket" of downtime can be a project, or multiple projects, and reducing it could yield some serious cost savings.

👉
Check out some common projects our customers discover with their downtime reasons.
📊
Data-Driven Projects

Examples of things that contribute to "effort":

1. Complexity: Is the solution of the project known or unknown? Projects with unknown solutions are generally more effort.
2. Cross-functionality: 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.
3. Costs associated to the project - more cost could be considered more effort if capex is required.
4. Time the projects might take - more time is more effort to do the project.

How to Execute

The Plan-Do-Check-Act Cycle

• 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 a 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.