WEBVTT

00:00:00.270 --> 00:00:06.690
Pronto para 10 dias de Microsoft 365, Copilot, IA, Azure e as pessoas que estão moldando o futuro do trabalho.

00:00:07.410 --> 00:00:11.910
Em janeiro, a M3106 Cucon está de volta e ainda maior.

00:00:12.870 --> 00:00:18.090
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.

00:00:18.830 --> 00:00:21.230
Nada de slides genéricos, nada de jargões em terminário.

00:00:21.870 --> 00:00:23.190
Estamos enfrentando os desafios reais.

00:00:23.690 --> 00:00:28.750
Copilot Studio, agente de IA, fábrica, segurança, governança e automação.

00:00:28.750 --> 00:00:34.150
Seja você um profissional de TI, desenvolvedor ou líder de negócios, há sessões projetadas para você.

00:00:35.430 --> 00:00:39.950
Com 10 dias inteiros, você pode explorar várias tecnologias e se conectar com uma comunidade global.

00:00:40.930 --> 00:00:44.130
Assista ao vivo e leve insights práticos para sua organização.

00:00:45.090 --> 00:00:48.790
Janeiro de 2027, 10 dias, uma única comunidade de Microsoft.

00:00:49.370 --> 00:00:50.470
As inscrições já estão abertas.

00:00:51.770 --> 00:00:52.970
Garanta sua vaga hoje mesmo.

00:00:52.970 --> 00:00:57.810
Acesse m3m5.net

00:00:57.810 --> 00:01:03.040
Inscreva-se agora em m365.net

00:01:03.040 --> 00:01:04.800
E nos vemos ao vivo em janeiro.

00:01:05.300 --> 00:01:07.940
Já se perguntou se seus dados poderiam agir sem que você precisasse tocá-los?

00:01:08.300 --> 00:01:10.260
Imagine detectar uma queda no estoque em tempo real.

00:01:11.460 --> 00:01:15.200
Em vez de enviar um e-mail ou verificar um painel, seu sistema simplesmente faz o pedido para você.

00:01:15.940 --> 00:01:16.860
Isso não é hipotético.

00:01:17.520 --> 00:01:19.260
Isso é o Fabric Data Activator em ação.

00:01:19.260 --> 00:01:24.920
Hoje, vamos conectar os pontos entre dados brutos, alertas instantâneos e respostas automatizadas

00:01:24.920 --> 00:01:29.300
e mostrar como ele interage com o Power BI, Synapse e o restante do Microsoft Fabric

00:01:29.300 --> 00:01:31.760
para transformar em sites em ação, sem demora.

00:01:32.280 --> 00:01:32.880
Sem demora.

00:01:34.000 --> 00:01:35.240
Belo perdido no seu ciclo de dados.

00:01:35.820 --> 00:01:38.100
A maioria das equipes dirá que opera em tempo real,

00:01:38.300 --> 00:01:42.760
mas ao olhar sob o capô as coisas parecem muito mais com o dia seguinte.

00:01:43.500 --> 00:01:47.320
Os painéis são atualizados a cada 15 ou 30 minutos, às vezes apenas uma vez por hora.

00:01:47.320 --> 00:01:52.000
Até lá, o padrão que se precisava captar já mudou e o relatório que você está vendo

00:01:52.000 --> 00:01:55.060
é mais uma análise pós-jogo do que uma transmissão ao vivo.

00:01:56.100 --> 00:01:58.040
A lance depois que o placar final já foi definido.

00:01:59.380 --> 00:02:01.800
O problema não é que as ferramentas de BI não mostram o que está acontecendo.

00:02:02.300 --> 00:02:03.520
Elas geralmente são muito boas nisso.

00:02:03.980 --> 00:02:06.400
A peça que falta é o que acontece depois que você vê o que está acontecendo.

00:02:07.440 --> 00:02:11.160
Atualmente, a maioria dos fluxos de trabalho depende de um humano para anotar a mudança,

00:02:11.160 --> 00:02:13.940
decidir qual ação tomar e, então, executá-la.

00:02:14.440 --> 00:02:15.440
Isso cria um gargalo.

00:02:15.440 --> 00:02:19.140
Até algo básico, como enviar um e-mail para clientes quando uma certa métrica cai,

00:02:19.520 --> 00:02:22.400
acaba sendo um trabalho manual porque o sistema não está configurado

00:02:22.400 --> 00:02:25.020
para conectar o Insight diretamente à ação.

00:02:26.220 --> 00:02:28.900
Esse atraso onde tantas oportunidades simplesmente esfria.

00:02:29.760 --> 00:02:33.220
Uma promoção lançada três horas atrasada após uma queda nas vendas perde-surgens.

00:02:33.940 --> 00:02:37.680
Um pico de erros no site que fica sem solução até a próxima reunião de revisão

00:02:37.680 --> 00:02:40.500
acaba custando conversões que nunca recuperaremos.

00:02:40.500 --> 00:02:44.640
O intervalo entre saber e agir é exatamente onde o Fabric Data Activator atua

00:02:44.640 --> 00:02:47.360
e ele foi projetado para reduzir essa lacuna a segundos.

00:02:48.460 --> 00:02:50.560
Como ele reside nativamente no Microsoft Fabric,

00:02:50.680 --> 00:02:55.540
o Data Activator dispensa a necessidade de exportar, conectar ou gerenciar fontes de dados constantemente.

