Die Anforderungen an ein ERP-System richtig definieren: Warum eine Wunschliste gut ist, aber zu viele Köche den Brei verderben

Die Kunst der Anforderungserfassung für ein ERP-Software ist keine einfache Aufgabe. Es kann sogar der schwierigste Teil des gesamten Prozesses sein. Denn hier gilt es die Vorstellungen des Managements in Einklang mit den Wünschen der Abteilungen zu bringen.

Viele von uns kennen aus verschiedenen Projekten, wie schnell Diskussionen ausarten können, sobald viele Personen und Interessensgruppen in den Entscheidungsprozess mit eingebunden sind.

Top-to-Bottom vs. Bottom-to-Top Ansatz

Bei der Definition von Anforderungen an ein neues ERP-System gibt es unterschiedliche Ansätze: Den Top-to-Bottom vs. Bottom-to-Top Ansatz. Bei dem Top-To-Bottom Ansatz definiert das Management die Anforderungen und die Mitarbeiter*innen müssen mit dem zur Verfügung gestellten System arbeiten. Beim Bottom-to-Top Ansatz werden die Anforderungen aus den Wünschen der Mitarbeiter*innen aus den Abteilungen heraus ermittelt.

Der Top-to-Bottom Ansatz bietet den der Vorteil, dass weniger Personen in die Entscheidung eingebunden sind und der Prozess somit weniger komplex ist. Dadurch werden Zeit und Ressourcen eingespart und ein Projekt kann schneller und kostengünstiger realisiert werden. Ein Nachteil dieses Ansatzes ist, dass die Wünsche der Mitarbeiter*innen, die schlussendlich mit dem System arbeiten, nicht im ausreichenden Maße einfließen. Das kann zur Folge haben, dass sie sich übergangen fühlen, das Projekt unternehmensinterne Widerstände hervorruft und das eingeführte System auf wenig Akzeptanz stößt.

Bei dem Bottom-to-Top Ansatz stehen die Wünsche und Anforderungen der Mitarbeiter*innen im Mittelpunkt. Doch genau hier liegt auch die Herausforderungen. Erfahrungsgemäß nutzen die Mitarbeiter*innen die Gelegenheit bei der Einführung eines neuen Systems all Ihre Wünsche zu platzieren, denn Sie wissen, dass der nächstmögliche Zeitpunkt vielleicht erst in ein paar Jahren kommt. Mit der Folge, dass häufig eine riesige Wunschliste entsteht. Das Kosten/Nutzen Verhältnis steht dabei eher im Hintergrund. Zudem sind die wenigsten Mitarbeiter*innen im vollen Umfang im Bilde darüber, wie sich das Unternehmen in der Zukunft ausrichten möchte. Die Folge ist ein hoher administrativer Aufwand, um sicherzustellen, dass nur Anforderungen umgesetzt werden, die auch tatsächlich benötigt werden und wirtschaftlich sinnvoll sind.

Die Mischung macht’s

Vielleicht kennen Sie es aus Ihrem jetzigen System. Werden dort wirklich alle Individualentwicklungen genutzt? Oder Sie haben ein System, bei dem nur ein Bruchteil der für Sie kostspielig entwickelten Funktionen auch tatsächlich eingesetzt werden?

Stellen wir uns folgendes – nicht selten in der Praxis vorkommendes Szenario vor: Auf Wunsch Ihres Finanzbuchhaltungsleiters wird die bisherige, etwas veraltete (aber: aus seiner Sicht nicht zu ersetzende!) Buchhaltungssoftware mit Hilfe einer teuren Schnittstelle mit Ihrem operativen System verbunden? Hätten Sie gerne Ihrem Gefühl nachgegeben und sich für ein System mit integrierter Finanzbuchhaltung entschieden? Das hätte zwar zu einem anfänglichen Frust bei Ihrem Abteilungsleiter der Finanzbuchhaltung hervorgerufen, was verständlich ist. Denn eine Umgewöhnung von Bekanntem, kann besonders in der Adaptionsphase mit Schmerzen und Rückschlägen verbunden. Aber wäre es im Nachhinein vielleicht die günstigere und mit Blick auf die Zukunft bessere Lösung gewesen?

Auch wenn dies ein fiktives Beispiel ist, vielleicht haben Sie ähnliche Erfahrungen gemacht. Deswegen ist es wichtig, darauf zu achten, dass im Rahmen des Bottom-to-Top Ansatzes die Wunschliste auch kohärent mit den Anforderungen des Managements ist. Denn oftmals entstehen Wünsche aus dem bekannten Prozessdenken heraus. Die Frage, die sich aber unbedingt gestellt werden muss: Gehen die vorhandenen Prozesse weiterhin einher mit der geplanten Zukunftsausrichtung des Unternehmens einher?

Die richtigen Key-User benennen

