Maschinenbau: Management-Erfahrung wichtiger als Kompetenz im Fachgebiet IT

Branche: Maschinenbau - Aufzüge

Linienfunktion: IT

Thema: Software-Entwicklung (Diagnose-Tool), Scrum

Umsatz: >9 Mrd. CHF

Mitarbeiter: 54.000

Aufgabe:

In einem Grosskonzern gab es zur Unterstützung der höher qualifizierten Feldingenieure drei Diagnose-Tools für die jeweiligen Untervarianten einer Produkt-Plattform. Für zwei weitere Plattformen gab es noch kein solches Instrument. Die Anwender der bestehenden Tools waren mit diesen generell sehr zufrieden. Ein grosser Nachteil war jedoch, dass jeweils bei einer Änderung eines Produktes auch das Diagnose-Tool angepasst werden musste.

Daraus entstand die Projektidee, ein neues Diagnosetool zu entwickeln auf der Grundlage eines „generischen Ansatzes", d.h. EIN Software-Instrument für alle 3 Produkt-Plattformen, basierend auf einer gemeinsamen Sprache der Schnittstellen und unabhängig von Änderungen des Produktes. Dieser generische Ansatz war scheinbar, zumindest für die Entwicklungsingenieure, nicht mehr vereinbar mit einer Funktionalität, die von den Feldingenieuren bisher bei den meisten Einsätzen verwendetet wurde und die diese als unverzichtbar taxierten.

Im Weiteren hatten die Entwicklungsteams der 3 Plattformen unterschiedliche Ansichten bezüglich der Konzepte für Diagnose und Unterhalt im Feld. Diese Konzepte bestanden auch, ausser bei einer Plattform, nur in den Köpfen der Teams. Das einzige dokumentierte Konzept einer Plattform war veraltet und das Dokument gar nicht mehr gültig.

Lösung:

(1) Als erstes ging es darum das Projekt aufzusetzen, d.h. die Projektvorbereitung durchzuführen. Die wichtigsten Teile waren die Strukturierung des Projektes (gewählte Struktur: Weg-Resultat-Matrix), die Erarbeitung der Projektorganisation (inkl. aller Stakeholder und des Steering-Comittees) und die Projektplanung. Bei der Planung musste immer der Spagat zwischen der Erreichung der kurzfristigen Ziele (ca. 8 Monate) und der langfristigen Entwicklung (ca. 4 Jahre) gemacht werden, um zu verhindern, dass nach Erreichung des kurzfristigen Ziels (Unterstützung Launch einer neuen Plattform) für das langfristige Projekt nicht wieder von vorne begonnen werden musste.

(2) Es musste sichergestellt werden, dass alle Stakeholder „ins Boot" geholt werden konnten. Dabei zeigte sich rasch, dass das gegenseitige Vertrauen zwischen den Anwendern und den SW-Entwicklern nicht vorhanden war und durch „zuhören" sowie aktivem Suchen nach neuen Lösungen hergestellt werden musste. Ein gewisser Mangel an Kundenorientierung beim Entwicklungsteam war nicht zu übersehen.

(3) Schnell wurde klar, dass ein klassischer Zielkonflikt bestand. Dieser wurde mit einem Problemlösungs-Zyklus bearbeitet. Der entscheidende Ansatz war die klare und eindeutige Definition des Problems. Die Lösungsvarianten wurden anschliessend bewertet und aus der „besten" Variante eine Strategie definiert. Zur Überprüfung wurde diese Strategie noch einem Stress-Test unterzogen (Was wäre, wenn; anhand konkreter „Fälle" aus dem Tagesgeschäft).

(4) Mittels Hinterfragen und Stellen von "dummen Fragen" meinerseits als „nicht IT-Spezialist" (mit der Konsequenz, dass ich manchmal unvorteilhafte Kommentare einstecken musste), fanden die Entwicklungsingenieure trotzdem einen Lösungsansatz, der als „Strategie Notausgang" diente, um insbesondere die stark beunruhigten Stakeholder zu beruhigen und von der Gesamtlösung zu überzeugen.

(5) Als weiteres Mittel zur Überzeugung der Stakeholder diente die klare, aber auch über das eigentliche Projekt hinausgehende Definition des generischen Ansatzes mit Lösungsansätzen für ein übergeordnetes Konzept für Diagnostik und Unterhalt. Dabei musste ich teilweise auch die „Machtachse" der Organisation in Anspruch nehmen.

(6) Eine grosse Aufgabe war das Requirement-Engineering, dazu wählte ich einen „GAP-Ansatz". Basierend auf dem bisher eingesetzten Diagnose-Tool wurden die GAPs, die Unterschiede der neuen zu den bestehenden Anforderungen, beschrieben. Dadurch konnten diese sehr schnell definiert werden und dies zudem noch in einer Form, die die Stakeholder gut verstanden. Anschliessend erfolgte eine Art „Übersetzung" in die Sprache der SW-Entwickler mit der Definition von Use-Cases.

(7) Mit der Entwicklung und Darstellung eines Drafts für das GUI (Graphical User Interface), und dies in mehreren Phasen, konnten die Feldingenieure (Hauptanwender) sehr gut ins Boot geholt werden.

(8) Mit einem neuen SW-Instrument, basierend auf dem SCRUM-Ansatz, wurde der Planungs-Prozess zur Entwicklung der Software implementiert.

(9) Ein Konzept für das Projekt-Marketing rundete die Lösungsansätze ab. Mit der Definition von generellen Ansätzen, aber insbesondere der Durchführung von konkreten Aktionen, galt es das Projekt optimal zu unterstützen.

Ergebnis

(1) Erfolgreiche Erarbeitung (Problemlösungs-Zyklus) und Implementierung (Stakeholder ins Boot holen) einer Strategie zur Überwindung eines für den Projekterfolg entscheidenden Zielkonfliktes

(2) Lösung des Konfliktes zwischen kurzfristig zu erreichendem Zwischenziel (Feb. 2015) und langfristigem Gesamtpaket (2018)

(3) Schaffung der Voraussetzungen für einen erfolgreichen Start der Software-Entwicklung

(4) Erfolgreiche Überbrückung der Barrieren zwischen der „Sprache" der Anwender (Stakeholder) und der „Sprache" der Entwicklungsingenieure. Sensibilisierung der Entwickler für die Anliegen der Anwender.

Peter Lüthi
Profil bei UNITEDINTERIM

Inwilerriedstr. 47
CH-6340 Baar

Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!
www.pl-consulting.ch

+41 79 356 59 24