Welches ERP-System passt, wenn Sie 3 Bereiche integrieren müssen und Excel ablösen wollen?

Wenn drei Unternehmensbereiche künftig mit denselben Daten arbeiten sollen, ist ein neues ERP-System nicht automatisch die beste Lösung. Entscheidend ist, ob die Software Ihre tatsächlichen Abläufe durchgängig unterstützt, bestehende Medienbrüche beseitigt und sich ohne unverhältnismässige Sonderentwicklungen erweitern lässt. Gerade Schweizer KMU müssen dabei auch Buchhaltungsanforderungen, Mehrwertsteuer, Sozialversicherungen und den Umgang mit Personendaten berücksichtigen.

Die Ablösung von Excel sollte deshalb nicht mit einer Anbieterliste beginnen. Zuerst müssen Geschäftsprozesse, Datenverantwortlichkeiten und kritische Schnittstellen sichtbar werden. Anschliessend lässt sich prüfen, welche Anforderungen ein ERP im Standard erfüllt, wo Konfiguration genügt und welche Lücken tatsächlich eine Entwicklung rechtfertigen.

Eine belastbare Auswahl entsteht durch wenige, gut vorbereitete Workshops, konkrete Prozessdemonstrationen und eine nachvollziehbare Gesamtkostenbetrachtung. So vermeiden Sie, dass ein vermeintlich umfassendes System lediglich die bisherigen Excel-Probleme in eine neue Software überträgt.

Warum Ihr digitales Unternehmensökosystem ab 3 Tools unübersichtlich wird und wie Sie Ordnung schaffen

Ein digitales Unternehmensökosystem wird nicht allein durch die Anzahl seiner Anwendungen unübersichtlich. Das eigentliche Risiko entsteht, wenn Systeme dieselben Informationen unterschiedlich verwalten, Daten mehrfach erfasst werden und wichtige Abläufe von manuellen Exporten oder einzelnen Mitarbeitenden abhängen. Drei Anwendungen können problemlos zusammenarbeiten, wenn Datenflüsse und Verantwortlichkeiten eindeutig geregelt sind. Umgekehrt kann bereits eine kleinere Systemlandschaft erhebliche Abstimmungsprobleme verursachen.

Typisch ist eine Kombination aus separater Buchhaltungssoftware, CRM und Lagerverwaltung. Kundendaten werden im CRM gepflegt, Auftragsinformationen in einer anderen Anwendung ergänzt und Lagerbewegungen in einer lokalen Lösung erfasst. Anschliessend werden Informationen per Excel übertragen oder manuell abgeglichen. Damit entstehen mehrere Versionen derselben Information.

Besonders kritisch wird es, wenn niemand die vollständige Verantwortung für eine Schnittstelle trägt. Fällt die Person aus, die regelmässig Daten exportiert, bereinigt und importiert, kann ein ansonsten funktionierender Prozess ins Stocken geraten.

Eine kurze Selbstdiagnose zeigt, ob die bestehende Systemlandschaft neu geordnet werden sollte:

• Werden Kunden-, Artikel- oder Finanzdaten in mehreren Anwendungen gepflegt?
• Wie viele manuelle Exporte und Importe werden monatlich durchgeführt?
• Gibt es Schnittstellen, deren Funktionsweise nur eine Person kennt?
• Werden Abweichungen zwischen den Systemen regelmässig manuell korrigiert?

Wenn mehrere dieser Fragen zutreffen, ist eine systematische Integrationsprüfung sinnvoll. Das bedeutet allerdings nicht automatisch, dass sämtliche Anwendungen ersetzt werden müssen.

Eine bessere Ordnung entsteht in drei Schritten. Zuerst werden die Prozesse dokumentiert, beispielsweise vom Angebot über den Auftrag bis zur Lieferung und Rechnung. Danach wird jeder Prozessschritt der tatsächlich verwendeten Anwendung zugeordnet. Abschliessend wird festgelegt, welches System für welches Datenobjekt verbindlich ist.

Diese eindeutige Datenverantwortung wird häufig als Single Source of Truth bezeichnet. Für Kundendaten kann beispielsweise das CRM zuständig sein, während Artikelbestände ausschliesslich im führenden Warenwirtschaftssystem gepflegt werden.

Bei Schweizer KMU mit zwei Standorten oder mehreren Sprachregionen kommt eine zusätzliche Herausforderung hinzu. Unterschiedliche lokale Arbeitsweisen können dazu führen, dass Standorte eigene Anwendungen und Datenbestände entwickeln. Die Systemlandschaft sollte deshalb nach gemeinsamen Prozessen und nicht ausschliesslich nach Standortgrenzen organisiert werden.

