Costi totali di gestione del software di governance: valutare l'onere delle modifiche e la sicurezza degli aggiornamenti

Nella scelta di un software di governance, il costo della licenza, l’implementazione e la gestione costituiscono la base del confronto economico. Per una valutazione su un arco di diversi anni, occorre inoltre tenere conto dei costi derivanti da modifiche tecniche, organizzative e normative. A tal proposito, è determinante la misura in cui la piattaforma è configurabile e se le personalizzazioni specifiche del cliente vengono mantenute in occasione degli aggiornamenti del prodotto.

Nuovi campi obbligatori, ruoli, autorizzazioni o report fanno parte dell’evoluzione di un’organizzazione di governance. Se tali requisiti devono essere programmati regolarmente dal produttore, oltre ai costi di sviluppo esterni si generano anche oneri interni legati al coordinamento, all’assegnazione degli incarichi, ai test e all’implementazione. Un prezzo di licenza contenuto può quindi comportare costi operativi complessivi più elevati.

Tenere conto delle modifiche che si verificano durante il periodo di utilizzo

Le offerte software indicano innanzitutto i costi immediatamente riconoscibili: licenza annuale, implementazione, hosting, assistenza e, se del caso, formazione e migrazione. Queste voci sono relativamente facili da mettere a confronto, ma rappresentano solo una parte delle implicazioni economiche di una scelta di piattaforma che si protrae per diversi anni.

Nel corso del ciclo di vita del sistema, l’organizzazione e le sue esigenze subiscono dei cambiamenti. Vengono integrate nuove società, le competenze vengono adeguate e si rende necessario l’utilizzo di ulteriori lingue. Allo stesso tempo, i requisiti normativi, gli audit interni o le richieste del management possono rendere necessarie modifiche ai modelli di dati, ai processi e alle analisi.

Nel Protezione dei dati Ciò riguarda, ad esempio, la struttura del registro delle attività di trattamento, una logica di rischio adeguata o processi di revisione a livello di gruppo con varianti locali. A ciò possono aggiungersi ulteriori autorizzazioni in caso di coinvolgimento di fornitori di servizi, nuovi indicatori, processi per la governance dell’IA, requisiti derivanti dalla gestione della sicurezza delle informazioni o documentazione integrativa per gli audit interni.

Tali adeguamenti devono essere considerati, ai fini della valutazione economica, come parte integrante dell'attività operativa corrente. Le aziende dovrebbero quindi verificare, già prima della scelta, quali modifiche possano essere apportate dai propri amministratori e quali richiedano invece un intervento di sviluppo da parte del fornitore.

Quali costi vanno inclusi in un'analisi del TCO

Il Total Cost of Ownership (TCO) indica i costi complessivi nell’arco della vita utile. Nel caso dei software di governance, questa analisi comprende l’implementazione, la gestione operativa e il successivo sviluppo. Ai fini di un confronto strutturato, è possibile distinguere cinque categorie di costo:

La classificazione serve a rendere comparabili le strutture dei costi delle offerte. Un fornitore può sembrare più conveniente al momento della stipula del contratto, mentre nel corso degli anni potrebbero aggiungersi costi considerevoli legati alle modifiche. Al contrario, una licenza più costosa può essere economicamente giustificabile se i costi di gestione e di adeguamento risultano di conseguenza inferiori.

A tal proposito, occorre considerare congiuntamente le prestazioni esterne del fornitore e i costi interni dell’azienda. Una valutazione che tenga conto esclusivamente dei prezzi di offerta indicati tralascia una parte significativa dei costi successivi.

Costi esterni e interni relativi alle richieste di modifica

Una richiesta tecnica inizialmente limitata può comportare una serie di modifiche correlate. Se, ad esempio, è necessario un nuovo campo, potrebbe essere necessario stabilire contemporaneamente per quali società esso sia obbligatorio. Una determinata risposta deve attivare una verifica; in caso di rischio elevato, occorre coinvolgere il responsabile della protezione dei dati e la direzione necessita di un'analisi filtrabile per paese e per unità aziendale. Per una società francese potrebbe inoltre essere necessaria una versione linguistica.

Nella misura in cui tali requisiti siano realizzabili solo tramite uno sviluppo personalizzato, al coordinamento tecnico seguono di norma la definizione delle specifiche, l’offerta, l’assegnazione dell’incarico, lo sviluppo, il collaudo, la pianificazione del rilascio, la messa a disposizione e Documentazione. Questi passaggi comportano un certo impegno, anche se la modifica tecnica in sé sembra di facile gestione.

