Ein Leitfaden für die Entwicklungskosten von Embedded Software und Elektronik

Lesezeit 10 min

Eine der ersten Fragen, wenn Firmen Produkte mit einer massgeschneiderten Steuerung ausrüsten wollen oder ihre Software erweitern wollen, ist: Was kostet die Steuerungsentwicklung? Was kostet die Softwareentwicklung?

Obwohl diese Frage sehr schwer zu beantworten ist, werde ich hier versuchen, mein Bestes zu geben und einige allgemeine Orientierungshilfen zur Preisgestaltung zu erläutern:

Sind die Entwicklungskosten der wichtigste Entscheidungsfaktor?
Wie viel kostet eine embedded Steuerungsentwicklung? Wie setzen sich diese Kosten zusammen?
Wie kann ich bei der Produktentwicklung sparen? Ohne es später teuer zu bezahlen?
Und was ist mit dem Stundensatz?
Was heisst es, wenn Schätzungen stark voneinander abweichen?
Wie kommt eine Kostenschätzung zu Stande?

Mailen Sie mir für eine Kostenschätzung

Sind die Entwicklungskosten der wichtigste Entscheidungsfaktor?

Eine Produktentwicklung ist, wie der Kauf eines Autos oder besser der Bau eines Hauses, sehr individuell. Es gibt so viele Wahlmöglichkeiten, dass die Preisbereiche sehr stark variieren können.

Ein einfacheres Fertighaus beginnt bei weniger als 200'000 CHF, schnell kann man für ein Haus auch 700'000 CHF ausgeben, wenn man mehr Platz, bessere Bodenbeläge, Home Automation, Verkabelung, Infotainment, Wärmedämmung, bessere Küchengeräte, einen Kamin etc. wünscht.

Wieso sind so viele Leute bereit, für ein Haus oder eine Wohnung mehr als das absolute Minimum zu bezahlen? Weil sie verstehen, dass sie lange in dem Haus wohnen werden und es jahrelang bereuen würden, nicht das Richtige ausgewählt zu haben. Sie wollen sichergehen, dass ihr Haus ihnen die Sicherheit, den Komfort, die Wartungsarmut und die Langlebigkeit gibt, die sie wünschen.

Dasselbe gilt auch für die meisten embedded Entwicklungen.

Glückliche Kunden beim Aufsetzen einer Kaffeemaschine

Sie werden Ihr Produkt, Ihre Basis Ihres wirtschaftlichen Erfolges, jeden Tag für viele Jahre produzieren, verkaufen und warten. So ist es entscheidend, die richtigen Optionen, den richtigen Entwicklungspartner und die richtige Entwicklungsmethodik zu verwenden. Aus diesem Grund entscheiden sich die meisten Firmen für den Partner, mit dem sie über die ganze Lebens- und den Servicedauer des Produkts am glücklichsten werden.

Leider richten einige Firmen den Blick nur auf die ersten Entwicklungskosten. Sie haben das Ziel den billigsten Anbieter zu finden und verzichten auf Fehlerfreiheit, Qualität, Benutzbarkeit, Erweiterbarkeit, Wartbarkeit und Freude bei ihren Endkunden, was unweigerlich zu Bedauern führt. Vor allem, da ein entwickeltes Produkt nicht einfach wie ein Auto eingetauscht werden kann wenn man damit unzufrieden und davon enttäuscht ist.

Und was sind solche Optionen?

Einige der häufigsten Optionen in einem Entwicklungsprojekt sind:

Bedienung:
- LED
- Knöpfe
- numerische Anzeigen
- grafische Bedienung (GUI) inkl.:
  - eingebaute Bedienungsanleitung
  - Mehrsprachigkeit
  - benutzerspezifisches Design (Layout, Farben, Grafiken...)
  - Touch-Bedienung
  - Zugriffskontrolle (Benutzer, Administrator, Servicetechniker...)
Aktoren:
- Motoren
- Ventile
Sensoren:
- Temperatur, Druck, Feuchtigkeit
- Anwesenheit
- Distanz, Lage, Beschleunigung
Schnittstellen:
- Bluetooth
- WLAN
- NFC
- Mobilfunk
- Ethernet/ LAN
- USB
funktionale Sicherheit (Maschinenrichtline...)
IoT (Internet of Things) Funktionen:
- Software Updates über das Netz
- Fernwartung
- Identifikation
- Präventive Wartung
- Informationssicherheit
Zugriff über App auf Smartphone
Positionsbestimmung (GPS)
Zustandsprotokolle
Stromsparbetrieb/ Batteriebetrieb
CE, UL und Funk-Zertifizierung

