RFI, RFP und RFQ Wahnsinn in supply chain

Joannes Vermorel

Im Laufe der Jahre hat Lokad etwas Bekanntheit erlangt, und wir haben das Privileg, an einer immer größeren Anzahl von RFI (request for information), RFP (request for proposal) und RFQ (request for quote) im Zusammenhang mit supply chain Optimierung beteiligt zu sein. Während ich dankbar bin, dass Lokad als bemerkenswert genug angesehen wird, um auf die Shortlist dieser Initiativen zu kommen – und routinemäßig auch ausgewählt wird – kann ich nicht umhin, über den schieren Wahnsinn nachzudenken, der diesen Prozessen zugrunde liegt.

Ich war schon lange von den bizarren Praktiken, die im Bereich enterprise software ¹ vorherrschen, ratlos. Kürzlich habe ich zudem einen Ansatz vorgeschlagen, von dem ich fest davon überzeugt bin, dass er in jeder Hinsicht den gängigen Ansätzen ² überlegen ist. Heute möchte ich jedoch einige der, ehrlich gesagt, bizarren (wenn nicht gar völlig wahnsinnigen) Elemente von RFPs, die ich beobachtet habe, näher erläutern. Kurzum, RFPs ³ sind Wissenschaftsfanatismus in Aktion. Eine Perspektive, eine Einstellung und ein Prozess, der in den Augen des allgemeinen Publikums nachahmt, wie ein „wissenschaftliches“ Unterfangen zu sein hat. In Wirklichkeit sind RFPs jedoch so wissenschaftlich oder rational wie eine Séance.

Zunächst einmal sind die in RFPs gesammelten Fragenlisten ohne Ausnahme sowohl lang als auch unsinnig. Diese Dokumente sind stets das Produkt eines Gremiums, das versucht, es jedem recht zu machen, indem es alle Fragen auflistet, die einem nur einfallen könnten. Schlimmer noch, wann immer Experten – typischerweise Berater – hinzugezogen werden, um die Liste zu überprüfen oder zu verbessern, wird der Fragenkatalog um ein Vielfaches aufgebläht.

Auch wenn das Sprichwort es gibt keine dummen Fragen vielleicht ein gültiges Leitprinzip für die Grundschule ist, ist es geradezu schädlich, wenn es um ein großes Unternehmen und seine supply chain geht. Einfach ausgedrückt können schlechte Fragen in der realen Welt Kosten in Form von verschwendeter Zeit, fehlgeleiteter Aufmerksamkeit und teuren Kompromissen verursachen, um Gefühle zu schonen. Es gibt mehrere Kategorien solcher Fragen ⁴, und im Folgenden werde ich sieben der häufigsten nennen und ihre Schwächen darlegen.

• Faule Fragen. Beispiel: Folgt die Lösung den Sicherheits-Best-Practices? Diese Fragen verschwenden einfach jedermanns Zeit. Kein Anbieter von Enterprise-Software im Vollbesitz seiner geistigen Kräfte wird jemals eine negative Antwort auf eine solche Frage geben.
• Dumme Fragen. Beispiel: Verwaltet die Lösung MOQ (minimal order quantities)? Diese Fragen führen zu Verwirrung. Das Management von MOQs ist trivial; es ist jede Art von Optimierung im Vorhandensein von MOQs, die schwierig ist.
• „Schlaue“ Fragen. Beispiel: Wie rationalisiert die Lösung Abweichungen in der Prognose gegenüber dem ursprünglichen Plan bei gleichzeitigen Stockouts? Ich vermute, diese Fragen (scheinbar präzise, aber tatsächlich vage) sollen Kollegen beeindrucken, fügen jedoch lediglich eine zusätzliche Ebene der Verwirrung hinzu, die bald durch die ebenso blumige Antwort des Softwareanbieters noch verstärkt wird.
• Suggestivfragen. Beispiel: Bietet die Lösung die Möglichkeit, seasonality Profile zu verwalten und anzupassen? Diese Fragen beeinträchtigen die Neutralität des Prozesses und werfen zusätzliche, implizite Fragen auf. Die Beispiel-Frage impliziert, dass seasonality durch „Profile“ angegangen werden sollte (warum?) und dass Endanwender einbezogen werden sollten (warum?).
• Mehrdeutige Fragen. Beispiel: Ermöglicht die Lösung die Einführung von KPIs? Diese Kategorie von Fragen verschärft Missverständnisse. Was einen KPI (key performance indicator) ausmacht, liegt im Auge des Betrachters; Anbieter und Kunde werden diesbezüglich kaum übereinstimmende Auffassungen haben.
• Randständige Fragen. Beispiel: Kann die Lösung ihre replenishment Vorschläge in Echtzeit neu berechnen? Diese Anfragen lenken von den Kernproblemen ab. Der Begriff „Echtzeit“ im Bereich verteilter Enterprise-Software impliziert lange, übermäßig technische Diskussionen, die letztlich irrelevant sind, wenn die replenishment Zahlen von Anfang an Müll sind.
• Angsteinflößende Fragen. Beispiel: Ist die Lösung nach ISO/IEC 27001 zertifiziert? Solche Fragen geben den falschen Parteien Rückhalt. Zertifizierungen in Enterprise-Software verleihen den Zertifizierungsstellen und ihrem Ökosystem Macht, während sie für das Kundenunternehmen absolut keinen Mehrwert bieten.

