Document ID: /curiavista/filtered/00000.jsonl.gz/245146

<h2>SubmittedText<h2><text><p>Die Bundeskanzlei hat kürzlich kommuniziert, dass als künftiges Content Management System (CMS) Bund die Software der Firma "Livingdocs" eingesetzt wird. Darauf sollen in den nächsten Jahren sämtliche Bundes-Websites migriert werden. Der Auftrag für Betrieb und Weiterentwicklung des CMS ging an die Swisscom. Als Beschaffungsgrundlage dient eine Ausschreibung vom Februar 2018. Unter dem Namen "Sourcing-Vorhaben NSB" (Simap Projekt-ID 166946) wurden drei Lose ausgeschrieben: 1. Content Delivery Services, 2. IBM-Mainframe und 3. Paketierung. Einzige Anbieterin war damals die Swisscom, die im Januar 2019 für Los 1 den Zuschlag von 80 Millionen Schweizer Franken, und für das Los 3 den Zuschlag in der Höhe von 65 Millionen Schweizer Franken. erhalten hat. Gleichzeitig existiert ein grosser Markt an CMS-Lösungen und -Anbieter, welche die Fähigkeiten haben, solche CMS-Projekte erfolgreich zu realisieren. Die Berücksichtigung einer CH-Software ist grundsätzlich zu begrüssen. Jedoch scheint es, dass das gewählte Verfahren der Bundesverwaltung einen echten Wettbewerb unter den Anbietern verhindert hat. In diesem Zusammenhang bitte ich den Bundesrat um die Beantwortung folgender Fragen:</p><p>1. Wie hätten Anbieter von CMS-Lösungen erkennen können, dass mit der Ausschreibung "Sourcing-Vorhaben NSB" im Jahr 2018 das neue CMS Bund beschafft wird?</p><p>2. Wie wird sichergestellt, dass künftige Ausschreibungen für die Anbieter klar ersichtlich benennt sind?</p><p>3. Wie kommt es, dass sich 2022 die Wahl des CMS Bund auf die Ausschreibung aus dem Jahr 2018 abstützt, obwohl diese nicht als solche klar erkennbar war?</p><p>4. Gibt es einen formellen Prozess, um ein Produkt strategisch zu beschaffen und als solches zu deklarieren?</p><p>5. Wurden im Rahmen des strategischen Leitfadens "Open Source Software in der Bundesverwaltung" etablierte Open Source CMS wie zum Beispiel Typo3, Drupal oder Wordpress evaluiert?</p><p>6. Inwiefern steht die Beschaffung von Services (im Gegensatz zu Software) im Konflikt mit dem strategischen Leitfaden und was könnte im Konfliktfall dagegen unternommen werden?</p><p>7. Wer hat den Entscheid nach welchen Kriterien getroffen, dass das CMS der Firma Livingdocs gewählt wird?</p><p>8. Welche anderen Firmen bieten Dienstleistungen für das künftige CMS Bund auf Basis von "Livingdocs" an? Besteht diesbezüglich ein funktionierender Wettbewerb?</p><p>9. Kann der Bund sich dafür einsetzen, dass das CMS "Livingdocs" unter einer Open Source Lizenz veröffentlicht wird?</p></text><h2>FederalCouncilResponseText<h2><text><p>Zur Frage 1:</p><p>Die Ausschreibung von 2018 bezog sich unter anderem auf Betrieb und Weiterentwicklung des CMS des Bundes.</p><p>Der Bund suchte mit der Ausschreibung kein CMS-Produkt, sondern einen Dienstleister, welcher "Content Delivery Services" anbieten konnte, wobei technologische Weiterentwicklungen optional enthalten waren. Die zu verwendende Software für die Dienstleistungen gab er nicht vor: Los 1 der Ausschreibung lautete "Content Delivery Services". Im Pflichtenheft - das interessierte Anbieter beziehen konnten - ist ausgeführt, dass sich "die Art (andere Software, Werkzeuge, Plattformen) der zu erbringenden Leistungen verändern kann". Die Leistungen waren also korrekt beschrieben, der Titel war rückblickend jedoch nicht selbsterklärend.</p><p>Zur Frage 2:</p><p>Der Titel einer Ausschreibung und der Lose soll den hauptsächlichen Beschaffungsgegenstand beschreiben. Die genauere Beschreibung erfolgt im Pflichtenheft und bei Unklarheiten besteht für die Lieferanten die Möglichkeit nachzufragen. Diese Regelung gilt bereits heute und soll auch künftig Bestand haben.</p><p>Zur Frage 3:</p><p>Wie in Antwort 1 ausgeführt, schrieb der Bund 2018 keine Software, sondern eine Dienstleistung aus. Innerhalb des Beschaffungsrahmens kann die Software bzw. das CMS deshalb gewechselt werden.</p><p>Zur Frage 4:</p><p>Die Bundesverwaltung (Bverw) kennt Ein- und Mehrprodukt-Standards für ein definiertes Einsatzgebiet. Diese Standards werden in Vorgaben durch den Bereich DTI der BK festgelegt (Art. 17 Abs. 1 Bst. d und e VDTI). Wenn die Bundesverwaltung direkt ein Produkt beschafft, folgt die Standardisierung des Produkts dem Resultat der öffentlichen Ausschreibung. Da zunehmend Services anstelle von Produkten ausgeschrieben werden, wird die Bundeskanzlei prüfen, ob die Art der Standardisierung angepasst werden muss.</p><p>Zur Frage 5:</p><p>Der Anbieter Swisscom (Zuschlagsempfänger) hat basierend auf Anforderungen der BVerw Tools zur Evaluation vorgeschlagen. Darunter befanden sich in einer frühen Phase auch die drei genannten Produkte und auch weitere Software, welche unter einer "Open Source Software"-Lizenz laufen.</p><p>Zur Frage 6:</p><p>Der Bundesrat sieht keinen Konflikt mit dem Leitfaden.</p><p>Zur Frage 7:</p><p>Der Entscheid wurde durch den Delegierten "Digitale Transformation und IKT-Lenkung" nach Konsultation des Digitalisierungsrats Bund getroffen (gemäss Art. 17, Abs. 1 Bst. d und e VDTI).</p><p>Der Entscheid wurde unter Berücksichtigung des Anforderungskataloges, den Erfahrungen aus den Pilotprojekten und Tests der Benutzerfreundlichkeit durch betroffene Webseitenverantwortliche getroffen. In den Diskussionen in den verschiedenen Gremien wurde auch die Chance einer rein schweizerischen Lösung hervorgehoben: Livingdocs ist ein schweizerisches KMU und die Daten speichert Swisscom in Rechenzentren in der Schweiz nach Schweizer Recht.</p><p>Zur Frage 8:</p><p>Als headless CMS verfügt Livingdocs über öffentlich dokumentierte Schnittstellen (API). Dies schafft eine gewisse Unabhängigkeit und ermöglicht, zusätzliche Dienste bei Bedarf bei anderen Lieferanten entwickeln und betreiben zu lassen. Auch ist vorgesehen, für Webseiten, welche sich nicht nach den Standardvorgaben des Bundes richten müssen, den Markt für die Gestaltung und Programmierung spielen zu lassen.</p><p>Zur Frage 9:</p><p>Der Bundesrat würde es begrüssen, wenn das CMS "Livingdocs" unter einer Open Source Lizenz veröffentlicht wird. Er hat indessen keine Handhabe, Livingdocs zur Veröffentlichung unter einer Open Source Lizenz zu verpflichten.</p></text>