SubmittedText

La Cancelleria federale ha annunciato recentemente che la Confederazione utilizzerà il software della ditta "Livingdocs" quale futuro sistema di gestione del contenuto (Content Management System, CMS). La migrazione di tutti i siti web della Confederazione è prevista nei prossimi anni. Il mandato di gestire e sviluppare il CMS è stato affidato alla Swisscom. Un bando di concorso indetto nel febbraio 2018 è servito come base d'acquisto. Con il nome "Progetto di sourcing NSB" (progetto Simap n. 166946) sono stati messi a concorso tre lotti: 1. Content Delivery Services, 2. mainframe IBM e 3. pacchettizzazione. A quel tempo l'unico offerente era Swisscom, che nel gennaio 2019 si è aggiudicata il lotto 1 per 80 milioni di franchi e il lotto 3 per 65 milioni di franchi. Parallelamente esiste un vasto mercato di soluzioni CMS e di offerenti che hanno le capacità di realizzare con successo simili progetti CMS. Prendere in considerazione un software svizzero va accolto in linea di massima favorevolmente. Tuttavia, sembra che la procedura scelta dall'Amministrazione federale abbia impedito un'autentica concorrenza tra gli offerenti. Ciò premesso chiedo al Consiglio federale di rispondere alle seguenti domande:

1. Come avrebbero potuto capire gli offerenti di soluzioni CMS che il concorso d'appalto del "Progetto di sourcing NSB" nel 2018 avrebbe consentito l'acquisizione del nuovo CMS della Confederazione?

2. Come si garantisce che i futuri concorsi d'appalto siano denominati in modo chiaro per gli offerenti?

3. Come mai nel 2022 la scelta del CMS della Confederazione si basa sul concorso d'appalto del 2018, sebbene questo non fosse chiaramente individuabile come tale?

4. Esiste un processo formale per acquistare strategicamente un prodotto e dichiararlo come tale?

5. Nell'ambito della guida strategica "Software open source nell'Amministrazione federale" sono stati valutati CMS open source affermati, come ad esempio Typo3, Drupal o Wordpress?

6. In che misura l'acquisto di servizi (contrariamente al software) è in conflitto con la guida strategica e che cosa si potrebbe fare al riguardo in caso di conflitto?

7. Chi ha deciso di scegliere il CMS della ditta Livingdocs e in base a quali criteri?

8. Quali altre ditte offrono servizi per il futuro CMS della Confederazione a partire dalle basi stabilite da Livingdocs? Esiste in tal senso una concorrenza che funziona davvero?

9. La Confederazione può far sì che il CMS "Livingdocs" sia pubblicato con una licenza open source?

FederalCouncilResponseText

Ad 1:

Il concorso d'appalto del 2018 si riferiva tra l'altro alla gestione e allo sviluppo del CMS della Confederazione.

Con il concorso d'appalto la Confederazione non cercava un prodotto CMS, bensì un offerente che fosse in grado di fornire "Content Delivery Services" in cui fossero integrati in via opzionale sviluppi tecnologici. Non prescriveva quale software utilizzare per i servizi: il lotto 1 dell'appalto era denominato "Content Delivery Services". Il capitolato d'oneri - che gli offerenti interessati potevano ottenere - precisava che il genere (altri software, strumenti, piattaforme) delle prestazioni da fornire poteva mutare. Le prestazioni sono state dunque correttamente descritte, retrospettivamente emerge tuttavia che la denominazione non era di facile comprensione.

Ad 2:

La denominazione di un concorso d'appalto e dei lotti deve descrivere l'oggetto principale dell'acquisto. La descrizione esatta è contenuta nel capitolato d'oneri e, in caso di ambiguità, i fornitori hanno la possibilità di chiedere chiarimenti. Questa norma è in vigore già oggi e deve essere mantenuta anche in futuro.

Ad 3:

Come già detto nella risposta 1, nel 2018 la Confederazione non ha indetto un concorso per un software, ma per un servizio. Nell'ambito dell'acquisto è perciò possibile cambiare il software o il CMS.

Ad 4:

L'Amministrazione federale (Amm. fed.) dispone di standard relativi a uno o più prodotti per un settore d'impiego definito. Gli standard sono fissati in direttive dal settore TDT della CaF (art. 17 cpv. 1 lett. d ed e OTDI). Se l'Amm. fed. acquista direttamente un prodotto, la standardizzazione di quest'ultimo segue il risultato del concorso pubblico d'appalto. Dato che sempre più spesso sono indetti concorsi per servizi anziché per prodotti, la Cancelleria federale verificherà se occorre adeguare il tipo di standardizzazione.

Ad 5:

L'offerente Swisscom (aggiudicatario) ha proposto strumenti da sottoporre a valutazione sulla base dei requisiti posti dall'Amm. fed. Tra di essi si trovavano, in una fase precoce, anche i tre prodotti menzionati e altri software rilasciati con una licenza open source.

Ad 6:

Il Consiglio federale non vede alcun conflitto con la guida strategica.

Ad 7:

La decisione è stata presa dal delegato "alla trasformazione digitale e alla governance delle TIC" dopo essersi consultato con il Consiglio TDT della Confederazione (secondo art. 17 cpv. 1 lett. d ed e OTDI).

La decisione è stata presa tenendo conto del catalogo dei requisiti, delle esperienze fatte con i progetti pilota e dei test di usabilità effettuati dai responsabili dei siti web interessati. Nelle discussioni condotte nei diversi organi è stata evidenziata anche l'opportunità di una soluzione prettamente svizzera: Livingdocs è una PMI svizzera e Swisscom conserva i dati in centri di calcolo situati in Svizzera conformemente al diritto svizzero.

Ad 8:

In quanto headless CMS, Livingdocs dispone di interfacce documentate pubblicamente (API). Ciò crea una certa indipendenza e consente, se necessario, di far sviluppare e gestire servizi supplementari da altri fornitori.

È anche previsto di lasciar agire il mercato per quanto riguarda la configurazione e la programmazione di quei siti web che non devono conformarsi agli standard della Confederazione.

Ad 9:

Il Consiglio federale vedrebbe di buon occhio che il CMS "Livingdocs" sia pubblicato con una licenza open source. Non ha tuttavia nessun mezzo per obbligare Livingdocs a pubblicare con una licenza open source.