Alinhamento
“Você foi convocado para uma reunião de relacionamento com cliente. Subject: Indisponibilidade do aplicativo de Transporte do dia 03 deste mês.”
Não entendeu. A mais de 10 anos na companhia, ligou para o gerente da área de Fretes e Transporte e perguntou sobre o que era esta reunião.
- “A Ludimilla, da TI, solicitou esta reunião comigo para tratar sobre o problema que tivemos no dia 3. Na real, amigo, nem me lembrava mais, mas enfim, ela disse que era importante para avaliarmos a disponibilidade e SLA da TI junto as áreas usuário. Não entendi quase nada do que ela falou... mas, por via das dúvidas, aceitei... Sabe como é... né.”
José não compreendia aquela abortagem, vinha de um tempo onde a programação, a qualidade e a análise era o mais importante dentro de um CPD do que a burocracia. Não entendia como aquela TI, depois de tantos anos de sucesso, acabou por ter mais burocratas do que técnicos.
Lógica
Não era ingênuo, nem inocente, sua formação técnica e suas especializações mostravam que a TI nos últimos anos havia se transformado. Sabia que metodologias estavam cada vez mais presentes no dia a dia da operação de uma missão crítica e que o famoso “foco no cliente” já imperava a muito nas grandes empresas e suas TIs.
Mas acreditava também que, nada era mais estável que um aplicativo bem desenvolvido, bem implementado e, principalmente, uma boa equipe de técnicos para suporte. Com isso, acreditava, não seria necessário tantas reuniões de alinhamento e relacionamento em sua agenda, já bem ocupada por outros assuntos técnicos e de gerenciamento.
Em poucos meses, aquela TI viu nascer gerencias de relacionamento com clientes, contratos, service desk, transição de serviço, segurança e processos de TI. Eram tantos que nem a TI mais entendia. Ficou imaginando como era o entendimento do resto da empresa.
Mas acreditava também que, nada era mais estável que um aplicativo bem desenvolvido, bem implementado e, principalmente, uma boa equipe de técnicos para suporte. Com isso, acreditava, não seria necessário tantas reuniões de alinhamento e relacionamento em sua agenda, já bem ocupada por outros assuntos técnicos e de gerenciamento.
Em poucos meses, aquela TI viu nascer gerencias de relacionamento com clientes, contratos, service desk, transição de serviço, segurança e processos de TI. Eram tantos que nem a TI mais entendia. Ficou imaginando como era o entendimento do resto da empresa.
José, foi na reunião e lá, foi obrigado pelo gerente de relacionamento a criar um plano de ação para mitigar uma nova ocorrência da indisponibilidade. Ele tentou explicar, em vão, o que tinha acontecido e as ações tomadas. Mas nem o cliente, nem o gerente de relacionamento eram técnicos.
Para ele, aquilo era o caos.
Para ele, aquilo era o caos.
“Oka, eu faço.” Restou.
Nos dias seguintes se debruçou em seus livros de faculdade e capricou no plano. Passou por todas as metodologias disponíveis. Mediu a quebra de SLA, espinha de peixe para as causas, pdca, etc...
Nos dias seguintes se debruçou em seus livros de faculdade e capricou no plano. Passou por todas as metodologias disponíveis. Mediu a quebra de SLA, espinha de peixe para as causas, pdca, etc...
Na reunião seguinte, a apresentação. Novamente o gerente de relacionamento não concordou. Informou que estava técnico demais e que assim ficava difícil para o cliente abstrair a tecnologia.
Processo
Resignado, imaginou o que viria depois. Procurou entender com o gerente de processos de TI o fluxo.
Foi informado, que pela metodologia, o correto seria relacionar o ticket de incidente a um problema. Se houvesse uma solução conhecida, registrado um erro conhecido e fornecido um Workaround ao Service Desk. Se o problema fosse desconhecido, o ticket deveria ser encaminhado para a equipe especialista. Continuou.. A cada semana deveria ocorrer um acompanhamento do ticket aberto. Quando a solução fosse encontrada, abrir uma mudança e depois uma liberação... mas isso, o gerente de transição poderia explicar melhor.. Pois era um processo que ele ainda não conhecia.
Foi informado, que pela metodologia, o correto seria relacionar o ticket de incidente a um problema. Se houvesse uma solução conhecida, registrado um erro conhecido e fornecido um Workaround ao Service Desk. Se o problema fosse desconhecido, o ticket deveria ser encaminhado para a equipe especialista. Continuou.. A cada semana deveria ocorrer um acompanhamento do ticket aberto. Quando a solução fosse encontrada, abrir uma mudança e depois uma liberação... mas isso, o gerente de transição poderia explicar melhor.. Pois era um processo que ele ainda não conhecia.
Respirou e se deu conta, que a partir daquela data, a TI seria assim, burocratica e complexa. Não tecnicamente, mas... internamente.
Lembrou dos técnicos... sem técnicos, pensou, será o caos. “Vou viver fazendo Powerpoints e planos de ação”.
A tristeza naquele dia foi tanta que acabou indo embora mais cedo. Lembrou das implantações de TI realizadas nos anos anteriores e por pouco não caiu em lágrimas.
Nos dias que se seguiram todos notaram a diferença. Não entendiam o que tinha acontecido com José.
Um mês depois saiu da companhia e abriu seu próprio negócio, low profile.
Comentários