InSyca IT Solutions GmbH

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

Eine API ist noch keine Integration.Wir arbeiten gerade an einer Integration, bei der wir eine API des Kunden nutzen müs...
20/08/2026

Eine API ist noch keine Integration.

Wir arbeiten gerade an einer Integration, bei der wir eine API des Kunden nutzen müssen. Eigentlich nichts Besonderes: Wir übergeben die Daten, die API nimmt sie entgegen und bestätigt uns den erfolgreichen Aufruf. Bei der Umsetzung sind wir allerdings auf einen interessanten Fehlerfall gestoßen. Die API akzeptiert unseren Request, bei der anschließenden Verarbeitung kann der Geschäftsvorgang trotzdem scheitern, ohne dass wir darüber eine Rückmeldung bekommen. Technisch ist damit alles erfolgreich. Fachlich wissen wir aber nicht, ob der Vorgang tatsächlich verarbeitet wurde.

Natürlich könnten wir uns auf die erfolgreiche Antwort verlassen und die Verarbeitung bei uns als erledigt markieren. Das wäre technisch sogar nachvollziehbar. Nur hätten wir damit einen Prozess gebaut, von dem wir wissen, dass er uns im Fehlerfall nicht die Wahrheit sagt. Also müssen wir einen anderen Weg finden, den tatsächlichen Status zu ermitteln und einen fehlgeschlagenen Vorgang gegebenenfalls erneut zu verarbeiten, ohne dabei eine Dublette zu erzeugen. Genau an solchen Stellen zeigt sich für mich, dass Integration eben mehr ist als zwei Systeme technisch miteinander sprechen zu lassen.

„Das System hat doch eine API“ höre ich seit Jahren in Integrationsprojekten. Und natürlich machen gute APIs unsere Arbeit erheblich einfacher. Ich halte es trotzdem für einen Fehler, technische Erreichbarkeit mit Integration gleichzusetzen. Eine API kann mir bestätigen, dass sie meine Nachricht erfolgreich angenommen hat. Mich interessiert aber, ob der Geschäftsvorgang erfolgreich war. Das klingt nach einem kleinen Unterschied, kann aber eine völlig andere Architektur erfordern. Für mich ist genau das die Grenze zwischen einer Anbindung und echter Integration.

Ein automatisierter Ablauf ist noch kein automatisierter Geschäftsprozess. Auf einer Demo sieht Automatisierung meistens...
18/08/2026

Ein automatisierter Ablauf ist noch kein automatisierter Geschäftsprozess.

Auf einer Demo sieht Automatisierung meistens ziemlich einfach aus. Ein Ereignis startet den Ablauf, Daten werden verarbeitet, ein anderes System wird angesprochen und ein paar Sekunden später ist alles erledigt.

Das funktioniert heute mit vielen Tools erstaunlich schnell. Nur würde ich deshalb noch nicht von Business Process Automation sprechen.

Im echten Betrieb wird es ohnehin erst interessant, wenn etwas nicht funktioniert. Das ERP ist nicht erreichbar, Daten fehlen oder ein Vorgang bleibt irgendwo in der Verarbeitung hängen. Plötzlich muss entschieden werden, ob erneut verarbeitet werden kann, wie Dubletten verhindert werden und wann tatsächlich ein Mensch eingreifen muss.

Ein wirklich automatisierter Geschäftsprozess muss deshalb seinen Zustand kennen, mit erwartbaren Fehlern umgehen können und sichtbar machen, wenn er selbst nicht mehr weiterkommt. Retry, Validierung und Monitoring sind keine technischen Extras. Ohne sie funktioniert die Automatisierung nur, solange alles nach Plan läuft.

Deshalb halte ich auch die Anzahl automatisierter Workflows für eine ziemlich schlechte KPI.

Wer den Erfolg von Business Process Automation an der Anzahl seiner Workflows misst, misst Aktivität, nicht Automatisierung.

Für mich zählt, wie viele Geschäftsvorgänge zuverlässig ihr Ziel erreichen, ohne dass ihnen jemand hinterherlaufen muss.

Alles andere ist vielleicht automatisiert. Aber noch lange nicht fertig.

Neulich war ich in einer Bäckerei und wurde mit einem freundlichen „Guten Tag, wie kann ich Ihnen helfen?“ begrüßt. Eige...
13/08/2026

