Problemas, você tem método ou a crença de que o tempo resolve?

Antes de entrar na discussão sobre método para a solução de problemas, precisamos entender o quê, de fato, é um problema. Coloquialmente, na fala do dia a dia, é comum definirmos problema como sendo qualquer coisa diferente do esperado. Mas, pensando de modo estruturado, focando em encontrar uma solução para essa condição não desejada, é melhor entender que um problema é tudo aquilo que está fora do padrão e não se sabe o motivo. Dito de outra forma, “problema é qualquer desvio de causa desconhecida”.

A esta altura alguém pode estar se perguntando ‘como assim? Um resultado não desejado ou um desvio do que era esperado eu entendo’, mas ‘por que incluir não se sabe o motivo ou a causa’ nessa definição. ‘Que diferença isso faz?’ Pois bem, aí está a grande sacada, se não sabemos o motivo, a origem do desvio, precisamos de um método para encontrar sua(s) causa(s) para então agir eliminando-a(s) do processo que gerou a situação inesperada e evitando-se que o problema persista. Por outro lado, se sabemos qual é o fato gerador do desvio, chegar a uma solução é bem mais simples, basta tomar uma decisão de como eliminá-lo do processo.

Entendido isso, o conceito de problema, vamos ver que método podemos adotar para sua solução. Não há um único método, ao longo da história, por todo o século passado (talvez antes disso), pensadores e pesquisadores vêm desenvolvendo sistemáticas (métodos) para a solução estruturada de problemas. Dentre os mais conhecidos estão o MASP, o A3, o DMAIC, o 8D, o Kepner Tregoe (de quem tomamos a definição de problema), entre outros. Sumarizando, cada método:

MASP (Método de Análise e Solução de Problemas) é o método utilizado pelo movimento da Qualidade Total, para a melhoria contínua de processos e seus resultados. Ele foi estruturado no arcabouço do modelo de gestão do PDCA (Plan, Do, Check e Action), levado ao Japão do Pós 2ª Grande Guerra pelo consultor americano J. W. Deming. Por lá foi chamado de QCStory (de Quality Control Story). São 8 etapas, organizadas no contexto do PDCA: [P] (1) identificar o problema, (2) observar seu contexto, (3) analisar sua(s) causa(s), (4) estabelecer um plano de ação, [D] (5) agir (implementar as ações planejadas), [C] (6) verificar sua eficácia, [A] (7) padronizar a solução para evitar reincidências e (8) concluir (analisar potenciais melhorias à aplicação do método).

A3, ou Relatório A3, assim denominado por originalmente ser trabalhado numa folha de papel tamanho A3. Esse método, que também está estruturado dentro do ciclo PDCA, foi desenvolvido e é utilizado pela Toyota, compondo o rol de ferramentas do Modelo Toyota de Produção (ou, Modelo de Produção Enxuta). São 8 suas etapas: [P] (1) definir o problema, (2) entender seu estado atual, (3) definir o que precisa ser solucionado, (4) analisar sua(s) causa(s), (5) estabelecer contramedidas, [D] (6) aplicar as contramedidas, [C] (7) avaliar os resultados, [A] (8) padronizar o novo processo.

DMAIC (acrônimo de Define, Measure, Analyse, Improve, Control) é o método utilizado no âmbito do Modelo de Gestão Seis Sigma, desenvolvido pela Motorola (USA). Podemos pensar que é um método derivado, uma contrapartida americana, ao MASP ou ao A3, sendo trabalhado em 5 etapas: [D] (1) identificar e definir o problema, [M] (2) quantificar o tamanho do problema, [A] (3) analisar a(s) causa(s), [I] (4) estabelecer uma solução de melhoria, [C] (5) controlar mantendo a solução.

