Welche Unternehmenssoftware passt, wenn 4 Abteilungen unterschiedliche Anforderungen haben?

Der Vertrieb möchte schneller Angebote erstellen, die Finanzabteilung verlangt nachvollziehbare Buchungen, die Logistik benötigt aktuelle Bestände und die Produktion will verlässliche Planungsdaten. Alle vier Abteilungen suchen eine neue Unternehmenssoftware. Doch ihre Anforderungen scheinen kaum miteinander vereinbar.

Die entscheidende Frage lautet nicht, welches System die meisten Funktionen besitzt. Viel wichtiger ist, welche Geschäftsprozesse die Software zuverlässig unterstützen und welche Übergaben zwischen den Abteilungen funktionieren müssen. Erst daraus entstehen nachvollziehbare Auswahlkriterien.

Eine geeignete Softwareauswahl beginnt deshalb mit der Dokumentation weniger zentraler Abläufe. Anschliessend werden Anforderungen priorisiert, Anbieter anhand identischer Geschäftsszenarien bewertet und verbleibende Lücken bewusst entschieden. Dieses Vorgehen lässt sich sowohl auf eine kleinere Softwareeinführung als auch auf ein umfangreiches ERP-Projekt übertragen.

Für Unternehmen in der Schweiz kommen lokale Rahmenbedingungen hinzu, insbesondere Datenschutz, Mehrwertsteuer und die Einbindung bestehender Fachsysteme. Sie sollten von Beginn an als konkrete Prüfanforderungen berücksichtigt werden, statt erst während der Einführung aufzufallen.

Warum die „Top-10-Features“-Liste fast immer zur falschen Software führt

Eine Feature-Liste zeigt, welche Funktionen eine Software anbietet, aber nicht, ob sie die tatsächlichen Geschäftsabläufe unterstützt. Zwei Systeme können dieselben Funktionen besitzen und sich bei Freigaben, Datenübergaben oder Ausnahmen grundlegend unterscheiden. Deshalb sollte jede wichtige Anforderung auf einen dokumentierten Prozessschritt zurückgeführt werden können.

Angenommen, der Vertrieb erfasst einen Auftrag, die Logistik prüft dessen Lieferbarkeit, die Produktion bestätigt einen Termin und die Finanzabteilung verarbeitet anschliessend die Rechnungsdaten. Eine Funktionsliste könnte dazu lediglich Kundenverwaltung, Lagerverwaltung, Produktionsplanung und Rechnungsstellung verlangen.

Diese Begriffe sagen jedoch wenig darüber aus, ob eine Auftragsänderung zuverlässig durch alle vier Abteilungen gelangt. Entscheidend sind konkrete Fragen: Wer darf den Liefertermin ändern? Wann erhält die Produktion die aktualisierte Information? Welche Daten benötigt die Finanzabteilung, um eine korrekte Rechnung auszustellen?

Die GOV.UK-Anleitung zur Analyse vollständiger Prozessabläufe empfiehlt, beteiligte Organisationseinheiten, Hintergrundprozesse und Übergaben gemeinsam zu betrachten. Diese ursprünglich für öffentliche Dienstleistungen entwickelte Methodik lässt sich auf die Untersuchung abteilungsübergreifender Unternehmensprozesse übertragen.

Ein Prozessschritt erzeugt eine überprüfbare Anforderung. Beispielsweise: Nach Freigabe eines Kundenauftrags muss der bestätigte Liefertermin für die zuständige Produktionsplanung verfügbar sein. Dieser Ablauf lässt sich mit Testdaten nachstellen und bewerten. Dagegen ist die Forderung nach einem «modernen Planungsdashboard» zunächst nur eine Präferenz.

Auch wirtschaftlich macht diese Unterscheidung einen Unterschied. Zusätzliche Funktionen können Lizenzkosten, Konfiguration, Schulung und Pflege erhöhen. Das gilt allerdings nicht automatisch für jede Funktion: Viele Softwarepakete enthalten ohnehin einen festen Leistungsumfang. Kostenrelevant wird ein Wunsch insbesondere dann, wenn zusätzliche Module, Anpassungen oder betriebliche Komplexität entstehen.