Neulich war ich in einer Bäckerei und wurde mit einem freundlichen „Guten Tag, wie kann ich Ihnen helfen?“ begrüßt. Eigentlich völlig normal. Trotzdem ist es mir aufgefallen. Wahrscheinlich, weil man heute schon positiv überrascht ist, wenn jemand freundlich ist, zuhört und wirklich helfen möchte.

Im geschäftlichen Umfeld erlebe ich etwas Ähnliches. Ich spreche mit erstaunlich vielen Unternehmen, die mit ihren IT-Dienstleistern unzufrieden sind. Nicht unbedingt, weil die Technik schlecht ist. Sondern weil Rückmeldungen dauern, Zuständigkeiten unklar sind und der Kunde seinem eigenen Problem hinterherlaufen muss.

Dabei muss guter Service gar nicht bedeuten, sofort eine Lösung zu haben. Oft reicht zunächst ein klares: „Ich kümmere mich darum und melde mich spätestens bis Ende des Tages.“ Und wenn die Lösung länger dauert, braucht es einen verlässlichen Feedback-Zyklus. Einfach „Ich melde mich“ zu sagen und dann zwei Wochen nichts hören zu lassen, ist keine Betreuung.

Gleichzeitig automatisieren wir immer mehr genau den Moment, in dem ein Kunde Hilfe sucht. Banken, Telekommunikationsanbieter und viele andere setzen Bots ein. Für die erste Einordnung finde ich das völlig in Ordnung. Wenn mein Anliegen damit schnell gelöst wird: perfekt. Aber genauso selbstverständlich muss es einen kurzen Weg geben zu sagen: „Ich möchte mit jemandem sprechen.“

Ich habe überhaupt nichts gegen KI. Im Gegenteil, wir setzen sie selbst intensiv ein. Aber Technologie sollte Routine übernehmen, damit Menschen mehr Zeit für die Fälle haben, in denen sie wirklich gebraucht werden.

Für mich ist guter Service deshalb am Ende erstaunlich einfach: zuhören, Verantwortung übernehmen, Erwartungen klar machen und verlässlich zurückmelden.

Nicht immer sofort lösen.

Aber immer dafür sorgen, dass der Kunde weiß: Jemand kümmert sich – und ich weiß, wann ich wieder etwas höre.

Vor ein paar Tagen konnten wir ein Peppol-Dokument nicht zustellen. Die Ursache war schnell gefunden: Beim Service Provi...
11/08/2026

Vor ein paar Tagen konnten wir ein Peppol-Dokument nicht zustellen. Die Ursache war schnell gefunden: Beim Service Provider des Empfängers war im SMP ein falscher Endpoint hinterlegt.

Eigentlich kein großes technisches Problem. Schwieriger war, dass wir die Kollegen auf der anderen Seite nicht direkt erreichen konnten. Also informierten wir unseren Kunden, unser Kunde seinen Kunden und dieser wiederum seinen Service Provider. Fünf Tage später haben wir erneut getestet – und der Endpoint funktionierte wieder. Eine Rückmeldung dazu gab es nicht.

Was mich daran stört, ist nicht der Fehler. Fehler passieren. Auch uns. Und wir waren selbst schon froh, wenn Kollegen uns direkt angesprochen haben. Dann sprechen zwei technische Ansprechpartner miteinander, finden die Ursache und lösen das Problem. Der Kunde bekommt davon im besten Fall kaum etwas mit – genau so sollte Service funktionieren.

Aus diesem Fall ist deshalb eine einfache Idee entstanden: Warum gibt es kein zentrales Register mit Fast Contacts für Peppol Service Provider? Wir haben den Vorschlag bei der KoSIT eingebracht – und dort war man sofort bereit, das Thema bei OpenPeppol weiter zu promoten.

Denn ein digitales Netzwerk funktioniert für mich nicht nur dann gut, wenn Systeme miteinander sprechen können. Auch die Menschen, die diese Systeme betreiben, müssen sich im Problemfall unkompliziert erreichen können.

Der Kunde sollte nicht unsere Kommunikationsschnittstelle sein.

Er sollte einfach erwarten dürfen, dass sein Dokument ankommt – und dass wir den Rest untereinander klären.

Unsere Daten liegen in Europa.Dieser Satz klingt beruhigend. Aber er beantwortet noch nicht die entscheidende Frage: Sin...
05/08/2026

Unsere Daten liegen in Europa.

Dieser Satz klingt beruhigend. Aber er beantwortet noch nicht die entscheidende Frage: Sind die Daten dadurch wirklich besser geschützt?

