MIC

Etablierte Firma

Alle Videos anzeigen

Organization for Fast Flow

Gerald Schweizer von MIC beleuchtet in seinem devjobs.at TechTalk die wesentlichen Gedanken, wie und warum die Organisation der Development Teams im Unternehmen verändert worden ist.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In Organization for Fast Flow erklärt Gerald Schweizer (MIC), warum MIC vom klassischen Funktionssilo auf ein Team-Topologies‑Modell umgestellt hat: Stream‑aligned Produkt‑ und Service‑Delivery‑Teams werden durch Platform‑, Enabling‑ und Complicated‑Subsystem‑Teams unterstützt, um kognitive Last zu senken, Übergaben zu minimieren und die Lieferung über ein globales, stark reguliertes Zollsoftware‑Portfolio zu beschleunigen. Anhand seines 24‑köpfigen CAST Germany & Austria Teams zeigt er End‑to‑End‑Verantwortung, zweiwöchige Scrum‑Zyklen, ITIL‑orientierten Support, überwiegend Waterfall‑Tests sowie einen Customer‑Success‑Manager als zentralen Ansprechpartner—Muster, die sich auf komplexe, verteilte Produktorganisationen übertragen lassen.

Organization for Fast Flow bei MIC: Wie eine Wertstrom-Organisation Komplexität reduziert und Liefergeschwindigkeit erhöht

Einordnung der Session

In „Organization for Fast Flow“ von Gerald Schweizer (Speaker) bei MIC (Company) ging es um einen tiefgreifenden Organisationswandel: weg von einer stark funktionsorientierten Struktur hin zu wertstrombasierten, cross-funktionalen Teams. Schweizer leitet den Value Stream für CAST Germany & Austria – das Import- und Export-Verfahren für Deutschland und Österreich – und hat aus der Pilotierung heraus den Übergang zu einer neuen Organisation vorangetrieben. Seine Botschaft: Komplexität lässt sich nicht nur mit Tools und Prozessen beherrschen, sondern vor allem mit klaren Team-Schnitten, reduzierter kognitiver Last und schnellen Feedback-Loops zwischen Entwicklung, Projekten und Support.

Ausgangslage: Produktvielfalt, Länderabdeckung und globale Verteilung

MIC ist seit 1988 stetig gewachsen – personell im Schnitt rund 10 % pro Jahr –, heute mit über 500 Mitarbeitenden an verteilten Standorten weltweit. Das Produktportfolio hat sich über Jahrzehnte stark erweitert:

CAST: Zoll-Anmeldungslösungen (Import/Export) für viele Länder, u. a. Deutschland und Österreich.
CCS: Klassifikation von Teilen und Stammdaten.
OCS: Ursprungsberechnung mit Fokus auf Freihandelsabkommen.
ECM: Exportkontroll-Management für Sanktions- und Geschäftspartnerprüfungen.
Globale Trade-Content-Dienste (Tarifdaten etc.).
Ein Data-Analytics-Produkt zur Auswertung und Visualisierung.
Weitere Module wie GAM und Funktionen für Nacherhebungen/Re-Kalkulationen.

Die Länderabdeckung umfasst 55+ Staaten, mit direkter oder indirekter (Broker-)Kommunikation zu Zollbehörden in zahlreichen Zeitzonen. Dazu kommt die Vielfalt an Verfahren:

Standard Import-/Export-Anmeldungen.
Zolllager (bonded warehouse).
Aktive/Passive Veredelung (Inward/Outward Processing Relief).
Re-Kalkulationen und nachträgliche Korrekturen.

Schweizers Kernpunkt: Diese fachliche Breite und die internationale Verteilung erhöhen die kognitive Last massiv – niemand kann in allen Modulen und Ländern gleichermaßen tief im Detail sein. Genau hier lagen die Schmerzen der bisherigen Organisation.

Die Schmerzpunkte der funktionsorientierten Organisation

Die vorherige Struktur war klassisch funktional: getrennte Bereiche für Entwicklung, Projekte und Support. In der Entwicklung gab es zwar bereits eine Spezialisierung nach Produkten (z. B. CAST, OCS, ECM), doch Projekt- und Support-Teams mussten häufig über das gesamte Portfolio hinweg arbeiten. Das führte zu mehreren systemischen Problemen:

Hohe kognitive Last im Support: Ein einzelner Support-Fall konnte OCS, CAST (mehrere Länder) und ECM betreffen – oft kundenspezifisch verknüpft. Das erforderte Wissen über Prozesse, Rechtslagen und Integrationen quer durch das Produktportfolio.
Verteilte Kommunikation über Zeitzonen: Entwicklung in einem Land, Support in einem anderen, große Kunden in weiteren Regionen – allein die Terminfindung für Fehleranalysen war schwierig. Dazwischen: Zeitverzug, Wissensverlust, hoher Koordinationsaufwand.
Übergaben als Reibungsverlust: Nach mehrjährigen Rollouts endete das Projekt – und das Wissen musste an den Support übergeben werden. „Zwei bis drei Jahre Wissen“ in wenigen Meetings zu übertragen, ist ein Rezept für Lücken.
Meetings statt Arbeit: Viel Zeit floss in Abstimmungen darüber, wie ein Problem koordiniert wird – statt in das Lösen des Problems selbst.