Ein einfacher Test entlarvt unklare Anforderungen: Welcher konkrete Prozessschritt benötigt diese Funktion, und wer führt ihn aus? Kann niemand eine nachvollziehbare Antwort geben, sollte die Funktion nicht unmittelbar als Muss-Kriterium gelten.

Sobald die relevanten Abläufe feststehen, lassen sich unterschiedliche Abteilungswünsche in gemeinsame, prüfbare Anforderungen übersetzen. Dafür braucht es einen strukturierten Austausch.

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

Drei aufeinander aufbauende Workshops schaffen eine praktikable Grundlage für die Softwareauswahl: Zuerst werden bestehende Abläufe dokumentiert, danach Anforderungen priorisiert und schliesslich Konflikte zwischen den Abteilungen entschieden. Wichtig ist, dass jede Anforderung einem Prozessschritt zugeordnet wird und ein überprüfbares Ergebnis beschreibt. Drei Workshops sind ein Organisationsvorschlag, keine vorgeschriebene Anzahl.

Die drei Termine sollten unterschiedliche Entscheidungen vorbereiten, damit nicht jede Sitzung erneut zur offenen Wunschsammlung wird.

Im ersten Workshop beschreiben die Fachbereiche möglichst reale Geschäftsvorgänge. Der Vertrieb könnte beispielsweise erklären: «Wir brauchen eine bessere Übergabe an die Buchhaltung.» Die Moderation muss diesen Wunsch konkretisieren. Welches Ereignis löst die Übergabe aus? Welche Informationen werden weitergegeben? Wer ist verantwortlich, und wann ist die Übergabe abgeschlossen?

Im zweiten Workshop werden daraus messbare Anforderungen formuliert. Eine mögliche Definition lautet: Der freigegebene Auftrag muss die für die Rechnungsstellung benötigten Daten vollständig und nachvollziehbar bereitstellen.

Für die Priorisierung eignet sich folgende Arbeitsdefinition:

• Muss: Ohne diese Anforderung kann ein unverzichtbarer Prozess nicht ausreichend funktionieren oder eine einschlägige rechtliche beziehungsweise verbindliche Schutzpflicht nicht eingehalten werden.
• Soll: Die Anforderung bietet einen wesentlichen betrieblichen Nutzen, ihre Nichterfüllung lässt jedoch einen vertretbaren Ausweichweg zu.
• Kann: Die Funktion ist wünschenswert, aber für den vorgesehenen Betrieb nicht entscheidend.

Gerade bei cloudbasierter Unternehmenssoftware in der Schweiz müssen Datenschutzanforderungen konkret geprüft werden. Die EDÖB-Informationen zur Auftragsdatenbearbeitung erläutern, dass ein Verantwortlicher auch bei der Auslagerung der Bearbeitung von Personendaten für den Datenschutz verantwortlich bleibt. Dazu gehören unter anderem die sorgfältige Auswahl des Auftragsbearbeiters und angemessene Datensicherheitsmassnahmen.

Im dritten Workshop werden widersprüchliche Wünsche entschieden. Verlangt beispielsweise die Finanzabteilung eine verpflichtende Kontrolle, während der Vertrieb auf eine möglichst schnelle Auftragsfreigabe besteht, muss der gemeinsame Prozess festlegen, wann die Kontrolle erforderlich ist und welche Schritte automatisiert werden können.

Jede Sitzung sollte mit einer verbindlichen Entscheidungsliste enden. Offene Punkte erhalten eine verantwortliche Person und einen Klärungsbedarf. Ein Kriterium ohne erkennbaren Prozessbezug wird zur Überarbeitung zurückgegeben.

Mit dieser Grundlage lässt sich entscheiden, welche Form der Anbieterprüfung zur Grösse und zum Risiko des Vorhabens passt.