Ein Serverstandort verhindert keine gestohlenen Identitäten, keine Fehlkonfigurationen, keine zu weitreichenden Berechtigungen und keinen Ransomware-Angriff. Auch ausländische Angreifer halten sich nicht an Landesgrenzen. Natürlich spielt die Jurisdiktion eine Rolle, und ein europäischer Anbieter kann bestimmte rechtliche Risiken reduzieren. Aber Datensouveränität und Datensicherheit sind nicht dasselbe.

Genau deshalb ist Informationssicherheit eine Führungsaufgabe. Ein gelebtes Informationssicherheitsmanagement zwingt Unternehmen dazu, die eigenen Annahmen zu hinterfragen: Welche Daten sind wirklich kritisch? Wer benötigt Zugriff? Wie werden privilegierte Konten geschützt? Wie erkennen wir einen Angriff? Und funktioniert unsere Wiederherstellung im Ernstfall tatsächlich?

Dabei gehört auch eine unbequeme Wahrheit auf den Tisch: Die großen Hyperscaler bieten heute häufig deutlich mehr Werkzeuge für Identitätsschutz, Datenklassifizierung, Verschlüsselung, Protokollierung und Bedrohungserkennung als viele kleinere europäische Anbieter. Das macht Azure, AWS oder Google Cloud nicht automatisch sicher. Aber es schafft technische Möglichkeiten, die konsequent genutzt werden können.

Ein europäischer Provider ist nicht allein deshalb sicherer, weil sein Rechenzentrum in Europa steht. Und eine schlecht konfigurierte Hyperscaler-Umgebung bleibt unsicher, obwohl alle Werkzeuge vorhanden wären.

Die entscheidende Managementfrage lautet deshalb nicht nur:

Wo liegen unsere Daten?

Sondern:

Können wir nachvollziehbar erklären, wie wir unberechtigte Zugriffe verhindern, erkennen und begrenzen?

„Hosted in Europe“ ist eine Standortangabe.

Datensicherheit entsteht durch Architektur, Verantwortung und konsequente Kontrolle.

Gute Führung bedeutet nicht, jede technische Frage selbst beantworten zu müssen.Gerade bei EDI, E-Invoicing, Peppol oder...
30/07/2026

Gute Führung bedeutet nicht, jede technische Frage selbst beantworten zu müssen.

Gerade bei EDI, E-Invoicing, Peppol oder Prozessautomatisierung entsteht schnell der Eindruck, man müsse jedes Format, jedes Protokoll und jede Systemabhängigkeit im Detail verstehen, bevor man eine fundierte Entscheidung treffen kann. In der Praxis führt das oft zu langen Abstimmungen, wachsender Unsicherheit und Projekten, die komplizierter werden, als sie sein müssten.

Ein guter Dienstleister sollte genau das verhindern. Seine Aufgabe ist es, technische Komplexität einzuordnen, zu abstrahieren und in einen klaren, belastbaren Weg zu übersetzen. Das Management muss nicht wissen, wie jede einzelne Schnittstelle funktioniert. Es muss wissen, was das Unternehmen wirklich betrifft, welche Entscheidungen notwendig sind, welche Risiken bestehen und wer Verantwortung dafür übernimmt, dass der Prozess auch nach dem Projekt zuverlässig läuft.

Technologie sollte Führung nicht zusätzlich belasten. Sie sollte Entscheidungen vereinfachen, Abhängigkeiten reduzieren und operative Sicherheit schaffen. Ein guter Partner liefert deshalb nicht nur Software oder eine Schnittstelle. Er sorgt dafür, dass Anforderungen verstanden, Risiken beherrscht und Ergebnisse geliefert werden.

Die beste technische Lösung ist nicht die, über die am meisten gesprochen wird. Es ist die, die im Alltag zuverlässig funktioniert, ohne ständig Aufmerksamkeit zu benötigen.

On-Premises ist nicht das Problem. Fehlende Verbindungen sind es.Viele ERP-, CRM-, WMS- und TMS-Systeme funktionieren zu...
28/07/2026

On-Premises ist nicht das Problem. Fehlende Verbindungen sind es.

Viele ERP-, CRM-, WMS- und TMS-Systeme funktionieren zuverlässig, können aber nicht ohne Weiteres mit Geschäftspartnern, Plattformen oder EDI-Netzwerken kommunizieren.

