Raus aus dem Silodenken
Wie Projekte wirklich kundenzentriert werden
Die Anwendung läuft. Die Schnittstelle liefert Daten. Das Team hat seine Anforderungen umgesetzt. Und trotzdem müssen die Menschen, die mit der Software arbeiten, Informationen zusammensuchen, Daten doppelt eingeben oder sich mit umständlichen Zwischenlösungen behelfen.
Wie kann das sein? Häufig liegt es daran, dass jedes Projekt seinen eigenen Ausschnitt optimiert. Innerhalb der Projektgrenzen ergibt vieles Sinn. Doch im Arbeitsalltag endet ein Prozess selten dort, wo die Zuständigkeit eines Teams aufhört. Wer Software entwickelt, muss deshalb über diese Grenzen hinausschauen: auf die Menschen, ihre Aufgaben und den gesamten Ablauf, den die Software unterstützen soll.
Der eigene Projekterfolg ist nur ein Teil des Ganzen
Wenn ich in ein neues Projekt komme, möchte ich verstehen: Wer arbeitet mit der Anwendung? Was brauchen die Menschen? Wie funktioniert der Prozess insgesamt? Und welchen Beitrag leistet unser Projekt dazu?
Die technischen Fragen gehören dazu. Aber sie reichen allein nicht aus. Eine Anwendung kann technisch sauber umgesetzt sein und trotzdem an den Bedürfnissen ihrer Nutzer:innen vorbeigehen. Eine Schnittstelle kann genau das liefern, was vereinbart wurde, während im nächsten System entscheidende Informationen fehlen. Jedes Team hat dann möglicherweise seine Aufgabe erfüllt. Der Gesamtprozess bleibt trotzdem holprig.
Kundenzentriert zu arbeiten bedeutet für mich deshalb, den Blick zu weiten. Vom einzelnen System auf den durchgängigen Ablauf. Und vom unmittelbaren Auftraggeber auch auf dessen Kund:innen: Was muss am Ende funktionieren, damit sie gut beraten werden, eine Leistung erhalten oder ihr Anliegen erledigen können?
Dafür braucht es ein gemeinsames Verständnis. Das entsteht, wenn wir die unterschiedlichen Perspektiven zusammenbringen.
Vier Dinge helfen mir dabei besonders:
1. Setz dich neben die Menschen, die mit der Anwendung arbeiten
Wer verstehen will, was eine Anwendung leisten muss, sollte sich anschauen, wie sie tatsächlich genutzt wird. Setz dich neben die Nutzer:innen. Lass dir ihren Arbeitsalltag zeigen. Welche Schritte gehen leicht von der Hand? Wo müssen sie nachfragen, Informationen übertragen oder zwischen Anwendungen wechseln? Was passiert, wenn etwas nicht wie vorgesehen funktioniert?
Gerade die kleinen Umwege sind aufschlussreich. Eine zusätzliche Excel-Liste oder eine handschriftliche Notiz kann zeigen, dass im vorgesehenen Ablauf etwas fehlt.
Die entscheidende Frage lautet: Was möchte dieser Mensch erledigen und was steht ihm dabei im Weg? So wird aus einer abstrakten Anforderung eine konkrete Aufgabe. Und es wird leichter zu beurteilen, welche Änderung im Alltag tatsächlich hilft.
2. Zeichne den Weg durch die Systeme auf
Eine einfache Skizze kann viel sichtbar machen. Wo beginnt der Prozess? Welche Systeme durchläuft er? Wo werden Daten erfasst, weitergegeben oder verändert? Und an welchen Stellen übernehmen Menschen? Dafür braucht es zunächst kein umfassendes Architekturmodell. Ein gemeinsam gezeichneter Ablauf reicht oft aus, um Abhängigkeiten und offene Fragen zu erkennen.
Vielleicht zeigt sich dabei, dass dieselben Informationen mehrfach eingegeben werden. Dass ein notwendiger Schritt zwischen zwei Zuständigkeiten liegt. Oder dass die Beteiligten ganz unterschiedliche Vorstellungen davon haben, wann der Prozess eigentlich abgeschlossen ist.
Eine solche Skizze schafft eine gemeinsame Grundlage für das Gespräch. Sie hilft auch dabei, Entscheidungen im eigenen Projekt einzuordnen: Welche Auswirkungen hat unsere Lösung auf den nächsten Schritt?
3. Hol das Wissen des Fachbereichs dazu
Die Menschen im Fachbereich kennen die Aufgaben, die die Software unterstützen soll. Sie wissen, welche Sonderfälle regelmäßig auftreten, welche Informationen entscheidend sind und welche Folgen ein Fehler im weiteren Ablauf haben kann. Dieses Wissen brauchen wir, um fachlich sinnvolle Lösungen zu entwickeln.
Wer beispielsweise eine Anwendung für den Versicherungsvertrieb baut, sollte verstehen, wie ein Beratungsgespräch abläuft. Welche Informationen benötigt der Vertrieb zu welchem Zeitpunkt? Welche Fragen stellen Kund:innen? Und was muss nach dem Gespräch passieren? Solche Fragen lassen sich nur gemeinsam beantworten. Dafür müssen technische und fachliche Perspektiven auf Augenhöhe zusammenkommen. Dabei lohnt es sich, auch scheinbar Selbstverständliches auszusprechen. Derselbe Begriff kann für verschiedene Beteiligte etwas anderes bedeuten. Wer früh nachfragt, schafft eine bessere Grundlage für die Umsetzung.
4. Sprich mit den Teams der Nachbarsysteme
Die Zusammenarbeit mit benachbarten Projekten ist ein wesentlicher Teil der Projektarbeit. Denn dort werden Entscheidungen getroffen, die den eigenen Ablauf beeinflussen. Gleichzeitig wirken die eigenen Entscheidungen auf diese Teams zurück.
Deshalb sollten wir früh miteinander sprechen: Was brauchen wir voneinander? Welche Annahmen treffen wir? Welche Änderungen stehen an? Und welche Auswirkungen haben sie auf den gemeinsamen Prozess? Dafür hilft eine sachliche, neugierige Haltung. Das andere Team hat eigene Anforderungen und Rahmenbedingungen. Wenn wir diese verstehen, können wir gemeinsam tragfähige Lösungen finden.
Eine gute Arbeitsbeziehung macht es außerdem leichter, Schwierigkeiten direkt anzusprechen. So lassen sich Abhängigkeiten klären, bevor sie im Projektalltag zum Hindernis werden.
Zusammenarbeit als Teil der Lösung
Dieser Blick über die Projektgrenzen kostet Zeit. Gespräche müssen geführt, Abläufe verstanden und unterschiedliche Sichtweisen zusammengebracht werden.
Bleibt das aus, tauchen ungeklärte Abhängigkeiten häufig später wieder auf: als zusätzliche Abstimmung, kurzfristige Korrektur oder Problem im laufenden Betrieb. Dann gerät das Projekt schnell in einen Modus, in dem es vor allem darum geht, das nächste Feuer zu löschen.
Um nach vorne zu arbeiten, brauchen wir ein Team, das über die eigenen Zuständigkeiten hinaus zusammenarbeitet. Menschen mit unterschiedlichen Kompetenzen, die Fragen stellen dürfen, Wissen teilen und gemeinsam auf das Ergebnis schauen.
Für mich beginnt kundenzentrierte Softwareentwicklung deshalb mit einer einfachen Frage:
Funktioniert das, was wir bauen, auch im gesamten Arbeitsalltag unserer Kund:innen?
Wer diese Frage beantworten will, muss den eigenen Projektausschnitt verlassen. Genau dort beginnt der Weg raus aus dem Silodenken.
Über den Autor
Ralph Löwe ist Principal Software Architect bei BettercallPaul. Er begleitet die Modernisierung komplexer Softwarelösungen – von Vertriebsanwendungen bis zu Versicherungssystemen. Als Architekt und Tech Lead verbindet er technische Expertise mit fachlichem Verständnis und bringt Teams über Projektgrenzen hinweg zusammen. Sein Fokus: Lösungen, die den gesamten Prozess unterstützen und den Menschen im Arbeitsalltag helfen.
Hinweis: Das Header- und Zusatzbild dieses Artikels wurden mithilfe Künstlicher Intelligenz erstellt.
