Teil 1: Klassische Beschaffung: «Big Design Upfront»
Der Lebenszyklus von Business Software unterscheidet sich grundlegend von dem physischer Güter. Trotzdem beschaffen viele Organisationen auch umfangreiche Business-Software, IT-Produkte und IT-Dienstleistungen wie industrielle Waren: Um die zunehmende Komplexität in der Beschaffung und die damit verbundenen Risiken zu bewältigen, wird in immer aufwendigere Spezifikationen und ausgefeiltere Auswertungen investiert. Das führt zunehmend zu Problemen in Evaluation, Einführung und Umsetzung. Weit schwerwiegender sind jedoch die langfristigen Folgen für die beteiligten Organisationen (Kunden wie Hersteller). Darum und um die Alternativen, geht es in dieser Serie.
In diesem ersten Teil gehe ich auf die Problematik der klassischen Evaluation mir ihrer umfassenden Spezifikation ein. Im zweiten Teil geht es um den Umgang mit Veränderung. Der dritte Teil skizziert, was mögliche alternative Denkansätze und Herangehensweisen sein können.
Beispiel Spezifikation in einer ERP-Evaluation
Hier geht es um komplexe Beschaffungsvorhaben. Als Beispiel verwende ich die Evaluation und Einführung eines neuen ERP-Systems für ein mittelständische Unternehmen. Nicht das ERP-System ist komplex, sondern die zu treffenden Entscheidungen vor dem Hintergrund der offenen Zukunft, der Dynamik von Organisationen und der vielfältigen und hohen Erwartungen.
Die Diskussion wird oft verkürzt auf die Frage «Was ist die richtige Methode?». Hier geht es um Vorhaben mit hoher Unsicherheit. Methode im Sinne von «regelbasiertem und planmässigem Vorgehen» ist in Unsicherheit selten hilfreich. Es gibt keine Methode für den Umgang mit Unsicherheit, die immer funktioniert, auch wenn viele Berater das Gegenteil behaupten. Hier geht es vielmehr um:
- Prämissen (für Entscheidungen in Unsicherheit)
- Wahrnehmung (für das, was in der Organisation geschieht und benötigt wird) und
- Kompetenz mit Unsicherheit umgehen zu können
In diesem Sinne möchte ich diese Beitragsserie nicht als Musterlösung sondern als Diskussionsgrundlage und als Inspiration und Entwicklung eigener Gedanken und Herangehensweisen verstanden haben.
Der Wunsch nach Sicherheit durch umfassende Spezifikation
1. Kundenperspektive
Es sieht naheliegend aus: Wenn Sie etwas kaufen möchten, beschreiben Sie, was Sie brauchen. Sie erstellen eine Spezifikation (oder ein Lastenheft), übergeben diese an mögliche Lieferanten als Anfrage und wählen aus deren Angeboten das wirtschaftlich beste aus. Die Idee dahinter ist: «Je umfassender und genauer wir beschreiben was wir brauchen, desto wahrscheinlicher bekommen wir was wir wollen.»
Wer schon einmal eine Spezifikation für ein ERP-System erstellt hat, kennt die Herausforderungen dabei. Ein ERP-System lösungsneutral zu spezifizieren ist schwierig (selbst für Profis). Man muss eine Wahl treffen, wie detailliert man spezifiziert. Man lässt dabei immer relevante Details weg. Es ist unmöglich, eine Organisation vollständig zu beschreiben. Hinzukommen Fragen wie: Was kann man als «Standard» in einem System erwarten? Wie priorisiert man sinnvoll? Wie behandelt man die ganzen Sonderfälle? können wir unser Prozesse mit der geeigneten Technik/besseren Tools vereinfachen? Man kann einen Berater engagieren, doch der kennt das Tagesgeschäft und die Herausforderungen der Organisation nicht im Detail. Er kann nie all diese Fragen kompetent beantworten sondern bestenfalls gute Übersetzungsarbeit leisten.
Meist wird ein bestehendes ERP-System abgelöst, weil es nicht mehr «uptodate» ist. Unklar bleibt dabei, welche tieferen Absichten mit dem Vorhaben verfolgt werden (was ist uptodate?). Dazu, was die Organisation genau benötigt, gibt es viele Sichtweisen. Meist ist das Ziel des Vorhabens unscharf formuliert (beliebt sind: zukunftstauglich, effizient, innovativer, kundenzentriert, produktiver oder agiler). Ich plädiere hier nicht etwa für smarte Ziele oder ähnliche Scheinkonkretheiten. Im Gegenteil: die Absichten, die mit solch einem Vorhaben verfolgt werden, sind vielfältig: Der Verkauf möchte seine Kunden besser bedienen können, der Innendienst seine Überstunden abbauen und die Produktion weniger Rückfragen zu den Produktionsaufträgen usw. Es wird nicht gelingen, all das in einem Satz zusammenzufassen.
Auf Nummer sicher
Die mit dem Erstellen der Spezifikation verbundene Unsicherheit führt zu einem wichtigen Effekt: Man geht im Zweifel auf Nummer sicher. Man möchte ja ein gutes System auswählen. So wird statt einer soliden Kundenverwaltung ein komplettes CRM, statt einer Plantafel ein Leitstand und statt übersichtlichen Kennzahlen ein komplettes BI-System spezifiziert. Alle Maschinen werden angebunden und alle Verkäufer arbeiten mobil. Wie sonst soll man zukunftstauglich werden?
Eine umfassende Spezifikation zu erstellen dauert erfahrungsgemäss zwischen 3 und 9 Monate. «Das ist lang», werden Sie sagen. Berücksichtigen Sie jedoch, dass die Beteiligten nicht zu 100% für das Projekt arbeiten, dies zum ersten Mal machen und, wie oben beschrieben, viele schwierige Entscheidungen treffen müssen. Lastenhefte für ERP-Systeme haben nicht selten 80 bis 100 Seiten und über 500 Anforderungen (10 Unternehmensbereiche mit je 50 Anforderungen plus einige übergeordnete Requirements und Sie sind dabei).
Zwei wichtig Punkte noch zur Spezifikation: In den meisten klassischen Spezifikationen ist beschrieben, was der Kunde benötigt. In welcher Qualität und mit welcher Priorisierung ist in der Regel kaum geklärt. Dazu später mehr.
Priorisierung von Anforderungen in der ERP-Evaluation
2. Anbietersicht
Die fertige Spezifikation wird an ausgewählte Anbieter geschickt. Für die mit der Anfrage betrauten Anbieter, ergeben sich nun folgende Herausforderungen:
- Sie können die Absichten, die die Organisation mit dem Vorhaben verfolgt, nur erahnen
- Die Anfrage ist teils unvollständig, teils widersprüchlich
- Die Anfrage schreibt Lösungen vor, die nicht ihrem Konzept entsprechen (die sie anders lösen würden)
- Sie wissen, vieles von dem was angefragt ist, wird weder benötigt noch umgesetzt
Die Anbieter möchten den Auftrag. Sie werden versuchen, die wichtigsten Fragen zu klären um so ein schärferes Bild davon zu schaffen, was sie anbieten müssen, um den Auftrag zu erhalten. Dabei müssen sie damit Leben, dass die Aussendarstellung des Kunden kaum Einblick in das Innenleben der Organisation erlaubt. Auch die Antworten zu Fragen über die heutigen/zukünftigen Prozesse und Strukturen sind meist unscharf. Die Anbieter haben daher zwei Möglichkeiten für die Angebotserstellung:
- Sie kalkulieren das Projekt «bottom up» gemäss Anfrage und treffen Annahmen, wo Unklarheit herrscht.
- Sie schätzen anhand von vergleichbaren Projekten, was hier an Modulen und Leistungen benötigt wird.
In beiden Fällen werden Sie sich daran orientieren, was «marktfähig» ist (denn sie wollen den Auftrag), gleichzeitig Reserven einrechnen und sich gegen die inhärenten Risiken absichern.
Der Leistungskatalog: Die umfassende Spezifikation birgt hohe Risiken
Vom Angebot zum Vertrag
Anhand der eingereichten Angebote und seiner Recherche wird der Kunde eine Auswahl treffen und eine Shortlist erstellen. Er wird sich schwer tun, die Unterschiede der Anbieter auszumachen, zu bewerten, was für ihn und sein Vorhaben relevant ist und wie er sich entscheiden soll. Der Abdeckungsgrad der Anforderungen ist in der Regel hoch, jedoch unterschiedlich verteilt. Für alle Angebote gibt es Pro- und Contra-Argumente. Um diese Komplexität reduzieren zu können, wird er den Preis als ein wesentliches Auswahlkriterium heranziehen.
die ausgewählten Anbieter werden sich und ihre Software-Lösungen beim Kunden präsentieren. In der Regel wird für dieses, von den Anbietern liebevoll «Schaulaufen» genannte Prozedere ein halber oder ein ganzer Tag investiert. Die Anbieter werden sich von der besten Seite zeigen, meist durch Mitarbeiter, die für das «Pitchen» speziell qualifiziert sind. Auswahlberater brüsten sich damit, dass die Projektleiterin/dern Projektleiter aufbieten. Das ändert nichts daran, dass der Kunden nicht erfährt, wie gut er mit dem Team des Beraters zusammenarbeiten kann. Das ist in der kurzen Zeit schlicht nicht möglich.
Der Kunde wird trotzdem entscheiden, mit welchen Anbietern er Vertragsverhandlungen führt. Er wird versuchen, die spezifizierten Anforderungen und Leistungen zu einem möglichst günstigen Preis zu bekommen und die wesentlichen Risiken in die Verantwortung des Anbieters zu geben. Der Anbieter wird versuchen, einen möglich hohen Preis zu erzielen und sich gegen Risiken, die er nicht allein verantwortet (das ist die Mehrheit) abzusichern.
Man wird einen Werk-, einen Dienstleistungsvertrag oder beides vereinbaren. Man wird auch über die Projektdauer diskutieren. Der Kunde möchte schnell einführen. Der Anbieter weist darauf hin, dass in der Regel der Kunde, nicht der Anbieter den Engpass der Einführung ist. Man einigt sich auf eine Einführungszeit von 11 Monaten. So kann man zum Ende des Geschäftsjahres umstellen und der Kunde verspricht, die Einführung mit höchster Priorität zu behandeln.
Zwischenbilanz
Was wir brauchen ist (stark vereinfacht): Der Kunde, also die Organisation, die ein neues ERP-System implementieren möchte, verfügt über eine hohe Problemkompetenz: Er kennt die Herausforderungen aus dem Tagesgeschäft mit seinen Kunden und in der internen Zusammenarbeit. ihm fehlt das Wissen darüber, wie er diese Herausforderungen mit bestimmten ERP-Lösungen besser lösen kann als heute. Über dieses Wissen (die Lösungskompetenz) verfügen die System-Anbieter. Sie kennen jedoch die spezifischen Herausforderungen dieser Organisation nicht.
Damit das Vorhaben im Sinn der Beteiligten erfolgreich werden kann, müssen beide jeweils vom anderen lernen. Oder anders gesagt, sie müssen sich gegenseitig unterstützen, ihr Verständnis der Bedürfnisse und der bereitgestellten Mittel des anderen zu erhöhen: Der Kunde muss das ERP-System und seine grundlegenden Konzepte verstehen, der Anbieter die Herausforderungen und Herangehensweisen des Kunden. Dabei wird keiner den beiden Experte auf dem «Fachgebiet» des anderen. Es geht vielmehr um eine Annäherung, so dass man gemeinsam entwickeln kann. Dazu braucht es vor allem eines: Kooperation.
Ko-Kreation in der ERP-Evaluation: Kunde und Systemanbieter müssen gegenseitig ihre Kompetenz erhöhen
Das Projekt läuft jetzt seit etwa einem Jahr (ca. 3-9 Monate für die Spezifikation und 3-4 Monate für Angebote, Auswertung, Workshops, Referenzauskünfte, Budget- und Projektplanung sowie Vertragsverhandlung). Das Ziel der Ausschreibung war, Klarheit und Sicherheit zu schaffen. Die Bilanz diesbezüglich sieht wie folgt aus:
- Die Unsicherheit zu Bedürfnissen und Zielen der Organisation ist hoch *): Das Ziel scheint klar: das alte ERP-System muss raus, das neue rein und dadurch muss alles besser werden. Weil das vordergründige Ziel so klar scheint, findet eine vertiefte Auseinandersetzung zu den dahinterliegenden Bedürfnissen meist nicht statt (was heisst «besser»?). Auch welche Alternativen es zur ERP-Einführung gäbe und welche anderen Vorhaben man aufgrund des Projekts nicht angehen kann (für was man sich alles nicht entscheidet und loslässt) bleibt eher unbetrachtet. Ein gemeinsames Verständnis zu dem, was erreicht werden soll, auf was hin man optimiert, ist jedoch wichtig als Orientierung im Projekt.
- Die Unsicherheit zu Art und Umfang der umzusetzenden Anforderungen ist hoch: Der Kunde hat definiert, was er glaubt umsetzen zu müssen. Im Verlauf des Projektes wird es bei den Beteiligten neue Erkenntnisse geben. Sie werden sehen, dass manche Sachen einfacher, andere aufwendiger sind als gedacht, das Angedachtes nicht benötigt und Weggelassenes dringend gebraucht wird. Das Projektteam wird viel Energie in die Frage investieren müssen, was (wirtschaftlich) sinnvoll und zielführend ist und auf was man besser verzichtet.
- Die Unsicherheit zur Eignung der ERP-Lösung ist hoch: Die Spezifikation fokussiert auf das, was benötigt wird. Auch hier wird es neue Erkenntnisse geben. Man wird sehen, das wichtige Details nicht beschrieben sind und qualitative Aspekte werden in den Vordergrund treten («Wir dachte, das geht schneller/einfacher»). Das Projektteam wird viel Zeit in die Frage investieren, wann eine Anforderung gut genug erfüllt ist. Und man wird die Frage stellen, ob man die richtige ERP-Lösung gewählt (denn die alte ERP-Lösung war da und dort doch nicht schlecht).
- Die Unsicherheit zur Zusammenarbeit von Kunde und Anbieter ist hoch: Die Zusammenarbeit zwischen Kundenteam und Team des Anbieters wurde nur am Rande beleuchtet. Wie belastbar sie tatsächlich ist, zeigt sich erst im Stress der Einführung.
- Die Unsicherheit zu Budget und Zeitplan ist hoch: Der Zeitplan wurde unter der Vorgabe «verhandelt», dass es schnell gehen muss. Und er wurde an einem Meilenstein ausgerichtet, der nichts über die Machbarkeit des Vorhabens mit den vorhandenen Kapazitäten und Fähigkeiten aussagt. Das Budget wurde unter der Annahme festgelegt, dass sich der Umfang des Projekts nicht ändert, was eher unwahrscheinlich ist (s. o.).
Die umfassende Spezifikation ist Investition die sich nicht auszahlt
Wir haben ein Jahr in die Evaluation eines neuen ERP-Systems investiert. Wir haben einen unterzeichneten Vertrag der beschreibt, was der Lieferant liefert, was diese Leistung kostet und wer welche Risiken trägt. Konkrete Werte im Sinne eins funktionierenden (Teil-)Systems sind noch nicht geschaffen. Wert wird erst mit Beginn des Einführungsprojektes geschaffen. Gleichzeitig sind die Risiken (die Unsicherheiten für das anstehende Einführungsprojekt nach wie vor hoch (s. o.):
Der Invest der Arbeit eines Jahres in ein Projekt ohne essentiellen Wert und solch hohen Risiken, muss sich in der Einführung auszahlen. Ob und wie das gelingt betrachten wir im nächsten Beitrag. Wir werden untersuchen, welche Auswirkungen diese Ausgangslage auf die Einführung und den weiteren Verlauf des Vorhabens hat. Ein wesentlicher Aspekt dabei wird der Umgang mit Veränderungen sein.
Hier ein Ausblick auf Teil 2 und 3 der Beitragsserie:
Teil 2: Wie Sie in ERP-Projekten erfolgreich mit Veränderungen umgehen
