Zum Inhalt springen
Wissen

Das SUTSCHE FIT-Framework

Warum nicht jede Anforderung gleich viel wiegt Jede Systemauswahl beginnt mit einer Liste. Anforderungen werden gesammelt – aus Workshops, aus Abteilungen, aus dem, was im letzten Projekt schmerzhaft gefehlt hat. Am Ende stehen zweihundert, dreihundert, manchmal vierhundert Zeilen in einer Tabelle. Und dann passiert das Entscheidende: Sie werden alle gleich behandelt. Jede Zeile ein Punkt. Jeder Punkt gleich viel wert. Das Ergebnis ist eine Zahl, die aussieht wie eine Entscheidung, aber keine ist.

Datum

Lesedauer

13 Min. Lesezeit

Ist ein KI-Assistent wichtiger als ein Rechtekonzept?

In einer unsortierten Anforderungsliste steht beides nebeneinander. Eine Zeile: „KI-gestützte Textvorschläge im Editor.” Eine andere Zeile: „Rollenbasierte Rechte bis auf Ebene einzelner Inhaltselemente.” Zwei Zeilen, zwei Punkte, gleiches Gewicht.

In der Praxis sind das zwei völlig verschiedene Kategorien von Anforderungen. Das eine ist ein Komfortgewinn, den es in zwölf Monaten in jedem System geben wird. Das andere entscheidet darüber, ob dreißig Menschen aus sechs Ländern überhaupt sinnvoll in einem System arbeiten können – und ob die Rechtsabteilung dem Betrieb zustimmt.

Hersteller richten ihr Marketing naturgemäß auf den Teil der Anforderungen aus, den sie gut bedienen. Das ist kein Vorwurf, das ist ihre Aufgabe. In jeder Demo sehen Sie deshalb dieselben zwanzig Prozent: die neue Oberfläche, den Assistenten, die Vorschau. Die anderen achtzig Prozent – Migrationspfade, Mandantenfähigkeit, Lizenzlogik bei wachsender Nutzerzahl, Verhalten bei einem Ausfall – kommen in keiner Präsentation vor, weil sie sich schlecht zeigen lassen.

Wer die Liste nicht strukturiert, übernimmt die Struktur des Herstellers.

Der eine große Topf

Anforderungen entstehen verteilt. Die Fachbereiche bringen Wünsche an die tägliche Arbeit mit, die IT bringt Vorgaben zu Hosting und Schnittstellen, der Einkauf fragt nach Lizenzmodellen, der Datenschutz nach Speicherorten. Alles landet in derselben Tabelle, meist in der Reihenfolge, in der es genannt wurde.

Daraus entstehen drei Probleme, die sich erst spät zeigen:

  • Keine Gewichtung. Ein Muss-Kriterium und ein Nice-to-have zählen gleich viel. Ein System kann die Auswahl gewinnen und trotzdem an einer einzigen Anforderung scheitern, die niemand als kritisch markiert hat.
  • Blinde Flecken. Was im Workshop niemand anspricht, taucht in der Liste nicht auf. Saßen dort vor allem Fachbereiche, fehlen die Betriebsthemen. Saß vor allem die IT dabei, fehlt die tägliche Arbeitsweise.
  • Keine Vergleichbarkeit. Jede Auswahl beginnt bei null. Zwei Projekte im selben Unternehmen kommen zu Ergebnissen, die sich nicht gegeneinander lesen lassen – und das Wissen aus dem einen hilft dem anderen nicht.
Anforderungen, einmal als Liste und einmal nach Perspektive sortiert.
Dieselben Anforderungen, einmal als Liste und einmal nach Perspektive sortiert. Die Sortierung allein verändert noch keine Bewertung. Sie macht aber sichtbar, wo eine Liste dünn ist – und das ist fast immer die rechte Hälfte.

Die Idee

Das Fit-Framework ist kein Bewertungsbogen. Es ist eine Ordnung: Sie legt fest, aus welchen Perspektiven ein System betrachtet wird, bevor der erste Anbieter den Raum betritt.

Der Gedanke dahinter ist einfach. Wenn feststeht, welche Perspektiven eingenommen werden müssen, fällt sofort auf, wenn eine davon leer bleibt. Eine Anforderungsliste ohne Betriebsthemen ist dann nicht mehr eine Liste, die eben so aussieht, sondern eine Liste mit einer sichtbaren Lücke.

