Italiano
Architettura enterprise · HCM

Sostituire PeopleSoft con Workday: integrare oltre 200 sistemi enterprise

La storia di una trasformazione HCM presso una delle cinque maggiori banche canadesi e dell’architettura di integrazione che ha permesso di sostituire la piattaforma ufficiale senza compromettere paghe, sicurezza, dichiarazioni fiscali, identità o uno qualsiasi degli oltre 200 sistemi collegati.

12 min di lettura Di SEYSO SERVICES INC

200+

Sistemi integrati

Tier-1

Banca canadese

API+File

Integrazione ibrida

0

Elaborazioni paghe saltate

Perché le trasformazioni HCM falliscono e cosa abbiamo fatto diversamente

La maggior parte delle trasformazioni HCM non fallisce al livello HCM. Workday e SuccessFactors sono piattaforme mature: i fornitori sanno ciò che fanno. I fallimenti avvengono ai margini, nelle integrazioni. L’HRIS è la spina dorsale che collega paghe, fiscalità, finanza, sicurezza, identità, directory, governance, formazione, performance, mobilità, viaggi, spese e una lunga serie di processi aziendali su misura. Sostituire la spina dorsale senza cambiare con cura i collegamenti fa crollare l’intero organismo.

Quando abbiamo preso in carico il programma, l’inventario ha rilevato oltre 200 sistemi integrati, sviluppati soprattutto in un decennio di collegamenti punto a punto ad hoc al database PeopleSoft. Alcuni erano estrazioni notturne di file. Altri erano servizi SOAP quasi in tempo reale. Altri ancora erano viste dirette in sola lettura sullo schema PeopleSoft. Alcuni, scoperti solo con un’analisi approfondita, erano stored procedure non documentate.

Il problema architetturale da risolvere non era «come passiamo a Workday». Era «come ricolleghiamo 200 integrazioni a una nuova piattaforma con un modello API completamente diverso, in tempi misurati in trimestri, senza saltare un’elaborazione paghe».

La strategia di integrazione a quattro livelli

Abbiamo classificato ciascuna delle oltre 200 integrazioni in uno di quattro modelli e costruito un’architettura di destinazione per ognuno. Da lì, gran parte del programma ha seguito un percorso ben definito.

  1. Integrazioni API in tempo reale. I sistemi di identità, sicurezza e directory consumano gli eventi Workday tramite servizi web REST/SOAP. I nuovi assunti arrivano in Active Directory, nei sistemi di autorizzazione e nei flussi di revisione degli accessi in pochi minuti.
  2. Batch basati su file. Paghe, dichiarazioni fiscali, gestione pensionistica e molti sistemi legacy consumano estrazioni pianificate. Abbiamo standardizzato un unico modello di file in uscita con versionamento rigoroso, così i futuri cambiamenti nei sistemi destinatari non si propagano all’intero insieme.
  3. Collegamento tramite middleware. Alcuni sistemi si aspettavano il vecchio contratto PeopleSoft e non potevano essere modificati nei nostri tempi. Li abbiamo collegati tramite il middleware di integrazione enterprise, traducendo i payload Workday nella struttura legacy e lasciando invariato il sistema destinatario.
  4. Dismissione diretta. Un numero sorprendente di integrazioni era ormai inutilizzato: realizzate anni prima, gestite da team che avevano cambiato attività, consumate da sistemi dismessi. Le abbiamo spente. Questo fa sempre risparmiare più tempo del previsto.

Il livello di accesso alle API Workday

Workday offre molte API ma impone convenzioni precise. Espone servizi SOAP basati su WSDL per quasi tutto, oltre a endpoint REST moderni per le funzionalità più recenti. Il modello corretto è incapsularli, senza esporre mai Workday direttamente ai sistemi interni.

