Wie sind die Ö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

Wie lautet die Website?

https://insyca.com/, https://insyca.com/de/datenschutz/, https://insyca.com/de/impressum/

InSyca IT Solutions GmbH, Finsinger Feld 5, Ottobrunn (2026)

13/10/2026

Viele Unternehmen bauen sich mit der E Rechnung gerade ihre nächste Integrationsbaustelle.

Nicht weil EN 16931, XRechnung, UBL oder CII schlechte Standards wären. Sondern weil sie zu tief in ERP, CRM und Fachsysteme eingebaut werden. Für Accounting wirkt das zunächst sauber. Dann kommt der nächste Geschäftspartner und braucht EDIFACT, ein eigenes XML oder JSON über eine API. Und plötzlich wird wieder transformiert, nur diesmal aus dem teuer eingeführten Standard wieder heraus.

Das ist für mich der eigentliche Fehler. Nicht der Standard, sondern der Ort, an dem man ihn verankert. Änderungen in einem ERP oder CRM sind selten klein. Da hängen Hersteller, Releases, Tests, Fachlogik und mehrere Teams dran. Eine Anpassung in einer zentralen Transformationsschicht ist dagegen oft überschaubar. Eine XSLT Änderung kostet häufig nur einen Bruchteil dessen, was dieselbe Anpassung innerhalb einer Business Anwendung kostet.

Und die E Rechnung ist ohnehin nur ein Teil der Realität. Daneben gibt es Bestellungen, Aufträge, Stammdaten, Logistik, Statusmeldungen, Portale und APIs. Jeder dieser Prozesse bringt wieder andere Formate und andere Partner mit. Selbst bei Rechnungen ist die Welt nicht einheitlich. In Deutschland können Geschäftspartner unter bestimmten Voraussetzungen weiterhin andere strukturierte Formate vereinbaren. EDI verschwindet also nicht, nur weil die E Rechnung kommt.

Mich stört nicht der Standard. Mich stört, wenn man ihn an die teuerste und unflexibelste Stelle setzt. Die E Rechnung ist wichtig. Aber sie ist nicht das Unternehmen.

Wer heute nur für Accounting optimiert, kann sich morgen bei jeder weiteren Automatisierung neue Kosten einbauen. Für mich ist deshalb die wichtigere Frage nicht, welchen Standard ein Unternehmen unterstützt, sondern an welcher Stelle dieser Standard aufhört.

08/10/2026

Standards lösen erstaunlich viel. Die Last Mile einer Integration lösen sie trotzdem nicht automatisch.

Bei EDI und E Invoicing merkt man das ziemlich schnell. Standards wie EN 16931 oder Peppol schaffen eine gemeinsame Basis für Datenstrukturen, Validierung und Austausch. Das nimmt viel Komplexität raus.

Trotzdem kann ein Dokument vollständig standardkonform sein und fachlich noch nicht dort sein, wo es gebraucht wird.

Ein aktuelles Beispiel aus der Pharmabranche ist die PZN, die Pharmazentralnummer. Die zugrunde liegenden Standards bieten Möglichkeiten, solche zusätzlichen Artikelinformationen strukturiert zu übertragen.

Damit ist aber nur geklärt, dass die Information technisch mitgegeben werden kann.

Auf der Last Mile beginnt die eigentliche Arbeit. Erkennt das empfangende ERP oder Warenwirtschaftssystem diesen Wert tatsächlich als PZN? Erwartet es ihn genau an dieser Stelle? Braucht es eine bestimmte Bezeichnung oder Codierung? Und wird die Information anschließend auch im richtigen Prozess weiterverarbeitet?

Eine Rechnung kann also valide sein, technisch korrekt übertragen werden und trotzdem fachlich unvollständig im Zielsystem ankommen.

Für mich ist genau das der Punkt, an dem Standards auf die Realität des Unternehmens treffen. Mapping, Transformation, Validierung, Routing und kundenspezifische Regeln sorgen dafür, dass aus einem standardisierten Dokument ein funktionierender Geschäftsprozess wird.