Das Schweizer KMU-Portal des SECO empfiehlt bei Unternehmenssoftware insbesondere die Kompatibilität der einzelnen Programme, modulare Erweiterbarkeit und regelmässige Updates zu berücksichtigen. Für Buchhaltungssoftware sind ausserdem Schweizer Anforderungen wie Kontenrahmen, Mehrwertsteuer, Währungen und Sozialversicherungen relevant. Diese Empfehlungen des Schweizer KMU-Portals zur Softwareauswahl bieten eine geeignete Grundlage für die Bestandsaufnahme.

Die entscheidende Frage lautet daher nicht, wie viele Anwendungen Ihr Unternehmen besitzt, sondern ob die Daten zwischen ihnen kontrolliert und nachvollziehbar fliessen.

Erst wenn sichtbar ist, wo Informationen doppelt entstehen und welche Anwendungen voneinander abhängig sind, lässt sich beurteilen, ob eine integrierte Plattform wirtschaftlich sinnvoller ist als eine gezielte Verbesserung der bestehenden Schnittstellen.

Warum 7 Einzellösungen oft teurer sind als 1 integrierter Stack

Sieben Einzellösungen können langfristig teurer sein als ein integrierter Software-Stack, wenn mehrere Anwendungen dieselben Daten verarbeiten und dadurch zusätzliche Schnittstellen-, Wartungs- und Abstimmungsarbeit entsteht. Der entscheidende Kostenunterschied liegt häufig nicht bei den monatlichen Lizenzgebühren, sondern bei den laufenden Aufwänden für den Betrieb der gesamten Systemlandschaft.

Eine isolierte Betrachtung der Softwarepreise führt deshalb leicht zu einer falschen Entscheidung. Ein günstiges CRM, eine separate Lagerlösung und eine eigenständige Buchhaltungssoftware können jeweils wirtschaftlich erscheinen. Zusammen verursachen sie jedoch möglicherweise einen erheblichen Koordinationsaufwand.

Für einen fairen Vergleich sollten Sie mindestens folgende Kostenpositionen berücksichtigen:

• Lizenzen und Hosting: Wiederkehrende Gebühren für jede Anwendung und ihre technische Infrastruktur.
• Wartung und Support: Abstimmung mit mehreren Anbietern und unterschiedliche Supportprozesse.
• Schnittstellenpflege: Überwachung, Fehlerbehebung und Anpassung bei Softwareupdates.
• Schulung: Einarbeitung der Mitarbeitenden in verschiedene Benutzeroberflächen und Abläufe.
• Manuelle Übertragung: Zeitaufwand für Exporte, Importe, Datenbereinigung und Abstimmungen.
• Fehlerkorrekturen: Nacharbeit aufgrund doppelter oder inkonsistenter Informationen.

Ein zusätzlicher Kostenfaktor ist die Verteilung der Ausgaben auf unterschiedliche Abteilungen. Die CRM-Lizenz steht möglicherweise im Vertriebsbudget, die Lagerlösung im operativen Bereich und die Schnittstellenwartung im IT-Budget. Dadurch erscheint keine einzelne Anwendung besonders teuer, obwohl die Gesamtlandschaft einen erheblichen Ressourcenbedarf verursacht.

Ein integrierter Stack macht diese Kosten häufig transparenter. Allerdings ist auch ein ERP-System nicht automatisch günstiger. Lizenzmodell, Implementierungsaufwand, Datenmigration, Schulung und erforderliche Anpassungen müssen ebenfalls berücksichtigt werden.

Eine sinnvolle Vergleichsrechnung betrachtet deshalb beide Varianten über denselben Zeitraum und mit denselben Kostenkategorien. Dabei sollte nicht nur die heutige Situation bewertet werden, sondern auch der erwartete Aufwand bei zusätzlichen Standorten, Mitarbeitenden oder Geschäftsprozessen.

Ein hypothetisches Beispiel verdeutlicht den Unterschied: Ein Schweizer KMU verwendet eine Cloud-Buchhaltung, ein separates CRM und eine lokale Lagerlösung. Die Mitarbeitenden gleichen Aufträge und Lagerbestände regelmässig über Tabellen ab. Ein integriertes Kernsystem könnte diesen Aufwand reduzieren. Ob sich die Investition rechnet, hängt jedoch davon ab, welche Schnittstellen tatsächlich entfallen und welche Kosten durch Einführung und Betrieb neu entstehen.

