Wir empfehlen nur Systeme, die für die Cloud und für KI gebaut sind. Nicht weil es Mode ist, sondern weil die Alternative bedeutet, Konzernpreise für Einschränkungen zu bezahlen, die 2005 vernünftig waren. Das meinen wir mit modern, in der Reihenfolge, in der wir es prüfen.
UX first
Die Benutzeroberfläche ist kein Anstrich. In einem modernen ERP wird die Oberfläche aus dem Geschäftsobjekt erzeugt: Kommt ein Feld hinzu, kennen Formular, Liste, Suche, Import, Export und API es. In älteren Systemen ist jedes davon eine eigene Entwicklungsaufgabe, weshalb «kleine Änderungen» Wochen kosten.
Wir erwarten, dass sich die Oberfläche so verhält, wie Deine Leute es von Software bereits gewohnt sind: vorhersehbare Anordnung, tastaturfreundlich, Suche überall, Rückgängigmachen, wo es zählt. Diese Erwartung setzt das Telefon in ihrer Tasche, und für das ERP wird sie nicht gesenkt.
Infrastrukturunabhängig und responsiv
Browserbasiert, auf jedem Gerät, ohne Client-Installation oder Terminalserver. Ein Lagermitarbeiter am Scanner, eine Technikerin mit dem Tablet im Feld, ein CFO, der eine Zahlung auf dem Telefon freigibt, eine Buchhalterin an zwei Bildschirmen: ein System, ein Login, Layouts, die sich anpassen. Alles, was den «ERP-PC» voraussetzt, fällt durch.
API first
Jede Funktion, die die Oberfläche ausführen kann, muss auch programmatisch erreichbar sein, für Standardobjekte wie für eigene. Aus drei Gründen:
Integration ist nicht mehr optional
E-Rechnungs-Netzwerke, Banken, Lohnanbieter, Webshops und Steuer-Engines verbinden sich über APIs oder gar nicht.
Automatisierung wandert von Skripten zu Agenten
KI-Agenten werden über die API in Deinem ERP handeln, nicht indem sie sich durch Masken klicken. Ein System mit schöner Oberfläche und dünner API bleibt dieser Zukunft verschlossen.
Weiterentwicklung
Eine API-first-Plattform lässt sich erweitern, ohne sie abzuspalten; das hält Dich auf dem Upgrade-Pfad.
Skalierbarkeit in der Cloud
Elastische Kapazität für Monatsabschluss, Jahresabschluss, Hochsaison und die Übernahme, die Du noch nicht angekündigt hast. Aber Skalierbarkeit ist eine Eigenschaft der Architektur, nicht des Hostings: Eine geteilte Anwendungsdatenbank, die zum Quartalsende für alle Mandanten langsamer wird, ist nicht skalierbar, was immer die Broschüre sagt.
Gebaut für KI
KI im ERP ist nur so gut wie das Datenmodell darunter. Saubere Stammdaten, explizite Prozesse und ein stimmiges Objektmodell sind die Voraussetzungen; der Assistent ist der einfache Teil. Wir beurteilen die KI-Reife danach, was das System weiss, nicht danach, was der Hersteller vorgeführt hat.
Warum wir trotzdem nicht «voll in die Cloud» gehen, nicht zu den Bedingungen des Herstellers
Hier weichen wir von der Broschüre ab. Gebaut für die Cloud darf nicht heissen: an eine Cloud gekettet. Public Cloud, Private Cloud und On-Premise sind unterschiedliche Antworten auf unterschiedliche Fragen: Datenhoheit, Souveränität, Latenz, Ausstieg. Für ein Schweizer Familienunternehmen mit sensiblen Kunden- oder Konstruktionsdaten kann eine private Installation die richtige Wahl sein; für ein schnell wachsendes Handelsunternehmen ist es Multi-Tenant-SaaS. Das System soll die Wahl erlauben, und die Wahl soll Deine sein, umkehrbar und dokumentiert.
Dieselbe Logik gilt für Deine KI: Modelle, die mit sensiblen Geschäftsdaten arbeiten, sollten isoliert laufen können.
Warum Plattform oder Best-of-Breed noch immer ein bewusster Entscheid ist
Jeder ERP-Hersteller verspricht, alles zu können. Keiner kann alles gut. Die richtige Architektur ist eine bewusste Mischung. Die Plattform besitzt das transaktionale Rückgrat (Procure-to-Pay, Order-to-Cash, Lager, Finanzen) und die Stammdaten. Best-of-Breed-Anwendungen besitzen die Tiefe, wo Tiefe entscheidet: länderspezifische Lohnbuchhaltung, E-Rechnungs- und Steuer-Clearance-Netzwerke, Lagersteuerung, Produktdaten, Analytik.
Der Fehler ist nicht, sich für das eine oder das andere zu entscheiden. Der Fehler ist, sich gar nicht zu entscheiden. Der ERP-Bericht 2026 von Panorama Consulting ergab, dass bei Organisationen mit Budgetüberschreitung die häufigste Ursache ein unerwarteter Bedarf an zusätzlicher Technologie war: Fehlpassungen, die spät im Projekt entdeckt wurden 3. Das ist Architektur aus Versehen. Wir legen die Grenzen vor der Auswahl fest, damit Integrationen entworfen und nicht erst entdeckt werden.
Was die Plattform zusammenhalten muss, zeichnen wir als drei Kreise. Jeder äussere Kreis ist die Breite, die ein Unternehmen braucht; sein innerer Kreis ist die Tiefe, die über die Eignung entscheidet. In der Mitte müssen alle drei zugleich funktionieren.
Die Pfeiltasten wechseln zwischen den Kreisen.
Äusserer Kreis
Platform ERP
Eine Plattform für das transaktionale Rückgrat: gemeinsame Stammdaten, ein Berechtigungsmodell, eine Oberfläche und eine API. Eine neue Anforderung erweitert die Plattform, statt ein weiteres System daneben zu stellen.
In einer Vorführung verlangen wir eine neue Freigaberegel und eine rollenspezifische Ansicht, und beide müssen ein Upgrade überstehen.
Innerer Kreis
Low Code, visueller Editor
Geschulte Fachanwender ändern Felder, Formulare, Ansichten, Regeln und Berichte in einem visuellen Editor, ohne Entwicklungsprojekt. Das verkürzt den Weg von einem Prozessbedarf zu einer funktionierenden Verbesserung, solange jede Änderung einen Verantwortlichen hat.
Wir lassen uns zeigen, wie ein neues Feld einmal angelegt und dann in einem Formular, in einer Liste, in einem Bericht und über die API genutzt wird, ohne Code.
Äusserer Kreis
Mehrere Währungen, mehrere Standorte, globale Einheiten
Der Ausgangspunkt für ein Unternehmen, das über Grenzen hinweg handelt: Rechnungen und Zahlungen in mehreren Währungen, mehr als eine Niederlassung oder ein Standort und Gesellschaften in mehr als einem Land.
Wir lassen uns eine Fremdwährungsrechnung zeigen, die zu einem anderen Kurs bezahlt wird, und die Kursdifferenz dort gebucht, wo Deine Buchhaltung sie erwartet.
Innerer Kreis
Mehrere Hauptbücher, Basiswährungen und Gesellschaften
Die Tiefe hinter den globalen Einheiten: Jede Gesellschaft führt ihre eigenen Bücher in ihrer eigenen Basiswährung, parallele Hauptbücher halten unterschiedliche Rechnungslegungen auseinander, etwa nach lokalem Recht und nach IFRS, und die Gesellschaften handeln innerhalb eines Systems miteinander. Mehrere Gesellschaften bedeuten noch nicht mehrere Basiswährungen oder parallele Hauptbücher; darum prüfen wir jedes einzeln.
Wir lassen uns Deine eigene Gesellschaftsstruktur zeigen: eine Transaktion zwischen zwei Gesellschaften mit unterschiedlichen Basiswährungen und die konsolidierte Sicht.
Äusserer Kreis
Module für Lager, Anlagen und Services
Waren, Anlagen und die Zeit von Menschen folgen unterschiedlichen Lebenszyklen. Bestand wird eingelagert, umgelagert und verkauft; eine Anlage wird beschafft, gewartet und abgeschrieben; eine Dienstleistung wird geplant, erbracht und verrechnet. Die eigenen Module der Plattform decken alle drei ab, auf denselben Kunden, Artikeln und Konten.
Wir lassen uns die Übergänge zeigen: ein Gerät, das samt Installation verkauft wird, und einen Servicevertrag, der Ersatzteile verbraucht.
Innerer Kreis
Projekte, die Lager und Zeit verbinden
Wo sich die Module treffen: Ein Projekt verbraucht Bestand und die Zeit von Menschen und verrechnet beides gegen eine Zusage. Ein leistungsfähiges Projektmodul und ein leistungsfähiges Lagermodul belegen für sich allein noch nicht, dass Material mit der erforderlichen Kalkulation, Eigentumszuordnung und Fakturierung durch einen Serviceauftrag fliessen kann.
Wir lassen uns ein Projekt zeigen, das Bestand und genehmigte Zeit verbraucht, samt einer Änderung, einer Rücksendung und einer Ausnahme bei der Verrechnung.
Wo sich die Kreise treffen
Die Mitte
Ein Projekt über mehrere Gesellschaften hinweg verbindet Bestand, die Zeit von Menschen, Währungen und lokales Reporting, und ein im Editor geänderter Ablauf muss durchgehend die richtigen Freigaben und Buchungen einhalten. Das suchen wir in einem modernen ERP: alle drei Kreise in einer Plattform und einem Datenmodell.
Drei überzeugende Modulvorführungen beweisen nicht, dass der Gesamtprozess funktioniert; darum prüfen wir die Mitte ausdrücklich.
Warum UX König ist
Weil die Menschen, die über ein ERP entscheiden (Führungskräfte, Architekten, Berater, Entwickler), nicht die Menschen sind, die es jeden Tag fahren. Spüren die täglichen Fahrer die Bedienung nicht, schauen sie nicht mehr aufs Dashboard. Sie führen ihre eigene Liste. Die Datenqualität bricht ein, und alles Nachgelagerte (Reporting, Prognosen, KI) erbt den Einbruch. «Garbage in, garbage out» ist kein technisches Versagen. Es ist ein UX-Versagen, das zum Finanzproblem wird.
Quellen
Alle regulatorischen Angaben mit Stand September 2026.
- Panorama Consulting Group, The 2026 ERP Report: panorama-consulting.com (PDF: 4439340.fs1.hubspotusercontent-na1.net)