process-mining
2021.10
true
Importante :
A tradução automática foi aplicada parcialmente neste conteúdo. A localização de um conteúdo recém-publicado pode levar de 1 a 2 semanas para ficar disponível.
UiPath logo, featuring letters U and I in white

Process Mining

Automation CloudAutomation Cloud Public SectorAutomation SuiteStandalone
Última atualização 20 de dez de 2024

Data Volume

Introdução

A quantidade de dados sempre será uma contrapartida direta com o desempenho. O Process Mining é inerentemente obcecado por detalhes para construir os gráficos do processo.

No entanto, ter todos esses carimbos de data e hora exclusivos afeta o desempenho. Em geral, existem limites teóricos enfrentados por todas as ferramentas do Process Mining e todas as ferramentas na memória.

Tipos de usuários

Fazemos uma distinção clara entre o desempenho dos dados usados para um Aplicativo e o Conector. Embora façam uso da mesma plataforma, existem algumas diferenças, ou seja, o que é aceitável para os usuários (desenvolvedores versus usuários finais) e o tipo de ações realizadas.

Grandes quantidades de dados podem ter impacto no Conector e no Aplicativo, mas tudo pode ser resolvido no Conector.

Data Volume

O desempenho que os usuários finais terão está diretamente relacionado ao volume de dados. O volume de dados é determinado pelo número de linhas nas maiores tabelas. Em geral, apenas o número de linhas determina o desempenho da experiência dos usuários finais. O número de colunas é apenas um fator quando os dados são carregados do banco de dados.

Processos com cerca de 5.000.000 (5M) casos e até cerca de 50.000.000 (50M) eventos por processo seriam ideais. Com mais casos e eventos, analisar os dados e exibir a visualização levará mais tempo.

A plataforma UiPath Process Mining continuará funcionando, porém, quando grandes quantidades de dados são inseridos, a velocidade de reação pode cair. Recomenda-se verificar a quantidade de dados com antecedência. Se exceder os números acima, é recomendável considerar a otimização ou limitação do conjunto de dados.

Nível de detalhe

Um nível mais alto de detalhes levará um tempo de resposta mais alto, o que afeta o desempenho.

A compensação exata entre a quantidade de dados, o nível de detalhe e o tempo de espera precisa ser discutida com os usuários finais. Às vezes, os dados históricos podem ser muito importantes, mas muitas vezes apenas os últimos anos são necessários.

Outro fator são os valores únicos que você tem em suas colunas. O UiPath Process Mining usa um método proprietário para reduzir o tamanho dos arquivos *.mvn ao mínimo. Isso funciona bem para valores semelhantes. Muitos valores exclusivos para um atributo também afetarão o desempenho, por exemplo detalhe do evento.

Soluções

Existem duas direções de solução principais para lidar com grandes volumes de dados:

  • otimização;
  • minimização de dados.

A otimização envolve os ajustes que os superadministradores podem fazer para tornar os painéis renderizados mais rapidamente, o que pode ser obtido adaptando as configurações do aplicativo ao conjunto de dados específico (consulte Design do aplicativo para obter mais informações).

Esta seção descreve a minimização de dados, que são as diferentes técnicas que você pode empregar para reduzir os dados visíveis ao usuário final, de acordo com a questão comercial específica.

As técnicas descritas aqui podem coexistir ou até mesmo ser combinadas para aproveitar os benefícios de várias técnicas. Além disso, você pode manter um aplicativo sem minimização de dados ao lado de aplicativos minimizados porque o nível de detalhamento às vezes pode ser necessário para análises específicas em que um desempenho mais lento é aceitável.

Escopo de dados

Limitar o número de registros que aparecerão no conjunto de dados do tour não apenas melhorará o desempenho do aplicativo, mas também melhorará a compreensão do processo e, por sua vez, melhorará a aceitação pelos negócios.

O escopo dos dados pode ser feito no Conector.

Uma das opções de escopo é limitar o intervalo de tempo a ser observado, filtrando datas ou períodos. Por exemplo, você pode limitar o prazo de 10 anos para um ano. Ou de 1 ano a um mês. Veja a ilustração abaixo.



Recomenda-se uma quantidade limitada de atividades, especialmente no início de qualquer esforço do Process Mining. A partir daí, você pode aumentar à medida que seu conhecimento cresce.

Abaixo está uma diretriz para a gama de atividades:

Alcance (n.º de atividades)

Description

5-20

Intervalo preferencial ao iniciar o Process Mining.

Processo simples para fornecer informações de insight.

20-50

Gama especializada. Expandindo com variantes claras.

50-100

Mais útil se houver variantes claras. Isso significa processos um tanto relacionados, mas principalmente por conta própria.

100+

Aconselhável é dividir em subprocessos.

Observação: filtrar atividades simplificará seu processo e o tornará mais compreensível. Esteja ciente de que você também pode perder informações ou detalhes.

