4 fundamentos para implementar processos em

TI mais eficazes
Para que qualquer iniciativa de processo seja bem-sucedida, existem,
de fato, quatro pré-requisitos. Revise-os sempre
Bob Lewis, CIO (EUA)
09/07/2021 às 16h04

Foto: Adobe Stock

https://cio.com.br/gestao/4-fundamentos-para-implementar-processos-em-ti-mais-
eficazes/?utm_campaign=cio_news_1207&utm_medium=email&utm_source=RD%20Station

A chave para administrar uma organização eficaz, nos dizem há décadas, é

entregar produtos de trabalho por meio de processos bem projetados e
gerenciados. O processo é saudado como o caminho para o nirvana
organizacional, na forma de resultados previsíveis e repetitíveis.
Mas os CIOs que começam iniciativas de processo, projetando processos e
treinando funcionários para usá-los, são semelhantes aos alunos de matemática
que se matriculam em cálculo diferencial sem primeiro passar em álgebra e
trigonometria. Para ter sucesso em qualquer disciplina, deve-se primeiro dominar
os pré-requisitos.
Para que qualquer iniciativa de processo seja bem-sucedida, existem, de fato,
quatro pré-requisitos:
• Uma cultura de processo;
• Uma compreensão clara da diferença entre processos e práticas;
• A capacidade de projetar, gerenciar e interpretar métricas de processo;
• Confiança entre todos os envolvidos na execução dos processos.
Sem esses pré-requisitos, nenhuma iniciativa de processo, seja gerenciamento de
serviço de TI baseado em ITIL (Information Technology Infrastructure Library), um
ciclo de vida de desenvolvimento de sistemas padronizado ou um manual de
fusões e aquisições de TI pode ter sucesso. Coloque esses quatro fundamentos no
lugar e o sucesso será quase inevitável.

Cultura de processo
“Cultura” é um termo pronunciado com muito mais frequência do que o definido.
Para fins comerciais, pense na cultura como a forma como fazemos as coisas por
aqui. É o conjunto de crenças e suposições compartilhadas que influenciam as
decisões e hábitos de trabalho de todos os funcionários de uma organização.
Se uma organização de TI tem uma cultura de processo, então não importa a
situação que os funcionários enfrentam, eles improvisarão apenas ao lidar com
uma situação para a qual nenhum padrão, processo documentado ou procedimento
foi definido. E quando eles improvisam, eles documentam o que eles descobriram,
seus resultados e melhorias potenciais a serem incluídas caso uma situação
semelhante surja no futuro.
Isso contrasta com uma cultura construída em torno da premissa “Somos pessoas
inteligentes. Vamos descobrir isso”. Não que ter confiança para descobrir como
lidar com algo inesperado seja intrinsecamente ruim. Acontece que, ao descobrir
do zero, onde os funcionários começam, eles expressam a opinião desonesta de
que são mais inteligentes do que o último grupo de funcionários que tiveram que
descobrir a mesma coisa - possivelmente que eles são mais inteligentes do que
todos os que já enfrentaram uma situação semelhante a esta.
Intrínseco às organizações que têm sucesso por meio de processos bem definidos
é a atitude de que todos os envolvidos, o tempo todo, são responsáveis por
aperfeiçoar constantemente "como fazemos as coisas por aqui".

Processos versus práticas

Um processo é um conjunto de tarefas, executadas de acordo com uma sequência
e um fluxo definidos, que produzem resultados reproduzíveis e previsíveis.
Processos são receitas: siga as instruções com precisão e você não pode evitar a
produção de uma deliciosa paella, por exemplo.
Organizações criadas para depender de processos são, como diz o ditado,
"projetadas por gênios para serem comandadas por idiotas", embora "idiotas
comuns" descreva melhor as pessoas que acabam fazendo o trabalho real do que
os "idiotas" e muitos dos designers de processos nem sempre são materiais da
Mensa (antiga sociedade de alto QI).
Como o suprimento de idiotas comuns geralmente excede a disponibilidade de
gênios, o modelo de receita não é uma escolha ruim para muitas situações de
negócios.
Mas nem todas as situações se prestam a receitas. O litígio é um exemplo -
advogados que executam exatamente as mesmas etapas da mesma maneira em
todos os processos têm pouca probabilidade de ganhar casos quando enfrentados
por um oponente mais imaginativo que é um juiz melhor de quais candidatos a
jurados são mais propensos a simpatizar com a causa de seus clientes, e quem é
mais criativo no desenvolvimento de narrativas convincentes que provavelmente
persuadem esses jurados.
É por isso que nos referimos à lei como uma prática, não como um processo.
Em TI, muito do que fazemos se ajusta ao modelo de processo - construir um
ambiente de teste, por exemplo.
Muito, quero dizer, mas longe de tudo. Considere o gerenciamento de projetos.
Segue uma série de etapas, mas isso não significa que executar cada etapa da
mesma forma em todos os projetos seja uma boa ideia.
O gerenciamento de projetos envolve muitas variáveis para qualquer abordagem
baseada em receita de tamanho único: diferentes patrocinadores respondem de
maneira diferente aos riscos e problemas que surgem no curso de um projeto e,
por esse motivo, os riscos e problemas que surgem diferem de projeto para projeto.
O mesmo pode ser dito para a equipe principal do projeto (não há duas equipes
com os mesmos pontos fortes e dinâmicas internas), sem mencionar as PMEs e os
usuários de negócios que compõem a equipe estendida do projeto.
Ah, e o que diferentes projetos devem produzir como seus produtos de trabalho
também não é uniforme: os arranha-céus são fundamentalmente diferentes dos
 porta-aviões, que têm pouco em comum com os decks do PowerPoint ou análises
