Systeme verändern heißt Arbeit verändern: Teams richtig einbinden

Systeme verändern heißt Arbeit verändern

Drei Monate nach der CRM-Einführung ist technisch alles erledigt. Die Pipeline steht, die Automationen laufen, das Dashboard ist live.

Trotzdem führt der Vertrieb seine Follow-ups wieder in Excel. Im Pflichtfeld „Entscheidungsdatum“ steht bei der Hälfte der Deals der 01.01. Und dem Forecast traut niemand so richtig.

Die schnelle Diagnose lautet: mangelnde Akzeptanz. Doch häufig liegt das eigentliche Problem früher.

Wer Systeme verändert, verändert auch die Art, wie Menschen arbeiten. Und genau das wird in vielen Systemprojekten zu spät berücksichtigt.

Die Herausforderungen

Was sich für das Team tatsächlich ändert

Eine neue Pipeline oder Automation klingt technisch. Für das Team ändert sich aber mehr:

• welche Informationen erfasst werden müssen
• wer wofür verantwortlich ist
• welche Entscheidungen das System künftig selbst trifft
• wer welche Daten sehen kann und wie Leistung sichtbar wird

Erst bauen, dann erklären

Das typische Vorgehen ist: konzipieren, umsetzen, dem Team vorstellen. Dabei fehlt das Wissen derjenigen, die den Prozess täglich ausführen. Dokumentierte und gelebte Prozesse sind selten identisch. Da gibt es die Prüfung vor der Lead-Übergabe, die nirgends steht, oder das Feld, das nie gepflegt wurde, weil es niemand brauchte. Genau daran scheitern später Automationen.

Die Folgen zeigen sich schleichend

Kaum etwas geht beim Go-live sichtbar kaputt. Stattdessen entstehen nach und nach Nebenlisten, übersprungene Felder und Abstimmungen per Messenger. Das Problem ist nicht die einzelne Tabelle, sondern der Verlust einer gemeinsamen Datenlogik. Pflichtfelder helfen nur begrenzt: Sie erzwingen Werte, keine korrekten Daten.

Schlechte Adoption wird zum Datenproblem und das Datenproblem zum Prozessproblem.

Warum mehr Schulung nicht reicht

Wenn mehrere Personen denselben Schritt umgehen, ist das selten Unwille. Häufiger ist der Ablauf zu kompliziert, Informationen fehlen oder ein häufiger Sonderfall wurde übersehen. Wiederkehrende Einwände sind Datenpunkte. Sie zeigen, wo Konzept und Realität nicht zusammenpassen.

Einbeziehen heißt dabei nicht abstimmen. Die entscheidende Frage lautet: Ist das eine echte fachliche Anforderung oder nur ein Workaround des alten Systems? Wer alte Prozesse einfach digitalisiert, automatisiert Umwege. Wer sie ignoriert, baut an der Praxis vorbei.

Die Lösung: Mitarbeitende gezielt einbinden

Dafür braucht es keine wochenlangen Workshops, sondern die richtigen Personen an den richtigen Stellen:

1. Den echten Prozess aufnehmen. Beschreiben, wie der Ablauf heute tatsächlich läuft, inklusive Sonderfällen und Schritten außerhalb des Systems.
2. Key User früh beteiligen. Einige erfahrene Personen prüfen Anforderungen und Praxistauglichkeit und werden später erste Ansprechpartner im Team.
3. Zweck und persönlichen Nutzen erklären. „Drei neue Pflichtfelder“ ist eine Information. „Keine doppelte Eingabe mehr, automatische Wiedervorlage“ ist ein Grund.
4. Transparenz über Auswertungen schaffen. Klar machen, welche Reportings es gibt und wofür sie genutzt werden. Wo Systeme Auswertungen über Verhalten oder Leistung ermöglichen, sollte ein vorhandener Betriebsrat frühzeitig einbezogen und die Mitbestimmung geprüft werden.
5. Im realen Ablauf testen. Nicht nur prüfen, ob die Automation läuft, sondern ob der gesamte Arbeitsablauf für die Person funktioniert, die ihn täglich ausführt.
6. Alte Wege schließen und dranbleiben. Dem Parallelbetrieb ein Enddatum geben, einen System Owner benennen und nach dem Go-live Nutzung und Datenqualität prüfen.

Adoption ist Teil der Systemarchitektur

Ein Prozess, der nur funktioniert, wenn Menschen gegen ihre tatsächliche Arbeitsweise handeln, hat nicht nur ein Kommunikationsproblem. Er hat ein Architekturproblem. Gute Systeme vermeiden doppelte Eingaben und machen den nächsten Schritt eindeutig.

Deshalb betrachten wir im System-Check nicht nur Tools und Schnittstellen, sondern auch die Prozesse dazwischen und die Menschen, die damit arbeiten.

Die beste Systemarchitektur ist nicht die eleganteste auf dem Papier, sondern die, die im Alltag funktioniert.