Uhrwerk

Multiprojektmanagement – Ein System ist mehr als die Summe seiner Teile

Sie sind unglücklich mit Ihrer Entwicklungsabteilung

Vor allem sind Sie unglücklich mit dem Output. Sie entwickeln nicht schnell genug, Sie entwickeln nicht genug Produkte, Sie stehen unter Druck zu liefern. Der Druck ist schon hoch, für Sie und die Mannschaft und dennoch geht immer etwas schief. Ein Termin wird gerissen, eine Punkt des Lastenheftes fällt unter den Tisch, die Kosten sowohl des Projektes, als auch des Produktes laufen weg. Das wollen Sie verbessern, das müssen Sie verbessern. Aber wie, darüber will ich mit Ihnen heute reden.

Verspätung von Projekten

Kennen Sie das? Der Druck ist da und Sie wollen vertrauen zurückgewinnen, nein eigentlich ist es schon so weit, dass Sie Vertrauen gewinnen müssen. Und dann diese Nachricht: Das Projekt Charlie verspätet sich um 6 Wochen. Der bisherige Plan lässt sich nicht halten. Muss das gleich so eine große Verschiebung sein? Sie schauen sich den Plan selber an, lassen die Mannschaft berichten und ja, es wird länger dauern. Sie hätten nur gerne eine kleinere Verschiebung oder mindestens doch früher davon gewusst. Schließlich haben Sie vor drei Tagen der GF gerade berichtet, dass alles in Ordnung sei und jetzt das, 6 Wochen.

Das erste, was unter Druck auf der Strecke bleibt ist die Wahrheit. Keiner hat Ihnen das angekündigt, vielleicht haben sie es auch alle nicht gesehen, oder nicht sehen wollen. Aber das kann doch nicht sein, dass so etwas vom Himmel fällt.

Projekte dauern zu lange

Und wenn alle Projekte sich mehrfach verspäten, dann dauern sie auch zu lange. Erstens schon mal länger als geplant. Das kostet Glaubwürdigkeit. Das tut weh, weil damit das Risiko einher geht, dass alle Aussagen hinterfragt werden.

Zweitens länger als im Business case, der Projektergebnisrechnung vorgesehen. Die Projekte sind also wirtschaftlich schwächer als geplant, schwächer als gedacht. Also werden sie wieder hinterfragt. Es wird neu priorisiert, gestrichen, umformuliert. Nur was passiert eigentlich mit den Projekten, in die schon viel Blut, Schweiß und Tränen eingeflossen sind wenn sie angehalten werden. Schlimmstenfalls entstehen Zombieprojekte. Nicht lebendig und nicht tot. Es wird nichts mehr gemacht, aber die Ressourcen werden nicht sauber freigegeben. Auch in den Köpfen der Organisation. Eine typische Nichtentscheidung.

Besser die Projekte werden richtig beendet und abgewickelt. Die Ressourcen werden wieder frei, die Mitarbeiter können sich wieder neuem zuwenden. Aber wer einmal Blut, Schweiß und Tränen in ein Projekt gesteckt hat und zusehen muss, wie es gestrichen wird, der steckt das nächste Mal nur noch seine Arbeitsleistung rein. Auch das wirkt sich auf die Produktentwicklung aus. Von der Arbeitskraft, die einfach verpufft ist und nie Werte geschaffen hat ganz zu schweigen. Wir verdienen ja kein Geld mit einem halbfertigen Produkt.

Also doch besser keine Projekte streichen, nur was macht man mit einem Projekt, das bei neuer Betrachtung nicht mehr wirtschaftlich ist? Weiter machen oder einstellen? Dazu muss man sich anschauen, nach welcher Wirtschaftlichkeitsrechnung Sie diese Entscheidung stellen wollen.

Schauen Sie Sich die ganze Projektlaufzeit an? Also auch in die Vergangenheit? Und machen dann eine umfassende Wirtschaftlichkeitsrechnung und stellen fest: Mit dem Business Case würden Sie das Projekt so nicht starten. Nur, seien wir da ganz klar. Wer so denkt hat den grünen Tisch nicht verlassen. Sie haben nicht die Möglichkeit, die Zeit zurückzudrehen und zu entscheiden, ob Sie das Projekt machen oder nicht. Das war gestern. Diese Entscheidung ist hypothetisch. Sie hat in der Realität nichts zu suchen.

Die Entscheidung, die Sie heute fällen können ist einstellen oder weitermachen. Aber niemand wird Ihnen die bisherigen Kosten zurückgeben. Das sind sunk cost. Das Geld ist weg und niemand bringt es zurück. Wenn das Ihre Kultur ist, können Sie jetzt einen Schuldigen suchen, aber das ändert nichts an der Tatsache, dass die einzige Entscheidung, die Sie jetzt fällen können ist: Einstellen oder weitermachen.

Einstellen heißt: Geld ausgegeben haben, das keiner mehr zurückgibt. Und dafür null Gegenwert erhalten. Also abschreiben. Fehler gemacht. Aufstehen, aufräumen, weiter machen.

Oder weiter machen. Und weitermachen heißt weiter Geld ausgeben. Aber hier ist die Frage, was haben Sie schon geschafft? Wieviel ist noch zu tun? Und wenn Sie Sich anschauen, wieviel Sie noch ausgeben müssen und was sie dann zurückerhalten, nämlich den kompletten Erlös aus einem fertig entwickelten Produkt. Ist das Rest-Projekt dann nicht doch gut.

Es gibt Projekte, bei denen ist es die richtige Entscheidung, sie fertig zu machen, weil der gesamte Projektnutzen am Ende kommt, obwohl es keinen Sinn machen würde, sie anzufangen. Das klingt paradox, liegt aber an den sunk cost: Sie entscheiden darüber einen Teil der Kosten auszugeben, um den kompletten Erlös zu erhalten. Im Einzelfall ist das dann die richtige Entscheidung. Für das Unternehmen ist es aber fatal, wenn das häufiger vorkommt.

Wenn Sie so organisiert sind, dass sie immer tolle Projekte starten, die gut aussehen und die Firma nach vorne katapultieren werden, dann aber sich verspäten und die Kalkulation sich so verschiebt, dass Sie das Projekt nie hätten starten sollen, dann tun Sie Ihrer Firma nichts gutes. Dann machen Sie ein unwirtschaftliches Projekt nach dem anderen und das schlägt dann auch auf Ihr Unternehmen durch.

Besser Planen und mehr managen

Die offensichtliche Reaktion bei soviel Schlendrian ist es, die Zügel anzuziehen und mehr zu planen und mehr zu managen. Geht ja offensichtlich nicht ohne. Der Projektplan wird detaillierter, der Aufwand steigt, mehr Berichte, mehr Hinterfragen, weniger Vertrauen.

Aber wird das Projekt dadurch besser? Befriedigt das nur das Bedürfniss nach Zucht und Ordnung, oder ist das wirklich zielführend? Ich persönlich glaube da gar nicht daran, dass mehr Kontrolle hilft. Vor allem nicht, wenn das heißt, dass die Entscheidungen weiter oben in der Hierarchie gefällt werden. Das heißt nämlich nur, dass die Entscheidungen noch später kommen, die Manager sind ja ach so beschäftigt. Und sie werden häufig schlechter. Liegt auch an schlechten Entscheidungsvorlagen, aber hat meist damit zu tun, dass weiter oben in der Hierarchie weniger Wissen über die Details vorhanden ist und dadurch Entscheidungen hier häufig mal unerwünschte Nebenwirkungen haben. Es hat einen Grund, warum in normalen Zeiten, die Entscheidungen so nah an der Arbeit wir möglich gefällt werden.

Aber unterstellen wir einfach mal, dass sich manche Projekte besser benehmen, wenn sie stärker kontrolliert werden. Dann haben wir immer noch den ganzen Overhead durch mehr Planung und mehr Kontrolle, der unser Projekt und die Arbeitsleistung belastet. Das kann eine gute Investitions sein, aber ändert nichts daran, dass in einer angespannten Zeit, jetzt noch weniger Ressourcen in die inhaltliche Arbeit gehen und mehr verwaltet wird.

Kompliziert und Komplex

Sehr spannend ist in diesem Zusammenhang die Frage, welche Projekte denn überhaupt geeignet sind, von mehr Planung zu profitieren. Ein einfaches Problem wird Sie nicht so schmeißen, dass Sie in die Verzweiflung kommen, es mit großem Projektmanagementoverhead zu bändigen. Die fallen raus. Die komplizierten Probleme, die sind es doch, Das hieße ja, das Sie vorher wissen, was Sie Schritt für Schritt machen müssen. Sie haben eine Ursache Wirkungsbeziehung und auch wenn Sie etwas komplizierter ist, so ist sie doch grundsätzlich durch Analyse erschließbar.

Viele technische Probleme sind so. Wenn Sie den Weg haben, ist es vielleicht aufwändig ihn zu gehen, aber ihn zu gehen führt berechenbar zum Erfolg. Also sauber planen, sich nicht belügen und dann abarbeiten. Je weniger vom Pfad der Tugend abgewichen wird, desto besser der Erfolg.

Aber es gibt auch andere Probleme, die wir im Rahmen der Produktentwicklung zu lösen suchen. Das sind die sogenannten komplexen Probleme. Komplexe Probleme haben die Eigenschaft, dass Ursache und Wirkung zwar beobachtet werden kann aber nicht im Vorfeld analysiert werden kann, weil die Kausalität unbekannt ist. Sie entzieht sich also der Planung. Sie können nur versuchen und beobachten und daraus lernen.

Projektmanagement ist zutiefst ein Werkzeug der Lösung komplizierter Probleme. Für komplexe Probleme eignen sich die agilen Methoden, die sich gerade in der Softwareentwicklund durchgesetzt haben. Software ist komplex. Gerade die Schnittstelle zum Menschen ist hier besonders davon betroffen, da menschliches Verhalten zu tiefst komplex ist.

Aber auch im Maschinenbau werden Produktentwicklungsprojekte immer mehr Lösung von komplexen Problemen. Gerade in Märkten, die schon länger keine Anbietermärkte mehr sind, sondern Nachfragermärkte ist gerade die Frage, ob die Kunden ein Produkt kaufen eine komplexe Sache, die am besten ausprobiert wird und die sich entsprechend der Planungssicherheit entzieht.

Je mutiger desto komplexer und desto weniger planbar

Und nicht zuletzt sind gerade die von Komplexität betroffen, die in ihren Produktenwicklungen große Schritte machen. Neue Technologien entwickeln oder erstmalig einsetzen, neue Märkte oder Nischen erobern, neue Vertriebskanäle und Supply Chains ausprobieren. Gerade diese mutigen großen Schritte sind besonders unberechenbar und vorhersagbare Ursache-Wirkungs-Beziehungen versagen.

Also gerade diejenigen, die besonders mutig vorangehen, können sich am wenigsten durch mehr Planungsoverhead den Erfolg kaufen. Die Unsicherheit lässt sich in komplexen Situationen nicht wegplanen.

Starten starten starten

Wenn einzelne Projekte unsicherer werden, dann lässt sich das Risiko doch durch mehr gleichzeitige Projekte auffangen. Frei nach dem Motto, eins wird schon durchkommen. Am grünen Tisch heißt diese Strategie nicht alle Eier im gleichen Korb haben. In der Praxis bedeutet dieses Vorgehen, dass wir die Unfähigkeit ein Projekt pünktlich abzuliefern als Begründung dafür benutzen, mehrere Projekte zu starten. Als ob dadurch, dass sich die Arbeitszeit und Aufmerksamkeit auf mehrere Projekte verteilt, gesichert wäre, dass die Projekte jetzt besser laufen.

Einstein wird das Zitat zugeschrieben: “Die Definition des Wahnsinns ist, immer dasselbe zu tun und ein anderes Ergebnis zu erwarten.”

Der Wunsch ist verbreitet, bei nicht funktionierenden Projekten wenigstens eins zu haben das funktioniert. Und wenn alle mehr oder weniger notleidend sind, dann ein neues anzufangen, bei der der Business case noch nicht mit der Realität kollidiert ist.

Schlechtestes bekommt Aufmerksamkeit

Es ist häufig auch so, dass bei mehreren Projekten genau dasjenige die gesamte Managementattention, also diese knappe Ressouce Aufmerksamkeit hat, das am schlechtesten läuft. Und damit da Ruhe einkehrt, werden dann so lange Ressourcen verschoben, bis ein anderes Projekt tiefer in der Tinte steckt.

Kennen Sie diese Geschichte von Krebsen im Eimer? Frisch gefangene Krebse im Eimer wollen wieder zurück ins Wasser und müssen dazu aus dem Eimer klettern. Diejenigen, die der Oberkante am nächsten sind, klettern auf den Rand zu und versuchen sich hochzuziehen. Die Krebse weiter unten stecken Zangen und Beine aus und ziehen die wieder zurück. Blödes Verhalten. Schlechte Motivation: Wenn ich es nicht herausschaffe, dann sollen die anderen auch nicht raus. Aber das ist nur die Wirkung, die Intention der Krebse ist ja nur auch raus zu kommen. Dabei halten sie sich an allem fest, was in Reichweite ist. Dumm, wenn das die Krebse weiter oben sind, und diese wieder heruntergezogen werden. Gut gemeint ist nicht gut gemacht. Am Ende entkommt kein Krebs.

So geht das ihren Projekten auch. Wenn eins so schlecht läuft, dass es Ressoucen von anderen abzieht, erreichen Sie am Ende damit nur, dass keines wirklich gut läuft.

Weiße Knöchel am Lenkrad

Gerade wenn mehrere Projekte betroffen sind ist dem Problem nicht über besseres Projektmanagement der einzelnen Projekte beizukommen. Das liegt erstmal nahe und man bekommt das Gefühl, etwas getan zu haben, aber hilft es?

Ein bisschen erinnert mich mehr Kontrolle und mehr Aufsicht an einen Autofahrer, der bei überfrierender Nässe unterwegs ist. Er weiß, dass er ein Problem hat. Er weiß, dass das Auto jederzeit ausbrechen kann. Er weiß, dass er etwas tun muss, um das Auto im Griff zu behalten und sicherzustellen, dass am Ende nicht er im Graben liegt. Was macht er? Er fasst das Lenkrad fester. Das ist für die Richtung des Autos zuständig und wenn er das Lenkrad nur gut festhält, dann fährt das Auto geradeaus. Die Knöchel sind schon weiß vom festen Zupacken, also bleibt das Auto auf der Straße.

Das ist völlig absurd sagen Sie. Langsam fahren hilft, zu hause bleiben hilft, hinter den Räumfahrzeugen fahren hilft, Winterreifen helfen. Aber Lenkrad festhalten? Was für ein hilfloser Versuch. Und dennoch gehen wir an Projekte in Not vielfach mit weißen Knöcheln ran und versuchen sie wieder auf Kurs zu lenken. Die Ursache, die wir uns anschauen müssten, liegt ganz woanders.

Sie wollen mehr leisten, müssen mehr leisten und fragen sich wie

Was können Sie denn tun? Ich will Projektmanagement nicht grundsätzlich die Wirksamkeit absprechen, fern davon. Eine mögliche gemeinsame Ursache, warum bei Ihnen regelmäßig Projekte notleidend werden liegt in der Ausbildung der Projektleiter und dem allgemeinen Verständnis von Projektmanagement begründet. Wer seine Projektleiter nicht unterstütz, indem er sie unterstützt, die neue Rolle auch auszufüllen, der hat sich eine Umgebung geschaffen, in der Projekte immer mal wieder schief gehen werden. Das lässt sich beheben, indem Mitarbeiter zu Projektleitern werden, die diese Rolle wollen, die verstanden haben, dass das eine andere Rolle als fachlicher Mitarbeiter ist und denen das notwendige Handwerkzeug mitgegeben wird, ihre Rolle auszufüllen. Dazu kommt noch ein Umfeld, dass diese Projektleiter unterstüttzt. Linienmanager, die ihre Rolle bei der Unterstützung der Projekte kennen.

Ein anderer Grund ist die realistische Erwartung an die Projekte. Wenn bei Ihnen Projekte geplant werden wie der Stuttgarter Bahnhof oder der Berliner Flughafen, (Erst ganz klein und wirtschaftlich und nachher sind alle an Bord) dann dürfen Sie Sich nicht wundern, wenn regelmäßig Kosten und Aufwand explodieren. Realistische Planungen sind wichtig, damit die Entscheidungen, die auf Basis der Daten gefällt werden auch richtig sind. Das kann man lernen und hier dürfen Sie nachsteuern, wenn regelmäßig die Planung an der Realiät vorbei geht.