Es braucht zur Bewertung einen Maßstab, der nicht vom bewerteten Gegenstand abhängt. Darum ist die oberste Ebene des Frameworks konstant – über Projekte, über Jahre und über Systemtypen hinweg. Was sich ändern darf, liegt darunter.

Die Struktur allein macht allerdings noch keine Auswahl. Was sie trägt, sind die Anforderungen, die darin liegen – und die entstehen nicht am Schreibtisch. Unsere Kataloge für Content-Management, Digital-Asset-Management, E-Commerce oder Formularmanagement sind über Jahre in Kundenprojekten gewachsen: jede Anforderung einmal gestellt, einmal gegen echte Systeme geprüft und, wo sie sich als unscharf erwiesen hat, neu geschnitten. Diesen Vorrat bringen wir in ein Projekt mit. Sie fangen damit nicht bei einer leeren Tabelle an, sondern bei einer vollen – und streichen, was nicht gilt.

Der Aufbau: drei Ebenen

Das Framework arbeitet auf drei Ebenen, die unterschiedlich beweglich sind. Das ist der eigentliche Kniff: Oben bleibt alles konstant, unten darf alles projektspezifisch sein.

Warum die oberste Ebene konstant bleiben muss, zeigt sich erst über die Zeit. Wer heute ein Content-Management-System und in zwei Jahren ein Digital-Asset-Management auswählt, liest beide Ergebnisse entlang derselben fünf Achsen. Ein Unternehmen, das in drei Ländern drei Auswahlen durchführt, kann die Resultate nebeneinanderlegen. Und wer in fünf Jahren wissen will, warum damals gegen ein bestimmtes System entschieden wurde, findet die Begründung an einer Stelle, die er versteht.

Die mittlere Ebene ist der Übersetzer. Eine Capability bündelt Anforderungen, die fachlich zusammengehören. „Mehrsprachigkeit” etwa umfasst Übersetzungsworkflows, Sprachvarianten, Fallback-Logik und die Frage, wie jemand erkennt, dass eine Übersetzung veraltet ist. Als Einzelanforderungen sind das vier Zeilen unter vielen. Als Cluster sind sie eine Eigenschaft, über die man eine Aussage treffen kann – und über die ein Anbieter Rede und Antwort stehen muss.

Die unterste Ebene ist die einzige, auf der konkret geprüft wird. Anforderungen sind so formuliert, dass sie sich beantworten lassen: erfüllt, teilweise erfüllt, nicht erfüllt, über Dritte erfüllt. Was sich nicht prüfen lässt, ist keine Anforderung, sondern ein Wunsch.

Die fünf Dimensionen

Jede Dimension beantwortet eine andere Frage – und richtet sich an andere Menschen im Unternehmen. Das ist Absicht: Wenn alle fünf besetzt sind, war auch der richtige Personenkreis am Tisch.

Dimension Die Frage dahinter Was passiert, wenn sie fehlt?
Functional Fit Deckt die Lösung die fachlichen Kernanforderungen und die wichtigsten Anwendungsfälle ab? Das System kann vieles, nur nicht das, wofür es täglich gebraucht wird.
Ecosystem & Integration Fit Fügt sich das System in die bestehende Landschaft, in Prozesse und Partner ein? Die Lizenz ist bezahlt, aber die Daten kommen nicht dorthin, wo sie gebraucht werden.
Technical & Architectural Fit Passt die Lösung zur Zielarchitektur und zur technischen Strategie? Das System funktioniert, steht aber quer zu allem, was die IT sonst betreibt.
Organizational & Scalability Fit Lässt sich das System betreiben und skalieren, und erfüllt es Sicherheit und Compliance? Der Betrieb bindet dauerhaft mehr Menschen, als bei der Entscheidung eingeplant waren.
Financial & Strategic Fit Stimmen Kosten über die Laufzeit, Vertragsmodell und strategische Richtung? Jahr eins ist günstig, Jahr vier nicht mehr finanzierbar.

