Ad oggi, dopo 10 anni di diffusione massiva delle tecnologie IoT, la maggior parte delle nuove apparecchiature (consumer, professionali o industriali) vengono progettate dal loro costruttore come connesse.

Solo in Europa, si stima che siano attualmente in funzione circa 1,5 miliardi di prodotti connessi.

I costruttori / OEM hanno investito ingenti risorse, dapprima per rendere i propri prodotti connessi e successivamente per cercare di sfruttare i dati ricevuti per offrire valore ai propri clienti.

Un enorme potenziale ancora non sfruttato

Ma, nonostante tutti gli sforzi e gli investimenti, oggi siamo di fronte a un fallimento di queste iniziative. La Commissione Europea infatti stima che l’80% dei dati generati dai prodotti connessi e raccolti dagli OEM non viene usato.

Il cambio di prospettiva, verso i servizi connessi

In che modo quindi un OEM può "usare" i dati ricevuti dai suoi prodotti connessi ?

A parte un uso interno allo scopo di migliorare la progettazione dei prodotti, l'unico altro modo per usarli è offrire valore aggiunto all'esterno.

E questo uso può prendere un’unica forma, quella di un servizio, un servizio basato sui dati o, come preferiamo chiamarli noi, un "servizio connesso".

Questo cambio di prospettiva è fondamentale: la vendita di prodotti connessi non basta, possiamo mantenere la "promessa" dell'IoT solo muovendoci verso i servizi connessi.

Come trasformare il dato in servizio

In quanti modi si può trasformare un dato in servizio? Quanti tipi possibili di servizi connessi ci sono?

Per rispondere a queste domande abbiamo analizzato oltre 300 casi e abbiamo interagito con i più autorevoli istituti di ricerca sulla servitization. Abbiamo quindi mappato tutti i possibili "use case" dei servizi connessi, cioè tutti i modi possibili per sfruttare i dati per erogare valore sotto forma di servizi.

In altre parole: come trasformare il dato in servizio.

"Usare" i dati ricevuti da prodotti connessi vuol dire avviare almeno una di queste 5 iniziative:

• Comporre, erogare e vendere servizi digitali ai clienti finali, come ad esempio funzionalità di monitoraggio e controllo remoto, analisi e consulenza sulle prestazioni, manutenzione assistita
• Rendere il field service "connesso" per l'OEM e i suoi partner, cioè sfruttare i dati dei prodotti connessi per ottimizzare le attività post-vendita, ridurre i rischi e aumentare i risultati e il valore dei contratti di servizio
• Semplificare e automatizzare la vendita di ricambi e consumabili, tenendo conto dell’utilizzo reale e delle condizioni del prodotto
• Evolvere verso i servizi avanzati alimentati dai dati, come contratti basati sui risultati, sulle prestazioni, XaaS o pay-per-use
• Condividere e monetizzare i dati verso terze parti interessate ad offrire altri tipi di servizi (dal 12 Settembre 2025 questo è anche quanto previsto dalla legge europea Data Act)

