Technologieentscheidungen
Individualsoftware oder SaaS?
Eine Build-vs.-Buy-Methode mit denselben Anforderungen, Nachweisen, Zeithorizonten, Betriebsverantwortungen und Exit-Tests für jede Option.
Kurz gefasst
- Entscheiden Sie eine Capability nach der anderen. CRM, proprietäre Angebotslogik, Identity und Reporting können im selben System unterschiedliche Antworten haben.
- Vergleichen Sie gleiche Anforderungen und Abnahmefälle. Der Technology Code of Practice der britischen Regierung gilt für den öffentlichen Sektor. Seine Lebenszyklusfragen sind dennoch nützlich: Nutzerbedarf, Integration, Security, Privacy, Daten, Einkauf und Nachhaltigkeit.
- Halten Sie mehr als zwei Optionen offen. Kauf, Eigenentwicklung, Hybrid, Partner, Verschieben und Stoppen bleiben möglich, bis Ausschlusskriterien und Nachweise sie entfernen.
- Modellieren Sie Szenarien ohne Marktmittelwert. Die britische Choosing-Technology-Guidance nennt Gesamtkosten, Integration, Datenkontrolle, Cyberpflichten, Wiederverwendung und lange Anbieterbindungen.
- Prüfen Sie Ownership und Exit. Beim Anbieter bleiben Konfiguration, Zugriffe, Adoption und Vertragsentscheidungen beim Kunden. Eine Eigenentwicklung erzeugt Pflichten für Delivery, Security, Support und Kontinuität.
Auf der richtigen Ebene beginnen
Definieren Sie die Entscheidungseinheit vor dem Lösungsvergleich.
„Die Plattform ersetzen“ ist meistens zu groß. Teilen Sie das System in Capabilities mit klaren Inputs, Outputs, Nutzern, Service Levels, Daten und Abhängigkeiten. Ein Standard-CRM kann Kontakte und Pipeline führen, während eine proprietäre Angebotslogik individuell bleibt. Das sind zwei Entscheidungen mit einer Integrationsgrenze.
Kern versus Commodity ist eine nützliche Frage, entscheidet das Ergebnis aber nicht allein. Eine differenzierende Capability kann gekauft werden, wenn ein Produkt die Abnahmefälle erfüllt und strategische Kontrolle erhält. Eine übliche Capability kann einen fokussierten Build brauchen, wenn verfügbare Produkte an einer harten Bedingung scheitern.
Der britische Service Standard verlangt Verständnis der Gesamtkosten und die Möglichkeit, später anders zu entscheiden. Machen Sie das prüfbar: Definieren Sie vor der Auswahl, was ersetzbar, exportierbar oder unabhängig betreibbar bleiben muss.
Dieselbe Capability, dieselbe Evidenz, derselbe Entscheidungshorizont.
Vergleichbarer Decision Record
Dieselben Fragen an SaaS, Individualsoftware und Hybrid stellen.
| Entscheidungsdimension | SaaS / Buy | Individualsoftware | Hybrid / Partner |
|---|---|---|---|
| Benötigtes Ergebnis | Welche Abnahmefälle funktionieren im aktuellen Produkt? | Welche Abnahmefälle müssen entworfen und gebaut werden? | Welche Fälle liegen im Produkt und welche bleiben individuell? |
| Harte Bedingungen | Welche Anforderung, Vertragsklausel, Region, Schnittstelle oder SLA schließt die Option aus? | Welche Capability-, Termin-, Budget- oder Ownership-Lücke schließt die Option aus? | Welche Grenze oder Abhängigkeit macht die Kombination unsicher oder unbrauchbar? |
| Evidenzstatus | Funktionierender Test, Vertrag, Export, API-, Support- und Security-Nachweise | Prototyp, Schätzgrundlage, Architektur, Staffing- und Delivery-Nachweise | End-to-End-Test, Schnittstellenvertrag, Fehlerpfad und gemeinsame Betriebsnachweise |
| Betriebsverantwortung | Kunde verantwortet Konfiguration, Zugriff, Adoption, Vendor Management und angebundene Systeme | Organisation verantwortet Produktentscheidungen, Delivery, Security, Support, Kontinuität und Veränderung | Ownership wird für Produkt, Custom Layer, Integration und Incident-Pfad explizit geteilt |
| Szenariokosten | Lizenz, Konfiguration, Integration, Migration, interne Arbeit, Support, Verlängerung und Exit | Discovery, Build, Infrastruktur, Security, Betrieb, Support, Veränderung, Kontinuität und Opportunitätskosten | Produktkosten plus Integration, Custom-Betrieb, Koordination und Fehler an der Grenze |
| Security-Evidenz | Lieferantenpraxis, Produktnachweise, Konfiguration, Identity, Datenfluss und Vertrag | Secure Development, Dependencies, Deployment-Kontrollen, Monitoring und Response | Nachweise für beide Seiten plus Schnittstelle, Credentials, Logging und Verantwortungsgrenze |
| Portabilität und Exit | Exporttest, Format, API, Vertrag, Wechselhilfe, Löschung und Ersatzpfad | Code, Daten, Konten, Lizenzen, Dokumentation, Menschen, Dependencies und Rebuild-Pfad | Jede Komponente separat verlassen und den Weiterbetrieb des Rests prüfen |
| Review-Auslöser | Verlängerung, Preis- oder Produktänderung, Akquisition, Serviceausfall oder neue Anforderung | Wesentliche Scope-, Nachfrage-, Security-, Team-, Kosten- oder Architekturänderung | Änderung an Schnittstelle, Vendor, Ownership, Volumen oder Betriebsmodell |
Drei Kontrollen
- Gleicher Scope
- Jede Option beantwortet dasselbe Ergebnis, dieselben Abnahmefälle und Ausschlusskriterien.
- Evidenz
- Verifizierte Inputs, Vendor-Aussagen, Schätzungen, Schlussfolgerungen und fehlende Informationen bleiben getrennt sichtbar.
- Exit
- Die Entscheidung umfasst Ersatz, Migration, Stopp oder Weiterbetrieb jeder Komponente.
Nächster Schritt
Zweite Meinung zu: Individualsoftware vs. SaaS
Schicken Sie uns, woran Sie gerade arbeiten. Wir antworten mit einem nächsten Schritt, nicht mit einem Verkaufsgespräch.
Vergleich aufbauen
Vier Schritte, die eine schwache Empfehlung sichtbar machen.
Abnahmefälle und Ausschlusskriterien vor Vendor-Gesprächen schreiben
Nutzen Sie repräsentative Workflows, Rollen, Daten, Volumenbedingungen, Ausnahmen, Service Levels und notwendige Integrationen. Ein gewichteter Feature-Score darf keine gescheiterte rechtliche, Security-, Portabilitäts-, Termin- oder Betriebsbedingung ausgleichen.
Die Evidenz hinter jedem Input kennzeichnen
Funktionierender Test, unterschriebener Vertrag, gemessener Workload, Vendor-Aussage, Schätzung, Schlussfolgerung und fehlende Antwort haben unterschiedliche Konfidenz. Halten Sie diese Labels im Decision Record, damit eine gute Demo fehlende Betriebsnachweise nicht überdeckt.
Szenarien und Sensitivität über den vereinbarten Horizont modellieren
Wählen Sie einen Horizont, der Vertrag, Investment oder Produktentscheidung abdeckt. Variieren Sie Adoption, Volumen, interne Zeit, Preis, Delivery, Support und Exit. Die Empfehlung ist fragil, wenn eine optimistische Annahme sie umkehrt.
Betriebs- und Exit-Grenzen testen
Bei CRM plus proprietärer Angebotslogik prüfen Sie, welches System jeden Datensatz führt, wie Fehler wiederholt werden, wer die Integration unterstützt, wie Angebotshistorie exportiert wird und was bei Austausch einer Komponente weiterläuft. Hybrid hat zwei Betriebsoberflächen und braucht eine bewusste Architektur.
Häufige Fragen
Was Entscheider zu Individualsoftware und SaaS fragen.
Ist SaaS günstiger als Individualsoftware?
Ohne Capability, Anforderungsbasis, Vertrag, Adoptionsmodell, Betriebsplan und Horizont gibt es keine übertragbare Antwort. Vergleichen Sie Szenarien mit denselben Kostenkategorien und Evidenzstatus. Ein niedriger Lizenzpreis kann mit teurer Integration oder Veränderung zusammenfallen. Eine Build-Schätzung kann Betrieb, Security, Kontinuität und verschobene Produktarbeit auslassen.
Entfernt Individualsoftware Vendor-Lock-in?
Nein. Ein eigenes System kann von Entwicklungsdienstleister, Schlüsselpersonen, Cloud-Diensten, Frameworks, proprietären Komponenten, Lizenzen, Modellen oder undokumentiertem Betriebswissen abhängen. Prüfen Sie Ownership und Zugriff auf Code, Daten, Konten, Build- und Deployment-Pfade, Dokumentation und Dependency-Records. Testen Sie danach, ob ein anderes qualifiziertes Team das System betreiben oder ersetzen könnte.
Wie sollte Security die Entscheidung beeinflussen?
Kauf verändert Evidenz und Verantwortungsaufteilung; Security-Arbeit bleibt bestehen. NIST SP 800-218 beschreibt Secure-Development-Praktiken, die auch Käufer in Gesprächen mit Lieferanten verwenden können. Die CISA Customer Guidance behandelt Vertrags- und Supply-Chain-Evidenz. Beim Build muss die Organisation diese Praxis tragen können. Bei SaaS zählen Vendor-Nachweise plus Kundenkonfiguration, Identity, Datenfluss, Monitoring und Incident-Verantwortung.
Beseitigt der EU Data Act SaaS-Lock-in?
Nein. Die Erklärung der Europäischen Kommission beschreibt Wechsel- und Portabilitätspflichten für erfasste Datenverarbeitungsdienste, darunter Cloud- und Edge-Dienste. Scope, Übergangsregeln, Verträge, technische Machbarkeit, ausgeschlossene Daten und die übrige Anwendungsarchitektur bleiben relevant. Testen Sie Export und Wechsel praktisch und klären Sie die Anwendbarkeit mit qualifizierter Rechtsberatung.
Sollten wir SaaS vor einem Custom Build evaluieren?
Führen Sie genug Markt- und Produktprüfung durch, um zu erkennen, ob eine belastbare Buy- oder Partneroption existiert. Die Tiefe folgt der Entscheidung. Wenn kein Kandidat eine harte Anforderung erfüllt, dokumentieren Sie das und beenden die Evaluation. Wenn ein Kandidat tragfähig erscheint, testen Sie dieselben repräsentativen Abnahmefälle wie beim Build.
Wie Some Tech Work entscheidet
Die Empfehlung bleibt von Umsetzungsumsatz getrennt.
Unser Build-vs.-Buy-Entscheidungsmemo hält Decision Owner, Einschränkungen, Optionen, Evidenz, Szenariokosten, Betriebsverantwortung, Empfehlung, Bedingungen, abweichende Sichtweisen und Review-Auslöser fest. Kauf, Hybrid, Verschieben und Stoppen bleiben belastbare Ergebnisse.
Eine tiefere Anbieterprüfung wird zur Vendor Due Diligence. Ein späterer Build oder eine Integration wird separat beauftragt und freigegeben. Die Analyse hängt dadurch nicht von einem Umsetzungsauftrag an Some Tech Work ab.
Verfasst von
Vineet Talwar
Co-Founder, Tech & Operations bei Some Tech Work. WordCamp-Speaker in Europa und Asien und Host des WP-Shoutout-Podcasts.
Hier starten
Bereit fürs Gespräch.Buchen Sie eine kurze Diagnose.
Sagen Sie uns, was nicht läuft
Wir lesen jedes Briefing und antworten innerhalb eines Werktags.
Lieber erst sprechen?oder Tech-Stack-Audit anfragen →oder direkt per E-Mail →
Unklar, wo Sie anfangen sollen? Schicken Sie die hängende Entscheidung, den Workflow oder die Seite. Wir sagen, ob ein Diagnosegespräch, ein Tech-Stack-Audit oder ein anderer erster Schritt passt.