Auffällig ist, wie selten die vierte und fünfte Dimension in einer Anforderungsliste auftauchen, die ohne Struktur entstanden ist. Betrieb und Kosten über die Laufzeit sind unangenehme Themen in einem Projekt, das gerade erst begeistert startet. Sie entscheiden trotzdem darüber, wie das Projekt in Jahr drei bewertet wird.

Die Umsetzung

Jede Anforderung bekommt eine Gewichtung. Nicht als Formalie, sondern als Entscheidung, die das Unternehmen trifft: Wie wichtig ist uns das, unabhängig davon, wer es liefert?

Der Zeitpunkt ist dabei wichtiger als die Skala. Wer gewichtet, nachdem er drei Demos gesehen hat, gewichtet unweigerlich entlang dessen, was ihm gefallen hat. Eine überzeugende Präsentation verschiebt die Maßstäbe, ohne dass es jemandem auffällt.

Wir legen die Gewichtung deshalb fest, solange noch kein Anbietername im Raum ist. Sie wird dokumentiert und verändert sich im weiteren Verlauf nur, wenn es einen fachlichen Grund gibt, der ebenfalls dokumentiert wird. Das klingt bürokratisch, erspart aber die Diskussion, die sonst am Ende jeder Auswahl steht: ob das Ergebnis nicht doch zurechtgelegt wurde.

Die Gewichtung hat eine zweite, unterschätzte Wirkung. Sie zwingt zu Gesprächen, die sonst nicht stattfinden. Wenn ein Fachbereich eine Anforderung als unverzichtbar einstuft, die die IT für verzichtbar hält, ist das kein Problem der Bewertung, sondern ein ungeklärter Zielkonflikt. Es ist deutlich billiger, ihn hier zu klären als nach der Vertragsunterschrift.

Von der Anforderung zur Zahl
Die Gewichtung kommt vom Kunden, das Rating aus der Bewertung. Beides bleibt getrennt nachvollziehbar.

Von der Anforderung zur Zahl

Methodisch ist das Fit-Framework eine gewichtete Nutzwertanalyse – ein Verfahren, das seit Jahrzehnten in Beschaffung und Investitionsrechnung verwendet wird. Neu ist nicht die Rechenart, sondern die Struktur, auf der sie arbeitet.

Weil die Werte über die Ebenen aufsummiert werden, lässt sich das Ergebnis in jeder Flughöhe lesen. Auf der obersten Ebene steht eine Rangfolge. Eine Ebene tiefer wird sichtbar, dass System A zwar insgesamt vorn liegt, im Integration Fit aber deutlich hinter System B zurückbleibt. Und noch eine Ebene tiefer steht, von welchen konkreten Anforderungen das hängt.

Dieser Fall ist kein konstruiertes Beispiel. In nahezu jeder Auswahl, die wir begleiten, gibt es mindestens eine Dimension, in der das insgesamt führende System nicht vorn liegt. Wäre das anders, bräuchte es das Verfahren nicht.

Genau hier liegt der eigentliche Nutzen. Die Gesamtzahl entscheidet nichts – sie ordnet nur. Die Entscheidung fällt in dem Gespräch, das auf die Frage folgt: Können wir mit dieser Schwäche in dieser Dimension leben? Manchmal lautet die Antwort ja, weil die betroffenen Anforderungen in zwei Jahren ohnehin anders aussehen. Manchmal lautet sie „nein“, und dann ist das Ergebnis der Auswahl ein zweiter Platz, der gewinnt.

Das Ergebnis ist kein Urteil, sondern eine Tagesordnung.

Warum die Menge nicht entscheidet

Eine reine Summe wäre an dieser Stelle schief. Eine Dimension, in der viele Anforderungen liegen, würde das Gesamtergebnis allein über ihre Menge bestimmen – und nicht darüber, wie wichtig sie dem Unternehmen ist. In der Auswahl greifen deshalb drei Mechanismen ineinander:

  • Ausschlusskriterien laufen nicht über Punkte. Eine Anforderung, deren Verletzung ein System unbrauchbar macht – ein unzulässiger Speicherort personenbezogener Daten etwa – wird nicht schlecht bewertet, sondern schließt aus. Sie steht außerhalb der Rechnung, weil sie sich nicht gegen Komfortgewinne aufwiegen lässt.
  • Jede Dimension wird normiert. Das Ergebnis einer Dimension wird auf eine gemeinsame Skala gebracht, bevor es in das Gesamtbild eingeht. Ob dahinter zwanzig oder hundertfünfzig Anforderungen liegen, ändert an ihrem Einfluss nichts.
  • Die Dimensionen werden untereinander gewichtet. Erst diese Gewichtung entscheidet, wie schwer eine Perspektive im Gesamtbild wiegt. Sie trifft das Unternehmen – nicht die Länge einer Liste.

