Ihre Sensoren sehen eine Menge. Ein Durchflussmesser erfasst den Verbrauch jede Minute. Ein Türkontakt weiß, wann ein Gefrierschrank geöffnet wurde. Ein Motor meldet Vibrationen, die aus dem zulässigen Bereich laufen, bevor er ausfällt. All das ist real, und das meiste davon erreicht nie die Systeme, mit denen Ihr Betrieb tatsächlich läuft. Die Abrechnung passiert im ERP. Die Kundenhistorie liegt im CRM. Das Serviceticket eröffnet eine Person, die vom Problem erst Stunden nach dem Gerät erfährt.
Die Aufgabe besteht darin, diesen Kreis zu schließen. Wenn ein Sensor etwas erkennt, sollte der Betrieb darauf reagieren: Ein Verbrauchswert wird zur Rechnungsposition, eine Störung wird zum Ticket, ein Anlagenwert aktualisiert den Datensatz, auf den Ihr Account-Team schaut. Dieser Beitrag zeigt die Muster, um Gerätedaten an ERP- und CRM-Systeme anzubinden, die Stellen, die Sie einholen, wenn Sie sie überspringen, und wie das auf TagoIO mit der REST API, Analysis-Skripten und Webhook-Actions funktioniert.
Warum Gerätedaten mit Geschäftssystemen verbinden
Gerätedaten für sich allein sind Monitoring. Verbunden mit einem Geschäftssystem werden sie zu Handlung.
Ein paar Beispiele machen den Nutzen greifbar:
- Ein Versorgungszähler meldet den kumulierten Verbrauch. In den Abrechnungszyklus des ERP eingespeist, wird daraus eine korrekte Rechnung ohne manuelle Ablesungen.
- Eine Maschine wirft einen Fehlercode. An das CRM oder ein Außendienstmodul übergeben, eröffnet sich ein Ticket und ein Techniker wird zugewiesen, bevor der Kunde anruft.
- Die Betriebsstunden einer Anlage überschreiten einen Schwellwert. Der Anlagendatensatz aktualisiert sich, und ein Wartungsvertrag wird planmäßig ausgelöst.
- Eine hochwertige Installation verstummt. Der zuständige Vertriebsmitarbeiter, der diesen Account betreut, erhält eine Benachrichtigung, statt es erst beim nächsten Quartalsgespräch zu erfahren.
In jedem Fall wusste das Gerät es bereits. Die Lücke war, dieses Signal in das System zu bekommen, in dem jemand etwas damit anfangen kann.
Die Integrationsmuster
Es gibt eine Handvoll Muster, zu denen Sie greifen werden, und die meisten echten Integrationen kombinieren zwei oder drei davon.
Webhooks. Die Geräteplattform schickt Daten an eine URL, sobald etwas passiert. Das ist die richtige Voreinstellung für Ereignisse: eine Störung, eine Schwellwertüberschreitung, eine Zustandsänderung. Das empfangende System bekommt die Nutzlast im Moment, in dem sie zählt, und Sie müssen nicht pollen.
REST APIs. Die Pull-Seite derselben Medaille. Ihr ERP oder CRM, oder ein Skript dazwischen, ruft einen Endpunkt auf, um Gerätedaten bei Bedarf oder nach Zeitplan zu lesen. Gut für Batch-Synchronisierung, etwa das nächtliche Abrufen eines Tages voller Zählerstände, und für jedes System, das lieber fragt, als informiert zu werden.
Middleware und iPaaS. Tools wie n8n, Make oder eine Workflow-Engine sitzen zwischen Plattform und Geschäftssystem. Sie übernehmen Wiederholungsversuche, Transformation und das unbequeme Mapping, wenn die Feldnamen des einen Systems nicht zu denen des anderen passen. Sobald Sie mehr als ein Zielsystem haben oder die Logik verzweigt wird, hält Middleware das aus beiden Enden heraus.
Ereignisgesteuerte Trigger. Logik, die läuft, wenn eine Bedingung erfüllt ist, statt im Takt einer Uhr. Ein Messwert trifft ein, eine Regel wertet ihn aus, und eine Aktion feuert nur, wenn die Bedingung zutrifft. So vermeiden Sie, das CRM mit jedem Messwert zu bombardieren, wenn Sie nur die interessieren, die eine Grenze überschreiten.
Überlegungen zu Datenmapping und Synchronisierung
Hier brechen Integrationen still und leise zusammen. Der Transport ist der einfache Teil. Zwei Systeme dazu zu bringen, sich über dieselben Fakten einig zu sein, ist der schwere Teil.
Bezeichner. Jedes Gerät braucht ein stabiles Mapping zu seinem Gegenstück im Geschäftssystem: ein Gerät zu einem Anlagendatensatz, ein Zähler zu einem Kundenkonto, eine Maschine zu einem Servicevertrag. Entscheiden Sie, wo dieses Mapping lebt, und halten Sie es maßgeblich. Versehen Sie das Gerät mit der ERP-Anlagen-ID, oder pflegen Sie eine Lookup-Tabelle, die die Integration liest. Was Sie nicht wollen, ist ein Abgleich über Namen, die nächstes Quartal jemand umbenennt.
Häufigkeit. Passen Sie die Synchronisierungsrate an den Anwendungsfall an. Abrechnungsablesungen können täglich laufen. Störungstickets müssen in Sekunden feuern. Anlagen-Laufzeitaktualisierungen sind vielleicht stündlich. Alles in Echtzeit zu senden ist verschwenderisch und führt zu Rate-Limits beim Zielsystem. Zu langsam zu senden bedeutet veraltete Datensätze.
Idempotenz. Netze wiederholen. Wenn eine Webhook-Zustellung eine Zeitüberschreitung hat und erneut feuert, wollen Sie keine zwei Rechnungen oder zwei doppelten Tickets. Geben Sie jedem Ereignis einen eindeutigen Schlüssel, anhand dessen das empfangende System Duplikate erkennen kann, und entwerfen Sie die Zieloperation so, dass eine zweite Ausführung mit demselben Schlüssel beim zweiten Mal nichts ändert.
Authentifizierung und Sicherheit
Sie verbinden eine operative Plattform mit Systemen, die Geld und Kundendaten halten, also kommt es auf die Zugangsdaten an.
Verwenden Sie eingeschränkte Token, keine kontoweiten Schlüssel. Der Token, mit dem eine Integration einen Zählerstand ins ERP schreibt, sollte genau das können und sonst nichts. Bei einem Leck ist der Schaden auf eine Operation begrenzt, nicht auf Ihr ganzes Konto.
Wenden Sie auf beiden Seiten das Prinzip der geringsten Rechte an. Die TagoIO-Seite liest nur die Geräte, die die Integration braucht. Die ERP- oder CRM-Seite akzeptiert Schreibzugriffe nur auf die Objekte im Geltungsbereich. Rotieren Sie Schlüssel nach Zeitplan und speichern Sie sie dort, wo sie nicht im Klartext in einem Skript liegen. TagoIO ist nach ISO 27001 zertifiziert und GDPR-konform, aber diese Haltung trägt nur, wenn die Zugangsdaten, die Sie ausstellen, derselben Disziplin folgen.
Wie TagoIO ERP- und CRM-Systeme anbindet
TagoIO liefert keinen Ein-Klick-Button für SAP oder Salesforce, und Sie sollten jeder Plattform misstrauen, die einen vorgefertigten Connector für jedes Enterprise-System behauptet. Was TagoIO Ihnen gibt, sind die Bausteine, um die Integration selbst zu verdrahten, mit der Logik dort, wo Sie sie sehen und ändern können.
Die REST API. Jedes Gerät, jede Variable und jedes gespeicherte Datum ist über die API erreichbar. Ein externes System, oder ein iPaaS wie n8n, kann Messwerte nach Zeitplan abrufen und ins Ziel schreiben. Ihre NetSuite-Integration kann die TagoIO API nächtlich aufrufen, den Tagesverbrauch pro Zähler lesen und Rechnungspositionen buchen.
Analysis-Skripte. Das sind serverlose Skripte, die innerhalb von TagoIO laufen, in Node.js oder Python. Hier passiert üblicherweise die eigentliche Arbeit. Eine Analysis kann auf eingehende Daten reagieren, eine Bedingung auswerten, die Nutzlast in die Form bringen, die das Zielsystem erwartet, und die ERP- oder CRM-API direkt aufrufen. Die Anbindung an HubSpot oder Salesforce wird zu einer Frage eines HTTP-Aufrufs aus Ihrem Skript an deren API mit einem eingeschränkten Token, plus der Mapping-Logik dazwischen. Weil es in der Plattform läuft, müssen Sie keinen Server aufstellen, um es zu hosten.
Webhook-Actions. TagoIO Actions können einen Webhook feuern, wenn eine Bedingung erfüllt ist. Eine Störungsvariable überschreitet einen Schwellwert, die Action sendet an Ihren Service-Desk-Endpunkt, und ein Ticket öffnet sich. Für ereignisgesteuerte Arbeit, bei der Sie einen Push in dem Moment wollen, in dem etwas passiert, ist das der kürzeste Weg. Kombinieren Sie ihn mit einer Analysis, wenn die Nutzlast umgeformt werden muss, bevor sie SAP oder Ihr CRM erreicht.
Eine häufige Form für eine echte Integration: Eine Action erkennt das Ereignis, ein Analysis-Skript formt und reichert die Daten an und kümmert sich um Idempotenz, und das Skript ruft die REST API des Enterprise-Systems mit einem eingeschränkten Token auf. Das deckt den Fall Störung-zu-Ticket, den Fall Verbrauch-zu-Rechnung und den Fall Anlagenaktualisierung mit denselben drei Bausteinen in unterschiedlicher Anordnung ab.
Womit Sie anfangen
Greifen Sie sich einen Kreislauf, der heute manuell läuft, und schließen Sie ihn. Verbrauch-zu-Rechnung und Störung-zu-Ticket sind die beiden, die sich am schnellsten auszahlen, weil sie eine Person aus einem sich wiederholenden Pfad nehmen. Mappen Sie zuerst die Bezeichner, legen Sie die Synchronisierungshäufigkeit fest, bauen Sie die Analysis, die die Transformation macht, und testen Sie Idempotenz, indem Sie dasselbe Ereignis bewusst zweimal feuern. Sobald ein Kreislauf von Anfang bis Ende funktioniert, folgt der Rest demselben Muster.
