115 Fragen, die uns Geschäftsführung und IT-Leitung wirklich stellen.

Ein KI-Agent ist ein Programm, das einen Vorgang von Anfang bis Ende übernimmt. Er arbeitet dabei so, wie es jemand aus dem Team tun würde. Ein Beispiel: Er liest eine eingehende Bestellung und prüft sie gegen Stammdaten im ERP. Dann legt er den Auftrag an und meldet nur die Fälle, bei denen etwas nicht passt. Anders als ein Chatbot wartet er nicht auf Fragen. Er arbeitet Aufgaben ab und nutzt dafür Werkzeuge wie SAP, Dynamics 365 oder SharePoint. Dazu hat er eine eigene Identität mit klar begrenzten Rechten. Bei Haavest laufen Agenten vom ersten Tag an in der echten Umgebung des Kunden. Dort bleiben sie auch im Regelbetrieb. Mehr dazu unter KI-Agenten.

Ein Chatbot antwortet auf Fragen. Ein KI-Agent erledigt Aufgaben. Der Chatbot sagt Ihnen, wie Sie eine Gutschrift anlegen. Der Agent legt sie an und prüft vorher die Rechnung. Liegt der Betrag über der Freigabegrenze, holt er sich die Zustimmung eines Menschen. Technisch heißt das: Der Agent hat Zugriff auf Systeme und eine eigene Identität. Er führt ein Protokoll seiner Schritte. Und er hat eine Logik, die mehrere Schritte nacheinander plant und ausführt. Ein Chatbot braucht davon nichts, weil er nach der Antwort fertig ist.

Microsoft 365 Copilot ist in erster Linie ein Assistent für Menschen. Er hilft beim Schreiben einer Mail, fasst ein Teams-Meeting zusammen oder sucht ein Dokument. Das macht er immer dann, wenn jemand ihn gerade bittet. Copilot lässt sich inzwischen auch mit Agenten erweitern. Sein Kern bleibt aber die Hilfe für einzelne Personen. Ein KI-Agent arbeitet dagegen ohne Zuruf und hat dafür eigene Berechtigungen in den Fachsystemen. Er geht zum Beispiel jede Nacht um drei über alle neuen Lieferscheine. Beides ergänzt sich gut: Copilot macht einzelne Personen schneller, Agenten übernehmen ganze Vorgänge. Viele Unternehmen, mit denen wir sprechen, starten mit Copilot. Nach einigen Monaten merken sie, dass die wiederkehrenden Prozesse davon nicht verschwinden. Genau dort setzen Agenten an.

Mehr dazu bei Microsoft: Überblick über Microsoft 365 Copilot

RPA (Robotic Process Automation) klickt vorgegebene Pfade in Oberflächen nach. Sieht eine Maske anders aus oder weicht ein Dokument vom Muster ab, bricht es ab. Ein KI-Agent versteht dagegen den Inhalt. Er liest auch die Rechnung, bei der der Lieferant das Layout geändert hat. Was zu tun ist, entscheidet er anhand von Regeln und Kontext. Dafür ist er nicht hundertprozentig deterministisch. Deshalb gehören Freigaben, Protokoll und Testfälle zum Bau dazu. In der Praxis lösen Agenten viele brüchige RPA-Bots ab. Für rein mechanische Schritte bleibt ein klassischer Workflow oft die bessere Wahl.

Steht jeder Schritt vorher fest und sind die Eingaben sauber strukturiert, reicht ein Workflow in Power Automate oder Logic Apps. Der ist günstiger und leichter zu prüfen. Sobald der Vorgang Verstehen braucht, kommt ein KI-Agent ins Spiel. Das betrifft etwa unstrukturierte Mails, Dokumente in wechselnden Formaten oder Entscheidungen mit Ermessensspielraum. Häufig kombinieren wir beides: Der Workflow transportiert, der Agent liest, prüft und entscheidet. Am Ende schreibt wieder ein Workflow ins ERP.

Gut kann er: Dokumente lesen und einordnen, Daten zwischen Systemen abgleichen und Standardfälle nach Regeln entscheiden. Außerdem schreibt er Entwürfe für Antworten oder Angebote und legt Menschen gezielt die Ausnahmen vor. Schlecht kann er Entscheidungen ohne klare Kriterien. Ebenso schlecht sind Vorgänge, bei denen jeder Fehler sofort teuer wird. Und alles, wofür die Daten im Unternehmen gar nicht vorliegen. Im Assessment sagen wir Ihnen offen, welche Ihrer Vorgänge in die erste Gruppe fallen. Erfahrungsgemäß sind das mehr, als die meisten erwarten. Es sind aber weniger, als manche Anbieter versprechen.

Ja, Sprachmodelle können Dinge erfinden. Ein Agent ohne Absicherung würde das irgendwann auch tun. Deshalb bekommt der Agent bei uns keine freie Hand. Er darf nur Werkzeuge mit definierten Ein- und Ausgaben nutzen. Jede Zahl muss aus einer Quelle stammen, die im Protokoll steht. Schreibvorgänge im ERP laufen gegen Prüfregeln. Dazu kommen Testfälle aus echten Vorgängen, die vor jedem Update durchlaufen. So bleibt vom Halluzinieren im Regelbetrieb eine messbare Fehlerquote übrig. Diese lässt sich mit der Fehlerquote der manuellen Arbeit vergleichen.

Zuerst fällt der Fehler auf, weil jeder Schritt protokolliert ist. Bei Unsicherheit übergibt der Agent an einen Menschen, statt zu raten. Dann wird der Vorgang korrigiert wie bei einem Tippfehler im Team. Wir schauen uns an, ob die Ursache ein fehlender Testfall, eine Lücke in den Regeln oder ein Datenproblem war. Für den Ernstfall gibt es einen Not-Aus, mit dem der Fachbereich den Agenten sofort anhält. Im Monatsbericht sehen Sie die Fehlerquote in Zahlen und nicht als Gefühl.

Der Agent bereitet vor. Der Mensch entscheidet dort, wo es darauf ankommt. Welche Fälle das sind, legt der Fachbereich fest. Zum Beispiel alle Gutschriften über 5.000 Euro oder alle Neukunden. Oder alles, bei dem der Agent seine eigene Sicherheit als niedrig einschätzt. Die Freigabe landet dort, wo die Person ohnehin arbeitet: meist in Teams oder Outlook. Ein Klick genügt für Ja, Nein oder Ändern. Nach einigen Wochen Regelbetrieb kann man die Grenzen anhand der Zahlen anpassen. Oft geht es dann nach oben, weil das Vertrauen gewachsen ist.

In unseren Projekten übernehmen Agenten den Teil der Arbeit, über den sich vorher alle beschwert haben: Abtippen, Abgleichen, Nachfragen, Weiterleiten. Die Menschen bleiben. Sie bekommen die Ausnahmen, die Kundengespräche und die Entscheidungen. Also das, wofür man sie eingestellt hat. Ehrlich ist auch: In Teams mit 80 Prozent Routine verändert sich der Zuschnitt der Stellen. Das gehört früh auf den Tisch, auch mit dem Betriebsrat. Wir haben noch kein Unternehmen erlebt, das wegen eines Agenten Stellen abgebaut hat. Die Arbeit, die liegen blieb, war immer größer.

Montagmorgen, 80 Bestellungen als PDF im Sammelpostfach. Bisher hat sie jemand bis mittags in SAP abgetippt. Der Agent liest jede Bestellung und gleicht Kunde, Artikelnummern und Preise mit den Stammdaten ab. Dann legt er den Auftrag an. Bei zwölf Bestellungen stimmt etwas nicht, etwa ein unbekannter Artikel oder ein abweichender Preis. Genau diese zwölf bekommt die Sachbearbeitung um 8:15 Uhr in Teams vorgelegt. Dazu kommen der Vorschlag des Agenten und ein Klick zur Entscheidung. Um neun ist der Posteingang leer. Am Monatsende steht im Bericht, wie viele Aufträge der Agent angelegt hat. Dort steht auch, wie oft ein Mensch eingegriffen hat.

Nein. Die meisten Agenten, die wir bauen, haben gar keine. Sie werden von Ereignissen ausgelöst und melden sich nur, wenn sie eine Entscheidung brauchen. Auslöser sind etwa eine neue Mail, ein Zeitplan oder ein Eintrag im ERP. Wo Menschen mit dem Agenten sprechen sollen, nutzen wir Microsoft Teams. Es ist schon da, und niemand muss ein neues Programm lernen. Eine Chat-Oberfläche ist also eine Option, nicht der Kern.

Mit einem konkreten Vorgang, der heute Zeit frisst. Eine Strategie für alles braucht es dafür nicht. Suchen Sie den Prozess, bei dem jemand regelmäßig Daten aus Dokumenten oder Mails in ein System überträgt. Zählen Sie dann, wie viele Stunden pro Woche das sind. Mit diesem einen Vorgang kommen Sie zu uns ins Erstgespräch oder direkt ins kostenlose Kurz-Assessment. Danach wissen Sie, ob es sich lohnt und was es braucht. Alles Weitere ergibt sich aus dem ersten Agenten heraus. Das gilt etwa für Datenplattform oder Governance.

Das Kurz-Assessment ist unser Einstieg ohne Rechnung. Gemeinsam mit Ihrem Fachbereich und Ihrer IT wählen wir einen Vorgang aus. Wir schauen uns die beteiligten Systeme und Daten an. Dann prüfen wir, ob ein Agent dort zuverlässig arbeiten kann. Zuerst geht es um den Vorgang und die Zahlen dahinter. Dann um Zugänge, Daten und Berechtigungen. Zum Schluss folgt ein erster Durchstich mit echten Beispielen. Am Ende bekommen Sie eine schriftliche Einschätzung mit Aufwand, Nutzen und Risiken. Sie entscheiden frei, ob und mit wem Sie weitermachen. Anfragen gehen über Kontakt. Es antwortet jemand aus unserem Team, der auf Ihren Bereich spezialisiert ist.