Kurz: Die Organisation schnitt quer zur tatsächlichen Wertschöpfung. Die Folge waren langsame Feedback-Zyklen, diffus verteilte Verantwortung und unnötige Handovers.

Die Zielarchitektur: Organization for Fast Flow

Das neue Organisationsmodell orientiert sich stark an „Team Topologies“. MIC hat die vier Teamtypen adaptiert und auf die eigene Domäne angewendet:

1) Stream-aligned Teams (Wertstrom-Teams)

Die primäre Liefereinheit. MIC unterscheidet hier zwei Ausprägungen:

Produktteams: End-to-End-Verantwortung für ein Produktsegment, inkl. Entwicklung, Projekten und Betrieb/Wartung. Das Team von Gerald Schweizer ist ein solches Produktteam (CAST für Deutschland und Österreich).
Service-Delivery-Teams: Zuständig für Enterprise-Kunden und deren spezifische Lieferanforderungen. Bei komplexen Fragestellungen greifen sie auf die Produktteams zurück.

Die Wirkung: Vertikale Schnitte entlang der Wertschöpfung statt horizontaler Funktionssilos. Das reduziert Übergaben und schafft direkte Feedback-Loops zwischen den Disziplinen.

2) Plattform-Teams

Sie reduzieren kognitive Last, indem sie wiederverwendbare Infrastruktur und Services bereitstellen. Beispiele, die Schweizer nannte:

Interfacing (z. B. ADIS) als zentraler Dienst, inklusive Länder-spezifischer Routen – Teams konsumieren APIs statt eigene Schnittstellen-Stacks zu bauen.
Cloud-Infrastruktur: Die Produktteams „wollen keine Kubernetes-Cluster betreiben, sondern sie einfach nutzen“.

3) Enabling Teams

Temporär „vermietete“ Befähiger, die andere Teams unterstützen, Methoden schärfen oder Strategien vorbereiten. Beispiel: Agile Coaches. Sie helfen beim Prozess-Setup, fördern Zusammenarbeit und Team-Entwicklung – und wechseln weiter, wenn ein Team eigenständig läuft.

4) Complicated Subsystem Teams

Seltene, spezialisierte Expertise, die nicht in jedem Team dauerhaft vorhanden sein muss. Beispiel: SAP-Integration bei Kundenprojekten. Diese Spezialisten werden bedarfsgerecht hinzugezogen.

Kollaborationsmuster

Plattform-Teams bieten Services und arbeiten mit Stream-aligned Teams zusammen.
Enabling Teams moderieren und befähigen temporär.
Complicated Subsystem Teams werden gezielt für knifflige Teilprobleme „zugeschaltet“.

Ergebnis: Schnellere Lieferung, klare Verantwortlichkeit, bessere Skalierbarkeit – und weniger kognitive Last in den Wertstrom-Teams.

Produktstream statt Funktionssilos

Der Produktstream ist entlang des Business Value vertikal geschnitten. Im Gegensatz zur alten Funktionsorganisation bündelt er alle benötigten Rollen:

Ein Team trägt End-to-End-Verantwortung von Entwicklung über Projektimplementierung bis hin zu Betrieb/Support.
Direkte Feedback-Schleifen: Was im Projekt oder Support auffällt, fließt unmittelbar zurück in Produktentscheidungen und Entwicklung.
Vereinfachte Übergaben: Projektmanager, Support- und Entwicklungskollegen arbeiten täglich zusammen – Wissen bleibt im Team, nicht in Übergabedokumenten.

Gleichzeitig adressiert MIC die Sorge vieler Enterprise-Kunden, dass sie nun „mit 20 Teams sprechen“ müssten: Ein Customer Success Manager (CSM) dient als zentraler Hauptansprechpartner. Er hält die Kundenbeziehung, koordiniert Themen und lotst Anfragen gezielt in die richtigen Teams.

Das Team CAST Germany & Austria – eine Produktstream-Perspektive

Schweizers Team verantwortet die Zoll-Anmeldelösungen für Deutschland und Österreich. Zu Beginn definierte das Team eine klare Vision:

„Eine einfache, verlässliche und vollständige CAST-DA- und RTA-Lösung, die Kundenbedürfnisse erfüllt – erreicht durch gegenseitige Unterstützung und Zusammenarbeit im Team.“

Struktur und Rollen (24 Personen)

