dot.blog

dot.coaching - Change beginnt mit Wertschätzung.

samuel.gerber@dotag.ch (Samuel Gerber) — Tue, 12 May 2026 04:00:00 GMT

In Organisationen entsteht Veränderung oft aus einem nachvollziehbaren Impuls: Etwas funktioniert nicht mehr wie gewünscht - also braucht es Veränderung.

dot.coaching - Warum Change scheitert - bevor er beginnt.

samuel.gerber@dotag.ch (Samuel Gerber) — Tue, 05 May 2026 04:00:02 GMT

Der schwierigste Schritt in jeder Transformation ist nicht die Umsetzung, sondern die Erkenntnis, dass struktureller Wandel überhaupt notwendig ist. In vielen Organisationen fehlt genau diese Erkenntnis - oder sie ist nur in Teilen vorhanden. Man spürt die Reibung, sieht die Symptome, weiss, dass etwas nicht stimmt. Aber der Schritt von "etwas läuft nicht rund" zu "wir haben ein strukturelles Problem, das wir als Führung gemeinsam angehen müssen" ist gross. Und er wird selten explizit gemacht.

Dieser Beitrag beschreibt, warum dieser erste Schritt so entscheidend ist - und wie wir Change gemeinsam mit Führungsteams angehen, wenn die Ausgangslage noch nicht vollständig anerkannt ist.

Was wir beobachten: Change, der absorbiert wird

In komplexen Organisationen - besonders in regulierten Umfeldern - entstehen strukturelle Probleme über Jahre hinweg. Fehlende Governance-Klarheit, unklare Rollen, Messdefizite, parallele Mandate: Das sind keine operativen Störungen. Es sind systemische Muster. Und sie sind kein Einzelfall - sie sind repräsentativ für eine breitere organisationale Realität.

Diese strukturelle Komplexität produziert keine neutrale Unordnung. Sie erzeugt spezifische, vorhersehbare Spannungen - zwischen Teams, an Schnittstellen (was eigentlich "Nahtstellen" sein sollten - Sprache schafft Wahrheit!) in Führungsrollen. Das Entscheidende: Diese Spannungen werden aktuell von Menschen absorbiert. Von Rollen, Teams und Einzelpersonen, die kompensieren, überbrücken und auffangen - anstatt dass die Ursache dort angegangen wird, wo sie entsteht: auf der strukturellen Ebene. Arbeit AM System!

Was als Leistungsproblem erscheint, ist oft die sichtbare Oberfläche einer strukturellen Frage, die die Organisation noch nicht gelöst hat.

Die Symptome - Reibung, Überlastung, mangelnde Entscheidungsklarheit - sind keine isolierten Klagen und keine individuellen Versäumnisse. Sie sind der menschliche Ausdruck eines Systems, das seine fundamentalen organisatorischen Fragen noch nicht beantwortet hat. Solange diese Fragen unbeantwortet bleiben, werden Massnahmen an der Oberfläche wirkungslos bleiben.

In einem unserer Projekte mit einer grossen Organisation (5^5) war die strukturelle Diagnose klar - aber das gemeinsame Anerkennen dieser Realität durch das Führungsteam war erst der Anfang. Genau das ist oft der eigentliche erste Schritt: nicht das Entwickeln eines Plans, sondern das kollektive Aussprechen dessen, was alle schon spüren. Erst danach konnte die Frage beantwortet werden, wie die Führung den Wandel aktiv übernimmt - sichtbar, konsistent und über Zeit. Und erst dann liess sich ein Change-Ansatz entwickeln, der der tatsächlichen Komplexität der Organisation gerecht wurde.

Unsere Haltung: Den Startpunkt verstehen und würdigen

Wir gehen bei Change-Vorhaben nicht mit einer vorgefertigten Roadmap rein. Wir beginnen damit, die Organisation so zu verstehen, wie sie wirklich ist - nicht wie sie sein sollte. Das bedeutet: den Ist-Zustand ernst nehmen, bevor Massnahmen definiert werden.

Jede Organisation hat auf dem Weg dahin, wo sie heute steht, etwas geleistet. Soziale Kohäsion, Fachkompetenz, regulatorische Verlässlichkeit - das sind keine Selbstverständlichkeiten. Wer diesen Ausgangspunkt versteht und anerkennt, schafft die Voraussetzung dafür, dass Menschen den nächsten Schritt mitgehen wollen.

Verhalten folgt Verhältnissen. Wer den Startpunkt nicht versteht, baut auf einer Annahme - nicht auf einer Grundlage.

Unser Change Approach im Überblick