8D (8 Disciplinas), é um método utilizado pela indústria automobilística FORD (USA), como forma de resolução de problemas orientados por equipes. As 8 disciplinas, ou etapas, são: (1) constituir a equipe de trabalho, (2) descrever o problema em detalhes, (3) conter o problema identificado reduzindo riscos, (4) investigar a origem (causas) do problema, (5) definir ações de melhoria para a solução do problema (eliminação das causas), (6) implementar as melhorias, (7) prevenir a recorrência do problema padronizando a solução, (8) finalizar o processo comemorando a solução.

Problem Analysis (PA) – Análise de Problema, é uma sistemática integrante do denominado processo racional de gestão, desenvolvido pela consultoria americana Kepner Tregoe. Ela orienta como encontrar a causa raiz de um desvio por meio do uso disciplinado de lógica e dados. Essa sistemática ajuda a focalizar os dados apropriados e evitar a tendência de olhar para causa(s) improvável(eis) antes que fatos relevantes tenham sido examinados. Suas etapas incluem descrever o problema, identificar e avaliar as possíveis causas e testá-las até encontrar a causa verdadeira, quando então ações corretivas são tomadas.

Em sua essência, todos os métodos têm em comum uma definição clara e objetiva do problema, a busca de dados e fatos sobre sua(s) causa(s), o planejamento e a implementação de ações de correção sobre o desvio com a confirmação de sua efetividade e a manutenção da melhoria imposta ao processo.

O mais importante aqui, além de entender o conceito de problema (desvio de causa desconhecida) é adotar um método. Mas qual? O que o responsável, ou a equipe, a quem cabe a solução do problema sentir ser o mais apropriado e/ou tem domínio sobre a sistemática. Em linhas gerais, tanto faz o método utilizado – todos se aplicam bem a solução de problemas complexos em processos –, o que importa é aplicar um método, sair de achismos. Isso traz eficiência à análise e identificação da(s) causa(s) (do desvio no processo) originando o problema e garantia de que a solução será eficaz (resolve o problema, com qualidade e economia de recursos) e efetiva (garante sua não recorrência).

Processos, veículo para a gestão da rotina

Processos, padronização e produtividade são expressões indissociáveis, mas nem todos reconhecem isso. Pelo contrário, é muito comum ouvirmos, em diversas empresas, de gestores em todos os níveis, a fala “padronização engessa a empresa”. Será? Essa generalização pode ser tomada como um fato?

Toda vez que ouço isso me lembro da imagem de um pit stop na F1, que fala por si. Os fãs do esporte de corridas automobilísticas, de sua principal categoria a Fórmula 1 (F1), sabem bem do que se trata. Como nem todos são seguidores desse esporte, vamos entender o que a imagem representa.

Numa corrida de F1, e outras categorias de velocidade, vence a corrida o piloto mais rápido e eficiente volta a volta na pista, desde que sua equipe de box, em intervenções no carro durante os chamados pit stops, também seja rápida e precisa. Na F1 essas paradas são obrigatórias, pelo menos uma deve ocorrer ao longo da corrida, para a troca dos pneus de um tipo de composto e dureza para outro. E não é só isso que acontece, por vezes são feitos ajustes em inclinação de asas, limpeza de entradas de ar de radiadores e viseira do piloto, quando não a substituição da asa dianteira que tenha sido danificada por toque com outro veículo ou escapada da pista.

Num pit stop na F1, em volta do carro há pelo menos umas 20 pessoas dentre mecânicos, monitores e chefe de equipe. No pequeno espaço restrito à parada, essa equipe consegue trocar os 4 pneus, e fazer algum ajuste e limpeza, em tempos entre 2 a 2,5 segundos e até menos. Como? Com processos bem desenhados e pessoal altamente treinado, levando à quase perfeição da ação com uma produtividade invejável. Se essa padronização é o que alguns querem dizer com engessamento, então está tudo certo!

