A INOVAÇÃO À VELOCIDADE DA INFORMAÇÃO

EPINGER, Steven D. Innovation at the speed of information. Harvard Business Review, v. 79, p. 3-11, jan./feb. 2001.

INOVAÇÃO À VELOCIDADE DA INFORMAÇÃO

A troca de informações é a força vital do desenvolvimento de produtos. Quando os planejadores de distribuição e transporte de uma empresa de eletroeletrônicos sabem o que os planejadores de encaixotamento estão fazendo, eles planejam uma distribuição mais adequada para as embalagens. E quando os responsáveis pelo empacotamento sabem o que os projetistas de transporte precisam, eles projetam uma embalagem onde é mais fácil colocar em um melhor meio de distribuição. Esses fluxos de informações permitem a experimentação e a inovação e, por essa razão, muitas empresas estimulam o feedback e a interação nos processos de desenvolvimento de seus produtos. Essa prática é conhecida como engenharia simultânea.

Mas a iteração excessiva pode ter desvantagens. Um contínuo vai e vem do trabalho inevitavelmente consome tempo e recursos. E muitas das iterações podem revelar-se apenas marginalmente benéficas ou mesmo um desperdício. Por exemplo, em uma empresa de telecomunicações que meus colegas e eu aconselhamos, havia até 20 iterações regulares entre as equipes que trabalhavam em duas especificações técnicas principais. O resultado foi que poucas pessoas trabalharam cuidadosamente nas especificações nos estágios iniciais, porque todos sabiam que um extenso retrabalho ocorreria no futuro.

A boa iteração deve ser incentivada e a iteração ruim deve ser eliminada. Para fazer isso, os gerentes precisam de ferramentas representacionais para ajudá-los a identificar e modelar a iteração.

A matriz de estrutura de design difere das ferramentas convencionais de gerenciamento de projetos, pois se concentra em representar fluxos de informação em vez de fluxos de trabalho. Assim, é mais capaz de descrever a dinâmica chave dos processos de inovação.

Existe, no entanto, uma ferramenta que os gerentes podem usar para obter uma representação simples e significativa de tais processos complexos. Essa ferramenta, a Matriz da Estrutura de design (DSM), difere fundamentalmente das ferramentas convencionais de gerenciamento de projetos, pois se concentra em representar os fluxos de informações, em vez dos fluxos de trabalho. Como resultado, é mais capaz de descrever a dinâmica chave dos processos de inovação, como o desenvolvimento de produtos. Além disso, muitas vezes ele pode fornecer representações de processos de desenvolvimento complexos em uma única página. Neste artigo, explicaremos como o DSM funciona e mostramos como um gerente pode usá-lo para tornar os processos de desenvolvimento mais eficientes. Primeiro, vamos explorar por que o desenvolvimento de produtos precisa de uma ferramenta de planejamento fundamentalmente diferente.

Desenvolvimento de produtos é sobre informações, não tarefas

Gráficos PERT, gráficos de Gantt e outras ferramentas de programação comuns foram criadas para ajudar os gerentes a planejar grandes projetos de construção, como construir navios ou fábricas. Embora esses projetos possam ser complexos, envolvendo centenas de tarefas diferentes ou mais, os princípios de planejamento são bastante simples: você decide onde e quando as tarefas devem ser executadas. Não importa quão complicados sejam, todos os projetos de construção podem ser considerados como uma sequência de tarefas distintas, muitas das quais podem ser conduzidas simultaneamente, mas nenhuma delas deve precisar de retrabalho como resultado de informações posteriores.

Imagine que você está construindo uma casa. Algumas tarefas devem ser concluídas em sequência. Você não pode enquadrar as paredes até construir a base. Você não pode colocar no telhado até ter construído as paredes. Tarefas sequenciais, por definição, dependem de informações geradas por tarefas anteriores. Outras tarefas, chamadas tarefas paralelas, podem ser executadas simultaneamente. Você pode instalar janelas, executar fios e colocar encanamentos ao mesmo tempo. Esses três trabalhos precisam de paredes, mas nenhum precisa dos outros dois. Nem tarefas sequenciais nem paralelas precisarão ser retrabalhadas como resultado de tarefas subsequentes. Você não muda a base depois de construir as paredes. Você não se recomece como resultado do envidraçamento da janela.

O desenvolvimento de produtos é muito diferente. Requer inovação, e a inovação requer ciclos complexos de aprendizagem (feedback). Você repete tarefas anteriores à medida que aprende com as subsequentes. Tarefas interdependentes que se beneficiam dessa maneira são conhecidas como tarefas acopladas (interligadas, vinculadas). Se você quiser criar uma base melhor para futuras casas, poderá refazer uma fundação depois de construir as paredes. A informação de tal iteração é precisamente o que ajuda a encontrar a melhoria, e a presença de tarefas acopladas é o que distingue os processos de inovação, como o desenvolvimento de produtos e projetos de construção.

As ferramentas convencionais respondem à pergunta: "Que outras tarefas devem ser concluídas antes de começar esta?" Mas os planejadores de um processo de desenvolvimento de produto precisam de uma ferramenta que responda a uma pergunta muito diferente: "Quais informações eu preciso de outras tarefas antes que eu possa completar esta? ” Essa é a questão que a Matriz da Estrutura de Design aborda.

Desenhando o DSM

A construção de um DSM no processo de desenvolvimento de produto existente da sua empresa é um processo relativamente simples, embora às vezes demorado. O primeiro passo, identificar as tarefas envolvidas, é fácil e está frequentemente disponível como parte da documentação de gerenciamento de projetos. Empresas com um processo de desenvolvimento já conhecem as tarefas necessárias para desenvolver um novo produto. A Ford, por exemplo, executa em grande parte o mesmo processo cada vez que desenvolve um novo motor de carro.

O que leva tempo é identificar corretamente as necessidades de informação das várias tarefas. Você não pode confiar no que os gerentes de sua empresa lhe dizem: eles geralmente não são as pessoas que realizam o trabalho e podem ter interesse em justificar processos existentes ou desatualizados. Quando desenhamos um DSM para um processo de desenvolvimento de produto, vamos para as bases e perguntamos às equipes de desenvolvimento individuais o que elas precisam de outras equipes para realizar seus trabalhos. É importante concentrar-se na entrada em vez de na produção porque descobrimos que gerentes, engenheiros e outros profissionais de desenvolvimento de produtos são mais precisos na identificação do que precisam saber do que na descrição do que os outros precisam saber.