Auf dieser Grundlage haben wir einen strukturierten Change Approach entwickelt, der top-down Richtung gibt und bottom-up Gestaltung ermöglicht. Er kombiniert Leadership-Involvement von Tag 1 mit einem crossfunktionalen Core Team. In 6-12 Monaten werden Abstraktionsmodelle und Zusammenarbeitsmodelle gemeinsam entwickelt, Rollen befähigt und der Go-Live mit Sicherheitsmarge geplant.

Darunter liegen zwei methodische Leitplanken: ADKAR beantwortet die Frage, wo die Menschen im Wandel stehen. Lean Change Management beantwortet die Frage, wie der Wandel konkret gestaltet wird - iterativ, feedback-getrieben, mit gezielten Experimenten statt starren Rollout-Plänen. Die strukturelle Arbeit am System wächst dabei kontinuierlich - sie nimmt nach dem Go-Live nicht ab, sondern zu.

ADKAR: Wo stehen die Menschen?

Bevor Massnahmen greifen können, braucht es ein klares Bild: Wo steht jede Person, jedes Team im Wandel? ADKAR (nach Prosci) gibt dafür einen präzisen Rahmen - und zeigt, wo echte Blockaden liegen: nicht im Framework, sondern im Menschen. Häufig liegt die Blockade bereits bei Awareness oder Desire - lange bevor es um Methoden oder Verankerung geht.

Lean Change Management: Experimente statt Rollout-Pläne

Parallel zur ADKAR-Reifung gestalten wir den Wandel nach den Prinzipien des Lean Change Managements. Der Ansatz folgt einem einfachen, aber mächtigen Zyklus: Zuerst Insights sammeln - was ist wirklich los, was war wertvoll, was blockiert? Dann Optionen abwägen - nicht planen, sondern entscheiden. Und schliesslich in gezielten Experimenten erproben, was die Organisation aufnehmen kann. Wie ein solcher Rahmen auf Organisationsebene strukturiert wird, beschreiben wir in unserem Beitrag zum Target Operating Model (TOM).

Top-down definiert die Richtung und die Nicht-Verhandelbaren Elemente. Bottom-up gestaltet mit, wie der Wandel im eigenen Kontext passieren kann.

Das Entscheidende: Experimente sind keine Piloten auf Verdacht. Sie sind zeitlich begrenzt und messbar. Zudem haben sie eine klar formulierte, vorangehende Hypothese "wir gehen davon aus, dass wenn wir xy machen, dieser positive Effekt eintrifft" sowie ein Abschluss Kriterium - weiterführen, adaptieren oder abbrechen. So entsteht eine empirische Grundlage statt einer auf den Idealzustand ausgelegten Roadmap. Compliance wird dabei nicht draufgesetzt, sondern in die Arbeitsweise der Teams eingebettet.

Wie angehen: drei parallele Streams

Die Frage "Wo fangen wir an?" ist eine der häufigsten in Transformationsprojekten. Unsere Antwort: nicht sequentiell - sondern mit drei Strängen gleichzeitig. Jeder Stream erzeugt eine andere Art von Klarheit. Zusammen schaffen sie die Grundlage für eine glaubwürdige, anpassungsfähige Change-Roadmap.

Ein zentrales Learning aus unserer Beratungsarbeit: Wenn Change nur in einzelnen Bereichen eigentümergeführt wird, entsteht kein Systemwandel - sondern neue Inkonsistenzen. Führungsalignment auf die Veränderungsrichtung ist keine Voraussetzung zum Starten - aber eine Voraussetzung zum Gelingen. Das Ziel ist nicht, zu stören, was funktioniert - sondern das Fundament zu schaffen, das funktioniert und skaliert.

Was das für deine Organisation bedeutet:

Struktureller Wandel gelingt nicht durch bessere Methoden allein - sondern durch die Bereitschaft, ihn gemeinsam zu führen. Unsere Empfehlung an solche Organisationen:

Verstehe, wo deine Organisation heute wirklich steht - und würdige diesen Ausgangspunkt.
Erkenne die strukturellen Muster offen an - kollektiv, nicht in Einzelgesprächen. Ohne Vorwürfe.
Führe den Wandel sichtbar und konsistent - er kann nicht delegiert werden.
Starte orchestriert den Piloten, Assessment und Messung parallel - nicht sequentiell.
Ermögliche Experimente - und gebe den Teams die Erlaubnis zu scheitern.
Plane realistisch: struktureller Wandel braucht mind. 2-3 Jahre.

Fazit

