Uma nova abordagem para a estrutura do trabalho

Durante anos, peritos em gestão presumiram que existiam cedências inevitáveis entre eficiência e flexibilidade – e que a estrutura organizacional certa para obter uma ou outra seria diferente. Mas é possível estruturar o trabalho de forma a oferecer simultaneamente agilidade e eficiência – se se souber como.

Por Nelson P. Repenning, Don Kieffer e James Repenning, publicado originalmente na MIT Sloan Management Review

Quase todas as publicações sobre negócios falam hoje sobre a velocidade crescente da mudança nas tecnologias e nos mercados e sobre a consequente necessidade de organizações mais adaptáveis. Tendo em conta o imperativo da adaptabilidade, não surpreende que poucas palavras tenham recebido mais atenção nos últimos debates sobre gestão e liderança como a palavra “ágil”. As organizações – de grandes empresas como a General Electric Co. a pequenas startups – estão a tentar ser flexíveis e rápidas na forma como reagem a novas tecnologias e condições de mercado.

A palavra “ágil” parece ter sido aplicada pela primeira vez ao software por 17 programadores em 2001. Depois de experimentar abordagens mais interactivas e simples para o desenvolvimento de novas aplicações durante várias décadas, o grupo compilou a sua experiência num manifesto ágil. «Estamos a descobrir formas mais adequadas de desenvolver software ao fazê- -lo e a ajudar outros a fazê-lo», escreveram. No desenvolvimento de software, o ágil tinha agora várias manifestações, incluindo “formação ordenada”, programação extrema e desenvolvimento de características. Os resultados foram significativos. Diversos estudos mostram que os métodos ágeis de desenvolvimento de software podem gerar uma melhoria significativa em comparação com os antecessores mais tradicionais.

Mas o que significa isto fora do software? Será que os métodos ágeis podem ser aplicados com sucesso noutros tipos de trabalho? Muitos proponentes (vários deles começaram no sector do software) argumentam que a resposta é sim, e um número crescente de livros, artigos e textos em blogues sugerem como pode ser feito. As provas, porém, permanecem limitadas até agora, e um artigo recente de dois dos fundadores do ágil avisa contra a aplicação indiscriminada do conceito. A blogosfera está também repleta de discussões sobre uma reacção negativa ao ágil.

Para oferecermos alguns conselhos práticos aos líderes empresariais que tentam compreender o que pode significar o ágil nas suas organizações, usamos uma abordagem diferente. A nossa pesquisa sugere que, ao aplicarem métodos ágeis do sector do software noutras áreas, os gestores muitas vezes confundem práticas e princípios. Quando os métodos ágeis funcionam, isso acontece porque as práticas associadas manifestam princípios comportamentais importantes no contexto do desenvolvimento de software. Mas por muito sucesso que estas práticas possam ter no desenvolvimento de software, não há qualquer garantia de que funcionem noutros contextos. A chave para se transferir um conjunto de práticas de um domínio para o outro é compreender primeiro por que razão elas funcionam e depois modificá- -las de forma a estarem alinhadas com o novo contexto e a manterem os princípios subjacentes.

O objectivo deste artigo é ajudar a compreender vários princípios importantes que reforçam não só as práticas ágeis no software, como também o famoso sistema de produção da Toyota Corp. Assim que estes princípios subjacentes são compreendidos – através de uma estrutura a que chamamos de estrutura de trabalho dinâmica – é possível criar processos de trabalho flexíveis e mais eficientes na organização.

Estabilidade versus incerteza
Académicos e gestores há muito acreditavam que as organizações tinham de criar cedências entre flexibilidade e eficiência. Uma noção central na teoria académica sobre a estrutura organizacional é a contingência, a ideia de que as organizações e os seus processos associados precisam de ser concebidos de forma a estarem alinhados com a natureza do trabalho. Uma das variáveis mais comuns na teoria da contingência é o grau de incerteza no ambiente circundante (muitas vezes conceptualizado como a necessidade de inovação). Quando o ambiente competitivo e o trabalho associado são estáveis e bem compreendidos, a teoria da contingência sugere que as organizações terão mais sucesso com estruturas altamente estruturadas e mecanicistas. Em contraste, ao enfrentarem situações altamente incertas que exigem uma adaptação contínua, a teoria sugere que as organizações têm mais sucesso com estruturas mais flexíveis e orgânicas.

