Cansei de pagar o pato: quero gerenciar as mudanças na minha TI!

Normalmente, a reflexão começa dessa forma, diferente do seguro do carro, que optamos em ter antes de precisar, o Gerenciamento de Mudanças surge após uma experiência negativa na qual pudemos refletir o que poderia ter sido feito para evitar um transtorno.

Minha experiência com Gerenciamento de Mudança começou da mesma forma. Após alguns anos administrando uma infraestrutura complexa onde o gerenciamento de serviços era deixado de lado para dar espaço ao gerenciamento operacional, percebi que sempre que algo saía do eixo após uma nova implantação, manutenção ou incidente qualquer, eu acabava pagando o pato por não ter previsto o que poderia dar de errado. Nessas horas, não importam os culpados, a responsabilidade é só de um.

A opção por gerenciar mudanças no ambiente abre um leque de quesitos antes da primeira reunião de mudança — o tal Comitê.

Da decisão às primeiras ações

Já estava precisando de uma solução para meus problemas dois anos antes de dar o primeiro passo. Esse espaço de tempo se deu unicamente por falta de conhecimento e recursos para pedir consultoria. Usei esses dois anos basicamente para me capacitar. No final, descobri que daria uma trabalheira, mas não seria um bicho de sete cabeças.

Minha primeira decisão concreta foi fazer um self assessment (auto avaliação) com base no questionário do ITSMF feito na época da ITIL v2. Uma simples planilha em Excel, com itens categorizados por processos de gerenciamento de serviços (Incidentes, Problemas, Configuração, Mudança…) e que calcula a maturidade desses processos de 0 a 5 pontos. Preenchida a planilha, passei por uma fase de autorreflexão (essa não tem termo em inglês porque é muito pessoal!), me questionando o tamanho da encrenca que eu estava me metendo e se eu teria disposição ou não para tocar o projeto.

A autorreflexão foi essencial em nível pessoal, já que era uma decisão de querer criar algo que ninguém estava demandando. Eu queria fazer para melhorar o trabalho de minha área. Ao ver as notas da auto avaliação, minha expectativa foi ao chão. Veja o quadro abaixo.

Processo Nota
Gerenciamento de Mudança 2,0
Gerenciamento de Liberação 2,0
Gerenciamento de Incidentes 1,5
Gerenciamento de Problemas 1,5
Gerenciamento de Configuração 1,5
Gerenciamento de Disponibilidade 1,5
Gerenciamento de Nível de Serviço 1,0
Gerenciamento Financeiro 1,0
Gerenciamento da Continuidade 1,0
Gerenciamento de Capacidade 1,0

 

Vendo os números, vejo um caos, mas para entender o que significa cada nota, basta comparar com a tabela abaixo.

NÍVEIS DE MATURIDADE
Nível Descrição
1 Pré-requisitos Verifica se os itens mínimos obrigatórios estão disponíveis
1.5 Objetivo da Administração Verifica se há política organizacional e objetivos de negócio declarados
2 Capacidade do Processo Verifica se há um conjunto mínimo de atividade sendo executadas
2.5 Integração Interna Verifica se tais atividades estão suficientemente integradas entre si
3 Qualidade do Produto Verifica o resultado real do processo, se todo os produtos relevantes estão sendo produzidos
3.5 Controle de Qualidade Verifica o resultado do processo para garantir os objetivos de qualidade
4 Gerenciamento da Informação Verifica se as informações necessárias à tomada de decisão pela Administração estão sendo geradas pelo processo
4.5 Integração Externa Verifica se todas as interfaces e relações externas ao processo foram estabelecidas na organização
5 Interface com o Cliente Verifica de forma contínua se o processo continua atendendo as necessidades do cliente, ou seja, das áreas de negócio da organização

 

Na verdade, não havia caos. A nota 1 já era inspiradora, 2 então… Analisando o placar, percebi que começar por um processo com melhor nota teria mais chances de sucesso, visto que haveria menos passos a dar e os ganhos rápidos existiriam. Tocar um projeto quase às cegas como o meu, sem vislumbrar um ganho a curto prazo poderia ser uma poda na minha autoestima e, consequentemente, fracasso. Vendo as notas (TABELA 1), consegui ter noção de qual passo estava meio-maduro em minha gestão: o controle das mudanças e das liberações para produção.

