IT-Konzept Ausschreibung schreiben: Technische Lösungen überzeugend präsentieren

Die Spielregeln verstehen: Warum gute Technik allein nicht reicht

Warum scheitern viele technisch exzellente IT-Angebote? Viele Unternehmen tappen in die Falle, ihr Angebot als rein technisches Dokument zu betrachten. Doch laut dem BMWK ist es für die Vergabestelle primär ein Bewertungsgegenstand. Der Bitkom weist darauf hin, dass Vergabestellen strikt an das Vergaberecht gebunden sind und nur das bewerten dürfen, was explizit im Konzept steht. Hier ist der entscheidende Punkt: „Selbstverständlichkeiten“ existieren in der Welt der öffentlichen Vergabe nicht. Wenn Sie nicht schreiben, dass Sie Backups verschlüsseln, tun Sie es für den Prüfer auch nicht.

Was ist die UfAB 2018 in diesem Kontext? Sie ist das zentrale Regelwerk hierfür. Wie der CIO des Bundes erläutert, definiert sie, wie der „L-Wert“ (Leistungswert) ermittelt wird. Ein häufiger Fehler ist die Verwendung von „Weichmachern“. Formulierungen wie „wir können unter anderem...“ oder „beispielsweise Technologien wie...“ sind Gift für Ihre Bewertung. Experten für Vergaberecht warnen, dass solche unbestimmten Begriffe als „nicht wertbar“ eingestuft werden können, da sie keinen verbindlichen Leistungsumfang zusichern. Wie können Sie sicherstellen, dass Ihre Formulierung wertbar ist? Sie müssen verbindlich und präzise formulieren: „Wir setzen Technologie X ein, um Anforderung Y zu erfüllen.“ Eine KI-Lösung wie Bidfix kann dabei helfen, diese Standards einzuhalten.

• Vermeiden Sie: „Wir unterstützen gängige Standards.“
• Schreiben Sie: „Die Lösung unterstützt die Standards REST, SOAP und OData gemäß Spezifikation V2.0.“

Sie fragen sich vielleicht: „Muss ich wirklich jedes Detail ausbuchstabieren?“ Die Antwort ist ein klares Ja. Berichte von Vergabe24 bestätigen, dass Präzision der Schlüssel zum Erfolg ist. Auf Plattformen wie e-Vergabe zeigt sich immer wieder, dass die Gewinner jene sind, die die Anforderungen der Leistungsbeschreibung (Lastenheft) Punkt für Punkt spiegeln und mit einer konkreten Lösungsmethode beantworten.

Lösungsarchitektur überzeugend darstellen: Vom Ist zum Soll

Was ist eine überzeugende Lösungsarchitektur? Sie ist das Herzstück Ihres IT-Konzepts. Hier müssen Sie beweisen, dass Sie die Anforderungen nicht nur verstanden haben, sondern eine tragfähige, zukunftssichere Architektur liefern können. Erfahrene Lösungsarchitekten empfehlen, die Darstellung immer vom Groben ins Detail zu entwickeln, um auch nicht-technische Entscheider abzuholen. Das bedeutet für Sie: Eine bloße Auflistung von Servern und Datenbanken reicht hier nicht aus.

Beginnen Sie immer mit dem Verständnis der Ausgangslage (Ist-Zustand). Best Practices zeigen, dass Anbieter, die die Probleme des Auftraggebers in eigenen Worten präzise zusammenfassen, eine höhere Kompetenzvermutung erzeugen. Hier ist ein wichtiger Schritt: Leiten Sie daraus Ihr Soll-Konzept ab. Wie hilft Visualisierung dabei? Nutzen Sie etablierte Modelle wie das C4-Modell (Context, Containers, Components, Code). Laut Simon Brown, dem Entwickler des C4-Modells, ermöglicht dies, die Architektur auf verschiedenen Abstraktionsebenen verständlich zu visualisieren. Dies hilft den Prüfern, sich in Ihrer Lösung zurechtzufinden.