Value Stream Lead: People Lead, stellt sicher, dass das Team alles hat, um gute Arbeit zu leisten; kümmert sich um Administration (z. B. Urlaube, Gehaltsgespräche) und unterstützt die Prozessgestaltung.
Product Owner: Verantwortlich für Produkt-Entwicklung, rechtliche Änderungen und Markterfolg; versteht Kundenbedürfnisse und stellt sicher, dass gesetzliche Anforderungen im Produkt korrekt abgebildet werden.
Agile Coach: Als Teil des Enabling-Ansatzes im Team, hilft beim Set-up der Arbeitsweisen, fördert kontinuierliche Verbesserung und Teamzusammenarbeit.
Entwickler: Bauen und pflegen die Produktfunktionalität.
Business- und Third-Level-Analysten: Arbeiten an Projekten und Entwicklung; sie übersetzen fachliche Anforderungen, unterstützen Spezifikationen und bearbeiten komplexe Problemfälle.
Incident Manager: Verantwortlich für Support, Störungsbearbeitung und Kundenanliegen.
Projektmanager: Steuern Implementierungen, enge Zusammenarbeit mit Kunde und Team über meist mehrmonatige bis mehrjährige Rollouts.

Service-zentriert vs. Entwicklungs-zentriert

Aufgrund der Teamgröße gliedert MIC die Arbeit in zwei Schwerpunkte:

Service-zentriert: Incident Manager und Projektmanager sind hier verankert.
Entwicklungs-zentriert: Entwickler bilden den Kern.
Brückenrollen: Business-Analysten und Third-Level-Analysten wechseln kontextabhängig zwischen beiden „Blöcken“.

Das ist kein neues Silo, sondern ein Arbeitsmodus, der Fokussierung ermöglicht – mit klarer Erwartung, dass Rollen teamübergreifend kooperieren.

Arbeitsmodell und Prozesse

Bi-weekly Scrum-basierter Entwicklungszyklus

Das Team plant im zweiwöchigen Takt seine Development-Arbeit und reviewed die Ergebnisse – iterativ, transparent, mit kurzen Feedback-Loops.

Support-Flow nach etablierten Leitlinien

Schweizer beschreibt den Support als „stark an den ETL-Richtlinien orientiert“ – mit Incident- und Service-Requests sowie Problem-Records für nachhaltige Lösungen bei schwerwiegenden Themen. Wichtig ist die klare Unterscheidung: Was ist akute Störungsbehebung? Was erfordert systemische Ursachenanalyse und langfristige Abhilfe?

Test- und Liefermodelle: Kontext entscheidet

Agile oder Wasserfall – abhängig vom Inhalt.
In der Zoll-Domäne dominiert Wasserfall: Das Ziel (z. B. eine korrekte Zollanmeldung mit festem Datensatz) ist rechtlich definiert. Entscheidungen zu Datenquellen, Verarbeitung und Automatisierungsgrad müssen häufig vorab getroffen werden. Innerhalb von Projekten gibt es trotzdem Spielräume für agile Iteration.

Domain-Onboarding und geteiltes Verständnis

Ein Grundpfeiler der Teamkultur ist geteiltes Domänenwissen. Jede Rolle – inkl. Entwickler – muss die relevanten rechtlichen Prozesse verstehen, um die richtigen fachlichen Entscheidungen technisch präzise umzusetzen. Deshalb bekommen neue Teammitglieder in den ersten Tagen, Wochen und Monaten eine ausführliche Einführung in die deutschen und österreichischen Zollprozesse.

Kultur: Keine Silos, gemeinsame Verantwortung

Schweizer betont die cross-funktionale Zusammenarbeit. Beispiele aus dem Alltag:

Entwickler dürfen (und sollen) bei Support-Incidents mithelfen – gemeinsam mit Incident Managern oder eigenständig, wenn sinnvoll.
Projektkollegen bearbeiten bei Bedarf auch Support-Tickets.
Support-Kollegen unterstützen Spezifikationen oder Validierungen für neue Entwicklungsvorhaben.

Die Leitplanke lautet: „Wir unterstützen uns gegenseitig.“ Das bricht Silogrenzen auf, beschleunigt Lernen und reduziert Übergaben.

Ergebnis: Schnellerer Fluss – und Skalierung auf die ganze Firma

Der Pilot mit Produktstreams – inklusive des Teams CAST Germany & Austria – läuft erfolgreich. MIC rollt das Modell nun auf das gesamte Unternehmen aus. Die wesentliche Verbesserung: Von der Entwicklung über Projekte bis in den Support entsteht Fluss – mit weniger Koordination, kürzeren Feedback-Schleifen und größerer Kundennähe. Oder in Schweizers Worten: „Es geht sehr gut – wir rollen es jetzt in der ganzen Firma aus.“

Praktische Lehren für Engineering-Leads und Architekt:innen