Um dos primeiros defensores da abordagem mecanizada para uma estrutura de trabalho foi Frederick Winslow Taylor, autor do livro de 1911 intitulado “Os Princípios da Gestão Científica”. A principal descoberta de Taylor era a ideia de que se um trabalho for repetido regularmente, então pode ser estudado e aperfeiçoado. Em ambientes estáveis e bem compreendidos, muitas vezes é melhor organizar o trabalho de maneira a aproveitar a eficiência que se ganha com a repetição. Por exemplo, numa fábrica moderna, as tarefas bem definidas são especificadas e o trabalho é feito em série, passando de um conjuntos cuidadosamente construído e definido de actividades para o próximo. Há pouca necessidade de colaboração nestes contextos e a estrutura organizacional que rodeia o trabalho estável e repetível tende a ser hierárquico, para assegurar que todos seguem a estrutura criada. O custo dessa eficiência é a adaptabilidade. Devido ao alto nível de rotinas e formalidades, as estruturas mecanicistas são difíceis de mudar em resposta a novas exigências. Embora eficiente, uma estrutura mecanicista não é ágil.

Quando, contudo, o ambiente é instável e incerto, as tarefas discretas são mais difíceis de definir e, por isso, as organizações não conseguem depender de uma sequência de passos claramente definidos. Por exemplo, as equipas de desenvolvimento de produto enfrentam frequentemente desafios para os quais há poucos precedentes. A teoria da contingência indica que em ambientes imprevisíveis como o desenvolvimento de novos produtos, as organizações dependem mais de factores como a formação e a colaboração e menos da rotina e da especificação cuidadosa. Desenvolver um produto ou serviço inovador é algo que não pode ser organizado como a linha de montagem de uma fábrica. Os peritos em marketing podem desenvolver um conjunto de exigências iniciais, que depois são passadas para os designers e os engenheiros, mas estas passam muitas vezes por múltiplas interacções, à medida que designers e engenheiros determinam o que é tecnicamente possível. Consequentemente, os processos de desenvolvimento eficazes exigem frequentemente uma colaboração contínua em tempo real, e não uma adesão mecânica a um conjunto de passos organizados sequencialmente.

Embora a teoria da contingência tenha sido desenvolvida pela primeira vez há mais de 50 anos, as suas ideias básicas reaparecem frequentemente no pensamento contemporâneo de gestão. Muitas variantes das melhorias concentradas no processo, como a gestão de qualidade, o Sigma Seis e a reengenharia dos processos empresariais, são extensões das ideias fundamentais de Taylor de que o trabalho que é repetido pode ser melhorado. Recentemente, a cada vez mais popular abordagem do “design thinking” pode ser vista como uma maneira de lidar com tarefas ambíguas e incertas com uma estrutura de trabalho mais colaborativa e menos hierárquica. Em geral, a teoria da contingência dá aos gestores uma abordagem simples para a estruturação do trabalho: avaliar a estabilidade do ambiente competitivo e o trabalho resultante e depois escolher a melhor mistura de tarefas definidas e colaboradores para enfrentar o desafio em mão. Se o trabalho consiste em tarefas bem definidas (como a montagem de componentes), então é melhor organizar tudo serialmente, ou, como dizemos, usando o modo “fábrica”. Inversamente, se o trabalho é altamente ambíguo e exige uma iteração contínua (por exemplo, criar novos produtos), o trabalho fica melhor organizado em colaboração ou, como dizemos, no modo “estúdio”.