Was sind die kritischen Unterschiede bei den Anforderungen? Trennen Sie funktionale und nicht-funktionale Anforderungen sauber. Während funktionale Anforderungen beschreiben, was das System tut (z.B. „Nutzer kann Dokument hochladen“), definieren nicht-funktionale Anforderungen, wie es das tut (z.B. Performance, Skalierbarkeit). Der Branchenverband Bitkom betont, dass gerade bei Cloud-Lösungen Themen wie Datenhoheit detailliert beschrieben werden müssen. Auch das BSI rät dazu, Sicherheitsaspekte und Schnittstellenstandards (API-Design) explizit zu machen. Schreiben Sie nicht nur „Wir nutzen eine Cloud-API“, sondern: „Die Schnittstelle wird als RESTful API gemäß OpenAPI 3.0 Spezifikation bereitgestellt, abgesichert durch OAuth 2.0.“

Warum ist die Begründung Ihrer Wahl entscheidend? Begründen Sie Ihre Technologieentscheidung aktiv. Warum setzen Sie auf Kubernetes und nicht auf Docker Swarm? Warum PostgreSQL statt Oracle? Die UfAB-Bewertungsmatrix honoriert es oft, wenn Anbieter Alternativen abgewogen haben. Wenn Sie formulieren: „Aufgrund der Anforderung nach hoher horizontaler Skalierbarkeit bei Lastspitzen (Anforderung ID 4.2) haben wir uns für eine Microservices-Architektur auf Basis von Kubernetes entschieden“, zeigt das, dass Sie mitdenken.

Wie können Sie die Integration in bestehende Systeme sicherstellen? Öffentliche Auftraggeber haben oft komplexe Legacy-Systeme. DResearch weist darauf hin, dass die Beschreibung der „Nahtstellen“ zwischen Alt und Neu oft über den Projekterfolg entscheidet. Beschreiben Sie Migrationspfade und Fallback-Szenarien konkret. Wie gehen Sie mit Datenverlust bei der Migration um? Welche Rollback-Strategien gibt es? Solche Details schaffen Vertrauen in Ihre technische Kompetenz.

Ihre Lösungsarchitektur sollte folgende Elemente enthalten, die sich oft am Standard von arc42 orientieren:

• Kontext-Sicht: Wie fügt sich das System in die Umwelt ein?
• Baustein-Sicht: Welche Komponenten (Datenbanken, Services) werden genutzt?
• Laufzeit-Sicht: Wie fließen Daten durch das System (Sequenzdiagramme)?
• Verteilungs-Sicht: Auf welcher Hardware/Cloud-Infrastruktur läuft was?

Mit dieser Struktur machen Sie es den Prüfern leicht, Ihre Lösung zu verstehen und - noch wichtiger - positiv zu bewerten.

Vorgehensmodell: Agilität im starren Korsett der Ausschreibung

Hier prallen oft Welten aufeinander: Der Auftraggeber fordert Festpreise und feste Termine, wenn Sie eigentlich agil nach Scrum arbeiten wollen. Wie können Sie diesen Widerspruch im IT-Konzept lösen? Experten für Wirtschaftsinformatik raten dazu, ein hybrides Modell zu beschreiben. Öffentliche Auftraggeber in Deutschland orientieren sich oft noch am V-Modell XT. Was ist hier die Herausforderung? Es sieht klare Phasen und Meilensteine vor, die Sie bedienen müssen.

Sie müssen Ihre agile Arbeitsweise in diese „Sprache“ übersetzen. Wie funktioniert diese Integration? Fachautoren wie Torsten Horn empfehlen, Sprints als „Iterationen“ innerhalb der Realisierungsphase zu definieren. Hier ist der Trick: Beschreiben Sie, dass Sie zwar in zweiwöchigen Zyklen arbeiten, aber zu festen Meilensteinen (z. B. „Meilenstein: Abschluss Basisfunktionalität“) prüfbare Ergebnisse liefern. Warum ist das sinnvoll? Das gibt dem Auftraggeber die Sicherheit eines Wasserfallmodells bei gleichzeitiger Flexibilität in der Umsetzung.

