Um guia do CIO para orientar a mudança nos negócios

Nas décadas de 1970 e 1980, a TI era o impulsionador reconhecido da mudança nos negócios, embora sob o apelido de “processamento de dados”, seguido por “sistemas de informações gerenciais”, seguido por “sistemas de informação”.

Tendo automatizado as luzes do dia da contabilidade geral, os programadores de TI e seus amigáveis suplicantes – gerentes de negócios sob pressão constante para cortar custos – atacaram os processos de negócios com alegria para automatizar as luzes do dia deles.

A diversão durou até Joseph Juran inventar o chamado “cliente interno” e o papel de liderança da TI de ajudar a empresa e todos nela a serem mais eficazes evaporou.

Em vez disso, a TI, em seu papel de “fornecedor”, enviou seus analistas de negócios emissários para descobrir o que esses clientes internos queriam dos produtos que estavam comprando da TI.

Foi quando todos caímos de cabeça na perdição.

Veja só: Analistas de negócios em organizações de TI da velha escola, da era industrial e focados no cliente interno perguntaram aos gerentes de negócios quais eram seus requisitos – ou seja, o que eles precisavam de um aplicativo para fazer.

Os gerentes de negócios da era industrial da velha escola se esforçaram para fornecer respostas úteis, embora para seus ouvidos a pergunta soasse muito como “explique os papéis da matéria escura e da energia escura para impedir que o universo se desfaça”.

Você pode ver o problema: Os gerentes de negócios não deveriam ser especialistas no que o software pode fazer. A pergunta que eles queriam responder, se ao menos o analista de negócios tivesse feito, era: “Como você quer que sua parte do negócio funcione de maneira diferente e melhor?” seguido de “Você gostaria de ajuda para descobrir isso?”

A falha da TI em fazer as perguntas certas levou à sua triste transição de líder de mudanças nos negócios para a perspectiva desanimadora de fornecedor para cliente interno que continua a distorcer nosso setor.

Também levou ao surgimento de metodologias de otimização de processos de negócios que prometiam aos gerentes de negócios um caminho para fazer sua parte do negócio funcionar de maneira diferente e melhor — sem ter que envolver a TI.

Claro, os gerentes de negócios, incentivados por “cinturões” de otimização de processos de negócios e apoiados por um monte de planilhas que os usuários de negócios criam quando a TI de que precisam não é a TI que eles têm, podem melhorar os processos de negócios que seguem.

Mas não tão bem quanto eles podem melhorá-los quando a TI é integrada à otimização de processos de negócios.

Como? Comece com uma visão clara de para que servem as principais metodologias de otimização de processos de negócios. Então, e só então, você pode melhorá-los.

Entendendo as metodologias de otimização de processos

Quatro metodologias passaram a dominar os esforços de otimização de processos de negócios: Lean, Six Sigma, Teoria das Restrições e Reengenharia de Processos de Negócios. Para ter sucesso no mundo digital de hoje, cada um deve ser uma habilidade de segunda natureza para os analistas de negócios de TI.

Lamentavelmente, porém, essas metodologias tornaram-se escolas de pensamento concorrentes (escolha a minha!) que evoluíram para religiões (a minha é melhor que a sua!). É tão sensato quanto discutir sobre o que funciona melhor, uma chave de fenda, um alicate, um ferro de solda ou um torno.

E você se pergunta por que nós, consultores, respondemos a tantas perguntas com “depende”.

Quando se trata de apoiar mudanças nos negócios, a “resposta depende” equivale a escolher a metodologia mais adequada, não a metodologia que o analista de negócios tem faixa preta.

Mas, por outro lado, a ideia de ter que ganhar faixas de vários tons ou seus níveis equivalentes de especialização em várias dessas metodologias, apenas para que você possa escolher a que melhor se adapta a uma situação, pode parecer intimidante demais para se preocupar com isso. Escolher um para usar em todas as situações e viver com suas limitações é compreensivelmente tentador.

Se aumentar a sua coleção de faixas não está no topo da sua lista de prioridades, aqui está o que você precisa saber para limitar suas escolhas, deixando as faixas pretas para os especialistas que você traz para o trabalho assim que decide qual metodologia se adapta melhor à sua situação.

Antes de poder escolher, tenha em mente as seis dimensões da otimização do processo: custo fixo, custo incremental, tempo de ciclo, rendimento, qualidade e excelência (para uma atualização, dê uma olhada rápida em “A dura verdade sobre Sucesso do processo de TI”.) Você precisa mantê-los no centro do palco, porque: Você só pode otimizar em torno de não mais do que três deles; os que você escolher têm compensações; e cada metodologia é projetada para otimizar diferentes dimensões do processo.

