Mittelstands-ERP-Auswahl hat eine wiederkehrende Pathologie. Das Gespräch beginnt mit einer Shortlist von zwei oder drei Plattformen, die jemand gehört hat — meist weil ein Aufsichtsratsmitglied, ein vorheriger CFO oder eine Vendor-Demo sie dort platziert hat. Die Entscheidung wird dann als Feature-Vergleich, als Preis-Vergleich, manchmal als Gartner-Quadrant-Vergleich neu verhandelt. Die Plattform mit der besten Demo gewinnt. Zwei Jahre später reden Operating-Modell und Plattform nicht mehr miteinander, und das Unternehmen ist in einem teuren Gespräch über Migration, Rescue oder beides.

Der Fehler liegt nicht in den Plattformen. Jede der vier, die wir hier betrachten — Odoo, weclapp, Xentral, NetSuite — ist genau für das Operating-Modell wirklich gut, für das sie gebaut wurde. Der Fehler liegt in der Reihenfolge der Entscheidungen. Mittelstands-ERP-Auswahl ist keine Shortlist-Übung. Sie ist die Frage, welche operative Realität das Unternehmen tatsächlich hat — und erst dann, auf welche Plattform diese Realität abbildet.

Vier Linsen, die den Großteil der Arbeit machen

Unter der Marketing-Schicht treiben tatsächlich nur eine kleine Zahl an Dimensionen die Antwort. Die meisten gescheiterten Auswahlen stolpern über eine dieser vier:

  1. Kunde- vs. Operations-Gewicht. Wo liegt die Komplexität des Unternehmens? Im Verkauf (Kanäle, Marktplätze, Shop, wiederkehrender Umsatz, Projekt-Pricing) — oder in der Lieferung (Lager, Fertigung, Intercompany, Multi-Country)? Auf dieser Achse trennen sich die Plattformen scharf.
  2. Finance-Tiefe. Einzelgesellschaft mit sauberem Buch- und Steuer-Setup — oder Multi-Entity, Multi-Currency, Multi-Book mit auditfester Konsolidierung? Diese Dimension trennt die Suiten, die global skalieren, von denen, die das nicht tun.
  3. Industrie- vs. Service- vs. Commerce-Profil. Diskrete Fertigung, leichte Fertigung, professionelle Dienstleistungen, B2B-Services, DTC-Commerce, B2B-Großhandel — jedes belohnt eine andere Plattform-Form.
  4. Skalierungspfad. Wo steht das Unternehmen in drei Jahren? Gleiche Form, größeres Volumen — oder neue Entitäten, neue Länder, neue Geschäftsmodelle? Manche Plattformen wachsen sauber mit; andere haben eine harte Decke.

Eine klare Lesart auf diesen vier Dimensionen, und die Plattform-Shortlist schrumpft meist von „fünf Kandidaten" auf „eine oder zwei echte Optionen". Der Rest des Vergleichs ist dann ein Plausibilitäts-Check, keine Strategie.

Wann Odoo

Odoos Stärke ist Suite-Breite. Es ist tatsächlich ein Produkt, das CRM, Sales, Lager, Fertigung, E-Commerce, HR, Projekte und Buchhaltung in einem Datenmodell abdeckt. Für mittelständische Unternehmen, die einer Sammlung verbundener Tools entwachsen sind, aber keine Tier-1-Enterprise-Plattform rechtfertigen können, ist Odoos modulare Struktur eine ernsthafte Antwort.

Odoo passt, wenn:

  • Das Unternehmen funktionale Breite über viele angrenzende Bereiche braucht, nicht Tiefe in einem.
  • Kosten-Disziplin real ist — Total Cost of Ownership zählt genauso wie Funktionalität.
  • Ein altes On-Premise-ERP plus drei Nebentools zu einer modernen Suite konsolidiert werden muss.
  • Interne Kapazität (oder Bereitschaft) für durchdachtes Customising vorhanden ist; Odoo belohnt das, aber nur wenn upgrade-freundlich geschnitten.
  • Das Operating-Modell mittelstands-skaliert ist — nicht tiefe Tier-1-Multi-Country-Komplexität, nicht Einzelgesellschaft mit Standard-Prozess.

Odoo ist die falsche Antwort, wenn Finance-Komplexität die führende Beschränkung ist — Multibook-Reporting nach mehreren Rechnungslegungsstandards, auditfeste Konsolidierung über viele Entitäten, tiefe Steuer-Exponierung über Länder. Dort biegt es sich auf Arten, gegen die zu kämpfen sich nicht lohnt. Odoo — JPS-iQ ist die Odoo-Practice der Group, bewusst als unabhängige Beratung positioniert, nicht als Reseller-getriebene Practice.

Wann weclapp

weclapp ist ein anderer Vorschlag. Cloud-nativ, in Deutschland entwickelt, und sein Sweet-Spot sind B2B-getriebene Geschäfte, in denen Kunde, Projekt und Abrechnung ein Datenmodell teilen. Wo Odoo Breite-zuerst ist, ist weclapp Integration-zuerst in einem schmaleren Band.

