Unternehmen haben bei Software die Qual der Wahl. In vielen Märkten gibt es Dutzende, wenn nicht sogar Hunderte von Anbietern von Softwarelösungen; das zeigt der Blick in Marktstudien bei ERP-Systemen, Planung, Reporting oder CRM-Systemen. Ein systematischer Auswahlprozess erfordert Disziplin, die Einbindung verschiedener Stakeholder und detaillierte Analysen zum Leistungsangebot verschiedener Anbieter, kurz: Zeit. Hier sei daran erinnert, dass Discounter nicht nur deshalb so beliebt sind, weil sie preisgünstiger sind – sondern auch, weil Einkäufer nicht zwischen 20 Joghurt-Varianten entscheiden müssen, sondern ein einziger Joghurt im Regal diese Qual der Wahl eliminiert. Oder erinnern Sie sich an Präsident Obama, der immer nur blaue Anzüge trug, um keine Zeit bei der Kleiderfrage zu verlieren?

Nicht überraschend also, dass immer wieder „Abkürzungen“ in diesem Prozess genommen werden, die sich allerdings bisweilen im Nachhinein als unglücklich herausstellen. Das Beratungshaus Zoeller & Partner formuliert das in einer Marktübersicht zu Dokumentenmanagementsystemen wie folgt: „Die am häufigsten genannten produktabhängigen Probleme (…) sind auf eine falsche Systemauswahl zurückzuführen. Typische Auswirkungen sind dann mangelnde Skalierbarkeit, unterschätzter Aufwand bei Installation, Anpassung und Betrieb, unvorhergesehener Individualentwicklungsaufwand wegen übersehener funktionaler Anforderungen, schlechte Endbenutzerergonomie u.a.“. Zwar gilt bei Software in der Regel die „Normative Kraft des Faktischen“, heißt: Ein Nutzer kommt gar nicht umhin, ein installiertes System zu nutzen, das Scheitern einer Softwareauswahl bzw. die Ablehnung einer neuen Software lässt sich in der Praxis nur sehr selten beobachten. Aber es entstehen erhebliche Reibungsverluste, Parallelsysteme (MS Excel) und Unzufriedenheit.

Der Auswahlprozess kostet Zeit

Man muss sich zunächst im Klaren sein, dass – zumindest bei größeren Softwaresystemen wie ERP oder DMS Software – der Auswahlprozess ganz erhebliche Zeitressourcen in Anspruch nimmt. Es klingt zunächst ganz einfach: Anforderungen aus dem Fachbereich einsammeln (priorisiert nach Kann- und Soll-Kriterien), und dann werden diese mit den am Markt erhältlichen Softwaresystemen abgeglichen. In der Praxis bedeutet die Herstellung einer einigermaßen detaillierten Marktübersicht, dass man etwa eine Marktstudie durcharbeitet, auf dieser Basis eine Shortlist erstellt, ein Lastenheft erstellt und hiernach Workshops mit Anbietern abhält. Im Bereich Dokumentenmanagementsysteme etwa startet der Prozess etwa mit der Marktstudie von Zöller & Partner, nämlich „Dokumenten Management Systeme – Marktübersicht 2018“. Diese wurde zusammen mit der bitkom herausgegeben. Die Studie umfasst 889 Seiten. Doch damit nicht genug, der geneigte Leser stolpert schon bald über folgenden Satz: „Für eine konkrete Produktauswahl ist die Darstellungstiefe dieser Marktübersicht nicht ausreichend. Diesem Anspruch will und kann eine solche Übersicht aber auch gar nicht genügen angesichts der Funktionsvielfalt der Produkte. Sie soll aber zur ersten Orientierung dienen und eine Abwägung erlauben, was man von einem modernen DMS mittlerweile im Standard erwarten darf.“

