Opel – Agiles Daten-Management in der Praxis


Wie alles begann – Die OPEL Success Story

CC0 Public Domain - Pixabay

Wenn eine Firma in der Krise steckt, rumort es bei den kreativen Köpfen und es ergeben sich einmalige Möglichkeiten.

Der Autobauer OPEL hat die Krise zu Beginn der zweiten Dekade des neuen Jahrtausends zu einem radikalen “Umdenken im Kopf” genutzt und administrative Prozesse in der Entwicklung konsequent hinterfragt und innovativ neue Ideen entwickelt.

So entstand die fruchtbare Zusammenarbeit von engagierten Auto-Entwicklern mit einem hoch motivierten Team von Software-Entwicklern.

Das Ergebnis war eine neuartige Software zur agilen Daten-Handhabung.

Ausgangspunkt

Wie in wohl jeder Firma beginnt ein neues Projekt mit der Erstellung von Bildern und Listen. Man verwendet dazu Microsoft Powerpoint und Excel oder eine analoge Software — weil es so einfach geht und man außerdem auch nichts Besseres kennt bzw. greifbar hat.

Flexibilität ist gefordert

Bei den Auto-Entwicklern dreht sich sehr viel um die Erstellung von vorläufigen Teile-Listen. Das ist ein sehr dynamischer Prozess, der hohe Flexibilität erfordert. In vielen Meetings entstehen Konzepte, werden bewertet, wieder verworfen und letztendlich immer weiter detailliert. Neudeutsch nennt man das „agiles Management“. Die dabei verwendeten Formate, hier besonders die Spalten der Listen (Bedeutung und Anordnung) unterliegt einem ständigen Wandel. Projekte werden immer komplexer, ebenso sind die Fach-Experten immer wieder kreativ und erweitern und optimieren ihre Daten.

Kollaboration

Schon sehr früh werden diese Listen mit anderen Betroffenen geteilt: Es beginnt mit der Produktentwicklung und Teilebeschaffung für den Prototypenbau. Die große Herausforderung ist, die Informationen in einer konsolidierten Liste zusammenzuhalten und eine stabile und nachvollziehbare Kommunikation hinzubekommen.

Wachstum

Nur kurze Zeit später interessieren sich weitere Bereiche für diese Daten. Alle verwenden die Basis-Informationen und fügen rechts ihre eigenen Spalten zu: Der Einkauf definiert potentielle Lieferanten, die Finanz vorläufige Kostenschätzungen, die Freigabe-Ingenieure ihre Termine, der Prototypenbau Rohmaterial-Berechnungen, das Labor Materialspezifikationen, …

Das Dilemma

In der alten Welt wurden diese sich ständig verändernden Listen per E-Mail regelmäßig neu als “Konstruktions-Mitteilung” an möglichst viele Empfänger verschickt. Später gab es dann Systeme wie Microsoft Sharepoint, wo man diese Listen zentral ablegen konnte.

Aber das Grundproblem ist damit immer noch nicht gelöst: Es bleiben eigenständige Dateien.

Wer zählt eigentlich die Stunden, die in einer nur mittelgroßen Firma aufgewendet werden, um solche „abgeleiteten“ Listen auf Stand zu halten? Dieser Aufwand fällt unter Büro-Arbeiten und wird nirgendwo budgetiert. Wenn dies aber nicht sorgfältig gemacht wird, kann das große Auswirkungen haben: Im schlimmsten Fall werden aufgrund nicht aktueller Informationen veraltete Prototypen-Teile teuer eingekauft und müssen dann sinnlos verschrottet werden!

Eigentlich bräuchte man ein System, bei dem man die Zeilen einer Liste mit Zeilen einer anderen Liste wie mit einem Gummiband verbinden und gemeinsam darstellen könnte.

Opel – Umdenken im Kopf

Genau dieses Problem sind die Leute bei Opel mit einer sehr kreativen Idee angegangen. Unterstützt durch die auch in den Medien verbreitete große Motivations-Initiative entstand eine allgemeine Aufbruchs-Stimmung die letztendlich die Einsicht förderte, dass das bisherige Silo-Denken und die „über den Zaun werfen“-Mentalität unter den einzelnen Fachbereichen überwunden werden muss. Das ist ein mühsamer Prozess, weil sämtliche Mitarbeiter aus ihren „Komfort-Zonen“ gelockt werden müssen.

Es kommt darauf an, grundsätzliche Arbeitsweisen zu verändern. Daten miteinander teilen.

Wow, was für eine großartige Idee, die als große Vision bestimmt im Kopf eines jeden Prozess-Verantwortlichen existiert. Aber was wurde nun konkret getan, um dies in der Praxis auch erlebbar zu realisieren?

Das Wichtigste Ziel war: Es muss nachhaltig Spaß machen! Es musste ein System gefunden werden, das die Mitarbeiter bei der Stange hält. Es hilft nicht, wenn sich wichtige Mitspieler nach kurzer Zeit wieder zurückziehen und wieder anfangen ihr eigenes Süppchen zu kochen.

Es gab einen großen Workshop, der bei Opel als „Value Stream Mapping Analysis“ bezeichnet wird.

