Kulturkampf Digitalisierung — eine Un-Success Story

Digitalisierung — Was bedeutet das überhaupt?

Immer wieder treffen wir in unserem beruflichen Alltag als Berater auf Unternehmen, die „sich digitalisieren” wollen. Damit können ganz unterschiedliche Dinge gemeint sein: eine Transformation zur Arbeit in agilen Teams, eine Neuaufstellung der digitalen Infrastruktur, eine Umgestaltung der kompletten Unternehmenshierarchie bis zu einer Änderung des Geschäftsmodells.

Im für uns besten Fall ist unseren Auftraggebern im Vornherein das „Warum” und das „Was” klar, und es geht in unseren Gesprächen nur um das „Wie”. Hier handelt es sich um eine klassische Blaupause für Success Stories.
Oft aber kommen wir in Grenzsituationen, in denen unseren Kunden zwar klar ist, dass sie sich ändern müssen — sei es bezüglich Prozessoptimierung, Wettbewerbsfähigkeit, Unternehmensgröße oder wegen einer Vielzahl von anderen Gründen , über die in anderen Blogs schon viel geschrieben wurde — aber nicht wie oder was. Meist kommt unser Mandat direkt aus der Führungsebene. Oft können wir den Unternehmen trotz aller Unklarheiten gut weiterhelfen. Manchmal aber auch nicht, wie die Erfahrung aus einem unserer letzten Projekte zeigt.

Von B2B zu Marke

Unser Kunde, der bisher im B2B-Bereich tätig war, wünschte sich eine teilweise Neuausrichtung. Das Portfolio sollte um eine Luxusmarke aufgestockt werden, welche explizite B2C-Orientierung mithilfe von Internet-Technologien vorsah. Unter Anderem sollten die Kunden der neuen Marke einen personalisierten Fragebogen ausfüllen, um ein perfekt auf sie zugeschnittenes Produkt zu erhalten. Im Vorfeld waren durch namhafte Startup-Berater Marktanalysen durchgeführt worden, man hatte sich auf einen Zielmarkt und eine grundsätzliche Strategie geeinigt. Ein erster Prototyp der neuen Website existierte ebenfalls bereits. Die Beratungsfirma empfahl uns als Partner für die weitere Umsetzung dieses Vorhabens. Berater von UX&I und codecentric machten sich euphorisch auf den Weg, einem neuen Produkt den Weg zu ebnen. Dabei wollten wir durch unsere Kompetenz im test- und hypothesengetriebenen Vorgehen sowie unseren hohen technischen Anspruch unserem Kunden einen Marktvorteil verschaffen.

Die Vertragsgestaltung sah ein agiles Vorgehen vor. Die Beauftragung war kurz: Sie umfasste nur den Umfang des Minimal Viable Products (MVP), eine Verlängerung war jedoch vorgesehen. — Schließlich wussten wir nicht, ob das Produkt Erfolg haben würde. Im Sinne eines Lean Startup trugen wir diese Entscheidung mit und hießen sie gut. Bereits nach kurzer Zeit stießen jedoch wir auf Herausforderungen, die wir nicht erwartet hatten.

Neuland

Es sollte eine Premium-Marke geschaffen werden, die über emotionalen Anspruch und hohe Produktqualität glänzen konnte. Da unser Kunde in diesem Feld bisher noch nicht tätig gewesen war, schlugen wir zwei Dinge vor:

1. Einstellen eines Experten für Premium-Marken und deren Marketing sowie
2. Zahlen- und analysegetriebene Priorisierung der Gestaltung der Website als MVP . Hierbei ist die grundsätzliche Idee, mit einem kleinen Feature-Umfang zu beginnen, Hypothesen — zum Beispiel über das Kundenverhalten — aufzustellen und dann durch konkrete Experimente herauszufinden, welche dieser Hypothesen zutreffend sind und welche nicht. So stellt man sicher, dass man immer nah am tatsächlichen Kunden arbeitet und nicht Luftschlösser spezifiziert, die im schlimmsten Fall an den Kundenbedürfnissen vorbeigehen. Anschauliche Beispiele für diese Art des testgetriebenen Vorgehens sind booking.com oder Netflix .