Warum ist die Rollenverteilung so wichtig? Definieren Sie klar, was Sie vom Auftraggeber erwarten (z. B. Product-Owner-Rolle). Nach Angaben von CosH Technology führen unklare Mitwirkungspflichten oft zu Projektstörungen. Wenn Sie ins Konzept schreiben: „Für den Erfolg des agilen Vorgehens ist die Verfügbarkeit eines Ansprechpartners auf Auftraggeberseite für ca. 4 Stunden pro Woche für Sprint-Reviews und Plannings erforderlich“, schaffen Sie Klarheit. Was sind die Vorteile? Damit zeigen Sie Professionalität und klären Erwartungen vor Vertragsabschluss.

Sicherheit und Risikomanagement nach BSI-Standards

Was ist ein BSI-konformes Risikomanagement?

Ein BSI-konformes Risikomanagement ist ein methodischer Prozess zur Identifikation, Bewertung und Behandlung von IT-Risiken, der für öffentliche Aufträge essenziell ist. Laut dem Bundesamt für Sicherheit in der Informationstechnik (BSI) müssen Sie dabei Risiken klassifizieren und durch Maßnahmen wie im IT-Grundschutz-Kompendium beschrieben mitigieren, um die Informationssicherheit langfristig zu gewährleisten.

In Zeiten steigender Cyber-Bedrohungen ist das Sicherheitskonzept oft das Zünglein an der Waage. Warum ist dieser Standard so entscheidend? Für öffentliche Auftraggeber in Deutschland ist hier das Bundesamt für Sicherheit in der Informationstechnik (BSI) der Maßstab. Der BSI-Standard 200-3 zum Risikomanagement ist oft explizit gefordert oder zumindest der Goldstandard, an dem Sie gemessen werden. Wenn Sie hier punkten wollen, reicht ein einfaches „Wir arbeiten sicher“ keinesfalls aus.

Ein professionelles Risikomanagement-Kapitel in Ihrem IT-Konzept muss methodisch sauber aufgebaut sein. Wie können Sie Risiken effektiv identifizieren? Beginnen Sie mit der Risikoidentifikation. Spezialisten für BSI-Grundschutz empfehlen, Risiken in Kategorien wie „Organisatorisch“, „Technisch“ und „Menschlich“ zu gliedern. Berichte der Allianz für Cyber-Sicherheit bestätigen, dass Sie nicht nur Serverausfälle auf dem Schirm haben sollten, sondern auch den Ausfall von Schlüsselpersonal (Key-Person-Risk) oder Lieferkettenprobleme.

Der entscheidende Schritt ist die Risikobewertung. Hier ist ein bewährter Ansatz: Nutzen Sie zwingend eine Risikomatrix, die Eintrittswahrscheinlichkeit und Schadenshöhe verknüpft. Das IT-Grundschutz-Kompendium liefert hierfür Vorlagen. Schreiben Sie beispielsweise: „Das Risiko eines Datenverlusts durch Ransomware bewerten wir mit einer Eintrittswahrscheinlichkeit von 'Mittel' und einer Schadenshöhe von 'Hoch'. Daraus ergibt sich ein Gesamtrisiko von 'Hoch', welches durch Maßnahmen M.1 bis M.4 mitigiert wird.“ Diese strukturierte Vorgehensweise signalisiert dem Prüfer: Hier arbeitet ein Profi, der die Behördensprache spricht.

