Einheit 14. HARA für den PoC, ein hybrider Vertrag und ein detaillierter Plan für das erste Epic

28. Oktober 2026 · Praktische Einheit · 1 Std. 34 Min. Grundlage sind das automatische Transkript IgorSikorskyKPI_28102026.mp4 sowie das draw.io-Diagramm und der Excel-Plan, die der Dozent während der Einheit erstellt hat. Dies ist ein redigiertes Lehrskript, keine wörtliche Abschrift: offensichtliche Erkennungsfehler wurden korrigiert und die Terminologie an frühere Einheiten angeglichen. Die Erfahrungen mit Herstellern und Lieferanten sind persönliche Praxis des Dozenten und werden ohne Firmennamen wiedergegeben. Redaktionelle Ergänzungen sind gesondert gekennzeichnet.

0. Organisatorisches

• Die Einheit wird aufgezeichnet; Video und automatisches Transkript stehen den Studierenden für ihre Notizen zur Verfügung.
• Die Arbeitsdatei mit den Diagrammen hat der Dozent auf Google Drive hochgeladen; nach Kursende werden die Materialien auf seinem Server mit einem Link auf der Website bereitgestellt.
• Als Ergebnis des Kurses ist ein methodischer Leitfaden geplant.
• Sicherheitshinweis: Bei Luftalarm vorsichtig sein und auf die eigene Sicherheit achten.

1. Wiederholung: Phasen, Gates und Unsicherheitskegel

Einheit 13 beschrieb, wie man dem Kunden einen Way of Work präsentiert: das Projekt in Phasen 1, 2, 3 … N teilen, die Offenheit für eine Fortsetzung (Support, Außerbetriebnahme usw.) betonen und ehrlich mindestens zwei Gates zeigen. Ein Gate ist ein Ausstiegspunkt:

• R&D war erfolgreich — weiter zum PoC;
• es ist gescheitert — das Gate erlaubt einen schnellen Ausstieg in einem frühen Stadium mit minimalem Verlust an Zeit und Geld für beide Seiten;
• oder man findet ein anderes Konzept und kehrt für Versuch Nr. 2, Nr. 3 an den Anfang zurück.

Je nach Projekttyp sollte man zumindest R&D und PoC nicht vergessen. R&D prüft die technische Machbarkeit beim heutigen Stand von Wissenschaft und Technik: Lautet die Antwort Nein, muss man andere Wissenschaft oder Technik suchen oder warten, bis sie reif ist. R&D verengt auch den Unsicherheitskegel: Je weiter ein Ereignis entfernt ist, desto mehr Annahmen trifft man und desto schwerer ist abzuschätzen, was man umsetzen kann, was es kostet und wie lange es dauert. Auch das muss dem Kunden in der R&D-Phase kommuniziert werden.

2. Was ein PoC bringt: die richtige Werkzeugwahl

Nach erfolgreichem R&D schlagen Sie dem Kunden einen Proof of Concept vor. Der Fokus liegt nicht auf Schönheit oder Fertigstellung des Produkts, sondern auf der Validierung Ihrer Entscheidungen:

Das Risiko, den PoC auszulassen, ist enorm: Man plant einen Chip ein, kauft ihn, entwickelt Elektronik, Gehäuse und Kühlsystem dafür — und dann „schafft“ er es nicht. Ein PoC kostet Geld, nimmt aber große künftige Risiken bei der Werkzeugwahl weg.

3. Was genau in den PoC kommt: HARA

Ein Projekt kann groß sein: eigene Hardware (Leiterplatten), Firmware darauf, Mechanik (das Gehäuse), in die alles eingebaut ist, ein Kommunikationsprotokoll zwischen Geräten, ein Desktop-Teil, die Cloud. Die Lehrtopologie: zwei physische Geräte in zwei Gehäusen, jedes mit eigener Elektronik, Chips und Firmware; ein Protokoll dazwischen; eine Firmware ist Master, und ein separater Rechner arbeitet als Gateway, der Daten zur und von der Cloud weiterleitet.