Im konkreten Projekt stießen wir hier auf mehrere Widerstände: Ein Markenexperte wurde nicht eingestellt. Es gab einen Mitarbeiter¹ in der Marketing-Abteilung, der etwas über ein Drittel seiner Kapazität auf dieses neue Produkt legen sollte. Von ihm kam der meiste Input bezüglich strategischer Ausrichtung.
A/B-Testing oder Verproben von Hypothesen an IT-Produkten waren im Konzern nicht verbreitet. Es gelang uns leider nicht, unsere Vorstellungen von testgetriebenem Vorgehen einzubringen. In den folgenden Monaten kam es daher oft zu Konflikten zwischen unseren Kollegen und Mitarbeitern auf Kundenseite.
Sieht man sich das Umfeld an, in dem sich unser Kunde befand, ist das nur verständlich. Der Konzern war streng hierarchisch ausgelegt. Für jede Produktlinie mussten im Vorfeld Projektionen bezüglich des Verkaufs getroffen werden, für deren Einhaltung die Verantwortlichen geradestehen mussten. Testgetriebenes Vorgehen bedeutet auch immer, Scheitern in Kauf zu nehmen, falls sich die eigenen Hypothesen als falsch herausstellen. Zu sagen: „Wir lagen falsch”, ist in einem streng hierarchischen Großunternehmen oft ein schneller Weg zum Abstellgleis, zumindest aber ein politischer Risikofaktor.
Hinzu kommt noch, dass man gerade im B2B-Umfeld häufig klare Metriken hat, die nichts mit vergleichsweise weichen Zahlen, wie Besucherzahlen einer Website oder Anzahl an Klicks, zu tun haben. – Eine neue Produktlinie verkauft sich oder verkauft sich nicht. Und da man Produktionszyklen mit einberechnet, ist auch der zeitliche Rahmen zwischen Konzeption und Verkaufsstart normalerweise ein anderer als der zeitliche Rahmen, den man benötigt, um evidenzbasiert eine Website zu entwickeln.

Dazu kam — rückwirkend betrachtet —, dass jeder Projektbeteiligte, sowohl im Team als auch seitens der Stakeholder, andere, zum Teil implizite Erfolgsmetriken im Kopf hatte, aus denen sich unterschiedliche Priorisierungen ergaben.

Learning:

Hier hätten wir als Berater die Bedürfnisse des Kunden besser erkennen und mehr auf seine Ängste, Wünsche und Vorstellungen eingehen können. Wir versuchten, dem Kunden eine Fehlerkultur abzufordern, die so nicht gelebt werden konnte, und stießen bei jedem Schritt auf natürliche Widerstände. Einen Schritt zurückzutreten und kritisches Beäugen des Projekts hätte allen Seiten gut getan.

Agiles Arbeiten im nicht-agilen Umfeld

Unsere Arbeitsweise als Berater in einem Unternehmen — unsere Kernkompetenz — ist Technik. Begleiten wir einen Kunden bei einer digitalen Neuausrichtung, tun wir das, indem wir in einem cross-funktionalen Team aus Entwicklern und Beratern in Zusammenarbeit mit Kundenmitarbeitern eine technische Lösung entwickeln. Normalerweise gehen wir gerade bei Unternehmen, für die agiles Arbeiten neu ist, nach Scrum vor. Der Product Owner (PO) und idealerweise einige Entwickler kommen in der Regel vom Kunden. Wir ergänzen durch weitere Entwickler und gegebenenfalls einen agilen Coach oder Scrum Master. Dass ein PO vom Kunden gestellt wird, ist unerlässlich. Akzeptanz im Unternehmen, Vernetzung, strategische Ausrichtung und nicht zuletzt die Priorisierung der für das Projekt notwendigen Arbeiten sollten vom Kunden kommen.

