Viele Köche verderben den Brei

Artikel#: 00123

Datum: 2026-08-25

Autor: Radim

"Vier Augen sehen mehr als zwei..."
Meistens stimmt das.
Wenn wir ein komplexes technisches Problem lösen, ist es sinnvoll, mehrere Personen nach ihrer Meinung zu fragen. Jeder hat andere Erfahrungen, einen anderen Blickwinkel und kommt vielleicht auf eine Lösung, an die wir selbst nicht gedacht hätten. Je mehr erfahrene Leute wir fragen, desto grösser ist die Chance, eine passende Lösung zu finden.

Es gibt aber auch ein anderes Sprichwort:

"Viele Köche verderben den Brei."
Und auch darin steckt etwas Wahrheit.

Zunächst ist es wichtig, dass die hinzugezogenen Experten auch die grösseren Zusammenhänge verstehen. Einen Experten nur zu einer konkreten Frage hinzuzuziehen, ohne dass er den breiteren Kontext kennt, kann gefährlich sein. Seine Lösung kann für dieses eine Detail perfekt sein, für das Gesamtsystem jedoch falsch. Bevor wir jemanden nach einer Lösung fragen, sollten wir ihm deshalb die Möglichkeit geben, das Gesamtbild zu verstehen.

Ein weiteres Problem entsteht, wenn all diese Experten in unterschiedliche Richtungen gehen wollen und nicht klar ist, wer am Ende entscheidet.

Es ist gut, viele Leute zu fragen. Es ist gut, ihre Argumente anzuhören und verschiedene Möglichkeiten abzuwägen. Aber am Ende muss es eine Person geben, die sagt: 'Wir entscheiden uns für diese Variante.' Und diese Person muss nicht nur die Befugnis haben, diese Entscheidung zu treffen, sondern auch die Verantwortung dafür übernehmen.

1. Entscheidungsbefugnis ohne Verantwortung:

Es ist einfach, Ratschläge zu geben, wenn man die Konsequenzen nicht selbst tragen muss.
'Ich würde das anders programmieren.'
'Ich würde noch einen Sensor hinzufügen.'
'Warum macht ihr das überhaupt so?'
'Ich würde das ganze Konzept ändern.'

Solche Meinungen können sehr wertvoll sein. Sie können uns auf etwas aufmerksam machen, das wir übersehen haben, oder den Weg zu einer besseren Lösung öffnen. Deshalb sollten wir sie uns anhören. Aber ein Ratschlag ist keine Entscheidung.
Wer während einer halbstündigen Diskussion einen Vorschlag macht, ist in der Regel nicht derjenige, der sich einige Monate später mit den Folgen dieses Vorschlags auseinandersetzen muss. Er muss die Lösung weder umsetzen noch in Betrieb nehmen, ihre Kosten rechtfertigen oder dem Kunden erklären, warum sie nicht wie erwartet funktioniert. Seine Meinung sollte Gewicht haben - aber sie sollte ihm nicht automatisch das Recht geben, die Entscheidung zu treffen.

2. Verantwortung ohne Entscheidungsbefugnis:

Das andere Extrem ist genauso problematisch.
Jemand ist für das Ergebnis verantwortlich, hat aber keine wirkliche Möglichkeit, über die Lösung zu entscheiden. Andere bestimmen, was er tun soll, wie er es tun soll und welche Variante er verwenden soll. Wenn die Lösung aber nicht funktioniert, lautet die Frage: 'Wer ist dafür verantwortlich?'
Und plötzlich meldet sich keiner der Ratgeber mehr. Wenn es um die Verantwortung geht, richten sich alle Blicke auf eine einzige Person. Das ist keine echte Ownership.

Wenn wir von jemandem erwarten, dass er die Verantwortung für das Ergebnis übernimmt, müssen wir ihm auch die entsprechende Entscheidungsbefugnis geben. Und wenn wir jemandem die Befugnis geben, Entscheidungen zu treffen, müssen wir von ihm erwarten, dass er für diese Entscheidungen auch die Verantwortung übernimmt. Entscheidungsbefugnis und Verantwortung müssen Hand in Hand gehen.
Deshalb sollte meiner Meinung nach eine einfache Regel gelten: Wer entscheidet, muss die Verantwortung tragen. Wer die Verantwortung trägt, muss auch entscheiden dürfen.