In den PoC kommt das Riskanteste — wo man „an den Pfosten schießen“ könnte. Um es zu finden, führt man eine HARA — Hazard Analysis and Risk Assessment (Gefährdungsanalyse und Risikobewertung) durch. Alle Ingenieure kommen zusammen (am besten vor Ort) und analysieren, was mit dem System passieren kann: wo man unsicher ist, was man noch nie gemacht hat, wo man Pionier sein wird.

Beispiel aus der Einheit:

Mit den HARA-Ergebnissen gehen Sie zum Kunden: „Im PoC möchten wir diese beiden Fragen untersuchen — sie erscheinen uns am gefährlichsten“, und belegen das mit Folien und der Tabelle. Die Reaktion des Kunden hängt von seiner Lage ab:

4. Wie eine HARA-Tabelle aussieht

Der Dozent zeigte eine typische Struktur einer solchen Analyse (das gefundene Beispiel war nach seinen Worten eher eine TARA — eine Bedrohungsanalyse der Cybersicherheit —, die Struktur ist aber dieselbe):

High-Risiken müssen analysiert werden; bei medium und low entscheidet man bewusst unter Berücksichtigung der Wahrscheinlichkeit. Zwei Beispiele:

• Ein Meteoriteneinschlag: sehr schwere Folgen, aber sehr geringe Wahrscheinlichkeit — das Risiko wird als niedrig eingestuft.
• Ein Pilot schläft am Steuer ein, der Autopilot ist aus: harte Arbeitsbedingungen machen die Wahrscheinlichkeit recht hoch, die Folgen sind schwer, also ist das Risiko sehr hoch.

Redaktionelle Anmerkung zum Pilotenbeispiel. Die Details, die der Dozent aus dem Gedächtnis nannte (Air France, Flug über Paris hinaus „fast bis Polen“), ließen sich nicht bestätigen. Dokumentierte Fälle, in denen beide Piloten einschliefen: Ethiopian-Airlines-Flug ET343 Khartum–Addis Abeba (August 2022) überflog sein Ziel, und die Besatzung wachte auf, als sich der Autopilot abschaltete und ein Alarm ertönte; ein Batik-Air-Flug Kendari–Jakarta (Januar 2024) — laut dem indonesischen Untersuchungsbericht schliefen beide Piloten etwa 28 Minuten, und das Flugzeug kam vom Kurs ab. An der Aussage des Beispiels ändert das nichts: hohe Wahrscheinlichkeit × schwere Folgen = hohes Risiko.

Redaktionelle Anmerkung zur Methode. Die vom Dozenten verwendete numerische Bewertung „Severity × Probability“ ist eine vereinfachte Risikomatrix im Stil der FMEA, praktisch für die interne Priorisierung eines PoC. Eine formale HARA nach ISO 26262-3 klassifiziert jedes gefährliche Ereignis nach drei Parametern — Severity (S0–S3), Exposure (E0–E4) und Controllability (C0–C3) — und bestimmt ASIL A–D oder QM. Die Bedrohungsanalyse der Cybersicherheit (TARA) ist in ISO/SAE 21434 beschrieben. Fällt das Projekt unter diese Normen, sollte eine interne PoC-Tabelle dem Kunden nicht als formale HARA oder TARA präsentiert werden.

5. Was mit dem PoC-Ergebnis zu tun ist

Die in der HARA ermittelten Risiken (hier: Protokoll und Überhitzung des Gehäuses) werden zu Untersuchungsgegenständen im PoC. Bestätigt sich das Problem, muss es gelöst werden — zumindest muss ein Lösungsweg gefunden werden:

• Lösungsweg gefunden — eine hinreichende Bedingung, um weiterzumachen;
• kein Weg gefunden — wir stoppen das Projekt oder wiederholen die Untersuchung.

Danach geht das Projekt Feature für Feature bis zum Ende weiter.

6. Ein hybrider Vertrag: was wir tun und was Lieferanten tun

Einheit 13 behandelte Fixed Price, Time & Material, T&M mit Obergrenze und ihre Kombination nach Phasen. Die Praxis zeigt eine weitere Variante — eine Aufteilung nach Verantwortung. Zurück zur Topologie mit zwei Geräten.