Im konkreten Beispielprojekt war vorgesehen, dass vom Kunden ein PO gestellt wird. Dieser war zuständig für die Priorisierung der Entwicklungstasks der Website sowie das Stakeholder-Management zwischen Marketing, Führungsebene und IT. Außerdem war von codecentric-Seiten ein agiler Coach eingeplant.
Bereits im ersten Projektmeeting kam es zu Spannungen zwischen unserem agilen Coach und dem Kunden. Als Konsequenz wurde vereinbart, dass dieser agile Coach nicht mehr im Projekt tätig sein würde. In der allgemeinen Aufbruchstimmung, die sehr positiv aufgeladen war, einigten wir uns darauf, zunächst kein agiles Coaching zu benötigen.

Learning:

Kommt es zu Spannungen zwischen agilem Coach und Kunden oder gar wegen agiler Vorgehensweise, kann das ein Indiz für starke kulturelle Differenzen sein. Hier ist es unabdingbar, das Projektsetting zu hinterfragen und neu zu justieren.

Die Rolle des Product Owners

Der uns zur Verfügung stehende Product Owner hatte einen beeindruckenden Hintergrund im klassischen Projektmanagement, unter Anderem im Leiten von Großprojekten mit mehreren hundert Beteiligten. Er stand dem Team nur anteilig zur Verfügung. Der Rest seiner Zeit war für andere Aufgaben eingeplant. Das führte zu einem klassischen Bottleneck: User Stories wurden nur unzureichend definiert, wiederholtes Nachfragen kostete viel Zeit und führte zu Frustrationen auf beiden Seiten. Zusätzlich waren die Rollenbilder in den Köpfen der Beteiligten unterschiedlich: Der Kunde sah unseren PO eher als klassischen Projektmanager, unser PO sah sich ebenfalls so. Wir hingegen versuchten, unsere Vorstellung eines POs auf den Kunden zu übertragen. Hier gelang es uns nicht, dieselbe Sprache zu sprechen wie unser Kunde.

Ein Teammitglied übernahm de facto die Rolle eines Proxy-POs, klärte Lücken in den User Stories ab und brachte fehlende Details in Erfahrung. Dies war in der vertraglichen Struktur nicht vorgesehen und wurde nie explizit abgeklärt. Als der entsprechende Kollege das Projekt verließ, wurde allen Verbleibenden eine schmerzliche Lücke bewusst, die vorher niemand wahrgenommen hatte.

Learning:

Kann ein Kunde keinen oder keinen Vollzeit-PO stellen, benötigt man einen Proxy-PO oder — weicher formuliert — “Projektkümmerer”, der den Kundenmitarbeitern unter Anderem praktische PO-Aufgaben abnimmt. Weitere Teile dieser Rolle: Sprachrohr zum Kunden, Anlaufstelle für klärungsbedürftige Fragen etc.

Dies ist immer kundenspezifisch, in jedem Projekt unterschiedlich und sollte, wenn vorhanden, bereits in der Ausgestaltung des Vertrages festgehalten werden.

Mangelnde interne Akzeptanz und Druck auf interne Mitarbeiter

Das Projekt wurde von Anfang an mit hohem Druck vorangetrieben. Es gab Deadlines, die unter Anderem an Produktionszyklen gekoppelt waren. Gleichzeitig wechselten die Anforderungen an die Website stets, die Priorisierung der User Stories wirkte zuweilen chaotisch. Unsere Ansprechpartner beim Kunden waren über längere Zeiträume schwer erreichbar.

Hinterher stellte sich heraus, dass gerade dieses Projekt intern im Unternehmen keine hohe Akzeptanz genoss. Unsere Stakeholder waren oft auf dem Prüfstand und mussten in der begrenzten Zeit, die sie hatten, mehrere Projekte durchführen, von denen unseres nicht besonders hoch priorisiert war. Das führte zu einem Teufelskreis aus Kontextwechseln, Spannungen und Druck, der weitergegeben wurde.

