Sechs Branchen, und ein System, das ihnen nicht gehört.
Eine Kreditorenplattform, eine Bau-App, ein Kreditgeber und eine Konzernfinanzabteilung haben fast nichts gemeinsam, bis jeder von ihnen etwas aus dem Buchhaltungssystem seines Kunden braucht oder hinein. Je Branche unterscheidet sich, welche Objekte das sind.
Beginnen Sie mit der, die beschreibt, was Sie bauen
Jede Seite ist für eine Zielgruppe geschrieben und trägt die Objekte, die Systeme und die Kunden, die zu ihr gehören.
- B2B-FintechPlattformen, deren Produkt am Buchhaltungssystem des Kunden hängt.
- SaaSSoftware, die den Auftrag steuert und ihn danach abrechnen muss.
- Banken & KreditgeberKredite prüfen und überwachen mit Zahlen aus den Büchern.
- ReiseplattformenReisebuchungen, die als korrekte Buchung ankommen müssen.
- SteuerberaterKanzleien, die Mandantenbücher aus jedem System auswerten.
- EnterprisesGesellschaften eines Konzerns, deren IT auf dem Hauptbuch aufsetzt.
Eine Anbindung, in jeder ein anderer Satz Objekte
Jede Branche unten trifft über dieselbe Freigabe und dasselbe Datenmodell auf dieselben Systeme. Was ihr Ablauf von diesem Modell verlangt, ist die Stelle, an der sie sich trennen.
- BrancheB2B-FintechErzeugtEinen Finanzprozess, der zu Ende laufen mussBraucht aus dem HauptbuchKunden, Lieferanten, Konten und Steuersätze hinein, Rechnungen, Eingangsrechnungen, Zahlungen und Buchungssätze zurück
- BrancheSaaSErzeugtEine Rechnung aus der geleisteten ArbeitBraucht aus dem HauptbuchKunden, den Kontenrahmen, Artikel und Steuersätze hinein, eine Rechnung zurück
- BrancheReiseplattformenErzeugtEine Reise, die gebucht werden mussBraucht aus dem HauptbuchKonten, Steuersätze, Lieferanten und Dimensionen hinein, Ausgaben oder Buchungen zurück
- BrancheBanken & KreditgeberErzeugtEine Kreditentscheidung, die zu treffen istBraucht aus dem HauptbuchKonten, Geschäftsjahre, Buchungssätze, Zahlungsbedingungen, Steuersätze und die Summen- und Saldenliste, nur lesend
- BrancheSteuerberaterErzeugtAuswertungen über einen ganzen MandantenstammBraucht aus dem HauptbuchKonten, Steuersätze, Journale, Dimensionen und die Summen- und Saldenliste je Mandat, Buchungssätze zurück
- BrancheEnterprisesErzeugtEigene Werkzeuge über alle GesellschaftenBraucht aus dem HauptbuchKunden, Lieferanten, Konten und Steuersätze hinein, Rechnungen, Zahlungen und Buchungssätze zurück, je Gesellschaft
Lesen Sie die rechte Spalte nach unten, dann ist der gemeinsame Teil kaum zu übersehen. Der Kontenrahmen und die Steuersätze tauchen in alle sechs auf, denn fast nichts lässt sich in ein Hauptbuch schreiben, ohne auf ein Konto zu zeigen und einen Satz zu tragen. Das ist das praktische Argument für ein Datenmodell statt einer Anbindung je Markt: die Objekte, die Sie für die erste Branche lernen, sind der Großteil der Objekte, die die nächste braucht, und die Systeme dahinter sind so oder so dieselbe Liste.
Die Unterschiede liest man besser als Anweisung denn als Beiwerk. Ein Kreditgeber liest nur, seine Anbindung muss also nie die Schreibprüfung eines Systems bestehen und riskiert nie ein Duplikat. Eine vertikale SaaS schreibt meist einen Beleg, ihre Arbeit liegt also darin, diesen Beleg richtig zu machen, und nicht in der Breite. Eine Kreditorenplattform tut den ganzen Tag beides und trifft auf jeden Sonderfall von beidem. Das ist dieselbe Anbindung mit drei ziemlich verschiedenen Mengen an Risiko, und deshalb taugt die Schätzung für eine Branche schlecht als Richtschnur für eine andere.
Die Branche wählt das System nicht, Ihr Kunde hat es längst getan
30+ Buchhaltungs- und ERP-Systeme in 20 Ländern, und dieselbe Liste bedient alle sechs Branchen dieser Seite.
Das ist der Teil, der Teams bei ihrer ersten Anbindung überrascht. Sie dürfen das System nicht wählen, und Ihre Branche auch nicht: eine Bauplattform in Bayern und eine Kreditorenplattform, die in dieselbe Straße verkauft, landen beide in dem, was der Buchhalter ihres Kunden vor Jahren eingerichtet hat. Über die Liste entscheiden Land und Größe des Kunden, und deshalb tauchen die deutschen Mittelstandssysteme und die, die ein größerer Konzern fährt, wie Business Central, in völlig verschiedenen Teilen desselben Kundenstamms auf.
Unter den Branchenunterschieden liegen die schweren Teile gemeinsam, und sie sind der Grund, warum ein Integrationsprojekt länger dauert, als es aussieht. Jedes System hat seine eigene Vorstellung davon, wann eine Liste endet und wie man die nächste Seite anfordert, und das klärt ein Modell für Filtern und Blättern. Manche antworten sofort und manche geben einen Auftrag zurück, den man abfragt, und genau das fängt die asynchrone Verarbeitung ab. Und eine einzelne Installation trägt irgendwann ein Feld, für das das gemeinsame Schema keinen Namen hat, und dafür gibt es den Griff am Modell vorbei. Keines dieser drei Dinge ist ein Branchenproblem. Sie kommen, auf welcher Seite Sie auch begonnen haben.
Eine Branchenseite ist die Zielgruppe, ein Use Case ist der Ablauf
Diese Aufteilung sollte man kennen, bevor man eine Seite wählt. Eine Branchenseite spricht an, wer das Produkt baut, und sammelt die Abläufe, die er fahren wird. Eine Use-Case-Seite nimmt einen dieser Abläufe und verfolgt ihn von Anfang bis Ende, mit den Endpunkten und den Entscheidungen, die die Dokumentation an Sie zurückgibt: wie eine Rechnung im System eines Kunden entsteht, wie eine Eingangsrechnung und ihre Zahlung gebucht werden, wie Steuersätze zu dem Buchungssatz kommen, der sie verwendet. Die Branchenseiten verlinken die, auf die sie sich stützen, statt sie zu wiederholen.
Unter beiden liegt dieselbe Mechanik, und sie entscheidet darüber, ob die zweite Anbindung kostet, was die erste gekostet hat: eine Anmeldeschicht über alle Systeme, eine Eventform dort, wo ein System Events aussendet, und eine Haltung, die keine Kopie der Bücher Ihrer Kunden behält. Wenn Sie lieber lesen, was andere Teams damit gemacht haben, als was wir darüber sagen, sind die Case Studies der kürzere Weg.
Eines tun diese Seiten nicht: für Sie raten. Wo ein Ablauf ein Objekt braucht, das die Zielsysteme nicht herausgeben, sagt die Seite es und nennt die Zahl, statt die Lücke in weicheren Worten zu beschreiben. Das ist Absicht: wer eine Integrationsschicht bewertet, ist technisch, findet die Lücke bei der Prüfung ohnehin, und das Einzige, was ein vager Satz einbringt, ist ein schlechteres Gespräch zwei Wochen später. Wo Sie auf einer dieser Seiten eine Zahl sehen, wurde sie gegen die Dokumentation je System gemessen, und wo Sie keine sehen, liegt es daran, dass es dort noch nichts Ehrliches zu schreiben gibt.
Wir nehmen die Systeme von Ihrer Roadmap, nicht das Produkt aus Ihrem Team
Jede Seite unten zieht diese Linie für ihre eigene Branche. Die allgemeine Fassung ist kurz genug, um sie einmal zu nennen.
- Anmeldung und Token je System
- Ein Vokabular für jedes Objekt
- Die Schreibform, die jedes erwartet
- Deren jährliche Brüche
- Welchen Ablauf Sie automatisieren
- Was auf den Beleg gehört
- Wann die Übertragung läuft
- Die eigenen Regeln Ihrer Kunden
Die Linie liegt dort, wo sie liegt, weil jede Seite etwas anderes wissen kann. Eine gemeinsame Schicht kann abnehmen, wie ein System angemeldet werden will, wie es einen Kunden nennt und welche Kennung sagt, zu wessen Büchern ein Aufruf gehört, und sie kann das weiter abnehmen, wenn der Hersteller es sich im nächsten Frühjahr anders überlegt. Sie kann nicht wissen, auf welches Konto Ihr Kunde eine bestimmte Art von Erlös bucht, und die Dokumentation sagt ausdrücklich, dass die Kategorisierungslogik von Ihrer Anwendung abhängt. In welcher der sechs Branchen Sie auch sind, diese Hälfte der Arbeit ist die, für die Ihre Kunden Sie tatsächlich bezahlen.