Ausschreibung oder Pilot: Was ist besser bei 2.000 Nutzern vs 50 Nutzern?

Bei 2.000 vorgesehenen Nutzern ist eine strukturierte Ausschreibung häufig sinnvoll, weil Integrationsaufwand, Einführung, Schulung und Vertragsrisiken systematisch geprüft werden müssen. Bei 50 Nutzern kann ein begrenzter Pilot schneller zeigen, ob die Software im Arbeitsalltag funktioniert. Die Nutzerzahl allein entscheidet jedoch nicht: Prozesskritikalität, Datenrisiken und technische Abhängigkeiten sind ebenso wichtig.

Eine Ausschreibung ermöglicht es, Anbieter nach denselben Anforderungen zu vergleichen. Sie macht Leistungsumfang, Einführungskonzept, Betriebsmodell und Kostenstruktur besser nachvollziehbar. Ein Pilot dagegen überprüft tatsächliche Arbeitsabläufe mit ausgewählten Anwendern und möglichst realistischen Testdaten.

Für grosse Projekte muss die Ausschreibung daher mehr als eine Funktionsbewertung enthalten. Gefragt sind beispielsweise ein belastbares Migrationskonzept, Zuständigkeiten für Schnittstellen, ein Roll-out-Ansatz und nachvollziehbare Leistungen des Implementierungspartners.

Die offizielle britische Beschaffungsanleitung für digitale Dienstleistungen beschreibt eine strukturierte Vorbereitung mit dokumentierten Anforderungen und Bewertungskriterien. Sie unterscheidet wesentliche von wünschenswerten Kriterien und betont transparente Anbieterbewertungen. Diese Grundsätze sind methodisch übertragbar; die britischen Vergaberegeln gelten dadurch nicht automatisch für Schweizer Unternehmen.

Auch ein kleiner Pilot braucht einen klaren Prüfauftrag. Das Team sollte nicht bloss Funktionen ausprobieren, sondern definierte Geschäftsvorfälle vollständig bearbeiten: vom Auslöser über die Freigabe bis zur Übergabe an das nächste System.

Eine sinnvolle Zwischenlösung kann eine kurze Vorauswahl von zwei oder drei Anbietern mit anschliessendem, gegebenenfalls bezahltem Pilot sein. Voraussetzung sind identische Bewertungskriterien, eine begrenzte Testdauer sowie dokumentierte Abnahme- und Abbruchbedingungen.

Bei besonders sensiblen Daten oder komplexen Integrationen kann selbst ein Projekt mit 50 Nutzern eine formale Sicherheits- und Architekturprüfung benötigen. Umgekehrt kann auch eine grosse Ausschreibung durch einen gezielten Praxistest ergänzt werden.

Welche Prüfmethode auch gewählt wird: Ihre Ergebnisse bleiben nur belastbar, wenn die richtigen Personen Einfluss auf die Entscheidung erhalten.

Der Stakeholder-Fehler, der Softwareauswahl zur Machtfrage macht

Softwareauswahl wird zur Machtfrage, wenn Abteilungen über ihre bevorzugten Funktionen abstimmen, ohne die jeweilige Prozessverantwortung zu berücksichtigen. Dann entscheiden Hierarchie, Durchsetzungsvermögen oder persönliche Vorlieben über die Prioritäten. Besser ist ein Rollenmodell, das fachlichen Einfluss an dokumentierte Aufgaben, Abhängigkeiten und die Verantwortung für die spätere Nutzung bindet.

Eine Fachbereichsleitung kann strategisch wichtig sein, ohne die tägliche Verarbeitung einzelner Geschäftsvorfälle genau zu kennen. Umgekehrt verfügen Mitarbeitende, die Aufträge erfassen, Rechnungen prüfen oder Produktionsdaten pflegen, häufig über entscheidendes Wissen zu Ausnahmen und Fehlerquellen.

Die Auswahlorganisation sollte daher mehrere Verantwortlichkeiten unterscheiden:

• Prozessverantwortliche definieren fachliche Anforderungen und beurteilen, ob die vorgesehenen Abläufe tragfähig sind.
• Schlüsselanwender prüfen praktische Arbeitsweisen, Ausnahmen und Bedienbarkeit.
• IT-Verantwortliche bewerten Architektur, Schnittstellen, Betrieb und technische Risiken.
• Datenschutz- und weitere zuständige Kontrollfunktionen prüfen Anforderungen ihres jeweiligen Verantwortungsbereichs.
• Geschäftsführung oder Projektsteuerung entscheidet über Budget, Prioritäten und ausdrücklich dokumentierte Zielkonflikte.

In einem praktikablen Governance-Modell erhalten Fachverantwortliche Entscheidungskompetenz für ihre Prozessdomäne. Bei bereichsübergreifenden Konflikten greift ein zuvor festgelegter Eskalationsweg. Dieses Modell ist eine mögliche Organisationsentscheidung, keine allgemein verbindliche Vorschrift.

Wichtig bleibt die Unterscheidung zwischen Beratung und Entscheidung. Eine Person, die keinen Prozessschritt verantwortet, aber von einer neuen Lösung betroffen ist, muss gegebenenfalls angehört werden. Sie benötigt deswegen nicht automatisch eine gleichgewichtete Stimme bei jeder Detailentscheidung.

Wer Schlüsselanwender übergeht, riskiert eine formal passende, aber schlecht akzeptierte Lösung. Verdeckte Umgehungen über Excel-Listen und informelle Abstimmungen können dann bestehen bleiben, obwohl die neue Software technisch funktioniert.

Vor jeder Auswahlsitzung sollte deshalb klar sein, wer welchen Prozess vertritt, wer technische oder rechtliche Risiken bewertet und wer den abschliessenden Beschluss trifft.

Mit geklärten Rollen können die Beteiligten ihre Ergebnisse in wenigen gemeinsam genutzten Unterlagen festhalten, statt dieselben Diskussionen mehrfach zu führen.

Welche 4 Artefakte beschleunigen die Auswahl, ohne Risiko zu erhöhen?

Vier Unterlagen reichen für viele überschaubare Softwareauswahlprojekte als gemeinsame Arbeitsgrundlage aus: ein priorisierter Anforderungskatalog, dokumentierte Kernprozesse, eine Fit-Gap-Matrix und ein kompaktes Entscheidungsdossier. Sie erfüllen unterschiedliche Zwecke und sollten konsequent wiederverwendet werden. Zusätzliche Dokumentation ist nur sinnvoll, wenn sie eine konkrete Prüfung oder Entscheidung unterstützt.

Das Ziel besteht nicht darin, möglichst viele Unterlagen zu produzieren. Entscheidend ist eine nachvollziehbare Verbindung vom Geschäftsprozess über die Anforderung zur Anbieterbewertung und schliesslich zur Auswahlentscheidung.

Ein besonders wichtiger Zusammenhang ist die eindeutige Kennzeichnung von Anforderungen. Beispielsweise kann eine Anforderung mit einer internen Referenz versehen werden, die im Prozessdokument, in der Anbieterbewertung und im Entscheidungsdossier wieder auftaucht.

So lässt sich Monate später nachvollziehen, warum eine bestimmte Funktion gefordert, abgelehnt oder als kostenpflichtige Erweiterung akzeptiert wurde. Das ist besonders hilfreich, wenn Projektmitglieder wechseln oder während der Einführung neue Wünsche entstehen.

Das Entscheidungsdossier sollte auf einer Seite die bevorzugte Lösung, ihre entscheidenden Vorteile, die verbleibenden Einschränkungen und den erforderlichen Beschluss darstellen. Technische Nachweise können als Anlagen hinterlegt werden.

Ein häufiger Fehler besteht darin, den Anforderungskatalog immer weiter auszubauen. Sobald einzelne Kriterien nicht mehr geprüft oder zur Entscheidung verwendet werden, sinkt der Nutzen zusätzlicher Detailtiefe.