Ein Beispiel kann der IT-Leiter sein, der zwar als Stakeholder an regelmäßigen Reviews teilnahm, aber nur um eine Beschwerdeliste ans Team weiterzugeben, was denn alles nicht funktioniere. Aus seiner Sicht ein vollkommen berechtigtes Vorgehen: Der Dienstleister muss Qualität liefern, und zwar genau wie spezifiziert. Wir erwarteten von unserem Kunden an dieser Stelle eine Flexibilität, die dieser nicht aufbringen konnte — sich ändernde Prioritäten und Anforderungen sind in einem Umfeld mit hohem Druck auf alle Beteiligten, bei klassischem Reporting, nicht vorgesehen.

Learning:

Agilität braucht Freiraum. Entscheidet man sich für ein digitales Transformationsprojekt mit einem agilen Team, muss man diesem Team, inklusive Stakeholdern, die Freiheit geben, die es braucht. Hier ist Support oder entsprechende Akzeptanz auf allen Hierarchieebenen im Unternehmen notwendig.

Projektende

Das MVP „Website” kam zum Go-Live. Im weitergehenden Betrieb kam es dann zu personellen Wechseln in unserem Team: Der de facto Proxy-PO verließ das Team, neue Kollegen wurden eingearbeitet. Hier entstand eine Lücke, die niemand kommen sah. Gleichzeitig gab es jetzt Verkaufszahlen, die darauf hindeuteten, dass das Produkt, so wie es konzipiert war, am Markt — zumindest kurzfristig — keinen großen Erfolg hatte.
Dementsprechend nahm der Druck zu, und es kam immer öfter zu Konflikten zwischen unseren Kollegen und Kundenmitarbeitern. Auch weil die Erwartungshaltungen nicht übereinstimmten und nicht explizit waren. Wir beschlossen schlussendlich gemeinsam, die weitere Kooperation bis auf Wartung der IT-Infrastruktur, die großteilig automatisiert abläuft, zu beenden.

Learning:

Wenn die jeweiligen Kulturunterschiede zu groß sind, um überbrückt zu werden, kann es sinnvoll sein, die Kooperation zu beenden. Das muss nichts Schlechtes sein: Beide Seiten haben Neues gelernt, Schritte gemeinsam unternommen. Das anfangs wenig greifbare Digitalisierungsvorhaben ist weiter konkretisiert worden. Mit dem Gelernten kann unser Kunde in zukünftigen Projekten schneller zu einem Erfolg kommen.

Lessons Learned

Wie genau Digitalisierung in schwierigen Umfeldern zu handhaben ist, ist von Fall zu Fall unterschiedlich. Die Begleitung eines Kunden ist so vielfältig wie unsere Kunden selbst. Klar ist: Viele Kunden haben ein echtes Anliegen, sich weiter in ein agiles Umfeld zu bewegen, dem Strom der Digitalisierung zu folgen, selbst wenn die gewachsenen, hierarchischen Strukturen nicht darauf ausgelegt sind. Als Projektpartner sehen wir es als unsere Aufgabe, unsere Kunden so gut wie möglich auf diesem Weg zu begleiten. Als agiles Unternehmen wissen wir, dass man am besten durch Fehler und den offenen Umgang damit lernt. Die zentralen/die wichtigstenErkenntnisse aus diesem Projekt sind:

Digitalisierungsvorhaben benötigen Support und Freiraum

