Enterprises bauen ihre eigenen Werkzeuge, und müssen dann jedes Hauptbuch erreichen
Ein Konzern betreibt so viele Buchhaltungssysteme, wie er Gesellschaften hat, und die Software, die Ihre eigene IT baut, muss sie alle lesen und beschreiben. Eine Anbindung je Gesellschaft, dieselben Objekte zurück.
- KonzernholdingMicrosoft Dynamics 365 BC
- Deutsche BetriebsgesellschaftDATEV Rechnungswesen
- Niederländische TochterExact Online
- Nordische TochterFortnox
Die Software steht längst, die Verbindung zu jeder Gesellschaft nicht
Konzerne mit eigener IT kommen selten und fragen nach einer Anwendung. Sie kommen mit einer, die sie gebaut oder gekauft und erweitert haben, und mit derselben Blockade darunter.
Eigene Werkzeuge für Kreditoren, Debitoren und Abgleich, oder ein gekauftes Produkt, intern erweitert.
Beschrieben, in jeder Gesellschaft
Ein BI-Stack, dem die Finanzabteilung längst vertraut, gespeist aus jeder Gesellschaft, die selbst abschließt.
Gelesen, in jeder Gesellschaft
Eine zentrale Stelle, aus der Kunden, Lieferanten und Produkte kommen sollen, und die alles andere speist.
Beides, und abgeglichen gehalten
Alle drei enden an derselben Wand, und es ist kein Modellierungsproblem. Jede Gesellschaft führt ihre Bücher in ihrem eigenen System, lokal gewählt, oft bevor der Konzern sie überhaupt besaß. Eine Holding auf Microsoft Dynamics 365 Business Central und eine Tochter auf Exact Online sind davor zwei Anbindungen und danach eine. Ein System zu erreichen ist ein Projekt. Elf zu erreichen ist ein Programm, und das elfte kommt in der Woche nach dem Abschluss einer Übernahme.
Schlimmer als ein normaler Integrationsrückstand ist es deshalb, weil die Arbeit nicht endet, wenn die Anbindung steht. Buchhaltungshersteller ändern ihre Schnittstellen nach eigenem Zeitplan, und ein Feld, das in einem Frühjahrs-Release verschwindet, ist ein Bericht, der an einem Dienstag nicht mehr rendert. Diese Pflege landet bei demselben internen Team, das eigentlich die Werkzeuge bauen sollte.
Ein Objektmodell, und fünf Probleme, die Sie nicht mehr je Gesellschaft lösen
Für ein internes Team ist der interessante Teil nicht, was die API zurückgibt, sondern was sie von der Roadmap nimmt. Jedes davon ist eine Arbeit, die sich sonst einmal je Gesellschaft und einmal je Hersteller wiederholt.
- Common Data Model
Eine Zuordnung je Gesellschaft schreiben, und eine zweite, wenn eine Tochter migriert.
- Unified Authentication
Ein Verbindungsablauf je Hersteller, auch für die Systeme, die mehrere Firmen hinter einer Anmeldung führen.
- Unified Pagination & Filtering
Ein nächtlicher Lauf, der alles zieht, weil sich das Delta nicht abfragen lässt.
- Unified Webhooks
Jede Gesellschaft nach Zeitplan abfragen, damit Ihr eigener Bestand mitläuft.
- Unified Logging & Monitoring
Vier Hersteller einzeln fragen, was mit einer Anfrage passiert ist, die nicht ankam.
Zusammen sind sie der Grund, warum eine zwölfte Gesellschaft eine Anbindung ist und kein Quartal Arbeit. Der MCP-Server liegt auf derselben Schicht für den Fall, dass die Frage von einem Agenten kommt und nicht von einer Anwendung, samt einer lokalen Variante für den Fall, dass eine gehostete Komponente nicht in Frage kommt.
Sechs Abläufe auf einer Anbindung, die dieselben Objekte lesen
Eigene Werkzeuge tun selten nur eines. Die Objektspalte unten wiederholt sich, und genau diese Wiederholung ist der Grund, warum sechs Abläufe auf einer Anbindung sitzen statt auf sechs.
- KreditorenbuchhaltungliestLieferanten, Kontenrahmen, Steuersätze, Dimensionenschreibt zurückEingangsrechnungen, Zahlungen
- DebitorenbuchhaltungliestKunden, Kontenrahmen, Steuersätze, Dimensionenschreibt zurückRechnungen, Zahlungen, Buchungsvorschläge
- ZahlungsabgleichliestKontenrahmen, Journale, Steuersätze, Dimensionenschreibt zurückBuchungssätze
- Finanzanalyse & FinanzplanungliestBuchungssätze, Rechnungen, Eingangsrechnungen, Konten, Steuersätze, Summen- und Saldenliste, offene Postenschreibt zurückschreibt nichts zurück
- KonzernkonsolidierungliestKonten, Buchungssätze, Rechnungen, Steuersätze, Journale, Dimensionen, Summen- und Saldenliste, Geschäftsjahreschreibt zurückschreibt nichts zurück
- Kunden- / LieferantensynchronisationliestKunden, Kontakteschreibt zurückKunden, Lieferanten
Die Konsolidierung kommt am häufigsten zuerst, und sie liegt selten bei dem Team, das die Anbindung baut. Sie liegt bei der Finanzabteilung, die entscheidet, worauf eine Konzernzahl abzustimmen ist und welche Gesellschaften zu einem Abschluss gehören. Diese Grenze mit ihr zu klären, bevor die erste Gesellschaft angebunden ist, ist billiger, als sie nach der dritten zu klären.
Stammdaten sind der Fall, der in beide Richtungen läuft
Die Abläufe oben laufen meist in eine Richtung. Kunden-, Lieferanten- und Produktdatensätze tun das nicht, und genau das macht sie zur schwereren Hälfte eines internen Datenvorhabens.
- 01IhresDas System jeder Gesellschaft
Kunden, Lieferanten und Produkte, jeweils lokal gepflegt
- 02MaesnEine Anbindung je Gesellschaft
Lesen und Schreiben, dieselben Objekte und dieselben Feldnamen
- 03IhrIhr zentraler Bestand
Der Data Lake oder Stammdaten-Hub, den Sie schon betreiben
- 04IhrAlles dahinter
BI, das Dokumentensystem und die Anwendungen, die danach fragen
Wo der führende Datensatz liegt und was er bedeutet, sind Entscheidungen, die wir nicht treffen.
Derselbe Kunde existiert in vier Systemen in vier Schreibweisen, und jede davon ist lokal für jemanden die führende. Das zu zentralisieren ist eine Entscheidung über Governance und nicht über Leitungen, und sie gehört Ihnen. Was die Anbindung liefert, ist der Teil, der in beide Richtungen funktionieren muss: Kunden- und Lieferantendatensätze, im System jeder Gesellschaft mit denselben Feldern gelesen und geschrieben, damit der Bestand in der Mitte gespeist werden kann und selbst zurückspeisen.
Welche Systeme das tatsächlich können, und für welche Objekte, ist nicht einheitlich. Es ist je System im Integrationsverzeichnis veröffentlicht statt gemittelt, und für einen Konzern zählt nicht, wie viele Systeme ein Objekt unterstützen, sondern ob jede Gesellschaft im Abschluss es tut.
Wir liefern die Objekte, Ihre IT behält die Architektur
Diese Zielgruppe baut beruflich Software, nützlich ist deshalb eine klare Linie und kein breites Versprechen.
- Eine Form für das System jeder Gesellschaft
- Freigabe je Gesellschaft
- Das eigene Vokabular jedes Herstellers
- Deren jährliche Brüche
- Wo der führende Datensatz liegt
- Worauf eine Konzernzahl abgestimmt wird
- Ihr Datenmodell und Ihr Bestand
- Alles, was Ihr Prüfer sieht
Nichts hier ist eine Anwendung. Es gibt keine Konsolidierungsmaschine, keine Berichtsschicht und keine Meinung zu Ihrem Warehouse, denn ein Konzern, der seine eigenen Werkzeuge gebaut hat, will keine zweiten darunter. Eine Währungsumrechnung, eine Zwischengewinneliminierung und ein Konzernkontenrahmen sind alles Entscheidungen, an denen Ihr Prüfer hängt, und sie bleiben dort, wo diese Verantwortung liegt.
Die Hälfte, die wir tragen, ist die, die nie fertig wird. Herstellerschnittstellen verschieben sich, Gesellschaften werden gekauft und verkauft, und eine Anbindung, die im März lief, ist im April ein Support-Ticket. Die Form konstant zu halten, während die Systeme darunter sich ändern, ist die Arbeit, die abgegeben wird, und sie lohnt sich gegen die interne Roadmap gerechnet, die sie freiräumt, und nicht gegen eine erste Anbindung.
Häufige Fragen
Welche Konzerne laufen bereits darauf?
Wir haben bereits eine Integrationsplattform. Wo ordnet sich das ein?
Unsere Gesellschaften nutzen nicht alle dasselbe Buchhaltungssystem. Ist das ein Problem?
Können wir auch zurückschreiben, oder ist das nur lesend?
Wie halten wir unseren zentralen Bestand aktuell, ohne abzufragen?
Wer im Konzern verantwortet das üblicherweise?
Deckt das neben der Buchhaltung auch unser ERP ab?
Wo liegen unsere Daten?
Einmal bauen, auf der Unified API.
Sehen Sie, wie Buchhaltungsdaten aus mehreren Gesellschaften für Ihre Integration funktioniert, oder steigen Sie in die technische Referenz ein.