Ein dritter Punkt, den ich gerne einbringe ist der, das Projekte häufig im luftleeren Raum geplant werden. Sie werden so geplant, als würden nur sie existieren. Es entsteht ein schöner Plan, der ist dann auch Basis für die Projektergebnisrechnung, für den business case und dann wird eine Entscheidung basierend auf ROI, Gegenwartswert oder internem Zinsfuß getroffen. Also nur aus dem Projekt heraus ohne zu berücksichtigen, ob andere Projekte die gleichen Ressourcen benötigen. Das passiert erst, wenn das Projekt verabschiedet ist und versucht wird, die verschiedenen Projekte unter einen Hut zu bekommen. Nur in dem Moment, wo ein Projekt Rücksicht auf das andere nimmt, verlängern sich die Laufzeiten und die schönen business cases sind hinfällig.

Hier dürfen Sie nachsteuern, wenn das bei Ihnen vorkommt. Wenn sie basierend auf dem business case das Projekt beschließen und die Mannschaft dann versucht, mehrere verabschiedete Projekte zu jonglieren und scheitert oder leidet.

Das Ziel der Produktentwicklung ist es nicht, alle Projekte im Plan und Budget abzuschließen. Das klingt erstmal ketzerisch, aber bleiben Sie kurz mit mir an Ball.

Das Ziel ist es den Unternehmensgewinn zu steigern.

Das Ziel ist es nicht alle Projekte im Plan und Budget abzuschließen. Das Ziel ist es den Unternehmensgewinn in der Zukunft maximal zu steigern. Es geht mal wieder ums Geld verdienen und Geld ist Potential für den Sinn der Unternehmung. Wenn wir dieses Ziel herunterbrechen und verschiedene Produktentwicklungen starten, um dieses Ziel der Gewinnsteigerung zu erreichen, dann kann man schon mal den Wald vor lauter Bäumen nicht mehr sehen und denken, dass jedes Projekt abzuliefern den Gewinn am zuverlässigsten steigert. Das könnte klappen, wenn alle Projekte leise durchlaufen. Das tun sie meist nicht.

Die Frage ist also nicht: Wie halte ich alle Projekte auf Kurs? Sondern: Wie erreiche ich den maximalen Gewinn? Es kann Sinn machen, ein Projekt bewusst zurückzustellen, damit ein anderes Projekt fertig gestellt werden kann, das Produkt an den Kunden ausgeliefert werden kann und wir wieder Geld verdienen.

Die beste Leistung besteht nicht darin, alle Projekte gleich schlecht zu managen, sondern bewusst Prioritäten zu setzen und einzelne Projekte vor anderen abzuschließen.

Systemperformance statt Einzelperformance

Warum ist das so? Warum leistet das System Produktentwicklung eines Unternehmens mehr, wenn wir nicht nur die einzelnen Projekte managen, sondern ganz bewusst die Abhängigkeiten und Verknüpfungen managen?

Ein Produktentwicklungsprojekt schafft Werte wenn es fertig gestellt wird. Produkt entwickelt, Fertigung angelaufen und wir verkaufen das Produkt an Kunden. Ob die Konstruktion besonders schnell war, oder der Einkauf sich super Mühe gegeben hat ist egal wenn sich das nicht auf das gesamte Projekt auswirkt. Nur die Gesamtleistung zählt. Wie beim Fussball, da werden auch nicht die individuellen Schüsse auf das Tor gezählt. Es zählt nur der abgeschlossene Angriff. Ball im Tor. Egal von wem und wie. Es werden keine halben Tore gezählt.

Ein Produkt verdient nur Geld, wenn es entwickelt, eingeführt und verkauft wird. Vorher nicht.

Und das ist auch das gefährliche in der Produktentwicklung. Wir fühlen uns wohl in unseren Rollen als Konstrukteur, Versuchsingenieur, Einkäufer, Logistiker, Vertriebler. Aber Geld verdienen können wir nur zusammen.

In der Fabrik ist das Material sichtbar

Die Fabrik hat es etwas einfacher. Jeder sieht es, wenn eine Maschine nicht weiter kommt und rumsteht. Eine Maschine, die nicht weitergebaut wird und rumsteht fällt auf.

Wenn ein Teil fehlt, kann nicht weiter gebaut werden, wer nicht weiter baut, wird nicht fertig. Eine nicht fertig gestellte Maschine wird nicht abgenommen, eine Maschine, die nicht abgenommen ist wird nicht versand und wird kein Umsatz. Jeder weiß das, jeder sieht die Maschine, die rumsteht und jeder wird vervös. Das Problem, die Maschine, die nicht weitergebaut wird ist sichtbar.

Wissensarbeit sichtbar machen

Das ist in der Entwicklung anders. Wissensarbeit ist nicht sichtbar. Es sind Bits und Bytes im Rechner. Die Arbeit ist unsichtbar, die Probleme sind unsichtbar und keiner wird nervös. Sie dürfen die Arbeit sichtbar machen. Sichtbar machen heißt managebar machen. Managen heißt Probleme auch mal preemptiv zu lösen.

Aber dazu muss das Problem sichtbar werden. Stellen Sie Sich dochmal folgende Situation vor: Ein Konstrukteur hat ein Problem mit einem Teil. Ihm fehlen Informationen. Er fragt nach und steckt fest. Also fängt er das nächste Teil an. Er ist wieder beschäftigt und hat etwas sinnvolles zu tun. Die Rückfrage ist nicht so dringend, er arbeitet ja produktiv.

Jetzt frage ich Sie als Manager. Ist das ein Problem oder ist das keins? Wollen Sie so etwas wissen oder ist das egal? Kein Problem, es arbeiten ja alle und Ingenieure, die ausgelastet sind, sind gut.

Stellen sie sich vor, das kommt häufiger vor. Jeder Konstrukteur hat das mehrmals erlebt und Konstruktionen geschoben, weil Informationen gefehlt haben oder andere Schwierigkeiten aufgekommen sind. Und keiner hat das als Problem angesehe, weil ja alle sich mit anderen Dingen beschäftigen konnten. Bei der Auzählung der fertigen Konstruktionen kommen wir voran, jede Woche werden Teile als fertig gemeldet. Immer noch kein Problem?

Jetzt kommen wir an das Ende des Projektes. Nur ein kleiner Teil von Teilen muss noch konstruiert werden. Leider sind das genau die Teile, bei denen irgendwelche Probleme aufgetaucht sind. Die deswegen liegen geblieben sind, weil es nicht voran ging. Jetzt wird im Projekt 95% fertig gemeldet und nicht ein einziges der Problemteile ist fertig. Geschweige denn durch die anderen Abteilugen. Können Sie Sich vorstellen, was das mit dem Projektplan macht? Immer noch kein Problem?

Doch wenn Ihre Kultur jetzt einen Schulidgen sucht, dürfen Sie noch etwas nachsteuern. Aber die Frage, die mich interessiert ist: Wann hätte man das erkennen könnnen? Wann hätte man das erkennen müssen, um noch Zeit zum gegensteuern, zum managen zu haben? Nur sichtbare Probleme sind mangbar. Wenn alle beschäftigt sind, heißt das nicht, dass das Projekt noch auf Kurs ist.

Prozess als Prozess managen

Die Kette: Funktionsklärung, Konstruktion, Beschaffung, Qualitätssicherung, Versuch, Montage, Auslieferung wird in jedem Produktentwicklungsprojekt dutzende oder hunderte Male durchlaufen. Und deswegen dürfen Sie diesen Prozess auch als Prozess managen. Mit allen damit verbundenen Vorteilen.

Wenn dieser Prozess bewusst gestaltet wird, dann führt das dazu, dass diese Kette, die über mehrere Abteilungen des Hauses gehen vernünftig zusammenarbeiten. Klar ist aber auch, dass das je nach Härte der Silostruktur ein ganz schönes Umdenken in der Organisation auslösen kann. Raus aus dem Silo, raus aus der Fachidiotie, hin zu einem Miteinander für den Kunden.

System performance

Wenn Sie diese Prozesskette durch die Brille der Prozessmanagementwerkzeuge sehen, dann fällt Ihnen auf, wie wenig die individuelle Leistung relevant ist für die Gesamtperformance. Klar, ein Bereich, der seine Entchen gar nicht hintereinander hat kann alles lahmlegen. Das war aber vorher schon so. Nur jetzt sehen wir das als Problem des Prozesses und können darauf reagieren. Können das managen und verbessern.

Aber was passiert mit einer motivierten Abteilung, die besonders tolle Arbeit macht? Nun auch bei der wird sichtbar, wie sehr dieses individuelle Heldentum nicht zu verbessertem Output beiträgt. Denn sie sind Teil eines Prozesses und wie eine Kette nur so stark ist, wie ihr schwächstes Glied, so wird der Prozess bestimmt durch seinen langsamsten Prozess. Vor diesem stauen sich die Arbeitspakete dahinter drehen die Mitarbeiter teilweise Däumchen. Das ist gut, denn jetzt wird sichtbar woran es hängt. Nicht, und das kann man gar nicht häufig genug wiederholen, um Schuldige zu finden, sondern um sichtbar zu machen, wer Hilfe braucht, wo Sie anfassen dürfen, damit alle Ihre Arbeit machen können und der Prozess fortschreitet.

System ist mehr als die Summe der Teile

In diesem Sinne ist der Prozess auch ein typisches System. Das heißt, es ist mehr als die Summe seiner Teile und die Teile profitieren davon, dass sie nicht individuell sondern als Teil des Systems gemanaged werden.

Da der Prozess nur am Flaschenhals beschleunigt werden kann, macht es keinen Unterschied, wenn in den anderen Prozessschritten Verbesserungen umgesetzt werden. Ausnahme: Diese Verbesserung wirkt sich auf den Flaschenhals aus. Klar, Sie können Kostensenkungen an einzelnen Stationen des Prozesses erreichen, auch wenn diese nicht der Flaschenhals sind, aber Durchsatzsteigerungen bekommen Sie nur am Flaschenhals hin.

Also, was heißt es, den Prozess als System zu managen? Nun, Durchsatzverbesserungen erreichen Sie nur am Flaschenhals. Wenn der Leiter einer anderen Abteilung nicht zufrieden mit dem Durchsatz ist, kann er mit Kapazitätssteigerungen in seinem Bereich nichts erreichen. Er wird nicht mehr schaffen, weil durch den Prozess als Ganzes nicht mehr durchgeht als der Flaschenhals durchlässt.

Die Optionen sind halt nur die, die sich auch auf den Flaschenhals auswirken. Er kann, wenn er nach dem Flaschenhals sitzt, Arbeitspakete etwas unreifer übernehmen und einen Teil der Arbeit damit vom Flaschenhals zu sich verlagern. Zum Beispiel kann die Anlage der Teile im ERP-System von der Konstruktion auf den Einkauf verlagert werden. Viele der Tätigkeiten benötigen den Konstrukteur, der sich jetzt darauf konzentrieren kann, die Komponenten nur im Konstruktionssystem zu pflegen. Der Abteilungsleiter kann, wenn er vor dem Flaschenhals sitzt, Arbeit zu sich verlagern, in dem Arbeitsschritte, die sonst am Flaschenhals gemacht werden würden jetzt stromauf gemacht werden.

Und, und das sieht man eigentlich viel zu selten: Natürlich kann auch Personal ausgeliehen werden. Wir können natürlich immer Personal von einer Funktion zu einer anderen schieben. Wenn man eine Organisation mit ihrer Hierarchie betrachtet, dann ist das nicht so offensichtlich, und wird deswegen auch erschreckend wenig gemacht, aber wenn Sie anfangen, den Prozess zu betrachten und auch als Prozess zu managen, dann springen solche Ansätze ins Auge.

Nur ein abgeschlossener Prozess schafft Werte

Es ist banal, aber nur ein abgeschlossener Prozess schafft Werte. Alle Zwischenschritte sind nur Aufwand. Kosten. Erst mit Abschluss des Prozesses bis zum Kunden und Geldeingang, sind die Werte final geschaffen, als dazwischen sind nur Rechengrößen, sollten aber nicht mit realisisertem Gewinn verwechselt werden.

Und auch das wird bei einer Prozess betrachtung sichtbar. In der Silodenke können Abteilungen verführt werden, zu denken, Sie hätten einen Wert geschafft, weil ihr Arbeitsschritt fertig ist. Nur, wenn das Teil dann vor dem Flaschenhals auf einem großen Stapel Teile liegt, dann ist in Summe das Projekt nicht vorangekommen. Dieser Blick auf das Fertig machen ist eines der großen Geschenke, die Sie erhalten, wenn Sie Sich an die Prozesssicht gewöhnen.

Reihenfolge

Und es hilft auch, bei dem Verständnis, dass es besser ist, ein Entwicklungsprojekt fertig zu machen, bevor Sie ein neuer angehen. Natürlich können Sie mehrer Projekte gleichzeitig bearbeiten, aber nicht an der gleichen Stelle. Es ist kein Problem, Ein Projekt in der Anforderungsklärung zu haben, eins im Systemdesign, eins in der Konstrutkion, eins in der Beschaffung, eins im Versuch, eins im Produktionsanlauf. Solange die Projekte sich nicht auf den Füßen stehen, ist alles gut, aber drei Projekte in der Konstruktion sorgt einfach nur dafür, dass die Kapa gedrittelt wird und alle Projekte langsamer bearbeitet werden und länger dauern als notwendig wäre.

Aber auch da hilft es von der Planung der Projekte als unabhängige Aktivitäten hin zu einer Projektsicht, die alle Projekte in Form der zugehörigen Arbeitspakete sieht.

PEP, Projekt Und Prozess

In dieser Episode ging es nicht um den PEP, den Produtkentwicklungsprozess, der beschreibt, welche Stufen ein Produktentwicklungsprojekt durchlaufen muss, sondern um die Prozesse, auf die sich die Projekt abstützen. Hier im Beispiel der Prozess von der Konstruktion bis zum freigegebenen Teil. Dieser Prozess wird für jedes Projekt dutzende bis hinderte Male durchlaufen und für das ganze Portfolio der Entwicklungsprojekte schnell auch mal tausend Mal im Jahr.

Dieser Prozess entscheidet über die Effizienz Ihrer Produktentwicklung, weil die einfache Frage, wie viele neue Teile Sie pro Monat erzeugt bekommen bestimmend ist für die Frage, wie viel Sie entwickeln können. Der andere Hebel, der der Effektivität ist die Frage, was Sie entwickeln. Unterschiedliche Projekte haben unterschiedliche Beiträge zu Ihrem Unternehmensgewinn und die richtigen Produkte auszuwählen hilft aus der begrenzten Kapazität das meiste herauszuholen. Wer sich dafür interessiert kann nochmal in die Folgen zu Priorisierung und COD3 reinhören.

Vorgehen

Was können Sie konkret also tun? Sie haben verstanden, dass Sie den unterliegenden Prozess bewusst gestalten dürfen und fragen Sich jetzt: Wie?

Der Erste Schritt ist die Anerkenntnis, dass hier ein Projekt existiert, der davon profitiert als Prozess über mehrere Abteilungen wahrgenommen zu werden und geführt zu werden. Dazu müssen Sie die unterschiedlichen Abteilungen ins Boot holen. Sie dürfen mit den Kollegen eine gemeinsame Prozessdarstellung machen und herausarbeiten, wer was wenn macht.

Wenn Sie den Konsenz darüber haben, dann dürfen Sie Sich die Werkzeuge bereitlegen, den Prozess zu managen. Gerade für Wissensarbeit ist es wertvoll, die Arbeitspakete sichtbar und anfassbar zu machen. Also ein Abstraktes Arbeitspaket darzustellen. Meine persönliche Präferenz sind hier Whiteboards in Form von Kanban Boards, da mit diesen ein gut dokumentierter gemeinsamer Wissenstand erreicht werden kann.

Manche bevorzugen elektronische Tools, ich mag das Board, weil ich es für sinnvoll halte, die abstakten Arbeitspakete dinglich als Karten zu visualisieren und nicht eine Abstraktum durch ein anderes Abstraktum zu ersetzen.

Auf dieser Visualisierung, die stets die Gegenwart darstellt und schon viel hilft, lassen sich Visualisierungen aufbauen, die helfen die Vergangenheit darzustellen und dadurch die Zukunft besser zu verstehen. Cumulative Flow Diagramme sind für mich da im Zentrum, aber es gibt noch ein paar andere Darstellungen. Die Cumulative Flow Diagramme kompaktieren die Prozesssicht so gut, dass sie sich auch eignen, ein paar Hierarchieebenen höher in enger Frequenz wahrgenommen zu werden. Sie müssen lediglich erklärt werden. Wenn Sie also Geschäftsführer eines Mittelständlers sind oder Entwicklungsleiter in einer großen Entwicklung, dann können Sie mit den CFD jeden Tag mittels Blickdiagnose erfassen, wie der Prozess tickt und werden nicht mehr überrachst.

Kombinieren Sie die Effizienz eines Prozesses mit der Innovationsfähigkeit eines Projektes

