1. Einen konkreten Arbeitsablauf auswählen
Wer eine Private-AI-Lösung mit einer bestehenden ERP- oder Buchhaltungssoftware verbinden möchte, beginnt mit einem Vorgang, den das Team bereits kennt. Das kann die Vorprüfung eingehender Rechnungen, die Suche nach einem Auftrag oder die Aufbereitung eines Abweichungsberichts sein. Beschreiben Sie den heutigen Ablauf vom ersten Eingang bis zur Übergabe an die nächste verantwortliche Person.
Für einen Rechnungseingang wäre ein überprüfbarer Auftrag etwa, Lieferant, Referenz und Betrag aus einem Dokument für die weitere Kontrolle aufzubereiten. Schreiben Sie auf, welche Eingaben im Alltag fehlen, welche Ausnahmen häufig Rückfragen auslösen und welche Entscheidungen eine Person trifft. Aus diesen Beobachtungen ergeben sich die Anforderungen an den Pilot und die Grenzen des Systems.
Benennen Sie vor der technischen Planung, wer den Vorgang fachlich betreut, wer Zugriff genehmigt und wer den Pilot abnimmt. Stimmen Sie mit diesen Personen ab, welche Quelle verbindlich ist. Klären Sie auch, ob die bestehende Anwendung im ersten Schritt nur gelesen werden soll oder ob ein späterer Entwurf im Zielsystem Teil des Vorhabens ist.
Ein sinnvoller Anfang lässt sich mit einem einzelnen Satz beschreiben. Zum Beispiel soll das Team aus einem eingehenden Dokument einen überprüfbaren Vorschlag erhalten, der auf die passenden Datensätze verweist und bei Unsicherheit eine Rückfrage auslöst. Sobald das Ziel feststeht, lässt sich entscheiden, welche Daten und Rechte die Anwendung tatsächlich braucht.
2. Datenfelder, Quellen und Zielsystem festlegen
Erstellen Sie eine kleine Zuordnungstabelle. Für jedes Feld stehen darin der fachliche Name, die maßgebliche Quelle, das erwartete Format, die zulässigen Werte und der Ort, an dem das Ergebnis verwendet wird. Eine Rechnungsnummer kann beispielsweise im Dokument stehen, während die interne Lieferantennummer aus dem ERP stammt. Beide Angaben erfüllen unterschiedliche Aufgaben und sollten entsprechend getrennt bleiben.
Die Tabelle sollte auch Fälle enthalten, in denen Daten fehlen, widersprüchlich sind oder mehrdeutig zugeordnet werden können. Stimmen Sie ab, ob die Anwendung in solchen Fällen eine Auswahl zur Prüfung vorlegt oder den Vorgang an eine bestimmte Rolle weitergibt. Der Ablauf muss erkennen lassen, aus welchem Dokument oder System ein Wert übernommen wurde.
Prüfen Sie gemeinsam mit dem Team den Unterschied zwischen Anzeigeformat und gespeichertem Wert. Ein Datum kann im Dokument anders aussehen als im Export. Beträge können mit verschiedenen Dezimalzeichen vorliegen. Externe und interne Referenzen können ähnlich aussehen. Für diese Unterschiede eignen sich feste Prüfregeln, die bei gleichen Eingaben zu einem reproduzierbaren Ergebnis führen.
Halten Sie fest, welche Informationen für den ersten Versuch weggelassen werden können. Wenn der Abgleich nur eine Lieferantenkennung und einen Bestellbezug benötigt, braucht die Suche keine vollständige Kopie aller Lieferantendaten. Prüfen Sie mit repräsentativen Beispielen, ob der reduzierte Datensatz auch bei Namensähnlichkeiten, korrigierten Dokumenten und lückenhaften Referenzen brauchbar bleibt.
Weiterführender Leitfaden. Datenfelder vor der Systemintegration zuordnen
3. Eine unterstützte API prüfen
Wenn die vorhandene Software eine dokumentierte API anbietet, prüfen Sie zuerst die tatsächlich installierte Version und den Funktionsumfang des konkreten Mandanten. Eine Schnittstelle kann für Aufträge verfügbar sein und für Buchungsentwürfe fehlen. Auch eine allgemeine Herstellerbeschreibung ersetzt keine Prüfung der vorhandenen Lizenz, der freigegebenen Endpunkte und der benötigten Rechte.
Beginnen Sie mit einer abgegrenzten Leseoperation in einer geeigneten Testumgebung. Fragen Sie beispielsweise einen bekannten Auftrag anhand seiner internen Referenz ab. Dokumentieren Sie die Antwortfelder, mögliche Fehler und die erwartete Reaktion bei einem fehlenden oder mehrfach gefundenen Datensatz. Bei einer Suche über mehrere Ergebnisse sind die Regeln für Seitennavigation, Filter und Sortierung relevant.
Wenn der spätere Pilot Schreibzugriff braucht, klären Sie den vorgesehenen Zielzustand. Ein Entwurf und ein bestätigter Eintrag sind verschiedene Dinge. Prüfen Sie, ob die Zielanwendung den gewünschten Entwurfszustand unterstützt und ob Änderungen mit einer stabilen Referenz wiedergefunden werden können. Prüfen Sie getrennt, welche Rückmeldung die Anwendung nach erfolgreicher Verarbeitung tatsächlich liefert.
Die Anbindung wird für die vereinbarte Anwendung und ihren Betrieb eingerichtet. Klären Sie dabei, welche Zugangsdaten sie nutzt, wie deren Erneuerung abläuft und wer sie bei einem Problem sperren kann. Für die Abnahme sollte das Team mindestens einen zulässigen Abruf und einen gezielt verweigerten Zugriff anhand der tatsächlichen Rollen testen.
4. Dateiexporte kontrolliert nutzen
Ein dokumentierter Dateiexport kann sinnvoll sein, wenn das ERP Daten auf diesem Weg zuverlässig bereitstellt oder der Pilot nur einen begrenzten Ausschnitt benötigt. Ausgangspunkt ist eine von der verantwortlichen Person freigegebene Datei oder ein festgelegter Exportordner. Vereinbaren Sie das Format, die Felder, die Bereitstellungszeit und die zuständige Rolle für Korrekturen.
Beschreiben Sie, woran die Verarbeitung eine vollständige Datei erkennt. Eine Datei im Zielordner kann noch geschrieben werden. Eine neue Spalte oder ein geändertes Trennzeichen kann die Zuordnung verschieben. Ein kontrollierter Eingang prüft deshalb Dateiformat, Pflichtfelder und gegebenenfalls eine Versionsangabe, bevor Daten für einen Vorschlag verwendet werden.
Für wiederholte Exporte braucht der Ablauf eine eindeutige Zuordnung. Eine Exportkennung, ein definierter Zeitraum und eine Prüfsumme helfen, dieselbe Lieferung zu erkennen. Wenn eine Datei ersetzt wird, sollte eine Korrektur als solche erkennbar bleiben. Der Pilot sollte eine doppelt gelieferte und eine nachträglich korrigierte Datei bewusst in die Testfälle aufnehmen.
Legen Sie fest, wie lange die Eingangsdateien, erzeugten Vorschläge und Prüfprotokolle für den Betrieb benötigt werden. Besprechen Sie auch, wer Fehler einsehen kann und wohin ein unbrauchbarer Export verschoben wird. Ein sauber abgegrenzter Export erleichtert den Einstieg, während die Aktualität und der Aufwand des Dateiprozesses im Pilot sichtbar werden.
5. Lesende Alternativen für ältere Software bewerten
Fehlt eine geeignete API, können freigegebene Standardberichte, regelmäßige Exporte oder eine dokumentierte lesende Schnittstelle ausreichen. Entscheidend ist, dass die verantwortliche Stelle den Zugriff unterstützt und dass der gewünschte Datensatz zuverlässig wiedergefunden werden kann. Fragen Sie zuerst, welche Zugriffswege der Hersteller oder der zuständige Betreuungspartner für dieses konkrete System vorsieht.
Ein lesender Bericht ist brauchbar, wenn das Team seinen Stand und seine Grenzen kennt. Zu einer Antwort gehört dann zum Beispiel der Hinweis, wann der Bericht erstellt wurde. Ist ein aktueller Eintrag für eine Entscheidung erforderlich, muss die Anwendung erkennen, dass ein alter Export nicht als Bestätigung des aktuellen Zustands dienen kann.
Bei einer vereinbarten Oberflächenautomatisierung hängt die Stabilität von der Anwendung und ihren Änderungen ab. Dialoge, neue Pflichtfelder oder Verbindungsabbrüche können einen Ablauf unterbrechen. Für einen ersten Versuch empfiehlt sich deshalb ein kontrollierter Leseschritt mit einem klaren Abbruchkriterium. Änderungen im Zielsystem brauchen eine separat geprüfte und nachvollziehbare Bestätigung.
Wenn weder ein verlässlicher Lesezugriff noch ein geeigneter Export verfügbar ist, kann der Pilot mit ausgewählten freigegebenen Dokumenten und einer manuellen Übergabe beginnen. So prüft das Unternehmen, ob die Aufbereitung hilfreich ist und welche Informationen tatsächlich für einen späteren Anschluss nötig wären. Der Pilot liefert dann eine Grundlage für die Entscheidung über weitere Integrationsarbeit.
6. Die Serverumgebung an Daten und Betrieb anpassen
Die geeignete Infrastruktur hängt davon ab, wo die Daten verarbeitet werden dürfen, welche Anwendungen erreichbar sein müssen und wer für Wartung und Störungen verantwortlich ist. CANIMAPS DIGITAL nutzt seine Private-AI-Basis und passt die Umgebung, die Rechte und die Schnittstellen an das jeweilige Unternehmen an. Die technische Auswahl folgt den Anforderungen des konkreten Arbeitsablaufs.
Bei einer Installation auf einem Server des Unternehmens kann der Datenweg innerhalb der vorgesehenen Infrastruktur bleiben, wenn die dafür nötigen Komponenten entsprechend eingerichtet und geprüft sind. Die Arbeitsplätze brauchen weiterhin Zugang zur internen Lösung. Klären Sie, wie Modelle und Komponenten installiert und aktualisiert werden und wie die Anwendung mit Verbindungsunterbrechungen umgeht.
Bei einer dedizierten Serverumgebung sind Standort, Zugangswege, Wartung und Datentransfer Teil der Projektabstimmung. Eine hybride Lösung kann unterschiedliche Aufgaben auf verschiedene Umgebungen verteilen. Für jede Verbindung sollte feststehen, welche Daten sie erhält und welche Informationen bei einem Ausfall verfügbar bleiben. Die Wahl einer Umgebung entscheidet noch nicht über alle angeschlossenen Dienste.
Zeichnen Sie für den Pilot den Weg eines Dokuments auf. Er beginnt bei der bestehenden Anwendung oder dem freigegebenen Eingang, führt über Verarbeitung und Prüfung und endet beim vorgesehenen Ziel. Ergänzen Sie Protokolle, Sicherungen und die beteiligten Konten. Das Team kann dann nachvollziehen, welche Bestandteile im Betrieb erreichbar und überprüfbar sein müssen.
7. Rollen und Berechtigungen im Pilot testen
Unterscheiden Sie Mitarbeitende, die einen Vorschlag anfordern, Personen, die fachlich prüfen, und technische Konten, die eine Schnittstelle nutzen. Ordnen Sie jeder Rolle die konkreten Quellen und Aktionen zu, die sie für ihre Aufgabe benötigt. Eine Rolle für den Rechnungseingang kann beispielsweise Referenzen prüfen dürfen, während die Freigabe in einem getrennten Arbeitsbereich liegt.
Die Berechtigungsprüfung gehört vor die Suche in geschützten Daten. Testen Sie denselben fachlichen Fall mit zwei tatsächlich unterschiedlich berechtigten Rollen. Halten Sie fest, welche Treffer beide Rollen sehen und welche Angaben ausschließlich der dafür freigegebenen Person zugänglich sind. Prüfen Sie auch, dass Protokolle und Fehlermeldungen keine gesperrten Inhalte offenlegen.
Verwenden Sie für technische Zugriffe ein Konto, dessen Rechte zum vereinbarten Vorgang passen. Wenn der Pilot nur lesen soll, prüfen Sie, wie das Zielsystem unzulässige Schreibversuche behandelt. Regeln zur Erneuerung, Sperrung und Überwachung des Zugangs gehören in dieselbe Betriebsdokumentation wie die Schnittstelle selbst.
Klären Sie schließlich, was passiert, wenn eine Person ihre Rolle wechselt oder ein Zugang entzogen wird. Der Pilot sollte eine nachvollziehbare Probe enthalten, bei der der Zugriff nach der Änderung tatsächlich wegfällt. Dieser Test hilft, den Unterschied zwischen einer vorgesehenen Regel und einer wirksamen Einschränkung in der eingesetzten Umgebung zu erkennen.
8. Fachliche Freigaben und den nächsten Schritt trennen
Ein Vorschlag aus der Private-AI-Anwendung sollte erkennen lassen, was übernommen, was berechnet und was als unsicher markiert wurde. Die prüfende Person braucht die Quelle und den relevanten Ausschnitt, um den Vorschlag beurteilen zu können. Definieren Sie im Arbeitsablauf, wann der Zustand vom Vorschlag zur geprüften Übergabe wechselt.
Für einen ersten Rechnungseingang kann die Anwendung die Felder aufbereiten und zur Kontrolle bereitstellen. Die zuständige Person prüft das Original, gleicht die passende Bestellung ab und entscheidet über die weitere Bearbeitung. Wenn das Zielsystem später automatisch einen Entwurf annehmen soll, ist der freigegebene Zustand des Vorschlags die Voraussetzung für diese Übergabe.
Trennen Sie die Sichtbarkeit einer Aktion von ihrer Ausführung. Eine Schaltfläche oder ein vorbereiteter Datensatz beweist noch nicht, dass die Zielanwendung etwas übernommen hat. Der Ablauf sollte nach der Übergabe den tatsächlichen Status zurücklesen, die dortige Referenz festhalten und für das Team sichtbar machen, welcher Schritt abgeschlossen wurde.
Stimmen Sie ab, welche Entscheidungen im bestehenden Verfahren bleiben. In der Buchhaltung können dazu eine fachliche Prüfung, ein Freigabeschritt und die anschließende Buchung gehören. Mit klaren Zuständen und Zuständigkeiten lässt sich testen, dass eine vorbereitete Information an der vorgesehenen Stelle ankommt und dass Ausnahmen zur richtigen Person gelangen.
9. Wiederholungen und doppelte Datensätze vermeiden
Eine Zeitüberschreitung kann auftreten, nachdem eine Anfrage verarbeitet wurde und bevor die Antwort angekommen ist. Vor einem erneuten Schreibversuch sollte der Ablauf deshalb den Zustand im Zielsystem prüfen. Dazu braucht er eine fachlich stabile Referenz und die Möglichkeit, den zugehörigen Eintrag anhand dieser Referenz wiederzufinden.
Vereinbaren Sie, welche Identität ein Vorgang über alle Schritte hinweg behält. Beim Rechnungseingang kann das eine interne Vorgangskennung sein, die mit dem Original und dem erzeugten Entwurf verknüpft ist. Wenn die Ziel-API einen Schlüssel für wiederholbare Anfragen unterstützt, nutzen Sie diesen gemäß ihrer Dokumentation und prüfen Sie das Verhalten mit demselben Testvorgang.
Für technische Lesefehler und vorübergehende Nichtverfügbarkeit eignen sich begrenzte Wiederholungen. Beachten Sie gegebenenfalls die vom Zielsystem angegebene Wartezeit. Wenn der Zustand eines Schreibvorgangs unklar bleibt, braucht die zuständige Person eine Meldung mit Referenz, letzter bestätigter Aktion und einem konkreten nächsten Prüfschritt.
Testen Sie eine doppelte Eingabe, eine nicht erreichbare Schnittstelle und eine verlorene Rückmeldung nach einem möglicherweise erfolgreichen Schreibvorgang. Prüfen Sie nach jedem Fall, wie viele Einträge wirklich existieren und welches Ergebnis die Beteiligten sehen. So lässt sich die Abbruch- und Wiederaufnahmelogik an der vorhandenen Anwendung prüfen.
Technische Referenz. Wiederholungen bei HTTP-Anfragen nach RFC 9110
10. Ein Beispiel für den Eingang einer Rechnung
Das folgende Beispiel beschreibt einen möglichen Pilotablauf. Eine Rechnung kommt als Dokument in einen freigegebenen Eingang. Die Anwendung erhält eine Vorgangskennung und legt fest, welcher Mandant und welcher Prozess zuständig sind. Bis zur Prüfung von Dateityp und Herkunft liegt das Original in einem Bereich mit beschränktem Zugriff. Bei einem Scan kann eine Texterkennung die für den Piloten benötigten Felder vorbereiten. Sie liest nur die für den Versuch vereinbarten Angaben und hält den Bezug zum Original fest.
Der Vorschlag enthält Lieferantenname, Rechnungsreferenz, Betrag und einen möglichen Bestellbezug. Ein getrennt konfigurierter Abgleich fragt die passende Referenz im ERP ab oder nutzt einen freigegebenen Export. Wenn kein eindeutiger Treffer vorliegt, sieht die prüfende Person die verfügbaren Hinweise und entscheidet, welche Rückfrage nötig ist.
Nach der Prüfung bestätigt die verantwortliche Person die vorbereiteten Felder. Der Pilot endet beim freigegebenen Entwurf. Eine spätere Übernahme kann die verantwortliche Person im üblichen Verfahren selbst durchführen. Wenn ein späterer Schritt die Anlage eines Entwurfs unterstützt, übernimmt eine dafür zugelassene Schnittstelle nur die bestätigten Felder. Der Ablauf speichert dann die Referenz des Entwurfs und liest dessen Status zurück.
Zur Auswertung gehören auch falsche oder unvollständige Eingaben. Fehlt eine Bestellreferenz, muss die Person die nächste Aktion erkennen können. Geht eine Rückmeldung verloren, soll der bestehende Vorgang auffindbar bleiben. Das Beispiel beschreibt eine technische und redaktionelle Prüfmethode. Der Nutzen ergibt sich aus dem Test im jeweiligen Unternehmen.
11. Messbare Kriterien für die Abnahme des Piloten
Vereinbaren Sie vor Beginn, was ein erfolgreicher Test zeigen soll. Beispiele sind eine nachvollziehbare Quellenangabe, korrekte Zuordnung für die vereinbarten Felder, passende Reaktionen auf fehlende Daten und wirksame Zugriffsregeln für die festgelegten Rollen. Halten Sie zu jedem Kriterium fest, wer es prüft und welche Beobachtung als Nachweis dient.
Für einen Vergleich mit dem bisherigen Vorgehen braucht das Team dieselben oder fachlich vergleichbare Aufgaben. Messen Sie die Zeit bis zum überprüften Ergebnis einschließlich Rückfragen, Kontrolle und Korrekturen. Erfassen Sie Fälle, die an eine Person zurückgegeben wurden. Die Ergebnisse gelten für den getesteten Ablauf und lassen sich erst anhand weiterer Prüfungen auf andere Vorgänge übertragen.
Prüfen Sie neben dem regulären Ablauf mindestens die wichtigsten Ausnahmen. Dazu zählen eine nicht eindeutige Referenz, fehlende Zugriffsrechte, ein fehlerhaftes Dokument und eine unterbrochene Verbindung. Für jeden Fall soll sichtbar werden, welchen Stand das System behält und wie das Team zur nächsten zulässigen Aktion gelangt.
Am Ende entscheidet das Unternehmen anhand der Beobachtungen, welche Bestandteile übernommen, angepasst oder erneut getestet werden. Diese Entscheidung kann auch ergeben, dass der Pilot beim lesenden Zugriff bleibt. Die Aufzeichnungen helfen dabei, den späteren Aufwand für eine Integration, ihre Pflege und die Betreuung bei Störungen einzuordnen.
12. Praktische Checkliste für die Vorbereitung
Notieren Sie einen Arbeitsablauf, die beteiligten Rollen und den fachlich verantwortlichen Ansprechpartner. Erfassen Sie die vorhandenen Programme mit ihrer Version und den vom Unternehmen freigegebenen Zugriffswegen. Benennen Sie für jedes benötigte Feld die maßgebliche Quelle und halten Sie fest, wie häufig die Angaben aktualisiert werden.
Bereiten Sie ausgewählte Testfälle vor, die sowohl gewöhnliche als auch unvollständige Eingaben enthalten. Definieren Sie, welche Beispiele für den Pilot verwendet werden dürfen und wie Testdaten von laufenden Vorgängen getrennt bleiben. Falls die Anwendung einen Entwurfszustand unterstützt, einigen Sie sich auf dessen genaue Bedeutung und auf die zugehörige Freigaberolle.
Planen Sie den Betrieb mit dem zuständigen Team. Entscheiden Sie, wer Zugänge verwaltet, Änderungen an Exporten meldet, fehlgeschlagene Vorgänge prüft und die Dokumentation aktuell hält. Formulieren Sie die Bedingungen für eine Wiederholung oder einen Abbruch, sodass die zuständige Person den Vorgang anhand einer Referenz wiederfinden kann.
Erstellen Sie zum Schluss eine kurze Liste prüfbarer Ergebnisse. Dazu gehören ein erfolgreicher Durchlauf, ein verweigerter Zugriff und eine nachvollziehbare Reaktion auf einen Ausfall. Legen Sie fest, welche Ergebnisse am Ende übergeben werden. Dazu können die Feldzuordnung, das Testprotokoll und Hinweise zu Grenzen und Wartung gehören.
13. Der nächste Schritt zur eigenen Private-AI-Integration
Bringen Sie für ein erstes Gespräch einen Vorgang mit, der regelmäßig manuelle Suche, Abgleich oder Übertragung erfordert. Eine kurze Beschreibung der vorhandenen Software, der verfügbaren Daten und der beteiligten Rollen reicht aus, um die ersten Fragen einzugrenzen. Beschreiben Sie besonders, was heute bei einer Ausnahme geschieht.
CANIMAPS DIGITAL kann mit Ihnen prüfen, wie sich dieser Vorgang auf der eigenen Private-AI-Basis umsetzen lässt. Die Anpassung kann die Serverumgebung, die Dokumentensuche, Zugriffsrechte und den Anschluss bestehender Anwendungen umfassen. Die konkrete Verbindung hängt von den freigegebenen Schnittstellen und den Anforderungen des Betriebs ab.
Aus der Prüfung sollte ein klarer erster Arbeitsauftrag entstehen. Darin stehen der vorgesehene Datenweg, die erlaubten Aktionen, das Ziel der fachlichen Prüfung und die Behandlung von Fehlern. So können Geschäftsleitung, Fachteam und technische Betreuung beurteilen, welche Schritte der Pilot abdecken soll und welche Fragen noch offen sind.
Wenn Sie eine ERP- oder Buchhaltungsanwendung einbinden möchten, beschreiben Sie die betreffende Aufgabe und das Ergebnis, das Ihre Mitarbeitenden überprüfen sollen. Mit dieser Grundlage lässt sich der Einstieg eingrenzen, bevor zusätzliche Datenquellen und Automatisierungsschritte Teil der Umsetzung werden.
Zum Angebot von CANIMAPS DIGITAL. Individuelle Private AI für Ihr Unternehmen