Sie ahnen es bereits, weder ein reiner Top-to-Bottom Ansatz noch ein reiner Bottom-zu-Top Ansatz führt zu einem optimalen Ergebnis. Beide Ansätze haben Vorteile, die für die Entscheidung genutzt werden sollen, aber bergen auch Risiken, die es zu berücksichtigen sind. Wie geht man nun also vor? Um den großmöglichen Nutzen aus einem neuen System zu gewinnen, ist es zwingend notwendig die Anforderungen der Endnutzer zu berücksichtigen und damit die Weichen für einen möglichst reibungslosen Wechsel von alten zu neuem System zu gewährleisten und eine möglichst hohe Akzeptanz zu schaffen. Damit nicht zu viele Köche den Brei verderben und die Wunschliste möglichst strukturiert erstellt wird, ohne dass diese zu umfangreich wird, macht es Sinn, bestimmte Mitarbeiter*innen aus den Abteilungen, sogenannte Key-User, zu benennen. Diese Key-User haben die Aufgabe, sich einen Überblick über die Wünsche ihrer Abteilungen zu verschaffen und diese zu qualifizieren. Dabei ist es wichtig, dass Key-User sowohl gute Kenntnisse über die Abläufe der Abteilung haben, als auch die nötige Power und Motivation, mit in das Projekt eingebunden werden zu wollen. Zum Beispiel: Ein junger, neuer Mitarbeiter möchte sich besonders zu Beginn seiner Berufstätigkeit beweisen, ist voller Tatendrang und bringt eine Menge Motivation mit, kennt jedoch die Prozesse der Abteilung nicht so gut wie ein langjähriger Mitarbeiter. Die Abteilungsleiterin auf der anderen Seite, kennt die Prozesse gut. Allerdings ist die Gefahr groß, dass sie nebenher mit so vielen anderen Projekten beschäftigt sein muss, dass sie zunächst halbherziger an die Sache herangeht. Da die Auswahl der richtigen Beteiligten bereits an dieser Stelle enorm wichtig ist, unterstützt ein guter IT Partner Sie im Rahmen des Change-Managements bereits aktiv bei diesem Schritt.

Aus der Synergie zwischen dem unternehmensspezifischen Wissen von Management und Key-Usern sowie der Erfahrung des Beratungs- und Softwaredienstleisters, der genau weiß, wie dieses Wissen genutzt werden kann, kann schließlich ein Anforderungskatalog erstellt werden, der alle Interessen berücksichtigt.

Setzten Sie Prioritäten mit MoSCoW

Ist nun eine Anforderungskatalog erstellt, gilt es diese zu Priorisieren, um Laufzeit und Kosten eines Projektes in einen realistischen und umsetzbaren Rahmen zu rücken Zur Priorisierung gibt es unterschiedliche Ansätze. Einer dieser Ansätze, die wir gerne heranziehen, ist die MoSCoW-Methode. Sie unterteilt Ihre Anforderungen in die Kategorien „Must have“, „Should have“, „Could have“ und „Won’t have“:

Anforderungen, die mit Must have gekennzeichnet sind, sind unternehmenskritisch und entscheidend für den Projekterfolg. Wenn auch nur eine Must have-Anforderung nicht enthalten ist, sollte das Projekt als gescheitert betrachtet werden. Allerdings können Must-Have Anforderungen im Sinne einer agilen Projektmethodik herabgestuft werden, wenn zum Beispiel neue Anforderungen für wichtiger erachtet werden. Eine Waageanbindung zum Beispiel ist eine solche Anforderungen, die bei Ensorgungs- und Redcycling Unternehmen, die erfolgskritisch für ein Projekt ist und mit Must have gekennzeichnet wird.

Anforderungen, die als Should have eingeordnet sind, können zwar genauso wichtig sein wie Must have, sind aber oft nicht so zeitkritisch oder es gibt eine andere Möglichkeit, die Anforderung zu erfüllen. Sofern eine Should nicht ein Must beeinträchtigt, sollten diese Anforderungen mit umgesetzt werden. In der Praxis wird ein DMS System oft als Should Have eingeordnet. Dieses wird oft in einer zweiten Projektphase implementiert, um sich in der Kernphase auf das ERP System zu fokussieren.

Anforderungen, die als Could eingeordnet werden, sind wünschenswert, aber nicht notwendig und könnten die Benutzererfahrung oder die Kundenzufriedenheit für einen geringen Entwicklungsaufwand verbessern. Diese werden in der Regel einbezogen, wenn Zeit und Ressourcen dies erlauben. Ein Kundenportal ist zurzeit ein sehr gutes Beispiel für eine Could Have Anforderung.

Anforderungen, die mit Won’t have gekennzeichnet sind, wurden von den Interessengruppen als die am wenigsten kritischen, am wenigsten rückzahlungsrelevanten Punkte vereinbart oder waren zu diesem Zeitpunkt nicht angemessen. Infolgedessen werden Anforderungen mit der Kennzeichnung Won’t have nicht für das Projekt oder eine Implementierung danach eingeplant. Die Anforderungen werden entweder fallen gelassen oder für die Aufnahme in einen späteren Zeitplan neu überdacht. Wenn Sie zum Beispiel nur wenige, eigene Fahrzeuge haben, die Sie disponieren, wäre eine grafische Tourenplanung vielleicht eine Won’t have Anforderung.

Eine solche Priorisierung gibt einen Überblick und schafft ein Verständnis dafür, was wirklich gebraucht wird. Wenn dieses Bewusstsein geschaffen ist, fällt es leichter Entscheidungen zu treffen. Es ist auch möglich das Projekt zu staffeln, indem man etwa zum Livebetrieb alle Must-Have Anforderungen umgesetzt haben will und andere Anforderungen im laufenden Betrieb sukzessive implementiert.

Zusammengefasst:

Für die Einführung einer neuen Unternehmenssoftware ist es wichtig, früh die richtigen Mitarbeiter*innen im eigenen Unternehmen auszuwählen. Die Anforderungsanalyse sollte gemeinschaftlich mit einem spezialisierten IT-Dienstleister durchgeführt werden. Eine nachgelagerte Priorisierung ist wichtig für den zeitlichen und wirtschaftlichen Erfolg des Projektes.