Skip to content
Insight

Risk management per i difetti del software: best practice nella gestione delle operation

Risk management per i difetti del software: best practice nella gestione delle operation

Quando si sviluppa un nuovo servizio digitale si tende sempre a concentrare l’attenzione sui benefici, considerando invece in modo marginale – o comunque poco strategico – il rischio di arresti anomali e bug. Tuttavia, l’esperienza insegna che questi possono verificarsi ed avere ripercussioni anche importanti sull’operatività, sull’immagine e sul profitto di un’azienda.

È dunque importante valutarne la gestione in modo oculato, ponendo l’accento su qualità del software e su di una manutenzione continuativa, per evitare proattivamente il loro verificarsi o, quanto meno,  provvedere alla pronta soluzione nel caso non sia stato comunque possibile prevenirli.

Se abbiamo parlato di rischio di arresti e bug, perchè non gestire anche questa assistenza come tutte le altre forme di prevenzione del rischio? Ripensare al bug come una sorta di sinistro offre la possibilità di gestirlo anche come tale, abbandonando il classico approccio all’assistenza basata sul ticketing e configurandola come una forma di assicurazione. Per quanto poco gradevole da pagare, l’assicurazione offre la certezza e la tranquillità di una copertura costante e di un rapido intervento.

Certezza dei costi

Ripensare l’approccio all’assistenza tecnica con una logica simile a quella di una polizza assicurativa presenta vantaggi anche dal punto di vista di bilancio: a differenza della logica di ticketing, in cui gli interventi portano con sé costi non prevedibili in modo preciso a priori, una logica di risk management presenta un costo certo indipendente dagli eventi successivi al rilascio del codice, finchè il loro effetto rientra all’interno di un frame contrattuale condiviso. 

Tuttavia, questo approccio richiede di superare quelle logiche tradizionali di procurement: il costo di un approccio basato sul risk management necessita di venir valutato non tanto in funzione dell’abituale dimensione del costo orario, quanto sulla base dei servizi che il fornitore si obbliga a fornire dopo la consegna del codice. Il nuovo approccio garantisce una completa consapevolezza su quelli che saranno i costi complessivi del progetto.

 

Ti piace leggere?

A noi piace scrivere, dai un’occhiata alle nostre guide e approfondimenti

Library di Innovazione Digitale
       .--.                   .---.
   .---|__|           .-.     |~~~|
.--|===|--|_          |_|     |~~~|--.
|  |===|  |'\     .---!~|  .--|   |--|
|%%|   |  |.'\    |===| |--|%%|   |  |
|%%|   |  |\.'\   |   | |__|  |   |  |
|  |   |  | \  \  |===| |==|  |   |  |
|  |   |__|  \.'\ |   |_|__|  |~~~|__|
|  |===|--|   \.'\|===|~|--|%%|~~~|--|
^--^---'--^    `-'`---^-^--^--^---'--'

Gestione del rischio in outsourcing

L’esigenza di contenere il rischio fa sì che la software house impegni quotidianamente risorse nella prevenzione e, al contempo, ne mantenga altre costantemente pronte a intervenire in caso di necessità, reperibili e dotate del know-how sul servizio digitale. Il cliente ha quindi l’ulteriore vantaggio di non dover gestire internamente questi elementi di complessità e può così concentrare le risorse sul proprio core business.

In questo modo l’assistenza diventa a tutti gli effetti una gestione oculata e preventiva del rischio di bug o down time da parte del fornitore, finalizzata a garantire la continuità del business. 

 

Valutazione del rischio ed effetti sulla qualità 

Ripensare l’assistenza in un’ottica assicurativa significa cambiare totalmente il suo modello di gestione e passare da una gestione contingente ad una basata sulla valutazione e gestione preventiva del rischio. 

Per ogni software da manutenere, infatti, si devono valutare i rischi connessi, per quantificare e predisporre le risorse necessarie ad assicurare un congruo livello di servizio.

Due concetti giocano un ruolo fondamentale nel definire questo nuovo approccio:

  • Gestione del rischio: Tipicamente, l’analisi dei rischi si basa sulla contemporanea valutazione della frequenza di accadimento e l’entità del danno. Questa valutazione, combinata con una preventiva analisi qualitativa del codice in termini di manutenibilità, qualità dei test ed altri elementi atti a incidere sui costi di gestione, è alla base della definizione delle specifiche commerciali e di servizio.
  • Qualità: Benché il quadro contrattuale delle attività di assistenza preveda comunque dei massimali limite per gli interventi, l’apertura di ticket, non più compensata “a consumo”, diventa a tutti gli effetti un costo per l’azienda sviluppatrice, che ha dunque l’esigenza di contenere il più possibile il ticketing per rispettare i parametri definiti in fase di analisi del rischio. La qualità del software sviluppato è quindi un elemento imprescindibile per permettere la sostenibilità di questo approccio, così come lo sono l’attività di monitoraggio continuativo della funzionalità e di compensazione del debito tecnologico.


Bottega52 adotta un approccio basato sul risk management per la manutenzione dei suoi prodotti digitali. In questo modo il cliente ha la certezza di una rendicontazione trasparente dei costi per la manutenzione del software, una continuità garantita e può dunque dedicarsi al suo business senza preoccuparsi dell’operatività del prodotto digitale.

 

Hai visto qui?

Abbiamo molti altri articoli da leggere, vai a vedere!

Insights52
,---------------------------------------.---------.    
|                                       |         |    
|    ,-----------------------------.    |    .    |    
|    |                             |    |    |    |    
|    |    ,-------------------.    |    |    |    |    
|    |    |                   |    |    |    |    |    
|    |    `----     ,----     |    |    |    |    |    
|    |              | @       |    |    |    |    |    
|    |    ,---------"---------:    |    `----'    |    
|    |    |                   |    |              |    
|    `----:    ,---------.    |    `---------.    |    
|         |    |         |    |              |    |    
|    .    |    |    .    |    |     ---------'    |    
|    |    |    |    |    |    |                   |    
:----'    |    |    |    |    |    ,--------------:    
|         |    |    |    |    |    |              |    
|    .    |    `----'    |    |    |     ----.    |    
|    |    |              |    |    |         |    |    
|    `----"---------     |    |    `---------'    |    
|                        |    |                   |    
`------------------------'    `-------------------'