Aligning Design & Supply Chains
Originally published in the April 22, 2002 issue of EBN, and still available online on the EE Times site, this was the first article in their "Thought Leadership Series". Note that this was written prior to the RoHS Directive and most other major product environmental regulatory requirements coming into existence. While not mentioned here because of that, they fit right into this framework when, for instance, you think of chemical or energy use requirements as simply more parametrics to be identified, addressed and managed.
Make/buy decisions and component selection for new-product development at OEMs today is often done solely by design engineers choosing off-the-shelf components and designing ASICs from suppliers of their choosing. Component selections are therefore based, almost universally and exclusively, on design and technology requirements, with little thought given to downstream supply chain concerns. This can create serious and costly problems later in the process. Consider these real-world examples:
A. An engineer designed a network switch that optimized performance but contained seven distinct types, sizes, and configurations of memories from five different suppliers. This required at least two different memory interfaces to be designed for the ASICs. A competitor's product was designed to use a single, high performance, multi-sourced memory device everywhere. The result of manufacturing the former switch was increased development costs, increased procurement complexity, and increased assembly complexity and cost, which led to margin and market-share erosion.
B. A small OEM ramped production in 2000 of its first networking product, which was wildly successful. Unfortunately, every component on the bill of materials (BOM), including resistors and capacitors, had only one source. The contract manufacturer, whose Preferred Supplier List (PSL) was not used during the product design phase, was screaming for more sources. The result was that the company had to hire more engineers and procurement specialists, spending more than $1 million in additional direct cost. Also, it incurred significant nonrecurring engineering costs over a six month period as it qualified second-source suppliers and layed out the board once again to accommodate more available package configurations while delaying product shipments.
C. A large multinational OEM outsourced board design to a Far East contract design house. Neither the OEM nor its contract manufacturer had a relationship with the supplier of one of the selected components, which was on allocation. Result: shipments were delayed while an executive fire drill forced the company to engage with the previously unknown supplier to get the necessary allocation. Existing preferred suppliers could have met the product need easily and at better prices had their parts been used in the design.
D. A start-up did the same thing described in example B, above, and failed to get a second round of funding.
Why do these problems occur? Because product development unwittingly defines the supply chain. Consider this: The design engineer's charter is to produce a working product that meets the marketing department's product requirements document. This document normally specifies the market, the product functionality, and other important considerations for a single product or product line. Producing a working product has little to do with its procurability, testability, serviceability, reliability, or manufacturability.
Further, component and supplier selection is often made in an expedient manner. Typically, it follows the path of least resistance. Usually that path leads to a supplier or component that the design engineer used in a previous design, saw in a recent technical sales presentation, found after a quick search of the Web, or got through a recommendation from a peer. The result is that anywhere between 70% and 95% of a product's cost is defined in the first 5% to 20% of development, long before downstream considerations have been taken into account.
Still, design engineers are not to blame for bad supply chain decisions. In most cases, there is no corporate supply chain strategy, so engineers are saddled with the responsibility. Typically, they have no experience, training, or tools, and little proactive guidance and information about supply chain issues. Few OEMs with less than $2 billion in revenue have applied resources and processes to define and manage supplier and component selection at the enterprise level.
At best, a BOM review - which is a formal or informal analysis of components and suppliers used on the product, usually performed by component engineering, other nondevelopment engineering groups and procurement, with the design engineer's help if they're lucky - will be held after the BOM is essentially complete and all components are therefore committed. Operations, the internal organization with the most complete knowledge of supply chain issues, will be able to minister to only the most egregious problems at that point because any significant change will delay the product. Even a seemingly minor problem can eat into development time, subsequently delaying time-to-market.
For example, a design engineer at a server manufacturer selected a high-density connector that, unbeknownst to him, soon became obsolete. This fact was not identified until boards were being assembled. An emergency end-of-life (EOL) buy, which cost the company $10,000, was required to cover the time needed to redesign the board with a replacement connector. Perhaps more painful was the research and board re-layout, which cost on the order of 200 person hours. These types of problems occur on almost every product, often more than once, at almost every OEM.
Design management suffers from the same lack of supply chain experience and sensitivity, despite the fact that poor component and supplier choices can have substantial negative impact on product implementation. Even if management reviews the component and supplier choices proposed by the engineers, they do so from the development organization's perspective alone and rarely disagree with the average component decision. Even less frequently does upper management drive strategic supplier selection during development of a new product line, which has the potentially devastating effect of misaligning their product roadmap with the roadmaps of key component suppliers.
OEMs have historically endured communication problems between the development and operations organizations, which lead to the scenarios described above. The former designs new products, while the latter builds them - the proverbial toss-it-over-the-wall syndrome that still exists today in many companies. Due to different agendas, the two groups tend to be unable to agree on the supply base or what rules to apply to new designs. Moreover, the agendas do not meet until the chief executive steps into the fray, since development and operations are nearly always run separately by vice presidents. However, this rarely produces a lasting solution as the chief executive is often too far removed from the detailed yet strategic product issues to align the two complex agendas. The result is that the CEO usually delegates the problem to his vice presidents to solve, which never resolves anything.
Part of the operations organization's agenda has been to simplify the supply chain by limiting the number of suppliers they have to manage and reducing the likelihood of supply constraints by insisting on multiple sources for all components. Often that results in operations hiring component engineers to identify second sources after New Product Introduction (NPI), because they have no leverage with the development organization.
How can development design a product with an edge on the competition without using new suppliers with unique parts or ASIC technology, which is what operations demands? It's not possible, so development simply ignores operations' requirements. This has been the mortar for the wall.
Structural issues are at work as well. In the early 1990s, the phenomenon of concurrent engineering, which involves engineers from various functional groups (e.g., reliability, manufacturing, test) at an early stage in the OEM's product development process, took hold at many large companies. If done well and managed properly, concurrent engineering brings a level of supply chain insight to the early stages of product development. Implementation, like ISO 9001 and other culture-adjusting measures, requires executive management buy-in and active involvement, as well as a relatively large and well staffed organization. The problem is that OEMs with less than $1 billion in revenue tend to lack many of the key functional groups required for concurrent engineering. So even if they wanted to introduce manufacturing and supply chain issues into the design process earlier, many don't have the staff to do so.
In the days before the rush to outsource production and procurement to contract manufacturers, OEMs had more direct informational and financial relationships with suppliers. They purchased components either directly or through distribution, and built products on their own assembly lines. Therefore, if internal concurrent engineering methods were broadly adopted they usually had the desired effect of reducing post-NPI problems. As costs for transitioning to surface mount technology increased and maintaining a well-balanced and loaded internal assembly line became increasingly challenging, the option of outsourcing production, typically viewed as neither a strategic capability nor a core competency, proved financially appealing. In the late '90s, this trend took off, creating a few giant EMS providers.
OEMs now just had to create a BOM, provide collateral assembly documentation, and throw it over a new wall to the EMS provider for component procurement and assembly production. It seemed to simplify matters dramatically, allowing operations to reduce the number of suppliers to one.
The appearance was, of course, an illusion. All the suppliers still exist and must be managed by someone - namely the third-party EMS provider. Development at the OEM still defines the supply chain, and similar but broader and more rigid design for manufacturability requirements continue to exert influence. But now, the operations organization's supply chain knowledge becomes third party because the supply chain itself is one step removed and controlled by the EMS provider with its own agenda.
The OEM may or may not have leverage with its EMS providers, which have yet another agenda: to maximize use of their preferred supply base and maximize capacity utilization, which means minimizing short production runs and design changes during production. This agenda is diametrically opposed to the relatively common OEM agenda of controlling their own supply base and building a high value/high dynamic mix product, often in low volume.
In the 1990s, many OEMs failed to understand their own agendas well enough before outsourcing, and further failed to understand the EMS providers' agenda and the impact it would have on procurement and production. OEMs were fooled, perhaps, by the fact that they sold their factories along with their employees to EMS providers and often continued to deal with the same people as before. Continuity of interpersonal relationships helped shield the reality that the EMS provider cannot be treated as an internal resource but must be managed as a strategic supplier.
Since EMS providers now own the supplier relationships and means of production, their agenda is clearly different from the OEMs' agenda. And any rationale for the operations and product development organizations to have differing agendas is greatly diminished since they no longer hold sway over the supply base or production engine. Operations' role has been changed to managing the EMS providers, the NPI process into the EMS providers, product distribution, returns, and sourcing of some strategic components.
For these reasons, development and operations cannot afford the wall that has separated them in the past. Similarly, operations is under the gun to manage the requirements of new product development in light of its chosen EMS providers' agendas. Operations, as well as the EMS provider, must work closely with the development organization in the earliest stages of product design, both before and while components and suppliers are being selected. This will ensure that new products use the right supply base and are within the EMS provider's production capabilities. At the same time, a close working relationship will allow risks or problems to be identified early enough to be designed out or managed and mitigated.
No question, design engineering's sensitivity to supply chain issues must improve. At the same time, operations' sensitivity to the more complicated outsourcing environment and design's needs must also improve. Operations must also have a close relationship with their chosen EMS providers, with frequent and joint review and comprehension of each other's agenda, requirements, accomplishments, and issues.
Know Your Processes
While software companies and the electronics press have been singing the praises of Internet-based collaborative environments, these tools have little to do with true collaboration. All they can do is enable it. Collaboration has everything to do with knowing the purpose and goal of collaboration, the upside and downside of not collaborating, the stakeholders in the value chain and their agendas, and what aspects of product development they need to be involved in from the start. Some stakeholders might be collaborators even before product development begins - in the product strategy and roadmap development phase, for example.
Successful collaboration requires a much more process-oriented approach than the tools alone provide. Indeed, few collaborative tools appear to be more than just glorified FTP sites with security and project management overlaying Web-based meeting capabilities. These tools alone will not guide a dysfunctional development process onto healthy ground.
1. Supplier Oversight
All suppliers of direct materials are selected and managed based not only on their ability to produce components that meet the product design's requirements, but also on how well their roadmap matches the requirements specified or implied by the OEM's product roadmap, production and distribution capabilities, pricing, willingness to work closely with the OEM on product requirements, and so on. This philosophy extends to selecting an EMS provider as well. The complication is that now the OEM must know and be able to measure the relationship, if any, that the potential component supplier has with the EMS provider.
The commodity team is an enterprise-wide, cross-functional group with members from development and operations chartered with defining and managing the supply base for a given commodity. Commodity teams are often only implemented for component types that are considered strategic or problematic (e.g., ASICs, processors, power supplies, optical transceivers), but ensuring that de facto teams also exist for all other commodities is advisable. At least one person on the team should be an acknowledged internal expert on the component type. Teams meet periodically to review adequacy of the current supply base and respond to proposals to add or remove suppliers. This is a point for tight collaboration with the EMS provider.
Supplier approval is a formal mechanism for ensuring that consistent information is gathered and analyzed about potential suppliers for comparison to requirements and to each other. Downstream production risk is minimized by formally evaluating suppliers based on project, product, and enterprise needs. Finding out whether a potential supplier can meet your volume, delivery, or quality requirements - or whatever you consider important - before engaging with them is critical in defining the right supply base. Most OEMs do not perform on-site audits of their suppliers, and many suppliers provide self-audits to minimize the number of on-site audits customers and potential customers perform. However, on-site audits of strategic suppliers can be critical to understanding supplier capability as well as improving the working relationship between companies.
For instance, a design engineer at a large server OEM selected a supplier of strategic I/O components, around whose component the entire product was to be designed. The supplier is small, has little infrastructure, and little interest in supporting the extensive and broad informational demands placed on it by the server OEM because the volume upside is relatively low.
A team of auditors went to the supplier, bringing development executives along to help the supplier understand the OEM's vision and how its roadmap coincided with the OEM's, pointing out that volume would grow and become a long-term recurring revenue stream. They also explained how working with this demanding OEM will help the supplier better meet all its customers' requirements. A program management mechanism was put in place to centralize contacts and track responsiveness from both sides. The product was an enormous success, and the supplier has since grown in to a powerhouse in its niche.
The preferred supplier list is the output of commodity teams and supplier approval. Usually a controlled document, this is a key tool for development's use in selecting components during product design. While it does not guarantee problem-free product development, it minimizes the possibility of downstream problems and helps identify new suppliers early in the development cycle. Sharing the PSL and explaining its use to design partners will help avoid the type of problem described in example C, above. Early identification of risks like using products from unapproved (or worse, banned) suppliers gives everyone time to assess and mitigate the problems.
2. Design Oversight
New products often require new technologies from new suppliers. The sooner downstream stakeholders are aware of the possible need to bring on a new supplier and/or a new technology, the more time everyone has to evaluate the value/risk trade-offs and plot a course of action. Formalizing risk assessment and mitigation drives deeper understanding of production requirements in development and encourages a shared agenda within the OEM. It also tests the relationship with the EMS provider and its willingness, ability, and desire to contribute early in the design phase.
Periodic component reviews are the project's cross-functional, concurrent engineering forum for understanding component-related design requirements, recommending components, voicing component-related concerns, and issuing and resolving action items. These are usually called BOM reviews, but too many people expect a BOM to already exist in order to review it. Starting component reviews prior to component selection soon after the design has been partitioned and high-level requirements are known preempts poor decisions and saves time downstream.
Returning to example B at the beginning of this article, had the OEM had these two processes in place it would have certainly not had every component single sourced, and would have been able to bring its next product to market sooner since development would not have been distracted with the extensive support required for solving this problem.
Finally, newly selected parts must be given an internal part number for tracking and control. Having a formal new part request process to do that with sign-off results in reduction of redundant parts in the database and serves as a final gate for component decisions to be evaluated.
3. Component Oversight
Component manufacturers will always obsolete their components in order to manage their costs or improve performance and competitiveness of their products. These mechanisms ensure that changes will be taken into account as needed. Further, having a methodology for identifying, qualifying, and approving critical components as well as changed components will help ensure a production-robust product.
A robust methodology for component qualification and approval ensures that otherwise unforeseeable problems are identified early and resolved. At a minimum, component approval consists of obtaining data sheets and other collateral materials that allow comparison of a component's properties against the requirements.
Often, however, this is insufficient to gauge whether a component will work in a design. High-speed components from different manufacturers, despite equivalent datasheet parameters, can have wildly different signal characteristics. Understanding these and designing for them requires obtaining models and planning for in-board testing. Defining a broad range of possible actions for approval, then selecting them as required for each component proposed for use in a design, is part of this methodology.
As products have lifecycles, so do components. Component lifecycle management becomes a critical factor in maximizing product manufacturability and profitability when the two lifecycles do not match. Product lifecycles are often longer than certain component lifecycles so understanding the deltas between the two in the design phase of the project is key. Active lifecycle management of selected components must be done as a matter of course for most products, based on expected or unexpected changes to the components. Most suppliers notify their customers when a change is made or pending to a part; determining when and how this notification takes place is part of the supplier approval process. These product change notices (PCNs) can range from the inconsequential (implant levels changed to improve yield) to potentially devastating (end-of-life). Suppliers often equate customers with component purchases. Therefore, OEMs that outsource procurement are not considered customers, so they must make sure their EMS providers and distributors provide a timely forwarding mechanism for PCNs.
OEMs then must have a mechanism for handling and evaluating the impact of the PCNs on their production and procurement. If a single-source component is EOL, there are many possible courses of action, including product redesign, EOL buy, and second-source identification and approval. Missing a PCN is perhaps the most frequent cause of avoidable downstream product problems.
When a supplier changes or obsoletes a part, the OEM must capture and internalize that information. Components are managed by internal part number, each with its own list of approved manufacturers and their own part numbers. This is the Approved Manufacturers List (AML).
Change management requires ownership of the AML such that the effect of the change is understood across all BOMs that use that AML. Different designs may use the same component in a different manner. Approval for one BOM should not equate to approval for all. Thus any change to the AML must be reviewed in light of each application for which the component is used.
The lifecycle delta described above plays in to component reuse management. Is it always a good idea to reuse existing components (i.e., AMLs that are already approved and have an internal part number) in a new design? Rather than a simple “yes”, the answer depends upon lifecycle status, incremental demand, and current supplier preference status (among other things). Parts that have already been used in one product are, by definition, at a later part of their lifecycle than they were when they were first designed in. Assessing whether they're at or near end-of-life is an important consideration for the design of new, or modified, products. If the incremental volume from the new product will be substantial, the supplier's capabilities or ability to allocate adequate capacity should be understood. And if the preference level of the supplier has changed since the part was originally approved, the impact of that vs. the impact of finding a replacement supplier and part must be assessed.
Together, these three pillars, or tracks, help define a “safe design space” for the design engineer and a “safe component space” for the enterprise. Applying the processes outlined here will help an OEM manage its supply base in a strategic, disciplined, and conscious manner.
Once the enterprise has processes in place that drive a common agenda and help protect the company from poor technology or supply chain decisions, the right tools may provide a more effective means of achieving the goals of the processes.
Understanding collaborative touch points in the era of outsourced procurement, production, and product development is key to implementing a development process that will result in a robust, production worthy, supply chain ready product while improving time-to-market. Without the right processes, procedures, and relationships in place, the best tools alone can never produce winning results.
For more information or to align your design and supply chains, please contact us.