Supply Chain Management

2023/06/16
Supply Chain Management Image
The whitepaper shares some design guidelines and advice on how to reduce failure causes and simplify the design - with application examples for a better comprehension.

Table of contents

  1. Introduction
  2. It all starts with the functional specification
  3. Working with procurement/commodities stakeholders
  4. Enterprise resource planning (ERP) (Download/Login)
  5. Working with the power solution vendor (Download/Login)
  6. Summary/Conslusions and follow-on info (Download/Login)
  7. References (Download/Login)

Get the whole Whitepaper now

ダウンロード/ログイン

1. Introduction

This whitepaper was created in conjunction with another, complementary whitepaper focused on supply chain management. While the two may have a similar look and feel on related topics, it should be noted this whitepaper focuses on how to manage the supply chain resources identified in the preceding document and facilitate managing those vendors.
NOTE: the term “vendor” is used loosely here and could easily apply to an organization’s internal resource management.

In other words, the last whitepaper focused on the tools for performing feasibility, while this one focuses more on the execution aspects. Again, though there may be some overlap in key topic areas, the content of each takes on differentiating and meaningful context and should therefore be treated as such.

2. It all starts with the functional specification

Everything from design to supply chain to any other critical, system-development dependency starts with a proper functional specification (spec). If the bar is not set correctly at the onset, the issues/risks/COSTS only magnify as the schedule progresses. It is quite common to put a lot of pressure on the design engineering resources to set a design in motion even before specifications are fully baked out. This is particularly true for smaller/fresher organizations, where resources are scant and the end of the funding runway if often on the horizon.

When it comes to developing power supplies and associated, powered solutions, this pressure will likely end up being funneled to the power electronics engineer or analogous team stakeholder having first-order responsibility to deliver system power infrastructure. They must stay strong in the face of this pressure and be vigilant in insisting system architects and other design partners sit down and have the necessary discussions and not except too many “TBD” (to be determined) placeholders for critical specs. This is not to say there should be an expectation of a final-quality document at project onset, which should certainly be tweaked and optimized as the development progresses, but even a draft spec should not be so broad and/or nebulous so as to inhibit (high-quality, timely) developments.

Many functional requirements and certifications are out of the hands of the power solution designer/owner, even if they have ultimate responsibility for successfully delivering the solution. Examples include derating guidelines (i.e. – IPC-9592, internal design guides, etc.), specialized certifications (i.e. – EN51055, 80PLUS, EMC class A/B, DoE Level VI, NEBS, etc.), digital interfaces with system SW/FW, and full environmental operating scenarios (inc. compatibility with elevation and pollution/harsh environments).
Many of these are not just stickers or rubber stamps to complete an aesthetic at assembly, but will have significant impacts on operating parameters (i.e. – minimum efficiency requirements, wider operating temperatures, more robust shock/vibe/electrical withstand, etc.) that can dictate the design from Day 1. The key takeaway is to be unrelenting with other stakeholders that lack the understanding/appreciation for what they are requesting and think these are questions that can be answered much later in the development process because when things go wrong, all that anyone remembers is that the “power person” is responsible for ANYTHING that inhibits successful shipment and field deployment.

A quintessential example of these communication gaps is when power subsystems implement digital reporting (control is not necessarily implied), which means a power converter can “talk” to the system via a digital bus and often, the system may have the ability to talk back. The only way these two components can be effectively designed to successfully operate cohesively and robustly in the application environment is if the HW and SW engineering stakeholders can come together to develop each of their respective, functional specifications (one for the converter, one for the system).
The power stakeholder is unlikely to have the knowledge/experience to specify the digital bus characteristics, register assignments, and fault code formatting (to give a brief sampling of a long list items) autonomously. The SW/ FW stakeholder is unlikely to have the knowledge/experience to specify fault thresholds, power supply states/behaviors, and protection circuitry. Mitigating the gap in team communications between HW and SW engineering (as one example) is absolutely essential for successful development of a minimally-viable functional specification in just about any modern system.

To further make the point, it should be noted a solid functional spec is also a key enabler of the request-for quote/proposal (RFQ/RFP) process, assuming a design is put out for bidding on by third parties. Everything from unit/warranty costs (inc. quality/reliability) to the development schedule to the availability of necessary resources to supply chain assurance of supply (AOS) to the financial viability of both the vendor and end-user organizations (in the most extreme cases) will be determined by the requirements set forth in the functional spec. This includes key items like safety/compliance/certification needs and design/qualification guidelines that must be followed.

When embarking on a new project, do you have what you need to generate a sufficient functional spec? Do you have the critical inputs of constraints from other engineering groups, program managers, and supply chain stakeholders? If Marketing cannot produce a product requirements doc (PRD, a.k.a. – marketing requirements doc or MRD) or equivalent, then how can you be expected to develop a proper functional spec for solutions to effectively meet those requirements? While it seems silly to say this, sometimes it is important to question if the requirements/specs being dictated are even pragmatically feasible with modern technology (or even fundamental physics sometimes). If your converter is required to have a transient response of 1MA/ns or support an operating environment of 500°C, then Houston, we have a problem!

3. Working with procurement/commodities stakeholders

