Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / Ti serve davvero un agente Copilot Studio? Come decidono personas e casi d’uso reali (Doppiaggio IA)

Transcript

Ti serve davvero un agente Copilot Studio? Come decidono personas e casi d’uso reali (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

0:00
Speaker 2: Pronto per 10 giorni di Microsoft 365, Copilot, EA, Azure
0:04
Speaker 2: e le persone che stanno plasmando il futuro del lavoro? Eh,
0:08
Speaker 2: questo gennaio M3605 contorna e sarà ancora più grande. Unisciti
0:13
Speaker 2: a noi per sessioni dal vivo, demo reali e conoscenze
0:15
Speaker 2: pratiche da MVP ed esperti del settore in tutto il mondo.
0:18
Speaker 2: Niente slide generic, niente gerbio infinito. Affronteremo le vere sfide.
0:23
Speaker 2: Copilot Studio, agenti IAA, Fabric, Sicurezza, Governance e Automazione. Che
0:30
Speaker 2: tu sia un professionista IT, uno sviluppatore o un leader aziendale,
0:33
Speaker 2: ci sono sessioni pensate per te. Con dieci giorni interi
0:36
Speaker 2: potrai esplorare diverse tecnologie e connetterti con una community globale.
0:40
Speaker 2: Guarda dal vivo e porta spunti pratici nella tua organizzazione.
0:45
Speaker 2: Gennaio 2027, dieci giorni. Un'unica community. Microsoft. Le iscrizioni sono aperte.
0:51
Speaker 2: Prenota il tuo posto oggi stesso. Il sito m300. net Iscriviti
1:00
Speaker 2: ora su m365con. net e ci vedremo dal vivo a gennaio.
1:05
Speaker 2: Hai davvero bisogno del tuo agente Copilot Studio o è
1:07
Speaker 2: solo l'hype dell'IA che parla? Questa è la decisione che
1:10
Speaker 2: quasi ogni azienda deve affrontare in questo momento. Se inizi
1:12
Speaker 2: troppo in fretta con il Copilot sbagliato, sprechi i mesi.
1:15
Speaker 2: Se inizi troppo lentamente, rimani indietro rispetto ai concorrenti che
1:17
Speaker 2: automatizzano in modo più intelligente. In questa sessione ti mostrerò
1:20
Speaker 2: esattamente come abbiamo testato questa domanda in un progetto reale
1:23
Speaker 2: e la sorpresa che abbiamo avuto confrontando una soluzione generica
1:26
Speaker 2: rapida con una creazione dedicata in Copilot Studio. La falsa
1:30
Speaker 2: promessa della soluzione era se il modo più veloce per
1:32
Speaker 2: raggiungere l'IA fosse anche il modo più rapido per bloccarsi.
1:35
Speaker 2: E questa è la trappola in cui cadono molte organizzazioni
1:37
Speaker 2: quando scelgono il primo copilot che viene loro proposto. Sulla
1:40
Speaker 2: carta sembra efficiente. C'è una demo curata, una presentazione chiara.
1:43
Speaker 2: E la promessa che puoi inserire l'IA nei tuoi flussi
1:45
Speaker 2: di lavoro senza pensare troppo alla progettazione. Ma la velocità
1:48
Speaker 2: non è sempre il vantaggio che sembra. Il problema è
1:50
Speaker 2: che queste implementazioni rapide raramente scoprono i bisogni più profondi dell'azienda.
1:54
Speaker 2: Quindi ciò che inizia come una scorciatoia promettente spesso finisce
1:57
Speaker 2: in un vicoloce. Pensa come iniziano la maggior parte dei team.
2:00
Speaker 2: Qualcuno vede un copilot per riassumere email o cercare documenti
2:02
Speaker 2: e sembra fantastico isolatamente. I decisori non sempre si fermano
2:06
Speaker 2: a chiedere se si adatta al lavoro quotidiano dei dipendenti
2:08
Speaker 2: o se si collega ai sistemi che contengono i dati critici.
2:11
Speaker 2: Invece di mappare le attività reali, prendono ciò che è
2:13
Speaker 2: già confezionato. Nelle settimane successive l'IA riceve un po' di attenzione,
2:17
Speaker 2: forse anche entusiasmo, ma poi l'adozione si ferma. Le persone
2:19
Speaker 2: si rendono conto che non aiuta davvero con i problemi
2:21
Speaker 2: che sottraggono ora ogni settimana. Puoi vederlo chiaramente con i
2:24
Speaker 2: team di vendita. Immagina un gruppo che passa la maggior
2:26
Speaker 2: parte del tempo a inseguire lead, preparare preventivi e rispondere
2:29
Speaker 2: alle domande dei clienti. Se la dirigenza offre loro un
2:31
Speaker 2: copilota generico progettato per riformulare email o riassumere note di
2:34
Speaker 2: riunione può suscitare qualche momento di stupore durante una demo.
2:38
Speaker 2: Ma quando il team inizia a chiedere eccezioni sui prezzi
2:40
Speaker 2: o se un cliente ha indeterminati requisiti di conformità il
2:43
Speaker 2: copilota appare improvvisamente superficiale. Non è stato collegato a tabelle
2:47
Speaker 2: dei prezzi, dati CRM o specifici manuali di vendita. Senza
2:50
Speaker 2: tali basi le risposte possono sembrare fluide ma restano inutili
2:53
Speaker 2: nella pratica. Che emergono i limiti naturali degli strumenti di
2:56
Speaker 2: IA generica? Senza conoscenze specifiche del dominio funzionano come brillanti generalisti,
3:01
Speaker 2: competenti nella comunicazione superficiale ma incapaci di fornire profondità quando conta.
3:06
Speaker 2: Gli utenti pongono domande dettagliate e il copilota indovina erroneamente
3:09
Speaker 2: o ricorre a frasi vaghe e inutili. È l'ora che
3:12
Speaker 2: la fiducia si screde. Una volta che i dipendenti smettono
3:15
Speaker 2: di fidarsi di ciò che dice la gente, smettono rapidamente
3:17
Speaker 2: di usarlo del tutto. A quel punto l'intero lancio rischia
3:19
Speaker 2: di essere etichettato come l'ennesimo giocattolo EA invece che come
3:21
Speaker 2: una seria funzionalità. I dati sull'adozione dell'EA confermano questa tendenza.
3:26
Speaker 2: Gli studi che monitorano i lanci aziendali hanno dimostrato che
3:28
Speaker 2: i progetti senza personalizzazione e adattamento al ruolo hanno un
3:30
Speaker 2: utilizzo molto inferiore dopo sei mesi dal lancio. Non perché
3:33
Speaker 2: la tecnologia smetta improvvisamente di funzionare, ma perché l'assenza di
3:36
Speaker 2: contesto la rende irrilevante. Le aziende confondono spesso la qualità
3:40
Speaker 2: della dimostrazione con il valore reale del deployment. Una buona demo,
3:43
Speaker 2: costruita attorno a esempi piccoli e curati. Le operazioni quotidiane,
3:46
Speaker 2: al contrario, portano input più disordinati e richiedono una conoscenza
3:49
Speaker 2: di base strutturata. Quando il copiloto non riesce ad adattarsi,
3:51
Speaker 2: il disallineamento diventa evidente. Allora, perché le aziende continuano a
3:54
Speaker 2: commettere questo errore? In parte è dovuto a lei. L'IA
3:56
Speaker 2: viene commercializzata come una funzionalità plug and play, qualcosa che
3:59
Speaker 2: puoi attivare allo stesso modo di una nuova licenza in
4:00
Speaker 2: Microsoft 365. I leader sotto pressione per mostrare progressi nell'IA
4:05
Speaker 2: spesso danno priorità alla visibilità rapida rispetto all'impatto sostenibile. Distribuiscono
4:09
Speaker 2: qualcosa velocemente, lo mostrano nelle presentazioni e spuntano al casino.
4:12
Speaker 2: Ma la velocità guidata dall'hype non equivale ai risultati misurali.
4:15
Speaker 2: I dipendenti che devono effettivamente usare lo strumento percepiscono immediatamente
4:18
Speaker 2: il divario, anche se le dashboard segnalano un deployment riuscito.
4:21
Speaker 2: Questa differenza tra velocità e progresso crea il vero bivio.
4:24
Speaker 2: Più veloce non significa sempre andare più lontano. Sì, puoi
4:26
Speaker 2: avere un agente funzionante domani se l'asticella è solo apparire
4:29
Speaker 2: dentro Teams o Outlook, ma se diventerà indispensabile dipende interamente
4:32
Speaker 2: dal fatto che sia stato adattato ai ruoli e ai
4:34
Speaker 2: flussi di lavoro reali. L'efficienza non deriva dal premere abilità.
4:38
Speaker 2: Deriva dal porsi la domanda più difficile fin dall'inizio. Abbiamo
4:40
Speaker 2: bisogno di un agente di Copilot Studio che riflette i
4:42
Speaker 2: nostri processi, il nostro linguaggio e i nostri dati. È
4:45
Speaker 2: quello il punto di svolta in cui i progetti si
4:46
Speaker 2: bloccano e si espandono. I team che si fermano a
4:49
Speaker 2: chiederselo possono progettare agenti che i dipendenti vogliono davvero usare
4:52
Speaker 2: perché ne riconoscono l'immediata rilevanza. I team che saltano questo
4:55
Speaker 2: passaggio continuano ad aggiungere strumenti che sembrano familiari ma non
4:57
Speaker 2: danno risultati. L'ironia è che un inizio più lento e
5:00
Speaker 2: ponderato finisce spesso per essere la strada più rapida verso
5:03
Speaker 2: l'adozione perché evita cicli sprecati su soluzioni inadeguate. Il passo
5:07
Speaker 2: successivo consiste nel capire come porsi questa domanda più complessa.
5:10
Speaker 2: Il punto di partenza non è affatto la tecnologia ma
5:12
Speaker 2: le persone. Dobbiamo decidere perché esattamente questa gente. Persona. Perché
5:18
Speaker 2: davvero questa gente? È facile cadere nella trappola di progettare
5:21
Speaker 2: qualcosa per tutti? Sembra inclusivo, forse persino efficiente, ma ciò
5:26
Speaker 2: che produce di solito è così annaquato che nessuno ne
5:28
Speaker 2: trae un vero valore. Nei progetti di intelligenza artificiale con
5:31
Speaker 2: la mentalità tuttofare garantisce quasi certamente una delusione. La prima
5:34
Speaker 2: vera domanda a cui devi rispondere è questa, chi deve
5:36
Speaker 2: aiutare esattamente la gente? Senza saperlo non stai costruendo un copilot,
5:40
Speaker 2: sei solo creando un bot capace di fare conversazione spicciola.
5:43
Speaker 2: Definire le persone non è un esercizio superfluo, è la
5:45
Speaker 2: base che rende possibile il resto del progetto. Quando senti
5:48
Speaker 2: parlare di persona non si tratta di profili di marketing
5:50
Speaker 2: o di personaggi fittizi con hobby e bevande preferite. In
5:53
Speaker 2: questo contesto una persona serve a identificare il ruolo, le
5:56
Speaker 2: responsabilità e l'ambiente della persona a cui si rivolge il
5:58
Speaker 2: tuo agente. Definisce ciò che l'agente deve sapere, come risponde
6:01
Speaker 2: alle domande e persino il tono che deve usare. Un
6:04
Speaker 2: dipendente generico non aiuta la tua IA a capire se
6:06
Speaker 2: deve estrarre dati di conformità in tempo reale o fornire
6:08
Speaker 2: istruzioni passo dopo passo per risolvere un problema. Questa vaghezza
6:12
Speaker 2: è il motivo per cui molti dei primi progetti si
6:14
Speaker 2: sono conclusi con agenti in grado di salutare in cinque
6:16
Speaker 2: modi diversi ma incapaci di risolvere il problema reale di utente.
6:18
Speaker 2: Ecco la differenza che fa nella pratica. Se immagini il
6:21
Speaker 2: dipendente come tua persona, potresti decidere che l'agente debba aiutare
6:25
Speaker 2: con le politiche HR, il supporto IT e le richieste
6:27
Speaker 2: sui documenti, tutto in uno. L'agente deve quindi disperdersi su
6:31
Speaker 2: più ambiti, senza eccellere in nessuno di essi. Confrontalo con
6:35
Speaker 2: la definizione di una persona come un tecnico sul campo
6:37
Speaker 2: che ha bisogno di risposte immediate sulla conformità presso le
6:39
Speaker 2: sedi dei clienti. Immediatamente il design cambia. Sai che questa
6:42
Speaker 2: persona è spesso in movimento, ha poco tempo e necessita
6:44
Speaker 2: di indicazioni chiare e autorevoli. Quella persona ti spinge a
6:48
Speaker 2: collegare il copilot ai database di conformità, a formulare le
6:50
Speaker 2: risposte in modo inequivocabile e a dare priorità alla rapidità
6:53
Speaker 2: rispetto a spiegazioni prolisse. Puoi vedere come l'una sia vaga
6:56
Speaker 2: e dispersiva, mentre l'altra sia abbastanza precisa da guidare allo
6:58
Speaker 2: sviluppo effettivo. La differenza al mondo reale diventa ancora più
7:01
Speaker 2: chiara quando osservi ruoli contrastanti. Prendi la persona di un
7:04
Speaker 2: agente del lab desk. Questo gruppo ha bisogno di rapidi
7:06
Speaker 2: passaggi per la risoluzione dei problemi, aggiornamenti sui guasti del
7:09
Speaker 2: sistema e la possibilità di un'altra etica del sistema. Il
7:11
Speaker 2: linguaggio è tecnico, i dati probabilmente provengono da strumenti come
7:13
Speaker 2: ServiceNow o Intune e gli utenti si aspettano istruzioni precise
7:16
Speaker 2: da seguire sotto pressione. Ora confrontalo con il profilo di
7:19
Speaker 2: un analista finanziario. Questo utente è più interessato ad accedere
7:22
Speaker 2: a modelli finanziari e a comprendere la conformità relativa all'approvazione
7:25
Speaker 2: delle spese o a generare report. Lavorano con numeri, catene
7:29
Speaker 2: di approvazione e terminologia finanziaria e devono potersi fidare che
7:32
Speaker 2: il copilota non esponga dati sensibili al pubblico sbagliato. Progetta
7:35
Speaker 2: per il dipendente generico e finirai per mancare entrami versati.
7:38
Speaker 2: Progetta per ogni specifico profilo e la gente diventerà non
7:41
Speaker 2: solo utile, ma affidabile. Un altro vantaggio trascurato della definizione
7:44
Speaker 2: dei profili è l'allineamento all'interno dell'organizzazione. Ma quando metti sul
7:48
Speaker 2: tavolo un profilo chiaro, i team di risorse umane, IT, conformità, operazioni,
7:51
Speaker 2: possono concordare rapidamente su quale sia l'ambito effettivo. Invece di
7:54
Speaker 2: infiniti dibattiti su cosa potrebbe fare il copilota, tutti hanno
7:57
Speaker 2: ora un punto di riferimento su cosa dovrebbe fare. Diventa
8:00
Speaker 2: una bussola per il processo decisionale. Se stai valutando se
8:03
Speaker 2: aggiungere una funzionalità, puoi verificarla rispetto al profilo. Aiuta il
8:06
Speaker 2: tecnico sul campo a ottenere risposte sulla conformità più rapidamente.
8:08
Speaker 2: Se si ottimo, Se no, allora probabilmente non appartiene alla
8:11
Speaker 2: prima versione. Questo tipo di disciplina impedisce al progetto di
8:14
Speaker 2: trasformarsi in una lista dei desideri privati. I profili vanno
8:16
Speaker 2: anche oltre la guida dell'ambito. Guidano i requisiti di conoscenza.
8:20
Speaker 2: Per ogni profilo devi chiederti di quali informazioni hanno bisogno quotidianamente,
8:24
Speaker 2: dove risiedono attualmente queste informazioni. Quanto velocemente cambia. Quell'analisi determina
8:28
Speaker 2: come integrare le fonti di conoscenza nel copilota e come
8:31
Speaker 2: mantenerlo aggiornato. Signori profili, sovraccaricherai la gente con dati irrilevanti o, peggio,
8:36
Speaker 2: lo priverai dei contenuti di cui ha realmente bisogno. In
8:39
Speaker 2: entrambi i casi la fiducia degli utenti finali svanisce, una
8:42
Speaker 2: volta persa l'adozione non si riprende facilmente. Un profilo ben
8:45
Speaker 2: definito non serve a limitare le possibilità ma a dare
8:47
Speaker 2: una direzione. Senza di esso i progetti di IA vagano
8:50
Speaker 2: inseguendo ogni funzionalità interessante finché non crollano sotto loro stessa ambizione.
8:53
Speaker 2: Con esso è una guida costante? Il profilo diventa la
8:56
Speaker 2: bussola che mantiene il progetto in rotta assicurando che il
8:58
Speaker 2: copilota sia costruito per persone reali, con compiti reali, non
9:01
Speaker 2: per una vaga idea di dipendente. E questa è la
9:05
Speaker 2: differenza tra un agente che viene ignorato dopo il lancio
9:07
Speaker 2: e uno su cui le persone fanno attivamente affidamento. Con
9:10
Speaker 2: i profili definiti il quadro diventa finalmente più nitido. Se
9:13
Speaker 2: è per chi sta lavorando. La domanda successiva naturale è
9:15
Speaker 2: cosa dovremmo aiutarli a fare esattamente. Casi d'uso che contano davvero?
9:20
Speaker 2: Non ogni compito merita un copilota anche se tecnicamente potrebbe
9:22
Speaker 2: averne uno. Che molte organizzazioni si lasciano prendere la mano.
9:25
Speaker 2: Una volta avviato il brainstorming sembra che ogni piccola frustrazione
9:28
Speaker 2: possa diventare una funzione dell'IA. Qualcuno propone e se ci
9:31
Speaker 2: ricordasse di inviare i fogli ora? Un altro aggiunge, magari
9:34
Speaker 2: potrebbe scrivere note di ringraziamento dopo gli incontri con i clienti.
9:37
Speaker 2: In poco tempo la lista è così lunga che nessuno
9:39
Speaker 2: ricorda più quale problema stesse cercando di risolvere. Il pericolo
9:42
Speaker 2: non è avere troppe idee, ma cercare di rendere un
9:44
Speaker 2: solo agente responsabile di tutte. A quel punto il copilota
9:47
Speaker 2: smette di sembrare uno specialista e diventa più simile a
9:49
Speaker 2: uno stagista sopraffatto. La realtà è che le sessioni di
9:52
Speaker 2: brainstorming generano quasi sempre decine di possibili direzioni. L'amministrazione chiede
9:56
Speaker 2: aiuto per le reportiste. Le risorse umane immaginano flussi di onboarding.
9:59
Speaker 2: Le vendite vogliono presentazioni automatizzate. L'IT sogna un triage dei
10:02
Speaker 2: ticket più veloce. Di per sé nessuna di queste è sbagliata,
10:04
Speaker 2: ma la domanda non è. L'IA può farlo? Ha importanza
10:07
Speaker 2: se l'IA lo fa? Quel piccolo cambiamento rivela quante idee
10:13
Speaker 2: sembrano intelligenti ma non offrono quasi alcun ritorno una volta implementate.
10:18
Speaker 2: Solo perché puoi automatizzare questioni secondarie Non significa che valga
10:21
Speaker 2: lo sforzo di costruire, addestrare e mantenere quell'automazione. Se hai
10:24
Speaker 2: mai osservato il risultato di progetti con un ambito eccessivo,
10:27
Speaker 2: il modello è prevedibile. La gente finisce per essere carico
10:30
Speaker 2: di decine di compiti sconnessi, svolgendoli tutti a un livello mediocre.
10:34
Speaker 2: Prendi qualcosa di semplice, come rispondere se una sala riunioni
10:36
Speaker 2: ha un proiettore. Certo, un copiloto può gestire questo tipo
10:39
Speaker 2: di facco con facilità, ma l'impatto è minimo. Confrontalo con
10:43
Speaker 2: un agente che convalida se una proposta di vendita soddisfa
10:45
Speaker 2: rigorosi criteri normativi prima di essere inviata. Il primo evita
10:48
Speaker 2: un po' di fastidio. Il secondo previene rischi legali e
10:51
Speaker 2: accelera i ricavi. Il contrasto mostra perché la definizione delle
10:54
Speaker 2: priorità è importante. Un modo utile per eliminare il rumore
10:57
Speaker 2: di fondo è applicare tre criteri all'inizio. Valore, frequenza e fattibilità.
11:02
Speaker 2: Valore significa chiedersi quanto il compito aiuti davvero l'azienda una
11:05
Speaker 2: volta automatizzato. La frequenza guarda quanto spesso si veri. Risolvere
11:09
Speaker 2: un piccolo problema che accade 50 volte al giorno può
11:11
Speaker 2: contare più di una sfida maggiore che accade solo una
11:13
Speaker 2: volta al trimestre. La fattibilità mantiene onesti i primi due criteri.
11:17
Speaker 2: Se i dati necessari non esistono in formato digitale o
11:19
Speaker 2: non sono accessibili in sicurezza, allora non è un buon
11:21
Speaker 2: candidato per la prima fase. Quando i team valutano ogni
11:24
Speaker 2: caso d'uso attraverso questa lente, le liste dei desideri sovraccariche
11:26
Speaker 2: si restringono improvvisamente in un piano mirato. Ci sono anche
11:29
Speaker 2: prove che i progetti pilota più piccoli con ambiti ristretti
11:31
Speaker 2: funzionino meglio. Le organizzazioni che si impegnano su soli due
11:34
Speaker 2: o tre casi d'uso all'inizio tendono a far crescere l'adozione
11:36
Speaker 2: interna più rapidamente. Funziona proprio così. Il copilota viene lanciato
11:40
Speaker 2: con un valore chiaro in una o due aree. I
11:42
Speaker 2: dipendenti acquisiscono sicurezza e lo slancio aumenta. Confrontalo con agenti
11:46
Speaker 2: che cercano di coprire dieci scenari diversi contemporaneamente. Quei progetti
11:49
Speaker 2: spesso crollano sotto il peso di una qualità incoerente e
11:52
Speaker 2: feedback frustrati. Si scopre che un inizio più mirato crea
11:55
Speaker 2: una base più solida per espandersi in seguito. Consideriamo due
11:59
Speaker 2: team immaginari come esempio. Il primo ha deciso di progettare
12:02
Speaker 2: un copilota che supportasse care, IT, finanza e assistenza clienti
12:04
Speaker 2: tutto in uno. Hanno passato mesi a mappare fonti dati,
12:08
Speaker 2: costruire flussi di lavoro complessi e promettere che sarebbe stata
12:10
Speaker 2: una soluzione unica per l'intera organizzazione. Quando è arrivato il
12:13
Speaker 2: giorno del lancio, i primi utenti hanno scoperto che non
12:14
Speaker 2: riusciva a gestire correttamente le esigenze di nessuno dei repartimenti.
12:17
Speaker 2: La maggior parte ha smesso l'usore di poesia. Il secondo team,
12:19
Speaker 2: al contrario, si è concentrato solo sull'aiutare i tecnici sul
12:21
Speaker 2: campo a confermare le regole di conformità prima delle installazioni.
12:24
Speaker 2: Hanno lanciato in una frazione del tempo, l'adozione è stata
12:26
Speaker 2: immediata e i tecnici hanno iniziato a chiedere nuovi scenari
12:29
Speaker 2: basati sulla loro esperienza positiva. Stessa tecnologia ha risultati molto diversi.
12:34
Speaker 2: Quindi la sfida non è trovare abbastanza casi d'uso, ma
12:36
Speaker 2: resistere alla tentazione di coprerli tutti in una volta. La
12:38
Speaker 2: domanda che conta è, su quali scenari vale la pena scommettere? quali,
12:42
Speaker 2: se automatizzati, diventerebbero uno strumento quotidiano di cui le persone
12:45
Speaker 2: si fidano davvero. È così che separa il rumore dal segnale.
12:48
Speaker 2: I casi d'uso scelti tendono ad essere quelli in cui
12:50
Speaker 2: i dipendenti percepiscono un miglioramento visibile nel modo in cui lavorano,
12:53
Speaker 2: non solo in quanti passaggi vengono automatizzati. Rendono le attività
12:55
Speaker 2: meno frustranti e più affidabili. Il punto fondamentale è che
12:59
Speaker 2: i migliori casi d'uso non si limitano ad automatizzare il lavoro,
13:01
Speaker 2: cambiano davvero la percezione del lavoro per l'utente finale. Quando
13:04
Speaker 2: qualcuno può finalmente dire questo copiloto ha appena reso il
13:06
Speaker 2: mio lavoro meno stressante e trovato la soluzione giusta, Ora
13:09
Speaker 2: che sappiamo per chi progettiamo di cosa hanno veramente bisogno,
13:11
Speaker 2: il passo successivo è capire quali competenze e conoscenze dobbiamo
13:14
Speaker 2: insegnare alla gente affinché possa davvero essere utile. Insegnare alla
13:19
Speaker 2: gente competenze e conoscenze. Una gente non è intelligente finché
13:22
Speaker 2: non gli insegni ciò che il tuo team sa già.
13:23
Speaker 2: E questa è la parte che molti progetti sottovaluta. Installare
13:26
Speaker 2: un copilata standard può darti qualcosa che sembra funzionale, ma
13:29
Speaker 2: se non è stato addestrato con le stesse conoscenze su
13:30
Speaker 2: cui fanno affidamento i tuoi dipendenti, non andrà lontano. Nel
13:33
Speaker 2: migliore dei casi colma alcune superficiali corrisposte raffinate e malaghe.
13:37
Speaker 2: Nel peggiore dei casi fornisce agli utenti una guida inaffidabile
13:40
Speaker 2: e mina completamente la fiducia. Ciò che fa la differenza
13:42
Speaker 2: è la base di conoscenza, alimentare la gente con i
13:45
Speaker 2: dati corretti e collegarla ai flussi di lavoro dove viene
13:47
Speaker 2: il lavoro reale. Pensa al contrasto. Un copilot privo di
13:51
Speaker 2: contesto sa come scrivere un'email professionale perché ha visto milioni
13:54
Speaker 2: di esempi. Ma se qualcuno chiede i termini specifici della
13:57
Speaker 2: politica di rimborso aziendale o cosa rientri nelle spese in
14:00
Speaker 2: conto capitale del sistema finanziario, lo stesso copilot appare improvvisamente vuoto.
14:04
Speaker 2: Potrebbe mettere insieme qualcosa di ragionevole, ma essere ragionevoli non
14:07
Speaker 2: basta quando una formulazione errata crea ritardi, problemi di conformità
14:10
Speaker 2: o perdite di ricavi. Immagina ora un agente collegato direttamente
14:14
Speaker 2: alle basi di conoscenza approvate, ai processi documentati e ai
14:17
Speaker 2: sistemi aggiornati della tua azienda. Non risponde più con risposte generiche.
14:21
Speaker 2: Puoi estrarre regole precise dalle cartelle dei contratti, citare la
14:24
Speaker 2: sezione corretta del manuale di conformità o indirizzare la richiesta
14:27
Speaker 2: attraverso un flusso di lavoro interno. È in quel momento
14:32
Speaker 2: che un copilot passa dall'essere una novità a un collega
14:33
Speaker 2: di cui fidarsi. In Copilot Studio ci sono due modi
14:36
Speaker 2: principali per calibrare questa intelligenza, il grounding della conoscenza e
14:39
Speaker 2: le competenze. Il grounding della conoscenza, la parte in cui
14:41
Speaker 2: colleghi il Copilot alle fonti da cui la tua organizzazione
14:44
Speaker 2: dipende già, può trattarsi di librerie SharePoint dove risiedono le
14:47
Speaker 2: policy o di wiki interni che il personale consulta ogni giorno.
14:50
Speaker 2: Integrandoli nell'ambiente della gente, gli dai la capacità di recuperare
14:53
Speaker 2: e riutilizzare contenuti che corrispondono esattamente ai tuoi requisiti, invece
14:56
Speaker 2: di affidarti a vaghi modelli linguistici che procedono per tentativi.
15:00
Speaker 2: Le competenze rendono il Copilot attivo non solo informativo, Sono
15:03
Speaker 2: i connettori verso API, flussi di lavoro e applicazioni che
15:05
Speaker 2: consentono alla gente di agire, invece di limitarsi a parlare.
15:08
Speaker 2: Ad esempio, il collegamento al ticketing di ServiceNow permette a
15:11
Speaker 2: un supporto IT di aggiornare una data o chiudere ticket direttamente.
15:15
Speaker 2: Invece di riscrivere estratti di policy, il copilot può guidare
15:18
Speaker 2: l'utente nei passaggi necessari, completando l'attività in background. Questa combinazione
15:23
Speaker 2: di grounding della conoscenza e competenze integrate distingue un chatbot
15:26
Speaker 2: da un vero assistente. Un chatbot recita un agente GISH.
15:30
Speaker 2: I rischi derivanti da saltare questo passaggio vengono rapidamente Se
15:32
Speaker 2: un copilot fornisce anche solo una risposta ad alto rischio
15:35
Speaker 2: che risulta errata, gli utenti se lo ricordano. Quel ricordo
15:37
Speaker 2: persiste molto più a lungo di qualsiasi esperienza positiva, specialmente
15:40
Speaker 2: in settori fortemente regolamentati. Basta una sola rassicurazione errata sulla
15:44
Speaker 2: conformità o un rendiconto finanziario impreciso per danneggiare la fiducia
15:47
Speaker 2: che l'intero team ripone nello strumento. Ricostruire l'adozione dopo un
15:51
Speaker 2: simile contraccolpo è molto più difficile che investire in un'adeguata
15:53
Speaker 2: integrazione dei dati fin dall'inizio. Anche quando le basi sono solide,
15:56
Speaker 2: la sfida non finisce qui. Le regole aziendali cambiano, i
15:59
Speaker 2: flussi di lavoro si evolvono, le policy vengono aggiornate. Ciò
16:02
Speaker 2: significa che addestrare una gente non è un compito da svolgere.
16:04
Speaker 2: È un processo iterativo che richiede una calibrazione costante nel tempo.
16:07
Speaker 2: Un nuovo quadro normativo potrebbe richiedere un nuovo grounding. Una
16:10
Speaker 2: migrazione di sistema potrebbe significare aggiornare le competenze. Anche i
16:13
Speaker 2: cambiamenti nel linguaggio, come il modo in cui i team
16:15
Speaker 2: parlano di prodotti o processi, possono compromettere le prestazioni signorati.
16:18
Speaker 2: Questo ciclo di perfezionamento continuo è ciò che distingue i
16:20
Speaker 2: team che ottengono un valore crescente da quelli cui i
16:22
Speaker 2: co- pilot svanisce nell'irrelevanza dopo il lancio. Il vantaggio di insistere
16:25
Speaker 2: è che il tuo co- pilot inizia a lavorare in tempo
16:27
Speaker 2: reale con la stessa profondità che i tuoi esperti apportano
16:29
Speaker 2: ai loro ruoli. Un copilot per le risorse umane può
16:32
Speaker 2: fornire dettagli sulle policy senza dover coinvolgere lo staff HR
16:35
Speaker 2: per ogni piccola domanda. Un copilot finanziario può guidare un
16:38
Speaker 2: analista attraverso le catene di approvazione, estraendo i dati corretti
16:41
Speaker 2: dei sistemi attuali. Questi non sono solo guadagni in termini
16:43
Speaker 2: di efficienza, cambiano il modo in cui le persone percepiscono
16:45
Speaker 2: l'uso dello strumento. Invece di essere un altro sistema con
16:48
Speaker 2: cui lottare, diventa il percorso più rapido verso risposte affidabili
16:50
Speaker 2: e attività completate. Ecco perché il confine tra un chatbot
16:53
Speaker 2: e un copilot è importante. Un chatbot sostiene conversazioni, un
16:57
Speaker 2: copilot prende il contesto, lo combina con le azioni e
16:59
Speaker 2: lo trasforma in un supporto di cui le persone si fidano.
17:02
Speaker 2: Gli agenti più forti sono quelli che rispecchiano ciò che
17:04
Speaker 2: il tuo team già conosce e possono agire su tale
17:06
Speaker 2: conoscenza immediatamente. E una volta definiti design e formazione, la
17:10
Speaker 2: sfida finale diventa come gestire il rollout stesso. Perché un
17:13
Speaker 2: copilot tecnicamente solido può comunque fallire se non supera la
17:15
Speaker 2: fase di adozione. Evitare gli insidi sulla strada verso la
17:19
Speaker 2: messa in produzione. Il modo più comune in cui i
17:21
Speaker 2: progetti di copilot falliscono non è nello sviluppo ma nel rollout.
17:25
Speaker 2: I team spesso passano settimane a perfezionare i profili, creare
17:28
Speaker 2: casi d'uso e collegare le fonti dati solo per vedere
17:30
Speaker 2: l'intera iniziativa bloccarsi al momento di consegnare la gente ai dipendenti.
17:35
Speaker 2: Non perché la tecnologia non funzioni, ma perché il lato
17:37
Speaker 2: umano del roll- out viene spesso trascurato. La governance non è definita,
17:41
Speaker 2: le aspettative non sono gestite e i piani di adozione
17:43
Speaker 2: sono solo un ripensamento. Ciò che inizia con entusiasmo al
17:45
Speaker 2: kick- off spesso si spegne prima che appaiano i risultati reali.
17:48
Speaker 2: Se hai mai visto l'entusiasmo di una riunione di lancio
17:50
Speaker 2: di un progetto, conosci quella sensazione. Una roadmap è alla parete,
17:53
Speaker 2: le tappe fondamentali sono concordate e tutti sono impazienti per
17:55
Speaker 2: la prima demo. Il primo flusso di lavoro viene implementato,
17:58
Speaker 2: il co- pilot risponde alle query di prova e tutto sembra promettente.
18:01
Speaker 2: Ma tra quella demo e il vero lancio, il terreno
18:02
Speaker 2: si sposta. I leader chiedono funzionalità extra a metà progetto,
18:06
Speaker 2: gli utenti finali non sono sicuri di come o quando
18:08
Speaker 2: usare il nuovo strumento e i team di progetto si
18:10
Speaker 2: rendono conto di non aver mai definito chi revisiona le
18:12
Speaker 2: modifiche o prova i dati di addestramento. Il divario tra
18:15
Speaker 2: la costruzione e il roll- out è dove lo slancio muore silenziosamente.
18:18
Speaker 2: Pensa a un agente che funzionava perfettamente durante i test
18:20
Speaker 2: interni ma che è inciampato al momento del rilascio. I
18:23
Speaker 2: dipendenti l'hanno aperto una o due volte e non hanno
18:24
Speaker 2: capito quali problemi risolvesse e se ne sono andati poco impressionati.
18:27
Speaker 2: In alcuni casi il team di sviluppo si è concentrato
18:29
Speaker 2: talmente tanto sulla precisione tecnica da non preparare mai un
18:32
Speaker 2: piano di comunicazione. Gli utenti finali davano per scontato che
18:35
Speaker 2: Copilota potesse rispondere a qualsiasi domanda sul loro ruolo. Invece
18:37
Speaker 2: quando hanno posto la prima domanda non supportata l'agente ha
18:39
Speaker 2: risposto in modo vago. Il singolo momento è bastato a
18:42
Speaker 2: minare la fiducia. L'adozione non si è più ripresa perché
18:45
Speaker 2: il lancio non era progettato per gestire la percezione e
18:47
Speaker 2: il feedback degli utenti. L'ampliamento incontrollato dell'ambito aggiunge un'ulteriore difficoltà.
18:51
Speaker 2: Supponiamo che un progetto puntasse inizialmente a due scenari ad
18:54
Speaker 2: alto valore per gli analisti finanziari. A metà percorso iniziano
18:57
Speaker 2: ad arrivare richieste a pioggia. Può anche aiutare le risorse
18:59
Speaker 2: umane all'inserimento dei nuovi dipendenti o magari offrire passaggi per
19:02
Speaker 2: le risoluzioni di problemi. La licenza vuole mostrare un impatto
19:04
Speaker 2: su tutti i dipartimenti, quindi queste richieste vengono aggiunte. Ora
19:07
Speaker 2: il team di progetto è sotto pressione, le scadenze slittano
19:09
Speaker 2: e i casi d'uso iniziali ad alto valore finiscono per ritardare.
19:12
Speaker 2: Quando i test terminano, il copilota cerca di seguire cinque
19:15
Speaker 2: direzioni contemporaneamente e non ne soddisfa nessuna. Il lancio viene
19:18
Speaker 2: posticipato di nuovo. La fiducia nel progetto scema e la
19:21
Speaker 2: promessa iniziale non si concretizza mai. Evitare questa spirale richiede
19:24
Speaker 2: una struttura. Un metodo comprovato sono i lanci graduali. Invece
19:28
Speaker 2: di imporre la gente all'intera azienda in una volta sola,
19:31
Speaker 2: iniziate con un piccolo gruppo pilota che rappresenti la figura chiave.
19:34
Speaker 2: Raccogliete i loro feedback, monitorate i tipi di domande e
19:36
Speaker 2: misurate i tassi di adozione in un ambiente controllato. Se
19:39
Speaker 2: pergono problemi è possibile apportare modifiche in modo discreto prima
19:41
Speaker 2: di passare alla scala principale. Inoltre, definire misure di successo
19:44
Speaker 2: trasparenti aiuta a mantenere l'entusiasmo ben radicato. Se il successo
19:48
Speaker 2: è definito come il 50% dei ticket risolti senza intervento
19:51
Speaker 2: umano o controlli di conformità completati in meno di due minuti,
19:54
Speaker 2: allora tutti possono vedere i progressi in termini chiari invece
19:56
Speaker 2: che con affermazioni vaghe. I buoni progetti di EA hanno
19:59
Speaker 2: anche dei champion, persone che fungono da traduttori interni tra
20:02
Speaker 2: il team tecnico e la base di utenti abituali. Questi
20:04
Speaker 2: champion aiutano a definire le giuste aspettative, mostrando ai colleghi
20:07
Speaker 2: dove il copiato eccelle e dove invece no. Invece di
20:10
Speaker 2: promettere che l'IA risolverà tutto, spiegano quali compiti specifici supporta
20:14
Speaker 2: perché quelli sono stati scelti come priorità. Questo tipo di
20:17
Speaker 2: supporto ha più peso se arriva dai colleghi piuttosto che
20:19
Speaker 2: dagli annunci che appaiono in un newsletter aziendale. Costruisce credibilità
20:23
Speaker 2: persona per persona al che scala l'adozione in un modo
20:25
Speaker 2: che nessun annuncio da solo può ottenere. Lo slancio dopo
20:28
Speaker 2: la prima demo deriva dal gestire questo equilibrio tra ambizione
20:30
Speaker 2: e realtà. La gente non dovrebbe restare nascosta in un
20:33
Speaker 2: laboratorio di innovazione senza visibilità, ma non può nemmeno essere
20:35
Speaker 2: lanciato a tutta la forza lavoro senza essere testato. I
20:37
Speaker 2: lanci che hanno successo di solito prevedono una sequenza paziente. sperimentare,
20:40
Speaker 2: espandere e poi integrare nel flusso di lavoro quotidiano.