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
Formado em Tecnologia em Processamento de Dados pela UNIBAN. Analista de Projetos de TI, atua no design, planejamento e implementação de projetos de tecnologias Microsoft, tais como ISA Server, Forefront TMG, servidores Windows, Windows Clustering e Hyper-V. Também trabalhou como IT Specialist na IBM e como Consultor de TI em empresas como Alcoa, Credicard, Bradesco Seguros, Unilever, Caterpillar e Banco Merril Lynch. Profissional certificado como MCTS em ISA Server, participa do grupo MTAC (Microsoft Technical Audience Contributor), publica artigos técnicos em seu blog no endereço http://uilson76.wordpress.com e também no portal TechNet Wiki (http://social.technet.microsoft.com/wiki) Linkedin: http://www.linkedin.com/in/uilsonsouza Twitter - http://twitter.com/usouzajr
You must be logged in to post a comment.
10:31:31 pm
Bom artigo.
O negócio é que as pessoas veem essas siglas todas de certificações por aí e as encaram como verdades absolutas, o mundo real é bem diferente e cada situação é uma situação.
Ontem mesmo estava conversando com um amigo sobre isso, ele trabalha numa multinacional e todos os processos são extremamente burocráticos, tão burocráticos que funcionários que não querem trabalhar usam isto em prol da preguiça.
Lá uma simples pergunta sobre a arquitetura de um sistema pode levar duas semanas para ser respondida, envolve um sem número de reuniões, e durante este período a equipe do projeto fica paralisada, praticamente férias. O cronograma do projeto é então mais uma vez adequado e o cliente dá o aceite (se fosse um pequeno prestador de serviço com certeza não aconteceria).
Dá até calafrio saber que muitas empresas são assim.
11:26:41 am
Excelente resposta Álvaro. Exatamente o que procurei colocar no texto. Realmente é assim, mas, vamos esperar para ver se algo muda!
Abraços e obrigado pelo comentário. Continue participando!
9:23:27 am
Caro Uilson Souza,
Sou gerente de projetos e percebo no seu post assim como percebo na minha empresa que os processos não foram bem implementados. Sendo assim, o problema deixa de ser do processo e passa a ser de que os desenhou.
É de praxe que processos sejam idealizados por pessoas que não fazem parte da rotina atual, isso é um erro! Não é possível que uma pessoal de fora, sem a visão interna da rotina crie processos, costumo dizer que cada empresa é uma empresa, cada processo é um processo e cada cultura é uma cultura, não se leva processos engessados de um lugar pra outro.
O outro lado da moeda é que processos são necessários para que as rotinas se tornem mais fáceis, talvez não “mais fáceis” no dia-a-dia, mas em matéria de rastreabilidade, controle, análise de recursos e resultados.
Abraços,
5:27:11 pm
Gabriel e Alexandre,
Gostei muito dos comentários de vcs e eles têm fundamento. Eu particularmente acho que hoje muitas consultorias e empresas patinam em processos e realmente emperram muita coisa. Coisas do processo? Coisas da implementação do mesmo? Pessoas erradas?? Tudo isso pode ser a razão.
Se vemos esses mesmos problemas e reclamações em diversos lugares, aí eu começo a pensar que, a questão não se resume somente em quem implementou, mas, como foi implementado.
Não sou contra a existência dos mesmos, mas, não vejo necessidade de tanta burocracia uso de ferramentas complexas e processos longos para ações, em muitos, casos pequenas.
De qualquer forma, as idéias que vcs apresentaram são muito boas e estou relendo e levando muita coisa em consideração.
Abraços e continuem participando!
9:38:09 am
Olá,
Não sendo tendencioso justamente por ser da área que “cria” todo essa chamada burocracia, mas vamos lá…
O segredo de tudo isso é obter uma linha entre pragmatismo e burocracia e é exatamente ai onde a alta gestão peca na hora de implementar processos padronizados em algum framework, tudo isso gera a mesma discussão que religião, política e futebol, são pontos de vista, mas uma coisa é fato, se implantarmos esses processos obedecendo certos critérios, os resultados virão e com certeza não virão apenas do seu diretor de ti o que acontece normalmente, virão do negocio, o que na minha visão é o que realmente importa. Apenas um comentário no que foi dito no
Artigo sobre um determinado atraso e isso gerou quebra de SLO e etc, para determinados tipos de mudanças, visando o ITIL ou até mesmo o PMI, precisamos ter um sistema de
Mudanças concreto e consequentemente mudanças consideradas
“Padrão” significa que a burocracia para tais mudanças ja se encontram pré aprovadas,
Isso ajudaria em muitos casos, trabalho em uma multinacional e todos os departamentos considerados os mais estruturados dão vistos pelos profissionais técnicos como os mais burocráticos, e sinceramente são os que mais geram receita. Abraços.
11:43:02 am
Realmente, quando eu trabalhei numa empresa grande, sempre imaginei o descrédito da empresa perante cada atraso de serviço por conta disso. Um controle realmente é de suma importância mas acho que estão exagerando com isso.