weclapp passt, wenn:

  • Das Geschäft projektgetriebene Services ist — Beratungen, Agenturen, Engineering-Häuser mit Zeiten, Reisekosten, Projekt-Marge, wiederkehrender Abrechnung.
  • Oder das Geschäft SaaS / Subscription ist — wiederkehrender Umsatz, Customer Success, Finance-Integration mit Subscription-Logik.
  • Oder das Geschäft DACH-Großhandel oder leichte Fertigung ist — Multi-Warehouse-Bestand, Einkauf, deutscher Steuer- und DATEV-Anspruch — ohne DTC-Commerce-Overhead.
  • Cloud, EU-Datenresidenz und eine saubere deutsche UX Entscheidungs­kriterien sind, nicht „nice to have".
  • Das Unternehmen will, dass CRM, Sales, Projekte und Finance als eine Kette funktionieren — nicht als drei zusammen­geflickte Integrationen.

weclapp ist die falsche Antwort, wenn DTC-E-Commerce-Volumen die führende Komplexität ist, oder wenn enterprise-grade Multi-Entity-Finance und globale Steuer-Architektur das Modell tragen müssen. Das erste ist Xentrals Terrain; das zweite ist NetSuite oder SAP. weclapp — JPS-iQ ist die weclapp-Practice der Group, ebenfalls als unabhängige Beratung.

Wann Xentral

Xentral hat einen schärferen Schwerpunkt als Odoo oder weclapp. Es ist gebaut für commerce-getriebene Marken — DTC, marketplace-native, fulfillment-lastig — und seine native Sicherheit reicht von Shop und Kasse über Auftrag, Lager, Versand bis in eine saubere Finance-Übergabe. Es belohnt Unternehmen, die mit Commerce-Volumen stehen oder fallen.

Xentral passt, wenn:

  • Das Geschäft DTC, E-Commerce oder fulfillment-getrieben ist — Wachstum heißt Auftragsvolumen, nicht Anzahl gelieferter Services.
  • Die Shop-Schicht (typischerweise Shopify) Source of Truth für Produkt-Stamm und Kunden ist.
  • Mehrere Verkaufskanäle ein Operations-System brauchen: eigener Shop, Marktplätze (Amazon, Otto, Kaufland, Zalando), B2B-Portale.
  • Lager und Versand erstklassige Themen sind, keine Nachgedanken — Picking-Strategie, Multi-Warehouse, Carrier, Retouren.
  • DATEV-Finance-Übergabe Pflicht ist und die Marke die Finance-Schicht aus demselben System haben will, das die Operations fährt.

Xentral ist die falsche Antwort, wenn das Unternehmen primär B2B-Services oder Projekte ist, oder wenn Commerce ein kleiner Teil einer viel größeren industriellen Operation ist. Dort wird die Commerce-Stärke zum Overhead. Xentral — JPS-iQ ist die zertifizierte Xentral-Practice der Group, gebaut um den Shopify-, Stripe-, ecosio- und DATEV-Stack als eine Lieferung.

Wann NetSuite

NetSuite ist die Plattform, die die Mittelstands-Decke durchstößt. Wenn das Operating-Modell tiefe Multi-Entity-Finance, Multi-Country-Setup, auditfeste Konsolidierung und zusätzlich Retail-, Service- oder Manufacturing-Tiefe verlangt, hält NetSuites Architektur dort, wo die anderen biegen.

NetSuite passt, wenn:

  • Die Gruppe Multi-Subsidiary-, Multi-Currency-Realität hat — heute oder in den nächsten zwei bis drei Jahren — und Audit-Komitees Zahlen erwarten, die einer Prüfung standhalten.
  • Industry-Tiefe zählt: Retail mit Omnichannel-Finance, Professional Services mit Revenue-Recognition, oder Manufacturing mit Planung, Kalkulation und Nachkalkulation.
  • SuiteSuccess oder unser eigener Manufacturing Blueprint das Modell tragen können, wo der Standard hält — und es Bereitschaft gibt, kontrolliert vom Standard abzuweichen, wo nicht.
  • Die Architektur sauber von Mittelstand bis Enterprise auf derselben Plattform skalieren muss, ohne Re-Implementierung.
  • Es einen mehrjährigen Evolutionspfad gibt, nicht nur einen „dieses Quartal live"-Druck.

NetSuite ist die falsche Antwort, wenn das Unternehmen wirklich klein ist, Einzelgesellschaft, mit Standard-Prozessen und ohne realen Pfad in Multi-Entity- Komplexität — die Plattform trägt dann ein Gewicht, das sich nicht rechnet. Dort ist Odoo oder weclapp die bessere Antwort; manchmal ist der richtige Schritt ein fokussierter Zoho-Rollout. NetSuite — JPS-iQ ist die Flagship-Business-Unit der Group.