Uma empresa bem estruturada funciona como uma coleção de processos sequenciados. O que isso significa? Tomando o caso da F1, de modo simplificado, a cada ano, o primeiro processo seria o projeto do carro, de seus subconjuntos e componentes, incluindo as ferramentas necessárias à montagem, substituição de partes e peças e para a troca rápida do conjunto rodas/pneus e asa dianteira. Tem também o desenho da melhor sequência de preparação e execução de pits stop obrigatórios ou não. Mas não fica só nisso, há o processo de montagem do carro (antes do primeiro treino preparatório para a corrida) e o de desmontagem do carro (pós-corrida), e outros tantos, cada um muito bem pensado, mapeado, com a equipe treinada, afinal velocidade, acerto das ações e segurança são palavras de ordem nesse esporte (um negócio).

Quanto à padronização, seu conceito vai além do que muitos pensam, a mera documentação descritiva de como as atividades operacionais devem ser realizadas. Ela passa inevitavelmente pelo treinamento da equipe nos processos e seus procedimentos (no caso da F1, quanto ao pit stop obrigatório, a repetição exaustiva do treino leva à quase perfeição). E, contrariando os que falam em engessamento, os processos devem ser revistos, com a promoção de melhoria sempre que oportuno (na F1, por ex., buscando-se tempos ainda menores para a troca dos pneus).

Concluindo, chegamos à razão de ser dos processos e sua padronização, a tão almejada produtividade em sua definição clássica fazer mais com menos, o que torna essas três expressões indissociáveis. Isso implica ser altamente eficiente – ter processos ágeis, feitos com o menor esforço, no menor tempo, sem perdas e evitando-se riscos – chegando a resultados eficazes – entregas conforme esperado, planejado e/ou prometido.

Com esse entendimento fica fácil compreender por que processos, padronizados e sistematicamente melhorados, são um veículo indispensável à excelência na gestão da rotina, com a garantia de entrega dos resultados projetados.

* Revisado, publicado originalmente no Blog PME Academy

Mapeamento e modelagem de processos

Já sabemos que a padronização de processos é essencial à gestão (ver ensaio Padronização de processos: base para a gestão). Ela é o primeiro passo na busca da previsibilidade dos resultados e servirá de referência para melhorias em processos com vistas a ganhos de competitividade. Então, para que a padronização aconteça de modo eficiente e eficaz, antes de qualquer coisa, precisamos ter compreensão clara e objetiva sobre seus fundamentos e práticas.

O entendimento sobre dois conceitos, muito confundidos, é essencial à boa padronização: mapeamento e modelagem de processos. Qual a diferença entre essas ações? E por que é importante entender isso?

mapeamento_processosMapear um processo é esboçar seu fluxo de atividades. O mapeamento é o primeiro passo para a padronização. O objetivo é conhecer o processo em seu estado atual, obtendo um fluxo preliminar de atividades. Mas isso não é tarefa fácil. Dominar uma simbologia, ter conhecimento sobre algum ferramental de desenho de processos, não implica saber mapear processos. O mapeamento de processos, além do conhecimento sobre sua diagramação, exige habilidade investigativa. O conhecimento sobre o ferramental é de fácil obtenção, já a capacidade para investigação exige muito treino desenvolvendo-se com a prática.

Processos são comuns às atividades humanas, se repetem no dia a dia muitas vezes sem que sejam percebidos por seus executores ou beneficiários. Vão sendo realizados a partir do conhecimento disponível na mente das pessoas que os executam. Obter essa informação, descortinar a sequência de atividades a executar, detalhes de como fazer, o que obter como resultados, identificar os recursos e facilidades necessários a sua execução, etc., não é simples. Diversos são os motivos, da dificuldade de expressão de quem executa o processo à resistência em passar esse conhecimento, da falta de visão sistêmica à ideia de que preservar o conhecimento é garantia de indispensabilidade, e assim por diante. O interessado em mapear o processo, então, precisa ter paciência, jogo de cintura, saber investigar sob vários pontos de vista, usar de imaginação,… Desenvolver essas habilidades – saber lidar com as pessoas e suas dificuldades e resistências – é chave para um mapeamento de processos bem sucedido.