Die Anzahl der Anforderungen in einer Dimension ist damit eine Aussage über den Markt und über die Gründlichkeit des Katalogs. Über das Gewicht im Ergebnis sagt sie nichts.

Was das Framework nicht leistet

Ein strukturiertes Verfahren verführt dazu, der Zahl am Ende mehr zuzutrauen, als sie verdient. Drei Dinge leistet das Fit-Framework ausdrücklich nicht:

  • Es nimmt die Entscheidung nicht ab. Die Gewichtung ist eine unternehmerische Festlegung, keine Berechnung. Wer sie ändert, ändert das Ergebnis – und das ist richtig so, solange es offen geschieht.
  • Es ersetzt den Test nicht. Wie sich ein System anfühlt, wenn echte Menschen echte Arbeit damit machen, steht in keiner Anforderungszeile. Deshalb gehören strukturierte Präsentationen entlang der eigenen Anwendungsfälle und, bei höherem Risiko, ein Proof of Concept dazu.
  • Es macht Anbieter nicht vergleichbar, wo sie es nicht sind. Ein Hersteller, der eine Funktion über ein Partnerprodukt abbildet, erfüllt die Anforderung anders als einer, der sie im Standard mitbringt. Das muss im Rating sichtbar bleiben, statt in einer gleichen Punktzahl zu verschwinden.
Ein Beispiel: der Katalog für CMS-Auswahlen
Beispiel einer Verteilung im SUTSCHE-Anforderungskatalog für CMS-Auswahlen, Stand Juni 2026.

Ein Beispiel: der Katalog für CMS-Auswahlen

So weit die Mechanik. Wie das konkret aussieht, zeigt der Katalog, mit dem wir Content-Management-Systeme bewerten – der umfangreichste, den wir pflegen.

Fünf Dimensionen, 26 Capabilities, 422 Anforderungen. Die Anforderungen verteilen sich dabei nicht gleichmäßig auf die fünf Dimensionen – und die Verteilung selbst ist schon eine Aussage.

Der größte Block ist nicht der funktionale, sondern der integrative. Das deckt sich mit dem, was wir in Projekten sehen: Systeme scheitern selten daran, dass ein Feature fehlt. Sie scheitern daran, dass Inhalte nicht sauber in den Shop kommen, dass die Benutzerverwaltung nicht an das Verzeichnis des Unternehmens angebunden ist oder dass eine Schnittstelle zwar existiert, aber nur in eine Richtung funktioniert.

Ebenso aufschlussreich ist das untere Ende. Einundzwanzig Anforderungen zu Betrieb, Skalierung und Compliance sind wenige – aber unter ihnen sind die härtesten. Anzahl und Gewicht sind zwei verschiedene Dinge. Eine einzelne Anforderung zum Speicherort personenbezogener Daten kann ein System ausschließen, während dreißig funktionale Wünsche verhandelbar bleiben. Genau deshalb wird normiert, gewichtet und ausgeschlossen, statt gezählt.

Wichtig ist, was der Katalog nicht ist: ein Pflichtprogramm. Für ein mittelständisches Unternehmen mit einer Website und zwei Sprachen sind vielleicht 180 der 422 Anforderungen relevant. Die übrigen werden nicht schlecht bewertet, sondern herausgenommen. Der Katalog ist ein Vorrat, aus dem geschöpft wird – keine Checkliste, die abgearbeitet werden muss.

Für andere Systemtypen bleiben die fünf Dimensionen unverändert, Capabilities und Anforderungen werden ausgetauscht. Ein Digital-Asset-Management hat andere Fähigkeiten als ein CMS, aber dieselben fünf Perspektiven. Dasselbe gilt für E-Commerce-Plattformen, Formularmanagement und die weiteren Systemtypen, für die wir eigene Kataloge pflegen – gewachsen auf demselben Weg und mit derselben Struktur lesbar.

