Übung: Prüfung von Geschäftsmaterial und technischem Angebot

30. September 2026 · Übung · 1 Stunde 16 Minuten 22 Sekunden. Quelle: Transkript P3. Wegen Luftalarms und geringer Teilnahme wurde die Veranstaltung teilweise als Demonstration und individuelle Besprechung durchgeführt. Die erwähnte Wiederholung der Übung war ein Vorschlag, keine bestätigte Veranstaltung.

Die Einordnung dieser Veranstaltung in den Kurs

Am 29. September erhielten die Teams die Aufgabe, eine Corporate Identity, persönliche Kontaktkarten und einen One-Pager zu entwickeln. Am 30. September folgt die Überprüfung: Erfüllen diese Materialien einheitliche Anforderungen, und können sie tatsächlich eine technische Zusammenarbeit anbahnen? Im zweiten Teil wird der Ablauf nach einer Messe dargestellt: Anfrage → technisches Angebot → Machbarkeitsnachweis → gestufte Lieferung.

1. Überprüfung studentischer Visitenkarten: praktische Mängel

Der Dozent bespricht Materialien von zwei Gruppen. Positiv fallen eine einheitliche Farbpalette, Logo, definierte Rollen, geschäftliche Kontaktdaten, beidseitige Karten und QR-Codes auf. Ein grundlegendes Audit findet trotzdem Fehler: Nachname vor Vorname in englischer Beschriftung; unterschiedliche Farbsysteme für Visitenkarten und One-Pager; widersprüchliche Domains auf Karten und Poster; falsches Partnerlogo; eine unzutreffende Plattformabbildung; fehlende direkte Kontaktdaten auf dem One-Pager.

Dass es sich um eine Ausbildungsaufgabe handelt, entschuldigt solche Fehler nicht. Sie bilden typische Integrationsprobleme nach, bei denen zwei Arbeitsprodukte unabhängig entstehen, obwohl beide exakt dasselbe Produkt oder Unternehmen beschreiben sollen.

2. Funktionen und Verantwortlichkeiten in einem Ingenieurunternehmen

Die studentischen Rollen eröffnen die Diskussion über eine häufige, aber keineswegs allgemeingültige Unternehmenshierarchie:

Eigentümer → C-Level → Fachbereichsdirektoren → Manager → Ingenieure und Spezialisten.

Der Eigentümer besitzt das Unternehmen; der CEO leitet es im Rahmen seiner gesellschaftsrechtlich und intern festgelegten Befugnisse. CTO und CFO verantworten ihre jeweiligen Funktionsbereiche. Ein Direktor führt einen größeren Fachbereich und kann ein delegiertes Budget besitzen. Engineering-, Projekt- und technische Manager koordinieren Umsetzung und Eskalation; Ingenieure und Technical Leads erbringen fachliche Ergebnisse. Konkrete Entscheidungsbefugnisse und Budgets hängen von Unternehmen, Rechtsform und Richtlinien ab. Das ist ein Lehrbeispiel, keine Rechtsnorm.

Senior, Middle, Junior und Trainee kennzeichnen Qualifikationsstufen im Personal- und Vergütungssystem, nicht Managementpositionen und nicht automatisch eine Ausgabenbefugnis. Ein Lead Engineer sollte tatsächlich technische Koordination übernehmen, meist für ein Team, dessen Existenz und Verantwortlichkeiten das vorgeschlagene Organigramm widerspiegeln sollte.

3. Weshalb ein One-Pager nachweisorientiert aufgebaut sein muss

Die Besprechung zeigt Stärken studentischer One-Pager: erkennbare Ausrichtung auf Embedded Systems, ECU/ADAS/Verifikation als Kompetenzfelder, klare Aufgabenverteilung und die Fähigkeit zur Kleinserienfertigung. Zugleich können die Unterlagen überladen sein und zu wenige technische Bilderklärungen enthalten. Auch eine unscharfe Serviceliste ist problematisch: Automotive-ECUs und EV-Ladesäulen können beide legitime Geschäftsgebiete sein, sollten aber als unterschiedliche Richtungen dargestellt werden, jeweils mit einem nachvollziehbaren Bezug zur Kompetenz des Teams.

