Standardlösung evaluieren in fünf Schritten

Warum sich eine saubere Evaluation der Standardlösung auszahlt

Wer ein Problem im Betrieb spürt, denkt schnell an eine eigene Software. Manchmal stimmt das auch. Oft genug aber gibt es bereits ein Produkt, das neunzig Prozent dessen kann, was du brauchst, und das von einem Anbieter betrieben wird, der nichts anderes tut. Eine Standardlösung zu evaluieren heisst, das systematisch zu prüfen, bevor du Geld in eine Entwicklung steckst, die du danach selbst pflegen musst.

Die Versuchung, diesen Schritt zu überspringen, ist gross. Eine Demo sieht gut aus, der Vertrieb ist freundlich, das Bauchgefühl sagt ja. Drei Monate später merkst du, dass die Lösung zwar hübsch ist, aber genau an der Stelle bricht, an der dein Geschäft eigentlich passiert. Eine Evaluation, die diesen Namen verdient, schützt dich davor. Sie kostet ein paar Tage Arbeit und erspart dir im Zweifel ein Jahr Ärger.

Im Folgenden gehe ich die fünf Schritte durch, die ich selbst gehe, bevor wir bei einem Kunden über eigene Software auch nur reden. Wir bauen und betreiben eigene Produkte wie Wortfreunde und Reazon. Gerade deshalb wissen wir, was ein Eigenbau über die Jahre wirklich verlangt, und empfehlen ihn nur, wenn die Standardlösung nachweislich nicht reicht.

Schritt eins: Eigene Anforderungen klären, bevor du den Markt anschaust

Die häufigste Ursache für eine misslungene Auswahl liegt nicht beim Produkt, sondern bei der Vorbereitung. Wer nicht weiss, was er braucht, kauft, was gut präsentiert wird. Also fängst du bei dir an.

Schreib auf, was die Software können muss, und trenne dabei zwei Dinge sauber: das, was wirklich zwingend ist, und das, was nett wäre. Ein zwingendes Kriterium ist eines, ohne das der Prozess im Betrieb nicht funktioniert. Wenn deine Aufträge zu achtzig Prozent über eine bestimmte Schnittstelle reinkommen, ist die Anbindung an diese Schnittstelle zwingend, nicht verhandelbar. Eine schönere Auswertung dagegen ist ein Wunsch. Diese Unterscheidung klingt banal, entscheidet aber alles, denn jede Standardlösung erfüllt deine Wunschliste nie vollständig.

Geh dabei von deinen tatsächlichen Abläufen aus, nicht von einer idealisierten Vorstellung. Setz dich mit den Leuten zusammen, die den Prozess täglich machen. Sie kennen die Sonderfälle, die in keinem Konzept stehen, den einen Kunden mit der abweichenden Rechnungsstellung, die Saison, in der die Mengen explodieren. Genau an diesen Sonderfällen scheitern Standardprodukte gern.

Wenn du heute mit Tabellen arbeitest, ist das übrigens ein guter Ausgangspunkt und kein Grund zur Scham. In Excel als Kernsystem, was nun? habe ich beschrieben, wie sich aus einer gewachsenen Tabelle eine saubere Anforderungsliste ableiten lässt. Am Ende dieses Schritts hast du eine Liste, die du gegen jedes Produkt halten kannst.

Schritt zwei: Den Markt sichten und die Auswahl bewusst eingrenzen

Jetzt erst schaust du nach aussen. Such gezielt nach Produkten, die für deine Branche oder deinen Anwendungsfall gemacht sind. Branchenlösungen treffen deine Anforderungen oft besser als generische Werkzeuge, weil die Anbieter dieselben Sonderfälle schon hundertmal gesehen haben.

Widerstehe der Versuchung, fünfzehn Produkte zu vergleichen. Das führt zu Tabellen, die niemand mehr liest, und zu einer Lähmung, in der du dich im Detail verlierst. Drei bis vier ernsthafte Kandidaten reichen. Filter grob vor: Ein Produkt, das deine zwingenden Kriterien schon laut Datenblatt nicht erfüllt, fliegt sofort raus.

