Wie bauen Sie digitale Strukturen auf, wenn 60% der Abläufe noch per Zuruf laufen?

Wenn ein grosser Teil der betrieblichen Abläufe per Zuruf funktioniert, fehlt nicht unbedingt die passende Software. Häufig fehlen verbindliche Antworten auf einfache Fragen: Wer darf Kundendaten verändern? Wer entscheidet über neue Prozesse? Wo wird eine Vereinbarung dokumentiert? Und wer übernimmt, wenn die zuständige Person abwesend ist?

Solange wenige Mitarbeitende eng zusammenarbeiten, können informelle Absprachen erstaunlich effizient sein. Mit zusätzlichen Teams, Standorten und digitalen Anwendungen wächst jedoch die Zahl der Schnittstellen. Informationen werden mehrfach erfasst, Entscheidungen unterschiedlich interpretiert und wichtige Aufgaben bleiben an einzelne Personen gebunden.

Digitale Strukturen entstehen deshalb durch klare Verantwortlichkeiten, nachvollziehbare Entscheidungen und gemeinsame Informationsregeln. Erst danach entfalten CRM-Systeme, Kollaborationsplattformen und automatisierte Workflows ihren Nutzen.

Für Schweizer KMU mit mehreren Fachbereichen ist ein schrittweises Vorgehen besonders praktikabel: zunächst kritische Zuständigkeiten sichtbar machen, anschliessend wenige verbindliche Regeln festlegen und diese direkt in den verwendeten Systemen abbilden. So wird aus einer informellen Zusammenarbeit eine Organisation, die auch bei Wachstum handlungsfähig bleibt.

Warum digitale Strukturen scheitern, wenn Zuständigkeiten nicht auf 1 Seite klar sind

Digitale Strukturen scheitern häufig an unklaren Zuständigkeiten, weil Software bestehende Abstimmungen nicht automatisch in verbindliche Entscheidungen verwandelt. Eine einseitige Verantwortlichkeitsübersicht zwingt die Beteiligten, festzulegen, wer Aufgaben ausführt, wer entscheidet und wer informiert werden muss. Lassen sich diese Fragen nicht beantworten, ist die Organisation noch nicht ausreichend geklärt.

In einer kleinen Abteilung reicht oftmals ein kurzes Gespräch, um eine Kundenanfrage weiterzugeben. Sobald Verkauf, Marketing und Kundendienst beteiligt sind, funktioniert derselbe Mechanismus nicht mehr zuverlässig. Jede Abteilung kennt möglicherweise ihren eigenen Ablauf, aber niemand überblickt die gesamte Bearbeitung.

Das Problem liegt nicht zwingend in fehlender Eigeninitiative. Gerade selbstständig arbeitende Fachbereiche können organisatorische Lücken lange überbrücken. Schwierigkeiten werden erst sichtbar, wenn mehrere Abteilungen dasselbe CRM nutzen, gemeinsame Daten benötigen oder eine zentrale Dienstleistung eingeführt wird.

Ein Organigramm beantwortet diese Fragen nur teilweise. Es zeigt hierarchische Beziehungen, aber nicht unbedingt, wer über eine Änderung an der Kundendatenbank entscheiden darf.

Der Zuständigkeits-Test verlangt für jeden kritischen Prozess drei eindeutige Antworten:

• Wer führt die konkrete Aufgabe aus?
• Wer trifft bei widersprüchlichen Anforderungen die verbindliche Entscheidung?
• Wer benötigt die Information, damit die anschliessende Arbeit funktioniert?

Ergänzend sollte feststehen, wer bei Abwesenheit übernimmt. Sind diese Angaben für alle Beteiligten ohne Rückfrage auffindbar, besteht eine tragfähige Grundlage für die Digitalisierung.

Die Beschränkung auf eine Seite ist dabei keine wissenschaftlich belegte Erfolgsformel, sondern eine praktische Verständlichkeitsprüfung. Wenn eine Übersicht immer umfangreicher wird, lohnt es sich zu prüfen, ob Zuständigkeiten tatsächlich entschieden oder lediglich ausführlich beschrieben wurden.

Als methodische Grundlage kann die Microsoft-Dokumentation zur Definition von Rollen und Verantwortlichkeiten dienen. Sie beschreibt unter anderem die RACI-Methode und die Bedeutung einer eindeutigen Letztverantwortung.