Eine praktische Qualitätsfrage lautet deshalb: Welche konkrete Entscheidung würde schlechter ausfallen, wenn dieses Dokument oder diese Information fehlte?

Der wichtigste Ausgangspunkt dieser Unterlagen bleibt eine verständliche Prozessbeschreibung. Sie muss weder umfangreich noch methodisch kompliziert sein.

Wie dokumentieren Sie 1 Kernprozess in 90 Minuten, ohne dass es akademisch wird?

Ein Kernprozess lässt sich in einem 90-minütigen Workshop als erste prüfbare Arbeitsgrundlage dokumentieren: 15 Minuten für Start und Ergebnis, 45 Minuten für Schritte und Verantwortliche, 15 Minuten für Ausnahmen und Schnittstellen sowie 15 Minuten für die Überprüfung. Eine einfache Tabelle genügt häufig. Die Zeitangabe ist ein praktischer Richtwert, keine Garantie vollständiger Prozessanalyse.

Entscheidend ist die Vorbereitung. Ein Prozessverantwortlicher sollte einen typischen Geschäftsvorfall auswählen und diejenigen Personen einladen, die den Ablauf tatsächlich ausführen oder wichtige Übergaben übernehmen.

Der Workshop folgt einer festen Struktur:

1. Minute 0–15: Ausgangspunkt, auslösendes Ereignis, Prozessende und erwartetes Ergebnis festlegen.
2. Minute 15–60: Arbeitsschritte, Verantwortliche, verwendete Systeme und Übergaben in ihrer tatsächlichen Reihenfolge erfassen.
3. Minute 60–75: Relevante Ausnahmen, Medienbrüche, manuelle Kontrollen und Schnittstellen ergänzen.
4. Minute 75–90: Den dokumentierten Ablauf gemeinsam überprüfen und offene Fragen einer verantwortlichen Person zuordnen.

Die Dokumentation sollte für Personen verständlich sein, die nicht am Workshop teilgenommen haben. Dafür eignet sich häufig eine Tabelle besser als eine komplexe Modellierungsnotation.

Dieses Beispiel ist ein hypothetischer Prozess. Die tatsächliche Reihenfolge und die Zuständigkeiten müssen im jeweiligen Unternehmen geprüft werden.

Auf dieser Detailebene sind vor allem die Übergaben wichtig. Jede Übergabe wirft Fragen nach Datenvollständigkeit, Aktualität, Zuständigkeit und Kontrolle auf. Genau daraus lassen sich später Testfälle für eine Software ableiten.

Nicht jeder Mausklick und jede seltene Ausnahme gehört in die erste Fassung. Werden beispielsweise Spezialfälle mit erheblicher steuerlicher oder technischer Bedeutung sichtbar, sollten sie dokumentiert und für eine gesonderte Prüfung markiert werden.

Die verbleibenden Unklarheiten sind kein Grund, den gesamten Workshop zu wiederholen. Sie können mit konkreter Fragestellung nachbearbeitet werden.

Ob ein Anbieter diese Szenarien tatsächlich erfüllt, zeigt anschliessend eine systematische Fit-Gap-Analyse.

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

Eine Fit-Gap-Analyse kann bei drei zentralen Fachbereichen in fünf Workshops organisiert werden: drei Sitzungen zur fachlichen Prüfung, eine zur Konsolidierung und eine zur Entscheidung. Jede Anforderung erhält den Status erfüllt, erfüllt mit Aufwand oder nicht erfüllt. Offene Abweichungen werden mit Kosten, Risiken und einem konkreten Beschluss dokumentiert.

Statt Workshops nach Softwaremodulen wie Stammdaten, Reporting und Workflow aufzuteilen, ist eine Gliederung entlang der tatsächlichen Geschäftsbereiche häufig verständlicher. Ein mögliches Modell für Vertrieb, Einkauf und Finanzen sieht so aus:

