Das Wichtigste vorweg: IT-Lösungen sind kein Sand! Was ich damit sagen möchte? Rohstoffe unterliegen in der Regel gewissen Normen. Für den Einkauf kann man exakt spezifizieren was man benötigt und mit Hilfe einer Ausschreibung den besten Lieferanten mit dem günstigsten Angebot ermitteln.

 

Beim Einkauf einer P2P-Lösung (Purchase-to-Pay) stellt sich das etwas anders dar. Dennoch ist die Ausschreibung – neben Empfehlungen, bestehenden Erfahrungen, Konzernvorgaben oder Referenzbesuchen – nach wie vor eine sehr beliebte Methode der Anbieter- und Lösungsauswahl im IT-Bereich.

In der IT Planning-Studie 2013 wurde festgestellt, dass „große Unternehmen im Durchschnitt 150 Tage benötigen, um ihre geschäftskritischen IT-Projekte aufzugleisen. Unter anderem auch deshalb, weil zu viele Beteiligte aus den Fachabteilungen konsultiert werden müssten.“ Neben den langen Laufzeiten bis zum Projektstart bedeutet eine Ausschreibung also auch einen großen internen Aufwand und nicht selten hohe Kosten für externe Berater. Am Ende steht der Wunsch nach der „eilerlegenden Wollmilchsau“, am besten natürlich zum Schnäppchenpreis und mit einem Go-Live in 3 Monaten – eine unrealistische Planung, die auf Idealannahmen basiert und die tatsächlichen P2P-Lösungen der Anbieter außer Acht lässt. Damit sind Folgeprobleme im Projekt vorprogrammiert. Zudem lassen Ausschreibungen den Anbietern nur eingeschränkte Möglichkeiten für Rückfragen und oftmals sehr kurze Zeitspannen bis zur verbindlichen Angebotsabgabe. Alles andere als eine gute Ausgangssituation für ein erfolgreiches IT-Projekt.
 

Die Ausschreibung: beschreiben statt fordern

Also, was kann man tun, um es besser zu machen? Wenn Sie trotz der beschriebenen Problematik eine Ausschreibung machen wollen oder müssen, versuchen Sie nicht zu viele Spezialisten zu involvieren und bei der Beschreibung Ihrer Wünsche immer prozessorientiert zu denken, d.h. welche Funktionen benötigt die P2P-Lösung, um den Prozess möglichst effizient zu gestalten und die gewünschten Kosteneinsparungen zu erzielen und nicht, welche Funktionen wünschen sich die am Prozess Beteiligten. Anstatt dem Anbieter geschlossene Fragen zu stellen, macht es mehr Sinn, seine Ist-Situation und Herausforderungen zu beschreiben und Fragen offen zu stellen. Fragen zur Vorgehensweise im Projekt (z.B. zum Ressourcenmanagement) oder zu den Risiken werden Ihnen einen Eindruck von der Erfahrung und der Seriosität des Anbieters vermitteln. Eine Ausschreibung sollte vielmehr eine Leistungsanfrage (RFI – request for information) statt einer verbindlichen Angebotsanfrage (RFP – request for proposal) sein.

Wenn die Ausschreibung nicht das Mittel der Wahl ist, sondern Sie eine freihändige Vergabe bevorzugen, können Sie die Anbieter, die in der engeren Auswahl sind, auch einladen und im Dialog die Anforderungen an die P2P-Lösung gemeinsam erarbeiten. Wichtig ist in jedem Fall, dass Sie dem Anbieter ausreichend Zeit lassen auf Ihre Anfrage einzugehen und ein Angebot auszuarbeiten, das reale Bedingungen zu Grunde legt, so dass Sie später keine bösen Überraschungen erleben.

Der erste Schritt ist geschafft, Sie haben sich für einen Anbieter und dessen P2P-Lösung entschieden. Doch wie geht es nun weiter? Auf welche Weise implementieren Sie die Lösung in Ihrem Unternehmen, welche Risiken bestehen und wie können Sie diese minimieren? Werfen wir zunächst einen Blick auf die größten Risiken:

• falsche Erwartungshaltung (z.B. aufgrund des RFP)

• interne Widerstände gegen die neue Lösung

• fehlendes Know-How  und  unklare Verantwortlichkeiten im Projekt-Team

• technische Restriktionen

