IT-Beschaffung ohne Reibungsverluste: Wie aus Anforderungen tragfähige Entscheidungen werden

Eine neue Software beginnt selten mit einer fertigen Ausschreibung. Meist steht am Anfang ein kleines Problem: Ein Team arbeitet mit Tabellen, ein Fachverfahren ist veraltet oder wichtige Informationen liegen in mehreren Systemen. Aus diesem Anlass entsteht schnell der Wunsch nach einer Lösung. Der schwierigere Teil folgt danach. Die Organisation muss klären, was sie tatsächlich braucht, wer davon betroffen ist und woran sie später erkennt, dass die Investition ihren Zweck erfüllt.

Gerade in Verwaltungen und grösseren Unternehmen hängt die Qualität einer IT-Beschaffung stark von der Vorarbeit ab. Eine gute Orientierung für Themen rund um digitale Beschaffung, IT-Organisation und passende Rahmenbedingungen bietet dv bern. Der Nutzen solcher Quellen liegt vor allem darin, dass sie die technische Sicht mit Fragen zu Prozessen, Verantwortung und Betrieb verbinden.

Das Problem vor dem Produkt beschreiben

Viele Projekte starten mit einem Produktnamen. Jemand kennt eine Plattform, hat von einer bestimmten Cloud-Anwendung gehört oder bringt eine Lösung aus einem früheren Unternehmen mit. Diese Reihenfolge verengt den Blick. Besser ist eine Beschreibung des Problems, die zunächst ohne Hersteller und konkrete Software auskommt.

Dazu gehört die Frage, welcher Arbeitsschritt heute Zeit kostet, Fehler verursacht oder unnötige Abhängigkeiten schafft. Eine Gemeinde kann etwa feststellen, dass Mitarbeitende Anträge aus E-Mails in mehrere Systeme übertragen. Ein Betrieb erkennt vielleicht, dass Freigaben zwar dokumentiert werden, der aktuelle Bearbeitungsstand aber nur über Rückfragen sichtbar ist. Solche Beobachtungen sind wertvoller als die allgemeine Forderung nach einer “modernen Lösung”. Sie zeigen, an welcher Stelle eine Veränderung ansetzen muss.

Auch die betroffenen Personen sollten früh zu Wort kommen. Die Leitung bewertet Kosten und Risiken, die IT prüft Architektur und Betrieb, die Fachabteilung kennt die täglichen Abläufe. Hinzu kommen Datenschutz, Informationssicherheit, Beschaffung und je nach Organisation der Personalbereich. Diese Gruppen verfolgen unterschiedliche Ziele. Ein sauber formulierter Bedarf hält die Unterschiede aus, statt sie vorschnell mit einer Produktentscheidung zu überdecken.

Von Wünschen zu prüfbaren Anforderungen

Eine Anforderung muss so formuliert sein, dass mehrere Anbieter sie nachvollziehbar beantworten können. “Benutzerfreundlich” klingt zunächst sinnvoll, lässt aber viel Raum für Auslegung. Eine prüfbare Formulierung beschreibt eine konkrete Handlung und ein erwartetes Ergebnis. Zum Beispiel kann ein Antrag nach dem Eingang automatisch einer zuständigen Stelle zugewiesen werden, während der Status für berechtigte Personen sichtbar bleibt.

Hilfreich ist die Trennung zwischen Muss-, Soll- und Wunschkriterien. Muss-Kriterien betreffen rechtliche Vorgaben, zwingende Schnittstellen oder den Kernprozess. Soll-Kriterien verbessern den Ablauf, können bei einem passenden Angebot aber unterschiedlich umgesetzt werden. Wünsche dürfen auf der Liste bleiben, sollten die Entscheidung jedoch nicht heimlich dominieren. Eine lange Wunschliste macht die Auswahl nicht automatisch besser. Sie erhöht oft den Prüfaufwand und lenkt von den Bedingungen ab, die für den Betrieb wirklich zählen.

• Beschreiben Sie zuerst den betroffenen Prozess und erst danach mögliche Funktionen.
• Formulieren Sie Anforderungen mit beobachtbaren Ergebnissen statt mit allgemeinen Wertungen.
• Trennen Sie zwingende Kriterien von Verbesserungen und optionalen Erweiterungen.
• Prüfen Sie Schnittstellen, Datenübernahme, Rollen und Berechtigungen bereits in der frühen Phase.
• Definieren Sie, wie Anbieter Antworten, Nachweise und Testzugänge liefern sollen.
• Halten Sie fest, wer eine Anforderung fachlich und wer sie technisch bewertet.

Die unsichtbaren Kosten des Betriebs

