Roberto Priolo: Quais são as principais diferenças entre o sistema de Chief Engineer e uma abordagem tradicional para o desenvolvimento de novos produtos?

Allison Weber: Em nossa experiência na TechnipFMC, o foco do desenvolvimento tradicional de novos produtos está em validar a tecnologia, mas não a totalidade dos processos que suportam a criação do produto acabado. Por exemplo, não se realiza uma análise aprofundada da viabilidade da fabricação do produto ou, como é o caso da nossa empresa, não se valida a cadeia de suprimentos da mesma forma que se valida o desenvolvimento da tecnologia. Por outro lado, em um sistema de Chief Engineer ou LPPD, deseja-se que o desenvolvimento valide o máximo possível de elementos do processo, o que é a melhor maneira de encontrar problemas rapidamente e aprender com eles.

A outra diferença está na abordagem de set-based concurrent engineering pela qual o LPPD é conhecido. No desenvolvimento tradicional de novos produtos, você usa conceitos para selecionar seu projeto - essencialmente, tomando decisões com base em "o que parece melhor no papel". Infelizmente, à medida que você se aproxima da linha de chegada e entra nos detalhes do processo de engenharia, desafios inevitavelmente surgem. Isso não acontece com o LPPD. Alan Labes, ex-Arquiteto Chefe para o nosso produto Subsea 2.0, nos pedia para detalhar todos os possíveis projetos e até mesmo criar protótipos para ver o quão fabricáveis eles eram na realidade. Não me lembro de nenhum projeto que tenha permanecido o mesmo depois disso (normalmente, combinaríamos os melhores elementos dos protótipos produzidos na solução final). Essa maneira de trabalhar leva mais tempo e parece custar mais, mas é na verdade mais rápida, pois evita erros, falhas e “cortar caminhos” no final.

RP: Interessantemente, um Chief Engineer tem a responsabilidade pelo produto, mas não necessariamente a autoridade sobre a equipe. O que isso significa para as interações diárias dele ou dela? Você acha que ter uma cultura lean implementada, criando uma organização mais horizontal onde conversas abertas acontecem o tempo todo, torna mais fácil trabalhar com um sistema de Chief Engineer?

AW: Sem dúvida. Em uma cultura não lean, a hierarquia é tudo. Liderar sem autoridade é possível quando sua visão e seu conhecimento são tão profundos que as pessoas querem seguir essa visão, mas nem sempre é o caso.

Quando adotamos o LPPD na equipe de Engenharia (foi em 2016), desde o primeiro dia, nossos Chief Engineers trabalharam em estreita colaboração com nosso patrocinador, um Vice-Presidente, que pulou algumas camadas de gerenciamento para estar próximo ao trabalho de desenvolvimento. Isso nem sempre foi bem recebido pelas pessoas, mas cinco anos depois, todos estão acostumados a esse tipo de comportamento, porque sabem que é a melhor maneira de obter informações. Portanto, liderar sem autoridade certamente não é fácil, mas é possível contornar isso.

RP: Do ponto de vista dos resultados, o que o LPPD significou para a organização?

AW: Do ponto de vista do desenvolvimento do produto, o qual foi liderado por Alan, dividimos o desenvolvimento em dois aspectos - produto e processo. Nossa estratégia era desenvolver o sistema Subsea 2.0 para ser  mais rápido, mais barato e melhor que o 1.0. Foi necessário um desenvolvimento substancial do produto para alcançar isso e Alan - com razão - decidiu não traduzir custo e prazo em entregáveis de engenharia. Em vez disso, usamos como KPIs o número de peças, o peso e o tamanho: queríamos reduzir pela metade o número de peças, o peso e o tamanho, e queríamos conquistar exatamente o mesmo mercado. Isso tornou a fase de concepção mais fácil de realizar.

Em comparação com a montagem geral de todo o portfólio do 1.0, reduzimos o número de peças em mais de 75%, o tamanho das peças em 45% e o peso em apenas 30%. A principal razão pela qual tivemos dificuldade com a meta de peso, a ponto de eventualmente a desconsiderarmos, é que as pessoas estavam usando-a de forma incorreta, tentando fazer coisas que adicionavam custo apenas para reduzir o peso.

Quando chegamos ao aspecto do desenvolvimento de processo, ao desenvolver um novo processo de configuração sob encomenda, começamos a implementar metas mais abrangentes e cruzadas: um prazo de entrega de 12 meses e uma redução de custo de 25%. Analisamos a lacuna que enfrentamos para cada parte do produto e começamos a descobrir especificamente quais áreas dele queríamos atacar primeiro, com o resultado de que nosso prazo de entrega diminuiu de 24 para 13 meses.

RP: Quais são os principais desafios de introduzir um sistema desse tipo?

AW: Um grande desafio é a governança. À medida que nos aproximávamos do final do desenvolvimento do produto, quando as peças estavam sendo liberadas e o projeto estava sendo finalizado, enfrentamos muita resistência de outras áreas da organização que esperavam assumir a governança do produto. Tradicionalmente, eles fariam isso, mas queríamos mantê-lo próximo ao produto e dentro da equipe, porque sabíamos que é onde reside o conhecimento do produto. A equipe pode resolver problemas para determinar como alcançar valor para o cliente sem comprometer nossos parâmetros fixos e flexíveis.

O mesmo desafio existiu no aspecto do desenvolvimento de processo, onde a equipe teve que proteger suas decisões em torno da cadeia de suprimentos e manufatura, por exemplo.

RP: Qual foi o seu maior aprendizado sobre LPPD nos últimos sete anos?

AW: Tudo o que fazemos está relacionado ao desenvolvimento das pessoas e a mantê-las seguras. Ser capaz de manter o seu produto estável permite que o seu fluxo de fabricação e de seus fornecedores também seja estável, e isso, por sua vez, significa ter a oportunidade de aperfeiçoar as coisas e tornar o trabalho mais fácil para as pessoas, levando a melhorias no trabalho (e as pessoas sendo responsáveis por essas melhorias). A conexão entre o design do produto e as pessoas que executam o trabalho às vezes se perde - afinal, são vinte etapas ao longo do processo - mas para mim, é disso que se trata. Sem estabilidade, não é possível criar uma cultura empresarial baseada na responsabilidade. Claro, pode levar anos para chegar lá, por isso a perseverança é fundamental.