1. Vertriebsworkshop: Auftragserfassung, Freigaben, Kundeninformationen und Übergaben.
2. Einkaufsworkshop: Bedarfsmeldung, Bestellung, Wareneingang und Lieferanteninformationen.
3. Finanzworkshop: Buchungen, Rechnungsprüfung, Abstimmung und Auswertungen.
4. Konsolidierungsworkshop: bereichsübergreifende Konflikte, Schnittstellen und verbleibende Lücken.
5. Entscheidungsworkshop: Auswirkungen, Kosten, Risiken und verbindliche Massnahmen festlegen.

Die fünf Sitzungen bilden ein schlankes Vorgehensmodell für drei Fachbereiche. Bei vier eigenständigen Abteilungen kann ein zusätzlicher Fachworkshop erforderlich sein; alternativ lassen sich eng verbundene Prozesse gemeinsam untersuchen.

Für jede Anforderung wird eine gemeinsame Bewertungsskala genutzt:

Bei einem nur teilweise erfüllten Kriterium muss die Bewertung präzise sein. Ist die Lücke durch Standardkonfiguration lösbar? Wird eine Schnittstelle benötigt? Ist eine Individualentwicklung vorgesehen? Welche Auswirkungen sind bei Updates zu erwarten?

Für Anpassungen sollten geschätzte Aufwandstage und, soweit ermittelbar, zusätzliche Lizenz-, Wartungs- und Betriebskosten erfasst werden. Unbekannte Kosten bleiben als offene Position sichtbar, statt stillschweigend mit null angesetzt zu werden.

Besonders problematisch ist die Aussage: «Daran werden sich die Mitarbeitenden schon gewöhnen.» Sie ersetzt keine fachliche Entscheidung. Für jeden wesentlichen Gap braucht es eine konkrete Behandlung: Prozess ändern, Software anpassen oder Anbieter ausschliessen beziehungsweise wechseln.

Eine interne Durchführung ist vor allem bei Standardsoftware mit überschaubarem Anpassungsbedarf realistisch. Bei komplexen Integrationen, umfangreichen Individualentwicklungen oder anspruchsvollen Sicherheitsanforderungen kann eine gezielte externe Fachprüfung sinnvoll sein.

Eine solche Prüfung muss nicht die gesamte Auswahl ersetzen. Häufig reicht es, kritische technische Annahmen und Kostenschätzungen unabhängig beurteilen zu lassen.

Damit sind die Voraussetzungen geschaffen, die eigentliche ERP-Frage zu beantworten: Welche Systemarchitektur kann mehrere Bereiche zuverlässig verbinden und die heutigen Excel-Übergaben ersetzen?

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

Ein geeignetes ERP-System verbindet die wesentlichen Abläufe der drei beteiligten Bereiche, gewährleistet verlässliche Datenübergaben und erfüllt die dokumentierten Muss-Kriterien. Dafür kann ein konfigurierbares Standard-ERP ausreichen. Auch eine Kombination aus ERP und angebundenen Fachsystemen ist möglich, sofern Schnittstellen, Verantwortlichkeiten und Betriebskosten nachweislich beherrschbar sind.

Die Entscheidung beginnt nicht mit einer Herstellerliste, sondern mit dem tatsächlichen Integrationsbedarf. Ein Unternehmen, das Vertrieb, Logistik und Finanzbuchhaltung zusammenführen möchte, hat andere Anforderungen als ein Betrieb, der Einkauf, Produktion und Lagerwirtschaft integrieren muss.

Im Mittelpunkt stehen deshalb drei Fragen: Welche Daten entstehen in welchem Bereich? Welche anderen Bereiche benötigen diese Informationen? Und wer bleibt für ihre Korrektheit verantwortlich?

