Eine neue Software, ein moderner Arbeitsplatz oder ein sicherer Cloud-Dienst beginnt selten mit der technischen Lösung. Der eigentliche Unterschied entsteht früher: bei der Frage, welches Problem gelöst werden soll, wer davon betroffen ist und wie sich die Entscheidung später im Alltag bewährt. Gerade kleinere Verwaltungen, Verbände und mittelständische Unternehmen stehen dabei unter Druck. Sie müssen Anforderungen sauber formulieren, Budgets einhalten und gleichzeitig Systeme auswählen, die auch in einigen Jahren noch tragfähig sind.
Eine hilfreiche erste Orientierung bietet dv bern. Die Plattform passt zu einer Beschaffungskultur, in der fachliche Anforderungen, wirtschaftliche Kriterien und die praktische Nutzung gemeinsam betrachtet werden. Das ist besonders relevant, wenn mehrere Abteilungen beteiligt sind und technische Details nicht zum Selbstzweck werden sollen.
Das Problem vor dem Produkt beschreiben
Viele Beschaffungsprojekte starten mit einem Produktnamen. Eine Abteilung wünscht sich ein neues Dokumentenmanagement, ein anderes Team sucht eine Projektplattform oder die IT prüft eine zusätzliche Sicherheitslösung. Diese Ausgangslage klingt konkret, lässt aber wichtige Fragen offen. Welche Arbeitsschritte kosten heute Zeit? Wo entstehen Fehler? Welche Informationen müssen Mitarbeitende schnell finden? Welche Vorgaben gelten für Datenschutz, Aufbewahrung und Zugriffsrechte?
Eine belastbare Beschreibung beginnt deshalb mit dem Arbeitsablauf. Wer bearbeitet einen Vorgang? Welche Übergaben finden statt? Welche Ausnahmen treten auf? Erst danach lässt sich entscheiden, welche Funktionen eine Lösung tatsächlich braucht. Ein Unternehmen kann dabei feststellen, dass eine kleine Anpassung an vorhandenen Systemen ausreicht. In einem anderen Fall zeigt die Analyse, dass eine neue Plattform sinnvoll ist, weil mehrere Einzellösungen bereits zu Doppelarbeit führen.
Diese Reihenfolge verändert auch die Kommunikation mit Anbietern. Statt allgemeine Versprechen zu vergleichen, können Verantwortliche konkrete Szenarien vorgeben. Ein Anbieter muss dann zeigen, wie ein Dokument freigegeben, eine Rolle geändert oder ein Bericht erstellt wird. Das macht Angebote besser vergleichbar und reduziert Missverständnisse.
Anforderungen so formulieren, dass sie prüfbar bleiben
Eine gute Anforderung beschreibt eine beobachtbare Eigenschaft. "Das System soll benutzerfreundlich sein" hilft bei der Bewertung kaum weiter. Präziser wäre: "Eine geschulte Person soll einen neuen Vorgang ohne zusätzliche Anleitung anlegen und an die zuständige Stelle weiterleiten können." Auch Begriffe wie "modern", "flexibel" oder "leistungsfähig" brauchen eine konkrete Übersetzung.
Bei der Vorbereitung kann eine einfache Trennung helfen. Muss-Kriterien betreffen Funktionen oder Rahmenbedingungen, ohne die der Einsatz nicht möglich ist. Dazu gehören etwa eine bestimmte Schnittstelle, ein definierter Speicherort oder eine verbindliche Sicherheitsanforderung. Bewertungskriterien erlauben einen Vergleich zwischen mehreren geeigneten Lösungen. Zusatzwünsche erhalten erst dann Gewicht, wenn die Grundanforderungen erfüllt sind.
- Den betroffenen Arbeitsprozess mit realen Beispielen beschreiben
- Pflichtanforderungen von wünschenswerten Funktionen trennen
- Technische, rechtliche und organisatorische Bedingungen gemeinsam prüfen
- Für jede Anforderung eine nachvollziehbare Bewertungsmethode festlegen
- Verantwortliche Personen und Entscheidungsfristen früh benennen
- Ergebnisse aus Tests und Gesprächen schriftlich dokumentieren
Eine solche Struktur verhindert, dass einzelne Funktionen den gesamten Vergleich dominieren. Ein Anbieter kann etwa eine besonders elegante Oberfläche zeigen, während Fragen zur Datenübertragung oder zum Betrieb offenbleiben. Die Bewertung bleibt sachlicher, wenn alle Anbieter dieselben Szenarien und Kriterien erhalten.
Die Menschen im Prozess früh einbeziehen
Technische Projekte scheitern häufig an Abläufen, die auf dem Papier plausibel wirken, im Alltag aber zu viel Aufwand erzeugen. Deshalb sollten Mitarbeitende aus den betroffenen Bereichen früh beteiligt werden. Sie kennen die Sonderfälle, die in einer Anforderungsliste leicht fehlen. Außerdem können sie einschätzen, an welchen Stellen ein zusätzlicher Klick, eine neue Anmeldung oder eine unklare Zuständigkeit Probleme verursacht.
Die Beteiligung muss kein großes Workshop-Programm sein. Kurze Gespräche mit ausgewählten Nutzerinnen und Nutzern reichen oft aus, wenn die Fragen gut vorbereitet sind. Welche Aufgabe erledigen sie am häufigsten? Wo suchen sie Informationen? Welche Schritte umgehen sie heute, weil sie zu umständlich sind? Solche Antworten liefern bessere Hinweise als eine allgemeine Zufriedenheitsabfrage.
Auch die Einführung gehört in die Beschaffung. Ein System kann technisch passen und trotzdem wenig Akzeptanz erhalten, wenn Schulung, Support und interne Zuständigkeiten fehlen. Daher sollten Anbieter erklären, wie sie Migration, Berechtigungen, Schulungen und den laufenden Betrieb begleiten. Die Organisation muss zugleich festlegen, wer nach dem Start Entscheidungen trifft und Fragen beantwortet.
Gesamtkosten statt Anschaffungspreis betrachten
Der Preis im Angebot ist nur ein Teil der wirtschaftlichen Bewertung. Hinzu kommen Einrichtung, Datenmigration, Schulung, Wartung, Schnittstellen, Support und mögliche Kosten für zusätzliche Nutzerinnen und Nutzer. Auch der interne Aufwand verdient Aufmerksamkeit. Wenn Mitarbeitende über Monate Daten bereinigen oder doppelte Prozesse pflegen müssen, wirkt sich das auf den Haushalt aus, obwohl dieser Aufwand nicht auf der Rechnung des Anbieters steht.
Ein einfacher Kostenvergleich sollte deshalb mehrere Jahre abbilden. Dabei können Organisationen unterschiedliche Nutzungsszenarien berechnen: eine stabile Nutzerzahl, ein Wachstum der Abteilung oder eine spätere Erweiterung um weitere Module. Ebenso lohnt ein Blick auf Vertragsbedingungen. Welche Preise gelten nach der Einführungsphase? Wie lässt sich der Leistungsumfang anpassen? In welchem Format erhält die Organisation ihre Daten, wenn sie den Anbieter wechselt?
Die Frage nach einem möglichen Wechsel ist kein Misstrauen gegenüber dem Anbieter. Sie gehört zu einer vernünftigen Vorsorge. Klare Exportmöglichkeiten, dokumentierte Schnittstellen und verständliche Zuständigkeiten senken das Risiko, dass eine Organisation dauerhaft von einer einzelnen Lösung abhängig wird.
Nach der Auswahl beginnt die eigentliche Arbeit
Eine Entscheidung ist erst dann belastbar, wenn die Umsetzung messbar begleitet wird. Dafür reichen wenige, gut gewählte Kriterien. Die Bearbeitungszeit eines Vorgangs kann sich verändern, die Zahl manueller Nacharbeiten kann sinken oder Rückfragen an den Support können nach einer Schulungsphase abnehmen. Solche Werte müssen vor dem Start möglichst klar definiert werden, damit später ein Vergleich möglich ist.
Nach einigen Wochen sollte das Projektteam prüfen, welche Annahmen eingetroffen sind und wo Anpassungen nötig werden. Vielleicht benötigen bestimmte Rollen weitere Rechte. Vielleicht fehlen Vorlagen oder ein Prozessschritt wurde falsch abgebildet. Eine frühe Korrektur ist meist einfacher als eine lange Umgehungslösung, die sich im Alltag festsetzt.
Gute IT-Beschaffung endet daher nicht mit dem Zuschlag und auch nicht mit dem ersten erfolgreichen Login. Sie verbindet eine klare Problemdefinition mit prüfbaren Anforderungen, realistischen Kosten und einer Einführung, die Menschen und Prozesse berücksichtigt. Wer diese Punkte zusammenführt, schafft eine bessere Grundlage für Entscheidungen, die im Betrieb tragen und später weiterentwickelt werden können.
