Alfred  ·  Pilotkundenprogramm
Vorab zu klären — vor Projektstart
Diese drei Punkte müssen mit dem IT-Verantwortlichen des Kunden geklärt sein, bevor wir loslegen.
Organisatorische Genehmigungen
Demo-Rechner ins Netzwerk
Genehmigung, unseren Laptop ans interne Netzwerk anzuschließen (WLAN oder LAN). Bei NAC / 802.1x: MAC-Adresse whitelisten oder Gastnetz mit Zugang zu den Zielanwendungen.
Selbstentwickelte Chrome-Extension
Genehmigung, eine nicht aus dem Web Store stammende Extension zu installieren. Für den Pilot genügt Developer Mode in Chrome. Die Extension kommuniziert ausschließlich mit dem internen Alfred-Server — keine externen Verbindungen.
Zugang zur Testumgebung
Bestehende Test-/Staging-Instanz der Zielanwendung benennen oder bereitstellen. Entwicklung und Schulung finden ausschließlich gegen Testdaten statt — niemals gegen Live.
Die drei Phasen
Sequenziell — jede Phase liefert eine klare Übergabe an die nächste.
A
System einrichten
Woche 1 · ~12–22 h
B
Mitarbeiter schulen
Woche 2–3 · ~3–6 h
C
Testphase
Woche 3–8 · laufend
Phase A
System einrichten
Server-Hardware / VM bereitstellen IT Kunde
OS, Docker, Compose installieren Wir 2–4 h
Ollama + Modell + Alfred deployen Wir 2–3 h
Testumgebung anbinden & prüfen Wir 2–4 h
Extension auf Pilot-PCs einrichten Wir 1–2 h
Smoke-Test (Chat-UI, LLM, Extension) Wir 1–2 h
Kick-off & Anwendungs-Inventory Wir + Kunde 2 h

Gesamt (unsererseits) ~12–22 h
Phase B
Mitarbeiter schulen
Recorder-Schulung (1–3 Schlüsseluser) Wir 1,5 h
Endnutzer-Schulung (pro Gruppe à 10) Wir 0,5 h
Erste Workflows gemeinsam aufnehmen Wir + Kunde 2–4 h
Schulungsunterlagen übergeben Wir

Gesamt (unsererseits) ~3–6 h
Phase C
Testphase
Workflows gegen Testumgebung validieren Wir + Kunde 3–7 h / WF
Fehler & Selektor-Anpassungen Wir 2–4 h / Woche
Abnahme & Freigabe für Live Wir + Kunde 1–2 h
Weekly Check-in Wir 0,5 h / Woche

Begleitbetrieb (4 Wochen) ~12–32 h
Gesamtaufwand — 5 Workflows
Richtwerte für einen Piloten mit 5 Workflows und 5–10 Nutzern.
Phase Umfang Aufwand (wir)
A — System einrichten Server, Extension, Testumgebung 12–22 h
B — Schulung Recorder + Endnutzer, 5 WF aufnehmen 18–41 h
C — Testphase 4 Wochen Begleitbetrieb 12–32 h
Gesamt Realistisch ca. 50–60 h 42–95 h
Testumgebung — zwingend erforderlich
Workflows werden immer zuerst gegen Testdaten entwickelt und validiert. Niemals gegen Live.
Mögliche Testumgebungen
Test-/Staging-Instanz
Bestehende Testinstanz der Zielanwendung. Idealfall — Kundenseitig meist vorhanden.
Anonymisierte Kopie
Snapshot mit geschwärzten/gefakten Daten. Gut wenn keine separate Instanz existiert.
Mock-Anwendung
Unsere mitgebrachte Mock-CRM für erste Schulungen und Demos. Kein Zugang zur Zielanwendung nötig.
Dedizierter Test-Account
Separater User in Live-System mit Test-Datensätzen. Minimalvariante — Vorsicht bei schreibenden Aktionen.
Ohne Testumgebung kein Pilot. Das ist kein Komfort-Feature, sondern Grundvoraussetzung für sicheres Arbeiten. Direkt im Kick-off klären.
Risiken & Mitigation
Risiko Eintritt Impact Mitigation
IT blockt Extension-Install mittel hoch IT früh einbinden; Developer Mode als Fallback; ADMX-Template vorbereiten
Keine Testumgebung vorhanden mittel hoch Blockiert Phase B; im Kick-off als Hard-Requirement kommunizieren
Zielanwendung ändert Selektoren hoch mittel Workaround-Flag in Recordings; Fehler-Overlay bei Replay
SSO / MFA des Kunden komplex mittel hoch Auth-Flow in Phase A früh testen; Session-Awareness ggf. vorziehen
Nutzer-Akzeptanz fehlt mittel niedrig Schlüsseluser von Anfang an einbeziehen; Quick-Win-Workflows priorisieren