Abaixo estão algumas sugestões para filtragem de dados:

  • Atividades não relacionadas: atividades que não impactam diretamente o processo podem ser filtradas.
  • Atividades secundárias: algumas atividades, ou seja, uma atividade de mudança, podem acontecer em qualquer parte do processo. Estes explodir significativamente um número de variantes.
  • Eventos de ocorrência mínima: os eventos que ocorrem apenas algumas vezes em seu conjunto de dados podem ser filtrados.
  • Processo menor: analisa apenas um subprocesso.
  • Agrupamento de atividades: algumas atividades em seu conjunto de dados podem ser mais como pequenas tarefas, que juntas representam uma atividade que faz mais sentido para o negócio. Agrupá-los exigirá alguma lógica no conector e pode resultar em atividades sobrepostas.
  • Se possível, dentro do desempenho do Conector, use o Conector para filtrar as atividades. Dessa forma, quaisquer alterações podem ser revertidas facilmente ou as atividades podem ser adicionadas novamente. Evite filtrar atividades na extração de dados ou carregamento de dados.

Remover valores discrepantes

Se houver um caso com muitos eventos (outlier), isso afetará algumas expressões que calculam agregações no nível do evento. O filtro de item do painel de/para é afetado por isso e pode ser demorado para calcular se você tiver esses valores discrepantes. É recomendável filtrar esses casos no Conector para removê-los do conjunto de dados.

Observação: isso afeta as métricas. Você só deve remover outliers de acordo com o usuário comercial.

Concentre-se nos valores atípicos

Em outros casos, os valores discrepantes podem ser a área-chave a ser focada. Se o seu processo está indo bem ou você adota metodologias Seis Sigma, você quer se concentrar nas coisas que estão dando errado. Em vez de mostrar todos os casos que dão certo, você mostra apenas os casos que dão errado.

Veja o exemplo abaixo.



Reduzindo o tamanho do conjunto de dados

No Conector, você pode remover atributos com muitos detalhes. Por exemplo, strings longas no atributo Detalhe do Evento .

Quando terminar de desenvolver, muitos atributos não utilizados podem acabar em seu conjunto de dados. Recomenda-se configurar apenas a disponibilidade dos atributos que são usados no conjunto de dados de saída do Conector para o público. Defina a disponibilidade de outros atributos como privados.

Pré-agregação

A pré-agregação é uma técnica empregada por muitas ferramentas de BI para obter informações sobre grandes volumes de dados. Envolve a agregação de dados sobre atributos específicos para reduzir o número de registros em um conjunto de dados. Em BI, isso normalmente seria somar o valor de cada fornecedor, portanto, tenha apenas um registro para cada fornecedor.

Veja o exemplo abaixo.



O Process Mining requer mais configuração, mas um ponto de partida é agregar apenas as variantes do processo. Para cada variante, você teria um registro de caso e um número relacionado de eventos. Isso pode reduzir significativamente os volumes de dados.

Para mostrar resultados corretos, você também teria que mostrar quantos registros cada variante representa, para o término do evento, você poderia usar uma duração mediana de cada evento. Agregar apenas usando variantes pode ser muito alto, então seria sensato verificar os filtros mais comuns usados, por exemplo, uma combinação de variantes, tipo de caso e mês do final do caso (para mostrar as tendências ao longo do tempo).

No entanto, adicionar atributos tem um efeito quadrático no número de registros, portanto, isso requer um equilíbrio cuidadoso entre desempenho e caso de uso.

A pré-agregação é mais aplicável para uma visão geral do seu processo e identificação de tendências gerais.

Amostragem

A amostragem é uma técnica onde você pega uma porcentagem dos casos e seus eventos acontecendo em um período específico. Você pode, por exemplo, definir que apenas 10% de todos os casos e seus eventos sejam mostrados. Dessa forma, você ainda tem exceções ou outliers, pois cada caso tem uma chance semelhante de aparecer no conjunto de dados.

Veja a ilustração abaixo.



Amostragem em Cascata

A amostragem em cascata é uma técnica em que a porcentagem de amostragem cai ao longo do tempo com uma certa porcentagem. Um exemplo disso mostra 100% dos dados da semana passada, 90% de duas semanas atrás, 80% de três semanas atrás e assim por diante.

Fragmentação de dados

A fragmentação de dados é uma técnica da solução de escopo de dados, que permite que as organizações dividam os dados em vários conjuntos de dados, em vez de apenas cortar uma parte. Essa configuração requer configuração adicional, pois o aplicativo precisa ser dividido usando módulos e vários conjuntos de dados menores precisam ser exportados do conector.

Com a fragmentação de dados, o conjunto de dados original é dividido em vários fragmentos. Quanto menor for cada fragmento, mais rápido será. Quando um usuário efetua login no aplicativo, apenas o fragmento de dados aplicável será carregado.

Uma unidade típica para sharding seria “Código da empresa” ou “Departamento”. Por exemplo, no caso de 50 códigos de empresa, cada estilhaço conterá um código de empresa e, essencialmente, será cerca de 50 vezes mais rápido que o conjunto de dados original.

Veja a ilustração abaixo para uma visão geral da fragmentação.



Esta página foi útil?

Obtenha a ajuda que você precisa
Aprendendo RPA - Cursos de automação
Fórum da comunidade da Uipath
Uipath Logo White
Confiança e segurança
© 2005-2024 UiPath. Todos os direitos reservados.