Wichtig ist auch die Grenze des Integrationsgedankens: Nicht jede Spezialsoftware sollte ersetzt werden. Eine Anwendung mit einem echten fachlichen Vorteil kann weiterhin sinnvoll sein, sofern sie zuverlässig an das Kernsystem angebunden ist. Entscheidend ist das Verhältnis zwischen ihrem Prozessnutzen und dem zusätzlichen Schnittstellenaufwand.

Für die Entscheidung empfiehlt sich eine Total-Cost-of-Ownership-Betrachtung. Sie stellt sämtliche wiederkehrenden und einmaligen Kosten der bestehenden Systemlandschaft den erwarteten Kosten eines integrierten Systems gegenüber.

Wenn Spezialanwendungen einen nachweisbaren Mehrwert bieten, sollten sie erhalten bleiben. Ziel ist nicht die geringstmögliche Anzahl an Programmen, sondern eine wirtschaftliche Architektur mit kontrollierten Datenflüssen.

Warum Funktionslisten Ihr ERP-Projekt in die falsche Richtung treiben?

Funktionslisten führen bei der ERP-Auswahl häufig in die falsche Richtung, weil sie einzelne Softwarefunktionen vergleichen, aber nicht zeigen, ob ein System Ihre tatsächlichen Geschäftsprozesse zuverlässig unterstützt. Eine Lösung mit vielen Häkchen kann in der Praxis schlechter passen als ein schlankeres ERP, dessen Standardfunktionen Ihre wichtigsten Abläufe durchgängig abbilden.

Das Problem beginnt häufig bei der Erstellung des Anforderungskatalogs. Verschiedene Abteilungen sammeln Wünsche, die anschliessend als einzelne Funktionen in einer Vergleichstabelle erscheinen. Anbieter erhalten dieselbe Liste und markieren, welche Funktionen vorhanden sind.

Diese Vorgehensweise hat einen entscheidenden Nachteil: Sie betrachtet Funktionen isoliert. Ob ein Auftrag vom Vertrieb über die Lagerverwaltung bis zur Fakturierung ohne doppelte Dateneingabe verarbeitet werden kann, wird dadurch nicht automatisch geprüft.

Für die Auswahl eines ERP-Systems sollten Sie deshalb zwischen zwei Betrachtungsebenen unterscheiden:

• Einzelfunktionen: Kann die Software beispielsweise Artikel verwalten, Rechnungen erstellen oder Kundendaten speichern?
• Prozessketten: Können die Informationen zwischen den beteiligten Bereichen ohne Medienbruch, widersprüchliche Daten oder unnötige manuelle Schritte weitergegeben werden?

Die zweite Ebene ist für die ERP-Entscheidung wesentlich aussagekräftiger. Besonders bei der Integration von drei Unternehmensbereichen muss deutlich werden, wie ihre jeweiligen Arbeitsschritte ineinandergreifen.

Statt 300 Funktionen abzuhaken, sollten Sie zunächst acht bis zwölf kritische End-to-End-Prozesse identifizieren. Ein Beispiel ist die Kette Angebot, Auftrag, Lager, Lieferung und Rechnung. Weitere Prozesse können Einkauf, Wareneingang, Rechnungsprüfung oder Finanzabschluss betreffen.

Für jeden Prozess wird festgehalten, welche Informationen entstehen, wer sie bearbeitet, welche Freigaben erforderlich sind und welche Daten an den nächsten Schritt übergeben werden. Die Anbieter müssen anschliessend anhand dieser konkreten Abläufe demonstrieren, wie ihre Software funktioniert.

Auch die Entscheidungspsychologie spielt eine Rolle. Umfangreiche Funktionslisten vermitteln einem Auswahlgremium schnell ein Gefühl von Sicherheit. Tatsächliche Zielkonflikte zwischen den Abteilungen bleiben jedoch häufig ungelöst. Beispielsweise kann der Vertrieb maximale Flexibilität wünschen, während die Buchhaltung standardisierte Abläufe und nachvollziehbare Belege benötigt.

Werden diese Prioritäten erst nach der Vertragsunterzeichnung geklärt, entstehen häufig zusätzliche Konfigurations- oder Entwicklungsanforderungen. Genau deshalb müssen die wichtigsten Prozessentscheidungen vor der Produktauswahl getroffen werden.

Für Schweizer Unternehmen kommt hinzu, dass die Verfügbarkeit einer Buchhaltungsfunktion allein nicht ausreicht. Die konkrete Umsetzung der Schweizer Mehrwertsteuer, des Kontenrahmens und der Sozialversicherungen muss ebenfalls überprüft werden.