Spätestens nach diesem Satz dürfte jedem Projektmanager eines Auswahlprozesses für eine vergleichbar umfangreiche Softwarelösung klar sein, dass diese neue Aufgabe nicht nebenher im Tagesgeschäft bewältigt werden kann. Insbesondere zu Zeiten von Fachkräftemangel und hoher Auslastung liegt dann die vermeintliche Lösung nahe, diesen Prozess einfach outzusourcen: Diese Aufgabe also einem Beratungshaus zu übergeben oder sogar die Entscheidung an das Systemhaus des Vertrauens zu übergeben. Dies wird zweifelsohne den Prozess beschleunigen und Zeitressourcen einsparen, dennoch kommt man nicht umhin, um eigene Ressourcen in diesen Prozess einzubinden, der mit den unternehmensspezifischen Anforderungen vertraut ist und Entscheidungen moderiert. Eine vollständige Externalisierung funktioniert nicht, ich erinnere mich an einen großen Mittelständler, der den Auswahlprozess eines ERP-Systems mit einem externen Berater gestartet hatte. Dieser Berater hatte 2 große Leitzordner mit dokumentierten Soll-Prozessen aus verschiedenen Unternehmensbereichen hinterlassen, die nach Übergabe alsbald im Schrank verschwanden; der Auswahlprozess endete in einer Sackgasse und versandete für zwei Jahr völlig. Was hier völlig fehlte: Zielvision, Projektsponsor aus dem Top-Management, das erforderliche Zeitbudget für einen Projektmanager und die betroffenen Linienmanager.

Ein beliebte Variante von „Abkürzungen“ sind Empfehlungen. Das kann in einigen Fällen zur passenden Softwareauswahl führen, etwa wenn Erfahrungen zu branchenspezifischen Softwareprodukten in Branchentreffs ausgetauscht werden; wenn Unternehmen vergleichbare Arbeitsprozesse haben, dann sind solche Empfehlungen absolut valide. Mindestens sollten solche Empfehlungen in die Gesamtbewertung einfließen.
Was sich im Übrigen auch beobachten lässt: Es gibt gar keinen Auswahlprozess, die Software wird vom Vertrieb eines Softwareherstellers in das Unternehmen „gedrückt“. Entscheider im Fachbereich werden auf Effizienzgewinne hingewiesen oder (neue) Compliance-Anforderungen, die mit einer Software erfüllt werden können. Wer ein drängendes Problem hat oder wenig Zeit oder beides, der handelt durchaus vielfach nach dem Motto: „Wir brauchen sowas und die Software kann das“. Die implizite Hypothese, dass Softwareprodukte „sowieso inzwischen alle einem Marktstandard“ folgen, gilt allerdings nicht immer. IN der bereits zitierten Marktstudie zu DMS heißt es etwa: „Für den Neueinsteiger ist der Markt häufig unübersichtlich. Die Lösungen unterscheiden sich in Kern- und Detailfunktionen erheblich voneinander und der Anwender muss wissen, welche Funktionen im Standard verfügbar sind oder wo er Aufwand für Einrichtung oder sogar Individualprogrammierung einplanen muss.“

Das Lastenheft oder die Anforderungsspezifikation

Die Formate eines Lastenhefts sind sehr unterschiedlich, insbesondere in der Phase der Vorauswahl: Mal wird dafür ein beschreibendes Dokument im WORD-Format angefertigt, mal eine Excel-basierte Liste mit Anforderungspunkten (Must-Have vs. Nice-to-Have), in der ein shortlisted Softwareanbieter ein Haken („erfüllt in der Standardversion“) setzen kann oder nicht. Die Eignung der verschiedenen Formate für diese oder jene Aufgabe ist kaum erklärungsbedürftig. Interessanter ist der Prozess, wie man zum Ergebnis kommt.

Man kann es kurz und knapp zusammenfassen: Die wenigsten bringen Begeisterung auf für Dokumentation, zum Beispiel die Dokumentation von IST-Prozessen in einer Abteilung oder auch nur die Dokumentation einer Sitzung (Gesprächsprotokoll). Der Entwickler möchte entwickeln, der Verkäufer möchte verkaufen. Schließlich wird die Leistung des Verkäufers auch nach seinem Umsatz bemessen, nicht nach Anzahl oder Umfang von Gesprächsnotizen im CRM-System. Auch in einem Softwareprojekt zur Auftragsprogrammierung trifft man häufig auf die Einstellung, man solle doch jetzt endlich mal anfangen zu programmieren, die paar Details könne man dann ja im Projektverlauf noch einspeisen. Die Dokumentation von Anforderungen (im Lastenheft) wird implizit als Zeitverschwendung und unnötige Verzögerung bewertet. Zu dem Thema lassen sich seitenweise Anekdoten erzählen, aber darum soll es nicht gehen. Es muss gemacht werden. Punkt. Wo sich kein Freiwilliger meldet, muss eine Top-Down-Entscheidung her.