Besonders teuer wird Unklarheit, wenn sie keine offenen Konflikte verursacht. Zwei Teams können unabhängig voneinander Kontaktlisten, Freigabewege oder Berichte entwickeln. Die zusätzlichen Arbeitsstunden erscheinen dann als normale Fachbereichskosten, nicht als Folge einer unzureichenden digitalen Organisation.

Die Übersicht muss nicht jeden Sonderfall lösen. Sie sollte zunächst die wichtigsten wiederkehrenden Abläufe verbindlich regeln. Daraus lassen sich konkrete digitale Arbeitsregeln ableiten, die Mitarbeitende tatsächlich anwenden können.

Wie Sie 10 Digital-Regeln erstellen, die Mitarbeitende wirklich einhalten

Zehn wirksame Digitalregeln entstehen nicht durch möglichst viele Verbote, sondern durch klare Entscheidungen für typische Arbeitssituationen. Jede Regel sollte beschreiben, welche Handlung erwartet wird, welches System dafür vorgesehen ist und an wen sich Mitarbeitende bei Ausnahmen wenden. Beginnen Sie mit den risikoreichsten Situationen und entwickeln Sie die Regeln gemeinsam mit den betroffenen Teams.

Eine Regel wie «Private Cloud-Speicher sind verboten» lässt entscheidende Fragen offen: Wo sollen Dateien stattdessen abgelegt werden? Was passiert, wenn der vorgesehene Speicher nicht erreichbar ist? Wer entscheidet über eine Ausnahme?

Praktikabler ist eine Formulierung wie: «Kundendokumente werden im freigegebenen Dokumentensystem gespeichert. Ist dies nicht möglich, entscheidet die zuständige IT- oder Datenschutzrolle über das weitere Vorgehen.»

Die Zahl zehn ist eine selbst gewählte Obergrenze für Übersichtlichkeit, keine rechtliche oder wissenschaftlich festgelegte Grenze. Ein Unternehmen kann mit drei bis fünf Regeln beginnen, die besonders wichtige Risiken abdecken.

Für ein KMU mit gemeinsamem CRM und mehreren Fachbereichen könnte ein erster interner Regelkatalog beispielsweise so aussehen:

1. Kundendaten werden ausschliesslich in freigegebenen Systemen bearbeitet.
2. Für jedes zentrale Datenobjekt ist eine verantwortliche Rolle benannt.
3. Entscheidungen über gemeinsame Prozesse werden am vereinbarten Ort dokumentiert.
4. Neue Software wird vor der Nutzung mit der zuständigen Stelle abgestimmt.
5. Freigaben erfolgen über den festgelegten Workflow.
6. Änderungen an zentralen Stammdaten sind nachvollziehbar.
7. Für kritische Aufgaben existiert eine Stellvertretung.
8. Verbindliche Arbeitsanweisungen stehen in einer gemeinsamen, gepflegten Ablage.
9. Datenschutz- und Sicherheitsvorfälle werden über einen bekannten Meldeweg weitergegeben.
10. Veraltete oder widersprüchliche Regeln werden an eine benannte verantwortliche Rolle gemeldet.

Diese Liste ist ein organisatorisches Beispiel und muss an die tatsächlichen Prozesse und Risiken angepasst werden. Entscheidend ist, dass Mitarbeitende die Regeln im Alltag umsetzen können.

Für Schweizer Unternehmen ist die datenschutzrechtliche Prüfung besonders wichtig. Das revidierte Schweizer Datenschutzgesetz ist seit dem 1. September 2023 in Kraft. Die Informationen des Bundesamts für Justiz zum neuen Datenschutzrecht erläutern die Rechtsentwicklung. Daraus folgt allerdings keine Pflicht, genau zehn interne Digitalregeln einzuführen.

Die Regeln sollten deshalb nicht erst nach ihrer Veröffentlichung auf mögliche Datenschutzprobleme geprüft werden. Bei Kundendaten, Cloud-Diensten und Zugriffsrechten gehört diese Prüfung bereits zur Formulierung.

Für die Einführung eignet sich ein kurzer bereichsübergreifender Workshop. Vertreter aus Verkauf, Administration und IT formulieren jede Regel in eigenen Worten, prüfen typische Ausnahmefälle und benennen einen Ansprechpartner. Wenn unterschiedliche Interpretationen auftauchen, muss die Regel überarbeitet werden.

