Mobile ERP
Ein Softwarehersteller mit einem ERP-Zusatzmodul für Sage 100 musste seine Lager- und Produktions-App von Windows CE — einer End-of-Life-Plattform — auf moderne Android-Hardware umstellen, ohne…
Fallstudie ansehen →Die Systeme verbinden, die Sie bereits betreiben — und die APIs, die Sie anderen anbieten
Ihre Systeme sollten miteinander sprechen. Meistens tun sie es nicht.
ERP, CRM, Marktplätze, Zahlungsanbieter, Fachverfahren von Behörden, die Middleware eines Herstellers, eine Tabelle, die zum System geworden ist. Die meisten Unternehmen laufen auf einem Flickwerk, das nie dafür gebaut wurde zusammenzuarbeiten. Wir bauen die Integrationsschicht, die es sauber verbindet — und die APIs, die Sie nach außen anbieten, wenn andere Unternehmen sich mit Ihnen verbinden müssen.
Manuelle Brücken skalieren nicht — und stille Brücken sind schlimmer.
Daten werden von Hand neu erfasst. Zwei Systeme halten je eine Version der Wahrheit, und niemand kann die Differenz erklären. Ein vor Jahren geschriebenes Skript bricht alle paar Monate leise, und wer es geschrieben hat, ist längst weg. Der teuerste Fehlerfall ist nicht die Integration, die stehen bleibt, sondern die, die weiterläuft und Datensätze verliert, die niemand bemerkt — bis ein Auditor oder ein Kunde es tut.
Integration wird meist als Nachgedanke behandelt: spät angeschraubt, undokumentiert, aufgegeben, sobald sie einmal funktioniert hat. Wir behandeln sie als Engineering — mit Datenmodell, Fehlerbehandlung, Prüfpfad und einem Verantwortlichen —, weil sie genau das ist.
Was wir bauen.
Integrationen zwischen den Systemen, die Sie betreiben, und Schnittstellen, die Sie Partnern anbieten. Beides mit derselben Disziplin: explizit gemappt, vollständig protokolliert, gefahrlos änderbar.
- ERP- und CRM-Anbindung: Sage 100, SAP über bestehende Middleware und die Eigenentwicklungen drumherum — erweitert um Portale und Mobile-Apps, die ERP-Daten lesen und schreiben, ohne dass jemand neu erfasst
- Marktplatz-, Lager- und Finanzplattformen (Zoho, Sellerboard, Amazon) zu einer Reporting- und Entscheidungsschicht zusammengeführt, mit SKU- und Identifikator-Mapping, das abgleicht, wie jedes System dasselbe Produkt nennt
- Abgleich als Funktion: geplante Importe, die Systeme vergleichen und Abweichungen als prüfbare Ausnahmen ausweisen, statt sie in einer Tabelle verschwinden zu lassen
- Formatbrücken, wo ein Partner das Datenmodell vorgibt — etwa Angebote aus einem Warenwirtschaftssystem in das vorgeschriebene XML-Beschaffungsformat eines großen Anbieters konvertieren
- Fachverfahren mehrerer Behörden hinter einer API vereinheitlicht, damit eine Bürger-App eine konsistente Schnittstelle sieht, egal wie viele Quellen dahinterstehen
- APIs, die Sie anderen anbieten: Design, Versionierung, Dokumentation und Sandboxes, damit ein Partner in Stunden statt Wochen gegen Sie integrieren kann
- Sicherer Transport und Robustheit im Feld: verschlüsselte Tunnel, Wiederholungen und eine sichtbare Warteschlange fehlgeschlagener Uploads — unzuverlässige Verbindungen sind Normalbetrieb, kein Sonderfall
- Monitoring, Protokollierung und ein Import-Prüfpfad, der beantwortet, was wann an welchen Datensatz gesendet wurde und ob es ankam — damit Fehler sofort sichtbar werden statt Monate später
Warum exbisoft.
Die fehlende Schicht zwischen zwei Systemen, die beide funktionieren.
Ein Bekleidungshersteller mit Amazon-Vertrieb betrieb Zoho Inventory und Sellerboard, und keines der beiden konnte die Fragen der Geschäftsführung beantworten. Wir haben die Plattform dazwischen gebaut: geprüfte Importe, SKU-Mapping über vier Identifikationsschemata, automatischer Abgleich, Landed Cost pro Einheit und eine Nachbestell-Werkbank, die Bestellentwürfe zurück nach Zoho schreibt. Keines der Systeme wurde ersetzt.
ERP-Daten dort, wo gearbeitet wird.
Für einen deutschen Maschinenbauer haben wir Sage 100 um ein Einkaufsportal erweitert, in dem internationale Lieferanten Aufträge bestätigen und Lieferungen melden; das ERP bleibt aktuell, ohne dass jemand abtippt. Für einen Softwarehersteller haben wir eine Lager-App an derselben Sage-100-Datenschicht gehalten, während wir sie von Windows CE auf Android gebracht haben.
Gebaut, um Veränderung zu überstehen.
Systeme werden ersetzt, aktualisiert, neu versioniert. Wir mappen explizit, halten das Mapping prüfbar und trennen Transport von Fachregeln — wenn der Partner sein Format ändert oder das ERP ein Upgrade bekommt, ist die Änderung eine Schicht, kein Neubau. Der D!VE-XML-Konverter, den wir gebaut haben, ist dem Format des Anbieters über mehrere Revisionen gefolgt.
Auch die andere Seite des Tisches.
Eine Plattform zur Führerschein-Verlängerung, die wir gebaut haben und betreiben, stellt eine Echtzeit-API bereit, die Partner in Websites, Apps, Kassensysteme und Geldautomaten einbetten. Eine Schnittstelle zu entwerfen, von der andere abhängen, ist eine andere Aufgabe als eine zu konsumieren — wir haben beides gemacht.
Dokumentiert statt Kopfwissen.
Jede Integration wird mit einer Dokumentation ausgeliefert, mit der ein späterer Entwickler tatsächlich arbeiten kann — auch einer, der uns nie getroffen hat —, plus Protokollen, mit denen ein Administrator einen fehlgeschlagenen Datensatz erneut anstößt, ohne jemanden anrufen zu müssen.
Systeme, die miteinander sprechen sollten, es aber nicht tun?
Erzählen Sie uns, was verbunden werden muss, wie jede Seite die Daten nennt und was heute passiert, wenn eine Übertragung fehlschlägt. Wir sagen Ihnen ehrlich, wie viel Arbeit das wirklich ist — und wo das Risiko sitzt.
Gespräch beginnen