Zu erwarten, dass der richtige Anbieter ausgewählt werden kann, indem man die falschen Fragen stellt, ist genauso sinnvoll wie zu erwarten, dass eine Berechnung korrekt ist, obwohl falsche Ausgangszahlen verwendet werden. Dennoch scheint dies der bevorzugte Ansatz zu sein, den die meisten großen Unternehmen in Bezug auf Enterprise-Software verfolgen.

Zu allem Überfluss enthalten viele RFPs eine Spalte „Compliance“ – oder etwas in der Art – neben der Spalte „Answer“, in der der Anbieter gebeten wird, seinen eigenen Grad an Übereinstimmung mit der Frage selbst zu diagnostizieren. Die Vorstellung, dass ein Softwareprodukt mit einer Frage konform sein könnte, ist verblüffend. In der Praxis sind RFP-Fragen jedoch derart von Vorurteilen durchzogen, dass die „Compliance“-Spalte in gewisser Weise doch Sinn macht, wenn auch auf eine bizarre, verdrehte Art.

Ich sollte auch darauf hinweisen, dass (fast?) alle RFP-Dokumente in ihrer Darstellung einen ziemlich eklatanten Mangel an Sorgfalt widerspiegeln. Jeder Absatz enthält abscheuliche Rechtschreibfehler. Es gibt doppelte Fragen und doppelte Fragennummern. Die Schriftgröße wechselt ungeschickt von 6 auf 20, und willkürlich eingefügte Zeilenumbrüche durchziehen das Dokument. Was die Fragen betrifft, ist es noch schlimmer, da RFPs typischerweise als Microsoft Excel-Tabellen formatiert sind – verteilt über mehrere Tabs, wobei jede ihren eigenen „Question“- und „Answer“-Spalten hat, plus noch ein paar weitere Spalten (wie das oben genannte „Compliance“-Beispiel). Das Tabellenformat ergibt im Kontext eines RFPs absolut keinen Sinn. Die Benutzererfahrung – sei es beim Verfassen oder Lesen eines mehrzeiligen Textabschnitts innerhalb einer Tabellenzelle – ist miserabel; umso mehr, wenn es hunderte von Fragen gibt, wie es in der Regel der Fall ist.

Als ob das noch nicht genug wäre, bedenkt man, dass e-Procurement-Tools, die häufig für diese Farce verwendet werden, im 9. Kreis der Hölle geschmiedet wurden. Diese Tools repräsentieren die schlimmsten Ausprägungen von Enterprise-Software, wobei jedes von ihnen Wege aufzeigt, die Erwartungen zu senken: unresponsive, schlampiges Design, inane Benutzererfahrung und beladen mit Tolkien-großen Rückständen unfertiger Bugs. Durch den Einsatz solcher e-Procurement-Tools wird der bürokratische Wahnsinn auf Hochtouren hochgefahren ⁵.

