Die Plattform ist nicht die Strategie. Die Architektur ist es.

Das Gespräch beginnt meist mit der Plattform. "Wir evaluieren NetSuite gegen S/4HANA." "Sollten wir von Business Central zu D365 F&O wechseln?" "Unser Vorstand will Xentral." Die Frage fühlt sich nach der strategischen Frage an, weil die Antwort mit Preisschild, Migrations-Roadmap und Vendor-Pitch kommt. Sie ist es nicht.

Die strategische Frage — die Frage, von der abhängt, ob die nächsten fünf Jahre rund laufen oder durch drei CFOs und eine Vorstandsumstellung brennen — sitzt eine Ebene darüber. Es ist die Frage der Architektur: wie ERP, Finance, Operations, Governance und die umliegenden Systeme als ein Operating Model zusammenhalten. Die Plattform dient dieser Architektur. Nicht umgekehrt.

Was hier mit „Architektur" gemeint ist

Es geht nicht um Visio-Diagramme. Es geht um die kleine Anzahl von Entscheidungen, die — einmal getroffen — die Form jedes weiteren Bausteins bestimmen. Und die nachträglich sehr teuer zu ändern sind.

Bei internationalen Gruppen liegen diese Entscheidungen auf fünf Ebenen:

1. Operating Model. Welche Gesellschaften, welche Länder, welche legalen Flüsse. Zentral, föderal, hybrid. Das ist keine IT-Frage; es ist eine Governance-Frage, der die IT folgen muss.
2. Finance-Architektur. Kontenrahmen, Multibook, Intercompany-Modell, Steuerarchitektur, Konsolidierungslogik, Reporting-Layer. Die Form der Zahlen — vor dem ersten Modul.
3. Stamm- und Prozessarchitektur. Kunde, Artikel, Lieferant, Projekt — und die Prozesse, die sie bewegen. Wo Daten entstehen, wo sie gepflegt werden, wo sie konsumiert werden.
4. Systemlandschaft. ERP plus die angrenzenden Systeme, die immer auftauchen: CRM, EPM, HRIS, E-Commerce, WMS, BI. Was im ERP lebt, was außerhalb lebt, und wie die Schnittstellen designt sind.
5. Operating Governance. Wer was nach Go-Live verantwortet. Change Management, Release Governance, Incident-Pfad, Audit-Posture. Der Teil, den alle aufschieben — und später bezahlen.

Sind diese fünf Ebenen sauber entschieden, ist die Plattformwahl eine logische Folge. Sind sie es nicht, wird die Plattformwahl zu einem Münzwurf zwischen zwei gleich teuren Fehlern.

Warum „Plattform-first" so zuverlässig scheitert

Wird die Plattform zuerst gewählt, wird jede weitere Entscheidung zur Geisel dieser Wahl. Der Kontenrahmen wird so geformt, wie es die Plattform bequem zulässt. Die Konsolidierungslogik wird aus der Reporting-Struktur der Plattform rückwärts gebaut. Intercompany-Flüsse werden an das Eliminierungsmodell der Plattform angepasst. Stammdaten werden auf die Datensatztypen der Plattform zentriert. Wenn die Architekturdiskussion dann tatsächlich stattfindet — meist sechs Monate später, beim ersten regulatorischen Thema — ist es zu spät. Die Architektur wurde längst still von den Implementierungs-Consultants geschrieben, optimiert auf Liefergeschwindigkeit, nicht auf das Operating Model.

Hier wird auch das klassische Reseller-Anreizmodell sichtbar: Die Plattformwahl ist der Ort, an dem die Marge sitzt — entsprechend kommt das Plattformgespräch zuerst. Das ist keine Verschwörungstheorie, das ist die Mechanik dieses Geschäftsmodells. Sie funktioniert in einfachen, einmandantigen Umgebungen. Sie produziert verlässlich Schaden in internationalen, mehrgesellschaftlichen, finanztiefen Organisationen.

Das Modell „Assessment-first"

Die Alternative ist einfach — und so arbeiten wir in der Gruppe: ein zweiwöchiges Assessment, das eine einseitige Zielarchitekturskizze erzeugt, bevor irgendein Plattformgespräch stattfindet.

Das Assessment deckt ab:

• Operating Model und legale Flüsse — was die Gruppe tatsächlich ist.
• Finance-Architektur — Kontenrahmenlogik, Multibook-Bedarf, Intercompany-Muster, statutarisches und Konzern-Reporting.
• Systemlandschaft — was bereits existiert, was bleibt, was gehen muss.
• Industrielle und operative Tiefe — Manufacturing, Services, Retail, regulierte Aktivität.
• Zeit-, Budget- und Risikofenster — was tatsächlich tragbar ist, durch wen, in welcher Reihenfolge.

Das Ergebnis ist kein 60-Slides-Deck. Es ist eine einseitige Skizze der Zielarchitektur, eine kurze Liste der Plattformen, die sie tragen können, und eine klare Einschätzung, welche davon am besten zu dieser Operation passt — mit offen benannten Trade-offs, nicht versteckten.

Wie das im JPS-iQ-Portfolio aussieht

In der Gruppe ist genau dieses Prinzip der Grund, weshalb wir bewusst ERP-agnostisch arbeiten. Die Architektur entscheidet, welche Plattform sinnvoll ist — nicht umgekehrt.

• Mid-Market Services und Retail mit mehrgesellschaftlicher Finanztiefe: NetSuite sitzt häufig am saubersten.
• Commerce-Volumen mit DACH-Prozessrealität: Xentral trägt oft weiter, als man erwartet.
• Microsoft-Estates mit kontrolliertem Wachstumspfad: Microsoft Dynamics 365 / Business Central.
• Reguliertes Manufacturing, finanzkontroll-lastige Umgebungen: SAP S/4HANA.
• Global verteilte Teams mit starkem CRM/Finance-Integrationsbedarf und pragmatischen Budgets: Zoho.

Plattformunabhängig trägt OPCON die Execution-Schicht und BPO die Finance-Operations — so bleibt die Architektur vom Blueprint bis in den Live-Betrieb verantwortet, auf jeder Plattform der Gruppe.

Was sich daraus am Montagmorgen ableiten lässt

Wenn Sie mitten in einer Auswahl oder einem ins Stocken geratenen Programm stehen, ist der nützlichste Test der einfachste: Bitten Sie die nächste Person, die Ihnen eine Plattform vorstellt, Ihre Zielarchitektur auf einer Seite zu beschreiben — ohne ihr Produkt zu erwähnen. Wenn sie es kann, hören Sie zu. Wenn nicht, führen Sie kein Architekturgespräch. Sie führen ein Vendor-Gespräch — und das ist ein anderes Gespräch, mit anderen Konsequenzen.

Für Vorstände, CFOs und COOs ist die praktische Bewegung, die Architekturdiskussion von der Plattformdiskussion zu trennen. Erst das Assessment. Danach die Plattformentscheidung — auf Basis einer Skizze, die im Audit-Komitee verteidigt werden kann. Die Kosten dafür: zwei Wochen. Die Kosten, es nicht zu tun, werden üblicherweise in Jahren gemessen.