Mit den CFD lassen sich Aussagen über die Prozessperformance in der Zukunft machen, die sehr gute Vorhersagekraft haben. Sie sind sehr gut geeignet, um Termine in die Projektplanung der individuellen Projekte zurückzumelden. Nutzen Sie dies, um die Projektleiter von der Fleißarbeit der Verfolgung von vielen kleinen Teilen zu entlasten und gleichzeitig verlässlichere Projektplänge zu erreichen.

Dabei bleiben viele Aktivitäten natürlich im Projektmanagement. Das wesen eines Produktentwicklungsprojektes ist ja das Betreten von Neuland, dafür sind ja die Projektmanagementwerkzeuge da. Aber die Fleißarbeit unten im Maschinenraum, die überlassen Sie doch eher der gut geschmierten Abläufe eines Prozesses.

Multiprojektmanagement

Für mich ist das ein wesentlicher Teil von Multiprojektmanagement. Derjenige, der mit der Abarbeitungsgeschwindigkeit der Arbeitspakete zu tun hat. Ich werde an anderer Stelle noch über andere Aspekte sprechen, aber hier haben Sie den großen Hebel in der Hand, um viele der Ressourcenkonflikte und Planungsaufwendungen, die damit zusammenhängen zu erschlagen.

Frau auf Motorrad

Haufe Blogparade: Organisationsrebellen

Der Stoff, aus dem Rebellen sind: Blogparade vom Haufe Blog. #Organisations­rebellen

How many psychiatrists do you need to change a light bulb. One, but the light bulb needs to want to change.

Wie viele Organisationsrebellen brauche ich um eine Organisation zu verändern. Einen, aber die Organisation muss sich verändern wollen.

Organisationsrebellen haben einen spannenden Job. Also gerade auch von dem Wert, den sie stiften können. Ein bisschen Unruhe in der Organisation, eine Person, die furchtlos immer wieder daran erinnert, was eigentlich das Ziel ist. Das kann eine Organisation unheimlich nach vorne bringen.

Aber wenn die Bemühungen nicht auf fruchtbaren Boden fallen, wenn die mahnenden Worte nur noch nerven? Dann ist der Organisationsrebell nur noch ein Fremdkörper ohne Wirksamkeit. Vielleicht auch aufgrund seiner Rastlosigkeit, die nicht zur Firma passt ist er auch nervig.

Die Wirksamkeit des Organisationsrebellen hängt also nur zum Teil von Ihr oder Ihm ab. Genau so wichtig ist es, die Saat in fruchtbaren Boden pflanzen zu dürfen. Der Grat zwischen Mahnen und Warnen und Meckern und Motzen ist schmal.

Es gibt für mich ein großes Vorbild für die Organisationsrebellen. Das ist der mittelalterliche Hofnarr. Er durfte ungestraft alles sagen und auch am Lack der Herrschaft kratzen. Das ist eine wichtige Funktion für einen Herrscher, der von Ja-Sagern umgeben ist, die ihm nach dem Munde reden. Er hat einen Mahner und Warner, der nicht an die Konvention gebunden ist und dadurch auch Dissenz erlaubt.

Wenn der Hofnarr seine kritischen Botschaften überbrachte, dann mit einer Prise Humor und so, dass sie weggelacht werden konnte. Der Herrscher konnte laut lachen und die Frechheit des Narren dadurch belohnen. Dann war die Kritik vordergründig unbedrohlich. Das ermöglicht der Gesellschaft dann wieder zur Sache zu kommen. Der Hofnarr war nicht bedrohlich, die Botschaft kam trotzdem an, wenn auch etwas indirekter.

Eine wichtige Eigenschaft des Hofnarren muss aber gegeben sein. Er muss von Herrschers Gnaden eingesetzt sein. Der Herrscher muss den Hofnarren akzeptieren, dulden und wollen. Er muss sich dem Gespött aussetzen und Widerspruch akzeptieren. Höfe an denen das nicht gegeben war, hatten keine Hofnarren. Das Vorhandensein eines Narren war gleichzeitig das Zeichen für einen selbstbewussten Herrscher.

Es gab keinen Betriebsrat, der eine Person gewählt hat, der den Oberen mal so richtig den Spiegel vorgehalten hat. Es war keiner Entscheider von außen, der dem Herrscher einen Spötter in den Pelz gesetzt hat. Nein, der Herrscher hat ihn zugelassen oder gewollt. Und das ist entscheidend.

Wenn Sie ein Narr sein wollen, achten Sie auf die Akzeptanz von oben. Widerspruch alleine reicht nicht, Sie müssen gehört werden. Das heißt nicht, dass man Ihnen folgen muss, aber Sie brauchen Respekt und Gehör. Holen Sie Sich diesen Respekt egal wie. Ohne den Respekt sind Sie kein wirksamer Rebell.

Recht haben, Recht bekommen und rechthaberisch sein sind völlig unterschiedliche Dimensionen, die weniger miteinander gemein haben, als den Worten ansehbar wäre.

Wenn Sie eine gute Führungskraft sein wollen, dann laden Sie Dissenz ein. Das muss nicht immer der gleiche sein, aber lassen Sie den Rebellen Raum. Hören Sie zu. Nur, warum sollten Sie? Weil Sie betriebsblind werden, weil Sie durch den Apparat (gewollt oder ungewollt) abgeschirmt werden von den Geschehnissen weiter unten und weil Sie diesen Seitenkanal brauchen um Ihr Bild abzurunden.

Nicht selten passiert es, dass eine Organisation von Erfolg besoffen wird und glaubt, sie habe die Erleuchtung gefunden. Sie weiß, wie man erfolgreich wird, weil sie es ja am eigenen Leib spürt. Und alles, was vorhanden ist, ist auf einmal richtig, weil in Summe der Erfolg da ist. Auf einmal werden Compliance-Abteilungen und Berichtswesen wertschöpfend angesehen und nicht mehr hinterfragt.

Ein Beispiel: Der CEO von Nokia hat nach dem großen Crash gesagt: Wir haben doch alles richtig gemacht. Das muss man sich auf der Zunge zergehen lassen. Es wirkt wahnsinnig naiv und dumm, nach dem Absturz so etwas zu sagen. Ich würde aber einiges dafür verwetten, dass Stephen Elop beides nicht ist. Aber er war betriebsblind. Nokia hat nicht auf die Narren gehört, die hätten helfen können aus dem Erfolgsrausch herauszukommen und der Realität früher ins Auge zu sehen.

Lasst uns von den Narren lernen:

Die Organisation muss die Rolle wollen. Die Rolle muss auch Gehör haben. Das ist etwas, was der Organisationsrebell nicht selber entscheiden kann. Das heißt nicht, dass die Rolle explizit im Organigram stehen muss oder nur einmal vorkommen darf. Aber die Rebellen die da sind, müssen sich entfalten dürfen.

Die Botschaft des Rebellen muss verdaulich sein. Die Narren haben das mit Humor gemacht, aber auch andere Methoden sind nutzbar. Gelegentliche Grenzübertritte sind ok, wenn das Respekt-Konto sie hergibt. Auch Organisationen haben eine Komfortzone. Wer diese erweitern will muss sich auf dem Umfang bewegen und immer wieder raus und rein gehen. Zu weit vorpreschen zerreißt nur das Gummiband.

Der Rebell muss wollen. Risk to get fired heißt es so schön. Ohne Lust an der Grenzübertretung, ohne Akzeptanz des damit zusammenhängenden Risikos wird sich wenig bewegen.

Die Motive des Rebellen müssen für alle klar sein. Der Narr hatte keinen Anspruch auf den Thron. Er war Helfer des Herrschers. Der Organisationsrebell muss so wahrgenommen werden, dass er sein Unwesen zu Gunsten der Firma treibt, nicht für eigenen Nutzen. Die Reinheit des Ziels lässt viele Grenzübertretungen tolerabel erscheinen. An dieser Wahrnehmung muss der Organisationsregell vorher arbeiten. Wie heißt es so schön: Spare beizeiten, dann hast Du in der Not.

In diesem Sinne wünsche ich allen Organisationsrebellen viel Spaß und Erfolg. Ich wünsche Euch ein Umfeld in dem Ihr gedeiht. Und wenn Ihr das nicht habt, dann wünsche ich Euch Erfolg auf der Suche nach fruchtbarem Boden.

Geld und Sinn

Geld und Sinn – Warum ich so viel über Geld rede und etwas völlig anderes meine

021 – Ich spreche hier im Podcast immer vom Geld verdienen durch eine gute geführte Entwicklungsabteilung. Das soll aber den Sinn Ihres Unternehmens nicht ersetzen. Mir geht es nicht ums Geld verdienen per se, sondern Geld ist Treibstoff und Potential für Ihre Ziele. Darum geht es. Ihre Ziele zu erreichen. Und der Weg dahin ist die gut geführte Entwicklungsabteilung.


Permalink zu den Shownotes und Transskript: http://smarterentwickeln.de/geld-und-sinn-warum-ich-so-viel-ueber-geld-rede-und-etwas-voellig-anderes-meine

Nehmen Sie Kontakt mit mir auf. Ich freue mich über Anmerkungen, Rückmeldungen und Fragen: florian@smarterentwickeln.de


Transkript der Episode

Warum spreche ich hier im Podcast eigentlich so viel vom Geld verdienen als Ziel der Produktentwicklung. Ist es das wirklich? Wollen wir denn nicht die Probleme der Menschheit lösen, die Kunden glücklich machen, etwas tun, das sich gut als Geschichte für die Kinder, als Geschichte in der Kneipe und bei der eigenen Beerdigung macht?

Ich glaube, ich darf hier eine kleine Schleife drehen und erläutern, warum ich so viel monetär sehe.

Simon Sinek hat es schön auf den Punkt gebracht: Start with why. Fang mit dem Warum an. Wer Menschen mitreißen möchte, der muss Ihnen einen Sinn geben, der muss ihnen sagen, warum die Gruppe etwas tut, damit sie dann ein Warum haben, das begründet, warum sie etwas tun sollen.

Erst dann kommt das How und What. Also das Wie und das Was. Der Weg und die Details. Das Ziel bestimmt den Weg. Und auf dem Wege kommen die Schritte. Ohne Ziel ist es auch egal, wo wir hingehen.

Und dennoch rede ich so viel vom Geld. Warum eigentlich? Ist Geld das Ziel? Ist das das große Warum? Nur Geld verdienen? Nein. Geld ist nicht das Warum. Geld ist Teil des Wies. Das möchte ich heute erläutern.

Ich stecke hier in einem Dilemma. Ich rede hier in mein Mikro rein. Ich sehe zwar stattliche Downloadzahlen, aber habe wenig Interaktion mit den Hörern. Ich hatte unter den Shownotes die Kommentare immer an. Ich habe die jetzt ausgemacht. Es hat überhaupt nur zu zwei Artikeln Komentare gegeben, was auch an der Darreichungsform des Podcasts liegt, der nebenbei konsumiert werden kann, fern ab der Tastatur, fern ab des Kommentarfeldes. Das hat Vorteile für die Hörer, die Podcasts immer hören können, aber für die Kommunikation also für den Austausch Nachteile. Ich freu mich über Emails und Kontaktaufnahmen unter florian@smarterentwickeln.de

So, zurück zu meinem Problem. Ich versuche hier mein Wissen unter das Volk zu bringen und dabei bei Ihnen einen Nerv zu treffen. Aber erstens bin ich einer und Sie viele und zweitens kenne Ich Ihre Märkte und Produkte nicht. Ich kann also nur allgemein bleiben. Nur genau hier im spezifischen sitzt aber das Warum. Genau in dieser Ihrer Besonderheit ist Ihr individueller Grund für Ihr Geschäft zu sehen. Ihr Produkt, Ihre Kunden, die Probleme, mit denen Sie sich identifizieren.

Und jetzt mache ich etwas um dieses Problem loszuwerden: Ich blende es einfach aus. Ich setze vorraus, dass Sie ein Warum haben, dass Sie wissen, warum sie im Geschäft sind, dass Sie Kunden haben, für die Sie dies machen. Wenn Sie keins haben, dann besorgen Sie Sich eins, denn nur Geld verdienen ist seelenlos und macht nicht satt.

Und doch ist das das Fundament, auf dem ich alles aufbaue. Warum eigentlich? Nun, Geld ist Treibstoff. Geld ist der Stoff, den Sie einsetzen können, um Ihrem Ziel, ihrem Warum näher zu kommen. Geld ist nicht alles, aber ohne Geld ist alles nichts. Wer sich an Mathe erinnert: Geld ist eine notwendige Voraussetzung, aber keine hinreichende.

Geld können Sie einsetzen und es investieren, Sie können davon Umlaufvermögen beschaffen und es als Input in Ihrer Firma einsetzen und wenn Geld vorhanden ist, haben Sie die Freiheiten Kunden anzunehmen oder abzulehnen.

Geld macht möglich. Und genau das ist die Verknüpfung. Je schneller Sie Ihre Produkte entwickeln, je besser die Produkte zu Ihren Kunden passen und je besser die Kunden sind, desto mehr Geld werden sie wieder einnehmen und desto mehr können Sie wieder auf Ihr Ziel zugehen. Geld sinnvoll in Produktentwicklung investiert hat die Chance in einem positiv rückgekoppelten Kreis zu kommen. Ein gutes neues Produkt, schnell auf den Markt. Mehr Kunden sind happy und kaufen, Ihnen bleibt mehr Deckungsbeitrag, den Sie wieder in Produktentwicklungen investieren können. Mehr gute Produkte, noch mehr Kunden sind happy, noch mehr Deckungsbeitrag zum reinvestieren. Ein Kreislauf, der sich selber stützt.

Gewinn, den Sie abführen nimmt Ihnen eigentlich nur Schwung aus diesem Kreisel, aber es kann trotzdem das richtige Sein. Nur der Sinn war das nicht.

Den Sinn, das Warum, das setze ich bei Ihnen vorraus. Wenn Sie den nicht haben, dürfen Sie hier nochmal etwas nachsteuern.

In meinem Podcast geht es darum, dieses Schwungrad mit Antrieb durch positive Rückkopplung zu bauen. Ich will Ihnen hier aufzeigen, wie Sie schnell entwickeln und dadurch einen schnellen Mittelrückfluss auf Ihre Investition in Produktenwicklung zu haben. Ich werde dieses Thema noch ein bisschen abrunden. Auch nochmal auf das Thema Lean für die Produktentwicklung eingehen und auch begründen, warum ich lieber Smart als Lean für den Namen genommen habe.

Danach will ich darüber reden, was ein richtiges Produkt ausmacht. Und was Sie tun können, um die Kunden zu begeistern. Auch das ist neben der Zeitfrage ein ganz wichtiger Hebel um das Schwungrad in Drehung zu bekommen.

Und zuletzt sprechen wir nochmal ausführlich über die Frage, was die Frage nach den richtigen Kunden für Ansätze bereithält, um das Schwungrad zu beschleunigen.

Ihr Warum, Ihren Sinn setze ich vorraus, aber das Schwungrad in Gang zu bringen und zu beschleunigen, das ist der gemeinsame Nenner über alle Zuhörer und das ist auch der Grund, warum ich hier so viel darauf herumreite. Schaffen Sie es, das Schwungrad zu beschleunigen, dann dürfen Sie beglückt in die Zukunft schauen, wenn das Schwungrad schon etwas träge ist, dann dürfen Sie jeden Hebel ziehen, es wieder in Gang zu bekommen.

Aber das Geld kann noch mehr. Ihr Ziel mag sehr konkret sein. Sie kennen es, alle kennen es und steuern es an. Sie werden Sich trotzdem schnell schwer tun abzuschätzen, wie viel näher Sie dem Ziel kommen, durch eine Ingenieursstunde in der Konstruktion. Oder EUR 10.000 für Werbemaßnahmen. Oder 10 Außendienstbesuche vom Vertrieb.

Management und besonders auch Produktentwicklung ist immer Abwägung. Das eine oder das andere. Die Option oder die? Und Sie müssen entscheiden. Auch Ihre Mitarbeiter entscheiden jeden Tag. Und Sie dürfen Sich überlegen, wie Sie diese Entscheidungen so beeinflussen, dass das richtige dabei herauskommt.

Sie können die Beispiele eben zwar auf Ihr Ziel beziehen. Aber meist nicht gut. Sie haben keinen direkten quantifizierbaren Zusammenhang. Sie wissen aber wahrscheinlich ziemlich genau, welchen Preis die Beispiele eben haben. Sie können sie also mit Leichtigkeit auf Geld beziehen. Es sind sich auch alle ziemlich einig. Dadurch haben Sie einen Wechselkurs etabliert, und dieser Wechelkurs hilft Ihnen alles an einem Maßstab zu messen. Sie können jetzt vergleichen, abwägen und sachlich entscheiden.

