Agil scheinen oder agil sein?

Als ich vor Jahren das erste Mal von Agilität hörte, hatte ich zunächst den Eindruck, Prozesse und Regeln sollten über Bord geworfen werden, um volatile Anforderungen auf wundersame Weise im Handumdrehen realisieren zu können. Ich konnte mir nicht vorstellen, wie das funktionieren soll: Agilität klang für mich nach unerfüllbarem Wunschkonzert.

Erst als unser damaliges Software-Entwicklungsteam anfing nach Scrum zu arbeiten – mit mir als Product Owner und begleitet durch einen erfahrenen Scrum Master – habe ich mich mit dem Thema ernsthaft auseinandergesetzt.

Ich lernte, dass Agilität nicht Chaos bedeutet, sondern ganz im Gegenteil lautete die

1. Lektion: Disziplin

Agiles Vorgehen hat Regeln. Die lernten wir in der vorausgehenden Scrum-Schulung. Vor allem aber legte unser Scrum Master uns sehr ans Herz, die Scrum-Regeln strikt einzuhalten, statt sie so auszulegen, wie es für uns am sinnvollsten erschien. Was ich gelernt habe: Agilität ist kein Laissez-faire, sondern bedarf eines sehr disziplinierten Vorgehens, das nur funktioniert, wenn es konsequent gelebt und nicht nach Bedarf verbogen wird.

2. Lektion: Der Sinn

Feste Rollen und Rituale sind nützlich. Wir hatten sie für Scrum zwar gelernt, aber echtes Verständnis wuchs erst nach und nach über das Coaching und die Fragen des Scrum Masters. Beispielweise wenn sich im Lauf eines Sprints herauskristallisierte, dass mehrere der vereinbarten User Storys nicht erreicht werden würden. Alle Teammitglieder versuchten natürlich, ihre eigene Aufgabe bestmöglich zu erledigen. Das hätte dazu geführt, dass die einzelnen User Storys zu nur 70% fertig werden würden. Der Scrum Master stellte zur Diskussion, stattdessen ein oder zwei User Storys für den Sprint zu verwerfen und bei der Fertigstellung der anderen mitzuhelfen. Was wir gelernt haben: Ergebnisorientierung und Fokussierung auf ein gemeinsames Ziel machen das Teamwork produktiver und die Teammitglieder zufriedener.

3. Lektion: Teamgeist

Je mehr wir den Sinn der Regeln, Rollen und Rituale verinnerlichten, desto effizienter wurden die Projekte. Das Team wuchs immer stärker zusammen und es entwickelte sich nicht nur ein gemeinsamer Fokus darauf das Ziel zu erreichen, sondern echter Zusammenhalt. Wo vorher Kollegen Unverständnis über die Arbeit der jeweils anderen geäußert hatten oder sich in Schuldzuweisungen übten, wusste nun jeder im Team, was die anderen machten und warum. Man half sich gegenseitig nach Kräften und vertraute einander immer mehr. Und da nachhaltiges Lernen vor allem über positive Emotionen funktioniert, war dies der Punkt, an dem wir wirkliches Verständnis für Agilität entwickelten.

Am Ende wurde mir klar, dass Agilität erst durch das Zusammenspiel von Regeln, Menschen und Motivation entsteht. Die hinter den Regeln stehenden agilen Werte zu verstehen, ist entscheidend. Sonst besteht die Gefahr – durch das Herausgreifen oder Zurechtbiegen einzelner Regeln auf die eigenen Bedürfnisse – mit dem agilen Ansatz zu scheitern.

Was nicht heißt, dass man die agilen Frameworks nicht anpassen oder selektiv anwenden darf. Aber erst, wenn man sie verstanden hat.

Über IoT-Failures und Vertrauen in Technologie