Das Ergebnis war erst mal eine frustrierend riesige Excel-Datei mit mehr als 150 Spalten, die allen Erfordernissen gerecht werden sollte. Es war schnell klar, dass dies nicht die Lösung sein konnte.

Business meets IT oder IT meets Business

Auch wenn man mit modernen Google-Lösungen das Problem des gemeinsamen Datenzugriffs in den Griff bekommen könnte, ist dies doch eine Komplexität, für die eine flache Liste einfach nicht mehr ausreicht.

Auf der anderen Seite liebt gerade diese Anwendergruppe große Listen, bei denen man alle Zusammenhänge auf einen Blick erkennen kann und die Übersicht behält. Genial wäre dazu noch die Möglichkeit, diese Listen aufklappen zu können um (z.B. Zusammenbau-)Strukturen dazustellen oder noch weitere Details bei Bedarf mit einblenden zu können.

Ein „Schlüsselloch-Blick“, der in einem Formular immer nur Details eines einzigen Datensatzes anzeigt, ist für diese Art der Anwendung dagegen ungeeignet.

Eine Spruchkarte, die zu dieser Zeit bei Opel beliebt war sagte: Hannibal: Entweder wir finden einen Weg, oder wir bahnen uns einen!

Zunächst wurde eine klassische Datenbank-Lösung in Erwägung gezogen, die ja nach allgemeinem Verständnis solche Fragestellungen von verknüpften Elementen lösen können müsste. Zwei entscheidende Punkte kristallisierten sich aber als kritisch heraus:

  • Für ein eigenes IT-Projekt für das man Geld auszugeben bereit gewesen wäre, waren die Anzahl der beteiligten Nutzer und die Anzahl der Datensätze zu gering. Außerdem passte dies zunächst nicht in die globalen Konzern-Überlegungen hinein, wo man gerade dabei ist, eine riesige allumfassende Lösung für alle Themen rund um Stückliste und Änderungs-Management zentral zu konzipieren und dann langfristig „gleich richtig“ zu implementieren.

  • Aus Anwender-Sicht ist für den Spaßfaktor die Geschwindigkeit einfach essentiell. Es geht hier nicht darum, wie bei einer Sparkassen-Anwendung die letzten 30 Kontobewegungen aus einer großen Datenmenge herauszufiltern, wo man noch dazu bereit ist, mal 20 Sekunden auf die Antwort zu warten. Hier geht es tatsächlich darum, alles mit allem zu verknüpfen und in Echtzeit anzuzeigen.

Die nächste Versuchung war dann groß, den sogenannten „Graswurzel“-Ansatz zu versuchen: Man gibt einem engagierten IT-Studenten die Möglichkeit, als Praktikant Berührung mit der Praxis zu bekommen. Dieser “zimmert” in ca. 4 Monaten ein Konglomerat aus Makros, Web-Seiten und anderen modernen IT-Mitteln (die Cloud nicht vergessen), das die Bedürfnisse zumindest der wortführenden Anwender zur vollen Zufriedenheit erfüllt, wenigstens zum Zeitpunkt der Einführung. Schade eigentlich, dass man keine Möglichkeit hatte, dieser Person eine Festanstellung anzubieten. (… hier wird schnell klar, warum das für IT-Verantwortliche eine Horror-Vorstellung ist und deshalb aus gutem Grund und mit aller Kraft gegen sogenannte „Shadow-IT“ gekämpft wird.)

Software-Entwicklung mit Agilen Methoden

Manchmal braucht es auch ein wenig Glück, dass einem im richtigen Moment die richtigen Leute über den Weg laufen. So kam es zur gegenseitig befruchtenden Zusammenarbeit mit der innovativen Startup-Firma KATLA. Diese Firma beschäftigt sich mit Themen rund um agile Arbeitsweisen und wie man dies von der Daten-Seite bestmöglich unterstützen kann. Herausgefordert von den „Maximal-Forderungen“ der Firma Opel ergab sich die Entwicklung einer komplett andersartigen Datenbank-Software, die heute den Namen JACAMAR trägt.

Das Prinzip der „Agilen Software Entwicklung“ wurde hier konsequent umgesetzt. Von der ersten rudimentären, aber lauffähigen Version wurden im Laufe von 1 ½ Jahren sage und schreibe 28 Versionen freigegeben, die von Anfang an produktiv verwendet wurden. Dadurch entstand eine einmalige „User-Experience“. Die Opel-Mitarbeiter waren die besten Tester und Kritiker und maßgeblich dabei, wenn es darum ging, die Inhalte für den nächsten „Sprint“ festzulegen. Es gab eine wunderbare Unterstützung durch die jeweiligen Vorgesetzten aus den Fachbereichen, die auch Krisen auf diesem Weg als Chancen betrachtet haben. Die Programmierer von KATLA waren durch den intensiven Kontakt in besonderer Weise herausgefordert, den hohen Erwartungen des Kunden gerecht zu werden.

Das Konzept

Das von KATLA verfolgte Ziel war es, eine leichtgewichtige Software, die letztendlich eben gerade keine Opel-Spezialanwendung wird, sondern allgemein anwendbar sein kann.