COD (Cost of Delay) ist letztlich nur so ein Austauschkurs. Der Preis der Zeit. Die Priorisierung nach COD3 also Cost of Delay divided by duration. Ist nichts anderes als die Methode, die das Schwungrad am schnellsten in Drehung versetzt, weil die Methode den größten Mittelrückfluss auf die Produktentwicklungsinvestition erzeugt. Mithin den Grad der positiven Rückkopplung optimiert. Zu Cost of Delay und Priorisierung nach COD3 habe ich eigene Episoden gemacht.

Nein, Geld ist nicht der Sinn der Unternehmung. Wenn dieser Sinn abhanden gekommen ist und nur noch über das Geld geredet wird, dann merkt man das im Unternehmen. Aber diese Kälte ist nicht, warum ich so viel auf das Geld beziehe. Ich will Ihnen helfen, Ihre Ziele zu erreichen, Ihr Warum zu leben. Und Geld ist da der Treibstoff und das Potential diese Ziele zu erreichen.

Sinek hat ein ganz einfaches Modell aus drei Kreisen. Das Warum in der Mitte, dann konzentrisch das Wie und das Was drumherum. Das Warum steht im Zentrum. Das ist das Ziel, die Motivation, der Nordstern. Ein Führer vermittelt das Warum und nimmt dadurch die Menschen mit. Um es zu erreichen kommt dann das Wie. Der Weg. Wie werden wir unser Ziel erreichen. Genau diese Übersertzungsleistung vom Warum zum Wie macht eine gute Führungskraft aus. Aus dem Ziel den Weg ableiten und aufzeigen und dann gehen.

Sie sehen also: Ich rede zwar immer vom Geld, aber das Geld ist nicht der Sinn, es ist nur der Weg, den Sinn, das Warum zu erreichen. Ihr Warum ist Individuell. Spezifisch für die Branche, meist auch spezifisch für Ihr Unternehmen. Produktentwicklung gut gemanaged ist universell. Die Implementierungen müssen angepasst werden, aber das große Konzept ist übertragbar. Ich bin fest davon überzeugt, das jedes Unternehmen von einer ganz bewussten Gestaltung der Produktentwicklung als großes Schwungrad ganz unten in der Maschine profitiert. Das Geld bewusst gesteuert vermehrt und reinvestiert die Innovationskraft entfaltet, mit der Sie Ihr Ziel erreichen.

Ich habe über die Jahre in der Produktentwicklung mir Modelle und Methoden angeeignet, die helfen Produktentwicklung als Wettbewerbsvorteil einzusetzen. Die Produktentwicklung und die Reinvestition des erwirtschafteten Geldes als Schwungrad zu sehen und damit die Firma anzutreiben. Dadurch hat sich bei mir mein eigenes Warum verschoben. Früher wollte ich bestimmte Produkte entwickeln, heute ist es mein Ziel möglichst vielen mittelständischen Unternehmen zu helfen, Ihre Produktentwicklung so zu managen, dass sie Ihre Ziele erreichen.

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.

Fünf vor Zwölf

Time to Market verstehen und verkürzen

019 -Time to Market verstehen und verkürzen

Time to Market ist eine der wichtigen Größen in der Produktentwicklung. Eine schnelle Produktentwicklung eröffnet viele Möglichkeiten, die in dieser Folge diskutiert werden. Wie Sie die Time to Market verkürzen und Ihre Produktentwicklung beschleunigen macht den zweiten Teil der Folge aus.

Permalink zu den Shownotes und Transskript: http://smarterentwickeln.de/time-to-market-verstehen-und-verbessern/

Videos aus der Episode

Nehmen Sie Kontakt mit mir auf. Ich freue mich über Anmerkungen, Rückmeldungen und Fragen.


Tragen Sie Sich hier für den Emailverteiler ein. Hier sende ich Ihnen wöchentliche Impulse, Terminankündigungen und Fragen und geben Ihnen die Chance, Themen für den Podcast vorzuschlagen und damit Ihrer Problemlösung näher zu kommen.


Name:

Email:





 

Transkript der Episode

Warum ist Time to Market ein wichtiger Parameter für die Produktentwicklung?

Time to market ist ein wichtiger Begriff und ein wichtiges Konzept. Time to market beschreibt, wie viel Zeit gebraucht wird von einer Idee bis das Produkt verkauft wird. Manche zählen auch noch die Produktionsrampe mit und stoppen die Uhr erst nach 100.000 verkauften Einheiten.

Das Konzept ist seit den 80er und 90er Jahren bekannt, hat aber seitdem nicht nur mehr Bekanntheit bekommen, sondern ist als Erfolgskriterium für eine Firma immer wichtiger geworden.

Jede Industrie hat hier ihre eigenen Zeitskalen. Während in der Autoindustrie die Entwicklungszeit von Jahren sich zwar verkürzt haben, aber immer noch in der Einheit Jahre gemessen werden können, macht das für Software heute keinen Sinn mehr. Programme, die früher als CD im Karton mit einer großen Änderung einmal im Jahr verkauft worden sind, werden heute als SaaS Software as a Service-Modell angebtoen mit Updates dutzende Male am Tag.

Diese Unterschiede führen vor allem dann zu Spannungen, wenn ein Produkt in zwei Welten spielt. Besonders auffällig immer wieder bei der Unterhaltungselektronik im Auto, die Jahre hinter dem hinterherhinkt, was wir bei Mobiltelefonen gewöhnt sind und daher besonders aus der Zeit gefallen wirkt.

Lassen Sie uns ein bisschen über die Vorteile von kurzen Entwicklungszeiten, von einer kurzen Time-to-Market (TTM) reden.

Marktführer werden – Vorteile genießen

Diejenige, die als erste auf den Markt kommt, hat erst mal den Markt für sich. Sie ist de facto Marktführerin. Dazu noch in einer Monopolsituation. Das hat handfeste wirtschaftliche Vorteile. Sie können den Preis Ihres Produktes, Ihrer Leistung mit dem Kunden ausmachen und müssen dabei keine Rücksicht auf die nicht vorhandene Konkurrenz nehmen. Sie können sich also sehr stark am Kundennutzen orientieren und nicht so sehr an Ihren eigenen Kosten. Das lässt Raum für deutlich interessantere Margen.

Aber auch jenseits des Zeitraums, in dem Sie noch alleine auf dem Markt sind, lohnt es sich, der Erste gewesen zu sein. Man erinnert sich an Sie, die Nische wird auf längere Sicht mit Ihrem Produkt verknüpft werden. Entweder wird Ihr Produkt zum Gattungsnamen (Tempotaschentücher) oder jeder denkt direkt an Sie.

Stellen Sie Sich vor, sie sind IT-Leiter und sollen eine ERP-System-Einführung machen. Sie haben sich diverse Gedanken gemacht, gute Software verglichen und letztlich eine ausgesucht. Jetzt kommt der Termin mit der Geschäftsführung, wo Sie Ihre Arbeit vorstellen. Sie stellen die verschiedenen Programme vor, Vor- und Nachteile und haben eine tolle Vergleichstabelle, die auch auf Powerpoint sowohl gut aussieht, als auch Informationsgehalt hat. Und was ist die erste Frage? Gibt es einen Grund, warum SAP in der Auswahl nicht vorkommt? Haben die nichts für uns?

Das wünsche ich Ihnen auch. Dominieren Sie Ihre Nische so, dass, wenn Sie nicht mit auf der Entscheidungsvorlage stehen, die Entscheidungsvorlage unvollständig erscheint. Sie werden automatisch angefragt.

Machen Sie Sich einen Namen, dadurch, dass Sie die ersten sind, die eine Produkt verkaufen und dominieren Sie begrifflich und wirtschaftlich Ihre Nische.

Natürlich hat das alles nicht nur Vorteile. Wer als erster eine Nische aufmacht und das erste Produkt anbietet, der muss manchmal eine ganze Menge erklären, bis die Menschen verstanden haben, warum sie etwas brauchen. Aber lassen Sie Sich davon nicht abschrecken, es kann sich sehr lohnen.

Innovativ sein

Eng verknüpft mit erster sein ist es innovativ zu sein. Das macht ja auch Sinn, jemand der regelmäßig der erste mit den Innovationen ist, ist auch derjenige von dem diese Innovationen kommen.

Das funktioniert nicht immer, so gibt es chinesische Hersteller, die Crowd-Funding-Platformen nach Ideen durchsuchen und vielversprechende Ideen aus den Markt bringen, bevor die eigentlichen Innovatoren Zeit hatten, Ihre eigenen Entwicklungen umzusetzen. Aber erstens ist das auch eine Leistung und zweitens geht das bei einfachen Konsumgütern leichter als bei Investitionsgütern.

Für einen Kunden, der sein Problem schwer zu lösen hält ist ein Innovator ein vertrauenerweckender Partner. Mein Problem ist so schwer, das können nur die ganz innovativen lösen…

Innovation mag nicht die leichteste Strategie sein, aber für innovative Produkte, die mit nichts vergleichbar sind, sind auch besserer Margen aufrufbar. Vorausgesetzt, sie lösen das Problem des Kunden wirklich.

Herdentrieb

Früher gab es in der IT den Spruch: Es ist noch keiner gefeuert worden, weil er IBM gekauft hat. Das war die Zeit der Mainframes, der großen Eisen wie man so schön sagt. Heute läuft ja alles auf Hardware mit PC-Architektur oder gleich ganz in der Cloud. Ich bin Maschinenbauer, ich will gar nicht über die Details der Computerentwicklung reden – kann ich auch nicht sinnvoll.

Aber der Satz hat eine wichtige Botschaft: Es gibt Lieferanten, mit denen ist man auf der sicheren Seite. Hier geht man kein Karriererisiko ein, wenn man bei denen kauft. Wenn es gut geht, war es die richtige Wahl, wenn es schlecht geht, hat man halt Pech gehabt, aber keinen Fehler gemacht, der Lieferant war ja tadellos und daran könnte es nicht gelegen haben.

Der Podcast wendet sich an Maschinenbauer, für Investitionsgüter, B2B. Hier wird oberflächlich nach Zahlen Daten und Fakten entschieden. Darunter ist aber nochmal eine ganz eigene Entscheidungsebene, bei denen nicht so sehr zum Wohle des Projektes, sondern zum Wohle des Entscheidungsträgers entschieden wird. Und ich rede da noch gar nicht von Korruption, sondern von diesen Gedanken zu den Fragen: Ist der Lieferant verlässlich? Fällt das auf mich zurück? Ist der Lieferant gut zu führen? Oder wird das eine Claim-Management-Hölle? Wenn die Kollegen sich meine Lieferantenauswahl anschauen, rümpfen die die Nase oder sagen die: Mit denen wollte ich auch immer mal zusammenarbeiten?

Im englischen gibt es dieses schöne: There is safety in numbers. In der Herde ist man sicher. Dieser Herdentrieb sorgt dafür, dass Menschen die Entscheidungen treffen, die andere schon mal in ähnlicher Situation getroffen haben. Das ging schon mal gut, das wird wieder gut gehen.

Warum erzähle ich das alles? Nun, stellen Sie Sich vor, Sie sind der erste in einem Markt. Die Käufer haben noch keine große Entscheidungsfreiheit. Sie lösen das Problem und es ist besser, etwas mit Ihnen zu machen als nichts zu machen, eine Konkurrenz gibt es nicht. Also kaufen sie bei Ihnen.

Und der nächste kauft und der nächste kauft. Wenn die Konkurrenz auf den Markt kommt, haben Sie die Referenzen und die Konkurrenz nicht. Es ist mit Ihnen schon mal gut gelaufen, die Konkurrenz muss das erst noch zeigen.

Dieser Rückenwind wird Sie noch lange nach der ersten Phase, in der Sie alleine auf dem Markt waren, beflügeln. Der Effekt ist in manchen Branchen stärker, in manchen schwächer, sie können auch etwas dazu beitragen, das dieser Effekt bestehen bleibt.

Der Herdentrieb der Kundschaft ist wichtig und stärkt den Marktführer oder in neuen Märkten den ersten. Nehmen Sie diesen Effekt mit, wenn sie Ihre Produktentwicklung beschleunigen und Erster auf dem Markt sind.

Enger am Markt agieren, Chancen nutzen Risiken minimieren

Sie haben eine tolle Produktidee, das wäre genau das richtige für den Markt jetzt. Jeder brauch es, keiner hat es. Also werden Sie das jetzt entwickeln. Der Businesscase sieht toll aus. Alle brennen für das Projekt und trotzdem gibt es Stimmen: Wir dürfen aber auch die neue Plattform, das neue Steuergerät, die Varianten für Entwicklungsländer nicht vernachlässigen. Die Produktroadmap ist voll und alle sind stolz.

Jetzt kommt unsere tolle Produktidee nicht so recht vom Fleck. Wegen der vielen anderen Projekte ist es schwer, das Team zusammenzustellen und alle notwendigen Rollen zu besetzten. Das macht aber nichts, der Plan steht und das Team muss sich einfach ein bisschen anstrengen um ihn einzuhalten.

Der Plan rutscht ein bisschen. Und noch ein bisschen. Es gibt immer gute Gründe. Mal fehlt Personal, dann fehlt die Fertigungskapazität, es wurden noch nicht die richtigen Lieferanten gefunden. Jedes Projektupdate verspätet sich das Projekt etwas. Meist heißt es dann: Das holen wir wieder auf. Wenn die Verzögerung zu groß geworden ist, so dass man sie nicht mehr wegdiskutieren kann, dann wird ein neuer Plan verabschiedet. Ab jetzt werden alle Verspätungen nur noch gegen diesen neuen Plan berichtet, so dass immer nur ein paar Wochen und Monate Verspätung sichtbar sind.

Würden Sie den originalen Plan daneben legen, so würden sich alle erschrecken, aber so geht die Salamitaktik auf und keiner muss seine Blutdruckmedikamente neu einstellen.

Jetzt kommen Sie mit 18 Monaten Verzug auf den Markt. Ihnen ist schon klar, dass der Bedarf, wie er sich damals abzeichnete nicht mehr so ausgeprägt zu verspüren ist. Sie haben sogar schon mal überlegt das Projekt einzustellen und die Ressourcen woanders einzusetzen. Aber, um die Wartezeit zu überbrücken sind sie mit einem Modell Ihrer Innovation auf die Messe gegangen. Die Katze ist aus dem Sack und jetzt wollen Sie auch liefern. Es geht hier schließlich um die Glaubwürdigkeit. Also haben sie weitergemacht und jetzt ist die Nachfrage nicht so wie erhofft.

Was ist passiert?

Können Sie mir die Lottozahlen der nächsten Woche sagen? Nein? Können Sie raten? Klar. Was ist die Wahrscheinlichkeit, dass Sie Recht haben? 1 zu 140 Mio. Können Sie mir die Lottozahlen der KW 16 in drei Jahren sagen? Nein, ein Tipp? Wie wahrscheinlich? 1 zu 140 Mio. Genauso unsicher. Es macht keinen Unterschied, ob Sie die Lottozahlen von morgen oder von in drei Jahren vorhersagen wollen. Die Wahrscheinlichkeit ist in beiden Fällen absurd niedrig.

Aber Sie spielen ja doch nicht Lotto, nicht im Unternehmen. Sie machen Analysen und Szenarienvergleiche und kommen so zu einer informierten Meinung. Aber wenn Sie sich zuhören, wie Sie über den Markt in drei oder fünf Jahren reden, dann sind da eine ganz ordentliche Portion Unsicherheit und eine Menge Abhängigkeiten drin. Welche Produkte entwickeln Sie, was macht die Konkurrenz, was für einen Präsident wählen die Amerikaner, steigt jetzt die Nachfrage nach Beton an der US Südgrenze oder nicht?

Nur, wenn Sie darüber diskutieren, was der Markt jetzt will, dann gibt es da zwar immer noch gewisse Unsicherheiten, diese sind aber viel kleiner und Sie sind Sich auch entsprechend sicherer in Ihren Aussagen.

Das ist die Unsicherheit der Zeit. Je weiter Sie versuchen in die Zukunft zu schauen, desto unsicherer werden Ihre Aussagen. Wenn Sie heute der Meinung sind, da ist ein Markt, der es wert ist angegangen zu werden, so ist die Aussage, ob dieser Markt in drei Jahren noch genauso vorhanden ist schon mit viel mehr Unsicherheit versehen. Sie gehen mit längeren Entwicklungsprojekten alleine aus diesem Aspekt ein größeres Risiko ein.

Wenn Sie mit Ihrer Firma eine gewisse Kapitalrendite anstreben, so schauen Sie auf den Erwartungsgewinn. Höhe des Nutzens des Projektes mal der Eintrittswahrscheinlichkeit. Schlechtere Wahrscheinlichkeiten können Sie eher theoretisch durch höheren Nutzen kompensieren. Die Rendite wird einfach fallen. Hätten Sie die Ideen, wie Sie höheren Nutzen erzeugen, würden Sie ja diese Projekte machen.

Risiko kostet Sie Rendite. Projektlänge steigert das Risiko. Alleine deswegen lohnt es sich, zu lernen Projekte schnell abzuwickeln. Erster sein, Konkurrenz ausstechen, aber vor allem den Markt noch so vorfinden, wie Sie das bei der Aufplanung Sich gedacht hatten.