Anfang April diesen Jahres besuchte ich die building IoT in Köln. Bei der Fachkonferenz, die von heise developer, iX und d.punkt Verlag organisiert wurde, drehte sich in Vorträgen und einer Ausstellung alles rund um Anwendungen für das Internet der Dinge (IoT) und Industrie 4.0. Zusammen mit meiner Kollegin Yang Zhong durfte ich in einem Vortrag  moderne User-Experience-Konzepte (UX) für IoT-Lösungen vorstellen.

Zum Abschluss unseres Vortrags, der einen Arbeitsprozess eines Anwenders, von der Datenaufnahme eines realen „Things“ bis zur Visualisierung der Live-Daten im Dashboard mittels Digitalem Zwilling zeigte, gab es eine sehr anregende Diskussion. Zwei Punkte waren hier besonders interessant: 

  • In vielen Anwendungsbereichen steht das Thema Customer-Journey weit oben auf der Agenda – was den aktuellen Trend bestätigt.  
  • Es ist essentiell, Software für Anwender zu entwickeln – was auch Konsens war.

Der Abend gehörte ganz dem Thema Industrial IoT. Als Moderatorin leitete ich eine Gesprächsrunde aus Vertretern unterschiedlicher Unternehmen und Softwarefirmen, wie beispielsweise Miele, Dürr Dental, Codecentric oder akquinet. Hier entwickelte sich eine intensive Diskussion um die vorherrschenden Themen der Industrie 4.0. Dazu gehören neben der Wahl der Steuerungselektronik oder des Funkstandards auch Fragestellungen, ob eine IoT-Lösung in einer Cloud betrieben werden soll. Gründe für Lösungen in einer Cloud sind natürlich der Komfort und die relativ effiziente und einfache Skalierbarkeit was die Anzahl der zu verwaltenden „Things“ betrifft. Im Gegensatz dazu spricht für das Verwalten der Software auf eigenen Servern (on-premise), dass vertrauliche Produkt- oder Kundendaten das Haus auch wirklich nicht verlassen. Die Diskussion hat meine Einschätzung bestätigt, dass beide Vorgehensweisen in der Praxis ihre Vorteile haben und entsprechend Anwendung finden.

Eines meiner persönlichen Highlights der diesjährigen building IoT war eine negative Hitliste mit IoT Produkten, so genannte IoT-Failures: Produkte also, die massive Sicherheitslücken besitzen, wie beispielsweise offene Datenschnittstellen. Einige „klassische“ Lücken waren schon bekannt, wie nicht geänderte Standard-Passwörter, die Datenmissbrauch/-diebstahl ermöglichen. Von anderen war ich überrascht: wie zum Beispiel einem Rauchmelder eines namhaften Herstellers, der bereits serienmäßig mit einem Mikrophon (?!) ausgestattet wurde, das wiederum unerwünschtes Mithören in Wohnräumen erlaubt.

Warum ist ein Mikrophon in einem Rauchmelder zu finden?  Das können wir nicht mit Sicherheit sagen, zumindest ist es nicht im Sinne des Kunden und lässt das Vertrauen in die Technik massiv schwinden. Und genau das ist der springende Punkt: Akzeptanz für neue Technologien benötigt Vertrauen. Und das wird bei  der zunehmenden Digitalisierung immer wichtiger.

20 Jahre PLM: Warum zweifeln Viele noch immer am Nutzen?

Mittlerweile blicke ich auf einige Jahre Beratung für Product Lifecycle Management zurück. Ein Thema, dessen Popularität im Laufe der Jahre deutlich schwankte und aktuell im Gefolge der Digitalen Transformation wieder stark im Aufwind ist.

Trotz der wieder steigenden Aufmerksamkeit für PLM bemerke ich, dass dem Begriff unverändert die Geschmacksnoten groß, schwerfällig, langwierig, unwirtschaftlich anhaften. Erstaunlich, denn der Aufwand, den viele Unternehmen beispielsweise in ERP-Projekte stecken, war und ist in den meisten Fällen deutlich höher. Dennoch werden Notwendigkeit und Nutzen von – teuren – ERP-Projekten zwar diskutiert, aber nur selten in Frage gestellt, siehe etwa Haribo und Lidl.

