Staffelstabübergabe

Sie brauchen kein Produkt, verkaufen Sie einfach das Lastenheft

020 – Wenn jeder in einem Projekt seine Arbeit in Ruhe fertig machen darf, bevor der nächste anfängt überhaupt nachzudenken, dauern Projekte ewig. Das könne und wollen wir uns nicht mehr leisten. Einer der wichtigen Begriffe hier: Concurrent Engineering. Also gleichzeitig entwickeln. Überlappend arbeiten. Nur, wie geht das und was kann passieren?

Jedes Bauteil hat viele Entscheidungen, die getroffen werden müssen. Nicht alle Entscheidungen werden aber zur gleichen Zeit gebraucht. Nehmen Sie eine Fluidführung. Die Funktion ist klar, es muss eine bestimmte Flüssigkeit in einer bestimmten Menge mit einer festgelegten Temperatur und Druck von A nach B. Dabei darf x an Druckverlust entstehen. Und das Bauteil muss Y an Umgebungsbedingungen aushalten (Vibration, Sonne, …).

Schlauch oder Rohr? Für die Funktion vielleicht egal. Gummi oder Metall? Auch noch nicht festgelegt. Normteil oder Eigenkonstruktion? Prüfkriterien? Farbe?

Lieferant? Herkunft für Zollfragen? Lagerort? Losgröße? Anlieferung ans Band? Was steht in der Montageanleitung? Was kommt in die Bedienungsanleitung? Wie ist die Ersatzteilversorgung geregelt?

Das alles muss für jedes Bauteil definiert werden. Sie sehen schon auch ganz schnell, wie viele Menschen an dem Bauteil mitarbeiten.

Ich muss die Funktion festgelegt haben, bevor in konstruieren kann. Ich muss die Konstruktion haben, bevor ich den Lieferanten auswählen kann. Oder doch nicht? Wie wäre es, sie würden den Lieferanten schon nach dem Konzept festlegen? Dann könnte der Lieferant mithelfen, das Teil zu konstruieren. Entweder ganz, oder mit seinem Wissen, wie so konstruiert wird, dass günstig gefertigt werden kann.

Aber wenn der Lieferant weiß, dass er das Teil liefern wird. Ist ja schließlich auch seine Konstruktion. Wenn er pfiffig war, dann hat er auch so konstruiert, dass er das gut fertigen kann, aber alternative Lieferanten auf dem Schlauch stehen würden und lieber anders bauen würden. Ja was macht dann dieser Lieferant in den Verhandlungen mit dem Einkauf? Er ist nicht sonderlich aufgeregt, wenn der Einkauf mit Alternativlieferanten droht. Bewegt sich also nicht. Und der Einkauf kommt sich hilflos vor. Schließlich lernt man doch als Einkäufer, dass eine gute BATNA hilft, eine gute Alternative hilft, ein gutes Verhandlungsergebnis zu bringen.

Die Konstruktion möchte gerne so früh wie möglich mit dem Lieferanten zusammenarbeiten, der Einkauf möchte eigentlich erst mit der fertigen Konstruktion die volle Verhandlungsmacht ausspielen.

Diese Abwägungen dürfen gemanaged werden. Wenn Sie Sich hier die Zeit nehmen, bewusst zu entscheiden, was sinnvoll ist: Früh zusammenarbeiten und Aufwand und Zeit sparen oder spät zusammenzuarbeiten und Einkaufsmacht erhalten, dann haben Sie einen großen Hebel in ihren Projekten. Meist entsteht hier irgendein verhalten und die kommerzielle Frage bleibt außen vor.

Schlimmer noch, wenn diese Entscheidungen nicht bewusst getroffen werden, dann streiten sich die Teams anhand ihrer Partikularinteressen. Eine Definition of done, eine Definition, was zwischen den Teams übergeben wird fehlt dann. Und wie immer in Projekten, wenn eine Übergabe nicht klar definiert ist und die Erwartungen nicht definiert sind, dann kostet dies Zeit. Zeit für Abstimmungsgespräche, die dann zum ungünstigsten Zeitpunkt anfallen und Zeit, die nicht im Projektplan aufgeführt ist, weil das Team, das doch mehr machen muss als gedacht, diese Zeit nicht eingeplant hat.

Diese Schnittstellen sind übrigens, warum ich empfehle die Kette Funktion, Konstruktion, Einkauf, Qualitätskontrolle, Erprobung, Fertigung auch innerhalb von Entwicklungsprojekten als Prozess abzubilden.

