Viele ERP-Projekte scheitern nicht an der Software, sondern an ungeklärten Abläufen im Unternehmen. Eine saubere Prozessanalyse vor ERP Einführung trennt Gewohnheiten von Anforderungen und verhindert, dass ein Pflichtenheft alte Probleme digital festschreibt. Wer zu früh über Funktionen spricht, übernimmt oft blinde Flecken aus dem Tagesgeschäft direkt ins neue System.
Auf einen Blick
- Eine saubere Analyse vor der ERP-Auswahl klärt Abläufe, Rollen, Stammdaten und Ausnahmen, bevor Anforderungen in ein Lastenheft geschrieben werden.
- In unserer Projektpraxis dauert die fachliche Klärung vor der Systementscheidung oft wenige Wochen, spart später aber deutlich mehr Abstimmungs- und Korrekturaufwand.
- Ein Soll-Prozess ist kein Wunschzettel, sondern ein belastbares Zielbild mit klaren Verantwortlichkeiten, Schnittstellen und Regeln für Ausnahmen.
- Medienbrüche, doppelte Datenerfassung und unklare Freigaben sind meist keine Softwarefrage, sondern ein Organisationsproblem vor dem Projektstart.
Wenn intern von Prozessanalyse vor ERP Einführung gesprochen wird, ist oft nicht klar, ob damit eine grobe Prozesslandkarte, eine Detailaufnahme der Kernabläufe oder bereits ein Soll-Prozess gemeint ist. Genau diese Unschärfe kostet Zeit, weil Fachbereiche, IT und Geschäftsleitung mit verschiedenen Erwartungen in denselben Workshop gehen.
Woran erkennen Sie, dass Prozesse vor dem ERP noch nicht entscheidungsreif sind?
Entscheidungsreif sind Abläufe erst dann, wenn nicht nur der Normalfall beschrieben ist. Auch Ausnahmen, Freigaben, Schnittstellen und Verantwortlichkeiten müssen sichtbar sein.
Ein Warnsignal ist, wenn jede Abteilung ihren eigenen Ablauf als Standard betrachtet. Dann fehlt meist die gemeinsame Sicht auf den Ist-Prozess.
Ein weiteres Zeichen ist ein Lastenheft, das fast nur Funktionslisten enthält. Wenn dort kaum Aussagen zu Stammdaten, Rollen oder Medienbrüchen auftauchen, wird die spätere Auswahl unsauber.
Beim Elektronik-Auftragsfertiger im Kanton Zug, 55 Mitarbeitende, zeigt sich das oft zwischen Verkauf, AVOR, Einkauf und Produktion. Jeder Bereich arbeitet mit eigenen Listen, und niemand kann auf Anhieb sagen, welche Daten an welcher Stelle verbindlich sind.
In der IT-Abteilung einer Stadtverwaltung im Kanton Zürich, 12 Mitarbeitende, liegt das Problem anders. Dort sind Abläufe häufig durch Fachbereiche, politische Vorgaben und bestehende Fachapplikationen geprägt, sodass technische und organisatorische Zuständigkeiten ineinanderlaufen.
Wer an diesem Punkt externe Führung braucht, setzt oft auf Technisches Projektmanagement, damit Anforderungen, Termine und Entscheide nicht zwischen Sitzungen versanden.
Welche Abläufe wirklich ins Zielbild gehören
Ein Zielbild ist die fachliche Entscheidung, welche Prozesse künftig standardisiert, vereinfacht oder bewusst separat geführt werden. Es unterscheidet sich vom Ist-Prozess dadurch, dass nicht alles Bestehende übernommen wird.
Viele Teams dokumentieren zu viel Nebensächliches und zu wenig Kritisches. Entscheidend sind die Abläufe, die Daten erzeugen, Freigaben auslösen oder mehrere Bereiche verbinden.
Dazu gehören typischerweise Auftrag bis Rechnung, Beschaffung, Lagerbewegungen, Servicefälle, Genehmigungen und Auswertungen. Gerade dort entstehen Medienbrüche, wenn Excel, E-Mail und Fachsysteme parallel laufen.
Hilfreich ist eine einfache Prozesslandkarte mit Kernprozessen, Führungsprozessen und Unterstützungsprozessen. Sie schafft einen Rahmen, bevor einzelne Workshops in Details abtauchen.
Für Schweizer Organisationen lohnt sich auch der Blick auf Standards und Rollenbilder aus Verbänden wie der Schweizerischen Gesellschaft für Organisation und Management. Nicht als Schablone, aber als Referenz dafür, wie sauber Prozesse beschrieben und Verantwortlichkeiten getrennt werden können.
Wenn die interne Moderation fehlt, hilft Projektmanagement für Prozessoptimierung, damit aus vielen Einzelmeinungen ein belastbares Zielbild wird.
Prozessanalyse vor ERP Einführung: Rollen, Medienbrüche und Ausnahmen sichtbar machen
Die eigentliche Analyse beginnt nicht mit Softwaredemos, sondern mit Fragen zur Arbeitspraxis. Wer macht was, auf welcher Grundlage, mit welchen Daten und mit welchen Ausnahmen?
Ein sauberer Workshop endet deshalb nicht bei Swimlanes oder hübschen Prozessbildern. Er zeigt, wo ein Medienbruch entsteht, wer Entscheidungen trifft und welche Schnittstellen heute nur über Zuruf funktionieren.
Was in dieser Phase oft schiefläuft
- Der Normalfall wird dokumentiert, Ausnahmen fehlen. Später tauchen Sonderfälle in Tests oder im Betrieb auf und erzwingen Nacharbeit im Konzept.
- Stammdaten werden als IT-Thema behandelt. In Wahrheit sind sie eine Führungsfrage, weil Definitionen, Pflege und Freigaben geklärt werden müssen.
- Verantwortlichkeiten bleiben implizit. Ohne Verantwortungsmatrix wird im Projekt vieles diskutiert, aber wenig verbindlich entschieden.
- Schnittstellen werden zu spät geprüft. Dann zeigt sich erst nach der Auswahl, dass Umsysteme, Exporte oder Berechtigungen nicht zum Zielbild passen.
Erfahrungsgemäss entstehen aus solchen Lücken schnell Nacharbeiten im mittleren fünfstelligen bis tiefen sechsstelligen Bereich, je nach Umfang des Vorhabens. Häufiger noch sind Verzögerungen, Doppelaufwand und interne Konflikte, weil Fachbereiche ihre Sicht erst spät wiederfinden.
Nicht jede Organisation braucht dieselbe Tiefe. Aber jede Organisation braucht Klarheit darüber, welche Fragen vor der Auswahl beantwortet sein müssen und welche erst in der Umsetzung folgen.
Warum Fachbereiche und IT oft über Unterschiedliches sprechen
Fachbereiche sprechen über Arbeit, Ausnahmen und Verantwortung. IT spricht über Systeme, Datenstrukturen und Integrationen. Beides ist richtig, aber ohne Übersetzung reden beide Seiten oft aneinander vorbei.
Der Fachbereich sagt, ein Prozess sei kompliziert. Die IT hört, dass eine Maske fehlt. Tatsächlich liegt das Problem vielleicht bei unklaren Stammdaten oder einer fehlenden Freigabelogik.
Hier hilft es, Anforderungen nicht sofort als Funktionen zu formulieren. Besser ist die Reihenfolge: Ist-Prozess verstehen, Soll-Prozess definieren, Verantwortungsmatrix festlegen, dann erst Anforderungen für das Lastenheft ableiten.
In unserer Projektpraxis liegt der grösste Hebel oft nicht in zusätzlichen Features, sondern in der Reduktion unnötiger Varianten. Weniger Sonderwege bedeuten meist weniger Abstimmung, weniger Testaufwand und weniger spätere Diskussionen.
Wenn ein Vorhaben zusätzlich Beschaffungsfragen berührt, etwa in einer Verwaltung oder bei formalen Offerten, lohnt sich ein Blick auf ein öffentliches Ausschreibung Beispiel, damit fachliche Anforderungen und Vergabeschritte sauber getrennt bleiben.
Manchmal reicht schon eine nüchterne Moderation von zwei bis drei Workshops, damit aus Meinungen belastbare Entscheide werden.
Welche Ergebnisse vor dem Lastenheft vorliegen sollten
Vor dem Lastenheft braucht es keine perfekte Welt. Es braucht aber Ergebnisse, die tragfähig genug sind, um Systeme fair zu vergleichen.
Dazu gehören eine abgestimmte Prozesslandkarte, dokumentierte Kernabläufe, die wichtigsten Ausnahmen, eine erste Sicht auf Schnittstellen und klare Regeln für Stammdaten. Ebenso wichtig ist eine Verantwortungsmatrix, damit Entscheide nicht offen bleiben.
Ein gutes Lastenheft beschreibt nicht nur, was die Software können soll. Es zeigt auch, wie die Organisation künftig arbeiten will.
Wer bereits weiss, dass Microsoft Dynamics oder ein ähnliches Umfeld infrage kommt, sollte die Analyse trotzdem nicht überspringen. Auch eine Navision Einführung wird nur dann sauber, wenn Prozesse, Rollen und Daten vorher geklärt sind.
Aus unserer Sicht ist der richtige Detaillierungsgrad erreicht, wenn Anbieter den Kern des Vorhabens verstehen, Unterschiede im Lösungsansatz sichtbar werden und interne Entscheide nicht mehr auf Vermutungen beruhen.
Ein sauberer Vorlauf muss nicht schwerfällig sein. Er muss nur konsequent genug sein, damit aus Diskussionen belastbare Grundlagen werden.
Wenn Sie intern bereits mehrere Sichtweisen auf denselben Ablauf haben, ist das kein Sonderfall, sondern ein klares Signal für Moderationsbedarf. Genau dort trennt sich eine nützliche Analyse von einer blossen Dokumentationsübung.
Wenn Sie Ihre Ausgangslage vor der ERP-Auswahl sauber klären wollen, rufen Sie uns an unter +41 77 491 77 94 oder schreiben Sie an info@tprojects.ch. Das erste Gespräch ist unverbindlich und kostenlos, und wir können die nächsten sinnvollen Schritte gemeinsam einordnen.
Über den Autor
FAQ
Was gehört in eine Prozessanalyse vor ERP Einführung?
Dazu gehören die Beschreibung der Kernabläufe, die wichtigsten Ausnahmen, Rollen, Freigaben, Schnittstellen, Stammdaten und eine erste Sicht auf den künftigen Soll-Prozess. Für die methodische Struktur eignen sich bewährte Methoden zur Prozessanalyse.
Wann ist der richtige Zeitpunkt für die Prozessanalyse vor ERP Einführung?
Der richtige Zeitpunkt liegt vor der Systemauswahl und vor dem Schreiben des Lastenhefts. Wenn intern noch unklar ist, welche Abläufe standardisiert werden sollen oder wer welche Entscheidung trifft, lohnt sich oft ein neutrales IT Beratung kostenlos Erstgespräch.
Wie detailliert müssen Prozesse vor einer ERP-Auswahl dokumentiert sein?
Sie müssen so detailliert sein, dass Anbieter den Kernprozess, die Ausnahmen und die relevanten Datenflüsse verstehen. Für die spätere Planung von Etappen kann auch eine einfache Meilenstein Darstellung Projekt Excel hilfreich sein.
Wer sollte aus dem Unternehmen an der Analyse beteiligt sein?
Beteiligt sein sollten die Prozessverantwortlichen aus den betroffenen Fachbereichen, eine entscheidungsfähige Führungsperson, die IT und bei Bedarf Personen mit Blick auf Datenqualität und Integration. Wenn repetitive Arbeitsschritte bereits heute auffallen, gehört auch die Frage nach Automatisierung von Prozessen früh auf den Tisch.
Was ist der Unterschied zwischen Ist-Prozess, Soll-Prozess und Zielbild?
Der Ist-Prozess beschreibt die heutige Arbeitsweise, inklusive Umwege und Ausnahmen. Der Soll-Prozess beschreibt den künftig gewünschten Ablauf, während das Zielbild den grösseren Rahmen mit Rollen, Systemgrenzen und Prioritäten festlegt; bei serviceorientierten Abläufen kann auch Kundenbetreuung Chatbot Teil dieses Zielbilds sein.