All’interno dell’azienda, a seconda dei casi, possono essere coinvolti diversi reparti. I reparti specializzati descrivono le esigenze, la protezione dei dati o Conformità definiscono i requisiti, il reparto IT ne valuta le implicazioni, il reparto acquisti affida l'incarico e la direzione del progetto coordina l'attuazione. Successivamente, gli utenti devono testare e il Documentazione devono essere adattati.

I costi di sviluppo devono essere considerati come una componente regolare dei costi. Ai fini della redditività, tuttavia, è rilevante la frequenza con cui sono necessari per l'aggiornamento tecnico continuo. Se ogni modifica viene implementata in questo modo, anche costi unitari moderati possono accumularsi in misura considerevole nel corso della vita utile.

La configurabilità come criterio di valutazione economica

Il "no-code" può consentire di apportare modifiche funzionali senza ricorrere alla programmazione personalizzata. Nel caso dei sistemi di governance, ciò riguarda in particolare l'adeguamento di campi dati, ruoli, moduli, questionari, flussi di lavoro e analisi. Il vantaggio economico dipende da quali di questi elementi siano effettivamente configurabili e dallo sforzo richiesto a tal fine.

Se un amministratore adeguatamente qualificato è in grado di implementare una richiesta nel giro di poche ore, ne deriva una struttura dei costi e dei tempi diversa rispetto a quella di un progetto di sviluppo della durata di diverse settimane. Ciò può ridurre i costi di sviluppo esterni, i tempi di attesa e gli oneri interni legati al progetto. Allo stesso tempo, l’organizzazione può diventare più indipendente dal produttore nell’ulteriore sviluppo dei propri processi.

L’indicazione generica secondo cui un software è „personalizzabile“ non è quindi sufficiente ai fini della valutazione. Essa può riferirsi sia a uno sviluppo a pagamento da parte del produttore sia a una configurazione che può essere effettuata autonomamente. Nel processo di selezione occorre chiarire chi può modificare quali elementi, quali conoscenze sono necessarie a tal fine e in che modo le modifiche influiranno sugli aggiornamenti futuri.

Per una piattaforma di governance aziendale, è necessario valutare in particolare le seguenti opzioni di configurazione:

• Campi e logica dei campi obbligatori: Integrazione di informazioni e dati obbligatori subordinati a determinate condizioni, a seconda del rischio, del ruolo, della società, dello stato del processo o di altri dati.
• Ruoli e autorizzazioni: Adeguamento delle responsabilità e dei diritti di visualizzazione alla rispettiva organizzazione.
• Flussi di lavoro e approvazioni: Modifica delle procedure di verifica, revisione e approvazione, comprese ulteriori fasi di autorizzazione.
• Scadenze e procedure di escalation: Configurazione di promemoria, scadenze e procedure di escalation.
• Moduli e questionari: Ulteriore sviluppo delle query tecniche senza il rilascio di una versione separata del prodotto.
• Rapporti: Adattamento delle analisi e delle dimensioni di analisi aggiuntive.
• Organizzazione e multilinguismo: Integrazione di ulteriori società, sedi, team e unità aziendali, nonché di ulteriori versioni linguistiche.
• Adeguamenti normativi: Modifica dei processi di governance interessati qualora si debba tenere conto di nuovi requisiti.

Queste possibilità devono essere valutate alla luce delle esigenze concrete dell'azienda. Ai fini della redditività, è determinante in che misura tali soluzioni consentano di far fronte ai cambiamenti prevedibili nel corso dell'attività operativa.

Sicurezza degli aggiornamenti e conservazione delle configurazioni personalizzate

La configurabilità ha un’utilità economica limitata se, a seguito di un aggiornamento del prodotto, le personalizzazioni specifiche per il cliente devono essere ricreate o completamente rielaborate. Oltre alle possibilità di modifica, occorre quindi verificare come si comportano tali personalizzazioni nelle versioni successive.

Una chiara distinzione tra lo standard del prodotto e la configurazione specifica del cliente dovrebbe consentire di continuare a sviluppare lo standard e di mantenere le configurazioni esistenti. Dovrebbe essere possibile utilizzare le nuove funzionalità del prodotto senza dover ricreare ogni volta i processi già configurati.

