Eckpunkte, die ein gutes ERP-Lastenheft ausmachenDNA für den Projekterfolg

Mit dem Lastenheft definieren Unternehmen die Erfolgsgrundlage ihres ERP-Projekts. Manche erstellen hierfür Dokumente von nur wenigen Seiten, andere Konvolute mit Hunderten von Fragen. Der ERP-Hersteller proALPHA verrät, worauf es wirklich bei einem Lastenheft ankommt.

Die Auswahl des richtigen ERP-Systems ist aktuell wichtiger für den Unternehmenserfolg denn je. Denn ERP-Systeme vereinen heute mehr als nur Warenwirtschaft und Finanzen. Sie sind das Rückgrat der unternehmensweiten Digitalisierung, denn sie steuern sämtliche unternehmenskritische Prozesse. Ein gutes Lastenheft ist dabei der erste entscheidende Baustein für den Projekterfolg. Darauf sollten Unternehmen bei der Erstellung unbedingt achten:

• Klare Ziele definieren und nennen: Ein Projekt, das nur versucht, den Status quo zu verbessern, bleibt hinter seinen Möglichkeiten zurück. Neben dem Beheben aktueller Schwächen müssen daher auch die Unternehmensziele für die kommenden Jahre in den Anforderungskatalog. Das Lastenheft sollte auch beschreiben, wohin sich der Markt und das Unternehmen entwickelt und welche aktuellen Trends für die zukünftige Unternehmensstrategie voraussichtlich eine Rolle spielen. Sieht sich ein Betrieb mehreren Szenarien oder widersprüchlichen Zielen gegenüber, müssen auch diese benannt werden. Nur so stellt ein Unternehmen sicher, dass das neue ERP die nötige Flexibilität mitbringt.
• Mitarbeiterinput: Vom „Wünsch Dir was!“ zu klaren Prioritäten. Die Befragung von Mitarbeitern, was sie sich von einem neuen System erhoffen, führt in der Regel zu umfassenden Wunschlisten. Unternehmen, die diese ungefiltert und unpriorisiert in ein Lastenheft übernehmen, riskieren, sich in einem Wust von Anforderungen zu verheddern. Wer die Wünsche der Mitarbeiter dagegen mit den strategischen und taktischen Prioritäten des Unternehmens abgleicht, läuft weniger Gefahr, sich zu verzetteln.
• Prozessketten durchleuchten: Manche Unternehmen neigen dazu, bei ihren größten Schmerzpunkten zu starten. Sprich: in den Abteilungen, die sich am häufigsten und lautesten beklagen. Die Gefahr dabei ist offensichtlich: Probleme werden nicht an der Wurzel angepackt. Und die neue Lösung vereinfacht zwar die Arbeit an einer Stelle, erschwert sie aber vielleicht an einer anderen. Daher ist es ratsam, am Beginn der Wertschöpfungskette zu starten und die Befragung der Abteilungen entlang der Prozesse durchzuführen. So gewinnt das Projektteam einen guten Gesamtüberblick über den Informationsfluss und die Abhängigkeiten.
• Informationsmenge: Viel hilft nicht immer viel. Diese Aussage ist nicht immer richtig. Denn wird die Dokumentation zum Sammelsurium der Selbstverständlichkeiten aufgebläht, ist niemandem geholfen. Standardfunktionalitäten, etwa aus der Finanzbuchhaltung, sollte das Lastenheft nur der Vollständigkeit halber stichpunktartig auflisten. Eine detaillierte Ausführung ist hier überflüssig. Gleichzeitig sollten ERP-Verantwortliche aber auch nicht zu viel voraussetzen: Sie können nicht erwarten, dass Anbieter den gleichen Kenntnisstand wie ein Firmeninsider mitbringen. Hier hilft am besten ein abschließender Test: Ein Review durch einen Mitarbeiter außerhalb des ERP-Projektteams oder einen externen Berater sichert Verständlichkeit und Klarheit.
• Statt Funktionen Anforderungen formulieren: Der Teufel steckt meist im Detail. Daher neigen Unternehmen dazu, bereits Ideen für die Umsetzung in einem Lastenheft zu präzisieren. Wer beschreibt, wie bestimmte Aufgaben zu erledigen sind, schießt jedoch über das Ziel hinaus. Schon deshalb, weil die neue Software Arbeitsschritte automatisieren kann, die heute noch manuell erledigt werden. Mitarbeitern der Fachabteilungen fehlt hier der Überblick über das technisch Machbare. Merke: Nicht Beschreibungen des „Wie“, sondern des „Was“ und „Warum“ gehören in ein Lastenheft.
• Vorsicht vor altem Wein in neuen Schläuchen: Viele Unternehmen formulieren ihre Anforderungen auf der Grundlage bestehender Prozesse. Dieses Vorgehen birgt ein großes Risiko. Denn oft werden im Zuge eines ERP-Projekts Abläufe neu definiert. Das führt oft zu neuen oder geänderten Anforderungen oder dazu, dass alte Anforderungen wegfallen. Prozesse, die bekanntermaßen zu langen Durchlaufzeiten oder Problemen führen, sollten daher zu Beginn untersucht und bereits idealtypisch formuliert werden. So ist von Anfang an klar: Dieser Teil des Projekts erfordert besondere Aufmerksamkeit.
• Blick über den Zaun: Neue und alte Schnittstellen: Natürlich darf eine Beschreibung der aktuellen IT-Infrastruktur nicht fehlen. Genauso wichtig ist aber auch, dem potenziellen Lösungsanbieter Informationen über die geplante Landschaft mitzugeben. Soll eine bestehende Software zur Qualitätssicherung weiterhin eingebunden werden? Welche Standorte gilt es neu anzubinden? Wo sollen in Zukunft Automatismen manuelle Dateneingaben ersetzen? Alle bisherigen und neuen Schnittstellen müssen zumindest schemenhaft skizziert und benannt werden.
• Beispielbelege sammeln: Hilfreich ist zudem, für sämtliche Belege, die die Abläufe aktuell begleiten, Beispiele zusammenzustellen. Dies liefert einen hervorragenden Überblick über diejenigen Daten, die zwischen den verschiedenen Stakeholdern manuell ausgetauscht werden. Sie bilden eine sehr gute Ausgangslage für die Dokumentation von Automatisierungspotenzialen.
• Kurz- und Langversion erstellen: Für ein erstes Screening potenzieller Anbieter genügt in der Regel ein kurzes Dokument mit den wesentlichen Anforderungen. Vier oder fünf Din A4-Seiten sind hier eine gute Richtschnur plus ein gekürzter Fragenkatalog. Anders in der Endphase der Anbieterauswahl: Sobald sich die Longlist der Anbieter zur Shortlist verdichtet, kommt die Langversion des Lastenhefts zum Zug. Denn die Hersteller, die zum Präsentationstermin eingeladen werden, sollten bereits ein möglichst umfassendes Bild aller Anforderungen erhalten. So können sie bereits während des Schaulaufens zeigen, wie sie Knackpunkte des Projekts angehen und lösen.

Ein gutes Lastenheft schreibt sich nicht über Nacht. Mehrere Wochen bis Monate sollte sich ein Projektteam dafür Zeit nehmen. Dies gilt insbesondere, wenn als Teil der ERP-Einführung auch Reorganisations- oder Change-Prozesse angestoßen werden. Dennoch muss sich jedes Unternehmen eine feste Deadline setzen, bis wann der Anforderungskatalog stehen soll. Dies erhöht die Projektdisziplin und hält trotz der langen Vorbereitungsphase alle Stakeholder „bei der Stange“. (rhh)

proALPHA