Aqueles que idealizaram os mais conhecidos métodos de processos em TI (COBIT, ITIL, etc) com certeza pensaram em agilidade, padronização, melhoria do serviço a ser entregue, entre outros benefícios. Agora, porque nós, profissionais de TI temos tanta dificuldade em aceitar e entender essa parte de processos?
Será que profissionais como eu, muito envolvidos com o a parte técnica, estão vendo nesses procedimentos, uma burocratização em algo que nunca deveria ser burocratizado?
Exatamente! Qualquer que seja o processo, se não for implementado da forma correta, torna a TI uma verdadeira repartição pública (com todo respeito a quem trabalha em repartições).
A uns 6 anos atrás trabalhei para uma grande multinacional americana onde desde a menor até a maior ação era feita com procedimentos registrados e documentados.
Sinceramente, não tenho nada contra essa vertente da TI, mas, era um sacrifício conseguir autorização para acesso ao prédio onde estava o datacenter e logo em seguida, outra autorização era necessária para acessar o Data Center.
Ora, o analista técnico que atua diretamente com a infraestrutura já não deveria estar automaticamente autorizado?
O resultado dessa burocracia foi a demora (sem necessidade) na reparação de um servidor de missão crítica e o escalonamento da parte do cliente para a diretoria da empresa, deixando a imagem da fornecedora com o cliente meio arranhada, não só pela demora na resolução, mas, também pelo prejuízo que a parada daquele servidor causou ao cliente.
No fim das contas, uma multa contratual que fez com que esta empresa faturasse menos que em outros meses. Tudo por conta de um processo mal pensado.
O processo em si não causa problema algum. As metodologias (volto a dizer) vieram para organizar a TI, mas, será que estão sendo bem entendidas por quem as implementa?
Já escrevi diversos artigos aqui sobre a importância de um projeto bem implementado e as conseqüências de um mal planejamento e com processos não é nada diferente.
O mau planejamento na implementação da sua biblioteca de procedimentos pode causar constrangimentos com seus cliente e até mesmo internamente.
Aqueles que coordenam os processos vivem em pé de guerra com os implementadores técnicos. De um lado se reclama de burocracia e de outro se reclama por não quererem entrar na ordem estabelecida.
Em alguns casos, existem até situações paradoxais…
Atuando em uma grande multinacional, me deparei com duas situações distintas:
1. Para implementar uma infra de servidores Windows tive que montar um documento extenso explicando o porque de fazer aquilo, quais impactos, quais áreas seriam afetadas, etc. Até aí tudo bem, se este é o procedimento estabelecido, ok! Vamos
seguir.
2. Em uma emergência, tive que subir um servidor as pressas para um cliente. Os procedimentos rezam que, independente da situação, a documentação prévia teria que ser apresentada. Mas, nesse caso, tive autorização e ao mesmo tempo ordem
expressa para fazer sem uma RfC (request for change).
Se o procedimento é documentado, porque vale para uma situação e para outra não?
Na minha visão, os processos de hoje precisam ser mais otimizados. O email é um excelente documento para ser guardado. Formulários on-line tomam tempo e (a meu ver) causam confusão.
Basta envolver as áreas afetadas e os responsáveis pelo contato com o cliente. Não vejo necessidade de algo mais que isso.
Com a atividade definida, o gerente de contas posiciona o cliente acerca da necessidade da mudança e aí teremos um “sim” ou um “ não” para o procedimento.
Os acessos, esses sim, devem ser mais controlados, mas, tendo em mente que, o profissional técnico deverá ter acesso irrestrito aos datacenters. Durante uma emergência, eles deverão ter fácil acesso…lembrem-se da história que contei sobre a dificuldade que tive para acessar um datacenter e os desdobramentos disso.
Está na hora dos profissionais envolvidos com processos entenderem o que afeta um determinado processo e aplica-lo de forma a termos ordem e organização sem burocratizar e impactar no SLA com o cliente.
Abraços
Uilson
Leave a Comment