Erst mit diesen Prozessfällen lässt sich zuverlässig beurteilen, ob ein ERP-System im Standard passt oder ob eine Lücke tatsächlich eine Konfiguration, Prozessänderung oder individuelle Entwicklung erforderlich macht.

Wie führen Sie eine Fit-Gap-Analyse in 5 Workshops durch, ohne Beraterarmee?

Eine Fit-Gap-Analyse können Sie mit fünf strukturierten Workshops durchführen, wenn die internen Prozessverantwortlichen vorbereitet sind und jeder Termin ein klar definiertes Ergebnis hat. Ziel ist nicht, jede Softwarefunktion zu untersuchen, sondern die wichtigsten Anforderungen mit den tatsächlichen Möglichkeiten des ERP-Systems abzugleichen.

Fit bezeichnet eine Anforderung, die das System bereits ausreichend erfüllt. Gap bezeichnet eine Abweichung zwischen dem benötigten Prozess und der verfügbaren Standardfunktion. Diese Unterscheidung ist wichtig, weil nicht jede Lücke automatisch durch individuelle Entwicklung geschlossen werden sollte.

Ein schlankes Vorgehen kann folgendermassen aussehen:

1. Workshop 1 – Kernprozesse und Muss-Kriterien: Die drei zu integrierenden Bereiche und ihre wichtigsten End-to-End-Prozesse dokumentieren. Ergebnis ist eine priorisierte Liste kritischer Anforderungen.
2. Workshop 2 – Fit-/Gap-Bewertung: Die Anforderungen je ERP-Modul mit dem Anbieter prüfen. Ergebnis ist eine dokumentierte Bewertung der vorhandenen Standardfunktionen und identifizierten Lücken.
3. Workshop 3 – Gap-Kategorisierung: Jede Lücke einer konkreten Behandlung zuordnen: Prozess anpassen, Standard nutzen, konfigurieren oder individuell entwickeln. Ergebnis ist ein verbindliches Gap-Register.
4. Workshop 4 – Aufwand und Reihenfolge: Aufwand, Abhängigkeiten, Risiken und Einführungsschritte bewerten. Ergebnis ist eine priorisierte Umsetzungsplanung.
5. Workshop 5 – Entscheidung und Roadmap: Offene Punkte, Kostenannahmen und Verantwortlichkeiten zusammenführen. Ergebnis ist eine nachvollziehbare Entscheidungsvorlage mit Einführungsroadmap.

Besonders wichtig ist die konsequente Unterscheidung der vier Behandlungsmöglichkeiten. Eine Prozessänderung kann eine unnötige Sonderanforderung beseitigen. Die Nutzung einer Standardfunktion verhindert zusätzliche technische Komplexität. Eine Konfiguration passt vorhandene Einstellungen an. Eine individuelle Entwicklung sollte dagegen nur dann erfolgen, wenn ein relevanter Geschäftsprozess anders nicht sinnvoll abgebildet werden kann.

Ohne grosse externe Beraterteams funktioniert dieses Vorgehen, wenn die internen Verantwortlichen ihre Prozesse bereits vor dem ersten Termin skizzieren. Hilfreich sind konkrete Beispieldaten, typische Geschäftsfälle und eine Liste der heutigen Probleme. Der Anbieter sollte die Fit-Gap-Bewertung nachvollziehbar dokumentieren.

Eine mündliche Aussage wie «Das lässt sich problemlos umsetzen» ist keine ausreichende Entscheidungsgrundlage. Kritische Anforderungen müssen in einer Demonstration mit eigenen Beispieldaten überprüft werden. Die Ergebnisse und zugesagten Leistungen sollten vor Vertragsabschluss schriftlich festgehalten werden.

Für eine wirksame Prüfung eignet sich folgende Vorgehensweise mit fünf überprüfbaren Arbeitsergebnissen:

Eine gute Fit-Gap-Analyse liefert damit nicht nur eine Liste fehlender Funktionen. Sie zeigt, welche Abweichungen geschäftlich relevant sind, welche Lösungen ohne Sonderentwicklung möglich sind und welche Risiken vor der Vertragsunterzeichnung noch geklärt werden müssen.

Wenn die funktionale Passung geklärt ist, muss als nächstes das Betriebsmodell geprüft werden. Insbesondere bei mehreren Standorten kann die Verfügbarkeit des Systems für Lager, Vertrieb und Finanzprozesse entscheidend sein.

Cloud-ERP oder On-Premise: Was passt bei 2 Standorten und strengen Verfügbarkeitsanforderungen?

