„So, ich mache dann jetzt mal einen Qualitätscheck, ob auch alle Funktionen der ERP-Software korrekt implementiert sind.“ Ich dachte, ich höre nicht recht. Über mehrere Projekt-Monate hatten wir die Software genau auf die Bedürfnisse des Unternehmens abgestimmt, exakt die Funktionen ausgewählt, die gebraucht wurden – und die weggelassen, die überflüssig waren oder die Abläufe nur unnötig komplex gemacht hätten. Die Software lief perfekt und erfüllte genau den Zweck, den die Geschäftsführung sich gewünscht hatte. Und dann kam dieser Mitarbeiter eines Software-Beratungsportals und wollte, dass alle Features auf seiner Liste implementiert werden.

Das habe ich mir einen halben Tag lang angeschaut – und dann die Reißleine gezogen.

Was war passiert?

Wie viele Features brauchen Sie wirklich?

Unser Kunde hatte bei der Auswahl seiner Software den Weg über ein Software-Beratungsportal gewählt. Die sind eine feine Sache: Sie wählen aus einer Liste von bis zu 1.200 Features und Funktionen per Mausklick die aus, die Sie brauchen und bekommen am Ende eine Liste von drei oder vier Anbietern. Aus denen hat unser Kunde auch eine gute Software ausgesucht, mit der auch ich schon gute Erfahrungen gemacht hatte. Der Nachteil bei diesen Portalen: Sie verführen dazu, viel mehr Features auszuwählen, als tatsächlich gebraucht werden. Und manchmal auch die falschen, die nicht wirklich zum Unternehmen passen. Wenn Sie die dann unbesehen in Ihrem Unternehmen installieren, erzeugen Sie statt einer Effizienzsteigerung nur Chaos und Effizienzverlust.

Zum Glück konnte ich den Geschäftsführer überzeugen. Er hat den „Qualitätscheck“ des Softwareberaters gestoppt.

Aber nicht immer geht es so gut aus.

Best Practice ist keine Lösung für Sie

Ein anderer Kunde war folgendermaßen vorgegangen: Er ist an einen renommierten, international tätigen Softwareanbieter herangetreten. Hat gesagt: „Bei uns im Unternehmen herrscht das Chaos. Sagt ihr mir doch mit eurer Erfahrung, was wir machen sollen. Zeigt uns eure Best-Practice-Lösungen!“ Der Anbieter hat dann auch eine Lösung geliefert, die aber denkbar schlecht zu den individuellen Bedürfnissen des Unternehmens passten, wie sich erst im Laufe des Projektes herausstellte. Die Software war gut, aber der Best-Practice-Ansatz war an zu vielen Stellen schlicht das falsche Werkzeug.

Das war nicht die Schuld des Anbieters. Es lag an der Herangehensweise des Unternehmers. Er wollte sich die Arbeit sparen, vorher zu analysieren, was genau er braucht. Damit hat er den Softwareanbieter praktisch gezwungen, so genanntes Feature Fucking zu betreiben: Weil er nicht genau weiß, was gebraucht wird, verkauft er Ihnen so viele Features wie er zu bieten hat – und nicht nur die, die Sie tatsächlich brauchen. Und tatsächlich hätte die Implementierung der Software in dem Unternehmen dann beinahe zu einer Verschlechterung statt zu einer Verbesserung der Situation geführt.

Best-Practice-Lösungen können nicht funktionieren, weil jedes Unternehmen anders ist. Ich behaupte darüber hinaus: Best Practice ist ein Innovationskiller. Wenn alle das Gleiche machen, können Sie nichts mehr besser machen als die anderen.

Extremes Feature Fucking lösen Sie dann aus, wenn Sie mehrere Softwarelieferanten ein Angebot machen lassen. Wie sollen die versuchen, diesen Auftrag zu bekommen, wenn nicht dadurch, dass sie damit werben, wie viele tolle Funktionen ihre Software bietet – mit Feature Fucking also?

Aber wie finden Sie denn sonst die für Sie richtige Software?

Warum scheitern 70 Prozent aller Projekte?

Viele denken, die Implementierung einer Business-Software sei ein IT-Projekt. Also zäumen Sie das Pferd von der falschen Seite auf: Sie suchen sich zuerst die Software aus und setzen dann das Projekt auf.

Tatsächlich aber ist es ein Organisationsprojekt. Sie müssen zuerst überlegen: Wo stehen Sie? Was wollen erreichen? Was soll anders laufen in Ihrem Unternehmen? Was müssen Sie dafür im Organisationsaufbau ändern? Wie arbeiten Sie heute und wie wollen Sie in Zukunft arbeiten? Und dann erst schauen Sie, welche Software Sie dabei am besten unterstützt.

Und ein Organisationsprojekt ist natürlich mit sehr viel mehr Arbeit verbunden, als ein paar IT-Fachleute ins Haus zu holen und eine neue Software installieren zu lassen. Dass dieser Aufwand immer wieder unterschätzt wird, ist ganz sicher einer der Gründe dafür, dass laut Studien 70 Prozent aller Projekte scheitern – also länger dauern als geplant, mehr kosten als geplant oder nicht das anvisierte Ergebnis bringen.

Wenn ich erreichen will, dass eine Software eine optimale Wirkung für das Unternehmen erzielt, muss ich mit den Projektleitern im Unternehmen, mit den Ingenieuren, mit den Leuten an der Basis reden: Wo hakt es? Wo schmerzt es im Moment? Was soll die Software verändern? Wie müssen die Prozesse sich ändern? Das braucht Zeit. Ist erhebliche Mehrarbeit – neben dem normal weiterlaufenden Tagesgeschäft. Und ich brauche dafür die besten Leute, muss sie für das Projekt teils über zwei bis drei Monate zu 70 Prozent aus ihrem Kerngeschäft rausholen. Das plant aber kaum jemand ein, wenn er ein Softwareprojekt aufsetzt. Die Unternehmen sind darauf nicht vorbereitet. Es fehlt ihnen die grundsätzliche Projektfähigkeit.

Was sich aus meiner Sicht bewährt hat und was in einem projektfähigen Unternehmen Standard wäre: Starten Sie ein Vorprojekt, bevor Sie sich für eine Software-Lösung entscheiden. Klären Sie vorab und in Ruhe alle Ziele, die wichtigsten Anforderungen und die Zuständigkeiten und Ressourcen, die für eine erfolgreiche Einführung der Business-Software erforderlich sind.

Dann wissen Sie, was in dem Projekt auf Sie zukommt und was Sie brauchen.

Und dann tappen Sie auch nicht in die Feature-Fucking-Falle.

Ihr

Michael G. Schmidt