Die teuerste Arbeit in Ihrer IT ist die langweiligste
Nicht das gescheiterte Projekt kostet am meisten, sondern die Routine dazwischen. Drei Werkzeuggenerationen haben sie verwaltet, besprochen und orchestriert. Erledigt hat sie niemand. Über die eigentliche Grenze von KI im Unternehmen.

Fragen Sie eine Geschäftsführung, wo Geld verloren geht, und Sie hören von gescheiterten Projekten, verpassten Aufträgen und teuren Fehlentscheidungen. Die ehrlichere Antwort steht in keinem Bericht: Es ist die Arbeit dazwischen. Anfragen aufnehmen, Systeme prüfen, Konten anlegen, Status weitergeben, Ergebnisse dokumentieren. Arbeit, die in keinem Lebenslauf steht und trotzdem jeden Tag stattfindet. In der IT zuerst, aber längst nicht nur dort.
Klein mal oft schlägt groß mal selten
Der Effekt ist ein Volumeneffekt, und er lässt sich messen. Über 40 Millionen Kundentickets haben wir inzwischen analysiert. Ein einzelnes Archiv haben wir vollständig offengelegt: 43.676 ServiceNow Incidents eines europäischen Fertigungskonzerns aus sechs Jahren. Dort standen die zehn häufigsten Fallarten für 48% des gesamten Volumens. Die mediane Lösungszeit lag bei 1,24 Tagen, auch für Fälle, die jeder Beteiligte auswendig kennt.
Der teuerste Posten ist also nicht der schwere Einzelfall. Es ist der einfache Fall, tausendfach. Dazu kommt der Teil, den keine Kennzahl erfasst: Jede dieser Kleinigkeiten unterbricht einen Menschen, der eigentlich an etwas Wichtigerem arbeitet. Die Minuten stehen im Ticket. Der zerrissene Nachmittag steht nirgends.
Drei Werkzeuggenerationen, ein gemeinsames Ende
An dieser Arbeit haben sich drei Generationen von Werkzeugen versucht.
Portale und ITSM Systeme haben sie erfasst und sortiert. Das war ein Fortschritt: Seitdem weiß man, wie viel liegen bleibt. Verwalten ist aber nicht erledigen.
Chatbots haben angefangen, über die Arbeit zu reden. Sie beantworten die Frage nach dem VPN Zugang mit einer Anleitung und lassen den Nutzer mit der Umsetzung allein. Das Ticket wurde vermieden, der Fall nicht.
Workflow Tools und Agent Builder orchestrieren die Arbeit: Sie erstellen Aufgaben, senden Benachrichtigungen, eskalieren pünktlich. Am Ende jeder dieser Ketten steht derselbe Moment: Ein Mensch öffnet ein System und erledigt den Schritt selbst.
Portale verwalten diese Arbeit. Chatbots reden über sie. Workflow Tools schicken Benachrichtigungen darüber. Erledigt hat sie bisher niemand.
Die Grenze ist nicht das Verstehen. Es ist das Ausführen.
Dass daran auch die meisten KI Projekte wenig geändert haben, liegt nicht an den Modellen. Sprachmodelle verstehen Anliegen längst gut genug: Sie erkennen, dass eine wirre Mail ein Offboarding beschreibt, und wissen, welche Angaben fehlen.
Was fehlt, ist die Schicht zwischen dem Modell und den echten Systemen eines Unternehmens. Die Schicht, die aus einem verstandenen Fall ausgeführte, geprüfte und dokumentierte Schritte macht: auf dem Server, auf dem Gerät, im Verzeichnisdienst, im Ticketsystem. Wir nennen sie die Ausführungsschicht, und sie ist der Grund, warum nara existiert.
Ausführung heißt dabei nicht, dass eine KI Texte in Eingabemasken tippt. Es heißt: Ein Agent nutzt definierte, freigegebene Werkzeuge mit typisierten Parametern, und jede Aktion hinterlässt einen Beleg.
Was das konkret bedeutet
Vier Beispiele aus echten Umgebungen.
Ein Agent installiert und aktualisiert Software direkt auf den Geräten, systemweit, still und protokolliert. Niemand verbindet sich per Fernwartung auf zweihundert Rechner.
Ein Austritt ist am Stichtag erledigt: Konto deaktiviert, Gruppen entzogen, Fristen überwacht, jeder Schritt im Ticket, bevor jemand fragt.
Ein hängender Dienst auf dem Druckserver wird auf der Maschine diagnostiziert und nach Freigabe neu gestartet. Das Ergebnis steht im Log, nicht im Kopf eines Administrators.
Ein Zugriff wird geprüft, vergeben und mit Begründung dokumentiert. Keine Blackbox, kein Zuruf auf dem Flur.
Kontrolle ist der Preis der Ausführung
Software auf fremden Geräten installieren und Konten deaktivieren: Das tut man nicht mit einem Prompt und gutem Willen. Wer Ausführung verspricht, muss Kontrolle beweisen.
Deshalb ist Kontrolle bei nara keine Richtlinie, sondern Architektur. Agenten nutzen nur Werkzeuge, die pro Agent freigegeben sind. Kritische Aktionen warten auf eine menschliche Freigabe. Rechte gelten bis auf die einzelne Ressource, und jede Aktion steht im Log, im Ticket und im Dashboard. Ausführung hinter der Firewall läuft ausschließlich über ausgehende Verbindungen, ohne dass sich am Perimeter etwas ändert.
Und es gibt Grenzen, die gewollt sind: Entscheidungen mit Ermessen bleiben bei Menschen. Der Agent bereitet sie vor und übergibt sie vollständig dokumentiert. Er trifft sie nicht.
Anfangen, wo das Volumen ist
Die langweilige Arbeit hat eine tröstliche Eigenschaft: Sie ist berechenbar. Welche Fälle sich zuerst lohnen, steht in Ihrer eigenen Ticket Historie, nicht in einer Anbieterfolie. Deshalb beginnt jede nara Einführung mit einer Analyse der echten Daten: Fallarten, Volumen, Lösungszeiten, Wissenslücken.
Der beste erste Prozess ist selten der spektakulärste. Es ist der, der jeden Tag vorkommt, klare Regeln hat und dessen Erledigung sich beweisen lässt. Wenn Sie wissen wollen, welcher das bei Ihnen ist: Bringen Sie den Prozess mit, der am meisten Zeit frisst. In 30 Minuten zeigen wir, welche Schritte nara übernimmt und womit Sie starten sollten.