(approfondisci l'argomento nel Learning Center: https://learn.servitly.com/docs/how-to-design-a-connected-services-strategy)

Il divario dati-servizio

Ma, nonostante le tecnologie e soluzioni oggi a disposizione (come ad esempio le IoT platform o le piattaforme di BI e data analytics), usare i dati per erogare anche solo una delle iniziative di servizi connessi non è affatto semplice. Tra la teoria e la pratica c’è un divario enorme.

Oggi molte testimonianze di aziende che hanno iniziato questa trasformazione verso i servizi connessi, pur confermando la convinzione nella loro scelta, evidenziano anche delle difficoltà e sfide.

Le possiamo riassumere tutte nel termine "divario dati-servizio".

Il divario dati-servizio è la combinazione delle difficoltà, problemi e limitazioni che le aziende trovano nell'intento di trasformare i dati ricevuti dai prodotti connessi in servizi basati sui dati (o “servizi connessi”) che siano realmente di valore per i clienti finali

Il divario dati-servizio è la causa che provoca l'inutilizzo dell'80% dei dati.

I 6 ostacoli principali

Sin dalla nostra fondazione, ci siamo concentrati sull'analisi e la comprensione di questo divario. Abbiamo trovato i 6 ostacoli principali che lo costituiscono.

Elaborazione dati inefficace

Molto spesso i dati non vengono elaborati, ma vengono semplicemente presentati in forma grezza all’interno di dashboard. La conseguenza negativa di questo limite è che gli utenti faticano a trovare informazioni utili e a capire cosa devono fare.

UI generica e prodotto-centrica

In genere, per semplicità, viene offerta la stessa interfaccia a tutti gli utenti e l'unica differenza riguarda la segregazione dei dati; l'interfaccia è progettata solo come un’estensione dell'HMI del prodotto. La conseguenza negativa di questa limitazione è che gli utenti non ricevono alcun aiuto specifico per le loro esigenze, i loro obiettivi o i loro compiti.

Soluzione cablata e inflessibile

Quasi sempre, tutta la logica e le interfacce sono incorporate direttamente nel codice sorgente di una soluzione custom, senza alcun livello di astrazione. La conseguenza negativa di questa limitazione è che le modifiche e gli aggiornamenti alla soluzione risultano complessi e costosi.

Nessuna funzione business integrata

In genere la soluzione si occupa solo di presentare i dati e non include nessuna funzione di supporto ai flussi di lavoro e ai processi di business, come ad esempio la gestione di ticket e work order, ordini di parti di ricambio, sottoscrizioni, registro delle attività di manutenzione, ecc. La conseguenza negativa di questa limitazione è un basso valore per l'utente e un’esperienza d'uso dispersiva tra soluzioni diverse.

Gestione inefficace di prodotti diversi

E' particolarmente complesso adattare la logica e l'interfaccia di una soluzione a tipi e famiglie di prodotti diversi. Le conseguenze negative di questa limitazione sono logica e interfacce troppo generiche, e quindi inefficaci, o la duplicazione della soluzione per tipi di prodotto diversi.

Isolamento del sistema

Spesso la soluzione non è progettata per le integrazioni, né verso l'interno, né verso l'esterno, cioè con i sistemi informativi di clienti e partner. Le conseguenze negative di questa limitazione sono il disallineamento dei sistemi interni e il rischio di rifiuto della soluzione da parte di clienti e partner.

I sintomi del divario

Se non affrontati, questi ostacoli hanno un impatto negativo sulla tua strategia di servizi connessi e portano a questi sintomi:

• Basso valore percepito dei servizi digitali - il valore dei servizi digitali percepito dai clienti è basso; l'adozione e la frequenza d'uso è bassa e, nel caso ci siano opzioni a pagamento, pochi sono disposti a pagare
• Field service non connesso e dispersivo - il tuo field service opera ancora "alla vecchia maniera", nonostante la sovrabbondanza di dati, con uno spreco di tempo e risorse ingiustificato ora che i dati ci sono
• Eccessivo time-to-market - i tempi per portare la tua soluzione e le sue evoluzioni al mercato sono eccessivi, non riesci a stare dietro alle richieste e aspettative (digitali) del mercato
• Paralisi nell'esecuzione della strategia - sei paralizzato nell'esecuzione della tua strategia e nella progressione lungo la scala dei servizi connessi, non sei in grado di progredire sugli scalini più alti e di generare nuovo valore
• Risorse sprecate e IP debole - sprechi risorse in attività tediose e a zero valore aggiunto e ne dedichi solo una frazione al "core", cioè alle funzioni ad alto valore aggiunto che costituiscono il tuo IP e il tuo vantaggio competitivo
• Decisioni cieche rispetto ai dati - nonostante la disponibilità di dati, non sei in grado di accedere facilmente ad informazioni utili per prendere decisioni, impostare le priorità, organizzare il lavoro

Come superare gli ostacoli e assicurare il successo dei servizi connessi

Per superare gli ostacoli la tua soluzione IoT deve avere 6 caratteristiche fondamentali, una per ogni ostacolo.

Un'elaborazione dati adeguata ai servizi per trasformare i dati in azioni

Non limitarti a presentare i dati in dashboard ma aggiungi anche tutte le funzionalità di elaborazione dati, basate su algoritmi e regole, necessarie per estrarre informazioni sintetiche e pratiche, come uno indice di uptime o di efficienza, individuare eventi, attivare avvisi e notifiche, fornire raccomandazioni operative e attivare processi aziendali.

Interfacce multiple, mirate a ruoli e bisogni

Differenzia le interfacce, dati, informazioni e funzionalità per ciascun tipo di stakeholder coinvolto nel sistema prodotto-servizio: gli utenti all'interno della tua organizzazione, gli utenti all'interno di terze parti (distributori, installatori, manutentori) e gli utenti all'interno dei tuoi clienti finali. Non si tratta solo di segregare i dati, ma di offrire agli utenti anche un'intera esperienza d'uso a loro dedicata.

Questa caratteristica è fondamentale per il successo della strategia dei servizi connessi, perché i “jobs-to-be-done” e i bisogni degli utenti sono molto diversi tra loro.

In particolare, hai bisogno di almeno due viste principali.

1. un Customer Portal dedicato ai clienti finali, che accedono così a dati approfonditi, informazioni pratiche, raccomandazioni e funzionalità digitali che li aiutano a sfruttare al meglio il prodotto connesso.
2. una Control Room dedicata al team di service after-sales che accede a dati dettagliati, approfondimenti, informazioni pratiche e funzionalità digitali, che supportano le loro attività.

Una soluzione facilmente configurabile

Tutti gli aspetti chiave del tuo sistema (interfacce, algoritmi, regole, integrazioni) devono essere separate dal codice sorgente e rese facilmente configurabili e aggiornabili.

Funzioni integrate di supporto ai processi

Oltre che alla presentazione di dati e informazioni aggiungi anche funzioni integrate per il supporto ai flussi di lavoro e ai processi di business, come:

• l'apertura e gestione di ticket
• la gestione del registro delle attività di manutenzione svolte
• la gestione dei work order
• la gestione degli ordini di parti di ricambio e/o consumabili
• la gestione di piani, sottoscrizioni e pagamenti online

Logica e interfaccia basate sul tipo di prodotto

Devi organizzare e gestire nella tua soluzione tutti i tuoi modelli di prodotti e definire logica ed interfacce differenti.

Architettura multi-party API-first

L’architettura della soluzione deve essere basata su API, con un distacco netto tra back-end e front-end. Tutte le funzioni disponibili nel front-end devono essere anche disponibili come API. Questo garantisce il massimo livello di integrabilità con altri sistemi informativi, sia interni, sia esterni.

Al tuo interno, la soluzione deve connettersi facilmente al CRM, per mantenere sincronizzati clienti e utenti, al FSM, per creare automaticamente ticket e ordini di lavoro, e al portale clienti per offrire ai clienti un'esperienza uniforme e coerente.

Al tuo esterno, la soluzione deve connettersi facilmente ai sistemi informativi dei tuoi clienti e partner. Ad esempio un cliente che ha già una soluzione di monitoraggio per il suo plant o building, potrà integrare dati e informazioni principali nella sua soluzione e accedere facilmente alla tua per approfondimenti.

Oppure, nel contesto degli obblighi del Data Act, una terza parte autorizzata dall'utente potrà accedere facilmente ai dati grezzi a cui lei ha diritto.

Conclusione

Nonostante la grande diffusione di prodotti connessi, oggi l’80% dei dati generati non è ancora usato.

Gli OEM possono davvero sfruttare quei dati solo se non si fermano a vendere prodotti connessi ma aggiungono al proprio modello di business anche un’offerta di servizi connessi.

Trasforma dati in servizio però non è banale. Ci sono 6 ostacoli principali che costituiscono il “divario dati-servizio”.

Puoi superare questi ostacoli concentrandoti su 6 caratteristiche fondamentali della tua soluzione IoT. Oppure adottando un SaaS di nuova generazione come Servitly.

‍