Acht Tipps für eine erfolgreiche IT-Vergabepraxis Beschaffungsprozesse wie Projekte behandeln

Autor / Redakteur: Darja Solovjova und Bastian Witte / Manfred Klein

Es ist ein oft komplexes Unterfangen, wenn IT-Waren in der Verwaltung beschafft werden müssen – ob es sich nun um IT-Systeme oder -Dienstleistungen, Software oder Hardware handelt. Es ist daher sinnvoll, IT-Beschaffungsprozesse wie Projekte zu behandeln.

Anbieter zum Thema

IT-Beschaffung verliert ihre Schrecken, wenn man Schritt für Schritt vorgeht
IT-Beschaffung verliert ihre Schrecken, wenn man Schritt für Schritt vorgeht
(© Aytunc Oylum – adobe.stock.com)

Die IT-Beschaffung ist komplex, gilt es doch, neben IT-spezifischen Fragestellungen eine ganze Reihe vergaberechtlicher Bestimmungen zu berücksichtigen und umzusetzen. Zudem stehen die Fachbereiche und auch die Vergabestellen unter dem Druck, den identifizierten Bedarf möglichst zeitnah und wirtschaftlich zu decken. Verschärft wird diese Situation noch durch die üblichen Zielkonflikte zwischen Fachbereich und Ver­gabestelle und durch die mannigfachen Stakeholder-Konstellationen, die deren unverzichtbare Zusammenarbeit mit sich bringt. All dies sind Treiber für eine wachsende Komplexität von Beschaffungsprozessen, auch im IT-Umfeld.

Acht Phasen aus der Praxis

Die Erfahrung zeigt, dass es vorteilhaft ist, den Beschaffungsprozess in konsekutive Phasen zu strukturieren. Jede hat andere immanente Herausforderungen, sowohl aus vergabefachlicher als auch aus Projektmanagementperspektive. Dabei ist ein Beschaffungsprojekt einem Hausbau nicht unähnlich. Im Grunde gleicht eine Vergabe – von der Bedarfsfeststellung über die Konstruktion bis zur Umsetzung – einem Architekturprojekt. Und wie beim Hausbau kommt es schon auf die ersten fundierten Schritte an, wenn das Projekt gelingen soll. Die Autoren haben bei IT-Beschaffungsprozessen acht grundlegende Projektphasen identifiziert und geben nachfolgend Tipps, um sie erfolgreich zu gestalten.

1. Beschaffungsstrategie und Bedarfsfeststellung

Am Anfang einer jeden Vergabe steht die Feststellung des Bedarfs. Was soll beschafft werden, worum geht es im Projekt? Um eine Textverarbeitungssoftware – in unserem Bild eine eher simple Holzhütte – oder um eine dezentrale Serverinfrastruktur an mehreren Standorten – also um einen komplexen Hochbau? Der Ursprung des Bedarfs liegt meist in den Fachbereichen der Organisation oder Behörde. Dennoch muss sich die Produkt- und Dienstleisterauswahl immer an der übergreifenden IT-Strategie der Organisationen orientieren.

Eine Verzahnung mit strategiedefinierenden Entscheiderebenen – etwa mit dem CIO – ist darum unverzichtbar. Dazu muss der Projektleiter sicherstellen, dass es einen wechselseitigen Kommunikationsfluss zwischen den Ebenen beziehungsweise Projektinstanzen gibt und dass das Beschaffungsvorhaben als eigenes Projekt und nicht lediglich als die Durchdeklination eines Prozesses verstanden wird. Organisatorisch bedeutet dies, dass die Entscheiderebenen mithilfe eines Projektsteuerungsausschusses oder eines Lenkungskreises und durch geeignete Reporting- oder Abstimmungsformate einbezogen werden müssen.

2. Bedarfsvalidierung

