Es ist kaum möglich, in einem RFP-Prozess eine wirklich gute und objektive Auswahl zu treffen. Wie kann das besser sein?
Erkennbar?
Haben Sie jemals einen RFP-Verlauf festgelegt? Sie hatten den Wunsch, ein digitales Produkt entwickeln zu lassen, und da dies mit viel Arbeit verbunden war, wollten Sie eine umfangreiche Auswahl an IT-Anbietern treffen. Um die gewünschte Qualität auszuwählen, aber sicherlich auch um finanziell verantwortungsbewusste Entscheidungen treffen zu können.
Sie starten kein RFP-Projekt unvorbereitet. Um den Lieferanten Klarheit über das zu entwickelnde Produkt zu geben, müssen viele Informationen gesammelt werden. Dies sind oft die Anforderungen und Wünsche der Organisation. Manchmal geht man etwas weiter und holt sich seine Wünsche vom Markt. Glücklicherweise achten einige Organisationen auch auf die beabsichtigten Benutzer.
Rauszoomen
Wenn Sie mit guten Absichten ein RFP-Projekt durchführen, dann haben Sie jetzt gesammelt, was der IT-Anbieter entwickeln soll. Doch wie die Lösung aussehen soll, weiß noch niemand
Die Angebote
Sie haben den RFP-Prozess verfolgt und die Fragen sind bei den IT-Anbietern. Glücklicherweise haben Sie sich etwas Zeit genommen, damit sich die Bieter kennenlernen und Fragen und Möglichkeiten individueller besprechen können (ein ziemlicher Schmerzpunkt in Ausschreibungsverfahren). Wo nötig, haben Sie Fragen mit den anderen Anbietern geteilt, damit alle möglichst die gleichen Informationen haben. Du teilst die Fragen mit den anderen Anbietern, damit alle so viele Informationen wie möglich haben.
Sie erhalten zum Einsendeschluss fünf Angebote. Fünf IT-Lieferanten haben viel Zeit und Aufmerksamkeit darauf verwendet, auf Ihre Ausschreibung bestmöglich zu reagieren. Sie werden vier von ihnen enttäuschen und Ihnen für diese Mühe danken. Aber wen wählen Sie jetzt aus?
Die Verlierer verbringen manchmal Wochen mit der Beantwortung einer Ausschreibung. Und diese Zeit werden sie nie zurückbekommen.
Wahrscheinlich passiert jetzt 1 von 3 Dingen:
- Es gibt eine Partei, die eindeutig die billigste ist. Sie entscheiden sich für diese Partei, weil zwischen ihr und der Nummer 2 ziemlich viel finanzieller Spielraum ist. Sie erkennen, dass es noch etwas Spielraum gibt, wenn noch mehr Arbeit zu erledigen ist. Diese Partei hat sich wahrscheinlich eingekauft. Während des Prozesses verbringen Sie viel Zeit mit (ablenkenden) Gesprächen über zusätzliche Arbeiten. Der endgültige Preis wird wahrscheinlich höher sein als die von anderen Parteien eingereichten Preise.
- Bei allem, was man dafür bekommt, hat man Mühe, einen guten Vergleich anzustellen. Die einfache Auswahl macht Ihnen Sorgen, deshalb werden Sie zusätzliche Schritte in den Auswahlprozess einbauen. Mit 2 oder 3 Parteien gehen Sie noch weiter in die Tiefe. Ihre Flugbahn wird viel komplexer und dauert viel länger als Sie ursprünglich dachten.
- Preislich gibt es große Unterschiede, aber auch Qualitätsunterschiede. Eine gute, erfahrene Partei hat reagiert, ist aber auch die teuerste. Vielleicht teurer als ursprünglich budgetiert. Dies liegt daran, dass diese Partei versteht, dass noch vieles unbekannt ist und dass eine Unsicherheitsmarge/Risikoprämie kein unnötiger Luxus ist. Da Sie Ihr Budget überschreiten, müssen Sie nach mehr Budget suchen.
Rauszoomen
Die meisten IT-Lieferanten arbeiten agil (aus gutem Grund). Und es ist nicht klar, wie genau die Lösung aussehen soll. Logisch, dass noch viel Unsicherheit besteht! Nicht nur bei den Lieferanten. Sie haben die gleichen Bedenken: Werde ich mit all dem Geld, das ich ausgeben werde, am Ende haben, was ich wollte?
Vergessen Sie nicht die versteckten Kosten. Der von Ihnen in den Prozess eingebundene Berater, der nun mehrere Monate länger an der RFP arbeitet. Ihre eigenen Kollegen, die noch eingebunden werden müssen, um die Ausschreibung zu einem erfolgreichen Abschluss zu bringen. Der Zeitverlust, durch den sich Ihre Time-to-Market (und damit der angestrebte Wert, den Sie realisieren wollten) immer weiter hinauszögert.
Beginn des Projekts
Die Auswahl ist beendet! Der IT-Lieferant kann loslegen. Er beginnt mit einer ausgiebigen Analysephase, denn vieles weiß er noch nicht. Er will sich ein gutes Bild von der bestehenden IT-Architektur machen und er unternimmt Schritte, um zu einer Lösung zu gelangen, die allen Anforderungen und Wünschen entspricht.
Hier kommt das „Wie“ ins Spiel. Wie wirkt das Produkt eigentlich? Welches Konzept steckt dahinter? Wir wissen vielleicht, welche Funktionalitäten benötigt werden, aber wie funktionieren sie genau? Da die Lösung immer noch auf 100 Wegen erarbeiten kann, ist es wichtig, möglichst schnell den einen gewünschten Weg zu finden.
In vielen Fällen sind hier IT-Leute am Ruder. Der Lieferant verwendet eine bevorzugte Technologie, die einen großen Teil davon bestimmt, wie das Produkt aussehen wird. Vieles wird in Richtung dieser Technologie argumentiert werden. Völlig gültig. Aber ist das auch die beste Lösung?
Was, wenn..
Was ist, wenn Sie das Projekt starten, wo Sie ein klares Bild davon bekommen, wie die IT-Architektur aussieht, aber vor allem, wie die gewünschte Lösung aussieht, was, wenn Sie sie in den Vordergrund rücken?
Was wäre, wenn Sie diese Analyse und die Übersetzung in die Lösung unter der Leitung Ihres Unternehmens (wo es hingehört) und unabhängig von der zu wählenden Technologie durchführen lassen? Natürlich sollten keine Dinge erfunden werden, die nicht gebaut werden können, aber die Technologie sollte nicht führend sein.
Wenn Sie die Analyse und Übersetzung vorziehen, stellen Sie einen Teil des Projekts vor die Ausschreibung. Und das von Profis, die viel Erfahrung in der Konzeption haben, ergänzt durch einen IT-Architekten, der die aktuelle IT-Architektur abbildet.
In der agilen Arbeitsweise haben Sie dafür sogar ein Mittel: die Discovery-Phase. Wo es oft von IT-Lieferanten genutzt wird, um alle technischen Informationen an die Oberfläche zu bringen, kann eine Discovery-Phase auch sehr gut genutzt werden, um das zu entwickelnde Produkt deutlich übersichtlicher zu gestalten.
Was hast du?
Indem Sie einen Schritt im Prozess vorziehen, haben Sie jetzt viel mehr Informationen darüber, was die beabsichtigte Lösung ist, bevor Sie die RFP deaktivieren. Und wo die Entwicklungsherausforderungen liegen. Weil diese beabsichtigte Lösung gegen die bestehende IT-Architektur beibehalten werden kann.
Infolgedessen gibt es viel weniger Unsicherheit im Projekt. Das bedeutet niedrigere Angebote, aber auch Angebote, bei denen viel weniger Platz für unvorhergesehene Zusatzarbeiten benötigt wird.
Darüber hinaus ist die Qualität des Endprodukts in den meisten Fällen viel höher. Denn IT-Lieferanten können sehr gut entwickeln, aber nicht immer eine Lösung aus Anforderungen und Wünschen herausholen.