Ein guter erster Vorgang hat vier Eigenschaften. Erstens kommt er oft vor, mindestens einige Dutzend Mal pro Woche. Zweitens sind die Regeln bekannt, auch wenn sie nur im Kopf einer erfahrenen Person stehen. Drittens liegen die Daten in Systemen, auf die man zugreifen kann. Viertens ist ein Fehler korrigierbar und nicht katastrophal. Typische Kandidaten sind Bestellerfassung, Rechnungsprüfung, Angebotsvorbereitung und Reklamationen. Auch das Nachpflegen von Stammdaten gehört dazu. Was sich als Erstes nicht eignet: der komplizierteste Prozess im Haus, den noch niemand sauber beschrieben hat.

Das hängt weniger vom Agenten ab als von Ihrem Haus. Die Dauer für Ihren Vorgang nennen wir Ihnen nach dem Kurz-Assessment. Der Weg ist immer derselbe: Assessment, Bau, Test mit echten Vorgängen, schrittweise Übergabe an den Fachbereich. Am längsten dauert meist nicht die Agentenlogik. Es sind Zugänge, Berechtigungen und Datenqualität. Genau das klären wir deshalb im Assessment zuerst. Weitere Agenten gehen schneller, weil Identitäten, Protokoll und Betrieb dann schon stehen.

Für das Assessment brauchen wir drei Dinge. Erstens eine Person aus dem Fachbereich, die den Vorgang wirklich macht. Sie sollte etwa zwei Stunden pro Woche Zeit haben. Zweitens eine Ansprechperson aus der IT für Zugänge und Fragen zur Umgebung. Drittens 20 bis 50 echte Beispielfälle, gern anonymisiert. Ein Microsoft-365-Tenant und eine Azure-Subscription sind hilfreich, aber nicht Voraussetzung. Beides lässt sich einrichten. Was wir nicht brauchen: eine fertige Prozessdokumentation oder eine Datenplattform.

Der Fachbereich ist der Auftraggeber. Er kennt den Vorgang, liefert die Beispiele und legt die Freigabegrenzen fest. Am Ende beurteilt er, ob der Agent gute Arbeit macht. Die IT stellt die Umgebung und vergibt Identität und Rechte des Agenten. Sie prüft Sicherheit und Datenschutz. Später übernimmt oder begleitet sie den Betrieb. Wir sitzen dazwischen, übersetzen in beide Richtungen und bauen. Projekte mit nur einer der beiden Seiten am Tisch scheitern meist in der Übergabe. Deshalb bestehen wir von Anfang an auf beiden.

Für den ersten Agenten nicht. Er arbeitet direkt mit den Systemen, in denen der Vorgang heute stattfindet. Das sind etwa SAP, Dynamics 365 oder ein Postfach. Eine Datenplattform wie Microsoft Fabric wird in drei Fällen wichtig. Wenn mehrere Agenten dieselben Daten brauchen. Wenn der Agent Auswertungen über viele Quellen machen soll. Oder wenn Sie ohnehin Ihre Berichtswelt neu aufstellen. Bei vielen Kunden entsteht die Plattform nach dem zweiten oder dritten Agenten. Dann zeigt sich, welche Daten wirklich gebraucht werden. Mehr unter Datenplattform.

Der Agent entsteht von der ersten Woche an in der Umgebung des Kunden. Er hat eine echte Identität, echte Berechtigungen und echte Daten. Zunächst arbeitet er nur für einen Teil der Fälle oder mit Freigabe für alles. Regelbetrieb heißt dann nicht Umzug. Es heißt: Die Freigabegrenzen werden angehoben, und der Monatsbericht beginnt. So entfällt die Lücke, in der nach unserer Erfahrung die meisten KI-Projekte stecken bleiben.

Das Plattform-Assessment ist für Unternehmen, die ihre Daten- und Berichtswelt auf Microsoft Fabric aufbauen wollen. Es passt auch, wenn Sie dorthin migrieren wollen. Wir sichten Quellen, bestehende Reports, Datenmodelle und Nutzung. Dann schätzen wir Kapazität und Aufwand. Sie bekommen einen Zielentwurf mit Reihenfolge und Risiken. Der Preis steht vorher fest, egal wie viele Fragen unterwegs auftauchen. Das Ergebnis ist eine Entscheidungsgrundlage, mit der Sie auch ohne uns weiterarbeiten können.

30 Minuten per Teams oder Telefon. Sie sprechen mit jemandem aus dem Team, der sich mit Ihrem Thema auskennt. Sie erzählen, welcher Vorgang oder welches Datenthema Sie beschäftigt. Wir stellen Fragen und sagen Ihnen offen, ob wir das für sinnvoll halten. Dazu nennen wir den nächsten Schritt. Es gibt keine Präsentation und keinen Pitch. Termin über Kontakt.

Die Antwort kommt von jemandem aus unserem Team, der Ihre Frage wirklich beantworten kann. Dafür nehmen wir uns die Zeit, die eine ehrliche Antwort braucht.

Das hängt von drei Dingen ab. Wie viele Systeme muss der Agent anbinden? Wie sauber sind die Daten dort? Und wie viele Ausnahmen hat der Vorgang? Ein Agent für Bestellungen aus Mails in ein gepflegtes Dynamics 365 ist deutlich günstiger. Teurer ist einer, der Verträge aus 15 Jahren Dateiablage auswertet. Deshalb nennen wir den Preis nach dem Kurz-Assessment als Festpreis für den Bau. Dazu kommt eine Monatspauschale für den Betrieb, wenn Sie ihn nicht selbst übernehmen. Hinzu kommen laufende Kosten bei Microsoft für Modelle und Rechenleistung. Die stehen im Monatsbericht in Euro.

Weil eine Zahl ohne den Vorgang dahinter entweder falsch oder nichtssagend wäre. Was wir stattdessen zusagen: Das Kurz-Assessment ist kostenlos. Der Bau eines Agenten und das Plattform-Assessment laufen zum Festpreis. Der Betrieb läuft als Monatspauschale. Sie wissen also vor jeder Entscheidung, was sie kostet. Wir gehen dabei in überschaubaren Schritten vor, jeder mit eigenem Festpreis. Das ist sicher für beide Seiten.

Der Festpreis gilt für ein klar beschriebenes Leistungspaket. Ein Beispiel: ein Agent für die Bestellerfassung, angebunden an Postfach und SAP. Dazu gehören Freigaben in Teams, Protokoll und Übergabe an Ihr Team. Was im Angebot steht, liefern wir für diesen Betrag. Eine gute Schätzung braucht genug Wissen über den Vorgang. Deshalb tasten wir uns heran und arbeiten in Schritten statt in einem großen Paket. Jeder Schritt hat seinen eigenen Festpreis. Das ist sicher für beide Seiten. Wollen Sie unterwegs etwas Zusätzliches, sprechen wir darüber. Wir schreiben es dann mit neuem Festpreis dazu. Die Grundlage für den ersten Schritt ist das Assessment.

Enthalten sind Überwachung des Agenten und Reaktion bei Fehlern und Ausfällen. Dazu kommen Updates von Modellen und Bibliotheken sowie die Pflege der Testfälle. Kleine Anpassungen an Regeln und Freigabegrenzen sind ebenfalls dabei. Einmal im Monat gibt es einen Bericht in Zahlen: Vorgänge, Eingriffe, Fehlerquote, Kosten bei Microsoft. Dazu kommen offene Rückfragen, Änderungen im Monat und unsere Empfehlung für den nächsten. Nicht enthalten sind die Microsoft-Kosten selbst, denn die laufen über Ihren Vertrag. Auch größere Erweiterungen sind nicht enthalten. Sie wären wieder ein Festpreis. Laufzeit und Kündigung regeln wir in Ihrem Vertrag. Mehr unter Managed Services.

Auf der Nutzenseite stehen die Stunden, die heute in den Vorgang fließen, mal dem Stundensatz. Dazu kommen die Fehlerkosten und Durchlaufzeiten, die sich verändern. Ein Rechenbeispiel: 80 Bestellungen am Tag zu je vier Minuten Erfassung sind über fünf Stunden täglich. Das sind etwa 1.200 Stunden im Jahr. Auf der Kostenseite stehen Festpreis, Monatspauschale und Microsoft-Kosten. Diese schätzen wir im Assessment. Trägt sich der Agent nicht innerhalb von zwölf bis 18 Monaten, raten wir meist ab. Oder wir schlagen einen anderen Vorgang vor.

Er lohnt sich, wenn ein Vorgang häufig vorkommt und Zeit kostet. Vor allem dann, wenn ihn heute qualifizierte Menschen erledigen. Die hätten eigentlich Besseres zu tun. Er lohnt sich nicht, wenn der Vorgang nur ein paar Mal im Monat anfällt. Ebenso wenig, wenn jeder Fall anders ist. Oder wenn die Daten so verstreut sind, dass erst eine Datenplattform nötig wäre. Die brächte für sich allein noch keinen Nutzen. Im Assessment rechnen wir das gemeinsam durch. Ein Nein gehört zu den möglichen Ergebnissen.

Im Wesentlichen drei Posten. Erstens die Modellaufrufe in Microsoft Foundry, abgerechnet nach verarbeitetem Text. Zweitens die Rechenleistung für den Agenten selbst, etwa in Azure Container Apps. Drittens je nach Aufbau Speicher oder eine Fabric-Kapazität. Nehmen wir einen einzelnen Agenten mit einigen hundert Vorgängen am Tag. Dafür liegt das in der Regel im Bereich einer zweistelligen bis niedrigen dreistelligen Summe pro Monat. Exakte Zahlen hängen von Dokumentlänge und Modellwahl ab. Wir setzen Budgets und Warnungen in Azure. Der Monatsbericht weist die Kosten je Agent aus.

Mehr dazu bei Microsoft: Bereitstellungstypen für Foundry-Modelle

Ja. In Deutschland, Österreich und der Schweiz gibt es Programme für Digitalisierung und KI im Mittelstand. Sie laufen auf Bundes- und Landesebene. Teils gibt es Zuschüsse für Beratung, teils für Umsetzung. Die Programme und Bedingungen ändern sich häufig. Deshalb nennen wir hier bewusst keine Beträge. Im Erstgespräch sagen wir Ihnen, welche Programme zu Ihrem Vorhaben und Ihrem Bundesland aktuell passen könnten. Wir liefern auch die Projektbeschreibung, die ein Antrag braucht. Die Antragstellung selbst bleibt bei Ihnen oder Ihrer Steuerkanzlei.