Es geht nicht darum, Diskussionen einzuschränken oder anderen nicht mehr zuzuhören. Ganz im Gegenteil. Fragen wir erfahrene Leute. Suchen wir nach Alternativen. Diskutieren wir ihre Vor- und Nachteile und die damit verbundenen Risiken. Aber irgendwann muss jemand die verfügbaren Informationen abwägen, sich für einen Weg entscheiden und die Verantwortung dafür übernehmen.

Ask many. Listen carefully. Let one decide. And let the one who decides own the result.

© Radim-Automation, 2020–2026. Alle Rechte vorbehalten.
Die Verbreitung dieses Artikels ist mit Angabe der Quelle (Link zur Originalseite) ausdrücklich gestattet.

Verwandte vorherige Artikel:

• Die falsche Illusion des schnellen Fortschritts
• Engagierte Mitarbeiter
• Halte die Dokumentation während des gesamten Projekts auf dem neuesten Stand
• Mein Chef war ein Held
• Dokumentationsprobleme
• Erkenntnisse aus einem abgeschlossenen Projekt sind unbezahlbar
• Ein gutes Konzept = Kompletter Satz geeigneter Lösungen
• Gibt es auch Nachteile?
• Denke kritisch!
• Entwerft Maschinen mit Fokus auf die Fähigkeiten und Bedürfnisse des Benutzers
• Lerne von deiner Reise!
• Projektleiter
• Warum scheitern Automatisierungsprojekte?
• Sammelt alle Anforderungen und sortiert sie!
• Wer weiss es?
• Ernenne einen Vertreter!
• Schreibe deine Best Practices und Prozesse auf!
• Bereite einen guten Projektplan vor und halte ihn auf dem neuesten Stand!
• Ist der Weg wirklich das Ziel?
• Willst du damit wirklich beginnen?
• Ich sehe was, was du nicht siehst
• Mach die richtigen Dinge und mach sie richtig!
• Definiere kontinuierlich Testszenarien und Testfälle!
• Mach es nicht schlimmer!
• Schreibe ein Projekttagebuch!
• Behaltet die Antworten auf die Frage "Warum"
• Verwirkliche jede gute Idee so schnell wie möglich!
• Komm und bleibe im "Flow"!
• Industrielle Evolution - Höre eurem Kunden zu und folge neuen Trends!
• Bleibe wachsam!
• Hab einen Experten zur Hand!
• Was braucht der Kunde?
• Enttäuscht euren Kunden nicht!
• Stelle Fragen!
• Weise Aufgaben effizient zu!
• Fordere Bottom-Up-Input auf!
• Kommunikationsfähigkeiten sind äusserst wichtig
• Ersetze Mitarbeiter nicht in der Mitte des Projekts!
• Entwickle Verantwortungsbewusstsein!
• Rekrutiere und behalte die besten Mitarbeiter!
• Erledige die Dinge mit einem kleinen, motivierten Team!
• Konzentriere dich auf das Ziel!
• Vermeide allzu optimistische Schätzungen!
• 9 Frauen können ein Baby nicht in einem Monat zur Welt bringen
• Schärfe deine Axt, bevor du beginnst zu fällen!
• Verstehen - Einverstanden sein - Identifiziert sein - Glauben
• Verstecke kein Problem!
• Halte es einfach!
• Erfolg ist kein Zufall
• Gute Kommunikation ist wichtig
• Entwicklung ist Evolution

Verwandte nächste Artikel:

• Lass deine Mitarbeiter nicht warten

Kommentar#: 00001

Datum: 2026-08-27

Benutzer: Radim

Vor vielen Jahren, am Anfang meiner Karriere, arbeitete ich als Softwareentwickler an einem meiner ersten grösseren Projekte. Ich entwickelte ein zentrales SCADA-System für eine Maschine, die von mehreren SPSen gesteuert wurde.

