KAISERSTADT Consulting
KAISERSTADTCONSULTING

Dynamics 365 Integration

Die Schnittstelle ist selten das Problem. Die Reihenfolge ist es.

Wenn Dynamics 365 und das ERP gegeneinander schreiben, liegt die Ursache fast immer vor der ersten Zeile Code: es war nicht geklärt, welches System für welches Datum die Wahrheit hält. Das ist eine fachliche Frage, keine technische — und sie kostet nach dem Go-live ein Vielfaches.

Befund zum FestpreisLage schildern
Microsoft-Partner · Dynamics 365 CE

Vier Wege

Wie Dynamics 365 an ein Umsystem kommt.

Die Wahl des Wegs bestimmt den Betrieb der nächsten Jahre, und sie fällt meistens beiläufig. Deshalb steht hier bei jedem Weg, was er kostet — nicht in Euro, sondern in Abhängigkeit.

Standard-Konnektor

Der richtige Weg, wenn

Wenn das Umsystem einen gepflegten Konnektor hat und die Felder sich ohne Umrechnung zuordnen lassen.

Was er kostet

Am billigsten in der Anschaffung, am teuersten in der Abhängigkeit: was der Konnektor nicht kann, kann man nicht nachbauen.

Power Automate

Der richtige Weg, wenn

Für überschaubare Mengen und Abläufe, die ein Fachbereich später selbst anpassen soll.

Was er kostet

Bei Massen wird es langsam und teuer, weil jeder Lauf zählt. Die Grenze kommt nicht als Fehler, sondern als Rechnung.

Azure-Integrationsschicht

Der richtige Weg, wenn

Wenn mehrere Systeme beteiligt sind, Wiederholversuche und Nachvollziehbarkeit gefordert sind, oder Lasten schwanken.

Was er kostet

Mehr Aufbau, dafür der einzige Weg, auf dem ein Fehler auffindbar bleibt. Bei einem Verband haben wir eine gewachsene Synchronisierung genau dorthin umgezogen.

Eigene Plugins im Dataverse

Der richtige Weg, wenn

Wenn die Logik dort greifen muss, wo der Datensatz entsteht — etwa bei einer Preis- oder Lizenzlogik.

Was er kostet

Der Teil, der bei einem Update als Erstes bricht. Deshalb schreiben wir Unit-Tests dafür; bei einem IT-Dienstleister werden sie seit fünf Jahren mitgeführt.

Die Reihenfolge

Fünf Schritte, und der erste ist der, der übersprungen wird.

Keine Methodik mit Namen, sondern die Abfolge, in der wir Schnittstellen bauen. Sie ist an den Arbeitspaketen der Fälle unten nachlesbar.

  1. 01

    Klären, welches System die Wahrheit hält

    Für jedes Datum genau ein führendes System. Diese Frage klingt banal und ist der Grund, warum Schnittstellen später gegeneinander schreiben: wenn beide Seiten dieselbe Adresse pflegen dürfen, gewinnt der letzte Lauf, nicht der richtige Wert.

  2. 02

    Mapping konzipieren, bevor entwickelt wird

    Feld für Feld, mit den Fällen, in denen es nicht aufgeht: fehlende Werte, abweichende Einheiten, Datensätze ohne Gegenstück. Bei einem Elektrogroßhändler haben wir das Mapping konzipiert und die Umsetzung des beteiligten Partners fachlich gesteuert, statt sie zu wiederholen.

  3. 03

    Richtung und Auslöser festlegen

    Einweg oder beidseitig, ereignisgesteuert oder im Takt. Beidseitig ist die Antwort, die sich niemand traut abzulehnen, und in der Hälfte der Fälle nicht nötig. Jede Richtung, die es nicht gibt, ist eine Fehlerquelle weniger.

  4. 04

    Fehlerfall bauen, nicht nur den Gutfall

    Wiederholversuche, ein Ort, an dem Fehlläufe sichtbar sind, und jemand, der zuständig ist. Eine Schnittstelle ohne Fehlerbehandlung funktioniert genau so lange, wie das Umsystem erreichbar ist.

  5. 05

    Migration getrennt vom Betrieb denken

    Die Erstübernahme der Altdaten ist ein anderes Vorhaben als der laufende Abgleich. Bei einer Ablösung im Großhandel liefen dafür eigene Migrationsdienste und mehrere Testläufe — erst in die Testumgebung, dann nach Review in die Produktion.