Ob Cloud-ERP oder On-Premise besser passt, hängt bei zwei Standorten vor allem von der Internetanbindung, den Anforderungen an den Lagerbetrieb, den verfügbaren IT-Ressourcen und den Wiederherstellungszielen ab. Eine pauschale Entscheidung zugunsten der Cloud oder der eigenen Infrastruktur ist nicht sinnvoll. Entscheidend ist, wie sich beide Betriebsmodelle unter realistischen Ausfallszenarien verhalten.

Ein Cloud-ERP wird zentral beim Anbieter oder dessen Infrastrukturpartner betrieben. Die Standorte greifen über das Netzwerk auf das System zu. Dadurch kann die interne Infrastruktur entlastet werden, während die Abhängigkeit von der Internetverbindung und dem Cloud-Betrieb steigt.

Bei einer On-Premise-Lösung betreibt das Unternehmen die Software auf eigener Infrastruktur oder in einer entsprechend kontrollierten Umgebung. Das schafft mehr unmittelbare Kontrolle über den technischen Betrieb, setzt aber ausreichende Kompetenzen für Wartung, Datensicherung, Sicherheit und Wiederherstellung voraus.

Für die Auswahl sollten Sie fünf Kriterien getrennt bewerten:

• Internetverbindung: Sind beide Standorte ausreichend zuverlässig angebunden? Gibt es eine alternative Verbindung für kritische Prozesse?
• Latenz: Funktionieren Lagerbewegungen, Scanner und andere zeitkritische Anwendungen ohne störende Verzögerungen?
• IT-Ressourcen: Kann das Unternehmen den eigenen Betrieb und die erforderliche Wartung zuverlässig gewährleisten?
• Recovery-Ziele: Wie schnell muss das System nach einer Unterbrechung wieder verfügbar sein und wie viel Datenverlust ist akzeptabel?
• Nachvollziehbarkeit: Welche Anforderungen gelten für Datenaufbewahrung, Zugriffe und revisionsrelevante Prozesse?

Bei der Verfügbarkeit müssen zwei Risiken unterschieden werden: ein Ausfall des externen Dienstleisters und ein Ausfall der eigenen Infrastruktur. Beide Szenarien können denselben Geschäftsprozess unterbrechen, benötigen aber unterschiedliche Gegenmassnahmen.

Besonders aussagekräftig ist ein konkreter Test: Was passiert, wenn ein Mitarbeitender im Lager einen Barcode scannt und gleichzeitig die Netzwerkverbindung ausfällt? Kann der Vorgang lokal zwischengespeichert werden? Werden Daten später korrekt synchronisiert? Welche Funktionen bleiben verfügbar?

Für die Wiederherstellung nach einem Ausfall sind zwei technische Begriffe besonders wichtig. Das Recovery Time Objective (RTO) bezeichnet die maximal akzeptable Zeit bis zur Wiederherstellung eines Dienstes. Das Recovery Point Objective (RPO) beschreibt den maximal akzeptablen zeitlichen Abstand zwischen dem letzten Wiederherstellungspunkt und dem Ausfall.

Beide Werte müssen aus den tatsächlichen Geschäftsanforderungen abgeleitet werden. Ein Lagerprozess kann andere Wiederherstellungsziele benötigen als ein weniger zeitkritischer Auswertungsprozess. Die technische Dokumentation von AWS zu RTO und RPO erläutert diese Unterscheidung. Daraus ergeben sich jedoch keine allgemeingültigen Schweizer ERP-Vorgaben.

Auch ein hybrides Betriebsmodell kann sinnvoll sein. Ein Cloud-Kernsystem kann beispielsweise mit lokalen Notfallfunktionen kombiniert werden. Alternativ kann ein Unternehmen ein lokal betriebenes ERP mit einzelnen Cloud-Anwendungen verbinden. Entscheidend ist, dass Datenkonsistenz und Wiederanlaufverhalten tatsächlich getestet werden.

Für Schweizer Unternehmen gehört ausserdem die Datenschutzprüfung in die Cloud-Auswahl. Der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte (EDÖB) weist darauf hin, dass die verantwortliche Organisation auch bei der Auslagerung an einen Cloud-Dienst für die Rechtmässigkeit der Datenbearbeitung verantwortlich bleibt.

Zu prüfen sind insbesondere Auftragsbearbeitung, Unterauftragsbearbeiter, Datensicherheit und mögliche Auslandübermittlungen von Personendaten. Ein Schweizer Hostingstandort allein beweist noch keine vollständige Datenschutzkonformität. Die Datenschutzhinweise des EDÖB zum Cloud-Computing bieten hierfür eine offizielle Orientierung.