Was ist Business Agility?

Das lässt sich noch etwas verallgemeinern. Bis hierhin haben wir nur von einem Projekt gesprochen. Aber Sie machen Ihre Projekte nicht zum Spaß, sondern um die Firma in der Zukunft besser da stehen zu lassen. Jedes Projekt beeinflusst die Wirtschaftlichkeit der Firma. Also schauen wir uns doch mal das Portfolio an.

Jedem Manager ist klar, wie wichtig die Produktentwicklungen für die Firma sind. Je nach Herkunft haben die Manager andere Schwerpunkte, auf die sie achten, aber egal ist es eigentlich keinem. Der Vertrieb will die Produkte, nach denen die Kunden fragen und die sich verkaufen lassen. Die Fertigung will endlich ihre Kostenziele umsetzen und legt wert auf Produkte, die sich einfacher montieren lassen. Die Qualitätsabteilung will, das endlich die unsäglich Gewährleistungssituation sich bessert und der Service hätte gerne Produkte, die zuverlässig laufen, aber genug Verschleißteile haben, dass sie auch morgen noch genug Arbeit haben. Keinem ist es wirklich egal, auch wenn sie alle eine andere Sprache sprechen.

Es ist also ein wichtiges Thema. Es wird darüber in Strategiesitzungen diskutiert, die Produktpipeline der nächsten 5 Jahre wird festgelegt. Schließlich ist das der ultimative Ritterschlag für ein Thema im Unternehmen, dass wir jetzt schon wissen, was wir in fünf Jahren auf dem Thema machen wollen. Wäre es nicht so wichtig, hätten wir nie die Zeit investiert, so lange in voraus zu planen. Auch hier gilt, übertreiben verdeutlicht, aber schauen Sie Sich doch mal bei Sich um und fragen Sie Sich, wie lange im Vorlauf Ihre Entwicklung schon verplant ist.

Und was passiert jetzt? Die Welt steht nicht still, sie dreht sich jeden Tag und einmal im Jahr auch um die Sonne. Die Konkurrent arbeitet die ganze Zeit, andere Technologien kommen auf den Markt und die Anforderungen der Kunden ändern sich. Die ganze Liebe, die Sie als Organisation der Produktentwicklung zukommen lassen, indem sie eine Produktstrategie für die nächsten fünf Jahre ausformulieren wirkt jetzt eher bedrückend. Wie ein etwas zu anhänglicher Partner hängt Ihnen diese Strategie die nächsten fünf Jahre an den Füßen, während sich draußen die Welt weiterdreht.

Eigentlich wollen Sie doch etwas anderes. Sie wollen flexibel auf den Markt reagieren können, Ihre Kunden mit Ihren tollen Produkten, die genau den Nerv der Zeit treffen, begeistern und nicht fünf Jahre in der Zwangsjacke stecken und zuschauen.

Es geht also nicht nur darum, ein spezifisches Projekt schnell durch den Entwicklungszyklus zu bringen, sondern mit der ganzen Firma flexibel auf die sich bietenden Chancen und Gelegenheiten zu reagieren. Die Fähigkeit ein Projekt schnell abzuwickeln ist das eine, die Fähigkeit, die richtigen Projekte zu definieren, die jetzt die besten für die Firma sind ist das andere. Nicht Agilität im Projekt sondern Business Agility.

Das ist ein großer Sprung für den einen oder anderen, denn schließlich ist doch eine volle Produktpipeline gut, und jetzt komme ich und sage, Nein, sie müssen den Kopf frei haben für kurzfristig interessante Themen, die sich lohnen, schnell ergriffen zu werden. Nur wer diese Fähigkeit beherrscht, kann schließlich kleinere Zeitfenster nutzen, in denen sich Möglichkeiten darbieten.

Die gleiche Agilität, die in den Projekten läuft. Kurze Feedbackzyklen, schnelle Entscheidungen, Backlog, der erst priorisiert und dann bearbeitet wird, darf auch auf der Ebene des Business gelebt werden. Keine fixierende Fünf-Jahresplanung mehr, sondern genau dann wenn wieder ein Projekt starten könnte, dann wird überlegt welches das genau dann beste Projekt ist.

Das ist die pure Herausforderung für klassisches Management. Wo lange Pläne Wertschätzung ausdrücken. Und an so einer Stelle sollen Sie jetzt von der Hand in den Mund leben? Mitnichten.

Ja es ist richtig, wenn Sie ein Projekt erst beginnen, wenn Sie auch die Ressourcen haben, dieses mit voller Kraft voraus zu bearbeiten, und dann sogar auch erst das Projekt auswählen, das begonnen wird, dann wird der Inhalt Ihrer Produktpipeline in der Tat unberechenbarer. Sie verlieren die Sicht auf Was Wann kommt. Und dennoch halte ich das für etwas Gutes. Es geht ja gerade darum, dass Sie das attraktivste Projekt, dass Ihnen vorliegt starten. Wenn Sie also von Ihrem 5-Jahresplan abweichen, dann doch genau deshalb, weil Sie eine bessere Chance gefunden haben, Ihre Ressourcen einzusetzen, ein besseres Projekt.

Und hier gilt ganz klar das Gute ist der Feind des besseren. Wenn Sie auf Businessebene nicht agil sind, wenn Sie nicht in der Lage sind, ein besseres Projekt vorzuziehen, dann entgehen ihnen Chancen Ihr Geschäft stärker auszubauen. Sie leben dann halt 5 Jahre mit Ihrem 5-Jahresplan und jede Verbesserung dessen wird ignoriert, weil jemand Stabilität vor Wertschöpfung stellt.

Stellen Sie Sich ein Buffet bei einer Konferenz vor. Das Social Event. Ein gutes Buffet. Auf dem Tisch steht das Menu mit der Auswahl, die Sie gleich sehen werden. Sie können nicht alles essen. Viel zu viele Gute Dinge. Also machen Sie Sich einen Plan.

Dann gehen Sie zum Buffet und ein Kollege, der gerade zurückkommt raunt Ihnen zu, dass der Lachs fantastisch ist. Sie schmeißen Ihren Plan in diesem Detail um. Lende raus, Lachs rein. Wie erleben Sie das? Haben Sie jetzt etwas besseres erreicht? War diese Flexibilität jetzt zu Ihrem Nutzen? Oder sind Sie jetzt ein Wackelkandidat, ein Umfaller, der keine Pläne durchziehen kann?

Das ist für mich Buisness Agility. Das Leben und Geschäftsleben sind voll von Gelegenheiten. Die Gewinner sind die, die diese Gelegenheiten genutzt haben und etwas tolles draus gemacht haben. Dafür müssen Sie Sich aus der Zwangsjacke befreien und sich selber den Freibrief geben diese Chancen auch zu nutzen.

Time to market quantifiziert – Cost of Delay nutzen um timing zu verbessern

Ich habe hier schon eigene Folgen zu Cost of Delay gemacht und auf diese sei hier verwiesen. Ich möchte das Thema aber hier nochmal aufgreifen, weil Cost of Delay dasjenige Werkzeug ist, das uns erlaubt Time to market auch wirtschaftlich auf Euro und Cent zu begreifen. Time to Market ist wichtig, ich habe jetzt schon einige Faktoren angesprochen ohne diese numerisch zu bewerten. Aber hier geht es ja auch um ZDF Zahlen, Daten, Fakten. Was bedeutet es für Sie, Ihre Time to Markt zu verbessern, was kostet es Sie, wenn Sie hier nicht handeln?

Cost of Delay berechnet die Kosten, die entstehen, wenn Sie eine Woche, ein Monat oder gar ein Jahr später auf den Markt kommen. Dabei werden nicht nur die direkten Kosten angeschaut (Mehraufwand, gebundene Ressourcen, Schleifen und Wiederholungen) sondern vor allem auf die Opportunitätskosten geschaut. Opportunitätskosten sind die Kosten, die sich berechnen aus dem entgangenen Nutzen, hier Gewinn, für Optionen, die Sie nicht realisiert haben. Wenn sie später als gewollt auf den Markt treten mit Ihrer Entwicklung, dann entgeht Ihnen Gewinn, die Konkurrenz ist schon da, langfristig kostet es Sie Marktanteile usw. Dieser entgangene Gewinn ist meist deutlich größer als die direkten Kosten. Das perfide ist, dass er nicht in den Projektkosten sichtbar wird und daher häufig vergessen oder ignoriert wird. Aber es sind harte EUR in dem Sinne, dass dies echter Gewinn ist, der sich am Ende des Projektes nicht realisieren lässt. Es ist also echtes Geld.

Sie können den Cost of Delay nutzen, um Ihre Time to Market zu verbessern. Einfach indem Sie erstens den Cost of Delay für Ihr Projekt berechnen und allen Projektbeteiligten bekannt machen und indem Sie zweitens dafür sorgen, dass das neue Wissen auch in die Entscheidungen im Projekt einfließt.

Ein Konstrukteur, der nochmal von vorne anfangen will, weil er sich in seinem Konzept verrannt hat und das jetzt keine so „schöne“ Konstruktion ist? Der Manager, der das Projekt in die Warteschleife schmeißt, weil er mit einer Entscheidungsvorlage nicht zufrieden ist und lieber in vier Wochen nochmal einen Anlauf machen will? All das Kostet Zeit. Das verlängert Ihre Time to Market und das kostet auch Geld. Ihnen entgeht messbarer Gewinn.

Das Wissen können und dürfen Sie nutzen, um Ihre Projektbearbeitungszeiten zu beschleunigen.

Wie kann ich meine Time to Market verkürzen?

Und damit sind wir auch schon mittendrin im zweiten Teil: Was können Sie denn tun, um Ihre Time to Market zu beschleunigen? Cost of Delay ist wichtig. Aber letztlich ist Gewinn ein nacheilender Indikator. Ein Indikator, der Ihnen hinterher sagt, ob Sie richtig oder falsch lagen. Und auch eine Prognose auf den nacheilenden Indikator macht daraus keinen voreilenden. Und wer hier schon ein paar Folgen gehört hat, der hat mir schon abgekauft, dass nacheilende Indikatoren geeignet sind um Schuldige zu finden und nur die voreilenden geeignet sind um zu managen.

Was Sie von agiler Softwareentwicklung für Produktentwicklung im Maschinenbau lernen können

Ich möchte Ihren Blick ein bisschen lenken Richtung Softwareentwicklung. Dort sind in den letzten Jahren und Jahrzehnten sehr spannende Dinge passiert, die sich teilweise sehr gut auch im Maschinenbau anwenden lassen.

Gerade der Bereich Agil und Lean wird in der Softwareentwicklung auf spannende Art anders gelebt als dies im Maschinenbau, gerade in der Fertigung, gelebt wird. Der große Unterschied zwischen Lean in der Entwicklung und Lean in der Fertigung ist, das die Fertigung viel Wert legt auf Berechenbarkeit, Wiederholgenauigkeit und generell jede Art von Abweichung ausmerzen will. Das sorgt für stabile Prozesse und guten Durchsatz. In der Entwicklung hingegen sind die Arbeitspakete viel unberechenbarer. Die Länge ist nicht klar, das Ergebnis ist nicht klar. Und auch durch mehr Planung lässt sich das nicht kompensieren, weil Unsicherheit in der Entwicklung sogar einen wirtschaftlichen Nutzen hat. Wenn sie entwickeln machen Sie Experimente. Wenn sie vorher wissen wie das Ergebnis ausgeht und nur die Experimente machen, von denen Sie wissen, wie sie ausgehen, schöpfen Sie keine Werte, sie generieren keine neuen Erkenntnisse. Neues Wissen wird durch Experimente generiert, deren Ergebnis nicht vorher klar ist. Das aber schafft Unsicherheit, in der Entwicklung sogar gewollte Unsicherheit.

Da ist uns die Softwareentwicklung und die IT näher als die Fertigung in der eigenen Branche.

Ein massiver Trend, weswegen sich auch Maschinenbauer mit schlanker Softwareentwicklung auseinandersetzen muss, ist, dass immer mehr Funktionen nicht in Hardware, sondern in Software realisiert werden. Eine Maschine, die früher eine große Welle und viele Getriebe hatte, damit sich alles synchron drehte, hat heute viele unabhängige Antriebe mit Frequenzumrichtern, die von Software synchron gehalten werden.

Wenn mehr Features in Software realisiert werden, heißt das aber auch, das Methoden der Softwareentwicklung in den Maschinenbau Einzug erhalten.

Schauen Sie Sich nur mal bei einem gebrauchten PKW das Navi und die Unterhaltungselektronik und vergleichen Sie dies mit dem, was auf Ihrem Handy heute geht. Hier ist noch ein sehr sichtbares Beispiel, wo die Koordination nicht funktioniert hat. Aus heutiger Sicht hat das schon Komik wie sehr da die Prozesse auseinander laufen.

Zweitens wurde Software ja nicht schon immer in so schnellen Zyklen entwickelt. Früher gab es in wichtigen Projekten massive Komplexität, die mit viel Projektmanagementaufwand und großen Teams abgearbeitet werden musste. Das hat heute noch den Namen Wasserfall oder Stage-Gate. Das Projekt durchläuft gewisse Phasen gleichzeitig.

Aus der großen Unzufriedenheit damals mit Termin- und Kostentreue sind andere Methoden entwickelt worden, Software zu entwickeln.

Gerade auch die Häufigkeit mit der Feedback vom Kunden eingeholt wird hat sich erheblich vergrößert. Dadurch sind Markt oder Kunde und das Projekt nicht so weit auseinandergedriftet, auch wenn das Projekt länger gebraucht hat.

Ferner fokussieren sich die Entwicklungsmethodiken mehr darauf, die Abarbeitung der Arbeitspakete zu verbessern und dadurch mehr Werte zu schaffen als einfach zu planen und dann mehr Plantreue einzufordern. Hier wird teilweise sehr agil die Reihenfolge und Wichtigkeit von Features im laufenden Projekt neu bewertet, aber immer zu Gunsten von Features, die dem Kunden mehr Nutzen bringen. Man kann hier also sehen, das die Inhalte unplanbarer werden, aber die Wertschöpfung sich dadurch verbessert und nicht verschlechtert. Im Maschinenbau gilt ja häufig noch der Glaubenssatz, dass wenn ein Projekt nur gut genug aufgeplant wird, jede Abweichung von diesem Plan negativ zu bewerten ist. Die Softwareentwicklung zeigt, dass dem nicht so ist. So sehr, dass mittlerweile deutlich weniger Wert auf detaillierteste Planung gelegt wird, weil diese für die Wertschöpfung unerheblich ist.

Auch die Entkopplung der Komponenten untereinander ist ein ganz großes Thema in der Softwareentwicklung, denn durch diese Entkopplung kann viel schneller in den Subsystemen entwickelt werden, ohne die anderen zu stören. Auch das ist ein Konzept, das sich sehr gut aus der Softwareentwicklung übernehmen lässt.

Jede Maschine lässt sich mehr oder weniger integriert bauen. Wenn Sie Ihre Produkte mit gut voneinander entkoppelten Subsystemen aufbauen, dann lassen sich Änderungen schneller umsetzen.

Und zuletzt noch ein Konzept. Software wird in Schichten gebaut. Datenbank unten, Kundenschicht oben und dazwischen Middleware. Sie können eine Software von herunterladbarem Programm zu Webseite mit gleicher Funktion umbauen indem Sie nur die Kundenschicht ändern und die beiden anderen darunter konstant lassen. Die IT-affinen Personen unter Ihnen mögen mir diese massive Vereinfachung nachsehen, mir geht es um das Konzept, verschiedene Subsysteme so weit voneinander zu entkoppeln, dass sie unabhängig voneinander entwickelt werden können. Das ermöglicht dann auch sehr kundenindividuelle Lösungen zu realisieren. In einer frühen Episode hatte ich mal das Beispiel einer Kleintierwaage für Tiermediziner. Gleiches Innenleben, wie die Gemüsewaage auf dem Markt, aber ganz andere Anforderungen an die äußere Hülle (abwasch- und desinfizierbar, Datenschnittstelle zum Praxisprogramm, usw.).

Entkopplung bietet Ihnen große Möglichkeiten, auf spezifische Kundengruppen viel intensiver einzugehen, als dies bisher der Fall war. Und nebenbei verkürzen Sich auch Ihre Zyklen.

Das Thema ist groß genug um es mal in eigenen Folgen auseinanderzunehmen.

Agiler Kulturwandel im Unternehmen

Fangen Sie den Agilen Kulturwandel für Ihr Unternehmen in Ihrer eigenen IT an. Erstens schadet eine schlagkräftige IT nicht und zweitens haben Ihre Mitarbeiter hier schon von Scrum und DevOps gehört. Entweder sie leben es schon, oder sie hören von draußen immer wie toll das ist und Sie rennen hier mit Ihrer Initiative offene Türen ein.