Sechs dokumentierte Fälle

Mit Kundennamen, ohne Durchsatzzahlen.

Jeder Fall hat eine eigene Fallstudie mit Laufzeit, Umfang und den Arbeitspaketen — gerendert aus dem konsolidierten Referenz-Datensatz, nicht frei geschrieben.

  • UniElektro

    Elektrogroßhandel

    SAP-Zwei-Wege-Schnittstelle. Wir haben das Mapping konzipiert und die Umsetzung des beteiligten Partners fachlich gesteuert.

    Zur Fallstudie

  • PromoCell

    Life Sciences

    Middleware-Schnittstelle zum ERP, dazu die Anbindung mehrerer E-Commerce-Partner und E-Rechnungsfähigkeit.

    Zur Fallstudie

  • BDU

    Verband

    Technologiewechsel der Synchronisierung auf Azure Functions, im laufenden Betrieb. Dazu die Veranstaltungsverwaltung über eine eigene Schnittstelle.

    Zur Fallstudie

  • IRIS Sales

    Industrie

    Business Central angebunden — mit einem eigenen Arbeitsstrang für die Abstimmung mit dem Integrationspartner. Der lag über der Entwicklung.

    Zur Fallstudie

  • Communardo Gruppe

    IT & Software

    Lizenz- und Rechnungsdaten aus einem Herstellersystem über eigene Plugins, über mehrere Gesellschaften hinweg.

    Zur Fallstudie

  • Axians IT Solutions

    IT & Software

    Eigene Plugins mit Unit-Tests, über fünf Jahre mitgeführt. Der Grund, warum diese Umgebung Updates übersteht.

    Zur Fallstudie

Klartext

Was bei uns nicht passiert.

Vier Zusagen. Die letzte ist die unbequemste, weil sie eine Zahl verweigert, die jeder gern hätte.

  • Wir bauen keine beidseitige Schnittstelle, weil sie im Angebot besser klingt. Wenn eine Richtung reicht, sagen wir das.
  • Wir ersetzen kein Umsystem, um die Anbindung einfacher zu machen. Die Entscheidung über Ihr ERP ist nicht unsere.
  • Wir übernehmen die fachliche Steuerung eines fremden Integrationspartners, ohne dessen Arbeit an uns zu ziehen. Bei Europas größter Frachtenbörse war genau das 36 Monate lang der Auftrag.
  • Wir nennen keine Durchsatzzahlen. Was eine Schnittstelle leistet, hängt an Ihrer Umgebung — eine Zahl aus einem anderen Projekt wäre keine Zusage, sondern eine Anekdote.

Häufige Fragen

Was zuerst gefragt wird.