Um por vez:

Lean

Lean é Henry Ford por meio da Toyota. O foco principal da Lean é reduzir o desperdício, o que, quando você reduz tudo, significa reduzir o custo incremental. A metodologia Lean também pode oferecer outros benefícios, como melhorar a qualidade e reduzir o tempo de ciclo, mas apenas na medida em que não afete a redução do desperdício.

Os proponentes do Lean serão rápidos em apontar que ela também enfatiza a melhoria contínua. E com razão. Apenas tenha em mente que Lean equivale a menos desperdício.

Se o desperdício é o seu problema, Lean é para você.

Six Sigma

Six Sigma é a herdeira da gestão da qualidade total. Seu foco é reduzir a variação, o que é realizado identificando e abordando as causas-raiz da variabilidade – as razões pelas quais as saídas do processo não são idênticas e não atendem às especificações.

O foco da Six Sigma, então, é melhorar a qualidade. Na medida em que as saídas defeituosas são descartadas ou canalizadas de volta ao processo para correção, a Six Sigma também pode, como benefício adicional, reduzir o custo incremental.

Mas em sua essência, a Six Sigma é sua escolha se a qualidade for o que mais importa para você. Caso contrário, você pode achá-la decepcionante.

Teoria das Restrições

A Teoria das Restrições é a melhor metodologia de otimização de processos que ninguém nunca ouviu falar. Isso é lamentável.

Inventada pelo ex-físico Eliyahu Goldratt, a ToC [Theory of Constraints] assume que a taxa de transferência insuficiente é o seu problema e que seu processo tem gargalos (restrições) que o limitam. Acelere ou elimine os gargalos do processo e você aumentará o rendimento – ou seja, a capacidade – e reduzirá o tempo de ciclo.

Se um sintoma das deficiências de um processo de negócios é que ele não consegue acompanhar a demanda, procure ajuda na Teoria das Restrições.

E embora não faça parte da doutrina oficial da ToC, você pode aplicar o loop fundamental do ToC – encontrar gargalo, corrigir gargalo, enxaguar e repetir – a qualquer objetivo de otimização de processo que você elencar como o mais importante. Não precisa ser um gargalo de capacidade.

Reengenharia do Processo de Negócios

Reengineering the Corporation, de Michael Hammer e James Champy, foi o livro que focou os líderes empresariais na importância de processos bem projetados. O ponto focal da Reengenharia de Processos de Negócios é que o lugar certo para começar é uma folha de papel em branco.

Assim, onde Lean, Six Sigma e Teoria das Restrições procuram as poucas etapas ruins do processo que causam mais danos e tentam corrigi-las para reduzir desperdícios, defeitos ou gargalos, o principal impacto da BPR [Business Process Reengineering] parece ser maximizar as horas de faturamento do consultor.

O que não é totalmente justo – há situações em que a BPR é sua única opção, por exemplo, quando você está terceirizando um processo de negócios anteriormente terceirizado.

Mas das quatro metodologias de otimização de processos dominantes, a BPR é a mais arriscada.

Pegue o quinto

Embora Lean, Six Sigma, ToC e BPR sejam as principais metodologias de otimização de processos de negócios, os grupos de TI que desejam liderar a melhoria de processos de negócios têm outra alternativa disponível: Oferecer os fluxos de processo incorporados em aplicativos comerciais como os locais lógicos para começar.

Software é uma opinião. Os aplicativos de negócios comerciais são opiniões sobre como um processo de negócios deve fluir. E embora essas opiniões nem sempre sejam adequadas, geralmente são um ponto de partida útil.

E embora começar com os processos integrados de um aplicativo facilite tanto a integração inicial quanto a manutenção contínua para a TI, isso não é apenas uma repetição do velho argumento de ‘sorvete de baunilha versus flocos de chocolates’ que tantas vezes atrapalha as implementações de aplicativos.

O problema de discutir sobre variedades de sorvete era… é… que são discussões sobre se a TI ou “o negócio” consegue o que quer.

Mas como não existe um projeto de TI, discutir sobre qual ‘sabor’ de software usar não deveria ser permitido.

Começar com built-in process? Sim, isso é, como um benefício marginal feliz, mais perto de aceitar softwares mais básicos para a TI manter. Mas ‘baunilhar’ não é o ponto. Processos eficazes são o ponto.

Seguir a opinião de design de processo do fornecedor do aplicativo também tem um benefício adicional para os negócios: ninguém precisa projetá-lo.

E um segundo: é um lugar viável para começar a aplicar Lean, Six Sigma ou ToC se não for bom o suficiente.