Wie Sie sehen, gibt es viele Optionen. Das ist der Grund, wieso wir mit unseren Kunden in der Offertphase in einem Workshop diese Optionen klären und evaluieren. In dieser Phase und während des gesamten Projekts ist es uns wichtig, dass die Auswirkungen von Optionsentscheiden, insbesondere auf der Kostenseite, für Sie transparent und klar sind.

Wie viel kostet eine embedded Steuerungsentwicklung? Wie setzen sich diese Kosten zusammen?

Für eine komplette Steuerungsentwicklung geben Firmen im Schnitt dreihundert Tausend bis zwei Millionen Franken aus. Dieser Betrag setzt sich zusammen aus:

~ 10% Systemdesign (am Anfang des Projektes: 2..5%, der Rest während der ersten Hälfte des Projektes)
- Definition der Funktionen
- Definition der nicht-funktionalen Anforderungen: Zertifizierungen, Bedienbarkeit, Normen...
- Auswahl der Architektur/ des Aufbaus des Systems und Selektion der Komponenten
~ 10% Hardwareentwicklung und Hardwaretest
~ 60% Softwareentwicklung und Softwaretest
~ 10% Verifikation der Prototypen/ System-Integration und Systemtests
~ 5% Validation der Prototypen/ Feldtests
~ 5% Produktionseinführung inkl. Produktionstester

Beachten Sie, dass sich der Aufwand für funktionale Sicherheit um Faktoren erhöht.

Wie kann ich bei der Produktentwicklung sparen?

Ohne es später teuer zu bezahlen?

Um ohne Qualitätseinbusse und Folgekosten Entwicklungskosten zu sparen gibt es zwei Wege. Einerseits kann man die Entwicklung vereinfachen, d.h. weniger Features und Funktionen verlangen, andererseits kann man die Anzahl der Änderungen und Korrekturen verringern oder zumindest die Entscheidungszeit dafür, was nun genau wie geändert werden soll.

Wie vereinfacht man die Produktentwicklung?

Ansätze, welche eine Vereinfachung der Entwicklung verlangen, sind im Moment in Mode, z.B. MVP (Minimum Viable Product). Mit einem MVP den Markt zu erkunden und dann möglichst schnell ("agil") auf Kundenwünsche zu reagieren ist nur auf den ersten Blick im Widerspruch zu klaren Anforderungen am Anfang des Projektes. Denn jede einzelne Produktiteration als eigenes Entwicklungsprojekt profitiert bezüglich Geschwindigkeit und Aufwand von klaren Anforderungen und wenig Änderungen.

Was führt zu weniger Änderungen im Projekt?

Wenn am Anfang in einer effizienten System Design Phase ein klares Pflichtenheft entsteht, dann können die Änderungen im Verlauf des Projektes minimiert werden und damit auch der Aufwand. Die Durchführung und das Änderungsmanagement für die dennoch nötigen Anpassungen können dann iterativ erfolgen. Wenn im Gegensatz ein rein agiler Ansatz gewählt wird, dann braucht es beim Start des Projektes nicht sehr viele Entscheide, dafür ist der Aufwand für die Anpassungen der technischen Lösung grösser.

Wie starr ist das Pflichtenheft?

Das Pflichtenheft bildet die Grundlage für die Entwicklung und den "Single Point of Truth" für die zu erreichenden Ziele. Nicht jedoch ein Korsett, welches nicht mehr angetastet werden darf.

Über die Dauer der Entwicklung eines Produktes tauchen immer Änderungswünsche auf: vom Markt, aus der Entwicklung selbst und von anderen Stakeholdern. Solange diese den Rahmen des Projektes nicht sprengen, sollten diese unbedingt in das Pflichtenheft einfliessen, d.h. die Anforderungen werden angepasst.

Was ist die Rolle des Produktmanagements?

Sowohl Vereinfachung der Anforderungen wie auch Minimierung der Änderungen hängen mit einem entscheidungsfreudigen Produktmanagement zusammen, welches die volle Verantwortung für das Entwicklungsbudget übernimmt. D.h. es braucht ein Produktmanagement, welches eine klare Vorstellung der Anforderungen der Benutzer und Entscheider hat und welches auch bereit ist, Features mit einem schlechten Nutzen-Aufwand Verhältnis zu streichen.

Zusammegefasst...

