Can Path Finding be used in the Production Environment?

Can Path Finding be used in the Production Environment?

In previous posts, I have discussed various scenarios when Path Finding can be used. All were focused on the early design process: implementation guidelines, robust design and process centering. But what if you have a design in production and ‘something’ happens; like a process is no longer available; a component must be replaced by another, yields become erratic, etc. Is there a role for Path Finding in a production environment?

Given that your production environment cannot produce the same number of finished products OR the cost to produce has dramatically increased, it is imperative to find a workable solution fast. The longer this problem exists, the worse the impact on your revenue and/or expenses.

Path Finding methodology does not understand whether this is new product exploration (pre production) or if this product is in production. The same exploration techniques that were used to help define how a product is implemented can be used to determine alternative solutions during production. However, there is one big constraint. Unless you plan to re-design the product anew, many of the previous decisions may not be altered. This requires laser-beam focus on the current issue, being able to replicate the issue in Path Finding and then determining what alternatives have the least (cost, risk) impact on the current production design.

The bad news: you may have few options to choose from due to constraints.

The good news: Path Finding can help you quickly evaluate the limited options and help identify the one that has the least impact (cost, risk, schedule, etc).

An example: Years ago, I had product responsibility for a family of ceramic packages at an IDM. One product had excellent final test yields that abruptly ‘crashed’: normal test yields of 98% dropped to 50%. Our production costs doubled while our price/unit remained constant. During this yield issue, we were losing money for each unit shipped AND required us to double our production quantities to hit customers’ orders. Our Path Finding focused on the back end manufacturing process and we ran a few experiments to quickly identify the physical location (Penang vs. Carrollton) and then quickly hone in on what operation caused the problem. Fortunately, the experiments quickly identified the location and operation. The issue was very easy, fast and cheap to implement. Yields quickly returned to their ‘standard’.

In the above example, we were lucky. The issue was related to an unapproved process change. If our exploration decided that it was not a process issue but a product implementation issue, we would then have explored alternative implementations. ~ B. Martin

  • Dr. Dev Gupta

    Though some of the basic sciences needed to tackle pathfinding ( for future products ) and troubleshooting ( of current products ) might be similar, they normally require different methodologies as for the former a lot of in depth data can be gathered at leisure for a few units while for the latter volumes of data is available from the line for a large no. of units but could be low quality and time is of the essence. Therefore conflating these two extremes involve some risk.

    • Dr. Gupta,

      Yes, during planning/designing (prior to Mfg release), you do have many more variables and PF experiments that can be run. When I mentioned ‘run’, I am talking virtual prototypes (models) rather than physical material. Once the first lots of material are produced, physical product testing will validate the design/verification process. The types of testing that are performed at this stage is defined by the Mfg to ensure yields used to quote the business. Time is still of the essence during this planning/design period since the rest of the market (competition) does not wait for you.

      On the Mfg side, the time pressure is increased since WIP is scrapped, end customer shipments can be delayed, etc. Determining where the issue lies involves setting up experiments to help isolate the root cause. If the root cause is changes to a Mfg process, you might be able to check these in your PF ‘virtual’ experiments. In the case I mentioned, we did not have a PF ‘mechanical’ setup to validate the rapid cooling caused micro cracks in the ceramic package. Where ever the root cause is found, it would be a good idea to double check any PF setup to see if it would have predicted the issue. If not, maybe the PF method/tools needs to be modified so you can have a closed looped method.