Viele Unternehmen stehen gerade an demselben Punkt. Der Pilot-Chatbot wirkt in der Demo sauber, die Fachbereiche sind neugierig, und trotzdem hakt es sofort, sobald echte ERP-, CRM- oder Finance-Daten ins Spiel kommen. Dann fehlen Freigaben, Antworten brechen ab, und niemand kann später nachvollziehen, was das System getan hat. Genau dort trennt sich ein hübsches Frontend von brauchbarer Chatbot-Entwicklung.
Dieser Beitrag richtet sich an Unternehmen, die Chatbot Development Services einkaufen oder intern aufbauen wollen. Er zeigt, welche Architektur ein produktiver Chatbot braucht, wie die Integration in ERP, CRM und Finance funktioniert, welche Kontrollen im EU-Umfeld Pflicht sind, wo die Kosten liegen und woran Sie einen passenden Dienstleister erkennen.
Warum Chatbot-Projekte selten an der KI scheitern
Im Test beantwortet der Chatbot scheinbar alles. Im Betrieb soll er dann einen Auftrag im CRM anlegen, eine Rechnung prüfen oder eine Freigabe im Finance-System anstoßen. An diesem Punkt kippt das Projekt, weil die Logik hinter dem Dialog nicht mit den echten Systemen verbunden ist. Das Problem ist dann nicht das Sprachmodell, sondern die fehlende Integrations- und Governance-Schicht.
Ein Bot kann freundlich formulieren und trotzdem für den Betrieb unbrauchbar sein, wenn er keine saubere Verbindung zu ERP, CRM oder Buchhaltung hat. Der Wert entsteht erst, wenn ein Chatbot nicht nur spricht, sondern Prozesse auslöst und Daten kontrolliert zurückschreibt. Professionelle Chatbot-Entwicklung ist deshalb eher ein Integrationsprojekt als ein Interface-Projekt.
Praktische Regel: Wenn ein Anbieter nur über Dialogdesign spricht, aber nicht über Rechte, Audit-Spuren und Systemgrenzen, fehlt der eigentliche Kern.
Ein sinnvoller Chatbot im Mittelstand muss drei Dinge gleichzeitig leisten: Er ist fachlich nützlich, technisch integrierbar und operativ kontrollierbar. Fehlt eines davon, entsteht Schattenarbeit statt Automatisierung.
Architektur eines produktiven Chatbots
Ein produktiver Chatbot ist kein einzelnes Tool, sondern ein Verbund aus Rollen, Schnittstellen und Kontrollen. Der Dialog ist nur die sichtbare Spitze. Darunter liegen Agenten, Konnektoren, Rechteprüfungen, Protokolle und ein Schichtmodell, das steuert, welche Aktion erlaubt ist. Bewerten Sie Angebote deshalb nicht nur nach Sprachverständnis und Oberfläche, sondern nach der Architektur dahinter.
Vom Agenten zum Konnektor
Ein Agent ist die Logik, die eine Aufgabe versteht und in Arbeitsschritte zerlegt. Ein Konnektor verbindet diesen Agenten mit einem Zielsystem, etwa SAP, Microsoft Dynamics, BMD, DATEV, Navision, Exact oder weclapp. In echten Systemlandschaften entscheidet dieser Teil über den Nutzen, weil dort nicht nur Text verarbeitet wird, sondern Stammdaten, Belege und Freigaben. Ohne Konnektor bleibt der Bot ein Berater ohne Zugang.
Wo die MCP-Schicht Sinn ergibt
Das Model Context Protocol (MCP) ist ein offener Standard, über den KI-Modelle Werkzeuge und Kontext einheitlich nutzen. Eine MCP-Schicht ist die Kontroll- und Vermittlungsebene zwischen Modell und Unternehmenssystemen. Sie hält Datenzugriffe, Kontext und Ausführungsrechte zusammen. Das verhindert Wildwuchs, weil nicht jede Modellanfrage direkt in jedem System landen darf. Für Integrationen in ERP, CRM und Finance ist das der Unterschied zwischen einem kreativen Assistenten und einem steuerbaren Produktionswerkzeug. Wie eine solche Schicht als Plattform aufgebaut ist, beschreibt unser Beitrag zur Enterprise Automation Platform.