Embora poderosa, esta abordagem às estruturas de trabalho não é totalmente satisfatória por duas razões. Primeiro, descreve um compromisso difícil de digerir: o trabalho feito com uma estrutura em série não é muito flexível, o que faz com que seja difícil de se adaptar a mudanças nas condições externas, e o trabalho feito em modo estúdio muitas vezes não é eficiente. Segundo, poucos tipos de trabalho encaixam perfeitamente no arquétipo de trabalho bem definido ou ambíguo. Até o trabalho mais rotineiro tem os seus momentos ocasionais de surpresa e, inversamente, até o trabalho mais criativo, como criar um novo produto ou serviço, exige muitas vezes a execução de análises de rotina e testes que apoiam cada iteração criativa. Independentemente das teorias académicas, o trabalho real é uma mistura de rotina e incerteza.

À primeira vista, os métodos ágeis parecem inclinar-se mais para o lado colaborativo do espectro do trabalho. Contudo, a nossa pesquisa sugere uma interpretação diferente. A abordagem convencional para as estruturas de processos e organizações são quase totalmente estáticas, presumindo implicitamente que assim que uma parte do trabalho é estruturada, tudo correrá como planeado. Em contraste, uma abordagem dinâmica para a estrutura do trabalho sugere ver o trabalho como uma resposta evolutiva aos tropeções e falhas que são inevitáveis nas organizações reais. Como iremos descrever mais tarde neste artigo, os métodos ágeis transcendem a questão “trabalho tradicional em série versus trabalho colaborativo” ao criarem mecanismos mais adequados para circular entre as duas formas básicas de organização de trabalho. Ao identificar mecanismos para, quando apropriado, saltitar entre tarefas bem definidas e modos colaborativos, uma abordagem ágil pode reduzir consideravelmente a cedência entre eficiência e adaptabilidade.

Estrutura de trabalho dinâmica na Toyota
Como funciona isto na prática? Vejamos um exemplo bem conhecido de estrutura de trabalho e organizacional, o cordão Andon da Toyota. O trabalho nas linhas de montagem da Toyota é o epitome da estrutura em série e mecanicista. As tarefas são especificadas com precisão, muitas vezes pormenorizando movimentos específicos do braço e da mão e a altura a que cada acção deve ter lugar. Numa fábrica que visitámos recentemente, a formação para um cargo específico começou com uma estagiária a aprender a apanhar quatro parafusos ao mesmo tempo – não três ou cinco. Só quando a estagiária conseguiu apanhar quatro parafusos regularmente é que teve permissão para passar para o movimento seguinte. Mas, apesar da atenção ao pormenor, que deixaria Taylor cheio de orgulho, por vezes as coisas correm mal. No esquema da Toyota, um colaborador que dê conta de um problema deve puxar aquilo que é conhecido como cordão Andon (ou carregar num botão) para parar a linha de produção e resolver o problema.

Embora os livros sobre gestão tenham sublinhado correctamente a importância de permitir aos colaboradores que parem a linha, o que acontece depois de puxarem o cordão pode ser mais importante. Durante uma visita recente que fizemos a um fornecedor da Toyota na Cidade da Toyota, no Japão, observámos que uma operadora da fábrica estava a ter dificuldade em terminar a sua tarefa no tempo necessário, por isso carregou num botão amarelo, ligando um alarme e uma luz. (Esta fábrica substituiu o cordão Andon por um botão amarelo em todas as estações dos operadores.) Em segundos, o supervisor chegou e ajudou a operadora a resolver a questão que a estava a impedir de seguir o processo decidido. Em menos de um minuto, a operadora, que já podia atingir o seu prazo, regressou à sua rotina normal e o supervisor às suas actividades.