de custo-benefício.
E assim por diante.
O objetivo de todas as funções de negócios - o termo coletivo para processos e
práticas - é transformar entradas em saídas. Os processos dependem de quão bem
aqueles que fazem o trabalho do processo seguem as etapas da tarefa ao pé da
letra. As práticas dependem do profundo conhecimento, experiência e julgamento
dos praticantes.
Compreender essa divisão básica e fundamental evitará que os CIOs caiam na
armadilha de tentar usar receitas quando elas simplesmente não se encaixam na
situação.
Também é importante notar que processo versus prática não é uma escolha
binária. Eles são mais os pólos de um continuum de possibilidades. Algumas
funções de negócios são mais semelhantes a processos; outros são mais práticos,
mas poucos são puramente um ou outro.
No final das contas, processos e práticas são ferramentas diferentes e igualmente
valiosas para realizar o trabalho de uma organização de TI (e, nesse caso, não de
TI). Use o caminho certo para o trabalho em questão.

Métricas
Se você não consegue medir, diz o velho ditado, você não consegue gerenciar. Ele
ignora a Lei das Métricas Ruins de Lewis, que afirma que você obtém o que mede,
portanto, se você avaliar mal, você administrará incorretamente.
Definir métricas para ajudá-lo a entender se uma função de negócios é saudável ou
precisa de um ajuste exige insight e rigor.
O que se segue é uma sinopse muito breve de um assunto complexo:

Métricas de Otimização de Processo

Os gerentes podem otimizar um processo para não mais do que três dessas seis
dimensões:
• Custo fixo: os investimentos únicos necessários para criar os sistemas e a
infraestrutura de que o processo precisa para funcionar.
• Custo incremental (também conhecido como marginal): o custo adicional de
processamento de uma única transação. O custo incremental não inclui custos
fixos amortizados.
• Tempo de ciclo: o tempo necessário para processar uma única transação - para
transformar entradas em uma única saída.
• Taxa de transferência (também conhecida como capacidade): o número de saídas
que a função de negócios pode fornecer em uma determinada unidade de tempo.
• Qualidade: Cumprimento das especificações; alternativamente, a ausência de
defeitos.
• Excelência: Flexibilidade; a capacidade de se adaptar a situações incomuns e de
adaptar ou personalizar.
A definição de métricas para um processo ou prática começa com a decisão de
quais duas ou três dessas dimensões de otimização são mais importantes. Estes
são os únicos a serem medidos. Você obtém apenas dois ou três, porque otimizar
para aqueles invariavelmente exige compensações com as dimensões restantes.
Esqueça os acordos de nível de serviço (SLAs)
Os SLAs são uma forma popular, mas equivocada, de medir as funções de
negócios.
Os níveis de serviço são métricas de duas partes. Eles definem (1) o limite mínimo
de desempenho aceitável e (2) a porcentagem de ocorrências que devem atender
a esse limite.
Por exemplo, para incidentes de nível um, o gerente da central de serviços pode
decidir que o tempo de ciclo é a dimensão de otimização mais importante para a
primeira parte da métrica, estabelecendo um tempo para resposta inicial de 5
minutos e tempo para resolução de uma hora como o limites mínimos de
desempenho aceitável. Para a parte dois, 95% ou mais incidentes de nível um
devem estar em conformidade com os limites estabelecidos na parte um.
Os SLAs são um mal necessário nos contratos de terceirização porque tanto a
empresa contratante quanto o terceirizador precisam saber se o desempenho está
de acordo com os requisitos contratuais.
Mas para o gerenciamento de funções de negócios, as métricas da velha escola de
média e desvio padrão são muito mais úteis.
Confiança
Em “Keep the Joint Running: A Manifesto for 21st Century Information Technology”,
eu apresentei o “ciclo de desconfiança do processo”. Mostra, de forma semi-
satírica, as consequências práticas da desconfiança: ao executar um processo, a
cada passo do caminho, a desconfiança faz com que a pessoa ou grupo que
recebe o trabalho em andamento presuma que ele é defeituoso em algum aspecto.
Isso leva a reclamações, retrabalho, atrasos, desperdício e desagrado geral.
E, como bônus, desconfiança adicional.
Com confiança, mesmo os processos mal projetados podem fluir sem problemas.
Sem ele, nenhum processo tem chance de entregar os resultados pretendidos.

Em conclusão
Esses quatro fundamentos - uma cultura de processo, reconhecimento das
diferenças entre processos e práticas, a capacidade de definir e rastrear métricas
adequadas e, acima de tudo, a confiança entre todos os envolvidos - fazem a
diferença entre uma organização de TI que faz o trabalho e uma que parece nunca
entregar o que está acontecendo.