Creare un capitolato d'oneri per il software aziendale nelle PMI svizzere

Cosa offre un capitolato d'oneri per il software aziendale

Un capitolato d'oneri – chiamato nella pratica anche capitolato dei carichi o specifica dei requisiti – definisce ciò che un software deve essere in grado di fare. Costituisce la base per le offerte, per lo sviluppo e per il collaudo. Se manca questo documento, non esiste una definizione comune di quando un progetto si considera «concluso».

I termini non sono sinonimi: il capitolato dei carichi fissa il «cosa» del committente, il capitolato d'oneri il «come» del fornitore. Nei progetti delle PMI, entrambi confluiscono spesso in un unico documento. Questa prassi è fattibile, purché rimanga riconoscibile cosa sia un requisito del committente e cosa una soluzione proposta dal fornitore.

La frase «Me lo immaginavo diversamente.» alla fine di un progetto software ha un costo elevato. Di solito non dipende da uno sviluppo scadente, ma dal fatto che i requisiti non sono mai stati formulati con sufficiente chiarezza. Dato che le PMI rappresentano il 95 percento del panorama economico della Svizzera (kmu.admin.ch), questo rischio riguarda la grande maggioranza dei progetti IT locali.

Cifre rilevanti per le PMI in Svizzera

Definire la situazione iniziale, l'obiettivo e lo stato prima/dopo

Descrivete la situazione attuale: quali processi vengono eseguiti e come, con quali ausili (liste Excel, carta, soluzioni isolate), dove si generano errori, duplicazioni o tempi di attesa? Annotate cosa dovrebbe migliorare concretamente il nuovo software. Un chiaro stato prima/dopo aiuta lo sviluppatore a stabilire le priorità giuste quando budget o scadenze sono sotto pressione.

Se il software elabora dati personali, un inventario dei flussi di dati fa parte della situazione iniziale. La checklist di Swisscom relativa alla Legge sulla protezione dei dati raccomanda un approccio pragmatico: esaminate le applicazioni aziendali esistenti alla ricerca di dati personali e annotate da dove provengono i dati, a quale scopo vengono utilizzati e dove sono archiviati.

Secondo questa checklist, è così possibile ottenere una panoramica con oltre l'80 percento di completezza. Per i lavori puramente interni, la fonte indica un budget temporale di circa un giorno lavorativo, con successivi affinamenti.

Passaggi per la creazione di un capitolato d'oneri per le PMI in Svizzera

Chiarire gruppi di utenti e autorizzazioni

Elencate chi utilizza il software: collaboratori, clienti, partner, amministratori. Per ogni ruolo va definito cosa può vedere, leggere, modificare e cancellare. Un magazziniere vede cose diverse rispetto a un direttore generale. Chi definisce i ruoli in anticipo risparmia lavoro in seguito, poiché i concetti di autorizzazione possono essere modificati successivamente solo intervenendo nella logica esistente.

Da chiarire anche: chi può esportare dati, chi modificare i dati master, chi assegnare i diritti di accesso? Se gli esterni ottengono l'accesso (portale clienti, accesso partner), si aggiungono questioni di autenticazione e di registrazione degli accessi.

Formulare i requisiti funzionali come user story verificabili

Formulate le funzioni come user story: «Come consulente clienti vorrei creare una nuova offerta, inviarla al cliente via e-mail e seguirne lo stato.» Non: «Il sistema dovrebbe avere un modulo per le offerte.» La differenza sta nella verificabilità. Alla fine del progetto, per ogni user story si può rispondere con sì o no se è stata soddisfatta – il consulente clienti può farlo o no?

Per ogni storia, integrate quali dati devono essere inseriti e quale risultato deve essere visibile. Termini generici come «facile da usare» o «flessibile» lasciano aperta questa risposta e non appartengono a un requisito, ma al massimo a un obiettivo di qualità separato.

Integrare requisiti non funzionali e protezione dei dati

I requisiti di prestazione non descrivono una funzione, ma le condizioni: quanto velocemente deve caricarsi una pagina, quanti utenti simultanei devono essere supportati, quali browser e dispositivi sono obbligatori? Queste indicazioni determinano l'architettura e l'impegno per i test.

Se il software elabora dati personali, si applicano le disposizioni della Legge federale sulla protezione dei dati (LPD) rivista, entrata in vigore il 1° settembre 2023. L'Incaricato federale della protezione dei dati e della trasparenza (IFPDT) sottolinea che la LPD è formulata in modo tecnologicamente neutrale e quindi direttamente applicabile alle applicazioni di IA.