Standards reduzieren den individuellen Aufwand erheblich. Sie nehmen uns aber nicht jede branchenspezifische Besonderheit und jede Eigenheit der internen Systemlandschaft ab.

Deshalb ist „Wir unterstützen Peppol“ oder „Wir unterstützen EDI“ für mich noch keine vollständige Aussage.

Entscheidend ist, ob die Information am Ende dort ankommt, wo sie fachlich gebraucht wird.

Die Last Mile bleibt Integration.

06/10/2026

Peppol sollte nicht wissen müssen, wie viele interne Systeme ein Unternehmen betreibt.

Besonders deutlich wird das bei eingehenden Rechnungen.

Viele Unternehmen betreiben mehrere Systeme parallel. Ein ERP verarbeitet einen Teil der Geschäftsvorgänge, ein TMS einen anderen, dazu kommt vielleicht noch ein WMS oder ein weiteres Business System. Technisch könnte man auf die Idee kommen, diese Systeme jeweils separat an Peppol anzubinden.

Genau dann beginnt aber das eigentliche Adressierungsproblem.

Ein Lieferant adressiert keine interne Anwendung. Er adressiert eine Business Entity. Er sollte nicht wissen müssen, ob seine Rechnung intern im ERP, im TMS, im WMS oder in einem anderen System verarbeitet wird.

Mehrere Peppol Participant Identifier für dieselbe Organisation sind technisch durchaus möglich, zum Beispiel über unterschiedliche zulässige Identifier Schemes. Historisch gibt es deshalb auch Unternehmen, die mehrfach registriert wurden. Das ist nicht automatisch falsch.

Problematisch wird es dann, wenn der Lieferant entscheiden muss, welche Peppol ID für seinen konkreten Vorgang die richtige ist.

Dann wurde interne Komplexität nach außen verlagert.

Für mich sollte die Adressierung deshalb möglichst stabil an der Business Entity hängen. Eine zentrale Integrationsschicht nimmt eingehende Dokumente entgegen und entscheidet intern, wohin sie gehören. Sie übernimmt Dispatching, Routing, Validierung, gegebenenfalls Transformation, Monitoring und technische Fehlerbehandlung.

Peppol kennt die externe Identität. Die Integrationsschicht kennt die interne Systemlandschaft.

Genau dieses Dispatching kann zum Beispiel linQsupply® übernehmen. Eine eingehende Rechnung wird über eine zentrale Peppol Anbindung empfangen und anschließend anhand der fachlichen Regeln an das richtige interne Zielsystem weitergeleitet.

Das macht die Architektur auch langfristig robuster. Wenn ein ERP ersetzt wird, ein weiteres System dazukommt oder sich interne Verantwortlichkeiten ändern, muss der Lieferant davon nichts mitbekommen. Seine Peppol Adresse bleibt gleich.

Outbound existiert natürlich ebenfalls die Herausforderung, mehrere Quellsysteme sauber an Peppol anzubinden. Dort ist es für mich aber eher ein Last Mile Thema.

Inbound liegt die eigentliche Architekturfrage eine Ebene höher:
Die Peppol Adresse sollte die Business Entity repräsentieren, nicht das interne Zielsystem.

01/10/2026

Ein KI Chatbot, der mich nicht zu einem Menschen durchlässt, ist keine Automatisierung. Er ist eine Warteschleife mit Textfeld.

Wir setzen selbst KI im Support ein und ich halte das Potenzial für enorm. Bei uns soll sie den menschlichen Support schneller machen, nicht verstecken. Strukturierte Logs, Correlation IDs, Vorgangskennungen, HTTP Status und Retry Informationen liefern technischen Kontext. Dazu kommt ein kuratierter Knowledge Pool, den wir laufend um bekannte Fehlerbilder und Lösungen erweitern. Die KI kann daraus Informationen vorsortieren, Zusammenhänge sichtbar machen und dem Support eine deutlich bessere Ausgangslage geben.