Dabei wurden 3 Konzepte vereinigt:
No Server

Was die IT-Abteilung am meisten freut: Es gibt in der Tat keinen aufwändig zu betreuenden Server im Netzwerk, auf den die Nutzer in der Regel die meiste Zeit warten müssen. Wie beim beliebten Excel wird alles auf den Endbenutzer-Rechner geladen. Nur zum Speichern braucht man einen Netzwerk-Kontakt, damit die einzelnen Anwender, die weltweit verteilt sein können, synchronisiert werden. Dieses Prinzip ist auch unter dem Namen „In-Memory-Datenbank“ bekannt und ermöglicht in der Praxis die tatsächlich bestmögliche Echtzeit-Bildschirm-Anzeige-Geschwindigkeit auch von riesigen Datenmengen. Weiterhin haben die Programmierer der Anzeige noch eine Funktionalität spendiert, die sie „Touch-Slide“ nennen, mit der man die riesigen Tabellen auch auf einem klassischen Standard-PC wie bei Google-Maps einfach mit der Maus in alle Richtungen verschieben kann, ohne mühsam die Scroll-Bars an den Seiten benutzen zu müssen.

No Programming

Die größten Bedenken von Anwendern bei der Einführung von neuen Datenbank-Lösungen ist, dass sie über längere Zeiträume mit dem in die Datenbank „eingebrannten“ Datenmodell leben müssen, obwohl sich der Business-Prozess schon lange verändert hat. Die Konsequenz ist, dass freie Datenfelder „missbraucht“ werden, ohne vernünftig dokumentiert zu sein. Oft flüchten die Anwender auch zurück in private Excel-Listen, was auch nicht im Sinne des Erfinders sein kann.

In der JACAMAR Software ist das Daten-Meta-Modell direkt online veränderbar. Die 3-dimensionale Visualisierung ermöglicht es, wirklich die Daten-Tabellen und ihre Verknüpfungen sichtbar vor sich zu haben, sodass beteiligte Anwendervertreter (Key-User) die tatsächlich gewünschten Abhängigkeiten ausdiskutieren können und direkt gleich implementieren können. Wenn dann in den nächsten Tagen in der Praxis-Anwendung klar wird, dass der erste Schuss noch nicht gesessen hat, kann man kurzfristig wieder zusammenkommen und direkt optimieren.

No SQL

Im Gegensatz zu Excel, wo man direkt in der Liste ändert (und damit bei gemeinsamer Benutzung den Kollegen evtl. auch etwas kaputt machen könnte), definiert man in JACAMAR Ansichten, in die man sich genau die (und nur die) Informationen hineinziehen kann, die man benötigt. Hier gibt es natürlich auch ein Berechtigungs-Konzept, wo Administratoren Schreibrechte und damit Workflows festlegen können.

Eine Grundvoraussetzung damit das alles auch praktikabel wird, ist eine einfache Konfigurations-Sprache, die es auch „normalen“ Auto-Entwicklern ermöglicht, auszudrücken, was in den einzelnen Zeilen und Spalten dargestellt werden soll. So einfach wie in Excel, wo man einfach eine neue Spaltenüberschrift definiert hat und loslegen konnte.

Der Kunden-Nutzen

Schon bald nach Einführung der ersten Versionen in der Produkt-Abteilung kamen bei Opel Vertreter vom Einkauf und konnten kaum glauben, dass es jetzt tatsächlich EINE aktuelle Liste der neuen Teile geben sollte. Bisher mussten diese Informationen immer aus vielen verschiedenen Quellen mit teils unklarem Freigabestand zusammengezogen werden. Die Kollegen fragten, ob sie diese Liste vielleicht haben könnten. Die Antwort war ein klares Nein. Man wollte ja keine Daten mehr verteilen (Stichwort: Datenproliferation). Aber sie könnten sich gern an die Original-Daten „andocken“ und durch eine kurzfristige Erweiterung des Datenmodells ihre eigenen Informationen mit in den gemeinsamen Daten-Pool einbringen.

Dies geschah mit verschiedenen Abteilungen. Im Ergebnis stieg die Zahl der Benutzer von ursprünglich mal 30 Gruppenleitern und Planern auf mittlerweile weltweit bis zu 800 eingetragene Mitarbeiter in ca. 50 Benutzer-Rollen mit ca. 200 von den Anwendern selbst maßgeschneiderten Ansichten.

Opel-Astra-2016-auto-des-jahres

Durch das No-Server und das In-Memory Prinzip können alle diese Mitarbeiter mit der gleichen Hochgeschwindigkeit arbeiten, da ja letztendlich jeder die Daten direkt auf seinem Rechner hat, aber eben nur das sichtbar ist, was gebraucht wird und was sie auch sehen dürfen.

Der neue Astra, das Auto des Jahres 2016, war zusammen mit den weltweiten Geschwister-Fahrzeugen das erste Projekt, bei dem diese Software zu Einsatz kam. Seitdem geht es mit Opel wieder aufwärts. 🙂

 

Der Artikel ist auch in English verfügbar.