4 fundamentos para implementar processos em TI mais eficazes

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.