Wir konstruieren die Mechanik, entwickeln und prüfen die Hardware, unsere Mechanik- und Elektronikingenieure konstruieren den Kabelbaum — aber wir fertigen nicht: Es gibt keine Fabrik, keine Kompetenz, keine Techniker, die Kabel crimpen, isolieren und in Kabelkanälen verlegen. Die Fertigung geht an externe Organisationen. Ein Lieferant (Vendor) ist eine andere Organisation, die Ihnen gegen Geld eine Leistung erbringt: eine Fabrik, ein Zulieferer oder ein Spediteur.

Warum reiner Fixed Price auf alles ein Schuss ins eigene Knie ist

Reiner FP auf alles bedeutet, der Kunde will „in den Laden gehen und einen Eimer Kartoffeln kaufen“: bezahlen, warten und ein fertiges Produkt erhalten. Lieferanten stehen aber nicht unter Ihrer Kontrolle: Sie können Zeit, Qualität und Preis ändern. Der Dozent schilderte seine eigene Praxis:

All diese Glieder können gleichzeitig „mitspielen“, und der Postdienst multipliziert alles mit seinem eigenen Faktor an Verzögerungen und Preisänderungen. Am schlimmsten: Es ist ein physisches Produkt. Findet die Eingangsprüfung Mängel, verdoppelt die Nacharbeit sofort die Lieferzeit. Weigert sich ein Lieferant nachzuarbeiten, wird die Rechtsabteilung eingeschaltet — und das kostet wieder Zeit. Der Dozent betonte außerdem, dass ein Produkt selten in nur einem Land entsteht, sodass Krieg und Beschränkungen irgendwo auf der Welt die Lieferkette immer beeinflussen.

Fazit: Fixed Price auf den Fertigungsteil unter heutigen Bedingungen — nicht nur in der Ukraine, sondern in ganz Europa — ist für jedes Embedded-Projekt ein Schuss ins eigene Knie.

Wann FP auf den Lieferantenteil trotzdem möglich ist

Nur wenn Sie rechtlich abgesicherte Verträge mit Spediteur, Komponentenlieferant sowie den Herstellern von Hardware, Mechanik und Kabelbäumen haben. Verzögert ein Lieferant dann, gehen Ihre Unternehmensjuristen vor Gericht, und der Lieferant ersetzt die Verluste, die in Ihrem FP-Vertrag mit dem Kunden festgelegt sind. Heutige Hersteller kennen diese Risiken aber genau und werden einen solchen Vertrag fast sicher nicht unterschreiben. Und wenn doch, treiben sie den Preis hoch. Sie erhöhen Ihren, und der Kunde erhöht entweder den Preis seines eigenen Produkts oder verzichtet auf Sie.

Die empfohlene Aufteilung

Überzeugen Sie den Kunden, das Kooperationsmodell in zwei Gruppen zu teilen:

• In-house-Service — Software, Architektur, Manufacturing Review, Recht, Finanzen, Office-Management, Montage — zu fester Zeit und festem Preis;
• Komponentenbeschaffung, Fertigung von Elektronik, Mechanik und Kabelbäumen, Lieferung — auf Time and Material.

Dann gilt, wie das ukrainische Sprichwort sagt: „Die Wölfe sind satt und die Ziegen heil.“ Ihr Risiko und das Projektrisiko sind „leibliche Brüder“: Scheitert etwas, leiden beide Seiten. Wenn Sie das erklären, kommt Ihnen ein Kunde „bei klarem Verstand“ in der Regel entgegen. Moderne Kunden kennen dieses kombinierte Modell recht gut.

Das Projekt hat jetzt zwei Sicherungen: diese Verantwortungsaufteilung und die Gates nach riskanten Phasen. Zusammen halten sie Belastung und Risiko für Sie, den Kunden und die Lieferanten im Gleichgewicht.

7. Das Montage-Dilemma: auslagern oder selbst machen

