Die Einführung einer neuen digitalen Lösung in Unternehmen stellt viele agile Teams vor große Herausforderungen. Es ist entscheidend, dass die Entwicklung einer Software und die damit einhergehenden organisatorischen Veränderungen Hand in Hand gehen, um den nachhaltigen Erfolg zu sichern.
In einer idealen Welt greifen die Softwareentwicklung und -einführung nahtlos ineinander: ein Inkrement wird ausgeliefert, produktiv verwendet, Feedback von Nutzer:innen proaktiv gegeben und das Produkt wird angepasst. Insbesondere die produktive Nutzung des neuen Systems und das daraus resultierende Feedback sind essentiell für den nachhaltigen Erfolg einer neuen Lösung. Auch wenn man vorab durch effektive Product Discovery das Risiko minimiert hat, am Bedarf vorbei zu entwickeln, zeigen sich die letzten und oft entscheidenden Anforderungen erst bei tatsächlicher Verwendung.
In der Realität treffen wir allerdings oft auf Rahmenbedingungen, die einen reibungslosen Dual Track Agile – Ansatz deutlich erschweren. Die Entwicklung der Software stellt dabei häufig den „leichteren“ Teil dar, verglichen mit den daraus resultierenden organisatorischen Veränderungen. Wir investieren typischerweise Zeit und Energie, um eine neue Softwarelösung von Anfang an konsequent an den Bedürfnissen und dem Alltag der Nutzer:innen auszurichten. Doch selbst mit einem sehr nutzerzentrierten Ansatz stoßen wir bei der Einführung neuer digitaler Lösungen häufig auf organisatorische Hürden.
In diesem Blogartikel werden gängige Herausforderungen skizziert und es wird aufgezeigt, wie man effektiv mit ihnen umgehen kann.
Typische Herausforderungen
Stress im Alltag
Um eine neue Software zu entwickeln und einzuführen, sind wir auf die aktive Mitarbeit unserer Nutzer:innen angewiesen. Wir müssen ein profundes Verständnis ihres Alltags, ihrer Bedürfnisse und Probleme aufbauen, um eine effektive Lösung zu entwickeln. Um in die Welt der Nutzer:innen einzutauchen und die Basis für das Requirement Engineering zu schaffen, greifen wir auf Methoden wie z. B. User Shadowing, Usability Prototyping oder User Story Mapping Workshops zurück. Nach Auslieferung eines Inkrements sammeln wir Feedback bspw. in Sprint Reviews und schauen uns die Benutzung der neuen Software am Arbeitsplatz an.
Der Alltag der Anwender:innen lässt initial häufig keine enge Zusammenarbeit zu. Denken wir beispielsweise an eine Klinik: die Chefärzt:innen haben wenig Zeit neben ihrem Tagesgeschäft, das medizinische Fachpersonal ist im Schichtbetrieb bis zur letzten Minute eingespannt und die Administration versinkt in Papier. Die gleiche Situation findet sich auch in vielen anderen Branchen. Es erfordert Zeit und Ruhe, sich mit einer neuen Software auseinanderzusetzen. In den seltensten Fällen ist diese Zeit vorhanden, sondern muss aktiv eingeräumt werden.
Widerstand gegen Veränderung
Obwohl Veränderung immer eine Chance ist, sich und die Organisation zukunftssicher aufzustellen, löst sie häufig Angst und Widerstände aus. Das ist auch nachvollziehbar, denn Veränderung wirft einige Fragen auf: Wie sieht mein Platz in dieser neuen digitalen Welt aus? Werde ich noch gebraucht? Verliere ich meinen Status?
Die Reaktionen auf diese sehr tief verankerte Unsicherheit können sehr vielfältig ausfallen. Beispielsweise wird relevantes, oft implizites Wissen (bewusst oder unbewusst) zurückgehalten, was die Anforderungserhebung deutlich erschwert. Oft folgen hier Aussagen wie „Mein Fachwissen ist nicht in der Software abbildbar, das ist zu komplex“, um den eigenen Wert nochmals hervorzuheben.
Eine andere Reaktion ist das bewusste Hinauszögern der produktiven Nutzung. Oft findet sich eine Vielzahl an Gegenargumenten, weshalb man noch nicht loslegen kann. Aussagen wie „Bevor nicht alles fertig ist, können wir das Altsystem nicht ablösen“ oder „Ich kann nicht in zwei Systemen (neu und alt) parallel arbeiten, dafür habe ich keine Zeit“ sind keine Seltenheit. Eine andere Verzögerungstaktik ist das Verstecken hinter dem stressigen Tagesgeschäft als Grund, keine Zeit zur aktiven Mitarbeit zu haben.
Damit eine neue Software sich gegen Altsysteme (digital oder analog) durchsetzen kann, muss diese aktiv und kontinuierlich genutzt und die damit einhergehende Veränderung muss zugelassen werden.
Silodenken
Eine neue digitale Lösung ermöglicht es häufig, Prozesse über Abteilungsgrenzen hinweg neu zu gestalten. Oft können einfache, repetitive Aufgaben automatisiert werden und selbst komplexe Tätigkeiten können durch Software drastisch vereinfacht werden. Mit dem neu gewonnenen Spielraum können bestehende Abläufe neu und digital gedacht werden, was aber nicht selten einer grundlegenden Umstrukturierung bedarf.
Die ganzheitliche Neugestaltung erfordert jedoch eine abteilungsübergreifende Zusammenarbeit und Offenheit. Hier beobachten wir nicht selten ausgeprägtes Silodenken. Die Auswirkungen des eigenen Verhaltens auf einen vor- oder nachgelagerten Prozessschritt sind oft nicht bekannt (z. B. Auswirkung fehlender/verzögerter Dokumentation), Doppelarbeiten sind nicht sichtbar (z. B. zwei Listen für dieselben Informationen), ein Austausch an den Schnittstellen findet nicht oder sehr selten statt und es fehlt ein Überblick über die „Ende zu Ende – Journey“ des Kunden.
Eine neue Software, die die Potenziale der Digitalisierung voll ausschöpfen soll, muss jedoch die Prozesse und Abläufe ganzheitlich betrachten, um die größtmögliche Wertschöpfung zu erzielen.
Erfolgsfaktoren bei der Einführung neuer digitaler Lösungen
Die Herausforderungen und Rahmenbedingungen jeder Organisation sind anders und demnach unterscheidet sich auch „das beste“ Vorgehen zur Einführung neuer digitaler Lösungen. Die nachfolgenden Erfolgsfaktoren können aber als Grundlage fungieren, um ein passendes Vorgehen zu finden.
Aktives Stakeholder Management gegen Silodenken und für mehr Commitment
Ein großer Bestandteil bei der Entwicklung und Einführung neuer digitaler Lösungen ist die Arbeit mit verschiedenen Individuen. Es ist daher entscheidend, so frühzeitig wie möglich die wichtigsten Stakeholder, mit ihren Bedürfnisse und Zielen, zu identifizieren und in die Produktentwicklung einzubeziehen. Frameworks wie das Power-Interest-Grid bieten sich hier an. Oft können schon früh erste Zielkonflikte aufgezeigt und thematisiert werden.
Um als Product Owner die Bot:innenrolle, die es keinem Recht machen kann, zwischen den Abteilungen zu verlassen, können Stakeholder Communities aufgebaut werden, bei denen alle Betroffenen für wichtige Entscheidungen am selben Tisch sitzen. Workshops, um z. B. eine neue, übergreifende User Journey zu besprechen, können dabei helfen, abteilungsübergreifendes Denken und das gegenseitige Verständnis zu fördern und das Commitment in die gemeinsam erarbeitete Lösung zu steigern. Weitere hilfreiche Tipps im Umgang mit Stakeholdern finden sich beispielsweise bei Roman Pichler.
Um Konflikte zwischen einzelnen Abteilungen aufzulösen, können auch Retrospektiven durchgeführt werden, um eine neue Grundlage für die gemeinsame Zusammenarbeit zu legen. Allerdings kann auch – je nach Art des Konflikts – ein Eingreifen der Führungsebene notwendig sein, insbesondere wenn es um Grundsatzentscheidungen geht.
Iteratives und inkrementelles Vorgehen, um Widerstände aufzulösen
Direktes Feedback aus produktiver Nutzung ist ungemein wertvoll, um Produkte zu entwickeln, die die Probleme und Bedürfnisse der Nutzer:innen wirklich adressieren. Wenn man in kurzen Zyklen arbeitet und sich regelmäßig zu Inkrementen Feedback einholt, können die Feinheiten noch sehr genau abgestimmt und Fehlentwicklungen minimiert werden.
Oft sind die Zwischenschritte nicht leicht zu erkennen – aber es gibt sie. Nehmen wir das Beispiel eines automatisch generierten OP-Terminvorschlags. Um diesen zu erhalten, müssen sehr viele Prozesse ineinandergreifen: medizinische Rahmenbedingungen (z. B. Verfügbarkeit des Arztes, Eingriff, Gelenk, OP-Saal), organisatorische Parameter (z. B. Versicherung), Bettenverfügbarkeit (z. B. Verfügbarkeit, Geschlecht) und die Anschlussheilbehandlung (z. B. Einrichtung, Dauer). Auf den ersten Blick erscheint es nicht sinnvoll, einen halbgaren OP-Terminvorschlag zu generieren. Bei genauerem Hinschauen sieht man, dass man aber durchaus z. B. einen medizinisch korrekten Vorschlag generieren kann, den man mit Fachwissen und den bestehenden Prozessen (z. B. einer Excelliste für die Bettenplanung) anreichern kann.
Der Vorteil, den medizinisch korrekten Vorschlag bereits produktiv zu nutzen, ist neben der graduellen Ablösung Altsystemen und der Identifikation weiterer relevanter Faktoren, auch das gesteigerte Vertrauen, das über die Zeit entsteht, je öfter man das neue System verwendet. Ebenso kann die Motivation der Nutzer:innen gesteigert werden, indem man ihnen durch Änderungen im System zeigt, dass ihr Feedback wirklich berücksichtigt wird.
Darüber hinaus ist Feedback zu Software, die weder produktiv noch in der echten Bedarfssituation genutzt wird, oftmals sehr oberflächlich und nicht vergleichbar mit dem Feedback, das während der echten Nutzung im Alltag entsteht. Das kommt beispielsweise dadurch zustande, dass man weniger Zeit investiert und nur schnell „drüber schaut“, sodass man das System nicht tief genug hinterfragt. Ebenso wird die Integration zu angrenzenden Prozessen oft vergessen und Kleinigkeiten, die das Produkt aber erst richtig rund machen, sowie seltene Fälle, zeigen sich erst im Laufe der Zeit. Daher entsteht qualitativ hochwertiges Feedback erst mit der echten, produktiven Nutzung im Alltag.
Weitere Taktiken, um Ängste vor einer neuen Lösung zu nehmen, sind das Einbauen von manuellen Eingriffsmöglichkeiten bei automatisierten Systemen (Gefühl von Kontrolle) und das Aufgreifen visueller Elemente aus den Altsystemen (Gefühl von Vertrautheit).
Top-Down and Bottom-Up für mehr Zeit und Unterstützung
Je nach Einsatzgebiet kann eine neue Software viele organisatorische Änderungen nach sich ziehen. Beispielsweise können Aufgaben- und Verantwortungsbereiche verschoben oder bestehende Teamkonstellationen aufgehoben werden.
Um eine Veränderung nachhaltig zu implementieren, Widerstand aufzulösen und Verständnis zu schaffen, bedarf es eines klaren Mandats der Bereichsleitung oder Geschäftsführung. Diese muss das Digitalisierungsvorhaben tatkräftig unterstützen, idealerweise mitgestalten, und die entsprechenden Stellen (z. B. den Product Owner oder ein dediziertes Team, siehe unten) enabeln, entsprechende Maßnahmen umzusetzen. Die Unterstützung der Führungsebene ist für viele auch ein richtungsweisendes Signal, ohne das sich Veränderung schnell chaotisch anfühlen kann. Ebenso ist ein explizites Mandat notwendig, um sehr tief verankerte Muster überhaupt aufbrechen zu können. Ebenso können Argumente wie „ich habe keine Zeit“ schnell ausgeräumt werden, indem die dedizierte Zeit für die Gestaltung neuer Abläufe geschaffen wird.
Genauso wichtig ist es, gleichzeitig Unterstützung innerhalb der Organisation zu gewinnen. Damit Veränderungsvorhaben skalieren, muss die breite Masse abgeholt werden. Ein großer Trägheitsmoment lässt Veränderungsvorhaben besonders zu Beginn sehr zäh anlaufen. Je mehr Verbündete man für sich gewinnen kann, desto leichter lässt sich der Stein ins Rollen bringen. Ebenso gewinnen Veränderungsinitiativen drastisch an Authentizität, wenn die eigenen Kolleg:innen überzeugt sind. So können auch Vorbehalte und Widerstände auf natürliche Weise abgebaut werden – oft reichen schon ganz informelle Gespräche an der Kaffeemaschine.
Koordination der Initiativen für einen nachhaltigen Erfolg
Je nachdem, wie tiefgreifend die Veränderung in der Organisation ist (z. B. gänzlich neue Endnutzer:innen-Journey), die durch eine neue Software angeregt wird, sollte die Einführung geplant und koordiniert werden. Eine gute Planung beinhaltet mitunter ein klares Mandat und Verantwortlichkeiten (z. B. in Form eines Teams), eine klare Zielsetzung und fokussierte Initiativen (nicht zu viele parallele Handlungsstränge). Hier können Ideen und Frameworks aus dem Change Management aufgegriffen werden, z. B. von Frederik Laloux oder John Kotter. Wichtig ist es, schnell kleine Erfolge mit möglichst großem Nutzen zu erzielen, um das Vertrauen in die neue Stoßrichtung zu steigern.
Fazit
Eine neue, digitale Lösung bietet oftmals die Chance, eine Organisation mit ihren Strukturen, Prozessen und Denkmustern neu zu denken und sich für die Zukunft kompetitiv aufzustellen.
Allerdings verläuft ihre Einführung oft nicht geradlinig. Um eine Software und die daraus resultierende Veränderung nachhaltig zu implementieren, bedarf es Zeit und einem strukturierten Vorgehen. Alte Gewohnheiten und Denkmuster müssen abgelegt und neue Abläufe sowie Strukturen müssen definiert, gelebt und wieder angepasst werden. Insbesondere die Änderung nicht offensichtlicher Faktoren (z. B. veränderter Umgang miteinander, ganzheitliches Denken) muss kontinuierlich und mit Feingefühl vorangetrieben werden.
Zusammengefasst bedeutet das, dass Softwareentwicklung und Organisation in stetiger Wechselwirkung zueinander stehen, sodass der nachhaltige Erfolg einer digitalen Lösung nur gewährleistet werden kann, wenn beide Bestandteile nahtlos ineinander greifen.