Wenn uns jemand fragt, was wir eigentlich tun, lautet unsere Antwort: Wir schaffen Räume. Räume, in denen genau diese Themen angeschaut werden können - strukturell, ehrlich und mit der nötigen Tiefe. Räume, in denen das Führungsteam gemeinsam die Realität der Organisation betrachten kann, ohne sofort in Lösungsmodus zu verfallen.

Diese Räume halten wir gemeinsam - mit unseren Kunden, nicht für sie. Weil nachhaltige Wirkung nur entsteht, wenn die Organisation die Antworten selbst entwickelt. Unsere Rolle ist es, den Rahmen zu setzen, die richtigen Fragen zu stellen und den Prozess so zu begleiten, dass wirkungsvolle Ergebnisse entstehen - und bleiben.

Change gelingt nicht durch bessere Frameworks. Er gelingt, wenn Führung die Verhältnisse schafft, in denen Menschen anders handeln können - und wollen. Und wenn der Startpunkt der Organisation nicht übergangen, sondern verstanden und anerkannt wird.

dot.coaching - Wenn der Agent ins Team kommt - Was sich in der Zusammenarbeit fundamental verändert und warum das kein IT-Thema ist

tobias.ellenberger@dotag.ch (Tobias Ellenberger) — Tue, 28 Apr 2026 05:40:00 GMT

Die Frage, ob AI Agents die Arbeit von Teams verändern werden, ist längst beantwortet. Sie tun es bereits. In Pilotprojekten, in ersten produktiven Einsätzen, in den Roadmaps von R&D-Organisationen, die Produkte im regulierten Umfeld bauen, pflegen und vertreiben.
Die eigentliche Frage lautet deshalb: Was machen Agents mit der Art, wie Teams funktionieren? Und sind Organisationen und Führungskräfte darauf vorbereitet, was dabei entsteht?
Dieser Beitrag ist kein Technikbeitrag. Er ist ein Organisationsentwicklungsbeitrag. Denn wer AI Agents als Werkzeug betrachtet, unterschätzt, was gerade passiert.

dot.coaching - Warum KI deine organisatorischen Probleme nicht lösen kann

tobias.ellenberger@dotag.ch (Tobias Ellenberger) — Tue, 14 Apr 2026 03:00:01 GMT

Viele Organisationen glauben, sie führen AI Agents ein. In Wirklichkeit legen sie ein neues Werkzeug auf ein altes Problem und machen dieses Problem dabei unsichtbarer, nicht kleiner. Das ist keine Hypothese aus dem Lehrbuch. Das ist eine Beobachtung aus der Praxis.

dot.research - Die 5er-Potenz in der Organisationsentwicklung - Oder wie gross darf eine Organisation sein?

david.berger@dotag.ch (David Berger) — Thu, 02 Apr 2026 04:59:58 GMT

Oder: Wie organisiere ich meine Organisation? Gibt es eine Zauberformel? Welche Strukturen skalieren wie und wie lange? In diesem Blog fassen wir die «Faustregel» der 5er-Potenz zusammen und bedienen uns dabei unterschiedlichen Quellen. Wir zeigen typische Muster und Intensitäten von «Organisation» innerhalb dieser 5er-Potenz. Willkommen.

dot.tipp - Workshop Assistenz: Die Rolle, die niemand ausschreibt und alle brauchen

david.berger@dotag.ch (David Berger) — Tue, 24 Mar 2026 06:00:00 GMT

In diesem Beitrag möchte ich gerne die Rolle der Workshop Assistenz skizzieren, die sich bewusst vom Workshop FacilitatorIn abgrenzt. Ich möchte gerne auch die Möglichkeiten der neuen Werkzeuge integrieren, namentlich KI mittels LLM. Dieser Beitrag entstand in Kooperation mit der agilist.cooperative während einer internen Unconference. Willkommen.

dot.research - Hypothese Matrixorganisationen im Comeback?

david.berger@dotag.ch (David Berger) — Wed, 11 Mar 2026 05:55:17 GMT

Etliche Unternehmen passen ihre Aufbauorganisation der Ablauforganisation an. Beispielsweise werden aus Agile Release Trains in SAFe auch entsprechende Aufbauorganisationen geschaffen. Oder auch LeSS beschwört die «Product Group» als alleiniges Organigramm. In diesem Beitrag möchte ich gerne darlegen, warum manchmal «virtuelle» Organisationen respektive Matrixorganisationen durchaus berechtigt sind. Willkommen.

dot.kunden - Strategisch planen mit SAFe... nicht nötig?