Der anfangs beschriebene Bedarf ist in der Regel noch mit Unsicherheiten behaftet, die es auszuräumen gilt. Konstruktionsfehler des Hauses und alles, was daraus an fehlerhaften Anforderungen und Kriterien für den Bedarf folgen könnte, müssen vermieden werden. Mögliche Risiken bestehen darin, dass der Bedarf der Organisationsstrategie zuwiderläuft, dass zur Bedarfsfeststellung die falschen Stakeholder befragt wurden oder dass es gar keinen Beschaffungsbedarf gibt, weil in der Organisation bereits eine Lösung existiert, die der meldende Fachbereich nicht kennt. Um den Bedarf zu validieren, sollte man ihn gemeinsam mit den Entscheidern unter anderem an der IT-Strategie reflektieren.

Dies kann durch einen regelmäßigen Austausch mit den Strategieverantwortlichen geschehen oder indem die Strategieverantwortlichen in den Projektlenkungsausschuss einbezogen werden. Stellt sich ein Bedarf als invalide heraus, geht es unmittelbar zurück in die Phase 1, zu einer erneuten Bedarfsermittlung, damit keine Haushaltsmittel für eine unnötige Lösung eingesetzt werden. Die beiden Phasen Bedarfsfeststellung und -validierung setzen allerdings voraus, dass die richtigen Stakeholder involviert sind – am besten man ermittelt sie durch eine vorgeschaltete Stakeholderanalyse.

3. Beschaffungsstrategie mit allen Stakeholdern

Neben dem Bedarf ist auch die Vergabestrategie, also das eigentliche Vergabeverfahren, sehr bedeutsam. Die Organisation muss auf fundierte Marktkenntnisse zurückgreifen, um die geeigneten Anbieter herauszufiltern. Es gilt, das Feld der Beschaffungsmöglichkeiten dabei weit zu öffnen und ausgiebig zu erkunden. Hier werden Kernfragen beantwortet wie: Welche Lösungen und Anbieter gibt es, und wie verhindere ich, dass ich eine Lösungsmöglichkeit zur Deckung meines Bedarfs übersehe? Strategische Partnerschaften mit Hochschulen, Markterkundungsverfahren oder die Expertise von Marktteilnehmern tragen zu einer fundierten Marktkenntnis bei.

Auf dieser Basis kann das Verfahren ausgewählt werden, das dem Vergabezweck am besten entspricht – was nicht zwangsläufig eine Ausschreibung ist. Unter Umständen existiert bereits ein (Rahmen-)Vertrag, der den Bedarf decken kann. Zu den Aufgaben in Beschaffungsprojekten gehört es auch, alternative Bezugswege zu identifizieren und diese bei der Wahl der besten Vergabestrategie zu berücksichtigen.

4. Grundgerüst erstellen: Anforderungsdefinition

Ist der Bedarf validiert und die Vergabestrategie bestimmt, folgt die Operationalisierung in Form einer Anforderungsdefinition. Es ist entscheidend, den Lösungs- oder Dienstleistungsbedarf so genau und so effizient wie möglich durch Anforderungen zu umreißen – ohne durch eine zu kleinteilige Definition das Auswahlverfahren von vornherein einzuschränken oder die kreativen Lösungen des Marktes erst gar nicht zuzulassen. Wichtig ist vielmehr, dass die Anforderungsdefinition eine Zielhierarchie abbildet, die mit der IT-Strategie korrespondiert und den technischen Fortschritt berücksichtigt. Anforderungen sind klar zwischen Muss- und Kann-Anforderungen zu trennen und sollten einander nicht widersprechen. Hilfreich ist eine konsistente Methode des Requirement Engineerings beziehungsweise der Anforderungsdefinition. Schließlich werden hier Größe, Form und Ausstattung unseres Hausbaus festgelegt. Aus organisatorischer Sicht hat es sich bewährt, bei der Anforderungsdefinition Fachexperten einzubeziehen. Dies können marktkundige Akteure, aber auch die Nutzer oder zukünftigen Betreiber der Lösung sein.

(ID:45562159)