Was lässt sich aus „Organization for Fast Flow“ konkret ableiten? Aus unserer DevJobs.at-Perspektive fallen mehrere übertragbare Prinzipien auf – alle direkt anschlussfähig an die Beispiele aus MIC:

1) Entlang des Wertstroms schneiden

Teams so zuschneiden, dass sie Ende-zu-Ende liefern: Entwicklung, Projekt, Betrieb/Support in einem Wertstrom.
Verantwortlichkeit und Feedback bündeln, Übergaben minimieren.

2) Kognitive Last aktiv reduzieren

Plattform-Teams für wiederverwendbare Infrastruktur (z. B. Schnittstellen, Cloud) etablieren.
Spezialwissen in Complicated Subsystem Teams bündeln und bei Bedarf dazunehmen.

3) Enabling als Beschleuniger verstehen

Agile Coaches und andere Befähiger temporär einsetzen, um Teams zu stabilisieren, Prozesse zu schärfen und Zusammenarbeit zu verbessern.

4) Kundenschnitt mit Bedacht gestalten

Trotz internem Vertikalschnitt extern eine klare „Hauptansprechperson“ anbieten – das CSM-Muster vermeidet Reibung für Enterprise-Kunden.

5) Domänenwissen systematisch aufbauen

Onboarding und kontinuierliche Wissensvermittlung sind Pflicht – besonders bei rechtlich getriebenen Prozessen wie Zoll.
Entwickler brauchen Prozessverständnis; Business-Rollen brauchen Techniknähe – beide lernen voneinander.

6) Kontextgerechte Delivery-Modelle

Dort agil iterieren, wo es sinnvoll ist.
Dort Wasserfall nutzen, wo Anforderungen (z. B. rechtlich) fix sind und Vorab-Design nötig ist.

7) Verteilte Zusammenarbeit bewusst organisieren

Zeitzonen kosten Zeit – reduzieren Sie Abhängigkeiten und Koordinationsbedarf.
Kleine, regelmäßige Abstimmungen im Kernteam schlagen große, seltene „Alignment-Calls“.

Umsetzungshinweise: So starten Teams in Richtung Fast Flow

Portfolio kartieren: Welche Produkte, Länder, rechtlichen Verfahren, Integrationen? Wo entstehen heute die meisten Übergaben und Wissensverluste?
Produktstreams schneiden: Entlang von klaren Wertbeiträgen (z. B. Länder-Cluster wie CAST DE/AT) statt entlang der Funktionen.
Plattform identifizieren: Welche Schnittstellen- und Infrastruktur-Bausteine sind generisch und sollten als Service bereitgestellt werden (Interfacing, Cloud, Routing)?
Rollen komplettieren: Ein Stream braucht PO, Engineering, Projekt, Support/Incident Management – plus die „Brückenrollen“ (Business-/Third-Level-Analyse).
Enabler einsetzen: Agile Coach temporär dazu, Prozesse aufsetzen, Routinen einüben, Retros etablieren.
Cadence etablieren: Zweiwöchige Planung und Reviews für Entwicklung; klare Support-Flows mit Incident/Service/Problem.
CSM-Rolle definieren: Ein zentraler Kundeneingang, der intern zielgenau verteilt – ohne externe Komplexität.
Start klein, dann skalieren: Ein Pilotstream validiert Schnitte und Zusammenarbeitsmuster – danach Rollout.

Woran Sie Fortschritt erkennen

Ohne zusätzliche Metriken zu erfinden, lassen sich anhand der in der Session genannten Muster qualitative Effekte ableiten:

Weniger Übergaben zwischen Projekt und Support, weil Rollen gemeinsam im Stream arbeiten.
Kürzere Reaktions- und Durchlaufzeiten durch reduzierte Koordination über Zeitzonen hinweg.
Höhere fachliche Trefferquote, weil Domänenwissen im Team breit verankert ist.
Bessere Kundenerfahrung dank CSM als Hauptkontakt – intern ist es komplex, extern bleibt es einfach.

Fazit

„Organization for Fast Flow“ von Gerald Schweizer (MIC) zeigt, wie eine Organisation mit hoher Produkt- und Länderkomplexität den Schritt zu Wertstrom-Teams meistert. Der Kern ist nicht nur eine neue Orchestrierung von Rollen, sondern eine bewusste Reduktion kognitiver Last: Plattformdienste bündeln Generika, Spezialwissen wird gezielt „zugeschaltet“, und die Produktstreams verantworten Ende-zu-Ende Entwicklung, Projekte und Betrieb. Das Ergebnis sind schnellere Feedbacks, weniger Übergaben und eine robuste Grundlage für global skalierende Lieferfähigkeit – genau das, was moderne Enterprise-Software in regulierten Domänen braucht.

Weitere Tech Talks

Weitere Tech Lead Stories