desiree.jakubowitz@dotag.ch (Désirée Jakubowitz) — Wed, 18 Feb 2026 08:43:46 GMT

dot.review - Die 30. Bärner Requirements Night in Bern vom 28. Januar 2026

david.berger@dotag.ch (David Berger) — Thu, 05 Feb 2026 06:00:01 GMT

Ich hab’s wieder einmal geschafft: eine Bärner Requirements Night besucht. Warum? Weil ich mit einigen Personen aus dem Board vertraut bin einerseits. Andererseits, weil das Thema mich umtreibt. Regelmässig bin ich im Thema Requirements Engineering verwickelt. In diesem Beitrag möchte ich diese Abendveranstaltung sanft resümieren. Willkommen.

Die Örtlichkeit

Die SBB sponsorte die Lokalität am Wylerpark. «Demnächst» soll ja die SBB alle ihre Büros am Campus Wankdorf zentralisieren. Für mich war’s aber irgendwie ein Zurückkommen. Ich habe im Wylerpark etliche Projekte bestritten und Workshops moderiert und Modelle skizziert. Nach so vielen Jahren bewegten mich diese Erinnerungen beim Eintreffen. Beispielsweise an das erste Vorstellungsgespräch bei der SBB im WYPB, wo ich mich als Modellierungsexperte am Flipchart beweisen musste. Danke Jüre!

Oder: Im selben Raum habe ich einst mal einen Vortrag zusammen mit Charlize Vogelsinger gehalten. Wir haben über die Unzulänglichkeit von Modellen uns Stichworte hin- und hergeworfen. Wir waren damals beide in Modelldiskussionen in der SBB beruflich vertieft – auch mit dem Gastgeber der 30. Requirements Nights, Alain Hofer. Danke euch beiden!

Für mich war die SBB immer mehr als nur eine Firma. Für mich ist die SBB ein nationales Symbol und ich bin weiterhin bin stolz erfüllt, dort in der Ära Meyer/Pilloud mitwirken und auch Mehrwert geleistet haben zu dürfen.

Doch nun zur Besprechung der Vorträge.

Christian Kaiser: AI ohne klare Anforderungen: Warum Erwartung und Realität kollidieren

Christian Kaiser ist Unternehmensarchitekt bei der SBB. Das war mal mein «Traumjob». Er verdeutlichte die Wichtigkeit der fundierten Problemanalyse – aka Requirements Engineering. Zudem warnte er davor, blind mit KI Probleme lösen zu wollen. Stattdessen solle die KI abgrenzbare Aufgaben erledigen. Als datenaffiner Architekt demonstrierte er zudem in anschaulichen SBB-Echtweltbeispielen die Bedeutung der Datenerfassung sowie -strukturierung. Ebenso sensibilisierte er die Teilnehmenden, dass für die Lösung eines Problems nicht nur eine Technologie angemessen sei – sondern in der Auseinandersetzung, also Problemerfassung die Technologie sich zeigen und herauskristallisieren werde.

So ungefähr meine Zusammenfassung. Sein kühler Vortragsstil, verstärkt durch eine subtile, aber gemutmasste Bewandtnis, hat die Aufmerksamkeitsspanne des Publikums maximiert. Ich hätte ihn sofort eingestellt oder engagiert – wäre ich suchend gewesen.

Rainer Grau: RE Education yesterday, today, tomorrow

Rainer Grau repräsentiert eine ganze RE-Epoche der Schweiz. Als Mitgestalter des bekannten IREB-Standards hat er kurz durch die Geschichte des Requirements Engineerings geführt. Als Faktenkenner habe ich keine Fehler zu beanstanden. In eleganten Klammern hat er jeweils zu aktuellen Trends sich geäussert – mit der bemerkbaren Zustimmung des Publikums.

Rainer konzentrierte sich auf die Tätigkeit des «Entwickelns». An der von ihm mitorganisierten Agile Unconference letzten Jahres war dies übrigens auch ein Thema. Für ihn versinnbildlicht Entwicklung nicht die Muskelmasse «Programmieren». Für ihn ist Entwicklung die vollendete Lösungsfindung eines Problems. Er postulierte den Requirements Engineer als grosser Orchestrator, der auch etliche KI-Agenten einsetzen kann, um das Problem zu lösen – und währenddessen stets über die Entwicklung auskunftsfähig sei. Faktisch ist das die Aufgabe eines RE, unabhängig, ob ein lokales Team, ein Near- oder Offshore-Team oder halt Agenten den Programmieraufwand bewältigen. In diese Rolle habe ich alle «meine» RE stets zu schulen versucht.

