Digitalprojekte gelingen an der Schnittstelle zwischen Fachbereich und IT

Wenn zwei Welten aneinander vorbeiplanen

Die meisten Digitalprojekte starten mit einem klaren Ziel. Ein Prozess soll schneller werden. Eine manuelle Arbeit soll wegfallen. Eine Schnittstelle zwischen zwei Systemen soll endlich funktionieren. Das Ziel ist greifbar – doch irgendwo zwischen erster Anforderung und fertiger Lösung geht etwas verloren.

In der Praxis zeigt sich ein wiederkehrendes Muster: Fachbereiche formulieren, was sie brauchen. Die IT oder ein externer Dienstleister setzt um. Und am Ende passt das Ergebnis nicht ganz – weil wichtige Details fehlten, weil Anforderungen falsch interpretiert wurden, oder weil sich die Realität im Betrieb schon längst weiterentwickelt hatte, während das Projekt noch lief.

Dieses Muster hat einen Namen: die Lücke zwischen Fachbereich und IT. Und sie ist einer der häufigsten Gründe, warum Digitalprojekte teurer, langsamer oder weniger wirksam werden als geplant.

Was jede Seite weiss – und die andere nicht

Fachbereiche tragen ein Wissen in sich, das sich selten vollständig dokumentieren lässt. Sie kennen die Abläufe, die ungeschriebenen Regeln, die Ausnahmen, die im Tagesgeschäft auftreten. Sie wissen, warum ein Prozess so gewachsen ist, wie er heute ist – und welche Anforderungen eine neue Lösung zwingend erfüllen muss.

IT-Teams und Entwickler bringen eine andere, ebenso unersetzliche Perspektive mit. Sie wissen, wo Systemgrenzen liegen, wie Daten strukturiert sein müssen, damit sie verarbeitbar sind, und was technisch realistisch ist – in einem gegebenen Budget, mit einer gegebenen Infrastruktur und in einem gegebenen Zeitrahmen.

Beide Perspektiven sind notwendig. Keine ist vollständig ohne die andere. Und trotzdem werden sie in vielen Projekten erst spät zusammengeführt.

Die Strukturfalle: nacheinander statt miteinander

Das eigentliche Problem ist selten mangelnder Wille zur Zusammenarbeit. Es ist die Art, wie Projekte strukturell aufgesetzt werden.

Ein klassisches Muster sieht so aus: Der Fachbereich erstellt ein Anforderungsdokument. Es wird an die IT oder einen externen Partner übergeben. Dieser entwickelt eine Lösung. Feedback kommt in einer späten Phase – wenn Änderungen bereits aufwendig und kostspielig sind.

Dieses sequenzielle Vorgehen hat historische Wurzeln und funktioniert in stabilen, gut dokumentierten Umgebungen passabel. In der Realität moderner Unternehmen – mit wechselnden Anforderungen, knappen Kapazitäten und hybriden Systemlandschaften – führt es regelmässig zu Reibungsverlusten.

Was stattdessen funktioniert, ist gemeinsame Verantwortung von Beginn an. Nicht ein Briefing, das weitergereicht wird, sondern ein gemeinsamer Rahmen: Wer entscheidet was? Was ist ein Must-have, was ein Nice-to-have? Welche Prozessschritte sind bereits klar – und wo braucht es zuerst mehr Klarheit, bevor überhaupt technisch gedacht werden kann?

Anforderungen sind keine Spezifikationen

Ein häufiges Missverständnis: Anforderungen und Spezifikationen werden gleichgesetzt. Der Fachbereich beschreibt, was er will – und erwartet, dass daraus direkt eine technische Umsetzung entsteht.

In der Realität sind Anforderungen ein Ausgangspunkt, keine Blaupause. Sie müssen hinterfragt, konkretisiert und auf technische Machbarkeit geprüft werden. Aus «wir wollen einen automatischen Bericht jeden Montagmorgen» wird erst dann eine sinnvolle Spezifikation, wenn klar ist: Welche Daten? Aus welchen Quellen? In welchem Format? Für wen? Unter welchen Bedingungen?

Diese Konkretisierung braucht beide Seiten am Tisch. Und sie braucht Zeit – die häufig nicht eingeplant wird, weil sie unsichtbar ist. Sie erscheint nicht im Projektplan, produziert kein sichtbares Deliverable und wird deswegen oft übersprungen.

Das Ergebnis: Entwicklungen starten auf unsicherer Grundlage. Anpassungen häufen sich. Das Projekt verlängert sich.

Drei Stellen, an denen Projekte kippen

Es gibt erkennbare Muster, wo die Zusammenarbeit zwischen Fachbereich und IT besonders anfällig ist.

Projektstart ohne gemeinsames Verständnis

Wenn ein Projekt startet, ohne dass beide Seiten ein gemeinsames Bild vom Ziel haben, entstehen parallele Vorstellungen. Der Fachbereich denkt in Prozessen und Nutzererfahrungen, die IT denkt in Systemen und Datenpfaden. Beides ist richtig – aber ohne bewusste Synchronisation führen beide Denkweisen zu unterschiedlichen Lösungsideen.

Ein gemeinsamer Workshop zu Projektbeginn – nicht als Formalität, sondern als echte Arbeitsgrundlage – kann diesen Abstand erheblich verringern.

Scope-Creep durch unklare Entscheidungshoheit

Wenn während eines Projekts unklar ist, wer Entscheidungen trifft, neigen Projekte dazu, zu wachsen. Neue Anforderungen werden ergänzt. Bestehende Anforderungen werden revidiert. Jede Änderung kostet Zeit – und häufig fehlt die Konsequenz, dass auch Umfang oder Zeitplan angepasst werden.

Klare Verantwortlichkeiten schützen Projekte vor diesem Muster. Nicht Bürokratie – sondern Klarheit darüber, wer «Ja» und «Nein» sagen darf.

Übergaben ohne Wissenstransfer

Wenn ein Projekt abgeschlossen wird und das Wissen darüber, wie die Lösung funktioniert, nur bei den Entwicklern liegt, entsteht eine neue Abhängigkeit. Der Fachbereich kann die Lösung nicht eigenständig betreiben, anpassen oder weiterentwickeln.

Ein bewusster Wissenstransfer am Projektende – Dokumentation, Schulung, Übergabegespräche – ist kein Luxus, sondern Voraussetzung für eine Lösung, die im Betrieb wirklich funktioniert.

Was eine gute Projektbegleitung leistet

Eine externe Begleitung kann diese Lücke nicht schliessen – das ist Aufgabe des Unternehmens selbst. Was sie leisten kann: die Strukturen schaffen, in denen Fachbereich und IT gemeinsam arbeiten können.

Bei Sergenta Group bedeutet das in der Praxis: Wir starten kein Entwicklungsprojekt, ohne den Prozess dahinter zu verstehen. Wir stellen die Fragen, die vor dem ersten Code-Block beantwortet sein müssen. Und wir sorgen dafür, dass Anforderungen nicht nur dokumentiert, sondern gemeinsam verstanden werden – von allen Beteiligten.

Das ist keine Methode. Es ist eine Haltung gegenüber Projekten: dass Technik immer im Dienst eines Zwecks steht – und dieser Zweck von Menschen definiert wird, die den Betrieb kennen.

Fazit

Digitalprojekte scheitern selten an der Technologie. Sie scheitern an den Strukturen, in denen sie entstehen. Wer Fachbereich und IT von Anfang an gemeinsam arbeiten lässt, gemeinsame Verantwortung definiert und Anforderungen konsequent konkretisiert, schafft die Grundlage für Projekte, die halten – im Budget, im Zeitplan und im Betrieb.