projektManagementaktuell | AUSGABE 2.2016 14 WISSEN In der Entwicklung mechatronischer Produkte geht es darum, Denk- und Vorgehensweisen der drei Disziplinen Mechanik, Elektronik und Informationstechnik zusammenzubringen. Mit steigendem Anteil der Informationstechnik und steigender Dynamik auf den Märkten müssen Parallelität und effektive Integration der drei Teilbereiche verstärkt werden. In der Informationstechnik haben agile Methoden in vielen Organisationen Einzug gehalten. Unternehmen, die mechatronische Produkte entwickeln, stellen sich die Frage, ob und wie sie agile Methoden nutzen können. Im Folgenden zeigen wir auf, welche Lösungsansätze diese für die Herausforderungen der mechatronischen Produktentwicklung bieten können. Einige Beispiele des Einsatzes agiler Methoden werden vorgestellt. Diese Überlegungen werden am aktuellen Stand der Produktentwicklung in einem Unternehmen der Automobilzulieferindustrie untersucht und reflektiert. Mechatronik als interdisziplinäres Fach Der Begriff „Mechatronik“ ist ein Kunstwort, das ursprünglich 1969 für die elektronische Funktionserweiterung mechanischer Komponenten stand bzw. für die Verbindung von Mechanik oder allgemeinem Maschinenbau mit Elektronik [10, S. 9]. Danach kam mit der Mikroelektronik die Informationstechnik als weiterer Bestandteil hinzu, sodass heute mechatronische Produkte als Produkte verstanden werden, in denen die Teilbereiche Mechanik, Elektronik und Informationstechnik zusammenwirken [10, S. 10]. Unser Alltag ist von Innovationen durch mechatronische Produkte wie z. B. Digitalkameras oder Smartphones geprägt, viele Teile eines Automobils - etwa die Schließsysteme - haben sich von rein mechanischen zu mechatronischen Produkten entwickelt. Industrieroboter sind Beispiele für mechatronische Produktionsanlagen. Im Rahmen der Digitalisierung ist der Anteil der Informationstechnik immer weiter gestiegen und wird aller Voraussicht nach weiter steigen [6, S. 225]. Gleichzeitig verkürzen sich die Entwicklungs- und Produktlebenszyklen. Damit steht die Entwicklung mechatronischer Produkte vor folgenden Herausforderungen: • Steigende Komplexität durch höhere Anzahl von miteinander in Wechselwirkung stehenden Komponenten • Verteilung des Wissens auf verschiedene Disziplinen mit unterschiedlichen Entwicklungsmethoden • Bedarf an verteilter Entwicklung und der disziplinübergreifenden Zusammenarbeit • Bildung gesamtoptimaler Schnittstellen zwischen den Teilsystemen und deren Integration in einem mechatronischen System • Wachsender Anteil der „nicht greifbaren“ Informationstechnik • Steigender Bedarf an Parallelisierung und Synchronisierung der Teilsysteme in der verteilten Entwicklung Vorgehen in der Entwicklung mechatronischer Systeme Der Verein Deutscher Ingenieure e. V. (VDI) gab 2004 eine Richtlinie für die Entwicklung mechatronischer Systeme heraus, die ein V-Modell als Erfolg versprechendes Vorgehen für die Entwicklung von den Anforderungen hin bis zum fertigen Produkt vorstellt (vgl. [10]). Das Besondere an dem V-Modell dieser Richtlinie VDI 2206 ist, dass beim Systementwurf eine Aufteilung in die beteiligten Disziplinen erfolgt, sodass dann parallel und je Disziplin ein Entwurf erfolgen kann, der anschließend als System integriert Herausforderungen der Entwicklung und praktische Lösungsansätze agiler Methoden Agile Methoden in der entwicklung mechatronischer Produkte Autoren: Dorothee Feldmüller, Nadine Sticherling >> Für eilige Leser Mechatronische Produktentwicklung ist geprägt vom Vorgehen nach dem V-Modell der VDI-Richtlinie 2206. Aufgrund des wachsenden Anteils von Informationstechnik in der Mechatronik wie auch der erfolgreichen Verbreitung agiler Methoden stellt sich die Frage, wie hier Agilität eingebracht werden kann. Nach Literaturstudium wird ein konkretes Unternehmensbeispiel untersucht. Agile Ergänzungen am Prozessmodell sind besonders zielführend, wenn sie frühzeitige Synchronisation zwischen den Teilbereichen beinhalten. Solche Änderungen sind zum Teil mit kleinen Anpassungen machbar. Andere Änderungsvorschläge erfordern kulturelle Veränderungen, die gut vorbereitet werden müssen und nicht in allen Fällen passen. Insgesamt ist ein hybrides Vorgehen für die mechatronische Produktentwicklung ein guter Weg. PM-aktuell_2-2016_Inhalt_01-72.indd 14 04.04.2016 5: 17: 00 Uhr WISSEN 15 projektManagementaktuell | AUSGABE 2.2016 erfolgt nur bei circa einem Fünftel der befragten Anwender durchgängig, die Mehrheit nutzt sie in hybrider Form oder selektiv [7, S. 10]. Bemerkenswert ist, dass agile Methoden auch außerhalb der IT eingesetzt werden [7, S. 11]. Die Verbindung von der Produktentwicklung zur Sportart Rugby, zum Bild des gemeinsamen Vorwärtsdrängens eines Teams mit schnellen Ballwechseln - wie sie die agile Methode Scrum auch aufgreift - wurde ursprünglich von Takeuchi und Nonaka gezogen (vgl. [9]). Sie benennen den Bedarf für Schnelligkeit und Flexibilität in der Produktentwicklung, für Selbstorganisation und überlappende Phasen mit schnellen Rückmeldungen und Lernzyklen, aber auch deren Risiken und Begrenzungen im Einsatz. Aufgrund der berichteten Erfolge und des ohnehin hohen IT-Anteils in der Entwicklung mechatronischer Produkte stellt sich die Frage, inwiefern der Einsatz agiler Methoden in diesem Bereich bessere Antworten auf die oben genannten Herausforderungen bieten kann. Gerade das späte Zusammenführen der drei Teilbereiche - wie es das Arbeiten nach dem V-Modell nahelegt - zieht häufig die Notwendigkeit von späten Fehlerkorrekturen nach sich. Hier ist ein klares Potenzial für agiles Vorgehen im Sinne von frühen, kleinen Iterationen und darauf aufbauenden Anpassungen gegeben. Agiles Vorgehen Seit der Veröffentlichung des Agilen Manifests 2001 [1] finden agile Methoden der Softwareentwicklung in der Informationstechnik wachsende Beachtung und Zuspruch. Damit sind Methoden gemeint, die Bezug nehmen auf die Werte und Prinzipien des Manifests. Typisch für agiles Vorgehen ist das frühe Erstellen von Produkten oder Produktteilen - Inkrementen - und das Einholen von Rückmeldungen von Kunden, um aus früh gemachten Fehlern schneller und effizienter zu einem fehlerfreien und angemessenen Produkt zu kommen. Ebenso wird Wert auf Selbstorganisation des Entwicklungsteams gelegt und Angemessenheit und Schlankheit in den Prozessen - ähnlich den mit dem Präfix „Lean“ versehenen Methoden aus der Betriebsorganisation. In der aktuellen Untersuchung „Status Quo Agile“ [7] werden agile Methoden bezüglich Erfolgskriterien wie unter anderem Budgeteinhaltung, Transparenz, Kundenorientierung, Termintreue, Ergebnisqualität nahezu durchgehend besser bewertet als klassisches Projektmanagement [7, S. 13 ff.]. Dabei hat die Nutzung agiler Methoden in den Unternehmen erst in den letzten Jahren begonnen [7, S. 12]. Der Einsatz agiler Methoden wird. Eine Darstellung dazu findet sich in Abbildung 1. Damit greift die Richtlinie die verteilte Entwicklung und übergreifende Zusammenarbeit auf und bildet hierfür einen zusammenführenden Rahmen ab. Die Einführung und organisationsspezifische Anpassung dieser Richtlinie ist in den vergangenen Jahren in vielen Unternehmen erfolgt. Zugrunde liegt der VDI-Richtlinie 2206 ein klassisches Vorgehen in Phasen und ein klassisches Denken in Zerlegung eines Systems in Entwurf und (spätere) Synthese. Die Tatsache, dass sich hier eher klassische Vorgehensweisen etabliert haben, ist auch dadurch bedingt, dass viele Produkte sich historisch aus mechanischen Produkten entwickelt haben, bei deren Entwicklung eine iterative Vorgehensweise nur begrenzt machbar ist. Ein physisch erstelltes Produkt lässt sich im nächsten Zyklus nur bedingt an die in dem vorhergegangenen Entwicklungszyklus gewonnenen Erkenntnisse anpassen. Allerdings kennt und benennt die Richtlinie auch das Prinzip der Iteration. Für die Entwicklung eines mechatronischen Produktes muss das V-Modell ggf. mehrmals durchlaufen werden, wie in Abbildung 2 dargestellt: Labormuster, Funktionsmuster, Vorserienprodukt usw. sind auch in der mechanischen Produktentwicklung seit Langem bekannte Iterationen. Abb. 1: V-Modell der VDI 2206; nach [10, S. 29] PM-aktuell_2-2016_Inhalt_01-72.indd 15 04.04.2016 5: 17: 03 Uhr projektManagementaktuell | AUSGABE 2.2016 16 WISSEN Kulturveränderungen und damit verbundenen Risiken kleiner zu halten. Klein und Reinhard entwickeln Kriterien, die bei der Anwendung agiler Methoden in der mechatronischen Entwicklung beachtet werden müssen [6, S. 228]. Sie empfehlen unter anderem umso mehr Agilität, je kürzer der Produktlebenszyklus ist. In der Automobilindustrie mit Produktzyklen von vier bis sechs Jahren erscheint eine geeignete Mischung - ein hybrides Vorgehen - angemessen, bei der Luft- und Raumfahrt mit Produktzyklen von zehn bis zwanzig Jahren ist Agilität nach ihrer Einschätzung nicht hilfreich. Hilfreich ist sie auch umso mehr, wo es nicht um komplett innovative Entwicklungen geht, sondern um Weiterentwicklungen bereits bestehender Produkte. Feste Entwicklungszyklen, wie sie von Scrum bekannt sind, würden es ermöglichen, Fehlerarbeit abbilden und deren Einführung mit hohem Aufwand verbunden gewesen ist. In diesen Unternehmen ist Agilität - hier mag auch ein Informationsproblem eine Rolle spielen - schon einmal mit dem Gedanken an Disziplinlosigkeit verbunden. Der Satz „Wir schätzen ... Individuen und Interaktionen mehr als Prozesse und Werkzeuge“ entstammt dem Agilen Manifest, entspricht eher nicht der bislang gelebten Unternehmenskultur. Eine Umstellung auf agile Vorgehensweisen erfordert Anpassungen der Unternehmenskultur sowie Schulung und Begleitung der beteiligten Personen und ist nicht in kurzer Zeit machbar (vgl. [5, S. 99 ff.). Ebenso wie in der Softwareentwicklung, wird auch für die Produktentwicklung in der Mechatronik vorgeschlagen, das Beste aus beiden Welten - klassischer und agiler Welt - miteinander zu kombinieren und damit auch die notwendigen Agilität und Mechatronik - Ausgangslage und grundsätzliche Überlegungen Grundsätzlich bietet die Entwicklung komplexer mechatronischer Produkte mit Unsicherheit über die Anforderungen und deren Verteilung auf die beteiligten Disziplinen auch ein gutes Betätigungsfeld für agile Werte wie Offenheit für Änderungen, Ergebnisorientierung, Angemessenheit, Selbstorganisation. Wie wir bereits erwähnt haben, sieht die VDI 2206 die Iteration vom Labormuster bis zum gebrauchsfertigen Produkt bereits vor, wenn sie auch sonst im klassischen Rahmen bleibt. Unternehmen, die mechatronische Produkte entwickeln, besonders in der Automobilindustrie, arbeiten häufig mit ausgefeilten Prozessmodellen, die organisationsübergreifende Zusammen- Abb. 2: V-Modell der VDI 2206 mit Iterationen; nach [10, S. 31] Anzeige PM-aktuell_2-2016_Inhalt_01-72.indd 16 04.04.2016 5: 17: 09 Uhr WISSEN 17 projektManagementaktuell | AUSGABE 2.2016 Bei größeren Entwicklungsvorhaben besteht ggf. die Chance, Teilaufgaben für ein agiles Vorgehen auszuwählen. Dies entspricht dann der schon genannten hybriden Vorgehensweise. Für Anfänger in agilen Methoden und Organisationen mit geringer Reife in Bezug auf Agilität empfiehlt es sich, mit einzelnen Techniken zu beginnen, die keinen großen Bruch zum bisherigen Vorgehen bedeuten. Dazu würde ein Daily Scrum zählen oder der Einsatz von Reviews. Die Einführung der Selbstorganisation, die intensiv vorzubereiten und zu begleiten ist, wäre hingegen schon ein größerer Bruch. Einige Beispiele und Erfahrungen Im Folgenden nennen wir einige Beispiele für den Einsatz agiler Methoden in der Entwicklung mechatronischer Produkte, die uns bekannt geworden sind. Anfragen nach Überlegungen und Erfahrungen zu deren Einsatz auch über den Softwarebereich hinaus liegen aus mehreren Abbildung 3 dargestellt. Nach unserer Einschätzung ist hier das wahre Können der Mechatronik gefragt, die passenden Synchronisationspunkte zu definieren. Wie bereits gesagt, ein entsprechender Reifegrad der Organisation wird für unumgänglich für die Einführung von Agilität gehalten und auch eine professionelle Begleitung beim Einführungsprozess. Auch bei bereits geübten Personen stößt die Selbstorganisation bei größeren und verteilten Teams allerdings an ihre Grenzen, wie schon Takeuchi und Nonaka formulierten. Komus formuliert aufgrund seiner Studie folgende Bedingungen als besonders vorteilhaft für den Einsatz agiler Methoden (vgl. [7, S. 20]): • Vornehmlich interne Ausrichtung • Budget kleiner 1 Mio. EUR • Projektteam von 5 bis 9 Personen • Häufig wiederkehrende Aktivitäten • Budgetvorgaben und Ergebnisvorgaben nur unscharf • Dauer von 3 bis 9 Monaten korrekturen für einen der nächsten Zyklen einzuplanen und weniger Wartezeiten sowie mehr Planbarkeit und Berechenbarkeit im Entwicklungsprozess zu erhalten - im Gegensatz zum klassischen Prozess, in dem im Extremfall alle Beteiligten auf eine Fehlerkorrektur warten müssen, bevor das gemeinsame Gate im Entwicklungsprozess durchlaufen ist. Die Einführung von festen kurzen Entwicklungszyklen für Iterationen wird mit horizontaler Agilität überschrieben [6, S. 228 f.]. Unter vertikaler Agilität verstehen die Autoren im Kontext der mechatronischen Entwicklung die Synchronisation der drei beteiligten Disziplinen Mechanik, Elektronik und Informationstechnik [6, S. 229] - die eigentliche Herausforderung dieses gemischten Faches. Ein Vorschlag ist, den IT-Anteil in kürzeren Zyklen zu entwickeln und zum Abschluss eines jeden Zyklus eine wenigstens informatorische Abstimmung mit dem in längeren Zyklen arbeitenden mechanischen bzw. elektronischen Anteil vorzunehmen, wie z. B. in Anzeige PM-aktuell_2-2016_Inhalt_01-72.indd 17 04.04.2016 5: 17: 09 Uhr projektManagementaktuell | AUSGABE 2.2016 18 WISSEN Es gibt auch positive Erfahrungen aus der Industriepraxis, über die berichtet wird: eine Kombination von horizontaler und vertikaler Agilität in der Entwicklung von Fahrzeugkomponenten [2, S. 162 ff.]. In dem genannten Beispiel arbeitet die IT in Takten von zwei Wochen, Mechanik und Elektronik sowie ein Lieferant arbeiten in größeren Etappen, synchronisieren sich aber spätestens nach zehn Wochen, um nach zwölf Wochen ein gemeinsames Inkrement erarbeitet zu haben. Mehrere solche Iterationen von zwölf Wochen führen zu einem Endprodukt. Vor allem die Visualisierung und die Disziplin in den vereinbarten Regeln wurden hierbei als sehr hilfreich empfunden. Gestartet wurde die Vorgehensweise bei Krisenfällen - zunächst also in einem be- „harten Weg“ - die Einbindung aller drei Teilbereiche der Mechatronik in agile Methoden - in der Praxis bestellt? Grimheden berichtet von einer Fallstudie im Mechatronikkurs an der Hochschule, bei der er statt einer Abschlusspräsentation des entwickelten Produktes die Studierenden drei Sprints einlegen lässt (vgl. [4]). Hier wird horizontale und vertikale Agilität miteinander kombiniert. Der Kurs wird von den Studierenden als sehr wertvoll für ihre weitere Entwicklung evaluiert. Die Vorteile der kurzen Lernzyklen und frühen Erkenntnisse haben sich positiv auf die Ergebnisse ausgewirkt, sodass zum Beispiel notwendige Korrekturen an den Zielsetzungen vorgenommen werden konnten. Unternehmen, die bislang klassisch gearbeitet haben, vor. Für den Teilbereich der Softwareentwicklung innerhalb eines mechatronischen Systems liegen die Vorteile agiler Vorgehensweisen auf der Hand und überraschen nicht. In einer Fallstudie von Volvo wird berichtet, wie dadurch falsche Annahmen früh aufgedeckt und eliminiert werden können [3]. Automobilzulieferer aus dem Bereich Infotainment nutzen seit 2011 agile Methoden im Entwicklungsprozess, der sehr softwarelastig ist (vgl. [11, S. 38]). Beide sind Beispiele für das, was Grimheden den „leichten Weg“ nennt, um agiles Vorgehen in die Entwicklung mechatronischer Systeme zu integrieren (vgl. [4, S. 970]). Wie aber ist es um den Abb. 3: Vertikale (interdisziplinäre) Agilität in der mechatronischen Entwicklung; nach [6, S. 229] PM-aktuell_2-2016_Inhalt_01-72.indd 18 04.04.2016 5: 17: 14 Uhr WISSEN 19 projektManagementaktuell | AUSGABE 2.2016 Als Ergebnis der Befragung konnten fünf Lösungsmöglichkeiten für die Praxis gefunden werden: • V-Modell als mehrmaliger Durchlauf • (Echt-)paralleler Durchlauf der einzelnen Vorgehensweisen in Mechanik-, Elektronik- und Softwareentwicklung • Räumliche Nähe bei der Zusammenarbeit • Organisierter Wissenstransfer • Neue Rollendefinition im Entwicklungsteam Den unterschiedlichen, vom Kunden geforderten Musterständen, vom ersten Labormuster über Funktionsmuster hin zum Serienprodukt, geschuldet sollte der Produktentwicklungsprozess diese Musterstände auch abbilden. Diese Möglichkeit bietet der mehrmalige Durchlauf des V-Modells. Besonders bei innovativen Produkten hat dieser iterative Ansatz den Vorteil, dass die Kundenanforderungen zu Beginn eines Projekts nicht in völliger Detailtiefe vorliegen müssen. Durch erste Tests mit den vorhandenen einmalig durchlaufen wird. Durch Umfragen in den einzelnen Entwicklungsabteilungen konnte der Ist-Stand zur mechatronischen Produktentwicklung eingeholt und herausgefunden werden, ob durch den Einsatz agiler Methoden der Entwicklungsprozess verbessert werden kann. Entwicklungsprojekte im Automobilbereich haben meist eine Laufzeit von vier Jahren mit einem Budget von ca. 4 Mio. Euro. Die Randbedingungen für eine agile Produktentwicklung nach Komus werden daher nicht ganz erfüllt. Aber mechatronische Produkte sind zu komplex, erfordern Parallelität in der Entwicklungsarbeit sowie hohe Abstimmungen mit dem Kunden, gerade bei innovativen Produkten, um sie rein nach klassischem Vorgehen effektiv entwickeln zu können. Somit stellt sich die Frage: Wie können agile Methoden das klassische V-Modell unterstützen? grenzten Umfeld und unter durchaus skeptischer Begleitung -, bis der Erfolg dem Vorgehen recht gab. Wie und bei welcher Art von Inkrementen die gemeinsame Taktzeit bei den mechanischen und elektronischen Anteilen eingeführt wurde, dazu wird in diesem Bericht leider keine konkrete Aussage getroffen. Allen Beispielen gemeinsam ist, dass sie nicht durchgängig auf Agilität setzen, sondern ein hybrides Vorgehen wählen. Die hohe Kunst der vertikalen Agilität in der Mechatronik scheint in einzelnen Fällen zu gelingen und auch als erfolgreich wahrgenommen zu werden. Mechatronische Entwicklung - Konkretes Unternehmensbeispiel In der betrachteten Prozessstruktur eines Automobilzulieferers werden derzeit mechatronische Produkte nach dem V-Modell entwickelt, welches Abb. 4: Mehrmaliger Durchlauf des V-Modells angepasst an die mechatronische Produktentwicklung eines Automobilzulieferers PM-aktuell_2-2016_Inhalt_01-72.indd 19 04.04.2016 5: 17: 19 Uhr projektManagementaktuell | AUSGABE 2.2016 20 WISSEN nik und Software zusammen, um das Produkt in Gänze und die jeweiligen Umsetzungskonzepte zu besprechen. Hier gibt es eine letzte Möglichkeit, das Produktkonzept besprechen zu lassen, bevor dieses aufgebaut wird. Die Synchronisationspunkte sollen hier sicherstellen, dass man sich auf Absprachen verlassen kann und somit jede Disziplin zwischen den Synchronisationspunkten auch wirklich parallel zu den anderen arbeiten kann. Trotz der aufgezeigten Parallelität während des Entwicklungsprozesses ist die räumliche Nähe bei der Zusammenarbeit sehr wichtig. Mit fortschreitendem Projektverlauf erhöht sich der Bedarf an nötigen sog. kleinen Absprachen zwischendurch. Hier sollten Rücksprachen nicht auf die wöchentlichen Meetings verlegt werden. Zwar helfen Online-Meetings bei den Problemerste Synchronisationspunkt erfolgt nach der Aufgabenanalyse, der Strukturierung und der Schnittstellendefinition. Der zweite Synchronisationspunkt muss nicht mehr über alle drei Disziplinen hinweg erfolgen. So wird dem zeitlich unterschiedlichen Vorhandensein der jeweiligen Design-Entwürfe Rechnung getragen. Zudem kann es sein, dass dieser Synchronisationspunkt von zwei Disziplinen mehrmals bis zur endgültigen Absprache durchlaufen werden muss. Hier kann die dritte Disziplin von diesen Schleifen ungestört weiterarbeiten oder wird erst nach einem weiteren Durchlauf hinzugezogen. Nach dem zweiten Synchronisationspunkt werden die Entwürfe der einzelnen Disziplinen weiter verfeinert. Bevor es in die konkrete Umsetzung geht, erfolgt der dritte Synchronisationspunkt. Hier kommen die drei Disziplinen Mechanik, Elektro- Musterständen können diese Anforderungen nach einem Review stets erweitert werden und bieten zudem die Möglichkeit der Überarbeitung, falls von falschen Voraussetzungen ausgegangen wurde. Für die zweite Lösungsmöglichkeit, den parallelen Durchlauf der einzelnen Disziplinen Mechanik, Elektronik und Software, wurden deren Vorgehensweisen in der Entwicklung betrachtet. Hier konnte zunächst positiv festgestellt werden, dass das Verständnis der Vorgehensweisen aus der Praxis mit dem in der Theorie übereinstimmt. Für ein echtes paralleles Arbeiten von Mechanik-, Elektronik- und Softwareentwicklung sind die einzelnen Schritte im linken Ast des V-Modells konkretisiert worden und sinnvolle Synchronisationspunkte gefunden, welche sich gleichzeitig als Review-Punkte eignen. Der Abb. 5: Paralleler Durchlauf der einzelnen Vorgehensweisen in der Software (hellblau), Elektronik (grün) und Mechanik (dunkelblau) mit geforderten Synchronisationspunkten PM-aktuell_2-2016_Inhalt_01-72.indd 20 04.04.2016 5: 17: 24 Uhr WISSEN 21 projektManagementaktuell | AUSGABE 2.2016 in die Prozessbeschreibung mit aufgenommen. Dies trägt nun dazu bei, dass der Entwickler zu den Synchronisationspunkten seinen Arbeitsfortschritt aufzeigen kann und die jeweilige geforderte Detailtiefe seiner Arbeit kennt. Der mehrmalige Durchlauf des V-Modells mit der aufgezeigten Umsetzung für den Entwicklungsprozess des Automobilzulieferers stieß im genannten Workshop auf die größte positive Resonanz. Hier konnte besonders der bewusste iterative Durchlauf überzeugen. Vorwiegend die Kollegen aus den Reihen der Entwickler fühlten sich verstanden. Eigentlich arbeiten diese durch die unterschiedlichen Musterstände bereits in iterativen Schleifen, finden diese Arbeit aber nicht im Entwicklungsprozess wieder und stehen stets vor der Aufgabe, einen Prozess zu erfüllen, der nicht ihre Arbeitsweise widerspiegelt. Die Mitarbeiter aus der Prozessbeschreibung haben dieses Modell als Arbeitspaket für die anstehende Überarbeitung des Entwicklungsprozesses aufgenommen. Im Gegensatz zur Projektleitung hat der projektbegleitende Berater eine I-Shape-Persönlichkeit. Dies bedeutet, dass dieser eine Person mit sehr fundiertem und speziellem Fachwissen in einem oder mehreren Themengebieten ist. Er oder sie ist ein Mitarbeiter, welcher losgelöst vom Pool der Produktentwickler ist und von Beginn an dem jeweiligen Fachentwickler und dem gesamten Team zur Verfügung steht. Somit kann auf den Erfahrungsschatz von meist älteren Mitarbeitern zugegriffen werden und junge Mitarbeiter können direkt von diesen lernen. Die aufgezeigten Lösungsmöglichkeiten wurden in einem internen Workshop des Automobilzulieferers mit dem Ziel vorgestellt, hierfür eine Umsetzung in die Praxis zu finden. Für das T-CoachIng gilt sicher, dass dieses im ersten Schritt nicht leicht zu realisieren ist. Schließlich kann ein Stab an Projektleitern nicht einfach ausgetauscht werden. Auch können die Mitarbeiter, die als Berater agieren können, im Entwicklungsprozess nicht schnell ersetzt werden. Dies erfordert einen Prozess, der aus dem bestehenden heraus wachsen muss. Projektleiter müssen für ihre neue Rolle geschult werden bzw. erst bei Neueinstellungen kann auf die besonderen Eigenschaften der T-Shape-Persönlichkeit geachtet werden. Angehende Berater können nur langsam durch neue Mitarbeiter ersetzt werden, was größtenteils Neueinstellungen voraussetzt. Der Punkt, dass räumliche Nähe während des Entwicklungsprozesses sehr wichtig ist, lässt sich ebenfalls zeitnah nicht in die Realität umsetzen, da vorhandene Räumlichkeiten nicht sofort verändert werden können. Jedoch wurde hier für dieses Thema sensibilisiert und über temporäre Arbeitsplätze für Entwickler aus anderen Abteilungen gesprochen, welche in kritischen Entwicklungsphasen eine direkte Zusammenarbeit zwischen den Fachdisziplinen ermöglichen. Der organisierte Wissenstransfer durch regelmäßige Kurzvorträge innerhalb einer Fachabteilung beruht eher auf freiwilliger Basis und kann schwer in einer Prozessbeschreibung festgehalten werden. Bei der Vorstellung der Ergebnisse innerhalb des Workshops traf dieser Vorschlag dennoch auf positive Resonanz. Hier wurde dieser Anreiz in die jeweiligen Entwicklungsabteilungen mitgenommen und soll in Zukunft umgesetzt werden. Die Konkretisierung der Vorgehensweisen für das parallele Arbeiten der einzelnen Entwicklungsabteilungen wurde umgehend aufgegriffen und darstellungen und Lösungsfindungen, indem Gespräche per Telefonkonferenz und mit einem geteilten Bildschirm durchgeführt werden, jedoch ist gerade für die Entwicklung am Objekt bzw. Produkt selbst oder beim Nachbau von Testaufbauten die direkte Zusammenarbeit der unterschiedlichen Disziplinen vonnöten. Die Projektarbeit, selbst bei mittelständischen Unternehmen, ist so umfangreich, dass ähnliche Produkte von unterschiedlichen Entwicklern bearbeitet werden. Damit nicht jeder Einzelne „das Rad neu erfinden“ muss, sondern auf bekannte Problemlösungen zurückgreifen kann, ist es wichtig, einen organisierten Wissenstransfer innerhalb der einzelnen Disziplinen durchzuführen. Hier eignen sich kurze Vorträge im Kreise der jeweiligen Entwicklungsabteilungen, bei denen jeder Entwickler nach eigenem Ermessen und Bedarf teilnehmen kann. Grundsätzlich sollten gefundene Lösungen in sogenannten Lessons Learned-Listen gesammelt werden. Diese neigen aber meist dazu, unübersichtlich und mit Mehrfachbenennungen gefüllt zu werden. Das direkte Gespräch miteinander ist oft auch hier sinnvoller. Damit der Wissenstransfer noch verstärkt werden kann, empfehlen wir eine neue Rollendefinition: das T-CoachIng. Dieses steht für folgende Eigenschaften: Es gibt zwei, engl. two, Betreuer bzw. Coaches, die das Entwicklungsteam unterstützen, auf der einen Seite die Projektleitung und auf der anderen ein projektbegleitender Berater oder eine Beraterin. Die Projektleitung stellt eine Art Team-Coach für das Projektteam dar. Sie fördert die Selbstorganisation und Selbstverantwortung des Teams und entscheidet über den Zugriff von außen auf das Team. Die bei agilen Methoden geforderte T-Shape- Persönlichkeit [8, Kap. 3.1] gilt besonders für die Projektleitung. Dabei steht der Längsstrich des „T“ für ein hohes Maß an Fachkompetenz und der Querstrich für ein breites Wissen über die eigene Fachexpertise hinaus. Er oder sie muss über alle Disziplinen hinweg das Grundverständnis für die jeweilige Entwicklungsarbeit und deren Ergebnisse haben. Gerade im Hinblick auf die Schnittstellendefinition der einzelnen Disziplinen untereinander gilt es, Missverständnisse zu vermeiden. Neben der eigenen fachlichen Qualifikation muss die Projektleitung die Arbeit der einzelnen Fachabteilungen nachvollziehen und Arbeitsergebnisse einschätzen können. Ressourcenplanung, die funktioniert Projektportfolio-Management Ressourcenplanung Zeit-/ Leistungserfassung Kosten-Controlling ½ Tag kostenlose Remote-Beratung Scheuring AG www.ressolution.ch Anzeige PM-aktuell_2-2016_Inhalt_01-72.indd 21 04.04.2016 5: 17: 25 Uhr projektManagementaktuell | AUSGABE 2.2016 22 WISSEN Kompetenzelemente der ICB 4.0 1.02 Governance, Strukturen und Prozesse, 2.03 persönliche Kommunikation, 2.06 Teamarbeit, 2.10 Ergebnisorientierung, 3.04 Ablauf und Termine, 3.05 Organisation, Information und Dokumentation Autoren Prof. Dr. rer. nat. Dorothee Feldmüller ist Professorin für Wirtschaftsinformatik auf dem Campus Velbert/ Heiligenhaus der Hochschule Bochum. Die promovierte Mathematikerin ist seit 1988 in der IT-Branche tätig, sie leitete als freie Projektleiterin und Beraterin zahlreiche IT-Projekte in Unternehmen des Maschinen- und Anlagenbaus und der Fertigungssteuerung. Seit 2004 ist Dorothee Feldmüller aktiv bei der GPM, unter anderem in der Region Dortmund/ Ruhrgebiet und als Leiterin der SIG „PM-Expertinnen“. Anschrift: Hochschule Bochum, Campus Velbert/ Heiligenhaus, Höseler Platz 2, 42579 Heiligenhaus, E-Mail: Dorothee.Feldmueller@ hs-bochum.de M. Eng. Nadine Sticherling war bis zum Sommer 2015 Studentin am Campus Velbert/ Heiligenhaus der Hochschule Bochum und hat ihre Masterarbeit im Bereich Projektmanagement zum Thema „Einsatz agiler Methoden zur Unterstützung der mechatronischen Produktentwicklung“ geschrieben. Bereits nach dem Bachelorabschluss arbeitete sie neben dem Masterstudium als Ingenieurin in der Entwicklungsabteilung eines Automobilzulieferers und hat derzeit die technische Projektleitung für mechatronische Projekte inne. Anschrift: Hochschule Bochum, Campus Velbert/ Heiligenhaus, Höseler Platz 2, 42579 Heiligenhaus, E-Mail: Nadine.Sticherling@ hs-bochum.de hybrides Vorgehen in der Mechatronik entwickelt sich, und die Anteile der Agilität werden wachsen.  Literatur [1] www.agilemanifesto.org/ iso/ de. Stand: 19.2.2014, verabschiedet 2001 [2] Brandes, U./ Gemmer, P./ Koschek, H./ Schültken, L.: Management Y. Campus. Frankfurt 2014 [3] Eliasson, U./ Heldal, R./ Lantz, J./ Berger, C.: Agile Model-Driven Engineering in Mechatronic Systems - An Industrial Case Study. In: Lecture Notes in Computer Science, 8767, 2014, S. 433-449 [4] Grimheden, M. E.: Can agile methods enhance mechatronics design education? In: Mechatronics: the science of intelligent machines, 23, 8, 2013, Pergamon Press, Oxford, S. 967-973 [5] Hruschka, Peter/ Rupp, Chris/ Starke, Gernot: Agility kompakt. Spektrum, Heidelberg Berlin 2004 [6] Klein, T./ Reinhart, G.: Approaches for Integration of Agile Procedures into Mechatronic Engineering of Manufacturing Systems. In: Zaeh, M. F. (Hrsg.): Enabling Manufacturing Competitiveness and Economic Sustainability. Springer, Cham, Heidelberg, New York, Dordrecht, London 2014, S. 225-230 [7] Komus, A./ Kuberg, M.: Status Quo Agile. GPM Deutsche Gesellschaft für Projektmanagement e. V., Nürnberg 2015 [8] Röpstorff, S./ Wiechmann, R.: Scrum in der Praxis - Erfahrungen, Problemfelder und Erfolgsfaktoren. dpunkt.verlag GmbH, Heidelberg 2012 [9] Takeuchi, H./ Nonaka, I.: The new new product development game. In: Harvard Business Review 64, 1986, 1, S. 137-146 [10] Verein Deutscher Ingenieure (VDI): Entwicklungsmethodik für mechatronische Systeme (VDI2206). VDI, Düsseldorf 2004 [11] Welge, M.: Agile Methoden in der Automobilentwicklung. In: projektMANAGEMENT aktuell 2/ 2014, Köln 2014, S. 33-39. [12] West, D.: Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today. Forrester Research, Inc., 2011 Schlagwörter agile Entwicklung, hybrides Vorgehen, mechatronische Produktentwicklung, Projektmanagement, Prozessoptimierung, VDI 2206 Fazit und Ausblick In der mechatronischen Produktentwicklung etablierte Prozessmodelle können und sollten aus Stabilitätsgründen erhalten bleiben. Agile Methoden oder Techniken sollten darin integriert werden, z. B. können agile Methoden wie Scrum oder Kanban im eigentlichen Entwicklungsprozess zum Einsatz kommen. Hybrides Vorgehen im Sinne von Water-Scrum-Fall (vgl. [12, S. 10]) erscheint als der Königsweg, der in der Praxis zunehmend zum Einsatz kommt. Als „leichter Weg“ der Agilität wird ein Einsatz nur in dem Teilbereich Informationstechnik der Mechatronik bezeichnet - ein solches Vorgehen trennt aber die Informationstechnik weiter von den anderen beiden Bereichen Mechanik und Elektronik ab und sollte nur mit Vorsicht eingesetzt werden. Stattdessen sollte ein ganzheitlicher „harter Weg“ gesucht werden, d. h. die Synchronisation aller drei beteiligten Teilbereiche in kurzen Abständen, die als vertikale Integration bezeichnet wird. Dieser „harte Weg“ bedeutet einen hohen Anspruch, da geeignete Zyklen bzw. Synchronisationspunkte für alle drei beteiligten Bereiche gefunden werden müssen. Bislang gibt es nur wenig Hinweise, wie das in der Praxis konkret gelingen kann, zumindest wenn es über den Einsatz von altbewährten Grundlagen hinausgeht. Auch die VDI 2206 kennt die Iteration von Labormuster, Funktionsmuster, Vorserienprodukt usw., aber wirkliche Agilität beinhaltet mehr. In unserem konkreten Unternehmensbeispiel konnten wir zeigen, wie agile Methoden mit dem Vorgehensmodell der VDI 2206 kombiniert werden können - einerseits durch geeignete Iterationen, andererseits durch geeignete Synchronisationspunkte zwischen den Teilbereichen. Hier geht es eher um leicht umzusetzende Anpassungen am Prozessmodell. Weiter gehen die Überlegungen, auch kulturelle Veränderungen in Richtung Agilität in Angriff zu nehmen, die einen größeren Wandel bedeuten und damit umfangreichere Vorbereitungen erfordern und auch nicht in jedem mechatronischen Entwicklungsprojekt einsetzbar sind: räumliche Nähe bei der Zusammenarbeit, mehr Wissenstransfer zwischen den Projekten, neue Rollendefinition im Entwicklungsteam im Sinne von mehr Selbstorganisation im Team. Die Untersuchung hat die Diskussion um derartige Veränderungen in Gang gesetzt und wird in weiteren Untersuchungen fortgesetzt. Zusammenfassend lässt sich sagen: Agiles bzw. PM-aktuell_2-2016_Inhalt_01-72.indd 22 04.04.2016 5: 17: 26 Uhr