The previous, complementary whitepaper provided a more in-depth analysis into multisourcing, what it is, how it can be interpreted, and some considerations (positive and negative) for performing a proper assessment of one’s resources and making an informed decision. In short, the different considerations really seem to boil down to a focus on mitigating technical risk versus pricing leverage. As a further reminder, the objectives of stakeholders (internal/external, engineering/supply chain the like) are typically in conflict, both in execution as well as the priorities driving them. Here, we shall take that assessment and expand upon it to turn the analysis into more actionable strategies for driving results.

Assuming the final decision has been made to implement some kind of multisourcing strategy, the first step is for Design Engineering to determine the “critical components” list for analysis. The term is in quotes because the characterization of what is critical can be highly subjective and variable. Even trying to simplify with rules like “only the power components” or “only the hottest components” or “only the components most critical to safety” will often lead to grey areas and points of dissent. Regardless, it is important to work closely with teammates (especially those in Component/Reliability Engineering and Supply Chain Management) to negotiate through the tradeoffs of performance, cost, time-to-market (TTM), and AOS.

Component/Reliability Engineering is typically the least concerned with cost, which means they can dictate many qualification/life tests that can be extremely expensive, time consuming, and require 3rd-party resources (each time one takes direct control away, it adds risk to the development and schedule). First negotiating with these stakeholders on the minimum list of critical components, with proper justifications for either accepting or eliminating items on the critical components list, is an excellent origin point. An example of a compromise proposal may be if a component can be assessed with more virtual/statistical methods (such as Monte Carlo analysis [1] or vendor random sampling data) instead of the far more comprehensive, thermal/electrical stress and accelerated life testing.

Any such “real” (e.g. – physical/environmental) tests will not only need to consider the qualification on the individual component, but also the validation in the actual system(s) it is targeted for so it should be fairly apparent how determining the number of devices/units under test (DUT/UUT) can be challenging with the number of printed circuit assembly (PCA) bill-of-material (BOM) combinations that will only grow exponentially with each extra source added to the mix. Some key questions to consider are as follows:

  • Has the program manager allocated (and therefore also budgeted) a sufficient number of (prototype) UUTs to accomplish the requisite testing?
  • How long will there testing take and at what stage in the development schedule?
  • If the schedule is very tight, then is there any contingency planning for when a proto fails highly-accelerated life testing (HALT) or exceeds electromagnetic interference (EMI) class limits?
  • Does this align with the power solution release target AND the system release target?

Supply Chain Management personnel are likely to be driven more by opportunities for cost reduction and tend to view multisourcing as a helpful tool for driving AOS. The latter point is debated in the previous whitepaper and will not be repeated here, but please be sure to investigate component availability and lead times on a line-by-line basis. The determination/qualification of a “critical” component was discussed above, but that is still a different discussion from how a second-source component is determined to be considered “equivalent” to a primary source. Again the quotes are not to be cheeky, but to emphasize the point this can be a very relative term and the semantics of which are inexorably tied to everyone’s success. Unfortunately, it is all too common these days for equivalence to be determined by some very fundamental figures of merit (FOM) and cost (typically, with highly inequitable weighting).

While this point is most salient in components that tend to be more sensitive to environmental/application factors (i.e. – semiconductor devices), it can be just as applicable to the simplest of passives (i.e. – resistors). Two different sources for a metal–oxide–semiconductor field-effect transistor (MOSFET) may have the same package/footprint, drain-to-source (a.k.a. – blocking) voltage, and gate voltage, but can still have drastically different gate charge or input/output capacitances. While this may be irrelevant for a small-signal, switching application, it can make all the difference in the world when used in a power FET application. Two different 1k resistors in the same package style and thermal rating may still have slightly different footprints, material composition, or termination styles. The different sources may still likely be characterized as dual sources under the internal part number in the company’s approved vendor list (AVL), which means either source is considered qualified to be used interchangeably and leads to major performance risks.

It is natural to want to define rules to help simplify complicated developments and implement processes for what may be perceived as optimizing for time/cost, but multisourcing is one of those particularly touchy areas in which being too generic or restrictive can be highly counterintuitive to meeting ultimate project goals. A simple example of this is that low-volume designs should have a totally different approach than high-volume designs. Low-volume designs tend to be more specialized, can have more aggressive/ruggedized specifications, and be less cost sensitive. High-volume designs tend to have more stringent quality requirements, have increased risk from AOS, and have the overall economic viability be tied to tightly-controlled component, manufacturing, and qualification costs.

A last, key topic in this discussion about how to effectively manage supply chain stakeholders in Commodities Management revolves around business continuity planning (BCP) support [2]. BCP is all about contingency planning against major interruptions, such as is the case for disaster recovery and mitigating enterprise resource planning (ERP, [3]) bottlenecks. While these typically involve tasks for those Commodities Management groups and the resources they associate with, it is always good practice for the power design resource/owner to keep abreast of these processes and the planned actions in the case of a disaster, whether it be from an act of God or a severe supply issue (i.e. – regulatory/embargo/customs). A worst-case scenario can be when an entire factory (or even region) is taken out by a natural …

Want to read the whole Whitepaper?

ダウンロード/ログイン
アプリケーション