Microsoft unterstützt über Partner wie uns bestimmte Vorhaben. Dazu gehören etwa Workshops zu Data & AI, Pilotphasen auf Azure oder Migrationen nach Fabric. Zeitweise gibt es dafür finanzierte Leistungen oder Azure-Guthaben. Welche Programme gerade laufen, prüfen wir gern konkret. Ebenso, ob Ihr Unternehmen die Voraussetzungen erfüllt. Denn die Bedingungen ändern sich jedes Halbjahr. Als Microsoft Solutions Partner für Data & AI haben wir Zugang zu diesen Programmen. Verlassen würden wir uns bei der Planung darauf nicht. Aber oft hilft es beim Start.

Nichts. Das Assessment ist für Sie kostenlos. Es gibt auch keine Verpflichtung, danach mit uns weiterzuarbeiten. Wir machen das, weil wir am Ende ein Angebot zum Festpreis abgeben wollen. Dafür müssen wir den Vorgang wirklich kennen. Was es Sie kostet, ist die Zeit Ihres Teams: etwa zwei Stunden pro Woche aus dem Fachbereich und einige Stunden aus der IT.

Durch Grenzen von Anfang an. Jeder Agent hat ein Budget in Azure mit Warnung bei 80 Prozent. Die Modellwahl richtet sich nach der Aufgabe und nicht nach dem Größten, was verfügbar ist. Lange Dokumente werden vor dem Modellaufruf auf das Nötige reduziert. Im Monatsbericht stehen die Kosten je Agent und je Vorgang. So sehen Sie schon vor der Rechnung, wenn ein Agent teurer wird. Bei Fabric gilt dasselbe für die Kapazität. Wir starten sie gern klein und vergrößern sie erst bei Bedarf. Wichtig zu wissen: Ein Azure-Budget warnt nur und hält keine Ressource an. Deshalb braucht jede Warnung jemanden, der reagiert.

Mehr dazu bei Microsoft: Budgets in Azure Cost Management

Mit dem Microsoft-Stack, den Ihre IT schon kennt. Microsoft Foundry liefert Modelle und Auswertung. Das Microsoft Agent Framework enthält die Agentenlogik. Azure Container Apps ist die Laufzeit, Entra ID verwaltet die Identitäten. Für Daten nutzen wir Dataverse oder Fabric. Wo Menschen beteiligt sind, ist Teams die Oberfläche. Alles läuft in Ihrer Azure-Subscription und Ihrem Microsoft-365-Tenant. Der Code liegt in Ihrem Repository. Wo es sinnvoll ist, nutzen wir Open-Source-Bausteine. Eine proprietäre Haavest-Plattform, die Sie an uns bindet, gibt es nicht.

Mehr dazu bei Microsoft: Was ist Microsoft Foundry?

Microsoft Foundry ist Microsofts Plattform für den Zugriff auf Sprachmodelle und die Werkzeuge drumherum. Dazu gehören Modellkatalog, Auswertung, Sicherheitsfilter, Protokollierung und Bereitstellung. Für Unternehmen zählen zwei Dinge. Die Modelle können in Azure-Rechenzentren laufen, etwa in Deutschland oder Schweden. Und es gelten Microsofts Unternehmensbedingungen: keine Nutzung Ihrer Daten für das Training. Wo eine Anfrage tatsächlich verarbeitet wird, entscheidet der Bereitstellungstyp. Global kann in jeder Azure-Region rechnen. Data Zone EU bleibt in der EU, Standard in der gewählten Region. Wir nutzen Foundry als Modellzugang für unsere Agenten. Außerdem laufen dort die Tests, mit denen wir Qualität über Modellversionen hinweg vergleichen.

Mehr dazu bei Microsoft: Bereitstellungstypen für Foundry-Modelle

Das Modell, das zur Aufgabe passt, nicht das, das gerade in den Nachrichten ist. Über Microsoft Foundry stehen die Modelle von OpenAI, Anthropic, Mistral, Meta, DeepSeek und weiteren bereit. Dazu kommen kleinere Modelle für einfache Klassifikationen. Die sind schneller und günstiger. Ein Agent kann für verschiedene Schritte verschiedene Modelle nutzen. Zum Beispiel ein kleines zum Sortieren und ein großes zum Prüfen eines Vertrags. Der Modellwechsel ist bei uns kein Umbau. Er ist eine Konfiguration, die gegen die Testfälle läuft.

Mehr dazu bei Microsoft: Überblick über Microsoft Foundry Models

Das Microsoft Agent Framework ist ein quelloffenes Framework von Microsoft. Damit baut man Agenten, unter anderem in Python und .NET. Es regelt, wie ein Agent Werkzeuge aufruft und mehrere Schritte plant. Es regelt auch die Zusammenarbeit mit anderen Agenten und das Protokoll. Das Framework ist der direkte Nachfolger von Semantic Kernel und AutoGen und führt beide zusammen. Für Sie bedeutet das: Der Code Ihrer Agenten ist Standard und läuft bei Ihnen. Jedes Team, das Python oder .NET beherrscht, kann ihn weiterentwickeln. Nicht nur wir.

Mehr dazu bei Microsoft: Microsoft Agent Framework im Überblick

Agenten laufen lange und warten auf Ereignisse. Manchmal brauchen sie Minuten für einen Vorgang. Das passt besser zu einem Container als zu einer kurzlebigen Funktion. Container Apps kann bei null Last auf null Replikate herunterskalieren. Dann fallen keine Nutzungskosten an. Es bringt Identität über Entra mit und protokolliert nach Azure Monitor. Einen Kubernetes-Betrieb braucht es nicht. Haben Sie schon ein AKS-Cluster, können Sie den gleichen Container auch dort betreiben. Die Entscheidung ist pragmatisch, nicht dogmatisch.

Mehr dazu bei Microsoft: Skalierungsregeln in Azure Container Apps

Ein Dataverse Agent ist ein KI-Agent, der seine Daten in Microsoft Dataverse hält und von dort aus arbeitet. Dataverse ist die Datenbank hinter Dynamics 365 und der Power Platform. Sinnvoll ist das, wenn Ihre Vorgänge ohnehin in Dynamics 365 Sales oder Customer Service laufen. Dann hat der Agent Tabellen, Berechtigungen und Prüfregeln schon vor sich. Er muss nichts doppelt halten. Business Central hat eine eigene Datenbank. Es lässt sich über virtuelle Tabellen an Dataverse anbinden. Wir bauen solche Agenten oft als Ergänzung zu Copilot Studio. Das lohnt sich, wenn die eingebauten Möglichkeiten nicht mehr ausreichen. Mehr unter Dynamics 365 und Power Platform.

Mehr dazu bei Microsoft: Was ist Microsoft Dataverse?

Ja, und das ist unser Standardweg, wenn Menschen beteiligt sind. Freigaben kommen als Karte in Teams. Die Karte zeigt die Daten des Vorgangs und Knöpfe für die Entscheidung. Rückfragen des Agenten erscheinen im Chat. Wer will, kann dem Agenten dort auch Aufträge geben. Niemand muss eine neue Oberfläche lernen. Die Berechtigungen kommen aus Entra, also aus derselben Anmeldung wie für alles andere. Für Teams ohne Microsoft 365 geht auch Outlook oder ein Webformular.

Microsoft Fabric ist Microsofts Datenplattform. Sie bringt Datenintegration, Lakehouse, Warehouse, Echtzeitdaten und Power BI unter ein Dach. Alles nutzt einen gemeinsamen Speicher, den OneLake. Für Agenten ist Fabric der Ort, an dem bereinigte Daten aus SAP, Dynamics und anderen Quellen liegen. So muss der Agent nicht in jedem System einzeln suchen. Er sieht dieselben Zahlen wie die Berichte. Wer schon Power BI nutzt, hat den ersten Schritt zu Fabric meist schon gemacht. Mehr unter Datenplattform.

Mehr dazu bei Microsoft: Was ist Microsoft Fabric?

OneLake ist der zentrale Speicher von Microsoft Fabric, einer pro Tenant. Darin liegen Tabellen in den offenen Formaten Delta Parquet oder Iceberg. Lakehouse, Warehouse und Power-BI-Modelle im Direct-Lake-Modus greifen auf denselben Speicher zu. Deshalb müssen Daten nicht mehr zwischen Werkzeugen kopiert werden. Mit Shortcuts lassen sich Daten einbinden, ohne sie zu verschieben. Das geht aus Azure Data Lake Storage, Amazon S3, Google Cloud Storage oder Dataverse. Azure-Databricks-Kataloge lassen sich spiegeln. Für Sie heißt das vor allem: ein Ort, ein Format. Und die Daten bleiben lesbar, auch wenn Sie Fabric irgendwann verlassen.

Mehr dazu bei Microsoft: Was ist OneLake?

Direct Lake ist ein Speichermodus, mit dem Power BI Daten direkt aus Delta-Tabellen im OneLake lädt. Die Daten müssen vorher nicht in ein Modell importiert werden. Es geht auch nicht bei jedem Klick eine Abfrage an eine Datenbank. Das verbindet die Geschwindigkeit des Import-Modus mit der Aktualität von DirectQuery. Statt eines langen nächtlichen Refreshs genügt ein kurzes Framing. Es verweist nur auf die neuesten Dateien. Direct Lake braucht eine Fabric-Kapazität und hat Grenzen. Dazu gehören Leitplanken je Kapazitätsgröße und eingeschränkte berechnete Spalten. In der Variante über den SQL-Endpunkt gilt zusätzlich: Abfragen auf Views oder Tabellen mit SQL-Zeilensicherheit fallen auf DirectQuery zurück. Deshalb prüfen wir im Plattform-Assessment, welche Berichte sich dafür eignen. Andere sind im Import-Modus besser aufgehoben.

Mehr dazu bei Microsoft: Direct Lake im Überblick