Unser linQsupply® Agent verbindet diese Systeme innerhalb weniger Minuten mit linQsupply®. Er übernimmt Daten aus lokalen Anwendungen und Verzeichnissen, ordnet sie dem richtigen Prozess oder Geschäftspartner zu und stellt eingehende Nachrichten wieder strukturiert bereit.

Der Agent ist seit 2022 produktiv im Einsatz und wurde kontinuierlich weiterentwickelt – unter anderem mit Tray-Icon, Steuerung des Windows-Dienstes und direkter Registrierung bei linQsupply®.

Auch kundenspezifisches Customizing ist möglich, etwa für besondere Verzeichnisstrukturen, lokale Abläufe oder individuelle Systemanforderungen.

Der Agent selbst ist Bestandteil von linQsupply® – ohne zusätzliche Lizenzkosten.

Keine neue Middleware. Kein unnötiger Austausch bestehender Systeme. Sondern ein pragmatischer Einstieg in automatisierte, überwachte Geschäftsprozesse.

Wie oft werden Digitalisierungsprojekte unnötig groß geplant, obwohl zunächst eine zuverlässige Verbindung ausreichen würde?

Viele Integrationsplattformen werden nicht langsam, weil sie schlecht gebaut wurden. Sie werden langsam, weil irgendwann...
24/07/2026

Viele Integrationsplattformen werden nicht langsam, weil sie schlecht gebaut wurden. Sie werden langsam, weil irgendwann zu viel Verantwortung an einer Stelle landet.

Am Anfang funktioniert zentrale Logik oft gut. Aber mit jedem neuen Partner, jedem neuen Format und jeder Ausnahme wächst die Komplexität. Irgendwann wird jede Änderung zum Risiko.

Genau deshalb bauen wir Integrationen anders: Ein Austausch zwischen zwei Systemen oder Partnern bekommt eine klare Verantwortung. Der Prozess kennt seinen Empfänger, seine Regeln und seinen Ablauf. Validierung, Transformation, Routing und Anreicherung sind flexible Bausteine, die angepasst werden können, ohne die gesamte Plattform zu verändern.

Das sehen wir in unseren Projekten immer wieder: Änderungen an Formaten, Endpunkten oder Übertragungswegen bleiben dort, wo sie hingehören — im betroffenen Prozess. Keine großen Umbauten. Keine Kettenreaktionen. Keine Angst vor der nächsten Änderung.

Für uns ist das die eigentliche Stärke von Microservices in der Integration: nicht möglichst viele kleine technische Einheiten zu bauen, sondern Verantwortung sauber zu schneiden.

Denn Integration bedeutet Veränderung. Neue Partner, neue Systeme, neue Formate und neue Anforderungen gehören zum Alltag. Die beste Architektur ist deshalb nicht die, die am Anfang perfekt aussieht, sondern die, die auch nach Jahren noch einfach angepasst werden kann.

Microservices sind in der Integration stark, weil sie Veränderung beherrschbar machen.

22/07/2026

Viele Business-Anwendungen sprechen heute über Digitalisierung, Automatisierung und KI.

Aber sobald ein Unternehmen einen einfachen Prozess über Systemgrenzen hinweg automatisieren möchte, wird es oft erstaunlich schwer.

Ein Auftrag wurde erstellt. Eine Rechnung wurde freigegeben. Ein Kunde wurde geändert. Ein Status hat sich verändert.

Das sind keine Sonderfälle. Das ist normaler Unternehmensalltag.

Trotzdem landet man bei vielen klassischen Business-Apps noch immer bei Exporten, Importen, CSV-Dateien, manuellem Nacharbeiten, Polling oder teurem Customizing. Und genau dort werden Automatisierungsprojekte langsam, teuer und unnötig kompliziert.

Dabei zeigen Plattformen wie Shopify oder HubSpot, wie einfach es sein kann: Etwas passiert, ein anderes System wird automatisch informiert, der Prozess läuft weiter.

Genau so sollte moderne Business-Software funktionieren.

Nicht, weil Webhooks technisch spannend sind. Sondern weil fehlende Anschlussfähigkeit Geld kostet. Sie bindet Mitarbeiter, verzögert Entscheidungen, erzeugt Abhängigkeit vom Hersteller und macht aus einfachen Prozessübergängen kleine Integrationsprojekte.

Richtig absurd wird es, wenn Hersteller erst keine offenen, einfachen Integrationsmöglichkeiten anbieten — und dann zusätzlich ihre eigene Integrationsplattform für teures Geld verkaufen.

