Deutsch
English
LKPU Blog
Aus der Praxis gelernt.
Für die Praxis geschrieben.
In unserem Blog schreiben wir über die Themen, die uns in Projekten wirklich beschäftigen. Über Dinge, die nicht ganz zusammenpassen, über Fragen, auf die es keine bequeme Antwort gibt, und über Probleme, die man gern ein bisschen zu lange ignoriert. Wir schauen genauer hin, hinterfragen Gewohntes und teilen, was wir dabei lernen. Wir schreiben aus der Praxis und mit dem Anspruch, Dinge klar zu benennen. Nicht jede Beobachtung ist bequem – aber genau darin liegt oft ihr Wert. Für Menschen und Teams, die Zusammenhänge wirklich verstehen und fundierte Entscheidungen treffen wollen.
Das Organigramm ist sauber. Die Kästchen sind ausgerichtet. Jeder hat einen Chef. Das Problem: Arbeit hält sich erstaunlich selten an Kästchen.
Organigramme beantworten eine wichtige Frage:
Wer berichtet an wen?
Leider beantworten sie viele andere Fragen nicht:
Wer macht welche Arbeit?
Welche Aufgaben sind wirklich kritisch?
Welche Fähigkeiten werden dafür benötigt?
Wo entstehen Engpässe?
Welche Rolle entscheidet?
Wo existieren Doppelzuständigkeiten?
Und warum landet diese eine Aufgabe eigentlich immer bei Bas?
Das Organigramm suggeriert Ordnung, weil es Ordnung visualisiert. Aber eine Organisation ist kein Baumdiagramm. Sie ist ein Netzwerk aus Arbeit, Verantwortung, Fähigkeiten, Kapazitäten und Abhängigkeiten. Zwei Abteilungen können organisatorisch weit voneinander entfernt sein und trotzdem jeden Tag voneinander abhängen. Zwei Personen können denselben Titel tragen und vollkommen unterschiedliche Aufgaben erledigen. Und eine Position kann auf dem Papier perfekt besetzt sein, obwohl die Person nicht über die benötigten Skills verfügt.
Das Organigramm ist deshalb nicht falsch – Es ist nur sehr unvollständig.
Problematisch wird es, wenn Unternehmen es trotzdem als Abbild ihrer Organisation behandeln. Ein besseres Organisationsbild verbindet mindestens drei Perspektiven:
Was muss getan werden?
Prozesse und Aufgaben.
Wer soll es tun?
Strukturen, Rollen und Stellen.
Wer kann es tatsächlich tun?
Menschen, Skills und Kapazität.
Erst wenn diese drei Perspektiven zusammenkommen, wird aus einem Organigramm ein Organisationsmodell. Bis dahin wissen Sie, wer wessen Chef ist. Das ist ein Anfang.
Autor: Anna-Lena Appel
Der Prozess ist dokumentiert, freigegeben und wahrscheinlich sogar als hübsches Flussdiagramm gespeichert. Dann nimmt Bas zwei Wochen Urlaub.
Der Prozess sah fantastisch aus.
Zwölf Kästen. Sechs Pfeile. Drei Freigaben. Eine Legende.
Es gab sogar eine Version 4.2_final_FINAL.
Dann war Bas nicht da.
Plötzlich stellte sich heraus, dass Schritt sechs nur funktioniert, weil Bas jeden Donnerstag eine Excel-Datei korrigiert. Schritt acht setzt voraus, dass jemand weiß, dass Kunde A anders behandelt wird. Und die Freigabe in Schritt zehn kommt offiziell von einer Rolle, deren Stelleninhaber seit vier Monaten gewechselt hat. Der dokumentierte Prozess war korrekt. Nur die Realität hatte offenbar die Dokumentation nicht gelesen. Das passiert, wenn Prozesse isoliert betrachtet werden. Ein Prozess besteht nicht nur aus Aktivitäten. Jede Aktivität braucht Verantwortung, Fähigkeiten, Kapazität, Informationen und häufig Systeme. Wenn nur einer dieser Punkte fehlt, bleibt der Prozess trotzdem hübsch dokumentiert. Er funktioniert nur nicht.
Die bessere Frage lautet deshalb nicht:
„Ist der Prozess dokumentiert?“
Sondern:
„Ist er organisatorisch abgesichert?“
Wer erledigt jede Aufgabe?
Ist die Verantwortung eindeutig?
Sind die notwendigen Skills vorhanden?
Ist genügend Kapazität verfügbar?
Was passiert bei Urlaub, Krankheit oder Wachstum?
Ein stabiler Prozess überlebt Abwesenheiten.
Ein instabiler Prozess hat Bas.
Und eine Excel-Datei.
Autor: Jan Koppetsch
Wenn Ihre Organisation nur funktioniert, weil Bas weiß, wen er anrufen muss, haben Sie kein Operating Model.
Bas kennt die Organisation. Nicht das Organigramm. Die echte Organisation. Er weiß, wer Entscheidungen treffen kann, wer Probleme löst und wen man besser nicht in CC setzt. Praktisch! Bis Bas nicht da ist. Es gibt in erstaunlich vielen Unternehmen einen Bas. Bas kennt nicht nur seinen Job. Er kennt auch die Abkürzungen, Sonderfälle und informellen Zuständigkeiten. Wenn ein Prozess hängt, weiß Bas, wen man anrufen muss. Wenn zwei Bereiche sich nicht einigen können, kennt Bas jemanden, der jemanden kennt. Und wenn eine Aufgabe offiziell bei Team A liegt, tatsächlich aber seit Jahren von Team B erledigt wird, weiß Bas das natürlich auch. Das ist komfortabel. Und ein Problem. Denn was auf den ersten Blick nach Erfahrung und guter Zusammenarbeit aussieht, ist häufig ein Hinweis darauf, dass ein erheblicher Teil der Organisation nur im Kopf einzelner Menschen existiert. Das Organigramm sagt, wer wem berichtet. Prozessbeschreibungen sagen, wie etwas theoretisch ablaufen soll. Stellenbeschreibungen sagen, wofür Menschen zuständig sein sollten. Bas weiß, wie es wirklich funktioniert. Spätestens wenn Bas Urlaub hat, krank wird oder das Unternehmen verlässt, beginnt die Suche:
„Wer macht das normalerweise?“
„Ich dachte, das macht Finance.“
„Nein, das macht eigentlich Operations.“
„Frag Bas.“
Ein belastbares Operating Model sollte nicht davon abhängen, dass einzelne Menschen seine Lücken kompensieren. Es sollte sichtbar machen, welche Aufgaben erledigt werden müssen, welche Rollen und Stellen dafür verantwortlich sind, welche Fähigkeiten benötigt werden und ob tatsächlich genügend Kapazität vorhanden ist. Das bedeutet nicht, informelle Zusammenarbeit abzuschaffen. Im Gegenteil. Gute Organisationen brauchen Menschen, die Verbindungen herstellen. Aber diese Menschen sollten das System besser machen – nicht das System ersetzen. Die interessante Frage lautet deshalb nicht:
„Wer weiß, wie das hier funktioniert?“
Sondern:
„Würde es auch funktionieren, wenn diese Person morgen nicht da wäre?“
Wenn die Antwort „Nein“ lautet, haben Sie gerade etwas Wichtiges über Ihre Organisation gelernt. Bei Firm Ground® beschäftigen wir uns genau mit diesen Verbindungen: Prozesse, Strukturen, Aufgaben, Skills und Menschen werden nicht getrennt betrachtet, sondern als zusammenhängendes Modell. Bas darf trotzdem bleiben. Er muss nur nicht mehr alles wissen.
Autor: Michael Nolte
Banking wird unsichtbar. Die Organisation dahinter darf es nicht werden.
Banking verschwindet zunehmend aus dem Blickfeld. Zahlungen, Finanzierung oder Authentifizierung werden Teil einer Journey, über die Kunden möglichst wenig nachdenken wollen.
Im Hintergrund wird es dadurch allerdings nicht einfacher. Produkt, Payments, Fraud, Risk, Operations, Technology und externe Provider müssen nahtlos zusammenspielen. Für den Kunden ist es eine Erfahrung. Intern sind es oft viele Einheiten und Schnittstellen.
Genau darin liegt die Herausforderung: Je unsichtbarer Banking wird, desto klarer müssen Verantwortung und End-to-End-Steuerung sein.
Wer entscheidet im Fehlerfall? Wer besitzt die Journey? Und wer priorisiert, wenn Kundenerlebnis, Risiko und Regulierung miteinander konkurrieren?
Banking darf unsichtbar werden. Verantwortung nicht.
Autor: Abtin Maghrour
Banken haben kein Strategieproblem. Sie haben ein Umsetzungsfenster.
AI, Instant Payments, Open Banking, neue Plattformen, neue Regulierung: Banken wissen ziemlich genau, welche Themen relevant sind.
Die schwierigere Frage lautet, wie schnell sie daraus Realität machen können.
Denn Strategie trifft in der Umsetzung auf Legacy-Systeme, begrenzte Budgets, Provider-Abhängigkeiten, regulatorische Programme und knappe Fachressourcen.
Damit verschiebt sich der Wettbewerbsvorteil. Nicht unbedingt derjenige gewinnt, der die beste Idee zuerst hatte, sondern derjenige, der eine gute Entscheidung schnell und sauber umsetzen kann.
Der Imagefilm bringt diesen Punkt auf eine einfache Formel: Viele Strategien sind klar. Die Umsetzung ist es nicht.
Die spannendere Vorstandsfrage lautet deshalb vielleicht:
Welche unserer heute richtigen Entscheidungen können wir tatsächlich schnell genug umsetzen?
Autor: Jan Koppetsch
„Projektstatus: läuft.“ Das ist noch keine gute Nachricht.
Kritische Projekte scheitern selten über Nacht.
Entscheidungen werden vertagt. Termine verschoben. Neue Anforderungen aufgenommen. Risiken wandern von Steering zu Steering.
Trotzdem bleibt der Statusbericht erstaunlich lange grün oder gelb.
Das Problem: Aktivität ist nicht dasselbe wie Fortschritt.
Ein gutes Project Rescue beginnt deshalb nicht mit einem neuen Reporting. Sondern mit einem realistischen Blick auf die Lage:
Was ist wirklich fertig? Welche Entscheidung fehlt? Welche Annahme stimmt nicht mehr? Wo wächst der Scope? Und welche Risiken werden seit Monaten weitergeschoben?
Transparenz, Fokus und Umsetzung sind deshalb keine Schlagworte, sondern die Grundlage dafür, ein Projekt wieder steuerbar zu machen.
Ein Projekt muss nicht rot sein, um bereits in Schwierigkeiten zu stecken.
Autor: Johannes Rotter
Ein Projekt wird nicht gerettet, indem man den Plan schöner macht.
Wenn ein Projekt unter Druck gerät, wird häufig zuerst neu geplant.
Mehr Details. Neue Meilensteine. Mehr Reporting.
Nur löst ein besserer Zeitplan keine ungeklärten Entscheidungen, keinen wachsenden Scope und keine fehlenden Verantwortlichkeiten.
Project Rescue beginnt deshalb mit anderen Fragen:
Was müssen wir wirklich liefern?
Was können wir nicht gleichzeitig liefern?
Wer entscheidet?
Was muss aus dem Scope?
Was muss jetzt passieren?
Ein guter Rescue-Plan kann zunächst sogar schlechter aussehen als der alte. Er zeigt Risiken, setzt Grenzen und korrigiert unrealistische Erwartungen.
Das ist kein Rückschritt.
Ein Projekt ist nicht gerettet, wenn der Plan wieder grün ist. Sondern wenn er wieder lieferbar ist.
Autor: Jan Koppetsch
Was Kunden in kritischen Projekten wirklich kaufen: Klarheit.
Beratung wird gern über Frameworks, Methoden und Workshops beschrieben.
In kritischen Situationen brauchen Kunden häufig etwas Einfacheres:
Klarheit.
Was ist das eigentliche Problem? Welche Optionen gibt es? Welche Entscheidung muss jetzt getroffen werden? Und wer übernimmt anschließend?
Genau deshalb ist gute Beratung nicht die Kunst, Komplexität möglichst beeindruckend darzustellen.
Sie muss Komplexität so weit reduzieren, dass wieder gehandelt werden kann.
Was wissen wir?
Was wissen wir nicht?
Was ist jetzt relevant?
Was kann warten?
Gerade wenn Programme verspätet sind, Provider blockieren oder Entscheidungen festhängen, kann diese Klarheit wertvoller sein als die nächste Methodik.
Komplexität erklären ist leicht. Sie entscheidbar zu machen ist die eigentliche Arbeit.
Autor: Jan Koppetsch
Mehr Fraud Prevention macht Payments nicht automatisch sicherer.
Betrugsprävention soll Betrug verhindern. Klingt eindeutig.
In der Praxis kann ein System aber so restriktiv werden, dass auch gute Kunden ständig blockiert werden. Dann sinkt vielleicht das Risiko – gleichzeitig steigen False Positives, Kaufabbrüche und Beschwerden.Die bessere Frage lautet deshalb nicht: Wie viele Transaktionen stoppen wir? Sondern: Wie gut unterscheiden wir zwischen legitimen und betrügerischen Transaktionen? Dafür müssen Fraud, Payments, Risk, Operations und Technology zusammenspielen.
Gute Fraud Prevention verhindert nicht möglichst viel. Sie trifft möglichst oft die richtige Entscheidung.
Autor: Abtin Maghrour