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.
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 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.
Einige der häufigsten Optionen in einem Entwicklungsprojekt sind:
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.
Für eine komplette Steuerungsentwicklung geben Firmen im Schnitt dreihundert Tausend bis zwei Millionen Franken aus. Dieser Betrag setzt sich zusammen aus:
Beachten Sie, dass sich der Aufwand für funktionale Sicherheit um Faktoren erhöht.
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.
Dies folgt aus dem magischen Dreieck des Projektmanagements: man kann immer nur zwei von den drei Zielen erreichen: minimale Zeit - maximale Qualität- minimale Kosten. Wählen Sie die zwei, die Sie Ihren Zielen am nächsten bringen.
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.
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.
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.
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.
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.
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:
Die Grösse der Bestellung bestimmt den Ansatz, da grosse Projekte eine dichtere Planung und dadurch eine höhere Gesamtauslastung ergeben.
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).
Es passiert häufig, dass verschiedene Schätzungen sehr unterschiedlich ausfallen. Dies kann aus verschiedenen Gründen geschehen.
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.:
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!
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 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.
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.
Andreas Stucki
Haben Sie zusätzliche Fragen? Haben Sie eine andere Meinung? Wenn ja, mailen Sie mir oder kommentieren Sie Ihre Gedanken unten!
Projekte? Ideen? Fragen? Machen wir einen kostenlosen Erst-Workshop!
Keine Kommentare