- Notas de versão
- Antes de começar
- Introdução
- Integrações
- Como trabalhar com aplicativos de processo
- Como trabalhar com painéis e gráficos
- Como trabalhar com gráficos de processo
- Trabalhando com Descubra modelos de processo e Importar modelos BPMN
- Showing or hiding the menu
- Informações de contexto
- Exportar
- Filtros
- Envio de ideias de automação ao UiPath® Automation Hub
- Tags
- Datas de conclusão
- Comparar
- Verificação de conformidade
- Análise de causa raiz
- Simulação de Potencial de Automação
- Triggering an automation from a process app
- Exibição de dados do processo
- Criação de aplicativos
- Carregamento de dados
- Personalização de aplicativos de processo
- Modelos de apps
- Recursos adicionais
- Tags prontas para uso e datas de vencimento
- Edição de transformações de dados em um ambiente local
- Setting up a local test environment
- Métricas personalizadas de tempo de transferência
- SQL differences between Snowflake and SQL Server
- Configuration settings for loading input data
- Designing an event log
- Estendendo a ferramenta de extração SAP Ariba
- Recursos de desempenho
Métricas personalizadas de tempo de transferência
Com a personalização de transformações de dados e edição de painel, você pode criar e usar métricas de tempo de throughput personalizadas. Os tempos de rendimento são as temporizações entre duas atividades A e B. Abaixo está uma descrição das etapas que você precisa executar para criar uma métrica de tempo de rendimento customizado ao editar transformações e como ativar a métrica de tempo de rendimento nos painéis do aplicativo de processo.
Você deve primeiro calcular o tempo de processamento e, em seguida, disponibilizá-lo como um campo Caso .
Por caso, você pode calcular os tempos de throughput entre Atividade A e Atividade B. Como as atividades podem ocorrer mais de uma vez por caso, você precisa levar em consideração se considera a primeira ou a última ocorrência de uma atividade.
-
Crie um modelo adicional com base no log de eventos para calcular os tempos de throughput desejados. Por exemplo, Cases_with_throughput_times.
-
Nesse modelo, crie tabelas de pré-processamento nas quais você define quais extremidades do evento deseja usar para os cálculos. Por tabela, você precisa do ID do casoe do fim do evento de uma atividade. Abaixo está um exemplo de como selecionar a última ocorrência da atividade A para um caso.
Event_end_activity_A as ( select Event_log."Case_ID", max(Event_log."Event_end") as "Event_end_activity_A" from Event_log where Event_log."Activity" = 'Activity A' group by Event_log."Case_ID")
Event_end_activity_A as ( select Event_log."Case_ID", max(Event_log."Event_end") as "Event_end_activity_A" from Event_log where Event_log."Activity" = 'Activity A' group by Event_log."Case_ID")Observação:Neste exemplo, se você quiser selecionar a primeira ocorrência da atividade, substitua max por min.
-
Defina a tabela de tempo de throughput juntando as tabelas de pré-processamento ao log de eventos e calculando o tempo real de throughput.
Dica:Você pode usar a função datediff fornecida no pacote pm-utils para calcular a diferença de tempo entre quaisquer dois eventos finais.
O tempo de transferência deve ser calculado em milissegundos para as instâncias em que a Atividade A precede a Atividade B. Milissegundos são a unidade de tempo usada para definir durações no modelo de aplicativo. Como os tempos de throughput já estão agrupados por caso nas tabelas de pré-processamento, você pode escolher qualquer registro. No exemplo acima, a agregação min é usada. A tabela de tempo de processamento, selecionando o tempo de processamento e uma ID de caso, pode ser definida conforme exibido abaixo.
Cases_with_throughput_times as ( select Event_log."Case_ID", case when min(Event_end_activity_A."Event_end_activity_A") <= min(Event_end_activity_B."Event_end_activity_B") then {{ pm_utils.datediff('millisecond', 'min(Event_end_activity_A."Event_end_activity_A")', 'min(Event_end_activity_B."Event_end_activity_B")') }} end as "Throughput_time_activity_A_to_activity_B" from Event_log left join Event_end_activity_A on Event_log."Case_ID" = Event_end_activity_A."Case_ID" left join Event_end_activity_B on Event_log."Case_ID" = Event_end_activity_B."Case_ID" group by Event_log."Case_ID)"
Cases_with_throughput_times as ( select Event_log."Case_ID", case when min(Event_end_activity_A."Event_end_activity_A") <= min(Event_end_activity_B."Event_end_activity_B") then {{ pm_utils.datediff('millisecond', 'min(Event_end_activity_A."Event_end_activity_A")', 'min(Event_end_activity_B."Event_end_activity_B")') }} end as "Throughput_time_activity_A_to_activity_B" from Event_log left join Event_end_activity_A on Event_log."Case_ID" = Event_end_activity_A."Case_ID" left join Event_end_activity_B on Event_log."Case_ID" = Event_end_activity_B."Case_ID" group by Event_log."Case_ID)"
Cálculo do tempo de produtividade em dias excluindo fins de semana
date_from_timestamp
fornecida no pacote pm-utils para calcular o número de dias entre duas atividades. Além disso, a função diff_weekdays
permite que você filtre dias de fim de semana.
Consulte o exemplo de código abaixo para saber como calcular o número de dias úteis entre a Atividade A e a Atividade B.
with Event_log as (
select * from {{ ref('Event_log') }}
),
Activity_A as (
select
Event_log."Case_ID",
min({{ pm_utils.date_from_timestamp('Event_log."Event_end"') }}) as "Date_activity_A"
from Event_log
where Event_log."Activity" = 'Receive invoice'
group by Event_log."Case_ID"
),
Activity_B as (
select
Event_log."Case_ID",
min({{ pm_utils.date_from_timestamp('Event_log."Event_end"') }}) as "Date_activity_B"
from Event_log
where Event_log."Activity" = 'Pay invoice'
group by Event_log."Case_ID"
),
Total_days_minus_weekends as (
select
Activity_A."Case_ID",
Activity_A."Date_activity_A",
Activity_B."Date_activity_B",
{{ pm_utils.diff_weekdays('Activity_A."Date_activity_A"', 'Activity_B."Date_activity_B"') }}
-- Only compute for cases where both dates are known.
from Activity_A
inner join Activity_B
on Activity_A."Case_ID" = Activity_B."Case_ID"
)
select * from Total_days_minus_weekends
with Event_log as (
select * from {{ ref('Event_log') }}
),
Activity_A as (
select
Event_log."Case_ID",
min({{ pm_utils.date_from_timestamp('Event_log."Event_end"') }}) as "Date_activity_A"
from Event_log
where Event_log."Activity" = 'Receive invoice'
group by Event_log."Case_ID"
),
Activity_B as (
select
Event_log."Case_ID",
min({{ pm_utils.date_from_timestamp('Event_log."Event_end"') }}) as "Date_activity_B"
from Event_log
where Event_log."Activity" = 'Pay invoice'
group by Event_log."Case_ID"
),
Total_days_minus_weekends as (
select
Activity_A."Case_ID",
Activity_A."Date_activity_A",
Activity_B."Date_activity_B",
{{ pm_utils.diff_weekdays('Activity_A."Date_activity_A"', 'Activity_B."Date_activity_B"') }}
-- Only compute for cases where both dates are known.
from Activity_A
inner join Activity_B
on Activity_A."Case_ID" = Activity_B."Case_ID"
)
select * from Total_days_minus_weekends
Cálculo do tempo de produtividade em dias excluindo feriados
Siga as etapas abaixo para calcular o tempo de produtividade em dias entre a Atividade A e a Atividade B , excluindo fins de semana e feriados.
Holidays.csv
para definir os dias que devem ser contados como feriados. O arquivo precisa conter pelo menos um registro para cada feriado. Use o seguinte formato:
feriado |
Data |
Dia útil |
Dia de ano novo |
2024-01-01 |
Sim |
Páscoa |
31-03-2024 |
Não |
.. |
.. |
.. |
Holidays.csv
são usados para contar o número de dias que precisam ser excluídos de um intervalo de datas.
Holidays.csv
como um arquivo semente no projeto dbt . Para informações detalhadas, consulte a documentação oficial do dbt sobre semente jinja.
date_from_timestamp
e diff_weekdays
fornecidas no pacote pm-utils conforme descrito acima em Cálculo do tempo de produtividade em dias excluindo fins de semana .
.csv
feriados que se enquadram no intervalo de datas fornecido para cada caso. Veja o código de exemplo abaixo.
Holidays_count as (
select
Total_days_minus_weekends."Case_ID",
count(Holidays."Date") as "Number_of_holidays"
from Total_days_minus_weekends
left join Holidays
on Holidays."Date" between Total_days_minus_weekends."Date_activity_A" and Total_days_minus_weekends."Date_activity_B"
where Holidays."Weekday" = 'Yes'
group by Total_days_minus_weekends."Case_ID"
)
Holidays_count as (
select
Total_days_minus_weekends."Case_ID",
count(Holidays."Date") as "Number_of_holidays"
from Total_days_minus_weekends
left join Holidays
on Holidays."Date" between Total_days_minus_weekends."Date_activity_A" and Total_days_minus_weekends."Date_activity_B"
where Holidays."Weekday" = 'Yes'
group by Total_days_minus_weekends."Case_ID"
)
Weekday = 'Yes'
é usado para não subtrair feriados quando o feriado ocorre em um sábado ou domingo. Isso já foi resolvido na função diff_weekday
.
5. Subtraia o número calculado de feriados do número total de dias contados para cada caso. Veja o código de exemplo abaixo.
Total_days_minus_weekends_and_holidays as (
select
Total_days_minus_weekends."Case_ID",
Total_days_minus_weekends."Number_of_days" - Holidays_count."Number_of_holidays" as "Number_of_days_between_dates"
from Total_days_minus_weekends
inner join Holidays_count
on Total_days_minus_weekends."Case_ID" = Holidays_count."Case_ID"
)
Total_days_minus_weekends_and_holidays as (
select
Total_days_minus_weekends."Case_ID",
Total_days_minus_weekends."Number_of_days" - Holidays_count."Number_of_holidays" as "Number_of_days_between_dates"
from Total_days_minus_weekends
inner join Holidays_count
on Total_days_minus_weekends."Case_ID" = Holidays_count."Case_ID"
)
Depois que a tabela de tempo de processamento é criada, esta tabela precisa ser unida à tabela Casos para adicionar os dados de tempo de processamento adicionais como informações de caso. Para ter o novo campo de tempo de produtividade disponível nos painéis, é necessário converter o novo campo de tempo de produtividade para um dos campos personalizados de duração do caso.
Substitua uma das linhas de duração de caso personalizadas na tabela Casos que se parece com isto:
{{ pm_utils.optional(ref('Cases_base'), '"custom_case_duration_1"', 'integer') }} as "custom_case_duration_1",
{{ pm_utils.optional(ref('Cases_base'), '"custom_case_duration_1"', 'integer') }} as "custom_case_duration_1",
com o tempo de throughput recém-criado:
Cases_with_throughput_times."Throughput_time_activity_A_to_activity_B" as "custom_case_duration_1",
Cases_with_throughput_times."Throughput_time_activity_A_to_activity_B" as "custom_case_duration_1",
As atualizações nas transformações para a métrica de tempo de throughput customizado agora são feitas e podem ser importadas para o modelo de aplicativo.
Quando você cria um tempo de rendimento personalizado em suas transformações, ele fica disponível em seu modelo de aplicativo como uma propriedade de caso em seu alias. Você pode personalizar seu aplicativo de processo para criar uma métrica de tempo de rendimento com base no tempo de rendimento personalizado que você criou nas transformações.
Por padrão, um novo campo de duração personalizado é adicionado como um campo do tipo numérico. Certifique-se de editar o campo e alterar o Tipo do novo campo para duração. Consulte também Gerenciador de dados.
- Acesse Data Manager e crie uma métrica.
- Selecione o campo de duração personalizado a ser usado para o tempo de rendimento e selecione Média ou qualquer outra agregação desejada. Você também pode renomear o campo personalizado de duração do caso com o nome desejado no Gerenciador de dados.
- Edite o aplicativo e coloque a nova métrica nos gráficos onde deseja disponibilizá-la para usuários corporativos.
- Publique os painéis para disponibilizar a métrica de tempo de rendimento nos painéis.
Nos modelos de aplicativo Purchase-to-Pay e Order-to-Cash, um cálculo de tempo de processamento já está disponível em Purchase_order_items_with_throughput_times e Sales_order_items_with_throughput_times, respectivamente. Tempos de produção customizados podem ser adicionados lá e disponibilizados como uma duração customizada em Purchase_order_items ou Sales_order_items.