Wer sein Unternehmen in die digitale Zukunft führen will, sollte sich im Klaren darüber sein, dass es sich unter Umständen um tiefgreifende Änderungen an einem gewachsenen System handelt. Diese Änderungen können nur erfolgen, wenn der erforderliche Support im Unternehmen da ist —von der Führungsebene aus durch alle Hierarchiestufen bis zum Team. Gleichzeitig benötigt das umsetzende Team den nötigen Freiraum, um sich entfalten und produktiv liefern zu können. Das beinhaltet oft einen kulturellen Wandel, den man bewusst vollziehen muss. Kultureller Wandel ist immer mit Spannungen und Schmerzen verbunden. Auch wir als Berater müssen lernen, diese Spannungen rechtzeitig zu erkennen und auf der geeigneten Ebene zu adressieren.

Agilität ist nicht immer und für alle das Maß aller Dinge

Berät man viel im agilen Umfeld, fällt es schwer, sich vorzustellen, wie irgendein anderes Vorgehen zum Erfolg führen kann. Gerade das Wasserfallmodell wird oft angeprangert. Oft zu Recht, jedoch: Gerade in großen Unternehmen gibt es auf allen Ebenen viele Menschen, die noch nie in Berührung mit agilem Vorgehen gekommen sind. Die berechtigte Sorgen haben, „ob das denn alles so funktioniert”. Hier gilt es, Vertrauen aufzubauen und behutsam vorzugehen, Kunden abzuholen und im Zweifelsfall auch einzugestehen, dass eine agile Transformation des Unternehmens zum gegebenen Zeitpunkt nicht oder nur teilweise erfolgen kann. Hier muss man differenziert vorgehen: Sei es, dass man einen „Projektkümmerer” ins Projekt aufnimmt, sei es, dass man dem Kunden ein anderes Unternehmen empfiehlt, das näher an der gewünschten Arbeitsweise des Kunden ist: Im Vordergrund darf nicht nur das „Aber Sie müssen doch jetzt alles anders machen” stehen. Auch kleine Anpassungen oder Veränderungen beim Kunden können mittel- und langfristig große Auswirkungen haben.

Eine gemeinsame Sprache sprechen

Zwischen Agilisten, DevOps-Mentalität, hierarchischen Großunternehmen und Startupkultur bestehen fundamentale Unterschiede in der Weltsicht. Zum Teil werden die gleichen Begriffe verwendet, jedoch in radikal unterschiedlichen Bedeutungen. Das kann dazu führen, dass man aneinander vorbei redet, ohne sich dessen bewusst zu sein. Eine Beauftragung für drei Monate kann für den einen ein Werkvertrag mit klaren Zielen, für den anderen ein „Time and Material” mit Vorschlägen sein. Hier ist es unabdingbar, dass man sich selbst und die Zusammenarbeit immer wieder kritisch hinterfragt und gerade bei Konflikten darauf achtet, wer sich wie ausdrückt und was genau gemeint ist. Nur so kann eine echte gemeinsame Lösung entstehen.

Fazit

Es ist schwer, ein Digitalisierungsvorhaben durchzuführen. Selbst wenn das „Was”, „Wie” und „Warum” von Anfang an klar sind, bestehen Ungewissheiten. Und diese Klarheit in allen Punkten entsteht nicht von alleine, sondern ist harte Arbeit. Wichtig ist, dass man sich immer wieder vor Augen führt, dass auch bei unklarer Sachlage ein Mehrwert entstehen und man aus einem Digitalisierungsvorhaben immer etwas lernen kann. Im Beispielprojekt hatte unser Kunde echten Mehrwert — zumindest ein Produkt und eine Website dafür. Beide Seiten gewannen wertvolle Einblicke: Der Kunde in die neue digitale Welt, wir in ein für das Team neues Setting zur Produktentwicklung. Alle Beteiligten können nun mit zukünftigen Herausforderungen besser umgehen. Digitalisierungsprojekte in Grenzsituationen können also durchaus für beide Seiten ein Erfolg sein, sogar wenn das übergeordnete Vorhaben im ersten Anlauf scheitern sollte.

¹ Wir entscheiden uns an dieser Stelle bewusst für das generische Maskulinum, um die Anonymität aller betroffenen Personen zu wahren.