Eine Einhaltung lässt sich anschliessend anhand konkreter Arbeitsproben beurteilen: Können Mitarbeitende den freigegebenen Speicherort zeigen? Kennen sie den Meldeweg? Finden sie die gültige Fassung einer Arbeitsanweisung?

Damit die Regeln verbindlich bleiben, braucht jede Regel eine verantwortliche Rolle und einen Anlass zur Überprüfung. Besonders bei gemeinsam genutzten Systemen führt das unmittelbar zur Frage, wer Aufgaben übernimmt und wer Entscheidungen treffen darf.

RACI oder RAPID: Welche Methode passt bei 3 Abteilungen und 1 gemeinsamem CRM?

Bei drei Abteilungen und einem gemeinsamen CRM ist RACI sinnvoll, um Aufgaben und Verantwortlichkeiten zuzuordnen. RAPID eignet sich ergänzend für Entscheidungen, bei denen mehrere Bereiche unterschiedliche Interessen vertreten. Entscheidend ist nicht die Unternehmensgrösse, sondern die Art der Unklarheit: Geht es um die tägliche Datenpflege oder darum, wer verbindliche Änderungen beschliessen darf?

RACI unterscheidet vier Rollen: Responsible für die Ausführung, Accountable für die Letztverantwortung, Consulted für fachliche Rückmeldungen und Informed für die Informationsweitergabe.

RAPID konzentriert sich dagegen auf Entscheidungsrechte. Das von Bain & Company entwickelte Modell unterscheidet Recommend, Agree, Perform, Input und Decide. Die Rollen beschreiben, wer einen Vorschlag erarbeitet, unter bestimmten Bedingungen zustimmen muss, die Entscheidung umsetzt, Informationen liefert und abschliessend entscheidet.

Der Bain-Fachartikel zum Veränderungsmanagement und zur RAPID-Methode erläutert die Bedeutung ausdrücklich zugewiesener Entscheidungsrechte. Das ist eine Darstellung des Methodenentwicklers und kein unabhängiger Nachweis, dass RAPID anderen Verfahren grundsätzlich überlegen ist.

Für die Auswahl hilft ein Vergleich der beiden Ansätze:

Bei nur drei Fachbereichen braucht es nicht zwingend eine umfangreiche Matrix. Für jedes zentrale CRM-Objekt kann eine kompakte Zuständigkeitszeile genügen.

Ein mögliches, ausdrücklich hypothetisches Beispiel: Marketing erfasst einen Lead, Verkauf verantwortet dessen kommerzielle Qualifizierung, und der Kundendienst pflegt die anschliessenden Servicevorgänge. Wer die Definition eines qualifizierten Leads ändern darf, wird separat als Entscheidungskompetenz festgelegt.

Die organisatorische Zuordnung muss im CRM wiederzufinden sein. Dazu können Datensatzverantwortliche, Berechtigungen, Freigaben und Eskalationswege gehören. Welche Funktionen technisch verfügbar sind, hängt vom jeweiligen System ab.

Andernfalls entsteht ein Widerspruch: Auf dem Papier entscheidet eine benannte Rolle, während im System weiterhin beliebige Mitarbeitende Änderungen vornehmen können.

Eine kurze Kontrolle nach der Einführung zeigt, ob die Methode funktioniert. Prüfen Sie anhand einer tatsächlichen Prozessänderung, wer den Vorschlag eingebracht hat, wer entscheiden durfte und ob die Änderung für alle betroffenen Teams sichtbar wurde.

Beide Methoden sollten nur so detailliert eingesetzt werden, wie es die Zusammenarbeit erfordert. Werden Zuständigkeiten im System nicht gepflegt, entstehen schnell parallele Listen und inoffizielle Lösungen ausserhalb der vorgesehenen Struktur.

Die stille Schatten-IT: 5 Warnsignale, dass Ihre Struktur bereits ausfranst