Brauchen wir eine bidirektionale Schnittstelle?
Seltener als angenommen. Bidirektional heißt, dass beide Seiten dasselbe Datum ändern dürfen — und damit muss geklärt sein, wer gewinnt, wenn beide es gleichzeitig tun. In etwa der Hälfte der Fälle reicht eine Richtung plus ein Lesezugriff. Jede Richtung, die es nicht gibt, ist eine Fehlerquelle weniger und eine Abstimmung weniger im Betrieb.
Ist Dual-Write das Richtige für uns?
Nicht zu verwechseln mit Dual-Write: das ist ein bestimmter Microsoft-Dienst zwischen Dynamics 365 Finance & Operations und Dataverse, kein Wort für Schnittstellen allgemein. Wenn Sie F&O einsetzen, ist er eine ernsthafte Option. Für Business Central, SAP oder eine Eigenentwicklung ist er es nicht — dort ist „Dual-Write" nur ein Wort, das für „Schnittstelle" gebraucht wird, und das führt in Angeboten regelmäßig zu Missverständnissen über den Aufwand.
Wie bindet man SAP an Dynamics 365 an?
Über eine Integrationsschicht, nicht über einen Direktzugriff. Die eigentliche Arbeit liegt nicht in der Technik, sondern im Mapping: welches Feld entspricht welchem, was passiert bei fehlenden Werten, und welches System hält die Wahrheit für Kunde, Preis und Auftrag. Bei einem Elektrogroßhändler haben wir das Mapping konzipiert und die Umsetzung des beteiligten Partners fachlich gesteuert.
Geht DATEV direkt an Dynamics 365?
In der Praxis läuft es über die Rechnungs- und Belegdaten, nicht über eine direkte Kopplung der Buchhaltung. Wir haben DATEV-konforme Rechnungsstellung in einer Verbandslösung umgesetzt, die über fünfzig Vereine bedient. Wichtig ist die Abgrenzung: das CRM erzeugt und übergibt Belege, es ist keine Buchhaltung und soll auch keine werden.
Was kostet eine Schnittstelle?
Das hängt an der Zahl der Felder, der Zahl der Richtungen und daran, wie gut das Umsystem dokumentiert ist — der letzte Punkt ist der teuerste Unbekannte. Wir schätzen erst, wenn das Mapping steht, und nennen dann eine Zeitschiene mit der Schätzung. Eine Zahl vor dem Mapping wäre geraten, und geraten heißt bei Schnittstellen regelmäßig zu niedrig.
Wer betreibt die Schnittstelle nach dem Go-live?
Das gehört vor die Umsetzung geklärt, nicht danach. Eine Schnittstelle braucht jemanden, der Fehlläufe sieht und zuständig ist. Wir bauen die Fehlerbehandlung mit — Wiederholversuche und einen Ort, an dem Fehler sichtbar sind — und übernehmen den Betrieb auf Wunsch im Monatsbudget. Bei mehreren Kunden läuft das seit über fünf Jahren so.
Können wir die Schnittstelle später selbst ändern?
Bei Power Automate ja, in Grenzen — das ist der Grund, warum wir diesen Weg für Abläufe wählen, die ein Fachbereich anpassen soll. Bei einer Azure-Integrationsschicht oder eigenen Plugins ist das Entwicklungsarbeit. Deshalb ist die Wahl des Wegs eine Entscheidung über Ihre eigene Handlungsfähigkeit und nicht nur über die Technik.
Was ist mit den Altdaten?
Die Erstübernahme ist ein eigenes Vorhaben, getrennt vom laufenden Abgleich. Bei einer Ablösung im Großhandel liefen dafür eigene Migrationsdienste und mehrere Testläufe: erst in die Testumgebung, dann nach Review und Nacharbeit in die Produktion. Wer Migration und Betrieb in einem Arbeitspaket plant, verschiebt am Ende beides.

Falls die Lage eine andere ist

Eine Schnittstelle ist selten das erste Thema. Meistens fällt sie auf, weil etwas anderes klemmt — dann ist die Frage, welche der drei Lagen Ihre ist.

Nächster Schritt

Erst der Befund, dann die Schnittstelle.

Wenn schon etwas läuft und nicht trägt, ist der Einstieg ein Audit mit öffentlichem Festpreis. Es sagt Ihnen, welches System die Wahrheit hält und wo sie heute verletzt wird — und es ist nicht an einen Folgeauftrag gebunden, auch nicht an einen mit uns.

Audit mit FestpreisLage schildern
Microsoft-Partner · Dynamics 365 CE

Stand · Verantwortlich: Pascal Peters, Senior Dynamics 365 CE Architect & Inhaber

Zuletzt geprüft: die sechs genannten Fälle gegen den Referenz-Datensatz, inklusive der Sperrlisten für genannte Systeme.