Entscheidende Prüffrage: Erkennt ein potenzieller Kunde innerhalb von zehn Sekunden am Messestand die Spezialisierung des Teams? Wenn nicht, muss die Informationshierarchie überarbeitet und die Verbindung von technischem Bild und Nutzenversprechen gestärkt werden.

4. Von RFI / RFQ / RFC zum Angebot

Nach dem Erstkontakt auf einer Messe und einem Folgegespräch kann ein potenzieller Kunde folgende Anfragen verschicken:

• RFI – Request for Information: Fragen zu Kompetenzen, Projekterfahrung, Werkzeugen, Ressourcen und Lieferfähigkeit des Unternehmens.
• RFQ – Request for Quotation: Anfrage nach Aufwandsschätzungen, Preisannahmen, Lizenzen, Ausrüstung und Auslagen.
• RFC – Request for Clarification: In diesem Kursszenario die Klärung des Vorgehens zur Lösung einer technischen Aufgabe, gefolgt von einem Angebot. In anderen Bereichen hat RFC andere Bedeutungen; der tatsächliche Kundenkontext ist maßgeblich.

Ein Proposal ist nicht bloß eine Preisliste. Es verbindet ein Ingenieurkonzept, den Verifikationsansatz, Lieferplan, Teamaufstellung und kommerzielle Rahmenbedingungen. In der Aufzeichnung präsentiert der Dozent ein anonymisiertes echtes Angebot für ein ECU Switching System, das nach mehreren technischen Gesprächen entstand. Zahlen und Projektgeschichten sind rückblickende Berufserfahrungen und keine für jedes Projekt gültigen Musterwerte.

5. Aufbau eines überzeugenden technischen Angebots

1. Executive Summary: Projektzweck, Mehrwert, geplante Phasen, voraussichtliche Dauer und Budget sowie Zusammenarbeitsmodell.
2. Glossar und Abkürzungen: Einheitliche Terminologie für Technik, Einkauf und Management.
3. Einführung und Kommunikationshistorie: Ausgangslage, Gegenstand, Vereinbarungen und Annahmen.
4. Anforderungsbasis: Erhaltene Dokumente und Referenzen, Anforderungen und offene Unsicherheiten.
5. Grobarchitektur: Systemstruktur, Schnittstellen, Datenwege, Stromversorgung und Steuerung.
6. Hypothesen für den Detailentwurf: Kandidaten für Module, Bauteile, physische Konzepte und Abhängigkeiten.
7. Validierung und Verifikation: Vorgehen, mit dem die geforderte Funktion nachgewiesen wird.
8. Phasen, Liefergegenstände und Terminplan: PoC, minimal nutzbares Produkt, Dokumentation, Meilensteine und Gantt-Diagramm.
9. Team und Ressourcen: Ingenieurrollen, Auslastung, Arbeitsreihenfolge und Kapazität.
10. Kommerzieller Rahmen: Festpreis oder Time & Materials, Ausschlüsse und Annahmen.
11. Anhänge und Versionshistorie: detaillierte Zeichnungen, umfangreiche Tabellen und Änderungsverfolgung.

Dies ist ein Beispiel für die Struktur eines Ingenieurangebots; einzelne Kunden können eine andere Reihenfolge verlangen. Der Dozent betont: Führungskräfte lesen wahrscheinlich zuerst die Executive Summary, technische Gutachter untersuchen dagegen Diagramme, Annahmen und Testmethoden. Im gezeigten Dokument mit 40 Seiten nimmt die Architektur einschließlich der detaillierten Modulaufteilung einen erheblichen Teil ein.

