Migrazione WLA: Best Practice e Approcci dei Vendor

Il 67% delle organizzazioni sta passando a strumenti di workload automation più funzionali, poiché la scelta giusta può migliorare l'efficienza operativa del 56% e ridurre i costi del 39% secondo lo State of IT Automation Report.¹

Esplora la migrazione della workload automation (WLA), le best practice, a cosa prestare attenzione e i diversi approcci dei vari vendor.

Cos'è la migrazione WLA?

La migrazione WLA (Workload Automation) è il processo di spostamento della pianificazione dei job e dei flussi di lavoro di automazione di un'organizzazione da una soluzione di workload automation a un'altra. Le aziende lo fanno per sostituire strumenti legacy con piattaforme moderne che possano supportare meglio le attuali esigenze aziendali o per risparmiare sui costi.

La migrazione WLA aiuta inoltre a garantire operazioni 24/7. Molte aziende si affidano agli scheduler per eseguire processi complessi e mission-critical, e il passaggio a una soluzione più robusta consente loro di soddisfare le crescenti richieste di automazione e di elaborazione in tempo reale.

La migrazione WLA non è solo un aggiornamento tecnico. È un abilitatore di business che allinea l'infrastruttura di automazione sia alle esigenze attuali che alla crescita futura, aiutando le organizzazioni a operare in modo efficiente, affidabile e su larga scala.

Perché le organizzazioni migrano verso nuovi strumenti WLA?

Gli scheduler di job legacy spesso faticano a orchestrare i processi negli ambienti IT moderni. Ad esempio, i sistemi WLA più vecchi potrebbero non eseguire i job in modo fluido sia sull'infrastruttura on-premises che su più piattaforme cloud, rendendo difficile la gestione dei flussi di lavoro IT ibridi.

Altri driver comuni per la migrazione includono:

• Iniziative di trasformazione digitale: Le aziende che attraversano una trasformazione digitale spesso scoprono che i loro strumenti di automazione esistenti mancano dell'agilità e delle capacità di integrazione necessarie per i nuovi progetti.
• Adozione del cloud e ambienti ibridi: Molti scheduler più vecchi non erano progettati per l'orchestrazione in cloud ibrido, spingendo verso un passaggio a strumenti cloud-ready. Vedi scheduler di job per cloud ibrido.
• Scalabilità e prestazioni: Le aziende oggi gestiscono volumi di dati e processi più ampi. I moderni strumenti di workload automation sono progettati per scalare orizzontalmente e verticalmente per gestire migliaia di job concorrenti, mentre uno scheduler legacy potrebbe avere difficoltà o diventare un collo di bottiglia.
• Costi di manutenzione e rischi di supporto: Il software di automazione legacy può comportare elevati costi di licenza e manutenzione. In alcuni casi, i vendor potrebbero aver interrotto lo sviluppo attivo o il supporto per le versioni più vecchie.
• Funzionalità e analisi avanzate: Le nuove soluzioni WLA offrono spesso funzionalità predefinite per fornire migliori intuizioni sulle operazioni, come: progettisti di flussi di lavoro visivi, dashboard di monitoraggio centralizzate, auditing granulare e ottimizzazioni basate su ML.

Approcci di migrazione dei principali vendor WLA

Tutti i principali vendor condividono lo stesso obiettivo, ovvero assistere le aziende nel passaggio dagli scheduler di job legacy riducendo il rischio, nonostante le loro strategie disparate. Esistono tre metodi principali:

• Sfruttare strumenti di conversione automatizzati
• Affidarsi a consulenti focalizzati sui servizi
• Combinare i due approcci.

Stonebranch (Universal Automation Center)

Stonebranch’s Universal Automation Center (UAC) offre un servizio di migrazione strutturato per spostare le organizzazioni dagli strumenti di workload automation legacy alla sua piattaforma moderna. Il servizio combina strumenti di automazione con supporto esperto e copre sistemi come CA 7, SAP Job Scheduler, Tidal, Windows Task Scheduler e cron.

Stonebranch offre lo Xpress Conversion Tool (XCT) per convertire automaticamente i job legacy in formati compatibili con UAC. Ad esempio, i job in background di SAP possono essere importati e trasformati con un minimo sforzo manuale. XCT preserva le definizioni dei job, i trigger, le dipendenze e le mappature delle risorse durante tutta la migrazione.