O que, da perspectiva da estrutura do trabalho, aconteceu neste pequeno episódio? Inicialmente, a operadora estava a trabalhar em modo “fábrica”, executando um trabalho bem definido para um prazo bem definido. Mas quando algo nessa estrutura cuidada falhou, a operadora não conseguiu completar as suas tarefas no tempo desejado. Assim que ocorreu o problema, a operadora teve duas opções. Podia ter encontrado uma adaptação, uma alternativa ou um atalho que lhe permitisse continuar a trabalhar. Mas esta escolha leva frequentemente a resultados disfuncionais. Em alternativa, como observámos, ela podia carregar no botão, parar o trabalho e pedir ajuda. Ao chamar o supervisor e pedir a sua ajuda, carregar temporariamente no botão alterou a estrutura do trabalho. O sistema deixou por breves momentos o modo mecanicista e em série para passar para uma abordagem mais colaborativa e orgânica, concentrada na resolução de problemas. Assim que o problema ficou resolvido, a operadora voltou à sua tarefa normal e à sua estrutura de trabalho em série.

O sistema de produção da Toyota pode ao início parecer ser o ideal no design mecanicista, mas um olhar mais atento sugere algo mais dinâmico. Quando um colaborador puxa o cordão Andon, o sistema move-se entre os dois modelos com base no estado do trabalho. Embora a natureza do trabalho seja totalmente diferente, esse movimento entre os dois modos é também a chave para se compreender o sucesso do desenvolvimento ágil de software.

O ágil como estrutura de trabalho dinâmica
Como debatemos anteriormente, as últimas duas décadas foram testemunhas de uma mudança significativa no desenvolvimento de software. Enquanto o software já foi desenvolvido usando aquilo que é conhecido como abordagem cascata, os métodos ágeis tornaram-se cada vez mais populares. Da perspectiva de uma estrutura de trabalho dinâmica, as abordagens cascata e ágil diferem significativamente.

Na abordagem cascata, o ciclo de desenvolvimento de software é normalmente dividido em poucas e grandes fases. Um projecto pode incluir uma fase de requerimentos, uma fase de desenvolvimento, uma fase pormenorizada de código e uma fase de testes e instalaão. Um projecto cascata normalmente desloca-se entre três modos básicos de trabalho. Primeiro, os programadores e engenheiros de software gastam a maior parte do tempo a trabalhar individualmente ou em pequenos grupos, completando o que a fase específica exige. Segundo, normalmente todas as semanas, essas pessoas deixam o seu trabalho individual para se juntarem numa reunião de projecto, onde reportam o seu progresso, verificam compatibilidades mútuas e adaptam-se a quaisquer alterações na direcção fornecida pela liderança. Terceiro, no final de cada fase, existe uma análise mais significativa, muitas vezes conhecida como “revisão de fases”, na qual os líderes seniores fazem uma análise pormenorizada para determinarem se um projecto está pronto para sair dessa fase e passar para a próxima. Os ciclos de desenvolvimento de outros projectos fora da área do software funcionam muitas vezes de forma semelhante. Os processos de desenvolvimento ágeis organizam o trabalho de maneira diferente. Por exemplo, na abordagem “formação ordenada” (uma versão do ágil), o trabalho não é dividido em poucas fases importantes, mas em diversos “sprints” curtos (muitas vezes de uma ou duas semanas) concentrados em terminar todo o trabalho necessário para criar uma parte de software pequena, mas em funcionamento. No final de cada sprint, o utilizador final testa a nova funcionalidade para determinar se esta cumpre ou não a necessidade específica.

Como no método cascata, a abordagem ágil para o desenvolvimento de software tem também três modos de trabalho básicos – trabalho individual, reuniões de equipa e críticas dos clientes –, mas move-se entre eles de forma muito diferente. Primeiro, os defensores do ágil sugerem reuniões diárias – passando assim do trabalho individual para o trabalho em equipa e vice-versa todos os dias – na forma de uma reunião “formação ordenada”, onde os membros da equipa reportam o progresso do dia, os seus planos para o dia seguinte e possíveis obstáculos. Segundo, o ágil recomenda que no final de cada sprint, a equipa deixe o cliente testar a funcionalidade nova. Por fim, semelhante ao cordão Andon, algumas versões do ágil incluem igualmente um aviso imediato a toda a equipa quando uma parte do código não passa nos testes apropriados, movendo efectivamente o sistema do trabalho individual para o modo de colaboração da equipa.

