Was spricht für eine Anforderungsanalyse vor einer ERP-Auswahl?
Im Rahmen der Anforderungsanalyse und der ERP Auswahl gibt es verschiedene Punkte, die Sie beachten sollten, um das Risiko eines Scheiterns des ERP Projektes zu vermeiden und auszuschliessen.
Neben den quantitativen Gründen, weshalb ERP Projekte scheitern, gibt es eine Reihe qualitativer Gründe, die auch für ein Scheitern verantwortlich sein können.
falsche Anforderungen führen automatisch zu falschen ERP Systemen oder zu IT Systemen die nicht optimal geeignet sind. Die Problematik dabei ist, dass die groben Anforderungen oder Prozesse meist auf hoher Organisationsebene noch leicht abbildbar und umsetzbar sind. Die Probleme tauchen in der Regel dann auf, wenn in der Detailarbeit die Software zeigen muss, dass sie den Business Prozess unterstützt, Schnittstellen bedienen soll und die Datenauswertungen für die Entscheider darstellen können muß.
Wenn die Anforderungen unklar oder ungenügend spezifiziert sind, wird mit hoher Wahrscheinlichkeit die falsche Software in den Einsatz gelangen.
Dies erfolgt unabhängig von Markennamen oder vom Integrationsgrad verschiedener Module der ausgesuchten Software.
in Projekten treffen wir immer wieder auf das Phänomen der impliziten Annahmen. Dies äußert sich sehr oft in Aussagen die beispielhaft so lauten können: dieser Prozess ist doch selbstverständlich, das brauchen wir nicht zu dokumentieren, muss doch Standard sein. Das Problem dabei ist, dass in vielen Fällen die Beteiligten einen großen Toleranzspielraum nutzen. Das kann dazu führen, dass Programmierer oder Softwareberater eine eigene, andere Idee realisieren, als der Auftraggeber, der Nutzer oder der ERP Verantwortliche sich vorstellt.
Im Rahmen eines ERP Projektes gibt es viele solcher impliziten Annahmen. Gerade deshalb ist es wichtig, diese zu erkennen und wo nötig, zu dokumentieren und in die Anforderungsanalyse und ERP Auswahl aufzunehmen.
Sie kennen sicher das kleine Beispiel aus der Kommunikationstheorie zum Sachverhalt von Aussagen und Informationsweitergabe. Gerne werden die Begriffe Sender und Empfänger dazu verwandt.
Selbst bei gleicher Sprache ist es nicht sicher, dass der Empfänger einer Botschaft das gleiche unter der Information versteht, wie der Sender der Information oder der Aussage.
Nicht selten erleben wir in ERP oder IT Projekten eine Veränderung von Anforderungen während der Projektlaufzeit. Gründe für diese Änderungen sind vielfältig. Nicht selten muss gerade bei langen Projekten auch sichergestellt werden, dass Anforderungen aus der Supply Chain oder aus den Kundendienstleistungen sich während der Projektlaufzeit verändern können. Entscheidend dabei ist jedoch, dass ein erfahrener Projektleiter in der Lage ist, schon zu Beginn des Projektes die Fragen von „in- und out Scope“ zu definieren und falls Änderungen im Projektverlauf notwendig sind, diese sauber zu dokumentieren und zu realisieren.
Dabei ist entscheidend, dass die Auswirkungen auf das Projekt, auf die Prozesslandschaft, den Zeitverlauf und nicht zuletzt auch die Investition berücksichtigt wird.
Alle Beteiligte wissen, dass eine schlechte Analyse zu Fehlern im Projektverlauf und zu hohen Kosten beim Rückbau oder Änderungsmanagement bei der Anforderungsanalyse und ERP Auswahl führen kann.
Für uns Umsetzungsberater zeigt sich aber deutlich ein Schwerpunkt ab. Es ist nicht einfach Anforderungen zu artikulieren.
Hinzu kommt:
Ein weiterer Grund ist auch, dass qualitativ hochwertige Anforderungsanalyse und ERP Auswahl Zeit und Geld kostet. Das Budget für die Anforderungsanalyse wird gerne schlank gehalten.
Dabei entsteht nur ein weiteres neues Phenomen. Nach Installation einer ERP Software oder andern IT Lösung und Inbetriebnahme, als auch nach deren Abnahme, bleibt dem Unternehmen keine Wahl, als auftauchende Fehler, falsches Customizing, mangelnde Funktionen und mangelnde Prozessunterstützung oftmals mit großen Nachtragszahlungen zu in Auftrag zu geben und zu realisieren. Aber dies erfolgt in der Regel nach dem Projekt, so dass der Zusammenhang zwischen Ursache (ungenügendes Anforderungsmanagement) und Wirkung (unpassende Software, fehlende Businessunterstützung) kaum mehr hergestellt wird.
Der Zeitfaktor ist auch oft ein Projekttreiber, der zu schwierigen Lösungen oder zu Problemen führen kann.
Eine qualitative Analyse benötigt ihre Zeit. Diese muss den Beteiligten auch zur Verfügung stehen.
Das Problem ist aber oft, dass die IST Aufnahmen für externe Spezialisten und externe Berater auf der Budgetseite auch unter Druck stehen und Geld für die IST Aufnahme gespart werden soll. Dies ist normal und im Rahmen einer Beurteilung einer Projekt ROI und zur Beurteilung der Leistungsfähigkeit der Beteiligten auch sinnvoll. Aber…
Es gibt solche Lösungen, die aber nur mit dem Einsatz hochspezialisierter Software und Auswertetools möglich ist. Wir haben Methoden und Werkzeuge im Einsatz, um die Aufwandszeit für die IST Analyse um etwa 50% zu reduzieren und gleichzeitig die Datenqualität für das nachfolgende Business Design zu erhöhen.