Klare Anforderungen und Randbedingungen, wenige Änderungen, kurze Entscheidungszeit für Änderungen: das ist eine kurze Liste, die auch einfach umzusetzen scheint... In der Praxis sind die Entscheide und Aufgaben doch ziemlich umfangreich. Für eine effiziente Produktentwicklung braucht es daher in der Produktmanagement-Rolle nicht zu knappe Fach- und Führungskompetenz, genügend Entscheidungsspielraum und genügend allozierte Zeit für das Projekt.

Und was ist mit dem Stundensatz?

Im Prinzip sollten bei Entscheidungen für eine Produktentwicklung nur die Gesamtkosten über die Lebensdauer des Produktes eine Rolle spielen, nur zeigt unsere Erfahrung, dass der Stundensatz immer ein Thema ist.

Unsere Auffassung über Preisgestaltung ist folgende: Wir verrechnen für Projektleiter und Ingenieure, für alle Erfahrungsstufen und für alle Funktionen dieselben Sätze, so dass wir die Arbeit in Ihr Projekt und nicht in komplizierte Verrechnungsschemen stecken können. Dies tun wir, weil:

unsere Novizen und Anfänger nur 60 bzw. 80% ihrer Stunden auf Kundenprojekte verrechnen, was einer Reduktion des Stundensatzes entspricht
die meisten Architekten und Projektleiter auch Entwicklerarbeiten machen , welche wir Ihnen nicht überteuert berechnen wollen

Die Grösse der Bestellung bestimmt den Ansatz, da grosse Projekte eine dichtere Planung und dadurch eine höhere Gesamtauslastung ergeben.

Unsere Kosten werden von folgenden Faktoren bestimmt

Lohnkosten der Ingenieure, welche alle fix in der Schweiz angestellt sind
- bereits eine einfache Vollkostenrechnung ergibt da interessante Resultate
- beachten Sie, dass wir nur Ingenieure beschäftigen
Ausbildung, d.h. alle unsere Ingenieure sind Hochschulabsolventen
Weiterbildung der Mitarbeiter, denn Ihr Projekt verdient aktuelle Technologien und Arbeitsweisen
- wir investieren 5% und mehr der Arbeitszeit in die Weiterbildung
Berufserfahrung unserer Ingenieure, damit Sie echte Experten bekommen
- im Durchschnitt über alle Ingenieure 18 Jahre
Firmentreue unserer Ingenieure, damit Sie auch nach zehn Jahren noch Ihre Ansprechpartner im Projekt haben
- im Durchschnitt 11 Jahre
Prozesse, d.h. unser Qualitätsmanagementsystem damit Sie durch die ganze Entwicklung die optimale Qualität bekommen
- im letzten Jahrzehnt haben wir mehr als zwei Millionen Franken darin investiert
Und zu guter Letzt durch die Auslastung, welche nicht immer 100% ist
- wie hoch ist Ihr Gesamtauslastungsgrad?

In der Produktentwicklungs-Branche der Schweiz können Sie, vor allem im Hardware-Bereich auch 25% tiefere Ansätze als Solcept sehen, in der Software, funktionalen Sicherheit und vor allem auch der Projektleitung und für Architekten auch 25 bis 40% höhere.

Und: Stundensätze sind zwar einfach zu vergleichen, ein tiefer Stundensatz in der Entwicklung ist nicht immer ein guter Indikator für die Gesamtkosten über die Produktlebensdauer (TCO: Total Cost of Ownership).

Was heisst es, wenn Schätzungen stark voneinander abweichen?

Es passiert häufig, dass verschiedene Schätzungen sehr unterschiedlich ausfallen. Dies kann aus verschiedenen Gründen geschehen.

Die Aufgabe wurde nicht (gleich) verstanden

Dies ist der üblichste Grund, das Projekt und dessen Anforderungen wurden nicht in der ganzen Breite erfasst, oder gewisse Faktoren sind vergessen worden, z.B.:

Zertifizierungsaufwände (CE, UL, EMV, Maschinenrichtlinie, funktionale Sicherheit...) inkl. der damit verbundenen Dokumentation und Drittkosten
Produktqualität (Robustheit/ Stabilität), d.h. die Fehlerbehandlung wird weggelassen oder ist minimal und nur der Geradeausfall wird implementiert: so führen Eingabefehler des Benutzers, Fehler in den angeschlossenen Systemen, Montagefehler, Alterung, Bauelementtoleranzen etc. zu "unerwartetem Verhalten" und damit zu Zusatzkosten in der Form von Änderungs- und Servicekosten oder noch schlimmer zu Garantiefällen
Integration in das zu steuernde Gerät, d.h. die Kosten für das gemeinsame Debuggen des gesamten Systemes (keine Spezifikation ist so klar und unmissverständlich, dass die Integration reibungslos verläuft)
Qualitätssicherung der Hardware und vor allem der Software durch sinnvolles, risikobasiertes Testen (wenn möglich automatisch) und Review der kritischen Designs
Dokumentation und Design in einem sinnvollen Umfang, welche die Wartung und Erweiterbarkeit des Produktes ohne grosse Kosten während seines ganzen Lebens zulassen

