Un cliente si è recentemente rivolto a noi con un problema che la maggior parte delle aziende di servizi in crescita conoscerà bene. Il loro lavoro era distribuito tra ClickUp e Freshservice. Desideravano autorizzazioni più granulari per i loro rapporti con i clienti, altamente regolamentati, e la flessibilità di automazione necessaria per fornire un servizio clienti coerente su larga scala. Hanno scelto HaloPSA, ritenendo che potesse sostituire entrambi gli strumenti. Tuttavia, c'era un ostacolo: dovevano conservare anni di dati storici, fondamentali per la continuità del servizio offerto ai loro clienti. Ciò significava che l'impedimento al passaggio a un nuovo strumento sarebbe stato il compito che nessuno ama affrontare: la migrazione dei dati.
La risposta tecnologica è solitamente chiara quando veniamo chiamati in causa: esiste una piattaforma di destinazione più adatta. L'ostacolo non è quale strumentoutilizzare, ma il timore che il percorso sia lento, costoso e imprevedibile. Si rischia di perdere ticket, di non riuscire a generare report, di incontrare resistenze, di ricevere obiezioni da parte di enti regolatori o clienti, di sforare i costi.
Ma niente di tutto ciò è inevitabile. Se eseguita correttamente, la migrazione dei dati non dovrebbe rappresentare un ostacolo alla gestione aziendale con gli strumenti più appropriati. Il consolidamento può – e dovrebbe – essere un'opportunità per migliorare il funzionamento effettivo dell'azienda, non solo per spostare i dati da un punto A a un punto B. Ecco come lo affrontiamo.
Le due fasi del consolidamento
Un progetto di consolidamento si compone di due parti che è facile confondere, ma che sono di natura molto diversa.
Il primo passo è il trasferimento dei dati : importare ticket, commenti, allegati, utenti, campi personalizzati e dati storici dalle piattaforme di origine a quelle di destinazione. Si tratta di un lavoro prettamente tecnico. Per qualsiasi operazione che vada oltre i casi più semplici, si lavora tramite API, spesso seguendo un ordine preciso, perché gli allegati dipendono dai ticket, i commenti dagli utenti, i campi personalizzati dagli schemi e così via. L'importazione di file semplici permette di completare solo una parte del lavoro, non tutto. È proprio per questo tipo di attività che esistono strumenti specializzati, come Help Desk Migration
Il secondo aspetto riguarda la del modello operativo : decidere come la nuova piattaforma debba effettivamente funzionare per l'azienda. Quali categorie di lavoro la attraversano? Come si presenta un buon sistema di reporting? Chi è responsabile di quali code? Quali nuove funzionalità sono ora disponibili (fatturazione, self-service per i clienti, gestione integrata delle modifiche) che prima non erano possibili, e quali di queste vale la pena attivare ora piuttosto che in un secondo momento?
Queste due metà si completano a vicenda. Fare solo la prima significa ritrovarsi con il vecchio caos in un nuovo sistema. Fare solo la seconda significa rimanere bloccati perché i dati storici non saranno disponibili.
L'errore più comune nei progetti di consolidamento è quello di considerarli semplicemente un'operazione di migrazione dati. I maggiori vantaggi, ma anche i maggiori rischi, risiedono nel modello operativo.
Perché il consolidamento è più difficile di quanto sembri
Parte della complessità è di natura puramente tecnica. Parte è di natura organizzativa. Le trappole che riscontriamo più spesso sono:
1. La mappatura dei dati non è ordinata. Strumenti diversi strutturano gli stessi concetti in modo diverso. Nomi di stato, livelli di priorità, tipi di ticket, campi personalizzati, categorie, tipi di richiesta: quasi nulla corrisponde uno a uno. La parte difficile non è scrivere la mappatura, ma decidere quale debba essere, il che impone decisioni sul modello operativo prima di essere pronti.
2. Il modello agente/utente/cliente varia tra gli strumenti. Alcune piattaforme separano gli agenti interni dagli utenti esterni e dai clienti esterni come tre tipi di entità distinti. Altre li uniscono. Alcune consentono agli agenti di essere partner esterni; altre no. Il modo in cui Freshservice modella le persone non è lo stesso Halo , né Jira Service Management . La migrazione degli utenti raramente è un semplice copia-incolla: è una traduzione, e le scelte che si fanno in questa fase influenzano autorizzazioni, reportistica e licenze per anni.
3. Campi personalizzati e tipi di ticket si accumulano. La maggior parte dei sistemi sorgente ha anni di personalizzazioni accumulate, alcune utili, molte dimenticate. Migrare l'intero sistema ricrea lo stesso problema di manutenzione in un nuovo strumento. Migrare solo ciò che è necessario impone discussioni difficili con le persone che hanno creato quei campi.
4. Le autorizzazioni diventano più complesse, non meno. Una piattaforma consolidata di solito viene utilizzata da più team rispetto a qualsiasi singolo sistema sorgente. Ciò significa nuovi modelli di autorizzazione, nuove regole di visibilità e un livello di difficoltà più elevato per fare le cose per bene, perché gli errori sono più visibili.
5. La reportistica è il punto in cui gli errori si manifestano per primi. I sistemi sorgente spesso hanno report che dipendono da specifiche strutture di campi, stati o convenzioni di denominazione. Quando questi cambiano nel sistema di destinazione, i report smettono di funzionare e gli stakeholder se ne accorgono immediatamente. I requisiti di reporting dovrebbero essere progettati nella migrazione, non aggiunti in seguito.
6. Di solito è necessaria una migrazione di prova completa. Non un campione, non una migrazione parziale: una migrazione UAT completa con dati reali, sul sistema di destinazione configurato, eseguita dalle persone che effettivamente utilizzeranno il nuovo sistema. È qui che emergono le vere sorprese: forme di dati inaspettate, decisioni di mappatura errate, integrazioni che necessitano di modifiche. Prevedete il tempo e i costi necessari. Cercare di saltare questa fase è la scorciatoia più costosa nel processo di consolidamento.
7. I requisiti normativi e dei clienti spesso dettano cosa deve essere conservato. A volte un cliente vuole "abbandonare il vecchio sistema e ricominciare da capo", ma i suoi clienti, o gli enti regolatori, richiedono che i ticket, i commenti e gli allegati storici vengano conservati a fini di audit. Questo cambia completamente l'ambito della migrazione, perché la traccia dei commenti e degli allegati è la parte che richiede il maggior lavoro sulle API e la sequenza più accurata. Abbiamo avuto progetti in cui il requisito di conservazione dei dati è stata l'unica ragione per cui la progettazione della migrazione si è complicata. Scopritelo per tempo.
Un approccio pratico
Ogni consolidamento che abbiamo effettuato ha seguito più o meno lo stesso schema. Le etichette contano meno dell'ordine.
1. Comprendere cosa viene effettivamente utilizzato. Prima di mappare qualsiasi cosa, scoprite come vengono effettivamente utilizzati i sistemi di origine oggi, non come erano stati pensati per essere utilizzati e non cosa dice la documentazione. Estraete i report di utilizzo. Parlate con le persone che svolgono il lavoro. Di solito scoprirete che una parte significativa delle personalizzazioni nel sistema di origine è inattiva o non più rilevante. Questo non è un problema; è un'opportunità per consolidare verso un obiettivo più semplice.
2. Definire il modello operativo di destinazione. Questa è la domanda a cui torniamo sempre: cosa volete che la nuova piattaforma faccia per l'azienda che le vecchie non fanno? Reportistica SLA migliore? Fatturazione e contabilità integrate? Portali di richiesta self-service? Gestione delle modifiche collegata a un CMDB? Ognuna di queste spinge la configurazione in una direzione specifica. Decidete cosa state ottimizzando prima di iniziare a mappare i dati.
3. Progettate la mappatura dei dati in base al nuovo modello, non al vecchio. L'errore che la maggior parte dei team commette è quello di mappare la struttura dei dati di origine direttamente in quella di destinazione. L'approccio corretto consiste nel mappare i dati di origine attraverso il modello operativo di destinazione: quali campi vengono mantenuti, quali archiviati, quali dismessi e quali consolidati. È qui che le decisioni relative al modello operativo e la migrazione tecnica convergono.
4. Eseguire migrazioni di prova mirate. Prima della prova generale completa, (ad esempio, i ticket di un singolo team, un flusso di lavoro personalizzato o un gruppo di utenti) per verificare che la logica di mappatura e la sequenza delle API funzionino effettivamente end-to-end. Queste brevi prove individuano i problemi quando sono ancora economici da risolvere.
5. Eseguire una migrazione UAT completa. La prova generale. Dati completi, configurazione completa, utenti reali che testano scenari reali. Pianificare il tempo necessario. Questa è la fase che determina se il passaggio effettivo sarà tranquillo o caotico.
6. Effettuare il passaggio con un piano, non con una speranza. Comunicazioni, criteri di rollback, copertura del supporto, chi decide cosa durante la finestra di test. Il passaggio stesso è solitamente deludente se l'UAT è stato accurato.
7. Supportare l'adozione in modo adeguato. Un nuovo strumento che funziona perfettamente ma che nessuno usa è un progetto fallimentare. L'adozione richiede promotori interni, documentazione chiara, formazione adeguata alle reali modalità di lavoro e un supporto visibile da parte della dirigenza. Questa è la parte che i progetti di migrazione puramente tecnici sottovalutano sistematicamente.
Un esempio recente
La migrazione ha dovuto gestire tre diverse forme di dati:
- Documenti di ClickUp, dove la struttura era simile a quella di un wiki e legata ai progetti
- Attività da ClickUp, dove il modello era annidato e consapevole delle dipendenze
- Ticket di Freshservice, dove il modello era uno schema di ticket classico con commenti, allegati e relazioni con i richiedenti
Ciascuno di questi elementi doveva essere mappato , non in una replica esatta di come esisteva nella fonte, ma nel modello operativo che avevamo progettato per la destinazione. I documenti sono stati trasferiti in una direzione, le attività in un'altra, i ticket in una terza, e in alcuni casi è stato necessario effettuare dei riferimenti incrociati perché lo stesso lavoro aziendale era rappresentato in sistemi diversi.
Esiste un'alternativa fai-da-te per questo tipo di lavoro: scrivere script di migrazione direttamente sulle API di origine e di destinazione. È una soluzione che abbiamo già adottato in progetti precedenti e gli strumenti basati sull'intelligenza artificiale la rendono ancora più veloce. Tuttavia, in progetti in cui le strutture dei dati sono varie, la configurazione di destinazione è complessa e le tempistiche sono stringenti, l'utilizzo degli strumenti specializzati di Help Desk Migrationriduce significativamente i rischi del trasferimento dati e comprime i tempi. Questo ci ha permesso di concentrarci su ciò che il cliente ci aveva effettivamente richiesto: la configurazione, la progettazione dell'automazione e il modello di autorizzazioni.
Il risultato che interessava al cliente non era "abbiamo trasferito i dati con successo". Era che la nuova piattaforma gli fornisse i controlli e le automazioni di cui la sua attività aveva bisogno, senza perdere lo storico dei dati su cui facevano affidamento i suoi clienti. Questa è la differenza tra un progetto di migrazione dati e un progetto di consolidamento.
Osserviamo dinamiche simili quando la destinazione è una piattaforma PSA, che integra funzionalità di fatturazione, contabilità, redditività dei progetti e monitoraggio del tempo, oltre al lavoro operativo. Per un esempio pratico di consolidamento in HaloPSA, si veda il nostro recente caso di studio su bdq.cloud.
Dove si inserisce Help Desk Migration
Non pretendiamo di essere un'azienda specializzata in strumenti per la migrazione dei dati. Il lavoro tecnico di creazione ed esecuzione di script di migrazione su diverse API di piattaforme, nella sequenza corretta, gestendo i casi limite relativi ad allegati, commenti e mappature degli utenti, è un'attività specialistica, e Help Desk Migration è davvero esperta in questo campo.
Altrettanto importante è che gli strumenti specializzati mantengono prevedibili sia i costi che le tempistiche del trasferimento dei dati. La spesa per la migrazione dovrebbe essere una voce di spesa nota, non un rischio indefinito, e quando è nota, l'approvazione del business case per il consolidamento più ampio diventa molto più semplice.
Il punto su cui continuiamo a tornare
La migrazione dei dati non dovrebbe rappresentare un ostacolo alla gestione della tua attività con gli strumenti giusti. Può essere costosa, richiedere molto tempo e comportare dei rischi, ma con i partner e l'approccio giusti, non è un motivo per rimanere su una piattaforma che non ti è più utile.
Le organizzazioni che traggono il massimo vantaggio dal consolidamento sono quelle che lo considerano un'opportunità per migliorare il modello operativo, non solo per trasferire i dati. Il valore aziendale non risiede negli aspetti tecnici dello scripting API e della mappatura dei campi. Il valore aziendale risiede in una migliore reportistica, processi più efficienti, una maggiore automazione e team in grado di visualizzare e agire concretamente sul lavoro che conta.
Se stai valutando un consolidamento, la domanda da cui partire non è "come spostiamo i dati?", ma "che aspetto dovrebbe avere il sistema una volta completato il processo?". La parte relativa ai dati verrà di conseguenza.
Informazioni su BDQ
BDQ Cloud è una società di consulenza IT con sede a Londra, specializzata nella migrazione, consolidamento e modernizzazione di piattaforme di gestione dei servizi. Lavoriamo con HaloITSM, Atlassian, Freshworks, Asana e altri strumenti moderni, e collaboriamo con Help Desk Migration per il lavoro tecnico di migrazione dei dati che supporta i nostri progetti di consolidamento. Se desiderate discutere di una specifica sfida di consolidamento, offriamo una valutazione della migrazione di 30 minuti incentrata sul modello operativo e sui risultati attesi, non solo sull'aspetto dei dati.
