Analyzing Cost Down Opportunities During Redesign Efforts

MANAGEMENT BRIEF: We analyze cost down opportunities during redesign efforts. Coupling LTBs may present options that extend life and reduce product cost—maybe.

Cost reduction is critical for product profitability. It ensures that investments yield high returns. During redesign efforts, we focus on identifying opportunities. The aim is to enhance efficiency while minimizing engineering redesign and manufacturing expenses.

Last Time Buy (LTB) from a component manufacturer can be an opportunity to look at the overall cost structure of the product. That said, the opportunity has a time window associated with it. If other cost down opportunities cannot be redesigned into the product and effectively redeployed to manufacturing in the required timeframe then a potentially catastrophic line down situation can occur. It is this balance that we try to address in this article.

First, we start with the component(s) that are indicated by the LTB - the time that it takes to redesign, validate, certify and adopt into manufacturing is your baseline starting point. This timeframe will also allow you to calculate the quantity targets for the LTB. When executing on your TLB ensure that you have your projected volume needs in your hip pocket. If you dont have these, you cannot evaluate your LTB quantities. As an example, if your timeframe for bringing the redesign to market is two years then your LTB quantities need to take the two year window into account including anticipated ramp or ramp down in demand coupled in with some safety margin that your organization is comfortable with.

18–24 mo. Typical duration of a memory-platform redesign in a certified environment

90–180 days Typical last-time-buy window — the only moment the bridge can be built

24–30 mo. Bridge horizon: redesign duration plus qualification and slip allowance

Next, we look at other opportunities that may allow further cost reduction. These opportunties can have varying degrees of risk associated with them. Many times, "bundling" of such opportunities is less costly them doing them individually. For instance, if LTB component is forcing a recertification of the product in the same area, then the engagement with the certifying body may be incrementally more expensive than if simply evaluated the LTB component in isolation. However, that incremental cost is very likely less expensive than an isolated engagement for each of the other components.

Now, we get to the heart of the matter and try to understand the types of cost downs that can be executed on without blowing out the sacred "no down time" window.

Much of the evaluation for component candidates comes down to component types:

Component Type	Time to redesign	Risk	Comments
Passives - Caps, Resistors, Series)	3-6 months	Low	Drop in replacements typically easy to find (series can be more challenging)
Memory (DDR, NAND)	18 months	Med	Look for pin compatible alternatives
Active Components ( FPGA, CPU, MCU,GPU,DSPs... )	18- 24 months	High	This category has a lot of variability. If within the same manufacturer and part family architecture can save significant time
Converters (ADC,DAC)	18 months	Med-High	This category has some variability. Converter architecture can save significant time (pay attention to matching convertor architecture (SARs vs Sigma Deltas) and voltage gain ranges

For all the above, assess package requirements for your application as well as supply voltage level requirements. These can greatly impact the extent of the redesign necessary.

PCB layout can be evaluated for potential opportunities for reducing the number of layers which can add to cost savings. However, this can require significant effort from the SI/PI and layout teams and would be considered a higher risk endeavor. If you are thinking about changing out PCB vendors make sure that you have good sourcing engagement supported by engineering when engaging. PCB materials can make a difference here. So due diligence is warranted.

While we used an LTB to drive this conversation, it should be understood that the LTB does not need to drive a cost reduction redesign. Engineering groups should have continuous product cost reduction efforts with their continuation engineering groups as matter of good practice.

The organizations with strong continuation process recognize obsolescence opportunities and builds a flexible roadmap. These roadmaps should reference a component-availability forecast; and a single owner accountable for the coupling. The ones that do not exhibit an equally recognizable signature — procurement and engineering surprising each other, serially, with each function's rational local decision creating the other's emergency. Which signature an organization carries is discoverable in an afternoon of the right questions, and changing it is a matter of operating structure, not heroics. That diagnostic — whether the bridge and the redesign are coupled, governed, and recurring. Good synchronization between engineering, sourcing and business is essential for making a good ROI decision.

Questions that should be asked are:

• What are the potential savings of bundling the opportunities?

• How long will it take to bring these savings to market?

• What is the effort and cost associated with the bundling opportunities?

• What are the risks? How much impact can these risks have to effort/cost and TTM. If risks manifest, is there a potential line down due to inability to bridge with the LTB?

• What are the projected sales long term for the product? Is it ramping up or ramping down or static?

• Are there side effects of these changes? For instance, what is the impact to firmware, software, documentation, manufacturing time etc? Make sure that these are accounted for in the initial workups for the efforts and cost across the organization.

• Are there commercial impacts? Will there be compatibility issues where forced upgrade to software or firmware is required by the end user? Will the functionality change in a way that impacts them?

With LTBs timeliness is everything. These adaptable processes are precisely the kind of question the Nexus Operating Architecture exists to solve.