La migrazione segue un approccio in 7 fasi:

1. Iniziazione: Definire l'ambito e configurare l'ambiente di migrazione.
2. Analisi: Inventariare e valutare l'attuale panorama dei job.
3. Migrazione pilota: Testare l'accuratezza della conversione e ottenere le approvazioni.
4. Transizione completa: Automatizzare la conversione di tutti i workload.
5. Validazione: Effettuare controlli di qualità e revisioni degli utenti.
6. Cut-over: Sostituire il sistema legacy con UAC in produzione.
7. Chiusura: Finalizzare la documentazione e il trasferimento di conoscenze.

Formazione, esecuzioni parallele e supporto al go-live garantiscono una transizione fluida con rischio e interruzioni minimi.

Redwood RunMyJobs

RunMyJobs fornisce un servizio di migrazione completamente guidato chiamato “migration factory”. RunMyJobs by Redwood dispone di un team di esperti e strumenti proprietari per migrare i workload da tutte le principali piattaforme WLA. Iniziano analizzando in dettaglio l'inventario dei job esistenti (valutazione della migrazione) e poi migrano i workload in sprint agile, partendo dai job a basso rischio.

Il processo di migrazione di RunMyJobs spesso prevede l'esecuzione parallela dei sistemi vecchio e nuovo e la formazione del team del cliente durante tutto il progetto. Con oltre 100+ aziende migrate ad oggi, Redwood sfrutta circa 30 anni di esperienza per garantire una transizione fluida con tempi di inattività minimi.

Strategia di migrazione di RunMyJobs

1. Lancio del progetto

La migrazione inizia con job semplici e a basso rischio e si sposta gradualmente verso quelli più complessi. È organizzata in sprint agile, raggruppando i job per applicazione, unità aziendale o tipo di job per ridurre al minimo le interruzioni.

2. Installazione e configurazione

Vengono configurati gli ambienti RunMyJobs, l'autenticazione dell'utente e i protocolli di sicurezza. L'integrazione con tutti i sistemi e i database garantisce l'esecuzione fluida del flusso di lavoro in tutta l'impresa.

3. Formazione del team

Gli stakeholder chiave seguono una formazione tramite la piattaforma on-demand di Redwood University e sessioni guidate da istruttori, garantendo un'esperienza pratica e un apprendimento continuo durante la migrazione.

4. Sprint di migrazione agile e hypercare

La migrazione avviene a fasi con i sistemi legacy e RunMyJobs che girano in parallelo. Dopo la conversione dei dati e i test, i flussi di lavoro vengono spostati in produzione. L'hypercare assicura che il sistema sia monitorato e che i problemi vengano risolti post-migrazione.

ActiveBatch

ActiveBatch offre un servizio di migrazione guidata per spostare le organizzazioni dagli scheduler legacy alla sua moderna piattaforma di workload automation. La migrazione segue un approccio a fasi e consapevole dei rischi. Inizia con un inventario dettagliato dei flussi di lavoro e degli oggetti job esistenti, seguito da una strategia di migrazione su misura.

ActiveBatch fornisce inoltre strumenti di migrazione automatizzati che convertono gli oggetti dello scheduler legacy in formati compatibili con ActiveBatch, semplificando la transizione.

La formazione e i test sono parti fondamentali della migrazione. Il team del cliente viene formato sulle funzionalità di ActiveBatch, e le esecuzioni parallele dei sistemi vecchio e nuovo vengono utilizzate per verificare la migrazione prima del deployment completo.

ActiveBatch ha un processo specificamente snellito per la migrazione da questi scheduler:

• BMC Control-M
• CA AutoSys
• CA Workload Manager
• IBM Tivoli
• Unix cron
• Windows Task Scheduler
• SQL Server Agent​

Per esempio, ActiveBatch può convertire automaticamente i job di questi scheduler (incluse regole di pianificazione complesse e avvisi) in flussi di lavoro ActiveBatch. Allo stesso modo, importa le definizioni dei job di CA AutoSys esportando i file JIL di AutoSys e convertendoli in oggetti ActiveBatch​.

Questi strumenti di conversione mantengono gli attributi dei job cũng come i calendari, i trigger di eventi, le allocazioni di risorse e le dipendenze. L'approccio enfatizza una migrazione affidabile e senza script (free) per ridurre al minimo il rischio e i tempi di inattività.

