RFI, RFP und RFQ-Wahnsinn in der Supply Chain

Joannes Vermorel

Im Laufe der Jahre hat Lokad eine gewisse Bekanntheit erlangt und wir haben das Privileg erworben, an einer immer größeren Anzahl von RFI (Request for Information), RFP (Request for Proposal) und RFQ (Request for Quote) im Zusammenhang mit der Supply Chain-Optimierung beteiligt zu sein. Während ich dankbar bin, dass Lokad als “bemerkenswert genug” angesehen wird, um in diesen Initiativen in die engere Wahl zu kommen - und regelmäßig auch ausgewählt wird - kann ich nicht umhin, über den reinen Wahnsinn nachzudenken, der diesen Prozessen zugrunde liegt.

Ich habe mich schon lange über die bizarre Praktiken gewundert, die in der Welt der Unternehmenssoftware ¹ vorherrschen. Vor kurzem habe ich auch einen Ansatz vorgeschlagen, von dem ich fest überzeugt bin, dass er in jeder Hinsicht überlegen ist ². Heute möchte ich jedoch einige der absolut bizarren (wenn nicht sogar völlig verrückten) Elemente von RFPs beleuchten, die ich beobachtet habe. Kurz gesagt sind RFPs ³ Wissenschaftsgläubigkeit in Aktion. Eine Perspektive, eine Haltung und ein Prozess, die in den Augen eines breiten Publikums das widerspiegeln, was von einem “wissenschaftlichen” Unterfangen erwartet wird. In der Praxis sind RFPs jedoch genauso wissenschaftlich oder rational wie eine Séance.

Um anzufangen, die Fragenkataloge in RFPs sind ausnahmslos lang und unsinnig. Diese Dokumente sind immer das Ergebnis eines Ausschusses, der versucht, alle Fragen aufzulisten, an die jeder denken könnte, um alle zufriedenzustellen. Schlimmer noch, wenn Experten - in der Regel Berater - hinzugezogen werden, um die Liste zu überprüfen oder zu verbessern, wird der Fragenkatalog um eine Größenordnung aufgebläht.

Während das Sprichwort “Es gibt keine dummen Fragen” ein gültiges Leitprinzip für eine Grundschule sein mag, ist es schlichtweg schädlich, wenn es um ein großes Unternehmen und seine Supply Chain geht. Ganz offen gesagt können schlechte Fragen in der realen Welt Kosten in Form von verschwendeter Zeit, vergeudeter Aufmerksamkeit und teuren Kompromissen verursachen. Es gibt verschiedene Arten solcher Fragen ⁴, und im Folgenden werde ich sieben der häufigsten identifizieren und ihre Mängel erläutern.