Das ist kein echter Plattformgedanke.

Das ist ein Geschäftsmodell auf Basis künstlicher Hürden.

Business-Software ohne moderne Integrationsfähigkeit ist keine echte Plattform. Sie ist ein Datensilo mit Benutzeroberfläche.

Und genau diese Silos werden in einer Welt von BPA, KI-Agenten und Echtzeitprozessen zum Problem.

Die Gewinner werden nicht die Hersteller sein, die ihre Kunden technisch am stärksten binden.

Die Gewinner werden die sein, die Prozesse einfach anschlussfähig machen: offen, ereignisbasiert, dokumentiert, bezahlbar und ohne jedes Mal ein Beratungsprojekt daraus zu machen.

Denn Unternehmen werden nicht dauerhaft für jeden einfachen Datenaustausch wochenlange Projekte bezahlen wollen.

Viele BPA-Projekte scheitern nicht an zu wenig Konzept. Sie scheitern daran, dass das Konzept irgendwann wichtiger wird ...
20/07/2026

Viele BPA-Projekte scheitern nicht an zu wenig Konzept. Sie scheitern daran, dass das Konzept irgendwann wichtiger wird als der Prozess selbst.

Am Anfang klingt alles vernünftig. Man will sauber arbeiten, Risiken vermeiden, alle Beteiligten einbinden und keinen Sonderfall vergessen. Doch genau dort kippt es oft. Aus einem sinnvollen Konzept wird ein Workshop-Marathon. Noch eine Ausnahme, noch ein Stakeholder, noch ein „Was ist, wenn …?“. Und irgendwann hat das Unternehmen ein beeindruckendes Konzept, ein gebundenes Budget, viele investierte Stunden — aber immer noch keinen Prozess, der im Alltag wirklich Arbeit abnimmt.

Für mich ist das kein Zeichen von Professionalität. Es ist oft nur gut moderierte Verzögerung. Business Process Automation ist nicht in erster Linie ein IT-Projekt. BPA ist eine Führungsentscheidung. Irgendwann muss jemand sagen: Das ist unser Startpunkt. Damit gehen wir los.

Denn jeder Prozess hat einen Trigger und jeder Prozess hat ein Ende. Genau dort sollte man anfangen. Was löst den Prozess aus? Welche Daten sind wirklich notwendig? Welche Entscheidung muss getroffen werden? Wann ist der Prozess abgeschlossen? Und vor allem: Wer trägt die Verantwortung? Wenn diese Fragen nicht beantwortet sind, helfen auch zehn weitere Workshops nicht. Wenn sie aber beantwortet sind, kann man meistens schneller starten, als viele glauben.

Nicht blind, nicht chaotisch und nicht verantwortungslos. Sondern pragmatisch. Mit dem kleinsten stabilen Prozesskern, der produktiv laufen kann. Spezialregeln, Ausnahmebehandlung und Optimierung kommen danach. Denn die Wahrheit über einen Prozess zeigt sich nicht im Meetingraum. Sie zeigt sich im Betrieb. Erst dort sieht man, welche Ausnahme wirklich relevant ist, welche Regel nur theoretisch war, wo Daten fehlen und ob die Plattform flexibel genug ist, um im laufenden Betrieb angepasst zu werden.

Deshalb ist Anpassbarkeit für BPA oft wichtiger als perfekte Vorab-Modellierung. Und deshalb verderben viele Köche auch bei Automation den Brei. Natürlich braucht es Input aus Fachbereich, IT, Compliance und Management. Aber am Ende muss einer den Hut aufhaben. Einer muss entscheiden, priorisieren und Verantwortung übernehmen.

Vielleicht ist das die eigentliche Management-Lektion aus vielen Technologiegeschichten: Nicht immer gewinnt das perfekteste Konzept. Oft gewinnt das System, das schneller startet, schneller lernt und sich besser anpassen kann.

Genau das gilt auch für BPA. Wer alles vorher perfekt lösen will, wird oft von denen überholt, die kontrolliert anfangen und schneller lernen.

Meine These nach über 30 Jahren IT: Die besten BPA-Projekte beginnen nicht mit der Frage: „Haben wir wirklich alle Sonderfälle berücksichtigt?“ Sondern mit: „Was ist der kleinste stabile Prozess, den wir jetzt produktiv machen können?“

Alles andere ist oft nur gut verpacktes Aufschieben.

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