Unser neues ERP läuft seit September produktiv. Wir haben es selbst entwickelt, und ein wichtiger Grund dafür war der direkte Zugriff auf unsere Daten. So können wir eigene Auswertungen bauen, Daten verbinden und neue Schnittstellen daraufsetzen.
Seit kurzem nutzen wir diese Basis auch für MCP. Über einen MCP-Server greifen AI-Assistenten wie Claude oder Gemini auf unser ERP zu, vorerst nur lesend. Neben Reports, Exporten und SQL-Abfragen haben wir damit einen weiteren Zugang zu unseren Geschäftsdaten.
Wir können genau nach der Auswertung fragen, die wir gerade brauchen, ohne sie zuerst als Report oder SQL-Abfrage in der Applikation verbauen zu müssen.
Reports, Exporte, SQL und neu der Chat
Bei den meisten Auswertungen wissen wir genau, was wir brauchen. Projektabrechnungen oder wiederkehrende Kennzahlen sind deshalb als Reports direkt im ERP verfügbar und liefern immer dieselbe Sicht auf die Daten. Für andere Fälle exportieren wir Daten nach Excel oder CSV. Für komplexere Auswertungen gibt es im ERP einen SQL-Editor, mit dem wir Ad-hoc- oder gespeicherte Abfragen direkt auf der Datenbank ausführen.
Mit MCP gewinnen wir vor allem Flexibilität. Wir können genau nach der Auswertung fragen, die wir gerade brauchen, ohne sie zuerst als Report oder SQL-Abfrage in der Applikation verbauen zu müssen. Der Agent führt dafür Daten aus verschiedenen Bereichen des ERP zusammen. Ist er zusätzlich mit weiteren Systemen verbunden, kann er die Auswertung mit Daten aus anderen Quellen anreichern.
Auch die Fragestellung muss nicht von Anfang an vollständig definiert sein. Wir können nachfragen, einen Aspekt genauer betrachten oder die Auswertung weiter eingrenzen. So entwickelt sich die Auswertung Schritt für Schritt im Gespräch.
Ressourcen und Auslastung im Chat: Die Auswertung entwickelt sich mit jeder Rückfrage weiter (fiktive Daten).
Der Agent baut seine Abfragen selbst
Unsere Weboberfläche greift bereits über GraphQL auf das ERP zu. Die API umfasst rund hundert Abfragen und beschreibt, welche Daten vorhanden sind und wie sie zusammenhängen. Vor diese API haben wir den Apollo MCP Server gestellt, den wir bereits in einem anderen Projekt produktiv einsetzen.
Der MCP-Server stellt dem Agenten nur drei grundlegende Werkzeuge bereit. Er kann das GraphQL-Schema erkunden, darin suchen und eine Abfrage ausführen. Welche Daten er für eine konkrete Frage braucht, findet der Agent selbst heraus. Er sieht im Schema beispielsweise, wie Projekte, Zeiterfassung, Kunden und Rechnungen miteinander verbunden sind, und erstellt daraus die passende GraphQL-Abfrage.
Wir müssen deshalb nicht für jede mögliche Auswertung ein eigenes MCP-Tool bauen. Kommen neue Daten oder Abfragen zur GraphQL-API hinzu, kann der Agent sie grundsätzlich ebenfalls nutzen. So wächst der MCP-Zugang mit der Applikation mit. Wie MCP funktioniert, haben wir in einem früheren Artikel beschrieben.
Die bestehenden Berechtigungen gelten auch für MCP
Beim Verbinden meldet sich der Benutzer über Keycloak an. Der MCP-Server prüft das Token und reicht es an das ERP weiter. Dort greifen dieselben Rollen und Regeln aus unserem Regelwerk wie in der Weboberfläche. Was ein Benutzer im ERP nicht sehen darf, kann auch sein Agent nicht abfragen.
Dasselbe Prinzip haben wir bereits bei Uniport MCP umgesetzt, über das AI-Agenten Benutzer, Rollen und Berechtigungen in unserem IAM abfragen. Der Agent arbeitet mit den Berechtigungen des angemeldeten Benutzers und nicht mit einem technischen Konto mit erweiterten Rechten. Ob jemand MCP überhaupt nutzen darf, steuern wir zusätzlich über eine eigene Rolle. Sie öffnet den Zugang zum MCP-Server, gibt aber keine zusätzlichen Daten frei.
Persönliche Daten bleiben draussen
Ein Agent kann in kurzer Zeit alles abfragen und verknüpfen, was der angemeldete Benutzer im ERP sehen darf. Was er dabei liest, landet im Kontext des Sprachmodells und damit beim Anbieter des Modells.
Bei persönlichen Daten unserer Mitarbeitenden setzen wir deshalb eine zusätzliche Grenze. Besonders sensible Angaben wie Löhne, AHV-Nummern oder private Bankverbindungen stellen wir über MCP nicht bereit, auch wenn ein Benutzer im ERP darauf zugreifen darf. Dafür erhält der MCP-Server ein reduziertes GraphQL-Schema. Zusätzlich prüft das ERP jede Anfrage über diesen Zugang und blockiert gesperrte Felder.
Ein Agent sieht damit nie mehr als der angemeldete Benutzer, bei bestimmten persönlichen Daten aber bewusst weniger.
Wir müssen nicht jede Frage vorwegnehmen
Reports bleiben die Grundlage für feste und wiederkehrende Auswertungen. Mit dem SQL-Editor greifen wir sehr gezielt auf die Daten zu, und über Excel oder CSV verarbeiten wir sie ausserhalb des ERP weiter. Für Fragen, für die sich kein eigener Report lohnt, mussten wir bisher Daten exportieren oder eine SQL-Abfrage schreiben. Heute stellen wir sie im Chat und vertiefen die Auswertung, bis sie passt.
So nutzen wir den direkten Zugriff auf unsere Daten jetzt auch im Gespräch mit einem Agenten.