Gerade deshalb sehe ich viele heutige KI Supportsysteme kritisch. Solange ein Problem nach zwei oder drei Rückfragen in ein bekanntes Muster passt, funktionieren sie oft erstaunlich gut. Sobald der Fall komplexer wird, beginnt bei manchen Systemen das Kreisen. Fragen werden wiederholt, Standardlösungen vorgeschlagen oder der Nutzer landet wieder am Anfang. Besonders problematisch wird es, wenn es keinen vernünftigen Weg zu einem Menschen gibt. Dann wurde Support nicht automatisiert. Der Aufwand wurde nur vom Unternehmen zum Kunden verschoben.

Technisch wird es außerdem dort interessant, wo viele Demos aufhören. Bevor Supportdaten für eine KI Analyse verwendet werden, muss klar sein, welche Informationen überhaupt benötigt werden. Gerade bei technischen Fällen können Logs, Nachrichteninhalte oder Fehlermeldungen auch kundenbezogene oder vertrauliche Daten enthalten. Deshalb ist Sanitizing für uns kein Nebenthema. Personenbezogene Daten, Zugangsdaten und andere sensible Informationen müssen vor der weiteren Verarbeitung möglichst entfernt oder maskiert werden. Gleichzeitig sollte die KI nur den Kontext bekommen, den sie für die Analyse tatsächlich braucht.

Bei komplexeren technischen Fällen habe ich bisher noch kein Dialogsystem gesehen, dem ich die vollständige Bearbeitung bedenkenlos überlassen würde. Eine sprachlich überzeugende Antwort ist noch kein Beweis dafür, dass die technische Analyse stimmt. Für mich liegt die Stärke von KI deshalb heute vor allem darin, Menschen besser vorzubereiten, relevante Informationen zusammenzubringen, bekannte Lösungen zu finden und Routinearbeit abzunehmen.

Wenn ein Fall nach wenigen sinnvollen Rückfragen nicht klarer wird, sollte die Übergabe an einen Menschen selbstverständlich sein. Und zwar mit dem gesamten bereits erarbeiteten Kontext.

KI im Support muss nicht menschlich wirken.
Sie muss wissen, wann ein Mensch übernehmen sollte.

29/09/2026

Ich hatte die Anforderung nicht falsch umgesetzt. Ich hatte sie falsch verstanden.

Vor vielen Jahren habe ich an einer Software für Crashtests gearbeitet. Auf einer Oberfläche sollten mehrere Zustände sehr deutlich in Rot oder Grün angezeigt werden. Die vorgesehenen großen Anzeigen fand ich ziemlich grob, also habe ich sie durch kleine Status LEDs ersetzt. Das sah sauberer aus, brauchte weniger Platz und ich war mit der Lösung ehrlich gesagt ziemlich zufrieden.

Bis ein Techniker ein gutes Stück entfernt stand und fragte, welche Farbe die Anzeige eigentlich habe.

In diesem Moment war klar, was ich übersehen hatte. Ich hatte die Anforderung aus meiner eigenen Perspektive interpretiert. Für mich bedeutete „gut sichtbar“: klar, kompakt und sauber auf dem Bildschirm. Für den Techniker bedeutete es: aus größerer Entfernung sofort erkennen können, ob der nächste Schritt bereit ist. Die Software war technisch korrekt. Nur der Kontext, für den ich sie gebaut hatte, war in meinem Kopf ein anderer als in der Realität.

Solche Situationen sind mir im Gedächtnis geblieben, weil sie erstaunlich viel über Softwareentwicklung erzählen. Anforderungen stehen nie für sich allein. Sie gehören zu Menschen, Abläufen und Situationen. Wenn man nur die Spezifikation betrachtet, aber nicht versteht, wer später damit arbeitet und unter welchen Bedingungen, kann man etwas technisch sehr sauber bauen und trotzdem am Bedarf vorbeigehen.

Deshalb versuche ich heute viel früher mit den Menschen zu sprechen, die eine Lösung später nutzen müssen, dürfen oder können. Nicht erst, wenn die Oberfläche fertig ist oder ein Prozess getestet wird. Oft versteht man erst in diesen Gesprächen, warum eine Anforderung überhaupt existiert und was wirklich wichtig ist.

Technische Qualität beginnt für mich deshalb nicht mit der Umsetzung.