Ihnen, vollständig. Der Code liegt in Ihrem Repository, der Agent läuft in Ihrer Azure-Subscription. Die Daten liegen in Ihrem Tenant, die Identität des Agenten ist in Ihrem Entra. Während des Projekts haben wir Zugang, den Sie jederzeit entziehen können. Nach der Übergabe haben wir nur noch den Zugang, den Sie für den Betrieb wünschen. Kein Lock-in, auch nicht bei uns. Sie können jederzeit mit Ihrem eigenen Team oder einem anderen Partner weitermachen. Die Dokumentation ist dafür geschrieben.

Ja, lesend wie schreibend. Dafür nutzen wir die Wege, die SAP vorsieht: OData-Services, BAPIs über den SAP Connector oder bei S/4HANA die freigegebenen APIs. Der Agent bekommt einen eigenen technischen Benutzer. Der hat genau die Rechte, die der Vorgang braucht. Jeder Schreibvorgang ist im SAP-Änderungsbeleg und im Agentenprotokoll nachvollziehbar. Für Auswertungen über große Datenmengen holen wir die Daten lieber nach Fabric. So belasten wir SAP nicht mit Abfragen. Mehr dazu unter Data Engineering.

Sie können es sein, wenn man sie entsprechend baut. Automatisch sind sie es nicht, nur weil Microsoft draufsteht. Entscheidend sind vier Punkte. Erstens werden die Daten in Ihrem Tenant in der EU gespeichert und verarbeitet. Die Bereitstellung muss dabei die Verarbeitung in der EU halten. Zweitens gibt es eine Rechtsgrundlage und einen Zweck für jede Verarbeitung. Drittens sieht der Agent nur die Daten, die der Vorgang braucht. Viertens ist jeder Schritt protokolliert und löschbar. Für Microsoft Foundry regelt das Data Protection Addendum aus den Microsoft-Produktbedingungen die Auftragsverarbeitung durch Microsoft. Wir liefern die technische Dokumentation für Ihren Datenschutzbeauftragten. Er braucht sie für die Prüfung und gegebenenfalls für eine Datenschutz-Folgenabschätzung.

Mehr dazu bei Microsoft: Datenschutz für Modelle in Microsoft Foundry

In Ihrem Microsoft-Tenant und Ihrer Azure-Subscription, in der Region Ihrer Wahl. In der Regel ist das Germany West Central in Frankfurt oder Sweden Central. Mit der EU Data Boundary sagt Microsoft zu, Kundendaten für Azure und Microsoft 365 in der EU zu speichern und zu verarbeiten. Dafür gibt es wenige dokumentierte Ausnahmen. Für die Modellaufrufe in Microsoft Foundry kommt es zusätzlich auf den Bereitstellungstyp an. Bei Global kann eine Anfrage in jeder Azure-Region verarbeitet werden. Deshalb nutzen wir Data Zone EU oder Standard in einer EU-Region. Nichts liegt bei Haavest: Wir haben keine eigenen Server mit Kundendaten. Entziehen Sie uns den Zugang, sehen wir nichts mehr. Der Agent läuft dann weiter.

Mehr dazu bei Microsoft: Was ist die EU Data Boundary?

Nein. Für die Modelle, die Microsoft in Foundry selbst anbietet, gelten Microsofts Unternehmensbedingungen. Das schließt Azure OpenAI ein. Eingaben und Ausgaben werden nicht zum Training der Modelle genutzt. Sie werden nicht an OpenAI oder andere Modellanbieter weitergegeben und nicht mit anderen Kunden geteilt. Das unterscheidet den Unternehmensweg von öffentlichen Chat-Diensten mit privaten Konten. Dort kann das je nach Einstellung anders sein. Für die Missbrauchserkennung kann Microsoft auffällige Ein- und Ausgaben in Ihrer Azure-Geografie speichern und prüfen lassen. Wer das ausschließen muss, kann eine geänderte Missbrauchsüberwachung beantragen. Nutzen Ihre Beschäftigten heute solche Dienste? Dann ist ein betrieblicher Agent übrigens auch aus Datenschutzsicht der sicherere Weg.

Mehr dazu bei Microsoft: Datenschutz für Modelle in Microsoft Foundry

Der EU AI Act stuft KI-Systeme nach Risiko ein. Die meisten Agenten für Bestellungen, Rechnungen oder Dokumente fallen in die Gruppe mit geringem Risiko. Sie brauchen vor allem Transparenz und Dokumentation. Hochrisiko-Anwendungen haben deutlich mehr Pflichten. Das betrifft etwa Personalentscheidungen oder Kreditvergabe. Dort raten wir, mit Juristen zu arbeiten, bevor ein Agent gebaut wird. Für alle Unternehmen gilt seit 2025 eine Schulungspflicht: Beschäftigte, die mit KI arbeiten, müssen ausreichend geschult sein. Ein Agenteninventar und ein Protokoll bauen wir ohnehin auf. Beides ist die Grundlage, um Auskunft geben zu können. Die rechtliche Bewertung bleibt bei Ihrer Rechtsberatung.

In Deutschland in den meisten Fällen ja. Ein Agent kann Vorgänge einzelner Beschäftigter protokollieren oder Freigaben zuordnen. Dann gilt er als technische Einrichtung, die Leistung oder Verhalten überwachen könnte. Das löst nach dem Betriebsverfassungsgesetz Mitbestimmung aus. Unsere Erfahrung: Wer den Betriebsrat zu Beginn des Assessments einlädt, bekommt eine Betriebsvereinbarung schnell. Wer ihn erst vor dem Go-live informiert, verliert viel Zeit. Wir liefern die Beschreibung des Agenten, der Daten und des Protokolls. Und zwar in einer Form, die in eine Vereinbarung passt. Gern sitzen wir auch mit am Tisch.

Er braucht zunächst eine Beschreibung des Vorgangs und seines Zwecks. Dazu eine Liste der verarbeiteten Datenkategorien und Systeme sowie die Angabe der Azure-Region. Hinzu kommen die Verträge und Produktbedingungen von Microsoft zur Auftragsverarbeitung. Außerdem ein Berechtigungskonzept für die Agentenidentität und die Beschreibung von Protokoll und Löschfristen. Bei Bedarf kommen die Unterlagen für eine Datenschutz-Folgenabschätzung dazu. Das alles entsteht bei uns im Projekt und ist kein Zusatzdokument. Wir laden den Datenschutzbeauftragten zum Start des Assessments ein. So kommen die Fragen früh und nicht erst beim Go-live.

Jeder Agent bekommt eine eigene Identität in Microsoft Entra ID, so wie jede neue Person im Team. Statt eines Passworts nutzt er eine verwaltete Identität oder ein Zertifikat. Daran hängen genau die Berechtigungen, die der Vorgang braucht: Lesen im Postfach, Anlegen von Aufträgen in SAP, nicht mehr. Ihre IT sieht den Agenten im Entra-Inventar. Sie kann die Rechte jederzeit ändern oder entziehen. Conditional Access für Workload Identities braucht eine Workload-ID-Premium-Lizenz. Es gilt nur für Service Principals Ihres Tenants, nicht für verwaltete Identitäten. Für KI-Agenten bietet Microsoft Entra Agent ID inzwischen eigene Agentenidentitäten. Jeder Agent arbeitet bei uns mit seiner eigenen Identität.

Mehr dazu bei Microsoft: Conditional Access für Workload Identities

Jeder Vorgang mit Zeitpunkt, Auslöser und gelesenen Daten. Dazu die aufgerufenen Werkzeuge, Zwischenergebnisse und die Entscheidung. Außerdem die beteiligte Freigabeperson und das Ergebnis. Ebenso die verwendete Modellversion und die Kosten des Aufrufs. Das Protokoll liegt in Ihrem Azure Monitor oder Log Analytics. Dort gelten die Aufbewahrungsfristen, die Ihr Datenschutz vorgibt: je Tabelle einstellbar bis zu zwölf Jahre. Das Protokoll ist die Grundlage für Monatsbericht, Fehlersuche und Auskunftsersuchen. Was wir nicht protokollieren: Inhalte, die der Vorgang nicht braucht.

Mehr dazu bei Microsoft: Aufbewahrung in Log Analytics verwalten

Ein Schalter, mit dem der Fachbereich den Agenten sofort anhält. Dafür muss niemand die IT anrufen, und es geht nichts kaputt. Praktisch ist das ein Befehl in Teams oder ein Knopf in einer kleinen Verwaltungsoberfläche. Er stoppt neue Vorgänge. Laufende bringt er sauber zu Ende oder setzt sie zurück. Das Ganze wird protokolliert. Wir testen den Not-Aus vor jedem Go-live gemeinsam, so wie man eine Feuerübung macht. Gebraucht wird er in der Praxis selten. Aber zu wissen, dass er da ist, verändert die Haltung gegenüber dem Agenten.

Purview ist Microsofts Werkzeug für Datenklassifizierung, Sensitivitätslabels, Datenverlustschutz und Audit. Es wirkt über Microsoft 365, Azure und Fabric hinweg. Für Agenten heißt das zweierlei. Verschlüsselt ein Label wie „Vertraulich“ das Dokument, kann der Agent es nur öffnen, wenn seine Identität Nutzungsrechte dafür hat. Und was er mit Daten macht, erscheint im Audit-Log neben dem, was Menschen tun. In Fabric werden Sensitivitätslabels außerdem nachgelagert vererbt. Etwa vom Lakehouse auf Power-BI-Modelle und Berichte, die darauf aufbauen. Wird Purview noch nicht genutzt, richten wir es im Rahmen der Governance ein.

Mehr dazu bei Microsoft: Informationsschutz in Microsoft Fabric

Ja, wenn der Vorgang es erfordert und eine Rechtsgrundlage besteht. Zum Beispiel für die Bearbeitung einer Kundenbestellung mit Name und Adresse. Die Regel lautet Datensparsamkeit: Der Agent bekommt nur die Felder, die er braucht. Personalakten oder Gesundheitsdaten bleiben außen vor, wenn sie für den Vorgang nicht nötig sind. Protokolle enthalten nicht mehr Personendaten als der Vorgang selbst. Bei besonders sensiblen Kategorien empfehlen wir eine Datenschutz-Folgenabschätzung, bevor gebaut wird. Das gilt etwa in der Personalabteilung.

