Viele Digitalprojekte scheitern nicht an der technischen Idee. Sie geraten ins Stocken, weil Geräte, Lizenzen, Cloud-Dienste oder externe Leistungen zu spät, unvollständig oder mit falschen Annahmen beschafft werden. Dann wartet die Entwicklung auf Hardware, der Datenschutz prüft einen bereits unterschriebenen Vertrag und der Einkauf muss unter Zeitdruck eine Lösung finden, die fachlich kaum noch bewertet werden kann.

Wer IT-Beschaffung als Teil der Projektplanung behandelt, erkennt solche Risiken früher. Eine gute erste Orientierung für Anbieter, Ausschreibungen und Beschaffungsfragen bietet it-beschaffung.com/. Der wichtigste Schritt folgt allerdings im eigenen Team: Alle Beteiligten müssen klären, welche Entscheidung wann gebraucht wird und welche Folgen eine falsche Wahl hätte.

Der Einkaufszeitpunkt gehört in den Projektplan

Projektpläne enthalten meist Meilensteine für Konzeption, Entwicklung, Tests und Einführung. Der Einkauf steht dagegen oft in einer separaten Liste. Diese Trennung wirkt harmlos, erzeugt aber Reibung. Ein neues System kann erst getestet werden, wenn Zugänge eingerichtet sind. Arbeitsplätze lassen sich erst ausstatten, wenn die endgültige Zahl der Nutzer feststeht. Ein Dienstleister kann erst starten, wenn Leistungsumfang, Datenschutz und Vergütung schriftlich geregelt sind.

Deshalb sollte das Team rückwärts planen. Für welchen Termin muss die Leistung verfügbar sein? Welche Prüfungen liegen davor? Wie viel Zeit brauchen interne Freigaben, Verhandlungen und die Einrichtung? Bei Hardware kommen Lieferzeiten, Konfiguration und Ersatzgeräte hinzu. Bei Software müssen Verantwortliche Rollen, Datenflüsse, Schnittstellen und Kündigungsbedingungen prüfen.

Ein realistischer Beschaffungstermin berücksichtigt auch Verzögerungen. Ein Anbieter antwortet möglicherweise verspätet. Ein Vertrag enthält offene Punkte. Eine technische Prüfung ergibt, dass eine gewünschte Funktion nur über ein Zusatzmodul verfügbar ist. Wer dafür keinen Puffer vorsieht, macht aus einem kleinen Problem schnell eine Projektblockade.

Die Anforderung muss eine Entscheidung ermöglichen

Unklare Anforderungen führen zu langen Abstimmungen und schwer vergleichbaren Angeboten. “Eine moderne Plattform mit hoher Sicherheit” klingt anspruchsvoll, hilft einem Einkauf aber wenig. Besser sind prüfbare Angaben: Wie viele Personen arbeiten mit dem System? Welche Rollen brauchen sie? Welche Verfügbarkeit wird erwartet? Welche Daten verarbeitet die Lösung? Welche Schnittstellen müssen vorhanden sein? Welche Reaktionszeit gilt bei Störungen?

Das Team sollte zwischen Muss-, Soll- und Wunschkriterien unterscheiden. Muss-Kriterien schließen eine Lösung aus, wenn sie fehlen. Soll-Kriterien beeinflussen die Bewertung, erlauben aber eine Abwägung. Wünsche können später berücksichtigt werden, falls Budget und Zeit es zulassen. Diese Einteilung verhindert, dass eine lange Wunschliste den Blick auf die eigentliche Aufgabe verstellt.

• Beschreiben, welches konkrete Problem die Beschaffung lösen soll.
• Messbare Mindestanforderungen für Leistung, Sicherheit und Verfügbarkeit festlegen.
• Abhängigkeiten zu bestehenden Systemen und Prozessen dokumentieren.
• Verantwortliche für Fachlichkeit, Technik, Datenschutz und Vertrag benennen.
• Bewertungskriterien vor dem Eingang der Angebote gewichten.
• Folgekosten für Betrieb, Support, Schulung und Erweiterungen einplanen.

Der günstigste Einstieg kann teuer werden