Das Betriebsmodell sollte deshalb anhand dokumentierter Anforderungen und getesteter Ausfallszenarien bewertet werden, nicht anhand allgemeiner Versprechen zur Verfügbarkeit.

Wenn die Infrastrukturentscheidung getroffen ist, bleibt eine weitere langfristige Kostenfrage: Wie weit darf das ERP-System individuell angepasst werden, ohne spätere Updates und Erweiterungen unnötig zu erschweren?

Der ERP-Customizing-Fehler, der Updates blockiert und Kosten explodieren lässt

Der häufigste strategische Fehler beim ERP-Customizing besteht darin, individuelle Entwicklungen für Anforderungen zu beauftragen, die sich durch eine Prozessanpassung oder vorhandene Standardfunktionen lösen liessen. Jede zusätzliche Erweiterung kann langfristigen Wartungsaufwand verursachen. Bei späteren Softwareupdates muss geprüft werden, ob die Anpassung weiterhin funktioniert und mit der neuen Version kompatibel ist.

Das Problem entsteht häufig bereits in der frühen Auswahlphase. Ein Unternehmen entdeckt eine Abweichung zwischen seinem bisherigen Ablauf und dem ERP-Standard. Statt zu prüfen, ob der Prozess vereinfacht werden kann, wird eine individuelle Entwicklung als schnelle Lösung vereinbart.

Damit entsteht eine technische Abhängigkeit. Die Anpassung muss dokumentiert, getestet und bei Änderungen der Basissoftware erneut überprüft werden. Je mehr individuelle Erweiterungen entstehen, desto grösser kann der Aufwand für die langfristige Pflege werden.

Die konkrete technische Abhängigkeit lässt sich anhand der Microsoft-Dokumentation zu Dynamics 365 Business Central Online nachvollziehen. Microsoft verlangt, dass individuelle Erweiterungen mit neuen Versionen der Basisanwendung kompatibel sind. Inkompatible Erweiterungen können dazu führen, dass ein geplantes Update nicht auf die betroffene Umgebung angewendet werden kann.

Die Microsoft-Dokumentation zum Update-Lebenszyklus von Business-Central-Erweiterungen zeigt damit einen konkreten produktspezifischen Mechanismus. Sie belegt nicht, dass jede individuelle ERP-Anpassung grundsätzlich problematisch ist oder bei allen Herstellern dieselben technischen Regeln gelten.

Für die Entscheidung über eine Entwicklung hilft eine einfache Unterscheidung:

Eine individuelle Entwicklung sollte insbesondere dann gerechtfertigt werden, wenn sie einen wettbewerbskritischen Prozess unterstützt, keine akzeptable Standardalternative existiert und der langfristige Nutzen dokumentiert ist.

Weniger überzeugend sind Sonderwünsche, die lediglich die Optik eines Reports verändern, persönliche Gewohnheiten aus dem Altsystem nachbilden oder nur in einem seltenen Einzelfall benötigt werden.

Die Bewertung muss über mehrere Updatezyklen erfolgen. Dazu gehören Entwicklungsaufwand, laufende Wartung, Kompatibilitätstests und mögliche Anpassungen bei neuen Softwareversionen. Eine kurzfristig günstige Entwicklung kann über den gesamten Nutzungszeitraum deutlich aufwendiger werden.

Ein praktisches Kontrollinstrument ist ein Customizing-Register. Darin werden jede individuelle Änderung, ihre fachliche Begründung, die zuständige Person, die Freigabe und die Anforderungen an spätere Updates festgehalten. Dieses Register ist eine sinnvolle Projektmanagementmassnahme, keine allgemeine gesetzliche oder herstellerspezifische Pflicht.

Auch vertraglich muss das Thema sauber geregelt werden. Wenn ein Anbieter eine bestimmte Anforderung vor Vertragsabschluss als umsetzbar bezeichnet, sollten Aufwand, Leistungsumfang, Abnahmekriterien und Updatefähigkeit schriftlich festgehalten werden.

Ein unverbindliches Versprechen wie «Das können wir später problemlos ergänzen» ist keine ausreichende Grundlage für eine Investitionsentscheidung.

Je weniger unnötige Sonderentwicklungen das ERP-Projekt erzeugt, desto einfacher lassen sich spätere Module und Standorte integrieren. Damit wird auch die Reihenfolge der Einführung zu einem wichtigen Erfolgsfaktor.

In welcher Reihenfolge führen Sie ERP-Module ein, damit nach 100 Tagen Nutzen sichtbar ist?

