Supply Chain Management

Supply Chain Management Bild
Dieses Whitepaper enthält einige Design-Richtlinien und Ratschläge zur Reduzierung von Ausfallursachen und zur Vereinfachung des Designs, einschließlich Anwendungsbeispielen zur besseren Verständlichkeit.

Jetzt das ganze Whitepaper herunterladen

1. Vorwort

Dieses Whitepaper wurde in Verbindung mit einem anderen, ergänzenden, Whitepaper erstellt, das auf das Lieferkettenmanagement fokussiert. Auch wenn sich die beiden Dokumente in Bezug auf verwandte Themen ähneln mögen, so ist doch anzumerken, dass sich dieses Whitepaper darauf konzentriert, wie die im vorangegangenen Dokument genannten Ressourcen der Lieferkette verwaltet und die Verwaltung dieser Anbieter erleichtert werden kann.
HINWEIS: Der Begriff „Anbieter“ wird hier sehr weit gefasst und kann ebenso auf das interne Ressourcenmanagement einer Organisation zutreffen.

Mit anderen Worten: Während sich das vorige Whitepaper auf die Werkzeuge zur Durchführung der Machbarkeit konzentriert, rückt dieses Whitepaper mehr die Aspekte der Ausführung in den Fokus. Auch hier gibt es zwar einige Überschneidungen in den wichtigsten Themenbereichen, aber der Inhalt der beiden Whitepapers steht jeweils in einem differenzierten und bedeutungsvollen Kontext und sollte deswegen auch als solcher behandelt werden.

2. Es beginnt mit der Funktionsspezifikation

Alles – vom Design, über die Lieferkette, bis hin zu jeder anderen entscheidenden Abhängigkeit bei der Systementwicklung – beginnt mit einer ordnungsgemäßen Funktionsspezifikation (Spez.). Wenn die Messlatte nicht von Anfang an richtig gelegt wird, wachsen die Probleme/Risiken/Kosten mit fortschreitendem Zeitplan. Es ist üblich, bereits bei der Produktentwicklung Druck aufzubauen, um ein Design zu erschaffen, noch bevor die Spezifikationen vollständig ausgearbeitet sind. Dies gilt vor allem für kleinere/jüngere Unternehmen, wo die Ressourcen knapp sind und das Ende der Finanzierung oft in greifbare Nähe rückt.

Wenn es um die Entwicklung von Stromversorgungen und den dazugehörigen Lösungen geht, wird dieser Druck wahrscheinlich auf den Leistungselektronik-Ingenieur oder einen ähnlichen Team-Stakeholder übertragen, der in erster Linie für die Bereitstellung der Stromversorgungsinfrastruktur des Systems verantwortlich ist. Sie müssen diesem Druck standhalten und darauf bestehen, dass sich Systemarchitekten und andere Designpartner zusammensetzen und die notwendigen Diskussionen führen und nicht zu viele „TBD“ (To Be Determined)-Platzhalter für kritische Spezifikationen akzeptieren. Das soll nicht heißen, dass zu Beginn des Projekts ein Dokument (z. B. Datenblatt) von endgültiger Qualität erwartet werden sollte, denn im Laufe der Entwicklung kann noch einiges angepasst und optimiert werden, aber selbst der Entwurf einer Spezifikation sollte nicht so vage gewählt sein, dass er (qualitativ hochwertige, zeitnahe) Entwicklungen verhindert. Viele funktionale Anforderungen und Zertifizierungen liegen nicht in der Hand des Entwicklers/Eigentümers der Stromversorgungslösung, auch wenn er letztendlich die Verantwortung für die erfolgreiche Bereitstellung der Lösung trägt. Beispiele hierfür sind Richtlinien zur Leistungsreduzierung (z. B. IPC-9592, interne Konstruktionsleitfäden usw.), spezielle Zertifizierungen (z. B. EN51055, 80PLUS, EMC Class A/B, DoE Level VI, NEBS usw.), digitale Schnittstellen mit der System-SW/FW und ganzheitlichen Umweltszenarien (einschließlich Kompatibilität mit Höhenlagen und Verschmutzung/rauen Umgebungen). Hierbei handelt es sich nicht bloß um Aufkleber oder Stempel, um die Ästhetik des Produkts zu vervollständigen: Sie haben erhebliche Auswirkungen auf die Betriebsparameter (z. B. Mindestanforderungen an den Wirkungsgrad, höhere Betriebstemperaturen, robustere Stoß-/Vibrations-/Elektrizitätswiderstand usw.), die das Design vom ersten Tag an bestimmen können. Das Wichtigste ist, dass man unnachgiebig ist gegenüber anderen Beteiligten, die nicht verstehen, was sie verlangen, und denken, dass diese Fragen auch viel später im Entwicklungsprozess beantwortet werden können. Denn wenn etwas schiefgeht, erinnert man sich nur daran, dass die „Leistungsversorgungs-Person“ die Verantwortung für einfach ALLES trägt, was die erfolgreiche Auslieferung und Anwendung in der Praxis behindert.

