IT-Beschaffung ohne Sackgassen: Wie Exit-Kriterien Projekte von Anfang an besser machen

Viele IT-Projekte starten mit einer langen Wunschliste: neue Notebooks, Cloud-Dienste, Lizenzen, Netzwerktechnik oder ein komplettes System für die digitale Zusammenarbeit. In der Auswahlphase zählen meist Funktionen, Preise und technische Leistungswerte. Eine Frage bleibt dabei oft unbeantwortet: Woran erkennt das Unternehmen später, dass die Beschaffung erfolgreich war und der Anbieter seinen Teil erfüllt hat?

Eine belastbare Antwort entsteht durch klare Exit-Kriterien. Sie legen schon vor der Bestellung fest, welche Bedingungen für Abnahme, Betrieb, Übergabe und einen möglichen Anbieterwechsel gelten. Wer sich früh mit professioneller http:/it-beschaffung.com/ beschäftigt, kann diese Kriterien in Ausschreibungen, Verträge und interne Freigaben einbauen. Das schafft Orientierung, ohne den Einkauf auf den niedrigsten Angebotspreis zu reduzieren.

Der Vertrag endet nicht mit der Lieferung

Eine Lieferung kann vollständig aussehen und trotzdem zu einem problematischen Start führen. Die Geräte stehen im Lager, die Software ist freigeschaltet, der Dienstleister meldet Vollzug. Im Alltag fehlen jedoch möglicherweise Dokumentationen, Administrationsrechte, Schulungen oder Schnittstellen zu vorhandenen Systemen. Solche Lücken fallen oft erst auf, wenn die Fachabteilung produktiv arbeiten soll.

Exit-Kriterien verschieben den Blick vom einzelnen Liefertermin auf den gesamten Übergang in den Betrieb. Eine Beschaffung gilt dann erst als abgeschlossen, wenn das Unternehmen mit dem Ergebnis arbeiten kann und die vereinbarten Nachweise vorliegen. Dazu gehören etwa ein getestetes Berechtigungskonzept, eine aktuelle Systemdokumentation oder ein klarer Prozess für Support und Störungsmeldungen.

Diese Logik hilft auch bei kleineren Vorhaben. Bei zehn neuen Arbeitsplätzen reicht vielleicht eine dokumentierte Einrichtung mit Übergabeprotokoll. Bei einer Plattform für mehrere Standorte braucht es zusätzlich Tests für Verfügbarkeit, Rollen, Datenübernahme und Wiederherstellung. Die Kriterien müssen zum Risiko passen, sollten aber konkret genug sein, damit zwei Parteien dieselbe Leistung darunter verstehen.

Welche Punkte vor der Auswahl geklärt werden sollten

Ein gutes Exit-Kriterium beschreibt ein prüfbares Ergebnis. “Der Dienst läuft stabil” lässt zu viel Spielraum. Besser ist eine Formulierung wie: “Der Dienst verarbeitet die vereinbarten Testfälle, protokolliert Fehler und erreicht im Abnahmetest die festgelegte Verfügbarkeit.” Damit wissen Einkauf, IT, Fachbereich und Anbieter, welche Prüfung ansteht.

• Welche Funktionen müssen am ersten Betriebstag verfügbar sein?
• Welche Daten werden übernommen, in welchem Format und mit welcher Prüfung?
• Wer erhält Administrationsrechte, Zugangsdaten und technische Dokumentationen?
• Welche Reaktionszeiten gelten bei Fehlern während der Einführungsphase?
• Welche Tests muss der Anbieter vor der Abnahme nachweisen?
• Wie kann das Unternehmen Daten und Konfigurationen bei einem späteren Wechsel exportieren?

Die Antworten gehören nicht ausschließlich in die technische Leistungsbeschreibung. Auch die Fachabteilung sollte festlegen, welche Arbeitsabläufe funktionieren müssen. Ein Ticketsystem kann technisch erreichbar sein und dennoch scheitern, wenn die Zuständigkeiten für Genehmigungen falsch abgebildet sind. Ein ERP-Modul kann alle geforderten Felder enthalten, aber wichtige Auswertungen nicht liefern. Fachliche Abnahmetests machen solche Unterschiede sichtbar.

Exit-Kriterien schützen vor unklaren Abnahmen

Ohne definierte Abnahme entsteht schnell eine unangenehme Situation. Der Anbieter verweist auf die bereitgestellte Leistung, während der Kunde auf fehlende Details hinweist. Beide Seiten haben dann andere Vorstellungen davon, was “fertig” bedeutet. Gespräche werden länger, Rechnungen bleiben liegen und interne Teams müssen improvisieren.

