- Notas de versão
- Introdução
- Instalação
- Requisitos de hardware e software
- Instalação do servidor
- Atualizando a Licença
- Implantando o Profiler do UiPath Process Mining
- Implantando um conector (.mvp)
- Atualizando o UiPath Process Mining
- Atualizando uma versão personalizada de um aplicativo ou acelerador de descoberta
- Instalando um Ambiente de Treinamento
- Configuração
- Integrações
- Autenticação
- Working with Apps and Discovery Accelerators
- Menus e painéis do AppOne
- Configuração do AppOne
- Menus e painéis do TemplateOne 1.0.0
- Configuração do TemplateOne 1.0.0
- Menus e painéis do TemplateOne
- Configuração do TemplateOne 2021.4.0
- Menus e painéis do Acelerador de Descoberta Purchase to Pay
- Configuração do acelerador Discovery de compra para pagamento
- Menus e painéis do Acelerador de Descoberta Order a Cash
- Order to Cash Discovery Accelerator Setup
- Basic Connector for AppOne
- Implantar o Conector Básico
- Introduction to Basic Connector
- Tabelas de entrada do Conector Básico
- Adicionando tags
- Adição de estimativas de automação
- Adicionando Datas de conclusão
- Adicionando modelos de referência
- Setting up Actionable Insights
- Configuração de gráficos recolhíveis
- Usando o conjunto de dados de saída no AppOne
- Output tables of the Basic Connector
- SAP Connectors
- Introduction to SAP Connector
- Entrada do SAP
- Verificando os dados no SAP Connector
- Adicionando tags específicas do processo ao SAP Connector para o AppOne
- Adição de datas de vencimento específicas do processo ao SAP Connector para o AppOne
- Adicionando estimativas de automação ao SAP Connector para o AppOne
- Adicionando atributos ao SAP Connector para o AppOne
- Adicionando atividades ao SAP Connector para o AppOne
- Adicionando entidades ao SAP Connector para o AppOne
- SAP Order to Cash Connector para AppOne
- SAP Purchase to Pay Connector para AppOne
- SAP Connector for Purchase to Pay Discovery Accelerator
- SAP Connector for Order-to-Cash Discovery Accelerator
- Superadmin
- Painéis e gráficos
- Tabelas e itens de tabela
- Integridade do aplicativo
- How to ....
- Como trabalhar com conectores SQL
- Introduction to SQL connectors
- Setting up a SQL connector
- CData Sync extractions
- Running a SQL connector
- Editing transformations
- Lançamento de um conector SQL
- Scheduling data extraction
- Structure of transformations
- Using SQL connectors for released apps
- Generating a cache with scripts
- Setting up a local test environment
- Separate development and production environments
- Recursos úteis
Data Volume
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.
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.
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.
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.
*.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.
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.
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. |
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.
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.
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.
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.
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.
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.
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.
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.