ERP-Auswahl mal anders (Auswahl auf Basis eines prozessorientierten Lastenhefts)

Die Idee zu diesem Beitrag kam mir in einem Gespräch mit einem Interessenten, der mir sinngemäß mitteilte, dass er vor der Auswahl eines ERP-Systems steht, aber diese „Spaß machen soll und er keine Lust habe, tagelang Kreuzchen zu setzen“. Wir diskutierten einen Moment über diese Äußerung und es wurde schnell klar, was dahintersteckte, nämlich die Sorge, das neue System nach den alten Kriterien auszuwählen.

Bevor wir über das Thema sprechen, möchte ich erklären, warum ein ERP-Lastenheft wichtig ist. Dann können Sie die beiden gezeigten Varianten für sich bewerten und eine fundierte Entscheidung treffen.

Wenn Sie grundlegende Fragen dazu haben, was ein Lastenheft ist, so empfiehlt sich wie so oft ein Blick auf Wikipedia. Dort wird auch der Bezug zur Anforderungsanalyse in der Softwareentwicklung hergestellt, was für die Einführung eines ERP-Systems von entscheidender Bedeutung ist.

Grundlegende / klassische Ziele eines Lastenhefts in der ERP-Auswahl:

• Das Lastenheft soll die Anforderungen Ihres Unternehmens in Bezug auf die neue ERP-Software enthalten, um sicherzustellen, dass alle spezifischen Bedürfnisse und Prozesse adäquat adressiert werden.
• Auf Basis der Unternehmensanforderungen soll ein objektiver Vergleich der infrage kommenden Anbieter und Systeme ermöglicht werden, was den Auswahlprozess wesentlich unterstützt und die Entscheidung für die richtige Lösung erleichtert.
• Das Lastenheft soll den (vollen) Projektumfang abbilden, inklusive aller notwendigen Schritte und Ressourcen, die für die erfolgreiche Implementierung des ERP-Systems erforderlich sind.
• Das Lastenheft des Auftraggebers bildet die Grundlage für das Pflichtenheft des Auftragnehmers, was die Kommunikation und Kooperation zwischen allen beteiligten Parteien verbessert und Missverständnisse minimiert.
• Festlegung klarer Kriterien zur Anbieterauswahl hilft dabei, den Auswahlprozess zu strukturieren und die Auswahl auf die Anbieter zu beschränken, die die besten Referenzen und die relevanteste Erfahrung im Umgang mit ähnlichen Unternehmensgrößen und Branchen vorweisen können.

Bezogen auf die grundlegenden Ziele lässt sich aus meiner Sicht Folgendes sagen: Die Methodik des klassischen Lasten- und Pflichtenheftes harmoniert „perfekt“ mit der Wasserfallmethodik nach der lange Zeit ERP-Projekte durchgeführt wurden und auch immer noch werden. Dieser Beitrag soll keine Gegenüberstellung unterschiedlicher Projektmethoden werden, es gilt allerdings zu berücksichtigen, dass die große Zeit der Wasserfallmethode wohl hinter uns liegt (bezogen auf ERP-Projekte). Immer mehrere meiner Kunden und immer mehr ERP-Anbieter verwenden agilere / hybride Methoden.

Neben den grundlegenden Zielen gilt es aus meiner Sicht, die Erstellung des Lastenhefts darauf auszurichten, dass die geleistete Arbeit und das Ergebnis einen maximalen Mehrwert für das anstehende Projekt liefern. Dies erfordert eine sorgfältige Beratung und Unterstützung durch erfahrene Projektteam-Mitglieder, um sicherzustellen, dass alle Kosten effektiv verwaltet und alle technischen und funktionalen Herausforderungen effizient angegangen werden.

Erweiterte Ziele der Lastenhefterstellung

• Fokussierung auf die notwendigen Prozesse und Funktionalitäten.
• Aktives ausklammern von Funktionalitäten, die mittlerweile ohnehin jedes moderne System bietet
• Bestmögliche Unterstützung über die gesamte Projektlaufzeit
• Ausrichtung der Anforderungen an den kommenden Herausforderungen und nicht am aktuell eingesetzten Altsystem

Der klassische Lastenheftansatz