Wie kommt es zu dieser unterschiedlichen Wahrnehmung? Eine Erklärung könnte sein, dass sich der Nutzen von PLM für Management und Mitarbeiter in den Unternehmen über Jahre nicht ausreichend erschlossen hat. Das lag vor allem daran, dass Reichweite und Sichtbarkeit der PLM-Projekte in den Unternehmen oft sehr eingeschränkt war.

Ein genauer Blick zeigt, dass viele der früheren PLM-Einführungen in Wahrheit eher PDM-Einführungen waren. PDM, Produktdaten Management, konzentriert sich auf produktbeschreibende Daten, also in erster Linie CAD-Modelle und Zeichnungen. Damit beschränkte sich der „PLM“-Einsatz eher nur auf die Kernbereiche der Produktentwicklung, sehr oft sogar ausschließlich auf die Mechanik-Konstruktion. Obwohl meist schon seit Jahren in einigen PLM-Lösungen verfügbar, wurden z.B. Änderungsmanagement, Dokumentenmanagement, Projektmanagement, abteilungsübergreifende Zusammenarbeit oder die Kommunikation mit Externen nicht genutzt. Stattdessen wurden oft vermeintlich „günstige“ Lösungen auf Basis von Excel, Outlook, dem Dateisystem oder Sharepoint in Eigenregie erstellt. Werkzeuge, die jeder im Unternehmen kennt. Und für die sich meist schnell jemand findet, der diese Tools per Makroprogrammierung „optimiert“. Geschürt wurde die ablehnende Haltung gegenüber PLM dabei sicher auch durch die überfrachteten, hochverdichten „Ingenieurs-Benutzeroberflächen“ der 1. und 2. PLM-Produktgeneration.

Da überrascht es nicht, dass PLM im Unternehmen als teure, wenig Nutzen stiftende und exotische Anwendung gesehen wurde.

In der aktuellen PLM-Renaissance haben die Unternehmen jetzt alle Chancen, aus den Defiziten der Vergangenheit zu lernen und die mittlerweile beeindruckenden Potenziale des Product Lifecycle Managements zu nutzen. Viele veraltete und abgekündigte PDM- und PLM-Lösungen werden aktuell oder demnächst gegen moderne PLM-Plattformen der 3. Generation ausgetauscht, die zudem auch die Anwendungsfälle rund um den Digitalen Zwilling und im Internet der Dinge unterstützen. Sie füllen die PLM-Idee mit Leben, indem sie die Prozesse über die Phasen, Fachbereiche und Unternehmensgrenzen hinweg effektiv und effizient begleiten. Dabei erhöhen neue, webbasierte HTML-5 Benutzeroberflächen die Akzeptanz bei allen Benutzergruppen im Unternehmen deutlich, indem sie auch komplexe Zusammenhänge übersichtlicher und im Handling performanter machen.

Jetzt besteht die Chance, „echtes“ Product Lifecycle Management zu verwirklichen! Vor dem Hintergrund neuer, digitaler Geschäftsmodelle, die die Nutzungsphase von Produkten viel stärker in den Vordergrund rücken, wird dies umso wichtiger. PLM-Lösungen fällt hier eine zentrale Bedeutung zu, denn sie legen den Grundstein für die Daten rund um den Digitalen Zwilling.

Aber am Ende zählen auch harte Fakten, wenn es um den Nutzen und RoI geht: Wird PLM tatsächlich mit all seinen Möglichkeiten unternehmensweit genutzt, ergeben sich schnell hohe Skaleneffekte durch die deutliche Minimierung von nicht-wertschöpfenden Tätigkeiten. Dies allein ermöglicht oft schon einen Return on Investment nach gut einem Jahr. Unbenommen der zusätzlichen Umsatzpotenziale aus neuen, datengetriebenen Geschäftsmodellen, die PLM zukünftig ermöglichen wird.