Interaktion statt Kooperation
Kooperation wird schon seit dem Ende des Fordismus als Gegengift zur Arbeitsteilung gepredigt. Sie bleibt nur leider so lange blutleer und inhaltslos als die Zusammenarbeit sich nicht in gegenseitigen Aufgabenstellungen niederschlägt. Oft wäre das technisch nicht weiter schwierig darzustellen. Es findet sich nur nicht in den Zielen der Fachabteilungen, die Fachexperten müssten sich anders Denkenden verständlich machen und die Verifikation von Ergebnissen läuft potenziell auch nicht mehr so glatt. Da ist es im eigenen Methodengarten schon gemütlicher. Das nutzen die Risiken natürlich aus, um an den organisatorischen Schnittstellen durchzuschlüpfen.
Zahlen-Daten-Fakten statt Glaubensbekenntnisse
Aus Fehleranalysen kann man lernen, dass die Grenze zwischen Wissen und Glauben stark von Erwartungshaltung abhängt. Naturgemäß erwarten Konstrukteure und Entwickler, dass ihre Technik funktioniert. Sie sehen das im Extremfall schon durch einen einzigen erfolgreichen Test als bewiesen. Dagegen verblassen gegenteilige Informationen sehr leicht. In diesem Nebel haben Risiken natürlich auch ein leichtes Fortkommen.
Die Abweichungen werden detektiert und die korrelierten Ursachen mit einem patentierten Verfahren ermittelt.
Im evolutionären Design, wenn sich die Innovation im Rahmen bekannter Bahnen fortent-wickelt, kann man dieses Rinnsal mit den etablierten Methoden im gewohnten Bett halten. Man kann (und sollte) also mit der Erfahrung denken.
Disruptive Technologie-Änderungen entziehen dem Erfahrungs-basierten Zugang aber weitgehend den Boden. In solchen Fällen ist es unvermeidbar, von Grund auf zu denken und radikal danach zu handeln. Das ist ungewohnt und unbequem, denn häufig kommt beim Denken etwas anderes heraus, als man gerne hätte. Aber es ist gesund, hält uns munter und es ist sehr effizient, weil man sich Risiken und Ausfallsmechanismen viel schneller vor stellen kann als sie in der Praxis zu erzeugen.
Man kann bei hoher Unsicherheit auch den steinigen Weg der Erfahrung gehen, also eine Reihe von Misserfolgen im Testbetrieb analysieren, um so festzustellen, wie das System im Detail funktioniert und wo seine Schwachstellen liegen. Das ist natürlich unschlagbar, aber wenn die Zeit limitiert ist sollte man den Großteil der Probleme denkend ermitteln und mit den Tests nur nach dem unbekannten Unbekannten fragen.
Fehler-Affinität statt Fehler-Aversion
Zuverlässigkeitsprobleme und -Ausfälle treten in der Regel mehrfach entlang der Entwicklungskette auf. Sie werden dann gerne kleingeredet, wegerklärt oder fortgeschwiegen, was sich ja gut machen lässt, weil die Tests übertrieben hart sind und Prototypen als Prüflinge verwendet werden müssen und der Prüfstand wohl ein Problem hatte, usw. Das kann natürlich alles sein – und es ist vor der jeweiligen Aktivität zu bedenken und auszuräumen und zu überwachen. Sonst wandern die Schwachpunkte mit dem Entwicklungsprozess in die nächste Generation und nach dem SoP zum Kunden, wo sie sich als Serienfehler zu erkennen geben.
In die Architektur der Software Suite Uptime SOLUTIONS sind diese Aspekte eingebaut. Sie liefert daher den organisatorischen Unterbau, der notwendig ist, um mit den Ergebnissen von Tests, Anlagen-Überwachung und Analytik tatsächlich höchste Zuverlässigkeit zu erreichen.