Ein Supported Software Catalog (SSC) schafft einen soliden Überblick über den eigenen „Software-Zoo“. Viele Unternehmen nutzen eine unübersichtliche Zahl an Software-Anwendungen. Zeit geht verloren, wenn dieselben Fragen zu Produkten mehrfach geprüft werden. Noch mehr Zeit und Geld kosten ähnliche Anwendungen, die parallel beschafft und betrieben werden. Gleichzeitig steigen die Risiken bei Datenschutz, IT-Security und dem Einhalten von Lizenzbedingungen.
Wer prüfte die Anwendung wurde? Warum lehnte das Unternehmen die Anfrage ab oder gab sie frei? Welche Entscheidung gilt noch und welche ist überholt? Diese Fragen sind schwer zu beantworten, wenn Informationen in Tickets, E-Mails, Vertragsordnern und Einzeldateien verteilt sind. Ein Supported Software Catalog schafft hier Transparenz. Er unterstützt schnellere Entscheidungen, vermeidet Doppel-Prüfungen und verbessert die Nachweisführung bei neuen Softwareanfragen.
In der Praxis erlebe ich, dass fast niemand mehr sagen kann, was nach einer Software-Prüfung eigentlich passiert ist. Wurde die Software freigegeben? Beschafft? Tatsächlich genutzt? Dokumentiert? Wird sie lizenzseitig überwacht? Viele offene Fragen, die eigentlich beantwortet sein sollten.
Dabei wird ein solcher Katalog schnell mit einer Freigabeliste verwechselt. Der Unterschied ist aber entscheidend: Eine Freigabeliste sagt, ob etwas erlaubt ist. Ein Supported Software Catalog sagt, warum und unter welchen Bedingungen. Er macht sichtbar, welche Kriterien geprüft wurden, welche Quellen herangezogen wurden und wo noch offene Punkte bestehen. Das klingt nach Mehraufwand, ist in der Praxis aber das Gegenteil.
Eine klassische Freigabeliste kann in überschaubaren Umgebungen eine Zeit lang funktionieren. Aber schon bei mittlerer Komplexität stößt sie an ihre Grenzen. Sie beantwortet nur die eine Frage: Ist die Software erlaubt? In der Praxis reicht das Beantworten dieser Frage aber nicht aus.
Was wirklich zählt:
Der erste Punkt wird in der Praxis häufig übergangen. Ich habe erlebt, wie eine Softwareanfrage den gesamten Prüfprozess durchlief, obwohl das Produkt bereits einmal bewertet worden war. Niemand hatte die frühere Bewertung gefunden, niemand danach gesucht. Der Aufwand entstand ein zweites Mal, mit demselben Ergebnis.
Das sind keine akademischen Fragen. Das sind Fragen, die spätestens beim nächsten Audit, der nächsten Migration oder dem nächsten Sicherheitsvorfall gestellt werden und auf die dann niemand mehr eine begründete und belegbare Antwort hat.
Ein hilfreiches Modell für einen Supported Software Catalog ist die dreistufige Einteilung: Gesamtkatalog, genehmigtes Portfolio, genehmigter Warenkorb.
Der Gesamtkatalog ist das Sammelbecken. Alle Anwendungen sind dort gelistet: Produkte in Prüfung, laufende Evaluierungen, abgelehnte Software. Gerade die abgelehnten Produkte sind wichtiger als viele denken. Wenn dieselbe Software zwei Jahre später erneut angefragt wird, spart eine dokumentierte Ablehnung erheblich Zeit und verhindert doppelte Arbeit.
Das genehmigte Portfolio ist enger. Hier stehen die Produkte, die nach Prüfung grundsätzlich für den Einsatz im Unternehmen geeignet sind; oft verbunden mit Bedingungen, Einschränkungen oder Hinweisen. Nicht jede Freigabe gilt uneingeschränkt.
Der genehmigte Warenkorb ist das, was tatsächlich bestellbar ist. Ein Produkt kann im Portfolio genehmigt sein und ist trotzdem gerade nicht verfügbar, zum Beispiel wegen einer laufenden Migration, einer strategischen Ablösung oder aufgrund eines auslaufenden Vertrages. Diese Unterscheidung klingt zunächst kleinteilig. Sie verhindert aber, dass Bestellungen ins Leere laufen oder veraltete Standards weiter gelten, obwohl intern längst etwas anderes entschieden wurde.
Früher ließ sich eine Software-Entscheidung oft mit einer technischen Prüfung und einem Gespräch über den Preis abschließen. Das reicht heute nicht mehr. Ein modernes Softwareprodukt ist gleichzeitig Cloud-Dienst, mobile App, Browser-Service, KI-Werkzeug und Integrationsplattform. Wer das nur unter einem Aspekt bewertet, sieht zwangsläufig zu wenig.
Ein SSC bringt die verschiedenen Prüfperspektiven zusammen:
| Prüfbereich | Typische Fragen | Nutzen |
|---|---|---|
| Datenschutz | Welche Daten werden verarbeitet? Wo? Export möglich? Technische Löschung? | Datenschutzrisiken früh erkennen, nicht erst nach Abschluss des Vertrages |
| IT-Security | User-Erkennung, Passwort-Komplexität, SSO, MFA, Rollen, Zertifikate? | Anforderungen an die Sicherheit klären, bevor die Beschaffung erfolgt |
| Lizenzmanagement | Lizenzart, Metrik, Laufzeit, Beschränkungen in der Nutzung, Audit-Risiken? | Falsche Beschaffung und Unterlizenzierung vermeiden |
| KI | Sind KI-Funktionen vorhanden? Werden Kundendaten für Trainings genutzt? | KI-Risiken konkret bewertbar machen, statt sie pauschal auszublenden |
| IT-Architektur | Desktop, Web, Cloud-ready? Technische Voraussetzungen? | Produkt in bestehende Landschaft einordnen können |
| Alternative Produkte | Gibt es bereits etwas Vergleichbares im Unternehmen? | Redundanzen erkennen, bevor sie entstehen |
| Quellen | Welche Dokumente, Herstellerinfos, Verträge wurden genutzt? | Entscheidung bleibt auch später noch erklärbar |
Der SSC ist damit kein reines Lizenzthema mehr. Er liegt an der Schnittstelle von Software Asset Management, IT-Serviceprozessen, Datenschutz, IT-Security und Software-Compliance. Er verbindet diese Bereiche, anstatt sie weiter zu trennen.
In der Praxis sollte eine neue Anfrage nicht reflexartig zu einer Beschaffung führen. Sinnvoll ist diese Abfolge:
Softwareanfrage → Katalogabgleich → strukturierte Prüfung → Quellenbewertung → fachliche Einschätzung → Entscheidung → Katalogpflege
Der erste wahre Schritt ist der Abgleich mit dem bestehenden Katalog. Wenn das Produkt bereits bewertet wurde, muss nicht bei null begonnen werden. Wichtig ist dann nur: Wann geschah die letzte Prüfung? Hat sich seitdem etwas geändert? Etwa am Produkt, an den Anforderungen, am Lizenzmodell?
Wenn keine Bewertung vorliegt, beginnt die strukturierte Prüfung. Eine reine Websuche reicht dafür nicht. Es braucht tragfähige Quellen: Hersteller-Informationen, Lizenzbedingungen, Datenschutz-Unterlagen, technische Dokumentation, Support-Informationen. Und wenn Informationen fehlen oder widersprüchlich sind, gehört das explizit in die Bewertung. Eine dokumentierte Lücke ist besser als eine scheinbar vollständige Bewertung ohne Grundlage. Am Ende steht eine fachliche Einschätzung. Sie trifft die Entscheidung nicht. Sie macht sie erst möglich.
Viele Probleme, die ohne SSC entstehen, sind nicht sofort sichtbar. Sie werden erst dann teuer, wenn ein Audit kommt, eine Migration ansteht oder eine Konsolidierung überfällig ist.
| Risiko | Praktische Folge |
|---|---|
| Mehrere Tools für denselben Zweck | Höhere Kosten für Lizenzen, Support, Administration |
| Fehlende Prüfdokumentation | Entscheidungen sind nicht mehr nachvollziehbar |
| Dezentrale Beschaffung ohne Meldung | Kein belastbarer Überblick mehr möglich |
| Keine Bewertung aus Datenschutzsicht | Risiken bei Speicherung, Export, Löschung werden zu spät erkannt |
| Unklare Lizenzbedingungen | Compliance-Risiken, Fehlnutzung, Nachkauf |
| Keine Prüfung von KI-Funktionen | Unkontrolliertes Verwenden von Kundendaten |
| Fehlende Quellenangaben | Rückfragen, Nacharbeit, mangelnde Belastbarkeit |
| Keine laufende Pflege | Der Katalog veraltet und verliert seine Glaubwürdigkeit |
| Keine Prüfung von Alternativen | Redundanzen wachsen still weiter |
| Keine klare Statuslogik | Genehmigtes, Abgelehntes, Historisches vermischt sich |
Der kritischste Punkt ist die Transparenz. Wer hat was geprüft? Auf welcher Basis? Mit welchem Ergebnis? Welche Punkte blieben offen? Diese Fragen kommen meistens dann, wenn man am wenigsten Zeit hat.
In vielen Prozessen gilt Dokumentation als lästige Nacharbeit. Im SSC ist das grundlegend anders. Die Dokumentation ist kein Beiwerk. Sie ist ein Kern des Supportes Software Catalog.
Ein Prüfdokument ist nur so gut wie seine Inhalte. Wenn Quellen fehlen, Bemerkungsfelder leer bleiben oder unklare Punkte einfach übergangen werden, sieht das Ergebnis auf den ersten Blick ordentlich aus, hilft bei Rückfragen aber kaum weiter. Eine gute Dokumentation bedeutet nicht, jedes Feld, um jeden Preis zu befüllen. Es bedeutet, relevante Punkte so festzuhalten, dass sie viele Monate später noch verständlich sind. Besonders wichtig: Bemerkungen bei unklaren Sachverhalten. Wenn ein Hersteller keine eindeutige Aussage zum Ort der Datenspeicherung macht, gehört das in die Bewertung. Wenn KI-Funktionen vorhanden sind, aber keine belastbare Aussage zum Training mit Kundendaten zu finden war, ist das ein relevanter Befund und kein Versagen der Prüfung.
Rückfragen entstehen selten bei sauber hergeleiteten Entscheidungen. Sie entstehen dort, wo das Ergebnis steht, aber die Begründung fehlt.
Ein häufiger Fehler: Softwareprüfungen laufen in getrennten „Silos“. Der Datenschutz prüft den Datenschutz. Die IT-Security prüft technische Risiken. Das Lizenzmanagement prüft Nutzungsrechte. Der Fachbereich prüft den Nutzen. Jeder sieht einen Ausschnitt und niemand das Ganze.
Ein SSC kann das ändern. Nicht weil eine Person alle Perspektiven allein übernimmt, sondern weil alle relevanten Informationen an einem strukturierten Ort zusammenlaufen. Im Folgenden die vier Perspektiven eine Softwarebewertung:
Diese vier Perspektiven beeinflussen sich gegenseitig: Ein Produkt kann lizenzseitig unkritisch sein und datenschutzrechtlich trotzdem problematisch. Ein Tool kann technisch sauber wirken und unklare KI-Funktionen enthalten. Eine Anwendung kann fachlich nützlich sein und trotzdem ein vorhandenes Standardprodukt doppeln. Nur wer alle vier Perspektiven gleichzeitig betrachtet, kann das erkennen.
Viele Unternehmen kaufen mehrere Anwendungen für denselben Zweck ein. Das passiert selten durch eine bewusste Entscheidung. Ein Team führt ein Tool ein. Ein anderer Fachbereich beschafft eine ähnliche Lösung. Später kommt eine Cloud-Anwendung dazu. Dann ein Spezialtool. Irgendwann gibt es drei Lösungen für denselben Zweck, dabei hat das niemand so gewollt. Das ist kein Einzelfall, sondern eine Situation, die ich mehr als einmal erlebt habe.
Das verursacht mehr als Lizenzkosten. Es erhöht den Aufwand für Support, Schulung, Paketierung, Bereitstellung, die Verwaltung von Berechtigungen und Verträgen, Datenschutzprüfung und die Bewertung der Sicherheit. Jede Anwendung mehr ist eine Anwendung, die gepflegt, überwacht und irgendwann wieder abgelöst werden muss.
Deshalb sollte jede neue Anfrage zu Software eine Frage enthalten: Gibt es im genehmigten Portfolio bereits etwas Vergleichbares? Die Antwort muss nicht automatisch zur Ablehnung führen. Es kann gute Gründe für ein weiteres Produkt geben. Aber diese Gründe sollten dokumentiert sein, sonst wächst die Software-Landschaft einfach weiter, ohne dass jemand bewusst entschieden hat.
Ein Supported Software Catalog ist kein Projekt, das irgendwann fertig ist. Die erste Erfassung schafft die Grundlage. Der eigentliche Wert entsteht danach.
Softwareprodukte ändern sich: Lizenzmodelle werden angepasst. Cloud-Funktionen kommen hinzu, Hersteller ändern die Nutzungsbedingungen, KI-Funktionen werden nachträglich integriert, Produkte werden umbenannt, abgekündigt, in größere Plattformen überführt. Auch interne Vorgaben ändern sich, etwa durch neue Security-Vorgaben, geänderte Datenschutzvorgaben, eine neue IT-Strategie. Ein Katalog, der nicht gepflegt wird, wird zur Altlast. Historische Produkte wirken weiter wie aktive Standards. Nicht mehr bestellbare Software steht als verfügbar. Neue Bewertungen fehlen. Dann ist der SSC wieder nur eine weitere Liste, die niemand mehr ernstnimmt.Ein Supported Software Catalog kann außerdem Unternehmen dabei helfen, ihre Anforderungen aus IT-Sicherheitsstandards wie ISO/IEC 27001 oder Vorgaben im KRITIS-Umfeld zu erfüllen. Er ersetzt kein Managementsystem für Informationssicherheit und keine formale Prüfung. Er schafft aber eine solide Grundlage: Softwareprodukte, Prüfkriterien, Quellen, Risiken, Entscheidungen und offene Punkte werden transparent dokumentiert. Das erleichtert interne Kontrollen, Audits und die Zusammenarbeit zwischen IT, Datenschutz, IT-Security und Lizenzmanagement.
Sein Wert liegt nicht darin, dass am Ende „genehmigt“ oder „abgelehnt“ steht. Er liegt darin, dass nachvollziehbar ist, warum welche Kriterien galten, welche Quellen genutzt wurden und welche Punkte offenblieben.
Der Aufbau eines Supported Software Catalog beginnt also nicht mit einer großen Systemeinführung, sondern mit einem sauberen Vorgehen: bestehende Software erfassen, Anfragen strukturiert prüfen, Quellen nachvollziehbar dokumentieren, Entscheidungen begründen und den Katalog laufend pflegen. Genau hier setzt die Dienstleistung an. Ein SSC unterstützt Unternehmen dabei, aus verstreuten Informationen eine Grundlage für Entscheidungen zu machen: für Datenschutz, IT-Security, Lizenzmanagement, KI-Bewertungen und Software-Governance.
Unternehmen, die Software nur freigeben oder ablehnen, gewinnen kurzfristig vielleicht an Geschwindigkeit. Unternehmen, die Entscheidungen sauber dokumentieren, bauen etwas auf, das tatsächlich hält: Transparenz, Steuerbarkeit und eine Software-Governance, der man trauen kann.
Lizenzkosten senken
Unsere Experten kennen alle Hebel zur Senkung von Lizenzkosten. Herstellerspezifisch identifizieren wir Potenziale, die langfristig wirken.
Compliance sichern
Wir reduzieren Lizenzrisiken frühzeitig – so bleiben Sie stets handlungsfähig und vermeiden kostspielige Nachforderungen.
SAM Automatisieren
Wir unterstützen Sie dort, wo Ressourcen fehlen – von der Auswahl des richtigen SAM-Tools bis zur verlässlichen Unterstützung im Tagesgeschäft.
Sie sehen gerade einen Platzhalterinhalt von Vimeo. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie müssen den Inhalt von reCAPTCHA laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr Informationen