00:02:56.580 --> 00:02:59.720
Ele lê fluxos de eventos à medida que acontecem e reage instantaneamente

00:02:59.720 --> 00:03:01.580
quando uma condição definida por você é atendida.

00:03:01.580 --> 00:03:04.180
A diferença é que em vez de parar em um alerta,

00:03:04.220 --> 00:03:06.740
ele pode iniciar uma reação em cadeia no restante dos seus sistemas.

00:03:07.620 --> 00:03:11.220
Imagine isto, um feed de vendas ao vivo monitora o desempenho em diferentes regiões.

00:03:12.680 --> 00:03:15.680
Normalmente, você notaria uma queda repentina em uma região no seu painel,

00:03:15.920 --> 00:03:17.800
investigaria, criaria uma oferta direcionada,

00:03:18.100 --> 00:03:20.300
obteria aprovação e publicaria a promoção.

00:03:20.960 --> 00:03:21.780
Isso poderia levar uma hora.

00:03:23.220 --> 00:03:27.220
Com o Data Activator, essa mesma queda pode acionar uma chamada de API pré-aprovada

00:03:27.220 --> 00:03:30.680
para seu sistema de automação de marketing lançando uma oferta direcionada em minutos

00:03:30.680 --> 00:03:32.880
antes mesmo que os concorrentes percebam a fraqueza.

00:03:34.040 --> 00:03:38.440
Sem esperar que a pessoa certa perceba, sem demora para deliberar sobre uma ação óbvia.

00:03:39.080 --> 00:03:39.820
Essa é a verdadeira mudança.

00:03:40.260 --> 00:03:41.880
Ferramentas de BI tradicionais rastreiam.

00:03:42.040 --> 00:03:43.560
O Data Activator ouve e responde.

00:03:44.380 --> 00:03:46.600
Com uma cadência típica de atualização do Power BI,

00:03:46.760 --> 00:03:50.540
de, digamos, a cada 30 minutos, a detecção por si só já pode estar atrasada

00:03:50.540 --> 00:03:52.220
desde o momento em que a mudança começou.

00:03:52.680 --> 00:03:52.780
Pô.

00:03:53.900 --> 00:03:57.840
Os gatilhos do Data Activator podem agir sob fluxos de eventos em tempo quase real,

00:03:58.400 --> 00:04:00.160
na ordem de segundos, dependendo da fonte,

00:04:00.160 --> 00:04:03.860
fazendo com que o momento da ação fique muito mais próximo do evento que o disparou.

00:04:05.400 --> 00:04:08.760
E como ele está integrado à fábrica e não se limita a um único painel ou conjunto de dados,

00:04:09.320 --> 00:04:12.000
ele pode se conectar a qualquer parte do ecossistema que faça sentido.

00:04:13.260 --> 00:04:17.580
Esse feed de streaming pode ser parte de um pipeline de dados do Synapse,

00:04:18.020 --> 00:04:21.200
que alimenta vários modelos downstream e de IA.

00:04:22.200 --> 00:04:26.000
Se algo importante acontece, o Data Activator não apenas avisa o seu painel.

00:04:26.000 --> 00:04:31.560
Ele envia o sinal para os sistemas capazes de corrigir ou explorar a oportunidade imediatamente, imediatamente.

00:04:32.300 --> 00:04:34.220
Esta é a ponte entre a observação e a execução.

00:04:34.860 --> 00:04:38.620
Em vez de encher o chat da sua equipe com mensagens que eles só verão depois do almoço,

00:04:38.700 --> 00:04:41.200
ele executa o próximo passo ali mesmo, na hora.

00:04:42.400 --> 00:04:45.260
Ele transforma cada evento qualificado em uma decisão já tomada,

00:04:45.260 --> 00:04:47.000
em uma ação já realizada.

00:04:47.740 --> 00:04:50.840
Ao comparar com o fluxo de trabalho de B e padrão, a vantagem é óbvia.

00:04:51.880 --> 00:04:53.520
Monitorar sozinho apenas conta a história.

00:04:54.260 --> 00:04:56.100
Monitorar somado à resposta altera o resultado.

00:04:57.220 --> 00:04:59.680
E em um cenário onde as janelas de oportunidade fecham rapidamente,

00:04:59.760 --> 00:05:02.440
essa diferença é mais que conveniência e competitividade.

00:05:03.580 --> 00:05:07.780
A seguir, veremos como isso se encaixa naturalmente nas ferramentas com as quais você já trabalha,

00:05:08.200 --> 00:05:10.840
sem adicionar outra camada de complexidade para gerenciar.

00:05:10.840 --> 00:05:13.440
Mais do que apenas alertas, a rede do Fábio.

00:05:14.000 --> 00:05:16.860
Enviar mais um ping no Teams não é automação, é apenas mais ruído.

00:05:17.640 --> 00:05:18.380
Você sabe do que eu tô falando.

00:05:18.760 --> 00:05:20.980
Uma enxurrada de pop-up surgindo em todas as telas,

00:05:21.080 --> 00:05:23.600
cada um exigindo que você veja algo que pode ou não ser importante.

00:05:24.520 --> 00:05:26.380
No início, há a sensação de estar no controle,

00:05:26.940 --> 00:05:31.420
mas logo sua equipe começa a ignorá-los e os alertas importantes acabam enterrados no caos.