Do ponto de vista da estrutura de trabalho dinâmica, o ágil oferece dois possíveis benefícios em comparação com a cascata. Primeiro, no desenvolvimento em cascata, a frequência dos episódios colaborativos é normalmente demasiado baixa, tanto entre os membros da equipa como entre a equipa e os clientes. Um programador que trabalhe uma semana ou duas sem um controlo pode desperdiçar esforços consideráveis antes de se tornar óbvio que cometeu um erro ou saiu da direcção desejada. Na prática, os programadores muitas vezes não esperam tanto tempo e falam informalmente com os supervisores ou membros da equipa. Embora aparentemente funcionais, estes controlos podem levar a uma situação em que a equipa não está a trabalhar a partir de uma base comum de informações sobre o estado do projecto. Nesses casos, o modo de operação começa a passar para o modo “fábrica”, onde o trabalho ambíguo é organizado em série. Isto cria uma iteração dispendiosa e lenta, a que chamamos iteração ineficaz. Pesquisas sugerem que nos processos de I&D [investigação e desenvolvimento], este modo pode ser altamente ineficiente. Similarmente, falar com a liderança sénior apenas nas revisões de fases periódicas significa que a equipa pode trabalhar durante meses antes de perceber que não está a cumprir as expectativas da gestão, fazendo assim com que o trabalho tenha de ser feito de novo.

A abordagem ágil para o desenvolvimento de software também melhora a qualidade do tempo que os programadores passam a trabalhar sozinhos. O enfoque no desenvolvimento de partes da funcionalidade significa que a equipa e o cliente nunca estão a mais do que umas semanas de distância de um software que pode ser usado, o que faz com que seja mais fácil avaliar se cumpre as expectativas do cliente. Em contraste, na cascata, as fases iniciais são caracterizadas por longas listas de exigências e características, mas não há nada para testar ou experimentar. Não surpreende então que os métodos em cascata muitas vezes levem a projectos nos quais as grandes falhas e outras lacunas são descobertas muito tarde no ciclo de desenvolvimento e exigem alterações dispendiosas.

Aplicar a estrutura de trabalho dinâmica
Tanto o sistema de produção da Toyota como os métodos ágeis de software são assim exemplos daquilo a que chamamos uma boa estratégia de trabalho dinâmica. Em contraste com as tradicionais abordagens estáticas, a estrutura dinâmica reconhece a inevitabilidade da mudança e desenvolve mecanismos para responder a ela. Assim que os gestores reconhecem a necessidade de se moverem entre modos de trabalho mais individuais e mais colaborativos, podem desenvolver quatro princípios para criar mecanismos de mudança que estejam bem alinhados com o trabalho da sua organização.

· Dividir trabalho bem definido e trabalho ambíguo.

Comecem por dividir claramente as tarefas bem definidas e as ambíguas. Tentar lidar com os dois tipos de trabalho no mesmo processo causa muitas vezes problemas. Os dois tipos podem ser frequentemente divididos através de uma avaliação, mas se não for possível, deve procurar-se o principal elemento do trabalho ambíguo, a iteração. Quando o trabalho é bem definido, pode passar para a fase seguinte como o testemunho que é passado numa corrida de estafetas. Quando tudo é feito correctamente, o testemunho não precisa de voltar para trás. Por outro lado, quando o trabalho é ambíguo, até os melhores esforços precisam muitas vezes de ser avaliados. Se uma tarefa em particular precisa de múltiplas iterações no mesmo conjunto de passos, é um bom sinal de que estamos perante uma ambiguidade ineficiente.

· Transformar os processos em unidades mais pequenas de trabalho que podem ser verificadas com mais frequência.