Ne derivano tre punti da includere come requisiti nel capitolato d'oneri: trasparenza su scopo, funzionamento e fonti dei dati; un diritto di opposizione degli interessati contro le decisioni individuali automatizzate; una valutazione d'impatto sulla protezione dei dati per le applicazioni ad alto rischio. Se il software viene gestito presso un provider di hosting o cloud o accede a sistemi di terzi, un contratto di trattamento dei dati per conto terzi fa parte dei requisiti.

Se sono previste funzioni di IA, vi appartengono regole per l'output: gli output dell'IA sono suggerimenti, non fatti verificati. Prima del contatto con il cliente, della pubblicazione, dell'efficacia contrattuale o della prenotazione, una persona competente deve controllare correttezza, completezza, tono e fonti. Le decisioni autonome con effetti giuridici o finanziari devono essere escluse come caso d'uso e informazioni sensibili come password, chiavi o dossier completi dei clienti non devono essere inserite in strumenti esterni.

Vantaggi e rischi nell'uso dell'IA nel software aziendale (Svizzera)

Descrivere le interfacce con i sistemi esistenti

Annotate con quali sistemi esistenti il nuovo software deve comunicare – ad esempio Bexio, Abacus, un ERP, uno strumento per newsletter, un web shop o una soluzione settoriale. Per ogni interfaccia va chiarito se esiste un'API documentata o se è necessario uno scambio di file.

Per ogni interfaccia, quattro indicazioni appartengono al capitolato d'oneri: direzione dei dati (lettura, scrittura o entrambi), oggetti e campi dati interessati, ritmo (tempo reale, orario, elaborazione notturna) e gestione degli errori. Nella gestione degli errori va risposto cosa succede se il sistema di destinazione non è raggiungibile, se un record viene rifiutato o se due sistemi modificano contemporaneamente lo stesso record. Senza queste quattro indicazioni, l'impegno sorge in modo non pianificato nel mezzo del progetto.

Delimitazione contro lo scope creep

Annotate altrettanto chiaramente cosa non fa parte del progetto: funzioni che arriveranno solo in una fase di espansione successiva, sistemi che non verranno collegati, migrazioni di dati che il committente svolge da sé, nonché l'ambito della formazione e della documentazione.

Questa delimitazione è il freno più efficace contro le estensioni striscianti. Rende visibile quando emerge un nuovo desiderio e permette di trattarlo come supplemento con proprio impegno e propria scadenza, invece di pagarlo tacitamente dal budget in corso.

Regolare le condizioni quadro tecniche e le questioni di proprietà

Prescrizioni per l'esercizio: il software deve girare su un server specifico o in un'infrastruttura esistente? Ci sono prescrizioni per database, linguaggio di programmazione o standard di interfaccia? Il codice sorgente deve appartenere all'azienda? Chiarite prima della conclusione del contratto cosa succede in caso di cambio di fornitore – esportazione dei dati, documentazione e passaggio del know-how.

Se l'azienda o il prodotto hanno un riferimento all'UE, si aggiungono scadenze regolamentari. Per i sistemi di IA ad alto rischio secondo l'Allegato III dell'EU AI Act valgono prescrizioni rigorose dal 2 dicembre 2027. Dal 11 dicembre 2027 il Cyber Resilience Act si applica completamente.

Anche i fornitori svizzeri possono esserne interessati, anche senza sede nell'UE. Decisivo è se prodotti o servizi sono mirati specificamente al mercato UE – ad esempio tramite un sito web adattato ai clienti UE, possibilità di consegna negli Stati UE o indicazione dei prezzi in euro.

Scadenze regolamentari per IA e cybersicurezza in Svizzera (riferimento UE)

Stabilire il grado di dettaglio e i criteri di accettazione

La regola empirica dice: scrivere in modo così dettagliato che due sviluppatori diversi capirebbero la stessa cosa. Se una frase lascia spazio all'interpretazione, verrà interpretata erroneamente. Verificate quindi ogni requisito con la controdomanda se due persone descriverebbero indipendentemente l'una dall'altra la stessa funzione.

Ne conseguono i criteri di accettazione: per ogni requisito si annota in base a cosa si misura l'adempimento. Nelle user story si tratta della domanda se la persona descritta può eseguire l'azione descritta. Integrate chi effettua il collaudo (settore specialistico, direzione di progetto, direzione aziendale) e in quale ambiente si testa – con dati di test, su un sistema di test e con le interfacce reali.

L'impegno per i dettagli deve corrispondere al rischio: dove vengono elaborati dati di clienti, personale, contratti o finanziari o vengono preparate decisioni automatizzate, servono più controllo, registrazione e documentazione rispetto a una funzione che struttura solo informazioni pubbliche. Il capitolato d'oneri non è un documento finale: i temi della protezione dei dati e della sicurezza vengono affinati ulteriormente, come dimostra l'esperienza, dopo un primo passaggio.