Es gab einen erfolgreichen Piloten. Das Management will Tempo. Die Entscheidung fällt: ausrollen auf den Rest der Organisation, andere Teams, andere Abteilungen. Was in einer Ecke funktionierte, muss jetzt überall funktionieren.
Das geht bei weitem nicht immer gut. Nicht weil die Technologie plötzlich anders reagiert, sondern weil die Umgebung, in der sie funktionieren muss, überall anders eingerichtet ist. Das Team, bei dem der Pilot gelang, hatte zufällig eine IT-Infrastruktur, die dem gewachsen war, was gefordert wurde, ein Datenmanagement, das auf Ordnung war, und eine Organisationsstruktur, in der jemand Verantwortung übernahm. Anderswo in der Organisation steht es um eine oder mehrere dieser Dinge anders. Das Ergebnis: derselbe Aufwand bringt an einer Stelle etwas und an einer anderen Stelle nichts, oder schlimmer, zusätzliche Arbeit, um Fehler zu beheben.
Skalieren fühlt sich wie der nächste Schritt an, weil der Pilot etwas bewiesen hat. Es gibt ein Ergebnis, es gibt Begeisterung, es gibt Druck, die Rendite zu erhöhen. Wer einmal etwas funktionieren ließ, will es nicht auf ein Team beschränkt lassen. Zudem ist Skalieren sichtbar: mehr Nutzer, mehr Teams, mehr Prozesslinien, die die neue Arbeitsweise aufgreifen. Das fühlt sich wie Fortschritt an, auch wenn die fundamentalen Dimensionen — Organisation, IT-Infrastruktur, Datenmanagement — noch nicht überall auf dem Niveau stehen, auf dem die Dimension, die von ihnen abhängig ist, tatsächlich laufen kann.
Die Reihenfolge, in der dies funktioniert, ist nicht optional. Steht die fundamentale Ebene nicht, hat die abhängige Ebene nichts, worauf sie aufbauen kann. Das ist keine Frage der Vorliebe oder davon, sich mehr Zeit zu nehmen; es ist die Art, wie die Dimensionen einander tragen. Skalieren ignoriert diese Reihenfolge und erwartet, dass die Wiederholung einer Arbeitsweise ausreicht, auch ohne die Grundlage, die beim ersten Mal zufällig vorhanden war.
Einige Signale kehren häufig wieder. Teams, die die neue Arbeitsweise übernehmen, berichten von unterschiedlichen Ergebnissen, und niemand kann gut erklären, warum es bei dem einen Team funktioniert und bei dem anderen nicht. Es wird nach mehr Training oder mehr Kommunikation gefragt, während das Problem anderswo liegt: in Systemen, die nicht aufeinander abgestimmt sind, in Daten, die nicht dieselbe Qualität haben, in einer Struktur, in der niemand Eigentümer des Ergebnisses über Teamgrenzen hinweg ist.
Erkennbar ist auch die Situation, in der Technologie über eine Struktur ausgerollt wird, die sich selbst nicht mitverändert hat: die neue Arbeitsweise wird technisch verfügbar gemacht, aber die Rollen, Verantwortlichkeiten und Entscheidungslinien sind dieselben geblieben wie vor dem Piloten. Vergleichbar ist das Muster, in dem ein Pilot in seiner eigenen Ecke gut funktioniert, aber nicht an den Rest der Organisation anschließt: die Skalierung kopiert die Arbeitsweise, nicht die Bedingungen, unter denen diese Arbeitsweise entstand.
Ein drittes Signal ist weniger sichtbar, aber ebenso ausschlaggebend: zwei Enthusiasten ziehen den Karren, und sonst fühlt sich niemand verantwortlich. Solange die Initiative von ein paar Leuten abhängt, die zufällig motiviert sind, gibt es keine organisatorische Grundlage, um zu skalieren — es gibt nur Begeisterung, die sich nicht vervielfacht, sobald das Team größer wird.
Wer diese Signale erkennt, tut gut daran, sich zu fragen, ob die Streuung zwischen Teams eine Folge der Ausführung ist oder eines Unterschieds in der Bereitschaft, der längst vorhanden war, bevor skaliert wurde. Diese Unterscheidung ist genau das, worauf die Reifegradmessung von hybridresourcing schaut: nicht auf eine Punktzahl für die gesamte Organisation, sondern auf fünf Niveaus über sieben Dimensionen, gemessen dadurch, dass mehrere Menschen einzeln bewerten und die Streuung zwischen ihren Antworten sichtbar wird. Diese Streuung sagt oft mehr aus als der Durchschnitt: Unterscheidet sich die Einschätzung des CEO grundlegend von der des CIO, liegt darin ein Teil der Erklärung, warum Skalieren an einer Stelle greift und an einer anderen nicht. Was ein CEO in dieser Messung über die eigene Organisation zeigt und was ein COO darin aus der täglichen Ausführung erkennt, ergeben selten dasselbe Bild, und genau dieser Unterschied ist das, worauf die Messung aufgebaut ist.
Diese Seite handelt von der Frage, ob die Organisation KI tragen kann: steht die Struktur, steht die Infrastruktur, steht das Datenmanagement auf einem Niveau, auf dem Skalieren sinnvoll ist. Das ist eine andere Frage als die, welcher Teil der Arbeit selbst geeignet ist, an KI übertragen zu werden. Diese letzte Frage beantwortet der Werkscan von FTE TO AI: der berechnet pro Aufgabe, welcher Teil der Arbeit von KI übernommen werden kann, unabhängig davon, ob die Organisation dafür schon bereit ist. Beide Fragen gehören zusammen, aber die Reihenfolge ist nicht beliebig — zu wissen, was übertragbar ist, hat wenig Wert, solange nicht feststeht, ob die Grundlage diese Übertragung tragen kann.
Die Reifegradmessung von hybridresourcing wird noch gebaut. Wer die Messung nutzen möchte, sobald sie verfügbar ist, kann sich für die Warteliste anmelden.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.