Jeder Verkäufer einer Software erklärt Ihnen, wie man mit seiner Software dafür sorgt, dass Geld gespart wird. Und es ist richtig, die Einführung von bestimmten IT-Systemen hat dafür gesorgt, dass Unmengen an Produkten schneller und oder besser hergestellt werden können.
Aber viel wichtiger – die Prozesse müssen passen.
Aber zunächst

In der Produktion

ist durch entsprechende Logistiksysteme, Maschinensteueranlagen, Lagerverwaltungssystemen etc. ein signifikante Veränderung über die letzten Jahre eingetreten.

Hier wird mit Akribie auf die Verkettung der Anlagen geachtet, Schnittstellen werden aufeinander abgestimmt, die Lagerhaltung mit sämtlichen Bauteilen und der entsprechenden Kontrolle über die Version des entsprechenden Objekts wird mit Argusaugen seitens der Controller betrachtet und kontrolliert.

Stiefkind Entwicklung:

im Gegensatz zur Produktion, in der sämtliche Artefakte einer sehr harschen Kontrolle unterliegen ist man in der Entwicklung oftmals weit vor jeglichem:

Jugend forscht.

Ich werde Ihnen im Folgenden einige Punkte auflisten welche in Ihrem Hause noch mehr Geld verbrennen als sie jemals mit einer super optimierten Produktionskette einsparen können.

Das Design bestimmt die Produktionskosten.

Alles was in der Entwicklung fehlerhaft designt wird – egal aus welchem Grund – kostet in der Produktion zusätzlichen Geld. Gerade wenn sie Serienprodukte entwickeln ist jeder noch so kleine Design Fehler ein Kostentreiber in der Produktion, egal ob es nun darum geht die entsprechende Maschine zu bauen, oder die entsprechende Wareneingangskontrolle zu tätigen, oder aber auch den Lieferanten regelmäßig zu überwachen.

In der Produktion streng, in der Entwicklung dilettantisch.

Grundsätzlich unterscheidet sich der Entwicklungsprozess nicht von einem Produktionsprozess. Es gibt einen signifikanten Unterschied, sie wissen vorab noch nicht wie das Produkt aussehen soll, sie sind ja noch in der Entwicklung.
Aber auch in der Entwicklung gilt es wie in der Produktion zu verfahren.

Die Wareneingangskontrolle.

Ist in jedem Produktionswerk Standard
Bei der Entwicklung ist die Wareneingangskontrolle (das Lesen der Kundenanforderungen) eher stiefmütterlich ausgebildet.
Der Vertrieb möchte verkaufen und verspricht das Blaue vom Himmel.
Es wird bereits akzeptiert ohne zu wissen was gebraucht ist.
Im Zuge der agilen Entwicklung vergisst man oftmals, dass man dem Kunden trotzdem gerecht werden muss und wenn sie in ein normatives Umfeld gehen, also dort wo sie Produkte herstellen welchen irgendwelchen Regulatorischen Vorschriften unterliegen, kann ich Ihnen nur wärmstens ans Herz legen die Eingangsdokumente ihres Kunden wirklich.

Die Richtige Version im Lager

Bau schon einmal etwas

mit dieser Anweisung würde in der Produktion ein riesiger Aufschrei entstehen, in der Entwicklung komischerweise nicht.
Wenn in der Entwicklung mit dem Kunden diskutiert wird, werden einfach mal ein paar Funktionsmodelle so gezimmert. Die entsprechenden Anforderungen des Kunden, selbst in einer Vorserienphase, oder in der reinen Prototypen und Entwicklungsphase werden einfach überhaupt nicht aufgeschrieben, oder aber überhaupt dokumentiert. Es wird mal einfach irgendetwas entwickelt.

Das grundsätzliche Forschen ist überhaupt kein Problem. Das Problem ist, dass Keiner wie auch immer noch geartet die entsprechenden Anforderungen sowie seine Gedanken irgendwo, irgendwie dokumentiert.
Selbst die typischen Besprechnungsprotokolle sind oftmals nicht einmal vorhanden.

Ich höre schon den Widerstand der Team-/Abteilungsleiter und auch der Entwickler, dass sie doch Entwickler und keine Dokumentatoren sind.

Während das grundsätzlich richtig ist, wird aber in einem jedem, in jedem, ich wiederhole: in jedem Buch, in jeder Vorlesung, in jedem standardingenieursmäßigen Prozess festgelegt, dass man die Anforderungen welche man erfüllen möchte irgendwo dokumentiert.