Ein Abnahmeplan ordnet diesen Prozess. Er nennt die verantwortlichen Personen, die Testumgebung, die Fristen und den Umgang mit Fehlern. Dabei sollte das Unternehmen zwischen Mängeln mit unterschiedlicher Wirkung unterscheiden. Ein fehlender Bericht kann den Start eines Projekts verhindern, während ein kleiner Darstellungsfehler in einer späteren Wartungsrunde behoben werden kann. Diese Einordnung verhindert, dass jede Abweichung denselben Streit auslöst.

Hilfreich ist ein Protokoll, das pro Prüfschritt vier Angaben festhält: die Anforderung, das erwartete Ergebnis, den Nachweis und den Status. Ein kurzer Praxisfall macht die Methode greifbar. Bei der Einführung einer Geräteverwaltung kann der Test prüfen, ob ein neues Notebook automatisch registriert, mit den richtigen Richtlinien versehen und bei Verlust gesperrt wird. Der Nachweis besteht aus einem Testprotokoll und einem Screenshot der Richtlinie. Damit lässt sich die Abnahme später nachvollziehen.

Der Anbieterwechsel gehört in die Planungsphase

Viele Organisationen beschäftigen sich mit einem Wechsel erst, wenn die Zusammenarbeit bereits schwierig geworden ist. Dann fehlen Exportfunktionen, Zugangsdaten liegen bei einzelnen Personen und die technische Dokumentation ist veraltet. Ein Wechsel wird teuer, obwohl der Vertrag vielleicht eine Kündigung erlaubt.

Ein realistisches Exit-Szenario muss keinen sofortigen Anbieterwechsel vorbereiten. Es soll sichtbar machen, welche Abhängigkeiten entstehen. Bei einem Cloud-Dienst betrifft das etwa Datenexporte, Dateiformate, Identitäten, Schnittstellen und Aufbewahrungsfristen. Bei ausgelagerter Hardware können Seriennummern, Garantieunterlagen, Konfigurationsdateien und Ersatzteilregeln relevant sein. Bei einem Beratungsprojekt geht es oft um Quelltexte, Architekturentscheidungen und Übergabewissen.

Der Vertrag sollte außerdem festlegen, in welchem Zeitraum der Anbieter beim Übergang unterstützt und welche Kosten dafür entstehen. Eine pauschale Klausel zur “angemessenen Mitwirkung” reicht selten aus. Besser sind konkrete Leistungen: Export der Daten, Übergabe einer Dokumentation, Bereitstellung von Zugangsdaten, Beantwortung technischer Fragen und ein definierter Zeitraum für Rückfragen. So kann das Unternehmen die Kosten eines Wechsels einschätzen, bevor die Entscheidung unter Zeitdruck fällt.

Eine kleine Methode für den Beschaffungsalltag

Unternehmen müssen für jedes IT-Vorhaben kein umfangreiches Handbuch erstellen. Ein kurzer Workshop mit Einkauf, IT, Fachbereich und Datenschutz reicht oft als Startpunkt. Die Gruppe beschreibt zunächst den gewünschten Betriebszustand. Danach fragt sie, welche Nachweise diesen Zustand belegen und welche Abhängigkeiten bei einem späteren Übergang entstehen.

Aus den Antworten entsteht eine überschaubare Liste von Kriterien. Jedes Kriterium braucht eine verantwortliche Person und einen Zeitpunkt. Manche Punkte gehören in die Angebotsbewertung, andere in die Abnahme oder in den laufenden Betrieb. Diese Trennung verhindert, dass ein Anbieter mit guten Präsentationsunterlagen automatisch die höchste Bewertung erhält, obwohl wichtige Übergaben ungeklärt bleiben.

Nach der Vergabe lohnt sich ein Abgleich zwischen Vertrag und Projektplan. Anbieter ändern in der Umsetzung gelegentlich technische Details, etwa bei Schnittstellen oder Betriebsmodellen. Solche Änderungen sollten dokumentiert und auf ihre Folgen für die Exit-Kriterien geprüft werden. Ein kurzer Abgleich kostet wenig Zeit. Er kann verhindern, dass das Unternehmen am Ende eine Lösung akzeptiert, deren Rückbau oder Wechsel kaum planbar ist.

Wer IT-Beschaffung über klare Ausstiegspunkte betrachtet, verbessert mehrere Entscheidungen zugleich. Anforderungen werden präziser, Abnahmen werden sachlicher und Anbieterabhängigkeiten werden früher sichtbar. Der Einkauf erhält damit kein zusätzliches Kontrollritual, sondern ein praktisches Werkzeug für verlässliche Ergebnisse. Gute Beschaffung endet dann nicht bei der Bestellung, sondern bei einem Betrieb, den das Unternehmen versteht und eigenständig bewerten kann.