gateway/docs/case-study-poweron-48h-agent.md
Stephan Schellworth ea566c270f docs: add gateway docs and Cursor plan artifacts
Made-with: Cursor
2026-04-22 07:21:43 +02:00

9.3 KiB
Raw Permalink Blame History

Case Study (Illustration / Template): PowerOn Launch48

Wichtig: Das primaere Kundenangebot zum Weitergeben ist poweron-launch48-offer.md verstaendlich fuer Management und Fachbereiche.
Dieses Dokument dient nicht als erstes Verkaufs-PDF: Es ist ein Beispiel-Verlauf / Pilot-Template zur Vertiefung, sobald Sie Referenzgeschichten brauchen. Alle Kundendaten, Branche und Kennzahlen sind fiktiv oder anonymisiert, bis ein reales Projekt mit schriftlicher Freigabe vorliegt.
Referenz fuer Liefermethodik: AI-augmented Engineering (vergleichbar der dokumentierten Abraxas DATA Hub Migration Kundennennung in oeffentlichen Materialien nur mit Freigabe).


Executive Summary

Ausgangslage (Beispiel): Ein mittelstaendisches Dienstleistungsunternehmen (anonymisiert) hatte wiederkehrende Kundenanfragen zu Vertrags- und Leistungsinhalten, die heute aus PDF-Handbuechern, E-Mail-Templates und internen Notizen manuell beantwortet werden. Die Bearbeitungszeit pro Anfrage war hoch, die Qualitaet von der Erfahrung der jeweiligen Person abhaengig.

PowerOn fuehrte mit dem Paket Launch48 einen 48-Stunden-Block auf der PowerOn-Plattform durch. Ergebnis (Zielbild des Templates): ein produktiv einsetzbarer KI-Assistent mit angebundenen internen Quellen, definierter Pilotgruppe und vereinbarten Erfolgszielen fuer die zweite Zahlungsstufe.

Kernresultat (Illustration): Von Kickoff bis Uebergabe 2 Arbeitstage intensiver Umsetzung; schneller Mehrwert im Pilot statt monatelanger Vorlauf; laufende Pruefung durch Ihre Fachexpertinnen und Experten fuer Qualitaet und Compliance.


Projekteckdaten

Aspekt Detail (Template / anonymisiert)
Kunde Anonymisiertes Dienstleistungsunternehmen, deutschsprachige Schweiz
Plattform PowerOn (Power Desktop / AI Workspace, Datenquellen, Automation)
Use-Case Erstbeantwortung und Strukturierung von wiederkehrenden Fachanfragen aus freigegebenen internen Unterlagen
Sprint-Dauer 48 Stunden gebundene Umsetzung (plus Vorlauf fuer Gates)
Umfang 1 Agent/Workflow, 3 Wissensquellen (Beispiel), 1 Integration (Beispiel: internes Ticket-Read)
PowerOn Team Patrick Motsch (Technische Leitung), Ida Dittrich (Architektur), Stephan Schellworth (Projektsteuerung)
Kunde Team Fach-Owner, IT-Ansprechpartner, 10 Pilotnutzer (Beispiel)

Die Herausforderung

Fachliche und technische Ausgangslage

  • Wissen verteilt in PDFs, geteilten Ablagen und persoenlichen Entwuerfen.
  • Kein einheitlicher Erstkontakt: Mitarbeitende formulieren Antworten neu Inkonsistenz und laengere Durchlaufzeiten.
  • Datenschutz: Kundenbezogene Details duerfen nicht in generische KI-Tools ohne Kontrolle.

Business Impact der Ausgangslage

  • Hoher Zeitaufwand pro Standardanfrage.
  • Skalierungsbremse bei Wachstum (Onboarding neuer Mitarbeitender).
  • Risiko unterschiedlicher Antwortqualitaet und laengerer Reaktionszeiten.

Der PowerOn-Ansatz

AI-Augmented Delivery auf der Plattform

PowerOn setzt auf Human-in-the-Loop: KI beschleunigt Aufbau und Iteration, Architektur und Freigaben bleiben beim erfahrenen Team und beim Kunden.

Kernprinzip: Schnelligkeit durch KI-gestuetzte Umsetzung, Qualitaet durch Reviews, Governance durch PowerOn-Faehigkeiten (Quellen, Rollen, nachvollziehbare Ablaeufe).

Phase 1: Use-Case & Impact (Vorlauf + Sprint-Start)

Aktivitaeten:

  • Priorisierung eines einzigen Kernprozesses.
  • Definition von 3 KPIs (z. B. Zeit pro Vorgang, Pilot-Zufriedenheit, Fehlerindikator).
  • Scope-Freeze fuer den Fixpreis.

Deliverables:

  • Schriftliche Scope- und KPI-Spezifikation.
  • Go/No-Go nach Compliance-Freigabe.

Phase 2: Wissensbasis

Aktivitaeten:

  • Anbindung von Handbuch-PDFs, FAQ-Dokument und freigegebenem SharePoint-Ordner (Beispiel).
  • Zuordnung zu Instanz-/Mandantenlogik gemaess Rollen.

Deliverables:

  • Indexierte Quellen im PowerOn-Workspace.
  • Kurz-Dokumentation, welche Inhalte nicht im Agent-Kontext liegen (Grenzen).

Phase 3: Tools & Anbindung