00:05:32.420 --> 00:05:34.900
A ironia é que os sistemas feitos para mantê-lo informado

00:05:34.900 --> 00:05:37.340
acabam muitas vezes tornando mais cego, mais cego.

00:05:38.180 --> 00:05:40.460
Todos nós já participamos daquela reunião de segunda-feira

00:05:40.460 --> 00:05:42.540
onde alguém menciona que perdeu um problema grave de um cliente

00:05:42.540 --> 00:05:44.460
simplesmente porque o alerta aparecia com todos os outros.

00:05:45.440 --> 00:05:47.420
A raiz do problema não é a falta de detecção,

00:05:47.780 --> 00:05:49.900
é a falta de inteligência sobre o que fazer a seguir.

00:05:50.900 --> 00:05:54.180
Gatilhos excessivamente sensíveis tratam cada pequena flutuação como uma crise.

00:05:54.440 --> 00:05:56.800
Isso cria uma cultura onde todos são treinados para ignorá-los.

00:05:58.560 --> 00:06:00.500
É aqui que o Data Activator do Microsoft Fabric,

00:06:00.600 --> 00:06:02.540
junto com o restante do Fabric, começa a fazer a diferença.

00:06:04.180 --> 00:06:05.640
Ele não é apenas um complemento.

00:06:05.640 --> 00:06:09.420
Opera lado a lado com o Power BI, o Synapse e o armazenamento de dados do Fabric.

00:06:10.300 --> 00:06:12.100
Isso significa que ele atua no mesmo ambiente

00:06:12.100 --> 00:06:14.720
que as ferramentas que já executam suas análises e pipelines.

00:06:15.600 --> 00:06:17.400
Em vez de notificar toda vez que uma métrica oscila,

00:06:17.460 --> 00:06:19.740
ele pode decidir se a oscilação justifica parar a operação.

00:06:20.860 --> 00:06:23.560
Pense nele como um operador de central telefônica à moda antiga,

00:06:23.620 --> 00:06:26.040
mas que realmente entende a urgência por trás de cada chamada.

00:06:26.880 --> 00:06:29.340
Quando algo acontece, como um feed de dados enviando um sinal

00:06:29.340 --> 00:06:31.740
de que o formato de nome do seu produto quebrou durante o carregamento,

00:06:31.740 --> 00:06:35.280
o Data Activator sabe quais conexões levam ao sistema certos.

00:06:35.640 --> 00:06:38.200
Ele não envia à equipe de marketing uma notificação que eles só lerão amanhã.

00:06:38.820 --> 00:06:40.680
Ele encaminha o problema diretamente para o sistema

00:06:40.680 --> 00:06:42.560
que pode congelar o carregamento defeituoso

00:06:42.560 --> 00:06:44.460
antes que ele corrompa os relatórios subsequentes.

00:06:45.340 --> 00:06:46.160
Este é um exemplo prático.

00:06:46.580 --> 00:06:49.680
Um pipeline do Synapse está extraindo dados de transações financeiras

00:06:49.680 --> 00:06:50.560
a cada poucos segundos.

00:06:51.480 --> 00:06:53.940
Um dos sistemas upstream começa a enviar registros duplicados

00:06:53.940 --> 00:06:55.320
devido a uma falha no fornecedor.

00:06:56.140 --> 00:06:57.440
Se você estiver usando apenas alertas,

00:06:57.520 --> 00:06:59.300
verá uma mensagem no Teams ou um e-mail dizendo

00:06:59.300 --> 00:07:00.960
Olá, contagem de duplicatas detectada.

00:07:00.960 --> 00:07:05.760
Com o Data Activator, ele pode pausar o pipeline

00:07:05.760 --> 00:07:07.240
assim que as duplicatas chegam,

00:07:07.480 --> 00:07:09.000
dando aos seus engenheiros de dados tempo

00:07:09.000 --> 00:07:11.380
para corrigir a fonte antes que os dados ruins

00:07:11.380 --> 00:07:12.620
entrem no seu warehouse.

00:07:13.900 --> 00:07:15.700
A correção acontece no nível do sistema,

00:07:15.800 --> 00:07:17.260
não porque alguém estava checando o painel por acaso.

00:07:18.100 --> 00:07:19.100
Essa é uma diferença fundamental.

00:07:19.500 --> 00:07:20.980
O Data Activator não está vinculado

00:07:20.980 --> 00:07:22.620
a um único conjunto de dados ou fluxo restrito.

00:07:22.960 --> 00:07:24.600
Ele funciona com vários tipos de entrada.

00:07:25.460 --> 00:07:27.680
Tabelas de warehouses estruturadas, fluxos de eventos

00:07:27.680 --> 00:07:29.660
e outras fontes de dados conectadas ao fábrica,

00:07:29.660 --> 00:07:32.820
aplicando as mesmas regras lógicas sem que você precise monitorá-las.

00:07:33.820 --> 00:07:37.020
Esse escopo entre serviços significa que ele não apenas sabe quando algo está errado.

00:07:37.640 --> 00:07:39.760
Ele sabe exatamente onde pisar no freio ou acelerar.

00:07:41.020 --> 00:07:42.880
E como ele vive dentro do mesmo ecossistema,

00:07:42.960 --> 00:07:44.860
que sua lógica de transformação e armazenamento,

00:07:44.960 --> 00:07:46.520
ele não luta contra os fluxos de dados.

