InSyca IT Solutions GmbH

InSyca IT Solutions GmbH E-Business Kommunikation | Datenintegration | Prozessautomatisierung
Wir sorgen für einen flüssige

Viele Unternehmen starten mit Peppol über die E-Rechnung.Eine Peppol-ID wird registriert, das Buchhaltungssystem wird an...
17/06/2026

Viele Unternehmen starten mit Peppol über die E-Rechnung.

Eine Peppol-ID wird registriert, das Buchhaltungssystem wird angebunden, Rechnungen kommen an und der Prozess läuft. Auf den ersten Blick scheint das Thema damit erledigt zu sein.

In der Praxis ist das aber oft nur der Anfang.

Denn Peppol ist nicht nur ein Kanal für Rechnungen. Über Peppol können auch andere Geschäftsnachrichten ausgetauscht werden: Bestellungen, Lieferscheine, Statusmeldungen oder weitere prozessbezogene Dokumente.

Und genau dann wird aus einer E-Rechnungsanbindung plötzlich eine Architekturfrage.

Ein Unternehmen nutzt Peppol bereits für die Buchhaltung. Später kommt ein Transport Management System hinzu. Danach vielleicht ein ERP-Modul, ein Lagerprozess oder eine Beschaffungslösung.

Dann stellt sich eine Frage, die technisch klingt, aber strategisch ist:

Wer soll diese Nachrichten eigentlich empfangen?

Das Buchhaltungssystem? Das TMS? Das ERP? Oder bekommt jedes System seine eigene ID und eigene Anbindung?

Am Anfang wirkt die letzte Variante pragmatisch. Man löst das konkrete Problem, verbindet das nächste System und macht weiter. Doch mit jeder neuen Ausnahme wächst die Komplexität. Aus einer Schnittstelle werden viele Sonderwege. Aus klaren Zuständigkeiten werden Grauzonen. Und irgendwann weiß im Fehlerfall niemand mehr sofort, wo ein Dokument gelandet ist oder warum es nicht verarbeitet wurde.

Das eigentliche Problem ist dann nicht Peppol.

Das Problem ist fehlendes internes Routing.

Peppol adressiert eine Empfängeridentität. Aber Peppol entscheidet nicht, welcher interne Prozess, welches System oder welche Abteilung eine Nachricht weiterverarbeiten soll. Diese Entscheidung muss innerhalb des Unternehmens sauber gesteuert werden.

Genau hier setzt linQsupply® an.

linQsupply® schafft einen zentralen Eingang für digitale Geschäftsnachrichten und verteilt sie anschließend intelligent an die richtigen Systeme. Rechnungen gehen an die Buchhaltung, transportrelevante Nachrichten an das TMS, Bestellungen an ERP oder Beschaffung. Validierung, Monitoring und Fehlerbehandlung bleiben dabei zentral nachvollziehbar.

Und dieser Gedanke ist nicht auf Peppol beschränkt.

Auch außerhalb von Peppol gilt: Wenn Unternehmen digitale Prozesse skalieren wollen, brauchen sie keine wachsende Sammlung einzelner Schnittstellen und IDs. Sie brauchen eine klare Integrationsschicht, die Ordnung schafft, bevor Komplexität zum Risiko wird.

Denn Digitalisierung scheitert selten an der ersten Anbindung.

Sie scheitert daran, dass viele kleine Einzellösungen irgendwann kein steuerbares Gesamtbild mehr ergeben.

Die entscheidende Frage lautet deshalb nicht:

„Haben wir Peppol angebunden?“

Sondern:

„Haben wir unsere digitalen Nachrichtenflüsse so organisiert, dass unser Unternehmen damit skalieren kann?“

Mit linQsupply® schaffen wir genau diese Grundlage.

09/06/2026

Wenn ich heute auf die gesamte Reise zurückblicke, überrascht mich eine Erkenntnis bis heute: Der wichtigste Erfolgsfaktor war nicht Azure. Nicht die Architektur. Nicht Service Bus, Functions oder irgendeine andere Technologie.

Nach fast zehn Jahren Betrieb hatten sich Prozesse verändert, Sonderfälle etabliert und Entscheidungen angesammelt, die irgendwann einfach Teil des Systems geworden waren. Je tiefer wir eingestiegen sind, desto häufiger haben wir gemerkt, dass die eigentliche Herausforderung nie darin bestand, Technologie zu migrieren. Die größere Herausforderung war zu verstehen, warum Dinge überhaupt so geworden sind.

Was aus meiner Sicht einen entscheidenden Unterschied gemacht hat, war die Zusammenarbeit. Wir hatten auf Kundenseite einen festen fachlichen Ansprechpartner, mit dem wir sehr eng gearbeitet haben. Jemand, der Prozesse verstanden hat, erreichbar war und vor allem Entscheidungen treffen konnte. Das klingt erstmal unspektakulär, hat aber wahrscheinlich mehr Einfluss auf den Projekterfolg gehabt als jede Technologieentscheidung.