Achte bei jedem Kandidaten auf ein paar Dinge, die in der Verkaufsbroschüre selten stehen. Wie lange gibt es den Anbieter, und verdient er sein Geld mit diesem Produkt oder ist es ein Nebenprojekt? Wie sieht der Support aus, gibt es ihn auf Deutsch, und in welcher Zeitzone? Wie häufig erscheinen Updates, und wie geht der Anbieter mit Sicherheitslücken um? Ein Produkt zu betreiben heisst, sich an einen Partner zu binden, dessen Zuverlässigkeit du über Jahre brauchst. Das ist eine Betriebsfrage, keine Funktionsfrage.

Lies Bewertungen, aber gewichte sie richtig. Eine Beschwerde über eine fehlende Funktion sagt dir wenig, eine Beschwerde über stundenlange Ausfälle oder einen Support, der nicht reagiert, sagt dir viel.

Schritt drei: Mit echten Daten testen statt mit der Hochglanz-Demo

Eine Demo zeigt dir, wie ein Produkt unter idealen Bedingungen aussieht. Der Vertrieb führt durch einen Pfad, der funktioniert. Über deinen Alltag sagt das wenig.

Deshalb ist dieser Schritt der wichtigste der ganzen Evaluation: Teste jeden ernsthaften Kandidaten mit deinen eigenen, echten Daten und deinen eigenen Abläufen. Nimm einen typischen Auftrag, einen typischen Kunden, einen typischen Monat, und versuch, ihn durch das System zu bringen. Nimm dann bewusst einen deiner Sonderfälle, den einen komplizierten, und schau, was passiert. Bricht das System? Brauchst du einen Workaround? Müsstest du deinen Prozess verbiegen, damit die Software glücklich ist?

Genau hier zeigt sich die Wahrheit. Ein Produkt, das deinen Standardfall sauber abbildet und bei deinem Sonderfall einen sinnvollen Weg anbietet, ist ein starker Kandidat. Ein Produkt, das dich zwingt, deinen Prozess umzubauen, kann trotzdem die richtige Wahl sein, wenn dein bisheriger Prozess schlecht war. Aber dann triffst du diese Entscheidung bewusst und nicht aus Versehen.

Bezieh die Leute ein, die später wirklich damit arbeiten. Eine Software, die der Chef toll findet und das Team hasst, wird im Betrieb umgangen, und dann hast du das Geld für ein Produkt ausgegeben, das niemand benutzt. Plan für diesen Test echte Zeit ein, nicht eine Stunde am Freitagnachmittag, sondern ein paar Tage mit ernsthafter Nutzung.

Schritt vier: Lock-in und Gesamtkosten prüfen, nicht nur den Listenpreis

Der Preis auf der Webseite ist der Anfang der Kosten, nicht das Ende. Bei einer Standardlösung zahlst du meist eine Lizenz pro Nutzer und Monat, dazu kommen oft Kosten für die Einrichtung, für Schulung, für zusätzliche Module und für die Anbindung an deine bestehenden Systeme. Diese Integrationskosten unterschätzen viele am stärksten. Wenn das neue Produkt mit deiner Buchhaltung oder deinem Warenwirtschaftssystem reden muss, kann diese Brücke teurer werden als die Lizenz selbst. Wie sich solche Kosten zusammensetzen, habe ich in Schnittstellen und ERP-Anbindung, was kostet das? ausführlicher beschrieben.

Der zweite Punkt ist der Lock-in, also die Frage, wie schwer du da wieder rauskommst. Kommst du an deine Daten ran, in einem Format, mit dem du etwas anfangen kannst? Oder liegen sie in einem proprietären System, das dich beim Wechsel praktisch enteignet? Was passiert, wenn der Anbieter die Preise verdoppelt oder das Produkt einstellt? Lock-in ist kein theoretisches Risiko, er bestimmt deine Verhandlungsposition für die ganze Laufzeit. Worauf du dabei konkret achten solltest, steht in Vendor-Lock-in vermeiden.

