Gestão de Desenvolvimento de Produtos: Uma Referência para a Melhoria do Processo

Citation preview

VI

7

Gestão de Desenvolvimento de Produtos Uma Referência para a Melhoria do Processo

Henrique Rozenfeld Fernando Antônio Forcellini Daniel Capaldo Amaral José Carlos de Toledo Sergio Luis da Silva Dário Henrique Alliprandini Régis Kovacs Scalice

ISBn 978-85-02-05446-2 85-02-05446-5 Rua Henrique Schaumann, 270 – CEP: 05413-010 Pinheiros – TEL.: PABX (0XX11) 3613-3000 Fax: (11) 3611-3308 – Televendas: (0XX11) 3613-3344 Fax Vendas: (0XX11) 3268-3268 – São Paulo – SP Endereço Internet: http://www.saraivauni.com.br

CIP-BRASIL. CAtALogAção nA Fonte SIndICAto nACIonAL doS edItoReS de LIvRoS, RJ. 05-2250. CDD 658.575

Filiais AMAZONAS/RONDÔNIA/RORAIMA/ACRE Rua Costa Azevedo, 56 – Centro Fone/Fax: (0XX92) 3633-4227 / 3633-4782 – Manaus BAHIA/SERGIPE Rua Agripino Dórea, 23 – Brotas Fone: (0XX71) 3381-5854 / 3381-5895 / 3381-0959 – Salvador BAURU/SÃO PAULO (sala dos professores) Rua Monsenhor Claro, 2-55/2-57 – Centro Fone: (0XX14) 3234-5643 – 3234-7401 – Bauru

CDU 658.512 Gestão de desenvolvimento de produtos / Daniel Capaldo Amaral... [et al.]. - São Paulo : Saraiva, 2006 ISBN 978-85-02-05446-2 85-02-05446-5 1. Produtos novos - Administração. 2. Administração de produtos. 3.Administração de projetos. I. Amaral, Daniel Capaldo. 05-2250

CDD-658.575 CDU-658.512

CAMPINAS/SÃO PAULO (sala dos professores) Rua Camargo Pimentel, 660 – Jd. Guanabara Fone: (0XX19) 3243-8004 / 3243-8259 – Campinas CEARÁ/PIAUÍ/MARANHÃO Av. Filomeno Gomes, 670 – Jacarecanga Fone: (0XX85) 3238-2323 / 3238-1331 – Fortaleza DISTRITO FEDERAL SIA/SUL Trecho 2, Lote 850 – Setor de Indústria e Abastecimento Fone: (0XX61) 3344-2920 / 3344-2951 / 3344-1709 – Brasília

Copyright©Henrique Rozenfeld, Fernando Antônio Forcellini, Daniel Capaldo Amaral, José Carlos de Toledo, Sergio Luis da Silva, Dário Henrique Alliprandini, Régis Kovacs Scalice 2006 Editora Saraiva Todos os direitos reservados.

GOIÁS/TOCANTINS Av. Independência, 5330 – Setor Aeroporto Fone: (0XX62) 3225-2882 / 3212-2806 / 3224-3016 – Goiânia MATO GROSSO DO SUL/MATO GROSSO Rua 14 de Julho, 3148 – Centro Fone: (0XX67) 3382-3682 / 3382-0112 – Campo Grande MINAS GERAIS Rua Além Paraíba, 449 – Lagoinha Fone: (0XX31) 3429-8300 – Belo Horizonte PARÁ/AMAPÁ Travessa Apinagés, 186 – Batista Campos Fone: (0XX91) 3222-9034 / 3224-9038 / 3241-0499 – Belém PARANÁ/SANTA CATARINA Rua Conselheiro Laurindo, 2895 – Prado Velho Fone: (0XX41) 3332-4894 – Curitiba PERNAMBUCO/ ALAGOAS/ PARAÍBA/ R. G. DO NORTE Rua Corredor do Bispo, 185 – Boa Vista Fone: (0XX81) 3421-4246 / 3421-4510 – Recife

direção editorial Coordenação editorial

Produção editorial

Flávia Alves Bravin Ana Paula Matos Gisele Folha Mós Juliana Rodrigues de Queiroz Rita de Cássia da Silva Daniela Nogueira Secondo Rosana Peroni Fazolari

Marketing editorial

Nathalia Setrini

Suporte editorial

Renata Moraes

Arte e produção

ERJ Composição Editorial

Capa

ERJ Composição Editorial

Produção gráfica Impressão Acabamento Atualização da 5a tiragem

Liliane Cristina Gomes Nononno Nonono ERJ Composição Editorial

RIBEIRÃO PRETO/SÃO PAULO Av. Francisco Junqueira, 1255 – Centro Fone: (0XX16) 3610-5843 / 3610-8284 – Ribeirão Preto RIO DE JANEIRO/ESPÍRITO SANTO Rua Visconde de Santa Isabel, 113 a 119 – Vila Isabel Fone: (0XX21) 2577-9494 / 2577-8867 / 2577-9565 – Rio de Janeiro RIO GRANDE DO SUL Av. A. J. Renner, 231 – Farrapos Fone: (0XX51) 3371- 4001 / 3371-1467 / 3371-1567 – Porto Alegre SÃO JOSÉ DO RIO PRETO/SÃO PAULO (sala dos professores) Av. Brig. Faria Lima, 6363 – Rio Preto Shopping Center – V. São José Fone: (0XX17) 3227-3819 / 3227-0982 / 3227-5249 – São José do Rio Preto SÃO JOSÉ DOS CAMPOS/SÃO PAULO (sala dos professores) Rua Santa Luzia, 106 – Jd. Santa Madalena Fone: (0XX12) 3921-0732 – São José dos Campos

Contato com o editorial [email protected]

1ª Edição 1ª tiragem: 2006 2ª tiragem: 2006 3ª tiragem: 2008 4ª tiragem: 2009 5ª tiragem: 2010

SÃO PAULO Av. Antártica, 92 – Barra Funda Fone: PABX (0XX11) 3613-3666 – São Paulo

353.617.001.005

Nenhuma parte desta publicação poderá ser reproduzida por qualquer meio ou forma sem a prévia autorização da Editora Saraiva. A violação dos direitos autorais é crime estabelecido na lei nº 9.610/98 e punido pelo artigo 184 do Código Penal.

GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

Na Introdução, narramos como este livro foi produzido, demonstrando quanto este trabalho é fruto da união de esforços e experiências de vários pesquisadores, profissionais de empresa e estudantes, que dedicaram parte preciosa de suas vidas para compartilhar conosco suas experiências e conhecimentos em desenvolvimento de produtos. Se contássemos todas as pessoas que, durante quase uma década, nos ajudaram a entender um pouco mais de desenvolvimento de produtos, certamente chegaríamos a centenas. Sem elas, não teríamos experiência suficiente para realizar esta empreitada, de certa maneira pretensiosa, de condensar as melhores práticas em desenvolvimento de produtos e colocá-las de forma organizada em um único livro. Gostaríamos de registrar os nossos sinceros agradecimentos a todos, sabendo que seria impossível nomeá-los neste espaço, tanto pela quantidade como pela certeza de que erros graves de esquecimento seriam cometidos. Ficam os nossos agradecimentos aos profissionais que abriram a porta de suas organizações, tiveram a paciência e a compreensão de compartilhar os problemas, experiências e os modelos de suas empresas, e, finalmente, criticaram as primeiras versões do modelo de referência: Marco Diniz, da Eaton; Eduardo Vaz, da Xerox; Wilson Moura e João Nascimento, da Multibras; e Renato Mastrobuono, da VW Caminhões e Ônibus. A contribuição e o incentivo do professor Majdi Najm, do E-business center, da Universidade de Missouri, também foram decisivos para a conclusão deste livro. Outra contribuição decisiva foi obtida dos pesquisadores e profissionais que participaram conosco do projeto Programa de Cooperação Acadêmica (PROCAD) — financiado pela Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (Capes) — e da PDPNet, nossa Comunidade de Prática na Internet sobre o tema deste livro. Esse projeto e a criação da comunidade foram fundamentais tanto para aproximar os autores como para o compartilhamento de valiosas informações e experiências. Agradecemos aos professores que participaram da fase inicial do projeto PROCAD: Nelson Back, Acires Dias, André Ogliari e Roberto Martins. Gostaríamos de destacar os nomes dos pesquisadores e profissionais que participaram com intensidade na criação de nossa comunidade virtual e nos debates e compartilhamento de conhecimentos: Elaine Mosconi, Sanderson Barbalho, Cristiano Vasconcellos Ferreira, Antonio Francisco Savi, Vinicius Kaster Marini, Edenilza Valéria da Silva, Sandro Giovanni Valeri, Leonardo Nabaes Romano, Andréa Cristina dos Santos, Antonio Carlos Peixoto Bitencourt, Diego Jorge Balthazar Neves, Luis Fernando Soares Zuin, Franco Antonio Menegatti, Karina Kühl de Lima e Leonardo Santiago. Gostaríamos, também, de agradecer a todos os nossos alunos de disciplinas de pós-graduação, graduação e, principalmente, nossos orientados que nos ajudaram a construir este conhecimento com suas dúvidas, sugestões, dissertações de mestrado e de doutorado, cujos resultados principais foram incorporados neste livro: Cristiano Bevitori M. Oliveira, Lucas Cley da Horta, Marcelo Gitirana Gomes Ferreira, Vander Guerrero, Fernanda Menezes Ferrari, Rogerio Omokawa, Glauco Henrique Souza Mendes, José Luiz Moreira de Carvalho, Marcelo Ruy e Mariana Maciel da Silva. Neste contexto, não poderíamos deixar de agradecer às instituições que fomentaram essas pesquisas: Fundação de Amparo à Pesquisa do Estado de São Paulo (Fapesp), Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq), Ministério de Ciências e Tecnologia (MCT) e Capes. Não podemos nos esquecer, ainda, de todo o pessoal de apoio, que sempre esteve presente no gerenciamento de nossa infra-estrutura para a realização desta obra: Fernando Walker Lima da Silva, Cristiane de Cássia Cornetta Bernardes e Francis Ribeiro da Silva.

vi

GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

O apoio do Instituto Fábrica do Milênio (IFM) também foi essencial para manter a nossa rede de cooperação e realização de projetos conjuntos, assim como de fornecer infra-estrutura para a realização de reuniões virtuais e de apoio financeiro para os diversos encontros. Finalmente, temos que agradecer aos nossos familiares, que foram privados de muitos momentos de nossa companhia, pois dedicamos grande parte de nosso tempo livre à confecção deste livro.

Os autores

GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

Henrique Rozenfeld Formou-se engenheiro mecânico, em 1980, e mestre, em 1983, pela USP. Doutorado em Sistematização da Produção no WZL da Universidade Técnica de Aachen, Alemanha, em 1988. Livre-docente, em 1992, na área de Planejamento do Processo e professor titular na área de Integração da Manufatura, em 1995. É docente do Departamento de Engenharia da Escola de Engenharia de São Carlos (EESC-USP), desde 1982, coordenador do Núcleo de Manufatura Avançada (NUMA) e do Grupo de Engenharia Integrada do NUMA. Além de vice-coordenador do Instituto Fábrica do Milênio. Possui mais de 300 artigos publicados nacionais e internacionais. Desenvolveu sistemas de planejamento de processo, realizou várias consultorias na área de desenvolvimento de produtos e de sistemas integrados de gestão. Já formou mais de 40 mestres e doutores. Foi professor convidado no ano de 2003 na Universidade de Missouri na área de Gestão do Ciclo de Vida de Produtos. Coordena projetos nacionais e cooperados com instituições européias na área de Engenharia Colaborativa, e outros de modelagem de processos de negócio.

Fernando Antônio Forcellini Formou-se engenheiro mecânico, em 1985, mestre, em 1989 e doutor, em 1994 pela Universidade Federal de Santa Catarina. Docente do Departamento de Engenharia Mecânica da UFSC desde 1994. Já formou mais de 30 mestres e doutores, possui mais de 150 artigos publicados em eventos nacionais e internacionais e periódicos. Participou e coordenou projetos cooperativos com diversas instituições nacionais e internacionais. Coordenador do NeDIP – Núcleo de Desenvolvimento Integrado de Produtos – até 2004. Atualmente, atua como pesquisador do Gepp – Grupo de Engenharia do Produto e Processo – e como professor dos Programas de Pós-Graduação em Engenharia Mecânica e de Engenharia de Produção da Universidade Federal de Santa Catarina.

Daniel Capaldo Amaral Doutor em Engenharia Mecânica pela Escola de Engenharia de São Carlos (EESC-USP) e mestre e engenheiro de produção formado pela Universidade Federal de São Carlos (UFSCar). Atualmente, é professor do Departamento de Engenharia de Produção da EESC-USP, sendo responsável pelas disciplinas de Projeto do Produto e Gerenciamento de Projetos. Realiza pesquisas na área de desenvolvimento e aplicação de sistemas para gestão do processo de desenvolvimento de produto. Desenvolveu protótipos de sistemas computacionais para engenharia colaborativa, estudos de implantações de sistemas para gestão do PDP e propostas para o ensino de desenvolvimento de produto.

viii

GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

José Carlos de Toledo Engenheiro de produção, mestre em Engenharia de Produção formado pela Coppe/UFRJ, doutor em Engenharia de Produção pela Escola Politécnica da Universidade de São Paulo. É coordenador e pesquisador do Gepeq – Grupo de Estudos e Pesquisa em Qualidade – e professor do Programa de Pós-Graduação em Engenharia de Produção da Universidade Federal de São Carlos. Cursou especialização em TQM – Total Quality Management – na AOTS – Association of Overseas Technical Scholarhip –, no Japão. Desenvolve atividades de ensino, pesquisa e de consultoria nas áreas de sistemas e ferramentas para gestão do desenvolvimento de produto, sistemas e ferramentas para gestão e melhoria da qualidade, métodos para coordenação da qualidade em cadeias de produção e sistemas da qualidade em unidades de produção agropecuária.

Sergio Luis da Silva Formou-se engenheiro de materiais e mestre em Engenharia de Produção pela UFSCar (Universidade Federal de São Carlos). Doutor em Engenharia Mecânica pela Escola de Engenharia de São Carlos – EESC/USP. Na UFSCar, atua desde 1995 como professor efetivo na área de Informação Tecnológica e Empresarial do Departamento de Ciências da Informação, e, a partir de 2004, como docente credenciado no Programa de Pós-Graduação em Engenharia de Produção. Colaborou na implantação do NIT/Materiais (Núcleo de Informação Tecnológica) do Departamento de Engenharia de Materiais dessa Universidade. Atua como pesquisador e consultor em temas relacionados ao Desenvolvimento de Produtos e à Gestão do Conhecimento, no Gepeq – Grupo de Estudos e Pesquisa em Qualidade –, do Departamento de Engenharia de Produção da UFSCar, e em colaboração com o Grupo de Engenharia Integrada – EI – no NUMA – Núcleo de Manufatura Avançada na EESC/USP. Nesses mesmos temas, publicou mais de 50 artigos em congressos nacionais, internacionais e periódicos científicos.

Dário Henrique Alliprandini Professor do Departamento de Engenharia de Produção da Universidade Federal de São Carlos (UFSCar) desde 1992. Formou-se engenheiro mecânico, em 1982, mestre, em 1990, e doutor, em 1996, pela Escola de Engenharia de São Carlos da USP. Atuou como engenheiro de fabricação, engenheiro de produto e supervisor de produção em empresas manufatureiras entre 1983 e 1991. Realizou estágio de pesquisa no Georgia Institute of Technology – School of Industrial Engineering (2000/2001). Atua em ensino e pesquisa sobre melhoria contínua, aprendizagem organizacional e sistemas de gestão em ambientes de manufatura e processo de desenvolvimento de produto.

Régis Kovacs Scalice Engenheiro mecânico formado em 1997 pela Universidade Estadual Paulista (FEG-Unesp) e doutor em Engenharia Mecânica, em 2003, pela Universidade Federal de Santa Catarina (UFSC), tendo trabalhado com Metodologia de Projeto e com o Desenvolvimento de Produtos Modulares. Coordena o Curso de Graduação em Engenharia Mecânica da Sociedade Educacional de Santa Catarina (Sociesc), desde 2005, e atua no grupo de pesquisa da instituição. Realizou consultorias na área de Desenvolvimento de Produtos e participou de projetos nacionais cooperados na área de Desenvolvimento de Produtos e com instituições européias na área de Engenharia Colaborativa.

Prefácio GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

O maior legado da onda de Reengenharia de Processos, iniciada pelo trabalho de Michael Hammer e James Champy no início dos anos 1990, talvez seja a disseminação do conceito de Processos de Negócio e da necessidade de seu adequado gerenciamento. Atualmente, a maioria das empresas líderes em seus mercados conhece, gerencia e aprimora continuamente seus processos-chave de negócio. Apesar de isoladamente isso não garantir o sucesso, esses fatores são fundamentais para a competitividade. O Processo de Desenvolvimento de Produtos se constitui num dos processos-chave de qualquer empresa que se proponha a competir por meio da criação de produtos próprios e da busca de liderança tecnológica. A antiga fórmula de sucesso — baseada em fazer um produto, produzi-lo a preços baixos e vendê-lo em grande quantidade — não se aplica mais ao ambiente atual dos negócios. É preciso identificar a premissa de criação de valor que garantirá, no mercado, o êxito com os clientes e realizá-la em tempo adequado para aproveitar ao máximo a oportunidade que se apresenta. O sucesso será conquistado pelas empresas que sabem produzir valor de mercado — aquelas que podem entregar o que as pessoas querem comprar. Assim sendo, o Processo de Desenvolvimento de Produtos deve ser abrangente, iniciando-se no entendimento das necessidades de mercado e terminando no final do ciclo de vida do produto. O modelo geral, proposto neste livro, atende a essa necessidade, constituindo-se numa excelente referência para aqueles que desejam aprimorar seu processo atual, necessitam implementar tal processo em sua empresa ou apenas precisam se iniciar no assunto. Os autores, professores em renomadas universidades brasileiras, combinam uma grande experiência em ensino, pesquisa e consultoria em áreas como: sistemas e ferramentas para gestão do desenvolvimento de produto e melhoria da qualidade, engenharia colaborativa, modelagem de processos de negócio, gestão do conhecimento e sistemas integrados de gestão. Desde o início da década de 1990, eles têm realizado pesquisa e análise profundas dos conceitos mais avançados na implementação e gerenciamento do Processo de Desenvolvimento de Produtos. Ao mesmo tempo, por meio da interação com instituições de ensino e pesquisa no exterior e trabalhos de consultoria em empresas de porte no Brasil, esses conceitos foram aplicados em casos reais, e com isso puderam ser refinados e tornaram-se melhores práticas, documentadas nesse livro. O resultado dessa dedicação e disposição em combinar a pesquisa acadêmica com experiência prática pode ser visto no livro. O modelo de referência foi desenvolvido com uma visão holística, incluindo fases anteriores e posteriores à parte mais visível do desenvolvimento de produto e processo, que são as atividades de engenharia própriamente ditas, além de abordar os processos de apoio relevantes. A importância dessa ligação entre o Processo de Desenvolvimento de Produtos com os processos de Pré-Desenvolvimento, Pós-Desenvolvimento e Processos de Apoio não é óbvia, o que leva muitas empresas a tratá-los separadamente, resultando desse procedimento projetos mal-sucedidos de desenvolvimento de produto. As melhores práticas no gerenciamento do Processo de Desenvolvimento de Produtos, encontradas na literatura e nas empresas de ponta, também estão presentes no modelo. A avaliação dos resultados ao término de cada fase inclui não somente a análise dos resultados esperados (deliverables), como ainda o registro de lições aprendidas, gestão do conhecimento gerado e análise dos indicadores de desempenho selecionados. O ciclo de aperfeiçoamento do Processo de Desenvolvimento de Produtos também está incluído no modelo, seguindo critérios reconhecidos de excelência em negócios. Diferentes ferramentas de gerenciamento de portfólio de projetos são levantadas, e a sua relação com o Planejamento Estratégico da empresa é abordada, sendo discutidas inclusive alternativas de estrutura organizacional para o desenvolvimento de produtos e ferramentas de Tecnologia de Informação, como sistemas ERP.

x

GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

Outra contribuição digna de nota é a apresentação e a análise de métodos e ferramentas aplicáveis a cada uma das fases do projeto, que estão nos quadros de cada capítulo. Essa é uma das áreas que as empresas mais tem dificuldade em desenvolver, pois requer disponibilidade de pessoal para buscar as ferramentas, estudá-las e definir a aplicabilidade em cada caso. Para orientar a aplicação dos conceitos em uma empresa, diferentes níveis de maturidade do Processo de Desenvolvimento de Produtos são definidos e analisados. O ritmo alucinante de trabalho nos dias atuais faz com que as empresas tenham dificuldades em manterem-se atualizadas; nesse contexto, as contribuições aqui apresentadas constituem patrimônio valioso. Durante o tempo em que trabalhei com alguns dos autores, desenvolvendo e implementando o primeiro processo estruturado para o desenvolvimento de produtos de minha empresa na metade da década de 1990, encontramos muita dificuldade em identificar o processo em si, compreender, selecionar e aplicar os inúmeros métodos existentes sem a ajuda de um guia como este livro. Fica claro para mim a utilidade que este livro pode ter, pois onde mais poderíamos encontrar, numa única referência, a maioria dos elementos importantes na área, acompanhados de análises detalhadas e com abordagem completa e rigorosa dos diversos temas? Ou a discussão dos diferentes conceitos de modelagem de processos no Capítulo 2 ou, ainda, a análise detalhada de outras abordagens para a gestão do Processo de Desenvolvimento de Produtos encontrados no Capítulo 16? Isto deve servir de motivação para que os profissionais com interesse no assunto leiam e utilizem os conceitos aqui apresentados. Posso afirmar que o conteúdo do livro lhes será muito útil e sua aplicação ajudará no avanço das atividades de desenvolvimento de produtos, com conseqüente aumento de produtividade, diminuição do tempo de desenvolvimento e melhoria na qualidade dos resultados.

Marco Antonio N. Diniz Diretor de Engenharia Divisão de Transmissões Leves e Médias Truck Components Group – Eaton Corporation Kalamazoo, Michigan, USA

Apresentação

xi

Apresentação GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

A.1

Objetivos do livro

O objetivo deste livro é apresentar de forma didática e completa um modelo estruturado, como se fosse um guia de orientação, para a estruturação e gestão do processo de desenvolvimento de produtos. O modelo possui algumas particularidades relacionadas com o desenvolvimento de bens duráveis e de equipamentos. Porém, o modelo geral, com algumas adaptações, pode ser adequado ao desenvolvimento de qualquer tipo de produto. Enfatiza-se a visão do desenvolvimento como um processo de negócio amplo, que abrange todo o ciclo de vida do produto. Esse processo compreende a integração com o planejamento estratégico da empresa, quando a carteira de produtos e projetos de desenvolvimento é definida; as fases de engenharia, lançamento e acompanhamento do produto durante a sua comercialização e operação; até a sua retirada do mercado e as atividades de reciclagem, reutilização ou descarte. A apresentação do modelo é desdobrada em macrofases, fases e atividades necessárias para o desenvolvimento de um produto. Para a compreensão do modelo, discutem-se os condicionantes do processo de desenvolvimento de produtos, em termos do ambiente competitivo e das estratégias e capacitações da empresa. São apresentados, também, os conceitos, ferramentas e fluxos de informações que podem ser aplicados nas diversas atividades para compreensão e tradução dos requisitos dos clientes e para o projeto e melhoria das especificações do produto e de seu processo de produção. Assim, as atividades são detalhadas em termos das informações de entrada necessárias, do conteúdo das tarefas a serem executadas, das informações de saída, das ferramentas de suporte e dos mecanismos de controle.

A.2

Público-alvo

O livro se destina a um público constituído por alunos, professores e profissionais de empresas que estejam em busca da compreensão de uma visão ampla e, ao mesmo tempo, detalhada das atividades do processo de desenvolvimento de produtos e de sua gestão estratégica e operacional. Os alunos de graduação em Engenharia encontrarão no livro um texto didático e estruturado que os guiará na compreensão das atividades e ferramentas que são pertinentes a esse processo. Os graduandos de Administração encontrarão uma visão geral do processo e dos principais elementos e condicionantes para gerenciamento dele. Os alunos de pós-graduação encontrarão, além da visão geral do processo, uma abordagem devidamente fundamentada e com indicações bibliográficas para a busca de uma compreensão mais detalhada de elementos, conceitos e ferramentas pertinentes ao processo. Os professores, de graduação e de pós-graduação, de diversas áreas de conhecimento, terão a sua disposição um livro que poderá ser utilizado como texto básico a ser seguido ao longo de toda uma disciplina sobre Desenvolvimento de Produtos, ou como relevante leitura complementar para disciplinas que abordam temas específicos aplicados no contexto ou no escopo do desenvolvimento de produtos, tais como Marketing, Design, Manufatura e Projeto de Processos. Os profissionais de empresas encontrarão no livro conhecimentos que lhes permitirão: n n

obter uma visão ampla do Processo de Desenvolvimento de Produtos (PDP); compreender, em função do tipo de produto, de mercado e de tecnologia da empresa em que atua, qual o escopo mais adequado para o desenvolvimento de produtos;

xii

GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

n

n

obter elementos que os auxiliarão na identificação e análise de como se encontram a estrutura e o gerenciamento do PDP da empresa; e conhecer um modelo de referência como base de apoio para planejar ou melhorar a estrutura do PDP da empresa; além de elementos para planejar a transição da situação atual para uma situação desejada com base no modelo aqui apresentado.

A leitura do livro pode ser útil a profissionais que atuam no desenvolvimento de produtos, bem como nos processos a ele relacionados, sejam em empresas de manufatura ou como consultores na área ou como desenvolvedores de sistemas de informação ou de integração do todo ou de partes deste processo.

A.3

Histórico do livro

O modelo que será apresentado contém os conceitos e as melhores práticas em Desenvolvimento de Produtos (DP), uma vez que incorpora experiências e conhecimentos em desenvolvimento de produtos acumulados pelos autores deste livro desde o início da década de 1990 — sejam em atividades acadêmicas e de ensino como, também, em atividades práticas em empresas. O modelo sistematiza conhecimentos adquiridos por meio da atuação em atividades de consultoria, orientações de dissertações e teses, coordenação de projetos de desenvolvimento de produtos, realização de pesquisas de campo (entre elas, estudos de casos profundos em empresas), execução de diagnósticos, realização de pesquisas-ação, estudo e comparação de modelos de referência de várias empresas, e análises mais amplas e abrangentes do PDP em empresas dos setores tratados no livro. Este modelo é também resultado de uma ação conjunta de grupos de pesquisa de três universidades brasileiras, com forte atuação na área de Desenvolvimento de Produtos. Essa ação, financiada pela Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (Capes), foi iniciada em 2001 como parte do Programa Nacional de Cooperação Acadêmica (PROCAD), que objetivou promover a integração e o intercâmbio de conhecimentos entre grupos de pesquisa nacionais, no âmbito da pós-graduação. No projeto de pesquisa em questão, coordenado pelo professor Henrique Rozenfeld, participaram os seguintes centros de pesquisa: n

n

n

Grupo de Engenharia Integrada do Núcleo de Manufatura Integrada (NUMA) do departamento de Engenharia da Escola de Engenharia de São Carlos, Universidade de São Paulo; Grupo de Estudos e Pesquisa em Qualidade (Gepeq), do Departamento de Engenharia de Produção da Universidade Federal de São Carlos (UFSCar). Inicialmente, pelo Departamento de Engenharia Mecânica da Universidade Federal de Santa Catarina, o Núcleo de Desenvolvimento Integrado de Produtos (NeDIP) e, posteriormente, o Grupo de Engenharia do Produto e Processo (Gepp).

Nesse projeto foram feitas várias ações de integração entre esses grupos, incluindo encontros entre os pesquisadores para troca de experiências e a criação de uma comunidade de prática em Desenvolvimento de Produtos, denominada PDPNet (http://www.pdp.org.br). Essa comunidade contou ainda com a participação de profissionais de empresas brasileiras com vasta experiência na Gestão do Desenvolvimento de Produtos. Um dos principais resultados dessa verdadeira coalizão que se formou em torno do assunto foi a elaboração de um modelo de referência com o objetivo de ser utilizado nas atividades didáticas e acadêmicas dos envolvidos na comunidade. A missão desse grande modelo de referência, de caráter mais geral, foi se tornar “referência” para a derivação de outros modelos, adequados a um setor ou tipo específico de produto. Paralelo a esse exaustivo trabalho de desenvolvimento do modelo de referência principal, os grupos de pesquisa desenvolveram modelos de referência para aplicações específicas. Foram criados e testados modelos para a indústria de máquinas agrícolas e alimentos, e outros estão em andamento — como é o caso de um modelo voltado para empresas de produtos mecatrônicos. Parte desses projetos desenvolvidos com o uso do modelo foi realizada com o apoio da rede de pesquisa do Instituto Fábrica do Milênio, um dos Institutos do Milênio criados pelo Ministério da Ciência e Tecnologia (http://www.ifm.org.br).

Apresentação

xiii

O modelo apresentado neste livro é uma evolução do modelo genérico desenvolvido pela comunidade PDPNet, o qual foi aprimorado e adaptado pelos autores com o objetivo de ser disseminado para o grande público: pesquisadores, profissionais e estudantes interessados nessa instigante e desafiadora atividade de criar soluções para melhorar a vida das pessoas e a competitividade da indústria nacional. A escrita do livro foi iniciada após a conclusão da primeira versão validada do modelo, no primeiro semestre de 2004. Portanto, caro leitor, o livro é resultado da união entre a experiência dos autores e a experiência de dezenas de pesquisadores e especialistas da área de Desenvolvimento de Produto, acumulada em encontros e discussões realizadas durante quase três anos de trabalho. Todo esse esforço, então, é para disseminar as técnicas de Desenvolvimento de Produto nas empresas nacionais e auxiliá-las a melhorar a eficiência nessa atividade.

A.4

Estrutura do livro O livro está estruturado em três partes e 16 capítulos. A Figura A.1 ilustra a estrutura das partes do livro.

Figura A.1

Estrutura do livro.

Parte 1: A primeira parte é dividida em dois capítulos. O Capítulo 1 apresenta os conceitos sobre Gestão do Processo de Desenvolvimento de Produtos, discutindo a importância do PDP e suas características; a realidade do Brasil nessa área; as principais abordagens e arranjos organizacionais para o PDP; e quais os fatores que afetam o desempenho desse processo. O Capítulo 2 mostra uma visão geral do modelo, apresentando as suas macrofases e os principais conceitos que o modelo contém. Assim, obtém-se a base conceitual para o seu entendimento. n Capítulo 1: Gestão do Processo de Desenvolvimento de Produtos n Capítulo 2: O Modelo Unificado do PDP.

Parte 2: Na segunda parte, o Modelo de Referência para o PDP é apresentado em 11 capítulos. O Capítulo 3 descreve as atividades gerais que se repetem em cada uma das fases. Cada uma das nove fases do modelo é descrita em detalhes nos capítulos subseqüentes, quando suas atividades e tarefas são mostradas, assim como os conceitos, métodos e ferramentas principais que podem ser utilizadas para o seu desenvolvimento. n Capítulo 3: Atividades Genéricas do Modelo n Capítulo 4: Planejamento Estratégico de Produtos n Capítulo 5: Planejamento do Projeto n Capítulo 6: Projeto Informacional n Capítulo 7: Projeto Conceitual

xiv

GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

Capítulo 8: Projeto Detalhado n Capítulo 9: Preparação da Produção do Produto n Capítulo 10: Lançamento do Produto n Capítulo 11: Acompanhar Produto e Processo n Capítulo 12: Descontinuar o Produto n Capítulo 13: Processos de Apoio Este último capítulo dessa parte, descreve os processos de apoio ao PDP: o processo de gerenciamento de mudanças de engenharia e o processo de melhoria incremental do PDP. n

Parte 3: A terceira parte discute a Aplicação do Modelo, mostrando quais os níveis de maturidade que o PDP de uma empresa pode possuir (Capítulo 14) e como utilizar o modelo proposto para aumentar a eficácia do PDP (Capítulo 15). No Capítulo 16, discute-se como adaptar esse modelo para outros tipos de empresa, diferentes das empresas de bens de consumo duráveis e de equipamentos, e finalmente qual a relação entre o modelo apresentado e as abordagens de gestão do PDP, mostradas no Capítulo 1. n Capítulo 14: Níveis de Maturidade do PDP n Capítulo 15: Método de Transformação do PDP n Capítulo 16: O Modelo, Suas Alternativas de Aplicação e Sua Relação com Outras Abordagens para Gestão do PDP Ao longo dos capítulos, há quadros, que detalham conceitos e ferramentas citados no texto. No final de cada um deles, são apresentadas questões para reflexão, atividades para reforço dos conhecimentos apresentados e são listadas referências bibliográficas complementares. No final do livro, há um glossário com a definição dos principais conceitos e termos usuais na área, além daqueles citados no modelo. Outros apêndices existentes servem para facilitar a aplicação prática do modelo de referência.

A.5

Como ler e empregar este livro

De modo geral, recomenda-se que o livro seja lido de forma completa e na seqüência em que os capítulos são apresentados. Entretanto, dependendo do curso e da disciplina que você esteja fazendo, ou do seu interesse individual e em função da sua área de atuação e experiência profissional que já possui, você poderá ler apenas alguns capítulos mais apropriados, conforme será sugerido a seguir. Se o interesse é ter apenas uma visão geral do que é PDP e do modelo de referência, você poderá ler apenas os capítulos 1 e 2, que trazem uma visão geral e um resumo do modelo completo. Na Figura A.2 são apresentadas as formas alternativas de ler e empregar este livro, de acordo com cada tipo de leitor. Este livro é voltado ao aluno interessado em GDP que esteja cursando disciAluno interessado plinas com esse conteúdo ou realizando projetos durante o seu curso e que precisa em Gestão do ter uma boa noção de como desenvolver um produto, ou, então, ao aluno que preDesenvolvimento de tende trabalhar, futuramente, nessa área. O aluno pode ser de várias áreas: AdminisProdutos (GDP) tração de Empresas, Engenharia e Economia. Sendo um livro com finalidade didática, o ideal é que você o estude de forma completa e na seqüência apresentada, uma vez que há um encadeamento de conceitos e de idéias, além, obviamente, de notações e terminologias adotadas, para uma melhor compreensão do modelo apresentado. Ou seja, existe uma relação de dependência entre os capítulos do livro.

Apresentação

Figura A.2

xv

Alternativas de leitura do livro conforme o tipo de leitor.

Leia sempre e atentamente os capítulos 1 e 2, antes dos demais, pois eles apresentam o referencial teórico básico do livro, bem como uma visão geral do modelo para PDP, que será detalhado nos capítulos seguintes. Em uma primeira leitura, você não precisa se preocupar em ler os quadros, uma vez que o texto descreve a seqüência do processo de desenvolvimento de produtos. Os quadros trazem explicações adicionais sobre os principais conceitos, ou uma introdução sobre determinados temas, ferramentas e métodos. Nesses casos, você precisará consultar as informações adicionais citadas ao final de cada quadro para poder se aprofundar nos assuntos tratados. Repare que os assuntos de alguns quadros são bem abrangentes e fazem parte de outras disciplinas do seu curso. Este livro é um guia que indicará leituras adicionais necessárias para você dominar a Gestão do Desenvolvimento de Produtos (GDP). Entretanto, aqui, você não vai encontrar especificidades relacionadas com as áreas tecnológicas. Este livro trata de gestão e não de conhecimentos tecnológicos especiais. Ele complementa o aprendizado dessas áreas tecnológicas, pois, normalmente, essa visão geral e ampla não é fornecida nos cursos regulares de Engenharia. As questões para reflexão e as atividades sugeridas no final de cada capítulo devem ser priorizadas após a sua leitura, já que reforçam a compreensão dos conceitos, a aprendizagem e a transposição para a sua realidade de interesse. Se não conseguir respondê-las, retorne à leitura do capítulo, reflita mais um pouco e dedique-se às atividades sugeridas. Se necessário, busque leituras complementares sugeridas. Um aluno de outra disciplina deve, primeiro, ler o Capítulo 2 para obter uma Aluno cursando outras visão geral do escopo e dos conceitos principais do PDP. Assim, ele consegue locadisciplinas lizar a sua disciplina no contexto geral do desenvolvimento de produtos. Em seguida, você precisa analisar quais fases e/ou atividades estão relacionadas com a sua disciplina em particular. Dedique-se a estudar em profundidade os capítulos correspondentes a essas fases e atividades. Identifique os quadros relacionados e estude-os também, em um segundo momento. Estude as bibliografias adicionais relativas aos quadros identificados.

xvi

GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

Planeje realizar uma disciplina de GDP para aumentar a sua visão sobre o PDP, adquirindo, assim, um escopo maior de oportunidades futuras na sua vida profissional. Para isso, você vai ter de seguir os passos propostos para os estudantes interessados em GDP. Se você coordenar um curso não diretamente relacionado com a área de EngeProfessor coordenador nharia, você deve ler as Partes 1 e 3 do livro para identificar o escopo do PDP e avade curso liar o conteúdo que você precisaria ter no curso que coordena. Se você for um coordenador de curso de Engenharia, deve, ainda, levantar os temas dos quadros, lendo-os com cuidado. Verifique com os outros professores da sua equipe quem estudaria qual capítulo e quadro para mapear as competências necessárias para definição ou atualização das disciplinas do curso. Em grupo, vocês poderiam consultar as informações adicionais para buscar um conhecimento mais detalhado sobre esses temas. E, ainda, identificariam os conteúdos necessários ao ensino de GDP, ou mesmo à inserção dos conceitos de PDP nas disciplinas atuais, ou em novas disciplinas a serem oferecidas. Você, professor de GDP, deve adotar este livro como livro-texto de sua disciProfessor de GDP plina. Baixe do site da editora as apresentações das aulas e o modelo de referência no formato de guia. Você pode completar o conteúdo das apresentações sobre os assuntos dos quadros que considerar mais relevantes. Tente mapear, com base nos quadros, as outras disciplinas existentes na sua universidade relacionadas com PDP. Assim, é possível identificar algumas lacunas e levar essas informações à coordenação do seu curso. Você pode passar aos alunos o modelo de referência (como um guia) para eles o utilizarem como base para os passos dos projetos que poderão realizar durante o curso. Um professor de outras disciplinas deve ler o Capítulo 2 para obter uma visão Professor de outras integrada do PDP. Identifique, no restante do livro, qual fase e/ou atividade está redisciplinas lacionada com a sua disciplina. Leia, então, os capítulos e quadros correspondentes. Localize a sua disciplina no contexto do modelo para motivar os alunos. Um executivo de alto nível da empresa, cuja área de responsabilidade relacioExecutivo de alto nível da na-se com o desenvolvimento de produtos, deve ler o Capítulo 2 para obter uma empresa relacionado com visão ampla do processo e do seu potencial. Em seguida, leia a Parte 3 do livro para o PDP conhecer os níveis de maturidade do PDP, as etapas necessárias para adaptação do modelo à realidade de sua empresa, assim como o método de transformação do PDP de sua empresa, com base no modelo proposto. Caso fique interessado em adotar as melhores práticas apresentadas no livro, você pode indicar a leitura para o seu gerente do PDP ou para os seus gerentes de projetos de desenvolvimento. Um gerente ou mesmo consultor pode estar participando de um projeto de Gerente de implantação implantação ou mudança do PDP. Este projeto pode envolver um grande número do PDP (ou consultor de de temas — da introdução de um novo arranjo organizacional até a implantação de implantação) um sistema de gestão de projetos. Não importa o projeto. Nesses casos, a premissa básica é que todos os participantes e a empresa possuam um “mapa” único de como desenvolver produtos. Isso pode ser obtido a partir do modelo proposto neste livro. Você deve ler o Capítulo 2 e a Parte 3 do livro. Em seguida, baixe do site da editora o modelo de referência em formato de guia. Você deve possuir conhecimentos sobre todos os temas relevantes em desenvolvimento de produtos. Identifique e analise o foco necessário ao seu projeto de mudança, utilizando o guia como uma checklist. Se surgir alguma dúvida, leia o capítulo correspondente ao item do guia. Consulte as bibliografias adicionais, se necessário, ou contate empresas ou parceiros que entendam do assunto. Você pode, ainda, usar o guia como referência para desenhar o processo específico do PDP da sua empresa. Gerente de projeto de desenvolvimento de produtos

Se você for um gerente de projeto de desenvolvimento de produtos, leia o Capítulo 2 e verifique a aderência do modelo à sua empresa. Se a empresa já possuir um modelo do PDP, use o livro como um benchmarking das melhores práticas. Se não

Apresentação

xvii

possuir, você pode adotar o livro como referência, e adaptar o modelo à realidade de sua empresa. Nesses casos, a empresa pode definir um gerente de implantação do PDP (veja o tipo de usuário anterior). Qualquer que seja a direção tomada, o livro pode ser lido e discutido em grupo, com cada membro se responsabilizando pela leitura e apresentação detalhada de capítulos específicos. A aprendizagem, bem como a adequação do modelo às necessidades da empresa, podem ser maiores, em função da sinergia no grupo de estudo. No final, podem ser definidos especialistas por quadros relevantes, e eles devem dar continuidade ao estudo e à implantação dos conceitos e ferramentas estudadas. No caso de você ser um membro de um time de desenvolvimento, leia primeiro Membro de um time de o Capítulo 2, para obter uma visão ampla do processo. Em seguida, utilize o Apêndesenvolvimento dice I “Áreas de conhecimento versus atividades” para identificar quais são as atividades relacionadas com a sua capacitação. Leia os capítulos relacionados com as atividades, assim como os quadros correspondentes. Se achar que são relevantes para o seu trabalho, consulte as informações adicionais e estude o material que obtiver. Utilize os quadros para realizar um autodiagnóstico dos seus conhecimentos e, assim, adquirir motivação para aprender novidades. Procure identificar com colegas do time, que possuem uma outra capacitação, quais as áreas de interesse deles. Tente entender como todos os membros são importantes para o projeto de desenvolvimento. Se você já estiver trabalhando com base em um modelo semelhante, identifique e analise os exemplos de critérios de revisão de fases e os exemplos de indicadores que podem ser aplicados na sua empresa.

Sumário GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

PARTE 1 O Processo

1

1. Gestão do Processo de Desenvolvimento de Produtos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13

O que é o Processo de Desenvolvimento de Produtos e sua importância . . . . . . . . . . . . . . . . . . . . 3 O papel do PDP no Brasil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Características do PDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Tipos de projetos de desenvolvimento de produtos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Definição e escopo do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 A importância da gestão do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Abordagens para gestão do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Arranjos organizacionais para o PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Fatores gerenciais que afetam o desempenho do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Modelo de referência é essencial para o PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Resumo do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2. O Modelo Unificado do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.1 2.2 2.3 2.4

2.5 2.6

2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16

Conceitos de modelagem de processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Visão geral do modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Os papéis principais das pessoas envolvidas no PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Visão geral da macrofase de pré-desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 2.4.1 Por que pré-desenvolvimento? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 2.4.2 Conceitos básicos do processo de planejamento estratégico . . . . . . . . . . . . . . . . . . . . . . . . 52 2.4.3 O início e o fim do pré-desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 2.4.4 A importância do pré-desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 2.4.5 Pré-desenvolvimento é para todos? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Visão geral da macrofase de desenvolvimento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 2.5.1 Características das fases do desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 2.5.2 O início e o fim do desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Visão geral da macrofase de pós-desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 2.6.1 Por que pós-desenvolvimento? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 2.6.2 O início e o fim do pós-desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 2.6.3 Pós-desenvolvimento é para todos? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Revisão de fases (gates) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Métodos e ferramentas de desenvolvimento de produtos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Indicadores de desempenho do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Parceiros do desenvolvimento colaborativo de produtos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Áreas de conhecimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Gestão do conhecimento do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Caracterizando o modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Resumo do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

xx

GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

PARTE 2 O Modelo

103

3. Atividades Genéricas do Modelo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8

Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Atualizar plano da fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Monitorar viabilidade econômico-financeira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Avaliar fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Aprovar fase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Documentar as decisões tomadas e registrar lições aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

4. Planejamento Estratégico de Produtos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11

Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Definir escopo da revisão do PEN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Planejar atividades para a revisão do PEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Consolidar informações sobre tecnologia e mercado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Revisar o PEN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Analisar o portfólio de produtos da empresa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Propor mudanças no portfólio de produtos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Verificar a viabilidade do portfólio de produtos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Decidir o início do planejamento de um dos produtos do portfólio . . . . . . . . . . . . . . . . . . . . . . 145 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

5. Planejamento do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 5.19 5.20

Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Definir interessados do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Definir escopo do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Definir escopo do projeto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Detalhar o escopo do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Adaptar o modelo de referência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Definir atividades e seqüência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Preparar cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Avaliar riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Preparar orçamento do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Analisar a viabilidade econômica do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Definir indicadores de desempenho. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Definir plano de comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Planejar e preparar aquisições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Preparar plano de projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Avaliar fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Aprovar fase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Resumo do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Questões e atividades didáticas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

6. Projeto Informacional. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 6.1 6.2 6.3 6.4 6.5 6.6

Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Atualizar o Plano do Projeto Informacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Revisar e atualizar o escopo do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Detalhar ciclo de vida do produto e definir seus clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Identificar os requisitos dos clientes do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Definir os requisitos do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

Sumário

6.7 6.8 6.9 6.10 6.11 6.12 6.13

xxi

Definir especificações-meta do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Monitorar a viabilidade econômico-financeira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Avaliar fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Aprovar fase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Documentar as decisões tomadas e registrar lições aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

7. Projeto Conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.7 7.8 7.9 7.10 7.11 7.12 7.13 7.14 7.15 7.16

Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Atualizar o Plano do Projeto Conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Modelar funcionalmente o produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Desenvolver princípios de solução para as funções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Desenvolver as alternativas de solução para o produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Definir arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Analisar Sistemas, Subsistemas e Componentes (SSC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Definir ergonomia e estética do produto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Definir fornecedores e parcerias de co-desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Selecionar a concepção do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Definir plano macro de processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 Atualizar estudo de viabilidade econômico-financeira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 Avaliar fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 Aprovar fase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 Documentar as decisões tomadas e registrar lições aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . 291 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

8. Projeto Detalhado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 8.1 8.2 8.3

8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11 8.12 8.13 8.14 8.15 8.16 8.17 8.18 8.19 8.20

Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 Atualizar o plano do projeto detalhado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 Criar e detalhar SSCs, documentação e configuração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 8.3.1 Criar, reutilizar, procurar e codificar SSCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 8.3.2 Calcular e desenhar os SSCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 8.3.3 Especificar tolerâncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 8.3.4 Integrar os SSCs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 8.3.5 Finalizar desenhos e documentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 8.3.6 Configurar produto e completar a estrutura do produto . . . . . . . . . . . . . . . . . . . . . . . . . . 335 Decidir fazer ou comprar SSCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 Desenvolver fornecedores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 Planejar processo de fabricação e montagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 Projetar recursos de fabricação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 Avaliar SSCs, configuração e documentação do produto e processo . . . . . . . . . . . . . . . . . . . . . . 363 Otimizar produto e processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 Criar material de suporte do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 Projetar embalagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 Planejar fim de vida de produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378 Testar e homologar produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378 Enviar documentação do produto a parceiros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 Monitorar a viabilidade econômico-financeira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 Avaliar fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 Aprovar fase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 Documentar as decisões tomadas e registrar lições aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . 386 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390

xxii

GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

9. Preparação da Produção do Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 9.10 9.11 9.12 9.13 9.14 9.15 9.16 9.17

Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 Obter recursos de fabricação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396 Planejar produção piloto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 Receber e instalar recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 Produzir lote piloto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Homologar o processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Otimizar a produção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 Certificar produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 Desenvolver processo de produção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 Desenvolver processo de manutenção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 Ensinar pessoal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 Monitorar viabilidade econômico-financeira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 Avaliar fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 Aprovar fase — liberação da produção. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 Documentar as decisões tomadas e registrar lições aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . 412 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413

10. Lançamento do Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 10.1 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 10.2 Planejar lançamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 10.3 Desenvolver processo de vendas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 10.4 Desenvolver processo de distribuição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 10.5 Desenvolver processo de atendimento ao cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 10.6 Desenvolver processo de assistência técnica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424 10.7 Promover marketing de lançamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 10.8 Lançar produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 10.9 Gerenciar lançamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428 10.10 Atualizar plano de fim de vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 10.11 Monitorar viabilidade econômico-financeira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 10.12 Avaliar fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430 10.13 Aprovar fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430 10.14 Documentar as decisões tomadas, registrar lições aprendidas e encerrar a macrofase de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431 10.15 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432 10.16 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433

11. Acompanhar Produto e Processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 11.1 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 11.2 Avaliar satisfação do cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439 11.3 Monitorar desempenho do produto (técnico, econômico, ambiental, de produção e de serviços) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440 11.4 Realizar auditoria pós-projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 11.5 Registrar lições aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 11.6 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 Questões para reflexão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 11.7 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444

12. Descontinuar o Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 12.1 12.2 12.3 12.4 12.5

Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446 Analisar e aprovar descontinuidade do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448 Planejar a descontinuidade do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449 Preparar o recebimento do produto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449 Acompanhar o recebimento do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450

Sumário

xxiii

12.6 Descontinuar a produção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451 12.7 Finalizar suporte ao produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451 12.8 Avaliação geral e encerramento do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 12.9 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 12.10 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452

13. Processos de Apoio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 13.1 Gerenciamento de Mudanças de Engenharia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456 13.1.1 Informações e papéis do ECM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 13.1.2 Sumário do processo de Gerenciamento de Mudanças de Engenharia. . . . . . . . . . . . . . . 460 13.1.3 Identificar mudança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 13.1.4 Propor mudança. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462 13.1.5 Alterar informações do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 13.1.6 Implementar mudança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 13.1.7 Comentários sobre a implantação do processo de ECM . . . . . . . . . . . . . . . . . . . . . . . . . . 466 13.2 Melhoria Incremental do PDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 13.2.1 Método amplo de transformação de negócios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470 13.2.2 Sumário do processo de melhoria incremental do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . 471 13.2.3 Informações e papéis na melhoria incremental do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . 472 13.2.4 Entender motivação das melhorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472 13.2.5 Analisar situação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 13.2.6 Definir Ações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474 13.2.7 Implantar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475 13.3 Prover a infra-estrutura, educar e treinar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 13.4 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 13.5 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478

PARTE 3 A Aplicação

479

14. Níveis de maturidade do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481 14.1 14.2 14.3 14.4 14.5 14.6 14.7 14.8 14.9

Conceitos sobre maturidade de processo de negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481 Níveis de maturidade para o PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 Nível 1: Básico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 Nível 2: Intermediário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 Níveis avançados de maturidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488 Comentários sobre os níveis de maturidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489 Resumo do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490

15. Método de transformação do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491 15.1 15.2 15.3 15.4 15.5 15.6 15.7 15.8 15.9

Entender motivação das melhorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494 Analisar a situação atual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 Definir ações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 Implantar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500 Prover infra-estrutura, educar e treinar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502 Integração entre transformação e melhoria incremental do PDP . . . . . . . . . . . . . . . . . . . . . . . . 503 Resumo do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506

xxiv

GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

16. O modelo, suas alternativas de aplicação e sua relação com outras abordagens para gestão do PDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507 16.1 Modelo para projetos radicais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508 16.2 Modelo para produção sob encomenda ETO (Engineering To Order) . . . . . . . . . . . . . . . . . . . 508 16.3 Modelo para fornecedor de commodities e para fornecedor de outros tipos de tecnologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510 16.4 Relação entre o modelo e outras abordagens para gestão do PDP. . . . . . . . . . . . . . . . . . . . . . . . 510 16.5 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517 16.6 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

Apêndice I

Modelo de Referência para o PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519

Apêndice II Glossário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 Apêndice III Abreviaturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541

Lista de Quadros

xxv

Lista de Quadros GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

Quadro 1.1 Quadro 2.1 Quadro 2.2 Quadro 2.3 Quadro 2.4 Quadro 2.5 Quadro 2.6 Quadro 2.7 Quadro 2.8 Quadro 4.1 Quadro 4.2 Quadro 4.3 Quadro 4.4 Quadro 4.5 Quadro 4.6 Quadro 4.7 Quadro 4.8 Quadro 4.9 Quadro 4.10 Quadro 4.11 Quadro 4.12 Quadro 5.1 Quadro 5.2 Quadro 5.3 Quadro 5.4 Quadro 5.5 Quadro 5.6 Quadro 5.7 Quadro 5.8 Quadro 5.9 Quadro 5.10 Quadro 5.11 Quadro 5.12 Quadro 5.13 Quadro 5.14 Quadro 5.15 Quadro 6.1 Quadro 6.2

Times/Equipes de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Estratégia Tecnológica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Planejamento Estratégico, Marketing ou Desenvolvimento de Produtos?. . . . . . . . . . . . . . . . . . . . . . . . 58 O que é Engenharia Simultânea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Diretrizes para a Realização de Reuniões Produtivas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Sistemas ERP e Soluções Relacionadas: CRM, SCM e PLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 O Surgimento da Parceira com Fornecedores e das Empresas Especializadas em Serviços de Engenharia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Outros Modelos de Referência Organizam as Atividades por Áreas de Conhecimento . . . . . . . . . . . . . 87 Diferenças entre o PDP e Outros Processos Estruturados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Fontes de Dados para Pesquisa de Mercado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Fontes de Erro em Pesquisas de Mercado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Vigilância Tecnológica na Era da Gestão do Conhecimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Formas de Capacitação Tecnológica (learning) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Tipos de Inovação Tecnológica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Comunidades de Prática no PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Gestão de Portfólio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Técnicas para Avaliação do Portfólio de Produtos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Comparando as Técnicas para a Avaliação de Portfólio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Diferenciação e Posicionamento de Produtos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Estratégias para Planejamento do Portfólio de Produtos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Minuta do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Gestão de Projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Escritório de Projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Participação de Fornecedores no PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Escopo do Produto versus Escopo do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Checklist do Escopo do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Definição de EDT (WBS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Cuidados para a Elaboração da EDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Importância da Definição do Escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Erros Comuns na Preparação da Declaração do Escopo do Projeto. . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Tipos de Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Identificando as Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Softwares de Gestão de Projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Tipos de Relacionamentos entre Atividades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Análise Econômica do Desenvolvimento de Produtos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 A Análise Financeira Acompanhará Todo o Ciclo de Vida do Produto . . . . . . . . . . . . . . . . . . . . . . . . . 196 Termos Utilizados no Projeto Informacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Clientes e Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

xxvi

GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

Quadro 6.3 Quadro 6.4 Quadro 6.5 Quadro 7.1 Quadro 7.2 Quadro 7.3 Quadro 7.4 Quadro 7.5 Quadro 7.6 Quadro 7.7 Quadro 7.8 Quadro 7.9 Quadro 7.10 Quadro 7.11 Quadro 7.12 Quadro 8.1 Quadro 8.2 Quadro 8.3 Quadro 8.4 Quadro 8.5 Quadro 8.6 Quadro 8.7 Quadro 8.8 Quadro 8.9 Quadro 8.10 Quadro 8.11 Quadro 8.12 Quadro 8.13 Quadro 8.14 Quadro 8.15 Quadro 8.16 Quadro 8.17 Quadro 8.18 Quadro 8.19 Quadro 8.20 Quadro 8.21 Quadro 8.22 Quadro 8.23 Quadro 8.24 Quadro 8.25 Quadro 8.26 Quadro 8.27 Quadro 8.28 Quadro 8.29 Quadro 8.30

Visão dos Custos do Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Checklist para Obtenção de Requisitos de Produto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Quality Function Deployment (QFD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Termos Utilizados no Projeto Conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Método FAST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Matriz Morfológica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 TIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Projeto Modular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Seleção de Materiais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Relação de DFX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Princípios e Recomendações do Projeto para a Manufatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Princípios e Recomendações do Projeto para a Montagem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Ergonomia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Definição de Design ou Desenho Industrial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Integração do Projeto Detalhado com o Projeto Conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 Tipos de Ciclos da Fase de Detalhamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 Projeto Preliminar entre o Projeto Conceitual e Detalhado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 Recomendações para o Planejamento das Tarefas de Detalhamento . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 Termos Utilizados no Projeto Detalhado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 Classificação de Itens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 Sistemas CSM, Catálogos na Internet e o e-procurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 Padronização no Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 Identificação de Itens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 Gerenciamento dos Parâmetros Críticos (CPM) de um Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 Sistemas CAD/CAE/CAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 Geometric Dimensioning and Tolerancing (GD&T) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 Processo de Desenvolvimento de Software (PDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 Tipos de BOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 Custo-alvo e Gestão de Custos do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 Diminuindo os Custos, Desenvolvendo Fornecedores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 Paralelismo entre Desenhar e Planejar Processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 Sistemas Product Data Management (PDM — Gestão de Dados de Produto) . . . . . . . . . . . . . . . . . . . 347 Métodos Amplos de Planejamento do Processo Tradicional (Manual) . . . . . . . . . . . . . . . . . . . . . . . . . 350 Manufatura Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 Sistemas Computer Aided Process Planning (CAPP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 Projeto de Fábrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 Métodos de Avaliação dos Sistemas, Subsistemas e Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 Failure Mode and Effect Analysis (FMEA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 Planejamento de Experimentos (DOE —Design Of Experiments) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 Projeto Robusto (RD —Robust Design) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 O Uso de Protótipos e Modelos de Produtos (Componentes e Ferramentas) . . . . . . . . . . . . . . . . . . . . 373 Disponibilidade, Confiabilidade e Manutenabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 Requisitos da ISO 9001 e as Atividades Deste Modelo de Referência . . . . . . . . . . . . . . . . . . . . . . . . . . 379 Product Life-cycle Management (PLM ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

Lista de Quadros

Quadro 9.1 Quadro 9.2 Quadro 9.3 Quadro 10.1 Quadro 10.2 Quadro 10.3 Quadro 10.4 Quadro 11.1 Quadro 11.2 Quadro 12.1 Quadro 12.2 Quadro 13.1 Quadro 13.2 Quadro 13.3 Quadro 13.4 Quadro 13.5 Quadro 15.1 Quadro 15.2 Quadro 15.3

xxvii

Análise dos Sistemas de Medição (MSA — Measurement System Analysis) . . . . . . . . . . . . . . . . . . . . . 402 Indicadores de Capabilidade de Processo e Controle Estatístico do Processo (CEP) . . . . . . . . . . . . . . 404 Lean Production (Produção Enxuta) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 Logística e Distribuição na Gestão da Cadeia de Suprimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421 Sistemas de Gestão Eletrônica de Documentos (GED) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 Riscos se os Processos de Apoio não Estiverem Operacionais no Lançamento . . . . . . . . . . . . . . . . . . . 428 Tarefas de Marketing no Desenvolvimento de Produtos?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431 Considerações sobre a Macrofase de Pós-desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 As Atividades de Acompanhamento Propiciam Benefícios para o Produto e para PDP como um Todo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438 O Impacto Ambiental, Relacionado à Retirada do Produto, Deve Ser Analisado, e Qualquer Aspecto Negativo, Tratado de Forma a Gerar uma Ação Efetiva . . . . . . . . . . . . . . . . . . . . . 448 Ecodesign e Design For Environment (DFE ). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450 ECM versus Gestão da Configuração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 Sistemas Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 Considerações sobre Melhoria do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469 PDCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 Técnicas de Diagnóstico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474 Melhoria Incremental ou Inovadora (Transformação)?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492 Benchmarking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495 Sistematização do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498

Como foi mencionado na Apresentação deste livro, esta primeira parte fornece a base conceitual para o entendimento do modelo (veja a Figura P1). Esta primeira parte é dividida em dois capítulos. O Capítulo 1 traz os conceitos da área de Gestão do Desenvolvimento de Produtos (GDP), que é a área que usa modelos de referência para a melhoria do processo. Destaca, ainda, a importância do Processo de Desenvolvimento de Produtos (PDP) para as empresas em geral. Em seguida, discute as particularidades desse processo de negócio e, também, a realidade do Brasil nessa área, as principais abordagens e arranjos organizacionais para o PDP, e quais os fatores que afetam o desempenho desse processo. As principais abordagens de GDP, então, são apresentadas, as quais serão novamente mencionadas no capítulo final, quando elas forem comparadas com o Modelo Unificado deste livro. Se você observar o tópico “Como ler e empregar este livro”, mostrado na Apresentação, verá a importância do Capítulo 2, que traz uma visão geral do modelo. Nele são apresentadas as macrofases e os principais conceitos gerais, que estão detalhados na Parte 2 deste livro. Esse capítulo é ideal para leitores que desejam ter uma visão ampla, mas superficial, do modelo. Para os demais leitores, é importante obter uma visão do todo, para, depois, aprofundar-se nas fases e atividades do modelo.

Visão geral dos capítulos da Parte 1.

Parte 1

O Processo

Gestão do Processo de Desenvolvimento de Produtos

1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13

3

O que é o Processo de Desenvolvimento de Produtos e sua importância O papel do PDP no Brasil Características do PDP Tipos de projetos de desenvolvimento de produtos Definição e escopo do PDP A importância da gestão do PDP Abordagens para gestão do PDP Arranjos organizacionais para o PDP Fatores gerenciais que afetam o desempenho do PDP Modelo de referência é essencial para o PDP Resumo do capítulo Questões e atividades didáticas propostas Informações adicionais

1. Gestão do Processo de Desenvolvimento de Produtos Gestão do Processo de Desenvolvimento de Produtos PARTE 1 O Processo

Depois da leitura deste capítulo, você será capaz de: l

l

l

l

l

l

l

Entender o que é desenvolver um produto e qual é o processo pelo qual são gerados novos produtos. Entender a importância estratégica do processo de desenvolvimento de produto e em que ele contribui para a competitividade da empresa. Conhecer as principais características específicas das atividades típicas de desenvolvimento de produto, tais como o elevado grau de incerteza e de requisitos a serem atendidos. Compreender como o desempenho desse processo depende da sua gestão. Conhecer as principais abordagens e arranjos organizacionais para gestão do desenvolvimento de produto. Conhecer os principais fatores gerenciais que contribuem para o desempenho desse processo Compreender que a adoção de um modelo de referência é importante para guiar a estruturação e a gestão desse processo.

1.1

O que é o Processo de Desenvolvimento de Produtos e sua importância

De modo geral, desenvolver produtos consiste em um conjunto de atividades por meio das quais busca-se, a partir das necessidades do mercado e das possibilidades e restrições tecnológicas, e considerando as estratégias competitivas e de produto da empresa, chegar às especificações de projeto de um produto e de seu processo de produção, para que a manufatura seja capaz de produzi-lo. O desenvolvimento de produto também envolve as atividades de acompanhamento do produto após o lançamento para, assim, serem realizadas as eventuais mu-

4

PARTE 1

O Processo

danças necessárias nessas especificações, planejada a descontinuidade do produto no mercado e incorporadas, no processo de desenvolvimento, as lições aprendidas ao longo do ciclo de vida do produto. O desenvolvimento de produtos é considerado um processo de negócio cada vez mais crítico para a competitividade das empresas, principalmente com a crescente internacionalização dos mercados, aumento da diversidade e variedade de produtos e redução do ciclo de vida dos produtos no mercado. Novos produtos são demandados e desenvolvidos para atender a segmentos específicos de mercado, incorporar tecnologias diversas, se integrar a outros produtos e usos e se adequar a novos padrões e restrições legais. Ou seja, é por meio desse processo que a empresa pode criar novos produtos mais competitivos e em menos tempo para atender à constante evolução do mercado, da tecnologia e dos requisitos do ambiente institucional (principalmente quanto à sua saúde, meio ambiente e segurança). Os clientes estão cada vez mais exigentes, informados e com maiores possibilidades de escolhas, e as empresas competidoras globais, com freqüência, lançam novos produtos, os quais buscam atender continuadamente às mudanças nas necessidades dos clientes, de forma melhor e com maior número de funcionalidades, tornando-os mais atrativos e criando no cliente o desejo de substituir o produto (modelo) anterior. Esse ambiente competitivo impõe ao processo de desenvolvimento de produtos a necessidade de estar apto, em habilidades e competências, para atuar com dinamismo e flexibilidade em um grau até então não experimentado pelas empresas. O Processo de Desenvolvimento de Produtos (PDP) situa-se na interface Desenvolvimento de entre a empresa e o mercado, cabendo a ele identificar — e até mesmo se antecipar produtos: interface entre a — as necessidades do mercado e propor soluções (por meio de projetos de produtos empresa e o mercado e serviços relacionados) que atendam a tais necessidades. Daí sua importância estratégica, buscando: identificar as necessidades do mercado e dos clientes em todas as fases do ciclo de vida do produto; identificar as possibilidades tecnológicas; desenvolver um produto que atenda às expectativas do mercado, em termos da qualidade total do produto; desenvolver o produto no tempo adequado — ou seja, mais rápido que os concorrentes — e a um custo competitivo. Além disso, também deve ser assegurada a manufaturabilidade do produto desenvolvido, isto é, a facilidade de produzi-lo, atendendo às restrições de custos e de qualidade na produção. Diversas publicações apontam o papel central que o PDP tem representado no Desenvolvimento de ambiente competitivo das últimas décadas. Além disso, significativos estudos analiprodutos: importante sando o desempenho de empresas em âmbito mundial, principalmente comparando para aumento da as indústrias japonesas e norte-americanas, demonstraram que uma importante parcompetitividade cela da vantagem competitiva conseguida pela manufatura japonesa nas últimas décadas advém do modo como os produtos são desenvolvidos e aperfeiçoados. As indústrias norte-americanas e européias dos setores automobilísticos e de produtos eletrônicos de consumo, por exemplo, incorporaram muitos novos conhecimentos sobre gestão do PDP a partir dos casos bem-sucedidos de desenvolvimento de produtos por empresas japonesas. O lançamento eficaz de novos produtos e a melhoria da qualidade daqueles já existentes fazem parte do escopo do PDP e são duas questões de grande relevância para a capacidade competitiva das empresas. Historicamente, por influência da cultura dominante nos tradicionais laboratórios de Pesquisa & Desenvolvimento (P&D), considerava-se que o êxito das empresas no desenvolvimento de produtos dependeria em grande parte da genialidade dos profissionais que atuavam nesse processo e de maiores montantes financeiros alocados a ele. Considerava-se que as incertezas, a baixa previsibilidade e criatividade inerentes a esse processo inviabilizariam qualquer tentativa de disciplinar as atividades e estruturar e gerenciar o processo, com conseqüências negativas nos resultados obtidos. Ao longo das últimas décadas, diversos casos bem-sucedidos de empresas e países em termos de desenvolvimento de produtos evidenciaram que o desempenho desse processo depende também e muito do modelo e das práticas de gestão adotadas. Ou seja, mesmo com tais especificidades (incerteza, baixa previsibilidade e criatividade), é possível e necessário gerenciar o PDP, planejando, executando, controlando e melhorando as atividades, em busca de melhores resultados de desempenho e de aprendizagem — algo que será apresentado ao longo deste livro.

CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos

1.2

5

O papel do PDP no Brasil

Em países em desenvolvimento, como é o caso do Brasil, as atividades de desenvolvimento de produtos tradicionalmente se concentram em grande parte nas adaptações e melhorias de produtos existentes. Em alguns segmentos de mercado (como automóveis, equipamentos eletrônicos, produtos farmacêuticos), os novos produtos tendem a ser concebidos e projetados quase exclusivamente nos países desenvolvidos (onde normalmente estão localizados os centros de desenvolvimento das corporações multinacionais e onde os mercados têm maior poder aquisitivo) e são difundidos nos demais países via transferência internacional de tecnologia. Assim, para produtos desses segmentos, as atividades de desenvolvimento de produtos no Brasil são voltadas principalmente para adequação do produto e do projeto às condições do mercado local, à estrutura de fornecedores existentes e aos processos de produção disponíveis. A importância estratégica e a divisão internacional de atividades do PDP, entre países desenvolvidos e em desenvolvimento, evidentemente, manifestam-se de forma diferenciada, conforme o setor e, também, o papel do país na produção mundial do produto em questão. No Brasil, em muitos setores industriais, a tendência em termos de desenvolvimento de produto é no sentido de consolidar uma competência local para adaptar projetos mundialmente atuais para o mercado local ou regional (por exemplo, Mercosul), ou mesmo para participar de projetos de desenvolvimento mundiais — responsabilizando-se por atividades e/ou etapas específicas desses projetos em função das capacitações existentes no país. Nesse segundo caso, a unidade local da corporação multinacional pode se responsabilizar por etapas do desenvolvimento e, eventualmente, ser a responsável pelo fornecimento global do produto, em função da capacidade de manufatura local. Também podem existir casos específicos em que a unidade local é a responsável pelo desenvolvimento total de um produto, em função do domínio tecnológico e de vantagens competitivas no desenvolvimento de determinadas linhas de produto. Essa possibilidade surge como reflexo de uma alternativa de organização do desenvolvimento de produto, de corporações multinacionais, de forma distribuída, a partir de competências locais específicas que cada unidade procura adquirir e que estão distribuídas pelo mundo, em contraposição às alternativas de desenvolvimento totalmente centralizado (na matriz) ou descentralizado (por país, sendo que, em cada um, pode haver repetição de competências). É o caso, por exemplo, do desenvolvimento de projetos de ônibus, de caminhões e de compressores herméticos por algumas unidades de multinacionais instaladas no Brasil. Pode-se destacar, ainda, o papel e a capacitação crescente do país no desenvolvimento de carros populares (com motorização de baixa cilindrada) e o reconhecimento internacional da capacitação da Embraer na coordenação dos projetos de desenvolvimento de suas aeronaves. Em relação ao desenvolvimento de produto em unidades de multinacionais instaladas no Brasil, observa-se, em algumas empresas, movimentações no sentido de reduzir as atividades de desenvolvimento locais, e, em outras, observa-se o aumento do espectro de atividades realizadas aqui no país. Não fica claro qual será o sentido dominante da tendência geral dessas movimentações (se de aumento ou redução) em relação às atividades do PDP realizadas no Brasil. Para equilíbrio e geração de superávits nas contas externas do Brasil, o país necessita exportar produtos de maior valor agregado, em vez de matérias-primas e produtos semiprocessados. Isso exige uma maior capacitação e esforço de desenvolvimento de produto, para dispor, ao mercado local, produtos brasileiros com padrões equivalentes aos importados, e para capacitar o país a exportar produtos de padrão internacional. E isso passa, necessariamente, pela melhoria na qualificação do corpo técnico e gerencial das empresas em gestão do Processo de Desenvolvimento de Produtos, o que é um dos focos deste livro. Ou seja, considera-se fundamental para o país a elevação do nível de conhecimento sobre as boas práticas de estruturação e gerenciamento desse processo de negócio. É importante ressaltar que mesmo que a tecnologia e a concepção de um novo produto venha do exterior, existem ainda muitas atividades de desenvolvimento (do projeto detalhado, passando pelo projeto ou planejamento do processo, testes, projeto de fábrica, lançamento etc.), que estão inseridas no escopo do desenvolvimento de produtos, e que fazem parte das responsabilidades de empresas locais.

6

PARTE 1

1.3

O Processo

Características do PDP

O PDP, comparado a outros processos de negócio, tem diversas especificidades. As principais características que diferenciam esse processo são: n n n n

n n n

elevado grau de incertezas e riscos das atividades e resultados; decisões importantes devem ser tomadas no início do processo, quando as incertezas são ainda maiores; dificuldade de mudar as decisões iniciais; as atividades básicas seguem um ciclo iterativo do tipo: Projetar (gerar alternativas)-ConstruirTestar-Otimizar, manipulação e geração de alto volume de informações; as informações e atividades provêm de diversas fontes e áreas da empresa e da cadeia de suprimentos; e multiplicidade de requisitos a serem atendidos pelo processo, considerando todas as fases do ciclo de vida do produto e seus clientes.

Essas características fazem com que a natureza desse processo seja relativamente diferente dos demais processos da empresa, o que condicionará os modelos e práticas de gestão adequadas ao processo, além do perfil e das capacitações requeridas dos profissionais que atuam no PDP. O lançamento de um produto novo no mercado, para a maioria das empresas, não é uma atividade rotineira e, sim, o resultado de um esforço que pode durar um tempo significativo e envolver quase todos os setores funcionais da empresa, com implicações nas vendas futuras e conseqüentemente na sobrevivência da empresa. Uma característica organizacional muito específica da atividade de desenvolvimento é que cada projeto pode apresentar problemas, dificuldades e históricos muito particulares. Ou seja, a atividade de desenvolvimento não é uma atividade rotineira, como acontece nos processos financeiros ou de produção. O volume de informações de entrada no processo, de informações processadas e repassadas é relativamente alto, variado e complexo. As informações de entrada, tais como requisitos de mercado, requisitos legais, requisitos de homologação, as capacidades e competências da empresa e de sua rede de fornecedores etc., são bastante variadas e provêm de diversas fontes internas e externas à empresa. Não se deve esquecer que os requisitos a serem considerados dizem respeito a todos os clientes de todas as fases do ciclo de vida do produto (projeto, manufatura, distribuidores, usuários, pessoal de assistência técnica, reciclagem do produto etc.). Além disso, as atividades do PDP influenciam e são influenciadas pelo trabalho de praticamente todas as pessoas da empresa, já que o novo produto será desenvolvido, produzido, vendido e controlado envolvendo e sendo envolvido por todos os setores. Assim, uma especificidade na gestão do PDP é a necessidade de integração de informações e decisões com muitas áreas da empresa. Isso aumenta a importância da coordenação e da comunicação entre as etapas e atividades relativas ao processo e a necessidade de integração interfuncional. Nas fases iniciais do PDP é que são definidas as principais soluções construtivas e as especificações do produto. É nesse momento que são determinados os materiais e as tecnologias a serem utilizados, os processos de fabricação, a forma construtiva etc. Apesar de existir a possibilidade de caminhar ao longo do processo com soluções alternativas, as definições essenciais e centrais são determinadas nesse período. Normalmente, argumenta-se que as escolhas de alternativas ocorridas no As decisões técnicas início do ciclo de desenvolvimento são responsáveis por cerca de 85% do custo do iniciais determinam produto final. Ou seja, todas as outras definições e decisões a serem tomadas ao 85% do custo final longo do ciclo de desenvolvimento, após as fases iniciais, determinam 15% do do produto... custo. Em outras palavras, depois da definição dos materiais, tecnologia, processos de fabricação e principais soluções construtivas, resta ao time de desenvolvimento: determinar as tolerâncias das peças; construir e testar o protótipo; definir os fornecedores; o arranjo de parceiros da cadeia de suprimentos e o arranjo físico da produção; a campanha de marketing; assistência técnica etc. E essas definições, quando comparadas com as anteriores, exercem menor influência no custo final do produto.

CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos

7

Além disso, parte dessas definições também ocorre nas fases iniciais e apenas são detalhadas e consolidadas nas fases subseqüentes. Conforme mostra a Figura 1.1, para muitos tipos de produto, durante as fases de desenvolvimento, os custos de fato incorridos (ou seja, aqueles que já aconteceram) são relativamente baixos em relação ao custo final. Porém, por outro lado, essas fases são bastante críticas quanto ao comprometimento do custo final do produto. Nas fases de produção, são poucas as possibilidades de redução desse custo, já que elas estão atreladas às especificações técnicas já definidas. Figura 1.1

Curva de comprometimento do custo do produto.

No entanto, exatamente quando se toma a maior parte das decisões, que são ...mas, justo no início, significativas para a determinação do custo final do produto, é o momento no qual quando temos de tomar se tem o maior grau de incerteza sobre o produto e suas especificações, sobre o seu as decisões, as incertezas processo de fabricação e mesmo se ele será um sucesso no mercado. Somente no desão grandes senrolar do desenvolvimento, quando muitos conceitos, alternativas construtivas e soluções estiverem definidos, é que esse grau de incerteza vai diminuindo. Com o tempo, as incertezas vão diminuindo, de acordo com as definições que vão sendo tomadas. Mas o fato concreto é que é preciso tomar decisões importantes quando ainda se têm muitas incertezas. Por mais que se procure tomar as melhores decisões e acertar as definições no início do desenvolvimento, sempre ocorrem mudanças no projeto ao longo do desenvolvimento, uma vez que as decisões tomadas envolvem muitas incertezas. O custo de modificação de uma decisão anterior de projeto aumenta ao longo do ciclo de desenvolvimento, pois, para se efetivar uma mudança, as decisões já tomadas e as ações conseqüentes já realizadas podem ser invalidadas. O segredo de um bom desenvolvimento de produtos é, assim, garantir que as O segredo, então, é incertezas sejam minimizadas por meio da qualidade das informações, e que, a cada gerenciar as incertezas momento de decisão, exista um controle constante dos requisitos a serem atendidos e uma vigilância das possíveis mudanças de mercado.

8

PARTE 1

O Processo

As incertezas típicas dizem respeito não apenas à falta de informações relevantes sobre eventos previstos, mas, também, à existência de problemas tecno-econômicos, cujos procedimentos de solução são desconhecidos, e à impossibilidade de traçar precisamente as conseqüências das decisões e ações tomadas. As atividades típicas do PDP seguem a seqüência Projetar-Construir-Testar-Otimizar, sendo que o que se “projeta-constrói-testa-otimiza” pode ser um conceito, uma especificação ou uma tolerância, tanto do produto ou do processo de produção. E isso é diferente das atividades típicas da manufatura em que, por exemplo, se tem uma especificação do produto e se produz e controla o processo de fabricação para atingir essa especificação. Tal especificidade faz com que o retrabalho, que é mais visível, definido e quantificável na atividade de manufatura, seja menos visível e definido, embora não menos custoso, no PDP, à medida que ele aparece diluído na própria natureza iterativa das atividades do processo.

1.4

Tipos de projetos de desenvolvimento de produtos

Os projetos de desenvolvimento de produtos podem ser classificados por diversos critérios, sendo que a classificação mais comum e útil é baseada no grau de mudanças que o projeto representa em relação a projetos anteriores. Essa classificação depende das especificidades do setor. Por exemplo, existem significativas diferenças na classificação adotada no setor automobilístico em relação ao setor alimentício. A Figura 1.2 traz a classificação de projetos de desenvolvimento usual nos setores de bens de capital e de bens de consumo duráveis. Figura 1.2

n

n

Tipos de projeto de desenvolvimento de produtos baseados na inovação.

Projetos radicais (breakthrough): são os que envolvem significativas modificações no projeto do produto ou do processo existente, podendo criar uma nova categoria ou família de produtos para a empresa. Como, nesse tipo de projeto, são incorporados novas tecnologias e materiais, eles normalmente requerem um processo de manufatura também inovador. Projetos plataforma ou próxima geração: normalmente representam alterações significativas no projeto do produto e/ou do processo, sem a introdução de novas tecnologias ou materiais, mas representando um novo sistema de soluções para o cliente. Esse novo sistema de soluções pode representar uma próxima geração de um produto ou de uma família de produtos anteriormente existentes. Também pode representar

CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos

n

9

o projeto de uma estrutura básica do produto que seria comum entre os diversos modelos que compõem uma família de produtos. Para funcionar como plataforma, um projeto deve suportar toda uma geração de produto (ou de processo) e ter ligação com as gerações anteriores e posteriores do produto. Projetos incrementais ou derivados: envolvem projetos que criam produtos e processos que são derivados, híbridos ou com pequenas modificações em relação aos projetos já existentes. Esses projetos incluem versões de redução de custo de um produto e projetos com inovações incrementais nos produtos e processos. Requerem menos recursos, pois partem dos produtos ou processos existentes, estendendo a sua aplicabilidade e ciclo de vida.

Além desses tipos de projetos, em países como o Brasil, temos os chamados projetos follow-source (seguir a fonte), que são projetos que chegam da matriz ou de outras unidades do grupo ou de clientes, e que não requerem alterações significativas da unidade brasileira que irá adequar o projeto e produzir o produto. Geralmente, nessas unidades, são realizadas atividades de desenvolvimento, como adaptações à realidade local, validação do processo e de equipamentos e ferramentas, a produção do lote piloto e o início da produção. Um outro tipo de projeto que pode existir nas empresas, mas menos comum, são os chamados Projetos de Pesquisa Avançada, que têm por objetivo criar conhecimento para projetos futuros. Esses projetos normalmente são precursores do desenvolvimento comercial, mas não possuem objetivos comerciais de curto prazo. Ou seja, não se trata de um projeto de desenvolvimento de produto propriamente dito, mas, sim, de pesquisa avançada. Todos esse tipos de projeto podem ser conduzidos internamente à empresa ou por meio de alianças ou parcerias com outras empresas ou instituições. A diferenciação em relação aos demais projetos não está no grau de mudança incorporado, e, sim, no fato de ser conduzido fora do âmbito da empresa ou em parcerias com outras empresas. Nos casos em que a empresa dispõe de um portfólio de produtos e de projetos, adotando uma abordagem de gerenciamento de multiprojetos e de projetos plataforma, é possível uma outra classificação de projetos de desenvolvimento, caracterizando-os em quatro tipos, dependendo do escopo da nova tecnologia ou de mudanças na plataforma e de quão rápido a empresa transfere a plataforma de um projeto para outro. Os quatro tipos de projeto são: n n

n

n

Novo projeto: é aquele em que é desenvolvida uma nova plataforma tecnológica. Transferência de tecnologia simultânea: quando um novo projeto utiliza a plataforma de um projetobase, antes que o desenvolvimento deste tenha sido concluído. Transferência de tecnologia seqüencial: quando um novo projeto utiliza a plataforma de um projetobase, cujo desenvolvimento já foi concluído e encontra-se em fase de produção. Modificação de projeto: neste tipo, não há transferência de tecnologia ou de plataforma de um projeto para outro. Um projeto é modificado, mas sem que haja mudança na plataforma. Há apenas modificações em um projeto existente.

Os projetos de novos produtos podem ser classificados também em termos de projetos de produtos que são novos para a empresa e de projetos que são novos para o mercado. Projeto novo para a empresa é aquele cujo produto já existe no mercado, mas que, para a empresa, é totalmente novo. Projeto novo para o mercado é aquele cujo produto ainda não existe no mercado. O primeiro projeto de videocassete doméstico, que foi desenvolvido pela JVC, era um produto novo para o mercado, ainda que tenha sido desenvolvido tendo como ponto de partida equipamentos já existentes para exibição em cinemas. Já quando, por exemplo, anos após, a LG desenvolveu o seu primeiro projeto de videocassete, o projeto era novo apenas para a empresa. Obviamente, quanto maior o grau de inovação do projeto, maior é o esforço de desenvolvimento requerido da empresa. A importância de classificar os projetos de uma empresa está na necessidade de planejar estrategicamente e de forma conjunta todos os projetos de desenvolvimento, os quais possuem relevância e necessidades de recursos que são específicas a cada caso. Com isso, assegura-se que se tenha a quantidade adequada de recursos para coor-

10

PARTE 1

O Processo

denar e executar os vários projetos, conseguir eficiência nas atividades realizadas e obter um padrão adequado de inovação dos produtos da empresa, que não seja nem tão conceitualmente estático nem caoticamente dinâmico.

1.5

Definição e escopo do PDP

Uma organização é um sistema complexo formado por pessoas e recursos, como equipamentos e instalações, com intensas, variadas e complexas relações entre si, tornando árdua a tarefa de compreendê-la. Essa complexidade, aliada às especificidades do processo já citadas, dificulta a determinação do contorno que delimita a composição do PDP, tendo em vista que esse processo abrange atividades de praticamente todas as áreas da empresa e de suas cadeias de suprimentos e de distribuição. É importante considerar dois aspectos relevantes para o enfoque da estruturação e gestão do desenvolvimento de produtos: o conceito de processo e o fluxo de informações. O PDP envolve um fluxo de atividades e de informações. Processo é, em linhas gerais, um conjunto de atividades realizadas em uma seqüência lógica com o objetivo de produzir um bem ou serviço que tem valor para um grupo específico de clientes. O conceito de processo auxilia na visualização das organizações em termos das atividades ou conjuntos de atividades realizadas, de suas inter-relações e da integração e eficiência de suas operações. A compreensão e o gerenciamento do fluxo de informações são importantes à medida que o PDP gera e faz uso de entradas e saídas de conhecimentos e informações, nas atividades e no processo como um todo, interagindo com as mais diversas fontes de informação, principalmente as áreas funcionais da empresa, fornecedores e clientes. Quando o PDP é visualizado como um fluxo de informações, estão subentendidos o fluxo de criação, de comunicação e de utilização das informações desenvolvidas, englobando a engenharia, a produção, o marketing e o mercado consumidor. A visão do PDP baseada em fluxo de atividades e de informações permite compreender as ligações críticas entre as áreas da empresa e entre essa, o mercado, os fornecedores, as fontes de informação tecnológica e as instituições de regulamentação do produto. Desse modo, pode-se posicionar o PDP dentro do ambiente da empresa, sua relação com os outros processos internos e com o ambiente externo à empresa. O processo de desenvolvimento de produto foi, tradicionalmente, visto como a O escopo do processo de elaboração de um conjunto de informações sobre as especificações de um produto e desenvolvimento de sobre como produzi-lo e sua disponibilização para a manufatura. Mas essa visão produto vem sendo convencional, ainda muito empregada, é posta em xeque quando se consideram as ampliado, envolvendo novas abordagens com as quais as empresas de ponta têm direcionado suas ativimuitas áreas funcionais da dades de desenvolvimento de produto. Essas empresas abordam o PDP como um empresa e a cadeia de suprimentos processo que integra suas áreas e sua cadeia de suprimentos. Assim, o desenvolvimento de produto pode ser compreendido e visualizado por meio da consideração de todas as atividades, internas à empresa e nas cadeias de suprimentos e de distribuição. Essas participam da função de traduzir o conhecimento sobre as necessidades do mercado, as oportunidades tecnológicas e as estratégias da empresa em informações para a produção, distribuição, uso, manutenção e descarte do produto, considerando todo o seu ciclo de vida. Nessa nova visão, o PDP deve integrar desde atividades do planejamento estratégico e competitivo da empresa até a descontinuidade ou retirada do produto do mercado. O desenvolvimento de produto envolve muitas atividades a serem executadas por diversos profissionais de diferentes áreas da empresa, tais como: Marketing, Pesquisa & Desenvolvimento, Engenharia do Produto, Suprimentos, Manufatura e Distribuição — cada uma vendo o produto por uma perspectiva diferente, mas complementares. Tal particularidade exige que essas atividades, e suas decisões relacionadas, sejam realizadas em conjunto e de forma integrada, evidenciando a necessidade de estruturar um processo específico que reúna esse conjunto de atividades a serem planejadas e gerenciadas de forma dedicada. Desenvolvimento de produtos como um processo

CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos

11

A tomada de decisões sobre o projeto envolvendo pessoas com diferentes visões do produto, ainda na fase de desenvolvimento, pode antecipar problemas e soluções, além de reduzir o tempo de lançamento do produto. Decisões inadequadas tomadas no início do desenvolvimento podem ser difíceis e caras de serem revertidas nas fases em que o produto já se encontra em produção e uso no mercado. Assim, quanto ao escopo do PDP, há uma ampliação em ambos os sentidos do processo de negócio, ou seja, a montante e a jusante de seu tradicional núcleo central, conforme pode ser acompanhado na Figura 1.3. Cada vez mais são incorporadas nesse processo as estratégias de produto, de mercado e tecnológicas da empresa, além das atividades necessárias para suportar a produção, o lançamento e o acompanhamento do produto no mercado e a decisão de sua descontinuidade. Com essas ampliações, obtém-se um processo mais coeso em que o planejamento e a execução do projeto e o acompanhamento do produto pós-venda estão integrados em um mesmo processo de negócio, que, como em um ciclo, permite que seja gerenciada e garantida a retroalimentação rápida e contínua dos dados e informações sobre o desempenho do produto e os requisitos dos consumidores e da sociedade. Os requisitos dos clientes e de instituições de regulamentação e os problemas manifestados nos produtos em campo são, dessa forma, continuamente compilados e alimentam o planejamento e as decisões tomadas durante o desenvolvimento de novos produtos e a melhoria dos produtos existentes. Figura 1.3 O processo de desenvolvimento de produtos envolve o processo de planejamento estratégico e acompanha o processo de produção.

O desenvolvimento de produtos deve abranger todo o planejamento e gerenciamento do portfólio de produtos (produtos que já estão no mercado, produtos que estão sendo lançados, produtos em fase de descontinuidade) e do portfólio de projetos (projetos em fase de planejamento, projetos em andamento, projetos concluídos), garantindo compatibilidade com as estratégias da empresa. Deve abranger, também, a especificação de todos os recursos e procedimentos de manufatura, envolvendo compra de máquinas, equipamentos, ferramentas e, quando necessário, a construção de novas unidades de produção. Ou seja, envolve tanto a gestão estratégica quanto a gestão operacional desse processo de negócio, considerando aspectos de mercado e da manufatura. E, ainda, não se pode esquecer que o produto desenvolvido envolve não só o bem físico como também todo o tipo de informação e serviços associados ao seu uso e manutençãoo. Assim, o seu desenvolvimento deve abranger a obtenção e garantia da qualidade de todos esses itens, ou seja, do produto físico e dos serviços (por exemplo, assistência técnica) e informações (por exemplo, manuais de instruções de operação e uso). Uma das principais explicações para a ampliação da visão do desenvolvimento de produto é a preocupação com o gerenciamento do ciclo de vida completo do produto (da identificação das necessidades à retirada física e disposição do produto). Nesses casos, não existe a dissolução das equipes responsáveis pelo desenvolvimento (ou

12

PARTE 1

O Processo

pelo menos de parte dela) após a sua “entrega” para a manufatura. Ou seja, durante a fase de produção e consumo, há momentos de registrar, para o PDP, as experiências obtidas a fim de melhorar e atualizar o produto desenvolvido e de aprender para não cometer os mesmos erros em futuros desenvolvimentos. Finalmente, deve-se preparar e implantar o plano de descontinuidade do produto no mercado. Todas essas atividades, e também a logística de captação do produto no momento do seu descarte pelo cliente e o planejamento de sua reciclagem, fazem parte do escopo do desenvolvimento. Para um desenvolvimento de produto bem-sucedido, é essencial a integração O PDP e outros processos desse processo com as funções e outros processos empresariais envolvidos na realide negócio ou áreas zação de atividades ou suprimento de informações para o PDP. Isso requer que o funcionais tempo, a comunicação, a disponibilização de informações e o conteúdo das atividades nas várias funções estejam coordenados e que as ações tomadas nas funções apóiem-se mutuamente, tendo em vista as metas do projeto. Os principais processos e funções que realizam atividades pertinentes ao PDP podem ser visualizados na Figura 1.4. Figura 1.4

Processos relacionados com o desenvolvimento de produtos.

Os processos que, na Figura 1.4, aparecem acima do PDP envolvem basicamente atividades de manipulação de informações referentes ao conhecimento sobre o mercado e às estratégias e práticas da empresa para atender esse mercado. Já os processos que aparecem abaixo referem-se à realização de atividades mais técnicas que suportam o desenvolvimento do projeto ou que permitem implantar o novo produto. O modelo de PDP apresentado nos capítulos seguintes do livro considera a integração com todos esses processos e funções, recebendo e fornecendo informações e compartilhando conhecimentos e atividades. O Planejamento Estratégico é um processo gerencial que não está vinculado a uma função específica dentro da empresa, caracterizando-se como um processo cross funcional. Uma das finalidades do Planejamento Estratégico é gerar informações que orientem o PDP principalmente nas suas fases iniciais, quando ocorre a definição do produto, mas também durante todo o processo de desenvolvimento. O Planejamento Estratégico, desdobrado no Planejamento Estratégico do Produto, orienta o PDP em relação às estratégias tecnológicas (foco da tecnologia central do produto, fontes para aquisição da tecnologia e timing para introdução das inovações tecnológicas) e às estratégias de produto da empresa (linhas de produto, segmentos de mercado a serem atendidos pela empresa, como levar o produto até o mercado — canais de distribuição —, características dos produtos a serem priorizadas para enfrentar a concorrência e atrair os clientes etc.). Monitorar o mercado é um processo geralmente vinculado à área funcional de Marketing. Tem por finalidade abastecer o PDP de informações sobre o mercado antes, durante e após o desenvolvimento propriamente

CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos

13

dito, acompanhando as tendências, comparando o desempenho e posicionamento dos produtos, captando requisitos e sugestões dos clientes e das instituições que regulamentam o produto e o setor no qual a empresa atua. O novo produto normalmente requer a preparação da equipe de Vendas, elaborando as argumentações para a venda, as orientações a serem passadas aos clientes, as vantagens do novo produto, além da preparação dos documentos pertinentes, tais como: rotinas, manuais e catálogos. Essas atividades devem se realizadas sob a orientação e em conjunto com as equipes do desenvolvimento do produto. Dependendo do tipo de produto, por exemplo, se é um novo equipamento com novas funcionalidades, caberá à equipe de desenvolvimento preparar o pessoal interno que atuará nas funções de Atendimento ao Cliente, para que os clientes sejam devidamente orientados (de forma remota ou com a presença física de equipes técnicas no próprio cliente) nas dúvidas que poderão surgir no uso do produto e para que o cliente consiga utilizar o novo produto em toda sua potencialidade. O PDP deverá capacitar o pessoal de atendimento para orientações quanto a problemas no uso e manutenção do produto e preparar os manuais e roteiros pertinentes. Em muitos modelos de referência sobre desenvolvimento de produto, em publicações e também em empresas, não há uma divisão clara entre o que é P&D e o que é PDP — sendo esses dois processos muitas vezes considerados em conjunto como algo único. No contexto deste livro, entende-se que existem os dois processos, cada um com uma finalidade específica. Ambos fazem parte de um processo mais amplo, que é o processo de inovação na empresa. O processo de P&D normalmente realiza atividades de pesquisa voltadas para o desenvolvimento ou domínio das tecnologias, isto é, soluções baseadas em fenômenos físicos e químicos voltadas para a solução de problemas bastante específicos. O resultado desse processo é o domínio da tecnologia, isto é, conhecimentos e soluções tecnológicas que serão utilizadas no processo de desenvolvimento de produtos, PDP. Somente as soluções tecnológicas que forem consideradas estáveis e maduras deverão ser incorporadas nos projetos de novos produtos. As soluções tecnológicas fornecidas ao PDP tanto podem ser desenvolvidas a partir de objetivos e planos internos da P&D, como podem ser desenvolvidas a partir de demandas/solicitações do próprio PDP. Essas atividades podem ser realizadas internamente à empresa e ou em parcerias, por exemplo, com instituições de pesquisa e até mesmo de ensino. No caso deste livro, o enfoque é unicamente no Processo de Desenvolvimento de Produtos. O processo de Suprimentos, no sentido do fornecimento de matérias-primas e componentes para a empresa, além de desempenhar o papel de abastecer com bens físicos, também proporciona informações técnicas e coopera nas atividades de desenvolvimento. Os fornecedores podem se responsabilizar pelo desenvolvimento, total ou em conjunto com a empresa cliente, dos projetos necessários para os itens a serem fornecidos. É o caso, por exemplo, do chamado desenvolvimento conjunto (normalmente citado em inglês como co-design), uma forma de desenvolvimento colaborativo que considera as vantagens do envolvimento o mais cedo possível dos fornecedores no projeto do item e até mesmo participando de equipes de projeto da empresa cliente. Quando o processo de desenvolvimento de produto da empresa tem uma proximidade maior com os fornecedores, o fluxo de informações entre os dois processos torna-se mais complexo. Essa relação pode assumir diferentes graus de interação em função do grau em que os fornecedores se responsabilizarem por atividades e partes do desenvolvimento do projeto. As informações de saída do PDP são entradas para o processo de Produção, que, ao final, produzirá os produtos em escala comercial. Porém, o PDP também deve receber informações da Produção, para realizar suas atividades, antecipando-se a problemas na fase de manufatura do produto. O PDP deverá ser informado e levar em consideração as restrições e capacidades de produção existentes na empresa e as disponíveis no mercado de fornecedores. Ou seja, deve incorporar, durante o desenvolvimento, a chamada “voz da fábrica” para assegurar a manufaturabilidade do produto desenvolvido. A Produção também participa do PDP, realizando atividades como elaboração de protótipos de produção, produção piloto, resolução de problemas para passagem da produção piloto para a produção em escala comercial (scale up), ações para melhoria da capabilidade do processo e reduções de custo de processamento do produto. A estrutura da logística de Distribuição da empresa, bem como os canais de distribuição do novo produto no mercado, também deve ter seus requisitos incorporados durante o desenvolvimento — uma vez que são

14

PARTE 1

O Processo

clientes do PDP no que diz respeito, por exemplo, a armazenar, manusear e transportar o produto. No outro sentido do fluxo de informações entre esses dois processos, caberá às equipes do PDP orientar a elaboração de informações, instruções e manuais para a preservação da qualidade na distribuição do novo produto. Em relação ao processo de Assistência Técnica, o PDP deverá orientá-lo sobre as falhas potenciais e prepará-lo para os serviços a serem prestados ao novo produto. No sentido do fluxo de informações da Assistência Técnica para o PDP, esse deverá ser informado sobre os requisitos desse cliente na fase de uso e manutenção do produto, bem como dos problemas que o produto apresenta em campo, para as correções necessárias no projeto. Os dados da Assistência Técnica também são uma importante fonte de informações para futuros projetos de desenvolvimento.

1.6

A importância da gestão do PDP

A demanda por mudanças nos produtos, e nas suas aplicações e usos, tem aumentado muito intensamente, justificando uma preocupação maior com a eficiência e a eficácia do desenvolvimento de produtos. E esse desempenho depende do gerenciamento do PDP. Já no início da década de 1990, gerentes seniores de grandes corporações japonesas, européias e norte-americanas identificaram o desenvolvimento de produtos como uma área de grandes oportunidades para elevar a competitividade das empresas e cujas capacidades necessitavam ser incentivadas e fortalecidas. Apesar da unanimidade sobre a importância do PDP, não são raros os casos de fracassos de desenvolvimento de novos produtos. No início da década de 1990, já podiam ser identificadas grandes empresas multinacionais com efetiva capacidade para desenvolver produtos, enquanto outras se debatiam com os elevados custos alcançados, com a demora no lançamento, com problemas de qualidade ou mesmo com a falta de mercado para o produto desenvolvido. O desenvolvimento deve buscar algo mais do que custo e desempenho técnico do produto. Também são condições desejáveis para a competitividade: a qualidade do produto no atendimento aos diferentes requisitos dos clientes; colocação do produto no mercado o mais rápido possível, para aproveitamento adequado da janela de oportunidades, antecipando-se em relação à concorrência; e, ainda, a manufaturabilidade (facilidade de produzir e montar) do produto e a criação e o fortalecimento, a cada projeto, das capacitações requeridas para o desenvolvimento de produto no futuro. A contribuição do PDP como fonte de vantagens competitivas para as empresas está sendo cada vez mais enfatizada. Estima-se que uma parcela significativa, algo em torno de 85% dos custos do ciclo de vida de um produto, é reflexo da fase de projeto, ou seja, fica determinada em função do que é definido no projeto (tecnologias básicas do produto e do processo, materiais, especificações etc.). Estima-se que são possíveis reduções de mais de 50% no tempo de lançamento de um produto, quando os problemas de projeto são identificados e resolvidos com antecedência, reduzindo o número de alterações posteriores e os tempos de manufatura e de resposta às necessidades do consumidor e, portanto, gerando competitividade. Além disso, é importante considerar e evitar o “efeito escala” do aumento do custo de alteração (mudanças) no produto ao longo dos seus estágios de desenvolvimento (idéia, projeto, protótipo, produção e lançamento): estima-se que o atraso na detecção e correção de problemas, à medida que se avança do projeto para a produção e para o consumo, representa um aumento do custo de alteração (resolução dos problemas), que cresce em progressão geométrica de razão 10 a cada fase. Além da obtenção da qualidade de produto e de processo, o PDP tem forte influência sobre outros fatores de vantagem competitiva, como custo, velocidade e confiabilidade de entrega e flexibilidade. A velocidade de entrega pode ser beneficiada pelo projeto de produtos mais fáceis de produzir e de montar. A confiabilidade de entrega é beneficiada pelo projeto de processos de fabricação dos produtos estáveis, mais fáceis de executar e de controlar. A vantagem em flexibilidade pode ser favorecida pelo PDP que compartilha grande quantidade de componentes e pelo projeto de processos, os quais buscam favorecer o compartilhamento dos equipamentos São muitas as vantagens competitivas que se obtém de um processo de desenvolvimento bem estruturado e gerenciado

CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos

15

de produção. O PDP também tem forte influência sobre a vantagem em custo, uma vez que o custo final do produto tem estreita ligação com o consumo e com o tipo de materiais utilizados na fabricação, que, por sua vez, são dependentes do projeto do produto e do processo. Ao se introduzirem novos produtos antes da concorrência, pode-se tornar o produto um padrão no mercado, pioneiro na inovação e apto para responder rapidamente aos feedbacks dos clientes, assegurando maiores margens de lucratividade. O processo de desenvolvimento de produto basicamente tem seu desempenho avaliado por meio de indicadores associados à qualidade total do produto desenvolvido, aos custos e à produtividade desse processo e ao tempo total de desenvolvimento, e de sua contribuição para a competitividade da empresa em termos de rentabilidade, crescimento, fortalecimento da imagem e participação no mercado. O modo como a empresa desenvolve produtos — ou seja, sua estratégia de produto e como ela organiza e gerencia o desenvolvimento — é que determinará o desempenho do produto no mercado e a velocidade, eficiência e qualidade do processo de desenvolvimento. Isto é, o desempenho do PDP depende de sua gestão (estratégias, organização e gerenciamento). Mas a gestão do PDP é bastante complexa em razão da natureza dinâmica desA gestão do processo de se processo, descrita no Tópico 1.1, à grande interação com as demais atividades e desenvolvimento de funções da empresa e da cadeia de suprimentos, e à quantidade e diversidade das inprodutos é bastante formações de natureza econômica e tecnológica manipuladas durante o processo. complexa As freqüentes mudanças nos requisitos dos clientes, nas tecnologias disponíveis e nas regulamentações que se aplicam aos produtos também contribuem para elevar a complexidade desse processo. A natureza dinâmica do processo diz respeito ao próprio ciclo iterativo de Projetar-Construir-Testar-Otimizar, presente nas atividades típicas de desenvolvimento, envolvendo constantes alterações e, também, interações entre as etapas. Assim, do ponto de vista gerencial, representa um grande desafio lidar com as incertezas, mudanças e complexidades, as quais dificultam, inclusive, a visualização do processo de forma sistêmica. Um processo eficaz e eficiente de desenvolvimento de produtos não é algo fácil de conseguir. Muitas empresas podem ter sucessos eventuais com um ou outro produto, mas são poucas as que alcançam êxito por meio de um processo de desenvolvimento eficiente de forma sustentada e conduzido de modo planejado e articulado com as estratégias competitivas da empresa. O que distingue as empresas com excelência em desenvolvimento de produtos Qual o diferencial das é o padrão de coerência e consistência em todo o processo de desenvolvimento, inempresas com excelência cluindo a estratégia, a estrutura organizacional, a sistematização das atividades, as em desenvolvimento de habilidades técnicas, as abordagens para resolução de problemas, os mecanismos de produtos? aprendizagem e o tipo de cultura dominante. De modo geral, pode-se argumentar que a consistência nas diversas dimensões de desempenho do produto desenvolvido (desempenho técnico, qualidade, custo, prazo de lançamento etc.) seria conseqüência da consistência na organização e no gerenciamento do desenvolvimento do produto. Acima de tudo, é necessário que se tenha uma adequada estratégia de desenvolUma adequada estratégia vimento. Essa estratégia representa um caminho para se criar uma estrutura capaz de desenvolvimento... de reduzir problemas típicos, como a falta de envolvimento da alta administração nas decisões do desenvolvimento de produtos, especialmente nas suas primeiras etapas, e a falta de sintonia entre o plano de negócios da empresa e os projetos em curso ou a serem iniciados. Por causa desse descompasso, importantes aspectos de marketing e de estratégia tecnológica, por exemplo, tendem a surgir apenas após os projetos estarem em andamento, o que torna seu gerenciamento uma tarefa mais complexa. A estratégia de desenvolvimento também trata de traduzir os objetivos do negócio, geralmente mais amplos, em requisitos de caráter detalhados, tais como: tempos para introdução de novos produtos, custos de desenvolvimento, definição de capacidades e de mix produtivo. Essa estratégia compreenderia não apenas uma visão de curto e médio prazos, relacionados à criação de novas gerações de produtos, mas, principalmente, a

16

PARTE 1

O Processo

identificação e o desenvolvimento das capacidades críticas para que a empresa possa continuar tendo um desenvolvimento eficaz no futuro. Assim, a gestão estratégica do PDP segue a orientação estratégica da empresa e, ao mesmo tempo, direciona as decisões em nível operacional do PDP. Já a gestão operacional do PDP ocupa-se do planejamento e controle das atividades rotineiras de desenvolvimento, tais como: o mapeamento dos requisitos dos clientes, dos requisitos do projeto, a definição das especificações do produto e dos materiais, a realização de avaliações, construção dos protótipos, análises de custos e prazos etc. Mas a estratégia de desenvolvimento não é suficiente para o desempenho do ...complementada por um processo, ela deve orientar e ser complementada e operacionalizada por um amplo adequado conjunto de conjunto de abordagens e fatores gerenciais, a serem comentados nos tópicos seabordagens e fatores guintes deste capítulo. gerenciais Resumidamente, as empresas com excelência em desenvolvimento de produtos possuem um modelo para o PDP, o qual apresenta forte consistência em seus elementos e possuem uma gestão estratégica e operacional do desenvolvimento de projetos devidamente articuladas.

1.7

Abordagens para gestão do PDP

A evolução da visão sobre o modo de gerenciamento do processo de desenvolvimento de produto está relacionada à evolução do modo de gestão geral adotado pelas empresas. Após a Primeira Guerra Mundial, os sistemas de produção industrial evoluíram da produção artesanal, caracterizada por elevados custos de produção e ausência de consistência e confiabilidade nos produtos e processos, para um novo sistema de produção em massa, baseado nas técnicas de Henry Ford. Os princípios da administração científica, de divisão de tarefas, busca pela maComo o PDP era visto neira ótima e das pessoas certas, bem como a estruturação funcional das organizaantes: Desenvolvimento ções, “moldaram” o surgimento da função de desenvolvimento de produtos nas de Produtos Seqüencial organizações. Como resultado, viu-se a criação do que hoje se chama Engenharia Tradicional ou Desenvolvimento de Produtos Seqüencial, no qual as tarefas re1 lacionadas ao projeto eram atribuídas a um número exagerado de áreas funcionais excessivamente especializadas e constituídas por técnicos com domínio específico na área funcional. Esse modelo de desenvolvimento é chamado de seqüencial porque as informações sobre o produto eram definidas em uma ordem lógica de uma área funcional para outra — primeiro Marketing, depois Design, Engenharia, Produção etc. O projeto “caminhava” entre elas, e cada uma se limitava a receber uma determinada informação, realizar o trabalho e produzir o resultado que dela se esperava. Não havia, portanto, uma interação forte entre elas durante e depois da realização das atividades. As atividades e procedimentos para o gerenciamento eram informais, baseados na experiência das pessoas e diferiam entre as áreas funcionais, que criavam culturas e padrões de trabalho próprios. No fundo, era como se houvesse uma premissa de que a excelência em desenvolvimento de produto dependesse única e exclusivamente da excelência em cada Características do uma das áreas de especialização. Desenvolvimento de Produtos Seqüencial Essa visão tradicional de desenvolvimento de produto apresenta as seguintes características: n

n

1

As áreas de P&D e de Desenvolvimento de Produtos (DP) tendem a ser mais isoladas do restante da empresa e não integradas à estratégia geral do negócio. Apresentam uma cultura, linguagem e compreensão dos problemas próprios. Existem barreiras organizacionais e de comunicação significativas entre essas áreas e o restante da empresa.

Por exemplo, na indústria automobilística, era comum encontrar: marketing, gerência, design, engenharia avançada, engenharia detalhada, engenharia de processo de fabricação, prototipagem e assim por diante, sendo que, ainda, havia segmentações dentro delas. Nas áreas de engenharia, havia, por exemplo: Engenharia de Chassis, Motor, entre outras. (Fonte: WOMACK, JONES e ROSS, 1992.)

CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos

n n

n

n

n

17

A alta administração participa pouco das principais definições das metas de P&D e do DP. Predomina a hierarquia e a linearidade no fluxo de informações e das atividades entre P&D, Engenharia de Produto e de Processo, Produção, Vendas, Assistência Técnica etc., que são vistas como seqüenciais e sem que uma interaja com as demais. Os fornecedores somente são envolvidos nas fases finais do desenvolvimento, com a empresa procurando ser excessivamente auto-suficiente. As atividades de P&D e de DP são consideradas como um conjunto de atividades de risco e, portanto, de difícil mensuração e controle. Assim na área havia uma forte resistência a controles e à contabilidade de custos e análise do retorno de investimentos. Os profissionais da área eram especializados, com a promoção na carreira sendo essencialmente vertical e sem mobilidade horizontal para outras áreas, valorizando o aprofundamento e isolamento do conhecimento.

Como resultado, havia uma grande dificuldade de compreensão mútua entre as Deficiências do áreas, e a coordenação do projeto era prejudicada. Quando surgiam problemas, Desenvolvimento de eram comuns os embates entre áreas funcionais, os quais aumentavam a turbulência Produtos Seqüencial e não contribuíam para a solução. Nessa época, começou a surgir o papel do gerente de projeto, que deveria se preocupar com o projeto como um todo e servir como facilitador na transição do projeto pelas áreas. Mas, na maioria dos casos, seu poder e influência eram limitados e bem menores que os gerentes funcionais, os quais podiam tomar a decisão final, muitas vezes priorizando a otimização dos esforços e aspectos relacionados à sua função. As barreiras culturais aprofundavam esse problema. Os valores, procedimentos e padrões de cada área dificultavam a integração, criando diferentes ambientes na empresa. Assim, os colaboradores não tinham conhecimento de como o processo de desenvolvimento ocorria e possuíam pouca informação do andamento do projeto. Eles tinham acesso somente à atividade sob sua responsabilidade, em alguns casos sem saber o porquê dos prazos, com poucas informações sobre o projeto e sem nem mesmo conhecimento de como aqueles resultados seriam utilizados. A superespecialização das áreas contribuía para que as decisões de projeto fossem tomadas de um ponto de vista restrito a um domínio de conhecimento da área. Por exemplo, um pesquisador norte-americano relata ter encontrado, no início da década de 1990, um projetista de uma montadora que, apesar de possuir vários anos de experiência no projeto de travas de automóveis, não tinha contato com o engenheiro responsável pelo desenvol2 vimento do processo de fabricação das mesmas travas. Trata-se de uma situação claramente inadequada, pois a troca de experiências seria fundamental para que o projetista tivesse um conhecimento melhor do projeto e pudesse projetar peças mais fáceis de serem fabricadas. Outra característica desse modelo é o fato de os departamentos de engenharia serem totalmente auto-suficientes. O projeto era realizado quase inteiramente por profissionais da mesma empresa, incluindo as peças que seriam produzidas por fornecedores externos. Isso prejudicava a manufaturabilidade do produto, o tempo de desenvolvimento e a atualização tecnológica. Por exemplo, enquanto empresas japonesas utilizando abordagens mais recentes de desenvolvimento empregavam em média 485 pessoas em uma equipe de projeto (as mais evoluídas, 333), as montadoras norte-americanas com desenvolvimento de produtos clássico empregavam 900, e havia montadoras alemãs que alocavam em média 1.500 engenheiros. Não que o trabalho fosse menor; a questão é que, no primeiro caso, há uma participação efetiva no projeto por parte das empresas fornecedoras e parceiras. No início da produção em massa, essas deficiências não eram tão prejudiciais como agora, pois o ciclo de vida dos produtos era maior, o produto ficava mais tempo no mercado e a concorrência era menor. À medida que o padrão competitivo avançou no sentido de exigir vários projetos concorrentes, com qualidade, tempo e custo, essas deficiências foram logo notadas. Assim, ao longo dos anos, diversos aperfeiçoamentos foram incorporados 2

WOMACK, JONES e ROSS, 1992.

18

PARTE 1

O Processo

nessa abordagem, buscando melhorar sua eficiência, mas sempre mantendo a mesma visão de um Desenvolvimento de Produtos Seqüencial. O primeiro passo nessa solução foi a busca de uma excelência funcional, ou A abordagem das seja, da excelência dentro de cada departamento, porém ainda sem uma excelência Metodologias de Projeto entre as funções. Um marco importante para o desenvolvimento de produtos, dentro dessa visão, foi a proposição e a difusão das chamadas Metodologias de Projeto. A proposta era encontrar a seqüência de etapas e atividades considerada mais racional para se desenvolver um produto. Nessa abordagem, o modo de gerenciamento é o funcional, em que cada departamento ou setor da empresa tem sua especialidade e realiza as atividades de desenvolvimento que lhe são pertinentes e as transferem a outro departamento. Não há a visão de um processo que integre as diversas atividades, do conjunto de áreas funcionais, que são necessárias para o desenvolvimento de um produto. Não há uma visão compartilhada do ciclo de vida do produto. Mas a complexidade e o dinamismo dos ambientes econômico, tecnológico, A abordagem da social e de regulamentação foram aumentando ao longo dos anos, com destaque Engenharia Simultânea para o aumento da diversidade de produtos, maior valorização do atendimento a prazos, maior pressão de custos, maior regulamentação socioambiental, aceleração da taxa de inovação tecnológica, clientes mais exigentes etc. A intensificação dessas exigências, no final dos anos 1980, levou ao surgimento de diversas propostas de mudanças maiores na visão de como desenvolver produtos, as quais resultaram em uma transformação significativa na gestão do PDP em um período curto de espaço de tempo. Essa abordagem tornou-se amplamente co3 nhecida como o movimento da Engenharia Simultânea . Foram muitas as inovações advindas desse movimento. Uma das mais significativas diz respeito à estrutura organizacional. Ele deu início à utilização de times multifuncionais de projeto, encabeçados por um gerente de projeto peso pesado, isto é, um gerente com poderes superiores ao dos gerentes funcionais. Era a descoberta das vantagens da Estrutura Matricial Forte. Essa abordagem ampliou a integração, propondo a participação de clientes e fornecedores no processo de desenvolvimento e, principalmente, mostrando as vantagens da realização de atividades simultâneas. As empresas e teóricos da época demonstraram que esse tipo de estratégia, só possível com uma integração maior entre as áreas funcionais, promovia a diminuição do tempo de desenvolvimento, de custo e, ainda, aumentava a qualidade. Esse movimento ajudou também a difundir a importância de utilizar técnicas sistemáticas de projeto para aumentar a produtividade do trabalho da engenharia e diminuir erros. Foram os primeiros autores a colecionar essas técnicas, classificá-las, geralmente em filosofias, técnicas e métodos, e a tentar entender a relação entre elas. Foi nesse momento que muitas das técnicas que serão apresentadas no decorrer deste livro (tais como: o Quality Function Deployment — QFD, Desdobramento da Função Qualidade —; a matriz de seleção de Pugh; a Failure Modes and Effects Analysis — FMEA, Análise dos Modos de Falha e Seus Efeitos —; e a Análise do Valor) foram sistematizadas e propostas para trabalhar conjuntamente. A abordagem da Engenharia Simultânea foi muito difundida, e saltos significaA abordagem do Funil de tivos de desempenho foram obtidos, mas outras melhorias importantes viriam logo Desenvolvimento em seguida, na metade dos anos 1990. Sem dúvida, uma das mais importantes foi a adoção da abordagem de processo de negócio. Até então, mesmo os teóricos da Engenharia Simultânea consideravam apenas as áreas funcionais, cujas atividades eram integradas e coordenadas por meio dos trabalhos dos times, gerentes de projeto e as técnicas. Com a adoção da visão por processos, a integração entre as atividades ficou ainda mais evidente, pois os profissionais de DP começaram a entender a relação entre atividades antes consideradas muito distantes, tais 3

Outra abordagem famosa nessa época foi chamada de Total Design, originada para se contrapor à abordagem tradicional por esses autores, que foi denominada Partial Design, ou projeto quebrado em pedaços, das estruturas funcionais. Aqui, esses foram considerados dentro do rótulo da Engenharia Simultânea por motivo de simplificação.

CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos

19

como: a criação da tecnologia e seu uso, a relação entre a retirada do produto do mercado e a obtenção de idéias para os novos produtos e assim por diante. Outra grande contribuição foi a descoberta da importância do alinhamento entre as atividades do PDP e o Planejamento Estratégico da Empresa, considerando a estratégia mercadológica, a estratégia de produtos e a estratégia tecnológica. Ambas as inovações foram consolidadas na proposta da Estrutura Estratégica para Desenvolvimento de Produtos, conhecida como Funil de Desenvolvimento, de Clark & Whelwright. Os teóricos dessa abordagem passaram a estudar o desenvolvimento de produtos como um processo, e propuseram um modelo de processo que integrava o planejamento estratégico de mercado e negócio com as atividades de desenvolvimento de produto. O PDP começava pelo planejamento de um conjunto de projetos (o portfólio de produtos) e, por meio de um processo de negócio disciplinado, com fases e avaliações, somente os produtos com maior probabilidade de sucesso chegavam ao mercado, garantindo eficácia e atendimento às metas da estratégia competitiva da empresa. Outro aspecto dessa ligação com a estratégia é que ela permitiu uma forma sistemática de criar novos produtos que compartilhem componentes-chave, mas cujas características e funções assegurem o atendimento diferenciado de um segmento bem específico de clientes. Isso permite atender melhor os clientes, criando soluções diferenciadas, dentro de um custo de manufatura e desenvolvimento viável. Portanto, a necessidade de integração e de coordenação das atividades de desenvolvimento levou à visão de um processo de negócio, o Processo de Desenvolvimento de Produtos, com ênfase para a sua estruturação e gestão. Consolidou-se, assim, o conceito de gestão do PDP da forma como pensamos atualmente — como um dos processos essenciais para o desempenho empresarial. Embora as primeiras definições de desenvolvimento de produtos como um A abordagem processo tenham surgido entre o começo e a metade dos anos 1990, somente no fiStage-Gates nal dessa década é que elas passaram a ser bem difundidos nas empresas de excelência em desenvolvimento de produtos. O legado do desenvolvimento de produtos seqüencial ainda era muito forte. Durante esse tempo, porém, a teoria de desenvolvimento de produtos passou a adotar rapidamente a visão por processos, e, com isso, várias abordagens para desenvolvimento de produtos surgiram, descrevendo-o sistematicamente e mostrando a relação entre técnicas e métodos anteriormente conhecidos. Com pequenas variações, pode-se considerar que elas adotavam os mesmos princípios citados até o 4 momento. A principal diferença era a quantidade de técnicas e áreas do conhecimento consideradas no processo. Uma delas, porém, merece ser citada, porque contribuiu para identificar a importância e mostrar como implementar uma disciplina sistemática de avaliação e transição de fases, integrada com o processo decisório de planejamento estratégico — a abordagem proposta por Cooper e denominada, em inglês, de Stage-Gates. O foco principal do seu modelo era um processo sistemático de decisão, que garantia não apenas o desempenho e a qualidade do desenvolvimento, mas permitia que essa escolha levasse em consideração o andamento de todos os projetos e as mudanças no ambiente. Essa integração fortalece ainda mais o impacto do desenvolvimento na estratégia de produtos. As abordagens da Engenharia Simultânea, Funil e Stage-Gates se desenvolA era do Desenvolvimento veram quase simultaneamente, no período de tempo entre o final dos anos 1980 e fiIntegrado do Produto nal dos anos 1990, comungam várias características e influenciaram uma às outras. Juntas, podem ser rotuladas como a era do Desenvolvimento Integrado do Produto, como uma evolução da era inicial que poderia ser denominada como era do Desenvolvimento Seqüencial. As abordagens do Desenvolvimento Integrado do Produto apresentam as seguintes características: n n n

4

O desenvolvimento de produtos é visto como um processo. A P&D e o DP são inseridos na estratégia geral da empresa e de sua cultura. O uso de projetos plataforma e modularizados para criar grande variedade de produtos, atendendo aos diferentes segmentos, com baixo investimento

Basta ver as abordagens de EPPINGER, BAXTER e vários outros autores.

20

PARTE 1

n

n n

n n

n

n

n

n

n

O Processo

O desenvolvimento de tecnologias e de produtos é visto como fundamental para a estratégia e a capacidade competitiva da empresa, e faz parte das preocupações maiores da alta administração. Há simultaneidade e superposição de informações e de atividades. Há maior capacidade e intensidade de comunicação entre os setores e departamentos, possibilitando formas de trabalho em grupo. Os projetos são conduzidos por meio de times de desenvolvimento multifuncionais. Os fornecedores são envolvidos desde o início do desenvolvimento e há mais facilidade de fazer alianças estratégicas para o projeto. Os projetos são constantemente submetidos à revisão e avaliação técnica e de custos, bem como de seu alinhamento com as estratégias de marketing e de produto. Os recursos aplicados no DP devem ser justificados pelas necessidades e são controlados e avaliados constantemente. Os profissionais tendem a ser mais generalistas; na carreira, há promoção tanto vertical quanto horizontal e há muita mobilidade de pessoal internamente para áreas externas, para outras áreas da organização. O treinamento e a seleção de pessoal reforçam os atributos mais gerais, como a capacidade de trabalhar em grupo. A visão ampla é tão importante quanto a especialidade ou a competência técnica. O estímulo à participação das áreas envolvidas ocorre em todas as fases dos projetos de desenvolvimento, mas, particularmente no início, ela é fundamental para que haja consenso sobre os parâmetros básicos dos projetos, evitando divergências posteriores. Desse modo, tomadas as decisões básicas de modo consensual, o projeto pode transcorrer de forma mais fluida e sem divergências

A ênfase em equipes de desenvolvimento multifuncionais com forte liderança e com participação ativa de especialistas de diversas áreas funcionais resultou em um salto significativo na produtividade do desenvolvimento, na qualidade dos produtos e na rapidez das respostas às exigências dos consumidores (diminuição do lead time). Algumas vantagens competitivas obtidas são a maior capacidade de projetar e produzir uma maior variedade de produtos, atingindo diferentes segmentos do mercado, e a obtenção de uma maior taxa de renovação de produtos, mantendo-os mais atualizados do que a concorrência. Um dos desafios para a excelência em desenvolvimento de produtos é a efetiva Entre os atuais desafios: a utilização das melhores práticas consolidadas na era do Desenvolvimento Integrado efetiva implementação da de Produtos. Embora esses conceitos tenham quase uma década, ainda é raro enconabordagem de trar empresas com altos níveis de evolução de disciplina de processo em todos os asDesenvolvimento pectos citados, isto é, capazes de colocarem as melhores práticas em funcionamento. Integrado de Produtos... O que se vê é uma pequena parte implantada completamente, enquanto outras estão parcialmente presentes, além da existência de práticas e características importantes ainda não utilizadas. Um dos desafios é a complexidade em gerenciar tais mudanças, algo que as abordagens da era do Desenvolvimento Integrado de Produtos não exploram de maneira efetiva. Trata-se de uma fronteira que está sendo desbravada pelos modelos de desenvolvimento de produtos mais recentes. Atualmente, é cada vez mais comum as empresas atuarem na forma de con...e a complexidade do sórcio e de desenvolvimento de um conjunto de projetos ao mesmo tempo (multiambiente do projetos), os quais são muitas vezes desenvolvidos e manufaturados em unidades de desenvolvimento continua produção diferentes (multiplantas) espalhadas pelo mundo, conforme é usual enaumentando: o contrar nas empresas transnacionais. desenvolvimento de multiprojetos em Os desafios dessa “globalização” dos projetos, aliados às estratégias das emmultiplantas presas transnacionais e aos novos recursos de comunicação, fazem com que o desenvolvimento aconteça em uma rede complexa de empresas e cadeias de produção. Nesse caso, a eficácia e a eficiência do desenvolvimento devem ser buscadas de forma sistêmica, em todo o conVantagens das abordagens de Desenvolvimento Integrado de Produtos

CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos

21

junto de projetos e na rede de empresas. Não basta ser eficiente em um projeto de desenvolvimento isolado; o que importa é o desempenho do conjunto de projetos. Portanto, os desafios de integração, comunicação e compatibilidade das decisões será ainda maior nas próximas décadas. Os projetos de desenvolvimento de produtos tenderam a ser maiores e mais complexos, uma vez que o desenvolvimento envolve um número maior, mais diversificado e disperso de atores participantes. Nesse contexto, é possível identificar abordagens recentes que têm proposto Novas abordagens mudanças significativas em comparação com as da era do Desenvolvimento Intepara o PDP grado de Produtos. Elas são mais recentes e, portanto, ainda faltam pesquisas sistemáticas que permitam diferenciá-las claramente das anteriores. Arriscaremos tecer algumas considerações sobre elas, as quais, no momento, são as novas fronteiras de estudo do PDP e, por isso, não estão tão consolidadas quanto as práticas das abordagens das eras anteriores. Para efeito de classificação, elas serão agrupadas sob o rótulo de Abordagens Recentes ou, simplesmente, Novas Abordagens para o PDP. Uma das abordagens muito citadas pela literatura é a do Desenvolvimento O desenvolvimento Lean Lean. À primeira vista, não parece se diferenciar muito do Desenvolvimento Integrado de Produtos. Inclui as mesmas práticas. Uma das contribuições de destaque está na proposta de uma visão mais orgânica do processo, que deve ser atingida por meio da máxima simplificação e diminuição da formalização do processo (pois são atividades que não agregam valor) e de uma valorização dos trabalhos dos times, com um foco nas atividades de prototipagem e testes. A idéia é valorizar ao máximo a experimentação e a aprendizagem. O gerente de projeto não é visto apenas como um coordenador e motivador, ele é também um dos orientados, no sentido acadêmico do termo, que orienta (tutoria) o processo de aprendizagem dos engenheiros e técnicos sob sua supervisão, em busca de uma inovação constante. Nesse ponto, tal teoria “se toca” com a valorização da aprendizagem organizacional e gestão do conhecimento. Nas abordagens de Desenvolvimento Integrado, esse aspecto do trabalho em times não era valorizado. A segunda contribuição é a idéia de retardar ao máximo as decisões de detalhes muito específicos, como tolerâncias, os quais serão otimizados nas etapas finais do projeto. Prega-se que o tempo despendido antecipadamente nesses detalhamentos seja investido em busca de alternativas de soluções e entendimento do problema de projeto. Essa é outra abordagem fruto da aplicação de conceitos criados para a manufaA abordagem do Design tura e que também prega as mesmas características que as abordagens da era do DeFor Six Sigma (DFSS) senvolvimento Integrado de Produtos. A diferença fundamental é o foco na integração de necessidades dos clientes, requisitos de produto, especificações e tolerâncias por meio do uso de otimização, por meio de ferramentas estatísticas e de simulação. No processo de desenvolvimento de produtos, os teóricos dessa abordagem descrevem em detalhes as atividades de desdobramento dos requisitos em especificações e tolerância. Trata-se de uma abordagem que prega a aplicação intensa de técnicas estatísticas, instrumentação digital de ensaios e simulação computacional de produtos. A grande incógnita é que esse tipo de atividade não é simples e nem mesmo barata. Nas abordagens de Desenvolvimento Integrado de Produtos não havia uma A abordagem dos modelos ênfase na implantação dos processos e menos ainda na melhoria contínua do Prode maturidade cesso de Desenvolvimento de Produtos. Trata-se de modelos estáticos que demonstram o nível mais avançado de prática. O problema é: O que fazer para chegar até aquele nível? Existem novas abordagens para desenvolvimento de produtos que enfatizam esse aspecto. A mais conhecida é o Capability Maturity Model Integration ou CMMI, proposto pela Software Engineering Institute (SEI). Trata-se de um modelo para sistematização do desenvolvimento que, além das atividades e fases, divididas em áreas de conhecimento, fornece níveis de maturidade em termos de práticas e indicadores capazes de medir esses níveis. É uma ótima inovação em abordagens para melhorar o Desenvolvimento de Produto, pois parte-se do princípio que nem todas as empresas precisam estar no nível mais alto de excelência, inclusive porque permanecer em um nível maior significa onerar os produtos com custos para melhoria e sistematização do processo, os quais podem não se reverter em benefícios.

22

PARTE 1

O Processo

Com os indicadores e níveis, os responsáveis pelo desenvolvimento podem facilmente identificar o nível de prática da empresa e planejar um nível adequado a ser atingido. Aí, pode-se focar os esforços nas práticas que contribuam para atingir aquele nível. Correremos o risco de citar aqui uma abordagem que, embora possa ser consiA abordagem do derada gerencial, tem suas origens no domínio da tecnologia de informação: Gestão Gerenciamento do Ciclo do Ciclo de Vida de Produtos. Como decorrência da evolução dos Sistemas Intede Vida de Produtos grados de Gestão Empresarial (ERP – Enterprise Resource Planing), vêm sendo criadas soluções corporativas complexas e sofisticadas que permitem transformar em realidade o sonho de qualquer gerente de projeto: navegar no conjunto complexo de dados e documentos e se comunicar com todos os envolvidos no projeto. Essas ferramentas, denominadas Sistemas para Gestão do Ciclo de Vida de Produtos, poderão também ser integradas com as ferramentas de trabalho (por exemplo, as ferramentas CAD 3D, os gerenciadores de documentos e os sistemas de gestão de projetos). A contribuição dessa abordagem é uma integração de dados e atividades muito mais elevada do que se podia pensar na era do Desenvolvimento Integrado de Produtos. Afinal, a integração que se buscava entre as áreas funcionais mais ligadas à engenharia e dentro de um mesmo projeto poderá evoluir para uma integração entre projetos distintos e com interações em tempo real com áreas da manufatura e de finanças. Estamos falando de funcionalidades, tais como: gerenciamento integrado de multiprojetos; desenvolvimento e gerenciamento simultâneo de dois produtos que compartilham uma mesma arquitetura com os sistemas, apoiando coordenação dessas atividades; cálculos em tempo real dos investimentos realizados no portfólio, medições em tempo real dos indicadores de desempenho do projeto e muitas outras inovações. O gerenciamento integrado de multiprojetos, por exemplo, permite maximizar as chances de a empresa obter um fluxo de novos produtos que cubra diversos segmentos de mercado e faça o melhor uso possível dos investimentos em tecnologia. Essa visão se aplica a muitas empresas que têm mais de um produto e desejam expandir o número de novos produtos de forma rápida e eficiente. Outra grande vantagem dessa abordagem será facilitar o equilíbrio entre o que é ótimo para um projeto individual e o que é ótimo para a empresa como um todo, em termos de especificações, custos e prazos. Essa visão sistêmica de multiprojetos se ajusta mais à realidade atual do que o foco na eficiência de projetos individuais. Assim, o conjunto dos projetos poderá ser coordenado de forma mais sistemática e disciplinada, com uma velocidade maior na tomada de decisões. A Toyota, por exemplo, é reconhecida por criar famílias de produtos bem integrados que compartilham conceitos de projetos, componentes-chave e tecnologias básicas. Resumindo, as características que têm sido propostas pelas abordagens mais Características das novas recentes para o desenvolvimento de produtos são: abordagens para o desenvolvimento de produtos n

n

n

Simplificar a formalização por meio de uma disciplina mais avançada de trabalho em equipe e utilização de ferramentas computacionais sofisticadas. Ênfase na aprendizagem e busca de soluções inovadoras, com ações como: • aumento do investimento de tempo em atividades de avaliação e proposição de novas soluções; • uso intenso de técnicas estatísticas, instrumentação e modelos computacionais, de maneira sistemática no processo de desenvolvimento de produtos — tanto para entender os parâmetros físicos envolvidos na função executada como para otimizar o desempenho do produto; e • foco na gestão do conhecimento. Adoção do conceito de níveis de maturidade para garantir êxito na implantação das abordagens como para garantir sua melhoria contínua. Introdução do conceito de gerenciamento do ciclo de vida de produtos, ampliando o escopo do processo, e fortalecendo a integração interprojetos. n

A Tabela 1.1 apresenta uma síntese dessas eras, abordagens e suas características.

CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos

Tabela 1.1

23

Eras, Abordagens e Suas Características

(continua)

24

PARTE 1

Tabela 1.1

O Processo

Eras, Abordagens e Suas Características (continuação)

CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos

25

A análise de como se encontra e como deveria ser a gestão do PDP de uma emQual a abordagem mais presa deve considerar um contexto amplo, o qual inclui o ambiente competitivo em adequada para a empresa? que ela está inserida e suas demandas, a capacitação e a organização interna da empresa e o desempenho do processo. Ou seja, o desempenho no desenvolvimento, um importante contribuinte para a competitividade da empresa, é determinado pela estratégia de produto da empresa e por suas capacidades técnica e gerencial e, ainda, pela organização no processo como um todo. E esses fatores influenciam uns aos outros. A abordagem para organização do PDP (por exemplo, funcional, integrado, desenvolvimento integrado de multiprojetos etc.) mais adequada à empresa dependerá dessa análise. O relacionamento entre as capacidades da empresa e seu ambiente competitivo é dinâmico. A incerteza e a diversidade do ambiente de mercado, por exemplo, podem mudar o papel do desenvolvimento de produtos na empresa. Para manterem e melhorarem seu desempenho e competitividade, as empresas devem, de forma dinâmica, adaptar suas formas de organização e de gerenciamento do desenvolvimento para modelos mais adequados ao ambiente competitivo e de mercado. A empresa, e as atividades do PDP, devem se adequar ao status estático/dinâmico das inovações no setor industrial em que está inserida, ou seja, caso, no setor, as inovações sejam raras (estático) ou bastante freqüentes (dinâmico). Culturas e práticas adequadas para empresas de um setor estático não funcionarão bem em um setor dinâmico e vice-versa. Os produtos também diferem quanto à complexidade de sua estrutura interna e quanto à complexidade da interface usuário-produto. Para cada tipo de produto, as questões críticas para a gestão do desenvolvimento dependeriam do grau dessas complexidades. Apesar de uma aparente vantagem superior, por exemplo, do desenvolvimento integrado em relação ao desenvolvimento funcional, pode-se dizer que não existe uma única melhor abordagem para todas as empresas e ela depende do contexto. O que funciona bem para determinada empresa e produto não necessariamente funcionará bem para outra. Assim, a abordagem mais adequada à empresa dependerá da análise do ambiente competitivo, das capacitações existentes, do desempenho do PDP, da complexidade do produto e do status estático/dinâmico das inovações no setor. A Associação Americana de Gestão do Desenvolvimento de Produto (PDMA, Product Development Management Association) procura identificar, nos Estados Unidos, os modelos e as práticas de gestão mais comumente presentes nas empresas com sucesso no desenvolvimento de produtos. E isso é feito por meio de pesquisas de 5 campo com levantamento de dados nas empresas, que são atualizadas a cada 5 anos. Investigando a evolução das práticas e do desempenho ao longo dos anos, e quais as suas particularidades nos diferentes setores industriais, a Associação afirma que, sem a manutenção de processos de desenvolvimento freqüentemente atualizados, diante das necessidades do ambiente econômico e tecnológico, as empresas sofrem uma crescente desvantagem competitiva. Tem sido crescente a preocupação das empresas com seus modelos de desenvolvimento e de gestão de projetos, além da própria avaliação do nível de maturidade em que esses modelos de gestão se encontram (veja a Parte 3 deste livro). A estratégia competitiva da empresa direciona a estratégia de desenvolvimento de novos produtos (veja o Capítulo 4) que, por sua vez, influencia os modelos de gestão e as práticas aplicadas no PDP. O modelo de sistematização do PDP Não é possível pensar o PDP e sua gestão como um processo isolado da empreapresentado neste livro sa. As atividades nele realizadas dependem de diversas áreas e processos da empresa pode ser utilizado em e são influenciadas por suas escolhas estratégicas e pelo seu ambiente competitivo. qualquer das abordagens No Capítulo 16, discute-se especificamente essa questão. aqui mencionadas. 5

Veja, por exemplo: GRIFFIN, A. “PDMA research on new product development practices: updating trends and benchmarking best practices.” Journal of Product Innovation Management, Manchester, v. 14, p. 429-458, 1997.

26

PARTE 1

1.8

O Processo

Arranjos organizacionais para o PDP

Para realizarem o desenvolvimento de produtos de forma efetiva, as empresas precisam organizar esse processo e suas equipes eficientemente. Quando, no início do século XX, os primeiros automóveis foram projetados, como na Ford, por exemplo, a organização do desenvolvimento não era uma questão crucial. Mas o alto nível de integração funcional existente naquela época foi se reduzindo com o aumento da diferenciação6 e da especialização departamental nas empresas, e os desafios organizacionais tornaram-se vitais. A organização das atividades de desenvolvimento de produto se refere à forma como os indivíduos que estão trabalhando estão ligados, individualmente ou em grupos, seja formal ou informalmente. As maneiras mais tradicionais de realizar essa ligação organizacional ocorrem por meio do alinhamento de funções ou de projetos, ou ambos. Uma função, no contexto organizacional, é uma área de responsabilidade que usualmente envolve alto grau de especialização de conhecimentos, em termos de formação e experiência. As funções clássicas envolvidas em um PDP são: Marketing, Engenharia e Manufatura. É comum existirem subdivisões dessas funções clássicas, tais como: Estratégia de Produto, Engenharia de Produto, Engenharia Industrial, entre outras. Mesmo estando ligados a uma função pela sua especialização, os indivíduos também podem estar vinculados a um projeto específico, aplicando, nesse contexto, o seu conhecimento. Assim, pode-se identificar duas formas clássicas de organização do PDP: a estrutura funcional e a estrutura autônoma ou por projeto. Na estrutura funcional, a ligação entre os indivíduos acontece primeiro entre aqueles que realizam funções similares. Na estrutura por projeto, essa ligação acontece preferencialmente entre aqueles que estão trabalhando em um mesmo projeto. As figuras 1.5 e 1.6 ilustram esses dois tipos de estruturas no PDP.

6

Figura 1.5

Estrutura funcional.

Figura 1.6

Estrutura por projeto.

Diferenciação pode ser entendida como o fenômeno oposto ao da integração. Uma organização cresce e necessita se diferenciar por meio de departamentos, funções, filiais, passar responsabilidades para fornecedores etc. Assim, à medida que ela se diferencia, a integração tende a ser mais fraca, e a empresa cria mecanismos organizacionais para compensar ou recompor a integração. Esse paradoxo da integração e diferenciação é uma questão clássica da teoria das organizações e brilhantemente tratada por Lawrence & Lorsch (1967). LAWRENCE, P. R.; LORSCH, J. W. “Differentiation and integration in complex organizations.” Administrative Science Quartely, v. 12, n. 1, p. 1-47, 1967.

CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos

27

Essas duas formas não são efetivamente distintas quando observadas na prática, principalmente porque indivíduos de diferentes funções podem estar simultaneamente ligados a sua função especializada e contribuindo em um ou mais projetos. Uma estrutura funcional pode conter indivíduos que participam de projetos específicos. Entretanto, a ligação organizacional forte é baseada na função, tanto pela relação hierárquica quanto pela alocação física. Cada área funcional tem seu próprio espaço físico, seu próprio orçamento, e um gerente cuja origem normalmente é da própria unidade. Por outro lado, os indivíduos de uma estruturação por projeto reportam ao gerente do projeto e não ao responsável pela área funcional de sua origem, e, normalmente, eles compartilham espaço físico relacionado ao projeto, mesmo que também façam parte de um departamento funcional específico. Uma organização tipicamente por projeto pode ser encontrada nos casos de empresas nascentes que estão desenvolvendo seus primeiros produtos, quando o próprio presidente assume o papel de líder. Nos casos de empresas já constituídas, o exemplo mais comum é quando se forma um Tiger Team com recursos dedicados exclusivamente a um projeto específico de vital importância para a empresa. Como esses times ficam dedicados a um projeto, os membros, com freqüência, mudam a cada projeto e ficam praticamente isolados das outras atividades do PDP da empresa, surgindo, então, a questão de como compartilhar o aprendizado de um projeto para outro. Por muito tempo, os projetos de desenvolvimento foram realizados por meio de um desses dois tipos de estrutura. Entretanto, principalmente por causa do aumento da complexidade e dos desafios da integração de tecnologias, surgiu um tipo de organização híbrida que apresenta características da estrutura funcional e da estrutura por projeto. Esse tipo de organização é conhecido por estrutura matricial (Figura 1.7). Figura 1.7

Estrutura matricial.

Na estrutura matricial, os indivíduos estão ligados a outros tanto por meio de suas áreas funcionais quanto por meio de um ou mais projetos. Nesse contexto, o indivíduo normalmente tem dois superiores hierárquicos: um da organização funcional e outro referente ao projeto. Na prática, como fica difícil esse compartilhamento hierárquico, em razão de questões de orçamento, avaliação de desempenho, entre outras, a ligação organizacional tende a ficar mais forte em um dos tipos (projeto ou função). Como conseqüência, surgiram duas variações da estrutura matricial, conhecidas por “Estrutura de Projeto Peso Pesado” e “Estrutura de Projeto Peso Leve”. Em uma estrutura de Projeto Peso Pesado predomina a ligação baseada no projeto. Ela tem a natureza cross-funcional. O gerente do projeto, conhecido por “gerente peso pesado”, tem completa autonomia e autoridade no orçamento e na avaliação do desempenho dos membros de seu time, e, normalmente, toma a maioria das decisões sobre a alocação de recursos para o projeto. Embora cada participante pertença a uma unidade funcional, o gerente funcional tem pouca autoridade e controle sobre ele em comparação com o gerente peso pesado. Em muitas empresas, um Time de Projeto Peso Pesado é conhecido por Time de Desenvolvimento Integrado de Produtos ou simplesmente de Time de Desenvolvimento.

28

PARTE 1

O Processo

A estrutura de Projeto Peso Leve apresenta ligações organizacionais baseadas na função mais forte do que no contexto do projeto. Nesse caso, o gerente do projeto é mais um coordenador ou administrador, não tendo autoridade nem controle sobre os indivíduos, sobre o orçamento do projeto, que normalmente é compartilhado e controlado pelos gerentes funcionais, e sobre a avaliação de pessoal. Suas atribuições básicas estão mais diretamente relacionadas às tarefas operacionais de gestão de projetos. A concepção de times de desenvolvimento — ou seja, do time de trabalho — parece fazer muito mais sentido nas estruturas por projeto ou matricial. A estrutura funcional possui mais as características do trabalho em grupo, isto é, uma ligação mais forte com a empresa como um todo e não com uma tarefa ou projeto específico. Uma variedade de fatores determina como se deve organizar o PDP de uma empresa. A empresa deve avaliar qual o tipo de organização mais adequado para o desenvolvimento de seus projetos. Ela pode, por exemplo, organizar seu PDP baseado em uma organização matricial do tipo peso leve, mas, para os projetos considerados mais estratégicos, é recomendado estruturar uma organização matricial peso pesado. Para os casos de projetos que envolvem alto grau de inovação, ou uma forte natureza de pesquisa e desenvolvimento, a organização de projeto pura pode ser mais adequada. Já para um projeto de atualização ou ajuste do produto, uma organização funcional pode ser suficiente. Obviamente, existem características e limitações que influenciam a decisão por um tipo de organização ou outro — por exemplo, o porte da empresa, a capacidade de integração com detentores de tecnologia externos, entre outros. Mas a importância do projeto, a dinâmica da inovação no ambiente em que ela compete e o tipo de liderança necessária são fatores-chave para a definição. Uma questão importante está relacionada à própria natureza dinâmica do PDP, devendo a empresa continuamente avaliar a necessidade de mudanças organizacionais nesse processo, procurando buscar pontos que fortalecem o desenvolvimento de produtos. Por exemplo, a necessidade crescente de operar com vários projetos simultaneamente. Esse foi o caso da Toyota, que promoveu uma mudança na organização do processo de desenvolvimento de produtos para aumentar sua capacidade de coordenação e integração interprojetos. A empresa realizou um projeto de reestruturação organizacional que culminou em uma organização que manteve a força da coordenação e integração cross-funcional da organização peso pesado, e promoveu o aumento de sua capacidade para coordenar vários projetos simultaneamente, como os projetos dos sistemas que compõem os veículos e os projetos dos próprios veículos. Isso se deu por meio da organização de equipes de coordenadores de projetos. As opções quanto ao tipo de organização do PDP não são muitas, mas suas variantes para cada aplicação são inúmeras. As tabelas 1.2 e 1.3 apresentam uma síntese das características de cada tipo de organização para o PDP, podendo ser útil para a tarefa de escolher as combinações mais adequadas para cada caso. Tabela 1.2

Exemplos dos Tipos de Arranjos Organizacionais Organização funcional

Exemplos típicos

Questões principais

Organização matricial Organização de projeto peso leve

Organização de projeto peso pesado

Projetos de customização; projetos do tipo inovação incremental. Projetos de empresas de pequeno porte.

Automóveis tradicionais; projetos de aparelhos eletrônicos. Projetos incrementais com alto grau de complexidade. Projetos derivativos de plataformas existentes.

Projetos de sucesso mais recentes da indústria automobilística. Projetos com alto grau de inovação da indústria eletrônica. Projetos do tipo plataforma.

Como garantir a integração entre as diferentes funções para atingir os objetivos do projeto?

Como determinar e gerenciar o equilíbrio adequado, da equipe, entre a ligação funcional e a do projeto?

Organização por projeto

Projetos de empresas que competem por inovação. Projetos de mudança tecnológica radical. Projetos da indústria aeroespacial Como compartilhar o aprendizado de um projeto para outro?

CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos

Tabela 1.3

29

Características dos Tipos de Arranjos Organizacionais

Tipos de organização

Funcional

Matricial

Características

Peso leve

Por projeto

Peso pesado

PERSPECTIVA DE LIDERANÇA Autoridade do gerente de projeto

Pouca ou Nenhuma

Baixa

Forte

Forte

Alocação do gerente de projeto

Tempo Parcial

Tempo Parcial

Tempo Integral

Tempo Integral

Principais funções desempenhadas pelo gerente de projeto

Técnicas

Técnicas Comunicação

Técnicas Gerenciais Negociação Comunicação

Técnicas Gerenciais Negociação Comunicação

Responsabilidade pela integração entre as áreas funcionais

Gerentes funcionais

Gerente peso leve

Gerente peso pesado

Gerente de projeto

Controle sobre o projeto de desenvolvimento

Compartilhada entre o líder e os gerentes funcionais

Compartilhada

Total pelo gerente do projeto

Total pelo gerente do projeto

entre o líder e os gerentes funcionais

PERSPECTIVA DO GRUPO Participação de pessoal de outros departamentos funcionais alocados ao projeto

Limitada

Limitada

Extensa

Extensa

Comunicação entre o gerente de projeto e os membros da equipe

Indireta

Direta e Indireta

Direta

Direta

PERSPECTIVA DE APRENDIZAGEM Aprendizagem sistêmica

Baixa

Moderada

Grande

Grande

Focada na área

Focada na área

Mais sistêmica

Mais sistêmica

(sobre o projeto como um todo) Criatividade

1.9

Fatores gerenciais que afetam o desempenho do PDP

Os principais fatores gerenciais que afetam o desempenho do PDP são: Integração do PDP com as estratégias de mercado, de produto e de desenvolvimento tecnológico: As estratégias de mercado, de produto e de desenvolvimento tecnológico da empresa devem ser o ponto de partida do PDP, e as atividades realizadas ao longo do PDP devem estar alinhadas a essas estratégias. Isso assegura a realização de um fluxo de projetos adequados do ponto de vista das estratégias competitivas da empresa, a visibilidade da contribuição do PDP para a competitividade da empresa e a articulação e o apoio da alta administração. Planejamento integrado do conjunto de projetos: O conjunto de produtos da empresa não representa unidades isoladas; eles são relacionados e interdependentes, pertencendo a uma mesma família — ou como derivados ou como extensões de linhas de produtos. Conseqüentemente, o mesmo ocorre com o conjunto dos projetos, os quais são interdependentes e relacionados em maior ou menor grau, compartilhando tecnologias básicas, componentes, conceitos, projetos básicos etc. E é preciso gerenciar essa articulação com uma visão sistêmica do conjunto de projetos, buscando-se a otimização do desempenho desse conjunto. Desenvolvimento: Os times, no sentido de uma equipe coesa, integrada e que compartilha uma mesma visão e os objetivos do projeto, são os responsáveis diretos pelo desenvolvimento, ou seja, eles transformam as informações sobre o mercado e sobre as tecnologias em informações para a realização de todas as fases do ciclo de vida do produto. Quanto à composição, há fortes evidências de que a interdisciplinaridade, a existência de um facilitador, e a afinidade entre os seus membros afetam positivamente o desempenho do time. Em muitos casos, o uso de times de projeto relativamente autônomos liderados por gerentes de projeto relativamente fortes (gerentes peso pesado)

30

PARTE 1

O Processo

no relacionamento com os gerentes funcionais e com os clientes e fornecedores possibilita melhores resultados. Para mais informações sobre Times de Projeto, veja o Quadro 1.1 a seguir. Quadro 1.1

Times/Equipes de Desenvolvimento

É comum uma equipe de desenvolvimento ser chamada de “time de projeto” ou “time de desenvolvimento”. O termo “time” provavelmente foi empregado em conseqüência do reconhecimento da necessidade de se ter um grupo mais coeso e engajado nos objetivos do projeto e do processo de desenvolvimento. Experiências mostram que trabalho em times e bom desempenho são inseparáveis. E o processo de desenvolvimento de produtos é um ambiente que requer tanto o trabalho em grupo no contexto de todo o processo como o trabalho em times no desenvolvimento de projetos.

Critérios para se construir um time Pode-se elaborar uma lista de critérios para se constituir um bom time de desenvolvimento, mas, certamente, ela não será completa ao longo do tempo, nem mesmo válida para todos os contextos de desenvolvimento de produtos. Smith e 7 Reinertsen apresentam uma lista de critérios que pode ser útil como guia na constituição de um time de desenvolvimento. Considera-se que, quanto maior o número de critérios da lista um time satisfizer, mais rapidamente ele deve desenvolver os produtos. Os critérios são os seguintes. Time formado por 10 ou menos membros:

• • • • • •

os membros são voluntários para compor o time; os membros trabalham no time desde a concepção até a produção; os membros dedicam-se em tempo integral ao time; os membros reportam-se diretamente ao líder do time; as funções-chave, que incluem Marketing, Engenharia e Produção, estão contidas no time; e

os membros estão fisicamente próximos, facilitando a comunicação e o diálogo. É difícil compor um time que atenda a todos esses critérios. E muitas questões são derivadas da análise dessa lista, tal como qual o tamanho ideal de um time, considerando-se o tamanho da empresa, a complexidade do produto, o prazo de desenvolvimento. Pode-se estimar a necessidade de horas de trabalho em termos de horas-homem, e comparar esse valor com o prazo para concluir o projeto. É importante salientar que times menores mostram-se mais eficientes, e que a dedicação integral agiliza o desenvolvimento, pois os membros gastarão menos tempo em reuniões e mais em tarefas de desenvolvimento em razão da maior facilidade do processo de comunicação.

Tamanho do time e competências necessárias A determinação do tamanho do time por essa maneira é relativamente fácil. Entretanto, vários fatores dificultam a com8 posição de um time. Ulrich e Eppinger destacam três fatores: (1) a necessidade de competências específicas para completar o projeto, sendo que o time não pode ter um profissional tão especializado durante todo o tempo de desenvolvimento; (2) um ou mais membros não podem se desligar de algumas responsabilidades que já possuem, limitando a participação em tempo integral; (3) a quantidade de trabalho não é constante ao longo do desenvolvimento (normalmente ela aumenta), acarretando a necessidade de inclusão de outros profissionais na tentativa de cumprir os prazos. Em relação às competências necessárias para os membros de um time, pode-se destacar três categorias de habilidades que auxiliam na composição do time: competências técnicas e funcionais, habilidades para solução de problemas e tomada de decisões, e habilidades interpessoais. Como um projeto de desenvolvimento de um novo produto envolve muitas incertezas, utilizam-se estimativas, principalmente para tratar as variáveis tempo e custo de desenvolvimento. Também existe a variável qualidade, que, junto com tempo e custo, pode ser utilizada para a realização de uma análise sobre a composição de um time de desenvolvimento. Por exemplo, quando um projeto envolve o uso de novos materiais (como o caso de termoplásticos de engenharia) e ainda não se tem domínio do comportamento da peça tanto na operação do sistema como um todo quanto no próprio processo de fabricação, a qualidade passa a ser uma variável importante para se definir a composição do time. Ou seja, o estudo da funcionalidade para a definição das especificações dimensionais vai requerer estudos especiais sobre durabilidade, confiabilidade

(continua) 7 8

SMITH, P. G.; REINERTSEN, D. G. Developing products in half time. 2. ed. New York: Van Nostrand Reinhold,1998. ULRICH, K. T.; EPPINGER, S. D. Product design and development. 2. ed. Boston: McGraw-Hill, 2000.

CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos

Quadro 1.1

31

Times/Equipes de Desenvolvimento (continuação)

e capacidade de processo, o que leva à inclusão de membros que dominam técnicas e métodos de confiabilidade, projeto de experimentos, capacidade de processo, e o próprio processo de transformação do termoplástico.

Liderança do time O aspecto liderança é um dos principais fatores para que um time tenha êxito. Apesar de o trabalho em time prever a possibilidade de compartilhamento dos papéis da liderança, no caso de projetos de desenvolvimento, a liderança interna pode ser compartilhada, dependendo das fases de desenvolvimento. Porém, a liderança do projeto como um todo deve ser mantida sob um único líder, pois os papéis relacionados à interface com outros setores internos ou externos, e, principalmente, com a alta administração, exigem uma convergência de habilidades em uma única pessoa. A primeira das habilidades de um líder de time de desenvolvimento é a Habilidade de Liderança. O líder deve estar preparado para aproveitar o máximo dos membros do time, e facilitar para que as atividades sejam de fato desenvolvidas como um trabalho em time. Ou seja, mostra que as responsabilidades não são somente individuais, mas também mútuas. A segunda habilidade é a Visão, que está relacionada à capacidade do líder em ter e saber construir uma visão clara do produto e o que determina o seu sucesso. Para isso, sua capacidade de argumentação para testar por meio de questionamento as decisões ao longo do desenvolvimento, e de saber manter o foco nos objetivos do projeto, deve ser superior. Existem outras duas habilidades que também são importantes, porém podem ser consideradas secundárias em relação às duas primeiras. Uma delas é a habilidade técnica, o que leva à necessidade de o líder conhecer as tecnologias que entram na composição do produto para poder entender aspectos técnicos envolvidos no projeto e argumentar com os membros sobre alternativas e interfaces tecnológicas com a fabricação, assistência técnica, entre outras. Os produtos atualmente envolvem vários tipos de tecnologia, e fica difícil, e às vezes arriscado, decidir por um líder pela competência técnica em uma dessas tecnologias. Isso é o que faz essa habilidade ser secundária em relação às habilidades de liderança e de visão. A última habilidade é a de Gerenciamento de Projeto, que está relacionada às atividades típicas de gestão de projetos, como cronograma, recursos, relatórios etc. Essa habilidade é considerada secundária em relação às duas primeiras porque o líder deve ter domínio sobre as atividades e métodos de gestão de projetos para fins de sínteses, análises e tomada de decisões, mas as tarefas mais operacionais podem ser realizadas por outra pessoa.

Recompensa Uma outra questão importante do trabalho em times é a recompensa. Considera-se que recompensar os membros de um time de desenvolvimento é uma boa prática relacionada aos produtos de sucesso. O objetivo de uma sistemática de recompensa não deve ser somente reconhecer o que o time realiza, mas também encorajar outros a fazer o mesmo.

Papel dos líderes e gerentes do projeto: A definição — ou seja, a indicação e o papel desempenhado pelos líderes e gerentes do projeto — é fundamental para o desempenho do time. Os líderes, por exemplo, fazem a ligação do time com a alta administração da empresa e com os administradores das áreas funcionais, gerenciam as atividades do projeto e mantêm a motivação do time. Assim, sua atuação afeta sobremaneira o desempenho do time, por sua capacidade de resolver conflitos, isolar o time de problemas exteriores, e prover os recursos, um bom ambiente de trabalho e uma visão ampla sobre o caminho a ser trilhado pelo time. Envolvimento da cadeia de fornecedores e de clientes: Quanto aos fornecedores, os casos bem-sucedidos evidenciam que o seu envolvimento, o mais cedo possível, diminui o tempo de conclusão do projeto (time to market) e aumenta a produtividade do desenvolvimento, por meio da diminuição da complexidade do projeto e da antecipação da solução de problemas no projeto por parte da equipe de desenvolvimento dos fornecedores. Já com relação aos clientes, considera-se que o seu envolvimento melhora principalmente a adequação do conceito do produto às necessidades dos usuários, ou seja, a qualidade do produto desenvolvido. Integração das áreas funcionais da empresa: Essa integração permite a prevenção e a resolução antecipada de problemas por meio da colaboração e da troca de informações em todas as fases do desenvolvimento, e ainda facilita a abordagem das questões do projeto relativas a interfaces entre os departamentos da empresa. É vastamente reconhecido que a orientação para o mercado, de todos os envolvidos no desenvolvimento, e a integração entre os diversos departamentos envolvidos podem afetar positivamente o desempenho do PDP.

32

PARTE 1

O Processo

Ainda em relação à integração entre as áreas funcionais da empresa e o PDP, uma maior aproximação entre a Pesquisa & Desenvolvimento e as Engenharias de Produto e de Processo tem como conseqüência uma mais rápida introdução de inovações tecnológicas nos novos produtos, resultando em maior confiabilidade do produto final e melhor manufaturabilidade. A integração do PDP com as áreas de Marketing e Produção contribui para reduzir o tempo de desenvolvimento pela proximidade maior com a manufatura e pela orientação decisiva e maior sensibilidade das atividades de desenvolvimento às necessidades do mercado. A integração entre o PDP e outros processos também foi discutida no Tópico 1.5 deste capítulo. Estruturação das etapas e atividades do processo: O PDP, assim como qualquer tipo de processo de negócio, pode ser representado simbólica e formalmente por meio de um modelo de referência, que descreve as atividades, os resultados esperados, os responsáveis, os recursos disponíveis, as ferramentas de suporte e as informações necessárias e ou geradas no processo. Tal modelo serve como um referencial comum na empresa, um guia que auxilia no gerenciamento do processo, por facilitar o entendimento e a comunicação entre os integrantes do desenvolvimento (internos e externos à empresa), e por facilitar a implantação e a integração de métodos, técnicas e sistemas de apoio ao PDP. Em relação a esse fator, a superposição das diferentes atividades funcionais e das fases do desenvolvimento é especialmente importante por facilitar a comunicação e a troca de informações, o mais cedo possível, entre as áreas envolvidas no PDP ao longo do ciclo de vida do produto. Isso permite, por exemplo, a resolução antecipada de problemas e a redução do tempo de desenvolvimento. Esse fator da gestão do PDP é o foco principal deste livro.

1.10 Modelo de referência é essencial para o PDP O desenvolvimento de produto precisa ser um processo eficaz e eficiente para realmente cumprir sua missão de favorecer a competitividade da empresa. O desempenho desse processo depende, fundamentalmente, do modelo geral para sua gestão, o qual, por sua vez, determina a capacidade de as empresas controlarem o processo de desenvolvimento e de aperfeiçoamento dos produtos e de interagirem com o mercado e com as fontes de inovação tecnológica. Por geral, entende-se o modelo que engloba a gestão estratégica, a gestão operacional do desenvolvimento e os ciclos de resolução de problemas, de melhoria e de aprendizagem, considerando-se todo o ciclo de vida do produto. Deve considerar, ainda, as melhores e mais adequadas práticas dos fatores de gestão anteriormente mencionados O núcleo central desse modelo geral, representado pela estruturação das etapas e atividades operacionais do desenvolvimento do projeto, é o foco do modelo de referência apresentado nos capítulos seguintes deste livro. Por eficácia do PDP, entende-se que ele deve apresentar resultados em projetos e produtos, que sejam adequados e competitivos, ou seja que atendam às expectativas do mercado e que estejam devidamente integrados às estratégias da empresa. Por eficiência, entende-se que o processo é capaz de atingir esses resultados utilizando o mínimo possível de recursos, os quais incluem o tempo e os custos para se desenvolver. A formalização do modelo de gestão e de estruturação do desenvolvimento de produto possibilita que todos os envolvidos (alta administração, pessoal das áreas funcionais da empresa e os parceiros) tenham uma visão comum desse processo: o que se espera de resultados do PDP, quais e como as atividades devem ser realizadas, as condições a serem atendidas, as fontes de informação válidas e os critérios de decisão a serem adotados. Assim, tendo em vista a importância do processo de desenvolvimento de produtos, e de se obter bons resultados dele a partir de sua gestão, é fundamental que se adote um modelo de referência, mais adequado às necessidades da empresa, que oriente a estruturação e gestão desse processo.

1.11 Resumo do capítulo O desenvolvimento de produtos é considerado um processo de negócio cada vez mais crítico para a competitividade das empresas, principalmente com a crescente internacionalização dos mercados, aumento da diversidade e variedade de produtos e redução do ciclo de vida dos produtos no mercado. Novos produtos são

CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos

33

demandados e desenvolvidos para atender a segmentos específicos de mercado, incorporar novas tecnologias, se integrar a outros produtos e usos e se adequar a restrições legais. Desenvolver produtos consiste no conjunto de atividades por meio das quais busca-se, a partir das necessidades do mercado e das possibilidades e restrições tecnológicas, e considerando as estratégias competitivas e de produto da empresa, se chegar às especificações de projeto de um produto e de seu processo de produção, para que a manufatura seja capaz de produzi-lo e de acompanhá-lo após seu lançamento. Assim, irão se realizar as eventuais mudanças necessárias nessas especificações, planejar a descontinuidade do produto no mercado e incorporar, no processo de desenvolvimento, as lições aprendidas ao longo do ciclo de vida do produto. Ao longo das últimas décadas, diversos casos bem-sucedidos de empresas e países em termos de desenvolvimento de produtos evidenciaram que o desempenho desse processo depende do modelo e das práticas de gestão adotadas. Ou seja, mesmo sendo um processo com elevado grau de incerteza e baixa previsibilidade de resultados, é possível e necessário gerenciar o PDP, planejando, executando, controlando e melhorando as atividades, em busca de melhores resultados de desempenho e de aprendizagem. O Brasil necessita exportar produtos de maior valor agregado, o que exige uma maior capacitação e esforço no desenvolvimento de produtos, para dispor, para o mercado local, produtos com padrões equivalentes aos importados, e para capacitar o país a exportar produtos de padrão internacional. E isso passa, necessariamente, pela melhoria na qualificação do corpo técnico e gerencial das empresas em gestão do processo de desenvolvimento de produtos. As características desse processo fazem com que sua natureza seja relativamente diferente dos demais processos empresariais, o que condiciona os modelos e as práticas de gestão adequadas ao processo, além do perfil e das capacitações requeridas dos profissionais envolvidos no PDP. Os projetos realizados por uma empresa podem ser classificados em categorias, o que facilita planejar estrategicamente e de forma conjunta todos os projetos de desenvolvimento, os quais possuem relevância e necessidades de recursos que são específicas a cada caso. Com isso, busca-se assegurar a quantidade adequada de recursos para coordenar e executar os vários projetos, conseguir eficiência nas atividades realizadas e obter um padrão adequado de inovação dos produtos da empresa. O desenvolvimento de produto envolve muitas atividades que devem ser executadas por diversos profissionais de diferentes áreas da empresa, tais como: Marketing, Pesquisa & Desenvolvimento, Engenharia do Produto, Suprimentos, Manufatura e Distribuição — cada uma vendo o produto por uma perspectiva diferente, mas de forma complementar. Essa particularidade exige que essas atividades e decisões sejam realizadas em conjunto e de forma integrada, evidenciando a necessidade de se estruturar um processo específico que reúna esse conjunto de atividades a serem planejadas e gerenciadas de forma dedicada. A tomada de decisões sobre o projeto envolvendo pessoas com diferentes visões do produto, ainda na fase de desenvolvimento, pode antecipar problemas e soluções, além de reduzir o tempo de lançamento do produto. Decisões inadequadas tomadas no início do desenvolvimento podem ser difíceis e caras de serem revertidas nas fases em que o produto já se encontra em produção e uso no mercado. Assim, cada vez mais se incorporam a esse processo as estratégias de produto, de mercado e tecnológicas da empresa e as atividades necessárias para suportar a produção, o lançamento e o acompanhamento do produto no mercado e a decisão de sua descontinuidade. Com essas ampliações, obtém-se um processo mais coeso, em que o planejamento e a execução do projeto e o acompanhamento do produto pós-venda estão integrados em uma mesmo processo de negócio. Além de influenciar a qualidade do produto e do processo, o PDP tem forte influência sobre outros fatores de vantagem competitiva como custo, velocidade e confiabilidade de entrega e flexibilidade. Estima-se que são possíveis reduções de mais de 50% no tempo de lançamento de um produto, quando os problemas de projeto são identificados e resolvidos com antecedência. Estima-se, também, que o atraso na detecção e correção de problemas, à medida que se avança do projeto para a produção e para o consumo, representa um aumento do custo de alteração (resolução dos problemas), que cresce em progressão geométrica de razão 10 a cada fase.

34

PARTE 1

O Processo

O processo de desenvolvimento de produtos pode ter seu desempenho avaliado por meio de indicadores associados à qualidade total do produto desenvolvido, aos custos e à produtividade deste processo e ao tempo total de desenvolvimento, e de sua contribuição para a competitividade da empresa em termos de conhecimento tecnológico, rentabilidade, crescimento e participação no mercado. O modo como a empresa desenvolve produtos — ou seja, sua estratégia de produto — e como ela organiza e gerencia o desenvolvimento é que determinará o desempenho do produto no mercado e a velocidade, eficiência e qualidade do processo de desenvolvimento. A análise de como se encontra e como deveria ser a gestão do PDP de uma empresa deve considerar um contexto amplo que inclui o ambiente competitivo em que a empresa está inserida e suas demandas, a capacitação e organização interna da empresa e o desempenho do processo. Ou seja, o desempenho no desenvolvimento, que é um importante contribuinte para a competitividade da empresa, é determinado pela estratégia de produto da empresa e por suas capacidades, técnica e gerencial, e pela organização no processo como um todo. A abordagem para organização do PDP, que pode ser considerada mais adequada à empresa, dependerá dessa análise. Ou seja, para manterem e melhorarem seu desempenho e competitividade, as empresas devem, de forma dinâmica, adaptar suas formas de organização e de gerenciamento do desenvolvimento para modelos mais adequados ao ambiente competitivo e de mercado. As empresas, e as atividades do PDP, devem se adequar ao status (estático ou dinâmico) das inovações no setor industrial em que estão inseridas, ou seja, caso, no setor, as inovações sejam raras (estático) ou bastante freqüentes (dinâmico). Culturas e práticas adequadas para empresas de um setor estático não funcionarão bem em um setor dinâmico e vice-versa. Os produtos também diferem quanto à complexidade de sua estrutura interna e quanto à complexidade da interface usuário-produto. Para cada tipo de produto, as questões críticas para a gestão do desenvolvimento dependeriam do grau dessas complexidades. A organização das equipes de desenvolvimento de produto se refere à forma como os indivíduos que estão trabalhando estão interligados, individualmente ou em grupos, seja formal ou informalmente. As maneiras mais tradicionais de realizar essa ligação organizacional ocorrem por meio do alinhamento de funções ou de projetos, ou ambos. A concepção de times de desenvolvimento, ou seja, do time de trabalho, parece fazer mais sentido nas estruturas por projeto ou matricial. A estrutura funcional possui mais as características do trabalho em grupo, isto é, ela representa uma ligação mais forte com a empresa como um todo e não com uma tarefa ou projeto específico. Os principais fatores gerenciais que afetam o desempenho do PDP são: n n n n n n n

Integração do PDP com as estratégias de mercado, de produto e de desenvolvimento tecnológico. Planejamento integrado do conjunto de projetos. Desenvolvimento de Times de Projeto. Papel dos líderes e gerentes de projeto. Envolvimento da cadeia de fornecedores e de clientes. Integração das áreas funcionais da empresa. Estruturação das etapas e atividades do processo.

O desenvolvimento de produtos deve ser um processo eficaz e eficiente para realmente cumprir sua missão de favorecer a competitividade da empresa. O desempenho desse processo depende, fundamentalmente, do modelo geral para sua gestão — o qual, por sua vez, determina a capacidade de as empresas controlarem o processo de desenvolvimento e de aperfeiçoamento dos produtos e de interagirem com o mercado e com as fontes de inovação tecnológica. A formalização do modelo de gestão e de estruturação do desenvolvimento de produto possibilita que todos os envolvidos (alta administração, pessoal das áreas funcionais da empresa e os parceiros) tenham uma visão comum desse processo: o que se espera de resultados do PDP, quais e como as atividades devem ser realizadas, as condições a serem atendidas, as fontes de informação válidas e os critérios de decisão a serem adotados.

CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos

35

1.12 Questões e atividades didáticas propostas Questões para reflexão 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

O que significa desenvolver produtos? Qual a finalidade e o escopo (abrangência) do PDP? Como o PDP pode contribuir para a capacidade competitiva de uma empresa? Quais as principais características específicas do PDP? Qual a importância de classificar, em categorias, os tipos de projetos de desenvolvimento de uma empresa? Qual a contribuição ou papel, para o PDP, das principais funções ou processos empresariais? Qual a importância, para a empresa, de uma boa gestão estratégica e operacional do PDP? Faça uma síntese e discuta as principais características e diferenças entre as abordagens gerais para gestão do PDP? Quais as principais características, bem como os pontos fortes e fracos, dos arranjos organizacionais para equipes de desenvolvimento? Identifique e explique os principais fatores gerenciais, que afetam o desempenho do PDP, separando os mais estratégicos dos mais operacionais? Por que é importante para uma empresa adotar um modelo de referência para o seu PDP? Quais as conseqüências previsíveis, caso a empresa vá estruturando seu PDP sem seguir um modelo?

Atividades didáticas 1. Vá a uma empresa, identifique e analise o escopo de seu PDP. Ele está adequado? O que estaria faltando ser incluído no PDP da empresa? 2. Discuta com profissionais de empresas, ou com estudantes, das áreas de Marketing e de Manufatura, o que eles entendem por desenvolvimento de produto? Qual a visão que eles têm confrontada com o escopo do PDP apresentado no livro? 3. Quais as categorias de tipos de projeto da empresa visitada? 4. Como se dá, na prática, o relacionamento e a integração do PDP com as áreas de Marketing, Manufatura e de Assistência Técnica da empresa? 5. Qual a estrutura organizacional que a empresa segue para as equipes de projeto? Quais os problemas existentes em relação a ela? Essa estrutura é a mais adequada à empresa? 6. Avalie como se encontra a gestão do PDP em uma empresa, ou seja, faça um diagnóstico dos principais fatores gerenciais que influenciam o desempenho do PDP dessa empresa.

1.13 Informações adicionais BROWN, S. L. & EISENHARDT, K. M. “Product development: past research, present findings, and future directions.” Academy of Management Review, v. 20, n. 2, p. 343-378, abr. 1995. CHRISSIS, M. B.; KONRAD, M.; SHRUM, S. CMMI: Guidelines for process integration and product improvement. SEI, New York: Addsion Wesley, 2003 CLARK, K. B.; FUJIMOTO, T. Product development performance: strategy, organization and management in the world auto industry. Boston-Mass.: HBS Press, 1991. p. 405. CLARK, K. B.; HENDERSON, R. M. “Architectural innovation: the reconfiguration of existing product technologies and the failure of established firms. Administrative Science Quarterly, Cornell, v. 35, p. 9-30, mar. 1990.

36

PARTE 1

O Processo

CLARK, K. B.; WHEELRIGHT, S. C. Managing new product and process development: text and cases. New York: The Free Press, 1993. CLAUSING, D. Total quality development. New York: ASME Press, 1994. COOPER, R. G.; EDGETT S. J.; KLEINSCHMIDT, E. J. Portfolio management for new products. New York: Perseus Books, 1998. CUSUMANO, M.; NOBEOKA, K. Thinking Beyond Lean. New York: Free Press, 1998. GRIFFIN, A. “PDMA research on new product development practices: updating trends and benchmarking best practices.” Journal of Product Innovation Management, Manchester, v. 14, p. 429-458, 1997. ROZENFELD, H.; AMARAL, D. C.; TOLEDO, J. C.; CARVALHO, J. “O processo de desenvolvimento de produtos”, cap. 8, p. 55-64. In: Fábrica do futuro: entenda hoje como sua indústria vai ser amanhã, São Paulo: Editora Banas, 2000. SAREN, M. A. “A classification and review of models of the intra-firm innovation process.” R&D Management, v. 14, n. 1, p. 11-24, 1984. ULRICH, K. T.; EPPINGER, S. D. Product design and development. New York: McGraw-Hill, 1995. p. 284. WARD, A. et al. “Toyota’s principles of set-based concurrent engineering.” Sloan Management Review, v. 40, p. 67-83, 1999. WHEELWRIGHT, S. C.; CLARK, K. B. Leading product development: the senior manager’s guide to creating and shaping the enterprise. New York: Hardcover, 1995.

2.1 2.2 2.3 2.4

2.5

2.6

2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16

Conceitos de modelagem de processos Visão geral do modelo Os papéis principais das pessoas envolvidas no PDP Visão geral da macrofase de pré-desenvolvimento 2.4.1 Por que pré-desenvolvimento? 2.4.2 Conceitos básicos do processo de planejamento estratégico 2.4.3 O início e o fim do pré-desenvolvimento 2.4.4 A importância do pré-desenvolvimento 2.4.5 Pré-desenvolvimento é para todos? Visão geral da macrofase de desenvolvimento 2.5.1 Características das fases do desenvolvimento 2.5.2 O início e o fim do desenvolvimento Visão geral da macrofase de pós-desenvolvimento 2.6.1 Por que pós-desenvolvimento? 2.6.2 O início e o fim do pós-desenvolvimento 2.6.3 Pós-desenvolvimento é para todos? Revisão de fases (gates) Métodos e ferramentas de desenvolvimento de produtos Indicadores de desempenho do PDP Parceiros do desenvolvimento colaborativo de produtos Áreas de conhecimento Gestão do conhecimento do PDP Caracterizando o modelo Resumo do capítulo Questões e atividades didáticas propostas Informações adicionais

2. O Modelo Unificado do PDP O Modelo Unificado do PDP PARTE 1 O Processo

Depois da leitura deste capítulo, você será capaz de: ●

●

●

●

Definir processo de desenvolvimento de produtos. Compreender a importância de utilizar o conceito de processo e modelos de referência para a gestão do desenvolvimento de produtos. Compreender a estrutura de macrofases e fases em que o modelo unificado foi estruturado. Compreender os principais conceitos, importância e resultados principais de cada uma das três macrofases do processo de desenvolvimento do modelo unificado.

38

●

●

●

PARTE 1

O Processo

Compreender alguns conceitos e tendências em desenvolvimento de produto que serviram de base para o modelo unificado. São eles: revisões de fase, métodos e ferramentas de desenvolvimento de produtos, indicadores de desempenho, parceria no desenvolvimento de produto e gestão do conhecimento. Compreender a relação entre as áreas do conhecimento empregadas na gestão do desenvolvimento de produtos e o modelo unificado. Entender algumas características específicas do modelo unificado que devem ser consideradas durante sua adaptação e utilização em casos reais.

Objetivo deste capítulo

Este capítulo apresenta uma visão geral do modelo unificado do Processo de Desenvolvimento de Produtos (PDP) com o objetivo de facilitar a compreensão da segunda parte do livro, que descreve uma visão completa do conteúdo do modelo.

Outro objetivo é apresentar os conceitos necessários ao entendimento das fases descritas na segunda parte deste livro. Começaremos pela definição do que é o modelo de referência unificado. O Capítulo 1 demonstrou a importância de conseguir a integração entre as atividades do PDP, e da sinergia desse processo com os demais processos empresariais, incluindo as empresas fornecedoras e clientes. Mas por que isso é tão difícil de conseguir na prática? Por causa da natureza não estruturada do processo de desenvolvimento de produtos. Um exemplo: imagine que alguém precise saber como é fabricado um automóvel. Embora seja um processo altamente complexo, é bem provável que a pessoa interessada iniciasse sua jornada visitando a linha de montagem. Durante a visita, então, seria possível observar todas as atividades principais para a montagem do veículo — desde a chegada das peças —, entendendo a seqüência em que elas ocorrem. Qualquer pessoa sairia de lá com uma boa noção de quem faz o quê. Isto é, os resultados e o papel de cada departamento, tais como: engenharia de processos, qualidade, logística, contabilidade etc. Imagine, porém, se a mesma solicitação fosse feita para demonstrar o desenvolvimento de um produto. Provavelmente, a pessoa iria para o departamento de engenharia. Ela encontraria um conjunto de funcionários atrás de vários computadores, realizando tarefas diferentes, conversando e, certamente, muitos deles realizando tarefas comuns, como passar um fax ou tomar café. Mas qual o processo de desenvolvimento? Para saber, seria preciso percorrer as estações, observando e tentando montar um quebra-cabeça imaginário, pois não daria para observar as atividades na seqüência correta. O próprio nascimento do produto não seria observável, afinal, provavelmente, os projetos atuais iniciaram meses atrás, a partir de alguma decisão em uma sala da diretoria. Além disso, muitas das atividades são realizadas no chão de fábrica — como o teste de uma máquina —, em outras partes da empresa — como a análise de viabilidade e orçamentos preparados no departamento de compras — ou, ainda, dentro de empresas fornecedoras e clientes. Imagine, também, a diversidade de áreas funcionais e pessoal envolvido. Em projetos de automóveis, por exemplo, caso alguém contabilize todos os profissionais que realizaram alguma tarefa do projeto, esse número pode chegar a milhares de pessoas e apenas poucas centenas farão parte efetiva da empresa responsável pelo projeto. O que é o modelo unificado do PDP?

A dificuldade de descrever como é o processo de desenvolvimento tem reflexos importantes na forma como ele pode ser gerenciado. Como prever, planejar e controlar o trabalho das pessoas uma vez que nem todos têm uma linguagem comum e uma visão mínima do andamento do projeto geral e da contribuição que é esperada para a empresa? Lembre-se de que, quando uma linha de produção pára, todos ficam sabendo, pois a paralisação afeta-os de maneira imediata. Ao contrário, um problema em um processo de desenvolvimento pode aparecer meses ou até mesmo anos após sua ocorrência. O primeiro passo para o gerenciamento eficiente do processo de desenvolvimento de produtos, portanto, é torná-lo “visível” a todos os atores envolvidos. É nesse momento que entra a importância da modelagem de processos de negócio, da qual trataremos detalhadamente neste capítulo. A modelagem de processos é uma área do conhecimento que estuda os métodos e as

CAPÍTULO 2

O Modelo Unificado do PDP

39

ferramentas necessárias para descrever os processos de negócio das empresas. O resultado final é um modelo, isto é, um mapa ou representação, que descreve como é o processo de negócio. No caso deste livro, estaremos abordando exclusivamente o processo (de negócio) de desenvolvimento de produtos (PDP). Portanto, obter um modelo do PDP significa descrever as atividades, recursos, informações, fases, responsabilidades e outras possíveis dimensões do processo. Em uma empresa, estaríamos falando de desenvolver o modelo de referência para essa empresa — aquele modelo que serve de guia para todos os projetos de desenvolvimento de produtos. Aqui, estaremos apresentando um modelo cujo objetivo é apresentar as melhores práticas em desenvolvimento de produtos. O propósito é claramente didático, mas nada impede que uma empresa utilize-o como referência para identificar pontos que poderiam ser melhorados: o modelo unificado. O modelo unificado de desenvolvimento de produtos originou-se da união das Origem do modelo metodologias, estudos de caso, modelos, experiências e melhores práticas desenvolvidas e coletadas nos últimos anos pelas equipes de pesquisadores coordenadas pelos autores, como descrito em detalhes na apresentação do livro. Ele também considera comparações e avaliações realizadas com modelos de referência para PDP de empresas líderes em desenvolvimento de produtos de diversos ramos, em especial metal-mecânico. Versões simplificadas e específicas do modelo já foram validadas em casos práticos, tanto no desenvolvimento de produtos realizado pelos autores deste livro, como, também, na criação de modelos de referência específicos em algumas empresas. O modelo reflete, portanto, o conhecimento e a experiência acumulados pelos autores. O capítulo contém três conjuntos de tópicos apresentados na Figura 2.1. O Conteúdo deste capítulo primeiro contém tópicos com conceitos básicos de modelagem e de desenvolvimento de produtos, fundamentais para que o modelo possa ser compreendido (parte inferior esquerda da figura). Profissionais de empresa ou estudantes já familiarizados com o desenvolvimento de produtos podem “saltar” os dois tópicos que fazem parte desse conjunto. O segundo conjunto é composto por tópicos contendo a descrição completa do modelo, em um nível mais alto de abstração (parte superior da figura), e está dividido em dois subconjuntos. O primeiro apresenta uma síntese de cada macrofase com as atividades, principais documentos e responsabilidades. Serve de leitura introdutória para a descrição detalhada do modelo na Parte 2 deste livro. Complementarmente, há um outro subconjunto de tópicos que trata das características especiais do modelo e que merece a atenção do leitor. Aí estão descritos detalhes considerados importantes e são apresentadas as melhores práticas adotadas na construção do modelo, que transcendem o escopo de apenas uma fase — isto é, são assuntos que dizem respeito a todas as fases. O terceiro subconjunto, composto por apenas um tópico, trata das limitações do modelo e é a discussão sobre suas características visando orientar a aplicação (parte inferior direita da Figura 2.1). Ele é fundamental para que os profissionais e estudantes de pós-graduação interessados em utilizar o modelo possam entender os limites para sua aplicação. Alunos de graduação ou profissionais de empresa interessados em uma visão geral do modelo podem ignorar esse tópico. A disposição dos tópicos foi elaborada conforme uma leitura seqüencial. Uma vez conhecida a organização apresentada na Figura 2.1, você poderá pular ou antecipar itens conforme sua experiência prévia no assunto. O capítulo inicia com a descrição dos conceitos básicos sobre modelagem de empresas. Depois é apresentado um primeiro nível de detalhamento do modelo, sua visão geral. Em seguida, são expostos os papéis citados nas atividades do modelo. As três macrofases são descritas em detalhes, fornecendo um segundo nível de detalhamento do modelo (o terceiro nível de detalhamento está na Parte 2 do livro). Os subitens subseqüentes descrevem conceitos complementares, que ajudarão no entendimento da Parte 2 do livro: o tópico “revisão de fases” descreve a origem e os princípios da avaliação de projetos de desenvolvimento; “parceiros” discute a forma de relacionamento entre empresas de uma mesma cadeia de suprimentos e como elas podem fazer proveito deste livro; “ferramentas e métodos” mostra de que maneira é possível relacioná-las com as atividades e tarefas propostas neste livro; “indicadores de desempenho” discute a necessidade de medir o progresso e os resultados de um projeto de desenvolvimento. O tópico “áreas de conhecimento” mostra que as atividades de cada fase

40

PARTE 1

Figura 2.1

O Processo

Esquema de apresentação do capítulo.

também podem ser agrupadas de uma outra forma, facilitando a sua visualização por pessoas que trabalham em departamentos funcionais e que participaram em times de desenvolvimento de produtos. A gestão de conhecimento é um tema que abrange todos os tópicos anteriores. Nesse tópico, o PDP é comparado a outros tipos de processos, e analisa-se como o modelo deste livro pode contribuir para a criação de uma organização que aprende. Finalmente, o modelo de referência a ser detalhado na Parte 2 do livro é caracterizado, para que o leitor entenda onde e como ele pode ser aplicado. Assim, você poderá estudar a Parte 2 do livro conhecendo o seu potencial e suas limitações, e já se preparando para entender a Parte 3, que trata exclusivamente da aplicação do modelo em casos práticos.

2.1

Conceitos de modelagem de processos

Diferença entre processo e projeto

1

Vamos conhecer alguns aspectos básicos da modelagem de processos para definir o tipo de modelo apresentado neste livro. Até agora, utilizamos os termos processo e projeto de desenvolvimento de produtos sem nos preocuparmos em distingui-los. Convém, então, delimitar esses termos para um melhor entendimento do conteúdo deste livro. Processos de negócio compreendem um conjunto de atividades organizadas entre si visando produzir um bem ou um serviço para um tipo específico de cliente (interno ou externo à empresa). Eles podem representar operações repetitivas da empresa, que normalmente são estruturadas, como no caso dos processos de gestão financeira ou de produção. No entanto, o 1 processo de desenvolvimento de produtos não é tão estruturado , porque cada desenvolvimento de um produto específico pode ser diferente.

Veja uma discussão completa no Tópico 2.12, mais adiante, neste capítulo e um exemplo de comparação entre o PDP e um processo estruturado no Quadro 2.8, também neste capítulo.

CAPÍTULO 2

O Modelo Unificado do PDP

41

Projetos também representam um conjunto de atividades, porém, eles são únicos e temporários, ou seja, possuem início, meio e fim. A Figura 2.2 salienta a diferença entre processo e projeto. Processos possuem objetivos estabelecidos periodicamente. Por exemplo, no processo de produção, pode-se definir que, em um ano, a porcentagem de peças refugadas na fábrica deve diminuir de 3% para 1%. Outro exemplo seria o aumento do retorno financeiro a ser estabelecido como meta do processo de gestão financeira da empresa. Projetos possuem objetivos únicos e específicos a serem atingidos no final de sua realização. No caso de um projeto de desenvolvimento de um produto, as metas normalmente estabelecidas indicam a data de lançamento do produto e o seu custo, entre outras. Figura 2.2

Diferença entre processos e projetos.

Ao documentar e disseminar o PDP de uma empresa, a gerência está definindo Projetos definidos a partir um padrão de como desenvolver os seus produtos. Esse padrão pode ser aplicado de processos de negócios pelas equipes e pelo gerente de cada projeto. Eles adaptarão as práticas descritas no modelo do processo conforme as necessidades do projeto. Com isso, cada projeto de desenvolvimento “beberá na mesma fonte”, havendo, assim, uma linguagem comum e a garantia de que certas práticas e ferramentas serão aplicadas em todos os projetos de desenvolvimento (veja a Figura 2.3). Isso é muito importante porque cada projeto possui tarefas específicas, dependendo de inúmeras variáveis, como a complexidade do produto, grau de inovação, tecnologia etc. O processo de desenvolvimento de produtos sistematizado e documentado permite que as particularidades de cada projeto e equipe de desenvolvimento sejam atendidas e, ao mesmo tempo, garante-se a utilização das melhores práticas de projeto e um linguajar padronizado e único para toda a corporação. Por exemplo, imagine que uma empresa possua na documentação de seu processo 50 atividades freqüentemente utilizadas na realização de um projeto. No início de um novo projeto, pode-se adotar essas 50 atividades e, depois, eliminar algumas que não estão diretamente relacionadas com o produto em questão e, ao mesmo tempo, adicionar outras atividades. Isso aumenta a qualidade e repetibilidade dos projetos de desenvolvimento de produtos. A partir desse momento, o desenvolvimento de um produto particular é gerenciado como um projeto. Para que o processo-padrão de desenvolvimento de produtos possa ser reutiliComo representar o zado por várias pessoas, ele é documentado na forma de um modelo.Um modelo processo? serve para representar a realidade. No caso deste livro, ele representa um processo de desenvolvimento de produtos. Vários autores mostram o desenvolvimento de produtos como uma seqüência de passos, fases, etapas, ou seja, na realidade, eles trazem modelos estruturados de diversas formas. Como os projetos de desenvolvimento são definidos a partir desse modelo, ele é conhecido como modelo de referência.

42

PARTE 1

Figura 2.3

O Processo

Projetos distintos resultantes de um mesmo processo.

Hoje, muitas empresas adotam modelos para definir qual o padrão de trabalho que elas desejam adotar para o desenvolvimento de produtos. Existem modelos de diversos tipos; alguns representam somente quais atividades devem ser realizadas. Outros são mais detalhados e especificam procedimentos, métodos que devem ser adotados, critérios de avaliação, e até conceitos e referências bibliográficas que precisam ser estudadas para que uma pessoa realize uma determinada atividade. Ou seja, o modelo é um documento que pode estar na forma de uma publicação, manual, ou mesmo na in2 tranet de uma empresa. O modelo que estamos apresentando neste livro está formatado como um manual e também está na Internet para facilitar a navegação entre as diversas fases e visões. Cada ator, que participa do desenvolvimento de produtos, enxerga o desenvolModelo apresenta uma vimento de produtos segundo a sua percepção. O pessoal de marketing olha para o visão unificada do processo de desenvolvimento de produtos como um todo, enfatizando as etapas inidesenvolvimento ciais e finais do processo de negócio. Eles enfatizam as avaliações sobre o mercado de produtos e, dentro de um prazo, aguardam os produtos a serem oferecidos, assumindo o processo de desenvolvimento de produtos como parte do processo de marketing. Os engenheiros enxergam o desenvolvimento como um desafio tecnológico a ser vencido, e estão mais preocupados em realizar as atividades técnicas, não possuindo, às vezes, um profundo conhecimento sobre as outras atividades, além de não terem uma maior preocupação com questões de gerenciamento do projeto. Pessoas envolvidas com a produção estão preocupadas com o impacto que vão sofrer com os novos produtos, e procuram garantir a capacidade de entrega, deixando para um segundo plano as avaliações de como produzir. A área financeira não se importa com os aspectos técnicos, mas e somente com a avaliação do retorno monetário que o projeto trará para a empresa. Poucos possuem uma visão do todo, e os gerentes de desenvolvimento, que teoricamente possuem essa visão, não conseguem administrar os conflitos e, às vezes, se perdem na abrangência do projeto. De maneira geral, as empresas não possuem uma visão unificada do processo. Além disso, o desempenho de cada unidade da empresa e a diferença do escopo dos produtos não permitem que se tenha uma visão única do processo de desen2

Existem vários formalismos para a representação de processos de negócios, cuja apresentação fugiria do escopo deste livro. Para visão geral desses formalismos, consultar: VERNADAT, F. B. Enterprise modeling and integration: principles and applications. London: Chapman & Hall, 1996.

CAPÍTULO 2

O Modelo Unificado do PDP

43

volvimento de produtos. Muitas vezes, cada pessoa possui um entendimento próprio do processo e utiliza um vocabulário e formalismo particular para descrevê-lo, advindos da sua área específica. No dia-a-dia, essas limitações acarretam problemas e ineficiências no processo de desenvolvimento de produtos, dificultando a comunicação e integração entre os profissionais e as áreas envolvidas. Modelos de referência surgiram para minimizar essas limitações. Eles descrevem O que são modelos de o processo de desenvolvimento de produto e servem de referência para que empresas e referência? seus profissionais possam desenvolver produtos segundo um ponto de vista comum. Com um modelo de referência, pode-se obter uma visão única do processo de desenvolvimento de produtos, nivelando-se os conhecimentos entre os atores que participam de um desenvolvimento específico. Ele passa a ser um linguajar único na empresa, é um mapa que serve de base para todos (Figura 2.4). Figura 2.4

Modelo de referência como mapa comum na empresa.

Este livro apresenta um modelo de referência genérico, com o objetivo de ser didático, mas ele também pode ser utilizado para a criação de modelos de referência específicos para empresas. Após essa discussão dos conceitos básicos sobre modelagem de processos, vamos apresentar uma visão geral do seu conteúdo e estrutura.

2.2

Visão geral do modelo O modelo deste livro é voltado principalmente para empresas de manufatura de bens de consumo duráveis e de capital. Esse aspecto será analisado em detalhes no Tópico 2.13. O importante agora é notar que ele é dividido em macrofases, subdivididas em fases e atividades. Conforme apresentado na Figura 2.5, as três macrofases são: Pré-Desenvolvimento, Desenvolvimento e Pós-Desenvolvimento. As macrofases de pré- e pós-desenvolvimento são mais genéricas e podem ser utilizadas em outros tipos de empresa com pequenas alterações. A macrofase de desenvolvimento enfatiza os aspectos tecnológicos correspondentes à definição do produto em si, suas características e forma de produção. Portanto, tais atividades são dependentes da tecnologia envolvida no produto.

44

PARTE 1

Figura 2.5

O Processo

Visão geral do modelo de referência adotado neste livro.

O que determina uma fase é a entrega de um conjunto de resultados (deliverables), que, juntos, determinam um novo patamar de evolução do projeto de desenvolvimento. Os resultados criados em cada fase permanecerão “congelados”, a partir do momento em que a fase é finalizada. Por exemplo, ao término da fase de projeto conceitual, um novo nível de evolução é atingido. Será o momento em que uma ou mais possíveis soluções são escolhidas para ser detalhadas. Uma vez avaliadas como satisfatórias e aprovadas, o processo de desenvolvimento muda para um novo patamar: a fase do projeto detalhado. As informações sobre a solução serão “congeladas”, ou seja, todas as pessoas podem acessá-la, mas não modificá-la. Qualquer mudança acontecerá única e exclusivamente por meio de um processo de mudança controlado (como apresentado no Capítulo 13, Tópico 13.1, “Gerenciamento de Mudanças de Engenharia”), o qual garantirá que o impacto da mudança seja verificado e todos os atores que se utilizam daquele resultado sejam comunicados. A avaliação dos resultados da fase serve também como um marco importante de reflexão sobre o andamento do projeto, antecipando problemas e gerando aprendizado para a empresa. Ela deve ser realizada por meio de um processo formalizado conhecido como transição de fase ou gate. Trata-se de uma revisão ampla e minuciosa, considerando a qualidade dos resultados concretos obtidos, a situação do projeto diante do planejado, o impacto dos problemas encontrados e a importância do projeto perante o portfólio completo (veja o conceito ainda neste capítulo, posteriormente, no Tópico 2.7). Caracterização de uma fase do processo de desenvolvimento de produtos

Sobreposição entre atividades de diferentes fases do modelo

Para facilitar a apresentação, as fases são representadas de forma seqüencial, porém, em projetos distintos, certas atividades de uma fase podem ser realizadas dentro de outra fase. Por exemplo, a sobreposição esquematizada na Figura 2.6, entre as fases do projeto conceitual e detalhado, é muito comum nos projetos denominados “derivados”, isto é, em que são desenvolvidos produtos similares a produtos existentes — como acontece, por exemplo, nas reestilizações de modelos de automóveis.

CAPÍTULO 2

O Modelo Unificado do PDP

Figura 2.6

45

Exemplo de sobreposição de atividades nas fases do processo de desenvolvimento de produtos.

Note que a atividade “Desenvolver Plano de Processo para os Componentes”, que no nosso modelo faz parte do projeto detalhado, é iniciada ainda durante a fase de projeto conceitual. Isso é possível pelo fato de o novo produto reutilizar um conjunto grande de peças do produto anterior; dessa forma, o processista já possui conhecimento suficiente do produto para antecipar parte de suas atividades. Ele poderá iniciar seu trabalho antes que a definição completa de todas as características e partes do produto seja concluída. Essa é a característica de paralelismo/simultaneidade, que é capaz de encurtar sobremaneira o tempo de desenvolvimento. Outro exemplo de um produto derivado seria o de uma máquina de lavar, que é desenvolvida utilizando a mesma carcaça, motorização e tambor de máquinas já desenvolvidas. Um novo projeto de desenvolvimento pode envolver a criação de um sistema de controle do ciclo de lavagem, com componentes eletrônicos, software de controle e componentes para admissão e expulsão de água, com o objetivo de diminuir o ciclo de lavagem e aumentar a economia de água. Nesses casos, pode-se efetuar cálculos de simulação da aplicação do produto na fase de projeto conceitual, embora essas sejam atividades típicas da fase de projeto detalhado. Poderia existir, também, um programa de simulação do processo de lavagem, ferramenta típica da fase de projeto detalhado. Se a empresa estivesse desenvolvendo uma nova máquina, sem mexer na tecnologia da lavagem, poderíamos utilizar esse programa na fase de projeto conceitual. Assim, testaríamos as diversas alternativas, verificando se os tempos de lavagem diminuiriam, mantendo-se a sua qualidade. Nesses casos, diminuiríamos o escopo e o tempo de desenvolvimento do projeto detalhado, pois muitas atividades poderiam ser adiantadas e realizadas durante o projeto conceitual. Deve-se ressaltar também uma diferença fundamental entre o pré-desenvolviA fase de Planejamento mento, particularmente a fase de Planejamento Estratégico de Produtos, e as deEstratégico de Produtos mais macrofases e fases. Como já visto, cada desenvolvimento de um produto envolve vários produtos específico torna-se um projeto único. Na Figura 2.7 é mostrado o aspecto da quantidade de produtos relacionada com cada macrofase, explicado nos parágrafos seguintes. Na fase de planejamento estratégico, são consideradas as estratégias de mercado da empresa e também as tecnológicas (veja o Tópico 2.4.2, posteriormente, neste capítulo). O planejamento dos produtos envolve todo o conjunto de produtos da empresa e sua relação com os mercados que se deseja atingir (na Figura 2.7, mercados A, B, C e D). Para cada mercado, define-se um conjunto de produtos (na Figura 2.7, os pontos dentro do quadrado). Esse conjunto é conhecido como portfólio de produtos da empresa, e está intimamente ligado com o planejamento estratégico da empresa, como mostra o Tópico 2.4.2. O portfólio contém os produtos em planejamento, os em desenvolvimento e aqueles que já estão sendo comercializados. O objetivo é manter um conjunto de produtos capaz de atender a todas as necessidades dos clientes.

46

PARTE 1

Figura 2.7

O Processo

Relação das macrofases do modelo e a quantidade de produtos.

Os produtos definidos no portfólio são desenvolvidos por meio de projetos (na Figura 2.7, projetos C1 a C6 para os respectivos produtos C1 a C6 do portfólio voltado ao mercado C). Esses projetos estão em diferentes estágios de desenvolvimento (na Figura 2.7, o projeto C1 está sendo finalizado; o C2 está congelado; o C3 está no meio do desenvolvimento; o C4 está sendo lançado e entrando no mercado; o C5 foi cancelado e o C6 está no início do desenvolvimento). Ou seja, as demais fases do desenvolvimento relacionam-se com um produto em particular por projeto de desenvolvimento: aquele (ou aqueles) que o planejamento estratégico mostrou ser atrativo (ou serem atrativos) o suficiente para a empresa gastar dinheiro no seu desenvolvimento. A quantidade de projetos paralelos depende da capacidade da empresa. Esse é o portfólio de projetos, o qual representa um subconjunto do portfólio de produtos, que também contém os produtos existentes no mercado. Tal conceito é conhecido como “funil” por vários autores. O princípio é que, no início, um número grande de idéias se transforme em um número menor de projetos especificados no portfólio, o qual, por sua vez, gerará um número menor ainda durante o desenvolvimento — pois a capacidade da empresa limita o desenvolvimento paralelo de muitos produtos — e, finalmente, apenas alguns produtos serão lançados; todos eles viáveis e com 3 grande probabilidade de sucesso no mercado. A fase de planejamento do projeto trata do desenvolvimento de um produto em particular do portfólio — 4 em que o escopo do produto e do projeto, os recursos necessários, o tempo e o custo são definidos em detalhes. Se esse planejamento for aprovado, o projeto tem início na macrofase subseqüente. As fases de desenvolvimento são equivalentes às fases de um projeto, cujo término (fechamento do projeto) culmina com o lançamento do produto no mercado. Após o lançamento do produto, inicia-se sua produção e comercialização sob a responsabilidade de outros processos de negócio da empresa, assim como de outras áreas e pessoas. Normalmente, o time de projeto é dissolvido, e seus membros são alocados para outros projetos ou retornam para as suas áreas funcionais. Porém, o processo de desenvolvimento de produtos ainda não terminou, pois é necessário um esforço de acompanhamento do produto durante todo seu ciclo de vida. Durante a fabricação, esse esforço será o de garantir a realiAs demais fases relacionam-se com um produto em particular

3 4

Leia sobre o conceito de funil no Tópico 2.4.2, e observe a Figura 2.12, ambos posteriormente, neste capítulo. Essa é uma visão simplificada do conteúdo do planejamento do projeto. Leia o Capítulo 5 para ter conhecimento sobre o conteúdo completo dessa fase.

CAPÍTULO 2

O Modelo Unificado do PDP

47

zação de mudanças para aprimorá-lo ou reparar defeitos identificados. Esse é o momento de se preocupar com a assistência técnica e o atendimento ao cliente. É aí que surgem oportunidades de melhoria no produto, as quais, por sua vez, devem ser gerenciadas de forma organizada para garantir a integridade das informações durante todo o ciclo de vida do produto. Em seguida, será preciso apoiar a descontinuação do produto, isto é, sua retirada do mercado. Em alguns casos, como bens de consumo duráveis e bens de capital, esse acompanhamento irá se estender enquanto houver clientes utilizando o produto. Veja o exemplo das aeronaves, que necessitam de uma equipe de manutenção e melhorias muitos anos após o término da sua produção, isto é, enquanto existirem produtos sendo utilizados pelas companhias aéreas. Em alguns casos, também, a macrofase de pós-desenvolvimento ficará a cargo de outros responsáveis, mas, no modelo que desenvolvemos, essa macrofase está relacionada com as anteriores, pois acessa e dá manutenção às mesmas informações anteriormente criadas. Além disso, nesse momento, aprende-se muito com o mercado, e essas lições devem ser consideradas pela empresa para não repetir os mesmos erros no futuro. Um outro aspecto a ser destacado é a temporalidade usual dessas fases em um Duração das macrofases ciclo de vida de um produto, como mostra a Figura 2.8. O pré-desenvolvimento leva do modelo dias e pode estar associado ao ciclo do planejamento estratégico das empresas, que normalmente é realizado uma vez por ano. O desenvolvimento em si varia muito de acordo com a complexidade do produto e a novidade que ele representa para a empresa, mas, tipicamente para empresas de manufatura discreta e para os tipos de produtos tratados neste livro, ele leva meses. Figura 2.8

Exemplo da duração típica das macrofases do modelo.

A macrofase de desenvolvimento de uma máquina com novos conceitos, como uma máquina-ferramenta ou mesmo uma nova copiadora, leva de 15 a 30 meses. Já uma máquina desenvolvida com base em uma existente, situa-se entre 6 a 10 meses. Um automóvel tipicamente levava de 36 a 48 meses e hoje leva de 15 a 25 meses. Uma copiadora que seja continuação de uma existente demora de 3 a 6 meses. Finalmente, a fase de pós-desenvolvimento dura até o final da vida do produto. Esse período tem diminuído ultimamente, mas, no setor de máquinas-ferramentas, o período de produção/comercialização dura em média 5 anos. E, depois, as máquinas ainda são utilizadas por anos. No caso do setor automobilístico, um mesmo produto pode ficar no mercado 10 anos, sofrendo pequenas mudanças estéticas e tecnológicas. Mesmo assim, a empresa precisa garantir a assistência técnica por vários anos após o encerramento de sua produção. Na Figura 2.9 estão mencionados os principais resultados produzidos ao final Principais resultados de cada uma das fases do modelo. A fase de planejamento estratégico de produtos, das fases que não consta na figura, resulta em dois documentos principais. Um deles é o portfólio de produtos com a descrição de cada um dos produtos e datas de início de desenvolvimento e lançamento, segundo as perspectivas de mercado e tecnológicas. O segundo é o primeiro documento que diz respeito a um projeto específico e é o primeiro apresentado na Figura 2.9: a Minuta do Projeto. Ela contém a primeira descrição do produto — algo bastante sucinto e que delimita o projeto. Esse documento serve de entrada para a fase de planejamento do projeto, que produzirá um plano detalhado com atividades, prazos, recursos necessários, riscos e uma primeira análise econômico-financeira do projeto, conforme apresentado na Figura 2.9.

48

PARTE 1

Figura 2.9

O Processo

Principais resultados das fases.

A primeira fase de desenvolvimento, o projeto informacional, cria, a partir do Plano do Projeto, as Especificações-Meta do futuro produto, que são aquelas que se deseja obter no final das atividades de engenharia, compostas pelos requisitos e pelas informações qualitativas sobre o futuro produto. Em seguida, na fase de concepção do produto, soluções de projeto são geradas e estudadas detalhadamente até se encontrar a melhor solução possível que seja capaz de atender às Especificações-Meta concebidas na fase anterior. As soluções de projeto são resumidas em um conjunto de documentos, listados na Figura 2.9, e que receberá o nome de Concepção do Produto. Nessa fase, o time de desenvolvimento pode estar lidando com uma concepção única, selecionada entre as alternativas definidas, ou mais de uma em paralelo, até que, após a realização do primeiro ciclo de detalhamento, também conhecido como projeto preliminar5, seja adotada somente uma das concepções. Na fase de Projeto Detalhado, a Concepção do Produto será detalhada e transformada nas Especificações Finais, que podem abranger uma ampla gama de documentos, detalhando cada item que o compõe e os respectivos processos de fabricação, conforme apresentado no detalhe da Figura 2.9. Outros documentos serão gerados também como Protótipo funcional, Projeto dos recursos, como dispositivos e ferramentas, e o Plano de fim de vida, o qual estabelece condições para a descontinuidade e a reciclagem dos produtos. O protótipo é aprovado, o produto pode ser homologado e as especificações finais são congeladas. Durante a preparação da produção, o produto é certificado com base nos resultados dos lotes piloto. Isso significa que os testes são feitos com produtos fabricados com peças oriundas da linha de produção. Acontece, também, a homologação da produção, culminando com a sua liberação. Esse é um documento oficial, no qual a empresa comunica que o produto começa a ser produzido em série (quando for o caso). A lista de documentos principais dessa fase é descrita na Figura 2.9. Em seguida, ocorre a fase de lançamento do produto, que termina com a emissão do documento oficial de lançamento, cujos documentos principais também estão presentes na Figura 2.9.

5

Veja a discussão no início do Capítulo 8, no Quadro 8.3, “Projeto Preliminar entre o Projeto Conceitual e o Projeto Detalhado”.

CAPÍTULO 2

O Modelo Unificado do PDP

49

Agora que acabamos de ter uma visão geral das macrofases e de seus principais resultados, vamos definir qual a organização responsável pelo desenvolvimento de produtos, pois ela será utilizada ao longo de todo este livro. Para que o processo de desenvolvimento de produtos possa ser realizado, é necessário que exista uma divisão de responsabilidades entre os participantes do desenvolvimento, apresentada no próximo tópico.

2.3

Os papéis principais das pessoas envolvidas no PDP

As macrofases, fases e atividades descrevem o que deve ser feito para o desenvolvimento do produto, mas quem deve ser o responsável pelas etapas de desenvolvimento de produtos? A resposta a essa pergunta está na identificação dos papéis. No Capítulo 1, foi possível conhecer os conceitos básicos sobre organização para o desenvolvimento de produtos. Foram apresentadas diferentes estruturas organizacionais possíveis, as quais podem ser mais ou menos adequadas, dependendo das características da empresa e de seus produtos. Em cada arranjo, as responsabilidades pelas atividades do PDP são divididas de maneira diferente dentro da organização. O que significa que teríamos que tecer a relação entre as atividades do PDP e cada um dos diferentes tipos de estrutura organizacional. Para facilitar a compreensão e simplificar a apresentação do modelo, faremos esse relacionamento por meio do conceito de papel. Cada papel representa uma determinada responsabilidade e tipo de atuação dentro do PDP. Portanto, durante a apresentação do modelo, iremos sempre nos referir aos papéis, os quais poderão ser atribuídos de maneira diferente, conforme a estrutura organizacional específica da empresa. O objetivo deste tópico é apresentar o conjunto-padrão de papéis organizacionais que serão utilizados como referência na descrição das atividades do modelo de referência unificado. Partimos também das premissas de que a empresa adota o conceito de time de desenvolvimento (independentemente de a organização ser matricial ou por projetos) e pratica a gestão por processos, sem a qual não haveria sentido em dizer PDP. O modelo de referência do PDP de uma determinada empresa descreverá os Os papéis são a ligação elementos específicos do processo, isto é, as atividades, documentos utilizados, sisentre a estrutura temas, pessoas envolvidas, entre outros fatores, para que o resultado do processo organizacional e as possa ser alcançado. Em relação ao aspecto da estrutura organizacional, isso signifiatividades do modelo de ca que o modelo pode conter os nomes específicos dos departamentos, áreas, colareferência unificado boradores e até das pessoas responsáveis pelas atividades. Já em um modelo genérico, como o deste livro, isso é impossível, pois os nomes das pessoas, cargos ou mesmo a definição da estrutura organizacional não existem. A solução encontrada foi a de identificar papéis. Cada papel é um conjunto de atribuições e responsabilidades que podem ser assumidas por um determinado ator. Por exemplo, utilizaremos o título gerente de projetos para identificar a pessoa cujas responsabilidades incorporem a de coordenar e controlar o desenvolvimento. Especialistas são aqueles responsáveis pela execução de atividades técnicas específicas de apoio ao time de projeto. Em uma empresa grande, por exemplo, esses papéis podem ser delegados para cargos distintos; conseqüentemente, pessoas distintas estariam assumindo cada um dos papéis. Já em uma pequena organização, uma única pessoa pode assumir ambos os papéis durante o desenvolvimento. Os papéis definidos e referenciados no modelo unificado de PDP são: ■

Papéis e suas responsabilidades no PDP

Membros da diretoria: eles reúnem o conjunto de responsabilidades referentes ao planejamento, aconselhamento e auditoria das atividades e decisões tomadas pelo agente executivo da organização ou unidade de negócio, quando existirem. Esse papel é comumente delegado para os cargos nomeados, tais como: diretor de marketing, fabricação, desenvolvimento etc. Eles são os patrocinadores do PDP e definem as estratégias que norteiam o planejamento estratégico de produto. Podem participar das revisões de fase de algum projeto de desenvolvimento im-

50

PARTE 1

■

■

■

■

■

■

■

■

■

O Processo

portante, trazendo a visão estratégica para comparar o projeto em avaliação, perante todo o portfólio e oportunidades existentes. Gerente funcional: responsável por uma função específica da empresa, tais como: financeira, vendas, marketing, engenharia, laboratórios de protótipos, oficinas, assistência técnica, suprimentos e produção. Varia muito de empresa para empresa. Responsável pela engenharia: pessoa que responde pelos recursos específicos da área de engenharia. Em algumas empresas, esse papel é assumido pelos cargos de diretor de desenvolvimento ou de engenharia. Em empresas maiores, pode existir um gerente de engenharia responsável pela linha de produtos com recursos próprios. Em empresas pequenas, pode ser um diretor ou mesmo o presidente ou dono da empresa. Seu papel é ser responsável pelos recursos de engenharia a serem utilizados pelos projetos de desenvolvimento. Gerente de projetos: responsável por um projeto específico de desenvolvimento e líder de um time de desenvolvimento. Em geral, possui o conhecimento técnico para gerenciar o desenvolvimento, mas, principalmente, deve ter as habilidades e os conhecimentos de gestão de projetos. Muitas vezes, um gerente é auxiliado por pessoas que tratam da consolidação de dados de controle de projeto, uso de sistemas de gestão, ou administração de recursos. Essas pessoas podem fazer parte de um escritório de projetos, que presta serviço para mais de um projeto, com o objetivo de compartilhar recursos entre os projetos. Especialistas: pessoas de determinadas áreas funcionais da empresa ou mesmo de empresas de consultoria que possuem um domínio sobre tecnologias empregadas do produto e processo de fabricação, ou sobre os métodos de trabalho (cálculo estrutural, injeção plástica, sistemas de controle, integração de hardware etc.). Parceiros: são pessoas de empresas parceiras, que podem contribuir nas mais diversas áreas de conhecimento (veja os tipos de parceiros no Tópico 2.10). Time de planejamento estratégico de produto: responsável pelo desdobramento do planejamento estratégico em portfólio de produtos da empresa (veja o Tópico 2.4.2). Pode ser constituído pelos membros da diretoria ou os gerentes funcionais. Time de desenvolvimento: responsável por um projeto específico de desenvolvimento. Pode envolver pessoas de diversas áreas da empresa, especialistas, assim como parceiros. A cada estágio do projeto, ele pode ser composto por membros diferentes (mais pessoas de marketing no início, de engenharia nas fases de projeto, de produção e marketing novamente no final). Time de avaliação: responsável por aprovar a continuidade do projeto após uma revisão da fase (veja uma explicação mais detalhada no Tópico 2.7). Membros da diretoria, gerência, especialistas e convidados podem fazer parte desse time. Time de acompanhamento do produto: é aquele que fica responsável pelo produto ao longo do seu ciclo de vida, após o término da macrofase de desenvolvimento. Os integrantes desse time não se dedicam intensamente ao produto. Participam de outros projetos ou tarefas operacionais, mas detêm o conhecimento sobre o produto desenvolvido e podem ser chamados a qualquer momento para analisar situações de desvio e propor mudanças, a serem direcionadas ao processo de apoio de Gerenciamento de Mudanças de Engenharia (veja o Capítulo 13, Tópico 13.1, “Gerenciamento de Mudanças de Engenharia”).

O leitor não deve confundir a existência desses papéis com a necessidade da criação de cargos ou funções na empresa. A estrutura organizacional precisa ser enxuta e adequada à situação específica de cada empresa, como vimos no Capítulo 1. O importante é verificar se cada um dos papéis citados está contemplado dentro da estrutura organizacional definida na empresa. Pois, assim, ao se criar um modelo de referência específico a partir desse modelo genérico, será possível mapear o elemento da organização (departamento, área, divisão), o qual deverá ser responsável por cada um dos papéis. Caso esse mapeamento identifique que um determinado papel não foi atribuído a ninguém, isso pode significar que aquelas atividades do modelo Adaptação dos papéis definidos a cada tipo de empresa

CAPÍTULO 2

O Modelo Unificado do PDP

51

estejam sem um responsável bem definido e não estejam formalizadas, sendo um indício de disfunção ou problema em uma determinada área do processo do PDP. A Figura 2.10 demonstra esquematicamente essa idéia. O organograma de duas empresas fictícias é apresentado. A primeira delas, a Empresa A, possui uma estrutura mais complexa com três níveis, diretorias, gerências funcionais e o terceiro com analistas e técnicos. Trata-se de uma estrutura matricial na qual representantes das áreas funcionais se unem nos times. O segundo caso representa a estrutura típica projetada de empresas médias de desenvolvimento. Há uma gerência para a engenharia, e os técnicos e analistas reportam diretamente ao gerente/diretor. O número de níveis organizacionais é de apenas dois. Enquanto os papéis de Membro da Diretoria e Responsável pela Engenharia são atribuídos à mesma pessoa na Empresa B, eles são delegados para pessoas diferentes no caso da Empresa A. Figura 2.10

2.4

Relação da visão organizacional entre o modelo de referência e o específico.

Visão geral da macrofase de pré-desenvolvimento

2.4.1 Por que pré-desenvolvimento? Tradicionalmente, quando se pensa em desenvolver produtos, a primeira coisa que vem à mente são os requisitos e desenhos. Basta decidirmos quem é o cliente e definir com ele o que temos que desenvolver, certo? É preciso começar muito antes de tudo isso. Imagine agora uma empresa Primeiro reunir idéias e... qualquer, por exemplo, uma pequena empresa que produza bebedouros. Suponha que ela possua 15 pessoas na engenharia, 5 na área de vendas e mais os seus diretores, 4 ao todo. Eles lêem revistas especializadas, conhecem o que seus competidores estão fazendo, visitam feiras e eventos científicos especializados e conversam com vários clientes. Ao final, teremos 24 pessoas dando idéias de produtos que poderiam ser desenvolvidos, tanto novos bebedouros

52

PARTE 1

O Processo

como produtos similares, pequenas geladeiras etc. Imagine que essa empresa possui 8 grandes distribuidores que trazem do campo reclamações e sugestões, os quais também podem conter excelentes idéias para novos produtos. Sem contar o novíssimo telefone 0800 e os relatórios da sua rede de assistência técnica. Tudo isso permitindo mais idéias de novos projetos de desenvolvimento. Esse mundo de oportunidades é claramente inesgotável. Porém, estamos no ...avaliar as restrições mundo real onde não existem apenas oportunidades — nele é preciso considerar as existentes restrições. A primeira delas é o capital. Desenvolver um novo produto significa investir em um negócio e uma empresa real, com riscos envolvidos. Por maior que seja a empresa, a capacidade de investimento é limitada. Mesmo se essa capacidade fosse infinita, há restrições físicas, institucionais e de capacitação de pessoal. Alguns exemplos: nada adianta dinheiro se você não puder aumentar rapidamente sua capacidade de produção, se não possuir fornecedores capazes de entregar peças ou matérias-primas a preços competitivos, se você não possuir mão-de-obra com experiência nas tecnologias daquele determinado produto, se não tiver acesso a uma rede de distribuição para o seu produto etc. Portanto, unindo ambos os lados da moeda, temos uma equação que precisa Priorizar os projetos de ser resolvida: quais projetos de desenvolvimento priorizar, considerando as restriacordo com a estratégia ções de capital, tecnologia e competências? Para iniciarmos a solução desse da empresa quebra-cabeça, você já deve ter notado que faltou algo: Estratégia Competitiva. Isto é, decidir o que será desenvolvido passa por resolver essa questão, considerando os objetivos que a empresa espera conseguir no futuro e como deseja atingi-los. Portanto, não é mais possível conceber o processo de desenvolvimento de produtos sem que ele esteja ligado à Estratégia Competitiva da Empresa. O pré-desenvolvimento deve garantir que o direcionamento estratégico, defiEntão a missão do nido a priori pela empresa no Planejamento Estratégico da Corporação, as idéias de pré-desenvolvimento é... todos os atores internos e externos envolvidos com os produtos, e as oportunidades e restrições sejam sistematicamente mapeados e transformados em um conjunto de projetos bem definidos, isto é, o portfólio dos projetos que deverão ser desenvolvidos. E é no planejamento detalhado de cada um desses projetos que se deve definir com clareza o seu escopo, garantindo-se uma integração com os direcionamentos estratégicos. As principais análises sobre o projeto são realizadas para decidir se realmente o que foi definido no planejamento estratégico tem chance de acontecer. No final do planejamento, é decidido se o desenvolvimento do produto deve continuar ou não. Para entendermos melhor a diferença entre essas fases, precisamos entrar em consenso sobre alguns conceitos básicos de planejamento estratégico.

2.4.2 Conceitos básicos do processo de planejamento estratégico O processo de planejamento estratégico é um processo gerencial, isto é, seu resultado final não agrega valor diretamente ao cliente. Ele obtém informações que orientam os demais processos de negócio da organização, incluindo o Processo de Desenvolvimento de Produtos (PDP). Esse tema é vasto por si só e mereceria um livro à parte, caso essa questão fosse aprofundada.6 De maneira simplificada, podemos considerar que desenvolver uma estratégia para uma organização é responder a um conjunto de questões: Processo de planejamento estratégico e o desenvolvimento de produto

1. 2. 3. 4. 5.

6

Onde estamos? Para onde vamos? Como chegaremos lá? Temos capacidade para realizar isso? Como saberemos se estamos chegando lá?

Para uma definição mais apropriada, recomenda-se a leitura de MITZENBERG, AHLSTRAND e LAMPEL (2000).

CAPÍTULO 2

O Modelo Unificado do PDP

53

Transportando essas perguntas para o universo de uma empresa, é possível perceber que elas podem ser aplicadas em diferentes níveis. De maneira didática, podemos identificar três deles, descritos na Figura 2.11. Figura 2.11

Níveis de planejamento estratégico.

Como exemplo, imagine que uma empresa produza vários tipos de equipaUm exemplo para mentos para impressão, atendendo, a partir de várias fábricas, diferentes tipos de entendermos o clientes: o profissional que possui uma impressora no escritório de sua casa, escritódesdobramento do rios de empresas e gráficas. O conjunto dessas fábricas e unidades administrativas é planejamento estratégico o que poderemos chamar de corporação. As características dos consumidores finais citados são muito diferentes. Um comprador doméstico, na maioria das vezes leigo em informática, precisa de um catálogo de informações simples e que consiga orientá-lo facilmente na aquisição do produto, sem que ele precise se tornar um especialista. Ele mede a qualidade do produto de uma maneira diferente também, considerando impressões, sentimentos transmitidos pelo produto e indicações do vendedor e de pessoas conhecidas. São muitos clientes, e o volume de vendas será alto, portanto, as margens em cada produto tendem a ser pequenas, inviabilizando a personalização do atendimento. Por outro lado, o consumidor gráfico realizará uma compra altamente técnica, discutindo cada especificação e detalhe do equipamento e avaliando o retorno financeiro que terá com o produto. Ele exigirá a presença de um profissional da assistência técnica tanto antes quanto após a compra, em um atendimento altamente especializado. A quantidade de consumidores nesse mercado7 é menor, porém com equipamentos de maior valor agregado. Deve-se vender poucos itens, mas a margem de lucro e faturamento em cada um deles será significativamente maior. Os canais de distribuição, isto é, a forma como o produto chega ao cliente é também muito diferente. Portanto, seria muito difícil, ou mesmo impossível, atendê-los com a mesma estrutura organizacional. A melhor forma de lidar com essa situação seria criar estruturas organizacionais distintas, chamadas de unidades de negócio. Apesar de ser a mesma tecnologia de produto e processo envolvida no produto, tais unidades funcionam como se fossem empresas distintas. Cada uma delas com número de funcionários, competências e procedimentos específicos, adequados às especificidades do mercado que atendem. É assim que a maioria das empresas, que atuam em diferentes ramos, opera de forma a manter seu tamanho sem comprometer a eficiência. Um exemplo é a General Eletric, que fabrica desde lâmpadas, eletrodomésticos até turbina de aviões e equipamentos médicos. Certamente, seria impossível gerenciar essa que é considerada a maior empresa do planeta sem essa estrutura organizacional.

7

Neste livro, estaremos utilizando bastante a palavra mercado, que, no senso comum, pode ser interpretada de diferentes maneiras. Deve-se entender mercado pelo conjunto de consumidores potenciais de um produto ou serviço. Para mais detalhes, veja KOTLER (2001).

54

PARTE 1

O Processo

No caso da empresa de exemplo, poderiam existir no mínimo três unidades de negócio: impressoras para uso doméstico; impressoras para escritório; e impressoras de alto desempenho para gráficas. Serviços especializados, comuns a todas elas e capazes de serem prestados como consultoria, tais como o RH e a infra-estrutura de tecnologia de informação, seriam candidatos também a se transformar em unidades de negócio. A diferença é que essas unidades seriam voltadas para o atendimento das outras três, isto é, seriam unidades da corporação voltadas para apoio. Dessa forma, as organizações mantêm estruturas operacionais adequadas a cada mercado e dividem os custos dos serviços comuns entre elas. Para este livro, o que interessa saber é que cada unidade opera com uma estrutura organizacional, objetivos e pessoal próprios. Além de facilitar e garantir a adequação do funcionamento da empresa, conforme as necessidades de cada mercado, a aplicação desse conceito permite diminuir riscos, pois a verificação do desempenho da corporação em cada nicho do mercado torna-se transparente, facilitando a ação dos executivos. Voltando ao planejamento estratégico, o exemplo da empresa de impressoras ajuda a entender a diferença entre os níveis de abstração na estratégia de uma empresa. A estratégia no nível corporativo precisa responder sobre os rumos da corpoPlanejamento Estratégico ração como um todo, incluindo todas as unidades de negócio. Onde a corporação da Corporação (PEC) está em termos de capitalização, desempenho, presença física, acionistas etc.? Qual a missão dessa corporação, isto é, aonde vamos? No “como chegaremos lá”, precisamos responder em quais unidades de negócio a empresa deve investir ou não. Isso significa decidir se a corporação deve reinvestir a receita de cada unidade de negócio ou transferi-la para uma delas — eventualmente mais importante para a concretização da missão da corporação. Por exemplo, um novo nicho de impressoras para fotografia digital caseira poderia se fortalecer, justificando o direcionamento de receitas da unidade de impressoras para gráficas para a unidade de negócio de consumidores domésticos, ampliando o investimento da corporação nesse novo negócio. Significa também rever a própria divisão entre as unidades mencionadas. O perfil dos consumidores em termos de comportamento e hábitos pode mudar, consolidando novos grupos com características diferentes. No processo de planejamento da estratégia corporativa, a eventual inadequação da estrutura de unidades de negócio precisa ser identificada, e propostas de novas segmentações devem ser desenvolvidas. Por exemplo, o crescimento da capacidade, da confiabilidade e da facilidade de uso das impressoras pode tornar as características de compra dos mercados domésticos e de escritórios muito parecidas. Nesse caso, a corporação poderia optar por unificar as duas unidades. Mas a empresa tem capacidade para realizar isso? Para responder a essa pergunta, é preciso identificar as restrições e os riscos para a adoção das soluções identificadas no passo anterior. Ao final, deve-se desenvolver metas para o desempenho da corporação. Em suma, isso significa definir objetivos específicos que cada unidade de negócio precisa atingir, para que as metas da corporação sejam atingidas. O Planejamento Estratégico da Corporação é o primeiro passo do planejamento estratégico. Uma vez definido o papel e as metas de cada unidade de negócio, deve-se detaPlanejamento Estratégico lhar como será a estratégia de ação da unidade de negócio em si. As perguntas genéda Unidade de Negócios ricas são as mesmas, porém as decisões e os problemas enfrentados são distintos. (PEUN) Esse plano estratégico deve começar pela análise da situação da unidade de negócio em questão, sua participação no mercado em que atua, faturamento, satisfação dos clientes diante da concorrência etc. A preocupação é, portanto, de natureza mais tática. Quais os desafios da unidade de negócio no nicho em que atua e como ela enfrentará a concorrência de maneira a atingir as metas previstas para essa unidade no Planejamento Estratégico da Corporação, considerando a previsão de investimentos e restrições internas e externas. Os gestores da unidade de negócio precisam segmentar o mercado e identificar inicialmente qual o desempenho, não apenas financeiro, como no planejamento corporativo, mas também em termos de eficiência e eficácia dos produtos e processos (logística, entrega, compras etc.) e percepção dos clientes, fornecedores e colaboradores — expressa no nível de satisfação. Em seguida, é preciso identificar suas competências essenciais e realizar a melhor previsão possível sobre as tendências tecnológicas e de mercado. A consideração desse conjunto grande de informações permite identificar as forças e também as fraquezas da empresa. Feito isso, pode-se pensar no “como”. Na estratégia corporativa, o

CAPÍTULO 2

O Modelo Unificado do PDP

55

“como” estava relacionado a discutir em qual unidade (no fundo, mercado) a empresa deve ampliar ou reduzir sua participação. Na unidade de negócio, é preciso identificar em quais segmentos de mercado a empresa deve apostar e como superar a concorrência em cada um deles. Nesse nível de planejamento, portanto, deve-se ir fundo nos detalhes, identificando a forma de superação, ou seja, que ganhos em termos de características de produtos e processos precisam ser obtidos para que haja superação suficiente para atingir as metas de desempenho. Pode ser menor custo, condições de entrega, diferenciação em atributos, tais como: desempenho, design etc. Além da estratégia em termos de concorrência, deve-se discutir estratégias em relação à cadeia de valor. Isto é, a unidade de negócio pode crescer sua participação no segmento de mercado, agregando operações realizadas pelos fornecedores ou em mercados de seus atuais clientes. No caso da unidade de negócio doméstico do nosso exemplo, a estratégia poderia ser a de crescer no sentido da diferenciação dos produtos em termos de aparência e sofisticação tecnológica. Essa decisão depende, logicamente, de toda a informação prospectada. Pode ser que a empresa tenha como força uma equipe com alta competência técnica e uma marca premium, isto é, valorizada pelo consumidor. Como fraqueza, uma dificuldade de penetração e presença em pontos-de-venda. Essa estratégia exploraria os aspectos positivos, as forças da empresa — como a marca e a competência —, transformando-os em um diferencial nos pontos-de-venda, em que, com custo similar ao do concorrente, esses fatores decidiriam a compra em favor da empresa. Uma vez definida a estratégia, deve-se avaliar a capacidade da unidade de negócio, em termos de riscos e restrições, quanto à operacionalização da estratégia. Ao final, metas e indicadores de desempenho, específicos para a unidade de negócio, precisam ser definidos. Indicadores são fundamentais para o acompanhamento da implementação da estratégia e para avaliar, ao final do período, se os objetivos foram atingidos. O último nível de planejamento estratégico é o de produto. Ele é realizado a Planejamento Estratégico partir do Planejamento Estratégico da Unidade de Negócios e se relaciona fortede Produtos (PEP) mente com o anterior. Na maioria das vezes, acontece simultaneamente. É aquele em que se determina a estratégia em relação às linhas de produto. Na prática, isso é feito por meio do desdobramento do portfólio, ou carteira de projetos, a partir da estratégia da unidade de negócio. As mesmas questões gerais anteriormente apresentadas são válidas para esse planejamento. Quadro 2.1

Estratégia Tecnológica

Para autores clássicos em planejamento estratégico, como Porter (1980), a estratégia tecnológica é o enfoque que a empresa adota para o desenvolvimento e uso da tecnologia, constituindo um ingrediente essencial de sua estratégia competitiva. Ou seja, objetiva orientar a empresa na aquisição, desenvolvimento e aplicação da capacidade tecnológica para obtenção da vantagem competitiva. Wheelwright & Clark (1992) consideram que uma estratégia tecnológica deve contemplar o foco, as fontes de capacitação e o momento e freqüência de implantação das inovações. Primeiro, deve ser definido o foco de mudança ou desenvolvimento técnico. A tecnologia deve incluir o know-how necessário para a empresa criar/desenvolver, produzir, vender seus produtos e distribuí-los aos consumidores. Uma parcela desse conhecimento pode estar apoiada na experiência acumulada da empresa ou pode ter origem no conhecimento científico ou nas atividades de P & D na área. Embora o conhecimento técnico possa ter diferentes origens e assumir diferentes formas, o mais relevante para a capacidade competitiva é a capacitação técnica da empresa — sua habilidade em utilizar esse know-how para obter resultados interessantes em seus produtos e processos. O segundo aspecto crítico da estratégia tecnológica diz respeito às fontes de capacitação. Essa pode ser desenvolvida internamente, por meio de investimentos em recursos humanos, equipamentos, laboratórios e metodologias, ou por meio de projetos de desenvolvimento avançado. Entretanto, a tecnologia pode também ser adquirida externamente, por meio de contratos de pesquisas com universidades, joint ventures, licenciamentos ou compras de pacotes tecnológicos. Essas duas fontes não são mutuamente exclusivas, e a definição do mix de fontes internas e externas é um dos aspectos críticos da estratégia tecnológica. Ainda que uma das fontes possa ser dominante, a outra geralmente também desempenha papel importante. Mesmo nos casos em que a fonte principal é externa, a empresa necessita de capacitação interna para avaliar as tecnologias disponíveis no mercado e integrá-las à sua realidade. Assim, as questões básicas a que a estratégia tecnológica deve responder sobre as fontes são:

(continua)

56

PARTE 1

Quadro 2.1

O Processo

Estratégia Tecnológica (continuação)

• Qual o papel das fontes externas e internas? • Como elas são integradas? Após determinar esses dois aspectos, a empresa precisa definir o momento (timing) e a freqüência de implementação das inovações. O momento envolve tanto questões referentes ao desenvolvimento da capacidade tecnológica quanto a introdução das inovações no mercado. A empresa pode optar em ser pioneira ou seguidora das demais empresas do mercado. A freqüência de inovação e os riscos associados dependerão, em parte, da natureza da tecnologia e dos mercados envolvidos e em parte da escolha estratégica da empresa. Pensando em dois extremos, uma empresa pode adotar uma estratégia de inovação baseada em saltos pequenos e freqüentes, representada por mudanças incrementais na tecnologia que asseguram melhoria contínua no desempenho. Em um outro extremo, estaria uma estratégia de grandes saltos, que permite desenvolver mudanças pouco freqüentes, mas de grande escala e que avançam substancialmente o estado da arte.

Onde estamos? Deve-se iniciar pelo levantamento da situação atual do portfólio de projetos. Ao final, deve-se responder quais são os produtos que estão no mercado, quais projetos estão em desenvolvimento, quais os resultados obtidos pelos produtos e a situação dos projetos em andamento. A meta é planejar o portfólio futuro de forma a satisfazer a estratégia da unidade de negócio. Voltemos ao exemplo das impressoras. A estratégia era obter uma diferenciação tecnológica e de qualidade. Para que essa estratégia seja implementada, é preciso que a linha de produtos da empresa seja, aos olhos do consumidor, mais sofisticada que a do concorrente. Análises do portfólio podem indicar que a empresa possui poucos produtos em situação favorável aos concorrentes nesse quesito e que os projetos em andamento, embora sofisticados e com design voltados para demonstrar isso, não apresentariam novidades. A empresa poderia, então, alterar o portfólio, incluindo o desenvolvimento de uma nova família de impressoras voltada para a impressão de fotografia digital com novos recursos — como scanner de negativo acoplado. Fundamental é que a linha de produtos da empresa seja capaz de responder à estratégia da empresa. Nesse caso, por exemplo, ter o produto de preço mais baixo do mercado não seria necessário, mas o produto mais avançado sim. Além dessa preocupação com o alinhamento estratégico, deve-se perseguir três outros objetivos durante a definição do portfólio: a maximização do valor econômico, o balanceamento da carteira e a diminuição dos ris8 cos . Deve-se considerar também as tendências e estratégias específicas da empresa com relação a dois aspectos: a estratégia tecnológica, garantindo que a empresa mantenha sua linha de produtos atualizada e uma equipe de profissionais capacitada a projetar utilizando as novas tecnologias. Uma analogia interessante para essa atividade é a de um funil ou tubo conectando a empresa ao mercado, conforme apresentado na Figura 2.12. Cada círculo nessa figura representa um determinado projeto de desenvolvimento de produto a ser realizado no tempo. Eles vão diminuindo porque, dado o risco dessa atividade, parte deles será congelada ou cancelada antes de ser lançada por diferentes razões. Mantendo-se um bom plane9 jamento desses projetos, os melhores sobreviverão e atingirão o mercado trazendo benefícios para a empresa. Ao final do planejamento do portfólio de produtos, obtém-se um “retrato” desse funil com a definição exata das famílias, produtos e projetos de desenvolvimento que deverão ser realizados pela unidade de negócio no horizonte de planejamento, que pode variar de empresa para empresa conforme o ramo de atividade. Um exemplo é um prazo de 5 anos. Falta definir agora o “como”, isto é, verificar se há capacidade para realizar esse plano. Isso terá que ser feito separadamente, para cada projeto. Portanto, à medida que se aproxima a data de início do desenvolvimento de um determinado produto do portfólio, a unidade de negócio precisa destacar um profissional para analisar e começar o planejamento específico daquele projeto, definindo detalhadamente seu escopo, cronograma e viabilidade técnica e financeira. 8 9

Esse conceito será apresentado em detalhes no Capítulo 4. Caso o leitor queira se antecipar, consulte o Quadro 4.7. O leitor deve reparar na semelhança da idéia de funil com a descrição geral do modelo. Não é por acaso, pois o modelo unificado é baseado nesse princípio, e sua aplicação gerará esse funil com produtos saindo da empresa até o mercado.

CAPÍTULO 2

O Modelo Unificado do PDP

Figura 2.12

57

Funil ou tubo de produtos.

O desdobramento da estratégia conforme apresentado aqui é reconhecidaPersonalizando o processo mente a melhor prática em desenvolvimento de produto. Se o processo de desende planejamento volvimento não possui uma forte conexão com essa estratégia, todo o esforço estratégico técnico e de monitoramento do mercado realizado nas fases seguintes corre grande risco de se dispersar, comprometendo o futuro da empresa. Logicamente, não é necessário que uma empresa possua os três níveis estratégicos para aplicar esses conceitos. O caso apresentado aqui é propositalmente complexo, o de uma empresa internacionalizada com unidades de negócio distintas e uma grande operação. A idéia básica pode ser seguida independentemente do tamanho da empresa. Por exemplo, empresas mais enxutas podem realizar um único plano estratégico contemplando desde a missão da organização até a linha de produtos da empresa. Portanto, não é o tamanho do processo de planejamento ou a quantidade de análises e de níveis que conta. Fundamental é contemplar um desdobramento de metas de longo prazo e financeiras da empresa como um todo (corporação) até a definição de uma linha de produtos e projetos de desenvolvimento, capazes de contribuir para que os objetivos da corporação sejam alcançados. Importante é manter uma estreita coerência entre o que se deseja em termos de resultados gerais, comerciais e financeiros, com a definição e priorização dos projetos. É isso que garante que a empresa canalize seus esforços de desenvolvimento no essencial, evitando desperdícios e garantindo uma coerência entre a comunicação com os colaboradores e clientes e o resultado concreto: os produtos. Se há incoerências entre mensagem e características dos produtos, fica evidente a fragilidade em atender os clientes. O modelo apresentado neste livro parte desse compromisso e apresenta um O modelo deste livro processo de desenvolvimento de produto com elevada integração com a estratégia da empresa. Isso é fundamental para garantir que sejam atendidas e superadas as expectativas dos clientes, mas também que se atinja os clientes certos, de interesse da empresa. Algo assim permite, ainda, que a proposta da empresa pareça clara para seu público-alvo, dentro de um estilo próprio capaz de diferenciá-la e atribuindo uma vantagem competitiva difícil de ser imitada: a vantagem competitiva por meio do desenvolvimento de produtos.

2.4.3 O início e o fim do pré-desenvolvimento A macrofase de pré-desenvolvimento envolve as atividades de definição do projeto de desenvolvimento, realizadas a partir da estratégia da empresa, delimitação das restrições de recursos e conhecimentos e informações sobre os consumidores, e levantamento das tendências tecnológicas e mercadológicas. O primeiro passo é o desdobramento do resultado do planejamento estratégico em um portfólio, ou carteira de projetos. E finaliza com a Declaração de Escopo e o Plano do Projeto inicial de um dos produtos previstos no portfólio de projetos, ou um dos produtos da carteira, o qual será desenvolvido nas etapas posteriores.

58

PARTE 1

O Processo

Os dois objetivos principais dessa macrofase são: 1) garantir a melhor decisão sobre o portfólio de produtos e projetos, respeitando a estratégia da empresa e as restrições e tendências mercadológicas e tecnológicas; 2) garantir que haja uma definição clara e um consenso mínimo sobre o objetivo final de cada projeto, partindo de uma visão clara sobre as metas do projeto para a equipe e evitando um “desvio de rota” em relação ao papel de cada produto dentro do portfólio da empresa. A macrofase de pré-desenvolvimento se inicia com o Planejamento EstratéPartimos do plano gico da Corporação e o Planejamento Estratégico da Unidade de Negócios, previaestratégico da corporação mente preparados. Em nosso modelo, esse é o limite que separa o processo de e da unidade de negócio planejamento estratégico do processo de desenvolvimento de produto. Segundo nossa concepção, todo o trabalho anterior está relacionado ao planejamento estratégico da empresa, e o trabalho de desenvolvimento começa na definição do portfólio de produtos e projetos. Objetivos principais da macrofase de pré-desenvolvimento

Quadro 2.2

Planejamento Estratégico, Marketing ou Desenvolvimento de Produtos?

Diferentes teóricos da área de marketing e de planejamento estratégico incluem o processo de desenvolvimento de produto como parte do processo de planejamento e marketing. Autores ligados ao desenvolvimento de produto, por sua vez, afirmam que o planejamento estratégico está dentro do desenvolvimento ou que o desenvolvimento começa com a idéia dos novos produtos. Na verdade, do ponto de vista prático, o importante mesmo é que exista a integração entre essas atividades, independentemente do nome do processo macro, qual seja estratégia ou desenvolvimento de produto. No caso do modelo apresentado neste livro, adotou-se um ponto objetivo e bastante específico para demarcar a divisão entre os dois processos: a elaboração da estratégia de produtos, cujo grande resultado é o portfólio de produtos. Ao realizar as decisões relativas ao portfólio de projetos, se está realizando uma primeira definição de cada um dos produtos e entendendo o seu papel específico na estratégia da empresa. Nessa fase, parâmetros suficientes para estabelecer uma primeira idéia do que é cada produto são definidos e daí parece ser um início conveniente para o Processo de Desenvolvimento do Produto. No decorrer desse processo, a definição inicial do produto será continuamente revisada e ampliada até se obter uma descrição exata e inequívoca de cada item e do processo de fabricação do produto, e tudo esteja pronto para que ele seja comercializado. Além disso, essa demarcação deixa subentendida a idéia fundamental de que um bom produto não nasce apenas “de uma idéia”, como colocado por vários livros-texto em desenvolvimento de produto. Por exemplo, imagine que um engenheiro da área de desenvolvimento da nossa empresa de impressoras apresentada no início do livro tenha uma idéia genial para criar um produto mais simples e significativamente mais barato que o dos concorrentes. No caso desse produto ser desenvolvido, ele estaria indo de encontro à estratégia da empresa, que é distinguir-se pela inovação tecnológica e não em custos. O produto não estaria contribuindo para as metas da empresa, correndo-se o risco de, por melhor que seja a solução técnica adotada no projeto, não existir o retorno comercial e de imagem pretendidos. Esse exemplo é algo que acontece na prática em muitas empresas. Gasta-se tempo e dinheiro criando interessantes planos estratégicos, que se tornam inúteis porque, no dia-a-dia das operações, decisões são tomadas distanciando a empresa das metas pretendidas.

Uma observação importante é que, dado o caráter criativo e recorrente das atividades de planejamento, o uso do Plano Estratégico de Negócios não significa a aceitação pura e simples das metas e estratégias nele contidas. Deve-se entender o Planejamento Estratégico de Produtos como um trabalho de recriação, isto é, de apropriação crítica em que os planos estratégicos, fruto de uma síntese de várias análises e estudos, são reavaliados e questionados até que o time de planejamento estratégico do produto esteja consciente da visão futura traçada para a corporação e/ou unidade de negócio e compreenda perfeitamente o papel que a linha de produtos da empresa deverá desempenhar na estratégia. A Figura 2.13 esclarece o escopo do pré-desenvolvimento.

CAPÍTULO 2

O Modelo Unificado do PDP

Figura 2.13

59

Relação entre os documentos principais do processo de planejamento estratégico e desenvolvimento de produtos.

A macrofase pré-desenvolvimento do nosso modelo é dividida, portanto, em duas grandes fases: Planejamento Estratégico de Produtos e Planejamento do Projeto. A primeira delas é composta pelo conjunto de atividades que transformam as informações contidas nas Estratégias Corporativas e da Unidade de Negócio no Plano Estratégico de Produtos, o qual contém a descrição do portfólio de produtos. A segunda fase tem seu início assim que se aproxima a data prevista da realização de um dos projetos do Plano Estratégico de Produtos. Portanto, um início diferente para cada projeto específico. Ela é composta pelas atividades de determinação do escopo e planejamento macro do projeto e finaliza no momento em que um projeto específico, depois de planejado, é considerado viável e aprovado no gate.

2.4.4 A importância do pré-desenvolvimento Agora deve estar mais fácil perceber a importância dessa macrofase. É nela que É a ponte entre os se faz a ponte entre o objetivo que a empresa possui e os produtos desenvolvidos. objetivos da empresa e os Embora essa discussão pareça extremamente simples e lógica, o leitor deve compreender projetos de que, ainda hoje, é bastante revolucionária diante das práticas adotadas nas indúsdesenvolvimento trias. Em muitas empresas, ainda predomina a visão de que desenvolver produtos é perguntar ao cliente o que ele quer e ir direto para a “prancheta”. O problema é que isso pode levar ao desenvolvimento de projetos que estejam desviando a empresa de uma meta. Ou fazendo com que a empresa deixe escapar oportunidades fundamentais para sua sobrevivência no longo prazo. Evita-se a perda dessas oportunidades quando, por exemplo, uma empresa decide desenvolver um produto deficitário do ponto de vista comercial, mas que contribui, por exemplo, com o desenvolvimento de uma nova tecnologia, a qual, no futuro, pode definir a sobrevivência da empresa. Dosar todas essas possibilidades, na definição do portfólio, é uma grande contribuição do pré-desenvolvimento. Assim, a importância do pré-desenvolvimento está em contribuir com os seguintes aspectos: ■ ■

foco nos projetos prioritários definidos pelos critérios da empresa; uso eficiente dos recursos de desenvolvimento;

60

PARTE 1

■ ■

O Processo

início mais rápido e mais eficiente; e critérios claros para avaliação dos projetos em andamento.

Além disso, o planejamento sistemático dos projetos permite que o escopo seja bem definido e que os riscos sejam avaliados, prevenindo problemas durante a sua realização. Um aspecto interessante a ser notado é que deficiências nessa macrofase não Quando existem são facilmente diagnosticadas como problemas de desenvolvimento. São comuns as deficiências no eternas lutas entre as áreas funcionais de engenharia e o setor de vendas das empré-desenvolvimento... presas, em um “jogo de empurra-empurra” sem fim: os dois identificando a fonte de seus problemas como sendo as atividades do outro. Vendas apontando deficiências na linha de produtos e a engenharia sem capacidade para novos projetos em conseqüência do excesso de novas idéias e mudanças nas metas de necessidades identificadas pela área de vendas. Ambos têm sua parcela de razão, mas não percebem que a causa fundamental de todos os problemas está na deficiência da delimitação do plano estratégico e do gerenciamento da carteira de produtos. Falta um pré-desenvolvimento mais sistematizado e integrado com as demais fases do PDP.

2.4.5 Pré-desenvolvimento é para todos? Sim, independentemente do tipo de processo de desenvolvimento de produto, a empresa necessita de um mínimo de entendimento da missão e objetivos estratégicos. E a escolha dos projetos de desenvolvimento precisa ser baseada nessa missão. Mesmo empresas que desenvolvem sob encomenda precisam analisar o mercado para avaliar quais as oportunidades e priorizar clientes e projetos. Mas, certamente, a importância dessa fase deve ser medida conforme certas características do processo de desenvolvimento de produto e do ambiente da empresa. Alguns exemplos: ■

■

■

Quanto à dimensão mercado-setor: alguns setores industriais específicos, como atualmente o eletroeletrônico, em especial celulares, e o de biotecnologia atravessam fases de saltos abruptos no nível tecnológico. Nesses ambientes, escolher adequadamente os projetos de desenvolvimento é fundamental e pode ser a diferença entre prosperar ou morrer. É condição essencial para que a empresa consiga manter uma linha de produtos atualizada e competitiva no longo prazo. Em casos assim, as empresas precisam ter um pré-desenvolvimento sofisticado, contendo todas as fases e atividades apresentadas no modelo. Quanto à dimensão mercado-concorrência: há setores industriais específicos em que, embora a tecnologia básica seja madura, a concorrência torna-se acirrada em termos de características subjetivas dos clientes ditadas por modas ou valores culturais. É o caso específico de empresas de perfumes, alimentos ou linha branca. O pré-desenvolvimento aqui é essencial para se definir uma quantidade de projetos capaz de gerar uma linha de produtos que atenda às necessidades específicas de cada cliente sem comprometer a manufaturabilidade. Complexidade do produto: produtos que possuem uma complexidade muito grande exigem um pré-desenvolvimento mais completo, pois é grande o risco de fracasso diante das dificuldades de desenvolvimento.

Em síntese, podemos dizer que, quanto mais turbulento o ambiente (no sentido de ser competitivo e com mudanças mais bruscas), mais inovador o produto, menor o tempo de vida do produto no mercado e maior a complexidade em quantidade de peças e processos de fabricação específicos, mais importante se torna o pré-desenvolvimento. Após o planejamento de um projeto específico de desenvolvimento de um produto, parte-se para a outra macrofase do modelo, na qual esse planejamento é utilizado e atualizado durante a realização do projeto propriamente dito, ou seja a macrofase de desenvolvimento.

CAPÍTULO 2

O Modelo Unificado do PDP

2.5

61

Visão geral da macrofase de desenvolvimento Após a definição do portfólio de produtos e o planejamento dos projetos, partiremos para o desenvolvimento propriamente dito. Por tradição, essa macrofase é denominada desenvolvimento de produtos ou projeto do produto. No nosso modelo, ela é integrada às macrofases de pré e pós-desenvolvimento.

2.5.1 Características das fases do desenvolvimento Na Figura 2.14 pode-se observar as fases do desenvolvimento. Vimos que uma fase termina com a entrega de resultados (deliverables), os quais, a partir desse momento, permanecem congelados. Essa divisão varia de empresa para empresa e não existe um padrão.10 Normalmente, a definição de uma fase está relacionada com o conceito de gate (veja o Tópico 2.7). No final de uma fase, sempre temos uma avaliação do projeto, isto é, a necessidade de avaliar os resultados de um projeto implica um gate, que, por sua vez, delimita uma fase.11 As características do processo de desenvolvimento de produtos foram apresentadas no início do Capítulo 1, e mostra a importância das fases iniciais do desenvolvimento, ressaltadas na Figura 2.14: no início, o grau de incerteza é grande, porém, é neste momento que são realizadas as escolhas de soluções de projeto (materiais, conceitos, processos de fabricação etc,), que determinam aproximadamente 85% do custo final do produto. Figura 2.14

Características das fases iniciais do desenvolvimento.

Em razão do grau de incerteza inicial, ocorrem modificações de produto nas fases subseqüentes do desenvolvimento, quando informações mais precisas estão disponíveis. O custo das modificações é cada vez mais elevado, conforme avançam as fases do DP. Vamos comparar qualitativamente o custo de uma modificação no desenvolvimento de uma máquina para entendermos melhor o que estamos falando. Imagine a introdução de alguma mudança durante a fase de projeto informacional, quando os requisitos do produto e suas especificações-meta foram definidos. O custo dessa modificação envolve definir os novos requisitos e as especificações e pode significar algumas horas de trabalho do 10

11

Veja quatro exemplos diferentes de fases do PDP: 1. estudo do mercado, especificação, projeto conceitual, projeto detalhado, processo, vendas; 2. análise de necessidades, pesquisa de mercado, projeto de componentes, projeto de processo, teste, início da produção, alteração de engenharia; 3. estudo de viabilidade, projeto preliminar, projeto detalhado, revisão e testes, modificações; 4. conceber produto, conceituar produto, projetar produto e processo, homologar produto e processo, ensinar empresa, produção, avaliação e ações corretivas. Existem empresas que definem avaliações intermediárias dos resultados do projeto no meio das fases. Nesses casos, os gates podem ser direcionados aos aspectos técnicos do projeto.

62

PARTE 1

O Processo

time de desenvolvimento. Imagine agora que estamos na fase de lançamento, na qual todos os desenhos, processos, ferramental, máquinas etc. já foram definidos, especificados, comprados, construídos etc. O custo de modificação nesse momento, dependendo do grau de mudança, é da ordem de até mil vezes o custo da mudança da fase do projeto informacional (Figura 2.15). Figura 2.15

Custo de mudanças cresce exponencialmente nas fases finais do desenvolvimento.

Mudanças sempre ocorrem, dada a natureza do processo de desenvolvimento, e o importante é fazer com que elas ocorram no início do desenvolvimento (Figura 2.16), quando o custo das alterações é menor. Esse é um dos objetivos da Engenharia Simultânea.12 Figura 2.16

12

Um dos objetivos da Engenharia Simultânea é fazer com que mudanças no produto ocorram no início da macrofase de desenvolvimento.

Veja o Quadro 2.3, a seguir, para saber o que é Engenharia Simultânea.

CAPÍTULO 2

O Modelo Unificado do PDP

Quadro 2.3

63

O que é Engenharia Simultânea

O termo Engenharia Simultânea vem sendo utilizado há anos com significados diferentes, porém complementares. Alguns autores também empregam o termo Engenharia Concorrente, mas, em português, esse termo não tem o mesmo significado que em inglês (Concurrent Engineering). Uma das primeiras iniciativas foi aumentar o grau de paralelismo entre as atividades de desenvolvimento, com ênfase na realização simultânea das tarefas de projeto e planejamento de processo. Apesar de um pouco teórica, essa iniciativa pregava que atividades, que eram iniciadas somente após o término e a aprovação das atividades anteriores, deveriam ser antecipadas de forma que seu início não dependesse dos demorados ciclos de aprovação (além disso, ciclos de aprovação “não agregam valor ao produto”). Para isso, os projetistas e processistas deveriam trabalhar em um mesmo time. Desde então, esse conceito vem evoluindo. Algumas empresas consideram a Engenharia Simultânea como um método que pode ser aprendido e utilizado, assim como o método de projeto robusto (por exemplo). Ela representa, no entanto, um conceito de trabalho mais amplo e envolve várias técnicas. Os objetivos da Engenharia Simultânea são os mesmos de outras técnicas de melhoria de processo:

• aumento de qualidade do produto, com foco no cliente; • diminuição do ciclo de desenvolvimento; e • diminuição de custos. Esses objetivos podem ser desdobrados em vários objetivos intermediários, como o apresentado no texto, de se diminuir a quantidade de mudanças nas fases finais do desenvolvimento. Isso, em última análise, diminui o tempo e os custos de desenvolvimento. Engenharia Simultânea é uma filosofia utilizada no processo de desenvolvimento de produtos. É uma abordagem sistemática, que possui os seguintes princípios:

• deve-se trabalhar em equipe, pregando-se a cooperação e confiança entre seus membros, assim como o compartilhamento de conhecimentos;

• devem fazer parte dessa equipe os clientes e fornecedores, enfim, todos os parceiros da cadeia de suprimentos; • as pessoas envolvidas no desenvolvimento devem considerar, desde o início, todos os elementos do ciclo de vida do produto, da concepção ao descarte, incluindo qualidade, custo, prazos e requisitos dos clientes; e

• enfatiza o atendimento das expectativas dos clientes. Além disso, a prática de Engenharia Simultânea faz uso de métodos e sistemas integrados de engenharia, tais como QFD, 13 FMEA, DFx, CAD/CAE, CAPP, PLM . Observa-se que o conceito de Engenharia Simultânea se confunde com o de desenvolvimento integrado de produtos, que é o conteúdo apresentado neste livro. Não se consegue tratar hoje de Engenharia Simultânea sem que seja considerada a visão de processo na sistematização do PDP.

2.5.2 O início e o fim do desenvolvimento A macrofase anterior produz informações necessárias para a realização do desenvolvimento, tanto do ponto de vista tecnológico, comercial e financeiro como do ponto de vista organizacional, ou seja, como se deve conduzir o projeto de desenvolvimento. Mas cada projeto é um caso específico. Dependendo de vários fatores, como grau de maturidade tecnológica, nível de inovação do produto, mercado, estratégias etc., estão disponíveis mais ou menos informações para o time de desenvolvimento. O time de desenvolvimento varia em tamanho e tipo de membro, dependendo O time de da fase. No início trabalham mais os representantes das áreas comercial e de markedesenvolvimento ting, pois é o momento em que se definem os requisitos do produto a partir das necessidades do mercado, culminando com a concepção do produto. No final, a maior parte do time é formada por pessoas das áreas de engenharia e produção. Porém sempre existe um time central multidisciplinar permanente participando de todas as fases de desenvolvimento, com o intuito de garantir uma 13

O significado dessas siglas encontra-se no Apêndice III deste livro.

64

PARTE 1

O Processo

continuidade de conhecimento ao longo dessa macrofase. Esse time comumente é dissolvido ao final do desenvolvimento, ou melhor, após acompanhar o resultado dos primeiros lotes do produto no mercado. Se o produto for inovador, o tempo de acompanhamento no começo da comercialização é maior do que nos produtos derivados. Tipicamente, o desenvolvimento parte das informações geradas pela macroInformações iniciais fase de pré-desenvolvimento, e documentadas no plano do projeto. Como pôde ser visto na Figura 2.9, o plano de projeto é constituído por: escopo do projeto, escopo do produto (conceito do produto), atividades e sua duração, prazos, orçamento, pessoal responsável, recursos necessários para realizar o projeto, especificação dos critérios e procedimentos para avaliação da qualidade (assim como possíveis normas que precisam ser atendidas), análise de riscos, indicadores de desempenho selecionados para o projeto e produto (com seus valores-alvo). Ao final dessa macrofase são produzidas informações técnicas detalhadas, de Resultados da macrofase produção e comerciais relacionadas com o produto; os protótipos já foram aprode desenvolvimento vados; os recursos a serem utilizados para a sua produção, comercialização e suporte técnico foram comprados, recebidos, testados e instalados; alguns produtos foram fabricados e aprovados; já ocorreu o lançamento no mercado e as pessoas da cadeia de suprimentos estão informadas e treinadas — tanto aquelas de empresas parceiras no fornecimento quanto as que estão envolvidas na comercialização e suporte. Em alguns casos, novos processos de negócio de produção, atendimento ao cliente e assistência técnica foram desenhados e implementados. Esses resultados estão resumidamente representados na Figura 2.9 por: especificações finais, liberação da produção e documento de lançamento. O time de desenvolvimento será constituído no início da macrofase de desenInicia-se com a volvimento por pessoas de diversas áreas da empresa, com ênfase nas áreas comerdeterminação de todas as cial e de marketing, mas sendo auxiliadas pelos engenheiros e pessoal da produção. especificações-meta O time de projeto tem em mãos a Minuta do Projeto e o Plano do Projeto, este úldo produto timo um plano detalhado contendo atividades, recursos, riscos, análise econômico-financeira e várias outras informações (veja a Figura 2.9). O primeiro passo será obter um entendimento comum do que está no plano do projeto, chegando a uma definição final sobre o problema do projeto, ou seja, o que se pretende atingir (“resolver”) com o produto. Eles identificam, então, as pessoas envolvidas com o produto durante o seu ciclo de vida (clientes, pessoal da assistência técnica, manufatura etc.) e levantam quais são as suas necessidades, complementando, assim, com o uso de diversas técnicas e métodos (apresentados no Capítulo 6) as informações recebidas da macrofase anterior. Com base nessas necessidades e requisitos, todas as especificações-meta do produto são determinadas e documentadas. O envolvimento das pessoas da cadeia de suprimentos e o contato com clientes em potencial são primordiais para garantir a qualidade das especificações. A seguir, são listados alguns exemplos de especificações: relacionadas às necessidades dos clientes em termos de parâmetros do produto, tais como: tamanho, peso, aparência e grandezas elétricas do produto; normas técnicas, de qualidade e de meio ambiente a que o produto precisa atender; informações mais precisas sobre parceiros no desenvolvimento e comercialização do produto com a determinação de parceiros-chave; verificação se a tecnologia a ser utilizada no produto está madura e pode ser usada; informações mais completas sobre as características de produtos concorrentes, se existirem; definição mais precisa do mercado e das vendas futuras, como volume de vendas esperado durante um período, preço que o mercado pagaria; e análise financeira do produto, mostrando se ele ainda seria rentável perante as novas informações disponíveis nas especificações. Com base nas especificações, são estabelecidas as estruturas funcionais do proDeve-se partir de uma duto, ou seja, quais as funções (físicas, de qualidade, estéticas etc.) ele deve possuir concepção para para atender aos requisitos de todas as pessoas que entrarão em contato com o prose projetar duto no decorrer do seu ciclo de vida, consumidores, técnicos de assistência técnica, vendedores etc., isto é, os clientes do produto. O time de desenvolvimento nesse momento envolve-se mais estreitamente com os parceiros e fornecedores da cadeia de suprimentos. Em conjunto são definidas as alternativas de solução, que correspondem às soluções construtivas e tecnológicas, as quais, por sua vez, fornecem as funções esperadas do produto. A melhor solução (ou as melhores soluções alternativas) é selecionada e verifica-se se ela garante um retorno financeiro, de acordo com o plano de negócio definido anteriormente.

CAPÍTULO 2

O Modelo Unificado do PDP

65

As soluções são detalhadas em informações técnicas, com a definição dos sistemas, subsistemas e componentes do produto. Fazem parte dessas informações, por exemplo, desenhos de conjunto do produto; cálculos preliminares de engenharia; esquemas com a definição da arquitetura do produto. Todas essas informações são reunidas em uma concepção do produto, que contém todos os elementos para decidir se o produto pensado no momento do plano de negócio vai ser viável ou não. Isso quer dizer que, mais uma vez, o estudo de viabilidade econômico-financeira é atualizado para avaliar o retorno financeiro que esse produto trará para a empresa. Nessa ocasião, o time de desenvolvimento tem o envolvimento cada vez maior Informações são de pessoas das áreas técnicas relacionadas com as tecnologias do produto e sua prodetalhadas, protótipos dução. Paralelamente aos projetos conceituais, pode-se detalhar informações e estestados e produto pecificações do produto (principalmente para projetos derivados), trabalhando-se homologado no conceito de Engenharia Simultânea. Inicia-se um processo de Projetar-Construir-Testar-Otimizar o produto em ciclos de detalhamento e otimização até a homologação do produto. Além de realizar todos os cálculos e desenhos detalhados, o time planeja como o produto vai ser produzido e lançado no mercado. Não se pode esquecer aqui dos manuais do cliente, técnico e para o pessoal de assistência técnica, assim como possíveis sistemas de apoio a vendas. Um exemplo aqui são os sistemas específicos de configuração de produtos, que os vendedores de elevadores possuem e levam junto quando eles vão visitar uma obra de construção de um prédio. Com alguns poucos dados da obra, eles podem fazer uma proposta comercial, graças às opções existentes nesses sistemas de configuração. Os processos de manufatura são finalizados contendo a seqüência de fabricação; as especificações das máquinas e das ferramentas; os métodos de produção; enfim todos os documentos que são necessários para se produzir o produto com qualidade. Em alguns casos, esses planos de processo de fabricação objetivam a produção em série. A obtenção da documentação de fabricação também pode ser obtida quase ao mesmo tempo em que são criados os desenhos de detalhamento, quando a empresa aplicar os princípios da Engenharia Simultânea. Nesse momento, existem ainda alguns itens do produto, que não são estratégicos, e deve-se definir o que será produzido dentro da própria empresa e o que será comprado dentro da cadeia de suprimentos. Anteriormente, já haviam sido determinados os parceiros mais estratégicos, agora outros fornecedores serão definidos. Em alguns casos, a cadeia de suprimentos é criada para o produto em questão; em outras palavras, é estabelecido todo o conjunto de fornecedores que, juntos, produzirão os componentes, tecnologia e serviços que garantirão que o produto chegue ao mercado com sucesso no tempo determinado. Paralelamente, os protótipos são produzidos e testados, e assim o produto é homologado. Homologar significa verificar se o protótipo atende todos os requisitos anteriormente definidos e/ou padrões específicos da indústria. Por exemplo, para produtos da linha branca e elétricos, há uma série de normas, nacionais e 14 internacionais, que precisam ser atendidas. Algumas delas possuem instituições, como o Inmetro , que fazem testes e emitem certificados, chamados selos de qualidade. Falta agora saber se a empresa (na verdade, a cadeia de suprimentos total, ou seja, todos os parceiros de fornecimento) consegue produzir produtos em série (quando for o caso) com as mesmas qualidades do protótipo e que também atendam aos requisitos dos seus clientes ao longo do ciclo de vida do produto. Todos os equipamentos necessários à produção do produto são especificados e adquiridos durante a confecção do projeto, pois, caso contrário, os prazos de lançamento serão mais longos. Muitas vezes, a produção exige equipamentos especiais, que não são encontrados no mercado de máquinas em geral. E, em alguns casos, esses equipamentos trazem um diferencial em produtividade, o que torna o produto competitivo. Em alguns casos, esses equipamentos são fabricados na própria empresa, pois são eles que garantem a vantagem competitiva do produto, e deverão ser finalizados ainda na fase de desenvolvimento. Hoje em dia, no entanto, é mais comum terceirizar as atividades de fabricação desses equipamentos.

14

Instituto Nacional de Metrologia, Normalização e Qualidade Industrial (http://www.inmetro.gov.br).

66

PARTE 1

O Processo

Começam a chegar os equipamentos comprados e os primeiros lotes de peças dos fornecedores. As máquinas precisam ser testadas com o uso das novas ferramentas para produção que também começam a ficar prontas. Em alguns casos, novas instalações (fábricas) precisarão ser construídas para a manufatura do novo produto. Quando o volume de produção é pequeno ou há capacidade ociosa na empresa, os equipamentos existentes podem dar conta do novo produto. Em qualquer um desses casos, realiza-se a produção inicial de um lote piloto, que é avaliado para provar que a empresa consegue obter produtos com as mesmas características do protótipo (ou melhores). Os atrasos costumam ser fatais, pois a falta de uma única peça específica, mesmo que simplória e no valor de centavos, pode impedir a produção de um produto complexo de milhares de reais. No final dessa macrofase, termina-se, por assim dizer, o projeto de desenvolvimento. A maior parte das metodologias de projeto termina nesse ponto. O nosso modelo de referência abrange todo o ciclo de vida do produto. Normalmente, o time de desenvolvimento se desfaz ou parte dele acompanha o início do período de comercialização, quando ocorrerem os primeiros problemas. Na fase de produção e comercialização do produto, são outros os processos de negócio que ficam no primeiro plano, e o processo de desenvolvimento de produtos ocorre paralelamente, realizando as atividades mostradas na próxima macrofase. Os equipamentos chegam, a produção inicia e o produto é lançado

2.6

Visão geral da macrofase de pós-desenvolvimento

2.6.1 Por que pós-desenvolvimento? Nas publicações mais tradicionais e mesmo em muitas empresas, o final da macrofase de desenvolvimento apresentada no tópico anterior representa o final do processo de desenvolvimento de produtos. É o momento em que a “engenharia passa o bastão para a produção”. Essa visão pode fazer com que as empresas desperdicem os conhecimentos adquiridos durante a fase de produção e comercialização do produto, como ilustrado no exemplo a seguir. Uma empresa fabricante de tratores acabou de lançar um novo produto no mercado e passou a responsabilidade pelo produto ao setor de manufatura. O time de desenvolvimento foi desfeito, as pessoas voltaram para as suas áreas funcionais e outras foram alocadas em novos projetos. Nenhuma dessas pessoas terá mais contato com o produto, que eles acabaram de desenvolver. Elas até podem reutilizar as informaExemplos de falta de gestão de conhecimento ções que foram criadas, mas sem o crivo da aplicação prática para verificar a qualidade dessas informações em casos reais. No entanto, o desempenho do trator em campo não está sendo o esperado. A empresa possui um departamento de assistência técnica com pessoas experientes, e a única pessoa desse departamento que participou do desenvolvimento do produto está alocada em um outro projeto. Eles conseguem resolver o problema de campo, que surgiu por uma falta de dirigibilidade do trator, causada por um problema da bomba hidráulica do comando de direção. A especificação da bomba foi modificada. No entanto, eles demoraram três meses para descobrir a causa e, com isso, perderam muitos clientes. Constataram que três anos atrás, um outro trator da mesma família apresentou o mesmo tipo de problema. Como foi que eles incorreram no mesmo erro? Foi falta de uma gestão de conhecimentos adequada que pudesse garantir o registro das lições aprendidas no campo para reutilização em projetos futuros. Ou seja, não existiu um pós-desenvolvimento sistematizado e, assim, eles perderam a chance de aprender com os problemas do passado, causando muitas perdas atuais, que poderiam ter sido evitadas. Esse mesmo trator permaneceu no mercado por cinco anos e, durante esse período, ele apresentou outros problemas. O volume de venda não foi o esperado, assim como o preço que foi cobrado. Após a sua substituição

CAPÍTULO 2

O Modelo Unificado do PDP

67

por um modelo novo da mesma família, a empresa ainda teve que dar manutenção aos tratores em campo e nunca soube com uma certa precisão qual o retorno que eles tiveram com o trator, para comparar com os dados iniciais dos estudos de viabilidade econômica do projeto de desenvolvimento e do trator. Durante a macrofase de desenvolvimento, o protótipo do trator tinha apresentado um problema de fadiga em sua estrutura, solucionado por especialistas em cálculo estrutural. No entanto, na aplicação prática, surgiram novas condições de uso que não tinham sido previstas, e o trator passou a apresentar o mesmo problema. Porém, aqueles especialistas estavam alocados em outros projetos, e o pessoal de assistência técnica levou as novas dificuldades para pessoas que não participaram do desenvolvimento. Demorou dois meses para se chegar a mesma solução que o time de desenvolvimento tinha proposto durante a fase de teste do protótipo. Por que isso ocorreu? Porque não foi designado um time de acompanhamento do produto nem existia na empresa um pós-desenvolvimento sistematizado, que garantisse uma continuidade à gestão do ciclo de vida do produto. Os conhecimentos gerados ficaram com as pessoas, e a empresa não os aproveitou. A empresa não aprendeu. Esses são exemplos, entre vários possíveis, do que a falta da macrofase de pós-desenvolvimento pode causar em uma empresa. O acompanhamento sistemático e a documentação correspondente das melhorias de produto ocorridas durante o seu ciclo de vida são atividades centrais do pós-desenvolvimento.

Atividade central do pós-desenvolvimento: acompanhar o produto

O acompanhamento recebe informações de todos os processos envolvidos com o produto: do monitoramento dos resultados do produto no mercado; da produção e distribuição do produto; do atendimento ao cliente; e da assistência técnica. Essas informações são processadas pelo acompanhamento que, quando necessário, aciona os processos de apoio correspondentes de gerenciamento das mudanças de enge15 nharia; ou de melhoria do PDP . A macrofase de pós-desenvolvimento compreende a retirada sistemática do produto do mercado e, finalmente, uma avaliação de todo o ciclo de vida do produto, para que as experiências contrapostas ao que foi planejado anteriormente sirvam de referência a desenvolvimentos futuros. Graças ao pós-desenvolvimento, garante-se que parte das pessoas e o conheciRazão do mento acumulado durante o desenvolvimento estejam à disposição da empresa no pós-desenvolvimento acompanhamento da vida do produto. Garante-se, ainda, que os conhecimentos adquiridos durante esse período sejam sistematizados e documentados, viabilizando a sua reutilização em novos projetos de desenvolvimento. Além disso, o pós-desenvolvimento compreende a retirada sistemática do produto do mercado, fazendo com que os requisitos de gestão do meio ambiente sejam considerados, para que, novamente aqui, a experiência possa ser útil em um novo desenvolvimento. A retirada pode envolver o reuso do produto (ou parte dele) em um outro, a desmontagem do produto e a utilização de suas partes ou material; a reciclagem do material empregado no produto; ou o descarte completo. Finalmente, no pós-desenvolvimento, acontece uma avaliação de todo o ciclo de vida a posteriori, para averiguar o grau de acerto do planejamento econômico anteriormente realizado e suas atualizações durante o ciclo de vida, a fim de se criar um padrão de previsões na empresa.

2.6.2 O início e o fim do pós-desenvolvimento Primeiro devemos ressaltar a duração dessa macrofase. Observe novamente a Figura 2.8. Veja que o tempo de duração dessa macrofase é bem superior ao tempo das demais fases. Um produto fica no mercado por muito tempo, quando comparado com o tempo de planejamento e de desenvolvimento. Hoje em dia, aumentou a freqüência de substituição dos produtos e, portanto, o seu ciclo de vida diminuiu, fazendo com que tenhamos de lançar mais produtos em menos tempo. Mesmo assim, em alguns casos, essa macrofase dura vários anos.

15

Descritos no Capítulo 13, tópicos 13.1 e 13.2, respectivamente.

68

PARTE 1

O Processo

Após a entrega dos primeiros lotes de produtos no mercado, quando se finaliza o projeto de desenvolvimento, o time de desenvolvimento é dissolvido, e os seus membros são deslocados para outros projetos ou retornam para as suas áreas funcionais. Nessa ocasião é formado o time de acompanhamento do produto, que é composto por membros do time de desenvolvimento acrescidos de pessoas responsáveis pela produção e assistência técnica do produto. Apesar de receber o nome de time, os seus membros não trabalham com dedicação exclusiva para o produto, mas estão disponíveis para atenderem chamados emergenciais. Normalmente, eles cumprem as suas obrigações funcionais nos departamentos em que estão alocados ou mesmo nos projetos em que estão atuando. No entanto, é bom que sejam designadas pessoas que participaram do desenvolvimento, pois elas preservam a memória do desenvolvimento. Existem várias configurações possíveis para esse time. Em qualquer uma delas, porém, deve-se alocar membros do time de desenvolvimento, para garantir uma continuidade e passagem de conhecimentos. Outras pessoas da organização também possuem funções operacionais relacionadas ao acompanhamento do produto, como o pessoal de assistência técnica, mas elas não fazem parte do time de acompanhamento e, provavelmente, não participaram do time de desenvolvimento. Elas estão formalmente alocadas a esse outro processo de negócio. E não necessariamente lidam apenas com um produto, dependendo de sua importância na empresa e volume no mercado. Esse time tem o conhecimento profundo de todos os aspectos do produto e Inicia-se pelo realiza um planejamento do acompanhamento do produto no pós-desenvolviplanejamento mento. Esse planejamento deve estar em consonância com todos os planos definidos durante a macrofase de desenvolvimento. Ele define as principais atividades e os responsáveis, ou seja, quem responderá pela interface com os dados do produto que podem ser atualizados durante todo o ciclo de vida e pelas atividades operacionais (normalmente departamentos estabelecidos para esse fim). Além disso, estabelece como será o procedimento em um momento de necessidade, quando, por algum motivo, o produto falhar no mercado, e, também, quando e como acionar o processo de apoio de gerenciamento de mudanças de engenharia. Na fase de acompanhamento, o time reúne as informações de todos os processos Integração e consolidação envolvidos com o produto: do monitoramento dos resultados do produto no merdas informações recebidas cado; da produção e distribuição do produto; do atendimento ao cliente; e da assisde outros processos tência técnica. Essas informações são processadas e consolidadas por membros do time, que são consultados quando necessário para realizar análises mais elaboradas. Essa fase possui duas atividades operacionais: a avaliação da satisfação do cliente e o monitoramento do desempenho técnico do produto. E três que ocorrem esporadicamente: as auditorias, o acompanhamento das modificações do produto, quando acionadas por um dos processos listados anteriormente, e o registro das lições aprendidas. A avaliação da satisfação do cliente pode ser realizada pelas pessoas responsáveis pelo produto que trabalham na área de marketing e é uma forma proativa da empresa ir a campo e verificar a percepção do cliente com relação ao produto. Por sua vez, o monitoramento pode ocorrer por meio da análise das informações recebidas de diversos canais de comunicação com o mercado, existentes nos processos de atendimento ao cliente (que recolhe opiniões e reclamações de clientes insatisfeitos) e de assistência técnica (traz as experiências de campo). O monitoramento pode envolver questões técnicas, econômicas, de produção e de serviços. De tempos em tempos, deve-se realizar auditorias para se avaliar em detalhes esses aspectos do produto. Essas auditorias podem estar associadas à avaliação da satisfação dos clientes, mas não devem ser limitadas a essas questões. Cada vez que a solução de um problema, ou mesmo uma oportunidade de melhoria, implicar mudança de alguma especificação do produto ou processo, deve-se gerenciar de forma sistemática a introdução dessa mudança na empresa. Em razão de sua importância e abrangência, o gerenciamento de mudanças de engenharia ocorre em um outro processo, considerado de apoio, pois, como mencionado anteriormente, o time de acompanhamento não tem dedicação exclusiva para o produto corrente. Além disso, o gerenciamento de mudanças não O time de acompanhamento

CAPÍTULO 2

O Modelo Unificado do PDP

69

ocorre somente durante a fase de produção, mas pode ocorrer, também, durante a macrofase de desenvolvimento, quando certas informações do produto já estiverem “congeladas”. Isso evita que aconteçam inconsistências entre as informações armazenadas e que os impactos das mudanças sejam avaliados, evitando vários desperdícios. Em alguns casos, na fase de acompanhamento, são detectadas inconsistências nas informações do produto ou processo, que surgiram por uma falha no próprio processo de desenvolvimento de produtos. Nesses casos, eles encaminham ou propõem uma melhoria no PDP. Essa melhoria é gerenciada por meio de um outro processo de apoio. Por exemplo, imagine que uma empresa de espelhos retrovisores automotivos Exemplo de falta de resolva atender a uma reivindicação de uma melhoria estética no produto, considegerenciamento de rada não urgente pelo cliente. E que ainda exista matéria-prima disponível para a mudanças de engenharia produção de 10 mil peças. Se ela implantar a mudança, sem utilizar o material disponível, estará desperdiçando seus recursos. Ou seja, ela deveria realizar a mudança, mas implantá-la somente após esgotar toda a matéria-prima anterior. Imagine ainda que essa mudança envolva uma atualização da geometria da peça, realizada pelos projetistas da empresa, resultando em um novo modelo geométrico dentro da base de dados do sistema CAD. Se não houver um controle efetivo da integridade das informações, pode ser que a área de processos de fabricação não receba a nova geometria e continue a produzir matrizes de injeção plástica com base na geometria antiga. Ou seja, apesar de a alteração ter sido realizada pelos engenheiros, os processistas não foram informados, e a empresa continuará a produzir espelhos com a geometria antiga. O gerenciamento sistemático das mudanças de engenharia procura evitar esses problemas (veja o Capítulo 13). Assim como nas fases de desenvolvimento, no pós-desenvolvimento deve-se Registre todas as lições registrar de forma sistemática todas as lições aprendidas durante o acompanhaaprendidas mento do produto. Elas devem estar armazenadas de tal maneira, que pessoas não envolvidas com o presente projeto possam reutilizar essas experiências, evitando incorrer nos mesmos erros no futuro. Pode ser que o momento de finalização da produção coincida com a retirada do Enfim o produto é retirado produto do mercado. Mas como o modelo de referência deste livro lida com prodo mercado dutos duráveis, mesmo que sejam de consumo, normalmente a empresa pára de produzi-los, mas eles ainda permanecem no mercado durante um tempo. Por isso, tratamos nesta macrofase de dois momentos distintos: o de encerramento da produção e o de retirada do produto do mercado. O momento de encerramento da produção é acompanhado por uma definição de quem será o fornecedor de produtos de reposição e serviços. No momento da retirada do produto de mercado, deve-se acionar os planos previstos para reúso, reciclagem ou descarte do produto. Um bom desenvolvimento deve prever essas atividades desde o levantamento dos requisitos do produto e a definição de soluções que atendam a esses requisitos, quando o ciclo de vida do produto é analisado. O planejamento do pós-desenvolvimento trata dessas questões somente do ponto de vista organizacional, pois as questões técnicas são consideradas durante o desenvolvimento. No final do ciclo de vida, são reunidas todas as informações associadas àquele O ciclo de vida é encerrado produto para permitir que elas sejam reutilizadas no futuro. São anexadas ao projeto de desenvolvimento, que foi finalizado no término da macrofase de desenvolvimento, todas as informações e conhecimentos relevantes, que surgiram durante a macrofase de pós-desenvolvimento. A associação das informações relacionadas com o produto acontece na verdade de forma contínua durante todo o ciclo de vida. No final, acrescenta-se um documento formal de fim de vida, no qual se avalia o retorno real que o produto trouxe à empresa, comparando-se com o que foi planejado.

70

PARTE 1

O Processo

2.6.3 Pós-desenvolvimento é para todos? Assim como a macrofase de pré-desenvolvimento, pode parecer que o pós-desenvolvimento só deve ser aplicado em grandes empresas. Não! Nas empresas grandes com produtos complexos, como é o caso da indústria aeronáutica, o pós-desenvolvimento é vital e uma exigência dos clientes e instituições que regulam o setor. O acompanhamento da operação das aeronaves pode durar até 40 anos, pois o fabricante é obrigado a realizar essas atividades enquanto existir um número mínimo de produtos em uso. Nessas empresas, deve-se estabelecer todos os papéis citados, o time de acompanhamento e as áreas envolvidas devem ser muito bem definidas. Em uma empresa pequena, por exemplo, uma empresa de fabricação de máquinas de pequeno porte com 30 funcionários ao todo, as mesmas fases e atividades podem ser realizadas, pois os clientes podem voltar a realizar consultas ou solicitar melhorias nos produtos comprados. Nesse caso, um pequeno time pode atender essas necessidades, por exemplo: uma pessoa da engenharia, que estaria à disposição quando algum problema ocorresse e necessitasse de atualização do produto; uma pessoa da assistência técnica, que, de qualquer maneira, estaria em contato com o produto em campo; e outra do controle da qualidade. O gerenciamento de mudanças poderia utilizar um sistema de registro das modificações integrado a um sistema de gerenciamento de documentos. Em casos mais simples, uma planilha poderia auxiliar a área de engenharia. Mesmo no caso de produtos de bens de consumo muito simples, ao menos parte das atividades dessa macrofase precisará ser realizada. É o caso do registro das lições aprendidas, problemas e falhas do produto no mercado. Uma empresa pequena pode utilizar ferramentas simples. Um exemplo: pode-se criar um arquivo de texto, no qual os problemas e suas causas seriam registrados. Logicamente, esse seria um primeiro nível de organização, que deveria evoluir com o tempo, fazendo uso de ferramentas modernas de recuperação dessas informações. No entanto, só para exemplificar, nos sistemas operacionais Windows, existe a função de busca de texto dentro de arquivos. Essa seria uma forma inicial de recuperar as informações registradas nos arquivos de lições aprendidas. O importante é adotar os conceitos existentes no modelo de referência e adaptá-los à realidade da empresa. Agora que já entendemos de maneira geral o processo de desenvolvimento de produtos descrito pelo modelo deste livro e também conhecemos com um pouco mais de profundidade as macrofases desse processo, vamos estudar quatro conceitos importantes desta nossa proposta. O primeiro é a sistemática de revisão de fases (gates).

2.7

Revisão de fases (gates)

Evolução da sistemática de revisão de fases

No final de cada fase do processo de desenvolvimento, deve acontecer uma revisão e aprovação formal dos produtos. Adota-se o termo em inglês gate, que, traduzido literalmente, significa portão. Ou seja, é a passagem de uma fase para outra. Se todos os requisitos necessários forem cumpridos, pode-se iniciar a fase seguinte. A introdução da sistemática formalizada de gates é uma prática que traz grandes benefícios para o desempenho da empresa. Um entre os diferenciais do modelo proposto neste livro é o de estabelecer formalmente a realização desse tipo de avaliação. Em um primeiro momento, os requisitos que condicionavam a passagem de uma fase para outra estavam na verificação do cumprimento das atividades planejadas. Ou seja, se 10 tarefas tinham sido planejadas para aquela fase e caso, ao final dela, verificava-se que elas tinham sido realizadas, considerava-se, então, que o projeto estava cumprindo os objetivos. Em seguida, passou-se a avaliar a qualidade dos resultados obtidos na fase. Essa verificação envolvia diversos aspectos tecnológicos, comerciais e financeiros. A geração

CAPÍTULO 2

O Modelo Unificado do PDP

71

mais recente da sistemática de gates considera ainda o valor do presente projeto perante os demais da empresa, ou seja, responde às seguintes questões básicas e cruciais para a continuidade do projeto: As atividades foram cumpridas, os resultados estão dentro dos previstos, mas será que ocorreram mudanças no mercado (necessidade dos clientes, concorrência e condições econômicas) que inviabilizaram o sucesso do produto e, portanto, a continuidade desse projeto? Se sim, deveríamos, então, investir os nossos recursos e esforços em outros projetos? Em outras palavras, coloca-se a perspectiva de negócio na avaliação do projeto para garantir que ele esteja sempre alinhado às estratégias da empresa, pois, afinal de contas, foram com base nelas que se definiu o portfólio de produtos/projetos (na fase de planejamento da estratégia). Imagine que estamos criando uma nova impressora que imprime simultaneaExemplo de gates mente os dois lados de uma folha. Nós seremos os primeiros a lançá-la no mercado. A tecnologia é cara, mas vale a pena, pois, ao sermos os primeiros, atingiremos um grande volume de vendas, segundo os estudos de marketing que recebemos. Isso garantiria um fluxo de caixa que pagaria todas as despesas com o desenvolvimento e a tecnologia, e o retorno seria ainda muito significativo, segundo o estudo aprovado pelo setor financeiro. Estamos no gate da fase de projeto informacional para ver se podemos passar para o projeto conceitual. Cumprimos todos os prazos (na verdade, estamos dois meses adiantados) e as informações do projeto informacional são alentadoras. No momento do gate, a inteligência de mercado traz a informação de que o nosso maior concorrente vai lançar em um mês uma impressora similar com a mesma tecnologia, ou seja, seis meses antes de conseguirmos colocar o primeiro lote piloto no mercado. O que fazemos? Com o lançamento do produto do mesmo tipo pelo nosso maior concorrente, antes do nosso produto inovador entrar no mercado, podermos ter o seguinte cenário: ■

■

■

O volume previsto de vendas não será o mesmo, e, assim, as premissas do nosso estudo de viabilidade econômica mudam. Provavelmente, não atingiremos mais os indicadores financeiros previstos na nossa análise de investimento. Não teremos mais o retorno esperado. Vamos perder dinheiro com esse produto. Não seremos os primeiros a lançar o produto, e a nossa imagem de inovadores ficará cada vez mais desgastada.

Então, temos de tomar uma decisão dentro de certas alternativas: É melhor abortar o projeto agora do que investir mais? Vamos passar o que desenvolvemos até agora para uma outra empresa? Devemos colocar os nossos esforços em uma outra linha de impressoras de baixo custo, cujo desenvolvimento estava congelado, pois não tínhamos recursos para desenvolver os dois produtos ao mesmo tempo? Somente com uma revisão de fase que possibilite a visão geral do portfólio é que podemos tomar tais decisões. É isso que significa um processo de gate segundo a melhor prática atual. É aquele no qual são considerados conjuntamente os aspectos técnicos do produto, de gerenciamento do projeto e da situação do mercado, sem esquecer o projeto em relação aos demais produtos e projetos da empresa. Pelo exemplo apresentado, pode-se observar que, no momento da revisão de fase, os Sistemática de gate resultados do projeto são avaliados individualmente. Além disso, precisamos verificar se o projeto ainda é o mais atrativo para empresa, considerando o portfólio de projetos. A sistemática de gates está ilustrada na Figura 2.17 e possui as seguintes atividades: ■ ■ ■

a definição dos critérios a serem utilizados ao final de uma fase; a avaliação constante pelo time de desenvolvimento se os critérios estiverem sendo cumpridos ou não; e a realização do gate propriamente dito, o qual é dividido em duas atividades: • auto-avaliação realizada pelo próprio time de desenvolvimento; e • aprovação; quando o relatório da auto-avaliação é analisado pelo time de avaliação, o presente projeto é comparado com os demais do portfólio e com a análise do estudo de viabilidade econômica.

72

PARTE 1

O Processo

Na definição dos critérios, toma-se como base um “catálogo” de critérios, isto é, um conjunto de critérios que serve como checklist.Esse catálogo deve fazer parte do modelo de referência da empresa. O time de desenvolvimento em conjunto com o time de avaliação define os critérios a serem utilizados em cada fase, assim como os valores dos critérios quantitativos, escolhendo, desse catálogo, quais critérios são pertinentes para aquele projeto específico. Essa definição deve ocorrer bem antes do gate, porque, caso contrário, o time de desenvolvimento tende a adotar somente critérios que eles sabem por antemão que serão aprovados (normalmente, esses critérios são definidos nas atividades de planejamento do projeto e no gate anterior). É vantajoso também que os responsáveis pela gestão do PDP identifiquem nesse catálogo quais critérios devem ser obrigatórios e quais são uma opção do time de projeto, conforme a natureza do critério. Figura 2.17

Sistemática de gates.

A premissa de que o time de desenvolvimento sabe com antecedência como o seu trabalho será avaliado, tendo ele próprio participado da definição dos critérios, é fundamental para o sucesso da implantação dos gates, pois possibilita a transparência do processo de avaliação. O gerente e o time conhecerão os critérios e, com isso, estarão atentos a questões relevantes para a aprovação da fase do projeto. A realização de gates é uma atividade coletiva e, como tal, acontece basicamente Cuidados e planejamento por meio de reuniões. A eficiência com que as reuniões são planejadas e realizadas é nas reuniões são fundamental para o sucesso da prática. É comum o surgimento de resistências quanfundamentais para o do as reuniões são vistas como improdutivas. O tempo consumido dos diversos técsucesso dos gates nicos e gerentes envolvidos é um investimento que a empresa está realizando no projeto e, como tal, precisa surtir resultados. Valem os mesmos cuidados gerais para qualquer tipo de reunião de negócio, conforme o Quadro 2.4, a seguir. No caso específico de reuniões de gates, um problema muito comum é a dispersão. Nessas reuniões é comum misturar gerentes e diretores, preocupados com o andamento do projeto em seu todo e os impactos no negócio, com técnicos das diversas áreas: financeira, de engenharia e outras. Quando um problema eminentemente técnico emerge, por exemplo, os especialistas podem começar uma discussão técnica, fugindo do escopo da decisão que, no caso, seria a solução em termos de ações que precisam ser realizadas. Nesses momentos, os demais participantes sentirão a sensação de improdutividade. O mesmo acontece em questões gerenciais que

CAPÍTULO 2

O Modelo Unificado do PDP

73

dispersam para discussões conceituais ou o histórico do problema, desestimulando, dessa vez, as pessoas com formação mais técnica. Deve-se redobrar, portanto, a atenção ao aspecto da dispersão ao se introduzir a sistemática de gates. Quadro 2.4

Diretrizes para a Realização de Reuniões Produtivas

As atividades em grupo por meio de reuniões são uma das principais ferramentas durante todo o processo de desenvolvimento de produto, em especial nos gates. Apesar das inúmeras vantagens, a produtividade desse tipo de trabalho pode ser grandemente afetada pelo planejamento, transformando-o em um grande desperdício de tempo. Por isso, deve-se ter bastante cuidado na realização de reuniões, observando-se as diretrizes a seguir. 1) Estabeleça o tipo de objetivo da reunião. Antes de planejar a reunião, identifique claramente o tipo de objetivo. Existem reuniões cujo intuito é de decisão, isto é, espera-se obter consenso sobre determinadas questões. Outras são reuniões de trabalho, em que uma determinada atividade deverá ser feita em comum. Ë conveniente sempre separá-las, pois, enquanto reuniões de decisão são possíveis com uma quantidade maior de pessoas, as reuniões de trabalho tornam-se inviáveis quando o número é maior do que até dez pessoas. Além disso, geralmente as pessoas que decidem fazem parte de um grupo maior do que daquele de quem executa. A estratégia e agenda dessas reuniões são também distintas. 2) Defina uma pauta e comunique-a antecipadamente. Para que qualquer reunião possa funcionar adequadamente, é preciso que as pessoas se preparem, consultando documentos ou mesmo lendo documentos que serão apreciados. A pauta tem um papel fundamental e pode ser um documento bastante simples, na forma de uma mensagem eletrônica — o importante é que ele discrimine claramente cada assunto, os participantes, data, local e, não se esqueça, o tempo previsto para término. 3) Prepare o local e certifique-se antecipadamente de que os recursos necessários estejam preparados. O local onde será realizada a reunião precisa ser preparado com todos os recursos multimeios e de apoio ao usuário. É fundamental que eles sejam testados e estejam ligados antes do horário da reunião — de preferência 15 minutos ou meia hora antes. Os participantes devem encontrar o ambiente totalmente preparado para o início da reunião. No caso de apresentações multimeios, é boa prática solicitá-las antecipadamente e deixá-las preparadas em um computador, pois é muito comum atrasos para conexões de laptop, cópias de arquivos ou por falhas em disquetes ou equipamentos. 4) Exija e pratique a pontualidade. O início atrasado das reuniões causa um efeito “bola de neve”, incentivando novos atrasos, e prejudicando a todos. Por isso, as reuniões devem começar pontualmente, evitando-se ao máximo a espera por algum dos membros. 5) O papel de coordenador ou facilitador deve estar bem definido. É comum acontecerem reuniões nas quais várias pessoas direcionam os assuntos. Corre-se o risco, assim, de promover a dispersão das pessoas. A solução ideal é que haja um único e bem definido coordenador em cada reunião. Ele será o responsável por conduzir os assuntos e manter o foco das pessoas na pauta e objetivos da reunião. Ele precisa saber como iniciar os trabalhos e conduzir democrática e sistematicamente os assuntos. 6) Discuta rapidamente a pauta com os participantes, identificando metas de tempo para cada assunto. É boa prática dispensar um tempo curto, 15 minutos, no início da reunião para discutir a pauta, solicitando aos membros sugestões de mudança ou esclarecendo possíveis dúvidas. Ao final da discussão, o objetivo a ser atingido com o trabalho precisa estar claramente identificado e ser um consenso entre os presentes. Uma boa prática é definir um intervalo de tempo para cada assunto. Caso contrário, um assunto pode se estender demasiadamente, comprometendo parte dos objetivos da reunião. No caso do grupo perceber o problema, deve-se tomar uma decisão que passará entre adiar o assunto em questão ou mantê-lo e ocupar o tempo de outros assuntos da pauta. Outra boa prática é manter a lista com a pauta ou agenda visível para todos os participantes. Os flip-charts são ótimos meios. 7) Defina o papel de monitoramento de tempo da reunião. Uma boa prática é delegar para um dos participantes da reunião o papel de monitorar o relógio e avisar o grupo quando o tempo para um dos assuntos estiver em vias de ultrapassar o limite. O “calor” das discussões faz as pessoas se esquecerem do tempo e, delegando esse papel, aumenta-se a chance de que esse aspecto seja continuamente avaliado. 8) Defina o papel de redator da ata da reunião. A ata é um instrumento fundamental para a comunicação dos resultados da reunião e a garantia da realização das ações definidas. Deve-se, desde o início, delegar esse papel a um dos participantes, que ficará responsável por publicar a ata após a reunião. Esse documento precisa apresentar de manei-

(continua)

74

PARTE 1

Quadro 2.4

O Processo

Diretrizes para a Realização de Reuniões Produtivas (continuação)

ra clara e sucinta os seguintes aspectos: data, local, lista de participantes, pauta, descrição dos assuntos principais e listagem das ações ou decisões realizadas. No caso das ações, a ata deve sempre descrever prazo e responsável para cada ação. Uma prática muito útil é criar uma lista permanente, à vista de todos os participantes, na qual as ações e decisões tomadas durante a reunião vão sendo anotadas, na frente de todos, para evitar erros de interpretação. Quando essa lista não é compilada de forma transparente, um erro do redator poderá gerar uma grande confusão. 9) Mantenha um ambiente favorável à livre expressão. Quando um grupo é formado, é comum que alguns membros se sobressaiam inibindo a expressão daquelas pessoas mais tímidas ou retraídas. O facilitador deve, a todo momento, estar atento a esse aspecto. Ao verificar, pela expressão do rosto, que alguém não concorda com algo, deve lhe dirigir a palavra, incentivando-o a expressar sua opinião. Além disso, nas reuniões de trabalho, ele deve adotar diferentes dinâmicas, tais como: jogos, trabalhos com cartões, divisão em grupos menores e outras técnicas que facilitem a interação e livre expressão de todos os participantes. As análises sistemáticas do tipo QFD e métodos criativos, apresentados no Capítulo 6, são alguns exemplos de dinâmicas.

Uma medida fundamental nesse sentido é separar o trabalho de análise com o de decisão. Quando eles se misturam, a probabilidade de dispersão aumenta. Análises devem ser delegadas para especialistas ou times de especialistas. Esses, por sua vez, produzem planos de ações e relatórios claros, com resumos executivos, que são apresentados nas reuniões de caráter decisório. Elas, sim, com a participação dos diversos atores envolvidos — gerentes, planejadores e técnicos com poder de decisão — e, portanto, com tempo e disponibilidade menores. Todos devem receber os relatórios específicos com antecedência para que possam se preparar adequadamente para a reunião. Aí, então, as reuniões de caráter decisório poderão transcorrer de maneira transparente e objetiva, com o foco no que interessa: a decisão de ir adiante ou não com o projeto. No caso de uma empresa muito pequena, na qual o time de projeto e o gerente Tipos de gates assumem conjuntamente os papéis de especialistas, gerente do projeto e do time de avaliação do produto (veja o Tópico 2.3), o gate pode ser feito por um conjunto pequeno de reuniões entre esse time — específicas para analisar todos os critérios e tomar a decisão final de aprovação ou não do projeto naquela fase. A auto-avaliação e a avaliação do gate, descritas anteriormente, são feitas de uma única vez. Deve-se atentar para o fato de que, mesmo sendo as mesmas pessoas que realizaram o projeto, o gate é para essas empresas uma forma sistemática do time avaliar o andamento dos trabalhos conjuntamente. No caso de empresas maiores e com produtos mais complexos, os papéis do time de avaliação e de gerente de projetos são comumente exercidos por diferentes pessoas. Uma solução em geral adotada nesses casos é criar diferentes tipos de avaliações dentro do processo de gates. A maneira mais simples é a criação de reuniões denominadas Revisões Técnicas (Design Reviews) e Revisões de Planejamento (Project Reviews). As primeiras são feitas pelas pessoas que assumem os papéis de membros do time de projeto, especialistas técnicos, parceiros do projeto e o gerente. Essa equipe revisará detalhadamente todos os aspectos técnicos do projeto e emitirá parecer com a avaliação dos critérios do gate ligados a esse tipo de questão. Essas reuniões dependem de uma grande preparação em que responsáveis por partes do produto analisarão antecipadamente a qualidade e os problemas sob sua responsabilidade. Durante essa análise, novas atividades ou necessidades de retrabalho podem ser identificadas. As revisões de planejamento são realizadas depois das revisões técnicas e têm como objetivo a verificação dos demais aspectos do projeto, considerando o resultado da verificação técnica. Verifica-se o desempenho do projeto em termos de tempo e comprometimento do orçamento, o impacto das dificuldades técnicas identificadas e novas atividades, o impacto de fatores externos e as mudanças no portfólio da empresa. Ao final, são obtidos uma análise de todos os critérios do gate e o resultado final sobre a aprovação ou não da fase e condições e direcionamentos para a próxima fase. A revisão de projeto deve ser sempre realizada em duas etapas, conforme discutido no subtópico “Sistemática de gates”. A primeira, de maior duração, é realizada pelo time de projeto e o gerente. Eles avaliam todos os critérios e criam o relatório de auto-avaliação que, então, é submetido para os atores que assumem o papel de

CAPÍTULO 2

O Modelo Unificado do PDP

75

time de avaliação. Eles se preparam estudando o relatório de auto-avaliação e realizam, assim, a reunião de revisão final em que participarão o time de avaliação e o gerente de projetos. Caso haja pontos controversos, outros participantes — como especialistas da própria empresa ou membros do time — poderão fazer parte da reunião, para auxiliar durante a tomada de decisão nos gates em cada fase. No final de cada fase do processo de desenvolvimento de produtos apresentado neste livro, repetem-se as seguintes atividades genéricas de revisão (gate): avaliar fase e aprovar fase. Por serem genéricas, isto é, aplicáveis a todas as fases, elas são descritas no Capítulo 3, a seguir, em tópicos separados, 3.4 e 3.5, respectivamente. Nos tópicos correspondentes a essas atividades, dentro de cada fase, as atividades genéricas são citadas e adicionam-se alguns critérios específicos relacionados àquela fase. Os critérios colocados são básicos e genéricos, compatíveis com um modelo de referência genérico, pois, para cada tipo de produto, estratégia, tecnologia etc. devem ser definidos critérios apropriados. A sistemática de revisão de fase deve ser formalizada de forma clara e simples e A sistemática de revisão deve ser incorporada pela empresa e praticada pelos times envolvidos. Ela envolve deve ser simples as pessoas de nível superior da empresa na tomada de decisões, como membros do time de avaliação. Essa sistemática garante que as estratégias de produto e, por conseguinte, as da empresa estejam sendo constantemente observadas em cada projeto. Assim, existem pontos de verificação quantificáveis, com os quais é possível monitorar o progresso do projeto. Um dos elementos críticos para o sucesso da introdução da prática de gates está nos critérios de avaliação utilizados. Devemos ter critérios bem definidos e relevantes para realizarmos o gate. Esses Critérios de avaliação critérios não podem ser limitados somente a aspectos técnicos do produto, mas, também, a aspectos estratégicos, de marketing, manufatura, finanças e qualidade. Eles devem ser abrangentes e devem fazer parte do modelo de referência de desenvolvimento de um determinado tipo de produto. Além disso, precisam ser adaptados no início de cada projeto de desenvolvimento e no gate da fase anterior, como mostrado na apresentação da sistemática de gate, e confirmados na atualização do planejamento daquela fase específica. Os critérios quantitativos estão associados a indicadores de medição de progresso do projeto (veja, mais à frente, o Tópico 2.9). Um exemplo é o grau de maturidade de uma nova tecnologia a ser utilizada em produtos. Deve-se garantir que, até o início da fase de projeto detalhado, esse indicador esteja com o valor de 100%, ou seja, que a tecnologia a ser empregada já tenha sido avaliada e homologada. É comum algumas empresas empregarem tecnologia não maduras e, com isso, correrem riscos na introdução de um novo produto no mercado. São os critérios qualitativos e quantitativos que vão nortear o desenvolvimento. O cumprimento de cada critério significa que as atividades relacionadas com esse critério foram finalizadas e que seus resultados foram entregues e possuem a qualidade exigida. A boa prática do processo e a definição e aplicação dos critérios só acontece se a organização estiver estruturada para a realização dos gates. O time responsável pelos gates é denominado no nosso modelo de time de avaTime de avaliação liação. Em geral, ele é composto por pessoas da alta administração da empresa e por especialistas (convidados ou não) nas diversas tecnologias empregadas no produto. Necessariamente, eles devem possuir uma visão ampla do portfólio de produtos e projetos da empresa. As pessoas do time de avaliação normalmente não são as mesmas do time de desenvolvimento para evitar que eles defendam e escondam os possíveis erros ocorridos em uma fase. Em empresas pequenas, esse time pode ser formado por pessoas da diretoria e um especialista, quando for o caso. Um dos problemas das empresas que começam a adotar a sistemática de gates é Diferenciar os gates por que elas avaliam todos os seus projetos da mesma forma. Cada projeto deve ser clastipo de projeto sificado e, para cada tipo de projeto, deve ser adotado um procedimento diferente. Projetos muito simples — por exemplo, que provavelmente envolvam o desenvolvi-

76

PARTE 1

O Processo

mento de um produto simples (derivado de um produto existente) — devem ser submetidos a somente alguns critérios técnicos. É sempre importante avaliar o impacto no portfólio de produtos e projetos da empresa. Depois de conhecer o primeiro conceito auxiliar do modelo de referência deste livro, vamos passar para o segundo, que trata dos métodos e ferramentas de desenvolvimento de produtos constantes dessa proposta.

2.8

Métodos e ferramentas de desenvolvimento de produtos

Métodos e ferramentas são meios que existem para apoiar a realização das atividades de PDP e, muitas vezes, são utilizados como sinônimos. Exemplos de métodos são: Quality Function Deployment (QFD), Design for Manufacturing and Assembly (DFMA), Failure Modes and Effects Analysis (FMEA), projeto robusto etc. Esses métodos também são conhecidos como ferramentas de apoio ao PDP. Porém, o termo ferramentas é mais utilizado para definir sistemas de informação, tais como: Computer Aided Design (CAD), Computer Aided Process Planning (CAPP), Computer Aided Engineering (CAE), Product Data Management (PDM) etc.16 Durante a descrição do modelo são apresentadas as várias ferramentas de informática que podem melhorar a eficiência e a eficácia do processo de desenvolvimento de produtos. Mas, além do benefício específico que cada uma delas pode proporcionar, existe uma forte tendência no sentido da integração. Os Sistemas Integrados de Gestão Empresarial (ERP, Enterprise Resource Planning), que, na última década, vêm se disseminando nas organizações, são a plataforma básica dessa integração. Eles começaram com foco na manufatura e finanças e, atualmente, estão cada vez mais suportando a integração com as ferramentas de planejamento e execução de projetos de engenharia. Essa mudança é significativa, pois, no passado recente, os sistemas de informação das áreas de engenharia trabalhavam de maneira isolada do dia-a-dia da empresa. Isto é, a direção tinha idéia apenas da quantidade de dinheiro e tempo gastos. Os resultados eram vistos no final, com o produto pronto. Com essa integração de ERPs e as outras ferramentas, a gestão integrada de todo o ciclo de vida dos produtos está se tornando uma realidade, (veja o Quadro 2.5). Métodos e ferramentas são sinônimos

Quadro 2.5

Sistemas ERP e Soluções Relacionadas: CRM, SCM e PLM

Com o avanço da tecnologia da informação (TI), as empresas passaram a utilizar sistemas computacionais para suportar suas atividades. Geralmente, em cada empresa, vários sistemas foram desenvolvidos para atender aos requisitos específicos das diversas unidades de negócio, plantas, departamentos e escritórios. Por exemplo, o departamento de planejamento da produção utiliza um sistema próprio e o departamento de vendas utiliza outro. Dessa forma, a informação fica dividida entre diferentes sistemas. Os principais problemas dessa fragmentação da informação são a dificuldade de obtenção de informações consolidadas e a inconsistência de dados redundantes armazenados em mais de um sistema. Os sistemas ERP solucionam esses problemas ao agregarem, em um só sistema integrado, funcionalidades que suportam as atividades dos diversos processos de negócio das empresas. Os sistemas ERP surgiram a partir da evolução dos sistemas Material Resource Planning, (MRP, Planejamento de Recursos de Manufatura). Neles, foram agregadas várias funções, e ele passou a ser chamado de MRP II. Com o objetivo de ampliar a abrangência dos produtos vendidos, os fornecedores de sistemas desenvolveram mais módulos, integrados aos módulos de manufatura, porém com escopo que ultrapassa os limites da manufatura. Como exemplo, foram criados os módulos de Ge-

(continua) 16

Os significados dessas siglas podem ser consultados no Apêndice III deste livro, e uma explicação mais detalhada desses métodos e ferramentas citados encontra-se em quadros posicionados dentro da descrição da atividade mais apropriada à sua aplicação.

CAPÍTULO 2

O Modelo Unificado do PDP

Quadro 2.5

77

Sistemas ERP e Soluções Relacionadas: CRM, SCM e PLM (continuação)

renciamento dos Recursos Humanos, Vendas e Distribuição, Finanças e Controladoria, entre outros. Esses novos sistemas, capazes de suportar as necessidades de informação para todo o empreendimento, são denominados sistemas ERP.

Estrutura típica dos sistemas ERP Os sistemas ERP são compostos por uma base de dados única e por módulos que suportam diversas atividades das empresas. A Figura 2.18 apresenta uma estrutura típica de funcionamento de um sistema ERP. Os dados utilizados por um módulo são armazenados na base de dados única, para serem manipulados por outros módulos. Figura 2.18

Estrutura típica de um sistema ERP.

Com o advento da Internet e a especialização dos sistemas ERP em sistemas verticais voltados para certos tipos de segmentos, a grande parte dos fornecedores o dividiu em três grandes suítes de módulos (alguns adotaram outro tipo de divisão): CRM (Customer Relationship Management): CRM visa entender e antecipar as necessidades dos clientes potenciais e dos atuais (base instalada). O objetivo é conhecer o cliente e atendê-lo melhor; com isso, procura-se reter os clientes atuais, para que ele compre mais. Além disso, o conhecimento dos clientes potenciais permite que sejam tomadas medidas específicas e eficazes para conquistá-los. Isso envolve captar todas as possíveis informações sobre eles, consolidá-las em um banco de dados, analisá-las para identificar padrões, distribuir resultados para todos os pontos de contato e usar essas informações para interagir com os clientes. O CRM integra módulos de automação de vendas, gerência de vendas, telemarketing, televendas, atendimento ao cliente, soluções para informações gerenciais, Web e comércio eletrônico. SCM (Supply Chain Management): SCM integra os processos de negócios dos parceiros da cadeia de suprimentos, envolvendo desde a produção até a distribuição. SCM não contempla apenas a área de suprimentos de produtos, mas também a demanda de mercado, vendas, compras, recebimento, estoques dos parceiros, planejamento de produção, transporte etc. Os módulos do SCM compreendem o núcleo do sistema ERP. PLM (Product Life-Cycle Management): PLM contempla a criação e a gestão das informações de produto e os projetos de desenvolvimento. PLM integra todas as soluções de tecnologia de informação relacionadas com o PDP. Em razão de sua importância para este livro, existem quadros específicos sobre PLM e seus principais componentes. Veja, no decorrer dos capítulos, os seguintes quadros:

(continua)

78

PARTE 1

Quadro 2.5

• • • • • • • •

O Processo

Sistemas ERP e Soluções Relacionadas: CRM, SCM e PLM (continuação)

Sistemas PLM Sistemas de Gerenciamento de Projetos Sistemas CAD/CAE/CAM Sistemas CAPP Sistemas CSM integrados ao e-procurement Sistemas PDM/EDM Sistemas GED

Manufatura virtual Como base para a operação dessas três suítes, estão os demais módulos de gestão financeira e de recursos humanos do ERP, já citados na Figura 2.18. A Figura 2.19 apresenta, de forma conceitual, a integração entre essas três suítes de software, destacando-se a intensidade de seu uso nas fases de desenvolvimento de produtos. Figura 2.19

Integração das soluções de CRM, SCM e PLM ao longo do ciclo de vida do produto, relacionada com o modelo de referência de desenvolvimento de produtos (adaptado da figura de SAP).

Durante as macrofases de pré-desenvolvimento e desenvolvimento, o principal sistema utilizado é o PLM. Mas a base de dados do CRM é muito importante para ser utilizada na fase de planejamento estratégico de produto e na fase de projeto informacional, quando se procura determinar padrões de clientes a serem contatados para pesquisas de mercado. CRM é também aplicado para se definir requisitos a partir de dados levantados dos processos de apoio, tais como: atendimento a clientes e assistência técnica. SCM é utilizado para o cálculo de necessidades de capacidade futuras com base nas programações existentes, para a compra e cotação de material, além da gerência dos fornecedores. Na fase de produção, o SCM entra em primeiro plano e o CRM acompanha as reações dos clientes às campanhas de lançamento. O PLM é mais utilizado no início para gerenciar as possíveis mudanças de engenharia, mas, depois, entra em uma época de manutenção da configuração. Após o término da produção, o PLM tem um papel relativo mais importante novamente, pois é responsável pela manutenção e atualização dos dados de produto. Hoje já se fala em ERP II, que conota a distribuição dos sistemas ERP por todos os parceiros da cadeia de suprimentos via Internet. A interface comum entre todos os usuários é um portal corporativo (ou da cadeia), que é personalizado para cada usuário, contendo funcionalidades à disposição que podem apoiar as suas atividades específicas.

CAPÍTULO 2

O Modelo Unificado do PDP

79

Os métodos contêm normalmente uma lista de passos que devem ser seguidos Métodos apresentam uma para se atingir os objetivos para os quais eles se propõem. seqüência de passos Toda publicação de desenvolvimento de produtos apresenta alguns desses métodos inseridos nas fases e atividades do PDP. Como a origem desses métodos comumente não estava relacionada com uma visão de processo, freqüentemente surge uma dúvida ao se relacionar os passos propostos por esses métodos e as atividades do PDP. Ou seja, existe atividade que é completamente realizada por um método; existe atividade que utiliza mais de um método (ou passos de diferentes métodos); e existem métodos que abrangem várias atividades. Por exemplo, o método QFD é utilizado nas seguintes atividades da fase de projeto informacional (veja o Capítulo 6): ■ ■ ■

identificar os requisitos dos clientes do produto; definir requisitos de projeto do produto; e definir especificações de projeto do produto.

Para manter o foco no modelo de PDP e evitar a repetição de conteúdos fartaA descrição desses mente desenvolvidos em outras publicações, este livro traz resumos dos principais métodos e ferramentas métodos e ferramentas, que são registrados em quadros. Esses quadros são posicioneste livro nados no texto, de forma a se relacionar com as atividades mais afins. No final de cada capítulo, são listadas as principais referências bibliográficas que trazem informações adicionais sobre esses métodos e ferramentas. Dessa forma, o leitor obtém as informações essenciais sobre o método e sua aplicabilidade no PDP, e encontra fontes para se aprofundar no entendimento do método caso julgar interessante. O mesmo ocorre com a descrição dos sistemas de informação apropriados. Vamos conhecer agora o terceiro conceito importante relacionado com o modelo proposto por este livro: os indicadores de desempenho do PDP.

2.9

Indicadores de desempenho do PDP

Como todo processo de negóTipos de indicadores cio, o desenvolvimento de produto deve ser monitorado por meio de indicadores de desempenho. A literatura de desenvolvimento de produtos propicia diversos indicadores que podem ser utilizados para a avaliação desse processo. Há indicadores ligados ao desempenho do produto no mercado, que servem para uma avaliação indireta do processo de DP que o gerou, bem como há outros indicadores que tratam diretamente da avaliação dos projetos de desenvolvimento em si, quanto a sua realização geral e das principais partes ou etapas que o compõem. Esses indicadores podem ser focados tanto na avaliação de todo o portfólio de projetos/produtos como na avaliação particular de alguns deles. Esse tipo de indicador monitora a produtividade do PDP avaliando o portfólio Indicadores do PDP que de produtos de maneira unificada, sem diferenciar os projetos individuais de desenagregam informações volvimento e preocupando-se com a contribuição desse processo aos objetivos esde todos os projetos tratégicos gerais da empresa. Esses indicadores, assim como os seus valores, são e produtos normalmente determinados durante o planejamento estratégico e tipicamente são atualizados ano a ano. Na Figura 2.20 são apresentados os indicadores desse tipo mais utilizados pelas empresas, sem, no entanto, entrar em detalhes de como levantá-los. Toda empresa deve definir os indicadores mais apropriados, segundo a

80

PARTE 1

O Processo

sua estratégia, as restrições em termos de obtenção dos dados e de forma integrada com os demais indicadores de 17 gestão do negócio da empresa. Figura 2.20

Porcentagem de uso de indicadores para medir a produtividade do processo de desenvolvimento de produtos por em18 presas em 2002.

O segundo grupo de indicadores de desempenho estão relacionados com quatro dimensões de avaliação: Sucesso financeiro (lucros, metas e crescimento de vendas, percentual de vendas dos novos produtos, participação de mercado — market-share, temIndicadores relacionados po/retorno de investimento, metas de margem e lucratividade etc.). com projetos individuais ■ Sucesso operacional (custos e tempos de desenvolvimento, diretrizes de qualidade atingidas, velocidade, produtividade do desenvolvimento). ■ Sucesso em qualidade (grau de aceitação pelo consumidor, satisfação do cliente, tempo de permanência no mercado). ■ Sucesso perceptivo (avaliações realizadas pela equipe e pelo gerenciamento, aprendizagem para futuros projetos). ■

Os indicadores de sucesso operacional e parte dos indicadores de sucesso em qualidade e perceptivo são equivalentes aos indicadores da área de gestão de projetos, pois o desenvolvimento de um produto específico ocorre por meio de projetos. Sendo assim, é possível avaliar diretamente os projetos de desenvolvimento em si, inclusive desdobrando os indicadores dessa categoria para avaliar as fases que o compõem. Veja no Capítulo 5, Tópico 5.12, o detalhamento proposto desses indicadores, que deve ocorrer durante o planejamento do projeto. Pode-se considerar que o processo de desenvolvimento de um produto foi bem-sucedido (teve um bom desempenho) se o produto resultante for aceito no mercado tal qual a previsão inicial ou, melhor, se trouxe a rentabilidade planejada para os investimentos, se contribuiu para fortalecer a imagem da marca conforme o esperado e se permite futuros lançamentos de produtos derivados. Esses são resultados atrelados aos objetivos maiores da empresa (faturamento, rentabilidade, aumento da participação no mercado etc.) e cada projeto/produto possui a sua margem de contribuição para a avaliação do PDP. 17

18

Os indicadores do processo de desenvolvimento de produtos devem estar coerentes com o desdobramento de indicadores globais da empresa. As empresas atualmente utilizam metodologias para gestão de indicadores, como os do Balacend Scorecard, para desdobrar indicadores para toda a organização. American Productivity and Quality Center (APQC), Measuring Research and Development (R&D) Productivity Webseminar, 3/6/2004.

CAPÍTULO 2

O Modelo Unificado do PDP

81

Como mencionado no tópico que discute as revisões das fases, alguns desses Indicadores de indicadores podem ser utilizados na sistemática de gate, juntamente com os critérios desempenho neste livro de aprovação. A definição dos indicadores apropriados depende da estratégia de cada empresa e deve ocorrer quando se implanta o modelo proposto neste livro e se institucionaliza o PDP. Vamos agora conhecer o último conceito complementar ao modelo apresentado, que discute sobre os parceiros de desenvolvimento dentro de uma cadeia de suprimentos.

2.10 Parceiros do desenvolvimento colaborativo de produtos Cada vez mais o processo de desenvolvimento de produtos de uma empresa é realizado em conjunto com os seus parceiros, o que pode acontecer desde as primeiras fases do desenvolvimento.19 O modelo deste livro considera as necessidades de um desenvolvimento colaborativo. As práticas nesse sentido estão em vários detalhes específicos das diversas partes do modelo. O objetivo deste tópico é ressaltar essas características de colaboração para que possam ser entendidas e utilizadas. A primeira característica que auTime de desenvolvimento xilia a colaboração é considerar os estendido: o importante parceiros como possíveis membros papel dos parceiros do time de desenvolvimento. Podem ser representantes de clientes ou fornecedores muito importantes que fazem parte do time e, portanto, atuam ativamente desde o início do projeto. Certamente, a quantidade não conta, pois participar desse time significa ser responsável por atividades diretas de desenvolvimento e ter acesso às decisões sobre o projeto. Esse tipo acontecerá quando o projeto de desenvolvimento for estratégico para a empresa cliente ou fornecedora e esse parceiro detiver uma competência essencial para contribuir com o projeto. No caso das empresas clientes, essa competência pode ser o conhecimento sobre os requisitos do mercado, por exemplo, quando a empresa pretende entrar em um novo ramo e se associa a uma outra empresa com larga experiência no mercado. No caso das empresas fornecedoras, a competência essencial geralmente é a capacidade de projetar um determinado subsistema que fará parte do produto. Nesse caso, o representante do fornecedor participará da equipe de projeto e será responsável pela especificação, projeto e teste do subsistema. Em qualquer um dos casos, a última condição essencial para que esse nível de cooperação seja interessante é a confiança entre as empresas parceiras. Participar do time do projeto significa também ter acesso à área de desenvolvimento da empresa e de informação muitas vezes confidenciais. Uma boa estrutura jurídica pode aumentar a segurança da empresa, mas experiência prévia de trabalho com o parceiro e confiança nas pessoas envolvidas são fundamentais para que o trabalho conjunto seja produtivo. A participação do parceiro no time de projeto demonstra um nível elevado de Tipos de parceiros cooperação. Convém destacar que existem diferentes níveis de parceria, com níveis existentes menos significativos de envolvimento. Devemos conhecer os papéis que cada um dos tipos de parceiros assume dentro do processo de desenvolvimento de produtos e saber utilizá-los de forma coerente para fortalecer o processo de desenvolvimento. Uma parceria mal definida pode causar problemas que drenam tempo precioso da gerência na solução de conflitos. No setor que estamos tratando neste livro, bens de consumo duráveis e de capital, existem os seguintes tipos de elos na cadeia de suprimentos:

19

No Apêndice II, há um termo em inglês bem conhecido (Early Supplier Involvement, ESI) que é utilizado para representar esse envolvimento.

82

PARTE 1

■

■

■

■

■

■

■

■

O Processo

Montador: Fornece seus produtos para o mercado de consumo final e possui contato com os consumidores. Exemplo: fabricantes de eletrodomésticos, produtos da linha branca (máquinas de lavar, secadoras, geladeiras etc.), automóveis, eletroeletrônicos etc. Fornecedor de equipamentos e ferramental: É como o montador, mas o seu produto é o meio de produção de um cliente final. Tanto ele quanto o montador podem comprar de um outro fornecedor de equipamentos e ferramental. Esses equipamentos e ferramental podem ser universais, como uma máquina-ferramenta de linha (exemplo, torno CNC), ou um equipamento ou ferramental específicos projetados para produzir um produto em particular (exemplo, uma máquina para montagem de um motor elétrico). Exemplo: fornecedor de moldes de injeção e forjamento, de equipamentos de medição etc. Fornecedor de primeiro nível: Fornece sistemas que fazem parte de um produto final de um montador ou fornecedor de equipamentos. Exemplo: fornecedor de chassis e estrutura para indústria de caminhões, motores de combustão etc. Fornecedor de segundo nível: Fornece subsistemas ou componentes que fazem parte dos produtos dos fornecedores de primeiro nível. Exemplo: fornecedor de motor elétrico, controles etc. 20 Fornecedor de commodities : Fornece subsistemas ou componentes padronizados no mercado, isto é, cujas características básicas são definidas por normas seguidas por todas as empresas que atuam no setor e o nível de qualidade é similar. Como resultado, os produtos de diferentes concorrentes podem ser intercambiáveis e a definição de onde comprar é baseada essencialmente no preço, dado que a qualidade é equiparada pela obediência aos padrões. Normalmente, esses produtos são utilizados por empresas de várias cadeias produtivas. Exemplos: fornecedor de rolamentos, peças-padrão, anéis de vedação, filtros etc. Fornecedor de matéria-prima: Freqüentemente um fornecedor de matéria-prima é tratado como um de commodities. Porém, surgem hoje em dia materiais especiais (como plásticos condutores de eletricidade, plásticos de engenharia etc.) e, nesses casos, essas empresas assumem papéis diferentes, podendo inclusive participar do PDP no momento da especificação dos requisitos do produto. Fornecedor de tecnologia: Desenvolve tecnologia a ser incorporada nos produtos dos parceiros da cadeia de suprimentos. Normalmente, eles possuem centros de pesquisa e desenvolvimento. No Brasil, não é usual encontrar empresas desse tipo — como no exterior. Em geral, a tecnologia é desenvolvida em instituições de pesquisa (como universidades e institutos estatais) ou em áreas de P & D dentro das próprias empresas. Mas, na maior parte das vezes, a tecnologia vem de outros países, normalmente sede de multinacionais aqui instaladas. Fornecedor de serviços: Há fornecedores de serviços de desenvolvimento (a serem contratados para realizar alguma tarefa de um projeto de desenvolvimento de um produto) e de serviços envolvidos com a manufatura do produto final. Exemplos da primeira categoria: fornecedor de serviços de desenhos, cálculos, prototipagem, marketing, grupo focal para levantamento de necessidades, entrevista de mercado etc. Exemplos da segunda categoria: serviços de usinagem especial, tratamento térmico, medição dimensional, injeção plástica etc.

Algumas empresas podem ser classificadas em mais de um tipo ao mesmo tempo. Um caso típico é no fornecimento de peças plásticas injetadas. Alguns fornecedores realizam somente a operação de injeção plástica, ou seja, possuem um parque de injetores e vendem o serviço de injeção. O cliente é responsável por todas as outras atividades, e ainda traz o molde de injeção. Outros fornecedores especializaram-se no setor de moldes de injeção plástica, e realizam o projeto do molde (simulando por computador o processo de injeção) e podem participar das fases de desenvolvimento de produtos, trazendo os seus conhecimentos na definição do estilo mais apropriado para o processo de injeção. Outros, ainda, abrangem todo o ciclo de peças injetadas. A Figura 2.21 mostra o relacionamento comum encontrado entre esses tipos de fornecedores dentro de uma mesma cadeia de suprimentos. 20

Usualmente, adota-se o termo em inglês, por não haver termo apropriado em português. O mais próximo é fornecedor de produtospadrão, mas não é usual.

CAPÍTULO 2

O Modelo Unificado do PDP

Figura 2.21

Tipos de parceiros dentro de uma mesma cadeia de suprimentos.

No modelo unificado, utilizaremos a classificação apresentada na Figura 2.22 21 para identificar os diferentes tipos de fornecedores. ■

■

21

83

Tipos de relacionamento com fornecedores no modelo unificado

Parceiro de risco: Ocorre quando uma empresa se associa à empresa que está coordenando o desenvolvimento e irá colaborar e dividir os riscos. Os contratos são de longo prazo, deverão durar toda a vida do produto, e a empresa participa de todas as decisões fundamentais no desenvolvimento e na comercialização. Geralmente, o parceiro assume o investimento no desenvolvimento e no custeio da produção de um subsistema do produto. Em troca, receberá uma parte das receitas de vendas. Ele é envolvido em todas as etapas do PDP. Ocorre normalmente com os fornecedores de primeiro nível; Parceiro de tecnologia: É essencial para existir inovação no produto. O objeto de fornecimento é a tecnologia, que pode fazer parte do produto do fornecedor. Muitas vezes, é uma empresa dentro do mesmo grupo, ou laboratório de Pesquisa e Desenvolvimento da organização. Em geral, esse papel é assumido pelo fornecedor de tecnologia, mas pode ocorrer com um fornecedor de máquinas e/ou de primeiro nível, quando a sua tecnologia for um diferencial para o produto final. Atualmente, instituições como universidades e centros de pesquisa têm assumido esse papel, fechando contratos de longo prazo com empresas.

Essa nomenclatura é adequada para os tipos de produtos nos quais uma empresa principal, a empresa cliente, coordena todo o processo de desenvolvimento de produtos. Há casos, como na construção civil, construção de navios e outros, que fogem ao escopo do modelo unificado em que há um consórcio de empresas que realiza o projeto, liderado pela empresa que será a consumidora final do produto, a contratadora. Nesse caso, essa tipologia não é de todo adequada.

84

PARTE 1

Figura 2.22

■

O Processo

Tipos de relacionamento com os fornecedores no PDP.

Co-desenvolvedor: Este nome é dado ao fornecedor que participa da definição dos requisitos do subsistema e do seu desenvolvimento. Geralmente, são responsáveis por sistemas ou módulos complexos e possuem domínio completo da tecnologia, gerando as possíveis concepções do subsistema e, muitas vezes, sugerindo alterações. Eles podem ou não produzir as peças mais tarde. Em caso afirmativo, estabelecem contratos de longo prazo com o fornecedor principal, garantindo a compra do subsistema por um período de anos ou a vida toda do produto principal. O caso em que não irão produzir diz respeito a empresas especializadas em engenharia (veja o Quadro 2.6, a seguir). São empresas formadas por técnicos e engenheiros que dominam a tecnologia e auxiliam na especificação, mas não possuem recursos para produzir os produtos. Na Figura 2.22, eles foram separados ainda em duas categorias, um deles denominado de parceiro. Tais parceiros são co-desenvolvedores que participam da equipe de projeto e, portanto, auxiliam também na especificação do produto final. Normalmente, o co-desenvolvimento acontece com os fornecedores de primeiro nível.

Quadro 2.6

O Surgimento da Parceira com Fornecedores e das Empresas Especializadas em Serviços de Engenharia

Os setores de engenharia surgiram dentro das empresas com a produção em massa. Até aquela época, os produtos eram projetados e construídos artesanalmente, muitas vezes pelo mesmo grupo de pessoas. Portanto, era difícil separar o trabalho de produção com a especificação dos produtos. A produção em massa alterou profundamente essa lógica. O requisito básico para a produção em série é a padronização dos componentes, que se inicia pela especificação detalhada. O sucesso da produção em massa fez surgir os departamentos de engenharia nas grandes corporações, as quais, no seu apogeu, eram responsáveis pela especificação de cada um deles. Isso significa milhares de profissionais trabalhando para detalhar o produto completamente. Essa situação perdurou até recentemente. Um estudo realizado no início da época de 1990 constatou, por exemplo, que as montadoras de carros, com exceção das japonesas, realizavam a grande maioria do trabalho de engenharia. Os fornecedores recebiam os desenhos das peças e eram obrigados a segui-los à risca.

(continua)

CAPÍTULO 2

O Modelo Unificado do PDP

Quadro 2.6

85

O Surgimento da Parceira com Fornecedores e das Empresas Especializadas em Serviços de Engenharia (continuação)

Essa situação causava um conjunto grande de ineficiências. O número de funcionários era maior. Os engenheiros das empresas não conheciam detalhadamente as máquinas e equipamentos de todos os fornecedores, causando custos adicionais ou mudanças e redesenho das peças. Os fornecedores tinham menos espaço para sugerir alterações que poderiam melhorar a fabricação. A situação começou a mudar quando as empresas japonesas demonstraram as vantagens de envolver cada vez mais os fornecedores, delegando-lhes responsabilidades de detalhamento e desenvolvimento das especificações das peças e processos. As empresas começaram a perceber também que certos subsistemas e componentes não representavam diferencial significativo no desempenho de seus produtos. Na linguagem utilizada, eles não eram core, isto é, não eram essenciais para a empresa, pois o cliente final não sentia os seus efeitos e, portanto, não impactavam na competitividade do produto. Havia também certos testes que exigiam uma grande infra-estrutura física e técnicos especializados, e eram subutilizados. Isso significa custos adicionais no desenvolvimento dos produtos da empresa como um todo. Passou-se, então, a subcontratar os serviços de engenharia de empresas especializadas, muitas delas formadas por ex-funcionários, e até mesmo de concorrentes. Por exemplo, existem empresas especializadas em projetos de lentes e que vendem esse serviço para empresas interessadas em incorporar tal tecnologia em seus produtos. Subcontratar um serviço desse tipo certamente valeria a pena se esse não fosse um item core da empresa. Imagine o custo de buscar um profissional no mercado, contratá-lo e montar laboratórios específicos. O resultado dessas mudanças é que parte significativa das atividades de desenvolvimentos são atualmente realizadas fora da empresa responsável pelo desenvolvimento de produto, conforme ilustra esquematicamente a Figura 2.23. O problema que os profissionais e gerentes de projeto enfrentam é saber quando é melhor projetar e produzir in house e quando subcontratar. Uma dica é a seguinte, os subsistemas e componentes essenciais (core) para o desempenho do produto deverão sempre ser desenvolvidos pela empresa principal, ou por parceiros de absoluta confiança e laços financeiros estáveis e de longo prazo. Os subsistemas não essenciais, mas complexos e que demandam uma competência bem especializada, poderão ser prioritariamente delegados para parceiros tecnológicos e de co-desenvolvimento. Em todos esses casos, os fornecedores precisarão ser envolvidos nas fases iniciais do processo de desenvolvimento de produto. Os módulos e componentes padronizados serão procurados no mercado no momento em que forem necessários, provavelmente na fase de preparação da produção, e serão adquiridos de fornecedores de peças-padrão, cujo relacionamento em termos de desenvolvimento de produto será pequeno ou inexistente. Há a possibilidade de restarem certos componentes que não são padronizados e poderiam ser desenvolvidos tanto internamente como por um fornecedor. Eles merecem uma análise make or buy que será feita na fase de detalhamento. Figura 2.23 Tipos de fontes de origem dos componentes de um produto manufaturado.

86

PARTE 1

■

■

O Processo

Fornecedores de serviços: São fornecedores que possuem um alto nível de capacitação técnica, mas, dadas as características do produto e do processo de fabricação, têm uma interface menor com o processo de desenvolvimento em si. Eles recebem os requisitos do produto e peças prontos da empresa cliente e desenvolvem a solução, podendo ou não oferecer sugestões de alterações. Nesse caso, visando principalmente a melhoria na manufaturabilidade das peças. Na Figura 2.22 foram classificados em dois tipos. Os primeiros são os fornecedores de serviços de engenharia, isto é, aqueles que recebem os requisitos do subsistema, os desenvolvem e podem ou não ser responsáveis pela sua fabricação. Os fornecedores de serviços de manufatura desenvolvem ferramentais, máquinas operatrizes, sistemas de automação, dispositivos de medição, teste e posicionamento, entre outros recursos necessários para a fabricação. Os fornecedores de segundo nível e alguns de primeiro podem assumir esse papel. Fornecedor de peças-padrão: Trata apenas da produção de sistemas e componentes de menor valor agregado e não possui acordos de parcerias. Nesses relacionamentos, o que importa são apenas o prazo e o custo de seus produtos. Esse é o caso dos fornecedores de commodities e de segundo nível, quando os seus produtos não forem estratégicos para o cliente. Nesse caso, o fornecedor desenvolve os produtos e os comercializa por meio de catálogos.

Conforme os tipos de empresa mostrados e as suas formas de relacionamento, o conteúdo do modelo precisa ser adaptado. As descrições de algumas atividades existentes na Parte 2 serão diferenciadas, dependendo do papel da empresa dentro da cadeia: se ela for uma empresa cliente final da cadeia (montadora) ou fornecedora intermediária (fornecedor de primeiro nível ou de equipamentos). No decorrer da apresentação do modelo, poderá ser observado que, desde as primeiras fases, os parceiros de risco e estratégicos estão envolvidos, participando inclusive do time de desenvolvimento. Em fases posteriores, os co-desenvolvedores atuarão, e, em outras, os fornecedores de commodities serão convidados para enviar cotações de seus produtos. Agora que já conhecemos os quatro elementos conceituais auxiliares do modelo, vamos conhecer uma outra forma de agrupar as atividades descritas na Parte 2 deste livro. Por que conhecer os tipos de empresa e as suas formas de relacionamento dentro de uma cadeia de suprimentos?

2.11 Áreas de conhecimento As macrofases desse modelo são divididas em fases, que, por sua vez, agrupam as atividades, as quais, em alguns casos, ainda são detalhadas em tarefas. Essa forma de apresentação tem como foco principal a evolução do produto em si. Dentro de uma visão integrada e multidisciplinar, é a forma mais didática de apresentar o desenvolvimento de produtos, que é o objetivo principal deste livro, pois reflete a realidade (os passos) dos processos de desenvolvimento das empresas.22 Como a quantidade de atividades é grande, esse agrupamento por fases também facilita o seu entendimento, organizando-as segundo o enfoque temporal. Mas existem outras formas de visualizar o desenvolvimento. As atividades podem ser Uma delas é classificando as atividades segundo as áreas clássicas relacionadas com classificadas por área de o desenvolvimento de produto A vantagem de agrupar as atividades em áreas de coconhecimento nhecimento é demonstrar a contribuição de cada uma delas para o processo de desenvolvimento. Um especialista interessado em conhecer qual sua potencial contribuição ou interessado em verificar a consistência do modelo em relação àquela área do conhecimento poModelo deste livro é organizado por fases, pois é mais didático

22

Como será discutido na Parte III deste livro, essa seqüência pode ser ajustada para a particularidade de cada processo de desenvolvimento.

CAPÍTULO 2

O Modelo Unificado do PDP

87

deria fazê-lo mais facilmente havendo essa classificação. Isso é importante porque a maior parte das empresas possui estruturas funcionais voltadas para áreas de conhecimento específicas. Por exemplo, possíveis áreas de uma empresa podem ser: escritório de projetos, engenharia de produto, marketing etc. As pessoas que atuam em uma dessas áreas podem ter uma idéia geral de todo o processo com a visão por fases, mas podem atentar às atividades mais voltadas à sua área específica de atuação, respectivamente gerenciamento de projetos, especificação do produto e marketing, no exemplo. Assim, ela pode gerenciar as atividades sob sua responsabilidade, sem perder a visão do processo. Uma pessoa da área de marketing, por exemplo, pode ler este livro com o objetivo de obter uma visão ampla do processo de desenvolvimento de produtos, mas, ao mesmo tempo, aprofundar-se mais nas atividades relacionadas com marketing. Quadro 2.7

Outros Modelos de Referência Organizam as Atividades por Áreas de Conhecimento 23

Outros modelos de referência existentes, tais como Project Management BOdy of Knowledge (PMBOK) e Capability Ma24 turity Model Integration (CMMI), das áreas de gestão de projetos e desenvolvimento de software integrado , respectivamente, agrupam as atividades em áreas de conhecimento. Nesses modelos, essas áreas são chamadas de áreas de processo. 25 No PMBOK, as atividades de referência estão agrupadas por capítulo (cada um tratando de uma área de processo ), mas existe também uma visão que agrupa as atividades por fase da gestão de projetos: iniciação, planejamento, controle e fechamento. No CMMI, as atividades estão agrupadas pelas áreas de processo, dividas em níveis de maturidade. São 24 áreas de processo e 5 níveis de maturidade. Esses modelos não têm intuito didático e, sim, são guias para utilização e certificação. Em razão disso, a organização por áreas de processo é mais apropriada para esses modelos, mas seu conteúdo é de difícil entendimento.

As áreas de conhecimento do modelo proposto neste livro são: gestão de projetos, meio ambiente, marketing, engenharia de produto, engenharia de processo, produção, suprimentos, qualidade e custos. O conteúdo dessas áreas — os temas tratados pelas atividades desse modelo — é apresentado na Tabela 2.1. Tabela 2.1

Temas e Atividades por Área de Conhecimento

Área de Conhecimento

Temas/Atividades típicas

Gestão de projetos

Definição de escopo, tempos, recursos humanos, sua qualificação e controle das atividades.

Meio ambiente

Sustentabilidade, reúso, remanufatura, reciclagem, reutilização de material, descarte.

Marketing

Relacionamento com o mercado, como levantamento de necessidades, inserção e avaliação dos produtos no mercado, e vigilância tecnológica.

Engenharia de produto

Soluções de estilo, de material, funcionais, estruturais, de comportamento do produto, integração de tecnologia etc.

Engenharia de processo

Processos e operações de fabricação e montagem, especificação e projeto de recursos de manufatura.

Produção

Atividades que consideram a manufatura dos produtos em desenvolvimento.

Suprimentos

Envolve as atividades de relacionamento com os parceiros, fornecedores, clientes da cadeia de suprimentos e o projeto da logística para viabilizar a produção.

Qualidade

Gestão constante dos requisitos dos produtos, mas cobre também o acompanhamento da qualidade dos processos de negócio resultantes do desenvolvimento de produtos e a qualidade dos produtos no mercado após o seu lançamento.

Custos

Definições de preços e custos-alvo, elaboração do orçamento, estudos de viabilidade e o monitoramento constante dessas informações.

23 24 25

Embora não adotem o termo “modelo de referência”. O CMMI considera o desenvolvimento integrado de produtos, que envolve várias tecnologias. Ele é uma evolução do CMM, que antes só tratava de desenvolvimento de software. As áreas de processo do PMBOK são: integração, escopo, tempo, custo, qualidade, análise de riscos, aquisição, comunicação e recursos humanos.

88

PARTE 1

O Processo

Na Figura 2.24 pode ser observada uma distribuição típica das atividades por essas áreas de conhecimento nas fases de desenvolvimento de produtos. A figura mostra qualitativamente que atividades de uma área de conhecimento são mais necessárias em determinadas fases do desenvolvimento. Por exemplo, atividades de suprimentos (compra de recursos, tais como equipamentos e ferramentas) são mais intensas na fase de “preparação da produção” do que em outras. Distribuição do esforço e a importância de cada área de conhecimento

Figura 2.24

Distribuição qualitativa típica das atividades (esforço e importância) por área de conhecimento nas fases do desenvolvimento.

No final deste livro encontra-se o Apêndice I com uma tabela que indica, para cada atividade, qual a área de conhecimento correspondente. Assim, o leitor que trabalha em uma determinada área — ou que possui um conhecimento específico — pode verificar quais as atividades relacionadas com os seus conhecimentos e/ou quais poderão ficar sob sua responsabilidade. Nesse ponto, já obtivemos uma visão geral do modelo, macrofases e conhecemos os conceitos que nos auxiliarão no entendimento do resto deste livro. Vamos discutir agora o conceito de gestão de conhecimento e como ele se relaciona com o modelo proposto.

2.12 Gestão do conhecimento do PDP Gerenciar o desenvolvimento de produtos é um desafio significativamente diferente do que gerenciar outras operações tradicionais na área de manufatura, e discutir essas diferenças é fundamental para entender por que a gestão do conhecimento é tão importante para o processo de desenvolvimento de produtos. Processo estruturado versus não estruturado

CAPÍTULO 2

O Modelo Unificado do PDP

89

O processo de manufatura é um processo estruturado e o de desenvolvimento de produtos é não estruturado, como discutido no Tópico 2.1 deste capítulo. No Quadro 2.8, são apresentadas as características que distinguem o processo de desenvolvimento de produtos de outros processos industriais. Tais diferenças são marcantes e “dizem muito” sobre a importância e o papel da gestão do conhecimento para o processo de desenvolvimento de produtos. A Tabela 2.2 traz uma comparação entre o processo de desenvolvimento de produtos e os processos estruturados. Tabela 2.2

Comparação entre o Processo de Desenvolvimento de Produtos e Processos Estruturados como Operações de Compra e Serviços Padronizados Processos Estruturados (Manufatura ou Serviços Padronizados)

Processo de Desenvolvimento de Produto

Resultado Final (produto)

Físico (tangível e bem determinado)

Dados e Informações (conjunto de informações para a produção industrial e retirada do produto)

Objetivos de melhoria no processo de gestão

Executar eficientemente tarefas bem estabelecidas

Resolver problemas de maneira rápida e eficaz

Unidade Elementar para a melhoria do Processo

Racionalizar o fluxo de materiais e recursos

Aumentar a competência dos indivíduos

Prazo de Duração

Curto (dias)

Longo (anos ou meses)

Grau de repetibilidade das atividades

Alta

Baixa

Nas operações produtivas, o produto e as atividades necessárias para construí-lo são definidos antes do início da fabricação. Os momentos de decisão são claros e, na maioria das vezes, podem ser padronizados por regras do tipo “Se... Então”. A inspeção de qualidade é um exemplo: se houver arranhões na pintura ou encaixe inadequado de um conjunto, enviar para a remanufatura; se houver problemas mais complexos, deve-se refugar o produto. O fluxo de materiais e atividades é bem definido e o ciclo, ou lead time, é de dias, trazendo o benefício da previsibilidade. Com intervalos de tempo curtos, é mais fácil estimar os prazos e as durações das atividades. As melhorias podem ser tratadas como ações paralelas, enquanto o processo principal é executado e mantido em um determinado nível de controle. Os processos de negócio que possuem essas características podem ser ditos estruturados, pois o resultado esperado é claro, as atividades para atingi-lo são previsíveis e percebidas da mesma forma por todos. Outros exemplos de processos bem estruturados são: aprovação de contas em um banco; processamento de um sinistro em uma companhia de seguros; compras; preparação de balanços financeiros e outros. O processo de desenvolvimento de produtos é de outra natureza. Parte significativa das atividades que o compõem envolve criação. Muitas vezes, tem-se pouco conhecimento do resultado final a ser alcançado. Tem-se conhecimento de diretrizes gerais de desempenho esperado no produto ou serviço, por exemplo: precisa-se de um freio de automóvel que pare um carro de 500kg, em 100m a uma velocidade de 80Km por hora. A configuração do mecanismo de freio será “criada” ao final do processo. Com pouco conhecimento do resultado esperado, fica difícil prever todas as atividades, como: quantas horas para detalhar as características do produto serão necessárias e quantas pessoas e como o resultado será consolidado? O mesmo vale para os momentos de decisão. A criação do produto envolve milhares de pequenas decisões interdependentes: que material escolher, qual o melhor desenho de estrutura, como realizar as atividades de testes e assim por diante. É difícil sistematizá-las previamente a partir de uma regra. A situação torna-se mais crítica se considerarmos que o conhecimento tecnológico avança rapidamente, trazendo novas possibilidades de soluções, novos caminhos, que precisam ser testados. Problemas idênticos, em dois projetos distintos no tempo, podem receber tratamentos diferentes, mesmo que solucionados por um único profissional. Basta que uma nova teoria, técnica ou conhecimento seja absorvida durante o período que distanciou os projetos.

Quadro 2.8

Diferenças entre o PDP e Outros Processos Estruturados

90

PARTE 1

O Processo

Note que em um processo estruturado, o fluxo a ser otimizado é o de materiais e recursos tangíveis, que podem ser medidos precisamente e cujas decisões são em um grau de variação menor. Nesses casos, o foco da melhoria do processo está na execução eficiente do fluxo e na melhoria contínua das práticas empregadas. No caso do desenvolvimento de produto, cada projeto realizado é bastante particular. Se é difícil entender quais são as atividades, como otimizar os métodos? Se o resultado é o conhecimento, como medi-lo? É evidente que nos processos não estruturados, melhorar a capacidade de solução de problemas da equipe é mais importante do que aprimorar os métodos. Pois mais importante do que dizer “como fazer” é possuir profissionais capazes de reagir adequadamente a cada situação, encontrando a melhor forma de proceder conforme o problema de projeto enfrentado. Conforme a capacitação do pessoal aumenta, maior a probabilidade de que soluções melhores sejam encontradas em cada momento do processo de desenvolvimento. A velocidade também depende disso, pois a equipe mais capacitada deverá encontrar as soluções mais rapidamente, diminuindo também o tempo de desenvolvimento. No final dos anos 1990, vários teóricos do mundo organizacional demonstraram, na prática, que, por trás de uma maior eficiência na área de desenvolvimento de produto, está a maior capacitação da equipe e a habilidade da empresa em mantê-las atualizadas. Os termos “empresa que aprende” e “aprendizagem organizacional” foram criados para designar as empresas que se distinguiam em termos de capacidade de aprendizado contínuo. Uma organização que aprende é aquela que continuamente revê suas práticas. Exemplo da Boeing Um exemplo citado é a Boeing. Após sofrer com vários problemas nos projetos dos aviões 737 e 747, a empresa criou um projeto batizado de homework. Uma equipe de gerentes seniores, com grande experiência, estudou e identificou as causas possíveis de cada um dos problemas ocorridos nesses projetos e os erros cometidos, comparando o processo de desenvolvimento desses aviões com 26 os dos 707 e 727 (com alto nível de sucesso). Segundo consta, o resultado desse estudo foi empregado nos projetos dos modelos 757 e 767, os quais, mais tarde, se tornaram os mais lucrativos da empresa. Uma empresa que aprende é também aquela cujo ambiente convida as pessoas O ambiente deve ser a se aprimorarem. Na época do “milagre econômico” japonês, no final dos anos convidativo ao 1980, identificou-se que a vantagem em desenvolvimento de produtos das empresas aprendizado e à inovação oriundas desse país estava relacionada com a postura dos engenheiros chefes que desafiavam as suas equipes a pesquisar e solucionar problemas, a aprender continuamente, em vez de dizer como o projeto deveria ser feito — tal qual ocorria nas empresas norte-americanas. Um exemplo é o Honda City, um grande sucesso de mercado, cujo projeto teve início com a proposta desafiadora de Hiro Watanabe de criar um carro com o seguinte slogan: “máximo de ser humano e mínimo de máquina”. O trabalho com esse desafio levou ao conceito de carro curto e alto, que influenciou e modificou o rumo da indús27 tria automobilística. Exemplo semelhante foi a tecnologia de tambor descartável criada pela Cannon , que permitiu a criação de toda uma geração de máquinas copiadoras de tamanho reduzido. Essa inovação teve origem em um desafio aos paradigmas vigentes proposto pelos líderes de projeto. O importante são pessoas capacitadas em resolver problemas

A organização que aprende é a que dispõe de habilidades para criar, adquirir e transferir conhecimentos e é capaz de modificar seu comportamento, de modo a refletir os novos conhecimentos e idéias (Garvin, 1988).

Uma empresa que aprende é também aquela que consegue criar um ambiente que estimule e cobre das pessoas uma postura de aprendizagem contínua e a reflexão sobre os problemas passados e experimentação como hábitos de trabalho. Um ambiente no qual as pessoas estejam continuamente introduzindo melhorias. Ela 26 27

Esse caso foi descrito primeiro por GARVIN, David A. Construindo a organização que aprende. Rio de Janeiro: Ed. Campus, 2000. Esse caso é descrito nos livros: DECHAMPS J.P. & NAYAK. P.R. Produtos irresistíveis. São Paulo: Makron Books, 1996; e NONAKA, Y. “A empresa criadora de conhecimento.” In: Harvard Business Review. Gestão do conhecimento. Rio de Janeiro: Campus, 2000.

CAPÍTULO 2

O Modelo Unificado do PDP

91

possui estrutura organizacional, procedimentos, práticas e cultura, isto é, valores, crenças, entre outros, compartilhados entre seus funcionários, voltados para o aprendizado contínuo. Na base da empresa que aprende está o profissional e o conceito de compeÉ a competência das tência. Na verdade, dizer que uma empresa aprende é uma figura de linguagem. São pessoas que torna a as pessoas que aprendem, que aprimoram suas competências e são responsáveis pela empresa uma organização renovação das práticas. Portanto, no âmago da empresa que aprende está o desenque aprende volvimento das competências individuais de seus colaboradores. Pode-se definir competência como o conjunto de conhecimentos, habilidades e atitudes, formadas a partir da experiência prática. Trata-se, portanto, da capacidade desenvolvida pelo profissional em solucionar problemas em um determinado campo de atuação. A competência é difícil de ser medida. Ela se manifesta no desempenho do indivíduo, mais precisamente no momento em que se observa a qualidade dos resultados produzidos por ele. Se há excelência na solução, há um conjunto de conhecimentos, habilidades e atitudes. Nesse conjunto, deve-se destacar o componente conhecimento. Trata-se de Conhecimento é algo difícil de ser medido, mas é fundamental para o aumento da competência dos fundamental para funcionários. Ele é indissociável do indivíduo e se materializa no conjunto de consaumentar a competência trutos que cada um se utiliza para interpretar o mundo. Não pode ser transmitido diretamente. Seu acréscimo depende de um processo individual de cada pessoa, facilitado pelo contato com informações e pela interação com outros indivíduos. Na prática, os gestores de áreas relacionadas ao processo de desenvolvimento de produtos não podem criar o ambiente em si — isso depende da interação dos profissionais. Resta-lhes criar ações e condições que estimulem o desenvolvimento desses ambientes. Tais incentivos compreendem desde formas mais tradicionais — como leituras, cursos, interações com clientes e fornecedores e interações entre os membros da empresa — até outras menos usuais — como promover e criar comunidades de pessoas interessadas em determinados assuntos, criar sistemas de informação que aproximem pessoas de diferentes unidades ou setores da empresa. O termo empregado para isso é o de Gestão do Conhecimento. Em termos formais, a Gestão do Conhecimento (GC) pode ser definida como Definição de Gestão do o conjunto de práticas e atividades destinadas a incentivar e garantir a criação, comConhecimento partilhamento e disseminação de informações e a troca de experiências visando a melhoria contínua das competências das pessoas e, conseqüentemente, o crescimento do conhecimento organizacional. Um problema com esse termo é que, em um primeiro momento, ele pode passar uma idéia errada, a de que se está gerenciando, isto é, planejando, controlando e medindo o conhecimento em si. Na verdade, como vimos anteriormente, o conhecimento não pode ser planejado, medido ou controlado. O que se planeja e se controla são as ações e as práticas gerenciais que estimulam a manutenção e a aprendizagem contínua das pessoas, por meio do compartilhamento de conhecimentos. Portanto, o objetivo da Gestão do Conhecimento é garantir que a empresa desenvolva práticas e uma “cultura” de criação, compartilhamento e uso de conhecimentos.

Gestão do Conhecimento (GC): o conjunto de práticas e atividades destinadas a incentivar e garantir a criação, compartilhamento e disseminação de informações e a troca de experiências, visando a melhoria contínua das competências das pessoas e, conseqüentemente, o crescimento do conhecimento organizacional.

Os projetos de gestão do conhecimento precisam trabalhar todos os aspectos das organizações para surtirem efeito, avaliando-os perante as necessidades de aprendizagem contínua e propondo ações para que reforcem a aprendizagem. Deve-se observar desde a missão, estratégia, política de recursos humanos, os sistemas de informações até os padrões e procedimentos organizacionais.

92

PARTE 1

O Processo

No modelo unificado de referência deste livro, a Gestão do Conhecimento (GC) permeia todas as atividades. A política de recursos humanos deve promover o clima para que o compartilhamento de conhecimentos ocorra. A definição de estratégias da empresa e por conseqüência as estratégias de produto devem reutilizar experiências do passado. Os sistemas de informação devem possibilitar a inserção de conhecimentos explícitos dos mais diversos tipos, a sua recuperação e a formação de comunidades entre membros da empresa, do time de desenvolvimento, dos parceiros externos e das pessoas que possuem interesses comuns. No final de cada fase do modelo, existe uma atividade denominada “Documentar as decisões tomadas e registrar as lições aprendidas”. A existência formal dessa atividade reforça a necessidade de realização de uma das facetas mais importantes da Gestão do Conhecimento: o armazenamento sistemático de informações e experiências. Isso deve ocorrer constantemente, sempre que uma pessoa considerar que possui conteúdo para compartilhar com os seus colegas e com a empresa como um todo. O acúmulo desses conhecimentos explícitos (que podem ser documentados) e de ferramentas de TI apropriadas permitem que esse conhecimento seja reutilizado, evitando, assim, que a empresa incorra nos mesmos erros do passado. Isso cria a empresa que aprende. As descrições das atividades do modelo não vão apresentar de maneira explícita atividades dessa natureza, mas, após este tópico, esperamos que o leitor considere que o compartilhamento de conhecimentos é uma postura constante de todos os membros do time de desenvolvimento. O próprio modelo é um registro de conhecimentos explícitos (regras de negócio, padrões) e seu uso, na otimização e sistematização do PDP, é considerado uma boa prática de Gestão do Conhecimento. Vamos agora discutir as características do modelo unificado, preparando o leitor para interpretar a segunda parte deste livro. Gestão do Conhecimento no modelo unificado de referência do PDP

2.13 Caracterizando o modelo No início deste capítulo, mostramos que o modelo de referência deste livro é voltado para empresas de manufatura de bens de consumo duráveis e/ou capital com ênfase na tecnologia mecânica de fabricação. Mostramos, também, os conceitos básicos sobre modelagem de processos para você entender a importância da existência de um modelo de referência. Em seguida, apresentamos uma visão geral do modelo, das suas macrofases, os papéis usuais das pessoas em um processo de desenvolvimento de produtos e destacamos alguns conceitos importantes do nosso modelo: a revisão de fases (gates); como relacionar os métodos e ferramentas de desenvolvimento de produtos ao modelo; os tipos de parceiros e as formas de relacionamento entre eles dentro de uma cadeia de suprimentos; e quais os indicadores de desempenho utilizados para avaliar os processo. Finalmente, mostramos as áreas de conhecimento tratadas no modelo e também como ele pode ajudar na Gestão do Conhecimento do processo de desenvolvimento de produtos. Agora que já temos a visão geral do modelo, podemos caracterizá-lo melhor para que você entenda para que serve o modelo apresentado neste livro. Para isso, vamos discutir mais um conceito importante da modelagem de processos: os modelos de referência e seus tipos. Deixamos esse assunto para este tópico e não para o início deste capítulo, pois, agora, você possui conhecimentos que facilitam o entendimento dessa questão. Existe uma discussão acadêmica sobre o significado do modelo de referência, Definição de modelo de mas, neste livro, vamos adotar a seguinte definição “modelo de referência pode ser referência e seus tipos utilizado como base para a criação de outros modelos ou para a definição de projetos”. Denominamos de modelo de referência genérico, quando definimos, a partir dele, um modelo de referência específico para uma determinada empresa, que, por sua vez, serve de base à definição de projetos de desenvolvimento de produtos dessa empresa, como ilustrado na Figura 2.25.

CAPÍTULO 2

O Modelo Unificado do PDP

Figura 2.25

93

Modelos de referência genéricos dando origem a modelos de referência específicos, os quais, por sua vez são a base para a definição de projetos.

Um modelo de referência genérico normalmente é voltado para um determinado setor, mas pode ser utilizado por mais de um setor. Por exemplo, um mesmo modelo genérico pode servir como referência para os setores de máquinas agrícolas e máquinas-ferramentas. Empresas de um mesmo setor poderiam definir os seus modelos específicos a partir do modelo genérico. No entanto, a partir da nossa experiência, consideramos que existem vários fatores que diferenciam empresas de um mesmo setor, dificultando a criação e a aplicação de um modelo genérico único para um determinado setor. Isto é, duas empresas de um mesmo setor podem possuir modelos de processos bens distintos. Não basta ser do mesmo setor. Portanto, um modelo genérico de um determinado setor deve ainda considerar outros fatores que o individualizam, como tecnologia, tipo de projeto de desenvolvimento, posição e relacionamento da empresa com os seus parceiros na cadeia de suprimentos, estratégia de produção, grau de responsabilidade da empresa, nível de maturidade em desenvolvimento de produtos, forma de inserção da empresa dentro do grupo, tipo de mercado, 28 entre outros. Em outras palavras, pode existir mais de um modelo de referência genérico para um mesmo setor (veja, na ilustração da Figura 2.25, o caso do Setor A que possui três modelos de referência genéricos). Um exemplo fácil de ser entendido está no setor automotivo. Vamos listar três tipos de fornecedores, diferenciando para esse exemplo somente o fator tecnologia: os de componentes eletrônicos, como a injeção eletrônica; os de pneus; e os fornecedores de chassi de carros. Alguns aspectos gerenciais do processo dessas empresas são equivalentes, mas, quando se trata das fases tecnológicas, as atividades a serem realizadas são distintas. Isso significa que os modelos de referência para esses fornecedores são diferentes. A maior diferença está nas atividades relacionadas com as tecnologias específicas: eletrônica, processamento de borracha e estrutura metálica e processo de soldagem. Então, para cada um desses três grupos de fornecedores, há um modelo genérico, e cada empresa dentro do grupo tem um modelo específico. O modelo apresentado em detalhes na Parte 2 deste livro é um modelo de refeQual o tipo do modelo rência genérico. O foco é na tecnologia de fabricação mecânica e é voltado para o deste livro? setor de bens de consumo duráveis, tais como produção de equipamentos, eletrodomésticos, linha branca (geladeira, fogão, lavadora etc.), automóveis etc. Vamos considerar agora alguns dos fatores de diferenciação do PDP listados para melhor caracterizar o modelo deste livro: 28

Para estudar uma discussão mais completa dos fatores que influenciam e caracterizam o processo de desenvolvimento de produtos, consulte ROZENFELD & AMARAL (1999).

94

PARTE 1

■ ■ ■

O Processo

tipo de projeto de desenvolvimento; posição e relacionamento da empresa com os seus parceiros na cadeia de suprimentos; e estratégias de produção.

Os tipos de projeto já foram discutidos no Capítulo 1 — radical, plataforma, derivado e follow source —, e a posição e o relacionamento da empresa com os seus parceiros na cadeia de suprimentos estão no Tópico 2.10, deste capítulo. Vamos agora conhecer as estratégias alternativas de produção, antes de analisar a aplicabilidade do modelo. Normalmente, os produtos do setor de bens de consumo duráveis são desenEstratégias de produção volvidos a partir de análise de mercado, com a estratégia de produção conhecida como Make To Stock (MTS). Ou seja, são produzidos para estoque e não para um cliente específico. Um exemplo é a fabricação de geladeira, um bem de consumo durável. Seus fabricantes pos29 suem uma análise da demanda por um produto, e, com base nessa análise, eles o produzem para estoque. Em certos casos, alguns desses produtos são produzidos conforme a especificação de um cliente em particular. As diferentes especificações definem uma combinação de acessórios, previamente definidos pela montadora. O desenvolvimento, então, já prevê todas essas variações. As estratégias de produção nesse caso podem ser Assembly To Order (ATO) ou Make To Order (MTO). Na estratégia ATO, os sistemas e os componentes principais são produzidos para um estoque intermediário, e, a cada pedido, o produto final é montado utilizando esses componentes — como é o caso de alguns fabricantes de computadores, em que o produto final é montado no distribuidor. Se o tempo de produção desses sistemas e componentes for menor do que o tempo de espera aceito pelo cliente, ou mesmo se a empresa trabalhar com Just In Time (JIT), estaremos falando da estratégia de MTO, isto é, somente após a entrada do pedido é que as peças são produzidas e, em seguida, o produto é montado. Esse é o caso de alguns produtos da indústria automobilística. Somente após o pedido do cliente30 é que a montadora inicia a produção do veículo. Para empresas de bens de capital de alto valor agregado (como uma turbina de uma hidroelétrica), a estratégia de produção é a Engineering To Order (ETO). Ou seja, a macrofase de desenvolvimento só é iniciada após a venda e o pedido do cliente. E, normalmente, esse pedido vem com especificações técnicas detalhadas e particulares. Agora temos todos os elementos para discutir onde se pode aplicar o modelo O modelo deste livro é deste livro. aplicável para qual tipo de Na Tabela 2.3 estão listados os fatores de diferenciação citados e na coluna da projeto e empresa? direita é mostrada a aplicabilidade do modelo deste livro. Tabela 2.3

Análise da Aplicabilidade do Modelo para Alguns Fatores de Diferenciação das Empresas

Fator de diferenciação Tipo de Projeto

Posição na cadeia de suprimentos

Aplicabilidade do Modelo

Projeto radical

Total, mas é preciso considerar uma maior integração com o processo de P & D.

Projeto plataforma

Total

Projeto derivado

As fases iniciais do desenvolvimento podem ser simplificadas.

Projeto follow source

As fases de Projeto Conceitual e Preliminar devem ser bem simplificadas ou até eliminadas.

Montador

Total

Fornecedor de equipamentos e ferramental

Total no caso de fornecimento para mercado. No caso de fornecimento sob encomenda, deve seguir a recomendação do tipo de produção ETO.

(continua) 29 30

Em alguns casos, as redes de lojas de revenda enviam uma previsão para os fabricantes e fecham a compra de grandes quantidades de geladeiras. A produção, então, é feita para atender esses pedidos. Nesse caso, o cliente pode ser um cidadão comum ou uma concessionária.

CAPÍTULO 2

O Modelo Unificado do PDP

Tabela 2.3

Análise da Aplicabilidade do Modelo para Alguns Fatores de Diferenciação das Empresas (continuação)

Fator de diferenciação

Relacionamento na cadeia de suprimentos

Estratégia de Produção

95

Aplicabilidade do Modelo

Fornecedor de primeiro nível

A fase de lançamento do produto é praticamente eliminada, pois todo o contato com o mercado fica com o montador.

Fornecedor de segundo nível

Idem ao anterior. Além disso, o modelo deve ser simplificado, pois, normalmente, os produtos são mais simples.

Fornecedor de commodities

Total, mas, dependendo da complexidade da commodity (e normalmente ela não é complexa), deve ser simplificado.

Fornecedor de matéria-prima

Parcial, pois a natureza (tecnologia) do material pode exigir outros tipos de atividades.

Fornecedor de tecnologia

Não é diretamente aplicável, mas é bom que um fornecedor desse tipo conheça o modelo, quando for participar do PDP dos clientes.

Fornecedor de serviços

Idem ao fornecedor de tecnologia.

Parceria de risco

Total

Parceiro de tecnologia

Deve se preocupar com as atividades relacionadas à prospecção tecnológica e de desenvolvimento, avaliação e teste de novas tecnologias, presentes nas fases iniciais do modelo.

Parceria estratégica

Total

Co-desenvolvedor

Total

Fornecedor de serviços

Poderá utilizar este modelo para estruturar um processo de venda e entrega do serviço. Deverá ser algo bem mais simplificado uma vez que as atividades de busca de informações dos clientes e a geração de soluções serão mais simples. O pré-desenvolvimento descrito em nosso modelo não se aplica neste caso, à medida que os projetos dependerão mais de uma prospecção de demanda do que planejamento de uma estratégia.

Fornecedor de peças-padrão

Idem ao anterior, mas um modelo para desenvolvimento de produtos padronizados, no qual as fases iniciais de planejamento estratégico, planejamento do projeto, projeto informacional e conceitual serão tremendamente simplificados, dado que são peças normalmente descritas cujas funções e características estão descritas em normas técnicas de fácil acesso.

Produção MTS

Total

Produção ATO

Total (a diferença está na forma como o produto é estruturado para facilitar essa estratégia).

Produção MTO

Total

Produção ETO

O pré-desenvolvimento terá que ser modificado. A fase de planejamento estratégico do produto é simplificada, pois a empresa tem menor poder de decisão diante da demanda que deverá atender. Porém, a fase de planejamento do projeto será muito mais sofisticada e deverá incluir parte das atividades das fases do projeto informacional e de lançamento. As atividades do projeto detalhado poderão ocorrer em mais de um ciclo, dada a complexidade do projeto; a fase de preparação da produção deve ser simplificada; provavelmente a fase de lançamento será eliminada, e, em seu lugar, haverá um esforço bem grande nas atividades de homologação de 31 forma a certificar que o produto atinge todas as metas previstas.

Vê-se que a aplicabilidade é para todo o tipo de projeto, ressaltando-se a necessidade de uma maior integração com o processo de P & D no caso de projetos radicais; além disso, algumas aplicações precisam de um modelo mais simplificado que o proposto. Como é raro que projetos radicais sejam realizados no Brasil, a aplicabilidade é grande para as empresas do setor a que ele se destina. Dentro da cadeia de suprimentos do setor de bens de consumo duráveis e de capital, o modelo proposto neste livro pode ser adotado como referência por empresas de todos os tipos, exceto a de fornecedores de tecno31

Consulte as adaptações desse modelo para atender empresas que trabalham com a estratégia ETO no Capítulo 16.

96

PARTE 1

O Processo

logia e serviços. Porém, como citado na Tabela 2.3, recomenda-se que as empresas desse tipo estudem o modelo para conhecer as possíveis fases e atividades do PDP dos seus clientes, uma vez que elas poderão atuar nesse processo. O processo de desenvolvimento mais abrangente é o das montadoras, cujo produto sempre é voltado para um mercado amplo de consumidores. Este livro, então, apresenta uma proposta para esse tipo de empresa. Para os demais tipos de empresa, o modelo pode ser simplificado. O modelo abrange, também, a maior parte das formas de relacionamento que agregam mais valor ao PDP. Nesses casos, deve-se usar esse modelo unificado para mapear o processo “conjunto” de desenvolvimento entre os membros da cadeia de suprimentos, mas o papel de cada um dos parceiros tem de ser bem definido. Isto é, quem será responsável por qual atividade. O modelo pode ser adaptado para empresas que fornecem sob encomenda para um cliente específico dentro da cadeia de suprimentos (caso dos fornecedores de equipamentos especiais). A adaptação está descrita na Tabela 2.3 de forma geral e em detalhes no Capítulo 16. A macrofase de desenvolvimento para todos os casos é praticamente a mesma. A ênfase dessa macrofase está na aplicação da tecnologia metal mecânica. Mas ela também pode ser adotada para produtos que utilizam outras tecnologias, como eletrônica e mecatrônica. Nesses casos, porém, deve-se especificar atividades adicionais voltadas a essas tecnologias (por exemplo, desenvolvimento de software, integração de hardware, projeto de circuitos eletrônicos etc.). As macrofases de pré-desenvolvimento e pós-desenvolvimento são mais genéricas e provavelmente podem ser utilizadas como referência para qualquer tipo de produto. Foram analisados somente esses critérios de diferenciação do modelo, mas existem outros, como já foi citado. Fique atento ao analisar a Tabela 2.3, pois uma empresa real não deve considerar somente um tipo de fator de diferenciação para verificar a aplicabilidade do modelo. A análise deve considerar todos os tipos de fatores simultaneamente. Como as diferenças de conteúdo do modelo dependentes do tipo de projeto in32 Esse modelo possui 4 cluem somente a simplificação do modelo, uma mesma empresa pode utilizar verversões: uma completa e sões mais simplificadas do modelo porque projetos de tipos distintos podem ser suas simplificações realizados paralelamente. Por exemplo, a empresa pode estar desenvolvendo um projeto plataforma para criar uma nova família de produtos “A”; e a mesma empresa pode estar realizando um projeto derivado “B34”, a partir da plataforma “B”. Para o projeto “A”, ela estará usando a totalidade do modelo proposto e, no caso do projeto “B34”, ela usará um subconjunto do modelo. Na verdade, então, esse nosso modelo de referência tem quatro versões: a completa, que contém todas as fases e atividades propostas na Parte 2 deste livro; e três versões mais simplificadas para cada tipo de projeto. Esse assunto será discutido no Capítulo 5 deste livro, durante o planejamento do projeto, quando se extrai do modelo de referência as atividades que comporão um projeto de desenvolvimento. Na Parte 3 deste livro, mostramos um método para ser adaptado para o modelo Como adaptar o modelo de uma empresa específica, e explicamos em maiores detalhes o que deve ser mupara uma aplicação dado para os casos citados anteriormente (empresas de bens de capital, eletrônica e prática? mecatrônica). Provavelmente, as mesmas atividades apresentadas na Parte 2 deste livro podem ser utilizadas, porém ordenadas de uma outra forma e estruturadas dentro de outras fases. Em outras palavras, estaremos discutindo como transformar o modelo de referência genérico deste livro em um modelo de referência específico para uma determinada empresa (veja a Figura 2.25). Vamos agora conhecer em detalhes as atividades e tarefas de cada uma das fases do modelo na Parte 2 deste livro.

32

Exceto no caso de projetos radicais, que não estão sendo considerados neste momento — veja a Tabela 2.3, em que discutimos o que deve ser feito para projetos radicais, que será detalhado na Parte III.

CAPÍTULO 2

O Modelo Unificado do PDP

97

2.14 Resumo do capítulo Processos de negócio podem ser estruturados ou não estruturados; o PDP é não estruturado; e dele podem ser derivados projetos de desenvolvimento de produtos. Um processo de negócio pode ser representado por um modelo; o modelo deste livro representa um PDP padrão voltado para empresas de bens de capital e de consumo duráveis; é um modelo de referência genérico para esse setor; um modelo de referência proporciona à empresa e seus parceiros uma visão unificada do processo. O modelo unificado é dividido em macrofases, fases, atividades e tarefas; as macrofases são: pré-desenvolvimento, desenvolvimento e pós-desenvolvimento. O que determina uma fase é a entrega de resultados (deliverables), que permanecem congelados a partir do momento em que a fase é finalizada; o final de uma fase é delimitado pela avaliação de fase ou gate. Embora as fases estejam representadas de forma seqüencial, elas podem estar sobrepostas em um projeto real. A fase de Planejamento Estratégico de Produtos envolve vários produtos, e as demais fases relacionam-se com um produto em particular. Atores e times do PDP são: membros da diretoria, gerentes funcionais, responsável pela engenharia, gerente de projeto, especialistas, parceiros, Time de Planejamento Estratégico de Produtos, Time de Desenvolvimento, Time de Avaliação, Time de Acompanhamento do Produto; em empresas pequenas, uma mesma pessoa pode assumir diversos desses papéis. Planejamento Estratégico compreende: Planejamento Estratégico da Corporação (PEC), que responde sobre os rumos da corporação como um todo, incluindo todas as unidades de negócio; Planejamento Estratégico da Unidade de Negócios (PEUN), que detalha como será a estratégia de ação da unidade de negócio em si; Planejamento Estratégico de Produtos (PEP), que é a primeira fase do pré-desenvolvimento. Planejamento Estratégico de Produtos garante que o direcionamento estratégico seja mapeado e transformado em um conjunto de projetos bem definidos, isto é, a carteira de projetos que deverão ser desenvolvidos (portfólio de projetos); considera a estratégia tecnológica, que é o enfoque que a empresa adota para o desenvolvimento e uso da tecnologia. Pré-desenvolvimento envolve também o planejamento detalhado de cada um desses projetos; deve-se decidir se realmente o que foi definido no planejamento estratégico tem chance de acontecer; no final do planejamento, verifica-se se o desenvolvimento do presente produto deve continuar ou não. Pré-desenvolvimento é a ponte entre objetivos da empresa e os projetos de desenvolvimento. Características do PDP: no início, o grau de incerteza é grande; porém é neste momento que são realizadas as escolhas de soluções de projeto (materiais, conceitos, processos de fabricação etc.), as quais determinam aproximadamente 85% do custo final do produto; portanto, as fases iniciais do desenvolvimento são importantes; mudanças sempre ocorrem, e o importante é fazer com que elas ocorram no início do desenvolvimento, quando o custo das alterações é menor. Engenharia Simultânea é uma filosofia utilizada no desenvolvimento; possui as seguintes premissas: trabalho em equipe, que envolve clientes e fornecedores; considera todos os elementos do ciclo de vida do produto; enfatiza o atendimento das expectativas dos clientes; paralelismo entre atividades; faz uso de métodos e sistemas integrados de engenharia, tais como QFD, FMEA, DFx, CAD/CAE, CAPP, PLM. O time de desenvolvimento varia em tamanho e tipo de membro, dependendo da fase. No desenvolvimento, são produzidas com detalhes todas as informações técnicas, de produção e comerciais relacionadas com o produto; os protótipos já foram aprovados; os recursos a serem utilizados para a sua produção, comercialização e suporte técnico foram comprados, recebidos, testados e instalados; alguns produtos foram fabricados e aprovados; já ocorreu o lançamento no mercado e as pessoas da cadeia de suprimentos estão informadas e treinadas — tanto aquelas de empresas parceiras no fornecimento quanto as que estão envolvidas na comercialização e suporte. Em alguns casos, novos processos de negócio de produção, atendimento ao cliente e assistência técnica foram desenhados e implementados.

98

PARTE 1

O Processo

Pós-desenvolvimento compreende: o acompanhamento sistemático e a documentação correspondente das melhorias de produto ocorridas durante o seu ciclo de vida; recebe informações de todos os processos de negócio envolvidos com o produto; quando necessário, aciona os processos de apoio correspondentes de gerenciamento das mudanças de engenharia; ou de melhoria do PDP; gerencia também a retirada sistemática do produto do mercado e finalmente uma avaliação de todo o ciclo de vida do produto; garante que parte das pessoas e os conhecimentos acumulados estejam à disposição da empresa, viabilizando a sua reutilização em novos projetos de desenvolvimento. Na revisão de fase (gate), avaliamos os resultados do projeto individualmente e também se ele ainda é o mais atrativo para empresa, considerando o portfólio de projeto; possui as seguintes atividades: a definição dos critérios, auto-avaliação (pelo time de desenvolvimento) e aprovação pelo time de avaliação. Ferramentas e métodos são meios que existem para apoiar à realização das atividades do PDP, e, neste livro, estão resumidamente colocados em quadros. Existem dois grandes grupos de indicadores para o PDP: relacionados com o processo como um todo e relacionados com os projetos e produtos individuais, que medem sucesso financeiro, operacional, qualidade e perceptivo. O PDP pode ser realizado de forma colaborativa desde as primeiras fases do desenvolvimento com os seus parceiros de cadeia de suprimentos; tipos de parceiros: montador, fornecedor de equipamentos e ferramental, fornecedor de primeiro nível, fornecedor de segundo nível, fornecedor de commodities, fornecedor de material, fornecedor de tecnologia e fornecedor de serviços; formas de relacionamento: parceria de risco, parceria tecnológica, parceria estratégica, co-desenvolvimento, parceria de produção, contratados de longo e curto prazos. Agrupar as atividades em cada fase é mais didático; pode-se também agrupar as atividades em áreas de conhecimento, garantir que os aspectos dessas áreas sejam considerados nas fases; as áreas de conhecimento são: gestão de projetos, meio ambiente, marketing, engenharia de produto, engenharia de processo, produção, suprimentos, qualidade e custos. A organização que aprende é a que dispõe de habilidades para criar, adquirir e transferir conhecimentos e é capaz de modificar seu comportamento, de modo a refletir os novos conhecimentos e idéias; os gestores de áreas relacionadas ao PDP não podem criar o ambiente de uma empresa que aprende, isso depende da interação dos profissionais; resta-lhes criar ações e condições que estimulem o desenvolvimento desses ambientes. Gestão do Conhecimento é o conjunto de práticas e atividades destinadas a incentivar e garantir a criação, compartilhamento e disseminação de informações e a troca de experiências visando a melhoria contínua das competências das pessoas e, conseqüentemente, o crescimento do conhecimento organizacional; no modelo unificado de referência deste livro a Gestão do Conhecimento permeia todas as atividades. Este livro apresenta um modelo de referência genérico, com foco na tecnologia de fabricação mecânica, voltado para o setor de bens de consumo duráveis, tais como produção de equipamentos, eletrodomésticos, linha branca (geladeira, fogão, lavadora etc.), automóveis etc; avalia, ainda, a aplicabilidade do modelo para PDP diferenciado por: tipo de projeto, posição e relacionamento na cadeia de suprimentos e estratégias de produção.

2.15 Questões e atividades didáticas propostas 1. Defina projeto, processo de negócio e cite as diferenças entre um projeto de desenvolvimento de produtos e um processo. 2. Visite o setor de desenvolvimento de produtos de uma empresa para conhecer o modelo de referência para desenvolvimento de produtos utilizado. Faça um relatório com as seguintes atividades: a) Compare com as fases do processo de desenvolvimento de produto. b) Identifique, na estrutura organizacional das empresas, quem exerce cada um dos papéis propostos no Tópico 2.3. c) Descreva os principais documentos gerados durante o desenvolvimento de produtos da empresa e compare-os com os resultados apresentados na Figura 2.9, principais resultados das fases, de forma a identificar o conteúdo de cada documento.

CAPÍTULO 2

O Modelo Unificado do PDP

99

3. Qual a relação entre o processo gerencial de planejamento estratégico e o processo de desenvolvimento de produtos? 4. O que é Engenharia Simultânea? 5. Cite o principal resultado e cinco atividades que acontecem em cada uma das macrofases do modelo: a) Pré-desenvolvimento. b) Desenvolvimento. c) Pós-desenvolvimento. 6. Defina Modelo de Referência. 7. Cite três usos potenciais dos modelos de referência. Qual é a função que podemos definir como a que engloba todas as demais (ou seja, à qual todos os objetivos são comuns)? 8. Quais das atividades a seguir não serão auxiliadas com o uso de modelos de referência? a) Desenvolver o Manual de Qualidade da Empresa. b) Análise de requisitos e implantação de sistemas de informação. c) Desenvolver a estratégia de produtos da empresa. d) Identificar skills e habilidades necessárias para as diversas funções da empresa. e) Gerenciar e identificar melhorias nos processos de negócio. 9. Por que, em termos de desenvolvimento de produtos, é necessário que uma empresa tenha vários modelos de referência ou um único modelo “customizável”? 10. Cite três características do processo de desenvolvimento de produto que influenciam na “customização” do modelo de referência. 11. Das características a seguir, qual não interfere na definição do processo de desenvolvimento de produtos? a) Grau de inovação do projeto. b) Inserção da empresa na estrutura mundial do desenvolvimento de produtos. c) Informações iniciais recebidas para o desenvolvimento do projeto. d) Setor industrial do qual a empresa faz parte. e) Número de projetistas e processadores que a empresa possui trabalhando.

2.16 Informações adicionais AMARAL, D. C. Arquitetura para gestão do conhecimento no processo de desenvolvimento de produtos. Tese (Doutorado) — Escola de Engenharia de São Carlos, Universidade de São Paulo, São Carlos, 2002. p.208. AMARAL, D. C.; ROZENFELD, H.; MOSCONI, E. P.; TOLEDO, J. C.; ALLIPRANDINI, D. H.; FORCELLINI, F. A. Development of reference model for integrating product development process-related knowledge. In: 17º INTERNATIONAL CONGRESS OF MECHANICAL ENGINEERING, São Paulo, 2003. COBEM. São Paulo: ABCM, 2003. v.17. O ARAUJO, C. S. An analisys of the life-cycle of product development tools. In: 2 BRAZILIAN CONGRESS OF PRODUCT DEVELOMENT MANAGEMENT, 2000, UFSCar, São Carlos, Brazil. ago. 2000, p. 30-31. BENEDICTIS, C. C.; AMARAL, D. C.; ROZENFELD, H. Avaliação dos principais métodos e ferramentas disponíveis para a modelagem do processo de desenvolvimento de produto. In: 4º CONGRESSO BRASILEIRO DE GESTÃO DE DESENVOLVIMENTO DE PRODUTO, 2003, Gramado. CBGDP. Porto Alegre: UFRGS, 2003. v. 4.

100

PARTE 1

O Processo

CLARK, K. B.; FUJIMOTO, T. Product development performance: strategy, organization and management in the world auto industry. Boston, Mass.: Harvard Business School Press, 1991. CLARK, K. B.; FUJIMOTO, T. Product development performance: strategy, organization and management in the world auto industry. Boston, Mass: Harvard Business School Press, 1991. CLAUSING, D. Total quality development: a step-by-step guide to world-class concurrent engineering. New York: Asme Press, 1993. COOPER, R. “From experience: the invisible success factors in product innovation.” The International Journal of Product Innovation Management, v. 13, p. 115-133, 1999. COOPER, R. G. Winning at new products: accelerating the process from idea to launch. Readin, MA: Perseus Books, 1993. CRUZ, T. Sistemas, métodos e processos: administrando organizações por meio de processos de negócios. São Paulo: Atlas, 2003. DECHAMPS, J. P.; NAYA, P. R. Produtos irresistíveis. São Paulo: Markron Books, 1997. DECHAMPS, J. P.; NAYA, P. R. Produtos irresistíveis. São Paulo: Markron Books, 1997. Harvard Business Review. Medindo o desempenho empresarial. Rio de Janeiro: Campus, 2000. KAPLAN, N.; NORTON. A estratégia em ação: balanced scoredcard. Rio de Janeiro: Campus, 1997. NONAKA, I.; TAKEUCHI, H. Criação de conhecimento na empresa. Rio de Janeiro: Campus, 1997. PAHL, G.; BEITZ, W. Engineering Design a systematic approach. Springer: Verlag, 1993. PEREZ, R. L., OGLIARI, A., BACK, N. Sistema de medição de desempenho aplicado no processo de projeto (SiMDAP). In: IV CONGRESSO BRASILEIRO DE GESTÃO E DESENVOLVIMENTO DE PRODUTOS, 2003, Gramado, RS, Brasil, 6 a 8 out. 2003. PUGH, S. Creating innovative products using Total Design: the living legacy of Stuart Pugh. Reading, MA: Addison Weslley, 1996. PUGH, S. Total design: integrated methods for successful product engineering. Reading, HA: Addison Wesley, 1991. Romano, L. N. Modelo de referência para o processo de desenvolvimento de máquinas agrícolas. 2003. Tese (Doutorado em Engenharia Mecânica) — Programa de Pós-Graduação em Engenharia Mecânica, Universidade Federal de Santa Catarina, Florianópolis, 2003. ROZENFELD, H.; AMARAL, D. C. Proposta de uma tipologia de processo de desenvolvimento de produto visando a construção de modelos de referência. In: I CONGRESSO BRASILEIRO DE GESTÃO DO DESENVOLVIMENTO DE PRODUTO, 1999, Belo Horizonte, MG. Anais do 1º Congresso Brasileiro de Desenvolvimento de Produto, 1999. p. 94-103. ROZENFELD, H.; AMARAL, D. C.; TOLEDO, J. C.; CARVALHO, J. “O processo de desenvolvimento de produtos e processos na fábrica do futuro.” In: ROZENFELD, H. R. (Org.). A fábrica do futuro. São Paulo: Banas. SHANE, S. A.; ULRICH, K. T. “Technological innovation, product development, and entrepreneurship.” Management Science, vol. 50, n. 2, p. 133-144, fev. 2004. SILVA, M. M.; ALLIPRANDINI, D. Aprendizagem organizacional no processo de desenvolvimento de produtos: investigação do conhecimento declarativo no contexto da sistemática de stage-gates. Dissertação (Mestrado) — Universidade Federal de São Carlos, Programa de Pós-Graduação em Engenharia de Produção, São Carlos, SP. p. 151. SILVA, S. L. DA. Proposição de um modelo para caracterização das conversões do conhecimento no processo de desenvolvimento de produtos. Tese (Doutorado em Engenharia Mecânica) — Escola de Engenharia de São Carlos, Universidade de São Paulo, São Carlos, 2002. 216 f.

CAPÍTULO 2

O Modelo Unificado do PDP

101

SILVA, S.; ROZENFELD, H. Gestão do conhecimento no processo de desenvolvimento de produto. In: I CONGRESSO BRASILEIRO DE GESTÃO DO DESENVOLVIMENTO DE PRODUTO, Belo Horizonte, out. 1999. SIMONS, R. Performance measurement & control systems for implementing strategy: texts and cases. New Jersey: Prentice Hall, 1999. TERRA, J. C. C. Gestão do Conhecimento. São Paulo: Negócio, 2000. TERRA, J. C. C. Portais corporativos: a revolução na Gestão do Conhecimento. São Paulo: Negócio, 2002. ULRICH, K. T.; EPPINGER, S. D. Product design and development. New York: McGraw-Hill, 1995. VALERI, S. G.; ROZENFELD, H.. “Improving the flexibility of new product development (NPD) through a new quality gate approach.” Journal of Integrated Design And Process Science, USA, v. 8, n. 4, p. 17-36, 2004. VALERI, Sandro Giovanni. Estudo do método de aprovação de fases no processo de desenvolvimento de produtos em uma indústria automobilística. Dissertação (Mestrado em Engenharia Mecânica São Carlos) — Universidade de São Paulo, 2001. Orientador: Henrique Rozenfeld. Of. VERNADAT, F. B. Enterprise modeling and integration: principles and applications. London: Chapman & Hall, 1996. WHEELWRIGHT, S. C. CLARK, K. B. Revolutionizing product development process: quantum leaps in speed, efficiency, and quality. New York: The Free Press, 1992. WHEELWRIGHT, S. C.; CLARK, K. B. Revolutionizing product development process: quantum leaps in speed, efficiency, and quality. New York: The Free Press, 1992.

Na Parte I, obtivemos uma visão abrangente do modelo de referência e dos conceitos gerais utilizados na sua construção. Cada uma das macrofases do modelo foi apresentada. Esta parte do livro descreve em detalhes as fases e atividades do modelo. Em todos os capítulos a seguir, há quadros que apresentam explicações detalhadas de conceitos e textos introdutórios sobre métodos e ferramentas relacionados com as atividades descritas no capítulo. Nesses casos, são citadas fontes para consulta adicional. A Figura PII representa o escopo de cada um dos 11 capítulos que compõem esta parte do livro. O Capítulo 3 descreve as atividades genéricas que são recorrentes em todas as fases. Assim, evita-se repetir o mesmo conteúdo na descrição de cada fase. As descrições das fases compreendem do Capítulo 4 ao Capítulo 12, como pode ser visto na figura. O Capítulo 13, o último desta parte, descreve os dois processos de apoio.

Figura PII

Visão geral dos capítulos que descrevem o modelo.

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8

Sumário Atualizar plano da fase Monitorar viabilidade econômico-financeira Avaliar fase Aprovar fase Documentar as decisões tomadas e registrar lições aprendidas Questões e atividades didáticas propostas Informações adicionais

3. Atividades Genéricas do Modelo Atividades Genéricas do Modelo PARTE 2 O Modelo

Depois da leitura deste capítulo, você será capaz de: l

l

l

l

l

Conhecer as atividades genéricas que são recorrentes em todas as fases do modelo unificado. Compreender a importância e saber como atualizar o plano de projeto no início de cada fase. Compreender a importância e como implementar o monitoramento da viabilidade econômico-financeira no final de cada fase. Definir as tarefas de revisão das fases (gates), cujos conceitos foram vistos no Capítulo 2. Essas atividades são realizadas no final de cada fase do modelo, em que estão definidos critérios a serem utilizados. Documentar as decisões tomadas durante o desenvolvimento e registrar as lições aprendidas. Os conceitos básicos dessas atividades encontram-se no Capítulo 2.

3.1

Sumário

Existem atividades que se repetem durante as fases que compreendem o desenvolvimento do produto, chamadas de atividades genéricas (veja a Figura 3.1). Elas são descritas neste capítulo com o objetivo de evitar sua repetição em cada uma das fases. Primeiro, para cada uma das fases, ocorre a atualização do plano do projeto, e as tarefas relacionadas com a fase que se inicia são atualizadas e detalhadas. Em seguida, ocorrem as atividades específicas de cada fase, descritas nos capítulos correspondentes. O monitoramento da viabilidade econômico-financeira é realizado durante o desenvolvimento da fase, nos momentos em que novas decisões possam comprometer os resultados do estudo de viabilidade, ou seja suas premissas e indicadores definidos e calculados no planejamento do projeto (veja o Capítulo 4). Porém, a atualização do estudo de viabilidade é formalmente realizada e documentada ao final de cada fase, antes da sua revisão (gate), pois a nova versão desse estudo fornece informações importantes para as tomadas de decisão do gate. Em seguida, realiza-se a revisão de fase (o gate propriamente dito), composta

106

PARTE 2

O Modelo

1

de duas atividades principais, como descrito no Capítulo 2. A primeira é a auto-avaliação, quando o próprio time de desenvolvimento aplica o método de revisão descrito no Capítulo 2, verificando se todos os critérios de passagem foram atendidos e se eles podem se submeter ao processo de aprovação. Em caso positivo, na segunda atividade da revisão, os responsáveis pelo projeto participam da avaliação e aprovam ou não a fase, permitindo que o projeto continue. Por fim, todas as decisões tomadas durante a realização da fase e durante a revisão, assim como as lições aprendidas, são formalmente documentadas. Figura 3.1

Atividades genéricas das fases do modelo.

Vamos agora descrever cada uma dessas atividades genéricas citadas.

3.2

Atualizar plano da fase

Após a fase de planejamento estratégico de produtos (descrita em detalhes no Capítulo 4), quando se define o portfólio de projetos a serem desenvolvidos, realiza-se individualmente o planejamento de cada um dos projetos de desenvolvimento específico (descrito no Capítulo 5). Esse planejamento do projeto envolve a definição dos principais resultados esperados de cada fase, assim como as atividades principais a serem realizadas para se atingir esses resultados. Além disso, o planejamento com2 preende a determinação do escopo do projeto , dos tempos de duração de cada atividade, da análise de risco etc. Todos esses temas são discutidos no Capítulo 5. Essas informações resultantes são registradas em um documento denominado plano do projeto. No início de cada fase de desenvolvimento, realiza-se essa atividade genérica A atualização sempre de atualização do plano de projeto. Na verdade, ele é atualizado e pode ser também ocorre no início de cada detalhado. Em projetos de grande porte e complexos, o plano inicial não contém fase do desenvolvimento detalhes sobre todas as atividades e prazos relacionados com uma fase específica. Nessa atividade, parte-se dos prazos-limite de início e fim de fase e as atividades mais específicas são detalhadas. As atividades apresentadas no Capítulo 5 são novamente realizadas. Nos casos de projetos de menor porte ou de menor complexidade, essa atividade objetiva revisar o planejado. Destaca-se que, em razão do menor escopo e das definições já existentes, o tempo de detalhamento do plano é bem menor do que aquele necessário à realização do planejamento inicial. É importante que se faça esse detalhamento no início da fase, pois, além de se estar mais próximo dos eventos daquela fase, é possível ajustar o plano com base nos resultados do gate da fase anterior. Durante o desenvolvimento podem existir novas condições que não foram consideradas durante o planejamento inicial, como uma mudança no mercado, avanço tecnológico, limitações de recursos, novas políticas etc. 1 2

Para projetos mais complexos e abrangentes, podem acontecer revisões técnicas intermediárias antes do gate final, que, nesses casos, compreende principalmente as questões gerenciais do projeto. Escopo do projeto define as características do projeto para se obter o produto final. Ele é formalmente definido no Capítulo 4.

CAPÍTULO 3

Atividades Genéricas do Modelo

107

Essas novas condições são apreciadas e também contribuem para o detalhamento, mas principalmente podem ser utilizadas para se atualizar o plano inicial, influenciando inclusive as fases subseqüentes de desenvolvimento. Serão agora simplesmente listadas as tarefas genéricas pertencentes a essa fase. Elas não serão detalhadas, pois equivalem às atividades discutidas no Capítulo 5, exceto a última tarefa de definição e atualização dos critérios de passagem dos gates: n n n n n n n n n n n n n

analisar o plano de projeto atual; analisar e sintetizar as novas condições para a realização do projeto; atualizar o escopo do produto; atualizar e detalhar o escopo do projeto; atualizar e detalhar as atividades, os responsáveis, os prazos e o cronograma; atualizar e detalhar recursos necessários; atualizar estimativa de orçamento do projeto; atualizar, monitorar, valorar e definir novos indicadores de desempenho; analisar a viabilidade econômico-financeira do projeto; avaliar novos riscos; atualizar plano de comunicação; planejar, atualizar e preparar novas aquisições; e definir/atualizar os critérios de passagem dos gates.

Como pode ser visto no Tópico 3.5, a última tarefa da atividade de “Aprovar e Fase” é ajustar os critérios da próxima fase. No planejamento da fase subseqüente esses critérios são confirmados na tarefa de “definir/atualizar os critérios de passagem dos gates”.

3.3

Monitorar viabilidade econômico-financeira

Como visto na descrição da atividade genérica anterior, a atualização e o detalhamento do plano do projeto para uma fase específica incluem a atualização do estudo de viabilidade econômico-financeira (realizado na fase de planejamento do projeto), para garantir que as premissas e os indicadores iniciais estão sendo mantidos. O estudo da viabilidade econômico-financeira do produto já nasce durante a Primeira versão da definição do portfólio, na fase de planejamento estratégico de produtos (Capítulo viabilidade 4). Durante o planejamento do projeto (Capítulo 5), é realizada uma atividade de econômico-financeira análise da viabilidade econômico-financeira do projeto, na qual são definidos os surge durante a definição principais indicadores financeiros do projeto relacionados com o produto final, tais do portfólio como: retorno do investimento, valor presente líquido e taxa interna de retorno (veja o Quadro 5.14, no Capítulo 5, sobre a análise econômico-financeira). Existem outros indicadores financeiros do projeto, que são operacionais e relacionam-se com o orçamento previsto (budget) versus gastos, e que, em última análise, influenciam no fluxo de caixa do projeto — podendo aí, sim, modificar os indicadores anteriormente citados. No momento da análise inicial da viabilidade econômico-financeira, pode ter sido definido um custo-alvo do produto (veja o Quadro 5.12, no Capítulo 5, sobre custo-alvo e gestão de custos), cujo monitoramento fornece subsídios para se atualizar a lucratividade esperada do produto no mercado (veja o Quadro 5.14, no Capítulo 5, sobre a análise econômico-financeira). A análise realizada durante o planejamento do projeto é a referência inicial As incertezas do início, para as demais fases do projeto. É com base nela que se toma a decisão de se desenrefletidas no primeiro volver o produto (não é o único critério, mas um dos mais importantes). No enestudo de viabilidade, tanto, esse referencial é adotado em um momento no qual existem ainda várias diminuem e precisamos incertezas (veja o Tópico 2.5.1 sobre as características das fases de desenvolvimento atualizar esse estudo de produtos). Durante o desenvolvimento, quando as especificações do produto são detalhadas, pode-se ter uma certeza maior do custo, das características técnicas, e, portanto, do preço/volume.

108

PARTE 2

O Modelo

Além disso, o mercado previsto inicialmente pode mudar. Nesse período, deve-se monitorar os indicadores econômicos do projeto, pois uma mudança para pior pode inviabilizar o retorno financeiro do projeto e a empresa deve avaliar se ele pode ter continuidade ou não. Lógico que uma mudança para melhor sempre é bem-vinda. O ideal é realizar um monitoramento constante, sempre atento às condições 3 O ideal é monitorar do mercado. Por essa razão é que sempre deve existir, no time de desenvolvimento, constantemente a alguém da área financeira, ou, no mínimo, a área financeira deve fornecer ferraviabilidade mentas eficazes para que esse monitoramento seja realizado. Pode ser que alguma econômico-financeira do mudança significativa realmente necessite de um estudo de viabilidade mais formaliprojeto/produto... zado antes de se atingir o final da fase, ou seja, qualquer grande decisão deve vir acompanhada de um estudo para ver se as premissas iniciais estão sendo mantidas ou não. A Figura 3.2 apresenta uma visão geral das tarefas dessa atividade. Figura 3.2

Tarefas da atividade genérica de monitorar a viabilidade econômico-financeira.

4

A atividade de monitoramento formal acontece ao final de cada fase de desen...mas o monitoramento volvimento. É um momento em que os resultados são consolidados e uma nova formal ocorre no final versão do estudo de viabilidade econômico-financeira é documentada. Essa nova verda fase são compreende: premissas (juros, custo de atratividade etc.), custo-alvo, preço/volumes previstos no tempo, novo fluxo de caixa e os novos indicadores (veja o Quadro 5.14, no Capítulo 5, sobre análise econômico-financeira do projeto). Além disso, se necessário, deve-se justificar os desvios do estudo atual com relação ao inicial e os possíveis impactos. Esse novo estudo é uma das informações analisadas durante a revisão de fase (gate), que também são atividades genéricas do modelo — as quais serão apresentadas nos próximos tópicos. 3

4

As condições de mercado podem envolver mudanças nas políticas e nas condições macro e microeconômicas da região em que se produz e que consumiria o produto, como: novas políticas de juros e poder aquisitivo do mercado-alvo; entrada de novos concorrentes ou mesmo o lançamento de novos produtos pelos concorrentes existentes; novos avanços tecnológicos que impactam o produto em desenvolvimento; e outros. O monitoramento contínuo também é formal, mas, no final da fase, ele é documentado de uma maneira tal que pode ser utilizado na revisão da fase.

CAPÍTULO 3

Atividades Genéricas do Modelo

3.4

109

Avaliar fase

Os conceitos principais sobre o processo de revisão de fases foram apresentados no Tópico 2.7, no qual foram comentados os critérios a serem verificados no gate, o time de avaliação, o processo de gate e sua adaptação. Conforme discutido, o processo de gate é dividido em duas atividades: a deste tópico do livro, na qual o próprio time de desenvolvimento realiza uma auto-avaliação, e uma outra na qual a decisão de continuidade do projeto é tomada pelo time de avaliação (veja o Tópico 3.5, a seguir). A Figura 3.3 apresenta uma visão geral das tarefas dessa atividade. Figura 3.3

Tarefas da atividade genérica de avaliar fase.

Nessa atividade, o time de desenvolvimento realiza uma auto-avaliação, para ver se o projeto pode ser submetido ao gate, coordenado pelo time de avaliação (atividade de aprovação da fase). São avaliados o cumprimento das atividades e os seus resultados. A qualidade dos resultados é analisada, e os critérios qualitativos e quantitativos são verificados, assim como a análise da viabilidade econômico-financeira. Se surgir algum problema nessas avaliações, o próprio time de desenvolvimento pode decidir implementar ações corretivas, antes de submeter a fase ao crivo do time de avaliação. Caso eles considerem que os resultados foram satisfatórios e os critérios atendidos, eles marcam a reunião de avaliação. É comum que se realize um relatório da auto-avaliação para facilitar o trabalho do time de avaliação. No entanto, deve-se tomar o cuidado de não acreditar somente nesse relatório, pois o time pode estar “escondendo” os problemas. Por isso é que a existência de critérios bem definidos é essencial para o sucesso da reunião de avaliação. Algumas empresas definem ainda um time assessor para essa atividade, que Pode existir também um contém pessoas da empresa com conhecimentos tecnológicos do produto sendo detime assessor para senvolvido e ao mesmo tempo uma visão crítica do portfólio de produtos. Esse time colaborar no processo não pode conter pessoas do time de desenvolvimento. É comum que sejam convide revisão dados para esse time membros de fora da empresa. O papel desse time é auxiliar o time de desenvolvimento na preparação para o gate com o time de avaliação e, ao mesmo tempo, auxiliar esse time a tomar a decisão na atividade subseqüente, pois, muitas vezes, os membros do time de avaliação não possuem conhecimentos técnicos nem tempo para entrar nos detalhes, que talvez sejam necessários, para aprovar a fase. Pode parecer que a existência desse time acrescente burocracia ao processo e só

110

PARTE 2

O Modelo

pode existir em empresas muito grandes. No entanto, ele pode ser constituído de somente uma pessoa interna já iniciada na gestão por gates, ou mesmo por um consultor externo cumprindo o papel mostrado. As tarefas dessa atividade também são genéricas e devem considerar os critéCritérios para a revisão rios específicos de cada área, que devem ser definidos a priori e atualizados a cada estão nos tópicos atividade de detalhamento do plano do projeto (veja o Tópico 2.7). Normalmente, específicos relacionados um modelo de referência, como o deste livro, apresenta alguns critérios que servem com cada fase de base para a definição dos critérios específicos para cada projeto. Dessa forma, ao final de cada fase, quando essas atividades genéricas forem realizadas, são apresentados neste livro os critérios pertinentes à fase em questão. Vimos que, no final da fase, há as atividades de avaliação e aprovação da fase, os Revisões técnicas antes do gates. No entanto, existem projetos grandes e complexos que necessitam de gates infinal da fase termediários. Normalmente, esses gates intermediários tratam apenas de questões técnicas, e lógico que o monitoramento do estudo de avaliação econômica pode ser revisto, uma vez que a revisão é contínua. Esses gates podem ser definidos no modelo de referência específico da empresa. No modelo apresentado, estaremos apresentando gates somente nos finais da fase. A fase de projeto detalhado, por exemplo, é uma fase que contém ciclos de detalhamento e otimização e, ao final de um ciclo, pode ser realizado um gate técnico. No final de um primeiro ciclo de detalhamento e otimização dentro da fase de projeto detalhado, existem informações mais detalhadas do que na fase de projeto conceitual, mas não se tem certeza ainda se o projeto deve continuar ou não. Nesse momento, é possível realizar um gate para aprovar a continuidade da fase de projeto detalhado. Esse gate é técnico e também envolve a atualização do estudo de viabilidade para que se decida se o projeto deve continuar ou não. Alguns autores chamam esse primeiro ciclo de detalhamento de projeto preliminar (veja o Quadro 8.3 sobre projeto preliminar entre o projeto conceitual e detalhado).

3.5

Aprovar fase

Nesta atividade, diferentemente da anterior, o objetivo da avaliação é mais amplo, pois, aqui, o portfólio de projetos também é analisado. Não é o time de desenvolvimento que coordena a realização desta fase, mas, sim, o time de avaliação (veja o Tópico 2.3 sobre os papéis principais das pessoas envolvidas no PDP). Nesta atividade é tomada a decisão de aprovação ou não da fase e, por conseqüência, do projeto — motivos do porquê definir esta atividade separadamente da anterior. A Figura 3.4 mostra as tarefas desta atividade. O time de avaliação, com uma visão do portfólio de projetos, analisa o resultado da auto-avaliação da fase anterior realizada pelo time de desenvolvimento, verificando a situação do presente projeto perante o portfólio de produtos e projetos existentes, ou seja, avaliando se ele ainda é prioritário perante as demais alternativas. Aprecia o estudo de viabilidade econômico-financeira, e, finalmente, toma a decisão, que pode ser de quatro tipos: n

n

n

Cancelar o projeto: quando o projeto não cumpriu as atividades programadas, ou os resultados não são satisfatórios, ou, ainda, perante o portfólio, esse projeto não é mais atrativo, e não existe forma de recuperação. Não é fácil cancelar um projeto, principalmente por problemas culturais, mas deve ser feito quando necessário. Congelar o projeto: em razão das outras prioridades no portfólio, o projeto é congelado para ser continuado em um outro momento. A continuação pode estar condicionada a um plano de ação ou não. Redirecionar o projeto: alguns dos resultados não foram satisfatórios, mas uma recuperação é possível, e um plano de ação é preparado para ser realizado em paralelo com o desenvolvimento da próxima fase. Pode-se, então, realizar uma avaliação posterior dos resultados do plano de ação ou pode-se incorporar essa avaliação no próximo gate.

CAPÍTULO 3

Atividades Genéricas do Modelo

Figura 3.4

n

111

Tarefas da atividade genérica de aprovar fase.

Aprovar a fase: nesse caso, a próxima fase é iniciada e os resultados do gate são documentados, registrando as lições aprendidas (Tópico 3.6), quando for o caso, para uma utilização posterior, a fim de evitar que os mesmos problemas ocorram no futuro.

Após a tomada de decisão, é preparado um relatório sobre a avaliação e aproTarefas para depois vação; os planos de correção são definidos; pode-se realizar uma análise de riscos, da decisão caso exista a possibilidade desses planos não eliminarem as causas da reprovação; o processo de revisão e os critérios utilizados são apreciados; e os critérios para a próxima fase são ajustados. A definição desses critérios baseia-se nos padrões existentes no modelo de referência, mas salienta-se que é na atividade de detalhamento do plano, no início de cada fase, que esses critérios são completamente definidos e aprovados. O time assessor, descrito na atividade anterior, pode auxiliar o time de avaliaTime assessor também ção, o qual normalmente possui pessoas do alto escalão da empresa e sem tempo pode ajudar o time para se envolver com os detalhes do projeto, principalmente se a empresa estiver dede avaliação senvolvendo muitos projetos ao mesmo tempo. Mas isso ocorre somente se ele existir, pois ele não é imprescindível à realização do processo de gate. Apesar de estarmos falando que uma fase precisa ser aprovada para darmos Antes do gate pode-se continuidade ao projeto, podem existir casos em que algumas atividades da próxima realizar atividades de outra fase já sejam adiantadas antes do gate. Essa superposição de fases contribui para difase para acelerar o minuir o tempo de desenvolvimento do produto. Caso a fase anterior seja reprovada desenvolvimento e o projeto congelado ou cancelado, os recursos investidos no adiantamento da fase seguinte serão perdidos. Na maior parte dos casos, todavia, essa prática diminui o tempo de desenvolvimento. A decisão de adiantar atividades de uma outra fase é tomada com base na expectativa compartilhada de aprovação, com anuência dos tomadores de decisão. Mas, mesmo assim, não deixa de ser um risco calculado, pois pode ocorrer que a fase seja reprovada e o projeto cancelado ou congelado.

Critérios Assim como descrito na atividade genérica anterior, os tópicos deste livro relacionados com o processo de revisão para cada uma das fases apresentam nos locais correspondentes os critérios específicos genéricos, que devem ser tomados como referência na definição de critérios específicos. Tanto na atividade anterior de avalia-

112

PARTE 2

O Modelo

ção como nesta utilizam-se os mesmos critérios, pois a diferença está na análise do portfólio e na existência do time de avaliação.

3.6

Documentar as decisões tomadas e registrar lições aprendidas

Ao longo de todo o processo de desenvolvimento de um projeto são realizadas atividades relacionadas à melhoria do processo de desenvolvimento de produtos, e as lições aprendidas durante esse processo são fontes importantes de informações para a realização das melhorias. A captura das lições aprendidas não pode ser uma atividade informal e não estruturada, pois é preciso garantir que a análise crítica do que se realizou durante o desenvolvimento de um projeto seja sempre feita. Isso garante mais transparência e facilita a gestão das ações de melhoria desdobradas a partir dessas lições. Quando não existe a atividade de registro das lições aprendidas sistematizada, é comum que quase todos os novos conhecimentos gerados ou aprimorados durante o desenvolvimento do projeto seja perdido ou esquecido, principalmente em razão da dinâmica do fluxo de projetos de desenvolvimento que exige esforços contínuos das equipes de desenvolvimento. Por outro lado, a realização de uma atividade dedicada à captura e registro de lições aprendidas, apesar de requerer mais tempo dos profissionais, pode resultar em benefícios em termos de tempo e qualidade muito significativos — principalmente em outros projetos. A atividade “Registrar lições aprendidas” é uma atividade simples em termos de sistematização, porém complexa em relação às análises necessárias. Para sua realização, uma equipe deve fazer uma análise normalmente estratificada por tópicos, tais como: aspectos técnicos do produto, aspectos técnicos do processo de produção, aspectos relacionados à gestão do processo de desenvolvimento e à gestão do projeto (estão incluídos aqui aspectos relacionados a fornecedores, clientes, protótipos, capacitação de pessoal, liderança, estratégias tanto de mercado quanto tecnológica). Essa análise resulta em registros que devem ser recuperados a qualquer tempo pelas equipes de desenvolvimento, visando a captura de conhecimentos úteis para a realização de atividades ao longo do projeto ou para a realização de melhorias no PDP. A atividade genérica de registro de melhorias e melhores práticas, que acontece no final de cada fase, trata com detalhes a captura das lições aprendidas ao longo de todo o desenvolvimento. A qualquer momento, durante o desenvolvimento, podem ser tomadas decisões e existem lições aprendidas que podem ser registradas, para evitar que, no futuro, se incorram em erros semelhantes aos ocorridos no passado. A empresa deve prover uma infra-estrutura que permita essa documentação. Além disso, os membros do time de 5 desenvolvimento devem estar capacitados para registrá-los e acessá-los durante a realização de suas tarefas. Essa atividade genérica formaliza o momento da documentação. Em algumas Deve-se registrar a todo o empresas, existe a prática de se exigir que os membros do time de desenvolvimento momento experiências escrevam um relato de uma página sobre as lições aprendidas para que elas fiquem adquiridas, mas existe um registradas. momento formal para No caso do modelo, define-se a realização dessa atividade logo após o gate, mas garantir a sua documentação pode-se exigir que um dos critérios para a aprovação da fase seja a evidência de existência da documentação das decisões tomadas e lições aprendidas. Ou seja, o registro desses conhecimentos ocorreria dentro do próprio processo de gate. As decisões e discussões que acontecem no gate também contêm conhecimentos explícitos e também devem ser registradas, de forma a serem recuperadas, quando necessário. Não existe um conjunto de tarefas específicas para a realização dessa atividade. Conforme o grau de formalismo da empresa, deve-se classificar essas informações e mesmo associá-las aos objetos do projeto/produto, a fim de facilitar a sua recuperação e reutilização no futuro. Essa prática dificulta um pouco o processo de inserção desses conhecimentos, pois exige que um membro do time insira essas informações adicionais às lições apren5

Existem hoje soluções computacionais baseadas em agentes, que analisam automaticamente os documentos armazenados, os relatos que os projetistas criam, ou outras informações coletadas durante o desenvolvimento, ou mesmo nos gates. Dessa análise resulta uma classificação de todo esse conteúdo, facilitando a sua recuperação posteriormente para reutilização daquele conhecimento registrado.

CAPÍTULO 3

Atividades Genéricas do Modelo

113

didas. Hoje existem alguns sistemas que analisam os textos e automaticamente o classificam, eliminando, assim, a necessidade de inclusão dessas informações adicionais. Porém, a existência de sistemas e procedimentos só ajuda, porque o mais importante é promover a cultura dessa prática dentro da empresa. Isso pode ser obtido se houver a promoção consistente da Gestão do Conheci6 mento (veja o Tópico 2.12 sobre gestão do conhecimento). Ou seja, o mais importante é fazer com que os membros do time estejam conscientes da necessidade da documentação, e também treinados para realizá-la da forma mais eficaz.

3.7

Questões e atividades didáticas propostas

Questões para reflexão 1. Qual o significado de uma atividade genérica? 2. Por que devemos atualizar o plano de projeto no início de cada fase do desenvolvimento? 3. Qual a razão de monitorar constantemente a viabilidade econômico-financeira do projeto e por que existe essa atividade genérica formal? 4. Discuta os indicadores que são avaliados na atividade de monitoramento da viabilidade econômico-financeira. 5. Qual a razão de separar a avaliação da fase em duas atividades? Qual o papel de cada uma dessas atividades? Como se deve proceder em uma empresa pequena? 6. Por que o time de desenvolvimento realiza uma auto-avaliação antes de se submeter à aprovação da fase? 7. Qual seria o papel de um time assessor para colaborar no processo de revisão de fase? 8. Quando é que se divide o gate em revisão técnica antes da gerencial realizada durante a fase de desenvolvimento? 9. Liste e explique cada uma das possíveis tomadas de decisão em um gate. 10. O gate é um divisor entre fases. A partir dele uma outra fase se inicia. Quando é que são desenvolvidas atividades das fases subseqüentes mesmo antes da finalização e aprovação da fase anterior? Cite exemplos. 11. Qual a importância da atividade genérica de documentar as decisões tomadas e registrar lições aprendidas? 12. Por que a atividade de registrar as lições aprendidas não pode ser uma atividade informal? 13. Qual a maior dificuldade em garantir a qualidade de registro das lições aprendidas?

Atividades didáticas 1. Simule com os colegas o início de uma fase. Selecione qualquer uma das fases de desenvolvimento. Recupere um plano de projeto, monte um cenário de mudança e sinta como seria atualizar esse plano. 2. Entreviste gerentes de desenvolvimento de produtos visando levantar as características de alteração de planos de projeto no meio de um projeto. 3. Recupere um estudo de viabilidade econômico-financeira de um projeto e simule a sua atualização no caso de uma queda do volume de vendas previsto. Reutilize o modelo criado em uma planilha. 4. Modifique outras premissas do estudo de viabilidade econômico-financeira inicial e veja o resultado. 5. Selecione algumas das variações realizadas nas duas questões anteriores e escreva um relatório de análise do novo estudo para ser tomado como referência durante o gate da fase. 6

Gestão do conhecimento envolve a definição de políticas, disseminação de cultura, organização para a gestão do conhecimento, treinamento, motivação e também o oferecimento de sistemas de informação para apoiar essa prática. Esses sistemas são conhecidos como portais corporativos para gestão do conhecimento (TERRA, 2000).

114

PARTE 2

O Modelo

6. Simule a auto-avaliação e a aprovação de fase com os seus colegas. Defina um conjunto de critérios de passagem, com base nos critérios fornecidos no final da cada capítulo que descreve uma fase. Acrescente novos critérios. Imagine um cenário e siga passo a passo as recomendações da atividade de avaliar a fase. 7. Realize novamente a atividade anterior, considerando, agora, o relatório recebido do monitoramento da viabilidade econômico-financeira. Compare as duas auto-avaliações. 8. Discuta com os seus colegas como vocês fariam para monitorar os indicadores não-financeiros do projeto durante o gate. 9. Simule o final de uma fase e tente escrever e registrar uma lição aprendida. Reúna as lições escritas pelos colegas e defina um padrão de formulário e uma forma padronizada de armazená-las. Após isso, critique as decisões tomadas e veja como isso poderia ser melhorado. 10. Tente buscar exemplos de empresas que praticam o registro de lições aprendidas (use para isso a Internet, publicações, informações adicionais ou contatos já existentes).

3.8

Informações adicionais

COOPER, R. G.; EDGETT, S. J.; KLEINSCHMIDT, E. J. Portfolio management for new products. United States of America: Perseus Books, 1998. p. 230. Disponível em: . Acesso em: 21 fev. 2005. PMI (Project Management Institute). “PMBOK — A Guide to the Project Management Body of Knowledge.” USA, 2000. TERRA, J. C. C. Gestão do conhecimento e e-learning na prática. São Paulo: Negócio Editora, 2003. p. 363. TERRA, J. C. C. Gestão do conhecimento: o grande desafio empresarial — uma abordagem baseada no aprendizado e na criatividade. São Paulo: Negócio Editora, 2000. p. 283. TERRA, J. C. C.; GORDON, C. Portais corporativos: a revolução na gestão do conhecimento. São Paulo: Negócio Editora, 2002. p. 453. VALERI, S. G. “Estudo do método de aprovação de fases no processo de desenvolvimento de produtos em uma indústria automobilística.” Dissertação (Mestrado) — Escola de Engenharia de São Carlos, Universidade de São Paulo, 2001. VALERI, S. G.; ROZENFELD, H. “Improving the flexibility of new product development (NPD) through a new quality gate approach.” Journal of Integrated Design and Process Science, USA, v. 8, n. 3, p. 17-36, set. 2004.

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11

Sumário Definir escopo da revisão do PEN Planejar atividades para a revisão do PEN Consolidar informações sobre tecnologia e mercado Revisar o PEN Analisar o portfólio de produtos da empresa Propor mudanças no portfólio de produtos Verificar a viabilidade do portfólio de produtos Decidir o início do planejamento de um dos produtos do portfólio Questões e atividades didáticas Informações adicionais

4. Planejamento Estratégico de Produtos Planejamento Estratégico de Produtos PARTE 2 O Modelo

Depois da leitura deste capítulo, você será capaz de: l

l

l

l

l

l

l

l

l

l

l

Entender a relação entre o Processo de Planejamento Estratégico da empresa e o Plano Estratégico de Produtos. Compreender o significado e a importância do Planejamento Estratégico de Produtos e o Portfólio de Produtos. Identificar a diferença entre produto e tecnologia. Conhecer as diferentes fontes de dados sobre o mercado e tendências tecnológicas. Entender os principais cuidados na coleta de informações sobre mercado e tendências tecnológicas. Descrever quais os objetivos e as metas da gestão de portfólio. Descrever quais as atividades e ferramentas disponíveis para realizar o planejamento estratégico de produtos; isto é, a definição dos projetos de desenvolvimento. Entender a importância da segmentação e posicionamento dos produtos na definição do portfólio de produtos, incluindo as diferentes estratégias possíveis. Listar todo o conteúdo de um Plano Estratégico de Produtos. Dar início ao desenvolvimento de seu primeiro Plano Estratégico de Produtos. Compreender como se dá a passagem entre as fases de Planejamento Estratégico de Produtos e o Planejamento do Projeto por meio da Minuta do Projeto.

4.1

Sumário

O Planejamento Estratégico de Produtos (PEP) é a primeira fase do modelo e inicia a macrofase de pré-desenvolvimento. Conforme apresentado no Capítulo 2 (Tópico 2.4.1), a macrofase de pré-desenvolvimento en-

116

PARTE 2

O Modelo

volve as atividades de definição do projeto de desenvolvimento — realizada a partir da estratégia da empresa —, restrições de recursos e conhecimentos, e informações sobre os consumidores, tendências tecnológicas e mercadológicas, conforme a área em destaque na Figura 4.1, a seguir. Figura 4.1

Localização das fases do pré-desenvolvimento dentro do processo de desenvolvimento de produtos unificado.

A Figura 4.1 ilustra como a macrofase de pré-desenvolvimento do nosso modelo é, portanto, dividida em duas fases: Planejamento Estratégico de Produtos e Planejamento do Projeto. O objetivo do Planejamento Estratégico de Produtos é obter um plano contendo o portfólio de produtos da empresa a partir do Planejamento Estratégico da Unidade de Negócios. Na prática, isso significa uma lista descrevendo a linha de produtos da empresa e os projetos que serão desenvolvidos, de maneira a auxiliá-la a atingir as metas estratégicas de negócio. Para os produtos em comercialização, esse portfólio de produtos deve incluir uma previsão da retirada do mercado. Com relação aos produtos a serem desenvolvidos, é preciso conter uma primeira descrição de suas características e metas para início de desenvolvimento, lançamento e retirada. Esse plano parte da estratégia de negócios, corporativa e/ou da unidade de negócio, e sua adequação a ela é fundamental. Por exemplo, se a estratégia da empresa é competir por meio de diferenciação tecnológica, o portfólio de produtos deve ser planejado de forma que a empresa possua uma linha de produtos mais sofisticada que a de seus concorrentes, isto é, que tenha conteúdo tecnológico maior, funções inovadoras e características que transmitam essa sensação aos consumidores, tais como o design arrojado. Por outro lado, se a estratégia da empresa é atacar o mercado de consumidores de baixa renda, toda a linha de produtos e as tecnologias escolhidas devem, além de atender às necessidades em termos de forma e função, apresentar custos aceitáveis a esses consumidores e considerar as restrições de estilo de vida, como espaço e tipo de moradia. Os principais atores nessa fase são os membros da diretoria e os gerentes funQuem assume o papel mais cionais. Uma prática avançada é formar o que se denomina de Comitê de Aprovação importante nessa fase? de Produtos ou Comitê Gestor do Portfólio de Produtos. Esse comitê torna-se responsável por gerenciar o portfólio de produtos, decidindo quais produtos serão retirados do mercado e quais projetos de desenvolvimento serão realizados. No Modelo Unificado, esse papel é denominado de Time de Planejamento Estratégico de Produtos.

CAPÍTULO 4

Planejamento Estratégico de Produtos

117

Em uma grande empresa multinacional, poderão existir vários desses comitês, espalhados por regiões do mundo e famílias de produtos. Em uma empresa pequena, poderá inexistir um comitê formal, e essa função será tratada dentro das próprias reuniões de diretoria. O que importa, na verdade, é que a responsabilidade por essa decisão seja bem definida e de preferência delegada a uma equipe multifuncional com capacidade de decidir sobre a realização ou não de um produto. Por isso, certamente deverá envolver membros da alta gerência da empresa. Todas as áreas devem acompanhar e dar opiniões sobre a adequação da linha de produtos, melhorando a qualidade das decisões e criando uma visão coerente sobre os objetivos específicos de cada projeto. Esse é um avanço em relação ao passado no qual, muitas vezes, essa decisão As vantagens dos comitês cabia unicamente ao marketing ou ao departamento de engenharia. Nesses casos, muitas vezes informações importantes de outros setores como manufatura e distribuição não eram consideradas nessa decisão, além de dificultar o processo de desdobramento da estratégia por falhas de comunicação e entendimento da visão da empresa pelas áreas funcionais responsáveis por tais escolhas. Sabe-se atualmente que é fundamental analisar a linha de produtos sobre a ótica da estratégia da empresa como um todo, considerando a realidade de todas as áreas da empresa. Ao mesmo tempo, o envolvimento de membros da alta gerência é crucial porque são eles que conhecem profundamente a estratégia de negócios da empresa. Um exemplo para a formação desse comitê seria: um diretor de cada área funcional (manufatura, marketing, logística, qualidade, finanças etc.) e os gerentes das áreas de desenvolvimento de produtos e marketing. No decorrer deste capítulo, adotaremos o nome Time de Planejamento Estratégico de Produtos. O fluxo das atividades da fase de Planejamento Estratégico de Produtos é apresentado na Figura 4.2. A principal informação de entrada é o Planejamento Estratégico de Negócios. Conforme apresentado no Capítulo 3, no caso de grandes corporações, ele pode ser formado por mais de um planejamento: o Planejamento Estratégico da Corporação e o Planejamento Estratégico da Unidade de Negócios. Esse plano, ou conjunto de planos, contém a estratégia da empresa dentro de um horizonte de planejamento, que, em suma, define como a empresa pretende competir e quanto almeja crescer. A saída dessa fase é a definição de um portfólio de produtos e projetos que permitam que a empresa atinja este objetivo. Figura 4.2

Fluxo de atividades da fase de Planejamento Estratégico de Produtos.

118

4.2

PARTE 2

O Modelo

Definir escopo da revisão do PEN

A primeira atividade desta fase é definir o nível de avaliação do Planejamento Estratégico, em que o Time de Planejamento Estratégico de Produtos deverá definir qual o nível de detalhamento e esforço necessários. A Figura 4.3 resume o conteúdo dessa atividade, que parte do Plano Estratégico de Negócios já elaborado. O resultado final será um documento simples, descrevendo o escopo da mudança e os assuntos a serem discutidos. Figura 4.3

Resumo da atividade “Definir o escopo de revisão do PEN”.

Isso é importante em razão do horizonte de planejamento. Em geral, um plano estratégico é revisto de período em período, anual ou semestralmente, mas aborda um horizonte de médio a longo prazos, entre 2 até 10 anos, dependendo do negócio. Pode ser que, de um ano para outro, não ocorram alterações significativas no cenário previsto no período anterior. É o caso quando não surge nenhum concorrente novo, nenhuma tecnologia inovadora e não existam sinais de mudança no comportamento e perfil dos consumidores. Nessa situação, certamente o novo Plano Estratégico conterá pequenas alterações em relação ao plano anterior e, provavelmente, poucas metas mudaram no Planejamento Estratégico da Unidade de Negócios. Conseqüentemente, não há necessidade de grandes estudos ou grandes decisões durante a revisão do novo Plano Estratégico de Produtos. Assim, não faz sentido um grande esforço de revisão, e essa atividade pode ser realizada rapidamente sem envolver maiores recursos e estudos aprofundados. Entretanto, há situações em que ocorrem grandes mudanças no cenário, tais como: fusões dos principais concorrentes, novos concorrentes de peso que não haviam sido previstos, surgimento de uma inovação tecnológica radical não prevista pela empresa ou mesmo uma mudança na sociedade, ocasionando a alteração de um hábito de consumo relacionado com o produto. No extremo da situação inovadora, deve-se contar também com a situação em que a empresa está criando pela primeira vez seu Planejamento Estratégico da Unidade de Negócios: por exemplo, quando ela está entrando pela primeira vez naquele mercado. Nesse caso, a equipe que está realizando o Planejamento de Produtos precisa se familiarizar e estudar criticamente o Planejamento de Negócios recém-elaborado. Ela necessitará de várias rodadas de reuniões, incluindo o apoio de especialistas em assuntos específicos e o levantamento de informações como pesquisas e relatórios. Resumindo, independentemente do grau de mudança, o objetivo dessa atividade inicial é avaliar o nível de análise necessário para que as atividades de planejamento sejam, enfim, planejadas! É o primeiro passo a ser realizado pelo Comitê de Avaliação de Produtos. Geralmente, inicia com o coordenador. Ele distribui cópias do

CAPÍTULO 4

Planejamento Estratégico de Produtos

119

Plano Estratégico de Negócios previamente para que os membros possam se preparar. Em geral, em uma reunião rápida, o time deve: n n n

n n n

analisar o Plano Estratégico de Negócios; definir os assuntos a serem discutidos; avaliar os elementos do Time de Planejamento Estratégico de Produtos, com o intuito de identificar possíveis competências complementares; definir a metodologia de revisão (quais fases, atividades e técnicas a serem utilizadas); definir o prazo final para o término do trabalho; e compilar o documento de declaração de escopo de revisão do PEN.

O coordenador deve estar atento para evitar o início da discussão dos assuntos específicos. Isso é muito comum, e acaba prolongando a reunião desnecessariamente, tornando-a improdutiva. O resultado final é um documento, denominado, em nosso modelo, de Escopo de Revisão do Plano Estratégico, contendo tais informações. Pode ser um documento simples, uma folha de papel, o importante é que se discuta e formalize o que deverá ser feito.

4.3

Planejar atividades para a revisão do PEN

Uma vez definido o escopo de revisão do planejamento estratégico, o Time de Planejamento Estratégico de Produtos poderá iniciar o planejamento das atividades de revisão do Plano Estratégico de Negócios e de preparação do Plano Estratégico de Produtos. Isto é, definição das atividades, prazos e recursos necessários. Essa atividade é sintetizada na Figura 4.4. As entradas são, além do Plano Estratégico de Negócios, a Declaração de Escopo de Revisão, preparada na atividade anterior. Os resultados principais são o cronograma de atividades e as agendas de discussões. Esta atividade pode acontecer na mesma reunião da atividade anterior. Figura 4.4

Resumo da atividade “Planejar atividades para a revisão do PEN”.

Uma prática comum é a utilização de workshops, isto é, reuniões de trabalho na quais os membros do time apresentam estudos específicos, realizam análises, discutem os resultados e tomam decisões. Pode-se fazer uma

120

PARTE 2

O Modelo

agenda com os principais temas que precisam ser discutidos e uma programação para atacá-los um a um. Uma pessoa ou subgrupo deve ser nomeado como redator e ficará com a responsabilidade de documentar os resultados. É comum, também, que esses encontros ocorram fora do ambiente da empreCuidados com o sa, como maneira de livrar os membros do comitê das interrupções rotineiras. A Planejamento da Revisão idéia é manter o grupo concentrado para que os encontros sejam proveitosos. Se as pessoas começam a se dispersar, as discussões se perdem e nenhuma decisão será tomada. Por exemplo, se um membro precisa se ausentar, mesmo que por minutos, quebra-se o ritmo da discussão e todos perdem tempo. Atualmente, só a distância física não é suficiente. Deve-se oferecer orientações específicas quanto ao uso de celulares e laptops com conexão “sem fio”. É comum observar pessoas desrespeitando seus colegas, consultando e-mails, enquanto os demais membros do grupo discutem. Outro aspecto que precisa ser bastante cuidadoso nesse processo é a democratização. Sempre que se formam pequenos grupos, alguns de seus membros acabam tomando naturalmente um papel de liderança, exercendo uma influência mais significativa nas decisões dos grupos. Seja pela legitimidade do cargo, como o presidente ou um grande diretor da empresa, pelo próprio carisma ou por algum domínio técnico especializado e reconhecido por todos. Nesses casos, cabe às pessoas que estão planejando o processo encontrar métodos de trabalho em que todas as pessoas possam expressar livremente suas opiniões. Do contrário, as pessoas se calam e concordam em um primeiro momento. Mas, depois de terminado o processo, questionarão as decisões obtidas e, independentemente da qualidade do resultado final, o plano perderá legitimidade, não sendo seguido. Um entrave à prática de realização de reuniões e workshops para planejamento é a grande mobilização da alta gerência, privando-a de suas atividades normais durante horas ou dias. Na maioria das empresas, isso é muito difícil, tanto por problemas de agenda quanto pelo investimento monetário que isso significa. Mais um motivo para que essa atividade de planejamento seja muito bem executada. Deve-se considerar todas as restrições de tempo e recursos, planejando um processo de discussão proveitoso e útil para a empresa e, ao mesmo tempo, que consuma o menor tempo possível. Se realizada com êxito, ao final dessa atividade, o Time de Planejamento EstraResultados do tégico de Produtos obterá as seguintes informações: lista dos especialistas e consulplanejamento da revisão tores que deverão apoiar o time em assuntos específicos; cronograma de reuniões e eventos (com data, local, participante, agenda e metas a serem cumpridas em cada uma delas) e programação dos recursos necessários em cada uma das atividades. Se realizadas com êxito, as atividades planejadas levarão a uma visão consensual da estratégia de negócios da empresa e do papel da linha de produtos, com o mínimo investimento de tempo e recursos. O planejamento da revisão pode ser realizado concomitantemente à atividade Definição do escopo da anterior. Nesse caso, a primeira reunião do Time de Planejamento Estratégico de revisão e do planejamento Produtos poderia servir para decidir o escopo e realizar o planejamento. Na outra se sobrepõem opção, no caso de ocorrerem separadamente, a definição do escopo é feita pelo time, e o planejamento pode ficar sob a responsabilidade do coordenador, que enviaria uma proposta de atividades e prazos para análise e aprovação pelos demais membros. Esse último caso é o mais recomendado para grandes corporações e atividades de planejamento com escopo maior de revisão. O planejamento deverá consumir muito tempo, e seria um desperdício de recursos manter os executivos desse comitê envolvidos com tal atividade.

4.4

Consolidar informações sobre tecnologia e mercado

Definido o escopo da revisão e, portanto, das alterações necessárias no portfólio de produtos da empresa, é preciso que o Time de Planejamento Estratégico de Produtos se prepare para realizar as atividades posteriores de revisão dos planos e proposição do portfólio de produtos. Todas as decisões referentes ao planejamento estratégico dependem do conhecimento das pessoas em relação ao ambiente, isto é, mudanças nos competidores, concorrentes e as tecnologias que vão sendo desenvolvidas. Portanto, é fundamental que a empresa mantenha-se continuamente atenta às mudanças. Não é possível traçar uma estratégia e definir uma linha de pro-

CAPÍTULO 4

Planejamento Estratégico de Produtos

121

dutos sem que se conheça profundamente o mercado, isto é, quais os competidores e os hábitos e preferências do consumidor, e sem o domínio das características das tecnologias disponíveis e as tendências de inovação futuras. Por isso, o modelo unificado contém a atividade de consolidar as informações sobre tecnologia e mercado, sintetizada na Figura 4.5. As entradas são as informações já compiladas nos planos já traçados, e a saída é um conjunto de dados e informações que as complementam e aprofundam. Na verdade, essa atividade pode ser realizada paralelamente a todas as demais atividades realizadas nessa fase. Figura 4.5

Resumo da atividade “Consolidar informações sobre tecnologia e mercado”.

No início da Revolução Industrial, as mudanças nos produtos eram significatiA importância da vamente mais lentas. Produtos como o Ford T permaneceram em produção duinformação: uma rante dezenas de anos e demoravam vários deles para ser projetados. Além de lentas, vantagem competitiva no as mudanças eram relativamente bem conhecidas por todos os profissionais da indesenvolvimento de dústria. As principais informações vinham da rede de relacionamento dessas pesnovos produtos soas, sendo a experiência e o contato dos profissionais de alto escalão a principal fonte de informações sobre o mercado. Com relação à tecnologia, a principal fonte vinha das bases de patentes, monitoradas pelas empresas. Portanto, no fundo, as empresas assumiam que as ações de busca de informações sobre mercado e tecnologia eram como uma atividade informal e implícita nas funções de marketing e desenvolvimento de produtos. Essa situação mudou radicalmente. Não apenas em razão da velocidade, mas também no que se refere à quantidade de informações, que vem se tornando assustadoramente grande. Tudo isso, aliado ao mercado altamente competitivo, faz do “conhecer precisamente as características dos consumidores” uma importante vantagem competitiva. Na “batalha” com a concorrência, é fundamental distinguir precisamente os produtos em grupos com comportamentos similares (os segmentos de mercado) e definir estratégias específicas para cada segmento-alvo. Na analogia com a guerra de precisão, os “tiros”, no caso os projetos de novos produtos, precisam atingir alvos precisos para evitar o desperdício de munição e aumentar a eficácia, isto é, o sucesso empresarial. Quanto maior o conhecimento sobre os consumidores, maior a probabilidade da empresa atendê-los adequadamente ou melhor que seus concorrentes. Essas informações provêm de diversas fontes, e as empresas com melhores práticas em desenvolvimento de produtos desenvolvem procedimentos sistemáticos para

122

PARTE 2

O Modelo

captá-las. Dividiremos a atividade em três tarefas principais: coletar informações de mercado, coletar informações tecnológicas e gerar cenários e análises. Com relação ao mercado, as pessoas associam tradicionalmente esse processo Tarefa 1: Coletar de busca ao termo pesquisa de mercado. Muitas também associam esse nome à realiinformações sobre o zação de uma pesquisa em si, isto é, a atividade de aplicação de um questionário ou mercado (clientes, realização de uma enquete. A visão mais moderna de pesquisa de mercado, porém, a comconcorrentes e cadeia de preende como a função que integra o consumidor, o cliente e o público aos profissiosuprimentos) 1 nais por meio de informação. Essa definição deixa claro que pesquisar um mercado é mais do que realizar um levantamento de dados específico. Trata-se de coletar e organizar informações de diferentes fontes de dados, isto é, dados obtidos de periódicos especializados do setor, relatórios de agências de serviço de marketing, dados dos sistemas de vendas da empresa, entre outros. Uma classificação dos tipos de fontes de dados pode ser consultada no Quadro 4.1, a seguir. Quadro 4.1

Fontes de Dados para Pesquisa de Mercado

As fontes de dados para pesquisas de mercado podem ser divididas em dois grupos principais: fontes primárias e fontes secundárias. As fontes primárias são aquelas que obtêm dados sob medida para o usuário da informação, conforme as necessidades do projeto — seja ele o desenvolvimento de um produto ou a análise do desempenho da empresa. Um exemplo é uma observação no campo ou uma pesquisa do tipo enquete, projetadas e conduzidas especialmente para responder a certas dúvidas encontradas no decorrer de um processo de planejamento estratégico. As fontes secundárias são aquelas que produziram informações para outros fins, mas que são úteis ao projeto. Exemplos são uma pesquisa publicada em um jornal, dados do censo do Instituto Brasileiro de Geografia e Estatística (IBGE) ou estatísticas computadas a partir do sistema de vendas da empresa. As fontes podem ainda ser classificadas em três grupos cada, conforme apresentado na Figura 4.6. Figura 4.6

Tipos de fontes de dados.

As fontes secundárias de dados podem ser divididas em três tipos: Registros Internos: é formada pelos dados que a empresa produz durante as operações rotineiras, tais como estatísticas de defeitos da assistência técnica, quantidade de vendas, observações dos pontos-de-venda coletadas pelos vendedores, chamadas para o serviço de atendimento ao consumidor (0800) etc. Se bem planejados, fornecem informações significativas com custo pequeno para a organização, na medida em que são obtidos de atividades inevitavelmente realizadas pela empresa. Um exemplo interessante é o de uma pequena empresa de eletrodomésticos brasileira que criou um programa de garantia estendida, grátis para seus clientes, desde que eles preenchessem um cadastro. Com isso, a empresa conseguiu coletar um conjunto significativo de informações valiosas sobre o perfil de seus consumidores.

(continua) 1

Esse é um resumo da definição adotada pela American Marketing Association, cuja íntegra pode ser consultada em AAKER, KUMAR & DAY (2001).

CAPÍTULO 4

Planejamento Estratégico de Produtos

Quadro 4.1

123

Fontes de Dados para Pesquisa de Mercado (continuação)

Dados Publicados e de Uso Comum: trata-se de informações dirigidas ao grande público sobre o setor ou o mercado consumidor. São os jornais e as revistas especializadas tradicionais, seja na mídia impressa, televisiva ou Internet. Pode-se acessar tais informações de duas maneiras. Assinando as principais publicações do setor (as principais revistas etc.), acompanhando e filtrando as notícias — o chamado clipping. Outra maneira é adquirindo os serviços de uma agência de informação. São empresas especializadas, que vendem seus serviços inclusive para os jornais, e que, muitas vezes, possuem canais de informação específicos para diferentes ramos de atividade. Cada canal é uma publicação em tempo real, por televisão ou cada vez mais comumente via Internet, em que as notícias são atualizadas conforme vão sendo produzidas: on time. Outros dados de uso comum são as informações coletadas pelas agências e órgãos governamentais e associações dos diferentes tipos, patronais, comerciais e de trabalhadores. Exemplos de dados de agências governamentais são os produzidos pelo IBGE na área de informações sobre população e território brasileiro e a Fundação Getúlio Vargas e o Instituto Nacional de Pesquisas Econômicas (IPEA) para dados sobre desempenho econômico (inflação, PIB etc.). A Associação Nacional dos Fabricantes de Veículos Automotores (Anfavea) e o Sindicato Nacional da Indústria de Componentes para Veículos Automotores (Sindipeças) são exemplos de associações empresariais atuantes, que reúnem dados importantes sobre esses setores econômicos. Tais dados podem ser obtidos pela compra de publicações ou filiação. Os publicados de uso comum são básicos e, se bem trabalhados, podem auxiliar imensamente no planejamento de produtos ou o planejamento estratégico. Dados Padronizados de Marketing: nesta categoria incluem-se dados produzidos por empresas da área de informação e de marketing, voltados exclusivamente para avaliação do mercado. São produzidos por empresas que visam o lucro com a comercialização dessa informação, vendendo-a para as empresas que atuam no setor. Exemplos desse tipo de material são os painéis setoriais comercializados pela Gazeta Mercantil. Cada um deles voltado para determinado setor e contendo dados como dimensão do mercado brasileiro, divisão entre os principais concorrentes e tendências. Outro exemplo famoso está na área de informática, são os relatórios do Gartner Group. Um exemplo bem conhecido no Brasil é a pesquisa de medição de audiência televisiva do Ibope. Esse produto é resultado da introdução de aparelhos em uma amostra de lares de diversas cidades. As empresas que compram esse serviço (agências de propaganda e emissoras) recebem um aparelho em que podem acompanhar instantaneamente o índice de audiência dos programas da TV aberta. Há painéis similares para medição de rádio e Internet. A empresa Nielsen de pesquisa de mercado comercializa nos Estados Unidos diversos serviços desse tipo, tais como: painéis de auditoria de lojas, painel de consumo doméstico, entre outros. As informações obtidas por esses tipos de pesquisa são bem mais detalhadas e profundas que os dados de uso geral, porém, o valor para a sua aquisição costuma ser expressivo, muitas vezes mais caro que a assinatura de revistas e serviços de informação. Os dados secundários são a principal fonte para se responder a questões como dimensionamento do mercado e participação da empresa e seus concorrentes. Eles podem também indicar problemas ou mudanças de comportamento, identificando a necessidade de busca por dados primários. Além disso, os dados secundários de registros internos podem oferecer boas informações sobre necessidades dos clientes sem precisar de altos investimentos. Outra vantagem dos dados secundários é que eles oferecem informações ricas para o planejamento e coleta adequada e racional de dados primários, que podem ser divididos em: Pesquisas Qualitativas: são pesquisas que empregam métodos capazes de analisar informações abstratas como conceitos e percepções dos consumidores. Os tipos de pesquisa qualitativa são as seguintes: 1. Observação Direta: trata-se do tipo mais simples de pesquisa qualitativa. O pesquisador sai a campo e observa diretamente o consumidor, utilizando ou comprando o produto. No desenvolvimento de equipamentos e máquinas agrícolas para se beneficiar mexilhão, por exemplo, a equipe de projeto pode acompanhar um grupo de maricultores em ação, observando-os limpar as cascas e classificar os animais. Em projetos de caminhões, tratores e equipamentos diversos, esse é um meio bastante eficaz de entender as necessidades dos clientes, inclusive de identificar comportamentos como usos peculiares de ferramentas e questões de manutenabilidade — alguns deles culturais e específicos da população. Outro uso importante é no projeto de embalagens como forma de determinar quais preferências e parâmetros são utilizados pelo consumidor. Um exemplo desse tipo de pesquisa é a escolha do tipo de embalagens de iogurte. Existem vários tipos: plástico, tetra pak, em diferentes volumes. O pesquisador se posiciona no supermercado, próximo à estante desse produto, e observa os consumidores durante a escolha. Ao final, como forma de melhorar essas impressões, ele pode inclusive abordar o consumidor e pedir para que justifique sua escolha. Trata-se de um método limitado em termos de generalização dos resultados, pois não é possível realizar muitos casos de observação dada a restrição de tempo. 2. Entrevistas Individuais em Profundidade (Entrevista): o segundo tipo de pesquisa qualitativa é a que utiliza o método da entrevista. Nesse caso, um entrevistador aborda o consumidor e faz um conjunto de perguntas, anotando cuidadosamente os resultados. São perguntas abertas ou que buscam percepções ou explicações para um conjunto de respostas fechadas. É o caso, por exemplo, de pesquisas para verificar a aceitação de produtos como perfumes ou alimentos. O entrevistador pode mostrar o produto e colher dos consumidores não apenas a informação se ele compraria ou não, mas, também, explicações do porquê ou impressões sobre o produto. Nesses casos, isso é fundamental para verificar se a essência

(continua)

124

PARTE 2

Quadro 4.1

O Modelo

Fontes de Dados para Pesquisa de Mercado (continuação)

ou o sabor despertam o interesse planejado no início do projeto. É um tipo de pesquisa que exige um entrevistador bem preparado, capaz de abordar o cliente adequadamente, conduzir a conversa e realizar anotações precisas. A compilação dos dados também é demorada. O instrumento de coleta é chamado de Roteiro de Entrevista. 3. Clínicas (Focus Groups): é o tipo de pesquisa na qual se seleciona um grupo de consumidores e realiza-se, em ambiente controlado, uma dinâmica de grupo em que os clientes são estimulados a reagir diante dos produtos e são avaliados seus comportamentos, comentários e sugestões. Os grupos variam de 5 a 9 pessoas e podem conter diferentes dinâmicas. Por exemplo, uma empresa que produz cadeiras pode verificar em uma pesquisa prévia que os clientes querem algo moderno. Mas, o que é moderno para o seu mercado consumidor? Uma clínica pode ser projetada de forma a colocar os consumidores em um ambiente contendo fotos ou modelos de cadeiras prévia e intencionalmente escolhidos, contendo combinações propositais de diferentes tipos de materiais, cores e formas básicas. Esse grupo discutiria quais são as mais “modernas”, e os projetistas poderiam avaliar quais características estão associadas à modernidade. Pode ser que as cadeiras em que predominava o uso de aço inoxidável, plásticos transparentes e formas orgânicas (indefinidas, com esferas e fluidez) poderiam ser as de preferência dos clientes durante a dinâmica, com comentários cheios de referências a essas características. As clínicas são muito utilizadas na indústria automobilística para se validar e aprimorar o design. Pode ser utilizado também para avaliar a mensagem do produto, a “usabilidade”, a dificuldade de montagem e outras questões desse tipo. Trata-se de um tipo de pesquisa mais complexa, pois exige profissionais especializados para a definição da dinâmica, escolha de um grupo de consumidores representativo, um ótimo facilitador para conduzir a dinâmica e profissionais experientes para analisar o resultado e discuti-los com a equipe de planejadores ou projetistas. Pesquisa Quantitativa (Enquetes): considera-se como pesquisa quantitativa de dados primários a pesquisa por meio de enquetes. Como o nome diz, trata-se de desenvolver um questionário com perguntas objetivas (utilizando números ou múltiplas escolhas) que podem ser respondidas pelo próprio consumidor ou com a ajuda de um entrevistador. O questionário pode ser aplicado por correio (o formulário é enviado e recebido por carta), por telefone, fax ou mensagem eletrônica. Como se trata de dados objetivos, a enquete é mais fácil de ser respondida, a entrevista dura um tempo menor que a entrevista em profundidade e exige menor capacitação do entrevistador, nos casos em que é necessária sua presença — como nas enquetes por telefone. Assim, ela é viável de ser aplicada a amostras de tamanho grande e, portanto, é recomendada nos casos em que se busca uma informação precisa e deseja-se uma precisão na generalização dos resultados para a população como um todo. Em um projeto de produto poderia ser utilizado, por exemplo, para entender o grau de prioridade dos clientes diante de um conjunto de atributos previamente listados em uma pesquisa de caráter qualitativo. Pode ser utilizada também para descobrir co-relações entre diferentes aspectos de consumo. Por exemplo, um questionário contendo idade e preferência de cor coletadas dos clientes poderia indicar uma co-relação entre as cores mais modernas (diferentes do tradicional) e menor idade. Isso é uma indicação de que, para esse produto, os clientes mais idosos preferem cores mais tradicionais. Essa informação pode ser valiosa no momento da escolha de opções de cores para produtos posicionados para as diferentes faixas etárias. Existem métodos de análise estatística bastante eficientes, capazes de detectar padrões de correlação não esperados, e esse tipo de informação é fundamental para atividades como a segmentação de mercado. Sua limitação é quanto aos aspectos qualitativos, como impressões e explicações, que não podem ser obtidos por meio de perguntas objetivas. Experimentos Controlados: os experimentos são um método de pesquisa no qual se constrói uma situação ou ambiente com variáveis controladas para testar uma ou mais hipóteses. Um exemplo é o teste de sabores, realizado amplamente nas empresas do ramo alimentício. Uma informação de mercado importante é saber, por exemplo, se o cliente consegue diferenciar o sabor de uma marca de cerveja da outra. Para verificar essa informação, monta-se um experimento em que os consumidores são desafiados a provar as diferentes bebidas, sem a identificação, e responder qual delas é a marca líder. Isso pode acontecer em supermercados, feiras e outros locais freqüentados por consumidores representativos do mercado e normalmente envolve algum tipo de brinde para incentivá-los a participar do teste. Aos olhos do cliente, isso pode ser feito de maneira a parecer uma brincadeira ou promoção, aliando o teste a uma iniciativa promocional. É comum utilizar experimentos para saber ainda: quais atributos de um produto alimentício (sal ou açúcar, por exemplo) estão correlacionados com o sabor, qual a melhor cor de um pão ou massa e assim por diante. Experimentos podem ser conduzidos também para avaliar atributos de embalagens e mesmo a aceitação de comerciais de TV. Existem várias técnicas estatísticas, na área chamada de Planejamento de Experimentos, que visam obter o maior número possível de inferências com a menor quantidade de rodadas de experimentos. Elas são intensamente utilizadas nesse tipo de pesquisa. Uma boa pesquisa de mercado é a compilação rigorosa e adequada de dados provenientes das diversas fontes. Com relação ao processo de desenvolvimento de produtos, ela pode ser utilizada para gerar informações sobre o mercado e dar subsídios às decisões das fases de Planejamento Estratégico da Corporação ou de produtos. Mais tarde, veremos que esses mesmos instrumentos podem ser utilizados na fase de projeto informacional para que a equipe de projetistas de uma oferta de produto em si possa descrever as necessidades específicas dos clientes quanto àquele produto. O resultado final, representado pela figura de base de dados no centro da Figura 4.1, é um conjunto de dados, observações e afirmações sobre o mercado da empresa ou sobre as necessidades dos clientes relacionadas a um produto específico. Fonte: AAKER, D.; KUMAR, V.; DAY, G. S. Pesquisa de marketing. São Paulo: Atlas, 2001.

CAPÍTULO 4

Planejamento Estratégico de Produtos

125

Uma observação importante sobre a pesquisa de mercado diz respeito à sua Limitações da pesquisa utilidade. É comum encontrarmos duas afirmações: a de que pesquisa de mercado é de mercado “cara” ou que, para produtos muito inovadores, ela não funciona. Ambas são incorretas se considerarmos o conceito apresentado anteriormente. De fato, realizar um painel de consumidores, uma enquete ampla, comprar o relatório de painel de consumo direto (como a audiência de TVs do Ibope) ou realizar uma clínica envolve um investimento considerável à medida que são formas de coletas de dados que exigem esforços de profissionais especializados e gastos elevados de ações no campo. O Quadro 4.1 demonstra claramente que essas não são as únicas formas de coleta de dados. Pode-se obter boas informações sobre os clientes e mercado utilizando fontes secundárias mais simples. Por exemplo, aprimorando os procedimentos de trabalho da assistência técnica e da área de vendas, com um investimento irrisório na maioria dos casos. Os sistemas CRM2 disponíveis vêm facilitando cada vez mais a reunião e síntese desses dados, de uma forma muito prática e de fácil consulta. Segundo a definição apresentada, isso é também pesquisa de mercado, na medida em que se estrutura um sistema de informações para monitorá-lo. Aliás, as fontes de dados mais caras e sofisticadas precisam ser utilizadas com cuidado e precisão. Somente quando a pesquisa é bem planejada e quando seus objetivos são realmente relevantes para o planejamento de produtos é que as informações obtidas valerão cada centavo do investimento. Com relação ao problema da inovação, a argumentação se baseia em uma afirmação correta: se o produto é inovador, os clientes não possuem paradigmas ou experiências de consumo anterior. O problema é com a conclusão: portanto, não podemos “perguntar” a ele o que ele quer, Certo? Errado, porque, se a pesquisa é bem planejada, especialmente no que diz respeito ao método de coleta de dados e aos instrumentos da pesquisa, essa dificuldade pode ser contornada. Nesses casos, o caminho não é desenhar pesquisas para perguntar o que o cliente quer, e sim verificar os hábitos do cliente em relação à necessidade fundamental. Independentemente do paradigma dos produtos atuais, os hábitos e as necessidades básicas são sempre possíveis de ser verificados. Por exemplo, quando a Sony lançou o walkman, não existia produto similar. Um exemplo das reais Porém, a necessidade básica de ouvir música em diferentes lugares já existia. Com limitações da pesquisa ou sem pesquisa de mercado, essa empresa foi hábil em identificar essa necessidade de mercado e, utilizando uma inovação tecnológica, traduzi-la em um produto capaz de satisfazê-la. Técnicas como a coleta de dados por observação ou clínicas teriam servido muito bem para solucionar esse fato. Logicamente, é preciso ter muito cuidado nesses casos. Naquela época, se algum profissional que, vislumbrando a possibilidade tecnológica de projetar um produto pequeno, perguntasse, utilizando uma enquete, qual o tamanho ideal de um aparelho de som, certamente ouviria algo na casa das dezenas de centímetros. Não porque os consumidores quisessem algo desse tamanho, mas, sim, porque esse tamanho (grande para os padrões atuais) significaria pequeno, segundo a experiência do consumidor — muitos deles acostumados inclusive à geração anterior de rádios com válvulas, monstruosos para os padrões atuais. Analisando de maneira simplista os dados produzidos, esse pesquisador poderia erroneamente chegar à conclusão de que os consumidores não precisavam de um produto tão pequeno e que o walkman não “emplacaria”. O erro está na escolha do método e no projeto do instrumento de coleta (a pergunta e formato, questionário, inadequados). A pesquisa exigiu uma resposta que o cliente não poderia responder por desconhecer o avanço tecnológico possível ou ter experiência com a nova tecnologia. Por outro lado, caso fosse perguntado, em uma clínica, onde o cliente gostaria de ouvir música, além da casa, certamente muitos diriam que gostariam de fazê-lo no metrô ou durante a corrida matinal e talvez até sugerissem a existência de um aparelho de som portátil igual ao walkman. Respondendo à pergunta inicial: é possível aplicar pesquisa de mercado mesmo Cuidados na realização das para produtos inovadores, desde que observados os devidos cuidados na escolha do pesquisas de mercado método e preparação dos instrumentos de coleta. Os casos de insucesso geralmente são frutos de aplicações inadequadas das técnicas ou erros nos procedimentos de condução da pesquisa. Consulte o Quadro 4.2 para uma visão geral de todos os problemas possíveis. Cabe, então, aos profissionais avaliar o teor da informação a ser obtida com a pesquisa e avaliar se os métodos de coleta 2

Veja o Tópico 2.8, no Capítulo 2.

126

PARTE 2

O Modelo

disponíveis são capazes de gerar a informação com grau suficiente de confiança. Caso seja impossível ou mesmo inviável pelo custo, é melhor não fazer a pesquisa do que utilizar procedimentos problemáticos, que, pior do que ajudar, podem atrapalhar sugerindo direções erradas. Quadro 4.2

Fontes de Erro em Pesquisas de Mercado

Toda pesquisa possui uma margem de erro que precisa ser controlada para que os resultados sejam efetivos. O total de erros de uma pesquisa é formado pela influência de um conjunto de erros que precisam ser controlados. A lista a seguir contém os erros mais freqüentes e serve como verificação. Erros de Amostragem: são os erros cometidos durante a escolha da amostra e que a tornam não representativa. Pode acontecer na escolha dos indivíduos, no dimensionamento ou em amostras estratificadas na definição dos estratos. Erros de Não-Amostragem: são os demais erros que não estão ligados somente à amostragem, eles podem ser divididos em:

• Erros de Projeto: são os erros de seleção, especificação da população-alvo, erros de substituição de informações (escolha da informação errada a ser obtida), erros de medidas (variáveis ou atributos escolhidos equivocadamente) e erros de métodos experimentais.

• Erros de Gerenciamento: erros na aplicação dos questionários ou outros instrumentos de coleta, erros de gravação (trocas de questionários, preenchimento errado por parte do pesquisador, troca de números etc.) e erros de interferência (alterações ou interpretações equivocadas por parte do entrevistador que o está aplicando).

• Erros de Resposta: erros intencionais ou não cometidos pelo respondente. Deve-se atentar para o fato de que ambos podem ter como causa-raiz o projeto inadequado do instrumento de coleta de dados. No caso dos intencionais, a causa pode ser o uso de um termo desconhecido ou que tenha outro significado para o respondente. Os intencionais podem ser gerados por termos ou perguntas que causem constrangimento ou que contenham implicitamente algum juízo de valor. O respondente altera a resposta para evitar o constrangimento ou garantir sua adequação a algum tipo de crença. Pode ser causado também pela falta de confiança do respondente em relação ao uso dos dados ou cansaço (se livrar do entrevistador).

• Erros de Não-Resposta: advêm da impossibilidade de contatar o número suficiente de consumidores segundo o projeto inicial da amostra ou por respostas incompletas ou dúbias que invalidem parte dos dados levantados. Fonte: AAKER, D.; KUMAR, V.; DAY, G. S. Pesquisa de marketing. São Paulo: Atlas, 2001.

A pesquisa das tendências tecnológicas se assenta sobre uma base mais técnica. Pode-se definir tecnologia como um modo peculiar de resolver um determinado problema, utilizando um ou mais princípios físicos ou químicos. Trata-se, portanto, de um corpo de conhecimentos para um fim prático. As tecnologias têm um ciclo de vida, sendo criadas e substituídas tal qual os produtos. Um cuidado especial é que elas podem ser protegidas pelas leis de propriedade intelectual. Para obterem informações tecnológicas, as empresas precisam estruturar um procedimento de vigilância (veja o Quadro 4.3), isto é, de monitoramento da evolução das tecnologias atualmente utilizadas em seus produtos e das tecnologias que podem vir a substituí-las. Um plano de vigilância deve mapear as tecnologias em uso na empresa, identiObtendo informações ficar quais tecnologias estão sendo desenvolvidas em institutos de pesquisa, univertecnológicas por meio da sidades e concorrentes e novas tecnologias substitutas oriundas de outros setores vigilância tecnológica industriais. Exemplos de tecnologias substitutas são: a tecnologia digital substituindo a ótica nas câmeras fotográficas e o CD digital substituindo o videocassete. Monitorar significa não apenas saber da existência, mas também avaliar e prever o desempenho, vantagens e desvantagens, e o período em que a tecnologia estará madura, pronta para ser introduzida em produtos comerciais. Tarefa 2: Coletar informações tecnológicas

CAPÍTULO 4

Planejamento Estratégico de Produtos

127

As empresas podem também utilizar o subterfúgio de criar projetos específicos Obtendo informações para obter análises e informações tecnológicas. A construção de carros-conceito é tecnológicas dos projetos um exemplo clássico. Trata-se de uma estratégia utilizada na indústria automobilísde desenvolvimento tica para avaliar tecnologias futuras. As empresas montam carros que nunca serão comercializados e os apresentam para o público. Esses projetos incorporam várias tecnologias em componentes e materiais inovadoras e tendências de forma e cor. Com isso, pode-se avaliar o potencial e maturidade de cada tecnologia e, ainda, com a apresentação, entender melhor a reação do público. Por exemplo, sabe-se atualmente que os carros baseados em gasolina estão com os dias contados, e as empresas investem há décadas em pesquisas com combustíveis inovadores e é comum, em todo salão de automóvel, observarmos carros-conceito com combustíveis alternativos: hidrogênio, eletricidade, mistos etc. Qualquer uma das grandes montadoras precisa manter vigilância constante sobre as inovações nessas áreas para que possa: dominar aspectos técnicos e já ir formando profissionais capacitados a utilizá-las, caso atinjam o ponto de maturação. Quadro 4.3

Vigilância Tecnológica na Era da Gestão do Conhecimento

Um sistema de vigilância tecnológica é um passo fundamental para a empresa se manter atualizada e para alimentar os sistemas de inteligência competitiva e de mercado. Ele é um sistema de informações, isto é, procedimentos e sistemas informatizados, capazes de manter um monitoramento constante sobre as inovações tecnológicas e suas tendências. Ele deve 3 cumprir quatro etapas básicas:

• Estabelecimento do sistema: o primeiro passo é a definição de recursos humanos, procedimentos, equipamentos e sistemas informatizados de forma a garantir a captação de informações tecnológicas. Montada a estrutura, é preciso identificar as fontes de dados principais sobre a tecnologia específica: bases de dados de patentes, revistas científicas, periódicos importantes sobre o setor, bases de dados de agências de informações, revistas e o mapeamento de competências (pessoas e instituições) que trabalham com o tema.

• Coleta de dados: definido o sistema, passa-se para a coleta contínua dessas informações e a sua organização. Esses dados precisam ser dispostos de forma a serem facilmente acessados pelos usuários da informação.

• Avaliação e análise dos dados: as informações coletadas precisam ser analisadas por especialistas das áreas de tecnologia e desenvolvimento de produtos. Uma prática comum é a criação de cenários a partir da contribuição de informações de diversos especialistas, empregando técnicas específicas de inteligência competitiva. Os sistemas web e o surgimento da Gestão do Conhecimento permitem hoje que essa informação seja analisada e avaliada de maneira compartilhada. A idéia é criar comunidades de prática, isto é, conjunto de pessoas interessadas em um determinado assunto ou pontos específicos relacionados com a tecnologia. As informações coletadas poderiam ficar disponíveis para esse grupo, o qual pode, então, discuti-las e trocar experiências naquele determinado tema. A empresa pode também criar fóruns para discutir os assuntos.

• Disseminação de Informações: as discussões nas comunidades, realizadas com base nas informações continuamente coletadas, podem ser sumarizadas pelo moderador do grupo na forma de políticas, sugestões de ações ou mesmo novos projetos de desenvolvimento ou de pesquisa para a organização.

Um exemplo menos radical de projetos especiais é comumente utilizado na indústria de informática. Imagine uma empresa que tenha um software para gestão de escolas, contendo ensino baseado a distância. Essa empresa pode ser contatada para verificar a possibilidade de desenvolver uma tecnologia que permita avaliar os alunos por meio de competências utilizando algoritmos de inteligência artificial para avaliar notas, trabalhos e opiniões de professores e colegas. Ela poderia fazer um acordo com um determinado cliente interessado nessa funcionalidade e desenvolver um produto sob medida, contendo-a. O cliente, nesse caso parceiro no desenvolvimento, assume os riscos e por isso geralmente paga um preço inferior pelo produto. Em troca, a empresa pode desenvolver e testar a tecnologia com um risco menor, pois parte do investimento virá da venda previamente acertada com o cliente-parceiro. Trata-se de um tipo de projeto de produto cujo objetivo principal é o desenvolvimento da tecnologia e não o lucro. Se tudo der certo, a empresa possuirá ainda um caso de implantação que poderá ser útil na promoção do produto. 3

Essas etapas foram baseadas em KOTLER (2001, p. 251).

128

PARTE 2

O Modelo

Compilando as informações coletadas

Quadro 4.4

As informações devem ser utilizadas na criação de cenários futuros antevendo as tecnologias mais maduras e mais competitivas em termos de custo/benefício. É com base nesses cenários que a empresa investirá na capacitação técnica da sua equipe técnica, podendo optar por diferentes caminhos — conforme demonstra o Quadro 4.4.

Formas de Capacitação Tecnológica (learning)

Existem vários meios de as empresas adquirirem tecnologia, comumente chamados de mecanismos de aprendizado. Os principais são :

• Aprendizado por operação ou utilização: é o fluxo de informações tecnológicas obtidas por meio da experiência, seja fazendo testes operando processos produtivos ou desenvolvendo produtos na área para aprender com eles. Por exemplo, é comum que empresas de softwares aceitem desenvolver produtos novos a preço de custo, quando elas pretendem desenvolver uma nova tecnologia que não dominam. É uma forma de a empresa custear o aprendizado com o desenvolvimento.

• Aprendizado pela realização de mudanças organizacionais: criar mudanças específicas na estrutura organizacional que reforcem a necessidade de desenvolvimento em alguma área. Com a introdução da eletrônica em produtos com tecnologia puramente mecânica, como câmbios e injeção, muitas empresas criaram áreas funcionais unindo profissionais que dominam o assunto como forma de incentivar os profissionais a se preocuparem com aquela determinada tecnologia e criar um centro de competência no assunto dentro da empresa.

• Aprendizado por meio de contratos de aquisição: realização de treinamentos formais. Trata-se do oferecimento de cursos para os profissionais. Isso é muito comum nas áreas de software e eletrônica, nas quais novas linguagens de programação e tipos de equipamentos são constantemente atualizadas pelos fornecedores. Nesse caso, a empresa pode investir em cursos para seus profissionais de desenvolvimento como forma de acelerar a introdução dessas tecnologias.

• Aprendizado por meio de contratação: a empresa contrata pessoas com conhecimentos técnicos e experiência na área. Deve-se tomar cuidado em relação ao uso desse tipo de instrumento de forma a evitar problemas judiciais por segredos de negócio.

• Aprendizado por aquisição: a empresa busca profissionais, empresas de consultoria, institutos de pesquisa ou universidades que detenham a tecnologia e realizam contratos de aquisição — seja por meio da compra de direitos sobre patentes ou mesmo a contratação de serviços especializados desses profissionais.

• Aprendizado por meio de Spin-Offs: uma forma de as multinacionais diminuírem os riscos de investimentos em novas tecnologias tem sido incentivar os funcionários que tenham interesse em desenvolvê-las a montar sua própria empresa, eventualmente, com investimento conjunto entre a empresa e o funcionário. São as chamadas empresas Spin-offs. Nesses casos, a empresa, diminui o risco investindo menos e, caso dê certo, manterá uma parte do negócio, facilitando uma possível reincorporação ou tornando-a um futuro fornecedor.

A empresa deve planejar a introdução paulatina das novas tecnologias nas suas linhas de produtos, minimizando os riscos com o uso de tecnologias pouco conhecidas e no tempo certo, sem atrasos tecnológicos. A melhor prática atualmente é evitar a introdução de um produto 100% novo, uma inovação radical. Existem outros tipos de inovações possíveis (veja o Quadro 4.5), que podem ser utilizados para introduzir novas tecnologias pouco a pouco. Assim, a empresa vai “aprendendo” com os produtos e, ao mesmo tempo, transmitindo uma imagem de empresa inovadora, que atualiza constantemente seus produtos aos “olhos” dos clientes. Com esse artifício, a empresa ainda diminui os riscos inerentes em qualquer inovação. Um aspecto importante a ser enfatizado é que as empresas precisam saber difeDiferenciar produto de renciar bem produto e tecnologia. No passado, muitas empresas as confundiam e tecnologia é fundamental um novo produto significava, no linguajar atual, produto com tecnologias novas, para o desempenho isto é, produtos com inovações radicais. Cada esforço de entrega de um novo proeficiente do processo de duto gerava, então, um reprojeto inteiro do produto anterior. Essa situação pode desenvolvimento de levar a um tempo de desenvolvimento elevado, demora da empresa em responder ao produtos mercado, taxa menor de reúso de componentes e introdução de produtos que não estejam em um grau de maturidade suficiente, causando vários problemas no campo. A melhor forma de atuar é a empresa criar em seu processo de desenvolvimento uma distinção muito clara entre tecnologia e desenvolvi-

CAPÍTULO 4

Planejamento Estratégico de Produtos

129

mento de produtos. Ela deve possuir a capacidade de avaliar cuidadosamente cada tecnologia, medindo sua robustez e, portanto, sua prontidão. Cada tecnologia é aprovada por um processo formal (incluindo testes e experimentos) antes de ser liberada para a incorporação em projetos de novos produtos. Em paralelo, a empresa estaria continuamente lançando novos produtos no mercado, simplesmente alterando sua aparência ou mesmo introduzindo outros tipos de inovação, tal como a incremental e arquitetural. Quadro 4.5

Tipos de Inovação Tecnológica

A empresa pode ir acrescentando atualizações tecnológicas pouco a pouco na linha de produtos. Assim, cada produto possuirá diferentes tipos de inovação, as quais podem ser classificadas em:

• Inovação radical: quando há inovações significativas na tecnologia dos componentes básicos (principais) ou na combinação dos componentes principais.

• Inovação modular: quando se faz uma inovação tecnológica grande, mas restrita, a um dos módulos específicos, sem alterar a concepção geral do produto.

• Inovação incremental: quando não há mudanças significativas na tecnologia dos componentes e na sua combinação, havendo melhorias e otimizações nas soluções de projeto já existentes.

• Inovação arquitetural: quando se faz uma inovação na forma de combinar os componentes, sem que haja evolução na tecnologia básica deles.

Um exemplo é o caso de produtos em estágio avançado no ciclo de vida, como os de linha branca. A velocidade das inovações tecnológicas radicais é pequena. As tecnologias empregadas no produto já existem há décadas e há poucos casos de inovações radicais. Apesar disso, anualmente, as empresas se esforçam para introduzir no produto inovações incrementais, modulares e arquiteturais, processos de fabricação e componentes, visando garantir a competitividade de seus produtos. Nos produtos em estágios iniciais de evolução, as inovações radicais acontecem bem mais freqüentemente. É o caso dos celulares e computadores do tipo tablet PC ou da TV digital. Nos últimos anos, vêm sendo lançados produtos com inovações radicais em termos de padrões. Cada novo padrão traz um salto tecnológico, multiplicando o desempenho dos produtos. A atividade de coleta de informações, conforme definido neste capítulo, pode ser Papéis e responsabilidades desempenhada por diferentes áreas funcionais da empresa, muitas vezes contando com pela atividade de o apoio ou serviços prestados por outras empresas e consultores. Por exemplo, a vigiconsolidar informações lância tecnológica pode ficar a cargo da área de engenharia. O monitoramento e o armazenamento das informações de mercado podem ficar a cargo de marketing. A responsabilidade por organizar os dados muitas vezes é delegada ao papel de gerente funcional. Em grandes empresas, é comum a opção por construir e manter uma área funcional específica para esse fim, um setor de informações ou vigilância competitiva, nos quais existam profissionais da área de ciência da informação dedicados a essa tarefa. No extremo, a empresa poderia criar um processo multifuncional e estruturado denominado monitorar o mercado, conforme discutido no Capítulo 1. Dessa forma seria criado um fluxo para que todas as informações fossem coletadas e reunidas nas diversas áreas funcionais para que pudessem ser sintetizadas e colocadas à disposição das pessoas envolvidas nessa e em outras atividades da empresa. No caso do nosso modelo, consideramos que o papel do Time de Planejamento é ir atrás dessas informações, independentemente de como tenham sido coletadas. Eles podem ainda decidir complementá-las com fontes de dados primárias e secundárias, conforme sentirem necessidades e as oportunidades sejam identificadas. Com base nas informações coletadas, o Time de Planejamento Estratégico de Tarefa 3: Criar cenários e Produtos poderá criar os cenários atual e futuro de tendências tecnológicas e de meranálises sintetizando as cado. Esses cenários e análises são sínteses das diversas informações e balizarão as deinformações cisões sobre o portfólio de produtos. Precisam ser claros e terem sido fruto de um consenso do grupo. São também confidenciais, pois deixam evidente a estratégia da empresa, portanto, eles deverão ser restritos a esse time e à alta administração.

130

PARTE 2

O Modelo

Um aspecto novo e importante em relação a esse tema é que o fluxo de informações não é de uma via apenas e não deve se restringir ao Time de Planejamento Estratégico de Produtos e aos gerentes funcionais. Dentro do conceito de gestão do conhecimento apresentado no Capítulo 2, a meta é disponibilizar os conhecimentos dos diversos colaboradores para todos os profissionais da empresa. Assim, deve-se criar mecanismos para que os diversos profissionais possam discutir e trocar informações complementares sobre esses assuntos; um exemplo é a utilização de grupos de discussão e comunidades de prática (consulte o Quadro 4.6). Fazendo isso, o Time de Planejamento Estratégico de Produtos poderá obter contribuições de todos os profissionais, aumentando a qualidade dos cenários, análises e decisões. Ao mesmo tempo, ao divulgarem parte das informações, estarão contribuindo para a capacitação e aumento do nível de conhecimento de todos os envolvidos no processo de desenvolvimento. A gestão do conhecimento deve ser cada vez mais presente nessa atividade

Quadro 4.6

Comunidades de Prática no PDP

A constituição de comunidades de prática é um poderoso recurso para as empresas interessadas em captar informações tecnológicas e mercadológicas. Conforme apresentado no Capítulo2, uma comunidade é um grupo de pessoas que realizam uma mesma função ou têm um mesmo interesse. Elas se unem para discutir determinados assuntos. A empresa pode incentivar a criação de comunidades para discutirem aspectos de diferentes tecnologias ou assuntos relacionados. Elas trocam experiências e informações, sendo uma importante fonte para a atualização tecnológica e obtenção de novas idéias de produtos. Por exemplo, comunidades de prática com todos os vendedores e pessoal de assistência técnica estão sendo constituídas nas empresas, para que os profissionais possam compartilhar melhores práticas e informações prévias dos clientes. Com os devidos cuidados, seria possível aproveitar essa comunidade para solicitar informações sobre o mercado ou discutir com eles tendências para os novos produtos. O registro adequado das discussões da comunidade pode ser de alto valor para os responsáveis pela análise do Plano Estratégico da Empresa. Outro exemplo, podem ser criadas comunidades de especialistas em determinadas tecnologias de forma que, em vez de contratar a peso de ouro um especialista externo para descobrir as tendências na área de ótica, o Time de Planejamento Estratégico de Produtos poderia consultar a comunidade inteira. Seria possível pedir para que eles discutissem o tema em um fórum e depois criassem um sumário da discussão para alimentar os cenários de tendências tecnológicas e de produtos. As comunidades podem auxiliar em outros aspectos do processo de desenvolvimento de produtos. Por exemplo, precisa-se de um especialista em lentes para compor um determinado time de desenvolvimento de produtos? Por que, então, não procurar esse especialista em uma das comunidades de prática sobre ótica, a qual poderia conter, além das pessoas da empresa, profissionais de empresas parceiras e de instituições como universidades e centros de pesquisa? Isso sem falar na mais imediata das implicações. Em vez de a empresa investir milhões anualmente em cursos de reciclagem para todos os funcionários, que tal a existência de uma comunidade em que eles se mantivessem em contínuo aprendizado, diminuindo a necessidade desses cursos e garantindo uma alta preparação dos colaboradores em momentos de tomadas de decisão? As possibilidades nesse sentido são grandes e tentadoras, mas será preciso enfrentar desafios novos. Diferentemente de outras áreas, nas quais o tão famoso “comprometimento da alta administração” é capaz de garantir um mínimo de resultados, não se pode criar uma comunidade “unilateralmente”, de cima para baixo, empregando as estruturas funcionais clássicas. Eis um conjunto de diretrizes visando esse objetivo:

• Estabeleça um grupo inicial que se conheça e respeite profissionalmente e, de preferência, tenha bons relacionamentos pessoais anteriores.

• No caso de uma empresa ou grupo de trabalho, estabeleça um objetivo que possa unir o grupo e que tenha o potencial de fazê-los realizar tarefas conjuntas.

• Encontre formas de fazer com que o grupo defina suas próprias regras de convivência e de valores, como criando um código de ética.

• Mais que evitar problemas, esteja preparado para solucioná-los de maneira transparente e democrática. • Faça dos problemas uma oportunidade para a discussão e aprimoramento do consenso sobre as formas de conduta dentro da comunidade.

• Utilize as ferramentas computacionais de maneira consciente, aproveitando o seu potencial de apoio nas atividades e de “marketing” na cooperação.

• Cultive a confiança dos membros a cada dia, todos os dias, com ações de esclarecimento e por meio de atividades cooperativas e programas de intercâmbio. Fonte: AMARAL, D. C.; MOSCONI, E. P.; ROZENFELD, H. “Cultivando confiança: o dia-a-dia de uma comunidade de prática em desenvolvimento de produtos.” In: TERRA, J. C. Gestão do conhecimento e e-Learning na prática: 39 casos. Rio de Janeiro: Elsevier, 2003.

CAPÍTULO 4

Planejamento Estratégico de Produtos

4.5

131

Revisar o PEN

A revisão do Plano Estratégico de Negócios é realizada pelo Time de Planejamento Estratégico de Produtos, por meio de reuniões de trabalho, seguindo o calendário e agendas previstos na etapa de planejamento, Tópico 4.3, e os cenários e informações sistematizados na atividade do Tópico 4.4; conforme ilustra a Figura 4.6. Serão uma ou mais reuniões nas quais a equipe discutirá o Plano Estratégico de Negócios até que exista um consenso sobre esse documento. As saídas dessa atividade são recomendações e observações sobre o Plano Estratégico definido. Figura 4.7

Resumo da atividade “Revisar o Plano Estratégico de Negócios –(PEN)”.

As tarefas principais que precisam ser realizadas pelo time são explicadas nos tópicos que se seguem. O nível de profundidade e o tempo dedicado em cada um deles variam conforme escopo da revisão de fases, preparado ao final da atividade do Tópico 4.2, e os resultados das atividades anteriores. n

n

Revisar missão: o Time de Planejamento Estratégico de Produtos precisa inicialmente ter ciência e clareza sobre a missão da organização. Essa missão é definida no Planejamento Estratégico da Unidade de Negócios e normalmente não precisará ser discutida, pois deverá ser bastante evidente e clara para todos os profissionais da empresa. Deverá ser objeto de análise apenas em casos especiais, uma vez questionada por algum membro da comissão ou recentemente adotada pela corporação. Revisar segmentação do mercado: deve-se analisar detalhadamente a divisão de segmentos de mercado proposta no Plano Estratégico de Negócios, mas com o foco no segmento para o qual está sendo realizada. A delimitação adequada dos segmentos de mercado é vital para a qualidade de qualquer planejamento estratégico. Um segmento significa um conjunto de consumidores com características de consumo similares. Quanto melhor essa delimitação, mais coeso será o público-alvo de cada projeto, e isso afetará todo o desenvolvimento dos produtos. Um exemplo, quanto mais coeso, mais fácil será realizar a atividade de levantamento de requisitos na fase de projeto informacional.

132

PARTE 2

n

n

n

n

n

n

n

O Modelo

Revisar posicionamento no mercado: isso significa analisar os cenários que foram desenvolvidos na atividade anterior, para identificar a posição da empresa diante da concorrência. Essa posição deve ser vista tanto do ponto de vista de mercado, participação, mas também em termos da linha de produtos. O Plano Estratégico de Negócios deve identificar claramente qual a percepção dos clientes quanto à linha de produtos da empresa, quais são os aspectos fortes e fracos e, principalmente, quais os diferenciais competitivos tanto dos produtos da empresa quanto dos concorrentes. Ao final da revisão, mudanças podem ser propostas. Revisar tendências tecnológicas: da mesma forma que a anterior, essa tarefa compreende a análise dos cenários ali consolidados. Aqui o importante é entender quais as tecnologias que devem predominar no decorrer do horizonte de planejamento. Além das tecnologias, deve-se atentar para as metas de desempenho dos produtos. Por exemplo, emissão de gases tóxicos, quantidade de rejeitos, velocidade e certos parâmetros fundamentais de desempenho muitas vezes precisam ser monitorados, pois são metas que deverão estar contidas na definição de novos projetos a ser realizada nas próximas atividades do modelo — seja pela evolução da concorrência ou por exigências de instituições normalizadoras ou governamentais. Mapas com a evolução desses parâmetros devem estar contidos no Plano Estratégico de Negócios e, nessa tarefa, são analisados com cautela pelo Time de Planejamento Estratégico, que poderá identificar necessidades de análises complementares ou apontar erros nas análises realizadas. Revisar o direcionamento estratégico da Unidade de Negócio (UN): se as análises anteriores forem realizadas com êxito, o time estará consciente das tendências tecnológicas e de mercado e poderá entender claramente a motivação da estratégia estabelecida para a unidade de negócio, expressa no direcionamento estratégico. Ele é a diretriz que resume a metas da UN e o meio que deverá ser utilizado para atingi-la. Para um exemplo simples, imagine uma unidade de negócio de desenvolvimento de produtos para colheitas agrícolas que poderia ter traçado a meta de aumentar em 10% sua participação no mercado de equipamentos para soja por meio do desenvolvimento de novos produtos para o plantio. Essa informação guiará a proposição do novo portfólio de projetos, que deverá, então, conter novos projetos de equipamentos para o plantio de soja. Portanto, compreender perfeitamente o que a alta direção deseja para a UN é o passo central e vital para a definição da estratégia de produtos, a qual deverá acontecer nas próximas atividades. Revisar competências: com os cenários de tendências de mercado e tecnológicos e a definição do direcionamento estratégico, deve-se começar a analisar a capacidade de a empresa em implementá-las. O primeiro passo é verificar se a empresa possui pessoas com as competências necessárias para enfrentar os desafios de mercado e trabalhar com as novas tecnologias que deverão ser utilizadas segundo as tendências observadas. Avaliando a situação da empresa nesse quesito, é possível antecipar ações de capacitação, seja com projetos, treinamento ou aquisição de profissionais do mercado, visando suprir as lacunas existentes. Revisar recursos necessários: idem à atividade anterior, mas a análise agora é quanto aos recursos físicos e monetários. Um exemplo de recursos físicos é o caso de uma empresa do ramo de máquinas que decide introduzir uma nova tecnologia baseada em eletrônica e precisará de um laboratório para desenvolver e produzir placas de circuito impresso e softwares. Isso precisa ser previsto no plano. A situação dos recursos financeiros previstos também é importante e precisa ser revista com cuidado. Revisar metas: ao final de todas as análises, o Time de Planejamento Estratégico de Produtos poderá revisar as metas para a UN estipuladas pela alta direção da empresa. Possíveis discordâncias teriam que ser levadas para uma discussão superior. Preparar documento sobre resultados da revisão do PEN: o resultado das discussões realizadas nesta fase serão dúvidas, sugestões e novas interpretações dos dados contidos no plano. Tais informações devem ser planejadas e serão úteis nas próximas atividades. Inclusive, várias idéias para novos projetos já devem ter surgido no decorrer dessas análises e, nesse caso, é fundamental que elas sejam cuidadosamente compiladas para ser aproveitadas nas próximas atividades.

CAPÍTULO 4

Planejamento Estratégico de Produtos

4.6

133

Analisar o portfólio de produtos da empresa

Uma vez realizadas as atividades anteriores, o Time de Planejamento Estratégico de Produtos estará pronto para iniciar o estudo do portfólio de produtos da empresa, atividade que é representada esquematicamente na Figura 4.8. O portfólio de produtos é a “carteira” de projetos de desenvolvimento que a empresa oferece, isto é, o conjunto de produtos que a empresa está desenvolvendo ou que comercializa. Nessa atividade, o Time de Planejamento Estratégico de Produtos deverá avaliá-lo com vistas a obter sugestões (idéias) de mudanças e possíveis novos produtos. Figura 4.8

Resumo da atividade “Analisar portfólio de produtos da empresa”.

Cada produto ou novo projeto pode ser visto como um negócio que visa obter Cada projeto de novo resultados para a empresa, que, em geral são: obter lucro, atender a quesitos especíproduto é um novo ficos da estratégia ou obter algum aprendizado. Um projeto pode buscar atender negócio todos esses objetivos ou ter um deles como prioritário. Outra característica que precisa ser notada é o fato de todo projeto possuir um risco associado. Como todo planejamento, o Plano Estratégico de Produtos é uma previsão, no popular “um chute”, que pode ou não a vir se concretizar. Os riscos inerentes a cada projeto podem ser maiores ou menores, dependendo da natureza do projeto. O importante é que a empresa aprimore seu processo de forma a aprimorar seu embasamento no momento da previsão, permitindo-lhe aprimorar cada vez mais esse “chute”. Visto isso, é fácil perceber por que a análise desse conjunto é fundamental para O que é o gerenciamento a sobrevivência da empresa. Ao definir o portfólio de produtos, o Time de Planejade portfólio? mento Estratégico de Produtos estará assumindo um determinado nível de risco e definindo o futuro da linha de produtos da empresa, algo fundamental para a sua sobrevivência. Uma escolha bem-feita significa que a empresa terá um conjunto de projetos que resultem em uma linha de produtos capaz de atender às necessidades dos clientes-alvo, conforme previsto na estratégia de negócios, com o menor nível de risco possível e a maior lucratividade. O menor risco significa que, mesmo que alguns dos projetos dêem errado, o resultado final não será comprometido. Escolher projetos ruins afastará o conjunto de projetos de um desses objetivos básicos e, mesmo que eles sejam bem-feitos e que tudo dê certo, a empresa não terá êxito no mercado. Exemplo: pode-se ter um conjunto de projetos que leve a produtos de alta rentabilidade, mas que esteja atacando necessidades não previstas na estratégia. Nesse caso, pode-se comprometer a sobrevivência futura da empresa. É possível, ainda, optar por um portfólio de produtos de alta rentabilidade e voltado para a estratégia, mas com projetos predominantemente de alto risco. Isso também pode comprometer o futuro da empresa, dado que existirá uma chance alta dos projetos

134

PARTE 2

O Modelo

falharem. Por fim, pode ser que o risco seja baixo e que os produtos sejam alinhados com a estratégia, mas, se a rentabilidade dos projetos é baixa, a saúde financeira da empresa no curto prazo poderá ser comprometida, levando-a à bancarrota antes dos lucros chegarem. O Quadro 4.7 possui uma definição formal do que é a gestão de portfólio e seus objetivos. Similar a um acionista que investe em uma carteira ou portfólio de ações, o objetivo principal do Time de Planejamento Estratégico de Produtos deve ser escolher os projetos a serem desenvolvidos e produtos que devem permanecer no mercado. Quadro 4.7

Gestão de Portfólio

A gestão do portfólio ou da carteira de projetos é um processo estruturado de decisão sobre quais projetos devem ou não ser desenvolvidos dentro da organização. Esse processo deve ser bem formalizado dentro da empresa e envolve atividades de avaliação dos projetos e produtos existentes, identificação de novas idéias, priorização e escolha. Seu resultado é uma decisão sobre cada projeto ou produto da empresa, envolvendo um dos cinco tipos básicos de escolha:

• Criar novo projeto. • Aprovar o projeto em desenvolvimento, na forma como está atualmente. • Redirecionar um projeto. É o caso no qual o projeto será mantido com a condição de que haja um conjunto específico de modificações no escopo.

• Congelar um projeto. É a alternativa de suspender o projeto até que ele possa ser retomado no futuro, do ponto em que se encontra.

• Cancelar um projeto. É a alternativa de abandonar ou matar um projeto. Normalmente, dada a cultura das empresas e da sociedade, essa alternativa é evitada ao máximo dentro das organizações. Tanto o Time de Planejamento Estratégico de Produtos como o Time de Desenvolvimento procuram evitar o sentimento de fracasso que acompanha tal decisão. Com isso, muitos projetos sabidamente problemáticos acabam sendo mantidos. E, para evitar um prejuízo menor, acaba-se criando um prejuízo muitas vezes maior no futuro. A verdade é que a atitude de cancelar um projeto precisa ser considerada como algo normal, inerente às incertezas ligadas a esse processo de negócio, desde que ela aconteça nas fases iniciais do processo de desenvolvimento de produtos e causada por motivos que não poderiam ter sido previstos anteriormente. Deve-se notar que as quatro últimas escolhas são idênticas aos tipos de decisão que acontecem na atividade genérica de aprovar a fase. Isso não ocorre por acaso, pois, ao se revisar o portfólio de projetos da empresa, os tipos de decisão são idênticos aos de aprovação de fase, com exceção da adicional de criar novo projeto. Tais escolhas devem ser feitas de maneira que o conjunto final de projetos e produtos satisfaça os três objetivos básicos da gestão de portfólio:

• Maximizar o retorno financeiro: o conjunto de projetos deve trazer a maior rentabilidade possível para a empresa. Os investimentos realizados em todos os projetos deverão ser superados com grande vantagem pelos retornos a serem produzidos. Trata-se de um critério fundamental, mas, se tomado isoladamente, pode levar a empresa a prejuízos no longo prazo. Isso é particularmente verdadeiro para o desenvolvimento de novos produtos, pois, para a maioria das empresas, os projetos mais lucrativos são os que se baseiam em continuação de produtos vencedores no mercado e/ou que utilizam tecnologias consagradas pela empresa. Portanto, se esse for o único critério utilizado pelo Time de Planejamento Estratégico de Produtos, a empresa corre o risco de realizar somente projetos desse tipo, comprometendo seu futuro.

• Alinhar com a estratégia da empresa: este critério é o grau com que tais projetos se alinham com as metas estratégicas da empresa. Por exemplo, se a meta da empresa é competir com diferenciação em custo, voltadas para a Classe C, o conjunto de projetos do portfólio deve permitir que a empresa constitua uma linha de produtos com tal diferenciação. Se há projetos de produtos sofisticados, com muitas funções e tecnologias inovadoras, é sinal de que essa carteira de projetos não está alinhada com a estratégia da empresa.

• Balancear o portfólio de projetos: os dois critérios anteriores são capazes de atender à missão da organização: ter lucro por meio de uma determinada estratégia. Mas avaliar os projetos utilizando apenas os dois critérios anteriores pode levar ao erro de não se considerar o nível de risco da carteira de projetos. Esse nível de risco deve ser o menor possível, e eis aí algo que pode ser obtido combinando projetos altamente inovadores, capazes de manter a sobrevivência da empresa no longo prazo, com projetos de menor risco e alta lucratividade, destinados a manter a posição da empresa no mercado. Portanto, balancear o portfólio é manter uma proporção adequada de inovação, risco e lucratividade, atendendo, além da estratégia da empresa, às realidades de curto e longo prazos do mercado. Informações adicionais podem ser obtidas em: COOPER, R. G; EDGETT, S. J.; KLEINSCHMIDT, E. J. Portfolio management for new products. Massachussets: Perseus Book, 1998.

CAPÍTULO 4

Planejamento Estratégico de Produtos

135

Há um conjunto de técnicas para se analisar uma carteira de projetos. Elas são similares às utilizadas na análise de mercados, segmentação em unidades de negócio e até mesmo na análise de carteiras de ações. Elas podem ser divididas em três tipos básicos, conforme apresentado no Quadro 4.8. Quadro 4.8

Técnicas para Avaliação do Portfólio de Produtos

As técnicas para gestão de portfólio podem ser divididas em três grupos distintos: Análise do Valor Comercial Esperado: é a avaliação por meio de modelos de matemática financeira, considerando investimento, retorno e riscos. Esses modelos utilizam os índices de avaliação financeira, tais como: Valor Presente Líquido, Taxa Interna de Retorno e outros para medir qual a média (esperança) de retorno financeiro de cada projeto. O resultado é comparado e pode-se priorizar os projetos com melhor retorno. Um exemplo simples é a obtenção do Valor Econômico Esperado por meio de um modelo de árvore de decisão, unindo os índices financeiros com um pouco de probabilidade, conforme a Figura 4.9. Figura 4.9

Valor econômico esperado.

Cada projeto foi dividido em duas grandes fases, denominadas, respectivamente, de Desenvolvimento e Lançamento. Obtém-se o valor gasto em cada uma delas para cada projeto: Custo do Desenvolvimento ($D) e Custo do Lançamento ($L). O time fará uma avaliação técnica para determinar a Probabilidade de Sucesso Técnico (Pts) e Comercial (Pcs). Deve-se calcular também o Valor Presente das receitas previstas no projeto (VPR). Com essas informações, é possível, então, calcular o Valor Esperado (ECV) de cada projeto, que, nesse caso, será dado pela seguinte fórmula: ECV = (VPR x Pcs – L) x Pts – D No linguajar estatístico, esse valor significa que, se esse projeto fosse executado repetidas vezes, tendendo ao infinito, e se fossem calculados os resultados financeiros, a média dos valores econômicos obtidos seria igual ao ECV. Portanto, trata-se de uma medida que combina Retorno Financeiro e Risco, de forma que quanto maior esse valor, melhor o projeto. Modelos Baseados em Notas (Score): são os modelos que utilizam um conjunto de critérios predefinidos e baseados em notas para avaliar os projetos. O primeiro passo é a definição dos critérios, tais como: facilidade de implementação, participação no mercado, dificuldade técnica, nível de risco etc. Cada um dos critérios é definido, incluindo uma escala qualitativa ou um índice quantitativo que serão utilizados para medir cada projeto. Os critérios são priorizados e aplicados para avaliar cada projeto. O próprio grupo responsável pela decisão pode avaliá-los. Em alguns casos, especialistas podem ser consultados para avaliar um ou mais critérios. Os resultados podem ser utilizados para criar índices compostos, com pesos adequados para cada um dos critérios, que fornecem a informação dos projetos que devem ser priorizados. A eficácia na utilização desses modelos depende totalmente da escolha adequada dos critérios e pesos e da sistemática de condução das reuniões e obtenção das avaliações. Caso alguns aspectos não sejam considerados ou os critérios sejam definidos inadequadamente, prejudica-se a qualidade da decisão. A condução das discussões é uma tarefa que precisa ser realizada de forma transparente e com a contribuição de todos. Deve-se criar um procedimento que impeça que uma ou mais pessoas, de personalidade mais forte, dominem o debate e influenciem a resposta de todo o grupo. Um exemplo de Modelo de Notas é apresentado nas figuras 4.10a e 4.10b. A primeira tabela é uma forma de dar pesos aos critérios, partindo-se de uma análise sistemática. O exemplo mostra três critérios para projetos de famílias de redutores. No

(continua)

136

PARTE 2

Quadro 4.8

O Modelo

Técnicas para Avaliação do Portfólio de Produtos (continuação)

caso, a estratégia da empresa é a de obter uma linha de produtos voltada para um nicho específico do mercado específico, que forneça para o cliente o menor custo de operação e que permita a criação de extensões futuras para outros segmentos de mercado. Portanto, os três critérios apresentados estão relacionados com a estratégia e são qualitativos. Trata-se de um exemplo didático, pois, na prática, deveriam ser considerados também critérios de risco e de retorno financeiros, podendo ser quantitativos. Feita a lista de critérios, eles são dispostos em uma matriz relacionando-os entre si. O Time de Planejamento Estratégico de Produtos se reúne e, por meio da Tabela da Figura 4.10a, compara cada critério contra todos os demais, identificando qual é o mais importante e anotando os pontos conforme a legenda da figura. A soma dos pontos, se relativizada, oferece um valor de peso para cada critério. Os critérios alimentam as matrizes para avaliação dos projetos, como exemplificado na Figura 4.10b. No exemplo, pode-se ver a avaliação do projeto da Família LGB. Cada um dos membros do time avaliou o projeto segundo os critérios. Por fim, o valor obtido para esse projeto é comparado com os demais projetos do portfólio na Figura 4.10c. Figura 4.10

Exemplo de modelo de notas.

Modelos de Gráficos de Bolhas: os Gráficos de Bolha são gráficos que possuem três dimensões (dois eixos e o diâmetro dos pontos) e se caracterizam por separar o espaço em quadrantes. Avaliar portfólio utilizando Gráficos de Bolhas significa desenhar o gráfico para o conjunto de projetos da empresa. O significado dos eixos e do raio da circunferência pode variar de acordo com a necessidade dos avaliadores. Os eixos geralmente representam o retorno financeiro e a probabilidade de sucesso técnico, e o raio significa a quantidade de investimento necessária para o projeto, conforme exemplificado na Figura 4.11, para uma empresa hipotética que desenha e produz caminhões.

(continua)

CAPÍTULO 4

Planejamento Estratégico de Produtos

Quadro 4.8

Figura 4.11

137

Técnicas para Avaliação do Portfólio de Produtos (continuação)

Exemplo de modelo de avaliação de portfólio utilizando Gráfico de Bolhas.

A grande vantagem dessa técnica de avaliação de portfólio é que esses gráficos apresentam, de uma forma sintética e simples, várias informações relevantes. Outro aspecto é que os quadrantes têm um significado bem claro para o Time de Planejamento Estratégico de Produtos, conforme os eixos escolhidos. Por isso, geralmente atribuem-se nomes a esses quadrantes como forma de classificar os tipos de projeto. No caso do exemplo, o quadrante superior da esquerda foi chamado de Pérolas, porque une os melhores projetos, aqueles que possuem alto retorno financeiro e alta probabilidade de sucesso técnico. Os da direita foram chamados de pão com manteiga porque contêm os projetos com baixo retorno financeiro, porém, com pouco risco. Geralmente, enquadram-se nessa categoria os projetos de mudança incremental nos produtos vencedores da empresa, isto é, produtos que são bem avaliados no mercado. As ostras são os projetos que, se bem cuidados, isto é, se os riscos forem diminuídos, podem se transformar em pérolas. Faz parte desse grupo os projetos que possuem alto retorno, mas a probabilidade de sucesso é baixa. Por fim, os elefantes brancos que são projetos com baixo retorno e alto risco, mas que podem trazer benefícios para estratégia ou para o marketing da empresa, conforme está exemplificado no projeto do caminhão ecológico. Um portfólio de produtos bem balanceado deve conter projetos nos vários quadrantes, garantindo-se a combinação de inovação e exploração máxima do potencial dos projetos já existentes. A vantagem desse modelo de avaliação é que ele permite balancear facilmente o portfólio. Fonte: COOPER, R. G.; EDGETT, S. J.; KLEINSCHMIDT, E. J. Portfolio management for new products. Massachussets: Perseus Books, 1998.

Do quadro contendo as técnicas para avaliação do portfólio é possível verificar que cada um desses três tipos básicos possui vantagens e desvantagens quanto ao atendimento dos objetivos principais da gestão de portfólio. É fácil perceber que a Análise do Valor Econômico Esperado é uma ótima técnica para identificar os projetos que maximizam o retorno financeiro, mas é inadequada para apontar quais deles se alinham com a estratégia da empresa. Já o Gráfico de Bolhas é ótimo para balancear os projetos e ruim para alinhar com a estratégia. O Modelo de Notas é mais flexível e possui a desvantagem de ser mais suscetível a erros de interpretação. O fato é que cada um dos modelos permite analisar com mais ou menos propriedade cada um dos objetivos básicos da gestão de portfólio e, portanto, a situação ideal é combiná-los de forma a obter o máximo de cada um, visando a melhor decisão. Uma comparação dos três tipos básicos de técnicas para gestão de portfólio é apresentada no Quadro 4.9.

138

PARTE 2

Quadro 4.9

O Modelo

Comparando as Técnicas para a Avaliação de Portfólio

A Figura 4.12, a seguir, apresenta uma comparação didática entre os métodos para a avaliação do portfólio com os objetivos básicos dessa análise. O Valor Comercial Esperado é mais eficaz na comparação da maximização do valor. Ele auxilia no balanceamento porque considera o risco dos projetos, mas é totalmente ineficaz quando a meta é alinhar com a estratégia da empresa. O Gráfico de Bolhas é o mais eficaz no balanceamento do portfólio, auxilia no alinhamento estratégico, mas não contribui de maneira eficaz para priorização da maximização do valor. Já o Modelo de Notas pode ser utilizado para adequar os projetos aos três objetivos, bastando, para isso, considerar critérios para cada um deles. O problema é que ele é menos eficiente que os demais em objetivos específicos, pois sua implantação está sujeita a uma série de vieses conforme são escolhidos os critérios e seus pesos. Figura 4.12

Comparação dos métodos para análise e avaliação do portfólio de projetos.

O ideal é que a empresa adapte esses diferentes índices e técnicas criando uma metodologia própria de avaliação de portfólio, na qual as diferentes metodologias se complementem e se fundem. Por exemplo, pode-se adicionar um índice de um Modelo de Notas em um Gráfico de Bolhas, o Valor Econômico Esperado como um critério do Modelo de Notas e assim por diante.

Agora que pudemos conhecer melhor o que é a gestão de portfólio e as técnicas que podem ser utilizadas, fica mais fácil entender as tarefas que compõem a atividade de avaliar o portfólio de projetos. Nessa atividade, basicamente, o Time de Planejamento Estratégico de Produtos deverá revisar a metodologia de avaliação do portfólio, isto é, definir os modelos a serem utilizados, critérios específicos e escalas. O grupo deve definir também a dinâmica a ser empregada nas reuniões em que houver trabalho coletivo, como na escolha dos critérios e definição de pesos. Definidos os critérios para a avaliação do portfólio de produtos, deve-se dar Tarefa 2: Avaliar o início à avaliação dos projetos em andamento e produtos existentes quanto aos criposicionamento dos térios propostos no modelo de avaliação. Essas informações podem ser compiladas produtos em uma única planilha ou qualquer outro software específico para essa função. No caso dos produtos que já estão no mercado, as informações sobre o seu deTarefa 3: Avaliar o sempenho diante da concorrência são essenciais e devem ser coletadas e sintetidesempenho dos zadas. Elas serão transmitidas ao Time de Planejamento Estratégico de Produtos e produtos servem de apoio ao processo de decisão. Portanto, essa é mais uma tarefa que deve acontecer nessa etapa. Tarefa 1: Revisar/Definir o método de avaliação de portfólios

CAPÍTULO 4

Planejamento Estratégico de Produtos

139

Uma análise importante é com relação às tecnologias básicas adotadas pela emTarefa 4: Avaliar presa e os concorrentes, sem se esquecer de avaliar as plataformas de produto. É tecnologias e plataformas fundamental identificar quais são as plataformas existentes e as variações, pois isso utilizadas traz uma enorme economia de investimentos no desenvolvimento de produtos e reutilização. Mais tarde, na macrofase de desenvolvimento, ficará clara a definição 4 de plataformas e a importância de seu planejamento. Idéias para novos projetos de desenvolvimento são continuamente geradas Tarefa 5: Compilar idéias dentro da organização. Por exemplo, os colaboradores da força de venda costumam de novos produtos ter boas idéias ou as coletam de seus clientes. Engenheiros e especialistas das áreas de desenvolvimento de produtos, além de novos produtos, podem identificar novas tecnologias potenciais. Possuir uma sistemática para coletar essas idéias é fundamental. A empresa pode adicionar um campo no formulário de visita ao cliente ou até mesmo oferecer certos tipos de recompensa por idéias que se transformam em produtos. O resultado será uma lista de propostas de novos projetos que deverá também ser fornecida ao Time de Planejamento Estratégico de Produtos. Se há uma planilha automatizada com os critérios e gráficos para análise do portfólio, cada um dos projetos potenciais poderia já ser cadastrado para manter um histórico das idéias. Afinal, pode ser que uma das idéias propostas não seja interessante no momento atual da avaliação do portfólio e, no futuro, ser “ressuscitada” ou servir como estímulo para uma nova idéia. São iniciadas as reuniões de trabalho do Time de Análise Estratégica dos ProTarefa 6: Analisar projetos dutos. O primeiro item da agenda será analisar as informações coletadas sobre os prosegundo critérios de dutos atuais entregues no mercado, plataformas e tecnologias e complementar a lista de análise do portfólio idéias de novos projetos. Caso existam muitas propostas, o time poderá realizar um primeiro filtro, eliminando aquelas sabidamente inviáveis técnica ou economicamente. Outro ponto importante é avaliar as plataformas e tecnologias utilizadas. Uma plataforma é um conjunto de elementos e subsistemas comum a um conjunto de projetos. Esse compartilhamento reduz custos e riscos do projeto. Ele ajuda também na assistência técnica e apoio ao cliente (o tópico a seguir contém uma breve descrição desse problema). Portanto, é preciso avaliar quais são as plataformas existentes. Depois de definida a lista de projetos que devem ser considerados, cada um deles será avaliado segundo os critérios propostos no modelo de avaliação do portfólio de projetos. Isso significa dar notas ou realizar previsões como cálculo do Valor Econômico Esperado. Ao final dessa tarefa, o time estará finalizando a atividade de Análise do Portfólio de Produtos da Empresa, e o Time de Planejamento Estratégico de Produtos estará ponto para tomar a decisão de quais projetos e produtos ficam, saem ou são adicionados.

4.7

Propor mudanças no portfólio de produtos

Com os resultados das avaliações de todos os projetos em mãos, o Time de Planejamento Estratégico de Produtos poderá dar início à definição do portfólio de produtos futuro da empresa, isto é, realizar a decisão de quais produtos serão desenvolvidos e mantidos no mercado. Essa atividade é representada esquematicamente pela Figura 4.13, sendo as informações de entrada o Portfólio de Produtos e a lista de idéias. Logicamente, todas as análises e cenários criados na atividade do Tópico 4.4 poderão ser extremamente úteis. O resultado final dessa atividade é o novo portfólio de produtos da empresa. Do conjunto de idéias de novos produtos compilados, parte será eliminada nessa fase. A palavra eliminada não significa necessariamente deixar de constar na planilha ou no sistema utilizado para gerenciar o portfólio. Como o histórico das decisões é importante para o aprendizado futuro, os projetos rejeitados devem ser armazenados para futuras consultas. Um aspecto fundamental nessa escolha e que vai além dos critérios de avaliação A importância do valor e do portfólio de produtos, apresentado no tópico anterior, é o aspecto da diferenciação da diferenciação dos e do posicionamento. Explicaremos melhor essa questão. produtos

4

Caso esteja interessado em obter mais informações neste momento, consulte o Apêndice II e os quadros de definições de termos-chave nos capítulos 6 e 7.

140

PARTE 2

Figura 4.13

O Modelo

Resumo da atividade “Propor mudanças no portfólio de produtos”.

Uma máxima atualmente válida para produtos e serviços, e que precisa ser sempre lembrada, é que, no mercado, não há espaço para produtos com desempenho mediano em todas as suas características. Produtos desse tipo estão fadados ao fracasso, pois, mesmo não apresentando deficiências em relação aos concorrentes, eles dificilmente irão se sobressair no momento da escolha realizada pelo cliente. As empresas que obtêm vantagens competitivas por meio de produtos são aquelas que possuem linhas de produtos com características tais que criam uma imagem única na mente dos consumidores e na qual cada produto possui vantagens em um conjunto coeso de características que são fundamentais para o cliente, conforme o tipo especial de cliente para o qual foi planejado. O usuário experimenta um diferencial em relação aos outros produtos porque as características que ele mais valoriza são melhores naquele produto. É o fator de diferenciação. Cada produto de uma linha deve ter esse fator bem definido de forma a atender um conjunto específico de clientes, sem haver também a sobreposição. (Veja o Quadro 4.10.) Quadro 4.10

Diferenciação e Posicionamento de Produtos

Segundo Kotler (2000), diferenciação é o ato de desenvolver um conjunto de diferenças significativas para distinguir a oferta da empresa (produto + serviço) da oferta da concorrência. Para diferenciar, é preciso entender os valores dos clientes, isto é, identificar os perfis de clientes e a hierarquia de valores de cada perfil. Isso significa identificar quais aspectos do produto e serviço são mais importantes dentro do perfil: o pacote de valores. Conhecendo os pacotes de valores, é possível planejar produtos de forma que ofereçam um conjunto de características coerente com o conjunto de valores. É isso que fará com que ele ocupe uma posição de destaque diante dos demais produtos da empresa e dos concorrentes, para aquele perfil de cliente específico. Essa ação é chamada de posicionamento. De uma maneira mais rigorosa, Kotler (2000) define posicionamento como o ato de desenvolver a oferta e a imagem da empresa para ocupar um lugar destacado na mente dos clientes-alvo. O resultado final do posicionamento é a definição de uma possível oferta de produto com definição clara de seu diferencial perante os produtos presentes no mercado. Fonte: Kotler (2000).

A identificação clara da diferenciação de cada produto da linha é fundamental também para obter uma maior racionalidade na produção e comercialização dos produtos, aumentando as chances de lucro da empresa. Se uma empresa possui uma sobreposição, com dois produtos capazes de atender às necessidades de um mesmo

CAPÍTULO 4

Planejamento Estratégico de Produtos

141

perfil de cliente, surgem várias ineficiências. O volume de vendas de cada produto será menor do que se houvesse apenas um produto, com o conseqüente aumento no custo das peças e a necessidade de estoque de uma quantidade maior de material. O esforço para treinar a força de vendas e assistência técnica é maior, aumentando o custo de manutenção e apoio ao cliente. E, por fim, pode-se dificultar a comunicação da melhor solução para o cliente, que terá dúvidas no momento da compra, entre optar por um deles, aumentando desnecessariamente seu desgaste. Tais dificuldades podem levá-lo a optar por um produto de empresa concorrente, que consiga indicar a melhor solução de uma forma mais transparente e direta. A Embraer é um caso de excelência mundial em desenvolvimento de produtos. Um caso de sucesso em A empresa saiu de uma situação financeira complicada para, em poucos anos, se termos de posicionamento: tornar uma das maiores produtoras de aeronaves do mundo. Um dos projetos que o projeto Embraer 170 ajudou a empresa nesta transformação é denominado 170, e seu sucesso está vinculado em grande medida a um trabalho excepcional de posicionamento de produto no mercado. A Figura 4.14 demonstra a situação em termos de capacidade de assentos nas empresas aéreas, colunas em cinza. A região em destaque está vazia por causa da inexistência de aeronaves capazes de voar economicamente com tais números de passageiros. Isto é, os produtos oferecidos pelas empresas aéreas eram muito grandes ou muito pequenos, tornando-os ineficientes em mercados regionais mais aquecidos com o número de passageiros na faixa em destaque. Figura 4.14

A lacuna no número de assentos ocupados no mercado de aviação.

Fonte: Site: http://www.ruleof70to110.com/main/index.html — consultado no dia 18 de janeiro de 2005.

O projeto da família de aviões Embraer 170/190 teve como escopo o atendimento desse mercado regional inexplorado, alcançando enorme sucesso. O fato de ser um projeto totalmente posicionado nesse segmento — e, portanto, com características bem definidas para atender às necessidades desses clientes (diferenciação) — possibilitou uma vantagem enorme para os produtos da família. E, ainda, dificultou a concorrência de grandes empresas do setor, que costumavam comercializar aeronaves maiores ou adaptações desses produtos, geralmente grandes aviões que eram “encurtados”. Sem dúvida, a competência técnica da empresa foi fundamental, afinal, essa oportunidade vislumbrada nunca poderia ter sido explorada sem a competência técnica. Mas o caso demonstra claramente a vantagem que

142

PARTE 2

O Modelo

pode ser obtida de um Plano Estratégico de Produtos bem elaborado, capaz de fornecer um posicionamento preciso do produto no mercado. A definição adequada do Portfólio de Produtos deve garantir um posicionamento ótimo para cada um dos produtos, sendo o elo entre Planejamento Estratégico e o esforço tecnológico para a obtenção de um produto em si. Portanto, além de considerar os critérios de alinhamento com a estratégia, de Considerações a serem maximização de valor e balanceamento do portfólio, discutidos na atividade anterior, tomadas durante a fase de o Time de Planejamento Estratégico de Produtos precisa escolher os produtos, preoproposição de mudanças cupando-se, também, com a estratégia a ser seguida pela linha de produtos em si, isto no portfólio de produtos é, o posicionamento e, conseqüentemente, a diferenciação que será buscada entre cada um deles. O Quadro 4.11, a seguir, apresenta uma lista de possíveis estratégias de produtos que podem ser adotadas. Quadro 4.11

Estratégias para Planejamento do Portfólio de Produtos

As mudanças no portfólio de produtos dependem das análises da estratégia, valor agregado e balanceamento, conforme visto no tópico anterior. Especificamente com relação à estratégia, porém, é comum encontrarmos uma visão simplista com 5 dois tipos genéricos de estratégia: baixo custo e diferenciação. Os consultores Deschamps e Nayak , porém, compilaram um conjunto de 8 estratégias para adição de valor aos produtos. Além do baixo custo e qualidade, são elas:

• Proliferação de produtos: segundo esses consultores, é a estratégia inaugurada pela Sony em equipamentos de áudio e pela Honda em motocicletas no Japão. Trata-se de oferecer ao cliente uma vasta gama de opções, minando a concorrência ao oferecer produtos com posicionamento melhor em todos os segmentos do mercado.

• Valor do dinheiro pago: é a estratégia de criar uma linha de produtos que maximiza o valor do dinheiro pago pelo cliente, isto é, cujo posicionamento visa obter o máximo em termos de valor com o menor custo total de propriedade. Um exemplo famoso é o da Toyota, no segmento de carros de luxo. A estratégia foi oferecer um conjunto de produtos com características de design, acabamento e desempenho compatíveis com os melhores carros de luxo europeus, porém, com custo total de compra e manutenção menores.

• Design: o conceito de design não é simples de definir, mas, para a compreensão desta estratégia, pode ser entendido como as características de comunicação e interface do produto com o cliente, tais como: as mensagens visual, táctil e a ergonomia do produto. Essa estratégia consiste em criar um conjunto de produtos com uma coerência de formas capaz de criar uma imagem distinta no consumidor. Um exemplo é a Harley-Davidson. As formas dos guidões, bancos, acessórios de couro, do escapamento e outros detalhes de comunicação visual e ergonomia, juntos, deram origem a um estilo de produto característico, um novo paradigma de motocicleta, com personalidade própria e que, depois de imitada, deu origem a uma nova categoria de produtos. Outro exemplo foi a Swatch, na área de relógios, que construiu uma imagem clara de comunicação visual inovadora com o uso de cores e elementos gráficos inspirados na arte moderna e formas não convencionais. Existem entusiasmados colecionadores que compram vários produtos da empresa 6 por ano, com formas totalmente distantes do padrão convencional. Para garantir esse alinhamento, a empresa inovou, inclusive, ao ser uma das primeiras a encomendar os projetos gráficos de seus produtos para artistas plásticos renomados. Logicamente que, no caso dessa empresa de relógios suíça, a mensagem não é transmitida unicamente pelo produto, mas passa, ainda, por uma coerência entre o produto e o visual no ponto-de-venda, com projetos de lojas que enfatizam o mesmo atributo da modernidade. Outro exemplo interessante é o da Apple. A empresa possuía um produto com diferencial tecnológico em termos de recursos gráficos, mas vinha perdendo mercado e enfrentava sérios problemas. Ela se recuperou ao lançar a linha de computadores iMAC, que enfatizava esse desempenho superior 7 e diferencial por meio de suas formas. Essa linha foi pioneira ao utilizar plásticos translúcidos, levar ao extremo o uso das formas ovaladas e inovar com a integração entre monitor e CPU em micros portáteis: uma quebra de paradigma. Tais elementos de design criaram uma personalidade própria e ajudaram a transmitir ao cliente a idéia de que se tratava de um produto especial, posicionando-o em uma categoria única no mercado de computadores portáteis, padrão

(continua) 5 6 7

DESCHAMPS, J. P.; NAYAK, P. R. Produtos irresistíveis. São Paulo: Makron Books, 1996. cap. 2. KOTLER (2000, p. 75). KOTLER (2000, p.313).

CAPÍTULO 4

Planejamento Estratégico de Produtos

Quadro 4.11

143

Estratégias para Planejamento do Portfólio de Produtos (continuação)

PC. Nesta estratégia, a empresa precisa definir uma meta clara de identidade que deverá ser compartilhada pelos projetos e a diferenciação que está planejando.

• Inovação: uma outra estratégia possível de produtos é o foco na inovação como diferencial. Nesta estratégia, a empresa define um portfólio capaz de garantir a linha de produtos mais inovadora do mercado, com os produtos mais avançados e sendo pioneira na introdução de inovações tecnológicas. A empresa também planeja o portfólio de forma que os produtos em operação sejam descontinuados mais rapidamente e haja uma proporção alta de projetos com grandes inovações. O exemplo clássico aqui é a 3M, famosa por buscar um direcionamento desse tipo nos produtos com tecnologia adesiva.

• Atendimento: em alguns mercados, o atendimento é o parâmetro mais importante na competição. Nesses casos, uma estratégia de produtos possível é definir um portfólio com produtos posicionados para serem superiores nesse parâmetro. Isso significa a definição das famílias de produtos, adoção de novas tecnologias e modularização, tudo isso visando a manutenabilidade e confiabilidade. Os consultores Deschamps e Nayak citam, como exemplo, os casos da OTIS e da Schindler/Westinghouse na área de elevadores.

• Velocidade: a estratégia de produtos baseada na velocidade é aquela em que o processo de desenvolvimento e o portfólio são planejados de forma a obter desempenho de lead time de desenvolvimento muito superior que o das empresas concorrentes. Trata-se de uma estratégia ampla que pode ser utilizada para diferentes fins. A empresa pode utilizá-la para criar uma diferenciação por quantidade de produtos, lançando maior número de opções (igual à estratégia de proliferação de produtos). Pode-se utilizá-la para adotar uma estratégia seguidora dentro do setor, esperando a concorrência correr os riscos pela inovação e entrando com uma solução mais madura e com ganhos de desempenho no mercado. Pode-se utilizá-la para aumentar os lucros, diminuindo o investimento em marketing. A empresa aproveita o lançamento feito pelo concorrente, e o seu esforço em propaganda, colocando simultaneamente o seu produto no mercado. Trata-se de uma estratégia importante em mercados com tecnologia ainda não madura, nos quais os padrões mudam constantemente e inovações são criadas a todo instante — como o mercado de celular há 10 anos e o mercado atual de desktops e palmtops. Fonte: Essas estratégias de produto foram propostas por DESCHAMPS, J. P.; NAYAK, P. R. Produtos irresistíveis. São Paulo: Makron Books, 1996.

Uma vez entendida a importância do posicionamento e da diferenciação, fica fácil compreender as tarefas que ocorrem na atividade proposição de mudanças no portfólio de produtos. São elas: n n n n n

n

Tarefas da atividade de proposição de mudanças no portfólio de produtos

identificar produtos a serem descontinuados; identificar projetos a serem abandonados e congelados; identificar projetos a serem redirecionados; identificar os novos projetos que deverão ser iniciados; preparar a Minuta do Projeto (minutas de projeto) para cada um dos novos produtos a serem desenvolvidos; e consolidar proposta de novo portfólio de produtos.

A ordem em que essas tarefas foram listadas não corresponde à ordem cronológica de ocorrência. Cada uma delas é uma decisão sobre a lista de produtos e projetos, as quais acontecem de maneira interativa. O Time de Planejamento Estratégico de Produtos poderá realizar isso em uma reunião de trabalho com todos os presentes ou realizar várias reuniões. O ideal é que os participantes tenham tempo para estudar separadamente as informações e se preparar para a reunião trazendo propostas. Cada um dos novos projetos que passarão a integrar o portfólio exige um esforço adicional do time: a preparação da Minuta do Projeto. Esse documento é a primeira definição do projeto, descrevendo as características fundamentais do produto, definindo preço-alvo, líder do time e datas para o início do desenvolvimento e entrega final.

144

PARTE 2

O Modelo

A atividade é finalizada com a consolidação de todas as informações no documento que descreve o novo portfólio de produtos.

4.8

Verificar a viabilidade do portfólio de produtos

Depois de definido o novo portfólio de produtos, o Time de Planejamento Estratégico de Produtos terá uma lista de todos os produtos a serem mantidos no mercado e todos os projetos de desenvolvimento que deverão ser realizados em um determinado horizonte. O próximo passo a ser realizado é avaliar a viabilidade econômica, de recursos e capacitação para a implantação do portfólio planejado, conforme sintetizado na Figura 4.15. Figura 4.15

Resumo da atividade “Verificar a viabilidade do portfólio de produtos”.

As tarefas que precisam ser realizadas são: n

n

n

Avaliar a viabilidade econômica do portfólio de projetos: esta análise pode ser feita criando-se um grande fluxo de caixa com as estimativas iniciais de investimento e retorno financeiro de cada um dos projetos do portfólio. Detalhes maiores sobre como proceder a uma análise de viabilidade econômica serão apresentados nos próximos capítulos. A única diferença em relação à análise econômica de um projeto único é que essa análise é baseada em um fluxo de caixa de todos os projetos e produtos da empresa. É algo raro de ser visto nas organizações dado o grau de dificuldade inerente à quantidade de informações que precisam ser sistematizadas. Espera-se que, no futuro, com o avanço e a integração das ferramentas computacionais de gestão de portfólio, veja o Quadro 2.5, no Capítulo 2 deste livro, a execução desse tipo de análise seja factível para as empresas. Avaliar a viabilidade de obter os recursos para implantação do plano: outra análise importante é a verificação se a empresa ou unidade de negócio possui os recursos financeiros e materiais para a implantação do portfólio. Em caso negativo, essa análise deve resultar na identificação das ações para sua obtenção, tais como: montagem de um determinado tipo de laboratório, bancada de ensaio ou busca de novas verbas para investimentos. Avaliar se a empresa possui todas as competências necessárias: para o desenvolvimento dos produtos, serão necessárias competências que precisam ser dominadas — seja pela própria empresa ou um de seus parceiros estratégicos. No caso do portfólio prever a incorporação de novas tecnologias nos próximos períodos, é fundamental que sejam elaboradas, nessa etapa, ações de aprendizagem que visem a

CAPÍTULO 4

Planejamento Estratégico de Produtos

n

4.9

145

incorporação dessas competências. Tais ações podem ser contratação de pessoal, compra de direitos para o uso de determinadas patentes, parcerias estratégicas e outras conforme listado no Quadro 4.4, anteriormente. Obter consenso sobre a decisão final: enfim tem-se a versão final do novo portfólio de produtos da empresa, montado a partir das discussões do Time de Planejamento Estratégico de Produtos, e que deverá ser implementado por ele. Se o planejamento das atividades dessa fase foi bem elaborado, todas as atividades listadas anteriormente devem ter ocorrido de forma transparente e democrática. Nesse caso, ao atingir-se esse momento há consenso no grupo de que o novo Portfólio de Produtos é o melhor a ser seguido. O Time passa então para uma fase de implantação do Portfólio, na qual há um acompanhamento periódico dos projetos e produtos, promovendo-se atualizações pontuais nessa versão do portfólio. Acompanhar significa verificar o andamento dos projetos por meio dos gates e dar início ao desenvolvimento de novos projetos, conforme previsto no plano. O início de um novo projeto é a próxima e última atividade da fase de Planejamento Estratégico de Produtos.

Decidir o início do planejamento de um dos produtos do portfólio

Esta atividade extremamente simples é a primeira em nosso modelo específica para um determinado projeto de produto — como já discutimos anteriormente Até agora, todas as atividades foram direcionadas para o conjunto de projetos e produtos existentes: o portfólio de produtos. Outra diferença importante é que as atividades anteriores ocorrem em um momento localizado no tempo, enquanto a ocorrência desta atividade depende da programação expressa no portfólio de projeto. A Figura 4.16 ilustra esta atividade que tem como principais informações de entrada o Portfólio de Produtos e o documento Minuta do Projeto. Este último é a proposta de um dos produtos do portfólio, que teve seu início planejado para a data atual. A saída será a Minuta do Projeto aprovada, isto é, referendada pelo Time de Planejamento Estratégico de Produtos, que deverá comunicar essa decisão para o Time de Desenvolvimento e para o gerente de projeto. Figura 4.16

Resumo da atividade “Decidir o início do planejamento do produto”.

146

PARTE 2

O Modelo

Em geral, as atividades anteriores ocorrem um ou dois meses no começo ou final do ano, quando se mobiliza o Time de Planejamento Estratégico em um esforço concentrado para realizar o Planejamento Estratégico de Produtos. Com o plano aprovado, esse time passará a ter as seguintes atribuições: 1) monitorar os projetos e produtos, respectivamente, em desenvolvimento e produção; 2) realizar pequenos ajustes no plano; e 3) dar início formal aos projetos conforme as datas previstas de início do projeto são atingidas. Se um projeto tem seu início marcado para 10 de julho, por exemplo, o time realizará o lançamento formal desse projeto quando essa data chegar. O lançamento formal de um projeto é feito pela assinatura e comunicação do O documento principal: documento Minuta do Projeto e que, no linguajar da Gestão de Projetos (veja Minuta do Projeto o Quadro 4.12). No caso do modelo unificado, são as pessoas que estão assumindo o papel de Time de Planejamento Estratégico de Produtos as responsáveis pela emissão da minuta. O leitor deve se lembrar que a primeira versão da minuta foi preparada durante a atividade 4.7, de proposição de mudanças no portfólio da empresa. Tarefas da atividade de decisão do início do planejamento do produto

Quadro 4.12

Minuta do Projeto

Segundo a teoria de Gestão de Projetos, a Minuta do Projeto, também conhecida pelo termo em inglês Project Charter, é um anúncio único que autoriza formalmente o início de um determinado projeto. Esse documento deve incluir uma descrição mínima do projeto, do produto que será desenvolvido e da pessoa responsável pelo trabalho de preparação da Declaração de Escopo desse projeto. É importante que esse documento seja emitido por uma pessoa com um nível adequado de decisão, isto é, que tenha o poder para autorizar o projeto. É um documento importante, mas, não significa que deva ser complexo e ser enviado a todas as pessoas envolvidas em decisões importantes sobre os projetos desenvolvidos na empresa.

O Time de Planejamento Estratégico de Produtos revisará a Minuta do Projeto para incorporar possíveis alterações no portfólio entre o tempo de sua primeira versão e o momento atual. Terá também a adição do nome da pessoa que assumirá o papel de gerente de projeto. Esse ator é fundamental no processo de desenvolvimento de produto. Desse momento em diante, coordenará as atividades da fase final do pré-desenvolvimento e todas as fases do desenvolvimento de produtos. Outro aspecto que deve ser notado é que a Minuta do Projeto contém a primeiA Minuta do Projeto ra definição do que é o produto. Essa definição será ampliada com novos detalhes na contém a primeira fase de Planejamento do Projeto, dando origem ao Escopo do Produto. Em seguida, definição do produto, que na fase de projeto informacional, esse escopo será esmiuçado e, novamente detaserá continuadamente lhado, dará origem aos requisitos do produto e especificações-meta. Estas, por sua aprimorada até o final do vez, serão transformadas em soluções técnicas e concepções na fase de projeto condesenvolvimento ceitual e, por fim, o produto e os processos de fabricação estarão completamente definidos, em inúmeros documentos contendo descrições técnicas de cada peça e processo de fabricação. Essa é uma característica de projetos de desenvolvimento, que são evolucionários. O produto vai sendo continuamente definido e detalhado até que possa ser fabricado.

4.10 Questões e atividades didáticas propostas 1. Escolha uma empresa que desenvolva produtos e que você (ou seu grupo) tenha acesso às pessoas responsáveis pelo processo de desenvolvimento de produtos. Peça que elas descrevam todas as atividades até o momento da escolha e realização da primeira definição de um determinado produto para ser projetado. Em seguida, compare com as atividades do modelo apresentadas no livro e responda: (a) os projetos de novos produtos são escolhidos conforme a estratégia da empresa? (b) cite os prós e os contras da sistemática adotada pela empresa.

CAPÍTULO 4

Planejamento Estratégico de Produtos

147

2. Por que é tão importante que a definição do portfólio de produtos esteja relacionada com a estratégia de negócios da empresa? Cite os problemas que podem acontecer caso essa ligação seja fraca. 3. Qual a relação entre Estratégia de Produto, Portfólio de Produtos e a Minuta do Projeto? 4. Quais são as vantagens de atribuir a um comitê a tarefa de escolha do portfólio de produtos da empresa? 5. Por que o esforço necessário para a revisão de um Plano Estratégico de Negócios pode variar de período a período? 6. Quais os cuidados básicos que devem ser tomados no planejamento de reuniões de trabalho? 7. Procure na Internet, em livros e artigos de seriados e periódicos exemplos de resultados de pesquisas de mercado baseadas em cada um dos seguintes tipos de fonte: a. Secundárias i. Registros Internos ii. Dados publicados de uso comum iii. Dados padronizados de marketing b. Primárias i. Pesquisa qualitativa ii. Pesquisa quantitativa iii. Experimentos 8. Escolha um produto ou uma classe de produtos como exemplo, tais como: ferramentas elétricas, colas, entre outros. Entre no site do Instituto Nacional de Propriedade Industrial (http://www.inpi.gov.br) e faça uma busca nas bases de marcas, patentes e desenhos industriais, relacionados com o produto escolhido. 9. Defina Gerenciamento de Portfólio. Quais são as metas principais do gerenciamento de portfólio? 10. Quais os três tipos de técnicas para gestão de portfólio? Descreva-os. 11. A tabela a seguir apresenta uma lista de projetos contendo algumas informações. Identifique o melhor projeto empregando a técnica do Valor Econômico Esperado. Quais as vantagens e desvantagens da técnica do Valor Econômico Esperado?

Nome do Projeto

Custo de Valor Presente Total investido Desenvolvimento Líquido (R$) (R$) (R$) VPL TI CD

Custo de Comercialização (R$) CC

Probabilidade de Sucesso Técnico (%) Pst

Probabilidade de Sucesso Comercial (%) Pst

Produto A (Incremental)

1.000.000,00

40.000,00

30.000,00

10.000,00

88

86

Produto B (Inovação no processo)

3.000.000,00

300.000,00

150.000,00

150.000,00

76

64

30.000.000,00

800.000,00

600.000,00

600.000,00

40

74

100.000,00

20.000,00

5.000,00

5.000,00

20

70

5.000.000,00

600.000,00

400.000,00

400.000,00

52

100

Produto C (Nova plataforma) Produto D (Pequeno Projeto) Produto C (Redesenho para inclusão de Nova Funcionalidade)

12. Desenhe Gráficos de Bolha para os projetos apresentados na listagem da questão anterior e, observando a análise realizada, responda: Quais projetos você cancelaria? É importante ter projetos em todos os quadrantes do diagrama? Explique.

148

PARTE 2

O Modelo

13. Faça uma lista com possíveis critérios para análises de portfólio baseada em modelos de notas. Liste no mínimo sete critérios. 14. Visite uma empresa e entreviste o gerente de desenvolvimento de produtos para conhecer a lista de produtos da empresa. Em seguida, crie uma planilha Excel que auxilie na análise de portfólio de produtos, combinando as técnicas apresentadas no texto. 15. Forme um grupo com três alunos. Escolha um tipo de produto e faça um levantamento das linhas de produto, classificando-as em segmentos e posicionamentos distintos. Utilize catálogos disponíveis nos sites de empresas que atuam na área. Sugestões de tipos de produtos

Empresa

Site

Linha Branca no Brasil

Brastemp

http://www.brastemp.com.br/

Electrolux

http://www.electrolux.com.br/index.asp

Enxuta

http://www.enxuta.com.br/

Pentax

http://www.pentax.com/products/cameras/

Sony

http://www.sony.com

Nikon

http://www.nikonusa.com/usa_home/home.jsp

Sigma

http://www.sigmaphoto.com/

Xerox

http://www.xerox.com.br/

HP

http://www.hp.com/country/bz/por/welcome.htm

Minolta

http://www.minolta.com.br/

Máquinas Fotográficas

Copiadoras

16. O que é a Minuta do Projeto? Qual a sua importância para o processo de desenvolvimento de produtos? 17. Que cuidados devem ser tomados na preparação da Minuta do Projeto?

4.11 Informações adicionais AAKER, D.; KUMAR, V.; DAY, G. S. Pesquisa de marketing. São Paulo: Atlas, 2001. CLARK, K. B.; FUJIMOTO, T. Product development performance: strategy, organization and management in the world auto industry. Boston, Mass.: Harvard Business School Press, 1991. COOPER, R. G.; EDGETT, S. J.; KLEINSCHMIDT, E. J. Portfolio management for new products. Massachussets: Perseus Books, 1998. DECHAMPS, J. P.; NAYA, P. R. Produtos irresistíveis. São Paulo: Markron Books, 1997. KIDDER, L. H.; JUDD, C. M. Research methods in social relations. 5. ed. New York: Holt, Rinehart and Winston, CBS College Publishing, 1986. KOTLER, P. Administração de marketing: a edição do novo milênio. São Paulo: Prentice Hall, 2000. OPPENHEIM, A. N. Questionnaire design, interviewing and attitude measurement. New York: Continuum, 2001. PAHL, G.; BEITZ, W. Engineering Design a systematic approach. Springer: Verlag, 1993. PMI Standards Committee. Project Management Body Of Knowledge. Pennsylvania: Project Management Institute Publications, 2000. Disponível em: . Acesso em: 20 mar. 2005. PUGH, S. Total design: integrated methods for successful product engineering. Addison Wesley, 1991. REA, L. M.; PARKER, R. Metodologia de pesquisa: do planejamento à execução. São Paulo: Pioneira, 2000. ULRICH, K.T.; EPPINGER, S. D. Product design and development. USA: McGraw-Hill, 1995. WHEELWRIGHT, S. C. CLARK, K. B. Revolutionizing product development process: quantum leaps in speed, efficiency, and quality. New York: The Free Press, 1992.

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 5.19 5.20

Sumário Definir interessados do projeto Definir escopo do produto Definir escopo do projeto Detalhar o escopo do projeto Adaptar o modelo de referência Definir atividades e seqüência Preparar cronograma Avaliar riscos Preparar orçamento do projeto Analisar a viabilidade econômica do projeto Definir indicadores de desempenho Definir plano de comunicação Planejar e preparar aquisições Preparar plano de projeto Avaliar fase Aprovar fase Resumo do capítulo Questões e atividades didáticas Informações adicionais

5. Planejamento do Projeto PARTE 2 O Modelo Planejamento do Projeto

Depois da leitura deste capítulo, você será capaz de: l

l

l

l

l

l

l

l

Identificar na empresa quem são os maiores interessados com o projeto de produto, relacionando suas necessidades, limitações, e potencial de envolvimento com o projeto. Definir o escopo do produto e do projeto, buscando uma clara compreensão do que será fornecido ao cliente e como será obtido. Adaptar o modelo de referência adotado pela empresa, para que seja utilizado em um projeto específico. Definir quais as atividades, o cronograma e os recursos necessários para realização do projeto. Elaborar um plano de gestão de riscos do projeto. Realizar a análise da viabilidade econômico-financeira, estimando as perspectivas de desempenho financeiro do produto resultante do projeto. Planejar os indicadores de desempenho que serão empregados no acompanhamento e avaliação das cinco fases do desenvolvimento do produto, durante a execução do projeto. Planejar o gerenciamento das comunicações no projeto e das aquisições do que será necessário adquirir para a realização do projeto.

150

5.1

PARTE 2

O Modelo

Sumário

A fase de planejamento do projeto finaliza a macrofase de pré-desenvolvimento, o que pode ser visualizado no destaque em cinza-escuro da Figura 5.1. Figura 5.1

Localização das fases do pré-desenvolvimento dentro do Processo de Desenvolvimento de Produtos unificado.

A fase de Planejamento Estratégico de Produtos, veja o Capítulo 4, transformou informações advindas do Planejamento Estratégico da Corporação e do Planejamento Estratégico da Unidade de Negócios em um portfólio de projetos e produtos da empresa. Nessa fase, realiza-se o planejamento macro de um dos projetos de novo produto planejados no portfólio, aquele aprovado pelo Time de Planejamento Estratégico de Produtos na última atividade da fase anterior. O planejamento tem início assim que um projeto específico é formalmente iniciado. Deve-se lembrar que esse momento foi previsto no portfólio de produtos e a comunicação é feita pelo Time de Planejamento Estratégico de Produtos. A comunicação deve ser feita para todas as áreas ligadas diretamente com o desenvolvimento de produtos, em especial, para o coordenador dessa atividade. Objetivo do Planejamento do Projeto

O resultado final é o Plano de Projeto do Produto que, demonstrando-se viável, será utilizado como guia para a próxima macrofase de Desenvolvimento do Produto. Como já ressaltado no Capítulo 2, a importância do pré-desenvolvimento reside no planejamento sistemático dos projetos, pois, ao permitir uma boa previsão e análise do seu escopo e riscos, previne problemas que poderiam ocorrer quando da realização efetiva do projeto no desenvolvimento do produto. As atividades do Planejamento do Projeto, de forma genérica, devem empreender esforços no sentido de identificar todas as atividades, recursos e a melhor forma de integrá-los para que o projeto siga em frente com o mínimo de erros. Compatível com as preocupações levantadas no Capítulo 1 a respeito dessas informações, o planejamento deve prever as necessidades de integração de informações e decisões entre as áreas funcionais e outros projetos da empresa, contribuindo para a melhor coordenação e comunicação no projeto.

CAPÍTULO 5

Planejamento do Projeto

151

A visão e a efetividade com que a empresa e seu Processo de Desenvolvimento de Produtos (PDP) tratam da questão do gerenciamento multiprojetos, conforme destacado no Capítulo1, terá significativo impacto na concepção e administração do portfólio de projetos/produtos da empresa, com conseqüente reflexo no Planejamento do Projeto. Esses reflexos referem-se tanto ao planejamento de colaborações entre pessoas e tecnologias nos diferentes tipos de projetos em andamento (plataformas, derivações etc) no PDP da empresa, como, também, ao planejamento das combinações entre os diferentes arranjos organizacionais possíveis no PDP da empresa, para conduzir a execução desses projetos. O plano do projeto é um documento que agrupará informações relevantes para O resultado da fase a execução do projeto. Essas informações são, como já mencionado no Capítulo 2: escopo do projeto, escopo do produto (conceito do produto), previsões das atividades e sua duração, prazos, orçamento, definição do pessoal responsável, recursos necessários para realizar o projeto, especificação dos critérios e procedimentos para avaliação da qualidade (assim como possíveis normas que precisam ser atendidas), análise de riscos e indicadores de desempenho selecionados para o projeto e produto (com seus valores-alvo). Dada a ligação imediata com a macrofase seguinte, a elaboração desse plano precisa considerar o escopo e as características de cada uma das cinco fases do desenvolvimento do produto: projeto informacional (gera especificações-meta), projeto conceitual (as concepções do produto), projeto detalhado (especificações finais), preparação da produção (liberação da produção) e lançamento do produto. Essas fases farão uso do plano do projeto, atualizando-o no início de cada fase, na atividade genérica de “atualizar plano do projeto”, descrita no Capítulo 3, Tópico 3.1. A Gestão de Projetos é uma área do conhecimento que estuda as ferramentas e Os conhecimentos da área as melhores práticas para o gerenciamento de qualquer tipo de projeto, desde a imde Gestão de Projetos são plantação de um novo serviço de manutenção elétrica, a organização de um evento, fundamentais incluindo o projeto de novos produtos, conforme pode ser observado no Quadro 5.1. O planejamento é uma das etapas principais da gestão de um projeto e, por isso, as atividades dessa fase estão fortemente relacionadas com essa área do conhecimento. Os conhecimentos, métodos e técnicas propostos pelos pesquisadores e profissionais da área devem, portanto, ser utilizados. O modelo unificado descreve a aplicação desses conceitos especificamente para o projeto de produtos físicos, o que significa que a escolha e a combinação das técnicas foi elaborada para esse tipo específico de projetos.

Quadro 5.1

Gestão de Projetos

Um projeto pode ser entendido como um empreendimento com começo, meio e fim bem definidos, seguindo a orientação do plano estratégico da empresa, e com o objetivo claro de criar um produto ou serviço bem delimitado. A Gestão de Projetos é, portanto, a forma com que esse empreendimento é conduzido dentro da empresa. Sua preocupação é com a otimização da realização das atividades e com o emprego dos recursos, ambos devidamente integrados, pelas pessoas que formam a equipe de projeto. Essa gestão deve estar preparada para mudanças que podem ocorrer no contexto em que o projeto está inserido, para que ele atinja desempenho igual, ou melhor, ao originalmente previsto. Em geral, a Gestão de Projetos deve ser realizada ao longo de todas as três etapas básicas de um projeto: desde seu planejamento, passando pela execução propriamente dita, até chegar a seu encerramento, quando são registrados os resultados atingidos pelo projeto e as lições aprendidas. O Project Management Institute (PMI) define cinco processos, conjuntos de atividades da gestão de projetos, conforme apresenta a Figura 5.2. Ao longo dessa gestão, é necessário o estabelecimento de controles e avaliações periódicas para o acompanhamento do projeto, e a constante busca de equilíbrio entre requisitos muitas vezes conflitantes, como a duração do projeto, os seus parâmetros de qualidade, e os recursos necessários, além dos diferentes interesses e necessidades dos vários atores envolvidos, tais como os clientes, os fornecedores, demais setores da empresa, dentre outros.

(continua)

152

PARTE 2

Quadro 5.1 Figura 5.2

O Modelo

Gestão de Projetos (continuação) Processos da Gestão de Projetos.

Fonte: PROJECT MANAGEMENT INSTITUTE(2000)

Uma completa Gestão de Projetos deve gerenciar de forma integrada vários conhecimentos, em que se destacam, segundo o Project Management Body Of Knowledge (PMBOK): o escopo, tempo, custo, qualidade, recursos humanos envolvidos, as comunicações do projeto, a gestão de riscos, as aquisições externas da empresa e a integração de todas essas áreas. Dada essa diversidade de assuntos envolvidos, é recomendável que a Gestão de Projetos relacione-se com outras disciplinas e práticas da administração. Fonte: PMI Standards Committee. Project Management Body Of Knowledge. Pennsylvania: Project Management Institute Publications, 2000. Disponível em: . Acesso em: 20 de março de 2001.

Um projeto, no contexto do PDP, significa seguir e interpretar esse processo de forma única e temporária, visando criar um novo produto. É única porque esse produto desenvolvido será de alguma forma diferenciado em relação aos outros produtos do portfólio da empresa, e seguiu um caminho único em seu desenvolvimento, embora orientado por um processo de desenvolvimento de produtos (DP) — que é o mesmo que orienta todos os demais produtos do portfólio. É temporário, pois o projeto deve ter um começo, meio e fim definidos. Essas características de unicidade e temporalidade do projeto trazem implicações em seu planejamento e gestão. Um projeto de DP deve ser planejado para aproveitar adequadamente um intervalo de tempo propício ao lançamento de um novo produto, pois, passado esse tempo, perde-se a oportunidade de mercado para isso. Durante o tempo de realização do projeto, deve ser previsto o envolvimento parcial ou integral das pessoas na equipe que o executará, e que, ao final, serão realocados em outros projetos ou trabalhos. As particularidades de cada projeto de produto, mesmo que seguindo o PDP padrão da empresa e sendo similar a outros projetos de DP, certamente exigirão habilidades particulares e que devem ser planejadas tanto quanto possível. No Capítulo 2, foi feita uma discussão detalhada desse aspecto, mas é importante aqui demonstrar as implicações em seu planejamento e gestão. Um projeto de DP deve ser planejado para aproveitar adequadamente um intervalo de tempo propício ao lançamento de um novo produto, pois, passado esse tempo, a oportunidade de mercado pode ser “perdida”, isto é, mudanças no ambiente podem torná-lo inviável. Durante o tempo de realização do projeto, deve ser previsto o envolvimento parcial ou integral das pessoas na equipe que o executará, e que, ao final, serão realocados em outros projetos ou trabalhos. Diferenças nas características do projeto e do processo certamente exigirão habilidades particulares e que devem ser planejadas tanto quanto possível.

CAPÍTULO 5

Planejamento do Projeto

153

A pessoa que coordenará todo o Planejamento do Projeto, e executará praticaQuem participa e quais são mente todas as atividades dessa fase, deve ser a mesma que exercerá o papel de gerente os responsáveis pelo de projeto, isto é, a pessoa que estará também na coordenação do time durante a maPlanejamento do Projeto? crofase de desenvolvimento. Essa característica do modelo é intencional e serve para garantir um bom fluxo de informações e aumentar o comprometimento da equipe. Por melhor que seja a qualidade dos documentos gerados nessa fase, se o gerente de projeto for uma pessoa diferente da que elaborou o plano, uma quantidade significativa de informação não explícita e conhecimentos tácitos serão perdidos. Além disso, uma pessoa distinta não teria o mesmo comprometimento. Isso vale para qualquer atividade de planejamento. Quando planejador e responsável por execução são a mesma pessoa, o cuidado na elaboração é maior. A pessoa só recomendará a aprovação se tiver consciência de que o Plano de Desenvolvimento de Produtos é viável, pois, caso contrário, é ele próprio quem sofrerá as conseqüências no futuro como gerente do projeto. Apesar de a nomeação do gerente de projeto acontecer nessa fase, não é necessária a nomeação do Time de Desenvolvimento. O planejamento, para a maioria dos projetos de desenvolvimento de produtos, pode ser realizada pelo gerente de projeto isoladamente, sem comprometer horas de trabalho de outras pessoas do time. Logicamente, o gerente de projeto poderá necessitar da ajuda de uma quantidade grande de especialistas para realizar as atividades, especialistas em finanças, técnicos, em vendas etc. Eles deverão fornecer estimativas de natureza diversa, fundamentais para o bom planejamento, como horas necessárias para realizar determinadas tarefas. Em casos especiais como produtos de grande porte, navios, aviões, projetos de novas plataformas de automóveis mundiais com várias versões e outros, a complexidade do planejamento, seja em termos de quantidade de recursos — como a logística para integração —, poderá exigir que o planejamento seja realizado por uma equipe específica. Nesse caso, essa equipe poderá ou não ser a mesma que realizará o projeto posteriormente. É comum também a existência de áreas funcionais especializadas em planejamento, cuja função é apoiar o gerente de projeto, que são os chamados escritórios de projeto (veja o Quadro 5.2). Quadro 5.2

Escritório de Projetos

É uma estrutura organizacional específica que realiza serviços de suporte para o gerenciamento dos projetos da empresa. Conhecido também como: Comitê Diretor de Projetos, Coordenação de Projetos, Escritório de Apoio a Projetos, Grupo de 1 Apoio à Gerência de Projetos, entre outros nomes. Segundo Valeriano, um escritório de projetos pode receber diferentes atribuições, conforme o nível de evolução da empresa em termos de maturidade da Gestão de Projetos. Essas atribuições são: 1) Para um estágio inicial: prestação de serviços de controle de prazos e custos; elaboração de relatórios multiprojetos e interdepartamentais; treinamento em aspectos específicos de gerenciamento de projeto; ligações com gerentes departamentais; melhoria contínua de processos de gerenciamento de projeto; e registro de lições aprendidas. 2) Estágio Intermediário: arquivo do histórico de projetos; administração dos processos de gerenciamento de projeto; consultoria interna sobre gerenciamento de projeto; desenvolvimento e aperfeiçoamento de métodos e padrões; e apoio a reuniões de avaliações e revisões de projetos. 3) Para um estágio avançado: distribuição de recursos de acordo com prioridades estabelecidas;

(continua) 1

VALERIANO (2000).

154

PARTE 2

Quadro 5.2

O Modelo

Escritório de Projetos (continuação)

avaliação externa de projetos; formação de gerentes de projeto; e gerência direta de grandes projetos da organização. Fonte: VALERIANO, D. L. Gerenciamento estratégico e administração por projetos. São Paulo: Makron Books, 2001.

As atividades realizadas nesta fase e a relação entre elas são representadas na Figura 5.3. O Planejamento do Projeto recebe informações do portfólio de produtos e projetos e, em especial, aquelas provenientes da proposta do produto (Minuta do Projeto). Como resultado, o Plano do Projeto apresenta informações relativas às declarações de escopo de produto e de projeto, às atividades e suas previsões de duração, aos orçamentos, recursos e pessoal necessários para a execução do projeto, às possibilidades de riscos e aos indicadores de desempenho que devem ser empregados. Os nomes das atividades, técnicas e métodos foram escolhidos tendo-se como referência principal o PMBOK (livro ou conjunto de conhecimentos em gerência de projetos)2 do PMI, com pequenas alterações para adequá-los. Essa associação de profissionais de Gestão de Projetos vem organizando e sistematizando os conceitos e técnicas da área e, tornando-se um padrão largamente adotado pelos profissionais de Gestão de Projetos de diferentes domínios. Com isso, espera-se facilitar a compreensão do modelo. Resumo das atividades realizadas na fase de Planejamento do Projeto

Figura 5.3

2

Informações principais e dependências entre as atividades da fase de Planejamento do Projeto.

PMI Standards Committee. Project Management Book of Knowledge. Pennsylvania: Project Management Institute Publications, 2000. Disponível em: . Acesso em: 20 de março de 2005.

CAPÍTULO 5

Planejamento do Projeto

5.2

155

Definir interessados do projeto

Essa atividade, cuja síntese é apresentada na Figura 5.4, trata da definição dos interessados no projeto, que são os indivíduos e as organizações envolvidos diretamente e também aqueles que, de alguma forma, serão afetados por sua existência. Esses agentes ou atores podem manifestar ou sofrer influências relativas ao projeto tanto ao longo de seu planejamento, como em sua realização e mesmo após sua conclusão. Cabe a presente atividade identificar essas partes envolvidas, e entender suas necessidades, limitações e o tipo de envolvimento que terão com o projeto, de forma que as demais atividades do planejamento e execução do projeto façam adequado uso dessa informação. Figura 5.4

Atividade de definição dos interessados do projeto.

Em um projeto de DP típico, existem algumas partes principais envolvidas: os membros da equipe; o gerente ou líder do projeto; os múltiplos clientes do projeto (produto); a organização executora e financiadora; os fornecedores diversos (de serviços para o projeto, e de serviços e componentes para a manufatura do produto e sua posterior pós-venda). Viabilizar o trabalho dessas partes ou interessados requer algumas ações de planejamento organizacional, montagem e desenvolvimento da equipe, que são as principais tarefas da presente atividade. Essas ações orientam-se por certas habilidades genéricas da administração, como a capacidade de liderança, comunicação, negociação, delegação, motivação, desenvolvimento de equipe e tratamento de conflitos, dentre outros temas relacionados ao tratamento de pessoas e gerenciamento de equipes de projeto na organização. A gestão dos interessados do projeto deve também considerar certas características inerentes ao projeto e que afetam significativamente as pessoas e equipes com ele envolvidas: n

n

projetos são temporários e, portanto, predominam as relações transitórias entre os envolvidos com sua execução; e as partes envolvidas, e sua intensidade de envolvimento, alteram-se ao longo do projeto.

156

PARTE 2

O Modelo

A determinação das responsabilidades e nível de dedicação (esforço alocado no projeto) de cada participante é feita no planejamento organizacional, que deve ocorrer logo no início do projeto. Esse planejamento já deve prever o envolvimento ao longo do projeto tanto dos atores internos à organização, provenientes de áreas funcionais — como engenharia, marketing etc. —, como também de colaboradores externos, como a participação de fornecedores e de outros parceiros estratégicos ao longo do DP (na presente atividade, uma das preocupações é o pré-estabelecimento de parcerias estratégicas). Planejamento organizacional dos interessados do projeto

Quadro 5.3

Participação de Fornecedores no PDP

No Capítulo 2, Tópico 2.10, foram apresentados os diferentes tipos de envolvimento dos fornecedores em projeto de desenvolvimento. Nessa atividade, devem ser identificados os fornecedores de nível maior de envolvimento no Processo de Desenvolvimento de Produtos. Tal qual os demais interessados, será preciso definir claramente suas responsabilidades no projeto. Por exemplo, pode-se identificar que o fornecedor de um determinado subsistema tem maior competência na tecnologia do que a empresa, possui um bom histórico de relacionamento, garantindo níveis suficientes de confiança e sigilo, e comprometimento de longo prazo. Nesse caso, ele poderá já ser escolhido para participar no projeto como co-desenvolvedor (veja a Figura 5.5), atribuindo desde já a responsabilidade pelo subsistema. Nesse caso, ele poderá dar início às negociações para obter uma confirmação do interesse da empresa e obter uma primeira proposta de orçamento. Se ele for um co-desenvolvedor do tipo parceiro, irá se comprometer com a nomeação de um engenheiro residente que fará parte do Time de Desenvolvimento, iniciando sua atuação na próxima fase, Planejamento do Projeto. Outra possibilidade é o fornecedor que entrega um subsistema importante, mas com interface padronizada, isto é, trata-se de um fornecedor de serviços. Ele é um fornecedor importante e sua competência será essencial para o sucesso do produto, mas, nesse caso, não precisará participar da equipe do projeto. O gerente de projeto especificará no plano que o fornecedor será escolhido no projeto detalhado (veja a Figura 5.5), mas não precisará se preocupar com contratos e decisões legais nesse momento. Ele será também o co-desenvolvedor e será escolhido durante a fase de projeto conceitual, quando a equipe de projeto irá lhe transmitir um conjunto de requisitos do produto definidos pelo time de projeto. O caso de menor interação é aquele no qual o fornecedor é responsável por produtos padronizados. Esses fornecedores não precisam ser identificados nessa fase também. Eles só serão escolhidos no momento de preparação da produção, pois a sua escolha dependerá principalmente dos critérios custo e entrega. Figura 5.5

Possibilidade de envolvimento dos fornecedores no PDP.

(continua)

CAPÍTULO 5

Planejamento do Projeto

Quadro 5.3

157

Participação de Fornecedores no PDP (continuação)

O parceiro de tecnologia auxilia no desenvolvimento da tecnologia, processo paralelo ao PDP. Eventualmente, ele pode ser consultado na definição do portfólio de produtos para que seja verificado se uma tecnologia está madura o suficiente para ser utilizada. Pode também participar da concepção, apoiando o time na primeira aplicação da tecnologia. O parceiro de risco geralmente precisa ser consultado desde a proposta do projeto e, neste caso, estaria acompanhando o trabalho atual do Gerente de Projeto. Sem o seu aval, a Proposta de Projeto não poderá ser encaminhada. Além disso, ele deve participar do planejamento de todo o projeto. Enfim, a participação de cada diferente tipo de fornecedor será iniciada em fases distintas, conforme sua responsabilidade dentro do projeto. Os fornecedores de maior interação (Parceiros de Tecnologia, Risco e Co-Desenvolvedores de maior envolvimento) terão que ser identificados nessa fase, e suas responsabilidades e nível de dedicação deverão ser claramente estabelecidos no escopo do projeto como interessados.

As informações necessárias para a realização do planejamento organizacional são basicamente dos seguintes tipos: das interfaces do projeto com outras entidades (unidades, setores etc.) da empresa; do perfil do pessoal envolvido quanto as suas habilidades; e das restrições das opções organizacionais do projeto, tais como: o tipo de estrutura organizacional da empresa, que pode ser mais ou menos favorável à Gestão de Projetos; os acordos trabalhistas, que podem dar maior ou menor possibilidade de alocação dos empregados da empresa em estruturas flexíveis voltados ao DP etc. Essas informações devem ser processadas a fim de constituir o planejamento organizacional do projeto, e, para isso, alguns procedimentos podem ser empregados. Um dos principais é tomar como base outros projetos bem-sucedidos da empresa, adaptando ao atual projeto a forma com que foram organizados as responsabilidades e relacionamentos, com base nessas novas informações. Outros procedimentos envolvem inspirar-se nas melhores práticas de gerenciamento de recursos humanos em diferentes setores da empresa e também na ampla literatura sobre teoria organizacional, de onde se podem derivar propostas de responsabilidades e relacionamentos para as atividades do projeto. Como resultados desse planejamento organizacional têm-se: n

n

n

n

as atribuições dos papéis e responsáveis pelas atividades do projeto, nas cinco fases do desenvolvimento do produto (do projeto informacional ao lançamento do produto) — portanto, essas responsabilidades variam ao longo do tempo de execução do projeto e devem estar ligadas ao detalhamento do escopo dessas atividades; um plano de gerenciamento do pessoal envolvido com o projeto, que descreve quando (ao longo da execução do projeto) e como (em que partes das atividades, com quais outras pessoas e recursos) os colaboradores serão alocados e retirados do time de projeto de DP; o organograma do projeto, um tipo de representação gráfica que ilustra os papéis e responsáveis pelas atividades do projeto além de seus relacionamentos; e outros detalhes para dar apoio a esse planejamento organizacional dos interessados do projeto, que normalmente incluem: avaliações de impacto nos recursos humanos da organização em razão do planejamento adotado; descrições das responsabilidades especificadas pelo planejamento; descrição do nível de dedicação de cada pessoa; e necessidades de treinamentos de pessoal.

Realizado o planejamento organizacional, a tarefa seguinte é a montagem da Montagem da equipe equipe que será responsável pelo projeto de DP, a qual exercerá o papel de Time de (time de desenvolvimento) Desenvolvimento especificado no modelo. A seleção daqueles que farão parte dessa equipe baseia-se no plano de gerenciamento do pessoal envolvido com o projeto e nas características do quadro de pessoal disponível na empresa, particularmente nas áreas e departamentos envolvidos com o DP. Verificar essas características envolve: analisar a experiência anterior de indivíduos e grupos em outros projetos, os interesses dessas pessoas e grupos em parti-

158

PARTE 2

O Modelo

cipar do atual projeto, suas afinidades para trabalhar em um mesmo time ou equipe, a disponibilidade dessas pessoas e grupos ao longo do projeto, e a compatibilidade entre as demandas do projeto com as competências e habilidades dessas pessoas. Essas informações quanto ao mapeamento dos recursos humanos, que se deseja façam parte do time de projeto de DP, servem de base para que se negocie com outras instâncias da empresa a necessária alocação do pessoal no projeto. Geralmente, o gerente de projeto negociará diretamente a equipe com as pessoas que assumem o papel de Time de Planejamento Estratégico de Produtos. Esse time possui a visão da estratégia da empresa e dos comprometimentos dos recursos nos diversos projetos em andamento, as quais são as bases para o projeto de desenvolvimento. Em casos extremos, podem ser necessárias negociações com a alta cúpula da empresa, que deve possuir a visão estratégica das prioridades da empresa em termos de produtos a serem lançados no mercado e, portanto, podem melhor intermediar as diferentes e, por vezes, conflitantes necessidades de pessoal. Deve ser buscado um equilíbrio nas disputas por recursos humanos entre os gerentes dos projetos de DP em andamento na empresa, e desses com os gerentes funcionais que naturalmente olham primeiro as necessidades de suas áreas ou departamentos. Uma negociação bem conduzida e transparente, ouvindo e discutindo com todos os interessados, permitirá a constituição de um time ou equipe de projeto estável. Isso minimiza conflitos dentro do projeto e com outros projetos e áreas funcionais, reduzindo alocações inadequadas de pessoas no projeto e os riscos de perdas de pessoal para outros projetos ou áreas funcionais, em trocas não previstas de pessoal ao longo do projeto. A finalização da montagem da equipe ou time de projeto do DP ocorre com o encerramento das negociações, quando é esperada a definição de quais as pessoas e grupos efetivamente farão parte do projeto ao longo do seu andamento, e, dentre essas, quais ficarão em alocação integral ou parcial. Ao longo de toda a execução do projeto, é necessário que se busque um conDesenvolvimento da tínuo aprimoramento e desenvolvimento, no sentido do trabalho efetivo em time equipe para a execução ou equipe, de forma que as partes envolvidas percebam e sintam que suas contribuido projeto ções individuais se encaixam em um todo maior e integralmente constituído, dado pelo esforço conjunto da equipe no projeto de DP. A verificação de como o efetivo desenvolvimento do trabalho em equipe está ocorrendo pode ser feita mediante certas comparações. As características esperadas de competência individual e para o trabalho em equipe — tendo-se como base os históricos a esse respeito em projetos anteriores dos membros alocados no projeto — podem ser comparadas com o desempenho desses participantes na execução individual e em equipe das atividades do plano do projeto atual, em consonância com o plano de gerenciamento do pessoal. Além disso, a equipe do projeto pode periodicamente se auto-avaliar em termos de trabalho individual e em equipe, comparando-se com o que foi realizado nesses quesitos em outros projetos, além de receberem avaliações independentes a esse respeito, de pessoas externas ao projeto. Para fomentar o desenvolvimento do trabalho em equipe, algumas ações são recomendadas e podem ser planejadas para ocorrer ao longo do projeto. Envolve essencialmente a criação de condições facilitadoras para melhorar o relacionamento entre os membros da equipe, como a oportunidade de participação coletiva em momentos de decisões no projeto, uma cultura de gestão do projeto que busca reconhecimento e recompensa aos participantes que consigam equilibrar contribuições individual e coletiva ao projeto, a alocação da maioria dos participantes do projeto em um espaço físico próximo, a realização de reuniões presenciais regulares para estimular a atualização coletiva, programas de treinamento formais e capacitação dos membros do projeto que priorizem a execução do trabalho em equipe etc.

5.3

Definir escopo do produto

A primeira atividade de planejamento a ser executada pelo gerente de projeto será estudar e detalhar as definições básicas do produto, definidas na Minuta do Projeto. O resultado final será um documento que sintetiza as características e funções do produto, o Escopo do Produto. A Figura 5.6 resume a atividade.

CAPÍTULO 5

Planejamento do Projeto

Figura 5.6

159

Atividade de definição do escopo do produto.

O documento Escopo do Produto (a saída na Figura 5.6) é composto por uma lista das características e funções que o produto deverá apresentar, e que o respectivo projeto deverá criar. Elas se relacionam diretamente com as características do projeto, mas o gerente de projeto não irá se preocupar com elas nesse momento (veja o Quadro 4.4). A idéia implícita no modelo é a de trabalhar sistematicamente, entendendo, primeiro, qual o produto que se espera criar com o projeto; antes de investir tempo no “como”, isto é, na definição das estratégias para o desenvolvimento do projeto, assunto esse que deverá ser tratado na próxima atividade. Quadro 5.4

Escopo do Produto versus Escopo do Projeto

Em projetos de desenvolvimento de produtos, devemos tomar bastante cuidado para nunca confundir o Escopo do Produto com o Escopo do Projeto. Todo o projeto é algo que possui começo, meio e fim bem definidos. Para definir, então, o escopo do projeto, é fundamental descrever o método de realização, os interessados, prazos e várias informações relevantes. Uma delas é o produto que será obtido com o projeto, em outras palavras, o escopo do produto. No caso de um projeto de produto físico, isso significa definir metas que o produto deverá atender quando pronto. Embora o escopo do produto seja fundamental para caracterizar um projeto, ele não diz como o resultado será obtido, isto é, as atividades, responsáveis, recursos, tempo e várias outras informações que fazem parte do escopo do projeto. Uma definição mais formal é a seguinte:

• Escopo do Produto: é composto pela especificação técnica que descreve o conjunto de funcionalidades e o desempenho desejado para o produto.

• Escopo do Projeto: define o conjunto de trabalhos que serão executados para construir e entregar o produto ou produtos do projeto. O escopo do projeto contém, em um de seus itens, uma descrição sucinta do escopo do produto. Uma observação final é que escopo do produto e o escopo do projeto são interdependentes e devem ser integráveis, isto é, se houver mudanças em qualquer um deles, então, é preciso avaliar o outro em busca de possíveis impactos e necessidades de mudanças.

O procedimento para construir o escopo do produto é simples: reuniões entre o gerente de projeto e os especialistas em diversas áreas, que auxiliarão na complementação e validação das características e funcionalidades do produto. O gerente de projeto terá como base as informações provenientes do portfólio e da Minuta do Projeto, e poderá utilizar como referência escopos de produtos similares.

160

PARTE 2

O Modelo

Como resultado da atividade, deverão ser definidos os parâmetros básicos que caracterizam o produto (o que é o produto) e as funcionalidades que dele se espera (para que serve o produto), de forma a se ter uma clara compreensão do que será fornecido ao cliente. Esses parâmetros devem ser preferencialmente quantitativos e devem apresentar metas claras e inequívocas, mesmo quando qualitativos. Por exemplo, para um produto de bem de consumo durável como um eletrodoméstico, o espaço que os clientes dispõem para armazená-los em casa é crucial na decisão de compra. Portanto, um dos parâmetros básicos para se entender o produto do projeto certamente será sua dimensão ou volume. Um erro que pode ser cometido é definir o projeto de maneira genérica, tal como “volume pequeno”. Essa descrição não quer dizer nada porque o significado de pequeno é relativo e varia de pessoa para a pessoa. O ideal é definir já um valor, tal como deve ocupar um volume máximo de 30cm de altura, 20cm de largura e 20cm de profundidade. Uma dúvida que pode surgir é a seguinte: como o gerente de projetos define esse valor sem consultar o cliente? Na verdade, esse valor será estabelecido de acordo com as análises dos produtos concorrentes, tendências de mercado e o comportamento conhecido atualmente do consumidor. Segundo o modelo unificado, essas informações foram levantadas na fase de planejamento estratégico, compiladas e já deverão estar disponíveis para o gerente desse projeto. Aliás, não apenas para esse gerente de projeto, mas para todos os demais, o que permitirá diluir entre os projetos os esforços de prospecção mercadológica e tecnológica realizados na etapa anterior. Essas informações foram utilizadas para definir o portfólio e distinguir cada um dos produtos presentes. Na próxima fase, projeto informacional, essa definição de tamanho, por exemplo, será validada e aprimorada, agora, sim, com base em dados de campo sobre o público-alvo específico do produto em questão. O resultado das pesquisas indicará se essa meta prevista inicialmente é realista, válida ou se deverá ser alterada. Além disso, muitas outras características e funções serão acrescentadas, pois, nesse momento, no Planejamento do Projeto, o gerente estará se preocupando com os parâmetros (características e funções) básicas do produto, apenas àquelas suficientes para discriminar claramente dos demais do portfólio e permitir o Planejamento do Projeto. Portanto, a descrição presente no atual Escopo do Produto será profundamente avaliada, validada e detalhada na próxima fase, quando haverá uma análise mais completa e intensa empregando-se várias técnicas, além da pesquisa de mercado, tais como: a análise de decomposição do produto, a análise e engenharia do valor, a análise de funções e o desdobramento da função qualidade. O gerente de projetos, de acordo com a necessidade, poderá se antecipar empregando princípios básicos dessas técnicas já durante a definição dessa primeira versão do escopo do produto. Outra prática interessante é utilizar uma mesma checklist para ambas as atividades: no planejamento e no projeto informacional. Um exemplo é apresentado no Quadro 6.4, do Capítulo 6. O gerente de projeto poderá consultá-lo para verificar se não falta algum parâmetro básico que ajude a descrever o produto.

5.4

Definir escopo do projeto

Uma vez entendido qual é o produto, ou produtos, do projeto, será preciso definir as características que delimitam o conteúdo do trabalho. São as características que descrevem “como” o produto será obtido, premissas assumidas, pessoas envolvidas, entre muitas outras. Essa atividade é apresentada sinteticamente na Figura 5.7 e é a base para todo o Planejamento do Projeto. A entrada principal é o Escopo do Produto e a saída é o documento Declaração do Escopo do Projeto. Para a construção da definição do escopo do projeto são utilizadas informações do escopo e da descrição do produto, e uma definição inicial de restrições e premissas que o projeto precisa respeitar. Essas informações provêm, basicamente, do escopo do produto, além da Proposta do Produto (Minuta do Projeto ou Project Charter), produzida na fase anterior. Assim como o escopo do produto, essas características precisam ser descritas de uma forma clara e sem ambigüidades, preferencialmente com metas quantitativas. Para a realização da definição e conseqüente planejamento do escopo, devem ser empregados alguns procedimentos nessas informações de entrada da atividade.

CAPÍTULO 5

Planejamento do Projeto

Figura 5.7

161

Atividade de definição do escopo do projeto.

Um dos procedimentos mais empregados é a análise de custo/benefício, que envolve verificar custos tangíveis e intangíveis e benefícios das várias alternativas do projeto. Técnicas de estímulo de discussão em grupo também podem ser empregadas para gerar diferentes alternativas e abordagens do projeto, tais como o brainstorming (“tempestade” de idéias) e o lateral thinking (pensamento lateral).3 Por fim, em complemento a esses procedimentos, uma outra opção é uma avaliação por especialistas dessas informações de entrada. Com o andamento do projeto, na macrofase seguinte de desenvolvimento do produto, modificações podem se fazer necessárias em seu escopo, de forma que a sua declaração provavelmente passará por revisões e refinamentos que reflitam essas mudanças. Tais modificações fazem parte da gestão do escopo e a possibilidade de ocorrerem, dadas as características do projeto, devem ser previstas na construção de sua definição. Essas mudanças podem se dirigir tanto no sentido de uma ampliação da definição do escopo do projeto como para uma redução de sua abrangência. Entre as definições do escopo do projeto, é fundamental a definição do processo de gestão do escopo, ou seja, as atividades que garantam um controle de todas as alterações realizadas nesse documento. É preciso garantir que qualquer alteração tenha seus impactos avaliados e sejam aceitas de comum acordo por todos os envolvidos no projeto. O controle das mudanças do escopo deve estar integrado aos demais controles do Planejamento do Projeto, que serão descritos nas próximas atividades, tais como: prazos, custos, qualidade etc, dado que a modificação de uma dessas variáveis afeta as demais assim como os objetivos do projeto. A definição de escopo do projeto também deve deixar claras as justificativas ou razões pelas quais o projeto deve ser realizado. Posteriormente, na próxima atividade, essa definição será utilizada para a elaboração de uma declaração escrita do escopo do projeto. Em síntese, ao final dessas duas atividades intrinsecamente relacionadas, o Planejamento do Projeto terá sua declaração do escopo e o seu plano de gerenciamento. Uma boa prática, semelhante à descrita no tópico anterior, é criar um modelo de documento que auxilie o gerente de projeto, para evitar esquecimentos ao se preparar o escopo do projeto. Esse documento é apresentado na Figura 5.8, no Quadro 5.5. A definição do escopo do produto e a do projeto, preparadas durante as atividades anteriores, são utilizadas para a elaboração de um documento formal denominado de Declaração do Escopo do Projeto (observe a Figura 5.9). Esse documento é conhecido no meio empresarial por outros nomes, entre eles Declaração do Trabalho (Statement Of Work – SNOW).

3

Consulte os métodos de criatividade descritos no Capítulo 6.

162

PARTE 2

Quadro 5.5

O Modelo

Checklist do Escopo do Projeto

A lista a seguir apresenta um conjunto de itens que podem fazer parte da descrição do escopo do projeto. Título do projeto. Apelido do projeto. Definir o apelido do projeto é uma prática que facilita a comunicação. Contexto. Informações sobre como o projeto surgiu, pessoas envolvidas e motivações principais. Descrever se esse projeto está inserido em um projeto mais amplo, discutindo qual o contexto. Sempre que possível, deve-se contextualizar esse projeto dentro da estratégia de produtos da empresa. Justificativa. Apresenta os requisitos do negócio aos quais o projeto deverá atender. Deve-se contemplar os requisitos do ponto de vista de todos os interessados e da comunidade em geral. Objetivos. Serve para dar uma visão ampla do que se deseja conseguir com esse projeto, pensando em um leitor “leigo” no assunto. Partes Envolvidas (interessados). Lista das pessoas/instituições que podem ser afetadas com a realização desse projeto. Incluem os clientes, outras áreas, instituições governamentais, dentre outras. Equipe Responsável/Organização. Definição dos times e especialistas responsáveis pela condução do projeto. É preciso definir seus papéis, contribuição (qual o conhecimento/experiência que cada um possui e que contribui para o sucesso do projeto) de cada um e suas responsabilidades. Além do organograma do projeto, uma forma fácil de realizar essa definição é criando uma matriz de responsabilidades e dedicação, como no exemplo a seguir: Figura 5.8

Matriz de responsabilidades e dedicação da equipe de projeto.

Lista de Produto(s) do Projeto/Metas. Descreve o resultado final do produto do projeto, na visão do cliente. Em caso de projetos de desenvolvimento de produto, os produtos podem ser: as especificações do produto, o ferramental para produção, protótipos, documentação que acompanha o produto (manuais), até mesmo uma nova fábrica que irá produzi-lo. Deliverables (subprodutos ou produtos intermediários). Descreve os resultados intermediários que se pretende atingir com esse projeto. Um deliverable pode ser algo físico (protótipo, por exemplo) ou um determinado estado final de algo que já existe (linha de produção pronta para ser produzida). Embasamento Teórico/Referências. Contém a lista de referências do material bibliográfico utilizado. Normalmente, esse item cita um anexo mais extenso ou um outro trabalho relacionado. Premissas, Limitações e Restrições. Definição das “verdades” a serem adotadas para a realização do projeto. São as afirmações que deverão ser assumidas como verdadeiras durante o planejamento e execução. (Exemplo: o módulo de acabamento do equipamento será o mesmo do projeto 178). Ou, então, das listas dos limites do presente projeto (aquilo que ele não pretende atingir) e condições que restringem a sua realização. Estratégias. Definição das estratégias genéricas para a realização do projeto, quando for o caso. Por exemplo, serão contratados serviços de terceiros, serão realizadas reuniões semanais, o time ficará totalmente dedicado a esse projeto etc. Metodologia. Descreve métodos ou padrões de processos de desenvolvimento que serão adotados como referência. Prazos Máximos a Serem Atingidos. Prazos máximos para a entrega dos principais produtos e subprodutos (deliverables). Custo e Preço-Meta. Valores-meta para custos do projeto que deverão ser respeitados. Plano de Gerenciamento do Escopo. Definição de como o projeto será controlado e de como as mudanças serão solicitadas, avaliadas e implementadas, incluindo quem será o responsável e como as mudanças serão aprovadas.

CAPÍTULO 5

Planejamento do Projeto

163

Uma Declaração do Escopo completa deve conter: n

n n

n n

Preparar o documento de Declaração do Escopo

a justificativa do projeto e os requisitos do negócio aos quais pretende atender; uma descrição sucinta do produto que será gerado no projeto; os objetivos do projeto colocados em termos quantificáveis, especialmente quanto a parâmetros de custo, cronograma e medidas de qualidade; o conjunto de premissas e restrições identificadas; e um plano de gerenciamento do escopo, que descreve como esse escopo será gerenciado e como as mudanças que vier a sofrer serão incorporadas ao projeto.

Enfim, o gerente de projeto terá em mãos uma lista com as características do produto e do projeto, respectivamente, o escopo do produto e a Declaração do Escopo. O problema é que ambas são informações textuais e analógicas, dependentes de interpretação. Por isso, será necessária uma nova atividade, o detalhamento do escopo do projeto.

5.5

Detalhar o escopo do projeto

Embora ofereça precisão, o formato de texto utilizado na Declaração do Escopo é árido e dificulta a obtenção de uma visão sintética e mais precisa de todo o trabalho necessário. Portanto, será preciso uma nova atividade, denominada Detalhar o Escopo do Projeto, que é apresentada esquematicamente na Figura 5.9. As entradas principais são a Declaração do Escopo do Projeto e o Escopo do Produto. Figura 5.9

Atividade de preparação da Declaração do Escopo.

A atividade Detalhar Escopo do Projeto tem os seguintes propósitos: n n n

uma melhor precisão de estimativas de custos, tempos e recursos; a definição de padrões mais objetivos para medir e controlar o desempenho; e por fim, uma atribuição mais clara e precisa de responsabilidades.

164

PARTE 2

O Modelo

O detalhamento do escopo deve ser realizado por meio de um recurso denominado Estrutura de Decomposição do Trabalho (EDT), que desmembra o projeto em suas partes componentes e elementos. Esse procedimento é bastante conhecido também pela sigla em inglês: WBS, Working Breakingdown Structure. O modelo unificado prescreve o uso dessa técnica e, por isso, a saída dessa atividade, na Figura 5.10, é a EDT. Preparar a Estrutura de Decomposição do Trabalho (EDT)

Quadro 5.6

Nessa técnica, todo o trabalho necessário no projeto, definido analiticamente na forma de texto, será decomposto em três tipos de elementos e suas relações: produtos do projeto, deliverables (entregas) e pacotes de trabalho (veja o Quadro 5.6).

Definição de EDT (WBS)

A Estrutura de Decomposição do Trabalho (EDT) é uma forma de decompor e agrupar os componentes do projeto, de maneira orientada aos resultados (deliverables e produtos) e que define o escopo completo do projeto (PMI, 2000, p. 59). A decomposição é feita em três tipos de elementos, em uma abordagem de cima para baixo (top-down). Os elementos básicos da EDT são:

• Produtos do projeto. É formado pelos resultados finais do projeto na linguagem dos clientes e, portanto, em um nível alto de abstração. No caso de projetos de desenvolvimento de produtos, pode ser a especificação do produto, protótipo, chão de fábrica preparado etc. A definição do produto se faz com metas abrangentes de especificação.

• Deliverables (entregas ou resultados importantes). Cada produto do projeto é desdobrado em resultados tangíveis, isto é, que podem ser observados, denominados deliverables (entregas). Eles podem ser físicos (um relatório, parte do protótipo etc.) ou uma mudança de estado verificável (pessoas treinadas etc.). A característica fundamental dos deliverables é a capacidade de serem medidos e avaliados. Este termo foi mantido no idioma original por se popularmente empregado desta forma nas organizações.

• Pacotes de trabalho. Representam um conjunto de atividades que precisam ser feitas para a obtenção de um deliverable ou produto do projeto.

• Atividade. É uma ação com verbo e substantivo que será programada e gerenciada no decorrer do projeto. Elas fazem parte de um pacote de trabalho. Esse é o menor nível de planejamento. Ações mais detalhadas só serão significativas para a pessoa que realiza a tarefa e não para o gerente e membros da equipe de projeto. A EDT não é apenas a identificação dos elementos do projeto, mas, também, a relação de pai e filho entre eles. Ela deve ser descrita por meio de uma lista ou de um gráfico similar a um organograma, como mostra a Figura 5.10 a seguir. Figura 5.10

Representação gráfica da EDT.

CAPÍTULO 5

Planejamento do Projeto

165

A elaboração da EDT deve ser iniciada pela identificação dos produtos do projeto. Eles formam o primeiro nível, conforme demonstrado no Quadro 5.7. Em projetos de desenvolvimento de produtos, o principal produto é a especificação, mas podem existir outros como o projeto e construção de uma nova fábrica, a estruturação de um novo canal de vendas, entre outros, dependendo do projeto. Em seguida, são identificados os deliverables e pacotes de trabalho de segundo nível, isto é, que juntos significarão a entrega do produto. É importante notar que o conjunto de elementos abaixo do produto precisa corresponder exatamente à entrega do produto. Note, no exemplo do Quadro 5.7, que o elemento Especificação do Produto, tomado isoladamente, é algo abstrato, mas, analisando o segundo nível da EDT, é possível identificar o que ele representa exatamente — no caso, o documento de requisitos, o produto homologado e o protótipo, só para citar parte do exemplo. Percebe-se que esse trabalho de decomposição poderá ocorrer indefinidamente. Na prática, porém, desdobra-se, na atividade de detalhamento do escopo, somente os primeiros níveis da EDT, geralmente de 2 a 4 níveis. Eles são suficientes para identificar os deliverables e pacotes de trabalho principais do projeto. A identificação de todos os elementos, incluindo as atividades, se dará no momento de detalhar o planejamento, isto é, de realizar a programação das atividades. Isso acontecerá na atividade Definir Atividades e Prazos e também nas atividades genéricas recorrentes de “ajustar o plano do projeto”, no início de cada fase. O detalhamento no início de cada fase é mais comum, quando o projeto for grande e/ou complexo, conforme mencionado no Tópico 3.2, no Capítulo 3. Pois seria improdutivo prever tudo o que acontecerá em detalhes, inclusive, porque muitas ações dependem de resultados das primeiras fases. Assim, o esforço de planejamento investido, no momento atual de definição de escopo, não seria produtivo em razão da imprecisão e dos riscos vindouros. Assim, em projetos longos, planejam-se os primeiros níveis da EDT nessa atividade, detalham-se as fases iniciais nas próximas atividades, e o planejamento detalhado das demais fases é delegado para antes do início de cada uma delas. A EDT é uma forma de apresentação adequada do projeto, pois é uma maneira didática e rigorosa de demonstrar todo o esforço que será necessário para a realização do projeto, a qual será a base do esforço de programação das atividades. Por isso, precisa ser realizada com atenção e cuidado. Não existe uma regra ou método exato para a sua determinação. Depende de habilidade e prática. Mais que isso, da experiência da própria empresa, que irá, com o tempo, identificar a melhor forma de dividir o trabalho, de acordo com as características de seus projetos de desenvolvimento e a estrutura organizacional da empresa. Porém, algumas dicas podem auxiliar no desenvolvimento e verificação da subdivisão. Quadro 5.7

Cuidados para a Elaboração da EDT

As principais diretrizes para a elaboração de EDTs são: 1) Cada elemento da EDT deve ser claramente definido e estar relacionado a um resultado (produto ou deliverable) único (propriedade de independência). 2) Cada elemento de um nível superior da WBS deve significar o resultado da agregação dos resultados de todos, e tão-somente, dos níveis inferiores. 3) Cada elemento-filho deve se relacionar com um único elemento-pai. 4) Todos os deliverables do projeto devem estar incluídos na WBS. 5) O número de elementos de um mesmo resultado deve ser planejado de maneira tal que (veja a Figura 5.11):

• Situação A — O número de atividades destinadas a um resultado (produto) não seja tão grande que torne impossível para uma pessoa gerenciar aquele resultado.

• Situação B — O número de atividades que compõem um deliverable não pode ser tão pequeno que gere mais deliverables no projeto do que o gerente seja capaz de controlar.

(continua)

166

PARTE 2

Quadro 5.7 Figura 5.11

O Modelo

Cuidados para a Elaboração da EDT (continuação) Exemplos gráficos de EDTs inadequadas.

Fonte: Project Management Institute. Practice standards for working-breaking-down structure. Newton square-Pennsylvania : PMI, 2001.

Preparar versão final da Declaração do Escopo

Quadro 5.8

Uma vez preparada a EDT, a Declaração do Escopo do Projeto estará pronta. E se transformará no documento que guiará todas as demais atividades de Planejamento do Projeto (veja o Quadro 5.8).

Importância da Definição do Escopo

A Figura 5.12, proposta pelo PMI, demonstra a importância da definição do escopo do projeto. Ela representa esquematicamente o relacionamento entre os processos de definição do escopo e os demais processos da Gestão de Projetos, conforme definidos pelo PMI. Note que ela servirá de base para praticamente todo o Planejamento do Projeto. Figura 5.12

Relacionamento entre a definição do escopo e a EDT com as atividades de planejamento do projeto.

Fonte: Baseado em PMI Standards committee. Project Management Body of Knowledgement. Pennsylvania: Project Management Institute Publication, 2000. Disponível em: . Acesso em: 20 de março de 2001. Tradução própria.

Dada a importância da Declaração do Escopo, é fundamental revisá-la até que se garanta um bom nível de maturidade, em que a probabilidade de erros seja pequena. Consulte o Quadro 5.9 para uma lista dos erros mais

CAPÍTULO 5

Planejamento do Projeto

167

comuns na preparação da Declaração do Escopo do Projeto. Uma boa prática é criar um modelo de documento contendo os títulos de todos os possíveis tópicos. Quadro 5.9

Erros Comuns na Preparação da Declaração do Escopo do Projeto

Um erro na confecção da Declaração do Escopo pode trazer conseqüências sérias para um projeto de desenvolvimento de produtos. Devemos sempre ter em mente que a Declaração do Escopo é elaborada para “selar o pacto” entre a pessoa que está assumindo o papel de gerente de projeto e os interessados. Um erro, mesmo que mínimo, pode levar a divergências de interpretação com impactos significativos. Os erros mais comuns são:

• Documentos desorganizados. O primeiro passo para garantir uma boa Declaração do Escopo é a utilização de boas práticas de organização do texto. Utilizar subitens numerados, separar os tópicos, dispô-los em uma seqüência lógica, incluir sumário e, quando extenso, incluir índices remissivos e analíticos são exemplos disso. Um erro comum é misturar os diversos elementos (especificações, aprovações e instruções especiais), tornando-o árido, inconsistente e impossibilitando análises críticas. Além de evitar os demais erros, faz com que o interessado deixe de notar aspectos específicos do projeto ou incoerências que levem a interpretações dúbias.

• Imprecisão terminológica. Definições conceitualmente erradas, termos utilizados de maneira inadequada, termos vagos (como “aproximadamente”, “etc.”, “vários” e outras) e frases com duplo sentido são exemplos de imprecisão terminológica. Ela acontece quando a mensagem fica prejudicada pelo desconhecimento ou uso errado dos termos. Avalie sempre se os termos utilizados no texto têm o mesmo significado para todos os interessados no projeto.

• Falta de padronização no tamanho das tarefas e resultados. É comum a definição e mistura de atividades e resultados muito distintos. Isso significa que algumas delas podem estar com níveis muito diferentes de abstração. Na prática, isso leva a uma série de sobreposições que podem esconder erros. Deve-se esforçar para garantir o máximo de padronização e coerência.

• Falha na solicitação de revisão por terceiros. A pessoa que está preparando o documento de Declaração do Escopo geralmente tem uma limitação de nível de conhecimento, isto é, é especialista em parte do projeto. Um erro comum, principalmente em projetos complexos, acontece quando ele julga sua própria experiência como suficiente. A probabilidade de erros aumenta, principalmente nas áreas na qual ele tem um conhecimento técnico menor. Por isso é uma boa prática submeter o documento para a revisão de especialistas nas diversas áreas para que verifiquem os termos empregados e garantam a clareza.

5.6

Adaptar o modelo de referência

Definidas as atividades anteriores do planejamento, fica mais claro qual é o escopo do produto e principalmente do projeto. A partir desses resultados, e das características do modelo de referência específico adotado na empresa para seu PDP, pode-se, na presente atividade (Figura 5.13), realizar as devidas adaptações nesse modelo, de forma a que venha a ser utilizado para o projeto de novo produto em questão. Conforme explicitado no Capítulo 2, um modelo de referência pode ser utilizado como base para a criação de outros modelos ou para a definição de projetos. Alguns modelos são criados para adequar-se a necessidades genéricas, tais como as de um setor, tecnologia etc. Quanto mais genérico, maior é o trabalho de adaptação do modelo, pois as práticas, ordem das atividades, soluções e documentos propostos são elaborados para atender à necessidade geral de todas as empresas dessa categoria. O ideal é que a empresa possua o seu próprio modelo de referência. Esses modelos mais gerais são interessantes porque, a partir deles, chega-se ao modelo de referência específico para uma determinada empresa, de acordo com a sua realidade particular, assunto que será tratado no Capítulo 15. O Planejamento do Projeto parte desse modelo específico, adaptando-o conforme a necessidade de cada projeto de desenvolvimento de produtos da empresa. Note, porém, que, mesmo dentro de uma única organização, os projetos de novos produtos podem variar bastante em termos de complexidade. Existem desde projetos mais simples, que envolvem pequenas variações de produtos existentes, até projetos que geram uma nova categoria ou tipo de produto — alguns deles incluindo projetos de novas fábricas. Por isso, mesmo o modelo de referência de uma empresa deve ser flexível o suficiente para atender às necessidades desses diferentes projetos. O primeiro passo para realizar essa personalização é

168

PARTE 2

O Modelo

identificar as características do projeto. Isso deve ser feito por meio de uma tipologia de projetos cuidadosamente elaborada e específica da empresa. Ao se classificar o projeto dentro dos diferentes tipos, ter-se-á uma boa noção das mudanças em relação ao projeto. Figura 5.13

Atividade de adaptação do modelo de referência.

Normalmente, os projetos podem ser classificados em quatro tipos básicos quanto à inovação tecnológica e esforço:4 n

n

n

4

Um projeto do tipo radical é aquele que resultará em um produto totalmente novo para a empresa e, algumas vezes, totalmente novo para o mercado. A inovação pode estar também no processo de fabricação, isto é, quando o processo de fabricação é totalmente novo para a empresa ou mesmo para o mercado. Eles não ocorrem com muita freqüência no DP de uma empresa, e o Time de Projeto deverá utilizar o modelo de referência unificado em sua completude, isto é, todas as fases e atividades. Além disso, dadas as características desse tipo de projeto, deve-se considerar a necessidade de uma maior integração do modelo com o setor ou processo de P & D da empresa (os ajustes e adaptações no modelo específico, necessários para seu uso nesse tipo de projeto radical, são comentados no Capítulo 16). Em um projeto do tipo plataforma, isto é, naquele em que o produto não é totalmente novo para a empresa, mas terá mudanças significativas na concepção. Significa a adoção de novas soluções na arquitetura do produto, originando uma nova plataforma, isto é, um novo conjunto básico de componentes que será reutilizado nas próximas gerações de produtos derivados da plataforma. Nesse caso, o modelo do processo de desenvolvimento será também utilizado na íntegra, incluindo todas as suas fases e atividades. Para um projeto derivado de uma plataforma, o objetivo é criar um produto adicional em uma linha, que deverá ser baseado em uma plataforma ou produto previamente desenvolvido e em produção. Em geral, as fases e atividades iniciais da macrofase de desenvolvimento podem ser simplificadas, pois a concepção do produto não terá modificações profundas.

Esses tipos foram discutidos brevemente no Capítulo 1, e agora são descritos com maiores detalhes.

CAPÍTULO 5

Planejamento do Projeto

n

169

Por fim, para um projeto do tipo follow source, além de simplificações de fases e atividades, pode mesmo ocorrer a eliminação da fase de projeto conceitual, pouco relevante para as características desse tipo de projeto.

Outros parâmetros podem ser utilizados nessa tipologia, além do grau de inovação. Deve-se escolhê-las identificando as características do projeto que mais afetam a maneira de gerenciar os produtos. Por exemplo, em produtos sob encomenda para a indústria metal-mecânica pesada, por exemplo, o volume ou tamanho de uma peça pode ser um fator determinante, dado que, em peças grandes, haverá necessidade de um cuidado especial nas atividades de planejamento da logística e instalação dos produtos, desnecessários em produtos menores. Exemplos de parâmetros que podem ser utilizados são complexidade dos produtos e relacionamento com outros projetos da empresa. No modelo de referência de PDP apresentado neste livro, a primeira tarefa Classificar o projeto dessa atividade é a classificação do projeto. O modelo prevê uma classificação combinando dois dos tipos mais utilizados: o grau de complexidade do produto/projeto e o seu grau de inovação, tomando-se como base informações provenientes das declarações de escopo, resultantes das atividades anteriores do planejamento. A primeira variável, novidade, mede quanto há de peças novas no produto. A segunda variável, complexidade, mede a quantidade de peças e/ou o seu agrupamento no produto. Em termos mais objetivos, a determinação do grau de novidade em um produto pode ser avaliado pela porcentagem de itens ou partes na BOM (Bill Of Material, Estrutura do Produto) desse produto que não foram utilizados antes em outro produto da empresa (se esse produto for um software, refere-se às novidades introduzidas no código fonte). Já o grau de complexidade deve ser avaliado por uma composição de indicadores, como o tempo gasto para projetar esses itens ou partes e combiná-los no produto, a necessidade de pessoas e conhecimentos para isso, os tempos e recursos necessários para a manufatura e montagem desses itens ou partes etc. Comparando-se os resultados desses indicadores com o obtido em outros produtos da empresa, é possível obter uma perspectiva do grau de complexidade do produto em questão. Se o produto for um software, o mesmo raciocínio, com as devidas adaptações, deve ser aplicado à realização de seu código-fonte. Com isso, ficam evidentes as adaptações que serão necessárias no modelo de referência específico do PDP da empresa, de forma a melhor utilizá-lo para o projeto em questão. A adaptação desse modelo específico para o escopo e as características do presente projeto de DP em planejamento devem considerar quais e como devem ser realizadas as atividades e tarefas de cada uma das seis fases do desenvolvimento do produto: o projeto informacional (que gera as especificações-meta do produto); o projeto conceitual (que chega às concepções do produto); o projeto detalhado (que apresenta as especificações finais do produto); a preparação da produção (que prepara e libera o projeto para a produção); e, finalmente, o lançamento do produto. A próxima tarefa aborda essa realização das fases do desenvolvimento, para os tipos de projetos anteriormente descritos — exceto o radical, que, em razão de suas particularidades, será abordado no Capítulo 16. A Figura 5.14 ilustra, a partir da avaliação conjunta da complexidade e inoAdotar versão adaptada vação do produto/projeto em questão, quatro versões adaptadas do modelo de refedo modelo específico rência específico, diferenciando-as conforme a ênfase com que serão tratadas as fases do desenvolvimento do produto. O comprimento de cada fase na Figura 5.14 (nominalmente citadas e numeradas na primeira versão e apenas numeradas nas outras três) indica o nível de esforço gasto durante o projeto. Um grande esforço significa realizar todas as atividades da fase e aplicar todas as técnicas.

170

PARTE 2

Figura 5.14

O Modelo

Versões do modelo de referência específico.

Em seguida, descreve-se cada uma das versões, da parte superior para a inferior da Figura 5.14, ou seja, da complexidade/novidade maior para a menor do produto/projeto, o que, em conseqüência, significa ir da mais completa versão para a mais simplificada, em termos de realização das atividades e fases do desenvolvimento do produto. Uma primeira versão é o modelo específico praticamente completo ou plenamente utilizado pelo projeto de DP, em termos do emprego na sua execução das cinco fases e suas respectivas atividades. Esse modelo completo é empregado no caso de projetos de produtos complexos e ao mesmo tempo inovadores, muitas vezes para explorar um novo segmento de mercado em que a empresa ainda não atuava ou não tinha um produto adequadamente direcionado para isso. Esse caso é típico quando ocorre o desenvolvimento de uma plataforma de produto totalmente nova, diferente de qualquer outra que a empresa já desenvolveu, inaugurando uma nova família de produtos na empresa (embora não necessariamente no mercado, pois já podem existir produtos pioneiros concorrentes), de onde é esperado o surgimento de muitas derivações futuras. Poderia ser citado, a título de exemplo, a entrada de uma montadora de automóveis, com um veículo totalmente novo, o primeiro da plataforma, em um determinado segmento do mercado em que não atuava. Deve-se notar que, embora todas as versões estejam com o mesmo tamanho, para deixar clara a ênfase, esses tipos de projeto normalmente têm duração muito maior que os demais tipos. Em uma segunda versão, há uma relativa simplificação do modelo de referência específico. Se comparada à versão anterior, possui como características diferenciais um planejamento de projeto menos detalhado e simplificações nas fases do desenvolvimento. Destaca-se como diferenças o projeto informacional e conceitual que podem ser tratados como uma única fase, além do projeto detalhado e da preparação da produção, que são reduzidos com várias de suas atividades e tarefas simplificadas, agrupadas, ou mesmo sem necessidade de execução. Essa versão do modelo de referência específico é especialmente aplicável em situações em que o produto/projeto não apresenta ao mesmo tempo complexidade e inovação altas. Apenas uma dessas duas dimensões é alta, ou, então, ambas estão em um patamar intermediário. Normalmente, esse contexto é encontrado no projeto de uma nova plataforma, em substituição a uma plataforma que a empresa descontinuará. Ou seja, uma nova família de produtos, mas em um segmento que a empresa já atua e, portanto, conhece bem. Também essa versão do modelo pode ser a mais adequada quando há o desenvolvimento dos principais derivados, de uma plataforma de produto totalmente nova (desenvolvida seguindo a primeira versão, como já explicado).

CAPÍTULO 5

Planejamento do Projeto

171

Como exemplo palpável, pode-se citar, na indústria automobilística, o desenvolvimento de uma nova plataforma de veículo, que ocorre regularmente após um conjunto de anos, no mesmo segmento e adotando o mesmo nome comercial do produto que a empresa já produz. Pode-se nominalmente citar os casos mundiais do Toyota Corolla e do VW Golf, que existem desde os anos 1970, porém, a cada período de alguns anos, são totalmente remodelados com a criação de uma nova plataforma. Outro exemplo, nessa mesma indústria, é o desenvolvimento das primeiras derivações, como uma nova station-wagon, ou uma nova van, a partir de uma plataforma de produto totalmente nova para a empresa. Sempre comparando com as anteriores, em uma terceira versão há uma grande simplificação do modelo de referência específico. Como características dessa versão, além de um planejamento de projeto reduzido, há muitas simplificações no desenvolvimento do produto. As fases de projeto informacional e conceitual permanecem unidas e com menos atividades e tarefas do que na versão anterior. O projeto detalhado se mantém, mas a preparação da produção pode ser simplificada. O lançamento do produto, que nas versões anteriores mantinha-se integralmente idêntico ao do modelo de referência específico, passa a ser executado parcialmente. Como pode ser observado na Figura 5.14, essa versão do modelo é aplicada em produtos/projetos em que as dimensões de complexidade e novidade tendem para um patamar de intermediário a baixo. Esse é o caso de derivações usuais ou convencionais a partir de plataformas de produtos já bem estabelecidas na empresa. Usando novamente a indústria automobilística como exemplo, podem ser citados aqui alguns desenvolvimentos de produtos normalmente encontrados nesse setor e que podem utilizar essa terceira versão: uma nova motorização de um veículo (porém, se for um motor que exija grandes modificações no veículo, cabe a segunda versão do modelo); um face-lift ou uma nova versão anual do veículo, que requer mínimas modificações do produto, mas com certo apelo mercadológico; as séries ou edições especiais do veículo, que são derivações com certas mudanças de acabamento e especificações técnicas, que não requer grandes modificações do produto original para ser feita etc. Por fim, há uma quarta versão do modelo de referência específico, em que são baixas tanto a complexidade quanto a novidade do produto/projeto. Esse é o caso dos denominados follow source, por exemplo, um produto já produzido pela matriz ou em outro mercado em que a montadora automotiva atua, e que é adaptado (“tropicalizado”, usando um termo mais comum nessa indústria), para lançamento no mercado brasileiro. Essa adaptação envolve mínimas modificações e regulagens no produto, por exemplo, ajustes para receber os tipos de combustível encontrados no Brasil e na suspensão para uso nas estradas brasileiras. Porém, pode existir muito a ser feito no projeto do processo de fabricação e montagem, dada a necessidade de preparar uma planta nacional para a produção local. Por essas características, a presente versão do modelo de referência específico normalmente dispensa o projeto conceitual, que não faz sentido uma vez que o produto já está totalmente concebido. Possui um projeto informacional reduzido, apenas para levantar certas especificidades do mercado local em relação ao produto já desenvolvido em outro país e que se pretende adaptar. O modelo concentra-se no projeto detalhado, e principalmente na preparação da produção e lançamento do produto, retornando essas fases na presente versão à mesma plenitude de realização das atividades e tarefas do modelo completo. Mesmo considerando-se que já há uma planta em produção em outro país, que serve de referência para o projeto do processo de produção local do produto, muitas diferenças existem e precisam ser consideradas. As fábricas, escalas de produção, processos produtivos, fornecedores, colaboradores, entre outras condições, são diferentes e requerem que muitos trabalhos dessas fases do projeto sejam refeitos para as novas condições encontradas na planta. Importante ressaltar que essa quarta versão é aplicável a situações em que um produto que se pretende lançar no mercado nacional já foi desenvolvido plenamente, e mesmo está em produção, em um outro local. Há situações em que a complexidade e/ou a inovação do produto/projeto são maiores, quando a unidade brasileira de uma multinacional participa do desenvolvimento original do produto na matriz, pois foi planejado que esse será lançado também no Brasil, podendo ser quase simultaneamente ao lançamento mundial. Nesses casos, faz sentido aplicar a segunda ou a terceira versão do modelo, dependendo das particularidades do projeto do produto em questão. As quatro versões anteriormente apresentadas não pretendem ser possibilidades absolutas de classificação do modelo de referência específico da empresa em relação à complexidade/inovação dos produtos/projetos da empresa. Antes disso, são os principais patamares de uma escala imaginária de mais para menos complexidade e inovação. Diversas readaptações dessas versões são possíveis, conforme a realidade encontrada em cada empresa e indústria.

172

PARTE 2

O Modelo

O modelo de referência apresentado no presente livro, no Apêndice I, é o da versão mais completa, com todas as fases/atividades/tarefas. Trata-se de uma indicação, cabendo a cada empresa julgar quanto essas escolhas são pertinentes para suas situações de desenvolvimento de produtos. Na realização de um Planejamento do Projeto de DP, após a realização da preIdentificar necessidades sente atividade, fica a empresa ciente de qual será a versão do modelo adotada para o de mudanças produto/projeto em questão. Sendo assim, cabe à empresa e especialmente aos envolvidos com o planejamento do DP passar a realizar as próximas atividades desse planejamento considerando a especificidade que ocorrerá nas fases seguintes do desenvolvimento, delimitadas pelo modelo que foi escolhido. Em outras palavras, cabe aos planejadores da empresa, ao realizar as próximas atividades do planejamento, se concentrar naquelas atividades do desenvolvimento de produto que fazem parte do modelo escolhido. Deve-se lembrar também que há casos especiais em que o projeto se enquadra em um dos tipos da empresa, mas com algumas exceções em termos de atividades. Utilizando o exemplo de categorização do modelo unificado, pode-se ter um projeto que é follow source, mas que precisa ser testado no mercado. Nesse caso, além do foco nas atividades de detalhamento, preparação da produção e lançamento, o projeto poderá incluir atividades da fase do projeto informacional. Outro exemplo é o caso de um produto que utilizará um mesmo canal de vendas de outro produto, substituindo sem muitas novidades para clientes e assistência técnica. Nesse caso, a fase de lançamento pode ser suprimida ou unida com a de preparação da produção.

5.7

Definir atividades e seqüência

A presente atividade é o detalhamento das atividades para a execução do projeto (veja a Figura 5.15). O objetivo dessa atividade é planejar todas as ações que precisam ser executadas no projeto, isto é, identificar cada uma delas e verificar o relacionamento. Se as atividades anteriores tiverem sido bem executadas, essa atividade será bastante facilitada. O modelo de referência do PDP adaptado e a Declaração do Escopo do Projeto, juntos, permitirão a programação das atividades, com probabilidade pequena de erros. Figura 5.15

Definição de atividades e prazos.

CAPÍTULO 5

Planejamento do Projeto

173

A primeira tarefa é identificar as atividades. Na verdade, a partida para essa Identificar atividades ação já foi dada. Basta lembrar que, no final da atividade Preparar Declaração do Escopo do Projeto, Tópico 5.5, o gerente de projeto já especificou os primeiros níveis da Estrutura de Decomposição do Trabalho (EDT). A identificação das atividades é realizada dando-se prosseguimento a esse mesmo processo de decomposição da EDT, só que, agora, conta-se com o apoio do modelo de referência na sua versão personalizada para o projeto. O gerente de projetos decompõe a EDT transformando todos os deliverables e pacotes de trabalho em pacotes de trabalho mais detalhados. Depois, com a ajuda do modelo de referência na versão personalizada, decomporá os pacotes de trabalho em atividades. Uma atividade pode ainda ser decomposta em um conjunto de outras atividades. Quando isso acontece, denominamos a atividade-pai de atividade-resumo (veja o Quadro 5.10, para uma lista dos tipos de atividades), pois, para efeitos de controle e cálculos, seus parâmetros serão o resultado do somatório das atividades-filho. Quadro 5.10

Tipos de Atividades

Para fins de planejamento, as atividades geralmente são classificadas em três tipos:

• Atividade: é a definição de uma ação necessária para a execução do projeto, com o nível mais baixo de detalhe. Uma atividade em um plano possui vários atributos, tais como: prazo, datas de início e fim, recursos humanos responsáveis, duração etc.

• Atividade-resumo: é aquela composta por um conjunto de atividades. Seus parâmetros são dependentes das atividades-filho que a caracterizam. Sua duração, por exemplo, é determinada pela data mais cedo de início e data mais tarde de término dentre todas as atividades-filho.

• Atividade-marco (milestone): é uma atividade inserida no planejamento e que recebe duração. Ela não afeta a programação e existe apenas como lembrete do fim ou início de um momento importante do projeto.

Atividade é o termo utilizado dentro da Gestão do Projeto para o último nível de detalhe da EDT. A identificação da atividade depende do nível de controle que se exercerá no projeto (veja o Quadro 5.11). Quadro 5.11

Identificando as Atividades

A decomposição correta de todo o trabalho em atividades tem impacto em todo o planejamento e controle do projeto. Não se engane, pois não é algo fácil de fazer. Depende de experiência, conhecimento profundo dos detalhes do projeto e prática. O maior cuidado está em saber o momento adequado de parar o desdobramento, isto é, quando temos a atividade (o menor nível do planejamento). A dica a ter em mente é verificar o nível de controle que se espera realizar sobre o projeto na fase de execução, nem maior nem menor. Se maior, o conteúdo da ação não ficará bem definido e o gerente de projeto terá dificuldade de especificar o esforço, como veremos adiante. Se menor, a lista ficará tão complexa e com detalhes tão irrelevantes que pode até mesmo atrapalhar o controle do projeto. Um nível suficiente significa que a ação é definida inequivocamente e apresenta detalhes suficientes para saber o que será feito na ação. Por exemplo, se esperamos verificar o andamento das atividades semanalmente e a montagem do protótipo de uma máquina dura 4 horas, faz sentido parar nesse nível, sendo a atividade de menor nível chamada simplesmente de Montar protótipo. O gerente de projeto, com essa informação, é capaz de controlar o andamento do projeto semanalmente e delegar essa atividade. Caso estejamos falando de um grande equipamento que demora 60 dias para ser montado, utilizar essa mesma atividade como último nível seria claramente inadequado do ponto de vista do gerenciamento. Pois, durante estes 60 dias, o uso de muitos equipamentos, esforços e pessoas precisaria ser identificado e seqüenciado em detalhes — o que não será possível com uma única atividade. Além disso, podem se passar até 12 semanas para identificar um problema. Nesse caso, montar protótipo pode ser uma atividade-resumo, mas seria fundamental quebrá-la em subatividades para facilitar o planejamento e controle, tais como: preparar galpão, montar estrutura etc.

(continua)

174

PARTE 2

Quadro 5.11

O Modelo

Identificando as Atividades (continuação)

Existem projetos em que há necessidade de controles muito finos; nesse caso, o nível de detalhes pode ser até maior, atingindo horas. Por exemplo, existem produtos de bens de consumo, tais como: escovas de dentes, absorventes, hastes flexíveis e outros, que são produzidos em altíssimos volumes por equipamentos específicos, complexos e altamente informatizados. O custo da hora parada dessas máquinas é muito grande. Por outro lado, na introdução do produto na fábrica, ele terá que ser parado e sofrer uma série de modificações para iniciar a produção piloto do novo produto. Nesse caso, um planejamento detalhado de tudo que será feito, pelos diversos técnicos que participam do projeto, poderá fazer-se necessário. O dimensionamento dessas tarefas em dias seria inadequado. Teríamos que as programar detalhadamente, em horas, para controlar a execução das várias atividades. Outra dica é padronizar a escrita da EDT utilizando sempre verbo e substantivo para designar atividades e pacotes de trabalho. Utilize substantivos para designar deliverables e produtos. Pode parecer perfeccionismo, mas a facilidade de compreensão do plano aumenta significativamente com o uso de padrões simples de escrita.

Ações com nível de detalhe maior do que o adequado ao controle são comumente denominadas de tarefas, com o intuito de distingui-las claramente das atividades. Atividade e tarefas são categorias de ações, mas é importante separá-las porque a tarefa traz informações irrelevantes do ponto de vista da Gestão do Projeto, pois NÃO se destinam a auxiliar na atribuição e muito menos ao controle das atividades. As tarefas devem ser identificadas e controladas pelo responsável pela atividade e, na grande maioria dos casos, não interessam ao gerente de projetos. Agora fica fácil entender uma das grandes vantagens da empresa trabalhar com o conceito de processos de negócio e utilizar modelos de referência dentro da empresa. O modelo de referência oferece ao gerente de pro5 jetos uma lista de todas as atividades possíveis, servindo como uma checklist e, ao mesmo tempo, facilitando a padronização das atividades. Aliás, a empresa pode ter um modelo de documento com essas listas em formato digital, facilitando ainda mais a vida do gerente de projeto. Nesse caso, as atividades-padrão do modelo poderão ser copiadas e modificadas. Uma ferramenta que faz a diferença são os softwares de Gestão de Projetos (consulte o Quadro 5.12). Normalmente, os primeiros níveis da EDT, identificados durante a prepaOs softwares de Gestão de ração da Declaração do Escopo, são registrados em um editor de textos padrão ou Projetos apóiam o gerente em planilhas. Utilizar sistemas de Gestão de Projetos para completá-lo é vantajoso de projetos nesta porque as funcionalidades de edição de listas e geração de gráficos da EDT podem atividade ser úteis para lidar com a quantidade grande de atividades. Projetos simples chegam a ter uma centena de atividades, mas há projetos complexos que podem atingir milhares delas. Outra razão, ainda mais forte, é que, conforme demonstrado no Quadro 5.12, esses sistemas auxiliam em uma série de análise. Uma das informações fundamentais para utilizar tais recursos é a lista de atividades. Realizá-la direto no sistema irá, portanto, economizar um tempo precioso nos próximos passos, momento em que tais análises poderão ser realizadas. Quadro 5.12

Softwares de Gestão de Projetos

O gerenciamento do projeto é uma atividade complexa formada por uma mistura de planejamento, tomada de decisões e muita negociação. A qualidade e atualização das informações sobre o projeto são requisitos básicos para o gerente tomar as melhores decisões. Um apoio fundamental é o das ferramentas computacionais conhecidas como softwares de Gestão de

(continua) 5

No modelo de referência unificado procurou-se utilizar a distinção entre atividade e tarefas apresentada neste texto. O nível descrito é o que deve ser utilizado para controle, e o nível das tarefas descreve as atividades para os responsáveis pela sua execução. É lógico que não se deve utilizar cegamente essa definição dessa referência, pois, dependendo das circunstâncias, tipo de produto, organograma da empresa, entre outros, o nível descrito como de tarefa pode ser útil ao planejamento, devendo constar na EDT.

CAPÍTULO 5

Planejamento do Projeto

Quadro 5.12

175

Softwares de Gestão de Projetos (continuação)

Projetos. Esses sistemas automatizam os cálculos de tempo, utilização e nivelamento dos recursos e custos. Conseqüentemente, permitem criar cenários para avaliar diferentes alternativas e definir o melhor planejamento possível. Eles aumentam a capacidade humana de monitorar as datas planejadas e compará-las com as datas reais. Em ambientes multiprojetos ou projetos de altíssima complexidade, milhares de recursos humanos e prazos de anos, essas ferramentas são imprescindíveis. Elas podem oferecer simulações que envolvem cálculos de diferentes durações de projeto ou análise de diferentes cenários (análise what-if) — por exemplo: avaliar como o atraso ou o adiantamento de determinadas atividades em um projeto pode afetar o cronograma de outros projetos que compartilham os mesmos recursos. Essas análises, entre outras, seriam bastante dificultadas sem o uso desses softwares (PMBOK, 2000). As funcionalidades típicas de um sistema de Gestão de Projetos são:

• Gestão de calendário e agenda: os sistemas permitem a organização e programação de calendários para o projeto, recursos ou tarefas. A programação do calendário envolve definir o período de trabalho diário, dias de trabalho por semana e eventuais feriados. As ferramentas mais sofisticadas permitem a criação de calendários-base com os dados da empresa e a sua personalização para cada recurso específico, material ou humano. Um exemplo: se um determinado fornecedor só pode trabalhar no período da tarde, o sistema permite criar um calendário específico para ele com essa restrição.

• Gestão de atividades: os sistemas permitem registrar as atividades, visualizá-las e organizá-las em níveis. Permitem, também, estabelecer diferentes tipos de precedência entre as atividades e representá-las na forma de rede de atividades, de Gráfico de Gantt e geração de EDT/WBS. Permitem buscas, filtros e outras facilidades para editar as tarefas e definir dados básicos como esforço, duração, datas de início e fim e recursos alocados.

• Gestão de recursos: permitem o gerenciamento das pessoas e materiais necessários para o projeto. Permitem, ainda, cálculos de disponibilidade, facilitam o acompanhamento do trabalho dos times e permitem diferentes padrões de alocação nas atividades. Os sistemas mais avançados possuem algoritmos para realizar o nivelamento dos recursos e são capazes de gerar diferentes tipos de gráficos para analisar a alocação. Alguns sistemas mais sofisticados integrados a sistemas ERP (veja o Quadro 2.5, no Capítulo 2) utilizam a base única da empresa dos recursos humanos, facilitando a seleção das pessoas por meio da análise de suas competências registradas na base de dados, e, também, o controle e remuneração integrados. A base de dados única permite um gerenciamento das férias e compartilhamento da pessoa em vários projetos e departamentos. A integração com o processamento da folha de pagamento permite que ela receba conforme o seu desempenho no projeto, desde que seja essa a regra para pagamento.

• Gestão de custos: com as informações dos recursos e atividades, esses sistemas possuem funções para calcular e gerenciar o orçamento do projeto. Trata-se de um recurso que auxilia bastante o gerente de projeto na preparação do orçamento e no controle dos gastos. Os sistemas de gerenciamento de projetos integrados a sistemas ERP permitem que todos os gastos de um projeto sejam alocados a um centro de despesas, com regras flexíveis para sua alocação ao plano de contas da empresa. Dessa forma, pode-se utilizar as regras de consolidação de contas da empresa, sem a necessidade de entrada de dados adicionais nos sistemas financeiros. Com isso, pode-se controlar os orçamentos de forma integrada e reportar as despesas dos projetos nas alíneas permitidas pelo fisco, conforme a classificação automática de suas despesas, que são transformadas em custos ou investimentos, dependendo da configuração estabelecida para cada um dos projetos. Essa integração permite um controle financeiro mais apurado do projeto.

• Ferramentas de monitoramento: os sistemas mais avançados possuem funcionalidades para auxiliar o acompanhamento do projeto. A funcionalidade mais simples é a geração de linhas de acompanhamento dentro de gráficos de Gantt. Devem permitir, também, o armazenamento de linhas de base, isto é, cópias da situação do planejamento em um dado instante. As ferramentas devem realizar comparações entre parâmetros do planejamento atual do projeto com os mesmos parâmetros armazenados nas linhas de base completas. Devem permitir o acompanhamento do projeto por meio da ferramenta de análise do valor agregado.

• Gerenciamento de múltiplos projetos: essas ferramentas devem permitir a análise do portfólio da empresa, isto é, gerenciar mais de um projeto ao mesmo tempo e compartilhar dados entre esses projetos. O principal deles é o do conjunto (pool) de recursos da empresa ou unidade como um todo. Esse é um problema delicado, pois, na grande maioria das empresas, vários projetos estão em andamento ao mesmo tempo, compartilhando um mesmo conjunto de recursos. Conhecer a capacidade da empresa é fundamental e muito difícil, dados o número de restrições e a grande quantidade de informações. As ferramentas com essa funcionalidade permitem análises do andamento dos vários projetos e a determinação do comprometimento atual dos recursos, considerando todos os projetos.

(continua)

176

PARTE 2

Quadro 5.12

O Modelo

Softwares de Gestão de Projetos (continuação)

Uma última observação é que, dentro da tendência em direção ao Product Lyfe-Cycle Management, PLM (veja o Quadro 8.30, no Capítulo 8), essas ferramentas vêm se ampliando para lidar também com a gestão de documentos do projeto e para facilitar a integração dos times. Portanto, a tendência é que as ferramentas de Gestão de Projetos sejam capazes de se integrar aos sistemas PDM e EDM e estão se desenvolvendo para incluir funcionalidades, tais como:

• Comunicação e integração: os sistemas mais modernos de Gestão de Projetos possuem funcionalidades para importar e exportar dados em outros sistemas (bancos de dados, ERPs etc.), realizar notificações por e-mail e possuir fóruns de discussões interno e na Internet (para suporte de instalação e utilização).

• Gestão de documentos, relatórios e impressão: permitem a geração de relatórios predefinidos e sua personalização. As funcionalidades de auxílio ao gerenciamento de documentos, como controle de versão e autoria, ou podem importá-los ou exportá-los para outros formatos. Ainda avalia se o software gera visões em formato de impressão para determinados dados ou gráficos.

• Colaboração entre equipes distribuídas: são sistemas de gerenciamento de projetos que rodam na Internet e permitem um controle de projeto distribuído, com uma consolidação centralizada desses controles pelo gerente do projeto. Todos os membros do time acessam as informações mais atualizadas via Internet. Além disso, eles podem compartilhar documentos pela Internet. Por fim, o crescimento do emprego de técnicas para gerenciamento de projetos deve muito à disponibilidade de softwares. Muitas delas exigem a manipulação de grande quantidade de dados, que, no passado, era realizada apenas pelas empresas que operavam com projetos de proporções e complexidade suficientes para tornar justificável a existência de uma equipe de apoio, com engenheiros, estatísticos e matemáticos, dedicados exclusivamente ao trabalho de gerenciamento. Com o auxílio dos sistemas, mesmo empresas de menor porte podem de maneira prática ter acesso a essas técnicas. No entanto, não se deve esperar que o computador substitua o tradicional processo decisório. Na Gestão de Projetos, o computador ainda é utilizado principalmente como uma ferramenta de apoio, facilitando a manipulação dos dados para o emprego de técnicas e métodos disponíveis na área. Sua principal vantagem é a velocidade de processamento de análises quantitativas, necessárias a uma grande variedade de processos (BADIRU, 1995). O emprego de técnicas computacionais mais sofisticadas, como a inteligência artificial, ainda está distante das práticas dos sistemas comerciais.

Ao final da identificação das atividades, tem-se uma primeira listagem com a descrição das atividades a serem realizadas no projeto, de preferência, já no sistema de Gestão de Projetos adotado como padrão na empresa. Essas atividades devem estar organizadas em agrupamentos conforme a EDT identificada do documento Declaração do Escopo do Projeto. Também é um resultado o aprendizado decorrido das discussões e decisões para a definição e descrição das atividades, que deve ser registrado para uso futuro em outros planejamentos de projetos. Como decorrência desse planejamento das atividades, pode ser percebido algum ponto incompleto no detalhamento do escopo dado pela EDT, o que deve, então, ser corrigido e/ou atualizado. As informações de entrada dessa tarefa são: a lista das atividades; a Declaração Definir relacionamentos do Escopo do produto, visto que suas características podem afetar as possibilidades entre atividades de seqüências das atividades; e, principalmente, o conhecimento e a experiência necessários para determinar as dependências obrigatórias conforme apresentado. Parte das atividades identificadas possui entre si uma seqüência natural, isto é, uma relação de precedência. Do ponto de vista de planejamento, tais relações representam restrições de programação que precisam ser consideradas. Por exemplo, se uma atividade é a de detalhar o plano de processo, é lógico que pelo menos um conjunto de detalhes fundamentais de especificação da peça deve existir. Portanto, a programação do início dessa atividade terá que ser feita após a conclusão das atividades que definiram a peça. Trata-se de uma precedência de ordem física e natural. Existem também precedências de ordem lógica. Acontecem quando a motivação da dependência é empírica, ou seja, não há restrições físicas, mas sabe-se, por experiência, que a seqüência torna o projeto mais produtivo. Por exemplo, as atividades de capacitar a assistência técnica e realizar um determinado teste do novo produto no mercado são totalmente independentes. Mas pode-se programá-las conjuntamente para obter economia de translados e compartilhar recursos humanos. O resultado da identificação das atividades

CAPÍTULO 5

Planejamento do Projeto

177

Conforme a natureza da relação entre as atividades, diferentes relações de precedência podem existir, conforme o Quadro 5.13. A próxima tarefa do gerente de projeto é estabelecer corretamente esses relacionamentos para garantir uma seqüência correta. Novamente, aqui é fundamental a utilização de sistemas computacionais de gestão de projeto. Quadro 5.13

Tipos de Relacionamentos entre Atividades

Existem quatros tipos básicos de relacionamentos entre atividades. Apresentamos, a seguir, definições de cada um deles e um exemplo da representação gráfica tradicionalmente utilizada pela maioria dos softwares de Gestão de Projetos: Final-Início. É o relacionamento mais simples e comum. Acontece quando a atividade sucessora só poderá ser iniciada quando a atividade predecessora for finalizada. É o caso da relação entre a atividade Preparar Proposta de Projeto e a atividade predecessora Decidir Início do Planejamento de um Produto do Portfólio, pertencentes à fase de Planejamento do Produto. Início-Início. É aquele que acontece quando a sucessora só poderá ser iniciada se a predecessora já estiver também iniciada, mas NÃO necessariamente finalizada. Um exemplo é o que acontece entre as atividades de detalhamento de um conjunto de subsistemas com grande interface, como o projeto de um motor de veículos. Sistemas de refrigeração, ignição eletrônica e outros podem ser planejados para iniciarem necessariamente juntos, para facilitar a discussão das equipes responsáveis por tais subsistemas. Final-Final. É a restrição em que as atividades podem começar independentemente, mas a atividade sucessora deve terminar junto com a antecessora. É o caso típico de atividades de documentação que requerem atualizações. Por exemplo, as atividades de aprovação final da Estrutura do Produto (BOM) e sua sucessora homologação do produto. Embora o processo de homologação comece depois da definição da estrutura, as atividades de documentação devem terminar juntas para garantir que todas as alterações necessárias durante a homologação do produto sejam devidamente documentadas. Duas observações importantes:

• Observação 1: Os livros e sistemas de Gestão de Projetos apresentam também a restrição Início-Final, mas ela tem um caráter mais conceitual, pois pode ser estabelecida no projeto empregando-se outros relacionamentos.

• Observação 2: Nos sistemas de Gestão de Projetos, além da restrição de seqüência, é possível identificar um prazo denominado de latência (nos sistemas em inglês, lag), isto é, um período de tempo que deve ser contabilizado entre o fim da atividade predecessora e o início da atividade sucessora.

O diagrama de rede do projeto é uma representação gráfica das atividades e as relações de seqüência entre elas. São gráficos que auxiliam na análise e otimização do projeto. Existem basicamente três modelos de diagramas que podem ser seguidos, são eles: n

n

n

Montar a rede do projeto

O método do diagrama de precedência, que basicamente utiliza retângulos para representar as atividades, que são conectados por setas que representam as dependências entre elas. Esse método, que é utilizado na maioria dos sistemas computacionais de apoio à gerência de projetos, envolve quatro tipos básicos de relacionamento de seqüência entre atividades: o início do trabalho da atividade sucessora depende ou do início ou do término do trabalho da atividade predecessora; ou o término do trabalho da sucessora depende do início ou do término da predecessora (como acabamos de ver no Quadro 5.13). O método do diagrama de flecha, que faz uso de setas para representar as atividades, cujas dependências são esboçadas por meio de nós que as relacionam. Esse método utiliza apenas o relacionamento lógico do início do trabalho da atividade sucessora que depende do término do trabalho da atividade predecessora. O método do diagrama condicional faz uso de técnicas de diagramação e modelos de sistemas dinâmicos, o que permite representar atividades não seqüenciais, que é uma limitação dos métodos anterio-

178

PARTE 2

O Modelo

res. Essa não-seqüencialidade pode ser desde uma repetição de atividade, conforme existam necessidades para isso (como um erro ou inadequação resultante da primeira execução da atividade), até escolhas entre atividades sucessoras conforme o resultado da atividade predecessora. Uma vez montada a rede, o gerente de projeto poderá analisá-la para identificar possíveis inconsistências em termos de falha na identificação de atividades e restrições de seqüência. Feito isso, ele poderá passar à próxima atividade: a obtenção do cronograma do projeto, que é a descrição das atividades com as estimativas dos prazos e recursos.

5.8

Preparar cronograma

Na atividade Preparar Cronograma (veja a Figura 5.16), o gerente de projeto definirá uma programação de datas de início e fim das atividades. Essa estimativa depende do esforço necessário para a realização da atividade e da quantidade de recursos disponíveis, que também deverão ser definidas em detalhes nesse momento. A qualidade do resultado final dependerá da experiência do gerente e especialistas consultados na realização de tarefas similares em projetos de desenvolvimento anteriores e na verificação dos acertos e erros dessas previsões. Figura 5.16

Atividade de preparação de cronograma.

As informações de entrada para essas previsões de duração temporal são: a lista de atividades; as restrições e premissas inerentes às atividades, que podem afetar as estimativas de seus tempos de execução; a maior ou menor disponibilidade dos recursos para a realização das atividades, bem como a produtividade obtida com esses recursos, o que influencia sua duração; a memória de projetos passados seja em registros formais ou informais pela experiência dos membros das equipes de projeto, quanto às estimativas de tempos nas atividades e sua efetiva ocorrência quando da realização da atividade; e, por fim, as possíveis ameaças e oportunidades decorrentes de cada estimativa de duração das atividades. A saída é o cronograma, ou programação do projeto, que pode ser apresentado de diversas maneiras e conterá datas de início e fim esperados para cada atividade.

CAPÍTULO 5

Planejamento do Projeto

179

A melhor maneira de prever prazo é considerar a quantidade de recursos disA definição de prazos poníveis. Intuitivamente, isso é fácil de ser entendido. Imagine que você é encarredepende da definição da gado de determinar o prazo para o desenvolvimento de uma tarefa de montagem do quantidade de recursos protótipo de um barco. Se for preciso realizá-la sozinha, provavelmente você irá dedisponíveis finir um prazo específico. Se você tiver à disposição um técnico altamente especializado e com experiência na função, as tarefas poderão ser divididas e provavelmente esse prazo será menor, podendo chegar até a 50% do primeiro, isto é, com duas pessoas, o prazo seria a metade. Mas a questão é ainda mais complexa porque, se houver uma única pessoa à disposição, outro técnico especializado, mas com pouca experiência, provavelmente o prazo será menor que a primeira situação, solitário, e maior que a segunda, dado que o conjunto de tarefas a serem divididas provavelmente será menor. A forma-padrão de solucionar esse problema, adotada na área da Gestão de Projetos, é utilizar três parâmetros fundamentais na programação das atividades, são eles: esforço, duração e unidade de recursos. A idéia é definir a duração como função do esforço total, medido em quantidade de horas para realizar uma determinada tarefa. Dividindo-o pelo número de recursos disponíveis para executar a tarefa, teremos então a duração. Por trás dessa relação, encontra-se a premissa de que, ao se alocar o dobro de recursos para uma determinada tarefa, a duração será a metade do previsto inicialmente. Essa proposição diminui a complexidade do problema e facilita a programação, embora não seja válida sempre. No caso de atividades em que a divisão de tarefas não é possível ou exige esforço adicional de coordenação e transmissão de informações, a adição de recursos não diminui a duração na mesma proporção. Aplicando os três parâmetros, a primeira tarefa do gerente do projeto na preEstimar o esforço paração do cronograma é prever o esforço, quantidade de homens-horas, necessário necessário para cada tarefa. Para fazer isso, ele irá levar em consideração a natureza da atividade e também a classificação de complexidade e novidade do projeto, realizada na atividade anterior, a adaptação do modelo. Note que, dada a relação apresentada, a estimativa do esforço é independente da quantidade de recursos necessária. Assim, o gerente de projeto pode se concentrar nos dois problemas de maneira distinta, isto é, com base na complexidade de definir o esforço necessário e, depois, alocar os recursos disponíveis com base na quantidade de recurso disponível e metas de prazo. O resultado final será um prazo de realização da atividade bastante realista. A relação apresentada facilita a comparação dos diferentes projetos anteriores, permitindo uma estimativa com base em dados históricos bem mais precisa. Uma vez definido o esforço necessário em cada atividade, o gerente de projeto Alocar recursos poderá alocar os recursos. Além das informações anteriores, ainda são necessárias a EDT, a rede do projeto e a quantidade de esforços — uma informação crucial é a disponibilidade dos recursos da empresa. O gerente de projeto precisa saber quantas horas de cada tipo de recurso ele poderá utilizar, no intervalo de tempo que o projeto deverá transcorrer (definido na Declaração do Escopo). Essa informação é crucial, mas é difícil de ser obtida porque depende do somatório da dedicação dos recursos em cada um dos projetos da empresa. Na prática, muitas vezes essa informação não existe de maneira precisa e acaba ficando a cargo da experiência do gerente de projeto, que terá que ir atrás da informação ou confiar na sua vivência dentro da empresa. É aqui que os sistemas para Gestão de Projetos têm um papel muito imporA gestão da tante. As ferramentas mais sofisticadas possuem o recurso de criar um único condisponibilidade junto (pool) de recursos para a empresa, que é utilizado por todos os gerentes de de recursos projeto. Assim, se um gerente aloca um determinado recurso no seu projeto, sua disponibilidade será diminuída e outros gerentes não poderão alocar o mesmo recurso duas vezes. É a melhor forma do gerente de projeto possuir essa informação detalhadamente. O software é importante, mas, logicamente, não é suficiente. Ele agiliza os cálculos e a definição, mas a empresa precisa estar em um nível alto de experiência em planejamento para que ele funcione. É comum que os dados de uso de recursos e conclusão de atividades sejam reportados de maneira irreal, inviabilizando o uso do sistema. Exemplo disso é um recurso registrado com a carga de 8 horas semanais dedicadas ao projeto, mas, na

180

PARTE 2

O Modelo

prática, dedicando muito mais tempo para a realização da atividade sem que isso seja apontado no sistema; horas adicionais inclusive fora do sistema. Quanto maior o número de projetos simultâneos, mais facilmente esse problema se apresenta. A solução passa por aspectos culturais, além do software. É preciso que as pessoas estejam disciplinadas para reportar de maneira fiel sua dedicação ao projeto e saibam negociar eventuais problemas encontrados. As empresas com alto nível de maturidade de Gestão de Projeto têm como uma de suas características fundamentais um nível avançado de gerenciamento do conjunto de recursos. Isso significa que, independentemente de utilizar softwares ou não, o gerente de projeto consegue obter de maneira confiável a informação do número de horas disponíveis para cada recurso no decorrer do tempo de desenvolvimento do projeto. Com essa informação, ele definirá a quantidade de recursos para cada uma das atividades e registrá-la, obtendo, concomitantemente, a estimativa da duração. Nos sistemas de Gestão de Projetos, esse cálculo é automático, dado que os três parâmetros fundamentais, esforço, duração e unidades de recurso são dependentes ente si. Um detalhe importante é que esses sistemas geralmente dispõem do recurso de fixação, isto é, pode-se escolher qual dos três parâmetros será mantido constante, e uma alteração em um dos outros dois impactará em mudança apenas no parâmetro restante. Assim é preciso, antes de realizar a alocação, observar o método de fixação ajustado para a atividade, pois, do contrário, pode-se perder a informação de esforço definida no tópico anterior. Uma observação muito importante precisa ser feita. Na prática da Gestão de Definir esforços e alocação Projetos, é difícil separar essas duas tarefas, estimar esforço e alocar recursos. Isso podem ser atividades acontece porque o gerente de projeto, enquanto está determinando o esforço, pode concorrentes possuir uma boa informação sobre os recursos disponíveis e, assim, poderá adiantar o trabalho adicionando também os recursos. Nada errado em relação a isso. O problema acontece quando se pensa apenas em prazos. Pois, conforme vimos, o esforço é um parâmetro mais comparável entre diferentes projetos do que a duração. A duração pode variar de projeto para projeto conforme a quantidade de recursos destinada, enquanto o esforço depende apenas da tarefa. Duas tarefas iguais, em projetos diferentes, deverão ter o mesmo esforço. Por isso, seguir a seqüência identificar pacotes de trabalho e atividades, identificar seqüência, prever o esforço e alocar recursos é mais produtivo, pois os gestores de projeto da empresa identificarão melhor a quantidade de esforço necessária em cada tarefa. Ao final da alocação o gerente de projeto terá a primeira versão do cronograma Otimizar a programação do projeto, pois terá a informação completa das atividades, esforço necessário em de atividades e recursos cada uma delas e recursos alocados. Ele poderá, então, obter uma primeira estimativa de prazos das atividades, incluindo o prazo total do projeto. Esse prazo terá que ser comparado com os prazos previstos no documento de Declaração do Escopo. Caso não atinjam a meta estabelecida, o plano precisará ser revisto. Em caso contrário, também, pois, independentemente de atingir as metas, essa primeira programação pode ser aprimorada visando prazos menores e indo em busca de uma utilização mais racional dos recursos. Essas atividades são feitas concomitantemente, de maneira interativa. Por questões didáticas, elas serão explicadas separadamente. Várias técnicas podem ser utilizadas para o desenvolvimento do cronograma Análise e diminuição dos do projeto, e os dados de entrada podem ser processados de diversas formas, destaprazos do projeto cando-se: n

n

Gráficos. Uma forma de analisar a programação realizada é por meio de sua representação gráfica. Uma delas já foi apresentada — o gráfico da rede de atividades. Além desse, há dois outros fundamentais para o gerente de projeto, são eles: o Gráfico de Gantt e o Calendário. O Gráfico de Gantt é uma representação na qual se utilizam barras, alocadas no eixo horizontal, para indicar o período de início e fim das atividades. É a forma mais comum, prática e sintética de se apresentar o cronograma do projeto. O Calendário é uma visão em que as atividades são apresentadas tal qual tarefas em uma agenda. Analisando esses gráficos, é possível identificar inconsistências e mudar as atividades para obter melhorias. Técnicas de análise de redes. Existem técnicas de análise matemática da rede. Elas permitem calcular as datas cedo e tarde em que as atividades podem ser iniciadas e finalizadas. Essas informações permitem

CAPÍTULO 5

Planejamento do Projeto

n

181

identificar o chamado Caminho Crítico, isto é, a seqüência de atividades que está limitando a programação. Caso uma dessas atividades atrase, haverá um atraso na entrega do projeto. As principais técnicas de análise de redes são Critical Path Method (CPM), Graphical Evaluation and Review Technique (GERT), e Program Evaluation and Review Technique (PERT). Simulação de Monte Carlo. Trata-se da melhor maneira de simular os dados do projeto. Nesse método, trabalha-se variando as possibilidades de ocorrências das premissas e restrições em cada atividade, para se chegar a diferentes cenários e conseqüentemente a cronogramas de duração do desenvolvimento do produto.

O uso de sistemas de Gestão de Projetos é fundamental neste momento. Os sistemas-padrão de mercado oferecem recursos para gerar os diversos gráficos, realizam as análises PERT/COM e apóiam a realização de simulações. Aliás, os sistemas de Gestão de Projetos geralmente permitem que seus dados sejam exportados para planilhas eletrônicas, em que as simulações de Monte Carlo podem ser utilizadas. Feita a primeira versão da programação, é fundamental a realização de uma Racionalizando o uso análise detalhada da distribuição de recursos. Como a programação inicial preocudos recursos pa-se geralmente com a obtenção do menor prazo, é comum a existência de variação na carga de trabalho de um recurso, isto é, período com muito trabalho alocado e outros com carga insignificante ou sem atividades. Isso é prejudicial por vários motivos. Nos momentos em que a carga é elevada, pode haver perda na qualidade do trabalho por causa de cansaço. É o problema da sobrecarga de trabalho — agravada em projetos de produto por esses serem eminentemente intelectuais e dependentes de atenção aos detalhes. Nesse tipo de trabalho, tais como dimensionamento e verificações de especificações técnicas, o esforço prolongado é contraproducente, pois a fadiga do trabalho intelectual gera dificuldade de manter a atenção e a memorização, diminuindo o rendimento e aumentando o número de falhas. Os dois outros tipos de problema ocorrem nos períodos de baixa carga de trabalho. Nesse caso, além de baixar a produtividade do recurso, pode significar prejuízos em termos de custo. Por exemplo, um profissional com uma carga de uma hora por dia durante uma semana terá, se trabalhar oito horas por dia, 35 horas disponíveis. Se esse projeto estiver sendo realizado em uma localidade distante da empresa, pode ser difícil alocá-lo em outro projeto durante esse período, por causa da distância, por exemplo, transformando essas horas em custo adicional para o projeto. Em caso de existir a possibilidade de realocá-lo facilmente para outro projeto, pode haver desperdício de tempo em razão da mudança de tarefa, pois, para concentrar seus esforços em outro assunto, ele gastará um período de tempo. Outro exemplo é o problema que ocorre quando há um pequeno hiato na distribuição de tarefas para o recurso, por exemplo, um ou dois dias sem atividade, entre duas atividades distintas. Esse período de tempo pode ser pequeno demais para que ele se dedique a qualquer outro projeto, transformando-se em custo para o projeto. Para evitar todos esses problemas, deve-se analisar a carga de cada um dos recursos, com o intuito de garantir um nível adequado e constante de trabalho. Essa atividade é denominada de Nivelamento de Recursos. Deve-se também procurar, durante o nivelamento, combinar atividades que exigem grande atenção com atividades repetitivas para se obter uma maior produtividade e evitar o esgotamento mental do colaborador. A análise do nivelamento é auxiliada por três técnicas: gráfico de recurso, relatório de uso dos recursos e uma heurística-padrão para tomar as decisões. Com o cronograma agora otimizado (recursos nivelados e prazos racionaliEstabelecer pulmões para zados), o esforço no cronograma ainda não terminou. Os procedimentos apreseno projeto tados até o momento são os métodos clássicos empregados na Gestão do Projeto. Nada errado com eles, pois funcionam perfeitamente, mas não levam em conta um aspecto cultural muito importante que os afeta imensamente: o comportamento dos colaboradores. As pessoas não são máquinas e utilizam diversos mecanismos de proteção quando começam a ser avaliadas e são solicitadas a dar previsões para entrega de trabalhos. Esses mecanismos as levam a propor estimativas de prazo muito maiores do que o normal para a atividade e, depois, como os prazos são longos, deixam as atividades para ser reali-

182

PARTE 2

O Modelo

zadas próximo às datas de entrega. Como conseqüência, além de um tempo total de execução do projeto maior, fica-se mais vulnerável aos imprevistos. A Teoria das Restrições trouxe uma inovação importante nesse aspecto, o conceito de “pulmão”. Segundo essa técnica, solicita-se aos especialistas que forneçam não o esforço médio, mas um valor otimista. Muitas vezes, isso é feito de maneira “cega”, dividindo a estimativa obtida do especialista por três. Em seguida, o intervalo de tempo economizado é alocado em pontos específicos do projeto na forma de pulmões (veja a Figura 5.17). Um pulmão é um intervalo de tempo entre duas atividades que amortecerá possíveis atrasos nas atividades anteriores. Faz-se, então, um sistema de comunicação visual no qual todas as pessoas do projeto podem acompanhar o “consumo” dos pulmões. É uma técnica interessante porque as pessoas trabalham pressionadas por prazos reais, sem margens para deixar as ações para depois. Qualquer imprevisto será amortecido nos pulmões e reconhecido imediatamente pelo gerente de projeto e demais membros do time, que poderão tomar medidas cabíveis para solucioná-los. Figura 5.17

Exemplo esquemático do uso de pulmões na programação do projeto.

Assim, com o plano otimizado, com estimativas de esforços realistas, o gerente de projeto deverá introduzir pulmões de projetos em pontos estratégicos. Os pontos ideais são o final de conjunto de atividades concorrentes que compartilham recursos. Deve-se lembrar que não basta incluir os pulmões — parte importante dessa técnica é torná-los visíveis para todos os envolvidos no projeto, por exemplo, por meio de quadros espalhados no ambiente. O cronograma com pulmões é a versão final. Se houver tempo disponível, é Consolidar o cronograma boa prática enviá-lo para especialistas ou outros gerentes de projeto para uma redo projeto visão. Em seguida, deve-se congelar essa primeira versão que será revista no início da próxima fase, naquele momento, já pelo time de projeto. Como vimos anteriormente, o cronograma pode ser apresentado em diferentes visões: diagrama de rede de atividades, Gráfico de Gantt e na forma de Calendário do Projeto. Sem dúvida, a mais intuitiva para os diversos profissionais é a segunda, o Gantt. Os gerentes de projeto, por estarem familiarizados com todas essas técnicas e terem ferramentas sofisticadas à disposição, têm uma tendência de criar gráficos sofisticados e com muita informação, os quais podem não ser ideais para a maioria dos profissionais envolvidos. Deve-se ter o cuidado de apresentar somente as informações essenciais e de forma simples. Um conceito que pode ser útil nesse momento é a Gestão à Vista, que se originou na área de manufatura, com a teoria de qualidade total e, mais recentemente, com a teoria do Lean Production, e hoje vem sendo adotado

CAPÍTULO 5

Planejamento do Projeto

183

na área de projetos. Esse princípio é o de utilizar quadros e indicações físicas simples, espalhadas pelo ambiente de trabalho, contendo as informações sobre o andamento do projeto, como o status do cronograma e comprometimento de pulmões. Mudanças no layout do ambiente de trabalho podem ser necessárias, e uma prática comum é a criação das chamadas “Salas de Operação” (War rooms), locais específicos em que são expostas em quadros as informações principais de andamento e conclusão dos projetos. Um cuidado a ser lembrado é que o acesso a esses ambientes precisa ser restringido conforme o nível de sigilo exigido no projeto e definido na Declaração do Escopo. Como resultados complementares, pode-se ter: a documentação das premissas Resultado adicional da e restrições identificadas, que serviram de apoio à construção do cronograma; os reatividade Preparar cursos requeridos por período de tempo e suas atualizações de nivelamentos; as posCronograma síveis alternativas de cronograma conforme mudanças de cenário de execução do projeto; e o plano de gerência do cronograma que define, dentre outros aspectos, como as mudanças no cronograma serão gerenciadas.

5.9

Avaliar riscos

A presente atividade (Figura 5.18) trata das condições de risco, que são normalmente maiores em projetos com práticas de gestão inadequadas e com grande participação e influência de agentes externos autônomos, sob o qual é difícil exercer algum controle. Também são maiores em projetos com grau de inovação elevado, tais como uma plataforma, do que, por exemplo, um derivativo. Figura 5.18

Atividade de avaliação de riscos.

Quanto maior a incerteza e imprevisibilidade no que se refere à ocorrência de eventos indesejáveis ao longo do projeto, e quanto menor as possibilidades de soluções disponíveis caso um evento ocorra, maior o potencial de riscos do projeto, o que compromete seu custo, cronograma e/ou qualidade. Um efetivo planejamento dessa gestão de riscos deve buscar o equilíbrio ou balanço entre a necessidade de reduzir os riscos de um projeto e aumentar sua previsibilidade, com a necessidade de buscar opções novas e ino-

184

PARTE 2

O Modelo

vações no produto/projeto — o que aumenta sua instabilidade. Ou seja, um planejamento para gerenciar a dicotomia entre riscos e inovação versus estabilidade e previsibilidade. Tentar reduzir a incerteza, eliminar eventos não oportunos e melhorar a quantidade e a qualidade de alternativas de soluções constituem a essência da avaliação e gestão de riscos do projeto. Essa avaliação se baseia em duas dimensões básicas: a probabilidade de ocorrência e o efeito potencial do risco. Uma boa avaliação de riscos deve basear-se em ambas. Se a probabilidade de algo acontecer é alta, mas o impacto no projeto é insignificante ou inexistente, não será preciso se preocupar. Mas, por outro lado, se a probabilidade é muito pequena e o impacto é grande, levando ao encerramento do projeto, então, deve-se tomar ações preventivas. Para realizar essa avaliação, um conjunto de seis tarefas é recomendado. Deve-se levar em consideração os limites de riscos possíveis de correr no proPlanejar a avaliação de jeto conforme suas características e importância para a organização. risco no projeto de DP Para esse planejamento, algumas informações são necessárias: a EDT; a Declaração do Escopo do Projeto; o cronograma do projeto; o project charter (Minuta do Projeto) autorizando formalmente o projeto; as políticas de gerenciamento de riscos da organização; as funções e responsabilidades já definidas para o projeto e conseqüente autoridade para tomada de decisões e gerenciamento de riscos; as tolerâncias a riscos que os envolvidos no projeto declaram e que apresentaram em projetos de DP anteriores dos quais participaram; e, por fim, os padrões determinados pela organização para orientar a confecção do planejamento de gerenciamento de risco de seus projetos de DP. A sistemática mais comum para o planejamento da avaliação e gerência de risco do projeto é a discussão por meio de reuniões de trabalho (workshops). Deverão participar o gerente de projeto e especialistas e profissionais da área de desenvolvimento que dominam os diversos aspectos do projeto. Conforme o tamanho do projeto, poderá ser feito de maneira isolada pelo próprio gerente ou poderá ser necessário até duas ou três reuniões com uma série de especialistas. O resultado dessa tarefa será a definição de um conjunto de elementos que pode conter os seguintes pontos: a) os diferentes procedimentos e fontes de informação que devem ser utilizados para avaliações dos riscos e de sua gerência ao longo da execução do projeto de DP; b) a definição e padronização dos critérios de pontuação e interpretação dos tipos de riscos que podem ocorrer ao longo do projeto de DP; c) um mapeamento do grau de tolerância aos riscos do projeto, entre os diferentes atores envolvidos — áreas funcionais da empresa, fornecedores, clientes etc —, o que subsidia as necessidades de intervenção diferenciadas na gestão do risco; d) o conteúdo e o formato desejáveis para os documentos que serão gerados pelo trabalho de avaliação e gerência de risco — análises, resultados etc —, de modo a facilitar a comunicação com as partes envolvidas e as consultas no futuro; e) a definição da equipe para a gerência de risco e seu líder, cuja composição pode variar ao longo do projeto conforme o tipo de avaliação de risco e gerência, e que deve envolver, além de pessoas da equipe de projeto, alguns membros independentes em relação ao projeto; f) as verbas disponíveis para a realização das ações e gastos com recursos necessários à gerência de risco do projeto; g) a distribuição das ações do gerenciamento de risco ao longo do cronograma de execução do projeto; h) a forma com que deve ser avaliado e auditado, no final do projeto, todo o trabalho de gerência de risco realizado, e uma determinação de como os documentos, experiências e lições aprendidas desse trabalho devem ser devidamente arquivados para aprendizado de futuros projetos de DP. Os itens a, b, c e d que versam sobre a forma de análise dos riscos, isto é, os métodos e critérios, serão sempre necessários. É interessante que a empresa possua uma metodologia-padrão, adotada em todos os projetos. Isso facilitaria, inclusive, a comparação entre os diferentes projetos. O item e só é necessário para programas, compostos de vários projetos com alto nível de complexidade.

CAPÍTULO 5

Planejamento do Projeto

185

Uma das principais tarefas da presente atividade é a identificação dos riscos Identificar e caracterizar os que podem afetar o projeto e suas características. Esse é o primeiro passo para que riscos potenciais ao possamos tomar ações visando controlá-los. projeto de DP Novamente, a forma básica de trabalho é a reunião. A identificação e a caracterização dos riscos potenciais são realizadas por meio de várias discussões entre o gerente de projeto e os especialistas dos vários setores da empresa, além dos envolvidos externos ao projeto, tais como fornecedores e clientes. A identificação dos riscos em um projeto requer uma série de informações de outras atividades/tarefas do Planejamento do Projeto. Começa pelo plano realizado na tarefa anterior, e inclui a busca de possíveis riscos por causa de decisões que serão tomadas na execução do projeto, com base no que foi planejado no: project charter, EDT, descrição do produto, cronograma e estimativa de custos, plano de recursos e de aquisições, lista de restrições e premissas, dentre outros. Além dessas informações, também é importante o conhecimento das categorias de risco mais influentes na indústria das quais o projeto de desenvolvimento faz parte. De forma genérica, normalmente essas categorias incluem: n

n

n

riscos em razão da complexidade da tecnologia envolvida no produto ou em sua forma de produção, que podem significar riscos de qualidade, atrasos ou custos adicionais ao projeto, pela não-maturidade tecnológica, as instabilidades por causa de maior freqüência de mudanças dos padrões tecnológicos etc; riscos em razão de inabilidade e/ou inexperiência em gerenciar projetos de desenvolvimento de produtos, que também envolve fatores organizacionais negativos como a mudança constante de prioridades na empresa quanto aos seus projetos de DP, excessivas disputas de recursos com outros projetos etc; e riscos em razão das possibilidades de mudanças em legislações e regulamentações ambientais, de proteção ao consumidor etc, que podem ocorrer ao longo da realização de um projeto de desenvolvimento de produtos.

Outro conjunto de informações úteis para se determinar a identificação dos riscos em um projeto são aprendizados de projetos anteriores, notadamente resultados e experiências de diagnóstico e avaliações de risco nesses projetos. Deve-se atentar, também, para problemas que ocorreram no passado e que se deve evitar. Por exemplo, se um determinado fornecedor do tipo parceiro tem um histórico de atrasos em projetos anteriores, será preciso tomar ações preventivas quanto a esse risco, pois a probabilidade de acontecer novamente será bastante alta. Coletadas essas informações, devem ser agora trabalhadas por alguns procedimentos para a identificação de risco no projeto. Um primeiro procedimento é realizar uma revisão detalhada de todos os registros e documentos coletados, organizando-os com o propósito de subsidiarem a identificação de risco. Em seguida, um segundo procedimento é reunir/agrupar essas informações, o que pode ser feito por uma ou mais das seguintes maneiras: n

n

n

brainstorming, que normalmente é o mais utilizado, resultando de suas discussões uma listagem de riscos, os quais, depois, serão analisados em termos quantitativos e qualitativos; técnica Delphi, que promove a coleta, via questionário aplicado a envolvidos com o projeto, de uma listagem de potenciais riscos, e o submete para apreciação de pessoas experientes em projetos de DP, mantidas anônimas, retornadando essa apreciação aos respondentes iniciais. Repetindo-se algumas vezes esse ciclo, pode-se chegar a um melhor consenso quanto aos riscos principais de um projeto, pois esse procedimento dificulta que pessoas específicas influenciem mais o resultado das discussões, como ocorre no brainstorming; entrevistas com gerentes e líderes experientes em projetos de DP, além de especialistas no assunto de identificação de riscos. Informações que descrevem o projeto, como a EDT e suas premissas, são sub-

186

PARTE 2

n

O Modelo

metidas a essas pessoas em uma entrevista, para que sejam analisadas com base em suas experiências quanto ao potencial de gerarem riscos ao projeto; também pode ser empregado o procedimento de análise de forças, fraquezas, oportunidades e ameaças 6 (conhecidos pela sigla SWOT , em inglês), para levantar potenciais riscos.

Um terceiro procedimento é uma checklist, que pode ser utilizada para identificar riscos no projeto baseando-se em comparações com outros projetos semelhantes. Possui a vantagem de ser um procedimento rápido e simples, porém dificilmente será completo em termos da quantidade de riscos. Limita-se a buscar no projeto em análise os mesmos tipos de riscos já percebidos em outros projetos, dando menor atenção a novas possibilidades de riscos. Um quarto tipo de procedimento é a análise das premissas ao qual o projeto está se baseando, verificando-se lacunas na exatidão e/ou fundamentação dessas premissas que podem trazer riscos ao projeto. Essas premissas estão presentes na Declaração do Escopo do Projeto. Por fim, de forma complementar aos procedimentos anteriores, certas formas de busca das causas de problemas em um projeto também podem ser úteis para a identificação de riscos. Um exemplo desse tipo é o diagrama de causa e efeito (que também recebe as denominações de “espinha de peixe” ou Ishikawa). O resultado principal da presente tarefa é a geração de uma listagem detalhando os riscos prováveis do projeto, com a descrição objetiva das características de cada um. Essas características podem incluir quais são os sinais ou advertências que indicam uma maior probabilidade do risco estar em condições efetivas de ocorrer. Como resultado indireto da presente tarefa, pode surgir a necessidade de ações em outras partes do plano do projeto, como o cronograma, a EDT etc, para reduzir suas vulnerabilidades a certas ocorrências que aumentam o risco do projeto. Essa análise utiliza procedimentos qualitativos para estimar a probabilidade de Analisar qualitativamente ocorrência dos riscos e a conseqüência ou impacto dessa ocorrência no projeto. os riscos potenciais Com essa análise, pode-se mapear quais são os riscos que potencialmente mais ameaças classificando-os segundo trazem ao projeto ao longo de sua execução, de forma que ações sejam previstas para seus efeitos no projeto atenuá-los ou eliminá-los. de DP A presente avaliação qualitativa não se esgota nesse momento de Planejamento do Projeto. Ela deve ser periodicamente revisada ao longo de sua execução, de forma que se mantenha atualizada com as mudanças ao longo do tempo, nos tipos e características dos riscos e suas possibilidades de ocorrências. Ressalte-se também que a análise qualitativa deve estar coordenada com a avaliação quantitativa e também com o planejamento das respostas aos riscos — tarefas que serão especificadas em detalhes nos tópicos seguintes dessa atividade de diagnóstico e gestão de riscos do projeto. Para a execução da análise qualitativa dos riscos, algumas informações são desejáveis e devem ser coletadas: n

n

n

n

6

o plano de gerência de riscos e a identificação dos riscos com seus impactos potenciais no projeto, informações advindas das tarefas anteriores da presente atividade; a situação do projeto em termos do portfólio de produtos e projetos, em especial se será executado com urgência em relação a outros projetos e/ou se é fundamental para a empresa, de forma que riscos devem ser minimizados, pois há reduzidas chances de corrigir seus efeitos; o tipo do projeto, ou seja, se é um projeto simples (por exemplo, um derivado), e, portanto, com riscos mais previsíveis, ou se é um mais complexo (por exemplo, uma plataforma), o que requer mais esforços para prever e avaliar riscos, dado o conjunto de novidades que esse tipo de projeto normalmente representa; as premissas que foram utilizadas para a identificação dos riscos, e que devem ser também consideradas para sua avaliação qualitativa.

Strength, Weakness, Opportunity, Threat (SWOT).

CAPÍTULO 5

Planejamento do Projeto

187

Dadas essas informações, é possível utilizar diferentes procedimentos para avaliar os riscos. Um procedimento de avaliação subjetiva é submeter cada risco a uma apreciação em termos de probabilidade e conseqüência (impacto) ao projeto de sua ocorrência. Em termos qualitativos, esses dois parâmetros podem se situar em uma escala entre muito alto, alto, moderado, baixo e muito baixo. A avaliação dos dois parâmetros para cada risco específico, feita por mais de uma pessoa envolvida no projeto, permite que se tenha uma avaliação geral do conjunto de riscos do projeto e que se delimitem aqueles que precisam ser tratados com mais rigor. Um outro procedimento que segue a mesma lógica para realizar a análise qualitativa é uma matriz de graduações de risco, diferenciando-se do anterior apenas por usar uma escala ou matriz numérica em vez de nominal. A análise qualitativa apontará os riscos que merecem análises detalhadas, para os quais deve-se empregar a quantificação e os planos mais cuidadosos de gerência de risco. Esses riscos são aqueles que apresentam, ao mesmo tempo, elevada probabilidade e impacto em sua ocorrência. Além desses dois procedimentos, também devem ser analisadas, de forma complementar, as premissas em que se baseou a identificação de risco do projeto. Essa análise qualitativa envolve julgar essas premissas em termos de sua estabilidade/permanência ao longo do projeto, ou seja, quanto elas podem permanecer efetivas ou deixar de fazer sentido, e que decorrências isso traria aos riscos previstos no projeto. Os resultados desses procedimentos de análise qualitativa são basicamente os seguintes: n

n

n

uma classificação do risco de um projeto comparativamente ao portfólio de projetos de desenvolvimento da empresa, que é uma informação útil para a tomada de decisões do tipo continuar ou não o projeto, aumentar ou reduzir recursos para o projeto etc; uma listagem de riscos classificando-os quanto à urgência com que devem ser tratados, em razão das conseqüências que podem trazer em termos de custos, qualidade e prazos do projeto; o destaque para aqueles riscos críticos que requerem análises adicionais do tipo quantitativas e ações prioritárias de planejamento de resposta (gerência) do risco.

A análise quantitativa normalmente é usada de forma adicional à avaliação quaAnalisar litativa, conforme se faça necessária para confirmar ou verificar seus resultados — quantitativamente os isso se houver tempo e recursos disponíveis no planejamento para mais essa análise riscos potenciais avaliando de risco. Os resultados que a mesma tendência possui nas duas avaliações reforçam a sua probabilidade de necessidade de uma ação específica de gerenciamento de risco, de maior ou menor ocorrência e seu impacto intensidade, conforme o caso. no projeto de DP Das tarefas anteriores da presente atividade de avaliação de riscos, a análise quantitativa requer as seguintes informações: o plano de gerência de riscos e os riscos identificados no projeto; e a lista de riscos que exigem maiores prioridades de ação e/ou análises adicionais. Também são úteis para a presente análise as informações sobre quantificações de riscos em outros projetos de desenvolvimento de produtos da empresa, os conhecimentos e experiências sobre quantificação de riscos provenientes de fontes de informação além do DP, internas ou externas à empresa, incluindo especialistas no assunto. Para processar essas informações, pode-se fazer uso dos seguintes procedimentos: n

n

n

entrevistas com especialistas no assunto que possam auxiliar a quantificar a probabilidade e tecer cenários sobre o impacto no projeto; análise de sensibilidade e/ou análise de árvore de decisão: o primeiro procedimento auxilia na determinação dos riscos de maior impacto no projeto, enquanto o segundo trabalha com um diagrama que ilustra o impacto da cadeia de decisões que será preciso tomar no projeto, quantificando o impacto de cada decisão em termos de custos, ganhos, riscos etc; e simulação: emprego de modelos matemáticos que tentem traduzir o projeto completo e as incertezas às quais será submetido. A técnica de Monte Carlo é comumente empregada nesse sentido.

188

PARTE 2

O Modelo

O resultado proveniente da análise quantitativa de riscos é agora um valor de probabilidade de ocorrência do risco e dados numéricos sobre o impacto nas dimensões de prazo, custo e qualidade. Essa quantificação dos riscos permite previsões mais precisas quanto às possibilidades efetivas de que os objetivos do projeto sejam atingidos, com base nas informações de seu planejamento. Esse planejamento, com base nos resultados das tarefas anteriores da presente Planejar ações em resposta atividade, busca delinear respostas preventivas e reativas para lidar com os riscos deaos riscos potenciais tectados. Esse plano de ações deve ser compatível com a criticidade do risco ao proanalisados jeto e com o contexto organizacional do projeto, em termos do custo e aceitação de impactos que a resposta pode causar a outras partes do projeto. As informações necessárias para o referido plano de respostas aos riscos advêm principalmente das tarefas anteriores: o plano de gerência de risco e a lista de riscos priorizados e suas qualificações, as classificações dos riscos do projeto, as análises quantificadas dos riscos e as previsões do projeto executado de atingir o planejado, listas de respostas potenciais aos riscos e a identificação dos membros do projeto que podem ficar responsáveis por cuidar dessas respostas, e tolerâncias da organização aos riscos. Dadas essas informações, deve-se definir ações que farão parte de um plano de respostas aos riscos do projeto. O propósito básico dessas ações é o mesmo: escolher a(s) melhor(es) resposta(s) para enfrentar o risco e, após essa escolha, detalhar como essa resposta pode ser implementada. Existem três formas básicas de ações para se precaver de um risco e que devem ser conhecidas: n

n

n

Ações que eliminem totalmente a fonte do risco. Esse é o procedimento mais recomendável e deve ser prioritário. São mudanças no plano do projeto visando eliminar as condições para que o risco venha a ocorrer. O limite desse procedimento é que muitas vezes as mudanças para isso requerem equipamentos de melhor qualidade ou métodos de trabalho mais sofisticados que podem comprometer condições básicas do projeto, como os custos. Exemplo: um projeto grande pode envolver o translado do protótipo do laboratório para o local de testes. Se houver riscos associados ao transporte, uma solução seria construí-lo em uma unidade perto do campo de testes, eliminando totalmente a possibilidade de ocorrência. Ações que diminuam a probabilidade de ocorrência dos riscos. Procedimento que envolve a redução até patamares aceitáveis da probabilidade e/ou impacto de ocorrência do risco. Por exemplo, a redução da complexidade de execução das atividades do projeto do produto, uma maior verificação dos resultados dessas atividades etc. podem ajudar na redução de probabilidade de certos riscos de falhas de projeto ocorrerem (cálculos errados, análises pouco criteriosas etc.). Já a capacidade de criação rápida de forças-tarefas para solucionar com urgência problemas detectados no projeto pode reduzir o impacto dos riscos. Seja por um caminho ou outro, há obviamente limites de recursos e disponibilidade de tempo que restringem esses procedimentos de resposta ao risco. Ações que diminuam o impacto dos riscos. Outro tipo de ação para responder aos riscos é diminuir o impacto, caso ele venha a ocorrer. Exemplos são mudanças nos planos para diminuir a interdependência entre as atividades (conseqüentemente, diminui-se o impacto de atrasos em uma das ações); no caso de atividades que dependam de recursos humanos especializados, realizar o trabalho cooperado com fornecedores e especialistas para que existam pessoas que possam assumir as atividades em casos de incapacidade do recurso; declaração em manuais e outros meios das responsabilidades do cliente em casos de mau uso do produto; dentre outras possibilidades. Dentre as ações desse tipo, há aquelas chamadas de contingência, que deverão ser disparadas no momento da ocorrência do risco. É o caso de enviar as especificações para dois fornecedores. Se um deles atrasar muito, pedir a peça para o segundo. Nesse caso, ele já teria um conhecimento do assunto, e o tempo para solucionar o problema seria menor.

Os maiores riscos deverão ter mais de um tipo diferente de ação. Algumas delas podem significar aumento de custo do projeto, mas, estando dentro das metas previstas na Declaração do Escopo, elas deveriam ser adotadas. O barato pode sair muito caro caso haja algum imprevisto. Mas, cabe à equipe de projeto aceitar integralmente o risco. No caso dos riscos menores, não prioritários, deve-se adotar ações somente no caso de não impactarem em custos para o projeto.

CAPÍTULO 5

Planejamento do Projeto

189

O resultado dessa tarefa será, então, o plano de resposta aos riscos. Esse plano deve descrevê-los e identificar as áreas e objetivos do projeto que podem ser afetados por eles, análises qualitativas e quantitativas, as causas que os originam e as respostas escolhidas para solucioná-los. Em outra parte desse plano, deve-se relacionar quem serão os responsáveis por implementar as respostas escolhidas, como isso será feito em termos de ações, recursos e prazos, quais foram as decisões tomadas a respeito de cada risco no planejamento, e quais os riscos residuais que ficarão e aqueles indiretamente criados pela adoção de uma resposta. Outros resultados dessa tarefa são os acordos contratuais, especialmente entre a empresa e parceiros externos do projeto do produto, especificando a responsabilidade de cada parte perante os riscos assumidos no projeto. Decisões da presente tarefa devem indicar o nível de reserva monetária necessário ao projeto, isto é, a quantia de gastos adicionais para dirimir riscos potenciais do projeto. Esse valor será incluído no orçamento para que o time tenha como responder prontamente na iminência de um dos riscos planejados. Durante a execução efetiva do projeto, deve-se continuamente realizar o conPlanejar como deve ser o trole e a monitoração dos riscos, enfim sua gestão, conforme planejado. Durante a controle e a monitoração execução do projeto, mudanças no ambiente podem alterar as ameaças e trazer de riscos ao longo de novas oportunidades também, o que afetará os tipos de riscos a que estará submetodo o DP tido. Rapidez e destreza no acompanhamento dos riscos ao longo do projeto são necessárias para acionar adequadamente as respostas planejadas ou, em certos casos, buscar novas respostas mais efetivas. Com o avanço do projeto nas fases do desenvolvimento do produto, do projeto informacional em direção ao seu lançamento, reduz-se gradativamente as incertezas que permeiam o projeto, e, então, é possível começar a descartar a possibilidade de ocorrência de vários dos riscos previstos. Por outro lado, quanto mais próximo do lançamento, maior será o impacto da ocorrência de um risco, se esse necessitar de retrabalho no projeto para saná-lo ou atenuá-lo.

5.10 Preparar orçamento do projeto Tendo como base os resultados das atividades anteriores do planejamento, bem como dados históricos de orçamentos de projetos de DP realizados pela empresa, inicia-se a atividade de preparar o orçamento completo do projeto, Figura 5.19. Todas as informações do planejamento são necessárias nesse momento, mas duas certamente serão as mais utilizadas: o cronograma que sintetiza toda a duração das atividades, esforços e recursos necessários e a Declaração do Escopo que delimita a responsabilidade da empresa e cada um dos parceiros. Essa atividade pode ser separada em duas tarefas, descritas a seguir. A estimativa de custos dos recursos empregados em cada atividade de desenPrevisões dos custos volvimento serve para compor uma estimativa de custo do produto final resultante. relacionados às atividades Embora esse custo seja apenas um dos componentes do preço final do produto, que e aos recursos planejados é muito afetado também por decisões de negócio da empresa e oscilações do ampara o DP biente em que o produto compete, ele serve para trazer uma estimativa, logo no Planejamento do Projeto, de que níveis de preço final do produto o tornariam viável e cobririam os custos envolvidos. Para estimar esses custos, são necessárias algumas informações de outras partes do Planejamento do Projeto: n

n n

n

da EDT, que, ao ser seguida para essa tarefa de estimativa dos custos, garante que não ficou esquecida nenhuma atividade e/ou trabalho previsto no DP; das necessidades de recursos definidos e planejados para as atividades de desenvolvimento; dos valores ou estimativas confiáveis de custos-padrão para uso dos recursos, como o custo horário de pessoal, o custo para a realização de um teste ou ensaio etc.; das estimativas de tempo de duração de cada atividade;

190

PARTE 2

Figura 5.19

n

n

n

O Modelo

Atividade de preparação do orçamento do projeto.

da memória de informações de custos dos vários tipos de recursos normalmente empregados em projetos de DP, como os registros a respeito em projetos anteriores da empresa, e também a própria lembrança dos membros mais experientes, envolvidos com essa questão em projetos passados; do sistema contábil da empresa, a estrutura com que as informações financeiras são registradas, para que as estimativas de custos considerem as categorias contábeis corretas; e das informações provenientes das avaliações de risco do projeto e de suas atividades (realizadas em outra atividade do planejamento), pois, dependendo dos riscos envolvidos e de seus efeitos, diferentes projeções de custos precisam ser pensadas.

Obtidas essa informações, a tarefa seguinte é analisá-las fazendo, para isso, o uso de certos procedimentos para a estimativa dos custos. Um desses procedimentos é a estimativa por analogia ou top-down, em que a principal base para se chegar aos custos previstos do projeto atual são os custos reais provenientes de projetos anteriores similares. As estimativas por analogia possuem a vantagem de ser mais rápidas e simples do que outros procedimentos, porém tendo menor precisão e sendo mais dependentes de pessoas com experiência e especialização para comparar custos entre projetos de diferentes momentos (e contextos) da empresa. Esse procedimento é particularmente interessante de ser usado quando há um bom levantamento de custos previstos e efetivados nesses projetos anteriores, e também nos momentos iniciais do projeto em que se está estimando os custos, visto que, nesse momento, há normalmente poucas ou escassas informações detalhadas sobre o projeto, que permitam estimar os custos por outras formas. Quando há mais informações disponíveis do projeto em planejamento, pode-se, então, aplicar um outro procedimento de estimativa dos custos, que é feito por meio de modelos paramétricos. Nessa forma de estimativa, basicamente modelos matemáticos são alimentados por dados e informações (parâmetros) do projeto, resultando em previsões para os custos dos recursos que serão utilizados nas atividades do projeto. Esses modelos podem variar significativamente em termos de complexidade de uso e precisão dos resultados, e atingirão melhores desempenhos à medida que forem utilizando modelos mais próximos da realidade do projeto de DP da empresa, alimentados por parâmetros precisos e confiáveis, e com certa flexibilidade para moldar as diferentes características que cada projeto de DP da empresa normalmente possui. Um terceiro tipo de procedimento é a estimativa de baixo para cima (botton-up), em que se parte dos custos estimados do trabalho a ser realizado e dos recursos a serem empregados, que constituem cada uma das atividades previstas para o DP, agrupando-se progressivamente esses resultados pontuais até se chegar à estimativa

CAPÍTULO 5

Planejamento do Projeto

191

de custos de recursos para todo o projeto. Esse procedimento, se de um lado permite resultados com certa precisão pelo detalhamento específico “item a item”, por outro pode ser dispendioso e demorado para um planejamento, especialmente em projetos com muitas e complexas atividades e recursos. Na estimativa dos custos, pode-se utilizar um ou mais dos procedimentos anteriores, que também podem ser apoiados ou agilizados por intermédio de softwares ou sistemas computadorizados de gerência de projetos e planilhas. Como resultado final do emprego de um ou mais dos procedimentos anteriormente descritos, chega-se a estimativas quantificáveis dos custos dos recursos utilizados no projeto. Essas estimativas são normalmente feitas em unidades monetárias, que venham a permitir comparações com outros projetos da empresa, embora, em certos casos, também se apliquem outras unidades de medida como homens-horas etc. Nas estimativas também devem ser consideradas previsões e reservas de custos adicionais para contingências em razão das avaliações de risco do projeto. Uma indicação do intervalo de precisão e confiança conseguido nessas estimativas de custo deve ser especificada, sabendo-se que podem ser refinadas ao longo da execução do projeto, pela maior disponibilidade e confiabilidade dos dados e informações sobre o projeto. Adicionalmente aos resultados das estimativas de custos, pode ser conveniente a manutenção dos documentos e outros registros que mostrem as bases, premissas, interpretações e discussões utilizados para encontrar esses resultados, visto que constituem uma importante memória do aprendizado ao se realizar a presente tarefa do Planejamento do Projeto. Por fim, um plano de gerenciamento dos custos do projeto pode ser elaborado com base nessas estimativas levantadas, especificando que ações devem ser tomadas conforme se observem variações nos custos estimados. Os custos estimados para as atividades do projeto precisam ser agrupados em Alocação orçamentária um orçamento a ser submetido para aprovação, e que estabelece uma base line de dos custos estimados custo, útil para medir o desempenho do projeto. Como informações de entrada para a realização da presente tarefa, tem-se: as estimativas de custos, como descritas na tarefa anterior; a EDT, que permite identificar os elementos do projeto em que os custos serão efetivamente alocados; o cronograma do projeto, sabendo-se, assim, em que intervalos de tempo do projeto planeja-se alocar os custos — as datas previstas de início e término das atividades do projeto; e, por fim, o plano de gerenciamento de riscos, à medida que esse inclui as previsões de contingências de custos. Tratando-se essas informações com um ou mais dos mesmos procedimentos utilizados na tarefa anterior de estimativas de custos — analogia ou top-down, modelos paramétricos, botton-up —, obtém-se como resultado o desenvolvimento dos orçamentos das atividades de execução do projeto. Agrupando-se adequadamente esses orçamentos, obtém-se a baseline de custo do projeto, ou seja, o referencial que deve ser utilizado para o acompanhamento da evolução dos custos do projeto, quando de sua execução efetiva no desenvolvimento do produto. Durante a execução do projeto, podem ser necessárias mudanças em seu orçamento, motivadas pelas mais diversas causas, sejam adaptações do projeto do produto a novas realidades tecnológicas ou de mercado, sejam correções no projeto advindas de lacunas do Planejamento do Projeto. É adequado que, na presente atividade, também se planeje como deve ser o controle dessas mudanças e os custos dela decorrentes, o que inclui: entender as causas das mudanças durante a execução do projeto, tanto aquelas em decorrência de melhorias como a correção de lacunas, e registrá-las como memória do projeto a ser utilizada em futuros planejamentos; integrar essas mudanças do orçamento e da baseline de custo com modificações (advindas das mesmas causas), no escopo, cronograma, avaliação de riscos etc. que implicam variações do plano do projeto, com custos daí decorrentes que devem ser monitorados.

5.11 Analisar a viabilidade econômica do projeto Embora o foco principal do gerenciamento dos custos do projeto direcione-se para os custos dos recursos necessários à implementação de suas atividades, esse gerenciamento cada vez mais busca considerar os efeitos das decisões do projeto no custo de utilização de seu produto resultante. Essa abordagem mais ampla dos custos do projeto, e sua decorrência nos custos do produto, é denominada custo do ciclo de vida (life-cycle costing), e deve ser considerada na análise da viabilidade econômico-financeira (Figura 5.20) do projeto (e do conseqüente produto).

192

PARTE 2

Figura 5.20

O Modelo

Atividade de análise da viabilidade econômico-financeira do projeto.

A análise da viabilidade econômico-financeira significa estimar e analisar as perspectivas de desempenho financeiro do produto resultante do projeto. Essa análise é de certa forma iniciada na própria definição do portfólio, na fase de Planejamento Estratégico de Produtos (PEP), pois, ao escolher um dos produtos para ser desenvolvido, já se aposta, com os dados disponíveis até então, na viabilidade econômico-financeira de seu projeto. A estimativa de orçamento para o projeto, resultante da atividade anterior, serve para trazer uma estimativa dos níveis de preço final do produto, que o tornaria viável e cobriria os custos envolvidos. Na presente atividade do Planejamento do Projeto, são definidos os principais indicadores financeiros do projeto relacionados com o produto final, tais como o custo-alvo do produto, as previsões de retorno do investimento e a análise de suas características, o Valor Presente Líquido e o fluxo de caixa esperado com o novo produto. Essa análise da viabilidade econômico-financeira realizada durante o Planejamento do Projeto é a referência inicial para as fases seguintes, já no desenvolvimento do produto propriamente dito, além de ser um dos critérios mais importantes para se manter a decisão de executar o projeto. Quadro 5.14

Análise Econômica do Desenvolvimento de Produtos

O principal elemento que justifica a existência de uma empresa é a geração de lucro. Para os investidores, porém, não basta que o projeto tenha um resultado positivo. Para um projeto de desenvolvimento ser atrativo, é preciso que a quantidade de lucro gerado, o retorno do projeto, seja melhor do que aquele que a empresa poderia obter com outros investimentos, por exemplo, aplicando no mercado financeiro. Portanto, a essência da avaliação econômico-financeira é medir o retorno do projeto de maneira comparável com outros investimentos. O primeiro passo para a realização da análise econômica é a montagem do fluxo de caixa, isto é, a definição do fluxo de entrada e saída de dinheiro durante o ciclo de vida planejado para o produto. Os três componentes principais de um fluxo de caixa são:

• Investimentos no novo produto: a quantidade de dinheiro gasta para o desenvolvimento das especificações e preparação para a produção do produto. Isso inclui gastos com o pessoal envolvido no projeto, testes, fabricação de protótipos, viagens para consultar especialistas, pesquisas de mercado, testes na produção, atividades de lançamento do produto, preparação inicial da equipe de vendas, entre outros. Uma forma de calcular o investimento é criar uma conta específica para cada projeto, da qual sairiam todos os pagamentos e gastos efetuados. O maior desafio é computar o custo de pessoa, principalmente para os membros do time que dividem seu tempo entre os vários projetos. É preciso também definir claramente o momento em que os custos e receitas serão calculados. Geralmente, esse momento é o final da aprovação do lote piloto, pois, a partir desse momento, os produtos produzidos pela linha poderão ser comer-

(continua)

CAPÍTULO 5

Planejamento do Projeto

Quadro 5.14

193

Análise Econômica do Desenvolvimento de Produtos (continuação)

cializados dando início aos dois outros tipos de entradas e saídas do fluxo de caixa, respectivamente, as receitas e os custos e despesas de produção;

• Receitas: é formada pela soma do dinheiro que se espera arrecadar com a comercialização dos produtos. Para estimar a receita, é preciso estimar inicialmente a demanda dos produtos. Em seguida, multiplica-se pelo preço estimado. Serviços associados ao produto deverão poder ser considerados como receitas quando considerados no modelo de negócios da empresa.

• Custos e despesas de produção: valores gastos diretamente e indiretamente para a produção e comercialização do produto. Por exemplo, o custo de uma peça entregue no fornecedor, energia elétrica e gastos com a força de vendas. Convém diferenciar bem dos investimentos —o que muitas vezes pode ser difícil. Por exemplo, os gastos de uma operação na produção que visa produzir uma peça do protótipo é investimento. O gasto da mesma operação em uma peça idêntica, após a liberação do lote piloto, que será comercializada deve ser já apropriado como custo direto, a ser contabilizado naquele produto específico. O intervalo para o cálculo depende da duração do ciclo de vida do produto. Um produto industrial em geral é planejado para ficar alguns anos no mercado e, por isso, o período utilizado é normalmente anual. Calculados esses valores, eles serão somados, obtendo-se um valor final do fluxo de dinheiro esperado na empresa, conforme apresentado no Gráfico 5.1, a seguir. Gráfico 5.1

Previsão do Fluxo de Dinheiro

O Gráfico 5.1 representa uma previsão do montante de dinheiro que entrará ou sairá da empresa em cada um dos períodos (no caso anos) do ciclo de vida do produto. Para sabermos se esse projeto é viável ou não economicamente, precisamos avaliar e comparar esse fluxo com outros investimentos à disposição do dono da empresa. Nesse cálculo, deve-se levar em consideração que o dinheiro possui um valor dependente do tempo, isto é, receber R$ 500,00 hoje é diferente do que receber esse mesmo valor no próximo ano. Portanto, utilizam-se índices financeiros e parâmetros calculados com os dados do fluxo de caixa que permitem comparações e análises do desempenho financeiro do projeto. A seguir são apresentados três dos indicadores financeiros mais utilizados em projetos de desenvolvimento de produtos. Valor Presente Líquido (VPL). Este método consiste em calcular o valor correspondente de cada uma das entradas e saídas do fluxo de caixa para o primeiro período de tempo. Depois, todos esses valores são somados, obtendo-se um valor no período inicial do fluxo de caixa, resultante de todas as entradas e saídas. Se esse valor for maior que zero, significa que o projeto será positivo para a empresa. Para calcular esse valor correspondente, é preciso encontrar o valor de dinheiro no período

(continua)

194

PARTE 2

Quadro 5.14

O Modelo

Análise Econômica do Desenvolvimento de Produtos (continuação)

inicial (t1) que equivale à quantidade de dinheiro no período n (tn). Isso é feito descontando-se os juros (custo do dinheiro no tempo) e, portanto, é preciso escolher uma taxa de juros como referência para a realização dessa operação de equivalência. Deve-se utilizar uma taxa que é conhecida como taxa de atratividade. Trata-se da maior taxa de juros que ele conseguiria obter caso optasse por um investimento no mercado financeiro qualquer, de pouco risco, por exemplo, a poupança, o CDB ou qualquer outro investimento ao qual o investidor tenha acesso. Veja o exemplo a seguir de um projeto cujos benefícios, receita (R) menos custos e despesas (C), é uniforme e vale R$ 2.000,00. O investimento foi de R$ 8.200,00.

Se Bn = (1+j)

n

e

j = 0,10,

então:

( 2.000 ) 1 ( 2.000 ) 2 ( 2.000 ) 3 ( 2.000 ) 4 ( 2.000 ) 5 VP(B) = + + + + ( 1+ j ) 1 ( 1+ j ) 2 ( 1+ j ) 3 ( 1+ j ) 4 ( 1+ j ) 5 VP(I) = –8.200,00 ∴VPL = 618,43 Taxa Interna de Retorno (TIR). Neste método, calcula-se a taxa que, aplicada no fluxo de caixa, gerará um Valor Presente Líquido igual a zero, isto é, na qual todas as receitas irão se igualar aos custos e despesas de produção e investimento. A TIR é calculada utilizando-se a mesma fórmula descrita anteriormente, porém igualando-se o VPL a zero e utilizando como incógnita a taxa de juros (j), a qual será denominada de TIR. O valor obtido deve ser, então, comparado com a taxa de atratividade, a mesma utilizada no projeto anterior (poupança, CDB etc.). Se o valor da TIR é maior que o da taxa de atratividade, significa que investir no projeto é mais rentável do que investir em aplicações financeiras. A seguir, apresentamos o cálculo da TIR para o mesmo exemplo anterior. O resultado é uma TIR de 7%, maior que o projeto.

(continua)

CAPÍTULO 5

Planejamento do Projeto

Quadro 5.14

195

Análise Econômica do Desenvolvimento de Produtos (continuação)

Método do período de retorno do investimento (payback ). Este método compara o período em que o investimento passará a gerar lucro para a empresa. A forma mais fácil de calculá-lo é simplesmente acumulando entradas e saídas e determinando o período em que houve a transição de um valor positivo para negativo. No exemplo anterior, o retorno do investimento se dará no período 4, como mostramos a seguir. Período

Valor Final do Fluxo

Fluxo Acumulado

0

–8.200

–8.200

1

2.000

–6.200

2

2.000

–4.200

3

2.000

–2.200

4

2.000

200

5

2.000

2.200

Cada um desses métodos resulta em informações diferentes, que podem ser utilizadas de maneira complementar. O VPL é um método que fornece uma boa noção do montante que será obtido com o projeto, isto é, o valor que será captado, porém, ele não permite uma comparação fácil com outros investimentos. Esse aspecto é a grande vantagem da informação obtida na TIR, que fornece um valor facilmente comparável. Mas existem projetos que retornam um bom montante (VPL altamente positivo) e rentáveis (TIR acima da taxa de atratividade) mas cujo período de retorno de investimento é longo, significando que a empresa terá que amargar um bom período de prejuízo até a obtenção do lucro. Portanto, sugerimos o cálculo desses três parâmetros. Existem muitos outros, inclusive com graus maiores de sofisticação. Vamos citar somente o ROI (Return on Investments) que é uma maneira simples e muito utilizada de alcançar uma estimativa do lucro a ser obtido pela empresa. O ROI fornece a medida do lucro total das vendas do produto em um determinado período de tempo preestabelecido em contraste com o que será gasto com seu desenvolvimento, sendo calculado por meio da seguinte fórmula: ⎛B⎞ ROI= ⎜ ⎟ × 100.....................................[%] ⎝I⎠ Onde: B Somatória dos benefícios (receitas menos custos e despesas de produção) de cada um dos períodos do fluxo de caixa em unidades monetárias (u.m.), obtido no período de referência considerado. I Total investido com o produto em u.m. Para o cálculo do ROI, usualmente os gastos com P & D e os outros custos de desenvolvimento não são considerados despesas, mas investimento. É importante destacar que todos os métodos anteriormente citados dependem de estimativas: da demanda do produto pelo mercado, sua expectativa de crescimento, do preço de venda do produto aceito pelo consumidor final, dos custos envolvidos na produção do produto, sendo essencial a participação e o comprometimento de diferentes partes da organização, principalmente do marketing, engenharias e vendas. O ROI deve ser calculado para cada projeto de investimento e, depois, comparados entre si, sendo os projetos mais interessantes os que resultarem em maiores valores de ROI. As empresas também podem adotar valores mínimos de ROI para que um projeto possa ser considerado viável. Na análise de portfólio, pode ter sido realizada uma primeira análise financeira do projeto, com base em premissas, que agora são mais precisas. O método de cálculo do valor comercial esperado visando o objetivo de maximização dos resultados, aplicado naquele momento, já trabalha com premissas, como o volume de venda e preço, que devem ser avaliados no momento da análise financeira do projeto.

Cabe uma revisão periódica dessa análise ao longo do andamento do projeto (veja o Quadro 5.15, a seguir), pois, na atividade de Planejamento do Projeto, estão disponíveis apenas informações preliminares, e, portanto, passíveis de mudanças, sobre o ambiente em que o produto irá ser inserido. Reforçando destaque feito no Capí-

196

PARTE 2

O Modelo

tulo 3, à medida que as fases do desenvolvimento vão ocorrendo, aproximam-se as condições reais do momento de lançamento do produto, e, portanto, vão aumentando as certezas quanto as características que o produto deve adotar, sua atratividade e receptividade no mercado, as condições desse mercado (concorrência efetiva, surgimento de novas tendências, mudanças econômicas etc), e sua relação quanto a preço/volume. Sendo assim, a análise de viabilidade econômico-financeira pode ser refinada e confrontada com a inicialmente planejada, para efeitos de aprendizado quanto à capacidade de previsão no início de um projeto de DP. Quadro 5.15

A Análise Financeira Acompanhará Todo o Ciclo de Vida do Produto

O comportamento de um determinado projeto de investimento pode ser facilmente acompanhado por meio do Mapa de Retorno desenvolvido por House & Price (1991), apresentado na Figura 5.21. Este mapa mostra o relacionamento existente entre o investimento total feito no projeto, o total de vendas (previsto) para o período e o lucro operacional total a ser obtido, de forma a permitir a avaliação do tempo total necessário para o ponto de equilíbrio entre vendas e investimento (o break-even point do projeto) e o tempo para se chegar ao equilíbrio, mas após o lançamento do produto . Figura 5.21

Mapa de Retorno (House & Price, 1991).

É importante destacar que o mapa de retorno apresentado na Figura 5.21 pode sofrer variações dependendo da velocidade de desenvolvimento do setor (o setor aeronáutico, por exemplo, possui um tempo de desenvolvimento muito mais longo se comparado com o de produtos de linha branca) e do tipo de projeto que está sendo desenvolvido (plataformas, derivativos ou follow source). Dessa forma, as curvas assumiriam outras inclinações e formatos, gerando visões dos custos do ciclo de vida do produto ligeiramente diferentes. Fonte: HOUSE, C. H. & PRICE, R. L. The return map: tracking product teams. Harvard Business Review. p. 92-100, jan.-fev. 1991.

Essa revisão da viabilidade econômico-financeira ocorre ao final de cada uma das fases do desenvolvimento do produto, juntamente ou não aos gates. Pode também ocorrer a qualquer momento, quando grandes modificações endógenas ou exógenas ao projeto assim demandarem, para se verificar se o produto continuará financeiramente viável ou não.

CAPÍTULO 5

Planejamento do Projeto

197

5.12 Definir indicadores de desempenho Planejar os indicadores de desempenho (Figura 5.22) que serão utilizados significa escolher aqueles mais propícios para avaliar a execução de um projeto, dadas as suas características e o seu tipo. Esses indicadores serão empregados no acompanhamento e avaliação de cada uma das cinco fases do desenvolvimento do produto. Figura 5.22

Atividade de definição dos indicadores de desempenho.

Seguindo o que já foi apontado no Capítulo 2, esses indicadores devem ter como preocupação não somente verificar se as fases/atividades do desenvolvimento foram cumpridas e com que resultados, mas também analisar quanto está se mantendo o valor previsto de contribuição do presente projeto para os negócios da empresa. Isso perante a dinâmica de adaptações dos outros projetos da empresa (portfólio de produtos/projeto) em resposta às mudanças inevitáveis nas necessidades dos clientes, concorrência e condições econômicas (planejamento das estratégias da empresa). Se no Capítulo 2 foi exposta uma sistemática detalhada sobre como proceder para usar os indicadores de desempenho nas avaliações dos gates nas fases do DP, na presente atividade do planejamento cabe elencar os tipos de indicadores de desempenho que serão utilizados quando da realização dessa sistemática. A condução do projeto, ao escolher uma dentre as quatro versões adaptadas do modelo de referência específico, automaticamente já selecionou quais atividades do DP serão executadas e, portanto, passíveis de avaliação pelos indicadores de desempenho que devem ser aqui definidos. A respeito da definição dos critérios/indicadores de desempenho para os gates, que começa na presente atividade de planejamento e se estende para outras atividades do próprio desenvolvimento, deve-se em todos esses momentos envolver participantes tanto do time de desenvolvimento como do time de avaliação, reforçando destaque a esse respeito feito no Capítulo 2. Dada a dinâmica de realização do DP, é de esperar que sejam necessárias adaptações ao longo da execução do projeto, em resposta a novas situações que vão surgindo. Isso envolve tanto um maior rigor ou critério em certas avaliações de desempenho, que exigem novos indicadores ou critérios mais rígidos para os já utilizados, como também pode envolver certo afrouxamento ou dispensa de avaliação de outros indicadores, que se mostraram menos preocupantes ou desnecessários. Essas adaptações devem ser devidamente registradas para que sirvam de aprendizados para futuros planejamentos de indicadores de desempenho em novos projetos de DP. O ideal é o mínimo de adaptações, pois isso dificulta comparações posteriores entre projetos, via séries históricas de medições dos mesmos indicadores.

198

PARTE 2

O Modelo

Os indicadores de sucesso operacional e parte dos indicadores de sucesso em qualidade e perceptivo, todos destacados no Capítulo 2, devem ser detalhados na presente atividade, visto que são equivalentes aos indicadores da área de Gestão de Projetos. Esses indicadores medem aspectos relacionados com o tempo, custo e escopo dos projetos individuais, tais como os exemplificados a seguir: n n n n n

tempo de desenvolvimento (time-to-market); realização das atividades programadas, conforme o planejamento; custo total do projeto; custo real sobre orçamento; e qualidade dos resultados em conformidade com as especificações.

Outros indicadores de desempenho são: n n n n n n n n

7

porcentagem de documentos reprovados/retrabalhados; satisfação dos clientes; custos de falhas internas para novos produtos; taxa de devolução de novos produtos custos de falhas externas para novos produtos; aprovação dos protótipos nos testes; causas de falhas no cliente; e tempo de desenvolvimento do fornecedor, entre outros indicadores.

Nota-se que há três parâmetros básicos para medidas de desempenho em projetos de DP: o custo, a qualidade e o tempo. Essa conclusão foi pioneiramente exposta no trabalho de Clark & Fujimoto (1991), avaliando o DP na indústria automobilística mundial. O custo refere-se à quantidade de recursos requeridos para conduzir o projeto, da concepção à comercialização. Apresenta as seguintes métricas gerais: custo do pessoal envolvido, mensurado geralmente em horas de engenharia, custos de desenvolvimento de ferramental, custo de equipamentos e serviços utilizados no DP, custo de realização de testes e emprego de recursos no projeto. Os indicadores de qualidade buscam traduzir de fatores críticos do produto à adequação do seu desenvolvimento, em métricas como: adequação e durabilidade em uso, atualidade de estilo, percepção do consumidor, confiabilidade etc, e também avaliar a própria qualidade de realização de testes e emprego de recursos ao longo da execução do projeto. O tempo de desenvolvimento preocupa-se tanto com o intervalo de tempo total do DP (concept-to-market lead time), como com as frações de tempos de execução de fases, atividades e tarefas, ao longo de todo o projeto. As empresas devem buscar a excelência conjunta dos três parâmetros em seus desenvolvimentos de produto, e balancear os trade-offs que possam existir entre eles. Existem trade-offs entre o desempenho do produto (qualidade — grau em que o Qualidade versus custo produto satisfaz os requisitos do consumidor), os custos de desenvolvimento e o versus tempo de time-to-market (medida do quão rápido a empresa pode se mover do conceito para o desenvolvimento mercado), sendo necessária a compatibilização entre esses fatores. Dada a importância da concorrência baseada no tempo, o desempenho do time-to-market é sempre importante, mas não é o único a ser aperfeiçoado. Não se deve perder de vista que a velocidade para lançar o produto pode ser um objetivo intermediário, sendo a lucratividade a meta final. Muitas vezes os meios 7

Documentos de desenvolvimento de produtos podem ser: requisitos, desenhos, especificações etc.

CAPÍTULO 5

Planejamento do Projeto

199

utilizados para reduzir o tempo de desenvolvimento têm efeito oposto e, em muitos casos, são mais custosos. O enfraquecimento dos procedimentos de prevenção de erros durante o desenvolvimento e o favorecimento de projetos que resultam em pequenas mudanças são alguns dos riscos de se acelerar o PDP. Deve-se buscar a velocidade, mas sem perder a qualidade na execução do projeto. Os indicadores apresentados na presente atividade são o ponto de partida para a formulação de indicadores para níveis com maior detalhamento dentro do PDP, quais sejam, nas fases e nas suas atividades, para uso nos critérios de revisões de fase (gates) do PDP. Para isso, é necessário que sejam adaptados para avaliar as ações e trabalhos que são realizados nesses níveis do modelo de referência escolhido para o projeto de DP em questão. Além de definições de indicadores de desempenho, é importante que esses sejam classificados para ser utilizados em cada momento de avaliação de fase do projeto de DP. Também deve ser planejado, ao menos preliminarmente, quais decisões tomar conforme os resultados encontrados na avaliação desses indicadores. Em termos gerais, conforme os resultados encontrados, um projeto pode continuar ou não, o que também depende de sua prioridade em termos do portfólio de projetos de DP da empresa. Mesmo essa continuidade pode ser aceita sob certas condições.

5.13 Definir plano de comunicação O plano ou o gerenciamento das comunicações (Figura 5.23) do projeto refere-se às ações necessárias para que ocorra adequadamente a geração, coleta, disseminação, armazenamento e descarte das informações que envolvem um projeto de desenvolvimento. Figura 5.23

Atividade de definição do plano de comunicação.

A comunicação do projeto é influenciada pelas habilidades de comunicação dos líderes e dirigentes do projeto, de seus atores ou participantes, e também pelas características de comunicação presentes no contexto do projeto, tais como: a realimentação e os limites à comunicação, os meios (escrito, oral etc.) e as formas formais e informais de comunicação, os estilos de redação e técnicas de apresentação etc. As necessidades de informações dos envolvidos e as possibilidades de meios de Determinar quem, quando comunicação variam significativamente conforme o tipo de projeto de DP (platae como as partes forma, derivados etc.), e o estágio em que o projeto se encontra (pré-desenvolvienvolvidas no projeto mento, desenvolvimento etc.). precisam de informações e comunicações

200

PARTE 2

O Modelo

Os requisitos de comunicação são diretamente influenciados pelo planejamento e estrutura organizacional do projeto. Portanto, o contexto organizacional encontrado no projeto deve ser devidamente considerado para a realização do planejamento das comunicações. Para a realização desse planejamento, algumas informações são necessárias: n

n

n

os requisitos de comunicações existentes no projeto, que é uma somatória dos tipos e formatos das informações demandadas pelas partes envolvidas no projeto, com uma análise do valor dessas informações. Para levantar isso, deve-se analisar a organização do projeto e quais as responsabilidades das pessoas envolvidas, deduzindo-se daí as necessidades, características e quantidade de trocas de informações que provavelmente deve ocorrer ao longo do DP; as tecnologias de informação e comunicação disponíveis no ambiente em que será realizado o projeto de DP, e sua adequabilidade aos requisitos de comunicação demandados, notadamente no que se refere: à capacidade de suprir as urgências de informação que podem ocorrer ao longo do projeto, à atualização tecnológica e robustez compatível com as exigência do projeto, e ao acesso e uso compatíveis com a experiência e conhecimento das pessoas envolvidas com o projeto; e restrições e premissas existentes quanto ao planejamento das comunicações, como carência de recursos para novos investimentos em tecnologia de informação para uso nas comunicações do projeto, necessidade de que essas tecnologias envolvam todas as pessoas do projeto com igual intensidade etc.

Dadas essas informações de requisitos, tecnologias, restrições e premissas, pode-se então trabalhá-las no sentido de criar o planejamento das comunicações do projeto, relacionando necessidades de informação e comunicação com as fontes de obtenção e tecnologias para seu manuseio, minimizando esforços com informações supérfluas e tecnologias inadequadas. O plano de gerenciamento das comunicações resultante da presente atividade do Planejamento do Projeto deve basicamente conter: n

n

n

n

n

as formas de coleta e armazenamento dos vários tipos de informações de interesse do projeto, assim como maneiras de atualizá-las notificando os interessados; a previsão da construção de uma memória de informações e conhecimentos do projeto para uso futuro. Essas ações não acorrem apenas no final do projeto, mas deve ser uma preocupação existente desde o início do DP; a especificação da estrutura de distribuição dessas informações: para quem serão entregues, em quais meios e formatos, e em que momentos do projeto de DP. Essa estrutura precisa ser coerente com as responsabilidades e relacionamentos do organograma do projeto; os padrões que devem ser seguidos quanto ao formato de apresentação dos conteúdos, tais como: o nível de detalhamento, terminologias e vocabulários a serem utilizadas etc.; e previsões de procedimentos para a atualização desse plano de gerenciamento das comunicações ao longo da execução das seis fases do desenvolvimento do produto.

5.14 Planejar e preparar aquisições O Capítulo 2 deste livro, que introduz o tema “parceiros no desenvolvimento colaborativo de produtos”, em que são discutidos os tipos de parcerias e formas de relacionamento entre cliente e fornecedores, no PDP, e mesmo a atividade de definição dos interessados do projeto, ao mencionar a participação de fornecedores e de outros parceiros estratégicos ao longo do desenvolvimento do projeto, serve de base para a presente atividade (Figura 5.24) de planejamento das aquisições para o projeto.

CAPÍTULO 5

Planejamento do Projeto

Figura 5.24

201

Atividade de planejamento e preparação das aquisições.

No Planejamento do Projeto, o gerenciamento das aquisições envolve planejar o que será necessário adquirir externamente para a realização do projeto e sua posterior produção, principalmente em fornecedores ou outros parceiros, como também em outras unidades da mesma empresa. Isso envolve tanto o fornecimento de bens como de serviços, para o projeto do produto e do processo de produção, e, posteriormente, para o próprio suprimento regular de partes e componentes para a manufatura/produção do produto. Portanto, a relação comprador ou cliente com o fornecedor é a que permeia toda a discussão sobre planejar aquisições. Nesse planejamento, busca-se identificar que partes da execução do projeto de Planejar o que será desenvolvimento, além de recursos que serão empregados nesse projeto e compoadquirido e quando nentes e sistemas do próprio produto em desenvolvimento, devem ser contratados de terceiros, sob quais condições, e em que momentos do projeto isso deve ser feito. Esse planejamento requer o envolvimento de pessoas do setor de produção, qualidade e gestão da cadeia de suprimentos da empresa, para que se aproveite a experiência desses setores em suas áreas de competência, no que tange aos relacionamentos com fornecedores. As informações necessárias para que se faça esse planejamento provêm essencialmente da Declaração do Escopo do Projeto e do Produto. Além disso, também são informações relevantes para a presente tarefa as instruções normativas que a empresa segue para efetuar aquisições, informações sobre a disponibilidade no mercado dos bens e serviços potencialmente demandados pelo projeto, e outras informações do Planejamento do Projeto de potencial interesse para viabilizar ou não as aquisições, tais como: estimativas e restrições de custos e cronograma, padrões de qualidade previstos, determinações da EDT, requisitos de gestão de riscos etc. Alguns procedimentos podem ser empregados individualmente ou em conjunto para trabalhar essas informações, no sentido de construir o plano de aquisições do projeto de DP. A análise de make-or-buy, ou seja, decidir entre fazer internamente ou comprar, é um procedimento que procura orientar a decisão de aquisição com base no custo-benefício das duas opções. Nessa análise, que deve ser feita por um grupo heterogêneo de pessoas envolvidas com o projeto, recomenda-se considerar várias dimensões para a decisão, e seus reflexos no tempo. Por exemplo, fazer internamente pode significar maior segurança de prazos e controle de tecnologia, comprar em um fornecedor pode significar acesso a um bem ou serviço de alguém com maior competência específica para realizá-lo, a um menor custo. Essas reflexões, muitas vezes contraditórias, precisam direcionar-se para decisões que busquem certo equilíbrio entre a demanda atual do Planejamento do Projeto e sua execução; o impacto dessas decisões no médio prazo, quanto à produção e assis-

202

PARTE 2

O Modelo

tência técnica desse produto; e no longo prazo, na gestão do portfólio de projetos e produtos quanto a suas relações estratégicas com fornecedores. Em certas decisões do planejamento de aquisições, por exemplo, quando envolve alguma tecnologia complexa e/ou crítica ao produto ou ao seu projeto, pode ser necessária à adoção de um procedimento de avaliação especializada, chamando-se inclusive a participação de atores externos ao DP e mesmo a empresa. Um procedimento relevante a ser também considerado nesse planejamento é prever quais as possibilidades ou categorias de contratos de aquisição podem ser aplicados para as demandas do projeto. O resultado principal da presente tarefa é um plano de gerenciamento das aquisições, com um nível de formalidade e detalhamento compatível com o demandado para o tipo de projeto em questão, registrando as decisões tomadas com base nas informações e procedimentos anteriormente explicados. Um outro resultado esperado é a especificação ou declaração do trabalho, que é basicamente uma descrição do que será contratado, em um nível de detalhamento suficiente para que potenciais fornecedores avaliem sua capacidade de atender a esse suprimento. Diferentes tipos de bens ou serviços, necessidades do comprador, e tipo de contrato com o fornecedor, influenciam como será redigida essa especificação do trabalho. Basicamente, essa tarefa envolve preparar os documentos necessários para ser Preparar documentos com utilizado no trabalho de escolha de fornecedores. Utiliza-se de informações proveos requerimentos do que nientes da tarefa anterior, o plano de gerência de aquisições e as especificações do será adquirido e identificar trabalho, além de outras informações do Planejamento do Projeto, como as previos fornecedores potenciais sões do cronograma. Partindo-se de instruções da empresa para a elaboração de documentos, além de formulários padronizados da empresa, os principais resultados da presente tarefa dividem-se em dois conjuntos que são: n

n

os documentos de aquisição, para serem utilizados para a solicitação de propostas nos fornecedores potenciais. Esses documentos são, em muitas empresas, conhecidos por denominações do tipo “coleta de preços”, “solicitação de proposta ou cotação” etc. A estrutura desses documentos deve orientar fornecedores para a proposição de respostas corretas e completas aos pedidos de fornecimento, e, para tanto, essa estrutura pode incluir cláusulas contratuais que o fornecedor terá que seguir se for o escolhido, especificações do trabalho que será contratado etc; e os critérios de avaliação, que são os documentos utilizados para a classificação e seleção das propostas dos fornecedores. Esses critérios vão desde o preço direto de compra, até aspectos mais específicos para a avaliação do fornecedor, como o custo indireto da decisão de compra (tal qual o custo futuro de manutenção do item fornecido), o histórico de qualidade e cumprimento de prazos por parte do fornecedor, a capacidade técnica, gerencial e financeira do fornecedor, a dependência que se pretende estabelecer com o fornecedor etc.

Deve-se prever no planejamento de aquisições o envio dos documentos de obtenção de propostas de fornecimento para uma lista de fornecedores qualificados, durante a execução efetiva do projeto. Essa lista é uma informação que pode ser levantada no planejamento, com base no quadro de fornecedores bem-sucedidos com que a empresa já contou em outros projetos de DP, atualizado por novos fornecedores entrantes no mercado. Reuniões de esclarecimentos com fornecedores potenciais, para orientá-los na correta preparação da proposta, é um tipo de procedimento que pode ser necessário e deve ser previsto no planejamento. Recebidas as propostas dos fornecedores, com todas as informações de preço, qualidade, prazos e capacidade de suprimento, conforme foi solicitado nos documentos de aquisição, deve-se planejar a forma de seleção dessas propostas, pelos critérios de avaliação já previstos. Definido(s) o(s) fornecedor(es) para cada item ou serviço, relacionado ao proPlanejar a gestão dos jeto de DP ou à sua posterior produção e distribuição, deve-se prever o estabelecirelacionamentos com os mento de um instrumento contratual entre essas partes — fornecedor e empresa — fornecedores que legalmente embasa essa relação em termos de direitos e deveres de ambos os en-

CAPÍTULO 5

Planejamento do Projeto

203

volvidos. Nesse contrato, também pode estar determinado o tipo de envolvimento do fornecedor no projeto de DP da empresa e desta para com o desenvolvimento do item ou serviço que será suprido. Para a execução do projeto, e que pode avançar para a produção do produto decorrente, deve ser planejado como será a administração dos contratos com os fornecedores, acompanhando-se o trabalho de cada um e, em um ambiente com um nível de terceirização crescente, os relacionamentos entre os vários fornecedores. A gerência dos relacionamentos com os fornecedores têm como diretriz orientadora os contratos estabelecidos, além do plano do projeto como orientação básica. Ao longo do envolvimento do fornecedor com o projeto de DP, podem ser necessárias mudanças não previstas inicialmente no contrato, seja porque o produto ou projeto mostrou-se mais complexo do que se esperava, seja porque modificações se fizeram necessárias para atender a novas solicitações do mercado ou novas tecnologias. A forma de proceder essas mudanças deve ser estabelecida no planejamento de aquisições, inclusive integrando-as à gestão das mudanças do projeto de DP. No planejamento da gestão das aquisições devem ser feitas previsões sobre como encerrar os contratos firmados com os fornecedores, verificar os resultados obtidos, e armazenar as informações e conhecimentos para uso em projetos futuros. Com o lançamento do produto e conseqüente encerramento do projeto de deEsse encerramento pode senvolvimento do produto, fecha-se a parte de envolvimento do fornecedor no proocorrer por partes. jeto do produto e processo de fabricação do cliente, que basicamente envolvem as engenharias de ambas as partes. No pós-desenvolvimento do produto, o fornecedor passa a suprir o item ou serviço negociado, havendo maior relacionamento entre a produção e a distribuição do fornecedor com o cliente, e eventualmente participa de melhorias nesse produto do cliente já em produção. Nesse caso, o encerramento do contrato ocorre quando houver a descontinuidade de produção do produto do cliente (ou se esse decidir trocar de fornecedor). Em certos tipos de item ou serviço, o contrato com o fornecedor se mantém após esse momento, estendendo suas responsabilidades até o fim da vida útil de um produto em uso, porém já não mais em produção (por exemplo, o fornecedor de um fabricante de aviões, de um grande computador do tipo mainframe, de um equipamento médico-hospitalar etc.). As aquisições relacionadas com o projeto de desenvolvimento em si são realizadas nessa atividade. No entanto, deve-se ter em mente que, no momento do Planejamento do Projeto, conforme o tipo de projeto de desenvolvimento, ainda não existem tantas informações disponíveis que permitam que sejam realizadas todas as aquisições de itens do produto e também recursos para produção. Para produtos mais simples, que são desenvolvidos em projetos do tipo derivado ou mesmo follow source, é possível fechar alguns acordos de parcerias nessa fase de detalhamento. Os projetos de desenvolvimento de produtos plataforma, porém, são mais complexos e as aquisições dependem de especificações que surgem durante o projeto conceitual e mesmo no projeto detalhado. Principalmente as aquisições relacionadas com a produção do produto, que dependem das informações do plano de processo e projeto de recursos criadas naquela fase. Ao longo do processo de desenvolvimento existem atividades e tarefas específicas que tratam dessas questões.

5.15 Preparar plano de projeto Utilizando-se de diversas informações, das atividades anteriores e do planejamento estratégico de produtos, é gerado o Plano de Projeto (Figura 5.25), um documento que será um guia no controle da execução do projeto. A elaboração desse plano pode ser cíclica, desde um esboço inicial no início do Planejamento do Projeto com, por exemplo, recursos, tarefas e prazos genéricos, até se chegar ao plano definitivo, após a obtenção de todas as informações necessárias ao final do planejamento, quando o plano final é gerado com recursos e tarefas bem delimitados e prazos devidamente quantificados. O Plano de Projeto, além de especialmente útil para guiar a execução do projeto, serve para documentar tanto as premissas como as decisões tomadas no Planejamento do Projeto.

204

PARTE 2

Figura 5.25

O Modelo

Atividade de preparo do Plano de Projeto.

Como informações utilizadas para a elaboração desse plano, além dos já mencionadas resultados das atividades anteriores e do Planejamento Estratégico de Produtos, também são consultadas informações de outros planejamentos da empresa, tais como previsões financeiras, planos de produção etc., informações de como foi a execução de planos de projetos já realizados, buscando verificar acertos e erros cometidos, dentre outras. Dessa forma, são levantadas e registradas, no plano, as restrições e premissas que delimitarão a execução do projeto. Restrições são limitações em escopo, recursos e prazos que serão encontradas na execução do projeto, enquanto premissas são fatores considerados necessários de ocorrerem para que a execução seja conforme o planejado. Todo esse conjunto de informações precisa ser trabalhado ao longo do Planejamento do Projeto de forma a se chegar ao plano final. Isso requer tanto um ambiente em que as partes envolvidas na equipe de projeto possam contribuir adequadamente com suas habilidades e conhecimentos para as tomadas de decisões nos planos, como também são necessárias ferramentas e técnicas de apoio à elaboração do plano por essa equipe, desde simples formulários-padrão, em papel ou meio eletrônico, passando por sistemas de informação e softwares para gerência de projetos, e chegando mesmo ao uso de simuladores para análise de riscos, prazos etc. O uso desses recursos obviamente é condicionado pela complexidade demandada pelo projeto de DP que se está planejando. O plano definitivo, elaborado ao final do Planejamento do Projeto, deve conter basicamente (segundo o PMBOK): n

n

n

n

n

Project charter, que é um documento formal da empresa que reconhece a existência do projeto e a autoridade de seu líder e contém os requisitos-chave que o projeto deve alcançar em sua execução, além de uma breve descrição do seu produto resultante. Declarações de escopo, que incluem os objetivos do projeto, e a estrutura analítica do projeto ou até o nível em que o controle deve ser exercido, que é um documento de base do escopo. Estimativas de custos, prazos, recursos e atribuições de responsabilidades, no nível para o qual o controle foi estabelecido, e documentos de base de medição desse desempenho. Planos de gerenciamento de escopo, cronograma, custo, qualidade, recurso, comunicação, risco e terceirização, com o detalhamento desses planos dado pelas necessidades de cada tipo de projeto em questão. E, se necessário, lista de questões por resolver e decisões pendentes do planejamento que só poderão ser tratadas durante a execução, além de outras documentações complementares ao plano do projeto.

CAPÍTULO 5

Planejamento do Projeto

205

Todo esse material deve ser organizado de maneira a facilitar o seu uso durante a execução do projeto, na macrofase seguinte, nas cinco fases do desenvolvimento do produto: projeto informacional, conceitual, detalhado, preparação da produção, e lançamento do produto. O sucesso desse desenvolvimento está inerentemente relacionado a uma boa realização do presente Planejamento do Projeto. O Plano do Projeto será utilizado nas fases seguintes do desenvolvimento do produto (capítulos 6 ao 10). Como já destacado no Capítulo 3, no início de cada uma dessas fases será realizada a atividade genérica de atualização do Plano do Projeto, levando para esse plano as especificidades da fase em questão e detalhando-o quando necessário. Essa atividade genérica é bem mais rápida do que a realização do plano inicial, e é importante que seja feita no início da fase, podendo assim ajustar o plano e, portanto, a continuidade de execução do projeto com base nos resultados do gate da fase anterior.

5.16 Avaliar fase O gerente de projeto, com o novo planejamento em mãos, deverá dar início à avaliação para a transição de fase, marcando o fim do Planejamento do Projeto e o início da fase de Projeto Informacional. O conteúdo dessa atividade foi descrito Capítulo 3, no Tópico 3.4. Os critérios que devem ser utilizados para a transição de fases são os expressos na Tabela 5.1. Tabela 5.1

Critérios para Avaliação da Fase de Planejamento do Projeto Critérios

Escopo do Produto Definido As características escolhidas para a definição do produto são suficientes? As metas de cada uma das características foram definidas de maneira inequívoca? Escopo do Projeto Definido Foram identificados todos os interessados do projeto? Foi identificada a equipe de desenvolvimento? A responsabilidade e dedicação de cada um dos interessados e equipes que desempenharão tarefas no projeto foram identificadas? Os itens utilizados para descrever o escopo do projeto são suficientes ? Foram identificados todos os objetivos e metas principais do projeto? Foram identificados o Preço e o Custo meta do produto? Existe um plano bem definido para o gerenciamento da Declaração do Escopo do Projeto? Planejamento e Programação do Projeto Preparado (Detalhamento do Escopo) Foram identificados todos os deliverables e pacotes de trabalho do projeto? As atividades identificadas são capazes de resultar nas entregas e objetivos planejados para cada pacote de trabalho? As atividades foram programadas com prazos, esforço e recursos? Os recursos estão claramente definidos e seu uso está nivelado no decorrer do projeto? Análise de Risco Realizada Todos os principais riscos foram suficientemente identificados? Foram realizadas análises qualitativas e quantitativas para mitigar os riscos? As análises resultaram em ações e mudanças suficientes para diminuir os riscos? Análise de Viabilidade Econômica Foi preparado um orçamento realista do projeto? Foi preparada uma análise de demanda suficientemente precisa? Os índices financeiros do projeto são superiores aos dados de atratividade, taxas e padrões, definidos previamente pela empresa? (No mínimo: Payback, TIR e VPL.) Foi feita uma análise de sensibilidade do plano, variando-se demanda e custos de insumos principais, para verificar se a viabilidade se manteria diante da relação a uma mudança no ambiente empresarial? O projeto mostrou-se robusto às variações?

206

PARTE 2

O Modelo

5.17 Aprovar fase Esta atividade segue o padrão da atividade genérica apresentada no Capítulo 3, Tópico 3.5. Os critérios apresentados na Tabela 5.1 serão utilizados pelo Time de Avaliação de Transição de fase que deverá aprovar o Plano do Projeto preparado. O gerente de projeto, que preparou o Planejamento do Projeto e será responsável por sua condução caso venha a ser aprovado, deverá defendê-lo perante o time mostrando todo o seu potencial e possíveis fraquezas. Já o time de avaliação precisa verificar não apenas a consistência do plano, visível no atendimento aos critérios apresentados na Tabela 5.1. Devem estar atentos para que o escopo do projeto e o escopo do produto estejam em conformidade com o papel desse projeto específico no Plano Estratégico de Produtos, preparado na fase anterior.

5.18 Resumo do capítulo A fase de Planejamento do Projeto inicia-se com a definição dos interessados, que podem manifestar ou sofrer influências relativas ao projeto tanto ao longo de seu planejamento, como em sua realização e mesmo após sua conclusão. Cabe ao planejamento identificar essas partes envolvidas, e entender suas necessidades, limitações, e potencial de envolvimento com o projeto. Para isso, deve considerar que projetos são temporários e, portanto, predominam relações transitórias entre os envolvidos com sua execução, que possuem diferentes intensidades de envolvimento, ao longo do projeto. A definição do escopo do produto apresenta os parâmetros básicos que o caracterizam (o que é o produto) e as funcionalidades que dele se espera (para que serve o produto), de forma a se ter uma clara compreensão do que será fornecido ao cliente. A definição do escopo do projeto será a base para decisões futuras no projeto. Deve-se considerar, nessa definição, a gestão do escopo, ou seja, qual o detalhamento e o controle de mudanças do escopo que será necessário para o projeto em questão. A elaboração de uma declaração escrita do escopo do projeto é a base genérica a ser seguida nas mais diversas decisões futuras do planejamento e execução do projeto, e deve conter, basicamente: justificativa do projeto; descrição sucinta do produto; objetivos do projeto em termos de custo, cronograma e medidas de qualidade; as premissas e restrições identificadas; e um plano de gerenciamento do escopo. A partir do escopo do produto, e principalmente do projeto, e das características do modelo de referência específico adotado na empresa para seu PDP, pode-se realizar as devidas adaptações nesse modelo, de forma a que venha a ser utilizado para o projeto do novo produto em questão. Partindo-se de uma avaliação conjunta da complexidade e inovação do produto/projeto, pode-se melhor classificá-lo em um dos tipos genéricos (radical, plataforma, derivado ou follow source). Com isso, ficam visíveis as adaptações que serão necessárias no modelo de referência específico do PDP da empresa, de forma a melhor utilizá-lo para o projeto em questão. Partindo-se da EDT que detalhou o escopo do projeto, e da versão do modelo de referência escolhido para o presente projeto, um passo seguinte do planejamento é definir quais as atividades específicas que deverão ser realizadas no projeto, também as descrevendo e, então, estabelecendo os relacionamentos e a conseqüente seqüência de execução dessas atividades. Então, pode-se planejar a estimativa de duração para cada uma das atividades, e o conseqüente cronograma de realização do projeto. Diretamente necessários para a elaboração desse cronograma, a definição ou planejamento dos recursos do projeto são parte de uma preocupação maior que deve existir no DP, que é o gerenciamento do custo do projeto, buscando-se garantir sua execução dentro do orçamento previsto. A estimativa dos custos dos recursos empregados em cada atividade de desenvolvimento serve para compor uma estimativa de custo do produto final resultante e as estimativas quantificáveis dos custos dos recursos que viabilizarão as atividades do DP. Os custos estimados para as atividades do DP precisam ser agrupados em um orçamento a ser submetido para aprovação, e que estabelece uma base line de custo, útil para medir o desempenho do projeto.

CAPÍTULO 5

Planejamento do Projeto

207

A análise de viabilidade econômico-financeira significa estimar e analisar as perspectivas de desempenho financeiro do produto resultante do projeto. A estimativa de orçamento para o projeto serve para trazer uma estimativa dos níveis de preço final do produto, que o tornariam viável e cobririam os custos envolvidos. Um efetivo planejamento de projeto deve buscar o equilíbrio ou balanço entre a necessidade de reduzir os riscos de um projeto e aumentar sua previsibilidade, com a necessidade de buscar opções novas e inovações no produto/projeto — o que aumenta sua instabilidade. Ou seja, um planejamento para gerenciar a dicotomia entre riscos e inovação versus estabilidade e previsibilidade. Tentar reduzir a incerteza, eliminar eventos não oportunos, e melhorar a quantidade e qualidade de alternativas de soluções constituem a essência da avaliação e gestão de riscos do projeto. Planejar os indicadores de desempenho que serão utilizados significa escolher aqueles mais propícios para avaliar a execução de um projeto, dadas suas características e seu tipo. Esses indicadores serão empregados no acompanhamento e na avaliação de cada uma das seis fases do desenvolvimento do produto. O gerenciamento das comunicações do projeto refere-se ao planejamento das ações necessárias para que ocorra adequadamente a geração, coleta, disseminação, armazenamento e descarte das informações que envolvem um projeto de DP. O gerenciamento das aquisições envolve planejar o que será necessário adquirir externamente para a realização do projeto de DP e sua posterior produção. Nesse sentido, gera o plano de gerenciamento das aquisições; a especificação ou declaração do trabalho, que é uma descrição do que será contratado; e prevê o estabelecimento de um instrumento contratual entre fornecedor e empresa. Finalizando o planejamento, fazendo uso de diversas informações, das atividades anteriores e do planejamento estratégico de produtos, é gerado o Plano do Projeto, um documento que será um guia no controle da execução do projeto.

5.19 Questões e atividades didáticas Questões para reflexão 1. Quais são as relações entre o Planejamento do Projeto com a fase de Planejamento Estratégico de Produtos que o precede no pré-desenvolvimento? E com o Processo de Planejamento Estratégico da Empresa? 2. Como as características de unicidade e temporalidade do projeto podem influenciar o seu planejamento? 3. Quais são os pontos mais críticos que se deve considerar na atividade de definição dos interessados do projeto? 4. Quais são as principais preocupações que devem existir na montagem e preparação da equipe que será responsável pelo projeto de DP? 5. Como se relacionam e se diferenciam o Escopo do Produto do Escopo do Projeto? 6. Quais são os cuidados básicos que se deve tomar para a correta elaboração de uma Declaração do Escopo do Projeto? 7. Quais são as principais diferenças entre as quatro versões adaptadas do modelo de referência específico? 8. Como o modelo de referência do PDP adaptado e a Declaração do Escopo do Projeto podem ajudar na adequada definição e seqüenciamento das atividades do projeto? 9. Quais são as otimizações que se pode obter no cronograma do projeto, conforme a disponibilidade e racionalização de uso dos recursos? 10. Quais são os principais riscos que podem ocorrer em um projeto e que, portanto, devem ser considerados em seu planejamento?

208

PARTE 2

O Modelo

11. Por que é importante analisar os riscos potenciais de um projeto tanto de forma qualitativa como quantitativa? 12. Quais são as principais preocupações que um plano de respostas aos riscos deve ter? 13. Como podem ser aplicados conjuntamente os procedimentos para a estimativa dos custos e orçamentos das atividades de execução do projeto? 14. De que forma podem ser balanceados os trade-offs entre os três parâmetros básicos para medidas de desempenho em projetos de DP: o custo, a qualidade e o tempo? 15. Quais são os principais cuidados que devem ser considerados na elaboração de um plano de gerenciamento das comunicações de um projeto? 16. Como as tarefas da atividade de planejamento e preparação das aquisições precisam ser adaptadas conforme o modelo de referência específico que está sendo seguido no projeto? 17. Quais informações um Plano de Projeto deve obrigatoriamente conter?

Atividades didáticas 1. Levante alguns endereços na Internet que tratem de planejamento de projetos e verifique como tratam de projetos de desenvolvimento de novos produtos. 2. Busque em teses e/ou dissertações nas áreas de administração e engenharia de produção exemplos de descrições e casos que ilustrem os diferentes tipos de envolvimento dos fornecedores em projeto de desenvolvimento de produtos. 3. Utilize a checklist do Escopo do Produto para descrever o escopo de um produto físico usual, como um eletrodoméstico. 4. Reflita sobre o projeto que resultou no produto da atividade anterior, utilizando para isso a checklist do Escopo do Projeto. 5. Levante na literatura de Gestão de Projetos e/ou em um caso real de uma empresa um exemplo completo de Estrutura de Decomposição do Trabalho (EDT) e busque entender toda a decomposição/desdobramento realizado. 6. No setor industrial em que sua empresa se insere, ou em um tipo de indústria que você conhece melhor, procure classificar os projetos/produtos realizados nos últimos anos quanto aos quatro tipos básicos listados (radical, plataforma, derivado e follow source). Relacione as eventuais dificuldades encontradas ao se realizar essa classificação. 7. Procure manusear um sistema/software de Gestão de Projetos, descrevendo suas funcionalidades típicas. 8. Relacione ao menos um exemplo para cada um dos tipos básicos de relacionamentos entre atividades. 9. Procure exemplos de utilização das técnicas de desenvolvimento do cronograma do projeto, relacionando sua aplicação prática com seu potencial descrito no presente capítulo. 10. Descreva ao menos um exemplo, ligado a projeto de produtos, para cada uma das formas básicas de ações para se precaver de um risco. 11. Procure um caso real, na literatura ou em uma empresa, de um estudo de análise da viabilidade econômico-financeira de um projeto (e do conseqüente produto). Procure entender, nesse caso, como foram utilizados os indicadores financeiros do projeto relacionados com o produto final, tais como o custo-alvo do produto, as previsões de retorno do investimento e a análise de suas características, o Valor Presente Líquido e o fluxo de caixa esperado com o novo produto. 12. Verifique como sua empresa trata do Planejamento de Projetos de Produtos, analisando criticamente a forma como ocorre as atividades/tarefas elencadas no presente capítulo, em casos reais de desenvolvimentos de produtos. Se você não trabalha em uma empresa em que esse levantamento seja possível, procure realizar visitas a outras empresas e/ou entrevistar especialistas em planejamento de projetos.

CAPÍTULO 5

Planejamento do Projeto

209

5.20 Informações adicionais BADIRV, A. B. Project management in manufacturing and high technology operation. 2 ed., New York: John Wiley & Sons, 1996. CLARK, K.; FUJIMOTO, T. Product development performance: strategy organization and management in the world auto industry. Boston: Harvard Business School Press, 1991. PROJECT MANAGEMENT INSTITUTE. A guide to the project management body of knowledge (PMBOK guide) Pennsylvania, 2002. VALERIANO, D. L. Gerenciamento estratégico e administração por projetos. São Paulo: Makron Books, 2001. VALERI, S. G. Estudo do método de aprovação de fases no processo de desenvolvimento de produtos em uma indústria automobilística. 2001. São Carlos: Dissertação (Mestrado) – Escola de Engenharia de São Carlos, Universidade de São Paulo, 2001. VERZUH, E. MBA compacto, gestão de projetos. Rio de Janeiro: Campus, 2000.

6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13

Sumário Atualizar o Plano do Projeto Informacional Revisar e atualizar o escopo do produto Detalhar ciclo de vida do produto e definir seus clientes Identificar os requisitos dos clientes do produto Definir os requisitos do produto Definir especificações-meta do produto Monitorar a viabilidade econômico-financeira Avaliar fase Aprovar fase Documentar as decisões tomadas e registrar lições aprendidas Questões e atividades didáticas propostas Informações adicionais

6. Projeto Informacional Projeto Informacional PARTE 2 O Modelo

Depois da leitura deste capítulo, você será capaz de: l

l

l

l

l

l

l

l

Entender como se inicia a macrofase de desenvolvimento do produto. Compreender a importância do correto entendimento do problema de projeto do produto. Definir os diferentes modelos de ciclo de vida e entender como relacionar o ciclo de vida do produto com os clientes do produto. Entender como tratar as necessidades obtidas dos clientes e representá-las como requisitos dos clientes. Definir os requisitos do produto a partir dos requisitos dos clientes. Entender o método QFD e como ele pode ser usado na fase de projeto informacional. Definir e estruturar as especificações-meta do produto. Entender que as especificações-meta do produto atuam na fase seguinte como guias para a obtenção de soluções para o problema de projeto do produto e como critérios de escolha da melhor alternativa desenvolvida.

6.1

Sumário

Os elementos obtidos ao final da fase de planejamento do produto fornecem uma definição do escopo, descrevendo o produto que será obtido e as definições básicas e as restrições que cercam o projeto — além das atividades e dos recursos necessários planejados. Essas informações permitiram também uma análise da viabilidade econômica e técnica do projeto. Feito isso, a equipe de desenvolvimento será reunida e a fase de Projeto Informacional será iniciada.

212

PARTE 2

O Modelo

O objetivo dessa fase é, a partir das informações levantadas no planejamento e em outras fontes, desenvolver um conjunto de informações, o mais completo possível, chamado de especificações-meta do produto. Essas especificações, além de orientar a geração de soluções, fornecem a base sobre a qual serão montados os critérios de avaliação e de tomada de decisão utilizados nas etapas posteriores do processo de desenvolvimento. É importante salientar que a definição inadequada dessas informações iniciais ou uma determinação imprópria de certos aspectos do problema poderá causar uma seqüência de decisões que fará emergir uma solução para um problema diferente daquele que se deseja. Ou seja, obter-se-á a solução de um problema definido erroneamente, resultando na perda de quase todos os recursos gastos. Esse conjunto de informações deve refletir as características que o produto deverá ter para atender às necessidades dos clientes. Essa fase, conforme mostrado na Figura 6.1, inicia-se pela atualização do Plano do Projeto Informacional, de modo que esse plano mantenha uma compatibilidade com o planejamento geral feito na fase anterior. Em seguida, parte-se para a definição do problema de projeto do produto na qual se busca o entendimento claro e completo do problema a ser enfrentado. Além de aprofundar as informações obtidas na fase de planejamento, são buscadas com detalhes outras informações sobre aspectos tecnológicos e de produtos concorrentes. Figura 6.1

Informações principais e dependência entre as atividades da fase de Projeto Informacional.

Com o problema definido, a atividade seguinte é a de mapear o ciclo de vida do produto e definir, para cada fase desse ciclo, os clientes (pessoas ou organizações) envolvidos com o produto e o projeto. Assim, com o conhecimento do problema e dos clientes envolvidos, parte-se para a identificação da “voz dos clientes”, ou seja, de suas necessidades, as quais, depois de serem tratadas, formam os chamados requisitos dos clientes. Os requisitos dos clientes, geralmente expressos na “linguagem do consumidor”, são tipicamente subjetivos. Um exemplo da subjetividade desses requisitos é: “o equipamento deve ser leve”. Esse tipo de informação, por não ser precisa, não está ainda na forma adequada para ser utilizada nas decisões necessárias nas demais fases do projeto do produto. Faz-se necessário que esses requisitos dos clientes, ainda na forma de necessidades, sejam descritos por meio de características técnicas, possíveis de serem mensuradas. Para tal, são definidos os chamados requisitos do produto.

CAPÍTULO 6

Projeto Informacional

213

As especificações-meta do produto compreendem: os requisitos de produto associados com valores-meta, reunindo, assim, os parâmetros quantitativos e mensuráveis que o produto projetado deverá ter. Poderão existir casos além desses requisitos, em que as especificações-meta poderão conter outros requisitos ou diretrizes não mensuráveis, desde que essas sejam entendidas como importantes pela equipe de desenvolvimento. Finalmente, ocorrem as atividades finais genéricas da fase, envolvendo o monitoramento da viabilidade econômica, o gate da fase e o registro das decisões tomadas e lições aprendidas. A aprovação da fase implica verificação de algumas características das especificações obtidas, tais como: abrangência, ambigüidade, redundância, clareza, praticabilidade e se as metas das especificações de custo estão de acordo com o custo-meta do produto.

6.2

Atualizar o Plano do Projeto Informacional

Essa atividade tem por objetivo compatibilizar o planejamento desta fase com o planejamento efetuado na fase de Planejamento do Projeto. Trata-se de uma das atividades que será recorrente durante o início de cada uma das fases daqui em diante. Basicamente deverão ser seguidas as mesmas orientações descritas no Capítulo 3, Tópico 3.2.

6.3

Revisar e atualizar o escopo do produto

Nesta atividade, tem-se por objetivo o estudo do problema de projeto associado ao Escopo do Produto. São coletadas e analisadas as informações que auxiliam a equipe de projeto a entender da forma mais completa possível o real problema. Procura-se verificar se a Declaração do Escopo do Produto contém os objetivos e as restrições associadas, além de uma série de informações necessárias para a busca de novas e mais detalhadas informações para o desenvolvimento do projeto do produto. A seguir, serão apresentadas e descritas as principais tarefas dessa atividade, conforme mostra a Figura 6.2. Figura 6.2

Tarefas da atividade “Revisar e atualizar o Escopo do Produto”.

214

PARTE 2

O Modelo

Inicialmente, busca-se a familiarização com o problema que vai ser resolvido, procurando-se o maior volume de informações possível sobre o problema. As informações já levantadas na fase de planejamento estratégico, tais como: tipo de produto; tipo de projeto; volume planejado de fabricação; desejos explícitos expostos pelos clientes; restrições do projeto ou do produto devem ser examinadas com maior profundidade. De um modo geral, além das informações técnicas e econômicas, deverão ser considerados os aspectos relacionados aos componentes, aos materiais, aos parceiros e fornecedores que se desejam utilizar no projeto. Essa declaração do problema é muito útil para se definir adequadamente o escopo geral dos esforços a serem empregados no projeto do produto. Um problema bem definido é um problema mais facilmente resolvido

Quadro 6.1

Termos Utilizados no Projeto Informacional

A relação dos termos principais deste capítulo e suas definições encontram-se na Figura 6.3. Figura 6.3

Relação entre os principais termos usados na fase de Projeto Informacional.

As definições estão a seguir: Termo

Definição

Escopo do Produto

É a primeira descrição do produto, contendo uma primeira versão de requisitos do produto e, possivelmente, algumas especificações-meta que serão reavaliadas e detalhadas posteriormente. O importante é que seja da forma mais detalhada segundo o nível de conhecimento atual do produto.

Ciclo de vida do produto

Descrição gráfica da história do produto, descrevendo os estágios pelos quais o produto passa, desde os primeiros esforços para realizar o produto, até o final do suporte pós-vendas, ou seja, quando é finalizada qualquer forma de compromisso da empresa com o suporte ao produto. Existem vários modelos propostos, com número diferente de estágios. Esses estágios caracterizam-se por ser seqüenciais e hierárquicos.

Necessidades dos clientes

Dados originais dos desejos dos clientes, que podem ser redundantes e expressar características dos produtos.

Requisitos dos clientes

Necessidades dos clientes organizadas, categorizadas e estruturadas.

Requisitos do produto

Características que o produto deve atender com os valores-meta, desdobrados a partir dos requisitos dos clientes.

Especificações-meta

Conjunto de objetivos ou metas a que o produto deve atender. Esse conjunto de informações, elaboradas durante o Projeto Informacional do produto, deve refletir as características que o produto deverá ter para atender às necessidades dos clientes.

Informações adicionais qualitativas

Informações complementares aos requisitos, advindas de outras fontes, que formam as Especificações-meta.

CAPÍTULO 6

Projeto Informacional

215

Ainda como parte dessa atividade tem-se a análise das tecnologias disponíveis e necessárias e a pesquisa sobre normas e patentes. A busca dessas informações deve ser dirigida em três direções, independentemente da ordem de realização delas: n n n

procura de tecnologias e métodos de fabricação disponíveis; procura de patentes sobre o produto que vai ser projetado; e procura de informação sobre produtos similares.

As informações sobre as tecnologias existentes (veja o Tópico 4.4, no Capítulo 4) levantadas na fase de planejamento estratégico, para todo o portfólio de produtos, são reutilizadas aqui. Novas pesquisas, visando complementar ou aprofundar as informações levantadas anteriormente, poderão ser feitas, caso se julgue necessário. O ideal é que sejam exceções tais que todas as equipes de projetos possam aproveitar o máximo possível um esforço conjunto. Os meios mais comuns nos quais essas informações podem ser encontradas são: dicionários técnicos, enciclopédias, manuais, livros-texto, livros técnicos, revistas técnicas, anais de congressos e eventos, revistas científicas, relatórios técnicos, normas técnicas e catálogos de empresas. Nos casos de produtos que vão ser reprojetados, as informações estarão focadas no produto existente, assim como em produtos concorrentes. Sobre os produtos similares, além de visitar os sites adequados na Internet, deve-se procurar catálogos e ofertas de produtores concorrentes, assim como a maior quantidade de informações possível relacionadas ao produto que vai ser projetado. Sobre as tecnologias de produção, devem-se pesquisar quais tecnologias são usadas para produzir produtos similares, quais estão disponíveis e tomar a maior quantidade de informação. Em qualquer caso, visitas ao centro de produção onde vai ser fabricado o novo produto favorecerão a obtenção de informações com especialistas de fabricação, montagem e embalagem. A determinação imprópria de certos aspectos do problema poderá causar uma seqüência de decisões que fará emergir uma solução para um problema diferente do requerido.

6.4

Detalhar ciclo de vida do produto e definir seus clientes

Após a definição do problema, o primeiro passo na busca de novas informações é a definição do ciclo de vida do produto. A Figura 6.4 ilustra as tarefas desta atividade. De um modo geral, os modelos do ciclo de vida fornecem uma descrição gráfica da história do produto, descrevendo os estágios pelos quais o produto passa. O início do ciclo é marcado pelos primeiros esforços organizados e planejados para criar o produto. O ciclo de vida do produto não acaba quando sua manufatura ou venda é descontinuada. Existem produtos que são usados por muito tempo após as vendas terem sido encerradas. Um exemplo típico são os aviões e automóveis. Contanto que a empresa ainda forneça ou fabrique componentes, o ciclo de vida do produto continua. Do ponto de vista da empresa, o final de um ciclo de vida de um produto é quando acaba o suporte de pós-vendas do produto. Nesse evento, é marcado o fim de qualquer forma de compromisso da empresa com o suporte ao produto. Isso significa que primeiro será descontinuada a manufatura, o estoque será vendido e não serão mais fornecidos componentes sobressalentes. Em alguns casos, as empresas fazem acordos com os consumidores para manter um estoque durante determinado período. As empresas devem preparar um inventário de componentes sobressalentes ou preservar o ferramental para possíveis necessidades. Existem vários modelos propostos, com números diferentes de estágios. Esses estágios caracterizam-se por ser seqüenciais e hierárquicos.

216

PARTE 2

Figura 6.4

O Modelo

Tarefas da atividade “Detalhar o ciclo de vida do produto”.

É importante a visão abrangente da “vida” do produto

Figura 6.5

Um dos modelos, muito utilizado principalmente na fase de pré-desenvolvimento, é o que mostra a evolução do projeto/produto em termos dos recursos financeiros associados com as diferentes fases ou estágios do ciclo, conforme mostrado na Figura 6.5.

Ciclo de vida segundo a evolução das vendas do produto.

A fase de desenvolvimento, que compreende o planejamento, projeto e produção, é caracterizada por um investimento crescente até o lançamento do produto no mercado. Nas fases de lançamento e crescimento, os custos de pesquisa e desenvolvimento, bem como os custos adicionais de promoção e penetração no mercado,

CAPÍTULO 6

Projeto Informacional

217

fazem com que os lucros sejam negativos ou baixos. Essas fases caracterizam-se por ser períodos de investimento e risco. Ocorre um aumento dos lucros durante a fase de crescimento e, geralmente, poucas empresas obtêm lucro antes dessa fase. Na fase de maturidade, tem-se uma estabilidade, mais bem descrita como um período sem crescimento e de estagnação do mercado. A maior parte dos lucros com o produto é obtida nessa fase. Na fase seguinte, de declínio, ocorre uma diminuição nas vendas causada por fatores como aumento da concorrência com novos produtos, por inovações e desenvolvimentos tecnológicos que levam o produto à obsolescência e a mudanças de hábitos nos consumidores. Em geral, nessa fase, as empresas gradativamente eliminam os canais de distribuição menos rentáveis para, em seguida, encerrar a produção do produto. O abandono de produtos geralmente ocorre após a fase de declínio, mas é possível, em alguns casos, que o produto vá diretamente da fase de crescimento para o declínio. Também, em termos das atividades relacionadas aos estágios ou fases pelas quais um produto passa, o ciclo de vida pode ser representado conforme mostra a Figura 6.6. Figura 6.6

Ciclo de vida segundo as atividades pelas quais o produto/projeto passa.

É importante ressaltar que cada produto possui seu próprio ciclo de vida, e que, com as informações levantadas na macrofase anterior, busca-se definir as fases do ciclo de vida do produto, baseando-se no conhecimento existente sobre produtos similares ou baseando-se nos produtos que o antecederam. Além disto, o ciclo de vida depende de vários fatores, dentre os quais se destacam: tipo de produto que vai ser projetado; tipo de projeto a ser executado; escala de produção; características de funcionamento; características de uso e manuseio; serviços de manutenção e filosofia de desativação.

218

PARTE 2

Quadro 6.2

O Modelo

Clientes e Ciclo de Vida

A definição dos clientes, associados às diferentes fases do ciclo de vida, vem a seguir. Os clientes de um projeto podem ser classificados em três tipos diferentes: clientes externos, clientes intermediários e clientes internos. O termo clientes externos é utilizado para definir o conjunto de pessoas ou organizações que irão usar ou consumir o produto, e/ou manter, desativar e retirar o produto. De uma forma geral, esses clientes desejam que os produtos contenham atributos, tais como: qualidade, baixo preço de aquisição e manutenção, eficiência, segurança, durabilidade, confiabilidade, fácil operação, manutenção e descarte, visual atrativo (estéticos), e que incorporem as últimas tendências e desenvolvimentos tecnológicos e, ainda, que sejam ecologicamente corretos. Os desejos desses clientes devem ser tratados com a máxima prioridade, pois, se o produto não atender às necessidades e requisitos desses, o produto resultará em um fracasso em termos de vendas. Os clientes intermediários correspondem àqueles responsáveis pela distribuição, compras, vendas e marketing do produto. Esses, normalmente, esperam que o produto satisfaça a todos os desejos e necessidades dos clientes externos, seja fácil de embalar, armazenar e transportar, seja atrativo e possa ser adequadamente exposto para o público. O atendimento dessas necessidades é um fator determinante para que o distribuidor tenha sucesso na venda do produto. Por clientes internos, entende-se como sendo os fabricantes e o pessoal envolvido no projeto e na produção dos produtos. Esses esperam que o produto contenha operações de fabricação, montagem, armazenamento e transporte fáceis e seguros, utilize recursos disponíveis (instalações, equipamentos, matéria-prima e mão-de-obra), utilize componentes padronizados, utilize as facilidades existentes e produza um mínimo de refugos e partes rejeitadas. As categorias de clientes são mostradas na Figura 6.7 formando parte e sendo associadas aos setores produtivos (clientes internos), que são aqueles setores em que se agrega valor ao produto; aos setores de mercado (clientes intermediários), em que o produto é comercializado; e aos setores de consumo (clientes externos), em que o produto é usado em funcionamento. Os atributos relacionados às diferentes fases do ciclo de vida auxiliam na definição das características físicas, de forma, de materiais, de uso, de fabricação e outras. Figura 6.7

Modelo do ciclo de vida em espiral (adaptado de Fonseca, 2000).

(continua)

CAPÍTULO 6

Projeto Informacional

Quadro 6.2

219

Clientes e Ciclo de Vida (continuação)

Essa visão do relacionamento entre ciclo de vida do produto e seus clientes é de grande interesse ao Processo de Desenvolvimento de Produtos (PDP), pois fornece uma visão mais ampla de todo o processo, permitindo o desenvolvimento de soluções específicas para cada um desses clientes. Outra visão de grande importância do relacionamento entre clientes e ciclo de vida é originada do marketing. Nessa visão, os clientes externos do produto são divididos em quatro categorias, relacionadas ao fluxo de vendas apresentado na Figura 6.5. São elas:

• Lançamento: neste período, freqüentemente, é observada uma taxa de crescimento em vendas relativamente forte, porém uma participação no mercado (market-share) ainda pequena. Os lucros ainda não foram suficientes para suplantar as despesas com projeto e lançamento do produto. Os clientes usualmente encontrados durante essa fase do ciclo de vida do produto são caracterizados pelo impulso de ser os primeiros a possuir tal bem, normalmente visando atrair as atenções daqueles que se encontram ao seu redor. Tais clientes foram chamados por Kottler (1988) de “inovadores”.

• Crescimento: as vendas já conseguiram suplantar as despesas realizadas no desenvolvimento do produto (existem e continuam as despesas para produzir e distribuir o produto) e a participação no mercado já se aproxima de seu ápice, sendo observado, até mesmo, um lucro mediano. O perfil de cliente que atua nesse instante do ciclo de vida do produto é caracterizado por pessoas que, ao verem uma nova tecnologia ser bem-sucedida, passam a adotá-la, causando um elevado crescimento na taxa de vendas. A esses clientes é dado o nome de “prontos adotadores”.

• Maturidade: a taxa de crescimento das vendas é muito fraca ou, até mesmo, nula, não havendo grandes variações na cota de mercado do produto. No entanto, é durante esse período que a empresa acaba por conseguir os maiores lucros, já que grande parte das despesas foi amortizada nas fases anteriores do ciclo de vida. Os clientes presentes nessa fase do ciclo de vida do produto são os chamados “maioria inicial”, os quais compram o produto, em grande parte, por imitação.

• Declínio: os lucros passam a fracos ou, até mesmo, a negativos, dado o declínio da participação do produto no mercado, sendo observada uma taxa de crescimento negativa. Para a empresa, é importante manter o monitoramento durante a maturidade do produto de forma a identificar o mais rapidamente possível o aparecimento da fase de declínio e, se for necessário, descontinuar o produto. Nessa fase, as vendas são feitas aos clientes mais fiéis do produto, os quais não foram atraídos por novas marcas ou tecnologias.

6.5

Identificar os requisitos dos clientes do produto

Nesta atividade, inicialmente busca-se levantar as necessidades dos clientes de cada fase do ciclo de vida. Essas necessidades “brutas”, na forma de variáveis lingüísticas, podem ser obtidas com o uso de listas de verificação ou por meio de observação direta, entrevistas e grupos de foco, ou usando qualquer outro método de interagir com os diferentes clientes (consulte o Quadro 4.1, no Capítulo 4). É necessário um processamento dessas necessidades inicialmente obtidas, classificando-as, ordenando-as e agrupando-as. A Figura 6.8 ilustra as tarefas envolvidas nesta atividade. Assim, posteriormente à obtenção das necessidades, é conveniente que essas necessidades sejam agrupadas e classificadas, incluindo aquelas necessidades já detectadas na Declaração do Escopo do Produto. As necessidades serão agrupadas de acordo com as fases do ciclo de vida correspondente ou por afinidades, por meio do diagrama de afinidades. O agrupamento possibilita verificar as necessidades similares, eliminando-se as É necessário tratar as repetições e aquelas necessidades pouco relevantes para o projeto. Recomenda-se necessidades obtidas levar adiante somente um grupo mínimo de necessidades. diretamente dos clientes Após o agrupamento, análise e classificação, essas necessidades, inicialmente descritas segundo a linguagem dos clientes, podem ser reescritas na forma do que chamamos de “requisitos dos clientes”. Os requisitos dos clientes podem ser relacionados a aspectos, tais como: desempenho funcional, fatores humanos, propriedades, espaço, confiabilidade, ciclo de vida, recursos e manufatura.

220

PARTE 2

Figura 6.8

O Modelo

Tarefas da atividade “Identificar os requisitos dos clientes do produto”.

Os requisitos ligados ao desempenho funcional representam os elementos de desempenho que descrevem o comportamento desejado para o produto. Esse comportamento pode ser descrito em termos dos fluxos de energia, material e sinal, ou por informações a respeito das operações e sua seqüência. Os requisitos ligados aos fatores humanos estão relacionados com a interface do produto com as pessoas. Os requisitos também podem estar relacionados às propriedades físicas, elétricas, térmicas, mecânicas, químicas e nucleares. O desejo por produtos duráveis está associado à confiabilidade. É importante entender o que confiabilidade significa para o consumidor, quais as conseqüências da falha do produto e as implicações relacionadas à segurança. Os requisitos associados com o ciclo de vida permitem que sejam considerados os diferentes aspectos das fases pelos quais o produto irá passar, além daqueles relacionados com a fase de uso. Vários são os requisitos relacionados aos recursos. O tempo é um recurso limitado em qualquer projeto. Os requisitos de custo estão relacionados aos custos de capital e aos custos do ciclo de vida. Requisitos relacionados às normas e ao meio ambiente são outros exemplos de requisitos ligados aos recursos. É extremamente importante que a equipe de desenvolvimento identifique os requisitos ambientais, considerando no projeto o impacto do produto durante a produção, uso e retirada. Os requisitos dos clientes podem ser registrados diretamente na matriz da Casa da Qualidade, conforme mostrado no Quadro 6.5, mais adiante, neste capítulo. É importante que seja entendido o que os clientes realmente esperam do produto, para que o Time de Desenvolvimento possa “escutar a voz dos clientes”. Outro aspecto importante é que os clientes normalmente se expressam em termos das falhas dos produtos, ou do que eles não gostaram na sua experiência com o uso do produto. Isso requer um esforço do Time de Desenvolvimento para descobrir o que os clientes esperam do produto, ou seja, suas necessidades latentes que não são mencionadas pelos clientes. Essa dificuldade é representada graficamente, considerando-se a satisfação dos clientes versus o desempenho do produto conhecido como Diagrama de Kano, como mostrado na Figura 6.9.

CAPÍTULO 6

Projeto Informacional

Figura 6.9

221

Diagrama de Kano de satisfação dos clientes.

Segundo esse diagrama, existem determinados requisitos do produto qualificados como básicos, que não geram um incremento de satisfação suficiente nos clientes, pois esses consideram que tais requisitos necessariamente têm de estar no produto. Geralmente são requisitos que não são verbalizados pelos clientes. Os consumidores irão mencioná-lo se o mesmo requisito não aparecer no produto. Ou seja, se o requisito não estiver implementado no produto final, os consumidores ficarão insatisfeitos. Se esses são incluídos, os clientes ficarão neutros. O segundo tipo de requisito são os chamados requisitos com desempenho esperado, ou seja, aqueles requisitos verbalizados pelos clientes e que, quanto melhor o seu desempenho, maior será a satisfação dos clientes. O principal objetivo de determinar o que os clientes esperam do produto (voz dos clientes) é achar os requisitos que realmente agradam e surpreendem favoravelmente os clientes, pois geram benefícios que os clientes não esperavam. Esses requisitos que causam impacto no cliente agrupam características e qualidades do produto não-verbalizadas na maioria das vezes pelos clientes. Representam os desejos ocultos e desconhecidos, insatisfações toleradas, expectativas até agora não alcançadas, novas facetas de uso e aplicação, aspectos de personalização do produto para o cliente etc. Essa visão dos requisitos dos clientes vem confirmar que existem necessidades que o cliente não conhece, ou, caso conheça, não sabe expressar o suficiente. Ao longo do tempo, com a evolução natural do mercado, os requisitos que excitam e surpreendem os clientes, hoje, tornaram-se os requisitos de desempenho esperado de amanhã, e, posteriormente, vão se tornar os requisitos básicos. Isso é verdade para uma ampla gama de produtos. Quando inicialmente introduzidas, novas características são consideradas especiais, surpreendendo e agradando os clientes. Após certo tempo, todos os concorrentes utilizam essas características e alguns com desempenho melhor que outros. Mais adiante, chega-se ao ponto em que essas características não são mais mencionadas nas propagandas do produto, uma vez que se tornaram características ou requisitos básicos. Com isso, o Diagrama de Kano nos mostra a necessidade contínua de achar novos requisitos que excitam/impactam os clientes. A valoração dos requisitos dos clientes é uma importante tarefa, pois os valores Os requisitos dos clientes (ou, também chamados, pesos) desses requisitos são indispensáveis para a utilização devem ser valorados da Matriz da Casa da Qualidade (Quality Function Deployment, QFD) em uma taquanto a sua importância refa posterior.

222

PARTE 2

Quadro 6.3

O Modelo

Visão dos Custos do Ciclo de Vida

Na preparação das informações sobre os custos, é importante que a equipe de projeto tenha uma visão das diversas áreas e fatores que afetam o custo do produto. A Figura 6.10 apresenta uma estrutura de desdobramento de custos, relacionando os custos do ciclo de vida do produto. Figura 6.10

Estrutura de desdobramento de custo (adaptada de Ferreira, 1997)

Embora os valores dos requisitos dos clientes possam ser definidos diretamente pela equipe de projeto, pode-se utilizar um procedimento mais sistematizado, que dependa menos da opinião pessoal de cada membro da equipe, tal como o Diagrama de Mudge. Nesse, a valoração é feita pela comparação dos requisitos aos pares, ou seja, cada requisito é comparado com cada um dos outros requisitos. Em cada comparação são feitas duas perguntas: Qual requisito é mais importante para o sucesso do produto? Quanto mais importante é esse requisito? Para finalizar a definição da importância dos requisitos dos clientes, pode-se realizar um benchmarking entre os produtos existentes no mercado, que concorreriam com o produto em desenvolvimento. Pode-se veri-

CAPÍTULO 6

Projeto Informacional

223

ficar se esses produtos possuem esses requisitos levantados. Pode-se, inclusive, realizar clínicas de avaliação (focus group — veja o Quadro 4.1, no Capítulo 4) dos produtos dos concorrentes. Assim, consegue-se levantar quanto os produtos dos concorrentes atendem a esses requisitos. Com isso, pode-se evitar que se desenvolva um produto com “qualidade exagerada”. Isto é, se um requisito do cliente for muito difícil de ser atendido, pois os custos associados são elevados, e nenhum concorrente também o atende, então, a empresa pode decidir estar melhor que os concorrentes, porém não atender completamente os desejos dos clientes.

6.6

Definir os requisitos do produto

Como se pode observar, na atividade anterior foi dado um primeiro passo importante, a obtenção da voz dos clientes, na forma das suas necessidades, ela foi levada à linguagem dos projetistas (requisito dos cliente). Entretanto, esses requisitos dos clientes geralmente estão ainda na forma de necessidades, sem estarem associados às características mensuráveis do produto. De uma forma geral, as necessidades são informações que tendem a expressar os desejos dos clientes, normalmente de uma forma qualitativa, e, em alguns casos, em termos subjetivos e vagos. Infelizmente, informações nessas condições não permitem uma comunicação precisa, necessária para o desenvolvimento adequado de um produto. Para obter-se uma comunicação precisa durante o desenvolvimento do projeto de um produto, torna-se fundamental que as informações que irão caracterizar o produto estejam de acordo com a linguagem técnica de engenharia. Ou seja, torna-se necessário “dizer em números” — expressão essa que significa que o produto a ser desenvolvido deve ser descrito por meio de características técnicas, possíveis de serem mensuradas por algum tipo de sensor. Assim, os parâmetros mensuráveis associados à descrição do desempenho esperado são os chamados requisitos do produto ou requisitos de engenharia. A obtenção dos requisitos do produto a partir dos requisitos dos clientes se constitui na primeira decisão física sobre o produto que está sendo projetado. Essa ação definirá parâmetros mensuráveis, associados às características definitivas que terá o produto, razão pela qual essa etapa se constitui em um momento importante para o todo o processo de projeto. A Figura 6.11 ilustra as tarefas dessa atividade. A obtenção desses requisitos poderá ser feita utilizando-se diferentes meios, tais como: brainstorming, checklists e informações de outros projetos. Figura 6.11

Tarefas da atividade “Definir requisitos de projeto do produto”.

224

PARTE 2

Quadro 6.4

O Modelo

Checklist para Obtenção de Requisitos de Produto

A utilização de checklists auxilia o trabalho sistemático e reduz as chances de que algum parâmetro ou alguma informação importante sejam desconsiderados. A seguir, é apresentada uma checklist baseada na proposta de Pugh (1990).

• Desempenho Qual(is) a(s) função(ões) que o produto tem que cumprir? Quais são os parâmetros pelos quais as características funcionais serão avaliadas (velocidade, potência, resistência, precisão, capacidade etc.)?

• Meio ambiente Quais as influências ambientais a que o produto estará sujeito durante a manufatura, armazenamento, transporte uso (temperatura, vibrações, umidade etc.)? Quais os efeitos do produto sobre o meio ambiente que devem ser evitados?

• Vida em serviço Quais as faixas de utilização do produto? Qual é a vida útil esperada para o produto?

• Eficiência Quais as características relativas à eficiência que o produto deverá exibir? Custos, disponibilidade, confiabilidade (tempos, modos e efeitos associados às falhas), manutenabilidade (tempos) etc.?

• Transporte Quais são os requisitos de transporte durante a produção e entrega do produto?

• Embalagem Embalagem é necessária? Contra quais influências deve a embalagem proteger o produto?

• Quantidade Qual o tamanho do lote? A produção será contínua ou por batelada?

• Infra-estrutura O produto deverá ser projetado para infra-estruturas de manufatura existentes? São possíveis investimentos em novas instalações para a produção?

• Tamanho e peso Quais são os limites de tamanho e peso em função da produção, transporte e uso?

• Estética, aparência e acabamento Quais são as preferências dos consumidores? Deverá o produto ter que seguir alguma tendência ou estilo específico?

• Materiais São necessários materiais especiais? Existem materiais que não devem ser usados (por razões de segurança dos usuários ou por efeitos do meio ambiente)? Quais as propriedades dos materiais que são necessárias?

• Normas Quais são as normas (internas, nacionais e internacionais) aplicáveis ao produto e a produção?

• Ergonomia Quais os requisitos com relação à percepção, uso, manipulação etc., a que o produto deverá atender?

• Armazenamento e vida de prateleira São necessários longos períodos de tempo de armazenamento durante a produção, distribuição e uso? Isso torna necessária alguma medida específica de conservação?

• Testes Para quais testes funcionais e de qualidade o produto será submetido, dentro e fora da empresa?

• Segurança Deverá ser providenciada alguma estrutura ou instalação especial para a segurança dos usuários e não usuários?

• Política do produto A família ou plataforma do produto impõe algum requisito sobre o produto?

(continua)

CAPÍTULO 6

Projeto Informacional

Quadro 6.4

225

Checklist para Obtenção de Requisitos de Produto (continuação)

• Implicações sociais e políticas Qual a opinião do público com relação ao produto?

• Responsabilidade do produto Quais são as possíveis conseqüências não intencionais da produção, operação e uso pelas quais o fabricante poderá ser responsabilizado?

• Operação e instalações Quais requisitos são necessários para a montagem e instalação final fora da fábrica, e para o aprendizado, uso e operação do produto?

• Reuso, reciclagem e descarte É possível prolongar o ciclo dos materiais pelo reuso dos materiais e partes? Podem os materiais e suas partes ser separados para o descarte?

Na conversão dos requisitos dos clientes em requisitos do produto pode-se utilizar o grau de importância para o foco em alguns requisitos. Com isso, é feita a primeira possível definição de parâmetros críticos do produto (veja o Quadro 8.10, no Capítulo 8). Após realizar a conversão, é analisada a correlação entre os requisitos dos clientes e os requisitos do produto. Normalmente, avalia-se com que intensidade um requisito do produto contribui para o requisito do cliente. Um exemplo de escala de intensidade é: baixa, média ou elevada. Imagine que um requisito dos clientes de uma impressora seja “facilidade de instalação”. Os requisitos do produto resultantes poderiam ser: maior quantidade de portas de conexão; compatibilidade com a maior quantidade de sistemas operacionais; existência de drivers na Internet; software tutorial para instalação; manual com gráficos explicando os passos de instalação; tabela de referência rápida para auxiliar a instalação. Nem todos esses requisitos contribuiriam com a mesma intensidade para se atender ao requisito do cliente. Por exemplo, a existência de drivers que possam atuar no método de instalação plug and play contribui mais do que o manual com gráficos. Nas tarefas de analisar, classificar e hierarquizar os requisitos do produto, poderiam ser usados como referência o grau de importância dos requisitos dos clientes e a intensidade de contribuição. Ou seja, um requisito do produto que contribui intensamente para se atingir um requisito do cliente é mais importante e merece um foco maior do que outro requisito que contribui pouco — ou que contribui para um requisito do cliente que não seja importante.

6.7

Definir especificações-meta do produto

Para formalizar a tarefa de projeto, é necessário um conjunto de informações completas e sem ambigüidades, que será utilizado como base para o desenvolvimento das etapas posteriores do processo de projeto. A Figura 6.12 ilustra as tarefas desta atividade. As chamadas especificações-meta de um produto são parâmetros quantitativos e mensuráveis que o produto projetado deverá ter. Assim, além de unidades, as especificações-meta deverão ter valores-meta, que são números que estabelecem o desempenho requerido. Nada mais são do que os requisitos do produto associados com valores-meta, os quais podem ser um valor específico (15kg/s), uma faixa de valores (de 10mm a 15mm) ou valores com tolerâncias (15 ±2). As especificações, além de atuarem como guias para a geração de soluções para o problema de projeto, fornecem a base sobre a qual serão montados os critérios de avaliação e de tomada de decisão, utilizados nas etapas posteriores do processo de projeto. Nesse momento, é bom avaliar a correlação entre os requisitos de produto, pois pode haver uma correlação positiva ou negativa no atendimento dos requisitos dos clientes. Isto é, os valores de um requisito do produto têm de ser aumentados para atender a alguns requisitos dos clientes, mas, ao mesmo tempo, isso causa um efeito negativo em outro. Vamos exemplificar para ficar mais claro.

226

PARTE 2

Figura 6.12

O Modelo

Tarefas da atividade “Definir especificações-meta do produto”.

Imagine que estejamos analisando dois requisitos de uma máquina. Um seria a tolerância de precisão do eixo-árvore, para atender ao requisito do cliente de obter tolerâncias apertadas de fabricação. Um outro requisito seria o acabamento da carcaça fundida, que deveria ser baixo, para atender ao requisito de baixo custo do cliente. Se a tolerância da carcaça for baixa, ela interferirá na precisão de giro do eixo-árvore. Esse é um trade off, e é preciso adotar uma solução de compromisso que atenda de forma satisfatória aos dois requisitos. De um lado, deve-se analisar até que ponto a tolerância da carcaça pode ser aberta, para não afetar a precisão de giro. Por outro, deve-se também avaliar se a tolerância do eixo-árvore tem de ser tão apertada assim, pois, com isso, os custos ficam elevados. As especificações possuem uma natureza evolucionária e são informações que podem mudar constantemente. Essas mudanças nas especificações podem ocorrer durante a sua obtenção, ao longo do desenvolvimento do produto e após o produto estar em uso. Algumas especificações praticamente não sofrem mudanças, ou sofrem mudanças muito lentas, enquanto outras, por exemplo, aquelas ligadas a um consumidor particular e relacionadas ao funcionamento de um produto em um ambiente particular, podem mudar de forma consideralvelmente rápida. Outros fatores que podem levar a mudanças nas especificações são: mudanças nas prioridades dos consumidores durante o desenvolvimento do produto em função de mudanças no ambiente de negócios; emergência de novos competidores etc.; mudanças no ambiente no qual o produto atuará, tornando necessárias as mudanças nas especificações para manter a compatibilidade; além de a organização que usará o produto poder mudar sua estrutura e processos, resultando em mudanças nas especificações que o produto deverá atender. A gestão das especificações tem uma forte relação com a gestão da qualidade, pois ambas estão direcionadas para aquilo que o consumidor espera (qualidade). Existem várias técnicas para auxiliar a equipe de projeto na geração das especificações-meta. Uma das mais conhecidas é o chamado QFD, mais especificamente a Matriz da Casa da Qualidade (Hauser & Clausing, 1988; King, 1989; Akao, 1990).

CAPÍTULO 6

Projeto Informacional

Quadro 6.5

227

Quality Function Deployment (QFD)

Este método foi desenvolvido no Japão nos anos 1970 e ganhou o mundo no início dos anos 1990. O QFD auxilia os projetistas no trabalho em equipe por meio da busca pelo consenso nas diferentes definições sobre o produto. Possibilita o estabelecimento de relações entre necessidades dos clientes e requisitos de projeto, documentar dados de benchmarking, das especificações por meio da definição de valores-meta associados aos requisitos de projeto, verificar os conflitos entre os requisitos de projeto e as dificuldades técnicas associadas a cada requisito. Os principais benefícios do QFD são: redução do número de mudanças de projeto; diminuição do ciclo de projeto; redução dos custos de início de operação (start-up); redução de reclamações de garantia; planejamento da garantia de qualidade mais estável; favorece a comunicação entre os diferentes agentes que atuam no desenvolvimento do produto, principalmente marketing e engenharia (projeto e manufatura); traduz as vontades dos clientes que são vagas e não mensuráveis em características mensuráveis; identifica as características que mais contribuem para os atributos de qualidade; possibilita a percepção de quais as características que deverão receber maior atenção. São várias as versões existentes do QFD. Entre as mais conhecidas, temos aquelas propostas por Akao (1990), King (1989) e ASI (1993). A seguir, será descrito o modelo da ASI. A estrutura típica da primeira matriz do QFD, conhecida como Matriz da Casa da Qualidade, é mostrada na Figura 6.13. Figura 6.13

Matriz da Casa da Qualidade do QFD.

Na seqüência ilustrada na Figura 6.13, observa-se que o desenvolvimento das informações começa com o estabelecimento de quem são os consumidores e o que eles esperam na forma dos requisitos dos clientes, que é o que os clientes esperam que o produto faça (corresponde ao campo 1 da Figura 6.13). No desenvolvimento dessas informações, pode-se determinar a importância de cada um desses requisitos para os clientes (campo 2). No campo 3, pode-se identificar a situação atual do produto com relação aos concorrentes, comparando quanto os requisitos dos clientes estão sendo satisfeitos tanto pelos competidores, quanto pelos produtos similares da empresa (se ela já tiver algum produto que atenda a esses requisitos). Com isso, pode-se encontrar oportunidades para melhorias no produto. É possível criar várias colunas nesse campo, contendo informações tais como: reclamações (número de reclamações relativas a determinado requisito do cliente), importância (indicação qualitativa de quanto determinado requisito do cliente influencia sua decisão de compra), qualidade desejada (indicação de qual é o nível em que a empresa deseja satisfazer seus clientes), taxa de melhoria (é a razão entre a qualidade desejada e o nível atual com que a empresa satisfaz determinado requisito do cliente), pontos fortes de vendas (baseado nas comparações com os competidores, pode-se identificar pontos fortes de venda para o produto que está sendo desenvolvido). Em seguida, parte-se para o estabelecimento dos requisitos do produto (campo 4), que representam como será medida a habilidade do produto para satisfazer os requisitos dos clientes. A correlação entre os requisitos dos clientes (os “quês”) e os requisitos do produto (os “como”) é dada pela Matriz de Relacionamento (campo 5). Para cada célula da matriz é determi-

(continua)

228

PARTE 2

Quadro 6.5

O Modelo

Quality Function Deployment (QFD) (continuação)

nado se existe uma relação ou não, e, caso exista, qual a sua intensidade. A quantificação dos requisitos irá formar o conjunto de especificações para o produto a ser desenvolvido (campo 6). As interações entre os requisitos do produto formam o chamado “telhado” da Casa da Qualidade, e propicia um entendimento sobre a natureza, efeitos e intensidade possíveis entre os requisitos do produto (campo 7). Relação da Casa da Qualidade e o Modelo Unificado Na Tabela 6.1 são comparados esses campos e as atividades descritas nesta fase. Tabela 6.1 Comparação entre os Campos e as Atividades da Fase de Projeto Informacional Capítulo

Campo do QFD

1

Requisitos dos clientes

2

Importância dos requisitos

3

Benchmarking com produtos dos concorrentes

4

Requisitos do produto

5

Correlação entre requisitos dos clientes e requisitos do produto

6

Quantificação dos requisitos do produto (valor-meta)

7

Correlação entre os requisitos do produto

Atividades da fase de Projeto Informacional

Identificar os requisitos dos clientes do produto

Definir os requisitos do produto

Definir especificações-meta do produto

Após a construção da Casa da Qualidade, tem-se em mãos uma quantidade apreciável de dados sumarizados, de razoável confiabilidade, prontos para ser utilizados no processo de tomada de decisões pelas pessoas envolvidas no desenvolvimento do produto. Os diferentes especialistas poderão, por exemplo, usar a classificação dos requisitos do produto como instrumento para a priorização das atividades de desenvolvimento. Outra saída importante da Casa da Qualidade diz respeito aos relacionamentos obtidos em seu telhado. Tais relacionamentos permitem identificar os requisitos do produto que deverão ser tratados de modo integrado, minimizando, então, os possíveis efeitos oriundos de relacionamentos do tipo “conflitante”. Outro fato importante acerca da Casa da Qualidade é que ela encontrará a sua finalidade nos diversos segmentos dentro da empresa, sem, contudo, divergir quanto aos objetivos almejados. Em outras palavras, seja qual for o usuário final, as conclusões irão sempre estar centradas no consumidor do produto. Por exemplo, enquanto para os executivos de marketing a Casa da Qualidade poderá representar a voz do consumidor, para os administradores de alto escalão, ela poderá representar uma fonte de dados a ser usada para descobrir oportunidades estratégicas, sendo que, para ambos, os objetivos estarão centrados nas necessidades do consumidor.

Desdobrando a Casa da Qualidade O desdobramento da Função Qualidade, refere-se basicamente às atividades necessárias para assegurar que a qualidade requisitada pelo consumidor seja realmente alcançada. Na primeira etapa do desdobramento, os “como” da primeira matriz — chamada de Casa da Qualidade — (os requisitos do produto) são colocados como os “quês”, formando a coluna da esquerda da segunda matriz, como mostra a Figura 6.14. A nova matriz servirá como base para várias das atividades das demais fases do desenvolvimento, identificando as características dos componentes de que o produto necessita para satisfazer os requisitos do produto (os “como” dessa segunda matriz). É importante notar que nem todos os requisitos do produto da primeira matriz (Casa da Qualidade) deverão ser desdobrados, mas somente aqueles que representam obstáculos de ordem técnica, e que realmente sejam importantes para a satisfação final do consumidor. Na Figura 6.14 são mostrados os desdobramentos da Casa da Qualidade em sistemas, subsistemas, componentes, processo e produção. Dificilmente são realizados todos esses desdobramentos. Se o produto não tiver tantos níveis hierárquicos

(continua)

CAPÍTULO 6

Projeto Informacional

Quadro 6.5

229

Quality Function Deployment (QFD) (continuação)

(sistemas, subsistemas etc.), a quantidade de desdobramentos diminui. Também não se deve desdobrar para todos os itens do produto e, sim, somente para os mais importantes — os itens críticos. Veja o Quadro 8.10, no Capítulo 8. Figura 6.14

Desdobramento da Casa da Qualidade.

Os procedimentos de construção e utilização tanto dessa nova matriz quanto das que a seguirão cumprem as mesmas convenções anteriormente apresentadas. A novidade é que o desdobramento dos componentes utiliza ferramentas de apoio, tais como: Análise de Valor, Análise da Árvore de Falhas (AAF), Análise de Modo de Falha e Efeito (FMEA), otimização de produtos e processos, projeto de experimentos (Método de Taguchi), Análise de Custos e Seleção de Componentes, para garantia de confiabilidade e obtenção de valores-objetivos que trazem melhor desempenho para o produto. Essa fase termina com a identificação das características críticas dos sistemas, subsistemas e componentes para a execução dos requisitos do produto. São essas características críticas que são desdobradas e formarão os “quês” das próximas matrizes. A matriz de planejamento de processo relaciona as características críticas dos componentes do produto (“o quê”) com os parâmetros dos processos de manufatura, ou seja, os “como” alcançá-los. Representa a transição das operações de projeto para as de fabricação. Esses documentos incluem informações como: lista de requisitos de processos e lista dos parâmetros de controle do processo. A matriz de planejamento da produção transfere as informações geradas nas fases subseqüentes para o chão de fábrica. Essa matriz relaciona os parâmetros dos processos de manufatura com os requisitos de produção. Nessa fase, são gerados documentos de forma a dar instruções de operação, ou seja, as listas operacionais que definem “como” os operadores devem executar as operações-chave de manufatura. A importância dessa documentação está na definição dos pontos de verificação e controle, informando claramente ao operador quais são as partes envolvidas, quantas serão verificadas, que ferramenta utilizará e como fará a checagem. Em outras palavras, o operador tem uma indicação do que é mais importante para o consumidor em relação à qualidade do produto.

QFD de quatro ênfases Dificilmente consegue-se desdobrar até o nível de processo, para empresas de manufatura discreta (para processos contínuos é mais comum). Por conseqüência, não se encontram muitos casos práticos de desdobramento até o nível de produção. Essa flexibilização pode acontecer se for utilizado o QFD de quatro ênfases, Cheng, et al. (1995).

(continua)

230

PARTE 2

Quadro 6.5

O Modelo

Quality Function Deployment (QFD) (continuação)

O desdobramento da qualidade (QD) possui a ênfase em: qualidade, tecnologia, custo e confiabilidade. A primeira matriz também é a Casa da Qualidade apresentada. Os desdobramentos sucessivos são guiados por um modelo conceitual, que mostra quais são as correlações mais interessantes para cada caso. A cada aplicação específica do QD, deve-se, antes de tudo, definir um modelo conceitual. O modelo conceitual representa a lógica para a confecção das matrizes. A Figura 6.15 apresenta um exemplo de um modelo conceitual. Figura 6.15

Exemplo de um modelo conceitual.

Na Figura 6.15, o desdobramento da Casa da Qualidade (matriz A) converte os requisitos dos clientes em requisitos do produto, definindo o seu grau de importância. O modelo conceitual mostra que os requisitos do produto são convertidos em funções do produto (matriz B). É definido o grau de importância das funções, com base no grau de importância dos requisitos dos clientes (matriz C). As funções são desdobradas em subsistemas, que realizam as funções (matriz D). Consegue-se assim saber qual o subsistema mais importante (é aquele que realiza uma função mais importante). Finalmente são definidos os componentes mais importantes desses subsistemas (matriz E).

Equivalência de termos do QFD O termo ”requisitos dos clientes“ é conhecido na literatura por qualidade exigida. Depois que esses requisitos são ponderados e valorados com base no grau de importância e benchmarking, eles se tornam a qualidade planejada. O termo “requisitos do produto“ é conhecido na literatura por característica da qualidade (do produto). Depois de ponderado com relação à qualidade planejada e depois de realizado o benchmarking técnico com os produtos dos concorrentes, ele se torna a qualidade planejada, que é o que chamamos de requisitos com valores-meta. Leia mais sobre este assunto em Cheng, 1995

É recomendável, em um primeiro momento, confrontar os requisitos de projeto com o problema de projeto original. A confrontação é feita visando verificar se a filosofia inicial implícita no problema que deu início ao projeto está sendo considerada, e também visando incluir outros elementos de importância como parte das especificações, decidindo quais requisitos de projeto integrarão, finalmente, as especificações. Como parte desta ati-

CAPÍTULO 6

Projeto Informacional

231

vidade, devem ser consideradas as restrições técnicas, do mercado e as de projeto do produto (contrato, ambientais, legislação, normas, geometria, operação, funcionais, manufatura). Assim, mesmo que os requisitos de projeto formem a base para a elaboração das especificações de projeto, outros requisitos de clientes importantes, mesmo qualitativos, poderão fazer parte das especificações de projeto. As especificações de projeto, além de proporcionar um guia para a obtenção de concepções para o produto, devem claramente refletir os elementos em relação a quais serão avaliados depois do projeto e do produto resultante. Uma representação típica de um documento de Especificações-meta do produto está mostrada na Figura 6.16. São estabelecidos elementos sensores, por meio dos quais é possível medir se os objetivos estão ou não sendo atingidos nas diversas fases do desenvolvimento do projeto. Pode-se também colocar as saídas indesejáveis, que representam o que, exatamente, se pretende evitar com a agregação dessa especificação. Figura 6.16

Estrutura de uma lista de Especificações-meta do produto (adaptado de Gomes Ferreira, 1997).

A Figura 6.17, a seguir, mostra uma síntese do fluxo de informações existente na fase de Projeto Informacional e as principais ferramentas. Figura 6.17

Evolução das informações na Fase de Projeto Informacional.

232

6.8

PARTE 2

O Modelo

Monitorar a viabilidade econômico-financeira

Nesta atividade, a equipe de projeto deve verificar inicialmente se foram considerados as necessidades e os requisitos de custo, ou seja, se as informações em termos dos custos nas diversas etapas do ciclo de vida do produto foram devidamente levadas em conta. Com requisitos e especificações detalhados, o nível de conhecimento sobre o produto aumentou. O primeiro passo será verificar se as especificações de custo definidas (requisitos de custos expressos com um número e uma unidade monetária) estão coerentes com o custo-meta estabelecido na fase de planejamento do projeto. Em seguida, é possível refazer o orçamento do projeto com um nível maior de precisão e refazer a análise de viabilidade econômica do projeto. Ela segue o padrão da atividade genérica apresentada no Tópico 3.3, no Capítulo 3.

6.9

Avaliar fase

Esta atividade segue o padrão da atividade genérica apresentada no Tópico 3.4, no Capítulo 3. O conjunto de especificações-meta gerado ao final desta fase pode ser avaliado utilizando-se os critérios mostrados na Tabela 6.2. Tabela 6.2

Critérios de avaliação do gate da Fase de Projeto Informacional Critérios

Abrangência As especificações-meta contemplam todos os aspectos relacionados ao produto durante o seu ciclo de vida? Concisão e ausência de redundâncias As especificações-meta possuem idéias e requisitos repetidos? Uniformidade de abstração As especificações-meta contêm apenas requisitos situados em um mesmo nível de abstração? Estruturação adequada A lista de especificações possui campos para todos os parâmetros que sejam de valia para elaboração de um bom projeto (metas, sensores, saídas indesejáveis etc.)? Clareza As especificações estão postas de forma clara, em linguagem compreensível a todos que se envolvam direta ou indiretamente com o projeto? Praticabilidade Os requisitos poderão ser observados e analisados de modo que sejam facilmente avaliados pela equipe de projeto? Econômicos O estudo de viabilidade econômica foi atualizado, analisado e aprovado?

6.10 Aprovar fase Esta atividade segue o padrão da atividade genérica apresentada no Tópico 3.5, no Capítulo 3. Os mesmos critérios verificados na auto-avaliação da atividade anterior são analisados pelo Time de Avaliação que, além disso, comparam o produto e o projeto com os demais do portfólio, para avaliar o seu sucesso (com relação aos outros projetos e produtos) e o retorno financeiro esperado.

CAPÍTULO 6

Projeto Informacional

233

6.11 Documentar as decisões tomadas e registrar lições aprendidas Esta atividade segue o padrão da atividade genérica apresentada no Tópico 3.6, no Capítulo 3. Ao longo deste capítulo foram descritas diversas práticas melhores. Ficaria repetitivo listá-las novamente neste tópico.

6.12 Questões e atividades didáticas propostas Questões para reflexão 1. Explique sobre a importância e abrangência da atividade de revisar/atualizar o Escopo do Produto. 2. Defina o conceito de ciclo de vida e sua importância para o processo de projeto de produtos. 3. Para um determinado produto existente, levante cinco produtos concorrentes e dez patentes relacionadas ao produto. 4. Por que as necessidades obtidas diretamente dos clientes devem ser “depuradas” para, então, ser utilizadas pelo Time de Desenvolvimento? 5. Quais são as diferenças entre “necessidades” e “requisitos dos clientes”? 6. Com base no Diagrama de Kano, explique por que se deve constantemente identificar/buscar requisitos que impactam/surpreendem os clientes. 7. Quais são as principais diferenças entre os chamados “custos de aquisição” e os “custos de utilização”? 8. Qual é a importância de utilizar parâmetros mensuráveis para descrever o desempenho esperado do produto? 9. Por que o QFD é entendido como uma ferramenta-chave para a implementação da engenharia simultânea? 10. Qual é a importância das Especificações-meta do produto para as demais fases do desenvolvimento?

Atividades didáticas 1. Escolha um projeto original para ser usado a partir de agora como exercício para os conteúdos dos capítulos da fase de desenvolvimento e pós-desenvolvimento. 2. Selecione um produto existente para ser reprojetado, segundo as abordagens propostas nos capítulos das fases de desenvolvimento e pós-desenvolvimento. 3. Para o produto definido no item 1, desenvolva o Escopo do Produto, o ciclo de vida associado e os requisitos dos clientes. 4. Para o produto definido no item 2 desenvolva um benchmarking competitivo de acordo com as premissas do QFD. 5. Para o produto definido nos Tópicos 6.1 e 6.2, desenvolva a matriz da Casa da Qualidade e elabore a lista de Especificações-meta dos produtos.

6.13 Informações adicionais AKAO, Y. (Ed.). Quality function deployment: integrating customer requirements into product design. Portland, Productivity Press, 1990. AMERICAN SUPPLIER INSTITUTE (ASI). Quality Function Deployment: implementation manual: 3-day workshop. Dearborn, ASI, 1993. BLANCHARD, B. S.; FABRYCKY, W. J. Systems engineering and analysis. New Jersey: Prentice- Hall, 1990. CHENG, L. C. et al. QFD — planejamento da qualidade. Minas Gerais: Editora Littera Maciel Ltda., 1995. p. 261.

234

PARTE 2

O Modelo

FERREIRA, C. V. Estimativa de custos de produtos na fase de projeto conceitual: uma metodologia para seleção da estrutura funcional e da alternativa de solução. 1997. Dissertação (Mestrado em Engenharia Mecânica), Universidade Federal de Santa Catarina, 1997. FONSECA, A. J. H. Sistematização do processo de obtenção das especificações de projeto de produtos industriais e sua implementação computacional. 2000. Tese Doutorado em Engenharia Mecânica), Universidade Federal de Santa Catarina, 2000. GOMES FERREIRA, M. G. Utilização de modelos para a representação de produtos no projeto conceitual. 1977. Dissertação (Mestrado em Engenharia Mecânica) —, Universidade Federal de Santa Catarina, 1977. HAUSER, J. R.; CLAUNSIG, D. The House of Quality. Harvard Busines Review, maio-jun., 1988. KING, B. Better designs in half the time: implementing quality function deployment in America. Methuen: GOAL/QPC, 1989. KOTTLER, P. Administração de marketing — análise, planejamento e controle. São Paulo: Atlas. 1988. OTTO, K.; WOOD, K. Product design — techniques in reverse engineering and new product development. New Jersey: Prentice-Hall, Inc., 2001. PUGH, S. Total design — integrated methods for successful product engineering. Massachusetts: Addison Wesley, 1990. ULLMAN, D. G. The mechanical design process. Third Edition. New York: McGraw-Hill, 2003.

7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.7 7.8 7.9 7.10 7.11 7.12 7.13 7.14 7.15 7.16

Sumário Atualizar o Plano do Projeto Conceitual Modelar funcionalmente o produto Desenvolver princípios de solução para as funções Desenvolver as alternativas de solução para o produto Definir arquitetura Analisar Sistemas, Subsistemas e Componentes (SSC) Definir ergonomia e estética do produto Definir fornecedores e parcerias de co-desenvolvimento Selecionar a concepção do produto Definir plano macro de processo Atualizar estudo de viabilidade econômico-financeira Avaliar fase Aprovar fase Documentar as decisões tomadas e registrar lições aprendidas Questões e atividades didáticas propostas Informações adicionais

7. Projeto Conceitual Projeto Conceitual PARTE 2 O Modelo

Depois da leitura deste capítulo, você será capaz de: l

l

l

l

l

l

l

l

l

l

Entender como ocorre a geração e seleção da concepção do produto a partir das especificações-meta do produto resultante da fase de projeto informacional. Entender como a modelagem funcional do produto é importante para a obtenção de alternativas de solução para o produto, inicialmente pela definição da função total do produto a partir das especificações-meta do produto e seguindo com a decomposição dessa função em funções de menor nível de complexidade. Entender os conceitos de estrutura de funções e árvore de funções. Entender como representar os princípios de solução para as funções de menor complexidade, por meio de efeitos físicos e portadores de efeito. Entender os diferentes métodos de criatividade e como esses podem ser usados para a obtenção de princípios de solução, em especial o brainstorming, a matriz morfológica e a TRIZ. Entender como a TRIZ pode ser usada em conjunto com o QFD, estrutura de funções e matriz morfológica. Entender como obter alternativas de solução para o produto a partir da matriz morfológica. Definir o conceito de arquitetura, sua utilização para a representação das alternativas para o produto. Entender coma a arquitetura modular pode ser utilizada, e suas diferentes aplicações. Entender como pode ser iniciado o detalhamento das concepções desenvolvidas por meio da escolha dos materiais, processos de fabricação e montagem dos SSC, dentro dos conceitos de engenharia simultânea.

236

l

l

l

PARTE 2

O Modelo

Entender a importância da interação entre o produto e as pessoas por meio das considerações de ergonomia e estética. Mostrar como se pode escolher as parcerias e fornecedores na fase de projeto conceitual. Definir um procedimento sistemático para a seleção da concepção mais adequada para o produto e que deverá ser considerada na fase de projeto detalhado.

7.1

Sumário

Diferentemente da fase de Projeto Informacional que trata, basicamente, da aquisição e transformação de informações, na fase de Projeto Conceitual, as atividades da equipe de projeto relacionam-se com a busca, criação, representação e seleção de soluções para o problema de projeto. A busca por soluções já existentes pode ser feita pela observação de produtos concorrentes ou similares descritos em livros, artigos, catálogos e bases de dados de patentes, ou até mesmo por benchmarking. O processo de criação de soluções é livre de restrições, porém direcionado pelas necessidades, requisitos e especificações de projeto do produto, e auxiliado por métodos de criatividade. A representação das soluções pode ser feita por meio de esquemas, croquis e desenhos que podem ser manuais ou computacionais, e é muitas vezes realizada em conjunto com a criação. A seleção de soluções é feita com base em métodos apropriados que se apóiam nas necessidades ou requisitos previamente definidos. Essa fase, conforme mostra a Figura 7.1, do mesmo modo que na fase anterior, inicia-se pela atualização do Plano do Projeto Conceitual, de maneira a manter uma compatibilidade com o planejamento geral feito na fase de Planejamento do Projeto. Figura 7.1

Informações principais e dependências entre as atividades da fase de Projeto Conceitual.

No início da fase de Projeto Conceitual, o produto é modelado funcionalmente e descrito de uma forma abstrata, independentemente de princípios físicos. Com isso, evita-se que experiências ou preconceitos formem

CAPÍTULO 7

Projeto Conceitual

237

uma barreira contra novas soluções, ou, em outras palavras, que o foco seja mantido na essência do problema e não na solução imediata. Essa abstração é feita definindo-se o produto em termos de suas funções. Para isso, inicialmente define-se a função global do produto que, em seguida, é desdobrada em várias estruturas de funções do produto até que uma seja selecionada. Depois de definida a estrutura de funções do produto, vários princípios de solução são propostos para satisfazer cada uma das funções. Assim, combinando os vários princípios, é possível criar várias alternativas de solução — dentre as quais uma ou mais possam ser selecionadas. Para cada uma dessas alternativas geradas, define-se uma arquitetura que contém a estrutura do produto em termos dos componentes e suas conexões. Tais arquiteturas são mais bem desenvolvidas dando origem às concepções, que já agregam informações de estilo e dos possíveis fornecedores. Essas concepções são, então, alvo de um processo de seleção, que vai apontar aquela concepção que melhor atende às especificações-meta e a outros critérios de escolha. A concepção obtida é uma descrição aproximada das tecnologias, princípios de funcionamento e formas de um produto, geralmente expressa por meio de um esquema ou modelo tridimensional, que, freqüentemente, pode ser acompanhado por uma explicação textual. É uma descrição concisa de como o produto satisfará as necessidades dos clientes Finalmente ocorrem as atividades finais genéricas da fase, envolvendo o monitoramento da viabilidade econômica, o gate da fase e o registro das decisões tomadas e lições aprendidas. A aprovação da fase implica verificação se o conceito escolhido atende às especificações-meta por meio de soluções técnicas adequadas e de custos aceitáveis.

7.2

Atualizar o Plano do Projeto Conceitual

Esta atividade tem por objetivo compatibilizar o planejamento dessa fase com o planejamento efetuado na macrofase de pré-desenvolvimento. Basicamente deverão ser seguidas as mesmas orientações descritas no Capítulo 3, Tópico 3.2.

7.3

Modelar funcionalmente o produto

A modelagem funcional auxilia o Time de Projeto a descrever os produtos em um nível abstrato, possibilitando a obtenção da estrutura de produto sem restringir o espaço de pesquisa a soluções específicas. Os modelos funcionais permitem que o produto seja representado por meio das suas funcionalidades, ou seja, por meio das suas funções — tanto aquelas realizadas externamente ao produto em sua interação com o ambiente quanto as funções internas ao produto, realizadas pelas suas partes. Tratar o problema de forma generalizada com a sua formulação em um plano abstrato é uma forma de abrir caminho para a obtenção de soluções melhores. Ignorar o particular e deter-se no que é geral e essencial previne que as experiências, preconceitos e convenções limitem a solução do problema de projeto. Essa generalização propicia uma formulação ampla e aberta, juntamente com o entendimento claro das restrições essenciais sem a consideração prévia de uma solução. A abstração também pode ser empregada na identificação de restrições fictícias, que poderiam limitar o emprego de novas tecnologias, materiais, processos de fabricação e mesmo novas descobertas científicas. O resultado desse estudo pode quebrar preconceitos e conduzir a uma melhor solução do problema, proporcionando um entendimento mais claro da tarefa de projeto, e a identificação das funções do produto, o que é indispensável para o êxito nas etapas subseqüentes do Projeto Conceitual. De uma maneira geral, funções descrevem as capacidades desejadas ou necessárias que tornarão um pro1 duto capaz de desempenhar seus objetivos e especificações. 1

Segundo Otto e Wood, 2001, as vantagens do modelamento funcional são: concentração sobre “o quê” tem que ser realizado por um novo conceito ou reprojeto, e não “como” vai ser realizado; auxilia a organização da equipe de projeto, tarefas e processo; as funções podem ser obtidas ou geradas diretamente das necessidades dos clientes, definindo os contornos da solução final de projeto; a criatividade é favorecida pela possibilidade de decomposição de problemas e manipulação de soluções parciais; pelo mapeamento das necessidades dos clientes — primeiro para funções e depois para forma —; e mais soluções podem ser sistematicamente geradas para a resolução do problema de projeto.

238

PARTE 2

O Modelo

As funções de um produto podem ser classificadas como mostra a Figura 7.2. As funções interativas são compatíveis com o conceito de função uma vez que “uma função é o que um elemento de um produto ativa ou passivamente faz para a realização de certo propósito”. As funções comunicativas estão relacionadas com a transmissão de sinais/informações do produto para o consumidor. Figura 7.2

Funções dos produtos (adaptado de Warell, 2001).

As funções técnicas podem ser representadas pela relação existente entre a entrada e a saída de um sistema, ou seja, a transformação de um estado de um sistema para outro, independentemente de qualquer forma. Por estado de um sistema compreende-se a totalidade dos valores de suas propriedades em um dado instante. Funções são geralmente definidas por meio de um predicado composto por um verbo e um substantivo, tal como dosar fertilizante, lavar roupa ou cortar grama. No modelamento funcional, a partir de uma análise das especificações-meta do produto e das funções inicialmente identificadas, o primeiro passo normalmente dado na busca de uma estrutura de funções para o produto projetado é a elaboração de uma descrição da função total, ou global, desse produto. Todos os produtos possuem uma função mais importante, que, de forma condensada, deve ser um resumo do que se deve esperar do produto, funcionalmente (Gomes Ferreira, 1997). A Figura 7.3 ilustra as principais tarefas desta atividade. Figura 7.3

Tarefas da atividade “Modelar funcionalmente o produto”.

CAPÍTULO 7

Projeto Conceitual

Quadro 7.1

239

Termos Utilizados no Projeto Conceitual

A relação dos termos principais deste capítulo e suas definições encontram-se na Figura 7.4. Os elementos desfocados nesta figura representam os termos definidos no Quadro 6.2, no Capítulo 6. Figura 7.4

Relação entre os principais termos usados na fase de Projeto Conceitual.

As definições estão a seguir: Termo

Definição

Especificações-meta

Conjunto de objetivos ou metas que o produto deve atender. Esse conjunto de informações, elaborado durante o Projeto Informacional do produto, deve refletir as características que o produto deverá ter para atender às necessidades dos clientes.

Estrutura funcional do produto

Representa de forma hierárquica e estruturada a lista de funções que o produto deve possuir.

Princípios de solução individuais

Propostas construtivas e formais de soluções que realizam as funções do produto.

Princípios de solução totais

Conjunto coerente e integrado dos princípios de solução individuais.

Alternativas de solução

Conjunto de princípios de solução totais.

Arquitetura do produto

Esquema pelo qual os elementos funcionais do produto (funções) são arranjados em partes físicas e como essas partes interagem. A relação entre os elementos funcionais e as partes físicas pode ser de um-para-um, um-para-vários e vários-para-um. Pode ter uma forma gráfica (layout do produto) e uma estruturada (BOM inicial).

Desenhos iniciais

Representação gráfica de todos os itens de um produto.

Lista dos SSCs (principais)

São os elementos constituintes do produto (sistemas, subsistemas e componentes), organizados em forma de lista.

BOM inicial (Estrutura do Produto)

Primeira versão da identificação dos itens e dos relacionamentos entre eles, assim como conexão com todos os documentos relacionados.

Modelo do produto

Esquema que representa os elementos principais do produto e suas interfaces. Pode ser um layout gráfico, um desenho, um modelo geométrico etc. (depende da ferramenta utilizada na fase de Projeto Conceitual).

(continua)

240

PARTE 2

O Modelo

Quadro 7.1

Termos Utilizados no Projeto Conceitual (continuação)

Termo

Definição

Concepção do produto

É uma descrição aproximada das tecnologias, princípios de funcionamento e formas de um produto, geralmente expressa por meio de um esquema ou modelo tridimensional, que, freqüentemente, pode ser acompanhado por uma explicação textual. É uma descrição concisa de como o produto satisfará as necessidades dos clientes. Pode conter a estrutura inicial do produto, mostrando a relação entre os SSCs principais. É o resultado do Projeto Conceitual.

Requisitos dos SCCs

Requisitos desdobrados a partir dos requisitos dos produtos.

Especificações iniciais dos SCCs

Atributos dos itens que o caracterizam na fase de Projeto Conceitual, nos SS eles podem ser os parâmetros críticos e nos componentes, as especificações críticas. Podem estar representados no desenho.

Plano macro de processo (inicial)

Seqüência inicial dos processos de fabricação que são necessários para se produzir um item.

Para a modelagem funcional, é possível utilizar as chamadas estruturas de funções ou, então, árvores de funções. Nas estruturas de funções, tem-se uma descrição que relaciona o sistema técModelagem funcional com nico e a física do problema por meio de fluxos básicos de energia, materiais e sinais. estruturas de funções De início, define-se a função total, a qual é em geral representada graficamente por uma transformação que ocorre em uma “caixa preta” com entradas e saídas definidas. Essas entradas e saídas são os estados do sistema. Para o caso das funções técnicas, a transformação das entradas nas saídas é descrita por energia, material e sinal que fluem (entram e saem) nos contornos do sistema. A Figura 7.5 mostra uma representação da função total. Figura 7.5

Representação esquemática da função total.

A função total é geralmente obtida pela análise dos requisitos funcionais contidos na lista de especificações-meta do produto. A seguir, apresenta-se um roteiro para a elaboração da função total a partir das especificações-meta do produto (Gomes Ferreira, 1997): 1. Localizar, dentre as especificações-meta, aquelas que dizem respeito às funções do produto. 2. Detectar, nessas especificações funcionais, as principais entradas e saídas do sistema em termos de fluxos de energia, material e sinal. 3. Estabelecer os estados das principais entradas e saídas listadas no item anterior. 4. Detectar, dentre os fluxos listados, quais os fluxos principais de entrada e de saída do sistema. 5. Do relacionamento entre os fluxos principais de entrada e de saída do sistema (e de seus estados), tentar expressar a função total em termos de um par verbo + substantivo. 6. Representar os dados levantados nos itens anteriores na forma de um diagrama de blocos, tal como apresentado na Figura 7.6.

CAPÍTULO 7

Projeto Conceitual

241

A elaboração da função total do produto ajuda a equipe de desenvolvimento a sintetizar o que realmente se espera do produto projetado. Também pode servir de ponto de partida para o processo de elaboração de uma estrutura funcional para o produto. Vale destacar que o fluxo mostrado na Figura 7.5 inclui as entradas e saídas de energia, material e sinal em razão da interação do produto com o meio ambiente, com o usuário e com outros sistemas técnicos. Também, a quantidade e a qualidade dessas entradas e saídas devem ser definidas. Sinal pode ser considerado como a forma física na qual a informação é transportada. Os sinais podem ser preparados, recebidos, comparados, combinados, transmitidos, mostrados ou gravados. Material possui propriedades de forma, massa, cor, condições etc. Materiais podem ser misturados, separados, mudados quimicamente. A energia é a responsável pelo transporte ou transformação de matéria e sinal; normalmente é considerada em suas formas manifestas, tais como: elétrica, cinética, magnética, calor e óptica. Para que algo ocorra, deve existir um fluxo de energia entrando e saindo no sistema. Ainda, a energia deve ser conservada, ou seja, a energia que entra em um sistema deve sair ou ser armazenada. Uma estrutura de funções é normalmente obtida pela decomposição da função total em funções de menor complexidade. A estrutura de funções obtida é recursivamente decomposta até se obter uma estrutura com funções no nível de complexidade requerida, conforme ilustrado na Figura 7.6. Figura 7.6

Desdobramento da função total em funções mais simples.

Na Figura 7.7, tem-se a função total de um produto destinado a lavar roupas. Como entradas do sistema, nós temos roupas sujas (Material), sabão (Material), água limpa (Material) e energia (Energia) — não necessariamente elétrica — e o grau de lavagem requerido (Sinal). Como saídas do sistema, temos roupas limpas (Material), água suja (Material) e energia (Energia). A saída “energia” representa a parcela de energia que sai do sistema sob formas indesejáveis, tais como: calor, vibrações e ruídos. Mesmo com essas saídas sendo indesejáveis, dificilmente obteremos os produtos finais sem elas. Podemos observar que, a rigor, a transformação de “roupas sujas” em “roupas limpas” poderia ser representada pela função total “separar sujeira das roupas”. Entretanto, o conceito do produto e as especificações-meta definiram certos aspectos tecnológicos do produto, como a utilização de água e sabão para a separação entre sujeira e roupa.

242

PARTE 2

Figura 7.7

O Modelo

Função total “lavar roupas”.

Achar uma solução diretamente para a função total é em geral difícil de ser obtida, razão pela qual se procede a uma decomposição da função total em funções com nível de complexidade menor. Assim a modelagem funcional evolui para um modelo de estrutura de funções de baixa complexidade interligadas por fluxos de energia, material e sinal. Vale lembrar que complexidade de uma função é uma característica bastante relativa e dependente do contexto no qual está inserida. A decomposição de uma função total, além de facilitar a busca por soluções, proporciona um melhor entendimento do problema de projeto. A decomposição de funções, no entanto, não é um trabalho simples que possa ser feito em uma única vez, necessitando de um grande esforço do time de projeto. A função total é o principal ponto de partida para elaboração da estrutura de funções. A estrutura de funções deve refletir a função total do produto. As fronteiras da estrutura de funções podem ser obtidas a partir do contorno da função total, com as suas entradas e saídas, conforme mostrado na Figura 7.8 para o caso do projeto de um dispositivo destinado a lavar roupas. Figura 7.8

Contorno de uma estrutura de funções.

É conveniente que se comece a esboçar a estrutura de funções pelo desdobramento de um dos processos existentes, que seja necessário à conversão do fluxo principal do sistema (entradas e saídas principais). A Figura 7.9 ilustra o desdobramento do processo utilizado para transformar “roupas sujas” na saída “roupas limpas”. Figura 7.9

Primeiro desdobramento da função total “lavar roupas”.

Paulatinamente, a estrutura de funções vai se desenvolvendo pela agregação de fluxos e funções auxiliares ao fluxo principal e pelo desdobramento das funções existentes em funções de mais baixo nível de complexidade.

CAPÍTULO 7

Projeto Conceitual

243

No modelo da Figura 7.10, agregaram-se os demais fluxos que cruzam a fronteira do sistema e também as funções auxiliares “misturar água e sabão”, “produzir movimento” e “alternar movimento”. Figura 7.10

Estrutura de funções para “lavar roupas”.

As estruturas de funções devem conter todos os fluxos de energia, material e sinal envolvidos. Deve-se garantir a compatibilidade entre funções adjacentes: as entradas para cada função devem corresponder às saídas para a função anterior. A estrutura de funções deve ser mantida tão simples quanto possível, de modo a levar a soluções simples e econômicas. Vale destacar que a decomposição da função global permite que sejam propostas diferentes estruturas funcionais que satisfaçam a função global. Essas estruturas funcionais alternativas podem ser obtidas por: (a) divisão ou combinação de funções; (b) mudança de disposição de funções individuais; (c) mudança do tipo de ligação (série ou paralelo); e (d) alteração das fronteiras do sistema. Para a seleção da melhor alternativa dentre as estruturas funcionais geradas, pode-se utilizar uma matriz de decisão. A dificuldade principal é estabelecer os critérios de escolha para um modelo do produto ainda muito abstrato. A lista de especificações-meta do produto ainda é o principal critério; no entanto, vale lembrar que é raro que as estruturas de função sejam completamente livres de pressuposições físicas e formais, o que permite que se possa imaginar os princípios de solução para possibilitar o confronto entre as diferentes estruturas funcionais. Nessa abordagem, a função principal do produto é decomposta hierarquicaModelagem funcional com mente em subfunções, sendo que, quando todas elas são executadas, a função total árvores de funções do produto é realizada. De um modo geral, busca-se que cada subfunção seja realizada por um diferente subsistema ou componente. Árvores de função podem ser montadas de maneira simples e rápida; entretanto, não fornecem uma representação das interações entre as funções decompostas. Existem diferentes métodos para a obtenção de árvores de função. No Quadro 7.2, a seguir, será apresentado o método FAST. Quadro 7.2

Método FAST

Esse método é usado para definir, analisar, entender as funções do produto e como elas se relacionam. A árvore de funções produzida pelo FAST possui uma orientação horizontal descrita pelas dimensões “como” e “por que”, conforme mostrado na Figura 7.11. Essa dimensão possibilita que as questões COMO e POR QUE organizem de maneira lógica as funções do sistema. Iniciando com a função global, pergunta-se COMO é que a função poderá ser obtida, buscando-se uma visão mais específica. Essa linha de questionamento e pensamento é lida da esquerda para a direita. Para

(continua)

244

PARTE 2

Quadro 7.2

O Modelo

Método FAST (continuação)

abstrair o problema para um nível mais elevado, pergunta-se POR QUE a função é realizada. Essa linha de lógica é lida da direita para a esquerda. Figura 7.11

Diagrama do Método FAST.

A função global do produto é colocada na parte superior esquerda do diagrama, e a função colocada imediatamente à direita da função global representa o propósito ou missão do produto ou processo, sendo chamada de função básica. As subfunções resultantes dos questionamentos COMO são colocadas à direita da função básica. Tipicamente, a realização de cada função secundária introduz outros efeitos indesejáveis que tornam necessárias novas funções para aliviar tais efeitos. Essas funções são colocadas na direção vertical. Existem, ainda, as funções que o produto pode possuir e que não aparecem no processo de decomposição, as quais são colocadas na parte superior do diagrama.

7.4

Desenvolver princípios de solução para as funções

Nessa atividade, inicia-se a passagem do abstrato ao concreto, da função à forma. A cada uma das funções da estrutura funcional escolhida na etapa anterior podem ser atribuídos um ou mais princípios de solução (veja a Figura 7.12). Para que isso seja possível, é necessário, a partir do correto entendimento da função, a busca de um efeito físico e de um portador de efeito físico que, por meio de determinados comportamentos, realizem o objetivo da função em questão.

CAPÍTULO 7

Projeto Conceitual

Figura 7.12

245

Tarefas da atividade “Desenvolver princípios de solução para as funções”.

A Figura 7.13 ilustra o relacionamento entre os termos efeito físico, portador do efeito e princípio de solução. Figura 7.13

Constituição de um princípio de solução (Gomes Ferreira, 1997).

Os sistemas físicos na natureza comportam-se de acordo com princípios fíEfeitos físicos sicos, químicos e biológicos, regidos por leis da natureza. Assim, esses sistemas desenvolvem efeitos físicos, químicos e biológicos capazes de realizar funções sobre o ambiente que os cercam. É natural que os projetistas, quando envolvidos na busca por princípios de solução, pensem primeiro em termos de efeitos físicos, químicos e biológicos que possam realizar a função requerida. Aqui, o termo efeitos físicos estará abrangendo também os efeitos químicos e biológicos que poderão ser desenvolvidos em sistemas técnicos. Algumas vezes, mais de um efeito físico é necessário para cumprir uma determinada função, como no caso de um par bimetálico. A função “ampliar força” é um exemplo de função que pode ser realizada por diferentes efeitos físicos, tais como: o efeito da alavanca, o efeito da cunha, efeitos hidráulicos e efeitos eletromagnéticos. Somente a descrição dos efeitos físicos envolvidos não é suficiente para uma rePortadores de efeito presentação adequada dos princípios de solução para as funções do produto; é necessário que se busquem sistemas físicos capazes de portar os efeitos físicos necessários à realização das funções pertencentes à estrutura funcional desenvolvida para o produto.

246

PARTE 2

O Modelo

Segundo Gomes Ferreira (1997), um portador de efeito é, dessa forma, um sistema físico, com seus elementos e suas relações entre elementos, definido qualitativamente, capaz de realizar o efeito físico esperado. Ao se definir um portador para um efeito físico em questão, define-se o princípio de solução a ser utilizado. O portador do efeito deve representar qualitativamente o sistema ou o meio que desempenhará a função desejada. Ele deve conter informações a respeito dos elementos que compõem o sistema, bem como das relações entre esses elementos. A Figura 7.14 ilustra os portadores de efeito relacionados ao efeito físico da alavanca utilizado para a realização da função “ampliar força”. Figura 7.14

Portadores para o efeito físico da alavanca (Gomes Ferreira, 1997).

As informações relacionadas aos elementos que constituem o princípio de solução incluem: tipo do elemento, quantidade, forma, posição, movimentos e atributos de material. O princípio de solução deve representar as formas aproximadas dos elementos, porém não deve fazer referência às suas dimensões, salvo no caso daquelas necessárias ao entendimento da função ou do comportamento do princípio de solução. Uma forma adequada de representar os princípios de solução no domínio da mecânica é por meio de “diagramas de linhas” ou “diagramas de esqueleto”, tal como utilizado por Hubka (1988) na Figura 7.15, para representação de dois princípios de solução para uma morsa. Nessa forma de representação, os elementos que compõem os princípios de solução são representados por intermédio de desenhos esquemáticos contendo tão-somente linhas. Também as informações — referentes aos movimentos necessários aos elementos do princípio de solução para o cumprimento de sua função — podem ser representadas por intermédio de símbolos apropriados. Nos princípios de solução, não se deve referenciar os materiais específicos a serem utilizados. Apenas atributos referentes às propriedades desses materiais devem ser especificados. Por exemplo: ductilidade, rigidez, fragilidade, transparência, condutibilidade elétrica, ponto de fusão e propriedades ferromagnéticas são atributos de material que podem estar contidos em uma representação de princípio de solução.

CAPÍTULO 7

Projeto Conceitual

Figura 7.15

247

Princípios de solução para uma morsa (Gomes Ferreira, 1997).

Os princípios de solução poderão ser obtidos por meio de bancos de dados de princípios ou de catálogos. Ainda, para auxiliar na busca de idéias para os princípios de solução que atendam às funções, é possível utilizar os chamados métodos de criatividade. A literatura aponta mais de uma centena dos chamados métodos de criatividade; entretanto, ao analisarmos os princípios básicos dos quais se derivam esses métodos, a aparente grande diversidade desaparece, podendo-se chegar a um número relativamente pequeno de métodos. Tais métodos podem ser classificados em intuitivos, sistemáticos e orientados, conforme mostrado na Tabela 7.1 (Sozo, 2001). Tabela 7.1

Classificação dos Métodos de Criatividade

Métodos Intuitivos

Métodos Sistemáticos

Métodos Orientados

Brainstorming

Método Morfológico

TRIZ

Método 635

Análise e Síntese Funcional

SIT

Lateral Thinking

Analogia Sistemática

Synetics ou Sinergia

Análise do Valor

Galeria

Questionários e Cheklists

São baseados principalmente nos estudos psicológicos da criatividade e em tentativa e erro para a busca de soluções criativas. Mesmo indicados para problemas simples, eles podem ser utilizados para solucionar determinadas etapas de problemas complexos.

Métodos Intuitivos

Brainstorming É um excelente caminho para o desenvolvimento de muitas soluções criativas para um problema. Trabalha focalizando o problema para, então, sugerir muitas soluções radicais. Idéias deverão ser apresentadas na maior quantidade e extravagância possível e desenvolvidas o mais rápido possível. Permite quebrar os padrões de pensamento existentes e olhar as coisas de uma nova maneira. Durante as sessões de brainstorming, as idéias que vão surgindo não devem ser criticadas. Deve-se sempre procurar abrir novas possibilidades e separar suposições erradas sobre os limites do problema. Análises e julgamentos nesse momento retardarão a geração de idéias. As idéias deverão ser avaliadas somente após a sessão ser encerrada, quando, então, as soluções poderão ser exploradas usando abordagens convencionais. O método é apropriado para grupos constituídos em torno de seis pessoas, preferencialmente de diferentes áreas ou formações. Deve haver um moderador para a sessão. Partindo-se de uma definição, o grupo busca gerar uma grande quantidade de idéias, muitas das quais serão posteriormente descartadas. Não são permitidas críticas, e a situação apresentada não deve conter restrições — sendo que idéias extravagantes e opiniões surpreen-

248

PARTE 2

O Modelo

dentes são encorajadas. Caracteriza-se principalmente por permitir uma visualização do problema de diferentes maneiras, prima pela quantidade e não pela qualidade das idéias; não é recomendado para problemas especializados, sendo indicado para problemas simples. Veja o Quadro 7.3. Quadro 7.3

Brainstorming

Brainstorming é uma técnica já bastante conhecida e relativamente simples, que, quando utilizada de maneira adequada, possibilita a obtenção de valiosas soluções. Para o desenvolvimento de uma sessão bem-sucedida de brainstorming, algumas diretrizes devem ser observadas: 1. O problema deve ser definido clara e concisamente; o problema não deve ser complexo ou multifacetado. Deve-se assegurar que todos os participantes tenham entendido e se familiarizado com o problema e estejam de acordo com o modo que foi formulado. Não é necessário colocar um grande número de restrições nesse momento. 2. O grupo deverá ser formado por três a dez pessoas. Devem ser convidadas pessoas com diferentes graus de experiência e nível de especialidade. Um número pequeno de participantes não permite uma interação suficiente entre as pessoas, de tal modo que as idéias possam ser “alimentadas” de uma para outra. (Aqui, as idéias são consideradas vivas, como vírus que podem ser transmitidos de pessoa a pessoa por contato verbal ou visual.) Um grupo grande é também indesejado, pois, geralmente, algumas pessoas acabam não participando das discussões, tornando-se negativas ou apáticas — o que é fatal para uma sessão de brainstorming. Deve-se encorajar a participação com entusiasmo de todos. 3. É preciso fixar um limite de tempo para a sessão, que deve ficar entre 30 e 40 minutos. Grupos grandes poderão necessitar de mais tempo para que todos possam efetuar suas contribuições. 4. Criticas e avaliações negativas não deverão ocorrer durante a sessão, uma vez que o objetivo é obter novas idéias e não avaliá-las. Procurar o máximo possível de soluções, quantidade acima da qualidade, soluções podem ser combinadas, uma pode gerar outra e em outro estágio. Deve-se pensar de forma extravagante para surgirem várias idéias, não deve haver propriedade dessas, sendo as idéias um resultado do grupo de trabalho. As críticas, julgamentos e avaliações irão bloquear o fluxo de idéias criativas, pois os participantes tenderão a ficar na defensiva, autoprotegendo-se, receando apresentar verdadeiramente novas e diferentes idéias, com medo de serem ridicularizados. 5. Deve ser definida uma pessoa do grupo para anotar as idéias geradas na sessão. As idéias geradas serão estudadas e avaliadas após a sessão.

Método 635 Este método, também conhecido como brainwriting, é semelhante ao brainstorming. Porém, como apenas algumas idéias iniciais são desenvolvidas intensamente, os resultados obtidos tendem a ser melhores. O grupo consiste de seis integrantes, e cada um escreve três sugestões iniciais para um determinado problema. A seguir, cada integrante passa essas soluções adiante, para que cada um dos outros cinco membros, após uma rápida observação, acrescente outras três sugestões ou melhoramentos para as inicialmente colocadas. É essa seqüência de números que dá nome ao método.

Lateral Thinking Neste método são geradas provocações — idéias, lógicas ou não — lançadas com o objetivo de obter outras idéias. Objetiva-se sair de um padrão de pensamento para outro. As técnicas de provocação retiram as pessoas de sua zona de conforto, pois é fora dela que o real crescimento criativo ocorre. Este método auxilia a vencer a inércia psicológica tendo forte tendência a gerar idéias inovadoras em razão de técnicas de provocação.

Synetics ou Sinergia Utiliza diferentes elementos da criatividade (incubação, pensamento divergente, tentativa e erro, analogias) de modo sinérgico. É um método para aplicação em grupo multidisciplinar de quatro a sete pessoas.

CAPÍTULO 7

Projeto Conceitual

249

Galeria Este método combina o trabalho individual e o trabalho em equipe, o chamado grupo móvel. É similar ao brainstorming, porém cada elemento do grupo é incentivado a propor individualmente soluções para o problema, por meio de desenhos e textos que são fixados em paredes. As idéias são, então, analisadas em grupos. É adequado para problemas em que todos os componentes foram projetados e deve-se determinar como montar/agrupar os componentes em um produto completo. São estruturados em passos, de modo a aumentar a probabilidade de se chegar Métodos Sistemáticos a soluções mais adequadas. Essa categoria de métodos é mais adequada à solução de problemas complexos, pois, em geral, busca a subdivisão de um problema complexo em problemas mais simples

Método Morfológico Consiste no desdobramento de um problema complexo em partes mais simples, buscando soluções para as partes. Inicialmente, o problema é definido e, a seguir, é dividido em parâmetros. O método de análise e síntese funcional pode ser utilizado para o desdobramento do problema. Depois, buscam-se formas alternativas para solucionar os parâmetros, por meio de catálogos, experiência, pesquisa ou criação. Em seguida, obtêm-se as combinações possíveis dos parâmetros. Ao final, a melhor combinação de parâmetros é adotada como solução. Produz grande variedade de concepções. A busca de soluções é feita de forma independente, sem a preocupação com os demais parâmetros, sendo indicado para problemas complexos. Quadro 7.4

Matriz Morfológica

A matriz morfológica constitui-se de uma abordagem estruturada para a geração de alternativas de solução para o problema de projeto, aumentando a área de pesquisa de soluções para um determinado problema de projeto. Auxilia a equipe de desenvolvimento a encontrar um conjunto grande de alternativas de solução para o produto por meio de uma análise sistemática da configuração/forma que o produto terá. Os parâmetros descrevem as características ou funções que o produto ou processo deverá ter ou atender. Uma matriz morfológica possibilita a captura e a visualização das funcionalidades necessárias para o produto e explora meios alternativos e combinações para atender às funcionalidades. Para cada função do produto existe um número de possíveis soluções. A matriz permite que as soluções sejam consideradas e fornece uma estrutura para a obtenção de soluções alternativas. Isso possibilita a definição inicial do que será a arquitetura do produto por meio da geração e consideração de diferentes combinações de “princípios de solução”. Usada apropriadamente, a matriz morfológica pode auxiliar na obtenção de potenciais soluções para o produto. A seguir será apresentado o procedimento básico para a montagem da matriz morfológica. 1. Listar as funções do produto. Deve-se listar as funções que são essenciais para o produto. Essa lista não deverá ser muito longa, e possuir um nível apropriado de generalização — o ideal é que não sejam mais do que dez funções. As funções poderão ser listadas de acordo com uma determinada ordem, segundo a importância, posição na estrutura, fluxo de energia, fluxo de informação. Cuidados deverão ser tomados para listar funções e não componentes. Cada função deverá ser mutuamente exclusiva. 2. Listar os possíveis meios (princípios de solução) para cada função. Deve-se listar as possíveis soluções ou meios que atenda cada função. Buscar novas idéias, tanto quanto soluções e componentes já conhecidos, sendo que essas idéias ou componentes podem ser representados visualmente ou por palavras. Tentar manter o mesmo nível de generalidade para todas as soluções. 3. Representar as funções e os princípios de solução e explorar as combinações. Esboçar a matriz contendo todos os possíveis princípios de solução, representando o “espaço de solução” total para o produto e combinar os princípios de solução (veja a Figura 7.16). Tentar sempre que possível representar todas as opções visualmente. Assim, será mais fácil identificar combinações viáveis. Como o número total de combinações pode ser grande, é necessário que se limite às opções mais viáveis ou atrativas.

(continua)

250

PARTE 2

Quadro 7.4

Figura 7.16

O Modelo

Matriz Morfológica (continuação)

Matriz morfológica e a combinação de princípios de solução.

Analogia Sistemática Este processo consiste na comparação e transferência de características originárias de dois domínios distintos em níveis compatíveis de abstração. A partir da definição do problema, abstraem-se as características mais relevantes e procura-se, então, transferir características do problema para possíveis áreas de analogia. Comparam-se características do problema com características da área de analogia. Tal comparação pode ser feita, por exemplo, ao nível de funções, estrutura, forma ou comportamento. Finalmente, fazem-se a transferência e o ajuste das características consideradas mais úteis ao problema.

Análise do Valor Tem por objetivo melhorar o produto ou sistema em análise. O critério para julgar o melhoramento é o custo, mas o valor ou qualidade do produto não deve ser reduzido. O método inicia com a escolha do produto a ser analisado e a formação de uma equipe. Depois, são coletadas as informações gerais da situação do produto e os custos envolvidos. Identifica-se a função de cada parte do produto e o seu valor. Concluídas essas tarefas, buscam-se idéias ou soluções que venham a reduzir os custos, por meio de questionamentos. Realizam-se, então, o julgamento das idéias e o planejamento para realizar as alterações. Este método é indicado para produtos já existentes, geralmente propicia a redução de componentes do sistema e é indicado para problemas complexos.

Questionários e Checklists Podem ser utilizados individualmente ou em grupo. Neste método, o projetista (ou a equipe) é forçado a responder a uma grande quantidade de questões. O objetivo das questões é estimular a geração de idéias. Pode

CAPÍTULO 7

Projeto Conceitual

251

ser aplicado em problemas simples e complexos, apresenta forte tendência a idéias inovadoras em razão da necessidade de responder aos questionamentos. São baseados em padrões reconhecidos no processo de solução de problemas de várias áreas e procuram utilizá-los para resolver outros problemas.

Métodos Orientados

Teoria da Solução de Problemas Inventivos (TIPS ou TRIZ) Esta teoria foi desenvolvida por Genrich S. Altshuller, nascido na antiga União Soviética, em 1926. Para construí-la, Altshuller, e outros, pesquisaram em mais de um milhão de patentes procurando levantar os problemas inventivos e como eles foram solucionados. Os resultados mostraram que a maior parte das patentes levantadas (mais de 1.500.000) continha pouca inovação, apresentando apenas alguma melhoria no produto existente. O autor constatou que era necessário desenvolver um método que realmente pudesse auxiliar na geração de soluções realmente inventivas. Segundo o autor, a teoria da invenção deveria satisfazer as seguintes condições: 1. 2. 3. 4. 5. 6.

ser sistemática, apresentando os procedimentos passo a passo; ser um guia, sem restringir o espaço de busca da solução ideal; apresentar repetibilidade, confiabilidade e não depender de ferramentas psicológicas; permitir o acesso ao corpo de conhecimento inventivo; permitir adicionar ao corpo conhecimento inventivo; e ser bastante familiar para os inventores.

Altshuller definiu um problema inventivo como sendo um problema no qual a sua solução faz gerar um outro problema. Por exemplo, o aumento da resistência de um prato de metal causa um aumento do seu peso. Normalmente, no processo de invenção, os pesquisadores são levados a fazer um trade-off e assumir compromissos entre as características do problema, e acabam não alcançando a solução ideal do problema. Estudando as patentes, Altshuller observou que, em algumas delas, foi eliminada ou solucionada a contradição do problema, sem recorrer a uma solução de compromisso (trade-off de requisitos). Segundo o pensamento de Altshuller, se a busca por uma solução ideal for conduzida por meio de um procedimento sistemático, a equipe de desenvolvimento de produto pode iniciar essa busca empregando um nível mais elementar de conhecimento, isto é, o conhecimento pessoal dessa equipe. Na seqüência, trabalhando em níveis mais altos, a equipe de projeto pode buscar soluções, cuja procedência encontra-se em outros campos de conhecimento, isto é, na própria indústria, outras indústrias e na ciência. Pesquisando essas patentes, Altshuller “destilou” os problemas, as contradições e as soluções, desenvolvendo uma teoria que rege a busca por soluções de problemas inventivos. Essa teoria é denominada Teoria da Solução de Problemas Inventivos. E, dentre os vários métodos para a solução de problemas, segundo a TIPS, o método dos princípios inventivos e da matriz de contradições merece destaque. Isso se justifica pela simplicidade do método, que se baseia nos conceitos de parâmetros de engenharia e princípios inventivos. O método inicia com a identificação dos requisitos de projeto a serem otimizados e conflitantes. Depois, associam-se esses requisitos em contradição com os parâmetros de engenharia da TIPS. Os parâmetros de engenharia correspondem às grandezas que devem ser maximizadas, minimizadas ou otimizadas. Existem 39 parâmetros de engenharia. Realizada a associação, identificam-se os princípios inventivos da TIPS, utilizando a Matriz de Contradição.

252

PARTE 2

Quadro 7.5

O Modelo

TIPS

A utilização da TIPS no processo de desenvolvimento de produtos pode ser vista na Figura 7.17. De uma forma bastante sucinta, para gerar as alternativas de concepção do produto, segundo a abordagem proposta na Figura 7.17, é empregada a Matriz de Contradição da TIPS, juntamente com a Primeira Matriz do QFD, a Casa da Qualidade. Para isso, primeiro deve-se identificar, na Matriz de Correlação do QFD, as contradições existentes entre os requisitos de projeto. Na seqüência, deve-se associar os requisitos em contradição aos parâmetros de engenharia da TIPS. A seguir, empregando a Matriz de Contradição da TIPS, obtêm-se os princípios inventivos da TIPS. E, finalmente, considerando esses princípios inventivos e empregando a Matriz Morfológica, são gerados os princípios de solução que, combinados, originam as alternativas de concepção do produto. Figura 7.17

Fluxograma de aplicação da TIPS no processo de projeto do produto.

A seguir, será apresentado, tarefa a tarefa, o emprego do QFD, juntamente com a Metodologia da TIPS na atividade de desenvolvimento do produto. Dessa forma, tem-se:

• Tarefa 1: Levantar as necessidades dos clientes. A execução desta tarefa pode ser realizada segundo as práticas tradicionais de projeto, por meio do emprego de questionários estruturados, pesquisa de mercado, entrevistas, entre outros.

• Tarefa 2: Estabelecer os requisitos de projeto do produto. A execução desta tarefa deve ocorrer segundo as práticas tradicionais de projeto.

• Tarefa 3: Relacionar as necessidades com os requisitos, visando identificar a importância relativa dos requisitos de projeto. A execução desta tarefa deve ser realizada segundo a abordagem tradicional do QFD.

• Tarefa 4: Correlacionar os requisitos de projeto entre si, procurando identificar as contradições entre eles. Para isso, esses requisitos devem ser correlacionados na Matriz de Correlação do QFD (telhado), procurando identificar, para um dado requisito a ser satisfeito, aqueles que dificultam o atendimento desse objetivo.

• Tarefa 5: Identificar os requisitos de projeto a serem otimizados e os respectivos requisitos em contradição. É realizada com base na importância dos requisitos de projeto, obtida na Tarefa 3. Dessa forma, comparando-se os requisitos em contradição, aquele que apresentar maior importância deve ser entendido como o requisito de projeto a ser otimizado e — o correspondente — o requisito em contradição.

(continua)

CAPÍTULO 7

Projeto Conceitual

Quadro 7.5

253

TIPS (continuação)

• Tarefa 6: Associar os requisitos em contradição aos parâmetros de engenharia da TIPS. Essa associação deve ser realizada considerando os 39 parâmetros de engenharia e levando em conta a sua similaridade e compatibilidade.

• Tarefa 7: Identificar o princípio inventivo da TIPS. Essa identificação, ou seja, a busca por uma orientação para a solução das contradições entre os requisitos de projeto é realizada empregando a Matriz de Contradição da TIPS. A utilização da Matriz de Contradição da TIPS, ilustrada, esquematicamente, na Figura 7.18, envolve, inicialmente, a identificação, no “Campo 1", do parâmetro de engenharia a ser otimizado e, no ”Campo 2", do correspondente parâmetro que se encontra em contradição. Do relacionamento entre esses requisitos é obtido, no “Campo 3”, um ou mais princípios de solução, que indicam a solução para o problema. Figura 7.18

Representação esquemática da Matriz de Contradição da TIPS.

Tarefa 8: Gerar as alternativas de concepção do produto. O processo de geração de alternativas de concepção envolve, inicialmente, a etapa de estruturação funcional, em que é desenvolvido um modelo do produto em termos de funções expressas por meio de fluxos de energia, material e sinal. Para auxiliar o desenvolvimento desse processo, pode-se empregar a modelagem funcional descrita no Tópico 7.3. Dando procedimento à geração das alternativas de concepção, na seqüência, deve-se estabelecer quais funções da estrutura funcional estão relacionadas com os requisitos de projeto a serem otimizados, identificados na Tarefa 5. Esse relacionamento tem o objetivo de determinar em quais funções podem ser empregados os princípios inventivos da TIPS, para auxiliar a geração dos princípios de solução que, combinados, originam as alternativas de concepção. Para auxiliar a execução dessa tarefa, pode-se empregar a Matriz de Relacionamento entre Função e Requisito Otimizado, apresentada na Figura 7.19. Nas colunas da matriz estão relacionadas as funções da estrutura funcional do produto e, nas linhas, os requisitos de projeto a serem otimizados. Os itens assinalados com o símbolo “•” indicam que existe uma relação entre a função e o requisito de projeto. Nesse caso, observa-se uma relação entre o requisito 1 e a função 1, o requisito 2 e a função i, e o requisito j e a função 2. Na seqüência, devem ser gerados os princípios de solução que, combinados, originam as alternativas de concepção do produto. A TIPS pode ser empregada na geração de princípios de solução. Para isso, a TIPS deve ser utilizada juntamente com a Matriz Morfológica. A Figura 7.20 ilustra, esquematicamente, a Matriz Morfológica. Nesse caso, considerando o resultado da Figura 7.19, os princípios inventivos da TIPS foram empregados na geração dos princípios funcionais das funções 1, 2 e I.

(continua)

254

PARTE 2

Quadro 7.5

O Modelo

TIPS (continuação)

Figura 7.19

Matriz de Relacionamento Função versus Requisito Otimizado.

Figura 7.20

Matriz Morfológica — representação esquemática.

7.5

Desenvolver as alternativas de solução para o produto

Com as alternativas de princípios de solução para as várias funções que compõem a estrutura de funções desenvolvida e selecionada para o sistema, o próximo passo em direção à elaboração de modelos de concepção é a combinação dos princípios de solução individuais para formar os princípios de solução totais para o produto. Uma importante ferramenta para a combinação de princípios de solução individuais em princípios de solução totais para o produto é a matriz morfológica. A matriz morfológica dispõe simultaneamente as funções que compõem a estrutura funcional escolhida para o produto e as diversas possibilidades de solução para elas. A matriz morfológica possibilita uma análise das possíveis configurações para o produto projetado. A matriz morfológica é construída tendo como primeira coluna as funções identificadas na atividade de estruturação funcional. Em seguida, procura-se gerar o maior número possível de princípios de soluções para cada uma das funções da matriz. Posteriormente, esses princípios de solução são combinados, formando os princípios

CAPÍTULO 7

Projeto Conceitual

255

de solução totais para o produto. A representação dos princípios de solução são geralmente abstratos, não tendo uma geometria mais específica. Os princípios de solução totais desenvolvidos podem ser representados por esboços, croquis, diagramas de blocos, descrições textuais, modelos de papel, argila ou polímero, ou outras formas que possam dar alguma indicação da maneira pela qual as funções são realizadas. Vamos considerar o desenvolvimento de um equipamento destinado à limpeza de mexilhões (Scalice, 2003). A função total do equipamento é mostrada na Figura 7.21; a estrutura funcional, na Figura 7.22 e, na Figura 7.23, a matriz morfológica para esse equipamento. Figura 7.21

Função total do equipamento para limpeza de mexilhões.

Figura 7.22

Estrutura funcional do equipamento para limpeza de mexilhões.

Após a geração dos princípios de solução, deve-se combinar (integrar) os princípios de solução (síntese). Um grande número de combinações é possível; contudo, existem restrições em razão da compatibilidade física e geométrica entre os princípios de solução e o próprio compartilhamento de funções. A Figura 7.24 apresenta possíveis alternativas de solução, para o produto, em que cada coluna representa uma delas.

256

PARTE 2

Figura 7.23

O Modelo

Matriz morfológica do equipamento para limpeza de mexilhões.

CAPÍTULO 7

Projeto Conceitual

Figura 7.24

7.6

257

Alternativas de solução para o processo de limpeza dos mexilhões.

Definir arquitetura

Nesta atividade, o produto deve ser visto como sendo composto de diferentes partes, as quais estão relacionadas com os princípios de solução individuais adotados nos princípios de solução total (alternativas de solução) e com as funções a eles atribuídas. Dessa forma, as alternativas de solução são desdobradas em Sistemas, Subsistemas e Componentes (SSC) que deverão atender às funções do produto. A Figura 7.25 mostra as tarefas desta atividade.

258

PARTE 2

Figura 7.25

O Modelo

Tarefas da atividade “Definir a arquitetura”.

A arquitetura de um produto é o esquema pelo qual os elementos funcionais do produto são arranjados em partes físicas e como essas partes interagem por meio das interfaces. Decisões sobre essa arquitetura influenciarão no gerenciamento e organização do esforço de desenvolvimento, pois possibilitarão que sejam designadas atividades de projeto e testes dessas partes para equipes, indivíduos e/ou fornecedores, de modo que o desenvolvimento de diferentes porções do produto possam ocorrer simultaneamente. Assim, cada alternativa de projeto ou modelo de princípio de solução total gerado na atividade anterior terá uma arquitetura específica. A Figura 7.26 ilustra o exemplo da representação de uma arquitetura para uma alternativa de projeto de um elevador de automóveis de passeio. Um motor elétrico aciona um redutor que, por sua vez, aciona, por meio de uma corrente, o eixo de um parafuso de movimento. O giro do parafuso faz subir ou descer o garfo que sustenta o automóvel, impedido de girar por uma guia. A segunda coluna é acionada pela primeira, por meio de uma segunda corrente. Figura 7.26

Representação da arquitetura de um elevador de automóveis (Gomes Ferreira, 1997).

CAPÍTULO 7

Projeto Conceitual

259

Como pode ser observado nesse exemplo, são exibidos os elementos que constituem o produto, bem como os seus inter-relacionamentos, incluindo a sua estrutura. Entretanto, não são representadas as formas exatas, dimensões, todas as quantidades dos elementos e materiais. O desenvolvimento da arquitetura de um produto envolve a divisão e identificação dos sistemas, subsistemas e componentes individuais, sua localização e orientação. A arquitetura de um produto pode ser classificada em modular e integral. A arquitetura modular é caracterizada por um a um dos módulos implementarem uma ou algumas poucas funções, não existindo o compartilhamento de funções entre dois ou mais módulos; e as interações entre os módulos são bem definidas e fundamentais para a realização da função global do produto. A arquitetura mais modular é aquela na qual cada função do produto é implementada exatamente por um módulo físico, e as interações entre os módulos são poucas e bem definidas. Nesse tipo de arquitetura, uma mudança de projeto pode ser feita em um módulo apenas, não sendo necessárias modificações em outros módulos para que o produto funcione corretamente. Os módulos podem ser de certa forma projetados, independentemente um dos outros. O oposto de uma arquitetura modular é a chamada arquitetura integral. E essa é caracterizada por ter as funções do produto distribuídas em vários conjuntos de componentes; e as interações entre os componentes são mal definidas. Um produto desenvolvido com uma arquitetura integral geralmente é projetado tendo-se em mente uma performance mais elevada. As funções podem ser distribuídas em vários conjuntos de componentes, e as funções podem ser combinadas em poucos componentes para otimizar o desempenho de certas dimensões e/ou parâmetros, contudo, modificações de projeto podem necessitar de um extenso trabalho de reprojeto do produto como um todo. As decisões sobre a estruturação do produto em módulos ou não dependem de fatores como: modificações no produto, desempenho, variedade, padronização dos componentes, manufatura e gerenciamento do projeto. A arquitetura do produto define como os componentes físicos se relacionam, definindo também como o produto pode ser modificado. Arranjos modulares permitem que mudanças sejam feitas em determinadas funções do produto, sem necessariamente afetar o projeto de outros módulos. Para arranjos integrais do produto, uma modificação pode afetar diferentes funções, tornando necessárias mudanças em vários componentes relacionados. Algumas razões para um produto sofrer modificações são: n n n n n n n

atualizações; adições; adaptações desgaste de certos componentes; consumo de materiais; flexibilidade no uso e reuso.

Em cada um desses casos, a arquitetura modular permite a minimização das modificações físicas necessárias para obter uma determinada mudança funcional. O termo modularidade é usado informalmente de muitas maneiras e em difeModularidade rentes contextos. No contexto do projeto de sistemas grandes e complexos, o termo refere-se ao uso de unidades independentes. No contexto da arquitetura, o termo está associado a uma construção que utiliza componentes padronizados. No contexto da manufatura, o termo refere-se ao uso de unidades intercambiáveis, para criar uma variedade de produtos. Independentemente do contexto, a independência de componentes é a propriedade de um projeto que leva à padronização e à intercambiabilidade (variedade). Modularidade pode ser vista como a qualidade ou característica de um sistema em separar partes independentes ou módulos, que podem ser tratados como unidades lógicas. Modularidade está relacionada com a maneira pela qual o produto é fisicamente dividido em componentes. Assim, modularidade é uma propriedade ou

260

PARTE 2

O Modelo

atributo relativo, ou seja, os produtos não podem ser classificados como modulares ou não, mas se exibem mais ou menos modularidade no projeto. Segundo Ulrish e Tung, (1991), o aproveitamento da padronização de componentes para a obtenção da variedade de produtos permite a classificação de cinco tipos de modularidade, que podem ser encontrados no ambiente industrial. A seguir tem-se a descrição desses tipos de modularidade, os quais são exemplificadas na Figura 7.27. Figura 7.27

n

n

n

Tipos de modularidade encontrados na indústria (Ulrish & Tung, 1991).

Modularidade em permutar componentes: é a habilidade de permutar duas ou mais alternativas de componentes sobre a mesma região de um produto básico, criando assim diferentes variantes do produto pertencentes à mesma família de produtos. Exemplos deste tipo de modularidade são encontrados em automóveis que disponibilizam diferentes rádios, toca-fitas, CDs, pára-brisas e rodas para um mesmo modelo de automóvel; em computadores que disponibilizam diferentes tipos de discos rígidos, monitores e teclados para a mesma CPU. Este tipo de modularidade é associado à criação de variedade de produtos. Modularidade em compartilhar componentes: este tipo de modularidade ocorre nos casos em que o mesmo componente básico é utilizados em diferentes famílias de produtos, sendo esse um caso complementar ao anterior. Exemplos deste tipo de modularidade em automóveis são o uso de mesmas sapatas de freio, alternadores e velas de ignição em diferentes famílias de automóveis. Em computadores, esta modularidade é exibida quando um mesmo microprocessador ou monitor é usado em diferentes famílias desse produto. Este tipo de modularidade é freqüentemente associado à idéia de componentes padronizados. Modularidade em adaptar para a variedade: este tipo de modularidade é empregado quando se utilizam um ou mais componentes padronizados conectados com um ou mais componentes adicionais variáveis. Na maioria das vezes, a variedade é associada às dimensões físicas dos componentes adicionais, que podem ser modificadas facilmente, por um processo de produção simples. Exemplos deste tipo de modularidade são as montagens de cabos, nas quais dois conectores padronizados podem ser usados com um cabo com comprimento qualquer, e cilindros hidráulicos que podem ser produzidos com comprimentos arbitrários.

CAPÍTULO 7

Projeto Conceitual

n

n

261

Modularidade através de barramento: este tipo de modularidade é empregado quando se faz uso de um componente básico, que possua duas ou mais interfaces de união, para o acoplamento de um ou mais componentes adicionais variáveis. No caso, suas interfaces aceitariam qualquer acoplamento, por meio de qualquer combinação, para o grupo de componentes a ser assentado ao mesmo. Este tipo de modularidade difere das anteriores pela sua capacidade de variar o número e a localização dos componentes do sistema, enquanto as demais só permitem variações nos tipos de componentes usados em um produto de arquitetura idêntica. Modularidade seccional: é caracterizada pela presença de uma coleção de tipos de componentes, que podem ser unidos de forma arbitrária às suas interfaces. Cada um desses componentes pode ter uma ou mais interfaces que permitem, a partir de um componente, a construção de uma seqüência ou uma árvore de estruturas. Exemplos típicos deste tipo de modularidade são achados em sistemas de tubulação, móveis do tipo sofá, blocos lego e sistemas de transporte.

Uma ferramenta para a definição dos módulos é a Matriz Indicadora de Módulos, MIM (Erixon et al. 1996), que indica quais as funções que apresentam uma maior vocação ou tendência a formar módulos e quais devem ser agrupadas, formando um módulo. Essa ferramenta baseia-se em 12 diretrizes relacionadas às razões pelas quais um produto deveria ser modularizado. As diretrizes são critérios que consideram características de todo o ciclo de vida do produto, mostradas na Tabela 7.2. Em um procedimento semelhante ao empregado no QFD (Quality Function Deployment), essas diretrizes são confrontadas com as funções desempenhadas pelo produto, atribuindo-se valores a cada relacionamento, tal qual ilustrado na Figura 7.28. As funções que apresentarem os melhores resultados no somatório de pontos poderão ser modularizadas, bem como os grupos de funções que apresentarem um forte relacionamento com alguma diretriz (Figura 7.28). Figura 7.28

Exemplo esquemático da aplicação da MIM.

262

PARTE 2

Tabela 7.2

O Modelo

Diretrizes de Modularização Segundo Erixon et al. (1996)

Desenvolvimento de produtos

Variação

Fabricação

Multiaplicativo (“Carry-Over”)

Uma função pode ser um módulo separado em que a solução tecnológica atual poderá ser levada para uma nova geração ou família de máquinas.

Evolução tecnológica

Uma função pode ser um módulo único se essa possuir uma tecnologia que será superada no seu ciclo de vida.

Planejamento de alteração de projeto

Uma função pode ser um módulo separado se essa possuir características que serão alteradas segundo um plano.

Especificação técnica

Poderão ser concentradas alterações para se conseguir variantes em um módulo.

Estilo

Função pode ser um módulo separado se essa for influenciada por tendências e modas de tal maneira que as formas e/ou as cores tenham de ser alteradas.

Unidade comum

Uma função poderá ser separada em um módulo se essa possuir a mesma solução física em todos os produtos variantes.

Processo e organização

Razões para separar uma função em um módulo: • Ter uma tarefa específica em um grupo. • Encaixar-se no conhecimento tecnológico da empresa. • Possuir uma montagem pedagógica. • Ter um tempo de montagem que difere extremamente dos outros módulos.

Qualidade

Testes em separado

Uma função poderá ser separada em um módulo quando essa função puder ser testada separadamente.

Aquisição

Compra de produtos prontos

Uma função que pode ser tratada como uma caixa preta causa redução dos custos logísticos.

Após estar no Mercado

Manutenção e

Manutenções e reparos podem ser facilitados se uma função ficar bem em um módulo separado.

manutenabilidade Atualização

Se for necessário, pode ser facilitada se a função a ser atualizada for um módulo.

Reciclagem

Isto pode ser uma vantagem para concentrar materiais poluentes ou recicláveis em um mesmo módulo ou em módulos separados, conforme o caso.

A integração entre os SSCs pode ser definida por meio das interfaces entre eles. As interfaces podem ser fixas, móveis ou ser um meio de transmissão, elas têm um papel importante no produto final, em virtude da intercambiabilidade entre os SSCs, e são determinantes para a sua montagem. A Matriz de Interfaces (Erixon et al., 1996), mostrada na Figura 7.29, pode ser utilizada para dar uma idéia das interfaces entre os módulos, indicando o tipo de interface, restrições e tempo de montagem.

CAPÍTULO 7

Projeto Conceitual

Figura 7.29

Matriz de Interfaces (Erixon et al., 1996).

Quadro 7.6

Projeto Modular

Um produto é considerado modular quando suas partes (módulos) podem ser testadas de forma independente, e suas interfaces (a forma de conexão entre os módulos do produto) foram desenvolvidas de maneira padronizada. Do ponto de vista do usuário, um módulo pode ser visto como uma caixa-preta, a qual engloba um ou mais SSCs do produto, e que pode ser facilmente substituído por outro módulo, contanto que seja respeitada a interface (conjunto de entradas, saídas e fixações especificadas durante o projeto). Vários são os objetivos em se adotarem metodologias de projeto modular, os quais podem ser enquadrados em uma ou mais das categorias descritas a seguir:

263

Fonte: www.netcar.co.il/img2/milon/ 36A%20modular%20body.jpg

• Desenvolvimento de plataformas de produtos: trata-se do desenvolvimento de famílias de produtos, de forma modular, que compartilham funções globais semelhantes, uma mesma física estrutura básica, e podem ser identificados como produtos distintos. Um exemplo típico da utilização do projeto modular para o desenvolvimento de plataformas é dado pela indústria automobilística, em que variações de modelo podem ser obtidas para um mesmo chassi, bem como modificações de natureza estética e de conforto em um mesmo modelo.

• Máximo compartilhamento de sistemas: as técnicas e ferramentas utilizadas no projeto modular podem ser empregadas de forma a serem estabelecidos sistemas e subsistemas (ou, em certos casos, até mesmo componentes) a serem utilizados de diferentes linhas e famílias de produtos, ou reutilizar sistemas já existentes. No limite, tal esforço leva à elaboração de uma série de (subsistemas) padrões, a exemplo de motores elétricos, compressores ou outros commodities, cuja produção pode ser, até mesmo, terceirizada.

• Máxima variação funcional: o objetivo é obter uma estrutura básica na qual diferentes módulos funcionais (ou seja, módulos que participam da função global do produto) possam ser acoplados de forma a estabelecer variantes do produto. Um exemplo que se enquadra nesse caso são os multiprocessadores de alimentos, os quais desempenham diferentes funções a partir de alterações mínimas em sua configuração.

• Otimização do ciclo de vida do(s) produto(s): ao desenvolver um novo produto, pode ser interessante utilizar os recursos disponibilizados pelo projeto modular para otimizar diferentes aspectos de seu ciclo de vida, levando soluções técnicas para novas gerações de máquinas, substituindo-se a tecnologia atual por uma em desenvolvimento (exemplo: encapsular componentes a serem substituídos), facilitando alterações estéticas, auxiliando a fabricação e

(continua)

264

PARTE 2

Quadro 7.6

O Modelo

Projeto Modular (continuação)

montagem, simplificando a aquisição de módulos já existentes no mercado, facilitando a manutenção e atualização do produto (exemplo: agrupando elementos de vida semelhante) e otimizando a reciclagem (exemplo: módulos com componentes de materiais semelhantes). Comparando-se com o processo convencional de desenvolvimento de produtos com o de desenvolvimento de produtos modulares, não se observam grandes diferenças em termos de estruturas de fases. No entanto, ao se analisar o PDP em relação às suas atividades e tarefas, grandes diferenças são observadas, dentre as quais incluem-se o levantamento de necessidades dos consumidores para todas as variantes da família de produtos durante o projeto informacional, a síntese e estudo em conjunto das estruturas funcionais visando encontrar as similaridades existentes entre as funções do produto durante o Projeto Conceitual, e a necessidade de se projetar a interface entre os módulos. Apesar do esforço extra de projeto, resultado do esforço simultâneo de desenvolvimento agregado ao projeto da interação entre módulos, vários benefícios advêm dessa modalidade de projeto, incluindo: obtenção de uma maior padronização entre produtos, reduções no número total de componentes na empresa, simplificação da aplicação de mudanças ao longo do ciclo de vida do produto, facilitação da realização de testes dos componentes dos produtos e, talvez o elemento mais atrativo às empresas, uma maior flexibilidade para se adaptarem e atenderem rapidamente as exigências do mercado. No entanto, tal modalidade não traz apenas benefícios, sendo problemas típicos a facilitação da cópia do produto em decorrência da identificação mais fácil do relacionamento forma-função e o ocasional aumento de custos de algumas variantes de produtos (usualmente compensado pelos fatores de economia de escala).

7.7

Analisar Sistemas, Subsistemas e Componentes (SSC)

Esta atividade compreende uma espécie de refinamento da atividade anterior, no qual são identificados e analisados aspectos críticos do produto observados no ciclo de vida do produto, como questões de funcionamento, fabricação, montagem, desempenho, qualidade, custos, uso, descarte e outros. As informações aqui levantadas são importantes para a definição de parcerias de co-desenvolvimento e identificação dos possíveis processos de fabricação dos componentes e de montagem do produto. A Figura 7.30 ilustra as tarefas desta atividade que basicamente transforma as alternativas de projeto em concepções do produto. Figura 7.30

Tarefas da atividade “Analisar SSCs”.

CAPÍTULO 7

Projeto Conceitual

265

Toda a alternativa de projeto de produto possui certos parâmetros que são críticos para a sua própria operação. É importante que se conheçam quais são os parâmetros (formas, dimensões, propriedades dos materiais etc.) críticos para o funcionamento do produto. Também se deve buscar os valores desses parâmetros para se obter um desempenho satisfatório ou melhorar a manufaturabilidade dos componentes. Além disso, pode-se definir de maneira inicial os possíveis modos de falha do produto. A arquitetura do produto geralmente representa o produto em termos das propriedades físico-técnicas que são essenciais ao seu funcionamento. Acontece que a avaliação e a escolha de uma determinada alternativa de projeto não deve apenas se basear em critérios de natureza técnica. Critérios relacionados ao uso, aparência, produção, custos e outros devem ser considerados. Assim, os modelos de princípios de solução total de produto devem ser desenvolvidos para se chegar aos chamados modelos de concepção do produto. De uma maneira geral, um modelo de concepção deve ser suficientemente detalhado para ser possível verificar custos, pesos e dimensões totais aproximadas, e a exeqüibilidade deve ser assegurada tanto quanto as circunstâncias permitam. Assim, o desenvolvimento das alternativas de projeto, já com suas arquiteturas definidas, em modelos de concepção, passa pela definição das formas, materiais utilizados e um dimensionamento inicial dos SSCs. Aproveitando-se o exemplo do elevador de automóveis, mostrado na Figura 7.26, para o desenvolvimento daquela arquitetura em uma concepção para o produto, em termos da definição das formas, deve ser escolhido o perfil aproximado das colunas de sustentação e as formas aproximadas do par parafuso e cubo dos garfos de sustentação do automóvel, entre outros. Em termos dos materiais utilizados nos SSCs, pode-se indicar que sua estrutura será construída fundamentalmente por chapas de aço-carbono laminadas, sem indicar precisamente qual aço-carbono será utilizado. No caso da chapa laminada, já há uma indicação da forma com que o material será apresentado, do processo a que foi submetido o material (laminação) e também de alguns dos possíveis processos envolvidos na construção do produto: corte, dobramento, aparafusamento e soldagem de chapas finas. Essas informações fornecem subsídios para uma estimativa bem preliminar de custos. Já o dimensionamento inicial dos principais SSCs pode ser matemático ou intuitivo. Deve-se buscar as dimensões mais significativas que possam servir de base para a estimativa de pesos, custos e outros critérios para a avaliação de concepção. Para o elevador, pode-se estimar as alturas e distâncias dos parafusos e das colunas em função das dimensões dos automóveis e das alturas à que devem ser elevados. A espessura da chapa pode ser dimensionada intuitivamente pela própria experiência do projetista. A potência do conjunto moto-redutor pode ser grosseiramente estimada pela multiplicação da velocidade de elevação pelo peso do automóvel, aplicando-se os devidos coeficientes de incerteza. Outras dimensões devem dessa forma ser estimadas e outras ainda, com menores implicações, devem ser deixadas para o projeto detalhado. Com isso, pode-se chegar ao modelo de concepção do elevador de automóveis mostrado na Figura 7.31. No caso, optou-se por utilizar um desenho de duas vistas de projeção ortogonal (frontal e superior). Também podem ser usados os modelos de concepção esboçados em perspectiva. O modelo de concepção representa o produto, sobretudo em linguagem gráfica, ou seja, em desenhos esquemáticos ou esboços. Suas propriedades já se assemelham razoavelmente com as propriedades pretendidas no produto — o modelo de concepção deve, na medida do possível, se parecer com o produto pretendido. Suas funções principais são a descrição e a comunicação das idéias básicas que constituem a concepção elaborada. Dessa forma, é possível gerar uma BOM (Bill Of Material, Estrutura do Produto) inicial para cada concepção desenvolvida.

266

PARTE 2

O Modelo

Figura 7.31

Modelo de concepção para um elevador de automóvel (Gomes Ferreira, 1997).

Quadro 7.7

Seleção de Materiais

Todos os produtos são compostos de um ou mais materiais. Esses materiais possuem massa e devem ser manufaturados para que se obtenha uma determinada forma dos componentes. Os materiais tipicamente desempenham uma ou mais das seguintes funções: suportar cargas, conduzir calor, isolar, conduzir eletricidade, resistir ao desgaste, resistir à corrosão, propiciar formas, superfícies e cores esteticamente agradáveis etc. Além disso, um material inadequadamente selecionado pode levar à falha de um componente e, também, a custos desnecessários. A seleção de um material que atenda às especificações-meta, em um custo aceitável, é uma parte importante do processo de desenvolvimento de um produto. Contudo, a seleção de materiais não pode ser feita independentemente do processo de manufatura, e a seleção do processo de manufatura depende de atributos geométricos do produto, tamanho e quantidade a ser manufaturada.

(continua)

CAPÍTULO 7

Projeto Conceitual

Quadro 7.7

267

Seleção de Materiais (continuação)

Além do elevado número de fatores que devem ser considerados, a seleção de materiais torna-se uma tarefa complexa pelo elevado número de alternativas encontradas no mercado. Atualmente estima-se que existam mais de 100.000 diferentes materiais entre metálicos e não-metálicos.

Sistemática de Seleção de Materiais A seleção de materiais é um problema de múltiplas variáveis e de múltiplas restrições. Vários procedimentos de seleção quantitativos foram desenvolvidos para analisar a grande quantidade de dados envolvidos no processo de seleção, possibilitando, assim, que uma avaliação sistemática possa ser feita. Observa-se, ainda, que o processo de seleção é dependente das propriedades dos materiais, do processo de fabricação e do projeto do componente. Geralmente, as empresas não realizam uma seleção de materiais rigorosa e minuciosa, sendo essa baseada na experiência e práticas anteriores, o que nem sempre significa uma solução ótima. As situações de projeto também são diferentes: o projeto de um produto novo ou o reprojeto de produto existente, e mesmo que a seleção de materiais e processos seja normalmente pensada em termos do desenvolvimento de um novo produto, existem muitas razões para se revisarem os tipos de materiais e processos usados em um produto existente. Essas razões incluem as vantagens obtidas com novos materiais e processos; a melhoria do desempenho em serviço, incluindo aumento de vida e confiabilidade mais elevada; o atendimento de novas exigências legais; mudanças nas condições de operação; redução de custo; melhora de desempenho e competitividade. A Figura 7.32 mostra uma alternativa para a tarefa de seleção de materiais. Figura 7.32

Sistemática para seleção de materiais.

Inicialmente, a análise dos aspectos críticos dos SSC e, sobretudo, das condições de serviço e o ambiente em que o produto deverá operar determinarão os requisitos que deverão ser atendidos pelo material a ser escolhido. Com os requisitos estabelecidos, deve-se traduzi-los em propriedades críticas do material e nos valores máximos ou mínimos dessas propriedades. As possíveis alternativas em termos dos materiais candidatos são obtidas comparando-se as propriedades críticas com as respectivas propriedades de materiais existentes, para identificar quais são aqueles que têm potencial para atender às exi-

(continua)

268

PARTE 2

Quadro 7.7

O Modelo

Seleção de Materiais (continuação)

gências. Por exemplo, quais os materiais que têm a resistência ao escoamento maior do que um limite fixado ou quais materiais que têm uma densidade menor do que um limite dado. Dessa forma, limita-se o universo de materiais que serão submetidos a uma análise mais detalhada. A escolha do material a ser utilizado se dá pela análise das alternativas de materiais em termos de desempenho do produto, custo, fabricabilidade e disponibilidade, com o objetivo de identificar o material que melhor atende ao problema. Após selecionar o material, é necessário conhecer as formas e tamanhos nos quais esses materiais são disponíveis comercialmente. A Tabela 7.3 mostra essas informações. Eles podem ser obtidos em várias formas: fundidos, extrudados, forjados, barras, placas, chapas, folhas, arames e pós-metálicos, e não-metálicos. Tabela 7.3

Formas Comercialmente Disponíveis de Materiais Material

Disponível como

Alumínio

P, F, B, T, A, E, L

Cobre e latão

P, f, B, T, A e, L

Magnésio

P, B, T, a, E, L

Aços

P, B, T, A, E, L

Metais preciosos

P, F, B, t, A, L

Zinco

P, f, B, T, a

Plástico

P, b, T

Elastômeros

P, B, T, e

Cerâmica (alumina)

P, B, T, A, e

Grafite

P, B, T, A, e

P – placa ou chapa, F – folha, B – barra, T – tubo, A – arame, E – formas estruturais, L – lingotes para fundição. Os caracteres minúsculos indicam disponibilidade limitada. A maioria desses materiais são disponíveis na forma de pó

A atividade de análise dos SSCs marca um momento importante na atividade de projeto, pois permite que a equipe de projeto possa prever os impactos do ciclo de vida no projeto do produto. A não-consideração ou estimativa inadequada desses fatores leva a decisões “pobres” e problemas imprevistos no projeto do produto, os quais resultarão em atividades de reprojeto. Previsões adequadas possibilitam à equipe de desenvolvimento do produto criar projetos superiores com desempenho satisfatório em todos os aspectos. Isso não somente reduz o número de iterações de reprojeto, o tempo de desenvolvimento e os custos de desenvolvimento e manufatura, mas também melhora a percepção do produto por parte dos clientes. Entretanto, existem dificuldades para prever esses aspectos do ciclo de vida nas primeiras fases do processo de projeto do produto. Essas dificuldades vão desde o nível de abstração do produto nas primeiras fases até a quantidade e complexidade desses aspectos. Assim, para auxiliar os projetistas a melhor avaliar os impactos do ciclo de vida relativos às suas decisões de projeto, empresas e pesquisadores desenvolveram vários métodos e ferramentas de auxílio às decisões de projeto, denominadas de abordagens DFX (Design For X, Projeto para X). O “X” representa qualquer uma das várias considerações que ocorrem ao longo do ciclo de vida, tais como: qualidade, manufatura, produção ou meio ambiente. Os métodos DFX podem se apresentar de diferentes formas. Pode ser na forma de um procedimento ou um conjunto de regras ou diretrizes, ou pode ser um software que reaO DFX no Projeto Conceitual

CAPÍTULO 7

Projeto Conceitual

269

liza vários tipos de análises, resultando em estimativas de custo, manufaturabilidade ou desempenho, que são, então, utilizados pelos projetistas nas tomadas de decisão. Além disso, o DFX é uma das mais efetivas abordagens para a implementação da Engenharia Simultânea. O DFX pode ser considerado uma base de conhecimentos com o objetivo de projetar produtos que maximizem todas as características como: alta qualidade, confiabilidade, serviços, segurança, usuários, meio ambiente e tempo de mercado — ao mesmo tempo que minimiza os custos do ciclo de vida e de manufatura do produto. A importância de qualquer metodologia DFX, principalmente no Projeto Conceitual, deve-se ao fato de que as decisões tomadas nessas etapas têm o maior efeito nos custos de um produto pelo menor investimento. Adicionalmente, essas decisões são responsáveis pela determinação de aspectos relacionados à funcionalidade, geometria e propriedades do produto; isto é, define-se o desempenho e a competitividade do produto por todo o seu ciclo de vida. Principalmente no aspecto de qualidade, a qual não pode ser construída em um produto a não ser que seja projetada nele; e no da atratividade econômica, já que o produto deve mostrar-se economicamente viável para todos os envolvidos, desde o fornecedor de matéria-prima até o recuperador. Quadro 7.8

Relação de DFX

A seguir serão apresentados os DFXs mais comumente encontrados na literatura e que são utilizados em empresas, dando uma visão geral das características e abordagem de cada um. Projeto para Manufatura (Design for Manufacturability, DFM): concentra-se no entendimento de como o projeto do produto interage com outros componentes do processo de manufatura e na definição de alternativas no projeto, para a configuração desse, visando custos, qualidade e produtividade. Pode ser encontrado com o nome de projeto para a produtividade. Projeto para Montagem (Design for Assembly, DFA): envolve o projeto do produto, verificando funções, formas, materiais e processo de montagem. Gera redução de custos em razão do tempo de montagem, redução de componentes e, muitas vezes, a simplificação da manufatura. Projeto para Manufatura e Montagem (Design for Manufacturing and Assembly, DFMA): compreende a união dos princípios do DFM com DFA. Projeto para Qualidade (Design for Quality, DFQ): este método visa a garantia do atendimento dos requisitos para a qualidade do produto. Implica gerenciamento de todo o processo, definindo e controlando fatores, que influenciam e garantem a qualidade. Projeto para Reciclagem (Design for Recycling, DFR): aqui são definidas regras e recomendações que visam auxiliar no projeto do produto, a fim de reaproveitá-lo ou partes dele para outros fins. Tem uma relação com alguns princípios do método de Projeto para Desmontagem. Projeto para Custo (Design for Cost, DFC): implica, de maneira geral, trabalho com os custos diretos (materiais, desenvolvimento etc.) e indiretos (transporte, estoque etc.) da companhia, relacionado ao processo de projeto. Objetiva estimar e trabalhar para a redução desses custos, controlando, assim, o processo. Projeto para Ciclo de Vida (Design for Cycle of Life, DFCL): trata de fatores que envolvem o ciclo de vida do produto, baseado nos custos e incertezas, de maneira a fornecer um modelo otimizado para especificação do produto e parâmetros do processo. Projeto para o Meio Ambiente (Design for Enviroment, DFE): tem o propósito de minimizar o impacto ambiental do produto e de sua produção. Apresenta aspectos relacionados com o domínio de estratégias de marketing e política de decisões (gerenciamento), e em um nível operacional relacionado ao domínio de projeto de produtos (projetistas). Assemelha-se aos conceitos de projeto para sustentabilidade e toda a gama de ecoferramentas e Green Design. Projeto para Controle Dimensional (Design for Dimensional Control, DDC), objetiva reconhecer e gerenciar o controle dimensional durante o projeto, manufatura e montagem. Abrange fatores como redução do tempo do ciclo de vida, complexidade do produto, etc. Projeto para Serviço (Design for Service, DFS): compreende na adequação do produto para a operação, manutenção, fácil acesso a componentes, etc; de maneira a garantir a performance contra conflitos entre diferentes serviços que possam ser executados no produto.

(continua)

270

PARTE 2

Quadro 7.8

O Modelo

Relação de DFX (continuação)

Projeto para Confiabilidade (Design for Reliability, DFR): visa a identificação de fatores que influenciam a confiabilidade do produto. Dessa forma, projetistas podem modelar seus projetos de maneira a identificar, potenciais falhas e tornar o produto confiável. Projeto para Desmontagem (Design for Disassembly, DFD): engloba as técnicas de projetar visando a desmontagem do produto, preocupando-se também com o descarte dessas peças. Nesse método, ocorre uma ligação com conceitos de projeto para reciclagem. Projeto para Manutenabilidade (Design for Maintainability, DFMt): concentra-se no projeto para manter o produto em funcionamento durante seu ciclo de vida, levando em conta a manutenção, inspeção, reparo, padronização etc. Tem forte relacionamento com métodos que tratam da ergonomia, estética, confiabilidade e montagem. Projeto para Fatores Humanos: (Design for Manability): concentra-se na relação entre o homem e o equipamento. Assim, tem-se o envolvimento de fatores psicológicos (reações para com o meio ambiente, expectativas, necessidades etc) e antropométricos (dimensões físicas, humanas etc.). Em algumas literaturas é denominado também como Projeto para Ergonomia. Projeto para Mínimo Risco (Design for Minimum Risk): objetiva analisar em detalhe as incertezas a respeito do produto com base em informações técnicas e econômicas de fatores que poderão provocar algum distúrbio no produto, providenciando, assim, uma nova configuração e diminuição das incertezas. Projeto para Competição: (Design for Competition): trata diretamente de fatores envolvidos com o processo de desenvolvimento de produtos e a equipe de projeto. São abordados o uso de ferramentas como Análise dos Modos de Falhas e seus Efeitos (FMEA); Projeto para Montagem (DFA); QFD (Casa da Qualidade) e Priorização de Estratégias Ambientais (EPS), no sentido de implementá-las no processo de maneira eficiente, obtendo bons resultados. Projeto para Modularidade (Design for Modularity): é tido como um método sistemático de geração e seleção de conceitos modulares para produtos, utilizando, para isso, ferramentas como QFD, matriz de seleção de Pugh, método DFMA, entre outras. Projeto para Inspeção (Design for Inspectability): está voltado para o controle na manufatura do produto, sendo este um método que disponibiliza rápida e precisamente um feedback do controle do processo de fabricação. Projeto para Padronização (Design for Standards): tem por objetivo a unificação e a determinação de soluções por meio da limitação das possibilidades dessas, sem causar conflitos. Utiliza, para isso, normas nacionais ou internacionais para a padronização de elementos, componentes, materiais, procedimentos de testes etc. Projeto para Estética (Design for Aesthetics): este método trata da adequação entre função do produto e formas agradáveis, levando em conta áreas de engenharia, produção, vendas, distribuição, uso e descarte; sempre objetivando a estética do produto. Projeto para Armazenagem e Distribuição (Design for Storage and Distribution): trata de toda a questão da armazenagem e distribuição do produto. Compreende, também, alguns trabalhos na área de embalagens, envolvendo questões de como projetar visando a apresentação, segurança etc. do produto pela embalagem. Projeto para Mérito Técnico (Design for Technical Merit): método que suporta a tomada de decisões antes da realização das fases do processo de projeto. É tido como uma métrica para a previsão de riscos, limites de performance, confiabilidade e economia. Projeto para Compatibilidade Eletromagnética (Design for Electromagnetic Compatibility): tem por objetivo trabalhar com equipamentos eletrônicos, levando em conta as interferências eletromagnéticas que esses equipamentos podem gerar. Projeto para Segurança (Design for Safety): este trata da segurança do usuário do produto, ou seja, todas as questões voltadas à segurança (também atendendo a normas), que o produto deve fornecer para quem estiver envolvido com ele em seu ciclo de vida. Projeto para Auxílio na Logística (Design for Supportability): consiste no gerenciamento dos recursos, suprimentos, instalações, equipamentos etc., compondo todas as considerações necessárias para o projeto com um efetivo e econômico auxílio durante todo o ciclo de vida do produto.

Design for Manufacturability (DFM, Projeto para Manufatura) é uma abordagem que enfatiza aspectos da manufatura ao longo do processo de desenvolvimento do produto. O DFM é uma abordagem que visa chegar a um produto com baixo custo sem sacrificar a qualidade do produto. Além disso, é uma das práticas mais integrativas durante o desenvolvimento do produto. DFM no Projeto Conceitual

CAPÍTULO 7

Projeto Conceitual

271

O DFM está relacionado com o entendimento de como o projeto do produto interage com os vários componentes do sistema de manufatura, de maneira que os componentes que formarão o produto após a montagem sejam fáceis de ser fabricados. Assim, o projeto do produto e o projeto do processo não podem de modo algum ser tratados como entidades separadas. Portanto, para maximizar a qualidade das primeiras decisões de projeto e, por conseguinte, minimizar as mudanças de engenharia nas etapas subseqüentes, é necessário levar em conta as informações relativas às atividades do sistema de manufatura, tanto quanto possível, no começo do processo de projeto. O DFM já pode ser levado em conta na definição da arquitetura do produto e na análise dos SSCs, auxiliando a equipe de desenvolvimento a obter SSCs que tenham eficiente e elevada manufaturabilidade. O DFM auxiliará na definição inicial dos melhores processos de manufatura para os SSCs assegurando que a forma desses SSCs seja a mais adequada para os processos selecionados. Para qualquer componente, existem muitos processos que podem ser usados em sua manufatura. Para cada processo de manufatura, existem diretrizes que, se observadas, fornecerão componentes de elevada qualidade e com mínimo desperdício. Mais detalhes a respeito da seleção de processos são mostrados no Tópico 7.10, mais adiante, neste capítulo. Quadro 7.9

Princípios e Recomendações do Projeto para a Manufatura

A simplificação de componentes e do projeto do produto é uma boa oportunidade para reduzir custos e aumentar a qualidade. Entretanto, essas ações necessitam ser avaliadas caso sejam o caminho mais fácil para o desempenho da função do componente. Os princípios e métodos do DFM fornecem uma abordagem estruturada para a obtenção de projetos simplificados. A complexidade do produto pode ser bastante reduzida pela utilização de módulos para a montagem de produtos. Por meio de módulos padronizados, uma ampla variedade de produtos pode ser montada a partir de um número limitado de módulos, e dessa maneira, simplificando o projeto e o processo de manufatura. A simplificação e a padronização elevam a eficiência do projeto e da produção. Existe um grande número de princípios e recomendações propostos para a obtenção de alta qualidade, baixo custo, facilidade de automação e melhor manutenabilidade. Exemplos desses princípios e recomendações para o DFM são listados a seguir:

• Reduzir o número de componentes, diminuindo a possibilidade de componentes com defeito ou erros de montagem, para, assim, reduzir o custo total de fabricação e montagem dos produtos e aumentar as chances de automação do processo.

• Utilizar componentes e materiais padronizados, para facilitar as atividades de projeto, simplificar o almoxarifado e padronizar as operações de manipulação e montagem. Componentes comuns resultam em pequenos almoxarifados, custos reduzidos e alta qualidade. A aprendizagem do operador fica simplificada e tem-se uma grande oportunidade para automação, como resultado dos altos volumes de produção e padronização de operações.

• Projetar para a fácil fabricação por meio da seleção de processos compatíveis com os materiais. Deve-se selecionar materiais compatíveis com o processo de produção para minimizar o tempo de processamento sem deixar de atender às especificações funcionais. Evitar geometrias desnecessárias que irão envolver processamento extra e/ou ferramental mais complexo. Deve-se aplicar as recomendações apropriadas a cada processo de fabricação. Processamentos secundários — tais como: acabamento superficial, pintura, revestimentos, tratamentos térmicos e movimentação de material — devem ser evitados sempre que possível, pois podem ser tão dispendiosos quanto o processamento primário.

• Utilizar as características especiais dos processos. A equipe de projeto deverá identificar as capacidades especiais dos processos de fabricação que são aplicáveis ao seu produto e tirar vantagens deles. Por exemplo, na injeção de plásticos, as peças já saem com a coloração e a textura desejadas; na sinterização, as peças apresentam porosidades que podem ser aproveitadas para a retenção de lubrificantes, de forma a não ser necessária a introdução de buchas para o caso de mancais. Aproveitando-se as características especiais de certos processos, pode-se eliminar muitas operações adicionais e mesmo componentes separados.

• Considerar no projeto a facilidade para a verificação do produto e seus componentes, propiciando que os testes e inspeções ocorram da forma mais natural possível.

• Evitar tolerâncias estreitas além da capacidade natural do processo de manufatura. Apesar de os custos extras na fabricação de tolerâncias estreitas já serem bem documentados e discutidos, esse fato, muitas vezes, não é bem apreciado pelos projetistas. Os custos elevados de tolerâncias estreitas resultam nos seguintes aspectos: custos elevados de usi-

(continua)

272

PARTE 2

Quadro 7.9

O Modelo

Princípios e Recomendações do Projeto para a Manufatura (continuação)

nagem em razão da precisão necessária, operações extras, como retificação, polimento e lapidação, após o processamento inicial das peças, maior freqüência na afiação de ferramentas, ciclos de operação mais longos, mais refugos e serviços de recuperação de peças, mão-de-obra qualificada e treinamentos, materiais mais caros, maior investimento em equipamentos de metrologia e de testes.

• Projetar os produtos com “robustez”, para compensar incertezas na manufatura, testes e uso do produto. • Projetar de acordo com o volume esperado. Cada processo tem um volume econômico de produção. Assim, conhecendo-se o volume de produção de uma peça ou produto, deve-se adequar o projeto ao correspondente processo de fabricação, e dessa forma obter as vantagens do processo. Por exemplo, não se deve projetar uma peça para fundição em matriz, caso o seu volume de produção seja tão pequeno que o custo da matriz não possa ser amortizado.

• Projetar produtos modulares para facilitar a montagem. • Projetar para fácil serviço

Design for Assembly (DFA, Projeto para Montagem) tem por principal objetivo simplificar a estrutura do produto a fim de reduzir custos. Segundo Bakerjian (1992), o projeto para montagem também compõe o conhecimento científico, necessário à arte de projetar, como uma filosofia, um processo e uma ferramenta. Como filosofia consiste em examinar o projeto já na etapa conceitual com o objetivo de diminuir os custos do produto e amenizar a transição do desenvolvimento do produto até a montagem final, seguida de um melhoramento contínuo e produção ininterrupta de um produto de qualidade. Como processo consiste em criticar, a todo o momento, os métodos e as soluções adotadas tentando simplificar ou eliminar a montagem enquanto mantém o projeto flexível ao analisar e questionar a arquitetura do produto, o relacionamento entre os componentes, o número de componentes, os métodos de segurança e o processo de montagem. Ou seja, guia a exploração de novas formas de efetuar as tarefas de manufatura ao preparar a equipe de projeto a desafiar as soluções usuais e fazer sugestões a novas abordagens. Como ferramenta, consiste em obter informações sobre as várias alternativas de projeto ponderando-se características, tais como: o número total de componentes, a dificuldade de manipulação e inserção, e o tempo de montagem. As ferramentas de DFA auxiliam o projetista a entender partes ou concepções específicas no produto que requerem melhorias, por discriminar o efeito de cada parte na montagem total. Assim, o conhecimento proporcionado pelo DFA pode ser usado para síntese da qualidade embutida no produto com o emprego de seus princípios ao avaliar qualitativamente o quão simplificado é a arquitetura do produto e o relacionamento entre os componentes. O DFA na avaliação de determinada montagem, como também na análise de produtos, examina cada componente individualmente e a sua relação com os demais a fim de conhecer o produto em detalhes, desvendando os pontos fortes e fracos desse. Tais empregos apresentam-se úteis na comparação de produtos concorrentes (benchmarking); ação de grande serventia na fase de planejamento e desenvolvimento (Sousa, 1998). Na fase de Projeto Conceitual, catálogos de exemplos, com princípios e diretrizes, e listas de controle (checklists) são as ferramentas de maior aplicação e eficiência em termos do DFA. Na atividade de modelagem funcional, o DFA pode ser aplicado por meio do questionamento da decomposição das funções principais e pelos índices que medem a eficiência da montabilidade do produto. Os mesmos índices são usados na matriz de decisão na escolha das melhores concepções alternativas. O DFA, ainda, direciona o projeto para que o produto tenha um menor número de peças, cuja união seja mais eficiente, melhorando a qualidade. Além disso, pode-se obter as seguintes vantagens: DFA no Projeto Conceitual

n n

simplificação dos processos de montagem; redução das operações de manipulação;

CAPÍTULO 7

Projeto Conceitual

n n n n

273

possibilidade de maior padronização e modularização dos produtos; Menor número de passos e ajustes (set-ups) de processamento; menor quantidade de pontos/superfícies de encaixe; e redução de problemas de tolerância (stack-up).

Segundo Sousa (1998), projetos simplificados obtidos com o uso das técnicas do DFA muitas vezes resultam em uma redução no custo dos componentes, significativamente maior que no custo de montagem. O projeto de fixações usadas na montagem também se torna mais simples. No projeto para montagem, outros aspectos são também considerados, tais como: projeto para a flexibilidade, racionalização funcional, processos de alimentação, aperto e inserção, e suas relações estruturais. A equipe de projeto realiza decisões envolvendo: n n n n n n n

a arquitetura do produto; o número de componentes; a geometria dos componentes; os métodos de união; as tolerâncias de montagem; composição de superfícies; e materiais.

A interdependência desses parâmetros também influi na determinação do método e tipo de montagem. As possibilidades de suprir um componente são restritas pela sua geometria. A geometria e as tolerâncias limitam o nível de automação — com o qual é possível dentro do custo-meta. A estrutura e o projeto das linhas de montagem são enormemente influenciados pela estrutura do produto. As instalações e as ferramentas necessárias são determinadas pelo método de montagem e pela forma das partes. Segundo Sousa (1998), o DFA procura racionalizar a estrutura do produto buscando o grau máximo de qualidade. Essa racionalização permite inclusive uma melhor racionalização operacional das empresas, aumentando também a produtividade, já que provoca a utilização das capacidades dos processos individuais de fabricação até o seu máximo em ordem de manter a estrutura do produto o mais simples possível. Outras vantagens e contribuições do DFA são: n n

n

n n

n n n

simplificação do produto pela redução de componentes individuais; possibilidade de fazer estimativas do custo de montagem e, posteriormente, estimar o custo dos componentes; fornece um procedimento sistemático para analisar um projeto proposto pelo ponto de vista da montagem; estimula a engenharia simultânea; redução maior nos custos de manufatura, tanto para pequenos volumes de produção quanto para altos volumes; redução dos custos gerais (overhead costs); estabelece uma base de dados de tempos de montagem e fatores de custos; e redução dos problemas associados à variação dimensional e funções das submontagens ou componentes em máquinas complexas.

O DFA surgiu a partir do conceito de Design for Manufacturing and Assembly (DFMA, Projeto para Manufatura e Montagem) decorrente da necessidade de reprojetar produtos para a automatização da montagem quando a automação da pro-

DFA versus DFM

274

PARTE 2

O Modelo

dução era a questão central das empresas em busca da competitividade, e da dificuldade de transmitir o ponto de vista do chão de fábrica para os membros da equipe de projeto. Sua importância cresceu e tornou-se uma metodologia complementar ao Design For Manufacturability (DFM, Projeto para Manufatura) — Sousa (1998). As diferenças básicas que ajudam a compreender melhor a metodologia de projeto para montagem são mostradas a seguir. No geral, o DFA enfoca: n n n n

a consolidação dos componentes; a montagem vertical com o auxílio da gravidade; o uso de características de orientação e inserção nas partes; e a revisão do Projeto Conceitual por meio do consenso da equipe de projeto (promove a Engenharia Simultânea).

Já o DFM: n

n

compara o uso de diferentes combinações de materiais e processos de fabricação selecionados para as partes de uma montagem; e determina o impacto no custo com o uso desses materiais e processos.

Ou seja, o DFM analisa cada componente em separado e tende a recomendar partes de formas simples em substituição a um componente de forma geométrica complexa, achando o mais eficiente uso da geometria do componente com relação ao processo de fabricação, e, em geral, ocasionando um aumento do número de componentes. Por outro lado, o DFA avalia todo o produto, não apenas as partes individualmente, buscando simplificar a arquitetura do produto e objetivando o mais eficiente uso da função do componente. A busca pela redução do número de componentes — principalmente os não-essenciais, como fixadores não integrais (parafusos, rebites, molas etc.) — leva a equipe de projeto a desafiar os limites impostos pelos materiais e processos disponíveis e a buscar novas soluções. Considerando que, no processo de projeto de um produto, existe uma intensa relação de função com a forma, os materiais e os processos de produção selecionados, e, nesse último, incluem-se os processos de fabricação e montagem, conforme mostra a Figura 7.33(a), a abordagem do DFM enfoca prioritariamente os aspectos da relação entre a forma, o material e processo de fabricação de um componente, conforme mostra a Figura 7.33(b). Diferentemente, o DFA engloba o relacionamento entre a(s) função(ões) do produto com a forma de seus componentes, seus materiais e o processo de montagem, conforme mostra a Figura 7.33(c). Figura 7.33

Relacionamentos entre função, forma, material e processo.

CAPÍTULO 7

Projeto Conceitual

Quadro 7.10

275

Princípios e Recomendações do Projeto para a Montagem

A idéia básica no projeto para a montagem é, primeiro, reduzir o número de componentes (partes e peças) que devem ser montados, e, então, assegurar que os componentes remanescentes sejam fáceis de montar e fabricar, reduzindo o custo total da montagem, e também satisfazer as especificações funcionais. Os princípios que norteiam o projeto para a montagem são: 1. Simplificar, integrar e reduzir o número de peças, pois cada peça constitui uma oportunidade para defeitos ou erros de montagem. Poucas peças resultam em um menor esforço na manufatura de um produto. Isso inclui itens tais como: tempo de engenharia, número de desenho e de peças; documentos de inventário e controle de produção; número de ordens de compra e venda, número de embalagens, contêineres, locação de estoques e paletes; quantidade de equipamentos de manipulação de materiais, quantidade de detalhes de contabilidade e cálculos; catálogos e serviços; número de itens de inspeção e tipo de inspeção necessário; e quantidade e complexidade dos equipamentos e facilidades de produção, montagem e treinamento. 2. Padronização e uso de partes comuns e materiais para facilitar as atividades de projeto, minimizar o inventário e padronizar a manipulação e as operações de montagem. Partes comuns reduzem o inventário, os custos e melhoram a confiabilidade. O aprendizado do operador é simplificado e tem-se uma boa oportunidade de automação em função dos grandes volumes de produção e padronização das operações. 3. Projetar produtos e montagem à prova de erros, de modo que o processo de montagem seja não ambíguo. Os componentes devem ser projetados para somente ser montados em uma direção. Chanfros, furos assimétricos e batentes podem ser usados para impedir montagens incorretas. Os produtos devem ser projetados para evitar ajustes. 4. Projetar partes que minimizem o esforço e a ambigüidade nas orientações e manipulações. As partes devem ser projetadas para ter orientação própria quando alimentadas em um processo. O projeto do produto deve evitar partes que se tornem emaranhadas, “encunhadas” ou desorientadas. O projeto das partes deve incorporar simetria, baixo centro de gravidade, detalhes facilmente identificáveis, superfícies guias e pontos que facilitem a captação e manipulação. Esse tipo de projeto pode permitir o uso de automação na manipulação e montagem de partes, através de transportadores vibratórios, tubos, magazines, robôs e sistemas de visão. 5. Minimizar partes flexíveis e interconexões. Evitar partes flexíveis e frágeis, tais como: correias, gaxetas, tubulações, cabos e armações de arame. A flexibilidade torna difícil a manipulação do material e a montagem, tornando as partes mais suscetíveis a danos. 6. Projetar para a fácil montagem pela utilização de movimentos simples e minimização do número de eixos de montagem. Orientações complexas e movimentos de montagem em várias direções devem ser evitados. Partes devem incluir detalhes como chanfros. O projeto do produto deve propiciar que a montagem comece com um componente-base, com massa relativamente grande e baixo centro de gravidade, sobre a qual outras partes serão adicionadas. A montagem deverá ser procedida verticalmente com outras partes adicionadas no topo e posicionadas com auxílio da gravidade. Isso minimiza a necessidade de reorientar a montagem e reduz a necessidade de uniões temporárias e fixações complexas. Um produto que é fácil de montar manualmente, em geral será mais fácil de ser montado com automação. 7. Projetar para união e fixação eficientes. Parafusos, porcas e arruelas consomem muito tempo na montagem e são difíceis de automatizar. Nos lugares em que eles devem ser usados, deve-se utilizar a padronização para minimizar a variedade; e nos lugares em que não o são, utilizar conectores do tipo engate rápido, snaps e adesivos. Deve-se ter em mente que cada elemento de fixação é mais um componente a ser armazenado, manipulado e posicionado; que os elementos de fixação não são baratos; e que os elementos de fixação são concentradores de tensões. Não existem regras para a qualidade de um projeto com relação ao número de elementos de fixação separados. Obviamente, um excelente projeto terá poucos elementos de fixação separados, e os existentes serão padronizados. Projetos pobres, por outro lado, necessitam de vários e diferentes elementos de fixação para a sua montagem final. Se mais do que 1/3 dos componentes de um produto são elementos de fixação, a montagem deverá ser questionada. 8. Projetar produtos modulares para facilitar a montagem. Um projeto modular deve minimizar o número de partes e as variações de montagens e processos de manufatura, enquanto produz um grande número de variantes do produto durante a montagem final. Esse procedimento minimiza o número total de itens a serem manufaturados, conseqüentemente reduzindo os itens de controle e melhorando a qualidade. Módulos podem ser manufaturados e montados em paralelo para reduzir o tempo global de produção do produto, e são mais facilmente testados antes da montagem final.

276

PARTE 2

7.7

O Modelo

Definir ergonomia e estética do produto

A maioria dos produtos funciona em coordenação com as pessoas. A ergonomia está relacionada com as características, habilidades, necessidades das pessoas e, em especial, com as interfaces entre as pessoas e os produtos. As quatro formas básicas de interações das pessoas com os produtos são: pelo espaço de trabalho ocupado em torno do produto; como fonte de potência para o produto; atuando como um sensor, e atuando como um controlador. Essas quatro formas de interação entre pessoas e produtos formam a base de estudo dos chamados fatores humanos, que desempenham um importante papel na atividade de projeto de produtos. Assim, os fatores humanos devem ser levados em conta para toda a pessoa que entrar em contato com o produto, quer seja na etapa de manufatura, como nas etapas de operação, manutenção e reparo, e descarte. Além disso, os fatores humanos estão fortemente relacionados com a qualidade e a segurança do produto. Como principal atributo da qualidade, deseja-se que o produto funcione como esperado. Isso significa uma expectativa de que os produtos possam ser usados de maneira confortável, ou seja, deverá existir uma boa compatibilidade entre o produto e o usuário dentro do espaço de trabalho. Espera-se que os produtos sejam fáceis de usar, ou seja, necessitem de uma mínima potência para seu acionamento. Espera-se, ainda, que os produtos possam ser facilmente sensoreados e que seu controle seja lógico e amigável. Com relação à segurança, normalmente produtos considerados inseguros não são vistos como produtos de qualidade. De fato, espera-se que nenhum dos usuários possa vir a ser ferido e nenhuma das propriedades do produto venha a ser destruída com o uso do produto (exceto quando o produto é projetado para tal). Para obter-se um projeto adequado em termos de ergonomia, deve-se considerar as seguintes recomendações (Magrab, 1997): A interação entre o produto e pessoas

n

n

n

Adequar o produto às características físicas e ao conhecimento do usuário. Evitar que o usuário tenha que exercer movimentos e forças extremos e complicados. Usar convenções, SSCs e arranjos normalizados. Simplificar e reduzir as tarefas necessárias para a operação do produto. Os controles e suas funções deverão ser óbvios; e as informações operacionais deverão ser claras, visíveis e não ambíguas. Prever os possíveis erros humanos, implementar restrições para prevenir ações incorretas por parte do usuário, e informar ao usuário que determinados modos de operação foram selecionados.

No projeto ergonômico de produtos, deve-se, ainda, considerar a idade, gênero, alcance, destreza, força e visão dos usuários. Problemas de ergonomia associados ao projeto do produto podem afetar o sistema de manufatura que produz o produto. Algumas características do produto que influenciam a ergonomia do sistema de manufatura são: n n n n n

Fragilidade e peso dos componentes. Tamanho, quantidade e torque de aperto dos elementos de fixação. Posição e localização das superfícies. Acessibilidade e folga dos componentes. Identificação e diferenciação de componentes.

Quadro 7.11

Ergonomia

O termo ergonomia deriva do grego ergon (trabalho) e nomos (regras). Sua origem remonta à Segunda Guerra Mundial, em que fisiologistas, psicólogos, antropólogos médicos e engenheiros trabalharam em conjunto para resolver os problemas causados pela operação de máquinas complexas, sendo os resultados obtidos de tal interação aproveitados pela indústria durante o pós-guerra (Dul & Weerdmeester, 1995).

(continua)

CAPÍTULO 7

Projeto Conceitual

Quadro 7.11

277

Ergonomia (continuação)

Existem duas escolas distintas em ergonomia, porém complementares. A primeira delas, denominada ergonomia física, aborda a interação homem—sistema em questão em termos de conforto físico, tratando de aspectos antropométricos (dimensões do corpo humano, postura, movimentos e esforços) e ambientais do trabalho (ruídos, vibrações, iluminação, clima, substâncias químicas etc.). As ferramentas utilizadas por essa escola de ergonomia incluem uma série de regras, quadros e tabelas, os quais definem as condições mais adequadas ou confortáveis para a realização do trabalho. A segunda escola, a ergonomia cognitiva, aborda a interação homem—sistema por meio da análise da troca de informações (em ambas as direções) entre o operador e o sistema. Nesse caso, a ergonomia não enxerga somente o sistema do ponto de vista do operador, mas também a interação entre eles e as reações dessas interações. Dessa forma, a ergonomia cognitiva atua na definição da melhor forma de transmitir e receber tais informações, de forma a atingir o objetivo desejado. As principais ferramentas utilizadas por essa escola são os chamados modelos cognitivos, os quais descrevem de forma qualitativa os diferentes modos de processamento de informações (divididas em performance baseada em habilidades, em regras e em conhecimentos) de uma pessoa em um ambiente de trabalho.

Fonte: CAÑAS, J. J. Ergonomía Cognitiva. Alta dirección, v.. 227, p. 66-70.

Os produtos não deverão somente atender às funções técnicas definidas na esA beleza também é trutura de funções, mas também ser esteticamente agradáveis para os clientes. A esfundamental tética é uma parte fundamental dos produtos, pois é o que normalmente atrai o consumidor para a compra, despertando o sentido visual e o desejo da aquisição. A estética do produto está ligada a tudo aquilo que o consumidor percebe, do ponto de vista da aparência, como a configuração das formas, das superfícies e das cores, predominando os aspectos relacionados à beleza. Os principais atributos estéticos de um produto são: o estilo e a mensagem simbólica e semântica do produto. Segundo Baxter (1998), o estilo de um produto a ser desenvolvido ou em desenvolvimento é influenciado pelos produtos antecessores, pela marca ou identidade da empresa, pelo estilo dos concorrentes e pelo benchmarking do estilo. Quando for o caso de reprojetar um produto já existente e bem-sucedido no mercado, e se não houver nenhuma exigência nova do mercado, é recomendável que se mantenha a identidade visual do produto anterior, possibilitando o reconhecimento visual pelos compradores habituais e, conseqüentemente, a compra. Logotipo, nome da empresa, combinações de cores e formas, embalagens, disposição de detalhes e outras características servem para identificar o produto no mercado. Empresas que possuem uma imagem positiva no mercado devem preservar essa identidade e passá-la aos consumidores por meio do produto. Novas empresas ou empresas que entram em um determinado mercado já existente podem seguir tendências de estilo adotadas por empresas já estabelecidas nesse mercado. De qualquer forma, é muito importante a análise das características que determinam a identificação dos produtos já existentes no mercado. O benchmarking do estilo, a partir da observação das cores, materiais, acabamentos superficiais, detalhes e formas dos produtos existentes, permitirá que se possa verificar quais são as tendências de estilo para o produto. O simbolismo do produto consiste na identificação ou relacionamento dos valores sociais e pessoais dos consumidores, com o estilo do produto. Os valores sociais estão ligados ao estilo de vida dos consumidores.

278

PARTE 2

O Modelo

O simbolismo do produto está ligado aos valores sociais e pessoais do consumidor e seu relacionamento com o estilo do produto. Assim, é importante que seja identificado o estilo de vida dos consumidores em potencial e quais as características que os consumidores mais valorizam nos produtos. A semântica do produto está relacionada com tudo aquilo que o produto quer comunicar. O tratamento desses atributos estéticos do produto são os temas tratados pela área conhecida como design ou como desenho industrial. Na verdade, os profissionais dessa área tratam de temas mais amplos, como descrito no Quadro 7.12. Quadro 7.12

Definição de Design ou Desenho Industrial

Em muitos países, existe a dificuldade de traduzir o termo design. Essa palavra possui muitos significados, pois é um anglicismo incorporado à língua portuguesa, em decorrência da falta de traduções capazes de exprimir o correto sentido da ação, bastante diferente de desenho — embora a representação gráfica seja parte imprescindível de seu exercício. No dicionário Michaelis, design é definido como “1. Planejamento ou concepção de um projeto ou modelo. 2. O produto desse planejamento”. 2 No site da Associação de Designers de Produto (ADP) , adota-se a seguinte definição de design, — utilizada pelo Conselho 3 Internacional de Sociedades de Desenho Industrial (ICSID) : Design é uma atividade criativa cuja finalidade é estabelecer as qualidades multifacetadas de objetos, processos, serviços e seus sistemas, compreendendo todo seu ciclo de vida. Portanto, design é o fator central da humanização inovadora de tecnologias e o fator crucial para o intercâmbio econômico e cultural. O design procura identificar e avaliar relações estruturais, organizacionais, funcionais, expressivas e econômicas, visando:

• ampliar a sustentabilidade global e a proteção ambiental (ética global); • oferecer benefícios e liberdade para a comunidade humana como um todo, usuários finais individuais e coletivos, protagonistas da indústria e comércio (ética social);

• apoiar a diversidade cultural, apesar da globalização do mundo (ética cultural); e. • dar aos produtos, serviços e sistemas formas que expressem (semiologia) e sejam coerentes com (estética) sua própria complexidade. O design diz respeito a produtos, serviços e sistemas concebidos a partir de ferramentas, organizações e lógica introduzidas pela industrialização — não apenas quando produzidos por meio de processos seriados. O adjetivo “industrial” associado ao design deve relacionar-se ao termo indústria, ou no seu sentido de setor produtivo, ou em seu sentido mais antigo de “atividade engenhosa, habilidosa”. Assim, o design é uma atividade que envolve um amplo espectro de profissões nas quais produtos, serviços, gráfica, interiores e arquitetura, todos participam. Juntas, essas atividades deveriam ampliar ainda mais — de forma integrada com outras profissões relacionadas — o valor da vida. O design tem como resultado final a configuração de um produto. Constitui-se um importante valor para quem cria e para quem possui o direito de o produzir, vender e divulgar. A lei que regulamenta a profissão de designer no Brasil compreende duas categorias básicas do design: industrial e gráfico. “O design é uma atividade especializada de caráter técnico-científico, criativo e artístico, com vistas à concepção e desenvolvimento de projetos de objetos e mensagens visuais que equacionem sistematicamente dados ergonômicos, tecnológicos, econômicos, sociais, culturais e estéticos, que atendam concretamente às necessidades humanas. Assim sendo, constitui-se um elemento fundamental para agregar valor e criar identidades visuais para produtos, serviços e empresas, definindo, em última análise, a personalidade das empresas no mercado. O design, em geral, é classificado em duas categorias básicas: Design Industrial: relaciona-se com as áreas de bens de consumo, de capital, máquinas e equipamentos, construção civil e ambiente. Design Gráfico: compreendendo a elaboração de logotipos, imagens corporativas, sinalização, editoração, impressos em geral, vídeos, entre outros. Alguns especialistas separam ainda a categoria de Design de Embalagens, pela especificidade do conhecimento técnico envolvida nessa área. Informações retiradas de http://www2.ciesp.org.br/detec1/design/conceito.htm. Acessado em: 15/2/2005.

2 3

Veja http://www.adp.organização.br. Acessado em: 15/2/2005 Veja http:// www.icsid.org. Acessado em: 15/2/2005

CAPÍTULO 7

Projeto Conceitual

7.8

279

Definir fornecedores e parcerias de co-desenvolvimento

Conforme colocado no Capítulo 2, o envolvimento dos fornecedores no desenvolvimento de produtos é um dos fatores responsáveis pela melhora do desempenho desse processo em termos de produtividade, velocidade e qualidade do produto. A definição de parcerias de co-desenvolvimento pode ocorrer durante toda a fase de Projeto Conceitual do produto. No momento da definição inicial dos SSCs, é possível fazer uma escolha inicial das parcerias e fornecedores. Para tal escolha, sugere-se que sejam considerados os seguintes critérios: A definição de parcerias de co-desenvolvimento pode ocorrer durante toda a fase de Projeto Conceitual do produto. No entanto, tal qual ressaltado na Figura 7.1, é durante a atividade de análise dos SSCs que serão identificadas o maior número de possibilidades de tais parcerias, sendo os parceiros formalmente definidos durante a atividade de seleção de concepções alternativas. A seguir são apresentadas algumas questões para auxiliar na definição dos fornecedores e parceiros. a) Perfil da empresa • Solidez: O fornecedor possui uma situação estável e vontade de investir em longo prazo? • Habilidade global: O fornecedor consegue suportar a empresa dentro da área geográfica em que a empresa opera? O fornecedor pode atuar em diferentes atividades do PDP, tais como: desenvolvimento, produção, lançamento entrega e distribuição? • Dependência: Qual é o volume de negócio com relação aos clientes do fornecedor e qual o tamanho e a importância desse negócio para o fornecedor? A dependência será grande ou pequena? Qual a estrutura de clientes que tem fornecedor? b) Gerenciamento • Gestão: O fornecedor utiliza procedimentos modernos de trabalho — por exemplo: equipes multifuncionais e planos de negócio em longo prazo? • Satisfação do cliente: O fornecedor faz uso de procedimentos eficazes para monitorar a satisfação do cliente? • Procedimentos de TQM: O uso dos critérios para premiações da qualidade no próprio desenvolvimento da qualidade. • Gerência de risco: O fornecedor possui conhecimento e utiliza procedimentos nesse campo? Pode incorporar riscos nos processos produtivos, como planos de contingência, proteção contra fogo? Pode incorporar riscos ambientais e perigos administrativos, como problemas em sistemas computadorizados e de comunicação? c) Meio ambiente • Sistema de gestão ambiental: O fornecedor é certificado e aplica o sistema de gestão ambiental de acordo com a ISO 14001? • Avaliação ambiental da empresa: Como o fornecedor está sendo avaliado em termos das suas práticas, produtos e serviços? d) Qualidade • Sistema de qualidade: O fornecedor está certificado e aplica um sistema de gestão da qualidade de acordo com as normas específicas do seu setor de atuação? • Planejamento da qualidade: O fornecedor possui e aplica um procedimento para o planejamento da qualidade, incluindo o uso de métodos como FMEA e teste de capabilidade? • Confiabilidade: O fornecedor acompanha a qualidade dos produtos finais e a influência de seus produtos com relação à garantia, freqüências de falhas, reclamações de cliente etc.? • Resolução de problemas: O fornecedor possui um procedimento formalizado e eficaz para a resolução de problemas?

280

PARTE 2

O Modelo

e) Logística • Sistema logístico: O fornecedor aplica um sistema para o gerenciamento logístico do material que entra, do controle de produção e da distribuição? • Precisão na entrega: O fornecedor é capaz de satisfazer as exigências em termos de tempo de quantidade de entrega. • Flexibilidade: O fornecedor é capaz de se adaptar a mudanças e novas programações de entrega? f) Pós-mercado • Documentação: O fornecedor tem capacidade e vontade de auxiliar a empresa com documentação técnica do produto, inclusive apontando as responsabilidades do fornecedor no projeto? • Literatura de apoio: O fornecedor é capaz de auxiliar na elaboração de manuais de operação e manutenção? • Cooperação: O fornecedor é capaz de fornecer partes sobressalentes em um prazo específico? Manterá os preços estáveis e apoiará os trabalhos pós-mercado? • Garantia: Qual é o tempo e a extensão de garantia que o fornecedor pode oferecer? g) Competência • Tecnologia industrial e de produto: Qual é o conhecimento que o fornecedor tem do produto? Dos sistemas funcionais, de pesquisa e desenvolvimento e dos processos industriais? Qual é a competência interna de desenvolvimento que o fornecedor possui? • Engenharia industrial: Quais são os padrões que o fornecedor possui com relação aos meios da produção, locais da produção, equipamentos, máquinas, ferramental e controle de produção. • Apoio e comunicação com o cliente: O fornecedor pode oferecer serviços, apoio, presença e velocidade de resposta? • Comunicação eletrônica: O fornecedor utiliza a Internet para enviar e receber mensagens? h) Desenvolvimento de produto • Apoio ao processo do desenvolvimento de produtos: Qual é a estrutura que o fornecedor possui em termos de desenvolvimento de produtos, incluindo recursos para pesquisa, engenharia do produto, verificação (testes) e validação? • Experiência de engenharia: O fornecedor possui experiência de engenharia devidamente documentada? • Tecnologia em engenharia do produto: O fornecedor faz uso de tecnologias modernas, apoio computacional (CAE/CAD) e linhas de comunicação desenvolvidas? • Protótipos: O fornecedor é capaz de fornecer protótipos dentro do prazo estipulado e com uma confiável relação com o padrão de produção em massa? • Pesquisa e desenvolvimento: Quais os recursos existentes para P & D e qual a política da empresa? • Mudanças de projeto: O fornecedor faz uso de procedimentos de controle, incluindo todas as atividades necessárias para as mudanças de projeto? i) Produtividade • Processo interno de redução de custos: O fornecedor é capaz de conduzir uma racionalização tanto no produto quanto na manufatura? É capaz de utilizar métodos de medição de desempenho e melhoramento de seus processos? • Custos-meta: O fornecedor é capaz de trabalhar de modo cooperativo para a determinação e monitoramento dos custos-meta? j) Compras • Processos de fornecimento: O fornecedor é capaz de conduzir um processo efetivo de avaliação, seleção, fixando requisitos e desenvolvendo seus próprios fornecedores?

CAPÍTULO 7

Projeto Conceitual

281

• Desempenho dos subcontratados: O fornecedor é capaz de proceder um acompanhamento e avalia-

ção sistemática dos fornecedores secundários (ou subfornecedores) com relação à qualidade, precisão de entrega, cooperação e taxa de melhoria? Vale destacar que os parceiros serão formalmente definidos durante a atividade de seleção de concepções alternativas.

7.9

Selecionar a concepção do produto

O objetivo principal dessa atividade é o de escolher, dentre as concepções geradas pelas atividades anteriores, o melhor desses conceitos — o qual será transformado no produto final. A principal dificuldade envolvida nessa tarefa encontra-se na principal característica da fase de Projeto Conceitual: informações técnicas ainda limitadas e abstratas. Portanto, se faz necessária a utilização de métodos ou procedimentos sistemáticos, compatíveis com a limitação de informações, e que auxiliem na tomada de decisão quanto à seleção da melhor concepção. A Figura 7.34 mostra as tarefas desta atividade. Figura 7.34

Tarefas da atividade “Selecionar a concepção do produto”.

É importante notar que o termo seleção ou escolha, aqui utilizado, implica ações de valoração, comparação e tomada de decisão. Como essas ações são fortemente inter-relacionadas, para se obter o maior número de informações para a tomada de decisão, os conceitos devem ser valorados de forma compreensiva, cobrindo um amplo espectro de objetivos, e também ser expressos na mesma linguagem e no mesmo nível de abstração. Existem dois tipos possíveis de comparação: absoluta e relativa. Na comparação absoluta, cada conceito é diretamente comparado com algum tipo de informação, conhecimento, experiência e, dependendo do caso, alguns requisitos. O segundo tipo é caracterizado pela comparação dos conceitos entre si. Uma das maneiras mais usuais para a avaliação das várias alternativas de concepção geradas é utilizando-se uma matriz, na qual as alternativas e os critérios de avaliação são colocados na primeira linha e primeira coluna,

282

PARTE 2

O Modelo

respectivamente. Esse método é conhecido como Método de Pugh ou Método da Matriz de Decisão (veja a Figura 7.35). Os critérios de avaliação podem ser algumas ou todas as especificações-meta, e, para os casos em que as concepções geradas estão representadas com um nível elevado de abstração, as necessidades dos clientes podem ser tomadas como critérios. Além desses, poderão ser adicionados outros critérios relacionados a outros aspectos, tais como: estética do produto e parcerias de co-desenvolvimento. Nesse método, uma das concepções geradas é escolhida como referência, e todas as outras concepções são comparadas com essa referência. Para cada critério de avaliação, o julgamento poderá indicar que a concepção é “melhor que”, “igual a” ou “pior que” a concepção de referência. Ao final desse processo, um escore é montado para cada concepção alternativa (coluna). Para os critérios em que uma dada concepção for considerada “melhor que”, atribui-se um “+”, para cada critério. Da mesma forma, para o critério que for julgado como sendo “igual a” referência, atribui-se um “S”; e, para o critério que obtiver um “pior que”, tem-se um “–”. As concepções que obtiverem o escore numérico mais alto, ou o maior número de (+) que excede o número de (–) deverão ser consideradas como mais adequadas. Figura 7.35

Modelo de Matriz de Decisão. Concepções Concepção 1

Critérios

Concepção 2 (referência)

Critério 1

0

Critério 2

0

Critério 3

Concepção 3

...

...

Concepção m

0

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

Critério n

0

Total +

0

Total –

0

Total Global

0

Os escores não devem ser tratados como medidas absolutas do valor das concepções, e, sim, como uma orientação. Os escores obtidos podem ser interpretados da seguinte forma: n

n

n

Se uma concepção ou grupo dessas tem um bom total global ou um grande número de escores “+”, é importante identificar quais aspectos dessa concepção são melhores que os da referência. Da mesma maneira, os escores “–” mostrarão quais as necessidades especialmente difíceis de ser atendidas. Se várias concepções obtêm o mesmo escore para um dado critério, deve-se examinar cuidadosamente esse critério. Pode ser que seja necessário um desenvolvimento maior na área de conhecimento desse critério para que sejam geradas concepções melhores. Também pode ser o caso do critério ser ambíguo, ou seja, poder ser interpretado de diferentes maneiras. Se o critério tiver baixa importância, não se deve despender muito esforço para clarificá-lo. Entretanto, se o critério é importante, devem ser empregados esforços e recursos ou para gerar novas concepções ou para clarificar o critério. Para conhecer mais o problema, deve-se refazer as comparações utilizando a concepção com o mais alto escore, como sendo a nova referência. Essa iteração deverá ser feita até que claramente surja o melhor conceito.

CAPÍTULO 7

Projeto Conceitual

283

Entretanto, existem dois aspectos importantes a serem considerados: o primeiro é que o “+” e o “–” não dão indicação de quanto melhor ou quanto pior do que a referência é a concepção para determinado critério de avaliação. O segundo é que os critérios de avaliação não são igualmente importantes. Assim, pode-se utilizar a matriz mostrada na Figura 7.36, que considera um peso para cada critério de avaliação. O peso total é a soma de cada escore multiplicado pelo peso de importância de cada necessidade. Um S conta como 0, um “+” como +1 e um “–”como –1. Figura 7.36

Modelo de Matriz de Decisão com o peso dos critérios. Concepções Peso

Critérios

Concepção 1

Concepção 2 (referência)

Concepção 3

...

...

Concepção m

Critério 1

P1

0

Critério 2

P2

0

Critério 3

P3

0

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

Critério n

Pn

Peso Total

0 0

Durante a fase de Projeto Conceitual, diferentes testes podem ser realizados conforme mostra a Figura 7.37 e servem para várias tomadas de decisão, inclusive para a seleção de concepções. Cada método de teste possui seus objetivos, abordagem e tipos de modelagem. Os quatro tipos de testes mais gerais são: testes exploratórios, testes de avaliação, testes de validação e testes de comparação. A seguir, esses testes serão descritos com mais detalhes. Figura 7.37

Tipos de testes.

Os testes exploratórios podem ser realizados no início do processo, ainda na fase de planejamento, quando o Escopo do Produto ainda está sendo definido e potenciais soluções estão sendo consideradas. O ideal é que o Time de Desenvolvimento tenha um bom conhecimento do perfil dos usuários e das necessidades dos clientes. O objetivo desses testes é examinar e explorar o potencial de possíveis idéias do produto e responder a algumas perguntas do tipo: O que os usuários pensam sobre o uso do conceito?; As funcionalidades básicas das idéias possuem valor para os usuários?; A interface com o usuário é adequada e operável?; Como o usuário se sente com relação à idéia?; As hipóteses e considerações sobre os clientes estão corretas?; Algum dos requisitos foi entendido erroneamente?

284

PARTE 2

O Modelo

Esse tipo de análise inicial é potencialmente mais crítico que todos os tipos de prototipagem e avaliações, uma vez que se o desenvolvimento é baseado em considerações incorretas sobre as necessidades dos clientes — inevitavelmente, mais tarde, os problemas aparecerão. Dados obtidos a partir de observação, entrevistas e discussões tenderão a ser qualitativos. O ideal é que os usuários usem o produto sem treinamento ou preparação, para avaliar o produto. Algumas medidas quantitativas podem ser utilizadas, tais como: o tempo para realizar uma tarefa, número de falhas ou erros de operação. Os testes de avaliação envolvem a análise mais detalhada de soluções específicas já em um ponto ligeiramente mais adiante no desenvolvimento do produto. O principal objetivo de um teste de avaliação é assegurar que as escolhas de projeto sejam apropriadas diante das considerações iniciais. Os testes de avaliação tenderão a forçar sobre a usabilidade ou o nível de funcionalidade oferecido, e, em alguns casos, pode ser apropriado para avaliar níveis iniciais de desempenho. Assumindo-se que a concepção escolhida é a correta, o teste de avaliação assegurará que ela está sendo implementada adequadamente e responderá a questões mais detalhadas como: A concepção é utilizável?; A concepção satisfaz a todas as necessidades dos clientes?; Como a concepção será montada e testada?; Poderá o usuário completar todas as tarefas conforme desejado? Testes de avaliação normalmente necessitam de modelos mais complexos ou detalhados que nos testes exploratórios. Uma combinação de modelos analíticos, simulações e mock-ups (não necessariamente na forma final) poderá ser usada. O processo de avaliação é relativamente informal, incluindo os clientes internos e externos. As informações obtidas são tipicamente qualitativas e baseadas na observação, discussão e entrevistas. Os testes de validação normalmente realizados mais no final do processo de desenvolvimento servem para verificar se todas as especificações-meta do produto foram alcançadas. Podem incluir usabilidade, desempenho, confiabilidade, manutenabilidade, montagem e robustez. Os testes de validação servem para verificar a funcionalidade e o desempenho da versão que será produzida. Normalmente, o teste de validação é a primeira oportunidade de avaliar o produto como um conjunto formado pelos vários componentes, mesmo que esses tenham sido testados individualmente. Portanto, o produto deverá ser representado o mais próximo possível da sua forma final, incluindo embalagem e documentação de processo. Também se inclui dentro dos testes de validação qualquer avaliação formal necessária para certificação, segurança ou requisitos legais. Comparando-se com os testes de avaliação, esses testes têm como mais ênfase a experimentação rigorosa e consistente. Os dados oriundos desses testes são predominantemente quantitativos, baseados na medição do desempenho. Em geral, esses dados são confrontados com o desempenho esperado. Aspectos de usabilidade poderão ser colocados em termos de velocidade, precisão ou taxa de uso, mas sempre na forma de dados quantitativos. Os testes comparativos podem ser realizados em qualquer estágio do processo de projeto, para comparar uma concepção, produto ou elemento do produto contra alguma alternativa. Essa alternativa pode ser uma solução existente ou uma alternativa de projeto. Testes comparativos podem incluir a captura de ambos — desempenho e dados de preferência — para cada solução. Esses testes podem ser usados para estabelecer uma preferência, determinar superioridade ou para o entendimento das vantagens e desvantagens de diferentes alternativas de solução e/ou concepção.

7.10 Definir plano macro de processo O principal objetivo dessa atividade é a identificação de possíveis processos de fabricação dos SSCs, identificando também o ferramental envolvido em tais processos. Os fatores ligados aos processos de manufatura, ao serem considerados adequadamente no projeto, garantem que os projetos finais sejam “produzíveis” e que os processos de produção sejam desenvolvidos com as necessidades de longo prazo do produto em mente. Normalmente existe mais de um método que pode ser utilizado para a fabriSeleção de processos de cação de um componente para um determinado material. As grandes categorias de fabricação métodos de processamento de materiais são:

CAPÍTULO 7

Projeto Conceitual

n n

n

n

n

285

Fundição – moldes consumíveis (feitos de areia, gesso, cerâmica) e permanentes (feitos de metal). Conformação e moldagem – laminação, estiramento, extrusão, forjamento, estampagem, cunhagem, trefilação, corte, dobramento e curvamento, repuxamento, rolamento, calandragem. Usinagem – torneamento, limagem, rasqueteamento, corte, serramento, traçagem, roscamento, recartilhamento, fresagem, corte de engrenagens, aplainamento, mandrilamento, furação, alargamento, brochamento, retificação, brunimento, polimento, espelhamento, eletroerosão, usinagem química, usinagem eletroquímica, feixe elétrons e ultra-som, corte a laser, corte com jato d’água, oxicorte, corte com plasma. União – por forma, força e material (soldagem, brasagem, difusão, colagem, e juntas mecânicas (parafusos, rebites etc.)). Operações de acabamento – esmerilhamento, rebarbação, polimento, lapidação, tratamento superficial (anticorrosão, revestimentos metálicos, revestimentos não-metálicos inorgânicos, pintura, proteção catódica, galvanização), tratamento térmico (recozimento, normalização, têmpera, revenido, isotérmico, endurecimento por precipitação, termoquímico)

A seleção de um processo particular depende não apenas da forma a ser produzida, mas também de um grande número de fatores. O tipo de material e suas propriedades são considerações básicos. Materiais frágeis e duros, por exemplo, são difíceis de ser trabalhados, mesmo que possam ser fundidos ou usinados de várias maneiras diferentes. Os processos de fabricação geralmente alteram as propriedades dos materiais. Metais conformados à temperatura ambiente tornam-se mais resistentes, duros e menos dúcteis que antes do processamento. Engenheiros de manufatura estão constantemente sendo demandados para a obtenção de novas soluções de problemas de manufatura e redução de custos. Tradicionalmente, peças de chapas metálicas são obtidas por corte, feito por punções e estampos. Embora ainda amplamente utilizadas, essas operações estão atualmente sendo substituídas por técnicas de corte a laser. Com os avanços na automação, o controle automático da trajetória do laser é possível, produzindo uma ampla variedade de formas, com precisão repetibilidade e economia. Os processos de manufatura são selecionados tendo-se em mente certos atributos, tais como: condições superficiais, precisão dimensional, forma e sua complexidade, taxa de produção, custos e tamanhos. O acabamento superficial é uma característica importante nos produtos. Em geral, os produtos são compostos de peças ou unidades que são fabricadas separadamente para, então, ser montadas formando o produto final. O acabamento superficial de uma peça determina a aparência da superfície, afeta a montagem da peça com outro(s) componente(s) e também fornece proteção contra a corrosão. Existe uma relação estreita entre a rugosidade da superfície e as tolerâncias. Geralmente, a tolerância deve ser maior que a distância entre o pico mais alto e o vale mais profundo do perfil da rugosidade superficial. As tolerâncias devem ser no mínimo dez vezes o valor da rugosidade superficial média. Tolerâncias e acabamentos superficiais obtidos em operações com trabalho a quente não são tão boas quanto aquelas obtidas com operações com trabalho a frio. Mudanças dimensionais, empenamentos e oxidação na superfície ocorrem durante o processamento em elevadas temperaturas. Alguns processos de fundição produzem um acabamento superficial melhor que outros em razão dos diferentes tipos de materiais dos moldes utilizados e de seus acabamentos superficiais. A intercambiabilidade de peças manufaturadas depende diretamente da precisão dimensional e é um requisito-padrão de muitos produtos com produção em massa. A intercambiabilidade está associada a vantagens, tais como: facilidade de montagem, facilidade de reposição e padronização de processos e componentes. Se duas ou mais peças são intercambiáveis, então, elas devem ser fabricadas com dimensões compatíveis. Enquanto certos processos podem assegurar tolerâncias dimensionais estreitas, outros não. Isso ocorre, em geral, por mudanças na temperatura, desgaste de ferramentas, e deflexões e vibrações entre a peça e a ferramenta. Tolerâncias nas dimensões nada mais são do que variações nas dimensões básicas que são permitidas para assegurar a intercambiabilidade entre as peças. Os custos de manufatura aumentam exponencialmente com a diminuição das tolerâncias

286

PARTE 2

O Modelo

e melhora do acabamento superficial, motivo pelo qual deve-se selecionar o acabamento superficial e as tolerâncias dimensionais não melhores do que necessário. Os produtos variam na sua forma e na complexidade de seus detalhes. Enquanto detalhes simples podem ser manufaturados através de vários diferentes processos, somente certos processos têm a capacidade de produzir detalhes complexos. Para um detalhe simples como um rebaixo, existem muitos processos que não são capazes de produzi-lo. Em outras palavras, cada processo tem suas limitações em relação à forma e complexidade das peças produzidas. Torneamento requer que a peça tenha simetria cilíndrica; metalurgia do pó não pode ser usada para produzir peças com ângulos agudos severos pelos aspectos de resistência. Peças planas contendo seção transversal fina não são adequadas para ser obtidas por fundição. Peças complexas não podem ser obtidas de maneira fácil e econômica por meio da conformação. Quase todos os processos não podem produzir um ou mais detalhes complexos. Portanto, a complexidade da peça determinará ou não se um processo de manufatura é candidato a manufaturá-la. Os produtos variam não apenas em suas formas, mas também em tamanho e peso, e esses fatores podem limitar a escolha do tipo de processo de manufatura a ser utilizado. Como citado anteriormente, todos os processos têm um número mínimo de peças que devem ser feitas para justificar economicamente a utilização do processo. Esse aspecto deve sempre ser levado em conta quando da escolha do processo de manufatura. O custo de um processo de manufatura normalmente é o atributo mais importante. É afetado pelos outros atributos: tamanho, forma, taxa de produção, tolerâncias e acabamento superficial. O custo das ferramentas, o tempo de desenvolvimento necessário para começar a produção e o efeito do material da peça sobre o ferramental são considerações bastante importantes. Dependendo do tamanho, do projeto e da vida esperada, o custo do ferramental pode ser substancial. Para peças feitas com materiais de custo elevado, a menor geração de sobras proporcionará uma produção mais econômica. Em razão da geração de cavacos, a usinagem pode ser mais dispendiosa que a conformação. Além dos custos de ferramentas, os custos de mão-de-obra e de equipamentos, entre outros, devem ser levados em conta. Assim, o custo de um processo tem grande influência sobre sua adequabilidade para a manufatura de uma peça. Um ou mais desses atributos podem ser utilizados para determinar os processos candidatos primários, que poderão ser adequados para a manufatura do produto. Operações secundárias, tais como: tratamento térmico, usinagem, pintura etc., não devem ser consideradas nesse estágio — uma vez que operações secundárias devem ser evitadas ou minimizadas para reduzir os custos, a manipulação e o tempo de ciclo. Infelizmente, para muitos processos de manufatura, a satisfação desses critérios freqüentemente envolve soluções de compromisso, de tal forma que nem todos os atributos podem ser satisfeitos de maneira desejada. Para minimizar a severidade desses compromissos, pode-se identificar as capabilidades dos processos de manufatura mais comuns de forma que os atributos mais importantes possam ser satisfeitos com um grau mais elevado. Essa abordagem é mostrada de forma resumida na Tabela 7.4.

CAPÍTULO 7

Projeto Conceitual

Tabela 7.4

287

Processos de Manufatura e Seus Atributos (Magrab, 1997)

Os processos de manufatura candidatos obtidos na Tabela 7.4 podem ser relacionados com os materiais candidatos por meio da Tabela 7.5. Essa tabela relaciona o grau de adequação dos materiais candidatos com os processos de manufatura candidatos. Associado com cada processo de manufatura existe um conjunto de recomendações que indicam limitações geométricas (forma) específicas, que, se observadas, resultarão em um produto fácil de fazer e de baixo custo. Para ilustrar o significado dessas recomendações, utiliza-se a concepção de uma peça, mostrada na Figura 7.38. As figuras de (b) a (g) mostram de maneira exagerada o efeito de diferentes processos de manufatura sobre a geometria da peça.

288

PARTE 2

Tabela 7.5

O Modelo

Adequabilidade de Materiais e Processos de Manufatura (Magrab, 1997)

CAPÍTULO 7

Projeto Conceitual

Figura 7.38

289

Efeito do processo de manufatura sobre a geometria — detalhes exagerados — (Magrab, 1997).

A equipe de projeto, quando da análise das alternativas de métodos para a proFatores de Custo na dução de uma parte, ou produto, ou para a execução de uma operação dentro de um Seleção de Processos de processo, põe-se diante de variáveis de custo relacionadas aos materiais, mão-de-obra Fabricação direta e indireta, ferramentas especiais, infra-estrutura e capital a ser investido. A inter-relação dessas variáveis pode ser considerável e, portanto, a seleção do melhor processo de fabricação é uma tarefa nada fácil. Raramente um produto pode ser feito apenas por um método, e vários processos competitivos estão disponíveis. Dessa forma, a avaliação e a comparação das alternativas devem ser detalhadas e completas, de modo que se tome conhecimento por completo dos impactos dos vários fatores sobre os custos unitários. Materiais: O custo unitário dos materiais é um fator importante quando os métodos que estão sendo comparados envolvem o uso de diferentes materiais ou diferentes quantidades de materiais. Por exemplo, o alumínio fundido em matriz apresenta um custo maior do que o ferro fundido em areia — se a peça for para a mesma aplicação. O processo de sinterização usa uma menor quantidade de material de maior custo do que o processo de fundição e de usinagem. Cavacos, retalhos e refugos podem influenciar consideravelmente o custo de materiais. Mão-de-obra direta: O custo da mão-de-obra é especialmente determinado por três fatores: o processo de fabricação propriamente dito; o projeto da parte ou do produto; e a produtividade dos operadores dos processos. Em geral, quanto mais complexo é o projeto, mais apertadas são as tolerâncias, maior é o requisito de acabamento superficial, mais usinagem é envolvida e maior será a mão-de-obra. O número de operações de fabricação, para completar uma peça, é provavelmente o maior determinante do custo da mão-de-obra. Cada operação envolve em pegar a peça, colocá-la na máquina, operar, retirar e colocá-la de lado — e, adicionalmente, inspeções podem ser necessárias. Custos indiretos podem aumentar; acumulação de erros pode ocorrer pelas diferentes fixações na máquina e diferentes superfícies de apoio. Mão-de-obra indireta: O custo da mão-de-obra de ajustagem das máquinas, inspeções, manutenção de equipamentos, afiação e reparo das ferramentas, movimentação de materiais é, em muitos casos, fator determinante na seleção de um processo de fabricação. Por exemplo, as vantagens do processo de forjamento podem ser reduzidas quando são considerados os custos da mão-de-obra de manutenção das matrizes e das próprias prensas. A ajustagem das máquinas pode se tornar importante principalmente na produção de pequenos lotes de peças. Nesse caso, é conveniente adotar um processo que requer pouca mão-de-obra de ajustagem, mesmo que a mão-de-obra no processo seja maior. Usinagens especiais: A fabricação de dispositivos de fixação, gabaritos, matrizes, moldes, ferramentas especiais, calibres e equipamentos de teste podem ser fatores importantes quando novas partes ou produtos são

290

PARTE 2

O Modelo

produzidos ou maiores modificações são introduzidas. O custo por unidade de produção de peça ou produto deve ser considerado para comparações, pois esse valor é muito dependente do volume de produção. Com um alto volume de produção, um alto investimento em ferramentas pode ser normalmente justificado pela redução na mão-de-obra direta, necessária no processo. Ferramentas e consumíveis: O custo resultante do uso de pastilhas, fresas, rebolos de corte e de retificação, brocas, brochas, machos e cosinetes, esmeris, lixas, limas, solventes, lubrificantes, desengraxantes e outros fluidos de limpeza, pós e pastas abrasivas e demais dependem em muito do processo de fabricação. Assim, ao selecionar um processo de fabricação e considerando o custo como fator principal, os custos de ferramentas e consumíveis devem ser considerados na tomada de decisão na seleção do processo de fabricação. Utilidades: Da mesma forma que no caso de ferramentas e consumíveis, os custos com energia elétrica, vapor, refrigeração, calor, água, ar comprimido devem ser considerados, quando houver diferenças consideráveis no seu uso nos diferentes processos e equipamentos, sendo analisados e avaliados para a seleção. Capital investido: Sempre é mais fácil e de menos risco para a empresa usar, para a fabricação de um novo produto, as facilidades de que ela dispõe. Assim, a disponibilidade de planta, máquinas e infra-estrutura devem ser comparadas com outras alternativas para as quais são necessários investimentos de capital. Ainda existe a alternativa de subcontratar serviços de fabricação. Os custos de investimento, por unidade de fabricação, das diversas alternativas de processos devem ser comparados para a sua seleção. Outros custos: Custos de embalagem, transporte, manutenção, ajustagens adicionais e refugos podem também influenciar na seleção do processo de fabricação.

7.11 Atualizar estudo de viabilidade econômico-financeira Nesta atividade, a equipe de projeto deve, inicialmente, para as arquiteturas geradas, estimar o custo dessas e comparar com os requisitos de custo estabelecidos na fase anterior, como forma de avaliar as arquiteturas geradas. Posteriormente, com as definições mais bem estabelecidas, as concepções serão avaliadas com relação a vários critérios, inclusive o custo. Ou seja, como a concepção escolhida ao final da fase passará por um processo de avaliação, para ser aprovada, ela deverá atender às especificações de custo.

7.12 Avaliar fase Esta atividade segue o padrão da atividade genérica apresentada no Capítulo 3, Tópico 3.4. O conjunto de especificações-meta geradas e atualizadas durante esta fase pode ser avaliado utilizando-se os critérios mostrados na Tabela 7.6. Tabela 7.6

Critérios de Avaliação do Gate da Fase de Projeto Conceitual Critérios

Viabilidade técnica Existe alguma limitação tecnológica? As especificações técnicas estão sendo atendidas? Viabilidade econômica As especificações de custo estão sendo atendidas? Quais são os custos de produção? Maturidade da tecnologia

• • • • •

Podem as tecnologias escolhidas ser manufaturadas pelos processos conhecidos? Os parâmetros funcionais críticos estão identificados? A segurança e a sensibilidade dos parâmetros operacionais são conhecidas? Os modos de falhas são conhecidos? A tecnologia é controlável por meio do ciclo de vida do produto?

CAPÍTULO 7

Projeto Conceitual

291

7.13 Aprovar fase Essa atividade segue o padrão da atividade genérica apresentada no Capítulo 3, Tópico 3.4. Os mesmos critérios verificados na auto-avaliação da atividade anterior são analisados pelo Time de Avaliação, o qual, além disso, compara o produto e o projeto com os demais do portfólio, para avaliar o seu sucesso (com relação aos outros projetos e produtos) e o retorno financeiro esperado.

7.14 Documentar as decisões tomadas e registrar lições aprendidas Essa atividade segue o padrão da atividade genérica apresentada no Capítulo 3, Tópico 3.6. Ao longo deste capítulo foram descritas diversas práticas melhores. Ficaria repetitivo listá-las novamente neste tópico.

7.15 Questões e atividades didáticas propostas Questões para reflexão 1. 2. 3. 4. 5. 6. 7. 8. 9.

Por que a modelagem funcional torna-se tão importante no início da fase de Projeto Conceitual? Qual a diferença entre estrutura de funções e árvore de funções? Quais as diferenças entre os métodos intuitivos e sistemáticos de criatividade? Em termos de representação, quais as diferenças entre uma alternativa de solução e a arquitetura de um produto. Descreva as diferentes facetas da modularidade no desenvolvimento de produtos. Quais os aspectos positivos e negativos do envolvimento dos clientes na fase de Projeto Conceitual? Quais os benefícios obtidos com a utilização dos DFXs na fase de Projeto Conceitual. Quais são as principais diferenças do DFM e DFA? Quais os tipos de testes que melhor auxiliam o Time de Desenvolvimento durante a fase de Projeto Conceitual?

Atividades didáticas 1. Para o projeto original escolhido no Tópico 6.12, desenvolva a função global e o desdobramento na estrutura de funções. 2. Para o produto a ser reprojetado, conforme definido no Tópico 6.12, desenvolva a função global e o desdobramento na estrutura de funções. 3. Para o projeto original escolhido no Tópico 6.12, desenvolva a matriz morfológica e as alternativas de solução correspondentes. 4. Utilize um método sistemático, um método intuitivo e um orientado para gerar princípios de solução para a estrutura de funções gerada no item1. 5. Utilize um método sistemático, um método intuitivo e um orientado para gerar princípios de solução para a estrutura de funções gerada no item 1. 6. Para o produto a ser reprojetado, conforme definido no item 1, aplique o método da TIPS, conforme apresentado no Quadro 7.5 para a obtenção dos princípios de solução. 7. Para as soluções geradas nos itens 3 e 4, selecione as concepções mais adequadas. 8. Para a(s) concepção(ões) selecionada(s) no item 7, identifique os possíveis processos materiais e processos de fabricação dos componentes. 9. Qual a importância da estética no sucesso de um produto? 10. Qual o papel dos fornecedores na fase de Projeto Conceitual?

292

PARTE 2

O Modelo

7.16 Informações adicionais BAKERJIAN, R. Tool and manufacturing engineers handbook. Society of manufacturing engineers. 4. ed. Dearborn: Society of Manufacturing Enginers, 1992. v. 6. BAXTER, M. Projeto de produto: guia prático para o desenvolvimento de novos produtos. São Paulo: Edgard Blücher, 1998. ERIXON, G.; VON YXKULL, A.; ARNSTRÖM, A. Modularity — the basics for product and factory reengineering. CIRP, 1996. DUL, J. WEERDMEESTER, B. Ergonomia prática. São Paulo. Edgard Blucher, 1995. GOMES FERREIRA, M. G. Utilização de modelos para a representação de produtos no projeto conceitual. 1977. Dissertação (Mestrado em Engenharia Mecânica) — Universidade Federal de Santa Catarina, 1977. HERRMANN, J. W.; COOPER, J.; GUPTA, S. K.; HAYES, C. C.; ISHII, K.; KASMER, D.; SANBORN, P. A.; WOOD, W. H. New directions in design for manufacturing, proceedings of DETC’04. ASME, Design Engineering Technical Conferences and Computers and Information in Engineering Conference. Salt Lake City, Utah USA, 28 set.- 2 out. 2004. HUANG, G. Q. Design for X: concurrent engineering imperatives. London: Chapman & Hall, 1996. HUBKA, V.; EDER, W. E. Theory of technical systems: a total concept theory for engineering design. London : Springer-Verlag, 1988. p. 275. MAGRAB, E. B. Integrated product and process design and development — he product realization process. Boca Raton: CRC Press, 1997. OTTO, K.; WOOD, K. Product design — techniques in reverse engineering and new product development. New Jersey: Prentice-Hall Inc., 2001. PAHL, G. & BEITZ, W. Engineering design — a systematic approach. London: Springer, 1996. SOUSA, A. G. Estudo e análise dos métodos de avaliação da montabilidade de produtos industriais no processo de projeto 1998. Dissertação (Mestrado em Engenharia Mecânica) — Universidade Federal de Santa Catarina, 1998. ULLMAN, D. G. The mechanical design process. New York: McGraw-Hill International Editions, 1997. ULRISH, K. & TUNG, K. Fundamentals of product modularity. DE-v. 39, Issues in Design Manufacture/Integration, ASME, 1991. p 73-79. ULRISH, K. T. & EPPINGER, S. D. Product design and development. New York: McGraw-Hill Higer Education, 2000. VOLVO GROUP SUPPLIER PORTAL. Disponível em: . PQP4/ISSUE 02 — 14JAN2003. Acessado em: 20 dez. 2004. VOLVO GROUP SUPPLIER PORTAL. Disponível em: . Acessado em 20 dez. 2004. WARELL, A. V. Design syntatics — a contribution towards a theoretical framework for form design. International Conference on Engeneering Design, Glasgow, 2001.

8.1 8.2 8.3

8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11 8.12 8.13 8.14 8.15 8.16 8.17 8.18 8.19 8.20

Sumário Atualizar o plano do projeto detalhado Criar e detalhar SSCs, documentação e configuração 8.3.1 Criar, reutilizar, procurar e codificar SSCs 8.3.2 Calcular e desenhar os SSCs 8.3.3 Especificar tolerâncias 8.3.4 Integrar os SSCs 8.3.5 Finalizar desenhos e documentos 8.3.6 Configurar produto e completar a estrutura do produto Decidir fazer ou comprar SSCs Desenvolver fornecedores Planejar processo de fabricação e montagem Projetar recursos de fabricação Avaliar SSCs, configuração e documentação do produto e processo Otimizar produto e processo Criar material de suporte do produto Projetar embalagem Planejar fim de vida de produto Testar e homologar produto Enviar documentação do produto a parceiros Monitorar a viabilidade econômico-financeira Avaliar fase Aprovar fase Documentar as decisões tomadas e registrar lições aprendidas Questões e atividades didáticas propostas Informações adicionais

PARTE 2 O Modelo Projeto Detalhado 8. Projeto Detalhado

Depois da leitura deste capítulo, você será capaz de: l

l

l

l

l

l

l

Coordenar a obtenção da especificação do produto a partir da sua concepção (resultante da fase de projeto conceitual), integrando da melhor forma as fases de projeto detalhado com o conceitual. Entender os ciclos de detalhamento, aquisição de itens e otimização do produto que ocorrem durante a fase de projeto detalhado, e quais são as atividades envolvidas. Definir, na sua empresa, como criar um novo item ou reutilizar um item existente ou mesmo procurar um item desejado para ser comprado, envolvendo a sua codificação, identificação, classificação e padronização. Entender a melhor forma de gerenciar os parâmetros críticos de um produto. Entender a inserção do processo de desenvolvimento de software no processo de desenvolvimento de produtos. Especificar uma sistemática de análise se um item deve ser fabricado internamente ou comprado no mercado. Entender o que é custo-alvo e qual o seu relacionamento com a gestão de custos.

294

l

l

l

l

l

PARTE 2

O Modelo

Planejar o processo de fabricação dos componentes e montagem dos subsistemas, sistemas e produto final dentro do conceito de engenharia simultânea, considerando também o projeto de recursos de fabricação e o projeto de fábrica. Entender a diferença entre testar/homologar um produto e a avaliação, validação e otimização do produto, contextualizando quando se deve aplicar conceitos de planejamento de experimentos ou de projeto robusto (método Tagushi). Relacionar os requisitos da ISO 9001:2000 e as atividades do modelo de referência deste livro. Definir a melhor forma de o enviar a documentação do produto a parceiros de desenvolvimento. Descrever quais os tipos de sistemas computacionais, métodos e ferramentas existentes, que podem ser utilizados durante a fase de projeto detalhado.

8.1

Sumário

O projeto detalhado dá prosseguimento à fase anterior, e tem como objetivo desenvolver e finalizar todas as especificações do produto, para então serem encaminhados à manufatura e às outras fases do desenvolvimento. Primeiro, é importante discutir a integração desta fase com a anterior, o projeto conceitual, mostrada no Quadro 8.1. Quadro 8.1

Integração do Projeto Detalhado com o Projeto Conceitual

Na fase de projeto conceitual, normalmente, são realizados desdobramentos sucessivos dos sistemas em subsistemas, depois em componentes, os quais são associados aos processos de fabricação, documentados no plano de processo macro, a partir da análise dos requisitos dos clientes. Ou seja, é realizado um processo top down (de cima para baixo — do produto final para os componentes) de raciocínio para a definição desses elementos. Pode acontecer a primeira integração física entre os SSCs, caso algum protótipo tenha sido produzido e testado no projeto conceitual. Veja a Figura 8.1 (repare na direção das flechas). Em seguida, no projeto detalhado, acontece um processo contrário, bottom up (de baixo para cima — dos componentes para o produto final), no qual são integrados os componentes, subsistemas, sistemas, sucessivamente, até o produto final. Outros detalhamentos completam a concepção (resultante do projeto conceitual) com o objetivo de obter um produto integrado, contendo as tolerâncias de seus parâmetros e especificações críticas dentro de uma faixa de valores que atenda aos requisitos dos clientes e todas as especificações-meta da fase de projeto informacional. Em outras palavras, primeiro, os SSCs são definidos e desdobrados para atender aos requisitos. Depois, eles são integrados, e o todo é avaliado. Como as duas barras superiores da Figura 8.1 indicam, existe uma superposição entre o projeto conceitual e o projeto detalhado. Na fase de projeto conceitual, podem ser realizados todos os desdobramentos dos itens do produto. Já no projeto detalhado, todavia, pode ser realizada parte do desdobramento, dependendo do grau de novidade e complexidade do produto para a empresa. Isto é, existem atividades do projeto conceitual que podem ser realizadas durante o projeto detalhado e vice-versa. Vamos discutir essa superposição em seguida, considerando o grau de novidade e a complexidade do produto.

Considerando o grau de novidade Quanto menor for o grau de novidade do produto para a empresa (relacionada, por exemplo, à inovação tecnológica), mais detalhada será a fase de projeto conceitual, chegando a especificar os SSCs com uma certa precisão. Esse é o caso de empresas que sempre produzem produtos com pequena variação, por exemplo, uma empresa que sempre produz o mesmo tipo de máquina. Muitas informações de produtos existentes são reutilizadas. A fase de projeto conceitual é rápida e a de detalhamento, mais simples. Devido a isso, existe a adaptação do modelo de referência (veja o Capítulo 5, Planejamento do Projeto). Quanto maior for a novidade apresentada pelo produto, só se conseguirá identificar os SSCs principais durante a fase de projeto conceitual, e grande parte deles será criada na fase de projeto detalhado, quando, além disso, todos os SSCs serão especificados.

(continua)

CAPÍTULO 8

Projeto Detalhado

Quadro 8.1

Figura 8.1

295

Integração do Projeto Detalhado com o Projeto Conceitual (continuação)

Desdobramento de itens e sua integração ao projeto conceitual e detalhado.

Considerando a complexidade do produto Quanto maior for o grau de complexidade do produto, mais ele será detalhado na fase de projeto conceitual, mas o motivo aqui não é a reutilização de muitas informações, e sim a necessidade de se ter uma noção mais precisa do produto, para se aprovar a continuidade do desenvolvimento no gate, pois há um risco inerente aos projetos complexos. Isso significa que algumas atividades da fase de projeto detalhado acontecem na fase de projeto conceitual. Um exemplo é a atividade de avaliar os SSCs, que pode ocorrer no projeto conceitual para analisar se um sistema pode ser incorporado ao produto ou não.

Detalhamento sucessivo Na fase de projeto conceitual, são obtidos vários resultados que são completados durante a fase de projeto detalhado. Por exemplo, um SSC é definido no projeto conceitual e faz parte de uma das concepções alternativas. Naquele momento, não se necessitava de uma especificação detalhada, que é realizada nesta fase. Outra particularidade da fase de projeto detalhado é a criação dos detalhamentos dos planos de processos de fabricação e montagem (veja a parte inferior à direita da Figura 8.1). Na fase de projeto conceitual são definidos os processos de fabricação que serão utilizados, mas a especificação e documentação finais serão realizadas na fase de projeto detalhado.

Agora que você entendeu que pode existir uma superposição entre as fases do projeto conceitual e do detalhado, precisamos discutir a natureza da fase do projeto detalhado. As atividades dessa fase não são realizadas de forma seqüencial e, sim, por meio de vários tipos de ciclos, que garantem o paralelismo entre as atividades. A seguir, estude o Quadro 8.2, sobre os tipos de ciclos da fase de detalhamento.

296

PARTE 2

Quadro 8.2

O Modelo

Tipos de Ciclos da Fase de Detalhamento

Para explicarmos os tipos de ciclos, não detalharemos as atividades e tarefas desta fase, que serão apresentadas ao longo deste capítulo. Primeiro, precisamos esclarecer o significado do termo “criar um SSC”. Criar significa identificar a necessidade de existência de um SSC, que será detalhado durante esta fase, e gerar esse elemento para a empresa, seja inserindo-o em uma base de dados, criando um desenho etc. Classicamente, o PDP é definido pelo ciclo: projetar—construir—testar—otimizar. Essa visão é válida e está de acordo com os ciclos apresentados aqui, mas vamos refiná-la em três ciclos, porque eles integram o relacionamento entre as atividades da fase de detalhamento. Os três ciclos desta fase, ilustrados na Figura 8.2, estão intimamente interligados. São eles: Figura 8.2

Tipos de ciclos da fase de Projeto Detalhado.

Ciclo de detalhamento: ocorre quando se criam e se detalham os SSCs, e envolve suas tarefas. É o ciclo que desdobra o produto em sistemas, subsistemas e componentes, e depois os integra, como mostrado no Quadro 8.1 . Na primeira tarefa dessa atividade, procura-se reutilizar os SSCs da própria empresa ou do mercado. Caso de início isso já seja possível, aciona-se o ciclo de aquisição. Para os demais SSCs, são realizadas as tarefas subseqüentes da atividade. Cada vez que existirem informações disponíveis (plano de processo) para se decidir comprar ou fabricar um SSC (make or buy decision), aciona-se novamente o ciclo de aquisição. Quando o detalhamento do SSC estiver adiantado, aciona-se o ciclo de otimização, no qual primeiro avaliam-se as especificações obtidas, que são otimizadas em caso de necessidade. Repare então que os ciclos de aquisição e otimização estão integrados com o ciclo de detalhamento. Depois de esgotadas as possibilidades de aquisição e otimização, serão finalizadas as últimas tarefas da atividade de criar e detalhar os SSCs. Ciclo de aquisição: é acionado durante o ciclo de detalhamento, como mostrado anteriormente. Ele envolve as atividades apresentadas na Figura 8.2. Os custos de fabricação de um SSC são calculados e comparados com os preços dos fornecedores. Se for vantajoso, será fechado um contrato de fornecimento. Ciclo de otimização: também ocorre durante o ciclo de detalhamento, quando os SSCs são construídos (protótipos) e testados, portanto, avaliados. Quando necessário, eles são otimizados, sofrendo mais um ciclo de detalhamento e/ou aquisição. A atividade de planejamento do processo de fabricação e montagem fornece informações importantes para todos esses ciclos e é realizada paralelamente, como descrito no Tópico 8.6. Ela é integrada à atividade de projetar os recursos. Quando se apresentam esses ciclos, pode parecer que a prática desta fase é complicada. No entanto, eles dão flexibilidade ao modelo de referência para que sirvam a diversos tipos de projetos e alerta as empresas para a necessidade concreta de trabalho em time, de forma paralela, para que se obtenham os benefícios da Engenharia Simultânea.

CAPÍTULO 8

Projeto Detalhado

297

Agora que já vimos como a fase de projeto detalhado está integrada com a fase anterior de projeto conceitual, e também conhecemos os ciclos de detalhamento, aquisição e otimização, fica mais fácil entender a visão geral desta fase e a relação de interdependência entre as suas atividades (Figura 8.3). Figura 8.3

Informações principais e dependência entre as atividades da fase de Projeto Detalhado.

A informação de entrada da fase de projeto detalhado é a concepção do produto. Essa fase inicia-se com a atualização do plano de projeto, como nas fases anteriores. A atividade central dessa fase é a criação e detalhamento dos SSCs, pois, nela, acontece o ciclo de detalhamento, e é a partir dela que são acionadas as atividades do ciclo de aquisição (decidir fazer ou comprar SSCs [make or buy decision] e desenvolver fornecedores) e do ciclo de otimização (avaliar SSCs, configurar e documentar o produto e o processo, otimizando-os quando necessário — por isso, a linha tracejada). Paralelamente à realização dos ciclos mencionados, ocorre a atividade de planejamento do processo de fabricação e montagem e o respectivo projeto de recursos, que pode envolver desde o projeto de uma ferramenta ou dispositivo específico até o projeto de uma nova fábrica. É ainda na atividade de criar e detalhar os SSCs que acontece a documentação final e configuração do produto, após a realização dos ciclos e atividades mencionadas. O final desses ciclos acontece ao término da atividade de avaliar os SSCs, quando todas as especificações que foram criadas são aprovadas. Nesse contexto, acontece a aplicação do conceito de engenharia simultânea, como descrito no Capítulo 2. Paralelamente, são realizadas as atividades de criação do material de suporte do produto e de projeto de embalagens, que, juntamente a todas as especificações, compreendem informações de entrada da atividade de testar e homologar o produto. Essa atividade agrega todas as informações criadas até então e possui tarefas semelhantes àquelas da atividade de avaliação dos SSCs. No entanto, seu foco está no produto final e seu aspecto não é mais somente interno, como na atividade de avaliação. Na homologação, a participação do cliente ou órgãos reguladores e/ou de homologação é comum. No entanto, ela ainda não é a certificação final do produto, que só ocorre na fase de preparação da produção, após a produção do lote piloto.

298

PARTE 2

O Modelo

Ao mesmo tempo, é criado o plano de fim de vida do produto, que consolida todas as informações relacionadas à descontinuidade do produto no mercado. Em seguida, a documentação final do produto é enviada aos parceiros da cadeia de suprimentos. O monitoramento da viabilidade econômico-financeira utiliza as especificações finais do produto, associadas às informações do planejamento de processo, para atualizar as premissas do estudo de viabilidade. Finalmente, as atividades de avaliação (gerencial) do projeto e sua aprovação são realizadas, seguidas da atividade formal de documentação das decisões tomadas e registro das lições aprendidas. Essa fase pode ser longa e demorada, se o produto for muito complexo e for constituído de muitos itens. Nesses casos, acontecem alguns gates intermediários técnicos, para aprovação das especificações do produto. As atividades de avaliar os SSCs, testar e homologar o produto podem ser consideradas gates técnicos. A atividade de avaliar os SSCs pode ser aplicada mais de uma vez, dependendo dos ciclos de detalhamento e otimização do produto. Um primeiro ciclo de detalhamento e otimização é denominado por alguns autores de projeto preliminar, conforme a discussão colocada no Quadro 8.3. Quadro 8.3

Projeto Preliminar entre o Projeto Conceitual e Detalhado

Alguns autores da área de desenvolvimento de produto propõem a existência de uma fase intermediária entre o projeto conceitual e o projeto detalhado, denominada de projeto preliminar. A justificativa é a necessidade de se ter uma noção mais concreta da primeira especificação do produto, para então decidir se a empresa deve continuar a investir no detalhamento das suas especificações. O projeto preliminar partiria da concepção do produto, que conteria as soluções alternativas, a serem detalhadas na fase do projeto preliminar, até o ponto em que uma decisão pudesse ser tomada e uma das soluções, selecionada. Segundo Pahl & Beitz (1996), é na fase preliminar que o projeto é desenvolvido, de acordo com critérios técnicos e econômicos e à luz de informações adicionais, até que a fase de projeto detalhado subseqüente possa conduzir diretamente à produção. Ainda segundo esses autores, o nível de detalhamento a ser alcançado na fase de projeto preliminar deve incluir: estabelecimento do layout definitivo do produto (arranjo geral e compatibilidade espacial); projeto preliminar das formas (formato de componentes e materiais); procedimentos de produção; estabelecimento de soluções para qualquer função auxiliar. Como pode ser observado, nessa como em outras abordagens clássicas, considera-se que a concepção gerada da fase de projeto conceitual é pouco detalhada. Esse tipo de fase era realmente algo necessário quando o desenvolvimento de produto fazia pouco uso de sistemas CAD. A concepção descrita continha somente esboços manuscritos dos produtos, indicando as soluções técnicas adotadas e as alternativas de suas combinações. As primeiras especificações mais formais surgiam no projeto preliminar, que compreendia os primeiros desenhos, cálculos etc. A empresa então tinha mais segurança para, a partir dessas informações, desenvolver um estudo de viabilidade econômico-financeira mais aprimorado, e, com isso, tomar a decisão de desenvolver o produto ou não. Hoje em dia, com a existência de sistemas CAD mais sofisticados e baratos; o conceito de gates técnicos e gerenciais; a flexibilidade de escopo do projeto conceitual; o reuso sistemático de itens; a padronização de projetos; e os ciclos de detalhamento e otimização da fase de projeto detalhado, não se necessita mais de uma fase formal de projeto preliminar, como será explicado a seguir. Na fase de projeto conceitual, já se trabalha com o modelo geométrico tridimensional do produto, criando-se inclusive o mock up digital, graças às funcionalidades dos sistemas CAD (veja o Quadro 8.11). Consegue-se, com isso, obter maior precisão de representação do produto já na fase de projeto conceitual. O reuso de itens facilita o levantamento de custo, e a padronização dos projetos acelera e deixa o projeto conceitual mais detalhado. Ou seja, se o produto não trouxer muitas inovações, o conteúdo da concepção já é suficiente para se tomar a decisão de continuidade do projeto de desenvolvimento (realização do projeto detalhado). Pode-se, já na fase de projeto conceitual, desenvolver uma série de atividades que antigamente eram colocadas no projeto preliminar. Para produtos inovadores (e também para outros produtos, cujas concepções não fornecem tanta segurança assim), pode-se “rodar” um primeiro ciclo de detalhamento e otimização da fase do projeto detalhado e, nesse ponto, realizar um gate técnico. Nesse momento, é possível igualmente atualizar o estudo de viabilidade econômico-financeira, pois seu monitora-

(continua)

CAPÍTULO 8

Projeto Detalhado

Quadro 8.3

299

Projeto Preliminar entre o Projeto Conceitual e Detalhado (continuação)

1

mento é constante. Ou seja, temos a mesma flexibilidade do projeto preliminar, sem a necessidade de criarmos uma fase específica com esta denominação no modelo de referência deste livro. Outra justificativa encontrada para a realização do projeto preliminar é a necessidade de sua aplicação em projetos complexos, pois a concepção tradicional do produto não traz informações suficientes. Novamente, argumenta-se que a concepção nesses casos deve ser mais completa e possuir informações suficientes para se tomar a decisão de continuidade do projeto ou não. Além disso, existe a flexibilidade do projeto detalhado, descrita anteriormente, que também pode ser aplicada em projetos complexos. Se o produto for único, como o caso da construção de navios, plataformas marítimas, enfim, bens de capital intensivo, o modelo deste livro não se aplica. Esses produtos são feitos (desenvolvidos) sob encomenda e entram no caso de produtos Engineering To Order (ETO). Para esses casos, o Capítulo 16 traz uma adaptação do modelo, no qual é inserida uma fase no final da macrofase de pré-desenvolvimento, denominada de “vender produto”, cujo resultado é um orçamento técnico comercial detalhado do produto. Nessa fase, são realizadas as atividades iniciais das fases de projeto conceitual (quando o cliente não fornece as especificações do produto) e algumas do projeto detalhado, se necessário. É determinado um preço, 2 realizado um orçamento e uma proposta comercial. Se a proposta for aceita e um pedido for feito, as fases subseqüentes de desenvolvimento reaproveitam as especificações criadas no orçamento. Ou seja, mesmo aqui não se necessita de uma fase de projeto preliminar. Algumas empresas insistem em criar essa fase de projeto preliminar , pois este conceito está arraigado na sua cultura. Como o conteúdo do projeto preliminar é uma repetição de algumas atividades do projeto conceitual e de muitas atividades do projeto detalhado, o modelo deste livro também pode ser adotado para a confecção de modelo de referência específico 3 que contenha esta fase.

Você observou a interação entre as atividades nos ciclos apresentados. Porém, por motivos didáticos (e devido às características inerentes de um livro) a descrição das atividades tem de ser seqüencial. Todavia, o leitor deve ter em mente o tempo todo que as atividades e tarefas acontecem de forma paralela, considerando os ciclos de detalhamento apresentados. Essa abstração é importante para o pleno entendimento da fase de projeto detalhado. Imagine um time de desenvolvimento trabalhando no detalhamento de um produto. Enquanto uma pessoa está criando um SSC, a outra contata fornecedores para outros SSCs, um projetista senta com um processista, e eles discutem como fabricar um componente. Outros estão testando certos sistemas e subsistemas etc. A seqüência que selecionamos para apresentar as atividades está descrita a seguir. Primeiro, descreveremos a atividade de atualização do plano de projeto, como em todas as fases. Em seguida, discutiremos a atividade central de criar e detalhar os SSCs. No meio da sua descrição, indicamos os momentos de acionar os demais ciclos. Depois, mostramos as atividades do ciclo de aquisição, as atividades de planejamento de processo e de projeto de recursos. Serão apresentadas, em seguida, as atividades de avaliação e otimização, pois elas tratam tanto de produto quanto de processo, ou seja, elas avaliam os resultados de todas as atividades anteriormente mencionadas. A partir desse tópico, apresentaremos as demais atividades na seqüência natural de sua realização: criar material de suporte do produto, projetar sua embalagem, planejar o fim de sua vida, testá-lo e homologá-lo, enviar sua documentação aos parceiros. Finalmente, mostramos as atividades finais genéricas de todas as fases deste modelo: monitorar a econômico-financeira, avaliar e aprovar a fase, documentar as decisões tomadas e registrar lições aprendidas. Vamos agora partir para a descrição das atividades desta fase. 1

2 3

Atividade genérica de “monitorar viabilidade econômica” (Tópico 3.2) acontece no final de cada fase de desenvolvimento, para formalizar o momento de revisão do estudo de viabilidade. A empresa, porém, deve possuir um modelo de fácil atualização (por exemplo, uma planilha), de maneira que ele possa ser atualizado durante todo o desenvolvimento. Com isso, garantimos o monitoramento constante, cada vez que tivermos de tomar alguma decisão que possa causar impacto no custo (veja o Gráfico do Quadro 8.15, sobre a análise financeira no PDP). Esse é o conteúdo da Tabela 16.1 do Capítulo 16, que descreve a adaptação deste modelo de referência para o caso de produtos ETO. No Capítulo 15, propõe-se um método para a obtenção do modelo de referência específico, a partir deste livro.

300

8.2

PARTE 2

O Modelo

Atualizar o plano do projeto detalhado

Como em todas as fases anteriores da macrofase de desenvolvimento, esta atividade pertence à área de conhecimento de Gestão de Projetos. É quando se atualiza o plano do projeto, que foi criado na fase de planejamento do produto, conforme a atividade genérica descrita no Tópico 3.2. Quadro 8.4

Recomendações para o Planejamento das Tarefas de Detalhamento

Deve-se tomar cuidado ao se definirem as atividades da fase de detalhamento. Certos planejadores possuem a tendência de exagerar no nível de detalhamento. Eles consideram a realização de cada documento como uma tarefa a ser controlada pelo projeto (por exemplo, o desenvolvimento de cada desenho). Imagine que tenhamos um produto com 200 itens, o que é normal para bens de capital, como uma máquina. Vamos considerar que 90 desses itens serão fabricados e, portanto, precisaremos confeccionar 90 desenhos e 90 planos de processo, com seus vários desdobramentos (documentos que detalham cada operação do plano de processo e os recursos a serem fabricados, veja tópicos 8.6 e 8.7). Teríamos então 180 documentos, a serem obtidos, e mais 40 documentos dos recursos. Não é apropriado criar 220 atividades no planejamento. No entanto, quando for solicitado o status do desenvolvimento da fase de detalhamento, deve existir a possibilidade de controlar a situação desses documentos. A melhor prática é trabalhar com atividades macro que agreguem o desenvolvimento desses documentos em poucas tarefas, como por sistema (módulo) do produto. No Capítulo 5, mais especificamente no Quadro 5.7, “Identificando Atividades”, discutimos detalhadamente essa questão, demonstrando que devemos sempre ter em mente que o Plano visa somente auxiliar a distribuição de tarefas, sua previsão e controle. Assim, o nível de detalhes deve ser suficiente para este propósito. Outra dificuldade é prever qual a duração da atividade de avaliação e melhoria. Deve-se prever um período para o ciclo de otimização com base em valores históricos, dando os devidos descontos a uma melhoria no desempenho no longo prazo. Porém, o mais importante é investir em treinamento e aplicação de métodos apropriados, como os métodos de DFx (veja Quadro 7.8), com os quais atuamos proativamente na prevenção de problemas. Finalmente, para facilitar o controle de status do desenvolvimento, com base na rastreabilidade e consulta da situação do desenvolvimento de cada item, devemos aplicar sistemas do tipo EDM/PDM. Alguns desses sistemas trabalham com uma estrutura de objetos, integrando à Estrutura de Produto tradicional (BOM) todos os documentos associados a um item. Assim, a consulta da situação do desenvolvimento varre toda a estrutura, consulta o status de cada item e emite um relatório com a questão solicitada. Lógico que para isso deveremos estar trabalhando com um controle do armazenamento de cada item com as funções de checkin e checkout, além de sistema de workflow integrado, para o qual o usuário deve se reportar ao status de cada documento associado, quando ele for atualizado e armazenado (veja o Quadro 8.18, sobre PDM/EDM). Conclusão: vamos planejar atividades agregadas e não relacioná-las a cada documento a ser criado na fase de projeto detalhado.

8.3

Criar e detalhar SSCs, documentação e configuração

Da fase anterior, projeto conceitual, resulta a concepção do produto, composta de: n Alternativas de solução Resultados anteriores, • Princípios de solução individuais entradas para esta • Princípios de solução totais atividade n Lista dos SSCs (principais) n Arquitetura do produto • Layout do produto • BOM inicial n Desenhos iniciais n Especificações iniciais dos SCCs n Plano macro de processo Observe as definições desses resultados no Quadro 8.5: Termos Utilizados no Projeto Conceitual.

CAPÍTULO 8

Projeto Detalhado

301

O termo “criar” pode causar a impressão que até este ponto não existiam os Existem SCCs criados no SSCs. Na verdade, os principais SSCs4 são identificados no projeto conceitual, e, projeto conceitual muitas vezes, criados durante aquela fase (repare no conteúdo da concepção do produto — lista dos SSCs principais e especificações iniciais dos SSCs). Mas é mais comum que, naquela fase, eles sejam somente identificados, e a continuidade da sua criação ocorra durante o projeto detalhado. Além disso, existem casos em que a concepção é bem genérica e muitos SSCs são criados no projeto detalhado (veja o Quadro 8.1). Esta atividade detalha a concepção. Conforme a sua denominação destaca, ela tem Objetivo desta atividade a finalidade de criar todos os Sistemas, Sub-sistemas e Componentes (SSCs) do produto, produzir as documentações finais e detalhadas, que compreendem todos os desenhos dos SSCs com cotas e tolerâncias finais, e a configuração final do produto, na maior parte das vezes refletidas na Estrutura de Produto (BOM). A partir desse ponto, essas informações serão congeladas em uma versão de configuração do produto e modificadas somente por meio de um processo de mudança de engenharia (veja o Tópico 13.1). Quadro 8.5

Termos Utilizados no Projeto Detalhado

Vamos observar a relação entre os termos principais deste capítulo e suas definições (Figura 8.4). Os elementos destacados na figura representam os termos do projeto detalhado. Como é nesta fase que as informações das fases anteriores de desenvolvimento são finalizadas, apresentamos o quadro geral de termos até agora utilizados. As definições desses outros termos estão nos quadros de termos utilizados no projeto informacional e projeto detalhado. Na tabela apresentada a seguir, estão somente os termos constantes nesta figura. Outros termos podem ser encontrados no glossário deste livro. Figura 8.4

Relação entre os principais termos usados na fase de projeto detalhado.

As definições estão na tabela a seguir:

(continua) 4

Se um sistema for bem complexo (por exemplo, um motor de um automóvel), todas as atividades descritas neste livro serão necessárias para o desenvolvimento deste sistema (neste exemplo, o motor).

302

PARTE 2

Quadro 8.5

O Modelo

Termos Utilizados no Projeto Detalhado (continuação)

Desenhos finais com tolerância

Representação gráfica de todos os itens de um produto, contendo as tolerâncias finais dos seus atributos.

Especificações finais dos SSCs

Atributos dos itens que os caracterizam e que são congelados em uma versão da configuração do produto. Nos SS, eles podem ser os parâmetros críticos e, nos componentes, as especificações críticas. Podem estar representados no desenho.

Plano de processo

Composto do plano macro e dos detalhamentos especificando como produzir ou montar um item.

Plano macro

Especificação da seqüência de operações, descrição, máquinas e tempos para produzir ou montar um item. Visa apoiar o planejamento e controle da produção.

Detalhamentos

Documentos diversos que detalham o conteúdo de uma operação para servir de referência aos operadores de máquinas e equipamentos. Pode conter: plano de preparação de máquina, programa CN, gráfico para controle estatístico do processo, plano de inspeção etc.

Projeto dos recursos

Configuração completa dos dispositivos, máquinas, equipamentos, ferramentas, fábrica e instalações necessárias para a produção, conforme as especificações do plano de processo.

Projeto de embalagem

Configuração completa das embalagens que serão utilizadas para o produto.

Material de suporte do produto

Todos os tipos de manuais necessários para a operação do produto, como: manual do usuário, manual de treinamento, manual de descarte.

Produtos

Produtos e serviços desenvolvidos para satisfazer os requisitos dos clientes e, ao mesmo tempo, os interesses estratégicos da empresa.

Estrutura de Produto Final (BOM final )

Versão final da identificação dos itens e dos relacionamentos entre eles, assim como a conexão com todos os documentos relacionados.

SSCs

Abreviatura de Sistemas, Subsistemas e Componentes.

Itens

Designação genérica para os SSCs.

Sistemas

Item do produto de mais alto grau hierárquico.

Subsistemas

Item do produto de grau hierárquico intermediário.

Componentes

Item do produto de menor grau hierárquico.

Matéria-prima

Item do produto que compõe os componentes e possui características físicas particulares.

Módulos

Itens de qualquer natureza agrupados, que possuem interfaces padronizadas e podem ser utilizados em mais de um produto (modular). Podem ser desenvolvidos, produzidos e normalmente testados separadamente. Muitas vezes representam a divisão do produto do ponto de vista do usuário.

Plataforma de produtos

Conjunto de SSCs organizados em módulos (de preferência) ou não, que permanece invariável dentro de uma família de produtos.

Famílias de produtos

Grupo de produtos similares, que normalmente compartilham muitos itens e podem derivar da mesma plataforma.

Especificações finais

Descrição completa das características físicas e funcionais do produto, bem como das descrições técnicas necessárias para construir, testar, produzir, operar, reparar e descontinuar um item. Conjunto de todos as informações documentadas relacionadas com o produto final e resultante do projeto detalhado.

Configuração do produto

Conjunto de todas as informações relacionadas ao produto. A cada momento no ciclo de vida, pode se congelar uma configuração para efeito de rastreabilidade do produto no mercado. No final do projeto detalhado, a configuração recebe a denominação de configuração de como foi projetado e equivale às especificações finais.

5

Vamos aqui distinguir dois grandes grupos de SSCs: os itens físicos e os não-físicos, como o software. Esse tópico trata basicamente dos itens físicos. Dentro do Tópico 8.3.4, vamos tecer algumas considerações sobre desenvolvimento de software. 5

Não podemos esquecer que os bens de consumo duráveis possuem, cada vez mais, software embarcado, pois são produtos mecatrônicos. Para não falar de produtos como computadores pessoais e eletroeletrônicos, para os quais o software é muito importante.

CAPÍTULO 8

Projeto Detalhado

As tarefas desta atividade estão representadas na Figura 8.5. Percebe-se que esta atividade é central na fase de projeto detalhado, pois se relaciona com praticamente todas as outras atividades da fase. Dela resultam as informações principais para a especificação final do produto. Figura 8.5

303

Tarefas desta atividade

Tarefas da atividade de criação dos SSCS.

As primeiras três tarefas acontecem quase simultaneamente, conforme o ciclo de detalhamento apresentado no Quadro 8.2, segundo o conceito de engenharia simultânea. Devido a sua abrangência e grande quantidade de métodos de PDP, utilizados na realização desta atividade, vamos colocar cada tarefa em um tópico separado.

8.3.1 Criar, reutilizar, procurar e codificar SSCs A lógica desta tarefa e seu relacionamento com as demais tarefas da atividade A lógica desta tarefa de criar e detalhar, assim como com as atividades do ciclo de aquisição, estão representadas na Figura 8.6. A concepção pode conter a definição de alguns SSCs, como vimos na descrição do projeto conceitual. Os itens que são definidos na concepção podem ser comprados ou fabricados pela empresa, e, nesse caso, devem ser projetados também. Naquela fase, já foram contatados os possíveis fornecedores dos itens a serem comprados, que, muitas vezes, tornaram-se parceiros de co-desenvolvimento. Os itens fabricados receberam então um có6 digo de identificação e depois seguem diretamente para as tarefas subseqüentes desta atividade. Normalmente, os itens estratégicos e principais já vêm definidos. 6

Como todas empresas hoje em dia de uma forma ou de outra trabalham com computador e registram os seus itens desde o início em base de dados (ou mesmo planilhas), todos os SSCs recebem um código de identificação desde as fases iniciais de desenvolvimento. Algumas empresas fornecem códigos provisórios, e somente na fase de detalhamento definem um código definitivo. Essa prática evita a proliferação de códigos, mas cria tarefas adicionais que não agregam valor ao desenvolvimento. Por isso, como os códigos são controlados por sistemas (veja o Quadro 8.5, sobre identificação dos SSCs), não deve existir a preocupação com a proliferação de códigos de identificação.

304

PARTE 2

Figura 8.6

O Modelo

Lógica da tarefa de criar, reutilizar, buscar e criar identificação.

Vamos observar um exemplo de um torno, cuja estrutura de produto resultante encontra-se na Figura 8.7. Os itens fabricados estão sublinhados e os comprados, não estão sublinhados. Na fase de projeto conceitual, os subsistemas de barramento e do cabeçote móvel foram detalhados, mas existem subsistemas que não foram. Nesse exemplo, o sistema de controle da máquina será comprado, mas mesmo assim os subsistemas principais foram identificados na concepção. Esta tarefa começa a criar os SSCs restantes, que não foram definidos no projeto conceitual. A criação não precisa envolver todos os itens que faltam de uma vez. Esse é um processo cíclico e iterativo. Neste momento, pode-se aplicar as demais casas de qualidade do QFD (veja o Quadro 6.5, sobre QFD). No nosso exemplo, vamos supor que o subsistema do eixo árvore seja desdobrado e os seus itens principais, criados (Figura 8.8). Pode acontecer que alguns dos novos itens ainda sejam estratégicos, ou seja, possuam uma tecnologia que a 7 empresa quer sob o seu domínio. Nesse caso, esses itens serão fabricados, ou seja, precisam ser projetados pela empresa. Eles recebem um código e vão direto para as fases subseqüentes de detalhamento (veja a Figura 8.6). Para os demais SSCs, sempre se deve tentar encontrar itens existentes na empresa, para tentar reutilizá-los, ou no mercado, para serem comprados. Devido a isso, o próximo passo é definir quais deles serão comprados e quais serão fabricados. Entretanto, há casos em que isso não está claro. Recomenda-se então tentar primeiro reutilizar aqueles existentes na empresa. Como resultado desse procedimento, existem cinco possibilidades (veja a Figura 8.6): a) Existe um item idêntico que pode ser reutilizado: este item já possui um código de identificação. Parte-se, em seguida, para as demais tarefas de detalhamento, nas quais ele será integrado ao conjunto de nível superior. 7

Nesta altura do desenvolvimento, não podem existir itens comprados e, ao mesmo tempo, estratégicos, que não foram definidos. Parcerias de fornecimento devem ter sido acordadas, para itens deste tipo, desde a macrofase de pré-desenvolvimento. No caso de não terem sido fechadas naquela fase, isso deve ocorrer até o final da fase de projeto conceitual.

CAPÍTULO 8

Projeto Detalhado

Figura 8.7

Estrutura de um torno resultante da concepção

Figura 8.8

Desdobramento do subsistema do eixo árvore e os seus iItens.

305

b) Existe um item semelhante ao que se deseja: este item tem de ser modificado e recebe um novo código de identificação. A seguir, ele segue para as próximas etapas de detalhamento.

306

PARTE 2

O Modelo

c) Não existe nada semelhante: caso o item deva ser fabricado e, portanto, projetado pela empresa, ele recebe um código de identificação. A próxima fase é a da criação e desdobramento dos seus componentes (se necessário). Em seguida, é realizada a tarefa de cálculo e desenho (próxima tarefa desta atividade). Nos outros casos, tenta-se encontrar algo no mercado. d) Não se encontrou nada no mercado que possa ser comprado: como no caso anterior, ele recebe um código, passando, posteriormente, para a subtarefa de criação e desdobramento dos seus componentes (se necessário). Em seguida, é realizada a tarefa de cálculo e desenho. e) Existe a possibilidade de se adquirir este item no mercado: inicia-se a atividade de procurar fornecedores, que, neste caso, pode ser simplesmente a solicitação de cotação do item encontrado. No nosso exemplo, sabíamos de antemão qual item seria comprado ou fabricado (Figura 8.8). Vamos procurar no mercado somente os rolamentos. Este exemplo é bem simples e didático. Porém, poderíamos ter dúvida em relação às engrenagens. Nesse caso, tentaríamos reutilizar aquelas já fabricadas e, em caso negativo, procuraríamos comprá-las no mercado. Como veremos mais adiante — após a finalização do ciclo inicial de detalhamento, quando as tolerâncias e os planos de processo estiverem definidos —, os itens não estratégicos (comuns) serão analisados na atividade de decidir fabricar ou comprar. Ou seja, mesmo com o seu detalhamento iniciado, pode ser que eles ainda sejam fabricados por terceiros. Estamos falando aqui da compra do serviço de fabricação do item. Depois de entender a lógica dessa tarefa, vamos explicar o que é um item estratégico; como reutilizar um item; procurá-lo no mercado; e criar um código para a sua identificação. Se um item (SSC) for core (de importância central) para o produto em questão, a empresa o define como um item estratégico. Mesmo se ele estiver disponível no mercado, a empresa pode decidir desenvolvê-lo para obter um diferencial competitivo. Um exemplo é o sistema de jato de tinta das impressoras. O seu bom funcionamento é essencial para atender aos requisitos dos clientes. Item estratégico

Às vezes, mesmo sendo core, não é viável para a empresa desenvolvê-lo, pois além de perder o foco no produto (no caso de empresas montadoras e integradoras), ela pode não conseguir o volume necessário para garantir um custo baixo, ou mesmo não dominar a tecnologia. Nesses casos, ela deve fechar uma parceria estratégica com um fornecedor deste item nas fases anteriores. Esse é o caso dos processadores (chips) nos computadores pessoais. Seria impossível uma empresa de computador ser capaz de desenvolver tecnologia madura para utilizar em seus produtos e, mesmo se conseguisse, ela não conseguiria um volume suficiente para produzir processadores a preços competitivos. Esses itens normalmente são identificados nas fases anteriores do PDP. Reutilização de itens

Desde a fase de projeto conceitual, estamos tentando reutilizar itens já existentes na empresa e definir quais serão comprados, principalmente na atividade de definir a arquitetura.

Não se procura inovar totalmente na criação de novos produtos, por causa do risco de se colocar no mercado muitas inovações de uma vez. E, do ponto de vista do mercado, um produto que reutiliza vários itens, mas apresenta algumas inovações, pode ser vendido como um produto inovador. Para a empresa, ele não é tão inovador assim. Dessa forma, consegue-se oferecer um produto novo, sem muitos riscos. Às vezes, os itens a serem reutilizados fazem parte de produtos existentes. E, se estivermos trabalhando com o conceito de plataforma e projeto derivado, ou mesmo com o conceito de customização em massa, a reutilização é planejada no momento de criação do portfólio de produtos. Na maior parte das empresas de manufatura é comum acontecer uma duplicação de itens, ou seja, o time de desenvolvimento cria novos itens que já existem. Estima-se que a duplicação abranja 10% a 30% dos itens produzidos. Isso é ainda pior em grandes empresas, principalmente quando elas adquirem outras do mesmo ramo,

CAPÍTULO 8

Projeto Detalhado

307

que provavelmente fabricam itens que poderiam ser reutilizados. A principal causa da duplicação é a forma como o item está descrito na base de dados da empresa, que não permite sua recuperação. No passado, as empresas procuraram utilizar códigos de classificação de itens baseados em tecnologia de grupo para, entre outros objetivos, recuperar informações e aumentar o nível de reutilização de SSCs. No entanto, codificar a base de itens existentes demandava muito esforço, e surgiram novas tecnologias que trouxeram benefícios maiores. Consulte no Quadro 8.6, sobre a classificação de itens, os conceitos de tecnologia de grupo e a evolução das formas de agrupar itens semelhantes, para entender melhor esses conceitos. Quadro 8.6

Classificação de Itens 8

A primeira sistematização da classificação de itens começou com a Tecnologia de Grupo (TG) nos anos 1960. TG é uma filosofia na qual itens ou outros objetos (planos de processo, produtos, montagens, ferramentas etc.) similares são identificados e agrupados para se aproveitarem as vantagens de suas similaridades nas diversas atividades da empresa (projeto, manufatura, compras, planejamento e controle da produção etc.). O aproveitamento dessas similaridades ocorre de três maneiras:

• executando-se atividades similares em conjunto, evitando-se assim perda de tempo com as alterações necessárias para mudar de uma atividade para a outra não relacionada (ex.: a fabricação, em seqüência, de duas peças com características similares reduz o tempo de setup entre as operações);

• padronizando as atividades similares e relacionadas, focando assim apenas nas diferenças necessárias e impedindo duplicação de esforços (ex.: redução da variedade de parafusos utilizados);

• armazenando e recuperando informações de forma eficiente, principalmente as relacionadas com problemas recorrentes, reduzindo assim o tempo de procura por informações, bem como eliminando a necessidade de resolver novamente um problema já solucionado (ex.: utilizar em um novo produto itens já existentes).

Conseqüências da classificação Uma das conseqüências é a redução da proliferação desnecessária de novos itens (peças compradas e fabricadas, dispositivos de fixação, ferramentas etc.). Na manufatura, os ganhos de eficiência vêm da: redução dos tempos de setup, programação em seqüência de peças de uma mesma família, melhoria no controle do processo, planos de processo e instruções padronizadas, formação de células de manufatura e aumento da qualidade. As vantagens no projeto são obtidas principalmente com a recuperação de informações, a padronização de itens e sua conseqüente não-proliferação. Por exemplo, quando os engenheiros recuperam desenhos existentes para utilizar em novos produtos e quando peças são padronizadas para prevenir sua proliferação.

Sistemas de Codificação e Classificação Na implementação da Tecnologia de Grupo, os Sistemas de Codificação e Classificação (SCC) surgem como uma poderosa ferramenta de auxílio, pois fornecem uma estrutura, baseada em atributos selecionados para esses objetos, para classificar os objetos em famílias. Diversos sistemas foram desenvolvidos no passado e selecionados de acordo com as necessidades de cada empresa, não existindo um sistema universal. Esses sistemas iniciaram-se com o uso de códigos alfanuméricos, porém, com o avanço da tecnologia da informação, alguns deles têm representado as características das peças por meio de seus atributos. Na utilização de Sistemas de Classificação, para o apoio à implementação da Tecnologia de Grupo, é importante que a estrutura de classificação atenda aos objetivos de aplicação e sejam flexíveis para suportar futuras alterações no produto ou introdução de novos produtos, novas tecnologias de produto e processo, e integração da base de dados.

Sistemas de Codificação e Classificação substituídos por base de dados flexíveis Com o advento dos sistemas gerenciadores de base de dados relacional, os princípios anteriormente expostos puderam ser adotados, fazendo com que os sistemas de classificação baseados em códigos de muitos dígitos caíssem em desuso, pois ele era dúbio e a classificação de um produto dependia demasiadamente da habilidade da pessoa que o codificou. Além disso, esses códigos não permitiam uma evolução dos critérios adotados para o significado de um dígito. Se um dígito, por

(continua) 8

Também conhecida, em inglês, como Group Technology (GT).

308

PARTE 2

Quadro 8.6

O Modelo

Classificação de Itens (continuação)

exemplo, representasse uma faixa de valor de uma dimensão, essa faixa deveria ser sempre significativa para empresa. O código não serviria se houvesse a necessidade se identificar produtos com diferentes valores de dimensão dentro daquela faixa. Isso é eliminado com o uso de base de dados, pois o valor exato de cada atributo do produto é armazenado e a busca pode ser mais precisa. Uma boa prática é utilizar um sistema de classificação de poucos dígitos, para se formarem “grandes famílias” de itens. Para atingir o benefício da tecnologia de grupo, deve-se usar as bases de dados na formação de famílias de itens. O uso dessa filosofia elimina a necessidade de códigos de identificação significativos (veja o Quadro 8.9, sobre identificação de itens). Muita confusão tem ocorrido entre a Tecnologia de Grupo (TG), os sistemas de classificação e o projeto de células de manufatura. Deve ficar bem claro que o sistema de classificação é um meio para a implantação da TG, e a célula de manufatura é uma das aplicações de TG.

Uso da classificação para busca de itens pela Internet Hoje existem sistemas de Gerenciamento de Componentes e Suprimentos (CSM — Component and Supplier Management), que oferecem suporte para a busca de componentes, além de uma empresa específica. Isso promete revolucionar a busca por componentes semelhantes no desenvolvimento de produto, via e-procurement, que, por sua vez, necessita de sistemas de classificação “universais”, amplamente aceitos e adotados pelas empresas (veja o Quadro 8.7, sobre CSM). Leia mais sobre este assunto em OLIVEIRA, 1999.

Hoje em dia, a reutilização tem um sentido mais amplo. Procura-se reutilizar itens e tecnologia de produtos dos concorrentes (descobertos por meio de estudos de benchmarking) e de produtos análogos. Uma boa prática é realizar inovações tecnológicas em no máximo 20% dos itens de um novo produto. Pode-se utilizar um indicador do grau de reusabilidade de um produto, que mostra o quanto de um produto é novidade ou não.9 Como vimos na Figura 8.6, na qual a lógica dessa tarefa foi apresentada, a reutilização está intimamente ligada com a procura de itens no mercado. Novamente enfatizamos que, assim como a reutilização, a procura de itens no 10 Procurar itens no mercado mercado vem acontecendo desde a fase de projeto conceitual. Reutilizar um item interno e comprar um item no mercado são duas faces da mesma moeda. A procura por itens normalmente não é suficientemente abrangente, pois as informações dos fornecedores não são padronizadas. É difícil procurar itens pesquisando seus atributos. Por mais que os novos sistemas de informação forneçam base de dados flexíveis, falta acesso às informações (mais técnicas) dos produtos disponíveis no mercado. Muitos times de desenvolvimento acabam criando novos itens porque não encontram nada similar no mercado. A publicação de catálogos na Internet, o conceito de classificação de itens (veja o Quadro 8.6), e a potencialidade dos sistemas de Component and Supplier Management (CSM ) fornecem possibilidades sem precedentes para se encontrar um item no mercado, que satisfaça os requisitos desejados (veja o Quadro 8.7 sobre sistemas CSM, catálogos na Internet e o e-procurement). Esses sistemas fornecem um ambiente único e integrado para a reutilização de itens e sua procura no mercado.

9 10

Veja uma discussão completa sobre reusabilidade no livro de CLAUSING, D., Total quality development, 1993. Hoje se utiliza o termo em inglês sourcing para o que chamamos de procura de itens no mercado.

CAPÍTULO 8

Projeto Detalhado

Quadro 8.7

309

Sistemas CSM, Catálogos na Internet e o e-procurement

Apesar de estarmos falando de software, queremos enfatizar o conceito da integração da reutilização com a procura por itens no mercado. A questão básica que se quer responder com este conceito é aquela que se deve formular durante as fases iniciais do PDP: existe algum item (SSC) que pode ser reutilizado e satisfaça os requisitos do produto? É um item interno ou fornecido por terceiros? No passado, com os sistemas de codificação e classificação de peças por tecnologia de grupo, não conseguíamos codificar todos os itens existentes e a codificação só abrangia itens internos da empresa e não novos itens que existem no mercado. Os sistemas Component and Supplier Management (CSM) permitem classificar os itens de uma forma flexível; padronizá-los; gerenciar um cadastro de fornecedores potenciais, acessando seus catálogos de produtos; e recuperar essas informações de forma flexível. Os sistemas de e-procurement apóiam a compra de quaisquer tipos de itens, mas estão mais voltados para as questões burocráticas, comerciais e financeiras. A procura (sourcing) é limitada. Sistemas de e-procurement estão inseridos em sistemas mais amplos de suprimento, denominados por alguns fornecedores de Supplier Relationship Management (SRM — Gestão do Relacionamento com os Fornecedores). O CSM é uma solução que pode funcionar de maneira integrada com esses sistemas, e o seu foco está no suporte à reutilização e procura de itens. Os sistemas CSM oferecem ferramentas flexíveis de classificação, que interpretam dados de itens em base de dados sem necessitar de um esquema fixo de classificação; podem trabalhar com os sistemas existentes; tem uma interface amigável de navegação; tornam-se uma interface única de procura (unifica os catálogos digitais); permitem a criação de listas e links preferenciais; podem ser integrados aos sistemas CAD, PDM e ERP. Assim, os catálogos de fornecedores ficam integrados a um único ambiente de trabalho. Um dos problemas ainda não resolvidos completamente, é o de garantir que a busca acesse todas as possibilidades existentes. Por enquanto, os fornecedores precisam oferecer os seus catálogos e integrá-los a sistemas maiores, como ERP ou CSM. Isso significa que ambos os sistemas utilizam o mesmo protocolo de comunicação e que os atributos dos itens do fornecedor seguem um padrão e estão acessíveis para a consulta. Ou seja, um projetista pode buscar um componente, conhecendo somente algum atributo que ele deseja. O sistema busca e fornece todas as opções que atendam ao critério de busca. Por exemplo, um projetista pode procurar um motor elétrico com a potência de 5 W, que possua outras características mais específicas. O sistema traz todas as opções, independentemente de fornecedor. Já existem iniciativas de se criarem descrições-padrão para itens padronizados, facilitando a sua busca na Internet. Além disso, já surgem também sistemas autônomos (conhecidos como agentes) que ficam navegando na Internet e alimentam o catálogo de busca da empresa, conforme as suas necessidades específicas. Assim, cada vez que uma empresa publicar o catálogo de seus produtos na Internet, o agente o encontraria e o incluiria no sistema de procura da empresa. Leia mais sobre CSM em NITIDUS; e sobre busca de produtos para comprar na Internet em EULALIA, 2002.

É importante que a empresa realize atividades de padronização de projeto, pois assim diminui a quantidade de alternativas e aumenta o grau de reuso dos seus itens, com conseqüente diminuição de custos e das variações no estoque e processo de fabricação (veja o Quadro 8.8, sobre padronização no projeto).

Quadro 8.8

Padronizar também garante reuso de SSCs

Padronização no Projeto

A padronização durante o processo de desenvolvimentos de produtos ocorre em diferentes circunstâncias, sendo resultado de diferentes ações. Os tipos mais abrangentes de padronização encontrados no PDP são os advindos de organizações com reconhecida autoridade em âmbito nacional, como ABNT no Brasil; AFNOR na França; BSI no Reino Unido; DIN na Alemanha; ANSI nos Estados Unidos da América etc., e internacional, a exemplo da International Organization for Standartization (ISO) e da International Electrotechnical Comission (IEC), resultantes da cooperação entre nações com interesses comuns. Esse tipo de normalização sempre resulta em padrões que devem ser obrigatoriamente atendidos pelos produtos desenvolvidos. As normas podem definir, de forma abrangente ou específica, diferentes aspectos relacionados a um produto (terminologia; es-

(continua)

310

PARTE 2

Quadro 8.8

O Modelo

Padronização no Projeto (continuação)

pecificação; amostragem e inspeção; ensaios e análises; limitação e variedades; classificação; comunicação; código de prática; embalagem; conservação; transporte; distribuição; segurança etc.) para diferentes setores industriais. Além dos padrões definidos pelas normas de tais organizações, as próprias empresas (ou grupos de empresas e setores industriais) podem estabelecer padrões mais específicos. Esses padrões abordam temas mais próximos do cotidiano da empresa e afetam as especificidades dos produtos, processos ou a estrutura organizacional da empresa. No caso do processo de desenvolvimento de produtos padrões, eles podem ser usados para:

• Definir uma lista de componentes ou materiais preferenciais a serem adotados durante o projeto. Por exemplo, uma empresa pode estipular que, dentre os parafusos normalizados, existentes no mercado, serão preferencialmente utilizados os de diâmetros 4, 8 e 12mm, independentemente do valor do diâmetro calculado, sendo sempre escolhido o diâmetro superior mais próximo. Isso diminui a variabilidade de itens comprados e, portanto, o seu estoque.

• Estabelecer ou atualizar tolerâncias, acabamentos, geometrias e outras features que se consegue obter com os equipamentos disponíveis na empresa, bem como o custo associado para obtê-los. Essas informações são de grande utilidade durante a fase de detalhamento do produto, pois permite à equipe de desenvolvimento selecionar os equipamentos mais econômicos e, ao mesmo tempo, desenhar os componentes de forma a serem manufaturáveis pelos equipamentos escolhidos. Esse é um dos aspectos do Design For Manufacturing (DFM). Veja o Quadro 7.8, sobre DFX. Tais padrões devem ser utilizados somente quando for útil e econômico, houver uma real necessidade, estiverem de acordo com as normas existentes, forem de fácil entendimento por parte de seu executor, não se constituírem em um empecilho à criatividade e ao trabalho da equipe de desenvolvimento e representarem questões absolutamente técnicas. O uso de padrões tem como vantagens:

• Melhora da qualidade — os padrões representam práticas a serem adotadas durante longos períodos pela empresa, tornando seu controle mais fácil e simples, e estão diretamente vinculados ao atendimento ou não do padrão. Eles também podem evoluir com o tempo de forma a melhorar continuamente.

• Maior confiabilidade — confiabilidade é, por definição, a probabilidade de que um produto ou componente tenha um desempenho satisfatório, durante certo período de tempo, quando operado e mantido sob as condições especificadas. O uso de padrões reduz os riscos de falhas, pois utiliza especificações mais estudadas e já usadas em sistemas existentes.

• Maior intercambiabilidade — resultante da padronização de componentes e de processos de fabricação. • Disponibilidade — as normas técnicas criadas, principalmente aquelas provenientes dos órgãos governamentais, podem levar as empresas a produzirem tais componentes padronizados em grandes volumes (os chamados commodities). Com o crescimento do número desses fabricantes, aumenta-se a disponibilidade devido às alternativas de suprimento. No mercado existe uma infinidade desses commodities, como: parafusos. rolamentos, acoplamentos, motores elétricos, bombas etc.

• Redução de variedade — com a padronização, eliminam-se variantes desnecessárias de SSCs e, assim, pode-se concentrar maior esforço no desenvolvimento, fabricação e testes em um menor número de tipos de componentes, sistemas ou produtos como um todo.

• Economia — as vantagens econômicas incluem compras em maiores quantidades de um tipo de material ou componente; menor movimentação de papéis ou troca de informações e na inspeção de recebimento dos materiais; redução de espaços físicos de armazenamento e de controle de estoques; menos tempo na busca de informações em manuais ou normas da empresa. Além disso, ao se adotar um componente normalizado, economiza-se tempo e recursos necessários para o projeto e a fabricação de um novo componente. Algumas técnicas podem auxiliar na definição de padrões na empresa, dentre as quais o projeto modular, que permite definir sistemas padronizados (os módulos) que podem ser compartilhados entre diversas linhas de produtos. Desta forma, o projeto modular (veja o Quadro 7.6) auxilia na redução da variedade, na intercambiabilidade do produto e, em certos casos, até mesmo na sua disponibilidade. Leia mais sobre este assunto em PAHL, 1996.

Criação do código de identificação

Como vimos na Figura 8.6 sobre a lógica desta tarefa, todos os novos itens precisam ser identificados, ou seja, deve-se atribuir um número a ele, ou melhor, um código de identificação. No quadro sobre identificação de itens, são apresentadas as melhores práticas existentes para a realização desta tarefa.

CAPÍTULO 8

Projeto Detalhado

Quadro 8.9

311

Identificação de Itens

A identificação e classificação de itens, e a conseqüente identificação de documentos e outros objetos referentes a esses itens, é uma das três áreas da gestão de configuração (veja o Quadro 13.1 sobre a Gestão da Configuração). O Número de Identificação (PN — Part Number ou Item Number) serve para identificar de forma única um item. O número (ou código) de identificação de um produto (popularmente chamado de “código falante”) pode ser significativo ou não.

Número significativo Um número significativo contém informações sobre o item, por exemplo: PN 123 F 456 3, em que 123 identifica o tipo de material; F, que é fabricado; 456 é o número do desenho de engenharia e 3, o formato do papel do desenho, neste caso, A3. Diversos autores criticam e não recomendam o uso de números de identificação significativos devido à série de problemas e desvantagens inerentes ao seu uso, como: o significado de um dígito pode ser interpretado de forma errada; pessoas diferentes podem assinalar dígitos diferentes para uma mesma característica; a criação de um sistema de números de identificação significativos não é uma tarefa fácil ou rápida, exigindo um grande esforço no seu desenvolvimento e no treinamento dos usuários. A flexibilidade desse sistema é também pequena, pois alterações nas características do produto podem tornar dígitos, antes significativos, em não significativos, ou implicar esforço adicional de manutenção. Essas são as razões principais. Imagine se a empresa resolve comprar o item mostrado anteriormente e tem de mudar o dígito “F” para “C". Ela deveria alterar todos os documentos e estruturas relacionadas. Esses problemas são intensificados se o número de identificação for longo. Além disso, muitas empresas utilizam dígitos alfanuméricos para possibilitar a existência do maior número de caracteres disponíveis. Porém, dígitos alfanuméricos possuem maior possibilidade de erros, devido a similaridades que existe entre alguns números e letras, como “l” (ele), “I” (i) e “1” (um); “O” (ó) e “0” (zero); “Z” (zê) e “2” (dois). Números significativos faziam sentido quando os computadores possuíam capacidade muito pequena de armazenamento e baixa velocidade de processamento, sendo necessário utilizar o seu significado como uma forma de acesso rápido e fácil às informações do item. Com a atual tecnologia de base de dados relacional, é possível transferir as informações que estavam no número para o arquivo mestre de informações do item e/ou para o sistema de classificação. O computador possibilita a associação entre a identificação e outros atributos dos itens, com recuperação rápida dessas informações. Dessa forma, não se depende mais de números significativos, o que possibilitou o uso de números menores sem significado. Se o número significativo for usado, ele será redundante com as informações armazenadas no arquivo mestre do item e no sistema de classificação, e a necessidade de atualizar a mesma informação em mais de um lugar pode levar a inconsistências.

Número sem significado O número de identificação deve ser baseado apenas em caracteres numéricos absolutamente sem significado, com o menor tamanho possível, designado seqüencialmente. O equivalente ao Registro Geral (RG ) da nossa Carteira de Identidade, ou o número do Cadastro Geral de Pessoa Física (CPF). Existem ainda questões que precisam ser esclarecidas sobre o número de identificação, como: — A quais itens deve ser fornecido um número de identificação? — Quando é necessário trocar o número de identificação? Por exemplo, se um item-filho é trocado por um outro item, o número de identificação do item-pai deve ser trocado ou mantido? Essas questões são importantes, é um dos assuntos centrais da gestão de configuração, e as informações adicionais citadas trazem as respostas. Então, hoje, a melhor prática é utilizar um número de identificação não significativo e utilizar um outro código para classificação (veja o Quadro 8.6, sobre classificação de itens). Consulte mais sobre este assunto nas informações adicionais, em OLIVEIRA, 1999.

Discutimos anteriormente sobre os ciclos desta atividade (veja a Figura 8.2) e dissemos que iríamos apresentá-la de forma seqüencial (única forma de apresentação em um livro). Após entender a lógica da primeira tarefa, queremos lembrar novamente que ela pode ter ocorrido durante o projeto conceitual, e mostrar que também pode ocorrer durante o projeto detalhado, e não somente no seu início.

Não esquecer que a realização desta atividade é cíclica e constante

312

PARTE 2

O Modelo

Durante as tarefas de cálculo, desenho, simulação e otimização dos SSCs, podem surgir novas soluções, para as quais se deve especificar novos itens. Nesses momentos, é necessário realizar novamente essa tarefa. Em outras palavras, sempre que um novo item é criado, deve-se tentar reutilizar o que existe, procurá-lo no mercado e comprá-lo (quando não for estratégico), além de codificá-lo.

8.3.2 Calcular e desenhar os SSCs Esta é a segunda tarefa da atividade de criar e detalhar os SSCs. Na definição dos novos SSCs, deve-se atentar para aqueles itens e características que são críticas para atender aos requisitos do produto. Esse foco deve ser garantido pelo gerenciamento dos parâmetros críticos do produto, como discutido no Quadro 8.10. Quadro 8.10

Gerenciamento dos Parâmetros Críticos (CPM) de um Produto

Apesar deste quadro estar localizado neste capítulo do projeto detalhado, o gerenciamento dos parâmetros críticos — também conhecido pela sigla CPM, de Critical Parameter Management — é realizado desde o desenvolvimento da tecnologia (outro processo de negócio relacionado com o PDP — veja o Capítulo 1). Os parâmetros críticos dos sistemas e subsistemas começam a ser definidos desde a fase de projeto conceitual (Figura 8.9). Figura 8.9

Relação entre os resultados do PDP e termos do gerenciamento de parâmetros críticos.

As necessidades dos clientes são transformadas em requisitos do cliente, que são convertidos nos requisitos do produto na fase de projeto informacional. Esses requisitos formam as especificações-meta do produto e são caracterizados por valores-meta quantificáveis, como: a dimensão de uma máquina, a precisão de posicionamento das pontas de fixação das peças na máquina, a cor de um automóvel, o nível de ruído do seu motor, a rotação do tambor de uma máquina de lavar, a velocidade de impressão de uma máquina copiadora etc. Na verdade, os requisitos do produto representam o desempenho esperado do produto. Das especificações-meta, são definidas as funções do produto, para as quais se determinam os princípios de solução. Ao mesmo tempo, os requisitos de produto são desdobrados em requisitos dos SSCs, que, juntamente aos princípios de so-

(continua)

CAPÍTULO 8

Projeto Detalhado

Quadro 8.10

313

Gerenciamento dos Parâmetros Críticos (CPM) de um Produto (continuação)

lução, definem as especificações dos SSCs principais (aqueles SSCs que já se consegue definir no projeto conceitual). Isso significa que os parâmetros críticos são determinados desde o projeto conceitual. Parâmetros são variáveis mensuráveis dos SSs (repare que estamos falando dos sistemas e subsistemas, e não dos componentes), que afetam diretamente seu desempenho e contribuem para a obtenção dos requisitos dos produto, que são variáveis dependentes das especificações dos SSs. Os parâmetros dos SSCs, por sua vez, dependem das especificações dos componentes (Cs), conhecidas como variáveis independentes. Especificações são variáveis que os engenheiros conseguem manipular e são relacionadas com as funções do produto. Elas são expressas por grandezas físicas, como: força, posição, tamanho, temperatura, voltagem, amperagem, tempos etc. O uso do termo crítico serve para dar uma conotação de importância maior a um parâmetro ou especificação em relação a outro. Algo que é essencial, primário, principal, significante. Alguns parâmetros são críticos, pois estão diretamente relacionados com o atendimento das necessidades (críticas, importantes etc) dos clientes. Normalmente, entre todos os parâmetros de um SS, poucos são críticos. Trabalhar com os críticos fornece foco à atuação do time de desenvolvimento. Comumente, um parâmetro crítico de um sistema ou subsistema é resultante da especificação crítica de um componente, que é marcada de forma especial nos seus desenhos (algumas vezes, denominados de característica-“estrela” do componente, pois são marcadas com uma estrela no desenho). Uma especificação crítica é obtida por meio do controle do processo de fabricação. No entanto, não existe na natureza qualquer atributo que seja exato, pois ele resulta de grandezas físicas, cujos valores são variáveis. Deve-se, portanto, especificar, nas especificações críticas e seus valores-alvo, as tolerâncias aceitáveis para a variabilidade. Por exemplo, uma dimensão de 150mm pode variar dentro da faixa de 149,995 até 150,005 para continuar a atender aos requisitos de produto. A tolerância, neste caso, é de +/- 0,005mm, ou seja, de 0,01mm. Todas as grandezas físicas possuem uma faixa de variação de tolerância. O gerenciamento dos parâmetros críticos é constituído das etapas cíclicas de definição e implementação dos parâmetros. Na Figura 8.10, está ilustrada a relação desses ciclos com o modelo de referência deste livro. Figura 8.10

Relação entre ciclos de definição e implementação do gerenciamento dos parâmetros críticos e o PDP do modelo de referência.

(continua)

314

PARTE 2

Quadro 8.10

O Modelo

Gerenciamento dos Parâmetros Críticos (CPM) de um Produto (continuação)

A definição trata da identificação e quantificação dos parâmetros da tecnologia dos SSCs e suas especificações, que garantem que as respostas dos sistemas e subsistemas às entradas planejadas serão sempre as mesmas, sem depender das condições de uso e interferências do meio (ruídos). Note na Figura 8.9 que essas respostas (os parâmetros críticos) influenciam os requisitos do produto. A definição compreende os seguintes passos: 1. Analisar as entradas e saídas do produto com base na modelagem funcional do produto (veja a fase de projeto conceitual no Capítulo 7); 2. Identificar a lista inicial dos parâmetros críticos com base: na lista das funções do produto expressas nos princípios de solução (veja a Figura 8.9); em sistemas e subsistemas similares; em dados de experimentos anteriores relacionados com a mesma tecnologia; em modelos teóricos ou empíricos já utilizados e nas características detectadas na análise de falhas; 3. Planejar e executar experimentos (veja o Tópico 8.8, sobre avaliação dos SSCs e o Quadro 8.24, sobre planejamento de experimentos, e Quadro 8.26 sobre projeto robusto); 4. Otimizar, verificar e validar valores das tolerâncias; atualizar as especificações dos SSCs. A implementação dos parâmetros críticos envolve a criação e, principalmente, a avaliação das especificações críticas dos componentes e suas tolerâncias. O planejamento do processo de fabricação garante a obtenção dos componentes dentro dos valores desejados, mas ele só é validado na fase de preparação da produção. Ela compreende os seguintes passos: 1. Desdobrar os requisitos do produto em requisitos dos SSCs e compatibilizá-los com os parâmetros identificados da etapa de definição; 2. Definir as especificações dos componentes durante o detalhamento dos seus desenhos e a especificação das tolerâncias; 3. Avaliar o desempenho dos SSCs; 4. Avaliar os processos de fabricação e tolerâncias. O tamanho dos círculos da Figura 8.10 mostra qualitativamente a quantidade de esforço relativo necessário para o gerenciamento dos parâmetros nas diversas fases do modelo unificado. Este tema é um assunto atual na comunidade de desenvolvimento de produtos, e envolve diversos outros métodos clássicos, utilizados no PDP. Consiste em definir, desde as primeiras etapas do PDP, quais são os parâmetros críticos do produto e dos SSCs. Em seguida, eles são avaliados durante a criação do produto, especificação dos SSCs, construção e teste do produto, sua homologação final e aprovação da fabricação do lote piloto na fase de preparação da produção. O CPM é um dos pontos centrais do Design for Six Sigma (DFSS) difundido atualmente. O CPM permite que o time de desenvolvimento foque sua atenção nas “poucas coisas” mais relevantes do produto, relacionadas ao custo e à qualidade, desde as fases iniciais do PDP. Os temas principais a serem tratados aqui consideram as características físicas do produto, decisões de engenharia, integração de sistemas, trabalho em equipe, medição do desempenho do produto e os seus SSCs, por meio de ensaio e fundamentos da estatística. É um dos temas principais do design for six sigma (veja o Capítulo 16). Isso é particularmente importante, pois o meio ambiente onde o produto vai ser aplicado possui condições variáveis, que não podem ser controladas e que podem influenciar no seu desempenho. Então, deve-se prever essas variações com antecedência, para evitar que muitas modificações sejam realizadas no final do PDP. As otimizações realizadas nos SSCs são importantes para se melhorar o produto final, e o CPM ajuda a manter a integridade entre os SSCs e o produto final. Trata-se aqui de medir funções e valores relacionados com as leis da física, procurando-se controlar a transformação e o fluxo de energia, massa e dimensões. São medidas preventivas para evitar problemas de custo, qualidade e tempo de desenvolvimento durante o ciclo de vida do produto. Os valores dos parâmetros críticos do produto são medidos e avaliados por meio do tratamento dos seus valores médios e desvios-padrão. Dos SSCs, mede-se ainda as mesmas variáveis e ainda os coeficientes de variabilidade e a relação ruído/sinal (esses termos são definidos no Quadro 8.26 sobre projeto robusto que trata das mesmas variáveis). Os principais métodos utilizados no PDP, relacionados com o CPM, são: QFD, FMEA, análise de valores, análise de tolerância, projeto robusto (método Tagushi), capabilidade do processo de fabricação, DFX. O QFD é utilizado para identificar os requisitos do produto e também para definir os principais SSCs e seus parâmetros críticos (veja também fase de projeto informacional, no Capítulo 6, e conceitual, no Capítulo 7). O FMEA é utilizado para analisar as falhas de potenciais do produto e identificar as características importantes, relacionadas a essas falhas, e, portanto, fonte de preocupação que deve ser quantificada em parâmetros críticos, para poder ser controlada durante o PDP. A análise de va-

(continua)

CAPÍTULO 8

Projeto Detalhado

Quadro 8.10

315

Gerenciamento dos Parâmetros Críticos (CPM) de um Produto (continuação)

lores (termo utilizado quando o produto existe; quando ele está sendo desenvolvido, utiliza-se o termo engenharia de valores) é aplicada para otimizar soluções selecionadas. A análise de tolerância trata de como combinar os SSCs (integrar) e medir o resultado do acúmulo de tolerâncias, resultando na tolerância do parâmetro final. Esse método é muito importante para o CPM e faz parte da descrição das tarefas da fase de criação e integração dos SSCs. O projeto robusto é utilizado na execução dos ensaios necessários para validar os parâmetros (veja Quadro 8.26). A capabilidade de processo é utilizada para se levantar os índices do processo de manufatura (veja o Quadro 9.2, sobre capabilidade de processo) e serve para monitorar o processo, procurando garantir que ele consiga fornecer as tolerâncias das especificações dos SSCs, que resultam nos parâmetros críticos do produto final. Todas as atividades previstas para CPM possuem custos associados. Deve-se prever a utilização completa deste conceito para produtos que utilizam novas tecnologias, como no primeiro desenvolvimento de uma plataforma. Os desenvolvimentos de outros produtos derivados, ou mesmo produtos distintos que utilizam a mesma tecnologia, não precisam aplicar todas as etapas descritas, pois eles reutilizam os elementos da tecnologia já desenvolvidos e validados. Porém, o conceito de CPM continua válido e deve ser aplicado, principalmente na validação das especificações críticas dos componentes e avaliação dos processos produtivos. Sintetizando o que foi apresentado, o CPM deve nortear o PDP (e, portanto, o modelo apresentado neste livro) na geração, seleção, integração, otimização, e balanceamento dos SSCs, suas funcionalidades e os processos de fabricação, que resultam no produto final.

Vamos analisar esta tarefa de calcular e desenhar, segundo os tipos de SSCs fabricados (Figura 8.11). Figura 8.11

Tipos de SSCs, segundo o grau de conhecimento e inovação da tecnologia.

Os SSCs novos são aqueles que nunca foram desenvolvidos anteriormente pela Os itens são novos para empresa, seja do ponto de vista de tecnologia, ou mesmo da forma, dimensão ou toempresa ou conhecidos? lerância. Observe que não estamos falando do produto final e, sim, das suas partes constituintes, os SSCs. Em outras palavras, não se podem aplicar conhecimentos adquiridos em experiências anteriores ou mesmo conhecimentos comuns. Os SSCs conhecidos, por sua vez, foram desenvolvidos no passado ou são similares aos já criados pela empresa, ou seja, existe experiência interna acumulada. Esses itens devem ter sido reutilizados, ou seja, recuperamos um item idêntico ou semelhante, mas precisamos ainda verificar como ele se comporta dentro do novo subsistema ou sistema. Vamos supor, no nosso exemplo do torno, que a nossa empresa só tinha experiência na produção de tornos convencionais e que esse seja o primeiro torno CNC. Não temos experiência alguma com os controladores, que serão comprados, mas devemos criar as interfaces com os sistemas mecânicos que fabricaremos. Devemos também pensar nos novos conceitos de barramento, carro, porta, ferramenta, fuso de esferas recirculantes etc. Reutilizaremos, porém o subsistema de emissão do fluido de corte, automatizando somente o seu acionamento. Outro aspecto a ser considerado é o grau de inovação da tecnologia empregada Qual é o grau de inovação nos SSCs. De um lado, existem as tecnologias tradicionais — como a mecânica, elétecnológica do item? trica, pneumática e hidráulica — que são difundidas há vários anos e cujo conhecimento está acumulado nas bibliografias existentes. Seus fornecedores deixam à disposição procedimentos de cálculo, que são muitas vezes utilizados por vários projetistas, como no cálculo de elementos de máquina (rolamentos, mancais de deslizamento, retentores, juntas etc.). Por outro lado, existem tecnologias ainda tradicionais, como a eletrônica de microprocessadores, cuja aplicação e componentes são padronizados, mas não há tanto conhecimento acumulado sobre elas, como no caso anterior. Sempre surgem

316

PARTE 2

O Modelo

novos componentes no mercado e é difícil acompanhar as novidades. Os conhecimentos mais gerais sobre essas tecnologias são ensinados em cursos técnicos e de engenharia, mas, em alguns casos, deve-se aprender e monitorar os avanços constantemente (essa pode ser uma das funções da vigilância tecnológica, veja o Quadro 4.3). As empresas que possuem experiência acumulada com essas tecnologias podem criar internamente inovações e difundi-las para os seus funcionários e parceiros que participam do processo de desenvolvimento de produtos. Finalmente, existem as tecnologias inovadoras, como a nanotecnologia, as relacionadas com novos materiais, ótica, sensores e atuadores inteligentes, química, bioquímica, semicondutores etc. A empresa que trabalha com essas tecnologias e não dispõe de conhecimento próprio acumulado terá grandes dificuldades em aplicar essas inovações em seus produtos e dependerá de acordos com parceiros que as dominam. No exemplo do torno, estamos tratando de tecnologias tradicionais. No projeto conceitual, os SSCs conhecidos podem ser especificados com Calcular e desenhar os maiores detalhes, contendo, inclusive, a maior parte das tolerâncias iniciais relacioSSCs conhecidos no nadas com os parâmetros críticos do produto. Nesses casos, um desenho inicial é projeto conceitual ou no criado durante o projeto conceitual. A empresa pode possuir sistemas CAE capazes detalhado? de simular a sua aplicação com base neste desenho. Dessa forma, há a possibilidade de realizar testes na fase de projeto conceitual, envolvendo não somente as questões de forma, aparência, mas também as funcionais (Figura 8.12). Figura 8.12

Síntese das características do cálculo e desenho dos SSCs.

No projeto detalhado, podem ser realizados alguns cálculos de dimensionamento e/ou otimização em cima das especificações do desenho inicial. Esses cálculos servem para verificar as especificações feitas no projeto conceitual. No caso de tecnologia tradicional, as tolerâncias especificadas anteriormente possuem certa precisão (veja explicação a seguir sobre a especificação de tolerância), pois existe o conhecimento sistematizado. Em novas tecnologias, o desenho vindo do projeto conceitual é utilizado para se fazerem os cálculos de dimensionamento e, em seguida, serão detalhadas as tolerâncias, que podem resultar desses cálculos. No caso de SSCs novos para a empresa, os testes realizados na fase de projeto Cálculo e desenho para conceitual preocupam-se com alguns aspectos do produto — como forma e apaSSCs novos para a rência — e somente algumas tolerâncias são estabelecidas (Figura 8.12). Mas muitas empresa vezes, para esse tipo de SSC, não se consegue montar qualquer protótipo, pois muitos deles precisam ser ainda especificados no projeto detalhado. Nesses casos, é comum que a concepção só contenha algumas características genéricas dos SSCs e que eles sejam criados na hora do detalhamento. Pode ser realizado um desenho inicial para servir de referência para os cálculos. Após os cálculos, o desenho inicial é ajustado até estar dentro das especificações desejadas. Ele é então acrescido das tolerâncias e finalizado.

CAPÍTULO 8

Projeto Detalhado

317

Nesses casos, é utilizado o método de especificação experimental de tolerância, no qual os valores iniciais são avaliados por meio de ensaios descritos no Tópico 8.8. Quando o SSC utiliza tecnologia tradicional, pode-se usar equacionamentos, manuais e sistemas conhecidos, e, às vezes, de domínio público, para calcular suas especificações e desenhá-los. No entanto, se a tecnologia for inovadora, devem ser utilizados novos equacionamentos e podem ser construídos protótipos para se avaliarem os sistemas e/ou produto resultantes.

Utilizar procedimentos de cálculos maduros para tecnologia tradicionais

A maior parte de elementos mecânicos de máquina, por exemplo, é dimensionadas com base em conhecimentos que estão sistematizados há mais de 100 anos, como a seleção de um rolamento. Os fornecedores de rolamento já possuem sistemas de seleção e dimensionamento na Internet. Lógico que estamos falando dos casos normais de aplicação. Casos mais complexos devem ser tratados de forma especial, com a especificação empírica de tolerâncias. Mas deve-se ter em mente que, muitas vezes, não vale a pena especificar componentes especiais se existem componentes padronizados ou outros produzidos no passado que podem ser reutilizados. O custo de um componente especial é muito alto e deve ser muito bem justificado. A própria empresa deveria definir seus componentes padronizados para não multiplicar a quantidade de itens em estoque desnecessariamente (veja Quadro 8.8, sobre padronização de projetos). Durante os novos desdobramentos e definições dessa tarefa de cálculo, pode-se acionar novamente a tarefa de criar, reutilizar, procurar e codificar um item. Vamos mostrar agora um exemplo de cálculo e desenho dos SSCs, voltando ao nosso exemplo do torno. Imagine que estejamos dando continuidade ao detalhamento do torno, cuja estrutura, resultante do projeto conceitual, está ilustrada na Figura 8.7. Para esse exemplo, vamos considerar que o torno CNC seja novo para a empresa, ou seja, no projeto conceitual foram definidos somente os parâmetros gerais de desempenho do produto, como rotação, torque, tamanho, aplicação e nível de ruído.

Exemplo de um redutor mecânico de um torno

Esse tipo de produto utiliza uma tecnologia amplamente conhecida (primordialmente mecânica), apesar do produto ser novo para a empresa, devido ao controle numérico. Os projetistas podem usar padrões de cálculo consagrados de elementos de máquina e ainda sistemas CAE de cálculo desses elementos. Eles também podem ter à disposição manuais de fornecedores de componentes e subsistemas, que já possuem sistemas computacionais para auxiliar o cálculo dos itens a serem adquiridos — como rolamentos e retentores — e, em casos mais sofisticados, para o cálculo de subsistemas, como um eixo-árvore. A Figura 8.13 mostra o exemplo de um catálogo e programa de cálculo de rolamentos na Internet. Para o desenho dos subsistemas, podem ainda ser utilizados os elementos gráficos dos componentes comprados, disponibilizados por seus fornecedores. O projetista tem a função de integrar esses itens na sua concepção e fazer a verificação de sua aplicação. Isso também ocorre para outros tipos de produtos, que são baseados em outras tecnologias. Por isso é que, na fase de projeto conceitual, já existe a possibilidade de buscar soluções de fornecedores de SSCs. Produtos que utilizam tecnologias hidráulica e pneumática também fazem uso de componentes padronizados e normalizados. Os cálculos e desenhos correspondentes são obtidos facilmente. Lembre-se de que estamos falando, no nosso exemplo, de produtos que são novos para a empresa, mas que contêm tecnologia tradicional. O problema que surge nessa aplicação é que, às vezes, as condições de contorno e referências, que podem ser encontradas em catálogos e programas de cálculo-padrão, não são aquelas de aplicação ao produto que estamos desenvolvendo. Nesses casos, é de grande importância às atividades subseqüentes de avaliação e otimização dos produtos (Tópicos e 8.8 e 8.9).

318

PARTE 2

Figura 8.13

O Modelo

Exemplo de um catálogo e programa de cálculo de rolamentos na Internet.

Fonte: http://www.skf.com

A descrição dos procedimentos de cálculo desta atividade é genérica, pois as tarefas específicas dependem da natureza da tecnologia empregada em cada produto. Não faz parte do escopo deste livro descrever essas tarefas com este nível de profundidade, uma vez que cada produto tem uma tecnologia específica e, portanto, regras, equacionamentos e procedimentos específicos. Os cálculos para se desenvolver um refrigerador são distintos daqueles utilizados no desenvolvimento de uma máquina lavadora, CD player, computador pessoal, máquina-ferramenta etc. Esses cálculos envolvem o tratamento dos fenômenos físicos e conhecimentos muito importantes e essenciais, advindos das áreas de mecânica, dinâmica, termodinâmica, fenômenos de transporte, energia, massa, eletricidade, eletrônica etc. Fugiria do escopo deste livro entrar nessas questões. Na verdade, seria impossível colocar em um único livro as regras, equacionamentos, informações e melhores práticas, relacionadas com todos esses fenômenos. Seria uma compilação de todo o conhecimento de engenharia de projeto. Este livro trata da gestão do PDP e os métodos apresentados são genéricos o suficiente para serem empregados no desenvolvimento de bens de consumo duráveis e de capital. Principalmente, os métodos apresentados 11 nas fases de projeto informacional e alguns da fase de projeto conceitual. As tarefas de cálculos dos SSCs são bem distintas para cada tipo de tecnologia. Nas fases subseqüentes de preparação da produção e lançamento do produto, as atividades são novamente mais genéricas e podem ser utilizadas para diversos tipos de produto. Tarefas de cálculo e detalhamento relacionadas com a natureza da tecnologia do produto

11

Na verdade, o termo cálculo, empregado da denominação desta atividade, não é tão genérico assim, mas ele está sendo utilizado, pois a maior parte dos bens de consumo duráveis e de capital é calculado (dimensionado é um outro termo freqüentemente utilizado) nas fases de projeto conceitual e detalhado. O termo mais genérico seria desenvolvido ou mesmo criado, pois quando tratamos de outros SSCs, como o software, não tem muito sentido utilizarmos o termo cálculo. Porém, queremos enfatizar que, nesta ativida-

de, eles são criados visando atender aos requisitos e de acordo com a concepção resultante do projeto conceitual.

CAPÍTULO 8

Projeto Detalhado

319

Primeiro, queremos enfatizar que, desde a criação do “esboço” de um produto, Trabalhar com croquis ou utiliza-se o CAD, pois não podemos esquecer que, hoje em dia, não tem muito mais diretamente com o sentido falar em se fazer croquis manuais, pois a aplicação de sistemas CAD está disistema CAD? fundida e abrange todas as fases de desenvolvimento de produtos. Um projetista comumente faz um croqui antes de criar o primeiro desenho, no entanto, cada vez mais as novas gerações de projetistas partem diretamente para o modelo geométrico tridimensional. O croqui é concebido mentalmente. O desenho é uma visão do modelo geométrico (veja o Quadro 8.11, sobre sistemas CAD/CAE). Quando os produtos são conhecidos e seu desenvolvimento é recorrente, Podem existir sistemas devem existir padrões de cálculo voltados às aplicações típicas da empresa. Ou seja, CAE específicos para a esse tipo de produto e tecnologia é conhecido e a empresa já criou padrões e sisempresa temas de cálculo que auxiliam o seu time de desenvolvimento e aumenta a produtividade dessas tarefas. O gasto no desenvolvimento desses sistemas é justificado pela quantidade de vezes que o mesmo cálculo é repetido. Esse é o caso típico de algumas empresas que desenvolvem produtos sofisticados, como máquinas copiadoras ou impressoras, e que já desenvolveram sistemas especiais para a simulação dos seus rolos-guias para direcionamento de papel por dentro dos produtos. Todos os parâmetros desses mecanismos (subsistemas e componentes) já estão definidos nos sistemas CAE específicos que auxiliam os projetistas nas tomadas de decisão. A atividade de detalhamento cuida principalmente da integração dos SSCs com base na concepção do produto. Na maior parte desses casos, durante o projeto conceitual, já existe a possibilidade de realizar simulações da aplicação parcial de um SCC (no caso do exemplo, o rolo de transporte de papel) empregando-se esses sistemas CAE específicos. Quadro 8.11

Sistemas CAD/CAE/CAM

Não é simples escrever um quadro sobre os sistemas CAD/CAE/CAM, devido ao grande número de alternativas e funcionalidades neles existentes. Todas as empresas hoje possuem sistemas CAD, e eles vieram para substituir a prancheta, assim como os processadores de texto substituíram os manuscritos, que eram depois datilografados. Mas vamos nos ater aos sistemas CAD/CAE, aplicados no desenvolvimento de bens de consumo duráveis e de capital, que é o escopo deste livro. Os sistemas CAD/CAE fornecem as mais amplas e diferentes capacidades que se pode imaginar. A sofisticação e qualidade das projeções gráficas e diferentes tipos de análise tem crescido tremendamente nos últimos anos, e seus futuros desenvolvimentos dependem apenas da potência dos computadores. A Figura 8.14 apresenta exemplos básicos dos tipos de análise que os sistemas CAD/CAE podem oferecer. Figura 8.14

Exemplos básicos dos tipos de análise que os sistemas CAD/CAE oferecem.

(continua)

320

PARTE 2

Quadro 8.11

O Modelo

Sistemas CAD/CAE/CAM (continuação)

Pela representação tridimensional de modelos sólidos do produto e seus componentes, estes sistemas podem realizar vários tipos de análises incluindo análise térmica, análise de tensões, fluxo de material, estudos de montagem e outros. A Figura 8.15 mostra um exemplo de software de estimativa paramétrica, em que é usado um modelo matemático para explorar as relações entre as opções de projeto e os custos de manufatura. O time de desenvolvimento pode manipular os parâmetros (dimensões, tolerâncias, tipos de materiais...) e verificar de modo imediato os impactos nos custos de manufatura, capacidade e tempo. Figura 8.15

Exemplo de um software de estimativa paramétrica.

Em outras áreas de aplicação ainda é viável discutir se a representação geométrica dos produtos deve ser bidimensional (2D) ou tridimensional (3D), como na área de engenharia civil. Porém, na área de aplicação, tratada neste livro, a representação mais apropriada é a 3D. A representação 2D passa a ser uma visão do modelo 3D. O CAD não é mais um substituto da prancheta, ou seja, o “D” do CAD não significa mais drafting, como alguns analistas antigamente se referiam aos sistemas utilizados somente para desenhar. Ele tornou-se uma ferramenta poderosa, que é usada desde a fase de projeto conceitual. Com o CAD, trabalha-se, desde o início, com o modelo geométrico do produto. Graças a isso, pode-se enviar este modelo para uma máquina de prototipagem rápida e obter um modelo físico do produto. Os maiores ganhos estão na integração do CAD com os sistemas CAE. E vamos utilizar esse termo para quaisquer sistemas que apóiam as tarefas de engenharia, desde a definição da estética do produto até a simulação de seu comportamento perante as condições de aplicação. Além disso, a reutilização de modelos geométricos e de modelos paramétricos aumentam a eficácia das atividades de detalhamento do produto. Modelos paramétricos são representações geométricas, cujos atributos são parâmetros. Se mudarmos o valor de um parâmetro, as dimensões correspondentes do modelo geométrico mudam e se ajustam. Existem sistemas conhecidos como low end, que são mais baratos e “rodam” em micros comuns. Os high end “rodam” em estações de trabalho. Antigamente, as funcionalidades de ambos eram muito diferentes. Pode-se dizer que hoje elas são equivalentes. No entanto, se o produto (ou SSC) que se estiver modelando for muito complexo e possuir muitas entidades

(continua)

CAPÍTULO 8

Projeto Detalhado

Quadro 8.11

321

Sistemas CAD/CAE/CAM (continuação)

geométricas, ou se a tarefa digital exigir um cálculo matemático muito demorado e pesado, um CAD low end não tem capacidade de processamento suficiente para dar apoio às tarefas de projeto. Nesses casos, somente os sistemas high end conseguem manipular esses dados. É comum que os grandes fornecedores de CAD ofereçam os dois tipos de sistemas integrados. Assim, eles podem ser utilizados em conjunto. Por exemplo, o modelo geométrico do produto total — com todos os SSCs montados, para avaliar interferências e realizar simulações mais sofisticadas — “roda” no CAD high end. Para componentes mais simples ou para a criação de documentos com detalhamentos, associados às visões 2D retiradas do modelo geométrico, utiliza-se o CAD low end.

CAD/CAM 12

A sigla CAD/CAM indica que a obtenção de programas para as máquinas CNC ocorre a partir do modelo geométrico do sistema CAD. O objetivo da programação CNC é calcular o caminho da ferramenta e especificar as ferramentas e ajustes nas máquinas, para obter automaticamente o componente fabricado, na linguagem específica do comando numérico da máquina. É interessante que o CAD/CAM deveria ser integrado aos sistemas CAPP, pois esses sistemas apóiam a obtenção das especificações de processo. Essa discussão, porém, foge do escopo deste livro.

Sistemas CAD/CAE específicos Outra evolução dos sistemas CAD/CAE foi o surgimento de sistemas voltados para uma aplicação ou domínio específico, conhecido como soluções verticais. Essas soluções usam as funcionalidades genéricas do CAD e oferecem funcionalidades adicionais. Por exemplo, um sistema CAD, utilizado para a construção de uma placa de processamento digital de um sistema de controle, já possui todos os elementos normalizados à disposição (não só sua representação gráfica, mas também os dados de especificação para a realização de cálculos e simulações); realiza avaliações de consistência, simula funcionamento etc. Além disso, cada empresa pode construir o seu sistema específico, usado para desenhar e simular o comportamento do produto (ou SSC) para um determinado tipo de tecnologia e aplicação (veja o exemplo apresentado do cálculo automático dos rolos de transporte de folhas de uma impressora).

CAD baseados em features Além da modelagem geométrica, existem sistemas que permitem a modelagem de produto com o uso de feature. Um feature pode ser definido como um elemento físico de uma peça que tem algum significado para a engenharia. Ele deve satisfazer as seguintes condições: ser o constituinte físico de uma peça; ser mapeável para uma forma geométrica genérica; ter significado técnico, sob o ponto de vista da engenharia e possuir propriedades previsíveis. O significado técnico de feature pode envolver a função para a qual um feature serve, como ele pode ser produzido, que ações a sua presença deve iniciar etc. Features podem ser pensados como “primitivas de engenharia” relevantes a alguma tarefa de engenharia. A modelagem por feature vem ganhando espaço, principalmente dentro da engenharia mecânica. O método permite criar furos, chanfros, rasgos etc, para serem associados com outras entidades ou faces. A modelagem por feature é baseada na idéia de desenhar utilizando building blocks (blocos de construção). Em vez de usar formas analíticas como paralelepípedos, cilindros, esferas e cones como primitivos, o usuário cria modelo do produto usando primitivos de maior nível de abstração, que são mais relevantes para a sua aplicação específica. Sistemas para aplicações particulares oferecem bibliotecas de feature apropriadas. O maior ganho no trabalho com feature é a sua integração às demais áreas e, principalmente, ao CAD/CAM. Os features já podem representar entidades, que podem ser fabricadas por macros CNC, diminuindo assim o tempo de obtenção do programa CNC.

Modelador geométrico O núcleo dos sistemas CAD é o seu modelador geométrico. É o software que efetua cálculos matemáticos sofisticados para realizar as operações de criação e visualização do modelo. No passado, os tipos de modelagem geométrica eram estudados, e a seleção de um sistema CAD considerava o método de modelagem que o sistema adotava (wire-frame, CSG, b-reps, nurbs etc.). Hoje em dia, o método de modelagem geométrica ainda é importante, mas já existem sistemas low end que possuem funcionalidades sofisticadas de modelagem. Os modeladores mais modernos integram muitos daqueles métodos.

(continua) 12

A sigla CAM sozinha, segundo alguns autores e entidades de classe, é utilizada para denominar sistemas de automação do chão de fábrica, integrados com os sistemas de informação de níveis hierárquico superiores, como os sistemas ERP (veja o Quadro 2.5, sobre sistemas ERP).

322

PARTE 2

Quadro 8.11

O Modelo

Sistemas CAD/CAE/CAM (continuação)

Para cada tipo de aplicação, ele utiliza um método, e isso fica claro para o usuário final. Nos casos mais extremos e sofisticados, no entanto, deve-se realizar uma análise mais aprofundada de qual modelador é mais apropriado. Aconteceu ainda uma outra evolução relacionada com os modeladores geométricos dos sistemas CAD. Até alguns anos atrás, cada fornecedor de um sistema CAD também desenvolvia o seu modelador geométrico. Era um diferencial competitivo. Os modeladores tornaram-se sofisticados, como mencionado, e muitas empresas se especializaram no seu desenvolvimento. Entretanto, outras, não deram conta de manter uma equipe especializada para realizar esse trabalho, pois o volume de vendas do sistema CAD não justificava o custo de desenvolvimento. Atualmente, pode-se enxergar um modelador geométrico como um chip para um computador. Existem empresas especializadas em desenvolver esses softwares, com equipes numerosas. A maior parte dos fornecedores de CAD incorpora um desses modeladores no seu produto. Assim, a empresa que desenvolve o modelador tem escala de mercado com alto volume, cobrindo os seus custos de desenvolvimento. Por outro lado, os fornecedores de CAD diminuíram os seus custos, pois compram o direito de incorporar o modelador nos seus sistemas, e focam sua atenção nas funcionalidades de seus sistemas. Assim, o diferencial está na funcionalidade.

Integração com outros sistemas A integração entre sistemas também é algo importante. Desde o início do uso dos sistemas CAD, vêm sendo desenvolvidos padrões de interface entre eles. O padrão mais conhecido, em uso até hoje, é o Initial Graphics Exchange Specification (IGES). Existe uma norma internacional, conhecida como Standard for The Exchange of Product model data (STEP), que veio para substituir o IGES. Ela possui um paradigma mais sofisticado de integração, baseado em objetos. Vários sistemas oferecem hoje em dia processadores que lêem e escrevem os seus modelos geométricos nesses padrões, permitindo a integração de diferentes sistemas. No entanto, a integração não é perfeita e em muitos casos precisam ser adicionados elementos gráficos específicos no momento de se transformar um modelo geométrico de um sistema no modelo de um outro. Para solucionar esses problemas existem grandes empresas que exigem que os seus fornecedores enviem os arquivos gráficos no mesmo padrão que eles utilizam. Ou seja, se uma montadora, por exemplo, utilizar um sistema CAD1, ela exige que os seus fornecedores enviem arquivos gráficos no modelo do sistema CAD1. O fornecedor deve arcar com os custos de transformação. Imagine um fornecedor que possui vários clientes com sistemas CAD diferentes. Ele tem de arcar com os custos de transformação. Para solucionar esse tipo de problema, existem segmentos que adotam um sistema único. Assim, esses problemas fizeram surgir um outro tipo de negócio. Empresas especializadas em transformar os arquivos gráficos do formato de um sistema para o formato do outro. Eles utilizam os padrões de interface e completam manualmente os elementos gráficos perdidos na transformação. Assim, um fornecedor não precisa se preocupar em comprar o sistema CAD específico do seu cliente, nem treinar algumas pessoas naquele sistema, e muito menos trabalhar com interfaces. Ele envia o arquivo para essas firmas especializadas e recebe de volta o arquivo no formato que desejar. Outra questão de integração é aquela relacionada com os sistemas de gestão empresarial. As funcionalidades dos sistemas CAD evoluíram e muitos são capazes de gerenciar a Estrutura de Produto (BOM), integrando-a às representações gráficas dos itens. No entanto, são os sistemas de gestão que manipulam a BOM e acrescentam outros atributos gerenciais aos 13 itens. A integração transparente entre essas entidades digitais é ainda hoje um desafio, que começa a ser resolvido pela aplicação de objetos distribuídos, cuja discussão foge do escopo deste livro.

Gerenciamento dos arquivos CAD A administração dos arquivos CAD/CAE tornou-se um grande problema, devido à segurança, integridade dos arquivos e sua distribuição entre os parceiros da cadeia de suprimentos. Funcionalidades de gerenciamento desses arquivos foram incorporadas aos sistemas CAD, que atualmente estão trabalhando de forma integrada aos sistemas PDM/EDM (veja o Quadro 8.18). Na verdade, alguns fornecedores de sistemas mais sofisticados incorporaram seus sistemas CAD/CAE/CAM, PDM/EDM e sistemas de gestão de projetos nos sistemas PLM (veja o Quadro 2.5).

Exemplos de funcionalidades Vamos agora listar algumas funcionalidades desses sistemas. Existem outras para casos mais específicos. A listagem não descreve as funcionalidades. Para conhecê-las com maior profundidade, você deve procurar nas informações adicionais ci-

(continua) 13

Existem sistemas ERP que acrescentam em torno de 300 atributos a um item, relacionados com: classificação fiscal, armazenamento, planejamento, programação, compra, venda, atribuição entre as organizações etc.

CAPÍTULO 8

Projeto Detalhado

Quadro 8.11

323

Sistemas CAD/CAE/CAM (continuação)

tadas. As homepages dos fornecedores sempre oferecem explicações adicionais, exemplos e simulações para divulgação de seus produtos. Modelador geométrico: método de modelagem híbrido, integração de superfícies, volumes, arestas, parâmetros e features; associação de atributos, como dimensões paramétricas, tolerâncias, GD&T, rugosidades, referências, sistema de coordenada, funções, equações, textos, cálculos, outros modelos geométricos, material, massa, volume, obtenção de projeções e visualizações 2D, e cortes de geometrias. Detalhamento de desenhos: dimensionamento e cotagem automáticos, consistência com modelo geométrico, uso de padrões gráficos, padrões de normas, dimensionamento de tolerâncias, biblioteca de símbolos. Apoio ao desenho industrial (estilo, estética — design): criação e avaliação de curvas e superfícies complexas, ferramentas de visualização, animação e rendering. Modelagem de conjuntos: inter-relacionamento entre os componentes, cálculo de tolerâncias resultantes e interferências, visualização e avaliação de mock ups, integração com BOM, manipulação de grafos integrada à visualização, simulações de montagem, inserção de regras de limitação geométrica, animação da montagem, simulação Monte Carlo de tolerâncias. Simulações para teste virtual da aplicação do produto: análise estrutural, deformações a esforços, durabilidade e fadiga, conformação de material, vibração, resposta dinâmica, análise térmica, escoamento de fluídos etc. Análises integradas a cálculos de engenharia: análise cinemática e de movimentos, aeroelasticidade, análise estrutural linear e não linear, testes de segurança, ergonomia e crash (rompimento do produto), dinâmica, durabilidade, análise térmica, acústica, fluidodinâmica computacional, refrigeração para produtos eletrônicos etc. Processamento de chapas: cálculos de dobramento e desdobramento de chapas, cálculo de alívios, especificação de ferramentas, desenhos de projeções. Projeto de ferramentas: biblioteca de elementos das ferramentas, desenvolvimento de moldes, automação de cálculos, simulação de operação (veja a análise integrada a cálculos), cálculo automático de cavidades e divisão entre partes da ferramenta. Soluções específicas para: moldes de injeção, moldes de conformação, estampas. Integração CAM: especificação interativa de features, reconhecimento automático de features, simulação do processo de fabricação, criação de representação gráfica de apoio. Gerais: processadores de integração (IGES, STEP, DXF), engenharia reversa, visualizadores de vários padrões, acesso via web, notação flexível, modelagem de cabos e fios. Outras funcionalidades, como a simulação de operação manual, também podem ser realizadas com esses sistemas, mas são mais comuns em sistemas de realidade virtual. Existe uma grande superposição das funcionalidades dos sistemas CAD/CAE com os de manufatura virtual (veja p. 321). Visite os seguintes sites para obter informações adicionais: UGS, 2005; IBM, 2005; PTC, 2005; DFMA, 2005; GALORATH, 2005; SOLID-EDGE, 2005.

Em casos mais sofisticados, quando a empresa não conhece o produto e a tecEm casos mais sofisticados? nologia é inovadora, o projeto conceitual fornece especificações genéricas dos SSCs, e é nesta atividade do projeto detalhado que eles são realmente criados, usando os conhecimentos de cada área específica. Esses casos são típicos do que se denomina projeto experimental, em que se procuram equacionamentos das áreas básicas de conhecimento — como física, matemática, química e biologia —, mas é na integração e testes das tecnologias e SSCs que se torna o Projeto Robusto.

8.3.3 Especificar tolerâncias As duas tarefas anteriores da atividade de criar e detalhar os SSCs foram: “Criar, reutilizar, procurar e codificar SSCs” e “Calcular e desenhar os SSCs”. Vamos descrever agora a terceira tarefa. Podemos dividir a especificação de tolerâncias em dois casos: especificação analítica e a experimental. A analítica é empregada toda vez que se tratar de produtos, soluções, tecnologias e processos conhecidos e dominados. A experimental, quando estivermos tratando de novas tecnologias ou processo, ou seja, se não houver conhecimento acumulado e sistematizado (Figura 8.16).

324

PARTE 2

Figura 8.16

O Modelo

Maneiras de especificar tolerâncias.

A especificação analítica de tolerância pode tratar de ajustes mecânicos, quando dois componentes precisam trabalhar em conjunto, como no caso do ajuste de um rolamento em um eixo ou da combinação de vários componentes, cujas tolerâncias das suas especificações críticas influenciam as do parâmetro crítico do componente-pai (subsistema). Para os conjuntos mecânicos, estaremos falando de cadeias dimensionais, mas, para os parâmetros de outra natureza (elétrica, magnética etc.), devemos tratar de modelos mais complexos. A especificação, nos casos de componentes mecânicos, parte do uso de tabelas e normas, pois tratam de conhecimento consolidado e sistematizado. As empresas, que já possuem uma experiência de especificação, reutilizam exemplos e experiências passadas, que se mostraram viáveis. Os projetistas usam o bom senso associado à análise da funcionalidade e de acordo com as limitações dos processos produtivos. Por isso é que um projetista deve possuir fundamentos de fabricação ou trabalhar em conjunto com processistas, dentro de um time multifuncional. Para ajustes mecânicos conhecidos, são utilizadas tolerâncias-padrão, associadas à recomendação dos processos. Por exemplo, o ajuste entre uma engrenagem e um eixo, quando o movimento for transmitido por chavetas, é um ajuste de guias precisas, normalizado pela ABNT-NBR 6409, 1997. As tolerâncias podem também resultar de cálculos, por exemplo, a tolerância entre os dois componentes de um mancal de deslizamento, a guia e o eixo, resulta do cálculo do mancal. Para grandezas de outra natureza, o gerenciamento de parâmetros críticos e os valores desdobrados do QFD são determinantes para a definição das tolerâncias, que devem tentar fazer uso de experiências passadas e conhecimentos acumulados e sistematizados (veja o Quadro 8.10, sobre gerenciamento dos parâmetros críticos). Uma empresa com mais experiência deve definir tolerâncias com maior precisão que aquelas sem experiên14 cia alguma, mas, em ambos os casos, esses valores são considerados iniciais e verificados em uma atividade paralela de análise dessas tolerâncias (veja Tópico 8.8). Um exemplo bem simples é a dimensão de um componente, como a largura de Exemplo de tolerâncias um anel espaçador (A2), que é uma dimensão que pode ser facilmente controlada no relacionadas com caso do subsistema do eixo de um redutor mostrado na Figura 8.17. Ela pode ter parâmetros críticos sido definida como especificação crítica anteriormente, pois tem uma grande in14

Assim como um projetista com mais experiência e conhecedor da empresa tem mais segurança em definir os valores das tolerâncias.

CAPÍTULO 8

Projeto Detalhado

325

fluência no parâmetro crítico do subsistema, que no nosso exemplo seria a folga de funcionamento para prever a sua dilatação (Aδ). A folga deste subsistema pode ser determinante para o funcionamento do sistema, o redutor, pois pode causar um travamento do funcionamento do redutor que não será aceito pelo cliente. A falha potencial (travamento) determinou o parâmetro crítico do subsistema (folga). Figura 8.17

Exemplo da relação de uma especificação crítica de um componente com um parâmetro crítico de um subsistema.

Existem diversos métodos para a especificação das tolerâncias, mas, basicamente, podem se destacar dois grandes grupos: métodos analíticos e experimentais. Nos analíticos, são utilizados modelos matemáticos ou de simulação para definir os valores e, posteriormente, analisar os seus efeitos nos elementos hierarquicamente superiores (os SSCs). Os valores iniciais das tolerâncias são determinados com base em melhores práticas, para componentes usuais, e esses valores são limitados pela capabilidade do processo. Para outros tipos de componentes, a especificação de valores iniciais parte da experiência dos projetistas. Caso contrário, deve-se aplicar métodos experimentais, nos quais são realizados ensaios de diversos tipos para determinar os valores. Nesses métodos, determinam-se os fatores que influenciam as respostas do sistema, definem-se os possíveis ruídos, e calcula-se a melhor combinação entre esses fatores para “rodar” vários ensaios. No Tópico 8.8, voltaremos para esse exemplo e mostraremos mais conceitos relacionados com a análise de tolerâncias. Vimos que todos os SSCs possuem atributos e que alguns dos atributos de sisTolerâncias geométricas temas e subsistemas são parâmetros críticos, resultantes de especificações críticas para componentes dos componentes (Figura 8.9). Nos componentes mecânicos, em especial, os desmecânicos vios possuem três ordens de grandeza. Os de primeira ordem são os desvios dimensionais, os de segunda ordem são os de forma e os de terceira, a rugosidade. Cada um deles deve estar dentro de uma faixa de tolerância. Percebeu-se, no passado, que só manter as tolerâncias dimensionais nos componentes mecânicos não garantia a funcionalidade desejada, pois os desvios de outra ordem de grandeza também tinham influência no funcionamento dos conjuntos mecânicos. Foram definidas então normas que estabeleceram padrões para a especificação de tolerâncias geométricas de forma e posição (Figura 8.18), e de rugosidade.15 Existem alguns padrões para medir a rugosidade, que podem ser consultados na norma ABNT referida.

15

Consulte a norma brasileira ABNT-NBR 6409, 1997.

326

PARTE 2

O Modelo

As tolerâncias de posição relacionam dois elementos geométricos, por exemplo, a posição entre dois furos (veja, na Figura 8.18, o símbolo do desvio de posição). Figura 8.18

Tolerâncias de forma e posição da norma.

A ligação entre as entidades geométricas segue o sistema tradicional de coordenadas cartesianas, que possui alguns problemas. O principal é o de deixar ao homem do “chão de fábrica”, ou mesmo ao processista, diversas alternativas de interpretação. Muitas peças que foram consideradas fora de especificação pelo sistema tradicional eram ainda funcionais (ou seja, deveriam ser aprovadas, mas eram reprovadas). O sistema Geometric Dimensioning and Tolerancing (GD&T) amarra as tolerâncias dimensionais com as de forma e posição. Graças ao sistema GD&T, pode-se diminuir os erros de interpretação de desenho e, principalmente, obter ganhos significativos na fabricação, pois o seu uso possibilita que tolerâncias mais abertas de forma e posição possam ser aceitas, dependendo da variação dimensional (veja o Quadro 8.12). Quadro 8.12

Geometric Dimensioning and Tolerancing (GD&T)

O GD&T é uma nova maneira de cotar, substituindo o sistema cartesiano. Stanley Parker realizou uma nova experiência, em 1940, ao montar produtos que funcionaram bem utilizando peças reprovadas na inspeção. Ele constatou que a característica crítica na montagem dos produtos é o afastamento em relação ao centro (true position), portanto, o campo de tolerância deve ser circular e não quadrado. O sistema cartesiano utiliza campos de tolerância quadrados e reprova as peças cujos centros dos elementos se localizam na zona fora do círculo (veja exemplo na Figura 8.19), provocando um grande desperdício, uma vez que a área do círculo é 57% maior que a do quadrado inscrito. Stanley Parker concluiu que as peças reprovadas, na verdade, eram peças boas. O que estava errado era o conceito de peça ruim. Assim, nasceu o GD&T, que utiliza campos de tolerâncias cilíndricos.

(continua)

CAPÍTULO 8

Projeto Detalhado

Quadro 8.12

Figura 8.19

327

Geometric Dimensioning and Tolerancing (GD&T) (continuação)

Exemplo de comparação entre a representação de posição de um furo com o sistema cartesiano e GD&T.

Depois, foram incorporados ao GD&T os princípios de máximo e mínimo material, a condição de independência, a zona de tolerância projetada, as zonas de tolerâncias compostas etc. No estágio atual, o GD&T é composto de 290 regras, cuja aplicação é normalizada pelas associações de normas técnicas dos diversos países. GD&T é uma linguagem precisa que descreve a dimensão, forma, orientação e localização dos elementos geométricos em 16 um componente. É um conceito que permite que os projetistas definam o componente com base na sua funcionalidade no produto final. Com isso, as tolerâncias atribuídas aos parâmetros dos componentes são maiores, diminuindo os custos de fabricação, eliminando assim o velho problema dos projetistas definirem tolerâncias muito apertadas no desenho. Quando se desenhava no papel, as dimensões gráficas colocadas eram as nominais e as tolerâncias eram as informações adicionais, que precisavam ser interpretadas corretamente pelos usuários do desenho. Os novos sistemas CAD permitem que se especifiquem as tolerâncias no modelo geométrico, permitindo assim uma automação maior das tarefas subseqüentes. Toda vez que um projetista estiver fazendo um detalhamento de um desenho, ele tem de responder às seguintes perguntas: — Como o componente será inspecionado e com qual freqüência? 17 — Quais serão as ferramentas utilizadas na inspeção e qual o seu R&R? — Como o componente será fixado para a inspeção? Essas questões devem ser formuladas em associação com as demais questões relacionadas aos métodos de DFX (veja o Quadro 7.8). Uma das maiores discrepâncias na medição das tolerâncias está no instrumento. Há uma diferença se medirmos uma dimensão (associada com a sua forma geométrica) com calibradores do tipo “passa não passa” ou com uma máquina de medição de três coordenadas (CMM — Coordinate Measurement Machine). No primeiro caso, estamos associando todos os elementos geométricos à forma como eles trabalharão, e, no segundo caso, medimos pontos e precisamos inferir sobre os desvios geométricos, o que normalmente é realizado automaticamente pelo software das máquinas CMM. Na Figura 8.20, é apresentado um exemplo de relação entre tolerância dimensional e geométrica de retilineidade de um eixo, com a condição de máximo material, cuja interpretação é apresentada a seguir. A notação afirma que o desvio de forma retilínea deve ser no máximo de 0,2 na condição de máximo material, ou seja, quando o diâmetro do pino estiver no seu valor máximo e, portanto, com 20,4mm de diâmetro. Isso significa que podemos aceitar um desvio maior de retilineidade se a dimensão ainda estiver dentro da faixa de tolerância, mas não no seu valor máximo. Isso é aceitável, porque a funcionalidade deste pino exige que ele possa ser encaixado em um furo. Em outras palavras, um erro maior de retilineidade, não vai prejudicar sua função, no caso de dimensões menores no diâmetro. Assim, podemos aceitar um desvio de até 1mm, se o diâmetro do eixo estiver na sua dimensão mínima. Ressalta-se que esse desvio é aceitável, para a funcionalidade descrita. Em outros casos, ele não é aceitável, e, portanto, não colocaríamos na sua especificação a condição de máximo material.

(continua) 16 17

A norma mais recente de GD&T é a ASME Y14.5M-1994. Reprodutibilidade e repetibilidade (Veja Quadro 9.1, sobre Análise dos Sistemas de Medição — MSA)

328

PARTE 2

Quadro 8.12

Figura 8.20

O Modelo

Geometric Dimensioning and Tolerancing (GD&T) (continuação)

Exemplo de relação entre uma tolerância dimensional e de forma na condição de máximo material.

Antes do uso deste conceito, é necessário acrescentar que se o eixo estivesse em uma dimensão intermediária, e o seu desvio de forma estivesse fora da faixa de tolerância estabelecida, ele seria rejeitado. Leia mais em ASME, 1994; PUNCHOCAR, 1995.

Após o término das três primeiras tarefas da atividade de criar e detalhar SSCs, podemos iniciar as atividades do ciclo de otimização do produto (veja o Quadro 8.2). Dessa forma, estaremos garantindo a confiabilidade do produto. Essas atividades são as de avaliar e otimizar o produto, que estão descritas nos Tópicos 8.8. “Avaliar SSCs, configuração e documentação do produto e processo e 8.9. “Otimizar produto e processo”, O processo de avaliação e otimização é contínuo. Mas por motivos de apresentação seqüencial dessas tarefas, vamos mostrar as demais tarefas que fazem parte da atividade de criar e detalhar, que só podem ser concluídas, entretanto, após a avaliação e otimização do produto. Na Figura 8.21, apresenta-se o exemplo da estrutura de produto do torno e seus documentos associados, 18 após o ciclo inicial de detalhamento. Todos os itens-filho estão definidos, assim como os desenhos e a maior parte dos planos de processo. Já podemos iniciar as próximas atividades do ciclo de otimização do produto

8.3.4 Integrar os SSCs Na Figura 8.1 do quadro sobre os integração entre projeto conceitual e projeto detalhado, foi mostrado o processo top down e bottom up de desdobramento e integração dos SSCs com o produto final. Uma outra forma de representar esse procedimento encontra-se na Figura 8.22. Nela, podemos observar o mesmo fluxo top down, para definição dos requisitos e seu desdobramento, e o fluxo bottom up, para integração e avaliação do produto. No fluxo de cima para baixo, definimos os sistemas, desdobrados em subsistemas e componentes, para atender aos requisitos dos clientes (esse é o conteúdo mostrado até agora). Nesses desdobramentos, são consideradas também as informações de inteligência de mercado da empresa, que fornecem dados atualizados sobre os produtos dos concorrentes e outras mudanças no mercado. Em seguida, passamos para as avaliações, integrando os componentes nos subsistemas, os subsistemas nos sistemas e os sistemas no produto (conteúdo a ser apresentado adiante). Paralelamente, dentro do processo de engenharia simultânea, são realizados os planos de processo de fabricação e montagem, assim como a aquisição dos SSCs comprados. 18

Não colocamos todos os desenhos e planos de processo para não poluir a figura.

CAPÍTULO 8

Projeto Detalhado

Figura 8.21

Exemplo da estrutura do torno após o ciclo inicial de detalhamento.

Figura 8.22

Desdobramento do produto em SSCs e integração dos SSCs em produto para atender aos requisitos dos clientes.

329

330

PARTE 2

O Modelo

Durante as avaliações, pode-se ajustar as especificações dos SSCs. O conteúdo principal dessa tarefa está na análise das interfaces entre os SSCs, reutilizando-se a matriz de interfaces que começou a ser criada na fase de projeto conceitual. Cada vez que a tolerância funcional de um subsistema for aprovada, resultante da aprovação das tolerâncias e funcionalidades de seus componentes, podemos aprovar as interfaces e sua integração em níveis superiores hierarquicamente na estrutura de produto. Procedemos assim, sucessivamente, até atingirmos o nível superior, que corresponde ao produto final. Todas essas atividades e tarefas ocorrem no contexto do gerenciamento dos parâmetros críticos do produto (veja o Quadro 8.10). No exemplo do nosso torno, vamos analisar o sistema de fixação e movimento da ferramenta, integrado ao sistema de avanço (Figura 8.23). Figura 8.23

Visualização do fuso, motor de avanço e suporte do torno CNC.

Neste exemplo, durante a análise de tolerâncias, podemos concluir que o elemento de interface, o suporte, acrescenta um acúmulo desnecessário de tolerância. Verificamos, entre outras possibilidades, a possibilidade de criar um único sistema no lugar dos dois e acoplar as funcionalidades do suporte no motor. Mas, ao mesmo tempo, avaliamos o custo associado, uma vez que os motores são padronizados, assim como os suportes. Essas são algumas das alternativas de raciocínio que se faz durante a análise das interfaces para integração dos SSCs.

CAPÍTULO 8

Projeto Detalhado

331

Não podemos esquecer do que comentamos no início deste capítulo que um Integração de software item de um produto poder ser um software. Nesta tarefa, deve-se também considerar a integração de software com os demais itens do produto. Como não falamos em nenhum local sobre software, vamos concentrar a sua discussão no Quadro 8.13. Quadro 8.13

Processo de Desenvolvimento de Software (PDS)

O processo de desenvolvimento de software (PDS) é um processo que está de acordo com a definição genérica de processos mencionada no Capítulo 2, “Processos de negócio compreendem um conjunto de atividades organizadas entre si, visando produzir um bem ou um serviço para um tipo específico de cliente (interno ou externo à empresa)”. O bem ou serviço resultante, nesse caso, é o software. O PDS também é um processo de referência e os softwares resultam de projetos de desenvolvimento, assim como o PDP, representado pelo Modelo Unificado deste livro, serviria de referência para o desenvolvimento de projetos de desenvolvimento de produtos. As fases típicas do PDS são: levantamento de requisitos, análise, desenho, implementação e testes. Elas variam um pouco conforme o modelo de ciclo de vida do software. Os modelos de ciclo de vida mais conhecidos são o modelo cascata, entrega 19 por estágios, espiral, prototipagem evolutiva, e modelo em paralelo. No modelo cascata, as fases são desenvolvidas em seqüência e existe um ponto de controle entre elas. O modelo de entrega por estágios é similar ao modelo em cascata. A única diferença está na entrega dos resultados de cada fase para o cliente avaliar. No modelo em espiral, o software é desenvolvido por meio de várias iterações. Na prototipagem evolutiva, a espiral é utilizada para desenvolver várias versões provisórias, os protótipos, que cada vez mais atendem aos requisitos do software final. O modelo em paralelo está na Figura 8.24 . Figura 8.24

Modelo da Rational Unified Process (RUP), adaptado de http://www-306.ibm.com/software/rational/ - copyright IBM.

Durante cada fase do desenvolvimento, podem acontecer diversas iterações, envolvendo os temas colocados à esquerda 20 da figura. No RUP, esses temas são denominados de workflow.

(continua) 19 20

Este último nome foi designado pelos autores deste livro, pois só existem nomes comercias. É o modelo de ciclo de vida adotado pelo Rational Unified Process (RUP), propriedade atual da IBM. O significado de workflow usado pelo RUP é diferente daquele discutido no Quadro 13.2. Para conhecer mais os conceitos de workflow do RUP, consulte http://www-306.ibm.com/software/rational/.

332

PARTE 2

Quadro 8.13

O Modelo

Processo de Desenvolvimento de Software (PDS) (continuação)

Nos outros modelos, como o modelo cascata, cada um dos temas era “esgotado” em uma fase. No RUP, pode-se levantar requisitos paralelamente à definição de um projeto e mesmo à implementação de algum método (um elemento de software). Isso só é possível devido aos novos paradigmas de programação, como a orientação por objetos. Não tem mais sentido, neste paradigma, dividi-los em fases, como análise, projeto e implementação. Pode-se observar que este modelo de ciclo de vida possui conceitos similares ao Modelo Unificado apresentado neste livro. Para fazermos um paralelo, considere as fases de iniciação, elaboração, construção e transição do RUP como sendo as fases do Modelo Unificado deste livro. Lógico que a natureza do software é diferente de um bem de consumo durável e, por isso, as fases são diferentes. Mas ambas são fases de gerenciamento de projeto com vários ciclos de iteração internos às fases, como se fossem espirais do método de prototipagem evolutiva. Os temas tratados (workflows) são equivalentes às áreas de conhecimento citadas no Capítulo 2. É importante destacar que um dos grandes avanços do RUP é fornecer uma suíte de ferramentas que dão suporte à metodologia de desenvolvimento proposta. Conclui-se então que um desenvolvimento de um software grande e sofisticado que seguisse esse modelo seria conceitualmente similar ao processo apresentado neste livro, considerando-se as diferenças de fases, áreas de conhecimento e seus métodos e ferramentas correspondentes. Mas não queremos afirmar com isso que o Modelo Unificado deste livro pode ser usado como referência para o desenvolvimento de software. Estamos aqui considerando o software como um item, um sistema ou subsistema do produto que estamos desenvolvendo. Seja um sistema de informação amplo para trabalhar em conjunto com o produto, como, os sistemas de vendas por Internet, assistência técnica, software de suporte ao usuário, software gráfico para operação do equipamento, seja os soft21 wares embarcados, que não são vendidos separados dos produtos. Alguns autores diferenciam os softwares embarcados em: embedded, responsável pelo controle completo de um conjunto de equipamentos mais sofisticados; bundled, que acompanha o hardware com memória tipo RAM e sistema operacional instalado; e firmware, um software instalado em um chip, responsável por realizar uma função específica integrada aos sensores e atuadores do produto. A questão que fica em aberto é como integrar os conceitos de PDS dentro do PDP, quando estivermos tratando de software como um item do produto. Um dos modelos de referência de PDS mais conhecido e usado para certificação de em22 23 presas de software é o CMM, que evoluiu para o CMMI, e procura resolver esse problema. Segundo a própria SEI, instituição responsável pelo CMMI desde 1991, várias versões de modelos vinham sendo usadas para organizar o desenvolvimento de soluções em engenharia de sistemas, engenharia de software, aquisição de software, gestão de times e desenvolvimento integrado de produto e processo. Apesar dos ganhos obtidos com o uso desses modelos, a multiplicidade deles era problemática, pois as diferenças entre eles (pois eram específicos para as suas áreas de aplicação) limitaram o sucesso da sua implantação. O CMMI surgiu para resolver esse problema. Ele é uma combinação dos CMMs para software, de um outro mo24 delo de referência das industrias eletrônicas, e um modelo de maturidade para desenvolvimento integrado de produtos. O desenvolvimento do CMMI também recebeu influência de outros modelos, que podem ser conhecidos ao se avaliar o seu 25 conteúdo no site do SEI. CMMI é um modelo de referência, a partir do qual podem ser definidos modelos apropriados à realidade de cada empresa específica. Pode-se encontrar nesse mesmo site do SEI um estudo comparativo entre o CMMI e o RUP, cujas conclusões principais são:

• O CMMI é um ótimo guia com práticas de desenvolvimento de sistemas26 gerais e institucionalização27 dessas práticas nas empresas;

• O RUP oferece ótimas práticas para desenvolvimento de software e ainda práticas básicas relacionadas à gestão de projetos e apoio ao desenvolvimento;

(continua) 21 22 23 24 25 26 27

Conhecido em inglês pelo termo embedded/bundled software. Capability Maturity Model (CMM); CMM Integration (CMMI). Software Engineering Institut (SEI), da Universidade de Carnegie Mellon, USA. Electronic Industries Alliance Interim Standard 731 (EIA/IS). Em http://www.sei.cmu.edu/cmmi/. O significado de sistemas é mais amplo do que o de sistemas computacionais, software. Sistemas abrangem os softwares e a organização como um todo (equipamento, pessoas, processos e procedimentos). Leia um pouco mais sobre institucionalização de processos de negócio no Capítulo 15.

CAPÍTULO 8

Projeto Detalhado

Quadro 8.13

333

Processo de Desenvolvimento de Software (PDS) (continuação)

• O RUP não trata de organização, gestão de fornecedores e institucionalização de processos;28 • O RUP é um PDS integrado a uma suíte de ferramentas; • O CMMI é um modelo de referência que integra o PDS a outros processos, incluindo o processo de institucionalização 29

do próprio processo. 30 A discussão realizada mostrou a visão geral do PDS e dos modelos de referência para que possamos fazer uma reflexão sobre o desenvolvimento de software inserido dentro do contexto do Modelo Unificado, proposto por este livro. Uma empresa de bens de consumo duráveis ou de equipamentos, foco do modelo apresentado, tem no software um componente adicional e teria muita dificuldade prática em adotar um modelo como o CMMI, pois o seu foco não está no software. Apesar do CMMI ser mais genérico, as práticas existentes são difíceis de serem empregadas nas empresas citadas, e ele ainda possui uma herança da sua origem na área de software. Mas não devemos descartar o seu uso integrado ao Modelo 31 Unificado e também à aplicação de um PDS similar ao RUP. Estamos inserindo o desenvolvimento de software como um tópico adicional na fase de projeto detalhado, mas devemos encarar o PDS como uma das áreas de conhecimento, e as atividades de desenvolvimento são similares àquelas propostas no nosso Modelo Unificado. Assim, desde a fase de planejamento de projeto, passando pelas fases de projeto informacional e conceitual, deve-se considerar o PDS. O ideal é que as atividades do PDS estivessem diluídas, distribuídas e integradas com as atividades do Modelo Unificado apresentado. Essa proposta ainda é discutível, pois hoje existe a tendência de trabalhar com o conceito de fábrica de software, que considera o PDS como um processo estanque que pode ser realizado de forma ad hoc com os outros processos que vão usar o software como um item, desde que os requisitos estejam muito bem definidos e sejam precisos. A nossa proposta é integrar o PDS adotado pela empresa ao PDP, conforme ilustrado na Figura 8.25. Figura 8.25

Integração dos PDPs com os diversos projetos de desenvolvimento de software.

(continua) 28 29 30 31

Mesmo porque não é essa a proposta do RUP, cujo foco é em desenvolvimento de software. Veja o Capítulo 15, para entender o conceito de institucionalização de processo. Esse é um termo usado pelos autores deste livro e não pelas instituições que criaram os modelos. Apresentamos aqui o RUP, como exemplo, por não existir uma generalização dos conceitos do RUP que seja de nosso conhecimento. Porém, outros fornecedores de suítes de PDS também oferecem modelos compatíveis com as suas ferramentas, que são similares ao RUP.

334

PARTE 2

Quadro 8.13

O Modelo

Processo de Desenvolvimento de Software (PDS) (continuação)

Softwares críticos Os softwares mais criticos ao produto são determinantes para a sua qualidade, tratam freqüentemente da operação do produto e, normalmente, oferecem uma grande interatividade humano-computador. Como exemplo, podemos citar o controle numérico de uma máquina. Estes softwares começam a ser desenvolvidos desde o planejamento estratégico, quando se definem parceiros estratégicos. Corresponde à fase de iniciação do PDS. Na fase de projeto informacional, equivalente ao início da fase de elaboração do PDS, são levantados os requisitos dos clientes e são definidos os requisitos do software. A fase de projeto conceitual corresponde ao final da fase de elaboração. E é na fase de projeto detalhado que ocorre a fase de construção do PDS.

Softwares de apoio aos processos de negócio Nos próximos capítulos, quando serão descritas as fases de preparação da produção e de lançamento de produto, vamos mostrar os processos de negócios que podem ser desenhados e operacionalizados, como: processo de vendas, processo de atendimento ao cliente, entre outros. Para a operação desses processos, pode ser necessário que sejam desenvolvidos softwares específicos. De novo aqui deve haver uma integração entre o PDS e o PDP. Naquelas fases do PDP, ficariam então contidas as fases do PDS. Existem casos, contudo, que as fases de iniciação desses projetos de desenvolvimento de software ocorrem bem mais cedo.

Softwares embarcados Normalmente os requisitos desses softwares começam a ser levantados desde o início do projeto de desenvolvimento do produto, principalmente se eles estiverem relacionados com os parâmetros críticos do produto. Mas existem também softwares embarcados mais simples, cujo desenvolvimento pode ser iniciado na fase de projeto detalhado.

Integração com software de terceiros Apesar de o foco desta discussão ter sido o PDS, não podemos esquecer que o processo de aquisição de software deve estar integrado com o PDS. Poucas empresas são capazes de desenvolver todos os softwares de que necessitam. Nesse contexto, a atividade de integração, apresentada neste capítulo de projeto detalhado, assume uma grande importância.

Ciclos de detalhamento e otimização Os ciclos de iteratividade, mostrados na Figura 8.24, ocorrem simultaneamente aos ciclos de detalhamento e otimização apresentados neste capítulo. Existe uma interface entre eles cada vez que alguma definição de um item afetar a especificação de um software. Leia mais sobre este assunto em PAULA, 2001. E consulte as informações disponíveis em: http://www-306.ibm.com/software/rational/.Acesso em: 20 fev. 2005.

Nesta altura do desenvolvimento, todos os SSCs foram criados, comprados (quando for o caso), desenhados, especificados, testados e integrados. Os ciclos de otimização e aquisição (que serão descritos mais adiante) também foram finalizados. Agora, restam as tarefas finais desta atividade central da fase de projeto detalhado.

8.3.5 Finalizar desenhos e documentos A especificação de tolerância, realizada anteriormente, fornece os subsídios para a obtenção dos desenhos finais dos componentes (principalmente daqueles que serão fabricados pela empresa) que consideram o processo de fabricação e sua capabilidade (veja o Quadro 9.2). Considera-se essa tarefa adicional, para que sejam levadas em conta as limitações de processo e normas. Ela, todavia, é simplesmente uma documentação adicional de todas as decisões e aplicação dos valores obtidos na análise de tolerância, que ocorre na atividade de avaliação dos SSCs (veja o ciclo de otimização na Figura 8.2).

CAPÍTULO 8

Projeto Detalhado

335

Em seguida, acontece a conclusão dos desenhos de conjuntos dos SSCs. DesVamos então concluir os taca-se a questão da codificação dos desenhos e seu cadastramento no sistema utilidocumentos, identificá-los zado pela empresa e que, conseqüentemente, será também usado pelo PCP, e classificá-los para manufatura, almoxarifado etc. Além da identificação dos desenhos, como consereuso futuro qüência da identificação dos SSCs (veja o Quadro 8.9 sobre a identificação de itens no início deste capítulo), devemos nos preocupar em classificá-los, para que possam ser recuperados no futuro e reutilizados em outros projetos (veja o Quadro 8.6, sobre classificação de itens). Sempre que criamos um documento, ou um arquivo (de CAD, por exemplo), ele deve possuir um código de identificação e ser relacionado com o item correspondente. A tarefa de conclusão verifica a integridade de todas essas informações e libera para a homologação do produto. Se a empresa estiver utilizando algum sistema de gestão de configuração, ou mesmo controle de documentos, esta tarefa não será necessária (veja o Quadro 8.18, sobre sistemas PDM/EDM).

8.3.6 Configurar produto e completar a estrutura do produto Finalmente, apesar de estar listada como última tarefa da atividade de criar e detalhar os SSCs, completar e atualizar a estrutura de produto (BOM) acontece continuamente durante o detalhamento do produto. A cada vez que se cria um item, deve-se inseri-lo na estrutura de produto. O objetivo dessa tarefa é especificar o tipo de estrutura de produto, que atende aos requisitos das demais áreas e processos de negócio da empresa, conforme discutido dentro do quadro tipos de BOM. Lembre-se de que as tarefas finais desta atividade ocorrem após a conclusão do ciclo de avaliação e otimização que estão descritos nos Tópicos e 8.8 e 8.9 Quadro 8.14

Tipos de BOM

A estrutura de produto (BOM) contém a identificação dos itens (SSCs) e dos relacionamentos entre eles, assim como a conexão desses itens com todos os documentos relacionados. A BOM é uma das fontes de informações fundamentais da manufatura, pois contém as informações de produtos utilizadas por todos os setores e processos envolvidos com a manufatura do produto. A maioria das empresas não garante que suas informações fundamentais, como a BOM, sejam completas e precisas. A falta de qualidade das informações fundamentais tem sido resumida por meio da expressão “garbage in, garbage out”, ou seja, se os processos da empresa estão manipulando informações sem qualidade, conseqüentemente, os resultados alcançados por esses processos também estarão comprometidos. A BOM é também um elemento que gera integração, já que suas informações são compartilhadas por quase todos os departamentos da empresa. Logo, a forma como é gerenciada, controlada e estruturada pode influenciar diretamente o sucesso da empresa. A maioria das empresas de manufatura sempre esbarra nas seguintes questões: O meu produto tem diversos opcionais e alternativas, como conviver com o grande número de estruturas de produto necessárias? Como a estrutura de produto pode refletir diferentes estratégias de estoque? Como conviver com mais de uma estrutura de produto? Quem é o “dono” da estrutura de produto? Como simplificar a estrutura de produto? Como aumentar a precisão das informações? A maioria das empresas só conhece a BOM padrão com a estrutura de pai e filho, e assim não consegue responder a essas questões de forma apropriada. Para isso, deve-se conhecer os tipos de BOM existentes e seus elementos, além de quando e como o melhor tipo deve ser aplicado.

Tipos de BOM e seus elementos BOM simples/padrão (flattened/standard BOM) A BOM mais simples possível é a de dois níveis, um deles corresponde às matérias-primas e itens comprados e outro, ao produto final. A única razão para a criação de mais níveis são as necessidades de planejamento e controle da produção (PCP), como a criação de submontagens ou itens intermediários que precisam ser estocados. Uma BOM de vários níveis é a estrutura mais conhecida, também chamada de BOM padrão (standard BOM).

(continua)

336

PARTE 2

Quadro 8.14

O Modelo

Tipos de BOM (continuação)

Item fantasma e pseudo-item (phantoms and pseudo items) Itens fantasmas são aqueles produzidos no processo de manufatura, possuem “pais” definidos, mas não são estocados. Apesar de existirem fisicamente, são rapidamente consumidos como componentes do item de nível imediatamente superior na BOM. A submontagem de uma engrenagem em um eixo, que é estocada na linha de montagem por pouco tempo e depois, inserida no redutor, é um exemplo de um item fantasma. Um pseudo-item é uma coleção artificial de componentes que são agrupados para serem utilizados no planejamento. Ao contrário dos itens fantasmas, entretanto, seus componentes não podem ser montados para produzir um item-pai que exista fisicamente. Por essa razão, os pseudo-itens nunca possuem inventário. O conjunto de todos os rotores de uma família de motores elétricos é um exemplo de um item fantasma. O conjunto não existe fisicamente, mas podemos planejar a sua produção. BOM Modular (modular BOM) A modularidade é a capacidade de construir um produto ou processo complexo, a partir de partes menores (chamados módulos), que podem ser projetadas independentemente e, ainda assim, funcionar juntas, como um todo (veja o Quadro 7.6 “Projeto Modular”). Se um produto possui muitas opções de escolha de itens, o número de combinações possíveis torna-se muito grande, dificultando a previsão de vendas e o planejamento mestre de produção de cada produto final. Além disso, se for mantida uma BOM para cada configuração diferente do produto, o espaço requerido pode ser muito grande, envolvendo altos custos de armazenagem e manutenção. Imagine um produto com cinco itens, possuindo cada um cinco opções de seleção. Nesse caso, teríamos 3.125 configurações possíveis. A solução para esse problema é a utilização da BOM modular. Em vez de manter uma BOM para cada produto final possível dentro de uma família, são identificadas as opções para cada um dos seus itens, que são organizadas em módulos. Se os módulos que contêm as opções estão no nível intermediário, a BOM pode ter o perfil mostrado na Figura 8.26. A BOM específica descreve exatamente um produto, a BOM modular, uma variedade de produtos. A BOM modular estrutura todas as opções dos módulos e serve de base à BOM de planejamento e à BOM genérica. Figura 8.26

BOM modular e um exemplo de perfil

BOM de Planejamento (planning BOM) No caso da Figura 8.26, não conseguiríamos fazer uma previsão de vendas dos produtos, pois temos 3.125 alternativas. No entanto, possuímos nos dados históricos quais as opções de cada módulo. Assim, podemos saber quais são os itens comuns que, dentro da previsão de vendas total dos produtos, sempre estarão presentes (certeza de 100%), e podemos levantar a porcentagem de cada opção por módulo. A BOM de planejamento resulta da BOM modular e contém essas porcentagens. Com base nesta BOM, podemos comprar material e prever a produção, sem que necessariamente tenhamos a previsão dos produtos finais (Figura 8.27). Planejaremos agora para 26 alternativas. No exemplo da figura, vamos prever a produção de 4.000 dos itens comuns e 80 itens da opção 2 do módulo 2 (40% de 4.000 = 1.600 módulos 2; 5% de 1.600 = 80).

(continua)

CAPÍTULO 8

Projeto Detalhado

Quadro 8.14 Figura 8.27

337

Tipos de BOM (continuação) BOM de planejamento.

Outra razão para se utilizar a BOM modular acontece nos casos em que o lead time de manufatura (tempo total de produção de um produto) é maior do que o tempo de entrega aceito pelo consumidor. Nesses casos, a modularização pode suportar a implantação da estratégia de estoque Assemble-To-Order (ATO), reduzindo o tempo entre a entrada do pedido do cliente e a entrega. A previsão de vendas é feita no nível dos módulos, que são fabricados e estocados. Quando ocorre um pedido do cliente, a configuração desejada é produzida, utilizando-se os módulos previamente preparados. BOM genérica (generic BOM) A estrutura de produto genérica é uma aplicação do conceito de BOM modular para as atividades de vendas técnicas e controle de configurações, assim como a BOM de planejamento é uma aplicação para previsão de vendas e planejamento mestre da produção. As aplicações para a configuração de produtos são uma extensão natural do conceito de BOM modular. Em vez de módulos predefinidos, como os usados na BOM modular, o configurador pode utilizar algorítmos, regras e condicionais para selecionar e calcular os componentes de um produto e seus requisitos de manufatura. A BOM genérica não pode ser utilizada diretamente para propósitos de planejamento e manufatura. Ela é apenas um frame para a criação de BOMs específicas no momento necessário, geralmente durante a entrada do pedido do cliente. BOM de manufatura (manufacturing BOM) BOM de manufatura representa a integração lógica da estrutura de produto e do plano de processo. A seqüência de operações é especificada e, a cada operação, são associados os itens necessários da BOM. A BOM de manufatura é usada como um guia para a fabricação e montagem de um produto, sendo que seus níveis refletem o fluxo de produção e pontos de estoque. Bill Of Objects (BOO ) É a extensão do conceito anterior, no qual cada item do produto pode possuir qualquer tipo de objeto como filho, por exemplo, documentos, arquivos multimídia, modelos geométricos etc. BOM para Informação (Information Bill Of Material) As estruturas de produto para informação são relatórios-padrão, gerados pelos sistemas de informação para suportar análises diversas sobre a BOM e seus itens. Os principais formatos de BOM para informação são:

• • • • •

estrutura de produto “indentada” (indented Bill Of Material); estrutura de produto “de onde é usado” (where-used Bill Of Material); estrutura de produto custeada (costed Bill Of Material); estrutura de produto matriz (matrix Bill Of Material); estrutura de produto resumida (summarized Bill Of Material).

(continua)

338

PARTE 2

Quadro 8.14

O Modelo

Tipos de BOM (continuação)

Variações da BOM e BOM única Como os diferentes usuários da BOM possuem diferentes necessidades, tornou-se prática comum que cada um deles estruturasse a sua própria BOM de acordo com essas necessidades individuais. Os exemplos mais comuns de BOM departamental são a BOM criada pela engenharia (E_BOM — Engineering Bill of Material), e a BOM utilizada pelo PCP e pela manufatura (P_BOM — Production Bill Of Material ou a M_BOM — Manufacturing Bill Of Material). A E_BOM, também chamada de estrutura de desenho, representa os sistemas funcionais do produto. Já a P_BOM é elaborada a partir da E_BOM, e reflete a transformação da matéria-prima e a montagem dos subconjuntos por meio do processo produtivo. Essa abordagem implica, entretanto, a redundância de informações e, conseqüentemente, no risco de inconsistência, bem como no aumento do esforço e do tempo de resposta das manutenções. Com o uso de sistemas PDM, PLM, ERP, é mais fácil hoje utilizar BOM únicas e fornecer múltiplas visões para suportar as necessidades de todos os usuários. Em muitas empresas, a área responsável pela BOM é o Planejamento e Controle da Produção (PCP). Dentro do enfoque colocado aqui, a BOM passa a ser responsabilidade de todos os seus usuários, pois a consistência de suas visões é garantida pelo sistema de informação e as mudanças que ela sofre são gerenciadas pelo processo formal de apoio Engineering Change Management (ECM ), descrito no Tópico 13.1. Leia mais sobre este assunto em OLIVEIRA, 1999.

Observe na Figura 8.3, no início deste capítulo, a dependência entre as atividades da fase de projeto detalhado. Paralelamente aos ciclos de detalhamento, estão as próximas atividades do ciclo de aquisição, no qual tomamos a decisão se os SSCs devem ser comprados ou projetados e fabricados internamente. Se eles forem comprados, precisamos procurar fornecedores. Caso contrário, damos continuidade ao ciclo de detalhamento e otimização do produto.

8.4

Decidir fazer ou comprar SSCs 32

As empresas terceirizam, cada vez mais, as suas atividades de negócio e estão desverticalizando a fabricação de seus produtos. Em outras palavras, elas se preocupam em fabricar somente aqueles itens que são estratégicos, essenciais e importantes para manter a qualidade de seus produtos, se o custo de aquisição dos SSCs permitir. Isso faz com que outras empresas (seus fornecedores) concentrem sua atenção nos grandes volumes na fabricação de certos itens, permitindo assim um custo menor para todos os parceiros da cadeia de suprimentos. Convém, neste ponto, recordar as formas de relacionamento entre as empresas envolvidas no PDP, apresentadas na Figura 2.19. Desde o início do processo de desenvolvimento, a empresa vem se relacionando com fornecedores de diversos tipos. Normalmente, os SSCs de um produto é dividido em: itens estratégicos, commodities e comuns. Os estratégicos são aqueles SSCs que fornecem vantagem competitiva para a empresa e, neste caso, a própria empresa desenvolve todos esses itens ou define, logo no começo do PDP, uma parceira de risco, tecnológica ou estratégica dentro da cadeia de suprimentos. Os itens considerados commodities normalmente são adquiridos mais para a frente, no PDP, pois a qualidade deles sempre é mantida pelos fornecedores e a decisão dependerá dos preços, mas a sua especificação ocorreu na atividade de criar e detalhar os SSCs. Os itens comuns podem ser fabricados ou não, dependendo da comparação do custo interno com o custo de sua aquisição no mercado. Esses itens comuns também podem ser fornecidos por parceiros de risco, quando a empresa é do tipo montadora e possui parceiros responsáveis por grande parte (sistemas ou subsistemas) dos seus produtos. Há, todavia, um conjunto de itens que pode ser fabricado dentro da própria empresa por razões econômicas e que não é estratégico. Na Figura 8.28, estão listadas as tarefas desta atividade, também conhecida pelo termo make-or-buy decision.

32

Uma empresa verticalizada produz todos os itens dos diversos níveis de sua estrutura de produtos: desde a matéria-prima até os componentes finais.

CAPÍTULO 8

Projeto Detalhado

Figura 8.28

339

Tarefas da atividade de decidir fazer ou comprar SSCs (make-or-buy).

Antes, devem ser levantadas informações de custos, tempo, capacidades e comLevantar informações petências para o desenvolvimento ou fornecimento dos SSCs, ou seja, quais são as dos SSCs características dos SSCs e a seqüência macro de fabricação. Essas informações podem resultar da fase de projeto conceitual ou da atividade de criar e detalhar os SSCs. O nível de detalhamento do item deve ser suficiente para se ter uma noção de seu custo. Por isso é que, para SSCs conhecidos, as informações do projeto conceitual são suficientes, pois o processo de fabricação (as operações macro) é obtido com uma certa precisão. No entanto, em relação aos novos SSCs, deve-se obter informações um pouco mais detalhadas para se ter uma noção mais aprimorada do seu custo. A estimativa dos custos internos para a empresa fabricar um componente é Estimar os custos dos SSCs composta dos seguintes elementos: para a empresa

n n n n n n

33

custo da matéria-prima; custo por operação de fabricação (operações de produção, montagem, inspeção etc.); custo de mão-de-obra direta; custo de ferramentas e equipamentos necessários para a sua fabricação; 33 custos indiretos associados; custo de desenvolvimento.

Existe uma discussão sobre a precisão de obter os custos indiretos para a decisão de make-or-buy, porém, com certeza, a margem de contribuição do item deve ser considerada neste cálculo.

340

PARTE 2

O Modelo

O custo de desenvolvimento pode estar, para algumas empresas, embutido nos custos indiretos associados. Porém, é bom que se tenha uma noção mais precisa desses custos, pois se o item for fabricado internamente, as demais atividades do PDP devem ser ainda realizadas. Não se deve detalhar itens que se deseja comprar, caso a sua qualidade possa ser garantida pelo fornecedor, como mostra o exemplo do Quadro 8.16 no Tópico 8.5. Quando estivermos falando de subsistemas e sistemas, devemos adicionar ademais os custos de cada componente de sua estrutura de produto e os custos das operações de montagem. Paralelamente à tarefa anterior, serão contatados os fornecedores (veja a próOrçar os SSCs dos xima atividade de desenvolvimento de fornecedores) e solicitados os orçamentos fornecedores para o fornecimento dos SSCs. Deverão ser pedidos diversos orçamentos com diferentes variações, dependendo do grau de envolvimento da empresa na cadeia de suprimentos. Entre essas variações estão aquelas em que a empresa participa do investimento do fornecedor em equipamentos e instalações, para ele poder ter a capacidade de produção do item desejado, desde que permaneça dentro do custo-alvo (veja o Quadro 8.15). Não se pode esquecer que uma cotação de um SSC deve ainda considerar os custos de transporte, logística, armazenamento e manipulação (custos do ciclo de vida). Além disso, o possível custo da falta de qualidade deve ser considerado. Quadro 8.15

Custo-alvo e Gestão de Custos do PDP

Para muitos produtos e mercados, não é o custo que, via de regra, determina o preço, mas o contrário, ou seja, fixando-se um preço máximo de mercado e uma taxa de retorno para a empresa, o resultado é um custo máximo possível de ser praticado, conhecido como “custo-alvo” ou (target cost). Em outras palavras, a fórmula antigamente era: Custo + Lucro (desejado, ou seja, um adicional sobre o custo) = Preço. Hoje, o raciocínio é outro: Preço (que o mercado determina) – Lucro (o mínimo que se consegue obter) = Custo-alvo. Assim, o custo de um produto é um dos elementos que dão suporte às decisões de entrar ou permanecer no mercado, de lançar ou de retirar um produto. Como já mencionado neste livro, o custo do produto é, em grande parte, determinado por decisões que são tomadas nas fases de projeto conceitual. Portanto, o custo do produto que está sendo desenvolvido precisa ser gerenciado de forma articulada com o PDP, para que se preveja o custo real do produto, procurando adequá-lo ao custo-alvo. O custo-alvo é a referência para todas as decisões subseqüentes do processo de desenvolvimento de produtos. Como custo de um produto, não se deve considerar apenas o seu custo de fabricação, que é a primeira idéia de custo que vem à mente. O conceito de “Custo” deve ser estendido para as demais fases do ciclo de vida do produto. Ou seja, quando a equipe de desenvolvimento adota uma determinada solução, deve ter ciência de que ela terá impactos, positivos ou negativos, não apenas no custo de fabricação desse produto, mas, também, nos custos de operação, de manutenção e até mesmo de descarte, quando o produto não tiver mais utilidade. O custo de aquisição é apenas um dos diversos componentes do que se conhece como Custo do Ciclo de Vida (CCV) do produto, e ele, assim como os demais, é definido em grande parte por decisões tomadas durante o seu desenvolvimento. Daí decorre a importância de uma gestão eficiente desses custos, quando o produto ainda está sendo conceituado, planejado e projetado, quando, de fato, grandes e pequenas decisões podem determinar o grau de rentabilidade do produto. Um modelo de gestão do PDP deve contemplar necessariamente elementos da gestão dos custos. Assim como há tarefas relacionadas ao dimensionamento de uma determinada peça ou subsistema, deve haver também atividades destinadas a responder se aquele subsistema tem um custo estimado dentro do que foi definido como custo máximo suportável. É necessário saber se o produto, em cada etapa de seu desenvolvimento, permite à empresa atingir seus objetivos de negócio (os lucros desejados). Da mesma forma como o projeto não pode prosseguir se determinado sistema ou componente ainda não foi desenvolvido o suficiente, de modo a atingir o desempenho que dele se espera, também não pode ir adiante enquanto não se conhecerem os impactos de cada decisão no custo do ciclo de vida do produto de modo a garantir, dentro do grau de

(continua)

CAPÍTULO 8

Projeto Detalhado

Quadro 8.15

341

Custo-alvo e Gestão de Custos do PDP (continuação)

certeza possível em cada etapa de desenvolvimento, que os custos estimados até aquele instante estejam dentro do que foi definido no plano de negócios como Custo-alvo. Na Gestão de Custos, diferentemente da simples Estimativa ou da Apuração, questionam-se e aprimoram-se os procedimentos e soluções adotadas anteriormente, o que pode levar a resultados melhores em relação ao projeto anterior. A Gestão dos Custos de novos projetos passa não apenas pelo conhecimento do que ocorreu no passado com outros produtos, mas também pela busca de novas alternativas, pela avaliação do impacto de cada uma delas no custo do ciclo de vida do produto e pelo controle, durante o PDP, do custo estimado para cada etapa em relação ao que havia sido estipulado. A Gestão de Custos deve estar presente em todo o ciclo de desenvolvimento. Definir um processo de gestão dos custos do ciclo de vida não é diferente, em essência, de definir um processo de dimensionamento de cada componente do produto. De maneira análoga, ao se definir um componente ou conjunto de componentes, deve-se determinar quem serão os responsáveis pela avaliação dos custos do ciclo de vida do produto decorrente dessa definição, quais os métodos de estimativa a serem utilizados, as atividades correspondentes e as informações necessárias a esse processo de modo a garantir, com o maior grau de certeza possível, que a alternativa de projeto escolhida implica o menor custo, dentro do que foi definido no plano de negócios, sem que haja comprometimento de outros aspectos, como a qualidade. O processo de gestão de custos garante, portanto, a manutenção dos custos reais futuros dentro dos valores do custoalvo. No monitoramento da viabilidade econômico-financeira, analisa-se a influência da variação do custo-alvo nos indicadores financeiros do projeto. Consulte as informações complementares em CROW, 1999; WEUSTINK et al, 2000; e FREIXO, 2004.

A tarefa de decidir tem como base os valores monetários levantados anteriorDecidir entre desenvolver, mente. É montado um fluxo de caixa para se avaliar qual a melhor solução para todo produzir ou comprar SSC o ciclo de vida do produto. Pode ser mais econômico comprar um item ao se compararem os custos internos com o preço de fornecimento (na cotação), mas durante todo o ciclo de vida isso pode ser desvantajoso. Essa decisão está intimamente relacionada com a atividade de desenvolvimento de fornecedores (descrita no próximo tópico, mas que ocorre paralelamente), com base nas diversas cotações, realizadas na tarefa anterior.

8.5

Desenvolver fornecedores

Existem vários tipos de parceiros de desenvolvimento, assim como de fornecedores dentro da cadeia de suprimentos (veja o Quadro 8.18, sobre a participação de fornecedores no PDP). Desde a fase de planejamento estratégico do produto estamos em contato com parceiros. Na fase de projeto conceitual, já são fechadas as parcerias de co-desenvolvimento. Na fase de projeto detalhado, estamos tratando dos fornecedores dos itens comuns, e os commodities são contratados. O desenvolvimento desses fornecedores acontece neste momento, porque anteriormente não estava decidido se iríamos comprar SSCs deles (isso só foi definido na atividade anterior de make-or-buy). Se a inserção da empresa dentro de uma cadeia de suprimentos for bem estabelecida e não existirem grandes novidades em relação ao produto, os fornecedores definidos nas fases de planejamento e projeto conceitual serão suficientes e a obtenção de fornecedores não será tardia. As tarefas desta atividade são genéricas e poderiam estar acontecendo anteriormente também (veja a Figura 8.29), logo após a codificação de um item que, desde o início, decidimos que deveria ser comprado (veja a Figura 8.6).

342

PARTE 2

Figura 8.29

O Modelo

Tarefas da atividade de desenvolvimento de fornecedores.

A seleção inicial de fornecedores, que não fazem parte da cadeia de suprimentos ainda (mas que farão, após o término da fase de projeto detalhado), pode acontecer hoje por meio da Internet, principalmente para os itens commodities, que ocorre no início desta fase (veja a Figura 8.6). Na Internet, pode-se fazer leilões reversos34, nos quais a empresa compradora coloca a necessidade de cotação e as empresas candidatas entram em contato. Mas, às vezes, a própria empresa precisa procurar os fornecedores,35 realizando essa atividade por meio da consulta a diversos market places ou, se ela possuir um catálogo de fornecedores criado em seu portal, por meio de agentes inteligentes (veja o quadro 8.7, sobre sistemas CSM, catálogos na Internet e o e-procurement). Consultar catálogos e parceiros atuais da cadeia de suprimentos é a maneira tradicional de buscar fornecedores. A próxima tarefa é enviar informações suficientes para que o fornecedor seja Enviar/atualizar capaz de cotar o SSC. Antigamente, eram enviadas informações detalhadas demais especificações do produto para itens comuns, mas, hoje em dia, os fornecedores assumem os serviços de detalhamento dos SSCs que eles fornecem, como mostra o Quadro 8.16. Selecionar fornecedores

Quadro 8.16

Diminuindo os Custos, Desenvolvendo Fornecedores

Antigamente, algumas empresas detalhavam um certo número de SSCs de seu produto, incluindo aqueles itens que seriam comprados no mercado, fabricados por terceiros. Era o caso de produtos fundidos, que representavam a peça em estado bruto para a fabricação da carcaça de seus produtos. Todo o custo do detalhamento ficava por conta da empresa compradora. Além

(continua)

34 35

Conhecidos também como pregões eletrônicos. Veja o Tópico 8.3.1.

CAPÍTULO 8

Projeto Detalhado

Quadro 8.16

343

Diminuindo os Custos, Desenvolvendo Fornecedores (continuação)

disso, comumente, sem experiência com o processo de fundição, elas mandavam algumas especificações erradas. Isso ocasionava, às vezes, produtos que não podiam ser fabricados ou mesmo erros, que aumentavam em demasia o ciclo de desenvolvimento. Alguns fornecedores (fundições) detectavam esses erros e pediam para a empresa corrigir. Depois de vários anos praticando esse tipo de relacionamento com as fundições, as empresas contrataram algumas delas como fornecedoras. Elas enviavam as especificações da peça final para as fundições parceiras e solicitavam todo o detalhamento da peça em estado bruto. Nunca mais houve problema de qualidade com a especificação errada da peça fundida e todos os seus custos de detalhamento foram eliminados, diminuindo assim o seu custo de desenvolvimento.

O envio das especificações pode ser realizado de forma tradicional, por meio de correspondência, ou atualmente via Internet, por market places, ou nos leilões reversos. Conforme o grau de dificuldade técnica que o SSC apresenta, pode ser necesAvaliar amostras dos SSC sário que o fornecedor envie amostras (ou mesmo um protótipo em casos mais comrecebidos plexos e de baixo volume) do item a ser adquirido. A homologação do fornecedor ocorre não somente com a aprovação da qualiHomologar fornecedores dade das amostras, mas também por meio da aprovação da empresa e de seus principais processos de negócio que influenciam a qualidade do seu produto (que é um SSC para a empresa compradora). Para isso, existem certificados de qualidade como a ISO 9000, que assegurariam a qualidade do fornecedor, mas existem muitos clientes que exigem condições adicionais. Está diminuindo a quantidade de fornecedores que estabelece padrões de qualidade próprios para os seus fornecedores, pois eles estão se associando com empresas da mesma categoria e criando padrões mais genéricos. Isso visa diminuir os 36 custos de seus fornecedores, que assim não precisarão atender a vários padrões, mas a um único. Algumas empresas, no entanto, ainda exigem que os seus padrões de qualidade específicos sejam atendidos, mas o outro lado da moeda, é que, em última análise, o fornecedor precisa embutir os custos de atender a esses critérios nos preços dos seus produtos.

8.6

Planejar processo de fabricação e montagem

Na presente atividade, aquele plano macro inicial, criado no projeto conceiObjetivo desta atividade tual, é atualizado, um novo pode ser criado e suas operações são detalhadas. Há um grande número de alternativas de documentação detalhada do plano de processo. Em seguida, serão apresentadas as possíveis tarefas de planejamento, que, dependendo do tipo de componente e estratégia de planejamento do processo, devem ser analisadas e eliminadas para cada caso particular. Primeiro, precisamos conhecer os dois níveis que existem de planejamento de processo: o planejamento macro e o detalhamento de operações. O plano macro fornece a seqüência de operações, especificação de máquinas e Dois níveis de equipamentos, e tempo, sendo utilizado pelo Planejamento e Controle da Produção planejamento para programar de forma correta a fabricação do componente (ou montagem do sis37 tema). O detalhamento das operações produz todas as informações que são colocadas ao lado do posto de trabalho, permitindo que a realização das operações tenha repetibilidade e qualidade. Ou seja, descreve em detalhes como se deve realizar uma operação (Figura 8.30). Não há padrões para o plano macro e para os detalhamentos. Cada empresa usa um tipo de documento e de detalhamento. Existem empresas 36

37

Esse foi o caso da indústria automobilística. As três maiores montadoras americanas unificaram os seus requisitos de qualidade, exigidos dos seus fornecedores, e criaram a QS 9000 (veja, na bibliografia, HOYLE, 1997), que hoje está sendo substituída pela norma ISO?TS 16949. Para a programação correta, necessita-se das especificações das máquinas (postos de trabalho) e tempos necessários para a realização de uma operação.

344

PARTE 2

O Modelo

que trabalham somente com o plano macro, mas têm dificuldades de manter a repetibilidade e ficam muito dependentes da habilidade do operador da máquina. Esse é o caso das ferramentarias. Para as empresas de bens de consumo duráveis e de capital, foco deste livro, deve-se sempre produzir os documentos de detalhamento. Nesse ramo, existem empresas que possuem de dois a três documentos de detalhamento, até empresas que possuem 12 tipos diferentes de documentos. Em uma empresa fabricante de blocos de motores a diesel, chegamos a conhecer planos de processo com 150 páginas no total. Figura 8.30

Níveis de planejamento de processo.

Durante a fase de projeto conceitual, paralela à identificação e análise dos SSCs, determinam-se os processos de fabricação (veja a atividade de definir processo macro na fase de projeto conceitual, Capítulo 7). A especificação desses processos equivale a uma primeira versão dos planos macros para os componentes que serão fabricados. Para um componente mecânico, por exemplo, podem ser definidos os seguintes processos: torneamento, furação, tratamento térmico de têmpera e retificação. Em algumas empresas, não se criam documentos específicos para esse fim, e as informações de planejamento do processo são anotadas no próprio desenho de especificação dos componentes. Porém, é uma boa prática criar um documento inicial naquele momento, desde que ele possa ser reutilizado em seguida, sem burocratizar o PDP. A definição do plano macro, durante a fase de projeto conceitual, é mais utilizada para os itens conhecidos. Para os novos SSCs, que são criados somente na fase de projeto detalhado, a primeira definição dos processos acontece nessa atividade. Enquanto os itens são inicialmente detalhados nos sistemas CAD, pode ocorrer a especificação do plano de processo macro. Novamente, enfatiza-se que deveria se utilizar um sistema integrado para que a definição dos processos não seja perdida durante o processo. É o momento de aplicar sistemas CAPP (veja o Quadro 8.21, sobre CAPP). Observe novamente na Figura 8.3 a dependência desta atividade na fase de Esta atividade ocorre projeto detalhado e vamos também recordar os ciclos de detalhamento da Figura simultaneamente ao 8.2. Esta atividade acontece de forma simultânea à criação e detalhamento dos detalhamento dos SSCs. O paralelismo dessas atividades do projeto detalhado é uma das caracterísdocumentos ticas da Engenharia Simultânea, descrita no Quadro “O que É Engenharia Simultânea” do Capítulo 2. Esse paralelismo traz um ganho enorme, mas o processo deve O início do planejamento do processo pode ocorrer no projeto conceitual

CAPÍTULO 8

Projeto Detalhado

345

estar sistematizado e as pessoas do time, treinadas para realizá-las. A Figura 8.31 mostra uma visão mais detalhada do paralelismo entre essas atividades, descrito em seguida. Figura 8.31

Seqüência das atividades e tarefas no conceito de engenharia simultânea.

1. No projeto conceitual, o processo macro pode ter sido definido para alguns itens conhecidos, como discutido anteriormente. 2. Durante a criação dos itens, são definidas iterativamente suas especificações críticas e tolerâncias. 3. Para os itens mais simples, o processo macro é determinado nesta fase, caso ele já não tenha sido definido no projeto conceitual. Isso é feito somente para os itens que, neste momento, estão definidos como itens a serem fabricados, pois aqueles que serão comprados, como commodities ou outros SSCs, já foram anteriormente determinados. Entre esses itens fabricados, há aqueles que serão fabricados pela empresa e os que serão fabricados por terceiros, mas que agora são ignorados, pois a atividade de decisão de fa38 bricar ou comprar não foi realizada. Itens mais complexos precisam ser especificados mais detalhadamente, desenvolvendo-se, na maior parte das vezes, o seu desenho inicial, pois somente com as especificações iniciais não se consegue determinar os seus processos. 4. É criado o plano macro, no qual são determinados os principais processos. Às vezes, já se consegue definir as operações principais e quais máquinas ou equipamentos serão utilizados. Em alguns casos, já ocorre uma determinação dos tempos necessários, para se poder levantar o custo interno de fabricação, como mostrado anteriormente. 5. Realiza-se então a atividade de decidir comprar ou fabricar, para se ter certeza quais os itens que serão fabricados pela própria empresa (veja o Tópico 8.4). 38

Embora, na apresentação seqüencial do livro, esta atividade esteja posicionada após a atividade de decidir fazer ou comprar, devemos ter em mente o ciclo de aquisição paralelo ao ciclo de detalhamento.

346

PARTE 2

O Modelo

6. Em seguida, as especificações finais dos SSCs serão determinadas. São as tarefas finais da atividade de criação e detalhamento dos SSCs. As tolerâncias dimensionais são resultantes do processo de fabricação, que, por sua vez, depende do formato e funcionalidade do componente. As operações críticas resultam nas especificações críticas dos componentes (observe a Figura 8.9, na qual essas informações estão relacionadas). 7. Durante o desenvolvimento das especificações finais, cada projetista deve estar treinado e ter a responsabilidade de liberar o item para que as demais tarefas do planejamento de processo fluam. Ou seja, não se deve esperar que todas as tarefas de detalhamento do item estejam encerradas para se realizar o detalhamento das operações. Esse paralelismo diminui significativamente o tempo de desenvolvimento, principalmente se considerarmos empresas que detalham e fabricam muitos itens (veja o Quadro 8.17 sobre paralelismo entre desenhar e planejar processo). 8. As especificações finais são avaliadas (descritas no Tópico 8.8, apresentado à frente). 9. Caso seja detectado algum problema nas especificações finais, elas serão modificadas. 10. A modificação pode envolver somente as especificações de um SSC, mas, mesmo nesses casos, o plano de processo deve ser analisado novamente e avaliado, pois a modificação pode resultar em mudanças no processo. No entanto, as modificações podem envolver os processos também. Toda vez que surgirem mudanças em documentos liberados para várias pessoas do time, o time for grande e /ou as pessoas estiverem distantes entre si, deve ser acionado o processo de Gerenciamento de Mudanças de Engenharia (ECM) descrito no Tópico 13.1. Quadro 8.17

Paralelismo entre Desenhar e Planejar Processo

Alguns críticos do processamento paralelo entre desenhar e planejar o processo dizem que liberar desenhos antes de sua aprovação final é desperdiçar recursos. No entanto, um time de desenvolvimento bem preparado, que trabalha com qualidade e utilizando as ferramentas e métodos apropriados não deve produzir documentos que precisam ser modificados com muita freqüência. Vamos imaginar que, no começo da aplicação de engenharia simultânea, 15% dos desenhos precisam ser modificados de tal forma após a sua avaliação, que afetariam os planos de processos já elaborados. Nesses casos, 85% do trabalho realizado paralelamente estaria aprovado e somente 15% deveria ser refeito, e, ainda assim, refazer não leva o mesmo tempo de um desenvolvimento completo (veja a ilustração da Figura 8.32). Figura 8.32

Comparação entre a duração do desenvolvimento seqüencial e paralelo.

(continua)

CAPÍTULO 8

Projeto Detalhado

Quadro 8.17

347

Paralelismo entre Desenhar e Planejar Processo (continuação)

Com o tempo, a qualidade do time melhora e a taxa de desenhos que precisam ser refeitos diminui, digamos para 5%. É claro o ganho resultante do paralelismo entre as atividades de detalhamento dos SSCs e o planejamento de processo.

Um problema que pode surgir, trabalhando-se com engenharia simultânea, é garantir a integridade entre as informações interdependentes. Normalmente, a aplicação de sistemas de informação como o PDM ou EDM garante essa integridade, como mostrado no quadro sobre sistemas PDM e EDM. Quadro 8.18

Sistemas Product Data Management (PDM — Gestão de Dados de Produto)

PDM é uma tecnologia de software que visa gerenciar todas as informações e processos relativos ao ciclo de vida de um produto. A tecnologia PDM propõe-se a explorar ao máximo os benefícios da Engenharia Simultânea, controlando a informação e distribuindo-a sistematicamente para as pessoas que dela necessitam. Várias nomenclaturas — como Product Information Management (PIM), Technical Document Management (TDM ), Technical Information Management (TIM) e Electronic Document Management (EDM) — são usadas com significados semelhantes. Porém, todos esses sistemas podem ser classificados dentro de dois grupos distintos: PDM e EDM. Sistemas Electronic Document Management (EDM) são todos aqueles focados no gerenciamento de documentos, podendo ou não estar relacionados à engenharia. Alguns autores tratam o EDM como um subconjunto do PDM, e outros consideram que o EDM possui uma abrangência horizontal maior (mais funcionalidades genéricas para tratamento da informação). O PDM utilizaria as funcionalidades do EDM direcionadas para as informações de engenharia, mas, na verdade, elas estão voltadas para o gerenciamento do produto e de seus itens, possuindo assim funcionalidades especiais, como controle da Estrutura de Produto (BOM — veja Quadro 8.14) e controle das mudanças de engenharia (Figura 8.33). No Brasil, o termo Gestão Eletrônica de Documentos (GED ) é o mais utilizado para denominar sistemas EDM. No quadro sobre GED, são apresentadas as funcionalidades desses sistemas. Existe uma grande superposição entre essas soluções, como está explicado no quadro sobre sistemas PLM. Figura 8.33

Visões alternativas sobre o relacionamento entre PDM e EDM.

Funcionalidades As funcionalidades de um sistema PDM podem ser divididas basicamente em gerenciamento de dados do produto e gerenciamento do processo. O gerenciamento de dados do produto abrange o controle da estrutura de produto, classificação de componentes e classificação de documentos. O gerenciamento do processo inclui todas as funcionalidades relativas ao fluxo de trabalho, como o processo de aprovação de um produto e de modificação de engenharia (veja o Quadro 13.2, sobre workflow). As funções de um sistema PDM podem ser divididas em funções de usuário e funções complementares, como descrito a seguir:

(continua)

348

PARTE 2

Quadro 8.18

O Modelo

Sistemas Product Data Management (PDM — Gestão de Dados de Produto) (continuação)

Funções do usuário Gerenciamento do ciclo de projeto: controla a criação e aprovação de documentos e partes do produto, a circulação (por meio de workflow), segurança e o acesso aos dados, relacionamento entre os dados, checkin e checkout; Alterações de engenharia: sistematização do Processo de Modificações de Engenharia (ECM), controle de versões e revisões; Estrutura de Produto (BOM): controla a estrutura, seus itens, controle de versões, status e documentos associados; Classificação: sistema de identificação e classificação de componentes e ferramentas de buscas rápidas e recuperação de informações; Gerenciamento de projetos: funções de planejamento e controle de projetos, controle de prazos e alocação de recursos (veja o Quadro 5.1, sobre sistemas de gerenciamento de projetos).

Funções complementares Comunicação: viabiliza a comunicação e notificação entre os usuários, e mantém interface com o sistema de e-mail; Transferência de dados: mecanismos de troca de dados entre os usuários do sistema, e entre diferentes aplicativos; Visualização: mecanismos de visualização rápida de imagens e redlines (anotações eletrônicas) sem a necessidade de executar o aplicativo de origem; Administração: configuração e customização, controle de usuários, administração do sistema.

Estrutura de um Sistema PDM Existe uma grande variedade de sistemas PDM disponíveis no mercado. Eles podem se diferenciar em vários aspectos, como no domínio de aplicação, arquitetura do sistema, abrangência de funcionalidades, preço etc. Porém, a maior parte deles utiliza os mesmos princípios para gerenciar as informações. A Figura 8.34 mostra esquematicamente a estrutura de um sistema PDM, seguida pela descrição de seus principais elementos. Figura 8.34

Estrutura de um sistema PDP.

Vault (cofre): o vault é o local onde os arquivos gerenciados ficam armazenados. É a parte do sistema que garante a segurança das informações e o controle de acesso dos usuários. Metadados: além do vault, o sistema possui uma base de dados com metadados (informação sobre a informação). Esses dados são informações sobre os arquivos, que permitem que eles sejam gerenciados. Alguns exemplos de metadados são: descrição do arquivo, autor, identificação do item, data de criação etc.

(continua)

CAPÍTULO 8

Projeto Detalhado

Quadro 8.18

349

Sistemas Product Data Management (PDM — Gestão de Dados de Produto) (continuação)

Modo de funcionamento O sistema PDP pode ser a interface única de acesso aos dados e aplicativos de engenharia. O usuário pode também acessar diretamente o aplicativo e armazenar o resultado do seu trabalho na base de dados do seu aplicativo. Mas, quando desejar compartilhar essas informações (ou mesmo acessar as informações liberadas por outras pessoas), ele deve utilizar as funcionalidades do PDM para arquivar o resultado de seu trabalho no cofre ou retirar uma informação disponível no cofre. As outras funcionalidades de gestão do projeto seriam acionadas por meio do PDM diretamente. Porém, atualmente, os sistemas de gestão de projeto (veja o Quadro 5.1) possuem funcionalidades de PDM. Para obter as informações de forma eficiente, é necessário que o sistema PDM esteja integrado aos aplicativos que geram as informações. A interface de sistemas PDM é geralmente gráfica e permite que o usuário acesse as informações disponíveis rapidamente, na forma de imagens, tabelas e gráficos.

Solução ideal A solução ideal e amplamente aceita não existe. A tendência é o usuário ter acesso a todos os objetos que ele deseja manipular via portal da empresa. O portal se encarregaria de acionar o sistema mais apropriado, que processa a informação desejada, cumprindo a tarefa acionada (veja discussão no Quadro 8.30 sobre sistemas PLM).

Benefícios • • • • • • • •

Integridade das informações Base única de dados técnicos Redução de custos (eliminação de tarefas improdutivas) Redução de time-to-market Redução do número de alterações de engenharia Preservação do acervo técnico Reutilização sistemática das informações existentes Aumento da produtividade do pessoal

Características da implantação O maior problema que envolve essa tecnologia, impedindo sua rápida expansão, é a dificuldade do processo de implantação dos sistemas PDM. Geralmente, esses processos são lentos, caros e exigem uma significativa adaptação técnica e cultural da empresa. Entretanto, muitos casos de sucesso estão mostrando que os benefícios de um sistema em funcionamento justificam sua utilização. Leia mais sobre este assunto em OMOKAWA, 1999.

Há um conjunto de funções desses sistemas PDM que são de workflow, mas também estão presentes em outros tipos de sistemas e são essenciais para manter uma troca estruturada de informações entre parceiros de um mesmo time. Principalmente, se esses parceiros estiverem distribuídos geograficamente e tiverem um elevado grau de interatividade e colaboração. Essa tecnologia é conhecida como workflow e está descrita no Quadro 13.2 do Capítulo 13. Graças à tecnologia de workflow, consegue-se realizar os ciclos descritos na Figura 8.31, possibilitando o paralelismo entre as atividades de detalhamento (veja o Quadro 8.17). Por exemplo, quando a informação de origem for modificada, é por meio desta tecnologia que se pode avisar automaticamente todos os interessados. No exemplo de engenharia simultânea, do Quadro 8.17, imagine que um dos desenhos reprovados deu origem a muitas informações de processo. A ligação lógica entre esses tipos de documentos é a condição para se saber que todos os usuários da informação precisam ser informados da mudança. O controle de versões do PDP/ECM desatualiza todas as informações dependentes, e o workflow envia as mensagens e a nova informação, de acordo com a sua configuração.

350

PARTE 2

O Modelo

Vamos agora conhecer as tarefas desta atividade, que estão listadas na Figura 8.35. Figura 8.35

Tarefas da atividade de planejamento de processo.

Primeiro, procura-se reutilizar os planos de processos existentes, uma vez que a economia, assim obtida, pode ser significativa.39 Para tanto, é preciso que haja na empresa uma sistemática de armazenamento dos documentos, permitindo que se encontrem planos de processos similares que podem ser reutilizados, assim como a tarefa de reutilizar itens, descrita no início do Tópico 8.3, “Criar e detalhar SSCs, documentação e configuração”. A classificação dos itens, realizada na atividade de criação e detalhamento dos SSCs, é uma condição para que se possam recuperar as informações nesta tarefa. Seu sucesso determina o método amplo de planejamento de processo (veja o Quadro 8.19). A partir da recuperação de um plano de processo existente, a sua modificação segue as tarefas descritas a seguir. Primeiro, procuraremos reutilizar o que já existe para economizar

Quadro 8.19

Métodos Amplos de Planejamento do Processo Tradicional (Manual)

A existência de um plano de processo que foi recuperado determina o método de planejamento de processo. Os métodos de planejamento de processo podem ser classificados em generativo e variante. O método generativo é empregado normalmente para novos itens, quando o processista não consegue reutilizar planos antigos e inicia o planejamento sem referência alguma. Ele parte da análise do desenho e das tolerâncias, e realiza as tarefas

(continua) 39

Este método de planejamento de processo é conhecido como planejamento variante. Em algumas empresas, nas quais componentes similares são sempre produzidos, pode-se economizar até 60% do tempo com o planejamento variante.

CAPÍTULO 8

Projeto Detalhado

Quadro 8.19

351

Métodos Amplos de Planejamento do Processo Tradicional (Manual) (continuação)

de planejamento, utilizando o conhecimento sistematizado, regras e fórmulas para a definição das informações e cálculos necessários. No método variante, o processista consegue reutilizar o plano de processo e detalhamentos existente, que foi realizado para um item semelhante. Com base nesse plano, ele cria outro, para o novo item. Ou seja, ele modifica o plano existente, aumentando assim a sua produtividade. Outra maneira de realizar o planejamento variante é por meio dos planos-padrão. Normalmente, esse método de planejamento só é possível de ser realizado quando a empresa produz itens organizados em famílias de peças, e quando foram criados planos-padrão para essas famílias. Na tarefa de reutilização de planos existentes, a classificação do novo item leva a se encontrar a família para a qual existe, nesses casos, um plano-padrão. A diferenciação desses métodos passa a ter um interesse maior quando se automatiza a atividade de planejamento (veja o Quadro 8.21, sobre sistemas CAPP, no final deste tópico).

Normalmente, o planejamento do processo não acontece de forma linear. As O raciocínio no informações obtidas possuem uma interdependência. Um processista experiente planejamento não realiza a maior parte das inferências de forma aleatória, ou seja, utilizando uma lóacontece de forma linear gica específica, que leva em consideração o tipo de peça, as condições de trabalho, sua experiência etc. Somente no momento da documentação dos resultados (edição do plano de processo) é que ele segue uma seqüência linear. Mesmo assim, existem muitas variações. Para peças mais complexas, é comum se ver o processista “ficar olhando” para peça durante horas, antes de começar a editar o plano de processo. A Figura 8.36 procura apresentar a interdependência entre essas tarefas. Não vamos descrever essas interdependências, pois é um processo complexo de raciocínio e diferente para cada processista. Colocamos essa figura para ilustrar a dificuldade que existe em sistematizar essas tarefas. Figura 8.36

Interdependência entre as tarefas de planejamento de processo.

352

PARTE 2

O Modelo

As descrições das tarefas, mostradas a seguir, estão relacionadas ao plano de processo de fabricação mecânica. No final desta seção, serão apresentadas algumas particularidades para outras tecnologias e do plano de processo de montagem. Uma das tarefas é a definição e/ou avaliação da peça em estado bruto, que norDefinição e/ou avaliação malmente já vem definida do projeto. Nesse caso, durante o planejamento do proda peça em estado bruto cesso, verifica-se se o sobremetal existente entre a peça em estado bruto e a peça final é suficiente para que cada operação retire material suficiente. Porém, se só vier especificada a matéria-prima da peça, o planejamento de processo determinará a forma mais apropriada. Essa função é muito importante na fabricação de grandes lotes, nos quais as peças em estado bruto são forjadas. Nesses casos, procura-se atingir uma máxima capacidade de produção por meio da menor taxa de remoção possível de cavaco. Ressalta-se que, apesar de ser uma das tarefas iniciais, ela depende das demais tarefas para se calcular com precisão o sobremetal. Devido a isso, essa tarefa também é realizada novamente após a definição de todas as operações e seus sobremetais intermediários. A determinação das operações e sua seqüência é uma tarefa determinante para Determinação das a definição das outras informações do plano de processo, mas ela também depende operações e sua seqüência das demais informações (veja a Figura 8.36). Ela deve estar em consonância com a seqüência de processos de fabricação, definida nas fases anteriores, e também com o plano de processo macro existente. São as operações que fornecem ao componente suas características e funcionalidades desejadas por meio da obtenção das especificações críticas, que podem ser as dimensões ou outras características físicas e suas tolerâncias. O que limita a especificação das operações e sua seqüência são os fatores econômicos, pois se deseja sempre obter um componente com o menor custo possível. A definição da máquina ou equipamento, que realiza uma operação, e a própria Selecionar/Especificar determinação da operação estão intimamente ligadas, pois as duas tarefas de planemáquinas e equipamentos jamento do processo são realizadas praticamente em conjunto, e uma não existe sem a outra. As tolerâncias das especificações críticas do componente definem quais máquinas e equipamentos podem ser utilizados. A informação sobre o equipamento necessário é muito importante para se planejar a produção (em curto prazo) e definir novos investimentos (em longo prazo). A informação sobre equipamento determina o posto de trabalho para a programação da produção. Os custos-padrão de cada posto de trabalho contribuem para o cálculo do custo de fabricação da peça (utilizado na atividade de decidir comprar ou fabricar). Caso a operação seja feita em máquinas existentes na empresa, ela é simplesmente selecionada de uma base de dados e especificada no plano de processo. Se a máquina não existir, pode-se partir para sua especificação e compra (se for encontrada no mercado) ou especificação, projeto e fabricação (no caso de máquinas especialmente desenvolvidas para o SSC em questão). Deve-se contar com pessoal qualificado para operar a máquina ou equipaSelecionar/Especificar mento especificado. Isso é especialmente importante para quando existir uma depessoal e habilidades pendência em relação à habilidade do operador. Esse é o caso mais freqüente nas operações de montagem. A forma como se posiciona e fixa o componente na máquina ou equipamento Especificar fixação determina a qualidade da operação de fabricação, pois, a partir dos sistemas da referência do componente, obtêm-se todas as cotas e tolerâncias. No planejamento de processo, também se determinam as operações de inspeção Especificar inspeção que são realizadas durante o processo produtivo. Essas operações devem medir os parâmetros de processo que determinam as especificações críticas do componente e, 40 portanto, avaliam a capabilidade do processo. Com base nessas operações de inspeção, são montadas as folhas de Controle Estatístico do Processo (CEP),41 que são utilizadas no momento de produção dos componentes. 40 41

Veja o Quadro 9.2, sobre capabilidade de processo. As folhas de CEP também são mencionadas no Quadro 9.2, sobre capabilidade de processo.

CAPÍTULO 8

Projeto Detalhado

353

Na realização de todas as operações podem ser utilizados métodos de fabriSelecionar/Especificar cação, fixação, inspeção e montagem. Esses métodos podem ter sido padronizados métodos pela empresa ou mesmo por instituições normativas. Nesse caso, eles são selecionados durante o planejamento do processo. Há também a possibilidade de especificar novos métodos para a realização das operações citadas. O processo de soldagem de precisão e alto risco é um exemplo típico de métodos padronizados e que precisam ser reutilizados no detalhamento de uma operação. O método e também o soldador (a pessoa que realizará a soldagem) precisam estar certificados. O termo “ferramental” abrange os dispositivos de fixação, de inspeção e as ferSelecionar/Especificar ramentas de produção, que podem ser especiais ou universais. ferramental A determinação do dispositivo de fixação é necessária para garantir a qualidade de fabricação. Em grandes séries, os dispositivos garantem também uma alta taxa de produção. Os dispositivos podem ser especiais, universais e modulares. Esses últimos são apropriados para os componentes de pequenas dimensões. Os dispositivos universais são aqueles que vêm como acessórios dos equipamentos, como: pinças, castanhas, cones etc. Os dispositivos especiais tomam bastante tempo do projeto e da fabricação, tornando-se muitas vezes o gargalo na fabricação de um lote de componentes (veja atividade descrita no Tópico 8.7). A determinação de dispositivos bem antes do planejamento de operações é um outro desafio da Engenharia Simultânea. Antes de se terminar o detalhamento das operações do plano de processo, deve-se ter uma boa noção das características do dispositivo para que ele possa ser especificado, projetado ou comprado antes de se produzir o lote piloto (veja a atividade “obter recursos de fabricação da fase de preparação da produção”, no tópico 9.2). As ferramentas de inspeção envolvem o uso de ferramentas universais e também de ferramentas especialmente projetadas e fabricadas para a verificação de uma especificação crítica do componente resultante da fabricação. A definição de ferramentas de produção está intimamente ligada à determinação de operações e influencia as demais funções do planejamento de processo, como cálculo dos parâmetros da operação e dos tempos de fabricação. Sobremetal representa o volume de material retirado por uma operação e é calCalcular sobremetal culado somente na produção de grandes lotes, pois cada milímetro que se economiza na usinagem de um componente representa muito quando multiplicado pela quantidade de componentes. O sobremetal que uma operação deve retirar deve permitir que sejam eliminados 42 os erros da operação anterior e os da própria operação causados pela capabilidade da máquina ou equipamento. De forma geral, os parâmetros de trabalho compreendem os ajustes de máquinas e equipamentos, e as condições de usinagem, quando se tratar de processos de fabricação mecânica.

Calcular parâmetros de trabalho

O cálculo das condições de usinagem depende essencialmente da ferramenta utilizada e do material da peça. Outros fatores são o acabamento superficial do componente, potência disponível na máquina etc. Em empresas organizadas, o processista determina essas informações com base nas informações contidas nos catálogos dos fabricantes de ferramentas. Há também a possibilidade de calcular as condições de 43 usinagem a partir de manuais de valores obtidos em ensaios de usinagem. Em empresas maiores, que trabalham em alta série, o fabricante de ferramentas é consultado e realiza ensaios na própria empresa, com as condi-

42 43

Para uma consulta mais aprofundada sobre o cálculo de sobremetal, consulte THIMM, G.; BRITTON, G. A.; FOK; S. C, 2004. A carta de tolerância de fabricação é uma técnica utilizada para apoiar o cálculo de sobremetal. Um dos exemplos clássicos é o Machining Data Handbook, 1980. Os valores contidos nesses manuais, no entanto, foram obtidos em ensaios controlados, e dificilmente suas condições práticas são as mesmas, devendo então ser adaptados para cada realidade. Os fabricantes de ferramentas oferecem catálogos de seus produtos com a indicação de parâmetros de usinagem apropriados para cada tipo de operação. Esses catálogos servem para as aplicações normais. Eles possuem versão na web (veja http://www.sandvik.com). Em aplicações especiais, deve-se contatar o fabricante, para realizar ensaios na própria empresa, quando possível.

354

PARTE 2

O Modelo

ções e materiais de trabalho, a fim de estabelecer as especificações necessárias. Podem acontecer muitos desvios devido à não-homogeneidade dos materiais envolvidos e à falta de conhecimento de processo. Outros tipos de parâmetros de trabalho são calculados com base em padrões e usam a referência de ensaios práticos. Pode-se também obter as especificações críticas das operações, como resultado do desdobramento da 44 função qualidade do componente. As instruções de trabalho são textos explicativos, cujo objetivo é mostrar detaDescrever instruções de lhadamente ao operador como proceder na realização de uma operação, preparação trabalho da máquina ou equipamento, inspeção de um parâmetro de um componente e até mesmo de fixação do componente no dispositivo de fixação. Essa tarefa normalmente é repetitiva e ocupa bastante tempo do processista. Para minimizar esse desperdício de tempo, trabalha-se com textos-padrão predefinidos que são reutilizados na edição de novas instruções.45 As instruções complementam as possíveis explicações existentes nos métodos-padrão adotados para a realização de diversos tipos de operações. Como se diz, “uma figura ilustra mais do que 100 palavras”. As instruções de traIlustrar operações balho podem ser complementadas ou mesmo substituídas por ilustrações de diversos tipos, como: croquis, desenho CAD, filmes, animações. Essa tarefa exige uma inte46 gração entre sistemas gráficos e sistemas CAPP. Toda vez que uma operação for realizada em uma máquina CNC, deve-se Obter programa CN obter o programa CN. Essa tarefa equivale praticamente à definição de operações, seu seqüenciamento e seleção de ferramentas, mas sua principal função é calcular o trajeto da ferramenta e especificá-lo em um formato particular da máquina CNC, na qual a operação será realizada.47 As informações de detalhamento de uma operação, instruções, ilustrações Criar informações / devem ser registradas em documentos que, na maior parte da empresas, ficam ao documentos de apoio ao lado dos postos de trabalho, contribuindo assim para a garantia da qualidade do traoperador balho. O formato desses documentos varia de empresa para empresa e precisa ser elaborado de forma que as informações sejam acessíveis para os operadores, preparadores de máquina etc. Há atualmente vários casos de empresas que não colocam mais os documentos ao lado dos postos de trabalho, utilizam terminais gráficos e mesmo a web, que inclusive podem conter filmes que mostram, por exemplo, como se deve montar um equipamento. Deve-se, nesses casos, estudar qual o melhor formato para mostrar as informações do plano de processo e seus detalhamentos ao operador das máquinas e equipamentos. Os tempos de fabricação e montagem podem ser calculados por meio de diCalcular tempos de versos métodos. Um dos métodos utiliza padrões de movimentos e tempos elemen48 fabricação e montagem tares. Ele é mais apropriado para se calcular o tempo que envolve as pessoas. Analiticamente, pode-se calcular o tempo gasto com a usinagem em função dos parâmetros de trabalho (especificamente, a velocidade de avanço) e do caminho a ser percorrido pela ferramenta.49 Quando se trabalha em máquinas CNC, o tempo de fabricação pode ser calculado com certa precisão por meio da simulação do processo. Mas não podemos esquecer que o tempo de fabricação é somente um dos compo44 45 46 47 48 49

Utiliza-se aqui o método QFD (veja o Quadro 6.5 correspondente) dentro do conceito de gerenciamento dos parâmetros críticos (veja o Quadro 8.10). Leia sobre textos-padrão no Quadro 8.21 sobre sistemas CAPP. Sistemas CAPP são os sistemas que apóiam o planejamento do processo (veja o Quadro 8.21). Pode-se automatizar o cálculo da trajetória da ferramenta por meio de sistemas CAD/CAM ou mesmo editores gráficos de programação CN. Para os tipos de métodos de programação CNC, consulte VEGA, 1993. Sobre cálculo de tempos elementares, consulte NIEBEL, 2002. Na teoria de usinagem dos metais, encontram-se fórmulas clássicas para calcular esses tempos. Para encontrar as fórmulas dos diversos processos de fabricação, consulte NIEBEL, 2002.

CAPÍTULO 8

Projeto Detalhado

355

nentes do tempo-padrão da operação. A forma mais tradicional de calcular esses tempos é por meio do estudo de tempos em métodos baseados em cronometragem da operação. Esse método tem a desvantagem de se obter o tempo somente após a realização da operação. Na fase de projeto detalhado, necessita-se ter uma noção relativamente precisa do tempo, pois eles são utilizados na determinação da carga de máquinas e dos custos de produção.50 A programação da produção utiliza ainda, em alguns casos, esses tempos.51 Com as informações das operações e máquinas ou equipamentos, pode-se anaOtimizar fluxo de lisar o fluxo da produção resultante da produção de um lote do produto em desenprodução volvimento, quando as máquinas já existirem. Nesse caso, deve-se verificar também os outros produtos e seus componentes que utilizam as mesmas máquinas. No caso de novas instalações, é mais simples avaliar o fluxo de produção. A otimização realizada nessa fase é analítica. Existem muitos algoritmos que podem ser usados.52 Uma outra possibilidade é aplicar ferramentas de simulação (veja o Quadro 8.20, sobre manufatura virtual). Na fase de preparação — depois que os equipamentos chegarem à empresa, ou no caso de instalações existentes — quando for fabricado o lote piloto, existe a possibilidade de otimizar o fluxo novamente de forma prática. Na indústria automotiva, algumas montadoras adotam um padrão de qualidade, que exige de certos clientes o envio dos estudos de análise de fluxo de produção, para verificar se eles otimizaram o fluxo e assim diminuíram 53 o custo de fabricação dos componentes que eles recebem. O processo de fabricação pode ser simulado de diversas formas. Basicamente, o Simular processo de objetivo da simulação é antever os problemas das operações e tentar otimizar o profabricação cesso. Pode-se simular desde o caminho da ferramenta de um programa CNC, como o fluxo de material em um processo de injeção plástica. Utiliza-se atualmente a realidade virtual no contexto mais amplo da manufatura virtual para se simularem os processos e, ao mesmo tempo, obter-se a sua visualização. Quadro 8.20

Manufatura Virtual

Manufatura virtual é mais um dos termos que reúne várias tecnologias digitais utilizadas na área de manufatura e possui uma superposição com outros termos utilizados neste livro. Ela pode ser vista como um ambiente integrado para analisar alternativas de soluções digitais, que visam melhorar a tomada de decisão no que diz respeito à melhor alternativa. A manufatura virtual oferece ferramentas para todas as fases do desenvolvimento de produtos, tratando principalmente do uso de sistemas de simulação e de realidade virtual. Os sistemas CAE (veja o Quadro 8.11) podem ser entendidos como um tipo de tecnologia de manufatura virtual.

(continua)

50 51

52 53

Entenda-se aqui custos pré-determinados para a tomada de decisões gerenciais, e não custos contábeis. No entanto, os custos contábeis podem utilizar os padrões de tempos do plano de processo se eles forem confiáveis e se a empresa adotar o método de custo-padrão. Os tempos utilizados na programação da produção (quando for o caso, pois em algumas empresas não se usam os tempos para se programar, principalmente se a empresa trabalhar com a filosofia da programação puxada — leia mais sobre produção puxada em WOMACK, 1996) podem ser diferentes daqueles utilizados para o cálculo do custo (leia mais sobre cálculo de custo em CROW, 1999). Quando se planeja a produção e define-se o lead time do componente, os tempos dos planos de processo devem ser acrescidos aos tempos de transporte do material entre as máquinas e os tempos de fila em uma máquina (leia mais sobre lead time em CORREA, 2001). Na programação fina da produção, utilizam-se os tempos dos planos de processo, adotando-se ainda uma política de superposição entre as operações (leia mais sobre programação fina da produção em CORREA, 2001). Na lean production, os tempos não são usados para a programação, mas para o cálculo do takt time, que define o ritmo de produção de uma célula de fabricação com base na demanda do cliente (leia mais no quadro sobre lean production e, em WOMACK, 1996, sobre o cálculo de takt time). Veja no trabalho MUTHER uma lista de métodos de otimização de layout. Observe o manual do Plano de Aprovação de Peças de Produção (PAPP) da QS 9000, para submissão de peças aos clientes. HOYLE, 1997.

356

PARTE 2

Quadro 8.20

O Modelo

Manufatura Virtual (continuação)

Hoje já é possível envolver um usuário no ambiente de trabalho futuro por meio da realidade virtual. Ele pode simular várias operações e concluir qual o melhor método e as soluções construtivas apropriadas. Imerso em um ambiente virtual, ele manipula objetos tridimensionais, permitindo análises mais intuitivas. Os modelos de simulação contínuos e matemáticos ajudam a prever o comportamento de produtos (por meio de sistemas CAE). Esses modelos são conhecidos como protótipo virtual ou digital. Isso evita que protótipos reais sejam construídos e acelera o tempo de desenvolvimento. No caso do projeto de sistemas produtivos completos (projeto de fábrica — veja quadro correspondente), pode-se utilizar a simulação de eventos discretos, que representaria, por exemplo, as operações de manufatura de uma empresa metal-mecânica. Nesses modelos, podem ser integrados métodos estocásticos que mostram a variação de entradas e saídas, segundo leis da estatística. Com isso, os modelos e os sistemas provêm de respostas apropriadas para a análise e sua otimização. Os modelos de simulação estão ficando tão sofisticados que poderão ser usados em pouco tempo em sistemas de manufatura, simulando, em tempo real, o seu comportamento, com base em dados levantados por sistemas de controle. Assim, um problema poderá ser detectado momentos antes do seu aparecimento. Hoje em dia, a maior dificuldade é ainda criar um modelo mais próximo da realidade, tanto para a realidade virtual quanto para a simulação. Essas ferramentas estão ficando mais amigáveis e o processamento possível graças ao avanço do hardware e software. Com isso, o tempo de simulação diminui (quando existem regras matemáticas muito complexas) e a interatividade com o ser humano torna-se mais intuitiva. A maior parte das ferramentas de manufatura virtual não trabalha de forma integrada, e isso traz uma dificuldade adicional, que deve ser sanada com a evolução da tecnologia de informação. Para obter maiores informações sobre este assunto, consulte PORTO, 2000.

Atualmente, a estrutura do produto contém não somente os SSCs, como também todas as operações do plano de processo dos componentes fabricados, operações de montagem dos sistemas e subsistemas, e a documentação associada a eles.54 A tarefa de atualizar a BOM garante a criação de uma BOM única dentro da empresa (veja o Quadro 8.10, sobre tipos de BOM). Na Figura 8.38, pode-se observar o exemplo de uma BOM com os documentos do plano de processo associados a um item. As tarefas apresentadas tiveram sua ênfase no processo de fabricação mecânica. Planejamento de outros O planejamento dos processos de fabricação metalúrgicos e de fabricação de comtipos de processos ponentes eletrônicos injetados contém praticamente as mesmas tarefas. A diferença está nas ferramentas, máquinas e equipamentos utilizados; nos detalhes que são diferentes; e nas mudanças das características de processo e seus parâmetros. Por exemplo, não há o cálculo de sobremetal no processo de injeção plástica. Além disso, outros parâmetros são importantes, como a pureza da peça injetada. A maior diferença do planejamento de operações de montagem está na caractePlanejamento de rística deste processo e seus parâmetros. Na montagem de subsistemas eletro-eleoperações de montagem trônicos, existe uma grande possibilidade de automação, e a especificação das máquinas, na maior parte das vezes, é especial para cada caso. Em regra, todavia, as operações de montagem são realizadas com a intervenção de um operador, e o planejamento da montagem precisa considerar as particularidades de ergonomia e saúde no trabalho. As mesmas tarefas acontecem, mas são uti55 lizados métodos distintos. Pode-se aumentar a produtividade da realização dessas estratégias de planejamento de processo, realizadas de forma manual, por meio da aplicação de sistemas Computer Aided Process Planning (CAPP ), como mostra o Quadro 8.21. Atualizar a BOM

54 55

No trabalho de OLIVEIRA, 1999, encontra-se uma apresentação completa dos tipos de estrutura de produto existentes. Sobre planejamento do processo de montagem, leia WANG, 1991.

CAPÍTULO 8

Projeto Detalhado

Quadro 8.21

357

Sistemas Computer Aided Process Planning (CAPP)

A qualidade do planejamento de processo convencional depende da experiência do processista e dos métodos e ferramentas que ele utiliza. Na forma convencional, o processista cria o plano de processo manualmente ou digitando em formulários de editores de texto. Essas informações são depois digitadas novamente em sistemas de Planejamento e Controle da Produção (PCP), como um sistema SCM/ERP (veja o Quadro 2.5). Em alguns casos, o processista digita diretamente as informações de processo nesses sistemas. Essa forma de planejar o processo de fabricação continua sendo empregada em várias empresas de manufatura. Contudo, esse modo de planejamento possui uma baixa produtividade, pois, em média, 63% do tempo é gasto com a redação e/ou digitação; 21% com cálculos diversos; e 8% com a recuperação de informações. Ou seja, 92% do tempo é empregado em funções que não agregam valor diretamente, e apenas 8% é utilizado em funções como concepção e análise. No início do desenvolvimento de sistemas CAPP, pretendia-se automatizar totalmente a tarefa de planejamento e substituir o processista de uma empresa. Foi a época das primeiras aplicações práticas de inteligência artificial. Muitos desenvolvimentos eram teóricos, funcionavam em casos específicos e não eram utilizados pelas empresas, tornando-se acadêmicos. Com a evolução da tecnologia de interatividade homem-computador, aumento de padronização, facilidade de manipulação de base de dados e linguagens de alto nível e de produtividade, surgiram sistemas mais flexíveis. Foram criados sistemas com inteligência na medida correta, ou seja, toda a vez que o domínio de aplicação era restrito e fácil de obter as 56 regras de negócio (neste caso de planejamento do processo), tornou-se possível a automatização.

Tipos de CAPP Vimos que se pode realizar o planejamento de processo tradicional de duas formas: generativa e variante. Com o CAPP, aumentam as possibilidades, resultando nos seguintes métodos de planejamento: Planejamento do Processo Generativo Interativo: o processista insere as informações de processo diretamente no computador, com base na escolha de padrões pré-cadastrados, por meio de uma interface amigável. Ele não precisa digitar textos longos ou explicativos para descrever uma operação. Além disso, se dois processitas digitassem, os textos seriam distintos. Neste método de planejamento, o processista escolhe o texto-padrão mais adequado para descrever a operação, e complementa o texto, quando necessário. A busca de padrão é ainda apoiada por uma classificação, ou filtros, que facilita a sua busca. Dessa maneira, o processista interage diretamente com o computador, digitando e encontrando menos dificuldade. Quando existir uma relação entre os padrões (por exemplo, a ferramenta “X” só pode ser utilizada na máquina “Y”), o processista não precisa navegar por muitas opções para escolher um padrão (no exemplo, a ferramenta). O sistema verifica o que já foi determinado e só apresenta para a seleção aqueles padrões que se relacionam com os já escolhidos (por exemplo, uma lista das ferramentas que podem ser utilizadas na máquina “Y”). Planejamento Generativo Automático: o princípio deste método de planejamento do processo é baseado no armazenamento de regras e dados de capacidade do processo de fabricação. Por meio dessas informações, é gerado um plano de processo sem a necessidade de uma pessoa experiente, pois os mecanismos de inferência, decisões, lógicas e algoritmos interpretariam os dados de projeto e tomariam as decisões sobre “como fazer”. Esse é o caso mais completo de planejamento automático. No entanto, pode haver outras formas de planejamento automático, nas quais somente certas funções de planejamento são automatizadas (veja a seguir, “Planejamento Híbrido”). A representação das peças deve estar armazenada no computador de uma forma interpretável pelo sistema CAPP, para que ele realize inferências automáticas nas tomadas de decisão. A melhor forma de representação para a inferência automática são os features (elementos da peça com significado para a fabricação e representação gráfica associada — veja o Quadro 8.10, sobre sistemas CAD/CAE). Planejamento do Processo Variante: parte da recuperação de um plano de referência, que é modificado, para se obter um novo plano. Neste tipo de planejamento, são utilizados planos-padrão ligados a famílias de peças ou planos semelhantes, que não requerem a formação de famílias de peças, proporcionando uma sistematização de curto período e investimento. É o mesmo princípio do planejamento variante do processo de planejamento tradicional, porém o computador fornece ferramentas poderosas de armazenamento de planos para posterior recuperação. Os sistemas CAPP variante usavam, antigamente (alguns ainda utilizam), códigos de classificação de produtos para recuperar informações semelhantes, assim encontravam um plano de processo, a partir do qual criavam um novo plano para uma peça semelhante. Hoje os sistemas oferecem buscas mais flexíveis, que utilizam o poder das bases de dados, e recuperam produtos semelhantes, procurando em categorias de produtos similares, criadas interativamente na base de dados, sem a necessidade de um código de classificação.

(continua) 56

Veja o exemplo de um caso de automação sobre medida em RIBEIRO, C. E. S.; KERRY, H. T.; PIEBER, E.; ROZENFELD, H., 1996.

358

PARTE 2

Quadro 8.21

O Modelo

Sistemas Computer Aided Process Planning (CAPP) (continuação)

Planejamento Híbrido: como cada método apresenta vantagens e desvantagens, a conclusão natural é a de que a combinação desses métodos em uma solução híbrida pode conseguir os melhores resultados de cada um dos métodos. A solução híbrida permite a utilização das vantagens de cada método, em partes distintas, das funções de planejamento de processo. Para itens totalmente novos, que não possuam planos de processo semelhantes, inicia-se o planejamento por meio do generativo interativo e, em determinados pontos, pode-se requisitar que o sistema faça uma inferência automática (por exemplo, para cálculo de tempos, cálculo de condições de usinagem, geração de CN para um feature conhecido). Outros itens, de formato mais bem comportado, que apresentem uma certa repetição, podem ser mais bem planejados por meio do método variante (Figura 8.37). Figura 8.37

CAPP híbrido.

Pode-se realizar também a geração de planos de processo de maneira totalmente automática, como no caso de peças que podem ser parametrizadas, por exemplo uma engrenagem, que pode ser descrita pelo seu passo de base, diâmetro primitivo, módulo etc. Nesse caso, o computador interpreta os parâmetros, realiza inferências na base de regras e fórmulas e gera automaticamente o desenho e o plano de processo, com seus detalhamentos. Planejamento do Processo usando sistemas ERP e/ou SCM: os sistemas ERP/SCM (veja o Quadro 2.5) também trabalham com padrões, facilitando a edição inteligente, ou seja, em vez de digitarmos textos longos sobre operações ou instruções, trabalhamos com textos padronizados, com significados lógicos para os sistemas. Alguns sistemas ERP fornecem módulos denominados CAPP, que, na verdade, são processadores automáticos de regras e fórmulas. Eles podem ser utilizados na tarefa de planejamento de processo, mas também em outras tarefas, quando existirem regras confiáveis para automação do processo. É o caso típico do cálculo de tempos elementares para, por exemplo, prever-se o tempo de uma tarefa de montagem. Sistemas CAPP parciais: há vários sistemas individuais voltados para automatizar funções especificas, como cálculo de tempos, condições de usinagem, seleção de ferramenta, desenho de ferramental específico etc. Esses sistemas podem ser considerados CAPP, apesar de cuidarem de tarefas especificas. Atualmente, é possível a sua integração em ambientes de planejamento mais amplos. Esta é mais uma vantagem dos sistemas híbridos.

Outras denominações e funcionalidades de gerenciamento integradas ao CAPP Alguns fornecedores de sistemas CAPP aumentaram a abrangência de seus sistemas e passaram a oferecer outras funcionalidades, mudando inclusive a denominação do sistema para Manufacturing Process Management (MPM), Manufacturing Information Management (MIM), ambos como parte do Manufacturing Execution Management (MES), e também para Product Data Management (PDM) e Product Life-cycle Management (PLM). Essas funcionalidades visam a integração desses sistemas com os demais sistemas de engenharia e gestão, e envolvem: gerenciamento da Estrutura de Produto (BOM), funções de gestão de documento (check in, check out, visualização de representações gráficas, workflow. Veja o Quadro 8.18, sobre

(continua)

CAPÍTULO 8

Projeto Detalhado

Quadro 8.21

359

Sistemas Computer Aided Process Planning (CAPP) (continuação)

sistemas PDM/EDM e Quadro 8.30, sobre PLM). As funções de planejamento de processo fazem parte agora de um diferencial desses sistemas, que os tornam “mais inteligentes”.

Benefícios reportados com o uso de sistemas CAPP Redução do tempo de planejamento: um dos principais ganhos com a implantação do CAPP é o aumento da produtividade de planejamento do processo. Com isso, é possível elaborar os planos de processos com um número reduzido de processistas e em curto período de tempo. Agilidade nas revisões: com o CAPP, cada operação do processo pode ser facilmente revisada. O histórico das revisões pode ficar armazenado em uma base de dados, possibilitando o acompanhamento de todas as modificações. Padronização dos processos: o uso do CAPP pode permitir que todos os parceiros trabalhem com um modelo único de plano de processo, garantindo uma padronização da documentação de processos da fábrica, além de garantir a padronização dos termos adotados. Criação de uma base única de processos: o CAPP permite a criação de uma base de dados única de processos, garantindo a integridade das informações registradas. Possibilidade de analisar os processos existentes na base de dados com funções do tipo where-used (em qual operação determinado padrão foi utilizado, especificado). Assim, por exemplo, pode-se diminuir a multiplicidade de ferramentas. Aumento da qualidade dos processos: com o uso do CAPP, pode-se adicionar outros tipos de informações aos planos de processos, além das informações descritivas. Assim, pode-se fazer uso de informações visuais por meio de fotografias, gráficos, desenhos ou outras instruções detalhadas do processo, como listas dos componentes montados em cada operação, instruções de controle e dispositivos necessários. Existem ainda várias outras vantagens, por exemplo, a redução drástica de papel impresso, agilidade na elaboração e alteração de uma especificação de projeto, alta confiabilidade nos dados (por estarem automatizados com fórmulas de cálculos), definição de hierarquia para aprovação de projeto, entre outras. As conseqüências do uso de CAPP nas outras áreas da empresa são: diminuição de refugos, diminuição do custo de ferramentas, diminuição de lead-time e criação de padrões de engenharia. Leia mais sobre este assunto em HALEVI, G.; WEILL, R. D., 1995.

Na Figura 8.38, apresenta-se a estrutura do torno, com seus documentos assoSituação do exemplo do ciados, após a atividade de planejamento de processo. Mostramos o plano de protorno após a finalização cesso somente de um componente, o eixo 1, que faz parte do subsistema do do processo eixo-árvore. Podemos observar na figura, na seqüência de cima para baixo, os seguintes exemplos de detalhamento do plano macro: folha de instruções de preparação da máquina, gráfico de inspeção, folha de montagem da ferramenta, ilustração de uma operação, programa CN e uma foto ilustrando a fixação do eixo na máquina em trabalho. Parte desses detalhamentos listados relaciona-se com uma operação do plano macro. Isso quer dizer que o plano de processo do eixo possui ainda muitos outros documentos não representados na figura. Repare que, para o item-pai do eixo, o subsistema do eixo-árvore, foi criado um plano de processo de montagem, que indica a seqüência das operações de montagem, as estações de montagem, e o tempo de montagem. Além disso, foi colocado, a título de ilustração, um documento de instruções de montagem, relacionado com uma das operações. Falta agora o projeto do dispositivo de fixação para inspeção. Ele já foi especificado e a sua identificação está criada na estrutura de documentos do plano de processo, mas ele ainda não foi projetado. Durante o seu projeto, descrito na próxima atividade, pode surgir a necessidade de atualização do plano de processo.

360

PARTE 2

Figura 8.38

8.7

O Modelo

Exemplo do torno após a atividade de planejamento do processo.

Projetar recursos de fabricação

Os recursos de fabricação compreendem: máquinas, equipamentos, ferramental e instalações. O termo ferramental, como já apresentado, abrange os dispositivos de fixação, de inspeção e as ferramentas de produção. Exemplos de ferramentas de fabricação são ferramentas de usinagem, moldes de injeção plástica, estampos de corte etc. Um dispositivo de fixação serve, por exemplo, para posicionar e fixar alguns componentes nas máquinas, como castanhas ou grampos de fixação. Uma ferramenta de medição — utilizada, por exemplo, na inspeção de uma especificação crítica de um componente durante a fabricação — pode ser um relógio comparador para avaliar a batida circular de um eixo. Um dispositivo para a mesma função pode ser um entre pontas, no qual o eixo girará para se verificar a batida. As instalações podem compreender uma instalação elétrica e hidráulica para o funcionamento de uma máquina ou até a construção de uma nova fábrica. Os recursos de fabricação podem ser universais e, portanto, comprados. Mas Recursos comprados ou eles também podem ser especiais e, para isso, devem ser especialmente projetados. fabricados57? Na maior parte das vezes, as empresas também compram os recursos especiais. Dependendo do acordo comercial entre o fornecedor e a empresa, o projeto é realizado pelo próprio fornecedor (caso mais comum) ou pela empresa. Ela mesma pode deO que são recursos de fabricação?

57

Leia, no Tópico 9.4, sobre a obtenção de recursos de fabricação na fase de preparação da produção.

CAPÍTULO 8

Projeto Detalhado

361

58

cidir fabricar o recurso de fabricação e, conseqüentemente, precisa projetá-lo. Essas opções são válidas para máquinas, equipamentos e ferramental. No caso de instalações, são poucas as empresas que ainda assumem a tarefa de projetá-las completamente. Nas empresas, é comum encontrar áreas que cuidam do layout, que resulta da atividade de planejamento de processo, já as demais especificações das novas instalações ficam a cargo de empresas especializadas. Em algumas empresas, como uma fábrica de girabrequins, o projeto do molde Exemplos de projetos de de forjamento segue alguns passos do processo de desenvolvimento de produtos ferramentas e dispositivos descrito neste livro, devido a sua complexidade. Na fase de validação, o fluxo de material no processo de forjamento é simulado por elementos finitos para se otimizar a geometria da ferramenta. No desenvolvimento de moldes de injeção plástica, também ocorrem as fases de projeto conceitual e detalhado. Em empresas de alta série, com produtos especiais, as máquinas produtivas são Exemplos de projetos de especialmente projetadas e, muitas vezes, elas são determinantes para o custo de famáquinas bricação do produto. Esse é o caso de máquinas para a produção de rotores e bobinas de motores elétricos. O desenvolvimento de uma máquina desse tipo também segue um processo estruturado, como o apresentado neste livro. Em alguns setores, já existem fabricantes de equipamentos especiais, ficando a cargo do cliente a tarefa de integrá-los ao seu processo produtivo. A seqüência de passos desta tarefa de projetar recursos pode ser tão ou mais 59 Projeto da fábrica complexa que o próprio desenvolvimento do produto, quando se tratar do projeto de uma nova fábrica. Imagine um produto simples, como um lápis, e a complexidade do seu desenvolvimento comparada com a complexidade do desenvolvimento de uma fábrica para produzi-lo. Apesar de muito relevantes, não serão descritos neste livro os passos para se projetar uma fábrica. Veja uma visão geral sobre projeto de fábrica no Quadro 8.22. Quadro 8.22

Projeto de Fábrica

Dadas as condições atuais, necessárias à competitividade, um projeto de fábrica deve se pautar pela concepção de uma fábrica flexível, que maximize opções de produção e variedade de produtos, a custos e qualidade compatíveis com os padrões do mercado. Traduzindo isso em termos de tamanho de lotes, organização de fluxos e programação, uma fábrica flexível deve buscar: lotes de produção pequenos, o que permite agilidade de reação a mudanças do mercado e maior diversidade de produtos; organizar-se em torno dos produtos, por meio de células ou equipes de trabalho, permitindo a proximidade entre as pessoas e o comprometimento com o que efetivamente agrega valor à empresa; e utilizar uma programação descentralizada, na qual o máximo possível de decisões são tomadas no chão de fábrica pelas pessoas que efetivamente agregam valor ao trabalho. Em um projeto de fábrica flexível — a partir das escolhas em relação aos processos produtivos ou de manufatura que coexistirão, equilibrando características de volume/variedade dos produtos a serem fabricados — pode-se determinar quais os melhores arranjos físicos que se deve projetar para a fábrica, normalmente eles são derivados da combinação de quatro tipos básicos de arranjos: o posicional; o por processo; o celular ou o por produto. Busca-se um projeto de arranjo físico que tente otimizar custo e flexibilidade da produção. Ao final dele, devem estar suficientemente detalhados a localização física de todo o maquinário e os fluxos de materiais e pessoas, além das operações que podem ser executadas por esses recursos. Um projeto de fábrica consistente permite que as decisões dos processos de negócio, em particular do desenvolvimento de produtos, torne-se realidade na produção e seja compatível com seu ambiente competitivo. Para isso, deve haver a preocupação com certos capacitadores organizacionais, como sua adequação ambiental e inserção numa rede de empresas,

(continua) 58 59

Apesar de existirem empresas de serviço especializadas no desenvolvimento de recursos de fabricação. Utiliza-se aqui o termo clássico da engenharia da produção, mas hoje em dia essa atividade é mais conhecida como “Projeto de Sistemas Produtivos”, que é mais genérico.

362

PARTE 2

Quadro 8.22

O Modelo

Projeto de Fábrica (continuação)

além de adotar os princípios da moderna gestão da qualidade e da aprendizagem organizacional e gestão do conhecimento. O projeto deve considerar também os seus capacitadores tecnológicos. Um desses capacitadores é a tecnologia de fabricação. Atualmente, os processos primários de fabricação na manufatura discreta estão cada vez mais eficientes em produzir componentes com menores tolerâncias, aproximando-se das especificações finais. Já os processos secundários possuem disponível para o projeto de fábrica ferramentas com melhores geometrias e materiais, assim como máquinas com velocidades crescentes e CNCs evoluídos, possibilitando a fabricação em seqüências mais curtas e tempos menores, compatíveis com os princípios recomendados pela lean production (veja o Quadro 9.3). Outro capacitador é a automação industrial, que pode ser um importante diferencial em uma nova fábrica. No projeto, a preocupação deve ser com as possibilidades de automação no “chão de fábrica” e com os comandos e sistemas de monitoramento e comunicação possíveis para as máquinas-ferramentas. Os sistemas de transporte e armazenagem da nova fábrica também podem beneficiar-se da automação, via armazéns automáticos, robôs, monovias etc. Com os avanços da tecnologia de informação, um novo capacitador para o projeto da fábrica é a manufatura ou fábrica virtual (veja o Quadro 8.19), na qual são simulados os principais aspectos em projeto integrado. Dessas simulações, resultam previsões mais precisas do seu desempenho nas mais diversificadas situações. Esse capacitador permite que o projeto seja acelerado, analisando-se diversas possibilidades de configuração a baixo custo e com resultados confiáveis. O uso disseminado da TI (tecnologia de informação) é um capacitador cada vez mais presente nas fábricas modernas. O projeto dessas fábricas deve incluir a presença de sistemas, desde os mais tradicionais aos integrados à Internet e à intranets, como, por exemplo, sistemas para controle e acompanhamento de maquinário e os portais para educação e gestão do conhecimento corporativo, passando por sistemas ERP, sem deixar de levar em conta as ferramentas de e-business ligadas aos processos logísticos. Por fim, como síntese desses capacitadores, um projeto de fábrica, para seguir os princípios da lean production, deve considerar, principalmente:

• a definição de políticas de atendimento da demanda interna e externa (make-to-stock, make-to-order etc) e dos sistemas just-in-time e kanban de controle mais apropriados para os produtos, peças e matérias-primas;

• a definição de políticas para a análise de capacidade, com base nos recursos-gargalos, e de alguns aspectos físicos (layouts);

• o impacto do processo de lean production em outros setores da empresa. O Projeto de Fábrica influenciará significativamente todo o desempenho futuro do produto, no que diz respeito a sua capacidade de produção. De forma crítica, isso será percebido primeiro nas suas atividades de fabricação de protótipos, ferramental e no início da produção (start-up), que apresentam elevados custos e responsabilidades dentro do PDP, principalmente por estarem próximas da fase de produção e lançamento e, portanto, de grandes investimentos. Consulte mais sobre projeto de fábrica em BLACK, 1988.

Após projetarmos, precisamos obter os recursos especiais

Situação do exemplo do torno após a finalização do projeto dos recursos

Depois de serem projetados, os recursos precisam ser obtidos (comprados ou fabricados dentro da própria empresa). A obtenção dos recursos de fabricação é a tarefa inicial da fase de preparação da produção, que ocorre normalmente paralelamente à fase de projeto detalhado (veja o Tópico 9.4). Agora, apresentaremos no exemplo do torno (Figura 8.39), o projeto do recurso, assim como o plano de processo para sua fabricação e uma folha de instruções de uma das operações.

CAPÍTULO 8

Projeto Detalhado

8.8

363

Avaliar SSCs, configuração e documentação do produto e processo

Mais uma vez é bom observar na Figura 8.3 a dependência desta atividade na fase de projeto detalhado e também recordar os ciclos de detalhamento do Quadro 8.2. Estude também o Quadro 8.10 sobre o Gerenciamento dos Parâmetros Críticos (CPM), que está relacionado com as tarefas desta atividade. Figura 8.39

Esta atividade acontece simultaneamente com a criação e detalhamento dos SSCs

Estrutura do torno e seus documentos após a finalização do projeto de recursos.

Esta atividade faz parte do ciclo de otimização e acontece paralelamente à atividade de criação e detalhamento dos SSCs, sempre verificando se existe algum problema no item, na sua integração com o item-pai (componentes nos subsistemas, subsistemas nos sistemas e sistemas no produto) ou na sua aplicação. O CPM compreende a definição e implementação dos parâmetros críticos (veja o Quadro 8.10, sobre gerenciamento dos parâmetros críticos). A implementação preocupa-se com a validação dos parâmetros. Assim, essa atividade envolve tanto as avaliações gerais dos detalhamentos, como aquelas do CPM. Há diversos métodos de avaliação que podem ser utilizados (veja o Quadro sobre 8.23 métodos de avaliação dos sistemas, subsistemas e componentes). Ela também acontece de forma paralela à atividade de planejamento de processo, que pode exigir uma mudança nas especificações dos componentes.

364

PARTE 2

Quadro 8.23

O Modelo

Métodos de Avaliação dos Sistemas, Subsistemas e Componentes

A avaliação pode ocorrer de forma qualitativa, analítica ou experimental. Na Figura 8.40, apresenta-se uma visão geral dos métodos de avaliação. Muitos deles já são utilizados desde a macrofase anterior. A avaliação analítica utiliza equações e regras que representam a influência de certos atributos de um item sobre outro, ou representam o comportamento do produto e seus SSCs sob a ação de alguma grandeza física relacionada com a sua aplicação (por exemplo, os esforços a que um componente é submetido durante a sua aplicação). Figura 8.40

Visão geral dos métodos de avaliação dos SSCs e configuração.

A avaliação qualitativa é feita com base em critérios e experiência de várias pessoas. O time de desenvolvimento pode realizar, em conjunto, uma análise de falhas potenciais dos SSCs. Pode empregar também o método de clínicas (ou focus group, descrito no Capítulo 4), no qual um grupo de pessoas avalia características de protótipos não funcionais (mockups). A análise com base em realidade virtual pode avaliar tanto aspectos de estética do produto, quando realizada no início do PDP, 60 quanto de aplicação, quando utilizada após a configuração do produto. A avaliação experimental estuda o comportamento do produto ou SSC em modelos dos sistemas ou protótipos funcio61 nais. Os sistemas Computer Aided Tolerancing (CAT) são utilizados para a simulação de modelos virtuais (digitais). O planejamento de experimentos serve para levantar as respostas dos sistemas (produto, sistemas ou subsistemas) às entradas típicas de sua aplicação, avaliando também o seu comportamento perante perturbações advindas das condições de uso. Um método que utiliza o planejamento de experimentos é o de análise experimental de tolerâncias, usado para SSCs com parâmetros de natureza menos conhecida, e quando existe um inter-relacionamento entre eles. É também aplicado na atividade de homologação do processo na fase de preparação da produção. Leia mais sobre este assunto em CREVELING, 1997.

Esses métodos são aplicados às tarefas de avaliação descritas a seguir. Algumas tarefas são apropriadas somente para alguns casos de aplicação, conforme a sua natureza e a existência de um protótipo ou modelo para realização dos testes. Todas essas tarefas ocorrem dentro do contexto do CPM (veja a Figura 8.10 do Quadro 8.10, sobre gerenciamento dos parâmetros críticos). Em última análise, esta atividade de avaliação verifica se as especificações críticas resultam nos parâmetros críticos desejados, ou seja, se os requisitos dos clientes são atendidos, considerando-se as condições de aplicação do produto. As tarefas desta atividade são: n n n

60

61

Analisar falhas Avaliar tolerância analiticamente Planejar os testes (produto e processo)

Como exemplo de aplicação de realidade virtual após a configuração do produto, temos a simulação da manutenção de um equipamento, no qual um membro do time tenta desmontar partes do produto interagindo com o modelo virtual. Ele verifica se há espaço para acessar e manipular os itens retirados (veja o Quadro 8.20, sobre manufatura virtual). CAT é um tipo especial de sistema CAE, voltado para o estudo de tolerâncias.

CAPÍTULO 8

Projeto Detalhado

n n n n

365

Desenvolver modelos para testes (elaborar modelos matemáticos e/ou fabricar/receber o protótipo) Executar os testes Avaliar os resultados e planejar ações Avaliar consonância da documentação com as normas

A seguir, vamos descrever as tarefas. A análise de falhas pode ser realizada durante toda a fase de projeto detalhado Análise qualitativa e, às vezes, durante o projeto conceitual. É uma atividade qualitativa e segue o pro62 de falhas tocolo de um método consagrado, conhecido como FMEA, Análise dos Modos de Falha e seus Efeitos (veja o Quadro 8.24). Nesta tarefa, o time aplica o método FMEA para analisar, em grupo, os detalhamentos dos SSCs críticos e prever possíveis falhas, muito antes de construir os protótipos. Os detalhamentos dos SSCs são realizados por pessoas, individualmente. As pessoas do time de desenvolvimento possuem um conhecimento multifuncional, pois, quando pessoas com diferentes pontos de vista e experiências analisam o que uma pessoa fez sozinha, podem ser evidenciadas falhas em potencial, que passaram desapercebidas pelo indivíduo. Como neste método também se prevê ações corretivas e formas de medição dessas falhas, ele já fornece subsídios para a atividade de otimização dos SSCs. O maior ganho desta tarefa está na prevenção de falhas, que podem ser causadas por problemas nas especificações detalhadas dos SSCs. Por esse motivo, esta tarefa ocorre depois da atividade de detalhamento dos SSCs, na fase do projeto detalhado. Algumas empresas utilizam o FMEA na fase de projeto conceitual, para prever as falhas com maior antecedência ainda. O problema deste tipo de aplicação está na falta da documentação detalhada naquela fase, ou seja, pode-se prever algumas falhas na fase de projeto conceitual, mas o detalhamento dos SSCs pode conter novas falhas potenciais. Por exemplo, a especificação de uma tolerância da rugosidade de uma haste de um amortecedor de automóvel é crítica para evitar que o retentor se desgaste e, com isso, o óleo hidráulico do amortecedor vaze. Só se consegue detectar se a tolerância da rugosidade está dentro de uma faixa aceitável, após a especificação da tolerância, ou seja, após o detalhamento do desenho da haste. Não se conseguiria detectar esse potencial de falha no momento da realização do projeto conceitual. Quadro 8.24

Failure Mode and Effect Analysis (FMEA)

O método de Análise dos Modos de Falha e seus Efeitos, conhecido como FMEA, é uma ferramenta que busca, em princípio, evitar falhas no projeto do produto ou do processo, por meio da análise das falhas potenciais e propostas de ações de melhoria. Sua aplicação visa detectar falhas antes que se produza um protótipo para ensaios ou cada componente de um produto. Assim, diminuem as chances do produto ou processo falhar, ou seja, estamos buscando aumentar a sua confiabilidade. Apesar de ter sido desenvolvida para o projeto de novos produtos e processos, a FMEA, pela sua grande utilidade, passou a ser aplicada de diversas maneiras. Assim, ela é utilizada para diminuir as falhas de produtos e processos existentes e a probabilidade de falhas em processos administrativos. A análise consiste basicamente na formação de um grupo de pessoas que identificam, para o produto/processo em questão, suas funções, os tipos de falhas que podem ocorrer, os efeitos e as possíveis causas desta falha. Em seguida, são avaliados os riscos de cada causa de falha por meio de índices e, com base nesta avaliação, são tomadas as ações necessárias para diminuir estes riscos, aumentando a confiabilidade do produto/processo. A Figura 8.41 mostra a relação entre esses elementos citados, que serão detalhados a seguir.

Etapas para a aplicação Etapa 1: Planejamento Esta etapa é realizada pelo responsável pela aplicação da metodologia e compreende:

(continua) 62

FMEA: Failure Mode and Effect Analysis.

366

PARTE 2

Quadro 8.24

O Modelo

Failure Mode and Effect Analysis (FMEA) (continuação)

• a descrição dos objetivos e abrangência da análise, em que se identifica qual(ais) produto(s)/processo(s) será(ão) analisado(s); • a formação dos grupos de trabalho, em que se definem os integrantes do grupo, que deve ser preferencialmente pequeno (entre quatro a seis pessoas) e multidisciplinar (contando com pessoas de diversas áreas, como as de qualidade, desenvolvimento e produção);

• o planejamento das reuniões, que devem ser agendadas com antecedência e com o consentimento de todos os participantes para evitar paralisações. Figura 8.41

Visão estrutural das informações da FMEA.

Etapa 2. Análise de Falhas em Potencial Esta etapa é realizada pelo grupo de trabalho que discute e preenche o formulário FMEA (Figura 8.42) de acordo com os passos que se seguem:

• • • • •

funções e característica do produto/processo (veja a Figura 8.41); tipo(s) de falha(s) potencial(is) para cada função (modo); efeito(s) do tipo de falha (o que o cliente sente); causa(s) possível(eis) da falha (origem da falha, problema que deve ser resolvido);

controles atuais de verificação. Etapa 3. Avaliação dos Riscos Nesta etapa, são definidos para cada causa de falha, de acordo com critérios previamente definidos, os seguintes índices:

• de severidade (S): mede quão severo é o efeito daquela falha para o cliente; • de ocorrência (O): mede a probabilidade de ocorrência da causa; • de detecção (D): mede a probabilidade dos meios de avaliações atuais detectarem a causa da falha. Depois, são calculados os coeficientes de Prioridade de Risco (R), por meio da multiplicação dos três índices citados anteriormente. Observações importantes: quando o grupo estiver avaliando um índice, os demais não podem ser levados em conta, ou seja, a avaliação de cada índice é independente. Por exemplo, se estamos avaliando o índice de severidade de uma determinada causa, cujo efeito é significativo, não podemos colocar um valor mais baixo para este índice somente porque a probabilidade de detecção seja alta. No caso de FMEA de processo, pode-se utilizar os índices de capabilidade da máquina (Cpk), para se determinar o índice de ocorrência.

(continua)

CAPÍTULO 8

Projeto Detalhado

Quadro 8.24

367

Failure Mode and Effect Analysis (FMEA) (continuação)

Etapa 4. Melhoria Nesta fase, o grupo, utilizando conhecimentos, criatividade e até mesmo outras técnicas como brainstorming, lista todas as ações que podem ser realizadas para diminuir os riscos. Estas medidas podem ser:

• • • • •

medidas de prevenção total ao tipo de falha; medidas de prevenção total de uma causa de falha; medidas que dificultam a ocorrência de falhas; medidas que limitem o efeito do tipo de falha;

medidas que aumentam a probabilidade de detecção do tipo ou da causa de falha; Essas medidas são analisadas em relação a sua viabilidade, sendo então definidas as que serão implantadas. O próprio formulário FMEA é uma forma de fazer o controle do resultado dessas medidas, utilizando-se suas colunas, nas quais ficam registradas as medidas recomendadas pelo grupo, nome do responsável e prazo, medidas realmente tomadas e a nova avaliação dos riscos.

Continuidade de aplicação do FMEA O formulário FMEA é um documento “vivo”, ou seja, uma vez realizada a análise para um produto/processo qualquer, ela deve ser revisada sempre que ocorrerem alterações neste produto/processo específico. Além disso, mesmo que não haja alterações, deve-se regularmente revisar a análise, confrontando-se as falhas potenciais, imaginadas pelo grupo, com as que realmente vêem ocorrendo no dia-a-dia do processo e uso do produto, de forma a permitir a incorporação de falhas imprevistas, bem como a reavaliação, com base em dados objetivos, das falhas já previstas pelo grupo. Figura 8.42

Formulário de FMEA.

A primeira aplicação do FMEA é trabalhosa e, normalmente, o grupo fica desanimado. Porém, quando um novo FMEA para um item semelhante tiver de ser desenvolvido, deve-se reutilizar o FMEA anterior como referência. Ele começa a ser tratado como se fosse um catálogo de falhas em potencial. O grupo, nesses casos, repassa as falhas listadas no passado; verifica se elas ainda são pertinentes e concentra-se na definição de novas falhas. O ganho, nesses casos, é excepcional.

Importância A metodologia FMEA é importante porque pode proporcionar para a empresa:

• uma forma sistemática de catalogar informações sobre as falhas dos produtos/processos;

(continua)

368

PARTE 2

Quadro 8.24

• • • •

O Modelo

Failure Mode and Effect Analysis (FMEA) (continuação)

melhor conhecimento dos problemas nos produtos/processos; ações de melhoria no projeto do produto/processo, baseadas em dados e devidamente monitoradas (melhoria contínua); diminuição de custos por meio da prevenção de ocorrência de falhas; o benefício de incorporar, dentro da organização, a atitude de prevenção de falhas, de cooperação e trabalho em equipe e a preocupação com a satisfação dos clientes.

Automação da obtenção da documentação Atualmente, existem sistemas que dão suporte inteligente à confecção do FMEA. Eles podem armazenar padrões de falhas e ações para eliminá-las, ou controles para detectá-las. A edição toma como referência textos-padrão parametrizados. Seu uso aumenta ainda mais a eficácia da obtenção do FMEA. Leia mais sobre este assunto em OLIVEIRA, 1997.

A avaliação analítica de tolerâncias está inserida no contexto do gerenciamento dos parâmetros críticos. Em outras palavras, uma das maneiras de verificar os parâmetros críticos é por meio da análise de tolerância. Com ela, podemos calcular a contribuição das tolerâncias dos itens-filho (por exemplo, um componente) nas tolerâncias do item-pai (por exemplo, um subsistema). Ela é utilizada paralelamente à especificação de tolerância, que ocorre na confecção dos desenhos, visando obter os valores das especificações críticas. Isso fica claro quando tratamos de um parâmetro dimensional, em componentes Exemplo de análise de mecânicos. As dimensões de um subsistema resultam das tolerâncias dos componentes, tolerâncias dimensional como mostra o exemplo da Figura 8.43 (é o mesmo subsistema da Figura 8.17). Avaliação analítica de tolerâncias

Figura 8.43

Exemplo de cadeia dimensional.

As dimensões e tolerâncias de todos os componentes marcados na figura contribuem para a folga, como mostra a Tabela 8.1.

CAPÍTULO 8

Projeto Detalhado

Tabela 8.1

369

Dimensões e Tolerâncias dos Componentes do Subsistema da Figura 8.43.

Dim.

Descrição

Valor (mm)

.+/- tol.(mm)

tol**2

A1

Largura do rolamento direito

-20,17

0,02

0,0004

A2

Largura do anel espaçador direito

-36,12

0,04

0,0016

A3

Largura da engrenagem

-27,34

0,06

0,0036

A4

Largura do ressalto do eixo

-56,35

0,08

0,0064

A5

Largura do rolamento esquerdo

-22,56

0,02

0,0004

A6

Largura do anel espaçador esquerdo

-7,2

0,03

0,0009

A7

Ressalto da tampa esquerda

-5,43

0,15

0,0225

A8

Largura externa da carcaça

158,62

0,12

0,0144

A9

Ressalto da tampa direita

17,24

0,15

0,0225

Folga resultante e sua tolerância

0,69

0,67

0,27

A folga resultante é de 0,69 mm +/- 0,67, ou seja, a folga máxima é de 1,36 e a mínima, de 0,02. Isso porque usamos o método conhecido como método de intercambilidade total, sem qualquer consideração estatística. Utilizando-se conceitos de estatística, considerando-se que todos os componentes seguem uma distribuição normal e que a porcentagem de folgas fora da especificação é de 0,27% (3 sigma), a tolerância resultante é de +/0,27. Portanto, a variabilidade cai de 1,34mm para 0,54mm. O exemplo apresentado é simples, pois trata de dimensões físicas em componentes mecânicos. Fica um pouco mais complicado analisar as dimensões no espaço, por exemplo, calcular a folga de fechamento de uma porta de automóvel. Existem, porém, sistemas CAT (Computer Aided Tolerancing) que permitem que essas cadeias dimensionais possam ser calculadas e a tolerância do parâmetro crítico do subsistema, calculada. Esses sistemas consideram, no caso do cálculo do acúmulo de tolerâncias dimensionais em componentes mecânicos, a 63 relação entre as tolerâncias dimensionais e as tolerâncias geométricas, conhecida como G&DT. A utilização desses sistemas já incorpora as tarefas da atividade de otimização, descritas no próximo tópico. Esses sistemas possuem o modelo geométrico do subsistema e aplica o método Monte Carlo.64 A avaliação experimental de tolerâncias é aplicada quando tratamos de outros Avaliação experimental parâmetros físicos e sua interdependência, como amperagem, voltagem etc. A anáde tolerâncias lise de tolerância fica mais complicada, pois são poucos os métodos analíticos existentes. Muitas vezes, deve-se desenvolver equações específicas para prever os comportamentos e os efeitos da variabilidade dos itens de uma cadeia. Nesses casos, também é mais difícil determinar quais são os componentes da cadeia que influenciam no parâmetro critico do item-pai. O mesmo acontece com novas tecnologias, cujos parâmetros críticos são grandezas de natureza mais complexa. A avaliação experimental não se constitui em uma tarefa, mas as três tarefas subseqüentes estão relacionadas com a execução de testes em protótipos ou modelos: n n n

63 64

planejar os testes (produto e processo); desenvolver modelos para testes (elaborar modelos matemáticos e/ou fabricar/receber o protótipo); executar os testes, avaliar os resultados e planejar as ações.

Consulte o Quadro 8.12, sobre G&DT. O método Monte Carlo consiste em simular um experimento com a finalidade de determinar propriedades probabilísticas de uma população, a partir de uma nova amostragem aleatória dos componentes dessa população. Ele é utilizado, no caso de análise de tolerâncias, na geração das variações aleatórias das tolerâncias dos componentes, segundo distribuições estatísticas, selecionadas para cada componente, e no cálculo da tolerância resultante do parâmetro crítico.

370

PARTE 2

O Modelo

Primeiro, deve-se definir se serão feitos testes em protótipos virtuais ou reais. Planejar testes Os protótipos virtuais, como os mock up eletrônico, já vêm sendo utilizados desde as fases anteriores. Existem atualmente sistemas computacionais que permitem representar SSCs mais complexos de forma virtual e fazer simulações de diversos tipos (veja o Quadro 8.20 sobre manufatura virtual e o Quadro 8.11 sobre sistemas CAD/CAE). Alguns testes desse tipo também são feitos nas fases anteriores com base em protótipos não funcionais, obtidos via prototipagem rápida (veja o Quadro 8.27 “O uso de protótipos e modelos de produtos”). Os ensaios com protótipos funcionais são realizados na fase de projeto detalhado, empregado-se SSCs similares aos do produto final. No planejamento dos testes devem ser tratadas as questões de logística para adquirir os SSCs e questões técnicas do ensaio. A logística deve garantir que todos os SSCs estejam disponíveis no momento do ensaio. Os fornecedores devem ser contatatos e os SSCs, solicitados, ou mesmo os modelos que possam ser utilizados. As questões técnicas estão relacionadas com a obtenção do protótipo ou modelo (próxima tarefa) e com a escolha dos testes que serão realizados, utilizando-se conceitos da área de Planejamento de Experimentos (DOE — Design of Experiments — veja o Quadro 8.25). Observa-se que o DOE envolve não somente o planejamento dos experimentos, como também o tratamento dos dados resultantes dos ensaios. Quadro 8.25

Planejamento de Experimentos (DOE — Design Of Experiments)

Imagine que precisemos testar um sistema com três entradas que determinam o seu comportamento. Na área de DOE essas entradas são chamadas de fatores. Os valores desses fatores possuem uma tolerância, ou seja, eles variam dentro de uma faixa. Se a variação desses fatores for contínua e quisermos testar o comportamento do sistema para todas as combinações, faríamos uma quantidade infinita de testes. Se definirmos que os valores desses fatores variam, de forma incremental, em 10 níveis diferentes cada um, teremos que realizar mil testes, o que ainda é demasiado. O DOE é uma técnica utilizada para definir dados, sua quantidade e as condições de coletas durante um determinado experimento, buscando, basicamente, satisfazer dois grandes objetivos: maior precisão estatística na resposta e menor custo. A sua aplicação no desenvolvimento de novos produtos é muito importante, pois uma maior qualidade dos resultados dos testes pode levar a um projeto com desempenho superior, seja em relação as suas características funcionais ou a sua robustez. No entanto, deve ficar claro que esta ferramenta não substitui o conhecimento técnico do especialista da empresa sobre o assunto, tampouco é uma “receita de bolo”, contendo as informações de como realizar um planejamento. O domínio do problema é de fundamental importância. O conhecimento do especialista sobre o problema, conjugado com a técnica (em casos especiais, somando-se ainda o auxílio de especialistas em planejamentos de experimentos), é que permitirá bons planejamentos de experimentos, ou seja, planejamentos mais rápidos (menos pontos), de menor custo e que possibilitem aos seus idealizadores, baseados em inferência estatística, a resposta a seus problemas. Apesar de novas, as principais técnicas de planejamento de experimentos já existiam e, potencialmente, poderiam estar sendo, sistematicamente, aplicadas na indústria há muitos anos. Porém, a maioria dessas técnicas requer uma quantidade exaustiva de cálculos, tornando fundamental o emprego dos recursos de informática. As ferramentas computacionais de análise estatística e soluções corporativas têm impulsionado a aplicação industrial do planejamento de experimentos e, cada vez mais, facilitam a realização das análises, manutenção e gerenciamento de dados. Nesse sentido, a tendência é que tais técnicas se aproximem mais das aplicações práticas e, portanto, sejam cada vez mais utilizadas. É preciso estar claro também que, em estatística, Planejamento de Experimentos designa toda a área de estudos que desenvolve técnicas de planejamento e análise de experimentos. Há, atualmente, um arsenal de técnicas, com vários níveis de sofisticação, e uma grande quantidade de livros sobre o assunto. As principais definições utilizadas em DOE são:

• Fatores: constituem-se em variáveis de controle ou entrada. • Níveis: correspondem às faixas de valores das variáveis de controle. • Variável resposta: parâmetro (críticos) de saída, resultante de uma variação dos fatores de entrada. Em seguida, apresenta-se uma seqüência genérica dos passos do DOE. 1. Selecionar as respostas do sistema que se pretende avaliar com o experimento. Compreende a definição dos parâmetros críticos dependentes de outros, que podem ser levantados, por exemplo, a partir da aplicação do QFD ou de outro método de definição.

(continua)

CAPÍTULO 8

Projeto Detalhado

Quadro 8.25

371

Planejamento de Experimentos (DOE — Design of Experiments) (continuação)

2. Selecionar os fatores que serão variados no experimento: em sistemas mais complexos (e, por isso, usa-se o DOE) não se tem certeza de quais são os fatores que influenciam a sua resposta. Dessa forma, as pessoas responsáveis do time devem conhecer a natureza do sistema para poder definir quais são esses fatores. 3. Selecionar e calibrar os sistemas de medição a serem utilizados no experimento. As variáveis a serem estudadas devem ser medidas com precisão para se ter certeza e confiança nos resultados dos experimentos. Para isso, deve-se utilizar o método da Análise dos Sistemas de Medição (conhecido como MSA – Measurement System Analysis), que é o mesmo método utilizado na preparação da produção, quando se aprovam as ferramentas de inspeção (veja o Quadro 9.1). Os instrumentos de medição estarão calibrados, quando as métricas do MSA estiverem dentro dos limites aceitáveis à realização do experimento. 4. Selecionar a matriz experimental com os valores dos fatores, que determina como eles devem ser variados e combinados para a realização do experimento. Precisamos decidir qual o modelo de planejamento que vamos utilizar, como variar os fatores, quantas interações devem ocorrer, quais os graus de liberdade e como vamos tratar os dados resultantes. Entre os modelos mais utilizados, existem: Tratamento em pares; Tratamento em Blocos; Quadrado Latino, Quadrado Greco-Latino, Quadrado Hiper-Greco-Latino e Experimentos Fatoriais. 5. Analisar os dados resultantes do experimento por meio de análise de variança (ANOVA — ANalysis Of VAriance), processo analítico que decompõe a contribuição de cada fator individualmente com relação à resposta total do experimento. Esse processo é capaz de detectar a contribuição e a interação entre fatores e erros no resultado final. 6. Determinar quais os fatores que contribuem para a resposta do sistema. Definir quais são os valores e a sensibilidade na resposta final do sistema. Leia mais sobre este assunto em CREVELING, 2003.

Quando estamos planejando os experimentos, e inclusive na fase de sua execução, algumas condições do meio ambiente de aplicação do produto podem fazer com que as respostas necessárias e aguardadas do produto, resultantes das entradas projetadas, desviem dos valores esperados (tolerância do parâmetro crítico). Isso acontece devido a fatores denominados ruídos, como temperatura, umidade, poeira, deterioração, interferência magnética etc. Taguchi65 desenvolveu um método conhecido como Projeto Robusto (RD — Robust Design) que visa avaliar a influência dos ruídos nos desvios de qualidade, que, em última análise, equivalem às variações não desejadas dos parâmetros críticos (veja o Quadro 8.26). No Projeto Robusto, procura-se desenvolver produtos que não sejam sensíveis à variação dos ruídos. Os experimentos dessa técnica utilizam os conceitos do planejamento de experimentos. Na verdade, no Projeto Robusto são utilizados experimentos fatoriais. O planejamento do modelo estatístico limita-se à seleção da matriz ortogonal, que define quais são os experimentos a serem realizados (veja o Quadro 8.26). Quadro 8.26

Projeto Robusto (RD — Robust Design)

Projeto Robusto, também conhecido como Método Taguchi, é uma abordagem da engenharia de qualidade off line, que busca aumentar a robustez dos produtos por meio da diminuição dos efeitos dos “ruídos” no seu desempenho (variação dos parâmetros críticos). Este método define a “função perda” do produto, que mostra quais foram os “prejuízos” em relação à qualidade, causados pelos ruídos. O método identifica os parâmetros ótimos de projeto, que minimizam ou mesmo eliminam as influências dos ruídos no desempenho do produto. Assim, em lugar da tendência tradicional de isolar o produto dos ruídos, o que pode ser de difícil execução e/ou encarecer o processo produtivo, o Método Taguchi procura realizar projetos que eliminem os efeitos dos ruídos. Pretende-se obter produtos robustos o suficiente para assegurar alta qualidade, a despeito de flutuações que venham a ocorrer no processo produtivo e no ambiente de uso do produto.

(continua) 65

Leia mais sobre este assunto em BERGAMO, 1997.

372

PARTE 2

Quadro 8.26

O Modelo

Projeto Robusto (RD — Robust Design) (continuação)

Exemplo de Projeto Robusto são impressoras que trabalham sempre com a mesma qualidade de impressão, não importando o tipo de papel usado, a umidade do ambiente e as variações de voltagem. O trabalho do Dr. Taguchi, além de ser uma nova abordagem para a área de qualidade, serviu também para consolidar o conceito de Projeto Robusto, ou seja, projetar produtos que minimizem os fatores ambientais. Assim, o Projeto Robusto consolidou-se como o conceito/filosofia de projetar produtos, minimizando a influência dos ruídos, o que pode ser alcançado com diversas outras técnicas ou mesmo a partir da experiência e bom senso dos projetistas. O Método Taguchi engloba o conjunto de técnicas propostas para atingir o objetivo de um Projeto Robusto, que inclui a otimização pela função-perda e projetos de experimentos fatoriais com matrizes ortogonais (um subconjunto do planejamento de experimentos). É preciso frisar também que o Método Taguchi foi desenvolvido com a preocupação de facilitar sua aplicação prática, o que lhe rendeu grande fama entre as empresas e profissionais, principalmente japoneses, e, por outro lado, muitas críticas de especialistas em estatística. Há um conjunto grande de obras que apresentam as limitações dos procedimentos adotados por Taguchi, visando a diminuição da complexidade do método, principalmente quanto à otimização. E, somado a esses problemas de ordem técnica, existe também outra barreira para a sua adoção, que é a necessidade de uma quantidade de testes que, para produtos complexos ou mais caros, pode se tornar inviável. Ruídos ou fatores de perturbação causam a variabilidade da função do produto. Tais ruídos podem ser enquadrados em três tipos: 1. Ruídos externos: decorrem tanto das condições de utilização do produto quanto do ambiente em que ele é utilizado, como a falha na sua operação, umidade do ar, tensão da rede de energia, poeira, temperatura ambiente etc. 2. Ruídos internos ou ruídos degenerativos: estão ligados às próprias características do produto, do processo ou serviço que o produto sofre antes de chegar ao mercado, e procuram estabelecer valores (ou níveis) dos fatores (ou parâmetros) que têm influência no valor estabelecido para a saída (ou resposta) do sistema, com baixa variação em torno desse valor. 3. Variações na produção: corresponde à variabilidade entre as unidades do produto manufaturado sob as mesmas especificações. Os passos básicos do Método Taguchi são: 1. Identificar os fatores (ruído e fatores principais do ambiente e processo de fabricação) e os parâmetros de produto (ou processo) relevantes. Para cada um deles, são previstas as possíveis influências e interações com os demais. Esta é uma etapa importante, pois o fato de desconsiderar um determinado fator ou parâmetro pode distorcer ou impedir a obtenção da função-perda, a qual guiará os projetistas em direção ao projeto mais robusto. 2. Planejar e conduzir os experimentos. Depois de finalizar o projeto e protótipos do produto realiza-se a etapa de planejamento da coleta de dados experimentais. Esses dados permitirão a construção da função-perda e da relação sinal/ruído. Isso é realizado utilizando-se conceitos de planejamento de experimentos (veja o Quadro 8.25), em especial os planejamentos fatoriais. Deve-se iniciar pela escolha do tipo de planejamento, ou seja, pela escolha da matriz ortogonal que melhor se aplica ao problema. A escolha das matrizes depende principalmente do número de fatores e da quantidade de corridas (ou seja, de casos de experimentos) que poderiam ser realizados conforme a disponibilidade de tempo e custo. Em seguida, são especificados valores para os diferentes níveis dos parâmetros. Com esses dados, basta escolher aleatoriamente as corridas e programar a realização dos ensaios. Ao final deste trabalho, com o plano de testes “em mãos”, são realizados os ensaios e as coletas de dados, respeitando-se os cuidados exigidos pelo tipo de teste específico. 3. Predizer os níveis ótimos dos parâmetros, procurando otimizá-los e considerando-se a menor relação sinal/ruído. Isso significa obter um modelo estatístico dessa relação com os dados coletados no experimento, e aplicar, neste modelo, técnicas de otimização para encontrar os valores dos parâmetros ótimos dos produtos. Ao final desta etapa, tem-se um conjunto de valores de parâmetros (ou características) do produto que tornam seu desempenho robusto e estável em relação às características ambientais e às variações do processo. 4. Validar os resultados, pois os níveis ótimos dos parâmetros obtidos anteriormente são fruto de um modelo estatístico, e, portanto, uma aproximação da realidade. Isso é feito conduzindo-se um experimento com um protótipo, cujos parâmetros são ajustados conforme os valores ótimos obtidos. Os resultados deste experimento devem coincidir com aqueles encontrados por meio do modelo, dentro, é claro, da devida margem de segurança. Caso isso ocorra, significa que o modelo obtido é confiável e, dessa forma, pode-se aprovar esses parâmetros como especificações para o projeto. Ao contrário, se ocorrer uma diferença significativa entre os modelos, deve-se reavaliar os resultados dos experimentos e seu planejamento. Nesses casos, provavelmente algum parâmetro do produto ou fator ruído deixou de ser considerado ou ocorreu algum problema durante a condução dos experimentos, entre outras possíveis distorções. Leia mais sobre este assunto em ROSS, 1995.

CAPÍTULO 8

Projeto Detalhado

Desenvolver modelos para testes

Quadro 8.27

373

No planejamento dos experimentos, a maior parte das informações e especificações necessárias foi obtida. Os modelos teóricos estatísticos de avaliação já foram selecionados. Esta tarefa compreende a confecção dos modelos físicos (protótipos), virtuais e matemáticos, necessários para a realização de ensaios e simulações na tarefa de execução (veja o Quadro 8.27).

O Uso de Protótipos e Modelos de Produtos (Componentes e Ferramentas)

O uso de protótipos para avaliação de produtos é uma prática que já vem sendo empregada há muitos séculos. A técnica mais antiga que se conhece é a construção de modelos icônicos, muito utilizada na arquitetura, cujo objetivo é representar a geometria do produto em escalas diferentes das do produto final. Exemplos de modelos icônicos incluem mockups, modelos reduzidos e ampliados, desenhos 2D e 3D em Computer Aided Design (CAD ), mapas e, até mesmo, os desenhos para a fabricação do produto. Outra técnica de modelagem de produtos resultam nos chamados modelos analógicos, definidos como representações do produto ou de suas partes, que obedecem os mesmos princípios e leis do produto original, sendo usados para avaliar a operação do produto. Nessa categoria, estão incluídos os simuladores de vôo, modelos de estruturas, modelos de embarcações para teste etc. Os modelos matemáticos utilizam fórmulas matemáticas para representar o produto ou suas partes, e podem ser vistos como representações abstratas do problema original. Dentro dessa categoria encontramos também os modelos computacionais, os quais usam o embasamento físico e matemático que regem o funcionamento do produto para simular as condições reais de uso do produto. Em engenharia, os modelos computacionais são usualmente manipulados por sistemas Computer Aided Engineering (CAE ). Logicamente, não podemos esquecer o emprego de protótipos funcionais do produto. Usualmente, eles são fabricados com base em desenhos para a fabricação do produto em seus estágios finais de elaboração e com recursos de ferramentaria (mais adequados à produção em pequenas quantidades), os protótipos funcionais são empregados para validar e/ou homologar o produto, ou partes dele, em fases mais tardias de seu desenvolvimento. Por meio do protótipo funcional, pode-se avaliar o correto funcionamento do produto, sua montabilidade, validar restrições e premissas, avaliar seu desempenho e verificar sua concordância com as especificações. Uma das grandes promessas de avanços em desenvolvimento de produtos é a prototipagem rápida de componentes e ferramentas. Por meio dela, é possível realizar avaliações dimensionais do produto em etapas prévias de seu processo de desenvolvimento, reduzindo tempo de desenvolvimento (time-to-market) e atendendo à crescente demanda para a construção de protótipos físicos de maneira rápida e precisa. Para a produção rápida de ferramentas (técnica conhecida como rapid tooling), já existem várias tecnologias, que variam desde a utilização de protótipos como padrão para a produção de moldes em silicone até a produção direta de moldes, utilizando a própria máquina de prototipagem por meio de processos de sinterização ou deposição de metais.

Normalmente, a confecção de protótipos é realizada montando-se componentes com características semelhantes à versão final, que ainda não foram produzidos pelo equipamento de fabricação, pois ainda não estão disponíveis. Existe um trabalho de logística intenso para obter esses SSCs, também se deve equilibrar a qualidade e o custo dos itens do protótipo. O ideal seria obter SSCs idênticos aos do produto na sua versão final, mas durante a fase de projeto detalhado ficaria muito caro obtê-los, pois as mudanças prováveis, advindas da atividade de otimização, encareceriam muito o processo de desenvolvimento. A tarefa de execução compreende a realização dos testes de acordo com o que Execução foi planejado. Após “rodar” alguns experimentos, pode-se verificar se as respostas estão dentro dos valores dos parâmetros críticos desejados e também quais são as especificações críticas que devem ser controladas, já que, nos experimentos, são percebidos os fatores que contribuem para a variação do parâmetro crítico. Além disso, na execução, podem ser levantados os valores de especificações que eliminam os efeitos dos ruídos.

374

PARTE 2

O Modelo

Por fim, deve-se verificar se as especificações finais do projeto detalhado (desenhos, instruções, planos de processo etc.) atendem a normas específicas, que possam ser necessárias no ramo em que se atua, ou mesmo o motivo pelo qual a empresa possui um sistema normalizado para a criação da documentação. Pode haver mercados específicos, como no caso de desenvolvimento de produtos de uso medicinal (aparelhos para avaliação de pacientes), que possuem regulamentações especiais a serem seguidas pelo processo de desenvolvimento e pela documentação. Em outros mercados, como o da indústria automotiva, existem algumas montadoras que exigem uma documentação especial, a ser submetida para a aprovação do fornecimento (veja atividade descrita no Tópico 8.14). Os documentos atendem a normas?

8.9

Otimizar produto e processo

Como indicado pela linha tracejada na figura de visão geral desta fase de projeto detalhado (Figura 8.3), a otimização pode ocorrer ou não. Normalmente, quando a avaliação dos SSCs levanta um potencial de otimização, ou mesmo quando surgem problemas na análise de tolerâncias, deve-se ajustar os valores das tolerâncias dos componentes para se atingir as metas definidas para os subsistemas e sistemas. Para esta atividade, também há diversos métodos associados à estratégia escolhida no detalhamento dos SSCs. Pode-se ajustar os valores da tolerância com base na análise de sensibilidade ou Exemplos de métodos por meio de otimizações estruturais e funcionais dos SSCs. No caso analítico, são 66 de otimização realizadas simulações segundo o método de Monte Carlo, em que as tolerâncias dos componentes são variadas conforme uma distribuição estatística. Esta otimização pode contar com o apoio de sistemas Computer Aided Tolerancing (CAT ), citados na atividade anterior. As faixas das tolerâncias das especificações críticas são variadas, assim como os modelos estatísticos, até que a tolerância do parâmetro crítico esteja entre os valores desejados. Após a otimização, deve-se atualizar as especificações dos SSCs e sua documentação. Na otimização da cadeia dimensional, podem ser tomadas as seguintes medidas: Nem sempre ocorre a otimização

n

n

n

n

n n n

Verificar se não existe uma cadeia mais curta. Pode ser que o equacionamento empregado esteja repetindo os itens, principalmente em cadeias complexas; Verificar se tolerância do subsistema é necessária. Retornar para o processo de CPM e novamente validar o valor do parâmetro crítico; Eliminar componentes. Esta é uma das medidas mais adotadas, principalmente quando se aplica o mé67 todo DFA ou a análise de valores na criação e, agora, na otimização do produto. Quando um componente substitui vários outros que contribuíam para a tolerância do parâmetro crítico, somente a sua tolerância entra no cálculo no lugar das tolerâncias dos itens substituídos; Diminuir a tolerância de componentes (se possível daquele mais significativo), otimizar o processo e colocá-lo em controle estatístico; Verificar as distribuições e probabilidades de erro; Adotar outro método de montagem para o mesmo projeto (ajustagem, montagem seletiva); Modificar a disposição entre os componentes e o processo de montagem correspondente.

Os métodos, citados na atividade anterior de avaliação, já contêm tarefas de otimização próprias que são aplicadas na sua execução. Por exemplo, durante os experimentos do método Taguchi de Projeto Robusto (veja

66 67

Leia mais sobre o método Monte Carlo na nota 50. Veja Quadro 7.8 sobre DFx, que contém o Design For Assembly (DFA ).

CAPÍTULO 8

Projeto Detalhado

375

o Quadro 8.26), os valores dos fatores são ajustados até que o sistema se torne insensível aos ruídos. Essa tarefa já é de otimização e acontece simultaneamente à execução do experimento. A otimização tem também por objetivo realizar as alterações necessárias que Otimização ainda realiza as constam na lista de ações corretivas e nos resultados dos testes dos protótipos. Por ações corretivas e pode exemplo, a aplicação do método FMEA pode resultar em uma lista de ações (veja o aplicar novamente alguns Quadro 8.24), que devem ser realizadas nesta atividade de otimização, visando elimétodos do projeto minar as falhas potenciais levantadas. conceitual Pode-se prever ainda a reaplicação de métodos DFx e as ferramentas utilizadas na fase de projeto conceitual, pois agora estão definidas as características finais dos SSCs. O momento é propício para isso, pois se tem os resultados de testes e todas as informações do produto ficam congeladas após o detalhamento. Todo esse ciclo acontece para aumentar a confiabilidade do produto e também diminuir a necessidade de manutenção, após a sua colocação no mercado. Nesse contexto, podemos utilizar os conceitos de confiabilidade, mostrados no Quadro 8.28 sobre disponibilidade, confiabilidade e manutenibilidade. Deve-se empregar as ferramentas descritas até agora e o conceito de gestão dos parâmetros críticos e o de confiabilidade. Quadro 8.28

Disponibilidade, Confiabilidade e Manutenabilidade

A disponibilidade refere-se ao requisito de máximo tempo de operação disponível que se exige de um equipamento ou bem de consumo durável. Ela avalia, portanto, a capacidade ou aptidão de um bem que esteja operando satisfatoriamente ou pronto para ser colocado em operação quando solicitado. Partindo-se do pressuposto que um equipamento pode falhar e, portanto, entrar em estado de indisponibilidade, e que, conseqüentemente, será necessário um intervalo de tempo para a realização de atividades de manutenção, a disponibilidade passa a ser função da taxa de falhas do equipamento e do tempo necessário para a manutenção. A taxa de falhas está associada ao conceito de confiabilidade, e o tempo de manutenção, ao conceito de manutenibilidade. A formalização do conceito de disponibilidade passou pela formalização dos conceitos de confiabilidade e de manutenibilidade.

Confiabilidade A confiabilidade é a característica de um bem, expressa pela probabilidade de que ele realize uma função requerida, durante um certo intervalo de tempo e sob determinadas condições de uso para o qual foi concebido. Normalmente, é representada com base em parâmetros médios de número de falhas ou do intervalo de tempo entre falhas. Procura representar, portanto, a confiança no desempenho do produto. O conceito de confiabilidade se aplica tanto a sistemas complexos quanto, por exemplo, a um computador, automóvel ou aeronave, bem como para os componentes desses sistemas. A confiabilidade de um componente ou sistema depende diretamente dos princípios técnicos que estão sendo aplicados nele. Os equipamentos eletrônicos, por exemplo, são mais confiáveis que os eletromecânicos. Em relação ao conceito de confiabilidade, pode-se destacar três aspectos:

• desempenho adequado (sem falhas) de uma função especificada; • por um período de tempo; • sob condições especificadas de uso. O desempenho adequado não significa, necessariamente, que o equipamento deve funcionar segundo um esquema binário do tipo “funciona — não funciona”, uma vez que podem existir vários estados de funcionamento adequados, em maior ou menor grau. O período de tempo para medição da confiabilidade deve ser limitado, uma vez que o tempo de vida pode afetar significativamente as características do sistema que está sendo avaliado. Por último, é necessário destacar que o ambiente e as condições de operação interferem decisivamente no seu desempenho. Assim, para se conhecer a confiabilidade de um sistema, é necessário submetê-lo ao desempenho sob condições específicas, e medir seu tempo de funcionamento até que falhe. A formalização quantitativa da confiabilidade pode se apresentar de diversas formas. Todas elas, entretanto, têm um ponto em comum: o desempenho ao longo do tempo. Os principais parâmetros de quantificação da confiabilidade são: a) Tempo Médio Entre Falhas (TMEF). Refere-se ao tempo médio entre sucessivas falhas de um sistema reparável.

(continua)

376

PARTE 2

Quadro 8.28

O Modelo

Disponibilidade, Confiabilidade e Manutenabilidade (continuação)

b) Tempo Médio Até a Falha (TMAF). Refere-se ao tempo médio até a falha de um sistema não reparável ou até a primeira falha de um sistema reparável. c) Taxa de Falhas. Refere-se à quantidade de falhas por unidade de tempo. A partir do conhecimento do TMEF, é possível prever as falhas do produto e planejar as atividades de manutenção, desde que conhecido o tempo necessário de intervenção. Daí o surgimento do conceito de manutenibilidade.

Manutenabilidade O conceito de manutenabilidade se desenvolveu tendo em vista que, durante uma parcela considerável de tempo, um equipamento pode estar indisponível, seja por causa do seu estado de manutenção ou por estar esperando uma atividade de manutenção. A manutenabilidade está intuitivamente associada à noção de “facilidade de executar a manutenção” de um equipamento ou sistema. Seu objetivo é facilitar, agilizar e baratear a manutenção. Essa facilidade dependerá de fatores como: o projeto do sistema e sua acessibilidade para reparos; os recursos para diagnóstico das falhas; os recursos disponíveis para a reparação; a disponibilidade e acesso a materiais de reposição; o índice de falhas etc. Ela pode ser definida como uma característica inerente ao projeto e instalação de um equipamento, que se relaciona com a facilidade, economia, segurança e precisão no desempenho das ações de manutenção. Está relacionada com os tempos de manutenção, com as características de receber manutenção, próprias do projeto, e com os custos de manutenção. Assim, enquanto a manutenabilidade é a aptidão que um equipamento tem para receber manutenção, essa última, por sua vez, constitui-se em uma série de ações a serem tomadas para retornar, ou manter, um determinado equipamento ao estado operacional. A quantificação da manutenabilidade requer a definição de dois tipos de parâmetros: um temporal, que expresse o período durante o qual as condições de operação devem ser restabelecidas, e um probabilístico que represente a probabilidade de atingir esse parâmetro temporal. A manutenabilidade pode ser vista então como a probabilidade de um sistema ser colocado em condições de operação satisfatória, ou ser restaurado às condições de especificação, dentro de um certo período de tempo, desde que as ações de manutenção se realizem de acordo com procedimentos e recursos previstos. Esse valor é obtido a partir do Tempo Médio Para Reparar (TPMR). Existem outras medidas de tempo, além do TMPR, pelas quais os requisitos operacionais podem ser traduzidos, como:

• • • •

Tempo inativo médio: tempo médio durante o qual um sistema não está em condições de operar por qualquer razão. Tempo médio de manutenção corretiva ativa. Tempo médio de manutenção preventiva ativa.

Tempo máximo de manutenção. Leia mais sobre este assunto em BERGAMO, 1997.

Observe novamente na Figura 8.3 as dependências entre as atividades da fase de projeto detalhado apresentadas até agora. Recorde também os ciclos de detalhamento no Quadro 8.1. Conforme a complexidade do produto e, conseqüentemente, do seu projeto de desenvolvimento, a fase de detalhamento torna-se muito longa. Podem ser realizados, nesses casos, gates técnicos intermediários, conforme discutido no Tópico 2.7. Após a otimização do produto e do processo, todos os SSCs, a BOM final do produto, a documentação, os planos de processo e seus detalhamentos, os projetos dos recursos, enfim a especificação final do produto estarão terminados. Esse foi um ciclo que envolveu as atividades apresentadas até agora. A partir deste ponto, serão realizadas as atividades de: Ciclo de otimização finalizado

n n n

Criar material de suporte do produto Projetar embalagem Planejar o término da vida do produto

CAPÍTULO 8

Projeto Detalhado

377

Depois dessas atividades, quando o produto final é testado e homologado, acontece a finalização de mais um ciclo.

8.10 Criar material de suporte do produto As tarefas desta atividade são: n n n

Criar manual de operação do produto Criar material de treinamento Criar manual de descontinuidade do produto

A primeira tarefa compreende a elaboração do material de treinamento de pessoal na instalação, transporte, assistência técnica e outras atividades que envolvem o aprendizado em relação ao produto. É criado também o manual específico para a operação do produto, contendo regulagens, ajustes, capacidades, limites de funcionamento, cuidados a serem tomados e outros. A tarefa seguinte produz um manual com instruções para o seu descarte. Outros materiais, manuais e informações de apoio (como catálogo eletrônico de configuração) ou mesmo divulgação (na Internet, catálogos, propaganda, filmes, modelo de realidade virtual) são produzidos na fase de lançamento do produto pelas atividades de desenvolvimento dos processos de negócio de vendas, de distribui68 ção, de assistência técnica e de atendimento ao cliente. Somente as informações técnicas, relacionadas à descontinuidade do produto, são confeccionadas neste momento. O próprio plano de fim de vida prevê na fase de descontinuar o produto que serão tomadas decisões sobre a logística de descontinuidade do produto.

8.11 Projetar embalagem As tarefas desta atividade são: n n n n n n

Avaliar a distribuição do produto: transporte e entrega Definir as formas e as sinalizações das embalagens do produto Identificar os elementos críticos Adequar embalagem aos elementos críticos Projetar embalagem Planejar processo de embalagem

Geralmente, esse assunto não é devidamente abordado em metodologias e até mesmo em projetos nas empresas, mas assume significativa importância ao se verificar que qualquer produto é transportado, armazenado e comercializado em embalagens. Dessa forma, a primeira tarefa, nesta atividade, aborda a análise e definição da finalidade da embalagem, envolvendo classificações como: embalagem de consumo, embalagem expositora, embalagem de distribuição física, embalagem de transporte e exportação, embalagem industrial ou de movimentação, e embalagem de armazenagem. Uma vez feita a classificação, são então definidas e analisadas a movimentação requerida e a utilidade da embalagem, compreendendo embalagens retornáveis ou não retornáveis. A tarefa seguinte aborda a análise das funções da embalagem para definição das suas características. Com relação às funções, as embalagens podem ser de contenção, proteção, comunicação e interação com outros ma-

68

Veja a descrição dessas atividades no Capítulo 10 sobre a fase de lançamento do produto.

378

PARTE 2

O Modelo

teriais e ambientes. A análise de características — como preço, apresentação, resistência, materiais de fabricação etc. — fornece informações importantes para as tarefas posteriores. Em seguida, são identificados elementos críticos do produto em relação à embalagem, visando sua adequação e compatibilização. Para exemplificar alguns dos elementos críticos, pode-se citar: partes móveis, sensíveis, restrições de posição etc. Todas essas tarefas são caracterizadas pelo desenvolvimento contínuo, assim como pela realização de desenhos e outros procedimentos durante o andamento da atividade. Depois disso, têm-se os dados necessários para completar o projeto da embalagem e o seu processo de fabricação. Finalmente, deve-se realizar o projeto e processo de embalagem que precisa atender aos requisitos anteriormente levantados. Conforme a complexidade da embalagem, o seu processo de desenvolvimento é um subconjunto das atividades desta fase, envolvendo a criação, desenhos, especificação, configuração, processo de fabricação, recursos de produção das embalagens (neste caso, o produto). Ou seja, pode-se utilizar o modelo de referência deste livro como um recurso para a obtenção de embalagens e para ser discutido, no caso da obtenção de recursos de produção.

8.12 Planejar fim de vida de produto Durante o estudo do portfólio, o levantamento da projeção de vendas, a definição da estratégia de produto e o desdobramento dos requisitos, foram documentadas informações relacionadas com o fim de vida do produto, por exemplo: como descontinuar o produto, data prevista para a descontinuidade, expectativa do mercado etc. As possíveis estratégias de descontinuidade do produto no mercado, como reciclagem reutilização, remanufatura, desmontagem e descarte, também foram definidas nos requisitos do produto, após a análise do seu ciclo de vida e das necessidades dos usuários em cada fase do ciclo de vida. Durante o projeto conceitual, quando se aplicou a técnica de Projeto para o Meio Ambiente (DFE — Design For Environment) e a de Projeto para Desmontagem (DFD — Design For Disassembly), essas estratégias de descontinuidade foram consideradas definição das soluções alternativas. Na fase de projeto detalhado, quando os SSCs foram criados e detalhados, essas estratégias ainda foram levadas em conta. Na definição do ciclo de vida do produto, todas essas informações e atividades/custos associados foram previstos e utilizados no estudo de viabilidade econômico-financeira, que é constantemente atualizado e monitorado. A existência desta atividade formal serve para se consolidar essas informações em um plano de fim de vida, que contém as diretrizes a serem aprovadas no gate gerencial desta fase e monitoradas durante todo o ciclo de vida. Quando mudar qualquer condição de mercado e tecnológica (mudança de requisitos, de regulamentações, de inovações de reciclagem, aceitação do produto pelo mercado, novas datas de descontinuidade do produto, volumes de vendas etc.), este plano deve ser atualizado, pois agrega as informações básicas para a fase de descontinuar o produto. Essas informações agregam todas as características do produto voltadas para o meio ambiente, obtidas até este momento, e também para a descontinuidade da produção e finalização do suporte ao produto (veja a fase de descontinuação do produto, no Capítulo 12).

8.13 Testar e homologar produto Esta atividade está relacionada à garantia da qualidade do produto, antes da sua produção e, por isso, convém que tenhamos uma visão da relação deste modelo com a ISO 9001, conforme colocado no Quadro 8.29. Assim, podemos comparar a atividade de testar e homologar com as atividades semelhantes.

CAPÍTULO 8

Projeto Detalhado

Quadro 8.29

379

Requisitos da ISO 9001 e as Atividades Deste Modelo de Referência

Uma empresa que esteja sistematizando o seu PDP, com base no modelo genérico, apresentado neste livro, pode se encontrar em três situações: já possui certificação da ISO 9000, deseja se certificar ou pretende atender aos requisitos desta norma, sem vislumbrar uma certificação. Em todos esses casos, o modelo de referência específico e o sistema de gestão da qualidade precisam estar integrados, para evitar desperdícios. Essa integração é discutida no Quadro 14.1 sobre ISO 9000, apresentado no Capítulo 14. Para que o conteúdo entre o modelo e os requisitos da ISO 9000 seja compatível, as atividades propostas no modelo devem estar em consonância com a norma ISO 9001 e, particularmente, com os seguintes requisitos relacionados à realização do produto (Capítulo 6 — Norma ISO 9001): determinação e análise crítica dos requisitos relacionados ao produto; comunicação com o cliente; planejamento do projeto de desenvolvimento; análise crítica das entradas e saídas de projeto, e do projeto de desenvolvimento; verificação e validação do projeto e controle de alterações. Na Tabela 8.2, apresentamos uma correlação entre esses requisitos e as atividades do modelo e, depois da tabela, discutiremos em maiores detalhes os requisitos de verificação e validação do projeto. Tabela 8.2 Relação entre Requisitos da ISO 9000 e o Modelo de Referência Requisitos da ISO 9000(*1)

Fase

Atividade

Determinação dos requisitos relacionados aos produtos

Projeto Informacional

Definir requisitos do produto

Todas as fases

O cliente pode participar do time de desenvolvimento e das revisões de fases

Projeto Detalhado

Enviar documentação do produto a parceiros

Planejamento do

Todas as atividades

Análise crítica dos requisitos relacionados ao produto (*2) Comunicação com o cliente

Planejamento do projeto de desenvolvimento

Projeto Todas as fases

Atualizar o Plano da Fase

Análise crítica das entradas

Projeto

Definir especificações do produto

de projeto

Informacional

Análise crítica das saídas de projeto

Projeto

Modelar

Conceitual

funcionalmente

Projeto Detalhado

Criar e detalhar SSCs, documentação e configuração

Todas as fases

Avaliar fase e Aprovar fase

Todas as fases

Avaliar fase e Aprovar fase

Projeto

Avaliar SSCs, configuração e

Detalhado

Documentação do produto e processo

Análise crítica do projeto de desenvolvimento Verificação do projeto

Testar e Homologar produto Validação do projeto

Projeto Detalhado

Avaliar SSCs, configuração e documentação do produto e processo Testar e Homologar produto

Preparação da

Certificar Produto

Produção

(continua)

380

PARTE 2

Quadro 8.29 Tabela 8.2

O Modelo

Requisitos da ISO 9001 e as Atividades Deste Modelo de Referência (continuação) Relação entre Requisitos da ISO 9000 e o Modelo de Referência (continuação)

Requisitos da ISO 9000(*1)

Fase

Atividade

Controle de alteração

Atendido pelo processo de apoio “Gerenciamento das mudanças de engenharia”

(*1) Esses requisitos fazem parte do Capítulo 7, sobre a ISO 9001, “Realização do Produto”. (*2) Segundo a norma, esta análise deve acontecer antes de a empresa assumir o compromisso de fornecer o produto. Ela está relacionada, portanto, ao desenvolvimento de produtos sob encomenda, que não é o foco do processo apresentado. Porém, é similar, como mostrado na parte “Modelo para produção sob encomenda Engineering To Order (ETO )” no Tópico 16.2. Observe a Tabela 16.2 do Capítulo 16, na qual são mostradas as adaptações do modelo de referência para desenvolvimentos desse tipo. Esse requisito seria atendido pela fase “vender produto”, do modelo adaptado a produtos ETO. Os requisitos constantes do Tópico 7.2.4, da norma, medição e monitoramento de produto, são atendidos parcialmente pela fase de acompanhamento de produto, pois somente nela são consolidadas as informações advindas dos processos de atendimento ao cliente e da assistência técnica. Os requisitos constantes do Tópico 7.3, controle de produto não conforme, são atendidos pelo processo de produção, e as ações para eliminar as não-conformidades que envolvem alterações do produto, pelo processo de apoio “Gerenciamento das mudanças de engenharia”. Os requisitos constantes do Tópico 7.5, melhorias, são atendidos pelo processo de apoio “Melhoria do PDP”. Leia mais sobre este assunto em ABNT NBR, ISO 9000: 2000, 2002.

Esta atividade de teste e homologação do produto fornece um aspecto formal ao processo, tornando-se um ponto de convergência e integração de todas as atividades relacionadas com averiguações do produto. Observando-se a Tabela 8.2 pode-se notar a diferença entre esta atividade e as outras do modelo. O teste e homologação atendem parcialmente aos requisitos da ISO 9001 de verificação e à validação do projeto. A verificação analisa os resultados (saídas/documentos) do projeto para garantir o atendimento dos requisitos do produto, ou seja, analisa as especificações finais do produto. A validação deve assegurar que o produto final atenda aos requisitos de sua aplicação específica, ou seja, testa o protótipo do produto. Os requisitos da ISO 9001 também são atendidos parcialmente pela tarefa de “avaliar SSCs, configuração e documentação do produto e processo”. A atividade de testar e homologar complementa a de avaliar. As avaliações reaA atividade de avaliar está lizadas em uma atividade não são repetidas na outra, pois elas são seqüenciais. A atino ciclo de otimização e é vidade de avaliar está no ciclo de otimização, é dinâmica, e visa otimizar os SSCs em complementada pelos primeiro plano, objetivando a qualidade do produto. Ela tem um caráter interno e testes de homologação do repetitivo. A tarefa de testar e homologar ocorre somente após o fechamento do produto final ciclo de otimização. Nela, a versão final do protótipo é aprovada, considerando-se todos os detalhamentos criados (na Figura 8.3, repare que esta tarefa possui, como entrada adicional, os resultados das atividades de criação do material de suporte do produto e do projeto de embalagens). Homologar tem um caráter de atendimento explícito às exigências das instituições reguladoras, de homologação ou clientes específicos. Muitas vezes esta atividade é realizada sob a supervisão dos clientes, órgãos de homologação ou de certificação etc. Às vezes, os testes finais e a homologação do produto são conduzidos pelos próprios clientes e esses órgãos. Nesta atividade, o protótipo final do produto pode ser testado até a sua exaustão, quando se tiver um certo grau de certeza de que o ciclo de otimização já terminou. Lógico que, mesmo com a finalização do ciclo de otimização, se o teste no produto final indicar alguma limitação, um novo ciclo deve ocorrer. Esta atividade é formal

CAPÍTULO 8

Projeto Detalhado

381

Em casos mais simples, acontece somente a compilação de todos os documentos criados anteriormente, após o término do ciclo de otimização e liberação técnica do produto. Eles são formalmente organizados para que se possa realizar a aprovação da fase (gate gerencial). As tarefas desta atividade são: n n n n n

Verificar a documentação Verificar a funcionalidade do produto Verificar o atendimento aos requisitos Verificar o atendimento a normas Obter certificado de homologação

Note que as tarefas são similares àquelas da tarefa de avaliação dos SSCs, acrescidas da confecção final do certificado de homologação. Como estamos testando um protótipo funcional do produto, mas não o produto final, produzido pelo equipamento de produção definitivo, a certificação, nesses casos, é intermediária. Na fase preparação da produção, acontece a homologação do processo, que avalia se o processo produtivo consegue fabricar produtos em série equivalentes aos protótipos aprovados e, portanto, de acordo com os requisitos de produto levantados. Certificar o produto na fase de preparação da produção consiste em receber a aprovação completa do produto e do processo produtivo pelo cliente ou entidade reguladora/normativa, caso necessário. A diferença entre a homologação e a avaliação/aprovação (gate) da fase de proCertificação de jeto detalhado está na abrangência de ambas. Observe a Figura 8.3 da visão geral desta homologação é fase de projeto detalhado. A homologação do produto depende da aprovação da dointermediária e a cumentação detalhada, da existência do projeto de embalagens e dos materiais de certificação final ocorre apoio ao produto, e não do detalhamento dos processos de fabricação e montagem. na fase de preparação da produção A aprovação (gate) da fase, todavia, depende da homologação do produto, da existência de um plano de fim de vida do produto e, principalmente, de um novo estudo de viabilidade econômico-financeira. Este, por sua vez, utiliza as informações de detalhamento do processo para poder calcular com maior precisão o custo do produto. A aprovação da fase também verifica se todas as atividades de detalhamento (incluindo o detalhamento do processo) foram realizadas. O escopo da aprovação é gerencial e o da atividade de homologação é técnico.

8.14 Enviar documentação do produto a parceiros Quando se trata de uma empresa fornecedora, ou seja, o produto resultante do desenvolvimento é parte do produto do seu cliente (um SSC), podem acontecer os seguintes relacionamentos entre a empresa e seus clientes: n n n

n

Situação de uma empresa fornecedora

o desenvolvimento ocorre no conceito de engenharia colaborativa; o cliente participou ou coordenou a atividade de homologação descrita anteriormente; a fornecedora já foi certificada anteriormente pelo cliente e possui um protocolo de comunicação acordado com relação à documentação de desenvolvimento; a fornecedora não possui um relacionamento de fornecimentos com clientes específicos, mas o seu mercado não é o mercado final e, sim, as montadoras.

Em alguns relacionamentos ocorrem combinações desses casos, por exemplo, uma empresa pode estar trabalhando em engenharia colaborativa com o cliente e, mesmo assim, o cliente participa da atividade de homologação.

382

PARTE 2

O Modelo

Os times de desenvolvimento de ambas as empresas estão em contato constante. Há uma troca intensa de informações durante todo o processo de desenvolvimento e, portanto, não tem sentido existir uma tarefa específica para o envio de documentação. Em relacionamentos mais estreitos, as empresas que trabalham com engenharia colaborativa compartilham as suas informações e até utilizam os mesmos sistemas de informação, por exemplo, o mesmo sistema PLM (veja o Quadro 8.30). Caso de engenharia colaborativa

Quadro 8.30

Product Life-cycle Management (PLM )

O termo PLM significa gestão do ciclo de vida de produtos. É um significado bem amplo e abrangente. Este livro trata, portanto, de PLM, pois o escopo do desenvolvimento de produtos que mostramos vem desde o planejamento estratégico até o fim da vida do produto. No entanto, queremos discutir, neste quadro, sistemas PLM e não o conceito mais abrangente. Os sistemas PLM passam a ser a panacéia do momento para a área de desenvolvimento de produtos, como foram os sistemas ERP no passado recente, dentro da área de gestão empresarial. Dessa forma, existem no mercado fornecedores de PLM que oferecem sistemas similares, mas com funcionalidades diferentes, dependendo de sua origem: fornecedores de ERP, de CAD/CAE e de PDM (veja a Figura 8.44). Figura 8.44

Abrangência do PLM de três tipos de fornecedores: de ERP, de CAD/CAE e de PDM.

Os sistemas de ERP, antigamente, tinham módulos simples de engenharia, que tratavam basicamente da inserção dos dados de engenharia na sua base de dados única. Eles então incorporaram funcionalidades mais sofisticadas, integrando suas soluções a sistemas PDM de outros fornecedores, que, por seu lado, foram incorporando funcionalidades de gestão de projetos. Alguns dos fornecedores de ERP romperam as alianças e desenvolveram seus módulos de PDM, integrados com os seus módulos financeiros, o que passou a ser uma das maiores vantagens competitivas de seus sistemas PLM. Os sistemas ERP foram divididos em três grandes suítes de sistemas conhecidas por: Customer Relatioship Management (CRM ), Supply Chain Management (SCM ) e PLM. Seus sistemas PLM precisam ser integrados às soluções CAD/CAE. Os fornecedores de CAD/CAE foram incorporando funcionalidades de gerenciamento de arquivos às suas soluções e, muitas vezes, associaram-se ou compraram sistemas PDM, que foram integrados. Eles oferecem todas essas soluções de forma única e criaram interfaces com os sistemas ERP, uma vez que precisam estar integrados com as funcionalidades que apóiam os processos de produção e de gestão financeira. Os fornecedores de PDM foram aumentando a funcionalidade de seus sistemas e se especializaram em alguns nichos de mercado. Desenvolveram interfaces com as soluções CAD/CAM mais conhecidas no mercado e também com os sistemas ERP. Dessa forma, os sistemas PLM abrangem todas as funcionalidades dos sistemas PDM/EDM, CAD/CAE/CAM/CAPP, de gestão de projeto, e está intimamente integrado com os sistemas ERP (ou os sistemas CRM e SCM). Ou seja, o PLM é um sistema integrado que gerencia todas as informações e o processo de desenvolvimento de produtos.

(continua)

CAPÍTULO 8

Projeto Detalhado

Quadro 8.30

383

Product Life-cycle Management (PLM ) (continuação)

Na Figura 8.45, procuramos fazer uma síntese das grandes funcionalidades dos sistemas PLM, com base na oferta de sistemas comerciais existentes atualmente. Figura 8.45

Visão geral dos módulos dos sistemas PLM.

Na base de tudo está a Gestão de Documentos (GED) e o gerenciamento dos dados da configuração de produtos (veja o Quadro 10.2), que são módulos acionados pelos usuários na realização de qualquer atividade do PDP. No centro do PLM, estão as funcionalidades genéricas que apóiam a colaboração entre os usuários distribuídos geograficamente e a integração entre sistemas de diversos tipos. O nível mais baixo de colaboração compreende a existência de ferramentas comuns de comunicação e compartilhamento de informações, como e-mail e diretórios compartilhados na Internet. No nível mais sofisticado, abrange o gerenciamento colaborativo de projetos e o desenho compartilhado de componentes na Internet, por exemplo. São funções de suporte que podem ser usadas por todos os outros módulos. O ponto de acesso é um portal flexível, que permite a sua customização para cada tipo de usuário. A integração envolve a tecnologia que apóia a transparência do trabalho colaborativo e a troca de dados entre aplicativos distintos. Outro ponto central do PLM são os aplicativos que permitem a criação de informações e documentos relativos aos produtos e seus SSCs. São os aplicativos CAD/CAE/CAM/CAPP entre outros (veja o Quadro 8.11). Os aplicativos de gestão de programas estão em um outro nível, que compreende a gestão de portfólio de projetos (veja o Capítulo 4) e a gestão de projetos (veja Quadro 5.1). Entenda-se por programa um conjunto de projetos de desenvolvimento. Essas funcionalidades apresentadas são genéricas e podem ser encontradas em todos os sistemas PLM, menos as funções 69 de criação, encontradas somente nos sistemas PLM, oriundos de fornecedores de sistemas CAD/CAE. Uma outra funcionalidade importante, encontrada somente em alguns sistemas PLM, é a de gestão do conhecimento. É difícil delimitar aqui as funções de GED e quais são as de gestão do conhecimento. Toda vez que existir um conhecimento explícito, registrado em um documento, ele será gerenciado por um sistema GED. Consideram-se aqui as seguintes funções adicionais de gestão do conhecimento: gerenciamento de arquivos não estruturados (como notas e comentários sobre documentos, por exemplo), currículo de pessoas, registro de melhores práticas e lições aprendidas, e a ligação lógica entre 70 todos esses elementos. As demais funcionalidades fazem parte de módulos, que representam soluções específicas de um ou de outro fornecedor de PLM.

(continua) 69

70

Esses fornecedores simplesmente nomeiam hoje as funcionalidades dos seus sistemas CAD/CAE como funcionalidades de PLM. Ou seja, “vendem” os mesmos produtos com outros nomes. Porém, não se deve esquecer das demais funcionalidades das suas suítes, chamadas de PLM. Essas sim são de gestão do ciclo de vida do produto e fazem parte dos sistemas PDM. Mesmo assim, ainda é discutível se as funcionalidades necessárias à gestão de conhecimentos não são as mesmas encontradas em sistemas GED mais sofisticados.

384

PARTE 2

Quadro 8.30

O Modelo

Product Life-cycle Management (PLM ) (continuação)

Busca e cotação de material (e-sourcing): apóia as atividades de aquisição de material (veja o Quadro 8.15, sobre uso de Internet para as atividades de aquisição do PDP). Gestão de ativos: inclui o suporte às atividades de manutenção de equipamentos e outros bens especificados e utilizados no PDP. Gestão da qualidade: compreende as funcionalidades relacionadas ao sistema de gestão da qualidade (gerenciamento do manual da qualidade, procedimentos, instruções e registros); controle da qualidade (controle estatístico, gestão de laboratório de metrologia, gerenciamento de ensaios e inspeções, calibração e testes etc.); e as auditorias da qualidade. Gestão de requisitos: reúne de forma sistemática todos os requisitos levantados e seus desdobramentos, visando a sua reutilização e validação durante todo o PDP. Gestão de times: funcionalidades integradas a aplicativos de gestão de recursos humanos, dedicada à seleção de pessoas (busca de competências), organização dos times, alocação (integrado com sistemas de gestão de projetos) e recompensas. Gestão do meio ambiente: cuida dos padrões técnicos e normativos associados à operação e ao plano de fim de vida do produto.

No caso de relacionamento com um cliente que participa ou coordena a atividade de homologação, esta atividade de envio da documentação acontece somente se o cliente exigir, com o objetivo de avaliar as especificações do produto. Nesses casos, esta atividade ocorre antes do teste e homologação. Mas também pode acontecer de o cliente simplesmente exigir que a documentação seja enviada para armazenamento nos seus arquivos e/ou utilização por seus projetistas, pois o cliente necessita das especificações detalhadas para analisar as interfaces entre os seus SSCs. Nesses casos, o cliente já certificou a empresa, com base em seus padrões de Caso de fornecedor fornecimento, ou exigiu uma certificação mais genérica, por exemplo a ISO 9000 ou 71 certificado que possui um a QS 9000, para o setor automotivo . A homologação não conta com a participação 72 protocolo de comunicação dos clientes, e a aprovação do produto se dá na fase de preparação da produção, com o cliente quando há a certificação final do produto, após a fabricação do lote piloto. Nesses casos, a documentação final é enviada ao cliente na fase de preparação da produção, junto ao fornecimento dos primeiros lotes, para aprovação do fornecimento pelo cliente e conseqüente certificação do produto. Se o fornecedor for certificado pela QS 9000, por exemplo, ele submete o seu produto (que para o cliente é um componente, subsistema ou sistema) com a documentação, seguindo o padrão 73 PAPP (Processo de Aprovação de Peças de Produção), da QS9000. Nos casos de fornecedores de SSCs intermediários que produzem para o merCaso de fornecedor de SSC cado, não existe um relacionamento com um cliente em especial, e assim não há o intermediários que produz envio da documentação. Toda a documentação é enviada com o fornecimento do para o mercado produto, e faz parte dos manuais de aplicação, quando necessário. Comumente, uma montadora se relaciona com o mercado final que adquirirá o Situação de uma empresa seu produto. Portanto, o envio de documentação para o cliente não acontece na fase montadora de projeto detalhado e, sim, no fornecimento do produto, como no caso anterior. Todavia, é uma boa prática compartilhar constantemente informações de seus produtos com os seus fornecedores, para evitar problemas de interfaces com o seu produto final. É comum uma montadora mudar a especificação de um SSC e não comunicar a mudança para o fornecedor, que pode estar deCaso de cliente que participa da homologação

71 72 73

Essa norma é específica de três montadoras de automóveis e está sendo substituída pela norma ISO/TS 16949. Normalmente, quando os fornecedores são certificados, os clientes não participam da homologação interna, diminuindo o custo do relacionamento. O PAPP (ou PPAP, em inglês Production Part Approval Process) é uma das especificações da QS 9000 para a indústria automotiva, que determina quais os documentos devem ser enviados com a peça (SSC), para aprovação pela montadora. Conforme a classificação de qualidade que o fornecedor possui perante a montadora, ele tem de submeter a ela mais ou menos documentos.

CAPÍTULO 8

Projeto Detalhado

385

senvolvendo um produto que possui interfaces com o SSC modificado pela montadora. O SSC não é aprovado pela montadora em uma fase muito tardia, causando impacto nos custos e tempo de desenvolvimento. Logicamente, o surgimento de um problema desse tipo mostra que não existe integração entre os parceiros da cadeia de suprimentos. Sistemas do tipo PLM (ou mesmo PDM ou EDM) teoricamente deveriam garantir a integridade entre as informações. Uma condição para que eles garantam esta integridade é a utilização desses sistemas por todos os parceiros da cadeia e a prática real da engenharia colaborativa. A existência explícita desta atividade dentro do modelo de referência do PDP de ambas as empresas contribui para alertá-las sobre a questão da integridade das informações entre os parceiros da cadeia de suprimentos, durante o PDP colaborativo.

8.15 Monitorar a viabilidade econômico-financeira Esta atividade segue o padrão da atividade genérica apresentada no Tópico 3.3. Ela recebe as informações precisas dos padrões de operação e tempos do planejamento de processo, possibilitando assim uma avaliação bem mais precisa que as anteriores.

8.16 Avaliar fase Esta atividade segue o padrão da atividade genérica apresentada no Tópico 3.4. Ela acontece na auto-avaliação para se preparar para a aprovação pelo time de avaliação. Ou seja, além do cumprimento das tarefas do projeto, devem ser analisados os critérios apresentados na Tabela 8.3. Tabela 8.3

Critérios de Avaliação do Gate da Fase de Projeto Detalhado Critérios

Técnicos Todos os SSCs foram especificados e aprovados? Todas as interfaces dos SSCs foram avaliadas e aprovadas? O protótipo foi aprovado e homologado com sucesso? Os modelos geométricos estão consistentes e armazenados na configuração para uso posterior? Os parâmetros críticos do produto e as especificações críticas foram avaliadas criticamente e estão coerentes entre si e dentro do requerido? A BOM reflete as necessidades dos demais processos de negócio da empresa? Tecnologia A tecnologia, que já estava madura e aprovada no final do projeto conceitual, continuou robusta durante o projeto detalhado e, principalmente, durante a atividade de testes e homologação? Surgiram novas tecnologias ou ameaças que podem causar impacto no sucesso do produto? Requisitos Os requisitos dos clientes estão atualizados e suas mudanças foram consideradas durante o projeto detalhado? Os requisitos de aceitação do produto estão formalizados para as próximas fases? Documentos Todos os documentos necessários foram criados e aprovados? Todos os documentos foram classificados para possibilitar reuso posterior? O sistema de gerenciamento dos documentos está operante e aprovado? As pessoas (e áreas) interessadas receberam cópias dos documentos ou foram alertadas da sua liberação? Existe uma baseline da configuração do produto liberada e armazenada com a segurança do vault para permitir, a partir de agora, somente mudanças controladas?

(continua)

386

PARTE 2

Tabela 8.3

O Modelo

Critérios de Avaliação do Gate da Fase de Projeto Detalhado (continuação) Critérios

Recursos Todos os recursos foram projetados e aprovados? A obtenção dos recursos está programada ou realizada, e eles chegarão antes da data programada para a produção do lote piloto e/ou lançamento do produto? Parceiros da cadeia de suprimentos Todos os parceiros já estão definidos e com cronogramas de fornecimento compatíveis com o planejamento de lançamento do produto? Todos os parceiros já estão com os processos de certificação em andamento, garantindo o fornecimento com qualidade até o final da data de preparação da produção? Planos Todos os planos para as fases subseqüentes foram atualizados ou receberam uma data para sua atualização? Conhecimentos As lições aprendidas e as melhores práticas foram documentadas e propriamente divulgadas? Econômicos e de desempenho O estudo de viabilidade econômica foi atualizado, analisado e aprovado? Os indicadores de desempenho do processo de desenvolvimento estão aprovados? Os indicadores de desempenho do produto no mercado, que são esperados, continuam válidos?

8.17 Aprovar fase Esta atividade segue o padrão da atividade genérica, apresentada no Tópico 3.5. Após a aprovação, ocorre a liberação oficial da produção de lotes de produtos a serem utilizados no lançamento, na distribuição inicial, nos primeiros clientes e na divulgação do produto. Mas a operação da produção em carga total depende da aprovação da fase de lançamento do produto e acontece após a demanda subir. Os mesmo critérios verificados na auto-avaliação da atividade anterior são analisados pelo time de avaliação.

8.18 Documentar as decisões tomadas e registrar lições aprendidas Esta atividade segue o padrão da atividade genérica, apresentada no Tópico 3.6. Ao longo deste capítulo foram descritas diversas práticas. Ficaria repetitivo listá-las novamente neste tópico74 No final da fase todas informações criadas são organizadas como especificações finais e equivalem a configuração do produto com o status “como projetado”. Elas ficam congeladas a partir do final desta fase. Durante o desenvolvimento, elas ainda podem ser modificadas, mas, nesses casos, recebem um outro status. Além disso, durante o ciclo de vida do produto, a organização das informações em configurações garante a sua rastreabilidade.

8.19 Questões e atividades didáticas propostas Questões para reflexão 1. Discuta os conceitos da integração entre a fase de projeto conceitual e projeto detalhado, focando os aspectos de detalhamento top down e integração dos SSCs de forma bottow up. Acrescente nessa discussão a análise sobre a integração, considerando o grau de novidade e complexidade do produto.

74

Existe uma atividade didática proposta, relacionada a este tópico.

CAPÍTULO 8

Projeto Detalhado

387

2. O que são os ciclos de detalhamento, de aquisição e de otimização da fase de projeto detalhado? Quais são as atividades envolvidas em cada um desses ciclos? Como eles estão interligados? Qual o significado no termo ciclo? 3. Algumas empresas aplicam uma divisão diferente de fases. Elas definem uma fase intermediária entre a de projeto conceitual e a de projeto detalhado. Por que elas fazem isso? Quais são as vantagens e desvantagens? Como é que uma dessas empresas pode utilizar o Modelo Unificado e, mesmo assim, prever esta fase de projeto intermediário, quando estiver realizando um projeto de desenvolvimento? 4. Defina o que são sistemas, subsistemas, componentes e itens de um produto. 5. O que caracteriza um módulo de um produto? 7. Qual a relação entre a plataforma de um produto e a família de produtos? 7. Qual a diferença entre as especificações finais de um produto e sua configuração? 8. Quais os motivos para sempre se tentar reaproveitar um item existente antes de criar um novo item na empresa? 9. Qual a diferença entre o código de identificação de produtos e o código de classificação? 10. A filosofia da Tecnologia de Grupo ainda é atual, pois prega a formação de famílias de itens e produtos. No entanto, caiu em desuso a aplicação de códigos de codificação e classificação de itens pela tecnologia. Explique por que não se usa mais esses códigos. Quais as novas ferramentas existentes para se classificar itens? Quais são as vantagens de classificar os itens? E, finalmente, quais são os ganhos que a Tecnologia de Grupo traz? 11. Explique a frase: “A reutilização hoje em dia tem um sentido mais amplo”. 12. Qual o significado e as vantagens de uma procura (sourcing) de itens no mercado? 13. Apresente os conceitos principais dos sistemas Component Supplier Management (CSM). 14. Relate quais são as estratégias de padronização no projeto e quais os benefícios resultantes desta prática. 15. Por que não é mais uma boa prática utilizar códigos de identificação significativos? Qual é a regra mais apropriada para se definir um código de identificação? 16. Explique a diferença entre parâmetros críticos e especificações críticas no contexto do gerenciamento dos parâmetros críticos (CPM). 17. Em quais momentos do PDP são identificados os parâmetros críticos? 18. Defina o escopo das etapas de definição e implementação do gerenciamento dos parâmetros críticos (CPM). 19. Às vezes, é realizado um cálculo de dimensionamento de um item durante o projeto conceitual. Nesses casos, deve-se calcular o item novamente durante o projeto detalhado? Justifique a sua resposta. 20. Deve-se trabalhar com sistemas CAD desde a fase de projeto conceitual? Explique a sua resposta. 21. Deve-se trabalhar nas empresas de bens de consumo duráveis com sistemas CAD, que possuem modelador geométrico 3D ou 2D? Por quê? 22. Descreva as características dos sistemas CAD baseados em features. 23. Liste algumas funcionalidades de sistemas CAD e explique o seu uso. 24. Quando é que se usa a aplicação de tolerância analítica e a experimental? Forneça exemplos. 25. Qual a razão de especificar as tolerâncias geométricas e a rugosidade em componentes mecânicos, além das tolerâncias dimensionais? 26. Explique o conceito de Geometric Dimensioning and Tolerancing (GD&T). 27. Por que a atividade de integrar os SSCs normalmente ocorre depois da finalização dos ciclos de otimização e aquisição? 28. Como o processo de desenvolvimento de software (como item do produto) está integrado com o processo de desenvolvimento de produtos?

388

PARTE 2

29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61.

O Modelo

Explique o que é uma estrutura de produtos (BOM) modular. Analise a afirmação: “A empresa deve possuir uma estrutura de produtos (BOM) única”. Descreva a atividade de decidir comprar ou fabricar (make or buy decision). Defina o que é o custo-alvo e como ele é aplicado no PDP. Por que as empresas passam cada vez mais atividades do seu PDP para os seus fornecedores? Liste as vantagens e desvantagens desta prática. Como é que se deve homologar os fornecedores durante a fase de projeto detalhado? Explique quais são os dois níveis de planejamento de processo e os motivos desta divisão. Quem são os usuários de cada um dos níveis de planejamento? Explique a frase: “O início do planejamento do processo pode ocorrer no projeto conceitual”. Explique quais são as condições para poder se realizar de forma paralela a criação de desenhos e o planejamento de processo. Compare as funcionalidades dos sistemas PDM e EDM (GED). Defina o que é um sistema workflow. Descreva o método de planejamento de processo convencional e o apoiado por computador. Defina o que é o cálculo de sobremetal de usinagem dentro do planejamento de processos. Quando é viável aplicá-lo? Qual é a relação entre a tarefa de selecionar máquina e a de determinar uma operação de fabricação? Defina o que é manufatura virtual e explique qual a superposição existente com as funcionalidades dos sistemas CAE. Liste todos os tipos de recursos de fabricação. Compare os objetivos da atividade de avaliar os SSCs com os da atividade de testar e homologar o produto. Analise a afirmação: “A atividade de avaliar os SSCs ocorre imediatamente após a finalização da atividade de criar os SSCs”. Descreva os termos “modo de falha”, “efeito” e “causa”, existentes no método FMEA. Qual a vantagem da aplicação do FMEA? Descreva de forma sucinta as etapas de aplicação do FMEA. O FMEA deve ser aplicado durante o projeto conceitual ou projeto detalhado? Justifique a sua resposta. Compare o DOE com o método de Projeto Robusto (método Tagushi). Quais são os tipos de protótipos que podem ser usados no PDP? Em que fases eles podem ser aplicados? Qual a abrangência da atividade de otimizar produto e processo? Descreva os conceitos básicos sobre disponibilidade, confiabilidade e manutenabilidade. Como eles se relacionam com o PDP? Descreva e analise a importância da atividade de criação do material de suporte. Por que a atividade de projetar embalagem faz parte da fase de projeto detalhado? Explique a afirmação: “As atividades deste modelo estão em conformidade com a norma ISO 9001: 2000”. Por que uma possível certificação do produto, que pode ocorrer na atividade de sua homologação, na fase de projeto detalhado, é considerada intermediária e não final? Defina em poucas palavras o que é um sistema PLM. Qual a grande diferença entre a funcionalidade de um sistema PLM, oferecido por um fornecedor de sistemas CAD/CAE/CAM, e a de um fornecedor de ERP? Apresente alguns exemplos de troca de informações entre parceiros de uma cadeia de suprimentos ao final da fase de projeto detalhado.

CAPÍTULO 8

Projeto Detalhado

389

62. Quais medidas poderiam ser tomadas para evitar que uma empresa montadora deixe de enviar as atualizações das especificações dos seus SSCs aos seus fornecedores?

Atividades didáticas 1. Quais são as denominações, que se encontram na bibliografia e na prática, equivalentes ao que se chama aqui de fase de projeto detalhado? 2. Entreviste pessoas responsáveis pelo gerenciamento de projetos de desenvolvimento de produtos e verifique como eles planejam as atividades da fase de projeto detalhado (ou uma fase equivalente). A intenção é descobrir qual o nível de detalhamento do planejamento. 3. Selecione alguns produtos conhecidos e identifique nele os sistemas, subsistemas, componentes e matéria-prima. Crie uma estrutura de produto-padrão (simplificada) para esses produtos, utilizando os itens identificados. Defina os módulos desses produtos e procure saber se eles possuem plataforma. 4. Pesquise exemplos reais de famílias de produtos que possuem plataforma e módulos. Represente, da melhor forma que conseguir, com o objetivo de apresentar para os seus colegas. 5. Levante casos reais de empresas que classificam seus produtos, para recuperação posterior e também para a formação de família de componentes. Descubra como essas empresas classificam os seus produtos. Utilize, para o seu levantamento, a Internet, contatos em empresas reais e artigos. Discuta esses casos e compare com a teoria fornecida. 6. Identifique na Internet catálogos de compras e especificação de itens, que poderiam ser utilizados no projeto detalhado. Crie uma categorização para esses catálogos segundo os tipos de informações que eles contêm e os tipos de produtos que podem ser comprados. 7. Levante exemplos reais de códigos de identificação de produtos e analise esses exemplos com base na teoria fornecida. 8. Defina alguns produtos e discuta com seus colegas quais seriam os parâmetros críticos e as especificações críticas dos seus SSCs. 9. Na bibliografia sobre PDP, identifique casos de empresas que empregaram com sucesso o gerenciamento dos parâmetros críticos, relatando os resultados obtidos. 10. Liste exemplos de produtos que possuem itens com inovações tecnológicas e itens tradicionais. 11. Descubra na Internet programas de apoio ao cálculo de itens de tecnologia tradicional. 12. Levante na Internet sites de fornecedores de soluções CAD/CAE/CAM, e monte um “catálogo” de exemplos de sistemas comerciais com exemplos de simulação. Organize esse catálogo em forma de uma tabela e entenda as funcionalidades básicas desses sistemas. Monte uma apresentação, comparando-os. 13. Tente encontrar uma aplicação prática real para algum dos sistemas levantados, e entreviste o usuário do sistema, perguntando quais as características do sistema e os benefícios reais que a empresa obteve com ele. 14. Defina um parâmetro crítico de um subsistema, como o do exemplo da Figura 8.16 (ou outro equivalente de um produto real que você tiver acesso). Defina cadeias dimensionais alternativas que avaliam o mesmo parâmetro crítico. 15. Arrume exemplos de desenhos reais de componentes com especificações de tolerâncias de forma e posição, assim como rugosidades. Interprete esses desenhos com os seus colegas, avaliando como você faria para inspecionar essas medidas. 16. Tente descobrir quais são os softwares (incluindo os embarcados) de um produto que você conhece. 17. Selecione um produto apropriado para possuir uma BOM modular. Tente montar um exemplo simplificado.

390

PARTE 2

O Modelo

18. Simule dados de um produto e monte uma planilha para calcular o seu custo de fabricação. Compare esse custo com o preço de um fornecedor fictício, e discuta a validade dessa comparação, uma vez que outros componentes de custo devem ser considerados para se realizar a comparação? 19. Levante casos reais de “decidir fazer ou comprar” e descubra como eles tomam a decisão e se ela está relacionada com o custo-alvo. 20. Levante exemplos de planos de processo e seus detalhamentos. Discuta se eles são divididos em dois níveis, como mostrado na teoria. Analise também as diferenças entre os documentos obtidos e quais são os motivos dessas diferenças. 21. Tente encontrar casos de paralelismo entre a obtenção de desenhos e o planejamento do processo. Como eles praticam a engenharia simultânea e garantem a integridade entre as informações? 22. Liste sistemas PDM, GED e PLM na Internet, e discuta quais são as superposições e diferenciais entre cada um deles. 23. Arrume um catálogo de máquina e anote quais são os atributos da máquina e outras características que são utilizadas no planejamento de processo. Defina como cada uma dessas características são utilizadas no planejamento. 24. Encontre na Internet catálogos de ferramentas, dispositivos etc. que poderiam ser utilizados no planejamento do processo. Monte cada catálogo em uma folha que descreva as suas principais características. 25. Mostre exemplos de sistemas CAPP (ou MPM) citando as empresas que os utilizam. 26. Levante alguns nomes de empresas especializadas em produzir equipamentos especiais e descreva em poucas palavras o seu portfólio de produtos, analisando se ela poderia ser fornecedora de uma outra empresa na atividade de projetar recursos de fabricação. 27. Descreva o exemplo de uma empresa especializada em projetos de fábrica. 28. Entreviste um funcionário de uma grande empresa, procurando saber se eles contratam os projetos de fábrica ou se eles os realizam. Análise o exemplo de uma maneira crítica. 29. Simule um time de desenvolvimento de produto com os seus colegas, selecione um produto simples e conhecido, e monte um FMEA, definindo para cada membro do time um papel e uma especialidade. 30. Crie uma planilha para a Tabela 8.1 e mude os valores das dimensões e das tolerâncias para analisar a sensibilidade daquela cadeia dimensional, mostrada na Figura 8.44. Você pode usar algum outro produto como exemplo, se estiver disponível. Recalcule as dimensões e tolerâncias dos elementos, no caso de se retirar um anel espaçador e também no caso de diminuir a tolerância final pela metade. 31. Liste todas as melhores práticas identificadas durante este capítulo.

8.20 Informações adicionais ASME Y 14.5M — 1994 Geometric Dimensioning and Tolerancing (GD&T) ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 6409/NB273: tolerâncias geométricas – tolerâncias de forma, orientação, posição e batimento – generalidades, símbolos, definições e indicações em desenho. Rio de Janeiro, 1997. ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO9000:2000: sistemas de gestão da qualidade – fundamentos e vocabulário. Rio de Janeiro, 2002. BLACK, J. O Projeto da fábrica com futuro. Porto Alegre: Artmed, 1988. 288p. CIMDATA (1998). Product data management: the definition, an introduction to concepts, benefits, and terminology. CLAUSING, D. Total quality development: a step-by-step guide to world class concurrent engineering. New York: ASME Press, 1994. 506 p. CORREA, H. Planejamento, programação e controle da produção. São Paulo: Atlas, 2001. 452 p.

CAPÍTULO 8

Projeto Detalhado

391

CREVELING, C. M. Tolerancing design: a hanbook for developing optimal specification. Massachusetts: Addison-Wesley, 1997. CREVELING, C. M.; SLUTSKY, J. L.; JUNIOR ANTIS, D. Design for six sigma: in technology and product development. New Jersey: Prentice Hall PTR, 2003. CROW, K. Product cost management through integrated product development. DRM Associates, 1997-A. Product Development Forum Home Page, 1999. DFMA. Disponível em . Acesso em: 18 fev. 2005. EULALIA, L. A. DE S.; ROZENFELD, H.; MOREIRA, E. DOS S.; CARVALHO, A.; P. DE L. F. DE. Using ontologies for intelligent information retrieval in an e-commerce application case study. In: EUROPEAN CONFERENE ON PRODUCT AND PROCESS MODELING IN THE BUILDING AND RELATED INDUSTRIES, 40., 2002, Slovenia. Proceedings... Slovenia: Balkema, 2002. p. 277-284. FREIXO, O. M. Incorporação da gestão dos custos do ciclo de vida ao processo de desenvolvimento do produto: a utilização da pesquisa-ação e o caso embraer. 2004. Tese (Doutorado em Engenharia de Produção). Universidade Federal de São Carlos, São Carlos, 2004. GALORATH. Disponível em . Acesso em: 18 fev. 2005. HALEVI, G.; WEILL, R. D. Principles of Process Planning: a logical approach. Chapman & Hall, 1995. p.399. HOYLE, D. QS-9000: quality systems handbook. USA: Society of Automotive Engineers, 1997. 562 p. IBM. Disponível em Acesso em: 18 fev. 2005. MACHINING data handbook. 3. ed. Cincinnati, Ohio: MDC, 1980. MUTHER, R.; WHEELER, J. D. Planejamento sistemático e simplificado de layout. Imam. 56 p. NIEBEL, B.; FREIVALDS, A. Methods, standards & work design. New York: McGraw-Hill Science, 2002. 768 p. NITIDUS Technology Inc. White paper component and supplier management: a strategic imperative. OLIVEIRA, C. B. M ; ROZENFELD, H. Desenvolvimento de um módulo de FMEA num sistema comercial de CAPP. In: ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇAO, 17., 1997, Gramado. Anais… Porto Alegre: UFRGS/PPGEP, 1997. OLIVEIRA, C. B. M. de. Estruturação, identificação e classificação de produtos em ambientes integrados de manufatura. 1999. Dissertação (Mestrado em Engenharia Mecânica) — Escola de Engenharia de São Carlos, Universidade de São Paulo, São Carlos, 1999. 104 f. OMOKAWA, R. Utilização de sistema PDM em ambientes de engenharia simultânea: o caso de uma implantação em uma montadora de veículos pesados. 1999. Dissertação (Mestrado em Engenharia Mecânica), Escola de Engenharia de São Carlos, Universidade de São Paulo, São Carlos, 1999. 154 f. PAHL, G. and BEITZ, W. Engineering design. A systematic approach. Springer-Verlag London Limited, 1996. PAULA Filho, W.P. Engenharia de software: fundamentos, métodos e padrões. Livros técnicos e científicos, 2001. 581p. PORTO, A. J. V.; PALMA, J. G. Manufatura virtual. In: Fábrica do Futuro. c. 10. São Paulo: Banas, 2000. p. 89-98. PTC. Disponível em