Sie beginnt damit, den Kontext richtig zu verstehen.

24/09/2026

Deutschland hat aus meiner Sicht weniger ein Digitalisierungsproblem als ein Integrationsproblem.

Seit Jahren messen wir Verwaltungsdigitalisierung daran, wie viele Leistungen online angeboten werden. Das ist sichtbar und deshalb politisch attraktiv. Interessanter finde ich aber, was nach dem Klick auf „Absenden“ passiert. Wenn Daten anschließend erneut erfasst, Nachweise manuell geprüft oder Informationen zwischen Bund, Ländern und Kommunen weitergereicht werden müssen, haben wir ein Formular digitalisiert, aber noch keinen Prozess automatisiert.

Wie groß der Hebel sein kann, hat der Nationale Normenkontrollrat bereits für die 60 wichtigsten Verwaltungsleistungen untersucht. Auf Verwaltungsseite wurde damals ein Einsparpotenzial von rund 701 Millionen Euro pro Jahr beziehungsweise 32,7 Prozent des betrachteten Aufwands errechnet. Zusammen mit den Entlastungen für Bürger und Unternehmen lag das Potenzial bei rund 2,9 Milliarden Euro. Heute wird mit der Registermodernisierung und NOOTS genau an diesem Problem gearbeitet: Daten sollen nach dem Once Only Prinzip nur einmal bereitgestellt und anschließend zwischen Behörden automatisiert ausgetauscht werden. 2026 wurden dafür 16 konkrete Pilotvorhaben aus Bund und Ländern ausgewählt. Das zeigt für mich ziemlich deutlich, wo ein großer Teil der eigentlichen Effizienzreserve liegt. Nicht im nächsten Portal, sondern in den Verbindungen zwischen den Systemen.

Bevor wir jetzt allerdings nur auf die Verwaltung zeigen: In der Privatwirtschaft sieht es vielerorts kaum besser aus. Gerade im Mittelstand sind Prozesse häufig digital, aber nicht durchgängig integriert. Laut KfW haben zuletzt nur 30 Prozent der mittelständischen Unternehmen Digitalisierungsprojekte durchgeführt, und die digitale Kluft zwischen großen und kleinen Mittelständlern bleibt deutlich. Besonders interessant finde ich, dass komplexere Vorhaben zur Reorganisation von Workflows weiterhin vor allem von digitalen Vorreitern umgesetzt werden. Ein Kundenportal, ein neues ERP oder ein Cloud Dienst sind eben noch keine Prozessautomatisierung, wenn Mitarbeiter anschließend Daten zwischen Systemen übertragen oder Prozesszustände manuell nachvollziehen müssen.

Vielleicht ist das die unbequeme Gemeinsamkeit von Verwaltung und Wirtschaft: Wir investieren gerne in Anwendungen, aber zu wenig in das, was zwischen ihnen passiert. Genau dort entstehen Medienbrüche, Mehrfacharbeit und Abhängigkeit von Menschen, die wissen, wie man den Prozess irgendwie am Laufen hält. Digitalisierung spart erst dann wirklich Geld, wenn Systeme nicht nur digital sind, sondern miteinander arbeiten.

Quellen: Nationaler Normenkontrollrat, „E Government in Deutschland: Vom Abstieg zum Aufstieg“, TOP 60 Verwaltungsleistungen; Nationaler Normenkontrollrat, Jahresbericht 2024 zur Registermodernisierung und zum Once Only Prinzip; FITKO, NOOTS Pilotprojekte 2026; KfW Research, Digitalisierungsbericht Mittelstand 2025 und Analyse „Digitalisierung im Mittelstand: Zuwächse bei digitalen Services“.

22/09/2026

Einmal Peppol implementieren und damit die elektronische Rechnungsstellung für Europa erledigen?

Diese Vorstellung höre ich erstaunlich häufig. Und technisch ist sie sogar nachvollziehbar. Peppol schafft eine gemeinsame Infrastruktur, standardisierte Dokumente und einen verlässlichen Weg, Geschäftspartner zu erreichen. Genau deshalb ist es für den europäischen Rechnungsaustausch so wichtig geworden. Nur bedeutet ein gemeinsames Netzwerk noch lange nicht, dass Europa auch einen gemeinsamen Prozess eingeführt hat.