Es gibt einen weiteren sehr spannenden (manchmal kritischen) Aspekt bei der Erarbeitung eines Lastenheftes bzw. Anforderungskatalogs. Im Status Quo haben sich typischerweise alle Beteiligten im Unternehmen mit bestehenden Prozessen und Strukturen arrangiert. Mit der Einführung einer neuen Software (etwa einer ERP-Software oder einem CRM-System) wird die Frage gestellt: Wo wollen wir hin, was können wir mit einer neuen Software besser machen? Oder sogar: Wie würden wir die Prozesse aufsetzen, wenn wir alles komplett neu erfinden könnten (Greenfield Ansatz)? Das kann der Beginn für einen wunderbaren Veränderungsprozess oder eine strategische Neuausrichtung sein; es kann aber auch der Auslöser für das Ausbrechen von eingedämmten Konflikten sein. Diese Dynamik muss man steuern und kanalisieren, die Beteiligten müssen sich auf eine Zielvision einigen und hieraus – Schritt für Schritt und in aufwändiger Detailarbeit – die Anforderungen für die betroffenen Prozesse ableiten. Dafür braucht es einen Projektsponsor, der in der Hierarchie weit genug aufgehängt ist; die Erstellung eines Lastenhefts ist kein Thema, das man einem Praktikanten oder Werkstudenten („Sammele doch bitte mal die Anforderungen und Ideen zusammen und strukturiere das ordentlich“) überlassen kann. Das ist im Idealfall möglich, wenn die Anforderungen und implizierten Prozesse widerspruchsfrei sein und wenn es die eierlegende Wollmilchsau gibt; aber in der Realität ist das selten der Fall.

Kurz: Planen Sie ausreichend Zeit und Ressourcen für den Erfassungs- und Abstimmungsprozess ein; das ist keine Zeitverschwendung, sondern die Basis für ein System, das nach Roll-Out eine hohe Akzeptanz genießt und funktioniert. Weiterführende Tipps für die Erstellung eines Lastenheftes finden Sie hier.

Das Kriterium Investitionssicherheit

Wer das Produkt MS Excel oder den MS SQL Server von Microsoft einsetzt, kann sich sicher sein, dass diese Applikationen in 10, 20 oder 30 Jahren noch gewartet werden; das gilt nicht für alle Softwareprodukte aus dem Markt. Halt! Schon der erste Teil des Satzes wirft eine interessante Frage auf, nämlich nach einem sinnvollen Zeithorizont für die wirtschaftliche Nutzung einer Software. Zwar zeigt der Blick in Unternehmen, dass einige Softwareanwendungen tatsächlich schon 20 oder 30 Jahre im Einsatz sind (häufig der Fall bei ERP-Systemen), jedoch würde ein IT Manager angesichts der gegenwärtig hochdynamischen Innovationszyklen im IT Markt (Stichworte: AI / KI, Cloud, SaaS) kaum mehr erwarten, dass eine Entscheidung für ein IT Produkt 30 Jahre Bestand hat. Selbst 20 Jahre halten einige IT Experten für weltfremd. Man darf aber durchaus mit dem Anspruch von 10 Jahren Investsicherheit herangehen; die Finanzbehörden gehen für die Bestimmung der Abschreibung von einer wirtschaftlichen Nutzungsdauer wie folgt aus: Die voraussichtliche Nutzungsdauer handelsüblicher Standardsoftware wird mit 3 Jahren bewertet. Speziell angefertigte Programme werden dagegen in der Regel über 5 Jahre abgeschrieben.