Ein Prozess zeichnet sich dadurch aus, dass es eine Kette von Arbeitsschritten ist, die in verschiedenen Teams gemacht werden, deren Zusammenwirken vorbestimmt und geklärt ist. Es wird also nicht für jedes Teil das Rad neu erfunden, sondern eben ein abgestimmtes Vorgehen abgespult wird. Sie sparen dadurch Zeit für Abstimmungen.

Da viele Teile, manchmal bis zu hunderte für ein Entwicklungsprojekt neu gemacht werden, lohnt sich der Aufwand, den Prozess zu definieren und zu optimieren.

Und mit dem Optimieren sind wir bei dem eigentlichen Thema der Folge: Was können wir machen, um schneller zu werden. Heute mit dem Hebel: Wann brauche ich welche Information?

Bleiben wir bei dem Beispiel der Schlauchführung. Wenn Sie einen Einkäufer haben, der den Markt für Schläuche kennt und weiß, welche Eigenschaften eines Schlauches beim Lieferanten was am Preis machen, dann ist das Risiko für diesen Einkaufsmitarbeiter geringer, ein schlechtes Verhandlungsergebnis zu erreichen, auch wenn er sich früh auf einen Lieferanten festgelegt hat.

Hat der Einkäufer dies nicht, so ist die Versuchung groß, sich andere Vorteile in der Verhandlung zu sichern, zum Beispiel damit zu drohen, zu anderen Lieferanten zu gehen.

Sie sehen an diesem Beispiel: Sie können sehr wohl Zeit sparen ohne großes Risiko, bei den Preisen über den Tisch gezogen zu werden. Sie müssen sich nur vorbereitet haben. Sind Sie das? Für welche Schlüsselkomponenten sind Sie das?

Ein anderes Beispiel: Die Entwicklung würde gerne mit dem letzten Prototypen sauber validieren, was die Maschine kann, damit die Versprechen dem Kunden gegenüber auch einhaltbar sind. Das Problem ist aber, dass diese Werte sehr spät in der Entwicklung wirklich fest werden. Der letzte Prototyp, der sich dann wirklich wie die Serie verhält ist halt erst kurz vor Fertigungsanlauf da. Meist auch erst mit dem Fertigungsanlauf und in der Investitionsgüterindutstrie ist es gar nicht so selten, dass der erste Zusammenbau der Maschine, so wie das Produkt ausgeliefert wird (mit allen Details, Hauben, Klappen, Zierelementen) dann für den ersten Kundenauftrag realisiert wird.

Das Produktmanagement würde die Werte aber gerne schon viel früher dem Marketing geben, damit es auch Werbematerial gibt, mit dem der Vertrieb dann losziehen kann, um eben diesen ersten Kunden einzuwerben.

Hier sind die Interessen diametral entgegengesetzt und je nachdem, was Sie für eine Kultur haben, hier mit Daten umzugehen, kann es sein, dass Sie sehr unterschiedliche Ergebnisse erreichen.

Nehmen Sie eine Entwicklungsmannschaft die sich dazu durchgerungen hat, sich auf Werte zu verpflichten, bevor alle Tests durchgelaufen sind. Sie waren mutig und haben den anderen ermöglichen wollen, ihre Arbeit zu machen. Sie haben auch sauber kommuniziert, dass die Daten vielleicht noch nicht ganz final sind.

Und jetzt kommt das, wo alle gehofft haben, dass es nicht kommt. Sie müssen die Werte ändern. Nicht viel, aber genug, dass die Versprechen in den Markt anders aussehen werden. Prospekte, Beispielrechnungen und Datenblätter müssen angepasst werden.

Wie gehen Sie damit um? Ist das ein Fehler, der nie wieder passieren darf? Dann wird er auch nicht mehr passieren. Sie erhalten das nächste Mal halt keine Daten mehr und schon gibt es auch keine Abweichungen mehr. Nur dann können auch die anderen Abteilungen nicht mehr arbeiten und schon wird Ihr Projekt deutlich länger.

Wir haben hier ein Beispiel für Unternehmenskultur und Qualität des Diskurses, der sich eins zu eins durchschlägt auf Ihre Projektlaufzeiten. Der sich über den Cost of Delay auch durchschlägt auf Ihre Wirtschaftlichkeit. Teilweise in erheblichen Umfang. Wie bewusst ist Ihnen das und steuern Sie diese Entscheidungen bewusst unter ökonomischen Aspekten?

