„Wir schulen unser Team in Power Automate.“ Das klingt nach einem Plan. Aber was danach besser läuft, bleibt unklar.

Denn Automatisierungskompetenz ist keine homogene Größe. Sie besteht aus einzelnen, klar abgrenzbaren Fähigkeiten. Und wer nicht weiß, welche davon benötigt wird, kann auch nicht gezielt aufbauen was fehlt.

Das PCT-Modell macht genau das sichtbar.

Was PCT bedeutet

PCT steht für Process•Capability•Tool. Es ist ein Ableitungsmodell mit drei Ebenen:

Prozess (Was): Der fachliche Ablauf – was soll automatisiert werden? Ein Prozess lässt sich in Bausteine zerlegen. Wir unterscheiden sechs Typen, die in nahezu jedem Automatisierungskontext vorkommen:

• Datenerfassung & Strukturierung – Eingaben lesen, parsen, normalisieren
• Prüf- & Entscheidungslogik – Regeln auswerten, Bedingungen prüfen, Pfade wählen
• Kommunikation & Benachrichtigung – E-Mails, Benachrichtigungen, Statusmeldungen
• Workflow & Orchestrierung – Schritte koordinieren, Abhängigkeiten steuern, Ausnahmen behandeln
• Dokumentation & Ablage – Ergebnisse speichern, Dateien ablegen, Nachweise erzeugen
• Monitoring & Reporting – Laufende Prozesse beobachten, Auswertungen bereitstellen

Capability (Wie): Die technologische Fähigkeit, die ein Baustein erfordert. Nicht „Power Automate kennen“ – sondern konkret: „strukturierte Daten aus externen Quellen verarbeiten“, „regelbasierte Entscheidungslogik formulieren“, „asynchrone Benachrichtigungen auslösen“. Capabilities lassen sich benennen, erfassen und gezielt aufbauen.

Tool (Womit): Das passende Werkzeug ergibt sich aus den Capabilities – nicht umgekehrt. Wer weiß was er bauen muss und welche Fähigkeiten dafür gebraucht werden, findet das richtige Tool. Wer mit dem Tool anfängt, sucht danach Prozesse die dazu passen.

Das Besondere: strukturelle Ähnlichkeit über Prozessgrenzen hinweg

Hier liegt der eigentliche Hebel des PCT-Modells.

Zwei Prozesse, die fachlich völlig unterschiedlich wirken, können PCT-strukturell identisch sein. Das bedeutet: Sie bestehen aus denselben Baustein-Typen – und erfordern damit dieselben Capabilities und dieselbe technologische Antwort.

Ein Beispiel aus dem EVU-Kontext: Parkhaus-Begehung dokumentieren und Grünflächen-Kontrolle erfassen. Fachlich: zwei völlig verschiedene Aufgaben in verschiedenen Bereichen. PCT-strukturell: beide erheben Daten vor Ort, prüfen Kriterien, dokumentieren Ergebnisse, lösen bei Abweichung eine Benachrichtigung aus. Dasselbe Muster. Wer die eine Automatisierung gebaut hat, hat die andere bereits mindestens zur Hälfte – nicht theoretisch, sondern konkret über referenzierbare Bausteine.

Das multipliziert den Wert jedes aufgebauten Use Cases. Nicht nur „der zweite ist schneller als der erste“ – sondern: der fünfte Bereich profitiert von dem was der zweite Bereich gelernt hat, auch wenn er mit anderen Prozessen arbeitet.

Gezielter Kompetenzaufbau statt allgemeiner Schulung

Wer weiß welche Capabilities seine nächsten zehn Use Cases brauchen, kann konkret fragen: Was davon können wir? Was nicht? Wo ist die Lücke am größten?

Das verändert wie Lernen funktioniert. Nicht „alle lernen die Plattform von vorne bis hinten“ – sondern „diese zwei Personen lernen gezielt, wie man strukturierte Daten aus externen Quellen verarbeitet, weil das in sechs der nächsten zehn Use Cases vorkommt“.

Kompetenzaufbau der an echten Bedarfen hängt, ist schneller und bleibt länger. Weil die Fähigkeit sofort gebraucht wird.

Wiederverwendung als Beschleuniger

Das zweite Projekt ist schneller als das erste – aber nur wenn das Wissen aus dem ersten nicht verloren geht.

Eine sauber entwickelte und dokumentierte Capability ist mehr als ein paar fertige Flows. Sie ist ein Muster: wie geht man mit diesem Baustein um, was sind die Stolperstellen, wie wurde es in einem ähnlichen Use Case gelöst? Wer das hat, fängt beim nächsten Use Case nicht bei null an.

Das ist der Mechanismus hinter dem Versprechen „es wird schneller“. Nicht die Erfahrung allein – sondern die Erfahrung die explizit gemacht und zugänglich ist.

Schneller Einschätzung neuer Use Cases

Wenn ein neuer Use Case eingebracht wird, lässt sich mit einem PCT-Mapping sofort einschätzen: Welche Bausteine braucht er? Haben wir die Capabilities dafür? Was fehlt?

Aus „keine Ahnung ob das geht“ wird „das braucht Capability X und Y – X haben wir, Y noch nicht, ein bis zwei Tage Einarbeitung“. Und aus „das sieht neu aus“ wird „das haben wir strukturell schon zweimal gebaut – im Personalbereich und im technischen Betrieb“.

Der Übergang von Bauchgefühl zu handwerklicher Einschätzung. Er funktioniert nur wenn Capabilities explizit erfasst sind.

Wie das in der Praxis aussieht

Eine Use Case Galerie die Capabilities erfasst, macht das alles möglich. Jeder Eintrag enthält nicht nur den Prozess – sondern auch die Bausteine und die benötigten Capabilities. Das erlaubt Auswertungen, die sonst nicht möglich sind.

Welche Capabilities brauchen unsere nächsten zehn Use Cases? Welche davon beherrschen wir bereits? Wo gibt es strukturelle Muster die sich über Bereiche hinweg wiederholen?

myFlow•Studio ist unser Werkzeug dafür: Use Cases strukturiert erfassen, mit PCT-Ebenen verknüpfen, Kompetenzstand und Wiederverwendbarkeit sichtbar machen – für alle die Automatisierungspotenziale einbringen wollen, nicht nur für IT.

Der eigentliche Hebel

Prozess → Capability → Tool

Nicht als Methode für sich – sondern als Grundlage dafür, dass Automatisierung in einer Organisation wirklich lernfähig wird. Dass strukturelle Ähnlichkeiten sichtbar werden die sonst verborgen bleiben. Dass das zehnte Projekt tatsächlich auf den ersten neun aufbaut – und nicht jedes Mal von vorne anfängt.

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