Drei Anbieter offerieren für dasselbe Ersatzsystem. Die Zahlen unterscheiden sich um den Faktor vier, und keiner der drei lügt. Sie beantworten verschiedene Fragen, weil ihnen niemand gesagt hat, welche Frage genau zu beantworten ist. Diese Lücke ist kein Beschaffungsfehler und kein Verhandlungsfehler. Sie ist ein Architekturfehler, und sie war Monate vor der Ausschreibung eingepreist.
Der Preis steht lange vor der Ausschreibung fest
Wenn die Offerte eintrifft, ist der grösste Teil des Preises längst entschieden. Entschieden hat ihn, wie genau die einkaufende Organisation sagen kann, was sie braucht, woran das neue System andocken muss, welche Daten ihr gehören und was “fertig” heissen wird. Ein Anbieter, der gegen einen klaren Umfang kalkuliert, kalkuliert eine bekannte Grösse. Ein Anbieter, der gegen einen unklaren kalkuliert, kalkuliert Risiko, und Risiko ist teuer.
Deshalb können drei ehrliche Offerten in vielen Organisationen um den Faktor vier auseinanderliegen. Jeder Anbieter hat die Lücken im Briefing mit eigenen Annahmen gefüllt und dann für die Annahmen aufgeschlagen, die er nicht prüfen konnte. Niemand ist dabei zynisch. Sie bepreisen die Unsicherheit, die man ihnen gegeben hat.
Der Anbieter hat oft als Einziger den Gesamtüberblick
Das tiefere Problem ist nicht der einzelne Einkauf. Nach einigen Jahren dieser Art zu kaufen ist der Anbieter oft die einzige Partei mit einem zutreffenden Bild davon, wie die Landschaft tatsächlich zusammenhängt. Er weiss, welche Schnittstelle die Lohnbuchhaltung wirklich nutzt, welchen nächtlichen Job niemand abzuschalten wagt und welche zwei Dienste still von einem Feld abhängen, das eigentlich provisorisch sein sollte.
Diese Asymmetrie ist kein Nebeneffekt der Beziehung. Sie ist die Beziehung. Sie setzt den Preis des nächsten Upgrades, sie entscheidet, wie glaubwürdig ein Konkurrenzangebot sein kann, und sie bestimmt, was ein Wechsel kosten würde. Nichts davon erscheint als Position auf einer Rechnung, und genau deshalb wird sie nicht gesteuert.
KI hat die Mitte verbilligt und damit den Hebel verschoben
Zwanzig Jahre lang war das Knappe in der Software die Lieferkapazität. Anbieter verkauften Kapazität, und die Beratung gleich mitzukaufen wirkte wie ein vernünftiger Weg, eine knappe Ressource auf das eigene Problem zu richten.
Diese Knappheit hat sich aufgelöst. Anforderungen entwerfen, eine Architektur skizzieren, Integrationscode schreiben, eine Regressionssuite pflegen und inzwischen auch die Teile eines Systems erkunden, die niemand spezifiziert hat, ist innerhalb von etwa zwei Jahren schneller geworden. Wir arbeiten täglich mit diesen Werkzeugen und sie sind gut darin, und genau das ist der Punkt: Wenn sie für uns gut sind, sind sie für Ihren Anbieter genauso gut, und die Kapazität, die den Aufschlag rechtfertigte, ist nicht mehr knapp.
Nicht günstiger geworden ist, zu wissen, wonach man fragen muss, und zu wissen, ob man es bekommen hat. Das Urteil über die eigene Landschaft, die eigene regulatorische Exposition, die eigenen Daten und darüber, was in fünf Jahren noch stimmen muss, lässt sich nicht komprimieren. Der Hebel ist also von der Mitte des Projekts an seine beiden Enden gewandert.
Ein erster Durchgang ist Umfang, nicht Spezifikation
Das vordere Ende ist kleiner, als die meisten erwarten, und es ist der Teil, der am häufigsten übersprungen wird, weil er aussieht, als brauche er ein Jahr.
Das tut er nicht. Was eine Kaufentscheidung braucht, ist Umfang: eine aktuelle Fähigkeitskarte, die wenigen Integrationen, die wirklich tragend sind, die Funktionen, die den Business Case tragen, im Unterschied zu denen, die es auf die Wunschliste geschafft haben, die Daten und ihre Rechtsordnung, und die Fähigkeiten, die Ihr eigener Fachbetrieb braucht, um mit dem Ergebnis zu leben. Nach unserer Erfahrung genügen zwei Wochen, um die Punkte zu verbinden, wenn die richtigen Leute verfügbar und im Raum sind. Diese Bedingung ist die eigentliche Einschränkung, nicht die Methode.
Umfang ist nicht die vollständige Spezifikation und soll nicht so tun. Die Detailarbeit gehört zu dem Anbieter, für den Sie sich am Ende entscheiden, und das ist in Ordnung, denn dann spezifizieren Sie aus einer bekannten Position heraus statt aus einer leeren. Der erste Durchgang hat drei Aufgaben: dafür sorgen, dass drei Anbieter dasselbe offerieren, Ihnen sagen, welche Produkte Sie tatsächlich einkaufen müssen, und Ihnen sagen, welche Fähigkeiten Sie danach selbst halten müssen, im Fachbetrieb wie im technischen Betrieb.
Das ist gewöhnliche TOGAF- und IREB-Praxis, bewusst früh und bewusst flach gefahren. Neu ist daran nichts. Neu ist, dass Erstellung und Pflege günstig genug geworden sind, dass eine mittelgrosse Organisation das halten kann, wo vor fünf Jahren die ehrliche Antwort lautete, dass sich das nur ein Konzern leisten kann.
Das Dokument, mit dem Sie kaufen, ist das Dokument, gegen das Sie abnehmen
Hier ist der Teil, der aus den beiden Enden eine Fähigkeit macht statt zweier Dienstleistungen.
Die Anforderung, die Sie für den Markt geschrieben haben, ist die Anforderung, an der Sie später die Lieferung messen. Einmal geschrieben, zweimal genutzt. Waren die Abnahmekriterien deutlich genug, um sie zu bepreisen, sind sie deutlich genug, um sie zu testen, und eine Regressionssuite ist die haltbare Form davon. Waren sie es nicht, wird die Abnahme zur Meinungssache, und die Meinung begünstigt zum Abnahmezeitpunkt immer die Partei, die im Code gelebt hat.
Das ist der praktische Grund, einem vagen Briefing zu widerstehen, mehr als jedes Prinzip über Sorgfalt. Ein vages Briefing kostet Sie nicht nur am Anfang Geld. Es kostet Sie am Ende die Möglichkeit, Nein zu sagen.
Die gängige Fassung dieser Geschichte: Software wird geliefert, dann werden die Anforderungen nachträglich rekonstruiert und die Tests rückwirkend zu Ende gebracht, weil niemand aufgeschrieben hatte, wogegen abgenommen wird. Diese Arbeit passiert ohnehin, nur zum schlechtestmöglichen Zeitpunkt, ohne Druckmittel, und sie endet oft mit einem Anbieterwechsel.
Die Abnahme gehört der Seite, die mit dem Ergebnis leben muss
Die förmliche Abnahme unterschreibt meist die Person, die am Meilenstein gemessen wird. Das ist die falsche Person, ohne eigenes Verschulden. Eine Projektleitung ist für ein Datum verantwortlich, und der ehrliche Anreiz am Ende eines verspäteten Projekts lautet: abnehmen und weitermachen.
Zwei andere Parteien müssen mit dem leben, was unterschrieben wird, und über sie wird regelmässig so gesprochen, als wären sie eine. Der Fachbetrieb ist die Kundin: die Organisation, die den Dienst für ihre eigenen Kunden betreibt, seine Kosten trägt, dafür gegenüber ihrem Regulator geradesteht und ihn mit der Zeit ändern lassen muss. Der technische Betrieb ist, wer das Ding danach am Laufen hält: die CVE patchen, das Backup zurückspielen und Nachweise liefern, wenn ein Auditor fragt. Das Erste ist immer die Kundin; das Zweite kann bei der Kundin liegen, bei uns oder beim Anbieter, je nachdem, was vertraglich vereinbart wurde. Keine der beiden Parteien sitzt üblicherweise im Raum, wenn das Abnahmeprotokoll unterschrieben wird.
Bei der Abnahme handeln wir für den Fachbetrieb: das ist die Seite, die die Abnahme schützen soll, und die Seite, die das Ergebnis noch Jahre nach Projektende trägt. Was dieses Urteil kaufenswert macht, ist die zweite Rolle: Wir betreiben Produktivsysteme selbst, wir wissen also, was eine Abkürzung in einer Schnittstelle oder ein fehlendes Runbook tatsächlich kostet, sobald das Projektteam weg ist. Das zu wissen ist nicht dasselbe wie die Partei zu sein, die damit leben muss, und wir achten darauf, beides nicht zu verwechseln.
In der Praxis ist es Abnahmetest gegen die expliziten Anforderungen, durchgeführt von unserer eigenen Testpraxis statt vom Lieferanten, der daran gemessen wird. Es ist eine unbequeme Rolle, jemanden dafür zu holen, und es ist die Rolle, die sich bei der ersten Zurückweisung bezahlt macht.
Wo das schiefgeht
Architektur schlecht ins Haus zu holen ist schlimmer, als es zu lassen. Eine Fähigkeitskarte, die niemand nachführt, ist ein Risiko, weil Menschen ihr vertrauen. Eine Architekturfunktion ohne Autorität über Kaufentscheidungen ist eine Dokumentationsübung, und das erste Projekt mit einem Termin wird sie umgehen.
Der Test ist unspektakulär, und er ist der, den man zuerst anlegen sollte. Können Sie einem konkurrierenden Anbieter einen Umfang übergeben, der genau genug ist, um dagegen zu offerieren, ohne Hilfe Ihres bisherigen Anbieters? Können Sie heute sagen, was Sie dazu bringen würde, die nächste Lieferung zurückzuweisen? Lauten beide Antworten Ja, ist die Fähigkeit da, und Ihre Preise werden es zeigen. Lautet eine Nein, dann ist genau das die Arbeit, ganz gleich, was das Diagramm an der Wand nahelegt.
Zwei Enden und eine Mitte
Ein Softwareprojekt hat drei Teile, die sich getrennt einkaufen lassen: entscheiden, was gebraucht wird, es bauen, und beurteilen, ob das Gelieferte dem Gebrauchten entspricht. Die meisten Organisationen kaufen alle drei beim selben Lieferanten und wundern sich dann, warum der dritte so grosszügig ausfällt.
Die Mitte ist der günstigste und am leichtesten vergleichbare Teil geworden. Die beiden Enden sind nicht günstiger geworden, und sie entscheiden darüber, was die Mitte kostet.
Besitzen Sie die Enden. Kaufen Sie die Mitte. Und halten Sie die Person, die die Abnahme unterschreibt, auf Ihrer Seite des Tisches.