Rückblickend glaube ich deshalb: Große Migrationen scheitern selten an Technologie. Sie scheitern oft an langsamen Entscheidungen, fehlender Fachlichkeit oder daran, dass Zusammenarbeit unterschätzt wird.

Technologie war am Ende der Enabler.

Der eigentliche Erfolgsfaktor waren Menschen.

Danke fürs Mitlesen.

04/06/2026

Vor dem Go-Live hatten wir ehrlich gesagt eine ziemlich klare Erwartung. Nach einer Migration verschwindet Komplexität normalerweise nicht einfach. Sie verlagert sich. Neue Plattform, neue Prozesse, neue Abläufe – und meistens entstehen an anderer Stelle neue Fragen. Deshalb sind wir davon ausgegangen, dass die ersten Monate vor allem eines bringen würden: Supportfälle.

Umso überraschter waren wir nach dem Abschalten des letzten BizTalk-Prozesses. Die neue Plattform läuft inzwischen seit rund sechs Monaten produktiv und rückblickend hatten wir weniger Supportfälle als vorher. Nicht weil plötzlich alles perfekt geworden ist und auch nicht, weil Azure irgendein magisches Problem gelöst hätte.

Rückblickend glauben wir eher, dass der Unterschied an einer ganz anderen Stelle lag. Während der Migration haben wir Prozesse nicht einfach kopiert. Wir haben sie hinterfragt, vereinfacht und an vielen Stellen bewusst neu gedacht. Genau das merkt man später im Alltag.

Denn am Ende zeigt sich die Qualität einer Architektur nicht beim Go-Live, sondern Monate später im Betrieb. Und manchmal erkennt man Erfolg nicht daran, was neu dazugekommen ist – sondern an den Dingen, die plötzlich nicht mehr passieren.

Im nächsten und letzten Beitrag geht es um die wichtigste Erkenntnis der gesamten Reise. Und überraschenderweise hat sie nur wenig mit Technologie zu tun.

03/06/2026

Während der Migration gab es einen Effekt, den wir anfangs überhaupt nicht auf dem Schirm hatten. Je mehr Prozesse nach Azure umgezogen sind, desto häufiger tauchte eine ganz praktische Frage auf: Wie kommen Kunden, Lieferanten oder Partner eigentlich an Informationen?

Über die Jahre hatte sich ein Muster entwickelt, das wahrscheinlich viele kennen. Sobald irgendwo etwas unklar war, wurde gefragt: Wurde die Nachricht verarbeitet? Welcher Status liegt vor? Ist etwas schiefgelaufen? Und irgendwann wurde uns klar, dass das eigentliche Problem oft gar nicht fehlende Informationen waren.

Das Problem war die Abhängigkeit.

Denn jedes Mal jemanden fragen zu müssen, erzeugt Wartezeiten, Rückfragen und unnötige Schleifen. Also haben wir angefangen, Informationen und Funktionen kontrolliert nach außen bereitzustellen – nicht als technische Spielerei, sondern damit Partner und Stakeholder Dinge selbst nachvollziehen konnten, ohne auf Rückmeldungen angewiesen zu sein.

Rückblickend war die Erkenntnis überraschend einfach: Viele Supportanfragen entstehen nicht durch Fehler. Sie entstehen, weil Transparenz fehlt.

Im nächsten Beitrag geht es um etwas, das uns nach dem Go-Live selbst überrascht hat: Warum es plötzlich weniger Supportfälle gab als früher.

02/06/2026

Während der Migration ist uns noch etwas aufgefallen, das anfangs ziemlich harmlos wirkte.

Über fast zehn Jahre hatten sich unzählige Regeln angesammelt. Manche waren fachlich wichtig, andere historisch gewachsen und einige existierten einfach deshalb, weil sie irgendwann einmal sinnvoll waren.

Das Problem war nicht die Regel selbst.

Das Problem war, wo sie lebte.

Denn über Jahre wandern Entscheidungen oft direkt in Systeme. Irgendwann steckt Fachlichkeit in Konfigurationen, Plattformfunktionen oder fest eingebauter Logik. Und plötzlich wird aus einer kleinen Änderung ein eigenes Projekt.

Je länger wir Prozesse hinterfragt haben, desto häufiger kam dieselbe Frage auf:

Muss diese Entscheidung wirklich fest im System verankert sein?

Oder braucht sie einfach einen Ort, an dem sie sich kontrolliert ändern lässt?

Rückblickend war das eine überraschend wichtige Erkenntnis. Denn je geschäftskritischer Prozesse werden, desto wichtiger wird nicht nur Stabilität.