00:07:47.440 --> 00:07:48.400
Ele está incorporado a eles.

00:07:48.400 --> 00:07:51.020
É por isso que você pode criar uma cadeia onde ingestão,

00:07:51.160 --> 00:07:53.780
transformação, validação e resolução acontecem em um único fluxo

00:07:53.780 --> 00:07:56.340
sem que as pessoas precisem se procurar para passar tarefas adiante.

00:07:57.000 --> 00:07:59.960
É a diferença entre reagir aos dados e ter seu sistema se adaptando

00:07:59.960 --> 00:08:04.240
durante o processo para manter a qualidade e a pontualidade intactas.

00:08:04.240 --> 00:08:07.520
Mas o verdadeiro benefício começa a surgir quando você não vê isso

00:08:07.520 --> 00:08:08.600
como uma ferramenta de alerta,

00:08:08.640 --> 00:08:10.560
mas como uma camada de tomada de decisão operacional.

00:08:11.220 --> 00:08:12.780
Ele responde com base no contexto,

00:08:12.960 --> 00:08:14.920
o que reduz drasticamente o volume de ruído

00:08:14.920 --> 00:08:17.320
enquanto aumenta a porcentagem de alertas

00:08:17.320 --> 00:08:19.400
que realmente acionam uma ação significativa.

00:08:19.400 --> 00:08:22.280
Você não fica mais sobrecarregado.

00:08:23.000 --> 00:08:25.700
Você obtém sinal em vez de ruído com menos trabalho humano.

00:08:27.020 --> 00:08:29.540
E como essas decisões podem desencadear mudanças reais

00:08:29.540 --> 00:08:32.640
para usar tarefas, atualizar registros, iniciar correções,

00:08:32.760 --> 00:08:35.500
isso não apenas reduz o atraso entre saber e agir.

00:08:36.320 --> 00:08:37.660
Isso elimina lacuna completamente.

00:08:38.080 --> 00:08:39.900
Agora vamos entrar na parte que chama atenção,

00:08:40.020 --> 00:08:42.420
chamar a API sem interagir com o mundo fora da Microsoft.

00:08:43.520 --> 00:08:45.080
Quando o interior chama o mundo exterior,

00:08:45.240 --> 00:08:46.600
seus dados podem fazer um telefonema

00:08:46.600 --> 00:08:48.340
antes mesmo de você ver a chamada perdida.

00:08:48.340 --> 00:08:50.320
Isso não é uma força de expressão,

00:08:50.380 --> 00:08:52.040
estamos falando de pegar o mesmo fluxo de eventos

00:08:52.040 --> 00:08:53.200
que você já rastreia

00:08:53.200 --> 00:08:56.380
e deixá-lo acionar algo fora do ecossistema Microsoft Fabric

00:08:56.380 --> 00:08:57.700
em tempo real.

00:08:58.640 --> 00:09:00.260
Em vez de esperar que você leia um painel

00:09:00.260 --> 00:09:01.860
ou clique em um alerta do Teams,

00:09:02.040 --> 00:09:05.060
o próprio sistema disca metafórica,

00:09:05.060 --> 00:09:05.940
ou literalmente,

00:09:06.220 --> 00:09:09.220
para iniciar uma ação em outro aplicativo ou serviço

00:09:09.220 --> 00:09:11.000
no momento em que a condição é atendida.

00:09:11.960 --> 00:09:13.800
A maioria das configurações de BI fala exatamente isso.

00:09:14.180 --> 00:09:15.780
Elas são excelentes em revelar em sites,

00:09:16.100 --> 00:09:17.320
às vezes até com visuais chamativos

00:09:17.320 --> 00:09:18.620
e comentários assistidos por IA,

00:09:18.900 --> 00:09:19.880
mas entregam a bola para você

00:09:19.880 --> 00:09:21.140
e esperam que você corra com ela.

00:09:22.520 --> 00:09:24.240
Você ainda precisa abrir o CRM

00:09:24.240 --> 00:09:25.720
e enviar o pedido, atualizar o RP

00:09:25.720 --> 00:09:27.340
ou iniciar o processo manualmente.

00:09:28.480 --> 00:09:30.500
Essa lacuna onde o gargalo humano aparece novamente,

00:09:31.360 --> 00:09:32.880
você pode detectar o problema em minutos,

00:09:33.040 --> 00:09:34.760
mas a execução acontece horas depois

00:09:34.760 --> 00:09:37.040
porque está esperando que alguém esteja livre para agir.

00:09:38.020 --> 00:09:39.100
Com o Data Activator,

00:09:39.160 --> 00:09:40.400
essa etapa não é apenas reduzida,

00:09:40.580 --> 00:09:41.200
ela desaparece.

00:09:41.200 --> 00:09:43.220
Imagine os níveis de estoque

00:09:43.220 --> 00:09:46.120
caindo abaixo do seu limite de reposição no meio do dia.

00:09:47.240 --> 00:09:48.340
Em uma configuração normal,

00:09:48.500 --> 00:09:50.140
alguém na operação percebe isso no Power BI,

00:09:50.340 --> 00:09:51.540
envia um aviso para o setor de compras

00:09:51.540 --> 00:09:52.600
e aguarda a confirmação.

00:09:52.900 --> 00:09:53.460
E a confirmação.

00:09:53.780 --> 00:09:54.340
Enquanto isso,