CA Workload Automation (Broadcom)

CA Workload Automation fornisce un servizio di migrazione strutturato e basato su strumenti, supportato da esperti dedicati. La migrazione è guidata dallo strumento proprietario di CA, che automatizza fino all'80% della conversione da scheduler legacy come Control-M, TWS, Tidal e cron.

La migrazione include esecuzioni parallele durante i test per ridurre al minimo le interruzioni. CA fornisce inoltre supporto operativo, formazione e trasferimento di conoscenze per garantire che il team del cliente possa gestire la piattaforma in modo efficace. Con decenni di esperienza e una metodologia comprovata, CA realizza migrazioni efficienti con tempi di inattività minimi.

Gli strumenti di migrazione supportano le transizioni dai seguenti prodotti:

• BMC: Control-M
• ASG: Zeke, Zena
• IBM® Tivoli®: TWS per z/OS, DJC, TWS per DS (precedentemente Maestro)
• Cisco: Tidal
• Scheduler nativi: cron, Microsoft® SQL Server®, Windows Batch Scheduler
• Redwood: Cronacle

Figura 2. Processo di migrazione di CA ³

HONICO (BatchMan for SAP)

Si specializza nella workload automation focalizzata su SAP e offre un servizio di migrazione su misura per i clienti che passano da altri provider WLA alla loro soluzione BatchMan. Stonebranch ha acquisito HONICO il 10 settembre 2025, integrando lo strumento SAP di HONICO, BatchMan, nella sua piattaforma UAC per un'orchestrazione IT ibrida unificata, mantenendo BatchMan disponibile come prodotto autonomo.

L'approccio di HONICO inizia con una thorough valutazione delle esigenze e un'analisi dell'ambiente attuale del cliente, seguita da una proof-of-concept che implementa alcuni processi critici in un sistema di test. Successivamente, eseguono una migrazione massiva automatizzata degli oggetti job in un ambiente di test per la validazione.

Quando si tratta di cutover, HONICO è flessibile: possono eseguire una migrazione passo-passo fianco a fianco o uno switch “Big Bang”, a seconda di ciò che i test indicano come più sicuro. Un periodo di HyperCare viene fornito post-go-live, in cui il team di HONICO supporta strettamente le operazioni del cliente per garantirne la stabilità. La loro esperienza nella pianificazione SAP significa che si concentrano sulla conservazione dei parametri dei job specifici di SAP e sul miglioramento dell'integrazione con i sistemi SAP. I clienti hanno riportato miglioramenti significativi (ad esempio, riduzione dello sforzo manuale e maggiore trasparenza nei processi batch SAP) dopo la migrazione alla piattaforma WLA di HONICO.

Esempi reali di migrazione WLA

SWM

SWM, un importante fornitore di servizi municipali in Germania, è migrato da BMC Control-M a RunMyJobs per snellire la sua workload automation e ridurre i costi operativi.

Sfide

SWM aveva bisogno di superare BMC Control-M per supportare le sue operazioni in espansione incentrate su SAP. Il team SAP Basis cercava una piattaforma con una profonda integrazione SAP e la flessibilità di gestire diversi sistemi aziendali. Un requisito chiave era l'automazione del complesso processo meter-to-cash all'interno di SAP IS-U, che comportava un'orchestrazione di job multi-step ad alto volume e richiedeva un'esecuzione affidabile su varie fonti di dati.⁴

Risultati:

• Eliminate oltre 1 ora di sforzo manuale per processo SAP
• Ridotti i carichi SAP HANA a 6–7 ore, i calcoli a 1,5–2 ore
• Abilitata l'orchestrazione notturna completa tra i sistemi
• Aggiunto auto-recovery: i job falliti ripartono in 30 minuti
• Migliorata l'accuratezza della fatturazione e la disponibilità dei dati dei clienti

BSH Hausgeräte GmbH

BSH, uno dei principali produttori mondiali di elettrodomestici, ha sostituito diversi strumenti di pianificazione obsoleti con RunMyJobs per armonizzare l'automazione nel suo ambiente IT globale. La transizione ha portato a un miglioramento della pianificazione dei job SAP, a un monitoraggio consolidato e a significativi guadagni di efficienza. Inoltre, la piattaforma unificata ha aiutato BSH a rispettare gli standard di governance interni.⁵

