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 RFP (Request for Quote) im Zusammenhang mit der Supply Chain-Optimierung beteiligt zu sein. Während ich dankbar bin, dass Lokad als hinreichend bemerkenswert 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.

The Desperate, Gustave Courbet

Ich habe mich schon lange über die bizarre Praktiken gewundert, die in der Welt der Unternehmenssoftware 1 vorherrschen. Vor kurzem habe ich auch einen Ansatz vorgeschlagen, von dem ich fest überzeugt bin, dass er in jeder Hinsicht überlegen ist 2. 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 3 Wissenschaftsgläubigkeit in Aktion. Eine Perspektive, eine Haltung und ein Prozess, die in den Augen eines allgemeinen Publikums das widerspiegeln, was von einem “wissenschaftlichen” Unterfangen erwartet wird. In der Praxis sind RFPs jedoch genauso wissenschaftlich oder rational wie eine Séance.

Zunächst einmal sind die Fragenkataloge, die in RFPs gesammelt werden, ohne Ausnahme lang und unsinnig. Diese Dokumente sind in der Regel 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 der Ausspruch es gibt keine dummen Fragen ein gültiges Leitprinzip für eine Grundschule sein mag, ist er 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, um Gefühle zu schonen. Es gibt verschiedene Arten solcher Fragen 4, und im Folgenden werde ich sieben der häufigsten identifizieren und ihre Mängel skizzieren.

  • 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 Durchführung einer 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, dass diese Fragen (scheinbar präzise, aber tatsächlich vage) dazu dienen, Kollegen zu 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 beeinträchtigen 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.
  • Tangentialfragen. 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, zu erwarten, dass der richtige Anbieter ausgewählt werden kann, 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 konform mit einer Frage 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, ist es noch schlimmer, da RFPs in der Regel als Microsoft Excel Tabellenkalkulationen formatiert sind - auf mehreren Registerkarten verteilt, versteht sich, von denen jede ihre eigenen “Frage”- und “Antwort”-Spalten sowie ein paar weitere für alle Fälle hat (wie das oben genannte Beispiel “Compliance”). Das Tabellenkalkulationsformat ergibt im Zusammenhang mit einem RFP null Sinn. Die Benutzererfahrung - sei es das Schreiben oder Lesen eines mehrzeiligen Inhalts in einer Tabellenzelle - ist miserabel; umso mehr, 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 5.

Es ist naiv zu glauben, dass die Form belanglos ist, solange es Substanz gibt. Die Form eines RFPs, so schrecklich sie auch ist, 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 Beschaffungsmanager oder Dritte. Beschaffungsmanager 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 offenen 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 bewahren. 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 chaotische Tabelle zu lenken, um den Prozess “ehrlicher” zu machen, auf den ersten Blick ziemlich weit hergeholt zu sein. (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 waren, indem sie sie ein Jahrzehnt später einstellen. Das Gegenmittel gegen diese (un)gute Praxis ist einfach: Identifizieren Sie Anbieter, die dieses Spiel spielen, und verbieten Sie sie vollständig 6. Realistisch betrachtet tun RFPs nichts gegen die Art von zukunftsorientierter 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 aufwändige Form des Unternehmens-“Virtue Signaling” sind 7. Im Zeitalter der Informationstechnologien ist es nicht akzeptabel und wird als simplistisch, 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”.


  1. Ein Leitfaden für Unternehmenssoftwarekäufer, Joannes Vermorel, August 2013. ↩︎

  2. Adversarial Market Research für Unternehmenssoftware - Vorlesung 2.4, März 2021, Joannes Vermorel ↩︎

  3. Der Begriff “RFP” bezieht sich in diesem Eintrag kollektiv auf RFI, RFP und RFQ, um die Kürze zu wahren. ↩︎

  4. Alle in diesem Abschnitt aufgeführten Beispiele sind echte RFP-Fragen, die wir im Laufe der letzten 12 Monate erhalten haben. ↩︎

  5. Als Faustregel gilt, dass sowohl Lokad als auch potenzielle Kunden bei Vorhandensein eines E-Procurement-Tools mehrere Mann-Tage damit verschwenden, das Äquivalent des Versendens einer E-Mail mit einem PDF-Anhang an 5 Empfänger in CC zu erledigen. ↩︎

  6. LinkedIn macht es relativ einfach, Softwareanbieter zu identifizieren, die Menschen einstellen, die bequemerweise zur “richtigen Zeit am richtigen Ort” waren. Allerdings macht es die Offenlegung aller relevanten Informationen noch raffinierter, da sie nicht einmal explizite Kommunikation zwischen den Parteien erfordert, sondern lediglich ein stillschweigendes Verständnis. ↩︎

  7. Ein weiterer zufälliger Nebeneffekt von RFPs könnte auch die Verdünnung der Verantwortung sein, da RFPs, durch ihre Gestaltung, eine beträchtliche Anzahl von Personen auf Seiten des Kunden einbeziehen. ↩︎