Mit dem Ende des Supports von SAP SRM in 2027 stellt sich schon jetzt die Frage, wie es dann weitergehen soll. Verschiedene Optionen stehen zur Wahl.
In den allermeisten Fällen haben SAP-SRM Kunden auch ein SAP ERP (ECC) im Einsatz. Das bedeutet oftmals, das eine Migration des ERPs geplant wird und SAP SRM als Bestandteil der Migration automatisch auf SAP ARIBA migriert werden soll.
Sicher, wie schon im Artikel über die Kurzversion Ariba SNAP von Joanna beschrieben, bietet SAP Ariba eine Reihe von Vorteilen:
- Cloud-basierte Lösung mit seinen Vorzügen hinsichtlich Implementierungs- und Wartungsaufwände
- Neue Oberflächen mit einer deutlich verbesserten Nutzererfahrung
- Ariba Supplier Network als Marktplatz für Lieferantenintegration
- Optimiertes Vertragsmanagement
Sollte man also in Anbetracht der Vorteile die Migration auf SAP Ariba einfach „durchwinken“?
Oder ist jetzt grade der Zeitpunkt noch einmal die Frage der richtigen Softwareauswahl zu stellen und was man denn wirklich benötigt als Einkaufsabteilung?
Auch wenn das bei dem ein oder anderen IT-Strategie-Verantwortlichen nicht unbedingt auf Gegenliebe stößt, kann eine Software-Abkündigung eine Chance sein, um sich nochmal ganz genau die eigenen Bedarfe und den dazu passenden Markt anzusehen. Dann kann man sich auch guten Gewissens auf eine Lösung für die nächsten Jahre festlegen.
Hört sich interessant an? Was ist also zu tun?
Um die verfügbaren Alternativen effizient vergleichbar zu machen ist ein professioneller RFP (Request-for-Proposal) dringend empfehlenswert. Nur so können verschiedene Anbieter transparent in Preis und Leistung miteinander verglichen werden.
Meine Erfahrung aus dem Prozess der Softwareauswahl ist, dass je besser die Vorbereitung des Projektes vonstattengeht, desto besser ist das Ergebnis und desto einfacher fällt die Auswahl des Anbieters am Ende. Mit dieser Form schafft man eine Objektivität, die das Ergebnis schwer anfechtbar macht.
1. Der Kriterienkatalog
Der Kriterienkatalog spiegelt die diversen Anforderungen wider, macht diese sichtbar und sorgt dafür, dass mögliche Aussagen von Lieferanten verschriftlicht sind. So gewinnt man, neben der transparenten Vergleichbarkeit die Möglichkeit später Lieferanten auf Ihre fachlichen Aussagen festzunageln. (Und damit Diskussionen zu vermeiden wie „Ja, das System kann das schon, aber das kostet eben extra…“ – wir kennen diese Spielchen)
1. Fachliche Anforderungen
a. Funktionale Anforderungen – Funktionalität, Workflows.
Die fachlichen/prozessualen Anforderungen sind der Kern des Kriterienkatalogs. Sie müssen detailliert dokumentiert sein, so dass die Leistungsfähigkeit der verschiedenen Lösungen verglichen werden kann. Eine Notation per User Story in der Form „Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>“ ist empfehlenswert, um klar die Anforderungen aufzunehmen (und nicht die Spezifikation auf Basis der Funktionalitäten des alten Systems zu definieren
b. Technische Anforderungen/Integration
Hier müssend die technischen Rahmenbedingungen seitens der IT definiert werden. Auch gehören hierzu mögliche Schnittstellenanforderungen, die oft auch die Kosten maßgeblich beeinflussen.
c. Performance bei der Produktpräsentation
d. Anwenderfreundlichkeit – Bewertung der User-Experience.
e. Referenzen
2. Kommerzielle Anforderungen
a. Implementierungsaufwände/-Kosten
b. Betriebskosten
c. Lizenzkosten
d. Lieferanten-Bewertung (Risiko)
Liegt die Liste der Kriterien „auf dem Tisch“, sollten diese gewichtet werden, um zu vermeiden, dass die Emotionen die Bewertung der Lieferanten verfälscht. Der Teilnehmerkreis für die Bewertung der Softwareauswahl sollte hierbei unbedingt ausgewogen sein.
2. Die Ausschreibung (RFP)
Nun geht es in die Planung der Ausschreibung für die Softwareauswahl. Hierbei ist für alle Schritte genügend Zeit einzuplanen. Angefangen von der Zeit für die Angebotsbearbeitung, Präsentationen der Anbieter und der Verhandlung und Vertragserstellung. Eventuell, je nach Komplexität und Wichtigkeit der Software kann auch eine „Short-List-Runde“ eingeplant sein, in der mit wenigen Lieferanten noch tiefer in die Möglichkeiten der Software eingestiegen wird und eventuell auch sogenannte „Proof-of-Concepts“ erstellt und mitbewertet werden.
Hat man alle Unterlagen und Informationen beisammen, kann der RFP raus an die potenziellen Anbieter. Hier ist es hilfreich, sich vorher informiert zu haben, welche Anbieter in Frage kommen und welche man doch lieber ausschließen möchte.
Ab dann heißt es, „Let the competition play“.
Die Lieferanten werden ihre Informationen zum Unternehmen und dem Produkt liefern, die Produkte präsentieren, Referenzen bieten. Die Teilnehmer aus dem eigenen Unternehmen werden die Informationen bewerten und so für eine vielschichtige Beurteilung der Lieferanten sorgen und den Kriterienkatalog mit Ergebnissen füllen. Eine gemeinsame Auswertung der Ergebnisse wird dann ans Licht bringen, wer der Favoritenkreis für die Softwareauswahl ist (falls man in 2 Etappen vorgehen möchte), oder der Favorit, mit dem man in finalen Verhandlungen einsteigt.
3. Die Verhandlung und der Vertrag
Ganz zum Schluss kann dann nochmal der Einkauf bei der Softwareauswahl glänzen. Mit der vorliegenden Transparenz Und hoffentlich mehr als einem möglichen Provider können die Preise entsprechend verhandelt werden. So kann ich hier als kleinen Tip geben, dass gerade bei Standardsoftware oft massive Preisrabatte umgesetzt werden können. Seid also nicht schüchtern in Euren Forderungen.
Wurde sich am Ende für einen Partner entschieden, ist im Normalfall ein Vertrag zu erstellen. Aus kommerzieller und fachlicher Sicht ist es hier empfehlenswert den erstellten Kriterienkatalog mit den Antworten des Anbieters mit in den Anhang des Vertrages als Pflichtenheft aufzunehmen, um somit bei eventuellen Auseinandersetzungen immer wieder drauf zugreifen zu können.
Was habe ich aus meinen Projekten gelernt?
Zum einen hilft die oben beschriebene Struktur ungemein objektiv eine Entscheidung in der Softwareauswahl zu treffen. Das Vorgehen hat dafür gesorgt, dass die Entscheidung für einen Anbieter für alle nachvollziehbar war und es keine Zweifel gab. Der breite interne Teilnehmerkreis hat bewirkt, dass sich alle einbezogen fühlten und nicht einfach eine Lösung „vorgesetzt“ bekommen haben. Die umfangreiche Dokumentation der Anforderungen hat dazu geführt, dass die Unterschiede der jeweiligen Lösungen sichtbar geworden sind – aber auch, dass sich der Fachbereich im Klaren war, was er wirklich benötigte.
Zum anderen kann ich berichten, dass dieses Vorgehen manchmal zu einer ganz anderen Lösung führt als ursprünglich angenommen, einfach weil wirklich alle Fakten transparent gegenübergestellt werden, anstatt sich auf das erste Baugefühl zu verlassen.
Die externe Unterstützung hat sich somit hier für den Kunden bezahlt gemacht.
Welche Schwierigkeiten hatten ihr schon in der Softwareauswahl. Wo haben diese sich vielleicht erst im Nachhinein bemerkbar gemacht?