Se questa separazione viene a mancare, possono insorgere costi aggiuntivi. Dopo un aggiornamento, occorre quindi chiarire quali modifiche continuano a funzionare, quali sono state sovrascritte e quali devono essere sviluppate ex novo. Nel peggiore dei casi, le modifiche specifiche per il cliente possono complicare o impedire l’aggiornamento. L’personalizzazione può quindi dar luogo a dipendenze tecniche e a costi ricorrenti.

Le aziende dovrebbero quindi chiedere in modo specifico quali configurazioni rimarranno invariate, quali test di regressione sono necessari e se determinate modifiche potrebbero bloccare le versioni future. In questo contesto, la sicurezza degli aggiornamenti è un criterio fondamentale per preservare gli investimenti già effettuati.

Esempio semplificato dei costi su un periodo di cinque anni

L'importanza degli adeguamenti successivi può essere illustrata con un esempio di calcolo semplificato. Gli importi riportati di seguito sono ipotetici:

Su questa base, il vantaggio in termini di costi del fornitore A ammonta inizialmente a 170.000 euro. Ai fini dell’ulteriore analisi, si ipotizza che il fornitore A debba sostenere i seguenti costi esterni di adeguamento in ciascuno dei quattro anni di esercizio successivi all’anno di introduzione:

• Quattro richieste di modifica di importo modesto, ciascuna pari a 8.000 euro: per un totale di 32.000 euro.
• Una modifica significativa al flusso di lavoro: 25.000 euro.
• Modifiche ai report: 10.000 euro.

I costi esterni legati alle modifiche ammontano quindi a 67.000 euro all’anno e a 268.000 euro in quattro anni. Sommando la licenza e l’implementazione, il costo per il fornitore A risulta pari a 698.000 euro. Tali cifre non includono ancora i costi interni, ad esempio per ulteriori test di rilascio e attività di coordinamento.

Nel caso del fornitore B, occorre considerare innanzitutto un costo di 600.000 euro per la licenza e l’implementazione. A ciò vanno aggiunti i costi delle configurazioni necessarie e gli oneri interni. Se le stesse modifiche possono essere configurate con uno sforzo sufficientemente contenuto, il vantaggio iniziale in termini di costi del fornitore A potrebbe ribaltarsi.

L'esempio non rappresenta un calcolo completo del TCO, ma illustra chiaramente perché, per effettuare un confronto attendibile, siano necessarie anche ipotesi relative alla frequenza e all'impegno richiesto dalle modifiche successive. Dalla sola configurabilità non è ancora possibile dedurre un risparmio sui costi specifico.

Requisiti relativi alla valutazione economica nella richiesta di offerta (RFP)

Nel caso di una scelta di piattaforma pluriennale, è possibile anticipare solo in misura limitata le esigenze future. Nella richiesta di offerta (RFP) si dovrebbe quindi considerare, oltre alla rappresentazione dei processi esistenti, anche la loro successiva modifica. Le risposte devono indicare chiaramente quali prestazioni sono incluse nella versione standard e in quali casi sorgono costi aggiuntivi.

Ai fini della valutazione, si prendono in considerazione in particolare le seguenti domande:

Configurazione

Quali campi possono essere modificati direttamente dagli amministratori? È possibile modificare campi obbligatori, logiche condizionali, flussi di lavoro, fasi di approvazione, promemoria ed escalation senza ricorrere alla programmazione?

Ruoli e diritti

È possibile creare ruoli personalizzati e adattare le autorizzazioni in base all'oggetto, allo stato o all'organizzazione?

Reportistica

Quali report e dashboard può configurare autonomamente il cliente? Per quali modifiche è necessario l'intervento del produttore?

Organizzazione

Come vengono aggiunte nuove società, team, sedi e unità aziendali? Quali costi aggiuntivi di implementazione ne derivano?

Aggiornamenti

Quali configurazioni personalizzate vengono mantenute in caso di aggiornamenti del prodotto? Quali test di regressione sono necessari? Le personalizzazioni possono bloccare una versione futura?

Richieste di modifica

Quali modifiche sono incluse nella configurazione standard e quali vengono fatturate separatamente? Come avviene la fatturazione e quali sono i tempi medi di consegna previsti?

Amministrazione

Quali configurazioni può eseguire autonomamente il cliente? Quali competenze devono possedere gli amministratori e in quali casi sono necessarie conoscenze di programmazione?

Queste questioni devono essere prese in considerazione nella valutazione economica prima della stipula del contratto. Riguardano i costi correnti, la durata degli adeguamenti successivi e la dipendenza dal fornitore.

