Ein ERP-Projekt kann auf der Website eines Softwarehauses überzeugend aussehen und im eigenen Betrieb dennoch scheitern.
Der Grund liegt selten bei der Programmiersprache.
Entscheidend sind Prozessverständnis, Schnittstellenwissen und die Bereitschaft, nach dem Go-live Verantwortung zu übernehmen.
Wer ein Softwarehaus Referenzen prüfen möchte, sollte daher nicht bei Logos und kurzen Erfolgsgeschichten stehen bleiben.
Gerade bei Individualsoftware ist eine Referenz kein Gütesiegel zum Abhaken. Sie zeigt, ob ein Entwicklungspartner vergleichbare fachliche, technische und organisatorische Herausforderungen bereits zuverlässig gelöst hat. Für österreichische Mittelstands- und Industrieunternehmen reduziert eine sorgfältige Prüfung das Projektrisiko deutlich.
Was Referenzen tatsächlich aussagen
Eine lange Kundenliste sagt zunächst nur, dass ein Anbieter Projekte gewonnen hat. Ob daraus eine funktionierende, langfristig betreute Lösung entstanden ist, bleibt offen. Aussagekräftig wird eine Referenz erst dann, wenn klar ist, welches Problem gelöst wurde, welche Rahmenbedingungen bestanden und welches Ergebnis im laufenden Betrieb erreicht wurde.
Bei einer Webanwendung für einfache interne Freigaben sind andere Fähigkeiten gefragt als bei einer individuellen ERP-Lösung, die Produktion, Lager, Außendienst und Finanzdaten verbindet. Ebenso unterscheidet sich ein einmaliges Digitalprojekt von einer Lösung, die täglich Maschinenzustände übernimmt, Lieferscheine erzeugt oder tausende Datensätze mit Fremdsystemen abgleicht.
Achten Sie deshalb weniger auf die Bekanntheit des Referenzkunden als auf die Übertragbarkeit. Ein Betrieb aus derselben Branche ist hilfreich, aber nicht zwingend erforderlich. Wesentlicher ist, ob die Anforderungen ähnlich sind: viele Ausnahmen im Prozess, historisch gewachsene Daten, Schnittstellen zu bestehenden Systemen, hohe Verfügbarkeit oder klare Nachweispflichten.
Softwarehaus-Referenzen prüfen: Die richtige Tiefe zählt
Gute Referenzen beschreiben nicht nur das fertige System, sondern auch den Weg dorthin. Fragen Sie konkret nach Ausgangslage, Projektumfang, Rollen und Betrieb. Ein verlässlicher Partner kann nachvollziehbar erklären, warum bestimmte Entscheidungen getroffen wurden und wo im Projekt Anpassungen notwendig waren.
Besonders aufschlussreich sind Projekte, bei denen nicht alles von Beginn an eindeutig war. In der Realität entstehen Anforderungen oft erst, wenn Fachabteilungen mit einem ersten Prototyp arbeiten oder wenn Daten aus einem Altsystem genauer analysiert werden. Ein Softwarehaus sollte zeigen können, wie es solche Änderungen strukturiert aufnimmt, priorisiert und transparent in Zeit- und Budgetplanung überführt.
Bei Referenzgesprächen mit bestehenden Kunden sollten Sie nicht nur nach Zufriedenheit fragen. Zufriedenheit ist subjektiv und wird häufig pauschal beantwortet. Besser sind Fragen nach konkreten Erfahrungen:
- Wie gut hat das Team die betrieblichen Abläufe verstanden?
- Waren Zuständigkeiten, Termine und Kosten während des Projekts nachvollziehbar?
- Wie wurden Änderungswünsche und unerwartete Probleme behandelt?
- Ist der Ansprechpartner nach dem Produktivstart weiterhin erreichbar?
- Welche Verbesserungen oder Einschränkungen wurden erst im laufenden Betrieb sichtbar?
- Würde das Unternehmen denselben Partner wieder beauftragen?
Die letzte Frage ist oft die ehrlichste.
Sie ersetzt keine fachliche Prüfung, ergänzt sie aber um die Perspektive der Zusammenarbeit unter realen Bedingungen.
Nicht nur das Schaufensterprojekt bewerten
Manche Referenzen sind besonders vorzeigbar: eine moderne App, ein klares Dashboard oder ein bekannter Kundenname. Für Ihre Entscheidung können gerade die weniger sichtbaren Projekte relevanter sein. Eine Schnittstelle zwischen Produktionsanlage und Warenwirtschaft, die Verarbeitung komplexer Dokumente oder die Ablöse einer fehleranfälligen Excel-Landschaft zeigt meist mehr über technische Sorgfalt als eine schöne Oberfläche allein.
Fragen Sie daher, welche Systeme integriert wurden, wie Datenqualität abgesichert wird und was passiert, wenn eine externe Schnittstelle nicht verfügbar ist. Bei kritischen Abläufen braucht es klare Regeln für Fehlerfälle, Berechtigungen, Protokollierung und Wiederanlauf. Das ist selten spektakulär, entscheidet aber über die Alltagstauglichkeit.
In wenigen Schritten zu Ihrem Projekt.
Vergleichbare Probleme sind wichtiger als gleiche Branchen
Ein Logistikunternehmen und ein Produktionsbetrieb haben unterschiedliche Geschäftsmodelle. Beide können jedoch ähnliche Anforderungen an mobile Datenerfassung, Statusverfolgung, Freigaben oder die Anbindung von Geräten haben. Ein Dienstleister mit vielen kundenspezifischen Aufträgen kann wiederum ähnliche Herausforderungen bei Kalkulation, Dokumentation und Ressourcenplanung haben wie ein technischer Handelsbetrieb.
Deshalb lohnt es sich, Referenzen nach Problemtypen zu sortieren. Dazu zählen etwa die Modernisierung eines Altsystems, die Einführung eines individuellen ERP-Moduls, die Integration mehrerer Datenquellen oder die Automatisierung dokumentenintensiver Prozesse. Bei KI-gestützten Lösungen sollte zusätzlich klar werden, welche Aufgaben automatisiert werden, wie Ergebnisse kontrolliert werden und wo Menschen weiterhin entscheiden.
Eine gute Referenz zeigt auch Grenzen. Kein seriöser Entwicklungspartner wird behaupten, dass jedes Projekt ohne Anpassungen oder Lernphasen läuft. Transparenz über anspruchsvolle Punkte ist ein Zeichen dafür, dass Risiken nicht erst angesprochen werden, wenn sie bereits Kosten verursachen.
Technische Qualität hinter der Referenz erkennen
Entscheider müssen keine Softwarearchitektur bewerten können. Sie sollten jedoch verstehen, ob die Lösung langfristig wartbar, erweiterbar und unabhängig betrieben werden kann. Fragen Sie, wie der Quellcode dokumentiert wird, wer Zugriff darauf hat und wie sich die Software weiterentwickeln lässt.
Das ist besonders relevant, wenn eine Individualsoftware zentrale Unternehmensprozesse abbildet. Gehört der Source Code dem Auftraggeber, bleibt das Unternehmen handlungsfähig. Es kann die Lösung mit dem bestehenden Partner ausbauen oder bei Bedarf an ein anderes Team übergeben. Dieses Eigentumsmodell ist nicht in jedem Projekt zwingend, bei geschäftskritischer Software schafft es jedoch klare Verhältnisse.
Auch die Betriebsfrage gehört zur Referenzprüfung.
Betriebsfragen
Wird die Anwendung in einer Cloud-Umgebung, auf eigenen Servern oder in einer Mischform betrieben? Gibt es geregelte Updates, Sicherungen und Zugriffsrechte? Wie werden Sicherheitslücken behandelt?
Die passende Antwort hängt von Datenschutz, internen IT-Vorgaben und Verfügbarkeit ab. Wichtig ist, dass der Anbieter die Entscheidung fachlich begründet und nicht eine Standardlösung für jeden Fall verkauft.
Auf Dauer der Zusammenarbeit achten
Eine abgeschlossene Referenz kann wertvoll sein, aber langfristige Kundenbeziehungen sagen oft mehr aus. Individualsoftware verändert sich mit dem Unternehmen: neue Standorte, zusätzliche Produkte, geänderte Vorschriften oder neue Schnittstellen schaffen laufend Anpassungsbedarf.
Fragen Sie daher, wie lange die referenzierten Systeme bereits produktiv sind und welche Weiterentwicklungen danach umgesetzt wurden. Ein Partner, der eine Lösung über Jahre betreut, kennt nicht nur den Code. Er versteht auch, welche Funktionen im Arbeitsalltag wirklich genutzt werden und welche Änderungen unerwartete Folgen haben können.
Regionalität ist dabei kein Selbstzweck. Für österreichische Unternehmen kann ein regionales Team mit festen Ansprechpartnern die Abstimmung wesentlich erleichtern, insbesondere wenn Fachabteilungen, Produktion und IT eng zusammenarbeiten müssen. Kurze Wege ersetzen kein gutes Projektmanagement, sie verbessern aber die Verbindlichkeit und das gemeinsame Verständnis.
Warnsignale bei der Referenzprüfung
Allgemeine Referenzen
Vorsicht ist angebracht, wenn Referenzen ausschließlich allgemein bleiben. Aussagen wie „effizientere Prozesse“ oder „erfolgreiche Digitalisierung“ sind ohne Ausgangslage und messbaren Nutzen wenig wert. Dasselbe gilt, wenn ein Anbieter keine technischen Fragen beantworten kann oder Referenzkunden nicht für ein Gespräch freigeben möchte.
Unrealistische Versprechen
Ein weiteres Warnsignal sind unrealistische Versprechen. Komplexe Software lässt sich nicht seriös allein aus einem kurzen Erstgespräch pauschal kalkulieren. Ein guter Partner grenzt zunächst den Bedarf ein, analysiert Prozesse und macht Annahmen sichtbar. Das kann mehr Vorbereitung verlangen, schützt aber vor Überraschungen im Projekt.
Wer hat umgesetzt?
Prüfen Sie auch, wer die Referenz tatsächlich umgesetzt hat. Bei manchen Anbietern übernimmt ein erfahrenes Team den Vertrieb, während Entwicklung und Wartung später an wechselnde externe Ressourcen gehen. Das muss nicht grundsätzlich problematisch sein. Für langfristige Individualsoftware sollten Verantwortlichkeiten, Kompetenzen und Erreichbarkeit aber klar geregelt sein.
Referenzen mit dem eigenen Projekt abgleichen
Die Referenzprüfung wirkt am besten, wenn Ihr eigenes Vorhaben bereits grob beschrieben ist. Halten Sie fest, welche Prozesse verbessert werden sollen, welche Systeme angebunden werden müssen und welche Ziele Priorität haben. Geht es primär um Zeitersparnis, weniger Fehler, bessere Planung, nachvollziehbare Dokumentation oder um eine skalierbare Basis für weiteres Wachstum?
Mit dieser Grundlage können Sie einem Softwarehaus konkrete Szenarien vorlegen. Bitten Sie nicht nur um eine Präsentation, sondern um eine Einschätzung: Welche ähnlichen Herausforderungen gab es? Welche Risiken sieht das Team? Welche Fragen müssen vor einer belastbaren Planung geklärt werden? An den Rückfragen erkennen Sie häufig schneller als an einer Hochglanzreferenz, ob echtes Verständnis vorhanden ist.
X-WORKS setzt bei solchen Gesprächen auf eine klare Bedarfsklärung, weil eine passende Lösung nicht bei der Technologie beginnt, sondern beim tatsächlichen Ablauf im Unternehmen. Erst wenn Prozesse, Daten und Verantwortlichkeiten verstanden sind, lässt sich entscheiden, welche Individualsoftware sinnvoll ist.
Die beste Referenz ist am Ende nicht jene mit dem größten Namen. Sie ist jene, in der Sie Ihre eigenen Herausforderungen wiedererkennen und deren Kunde glaubwürdig schildern kann, wie aus einem komplexen Anliegen eine verlässliche Lösung im täglichen Betrieb wurde. Nehmen Sie sich für diese Gespräche Zeit - sie ist meist deutlich günstiger als eine spätere Kurskorrektur im Projekt.
Eigenes Vorhaben vorlegen (30 min)
Sie planen ein konkretes Softwareprojekt, möchten ein bestehendes System weiterentwickeln oder ablösen.
FAQ – Frequently Asked Questions
Häufig gestellte Fragen