Der Kaufpreis steht in vielen Entscheidungsunterlagen an prominenter Stelle. Die späteren Betriebskosten verteilen sich dagegen auf mehrere Positionen. Dazu zählen Lizenzen, Wartung, Speicher, Support, Schulungen, interne Administration und Anpassungen an neue gesetzliche oder technische Vorgaben. Auch die Zeit der Mitarbeitenden gehört in die Betrachtung. Wer Daten manuell bereinigen oder Benutzerkonten einzeln pflegen muss, bezahlt dafür jeden Monat mit Arbeitsstunden.

Eine belastbare Bewertung fragt deshalb, was innerhalb von drei bis fünf Jahren anfällt. Dabei geht es nicht um eine scheinbar exakte Zahl, wenn wichtige Annahmen noch fehlen. Es reicht, die Kostenblöcke offenzulegen und zu markieren, welche Werte vom Nutzungsvolumen, von Vertragsbedingungen oder von der gewählten Betriebsform abhängen.

Besondere Aufmerksamkeit verdient der Ausstieg. Ein System kann fachlich gut passen und trotzdem ein hohes Risiko darstellen, wenn Daten nur schwer exportiert werden können. Vor der Beschaffung sollte feststehen, in welchem Format die Organisation ihre Daten erhält, welche Fristen gelten und wer für die Übertragung verantwortlich ist. Ebenso muss geklärt werden, wie Backups, Löschfristen und Protokolle behandelt werden. Diese Punkte wirken im Projekt oft trocken. Später entscheiden sie darüber, wie beweglich die Organisation bleibt.

Entscheidungen nachvollziehbar dokumentieren

Eine Entscheidung wird nicht allein durch ihre Begründung belastbar. Sie braucht auch einen nachvollziehbaren Weg dorthin. Dazu gehört eine kurze Dokumentation der Ausgangslage, der geprüften Optionen und der Kriterien. Wenn ein Kriterium besonders stark gewichtet wurde, sollte die Begründung sichtbar sein. Das hilft der Leitung bei der Freigabe und erleichtert später die Kommunikation mit betroffenen Teams.

Ein Entscheidungsprotokoll muss kein langer Bericht sein. Eine übersichtliche Tabelle kann genügen, sofern sie die relevanten Annahmen enthält. Wichtig ist, zwischen Fakten, Einschätzungen und offenen Punkten zu unterscheiden. Die Aussage, ein System erfülle eine gesetzliche Vorgabe, braucht einen Nachweis. Die Einschätzung, eine Oberfläche sei leicht verständlich, sollte aus Tests oder konkreten Nutzungsszenarien hervorgehen.

Auch Absagen verdienen eine kurze Begründung. Eine verworfene Option kann später wieder auftauchen, wenn sich Budgets, Schnittstellen oder gesetzliche Anforderungen ändern. Wer den damaligen Grund festhält, spart sich eine erneute Grundsatzdiskussion. Gleichzeitig erkennt das Projektteam schneller, welche Annahmen neu geprüft werden müssen.

Den späteren Alltag schon im Auswahlprozess testen

Präsentationen zeigen häufig den idealen Ablauf. Für eine gute Entscheidung braucht die Organisation jedoch Szenarien aus dem eigenen Alltag. Ein Test kann mit einem echten, anonymisierten Vorgang beginnen: Eine Person erfasst einen Antrag, eine zweite prüft ihn, eine dritte gibt ihn frei. Dabei werden Rechte, Benachrichtigungen, Suchfunktionen und Protokolle sichtbar. Kleine Hürden fallen in solchen Abläufen schneller auf als in einer allgemeinen Produktvorführung.

Am Test sollten Menschen teilnehmen, die später mit dem System arbeiten. Ihre Rückmeldungen sollten sich auf konkrete Aufgaben beziehen. “Das fühlt sich kompliziert an” ist ein brauchbarer Hinweis, wird aber erst durch die Nachfrage verwertbar: An welcher Stelle entsteht die Unsicherheit? Welche Information fehlt? Wie viele Schritte sind nötig? Auf diese Weise lassen sich Beobachtungen in Anforderungen übersetzen.

Nach dem Entscheid endet die Beschaffung nicht. Die Organisation braucht einen klaren Übergang in den Betrieb, feste Verantwortlichkeiten und einen Termin für die erste Prüfung. Nach einigen Monaten lässt sich feststellen, ob der erwartete Prozess tatsächlich einfacher geworden ist, ob Mitarbeitende Unterstützung benötigen und ob weitere Anpassungen sinnvoll sind. So wird aus einer einmaligen Anschaffung ein steuerbarer Teil der digitalen Arbeitsorganisation.