Gleichzeitig dürfen Sie Sich in der Führung damit auseinandersetzen, was es heißt Business Agility groß zu schreiben. Also wie schaffen Sie es vorzuleben, was Sie von anderen verlangen. Dazu gehört eine Kultur des Feedbacks in kurzen Schleifen, der Reaktionsschnelle auf Entwicklungen und eine gewisse Kultur, seine Entscheidungen datenbasiert zu fällen.

Generell achten Manager zu sehr auf Ressourceneffizienz und zu wenig auf Floweffizienz. Sie bekommen in BWL als Haupt- oder Nebenfach beigebracht, dass eine Maschine bestmöglich ausgelastet sein soll. Damit die Stückkosten minimal werden und der Gewinn maximiert wird. Das galt mal als Mehrheitsmeinung in der Fertigung und ist dann durch Lean abgelöst worden mit einer Fokussierung auf den Wertstrom durch die Fabrik und stark ausgelastete Ressourcen bringen Verzögerungen in den Ablauf.

In der Entwicklung war es noch nie richtig dafür zu sorgen, dass Ressourcen stark genutzt sind. Hier ist es viel wichtiger, dass Ressourcen dann zur Verfügung stehen, wenn die Projekte sie brauchen, damit diese nicht verzögert werden. In der Episode zum Cost of Delay haben wir herausgearbeitet, dass die Kosten durch Verzögerung viel höher sind als die direkten Kosten. Hohe Ressourcenauslastung macht keinen Sinn.

Und zuletzt gehört zu Business Agility, kleine Projekte zu machen. Ein Projekt wie der Berliner Flughafen, der Stuttgarter Bahnhof oder der Elbphilharmonie mag zwar geeignet sein, den beteiligten Politikern ewigen Ruhm zu geben (sobald sie dann mal fertig sind). Aber in einer Produktentwicklung von der die Zukunft der Firma abhängt ist ein solcher Umgang mit der Zeit schlicht nicht akzeptabel.

Es geht mehr als Sie denken

Ich möchte an dieser Stelle Werbung machen, dass Sie Sich nicht zu sehr im Denken einschränken. Während es schwierig ist, für etwas die Kosten zu halbieren oder den Gewinn zu verdoppeln, eben weil hier viele Augen drauf schauen und offensichtliche Potentiale schnell genutzt werden, so gilt dies beim Thema Zeit nicht. Viele Manager wissen gar nicht, wie sie es anstellen sollten, einen Vorgang in der halben Zeit abzuschließen. Wenn aber jemand, der sich mit so etwas auskennt, der Sache annimmt, dann kommen erstaunliche Fortschritte dabei heraus. Dies liegt daran, dass wir bei allem Druck Zeit meistens nicht gut managen. Dadurch sind hier meist auch noch ganz erhebliche Potentiale.

Das Nachher die umstehenden sagen: „Das war aber unkonventionell“ sagt nicht so viel über die Beschleunigung aus, sondern mehr darüber wie wenig dieses Wissen im Mainstream verfügbar ist.

Hier sind mal zwei Beispiele von Projekten die verglichen mit dem, was wir für normal halten massiv beschleunigt wurden und das durch Methoden, die eigentlich nicht unkonventionell sein sollten.

Hier wird eine Prachtstraße in Moskau neu geteert. Mehrere hundert Meter lang, viele Spuren breit an einem Tag. Das Video ist aufschlussreich. Hier sind die wichtigsten Takeaways. Erstens es arbeiten genau so viele Teermaschinen, wie notwendig um die Breite der Straße abzudecken. Das ist das Maß an Parallelität, das notwendig ist. Eine Maschine zu wenig und eine Maschine muss die Strecke zweimal fahren und die Baustelle dauert doppelt so lange. Eine Maschine mehr und sie hätte nichts zu tun. Dies ist der Engpass. Vor den Teermaschinen eine Armada von LKW, die neuen Teer ranschaffen. Bloß nicht den Nachschub stocken lassen, damit die Teermaschinen immer arbeiten können. Hier sieht es nach zu vielen LKW aus, weil ja immer welche herumstehen und nichts machen. Aber, das ist wichtig, damit der Engpass, die Teermaschinen durcharbeiten können. Wenn die Teermaschinen vorgefahren sind und eine Asphaltdecke hinterlassen kommt eine Menge Walzen ins Spiel, die den Asphalt glättet.

So eine Baustelle ist sehr gut kalkulierbar. Man weiß, wie viel Teer eine Teermaschine pro Stunde macht und wenn man sie gut versorgt halt, dann kann sie das auch leisten. Also hat man hier ein Projekt, dass sehr schnell durchgezogen wurde, aber in der Kernkonzeption nicht zu fragil ist.

Ein zweiter Film ist ein Tunnel unter der Autobahn in Holland. Hier wird der Tunnel als Betonkasten neben der Autobahn vorbereitet und dann die Autobahn nur für ein Wochenende aufgegraben, um den Tunnel einzubringen.

Auch hier ist eine wichtige Lektion Dinge vom kritischen Pfad wegzuhalten. Der Tunnel ist komplett vormontiert und wird auf Schienen an seinen Platz gebracht, ein Tag, nachdem die Autobahn aufgegraben wurde und einen Tag später war der Tunnel vergraben, die Teerdecke wieder hergestellt. Welche Möglichkeiten haben Sie, den kritischen Pfad zu entlasten und schon mal Dinge vorzubereiten, die sonst Zeit kosten. Ich kenne mehr als einen Einkauf, der gerne mit fertigen Zeichnungen zum Lieferanten gehen will, weil er dann die meiste Macht beim Preise verhandeln hat. Wird zu früh verhandelt kann ein pfiffiger Lieferant für jede Änderung den Preis anpassen und der Preis endet dann im Endeffekt höher. Nur: Wo ist hier das globale Optimum? Der Einkauf setzt hier Zeit ein, um sein Siloziel zu erreichen.

Ich habe in meiner eigenen Geschichte Lieferanten von Anlagenbaukomponenten gehabt, die wir spezifisch für die Anlagen gekauft haben, die also noch konfigurieren mussten. Wir hatten da regelmäßig 8-12 Wochen Lieferzeit auf den Komponenten, was uns immer wieder zu Problemen bei unseren Aufträgen geführt hat. Also habe ich den Lieferanten vorgegeben, dass wir in Zukunft in 2 Wochen nach Lieferung beliefert werden wollen. Wir haben das mit mehreren Lieferanten geschafft, mit jedem gab es ein individuelles Vorgehen, für jeden Lieferanten haben wir auch Änderungen bei uns gemacht, dass es denen leichter fällt. Warum 2 und nicht 6 Wochen? Von 8 auf 6 Wochen, da wäre die Versuchung groß gewesen, das mit mehr Druck und mehr Managerfingern im Prozess zu lösen. Das hätte ein paar Male geklappt und danach nicht mehr. Für 2 Wochen mussten wir uns die Prozesse hüben wie drüben anschauen und aufräumen. Es war immer Arbeit auf beiden Seiten, aber das Ergebnis war dann auch, dass die 2 Wochen zuverlässig funktioniert haben. Kostensteigerungen? Keine, das war Bedingung.

Ich habe an anderer Stelle schon mal eine Episode zu Großen und Kleinen Zielen gemacht. Mein Fazit damals war, dass ich Große Ziele bevorzuge. Faktor 5 statt 5% weil Sie um das zu erreichen anders denken müssen und das Problem grundsätzlich hinterfragen. Und häufig geht es auch, nur nicht, wenn man nicht nachdenkt. Jedes Jahr 5% bringt einen eigentlich auch ans Ziel, aber da ist die Versuchung zu groß, jedes Jahr nur den Druck zu erhöhen und nicht das System zu verbessern. Das Ergebnis ist, dass die 5% dann doch nicht erreicht werden und keiner mehr zufrieden ist. Oder das Ergebnis ist, dass mögliche Verbesserungen nicht wahrgenommen werden, um nächstes Jahr noch Luft zu haben. Auch nicht gut.

Seien Sie mutig, meist geht mehr als Sie denken, aber eben nur, wenn Sie strukturell aufräumen und lernen die richtigen Fragen zu stellen und die richtigen Probleme zu lösen. Und darum geht es hier bei Smarter Entwickeln. Wir wollen die Produktentwicklung im Maschinenbau von der Wertschöpfung her neu denken und mit allen Methoden, die uns voran bringen die richtigen Produkte für die richtigen Kunden schnell auf den Markt bringen.

In diesem Sinne haben Sie eine erfolgreiche Woche, Ihr Florian Kuhnke

Entchen in einer Reihe angeordnet

Optimal Projekte priorisieren mit COD3

018 – Optimal Projekte priorisieren mit COD3

Die Herausforderung

Sie haben eine Entwicklungsabteilung und viele tolle Projektideen. Sie haben verstanden, dass wenn Sie alles gleichzeitig machen wollen, Sie alles verspätet bekommen. Also wollen Sie Priorisieren. Die Projekte in der sinnvollsten Reihenfolge abarbeiten.

Der Controller zeigt den ROI. So hat er es gelernt, Geld ist knapp, also muss das beste daraus gemacht werden.

Der Werksleiter schreit nach den Produkten, die hier am Standort gefertigt werden, klar, er will seinen Overhead schön auf Volumen verteilen. Seine Zahlen sehen am Besten aus, wenn der weder überlastet ist, noch unterausgelastet ist, sondern genau das verkauft wird, was er fertigen kann und dabei die Umlagen sich auf viele Aufträge verteilen.

der Vertrieb will die Produkte, die sich am besten verkaufen, so lässt sich am meisten AE hereinholen und von Aufträgen leben Sie doch. Oder er schreit nach Entwicklungen, damit der Wettbewerbsnachteil ausgeglichen wird, den Sie bei einem Produkt hat. Er würde gerne wieder das versprochene Volumen liefern, aber bei der Konkurrenzlage, keine Chance.

Das Marketing will jetzt endlich die Big-Data-Komponente umgesetzt haben, damit sie damit auf die Messe gehen können. Sie wollen doch ein modernes Image, oder nicht.

Und Sie als Leitung sitzen dazwischen und wollen Struktur in diese Unruhe bringen. Aus der Kakophonie der Anforderungen ein schlüssiges Konzept machen. Hat nicht das Produktmanagement eine Entscheidungsvorlage gemacht? Und während Sie diese noch suchen, kommt ein kleiner frecher Gedanken hoch: Keiner Ihrer Leute hat vom Kunden her argumentiert, keiner hat über seine Silogrenzen hinaus gedacht, keiner hat die Punkte der anderen aufgenommen, geschweige denn deren Sprache gesprochen.

Sie können sich jetzt für einen entscheiden, aber dann verärgern Sie N-1 andere. Es steht Ihnen zu, diese Entscheidung zu fällen. Aber warum sollten Sie das eigentlich machen? Ist das nicht eigentlich eine Sachentscheidung? Oder zumindest eine, die sich sachlich vorbereiten lässt, auch wenn dann noch etwas Unsicherheit bleibt? Wo ist denn die Entscheidungsvorlage vom Projektmanager, sie hätten gerne eine Liste der Projekte in einer Reihenfolge. Erstens, zweitens, drittens und wenn wir können viertens. Mit Zahlen, Daten, Fakten Argumenten und einem sinnvollen Vergleich. Kurz, eine Entscheidungsvorlage mit einem Vorschlag und unterstützenden Argumenten.

Haben Sie dies so oder ählich schonmal erlebt? Dann ist diese Episode für Sie, denn ich möchte Ihnen einen Weg herausweisen.

Aber zuerst nochmal ein Schritt zurück: Was wollen sie eigentlich erreichen?

Sie haben begrenzte Möglichkeiten. Eine existierende Entwicklungsabteilung. Eine bestimmte Gruppengröße der Konstruktion, eine bestehende Prüfstandsinfrastruktur, ein bestimmtes Budget, dass Sie Sich leisten können, Kundenbedüfrnisse und eine gewisse Ahnung, wo die Märkte hingehen. Kurz, Sie haben jede Menge Randbedingungen, die gegeneinander abgewogen werden müssen.

Sie wollen ein erfolgreiches Unternehmen führen. Erfolgreich kann vieles bedeuten, die Sinnfrage beantwortet jeder unterschiedlich. Aber allen Sinnfragen ist eines gemeinsam: Sie werden Ihr Ziel nur erreichen, wenn Sie die Möglichkeiten dazu haben. Dazu brauchen Sie Geld. Geld ist ein Potential, ein Rohstoff, den Sie einsetzen können, um die Ziele zu erreichen. Um es frei für Ihre Ziele einsetzen zu können muss es frei sein, übrig nach dem alle Kosten abgezogen worden sind. Gewinn also.

Beantworten Sie Sich Ihre Sinnfrage, wie sie wollen, der Weg dahin führt über Gewinn. Dabei müssen Sie Gewinn nicht notwendigerweise herausziehen, sie können auch Reinvestieren oder bestimmte Dienstleistungen dadurch subventionieren, weil Sie etwas zurückgeben möchten.

Sie wollen schnell auf dem Markt sein. Das Rad dreht sich schneller, die Konkurrenz ist schneller, es kommt Konkurrenz aus technologien, die sich viel schneller entwickeln. Früher wurden Maschinen mit spannenden Getrieben gebaut und konnten eine Bewegung durchführen. Heute läuft das alles in Software. Andere Bewegung vom Roboter -> Software, andere Hubkurve an der Presse -> Parameter, andere Belüftungsstrategie -> Software.

Diese anderen Technologien kommen in Ihren Markt und verändern das Tempo. Nicht selten wird dabei die Zeitskala um den Faktor 10 oder 100 verkürzt. Etwas was früher vier Monate gedauert hat, 100 Tage, weil es konstruiert, gebaut, verschifft, verzollt, eingebaut und in Betrieb genommen werden musste, wird jetzt als Softwareänderung über Nacht eingespielt.

Hier halten Sie nur mit, wenn Sie ähnlich agil werden. Wenn Sie ein Produktmanagement haben, dass nicht versucht zu erraten, wie die Welt in fünf Jahren aussieht und dann ein die Firma verwettet auf ein paar wenige große Projekte mit langer Laufzeit.

Sie fühlen sich zunehmend unwohl damit, die Priorisierung als Verhandlungsergebnis zu sehen. Jeder bringt seine Vorschläge, Ideen, Forderungen und Taktiken mit und am Ende hat sich durchgesetzt, wer am meisten und am lautesten geredet hat. Die schlagfertigsten Antworten parat hatte um die Kollegen am durchsetzen Ihrer Punkte zu hindern.

Warum soll ein für die Firma besseres Ergebnis herauskommen, wenn ein extrovertierter Vertriebler einen introvertierten Controller unter den Tisch quatscht?

Sie wollen eine sachliche Entscheidungsbasis. Eine, die schon auch mal überstimmt werden kann, wenn der Bauch gar in eine andere Richtung zeigt, aber eine Basis, die hilft die Interessen aller auf einem Maßstab abzubilden und hinterher auch hilft, der ganzen Firma zu erklären, warum die Entscheidung denn so gefallen ist.

Denn nur, wenn Sie es schaffen, die Priorisierung der Führungsebene und dem Rest des Hauses zu verkaufen, haben Sie die Chance, dass sich die Leute danach richten. Die Priorisierung für ihre Entscheidungen nutzen und dadurch auch nicht nur am gleichen Strang zu ziehen, sondern auch am gleichen Ende. Kurz eine Priorisierung, die vom Haus aufgegriffen wird, führt dazu, dass alle in die gleiche Richtung marschieren und Sie die Energie in die Erreichung der Ziele und nicht in interne Querelen stecken.

Sie brauchen eine Methode, die diese Kriterien erfüllt. Eine Methode, die Sie weitergeben können, mit der das Team arbeiten kann, mit der eine schlüssige Entscheidungsvorlage erstellt werden kann.

Damit Sie eine Entscheidungsvorlage bekommen, die Sie aufnehmen können und verabschieden können. Sie geben die Methode vor und behalten die Kontrolle. Ihr Team bereitet die Daten auf und sie kommen mit einer einheitlichen, vermittelbaren Priorisierung aus dem ersten Meeting.

Klingt gut? Hier ist mein Vorschlag und ich will Ihnen auch erläutern warum ich so denke.

Cost of Delay divided by duration. COD3.

Sie nehmen den Cost of Delay eines Projekts. Also, den entgangenen Gewinn, wenn sich dieses Projekt verzögert. Wie das geschieht, dazu habe ich schon eine Episode gemacht. Das Beispiel damals war ein COD von EUR 100.000 pro Woche.

Ferner schauen Sie sich an, wie lange ihre Engpassressource von diesem Projekt belegt wird. Also wie sehr Sie andere Projekte verschieben, wenn Sie dieses Projekt vorziehen.