As boas notas em Gerenciamento de Mudança e Gerenciamento de liberação era uma caraterística de minha empresa. Aqui, os processos de TI foram inicialmente formalizados em um Sistema de Gestão da Qualidade (SGQ) e, por isso, havia algum comprometimento com algumas atividades que coincidiam com processos de gestão de serviços de TI. Pura coincidência? Não… ou nem tanto.

Na época em que o SGQ estava sendo implantado, já havia rumores ou intenções individuais em se entender um pouco mais sobre Gerenciamento de Serviços de TI. Com as informações latentes na memória, naturalmente, foram brotando vestígios da ITIL, do CobIT e mesmo de algumas ISOs que estávamos lendo no desenho dos processos do SGQ. Essa influência, portanto, deu início ao que chamo de Cultura Gerencial, que antes ignorávamos.

Nem todos os processos de Gerenciamento de Serviços de TI tinham rastros em nosso SGQ, o que explica as notas abaixo de 2,0. Desses com alguma influência, certamente, o Gerenciamento de Mudanças e o de Liberações eram os mais aderentes ao nosso SGQ, porque, segundo a auto avaliação, “há um conjunto mínimo de atividade sendo executadas”. A escolha pelo Gerenciamento de Mudanças como primeiro passo foi uma decisão segura e não uni, duni, tê. O Gerenciamento de Mudanças aparecia no SQG como um procedimento (uma caixinha) no processo de Implantação de Novos Produtos (para nós, PR-001), enquanto o Gerenciamento de Liberações era praticamente o motivador do PR-001. Assim, consideramos que um processo já estava em uso e oficializado, e o outro precisa ser aprimorado, tornando-se um procedimento apartado e abrangente.

Comecei a tocar o projeto a pleno vapor. Minhas ferramentas para tanto eram os dois livros principais da ITIL v2 (Service Support e Service Delivery), alguns livros de apoio, blogs e disposição.

As ações imediatas foram:

  • Criação e formalização de um processo de Gerenciamento de Mudança
  • Divulgação de uma cultura de Gerenciamento de Mudança (hábitos)
  • Um pouco de intransigência disfarçada em burocracia (a má vontade)

Criação e formalização de um processo de Gerenciamento de Mudança

A criação de um processo pode ser entendida como a simples diagramação de um fluxo de informações, onde cada ação a ser tomada está prevista (fluxograma). Porém, não adianta simplesmente desenhar. O desenho é uma ferramenta para documentar e divulgar o processo.

O fluxograma

O fluxograma que adotei foi retirado do livro de Service Support que compõe a ITIL v2. Fiz pouquíssimas adaptações, omitindo etapas não adequadas à minha realidade.

Com o fluxo estabelecido, formalizei o processo lançando mão do SGQ que era o único sistema de gestão formalizado na empresa.

Divulgação de uma cultura de Gerenciamento de Mudança (hábitos)

Processo e procedimento são juntos a parte fácil de qualquer iniciativa. Torná-los práticas constantes é o grande desafio.

Com a experiência de iniciativas fracassadas, cujos esforços desperdiçados deixaram a desmotivação como marca, precisei reavaliar meus medos. Não é papo filosófico, não. Aprender com o fracasso é mais eficaz que experimentar logo o sucesso. O sucesso fácil não nos faz superar dificuldades, vícios e medos. Só o fracasso de fato nos testa, põe à prova nossas crenças e conhecimentos. E a coisa que ficou latente na derrota de outros processos que tentei estabelecer foi sem dúvida entender a necessidade do hábito no ciclo de vida do processo.

Quando falo de hábito, não falo do cumprimento ortodoxo ou regimentado de um processo, como ocorre com rotinas obrigatórias em nossas vidas que fazemos simplesmente porque mandam. Falo especificamente do hábito como prática válida, que executamos porque acreditamos ser necessária para o bom funcionamento do sistema, da corporação ou mesmo de um pequeno grupo que compomos. Hábito é perceber a importância de uma ação.