Roadmap del prodotto e ulteriore sviluppo dello standard

Anche la strategia di prodotto può influire sui costi totali di gestione. Se i requisiti tecnici vengono ulteriormente sviluppati nel prodotto standard, ciò può ridurre la necessità di progetti personalizzati. Se, invece, le estensioni vengono realizzate prevalentemente su misura, il cliente in questione si fa carico in larga misura dei relativi costi di sviluppo.

Nel processo di selezione occorre quindi chiarire quali funzioni debbano essere incluse nello standard, con quale frequenza vengano rilasciate le nuove versioni e in che modo vengano prese in considerazione le modifiche normative. È inoltre importante stabilire quali estensioni vadano a vantaggio di tutti i clienti e in che modo il fornitore distingua tra lo sviluppo generale del prodotto e i servizi personalizzati.

La roadmap va quindi considerata come parte integrante dell'analisi dei costi, poiché fornisce indicazioni sulla misura in cui l'ulteriore sviluppo del prodotto possa rendere superflui successivi adeguamenti individuali.

Gestione controllata e requisiti temporali

La possibilità di configurare autonomamente i sistemi presuppone una chiara definizione delle competenze. Non tutti gli utenti dovrebbero poter modificare i flussi di lavoro, i campi obbligatori o le autorizzazioni, poiché una configurazione errata può compromettere le procedure di verifica e approvazione previste.

Le aziende dovrebbero quindi stabilire chi è autorizzato ad apportare modifiche e chi è incaricato di verificarle. Nella valutazione della piattaforma occorre inoltre chiarire se le modifiche alla configurazione vengono sottoposte a controllo di versione, quali possibilità di test sono disponibili e se è possibile ripristinare una configurazione precedente. Il «no-code» cambia le modalità di implementazione; la necessità di un’amministrazione controllata rimane tuttavia immutata.

Inoltre, occorre tenere conto della durata dell’implementazione come fattore economico. Se una modifica di processo imposta dalla normativa deve essere attuata in tempi brevi, l’avvio preventivo di un progetto di produzione può causare ritardi. Dipendenze simili possono verificarsi in caso di cambiamenti organizzativi interni o di requisiti aggiuntivi derivanti da audit.

Le conseguenze economiche di un ritardo possono andare oltre il costo della richiesta di modifica. La flessibilità deve quindi essere valutata anche alla luce della possibilità di apportare gli adeguamenti necessari entro i termini previsti.

Requisiti per una piattaforma come Ailance

I criteri descritti devono essere applicati anche a una piattaforma come Ailance. I processi di governance sono costituiti da oggetti, campi, ruoli, flussi di lavoro, decisioni, attività, revisioni, report e dalle relazioni tra questi elementi. Nella misura in cui questi componenti possono essere configurati in modo controllato, è possibile limitare la necessità di progetti di sviluppo individuali per le modifiche funzionali.

L'obiettivo è realizzare un prodotto standard con opzioni di configurazione che rimangano invariate anche in occasione di aggiornamenti successivi. Le nuove esigenze devono poter essere implementate sulla piattaforma esistente senza ostacolarne l'ulteriore sviluppo. Nel caso di implementazioni aziendali a lungo termine, occorre prestare particolare attenzione a questo equilibrio tra standard, personalizzazione e sicurezza degli aggiornamenti.

Esame pratico nell'ambito della procedura di selezione

La valutazione dovrebbe riunire i punti di vista del reparto specialistico, dell’ufficio acquisti, dell’IT e della direzione aziendale. Mentre il reparto specialistico valuta la rappresentazione dei propri processi, l’ufficio acquisti esamina i prezzi e l’IT valuta il funzionamento e l’integrazione. Per i responsabili finanziari sono rilevanti i costi complessivi su un arco di diversi anni; dal punto di vista della direzione IT occorre inoltre valutare la futura dipendenza dal fornitore.

Per concretizzare il concetto, è possibile fare riferimento a cinque requisiti derivanti dall’attività operativa corrente:

1. Viene aggiunto un nuovo campo obbligatorio.
2. Una determinata risposta fa scattare un controllo aggiuntivo.
3. Un’altra persona autorizzata all’approvazione viene inserita in un flusso di lavoro.
4. La direzione ha bisogno di un nuovo report.
5. Una società controllata necessita di una variante locale di un processo.