Se retirarmos toda a propaganda exagerada, a agilidade de qualquer processo de trabalho – ou seja, a sua capacidade de ajustar o trabalho devido a mudanças nas condições externas e de resolver problemas – resume-se à frequência e eficácia dos resultados. Na produção pré- -Toyota e no desenvolvimento de software em cascata, as avaliações eram pouco frequentes e pouco eficazes. Consequentemente, ambas as abordagens tendem a ser lentas a ajustarem-se a mudanças externas e a qualidade só é atingida com ciclos de revisão de trabalho lentos e dispendiosos. Em contraste, quando as avaliações são frequentes e eficazes, o processo torna-se altamente adaptável e a qualidade melhora rapidamente. A receita fundamental para melhorar a agilidade dos processos é isto: unidades de trabalho mais pequenas e verificadas com mais frequência.

· Identificar a cadeia de indivíduos que apoiam quem faz o trabalho.

É também importante identificar a cadeia de ajuda – a sequência de pessoas que apoiam quem faz o trabalho. Na produção, a cadeia de ajuda começa com um operador de máquina e vai dos encarregados aos supervisores até ao gestor da fábrica. No software, a cadeia de ajuda começa muitas vezes com um engenheiro e vai até ao líder da equipa e aos gestores seniores, acabando no cliente. É crucial, segundo a nossa experiência, identificar as cadeias de indivíduos que fazem e apoiam o trabalho, não os seus cargos, departamentos ou funções. Aumentar a agilidade exige saber quem chamar quando há um problema ou quando é preciso feedback.

· Apresentar estímulos e controlos que passam o trabalho para um modo mais colaborativo.

Assim que se compreende a cadeia de ajuda, temos dois mecanismos básicos para a activar: estímulos e controlos. Um estímulo é um teste que revela defeitos ou falta de alinhamento e depois passa o trabalho do modo fábrica para um modo mais colaborativo. No nosso primeiro exemplo, a incapacidade da operadora da Toyota para completar a sua tarefa na linha de montagem fez com que carregasse num botão e recebesse ajuda de um supervisor. Um controlo envolve um ponto pré-definido em que o trabalho passa para um ambiente mais colaborativo para ser avaliado. No desenvolvimento ágil de software, esta mudança acontece diariamente nas reuniões em que a equipa avalia rapidamente o estado actual do projecto. Completar um sprint cria uma segunda oportunidade, desta vez para falar com o cliente.

Melhorar o desempenho das compras

Usar esta estrutura de trabalho dinâmica dentro de uma empresa pode levar a melhorias significativas na eficiência e na adaptabilidade. Vejamos o caso de uma empresa a que chamaremos “RefineCo”, proprietária de várias refinarias de petróleo e terminais de distribuição nos Estados Unidos da América. A empresa tinha uma organização de compras pouco competitiva, independentemente dos critérios. A RefineCo pagava mais por peças e serviços semelhantes do que as suas concorrentes e os custos gerais do grupo das compras eram mais altos do que a média do sector. Mais preocupante, quando peças fundamentais não eram entregues numa refinaria, muitas vezes descobria-se que esta estava “suspensa em crédito” devido à incapacidade de pagar ao fornecedor a tempo e horas. Todos os participantes no sistema, da gestão sénior aos colaboradores que enviavam e recolhiam material, se sentiam frustrados.

O sistema de compras de cada um dos locais da RefineCo trabalhava da seguinte forma. Para comprar um item ou serviço a um fornecedor, um colaborador colocava os requisitos no sistema de compras electrónico, que depois aparecia como um pedido na função central de compras. Os colaboradores da secção das compras analisavam então o pedido e lançavam um pedido de compras. Esse pedido ia para o fornecedor. Quando o produto chegava à refinaria ou o serviço tivesse terminado, era gerado um recibo de entrega ou recibo de verificação de serviço, que também entraria no sistema de compras. Mais tarde, o fornecedor mandaria a fatura, que também entraria no sistema. O sistema electrónico verificava então se tudo havia sido feito correctamente: a ordem de compra devia bater certo com o recibo de verificação que, por sua vez, teria de bater certo com a fatura. Se isso não acontecesse, a fatura seria “retirada” do sistema e o fornecedor não receberia até a discrepância ser resolvida.