ERP-Module sollten nicht gleichzeitig eingeführt werden, sondern in einer Reihenfolge, die möglichst früh einen messbaren betrieblichen Nutzen erzeugt. Dafür eignet sich zunächst ein Modul mit hohem manuellem Aufwand, überschaubaren Schnittstellenabhängigkeiten und einer Datenbasis, auf der spätere Module aufbauen können. Die Marke von 100 Tagen ist dabei ein Orientierungsziel und keine allgemeine Einführungsgarantie.

Die tatsächliche Dauer hängt von mehreren Faktoren ab: Komplexität der Geschäftsprozesse, Qualität der vorhandenen Stammdaten, Umfang individueller Anpassungen und Verfügbarkeit interner Projektressourcen. Ein Unternehmen mit unvollständigen Kundendaten und zahlreichen Excel-Sonderprozessen benötigt andere Vorbereitungen als ein Betrieb mit klar dokumentierten Abläufen.

Eine sinnvolle Reihenfolge beginnt deshalb mit einer Priorisierung der Module nach drei Kriterien:

• Wie viel manueller Aufwand entfällt durch die Einführung?
• Wie unabhängig ist das Modul von anderen Systemen und noch offenen Entscheidungen?
• Welche Daten oder Prozessgrundlagen schafft es für spätere Module?

Häufig kann die Finanzbuchhaltung ein geeigneter Einstieg sein, wenn sie klar abgegrenzt ist und die Schweizer Buchhaltungsanforderungen zuverlässig erfüllt. Ebenso kann ein anderer Kernprozess Vorrang haben, wenn dort der grösste operative Aufwand entsteht und die Datenbasis ausreichend vorbereitet ist.

Entscheidend ist, dass nicht automatisch das umfangreichste Modul zuerst eingeführt wird. Ein anspruchsvolles Modul mit vielen Sonderanforderungen kann das gesamte Projekt blockieren. Werden gleichzeitig mehrere Module gestartet, entstehen zudem parallele Abhängigkeiten und zusätzliche Abstimmungsprobleme.

Ein gestaffeltes Vorgehen schafft dagegen klare Verantwortlichkeiten. Nach dem ersten Modul wird geprüft, ob die vereinbarten Prozesse stabil funktionieren. Erst dann beginnt die nächste Ausbaustufe.

Die Stabilität sollte anhand konkreter Kriterien beurteilt werden. Dazu gehören beispielsweise fehlerfreie Periodenabschlüsse über eine definierte Anzahl von Perioden, eine ausreichende aktive Nutzung durch die vorgesehenen Mitarbeitenden und die erfolgreiche Verarbeitung der wichtigsten Geschäftsfälle.

Auch die Datenmigration sollte nicht als einmaliger technischer Vorgang behandelt werden. Stammdaten müssen bereinigt, Verantwortlichkeiten festgelegt und Datenübertragungen kontrolliert werden. Andernfalls werden alte Inkonsistenzen in das neue ERP übernommen.

Ein realistischer Einführungsplan enthält deshalb für jedes Modul einen klaren Umfang, eine verantwortliche Person, einen geplanten Start und ein überprüfbares Stabilitätskriterium. Die nächsten Module werden erst freigegeben, wenn diese Kriterien erfüllt sind.

Das schafft eine bessere Grundlage für einen frühen Nutzen als ein Big-Bang-Ansatz, bei dem alle Bereiche gleichzeitig umgestellt werden und Fehler sich gegenseitig beeinflussen können.

Damit die Reihenfolge tatsächlich funktioniert, müssen die Anforderungen vor Projektbeginn zwischen den drei Bereichen abgestimmt werden. Genau dafür braucht es einen strukturierten Anforderungsprozess.

Wie führen Sie 3 Anforderungsworkshops durch, die zu klaren Muss-Kriterien führen?

Drei Anforderungsworkshops reichen für eine erste belastbare ERP-Auswahl aus, wenn sie konsequent zwischen Ist-Prozessen, Soll-Prozessen und überprüfbaren Muss-Kriterien unterscheiden. Entscheidend ist, dass nicht jede Abteilung ihre Wunschliste einbringt, sondern gemeinsam festgelegt wird, welche Anforderungen für den Geschäftsbetrieb unverzichtbar sind.

Die drei Workshops ergänzen die spätere Fit-Gap-Analyse. Während dort die Anforderungen mit den Möglichkeiten des konkreten ERP-Systems abgeglichen werden, schaffen die Anforderungsworkshops zunächst eine gemeinsame Grundlage für die Auswahl.