Falsch gewählte Schätzmethode

Manchmal kann es auch darum sein, weil keine strukturierte Schätzmethode verwendet wurde. Lassen Sie sich immer die Schätzmethode und deren detaillierten Resultate zeigen, damit Sie die Qualität der Schätzung beurteilen können!

Die Verrechnungsmodelle sind unterschiedlich

Einerseits kann eine Kostenschätzung vom minimalen Projektumfang und von unklaren Anforderungen ausgehen und dann nach Aufwand/ iterativ/ agil durchgeführt werden. Dies kann zu Überraschungen und Nachverhandlungen führen, wenn es sich herausstellt, dass es zwischen Entwickler und den anderen Stakeholdern Missverständnisse über die Ziele gab.

Andererseits können alle Stakeholder sich über die Anforderungen klar sein, dass das Projekt zum Fixpreis durchgeführt werden kann. Dies führt, solange sich nicht neue Anforderungen auftun, zu keinen Überraschungen.

Ein Beispiel aus der Praxis zeigt, dass agiles Near-Shoring teurer zu stehen kommen kann als Fixpreis in der Schweiz.

Es liegen andere Geschäftsmodelle zugrunde

Es gibt Lock-In (Kostenfalle/ Abhängigkeit), in dem ein "politischer" Preis unter den realen Kosten für die Entwicklung offeriert wird. Der Gewinn wird im Nachhinein mehr oder weniger versteckt durch erhöhte Margen bei der Produktion der Elektronik oder für technische Änderungen an Soft- und Hardware erzielt. Der Kunde bleibt vom Anbieter abhängig, da er für seinen Preis nur das fertige Produkt oder den compilierten Binärcode bekommt.

Wenn eine Steuerung Herstellkosten inkl. Herstellmarge von 100 CHF hat und dazu eine versteckte Marge von 20% geschlagen würde, dann kann die versteckte Marge bei einer moderaten Jahresstückzahl von 1000 Stück über die Produktlebensdauer von zehn Jahren bereits 200'000 CHF ausmachen. Diese versteckte Marge wäre dann die Hälfte der Entwicklungskosten von 400'000 CHF, bei nur schon 2000 Stück pro Jahr würde sie bereits die ganzen Entwicklungskosten erreichen.

Das andere Modell ist das offene Geschäftsmodell, in dem der Kunden alles geistige Eigentum bekommt und in dem die Kosten für die Entwicklung transparent ausgewiesen werden. Dadurch werden die Kosten über die Lebensdauer geringer, da keine versteckten Margen abgezweigt werden können. Denn der Kunde kann mit den Quellcodes, den Schemas und den Layoutunterlagen plus den dazu gehörigen Dokumentationen selbst oder mit einem Partner seiner Wahl das Produkt herstellen, betreiben und weiterentwickeln.

Wie kommt eine Kostenschätzung zu Stande?

Selten ist ein Projekt schon aus der Dokumentation so klar, dass die Schätzung gerade beginnen kann. Daher findet zuerst ein Workshop mit allen Stakeholdern (Produktmanagement, Industrial Design, mechanisch Entwicklung, Marketing, Service etc.) statt, in dem alle Faktoren diskutiert werden, welche den Preis bestimmen.

Dieser Workshop wird in einem Dokument, dem gemeinsamen Projektverständnis zusammengefasst, in welchem das Projekt in den Worten der Software- und Hardware-Entwickler beschrieben wird. Dieses durchläuft eine Review bei den Stakeholdern und wird danach angepasst, wenn es Missverständnisse gab.

Erst dann wird eine Schätzung erstellt und dokumentiert. Der Kunde bekommt diese detaillierte Dokumentation der Schätzung (typischerweise mehrere Dutzend Punkte), welche in einem weiteren Workshop mit allen Stakeholdern optimiert wird. Dann entsteht eine kommerzielle Offerte für den gewünschten Projektumfang.