O modelo aqui desenvolvido visava uma técnica para a identificação de descolamentos de áreas ‘inferiores’ na hierarquia da empresa (por ex: centro de custo) em relação à sua 'superior' (por ex: fábrica) quanto às diversas métricas de absenteísmo. Foi construído um modelo para identificar outliers através de um teste estatístico que gerasse como resultado uma métrica que pudesse responder à questão identificando esses descolamentos como mero acaso ou se estes são estatisticamente significativos, de forma que para estes possamos estabelecer uma série de alertas.

Tabelas usadas como base

São utilizadas as seguintes tabelas como base nesse workflow:

murabei.absenteismo_database__wide2

Tabela com informações sobre as métricas de absenteísmo, horas previstas e hoas extras. Foram utilizados os seguintes campos:

• modeling_unit_id [int64]: matrícula do colaborador

• hrs_prev [float64]: horas previstas totais para o colaborador no mês de referência

• faltas_injust [float64]: faltas injustificadas, em horas, do colaborador no mês de referência

• falta_abon [float64]: faltas abonadas, em horas, do colaborador no mês de referência

• faltas_just [float64]: faltas justificadas, em horas, do colaborador no mês de referência

• faltas_legais [float64]: faltas legais, em horas, do colaborador no mês de referência

• atestados [float64]: faltas com atestados, em horas, do colaborador no mês de referência

• afastamentos [float64]: faltas com afastamentos, em horas, do colaborador no mês de referência

• faltas_sem_afast [float64]: faltas sem afastamentos, em horas, do colaborador no mês de referência

• total_horas_extras [float64]: total de horas extras realizadas pelo colaborador

• he_folgas [float64]: horas extras trabalhadas em folgas

• time [datetime64]: mês de referência

absenteimo_prep.sap__informacoes_cadastrais

Tabela com as principais organizações cadastrais de cada colaborador bem como as informações relevantes de unidades e fábricas de trabalho, será utilizada para a criação da coluna grupo_divisao posteriormente. Foram usados os seguintes campos:

• modeling_unit_id [int64]: matrícula do colaborador

• descricao_atividade4 [object]: ramo de atividades

• local_fisico [object]: local físico

• centro_de_custo [object]: centro de custo

• time [datetime64]: mês de referência

Descrição dos passos necessários

Para rodar o modelo são necessários alguns passos de preparação de dados, sucedidos pelo modelo em si e um processo para gerar as bases que são utilizadas no PowerBI.

Merge entre as tabelas
Workspace/people-analytics-absenteismo/01__tratamento_inicial/Metas_teste_estatístico/df_testes_estatisticos.py

Entrada:

murabei.absenteismo_database__wide2
absenteimo_prep.sap__informacoes_cadastrais

Saída:

absenteimo_prep.metas_teste_estatistico__modelo_metas

Primeiramente é feito o merge entre as tabelas de entrada, através das chaves time e modeling_unit_id coincidentes nas duas. Assim, obtem-se para cada colaborador no mês de referência suas informações de absenteísmo, horas extras bem como as informações de local de trabalho e divisão a qual pertence.

Tratamento e criação de algumas variáveis de interesse

Workspace/people-analytics-absenteismo/01__tratamento_inicial/Metas_teste_estatístico/data_prep_testes_estatisticos.py

Entrada:

Saída:

Faz um tratamento simples das variáveis e também a criação da variável de interesse grupo_divisao. Consta dos seguintes passos:

1. Filtro do ramo de atividade 4:
   Filtra-se a coluna descricao_atividade4 para trazer apenas os valores: OPERACIONAL, ADMINISTRATIVO e TECNICO
   
   

2. Filtro de colaboradores que possuem horas previstas maior que 0:
   Filtra-se a coluna hrs_prev para trazer apenas os colaboradores que naquele mês de referência possuem horas previstas maior que 0, evitando-se assim de computar como absenteísta colaboradores que não batem ponto, que estejam de férias (e portanto sem horas previstas) entre outros casos similares.
   
   

