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.
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.
A noi piace scrivere, dai un’occhiata alle nostre guide e approfondimenti
Library di Innovazione Digitale.--. .---. .---|__| .-. |~~~| .--|===|--|_ |_| |~~~|--. | |===| |'\ .---!~| .--| |--| |%%| | |.'\ |===| |--|%%| | | |%%| | |\.'\ | | |__| | | | | | | | \ \ |===| |==| | | | | | |__| \.'\ | |_|__| |~~~|__| | |===|--| \.'\|===|~|--|%%|~~~|--| ^--^---'--^ `-'`---^-^--^--^---'--'
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.
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:
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.
,---------------------------------------.---------. | | | | ,-----------------------------. | . | | | | | | | | | ,-------------------. | | | | | | | | | | | | | | `---- ,---- | | | | | | | | @ | | | | | | | ,---------"---------: | `----' | | | | | | | | `----: ,---------. | `---------. | | | | | | | | | . | | . | | ---------' | | | | | | | | | :----' | | | | | ,--------------: | | | | | | | | | . | `----' | | | ----. | | | | | | | | | | `----"--------- | | `---------' | | | | | `------------------------' `-------------------'