24.08.2017 Lasten- und Pflichtenheft

Agiles Vorgehen in ERP-Projekten? – Eher nicht

Von: Guido Piech

In den letzten Jahren ist in Zusammenhang mit größeren IT-Vorhaben zunehmend die Rede von agilem Vorgehen. Die Projekte werden dabei in kleinere Abschnitte unterteilt, um sie besser steuern und Fehler leichter korrigieren zu können. Doch davon raten Experten im Falle von ERP-Implementierungen weitgehend ab.

  • Teillösungen in kleinen Schritten an den Kunden zu übergeben, wird als agil und iterativ bezeichnet, bei Standard-ERP-Software ist das eher ungeeignet.

    Agil und beweglich: Teillösungen in kleinen Schritten an den Kunden zu übergeben, wird als agil und iterativ bezeichnet. Bei Standard-ERP-Software ist das eher ungeeignet.

  • GPS-Geschäftsführer Werner Schmid

    „Die ERP-Anbieter wollen Geld verdienen und verkaufen deshalb auch Schnittstellen, die sie in ähnlicher Form bereits realisiert haben, jedes Mal als individuelle Neuentwicklung“, kritisiert GPS-Geschäftsführer Werner Schmid.

  • Jörg Rehage von F&M Consulting: In seinen Augen sollte kein komplexes IT-Projekt ohne ein Lasten- und Pflichtenheft gestartet werden.

    Jörg Rehage von F&M Consulting: In seinen Augen sollte kein komplexes IT-Projekt ohne ein Lasten- und Pflichtenheft gestartet werden.

  • Arndt Laudiehn von MQ Result: Agile Projektmethoden sind seiner Erfahrung nach eher für Software-Entwicklungsprojekte und weniger für Standard-Software-Einführungsprojekte geeignet.

    Arndt Laudiehn von MQ Result: Agile Projektmethoden sind seiner Erfahrung nach eher für Software-Entwicklungsprojekte und weniger für Standard-Software-Einführungsprojekte geeignet.

„Ein Standard-ERP-Projekt ist primär kein Entwicklungsprojekt“, macht z.B. GPS-Chef Werner Schmid deutlich. Um das aufwendige Erstellen eines detaillierten Lasten- und (!) Pflichtenheftes kommen die Anwender also nicht herum. Dies bestätigt Jörg Rehage von F&M Consulting. In seinen Augen sollte kein komplexes IT-Projekt ohne ein Lasten- und Pflichtenheft gestartet werden. Ein Lastenheft sollte dabei immer den Projektgrund, das Projektziel und die zu berücksichtigen Besonderheiten des auftraggebenden Unternehmens beschreiben, bestenfalls mit einer genauen Ist- und Soll-Prozessbeschreibung. „Ein Pflichtenheft sollte dann nach einem zuvor definierten Prototyping und einer Ausstiegsmöglichkeit in dem Projekt die konkrete Umsetzung beschreiben, wobei das Pflichtenheft idealerweise mit dem Anbieter gemeinsam geschrieben wird“, so Rehage.

In der Regel wird eine ERP-Standard-Software in genau definierten Meilensteinen eingeführt. Dabei geht es nicht um bestimmte Funktionen, die sukzessive aktiviert werden, sondern um feste Zielvereinbarungen im Projektverlauf wie Prototyping, Customizing, Proof of Concept, Go-Live und Fine Tuning. Im Gegensatz dazu stehen Individualsoftware-Projekte, in denen es im Wesentlichen um die eigentliche Entwicklung eines Softwareproduktes geht. Dabei werden häufig bereits Teillösungen in kleinen Schritten an den Kunden übergeben. Rehage: „Diese Projektvorgehensweise wird als agil und iterativ bezeichnet, die bei Standard-ERP-Software jedoch eher ungeeignet ist.“

Auch Arndt Laudiehn von MQ Result pflichtet grundsätzlich bei, dass sich die Anwendung agiler Projektmethoden seiner Erfahrung nach eher für Software-Entwicklungsprojekte und weniger für Standard-Software-Einführungsprojekte eignet, gibt jedoch zu bedenken, dass ein hybrides Vorgehen in ERP-Projekten sinnig sein könne. „Wenn z.B. innerhalb eines ERP-Projekts vorher bekannte Entwicklungsleistungen notwendig und abgestimmt sind, können diese im Scrum-Verfahren realisiert werden, während das Gesamtprojekt klassisch in seinen definierten Phasen innerhalb vorher definierter Meilensteine umgesetzt wird.“

Grundsätzlich müssten sich die Anwenderunternehmen jedoch immer entscheiden, wie wichtig ihnen die Absicherung des ERP-Projektbudgets und die Benennung einer klaren zeitlichen Planung zur Umsetzung eines fest definierten Projektinhalts vor Vertragsschluss sind. Die Frage ist, um was es sich bei den erwähnten Entwicklungsleistungen handeln könnte. Werner Schmid jedenfalls rät stark davon ab: „Unsere Empfehlung: Nur den als Standard ausgewiesenen Funktionsumfang verlangen und nutzen, sonst nichts.“

Schnittstellen, das ewige Thema

Offensichtlich wird dieser Ratschlag oft nicht gut genug befolgt, denn sonst liefen nicht so viele ERP-Implementierungen aus dem Ruder. Das kann abseits der mangelnden Projektvorbereitung daran liegen, dass „es dem Anwender in Teilbereichen nicht möglich ist, sich auf die vom Anbieter als branchenüblich definierten Prozesse und Funktionen einzulassen“, wie Arndt Laudiehn meint. Er verweist erneut auf die genaue Überprüfung der Software, in diesem Falle der Best Practices der jeweiligen Branche.Jedoch: Ein wenig Individualität sollte schon erlaubt sein. Andernfalls wären alle Unternehmen austauschbar und gleich.

Diese in Teilen gewollte Individualisierung erklärt jedoch nicht die wiederkehrenden Probleme bei der Erstellung von Schnittstellen, die nach allgemeinem Dafürhalten Standard sein sollten. Vielleicht liegt die Schnittstellenproblematik darin begründet, dass „die ERP-Anbieter Geld verdienen wollen und deshalb auch Schnittstellen, die sie in ähnlicher Form bereits realisiert haben, jedes Mal als individuelle Neuentwicklung verkaufen“, wie Werner Schmid kritisiert.

Laut Jörg Rehage sind mit der richtigen Projektstruktur und dem nötigen Detailwissen auch Schnittstellen nicht wirklich ein Problem. Denn alle Softwarehersteller haben ihre Schnittstellen an denselben Stellen und auch Schnittstellendefinitionen seien vorhanden. Nur könnten diese in den ausschreibenden Unternehmen kaum jemand interpretieren. Systemintegratoren wie er setzen daher in ERP-Projekten neben Projektleitern auch Fachinformatiker und Anwendungsentwickler ein, um diese Entwicklungsaufwendungen vorher genau zu definieren.

Bildquelle: Thinkstock

 

 

©2017 Alle Rechte bei MEDIENHAUS Verlag GmbH