Wer sich für eine Beschaffungslösung entscheiden will, muss erst einmal genau hinsehen, ob sie passt. (Bild: Arsenii - stock.adobe.com)
Wer eine neue Software sucht, folgt im besten Fall der Empfehlung eines wohlmeinenden Kollegen, oft aber auch nur den Vorschlägen, die ihm Google macht. Findet er oder sie etwas Interessantes, wird beinahe reflexartig ein Testzugang erbeten. Etwa jeder zweite Interessent tut das bereits in der allerersten E-Mail an den Anbieter. Und einer von fünf springt ab, wenn die Bitte nicht erfüllt wird.
Für den Anbieter scheint es ein Leichtes, potenziellen Kunden den Zugang zu gewähren und sie mit der Test-Instanz 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 ersten 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 und zum jeweiligen Unternehmen passt, lässt sich so kaum herausfinden. Stellt ein Anbieter dennoch einen Testzugang zur Verfügung, wird dieser die gewünschten Use Cases nicht auf Knopfdruck abbilden können. Also schafft er es mit hoher Wahrscheinlichkeit nicht in die nächste Auswahlrunde. 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 bekannt sein – sowohl dem Unternehmen selbst als auch dem Anbieter.
Immer informiert mit den Newsletter von TECHNIK+EINKAUF
Hat Ihnen gefallen, was Sie gerade gelesen haben? Dann abonnieren Sie unseren Newsletter. Zwei Mal pro Woche halten wir Sie auf dem Laufenden über Neuigkeiten, Trends und Wissen rund um den technischen Einkauf - kostenlos!
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: Es gibt akuten Beratungsbedarf.
Use Case schlägt Teststellung
- Weder Anbieter noch Kunden können es sich leisten, Ressourcen zu verschwenden. Wer eine neue Beschaffungslösung sucht, sollte sich daher im Vorfeld über seine Anforderungen im Klaren sein und eine Shortlist präferierter Softwareanbieter erstellen – eventuell mithilfe kompetenter Beratung.
- Definierte Use Cases dienen als Basis für einen Leistungsvergleich der Anbieter.
- Nur mit einem Deep Dive beziehungsweise Proof of Concept lässt sich feststellen, ob Softwareanbieter und Anwenderunternehmen zusammenpassen und die Lösung den Beschaffungsprozess verbessern kann.
- Der Aufwand dafür ist nicht zu unterschätzen. Aber es lohnt sich für beide Seiten – auch deshalb, weil sich spätere Streitigkeiten so von vornherein ausschließen lassen.
Ergo: Auf die Anforderung und Bereitstellung von unbetreuten Testzugängen können Interessenten getrost verzichte
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. In vielen Fällen müssen deshalb auch die bestehenden Abläufe angepasst werden. Vor der Frage nach der Funktionalität der Software steht also die nach den Prozessen.
Unternehmenskritische Abläufe, zum Beispiel 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 eines Großunternehmens 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. Meist gibt es sogar innerhalb einer Einkaufsorganisation unterschiedliche Beschaffungsprozesse, abhängig von Ware, Bestellhäufigkeit und Lieferart.
Wenn es sich nicht gerade um einen stark standardisierten E-Procurement-Prozess handelt, ist eine herkömmliche Test-Instanz 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 alle Prozesse, wie gewünscht, abbildet, besteht die Gefahr, dass im Nachhinein teure Anpassungen notwendig werden. Dies führt im schlimmsten Fall zu einem erneuten Anbieterwechsel.
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 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. Erfahrene Softwareanbieter arbeiten von Anfang an intensiv mit dem Kunden zusammen – auch wenn sie dafür einen hohen Aufwand betreiben müssen.