Bevor ich den klassischen Ansatz der Lastenhefterstellung kurz skizziere, möchte ich klarstellen, dass ich diesen weder ablehne noch schlecht machen möchte. Ich verwende ihn selbst und es gibt genügend Unternehmen, für die dieser absolut der Richtige ist. Was ich aufzeigen möchte, ist, dass es auch andere Ansätze gibt, vielleicht sogar mehrere, die man bei der Wahl des richtigen Verfahrens in Betracht ziehen sollte.

Im klassischen Fall wählt ein Unternehmen einen Dienstleister aus, mit dem es die ERP-Auswahl durchführen möchte. Diese Dienstleister haben oft „fertige“ ERP-Lastenhefte mit einer schier riesigen Anzahl an möglichen Funktionalitäten zu den unterschiedlichsten Bereichen von Unternehmen. Man kann sich das wie einen Katalog vorstellen, aus dem der Kunde dann, begleitet durch einen Berater, die Funktionalitäten aussucht, welche er in seinem zukünftigen ERP-System benötigt. Dieser Katalog (das Maximallastenheft), wird abteilungsweise durchgesprochen und am Ende steht das ausgefüllte Lastenheft. Natürlich werden während der Workshops auch Ergänzungen gemacht, falls Funktionen benötigt werden, welche in der Lastenheftvorlage nicht enthalten sind. Dieser Prozess bildet eine grundlegende Entscheidungshilfe in der Implementierung des ERP-Systems und trägt dazu bei, dass das Projektteam die richtigen technischen und funktionalen Anforderungen klar definieren kann.

Die prozessbezogene Ermittlung der Anforderungen

Wie an anderer Stelle beschrieben, benutze ich sehr gerne die Geschäftsprozessanalyse, um im Unternehmen den Umfang des anstehenden Projektes so weit wie nötig klar zu dokumentieren. Da die Durchführung dieser Analyse in einer der ersten beiden Phasen eines ERP-Projekts durchgeführt werden sollte, liegt es nahe, das Ergebnis auch für die ERP-Auswahl zu verwenden. Wie in dem verlinkten Artikel beschrieben, ist das Ergebnis der GP-Analyse eine Übersicht über alle, mit der neuen ERP-Software abzubildenden, Prozesse, inklusive der für die Prozesse notwendigen Teilschritte. Ebenfalls Teil der Analyse ist ein die Bewertung der einzelnen Teilschritte, hinsichtlich ihrer Redundanz (wenn Teilschritte in mehreren Prozessen in gleicher Art und Weise benötigt werden).

Einfach das Ergebnis der normalen Geschäftsprozessanalyse als Anforderungsdokumentation zur Anbieterauswahl zu verwenden, wäre dann allerdings doch ein wenig zu trivial. Im Rahmen der Geschäftsprozessanalyse werden normalerweise einige Dinge nicht durchgeführt und dokumentiert, welches essenziell für den weiteren Prozess, sowie die Festlegung der notwendigen Kriterien, der Anbieterauswahl sind:

• Dokumentation von abteilungsinternen Abläufen: Dies umfasst spezifische Prozesse, die hauptsächlich innerhalb einzelner Abteilungen wie der Anlagenbuchhaltung oder Personalverwaltung stattfinden. Diese Prozesse sind kritisch, da sie oft spezialisierte Funktionen des ERP-Systems betreffen, die genau auf die Bedürfnisse dieser Abteilungen zugeschnitten sein müssen.
• Technische Anforderungen: Wichtige technische Spezifikationen, die das ERP-System erfüllen muss, wie unterstützte Sprachen, die Notwendigkeit eines umfassenden Workflowmanagements und spezielle Anforderungen im Bereich des Dokumentenmanagements, sind entscheidend für die Auswahl der passenden Lösung.
• Funktionale Anforderungen spezifischer Bereiche: Für bestimmte Unternehmensbereiche oder Abteilungen notwendige funktionale Anforderungen, wie die Verwendung von mobilen Endgeräten in Lager, Produktion und Service oder spezifische Schnittstellenanforderungen zu externen Systemen wie Business Intelligence-Plattformen, müssen detailliert erfasst und bewertet werden.
• Stammdatenthemen: Unterstützte Artikelklassifizierungen und die zugehörigen Prozesse wie Artikelanlageworkflows, die eventuell aus CAD-Systemen stammen, oder Kontakte im CRM-Bereich, sind wesentliche Bestandteile, die in der Geschäftsprozessanalyse oft übersehen werden können.