Aktivitaeten:

  • Eine Integration im vereinbarten Umfang: z. B. Lesen von Ticket-Metadaten fuer Kontext (kein Schreiben in Produktion im Template-Beispiel).
  • Festlegung von Freigaben und Testfaellen.

Deliverables:

  • Funktionsfaehiger Integrationspfad in der Pilotumgebung.
  • Testprotokoll (Grundfaelle).

Phase 4: 48h Build-Sprint

Aktivitaeten:

  • Gemeinsame Umsetzung mit Pairing (Kunde + PowerOn).
  • Iterative Tests mit realistischen Anfragen.
  • Runbook und Handover.

Deliverables:

  • Einsatzbereiter Agent/Workflow im Pilot.
  • Runbook + Enablement-Session.

Execution Das Herzstueck

  1. Strukturierte Zielvorgaben aus Phase 13.
  2. Plattformnahe Umsetzung (kein „einmaliger Skript-Hack“ ausserhalb des Betriebsmodells).
  3. Validierung durch Fach-Owner und Architektur-Review.
  4. Test mit Pilotnutzern vor KPI-Messfenster.

Effizienzgewinn (Illustration): Statt mehrwoechiger interner Experimentierphase entsteht in 48 Stunden ein abnahmefaehiger Pilot mit klarer Messgroesse.


Testing & Uebergabe

  • Pilotgruppe (z. B. 10 Nutzer) fuer 10 Arbeitstage nach Uebergabe.
  • Sammelfeedback und kleine Nachjustierungen im vereinbarten Rahmen (optional als Zusatzleistung klaeren).
  • Auswertung der Erfolgsziele zum vertraglichen Stichtag → Basis fuer die CHF 7000-Komponente von Launch48.

Enablement: Das Ziel ist Autonomie: Internes Team versteht Grenzen, Bedienung und Eskalationspfad analog zur Enablement-Philosophie bei groesseren PowerOn-Projekten (vgl. Wissenstransfer in der Abraxas-Methodendokumentation, sofern intern referenziert).


Business Impact (Illustrationsbandbreiten)

Hinweis: Zahlen erst mit echtem Projekt ersetzen.

Dimension Illustrative Aussage
Time-to-Value Produktiver Pilot in Tagen statt Monaten
Zeit pro Vorgang Ziel z. B. 2540 % Reduktion nach Baseline
Qualitaet Weniger Streuung durch einheitliche Wissensbasis
Risiko Weniger Shadow-AI durch freigegebene Plattform

Lessons Learned (generisch, aus Sprints dieser Art)

  1. Scope schlaegt Feature-Wunschliste ein scharfer Use-Case traegt KPIs.
  2. Gates sparen Zeit Compliance und Zugang vor dem Sprint klaeren.
  3. Human-in-the-Loop verhindert Halluzinationen im produktiven Kontext.
  4. Runbook ist Produkt ohne Dokumentation sinkt Adoption.
Herausforderung Loesung
Unklare Verantwortung Fach/IT Zwei benannte Owner von Tag 1
Zu grosse Wissensmenge Priorisierte Quellen, spaetere Erweiterung
Integration komplexer als gedacht Frueh Spike oder Scope auf „read-only“ reduzieren

Technische Details (Beispiel-Stack)

PowerOn:

  • Power Desktop / AI Workspace
  • Datenquellen (z. B. SharePoint, Uploads)
  • Automation / Workflow (je nach Use-Case)
  • Rollen und Sichtbarkeit gemaess Organisationsmodell

Optional erwaehnt im echten Case:

  • Spezifische Modelle/Provider nur nach Kundenfreigabe dokumentieren.

Projektorganisation

Meilenstein Zeit (Beispiel)
Kickoff & Gates Woche -1
Sprint Tag 1 z. B. Do
Sprint Tag 2 z. B. Fr
Handover Ende Tag 2
KPI-Messfenster 10 Arbeitstage
Auswertung Stichtag laut Vertrag

Verbindung zur Abraxas-Methodik (interner Verweis)

Die Abraxas DATA Hub Migration zeigte: strukturierte Analyse, Architekturentscheide mit Review, KI-gestuetzte Execution und Enablement liefern hohe Geschwindigkeit bei produktionsreifer Qualitaet. Launch48 uebertraegt diese Prinzipien auf kleinere, scharf umrissene KI-Piloten auf der PowerOn-Plattform mit Fixpreis und vereinbarten Erfolgszielen fuer die zweite Zahlungsstufe.

Oeffentliche Zitate oder Logos von Abraxas nur mit schriftlicher Freigabe.


Fazit

Launch48 macht aus einem konkreten Alltags-Engpass einen messbaren Piloten auf PowerOn schnell, mit klaren Leitplanken und ohne Monatsprojekt-Pflicht. Nach dem ersten echten Kundenprojekt: dieses Template durch verifizierte Kennzahlen, Zitate und freigegebenen Namen ersetzen.


  • Entscheid: Duerfen wir Abraxas als Referenz namentlich nennen?
  • Entscheid: Duerfen wir diesen Pilot-Kunden nennen?
  • Template-Kennzeichnung auf Website/PDF: „Beispielszenario“ bis zur Finalversion.
  • KPI-Formulierungen von Recht/Finance geprueft.
  • Screenshots nur mit anonymisierten Daten.

Referenzen