Schatten-IT wird zum organisatorischen Warnsignal, wenn Teams Daten und Arbeitsabläufe in Anwendungen verwalten, die ausserhalb der vereinbarten IT-Governance liegen. Besonders kritisch sind doppelte Datenbestände, personengebundene Prozesse, informelle Einarbeitung, eigenständig beschaffte Tools und nicht nachvollziehbare Entscheidungen. Eine strukturierte Bestandsaufnahme hilft, Risiken von berechtigten praktischen Bedürfnissen zu unterscheiden.

In einem Unternehmen mit ausgeprägter Eigeninitiative kann Schatten-IT aus dem Wunsch entstehen, ein konkretes Problem rasch zu lösen. Ein Team erstellt eine zusätzliche Tabelle, weil das CRM eine bestimmte Information nicht übersichtlich darstellt. Eine andere Abteilung verwendet ein eigenes Projektwerkzeug, weil Freigaben zu lange dauern.

Solche Lösungen können zunächst nützlich sein. Problematisch werden sie, wenn niemand mehr weiss, welche Anwendungen tatsächlich verwendet werden und welcher Datenbestand verbindlich ist. Dass dies in Schweizer KMU besonders häufig vorkommt, lässt sich aus den vorliegenden Quellen allerdings nicht statistisch belegen.

Fünf Warnsignale verdienen besondere Aufmerksamkeit:

• Doppelte Daten: Kundeninformationen werden in mehreren privaten Tabellen oder voneinander unabhängigen Anwendungen gepflegt.
• Abhängigkeit von Einzelpersonen: Ein kritischer Ablauf funktioniert nur, solange eine bestimmte Person verfügbar ist.
• Einarbeitung per Zuruf: Neue Mitarbeitende erhalten mündliche Erklärungen, weil keine verlässliche Prozessbeschreibung existiert.
• Unkoordinierte Softwarebeschaffung: Fachbereiche führen Anwendungen ein, ohne Verantwortliche für IT, Datenschutz oder Informationssicherheit einzubeziehen.
• Widersprüchliche Entscheidungen: Vereinbarungen werden später unterschiedlich wiedergegeben, weil ein verbindlicher Entscheidungsverlauf fehlt.

Ein einzelnes Signal beweist noch kein schwerwiegendes Sicherheitsproblem. Mehrere gleichzeitig auftretende Signale weisen jedoch darauf hin, dass die dokumentierte Organisation nicht mehr mit der tatsächlichen Arbeitsweise übereinstimmt.

Statt alle nicht freigegebenen Anwendungen pauschal zu verbieten, sollte zunächst geklärt werden, warum sie eingesetzt werden. Eine Bestandsaufnahme erfasst die tatsächlich verwendeten Tools, bearbeiteten Datenarten, verantwortlichen Personen und offenen Risiken.

Für jede Anwendung stehen anschliessend drei mögliche Wege zur Verfügung: kontrolliert übernehmen, in die bestehende Systemlandschaft integrieren oder geordnet stilllegen. Die Entscheidung sollte sowohl den geschäftlichen Nutzen als auch Datenschutz, Sicherheit, Kosten und technische Abhängigkeiten berücksichtigen.

Beim Cloud-Einsatz bleiben Unternehmen für die rechtmässige Bearbeitung von Personendaten verantwortlich, auch wenn externe Dienstleister eingesetzt werden. Die EDÖB-Informationen zur Datenbearbeitung in der Cloud erläutern unter anderem Fragen der Auftragsbearbeitung und der gesetzlichen Anforderungen. Private Cloud-Dienste sind dabei nicht ausnahmslos verboten; entscheidend ist die konkrete datenschutzrechtliche Beurteilung.

Wichtig ist, dass eine Inventur nicht als Suche nach schuldigen Mitarbeitenden wahrgenommen wird. Wer eine inoffizielle Anwendung nutzt, kann damit auf eine tatsächliche Lücke im bestehenden Prozess aufmerksam machen.

Eine dauerhafte Lösung entsteht erst, wenn die betroffenen Prozesse, Entscheidungen und Verantwortlichkeiten verbessert werden. Damit stellt sich die nächste Frage: Wie viel Prozessklärung braucht es, bevor eine neue Software sinnvoll eingeführt werden kann?

Wann sollten Sie erst Prozesse klären und erst dann Tools ausrollen?

