Publicado em terça, 20 de setembro de 2022
CIO - O que os CIOs erram sobre otimização
Como CIO, muito do que você faz é projetar coisas, e isso é quando você não está supervisionando outras pessoas que projetam coisas. Ou quando você não está certificando-se de que as coisas que todos estão projetando se encaixam da maneira que deveriam.
Existem algumas regras universais que governam o bom design, não importa o que está sendo projetado. A mais famosa é provavelmente a máxima do grande arquiteto Louis Sullivan de que a forma segue a função. Menos conhecido, mas igualmente importante (pelo menos para o nosso contexto) é uma [máxima] introduzida por W. Edwards Deming: Para otimizar o todo devemos subotimizar as partes.
Isso importa independentemente do que está sendo projetado, seja um gadget, software, uma organização ou um processo. E é a chave para entender por que tantos CIOs erram na otimização.
De fila em fila: o gargalo do processo oculto
Se os CIOs pudessem ganhar a vida com um único truque, provavelmente seria a otimização de processos. É vital que a TI desempenhe bem sua própria função, e muito do que a TI faz para ganhar a vida é ajudar os gerentes de negócios a otimizar seus processos também.
Os otimizadores de processos dentro e fora da TI têm uma grande variedade de frameworks e metodologias à sua disposição. Lean está entre os mais populares, então vamos usar isso para ilustrar o ponto.
Talvez a contribuição mais importante, mas menos reconhecida, que o pensamento Lean tenha feito para o mundo da otimização de processos é que os processos não são coleções de tarefas que fluem de uma caixa para outra.
Em vez disso, são tarefas que fluem de fila para fila para fila. A diferença pode parecer sutil, mas é uma das razões pelas quais a otimização de um todo oferece resultados diferentes da otimização das partes de um todo. Isso pode soar como hoo-ha acadêmico ou koan de TI, mas entender essa diferença é a chave para dominar a otimização de processos.
Me ouça.
Imagine que você está gerenciando um projeto que precisa de um novo servidor para prosseguir, supondo que, no momento, a TI não tenha se tornado a nuvem completa e ainda possua servidores e um data center. Você segue o procedimento e envia uma solicitação para a fila de solicitações de TI.
É um fluxo direto. As equipes responsáveis por cada etapa há muito otimizaram os procedimentos para lidar com suas responsabilidades. O esforço total e o tempo de ciclo do processo são os mesmos – para este exemplo hipotético, calcule cerca de oito horas ou um dia no cronograma do projeto.
Cada etapa do processo é gerenciada como uma fila FIFO (first in, first out). As equipes trabalham em solicitações somente quando a solicitação fluiu pela fila e saiu para processamento. O esforço total é o mesmo estimado na visualização caixa a caixa. Mas o tempo de ciclo inclui tanto o tempo de trabalho quanto o tempo na fila — para esse processo modelado, cinco dias mais ou menos.
A análise real é mais complicada do que isso. Normalmente, uma etapa acaba sendo um gargalo; o trabalho se acumula em sua fila enquanto outras filas ficam secas, contrabalançadas por todas as filas que recebem solicitações de mais de uma origem. Mas isso não muda o princípio, apenas a complexidade da simulação.
Isso é real, não apenas teoria. Não muitos anos atrás, um cliente, cujos tamanhos de fila eram um pouco maiores do que o descrito acima, experimentou atrasos de vários meses no projeto enquanto suas equipes esperavam pela instalação de servidores aprovados dos quais dependiam, mesmo que um servidor típico não exigisse mais esforço para adquirir, configurar e instalar do que o descrito acima.
A causa raiz? Os gerentes responsáveis por compras, administração de rede, instalação de software, garantia de qualidade e implantação organizaram o trabalho de seus departamentos para maximizar a utilização e o rendimento da equipe.
Eles — as partes — haviam se otimizado às custas do todo de cada projeto.
Eliminando externalidades
A solução, que os devotos de DevOps reconhecerão e adotarão imediatamente, foi incluir analistas de infraestrutura de TI na equipe principal do projeto e, ainda mais importante, incluir tarefas de infraestrutura, como configurar servidores no plano de trabalho de cada projeto, atribuindo datas de início e datas de vencimento com base em quando seus produtos de trabalho seriam necessários.
Com essa mudança, as compilações de servidores passaram a fazer parte do cronograma do projeto em vez de serem externalidades sobre as quais o gerente de projeto não tinha controle.
Em troca, o CIO teve que aceitar que, se os projetos entregassem seus resultados no prazo e dentro de seus orçamentos, o restante da organização de TI teria que permitir alguma folga em seu gerenciamento de trabalho. As metas de utilização da equipe não devem se aproximar de 100%. (Dica profissional: invista algum tempo pesquisando a metodologia de gerenciamento de projetos Critical Chain de Eliyahu Goldratt para uma compreensão mais profunda desse ponto.)
O colapso do MBO
A questão da otimização/subotimização se aplica a muito mais do que o design do processo. Tomemos, por exemplo, a remuneração da administração.
Antigamente, Gestão por Objetivos (MBO) era uma teoria popular de como tirar o máximo proveito da organização, obtendo o máximo de cada gerente da organização. Sua falha fatal também foi uma falha em reconhecer as consequências inevitáveis, mas não intencionais, de otimizar as partes em detrimento do todo.
A maneira como funcionava – ou melhor, não funcionou – era que, como o nome indica, os executivos da empresa atribuíam a cada gerente um ou mais objetivos. Os gerentes, dada a maior clareza sobre o que deveriam realizar, começaram a realizá-lo com fervor monomaníaco, desimpedidos pelas distrações do que qualquer outro gerente da organização precisava para atingir seus próprios objetivos.
As organizações modernas que sofrem com o que seus habitantes chamam de “pensamento de silo” com sua incapacidade de colaborar são vestígios da era MBO.
Ajudando desamparadamente o help desk
Como alguém disse uma vez – ou como quase todo gerente disse sempre que o assunto surge – não há organogramas perfeitos. O princípio de otimização/subotimização de Deming é um dos principais contribuintes para as imperfeições do organograma.
Pegue o help desk clássico e sua posição no design organizacional de TI. Possui metas de nível de serviço para o atraso entre o primeiro contato do usuário final e a resposta inicial do suporte técnico; também uma meta para o tempo necessário para resolver o problema do usuário final. Em algum lugar, há também o objetivo de minimizar o custo por incidente.
Imagine que lidar com cada incidente relatado inclui o tempo gasto para registrá-lo e o tempo gasto tentando resolvê-lo ou o tempo gasto para se livrar dele entregando-o a uma equipe de TI diferente.
A maneira mais fácil de o help desk atingir seu nível de serviço de resposta inicial é fazer o mínimo possível durante a resposta inicial, entregando cada incidente o mais rápido possível. Isso mantém os analistas de help desk livres para atender a próxima chamada e de ficarem presos tentando resolver problemas para os quais não estão preparados. Melhor ainda, direcionando os problemas para departamentos com mais experiência, os incidentes serão resolvidos mais rapidamente do que se os analistas de suporte técnico tentassem resolvê-los por conta própria.
Infelizmente, essa abordagem também garante que os analistas de suporte técnico nunca aprendam a lidar com problemas semelhantes no futuro. E, embora também mantenha os custos do suporte técnico baixos, faz isso às custas de distrair os talentos mais caros de seu conjunto atual de prioridades, que, da perspectiva do valor geral, provavelmente são mais importantes.
A otimização do suporte técnico acaba sendo um exercício de transferência irrestrita de custos e responsabilidades. O custo total do gerenciamento de incidentes aumenta proporcionalmente à diminuição dos custos do próprio help desk.
Para otimizar o todo, é preciso subotimizar as partes. Essa orientação pode não parecer concreta e pragmática, mas não deixe que seus tons esotéricos o desencorajem. Se você deseja os melhores resultados, certifique-se de que todos os envolvidos na entrega desses resultados saibam o que eles deveriam ser.
E também que ninguém será penalizado por colaborar para que eles aconteçam.
Fonte: It Fórum
Voltar para notícias