Sfide

La dipendenza di BSH da Broadcom AutoSys limitava la sua capacità di scalare e automatizzare processi finanziari e di supply chain complessi. La necessità di frequenti sviluppi personalizzati portava a instabilità, elevati costi di manutenzione e interruzioni. Con un ambiente IT vasto, che includeva cinque sistemi core SAP ERP, oltre 30 sistemi aggiuntivi e oltre 2.000 server, BSH richiedeva una piattaforma di automazione più affidabile e scalabile per supportare le sue operazioni globali.

Risultati:

• Costruita la resilienza attraverso la gestione delle eccezioni e flussi di processo dinamici
• Sostituito AutoSys con un'orchestrazione in tempo reale guidata dagli eventi
• Migliorata l'accuratezza dei dati e il processo decisionale in tutta la supply chain
• Ottenuta la piena visibilità dei processi tramite dashboard e avvisi
• Standardizzata l'automazione della supply chain e ridotto il lavoro manuale

Whitbread PLC

Whitbread, la più grande azienda di ospitalità del Regno Unito, ha adottato RunMyJobs per supportare il suo panorama SAP. L'organizzazione mirava a ridurre al minimo gli interventi manuali e a migliorare l'affidabilità della pianificazione nelle operazioni finanziarie e di vendita al dettaglio. La migrazione ha permesso a Whitbread di aumentare la resilienza del sistema e gestire i picchi di carico in modo più efficace, in particolare durante i periodi di vendita intensi.⁶

Sfide

Whitbread ha affrontato la doppia sfida di sostituire due sistemi legacy, SAP RemoteWare per i trasferimenti di file e Broadcom AutoSys per la pianificazione dei job, entrambi gestiti da terze parti. Con RemoteWare vicino alla fine del ciclo di vita, il team aveva bisogno di una migrazione a fasi e non disruptiva che rispettasse i rigorosi standard di governance IT e sicurezza. Il loro obiettivo era consolidare le operazioni sotto un'unica piattaforma di automazione affidabile, capace di gestire workload complessi a livello aziendale tra le divisioni retail e hospitality.

Risultati:

• Migrati 1.900 job in 6 mesi con zero problemi post-migrazione
• Consolidati 1.200 job AutoSys a soli 100 utilizzando Redwood
• Ottenuta la piena visibilità di oltre 800 punti vendita aziendali
• Automatizzata la documentazione dei processi e migliorato l'allineamento tra i team
• Integrata la gestione degli incidenti con ServiceNow

UBS

La società globale di servizi finanziari UBS è passata a RunMyJobs per ottenere un migliore controllo sulle sue operazioni distribuite di job batch. Il nuovo sistema ha offerto a UBS una vista unica e centrale dell'esecuzione dei job e ha permesso risposte più rapide agli incidenti. La banca ha beneficiato di una maggiore compliance, di un ridotto rischio operativo e di un reporting migliorato tra i team.⁷

Sfide

UBS lottava con un ambiente di reporting finanziario frammentato e ad alta intensità di lavoro, affidandosi a quasi 100 dipendenti per coordinare manualmente sistemi disconnessi. Con 10 milioni di registrazioni all'ora e la necessità di rendicontare 500 milioni di saldi di conto, gli strumenti legacy non riuscivano a soddisfare le richieste di prestazioni o compliance. I crescenti requisiti normativi (ad es. US GAAP, IAS) e un panorama IT vasto stavano facendo aumentare il TCO, senza che alcun sistema singolo fosse in grado di gestire la scala, fino all'introduzione di Redwood.

Risultati:

• Sostituite 16 applicazioni legacy con una piattaforma di automazione unificata
• Migliorato il costo totale di proprietà (TCO) del 30%
• Ridotto il tempo di reporting esterno da 9 giorni a 5 giorni post-chiusura
• Automatizzata l'elaborazione di oltre 15 miliardi di transazioni in 9 mesi
• Centralizzati i dati finanziari per intuizioni e risposte ai rischi più rapide
• Ottenuto un vantaggio strategico di 5 anni, secondo la leadership di UBS

Scopri altri nostri benchmark e approfondimenti basati sui dati nella Ricerca Google.

Aggiungi come fonte preferita

Cosa considerare prima e durante la migrazione WLA