Prozesse sollten vor der Einführung eines Tools so weit geklärt sein, dass Verantwortlichkeiten, grundlegende Entscheidungen und kritische Freigaben feststehen. Eine vollständige Beschreibung aller Sonderfälle ist dagegen nicht immer erforderlich. Bei begrenzter Unsicherheit kann ein kontrollierter Pilot helfen, offene Prozessfragen anhand der tatsächlichen Nutzung zu entscheiden.

Die verbreitete Gegenüberstellung «erst alles dokumentieren, dann digitalisieren» oder «erst Software kaufen, dann organisieren» greift zu kurz. Unterschiedliche Prozessfragen verlangen unterschiedliche Zeitpunkte für ihre Klärung.

Vor dem Start müssen insbesondere jene Entscheidungen feststehen, die das System technisch abbilden soll. Dazu gehören die Verantwortung für Datenobjekte, Berechtigungen, verbindliche Freigaben und die Behandlung von Konflikten zwischen Abteilungen.

Andere Einzelheiten können während einer Pilotphase konkretisiert werden. Beispielsweise zeigt erst die tatsächliche CRM-Nutzung, ob ein zusätzliches Eingabefeld hilfreich ist oder nur administrativen Aufwand erzeugt.

Für die Entscheidung eignet sich folgende Unterscheidung:

Ein Tool kann die Prozessklärung durchaus beschleunigen. Das funktioniert besonders dann, wenn eine verantwortliche Projektleitung Entscheidungen herbeiführen kann, der Pilot auf einen überschaubaren Bereich begrenzt ist und Änderungen kontrolliert dokumentiert werden.

Ohne diese Voraussetzungen droht das Gegenteil: Die Software wird eingerichtet, obwohl Verkauf und Kundendienst weiterhin unterschiedliche Vorstellungen von einem abgeschlossenen Kundenfall haben.

Ein klar begrenzter Klärungszeitraum verhindert gleichzeitig, dass das Projekt in immer neuen Prozessworkshops stecken bleibt. Statt jede Ausnahme vorwegzunehmen, werden offene Fragen nach ihrer Auswirkung priorisiert.

Ein praktikables internes Startkriterium lautet: Für jede geschäftskritische Prozessfrage gibt es eine benannte Person, die eine verbindliche Antwort geben kann. Wenn das nicht gelingt, sollte die betreffende Funktion noch nicht unkontrolliert ausgerollt werden.

Eine erfolgreiche Einführung braucht damit weder perfekte Prozesshandbücher noch spontane Technologieentscheidungen. Dieselbe Logik gilt bei der Wahl der Teamstruktur: Auch organisatorische Frameworks sollten zum tatsächlichen Koordinationsbedarf passen.

Spotify-Modell oder klassische Teams: Was passt bei 1 Produkt und 3 Stakeholdern?

Bei einem Produkt und drei Stakeholdern reicht meist ein festes Kernteam mit klaren Verantwortlichkeiten und einem verbindlichen Entscheidungsweg. Das sogenannte Spotify-Modell mit Squads, Chapters und Guilds bietet in dieser Konstellation häufig keinen zusätzlichen organisatorischen Nutzen. Ausschlaggebend sind die Zahl der Abhängigkeiten, die Häufigkeit von Prioritätsänderungen und der tatsächliche Koordinationsbedarf.

Das Spotify-Modell wurde durch die Beschreibung der Arbeitsorganisation des Streamingunternehmens bekannt. Es verbindet kleine, weitgehend selbstständig arbeitende Produktteams mit fachlichen Austauschstrukturen. Daraus lässt sich jedoch keine allgemeine Verpflichtung ableiten, diese Organisationsform in anderen Unternehmen zu übernehmen.

Bei einem einzigen Produkt kann die Einführung mehrerer zusätzlicher Rollen dazu führen, dass dieselben Personen parallel unterschiedliche organisatorische Funktionen ausfüllen. Dann wächst die Zahl der Abstimmungen, ohne dass neue Entscheidungskompetenz entsteht.

Ein klassisches Kernteam ist häufig übersichtlicher. Es benötigt eine verantwortliche Person für die Produktprioritäten, klar benannte Fachverantwortliche und einen gemeinsamen Ort für Anforderungen und Entscheidungen.

Die drei Stakeholder sollten dazu zwei Fragen beantworten:

• Wie häufig ändern sich die Prioritäten tatsächlich, und wie viele Personen müssen dabei mitentscheiden?
• Welche wiederkehrenden Entscheidungen verursachen heute Wartezeiten oder widersprüchliche Erwartungen?

