Einkaufslösungen – Warum Testzugänge für Beschaffungslösungen sinnlos sind

Wer eine umfassende Lösung evaluieren möchte, stürzt sich auf Testzugänge zum Ausprobieren. Was auf den ersten Blick sinnvoll und selbstverständlich erscheint, kann aber schnell in die Irre führen. Denn man bekommt einen ersten Eindruck von der Benutzeroberfläche einer Standardsoftware, komplexe Prozesse lassen sich damit aber nicht abbilden – schon gar nicht, wenn Interessenten noch nicht sicher wissen, was sie eigentlich brauchen. Ein Ratgeber.

Wer eine neue Software sucht, folgt im besten Fall der Empfehlung von Kollegen, oft aber auch Vorschlägen, die Google unterbreitet. Meist wird dann beinahe reflexartig ein Testzugang erbeten. Unserer Erfahrung nach tut das jeder zweite Interessent bereits in der allerersten E-Mail an den Anbieter.

Für den Anbieter scheint es ein Leichtes, potenziellen Kunden den Zugang zu gewähren und sie mit der Test-Instanz erst einmal allein zu lassen. Aber Vorsicht. Diese Haltung ist sowohl aus Kunden- als auch aus Anbietersicht falsch. Der Grund: Bei einem Testzugang handelt es sich in der Regel um eine vereinfachte Standardkonfiguration des Produkts. Damit können Interessenten sicher einen Eindruck von der Benutzeroberfläche gewinnen und vielleicht auch abschätzen, wie gut die Anwender damit arbeiten können. Ob die Lösung aber tatsächlich alle Anforderungen erfüllt, lässt sich so jedoch kaum herausfinden.

Prozess geht vor Funktion. Wie die Erfahrung zeigt, wollen potenzielle Kunden bei einem ersten Test vorhandene Prozesse mit der neuen Lösung abbilden. Einfachere, schnellere und sicherere Abläufe lassen sich mit dieser Vorgehensweise jedoch nicht entwickeln. Ein neues Softwaresystem wird meist eingeführt, um Qualitäts- und Produktivitätssteigerungen zu erzielen. Deshalb müssen oft auch die bestehenden Abläufe angepasst werden. Vor der Frage nach der Funktionalität der Software steht also die nach den Prozessen.

Source-to-Pay-Prozesse, unterscheiden sich per Definition von denen anderer Organisationen – selbst dann, wenn diese zu ähnlichen Branchen gehören. Nehmen wir als Beispiel eine Einkaufslösung, die für die komplexen Beschaffungsprozesse in Großunternehmen ausgelegt ist. An der Oberfläche sieht es so aus, als wäre der Vorgang immer derselbe: Ausschreibung, Verhandlung, Vertrag, Lieferung, Rechnung. Doch die Unterschiede liegen im Detail – genauer gesagt in den konkreten Anwendungsfällen (Use Cases), die es mit einer neuen Softwarelösung abzubilden und zu verbessern gilt.

Wenn es sich nicht gerade um einen stark standardisierten E-Procurement-Prozess handelt, ist eine herkömmliche Testinstanz also für beide Seiten reine Zeitverschwendung. Schlimmer noch: Oft wird eine Softwarelösung, die dem Unternehmen weiterhelfen könnte, abgelehnt, denn: »So wie wir das machen, geht das mit dem Tool nicht.« Falls aber eine anhand von Standardkonfigurationen evaluierte Softwarelösung tatsächlich nicht alle Prozesse abbildet, besteht die Gefahr, dass im Nachhinein teure Anpassungen notwendig werden. Dies führt im schlimmsten Fall zu einem erneuten Anbieterwechsel, der zusätzliche Implementierungskosten verursacht.