00:09:54.400 --> 00:09:55.520
você continua vendendo o produto

00:09:55.520 --> 00:09:56.980
e caminhando para uma ruptura de estoque.

00:09:58.040 --> 00:09:58.580
Em vez disso,

00:09:58.660 --> 00:10:00.500
o Data Activator pode enviar uma chamada de API

00:10:00.500 --> 00:10:02.560
direto para o sistema de pedidos do seu fornecedor

00:10:02.560 --> 00:10:04.420
no momento em que os dados cruzam esse limite.

00:10:05.060 --> 00:10:06.900
O pedido de compra, entrega, entra na fila,

00:10:06.900 --> 00:10:08.480
ninguém da sua equipe leu o alerta ainda

00:10:08.480 --> 00:10:10.800
e a correção já está em andamento.

00:10:11.240 --> 00:10:12.880
Esse é o valor de realizar chamadas externas

00:10:12.880 --> 00:10:14.160
diretamente dentro do fábrico.

00:10:14.920 --> 00:10:17.140
Você não está limitado às ferramentas da Microsoft,

00:10:17.280 --> 00:10:18.160
sejam CRM SASE,

00:10:18.220 --> 00:10:18.840
um RP legado,

00:10:18.920 --> 00:10:20.340
um Endpoint REST personalizado

00:10:20.340 --> 00:10:21.800
ou até a API de um parceiro.

00:10:21.880 --> 00:10:23.560
Você pode conectar esse gatilho em tempo real

00:10:23.560 --> 00:10:25.280
para reduzir a distância entre a detecção

00:10:25.280 --> 00:10:26.400
e a resolução.

00:10:27.700 --> 00:10:29.280
A saída pode ser tão simples

00:10:29.280 --> 00:10:31.000
quanto enviar dados para um webhook

00:10:31.000 --> 00:10:32.200
ou tão estruturada

00:10:32.200 --> 00:10:33.680
quanto enviar um payload formatado

00:10:33.680 --> 00:10:34.940
que aciona um fluxo de trabalho

00:10:34.940 --> 00:10:35.840
de várias etapas

00:10:35.840 --> 00:10:37.800
em uma plataforma completamente diferente.

00:10:39.240 --> 00:10:40.700
Este é o ponto em que o fábrico

00:10:40.700 --> 00:10:42.140
deixa de ser apenas um conjunto

00:10:42.140 --> 00:10:43.240
de ferramentas de análise

00:10:43.240 --> 00:10:44.540
e passa a se comportar

00:10:44.540 --> 00:10:45.720
como o sistema nervoso central

00:10:45.720 --> 00:10:47.440
do seu ambiente operacional.

00:10:48.440 --> 00:10:49.400
Quando um evento ocorre,

00:10:49.480 --> 00:10:50.760
o nervo não apenas envia um sinal

00:10:50.760 --> 00:10:51.400
para seus olhos,

00:10:51.920 --> 00:10:53.260
ele envia instruções para os membros

00:10:53.260 --> 00:10:54.640
que podem agir imediatamente.

00:10:55.040 --> 00:10:55.440
Imediatamente.

00:10:55.780 --> 00:10:56.540
É assim que você passa

00:10:56.540 --> 00:10:57.920
do monitoramento de operações

00:10:57.920 --> 00:10:59.240
para uma situação em que ela se autorregula

00:10:59.240 --> 00:10:59.900
em grande parte.

00:11:00.540 --> 00:11:01.640
Você pode ver isso em setores

00:11:01.640 --> 00:11:02.800
com forte presença de IoT.

00:11:02.800 --> 00:11:04.840
Imagine uma fábrica

00:11:04.840 --> 00:11:06.040
com sensores de vibração

00:11:06.040 --> 00:11:07.580
instalados em maquinário crítico.

00:11:08.920 --> 00:11:10.080
Esses sensores transmitem dados

00:11:10.080 --> 00:11:10.920
para o fábrico em tempo real.

00:11:11.340 --> 00:11:12.300
No momento em que uma leitura

00:11:12.300 --> 00:11:13.760
entra na faixa de aviso de falha,

00:11:13.760 --> 00:11:15.220
o Data Activator pode criar

00:11:15.220 --> 00:11:16.740
e atribuir uma ordem de serviço

00:11:16.740 --> 00:11:17.900
no Dynamics 365,

00:11:18.400 --> 00:11:19.160
agendando o engenheiro

00:11:19.160 --> 00:11:20.220
antes mesmo que a máquina

00:11:20.220 --> 00:11:21.380
chegue perto de falhar.

00:11:21.380 --> 00:11:23.380
Nenhum supervisor

00:11:23.380 --> 00:11:24.160
precisa interromper o dia

00:11:24.160 --> 00:11:24.900
para fazer a ligação,

00:11:25.040 --> 00:11:25.680
o sistema em caminho

00:11:25.680 --> 00:11:26.860
trabalha automaticamente

00:11:26.860 --> 00:11:27.900
com todo o contexto

00:11:27.900 --> 00:11:28.980
que o técnico precisa.

00:11:30.040 --> 00:11:31.140
O trabalho de reparo

00:11:31.140 --> 00:11:31.960
começa antes mesmo

00:11:31.960 --> 00:11:32.880
que o tempo de inatividade

00:11:32.880 --> 00:11:33.580
vire assunto.