modelagem_processos_bpmnModelar um processo é efetuar o registro do fluxo mapeado segundo determinado tipo de notação. Isso tem dois objetivos, facilitar análise crítica e comunicar o andamento do processo. A padronização é resultado de um processo modelado. É evidente que para mapear necessitamos de alguma simbologia (alguma notação), ou seja, podemos dizer que o mapeamento é uma modelagem descompromissada de uma notação específica ou rígida.

A modelagem permite analisar um processo buscando identificar melhorias, direcionando mudanças para ampliação de competitividade. Inúmeras são as técnicas de modelagem existentes, cada uma com objetivos específicos. Por exemplo, se a intenção é obter ganhos de produtividade, com redução de custos, pode-se utilizar a modelagem preconizada pelo Mecanismo da Função Produção (MFP), que permite identificar restrições e perdas nos fluxos de processo. Se a necessidade é modelar um processo com vistas a sua automatização via TI (tecnologia da informação), pode-se utilizar a Notação de Modelagem de Processos de Negócio (BPMN – Business Process Model and Notation), que facilita a compreensão das trocas de informação entre as atividades.

Não é objetivo deste texto esmiuçar os padrões de modelagem, mas sim explicitar que existem alternativas e deixar claro que o modelo a ser utilizado dependerá do objetivo almejado. Aos interessados em se aprofundar em padrões de modelagem, sugiro pesquisar, além dos exemplos citados (MFP e BPMN), as notações IDEF (Integration DEFinition methods), Workflow, UML (Unified Modeling Language), EPC (Event Driven Process Chain), entre outras.

Gestão por processos ou de processos?

Se observarmos com atenção para os modelos (de excelência) de gestão, sejam normativos, avaliativos ou referenciais amplamente experimentados, todos falam que devemos estabelecer a gestão por processos. Isso está em seus princípios, é um dos fundamentos da excelência em gestão. Por outro lado, se olharmos para a forma como a grande maioria das organizações controla seus processos veremos que é feita a gestão de processos e não por processos. Qual a diferença?

Quando falo de processos, tenho por hábito colocar uma questão aos meus ouvintes “Qual a diferença entre um projeto e um processo?”. A resposta que costuma emergir rapidamente é “Um projeto tem início, meio e fim.” Então digo “Certíssimo!”, mas retruco perguntando “Qual processo também não tem início, meio e fim?” Todos concordam, como deveria ser. Volto a insistir na questão sobre a diferença entre um projeto e um processo. Surgem novas ideias, como “Um projeto tem objetivos claros e recursos escassos.”. Pois bem, digo eu, “Um processo também não tem, ou pelo menos deveria ter, seus objetivos clara e explicitamente estabelecidos? E, também não é realizado com recursos bem definidos, portanto escassos?”. Novamente todos concordam. Eu permaneço na questão sobre a diferença entre projeto e processo: “Mas, então, onde está a diferença?”.

Alguém acaba dizendo “Um projeto é executado uma única vez.”. Logo complemento dizendo “Certo! Um processo é executado inúmeras vezes, mas podemos pensar um projeto como um caso particular de um processo que não se repete.” Então volto à pergunta: “Onde está a diferença?”.

A partir desse ponto da discussão dou uma pista: “E quanto à equipe?”. Alguém acaba dizendo: “Agora percebi, normalmente um projeto é realizado por uma equipe multifuncional.” E eu, novamente, contraponho dizendo “Então vejamos um  macroprocesso, aquele que se inicia com um pedido do cliente e termina com a entrega do produto. Esse processo maior da organização também não é executado por uma equipe multifuncional?”. Diante da expectativa criada, e ainda não aplacada, completo o debate dizendo “Tem sim uma diferença fundamental! Um projeto tem um gestor a quem foi delegado poder sobre o todo, com autoridade para estabelecer o plano de ação e atuar sobre seu andamento (suas causas) e responsabilidade de entregar o resultado (o efeito) esperado, planejado.”.