Zwei Lesarten klären die meisten Fälle. Erste: wo lebt die operative Komplexität — in der Kunden-Kette oder in der Operations-Kette? Zweite: wie tief muss die Finance-Architektur in drei Jahren sein? Diese zwei Antworten zeigen in fast jedem Mittelstands-Fall auf eine der vier Plattformen.

Wo die Entscheidung am häufigsten falsch verschlüsselt wird

Drei Muster wiederholen sich in jeder Auswahl, die mit Bedauern endet.

Muster eins: Wahl nach der Demo, nicht nach dem Operating-Modell. Die geschliffenste Demo gewinnt. Zwei Jahre später ist die Plattform für das konfiguriert, was die Demo zeigte, und das Operating-Modell für das, was die Plattform zuließ. Die Kosten, das aufzulösen, sind ungefähr die Kosten der Implementierung noch einmal — plus operativer Disruption.

Muster zwei: Wahl für das heutige Volumen, nicht für die Drei-Jahres-Form. Unternehmen wählen eine Plattform, die zur aktuellen Gesellschaft perfekt passt — und fügen dann innerhalb von achtzehn Monaten drei Tochter­gesellschaften in drei verschiedenen Ländern hinzu. Die Plattform konnte das nicht wissen, aber die Architektur hätte es gemusst. Auswahl, die den Wachstumspfad ignoriert, ist Auswahl, die in vier Jahren ein Re-Platforming einbaut.

Muster drei: Breite mit Tiefe verwechseln. Eine Suite, die viele Funktionen auf „gut genug"-Niveau abdeckt, ist nicht dasselbe wie eine Plattform, die wenige Funktionen in der Tiefe abdeckt. Für commerce-lastige oder finance-tiefe Operationen produziert das Suite-Breite-Argument leise ein System, das alles schlecht genug abdeckt, um nach achtzehn Monaten drei angrenzende Tools zu brauchen. Genau das Problem, das die Suite lösen sollte.

Wie JPS-iQ die Frage führt

Wir bearbeiten die Entscheidung in der umgekehrten Reihenfolge des Standard- Reseller-Pitches. Das Plattform-Gespräch findet nicht zuerst statt. Es findet am Ende eines zweiwöchigen Assessments statt, das eine einseitige Zielarchitektur produziert — Operating-Modell, Finance-Architektur, Systemlandschaft, Skalierungspfad. Die Plattform-Shortlist fällt aus dieser Skizze. Manchmal landet sie bei Odoo. Manchmal bei weclapp, Xentral, NetSuite, Microsoft, SAP oder Zoho. Manchmal landet sie bei „die Plattform jetzt nicht wechseln — zuerst die Architektur reparieren". Auch das ist eine verteidigbare Antwort.

Das funktioniert strukturell, weil die Group all diese Business Units parallel betreibt — und auf Odoo und weclapp speziell als unabhängige Spezialisten, nicht als Lizenz-Reseller. Es gibt keinen Margenhebel, der die Empfehlung in eine Richtung schiebt. Der Fall für die richtige Plattform ist der Fall, der eine Audit-Komitee-Lesung übersteht — nicht der Fall, der eine Quote schließt.

Kernaussage

Erst auf die operative Realität entscheiden. Odoo für Breite und modulare Flexibilität. weclapp für B2B-Services, Projekte und DACH-Großhandel. Xentral für Commerce, Fulfillment und DTC-Volumen. NetSuite für Multi-Entity-Finance-Tiefe und industrielle Skalierung. Die Plattform ist Folge der Architektur — nie die Strategie selbst.

Was Sie damit am Montag­morgen anfangen

Wenn Sie in einer aktiven Auswahl sind, trennen drei Tests ein echtes Architektur- Gespräch von einem als-Strategie-verkleideten Vendor-Gespräch.

Test eins. Kann die nächste Person, die Ihnen eine Plattform pitcht, Ihre Zielarchitektur auf einer Seite beschreiben, ohne ihr Produkt zu erwähnen? Wenn ja, hören Sie zu. Wenn nein, sind Sie nicht in einem Architektur-Gespräch.

Test zwei. Trägt die Empfehlung in drei Jahren — oder nur heute? Fragen Sie explizit: bei welcher Veränderung Ihres Geschäfts hört diese Empfehlung auf, richtig zu sein? Wenn die Antwort vage ist, ist die Empfehlung vage.

Test drei. Woher kommt die Marge des Partners? Wenn die Antwort „Lizenzquote auf der Plattform, die wir empfehlen" lautet, ist das nicht disqualifizierend — aber Sie lesen ein anderes Dokument als Sie denken.

Wenden Sie diese drei Tests auf jeden an, der gerade mit Ihnen im Raum ist. Wenn die Antworten stehen, ist das Plattform-Gespräch in guten Händen. Wenn nicht, ist das genau die Art von Entscheidung, bei der ein zweiwöchiges, plattform-agnostisches Assessment sich vielfach selbst auszahlt — bevor eine Lizenz unterschrieben wird, bevor ein Implementierungs-Budget feststeht, bevor das Operating-Modell still an einem Freitagnachmittag von einem Implementierungs-Berater geschrieben wird.