Lange Listen und nix dahinter?

Sind Lasten- und Pflichtenhefte in einer Zeit, in der agile Projektmethoden propagiert werden, überflüssig? Lasten- und Pflichtenhefte waren lange Zeit der Standard, wenn es um Softwareentwicklung ging. Mit dem Aufkommen von agilen Umsetzungsmethoden, wie SCRUM oder Extreme Programming sind lange Lastenhefte mit detailliert beschriebenen Funktionen beinahe Vergangenheit und werden immer seltener verwendet. Dennoch einigen sich Kunde und ERP-Anbieter bei Einführungsprojekten oftmals noch mittels einem Lasten- /Pflichtenheft über (funktionale) Verpflichtungen. Der Kunde möchte sich zum einen absichern, dass er auch den Funktionsumfang erhält, den er sich wünscht und zum anderen Sicherheit über das Budget. Der Anbieter lässt sich auf einen Festpreis nur dann ein, wenn die Leistung so genau wie möglich beschrieben ist. In unseren Projekten sind unsere Kunden dann oft skeptisch, wenn wir sagen, dass lange Lasten- und Pflichtenhefte nicht per se nötig sind. Was spricht nun für bzw. gegen ein Lasten- und Pflichtenheft?

Im Rahmen einer ERP-Einführung beschreibt das Lastenheft alle Anforderungen des Auftraggebers an das ERP-System inkl. Schnittstellenbeschreibungen. Das Pflichtenheft hingegen liegt in der Hand des ERP-Anbieters und beschreibt alle Leistungen, für die sich der Anbieter verpflichtet. Somit bildet das Pflichtenheft den Lösungsansatz des Anbieters auf die Anforderungen des Auftraggebers, also des Kunden, ab.

Die zentrale Aufgabe eines Lasten- und Pflichtenhefts ist die Dokumentation und der damit verbundene Anspruch auf vollständige Erfüllung der verhandelten Inhalte. Somit sichern sich sowohl Kunde als auch ERP-Anbieter im angegebenen Leistungsumfang ab. Daher ist der sicherlich größte Vorteil von Lasten- und Pflichtenheften, dass die Ziele und der Umfang des Projekts klar definiert werden. Ein Lasten- bzw. Pflichtenheft gewährleistet Planungssicherheit sowohl beim Auftraggeber als auch beim Auftragnehmer und gibt dem Auftragnehmer die Möglichkeit die Einführungskosten einer Software valide zu kalkulieren und spiegelt die Vorstellungen des Auftraggebers über den erwarteten Softwareumfang wider.

Im Gegenzug schränkt dieser Leistungsumfang jedoch auch ein. Wir wollen das mit einem kurzen Beispiel erläutern: Unsere Kunden haben häufig Geschäftsprozesse, die seit Jahren im Unternehmen etabliert sind und einer Effizienzsteigerung bedürfen. Die Erarbeitung neuer Prozesse ist eine Kombination aus der Nutzung von ERP-Standardfunktionen und der Etablierung neuer interner Abläufe. Wurden jedoch bereits vor dem ERP-Einführungsprozess Lasten und Pflichten festgehalten, entsteht nun die Herausforderung, Anpassungen am Lastenhefts vorzunehmen. Eine flexible Lösungsfindung im Projekt ist somit möglich, aber mit viel Aufwand verbunden. Daher sollte der Kunde idealerweise von Beginn an sicherstellen, den kompletten, bis ins Detail beschriebenen Leistungsumfang zu kennen und zu formulieren. Was zunächst einfach scheint, stellt sich dann als schwierig heraus. Denn ob ein Prozess für ein Unternehmen und die Mitarbeiter mit dem neuen ERP-System gut funktioniert, weiß man aus unserer Erfahrung erst wenn man es tatsächlich einmal ausprobiert hat.

Natürlich sind der Kunde und auch der ERP-Anbieter nach dem Klären der Lasten und Pflichten im engen Austausch miteinander. Änderungswünsche können also nachträglich besprochen und umgesetzt werden. Die zeitliche Perspektive ist hierbei dennoch nicht zu unterschätzen. Sowohl Kunde als auch Anbieter müssen die Veränderungen gemäß den Heften nachhalten und dokumentieren. Nach besprochener und dokumentierter Anforderung erfolgt nun die Umsetzung seitens des Anbieters. Exemplarisch ist das Wasserfallmodell zu nennen, welches oft den Rahmen einer Lasten- und Pflichtendokumentation bestimmt. Denn feststeht:

