Wie du Business-Software strukturiert auswählst oder ausschreibst – und woran du erkennst, dass der klassische Weg für dich der falsche ist.
TL;DR – Die 3 wichtigsten Punkte
- Die meisten Fehlentscheidungen fallen vor dem ersten Angebot: Unklare Anforderungen erzeugen beliebige Vergleiche – und beliebige Vergleiche erzeugen die falsche Software.
- Wer Individualentwicklung einkauft, vergleicht keine Produkte, sondern Teams, Vorgehen und Architektur. Die komplette Ausschreibungslogik ändert sich.
- Kriterien wie Code-Eigentum, Datenexport und EU-Hosting stehen in kaum einer Vergleichsmatrix – sie entscheiden aber darüber, wie frei du in fünf Jahren noch bist.
Was dir dieser Beitrag bringt
Du bekommst den kompletten Ablauf einer Softwareauswahl aus Entscheidersicht: von der Anforderungsaufnahme über Shortlist und Bewertung bis zur Frage, wie du Entwicklung vertraglich einkaufst. Dazu die Kriterien, die in den üblichen Vergleichsmatrizen fehlen, und die ehrliche Antwort darauf, wann du dir eine klassische Ausschreibung sparen solltest. Keine Vorlagensammlung, sondern ein Entscheidungsrahmen für Geschäftsführer.
Warum die Softwareauswahl Chefsache ist
Eine Softwareentscheidung ist keine IT-Entscheidung – sondern eine Strukturentscheidung. Das gewählte System bestimmt, wie dein Unternehmen arbeitet: wer was sieht, wer was freigibt, wer was verantwortet. Die Lizenzkosten sind dabei oft der kleinste Posten. Teuer wird die Reibung: Workarounds, Doppelerfassung, die Excel-Liste neben dem System, E-Mail als Kleber.
Dazu kommt die Bindung. Ein eingeführtes System wächst in deine Prozesse hinein. Mitarbeiter lernen es. Schnittstellen docken an. Daten sammeln sich. Nach zwei Jahren wechselt niemand mehr „mal eben" das System. Jede Auswahl ist eine Entscheidung für viele Jahre – getroffen in wenigen Wochen.
Genau deshalb gehört sie auf deinen Tisch. Nicht, weil du jede Funktion bewerten musst – sondern weil nur du beurteilen kannst, wohin das Unternehmen will und ob das System diesen Weg trägt. Mehr zu diesem Muster: Operative Komplexität Software ist schnell gekauft – Struktur nicht.
Die Entscheidung vor der Entscheidung: Standard oder individuell?
Bevor du Anbieter vergleichst, klär die Grundsatzfrage: Kaufst du ein Produkt, oder lässt du entwickeln? Für Standardprozesse ist Standardsoftware die richtige Antwort. Buchhaltung, Lohn, E-Mail: erprobt, günstig, sofort verfügbar. Und ein gutes ERP bleibt ein gutes ERP.
Anders sieht es dort aus, wo deine Wertschöpfung entsteht: Disposition, Projektsteuerung, die Sonderfälle, die kein Produkt von der Stange kennt. Standardsoftware bildet Durchschnitt ab. Dein Unternehmen ist kein Durchschnitt. Je näher ein Prozess an deinem Wettbewerbsvorteil liegt, desto schlechter passt die Durchschnittslösung.
Diese Vorentscheidung verändert alles Weitere. Ein Produkt vergleichst du über Funktionen, Referenzen und Preis. Eine Entwicklung vergleichst du über Menschen, Vorgehen und Architektur. Wer beides in dieselbe Ausschreibung packt, bekommt Angebote, die sich nicht vergleichen lassen. Mehr dazu: Standardsoftware vs. Individualsoftware Erst die Richtung klären – dann vergleichen.
Der Ablauf: fünf Phasen von der Anforderung bis zur Entscheidung
Eine belastbare Softwareauswahl folgt einem Trichter. Fünf Phasen, jede mit einem klaren Ergebnis:
Anforderungen erheben. Kernprozesse, Schmerzpunkte, Mengengerüst, Systemlandschaft. Ergebnis: ein priorisiertes Anforderungsprofil – kein Wunschzettel.
Markt sichten. Eine Longlist möglicher Anbieter oder Partner, grob geprüft gegen deine K.o.-Kriterien. Ergebnis: acht bis zwölf Kandidaten.
Shortlist bilden. Die Longlist gegen das Anforderungsprofil verdichten. Ergebnis: drei bis fünf Anbieter, die eine echte Prüfung verdienen.
Prüfen statt vorführen lassen. Workshops mit deinen eigenen Use Cases und deinen Daten – nicht die polierte Standard-Demo. Ergebnis: belegte Bewertungen statt Eindrücke.
Entscheiden und verhandeln. Bewertung, Referenzgespräche, Vertragsmodell, Eigentumsfragen. Ergebnis: eine Entscheidung, die du begründen kannst.
Der Trichter selbst ist simpel – die Disziplin, ihn einzuhalten, ist die eigentliche Arbeit.
Anforderungen erheben – ohne ein Lastenheft-Monster zu bauen
Das klassische Scheitern beginnt mit einer Tabelle: 200 Zeilen Anforderungen, eingesammelt aus allen Abteilungen, jede Zeile „wichtig". Das ist kein Fehler des Unternehmens – es ist der normale Reflex, wenn Struktur fehlt. Nur hilft er nicht. Drei Fallen stecken in fast jedem Lastenheft:
- Scheingenauigkeit. 200 ungewichtete Anforderungen sind keine Klarheit, sondern Lärm. Ohne Priorisierung in Muss, Soll und Kann kann kein Anbieter seriös kalkulieren – und jeder Vergleich wird beliebig.
- Lösungen statt Probleme. „Wir brauchen ein Dropdown für Ersatzartikel" ist keine Anforderung – sondern eine verkleidete Lösung. Beschreib den Prozess und das Problem. Die Lösung ist Aufgabe des Anbieters.
- Veraltung. Ein Lastenheft, an dem sechs Monate geschrieben wurde, beschreibt beim Projektstart ein Unternehmen, das es so nicht mehr gibt.
Besser: zehn bis fünfzehn Kernprozesse als Use Cases beschreiben, mit echten Mengen und echten Sonderfällen. Wo läuft ein Auftrag heute durchs Haus? Wo bricht die Information ab? Wo landet die Krankmeldung um 5:30 Uhr?
Ein gutes Anforderungsprofil beschreibt dein Geschäft – nicht deine Featureliste.
Von der Longlist zur Shortlist: Kriterien mit Gewicht
Vergleichbar wird die Auswahl erst durch eine gewichtete Kriterienmatrix. Der Aufbau ist unspektakulär: Kriterien aus dem Anforderungsprofil ableiten, gewichten, jeden Kandidaten auf derselben Skala bewerten. Entscheidend sind zwei Regeln.
Erstens: K.o.-Kriterien zuerst. Was zwingend ist – etwa eine funktionierende Anbindung an dein Buchhaltungssystem oder Hosting in der EU – wird nicht gewichtet, sondern geprüft. Wer durchfällt, fliegt. Das hält den Trichter schlank.
Zweitens: Bewertet wird, was belegt ist. Eine Zusage im Vertriebsgespräch ist kein Beleg. Ein Nachweis am eigenen Use Case ist einer. Lass dir nicht zeigen, was das System kann – lass zeigen, wie es deinen Fall löst.
Die Matrix ersetzt nicht dein Urteil – sie macht es überprüfbar.
Was in eine Software-Ausschreibung gehört
Ob du sie Ausschreibung, Anfrage oder RFP nennst: Das Dokument, das du an Anbieter schickst, entscheidet über die Qualität der Angebote. Hinein gehört:
- Ausgangslage und Zielbild
Was heute wie läuft, was sich ändern soll. Ehrlich, inklusive der Altlasten.
- Kernprozesse als Use Cases
Die zehn bis fünfzehn Abläufe, an denen sich jedes Angebot messen lassen muss.
- Mengengerüst
Nutzer, Aufträge, Artikel, Standorte. Ohne Mengen keine seriöse Kalkulation
- Systemlandschaft und Schnittstellen.
ERP hier, CRM dort, Excel dazwischen: Genau das muss der Anbieter vorher wissen.
- Priorisierte Anforderungen
Muss, Soll, Kann. Kurz und gewichtet schlägt lang und beliebig.
- Rahmenbedingungen
Zeitfenster, Budgetkorridor, Datenschutz, Hosting-Vorgaben, Entscheidungsweg.
- Deine Bewertungskriterien
Wer weiß, woran er gemessen wird, schreibt ehrlichere Angebote.
Eine gute Ausschreibung ist kein Fragenkatalog – sondern ein ehrliches Bild deines Unternehmens.
Individualentwicklung ausschreiben: Teams statt Produkte vergleichen
Schreibst du keine fertige Software aus, sondern eine Entwicklung, kippt die Logik. Es gibt kein Produkt, das du testen könntest. Du vergleichst stattdessen, wer baut und wie gebaut wird. Drei Fragen trennen die Kandidaten schneller als jede Featureliste:
- Wer arbeitet an deinem Projekt? Eigene Entwickler oder wechselnde Subunternehmer? Sprichst du mit Menschen, die den Code verstehen – oder mit einer Vertriebsschicht, die jede Frage erst „mitnehmen" muss? Übersetzungsverluste zwischen Business und Code sind einer der häufigsten Gründe, warum Projekte haken.
- Wie geht der Anbieter mit Unklarheit um? Ein seriöser Partner stellt Rückfragen, benennt Risiken und widerspricht dir, wenn eine Anforderung keinen Sinn ergibt. Ein 80-Seiten-Festpreisangebot auf ein vages Lastenheft ist kein Qualitätsmerkmal – sondern ein Warnsignal.
- Denkt der Anbieter in Architektur oder in Features? Dein System soll wachsen, Schnittstellen tragen und in fünf Jahren noch erweiterbar sein. Das entscheidet sich am Fundament, nicht an der Oberfläche. Wie wir diese Fragen beantworten: Individuelle Softwareentwicklung
Du kaufst kein Produkt – du wählst, wem du dein Betriebssystem anvertraust.
Festpreis oder agil: Wie du Entwicklung einkaufst
Die Vertragsfrage spaltet den Markt in zwei Lager. Festpreis klingt nach Sicherheit, belohnt aber starre Pläne: Jede Erkenntnis während des Projekts wird zum Nachtrag. Rein agile Abrechnung klingt nach Flexibilität, verlagert aber das komplette Risiko zu dir: Bezahlt wird Aufwand, nicht Ergebnis.
Belastbar ist die Reihenfolge: erst eine strukturierte Analyse, die Scope und Architektur klärt. Dann ein Festpreis für die erste Ausbaustufe – denn jetzt ist klar, was gebaut wird. Danach Weiterentwicklung in kurzen Zyklen mit festem Monatskontingent, priorisiert von dir, jederzeit anpassbar. So trägt jede Phase das Risiko, das zu ihr passt. Wie das konkret abläuft: Unser Projektablauf Nicht Festpreis oder agil – sondern beides, in der richtigen Reihenfolge.
Die Kriterien, die in keiner Matrix stehen
Die üblichen Vergleichsmatrizen prüfen Funktionen, Preis und Usability. Was sie selten prüfen, entscheidet über deine Freiheit in fünf Jahren:
| Kriterium | Frag den Anbieter | Warum es zählt |
|---|---|---|
| Eigentum an Code und Daten | Gehören dir Quellcode und Datenbank – oder mietest du dauerhaft eine Blackbox? | Steht davon nichts im Vertrag, lautet die Antwort: Blackbox. |
| Exit-Fähigkeit | Bekommst du deine Daten in offenen, dokumentierten Formaten heraus? | Ein Anbieterwechsel, der praktisch unmöglich ist, macht jede Preisverhandlung zur Farce. |
| Hosting und Datenschutz | Wo liegen die Daten, wer hat Zugriff, gibt es einen Auftragsverarbeitungsvertrag? | Die DSGVO verlangt angemessene technische und organisatorische Maßnahmen. |
| Wartbarkeit und Dokumentation | Kann ein anderes Team den Code übernehmen? | Frag danach, und beobachte, wie selbstverständlich die Antwort kommt. |
| Schlüsselpersonen-Risiko beim Anbieter | Hängt dein System an einer einzigen Person? | Dann hast du das „Frag Peter"-Problem nur ausgelagert – nicht gelöst. |
Was in deinem Fall angemessen ist, klärst du mit deinem Datenschutzbeauftragten. Dieser Beitrag ersetzt keine Rechtsberatung.
Frei bleibt, wer den Exit mitdenkt, bevor er einsteigt.
Typische Fehler bei der Softwareauswahl
- Die Demo entscheidet. Vorführungen zeigen, was der Anbieter zeigen will. Dein Alltag kommt darin nicht vor, es sei denn, du bringst ihn selbst mit.
- Nur ein Kandidat wird ernsthaft geprüft. Ohne Vergleich fehlt dir jeder Maßstab, fachlich wie preislich. Mindestens zwei Anbieter gehören in die Endrunde.
- Der Lizenzpreis ersetzt die Gesamtrechnung. Einführung, Anpassung, Schnittstellen, Schulung, Betrieb: Über die Nutzungsdauer gerechnet verschieben sich die Verhältnisse oft deutlich.
- Die Nutzer kommen zuletzt. Wer täglich mit dem System arbeitet, erkennt Praxislücken sofort – und entscheidet später über die Akzeptanz.
- Das Projekt endet mit der Unterschrift. Die Auswahl ist die halbe Arbeit. Einführung, Datenübernahme und Change entscheiden über den Rest. Ein klassisches Muster aus der Praxis: ERP-Einführung: Ablauf, Kosten und typische Fehler
Jeder dieser Fehler ist vermeidbar – mit Prozess statt Bauchgefühl.
Wann eine klassische Ausschreibung der falsche Weg ist
Was, wenn du gar nicht genau weißt, was du ausschreiben sollst? Viele Unternehmen stehen genau dort: Das Geschäft läuft, aber ERP hier, CRM dort, Excel dazwischen. Jedes System funktioniert – bis es nicht mehr funktioniert. Die operative Komplexität ist größer geworden als die Systeme, die sie steuern.
In dieser Lage liefert eine Ausschreibung zuverlässig nur eins: Angebote für das falsche Problem. Denn das Problem ist nicht das fehlende Produkt – sondern die fehlende Struktur dahinter. Software allein löst keine strukturellen Probleme. Noch mehr Software erst recht nicht.
Der belastbare erste Schritt ist dann keine Ausschreibung, sondern eine Analyse:
Ist-Zustand → Schmerzpunkte → Architekturentwurf → Umsetzungsfahrplan.
Erst wenn klar ist, welches System dein Unternehmen braucht, lohnt der Vergleich, wer es bauen soll. Was so eine Analyse leistet: Das System-Audit Wer das falsche Problem ausschreibt, bekommt die falsche Lösung – nur sehr gründlich verglichen.
Wie du startest
Fang nicht mit der Longlist an. Fang mit Klarheit an: Welche Prozesse tragen dein Geschäft, wo entsteht Reibung, was soll in drei Jahren anders sein? Mit diesem Bild wird die Auswahl schneller – und die Ausschreibung ehrlicher.
Wenn du dir dieses Bild strukturiert erarbeiten willst, ist das System-Audit dafür gebaut: eine Analyse von Ist-Zustand, Schmerzpunkten, Architektur und Fahrplan – als eigenständige Leistung. Der Report gehört dir – auch wenn du danach nicht mit uns arbeitest. Du kannst damit ausschreiben, vergleichen oder intern entscheiden.
Technologie soll Menschen freier machen. Auch und gerade bei der Softwareauswahl: frei von Bauchentscheidungen, frei von Abhängigkeiten, frei von Systemen, die nicht passen. Wir verwandeln operativ komplexe Mittelständler in Tech-Unternehmen.
Die beste Ausschreibung beginnt nicht beim Anbieter – sondern bei dir.
See what's possible