Variante 1: Das Mechanikwerk übernimmt die Montage. Angenommen, ein mechanisches Produkt besteht aus etwa 120 Teilen: Front, Basis, Rahmen, Oberteil, innere Versteifungen. Sie schicken dem Werk die Konstruktionsunterlagen, dann stimmen der Technologe des Werks und Ihr Ingenieur den Fertigungsprozess ab: Biegen, Laserschneiden, Fräsen usw. Jede Maschine arbeitet etwas anders: Zwei identische Biegemaschinen biegen unterschiedlich, eine Lackieranlage ergibt einen leicht anderen Farbton. Deshalb dürfen Ingenieur und Technologe nicht nur eine Spezifikation austauschen, sondern müssen durchsprechen, was genau zu tun ist, damit sich das Produkt sicher montieren lässt und funktioniert. Der Dozent scherzte über die „Ziege“ (ukrainisch Kosa) — einen KPI-Spitznamen für die Konstruktionsnotiz, faktisch eine Spezifikation für ein bestimmtes Werk. Nach der Fertigung liefert Ihr Ingenieur die Montageunterlagen (Montageanleitung), und das Werk montiert das Produkt.

• Vorteil: Sie erhalten ein fertiges mechanisches Produkt.
• Nachteil: Der Preis steigt erheblich — für den Hersteller bedeutet das zusätzliche Verpflichtungen, Personal und eine Montagehalle, die er vielleicht gar nicht hat.

Aber die Montage hat drei Ebenen:

1. Mechanikmontage — aus einzelnen Türen, Rahmen usw.
2. Platinenmontage — Komponenten des Lieferanten werden auf die Leerplatine gelötet, es entsteht eine PCBA (PCB Assembly).
3. Produktmontage — die PCBA wird in die Mechanik eingebaut; danach wird die Firmware in das fertige Produkt geladen.

Genau diese Mehrstufigkeit brachte den Dozenten dazu, eine eigene Montagerolle zu schaffen — eine eigene Montageabteilung. Sie wird von einem Techniker besetzt, der zwei Kompetenzen hat: mechanische Montage und PCBA-Bestückung/Löten. „Wenn eine Funktion zweimal verwendet wird, ist es sinnvoll, daraus eine eigene Funktion zu machen.“

Hat der Techniker einen ordentlichen Arbeitsplatz, Lager und angemessenes Werkzeug — fühlt er sich also wohl und nicht wie „ein weißer Rabe im IT-Büro“ —, kann er auch einen großen Teil der Kabelbäume fertigen: Steckverbinder, Draht und Isolierung kaufen und die Kabelbäume nach Ihrem Entwurf bauen. Eine eigene Montagerolle:

• senkt das Fehlerrisiko bei der Mechanikmontage erheblich;
• eröffnet die Möglichkeit, die Kabelbaumfertigung ins eigene Haus zu holen.

Wozu brauchen Softwarestudierende das? Weil Sie ein System entwickeln: Software ist in einen Chip eingebettet, der Chip in eine Platine, die Platine in ein Gehäuse. Kaum jemand von Ihnen wird die Fertigung persönlich begleiten, aber zu verstehen, wie dieser Prozess aufgebaut ist, ist sehr wichtig.

8. Beispiel: zwei Geräte und ein Bedienerarbeitsplatz

Ein fiktiver Kunde möchte ein System aus drei Teilen:

• Gerät A — ein reales Produkt mit Halterung, Elektronik und Code; über Sensoren erkennt es, dass es montiert und eingeschaltet ist, und sendet seinen Zustand per Funk;
• Gerät B — empfängt diesen Datenstrom und gibt ein erkanntes Ereignis an den Rechner der Bediener weiter;
• der Rechner der Bediener zeigt, welche Aktion jetzt auszuführen ist: Item 1, Item 2, Item 3. Das genügt: Sehen die Bediener Item 1, führen sie die zugehörige Aktion aus.

Der Kunde hat es eilig, also ist der erste Schritt detaillierte Planung. Nach der Erfahrung des Dozenten ist Excel dafür das beste Werkzeug.

9. Ein detaillierter Plan für EPIC 1

Unten steht das Phasendiagramm, das der Dozent live erstellt hat. Die Gates G1–G4 stehen dort, wo das Ergebnis das Projekt stoppen kann.

Redaktionelle Anmerkung. In der Excel-Arbeitsdatei sind die Zeilen 23–24 und 26–27 mit „review / Review (Mech)“ bzw. „review / Review (HW)“ beschriftet. Nach der Erklärung des Dozenten in der Einheit lautet die Reihenfolge Montage → Review → Nacharbeit; daher sind sie hier als Review und Nacharbeit dargestellt.

