Innere Werte
Sie bringen Autofahrer nach Hause und Hochseeyachten sicher in den Hafen, sie halten Flugzeuge am Himmel und den Kühlschrank kalt, sie waren an der ersten Mondlandung beteiligt und stecken heute in jedem Fernseher, Handy und DVD-Player, in Druckerpressen und Werkzeugmaschinen, in Containerkränen und in Wäschetrocknern: Embedded Systems, zu Deutsch: eingebettete Systeme. So heißen die Kontroll-, Steuer- und Regulierungseinheiten, die in nahezu allen elektronischen Geräten oder Maschinen mit elektronischen Bauteilen Dienst tun – eben eingebettet in eine größere Einheit, für die sie eine bestimmte Funktion übernehmen.
Embedded Systems sind eine Kombination von Hard- und Software mit nahezu unbegrenzten Einsatzmöglichkeiten. In modernen Autos beispielsweise sind rund hundert unterschiedliche elektronische Komponenten samt Miniprozessoren an Fahrzeugfunktionen beteiligt, Ende der achtziger Jahre waren es gerade einmal zehn. Die Palette reicht vom Airbag über die Motorsteuerung und das Navigationssystem bis hin zu Stereoanlage und Öltemperaturkontrolle. Ebenso wichtig und häufig vertreten sind die kleinen Rechner in Produkten der Telekommunikation, der Luft- und Raumfahrt, in der Medizin- und Umwelttechnik sowie natürlich in der Unterhaltungselektronik – und ihre Bedeutung wird noch massiv zunehmen.
Davon ist Wolfgang Huhn, Director bei McKinsey & Company und Leiter der Wissensinitiative Embedded Systems, überzeugt. „All diese Branchen waren in der Vergangenheit traditionell stark bei der Entwicklung neuer Hardware-Komponenten. Innovationen spielen sich mittlerweile aber in erster Linie im Bereich der Software ab. Sie bietet den Firmen die Möglichkeit, flexibel auf Kundenbedürfnisse einzugehen und neue Funktionen und Features zu entwickeln. Und in Zukunft wird sich dieser Trend noch verstärken“, sagt Huhn. Allein im Automobilbereich betreffen 70 bis 90 Prozent aller Innovationen Elektronik und die zugehörige Software. Ein Riesenmarkt: Der Wert der Software in Automobil-Elektronik wird derzeit auf 25 Milliarden Dollar geschätzt, bis 2015 sollen es 100 Milliarden sein.
Der Haken an der Sache: Bei der Entwicklung von Software für Embedded Systems haben die Unternehmen noch längst nicht die Qualität und Produktivität der Hardware-Entwicklung erreicht. Das ist das Ergebnis einer Studie, die McKinsey im Rahmen von Workshops bei 35 Firmen der Automobilbranche in Europa und Japan erstellt hat. Weil die Zahl der elektronischen Komponenten aber stetig steigt und die Qualität bei der Entwicklung der entsprechenden Embedded Systems nicht Schritt halten kann, steigt auch die Fehlerquote in den Fahrzeugen. Damit wächst die Gefahr teurer und image-schädigender Rückrufaktionen – und wichtiges Innovationspotenzial bleibt ungenutzt.
Verantwortlich dafür sind zunächst einmal die schwierigen Bedingungen der Software-Entwicklung selbst. Allein die Komplexität der Systeme stellt eine kaum zu überwindende Hürde dar. Ein Auto durchläuft während der Entwicklungsphase rund 6000 Hardware-Tests – um die entsprechende Software mit allen funktionalen Kombinationsmöglichkeiten zu prüfen, wären sechs Millionen Tests nötig, das entspräche einer jahrzehntelangen Entwicklungszeit. Selbst mit zeitsparenden virtuellen Tests lassen sich nicht alle Varianten durchspielen. Software kann deshalb so gut sein, wie sie will, sie wird immer nur einen gewissen Reifegrad erreichen.
Hinzu kommt: Die Software in Embedded Systems muss wegen der engen Verbindung der Komponenten wie angegossen zur Hardware passen – Standardisierung ist nur in begrenztem Maße möglich. An der Hardware aber wird gespart, aufgrund des enormen Kostendrucks darf die Produktion keinesfalls noch teurer werden. Das weist der Software die Hauptrolle zu: Obwohl die Systeme auch unter extremen Belastungen wie Kälte, Hitze, hoher Luftfeuchtigkeit, Schlägen oder Vibrationen tadellos funktionieren müssen, ist es am Ende Aufgabe der Software, mögliche Fehlfunktionen zu verhindern.
All das macht die Sache kompliziert, die entscheidenden Ursachen für den Qualitätsrückstand in der Software-Entwicklung sind nach Ansicht von Jürgen Reiner allerdings hausgemacht. Der IT-Experte und Projektleiter von McKinsey attestiert Unternehmen eine Reihe von Versäumnissen. „Zum einen fehlt es den meisten schlicht an Erfahrung bei der Embedded-Software-Entwicklung. Sie sehen die enormen Potenziale, unterschätzen aber die Risiken. Daneben mangelt es an der Einstellung – es gibt genug Manager, die noch nicht verstanden haben, dass die Verbesserung der Software-Entwicklung oberste Priorität haben muss. Und schließlich zieht die Neufokussierung immer einen ganzen Rattenschwanz an notwendigen Veränderungen im Unternehmen nach sich. Das dauert seine Zeit. Und gilt übrigens nicht nur für die Autoindustrie: Hier treten die Folgen der Versäumnisse lediglich besonders auffällig für den Endkunden zutage.“
Auswege aus der Misere zeigt die McKinsey-Studie, die helfen will, die Qualität der Software-Entwicklung leichter messbar zu machen. McKinsey-Berater Reiner beschreibt den Ansatz so: „Bei der Entwicklung von Embedded Systems geht es um Features, um ganz genau definierte Funktionen eines Systems. Diesen Funktionen können wir auftretende Defekte zuordnen. Wir messen Fehler pro standardisierter Funktionseinheit, also Fehlerdichten, und haben damit ein normiertes Maß für Qualität – im Grunde können wir jetzt die Qualität eines Geschirrspülers mit der einer Getriebeeinheit vergleichen.“
In vier Bereichen identifiziert die Studie Ansatzpunkte, um Qualität und Produktivität in der Entwicklung eingebetteter Software und Systeme zu verbessern: bei der Systemspezifikation, der Systemarchitektur, den Prozessen und Werkzeugen sowie bei der Kooperation mit Lieferanten.
Bei der Systemspezifikation sollte laut McKinsey ein Grundsatz gelten, der so simpel ist, dass er eigentlich kaum erwähnenswert sein dürfte: Konzentriere dich auf die Entwicklung derjenigen Features, die der Kunde wirklich braucht oder will. „Leider wird dieses Prinzip ziemlich oft missachtet“, sagt Reiner, „klassische Beispiele dafür sind Funktionen bei Mobiltelefonen oder im Auto, die der Benutzer nie verwendet.“ Marketingfachleute, Ingenieure und Produktionsexperten eines Unternehmens sollten sich daher früh, vor allem aber während des gesamten Entwicklungsprozesses immer wieder über Nutzen und Einsatz der Systeme verständigen. Sonst riskieren sie Probleme – wie etwa der Autohersteller, der ein System entwickelt hat, das beim verschlossenen Auto nur genau die Tür öffnet, der sich der Fahrer nähert, während alle anderen Türen zu bleiben. Die technische Spielerei ist aufwendig zu realisieren, weil alle Türen individuell angesteuert und Komponenten quer durch das Fahrzeug miteinander vernetzt werden müssen. Die Folge: Die Belastung der Steuersysteme wächst, die Zahl der Fehlerquellen auch – und der Kunde bemerkt die Funktion im Zweifel nicht mal.
Bei der Auswahl eines Features müssen darüber hinaus so früh wie möglich alle weiteren Kosten bedacht werden, die im Laufe seines gesamten Lebenszyklus entstehen oder entstehen können, also beispielsweise für Tests, Herstellung und mögliche Gewährleistungsansprüche. Denn schon ein kleiner Fehler kann große Auswirkungen haben, weiß Reiner: „Ein Neuwagen-Modell war komplett lahmgelegt, weil eine winzige Bremslichtglühbirne kaputtging. Ursache war ein Sicherheits-Feature, das das Automatikgetriebe bei einer Fehlfunktion sofort abschaltete – offenbar war das Bremslicht mit derselben Steuereinheit verschaltet.“
Der Lebenszyklus ist entscheidend – aber schwer kalkulierbar
Die Fokussierung auf den Lebenszyklus ist aus der Integrierten Produktentwicklung hinlänglich bekannt. „Aber Integrierte Produktentwicklung hat sich immer auf anfassbare Hardware konzentriert“, sagt Reiner. Software-basierte Features seien dagegen so komplex, dass auch die Anwendung des Lebenszyklus-Prinzips deutlich komplizierter werde. Die Entwickler stünden vor zahlreichen Entweder-Oder-Entscheidungen, sagt Reiner. Viele Funktionen lassen sich sowohl im Hardware- als auch im Software-Bereich umsetzen – etwa die Geschwindigkeitsanzeige im Auto, die als Tachonadel (Hardware) oder als Head-up-Display (Software) realisiert werden kann. Für welche Option soll sich der Entwickler entscheiden? Ein ähnliches Dilemma gilt bei der Spezifikation: Wie soll der Lebenszyklus von Features berücksichtigt werden, die noch gar nicht existieren, aber später unverzichtbar sein werden, weil der Kunde sie will? Schließlich haben software-basierte Innovationen oft einen viel kürzeren Entstehungszyklus als das Produkt, in dem das Feature zum Einsatz kommt – ein Jahr für einen MP3-Player mit besserem Klang beispielsweise, fünf Jahre für ein Auto. Als Abhilfe für dieses Problem empfiehlt McKinsey, am Anfang bewusst zu viele Features einzuplanen und im Verlauf des Projektes diejenigen zu eliminieren, die am wenigsten den evaluierten Kundenwünschen entsprechen – Overloading nennt sich das.
Der zweite Bereich, den die Studie ins Auge fasst, ist die Systemarchitektur. Sie ist der Bauplan und beschreibt die Beziehung der einzelnen Komponenten eines Produktes zueinander. Idealerweise bietet sie eine effektive Lösung für die jeweiligen Anforderungen und ist möglichst simpel aufgebaut. Gleichzeitig muss sie flexibel genug sein, um für künftige Aufgaben angepasst werden zu können. Die Wahl der richtigen Architektur kann Qualität und Produktivität bei der Entwicklung von Embedded Systems in der Industrie entscheidend verbessern, meinen die Unternehmensberater. Grundsätzlich gilt: Je ausgereifter die Architektur, desto höher sind langfristig Qualität und Produktivität – entsprechende Investitionen in den Bauplan können allerdings zulasten der Entwicklung neuer Kunden-Features gehen, die kurzfristige Erlöse versprechen.
Eine optimale Reduktion der Komplexität ist zudem nicht ohne höhere Hardware-Kosten zu haben. „Die Firmen müssen sich der Trade-offs bewusst sein“, sagt Jürgen Reiner, „und bei jeder Architektur-Entscheidung Nutzen und Kosten genau abwägen.“ Dabei spielen auch die verschiedenen Einsatzgebiete der Embedded Systems eine Rolle. Bei der Steuerung eines Airbags zum Beispiel muss die Systemarchitektur extrem kurze Reaktionszeiten und unbedingte Zuverlässigkeit garantieren, bei einem Navigationssystem kommt es eher darauf an, dass sich innovative Features leicht integrieren lassen.
Die Zukunft gehört standardisierten Architekturkomponenten, davon ist McKinsey überzeugt. Denn die Vereinheitlichung spart Zeit und Geld. In der Autoindustrie können Hersteller so schneller auf wechselnde Marktbedürfnisse reagieren, da sie gleich auf mehrere Zulieferer zurückgreifen können, die mit standardisierten Komponenten die gewünschten Features in kurzer Zeit entwickeln. Den Zulieferern wiederum eröffnet die Standardisierung einen größeren Freiraum bei Entwicklung und Absatz eigener Innovationen – die Neuerungen lassen sich schneller erarbeiten und sind mit den Produkten der OEM kompatibel.
Die dritte Optimierungsdimension bilden Prozesse und Methoden bei der Entwicklung von Embedded Software. McKinsey empfiehlt kleine, bewegliche Teams, zusammengesetzt aus Vertretern unterschiedlicher Bereiche, allen voran Software-Entwickler und Hardware-Spezialisten. Sie arbeiten gemeinsam an jeweils einem bestimmten Feature, und zwar in kleinen Einzelschritten, deren Ergebnisse immer wieder überprüft werden. Das kann in der Praxis so aussehen: Ein Team aus Mitarbeitern von Hersteller und Zulieferer entwickelt ein Modul zur Optimierung des Fahrverhaltens, das Signale der Bremsanlage sowie der Motor- und Getriebesteuerung integriert und die Funktion der Getriebeautomatik und des ABS optimieren soll, erzählt Jürgen Reiner. „Dann fährt ein Testpilot des Herstellers stundenlang über eine Eispiste, begleitet von einem Spezialisten des Zulieferers, der mithilfe eines Laptops permanent die Daten prüft und Einstellungen optimiert. Und zwar so lange, bis es perfekt ist.“ Auch in dieser Konstellation sollen rigorose Zeitvorgaben für Zwischenziele garantieren, dass das Gesamtprojekt sich nicht verzögert. Ebenso strikt müssen sämtliche Entwicklungsschritte aller Beteiligten protokolliert werden, die kleinste Änderung muss auch nach Monaten noch nachvollziehbar sein.
Virtuelle Testmodelle können helfen, Millionen zu sparen
Das größte Potenzial für Verbesserungen der Prozesse und Tools sieht die Studie in der Anwendung virtueller Modelle, die das Zusammenwirken von Hard- und Software unter beliebigen Bedingungen simulieren. Digitale Modelle sind im Werkzeug- oder Maschinenbau schon lange Standard, haben aber erst in den vergangenen Jahren eine Qualität erreicht, die ihren Einsatz bei der Entwicklung von Embedded Systems ermöglicht. Mittelfristig können sie den teuren und zeitaufwendigen Bau von Prototypen überflüssig machen – die Untersuchung nennt als Beispiel ein Raumfahrtunternehmen, das durch den Einsatz eines virtuellen Testmodells bei der Entwicklung eines neuen Produktes 80 Millionen Euro gespart hat.
Zu guter Letzt hält McKinsey auch die Kooperation zwischen Herstellern und Zulieferern für verbesserungswürdig – eine Beziehung gegenseitiger Einflussnahme und Abhängigkeit, die ohnehin schon ständiger Abstimmung bedarf und bei der Entwicklung von Embedded Software noch enger werden muss. Denn Embedded Systems gehören zu den sensibelsten Teilen eines Produktes. Der Hersteller muss deshalb dafür sorgen, dass Zulieferer von Systemkomponenten bei der Systemspezifikation, der Architektur und den Prozessen dieselbe Sorgfalt walten lassen wie er selbst. Die Aufgaben zwischen Hersteller und Zulieferer müssen klar verteilt, immer wieder geprüft und gegebenenfalls angepasst werden, da sich im Laufe der Zeit Kapazitäten, Ressourcen und die Situation beider Parteien verändern werden. Was bedeutet, dass die Partner schon bei Projektbeginn den effizienten Austausch von Informationen institutionalisieren müssen.
Wer alle vier in der Studie behandelten Bereiche berücksichtigt, kann die Qualität seiner Systeme deutlich steigern – allerdings nicht von heute auf morgen. Und nie wird ein Unternehmen an allen Stellschrauben gleichzeitig drehen können. Die Firmen müssen „Kopf, Hand und Herz“ benutzen, meint McKinsey-Director Wolfgang Huhn. Kopf bedeutet, es muss klar sein, wann welcher Hebel betätigt werden soll, mit welchem Ziel und wie die Hebel einander beeinflussen. Die Hand steht für ein Management-System, das die Veränderungen konsequent umsetzt. Das Herz betrifft die Menschen und meint: Die Ziele können nur mit qualifizierten, engagierten Mitarbeitern erreicht werden.
Das kann in sechs Schritten gelingen, wie die Studie aufzeigt. Am Anfang steht eine umfassende Bilanz: Was leistet das Unternehmen momentan, wie steht es um Qualität und Produktivität? Wie sind Prozesse und Strukturen aufgebaut? Wie groß ist der Abstand zu den Besten der Branche, und wozu wäre die Firma künftig in der Lage? Danach entscheidet das Unternehmen, was es auf welchen Märkten anbieten will – das Produktportfolio wird definiert. Der dritte Schritt legt fest, bis wann die Ziele erreicht werden sollen. Anschließend muss das Management analysieren, welche Hebel es in Bewegung setzen will, um sich den Vorgaben entsprechend zu verbessern. Der Analyse folgt die Umwandlung der Unternehmensorganisation. Am Ende gilt es, alle vorangegangenen Schritte in einem Masterplan zu bündeln. Ob das Programm etwas taugt, lässt sich in einem Pilot-Projekt prüfen: Das Unternehmen wählt einen bestimmten Bereich aus, der verbessert werden soll, und testet dort die Auswirkungen der Veränderungsmaßnahmen. Mit der Chance, Fehler zu erkennen und den Plan anzupassen – so flexibel und exakt wie ein ausgereiftes Embedded System.
Dieser Text stammt aus unserer Redaktion Corporate Publishing.