Sondern auch Veränderbarkeit.

Im nächsten Beitrag geht es um etwas, das wir anfangs völlig unterschätzt haben:

Warum API Management plötzlich mehr wurde als nur ein Gateway.

28/05/2026

Während der Migration gab es eine Entscheidung, über die wir anfangs selbst kurz gestolpert sind.

Je mehr Transparenz wir aufgebaut haben, desto häufiger kamen Rückfragen aus den Fachbereichen. Nicht technische Fragen, sondern ganz praktische: Wo finde ich eine bestimmte Nachricht? Was wurde an einen Geschäftspartner gesendet? Was genau ist bei einer Reklamation passiert?

Unsere erste Reaktion war ziemlich naheliegend. App Insights, Logs, Dashboards – technisch gab es genug Möglichkeiten. Aber irgendwann wurde uns klar, dass wir gerade ein IT-Problem lösen wollten, obwohl die eigentliche Frage eine ganz andere war.

Die Menschen wollten keine Telemetriedaten durchsuchen und keine Plattform verstehen. Sie wollten einfach Antworten.

Also haben wir die Nachrichten strukturiert nach System, Geschäftspartner und Prozess abgelegt. Stakeholder konnten sich den Pfad sogar lokal einbinden und Informationen direkt dort finden, wo sie ohnehin täglich arbeiten.

Rückblickend war die Erkenntnis überraschend einfach:

Nicht jede gute Lösung muss besonders modern wirken.

Manchmal ist die beste Lösung einfach die, die Menschen ohne Erklärung sofort verstehen.

Im nächsten Beitrag geht es um etwas, das wir während der Migration komplett neu denken mussten:

Warum Konfiguration plötzlich wichtiger wurde als feste Regeln.

27/05/2026

Eine Sache haben wir während der Migration komplett unterschätzt: Transparenz.

Am Anfang dachten wir, die eigentlichen Herausforderungen liegen in der Architektur, der Migration oder den Prozessen selbst. Aber je mehr Prozesse wir Schritt für Schritt aus der alten Plattform herausgelöst haben, desto öfter kamen im Alltag Fragen auf, die wahrscheinlich jeder kennt, der geschäftskritische Integrationen betreibt:

Ist die Nachricht angekommen? Wurde sie verarbeitet? Was passiert gerade im System?

Und irgendwann ist uns aufgefallen, dass diese Fragen eigentlich etwas anderes aussagen. Sie zeigen vor allem, dass man versucht zu verstehen, was im Hintergrund gerade passiert.

Solange wenige Prozesse laufen, funktioniert das noch. Aber wenn täglich tausende geschäftskritische Abläufe darüber laufen, reicht ein einfaches „läuft“ irgendwann nicht mehr aus.

Relativ früh wurde uns klar, dass wir nicht einfach eine neue Plattform aufbauen wollten. Wir wollten einen Zustand schaffen, in dem nachvollziehbar ist, was passiert – nicht erst dann, wenn etwas schiefläuft, sondern jederzeit.

Rückblickend war das wahrscheinlich eine der größten Veränderungen überhaupt. Denn aus einem eher reaktiven Supportmodell wurde Schritt für Schritt ein Betrieb, bei dem deutlich mehr Transparenz und Kontrolle entstanden ist.

Im nächsten Beitrag geht es um eine Entscheidung, die uns selbst überrascht hat:

Warum wir plötzlich wieder angefangen haben, über Dateifreigaben nachzudenken.

26/05/2026

Während der Migration gab es einen Moment, der zunächst völlig unspektakulär wirkte – und sich später als ziemlich interessante Erkenntnis herausgestellt hat.

Je tiefer wir Prozesse auseinandergenommen haben, desto häufiger sind wir auf Dinge gestoßen, die seit Jahren einfach liefen. Nicht, weil sie bewusst irgendwann als optimale Lösung entworfen wurden, sondern weil sie sich über die Zeit etabliert hatten.

Systeme haben geprüft, ob neue Daten da sind. Gewartet. Wieder geprüft. Nochmal gewartet.

Und ehrlich gesagt hinterfragt man das irgendwann nicht mehr. Solange etwas stabil läuft, wirkt es plötzlich ganz normal.

Bis man anfängt, wirklich hinzusehen.

Irgendwann saßen wir zusammen und stellten uns eine erstaunlich einfache Frage:

Warum beschäftigen wir Systeme eigentlich dauerhaft damit festzustellen, dass gerade nichts passiert?

Je länger wir darüber gesprochen haben, desto klarer wurde: Viele Integrationen sind permanent aktiv, obwohl fachlich oft überhaupt keine Aktivität stattfindet.

Und plötzlich war das keine technische Diskussion mehr.