3. Criação das variáveis de interesse de absenteísmo e horas extras por horas previstas:
   
   

   • faltas_injust-hrs_prev = divisão das colunas faltas_injust/hrs_prev

   • falta_abon-hrs_prev = divisão das colunas falta_abon/hrs_prev

   • faltas_just-hrs_prev = divisão das colunas faltas_just/hrs_prev

   • faltas_legais-hrs_prev = divisão das colunas faltas_legais/hrs_prev

   • atestados-hrs_prev = divisão das colunas atestados/hrs_prev

   • afastamentos-hrs_prev = divisão das colunas afastamentos/hrs_prev

   • faltas_sem_afast-hrs_prev = divisão das colunas faltas_sem_afast/hrs_prev

   • total_horas_extras-hrs_prev = divisão das colunas total_horas_extras/hrs_prev

   • he_folgas-hrs_prev = divisão das colunas he_folgas/hrs_prev
     
     

4. Ajuste e tratamento da variável de ‘local físico':
   
   A variável de local físico continha valores que traziam um código numérico seguido do local propriamente dito, como por exemplo 0006 - FÁB METAIS SP CML. Tratou-se dessa variável para retirar o código numérico e o restante fosse transferido para uma coluna nova chamada divisao.
   
   Assim, no exemplo 0006 - FÁB METAIS SP CML, o código 0006 era jogado fora e ‘FÁB METAIS SP CML’ era transferido para essa nova coluna 'divisão’.
   
   

5. Criação da coluna grupo_divisao:
   
   A partir dos valores da coluna divisao cria-se a hierarquia acima, o grupo_divisao. Os valores usados foram:
   
   

   • HYDRA ARACAJU → Louças

   • FÁB LOUÇAS JUNDIAÍ I → Louças

   • FÁB LOUÇAS RECIFE → Louças

   • FÁB METAIS SP INDL → Metais

   • FÁB METAIS JUNDIAÍ → Metais

   • FÁB AGUDOS → Madeira

   • FÁB LOUÇAS QUEIMADOS → Louças

   • FÁB LOUÇAS PARAÍBA → Louças

   • FÁB ITAPETININGA → Madeira

   • FÁB UBERABA → Madeira

   • FÁB METAIS SP CML → Metais

   • FÁB TAQUARI → Madeira

   • FL UBERABA → Duraflora

   • FL AGUDOS → Duraflora

   • FL ITAPETININGA → Duraflora

   • FL LENÇÓIS PAULISTA → Duraflora

   • FL ESTRELA DO SUL → Madeira

   • FÁB METAIS JACAREÍ → Metais

   • FÁB LOUÇAS SUL → Louças

   • FL BOTUCATU → Duraflora

   • FÁB HYDRA SÃO PAULO → Louças

   • CD TUBARAO → Outros

   • HYDRA TUBARÃO → Louças

   • FÁB LOUÇAS JUNDIAÍ → Louças

   • FÁB LOUÇAS JUNDIAÍ II → Louças

   • FÁB BOTUCATU → Madeira

   • FL PIRATININGA → Madeira

   • FÁB METAIS SP → Metais

   • CD RECIFE → Madeira

   • FL TAQUARI → Duraflora

   • CD BETIM → Outros
     
     Os grupos_divisao resultants foram: Metais, Louças, Duraflora, Madeira e Outros.
     
     Esses tratamentos e a criação dessas novas colunas foram colocados na tabela absenteimo_prep.metas_teste_estatistico__prepared, sendo esta a tabela a ser usada no modelo propriamente dito.
     
     

Criação do modelo

O modelo foi criado em três etapas:

1. Geral -> grupo divisão:
   Workspace/people-analytics-absenteismo/02__modelos/metas_teste_estatístico/teste_geral-grupo_divisao.py

2. Grupo divisão -> divisão:
   Workspace/people-analytics-absenteismo/02__modelos/metas_teste_estatístico/teste_grupo_divisao-divisao.py

3. Divisão -> centro de custo:
   Workspace/people-analytics-absenteismo/02__modelos/metas_teste_estatístico/teste_divisao_centro-custo.py
   
   Entrada:

Todas as três etapas são essencialmente a mesma, diferindo entre si apenas em quais das colunas serão rodados os testes. No primeiro considera-se como hierarquia superior a Dexco como um todo e como hierarquia inferior a coluna grupo_divisao, esta é então hierarquia superior na segunda etapa sendo divisao a hierarquia inferior, finalmente na terceira etapa divisao é a hierarquia superior e centro de custo a herarquia inferior.

As etapas internas do modelo são:

1. Seleção de uma janela de 6 meses:
   A coluna time é varrida em cada iteração do modelo para uma seleção de uma janela de seis meses. A cada interação desloca-se um mês para a frente, e então o modelo é rodado novamente, até ter varrido todo o intervalo de meses disponíveis na base. Assim,
   
   

   • na primeira interação, constam-se os meses de janeiro até junho

   • na segunda interação, constam-se os meses de fevereiro até julho

   • na terceira interação, constam-se os meses de março até agosto
     e assim por diante.
     
     

2. Iteração entre os valores da herarquia superior e da hierarquia inferior
   
   

3. Criação de novas variáveis:
   
   horas_variavel_superior: soma das horas de absenteísmo na hierarquia superior
   horas_esperadas_superior: soma das horas previstas na hierarquia superior
   proporcao_sup: divisão das colunas horas_variavel_superior/horas_esperadas_superior
   
   horas_variavel_inferior: soma das horas de absenteísmo na hierarquia inferior
   horas_esperadas_inferior: soma das horas previstas na hierarquia inferior
   proporcao_inf: divisão das colunas horas_variavel_inferior/horas_esperadas_inferior
   
   

4. As variáveis do modelo:
   
   O modelo em si consiste em uma analogia com o jogo de uma moeda: lança-se uma moeda n vezes e pergunta-se “a moeda é viciada?”.

   
   A analogia consiste em tratar como um lance que deu “cara” cada vez que se registrar um colaborador que naquele mês de referência tenha tido mais faltas que o proporcional registrado na hierarquia superior, ou seja que a variável proporcao_sup. Registra-se como “coroa” o colaborador que tenha faltas abaixo desse limite:
   
   

   • heads → métrica de absenteísmo > proporcao_sup

   • tails → métrica de absenteísmo < proporcao_sup

     métrica de absenteísmo são as métricas fltas_sem_afast, faltas_abon etc

     A proporção heads / heads + tails é a proporção de caras em relação ao total de vezes que essa ‘moeda’ foi lançada. E esse valor será usado para o teste estatístico tendo a hierarquia superior como moeda de referência.
     
     

Após isso, verifica-se a quantidade de ‘caras’ e ‘coroas’ na hierarquia inferior e verifica-se a proporção
heads_inferior / heads_inferior + tails_inferior e obtem-se assim a proporção de ‘caras’ e ‘coroas’ dessa ‘moeda’ na hierarquia inferior. Esse valor será usado para se testar a ‘moeda’ lançada na hierarquia inferior contra a ‘moeda’ lançada na superior e responder à questão proposta acima.

O teste usado é um teste Z entre essas proporções.

Novas variáveis para o dash

A partir dos resultados do modelo, são criadas algumas variáveis para inserção no dashboard e para melhor interpretação pelo cliente.

O resultado do teste estatístico é um número real entre 0 e 1. Quanto mais próximo de zero mais estatisticamente significativo é o resultado para rejeitar a hipótese de que as métricas de absenteísmo observadas nas hierarquias superior e inferior são frutos do acaso, ou seja, a métrica observada está sim se descolando. Por outro lado, quanto mais próximo de 1, podemos dizer que o resultado não é significativo e a métrica não está se descolando.
O limite para se rejeitar a hipótese foi escolhido em 10%, ou seja, resultados de teste Z entre 0 e 0,1 são considerados significativos e devem acender um alerta para aquela unidade. Resultados maiores que 0,1 são considerados não significativos.

Foram criados os valores não significativo, probabilidade alta e probabilidade muito alta para resumir essas considerações. Esses valores devem ser lidos como:

• não significativo: o teste não foi significativo e não se deve acender um alerta para aquela unidade naquela métrica de absenteísmo

• probabilidade alta: a probabilidade de se estar observando um descolamento naquela unidade em relação aos seus pares é alta. Nesse caso, deve-se acender um alerta.

• probabilidade muito alta: a probabilidade de se estar observando um descolamento naquela unidade em relação aos seus pares é muito alta. Nesse caso, deve-se acender um alerta.

Criação das bases de dados que serão consumidas nos dashboards

Workspace/people-analytics-absenteismo/02__modelos/metas_teste_estatístico/teste_merge_resultados_completo.py

Entradas:

Saídas:

Responsável por concatenar as tabelas resultantes dos modelos e a criação de uma base final contendo todos os resultados, todos os valores de testes e todas as bandeiras (não significativo, probabilidade alta e muito alta) etc.

O script também é responsável por ajustar as variáveis para que fiquem em um formato mais executivo para ser apresentado no dashboard.