In der Regel ja. Während Bau und Betrieb haben wir Zugang zu Ihren Systemen. Dabei können wir personenbezogene Daten sehen, auch wenn wir sie nicht speichern. Wir haben dafür einen Standardvertrag nach Artikel 28 DSGVO, den Ihr Datenschutzbeauftragter prüfen kann. Gern unterschreiben wir auch Ihre Vorlage. Mit Microsoft haben Sie über die Produktbedingungen bereits eine Vereinbarung zur Auftragsverarbeitung. Sie deckt den Betrieb der Plattform ab.

Microsoft Fabric ist eine Plattform, auf der alle Datenarbeit im Unternehmen an einem Ort stattfindet. Sie holen Daten aus SAP, Dynamics oder Dateien und bereiten sie auf. Dann speichern und werten Sie sie aus und zeigen sie als Power-BI-Bericht. Statt fünf Werkzeugen mit fünf Verträgen und fünf Kopien der Daten gibt es eine Kapazität. Dazu kommen ein Speicher namens OneLake und eine Oberfläche, die aussieht wie Power BI. Fabric läuft als Software-as-a-Service in Microsofts Cloud. Es gibt keine Server, die Ihre IT pflegen muss. Für Unternehmen, die Power BI schon nutzen, ist Fabric der natürliche nächste Schritt.

Mehr dazu bei Microsoft: Was ist Microsoft Fabric?

In vier Schritten. Erstens eine Bestandsaufnahme: Welche Quellen und welche Berichte gibt es, und wer nutzt was wirklich? Meist werden 30 bis 50 Prozent der Berichte nicht mehr angeschaut und müssen gar nicht mitziehen. Zweitens der Zielentwurf mit Lakehouse oder Warehouse, Schichten, Namenskonventionen und Berechtigungen. Drittens der Umzug in Etappen nach Fachbereichen. Jede Etappe läuft mit Parallelbetrieb und Abnahme durch die Fachbereiche. Viertens die Abschaltung der alten Welt und die Übergabe an Ihr Team oder in Managed Fabric. Das Plattform-Assessment zum Festpreis liefert die ersten beiden Schritte.

Unsere größte Referenz dafür ist Telefónica Germany. Rund 1.000 Reports und etwa 300 Beschäftigte, die damit arbeiten, zogen von Tableau nach Power BI. Parallelbetrieb und Schulung waren eingeschlossen. Für einen Mittelständler mit 100 bis 200 Berichten geht es deutlich schneller. Die Dauer hängt weniger von der Zahl der Berichte ab als von der Zahl der Datenquellen. Wichtig ist auch, wie viel Logik in Tableau-Berechnungen steckt. Diese Logik muss nach DAX übersetzt werden. Eine Eins-zu-eins-Kopie ist selten sinnvoll. Die Migration ist die Gelegenheit, Berichte zu konsolidieren. Mehr unter Referenzen.

Qlik Sense und QlikView haben ein assoziatives Datenmodell und eine eigene Skriptsprache für das Laden. Beides gibt es in Power BI so nicht. Die Ladeskripte werden zu Dataflows, Notebooks oder Pipelines in Fabric. Das Datenmodell wird zu einem Sternschema mit Beziehungen. Set-Analysis-Ausdrücke werden zu DAX-Measures. Der Aufwand liegt deshalb mehr in der Datenschicht als in der Oberfläche. Wir empfehlen, mit dem Fachbereich mit der größten Nutzung zu starten. So zeigt sich der Nutzen früh.

Microsoft empfiehlt für neue Data-Warehouse-Vorhaben Fabric. Für bestehende Synapse-Umgebungen gibt es einen Upgrade-Pfad. Deshalb lohnt sich der Umstieg für die meisten Synapse-Kunden. Dedicated SQL Pools werden mit dem Migration Assistant zum Fabric Warehouse. Spark-Notebooks ziehen mit dem Spark Migration Assistant und kleinen Anpassungen um. Pipelines lassen sich mit dem Upgrade-Werkzeug weitgehend übernehmen. Dieses Werkzeug ist derzeit in der Vorschau. Der Data Lake wird per Shortcut in OneLake eingebunden, ohne die Daten zu verschieben. Diese Werkzeuge wenden wir im Plattform-Assessment auf Ihren Bestand an. Der Nutzen ist vor allem weniger Betrieb und ein Preis für alles.

Mehr dazu bei Microsoft: Migration von Synapse SQL-Pools nach Fabric

Ja, und das ist einer der häufigsten Fälle, die uns im Mittelstand begegnen. T-SQL-Logik aus Views und Prozeduren wandert in das Fabric Warehouse. Das ist weitgehend T-SQL-kompatibel. SSIS-Pakete werden zu Pipelines oder Dataflows. Alternativ laufen sie über die Aktivität „Invoke SSIS Package“ in Fabric weiter. Diese Aktivität ist derzeit in der Vorschau. SSRS-Berichte werden zu Power BI. Für Schema und Daten gibt es den Fabric Migration Assistant. Er unterstützt auch SQL Server als Quelle. Die Quellsysteme im Rechenzentrum erreicht Fabric über ein On-premises Data Gateway. So können SAP oder die Warenwirtschaft dort bleiben, wo sie sind. Der Betrieb des Servers, die Backups und die Patches entfallen danach.

Mehr dazu bei Microsoft: Fabric Migration Assistant für Data Warehouse

Beide speichern im selben OneLake und im selben Format. Der Unterschied liegt im Werkzeug. Das Lakehouse wird mit Spark und Notebooks bearbeitet. Es eignet sich für Rohdaten, Dateien und Datenaufbereitung mit Python. Das Warehouse wird mit T-SQL bearbeitet. Es eignet sich für Teams aus der SQL-Server-Welt, die saubere Tabellen für Berichte brauchen. Unsere übliche Empfehlung: Lakehouse für die ersten Schichten. Für die Berichtsschicht ein Warehouse oder ein Lakehouse mit seinem nur lesenden SQL-Analyseendpunkt. Das hängt davon ab, was Ihr Team besser kann. Die Entscheidung ist nicht endgültig, weil die Daten ohnehin dasselbe Format haben.

Mehr dazu bei Microsoft: Entscheidungshilfe Lakehouse oder Warehouse

Fabric wird über Kapazitäten abgerechnet, von F2 bis F8192. Die größten sind nicht in allen Regionen verfügbar. Sie zahlen nutzungsabhängig und pausierbar oder über eine Reservierung. Dazu kommt der Speicher im OneLake, der separat abgerechnet wird. Ein Mittelständler mit einigen Dutzend Berichten und nächtlichen Ladeläufen kommt oft mit F2 bis F8 aus. Größere Häuser mit vielen Zugriffen und Direct Lake brauchen F64 oder mehr. Ab F64 sind auch keine Power-BI-Pro-Lizenzen mehr für die reinen Leser nötig. Wir starten klein und messen die Auslastung mit der Capacity Metrics App. Vergrößert wird erst, wenn die Zahlen es zeigen. Konkrete Preise stehen in der Microsoft-Preisliste und ändern sich. Deshalb nennen wir hier keine.

Mehr dazu bei Microsoft: Fabric-Lizenzen und Kapazitäten

Sie fängt beim Datenmodell an und nicht beim Diagramm. Die meisten langsamen oder widersprüchlichen Berichte haben kein Problem in der Visualisierung. Sie haben ein flaches Modell ohne Sternschema. Ihre Measures haben keine klare Definition, und es gibt drei Versionen der Umsatzzahl. Gute Beratung liefert ein Modell, das der Fachbereich versteht. Dazu Measures mit Namen, die im Unternehmen gelten. Und eine Berechtigung auf Zeilenebene, die mit der Organisation mitwächst. Im Team arbeiten zertifizierte Power BI Data Analysts nach PL-300. Wichtiger als das Zertifikat ist: Es macht das seit Jahren für Konzerne und Mittelständler. Mehr unter Business Intelligence.

Ja, und das sollten Sie. Wir migrieren in Etappen, und jede Etappe läuft einige Wochen parallel. Die Fachbereiche vergleichen die Zahlen im alten und im neuen Bericht. Abweichungen werden erklärt oder behoben. Erst nach der Abnahme wird der alte Bericht abgeschaltet. Die Kosten für den Parallelbetrieb sind der Preis für Vertrauen. Bei Telefónica war genau das der Grund für den Erfolg: 300 Beschäftigte haben am Ende ohne Widerstand gewechselt. Wichtig ist nur ein Enddatum für die alte Welt. Sonst bleibt sie ewig.

Databricks ist die Wahl, wenn Sie ein Data-Science-Team mit Spark-Erfahrung haben. Ebenso, wenn Sie viel Machine Learning betreiben oder bewusst unabhängig von Microsoft bleiben wollen. Fabric ist die Wahl, wenn Power BI Ihr Berichtswerkzeug ist. Dazu passt ein Team aus der SQL- und Microsoft-Welt, das möglichst wenig Betrieb will. Beides zusammen geht auch. Databricks übernimmt die schwere Aufbereitung. Fabric greift für Berichte auf dieselben Delta-Tabellen zu, mit Shortcuts oder einem gespiegelten Azure-Databricks-Katalog. Wir beraten unabhängig. Für manche ist die Antwort Databricks, auch wenn wir es dann nicht bauen.

Mehr dazu bei Microsoft: OneLake-Shortcuts

Das hängt von SAP-System und Lizenz ab. Für S/4HANA und ECC gibt es die SAP-Konnektoren in Fabric Data Factory wie SAP Table, SAP HANA oder SAP BW. Weitere Wege sind OData-Services und CDS-Views. Bei größeren Datenmengen und Änderungserkennung nutzen wir Mirroring für SAP mit SAP Datasphere. Alternativ gibt es Drittwerkzeuge, die auf Delta-Extraktion ausgelegt sind. Vorher ist eine Frage entscheidend: Erlaubt Ihr SAP-Vertrag die Extraktion in dieser Form? Das klären wir mit Ihnen und gegebenenfalls Ihrem SAP-Partner. Microsoft verweist beim SAP-CDC-Connector dazu ausdrücklich auf den SAP-Hinweis 3255746. Für SAP Business One ist der Weg einfacher, meist direkt aus der SQL- oder HANA-Datenbank. Mehr unter Data Engineering.