Per ogni requisito occorre chiarire se l’azienda sia in grado di attuarlo autonomamente, quanto tempo richiederà la modifica, quali costi comporterà e se sia necessario un progetto di produzione. Inoltre, occorre verificare come si comporterà la configurazione modificata in occasione del prossimo aggiornamento del prodotto.

Questa analisi rende più concrete le conseguenze economiche delle opzioni di adeguamento proposte e integra il confronto tra le funzioni esistenti con i costi relativi al loro successivo sviluppo.

Criteri di valutazione per la decisione di acquisto

Un prezzo di partenza contenuto può andare di pari passo con costi operativi complessivi contenuti, purché la piattaforma sia sufficientemente configurabile e la gestione quotidiana richieda uno sforzo minimo. Allo stesso modo, una licenza più costosa può essere giustificata dal punto di vista economico da costi di modifica inferiori. Un prezzo più elevato non garantisce di per sé una maggiore redditività.

Ai fini della decisione di acquisto sono quindi determinanti la struttura dei costi nell’arco della vita utile, i cambiamenti prevedibili e le dipendenze ad essi correlate. La configurabilità, la sicurezza degli aggiornamenti e la roadmap del prodotto rientrano in questa valutazione, poiché influenzano lo sforzo che l’azienda dovrà compiere in seguito per sviluppare ulteriormente i propri processi di governance.

Domande e risposte

Come si valutano i costi totali di gestione di un software di governance?

Occorre tenere conto dei costi relativi alla licenza, all’implementazione e alla gestione, nonché dei costi per modifiche, aggiornamenti ed espansioni organizzative. I servizi esterni e gli oneri interni dovrebbero essere considerati nello stesso periodo di riferimento.

Perché il prezzo della licenza non è sufficiente per un confronto tra software?

Dopo l'implementazione potrebbero sorgere costi aggiuntivi per adeguamenti tecnici, test e gestione amministrativa. Modifiche frequenti possono alterare in modo significativo il confronto dei prezzi iniziale nel corso di diversi anni.

Quali costi ricorrenti possono derivare dall'utilizzo di software di governance?

Tra queste figurano le richieste di modifica, lo sviluppo personalizzato per il cliente, i test di regressione dopo gli aggiornamenti, i report aggiuntivi, le modifiche al flusso di lavoro, i nuovi ruoli, ulteriori versioni linguistiche e gli adeguamenti richiesti dalla normativa.

In quali circostanze il no-code può ridurre il TCO?

Se le modifiche necessarie possono essere configurate senza ricorrere allo sviluppo personalizzato di software, è possibile contenere i costi di sviluppo esterni e l'impegno interno dedicato al progetto. Occorre comunque tenere conto dell'effettivo impegno richiesto dalla configurazione.

Perché la sicurezza degli aggiornamenti è rilevante dal punto di vista economico?

Se le configurazioni personalizzate vengono mantenute negli aggiornamenti del prodotto, non è necessario ricreare i processi già configurati ad ogni nuova versione. È inoltre necessario verificare quali test e adeguamenti siano ancora necessari.

Quali modifiche dovrebbero essere possibili senza un progetto di sviluppo?

In particolare, vengono presi in considerazione campi, logiche dei campi obbligatori, ruoli, flussi di lavoro, approvazioni, promemoria, escalation e questionari, nonché il maggior numero possibile di personalizzazioni dei report. L'entità richiesta dipende dai processi aziendali.

Quali domande relative alle richieste di modifica devono essere incluse in una RFP?

Occorre chiarire la differenza rispetto alla configurazione standard, i servizi che il produttore dovrà fornire, le modalità di fatturazione e i normali tempi di consegna.

Che importanza ha la roadmap di prodotto per il TCO?

L'ulteriore sviluppo dello standard potrebbe rendere superflui i progetti personalizzati. È importante stabilire quali funzioni e quali requisiti normativi debbano essere integrati nel prodotto standard.

Una piattaforma di governance più costosa è automaticamente più conveniente?

No. Ciò che conta è la struttura complessiva dei costi nell'arco della vita utile. Una piattaforma più economica può risultare economicamente vantaggiosa se offre una configurabilità sufficiente e bassi costi di esercizio.

Qual è la questione centrale nella valutazione delle modifiche successive?

È necessario chiarire quali oneri esterni e interni derivino da una modifica di un processo rappresentato e se tale adeguamento venga mantenuto nei futuri aggiornamenti.