Colaboradores Entram E Saem Das Organizações De Forma Muito Frequente

O problema real de turnover alto em TI e RH

Quando colaboradores entram e saem das organizações de forma muito frequente, o custo real não é só o recrutamento. É a perda de contexto que acontece entre a saída de uma pessoa e a chegada da próxima. A maioria das empresas trata onboarding como um formulário a ser preenchido e offboarding como uma lista de desligamento. Ambos os processos são feitos de forma reativa, o que gera buracos operacionais que ninguém percebe até que algo quebre. Eu trabalho com gestão de identidade e acesso há anos. Já vi equipe de TI passar mais tempo refazendo acesso do que trabalhando em nada mais produtivo. O ciclo é simples: pessoa entra, ganha acesso manualmente, esquece de documentar, pessoa sai, alguém lembra de remover e o processo de recuperação leva dias. Em environments híbridos com Active Directory, AWS, GCP e ferramentas SaaS espalhadas, isso se multiplica. Um único funcionário pode ter quarenta contas_ativas distribuídas entre plataformas que não conversam entre si.

Colaboradores entram e saem das organizações de forma muito frequente: o que ninguém conta

A primeira coisa que precisa mudar é a mentalidade de que onboarding e offboarding são eventos. Eles são processos que precisam existir independentemente de alguém ter entrado ou saído hoje. Se sua organização depende de um e-mail manual do gestor para iniciar qualquer mudança de acesso, você já tem um gargalo. E quando o turnover é alto, esse gargalo vira congestionamento crônico. Um detalhe que poucas pessoas consideram é a diferença entre desligamento formal e desligamento funcional. Formalmente, a pessoa pode estar ativa no sistema por quinze dias depois de anunciar a saída. Funcionalmente, ela já não está mais no dia a dia. Durante esse período, o acesso dela continua ativo e muitas vezes cresce. Já vi casos onde o acesso de um colaborador que anunciou saída adquiriu permissões adicionais porque foi temporariamente designado para cobrir uma falta. Quando a pessoa sai de verdade, essas permissões extras permanecem lá. Isso é o que chamamos de privilege creep e é um dos maiores vetores de risco em ambientes com alta rotatividade. O workaround que funcinou para mim foi implementar uma revisão periódica de acessos baseada em roles, não em indivíduos. Em vez de tentar acompanhar cada entrada e saída manualmente, definimos perfis de acesso padrão para cada cargo e função. Quando alguém entra, o sistema aplica o role correspondente automaticamente. Quando alguém sai, o role é revogado junto. Sobras de acesso que não se encaixam em nenhum role são sinalizadas para revisão. Isso reduziu o tempo médio de provisionamento de três horas para vinte minutos em casos padrão, e praticamente eliminou acessos órfãos.

Como estruturar isso na prática

Existe uma confusão comum sobre Ferramenta de Gestão de Identidade vs Ferramenta de Gestão de Acesso. A primeira controla quem é a pessoa no sistema. A segunda controla o que ela pode fazer. Ambas precisam existir e precisam se comunicar. Se você tem uma ferramenta de identidade mas não automação de acesso, o cadastro é rápido mas a liberação continua manual. Se tem automação de acesso mas não governança de identidade, você automatiza processos errados com eficiência. A implementação prática segue esta sequência: inventário completo de todos os sistemas que concedem acesso, mapeamento de cada access_path para roles existentes, definição de um catálogo de roles com regras de aprovaçao, e então a automação dos fluxos de entrada e saída conectando o ERP ou sistema de RH aos sistemas de destino via SCIM ou similar. O passo mais difícil não é técnico. É político. Definir roles significa decidir quem pode acessar o quê, e isso toca em áreas sensíveis de poder dentro da organização. Um diretor que sempre teve acesso irrestrito a certos sistemas pode não querer ver esse acesso restringido a um role específico. O consiglio é começar pelos cargos de menor influência política e ir expandindo conforme os resultados aparecem. Quando as equipes veem que o processo de entrada ficou mais rápido e menos burocrático, a resistência diminui naturalmente.

Limitações e cenários onde isso falha

Automação de onboarding e offboarding não é bala de prata. Ela depende criticamente da qualidade dos dados de entrada. Se o sistema de RH lança informações incompletas ou incorretas sobre o cargo e setor do colaborador, a automação vai provisionar acessos errados tão rapidamente quanto provisionaria os certos. A correção manual desses erros em escala consome mais tempo do que o processo manual original em muitos casos. Outro ponto cego é a questão de contractors e fornecedores. Eles geralmente não entram no sistema de RH da empresa e sim em plataformas terceiras de gestão de mão de obra. Ignorar esses fluxos cria uma zona cinzenta onde o acesso é concedido sem rastreamento e revogado nunca. Em uma ocasião, identifiquei que uma empresa estava gerenciando duzentos contractors via uma plataforma que não integrava com seu sistema de identidade principal. O resultado era que esses contractors mantinham acesso a sistemas internos por meses após o término do contrato. A solução foi exigir que a plataforma de contractors emitisse certificados SCIM para o sistema de identidade da empresa, mas isso levou quatro meses de negociação contratual. Também vale mencionar que em organizações com infraestrutura legada que não suportam SCIM ou APIs modernas, a automação fica limitada. Você ainda pode usar scripts ou ferramentas de RPA para interagir com interfaces antigas, mas a confiabilidade cai e a manutenção aumenta. Nesses casos, o ideal é isolar os sistemas legados em uma rede separada com acesso mais restrito, mesmo que isso signifique aceitar algum overhead manual nos casos que realmente não podem ser automatizados.

O que funciona no dia a dia

A rotina operacional que reduz drasticamente o atrito com colaboradores entram e saem das organizações de forma muito frequente envolve três elementos principais. Primeiro, um ticket_unico que inicia tanto onboarding quanto offboarding e rastreia cada step automaticamente. Segundo, revisoes trimestrais de acessos com relatorios automatizados que destacam privilegios ociosos ou excessivos. Terceiro, uma politica clara de que todo acesso temporario tem data de expiracao e é revogado automaticamente, sem excecao. O ticket_unico é o elemento mais subestimado. Na prática, significa que o momento em que o colaborador assina a contratacao ou o termo de rescisao dispara automaticamente um fluxo que notifica TI, segurança, facilities e o gestor. Cada area recebe as instrucoes especificas para seu domínios e o sistema rastreia o progresso. Ninguém precisa ligar para ninguém. Ninguém precisa lembrar de nada. Existem solucoes comerciais como SailPoint, Okta, Microsoft Identity Manager e Ping Identity que oferecem parte ou totalidade dessas capacidades. Para organizacoes menores, ferramentas como Azure AD Identity Governance ou até mesmo fluxos automatizados baseados em Power Automate e ServiceNow podem cobrir necessidades basicas com custo significativamente menor. A escolha depende do tamanho da infraestrutura e do volume de movimentacoes. Uma regra pratica: se sua equipe de TI passa mais de dez horas por semana apenas gerenciando acessos de entrada e saida, a automacao já se paga em menos de um ano.

O resultado final não é perfeito. Acessos manuais ainda vão existir para casos excepcionais. Revisões ainda vão identificar lacunas. Mas o ciclo vicioso de entrada e saída caótica se transforma em um processo previsível onde o tempo médio de provisionamento e desprovisionamento cai de dias para horas, e o risco de acessos órfãos ou excessivos é drasticamente reduzido.