6. Architektur vor dem Vertrag: Verständnis des Problems nachweisen

In der Angebotsphase existiert noch kein fertiges Produkt. Ein modulares Konzept, CAD-Skizzen, Blockdiagramm, Schnittstellenbeschreibungen und ausgewählte physische Nachweise ermöglichen dem Kunden dennoch, die technische Machbarkeit einzuschätzen. Visualisierung muss fachliche Argumentation ergänzen: Ein Bild beantwortet „Wie könnte das aussehen?“, eine technische Skizze „Wie könnte es funktionieren?“.

Beim ECU-Switcher-Beispiel beschreibt der Dozent einen Machbarkeitsnachweis mit Evaluierungsplatine, UART-Kommunikation, experimentellem Prüfaufbau und Wärmebildaufnahme. Damit wird ein technisches Risiko frühzeitig reduziert; es ist kein Nachweis, dass das spätere Gerät bereits sämtliche Anforderungen erfüllt. Die veröffentlichten Notizen enthalten weder vertrauliche Kundenunterlagen noch kommerzielle Zahlen des Falles.

7. PoC → MVP → Dokumentation und Wiederholbarkeit

Ein Proof of Concept prüft eine riskante technische Hypothese. Ein Minimum Viable Product stellt jene Mindestfunktionen bereit, die bereits einen praktischen Nutzen erzeugen; dazu gehören ausdrücklich definierte Abnahmekriterien. Fertigungsdokumentation macht Montage, Prüfung und Support reproduzierbar. Jede Phase benötigt klar bestimmte Ergebnisse: Demonstrationsprotokoll oder PoC-Bericht, Liste abgenommener MVP-Funktionen sowie Quelldateien und Fertigungsanweisungen zur Reproduktion.

Illustrative Schätzgleichung (keine statistische Formel): E = Σ(rᵢ × tᵢ). Hier bezeichnet E die geschätzten Personenstunden, rᵢ die Zahl der Fachkräfte in Rolle i und tᵢ den geschätzten Aufwand pro Fachkraft dieser Rolle. Dies ist nur eine einfache Konsistenzprüfung des Ressourcenplans; eine Finanzkalkulation benötigt zudem Stundensätze, Reserven, Material und explizite Annahmen.

8. Geschäftsmodell und Änderungsverwaltung

Im Beispielprojekt wurde Time & Materials gewählt, weil die technische Aufgabe neuartig und der Umfang nicht vollständig vorhersehbar war. Das entbindet nicht davon, Budget, Dauer, Änderungen, Risiken und Arbeitsumfang zu überwachen und abzustimmen. Ein Angebot kann mehrfach überarbeitet werden. Nach der ersten Besprechung sollte ein Änderungsprotokoll Version, Datum, Änderung, Autor und Entscheidung des Kunden dokumentieren.

9. Aufgaben für Studierende und Abnahmekriterien

1. Jede Visitenkarte und jeden One-Pager anhand der Mängelcheckliste prüfen.
2. Ein kompaktes Organigramm mit Zuständigkeiten erstellen und die Aufgabe jedes Beteiligten erklären.
3. Ein lösbares Kundenproblem identifizieren und die eigentliche Anforderung von einer bevorzugten Technologie unterscheiden.
4. Ein Inhaltsverzeichnis für ein Angebot erstellen, das diese Anfrage beantwortet.
5. Die risikoreichste Hypothese auswählen und den kleinsten geeigneten PoC zu ihrer Prüfung definieren.
6. Überprüfbare Referenzen vorbereiten und fiktive Partnerschaften aus dem Rollenspiel nicht als real ausgeben.

Ergebnis: Das Team ist auf die realitätsnahe Simulation eines Kundengesprächs vorbereitet. Die nächste Veranstaltung behandelt Erstkontakt, Einwände und die Vereinbarung eines Folgetermins. Das ausführliche technische Angebot wird in einer späteren Phase ausgearbeitet.