Das gilt auch in der agilen Welt. Auch dort gibt es grundsätzlich §Epics“,  User Stories und irgendwelche Test Fälle mit denen man seine Anforderung überprüft. In dem Falle gilt es hier die sogenannte „Definition of done“ zu nehmen.

Der Review.

In einem jeden Produktionsprozess würde man überprüfen ob die Bauteile welche man erhält überhaupt die Prüfung der letzten Station überstanden haben. Niemand käme auf die Idee ein Kunststoffbauteil mit einem Holzbearbeitungswerkzeug, oder ein Stahlbauteil mit einem Kunststoffwerkzeug zu bearbeiten und würde das Bauteil zurücksenden und sagen: „passt nicht“.

Dieser Vorgang nennt sich in der Entwicklung

Review

ist an sich überhaupt nichts schwieriges, es ist einfach bloß Arbeit. Wenn sie sich nicht hinsetzen und nicht überlegen ob sie eine Anforderung haben die überhaupt erfüllbar ist, die technisch sauber definiert ist etc. und die man auch überprüfen kann (Verifikationskriterien), dann werden sie nie ein vernünftiges Produkt bekommen.

In einem jeden Produktionsprozess macht man das, wobei es hier oftmals viel einfacher zu beurteilen ist und in der Entwicklung sagt man:
„Brauche ich nicht, geht schon so“

hier wird auf jeden Fall Unmengen an Geld verbrannt, weil man sich an die Basisprinzipien einer jeglichen ingenieursmäßigen Herangehensweise nicht hält.

Während der obige Revenue ein Prozess ist, der von Menschen durchgeführt wird, so gibt es aber ein Hindernis welches noch gravierender ist.

Datenkonsistenz

fast ein jeder Projektleiter den ich kenne kämpft damit dass er – meist über ein sogenanntes Projektmanagement Office – die Daten der Entwicklung zusammenführt und konsistent hält. (Was de facto NIE klappt)

Für jede Disziplin der Entwicklung gibt es eigene Werkzeuge, egal ob es das Anforderungsmanagement ist, das Projektmanagement, das Testen usw.

Daten Konsistenz und Rückverfolgung der Artefakte in der Entwicklung ist nicht gegeben und führt zu Chaos und extra Stress.

Hier ist die Kommunikation zwischen den einzelnen Abteilungen, unabhängig von irgendwelchen persönlichen Interferenzen, signifikant eingeschränkt.

Das Gesetz von Conway hat schon 1967 festgestellt, dass die Produktqualität zu dem Ausmaß beeinträchtigt wird, wie die Kommunikation im Unternehmen nicht funktioniert.

Wenn Sie sogenannte Toolbrüche haben, dann haben Sie dort auch immer einen Kommunikationsbruch.

Wenn sie es nicht schaffen über die gesamte Entwicklung hinweg konsistent zu bekommen fliegt es Ihnen in genau diesem Maße um die Ohren, wie die Daten nicht konsistent sind.

Stellen Sie sich das in der Produktion vor:

sie bekommen irgendwelche Teile angeliefert und den sie nicht wissen was es ist, und müssen regelmäßig per Hand diese Daten zusammenbauen. Ich glaube ein jeder Produktionsplaner ein jeder Controller würde hier die Hände über dem Kopf zusammenschlagen und schnellstmöglich für Abhilfe sorgen.

Datenkonsistenz in der Entwicklung

In der Entwicklung ist das scheinbar eine akzeptierte Struktur.

Es gibt Tools, welche es ihnen ermöglicht ihre Daten in „Echtzeit“ untereinander zu synchronisieren.

Wenn irgendjemand sagt, dass diese Synchronisation über die verschiedenen Tools hätten hinweg nicht möchte, so wissen Sie, dass er dafür sorgen möchte, dass sie signifikant mehr Geld in der Entwicklung ausgeben, schlechtere Produkte produzieren und was auch immer noch.

Wenn Sie es schaffen ihre Daten von der ersten Angebotsphase des Kunden über ihre Entwicklungsprozesse hinweg bis hin zur Übergabe in die Produktion zu optimieren und die Daten dort konsistent zu bekommen, egal welche Tools eingesetzt werden (müssen), so wird Ihnen das zu Anfang ein riesiges Kopfzerbrechen bereiten, die existierende Toollandschaft untereinander wirklich in den Prozess einzubinden, sowie den entsprechenden Prozess zu adaptieren. Aber sobald sie das einmal gemacht haben, sobald die Daten konsistent sind, wird es signifikant einfacher werden etwas in besserer Qualität in kürzerer Zeit mit mehr Spaß herzustellen. Fragen Sie wie das geht.