00:11:34.040 --> 00:11:35.220
A combinação de monitoramento

00:11:35.220 --> 00:11:36.540
automatizado e APS saída

00:11:36.540 --> 00:11:37.820
é onde a verdadeira autonomia

00:11:37.820 --> 00:11:38.540
entra em ação.

00:11:39.000 --> 00:11:39.760
Você não está apenas

00:11:39.760 --> 00:11:41.020
filtrando alertas por relevância,

00:11:41.100 --> 00:11:41.760
você está conectando

00:11:41.760 --> 00:11:42.660
esses gatilhos filtrados

00:11:42.660 --> 00:11:43.420
a ações tangíveis

00:11:43.420 --> 00:11:44.460
que acontecem imediatamente.

00:11:45.040 --> 00:11:45.660
Esse é o salto

00:11:45.660 --> 00:11:46.540
se orientado por dados

00:11:46.540 --> 00:11:47.620
para ser ativado por dados,

00:11:48.060 --> 00:11:49.080
onde a capacidade de resposta

00:11:49.080 --> 00:11:50.000
do sistema é tão rápida

00:11:50.000 --> 00:11:51.260
quanto sua capacidade de detecção.

00:11:52.080 --> 00:11:53.840
Quando você configura corretamente,

00:11:53.940 --> 00:11:54.940
seus processos não apenas

00:11:54.940 --> 00:11:56.780
dispensam o microgerenciamento humano.

00:11:56.960 --> 00:11:57.940
Eles melhoram ativamente

00:11:57.940 --> 00:11:59.820
porque o ciclo entre detecção e ação

00:11:59.820 --> 00:12:01.020
é estreito, consistente

00:12:01.020 --> 00:12:01.960
e sempre ativo.

00:12:03.260 --> 00:12:04.240
Você pode se concentrar

00:12:04.240 --> 00:12:05.480
em projetar melhores regras

00:12:05.480 --> 00:12:06.700
e lógica em vez de se preocupar

00:12:06.700 --> 00:12:07.920
se alguém viu o alerta.

00:12:08.820 --> 00:12:09.780
Mas até o sistema nervoso

00:12:09.780 --> 00:12:11.000
mais responsivo possui limites

00:12:11.000 --> 00:12:11.980
que você não pode ignorar.

00:12:12.700 --> 00:12:13.440
E se você nos conhecer

00:12:13.440 --> 00:12:14.080
antes de começar,

00:12:14.200 --> 00:12:15.060
os resultados podem se tornar

00:12:15.060 --> 00:12:15.960
caóticos rapidamente.

00:12:17.000 --> 00:12:17.860
Conhecer as fronteiras

00:12:17.860 --> 00:12:18.680
antes de construir

00:12:18.680 --> 00:12:20.360
todo o herói da automação

00:12:20.360 --> 00:12:21.460
tem uma história de origem

00:12:21.460 --> 00:12:23.000
e uma lista de problemas

00:12:23.000 --> 00:12:24.500
que gostaria de ter previsto.

00:12:25.860 --> 00:12:26.660
Com o Data Activator,

00:12:26.740 --> 00:12:27.420
a realidade é que,

00:12:27.540 --> 00:12:29.000
embora a ideia de detecção

00:12:29.000 --> 00:12:30.320
mais reação pareça ilimitada,

00:12:30.420 --> 00:12:31.100
existe uma estrutura

00:12:31.100 --> 00:12:32.500
muito prática por baixo dela.

00:12:33.380 --> 00:12:34.120
Não é mágica.

00:12:34.320 --> 00:12:35.400
Ainda está sendo executado

00:12:35.400 --> 00:12:36.440
na arquitetura do Fabric,

00:12:36.780 --> 00:12:37.740
limitado pelos mesmos

00:12:37.740 --> 00:12:38.740
modelos de capacidade,

00:12:38.880 --> 00:12:39.720
limites de serviço

00:12:39.720 --> 00:12:40.640
e premissas de design

00:12:40.640 --> 00:12:41.520
que se aplicam

00:12:41.520 --> 00:12:42.960
a todo o restante do ecossistema.

00:12:44.020 --> 00:12:44.980
Ignore esses limites

00:12:44.980 --> 00:12:46.280
e você descobrirá rapidamente

00:12:46.280 --> 00:12:46.880
o que acontece

00:12:46.880 --> 00:12:47.700
quando uma automação

00:12:47.700 --> 00:12:48.640
bem-intencionada

00:12:48.640 --> 00:12:49.620
para de funcionar.

00:12:50.620 --> 00:12:51.440
A parte complicada

00:12:51.440 --> 00:12:52.300
é que os pontos de falha

00:12:52.300 --> 00:12:53.120
geralmente não aparecem

00:12:53.120 --> 00:12:54.240
durante a sua prova de conceito.

00:12:54.900 --> 00:12:55.660
Em um teste pequeno,

00:12:55.800 --> 00:12:56.780
tudo parece instantâneo.

00:12:57.380 --> 00:12:58.380
As condições são acionadas,

00:12:58.480 --> 00:12:59.120
as ações disparadas,

00:12:59.200 --> 00:12:59.740
você vê o resultado

00:12:59.740 --> 00:13:00.480
quase imediatamente.

00:13:01.440 --> 00:13:02.440
É quando você escala,

00:13:02.920 --> 00:13:04.240
conectando vários sistemas externos,