Excel ist dabei nicht grundsätzlich ungeeignet. Tabellen bleiben für Analysen, einmalige Auswertungen oder individuelle Berechnungen nützlich. Problematisch werden sie, wenn mehrere Abteilungen dieselben geschäftskritischen Daten unabhängig pflegen und die Übergabe ausschliesslich von manuellem Kopieren, Dateiversionen oder persönlichen Absprachen abhängt.

Ein ERP muss nicht zwingend alle drei Abteilungen vollständig in einer einzigen Anwendung abbilden. Wenn eine spezialisierte Produktionssoftware erhalten bleiben soll, kann eine zuverlässig integrierte Lösung wirtschaftlicher und fachlich geeigneter sein als ihre vollständige Ablösung.

Entscheidend ist, ob die Verbindung im Alltag funktioniert: Werden Änderungen übertragen? Lassen sich Fehler erkennen? Gibt es eine eindeutige Datenquelle? Können Berechtigungen und Protokollierung angemessen umgesetzt werden?

Für Schweizer Unternehmen kommt die lokale Eignung hinzu. Besonders bei Buchhaltungs- und ERP-Lösungen sollten die anwendbaren Mehrwertsteueranforderungen geprüft werden.

Die Mehrwertsteuerinformationen der Eidgenössischen Steuerverwaltung nennen für die Schweiz seit dem 1. Januar 2024 einen Normalsatz von 8,1 Prozent 1. Januar 2024 sowie die Pflicht zur elektronischen MWST-Abrechnung seit dem 1. Januar 2025. Daraus folgt nicht, dass jede ERP-Lösung zwingend über eine direkte Schnittstelle zur ESTV verfügen muss. Entscheidend ist, ob die gesetzlich erforderlichen Abrechnungsprozesse korrekt unterstützt werden.

Ist die Lohnbuchhaltung betroffen, müssen zusätzlich die einschlägigen Schweizer Anforderungen an die Lohnverarbeitung und die vorhandenen Abrechnungssysteme berücksichtigt werden. Je nach Branche können spezifische Prozessanforderungen entstehen, etwa im Handwerk oder Detailhandel.

Auch die Verfügbarkeit kompetenter Einführungspartner verdient eine eigene Bewertung. Ein funktional geeignetes System kann erhebliche Einführungsrisiken aufweisen, wenn Migration, Integration, Support oder notwendige Anpassungen nicht ausreichend abgesichert sind. Die geografische Nähe allein garantiert allerdings keine bessere Umsetzung.

Aus der Analyse ergeben sich drei grundsätzliche Lösungswege:

• Standard-ERP mit Konfiguration: sinnvoll, wenn die wesentlichen Prozesse weitgehend durch vorhandene Funktionen abgedeckt werden.
• ERP mit integrierten Fachsystemen: geeignet, wenn einzelne spezialisierte Lösungen erhalten bleiben sollen und die Schnittstellen ausreichend zuverlässig sind.
• Stärker individualisierte Lösung: nur dann näher prüfen, wenn geschäftskritische Anforderungen mit Standardsoftware und angemessenen Prozessanpassungen nicht tragfähig erfüllt werden können.

Die wirtschaftliche Bewertung sollte neben der Erstinvestition auch wiederkehrende Kosten und absehbare Veränderungen umfassen: Lizenzen, Implementierung, Datenmigration, Schulung, Schnittstellenbetrieb, Anpassungspflege sowie die Möglichkeit, Daten später wieder aus dem System zu übernehmen.

Am Ende gewinnt nicht automatisch der Anbieter mit den meisten erfüllten Einzelanforderungen. Ausschlaggebend sind die verlässlich abgedeckten Muss-Kriterien, die vertretbaren Gesamtkosten und die bewusst akzeptierten Einschränkungen.

Als nächster Schritt empfiehlt sich, einen bereichsübergreifenden Kernprozess auszuwählen, seine Übergaben zu dokumentieren und daraus wenige prüfbare Muss-Kriterien abzuleiten. Mit dieser Grundlage lässt sich die passende ERP-Systemklasse bestimmen und eine zielgerichtete Anbieterauswahl beginnen.