Typische Fertigungszeiten aus der Erfahrung des Dozenten:

In dieser Zeit untätig zu sein, wäre „eine Sünde“: Genau dann sorgt man dafür, dass Komponenten und Werkzeuge verfügbar sind.

Ein Epic ist noch kein Projekt

Alles Beschriebene ist ein Epic. In der Embedded-Entwicklung mit Mechanik und Hardware gibt es nie nur ein Epic — mindestens drei. Deshalb wurde der Plan „eingefroren“: Der Dozent versprach, nächste Woche mit EPIC 2 weiterzumachen.

Praktische Schlussfolgerungen

• Ein PoC ist eine Investition, die das Risiko falsch gewählter Komponenten, Frameworks, Sprachen und Betriebssysteme beseitigt.
• Was in den PoC kommt, entscheidet eine HARA (und TARA), die das gesamte Engineering-Team durchführt.
• Die Risikoprioritäten werden dem Kunden gezeigt; er wählt den PoC-Umfang nach Budget und Risikobereitschaft.
• Ein gefundener Lösungsweg ist eine hinreichende Bedingung zum Weitermachen; wird keiner gefunden — Stopp oder erneute Untersuchung.
• Fixed Price passt zum eigenen Engineering-Service; Fertigung, Einkauf und Lieferung gehören zu T&M.
• Die Montage hat drei Ebenen; ein eigener Montagetechniker senkt Risiken und ermöglicht eigene Kabelbaumfertigung.
• Ein detaillierter Epic-Plan ist eine Kette von der Datensammlung bis zum Firmwaretest, mit Gates dort, wo das Projekt stoppen kann.
• Fertigungszeiten werden für parallele Beschaffung und Vorbereitung genutzt.

Fragen zur Selbstkontrolle

• Welche vier Arten von Entscheidungen validiert ein PoC?
• Wie wird eine HARA durchgeführt, und wer sollte teilnehmen?
• Welche Felder enthält eine HARA-Tabelle?
• Wie wählen Kunden in unterschiedlicher finanzieller Lage den PoC-Umfang?
• Wie unterscheidet sich eine vereinfachte Bewertung Severity × Probability von der Klassifikation S/E/C → ASIL nach ISO 26262?
• Warum ist Fixed Price auf den Fertigungsteil eines Embedded-Projekts gefährlich?
• Unter welcher Bedingung ist FP auf den Lieferantenteil möglich, und warum stimmen Lieferanten selten zu?
• Welche drei Montageebenen hat ein physisches Produkt?
• Warum lohnt sich eine eigene Montagerolle für das Unternehmen?
• Wo stehen die Gates G1–G4 im Plan für EPIC 1, und warum dort?
• Warum wird Hardware zweimal geprüft — von einem anderen Hardware- und von einem Firmware-Ingenieur?
• Was tut der Procurement Manager, während die Fertigung läuft?

Angekündigt

Für nächste Woche kündigte der Dozent an: EPIC 2 und weitere Epics, ein Gantt-Diagramm, die Teambildung, die Festlegung der benötigten Ingenieure und ihrer Profile, eine fiktive Einstellung und die Migration des Plans nach Jira. Dies ist ein angekündigter Plan, keine bereits gehaltenen Einheiten.

Materialien der Einheit

• Das draw.io-Diagramm der Einheit: .drawio herunterladen
• Der Excel-Plan für EPIC 1: .xlsx herunterladen

Geprüfte Links

• ISO 26262-3:2018, Road vehicles — Functional safety — Part 3: Concept phase: https://www.iso.org/standard/68385.html
• ISO/SAE 21434:2021, Road vehicles — Cybersecurity engineering: https://www.iso.org/standard/70918.html
• Batik Air, beide Piloten eingeschlafen (ITV News, 11.03.2024): https://www.itv.com/news/2024-03-11/plane-veered-off-course-after-pilots-fell-asleep-on-flight-report-says
• Ethiopian Airlines ET343 (The Tribune, 19.08.2022): https://www.tribuneindia.com/news/trending/both-pilots-fall-asleep-while-flying-at-37-000-feet-miss-their-landing-423279