Veränderungen gehören zur Tagesordnung
Der erste Teil der Serie betrachtet anhand einer ERP-Evaluation die Risiken, die in der traditionellen Software-Beschaffung mit detaillierter Produkt-Spezifikation nicht angemessen gehandhabt werden. Im zweiten Beitrag untersuchen wir die Risiken, die in der traditionellen Software-Beschaffung gegenüber neuen Anforderungen, sprich: Veränderungen entstehen.
Der Scope ist (eigentlich) fix
Die traditionelle Software-Evaluation versucht, Art und Umfang der Anforderungen an eine Business-Software (neud. den Scope) umfassend festzulegen und zu beschreiben (siehe Teil 1). Der Scope ist die Grundlage für Budget und Zeitplanung des Projekts. Er wird vorab definiert, ist fix, kostet soviel und dauert solange.
Bereits während des Einführungsprojekts entstehen jedoch neue Anforderungen. Als Quellen für neue Anforderungen kann man unterscheiden:
- Neue Anforderungen von ausserhalb des Projekts: Anforderungen von Kunden, Märkten, angebundenen Systemen, Weiterentwicklungen, Vorgaben (Normen, Gesetze), Reorganisationen, Zukäufen uvm.
- Neue Anforderungen aus dem Projekt: neue Erkenntnisse im Projektteam zu Art und Umfang der Anforderungen, die während der Arbeit im Projekt gewonnen werden (z. B. eine Anforderung ist wichtiger/weniger wichtig, benötigt zusätzlich dies, man könnte es anders umsetzen usw.).
Risiko 1: Change Request: Administrativer Aufwand und lange Realisierungszeiten
Ist eine Anforderungen als notwendige Änderung des Scopes identifiziert, muss sie per Change Request (CR) angefragt, kalkuliert und genehmigt werden. Change Requests sind aus verschiedenen Gründen unbeliebt:
- Einen CR zu erstellen erfordert Sorgfalt und Abstimmung (intern, mit dem Lieferanten). Das ist aufwendig. Diese Arbeiten sind im Projektplan nicht vorgesehen. Und ob ein Change Request genehmigt wird, ist ungewiss.
- CR müssen i. d. R. von höherer Stelle genehmigt werden. Das benötigt Zeit (z. B. durch Abwarten der nächsten Sitzung im Gremium). Oft sind die prüfenden Stellen nicht im Detail mit den Fragestsllungen vertraut und tun sich schwer mit Beurteilung und Priorisierung.
- CR verursachen zusätzliche Kosten und Verzögerungen in der Umsetzung.
- Bei Auslieferung eines Changes stellt sich heraus, dass die Funktion nicht oder anders benötigt wird usw.
Risiko 2: Einschränkung der Reaktionsfähigkeit
Die Reaktionsfähigkeit einer Organisation hängt wesentlich davon ab, wie schnell neue Anforderungen (Prozesse, Strukturen, Funktionen) in den beteiligten IT-Systemen umgesetzt werden können. Und wie schnell dies gelingt, wird bereits in der System-Evaluation erarbeitet. Hier wird definiert, wie Veränderungen in der Organisation und in Zusammenarbeit mit dem/den Lieferanten gehandhabt werden. Das Verfahren mit dem System-Partner vertraglich festgelegt. Es hat somit Auswirkungen weit über das Einführungsprojekt hinaus.
Und das ist schwerwiegend denn: weil die Handhabung von Änderungen mit fixem Scope und Change Requests umständlich ist, versuchen Organisationen in der traditionellen Beschaffung Änderungen am Scope auf das Notwendigste zu reduzieren. Wichtige Änderungen am System werden aufgeschoben um Budget und Zeitplan einhalten zu können. Damit schränkt die Organisation ihre Reaktionsfähigkeit ein. Zudem wird i. d. R. nicht geprüft, ob bereits vorab spezifizierte Anforderung noch notwendig und sinnvoll sind (der Scope ist fix). Es besteht somit das Risiko, dass wichtige Anforderungen gegenüber weniger wichtigen zurückgestellt werden.
Risiko 3: Energie für Diskussionen und Konflikte
In der traditionellen Software-Beschaffung konfiguriert der Systempartner das neue System in der Umsetzung gemäss Spezifikation nahezu vollständig, bevor es an den Kunden ausgeliefert wird. Bis die Anwenderinnen und Anwender vertieft mit dem System arbeiten, vergehen 4 bis 8 Monate.
Es ist eine Utopie zu glauben, man könne Business Software wie ERP- oder CRM-Systeme unabhängig von einer technischen Lösung umfassend spezifizieren, die Spezifikation an vorab nicht beteiligte Anbieter übergeben und ohne dass es zu Missverständnissen kommt. «Neue Erkenntnisse» entstehen somit auch, wenn…
- das Projektteam bei Auslieferung feststellt, dass der Kunde in der Spezifikation etwas anderes meinte, als der Software-Partner verstanden hat,
- wichtige Anforderungen, die man als selbstverständlich vorausgesetzt hat, nicht erfüllt werden, oder
- die Funktion zwar vorhanden, aber nicht in der benötigten Qualität verfügbar ist (Performance, Usability, Dateillierung).
Das hat nichts mit Unvermögen zu tun. Missverständnisse sind zu erwarten:
Der umfassende Anforderungskatalog. So sind Veränderungen nur schwer umzusetzen
Das Projektteam wird einen erheblichen Teil seiner Zeit und Energie investieren um es festzustellen, wie es zu dem Missverständnis kam, wer der Verursacher ist und ob die Änderung Teil des Budgets ist oder ein Change Request notwendig ist. Ein weites Feld mit viel Konfliktpotenzial in dem keine wirkliche Wertschöpfung entsteht.
Fazit
Die traditionelle Software-Beschaffung geht implizit davon aus, dass der Scope für das Einführungsprojekt feststeht und es nur wenig Veränderungen geben wird. Änderungen am Scope werden als notwendiges Übel angesehen und sind aufwendig in der Handhabung.
Wir brauchen einen besseren Umgang mit Veränderungen: Neue Anforderungen sind jedoch zu erwarten. Denn Organisationen verfügen über eine hohe Autonomie, Eigendynamik und Emergenz. Benötigt wird ein Verfahren mit wenig administrativem Aufwand, mit dem neue Anforderungen schnell und effektiv eingeordnet und je nach Priorität für die Organisation umgesetzt werden können.
Das Projektteam erhält erst nach der Auslieferung des Gesamtsystems Rückmeldung zur Qualität der Umsetzung. Dadurch entsteht ein hohes Risiko Fehlentwicklungen (wenig wichtige Funktionen, ungenügende Qualität).
Wir brauchen früheres Feedback von Anwenderinnen und Anwendern: Nur wenn Anwenderinnen und Anwender früh Rückmeldung zur Funktionen und Prozessen in der Business Software geben, können die Entwicklungen rechtzeitig (nicht erst nach 4 bis 8 Monaten) angepasst werden können.
Im dritten Teil der Serie skizziere ich, wie das gelingen kann.
Teil 1: Über die Risiken, die durch umfassende Spezifikationen entstehen.
Teil 3: Über alternative Vorgehensmodelle, die Unsicherheiten und Risiken besser handhaben