Denn jedes dauerhaft laufende System erzeugt Betrieb, Aufmerksamkeit und Komplexität. Und genau diese Dinge wachsen über Jahre oft still mit, ohne dass sie jemand wirklich bemerkt.

Ab diesem Punkt haben wir angefangen, Prozesse anders zu betrachten. Nicht mehr mit der Frage:

„Wer schaut regelmäßig nach?“

Sondern eher:

„Wer meldet sich, wenn wirklich etwas passiert?“

Klingt erstmal nach einem kleinen Unterschied.

Rückblickend hat genau diese Denkweise aber erstaunlich viel verändert.

Im nächsten Beitrag geht es um etwas, das wir anfangs komplett unterschätzt haben:

Warum Transparenz plötzlich wichtiger wurde als Funktionen.

21/05/2026

Einer der spannendsten Momente kam überraschend früh.

Nicht bei der Infrastruktur.

Nicht bei Azure.

Sondern bei einer einfachen Frage:

Was migrieren wir hier eigentlich wirklich?

Denn sobald man tiefer einsteigt, merkt man schnell: Man migriert selten nur Technologie.

Man migriert Gewohnheiten.

Architekturen.

Und manchmal sogar Abhängigkeiten, die über Jahre ganz selbstverständlich geworden sind.

Plötzlich standen Fragen im Raum, über die vorher kaum jemand nachgedacht hatte:

Brauchen wir dafür wirklich eine spezielle Plattformfunktion?

Brauchen wir proprietäre Designer?

Brauchen wir Spezialwissen, das nur wenige Menschen beherrschen?

Oder lösen wir eigentlich ein Problem, das vor zehn Jahren entstanden ist?

Und genau dort kam eine Erkenntnis, die ich rückblickend extrem spannend finde:

Je geschäftskritischer Systeme werden, desto gefährlicher wird Spezialwissen.

Nicht weil es schlecht ist.

Sondern weil Unternehmen dadurch abhängig werden.

Deshalb haben wir bewusst versucht, Standardwissen stärker zu nutzen: native Entwicklung, bekannte Technologien und Architekturen, die auch in Zukunft einfacher verständlich und erweiterbar bleiben.

Rückblickend ging es dabei nie um BizTalk oder Azure.

Es ging um Kontrolle.

Und darum, Komplexität nicht einfach weiterzuvererben.

Im nächsten Beitrag geht es um eine Entscheidung, die fast alle überrascht hat:

Warum wir plötzlich angefangen haben, mehr auf Events zu setzen – und weniger auf Polling.

20/05/2026

Vor rund einem Jahr dachten wir zunächst, dass wir vor einer klassischen Migration stehen.

BizTalk raus. Azure rein.

Fertig.

Zumindest war das der Plan.

Aber je tiefer wir in die bestehende Landschaft eingestiegen sind, desto deutlicher wurde: Wir migrieren hier nicht einfach eine Plattform.

Wir migrieren zehn Jahre Entscheidungen.

Und genau das war der Punkt, an dem es spannend wurde.

Denn über Jahre entsteht etwas, das fast jede gewachsene Plattform irgendwann entwickelt:

Kleine Sonderwege.
Zusätzliche Regeln.
Workarounds.
Historische Entscheidungen.

Nichts davon ist falsch.

Jede einzelne Entscheidung hatte irgendwann ihren Grund.

Aber plötzlich stellt man sich eine unbequeme Frage:

Brauchen wir das heute überhaupt noch?

Und genau hier haben wir eine Entscheidung getroffen, die sich später als einer der größten Erfolgsfaktoren herausgestellt hat:

Wir wollten nicht einfach BizTalk nach Azure verschieben.

Wir wollten bewusst vermeiden, alte Probleme in eine neue Plattform mitzunehmen.

Denn neue Technologie löst keine alten Entscheidungen.

Sie macht sie oft nur teurer.

Im nächsten Beitrag geht es um einen Punkt, der uns dabei überrascht hat:

Warum Plattformmigration am Ende weniger mit Technik zu tun hatte als gedacht.

Adresse

Finsinger Feld 5
Ottobrunn
85521

Öffnungszeiten

Montag 09:00 - 18:00
Dienstag 09:00 - 18:00
Mittwoch 09:00 - 18:00
Donnerstag 09:00 - 18:00
Freitag 09:00 - 18:00

Telefon

+498921546094

Webseite

, ,

Benachrichtigungen

Lassen Sie sich von uns eine E-Mail senden und seien Sie der erste der Neuigkeiten und Aktionen von InSyca IT Solutions GmbH erfährt. Ihre E-Mail-Adresse wird nicht für andere Zwecke verwendet und Sie können sich jederzeit abmelden.

Service Kontaktieren

Nachricht an InSyca IT Solutions GmbH senden:

Verknüpfungen

Teilen

Kategorie