• Faule Fragen. Beispiel: Entspricht die Lösung den Sicherheitsbest Practices? Diese Fragen verschwenden einfach nur die Zeit aller. Kein Anbieter von Unternehmenssoftware wird in seinem gesunden Menschenverstand jemals eine negative Antwort auf eine solche Frage geben.
• Dumme Fragen. Beispiel: Verwaltet die Lösung MOQ (Mindestbestellmengen)? Diese Fragen führen zu Verwirrung. Die Verwaltung von MOQs ist trivial; es ist die Optimierung in Anwesenheit von MOQs, die schwierig ist.
• “Schlaue” Fragen. Beispiel: Wie rationalisiert die Lösung Abweichungen von der ursprünglichen Planung bei Lagerbestandsausfällen? Ich nehme an, diese Fragen (scheinbar präzise, aber tatsächlich vage) sollen Kollegen beeindrucken, aber sie fügen nur eine zusätzliche Schicht von Verwirrung hinzu, die bald durch die ebenso blumige Antwort des Softwareanbieters verstärkt wird.
• Fangfragen. Beispiel: Bietet die Lösung die Möglichkeit, Saisonalitäts-Profile zu verwalten und anzupassen? Diese Fragen beeinflussen die Neutralität des Prozesses und werfen zusätzliche implizite Fragen auf. Die Beispielfrage legt nahe, dass Saisonalität durch “Profile” angegangen werden sollte (warum?) und dass Endbenutzer involviert sein sollten (warum?).
• Mehrdeutige Fragen. Beispiel: Ermöglicht die Lösung die Einführung von KPIs? Diese Art von Frage verstärkt Missverständnisse. Was ein KPI (Key Performance Indicator) ist, liegt im Auge des Betrachters; der Anbieter und der Kunde werden in dieser Hinsicht wahrscheinlich nicht die gleichen Ansichten teilen.
• Nebenfragen. Beispiel: Kann die Lösung ihre Auffüllungs-Vorschläge in Echtzeit neu berechnen? Diese Anfragen dienen dazu, von Kernfragen abzulenken. Die Vorstellung von “Echtzeit” im Bereich der verteilten Unternehmenssoftware beinhaltet lange, übermäßig technische Diskussionen, die letztendlich irrelevant sind, wenn die Auffüllungszahlen von Anfang an fehlerhaft sind.
• Beängstigende Fragen. Beispiel: Ist die Lösung nach ISO/IEC 27001 zertifiziert? Solche Fragen geben den falschen Parteien Macht. Zertifizierungen in der Unternehmenssoftware geben Zertifizierungsstellen und ihrem Ökosystem Macht, bringen der Kundenfirma jedoch absolut keinen Mehrwert.

Es ergibt genauso wenig Sinn, den richtigen Anbieter auszuwählen, indem man die falschen Fragen stellt, wie zu erwarten, dass eine Berechnung korrekt ist, wenn falsche Anfangszahlen verwendet werden. Dennoch scheint dies der Ansatz zu sein, den die meisten großen Unternehmen bei Unternehmenssoftware verfolgen.

Um die Sache noch schlimmer zu machen, enthalten viele RFPs eine “Compliance”-Spalte - oder etwas Ähnliches - neben der “Antwort”-Spalte, in der der Anbieter aufgefordert wird, seinen eigenen Grad der Übereinstimmung mit der Frage selbst zu diagnostizieren. Die Vorstellung, dass ein Softwareprodukt mit einer Frage “konform” sein könnte, ist verwirrend. In der Praxis sind RFP-Fragen jedoch so voller Vorurteile, dass die “Compliance”-Spalte in einer seltsamen, verdrehten Weise durchaus Sinn ergibt.

Ich möchte auch darauf hinweisen, dass (fast?) alle RFP-Dokumente in ihrer eigenen Präsentation eine ziemlich brutale Sorglosigkeit widerspiegeln. Jeder Absatz enthält schreckliche Rechtschreibfehler. Es gibt doppelte Fragen und doppelte Fragenummern. Die Schriftgröße wechselt unschön von 6 auf 20 und willkürliche Zeilenumbrüche verschandeln das Dokument. Was die Fragen betrifft, so sind RFPs in der Regel als Microsoft Excel-Tabellen formatiert - verteilt auf mehrere Registerkarten, versteht sich, von denen jede ihre eigenen “Frage” und “Antwort”-Spalten hat, sowie ein paar andere zur Sicherheit (wie das oben genannte “Compliance”-Beispiel). Das Tabellenformat ergibt im Zusammenhang mit einem RFP überhaupt keinen Sinn. Die Benutzererfahrung - sei es das Schreiben oder Lesen eines mehrzeiligen Inhalts in einer Tabellenzelle - ist miserabel, vor allem wenn es Hunderte von Fragen gibt, wie es in der Regel der Fall ist.

Als ob das nicht genug wäre, bedenken Sie, dass E-Procurement-Tools, die häufig für diese Farce verwendet werden, in der neunten Hölle geschmiedet wurden. Diese Tools repräsentieren die schlimmsten Inkarnationen von Unternehmenssoftware, wobei jedes einzelne Pionierarbeit leistet, um die Erwartungen zu senken: unresponsives, schlampiges Design, sinnlose Benutzererfahrung und mit Tolkien-Länge ungelöster Fehler behaftet. Durch den Einsatz solcher E-Procurement-Tools wird der bürokratische Wahnsinn auf elf hochgedreht.

