In tutti gli ambiti applicativi, sia pure con diversa intensità, la personalizzazione del software è un fenomeno molto diffuso che fa lievitare i costi, allunga i tempi di realizzazione, pregiudica la qualità e ne complica la gestione. Ma quali sono le ragioni di questo comportamento ? Sono realmente giustificate ?
Le ragioni alla base del fenomeno sono tante, provo qui a riportare le principali e a condividere qualche riflessione.
- Il software non prevede una funzione o delle informazioni. Ciò può dipendere da un’analisi carente, il tal caso lo sviluppo arricchirà il prodotto, o da esigenze particolari dell’azienda sanitaria che, una volta soddisfatte, rimarranno specifiche e circoscritte.
- Il software prevede una funzione o delle informazioni che però non sono come dovrebbero essere – ad esempio campi di testo anziché dati strutturati o viceversa. In questo caso la valutazione è spesso soggettiva e condizionata da fattori quali l’usabilità, l’abitudine, lo scopo per il quale si raccolgono i dati.
- Il software prevede una funzione o gestisce un processo in una modalità differente da come si svolge nell’azienda sanitaria. Nella mia esperienza la richiesta dell’azienda sanitaria, in questi casi, è di voler adattare il software piuttosto che considerare di modificare il processo, anche quando si è in presenza di una trasformazione digitale di un processo gestito su carta.
- Il software gestisce molte informazioni, magari frutto di più personalizzazioni, ed è giudicato troppo complicato, da cui la richiesta di semplificare delle form o delle funzioni. Questo problema è maggiore quando la personalizzazione è stata affrontata non sul piano della parametrizzazione o non ingegnerizzata (personalizzazione additiva).
- Il software prevedere delle informazioni che, nel particolare contesto dell’azienda sanitaria, non sono disponibili, per cui è necessario prevedere dei workaround per bypassare il problema. Anche in questo caso l’impatto della personalizzazione dipende dall’ingegnerizzazione del software e se tale eventualità è stata o meno prevista in fase di disegno.
- L’interfaccia utente del software presenta degli aspetti grafici che gli utenti non gradiscono e vogliono cambiare. Talvolta queste richieste sono legittime e focalizzate sul miglioramento dell’usabilità, altre molto soggettive e non necessariamente corrette.
- Vi sono caratteristiche dei device, ad esempio la risoluzione dei monitor in uso, i sistemi operativi installati, i database, la necessità di impiegare dispostivi mobili, che non si conciliano o sono incompatibili con il software. Come anche per il punto precedente, questo tipo di modifiche / personalizzazioni possono essere molto complesse ed onerose e quindi spesso non si eseguono.
- Il software deve operare con periferiche come stampanti, lettori barcode, ed altri che non sono supportati e non possono essere sostituiti. Anche in questo l’impatto della personalizzazione dipende fortemente dall’architetura del software.
- Il software deve essere integrato con altri sistemi. Se questo non è basato su un’architettura a servizi e non prevede un middleware di integrazione, questa attività può risultare molto complessa ed onerosa.
- Il software deve essere adeguato a normative locali o regionali. Se il software non è stato progettato per gestire questa problematica, l’implementazione di nuove funzioni o la gestione di informazioni aggiuntive può risultare complicato e avere un impatto sensibile sul software, a volte stravolgendolo.
Quando la parametrizzazione non è sufficiente per rispondere alle richieste sopra menzionate o l’ingegnerizzazione non è in grado di adattare il software, si ricorre a modifiche embedded nel codice che di fatto determinano la creazione di un nuovo software, generato da quello originale, che diventa pertanto un semilavorato da cui partire per realizzare le soluzioni per le aziende sanitarie clienti.
Questo approccio presenta tanti aspetti negativi: richiede risorse per gli sviluppi; fa aumentare i costi; allunga i tempi di realizzazione; pregiudica la qualità e comporta la necessità di effettuare molti test e verifiche; compromette la gestione futura del software che diviene una soluzione ad hoc, difficile ed antieconomico da manutenere e far evolvere.
C’è poi un altro aspetto che questo approccio determina: la deresponsabilizzazione del fornitore che non investe come dovrebbe nell’analisi e nella ricerca su come disegnare al meglio funzioni e processi, dal momento che saranno poi i clienti a dettare le regole e i requisiti su come dovrà essere il software. Attività che spesso pesa molto di più, in termini economici e di margini, rispetto alla vendita di licenze software e servizi correlati.
Il valore del software quindi diventa marginale a scapito delle attività di configurazione e personalizzazione che, salvo eccezioni, sono captive perché in presenza di un meccanismo di lock-in che impone al cliente la scelta, per tutta la vita del software, del fornitore che ha vinto la gara, magari scontando al massimo il costo delle licenze software.
Tutto ciò è antieconomico e genera inefficienza oltre a un discreto livello di insoddisfazione tra gli utenti, le aziende sanitarie e tutto sommato anche i fornitori che, a conti fatti, ottengono margini risicati da una serie di attività non ripetibili e fini a sé stesse, anche se pagate su base giornaliera, ma a volte con tariffe basse.
Per questa ragione è necessario che in sanità, come è avvenuto in altri settori, si superi la logica del “vestito su misura” per andare nella direzione dei prodotti che, in alcuni casi, dovranno essere certificati come dispositivi medici di tipo IIA. Per realizzare ciò è però necessaria una vera e propria rivoluzione culturale sia da parte degli utenti, sia dei fornitori che sono chiamati a rivedere la loro logica di business, la tipologia di risorse professionali da coinvolgere, il livello di investimento necessario per realizzare nuovi prodotti.