Das Projekt war sehr gut geführt. Ein gutes Konzept, eine gute Dokumentation, klare Spezifikationen und ein realistischer Projektplan.

Zum SCADA-System gehörte auch eine BDE - Betriebsdatenerfassung. Wir sammelten Produktionsdaten in einer Datenbank, aggregierten sie und erstellten Statistiken: die Anzahl der produzierten Teile, die Anzahl der Maschinenstopps pro Schicht, den kürzesten und längsten Stillstand und ähnliche Informationen.

Auch dieser Teil war im Voraus durchdacht und gut spezifiziert.

Als ich jedoch mit der Programmierung begann, stiess ich auf ein Problem. Die Spezifikation berücksichtigte nur den optimalen Zustand, in dem alle Teile der Maschine in Betrieb waren und alle SPSen Daten lieferten. Aber was passiert, wenn ein Teil der Maschine absichtlich ausgeschaltet ist? Was passiert, wenn eine SPS eine Störung hat und keine Daten liefert? Was passiert, wenn die Kommunikation mit dem SCADA-System genau beim Schichtwechsel unterbrochen wird? Während ich all diese IF - THEN - ELSE-Anweisungen programmierte, wurde mir langsam klar, dass die Statistiken in solchen Situationen möglicherweise keine korrekten Ergebnisse liefern würden.

Ich wies darauf hin. Aufgrund der zugesagten Termine bekam ich jedoch im Wesentlichen eine einfache Antwort: "Die Funktion ist spezifiziert. Programmiere sie gemäss der Spezifikation." Also tat ich das.

Die Maschine wurde erfolgreich an viele Kunden auf der ganzen Welt verkauft und ausgeliefert. Mehrere Monate lang passierte nichts.

Dann rief mich eines Tages ein leitender Manager in sein Büro. Ich stand vor seinem Schreibtisch, und er erklärte mir, dass ein Kunde die Abnahme verweigerte, weil die statistischen BDE-Funktionen nicht richtig funktionierten, wenn einige Teile der Maschine ausser Betrieb blieben.

"Was sagst du dazu?"

"Ah... ich weiss", antwortete ich.

Er stand plötzlich von seinem Stuhl auf.

"Was? Du weisst das?"

"Ja. Ich musste es gemäss der Spezifikation programmieren. Situationen, in denen nicht die gesamte Maschine in Betrieb ist, wurden bei der Auswertung der statistischen Daten nicht berücksichtigt."

Er dachte einen Moment nach und sagte dann: "Gut. Dann wirst du das korrigieren. Und danach gehst du zum Kunden und weist nach, dass die Lösung korrekt ist. Du bleibst dort so lange, bis er bestätigt, dass das System funktioniert, und die Abnahme erteilt. Wie viel Zeit brauchst du?"

Wenn ich mich richtig erinnere, bat ich um ungefähr sechs Wochen für die Überarbeitung und eine Woche für die Installation und Tests beim Kunden.

Am Ende blieb ich zwei Wochen beim Kunden. Wir optimierten die letzten Details, der Kunde war zufrieden und erteilte die Abnahme.

An diese Erfahrung erinnere ich mich auch Jahre später noch. Als Junior tat ich damals genau das, was mir gesagt wurde. Ich implementierte die freigegebene Spezifikation. Und trotzdem sah ich bereits während der Implementierung ein Problem, das die Personen, die über die Lösung entschieden, nicht sehen konnten. Nicht, weil sie ihre Arbeit schlecht gemacht hätten. Bei einem komplexen System ist es sehr schwierig, jede mögliche Kombination von Zuständen im Voraus zu berücksichtigen. Manchmal erkennt ein Problem erst derjenige, der tief in die Implementierung einsteigt.

Und genau deshalb reichen eine gute Spezifikation, gute Experten und klar verteilte Aufgaben allein nicht aus. Es muss auch einen Weg geben, neue Erkenntnisse aus der Implementierung zurück zu der Person zu bringen, die die Entscheidungsbefugnis hat. Und diese Person muss bereit sein, eine Entscheidung erneut zu öffnen, wenn neue Informationen auftauchen.