Beschaffung von Regierungssoftware: Ein praxisorientierter Leitfaden für Beamte
Beschaffung von Regierungssoftware: Ein praxisorientierter Leitfaden für Beamte. Verwenden Sie eine RFP nur, wenn Sie Faktoren jenseits des Preises bewerten müssen. In allen anderen Fällen bringt Sie eine RFQ oder ein GSA-Schedule-Vertragsinstrument schneller und mit geringerem Einspruchsrisiko zum Vertrag.
Beschaffung von Regierungssoftware: Ein praxisorientierter Leitfaden für Beamte
Verwenden Sie eine RFP nur, wenn Sie Faktoren jenseits des Preises bewerten müssen. In allen anderen Fällen bringt Sie eine RFQ oder ein GSA-Schedule-Vertragsinstrument schneller und mit geringerem Einspruchsrisiko zum Vertrag. Für jede Softwarebeschaffung im öffentlichen Sektor gelten unabhängig vom Verfahren drei Schutzvorkehrungen: FAR-Konformität, eine dokumentierte Sicherheitslage (Ausrichtung an FedRAMP, FISMA oder NIST SP 800-53) sowie belastbare, vorab festgelegte Bewertungskriterien.
Ihre nächsten Schritte:
-
Führen Sie Marktforschung durch, um vor der Formulierung kundenspezifischer Anforderungen zu bestätigen, ob kommerzielle Lösungen verfügbar sind.
-
Führen Sie eine Prüfung der Sicherheits-Baseline anhand der FISMA-Kategorisierung Ihrer Behörde und der FedRAMP-Autorisierungsanforderungen durch.
-
Beziehen Sie Ihren Beschaffungsbeamten oder ein Team für unterstützte Beschaffungen frühzeitig ein, wenn die Anforderungen komplex oder die Zeitpläne knapp sind.
Inhaltsverzeichnis
-
Welche Vergabeart passt zu Ihrer Beschaffung von Regierungssoftware?
-
Wie sieht der Lebenszyklus einer Softwarebeschaffung tatsächlich aus?
-
Wie formuliert man Anforderungen und erstellt eine belastbare Bewertungsmatrix?
-
SaaS/COTS oder kundenspezifische Entwicklung: Wie entscheiden Sie sich?
-
Welche Sicherheits- und Compliance-Anforderungen gelten für Regierungssoftware?
-
Wie sehen realistische Zeitpläne und die Gesamtbetriebskosten aus?
-
Wie Ridiculous Engineering öffentliche Auftraggeber unterstützt
-
Ridiculous Engineering unterstützt Beschaffungsteams, die einen technischen Partner benötigen
Welche Vergabeart passt zu Ihrer Beschaffung von Regierungssoftware?
Die Wahl zwischen RFI, RFQ und RFP ist die erste Entscheidung, die alle nachfolgenden Schritte prägt. Treffen Sie die falsche Wahl, überkonstruieren Sie entweder eine einfache Beschaffung oder spezifizieren eine komplexe Beschaffung unzureichend.
| Verfahren | Am besten geeignet für | Wann verwenden |
|---|---|---|
| RFI | Nur Marktforschung | Vor Abschluss der Anforderungen; führt zu keiner Vergabe |
| RFQ | Preisorientierter, klar definierter Umfang | COTS/SaaS mit bekannten Spezifikationen, Kleinstbeschaffungen |
| RFP | Bewertung nach mehreren Faktoren | Technischer Ansatz, bisherige Leistungen oder Servicebereitstellung sind entscheidend |
| GSA MAS / OneGov | Vorab ausgehandelte IT-Beschaffungen | Schnellere Vergabe, einheitliche Sicherheitsbedingungen, Mengenpreise |
| Kooperative Beschaffung / Vertragsübernahme | Schnelligkeit, bestehender Vertrag | Leistungsumfang und Preise müssen übereinstimmen; eine sorgfältige Prüfung ist erforderlich |
GSA-Beschaffungsprogramme bündeln gängige IT-Ausgaben über vorab ausgehandelte, compliance-bereite Vertragsvehikel. Für viele Softwarebeschaffungen ist eine Bestellung über einen GSA Multiple Award Schedule (MAS) schneller und risikoärmer als eine eigenständige Ausschreibung.
Die Übernahme des Vertrags einer anderen Behörde kann die Beschaffungsdauer um Wochen verkürzen, erfordert jedoch die Bestätigung, dass der Leistungsumfang des ursprünglichen Vertrags Ihren Anwendungsfall abdeckt, die Preise weiterhin wettbewerbsfähig sind und die Sicherheitszertifizierungen des Anbieters noch gültig sind. Werden diese Prüfungen übersprungen, scheitert die Vertragsübernahme häufig.
Profi-Tipp: Verwenden Sie RFPs nur, wenn Sie nicht preisbezogene Faktoren bewerten müssen. Ein RFP als Standard für jede Softwarebeschaffung verlängert den Prozess um Monate und erhöht das Einspruchsrisiko, ohne die Ergebnisse zu verbessern.
Wie sieht der Lebenszyklus einer Softwarebeschaffung tatsächlich aus?
Jede Phase erzeugt ein spezifisches Artefakt. Wird eine Phase übersprungen, muss sie später meist zu höheren Kosten nachgeholt werden.
| Phase | Zentrales Artefakt | Hauptverantwortlicher |
|---|---|---|
| Anforderungen & Marktforschung | Marktforschungsbericht, Anforderungsdokument | Programm-/technische Leitung |
| Ausschreibung | RFQ, RFP oder Bestellanforderung | Vertragsbeauftragter |
| Bewertung | Bewertete Angebote, Konsensvermerk | Bewertungsgremium + CO |
| Vergabe | Vertrag / Einzelauftrag | Vertragsbeauftragter |
| Implementierung | Abnahmetestplan, Bereitstellungsunterlagen | Technische Leitung + Anbieter |
| Vertragsmanagement | Leistungsberichte, Änderungsprotokoll | CO + Programmstelle |
Die Zeitrahmen variieren erheblich. Eine unkomplizierte SaaS-Bestellung über einen GSA Schedule kann innerhalb weniger Wochen abgeschlossen werden. Ein wettbewerblicher RFP für eine maßgeschneiderte Plattform dauert von der Anforderungsdefinition bis zur Vergabe typischerweise mehrere Monate; je nach Leistungsumfang kommen für die Implementierung weitere Monate hinzu. Die meisten Verzögerungen entstehen bei der Anforderungsdefinition und Bewertung, nicht bei der Ausschreibung.
Der kostspieligste einzelne Fehler bei der Beschaffung von Software im öffentlichen Sektor besteht darin, die Ausschreibung zu starten, bevor die Anforderungen stabil sind. Behörden, die zwei bis vier Wochen in strukturierte Marktforschung investieren, verkürzen ihren gesamten Beschaffungszyklus durchgängig.
Wie formuliert man Anforderungen und erstellt eine belastbare Bewertungsmatrix?
Ergebnisorientierte Anforderungen beschreiben, was das System leisten muss, nicht wie es entwickelt werden muss. „Das System muss monatlich 10.000 Genehmigungsanträge mit einer Verfügbarkeit von 99,5 % verarbeiten“ ist prüfbar. „Das System muss modern und benutzerfreundlich sein“ ist es nicht.
Trennen Sie verbindliche Ausschlusskriterien von bewerteten Elementen. Verbindliche Kriterien schließen nicht konforme Angebote aus, bevor die Bewertung beginnt. Bewertete Elemente unterscheiden zwischen konformen Angeboten.
| Bewertungsfaktor | Gewichtung | Bewertungshinweise |
|---|---|---|
| Technischer Ansatz | — | Methodik, Architektur, Integrationsplan |
| Bisherige Leistungen | — | Referenzen, vergleichbarer Umfang, Aktualität |
| Sicherheitsstatus | — | FedRAMP-Status, NIST-Kontrollen, Reaktion auf Vorfälle |
| Preis / Gesamtkosten | — | Lizenzen, Implementierung, laufende Wartung |
Eine Compliance-Bewertungstabelle die einheitlich auf alle Bieter angewendet wird, verringert das Protestrisiko und erleichtert die Dokumentation der Vergabeentscheidung.
Wichtige Praktiken für prüfungstaugliche Bewertungen:
-
Legen Sie Bewertungskriterien und Gewichtungen in der Ausschreibung fest, bevor Sie Angebote erhalten.
-
Verwenden Sie einen konsensbasierten Bewertungsprozess, bei dem die Einzelbewertungen vor der Diskussion des Gremiums dokumentiert werden.
-
Führen Sie eine Versionskontrolle für alle Änderungen an der Ausschreibung und alle Bewertungsbögen.
Profi-Tipp: Dokumentieren Sie jede Bewertungsentscheidung mit einem Begründungssatz. „Bieter A erhielt 4/5 Punkte für den technischen Ansatz, weil …“ ist der Satz, der eine erfolgreiche Verteidigung gegen einen Protest ermöglicht.
SaaS/COTS vs. kundenspezifische Entwicklung: Wie entscheiden Sie sich?
Die ehrliche Antwort lautet, dass die meisten Behörden standardmäßig auf COTS setzen, wenn eine kundenspezifische Lösung angebracht wäre, und gelegentlich kundenspezifische Entwicklungen in Auftrag geben, obwohl ein kommerzielles Produkt völlig ausgereicht hätte. Die Abwägungen zwischen Open-Source- und proprietärer Software folgen einem ähnlichen Muster.
| Dimension | SaaS / COTS | Kundenspezifische Entwicklung |
|---|---|---|
| Am besten geeignet für | Gängige Arbeitsabläufe, bewährte Anwendungsfälle | Einzigartige Prozesse, Integration in Altsysteme, missionsspezifische Anforderungen |
| Gesamtkosten der Eigentümerschaft | Geringere Anfangskosten; Abonnementkosten summieren sich | Höhere Anfangskosten; bei guter Wartung langfristig niedriger |
| Bereitstellungsdauer | Wochen bis Monate | Monate bis Jahre (ein modularer Ansatz verkürzt diesen Zeitraum) |
| Risiko der Anbieterbindung | Hoch; Datenportabilität muss ausgehandelt werden | Gering, wenn Sie die Rechte am geistigen Eigentum und den Quellcode besitzen |
| Sicherheitslage | FedRAMP-Autorisierung für wichtige Plattformen verfügbar | Muss integriert werden; erfordert die Ausrichtung an NIST SP 800-53 |
| Wartungsmodell | Vom Anbieter verwaltete Aktualisierungen | Von der Behörde oder dem Auftragnehmer verwaltet |
| Flexibilität bei der Lizenzierung | Standard-EULA; eingeschränkte Änderungsrechte | Umfassende Rechte über den Vertrag verhandelbar |
FAR Part 39 empfiehlt modulare Vertragsgestaltung für große IT-Projekte, wobei die Arbeiten in kleinere Abschnitte aufgeteilt werden, um Termin- und technische Risiken zu reduzieren. Diese Empfehlung gilt gleichermaßen für kundenspezifische Entwicklungen und phasenweise COTS-Implementierungen.
Profi-Tipp: Wenn Sie eine kommerzielle Lizenz akzeptieren, prüfen Sie die EULA vor der Unterzeichnung auf Freistellungsklauseln. FAR Part 12 warnt davor, Bedingungen zu akzeptieren, die Verpflichtungen schaffen, die nicht mit dem Bundesrecht vereinbar sind, einschließlich des Anti-Deficiency Act.
Welche Sicherheits- und Compliance-Anforderungen gelten für Regierungssoftware?
Sicherheit ist kein Thema, das erst nach der Auftragsvergabe relevant wird. Sie gehört in die Ausschreibung, die Bewertungskriterien und den Vertrag.
Mindestanforderungen nach Systemtyp:
-
Cloud-SaaS: FedRAMP-Autorisierung auf der Wirkungsstufe, die Ihren Daten entspricht (niedrig, mittel oder hoch). Überprüfen Sie den aktuellen Autorisierungsstatus vor der Auftragsvergabe auf dem FedRAMP Marketplace.
-
On-Premises oder hybrid: FISMA-Compliance-Dokumentation und eine aktuelle Authority to Operate (ATO) oder einen Plan, eine solche zu erhalten.
-
Jegliche Software: Zuordnung zu den relevanten NIST-SP-800-53-Kontrollfamilien, insbesondere Zugriffskontrolle (AC), Reaktion auf Sicherheitsvorfälle (IR) und Konfigurationsmanagement (CM).
Vertraglich vorzuschreibende Klauseln:
-
Datenrechte und Eigentum (die Regierung behält jederzeit die Rechte an ihren Daten).
-
Fristen für Patches und die Reaktion auf Schwachstellen (kritische Patches innerhalb von 30 Tagen sind ein gängiger Standard).
-
Anforderungen zur Meldung von Sicherheitsvorfällen (eine Meldung innerhalb von 72 Stunden ist ein gängiger Schwellenwert).
-
Haftungsbeschränkungsklauseln, die im Hinblick auf das Bundesrecht geprüft wurden.
Die Sicherheitslage ist ein Bewertungsfaktor, keine bloße Checkliste. Ein Anbieter mit einer FedRAMP-Moderate-Autorisierung und einem dokumentierten Plan zur Reaktion auf Sicherheitsvorfälle stellt ein wesentlich geringeres Risiko dar als ein Anbieter mit einer Selbstauskunft und einer vage formulierten Sicherheitsrichtlinie.
Kommerzielle EULAs enthalten häufig Freistellungs- oder Gewährleistungsbedingungen, die mit den Regeln für die Beschaffung durch die Bundesregierung kollidieren. FAR Part 12 weist Vertragsbeauftragte an, kommerzielle Software im Rahmen standardmäßiger öffentlicher Lizenzen zu erwerben, sofern diese Lizenzen mit dem geltenden Recht vereinbar sind, und Bedingungen zu kennzeichnen, bei denen dies nicht der Fall ist. Eine rechtliche Prüfung vor dem Vertragsabschluss ist bei Verträgen mit hohem Wert oder sensiblen Daten keine optionale Maßnahme. Für Zero-Trust- und Sicherheitsanforderungen an Bundesauftragnehmer ist die Messlatte in den letzten Jahren erheblich gestiegen.
Wann sollten Sie unterstützte Beschaffungsdienstleistungen nutzen?
Unterstützte Beschaffung bedeutet, eine externe Vertragsorganisation wie ein GSA Center of Excellence oder die Vertragsabteilung einer anderen Behörde zu beauftragen, die Beschaffung in Ihrem Namen durchzuführen. Ihre Behörde behält die technische Verantwortung und die Befugnis über die Anforderungen; das Team für die unterstützte Beschaffung übernimmt die Ausschreibung, die Unterstützung bei der Bewertung und die Verwaltung der Auftragsvergabe.
Die unterstützten Beschaffungsdienstleistungen der GSA reduzieren den Verwaltungsaufwand und bringen vorab ausgehandelte Beschaffungsinstrumente sowie Compliance-Expertise in komplexe Beschaffungsvorhaben ein. Sie sind besonders nützlich, wenn Ihrer Behörde die Beschaffungskapazitäten fehlen, die Anforderung spezialisierte IT-Expertise umfasst oder ein enger Zeitplan eine vollständig behördeninterne Ausschreibung unpraktikabel macht.
Unterstützte Beschaffung ist kein Weg, die Aufsicht zu umgehen. Sie ist eine Möglichkeit, die Energie Ihres Teams auf das zu lenken, was nur Ihre Behörde leisten kann: Anforderungen definieren, Abnahmekriterien festlegen und die Leistung des Anbieters nach der Auftragsvergabe steuern.
Profi-Tipp: Behalten Sie während jeder unterstützten Beschaffung eine technische Leitung aus Ihrem Programmreferat ein. Das Vertragsteam kümmert sich um den Prozess; Ihr Team trägt die Verantwortung für das Ergebnis.
Checkliste für die Due-Diligence-Prüfung von Anbietern und Warnsignale
Die Due-Diligence-Prüfung erfolgt vor der Auftragsvergabe, nicht erst, nachdem ein Problem aufgetreten ist.
Checkliste:
-
Überprüfen Sie Referenzen zur bisherigen Leistung für Verträge mit vergleichbarem Umfang und ähnlicher Komplexität.
-
Bestätigen Sie, dass der FedRAMP-Autorisierungsstatus oder die FISMA-Dokumentation aktuell ist.
-
Prüfen Sie SOC-2-Typ-II-Berichte von SaaS-Anbietern, die mit sensiblen Daten umgehen.
-
Prüfen Sie Indikatoren für die finanzielle Stabilität (Jahre im Geschäft, Historie staatlicher Verträge).
-
Bestätigen Sie, dass SLAs für Patching und Reaktion auf Vorfälle dokumentiert und durchsetzbar sind.
| Vertragslaufzeit | Mindeststandard |
|---|---|
| SLA-Verfügbarkeit | 99,5 % oder höher für geschäftskritische Systeme |
| Reaktionszeit für kritische Patches | 30 Tage ab Bekanntgabe |
| Datenrückgabe bei Vertragsbeendigung | 30 Tage, maschinenlesbares Format |
| Benachrichtigung über Vorfälle | 72 Stunden ab Entdeckung |
| Abnahmekriterien | Definiert, messbar und an Zahlungsmeilensteine gekoppelt |
Warnsignale: undurchsichtige oder nicht verhandelbare EULA-Bedingungen, Freistellungsklauseln, die eine unbegrenzte Haftung auf die Regierung abwälzen, eine Produkt-Roadmap, die seit über einem Jahr nicht aktualisiert wurde, sowie SLA-Zusagen ohne finanzielle Abhilfe bei Verstößen. Die Nutzung eines bestehenden Vertrags kann schnell gehen, aber diese Prüfungen gelten weiterhin.
Wie sehen realistische Zeitpläne und die Gesamtbetriebskosten aus?
| Beschaffungsart | Vorlaufzeit der Beschaffung | Implementierung | Stabilisierung |
|---|---|---|---|
| SaaS über den GSA-Vertrag | Mehrere Wochen | Einige Monate | Mehrere Wochen bis einige Monate |
| Wettbewerbliche Ausschreibung, COTS | Mehrere Monate | Mehrere Monate | Mehrere Monate |
| Individuelle Entwicklung (modular) | Mehrere Monate | Mehrere Monate bis über ein Jahr | Mehrere Monate |
Verborgene Kostentreiber, die Budgets routinemäßig übersehen: Datenmigration, Integration in Altsysteme, Sicherheitsmaßnahmen vor der ATO, Schulungen für Endbenutzer und laufende Wartung nach Ablauf der ursprünglichen Vertragslaufzeit. Eine Analyse der Gesamtbetriebskosten über drei Jahre, einschließlich Lizenzsteigerungen und Supportkosten, führt fast immer zu einer anderen Rangfolge als ein Preisvergleich für das erste Jahr.
Profi-Tipp: Strukturieren Sie Verträge für kundenspezifische Entwicklungen gemäß FAR Part 39 als modulare Abschnitte. Jeder Abschnitt verfügt über eigene Abnahmekriterien und eine eigene Finanzierungsfreigabe, wodurch das Risiko begrenzt wird, falls sich die Anforderungen während des Projekts ändern.
Wie Ridiculous Engineering öffentliche Auftraggeber unterstützt
Ridiculous Engineering arbeitet mit Organisationen aus dem öffentlichen Sektor in den Phasen Anforderungsdefinition, Umsetzung und langfristiger Support einer Beschaffung zusammen.
Leistungen, die direkt auf Beschaffungsanforderungen abgestimmt sind:
-
Definition von Anforderungen und Erstellung technischer Spezifikationen.
-
Entwurf modularer Architekturen gemäß den Vertragsstrukturen von FAR Part 39.
-
Sichere Entwicklung kundenspezifischer Software mit Ausrichtung an den Kontrollen von NIST SP 800-53.
-
Integration von Altsystemen und API-Entwicklung.
-
DevOps, Einrichtung von CI/CD-Pipelines und Cloud-Architektur.
-
Implementierung, Tests und langfristiger Wartungssupport nach der Auftragsvergabe.
Beschaffungsteams können Ridiculous Engineering über eine Leistungsbeschreibung im Rahmen eines bestehenden Beschaffungsvehikels, als Unterauftragnehmer nach der Auftragsvergabe oder durch eine Kooperation im Rahmen einer unterstützten Beschaffung gemäß den Behördenvorschriften beauftragen. Das Ziel ist immer dasselbe: Ihnen dabei zu helfen, zu definieren, was Sie tatsächlich benötigen, es korrekt zu entwickeln und dauerhaft funktionsfähig zu halten.
Wichtigste Erkenntnisse
Eine effektive Beschaffung von Regierungssoftware erfordert die passende Ausschreibungsart, eine dokumentierte Sicherheitslage und belastbare Bewertungskriterien, die vor Eingang der Angebote festgelegt werden.
| Punkt | Details |
|---|---|
| Ausschreibung an die Komplexität anpassen | Verwenden Sie eine RFQ für preisorientierte Beschaffungen; reservieren Sie die RFP für Bewertungen anhand mehrerer Faktoren, um Zeit zu sparen und das Anfechtungsrisiko zu verringern. |
| Sicherheit ist ein Bewertungskriterium | Fordern Sie in jedem Softwarevertrag eine FedRAMP-Autorisierung, die Ausrichtung an NIST SP 800-53 und durchsetzbare SLAs für die Behebung von Sicherheitslücken. |
| Bewerten Sie, bevor Sie Angebote erhalten | Legen Sie Bewertungskriterien und Gewichtungen in der Ausschreibung verbindlich fest; dokumentieren Sie jede Begründung der Bewertung für die Prüfungsbereitschaft. |
| Verwenden Sie für umfangreiche Entwicklungen modulare Verträge | FAR Part 39 empfiehlt, umfangreiche IT-Arbeiten in Abschnitte zu unterteilen, um Terminrisiken zu begrenzen und die Flexibilität bei der Mittelbereitstellung zu erhalten. |
| Ridiculous Engineering als technischer Partner | Ridiculous Engineering unterstützt öffentliche Auftraggeber von der Anforderungsdefinition über die Umsetzung nach der Auftragsvergabe bis hin zur langfristigen Wartung. |
Ridiculous Engineering unterstützt Beschaffungsteams, die einen technischen Partner benötigen
Beschaffungsbeauftragte der öffentlichen Hand wissen oft genau, welches Ergebnis sie benötigen, und verfügen über zahlreiche Leitlinien für die Prozesse. Was ihnen häufig fehlt, ist ein technischer Partner, der Missionsanforderungen in ein realisierbares, sicheres und wartbares System übersetzen kann und versteht, wie öffentliche Aufträge tatsächlich funktionieren.
Ridiculous Engineering bietet kundenspezifische Softwareentwicklung an, die auf Beschaffungsvehikel zugeschnitten ist – von Beauftragungen auf Grundlage einer Leistungsbeschreibung bis hin zu Lieferverträgen nach der Auftragsvergabe. Das Team deckt Anforderungsdefinition, sichere Architektur, Integration in bestehende Behördensysteme und langfristigen Support ab – ohne den Aufwand eines großen Systemintegrators oder das Risiko eines Anbieters, der nach dem Go-live verschwindet.
Um zu besprechen, wie Ridiculous Engineering Ihre nächste Softwarebeschaffung unterstützen kann, wenden Sie sich direkt über die Seite zu den Dienstleistungen für kundenspezifische Softwareentwicklung an das Unternehmen.
Maßgebliche Quellen und weiterführende Literatur
-
FAR Part 12: Beschaffung kommerzieller Produkte und kommerzieller Dienstleistungen – regelt den Umgang mit kommerziellen Softwarelizenzen und die Anforderungen an die Prüfung von Endbenutzer-Lizenzvereinbarungen.
-
FAR Part 39: Beschaffung von Informationstechnologie – behandelt die Richtlinien für modulare Verträge und Verfahren zur IT-Beschaffung.
-
FAR 15.203: Aufforderungen zur Angebotsabgabe — legt die Struktur von RFPs und die Mindestanforderungen an den Inhalt für wettbewerbliche Beschaffungen fest.
-
GSA-Beschaffungsprogramme — unterstützte Beschaffungsdienstleistungen und vorab ausgehandelte IT-Vertragsmodelle.
-
GSA OneGov — zentralisierter Softwareeinkauf für einheitliche Preise und Sicherheitsbedingungen.
-
FedRAMP Marketplace — maßgebliche Quelle zur Überprüfung des Autorisierungsstatus von Cloud-Produkten.
-
DFARS Unterabschnitt 227.72 — verteidigungsspezifische Regeln für Rechte an Computersoftware und Dokumentation.
-
RFQ vs. RFP bei öffentlichen Ausschreibungen — praxisnahe Analyse, wann welcher Ausschreibungstyp Anwendung findet.
FAQ
Wann sollten Sie statt einer RFQ eine RFP verwenden?
Verwenden Sie eine RFP, wenn neben dem Preis auch Bewertungsfaktoren wie der technische Ansatz, die bisherige Leistung oder das Sicherheitsniveau beurteilt werden müssen. Bei klar definierten Softwarekäufen, bei denen der Preis das wichtigste Unterscheidungsmerkmal ist, ist eine RFQ schneller und birgt ein geringeres Anfechtungsrisiko.
Was ist FedRAMP und warum ist es für die Softwarebeschaffung wichtig?
FedRAMP ist das bundesweite Autorisierungsprogramm für Cloud-Dienste. Die Forderung nach einer FedRAMP-Autorisierung auf der geeigneten Auswirkungsstufe (Niedrig, Mittel oder Hoch) bedeutet, dass die Sicherheitskontrollen des Anbieters unabhängig bewertet wurden, wodurch der ATO-Aufwand und die Risikobelastung Ihrer Behörde reduziert werden.
Was sagt FAR Teil 39 über große IT-Projekte aus?
FAR Teil 39 empfiehlt bei großen IT-Beschaffungen eine modulare Vertragsgestaltung, bei der die Arbeiten in kleinere Abschnitte mit festgelegten Abnahmekriterien aufgeteilt werden. Dadurch wird das Terminrisiko begrenzt und die Finanzierungsflexibilität bleibt erhalten, falls sich die Anforderungen ändern.
Wie reduziert eine unterstützte Beschaffung das Beschaffungsrisiko?
Bei einer unterstützten Beschaffung wird die Vertragsverwaltung an ein spezialisiertes Team, beispielsweise ein GSA-Zentrum, übertragen, während Ihre Behörde die technische Verantwortung und die Zuständigkeit für die Anforderungen behält. Dies ist besonders bei komplexen IT-Beschaffungen, engen Zeitplänen oder begrenzten internen Vertragskapazitäten hilfreich.
Kann Ridiculous Engineering eine staatliche Softwarebeschaffung unterstützen?
Ja. Ridiculous Engineering unterstützt öffentliche Auftraggeber bei der Definition von Anforderungen, der sicheren kundenspezifischen Entwicklung, der Systemintegration und dem Support nach der Auftragsvergabe – strukturiert für die Nutzung standardmäßiger Beschaffungsmodelle einschließlich Leistungsbeschreibungen und Unterauftragsvereinbarungen.