Value Discovery: Zeitfresser finden, messen und mit Claude Cowork abstellen

Die Dauern kommen von denen, die die Arbeit tun

Ein österreichisches KMU betreibt dieselben Prozesse wie ein Konzern, nur ohne eine Abteilung, die sie repariert. Der Bericht, der jeden Montag von Hand zusammengebaut wird. Das Angebot, das zwischen drei Systemen hin- und herkopiert wird. Die Rechnung, die aus dem Postfach in die Buchhaltung getippt wird. Jede dieser Stellen kostet Stunden, und keine davon steht in einem Budget.

Genau diese Stellen findet der Value-Discovery-Durchlauf. Er bewertet sie in Stunden pro Monat und weist den fünf wertvollsten eine Route zu. Die Route führt in den meisten Fällen zu Claude Cowork, das die bestehenden Firmen-Apps über eingepackte Schnittstellen erreicht. Den Cowork-Teil führt das Büro nach dem ersten Skill selbst weiter. Die Schnittstellen, die Apps mit Urteil und die Beförderung in den geregelten Betrieb sind unser Engineering. Was sein Ziel verfehlt, bleibt eine Aufgabe für Menschen, und auch das ist ein Ergebnis.

Die Zeitfresser stehen in den laufenden Systemen

Am Anfang steht eine Inventur dessen, was das Unternehmen bereits betreibt: welche Microsoft-365-Dienste im Tenant freigeschaltet sind, was Terminplanung, Fakturierung und Buchhaltung halten, welche Postfächer und Dateiablagen die Arbeitsdokumente tragen und welche Excel-Tabellen mit den Jahren zu Datenbanken geworden sind. Gelesen wird direkt aus den laufenden Systemen, am Tag, an dem die Arbeit beginnt.

Zwei Befunde kehren dabei regelmäßig wieder. Der erste sind Dienste, die auf der Rechnung stehen und nie geöffnet wurden. Sie decken Arbeit ab, die ohne neuen Kauf starten könnte. Der zweite sind Listen, die in Excel gepflegt und anderswo noch einmal abgetippt werden. Dort sammeln sich die manuellen Stunden, bevor irgendein Prozess bewertet wurde.

Die wiederkehrende Arbeit selbst wird aus denselben Quellen gehoben: aus dem Ticketsystem die Anfragen, die nach Plan eintreffen, aus Postfächern und geteilten Kalendern die Aufgaben mit festem Muster, aus den Fachanwendungen die Abläufe mit bekanntem Auslöser, aus den Tabellen die Arbeit, die regelmäßig kopiert wird. Eine Sitzung mit dem Büro bestätigt danach Häufigkeit und Aufwand je Position und schließt die Lücken. Die Liste entsteht aus den Systemen. Die Leute, die die Arbeit machen, prüfen sie.

Drei Messwerte, sechs Kriterien, ein KPI

Welcher Prozess nervt, ist eine andere Frage als welcher sich rechnet. Deshalb trägt jede Position drei Messwerte: wie oft sie im Monat läuft, wie viele Minuten ein Durchlauf braucht und wie viel Nacharbeit dahintersteckt. Alle drei lösen sich in Stunden pro Monat auf, und in dieser Einheit wird bis zum Ende gerechnet.

Dazu kommen sechs Eignungskriterien: Regelmäßigkeit, Eingangsdaten, Überprüfbarkeit, Fehlerfolgen, Systemzugang und Abnahmekriterien. Die Summe liegt zwischen 6 und 30. Am stärksten sortieren die Fehlerfolgen um. Ein falsches Ergebnis, das eine Gutschrift oder eine aufsichtsrechtliche Frage auslöst, kostet in der Eindämmung mehr, als die Automatisierung einspart. Aufgaben mit Personenbezug behalten ihren Platz und bekommen eine Prüfung angehängt.