Mehr dazu bei Microsoft: SAP-Daten nach Microsoft Fabric extrahieren

Managed Agent Ops ist der Betrieb Ihrer KI-Agenten durch uns. Er läuft als Monatspauschale. Wir überwachen die Agenten und reagieren auf Fehler und Ausfälle. Wir pflegen Testfälle und Regeln und spielen Updates von Modellen und Bibliotheken ein. Einmal im Monat liefern wir einen Bericht in Zahlen. Die Agenten laufen dabei weiterhin in Ihrer Umgebung. Wir haben nur den Zugang, den der Betrieb braucht. Gedacht ist das für Unternehmen, die keine eigene Mannschaft für den Betrieb aufbauen wollen. Oder noch nicht. Mehr unter Managed Services.

Managed Fabric ist der Betrieb Ihrer Microsoft-Fabric-Plattform durch uns. Wir überwachen die Ladeläufe und die Kapazität und beheben Fehler. Ändert sich eine Quelle, passen wir die Pipelines an. Wir verwalten Berechtigungen und Arbeitsbereiche und kontrollieren die Kosten der Kapazität. Jeden Monat gibt es einen Bericht mit Auslastung, Laufzeiten und Kosten. Dazu gehört ein Kontingent für kleinere Änderungen und neue Berichte. Auch hier gilt: Monatspauschale, und die Plattform bleibt in Ihrem Tenant.

Zahlen, keine Prosa. Für Agenten: bearbeitete Vorgänge, Anteil ohne menschlichen Eingriff, Freigaben sowie Fehler und ihre Ursachen. Dazu Laufzeit je Vorgang, Kosten bei Microsoft je Agent und Änderungen im Monat. Für Fabric: Auslastung der Kapazität sowie Dauer und Erfolgsquote der Ladeläufe. Dazu die Nutzung der Berichte, Kosten und offene Punkte. Eine weitere Seite zeigt, was wir im nächsten Monat ändern wollen und warum. Die Geschäftsführung kann den Bericht in zehn Minuten lesen. Er ist die Grundlage für die Frage, ob sich der Betrieb weiter lohnt.

Wir vereinbaren Reaktionszeiten nach Schwere. Ein Agent, der steht oder falsche Daten schreibt, hat immer Vorrang. Danach kommen Fehler ohne Auswirkung auf den Betrieb. Änderungswünsche folgen nach Absprache. Betreuung rund um die Uhr bieten wir nur, wenn der Vorgang es wirklich braucht. Halten wir das nicht für nötig, sagen wir es Ihnen. Die Verfügbarkeit der Plattform selbst garantiert Microsoft über die Azure- und Fabric-SLAs. Genaue Zeiten stehen im Vertrag und richten sich nach dem Vorgang.

Laufzeit und Kündigung regeln wir individuell in Ihrem Vertrag. Sie richten sich nach dem Vorgang und der Einführungsphase. Endet der Vertrag, laufen Agent oder Plattform weiter, weil alles in Ihrer Umgebung liegt. Was endet, ist unsere Überwachung und Pflege. Im letzten Monat übergeben wir Dokumentation, Zugänge und offene Punkte an Ihr Team oder den nächsten Partner. Ein Betrieb soll weiterlaufen, weil er sich für Sie lohnt.

Die Übergabe beginnt beim Bau, nicht am Ende. Ihr Team sitzt bei Entscheidungen mit am Tisch. Der Code liegt von Anfang an in Ihrem Repository. Die Dokumentation beschreibt, wie man einen Testfall ergänzt, ein Modell wechselt oder eine Regel anpasst. Zum Abschluss gibt es zwei bis drei Arbeitssitzungen. Darin führt Ihr Team typische Betriebsaufgaben selbst durch, und wir schauen zu. Danach können Sie den Betrieb ganz übernehmen oder uns für einzelne Monate dazuholen. Für einen Agenten reicht erfahrungsgemäß eine Person mit Python- oder .NET-Kenntnissen und etwas Zeit pro Woche.

Bei Agenten laufen vor jedem Update die gespeicherten Testfälle aus echten Vorgängen. Erst wenn die Ergebnisse gleich oder besser sind, geht die neue Version in den Betrieb. Die Rückkehr zur vorherigen Version bleibt möglich. Bei Fabric kommen die Plattform-Updates von Microsoft automatisch. Wir prüfen monatlich, ob neue Funktionen oder abgekündigte Elemente Ihre Pipelines oder Berichte betreffen. Alle Änderungen stehen im Monatsbericht. Updates spielen wir geplant ein. Sofort geht es nur bei einem Sicherheitsproblem.

Allgemein verfügbare Modellversionen in Microsoft Foundry werden in der Regel 18 Monate nach dem Start abgeschaltet. Nach zwölf Monaten können neue Kunden sie schon nicht mehr bereitstellen. Microsoft kündigt das Ende mindestens 60 Tage vorher an. Neue Modelle erscheinen alle paar Monate. Im Managed Service beobachten wir das. Neue Versionen testen wir gegen Ihre Testfälle, bevor sie in den Betrieb gehen. Oft ist ein neues Modell günstiger oder genauer. Manchmal ist es für Ihren Vorgang auch schlechter. Dann bleiben wir beim alten, solange es geht. Der Wechsel ist eine Konfiguration, kein Umbau. Denn der Agent ist so gebaut, dass das Modell austauschbar ist. Eine Falle in der Praxis ist die Upgrade-Einstellung jeder Bereitstellung. Bei automatischem Update auf die Standardversion wechselt das Modell ohne Ihr Zutun. Wer eine Version festhalten will, muss zusätzlich das automatische Upgrade abschalten. Dann hört die Bereitstellung beim Abschalten der Version auf zu antworten. Deshalb legen wir die Einstellung bewusst fest und planen den Wechsel vorher.

Mehr dazu bei Microsoft: Upgrade-Einstellung für Modellbereitstellungen

Zuerst merkt es die Überwachung, nicht der Fachbereich. Bleiben Vorgänge liegen oder häufen sich Fehler, geht eine Meldung an uns. Auf Wunsch geht sie auch an Ihre IT. Der Agent nimmt liegen gebliebene Vorgänge nach dem Neustart auf. Dabei bearbeitet er nichts doppelt. Im Zweifel schaltet der Fachbereich auf den manuellen Weg zurück, bis der Agent wieder läuft. Dieser Weg wurde ja nie abgebaut. Totalausfälle haben nach unserer Erfahrung meist eine Ursache außerhalb des Agenten. Ein Beispiel ist ein geändertes Passwort an einer Schnittstelle. Genau solche Abhängigkeiten stehen deshalb im Betriebshandbuch.

Die Zahlen. Wir messen für jeden Agenten laufend, wie oft Menschen eingreifen und wie oft Freigaben abgelehnt werden. Ebenso, wie lange Vorgänge dauern. Verschieben sich diese Werte, ist das ein Signal. Und zwar lange bevor sich jemand beschwert. Ursachen sind meist Veränderungen außen. Etwa ein Lieferant mit neuem Rechnungsformat oder ein neues Feld im ERP. Zusätzlich ziehen wir monatlich eine Stichprobe von Vorgängen und lesen sie durch. Denn manche Fehler tauchen in keiner Kennzahl auf.

Ja, in beide Richtungen. Manche Unternehmen übernehmen später selbst, weil sie inzwischen ein Team haben. Für eine Modellumstellung oder einen neuen Agenten holen sie uns später wieder dazu. Andere starten selbst und merken, dass der Betrieb mehr Aufmerksamkeit braucht als gedacht. Dann geben sie ihn an uns. Alles liegt in Ihrer Umgebung und ist dokumentiert. Deshalb ist der Wechsel in beide Richtungen eine Sache von Wochen, nicht von Monaten.

Nach unserer Erfahrung ab etwa 50 Beschäftigten. Dann haben einzelne Vorgänge genug Volumen, dass ein Agent spürbar Zeit spart. Und es gibt jemanden, der den Agenten fachlich verantwortet. Entscheidend ist aber nicht die Zahl der Köpfe, sondern die Zahl der Wiederholungen. Ein Handelsunternehmen mit 60 Beschäftigten und 300 Bestellungen am Tag hat einen besseren Fall. Ein Ingenieurbüro mit 200 Beschäftigten und lauter Einzelprojekten hat einen schwächeren. Unsere Kunden reichen vom Mittelständler mit 50 Beschäftigten bis zum Konzern wie Telefónica Germany. Die Agenten sind im Kern dieselben.

Fast immer dieselben fünf. Bestellungen aus Mails und PDFs ins ERP übernehmen. Eingangsrechnungen prüfen und zur Freigabe vorbereiten. Angebote aus Anfragen vorbereiten. Reklamationen und Serviceanfragen einordnen und beantworten. Stammdaten pflegen und abgleichen. Je nach Branche kommt das Auslesen von Lieferscheinen, Zeugnissen, Zertifikaten oder Verträgen dazu. Was diese Vorgänge gemeinsam haben: Sie laufen täglich und sind beschreibbar. Und sie halten heute Fachkräfte vom eigentlichen Geschäft ab. Unter Agenten zeigen wir Beispiele, unter Branchen die Besonderheiten.

Ja. SAP Business One hat mit der Service Layer eine REST-Schnittstelle. Darüber kann ein Agent Geschäftspartner, Artikel, Aufträge und Belege lesen und anlegen. Für Auswertungen lässt sich die Datenbank direkt anbinden, ob SQL Server oder HANA. Typische Agenten im Business-One-Umfeld sind Bestellerfassung, Rechnungsprüfung und Angebotsvorbereitung. Wichtig ist ein eigener technischer Benutzer für den Agenten mit begrenzten Rechten. So bleibt im Änderungsprotokoll von Business One nachvollziehbar, was der Agent getan hat.