Der Engpass ist die Ressource, die für Ihr System durchsatzbestimmend ist. Man kann sie systematisch sichtbar machen mit Kanban-Boards und Cumulative-Flow-Diagrammen aber sie sind meist auch intuitiv zugänglich und sichtbar daran, dass hier die meisten Projektverzögerungen und Konflikte auftauchen.

Das kann eine Konstruktion sein, das kein ein Prüfstand sein, eine Qualitätsischerung, die mit der Erstbemusterung nicht hinterher kommt oder andere Abteilungen. Meist teure Spezialisten, die aber dringend gebraucht werden.

Wenn Sie 30 Konstrukteure haben und für ein Projekt 300 Teile à 30 Stunden Aufwand konstruieren müssen, dann binden Sie 300 Mannwochen Konstruktion. Bei 30 Konstrukteuren blockieren sie damit die Konstruktion für andere Aufgaben für 10 Wochen. Kurz, wenn Sie dieses Projekt machen, schieben sie alle anderen Projekte 10 Wochen nach hinten verglichen mit dem Fall, das Projekt nicht zu machen oder nach allen anderen zu machen.

Aus diesen beiden Zahlen bilden Sie jetzt den Quotient. Also EUR 100 000 pro Woche durch 10 Wochen. Die Einheit ist Euro pro Woche im Quadrat, eine Einheit, mit der man zwar abstrakt arbeiten kann, die aber nicht unmittelbar zugänglich ist.

Es geht einfach nur darum, den Nutzen eines Projektes mit dem Aufwand ins Verhältnis zu setzen. Der Begriff Cost of Delay kommt vom Begriff der Opportunitätskosten. Und Opportunitätskosten sind entgangene Gewinne, wenn Sie ein Projekt verschieben, bzw. Gewinne, die Sie erwirtschaften, wenn Sie das Projekt jetzt machen. Es geht also um Gewinnsteigerung.

Und der Delay ist die Zeit, die eine Engpassressource durch dieses Projekt blockiert ist. Also letztlich ein Maß für den Preis, den wir zahlen, um das Projekt durchzusetzen. Ich habe diverse Episoden zu Warteschlangen und Priorisierung gemacht, in denen ich auf die Details eingehe.

Also einfach nur ein bestimmtes Maß für den Nutzen (Gewinnsteigerung, die mir nicht entgehen soll) durch einen Aufwand (Engpassressource, die ich unwiederbringlich in dieses Projekt investiere und für nichts anderes heranziehen kann). Nutzen durch Aufwand. So bekannt.

Kleiner Exkurs für Ingenieure: Erinnern Sie Sich an Kinematik? Weg, Geschwindigkeit, Beschleunigung? Was waren denn da die Einheiten dran? Welche Dimension hatten Sie da? Das waren m, also Länge für den Weg. m/s für die Geschwindigkeit also Länge durch Zeit. Und Länge durch Zeit zum Quadrat, also m/s2 war die Einheit der Beschleunigung.

Was sind also EUR/Woche2?

EUR ist die Einheit vom Gewinn.

EUR/Woche ist die Einheit des Gewinnwachstums und

EUR/Woche2 ist die Einheit für die Gewinnbeschleunigung.

Die Entwicklungsabteilung ist also nichts anderes als das Gaspedal Ihres Unternehmens und unsere Priorisierung zielt auf nichts anderes als die maximale Beschleunigung für Ihren Gewinn zu erreichen. Und dazu suchen wir uns die Projekte aus, die den größten Beschleunigungswert aufweisen.

Das ist auch der Moment, nochmal an Alois Gälweiler zu verweisen, der sein vierstufiges Modell hatte, dass die Entwicklung die zukünfitge Marktposition beeinflusst, die aktuelle Marktposition (Marktanteil, Marktführerschaft) beeinflusst den Gewinn und der wirkt sich auf den Cash aus. Cash bestimmt letztendlich über Leben und Tod, also Insolvenz einer Unternehmung. Hier schließt sich also wieder der Bogen zur Episode Werte schaffen in der Entwicklung.

Ich will nicht über klassisches Multi-Projektmanagement lästern, nur, wer sich damit im Detail auseinander gesetzt hat, weiß noch, wie kompliziert es ist, die verschiedenen Abhängigkeiten abzubilden. Und wie überaschend die Kaskade von Änderungen, die in einem Projekt gestartet sind dann durch die anderen schwappen. Nicht selten kamen dabei große Veränderungen an den Zeitplänen heraus, die komplex und unberechenbar waren, so dass sich dann auch keiner mehr dafür verantwortlich zeigen wollte.

COD3 ist eine sehr einfache Methode, deren ganz großer Vorteil auch darin besteht, dass die Kennzahl, nach der sortiert wird für ein Projekt berechnet werden kann, ohne, dass Abhängigkeiten zu anderen Projekten bestehen. Das sorgt für ruhigere Ergebnisse, weil sich die Kennzahl nur ändert, wenn sich an meinem Projekt etwas ändert und das wiederum fürht dazu, dass sich die Mitarbeiter auch mit den Ergebnissen des Projektes identifizieren und bereit sind, sich daran auch messen zu lassen.

Priorisieren mit COD3

Wie gehen Sie daran, COD3 bei Ihnen zu implementieren?

Für jedes Projekt haben Sie eine Projektergebniskalkulation, also eine Rechnung, wie das Projekt sich auf Ihr Ergebnis auswirken wird. Welche Aufwände haben Sie? In welcher Höhe und wann? Welche Auswirkungen hat das Projekt? Stückzahlen, Marge, AE, Umsatz, Kosten und letztlich Gewinn?

Dies ist die Grundlage für Ihren Szenariovergleich. Vergleichen Sie den Gewinn für ein pünktliches Projekt mit einem verspäteten Projekt. Sehen sie dabei die direkten Kosten (Prüfstand länger benutzt, Mitarbeiter länger im Projekt gebunden) machen Sie sich aber vor allem Gedanken darüber, wie das Projektergebnis im Markt beeinflusst wird.

Wenn sie später fertig werden, verlieren Sie dann Verkäufe? Fast sicher.

Kann es sein, dass Sie Probleme haben werden, den angenommenen Marktanteil zu realisieren. Gerade wenn eine neue Nische besetzt werden soll, kann ein verspäteter Markteintritt zu empfindlich kleineren Marktanteilen führen.

Sind Sie in einem kurzlebigen Markt? Wie lange lässt sich das Produkt überhaupt verkaufen (Regulatorische Einflüsse, aber auch Moden). Das kann Ihre Projektergebnisrechnung empfindlich beeinflussen.

Jetzt kennen Sie den Cost of Delay. Jetzt brauchen Sie noch den Teiler.

Was ist Ihr Engpass? Was ist ihre knappe Ressource, die bestimmt, wie viele Projekte Sie im Jahr schaffen. Controller, Geschäftsführer und andere kaufmännisch denkende Menschen sagen häufig: Geld. Aber stellen Sie sich vor, sie würden doppelt so viel Geld bereitstellen, würden Sie dann doppelt so viel Ergebnis sehen? Kann ich einmal die Hände sehen, von denen, die glauben, dass Geld die wahre Knappheit ist?

Es sind meistens andere Dinge. Ich reite hier nicht umsonst im Podcast so viel auf Beispielen herum, die davon ausgehen, dass die Konstruktion der Engpass ist. Gerade in gewachsenen Betrieben, wo früher am Reißbrett gearbeitet wurde, wird schnell vergessen, dass durch die Einführung von CAD nicht nur eine Beschleunigung der Konstruktionsarbeit stattgefunden hat, sondern auch viele Aufgaben in der Konstruktion gelandet sind.

Ein Gussteil wurde früher gezeichnet und der Formenbauer musste an unzähligen Stellen noch Details in die Zeichnung hereininterpretieren. Das war OK, das war die Arbeitsteilung und die hat funktioniert. Eine 3D-Konstruktion muss aber alle Details vorgeben. Einen Formenbauer, der Lücken füllt gibt es nicht mehr, die Fräse, die die Form aus dem vollen Fräst nimmt nur Daten aus der Konstruktion. Garbage in – garbage out. Das gleiche bei Stammdaten, Lieferanten usw. An vielen Stellen macht die Konstruktion heute mehr Wertschöpfungstiefe als früher.

Natürlich können Sie Externe einsetzen. Aber wie viele? Wenn Sie sich mit dieser Thematik auseinandersetzen sind sie nicht irgendwer, sondern erster, zweiter oder dritter in Ihrem Markt. Sie können etwas besonders gut, dass sie heraushebt. Und da soll ein allgemeiner Konstruktionsdienstleister gleichwertige Arbeit machen können? Das funktioniert in Excel-Sheet des Controller, aber nicht ich der Kernkompetenz des Unternehmens.

Davon unbenommen ist natürlich die Möglichkeit unspezifische Arbeiten abzugeben, das kann ganz gut klappen.

Dieser Engpass begrenzt den Durchsatz für alle. Ich kann noch so viele Einkäufer haben, wenn die Konstruktion nicht nachkommt, drehen die Einkäufer halt Däumchen. Der Durchsatz wird im Engpass bestimmt und Prozessverbesserungen sind auch nur im Engpass relevant für den Durchsatz.

Der Engpass kann auch in den Prüfständen liegen. Teure Investitionsgüter, die man nicht eben mal baut. Schauen Sie genau auf Ihren Fall und lassen Sie sich ggfs helfen.

Jetzt schauen Sie in den Projektplan und bewerten Sie den Aufwand im Engpass. Der Aufwand geteilt durch Ihre Kapazität im Engpass ist die Zeit, die sie den Engpass für dieses Projekt monopolisieren. Die Zeit, die andere warten müssen.

Diese zwei Zahlen setzen Sie zusammen zu COD3.

Noch haben Sie nur innerhalb des Projektes gearbeitet, keine Abhängigkeiten der Projekte untereinander. Diesen Schritt können Sie also für jedes Projekt einfordern, noch bevor eine Entscheidung fällt über tun oder nichts tun.

Diese Kennzahl funktioniert am besten, wenn es einen konkreten, berechenbaren Nutzen gibt. Technologie-Projekte, Vorentwicklungen, Strategischen Themen und ganz neue Geschäftsfelder sind schlechter zu erfassen als konkrete Produktentwicklungen für bekannte Märkte mit bekannten oder gar bestehenden Kunden. Ihnen wird die Führungsaufgabe also nicht vollständig abgenommen.

Mit diesen Zahlen gehen Sie in den Vergleich. Und dann sehe ich das ganz nüchtern: Wer schnell fahren will muss gut beschleunigen. Nehmen Sie also die Projekte, die Ihren Gewinn am meisten beschleunigen nach vorne und machen Sie die anderen später.

Jetzt wird es etwas Geschrei geben, weil die Reihenfolge der Projekte nach COD3 wahrscheinlich anders aussieht, als sich das Vertrieb oder Produktion gewünscht haben. Das ist aber auch in Ordnung. Sie priorisieren ja nicht mehr nach den Partikularinteressen der Silos, sondern nach dem Gesamtwohl der Firma. Gewinn. Und Gewinn können Sie dan reinvestieren und das Rad schneller drehen lassen oder anderweitig verändern, so, wie Sie Sich Ihre Sinnfrage beantwortet haben.

Jetzt kommen wir an einen spannenden Punkt, und ich will ja auch, dass Sie Sich freuen, die Episode ganz angehört haben.

Wenn jetzt jemand unzufrieden ist, mit der Platzierung auf der Rangliste. Kann er oder sie sich bemühen, das Projekt so zuzuschneiden, dass es attraktiver wird.

Erinnern Sie Sich an diesen einen Mitschüler, der nach jeder Klausur zum Lehrer hingegangen ist, um die Note nachzuverhandeln. Ich musst immer feixen, wenn der Lehrer geantwortet hat: Es gibt einen ganz einfachen Weg, die Note zu verbessern. Du setzt Dich hin, lernst die Vokabeln, nächstes Mal machst Du weniger Fehler und schwuppdiwupp ist Deine Note besser.

Hier ist es genauso. Jeder ist seines eigenen Glückes Schmied. Jeder hat es in der Hand ein Projekt attraktiver zu machen. Nehmen wir an Pareto hatte Recht. Und es geht hier nicht um die absoluten Zahlen, sondern um das Prinzip, das Aufwand und Ergebnis meist sehr ungleich verteilt sind. Dann lassen sich in jedem Projekt die 20% Aufwand finden, die für 80% des Ergebnisses veranwortlich sind. Das ist viermal so viel Nutzen pro Aufwand wie das ursprüngliche Projekt.

Schauen Sie sich die Projekte an. Dann machen wir das noch, und das gleich mit, und wir haben schon so lange nichts neues mehr gemacht, das muss der große Wurf werden… Viele Projektentwürfe haben eine fette Speckschicht angesammelt. Schneiden Sie die rigoros ab.

Laden Sie die Projekte zum Wettbewerb ein. Laden Sie zum manipulieren der Rangliste ein. Wer sein Fett so abgeschnitten bekommt, das pure Wertschöpfung über bleibt, der hat es dann auch verdient als erstes bedient zu werden.

Das hat drei Effekte. Erstens werden dadurch die Projekte kleiner, kürzer, sie sparen Sich überflüssigen Aufwand und verringern dadurch die Zeit am Flaschenhals. Kürzere Projekte machen Sie agiler und sie können mehr Innovationen pro Jahr auf den Markt bringen.

Zweitens ist der Wettbewerb ein gesunder, weil die Projekte besser werden. Es geht nicht darum, wer am meisten schreit, wer am besten erzählt, sondern darum, welches Projekt am meisten Werte schafft. Unzufrieden, verbesser Dein Projekt.

Und drittens, setzt diese Methode Kreativität frei. Hier ein kleines Beispiel. Der Einkauf hat eine Reihe von Kostenreduktionsthemen, die nicht abgearbeitet werden, weil sie nicht auf der gleichen Liste stehen wie die Entwicklungsprojekte. Sie sind auch nicht so sexy. Aber, es kann durchaus sein, dass diese Themen sehr attraktiv sein können, weil sie große Einsparung bringen für verhältnismäßig wenig Konstruktionsaufwand. Aufwand, den auch der Lieferant übernehmen könnte, wenn er ins Geschäft kommen will. Der Engpass ist die Konstruktion in der eigenen Firma, nicht Konstruktionsaufwand allgemein. Dadurch lassen sich ideen schnell mal um den Faktor 10 in der Bewertung verbessern.

Sie merken also, ich will ihnen die Methode wärmstens ans Herz legen.

Wer mehr darüber lesen will kann bei Donald Reinertsen The Principles of Product Development Flow fündig werden. Ein Link ist in den Shownotes. Das Buch ist Gold wert für Menschen, die sich mit der wirtschaftlichen Seite der Produktentwicklung beschäftigen. Es ist auch das Buch, das ich am meisten verschenkt habe.

Nächste Woche gehe ich nochmal spezifisch auf Time-To-Market ein. Ich will diskutieren, warum kurze Entwicklungszeiten überproportional wertvoll sind. Ich freue mich darauf, Sie dann wieder begrüßen zu dürfen.

Stau

Die wahren Kosten der Warteschlange

017 – Die Echten Kosten der Warteschlangen

Heute will ich mal ein paar Dinge zusammenziehen, die ich in den vergangenen Episoden vorbereitet habe.

Aber zuerst: Zwei Geschichten:

Oma und Kleinfritzchen gehen auf dem Fußweg. Kleinfritzchen sieht einen Hunderteuroschein auf der Straße liegen und will ihn aufheben. Oma lässt ihn nicht und zieht ihn weiter. Kleinfritzchen meckert und zetert aber Oma sagt: Den Hunderteuroschein gibt es nicht, denn wenn es ihn gäbe hätte ihn schon jemand mitgenommen. Keiner lässt doch einen Hunderteuroschein liegen.

Neben dem Fußweg herrscht Stau in der Stadt. Zu viele Autos wollen die Einfallstraße reinfahren und der Verkehr steht. In jedem Auto sitzt eine Person. Eine Handwerker, eine Ärztin, ein Lehrer, eine Ingenieurin, Programmierer, Erzieher, Händler, der Stau ist ganz demokratisch, jeder hat seinen eigenen Stehplatz auf der Fahrbahn.

Wenn man sich mal den Stundenlohn zusammenrechnet, der hier verprasst wird, ist das schon faszinierend. Ach nehmen wir nicht den Lohn, sondern die Kosten für den Arbeitgeber mit Steuern, Nebenkosten und Overhead.

Da sind wir bei schnell bei EUR 200 pro Fahrzeug und Stunde. Ein Fahrzeug ist 5 m lang, also EUR 40 pro Meter Fahrbahn. EUR 40 000 pro Kilometer.

EUR 80 000 für zwei Spuren.

Morgens und Abends, fünf Tage die Woche. EUR 800 000.

