Eine Software-Einkaufsfreigabe prüft Bedarf, Budget, Risiken und Vertrag, bevor jemand bestellt. Sie endet mit einer dokumentierten Entscheidung einer Person, die dafür unterschreiben darf. Mit einem festen Antrag, klaren Rollen und einer kopierbaren Checkliste bleibt der Ablauf auch bei mehreren beteiligten Teams leichter nachvollziehbar.
- Trenne fachliche Empfehlung, Kontrollprüfung und verbindliche Entscheidung.
- Lege die Prüftiefe nach Risiko fest, nicht nur nach der Höhe der Ausgabe.
- Gib jede Freigabe für genau eine Angebots- und Vertragsversion und halte Auflagen schriftlich fest.
- Benenne schon vor der Bestellung einen Owner, der Rechnungen, Nutzer und Verlängerung betreut.
Was ist eine Software-Einkaufsfreigabe?
Eine Software-Einkaufsfreigabe ist die dokumentierte Entscheidung vor einer Bestellung, dass ein konkretes Angebot gekauft werden darf. Sie verbindet die fachliche Notwendigkeit, die verfügbaren Mittel, die technischen Risiken und die Vertragsbedingungen zu einem Ja, einem Nein oder einer Entscheidung unter Auflagen.
Eine Budgetzusage allein reicht dafür nicht. Ein bestandener Sicherheitstest ist ebenfalls noch keine Unterschriftsberechtigung. Definiere deshalb, wer den Bedarf bestätigt, wer kontrolliert und wer die Bestellung rechtsverbindlich auslösen darf. Die genaue Rollenverteilung ergibt sich aus euren internen Regeln und nicht aus einer universellen Standardliste.
Die Freigabe ist ein Teil des größeren Ablaufs. Wie eine Anfrage von der Bedarfsmeldung bis zur Verlängerung wandert, beschreibt der Leitfaden zum Software-Beschaffungsprozess. Wie du mehrere Anbieter vergleichbar bewertest, zeigt die Softwareauswahl-Matrix. Dieser Artikel konzentriert sich auf den Moment dazwischen, also auf die Frage, wer auf Basis welcher Unterlagen Ja sagen darf.
Dokumentiere die geprüfte Angebotsversion und jede Auflage. Eine spätere Änderung von Laufzeit, Datenzugriff oder Leistungsumfang kann eine neue Entscheidung erfordern.
Welche Schritte umfasst die Freigabe?
Die Freigabe umfasst sieben Schritte: Antrag stellen, Bestand prüfen, fachlich bewerten, Kontrollprüfungen durchführen, entscheiden, bestellen und übergeben. Jeder Schritt endet mit einem Ergebnis, das ein anderer Beteiligter ohne Rückfrage lesen kann.
1. Antrag mit Problem und Ergebnis stellen
Der Antragsteller beschreibt das Problem, das gewünschte Ergebnis, den Zieltermin und die verantwortliche Person. Ein Antrag, der nur einen Produktnamen nennt, ist unvollständig und geht zur Ergänzung zurück.
2. Vorhandene Anwendungen prüfen
Die IT oder der Software-Owner prüft, ob eine vorhandene Lizenz, ein Rahmenvertrag oder eine bestehende Anwendung den Bedarf schon deckt. Begründe schriftlich, warum die Bestandslösung ausscheidet.
3. Fachliche Eignung bewerten
Der Fachbereich bestätigt, dass das Angebot zum beschriebenen Anwendungsfall passt und welche Muss-Kriterien erfüllt sind.
4. Kontrollprüfungen durchführen
IT, Informationssicherheit, Datenschutz, Einkauf und Finanzen prüfen ihre jeweiligen Fragen. Nicht jeder Fall braucht alle Prüfer. Die Prüfpflichten richten sich nach Risiko und interner Kompetenzordnung.
5. Entscheiden
Die entscheidungsberechtigte Rolle genehmigt, lehnt ab oder fordert Ergänzungen an. Dafür braucht sie eine Übersicht, welche Prüfungen abgeschlossen, offen oder mit Auflagen versehen sind.
6. Zu den genehmigten Bedingungen bestellen
Einkauf oder die bevollmächtigte Rolle löst die Bestellung nur mit den genehmigten Konditionen aus. Weicht das Angebot ab, geht der Vorgang zurück zu Schritt 5.
7. An den Betrieb übergeben
Der künftige Owner übernimmt Nutzer, Rechnungen, Verlängerungstermine und den späteren Ausstieg. Die IT richtet Zugriffe entsprechend den Auflagen aus den Prüfungen ein.
Nicht jeder Fall braucht die volle Strecke. Eine Verlängerung ohne wesentliche Änderung kann einen verkürzten Weg nehmen, wenn eure Regeln das ausdrücklich vorsehen. Wichtig ist, dass die Verkürzung eine dokumentierte Regel ist und keine stillschweigende Abkürzung.
Welche Statuswerte braucht ein transparenter Workflow?
Ein transparenter Workflow braucht eindeutige Statuswerte, eine zuständige Rolle je Status und erlaubte Übergänge. Ob du das in einem Ticketsystem, einer Tabelle oder einem Formular abbildest, ist zweitrangig. Entscheidend sind Zugriffsrechte, Versionsstand und eine nachvollziehbare Entscheidung.
| Status | Bedeutung | Zuständige Rolle | Erlaubter nächster Status |
|---|---|---|---|
| Entwurf | Antrag wird noch erstellt | Antragsteller | Eingereicht |
| Eingereicht | Antrag liegt zur Vollständigkeitsprüfung vor | Software-Owner oder Einkauf | Rückfrage, In Prüfung |
| Rückfrage | Angaben fehlen oder sind unklar | Antragsteller | Eingereicht |
| In Prüfung | Kontrollprüfungen laufen | Jeweilige Prüfer | Rückfrage, Entscheidungsreif |
| Entscheidungsreif | Alle Pflichtprüfungen liegen vor | Entscheider | Genehmigt, Abgelehnt, Rückfrage |
| Genehmigt | Bestellung unter Bedingungen erlaubt | Einkauf | Bestellt, Entscheidungsreif (wenn das Angebot abweicht) |
| Abgelehnt | Bestellung nicht erlaubt, Begründung liegt vor | Entscheider | Abgeschlossen |
| Bestellt | Bestellung ist ausgelöst | Einkauf | Abgeschlossen |
| Abgeschlossen | Vorgang beendet, Owner benannt, Unterlagen abgelegt | Owner | Keiner |
Ein Rückfrage-Status ist keine Ablehnung. Er darf den Vorgang aber auch nicht unsichtbar beenden: Setze eine Frist und eine Person, die nachfasst.
Welche Angaben gehören in den Antrag?
In den Antrag gehören Antrags-ID, Antragsteller, Team, Anwendungsfall, Zieltermin, das Angebot samt Vertragsversion, sofern schon eines vorliegt, und der künftige Owner. Beschreibe das Problem so konkret, dass auch jemand außerhalb des Teams den Bedarf versteht.
Ergänze vorhandene Alternativen und warum sie nicht ausreichen. Notiere gewünschte Nutzergruppen, Datenkategorien, Integrationen und benötigte Administratorrechte. Wichtig am Angebot sind Währung, Abrechnungsperiode, Laufzeit, Verlängerungsbedingungen und mögliche Zusatzleistungen.
Die folgende Tabelle ist ein Muster für einen Freigabeantrag. Die Werte sind fiktiv und dienen nur zur Illustration. Ersetze sie durch echte Angaben und verlinke die Nachweise. Leere oder offene Felder gelten nie als Freigabe. Die Statuswerte in dieser Tabelle gelten für einzelne Prüffelder, nicht für den ganzen Vorgang.
| Feld | Fiktiver Eintrag | Prüfer | Status |
|---|---|---|---|
| Antrag | SW-014 | Einkauf | Erfasst |
| Bedarf | Übergaben zwischen Teams vereinfachen | Fachbereich | Geprüft |
| Bestandslösung | Nicht passend, Begründung liegt bei | IT | Geprüft |
| Angebot | Version A, 12 Monate | Einkauf | Offen |
| Budget | Kostenstelle intern bestätigen | Finanzen | Offen |
| Daten | Interne Vorgänge, keine Kundendaten | Datenschutz | Offen |
| Zugriffsrechte | Auf Teammitglieder begrenzt | IT | Offen |
| Vertrag | Entwurf liegt vor | Einkauf | Offen |
| Entscheidung | Noch nicht erteilt | Entscheider | Offen |
| Betriebsowner | Zu benennen | Fachbereich | Offen |
Füge in der produktiven Version Spalten für Prüfdatum, Beleglink und letzte Änderung hinzu. Unbekannte Angaben müssen sichtbar offen bleiben, statt stillschweigend als bestanden zu gelten.
Wer ist für die Freigabe verantwortlich?
Für die Freigabe sind mehrere Rollen verantwortlich, und nur eine davon entscheidet verbindlich. Trenne deshalb fachliche Empfehlung, Kontrollprüfung und Entscheidung.
| Rolle | Prüffrage | Ergebnis |
|---|---|---|
| Fachbereich | Passt das Angebot zum Anwendungsfall? | Fachliche Empfehlung |
| IT | Passt die Anwendung in die vorhandene Landschaft und wer betreibt sie? | Betriebs- und Integrationsbewertung |
| Informationssicherheit | Welche technischen Risiken bestehen? | Befunde und Auflagen |
| Datenschutz | Werden personenbezogene Daten verarbeitet und unter welchen Bedingungen? | Einschätzung, gegebenenfalls Vereinbarungen |
| Einkauf | Sind Beschaffungsweg, Angebot und Vertragsunterlagen in Ordnung? | Vertragsprüfung |
| Finanzen | Ist das Budget gedeckt und welche Kostenstelle wird belastet? | Budgetbestätigung |
| Recht (falls vorhanden) | Sind die Vertragsklauseln akzeptabel? | Rechtsprüfung |
| Entscheider | Reichen die vorliegenden Nachweise für ein Ja? | Genehmigung, Ablehnung oder Auflage |
Die entscheidungsberechtigte Rolle richtet sich nach der internen Vollmacht. In kleinen Teams fallen Rollen zusammen. Dann sollte die Entscheidung nicht allein bei der Person liegen, die den Antrag gestellt hat. Dokumentiere dennoch die unterschiedlichen Prüffragen, denn aus ihnen ergibt sich, wer was geprüft hat. Das ist eine Empfehlung für die interne Prozessgestaltung und keine gesetzliche Zuständigkeitsmatrix.
Wie lege ich sinnvolle Freigabestufen fest?
Lege Freigabestufen anhand von Risiko und finanzieller Verpflichtung fest, nicht nach einer einzelnen Betragsgrenze. Übernimm keine beliebigen Eurogrenzen aus einer fremden Vorlage, sondern prüfe zuerst bestehende Zeichnungsregeln, Budgetzuständigkeiten und Risikoklassen.
Eine geringe Ausgabe kann wegen umfangreicher Zugriffsrechte trotzdem kritisch sein. Eine höhere Ausgabe kann bei klar begrenztem Einsatz technisch überschaubar sein. Bewerte deshalb finanzielle Verpflichtung und technische Tragweite getrennt und kombiniere beide.
| Fall | Finanzielle Verpflichtung | Technische Tragweite | Sinnvoller Weg |
|---|---|---|---|
| Bekannte Verlängerung ohne Änderung | Gering bis mittel | Gering | Verkürzter Weg mit Owner und Abgleich der tatsächlichen Nutzerzahl |
| Neues Werkzeug für ein Team ohne sensible Daten | Gering | Gering | Standardweg mit IT-Kurzprüfung |
| Neues Werkzeug mit personenbezogenen Daten | Gering | Hoch | Standardweg mit Datenschutz und Sicherheit |
| Mehrjahresvertrag mit hoher Summe, begrenzter Einsatz | Hoch | Gering | Erweiterter Weg mit Einkauf, Finanzen und Rechtsprüfung |
| Unternehmensweiter Einsatz mit Integrationen | Hoch | Hoch | Voller Weg mit allen Prüfern und Entscheider auf Leitungsebene |
Die Wege unterscheiden sich in den beteiligten Prüfern: Der verkürzte Weg braucht nur Owner und Einkauf, der Standardweg zusätzlich eine IT-Kurzprüfung, der erweiterte und der volle Weg alle Prüfer. Lege fest, wann Datenschutz, Sicherheit oder Rechtsprüfung zwingend einzubeziehen sind. Jede Ausnahme braucht eine begründete Entscheidung durch die zuständige Rolle. Überprüfe die Regeln regelmäßig anhand tatsächlich aufgetretener Rückfragen und Fälle.
Wie prüfe ich die Kosten richtig?
Prüfe die Kosten am konkreten Angebot und nicht an einer ungeprüften Preisliste. Trenne dabei Listenpreis, individuell angebotenen Preis, monatlich kündbare Zahlung und den rechnerischen Monatswert einer jährlichen Abrechnung. Ein aus einem Jahresvertrag errechneter Monatsdurchschnitt ist kein monatlich kündbarer Preis.
Notiere außerdem Einführungsaufwand, Migration, Schulung und mögliche nutzungsabhängige Gebühren. Halte bei Aktionen die Gültigkeit des Rabatts und die Bedingungen nach Ablauf fest. Prüfe Vertragslaufzeit, automatische Verlängerung, Kündigungsfrist und Exportmöglichkeiten.
Das folgende Rechenbeispiel ist fiktiv und zeigt, warum der Monatswert allein nicht reicht. Ein Team von 25 Personen prüft dasselbe Werkzeug in zwei Zahlungsarten.
| Posten (fiktiv) | Jahresvertrag | Monatlich kündbar |
|---|---|---|
| Preis je Lizenz und Monat | 18 € | 22 € |
| Lizenzen | 25 | 25 |
| Laufende Kosten im ersten Jahr | 5.400 € | 6.600 € |
| Einrichtung (einmalig) | 600 € | 0 € |
| Summe im ersten Jahr | 6.000 € | 6.600 € |
| Zusätzlich gebunden | Zwölf Monate, bei Nichtkündigung Verlängerung | Nur der laufende Monat |
Der Jahresvertrag ist im Beispiel um 600 € günstiger, bindet das Team aber zwölf Monate. Ob die Ersparnis das Risiko trägt, hängt davon ab, wie sicher der Bedarf ist. Genau diese Abwägung gehört in die Entscheidungsvorlage.
Dokumentiere auch, welche Kostenstelle belastet wird und wer Rechnungen kontrolliert. Wenn ein Anbieter keine klare Aussage zu einem Preisbestandteil liefert, ist das Ergebnis offen und gehört als Rückfrage in den Prozess.
Welche Datenschutz- und Sicherheitsfragen muss ich klären?
Kläre vor der Freigabe, welche Daten in die Anwendung gelangen, wer Zugriff erhält, welche Systeme verbunden werden und wie der Ausstieg aussieht. Beginne mit einem einfachen Datenfluss, der zeigt, was hineingeht, was herauskommt und wer es sieht.
Frage nach Benutzerverwaltung, Berechtigungen, Administratorrechten und dem Umgang mit ausscheidenden Mitarbeitenden. Untersuche außerdem, wie Daten exportiert und Integrationen getrennt werden können.
Bei personenbezogenen Daten muss die zuständige Stelle die konkrete Verarbeitung und gegebenenfalls erforderliche Vereinbarungen prüfen. Ob ein Anbieter etwa als Auftragsverarbeiter tätig wird, hängt vom konkreten Dienst ab. Sicherheitsversprechen auf einer Anbieterseite ersetzen keine interne Prüfung. Notiere Befunde, Nachweise, offene Fragen und verantwortliche Personen. Kritische offene Punkte sollten vor der Bestellung geklärt sein.
Der Ausstieg ist Teil der Risikoanalyse. Lege vor dem Kauf fest, wer Export, Löschung und Abschaltung organisiert, falls der Vertrag endet. Das lässt sich vorher leicht klären und danach nur noch mit Aufwand.
Wie dokumentiere ich die Entscheidung?
Dokumentiere die Entscheidung in einem Nachweis, der Antrags-ID, Anbieter, Angebotsversion, geprüfte Unterlagen, Datum, entscheidende Rolle und Ergebnis nennt. Füge gegebenenfalls Auflagen und einen Wiedervorlagetermin hinzu.
| Feld | Fiktives Beispiel |
|---|---|
| Antrags-ID | SW-014 |
| Anbieter und Angebotsversion | Anbieter X, Angebot Version A vom 3. November 2026 |
| Geprüfte Unterlagen | Antrag, Angebot, Vertragsentwurf, IT-Bewertung, Budgetbestätigung, Datenschutzeinschätzung |
| Entscheidung | Genehmigt unter Auflagen |
| Auflagen | Zugriff auf Teammitglieder begrenzen, Exportfunktion vor Vertragsschluss bestätigen lassen |
| Entscheidende Rolle und Datum | Leitung Fachbereich, 5. November 2026 |
| Wiedervorlage | Drei Monate vor Vertragsende |
Bewahre die Nachweise nach den internen Regeln auf und begrenze den Zugriff auf berechtigte Personen. Preisverhandlungen oder personenbezogene Angaben gehören nicht automatisch in einen für alle sichtbaren Kanal. Dokumentiere auch eine Ablehnung mit verständlicher Begründung, damit derselbe Antrag nicht ohne neue Argumente erneut gestellt wird.
Wenn sich nach der Freigabe Nutzerumfang, Datenarten oder Laufzeit ändern, prüfe, ob die Entscheidung noch trägt. Versionierung erleichtert spätere Audits.
Was muss nach der Genehmigung passieren?
Nach der Genehmigung löst Einkauf oder die bevollmächtigte Rolle die Bestellung nur zu den genehmigten Bedingungen aus. Die IT richtet Zugriffe und Berechtigungen entsprechend den Auflagen aus den Prüfungen ein.
Bestimme einen Vertragsowner, der Rechnungen, Nutzung, Änderungen und Verlängerungstermine überwacht. Dokumentiere Vertragsbeginn, relevante Fristen und den Speicherort der Unterlagen. Vor einer Verlängerung solltest du Nutzen, tatsächliche Nutzerzahl, Risiken und mögliche Alternativen erneut betrachten. Wie du Anbieter für eine solche Neubewertung strukturiert vergleichst, zeigt die Softwareauswahl-Checkliste.
Auch eine Ablehnung braucht eine klare Rückmeldung und gegebenenfalls einen anderen Lösungsweg. So sinkt die Gefahr, dass abgelehnte Anfragen später informell über einzelne Firmenkarten oder private Konten beschafft werden.
Welche Fehler sind besonders häufig?
Ein typischer Fehler ist ein Antrag, der nur einen Produktnamen enthält. Ohne konkrete Problemdefinition kann niemand die fachliche Eignung beurteilen.
- Fehlende Owner: Niemand verantwortet Nutzer, Rechnungen und Verlängerung. Die Software läuft dann ohne Betreuer weiter.
- Unklare Entscheidungsbefugnis: Mehrere Personen glauben, die Freigabe sei bei einer anderen Rolle. Lege die Vollmacht schriftlich fest.
- Budgetfreigabe als Vertragsprüfung: Manche Teams verwechseln die Budgetzusage mit einer vollständigen Prüfung der Vertragsbedingungen.
- Pilot mit echten Daten: Ein Test mit Kundendaten startet, bevor die notwendigen Kontrollen erfolgt sind.
- Günstig gleich harmlos: Auch ein günstiges Werkzeug kann wegen umfangreicher Zugriffsrechte riskant sein.
- Fehlende Änderungssteuerung: Eine Freigabe für einen kleinen Test deckt nicht automatisch einen späteren unternehmensweiten Einsatz ab.
Definiere außerdem Auslöser für eine erneute Prüfung, zum Beispiel mehr Nutzer, neue Datenkategorien oder eine längere Laufzeit. Miss nicht nur die Geschwindigkeit des Verfahrens, sondern auch die Vollständigkeit der Dokumentation.
Wie führe ich den Prozess praktisch ein?
Führe den Prozess ein, indem du zuerst den Ist-Zustand erfasst und dann ein schlankes Formular mit wenigen Pflichtfeldern entwirfst. Ermittle, wie Software heute bestellt wird und wer Verträge unterschreibt. Sammle typische Rückfragen aus Einkauf, IT und Finanzen.
Ergänze risikobasierte Fragen nur dort, wo sie wirklich benötigt werden. Teste den Ablauf an einem fiktiven Beispiel und an einem realen, noch offenen Antrag. Prüfe, ob alle Beteiligten den nächsten Schritt erkennen, und überarbeite unklare Statuswerte. Benenne für jede Übergabe eine zuständige Person.
Lege anschließend einen zentralen Eingangskanal fest und teile ihn mit, damit Anträge nicht mehr per Chat oder E-Mail an einzelne Personen gehen. Kontrolliere regelmäßig offene Anträge, häufige Rückfragegründe und Fälle ohne Owner.
| Kennzahl | Berechnung | Wozu sie dient |
|---|---|---|
| Durchlaufzeit | Entscheidungstag minus Eingangstag | Lange Bearbeitung erkennen |
| Anteil vollständiger Anträge | Anträge ohne Nachforderung / alle Anträge | Qualität der Antragsfelder prüfen |
| Anteil dokumentierter Freigaben | Käufe mit vollständigem Nachweis / alle Käufe | Nachvollziehbarkeit prüfen |
| Käufe ohne Owner | Anzahl Verträge ohne benannten Owner | Lücken in der Übergabe finden |
Eine längere Prüfung ist nicht automatisch schlecht, wenn sie notwendige Risiken klärt. Problematisch wird es, wenn das Ergebnis einer kurzen Prüfung später niemand mehr nachvollziehen kann.
Welche Checkliste nutze ich direkt vor dem Kauf?
Nutze vor dem Kauf eine kurze Checkliste, die jeden Pflichtpunkt mit einem Nachweis verknüpft. Sie ersetzt keine organisationsspezifische Rechts- oder Sicherheitsprüfung. Jeder offene Pflichtpunkt braucht eine Klärung oder eine dokumentierte Ausnahme durch die zuständige Rolle.
- Bedarf klar beschrieben und Antrags-ID vergeben
- Vorhandene Lösung geprüft und Ergebnis dokumentiert
- Angebot aktuell und Vertragsversion festgehalten
- Budget und Kostenstelle bestätigt
- Daten, Zugriffsrechte und Integrationen erfasst
- Kontrollprüfungen abgeschlossen oder Ausnahme begründet
- Zeichnungsberechtigung der entscheidenden Rolle geklärt
- Betriebsowner benannt und Verlängerungstermin eingetragen
Ein offenes Pflichtfeld bedeutet nicht automatisch Ablehnung. Es bedeutet, dass vor der Bestellung eine weitere Entscheidung oder Information erforderlich ist.
Häufige Fragen zur Software-Einkaufsfreigabe
Reicht eine Budgetzusage als Freigabe aus?
Eine Budgetzusage reicht als Freigabe nicht aus. Sie bestätigt nur die finanzielle Grundlage. Erforderliche Vertrags- und Risikoprüfungen können weiterhin offen sein, und die verbindliche Entscheidung trifft die dafür berechtigte Rolle.
Muss jede Anwendung gleich geprüft werden?
Nicht jede Anwendung braucht dieselbe Prüfung. Die Prüftiefe hängt vom Anwendungsfall, den verarbeiteten Daten, der technischen Tragweite und den internen Regeln ab. Eine bekannte Verlängerung braucht oft weniger Prüfschritte als ein neues Werkzeug mit Zugriff auf personenbezogene Daten.
Kann ich den Ablauf ohne Einkaufssoftware umsetzen?
Ja. Ein vorhandenes Ticketsystem oder eine kontrollierte Tabelle kann genügen, wenn Zuständigkeiten, Versionsstand und Entscheidungen nachvollziehbar bleiben.
Wer darf Software freigeben?
Software darf freigeben, wer dafür eine interne Vollmacht hat. Wer das ist und bis zu welcher Verpflichtung, legen die Zeichnungsregeln des Unternehmens fest. Lege schriftlich fest, wer bis zu welcher Verpflichtung und Risikoklasse entscheiden darf.
Was gehört in einen Freigabenachweis?
Antrags-ID, Anbieter, Angebotsversion, geprüfte Unterlagen, Datum, entscheidende Rolle, Ergebnis sowie gegebenenfalls Auflagen und ein Wiedervorlagetermin.
Wann muss eine Freigabe erneut eingeholt werden?
Eine Freigabe muss erneut eingeholt werden, wenn sich wesentliche Punkte ändern, etwa Nutzerzahl, Datenkategorien, Laufzeit oder Leistungsumfang. Lege diese Auslöser im Prozess fest, damit sie nicht erst bei einer Verlängerung auffallen.
Fazit: Eine Entscheidung, eine Version, ein Owner
Eine gute Software-Einkaufsfreigabe trennt Empfehlung, Prüfung und Entscheidung, richtet die Prüftiefe am Risiko aus und bezieht sich auf genau eine Angebotsversion. Halte Auflagen schriftlich fest, benenne vor der Bestellung einen Owner und trage den Verlängerungstermin sofort ein. So lässt sich auch später erklären, warum eine Software gekauft wurde.