Business Central ist für Agenten ein dankbares System. Es läuft in Microsofts Cloud und ist über APIs und Dataverse erreichbar. Die Anmeldung läuft über Entra. Was der Agent darf, regeln Berechtigungssätze in Business Central. Ein Agent kann Verkaufsaufträge anlegen und Einkaufsrechnungen vorerfassen. Er kann Artikel und Debitoren pflegen und Freigaben über Teams einholen. Eine eigene Schnittstelle muss dafür nicht gebaut werden. Für einfache Schritte binden wir außerdem gern Power Automate oder Copilot Studio ein. Das geht über den Business-Central-Connector. Welche Lizenzen dafür nötig sind, klären wir vorher. Mehr unter Dynamics 365 und Power Platform.

Mehr dazu bei Microsoft: Zugriff auf Business Central verwalten

In Grenzen. DATEV ist für Steuerkanzleien und Buchhaltung gebaut. Es öffnet sich über DATEV-Schnittstellen und Datenservices. Damit kann ein Agent zum Beispiel Belege mit Buchungsinformationen an DATEV Unternehmen online übergeben. Oder er bereitet Buchungsstapel vor. Was gut funktioniert: Der Agent prüft Eingangsrechnungen und ergänzt Kostenstelle und Kontierung nach Ihren Regeln. Dann übergibt er sie strukturiert an die Buchhaltung oder die Steuerkanzlei. Die Buchung selbst bleibt bei den Menschen, die dafür verantwortlich sind. Wir nutzen einen solchen Belegagenten auch im eigenen Haus.

Ja. Viele Betriebe, mit denen wir sprechen, haben ein bis zwei Personen für IT oder ein externes Systemhaus. Wir brauchen jemanden, der Zugänge freigeben und Fragen zur Umgebung beantworten kann. Das kann auch Ihr Systemhaus sein. Mit dem arbeiten wir gern zusammen. Den Betrieb übernehmen wir dann als Managed Service. So muss niemand bei Ihnen Azure lernen. Was Sie selbst brauchen, ist eine Person aus dem Fachbereich, die den Agenten als ihren betrachtet. Sie sagt, wenn er Unsinn macht.

Die Bedenken sind berechtigt, und man muss sie konkret beantworten. Konkret heißt: Die Daten werden in Ihrem Microsoft-Tenant in Deutschland oder der EU gespeichert und verarbeitet. Die Bereitstellung hält dabei die Verarbeitung in der EU. Microsoft nutzt die Daten nicht für Training. Der Zugriff läuft über Ihre Identitäten. Und Sie können jederzeit alles exportieren, weil die Formate offen sind. Die meisten Mittelständler, die wir kennen, haben ihre Mails und Dateien ohnehin schon in Microsoft 365. Dort liegen oft sensiblere Dinge als in der Bestellerfassung. Darf ein Vorgang trotzdem nicht in die Cloud, sagen wir das. Dann bauen wir für diesen Vorgang keinen Agenten.

Mehr dazu bei Microsoft: Bereitstellungstypen für Foundry-Modelle

Erstens: Fragen Sie Ihr Team, wo es am meisten abtippt, abgleicht oder nachfragt. Zählen Sie dann die Stunden. Zweitens: Prüfen Sie, wo die Daten dafür liegen. In Systemen, die man anbinden kann, oder in Köpfen und Excel-Dateien? Drittens: Wählen Sie einen Vorgang und sprechen Sie mit jemandem, der so etwas schon gebaut hat. Bei uns geht das im kostenlosen Erstgespräch oder im dreiwöchigen Assessment. Was Sie nicht zuerst brauchen: eine KI-Strategie mit 40 Seiten, eine Datenplattform oder einen Chief AI Officer.

Microsoft 365 ist eine gute Basis. Identitäten, Teams, SharePoint und Postfächer sind dann schon da. Das ist die Hälfte dessen, was ein Agent braucht. Dazu kommt eine Azure-Subscription für die Modelle und die Laufzeit des Agenten. Sie lässt sich in einem Nachmittag einrichten und wird nur nach Nutzung abgerechnet. Copilot-Lizenzen sind nicht nötig, Fabric auch nicht für den Anfang. Arbeiten Sie noch mit lokalen Exchange-Servern und Dateiablagen? Dann sollten Sie den Umzug nach Microsoft 365 vor dem ersten Agenten machen.

Im Assessment etwa zwei Stunden pro Woche für Gespräche und das Zusammenstellen von Beispielen. Während des Baus ist es ähnlich. Dazu kommen einige Stunden für das Durchsehen von Testergebnissen. Denn nur der Fachbereich weiß, ob ein Vorschlag des Agenten richtig ist. In den ersten Wochen des Betriebs ist der Aufwand für Freigaben höher, weil die Grenzen noch eng sind. Danach sinkt er. Nach unserer Erfahrung zahlt sich die Zeit innerhalb weniger Wochen nach dem Go-live zurück. Wer mitgebaut hat, wirbt später am überzeugendsten dafür.

Nicht vor dem ersten Agenten, aber nach dem zweiten. Der erste Vorgang zeigt, was in Ihrem Haus funktioniert und welche Daten fehlen. Er zeigt auch, wie Ihr Team auf einen Agenten reagiert. Darauf lässt sich eine Strategie bauen, die nicht am Schreibtisch erfunden ist. Haben dann mehrere Fachbereiche Ideen, hilft ein kurzer Rahmen. Welche Vorgänge zuerst? Welche Regeln für alle Agenten? Wer entscheidet, und wie wird gemessen? Diesen Rahmen erarbeiten wir unter KI-Strategie und Enablement. Dazu gehört Schulung für alle, die mit Agenten arbeiten.

Business Central ist Microsofts ERP für kleine und mittelständische Unternehmen. Finanzbuchhaltung, Einkauf, Verkauf, Lager und Projekte laufen in einem System. Bei Bedarf kommen Fertigung und Service dazu. Microsoft nennt als Schwerpunkt Großhandel und Dienstleister. Es unterstützt aber auch Montage, Produktion und Lagerlogistik. Business Central läuft als Cloud-Dienst von Microsoft, Sie brauchen also keine eigenen Server. Gut passt es, wenn Sie ohnehin mit Microsoft 365 arbeiten. Und wenn Ihre Abläufe nicht mehr in Einzelprogrammen und Excel-Listen verteilt sein sollen.

Mehr dazu bei Microsoft: Business-Funktionen von Business Central

Microsoft beschreibt Business Central ausdrücklich für Unternehmen, die aus einer Einstiegslösung herausgewachsen sind. Es richtet sich auch an Firmen, die ein in die Jahre gekommenes System ablösen wollen. Typische Anzeichen sind doppelt gepflegte Daten und Auswertungen, die erst nach Tagen in Excel fertig sind. Oder Abläufe, die nur eine Person wirklich kennt. Ist Ihre Buchhaltung dagegen schlank und läuft gut, raten wir nicht zum Wechsel um des Wechsels willen. Genau das klären wir im kostenlosen ERP-Check, bevor Sie etwas entscheiden.

Mehr dazu bei Microsoft: Einführung in Business Central (Training)

Ihre Steuerkanzlei bleibt Ihre Steuerkanzlei und bekommt ihre Daten weiterhin. Zu einer Essentials- oder Premium-Lizenz können Sie bis zu drei kostenlose Lizenzen für die externe Buchhaltung beziehen. So kann Ihre Kanzlei direkt in Business Central mitarbeiten. Für die Übergabe an DATEV richten wir bei der Einführung einen Export ein. Den stimmen wir vorher mit Ihrer Steuerkanzlei ab. Auch den Datenexport für die digitale Betriebsprüfung empfiehlt Microsoft gemeinsam mit der Steuerkanzlei festzulegen.

Mehr dazu bei Microsoft: Externe Buchhaltung in Business Central

Beide sind ERP-Systeme für den Mittelstand, und beide können eine Firma gut tragen. Wir sind Microsoft-Partner und deshalb nicht neutral. Das sagen wir offen. Für Business Central spricht vor allem die Nähe zu Microsoft 365. Daten aus Business Central erscheinen direkt in Outlook, Excel und Teams. Anmeldung und Berechtigungen laufen über dieselbe Microsoft-Identität. Arbeitet Ihr Unternehmen schon auf Microsoft 365? Oder will es seine Daten auf Microsoft Fabric auswerten? Dann ist das ein echter Vorteil im Alltag.

Mehr dazu bei Microsoft: Willkommen bei Business Central

Business Central wird pro Person lizenziert, und zwar über Microsoft-Partner im CSP-Programm. Es gibt drei Varianten. Essentials ist für die volle Arbeit in Finanzen, Einkauf, Verkauf und Lager. Premium enthält zusätzlich Fertigung und Serviceverwaltung. Team Members ist für alle, die nur eingeschränkt schreiben. Je nach Bedarf kommen weitere Kosten hinzu: für zusätzliche Umgebungen, Speicher oder die Nutzung von KI-Agenten. Die aktuellen Preise nennt Microsoft auf der Produktseite zu Business Central. Im ERP-Check rechnen wir mit Ihnen aus, welche Mischung Sie wirklich brauchen.

Mehr dazu bei Microsoft: Lizenzierung in Business Central

Ja. Microsoft liefert eine eigene deutsche Version. Die Datenbank einer Umgebung mit deutscher Lokalisierung liegt in der Azure-Region Deutschland. Die deutsche Version enthält unter anderem die Umsatzsteuer-Voranmeldung als Datei für ELSTER. Dazu kommen E-Rechnungen in XRechnung, ZUGFeRD und Peppol. Auch der Datenexport für die digitale Betriebsprüfung nach GoBD ist enthalten. Eine Software allein macht ein Unternehmen aber nicht GoBD-konform. Die Verfahrensdokumentation und Ihre internen Abläufe bleiben Ihre Aufgabe. Wir helfen Ihnen gern, sie bei der Einführung gleich mitzuschreiben.

Mehr dazu bei Microsoft: Deutsche Lokalisierung von Business Central

Ein Agent meldet sich bei Business Central als eigene App in Microsoft Entra an. Er arbeitet über die offiziellen Schnittstellen, nicht über Umwege. In Business Central bekommt diese App eigene Berechtigungssätze. Die volle Administratorberechtigung SUPER lässt sich ihr gar nicht zuweisen. So darf der Agent genau das, was sein Vorgang braucht. Jeder Schritt ist einer Identität zugeordnet. So arbeiten wir auch selbst: Bei uns legen Agenten die Eingangsrechnungen in Business Central an. Gebucht wird erst, wenn unsere Buchhaltung sie geprüft hat. Wie das bei Ihnen aussehen kann, zeigen wir unter Business Central mit Agenten.

