(*) Patrick Gray
Os paralelos entre o vazamento de petróleo ocasionado pela British Petroleum (BP) no Golfo do México e desastres de TI podem nos ensinar lições impressionantes.
Tendo trabalhado com um cliente em serviços de campo de petróleo, mais precisamente na indústria que fornece as brocas, ferramentas e know-how para empresas como a BP, eu ainda fico espantado com a forma como o processo é tecnicamente complexo. A maioria de nós não imagina a complexidade por trás da ação de abastecer nossos carros nos postos de gasolina, assim como a maioria dos usuários não enxerga a complexidade por trás do trabalho de disponibilizar desde e-mail até o sistema de ERP para uso. Em muitos casos as pessoas “comuns” suspeitam que a indústria do petróleo possui interesse nefastos por trás, assim como muitos suspeitam que a TI de suas empresas existe apenas para espioná-los, restringir o acesso e, geralmente, tornar suas vidas mais difíceis.
O paralelo mais dramático é que o derrame de petróleo no Golfo do México é em sua essência um problema técnico, exigindo uma solução técnica. Enquanto segurança, processos e falhas gerenciais levaram ao desastre, nenhum impacto político bombástico, gestão das expectativas, relações públicas ou revoltas populares podem mudar o fato de que um buraco a um quilômetro de profundidade no oceano até muito recentemente estava jorrando óleo de forma descontrolada, e apenas os técnicos da BP e seus fornecedores eram capazes de mudar isso. Assim, que lições a TI pode aprender com este incidente?
Certificação internacional para gestores de service desk
ACEITAR A CULPA AGORA E JOGAR O “JOGO DO CULPADO” DEPOIS
Imediatamente após o desastre, o CEO da BP, Tony Hayward aceitou a total responsabilidade pelo acidente e prometeu pagar pelos danos. Imediatamente depois, a classe política nos Estados Unidos começou a apontar o dedo e fazer acusações, assim, as duas partes com as maiores capacidades para resolver o problema, o governo dos EUA e a BP, foram colocados em um relacionamento de adversários, quando precisavam na verdade uns dos outros. Quando um desastre de TI acontece, reconheça, assuma a responsabilidade e deixe para depois a preocupação de quem culpar.
ÀS VEZES, UM “PLANO B” NÃO É O SUFICIENTE
A solução para o derramamento de petróleo era algo que levaria algum tempo, em um processo que foi demoraria meses para dar frutos. A BP ofereceu planos diferentes, mas quando a primeira alternativa falhou, eles parecem ter sido pegos despreparados. Em um desastre desta magnitude, ter "plano B" não é suficiente. Semanas e milhares de barris de óleo derramados poderiam ter sido evitados se a BP simultaneamente tivesse executado planos de backup adicionais, ao invés de apostar em um que falhou e só então ter planejado e executado outro plano alternativo.
Olhando para TI, ninguém quer ouvir falar de bits e bytes, quando sua empresa não pode inserir pedidos de compra no sistema. Oferecer uma explicação de leigo para um problema técnico e ter um plano de ações para remediar o problema, proporciona muito mais confiança do que relatórios minuciosos e fragmentados de status.
Dê um salto em sua carreira com um curso internacional
AS APARÊNCIAS IMPORTAM
Eu raramente defendo a presença física para manter as aparências. Prefiro uma equipe de trabalho que gere resultados trabalhando de casa ao invés aqueles que realizam pouco, mas chegam ao escritório todos os dias às 7h da manhã. No entanto, em caso de desastres, essa regra muda. O CEO da BP e o presidente dos EUA Barak Obama sofreram merecidos abalos às imagens, quando ambos decidiram sair de férias quando deveriam estar se mostrando e dando respostas. Embora a presença destes dois homens, obviamente não iriam contribuir para a solução técnica do problema, como um líder, se espera que você esteja em cena durante todo o desastre e não fugindo para seus iates ou a campos de golfe.
DURANTE UM DESASTRE TÉCNICO, O TRABALHO DO LÍDER É TORNAR A VIDA DO TÉCNICO MAIS FÁCIL
Os "fazedores" de qualquer organização raramente são quem mandam, mas em resposta a um problema técnico, como o derramamento de petróleo da BP, os líderes precisam sair do caminho e facilitar a solução ao invés de se tornarem parte do problema. O presidente Obama se mostrou inapto de fazer isso, quando sugeriu um estudo mais aprofundado e comissões de "experts", criticando publicamente, as únicas pessoas em condições de realmente tamparem o poço de petróleo. Muito tem sido feito da incapacidade das comunidades locais em obter licenças apropriadas ou permissão para construir paredões ou tomar medidas preventivas, e de regras federais impedindo os navios estrangeiros de auxiliar a limpeza - todas as áreas onde o governo poderia ter prestado assistência ou facilitado a vida para aqueles no que estavam colocando a mão na massa.
Pressionando os técnicos, exigindo atualizações de status constantes e publicamente questionando a capacidade de seus técnicos ao invés de sair do caminho e remover obstáculos administrativos foram maneiras de prolongar o desastre.
Certamente haverá anos de resíduos desta catástrofe e é necessário um estudo por parte do líder empresarial, mesmo que esteja dentro ou fora da parte técnica de sua organização. Para o líder de TI, esse derramamento fornece o exemplo perfeito de como uma pessoa de fora vê a tentativa de resolução de um problema técnico. Assim como você provavelmente não entende as nuances de perfuração direcional ou prevenção de explosões, seus usuários não se preocupam com firewalls ou falhas nos SANs. O modo como o líder de um corpo técnico e o CEO informam o resto da organização sobre o seu progresso, determina se você tem o equivalente em TI ao derramamento da BP ou uma remediação bem gerida e eficaz.
(*)Patrick Gray é o fundador e presidente do Prevoyance Group e autor do Breakthrough IT: Supercharging Organizational Value through Technology. Patrick pode ser contatado em patrick.gray@prevoyancegroup.com
4 vagas restantes para o HDM no Rio de Janeiro
Aproveite!
Aproveite!
Participe do fórum do maior instituto de Service Desk e Field Support do mundo!
Saiba das últimas novidades do mercado de Service Desk e Field Support
Nenhum comentário:
Postar um comentário