Latest / M365.FM – Podcast de Microsoft 365, Copilot e IA em português / Fabric Data Activator: automação em tempo real em vez de ficar olhando dashboards (Dublagem IA)

Transcript

Fabric Data Activator: automação em tempo real em vez de ficar olhando dashboards (Dublagem IA) · M365.FM – Podcast de Microsoft 365, Copilot e IA em português

0:00
Pronto para 10 dias de Microsoft 365, Copilot, IA, Azure e as pessoas que estão moldando o futuro do trabalho.
0:07
Em janeiro, a M3106 Cucon está de volta e ainda maior.
0:12
Junte-se a nós para as sessões ao vivo, demonstrações reais e conhecimento prático com MVPs e especialistas do setor em todo o mundo.
0:18
Nada de slides genéricos, nada de jargões em terminário.
0:21
Estamos enfrentando os desafios reais.
0:23
Copilot Studio, agente de IA, fábrica, segurança, governança e automação.
0:28
Seja você um profissional de TI, desenvolvedor ou líder de negócios, há sessões projetadas para você.
0:35
Com 10 dias inteiros, você pode explorar várias tecnologias e se conectar com uma comunidade global.
0:40
Assista ao vivo e leve insights práticos para sua organização.
0:45
Janeiro de 2027, 10 dias, uma única comunidade de Microsoft.
0:49
As inscrições já estão abertas.
0:51
Garanta sua vaga hoje mesmo.
0:52
Acesse m3m5.net
0:57
Inscreva-se agora em m365.net
1:03
E nos vemos ao vivo em janeiro.
1:05
Já se perguntou se seus dados poderiam agir sem que você precisasse tocá-los?
1:08
Imagine detectar uma queda no estoque em tempo real.
1:11
Em vez de enviar um e-mail ou verificar um painel, seu sistema simplesmente faz o pedido para você.
1:15
Isso não é hipotético.
1:17
Isso é o Fabric Data Activator em ação.
1:19
Hoje, vamos conectar os pontos entre dados brutos, alertas instantâneos e respostas automatizadas
1:24
e mostrar como ele interage com o Power BI, Synapse e o restante do Microsoft Fabric
1:29
para transformar em sites em ação, sem demora.
1:32
Sem demora.
1:34
Belo perdido no seu ciclo de dados.
1:35
A maioria das equipes dirá que opera em tempo real,
1:38
mas ao olhar sob o capô as coisas parecem muito mais com o dia seguinte.
1:43
Os painéis são atualizados a cada 15 ou 30 minutos, às vezes apenas uma vez por hora.
1:47
Até lá, o padrão que se precisava captar já mudou e o relatório que você está vendo
1:52
é mais uma análise pós-jogo do que uma transmissão ao vivo.
1:56
A lance depois que o placar final já foi definido.
1:59
O problema não é que as ferramentas de BI não mostram o que está acontecendo.
2:02
Elas geralmente são muito boas nisso.
2:03
A peça que falta é o que acontece depois que você vê o que está acontecendo.
2:07
Atualmente, a maioria dos fluxos de trabalho depende de um humano para anotar a mudança,
2:11
decidir qual ação tomar e, então, executá-la.
2:14
Isso cria um gargalo.
2:15
Até algo básico, como enviar um e-mail para clientes quando uma certa métrica cai,
2:19
acaba sendo um trabalho manual porque o sistema não está configurado
2:22
para conectar o Insight diretamente à ação.
2:26
Esse atraso onde tantas oportunidades simplesmente esfria.
2:29
Uma promoção lançada três horas atrasada após uma queda nas vendas perde-surgens.
2:33
Um pico de erros no site que fica sem solução até a próxima reunião de revisão
2:37
acaba custando conversões que nunca recuperaremos.
2:40
O intervalo entre saber e agir é exatamente onde o Fabric Data Activator atua
2:44
e ele foi projetado para reduzir essa lacuna a segundos.
2:48
Como ele reside nativamente no Microsoft Fabric,
2:50
o Data Activator dispensa a necessidade de exportar, conectar ou gerenciar fontes de dados constantemente.
2:56
Ele lê fluxos de eventos à medida que acontecem e reage instantaneamente
2:59
quando uma condição definida por você é atendida.
3:01
A diferença é que em vez de parar em um alerta,
3:04
ele pode iniciar uma reação em cadeia no restante dos seus sistemas.
3:07
Imagine isto, um feed de vendas ao vivo monitora o desempenho em diferentes regiões.
3:12
Normalmente, você notaria uma queda repentina em uma região no seu painel,
3:15
investigaria, criaria uma oferta direcionada,
3:18
obteria aprovação e publicaria a promoção.
3:20
Isso poderia levar uma hora.
3:23
Com o Data Activator, essa mesma queda pode acionar uma chamada de API pré-aprovada
3:27
para seu sistema de automação de marketing lançando uma oferta direcionada em minutos
3:30
antes mesmo que os concorrentes percebam a fraqueza.
3:34
Sem esperar que a pessoa certa perceba, sem demora para deliberar sobre uma ação óbvia.
3:39
Essa é a verdadeira mudança.
3:40
Ferramentas de BI tradicionais rastreiam.
3:42
O Data Activator ouve e responde.
3:44
Com uma cadência típica de atualização do Power BI,
3:46
de, digamos, a cada 30 minutos, a detecção por si só já pode estar atrasada
3:50
desde o momento em que a mudança começou.
3:52
Pô.
3:53
Os gatilhos do Data Activator podem agir sob fluxos de eventos em tempo quase real,
3:58
na ordem de segundos, dependendo da fonte,
4:00
fazendo com que o momento da ação fique muito mais próximo do evento que o disparou.
4:05
E como ele está integrado à fábrica e não se limita a um único painel ou conjunto de dados,
4:09
ele pode se conectar a qualquer parte do ecossistema que faça sentido.
4:13
Esse feed de streaming pode ser parte de um pipeline de dados do Synapse,
4:18
que alimenta vários modelos downstream e de IA.
4:22
Se algo importante acontece, o Data Activator não apenas avisa o seu painel.
4:26
Ele envia o sinal para os sistemas capazes de corrigir ou explorar a oportunidade imediatamente, imediatamente.
4:32
Esta é a ponte entre a observação e a execução.
4:34
Em vez de encher o chat da sua equipe com mensagens que eles só verão depois do almoço,
4:38
ele executa o próximo passo ali mesmo, na hora.
4:42
Ele transforma cada evento qualificado em uma decisão já tomada,
4:45
em uma ação já realizada.
4:47
Ao comparar com o fluxo de trabalho de B e padrão, a vantagem é óbvia.
4:51
Monitorar sozinho apenas conta a história.
4:54
Monitorar somado à resposta altera o resultado.
4:57
E em um cenário onde as janelas de oportunidade fecham rapidamente,
4:59
essa diferença é mais que conveniência e competitividade.
5:03
A seguir, veremos como isso se encaixa naturalmente nas ferramentas com as quais você já trabalha,
5:08
sem adicionar outra camada de complexidade para gerenciar.
5:10
Mais do que apenas alertas, a rede do Fábio.
5:14
Enviar mais um ping no Teams não é automação, é apenas mais ruído.
5:17
Você sabe do que eu tô falando.
5:18
Uma enxurrada de pop-up surgindo em todas as telas,
5:21
cada um exigindo que você veja algo que pode ou não ser importante.
5:24
No início, há a sensação de estar no controle,
5:26
mas logo sua equipe começa a ignorá-los e os alertas importantes acabam enterrados no caos.
5:32
A ironia é que os sistemas feitos para mantê-lo informado
5:34
acabam muitas vezes tornando mais cego, mais cego.
5:38
Todos nós já participamos daquela reunião de segunda-feira
5:40
onde alguém menciona que perdeu um problema grave de um cliente
5:42
simplesmente porque o alerta aparecia com todos os outros.
5:45
A raiz do problema não é a falta de detecção,
5:47
é a falta de inteligência sobre o que fazer a seguir.
5:50
Gatilhos excessivamente sensíveis tratam cada pequena flutuação como uma crise.
5:54
Isso cria uma cultura onde todos são treinados para ignorá-los.
5:58
É aqui que o Data Activator do Microsoft Fabric,
6:00
junto com o restante do Fabric, começa a fazer a diferença.
6:04
Ele não é apenas um complemento.
6:05
Opera lado a lado com o Power BI, o Synapse e o armazenamento de dados do Fabric.
6:10
Isso significa que ele atua no mesmo ambiente
6:12
que as ferramentas que já executam suas análises e pipelines.
6:15
Em vez de notificar toda vez que uma métrica oscila,
6:17
ele pode decidir se a oscilação justifica parar a operação.
6:20
Pense nele como um operador de central telefônica à moda antiga,
6:23
mas que realmente entende a urgência por trás de cada chamada.
6:26
Quando algo acontece, como um feed de dados enviando um sinal
6:29
de que o formato de nome do seu produto quebrou durante o carregamento,
6:31
o Data Activator sabe quais conexões levam ao sistema certos.
6:35
Ele não envia à equipe de marketing uma notificação que eles só lerão amanhã.
6:38
Ele encaminha o problema diretamente para o sistema
6:40
que pode congelar o carregamento defeituoso
6:42
antes que ele corrompa os relatórios subsequentes.
6:45
Este é um exemplo prático.
6:46
Um pipeline do Synapse está extraindo dados de transações financeiras
6:49
a cada poucos segundos.
6:51
Um dos sistemas upstream começa a enviar registros duplicados
6:53
devido a uma falha no fornecedor.
6:56
Se você estiver usando apenas alertas,
6:57
verá uma mensagem no Teams ou um e-mail dizendo
6:59
Olá, contagem de duplicatas detectada.
7:00
Com o Data Activator, ele pode pausar o pipeline
7:05
assim que as duplicatas chegam,
7:07
dando aos seus engenheiros de dados tempo
7:09
para corrigir a fonte antes que os dados ruins
7:11
entrem no seu warehouse.
7:13
A correção acontece no nível do sistema,
7:15
não porque alguém estava checando o painel por acaso.
7:18
Essa é uma diferença fundamental.
7:19
O Data Activator não está vinculado
7:20
a um único conjunto de dados ou fluxo restrito.
7:22
Ele funciona com vários tipos de entrada.
7:25
Tabelas de warehouses estruturadas, fluxos de eventos
7:27
e outras fontes de dados conectadas ao fábrica,
7:29
aplicando as mesmas regras lógicas sem que você precise monitorá-las.
7:33
Esse escopo entre serviços significa que ele não apenas sabe quando algo está errado.
7:37
Ele sabe exatamente onde pisar no freio ou acelerar.
7:41
E como ele vive dentro do mesmo ecossistema,
7:42
que sua lógica de transformação e armazenamento,
7:44
ele não luta contra os fluxos de dados.
7:47
Ele está incorporado a eles.
7:48
É por isso que você pode criar uma cadeia onde ingestão,
7:51
transformação, validação e resolução acontecem em um único fluxo
7:53
sem que as pessoas precisem se procurar para passar tarefas adiante.
7:57
É a diferença entre reagir aos dados e ter seu sistema se adaptando
7:59
durante o processo para manter a qualidade e a pontualidade intactas.
8:04
Mas o verdadeiro benefício começa a surgir quando você não vê isso
8:07
como uma ferramenta de alerta,
8:08
mas como uma camada de tomada de decisão operacional.
8:11
Ele responde com base no contexto,
8:12
o que reduz drasticamente o volume de ruído
8:14
enquanto aumenta a porcentagem de alertas
8:17
que realmente acionam uma ação significativa.
8:19
Você não fica mais sobrecarregado.
8:23
Você obtém sinal em vez de ruído com menos trabalho humano.
8:27
E como essas decisões podem desencadear mudanças reais
8:29
para usar tarefas, atualizar registros, iniciar correções,
8:32
isso não apenas reduz o atraso entre saber e agir.
8:36
Isso elimina lacuna completamente.
8:38
Agora vamos entrar na parte que chama atenção,
8:40
chamar a API sem interagir com o mundo fora da Microsoft.
8:43
Quando o interior chama o mundo exterior,
8:45
seus dados podem fazer um telefonema
8:46
antes mesmo de você ver a chamada perdida.
8:48
Isso não é uma força de expressão,
8:50
estamos falando de pegar o mesmo fluxo de eventos
8:52
que você já rastreia
8:53
e deixá-lo acionar algo fora do ecossistema Microsoft Fabric
8:56
em tempo real.
8:58
Em vez de esperar que você leia um painel
9:00
ou clique em um alerta do Teams,
9:02
o próprio sistema disca metafórica,
9:05
ou literalmente,
9:06
para iniciar uma ação em outro aplicativo ou serviço
9:09
no momento em que a condição é atendida.
9:11
A maioria das configurações de BI fala exatamente isso.
9:14
Elas são excelentes em revelar em sites,
9:16
às vezes até com visuais chamativos
9:17
e comentários assistidos por IA,
9:18
mas entregam a bola para você
9:19
e esperam que você corra com ela.
9:22
Você ainda precisa abrir o CRM
9:24
e enviar o pedido, atualizar o RP
9:25
ou iniciar o processo manualmente.
9:28
Essa lacuna onde o gargalo humano aparece novamente,
9:31
você pode detectar o problema em minutos,
9:33
mas a execução acontece horas depois
9:34
porque está esperando que alguém esteja livre para agir.
9:38
Com o Data Activator,
9:39
essa etapa não é apenas reduzida,
9:40
ela desaparece.
9:41
Imagine os níveis de estoque
9:43
caindo abaixo do seu limite de reposição no meio do dia.
9:47
Em uma configuração normal,
9:48
alguém na operação percebe isso no Power BI,
9:50
envia um aviso para o setor de compras
9:51
e aguarda a confirmação.
9:52
E a confirmação.
9:53
Enquanto isso,
9:54
você continua vendendo o produto
9:55
e caminhando para uma ruptura de estoque.
9:58
Em vez disso,
9:58
o Data Activator pode enviar uma chamada de API
10:00
direto para o sistema de pedidos do seu fornecedor
10:02
no momento em que os dados cruzam esse limite.
10:05
O pedido de compra, entrega, entra na fila,
10:06
ninguém da sua equipe leu o alerta ainda
10:08
e a correção já está em andamento.
10:11
Esse é o valor de realizar chamadas externas
10:12
diretamente dentro do fábrico.
10:14
Você não está limitado às ferramentas da Microsoft,
10:17
sejam CRM SASE,
10:18
um RP legado,
10:18
um Endpoint REST personalizado
10:20
ou até a API de um parceiro.
10:21
Você pode conectar esse gatilho em tempo real
10:23
para reduzir a distância entre a detecção
10:25
e a resolução.
10:27
A saída pode ser tão simples
10:29
quanto enviar dados para um webhook
10:31
ou tão estruturada
10:32
quanto enviar um payload formatado
10:33
que aciona um fluxo de trabalho
10:34
de várias etapas
10:35
em uma plataforma completamente diferente.
10:39
Este é o ponto em que o fábrico
10:40
deixa de ser apenas um conjunto
10:42
de ferramentas de análise
10:43
e passa a se comportar
10:44
como o sistema nervoso central
10:45
do seu ambiente operacional.
10:48
Quando um evento ocorre,
10:49
o nervo não apenas envia um sinal
10:50
para seus olhos,
10:51
ele envia instruções para os membros
10:53
que podem agir imediatamente.
10:55
Imediatamente.
10:55
É assim que você passa
10:56
do monitoramento de operações
10:57
para uma situação em que ela se autorregula
10:59
em grande parte.
11:00
Você pode ver isso em setores
11:01
com forte presença de IoT.
11:02
Imagine uma fábrica
11:04
com sensores de vibração
11:06
instalados em maquinário crítico.
11:08
Esses sensores transmitem dados
11:10
para o fábrico em tempo real.
11:11
No momento em que uma leitura
11:12
entra na faixa de aviso de falha,
11:13
o Data Activator pode criar
11:15
e atribuir uma ordem de serviço
11:16
no Dynamics 365,
11:18
agendando o engenheiro
11:19
antes mesmo que a máquina
11:20
chegue perto de falhar.
11:21
Nenhum supervisor
11:23
precisa interromper o dia
11:24
para fazer a ligação,
11:25
o sistema em caminho
11:25
trabalha automaticamente
11:26
com todo o contexto
11:27
que o técnico precisa.
11:30
O trabalho de reparo
11:31
começa antes mesmo
11:31
que o tempo de inatividade
11:32
vire assunto.
11:34
A combinação de monitoramento
11:35
automatizado e APS saída
11:36
é onde a verdadeira autonomia
11:37
entra em ação.
11:39
Você não está apenas
11:39
filtrando alertas por relevância,
11:41
você está conectando
11:41
esses gatilhos filtrados
11:42
a ações tangíveis
11:43
que acontecem imediatamente.
11:45
Esse é o salto
11:45
se orientado por dados
11:46
para ser ativado por dados,
11:48
onde a capacidade de resposta
11:49
do sistema é tão rápida
11:50
quanto sua capacidade de detecção.
11:52
Quando você configura corretamente,
11:53
seus processos não apenas
11:54
dispensam o microgerenciamento humano.
11:56
Eles melhoram ativamente
11:57
porque o ciclo entre detecção e ação
11:59
é estreito, consistente
12:01
e sempre ativo.
12:03
Você pode se concentrar
12:04
em projetar melhores regras
12:05
e lógica em vez de se preocupar
12:06
se alguém viu o alerta.
12:08
Mas até o sistema nervoso
12:09
mais responsivo possui limites
12:11
que você não pode ignorar.
12:12
E se você nos conhecer
12:13
antes de começar,
12:14
os resultados podem se tornar
12:15
caóticos rapidamente.
12:17
Conhecer as fronteiras
12:17
antes de construir
12:18
todo o herói da automação
12:20
tem uma história de origem
12:21
e uma lista de problemas
12:23
que gostaria de ter previsto.
12:25
Com o Data Activator,
12:26
a realidade é que,
12:27
embora a ideia de detecção
12:29
mais reação pareça ilimitada,
12:30
existe uma estrutura
12:31
muito prática por baixo dela.
12:33
Não é mágica.
12:34
Ainda está sendo executado
12:35
na arquitetura do Fabric,
12:36
limitado pelos mesmos
12:37
modelos de capacidade,
12:38
limites de serviço
12:39
e premissas de design
12:40
que se aplicam
12:41
a todo o restante do ecossistema.
12:44
Ignore esses limites
12:44
e você descobrirá rapidamente
12:46
o que acontece
12:46
quando uma automação
12:47
bem-intencionada
12:48
para de funcionar.
12:50
A parte complicada
12:51
é que os pontos de falha
12:52
geralmente não aparecem
12:53
durante a sua prova de conceito.
12:54
Em um teste pequeno,
12:55
tudo parece instantâneo.
12:57
As condições são acionadas,
12:58
as ações disparadas,
12:59
você vê o resultado
12:59
quase imediatamente.
13:01
É quando você escala,
13:02
conectando vários sistemas externos,
13:04
aumentando o volume de gatilhos
13:05
e adicionando lógica complexa
13:06
que as restrições aparecem.
13:08
A latência aumenta,
13:10
o uso da capacidade dispara.
13:11
De repente,
13:12
aquele mecanismo
13:13
de decisão em tempo real
13:14
é limitado ou colocado
13:15
em uma fila.
13:17
Pense no que acontece
13:18
quando um gatilho
13:19
depende de uma fonte
13:19
que está tecnicamente conectada,
13:21
mas não roda
13:21
dentro dos serviços
13:22
nativos do fabric.
13:24
Talvez se tenha um fluxo
13:25
de dados vindo de um hub
13:26
de eventos externo
13:27
que alimenta seus relatórios.
13:30
Se o Data Activator
13:30
depende desse feed
13:32
para disparar um processo crítico,
13:33
mas o intervalo de processamento
13:34
na origem é mais lento
13:35
que o tempo de reação
13:36
do fabric,
13:37
você nunca terá
13:39
a resposta que espera.
13:41
Já vi implementações
13:42
travarem porque as condições
13:43
foram criadas
13:43
sobre dados semi-estáticos
13:44
que simplesmente
13:45
não acompanhavam
13:45
a lógica do gatilho.
13:47
A automação não falhou,
13:48
ela apenas chegou tarde demais
13:49
para importar.
13:50
Existe também
13:51
a tentação de monitorar tudo.
13:52
Bem,
13:52
isso faz sentido no início.
13:54
Mais condições de monitoramento
13:55
deveriam significar
13:56
mais oportunidades de reação,
13:58
mas cada gatilho
13:59
que você define
13:59
contribui para a carga
14:00
de trabalho executada
14:01
em sua capacidade do fabric.
14:03
Isso significa
14:03
que você está consumindo
14:04
a mesma capacidade
14:05
que suporta
14:05
suas atualizações de BI,
14:07
seus fluxos de dados
14:07
e suas consultas de warehouse.
14:10
Se forçar demais,
14:11
verão o efeito dominó
14:12
onde outras cargas de trabalho
14:13
ficam lentas
14:14
porque seus gatilhos
14:14
estão consumindo
14:15
todo o processamento.
14:17
Planejamento de capacidade
14:18
não é opcional aqui,
14:18
pois é a disciplina
14:19
que evita que a automação
14:20
se transforme
14:20
em um tempo
14:21
de inatividade auto-infligida.
14:22
As metas de latência
14:23
vem só agora.
14:24
O Detectivator pode reagir
14:25
em segundos,
14:26
mas apenas se os sistemas
14:27
upstream e downstream
14:27
puderem lidar
14:28
com essa velocidade.
14:29
Se sua chamada de API disparada
14:31
aponta para uma integração
14:32
de RP processada
14:33
em lote a cada 15 minutos,
14:34
você efetivamente
14:35
criou atrasos embutidos.
14:38
O gatilho é executado,
14:39
mas o resultado final
14:40
ainda aguarda
14:40
pelo próximo lote.
14:42
Essas diferenças
14:42
no ritmo de serviço
14:43
precisam ser mapeadas
14:44
antes de começar
14:45
a conectar os sistemas.
14:47
O caminho mais seguro
14:47
é começar com condições
14:49
de alto valor
14:49
e baixa frequência.
14:51
Isso significa
14:51
escolher cenários
14:52
onde,
14:53
mesmo que você dispare
14:53
apenas algumas vezes
14:54
ao dia,
14:55
cada um tem um impacto
14:56
claro que justifique
14:56
a automação.
14:58
Trata-se de provar
14:58
eficácias
14:59
sem inundar
15:00
sua capacidade
15:01
de sobrecarregar
15:01
os serviços downstream.
15:03
Você ajusta
15:04
a lógica do gatilho,
15:05
entende o perfil
15:06
de processamento
15:06
e só então
15:07
começa a expandir.
15:09
Vale lembrar também
15:10
que preços
15:10
e capacidade
15:11
não se referem
15:11
apenas a armazenamento
15:13
ou atualizações.
15:15
A avaliação de gatilhos
15:16
e a execução de ações
15:17
consome recursos
15:17
do mesmo conjunto.
15:18
Aquela chamada
15:19
de API de saída
15:19
é processamento.
15:21
A transformação
15:21
que você executa
15:22
antes de verificar
15:22
uma condição
15:23
também consome processamento.
15:25
Se você escalar
15:26
condições e conexões
15:27
sem levar em conta
15:27
o pool de suas unidades
15:28
de fábrica
15:29
atingirá os limites
15:30
mais rápido
15:30
do que espera.
15:32
Boa notícia
15:33
é que uma vez
15:33
que você sabe
15:33
onde estão os limites
15:34
e pode projetar soluções
15:35
contornando-nos?
15:36
Você cria processos
15:37
que se auto...