Soviel zur Arithmetik. Wie die Investsicherheit von Software zu beurteilen ist, das lässt sich zunächst einfach definieren – eine belastbare Einschätzung wiederum, ist dagegen nicht so trivial. Wir suchen, erstens, nach einem Softwarehersteller, der finanzielle Stabilität aufweist. Das lässt sich leicht nachprüfen mit einem Blick in den Bundesanzeiger. Wir suchen, zweitens, nach einem Produkt, das für einen Hersteller eine solche strategische oder finanzielle Relevanz hat, so dass das Produkt über den gewünschten Zeitraum weitergepflegt und gewartet wird. Schon dieses Kriterium lässt sich nicht immer zweifelsfrei überprüfen, die Produktpolitik eines Softwareunternehmens kann sich ändern. IBM Cognos wurde beispielsweise in der Anwendung und Administration immer aufwändiger (vor allem ab Version 8), das Produkt wurde zunehmend auf Grußunternehmen ausgerichtet, so dass bei mittelständischen Unternehmen aus nutzerergonomischen Gründen die Frage aufkam, ob das Produkt weiter Sinn machte. Heute stellt sich in der Produktpolitik häufig die Frage nach on-premise versus Cloud, wo sind die Server für Cloud-Services gehostet? Die Produktpolitik lässt sich kaum, eigentlich überhaupt nicht für einen Zeitraum jenseits von 2 bis 3 Jahren verlässlich abschätzen.

Es kommt hinzu, dass Unternehmen im Rahmen von Marktkonsolidierungen auch übernommen werden – die Produktpolitik kann davon massiv betroffen sein. Hier sei nochmals auf das vorgenannte Beispiel von Cognos verwiesen, ein Unternehmen, das im Jahr 2008 von IBM übernommen wurde. Im schlimmsten Fall übernimmt ein Softwarehersteller einen Wettbewerber, übernimmt die Kunden und migriert die Kunden einer Softwarelösung auf das Softwareprodukt mit der höheren Marktakzeptanz bzw. moderneren Softwarearchitektur. Das ist verständlich, denn warum sollte ein Softwarehersteller die Entwicklungskosten für zwei Produkte aufbringen, die beide den gleichen Markt bedienen bzw. die gleichen Funktionalitäten aufweisen? Es sei aber darauf hingewiesen, dass in einem solchen Fall Anbieter zwecks Kundenbindung Migrationshilfen und –prozesse anbieten, um beim Kunden im Falle des Produktwechsels möglichst wenig Reibungsverluste entstehen zu lassen.

Kurz, im Hinblick auf Produktpolitik und Marktkonsolidierungen ist das Kriterium Investitionssicherheit nicht trivial, aber darum ist es nicht weniger wichtig. Ich habe etwa den Fall eines mittelständischen Unternehmens in der Telekommunikationsindustrie verfolgt, wo einer meiner Onkels in der Geschäftsführung war. Das Unternehmen entschied sich für ein ERP-System, führt dies in einem mehrmonatigen Roll-Out Prozess ein und … das Unternehmen meldete nach einigen Jahren Insolvenz an. Der betroffene Mittelständler startete erneut den Auswahlprozess (die Unterlagen dürften noch alle vergleichsweise aktuell gewesen sein) und entschied sich für einen neuen Anbieter. Und dann Murphy’s Law, statistisch nicht weit entfernt von einem 6er im Lotto: Der neue ERP-Anbieter ging erneut pleite. Man kann sich nun trefflich darüber wundern, wie im zweiten Auswahlprozess ein Unternehmen zum Zuge kommen konnte, das auch nur im Entferntesten Zweifel an finanzieller Bonität aufwies, aber es ist passiert. Die Geschäftsführung reagierte wie folgt: Um das Telekommunikations-Unternehmen den dritten, kräftezehrenden Anlauf zu ersparen, übernahmen sie kurzerhand den Hauptentwickler des ERP-Anbieters als Angestellten. Wer den Einführungsprozess einer ERP-Software kennt, kann einschätzen, welche Management- und Zeit-Ressourcen hierfür verbraucht werden; eine unkonventionelle Antwort, die zumindest für einige Jahre tragfähig war und dem Unternehmen erlaubt hat, die Management Attention wieder der eigenen Produktentwicklung zu widmen.