Was die hier aufgelisteten Punkte angeht, schlage ich zwei verschiedene Wege vor. Einerseits kann man einige der abteilungsinternen Prozesse ebenfalls als Geschäftsprozesse abbilden, um die Liste der Prozesse auf diese Art umfangreicher zu gestalten und damit eine detailliertere Planung und Implementierung des ERP-Systems zu ermöglichen. Dieser Ansatz trägt dazu bei, dass die spezifischen Anforderungen jedes Unternehmensbereichs in die Auswahl des ERP-Systems einfließen, was die Effizienz und Nutzung der endgültigen Lösung maximiert.

Eine weitere Möglichkeit, die sich für einen Großteil der Themen anbietet, ist die funktionale Ergänzung der einzelnen Geschäftsprozess-Teilschritte. Dies ermöglicht eine präzisere Darstellung der erforderlichen Funktionalitäten und fördert eine tiefere Integration der ERP-Lösung in die täglichen Abläufe des Unternehmens. Beispielsweise könnte man einen Prozessschritt wie die „Einlagerung von Bestellware“ um die folgenden funktionalen Anforderungen ergänzen:

• Verwendung von MDE-Geräten
• Automatische Zuweisung der zu verwendenden Lagerplätze

Für die Aufbereitung der Ergebnisse kann man verschiedene Möglichkeiten in Betracht ziehen. Wenn es darum geht, einzelnen Anbietern einen Eindruck über die aktuellen Anforderungen zu geben, kann man sicherlich die ergänzte GP-Analyse direkt verwenden. Bei umfangreicheren Auswahlprojekten würde ich jedoch entweder die Darstellung als klassischen Lastenheftkatalog oder aber die Darstellung in Form eines Produktbacklog, verwenden.

Vor- und Nachteile der beiden Vorgehensweisen

Unter welchen Bedingungen würde ich, welches Vorgehen einsetzen?

Klassisches Lastenheft

Diese Art der Anforderungsaufnahme bietet sich dann an, wenn Ihr Unternehmen in einer Branche angesiedelt ist, zu der es bereits viele Standards gibt. Dies erhöht die Chancen, dass Sie einen Anbieter für die Einführung finden, welcher einen nahezu vollständigen Funktionskatalog für Ihre Branche mitbringt, den es dann durchzuarbeiten gilt. Eine Vorauswahl kann durch eine Checkliste unterstützt werden, die sicherstellt, dass alle relevanten Funktionen berücksichtigt werden. Eine weitere Voraussetzung ist in meinen Augen, dass Sie sich gut vorstellen können, das ERP-Projekt mithilfe der, bzw. einer Art, Wasserfallmethodik durchzuführen, denn genau dann ergänzt das Lastenheft die Vorgehensweise optimal. Natürlich ist es auch möglich, auf die klassische Auswahl eine dynamischere Vorgehensweise folgen zu lassen; dann sollte das Lastenheft nach der Auswahl allerdings in eine „projekttaugliche“ Dokumentation umgewandelt werden, was oft Vertragsverhandlungen und Anpassungen seitens der Mitarbeiter und Software-Spezialisten erfordert.

Die prozessorientierte Vorgehensweise

Wie es bei solchen Vergleichen meist der Fall ist, kommt die andere Methode dann zum Zuge, wenn die Voraussetzungen für die zuerst dargestellte nicht gegeben sind. In unserem Fall also das Fehlen eines möglichst vollständigen Funktionskataloges (Vorlagelastenheft) und/oder der Wunsch nach einer dynamischeren/agileren Projektvorgehensweise bei der Einführung des ERP-Systems. Zusätzlich möchte ich noch anführen, dass das Abhaken von ggf. notwendigen Funktionsbausteinen auch ein Vorgehen ist, welches nicht notwendigerweise jedem Keyuserteam liegt. Um zu verhindern, dass sich die Mitarbeiter zu stark an das aktuell vorhandene System klammern, bietet sich der prozessorientierte Ansatz an. Dieser Ansatz ist in vielen Fällen vorteilhafter, da er die tatsächlichen Prozesse und Anforderungen des Unternehmens in den Mittelpunkt stellt und somit eine maßgeschneiderte Lösung ermöglicht, die die Effizienz und Produktivität nachhaltig steigert.