Il PNRR sta evidenziando tutti i limiti di un mercato a “ciclo chiuso” dove le aziende fanno, da sole, la produzione del software e i servizi necessari, oltretutto con logiche poco efficienti (software fai da te).
Il mercato della sanità digitale è caratterizzato da due aspetti fondamentali: il modello di business e quello di produzione del software. Il primo vede, salvo poche eccezioni, un approccio a “ciclo chiuso” dove chi realizza il software è l’unico che possa erogare i servizi professionali. Si tratta di una logica “captive” nella quale il fornitore crea un forte lock-in con il cliente che, in questo modo, ne è totalmente dipendente. La complessità del software oggi, insieme alla scarsa se non totale assenza di documentazione, rende questa prassi molto resistente a qualsiasi tentativo di limitarne gli effetti attraverso la cessione del codice sorgente o della licenza d’uso. Questo approccio ha però anche spiacevoli conseguenze per i produttori. La necessità di dover provvedere da soli ai servizi professionali rende poco scalabile il modello di business. Al crescere dei clienti devo aumentare il numero delle persone per il delivery in un mercato dove trovare risorse professionali non è facile. La scarsa documentazione rende poi il processo di formazione lungo e dispendioso. Il vantaggio di operare in un mercato captive si rivela una gabbia dalla quale è difficile uscire.
Il modello di produzione del software è lo stesso di 20 – 30 anni fa. Sono naturalmente cambiate nel tempo le architetture e le tecnologie ma, salvo eccezioni, chi produce software realizza o è responsabile di tutto lo stack applicativo utilizzando linguaggi e metodi tradizionali, magari ricorrendo a componenti open source. Rispetto al passato, tuttavia, la complessità delle applicazioni è notevolmente cresciuta e tenere aggiornato il codice è sempre più difficile. Una modifica al browser rende necessario l’adattamento del front-end così come quello di una qualsiasi delle componenti di back-end. Ciò che succede di solito è le applicazioni rimangono “congelate” sulle tecnologie di quando sono state sviluppate. Nel giro di pochi anni queste evolvono e l’applicazione, dal punto di vista tecnologico, invecchia inesorabilmente. Tenere il passo con il ritmo di aggiornamento / evoluzione delle tecnologie e dei linguaggi di sviluppo è un’impresa anche per le aziende più strutturate.
Il modello di business e quello di sviluppo pesano sui conti e la redditività delle aziende di software specie in quei mercati, come ad esempio la sanità, dove le vendite anche per i leader di mercato sono poche (nell’ordine delle decine), la variabilità tra un cliente e l’altro significative, le tempistiche spesso ridotte (si vedano i progetti PNRR). Gli investimenti non si ripagano, la qualità ne risente, i clienti sono spesso insoddisfatti. Anche le aziende che operano in più paesi fanno fatica, per i limiti dei modelli che ho descritto e per le specificità dei mercati, a recuperare gli investimenti e a espandere le proprie attività.
Se guardiamo alle aziende che hanno avuto successo e sono diventate grandi e profittevoli, possiamo notare che tutte queste hanno costruito il proprio successo attraverso un ecosistema di partner che hanno sviluppato per e con loro il mercato. Il modello economico a ciclo chiuso non funziona, non fa crescere.
Riguardo poi le modalità di sviluppo del codice è anche qui necessario fare un cambio di paradigma. Piuttosto che fare tutto da soli, meglio utilizzare piattaforme “low-code” che consentono di lasciare l’onore dell’aggiornamento tecnologico ai loro produttori per potersi così concentrare sulle logiche e le esigenze del dominio. Piuttosto che provare a svilupparsi in casa delle simil piattaforme di sviluppo, meglio lasciare questo lavoro a chi lo fa di mestiere e concentrarsi sulle logiche del dominio nelle quali l’esperienza e la competenza che si possiedono può fare la differenza. Le piattaforme “low-code” sono di norma ben documentate, sono corredate di corsi e materiale formativo, così che l’inserimento di nuovi sviluppatori è molto più facile di quanto non avviene dove ci sono software e componenti fatti in casa.
Prototipazione, flessibilità, tempi di sviluppo, sono alcuni dei vantaggi che le piattaforme “low code” assicurano, specie quando sono specializzate per uno specifico dominio. Le Digital Health Platform permettono di creare ecosistemi di partner e di operare sul mercato con logiche efficienti ed efficaci dal punto di vista del business.
Comprendo bene che questo cambiamento non sia facile da accettare per chi magari è abituato a “controllare” e “fare” tutto in totale autarchia, magari senza calcolare i “costi effettivi” che in questo modo si sostengono e le opportunità che si perdono, ma continuare a fare le stesse cose sperando in risultati diversi è veramente stupido.