Ein niedriger Anschaffungspreis sagt wenig über die Kosten eines IT-Produkts über mehrere Jahre aus. Gebühren für zusätzliche Nutzer, Speicher, Support oder Schnittstellen verändern die Rechnung. Auch interne Aufwände gehören hinein. Mitarbeitende müssen Daten migrieren, Prozesse anpassen und Nutzer schulen. Manchmal braucht eine Abteilung zusätzliche Werkzeuge, weil die gekaufte Lösung eine wichtige Funktion nur eingeschränkt unterstützt.

Für einen fairen Vergleich braucht das Team deshalb ein einheitliches Kostenmodell. Es sollte die Vertragslaufzeit, einmalige Einrichtung, laufende Gebühren, Erweiterungen und mögliche Ausstiegskosten abbilden. Bei Miet- oder Cloud-Modellen kommt die Frage hinzu, wie sich Preise verändern dürfen. Eine automatische Erhöhung kann ein Projektbudget nach zwei Jahren stark belasten.

Auch der Wechselaufwand verdient Aufmerksamkeit. Lassen sich Daten in einem brauchbaren Format exportieren? Gibt es dokumentierte Schnittstellen? Können Administratoren Berechtigungen selbst verwalten? Wenn der Anbieterwechsel praktisch kaum möglich ist, hat das Auswirkungen auf die Verhandlung und auf die langfristige Planung.

Sicherheit und Datenschutz beginnen vor dem Vertrag

Datenschutz wird häufig erst geprüft, wenn die Fachabteilung ihre Wunschlösung ausgewählt hat. Dann sind Erwartungen bereits festgelegt, und Änderungen wirken wie ein Rückschritt. Besser ist eine frühe Prüfung der Datenarten und Zugriffswege. Personenbezogene Daten, Geschäftsgeheimnisse und besonders schützenswerte Informationen brauchen unterschiedliche Kontrollen.

Das Team sollte konkret fragen, wo der Anbieter Daten verarbeitet, wer administrativen Zugriff hat und wie Sicherheitsvorfälle gemeldet werden. Ebenso relevant sind Löschfristen, Backups, Unterauftragnehmer und die Trennung verschiedener Kundenumgebungen. Zertifikate können Hinweise liefern, ersetzen aber keine Prüfung des konkreten Dienstes und des geplanten Einsatzes.

Vertragliche Regelungen müssen zur Nutzung passen. Ein Unternehmen kann hohe Sicherheitsstandards verlangen, aber keine klare Zuständigkeit für Updates, Berechtigungen oder Wiederherstellung festlegen. Dann bleibt im Störungsfall offen, wer handeln muss. Service-Level, Eskalationswege und Nachweise sollten deshalb verständlich beschrieben werden.

Nach dem Zuschlag beginnt die eigentliche Arbeit

Der Zuschlag beendet die Beschaffung, aber nicht das Risiko. Jetzt muss die Organisation die Lösung in den Betrieb überführen. Dazu gehören ein Einführungsplan, klare Ansprechpartner und ein Verfahren für Änderungswünsche. Kleine Abweichungen vom ursprünglichen Umfang sollten dokumentiert werden. Sonst wächst das Projekt still, während Termin und Budget unverändert bleiben.

Ein kurzer Übergabe-Workshop kann viele Missverständnisse vermeiden. Dabei klärt das Team, welche Funktionen zum Start benötigt werden, welche Tests vor dem Go-live stattfinden und wer Fehler priorisiert. Für kritische Systeme braucht es außerdem einen Plan für Ausfälle. Eine manuelle Übergangslösung oder ein Ersatzprozess kann den Betrieb sichern, wenn die neue Anwendung nicht verfügbar ist.

Nach einigen Wochen lohnt sich eine nüchterne Auswertung. Welche Anforderungen erfüllt die Lösung? Wo entstehen unerwartete Kosten? Welche Aufgaben bleiben beim Anbieter, welche beim eigenen Team? Diese Ergebnisse helfen bei Verlängerungen, Erweiterungen und der nächsten Beschaffung. So wird aus einem einmaligen Einkauf ein belastbarer Lernprozess, der künftige Projekte besser planbar macht.