Ein Competence Center Automation & KI (CC) klingt nach einer neuen großen Org-Einheit und nach viel Konzeptarbeit. Dabei ist es eine pragmatische Hybrid-Organisation, um verschiedene Zielsetzungen durch ein organisatorisches Modell zu realisieren.

Das Ziel, eine solche Struktur aufzubauen, ist richtig. Der Einstieg ist oft nicht so leicht …

Was ein CC eigentlich ist

Ein CC Automation & KI ist kein zentrales IT-Team das alle Automatisierungen baut. Es ist eine Hybridstruktur: eine kleine zentrale Einheit – manchmal eine Person, manchmal ein kleines Team – kombiniert mit verteilten Rollen in den Fachbereichen.

Die zentrale Einheit verantwortet Methode, Plattform und Standards. Sie baut Kompetenz auf, pflegt das Wissen der Organisation und sorgt dafür dass Erfahrungen nicht verloren gehen. Die Fachbereiche bringen die Inhalte: Sie kennen ihre Prozesse, identifizieren Potenziale und übernehmen mit der Zeit Verantwortung für die Automatisierungen in ihrem Bereich.

Das Modell ist hybrid weil es zwei Logiken verbindet: zentrale Steuerung dort wo Konsistenz wichtig ist – Plattform, Qualität, Wissensmanagement – und dezentrale Verantwortung dort wo fachliches Wissen sitzt.

Was ein funktionierendes CC konkret tut:

– Use Cases identifizieren – strukturiert, bereichsübergreifend, priorisiert nach Aufwand und Nutzen

– Umsetzung begleiten oder selbst umsetzen – je nach Kompetenzlevel in den Fachbereichen

– Wissen sichern – Use-Case-Galerie pflegen, Muster dokumentieren, Erfahrungen übertragbar machen

– Fachbereiche befähigen – nicht schulen im Sinne von Kursen, sondern durch gemeinsames Arbeiten an echten Prozessen

– Plattform und Standards verantworten – damit das fünfte Projekt nicht wieder von vorne beginnt wie das erste

Das ist handhabbar. Auch für eine Organisation, die jetzt erst damit anfängt.

Das Problem mit dem CC als Startpunkt

Ein Competence Center ist eine Struktur. Und Strukturen sind dazu da, etwas zu skalieren das bereits funktioniert. Wer eine CC-Struktur aufbaut bevor klar ist was skaliert werden soll, baut ein leeres Gebäude.

In der Praxis sieht das dann häufig so aus: Es wird ein Team benannt, ein Budget definiert, vielleicht eine Plattform ausgewählt. Es startet der ganz große Bahnhof – alle werden wuschig gemacht, viel wird versprochen. Am besten auch erstmal ganz viele Leute geschult. Dann kommt die entscheidende Frage – und sie kommt zu spät: Welche Prozesse automatisieren wir eigentlich?

Wenn diese Frage erst nach der Strukturentscheidung kommt, wird sie durch die Struktur beantwortet. Es werden Prozesse automatisiert, die zum Team passen, zur Plattform passen, zum Budget passen – nicht Prozesse die den größten Hebel haben.

Der wirksamere Einstieg

Sucht erst mal alle Prozesse die sich automatisieren lassen“ – das klingt logisch. Funktioniert aber in der Praxis nicht. Denn wer noch nie eine Automatisierung gesehen hat, kann sich kaum vorstellen, was möglich ist und wie es in den Grundzügen funktioniert. Es fehlt schlicht das „Gesicht“ der Automatisierung.

Der wirksamere Einstieg sieht anders aus:

Einen Bereich finden der Lust hat. Nicht den größten, nicht den schwierigsten. Einen Bereich, wo die Mitarbeitenden neugierig sind und mitmachen wollen. Das Mindset lässt sich später noch entwickeln – am Anfang hilft es, mit denen zu starten, die bereits offen sind.

Dort 2-3 Use Cases umsetzen – schnell und einfach. Nicht das komplexeste Problem lösen. Etwas das in wenigen Tagen läuft und einen echten Unterschied macht. Das Ziel in dieser Phase ist nicht Vollständigkeit, sondern Glaubwürdigkeit.

Von dort aus in den nächsten Bereich. Wieder 2-3 Use Cases, wieder Fokus auf schnelle Umsetzbarkeit. Wer sieht, dass es im Nachbarbereich funktioniert, entwickelt eine ganz andere Vorstellung davon was bei einem selbst möglich wäre.

Erst wenn diese Basis steht – laufende Prozesse, Menschen die es erlebt haben, erste Glaubwürdigkeit im Unternehmen – macht es Sinn zu systematisieren. Dann versteht die Organisation worum es geht. Und dann trägt die Struktur auch etwas.

Der Quick-Check fällt schon in den Aufgabenbereich des CC

Der Einstieg, den wir empfehlen, ist bewusst klein: ein strukturierter Prozess, um Automatisierungspotenziale in einem oder mehreren Fachbereichen zu identifizieren. Das Werkzeug heißt Quick-Check und es unterstützt die strukturierte Bestandsaufnahme: dabei geht es weniger um die vielen Details als eher um den Überblick und das zukünftige Nachverfolgen von Automatisierungspotenzialen.

Keine IT-Kenntnisse nötig. Kein Projektbudget. Keine Plattformentscheidung.

Das Ergebnis ist ein priorisierter Use-Case-Pool: konkrete Ansatzpunkte, bewertet nach Aufwand und Nutzen, Pain-Points, verständlich formuliert für alle Beteiligten.

Erst auf dieser Basis lohnt es sich über Struktur zu sprechen. Denn dann weiß man, was die Struktur tragen soll.

Was das bedeutet für die CC-Planung

Ein Competence Center, das auf einem soliden Use-Case-Pool aufbaut, hat von Anfang an klare Prioritäten. Es arbeitet nicht im Leerlauf, es hat keine Legitimationsprobleme, und es kann messbar zeigen, was es tut. Es ist aus unserer Sicht die kürzeste Route zu einer CC-Struktur, die tatsächlich funktioniert.

Und noch etwas: Wer den Quick-Check-Prozess einmal durchläuft, merkt schnell, dass die Fähigkeit zur Use-Case-Identifikation selbst ein zentraler Baustein eines Competence Centers ist. Strukturen, die das nicht können, skalieren nicht.

Zur Einordnung

Competence Center Automation & KI sind das richtige Modell, um Automatisierung dauerhaft in einer Organisation zu verankern.

Aber der Weg dorthin beginnt mit Inhalten, nicht mit Struktur. Wer den Einstieg richtig setzt, baut kein leeres Gebäude. Er baut eines das von Anfang an weiß was es beherbergen soll – und das die Organisation Schritt für Schritt mitzieht statt vor vollendete Tatsachen zu stellen.

Wie sich ein CC organisiert und wie er in der Organisation wirkt, das haben wir in unserem Blogbeitrag „The new Kitt on the Block“ beschrieben.

myFlow begleitet Organisationen dabei, Automatisierung als systematische Fähigkeit aufzubauen – nicht als Projekt.