Jedenfalls verstand er es ausgezeichnet, das Publikum mit Anekdoten und Erfahrungswissen sowie Orakelfähigkeiten günstig zu beeinflussen. Auf die letzten acht Minuten seines Vortrages verzichtete er mit dem Hinweis, er brauch sie nicht. Das Publikum dankte. Sehr gelungen.

Gerd Maier: Zeitreise Anforderungs- und Nachweismanagement

Gerd Maier ist RE bei der armasuisse, der Beschaffungsorganisation des VBS. Auch Gerd ist schon seit einigen Jahrzehnten im Thema Requirements Engineering involviert. Sein Schwerpunkt bildete das Anforderungsmanagement, im aktuellen IREB-Lehrplan das 6. Kapitel, wo gemäss Alain am 3. Tag der Default IREB Foundation Schulung bereits alle Mitarbeitende dösen sollen.

Anforderungsmanagement bedeutet automatisch Werkzeugunterstützung (Kapitel 7). Also kombinierte Gerd seinen Lebenslauf mit der Geschichte der Requirements-Managements Werkzeugen. Am Anfang war das Papier, das per Business-Class durch die Welt mit entsprechenden Prüftechniken transportiert wurde. Und dann kam Excel. Und am Schluss wieder Excel.

Ich habe die Pointe bewusst vorweggenommen. Excel ist für ihn aber vielmehr «Frontend» statt «Backend». Er hat mit Excel erfolgreich die Zugänglichkeit für die Fachbereiche erhöht, weil diese komplizierten RM-Tools wirklich kompliziert in der Bedienung sind. Ich kenne riesige SMI-Konzerne, wo bloss eine handvolle Mitarbeitende die Struktur der System Requirements im spezialisierten RM-System korrekt rezitieren können – und einer davon wortwörtlich blind.

Ich bin ja bekanntlich kein Excel-Freund. Es gibt bessere Excel-Bediener (mehrheitlich männlich), ich kenne sogar in der Familie einen. Ich kann mir also gut vorstellen, dass in einem bestimmten Kontext Fachbereiche Excel bevorzugen. In diesem Sinne war Gerd der beste aller Requirements Engineers: Problem verstanden und Lösung ganz technologieoffen entwickelt. Dass Gerds Liebe zu Excel keine heimliche ist, hatte das Publikum verstanden.

BTW: Und Gerds Excel ist sowieso «nur» das Frontend, alle Anforderungen werden im «Backend» revisionssicher gespeichert; Nachvollziehbarkeit ist kein Thema - also dass wir uns hier nicht missverstehen. Für uns im Publikum war das klar.

Was nehme ich mit?

Den Netzwerk-Teil musste ich kurzhalten. Die soziale Energie ist manchmal erschöpft und der SBB-Fahrplan doch noch nicht so verdichtet. Deswegen kann ich nicht viel von neuen Kontakten etc. berichten – wäre auch als Blogformat nicht so vorteilhaft. Immerhin ein kurzes Wiedersehen mit einigen Kollegen am Platz Bern.

Für mich war Requirements Engineering niemals «gestorben». Weder zu agilen Hochzeiten noch im KI-Zeitalter. Insbesondere im KI-Zeitalter wird die Disziplin umso wichtiger. Es ist für mich weniger das «Prompt Engineering», das das Thema treibt. Das ist einigermassen «abgelatscht» – wie es beispielsweise Christian Kaiser im Nebensatz konstatierte. Für mich bleibt Requirements Engineering die Fähigkeit, Probleme zu verstehen und Lösungen entwickeln zu lassen und deren Richtigkeit überprüfen zu können – und das ganze prozessual zu begleiten und einigermassen nachhaltig im Sinne des Wissensmanagements zu dokumentieren. Umso schneller die Lösungen (beispielsweise in einer (IT-)Exploration), umso wichtiger diese Fähigkeit. Das muss meinetwegen nicht in einer ICT-Berufsrolle manifestiert sein.

dot.internes - Alles ist Verhandlung

david.berger@dotag.ch (David Berger) — Tue, 27 Jan 2026 06:00:00 GMT

Bekanntlich investieren wir in die Am-System-Arbeit. Das beinhaltet auch regelmässige Weiterbildungen, die uns als Team stärken sollen. Unter dem Schlagwort "Internes" berichten wir hier über solche Ausbildungen. Im Sommer 2025 haben wir Matthias Herter von MSH Advice & Training eingeladen, um das Thema "Verhandlung" zu vertiefen. In diesem Blog fasse ich diesen Weiterbildungstag zusammen.