O problema de resolver essas discrepâncias cabia aos colaboradores do departamento de compras da refinaria. Infelizmente, os produtos e serviços adquiridos muitas vezes não estavam alinhados no sistema, levando a um excesso de trabalho no departamento de compras e a fornecedores frustrados. Embora a refinaria fizesse parte de uma empresa grande e bem-sucedida, muitas vezes estava “suspensa” por não pagar a tempo, tornando mais difícil aos colaboradores fazerem o seu trabalho e gerirem a fábrica com segurança. O pessoal do departamento das compras trabalhava mais de 10 horas por dia e contratava pessoal temporário para ajudar a lidar com os atrasos, mas continuava a ficar para trás.

A maioria dos membros da equipa das compras queixava-se de excesso de trabalho e de o sistema não funcionar adequadamente. Ninguém viu qualquer oportunidade de melhoria para além do aumento dos colaboradores em falta. Para nós, o momento crucial no nosso trabalho com o pessoal das compras foi quando um dos membros mais antigos da equipa explicou que um bom pedido de compras continha «todas as informações necessárias» e podia ser transformado num pedido oficial de compras em «cinco ou 10 minutos». Mas um pedido de compras difícil não continha informações importantes e poderia levar uma a duas horas a processar à medida que os colaboradores das compras trocavam emails com a unidade que fez o pedido e com os fornecedores. Apesar deste esforço, os pedidos difíceis eram normalmente os que falhavam o processo de verificação e eram retirados do sistema. Outra análise revelou que o sistema de pedidos de compras estava totalmente atolado com os pedidos retirados e a equipa passava muito tempo a tentar limpá-los. O sistema entrara na armadilha habitual: existiam tantos pedidos de compras a serem processadas que o tempo de resposta a qualquer um era demasiado longo. Mas os longos tempos de resposta criavam clientes e fornecedores insatisfeitos que ligavam constantemente a reclamar e a perguntar sobre um pedido ou pagamento em particular. Consequentemente, a equipa de compras estava constantemente a alterar as suas prioridades e a reagir ao cliente ou fornecedor mais insatisfeito.

A primeira coisa que fizemos foi reconhecer que a equipa de compras estava envolvida em dois tipos diferentes de trabalho que correspondiam àquilo a que chamamos trabalho de “fábrica” em série e trabalho colaborativo de “estúdio”. Quando o item pedido era comum e era fornecida toda a informação necessária, uma única pessoa podia processar facilmente o pedido sem colaboração; depois, quando o pedido de compra entrava, passava facilmente pelo sistema, como um item numa linha de montagem. Contudo, os pedidos comuns só passavam facilmente pelo sistema se o pedido viesse com a informação correcta. Se não, então exigiria várias rondas de iteração, normalmente através de email, para lançar o pedido de compra. Como tal, a função de compra criou uma checklist simples que descrevia um bom pedido de compras. A ideia era assegurar que os pedidos comuns chegassem sempre com a informação correcta. Para dar aos vários departamentos um incentivo para usar a checklist, o departamento de compras prometeu que qualquer pedido recebido depois das 7 da manhã com as informações adequadas resultaria num pedido de compra lançado por volta das 14h. Na altura, um tempo de resposta de um dia era inédito, porque todos os pedidos iam simplesmente para a pilha “a fazer”. O departamento de compras também criou um estímulo simples para melhorar a produtividade: os pedidos de compra com itens da checklist em falta seriam devolvidos imediatamente à unidade que os pedira.

A segunda parte da intervenção implicou o reconhecimento de que nem todos os pedidos poderiam ser suportados em modo fábrica. No sistema existente, nem quem fazia os pedidos nem o pessoal das compras distinguia entre um pedido comum e um novo. Assim, quando aparecia um pedido novo para um produto ou serviço, o agente daria o seu melhor para o processar, normalmente exigindo diversos emails, muitas vezes ao longo de vários dias, para obter as informações relevantes. Em muitos casos, quando os agentes não conseguiam obter as informações, faziam o melhor que podiam e submetiam um pedido incompleto ou incorrecto. Isto também criava uma iteração adicional, já que o fornecedor, sem ter a certeza do que fora pedido, teria de telefonar ou mandar um email ou colaborador. O processo de compra era como tentar atingir um trabalho ambíguo num modo em série, criando assim uma iteração lenta e dispendiosa.

