Machbarkeitsanalyse und Systemauswahl

„Lässt sich das überhaupt machen?" – diese Frage steht am Anfang jedes größeren IT-Projekts. Die Machbarkeitsanalyse (englisch Feasibility Study) prüft, ob ein geplantes System realistisch umgesetzt werden kann – und zwar in vier Dimensionen: technisch, wirtschaftlich, organisatorisch und rechtlich. Ein Projekt, das nur in einer Dimension funktioniert, scheitert garantiert. Diese Lektion zeigt dir, wie eine saubere Machbarkeitsanalyse aufgebaut ist, wie du Risiken früh erkennst und wie du am Ende eine fundierte Entscheidung für oder gegen die Umsetzung triffst – inklusive der wichtigen Frage „selbst bauen oder kaufen?".

1) Die vier Dimensionen der Machbarkeit

Eine vollständige Machbarkeitsanalyse prüft alle vier Dimensionen. Schwächen in einer reichen für den Projekt-Stopp. Klick durch und sieh, was in jeder Dimension geprüft wird:

Die vier Machbarkeits-Dimensionen

Achtung: Die vier Dimensionen sind nicht hierarchisch. Es nutzt nichts, technisch und wirtschaftlich grünes Licht zu haben, wenn der Betriebsrat blockiert oder die Lösung gegen die DSGVO verstößt. Ein „Nein" in einer Dimension = Projekt nicht machbar (zumindest nicht in dieser Form). Manchmal lässt sich umkonzipieren – siehe Variantenarbeit aus Lektion 1.

2) Make-or-Buy – selbst bauen oder kaufen?

Eine der häufigsten Make-or-Buy-Entscheidungen bei IT-Projekten ist: Eigenentwicklung oder fertiges Produkt? Die Antwort hängt nicht nur von Kosten ab, sondern von einer Reihe strategischer Faktoren. Hier eine typische Entscheidungslogik:

Make-or-Buy-Entscheidungsbaum

Faustregel: Standardfunktionen kauft man (kein Wettbewerbsvorteil durch Eigenbau, fertige Lösungen meist günstiger und stabiler). Differenzierende Funktionen baut man: Was dein Geschäft besonders macht, sollte unter eigener Kontrolle stehen – sonst hat es der Wettbewerb morgen auch. Beispiel: Online-Versandhändler kauft Microsoft 365 für E-Mail, entwickelt aber sein Empfehlungssystem selbst. Mehr in Make-or-Buy.

3) Risiken systematisch identifizieren

Eine Machbarkeitsanalyse ohne Risikobetrachtung ist nur halb. Risiken werden klassifiziert nach Eintrittswahrscheinlichkeit und Auswirkung – das Resultat ist eine 3×3-Matrix (manchmal 5×5). Klassische IT-Projekt-Risiken:

Risiko-Matrix – typische Projektrisiken

Auswirkung gering

mittel

hoch

Wahrsch.
hoch

Sinkende Anwender-Akzeptanz

Datenmigrations-Fehler

Schlüsselmitarbeiter fällt aus

mittel

Zeitliche Verschiebung < 2 W.

Externe Dienstleister-Probleme

Budgetüberschreitung > 30 %

gering

Tippfehler in Doku

Kleinere Performance-Probleme

Lieferant geht insolvent

Für jedes roten Risiko muss eine Gegenmaßnahme definiert werden – nicht alles ist vermeidbar, aber alles ist behandelbar. Vier Strategien gibt es: Vermeiden (Risikoquelle ausschalten), Vermindern (Wahrscheinlichkeit oder Auswirkung senken), Übertragen (Versicherung, Vertragsklauseln), Akzeptieren (bewusst tragen, ggf. mit Rücklage). Mehr in Warum Projekte scheitern.

4) Proof of Concept (PoC) – Machbarkeit beweisen

Wenn die technische Machbarkeit unklar ist, hilft kein theoretisches Argumentieren – nur ein Proof of Concept. Das ist eine kleine, fokussierte Demo, die genau die kritische Frage beantwortet: „Funktioniert die zentrale Technik unter realen Bedingungen?". Wichtige Eigenschaften eines guten PoC:

Klare Fragestellung: Was genau soll bewiesen werden? Beispiel: „Kann unser Zielsystem 10.000 gleichzeitige Anfragen pro Sekunde bedienen?"
Zeitlich begrenzt: 1-4 Wochen, nicht länger. PoC ist kein Produkt-Mini.
Echte Daten verwenden: Anonymisierte Produktionsdaten geben realistischere Ergebnisse als Test-Datensätze.
Klares Erfolgskriterium: Vor dem PoC definieren, wann er als erfolgreich gilt. Sonst gibt es nur Schulterzucken am Ende.
Zum Wegwerfen gebaut: PoC-Code wird typisch nicht weiterverwendet. Er beweist nur Konzept, nicht Produktionsqualität.

Vorsicht vor dem klassischen Anti-Pattern: PoC wird vom Management als „fertige Lösung" gesehen und in Produktion geschoben. Resultat: instabiles System, das nicht für Produktionslast gemacht wurde. Daher in PoC-Berichten immer explizit klarmachen: „Erfolgreicher Machbarkeitsnachweis. Produktivumsetzung erfordert vollständige Implementierung."

5) Systemauswahl – mehr als Featurelisten vergleichen

Ist die Machbarkeit positiv, geht es um die konkrete Systemauswahl: welches Produkt oder welcher Anbieter erfüllt die Anforderungen am besten? Hier reicht es nicht, Featurelisten zu vergleichen – wichtige Auswahlkriterien gehen weiter:

Kriterium	Worauf achten
Funktionale Abdeckung	Pflichtanforderungen müssen alle erfüllt sein. „Können wir nachrüsten" zählt nicht als erfüllt.
Marktposition	Wie stabil ist der Anbieter? Wie viele Kunden? Gibt es ein Wartungspaket mit definiertem Support-Level?
Referenzkunden	Wer setzt das System ein, idealerweise in vergleichbarer Branche? Referenzbesuche möglich?
Total Cost of Ownership	Anschaffung + Lizenzen + Wartung + Schulung + Migration über 5 Jahre. Mehr in TCO.
Vertragsbedingungen	Kündigungsfristen, SLAs, Eskalationswege. Was passiert beim Anbieter-Wechsel? Data Portability?
Roadmap des Anbieters	Welche Features kommen in den nächsten Jahren? Strategie der Firma?
Community / Ecosystem	Gibt es ein lebendiges Forum, Partner-Netzwerk, Plugins? Bei Open Source: Wie aktiv ist die Community?
Sicherheits-Track-Record	Wie geht der Anbieter mit Sicherheitslücken um? CVE-Historie, Disclosure-Praxis.

Eine reine Featureliste-Auswahl führt oft in die Sackgasse, weil zwei Systeme „funktional gleich" aussehen können, aber in Wartbarkeit, Support und Strategischer Stabilität meilenweit auseinanderliegen. Mehr in Marktgängige IT-Systeme bewerten.

6) Open Source vs. proprietär

Eine spezielle Achse der Systemauswahl: Open Source oder kommerzielle Closed-Source-Lösung. Beide haben ihre Berechtigung, und beide haben ihre Fallen:

Open Source Vorteile: Keine Lizenzkosten (oft), Code einsehbar (Sicherheits-Audit möglich), kein Anbieter-Lock-in, große Community oft sehr reaktionsschnell bei Bugs.
Open Source Risiken: Support oft nur über Community-Foren (außer bei kommerziellem Support-Vertrag), Lizenzkomplexität (Copyleft-Lizenzen wie GPL können eigene Software „infizieren"), Maintainership-Risiko (Projekt kann eingestellt werden, wenn Hauptentwickler aussteigt).
Proprietär Vorteile: Klarer Support-Ansprechpartner mit SLA, oft polierter und integrierter, Schulungen und Zertifikate verfügbar, Anbieter haftet für Mängel.
Proprietär Risiken: Vendor-Lock-in, hohe Lizenzkosten (oft pro Nutzer/Jahr), Anbieter kann Preise erhöhen oder Features streichen, Daten-Export schwierig.

In der Praxis ist die Wahl oft hybrid: Linux als OS (Open Source), darauf eine kommerzielle Datenbank (Oracle/SQL Server) oder umgekehrt Windows mit PostgreSQL. Mehr in Open-Source-Lizenzen und Lizenzmodelle.

7) Das Ergebnis dokumentieren

Eine Machbarkeitsanalyse mündet in einen schriftlichen Bericht für den Auftraggeber. Wichtige Elemente:

Klare Empfehlung: Geht das Projekt durch (Go), nicht durch (No-Go), oder muss es umkonzipiert werden (Go mit Änderungen)?
Begründung pro Dimension: Technisch, wirtschaftlich, organisatorisch, rechtlich – jeweils mit Bewertung.
Risiken und Gegenmaßnahmen: Was kann schiefgehen, wie wird vorgesorgt.
Voraussetzungen: Welche Bedingungen müssen erfüllt sein (Budget, Mitarbeiter, externe Dienstleister)?
Alternativvorschläge: Falls die Hauptlösung nicht machbar ist – welche Plan-B-Optionen gibt es?
Nächste Schritte: Was muss als nächstes passieren? Verträge, Bestellungen, Schulungen, Pilot?

Wichtige Disziplin: Eine ehrliche Machbarkeitsanalyse darf auch ein „Nein, nicht machbar" empfehlen. Das ist viel besser, als ein zum Scheitern verurteiltes Projekt anzufangen und die Mitarbeiter monatelang frustriert durch eine sinkende IT-Lösung zu jagen. Wer zu früh „Ja" sagt, schadet allen Beteiligten. Mehr in Ist-Analyse und Soll-Konzept.

Zusammenfassung

Eine Machbarkeitsanalyse prüft vor Projektstart, ob ein Vorhaben realistisch umgesetzt werden kann. Vier Dimensionen müssen alle grünes Licht zeigen: technisch (Technologie verfügbar, Performance, Integration), wirtschaftlich (Kosten, ROI, TCO, Budget), organisatorisch (Personal, Know-how, Schulung, Betriebsrat), rechtlich (DSGVO, Lizenzen, Vorschriften). Bei unklarer Technik: Proof of Concept bauen – klare Fragestellung, zeitlich begrenzt, echte Daten, klares Erfolgskriterium. Make-or-Buy: Standardfunktionen kaufen, differenzierende Funktionen selbst bauen. Risiko-Matrix nach Wahrscheinlichkeit × Auswirkung, vier Behandlungsstrategien (Vermeiden, Vermindern, Übertragen, Akzeptieren). Systemauswahl: nicht nur Features, sondern auch Anbieter-Stabilität, Referenzen, TCO, Vertragsbedingungen, Sicherheits-Track-Record. Open Source vs. proprietär: jeweils Vor- und Nachteile abwägen. Ergebnis: Bericht mit klarer Empfehlung (Go / No-Go / Go-mit-Änderungen), Risiken, Voraussetzungen, nächste Schritte.