
Individualsoftware beschaffen: Das 2026-Playbook für Einkäufer in 7 Schritten
Individualsoftware-Beschaffung ist der Prozess, maßgeschneiderte Software bei einem externen Entwicklungsdienstleister in Auftrag zu geben: Business Case, Leistungsbeschreibung, RFP, Anbieterbewertung, Vertrag und der Abnahmetest, der das Projekt abschließt. Sie ist kein Produkt. Sie ist ein Einkaufsprozess, den Sie selbst durchführen.
Wer danach sucht, bekommt von Google neun Tool-Kataloge und eine 900-Wörter-Richtlinie der UCLA. Der Prozess selbst bleibt unbeleuchtet, weil Tool-Anbieter schreiben, was rankt. Dieser Leitfaden beantwortet die zweite Frage: Wie kauft man Software, die es noch gar nicht gibt?
Die wichtigsten Erkenntnisse:
- Individualsoftware-Beschaffung ist der Prozess, maßgeschneiderte Software bei einem Anbieter in Auftrag zu geben, nicht der Kauf eines Einkaufstools.
- Ein vollständiger Beschaffungslauf umfasst 7 Schritte vom Business Case bis zur Abnahme, in der Regel 10–16 Wochen vor Entwicklungsbeginn.
- Neun Vertragsklauseln schützen Ihr Budget; IP-Eigentum, Abnahmekriterien und Meilensteinzahlungen wirken am stärksten.
Individualsoftware-Beschaffung ist keine Beschaffungssoftware
Beschaffungssoftware ist ein Tool, das den Einkauf automatisiert: Bestellungen, Freigaben, Rechnungen, Lieferantenkataloge. Individualsoftware-Beschaffung ist der Prozess, maßgeschneiderte Software bei einem Entwicklungsdienstleister zu beauftragen. Das eine ist ein Produkt, das Sie lizenzieren. Das andere ist ein Projekt, das Sie durchführen, mit Vertrag und Abnahmetest. Dieser Leitfaden behandelt das Zweite.
Die Verwechslung ist verständlich: Der Tool-Markt ist riesig und gut abgedeckt. Das Anbieterverzeichnis von Art of Procurement listet über 200 Plattformen in 19 Kategorien, und der Einkaufsleitfaden 2026 von Brex vergleicht auf knapp 4.000 Wörtern fünf davon. Niemand in diesem Stapel erklärt, wie man Software von Grund auf in Auftrag gibt. Genau diese Lücke füllt dieser Beitrag.
Vorab: Ist Individualsoftware wirklich die richtige Wahl?
Individualsoftware ist die richtige Wahl, wenn die Software zum Kern Ihrer Arbeitsweise gehört und kein bestehendes Produkt ohne Provisorien in Ihren Workflow passt. Sie ist die falsche Wahl, wenn ein lizenziertes Produkt bereits 80 % des Bedarfs abdeckt. Entscheiden Sie ehrlich, bevor Sie einen einzigen Euro in eine RFP für Individualsoftware stecken.
| Option | Gewinnt, wenn | Risiken |
|---|---|---|
| Standard-SaaS | Der Bedarf generisch ist (Lohnbuchhaltung, CRM, Rechnungswesen) und 80 % Abdeckung reichen | Pro-Sitz-Gebühren summieren sich; Sie mieten und besitzen nie |
| Plattform anpassen | Eine Plattform passt weitgehend und Ihr Sonderfall ist Konfiguration, kein Neubau | Anpassungsschulden; Upgrades zerstören Ihre Modifikationen |
| Vollständige Eigenentwicklung | Die Software ist Ihr Prozess, Wettbewerber können sie nicht kaufen und Sie brauchen das IP | Sie tragen das Entwicklungsrisiko, also muss der Vertrag es zuordnen |
Sie sind noch unsicher, welche Zeile auf Sie zutrifft? Unser Scoring-Framework für Selbermachen oder Kaufen beantwortet das Ob; dieser Leitfaden beantwortet die Folgefrage, wie Sie das Kaufen dann durchführen.
Dann halten Sie den Business Case schriftlich fest. Eine Einseiter-Vorlage zur Kaufrechtfertigung genügt:
Problem: What is broken, in one sentence
Current cost: What it costs today (hours per week x rate, or lost revenue)
Outcome: The measurable result the software must produce
Ceiling: The maximum budget, and the date the money runs outAuch eine Zwei-Personen-Beschaffung profitiert von einer schriftlichen Beschaffungsrichtlinie: ein Absatz darüber, wer Ausgaben freigibt und wer unterschreibt. Das verhindert das Chaos nach dem Muster "der Gründer hat es im Call abgesegnet", das Abnahmen gefährdet.
Der 7-Schritte-Prozess für die Individualsoftware-Beschaffung
Der Beschaffungsprozess für Individualsoftware hat sieben Schritte, und sechs davon passieren, bevor irgendjemand Code schreibt. Der gesamte Ablauf, je eine Zeile:
- Bedarf und Business Case: nachweisen, dass das Problem Geld wert ist
- Leistungsbeschreibung (SOW): exakt aufschreiben, was "fertig" bedeutet
- Marktscan: Anbieter in die engere Wahl nehmen, die diese Art von Arbeit machen
- RFP / RFQ: allen dasselbe Briefing schicken
- Anbieterbewertung: Antworten nach Belegen bewerten, nicht nach Bauchgefühl
- Verhandlung und Vertrag: die neun Klauseln schriftlich fixieren
- Lieferung und Abnahme: gegen die Kriterien aus Schritt 2 testen
Diese Spannen sind unsere Interpretation typischer KMU-Projekte, kein gemessener Benchmark: eine freihändige Verlängerung läuft in drei Wochen durch, eine regulierte Ausschreibung dauert sechs Monate.
| Phase | Typische Wochen | Erzeugtes Artefakt | Verantwortlich |
|---|---|---|---|
| 1. Bedarf und Business Case | 1–2 | Einseitige Kaufrechtfertigung | Sie (Käufer) |
| 2. Leistungsbeschreibung | 2–4 | SOW plus Abnahmekriterien | Sie, mit Anbieter-Input |
| 3. Marktscan | 1–2 | Anbieter-Shortlist mit 5–8 Namen | Sie |
| 4. RFP / RFQ | 2–3 | Versendetes Briefing und Antworten | Sie, dann Anbieter |
| 5. Anbieterbewertung | 1–2 | Ausgewertete Scorecard | Sie |
| 6. Verhandlung und Vertrag | 2–3 | Unterschriebener Vertrag | Beide, plus Rechtsabteilung |
| 7. Lieferung und Abnahme | läuft durch die gesamte Entwicklung | Abnahmeunterschrift | Beide |
| Gesamt vor Entwicklungsbeginn | 10–16 | Unterschriebener Vertrag und testfähiges SOW | Sie |
1. Bedarf und Business Case
Starten Sie mit dem Einseiter oben. In unseren Projekten ändern genau die Aufträge mitten in der Entwicklung den Umfang, die diesen Schritt überspringen, dann nämlich, wenn Änderungen echtes Geld kosten statt eines Absatzes. Er setzt auch die Budgetobergrenze, die Sie in der RFP nennen.
2. Leistungsbeschreibung (SOW)
Eine Leistungsbeschreibung macht aus dem Business Case eine Spezifikation, über die beide Seiten streiten können: Features drin und draußen, Integrationen, Zeitplan und die Abnahmekriterien, an denen die Lieferung gemessen wird. So scoppen Sie ein Web-App-Projekt zahlt sich hier aus, oder scoppen Sie die Anforderungen mit KI für einen schnelleren Entwurf.
3. Marktscan
Erstellen Sie eine Shortlist von fünf bis acht Anbietern mit aktuellen, fachlich passenden Referenzen. Fragen Sie Kollegen, die Ähnliches ausgeliefert haben; prüfen Sie Case Studies für Ihre Branche, nicht Homepages. Überspringen Sie Verzeichnisse, die nach Vermittlungsprovision sortiert sind.
4. RFP / RFQ
Schicken Sie jedem Anbieter auf der Shortlist dasselbe Briefing und verlangen Sie dasselbe Antwortformat. Eine RFP (Request for Proposal) fragt, wie der Anbieter bauen würde; eine RFQ (Request for Quotation) fragt, was ein definierter Umfang kostet. Bei der Individualsoftware-Beschaffung kommt die RFP zuerst.
5. Anbieterbewertung
Bewerten Sie jede Antwort mit derselben Scorecard und gewichten Sie Referenzen und Code-Prüfrechte höher als den Preis. Das günstigste Angebot ist meist das, das den wenigsten Aufwand bepreist hat. Rufen Sie die Referenzen selbst an.
6. Verhandlung und Vertrag
Nehmen Sie das Gewinner-Angebot und ergänzen Sie die neun Klauseln unten. Verhandeln Sie zuerst Abnahmekriterien und Meilensteinzahlungen, den Preis zuletzt: Der Preis lässt sich am leichtesten verschieben, die Abnahme ist den Kampf wert.
7. Lieferung und Abnahme
Lieferung heißt nicht "der Code wurde geschickt". Abnahme bedeutet, dass die Software die SOW-Kriterien in Ihrer Umgebung besteht, mit unterschriebener IP-Übertragung und übergebenem Quellcode. Halten Sie die letzte Meilensteinzahlung zurück, bis dieser Test bestanden ist.
Die RFP, die Ihnen echte Angebote einbringt
Eine RFP ohne Abnahmekriterien ist ein Preisangebot für Arbeit, die niemand definiert hat. Das Gerüst unten ist die Vorlage für Individualsoftware-Beschaffung, die wir uns von jedem Einkäufer wünschen würden. Kopieren Sie es, füllen Sie die Lücken, und fünf Anbieter bepreisen einen Umfang statt fünf Vermutungen.
CUSTOM SOFTWARE RFP
1. Company context
Who you are, team size, the system this replaces or connects to
2. Problem statement
The broken process, what it costs you today, who feels it
3. Scope
In: the features and integrations the first release must ship
Out: anything you have decided to defer
4. Technical constraints
Stack preferences, hosting rules, compliance (GDPR, HIPAA), SSO
5. Timeline
Hard dates, and what happens if you miss them
6. Budget range
A ceiling, not a target. Vendors price to the number you give.
7. Acceptance criteria
The pass/fail tests the final delivery must clear before sign-off
8. Evaluation criteria
How you will score responses, and the weight of price vs. references
9. Response format
Page limits, the questions to answer, and the reply deadlineNennen Sie vor allem drei Dinge: Budgetobergrenze, Abnahmekriterien, Antwortformat. Sie sind es, die vage Pitches in vergleichbare Angebote verwandeln.
Streichen Sie drei Dinge: Implementierungsvorschriften ("Microservices verwenden"), NDAs vor der Shortlist, 40-seitige Anforderungsanhänge. Sie kaufen ein Ergebnis, keine Architektur.
Zwei praktische Hinweise: Schicken Sie allen Anbietern dasselbe Dokument, denn nur einheitliche Antworten machen eine Scorecard überhaupt aussagekräftig; und nennen Sie Ihre Bewertungsgewichte direkt in der RFP. Anbieter schreiben schärfere Angebote, wenn sie wissen, dass Referenzen schwerer wiegen als der Preis.
Wie bewertet man einen Anbieter für Individualsoftware?
Anbieterbewertung heißt, jedes Angebot mit derselben beleggewichteten Scorecard zu bewerten, damit die Entscheidung auch einem zweiten Blick standhält. Der Preis verdient weniger Gewicht, als die meisten Einkäufer ihm geben: Angebote, die den Markt unterbieten, haben in der Regel den wenigsten Aufwand bepreist. Die Scorecard, die wir für KMU-Budgets empfehlen:
| Kriterium | Gewicht | Bewertungshilfe |
|---|---|---|
| Fachlich passende Referenzen | 25 % | 5: zwei Referenzen, die Sie wirklich angerufen haben, in Ihrer Domäne. 1: eine Logo-Wand |
| Code-Prüfrechte | 15 % | 5: stimmt schriftlich einer Code-Prüfung durch Dritte vor der Schlusszahlung zu |
| Finanzielle Gesundheit | 10 % | 5: profitabel, mehrjährige Erfolgsbilanz. 1: kann sie nicht vorlegen |
| Sicherheitsaufstellung | 15 % | 5: dokumentierter SDLC, Dependency-Scanning, Least-Privilege-Zugriffe |
| Teamkontinuität und Betriebszugehörigkeit | 15 % | 5: namentlich benanntes Team, geringe Fluktuation. 1: "Personal planen wir nach Vertragsabschluss" |
| Kommunikationsrhythmus | 10 % | 5: wöchentliche Demo schriftlich zugesagt. 1: "Wir nutzen Slack" |
| IP-Disziplin | 10 % | 5: saubere Work-for-Hire-Übertragung, kein wiederverwendeter proprietärer Kern |
Die Gewichte sind ein Ausgangspunkt. Verschieben Sie sie ruhig, aber summieren Sie sie auf 100 und halten Sie sie schriftlich fest, bevor Sie auch nur ein Angebot lesen. So ranken wir Entwicklungsunternehmen wendet dieselbe Disziplin an; was Entwicklungsservices wirklich umfassen hilft Ihnen, Einzelposten Vergleichbar gegen Vergleichbar gegenüberzustellen.
Due-Diligence-Checkliste für den Softwarekauf
Führen Sie diese Liste bei den Top-2-Anbietern durch, bevor Sie unterschreiben, nicht bei allen fünf:
- Referenzen mit echten Fragen geprüft (was ist kaputtgegangen, wie wurde es gelöst, würden Sie wieder beauftragen)
- Code-Prüfrechte schriftlich vereinbart, vor der letzten Meilensteinzahlung
- Finanzielle Gesundheit bestätigt (Jahre am Markt, Profitabilität, Kundenkonzentration)
- Sicherheitsaufstellung geprüft (SDLC, Zugriffskontrolle, Vorfallhistorie)
- Kontinuität der Schlüsselpersonen bestätigt (das Pitch-Team ist das Projektteam)
- IP-Übertragung von Ihrem Anwalt geprüft, nicht von deren
9 Vertragsklauseln, die Ihr Budget schützen
Die Klausel, die Ihr Budget schützt, ist nicht der Preis. Es ist der Abnahmetest. Die Einkaufsempfehlung der UCLA, die einzige institutionelle Seite in Googles Top Ten zu diesem Thema, baut ihre Individualsoftware-Empfehlung um genau diesen Gedanken auf: Leistungsbeschreibung, IP-Eigentum, Abnahmetest und Gewährleistung, bevor der Preis überhaupt ins Spiel kommt. Wir haben diese Systematik zu neun Klauseln für gewerbliche Einkäufer erweitert.
Wenn Sie eine Vorlage für einen Softwarekaufvertrag zusammenstellen, sind diese neun Zeilen das Rückgrat:
| Nr. | Klausel | Warum sie wirkt | Einzeilige Beispielformulierung |
|---|---|---|---|
| 1 | IP-Eigentum / Work-for-Hire | Ohne sie behält der Anbieter das Urheberrecht und lizenziert die Software an Sie zurück | "Alle Liefergegenstände sind Work made for hire; mit Zahlung geht das gesamte IP an den Käufer über" |
| 2 | Abnahmekriterien und -verfahren | Die einzige objektive Definition von "fertig"; ohne sie werden Streitfragen zu Meinungsfragen | "Die Lieferung gilt erst als abgenommen, wenn alle Tests in Anlage B in der Käuferumgebung bestehen" |
| 3 | Meilenstein-gebundene Zahlungen | Hält das Geld hinter dem Fortschritt; beseitigt das 100-%-Voraus-Risiko | "20 % bei Kickoff, dann 20 % pro Meilenstein, 20 % bei Endabnahme" |
| 4 | Änderungssteuerung | Verhindert, dass aus Scope-Streitigkeiten Rechnungs-Streitigkeiten werden | "Scope-Änderungen erfordern einen schriftlichen Change Order mit Preis- und Terminauswirkung, von beiden Seiten unterschrieben" |
| 5 | Gewährleistungsfrist | Zwingt den Anbieter, nach der Übergabe für den Code einzustehen | "Der Anbieter behebt Mängel, die innerhalb von 90 Tagen nach Abnahme festgestellt werden, kostenlos" |
| 6 | Preissicherung | Begrenzt den Schadensradius optimistischer Schätzungen | "T&M-Sätze 12 Monate fest; Höchstgrenze nur mit schriftlicher Neufreigabe" |
| 7 | Leistungsmerkmale | Macht aus "ist langsam" einen Vertragsbruch, keine Beschwerde | "p95-Seitenladezeit unter 2 s; API-p99 unter 300 ms bei 500 gleichzeitigen Nutzern" |
| 8 | Schlüsselpersonal | Verhindert den Senior-Pitch-Junior-Bau-Wechsel | "Namentlich benannte Leads dürfen ohne schriftliche Zustimmung des Käufers nicht ausgetauscht werden" |
| 9 | Kündigung und Quellcode-Hinterlegung | Ihr Ausweg, wenn der Anbieter ins Stocken gerät, aufgibt oder geht | "Der Käufer kann aus wichtigem Grund mit 14 Tagen Frist kündigen; hinterlegter Quellcode wird bei Insolvenz freigegeben" |
Fehlt auch nur eine, finanzieren Sie eine Hoffnung. Hat Ihr Anwalt Zeit für drei Klauseln, geben Sie ihm 1, 2 und 3.
Was kostet Individualsoftware, und wie strukturieren Sie die Zahlung?
Der Umfang bestimmt den Preis, darum existiert das SOW, bevor irgendein Angebot etwas bedeutet. Der veröffentlichte Ankerwert ist die Schätzung von ScienceSoft von 200.000–400.000 $ und rund 10 Monaten für maßgeschneiderte Beschaffungssoftware auf Enterprise-Niveau; ScienceSoft führt die dort genannte ROI-Zahl von 315 % auf eine Forrester-Total-Economic-Impact-Studie zurück.
Das sind deren Zahlen für große Enterprise-Projekte, nicht unsere. Kleinere KMU-Projekte, ein internes Tool, ein Kundenportal, eine mobile App, landen deutlich unter diesem Band; betrachten Sie unsere KMU-Lesart als Interpretation, und holen Sie drei Angebote ein, bevor Sie etwas davon glauben. Für einen Ankerwert je App bepreist unsere Aufschlüsselung der App-Entwicklungskosten Projekte nach App-Typ.
Die Struktur der Zahlung ist so wichtig wie die Summe:
| Modell | Gewinnt, wenn | Risiko liegt bei | Typischer Einsatz |
|---|---|---|---|
| Festpreis | Der Scope eingefroren und das SOW wasserdicht ist | Anbieter (er trägt Überschreitungen) | Klar definierte erste Releases |
| Aufwand und Material | Der Scope sich entwickeln wird und Sie dem Team vertrauen | Ihnen (jede zusätzliche Stunde wird berechnet) | Discovery-lastige oder langlaufende Projekte |
| Meilenstein-gebunden | Beide Modelle, mit Zahlungen an abgenommene Liefergegenstände geknüpft | Geteilt (Geld folgt dem Nachweis) | Die meisten KMU-Individualprojekte |
| IP kaufen vs. lizenzieren vs. abonnieren | Code gehört Ihnen nur, wenn der Vertrag das IP überträgt; Lizenzierung und SaaS-Abos mieten ihn | Vendor-Lock-in bei Lizenz und Abo | Kaufen, wenn die Software Kerngeschäft ist; abonnieren, wenn sie Standardbedarf ist |
Unsere Empfehlung: Standardmäßig Meilenstein-gebundene Zahlungen bei festem Scope, 20 % oder weniger bei Kickoff, die letzte Tranche an den Abnahmetest geknüpft. Festpreis nur, wenn Ihr SOW einer feindlichen Lektüre standhält; Aufwand und Material nur mit einem Anbieter, mit dem Sie schon einmal geliefert haben. Nie 100 % im Voraus; diese Struktur taucht unten wieder auf.
Warnsignale: Woran Individualsoftware-Beschaffungen wirklich scheitern
100 % im Voraus zu zahlen verschafft Ihnen keine Priorität. Es verlagert das gesamte Lieferrisiko auf Sie. Jedes Warnsignal unten gibt dem Anbieter Verhandlungsmacht, die Sie nicht zurückbekommen:
- Vages SOW. "Bauen Sie uns ein CRM", keine Feature-Liste. Jeder undefinierte Begriff wird zum Change Order, bepreist ohne Wettbewerb.
- Kein Abnahmetest. "Wir erkennen es, wenn wir es sehen." Dann sehen Sie es nie, weil "fertig" nie definiert war.
- 100 % Vorauszahlung. Geld ist Ihre einzige Verhandlungsmasse nach der Unterschrift; geben Sie sie am ersten Tag aus, bleibt Ihnen keine.
- Keine Änderungssteuerung. Der Scope wächst, die Rechnungen wachsen, niemand hat das Wachstum unterschrieben.
- Fehlende IP-Übertragung. Sie haben für die Software bezahlt und sie zurücklizenziert, ohne es zu merken.
- Keine Schlüsselpersonal-Klausel. Das Senior-Team, das den Pitch gewonnen hat, verschwindet in der Woche nach Vertragsabschluss.
Wir beantworten jedes Quartal Individualsoftware-RFPs von der Anbieterseite, und zwei Muster kehren so zuverlässig wieder, dass wir sie als Grundrate des Beschaffungsscheiterns behandeln: RFPs ganz ohne Abnahmekriterien und Zahlungspläne, die den Großteil im Voraus vorsehen und dem Anbieter jeden Anreiz geben, das Projekt nach Zahlungseingang herunterzustufen. Unsere Lesart, und es ist Interpretation, keine Messung: Die Einkäufer, die am härtesten um den Preis verhandeln, sind genau die, welche die zwei Klauseln übersprungen haben, Abnahme und Meilensteine, die ihn geschützt hätten.
Die Branchendaten zeigen in dieselbe Richtung. Die Standish Group verfolgt seit drei Jahrzehnten Projektergebnisse in ihrer CHAOS-Forschung; ihr wiederkehrender Befund ist, dass gefährdete Projekte, also Budgetüberschreitung, Verspätung oder Feature-Kürzung, saubere Erfolge zahlenmäßig übertreffen, mit vagen Anforderungen und schwacher Projektpatenschaft weit oben auf den Ursachenlisten.
Wenn Sie nur eine Sache beheben, beheben Sie die Abnahmekriterien. Sie sind die Klausel, die jede andere Klausel erst durchsetzbar macht.
Wie Techsy die Individualsoftware-Beschaffung angeht
Unsere Auftragsannahme folgt denselben sieben Schritten von der anderen Seite des Tisches. Wir erstellen SOW und Abnahmekriterien, bevor wir eine Zahl nennen, denn Angebote auf ein vages Briefing sind der Weg, auf dem Anbieter Dumpingpreise nennen und Einkäufer zu viel zahlen. Projekte laufen mit Meilenstein-gebundenen Zahlungen, wöchentlichen Demos und Code-Prüfrechten in jedem Vertrag. Wenn die Abnahme bestanden ist, gehört Ihnen das IP und das Repository, keine Lizenz.
Ehrliche Grenzen: Wenn Sie ein lizenziertes SaaS-Tool brauchen, das den Einkauf automatisiert, sind wir die falsche Adresse. Das ist ein Produktkauf, kein Projekt; ein Tool-Anbieter bedient Sie schneller und günstiger. Wir übernehmen Individualprojekte, bei denen die Software der Prozess ist und das IP zählt.
Wenn Ihr Projekt in die zweite Kategorie fällt, holen Sie sich ein kostenloses Erstgespräch.
Häufig gestellte Fragen
Was ist Softwarebeschaffung?
Softwarebeschaffung ist der Prozess, Software zu beschaffen: Bedarf definieren, Optionen bewerten, Konditionen verhandeln, Lieferung abnehmen. Sie umfasst lizenzierte Produkte und Individualprojekte gleichermaßen. Dieser Leitfaden konzentriert sich auf das Zweite: den Prozess von Business Case über RFP und Vertrag bis zum Abnahmetest.
Was sind die 4 Arten der Beschaffung?
Die vier gängig genannten Arten sind direkte Beschaffung (Produktionsinput), indirekte Beschaffung (Betriebsmittel und Dienstleistungen), Warenbeschaffung und Dienstleistungsbeschaffung. Software überspannt indirekt und Dienstleistung: ein lizenziertes Tool ist ein indirekter Kauf; ein Individualprojekt ist ein Dienstleistungsauftrag, der in gelieferten Gütern endet.
Was ist der Unterschied zwischen Beschaffungssoftware und Individualsoftware-Beschaffung?
Beschaffungssoftware ist ein Tool, das Einkaufsprozesse automatisiert, wie Tradogram oder Tipalti. Individualsoftware-Beschaffung ist der Prozess, maßgeschneiderte Software bei einem Entwicklungsdienstleister in Auftrag zu geben. Sie suchen die beste Einkaufsplattform? Dann brauchen Sie das Erste; dieser Leitfaden ist das Zweite.
Wie lange dauert die Beschaffung von Individualsoftware?
Planen Sie 10–16 Wochen vom Business Case bis zum unterschriebenen Vertrag bei einem typischen KMU-Projekt, bevor die Entwicklung beginnt; betrachten Sie das als Interpretation, nicht als Benchmark. Eine freihändige Verlängerung schrumpft auf Wochen; eine regulierte Ausschreibung kann sich über sechs Monate ziehen.
Was kostet Individualsoftware?
ScienceSoft schätzt 200.000–400.000 $ und etwa 10 Monate für maßgeschneiderte Beschaffungssoftware auf Enterprise-Niveau und führt eine ROI-Zahl von 315 % auf eine Forrester-Studie zurück. Kleinere KMU-Projekte landen deutlich unter diesem Band. Bei der Individualsoftware-Beschaffung bestimmt der Umfang den Preis: RFP und SOW existieren, bevor irgendein Angebot etwas bedeutet.
Wem gehört das IP bei Individualsoftware?
Wem der Vertrag es zuspricht. Ohne ausdrückliche Work-for-Hire- oder IP-Übertragungsklausel behält der Anbieter das Urheberrecht und lizenziert die Software an Sie zurück. Halten Sie das Eigentum schriftlich fest, an die Zahlung geknüpft: Mit der Schlusszahlung gehört dem Käufer alles. Binden Sie diese Übertragung an die abnahmegebundene Schlusstranche, nicht an die Kickoff-Zahlung, damit das Eigentum sich erst bewegt, wenn die Software es tut.
RFP oder RFQ, was brauche ich?
Eine RFP (Request for Proposal) fragt, wie Anbieter Ihr Problem lösen würden; eine RFQ (Request for Quotation) fragt, was ein definierter Umfang kostet. Schicken Sie bei Individualsoftware zuerst die RFP: Anbieter müssen einen Ansatz vorschlagen, bevor ein Preis etwas bedeutet. Die RFQ kommt, sobald das SOW eingefroren ist.
Festpreis oder Aufwand und Material?
Festpreis schützt Sie, wenn das SOW wasserdicht ist: Der Anbieter trägt Überschreitungen. Aufwand und Material passt zu Discovery-lastiger Arbeit, bei der sich der Umfang entwickelt, aber Sie tragen das Überschreitungsrisiko. Die meisten KMU-Einkäufer fahren am besten mit Meilenstein-gebundenen Zahlungen bei festem Scope, die Schlusstranche an den Abnahmetest geknüpft.
Was gehört in eine Leistungsbeschreibung?
Eine Leistungsbeschreibung sollte Features innerhalb und außerhalb des Scope benennen, Integrationen, Zeitplan, die Abnahmekriterien, an denen die Lieferung gemessen wird, und Zahlungsmeilensteine, die an jeden Liefergegenstand geknüpft sind. Steht ein Punkt nicht im SOW, ist er nicht im Projekt.
Über den Autor
Mert Batur ist Co-Founder von Techsy.io, wo das Team KI-Agenten, Automatisierungssysteme und Voice-/SDR-Pipelines für B2B-Kunden liefert. Er schreibt über den LLM-Tooling-Stack, den das Techsy-Team tatsächlich in der Produktion einsetzt. Er leitet auch die Individualsoftware-Projekte, aus denen dieser Leitfaden schöpft, von der RFP-Antwort bis zur abgenommenen Übergabe. Auf LinkedIn vernetzen.
Fazit
Individualsoftware-Beschaffung läuft auf Artefakte hinaus, nicht auf Verhandlungen: der einseitige Business Case, das SOW mit Abnahmekriterien, das RFP-Gerüst, die Scorecard, der Neun-Klauseln-Vertrag. Stimmen diese fünf Dokumente, erledigt sich das Anbietergespräch von selbst. Gehen Sie die sieben Schritte der Reihe nach durch, halten Sie die Schlusszahlung hinter dem Abnahmetest zurück, und wenn Sie eine zweite Meinung zu Ihrer RFP möchten, holen Sie sich ein kostenloses Erstgespräch.