Rechne über einen realistischen Zeitraum, drei bis fünf Jahre. Eine Lösung, die in der Anschaffung günstig ist, aber pro Nutzer abrechnet, wird teuer, wenn dein Team wächst. Eine Lösung mit hohen Einmalkosten kann über die Jahre günstiger sein. Erst diese Gesamtrechnung macht zwei Produkte vergleichbar, und sie ist auch die Grundlage, wenn du die Ausgabe intern begründen musst, wie in Software-Investition begründen gezeigt.

Schritt fünf: Entscheiden und die Entscheidung festhalten

Nach vier Schritten hast du alles, was du brauchst. Jetzt geht es darum, die Entscheidung zu treffen und so zu dokumentieren, dass sie nachvollziehbar bleibt.

Geh deine zwingenden Kriterien durch. Welcher Kandidat erfüllt sie, ohne dass du deinen Prozess unnatürlich verbiegen musst? Oft schält sich hier ein klarer Sieger heraus. Wenn zwei Produkte gleichauf liegen, entscheiden die weichen Faktoren: das Gefühl deines Teams aus dem Test, die Verlässlichkeit des Anbieters, die Frage, bei wem du dich für die nächsten Jahre besser aufgehoben fühlst.

Halt schriftlich fest, warum du dich so entschieden hast. Das klingt nach Bürokratie, ist aber Gold wert. In einem Jahr, wenn jemand fragt, warum ihr nicht das andere Produkt genommen habt, hast du eine Antwort, die nicht aus dem Gedächtnis kommt. Und falls die Lösung doch nicht hält, was sie versprach, siehst du genau, welche Annahme falsch war, und lernst für das nächste Mal.

Wann sich der Eigenbau gegen die Standardlösung durchsetzt

Manchmal endet eine saubere Evaluation mit dem Ergebnis, dass kein fertiges Produkt passt. Das ist ein legitimes Ergebnis, kein Scheitern. Es lohnt sich allerdings nur in wenigen, klar erkennbaren Fällen.

Der stärkste Grund ist ein Prozess, der dein Geschäft von der Konkurrenz unterscheidet. Wenn das, was deine Software können müsste, genau das ist, womit du Geld verdienst, dann willst du es nicht in ein Produkt giessen, das deine Wettbewerber genauso kaufen können. Eine Standardlösung macht dich austauschbar, ein eigenes System kann ein Vorsprung sein. Der zweite Grund sind Anforderungen, die so speziell sind, dass jede Standardlösung an ihnen zerbricht, und die du im Test (Schritt drei) auch wirklich getestet hast, nicht nur vermutet. Diese Abwägung im Detail haben wir in Standard-Tool anpassen oder eigenes bauen? auseinandergenommen.

Gegen den Eigenbau spricht fast immer der Betrieb. Eine eigene Software baust du nicht einmal, du betreibst sie für Jahre. Updates, Sicherheit, Ausfälle, neue Anforderungen, das alles liegt dann bei dir. Wer Wortfreunde und Reazon selbst betreibt, weiss, dass dieser Teil der eigentliche Aufwand ist, nicht das erste Release. Eine Standardlösung nimmt dir genau das ab, und das ist ihr grösster Wert. Solange ein fertiges Produkt deine zwingenden Kriterien erfüllt und du mit dem Lock-in leben kannst, ist es fast immer die ruhigere Wahl.

Wenn die Evaluation aber zeigt, dass du wirklich etwas Eigenes brauchst, dann lohnt sich der Blick in unsere Leistungen rund um Individualsoftware für KMU. Wichtig ist nur die Reihenfolge: erst prüfen, ob es das fertige Produkt schon gibt, dann bauen. Diese fünf Schritte sorgen dafür, dass am Ende eine Entscheidung steht, die du belegen kannst, und nicht ein Bauchgefühl, das eine Demo dir eingeredet hat.