Migrare workload di automazione critici è un progetto complesso con rischi tecnici, operativi e aziendali. Le considerazioni chiave includono:

Fattori tecnici

• Compatibilità e migrazione dei dati: Le definizioni dei job, le pianificazioni, gli script e le dipendenze devono essere tradotti nel nuovo sistema. Gli script personalizzati o le chiamate API legacy potrebbero richiedere una riscrittura. Assicurarsi che tutti i metadati di pianificazione siano migrati o riconfigurati correttamente.
• Integrazione: Verificare tutte le integrazioni con altri sistemi. Colmare le lacune per evitare interruzioni.
• Strumenti di automazione: Molti vendor forniscono strumenti di migrazione automatizzati che convertono job e flussi di lavoro, coprendo spesso il 70–80% della migrazione. Gli ingegneri dovrebbero gestire i casi limite e testare accuratamente i job critici.

Considerazioni operative

• Rischio di downtime: L'esecuzione di job batch critici o pipeline di dati può essere interrotta. Ridurre il rischio eseguendo i sistemi vecchio e nuovo in parallelo o migrando a fasi.
• Validazione del workload: Verificare che i job migrati si attivino ed eseguano correttamente. Confrontare i log di esecuzione dei sistemi vecchio e nuovo.
• Formazione e trasferimento di conoscenze: Assicurarsi che il personale operativo sia formato sul nuovo sistema per evitare configurazioni errate e risposte lente. Documentare i processi e configurare monitoraggio e avvisi fin dal primo giorno.

Considerazioni aziendali

• Consenso degli stakeholder: Assicurarsi che la leadership e gli utenti finali comprendano lo scopo e i benefici attesi per garantire la cooperazione.
• Costi e ROI: La migrazione include costi di licenza e di progetto. I benefici attesi, come la riduzione del lavoro manuale o nuove funzionalità, dovrebbero superare lo sforzo di migrazione.
• Tempistiche: Evitare conflitti con periodi aziendali critici come le chiusure di trimestre o le stagioni festive.

Best practice per la migrazione WLA

Una preparazione accurata è essenziale per una migrazione WLA fluida. Questi passaggi aiutano le organizzazioni a pianificare, eseguire e validare la transizione con rischio e interruzioni minimi.

1. Audit e valutazione dei workload

Iniziare con un inventario completo di tutti i job, i flussi di lavoro e le dipendenze. Identificare i job critici e complessi, così come eventuali attività ridondanti o obsolete che potrebbero essere rimosse. Questa valutazione definisce l'ambito della migrazione ed evidenzia le aree che richiedono maggiore attenzione.

2. Iniziare la pianificazione presto

Iniziare a valutare le nuove soluzioni WLA ben prima della data di go-live prevista, idealmente sei mesi prima. Una pianificazione anticipata permette di confrontare i vendor, eseguire proof-of-concept e allocare i budget senza fretta.

3. Selezionare il vendor giusto

Non tutte le piattaforme WLA gestiscono la migrazione allo stesso modo. Esaminare le funzionalità, le integrazioni e le capacità di migrazione di ogni vendor. Strumenti di conversione automatizzati o servizi di consulenza possono ridurre significativamente lo sforzo manuale e il rischio. Verificare i riferimenti e i feedback dei clienti per confermarne l'affidabilità.

4. Mappare processi e dipendenze

Documentare come operano oggi i flussi di lavoro, inclusi gli scheduler dei job, i trigger, le dipendenze, gli script e la gestione degli errori. Identificare eventuali soluzioni temporanee o script personalizzati che possono essere semplificati nella nuova piattaforma.

I moderni strumenti WLA offrono spesso funzionalità integrate che sostituiscono i complessi script legacy.

5. Coinvolgere gli stakeholder

Coinvolgere presto l'IT, le operazioni, i proprietari delle applicazioni, gli utenti aziendali e i dirigenti. Spiegare il piano di migrazione, la cronologia e i potenziali rischi. Raccogliere input da tutti i gruppi per assicurarsi che i job critici siano considerati e che tutti comprendano i benefici attesi.

6. Eseguire una migrazione pilota

Prima della migrazione completa, testare un sottoinsieme di workload. Scegliere job che coprano varie funzionalità dello scheduler ma che non siano così critici da causare interruzioni maggiori in caso di errore. Le esecuzioni pilota validano gli strumenti di migrazione, scoprono problemi e consentono al team di familiarizzare con il nuovo sistema.