00:13:04.300 --> 00:13:05.420
aumentando o volume de gatilhos

00:13:05.420 --> 00:13:06.680
e adicionando lógica complexa

00:13:06.680 --> 00:13:07.900
que as restrições aparecem.

00:13:08.960 --> 00:13:09.960
A latência aumenta,

00:13:10.140 --> 00:13:11.320
o uso da capacidade dispara.

00:13:11.980 --> 00:13:12.320
De repente,

00:13:12.420 --> 00:13:13.000
aquele mecanismo

00:13:13.000 --> 00:13:14.180
de decisão em tempo real

00:13:14.180 --> 00:13:15.260
é limitado ou colocado

00:13:15.260 --> 00:13:15.920
em uma fila.

00:13:17.320 --> 00:13:18.400
Pense no que acontece

00:13:18.400 --> 00:13:19.040
quando um gatilho

00:13:19.040 --> 00:13:19.860
depende de uma fonte

00:13:19.860 --> 00:13:21.160
que está tecnicamente conectada,

00:13:21.240 --> 00:13:21.820
mas não roda

00:13:21.820 --> 00:13:22.680
dentro dos serviços

00:13:22.680 --> 00:13:23.600
nativos do fabric.

00:13:24.840 --> 00:13:25.840
Talvez se tenha um fluxo

00:13:25.840 --> 00:13:26.780
de dados vindo de um hub

00:13:26.780 --> 00:13:27.580
de eventos externo

00:13:27.580 --> 00:13:28.720
que alimenta seus relatórios.

00:13:30.020 --> 00:13:30.980
Se o Data Activator

00:13:30.980 --> 00:13:32.000
depende desse feed

00:13:32.000 --> 00:13:33.320
para disparar um processo crítico,

00:13:33.380 --> 00:13:34.640
mas o intervalo de processamento

00:13:34.640 --> 00:13:35.660
na origem é mais lento

00:13:35.660 --> 00:13:36.620
que o tempo de reação

00:13:36.620 --> 00:13:37.460
do fabric,

00:13:37.780 --> 00:13:39.040
você nunca terá

00:13:39.040 --> 00:13:40.280
a resposta que espera.

00:13:41.560 --> 00:13:42.360
Já vi implementações

00:13:42.360 --> 00:13:43.440
travarem porque as condições

00:13:43.440 --> 00:13:43.960
foram criadas

00:13:43.960 --> 00:13:44.940
sobre dados semi-estáticos

00:13:44.940 --> 00:13:45.360
que simplesmente

00:13:45.360 --> 00:13:45.960
não acompanhavam

00:13:45.960 --> 00:13:46.840
a lógica do gatilho.

00:13:47.740 --> 00:13:48.580
A automação não falhou,

00:13:48.660 --> 00:13:49.580
ela apenas chegou tarde demais

00:13:49.580 --> 00:13:50.060
para importar.

00:13:50.680 --> 00:13:51.120
Existe também

00:13:51.120 --> 00:13:52.200
a tentação de monitorar tudo.

00:13:52.640 --> 00:13:52.800
Bem,

00:13:52.880 --> 00:13:53.800
isso faz sentido no início.

00:13:54.580 --> 00:13:55.900
Mais condições de monitoramento

00:13:55.900 --> 00:13:56.740
deveriam significar

00:13:56.740 --> 00:13:58.180
mais oportunidades de reação,

00:13:58.680 --> 00:13:59.300
mas cada gatilho

00:13:59.300 --> 00:13:59.840
que você define

00:13:59.840 --> 00:14:00.640
contribui para a carga

00:14:00.640 --> 00:14:01.460
de trabalho executada

00:14:01.460 --> 00:14:02.820
em sua capacidade do fabric.

00:14:03.420 --> 00:14:03.960
Isso significa

00:14:03.960 --> 00:14:04.800
que você está consumindo

00:14:04.800 --> 00:14:05.420
a mesma capacidade

00:14:05.420 --> 00:14:05.940
que suporta

00:14:05.940 --> 00:14:06.900
suas atualizações de BI,

00:14:07.040 --> 00:14:07.780
seus fluxos de dados

00:14:07.780 --> 00:14:09.020
e suas consultas de warehouse.

00:14:10.360 --> 00:14:11.180
Se forçar demais,

00:14:11.280 --> 00:14:12.140
verão o efeito dominó

00:14:12.140 --> 00:14:13.320
onde outras cargas de trabalho

00:14:13.320 --> 00:14:14.020
ficam lentas

00:14:14.020 --> 00:14:14.780
porque seus gatilhos

00:14:14.780 --> 00:14:15.440
estão consumindo

00:14:15.440 --> 00:14:16.380
todo o processamento.

00:14:17.120 --> 00:14:18.040
Planejamento de capacidade

00:14:18.040 --> 00:14:18.800
não é opcional aqui,

00:14:18.920 --> 00:14:19.520
pois é a disciplina

00:14:19.520 --> 00:14:20.400
que evita que a automação

00:14:20.400 --> 00:14:20.960
se transforme

00:14:20.960 --> 00:14:21.300
em um tempo

00:14:21.300 --> 00:14:22.540
de inatividade auto-infligida.

00:14:22.900 --> 00:14:23.600
As metas de latência

00:14:23.600 --> 00:14:24.000
vem só agora.