Abbiamo realizzato un livello di integrazione leggero davanti a Workday: un catalogo interno di servizi REST che traducono il vocabolario di dominio della banca (dipendente, ruolo, centro di costo, responsabile) negli oggetti nativi Workday. Qui risiedono autenticazione, autorizzazione, limitazione del traffico, tentativi, idempotenza e audit. I sistemi destinatari non devono quindi conoscere Workday e, se Workday introduce una modifica incompatibile, cambia soltanto questo livello.

Per le letture ad alto volume (organigrammi, mappature dei ruoli, navigazione delle gerarchie), replichiamo i dati Workday in un archivio di lettura aggiornato tramite Workday Outbound EIB e sottoscrizioni agli eventi. I consumatori batch accedono alla replica, senza sovraccaricare il tenant Workday attivo.

Single sign-on e mobile, una volta sola

Due iniziative trasversali erano incluse nel programma perché realizzarle dopo sarebbe costato il doppio.

La prima era l’SSO su tutta la piattaforma Workday . Federazione SAML dal provider di identità della banca a Workday, sia desktop sia mobile, abbinata all’accesso condizionale basato sul rischio della sessione. Gli utenti hanno un unico accesso; il team di sicurezza ottiene controllo centralizzato delle sessioni e una traccia di audit chiara.

La seconda era il mobile tramite AirWatch (ora Workspace ONE) come EMM. Workday Mobile viene distribuito tramite AirWatch con controlli di policy: divieto di copia/incolla dei dati sensibili, accesso condizionale, cancellazione remota dei dispositivi smarriti. Introdurlo insieme al passaggio HCM ci ha evitato di dover riprendere il mobile dopo l’avvio in produzione.

Passaggio: graduale, parallelo, reversibile

Per un sistema che gestisce paghe e dichiarazioni fiscali, un passaggio in blocco non è un’opzione. Abbiamo operato in parallelo per un intero ciclo paghe: PeopleSoft e Workday producevano output contemporaneamente, il livello di integrazione alimentava i sistemi a valle da PeopleSoft, allora sistema ufficiale, e un motore di riconciliazione confrontava ogni record tra le due piattaforme HRIS. Gli scostamenti venivano esaminati ogni giorno.

Il passaggio è avvenuto dominio per dominio, non tutto insieme: prima Core HR, poi Compensation, Time Tracking e Talent. Per ogni dominio, il sistema ufficiale cambiava solo dopo un’esecuzione parallela senza problemi. Il rollback era automatizzato tramite script: non abbiamo mai iniziato una fase senza una via d’uscita testata.

Cosa può impararne un’azienda

  • Inventario prima dell’architettura. Le prime sei settimane sono state dedicate alla ricognizione completa delle integrazioni: letture degli schemi, processi pianificati, procedure non documentate. Saltare questo passaggio significa scoprire sorprese durante la migrazione.
  • Incapsulare il SaaS. Non lasciare che i sistemi interni dipendano direttamente dai WSDL Workday. Il livello di integrazione leggero è l’elemento più prezioso che abbiamo realizzato.
  • Repliche di lettura per i consumatori con molte letture. I tenant Workday non gradiscono richieste intensive di dati organizzativi. Prima replicare, poi leggere.
  • Suddividere il passaggio in fasi. Dominio per dominio, con esecuzione parallela e riconciliazione, non tutto in una volta.
  • Integrare SSO e mobile durante il progetto. Realizzarli durante il passaggio costa molto meno che farlo dopo.

Stai affrontando questo percorso nella tua azienda?

SEYSO ha progettato e guidato migrazioni HCM, ERP e SaaS presso banche di primo livello e grandi imprese. Se stai pianificando un passaggio a Workday, SuccessFactors o un altro importante SaaS con numerose integrazioni legacy, parliamone. La mappa delle integrazioni è sempre il vero lavoro, ed è quello che sappiamo fare meglio.

Stai pianificando una migrazione SaaS importante?

Parla con architetti che hanno guidato trasformazioni Workday HCM in banche di primo livello.