Evaluation, Beschaffung und Einführung eine grösseren Business Software ist für Organisationen ein Veränderungsvorhaben mit Unsicherheiten und hohen Risiken. Die traditionelle Software-Beschaffung versucht dem mit umfassender Spezifikation und detaillierten Analysen zu begegnen. Damit gelingt es nicht, Gewissheit und Sicherheit zu erlangen, wie der erste Beitrag der Serie zeigt. Die Zukunft bleibt unvorhersagbar. Organisationen müssen laufend mit Überraschungen und neuen Anforderungen umgehen. Durch umfassende Spezifikationen laufen sie Gefahr, ihre Handlungs- und Reaktionsfähigkeit einzuschränken (siehe zweiter Beitrag). In Situationen mit hoher Unsicherheit in eine aufwendige und lange Analyse zu investieren ist nicht nur unsinnig (weil sie zur Zukunft nicht aussagefähig ist) sondern auch fahrlässig (Verschwendung und Einschränkung).
Doch zu erkennen, dass etwas dysfunktional ist, heisst noch nicht zu wissen, was stattdessen funktionieren könnte. Daher skizziert dieser Beitrag, wie die Evaluation einer Business Software gestaltet werden kann, um einen geeigneten Umgang mit den beschriebenen Unsicherheiten und Risiken zu entwickeln. Die Phase der Beschaffung ist zentral, weil hier die Grundlagen für die späteren Phasen, einschliesslich der Weiterentwicklung der Business Software, gelegt und im Vertrag festgehalten werden.
Entscheiden in Ungewissheit: Robustheit in der Evaluation durch Heuristik
Wir müssen akzeptieren, dass wir in einem Vorhaben wie einem ERP-Projekt das meiste nicht wissen. Selbst wenn wir alle heute verfügbaren Daten analysierten (inkl. Referenzen und Eigentumsverhältnissen der Anbieter), könnten wir diese Fragen nicht zuverlässig beantworten. Die Zukunft bleibt offen. Strategien die auf Analyse der Vergangenheit, Extrapolation oder der Maximierung des erwarteten Nutzens basieren, helfen uns in komplexen Fragen nicht weiter. Sie beruhen auf Annahmen und Schätzungen, die sich jederzeit ändern können und sind daher extrem fehleranfällig.
Stattdessen braucht es ein Verfahren, das iterativ, das heisst wiederkehrend die relevanten Variablen überprüft und so Änderungen der Situation berücksichtigen können. Solche Heuristiken ermöglichen anhand weniger aussagefähiger Variablen (begrenztem Wissen) und Intuition zu prüfen, ob ein Vorhaben «auf Kurs» ist. Die Faustregel für die Unterscheidung zwischen Analysen und Heuristiken heisst:
- Stabile Situation, wenig Optionen, viele Daten > Mach es komplex: Big Data, Statistik, Data Mining, traditionelle Beschaffung
- Unstabile Situation, viele Optionen, wenig Daten > Mach es einfach: Heuristik
Nebenbemerkung: Wenn Sie dieses Thema unabhängig von der Software-Beschaffung interessiert, empfehle ich Ihnen den Vortrag von Prof. Gerd Gigerenzer als Einstieg. Wir leben in einer Gesellschaft die glaubt, alles über Analysen lösen zu können. Doch wir brauchen beides: analytische Methoden und Heuristiken. Und wenn Sie oben an dem Wort «Intuition» hängegeblieben sind, schauen Sie sich dieses kurze Video zum Umgang mit Komplexität von Peter Kruse an.
Im Folgenden beschreibe ich eine Heuristik, wie wir sie bei elean für die Beschaffung von Business Software einsetzen. Sie beruht auf dem von Mirko Kleiner entwickelten Lean Agile Procurement. Es ist kein Rezept, das man immer gleich anwenden kann. Heuristiken sind kontextabhängig und müssen jeweils an Rahmenbedingungen und Fragestellung angepasst werden. Die Beschreibung gibt jedoch Einblick in die grundlegenden Unterschiede zur traditionellen Software-Evaluation mit detaillierter Spezifikation und deren beschriebener Problematik.
Die zentrale Variable der Heuristik ist die Qualität der Zusammenarbeit zwischen Kunden und Anbieter gemessen am Umgang mit Risiko und Veränderung. Selbstredend ist, dass sowohl Anbieter wie Kunde dazu ihren Beitrag leisten müssen.
Prämissen für moderne Software-Evaluation und Beschaffung
1. Prämisse: Wir starten ein Entwicklungsvorhaben mit Unsicherheiten (nicht ein Einführungsprojekt mit definiertem Zielzustand)
Organisation und Business-Software entwickeln sich während und nach der Einführung weiter. Es geht nicht darum, einen vorab definierten Zielzustand zu erreichen, sondern
- Veränderungen wie neue Erkenntnisse, neue Anforderungen leicht berücksichtigen zu können und
- Handlungsoptionen, d. h. einen genügend grossen Raum für situativ passende (und heute noch unbekannte) Lösungen zu schaffen.
Das erfordert Stabilität und Offenheit.
2. Prämisse: Wir suchen die Kooperation mit einem kompetenten Partner mit geeigneten Werkzeugen (statt nur eine Software)
Neben der fachlichen Kompetenz gehört auch der Umgang mit Unsicherheit und Veränderung dazu. (Einen nicht unerheblichen Teil meiner Arbeitszeit investiere ich in diesen Bereich bei System-Anbietern). Wir suchen nicht den besten Partner sondern einen geeigneten (Safe Enough to Try). Das nimmt den Druck, alles zu analysieren.
Partnerschaft bedeutet ehrliches Interesse einen Ausgleich zwischen den eigenen Bedürfnissen und denen des Partners zu finden. Das ist nicht gegeben, wenn der Anbieter für den definierten Umfang da und dort zusätzlichen Umsatz zu erzielen oder der Kunde für einen vereinbarten Preis so viele Anforderungen wie nur irgendwie möglich umgesetzt haben möchte. Und das ist die gängige Praxis in der traditionellen Software-Beschaffung.
3. Prämisse: Wir konzentrieren uns auf das, was für die Organisation am meisten Wert hat (und prüfen unsere Priorisierung laufend neu)
Es gilt zu verhindern, dass mit viel Engagement etwas umgesetzt wird, das nicht mehr oder anders benötigt wird, nur weil es einmal spezifiziert wurde. Wir spezifizieren so viel wie zum gegebenen Zeitpunkt nötig. D. h. in der Evaluation des Partners wird nur das spezifiziert, was für die Auswahl des Partners benötigt wird («Enough Design Upfront» statt «Big Design Upfront»).
(Die Idee zu diesen Bild stamm von Thomas Molitor)
Die Detailspezifikation wird jeweils mit dem System-Partner durchgeführt. Die direkte Kommunikation schafft mehr Klarheit.
Vorgehen für komplexe Software-Beschaffung (Partner-Evaluation)
1. Stelle ein kompetentes Team zusammen
Hier sind drei Faktoren zentral: Fertigkeiten und Fähigkeiten, Kapazität (echte auch gedankliche Verfügbarkeit) und Ermächtigung. Wir stimmen mit dem Auftraggeber im Detail ab, was das Team eigenständig entscheiden darf und was in welchem Umfang abzustimmen ist. Ein wirklich kompetentes Team kann viel selber entscheiden und ist somit in weiten Bereichen autonom.
Das Team führt durch die Evaluation und definiert dazu das Vorgehen. Es involviert die Stakeholder bei Bedarf z. B. um Anforderungen zu spezifizieren oder Feedback einzuholen.
2. Definiere den angestrebten Wertbeitrag des Vorhabens
Das sind priorisierte und gewichtete Geschäftsziele. Das Projektteam muss im Projekt schwierige Entscheidung treffen. Es braucht eine Vereinbarung wohin die Organisation optimieren möchte. Vorgaben wie «mehr Effizienz» oder «optimale Prozesse» geben keine Orientierung. Auch smarte Ziele (oder ähnlicher Unsinn) sind hier nicht gemeint. Es braucht ein gemeinsames Bild darüber, was als wertvoll angesehen wird.
Ist das nicht vorhanden, erarbeiten wir das mit Geschäftsleitung und Team. Das kann Zeit in Anspruch nehmen. Einer meiner Kunden stellte dabei fest, dass er sich vom klassischen Lieferanten zum Dienstleister in einer Kreislaufwirtschaft entwickelt. Ein andere stellte statt den Verkauf die Vermietung von Anlagen in den Mittelpunkt. Das ist elementar. Sonst rennt Ihr die in die falsche Richtung.
3. Ermittle die Kundenbedürfnisse
Um Kundenbedürfnisse ermitteln zu können, müssen Sie ihre Kunden involvieren. Hier gibt es verschiedene Herangehensweisen. Wir machen Stakeholder-Analyse und den ersten Anforderungsworkshop in einem. Anschliessend wird mit weiteren Stakeholdern so tief spezifiziert, wie es für die Evaluation des Software-Partners notwendig ist (Enough Design Upfront). Daraus ergeben sich Eignungskriterien für System-Anbieter, die später für die Recherche benötigt werden.
4. Baue Dein Risiko-Management auf
Dieser Punkt beinhaltet Themen wie Kostenstruktur (Budget, Konditionen), Zeitplan (Phasen, Roadmap, Checkpunkte), Verantwortungen, Prozesse (Inspektionen, Abnahmen, Eskalationsprozesse), Change Management und Risikoverteilung. In unseren Projekten werden Budget und Zeitplan in der Evaluation festgelegt. Das Scope bleibt veränderbar. Das ist wichtig um neue Anforderungen und neue Erkenntnisse einfliessen lassen zu können.
5. Bereite den Anbieter-Workshop vor
Das Team recherchiert möglich Anbieter (z. B. Internet-Recherche, Telefoninterviews). Drei favorisiert Anbieter werden zum Workshop eingeladen. Sie erhalten in kurzes Briefing, so dass sie verlässlich entscheiden können, welche Personen am Workshop benötigt werden. Denn sie ergänzen das bestehende Team des Kunden, wenn es zur Umsetzung kommt. Das Briefing ist kein detaillierte Ausschreibung. Denn im Anbieterworkshop testen wir die Zusammenarbeit mit dem System-Partner. Dazu müssen die Anforderungen unangetastet sein.
6. Führe den Anbieter-Workshop durch
Im Anbieter-Workshop geht das Team des Kunden zusammen mit dem Team des Anbieters die in den Schritten 1 bis 4 erarbeiteten Grundlagen durch und prüft, was der Anbieter dazu beitragen kann (meist in geänderter Reihenfolge):
- Was kann er zum Wertbeitrag des Vorhabens einbringen?
- Welche Kompetenzen bringt sein Team dafür mit?
- Wie gehen wir gemeinsam mit Risiken und Veränderungen um?
- Wie setzen wir die Kundenbedürfnisse um?
In Punkt vier wird mit der Umsetzung der am höchsten priorisierten Anforderungen begonnen. Zunächst wird die Spezifikation ergänzt. Dabei kann der Anbieter Fragen stellen. Er erhält unmittelbar Rückmeldung von den Fachpersonen. Es entsteht ein Dialog in dem die Spezifikation klarer wird und der Kunde Einblick in Konzepte und Bedienung der Business Software erhält. Zudem beginnen Themen wie Kompetenzen, Arbeitsweisen, Kommunikationsgewohnheiten und -bedürfnisse, Stärken und Schwächen sichtbar zu werden. Das ist wichtig. Dort wo dem Kunden etwas fehlt, muss der Anbieter ergänzen können und umgekehrt.
Im Workshop werden Details zu Budget, Zeitrahmen, Umfang der Anforderungen, Risikomanagement laufend ergänzt. Nach dem Workshop sind damit die Grundlagen für den Vertrag des Umsetzungprojekts im benötigten Umfang festgelegt (Fachleute für rechtliche Fragen werden von Anfang an involviert). Der Vertrag kann innerhalb weniger Tage fertiggestellt und unterzeichnet werden.
7. Hole Feedback ab und Entscheide
Bereits während des Workshops bewertet das Team die Zusammenarbeit mit den Kunden in verschiedenen Bereichen:
Nach dem Workshop sammelt es Feedbacks, gleicht diese ab und entscheidet, mit welchem Anbieter es die Umsetzung starten möchte. Neben den gesammelten Fakten spielt dabei die Intuition der Beteiligten eine wichtige Rolle. Wir arbeiten hier transparent. Die Anbieter kennen die Details der Entscheidung. Der Auftraggeber ist so involviert, dass eine schnelle Entscheidung möglich ist. Das Vorhaben wird nahtlos in die Umsetzung überführt. Das Team, das die Evaluation durchgeführt hat, ist auch für die Umsetzung zuständig.
Zur (Un)Sicherheit
Wir benötigen 4 bis 8 Wochen bis wir den geeigneten Partner gefunden haben. Anschliessend beginnt der Aufbau des neuen Systems (Sie erinnern sich: in der traditionellen Evaluation dauert es 6 bis 12 Monate um zu diesem Punkt zu kommen).
Ich werde häufig gefragt, ob in diese Zeit wirklich sicherer bestimmt werden, wer der richtige Software-Partner mit der richtigen Software-Lösung ist. Ich hoffe, dass diese drei Beiträge die Antwort klar genug geben: die traditionelle Software-Beschaffung mit umfassender Spezifikation und analytischem Ansatz schafft keine Sicherheit. Der für mich entscheidende Punkt ist jedoch ein anderer:
Angenommen nach 6 Wochen im Einführungsprojekt stellt sich heraus, dass die Zusammenarbeit zwischen Kunden und Systemanbieter nicht funktioniert (was, wenn man ehrlich ist, sein kann), dann können wir recht entspannt aussteigen. Wir haben gerade 10 Wochen investiert und noch keine Lizenzen gekauft. In einer traditionellen Evaluation hatten Sie dann mindestens 6 Monate u. U. gar mehr als Ein Jahr investiert. Viele Kunden tun sich dann schwer auszusteigen. Weil sie schon so viel investiert haben investieren sie weiter in etwas was nicht funktioniert (Sunk-Cost-Effekt, mentaler Investitionsschutz). Und das ist das weitaus grössere Drama.
Teil 1: Wieso die umfassende Produkt-Spezifikation hohe Risiken schafft
Teil 2: Über den Umgang mit Veränderungen in System-Evaluationen