Das Framework im Auswahlverfahren

Im Projekt ist das Framework nicht ein Schritt, sondern der rote Faden. Es taucht an vier Stellen auf:

  • Bei der Anforderungsaufnahme. Die fünf Dimensionen geben die Agenda der Workshops vor. Das sorgt dafür, dass die richtigen Personen eingeladen werden – und niemand zwei Stunden über Oberflächen spricht, während der Betrieb unbesprochen bleibt.
  • Bei der Reduktion der Longlist. Gegen die Muss-Anforderungen lässt sich ein breiter Markt schnell auf eine belastbare Shortlist eindampfen, ohne dass dafür jeder Anbieter einzeln angefragt werden muss.
  • Bei den Herstellerpräsentationen. Die Agenda folgt den Capabilities, nicht dem Foliensatz des Anbieters. Jeder zeigt dasselbe, und das Gesehene lässt sich hinterher nebeneinanderlegen.
  • In der Entscheidungsvorlage. Das Ergebnis wird entlang derselben Struktur dokumentiert, in der es entstanden ist. Wer in drei Jahren fragt, warum so entschieden wurde, bekommt eine Antwort statt einer Erinnerung.

Dass die Bewertungen über Projekte hinweg vergleichbar bleiben, hat einen praktischen Nebeneffekt: Wir können sie sammeln. In unserer Bewertungsdatenbank – Judge Hank – liegen die Einschätzungen zu den Systemen, die wir in Projekten gesehen haben, aufgebaut aus gesicherten Herstellerinformationen und dem, was wir in Präsentationen und Projekten überprüfen konnten.

Daraus entsteht kein fertiges Ergebnis für Ihr Projekt – Ihre Gewichtung kennt die Datenbank nicht. Was daraus entsteht, ist Geschwindigkeit: Eine Longlist lässt sich in Tagen statt in Wochen reduzieren, weil die Grundlagenarbeit nicht bei jedem Projekt von vorn beginnt. Und wir können sagen, wenn ein System auf eine Anforderung eine Antwort gibt, die in anderen Projekten nicht gehalten hat.

Am Ende jeder Auswahl läuft eine Option mit, die in Verfahren ohne Struktur selten jemand schwarz auf weiß bekommt: Das Bestandssystem bleibt eine gültige Antwort. Wenn es gegen die gewichteten Anforderungen besser abschneidet als die Alternativen, ist das ein Ergebnis – und kein Scheitern des Projekts.

Was hängen bleiben sollte

Erstens: Eine strukturierte und kategorisierte Anforderungsliste verschafft Überblick und deckt auch Lücken im Anforderungsprofil auf. Sie hilft bei der internen Steuerung z.B. von Rückfragen und Bewertung der Stakeholder mit den jeweiligen Schwerpunkten.

Zweitens: Struktur entsteht auf drei Ebenen. Fünf Dimensionen bleiben konstant, Capabilities richten sich nach dem Systemtyp, Anforderungen nach dem Projekt.

Drittens: Gewichtet wird vor dem ersten Anbieterkontakt. Danach gewichtet die Demo mit.

Viertens: Anzahl ist nicht Gewicht. Normierung, Dimensionsgewichtung und Ausschlusskriterien sorgen dafür, dass die längste Liste nicht automatisch das Ergebnis bestimmt.

Wie wir dabei unterstützen

Wir erheben Anforderungen entlang der fünf Dimensionen, gewichten sie gemeinsam mit Ihnen und führen die Bewertung bis zur Handlungsempfehlung – von der Longlist über strukturierte Herstellerpräsentationen bis zur Entscheidungsvorlage, die auch in zwei Jahren noch nachvollziehbar ist.

Wir haben dabei kein Interesse an einem bestimmten Ergebnis. Wir haben keine Verträge mit Herstellern und setzen nicht selbst um. Wenn Ihr bestehendes System die beste Antwort auf Ihre gewichteten Anforderungen ist, sagen wir das.

Bastian Sirvend
Kontakt

Lassen Sie es
uns anpacken

„Projektkümmerer“ hat uns vor Jahren ein Kunde genannt. Der Name ist geblieben, weil er stimmt. Sagen Sie uns, wo es gerade hakt – wir kümmern uns.