Es ist naiv zu glauben, dass die Form nebensächlich ist, solange Substanz vorhanden ist. Die Form eines RFP, so grausam sie auch ist, stellt sicher, dass das Eintauchen in die Fragen – geschweige denn in die Antworten – ein enormer Zeitfresser ist. Infolgedessen treten die Personen, die den Auswahlprozess eigentlich anführen sollten – Führungskräfte wie der supply chain director – zurück und delegieren an „Experten“, wie beispielsweise Einkaufsleiter oder Dritte. Einkaufsleiter haben in der Regel wenig Einblick darin, was für ihr eigenes Unternehmen eine vernünftige Lösung darstellt. In der Zwischenzeit werden Dritte, die als Vermittler des RFP eingeführt werden, dazu angereizt, das Vorhaben so labyrinthartig wie möglich zu gestalten.

Manche könnten argumentieren, dass ein RFP das geringere Übel im Vergleich zur offenen Bestechung darstellt, die ohne ihn stattfinden würde. Mit anderen Worten, RFPs bleiben, so fehlerhaft sie auch sein mögen, die sicherste Option, um die Integrität des Unternehmens und seines Auswahlprozesses zu wahren. Dies ist jedoch eine ziemlich außergewöhnliche Behauptung, die folglich außergewöhnliche Beweise erfordert. In der Tat wirft dies Fragen hinsichtlich der Art von Betrug auf, den RFPs verhindern sollen, und folglich, wie effektiv sie in dieser Mission sind. Offen gesagt erscheint die Idee, einen großen Auswahlprozess durch eine ebenso große und willkürlich zusammengestellte Tabelle zu leiten, als würde dies den Prozess „ehrlicher“ machen, auf den ersten Blick ein ziemlicher Kraftakt. (Verzeihen Sie meinen Skeptizismus.)

Meine eigenen anekdotischen Beobachtungen in der Welt der Enterprise-Software deuten darauf hin, dass viele große Softwareanbieter großzügig Personen belohnen, die früher in einflussreichen Positionen, was RFPs betrifft, waren, indem sie diese ein Jahrzehnt später anstellen. Das Gegenmittel zu dieser (Miss)praxis ist einfach: Identifizieren Sie Anbieter, die dieses Spiel spielen, und verbannen Sie sie gänzlich ⁶. Realistisch gesehen unternehmen RFPs nichts gegen die Art von zukunftsweisender Bestechung, die in der Welt der Enterprise-Software existiert.

Meine Analyse lautet daher: Alles, was den Auswahlprozess des Anbieters bürokratischer macht, als es unbedingt notwendig wäre, macht den Prozess wiederum anfälliger für böswillige Akteure. Diese Aussage lässt sich aus der Perspektive der Computersicherheit so umformulieren: Bürokratie vergrößert die Angriffsfläche des Auswahlprozesses, da das Vertrauen (und somit die Verwundbarkeit) auf Schichten von Personen verteilt wird, denen im Rahmen dieses Prozesses kein Grund zur Vertrauenswürdigkeit gegeben ist.

Trotz all dieser Probleme sind RFPs in der Enterprise-Software weit verbreitet. Doch im privaten Kreis geben die meisten – zumindest diejenigen, die nicht ihren Lebensunterhalt mit RFPs verdienen – zu, dass der Prozess wenig Sinn ergibt, was die Verbreitung von RFPs umso rätselhafter macht. Die einfachste Erklärung, die mir einfällt, ist, dass RFPs eine aufwendige Form des Corporate virtue signaling ⁷ sind. Im Zeitalter der Informationstechnologien ist es inakzeptabel zuzugeben, dass eine wichtige Entscheidung auf nichts weiter als einer fundierten Vermutung basieren kann, und wird als simpel, wenig anspruchsvoll und geradezu unwissenschaftlich empfunden. Der RFP-Prozess mag für das Unternehmen keinen echten Mehrwert bringen, aber er spricht den Aspekt des virtue signaling ausführlich an.