Eine praktische Übung besteht darin, alle regelmässigen Entscheidungsarten zu sammeln. Geht es beispielsweise überwiegend um Funktionsprioritäten, Budgetfreigaben und technische Umsetzung, kann eine kleine Entscheidungsmatrix ausreichen.

Die Orientierung an ungefähr zehn wiederkehrenden Entscheidungstypen ist hier lediglich eine pragmatische Arbeitshilfe und kein empirisch bestätigter Grenzwert. Auch wenige Entscheidungen können komplex sein, wenn sie rechtliche, finanzielle oder technische Risiken betreffen.

Ein stärker ausdifferenziertes Modell kann sinnvoll werden, wenn mehrere eigenständige Produktbereiche, zahlreiche Abhängigkeiten oder dauerhaft spezialisierte Teams entstehen. Entscheidend ist dann nicht der Bekanntheitsgrad des Frameworks, sondern sein konkreter Nutzen.

Je grösser ein Unternehmen wird, desto wichtiger wird zusätzlich die Frage, welche Dienstleistungen zentral erbracht werden sollten und welche Fachbereiche eine direkte Beratung benötigen.

Shared Services oder Business Partner: Was passt bei 300 Mitarbeitenden?

Bei rund 300 Mitarbeitenden eignen sich Shared Services vor allem für häufige, standardisierbare Leistungen wie IT-Support oder administrative Personalprozesse. Business-Partner-Rollen sind sinnvoll, wenn Fachbereiche individuelle Beratung und ein tiefes Verständnis ihres Geschäftskontexts benötigen. Die Entscheidung sollte für jede Funktion anhand von Nachfrage, Komplexität und notwendiger Nähe zum Fachbereich getroffen werden.

Shared Services bündeln wiederkehrende Leistungen. Mitarbeitende richten ihre Anliegen über einen definierten Zugang an eine gemeinsame Servicestelle. Dadurch können Verfahren vereinheitlicht und Zuständigkeiten transparent gestaltet werden.

Business Partner arbeiten näher an einzelnen Fachbereichen. Ihre Aufgabe besteht weniger darin, standardisierte Anfragen abzuarbeiten, sondern komplexe Anforderungen zu verstehen und fachliche Entscheidungen zu begleiten.

Bei einer Organisation mit ungefähr 300 Mitarbeitenden können beide Ansätze gleichzeitig sinnvoll sein. Die Mitarbeiterzahl allein begründet aber weder eine bestimmte Anzahl interner Spezialisten noch die Wirtschaftlichkeit eines Shared-Service-Centers.

Ein häufig unterschätztes Risiko zentraler Dienstleistungen entsteht, wenn Fachbereiche die neue Servicestelle als schwer erreichbar wahrnehmen. Fehlt ein transparenter Anfrageweg, greifen Mitarbeitende wieder auf persönliche Kontakte und informelle Absprachen zurück.

Deshalb gehört zum Aufbau eines Shared Service ein verständlicher Servicekatalog. Er beschreibt, welche Leistungen angeboten werden, wie Anfragen eingereicht werden, wer sie bearbeitet und wie bei dringenden oder ungeklärten Fällen vorzugehen ist.

Für Schweizer Unternehmen können zusätzliche Rahmenbedingungen relevant sein: mehrere Standorte, unterschiedliche Sprachregionen und grenzüberschreitende Beschäftigungsverhältnisse. Welche rechtlichen und administrativen Anforderungen daraus entstehen, muss für die jeweilige Situation gesondert geprüft werden.

Eine zentrale HR-Administration kann beispielsweise für standardisierte interne Vorgänge geeignet sein, während Fragen zu Beschäftigungsverhältnissen mit Auslandsbezug zusätzliche Fachkompetenz erfordern.

Vor einer Reorganisation empfiehlt sich die Auswertung realer Anfragen. Welche Anliegen treten wiederholt auf? Welche benötigen Spezialwissen? Welche werden heute direkt an Einzelpersonen gerichtet? Auf dieser Grundlage lässt sich eine sinnvolle Aufgabenverteilung entwerfen.

