Mensurando o ROI do Change Management (1/2)
O Problema
Há alguns anos, atuei como consultor responsável pela frente de melhoria de processos de negócios em um projeto de transformação organizacional de grande escala e alta complexidade.
Somente para dar uma noção do que acabo de dizer, todo o projeto envolvia 6 países, 2 continentes, 6 macro processos, que precisavam ser totalmente redesenhados e harmonizados entre esses países, 4 novas ferramentas, algumas migrações de dados e dezenas de cenários de uso envolvendo diversas combinações de país, processo, ferramenta e outras variáveis próprias do negócio que não posso mencionar por respeito à confidencialidade. Enfim, um projeto realmente desafiador.
A certa altura do projeto, todo o trabalho consultivo de entendimento e modelagem do cenário atual (“As-Is”), análise e desenho dos futuros processos (“To-Be”) havia sido concluído e se aproximava o momento de começar a implementar os novos processos e ferramentas.
Durante a conceituação do projeto, já tinhamos discorrido sobre os benefícios da Gestão de Mudanças (Change Management) e dos riscos decorrentes da decisão de ignorar essa disciplina gerencial em transformações organizacionais, especialmente as mais complexas. Apesar de aceitar os argumentos apresentados, para reduzir os custos, o cliente optou inicialmente por tocar a fase de implantação dos novos processos e ferramentas com sua própria equipe, sem o apoio de consultores externos.
Porém, terminada a consultoria de processos, ao perceber que a empreitada poderia ser mais complexa do que a inicialmente imaginada, as discussões sobre o tema foram reabertas. Foi quando surgiu a seguinte questão: “Como podemos demonstrar, em números, para os executivos que tal serviço é realmente indispensável? Precisamos quantificar o ROI para obter o orçamento necessário”.
Ou seja, o cliente precisava de um Business Case para Change Management. Mas… Como fazer isso?
Compartilharei, então, a experiência que tive na esperança de que abordagem que adotei venha a ser útil àqueles enfrentando o mesmo questionamento.
O Insight
Conforme mencionado, como consequência das discussões prévias, já havia um entendimento compartilhado das consequências qualitativas, digamos assim, do uso ou não de técnicas de Change Management na implantação dos processos e ferramentas. O desafio era, então, quantificar essas consequências.
Sendo assim, posso dizer que o cliente já entendia e aceitava que projetos sem uma estratégia robusta de Change Management estão sujeitos, entre outros, aos seguintes riscos:
- Capacitação inapropriada dos funcionários
- Comunicação ineficiente com os diversos grupos de stakeholders
- Perda de deadlines e entregáveis acordados
- Stakeholders não comprometidos o suficiente com a transformação (resistência à mudança)
- Queda no nível de satisfação dos funcionários
- Disseminação de percepções negativas acerca do projeto
que podem, se não adequadamente eliminados ou mitigados, gerar os seguintes impactos:
- Turnover de funcionários
- Mais tempo para adoção das mudanças e, por tabela, corrigir problemas do cenário atual
- Captura apenas parcial (ou, em casos extremos, a não captura) dos benefícios projetados
- Redução da produtividade da equipe envolvida na transformação pela excessiva demanda decorrente de atividades mal planejadas e retrabalho
- Outros custos adicionais decorrentes de atrasos
e foi a partir deles, tomados como premissas, que elaboramos o Business Case.
Em resumo, a ideia base, o ponto de partida de todo o trabalho, foi determinar quanto custariam os impactos listados acima, caso efetivamente ocorressem. Deste modo, desenvolver o Business Case equivalia a transformar esses impactos em dinheiro.
A abordagem
Quanto custa a perda indesejada de funcionários? Quanto custam para o cliente os problemas atuais e a sua permanência além do necessário? Qual o valor da perda parcial ou total dos benefícios esperados do projeto? Quanto custa a perda de produtividade dos recursos dedicados a um projeto que se estende além do necessário? Estas eram as perguntas que precisavam de respostas.
Não existem instrumentos de medida ou leis (econômicas, matemáticas, físicas, etc.) que permitam medir ou calcular diretamente esses custos. Desse modo, a abordagem passou pela criação de modelos que relacionam alguns parâmetros e variáveis para a sua estimação. Vejamos, então, os modelos criados e o raciocínio empregado na sua elaboração:
- Custo do turnover (CT)
CT = [A] x [B] +[C] x [D]
onde:
[A] é a produtividade de um funcionário (em R$ / hora)
[B] é a perda de produtividade gerada pelo turnover (em horas)
[C] é o número de funcionários perdidos involutariamente
[D] é o custo para recrutar um novo funcionário
com:
[B] = [C] x [E] x (1 - [F])
e
[E] = Horas de trabalho em um certo período
[F] = Fator de produtividade de novos funcionários (em %)
Expliquemos melhor como calcular cada um desses termos.
[C] Número de funcionários perdidos involutariamente
É sabido que algumas transformações ocasionam (e, em muitos casos, até buscam) uma redução do número de funcionários. Quando, por exemplo, após uma automação de processos, resta um excedente de funcionários, sem possibilidade de reskilling e reaproveitamento em outras atividades da organização, a demissão dessas pessoas é parte do processo de mudança e deve ser planejada e conduzida com cuidado e respeito.
O problema é que a mudança pode também acarretar um turnover, ou seja, a saída indesejada do funcionário. Ou seja, pessoas que a empresa planejava manter após a mudança podem optar por solicitar o desligamento (os motivos variam do medo ao desinteresse na nova configuração da organização). Esses casos devem ser minimizados porque geram perda de produtividade (veremos o porquê a seguir) e custos adicionais de seleção e recrutamento (justamente a 2a parcela do CT).
No modelo desenvolvido na ocasião, definimos [C] como sendo:
[C] = [# Funcionários impactados pela mudança] x [Fator de perda]
Com o [Fator de perda], em %, dado por:
[Turnover sem Change Management] - [Turnover com Change Management]
O número de funcionários impactados pela mudança é, via de regra, fácil de se conseguir. No caso específico do projeto em questão, durante o planejamento da transformação, identificamos quantos funcionários executavam os processos-alvo da mudança. Somente em um dos países, cerca de 600 pessoas precisariam adotar os novos processos e ferramentas. Importante destacar que a companhia desejava, ao menos a priori, manter todos esses funcionários ao término da transformação.
O problema foi determinar o [Fator de perda]. Foi impossível, com os recursos e tempo que dispúnhamos na ocasião, encontrar um benchmarking universal que pudesse ser adotado para o caso em tela. Sendo assim, consideramos esse fator como um parâmetro e arbitramos o valor de 2%*. Ou seja, estimamos que o turnover de uma transformação sem Change Management seria, no mínimo, superior em 2% à uma transformação com a aplicação dessa disciplina gerencial. O valor foi considerado aceitável pelo cliente e, assim, adotado na elaboração do Business Case. Deste modo, no projeto em questão e no país mencionado como exemplo, consideramos que cerca de 12 funcionários** solicitariam desligamento indesejado e evitável da organização caso não fosse feita uma gestão adequada da mudança.
* Observe que 2% pode ser um número muito baixo para o seu caso específico. Ao estimar esse parâmetro, considere informações como clima organizacional, histórico de turnover*** em transformações semelhantes e o nível de ‘agressividade’ da transformação. Automação massiva de processos, elevado número de demissões planejadas (evidente ou previsível), histórico de clima organizacional ruim e/ou transformações mal-sucedidas, previsão de redução de estrutura organizacional e/ou posições de liderança, remanejamento de times para outras regiões e fusão com outra organização são alguns dos fatores que aumentam a percepção de ‘agressividade’ de uma transformação por parte dos funcionários;
** No cálculo de [C], o termo [# Funcionários impactados pela mudança] deve considerar somente os funcionários que se deseja manter após a mudança;
*** Estatísticas demissionais podem ser conseguidas com o RH e correlacionadas com um histórico de projetos. Sabemos que pode ser difícil, mas se for possível obter a causa raiz da saída de cada funcionário e considerar somente aqueles que se desligaram por razões associadas às transformações realizadas, melhor ainda.
[F] Fator de produtividade de novos funcionários
O tempo necessário para um novo funcionário se tornar totalmente produtivo varia com uma série de fatores, mas uma coisa se pode dizer: ele não é igual a zero. A Training Industry Quarterly, em artigo de 2012, avaliou que levará algo entre 1 e 2 anos para que um novo funcionário se torne totalmente produtivo. No modelo desenvolvido, consideramos, também em consenso com o cliente, que os novos funcionários trabalhariam por 1 ano com, na média, 80% da produtividade daqueles que eles substituíram.
[E] Horas de trabalho em um certo período
Como nos interessava estimar a perda de produtividade com a saída indesejada de funcionários e consideramos que somente no primeiro ano de trabalho os seus substitutos apresentariam performance reduzida, definimos essa variável como sendo o número de horas de trabalho deste período, já descontando os finais de semanas e feriados.
[A] Produtividade de um funcionário (em R$ / hora)
Uma maneira bem simples de calcular essa variável, em valores médios, é claro, é através da razão entre a receita líquida da companhia e o total de horas trabalhadas por todos os funcionários em um mesmo período. Não utilizamos essa definição por achar que era demasiado grosseira, especialmente porque o cliente em questão se tratava de companhia fortemente baseada em tecnologia (com faturamento altíssimo e não-exclusivamente associado a recursos humanos).
Para evitar maiores controvérsias sobre a definição de produtividade, preferimos, na ocasião, adotar uma linha extremamente conservadora e tomar como produtividade de um funcionário o menor valor possível: seu próprio salário/hora (incluindo todos os encargos e benefícios). Afinal de contas, se um funcionário não produz nem mesmo o que recebe como pagamento, ele, via de regra, está destruindo valor para a empresa, não gerando.
Sabemos que, em sua maioria, os funcionários produzem mais do que o salário (é o normal em um negócio sustentável), mas nosso objetivo era atingir um consenso rápido sobre o modelo e os valores assumidos por seus parâmetros e variáveis. Deste modo, atribuímos a esta variável o salário médio por hora dos funcionários impactados pela mudança. Conforme dito, valor mais conservador do que este é simplemente impossível.
Por fim, o custo para recrutar um novo funcionário (parâmetro [D]) costuma ser facilmente conseguido junto ao Departamento de Recursos Humanos.
- Custo do atraso na resolução de problemas (CARP)
CARP = [G] x [H] x [I] + [J]
onde:
[G] = Percentual estimado da redução de desperdícios (o problema da situação analisada) que seria perdida pelo atraso* na implementação da mudança
[H] = Total de anos (ou meses) em que o projeto poderia atrasar*
[I] = O custo médio dos problemas por ano (ou mês) com base nos valores do Business Case do projeto para o período [H]
[J] = O custo do problema** nos anos que, devido ao atraso*, deixarão de fazer parte da janela original de avaliação do projeto
Mais uma vez, analisemos cada parâmetro e variável separadamente:
[I] Custo médio dos problemas para o período [H]
Para determinar se o projeto deveria ou não ser realizado, o cliente já tinha elaborado previamente um Business Case — que adjetivaremos doravante de BCP, para diferenciá-lo do Business Case para o Change Management, BCCM — onde listou seus custos e ganhos projetados com o projeto. Dessa forma, já dispúnhamos de uma expectativa de quanto dos desperdícios de recursos, o problema no caso desse cliente específico, se esperava reduzir ano a ano no horizonte de 5 anos considerado para a análise de viabilidade econômica e de retorno do projeto.
Na ocasião, como valor desse parâmetro, tomamos a redução esperada de desperdícios (em valores monetários, naturalmente) ao longo de um período de tempo igual ao atraso estimado* que estimamos para implementação plena dos novos processos e ferramentas (justamente o parâmetro [H], que descreveremos a seguir).
* consideramos somente o atraso que avaliamos poderia ocorrer como consequência de um Change Management mal realizado
** o desperdício de recursos, conforme já mencionamos
[H] Tempo estimado de atraso do projeto
Aqui partimos da premissa que a adoção dos novos processos e ferramentas levaria mais tempo do que as estimativas originais caso a etapa de implementação/adoção desconsiderasse um suporte especializado em Change Management.
No caso específico do projeto do qual participei, desde a sua concepção foi planejado que o seu primeiro ano corresponderia ao trabalho de entendimento dos processos “As-Is” e desenho dos processos “To-Be” e o seu segundo ano à implementação destes últimos. Os demais anos seriam para captura dos benefícios esperados, aqueles que justificaram a realização do próprio projeto.
Quando estávamos discutindo o Business Case para o Change Management (BCCM), avaliamos a complexidade do trabalho a ser realizado e concluímos que, sem o suporte de especialistas, a implementação precisaria de 2 anos para ser finalizada completamente. Ou seja, consideramos um atraso de 1 ano com relação ao prazo original. O racional apresentado foi aceito pelo cliente que nos permitiu considerar esse número em nosso Business Case (BCCM).
[G] Percentual médio da redução/eliminação do problema perdido pelo atraso
Já argumentamos que atrasos nas mudanças impactam a captura dos benefícios. Por outro lado, mesmo um projeto com atrasos pode gerar alguns retornos. Sendo assim, decidimos na ocasião considerar uma perda apenas parcial dos benefícios a serem capturados no terceiro ano de projeto, ano adicional de implantação decorrente do atraso [H]. Para a elaboração do Business Case (BCCM), estimamos essa perda em cerca de 15%.
[J] O benefício não capturado (no prazo de avaliação) devido ao atraso
Por outro lado, há certos atrasos que impossibilitam a captura por completo do benefício previsto no Business Case do Projeto (BCP) durante a sua ocorrência. Nessas situações, existe a perda do benefício que se esperava capturar em um período de tempo igual ao atraso no final da janela de avaliação do projeto.
Confuso? Vamos tentar esclarecer. Imagine que um projeto de 12 meses foi aprovado a partir do seguinte Fluxo de Caixa Projetado, desenvolvido para a análise de viabilidade do projeto:
Se considerarmos uma taxa mínima de atratividade de 1% ao mês, temos que o VPL do projeto é de aproximadamente +319.5 K. Ou seja, a princípio, o projeto é viável economicamente. Note que a janela de avaliação do projeto foi de 12 meses e a primeira entrada positiva do fluxo de caixa foi prevista para acontecer no sexto mês. Se esse projeto atrasar 1 mês, sem nenhuma captura de benefícios durante esse tempo, vejamos o que acontece com seu fluxo de caixa projetado:
Observe que, além da perda do benefício esperado no sexto mês (recuperada, nesse exemplo, no sétimo mês), temos a perda da captura do benefício previsto para o décimo-segundo mês (ambos em vermelho tracejado no diagrama acima). Essa é a parcela [J] do modelo proposto.
Obs.: É claro que:
(i) aqui estamos considerando uma janela de avaliação rígida, condição que, mesmo em tempo de projetos ágeis e “eterno beta”, entendemos ser necessária para análise do retorno de um investimento.
(ii) o benefício previsto para o décimo-segundo mês não será efetivamente perdido, mas será capturado um mês depois, já fora da janela de avaliação original, portanto. Naturalmente que, se a captura de um benefício depende de algum fator temporal irrepetível, este será perdido de maneira definitiva;
(iii) existem projetos onde é possível recuperar, ainda no intervalo de tempo determinado para a avaliação do projeto, parte, ou mesmo a totalidade, dos benefícios originalmente previstos e perdidos por atraso. Todavia, estamos aqui (1) trabalhando com modelos e (2) na busca de uma estimativa. Tudo vai depender das premissas consideradas no processo de modelagem. Falaremos sobre isso no item (v).
(iv) A medida real do retorno de um projeto só será conhecida efetivamente ao término do período considerado para sua avaliação, quando todos os dados estiverem disponíveis, e sempre levará em conta as regras definidas para lidar com as excepcionalidades definidas ainda no tempo de sua análise de viabilidade.
(v) o uso dos parâmetros [G], [H], [I] e [J] dependem da natureza e riscos específicos do projeto que você está buscando estimar os possíveis prejuízos decorrentes de falhas no processo de mudança. Estas características determinarão as premissas mais adequadas e, consequentemente, os valores dos parâmetros listados acima. Cada situação concreta demanda uma análise individualizada e, dessa maneira, os parâmetros aqui listados devem ser entendidos como componentes que podem estar ou não presentes no SEU modelo final.
(vi) desconsideramos, nesta parcela, custos adicionais que poderiam ocorrer devido ao atraso (discutiremos esse custo mais adiante)
- Custo da captura parcial dos benefícios planejados (CCPB)
Sabemos que, infelizmente, existem projetos que, mesmo após os atrasos e esforços adicionais, entregam somente parte de seu escopo original. Tomando como exemplo a situação em tela, imaginemos que alguns dos casos de uso originalmente considerados não foram implementados no prazo de avaliação do projeto. Essa seria uma entrega parcial e, consequente, resultaria numa captura também parcial dos benefícios projetados. É esse custo que a parcela CCPB do modelo buscou estimar. Fizemos isso definindo-a da seguinte maneira:
CCPB = [M] x [K]
onde:
[K] é o total de benefícios que ainda se espera capturar
[M] é o percentual dos benefícios que ainda se espera capturar sob risco de perda
Analisemos cada parâmetro e variável:
[K] Total de benefícios que se ainda espera capturar
Essa variável é semelhante a [I] e também se obtém do Business Case do Projeto (BCP). O ponto de atenção aqui é que o período correspondente ao atraso e o fator [J] devem ser desconsiderados do cálculo de [K], por isso o “ainda” em destaque. Deve ser assim para que se evite a contabilização duplicada de um mesmo custo potencial. Mais uma vez, o diagrama de Fluxo de Caixa Projetado (já com os possíveis atrasos estimados) utilizado como exemplo ajudará a esclarecer.
No planejamento desse projeto, estimava-se capturar (e, aqui, não estamos trazendo a valor presente) 900 K em benefícios até o final do período de avaliação (12 meses). Considerando que o projeto atrasou 1 mês (sem captura de nenhum benefício durante esse período) e, portanto, 250 K dos benefícios projetados (para os meses vindouros) foram perdidos (supondo que sejam irrecuperáveis, naturalmente), restam 650 K passíveis ainda de serem capturados no período de avaliação do projeto (consideramos que esta não é extensível, por definição), sendo este o valor de [K].
Nota: No projeto para o qual desenvolvemos esse modelo, estimamos [K] através da soma das reduções de desperdícios anuais ainda passíveis de serem capturadas após o atraso estimado [H] (segundo os valores projetados no Business Case do Projeto).
[M] Percentual dos benefícios que ainda se espera capturar sob risco de perda
Baseado em uma análise de complexidade dos casos de uso a serem implementados, da capacidade (capacity e capability) disponível para execução do projeto e do atraso estimado, concluímos que, se o projeto atrasasse 1 ano, como estimamos na ocasião, cerca de 10% dos casos de uso correriam risco de serem implementados de maneira aquém do necessário para gerar os benefícios originalmente previstos. Consideramos então [M] igual a 10%.
Por fim, vale destacar que podemos interpretar esse fator como uma estimativa da perda de qualidade na implementação em decorrência de uma mudança mal gerenciada.
- Custo da perda de produtividade da equipe do projeto (CPPE)
Esse é um custo muitas vezes negligenciado, mas bastante importante em projetos com problemas de execução. Ele é oriundo do tempo extra (o atraso [H] de nosso modelo) que recursos da organização precisam dedicar para estabilizar um “projeto problema” e cumprir com as entregas previstas no plano. Durante esse período, não raro, as atividades regulares desses recursos são prejudicadas, horas-extras são realizadas e a produtividade dos membros do time de projeto em suas atividades funcionais tende a cair.
No projeto ao qual fazemos referência neste artigo, definimos esse fator da seguinte maneira:
CPPE = [N] x [O] x [P]
onde:
[N] é a produtividade média dos recursos da organização envolvidos nas atividades de mudança
[O] é a quantidade de homens x hora dedicadas pelos recursos da organização às atividades de Gestão de Mudança
[P] Fator de impacto do atraso estimado nas atividades
Analisemos os parâmetros ainda não definidos, [N] e [O]:
[N] Produtividade média dos recursos da organização envolvidos nas atividades de Change Management
A exemplo do que consideramos para o parâmetro [A] (produtividade de um funcionário em R$ / hora), utilizamos uma média dos salários pagos aos recursos envolvidos nas atividades de Change Management — o que incluiu, na ocasião, também os afetados pelas mudanças — como sendo o valor deste parâmetro.
Não é nem de perto uma boa estimativa da produtividade real, mas foi o critério acordado com o cliente.
Nota: O uso da mediana no lugar da média pode ser mais adequado em cenários com outliers que distorçam muito a média.
[O] Quantidade de homens x hora dedicadas ao Change Management
Considerando o tamanho da Comunidade de Mudanças (na ocasião, previsto para 5% do time afetado pela mudança) e uma alocação média de cerca de 20% das horas de trabalho diárias (8 horas) às atividades de Change Management, chegamos a uma estimativa desse parâmetro ao longo do prazo previsto no BCP (1 ano) para a implantação dos novos processos e ferramentas. Observe que consideramos os salários dos afetados pela mudança para a estimativa de [N], mas não consideramos as suas horas x homem para o cálculo de [O]. Fizemos assim para balancear possíveis excessos cometidos na estimativa de [N].
Nota: O valor de 20% pode ser considerado alto em mudanças de menor porte, mas foi considerado adequado no projeto em questão devido à sua enorme complexidade e à importância do esforço de Change Management para o sucesso da transformação desejada.
[P] Fator de impacto do atraso estimado
Por fim, para este parâmetro, consideramos que o atraso estimado [H] impactaria em mais 50% no esforço estimado [O] para as atividades de Change Management. Sendo assim, utilizamos [P] = 1.5, também em consenso com o cliente.
- Outros custos adicionais decorrentes de atrasos (OC)
Já nos aproximando do final, temos essa última parcela. Nela podemos contabilizar custos como aluguel de infraestrutura (instalações, equipamentos, etc.) e contratação de serviços necessários para a execução do projeto por tempo além do originalmente considerado no planejamento. Ou seja, todos os custos que não se encaixam nas parcelas anteriores.
No caso do projeto em questão, esse custo foi considerado como sendo igual a zero.
Finalmente, somando todas as parcelas chegamos ao custo estimado dos impactos decorrentes dos riscos aos quais o cliente se submetia. Podemos considerar esse valor como o “Custo Potencial da Decisão de Não Contratar”:
Custo Potencial da Decisão =
[CT] + [CARP] + [CCPB] + [CPPE] + [OC]
Uma observação final. Aqui consideramos um Business Case do Projeto que não sofre alterações por entender que essa é a forma que melhor permite avaliar a qualidade da decisão original de executar o projeto. Naturalmente, atualizações podem ser realizadas sobre o Business Case ao longo das etapas do projeto e, sendo o caso, os valores mais atuais do BCP devem ser considerados na elaboração do BCCM.
Conclusão
Ufa! Chegamos ao final!
Não imaginava que um modelo que levou apenas alguns dias para ser desenvolvido tomaria tantas linhas para ser detalhado em um artigo. Não era a intenção original que houvesse uma parte 2, mas acredito que vale a pena endereçar com calma algumas dúvidas que, provavelmente, muitos leitores tem em mente ao chegar até aqui:
O modelo tem diversos parâmetros cujos valores foram, vamos dizer assim, “chutados”. Como saber se esses valores são de fato razoáveis?
e
Como seus valores afetam o “Custo Potencial da Decisão”?
Essas dúvidas são naturais e também as tivemos, cliente e eu, à época. Sem abandonar a estrutura conceitual da abordagem, caso contrário já estaríamos falando de outro modelo, em um artigo futuro veremos como essas dúvidas foram respondidas. Até lá.