No meu caso, o hábito foi uma meta que busquei atingir pelo estabelecimento de uma cultura corporativa. Essa parte foi difícil, porque dói, implica em mudar pessoas e não apenas processos. Em resumo, criar o hábito do gerenciamento das mudanças era eliminar maus hábitos que fragilizavam nossas operações.

Eu cito cinco etapas vencidas para a criação de uma cultura de gerenciamento de mudanças. Ainda que tenham sido observadas em um projeto específico, acredito que tais etapas sejam realidade para qualquer desafio em grupo.

  1. Acreditar verdadeiramente na necessidade e utilidade do processo;
  2. Divulgar de forma clara o processo de Gerenciamento de Mudança;
  3. Ser ortodoxo com o processo;
  4. Ouvir sugestões e indicações de melhorias;
  5. Esperar o tempo passar.

Essas etapas ocorreram exatamente nessa ordem. A primeira é a que nasce em você e só depende de você. A segunda depende de apoiadores que consegui com muito esforço. A terceira é indispensável para que o processo seja consolidado, ou seja, se houver flexibilidade no início, vão surgir vários processos paralelos e aquele que foi originalmente concebido existirá apenas no papel, portanto, faça-o ser cumprido por mais chato que possa ser. Como foi cumprido à risca desde o início, a quarta etapa surgiu naturalmente pela necessidade de gerar melhoria, foi quando percebi que o processo é um ser vivo. A quinta e última etapa é onde tudo pode ir por água abaixo: esperar o tempo passar para ver o ser vivo amadurecer.

Até aqui, quase três anos depois, ainda estou vendo bons resultados.

Um pouco de intransigência disfarçada em burocracia (a má vontade)

Acredito que exista uma grande variedade de fórmulas para começar um Gerenciamento de Mudança, mas a minha foi assim: precisei bancar o durão, o cara intransigente que estava dificultando as coisas.

Qualquer mudança precisava passar por uma sequência de aprovações, com formalização do “de acordo” do CCM (Comitê Consultivo de Mudanças). Mas, com frequência, batiam alterações “urgentes” para serem executadas sob a encomenda de uma história ruim de algum cliente passando por certas dificuldades com os sistemas. Eu respirava fundo e, munido da minha verdadeira crença no processo (etapa 1), dizia “a mudança não está autorizada”. Eu era odiado naquele minuto, mas como o processo estava amplamente divulgado (etapa 2), o demandante não podia se fazer por desavisado. Havia uma sequência de aprovações que eu não poderia abrir mão: nada de ideologia do favor; adeus corporativismo… eu fui realmente odiado por algum tempo.

Acho que essa fase de ódio durou poucos meses (dois ou três… talvez quatro). As áreas mais afetadas eram o Desenvolvimento e Pós-Venda. Para piorar a relação, toda vez que um desvio ocorria, lá eu ia evidenciar faltas de cumprimento do processo. As faltas mais comuns eram:

  1. Aprovações sem conhecimento da mudança: quando o demandante não era questionado e uma mudança acabava por ser aprovada na base da confiança;
  2. Aprovações do tipo “la garantía soy yo”: quando mediante um risco iminente e grave o demandante se colocava como garantia;
  3. Aprovações “laranjas”: quando uma mudança era aprovada, mas outra não declarada ia de carona para mascarar estouro de prazos, esquecimentos, testes em produção…

Conclusão

Mudanças em TI são antes de tudo mudanças de hábitos, mudanças comportamentais e mudanças de mentalidade. Não há mudanças em ambientes computacionais sem que haja crença no processo, fidelidade ao processo e vontade de ver o processo funcionar.

Passada a fase em que fui odiado, uma fase de paz e crescimento mútuo surgiu do respeito ao processo de mudanças. Muitos downtimes deixaram de acontecer, dando espaço a mais planejamento e responsabilidade com as entregas. A transformação de mudanças emergenciais em mudanças programadas fez uma mudança no gráfico: antes do processo amadurecer, 70% das mudanças eram para ontem e 30% eram para hoje. Hoje, 90% das mudanças são para semana que vem e 10% podem ser hoje ou amanhã. Incrível!

Posso afirmar pela minha crença e experimentação do processo que a principal meta alcançada foi ver a minha organização mudar.

Comentários

comentarios

Cleber Sousa
na