21. Juli 2026
IT Product Selector: Produktauswahl mit System statt Bauchgefühl
IT-Produktentscheidungen entstehen oft aus Bauchgefühl, Vendor-Folien und mühsam gepflegten Excel-Matrizen. Der Prozess ist langsam, schlecht dokumentiert und selten reproduzierbar — und am Ende kann niemand mehr nachvollziehen, warum Produkt X gewonnen hat.
Ein wiederholbarer, evidenzbasierter Auswahlprozess: Anforderungen, Marktanalyse und Einzelbewertungen strukturiert durchlaufen und als nachvollziehbaren Report dokumentieren — in Stunden statt Wochen.
7-Phasen-Workflow mit LLM-Unterstützung: pro Lauf 5–6 Produkte gegen ~120 gewichtete Anforderungen geprüft (600–720 Einzelbewertungen mit Begründung), interaktiver HTML-Report mit Ranking und Empfehlung. LLM-Kosten pro vollständigem Audit: ca. 3–4 USD.
Wie entscheidet ein Unternehmen eigentlich, welches Artifact Repository, welche CI/CD-Plattform oder welche Datenplattform es kauft? Nach meiner Erfahrung erstaunlich oft so: Jemand kennt Produkt X vom letzten Arbeitgeber, der Vendor hatte die überzeugendste Folienschlacht, und irgendwo kursiert eine Excel-Matrix, die drei Leute unabhängig voneinander in unterschiedlichen Versionen pflegen. Nach Monaten fällt eine Entscheidung — und ein Jahr später weiß niemand mehr, warum eigentlich.
Genau dieses Muster wollte ich brechen. Herausgekommen ist der IT Product Selector: ein Open-Source-Framework, das eine vollständige Produkt-Evaluierung strukturiert durchläuft — von der Anforderungserhebung bis zum fertigen, interaktiven HTML-Report. Die Fleißarbeit übernimmt ein LLM, die Struktur und die Kontrolle behält der Mensch.
Das Problem: Produktauswahl ist meistens undokumentiertes Bauchgefühl
In größeren Organisationen ist die Auswahl von IT-Produkten ein wiederkehrender, teurer Prozess. Und er hat fast immer dieselben Schwächen:
- Unvollständige Anforderungen. Was in Workshops zusammengetragen wird, deckt selten alle relevanten Kategorien ab — Betrieb, Security, Compliance und Exit-Strategie fallen gern hinten runter.
- Asymmetrisches Wissen. Der Vendor kennt sein Produkt perfekt; das Auswahlteam kennt es aus einer Demo. Die Bewertung kippt Richtung Marketing.
- Keine Nachvollziehbarkeit. Die berühmte Bewertungsmatrix sagt dass ein Produkt 4 von 5 Punkten bekommen hat — aber nicht warum, von wem und auf welcher Grundlage.
- Enormer Aufwand. Eine saubere Evaluierung von fünf Produkten gegen hundert Anforderungen sind fünfhundert Einzelfragen. Das macht händisch niemand konsequent — also wird abgekürzt.
Dabei ist genau diese Fleißarbeit — viele gleichartige, gut abgrenzbare Bewertungsfragen mit Begründung — etwas, das moderne Sprachmodelle bemerkenswert gut können, wenn man sie strukturiert führt statt frei fabulieren zu lässt.
Die Motivation: Evidenz erzwingen, nicht erhoffen
Ich wollte kein „Chatbot, der Produkte empfiehlt”. Eine einzelne Frage an ein LLM — „Welches Artifact Repository sollen wir nehmen?” — liefert eine flüssig formulierte, aber unüberprüfbare Meinung. Interessant wird es erst, wenn man den Prozess umdreht:
- Erst werden die Anforderungen festgezurrt — mit Gewichtung, bevor irgendein Produktname fällt.
- Dann wird jede Anforderung für jedes Produkt einzeln geprüft, auf einer verankerten Skala von 1–5, jede Bewertung mit schriftlicher Begründung.
- Erst ganz am Ende wird aggregiert, gerankt und eine Empfehlung formuliert.
Das ist im Kern das Vorgehen eines sauberen IT-Audits — daher nenne ich den Prozess intern Lean IT-Audit. Das LLM bekommt dabei nie die Chance, mit einer vorschnellen Gesamtmeinung zu starten. Es muss sich die Empfehlung aus hunderten atomarer Einzelbewertungen verdienen.
Wie es funktioniert: sieben Phasen
Der Ablauf im Detail:
- Kundenkontext erfassen — die Ausgangslage als Freitext, Textdatei oder PDF: Was wird gesucht, welche Rahmenbedingungen, welche Bestandslandschaft?
- Anforderungen generieren — ein Standard-Katalog wird um kontextspezifisch generierte Anforderungen ergänzt; alles zweistufig gewichtet (Kategorie-Gewicht × Anforderungs-Gewicht).
- Vendor Discovery — passende Anbieter und Produkte werden identifiziert, inklusive kompakter Unternehmens-Eckdaten.
- Vendor Features — Alleinstellungsmerkmale der Kandidaten fließen als zusätzliche Anforderungen zurück in den Katalog. So wird nicht nur gegen die Wunschliste geprüft, sondern auch gegen das, was der Markt kann.
- Atomic Audit — das Herzstück: jede Anforderung wird für jeden Vendor einzeln bewertet, auf einer verankerten 1–5-Skala, mit schriftlicher Begründung. Bei den Beispielen unten sind das 600–720 Einzelprüfungen pro Lauf.
- Scoring — gewichtete Aggregation zu Kategorie-Scores und Gesamt-Ranking.
- Report — ein selbstständiges HTML-Dokument mit Ranking, Bewertungsmatrix, allen Audit-Details, einer Empfehlungs-Synthese und der vollständigen LLM-Kostenübersicht des Laufs.
Wichtig dabei: Der Mensch bleibt im Loop. Nach den Phasen 2 und 3 wird bestätigt, angepasst oder neu generiert — Anforderungen streichen, Vendor-Liste korrigieren. Erst dann startet das (vergleichsweise teure) Audit. Und weil jede Phase ihren Fortschritt in einer State-Datei sichert, lässt sich ein Lauf jederzeit unterbrechen und später exakt dort fortsetzen.
Wo genau hilft hier die KI — und wie ist sie eingebaut?
Der IT Product Selector ist kein Chat, sondern ein programmatischer Workflow: ein Python-Programm orchestriert die Phasen und ruft das LLM gezielt dort, wo Sprach- und Weltwissen gebraucht wird. Ein paar Design-Entscheidungen, die sich bewährt haben:
Strukturierte Ausgaben statt Prosa. Fast alle Modell-Aufrufe laufen über eine ask_json()-Schnittstelle mit nativem JSON-Mode. Das Modell antwortet nicht mit Fließtext, sondern mit validiertem JSON, das direkt in den State übernommen wird. Kaputte Antworten (das passiert selten, aber es passiert) werden automatisch erkannt und der einzelne Call wiederholt — nicht die ganze Phase.
Batching gegen Context-Bloat. Beim Audit werden Anforderungen kategorieweise in Batches von maximal zwölf gebündelt und zusammen mit einem kompakten Vendor-Kontext geprüft. Das hält die Prompts klein, die Antworten fokussiert und die Kosten kalkulierbar.
Drei Modell-Stufen, nach Wert der Aufgabe. Nicht jede Aufgabe braucht das beste Modell: Vendor-Kurzprofile erledigt ein kleines, schnelles Modell (Haiku-Klasse), die Masse der Audits und Generierungen ein mittleres (Sonnet-Klasse), und nur die finale Empfehlungs-Synthese — ein einziger Call pro Report — bekommt das Top-Modell (Opus-Klasse). Der Provider ist austauschbar; neben der Claude-API wird auch Google Gemini unterstützt.
Kostentransparenz als Feature. Vor dem Audit gibt es eine Vorab-Schätzung auf Basis kalibrierter Token-Richtwerte; nach dem Lauf steht die tatsächliche Kostenaufstellung pro Phase und Modell im Report. Die vier Beispiel-Läufe unten haben jeweils rund 3–4 US-Dollar an LLM-Kosten verursacht — für je 600+ begründete Einzelbewertungen. Zum Vergleich: allein das Vorbereiten eines einzigen Workshop-Termins mit fünf Personen kostet mehr.
Ehrliche Grenzen. Die Bewertungen beruhen auf modellgestützter Einschätzung — jeder Report sagt das auch explizit. Das Ergebnis ist eine fundierte Entscheidungsgrundlage, kein Ersatz für einen Proof of Concept: Sicherheitskritische oder vertragsrelevante Punkte gehören vor der Unterschrift verifiziert. Der Wert liegt darin, dass die Shortlist und die kritischen Fragen nach einem Tag auf dem Tisch liegen statt nach drei Monaten — und dass jede einzelne Zahl im Ranking eine nachlesbare Begründung hat.
Vier echte Beispiel-Reports
Am besten versteht man das Ergebnis, wenn man es anschaut. Hier vier vollständige Reports aus realistischen Szenarien (Kontexte anonymisiert, jeweils ein eigenständiges HTML-Dokument — Ranking, Matrix und alle Audit-Details inklusive):
- Zentrale Datenplattform (SAP-/BI-Umfeld) — 5 Produkte, 120 Anforderungen, 600 Einzelprüfungen. Klassisches Konsolidierungsszenario: gewachsene SAP-, Power-BI- und Qlik-Landschaft, gesucht ist die zentrale Plattform.
- Generic Artefact Manager Services — 5 Produkte, 123 Anforderungen, 615 Einzelprüfungen. Enterprise-weiter Artifact-Repository-Dienst als Managed Service.
- Software Supply Chain Security für Artefakte — 6 Produkte, 120 Anforderungen, 720 Einzelprüfungen. SBOM, Schwachstellen-Scanning und Policy-Enforcement rund um den Artefakt-Fluss.
- Bare-Metal Kubernetes DevSecOps-Plattform (KRITIS) — 6 Produkte, 120 Anforderungen, 720 Einzelprüfungen. Regulierter Betrieb auf eigener Hardware, DevSecOps-Toolchain inklusive.
Die Reports sind bewusst unverändert so, wie der Selector sie erzeugt hat — nur die Farben habe ich an diese Seite angepasst.
Was ich dabei gelernt habe
Die wichtigste Erkenntnis: LLMs werden dramatisch besser, wenn man ihnen die Struktur vorgibt und die Gesamtentscheidung wegnimmt. Dieselbe Frage, die als Chat-Prompt eine oberflächliche Meinung liefert, wird als orchestrierter Prozess aus hunderten atomarer Teilfragen zu einem Werkzeug, dessen Ergebnis man Zeile für Zeile überprüfen kann. Der zweite Punkt: Modell-Tiering lohnt sich sofort — der Unterschied zwischen „alles mit dem Top-Modell” und „das richtige Modell pro Aufgabe” ist bei diesem Workload etwa Faktor fünf bei den Kosten, ohne messbaren Qualitätsverlust in der Masse.
Das Projekt steht unter MIT-Lizenz. Wenn dich Details zur Umsetzung interessieren — schreib mir gern über das Kontaktformular.