Criar um modelo colaborativo eficaz para lidar com os complexos pedidos de compras exigiu duas mudanças na estrutura do trabalho. Primeiro, a equipa criou um estímulo claro: se um pedido estava fora dos padrões normais, passaria para uma pilha diferente e não seria processado imediatamente. Segundo, todos os dias, às 14h, a equipa trabalharia em conjunto para processar os casos mais complexos. Ao trabalharem em colaboração (em modo estúdio), conseguiam resolver muitos dos casos mais complexos sem intervenções adicionais – alguém da equipa poderia ter tido um pedido semelhante anteriormente. Além disso, ter uma reunião presencial era muito mais eficiente do que a interminável cadeia de emails que a substituía. E, se fosse preciso informações adicionais, a equipa podia programar um telefonema após as 14h, em vez de enviar um email, mais uma vez reduzindo o número de iterações dispendiosas. Os resultados destas duas alterações foram significativos. Criar um modo fábrica para as ordens comuns permitiu à equipa fazer bons progressos na promessa “entrar às 7h, sair às 14h” que imediatamente, gerou uma enorme boa vontade por parte de quem fazia os pedidos. Passar a tarde em modo estúdio também acelerou o processo dos pedidos complexos. As duas alterações criaram espaço suficiente para a equipa usar o tempo de estúdio não só para processar os pedidos mais complexos, mas também para trabalhar nos pedidos por resolver. No fim, graças às melhorias na eficiência, a equipa de compras reduziu o seu staff no equivalente a dois colaboradores a tempo inteiro, oferecendo ao mesmo tempo um serviço muito mais rápido e fiável. Estas melhorias nos processos foram depois aplicadas noutros locais da empresa nos EUA e, na altura deste artigo, a RefineCo paga mais de 90% das suas faturas a tempo, resultando num grupo de fornecedores mais satisfeito.

Procurar os melhores princípios
Gestores e consultores muitas vezes ficam obcecados com a procura das melhores práticas – as actividades que parecem separar as melhores organizações do resto da matilha. A ideia por detrás desta pesquisa é que, assim que identificadas, as melhores práticas podem ser adoptadas por outras organizações, que depois passarão por ganhos semelhantes no desempenho. Embora haja alguma verdade nesta ideia, as provas são decididamente contraditórias. As organizações muitas vezes sentem dificuldade em implementar novas ferramentas e práticas e raramente experimentam ganhos semelhantes no desempenho. Em muitos sectores, o fosso no desempenho entre os colaboradores de topo e os intermédios permanece resolutamente difícil de fechar. Uma das principais razões para estes fracassos é que as organizações são configurações complexas de pessoas e tecnologias, e um conjunto de ferramentas ou práticas que funcionam bem num contexto pode não ser tão eficaz numa grande concorrente – mesmo que essa concorrente esteja apenas ao virar da esquina.

As melhores práticas são as “melhores” quando manifestam um princípio comportamental subjacente bem alinhado com a organização que as utiliza. O famoso cordão Andon e a resolução de problemas que catalisa funcionam ao aproveitar a eficiência que nasce da repetição individual e da inovação que nasce da resolução conjunta de problemas. Inversamente, os métodos ágeis de desenvolvimento funcionam ao aproveitarem a criatividade dos engenheiros de software através de reuniões frequentes e interações com os clientes. De forma mais generalizada, as organizações tornam-se mais adaptáveis quando encontram rapidamente defeitos e falta de alinhamento. Uma abordagem dinâmica para a contingência, apoiada por estímulos e controlos, pode abrir o caminho para a criação de práticas que apoiam o aumento da agilidade no trabalho de uma organização.

Este artigo foi publicado na edição 91 da Human Resources.