Ein guter Projektstart schafft Klarheit über die heutige Aufgabe, das gewünschte Ergebnis und die Grenzen der Automatisierung. Erst wenn Auslöser, Daten, Systeme und Verantwortlichkeiten bekannt sind, lässt sich eine passende technische Lösung auswählen.
Das Vorgehen muss nicht groß oder theoretisch sein. Ein realer Prozess, mehrere repräsentative Fälle und ein verantwortlicher Fachbereich reichen aus, um eine belastbare Analyse zu beginnen.
Vor dem Projekt: Problem und Ziel konkret beschreiben
Aussagen wie „Wir möchten KI einsetzen“ geben noch keine Richtung. Hilfreicher ist eine Beschreibung der wiederkehrenden Arbeit: Wer erhält welche Information, was wird damit getan und wo entstehen Wartezeit, Rückfragen oder Übertragungsarbeit?
- einen klar abgegrenzten Prozess benennen
- fachlich verantwortliche Mitarbeiter einbeziehen
- reale Eingaben und typische Ergebnisse sammeln
- beteiligte Programme und Datenquellen auflisten
- bekannte Sonderfälle und Fehlerfolgen dokumentieren
- gewünschte Veränderung ohne technische Vorfestlegung formulieren
Ein geeignetes Ziel formulieren
Ein brauchbares Ziel beschreibt den Prozesszustand, nicht eine Produktfunktion. Zum Beispiel: Eingehende Anfragen sollen mit vollständigen Pflichtangaben und klarer Zuständigkeit als Aufgabe vorliegen. Ob dafür Klassifikation, Formularlogik oder ein Assistent eingesetzt wird, entscheidet das Konzept.
Einen Prozessinhaber benennen
Der Prozessinhaber beantwortet fachliche Fragen, priorisiert Sonderfälle und nimmt Ergebnisse ab. Ohne diese Rolle bleiben Regeln häufig unentschieden und technische Umsetzung kann fachliche Verantwortung nicht ersetzen.
Die sieben Phasen eines KI-Automatisierungsprojekts
Der genaue Umfang variiert, doch eine klare Folge von Analyse, Umsetzung und kontrollierter Einführung verhindert, dass Technik und Fachprozess auseinanderlaufen.
Jede Phase erzeugt ein überprüfbares Zwischenergebnis und eine Entscheidungsgrundlage für den nächsten Schritt.
- Erstgespräch: Ziele, Probleme und Rahmenbedingungen verstehen
- Prozessanalyse: Aufgaben, Daten, Systeme und Verantwortlichkeiten aufnehmen
- Lösungskonzept: Automatisierung, Schnittstellen und Kontrollpunkte festlegen
- Entwicklung: den vereinbarten Umfang technisch umsetzen
- Testphase: reale Normal-, Sonder- und Fehlerfälle prüfen
- Einführung: Nutzer vorbereiten, dokumentieren und kontrolliert freischalten
- Betrieb: überwachen, korrigieren und gezielt erweitern
Zwischen den Phasen bewusst entscheiden
Eine Analyse kann ergeben, dass Daten fehlen, eine Schnittstelle ungeeignet ist oder ein einfacherer Regelprozess ausreicht. Dieses Ergebnis ist wertvoll: Es verhindert, dass ein Projekt trotz ungeklärter Grundlage in die Entwicklung wechselt.
Pilotumfang und Tests sinnvoll definieren
Ein Pilot ist keine unverbindliche Demonstration. Er sollte einen echten, aber begrenzten Teilprozess abbilden und klare Abnahmekriterien besitzen.
- welche Eingabekanäle und Fallarten enthalten sind
- welche Datenfelder erkannt oder erzeugt werden
- welche Systemaktionen erlaubt sind
- welche Ergebnisse immer geprüft werden
- wie Unsicherheit und technische Fehler behandelt werden
- wer fachlich und technisch abnimmt
Nicht nur ideale Beispiele testen
Testdaten sollten unvollständige E-Mails, ungewöhnliche Dokumente, Dubletten und widersprüchliche Angaben enthalten. Nur so zeigt sich, ob Übergaben und Fehlermeldungen auch außerhalb des Idealwegs funktionieren.
Menschliche Kontrolle konkret festlegen
„Ein Mitarbeiter prüft“ ist noch keine vollständige Regel. Es muss klar sein, welcher Mitarbeiter welchen Fall in welcher Oberfläche sieht, welche Informationen für die Entscheidung vorliegen und wie eine Korrektur zurück in den Prozess gelangt.
Konkretes Startbeispiel und Projektcheckliste
Ein Unternehmen wählt zunächst nur Anfragen aus seinem Websiteformular. Gemeinsam werden Pflichtangaben, Kategorien und Zuständigkeiten definiert. Die erste Version legt noch keinen Kunden automatisch an, sondern zeigt den vorbereiteten Datensatz zur Freigabe.
- eine Auswahl unterschiedlicher realer Beispielfälle fachlich sichten
- Kategorien, Pflichtfelder und Übergaberegeln festlegen
- Zugriff auf Formular und Testbereich des CRM prüfen
- vorbereitete Datensätze gegen erwartete Ergebnisse testen
- Sonderfälle sammeln und Regeln gezielt ergänzen
- erst nach Abnahme eine kontrollierte CRM-Übergabe aktivieren
Checkliste vor dem Erstgespräch
- kurze Beschreibung des heutigen Ablaufs
- Beispiele für typische und schwierige Fälle
- Liste der beteiligten Systeme und Ansprechpartner
- bekannte Datenschutz- oder Sicherheitsanforderungen
- gewünschtes Ergebnis und wichtige Kontrollpunkte
- Ideen für einen realistisch begrenzten Startumfang
Nach dem Start: beobachten statt vergessen
Prozesse, Eingaben und externe Schnittstellen ändern sich. Deshalb benötigt die Lösung Zuständigkeiten für Überwachung, Rückmeldungen und Anpassungen. Ein erfolgreicher Start ist der Beginn eines kontrollierten Betriebs, nicht das Ende der Verantwortung.
Häufige Fragen
Braucht man vor dem Erstgespräch bereits ein technisches Konzept?
Nein. Wichtiger sind ein konkreter Ablauf, reale Beispiele und das gewünschte Ergebnis. Die technische Architektur wird erst nach Prüfung von Systemen, Daten und Anforderungen festgelegt.
Sollte ein Projekt direkt mehrere Abteilungen umfassen?
Meist ist ein klar abgegrenzter Start leichter zu prüfen. Abhängigkeiten zu anderen Abteilungen sollten bekannt sein, der erste produktive Umfang kann dennoch auf einen Prozess oder eine Nutzergruppe begrenzt bleiben.
Wann kann der Automatisierungsgrad erweitert werden?
Wenn reale Tests zeigen, dass definierte Fälle zuverlässig erkannt werden und Ausnahmewege funktionieren. Jede zusätzliche Systemaktion oder Fallgruppe sollte erneut fachlich und technisch geprüft werden.