Unterschiedliche Verständnisse von umzusetzenden Anforderungen sorgen in der Regel für viel Verzug im Einführungsprojekt, da der Gap zwischen Kundenvorstellung und Anbieterumsetzung erfahrungsgemäß groß ist. So können simple Anpassungen große zeitliche Verlagerungen mit sich bringen. Eine Änderung im Lastenheft erfordert ein verändertes Anforderungsdesign, welches neu implementiert und anschließend getestet werden muss. Im Gegenzug werden die Arbeitsschritte durch den Kunden verifiziert. Betrachtet man hier agile Methodiken, wird schnell klar, dass Kunde und Anbieter sich auf einer anderen Ebene der Kommunikation befinden und Anpassungen schnell wirksam werden.

Auch bei einer agilen ERP-Einführung müssen Anforderungen, die der Kunde an das ERP-System stellt, aufgenommen werden. In der Regel werden hier externe Experten hinzugezogen, die eine objektive Sicht auf das Unternehmen des Kunden haben und somit besser beurteilen können, welchen System-relevanten Herausforderungen der Kunde gegenübersteht. Allerdings werden die Anforderungen nicht komplett im Detail vor Beginn der Implementierung festgelegt. Stattdessen wird sich geeinigt, welche Prozesse und Funktionsbereiche im Projekt bearbeitet werden sollen. Zu Projektstart einigt man sich auf ein oder zwei Arbeitspakete / Themenkomplexe, mit denen in die Detailarbeit gestartet wird (im Detail in unserem Whitepaper Agile ERP Einführungen zu lesen  LINK). In meist kleinen Teams bis zu 10 Personen werden die Arbeitspakete in 2-3-wöchigen Sprints bearbeitet. Der Austausch zwischen Kunde und Anbieter findet so in regelmäßiger Runde statt. Der Unterschied: Die Anforderungen werden nicht in dem Maße zu Beginn des Projektes dokumentiert, wie es klassischer Weise beim Lastenheft der Fall ist. Auch kurzfristige Anpassungen, beispielsweise aufgrund einer ungenügenden Anforderungsdefinition oder der Erkenntnis, dass der eingeschlagene Lösungsweg nicht der Richtige ist, können schnell umgesetzt werden. Die noch offenen Prozesse und Themenkomplexe können in einem Backlog (Aufgaben, die noch zu erledigen sind) nachgehalten werden. Aktuell zu bearbeitende Aufgaben werden im Sprint nachgehalten. Der Kunde hat somit die Chance nachzuvollziehen, wo er sich im Projekt befindet und welche Anforderungen es noch umzusetzen gilt, während im klassischen Wasserfallmodell der Umsetzungsstatus mitunter nicht so transparent ist und beim ERP-Dienstleister abgefragt werden muss.

Letztlich ist ein „agiles“ Vertragswerk nicht pauschal besser als ein Pflichtenheft. Wir empfehlen daher ein hybrides Vertragswerk. Das bedeutet, der Kunde verpflichtet den ERP-Anbieter Prozesse des Unternehmens gemeinsam mit ihm umzusetzen. Der Unterschied zum klassischen Pflichtenheft besteht darin, dass in dieser frühen Phase noch keine Lösungsvorschläge definiert sind, sondern diese erst in der Einführung mit dem Auftraggeber gemeinsam erarbeitet werden. Denn dieser kennt seine Prozesse schließlich am besten und im Diskurs bieten sich Chancen die eigenen Prozesse mithilfe des neuen ERP-Systems effizienter zu gestalten. Ob ein ERP-System infrage kommt und die entsprechenden Auftraggeber-spezifischen Funktionen umsetzen kann, wird vorher in der Auswahl mehrerer ERP-Anbieter/Systeme geklärt. Die preisliche Grundlage wird hier i.d.R. aufgrund von Personentagen, die es schätzungsweise braucht, um einen (Teil-)Prozess umzusetzen, kalkuliert.