Was sind die geeigneten Maßnahmen zur Risikobehandlung? Beschreiben Sie anschließend Ihre Strategien zur Mitigation. Unterscheiden Sie dabei zwischen präventiven (Verhinderung), detektierenden (Erkennung) und korrigierenden (Behebung) Maßnahmen. Der Forum Verlag rät, hier konkrete SLAs (Service Level Agreements) und Reaktionszeiten zu nennen. Analysen von Gartner zeigen zudem, dass präzise Metriken das Vertrauen erhöhen. Statt „schnelle Hilfe bei Ausfall“ schreiben Sie: „Im Falle eines Prio-1-Vorfalls garantieren wir eine Reaktionszeit von < 30 Minuten und eine Wiederherstellungszeit (RTO) von < 4 Stunden.“

Vergessen Sie nicht den Datenschutz (DSGVO). Ein IT-Sicherheitskonzept ohne Datenschutzbezug ist heute unvollständig. In Schulungen der Bitkom Akademie wird immer wieder betont, dass Auftragsverarbeitungsverträge (AVV) und Technische und Organisatorische Maßnahmen (TOMs) referenziert werden müssen. Sie werden sehen, dass dies oft den Unterschied macht. Integrieren Sie einen Abschnitt „Datenschutz durch Technikgestaltung (Privacy by Design)“, in dem Sie erklären, wie Ihre Software Datenminimierung und Pseudonymisierung technisch umsetzt.

Ein starkes Risikokapitel endet mit dem Prozess der kontinuierlichen Überwachung. Wann sollten Sie Risiken neu bewerten? Risikomanagement ist kein Einmal-Event. Beschreiben Sie, wie Sie während der Projektlaufzeit Risiken neu bewerten. „Wir führen quartalsweise Risiko-Reviews im Lenkungsausschuss durch, um neue Bedrohungen zu identifizieren.“ Dies zeigt dem Auftraggeber, dass Sie auch nach Vertragsunterschrift aktiv an der Sicherheit arbeiten.

• Identifikation: Welche Gefahren drohen konkret?
• Analyse: Wie wahrscheinlich und wie teuer wird es?
• Behandlung: Was tun wir dagegen (vermeiden, reduzieren, verlagern)?
• Überwachung: Wie kontrollieren wir den Erfolg der Maßnahmen?

Mit diesem Vorgehen erfüllen Sie nicht nur die formalen Anforderungen der UfAB, sondern positionieren sich als verlässlicher Partner für kritische Infrastrukturen.

Qualitätssicherung und Visualisierung: Das Auge wertet mit

Ein oft unterschätzter Faktor bei der Bewertung von IT-Konzepten ist die Lesbarkeit. Warum ist dieser Aspekt so entscheidend? Prüfer müssen oft hunderte Seiten lesen - machen Sie es ihnen leicht. Laut Best Practices in der Dokumentation senken Visualisierungen die kognitive Last massiv. Hier ist ein Tipp: Nutzen Sie Diagramme nicht als Deko, sondern als Erklärhilfe. Sie werden sehen, ein Sequenzdiagramm erklärt einen Login-Prozess schneller als zwei Seiten Text.

Was sind die konkreten Erwartungen an die Qualitätssicherung (QS)? Öffentliche Auftraggeber setzen hier hohe Maßstäbe. Berichte von Cosh.de bestätigen, dass Zertifizierungen wie ISO 9001 oft der Mindeststandard sind. Wie gängige Branchenstandards zeigen, ist ein detailliertes Testkonzept unerlässlich: Von Unit-Tests über Integrationstests bis hin zu User Acceptance Tests (UAT). Wenn Sie Tools wie SonarQube für statische Codeanalyse erwähnen, untermauern Sie Ihre Ansprüche an die Code-Qualität effektiv. Ein Satz wie „Wir führen CI/CD-Pipelines mit automatisierten Regressionstests bei jedem Commit ein“ beweist moderne QS-Methodik.

Denken Sie daran: Ihr Konzept ist die erste Arbeitsprobe. Wie wirkt sich das Layout auf die Wahrnehmung aus? Ein schlecht formatiertes, unübersichtliches Dokument lässt oft auf unsauberen Code schließen. Das bedeutet für Sie: Investieren Sie in ein professionelles Layout und Lektorat.