Aus den Monatsstunden gegen die Eignungssumme entsteht eine Rangliste, und aus ihr werden genau fünf ausgewählt. Jeder bekommt ein Datenblatt: wer ihn ausführt, wer das Ergebnis abnimmt, die aktuellen Stunden pro Monat mit Datum und Quelle, ob gemessen oder geschätzt, und ein Ziel in derselben Einheit. Dieser Ausgangswert ist der KPI. Dieselbe Messung nach der Änderung zeigt, was sich bewegt hat.

Die Route folgt der Aufgabe

Neun Fragen laufen in fester Reihenfolge, der erste Treffer gewinnt. Ein unklarer Ablauf bekommt einen Planungsschritt. Arbeit, die in Outlook, Excel oder Teams lebt, nimmt die Microsoft-365-Route. Ein Portal ohne Schnittstelle geht in die Browser-Automatisierung. Ein fester Hausstandard wird zu einem Skill oder einem MCP-Connector. Weil die Fragen in Reihenfolge laufen, entscheidet die Aufgabe über die Route, und die Logik ist nachlesbar.

Auf der Cowork-Seite wird der Agent in dem Ordner eingerichtet, in dem die Dokumente liegen, mit einer Regeldatei für sein Verhalten und unter Versionskontrolle ab dem ersten Tag. Der erste Skill entsteht an einer Aufgabe, die jemand bereits jeden Montag erledigt: einmal von Hand mit der Person, der sie gehört, dabei mitgeschrieben, dann als Klartext-Datei abgelegt, die jeder lesen und ändern kann. Outlook, SharePoint, OneDrive, Kalender und Teams erreicht der Agent über Microsoft Graph mit delegierten Berechtigungen, als das Konto, für das er handelt. Er sieht nur, was diese Person auch ohne ihn öffnen darf.

Auf der Engineering-Seite bekommen die Systeme außerhalb des Tenants einen Connector. Eine bestehende REST-Schnittstelle, eine Datenbank oder ein interner Dienst wird als Model-Context-Protocol-Server eingepackt, mit Werkzeugen, die im Vokabular des Büros beschrieben sind, damit ein halb erinnerter Kunden- oder Gebäudename zum richtigen Datensatz führt. Das System dahinter bleibt, wie es ist. Terminplanung, geteiltes Postfach und die Tabelle, die zur Datenbank wurde, stehen so neben Microsoft 365 in einer Unterhaltung, und kein neues Abonnement kommt auf die Monatsrechnung.

Cowork ist der Einstieg, Engineering die Lieferung

Absichtlich ist der Cowork-Teil so gebaut, dass er ohne uns weiterläuft. Ein Skill ist eine Klartext-Datei im Firmenspeicher, unter Firmenkonten, und wer eine Prozedur ändern will, ändert einen Text. Der Übergabetest lautet: Jemand anderes führt den Montagsjob am Montag allein aus der Datei aus. Wer das einmal gesehen hat, braucht für den nächsten Skill keinen Berater mehr.

Was Beratung braucht, sind die Stellen dahinter. Das System, das keinen Connector mitbringt. Die App, die nicht mehr mithält: ein Update, das etwas gebrochen hat, eine Lizenz, die jedes Jahr steigt, ein Lieferantenportal, in das sich noch jemand von Hand einloggt. Und die Automatisierung, die ihren KPI erreicht hat und jetzt ohne Aufsicht laufen soll. Das ist Agentic Engineering, und so arbeiten wir dort.

Zuerst bekommt jede App ein Urteil: migrieren, erweitern oder ersetzen, mit Begründung und mit der Reihenfolge, in der die Apps drankommen. Aus dem, was läuft, kommen die Fakten dafür, im selben Durchlauf wie die Prozessbewertung. Als MCP-Server gebaut, hält ein Connector dem Modell kein Schreibwerkzeug hin. Das Werkzeug liefert ein Formular zurück, und erst das Formular schreibt den einen Datensatz ins führende System, nachdem eine Person bestätigt hat.