Workshop 1: Ist-Prozesse und Schmerzpunkte erfassen

Im ersten Workshop dokumentieren die Verantwortlichen der drei Unternehmensbereiche ihre heutigen Abläufe. Dabei geht es nicht darum, die bestehende Software zu beschreiben, sondern die tatsächliche Arbeit sichtbar zu machen.

Für jeden Prozess sollten die wichtigsten Eingaben, Bearbeitungsschritte, Verantwortlichkeiten, Datenübergaben und typischen Probleme festgehalten werden. Besonders relevant sind doppelte Dateneingaben, manuelle Excel-Übertragungen und fehlende Informationen zwischen Abteilungen.

Teilnehmen sollten die Personen, die die jeweiligen Abläufe tatsächlich verantworten oder täglich durchführen. Das Ergebnis ist eine dokumentierte Ist-Prozessübersicht mit den wichtigsten Schwachstellen.

Workshop 2: Soll-Prozesse und Priorisierung definieren

Im zweiten Workshop wird festgelegt, wie die Abläufe nach der ERP-Einführung funktionieren sollen. Dabei müssen die drei Bereiche gemeinsame Prozessregeln entwickeln, statt lediglich ihre bisherigen Einzelprozesse in ein neues System zu übertragen.

Die Anforderungen werden in drei Kategorien eingeordnet:

• Muss: Ohne diese Anforderung kann ein kritischer Geschäftsprozess nicht angemessen funktionieren.
• Soll: Die Funktion bringt einen relevanten Vorteil, ist aber nicht zwingend für den grundlegenden Betrieb erforderlich.
• Kann: Die Funktion ist wünschenswert, hat jedoch eine nachrangige Priorität.

Diese Priorisierung verhindert, dass persönliche Präferenzen als unverzichtbare Anforderungen behandelt werden. Für jedes Muss-Kriterium sollte eine verantwortliche Person benannt werden, die seine betriebliche Notwendigkeit begründen kann.

Workshop 3: Muss-Kriterien überprüfbar formulieren

Im dritten Workshop werden die priorisierten Anforderungen in konkrete Auswahlkriterien übersetzt. Allgemeine Aussagen wie «gutes Lagermanagement» sind nicht ausreichend. Eine Anforderung muss so formuliert werden, dass ein Anbieter ihre Erfüllung demonstrieren kann.

Ein geeigneteres Beispiel lautet: «Jede Warenbewegung muss bis zum zugehörigen Beleg nachvollziehbar sein.» Wo eine zeitliche Anforderung notwendig ist, muss der Betrieb den tatsächlich benötigten Zeitraum selbst festlegen, statt einen beliebigen Grenzwert zu übernehmen.

Jedes Muss-Kriterium sollte mindestens folgende Informationen enthalten:

• Beschreibung des benötigten Prozesses.
• Begründung der geschäftlichen Notwendigkeit.
• Verantwortliche Person für die Anforderung.
• Konkretes Prüfkriterium für die Anbieterbewertung.
• Zuordnung zum späteren Fit-Gap-Workshop.

Eine Anforderung darf nur dann als Muss gelten, wenn drei Bedingungen erfüllt sind: Der betreffende Prozess kann ohne sie nicht angemessen funktionieren, es existiert kein akzeptabler manueller Umweg und eine verantwortliche Person verteidigt die Notwendigkeit schriftlich.

Diese Regel hilft, den Anforderungskatalog überschaubar zu halten. Sie reduziert das Risiko, dass die spätere ERP-Auswahl durch zahlreiche Sonderwünsche dominiert wird.

Gerade bei drei zu integrierenden Bereichen ist die gemeinsame Priorisierung entscheidend. Vertrieb, Lager und Finanzen können unterschiedliche Interessen haben. Das ERP-System muss jedoch die Übergaben zwischen diesen Bereichen zuverlässig unterstützen.

Die drei Workshops liefern damit die Grundlage für eine Auswahl, bei der die Prozesspassung wichtiger ist als die Anzahl vorhandener Funktionen. Anschliessend kann jeder Anbieter anhand derselben Muss-Kriterien und Beispieldaten geprüft werden.

Der nächste praktische Schritt besteht darin, die drei Bereiche gemeinsam zu kartieren, die wichtigsten Muss-Kriterien schriftlich freizugeben und diese anschliessend in einer Fit-Gap-Demonstration mit konkreten Geschäftsfällen zu überprüfen. So wird aus der ERP-Evaluation eine nachvollziehbare Investitionsentscheidung statt eines reinen Softwarevergleichs.