Ein Software-Beschaffungsprozess führt eine Anfrage über Anbieterauswahl, Prüfungen und Freigaben bis zum Kauf und zur späteren Vertragsverlängerung. Er macht sichtbar, wer entscheidet, welche Nachweise fehlen und was die Software über ihre Laufzeit kostet. Gerade bei SaaS reicht es nicht, einen Preis anzuklicken und eine Firmenkarte zu hinterlegen.
- Erfasse zuerst den konkreten Bedarf und prüfe vorhandene Lizenzen.
- Vergleiche Angebote auf derselben Kostenbasis: Laufzeit, Nutzerzahl, Einrichtung.
- Lass IT, Datenschutz, Recht und Budgetverantwortliche abhängig vom Risiko prüfen.
- Dokumentiere die Entscheidung und plane den nächsten Kündigungs- oder Verlängerungstermin sofort mit ein.
Was gehört zum Software-Beschaffungsprozess?
Zur Softwarebeschaffung gehören die Bedarfsmeldung, die Prüfung vorhandener Lösungen, die Markt- und Anbieterauswahl, der Angebotsvergleich, Sicherheits- und Vertragsprüfungen, die interne Freigabe, der Einkauf, die Einführung und die Betreuung bis zur Kündigung oder Verlängerung. Der eigentliche Kauf ist nur ein Teil davon.
Bei klassischen Gütern stehen Bestellung, Lieferung und Rechnungsabgleich im Mittelpunkt. Bei SaaS kommen wiederkehrende Zahlungen, Nutzerkonten, Zugriffsrechte, gespeicherte Daten, Integrationen und Kündigungsfristen hinzu. Ein Dienst kann heute günstig wirken und bei zusätzlichen Lizenzen oder einer automatischen Verlängerung deutlich mehr kosten.
SAP beschreibt Source-to-Pay als Geschäftsprozess, der alle Aktivitäten rund um die Beschaffung von Waren und Dienstleistungen umfasst, von der Ermittlung des Bedarfs bis zur Bezahlung des Lieferanten. Für Software ergänzt dieser Leitfaden den Lebenszyklus um Einführung, Lizenznutzung und Vertragsende. Quelle: SAP, Source-to-Pay.
| Phase | Zentrale Frage | Dokumentierter Nachweis | Typischer Verantwortlicher |
|---|---|---|---|
| Bedarf | Welches Problem soll gelöst werden? | Bedarfsbeschreibung, Ziel, gewünschte Nutzerzahl | Anfragendes Team |
| Bestand | Gibt es bereits eine geeignete Lizenz? | Prüfung vorhandener Tools und Verträge | IT / Software-Owner |
| Markt | Welche Lösungen kommen infrage? | Shortlist mit Muss-Kriterien | Fachteam / Einkauf |
| Angebote | Welche Kosten und Leistungen sind vergleichbar? | Schriftliche Angebote, Laufzeiten | Einkauf / Finance |
| Risiko | Darf der Dienst mit unseren Daten arbeiten? | IT-, Sicherheits- und Datenschutzprüfung | IT / Security / Datenschutz |
| Freigabe | Wer darf verbindlich zustimmen? | Entscheidung, Datum, Bedingungen | Budget-Owner / Recht |
| Kauf | Was wurde tatsächlich bestellt? | Vertrag, Bestätigung, Rechnungsdaten | Einkauf / Finance |
| Einführung | Wer richtet Zugriffe und Integrationen ein? | Owner, Rollout- und Abnahmeliste | IT / Fachteam |
| Laufzeit | Wann wird erneut entschieden? | Kündigungsfrist, Verlängerungstermin, Nutzung | Vertrags-Owner |
Die Rollen sind eine empfohlene interne Prozessgestaltung, keine allgemeingültige gesetzliche Zuständigkeitsmatrix. Kleine Teams können Rollen bündeln. Wichtig ist, dass kritische Prüfungen nicht stillschweigend entfallen.
Wie funktioniert der Software-Beschaffungsprozess in 9 Schritten?
1. Bedarf und Entscheidungstermin erfassen
Starte mit einem schriftlichen Bedarf statt mit einem bereits ausgesuchten Anbieter. Das Fachteam sollte beschreiben, welches Problem besteht, welche Arbeitsabläufe betroffen sind und woran eine erfolgreiche Lösung erkennbar wäre. Ergänze gewünschte Nutzerzahl, Budgetrahmen, Einsatzland und spätesten Entscheidungstermin.
Eine brauchbare Anfrage nennt fünf Dinge: die Nutzer des Tools, die übernommene Aufgabe, die verarbeiteten Daten, die Folgen eines Ausfalls und den spätesten Entscheidungstermin. Ein Satz wie „Wir brauchen ein neues CRM“ reicht nicht. „Zwölf Vertriebsmitarbeitende benötigen eine gemeinsame Pipeline mit Export und Rollenrechten“ ist prüfbar.
Ergebnis: Eine Anfrage mit eindeutigem Owner, Datum und messbaren Muss-Kriterien.
2. Vorhandene Software und Lizenzen prüfen
Bevor du neue Angebote einholst, suche in eurem Tool-Verzeichnis nach einer vorhandenen Lösung. Prüfe, ob ein anderes Team die benötigte Funktion bereits bezahlt. Frage nach freien Lizenzen, bestehenden Rahmenverträgen und verfügbaren Integrationen.
Dieser Schritt verhindert nicht automatisch doppelte Ausgaben. Er schafft die Grundlage für eine Entscheidung: bestehende Software erweitern, eine vorhandene Lizenz umverteilen oder ein neues Produkt beschaffen. Dokumentiere auch, warum die Bestandslösung ausscheidet. Sonst beginnt dieselbe Diskussion beim nächsten Kauf erneut.
Ergebnis: „Bestandslösung geeignet“, „Erweiterung prüfen“ oder „Neubeschaffung erforderlich“, jeweils mit Begründung.
3. Anforderungen gewichten und Anbieter eingrenzen
Trenne Muss-Kriterien von Kann-Kriterien. Zu den Muss-Kriterien können bestimmte Datenexporte, rollenbasierte Rechte, ein benötigtes Integrationsverfahren oder eine erforderliche Verfügbarkeit gehören. Kann-Kriterien verbessern die Nutzung, sind aber keine Ausschlussgründe.
Vergib für Kann-Kriterien Gewichte, bevor du Demos ansiehst. Sonst beeinflusst eine überzeugende Präsentation nachträglich die Bewertung. Nutze eine kurze Liste mit zwei bis vier realistischen Anbietern. Das ist eine Faustregel, keine Pflicht für jeden Einkauf.
Eine Bewertungsmatrix hilft nur, wenn die Kriterien auf den tatsächlichen Einsatzfall passen. Ein günstiges Tool ohne zwingend benötigte Exportfunktion bleibt ungeeignet, auch wenn seine Gesamtpunktzahl hoch ausfällt.
Ergebnis: Shortlist und dokumentierte Kriterien einschließlich klarer Ausschlussgründe.
4. Schriftliche Angebote vergleichbar machen
Vergleiche nicht einfach zwei Monatsbeträge. Frage nach der Abrechnungsperiode, Mindestlizenzzahl, Vertragsdauer, Einrichtungsgebühren, Zusatzmodulen, Steuern, Support, Währung und Kündigungsbedingungen. Notiere ausdrücklich, ob der Preis ein öffentliches Listenangebot oder ein individuell verhandeltes Angebot ist.
Für den internen Vergleich kannst du folgende Rechenlogik verwenden:
Kosten im ersten Vertragsjahr = wiederkehrende Kosten für die tatsächlich vereinbarten Monate + einmalige Gebühren + weitere vertraglich zugesagte Kosten.
Kosten über die Laufzeit = Summe aller fälligen Entgelte im vereinbarten Zeitraum.
Wichtig: Wenn ein Anbieter jährlich im Voraus abrechnet, ist die Zahlung anders verteilt als bei monatlicher Abrechnung. Das darf die Gesamtkostenrechnung nicht verzerren. Preissteigerungen nach Ablauf der Erstlaufzeit gehören in eine separate Verlängerungssimulation, wenn sie vertraglich feststehen. Unbekannte Erhöhungen bleiben als Risiko offen.
| Posten | Erstes Angebot | Zweites Angebot |
|---|---|---|
| Benötigte Lizenzen | 20 | 20 |
| Preis je Lizenz und Monat | 15 € | 12 € |
| Vereinbarte Laufzeit | 12 Monate | 12 Monate |
| Einmalige Einrichtung | 0 € | 900 € |
| Gesamtkosten für 12 Monate | 3.600 € | 3.780 € |
Rechenbeispiel mit zwei fiktiven Angeboten: Das erste Angebot (A) kostet 20 × 15 € × 12 = 3.600 €. Das zweite Angebot (B) kostet 20 × 12 € × 12 + 900 € = 3.780 €. Angebot B hat den niedrigeren Preis je Lizenz, aber die höheren Gesamtkosten im Beispiel. Nicht enthalten sind Steuern, variable Nutzung und spätere Vertragsänderungen.
Ergebnis: Vergleichbare schriftliche Angebote und eine nachvollziehbare Kostenrechnung.
5. IT-Sicherheit und Datenschutz prüfen
Der Prüfaufwand richtet sich nach Daten, Integrationen und geschäftlicher Kritikalität. Ein kleines Design-Tool ohne vertrauliche Daten braucht nicht dieselbe Prüfung wie ein System mit Kunden-, Gesundheits- oder Personaldaten. Lege vorab fest, welche Fragen bei welchem Risiko zwingend beantwortet werden müssen.
Prüfe beispielsweise Authentifizierung und Rechteverwaltung, Protokollierung, Datenexport, Sicherungen, Störfallkommunikation, Speicherorte, Unterauftragnehmer und das Vorgehen bei Vertragsende. Fordere Nachweise an, statt eine Zertifizierung aus einem Werbebanner abzuleiten. Eine Zertifizierung oder ein Prüfbericht muss zum konkret eingesetzten Dienst und seinem Geltungsbereich passen.
Der BSI-Baustein OPS.2.2 „Cloud-Nutzung“ behandelt unter anderem Anforderungsprofile, die Auswahl von Cloud-Anbietern, Nachweise zur Informationssicherheit und die geordnete Beendigung. Das ist eine fachliche Orientierung, keine Aussage, dass jedes Unternehmen denselben Baustein zwingend anwenden muss.
Wenn ein Dienst personenbezogene Daten im Auftrag verarbeitet, sind die Anforderungen aus Artikel 28 DSGVO zu prüfen. Ob im konkreten Fall Auftragsverarbeitung vorliegt und welche Vertragsunterlagen benötigt werden, entscheidet sich anhand der tatsächlichen Verarbeitung und Rollen. Nicht jeder SaaS-Vertrag ist automatisch ein Auftragsverarbeitungsvertrag.
Ergebnis: Freigegebene Sicherheits- und Datenschutzbewertung oder klar dokumentierte offene Punkte. Kritische Lücken bleiben ein Stoppgrund, bis sie geklärt sind.
6. Budget, Vertrag und Kaufentscheidung freigeben
Eine Entscheidung braucht einen benannten Freigabeberechtigten. Das kann der Budget-Owner sein, gegebenenfalls ergänzt um IT, Security, Datenschutz und Recht. Lege die Regeln intern fest, etwa anhand von Vertragswert und Risiko. Die folgende Tabelle zeigt Beispiele für Prüfpfade, keine gesetzlichen Schwellen.
| Situation | Möglicher Prüfpfad |
|---|---|
| Bereits genehmigtes Tool, zusätzliche Standardlizenz | Budget-Owner und Lizenz-Owner |
| Neuer Dienst ohne sensible Daten, kleiner Umfang | Budget-Owner und IT-Check |
| Neuer Dienst mit personenbezogenen Daten | Budget, IT/Security und Datenschutzprüfung |
| Kritisches System mit langer Bindung | Budget, IT/Security, Datenschutz soweit relevant, Recht und Geschäftsverantwortung |
Dokumentiere, welches konkrete Angebot freigegeben wurde. Eine geänderte Laufzeit oder ein neuer Anbieter kann eine neue Entscheidung erfordern. Bewahre Angebot, Prüfunterlagen, Freigaben und Vertrag gemeinsam auf. So lässt sich später nachvollziehen, warum ein Kauf zustande kam.
Ergebnis: Datiertes Ja, Nein oder „Ja unter Bedingungen“ für genau eine Angebotsversion.
7. Bestellung, Zahlung und Vertragsdaten sauber übergeben
Nach der Freigabe legt der Einkauf oder die berechtigte Person die Bestellung an. Übertrage die freigegebenen Konditionen ohne Abweichung. Hinterlege den tatsächlichen Vertragsbeginn, Rechnungsadresse, Zahlungsweise, Vertrags-Owner und Kontakt beim Anbieter.
Die Buchhaltung benötigt die Bestell- oder Vertragsreferenz, damit sie Rechnungen zuordnen kann. Prüfe, ob eine Bestellung, ein unterzeichneter Vertrag oder eine Online-Bestätigung die verbindliche Grundlage ist. Ein Screenshot einer Preisseite ersetzt keinen belastbaren Nachweis über den tatsächlich geschlossenen Vertrag.
Ergebnis: Kaufbeleg, Vertragsakte und eindeutiger Verantwortlicher für die Laufzeit.
8. Software einführen und abnehmen
Plane die Einrichtung von Nutzerkonten, Rollen, Datenimporten, Integrationen, Schulungen und Supportwegen. Lege fest, wer die technische Abnahme und wer die fachliche Abnahme übernimmt.
Teste mit realistischen, datenschutzkonformen Beispieldaten. Prüfe auch einen Export, bevor produktive Informationen ausschließlich im neuen Dienst liegen. Bei kritischen Abläufen braucht es einen Rückfallplan. Dokumentiere, welche Anforderungen aus Schritt 3 erfüllt wurden und welche bewusst zurückgestellt sind.
Ergebnis: Abnahmeprotokoll, Betriebs-Owner und ein erster Termin zur Nutzungsprüfung.
9. Nutzung, Kündigungsfristen und Verlängerung steuern
Halte bereits beim Kauf das Laufzeitende und die vertragliche Kündigungsfrist fest. Setze eine interne Entscheidungsfrist deutlich vor die externe Frist. Die Vorlaufzeit hängt vom Vertrag und dem Aufwand für einen möglichen Wechsel ab.
Prüfe vor der Verlängerung aktive Lizenzen, tatsächlichen Bedarf, neue Angebote, Supportprobleme, offene Sicherheitsfragen und Datenexport. Kündigung, Verlängerung und Wechsel sollten wieder als dokumentierte Entscheidung enden. Wenn ein Anbieter gewechselt wird, gehören Zugriffsabbau, Datenmigration und Löschbestätigung in die Übergabe.
Das BSI empfiehlt im genannten Cloud-Baustein eine geordnete Beendigung des Nutzungsverhältnisses und behandelt Portabilität bei erhöhtem Schutzbedarf. Eine Exportfunktion allein garantiert noch keinen reibungslosen Anbieterwechsel.
Ergebnis: Verlängerung, Anpassung oder Kündigung mit rechtzeitigem Nachweis und verantwortlichem Owner.
Welche Vorlage brauche ich für einen Softwarekauf?
Für kleinere Teams reicht oft ein gemeinsamer Vorgang mit standardisierten Feldern. Kopiere die folgende Struktur in ein Dokument, ein Ticket oder eine Tabelle. Sie ist sofort als Text nutzbar; eine Excel-Datei zum Download gibt es dazu nicht.
| Feld | Leitfrage |
|---|---|
| Vorgangs-ID | Eindeutige interne Nummer |
| Anfragendes Team und Owner | Wer trägt den Bedarf? |
| Problem und gewünschtes Ergebnis | Welche Arbeit wird erleichtert? |
| Bestehende Alternative | Welches Tool wurde bereits geprüft? |
| Muss-Kriterien | Welche Funktionen sind unverzichtbar? |
| Nutzerzahl / Rollen | Wie viele Lizenzen und welche Zugriffe? |
| Datenkategorien | Welche Informationen fließen in den Dienst? |
| Anbieter und Angebotsversion | Wer bietet was zu welchen Bedingungen? |
| Laufzeit und Gesamtkosten | Welche Zahlungen entstehen bis Vertragsende? |
| IT-/Security-Prüfung | Wer hat was wann geprüft? |
| Datenschutz / Recht | Erforderlich, geprüft, offen oder nicht einschlägig? |
| Budget-Freigabe | Person, Datum und Bedingungen |
| Entscheidung | Kaufen, nacharbeiten oder ablehnen |
| Vertragsbeginn und Kündigungsfrist | Verbindliche Daten aus dem Vertrag |
| Betriebs-Owner und nächster Review | Wer kontrolliert Nutzung und Verlängerung? |
Eine zusätzliche Statusspalte macht den Ablauf sichtbar: Anfrage → Bestand geprüft → Anbieterprüfung → Angebotsvergleich → Risiko-/Vertragsprüfung → Freigabe → Gekauft → Eingeführt → Verlängerungsprüfung. Ein Vorgang darf nur weitergehen, wenn die für diese Phase erforderlichen Nachweise vorliegen.
Atlassian beschreibt auf seiner deutschen Jira-Seite eine Beschaffungsvorlage mit Formularen, Aufgabenlisten und anpassbaren Workflows. Das ist ein Beispiel für die technische Abbildung, nicht die einzig geeignete Lösung. Ein sauber geführtes Tabellenblatt kann bei wenigen Käufen ebenfalls genügen.
Wer sollte bei der Softwarebeschaffung entscheiden?
Die Fachabteilung verantwortet den Nutzen, Finance das Budget, IT die technische Einbindung und Security die Sicherheitsanforderungen. Datenschutz und Recht prüfen ihre jeweiligen Themen, wenn sie einschlägig sind. Der Einkauf koordiniert Angebote und Vertragsunterlagen. Eine benannte Person besitzt den gesamten Vorgang und sorgt dafür, dass keine Entscheidung zwischen Abteilungen liegen bleibt.
Vermeide eine scheinbar gemeinsame Verantwortung ohne Entscheidungskompetenz. Schreibe für jede Prüfung auf, wer entscheidet, wer mitwirkt und wer lediglich informiert wird. Wenn eine Rolle in einem kleinen Unternehmen fehlt, benenne ausdrücklich die Person, die ihre Aufgaben übernimmt, und kläre bei rechtlichen Fragen die notwendige Fachberatung.
Eine einfache RACI-Logik kann helfen: R führt aus, A trägt die Entscheidung, C wird konsultiert und I wird informiert. Das Modell ist eine Organisationshilfe. Es ersetzt weder interne Unterschriftsregeln noch gesetzliche Verantwortlichkeiten.
Wie unterscheidet sich SaaS-Beschaffung von einmaligem Softwarekauf?
Bei SaaS laufen Leistung und Kosten weiter, solange der Vertrag besteht. Deshalb ist der Software-Beschaffungsprozess nach dem ersten Kauf nicht abgeschlossen. Er braucht einen aktiven Vertrags-Owner, einen Verlängerungskalender und regelmäßige Nutzungsprüfungen.
Eine einmalige Desktop-Lizenz kann ebenfalls Wartung, Support und Datenschutzfragen auslösen. Trotzdem sind bei SaaS besonders die Zahl der aktiven Konten, flexible Tarifstufen, laufende Zahlungen, Zugriffsentzug und Datenportabilität relevant. Vergleiche deshalb nicht nur den Startpreis, sondern die tatsächlichen Vertragsbedingungen und den geplanten Betrieb.
Wenn ein Anbieter Sicherheitsfunktionen wie SSO oder Audit-Logs anbietet, prüfe, ob sie im konkret angebotenen Tarif enthalten sind. Eine allgemeine Produktseite belegt nicht automatisch die Verfügbarkeit im eigenen Vertrag.
Wie sieht ein vollständiger Softwarekauf in der Praxis aus?
Fiktiver Fall: Ein Team mit 20 Beschäftigten möchte elektronische Signaturen einführen. Der Bedarf lautet: Vertragsunterlagen sollen digital versendet, unterschrieben und anschließend exportiert werden können. Das Budget liegt intern bei 4.000 € für das erste Jahr. Alle Zahlen und Entscheidungen in diesem Beispiel sind erfunden und dienen ausschließlich der Veranschaulichung.
Das Team prüft zuerst bestehende Verträge. Eine vorhandene Lösung bietet die erforderliche Funktion nicht im gebuchten Tarif. Danach definiert es Muss-Kriterien: nachvollziehbarer Signaturprozess, Export, geeignete Berechtigungen und ein für den konkreten Dokumententyp passender rechtlicher Rahmen. Zwei Anbieter kommen in die engere Wahl.
Der Einkauf holt schriftliche Angebote ein und berechnet die Kosten über die jeweils vereinbarte Laufzeit. IT prüft die Kontenverwaltung und Exportmöglichkeiten. Datenschutz und Recht klären anhand der konkreten Dokumente und Daten, welche Vertrags- und Signaturanforderungen gelten. Finance gibt den Budgetrahmen frei, sobald IT und Datenschutz ihre Prüfung abgeschlossen haben.
Erst dann wird bestellt. Die IT richtet vor dem Produktivbetrieb einen kleinen Pilot ein, das Fachteam nimmt den Ablauf ab und der Vertrags-Owner erfasst die Kündigungsfrist. Drei Monate vor der internen Entscheidungsfrist, als frei gewählter organisatorischer Puffer, prüft das Team die Nutzung. Dieser Puffer ist keine allgemein vorgeschriebene Frist.
Welche Fehler verzögern Softwarekäufe besonders häufig?
Ein Anbieter steht schon fest, bevor Anforderungen definiert sind. Dadurch wird die Auswahl zur nachträglichen Rechtfertigung. Beginne mit dem Problem und den Muss-Kriterien.
Preise werden auf unterschiedlicher Basis verglichen. Ein monatlicher Listenpreis und ein jährliches Angebot mit Einrichtungsgebühr sind nicht unmittelbar vergleichbar. Rechne beide auf dieselbe Laufzeit und Nutzerzahl um.
Datenschutz wird erst nach der Unterschrift eingebunden. Dann können notwendige Vertragsänderungen den Start verzögern. Prüfe die Datenverarbeitung frühzeitig, ohne pauschal jeden Dienst als Auftragsverarbeitung einzustufen.
Freigaben gelten nur mündlich. Eine mündliche Zusage lässt oft offen, welche Angebotsversion gemeint war. Erfasse Entscheider, Datum, geprüfte Version und Bedingungen.
Der Vertrag hat keinen Owner. Dann werden Kündigungsfristen übersehen und Lizenzen nicht überprüft. Benenne den Owner bereits vor dem Kauf.
Ein Tool wird nur wegen des niedrigen Einstiegspreises gewählt. Fehlende Integrationen, teure Zusatzmodule oder schwierige Exporte können den Nutzen mindern. Prüfe Gesamtbedingungen und den geplanten Betrieb.
Brauche ich eine Software für den Beschaffungsprozess?
Nicht zwingend. Bei wenigen Anfragen kann eine Tabelle mit klaren Zuständigkeiten funktionieren. Wenn mehrere Teams gleichzeitig Software bestellen, Angebote vergleichen und Freigaben dokumentieren müssen, kann eine spezialisierte Lösung den Prozess übersichtlicher machen. Entscheidend ist nicht die Anzahl der Funktionen, sondern ob die gewählte Lösung eure tatsächlichen Übergaben und Prüfungen abbildet.
Scout SaaS ist unser eigenes Produkt und beschreibt auf der deutschsprachigen Website einen Workspace für Softwareanfragen, Anbieterangebote sowie Sicherheits-, Rechts- und Budgetprüfungen. Laut Anbieter werden Entscheidungen am jeweiligen Einkaufsvorgang dokumentiert; die eigentliche Angebotseinholung und der Kauf bleiben beim Team. Die App-Oberfläche ist laut Website auf Englisch. Die Beschreibung stammt vom Hersteller, also von uns, und ist kein unabhängiger Praxistest.
Für einen Marktvergleich verschiedener Anbieter gibt es außerdem das bestehende SaaS-Procurement-Software-Verzeichnis auf Englisch. Es behandelt die Auswahl von Beschaffungstools. Dieser Artikel behandelt dagegen den internen Prozess für den Einkauf beliebiger Software.
Wie messe ich, ob der Beschaffungsprozess funktioniert?
Wähle wenige Kennzahlen, die ein konkretes Problem sichtbar machen. Die folgenden Definitionen sind redaktionelle Vorschläge, keine externen Benchmarks:
| Kennzahl | Berechnung | Wofür sie hilft |
|---|---|---|
| Durchlaufzeit | Entscheidungstag minus Eingangstag | Lange Bearbeitung erkennen |
| Nachforderungsquote | Anfragen mit fehlenden Angaben / alle Anfragen | Qualität der Bedarfsmeldung prüfen |
| Anteil dokumentierter Freigaben | Käufe mit vollständigem Freigabenachweis / alle Käufe | Nachvollziehbarkeit prüfen |
| Verlängerungen mit rechtzeitiger Entscheidung | Vor interner Frist entschiedene Verträge / fällige Verträge | Verlängerungsprozess beurteilen |
| Genutzte Lizenzen | Im Review tatsächlich benötigte Lizenzen / bezahlte Lizenzen | Über- oder Unterversorgung erkennen |
Definiere vor der Messung, welche Vorgänge zählen. Eine zurückgezogene Anfrage sollte beispielsweise nicht ohne Kennzeichnung die durchschnittliche Kaufdauer verfälschen. Leite keine Einsparungsquote aus einem Listenpreis ab, wenn es keinen belastbaren Vergleichswert gibt.
Häufige Fragen zum Software-Beschaffungsprozess
Wie lange dauert ein Software-Beschaffungsprozess?
Es gibt keine allgemeingültige Dauer. Ein zusätzlicher Platz in einem bereits genehmigten Dienst kann schnell freigegeben werden. Eine neue Plattform mit sensiblen Daten, Integrationen und Vertragsverhandlungen braucht meist mehr Abstimmung. Miss die tatsächliche Durchlaufzeit im eigenen Unternehmen statt einen pauschalen Branchenwert zu übernehmen.
Ist ein RFP für jeden Softwarekauf notwendig?
Nein. Ein formelles Request for Proposal kann bei komplexen Anforderungen sinnvoll sein. Für kleine, risikoarme Käufe genügt häufig eine kurze dokumentierte Anfrage mit vergleichbaren Angeboten. Ob besondere Vergaberegeln gelten, hängt vom jeweiligen Unternehmen und Rechtsrahmen ab. Für öffentliche Auftraggeber können andere Anforderungen gelten.
Muss bei jedem SaaS-Kauf ein AV-Vertrag geschlossen werden?
Nein. Zuerst muss geklärt werden, ob der Anbieter personenbezogene Daten als Auftragsverarbeiter verarbeitet. Wenn das zutrifft, sind die Anforderungen aus Artikel 28 DSGVO relevant. Die Einordnung hängt vom konkreten Dienst und der Verarbeitung ab.
Wer ist für eine Vertragsverlängerung zuständig?
Ein namentlich benannter Vertrags-Owner sollte die Entscheidung koordinieren. Budget, IT und andere Prüfstellen werden nach Bedarf beteiligt. Die interne Zuständigkeit sollte schon bei der ersten Bestellung festgelegt werden.
Was ist der Unterschied zwischen Beschaffung und Softwareauswahl?
Die Softwareauswahl vergleicht Anforderungen und Anbieter. Die Beschaffung umfasst zusätzlich Anfrage, interne Freigaben, Vertrag, Bestellung, Einführung und laufende Vertragssteuerung. Eine Bewertungsmatrix deckt deshalb nur einen Teil des Gesamtprozesses ab.
Fazit: Ein Vorgang, ein Owner, eine nachvollziehbare Entscheidung
Ein guter Software-Beschaffungsprozess beginnt mit dem Bedarf und endet nicht beim Kauf. Halte Anforderungen, Angebote, Sicherheitsprüfungen, Freigaben und Vertragsdaten in einem gemeinsamen Vorgang fest. Gib jedem Kauf einen Owner und plane die nächste Vertragsentscheidung rechtzeitig ein. So bleibt Softwarebeschaffung auch bei mehreren beteiligten Teams nachvollziehbar.
Quellen und fachliche Grundlagen, geprüft am 02.11.2026: SAP (Source-to-Pay), BSI: OPS.2.2 Cloud-Nutzung, EUR-Lex: DSGVO, Artikel 28, Atlassian (Jira-Beschaffungsvorlage).