Retomando a questão original, ‘gestão por processos ou de processos?’, podemos concluir que dificilmente um empreendimento, um negócio, que foi organizado com uma estrutura de poder funcional, departamentalizada, conseguirá instalar a gestão por processos. Essa implica que cada linha (ou família) de produtos (sejam bens e/ou serviços), ou cada segmento de clientes, deveria ter seu atendimento realizado por uma equipe multifuncional, capitaneada por um único gestor com autonomia sobre todo o trajeto (o macroprocesso) e respondendo pelo resultado final, assim como ocorre num projeto.

Com a gestão de processos, o caso comum nas organizações, o que temos são processos funcionais, controlados por gestores departamentais. Ou seja, o atendimento ao cliente, do pedido à entrega, passará por diversas etapas do (macro)processo da organização, onde o resultado acaba sendo medido em partes e não em seu todo. Por isso mesmo esse atendimento acaba sendo tratado como consequência e não como o efeito desejado. Historicamente, temos visto o quanto essa forma de gestão, extremamente arraigada, gera conflitos, disputas de poder, dificuldades para a solução de problemas, levando à desatenção e desatendimento ao cliente.

Como vencer a barreira estrutural da organização departamentalizada? Isso será tema de um próximo ensaio, onde falarei das áreas de autoridade & responsabilidade e suas interdependências e interações…

Inovação de processo

Inovação de processoA inovação de processo tem seu foco em mudanças no conjunto de atividades (o processo) de produção de produtos, sejam bens e/ou serviços. Assim, ela não deve causar alterações, ou qualquer impacto, sobre os produtos. Ou seja, ela atua sobre as causas e não sobre o efeito do processo. Seu objetivo é levar o processo a um novo e bem mais elevado patamar de eficiência, com ganhos significativos de produtividade e/ou qualidade. A inovação de processo não deve ser confundida com melhoria de processo, normalmente um salto limitado de performance em sua eficiência.

Dois métodos para a realização da inovação de processo são o benchmarking e a reengenharia.

O Benchmarking é uma técnica que permite a identificação das melhores práticas de processos, que assim podem ser incorporadas à organização, levando a um desempenho superior. O resultado esperado com a aplicação dessa técnica, e consequentemente seus achados, são práticas excelentes, ideias inovadoras e procedimentos efetivos. O benchmarking essencialmente passa pela comparação das práticas (no caso, de processos) da organização contra as práticas de outras organizações que alcançam performances superiores. Essas outras organizações podem ser outras unidades de um mesmo grupo empresarial ou outras empresas, concorrentes ou não. No caso de outras empresas, se o processo a ser inovado tem ligação direta com a atividade fim da organização, com a produção de seus produtos, então a comparação deve ser feita com concorrentes. Por outro lado, se o processo em inovação está associado a uma atividade meio, de apoio (como, p. ex., gestão de pessoal, serviços internos de TI, etc.), então pode ser comparado com processos de empresas não concorrentes, mas que tenha adquirido uma reputação de excelência na atividade de interesse.

A Reengenharia visa promover um repensar fundamental do processo, levando a uma mudança radical na forma de sua condução, isso feito para que seja obtida uma performance, uma eficiência, muito superior a atual. A reengenharia exige pensamento descontínuo, e essa é a grande dificuldade em sua aplicação, esquecer o que existe e como as coisas funcionam. O objetivo é redesenhar o processo como se fosse a primeira vez, sem um conhecimento preliminar sobre o mesmo, mas apenas e tão somente focando o (novo) nível de desempenho desejado. Uma pergunta chave para a aplicação da reengenharia é “afinal, porque fazemos o que fazemos?”.

Lembrando que a gestão deve entregar previsibilidade como fruto de suas ações, o cuidado que deve ser tomado ao se realizar esse tipo de inovação é evitar a perda da previsibilidade do processo. Em outras palavras, garantir que a entrega do produto aconteça conforme contratado com o cliente. Contudo, deve-se observar que alterações em atividades já bem dominadas sempre levam a algum nível de instabilidade, mas essa deve ser minimizada e seu efeito não pode chegar ao cliente. Daí, uma boa prática na inovação de processos é sua aplicação como um piloto, antes de sua efetivação.