Bleiben wir bei wirtschaftlichen Überlegungen. Wenn Sie Sich Ihre Entwicklungsprojekte überlegen und definieren sind die Wirtschaftlichkeitsrechnungen voll von Annahmen. Das sind alles Unsicherheiten, die Sie über das ganze Projekt mit sich herumschleppen und zu denen Sie Daten bekommen, wenn Sie das fertige Produkt dann erstmals an Kunden verkaufen. Sie bräuchten hier dringend bessere Daten früher im Projekt, haben sie aber nicht. Also machen Sie Annahmen und hoffen.

Schaun wir uns doch mal den Verkaufsprozess für Investitionsgüter an. Der Kunde hat eine Ausschreibung oder seine Anforderung in anderer Form formuliert und Sie machen dem Kunden ein Angebot. Der Kunde schaut sich die Angebote an, die er bekommen hat, bewertet nach seinen Entscheidungskriterien. Und will von dem Favoriten und vielleicht noch dem zweiten wissen, dass sie es auch wirklich können. Also, will mit anderen Kunden sprechen oder Referenzen sehen, um zu prüfen, ob die Versprechen zum Ergebnis passen und will die Fertigung und die Finanzen sehen, um zu prüfen, ob das Unternehmen auch liefern kann.

Zu keiner Zeit kauft der Kunde wie im Supermarkt, wo das Produkt fertig vor ihm liegt und er es anfassen kann. Das Produkt ist nicht da, es sind versprechen. Meist ist in der Investitionsgüterindustrie so viel customizing an den Maschinen dran, dass das, was dem Kunden versprochen wird noch nie genau so eins zu eins geliefert worden ist. Auch wenn das Produkt schon länger auf dem Markt ist.

Zu keiner Zeit muss das Produkt also fertig sein, damit der Kunde kauft. Aber wieviel Informationen benötigt denn der Kunde? Und wann liegen die Informationen vor? Brauchen Sie alle Versuche aus der Prototypenvalidierung oder geht es auch schon vorher? Muss das Produkt fertig konstruiert sein? Worauf kommt es denn an? Gehen Sie so weit wie möglich nach vorne und schauen Sie, womit Sie eine ernsthafte Diskussion mit dem zukünftigen Ziel-Kunden erreichen können.

Also, nehmen Sie das Lastenheft, das die erste Beschreibung ist, wie das Produkt aussehen wird, drucken Sie den Prospekt und fangen Sie an zu verkaufen. Nicht fragen, würden Sie das kaufen, dann bekommen sie Gefälligkeitsaussagen. Verkaufen. Verkaufen sie das Produkt, dass sie noch nicht haben (es hat dann halt eine längere Lieferzeit). Das Feedback, was Sie hieraus bekommen ist Gold wert zur Reduktion Ihres Marktrisikos und der Annahmen in Ihrem Projektauftrag. Und wenn Sie schonmal am Zuhören sind, vielleicht kommt ja noch die eine oder andere Anregung, die Ihr Produkt noch besser macht.

Das lohnt sich vor allem bei Produkten die einen etwas größeren Sprung in der Entwicklung machen und eine neue Technologie einsetzen. Viele Ingenieure fokussieren sich dann auf die neue Technologie und das damit zusammenhängende Risiko. Nur, dass eine neue Technologie auch die Parameter Ihrer Maschine deutlich verschieben kann und sie vielleicht auf einmal gar nicht mehr so interessant für Ihren Kunden ist, das wird nicht selten mit weniger Aufmerksamkeit bedacht.

Schauen Sie Sich an, zu welcher Zeit im Projekt sie wirklich welche Informationen benötigen. Und ob es nicht manchmal sogar besser ist, mit fast fertigen Informationen schon mal loszuarbeiten und Ergebnisse zu produzieren. Lassen Sie Sich nicht aufhalten, dadurch, dass noch nicht alles fertig ist. Schaffen Sie Werte und reduzieren Sie Risiken so früh Sie können in Ihrem Projekt. Aber fressen Sie Sich auch nicht gegenseitig auf, wenn es mal nicht klappt mit den ersten Annahmen und Sie nochmal nachsteuern lassen. Eine Fehlertolerante Kultur ermöglicht es Ihren Mitarbeitern mutig voran zu gehen, das Projekt zu beschleunigen und Ihren Gewinn zu steigern.