Es ist naiv zu glauben, dass die Form belanglos ist, solange es Substanz gibt. Die Form eines RFPs, so schrecklich sie auch sein mag, stellt sicher, dass das Eintauchen in die Fragen, geschweige denn die Antworten, eine massive Zeitverschwendung ist. Als Ergebnis ziehen sich diejenigen, die den Auswahlprozess leiten sollten - Führungskräfte wie der Supply Chain Director - zurück und delegieren an “Experten” wie Einkaufsleiter oder Dritte. Einkaufsleiter haben in der Regel wenig Einblick in das, was für ihr eigenes Unternehmen eine vernünftige Lösung darstellt. In der Zwischenzeit sind Dritte, die als Facilitatoren des RFPs eingeführt werden, darauf ausgerichtet, das Unternehmen so labyrinthisch wie möglich zu gestalten.

Manche mögen argumentieren, dass ein RFP ein geringeres Übel ist im Vergleich zur offensichtlichen Bestechung, die in seiner Abwesenheit stattfinden würde. Mit anderen Worten, RFPs, so fehlerhaft sie auch sein mögen, bleiben die sicherste Option, um die Integrität des Unternehmens und seines Auswahlprozesses zu wahren. Dies ist jedoch eine außergewöhnliche Behauptung und erfordert daher außergewöhnliche Beweise. Tatsächlich wirft es Fragen auf, welche Art von Betrug RFPs verhindern sollen und wie effektiv sie in dieser Mission sind. Ehrlich gesagt scheint die Idee, einen großen Auswahlprozess durch eine ebenso große und willkürliche Tabelle zu kanalisieren, den Prozess “ehrlicher” zu machen, auf den ersten Blick ziemlich weit hergeholt. (Entschuldigen Sie meine Skepsis.)

Meine eigenen beobachtenden Beobachtungen der Unternehmenssoftwarewelt zeigen, dass viele große Softwareanbieter Menschen großzügig belohnen, die früher in einflussreichen Positionen im Zusammenhang mit RFPs standen, indem sie sie ein Jahrzehnt später einstellen. Das Gegenmittel gegen diese (schlechte) Praxis ist einfach: Identifizieren Sie Anbieter, die dieses Spiel spielen, und verbieten Sie sie vollständig ⁵. Realistisch gesehen tun RFPs nichts gegen die Art von vorausschauender Bestechung, die in der Welt der Unternehmenssoftware existiert.

Daher lautet meine Analyse wie folgt: Alles, was den Anbieterauswahlprozess bürokratischer macht, als es strikt erforderlich ist, macht den Prozess anfälliger für bösartige Akteure. Diese Aussage kann aus einer Perspektive der Computersicherheit umformuliert werden: Bürokratie erhöht die Angriffsfläche des Anbieterauswahlprozesses, da sie das Vertrauen (und damit die Verwundbarkeit) über Schichten von Personen verteilt, denen in Bezug auf diesen Prozess kein Vertrauen entgegengebracht werden sollte.

Trotz all dieser Probleme sind RFPs in der Unternehmenssoftware weit verbreitet. Doch privat geben die meisten Menschen - zumindest diejenigen, die nicht von RFPs leben - zu, dass der Prozess wenig Sinn ergibt, was die Verbreitung von RFPs umso rätselhafter macht. Die einfachste Erklärung, die ich finden kann, ist, dass RFPs eine ausgeklügelte Form des Unternehmens-“Virtue Signaling” sind ⁶. Im Zeitalter der Informationstechnologien ist es nicht akzeptabel und wird als einfach, unsophistiziert und geradezu unwissenschaftlich wahrgenommen, eine wichtige Entscheidung allein auf der Grundlage einer fundierten Vermutung zu treffen. Der RFP-Prozess mag für das Unternehmen keinen Mehrwert bringen, aber er adressiert gründlich den Aspekt des “Virtue Signalings”.