Und alles nur wegen einer Baustelle, ein Rohr ist geplatzt, die Straße wurde aufgegraben, notdürftig geflickt aber bis die Reparatur endlich fertiggestellt werden kann und die Straße wieder freigegeben wird muss noch das Bautrupp noch woanders fertig werden.

10 Wochen dauert das. 8 Millionen. Die Wartezeit ist ein Vielfaches teurer als die direkten Kosten der Baustelle. Aber die Kosten sieht die Stadt ja nicht und zahlt die Stadt ja nicht.

Wartezeit kostet. Viel, viel mehr als die Baustelle selber. Die Zeit, die die Leute nicht arbeiten konnten sind Opportunitätskosten. Cost of Delay, die Kosten, dafür, dass sie im Stau feststeckten.

Warum erzähle ich das? Ich rede doch sonst über Entwicklung.

Haben Sie diesen Kollegen, durch den alles durch muss? Der Spezialist, der gerne konsultiert wird, der Supermann, der der einzige ist, der eine Aufgabe machen kann? Hat jeder. Wenn ihnen keiner einfällt, gehen Sie doch mal suchen, Sie werden einen finden. Ihr Team kennt ihn sicher.

Wandeln wir das Bild etwas um. Dieser Experte ist viel gefragt. Schau doch mal auf die Auswertung, was denkst Du zu den Messwerten, konntest Du schon meinen Bericht anschauen. Immer warten wir auf diese eine Person.

Und ich verstehe das, manche Personen sind echt teuer. Richtige Spezialisten gibt es nicht wie Sand am Meer. Da kann man froh sein, wenn man einen hat. Mehr können wir uns nicht leisten, mehr können wir auch gar nicht auslasten. Schreck, die Kosten wenn der Spezialist nicht die ganze Zeit arbeitet.

Und in der Zeit warten Arbeitspakete auf den Mitarbeiter. Und bleiben liegen. Sie stehen sozusagen im Stau. Und verzögern sich. Sie haben einen Delay. Und letzte Woche sprachen wir von Cost of Delay und wie man den misst. Und wir haben herausgefunden, dass ein Projekt teilweise erhebliche COD haben kann, dass das aber Opportunitätskosten sind, Kosten, die wir nicht sehen, nur entgangener Gewinn, noch nicht mal für dieses Geschäftsjahr. Nur in ein zwei Jahren fehlt dann halt der Gewinn.

 

Aber warum erzähle ich das?

Verzögerung kostet, sogar erschreckend viel. Und Wartezeiten, Warteschlangen, verzögern Arbeitspakete und Projekte und kosten daher auch.

Jede Warteschlange erzeugt Opportunitätskosten. Wir könnten schneller fertig werden und die Vorteile haben. Machen wir nicht, also entgeht uns der Nutzen, der Gewinn, also haben wir Opportunitätskosten.

Jetzt haben wir ein Arbeitspaket in einem Projekt, dass sich verzögert. Der unersetzliche Schlüsselmitarbeiter kommt nicht dazu, weil er erst noch zu einem Kunden fahren muss, einen Vortrag halten soll und danach noch drei weitere Dinge zu erledigen hat. Also bleibt das Arbeitspaket liegen. Es ist auf dem kritischen Pfad. Verzögerungen wirken sich also eins zu eins auf das Projekt aus.

Nehmen wir die Zahlen aus dem Beispiel der letzten Woche. Also einen Cost of Delay von EUR 100 000 pro Woche. Das Arbeitspaket bleibt drei Tage liegen. Also EUR 60 000.

Dumm nur, dass das gleiche auch mit zwei anderen Projekten passiert. Nehmen wir der Einfachheit halber die gleichen Zahlen. Also kostet uns das ganze Spiel jetzt schon EUR 180 000. Wieviel verdient dieser Mitarbeiter und könnte man davon nicht noch einen finden, oder kann man seine Aufgaben auf mehr Schultern verteilen?

Zu weit hergeholt? Glaube ich nicht, aber nehmen wir ein anderes Beispiel:

Alle Entwicklungsprojekte müssen durch die Konstruktionsabteilung. Wir haben hier 7 Projekte. Cost of Delay wie oben. Jedes Projekt könnte in 2 Monaten durch die Konstruktionsabteilung geschleust werden, wenn wir sie brav der Reihe nach abwickeln würden.

Warum nacheinander? Es gab da mal eine Folge zu. Sequentiell statt Parallel. Da habe ich das erklärt.

7 mal zwei Monate: Also brauchen wir die Konstruktionsabteilung dieses Jahr 14 Monate. Sie ist etwas überbelegt, aber nur ein bisschen.

Wir haben ja gute Projektmanager, die daran gemessen werden, dass ihr Projekt vorankommt. Jeder kümmert sich um sein Projekt. Mehr kann man ja nicht machen.

Erkennen Sie ihre Firma wieder? So weit so typisch.

Jetzt haben sie richtig gute Projektmanager, sie haben ja gute Leute. Sie wissen auch das Projektmanagement wichtig ist und haben hier nicht gespart. Kurz, Sie sind der Meute einen Schritt vorraus. Andere Firmen setzen Führungsanfänger im Projektmanagement ein, Führung light sozusagen, aber doch nicht Sie. So weit so untypisch.

Also diese guten Projektleiter wissen, dass die Konstruktion ein Problem wird. Also kämpfen sie von Anfang an, direkt im Januar darum, dass Ihr Projekt in der Konstruktion bearbeitet wird. Jeder Konstrukteur, den Sie abgeben müssen tut ihnen weh, aber so ganz egoistisch wollen die Projektleiter ja auch nicht dastehen, also gestehen sie den anderen Projekten zu, dass an ihnen gearbeitet wird, solange nur auch am eigenen gearbeitet wird.

Also machen wir alles parallel. Wenn überall dran gearbeitet wird, machen wir doch überall Fortschritt und alles ist gut.

Jetzt verteilt sich die Arbeit gleichmäßig auf die Projekte und an allen wird gearbeitet. Nach 14 Monaten ist die Arbeit an allen Projekten fertig. Aber eben auch nicht früher, weil immer wenn ein Projekt sich einen Vorsprung erarbeitet hatte, haben die anderen Projektleiter das gleich als Argumentation genutzt Ressourcen auf ihr eigenes Projekt, das ja stärker notleidend ist umzuleiten.

Jetzt würde ich gerne wissen, wie sehr sich dadurch die einzelnen Projekte verzögert haben. Wir brauchen also einen Referenz. Die schnellste Art, Projekte fertig zu machen, ist, an einem zu arbeiten bis es fertig ist und dann zum nächsten überzugehen.

Das erste Projekt wäre nach 2 Monaten fertig, das zweite nach 4, das dritte nach 6 und das siebte nach 14.

Das siebte Projekt wird also nicht später fertig. Kein Verzug, keine Verzugskosten.

Das sechste Projekt wird zwei Monate später fertig. Also zwei Monate Verzug, 8 Wochen. Umgerechnet sind das EUR 800 000.

Das fünfte Projekt wird vier Monate später fertig. Also vier Monate Verzug, 16 Wochen. EUR 1,6 Mio.

Das vierte Projekt wird sechs Monate später fertig gestellt. Sechs Monate Verzug, 24 Wochen, EUR 2,4 Mio.

In Summe haben wir schon Verzugskosten von 4,8 Mio EUR.

Das Dritte Projekt wird acht Monate später fertig. Acht Monate Verzug, 32 Wochen. 3,2 Mio EUR.

Die Zwischensumme liegt jetzt bei 8 Mio EUR. Wohlgemerkt, Opportunitätskosten. Nicht realisierter Gewinn. Niemand wird diese Zahl irgendwo in der Buchführung sehen. Zumindest nicht als Mehrkosten Konstruktion. Aber es fließt in die Zahlen ein. Ein Entwicklungsprojekt, das nicht fertig ist, hat noch kein verkaufsfähiges Produkt abgeliefert. Keine Verkaufsbemühungen, kein AE, Der Umsatz fehlt, die Fixkosten sind da, der komplette Deckungsbeitrag fehlt in der Gewinnsumme. Opportunitätskosten sind keine Kosten, die in der Buchführung irgendwo unter Kosten stehen, das heißt aber nicht, dass sie nicht in der GuV auftauchen und ziemlich viel schlechte Laune machen können.

Wenn sie jetzt die Episode pausieren möchten, weil Sie zwei dringende Fragen beantwortet haben wollen: Was sind unsere Cost of Delay und wie werden die Projekte priorisiert? Dann kann ich das verstehen. Sie können ja gleich zurück kommen.

Das zweite Projekt hat jetzt 40 Wochen Verzug und Verzugskosten von 4 Mio.

Das erste Projekt ist ein volles Jahr später fertig. Bei glatten vier Wochen pro Monat 48 Wochen. Also 4,8 Mio.

Die Gesamtsumme beläuft sich auf 16,4 Mio.

Eine Firma in der diese 7 Projekte parallel laufen mit den Zahlen aus dem Beispiel hätte einen Umsatz von 700 Mio, wenn sie jedes Produkt nach vier Jahren erneuert. Also vier mal sieben mal 25 Mio Umsatz pro Produkt.

16,8 Mio sind 2,4% vom Umsatz. Also ein erheblicher Anteil vom Gewinn.

Was ist hier eigentlich schief gelaufen? Welche Optionen haben Sie, solches zu verhindern?

 

Nun das erste, was sie machen dürfen ist das gleiche, was wir getan haben, um unseren Referenzfall zu bauen: Die Projekte weitestgehend nacheinander abarbeiten, damit sie schnell die ersten fertig stellen und diese nicht ein Jahr in die Länge ziehen.

Dazu dürfen Sie Priorisieren. Aber auch hier sei weider mein Kommentar erlaubt: Priorisieren Sie ordinal, als sagen sie: Das ist das erste Projekt, das ist das zweite Projekt. Priorisieren nach Klassen führt nur wieder dazu, dass Projekte gleichzeitig ausgeführt werden.

Zu einem Projekt im Maschinenbau gehört viel mehr als ein paar Konstruktionen. Ich plädiere nicht dafür, dass Sie ein Produkt komplett einführen und dann erst das nächste angehen, das wäre Quatsch. Aber sie dürfen die Projekte staffeln, so dass eins gerade aufgeplant wird, eins in der Konzeptphase steckt, eins konstruiert wird, eins gebaut wird und eins getestet wird, während eins gerade in den Markt eingeführt wird. Die Konzentration auf das aktive Projekt gilt innerhalb eines Teams, einer Funktion.

Und ja, nicht immer wird ein Projekt schneller, wenn man noch mehr Mitarbeiter bereitstellt, der Kommunikationsoverhead steigt und manchmal macht es kein Sinn mehr Mitarbeiter in einem Projekt zu beschäftigen. Richtig. Aber das Projekt, das Priorität hat, sollte alle Ressourcen bekommen, die es sinnvoll verdauen kann und erst wenn dann noch Kapa übrig ist, kommen die nachrangigen Projekte zum Zug.

Unser Fall ist vereinfachend um ein Problem in Reinform aufzuzeigen das Muster findet aber abertausendmal im deutschen Mittelstand und allen Großkonzernen statt.

 

Wie befreien Sie sich aus der Falle? Nun es ist schon angesprochen worden, aber hier ist die Liste nochmal:

Fragen Sie nach den Cost of Delay für Ihre Projekte. Seien Sie sich über den echten Wert der Zeit in ihrem Fall für jedes Projekt bewusst.

Priorisieren Sie die Projekte. Bearbeiten sie sie bewusst nacheinander in einer Reihenfolge, die bewusst entschieden worden ist und von der Firma getragen wird. Lassen Sie nicht die Projektleiter das untereinander ausfechten. Da gewinnt der Lautere, aber nicht die Firma.

Seien Sie sich auch über Ihre Kapazitätsgrenzen im Klaren. Verplanen Sie nicht mehr Ressourcen, als Sie haben oder bereit sind zur Verfügung zu stellen.

Seien Sie sich darüber im Klaren, dass mehr Kapazität am Flaschenhals fast immer billiger ist, als alle Projekte zu verzögern. Rechnen Sie hier mit dem spitzen Bleistift. Es muss ja nicht immer eigene Mannschaft sein.

Schauen Sie sich auch die Zuschnitte Ihrer Projekte an. Wenn nur die Hälfte der Projekte Konstruktions-lastig wäre und die andere Hälfte Versuchs-lastig, dann kann sich die Situation entspannen, dazu aber nächste Folge.

Ein Kommentar noch: Kein bienenfleißiger Konstrukteur, kein durchsetzungsstarker Projektleiter kann dieses Problem verhindern, wenn die Führungsmannschaft die Führung verweigert und nicht priorisiert hat. Es geht hier nicht um mehr Druck oder mehr Schweiß, es geht darum die Prozesse und Systeme so zu gestalten, dass die Mitarbeiter optimal zum Unternehmenswohl beitragen können. Das ist die Verantwortung der Führung und das ist aber auch ihre große Chance einen echt wertschöpfenden Beitrag zu leisten.

Und zuletzt: Sie dürfen Oma ignorieren und den Hunderteuroschein selber in Augenschein nehmen. Rechnen sie einfach nach, was die verschiedenen Szenarien für Ihre eigene Situation bedeuten. Ihre Zahlen werden sich von dem Beispiel unterscheiden, aber sie könnten sich durchaus erschrecken.

Diese Woche lasse ich Sie noch an der Klippe hängen und sage nur sie müssen priorisieren und in der Tat, jede Prio ist besser als keine. Nächste Woche zeige ich ihnen wie sie priorisieren und was die Effekte sind. Bis dahin wünsche ich Ihnen viel Erfolg bei der Arbeit.

Gant Chart

Projektmanager 2030

Das Projektmagazin hat zur Blogparade gerufen über den Projektmanager 2030.

https://www.projektmagazin.de/blogparade_2017

Die Agilen Prozesse unterstützen den Projektleiter bei seinen Aufgaben. Die Aufgaben, die er hier aufgibt werden kompensiert durch die gestiegene Verantwortung in einer VUCA-Welt sicherzustellen, dass der Projektauftrag dem Sinn und nicht nur dem Worte nach erfüllt wird.
Das verändert auch die Ausbildung zum Projektleiter und Projektleitung wird sich weiter entwickeln vom Einstieg in die Führung vor eigener Personalführung zu einer Rolle für erfahrene Führungskräfte, die schon Teams und Gruppen geführt und Prozesse verantwortet haben.

Kalender mit radiertem Datum

Zeit ist Geld, aber was ist der Wechselkurs

016 – Zeit ist Geld. Der Termin für die Projektfertigstellung ist nicht willkürlich gewählt. Ihm unterliegt ein wirtschaftlicher Nutzen. Wer diesen Termin verstreichen lässt richtet einen Schaden an. Wir klären wieviel.

Bei der Berechnung des Cost of Delay ist es wichtig zu verstehen, dass vor allem die Opportunitätskosten wichtig sind. Die neuen Produkte, die man hätte verkaufen können, wenn das Entwicklungsprojekt fertig geworden wäre.

Ein einfaches Rechenbeispiel zeigt wie groß dieser Schaden sein kann.

Wer diesen Schaden verhindern möchte, sollte darauf achten, den Cost of Delay allen Projektbeteiligten bekannt zu machen und dafür zu sorgen, dass er für Entscheidungen auch herangezogen wird.

Flaschenhals

Das Ziel, ein Roman über Prozesse und die Engpasstheorie.

Buchvorstellung The Goal / Das Ziel von Elijahu Goldratt und Transfer der Theory of Constraints / Engpasstheorie auf die Produktentwicklung.

Elijahu Goldratt schrieb The Goal (Das Ziel) und stellt darin seine Theory of Constraints, die Engpasstheorie, vor.

Jeder Prozess ist im Durchsatz durch seinen Engpass begrenzt und durch richtiges Management dieses Engpasses, können Sie eine gute Planungsqualität und beschleunigten Durchsatz erreichen.

The Goal ist das in dieser Folge beschriebene Buch. Es stellt die Engpasstheorie als Businessroman vor. Gut verdaulicher Text, und sehr spannende Betrachtungsweise eines Prozesses. Gerade die Betrachtung des Engpasses und die Nutzung des Engpasses zur Planung und Steuerung sind phantastisch. Auch als Audiobuch verfügbar.

Die deutsche Version des Buches.

Factory Physics wird in der Folge erwähnt und enthält das CONWIP-Konzept, dass in dieser Folge die TOC erweitert und TOC mit Kanban-Boards und Cumulative Flow Diagrams (CFD) paart. Das Buch selber ist eine Schatzkiste aber sehr numeriklastig. Im Gegensatz zu Das Ziel sicher keine einfache Bettlektüre.

Eine Zusammenfassung von Factory Physics mit den wichtigsten Erkenntnissen, die ein Manager nach Meinung der Autoren mitgenommen haben sollte. Sehr reichhaltig, aber viel besser verdaulich als Factory Physics selber, dass ein sehr numeriklastiges Lehrbuch ist.