Mit Anmeldung, automatisierten Tests und einem sicheren Release-Prozess kommt jede Anwendung, die wir ausliefern. Das sind die Teile, die ein Konzern verlangt und die sonst niemand vorführt. Zwei Anwendungen haben im Juni 2026 in jeweils etwa drei Wochen die Produktion erreicht, mit allen dreien an Bord. Möglich ist das, weil der Großteil nicht neu gebaut wird: Jeder Build startet auf dem Produkt, mit dem wir unsere eigenen Bücher führen. Anmeldung, Navigation und Bildschirmaufbau sind dort gelöst. Ihre Rechnung deckt Ihre Anwendung, nicht das Fundament darunter.

Gehostet wird zu einem festen Monatspreis bei einem unabhängigen europäischen Anbieter, und ein Umzug zwischen Anbietern ist eine Konfigurationsänderung. Ein Kunde hat sechs Anwendungen in einem Fenster umgezogen, als die Cloud-Rechnung dem Budget davonlief.

Nachmessen, dann befördern

Zunächst läuft jeder Schreibzugriff auf ein laufendes System beaufsichtigt, mit einem Prüfschritt danach. Lesende Integrationen bleiben lesend. Frühestens vier Wochen nach dem Start wird der KPI mit derselben Methode nachgemessen, mit der der Ausgangswert entstand. Gemessen gegen gemessen, geschätzt gegen geschätzt. Die Zahl hat sich bewegt oder nicht, und das Datenblatt hält es fest.

Eine Automatisierung, die ihr Ziel erreicht, wird befördert: vom beaufsichtigten Cowork-Lauf zum geplanten Agententask, mit einem freigegebenen Modell je Anwendungsfall, jedem Aufruf samt Kosten im Protokoll und den Zahlen in einem eigenen Kontrollzentrum, das mit der ersten Integration ausgeliefert wird. Die Aufsicht wird pro Prozedur gelockert, auf Basis ihrer eigenen Läufe. Engineering-Arbeit ist auch die Beförderung selbst: Der Skill, den das Büro angestoßen hat, wird zu einem Lauf, der auf Firmenmaschinen zu einer Zeit startet, an der niemand am Rechner sitzt, und dessen Kosten pro Lauf am nächsten Morgen lesbar sind. Verfehlt eine Automatisierung ihr Ziel, geht die Aufgabe zurück an die Person, die sie vorher hatte. Dann hat der Durchlauf gezeigt, dass sie kein Kandidat war, bevor Geld dafür ausgegeben wurde.

Compliance läuft im selben Durchlauf mit

Die Prüfung nach DSGVO und EU AI Act läuft über den Bestand, wie er heute produktiv ist, bevor ein Modell Firmendaten berührt. Eine Architektur, die noch nicht existiert, lässt sich nicht bewerten. Heraus kommt ein Betriebskonzept mit EU-Hosting, die Datenschutzbedingungen je angebundenem Dienst und die praktische Differenz zwischen Team- und Enterprise-Lizenzbedingungen. Für ein kleineres Unternehmen zählt die Lizenzstufe mehr als der Sitzpreis, weil die Stufe festlegt, was mit Firmeninhalten geschehen darf, sobald sie übergeben sind.

Weil die rechtliche Frage zuerst beantwortet wird, ist die Phase gefahrlos abbrechbar. Nichts wird gekauft, installiert oder migriert. Es gibt kein Lizenzjahr, das verteidigt werden müsste.

Was auf dem Tisch liegt

Am Ende des Durchlaufs liegen vier Dinge vor: die bewertete Prozessliste mit je einer führenden Route, ein Datenblatt je ausgewählter Aufgabe mit ihrem KPI-Ausgangswert, eine Checkliste je Stakeholder-Rolle und die schriftliche Position zu DSGVO und EU AI Act. Diese vier sind dieselben, ob fünf durchkommen oder keiner.

Die Seite Value Discovery & Compliance beschreibt jeden Schritt von der Inventur bis zum unterschriebenen Datenblatt. Wer wissen will, ob die eigene Montagsaufgabe ein Kandidat ist und welche App dahinter ein Urteil braucht, bringt beides in ein kostenloses Erstgespräch von 30 Minuten mit.