Gerade jetzt sieht man, wie unterschiedlich die einzelnen Länder ihre E Invoicing Vorgaben umsetzen. Frankreich nutzt Peppol, verbindet damit aber eigene regulierte B2B Prozesse, nationale Formate und E Reporting. Die Slowakei setzt ebenfalls auf Peppol BIS Billing und ergänzt nationale Reporting Anforderungen. Deutschland hat mit XRechnung eigene Vorgaben und Übergangsregeln. Polen wiederum verbindet Peppol mit einer nationalen Infrastruktur und eigenen Dokumenttypen. Technisch bewegen wir uns also zunehmend auf einer gemeinsamen Basis, fachlich bleiben wir mitten in nationalen Regelwerken.

Deshalb halte ich „Wir unterstützen Peppol“ inzwischen für eine ziemlich unvollständige Aussage. Für Unternehmen, die in mehreren europäischen Ländern Rechnungen austauschen, liegt die eigentliche Komplexität nicht nur im Transport. Entscheidend ist, welche Rechnung in welchem Land zulässig ist, welche zusätzlichen Daten verlangt werden, welche Statusmeldungen verarbeitet werden müssen und ob neben der Rechnung auch steuerliche Reporting Pflichten entstehen. Peppol kann dabei ein sehr guter gemeinsamer Nenner sein. Es nimmt uns aber nicht die nationalen Besonderheiten ab.

Vielleicht ist genau das die paradoxe Entwicklung beim europäischen E Invoicing: Die technische Infrastruktur wird einheitlicher, während die Umsetzung zunächst komplexer wird. ViDA bringt langfristig weitere Harmonisierung, insbesondere bei grenzüberschreitendem Reporting ab 2030. Bis dahin ist eine Peppol Anbindung für mich keine europäische E Invoicing Strategie. Sie ist die Basis, auf der diese Strategie überhaupt erst gebaut werden kann.

18/09/2026

Die teuerste Integration ist manchmal die, die längst erfolgreich abgeschlossen wurde.

Das Projekt ist fertig, die Schnittstellen laufen und der Go Live war erfolgreich. Ein paar Monate später ändert der Hersteller seine API, ein Zertifikat läuft ab, ein Geschäftspartner liefert plötzlich andere Daten oder ein Prozess verhält sich anders als erwartet. Spätestens dann taucht eine erstaunlich einfache Frage auf: Wer ist eigentlich dafür verantwortlich? Das Projektteam gibt es vielleicht nicht mehr, der Hersteller sieht seine Anwendung als funktionierend an und der interne Betrieb stellt fest, dass das Problem irgendwo zwischen mehreren Systemen liegt.

Ich glaube deshalb, dass wir bei Integrationsprojekten zu viel über den Go Live und zu wenig über die Jahre danach sprechen. Eine Integration ist kein fertiges Stück Software, das man einmal installiert und anschließend vergisst. Sie verbindet Systeme, Unternehmen und Geschäftsprozesse, die sich unabhängig voneinander verändern. Wer nur die technische Umsetzung verantwortet, überlässt dem Kunden anschließend genau die Stelle, an der es im Betrieb kompliziert wird.

Für mich gehört deshalb die Frage nach dem späteren Eigentümer bereits in die Architektur. Jemand muss nicht nur reagieren, wenn etwas ausfällt, sondern verstehen, was der Prozess eigentlich tun soll, Veränderungen bewerten und die Integration weiterentwickeln können. Sonst besitzt am Ende jeder sein eigenes System und niemand den Prozess dazwischen.

Vielleicht ist genau das der Grund, warum ich mit dem Begriff „Projektabschluss“ bei Integration inzwischen etwas vorsichtiger geworden bin. Ein erfolgreicher Go Live beendet die Implementierung. Die Verantwortung für einen funktionierenden Geschäftsprozess beginnt dort erst richtig.

16/09/2026