Ein typisches Beispiel für diese Kommunikationslücken ist, wenn Stromversorgungs-Subsysteme ein digitales Berichtswesen implementieren (Kontrolle ist nicht notwendigerweise impliziert), was bedeutet, dass eine Stromversorgung über einen digitalen Bus mit dem System „sprechen“ kann und das System oft auch die Möglichkeit hat zu antworten. Die einzige Möglichkeit, diese beiden Komponenten so zu konzipieren, dass sie in der Anwendungsumgebung erfolgreich und robust arbeiten, besteht darin, dass die an der HW- und SW Entwicklung Beteiligten zusammenkommen, um ihre jeweiligen funktionalen Spezifikationen auszuarbeiten (eine für die Stromversorgung, eine für das System). Es ist unwahrscheinlich, dass der an der Stromversorgung Beteiligte über das Wissen und die Erfahrung verfügt, um die Eigenschaften des digitalen Busses, die Registerzuweisungen und die Formatierung von Fehlercodes (um nur eine kurze Auswahl aus einer langen Liste von Punkten zu nennen) eigenständig zu spezifizieren. Und es ist unwahrscheinlich, dass der SW/FW-Beteiligte über die Kenntnisse/Erfahrungen verfügt, um Fehlerschwellenwerte, Zustände/Verhaltensweisen der Stromversorgung und Schutzschaltungen zu definieren. Die Verringerung der Kommunikationslücke zwischen HW- und SW-Entwicklern (um nur ein Beispiel zu nennen) ist für die erfolgreiche Entwicklung einer minimal praktikablen funktionalen Spezifikation in nahezu jedem modernen System absolut notwendig.

Außerdem ist eine solide funktionale Spezifikation auch eine wichtige Voraussetzung für den Prozess der Angebotseinholung (RFQ/RFP), wenn ein Entwurf von Dritten ausgeschrieben wird. Alles – von den Stück-/Gewährleistungskosten (inkl. Qualität/Zuverlässigkeit), über den Entwicklungszeitplan und die Verfügbarkeit der erforderlichen Ressourcen, bis hin zur Lieferkette (AOS) und der finanziellen Überlebensfähigkeit sowohl des Anbieters als auch (in den extremsten Fällen) des Endbenutzers – wird durch die in der Funktionsspezifikation festgelegten Anforderungen bestimmt. Dazu gehören wichtige Punkte wie Sicherheits-, Compliance- und Zertifizierungsanforderungen sowie Design- und Qualifizierungsrichtlinien, die befolgt werden müssen.

Wenn Sie ein neues Projekt in Angriff nehmen, verfügen Sie dann über die nötigen Informationen, um eine ausreichende Funktionsspezifikation zu erstellen? Verfügen Sie über die entscheidenden Informationen von anderen technischen Gruppen, Programmmanagern und Stakeholdern der Lieferkette? Wenn das Marketing nicht in der Lage ist, ein Produktanforderungsdokument (PRD) oder ein gleichwertiges Dokument zu erstellen, wie können Sie dann erwarten, dass Sie eine angemessene funktionale Spezifikation für Lösungen entwickeln, um diese Anforderungen effektiv zu erfüllen? Es mag albern klingen, dies zu sagen, aber manchmal ist es wichtig zu hinterfragen, ob die Anforderungen/Spezifikationen, die diktiert werden, mit moderner Technologie (oder manchmal sogar mit der grundlegenden Physik) überhaupt pragmatisch machbar sind. Wenn Ihr Konverter ein Einschwingverhalten von 1MA/ns hat oder eine Betriebsumgebung von 500°C unterstützen muss, dann heißt es: Houston, wir haben ein Problem!

3. Arbeit mit Beschaffungs-/Rohstoff-Stakeholdern