Unabhängig vom gewählten Modell braucht die Organisation klare Übergaben zwischen den Bereichen. Werden diese Schnittstellen mit zu vielen regelmässigen Besprechungen verwaltet, entsteht jedoch eine neue Form unnötiger Koordination.

Warum agile Organisationsstrukturen bei 4 Teams oft mehr Meetings erzeugen als Output

Agile Organisationsstrukturen können bei vier Teams unnötigen Meetingaufwand erzeugen, wenn Rituale unabhängig vom tatsächlichen Abstimmungsbedarf eingeführt werden. Daily Meetings, Reviews, Retrospektiven und Planungsrunden sind keine Selbstzwecke. Entscheidend ist, ob sie konkrete Hindernisse beseitigen, Prioritäten klären oder Entscheidungen ermöglichen, die ohne gemeinsame Besprechung nicht zuverlässig zustande kämen.

Agile Methoden helfen insbesondere dort, wo sich Anforderungen häufig verändern und mehrere Beteiligte ihre Arbeit eng koordinieren müssen. Bei vier Teams mit weitgehend stabilen Aufgaben kann dieselbe Ritualstruktur jedoch überdimensioniert sein.

Der Aufwand wächst vor allem dann, wenn Statusinformationen mehrfach besprochen werden. Ein Team berichtet intern über seine Fortschritte, anschliessend in einer bereichsübergreifenden Runde und später erneut gegenüber der Leitung.

Das eigentliche Problem ist nicht zwangsläufig die agile Methode. Häufig fehlt eine klar benannte Stelle, die Prioritäten verbindlich festlegt. Dann dienen Meetings dazu, wiederholt über dieselben offenen Fragen zu sprechen.

Ein Meeting sollte einen nachvollziehbaren Zweck erfüllen. Drei Kategorien helfen bei der Bewertung:

• Entscheidungsmeeting: Ein Konflikt, eine Prioritätsänderung oder eine konkrete Freigabe erfordert die gemeinsame Entscheidung.
• Arbeitsmeeting: Beteiligte lösen gemeinsam ein fachliches Problem, das nicht sinnvoll nacheinander bearbeitet werden kann.
• Statusmeeting: Bereits vorliegende Informationen werden hauptsächlich mündlich weitergegeben.

Vor allem die dritte Kategorie bietet Potenzial für asynchrone Zusammenarbeit. Ein gemeinsames Dashboard, eine gepflegte Aufgabenliste oder eine kurze schriftliche Aktualisierung kann den gleichen Informationsbedarf decken, ohne alle Beteiligten gleichzeitig zu binden.

Das bedeutet nicht, sämtliche regelmässigen Meetings abzuschaffen. Eine Retrospektive kann sinnvoll sein, wenn sie wiederkehrende Zusammenarbeitshindernisse aufdeckt. Eine Planungsrunde bleibt nützlich, wenn mehrere Teams ihre Abhängigkeiten tatsächlich gemeinsam festlegen müssen.

Wichtig ist, nicht bloss die Anzahl der Meetings zu zählen. Eine kurze Besprechung, die einen kritischen Konflikt verbindlich löst, kann wertvoller sein als zahlreiche schriftliche Nachrichten ohne Ergebnis.

Als einfache Prüfung können Teamleitungen für jedes wiederkehrende Meeting dokumentieren, welche Entscheidungen, Arbeitsergebnisse oder gelösten Hindernisse daraus hervorgehen. Fehlen solche Ergebnisse über mehrere Durchläufe, sollte Format, Teilnehmerkreis oder Häufigkeit überprüft werden.

Eine schlanke Alternative besteht darin, den gemeinsamen Aufgabenbestand laufend aktuell zu halten und zusätzliche Abstimmungen an konkrete Entscheidungsanlässe zu knüpfen. So bleibt die Organisation anpassungsfähig, ohne jede Anpassung mit einer neuen Regelbesprechung zu begleiten.

Beginnen Sie mit einem konkreten Ablauf, der heute hauptsächlich per Zuruf funktioniert. Dokumentieren Sie seine Verantwortlichkeiten auf einer Seite, bestimmen Sie den verbindlichen Informationsort und überprüfen Sie anschliessend, welche Besprechungen noch notwendig sind. So entsteht eine digitale Struktur durch überprüfbare Veränderungen im Arbeitsalltag statt durch zusätzliche organisatorische Komplexität.