Rolando Bonaccorsi, Diretor de Operações da Vert Analytics, analisa que muita gente acredita que ter um modelo operacional de TI significa desenhar um organograma, com caixas para infraestrutura, desenvolvimento e suporte, ligadas por setas. Essa imagem está incompleta pois o desenho da estrutura é apenas uma das camadas de um modelo que precisa funcionar todos os dias. O organograma mostra quem se reporta a quem, mas não diz como o trabalho flui, quem decide diante de um problema nem como se mede se o serviço entregue está bom.
O que o modelo operacional realmente define?
Um modelo operacional de TI é o conjunto de regras que determina como a área transforma demandas em serviços que funcionam. Ele reúne pessoas e responsabilidades, processos, ferramentas, indicadores e formas de governança. Quando um desses elementos falta, os outros compensam de maneira improvisada, e a operação passa a depender de heróis individuais, que sabem de cor onde cada coisa está e resolvem tudo por memória.
Como reforça Rolando Bonaccorsi, o modelo funciona melhor quando responde a perguntas simples e concretas: quem é dono de cada serviço, como uma solicitação chega e é priorizada, o que acontece quando algo falha e quais números provam que a entrega está dentro do combinado. Se uma dessas respostas depende de alguém que só um colega sabe indicar, a área ainda não tem modelo, tem hábitos que se acumularam com o tempo e que ninguém consegue reproduzir quando a equipe muda.
Mito: um modelo único serve para qualquer empresa
A segunda crença comum é a de que existe um modelo pronto, copiado de uma consultoria ou de uma grande empresa, que basta ser aplicado. Em operações de TI de porte médio, por exemplo, a mesma equipe costuma atender sistemas internos, suporte ao usuário e projetos novos, e isso pede um desenho muito diferente do de uma empresa com times separados para cada frente. Copiar a estrutura de uma organização gigante tende a criar camadas, aprovações e reuniões que o negócio não comporta.
Sob a perspectiva de Rolando Bonaccorsi, referências de mercado servem como vocabulário e ponto de partida, nunca como projeto acabado. O que muda de uma empresa para outra é o tamanho da equipe, a criticidade dos sistemas, o grau de terceirização e a tolerância do negócio a paradas. Um modelo bem escolhido nasce do diagnóstico dessas condições e ganha forma aos poucos, com ajustes a cada ciclo, em vez de chegar completo de uma vez.
Mito: modelo operacional é assunto de gestor, e Rolando Bonaccorsi mostra por que não
O terceiro equívoco é tratar o modelo como documento de gestão, guardado em uma pasta e consultado em auditorias. Um modelo que só os gerentes conhecem existe no papel e deixa de existir na prática. Quem atende o chamado, acompanha o monitoramento e acorda de madrugada com um alarme precisa saber qual é o seu papel, a quem recorrer e até onde pode decidir sozinho. Um fluxo de escalonamento que ninguém aprendeu, convenhamos, serve mais como enfeite de parede do que como instrumento de trabalho.
Pela ótica de Rolando Bonaccorsi, a clareza de papéis é o que reduz o tempo perdido nos momentos de tensão. Quando todos sabem quem lidera um incidente, quem comunica à área de negócio e quem registra o que foi feito, a equipe gasta energia resolvendo o problema, e não discutindo de quem é a responsabilidade. Para isso, o modelo precisa ser treinado, revisado e testado em simulações, e não apenas apresentado em uma reunião de lançamento.
Como saber se o modelo está funcionando?
A quarta ideia equivocada é a de que o modelo está pronto quando o desenho é aprovado. Na verdade, ele só se prova em uso, e os sinais costumam aparecer em quatro frentes: a previsibilidade das entregas, a rapidez na resposta a falhas, a qualidade do serviço percebida por quem usa os sistemas e a capacidade de absorver mudanças sem desorganizar a rotina. Indicadores de nível de serviço, os chamados SLAs, acordos que fixam o que se promete entregar e em que prazo, ajudam a medir esses pontos, desde que sejam poucos e tenham dono.
Na leitura de Rolando Bonaccorsi, o erro mais frequente é medir demais e decidir de menos. Um painel com dezenas de números não revela se o modelo funciona, e uma lista curta de indicadores acompanhados com regularidade, discutidos pela equipe e ligados a ações concretas, revela muito mais. Quando um número piora e ninguém sabe quem deve agir, o modelo ainda tem uma lacuna a fechar, e o caminho é voltar às perguntas básicas de responsabilidade, prioridade e resposta a falhas.
O modelo operacional é melhor tratado como algo vivo. Ele muda quando o negócio cresce, quando uma tecnologia nova entra em produção ou quando uma falha grave expõe um ponto cego. Revisar o desenho a cada ciclo, com a participação de quem opera os sistemas, mantém o modelo próximo da realidade e evita que ele envelheça como documento esquecido.