7. Prepararsi per le esecuzioni parallele

Eseguire i sistemi vecchio e nuovo simultaneamente per un periodo. Durante questa fase, i job vengono eseguiti su entrambe le piattaforme per verifica. Le esecuzioni parallele riducono il rischio, consentono un confronto diretto dei risultati e aumentano la fiducia prima del cutover completo.

8. Formare il proprio team

Assicurarsi che gli amministratori e gli operatori siano formati sulla nuova piattaforma. Utilizzare le risorse del vendor come workshop, corsi online o programmi di certificazione. Coinvolgere il team nella configurazione pratica e nei test durante la migrazione per accelerare l'apprendimento e aumentare la fiducia.

9. Validare i workload

Testare e verificare accuratamente che tutti i job vengano eseguiti correttamente sul nuovo sistema. Controllare pianificazioni, dipendenze, trigger, avvisi, logica di riavvio, fusi orari e calendari festivi. Coinvolgere gli utenti finali o i proprietari delle applicazioni a valle nei test per confermare che gli output corrispondano alle aspettative. Procedere al cutover completo solo quando i risultati sono validati e gli stakeholder approvano.

10. Pianificare il cutover e il supporto post-migrazione

Programmare lo switch finale durante le ore a basso impatto. Mantenere un piano di rollback in caso di problemi. Fornire supporto HyperCare immediatamente dopo il go-live, con personale extra o ingegneri del vendor disponibili per risolvere rapidamente i problemi. Documentare l'intero progetto, raccogliere le lezioni apprese e finalizzare i compiti rimanenti, come la dismissione dei vecchi server.

FAQ

Cita questa ricerca

Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.

@misc{dilmegani2026,
  author = {Dilmegani, Cem},
  title  = {{Migrazione WLA: Best Practice e Approcci dei Vendor}},
  year   = {2026},
  month  = mar,
  howpublished    = {\url{https://aimultiple.com/wla-migration}},
  note   = {AIMultiple. Consultato il 16 Marzo 2026}
}

Collegamenti di riferimento

1.

IT Automation Trends 2026 | Global State of IT Automation Report

2.

Simplify Your Workload Automation Migration With Redwood

3.

Solution BriefWorkload Automation Migration Methodology

4.

Stadtwerke München Case Study

5.

BSH Case Study

6.

Whitbread Case Study

7.

UBS Case Study

Cem Dilmegani

Analista principale

Segui

Cem è analista principale presso AIMultiple dal 2017. AIMultiple fornisce informazioni a centinaia di migliaia di aziende (secondo SimilarWeb), tra cui il 55% delle aziende Fortune 500, ogni mese. Il lavoro di Cem è stato citato da importanti pubblicazioni globali come Business Insider, Forbes, Washington Post, società globali come Deloitte e HPE, ONG come il World Economic Forum e organizzazioni sovranazionali come la Commissione Europea. È possibile consultare l'elenco di altre aziende e risorse autorevoli che hanno citato AIMultiple. Nel corso della sua carriera, Cem ha lavorato come consulente tecnologico, responsabile acquisti tecnologici e imprenditore nel settore tecnologico. Ha fornito consulenza alle aziende sulle loro decisioni tecnologiche presso McKinsey & Company e Altman Solon per oltre un decennio. Ha anche pubblicato un report di McKinsey sulla digitalizzazione. Ha guidato la strategia tecnologica e gli acquisti di un'azienda di telecomunicazioni, riportando direttamente al CEO. Ha inoltre guidato la crescita commerciale dell'azienda deep tech Hypatos, che ha raggiunto un fatturato annuo ricorrente a 7 cifre e una valutazione a 9 cifre partendo da zero in soli 2 anni. Il lavoro di Cem in Hypatos è stato oggetto di articoli su importanti pubblicazioni tecnologiche come TechCrunch e Business Insider. Cem partecipa regolarmente come relatore a conferenze internazionali di settore. Si è laureato in ingegneria informatica presso l'Università di Bogazici e ha conseguito un MBA presso la Columbia Business School.

Visualizza il profilo completo

Sii il primo a commentare

Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.

Nome

Indirizzo e-mail

Commento

0/450

Pubblica un commento