Mehr dazu bei Microsoft: Service-to-Service-Anmeldung

Copilot ist in Business Central eingebaut. Sie können im Chat nach Daten fragen und Listen per Spracheingabe auswerten. Sie können Datensätze zusammenfassen oder sich beim Bankabgleich helfen lassen. Dazu kommen Microsoft-Agenten wie der Payables Agent. Er bereitet Eingangsrechnungen aus einem Postfach als Entwurf vor. Abgerechnet wird er über Copilot-Guthaben. Laut Microsoft ist er bisher nur für Englisch geprüft. Diese Funktionen gibt es nur in Business Central online. Welche davon in Deutschland und auf Deutsch verfügbar sind, wechselt mit jedem Release. Eigene Agenten lohnen sich dort, wo Ihr Vorgang über Business Central hinausgeht. Oder wo Ihre Regeln nicht in den Standard passen.

Mehr dazu bei Microsoft: KI in Business Central

Wir beginnen mit einem kostenlosen ERP-Check. Dabei sehen wir uns Ihre heutigen Abläufe, Systeme und Daten an. Dann sagen wir Ihnen offen, ob Business Central passt. Danach bekommen Sie ein Angebot zum Festpreis, gestaffelt in Größen je nach Umfang. So wissen Sie vor dem Start, was die Einführung kostet. Die Agenten planen wir von Anfang an mit. Sie arbeiten vom ersten Tag an im neuen System mit. Den laufenden Betrieb übernehmen wir auf Wunsch zu einer monatlichen Pauschale. Mehr dazu unter Business Central mit Agenten.

Ja, und das ist oft der vernünftigere Weg. Sie lizenzieren nur die Personen, die wirklich in Business Central arbeiten. Essentials oder Premium sind für die volle Arbeit, Team Members für eingeschränktes Schreiben. Wer nur gelegentlich Daten ansehen muss, kann freigegebene Datensätze mit seiner Microsoft-365-Lizenz in Teams lesen. Fachlich starten viele mit Finanzbuchhaltung und Einkauf. Lager, Projekte oder Fertigung nehmen sie später dazu. Nach unserer Erfahrung ist ein Agent für die Eingangsrechnungen ein guter erster Schritt. Er nimmt sofort spürbar Arbeit ab.

Mehr dazu bei Microsoft: Zugriff mit Microsoft-365-Lizenzen

Stammdaten wie Kunden, Lieferanten, Artikel und Sachkonten übernehmen wir per Datenmigration. Das geht über Excel-Vorlagen oder über Konfigurationspakete. In den Paketen lassen sich die Daten vor dem Einspielen prüfen. Offene Posten und Eröffnungssalden buchen wir zum Stichtag ein. So starten Sie mit sauberen Zahlen. Die vollständige Buchungshistorie muss nicht zwingend mit umziehen. Sie bleibt für die Aufbewahrungsfristen lesbar, im Altsystem oder in einem Archiv. Wollen Sie die alten Zahlen weiter auswerten? Dann führen wir sie mit den neuen in einer Datenplattform auf Microsoft Fabric zusammen.

Mehr dazu bei Microsoft: Daten aus anderen Systemen importieren

Haavest ist eine Beratung aus Düsseldorf. Seit 2016 bauen wir Datenplattformen und Business Intelligence im Microsoft-Umfeld, inzwischen auch KI-Agenten. Unsere Kunden sind Unternehmen jeder Größe. Wir sind inhabergeführt und Microsoft Solutions Partner für Data & AI. Wir bringen KI-Agenten dorthin, wo die meisten Projekte stecken bleiben: in den Regelbetrieb. Mit echten Berechtigungen, Protokoll und Monatsbericht. Uns verbindet eine Überzeugung: Technik muss dem Kunden gehören, nicht der Beratung.

Seit 2016, also seit zehn Jahren. Angefangen haben wir mit Data Warehousing und Power BI. Dazu kamen Data Engineering mit SAP und Dynamics und Microsoft Fabric. Seit einigen Jahren bauen wir auch KI-Agenten. Die Größe ist Absicht. Wir sind groß genug für ein Migrationsprojekt mit 1.000 Reports. Und klein genug, dass jede Anfrage direkt bei den Richtigen landet.

Unser Büro ist in der Grafenberger Allee 125 in Düsseldorf. Wir beraten persönlich bei Ihnen vor Ort, in ganz Deutschland, Österreich und der Schweiz. Bei Bedarf kommen wir auch in andere Länder Europas. Zwischen den Terminen arbeiten wir remote. Wer einen Microsoft Partner für Data & AI in Düsseldorf sucht, findet uns über Kontakt.

Das ist eine Partnerstufe, die Microsoft an Unternehmen mit nachgewiesener Erfahrung in Daten- und KI-Projekten auf Azure verleiht. Dazu gehören zertifizierte Fachleute und erfolgreiche Kundenprojekte. Grundlage ist der Partner Capability Score. Er setzt sich aus Kundenzuwachs, Zertifizierungen und Kundenerfolg zusammen, also Nutzungswachstum und Bereitstellungen. Die Einstufung muss jährlich erneuert werden. Für Sie heißt das: Unser Team ist von Microsoft zertifiziert. Das Wissen liegt nachweislich bei uns im Haus, verteilt auf das ganze Team. Wir kennen die Microsoft-Produkte aus der Praxis. Und wir haben Zugang zu Partnerprogrammen, die Ihrem Projekt zugutekommen können.

Mehr dazu bei Microsoft: Partner Capability Score

Im Team gibt es Zertifizierungen für Fabric und Power BI: Fabric Analytics Engineer (DP-600), Power BI Data Analyst (PL-300) und Fabric Data Engineer (DP-700). Für Azure sind es Azure Solutions Architect Expert (AZ-305) und Azure Administrator (AZ-104). Dazu kommt eine Zertifizierung für GitHub Copilot. Die Zertifikate sind für uns ein Nebenprodukt der täglichen Arbeit und kein Ziel an sich. Wichtiger ist etwas anderes. Dasselbe Team hat die Migration bei Telefónica und die Agenten im Mittelstand gebaut.

Unsere größte veröffentlichte Referenz ist Telefónica Germany. Rund 1.000 Reports für etwa 300 Beschäftigte zogen von Tableau nach Power BI. Parallelbetrieb, neues Datenmodell und Schulung waren eingeschlossen. Dazu kommen Projekte bei Mittelständlern in Handel, Fertigung und Dienstleistung. Viele davon nennen wir auf Wunsch der Kunden nicht namentlich. Im Gespräch beschreiben wir sie gern. Mehr unter Referenzen.

Bei uns baut das Team, das Sie im Erstgespräch kennenlernen, auch das Projekt. Wir haben keine Junior-Bänke, die ausgelastet werden müssen. Wir haben keine eigene Plattform, die Sie an uns bindet. Wer Sie betreut, bleibt vom ersten Gespräch bis in den Betrieb dieselbe Person. Folgeprojekte entstehen bei uns aus guten Ergebnissen. Wir arbeiten an wenigen Projekten gleichzeitig, dafür mit voller Aufmerksamkeit. Deshalb sagen wir auch mal, dass wir erst in einigen Wochen starten können. Festpreise in überschaubaren Schritten sind unsere Antwort auf die Frage, wer das Risiko trägt.

Beides, und wir haben eine klare Meinung dazu. Assessment-Start, Entscheidungstermine und Go-live sind besser vor Ort. Dort lernt man das Team kennen, das den Vorgang wirklich macht. Bau, Test und Betrieb laufen remote. Es gibt feste Termine in Teams und einen gemeinsamen Kanal für alles dazwischen. Bei Kunden im Rheinland und Ruhrgebiet sind wir regelmäßig im Haus. Für Kunden in München, Wien oder Zürich planen wir die Vor-Ort-Tage im Voraus.

Ja, wir nutzen selbst mehrere Agenten im eigenen Haus. Etwa für Belege, Zeiterfassung und Angebote. Dabei nutzen wir dieselben Werkzeuge, dieselbe Governance und denselben Monatsbericht, die wir Kunden anbieten. Das hat zwei Gründe. Wir wollen wissen, wie sich der Betrieb anfühlt, bevor wir ihn jemandem versprechen. Und wir sparen damit im ganzen Team tatsächlich Zeit. Was dabei nicht funktioniert hat, erzählen wir im Erstgespräch genauso wie das, was funktioniert.

Für Handel und Großhandel, Fertigung, Telekommunikation, Dienstleistung und Energie. Also überall dort, wo viele Belege, Bestellungen und Daten durch das Haus laufen und Microsoft die Grundlage ist. Branchenwissen ist für uns wichtig. Ein Agent für Lieferscheine in der Fertigung braucht andere Regeln als einer für Anfragen im Großhandel. Die Technik dahinter ist aber dieselbe. Unter Branchen beschreiben wir, was in den einzelnen Bereichen typischerweise zuerst ansteht.

Im Kern ja, und das ist eine bewusste Entscheidung. Wir wollen eine Plattform wirklich gut können, statt fünf halb. Quellsysteme dürfen trotzdem alles sein: SAP, Salesforce, Datenbanken, Dateien. Auch Databricks oder Snowflake als Nachbarn einer Fabric-Plattform sind kein Problem.

Wir suchen Menschen, die Daten und KI im Microsoft-Umfeld bauen und betreiben wollen. Beraten allein reicht uns nicht. Gesucht sind Menschen für Data Engineering mit Fabric oder SQL, für Power BI, für Agenten in Python oder .NET und für die Beratung, die mit Fachbereichen reden kann. Wir sitzen in Düsseldorf, arbeiten hybrid und nehmen uns Zeit für Zertifizierungen. Schreiben Sie uns über Kontakt ein paar Zeilen dazu, was Sie zuletzt gebaut haben. Die Antwort kommt von Menschen aus unserem Team.