Wie sehen die Alternativen aus? Es ist verständlich, dass kein Kunde eine neue Einkaufssoftware kauft, ohne zu prüfen, ob sie auch tatsächlich seinen Anforderungen entspricht. Was also kann der Softwarehersteller dem Interessenten bieten, damit er sich auch vor oder ohne Testzugang ein Bild von der künftigen Lösung machen kann? Die Antwort lautet: Sie müssen Use Cases einfordern – oder diese gemeinsam mit ihren potenziellen Kunden erarbeiten. Dafür bieten sich zwei Formate an.

Deep Dive. Erfahrene Softwareanbieter arbeiten von Anfang an intensiv mit dem Kunden zusammen – auch wenn sie dafür einen hohen Aufwand betreiben müssen: Sie schicken zum Beispiel Berater für mehrere Tage zum potenziellen Kunden – vorausgesetzt, dieser verrät ihnen, wo die größten Herausforderungen liegen. Gemeinsam mit den Experten auf Kundenseite steigen die Berater tiefer in die zwei oder drei Prozesse ein, die digitalisiert und verbessert werden sollen oder bei denen akuter Handlungsbedarf besteht. Daraus definieren sie Use Cases und erarbeiten individuelle Lösungsvorschläge. Beispielsweise werden die Beschaffungslösungen so konfiguriert, dass sie die gewünschten Anwendungsszenarien bestmöglich abbilden.

Proof of Concept. Benötigt der Interessent weitere Entscheidungshilfen, empfiehlt sich ein Proof of Concept (PoC). Dieser dauert in der Regel mehrere Wochen und benötigt auch personelle Ressourcen auf Kundenseite. Das Projektteam betrachtet nicht nur deutlich mehr Use Cases als beim Deep Dive, sondern erstellt auch digitale Handbücher, die jede Benutzeraktion dokumentieren und im Laufe des PoC immer wieder angepasst werden. Mehrmals pro Woche besprechen Projektleiter und Key User mit dem Anbieter, inwieweit sie mit dem System und dem dazugehörigen Handbuch arbeiten können oder was noch geändert werden muss. Am Ende des PoC steht ein ausführliches Debriefing. Danach sollte die Produktentscheidung leicht fallen: Entweder ist der potenzielle Kunde mit der Abbildung seiner Use Cases zufrieden – oder er entscheidet, denselben Prozess mit einem anderen Anbieter erneut anzugehen.

Fazit: Use Case schlägt Teststellung. Eine Softwarelösung, die zur Effizienzsteigerung wichtiger Unternehmensprozesse eingesetzt werden soll, lässt sich nicht testen wie eine klassische Standardsoftware. Wenn sie individuelle Herausforderungen lösen soll, müssen diese vorher klar benannt werden – sowohl vom Unternehmen selbst als auch vom Anbieter. Doch viele Kaufinteressierte, die sofort nach einem Testzugang fragen, sind sich weder über ihre aktuellen Schmerzpunkte und angestrebten Ziele im Klaren, noch haben sie eine Vorstellung von Art und Umfang des notwendigen Projekts. Häufig verfügen sie auch nicht über klar definierte Zeitpläne und Budgets. Das heißt: Sie haben im Grunde akuten Beratungsbedarf. Wer eine neue Beschaffungslösung sucht, sollte sich daher im Vorfeld über seine Anforderungen im Klaren sein oder für den Auswahl- und Bewertungsprozess die Hilfe spezialisierter Berater in Anspruch nehmen.

 


Jan-Hendrik Sohn ist Vice President DACH und CEE von Ivalua. Er verfügt über mehr als 20 Jahre Erfahrung im E-Procurement-Business und ist Experte für die Einkaufsprozesse in Großunternehmen. Der gelernte Groß- und Außenhandelskaufmann war vorher als Senior Account Director DACH bei Tradeshift tätig. Während seiner Karriere bekleidete Sohn verschiedene Führungspositionen – unter anderem als Sales Director bei SynerTrade, Prokurist und Mitglied der Geschäftsführung der Onventis GmbH sowie als Sales Manager für die DACH-Region und die Niederlande bei Capgemini Procurement Services.

 

Illustration: © Valeriy Kachaev | Dreamstime.com