• fehlende/missverständliche Kommunikation

• sich ändernde Anforderungen

Wie Sie einer falschen Erwartungshaltung größtenteils vorbeugen können, wurde bereits im Abschnitt über die Auswahl eines Anbieters beschrieben. Internen Widerständen kann mit einer gründlichen Stakeholder-Analyse und einer guten Kommunikation begegnet werden. Das Projekt-Team sollte mit klaren Strukturen und Rollen versehen und ein Lenkungsausschuss eingesetzt werden, der das Projekt eng begleitet.
 

Think big, start small: die agile Methode

Das wichtigste und zugleich am schwersten zu kalkulierende Risiko sind die Anforderungen an eine P2P-Lösung, die sich im Projektverlauf verändern können. In der IT-Planning Studie 2013 heißt es: „Ein nicht zu unterschätzender Risikofaktor sei zudem die schiere Menge an Änderungen, die nach Projektstart über die kommenden 9 bis 12 Monate anfallen.“ Sowohl Business-Prozesse als auch IT-Lösungen sind kurzlebig, Änderungen müssen also einkalkuliert werden. Das Problem bei einer klassischen Umsetzung des Projektes nach der Wasserfall-Methode ist, dass dies wenig Raum für Änderungen lässt. Eine gute Alternative ist daher die agile Methode.

Geht man ein Implementierungsprojekt mit der agilen Methode an, startet man zunächst mit einem Best Practice, d.h. mit einer vorgefertigten Lösung, die den Standard abbildet. 80% der Anforderungen eines Unternehmens an eine Purchase-to-Pay-Lösung sind in aller Regel Standard. Anstelle einer ausgedehnten Feinspezifikation vor Projektstart empfiehlt sich ein sogenannter Fit & Gap-Workshop, in dem das Best Practice mit den Anforderungen abgeglichen und Sonderfälle identifiziert werden. Nach der Implementierung werden die übrigen Anforderungen (wiederholt) evaluiert und die Best Practice-Lösung entsprechend weiterentwickelt.



Der große Vorteil bei diesem Vorgehen liegt darin, dass man relativ flexibel auf Veränderungen in den Anforderungen reagieren kann. Zudem kann man die Lösung früher nutzen und dementsprechend auch schon früher Kosten einsparen. Erfahrungen zeigen, dass die Projektkosten bei der agilen Methode insgesamt niedriger ausfallen und auch in der Folge weniger Kosten entstehen, da der Aufwand für Updates aufgrund der großen Nähe zur Standard-Lösung geringer ist als bei maßgeschneiderten Produkten. Und ganz nebenbei kann man internen Bedenkenträgern den Wind aus den Segeln nehmen, denn eine funktionierende Lösung spricht sich rum und baut Hürden für den weiteren Ausbau ab.


 

SaaS statt On-Premise

Zum Abschluss sei hier noch auf das Thema Software-as-a-Service (SaaS) hingewiesen. Neben der Installation der Software beim Kunden, also On-Premise, bieten viele Lieferanten inzwischen die Möglichkeit, die Purchase-to-Pay Lösung über dessen Infrastruktur als Dienstleistung zu nutzen. Dies hat Vorteile wie die Reduktion der technischen Risiken, sofortige Verfügbarkeit und damit eine weitere Verkürzung der Projektlaufzeit. Auch das gilt es bei der Entscheidung für und Implementierung von einer P2P-Lösung zu berücksichtigen. Die wichtigesten Punkte dazu fasst dieses Datenblatt zum Thema Purchase-to-Pay als Software-as-a-Service nochmal zusammen.

Wenn Sie konkret etwas über die P2P-Lösung von Basware erfahren möchten, zögern Sie nicht, mich über das Kontaktformular anzusprechen.
 
Wenn Sie mehr darüber erfahren möchten, wie Sie Purchase-to-Pay international einführen, empfehle ich Ihnen die Webinar-Aufnahme „Internationale Einführung von Purchase-to-Pay“.

Übrigens:
In unserem LIVE-Webinar berichtete Anna-Kathrin Werkmeister aus eigener Erfahrung als Heads of Business Controlling & Optimization bei Klöckner, wie man einen digitalen Purchase-to-Pay-Prozess erfolgreich in seinem Unternehmen einführen kann.
Die Webinar-Aufnahme können Sie sich hier ansehen >>
 

Teile das