A verdade sobre o sucesso de processos de TI
Construindo TI 101 eficaz: Deseja projetar e implementar processos de TI eficazes? Você deve estabelecer esses quatro fundamentos antes mesmo de começar.
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 bom processo é bem definido e aclamado como o caminho para o nirvana organizacional, na forma de resultados previsíveis e reproduzí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, é preciso primeiro dominar os pré-requisitos.
Para que qualquer iniciativa de processo seja bem-sucedida, existem, de fato, quatro pré-requisitos: (1) uma cultura de processo; (2) uma compreensão clara da diferença entre processos e práticas; (3) a capacidade de projetar, gerenciar e interpretar métricas de processo; e (4) confiança entre todos os envolvidos na execução dos processos.
Sem esses pré-requisitos, nenhuma iniciativa de processo, seja gerenciamento de serviços de TI baseado em ITIL, um ciclo de vida de desenvolvimento de sistemas padronizados 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 é 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 os hábitos de trabalho de todos os funcionários de uma organização.
Se uma organização de TI tem uma cultura de processo, independentemente da situação que os funcionários enfrentam, eles improvisarão ao lidar com uma situação para a qual não há padrão, processo ou procedimento documentado definidos. E quando improvisam, eles documentam o que criaram, seus resultados e melhorias potenciais a serem incluídas caso uma situação semelhante surja novamente no futuro.
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 executar e 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 poderá deixar de produzir um prato delicioso, por exemplo.
Organizações criadas para depender de processos são, como diz o ditado, “projetadas por gênios para serem comandadas por executores”, embora “executores”, embora menos enérgicas, descreve melhor as pessoas que acabam fazendo o trabalho real seguindo estritamente as regras, e muitos dos designers de processos nem sempre são materiais da *Mensa, termo explicado ao fim do texto como o estímulo da inteligência para o bem comum.
Como a oferta de executores comuns geralmente excede a disponibilidade de gênios, o modelo de receita não se encaixa mal em 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 julga 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 encaixa no 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 (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 os diferentes projetos devem produzir como 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 slides 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 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 de profundo conhecimento, experiência e julgamento dos especialistas em negócios e processos.
Entender essa divisão básica e fundamental evitará que 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 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, de outra organização). Use o caminho certo para o trabalho em foco.
Métricas
Se você não consegue medir, diz o velho ditado, você não obteve sucesso. Talvez esteja ignorando a Lei das Métricas Ruins de Lewis, que afirma que você obtém o que mede, portanto, se você avaliar incorretamente, 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 esses invariavelmente exige compensações com as dimensões restantes.
Elimine 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.
Confiar
Em Keep the Joint Running: Um Manifesto para a Tecnologia da Informação do Século 21, foi apresentado 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, retrabalhos, atrasos, desperdícios e desagrados. E, como bônus, desconfiança adicional.
Com confiança, mesmo os processos mal projetados podem fluir sem problemas. Sem ela, nenhum processo tem chance de entregar 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 outro que parece nunca entregar o que está realmente acontecendo.
*Mensa: A constituição da Mensa enumera três finalidades: “para identificar e fomentar a inteligência humana para o benefício da humanidade, para incentivar pesquisas sobre a natureza, características e usos da inteligência, e para fornecer um ambiente intelectual e social estimulante para os seus membros”.