Der gefährlichste Satz in der Prozessautomatisierung ist für mich: „Das andere System wird schon antworten.“

Solange Prozesse innerhalb einer Anwendung bleiben, kann man sich das vielleicht noch leisten. In der Realität eines Unternehmens läuft ein Geschäftsvorgang aber schnell durch ERP, CRM, E Commerce, Logistik, EDI Plattformen und externe Partner. Einige Systeme antworten sofort, andere irgendwann und manche im entscheidenden Moment überhaupt nicht. Trotzdem muss der Prozess weiter wissen, wo er steht. Eine Bestellung verschwindet schließlich nicht, nur weil ein beteiligtes System gerade nicht erreichbar ist.

Deshalb halte ich zustandslose Automatisierung für viele geschäftskritische Prozesse für die falsche Vereinfachung. Ein belastbarer Prozess muss wissen, was bereits passiert ist, worauf er wartet und was beim nächsten Versuch passieren darf. Sonst wird aus Automatisierung sehr schnell das Gegenteil: Jemand schaut in Logs, vergleicht Datensätze und versucht herauszufinden, an welcher Stelle der Vorgang eigentlich verloren gegangen ist. Das ist dann technisch automatisiert und organisatorisch wieder Handarbeit.

Genau hier unterscheidet sich für mich Business Process Automation von der Automatisierung einzelner Aufgaben. Ein Trigger, ein paar Aktionen und ein grünes Häkchen können beeindruckend schnell gebaut sein. Bei einem Geschäftsprozess interessiert mich aber nicht, wie schnell der Happy Path funktioniert. Mich interessiert, ob wir am nächsten Morgen noch wissen, wo jeder einzelne Vorgang steht, wenn in der Nacht drei beteiligte Systeme unterschiedliche Vorstellungen davon hatten.

14/09/2026

Compliance wird erstaunlich teuer, wenn man sie erst kurz vor dem Go Live entdeckt.

Das klingt banal, begegnet mir in IT Projekten aber immer wieder. Eine Lösung ist technisch weitgehend fertig, die Architektur steht und dann kommen die eigentlich simplen Fragen: Welche Daten verarbeiten wir hier genau? Wer darf darauf zugreifen? Wo liegen Secrets? Was wird protokolliert? Wie bekommen wir eine Änderung kontrolliert in Produktion? Keine dieser Fragen ist besonders spektakulär. Wenn die Antworten aber nicht zur gebauten Lösung passen, können sie plötzlich erstaunlich viel Arbeit verursachen.

Bei uns hat ISO 27001 deshalb einen Effekt gehabt, den ich anfangs gar nicht für den wichtigsten gehalten hätte. Natürlich gibt es Policies, Risikobewertungen und Nachweise. Interessanter finde ich, was davon inzwischen ganz selbstverständlich in technischen Entscheidungen steckt. Berechtigungen werden möglichst nicht vergeben, wenn eine Managed Identity reicht. Änderungen laufen durch Pipelines, Tests und Quality Gates. Security Checks gehören in den Entwicklungsprozess und nicht auf eine Liste, die jemand kurz vor dem Release abhakt. Nicht weil ein Auditor das gerne sieht, sondern weil spätere Korrekturen meistens die schlechtere und teurere Architektur produzieren.

Deshalb sehe ich Compliance inzwischen weniger als Kontrollfunktion und mehr als eine technische Randbedingung guter Architektur. Gute Randbedingungen machen Entwicklung nicht langsamer. Sie verhindern nur Lösungen, die man später mit viel Aufwand wieder einfangen muss. Ein ISO Zertifikat an der Wand interessiert mich dabei deutlich weniger als eine Architektur, bei der Security und Compliance im normalen Betrieb kaum noch auffallen.

InSyca IT Solutions GmbH

13/10/2026

08/10/2026

06/10/2026

01/10/2026

29/09/2026

24/09/2026

22/09/2026

18/09/2026

16/09/2026

14/09/2026

Adresse

Öffnungszeiten

Telefon

Website

Benachrichtigungen

Service Kontaktieren

Verknüpfungen

Teilen

Kategorie

Antrag auf Entfernung des Eintrags

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