Zu häufig werden in Vertriebsprozessen Module und geschätzte Lizenzen verkauft, die am Ende entweder aufgrund fehlerhafter Einschätzung oder eben nicht implementierter Prozesse brach liegen. Damit verschenkt der Kunde Geld und kann die Subskription auch nicht ohne Weiteres anpassen. Es kann dennoch Sinn machen diesen Umstand genauer zu untersuchen und damit den Return On Invest zu steigern bzw. die Potentiale zu schöpfen.
Die Wirtschaftswoche schreibt darüber in ihrem Artikel vom 27.01.2022 - https://www.wiwo.de/28012136.html - was passiert mit ungenutzten Lizenzen, die im Rahmen einer SAP Software Implementierung aufkommen?
Hinter den Beratungshäusern sitzt eine Marketing- und Vertriebsmaschinerie, die getrieben ist, getrieben die Umsätze in gewissen Bereichen zu stärken und zu erhöhen. Man mag nun keine Absicht unterstellen, aber da wird was die "Menge" an Software angeht, gerne auch mal mit der groben Kelle bemessen. Das liegt aber nicht alleine am Verkäufer, sondern auch der Einkäufer muss ja in etwa wissen, wie viel er braucht oder wie viel er haben will.
Es ist ja dann, wie an der Wursttheke, bestelle ich zu viel, dann muss ich am Ende entweder den Rest wegwerfen oder eben bestmöglich "verwerten".
1. Gründe für zu viele Lizenzen
Der Reihe nach, was sind denn die Gründe für zu viele Lizenzen. Meist fehlende genaue Kenntnis über den "Hunger" den der Kunde mitbringt. Jetzt ist es nun mal so, dass nicht alle Ausschreibungen Ergebnisse von Vorprojekten sind, sondern bisweilen auch Nebenprodukt des Tagesgeschäfts und mal eben so geschrieben wurden.
Es ist aber Tatsache, dass nicht immer die Ist-Prozesse die Relevanz für die Ausschreibung haben, sondern die Soll-Prozesse - und die müssen bei Weitem nicht dem Status Quo entsprechen. Es ist gar kein so leichtes Unterfangen, eine Ausschreibung aufzubauen - neben dem Tagesgeschäft sowieso nicht. Wie oft erleben wir Anfragen der Art - "Ich soll mal eben in Erfahrung bringen, was Ihre Software so kann", von Werksstudenten. Das soll an der Stelle kein Affront gegen Werksstudenten sein - jene, die wir kennen sind top, sondern eher aufzeigen, dass die Priorität solcher Maßnahmen nicht zwingend anerkannt ist und die Wichtigkeit nicht angemessen.
Es ist schlichtweg richtig und wichtig, dass methodische Grundlagen eingehalten werden, um Ausschreibungen und die eigene Aussagekraft in Richtung Anbieter zu stärken. Wir begleiten nur zu oft SAP Vorprojekte in denen so genannte Design Thinking Workshops durchgeführt werden, Fit/Gap Analysen, also Ist und Soll abgeglichen werden, Requirements Management ist ebenso ein Thema, auch kritische Fragen von außen, ob das wirklich alles so sein muss, bis hin zu frühzeitigem Communication und Change Management (nicht zwingend erst im Hauptprojekt). Per Definition ist Scope Management (Umfang) wesentlicher Bestandteil aller Projekte und damit Grundvoraussetzung von sauberen Lasten- bzw. Pflichtenheften. Alleine, dass diese Dokumente und die Bedeutung zu oft in den Hintergrund treten zeigt, dass die Wertigkeit von Ausschreibungsdokumenten nicht dort ist, wo sie sein muss.
Übrigens, wir hatten auch schon Fälle, wo in der Ausschreibung "der Abdeckungsgrad von Software A,B oder C angepriesen wurde" - bisweilen formale Fehler mindestens aber schlechtes Signal an den Wettbewerb der Ausschreibung; ganz nebenbei.
Jetzt soll es nicht als Lehrstunde ausarten, nur klarmachen und verdeutlichen, wie wichtig das Projekt vor dem Projekt ist. Also wenn nicht mehr wie früher klassisch Scope Management Teil des eigentlichen Projekts ist, dann sollte es im Rahmen von Vorprojekten methodisch sauber aufgesetzt werden. Die Argumente "kostet Geld", "wir haben niemanden dafür" oder "zu wenig Zeit" - nun ja, wir sprechen gerade darüber, dass man am Ende zweimal bzw. mehr zahlt.
Also, wenn ich meinen Hunger nicht einschätzen kann, dann nehm ich schon mal vorweg zu viel mit nach hause.
2. Projektdurchführung
Ist die Ausschreibung durch, nach bestem Wissen und Gewissen der Partner für die Implementierung gefunden, dann geht es aus dem Lastenheft üblicherweise ins Pflichtenheft. Grob gesagt, dass die zu liefernden "Gegenstände" en detail beschrieben werden und wichtig, mit Abnahmekriterien versehen sind.
Nun sind auch hier mehr Parteien am Werk, dummerweise auf der einen Seite, die Mitarbeiter im Unternehmen. Diese kennen ihr Tagesgeschäft bestens und wissen, wie ihre Anwendungen am ehesten unterstützen. Eigentlich müsste man mit allen Interviews führen und verstehen, wie die Software das Tagesgeschäft unterstützt (Benefit Case). Um das zu beschleunigen, werden je gewöhnlich Projektteams gebildet, diese sitzen dann dem Implementierungspartnergegenüber. Im besten Fall wenigstens mit Branchen-Know-How und Berufserfahrung, im schlechtesten Fall keines von beidem. Auf der einen Seite eine konsolidierte Truppe, die als Fürsprecher arbeitet und auf der anderen Seite ein Team aus "Beratern".
Es soll nun nicht arrogant und abwertend werden, aber das Problem ist durchaus daran am ehesten zu erfassen. Kommunikation ist immens wichtig, auf allen Ebenen - es braucht schon mindestens eine ordentliche Motivation die Dinge ins Laufen zu bringen. Wenn man nun davon ausgehen darf, dass ein Vorprojekt Bestand hatte und die notwendigen Prozesse klar definiert wurden, dann sind hier "nur" noch Details und entsprechende Kriterien auszuprägen.
Jetzt sollte der erfolgreichen Implementierung der Prozesse nichts mehr im Wege stehen. Einzige Bruchstelle bleibt die Kommunikation - Sender / Empfänger-Zeug eben.
Also, wenn ich dem Koch nicht bestmöglich beschreiben kann, was ich essen möchte, dann schmeckt es nicht oder ich bekomm eben das falsche Gericht. War die Beschreibung bestmöglich, dann hatte der Koch vielleicht kein Talent.
3. Im Dilemma und dann ...
Aus den kurzen Beschreibungen entstehen jeweils Mehrkosten. Einerseits haben wir nun zu viele Lizenzen ungenutzt, weil zu viele Benutzer die Anwendung nicht brauchen oder schlimmer, nicht nutzen. Zum anderen, weil wir Lizenzen für Prozesse gekauft haben, die letztlich nicht umgesetzt wurden oder nicht nutzbar sind für die Anwender. So oder so - verschenken wir Geld bzw. Potentiale.
An der Stelle knüpfen wir an, schauen sozusagen wie man alles ideal "verwertet" und zu einem genüßlichen Mahl zusammenstellt.
Das ist schon eine der schwierigsten Ebenen in ein Projekt einzutreten bei dem die Constraints mindestens auf gelb stehen (Budget am Ende, Zeit überzogen, Umfang nicht umgesetzt, Qualität eher weniger gut). Das ist uns klar, dennoch glauben wir an unsere Expertise über all die Jahre.
Wie wir das tun: Grob gesagt, gehen wir die zuvor beschriebenen Schritte im schnelleren Vorlauf an. Aufgrund unserer Erfahrungen aus anderen Projekten, haben wir einen guten Blick für die wesentlichen und wichtigen Details. Da wir des öfteren in Vorprojekten beraten, sind wir uns der Ergebnisse ebenso bewusst. Daraus entstehen Fragen und konkrete Handlungsempfehlungen, die wir auf Prozess- und Kommunikationsebene einbringen.