Ein guter Bot ist nicht der, der die schönste Antwort liefert. Ein guter Bot führt die richtige Aktion im richtigen System aus und bleibt danach nachvollziehbar.
Integration in ERP, CRM und Finance
Sobald Chatbots in echte Abläufe eingreifen, verschiebt sich der Fokus von der Konversation zur Prozesskette. Der Mehrwert entsteht dort, wo Mitarbeitende nicht mehr zwischen fünf Tools springen müssen. Im Mittelstand sind das meist drei Zonen: CRM für Vertrieb und Kundenbeziehung, ERP für Stammdaten und operative Logik, Finance für Freigaben, Belege und Kontrollen.
Der Vertriebsinnendienst will ein Angebot aus vorhandenen Kundendaten erzeugen, Finance einen Beleg prüfen und freigeben, Operations Stammdaten aktualisieren. Das klingt einfach, scheitert aber häufig an Medienbrüchen, unklaren Zuständigkeiten und manuellen Übergaben, nicht am Modell.
| Anwendungsfall | Primäres System | Beispiel-Workflow |
|---|---|---|
| Angebotsanlage | CRM | Kundendaten abrufen, Angebot vorbereiten, Rückfrage an den Vertrieb schicken |
| Rechnungsfreigabe | Finance | Beleg prüfen, Freigabe anstoßen, Status zurückmelden |
| Stammdatenpflege | ERP | Adresse oder Artikelinformationen aktualisieren, Änderungen protokollieren |
| Ticket-Rückmeldung | Helpdesk | Vorgang auslesen, Status setzen, Notiz ins Ticket schreiben |
Wo die meisten Integrationen stolpern
Die häufigsten Fehler sind unspektakulär. Es fehlt ein eindeutiger Datensatz als führende Quelle, ein Feld heißt im Quellsystem anders, oder ein Freigabeschritt ist nur im Fachbereich bekannt, aber nirgends dokumentiert. Auch das Rollenmodell wird oft zu spät geprüft. Wer einen Chatbot an CRM und Finance koppelt, muss die Rückschreibelogik genauso ernst nehmen wie die Ausgabe.
Sicherheit, Datenschutz und Governance im EU-Umfeld
Sobald ein Bot personenbezogene Daten, Kundendaten oder Finanzinformationen verarbeitet, reicht eine Funktionsdemo nicht mehr. Dann zählen Nachvollziehbarkeit, Zugriffskontrolle und klare Betriebsregeln. In der EU gehört das nicht an den Rand des Projekts, sondern in die Leistungsbeschreibung.
Ein sauberes Rollen- und Rechtekonzept trennt Leserechte, Freigaberechte und administrative Rechte. Die Protokollierung zeigt, wer was wann ausgelöst hat und warum ein Systemzugriff erlaubt war. Schreibt ein Bot in ERP, CRM oder Finance, braucht jede Aktion einen nachvollziehbaren Pfad zurück zum Auslöser. Freigaben dürfen nicht in Chats, E-Mails oder informellen Nebenkanälen verschwinden, sondern müssen im Zielsystem oder in einer dokumentierten Workflow-Stufe nachvollziehbar bleiben.
Typische Stolperfallen sind Bots mit zu weitreichenden Berechtigungen, unvollständig aufbewahrte Protokolle und Änderungen, die niemand fachlich abgesegnet hat. Je tiefer die Integration, desto stärker wachsen Testtiefe, Freigabeaufwand und Kontrollbedarf. Wird die Governance erst nach dem Rollout gebaut, werden Korrekturen teuer.
Wichtiger Prüfpunkt: Fragen Sie nicht nur, ob ein Anbieter DSGVO-konform arbeitet. Fragen Sie, wie er Rollen trennt, Protokolle aufbewahrt und Freigaben im laufenden Betrieb kontrollierbar macht.
Kontrollfragen für Beschaffung und IT
- Datenresidenz: Wo liegen Protokoll- und Betriebsdaten, und wer kann darauf zugreifen?
- Rechtekonzept: Sieht der Bot nur, was er für die Aufgabe braucht, oder hat er zu breite Systemrechte?
- Auditfähigkeit: Gibt es vollständige Logs für Eingaben, Aktionen und Rückschreibungen?
- Eskalation: Was passiert, wenn ein Vorgang unklar, fehlerhaft oder risikobehaftet ist?
- Betriebsgrenzen: Welche Aufgaben darf der Bot nie autonom erledigen?
Setzt Ihr Unternehmen den Bot für Beschäftigte ein, gilt seit 2. Februar 2025 zudem die Pflicht zur KI-Kompetenz nach Art. 4 des EU AI Act. Die Menschen, die mit dem System arbeiten, müssen wissen, was es kann und wo seine Grenzen liegen.
Kostentreiber und Wirtschaftlichkeit
Der Nutzen entsteht selten in einem großen Sprung. Er entsteht dort, wo Teams jeden Tag dieselben manuellen Schritte vermeiden. Im Vertrieb kostet nicht das Kundengespräch Zeit, sondern das Nacharbeiten im CRM, das Suchen nach Stammdaten und das Übertragen von Informationen in Folgeprozesse. In Finance liegen die größten Aufwände bei wiederkehrenden Belegprüfungen, internen Freigaben und Rückfragen zu Status und Zuständigkeit. Sobald ein Bot Belege vorsortiert, Freigabewege anstößt und den Status transparent zurückmeldet, wird aus manuellem Hin und Her ein kontrollierter Workflow.
Die üblichen Kostentreiber sind Discovery, Integrationsarchitektur, Konnektorentwicklung, Testtiefe, Security-Review und laufende Optimierung. Je komplexer die ERP-, CRM- oder Altsystemanbindung ist, desto stärker verschiebt sich das Budget von der Oberfläche in die Backend-Arbeit. Die Spanne reicht deshalb von kleinen regelbasierten Assistenten bis zu mehrmonatigen Integrationsprojekten. Wer nur die Chatoberfläche bepreist, unterschätzt die eigentliche Leistung.
Regel für die Wirtschaftlichkeit: Rechnen Sie nicht nur mit eingesparten Minuten, sondern mit vermiedenen Medienbrüchen, weniger Eskalationen und kürzeren Durchlaufzeiten in den Kernsystemen.
Wie Sie eingesparte Zeit sauber in Euro und ROI übersetzen, zeigt der Beitrag Zeitersparnis berechnen.
Auswahlkriterien für den richtigen Dienstleister
Ein Chatbot-Projekt in einer ERP- oder CRM-lastigen Organisation steht und fällt mit der Integrations- und Governance-Schicht. Die Oberfläche lässt sich schnell zeigen. Entscheidend ist, ob der Dienstleister Prozesse sauber in bestehende Systeme einhängt, Zugriffe kontrolliert, Protokolle auditierbar hält und spätere Änderungen ohne Risiko für den Betrieb zulässt.
Drei Liefermodelle im Vergleich
Plattformanbieter sind stark, wenn ein klar umrissener Standardfall zügig umgesetzt werden soll. Für einfache Assistenzfunktionen reicht das, solange die Lösung nicht tief in Konnektoren, Berechtigungen oder Freigabeketten eingreifen muss. Klassische IT-Beratungen bringen oft gutes Prozessverständnis mit, stoßen aber an Grenzen, wenn Modellsteuerung, Kontextlogik und Betriebsüberwachung zusammenspielen sollen. Spezialisten für AI Engineering sind im Vorteil, wenn der Bot in reale Systemlandschaften hineinwirken soll, also in ERP, CRM und Finance mit sauberem Logging, klaren Rollen und nachvollziehbaren Workflows.
Worauf Beschaffer konkret achten sollten
- Seniorität der Engineers: Wer implementiert tatsächlich, und wer liefert nur Folien?
- Eigentum an den Konnektoren: Gehören Ihnen die Integrationen, oder bleiben Sie beim nächsten Change Request vom Anbieter abhängig?
- Lock-in-Risiko: Lassen sich Modelle, Systeme und Workflows später austauschen, ohne das Projekt neu aufzusetzen?
- EU-Datenresidenz: Bleiben Betriebs-, Protokoll- und Prozessdaten in der gewünschten Jurisdiktion?
- Modellunabhängigkeit: Läuft die Lösung mit mehreren Modellen, oder hängt die Architektur an einem einzelnen Anbieter?
Auch die organisatorische Passung zählt. Für Unternehmen mit vielen Systemgrenzen, etwa im Mittelstand oder in Portfolios von Private-Equity-Fonds, reicht ein Anbieter nicht, der Prozesse nur isoliert betrachtet. Eine gute KI-Beratung denkt Modellfragen, Integrationswege, Governance und Adoption zusammen. Wie wir als eingebettetes Engineering-Team arbeiten, beschreibt die Seite unserer KI-Agentur in Wien.
Fahrplan von der Discovery bis zur Produktion
Ein sauberes Projekt beginnt nach dem Vertragsabschluss erst richtig. Wer echte Produktionswerte erreichen will, braucht eine Abfolge mit klaren Übergabekriterien, sichtbaren Zuständigkeiten und einem kontrollierten Übergang vom Test in den Betrieb. Das gilt besonders für Finance- und Ops-Workflows, weil Fehler dort sofort operative Kosten erzeugen.
Die Discovery klärt Prozess, Datenquellen und geschäftlichen Zweck. Danach folgt die Integrationsarchitektur, in der Zugriffe, Rechte, Konnektoren und Logging definiert werden. Erst dann startet der Pilot, und zwar klein genug, um Fehler früh zu sehen: mit einem kleinen Teil der späteren Nutzer und Anfragen, bei dem das Team in dieser Phase jede Konversation prüft. Danach folgen der kontrollierte Rollout und die laufende Optimierung auf Basis echter Nutzung. So werden falsche Zuordnungen, schwache Suchtreffer und Lücken in der Eskalation sichtbar, bevor sie im Betrieb teuer werden.
- Discovery-Abschluss: Fachlicher Scope, Datenquellen und Eskalationspfade sind schriftlich festgehalten.
- Architekturfreigabe: Rechte, Protokollierung und Rückschreibelogik sind geprüft.
- Pilotfreigabe: Das Team hat festgelegt, welche Fälle der Bot bearbeiten darf und welche nicht.
- Rolloutfreigabe: Die Fachabteilung kennt Monitoring, Supportwege und Verantwortlichkeiten.
- Betriebsfreigabe: Es gibt einen Plan für kontinuierliche Verbesserung und regelmäßige Fall-Reviews.
Wichtig ist nicht, wie schnell etwas live geht, sondern wie kontrolliert. Was vor dem Go-live erfüllt sein muss, fasst unsere Checkliste zur Production Readiness zusammen.
Checkliste vor der Beauftragung
Am Ende zählt, ob Beschaffung, IT und Fachbereich dieselben Risiken sehen. Eine gute Auswahl beruht auf drei Fragen: Kann der Bot sicher in echte Systeme schreiben, bleibt er später beherrschbar, und lässt er sich ohne harte Abhängigkeit weiterentwickeln?
- Ist die Integrationsschicht dokumentiert? Das reduziert das Risiko von Black-Box-Lösungen.
- Sind Freigaben und Audit-Spuren vorhanden? Ohne sie fehlt die Nachvollziehbarkeit im Betrieb.
- Wem gehören Konnektoren und Workflows? Das entscheidet über Lock-in und spätere Flexibilität.
- Sind Datenresidenz und Rollenmodell klar? Das schützt vor Compliance-Lücken.
- Gibt es einen Pilot mit klaren Gates? Das senkt das Risiko, mit einem unfertigen Prozess in Produktion zu gehen.
Gute Antworten sind konkret, technisch und überprüfbar. Schlechte Antworten bleiben allgemein, verweisen auf spätere Klärung oder sprechen nur über die Oberfläche.
Sprechen Sie mit uns
Wenn Sie einen Chatbot nicht als Demo, sondern als Teil Ihrer ERP-, CRM- und Finance-Prozesse einsetzen wollen, sprechen Sie mit uns.