Das vorangegangene, ergänzende, Whitepaper enthielt eine tiefergehende Analyse des Multisourcings, was es ist, wie es interpretiert werden kann, und einige (positive und negative) Überlegungen, um eine angemessene Bewertung der eigenen Ressourcen vornehmen und eine fundierte Entscheidung treffen zu können. Kurz gesagt: Die verschiedenen Überlegungen scheinen sich darauf zu beschränken, das technische Risiko zu mindern und nicht die Preisgestaltung zu beeinflussen. Zur Erinnerung: Die Zielsetzungen der Beteiligten (intern/extern, Technik/Lieferkette usw.) stehen in der Regel im Widerspruch zueinander – sowohl bei der Ausführung als auch bei den Prioritäten, von denen sie bestimmt werden. Im Folgenden werden wir diese Einschätzung aufgreifen und erweitern, um die Analyse in umsetzbare Strategien für bessere Ergebnisse umzuwandeln.

Wenn die endgültige Entscheidung für eine Multisourcing-Strategie gefallen ist, muss das Design Engineering in einem ersten Schritt die Liste der „kritischen Komponenten“ für die Analyse festlegen. Der Begriff ist in Anführungszeichen gesetzt, da die Charakterisierung dessen, was „kritisch“ ist, sehr subjektiv und variabel sein kann. Selbst eine Beschränkung der Definitionen auf „nur die Leistungskomponenten“ oder „nur die wärmsten Komponenten“ oder „nur Komponenten mit dem größten Sicherheitsrisiko“ führt oft zu Grauzonen und Meinungsverschiedenheiten. In jedem Fall ist es wichtig, eng mit den Teamkollegen zusammenzuarbeiten (insbesondere mit jenen aus den Bereichen Component/Reliability Engineering und Supply Chain Management), um die Kompromisse zwischen Leistung, Kosten, Time-to-Market (TTM) und AOS auszuhandeln.

Das Component/Reliability Engineering macht sich in der Regel wenige Gedanken um die Kosten, was bedeutet, dass es viele Qualifizierungs-/Lebensdauertests vorschreiben kann, die wiederum extrem teuer und zeitaufwändig sein können und Ressourcen von Dritten erfordern (immer wenn einem die direkte Kontrolle entzogen wird, erhöht dies das Risiko für die Entwicklung und den Zeitplan). Die erste Abstimmung mit diesen Interessengruppen über die Mindestliste der kritischen Komponenten (mit angemessenen Begründungen für die Annahme bzw. Streichung von Elementen auf dieser Liste) ist ein ausgezeichneter Ausgangspunkt, um das Risiko von etwaigen Zusatzkosten durch Dritte zu senken und den Zeitplan einzuhalten. Ein Beispiel für einen Kompromissvorschlag wäre, wenn eine Komponente mit mehr virtuellen/statistischen Methoden (z. B. Monte-Carlo-Analyse [1] oder Stichprobendaten des Herstellers) anstelle der weitaus umfassenderen thermischen/elektrischen Belastungs- und beschleunigten Lebensdauertests bewertet werden kann.

Bei physikalischen oder umwelttechnischen Tests muss nicht nur die Qualifikation der einzelnen Komponente berücksichtigt werden, sondern auch die Validierung in dem/den tatsächlichen System(en), für das/die sie bestimmt ist. Es scheint somit offensichtlich, dass die Bestimmung der Anzahl der zu testenden Baugruppen/Einheiten (DUT/UUT) angesichts der Anzahl der Stücklistenkombinationen für Leiterplatten (PCA), die mit jeder zusätzlichen Quelle exponentiell steigt, eine Herausforderung darstellen kann. Folgend einige Fragen, die berücksichtigt werden sollten:

  • Hat der Programmmanager eine ausreichende Anzahl von (Prototyp-)Prüflingen für die erforderlichen Tests vorgesehen (und damit auch budgetiert)?
  • Wie lange werden die Tests dauern und in welchem Stadium des Entwicklungszeitplans finden sie statt?
  • Wenn der Zeitplan sehr eng gesteckt ist, gibt es dann einen Notfallplan für den Fall, dass ein Prototyp die hochbeschleunigten Lebensdauertests (HALT) nicht besteht oder die Grenzwerte für elektromagnetische Störungen (EMI) überschreitet?
  • Stimmt dies mit dem Ziel der Freigabe der Stromversorgungslösung UND dem Ziel der Systemfreigabe überein?