00:14:24.420 --> 00:14:25.600
O Detectivator pode reagir

00:14:25.600 --> 00:14:26.040
em segundos,

00:14:26.160 --> 00:14:27.040
mas apenas se os sistemas

00:14:27.040 --> 00:14:27.780
upstream e downstream

00:14:27.780 --> 00:14:28.400
puderem lidar

00:14:28.400 --> 00:14:29.000
com essa velocidade.

00:14:29.940 --> 00:14:31.560
Se sua chamada de API disparada

00:14:31.560 --> 00:14:32.560
aponta para uma integração

00:14:32.560 --> 00:14:33.600
de RP processada

00:14:33.600 --> 00:14:34.700
em lote a cada 15 minutos,

00:14:34.840 --> 00:14:35.820
você efetivamente

00:14:35.820 --> 00:14:37.480
criou atrasos embutidos.

00:14:38.300 --> 00:14:39.220
O gatilho é executado,

00:14:39.220 --> 00:14:40.020
mas o resultado final

00:14:40.020 --> 00:14:40.520
ainda aguarda

00:14:40.520 --> 00:14:41.340
pelo próximo lote.

00:14:42.060 --> 00:14:42.820
Essas diferenças

00:14:42.820 --> 00:14:43.660
no ritmo de serviço

00:14:43.660 --> 00:14:44.480
precisam ser mapeadas

00:14:44.480 --> 00:14:45.120
antes de começar

00:14:45.120 --> 00:14:45.960
a conectar os sistemas.

00:14:47.140 --> 00:14:47.960
O caminho mais seguro

00:14:47.960 --> 00:14:49.060
é começar com condições

00:14:49.060 --> 00:14:49.740
de alto valor

00:14:49.740 --> 00:14:50.740
e baixa frequência.

00:14:51.320 --> 00:14:51.980
Isso significa

00:14:51.980 --> 00:14:52.700
escolher cenários

00:14:52.700 --> 00:14:52.980
onde,

00:14:53.100 --> 00:14:53.820
mesmo que você dispare

00:14:53.820 --> 00:14:54.580
apenas algumas vezes

00:14:54.580 --> 00:14:54.940
ao dia,

00:14:55.400 --> 00:14:56.140
cada um tem um impacto

00:14:56.140 --> 00:14:56.940
claro que justifique

00:14:56.940 --> 00:14:57.500
a automação.

00:14:58.180 --> 00:14:58.980
Trata-se de provar

00:14:58.980 --> 00:14:59.580
eficácias

00:14:59.580 --> 00:15:00.400
sem inundar

00:15:00.400 --> 00:15:01.080
sua capacidade

00:15:01.080 --> 00:15:01.700
de sobrecarregar

00:15:01.700 --> 00:15:02.680
os serviços downstream.

00:15:03.880 --> 00:15:04.620
Você ajusta

00:15:04.620 --> 00:15:05.440
a lógica do gatilho,

00:15:05.740 --> 00:15:06.240
entende o perfil

00:15:06.240 --> 00:15:06.940
de processamento

00:15:06.940 --> 00:15:07.680
e só então

00:15:07.680 --> 00:15:08.560
começa a expandir.

00:15:09.400 --> 00:15:10.140
Vale lembrar também

00:15:10.140 --> 00:15:10.700
que preços

00:15:10.700 --> 00:15:11.400
e capacidade

00:15:11.400 --> 00:15:11.980
não se referem

00:15:11.980 --> 00:15:13.200
apenas a armazenamento

00:15:13.200 --> 00:15:14.360
ou atualizações.

00:15:15.160 --> 00:15:16.160
A avaliação de gatilhos

00:15:16.160 --> 00:15:17.020
e a execução de ações

00:15:17.020 --> 00:15:17.820
consome recursos

00:15:17.820 --> 00:15:18.500
do mesmo conjunto.

00:15:18.760 --> 00:15:19.280
Aquela chamada

00:15:19.280 --> 00:15:19.900
de API de saída

00:15:19.900 --> 00:15:20.700
é processamento.

00:15:21.220 --> 00:15:21.780
A transformação

00:15:21.780 --> 00:15:22.480
que você executa

00:15:22.480 --> 00:15:22.920
antes de verificar

00:15:22.920 --> 00:15:23.320
uma condição

00:15:23.320 --> 00:15:24.380
também consome processamento.

00:15:25.300 --> 00:15:26.000
Se você escalar

00:15:26.000 --> 00:15:27.180
condições e conexões

00:15:27.180 --> 00:15:27.880
sem levar em conta

00:15:27.880 --> 00:15:28.760
o pool de suas unidades

00:15:28.760 --> 00:15:29.260
de fábrica

00:15:29.260 --> 00:15:30.080
atingirá os limites

00:15:30.080 --> 00:15:30.620
mais rápido

00:15:30.620 --> 00:15:31.300
do que espera.

00:15:32.460 --> 00:15:33.000
Boa notícia

00:15:33.000 --> 00:15:33.460
é que uma vez

00:15:33.460 --> 00:15:33.980
que você sabe

00:15:33.980 --> 00:15:34.620
onde estão os limites

00:15:34.620 --> 00:15:35.560
e pode projetar soluções

00:15:35.560 --> 00:15:36.160
contornando-nos?

00:15:36.440 --> 00:15:37.480
Você cria processos

00:15:37.480 --> 00:15:38.340
que se auto...