Für Mitarbeiter des Lieferkettenmanagements stehen Möglichkeiten zur Kostensenkung wahrscheinlich eher im Vordergrund. Sie betrachten Multisourcing als hilfreiches Instrument zur Steigerung der AOS. Der letztgenannte Punkt wurde bereits im vorangegangenen Whitepaper erörtert und wird hier nicht wiederholt, dennoch sei erwähnt, dass die Verfügbarkeit von Komponenten und die Vorlaufzeiten zeilenweise geprüft werden sollten. Die Diskussion über die Bestimmung/Qualifizierung einer „kritischen“ Komponente wurde bereits weiter oben geführt, unterscheidet sich jedoch immer noch davon, wie eine Komponente aus einer zweiten Quelle als „gleichwertig“ mit einer primären Quelle eingestuft wird. Auch hier sollte man bedenken, dass dies ein sehr relativer Begriff sein kann (deswegen die Anführungszeichen), dessen Semantik unweigerlich mit dem Erfolg eines Jeden verbunden ist. Leider ist es heutzutage nur allzu üblich, dass die Gleichwertigkeit anhand einiger sehr grundlegender Kennzahlen wie Verdienstzahlen (Figures Of Merit – FOM) und Kosten (in der Regel mit sehr ungleicher Gewichtung) bestimmt wird.

Dieser Punkt ist zwar bei Komponenten, die empfindlicher auf Umwelt- und Anwendungsfaktoren reagieren (z. B. Halbleiterbauelemente), besonders wichtig, trifft aber genauso gut auf die einfachsten passiven Bauelemente (z. B. Widerstände) zu. Zwei verschiedene Quellen für einen Metall-Oxid-Halbleiter Feldeffekttransistor (MOSFET) können zwar das gleiche Gehäuse/den gleichen Platzbedarf, die gleiche Drain-To-Source-Spannung (auch bekannt als Sperrspannung) und die gleiche Gate-Spannung haben, aber dennoch drastisch unterschiedliche Gate-Ladungen oder Eingangs-/Ausgangskapazitäten aufweisen. Während dies für eine Schaltanwendung mit kleinen Signalen irrelevant sein mag, kann es bei einer Leistungs-FET-Anwendung den entscheidenden Unterschied ausmachen. Zwei verschiedene 1k-Widerstände im gleichen Gehäuse und mit der gleichen thermischen Leistung können sich in der Grundfläche, der Materialzusammensetzung oder der Art der Anschlüsse leicht unterscheiden. Die verschiedenen Quellen können unter der internen Teilenummer in der Liste der zugelassenen Hersteller (AVL) des Unternehmens immer noch als duale Quellen gekennzeichnet sein, was bedeutet, dass beide Quellen als austauschbar betrachtet werden, jedoch zu großen Leistungsrisiken führen.

Es ist ein natürlicher Prozess, dass man Regeln definieren möchte, um komplizierte Entwicklungen zu vereinfachen und Prozesse zu implementieren, die als Zeit-/Kostenoptimierung wahrgenommen werden können. Multisourcing ist jedoch einer der besonders heiklen Bereiche, in denen ein zu allgemeiner oder restriktiver Ansatz dem Erreichen der letztendlichen Projektziele zuwiderlaufen kann. Ein einfaches Beispiel dafür ist, dass für Entwürfe mit geringen Stückzahlen ein völlig anderer Ansatz gewählt werden sollte als für Entwürfe mit hohen Stückzahlen. Entwürfe mit geringen Stückzahlen sind in der Regel spezieller, können aggressivere/widerstandsfähigere Spezifikationen haben und sind weniger kostensensibel. Designs mit hohen Stückzahlen haben in der Regel strengere Qualitätsanforderungen, bergen ein höheres Risiko bezüglich der AOS, und die wirtschaftliche Rentabilität ist an streng kontrollierte Komponenten-, Herstellungs- und Qualifikationskosten gebunden.

Ein letztes zentrales Thema in dieser Diskussion über die effektive Verwaltung von Stakeholdern in der Lieferkette im Rahmen des Commodities Management bildet die Unterstützung des Business Continuity Planning (BCP) [2]. Beim BCP geht es um die Notfallplanung für größere Unterbrechungen, z. B. bei der Wiederherstellung nach einer Katastrophe oder bei der Abschwächung von Engpässen im Enterprise Resource Planning (ERP) [3]. Auch wenn es sich dabei in der Regel um Aufgaben für die Rohstoffmanagement-Gruppen und die mit ihnen verbundenen Ressourcen handelt, bewährt es sich immer, wenn die für die Energieplanung zuständigen Ressourcen/Eigentümer über diese Prozesse und die geplanten Maßnahmen im Falle einer Katastrophe, sei es aufgrund höherer Gewalt oder eines schwerwiegenden Versorgungsproblems (gesetzliche Vorschriften/Embargo/Zoll), auf dem Laufenden bleiben. Im schlimmsten Fall kann eine Naturkatastrophe …

Das gesamte Whitepaper lesen?