ANÁLISE E SELEÇÃO DE SOFTWARE PARA APOIAR A GESTÃO DO PROCESSO DE DESENVOLVIMENTO DE PRODUTOS: EXPERIÊNCIAS E LIÇÕES APRENDIDAS

Transcrição

1 ANÁLISE E SELEÇÃO DE SOFTWARE PARA APOIAR A GESTÃO DO PROCESSO DE DESENVOLVIMENTO DE PRODUTOS: EXPERIÊNCIAS E LIÇÕES APRENDIDAS Creusa Sayuri Tahara Amaral (USP) tahara@sc.usp.br Janaina M. H. Costa (USP) jcosta@sc.usp.br Henrique Rozenfeld (USP) roz@sc.usp.br A aplicação de software é uma maneira de melhorar o processo de desenvolvimento de produtos (PDP). Contudo esta melhor prática é ainda subestimada devido à falta de entendimento no processo de seleção de software no sentido de atender aos rrequisitos específicos, principalmente para pequenas e médias empresas (PME). Este artigo apresenta um método que permite às PMEs analisar e selecionar software, para auxiliar seu PDP. O método sistematiza o processo de busca de conhecimentos empíricos sobre melhores práticas para o PDP. Este conhecimento pode ser atualizado por uma comunidade de prática a partir de seus conhecimentos e experiência em selecionar e aplicar soluções para o PDP. Isto pode ser reutilizado como uma base para empresas definirem seus critérios sem ter que iniciar o processo sem informação nenhuma. O artigo também apresenta uma aplicação do método em uma rede de empresas, descrevendo todas as fases até a seleção final dos softwares. Palavras-chaves: Processo de desenvolvimento de produtos, seleção de softwares

2 1. Introdução A literatura indica duas tendências para capacitar pequenas e médias empresas (PME) a trabalharem colaborativamente no processo de desenvolvimento de produtos (PDP) e, ao mesmo tempo, alcançar e desenvolver seus projetos tão eficientemente quanto possível, que são: (1) pela adoção de modelos de referência para o PDP e (2) pela implementação de ferramentas que possam apoiar esse processo. Muitos modelos de referência para o PDP são citados na literatura, tais como: Stage-gate Process (COOPER, 2001), Pahl & Beitz Model (PAHL and BEITZ, 2003), Product Design and Development Model - PDDM (ULRICH & EPPINGER, 2004), CMMI (CHRISSIS, 2004) e o modelo PDPnet (ROZENFELD et al., 2006). Paralelamente a isso, existem muitas ferramentas, métodos e software que podem ser utilizados como suporte ao gerenciamento do processo de desenvolvimento de produto. A aplicação de ferramentas e métodos são fatores importantes para a melhoria contínua do PDP. Contudo, a seleção destas práticas depende de decisões que estão associadas a duas questões: (1) a adoção ou (2) difusão dessas ferramentas. A adoção está relacionada com a decisão de se usar ou não uma determinada ferramenta. Por outro lado, a difusão está associada ao número de empresas que já tem vem adotando determinada ferramenta. (CHAI, 2006, NIJSSEN & FRAMBACH, 2000). Nijssen and Frambach (2000) concluem que uma empresa pode obter ajuda (por exemplo, de consultorias ou de agências de pesquisa de Mercado) para selecionar uma ferramenta adequada e também para saber como utilizá-la. Assim, embora para grandes empresas seja possível contratar consultorias para avaliar e indicar soluções mais viáveis e ajustadas aos requisites da empresa, esse caminho não é tão simples para as PMEs. Uma vez que em geral elas não dispõem de capital financeiro suficiente para pagar por consultorias externas, mas também têm necessidades por ferramentas que sejam adequadas à sua realidade, ou seja, em termos de custo, requisitos culturais e tecnológicos. Oportunamente, uma grande quantidade de softwares livres e gratuitos podem ser utilizados para auxiliar o PDP das empresas. Assim, as PMEs podem obter vantagens utilizando essas ferramentas, desde que faça a escolha mais adequada. Esse fato reforça a necessidade de um método de apoio para esse processo de decisão. Desta forma, este artigo apresenta um método para analise e seleção de software associados ao PDP. Este método será publicado na internet, a partir de um portal sobre desenvolvimento de produtos ( de modo que possa ser utilizado por PME gratuitamente. O artigo também apresenta um caso de aplicação do método em uma rede de empresas de base tecnológica. Os critérios de seleção definidos no caso são descritos. Estes critérios referem-se a ferramentas para algumas áreas de conhecimentos: gestão de projetos (PM), gestão de conteúdo (CM) e gestão de clientes (CRM). Nessa experiência foram registradas as lições aprendidas. O artigo foi estruturado nas seguintes seções: uma seção para a revisão da literatura, onde foi discutida a importância dos modelos de referência como meio de melhoria contínua do PDP. Em seguida apresentamos o método proposto e os resultados empíricos da aplicação do método, finalizando com as conclusões e trabalhos futuros. 2

3 2. Revisão da literatura O desenvolvimento de novos produtos é um processo de negócio conduzido por um grupo de pessoas com o objetivo de transformar dados em oportunidades de Mercado e possibilidades técnicas em informações para auxiliar o projeto de produtos comerciais. (CLARK & FUJIMOTO, 1991). De acordo com Ulrich & Eppinger (ULRICH & EPPINGER, 2004), o PDP pode ser considerado como uma seqüência de passos ou atividades utilizadas por uma empresa para conceber, projetar e comercializar um produto. Como essas atividades trocam informações entre si (BROWNING & EPPINGER, 2002), esse processo requer a cooperação de pessoas com variado e diferentes níveis de experiência, vindo de diferentes departamentos da organização. Conseqüentemente, uma efetiva comunicação é fundamental para o gerenciamento das atividades do PDP como um processo de aprendizado contínuo (SÖDERQUIST, 2006, BRADFIELD & GAO, 2007). Algumas das características do PDP são: alto nível de incerteza e risco nas atividades e resultados; utilização e produção de grande quantidade de informação; atividades e informações derivam de diversas fontes; e existem múltiplos requisitos que devem ser considerados de todas as fases do ciclo de vida do produto e das necessidades dos clientes (ROZENFELD et al., 2006). O PDP é um processo de negócio crítico para garantir a melhoria contínua e para manter a competitividade da empresa, diversidade de produtos, especialmente quando pensamos no mercado internacional e em redução do ciclo de vida do produto (BÜYÜKÖZKAN & BAYKASOGLU, 2007; ROZENFELD et al., 2006). Assim, a eficiência do PDP se deve a uma meta estabelecida para toda a empresa. Contudo, para atingir essa eficiência processo deve ser visível por todos os responsáveis (COSTA et al., 2007). Isso pode ser alcançado pela modelagem do processo de negócio e sua publicação, por exemplo, na intranet da empresa. O resultado é um mapa ou representação que descreve o processo da empresa (PERNICI & WESKE, 2006), conhecido como modelo de referência do processo de negócio. Um modelo de referência é uma coleção de melhores práticas e pode ser adaptado de acordo com o nível de maturidade do PDP da empresa. Ele também pode ser utilizado como benchmark para melhoria de novos projetos. Um modelo de referência genérico é usualmente desenvolvido para um determinado setor, mas pode ser adaptado para aplicação em outros. Isto quer dizer que as empresas que pertencem ao mesmo setor podem estabelecer seu modelo de processo padrão a partir de um modelo de referência genérico para sua corrente situação do PDP. Existem muitas propostas de modelos de referência para o PDP ( colocar referência de revisão). Nesse artigo em especial, vamos analisar com mais detalhe o modelo PDPnet (ROZENFELD et al., 2006). O modelo PDPnet sistematiza as melhores práticas do PDP, com foco na integração do planejamento estratégico e a gestão de portfólio; na incorporação dos conceitos do PMBOK (PMI, 2004) dentro na fase de planejamento; na definição de ciclos integrados no detalhamento, aquisição e otimização do produto na fase de detalhamento da produção; e na integração da fase de lançamento do produto com outros processos de negócio, tais como a assistência técnica e o processo de venda. A variedade de atividades inerentes aos modelos de referência pode ser apoiada por diversas ferramentas, métodos, conceitos, sistemas, etc. Em específico, quando buscamos uma ferramenta para auxiliar o processo, essa decisão depende: (1) do conhecimento do melhor momento para aplicá-la (em que fase, em qual atividade); (2) da capacidade de produzir 3

4 resultados; (3) da sua dependência do tipo de produto e (4) das necessidades de recursos. Isto representa uma dificuldade adicional no PDP, pois aumenta a complexidade das atividades de gerenciamento. Essas tecnologias computacionais são utilizadas no PDP, mas em algumas situações pode acabar restringindo o modo operacional da empresa em função do software utilizado. Assim, torna-se mais importante ainda definir um procedimento estruturado e sistematizado para auxiliar as empresas a selecionarem suas ferramentas computacionais (soluções computacionais que implementam métodos) que realmente se ajustem às suas necessidades. 3. Método de seleção e análise de software (MSAS) para apoiar o PDP A abordagem científica usada para o desenvolvimento do trabalho foi a hipotético-dedutiva, já que cada caso de aplicação da proposta representa uma tentativa de refutar a hipótese de pesquisa, que foi definida como: o método de seleção e avaliação de software (MSAS) é viável para ser utilizado por empresas. O método proposto nesse trabalho está ilustrado na figura 1 e pode ser dividido e 4 fases. A primeira fase desse método tem como finalidade auxiliar na elaboração da lista de requisitos da empresa. Esses requisitos específicos da empresa são obtidos por meio de entrevistas com as pessoas que estão relacionadas com as atividades para as quais está se buscando apoio (ou áreas de conhecimento vinculadas ao PDP). Contudo, uma PME pode não ser capaz de definir adequadamente todos esses requisitos. Como apoio à essa fase, o MSAS propõe uma consulta a bases de dados que contenham exemplos de consolidação de requisitos tais como a análise das melhores práticas de modelos de referência, pois elas podem indicar alguns requisitos. O conhecimento empírico é outra fonte de consulta, tais como: jornais especializados, web sites e relatos de casos em revistas. Essa investigação auxilia as empresas em preparar uma lista inicial de requisitos. Os requisitos dessa fase são verificados no Gate 1, cujo objetivo é avaliar se a quantidade e a qualidade dos requisitos definidos são suficientes para se passar para a próxima fase. Se não, é necessário retornar ao processo de especificação dos requisitos consultando de modo complementar as diversas fontes de dados. O objetivo da segunda fase é produzir critérios que serão utilizados na avaliação do software. Para isso, duas atividades foram consideradas: a primeira foi analisar o PDP da empresa em busca de outros requisitos específicos, os quais são fundamentais para que a seleção do software seja eficiente e eficaz (por exemplo, linguagem de programação, base de dados, sistema operacional, etc.). A outra atividade é a de definição de prioridades para os requisitos. Essa atividade deve ser conduzida a partir de entrevistas com o maior número possível de colaboradores da empresa. A partir da entrevista é possível definir o grau de importância de cada requisito para a empresa (vinculados a diversas áreas e com nível operacional diferentes, por exemplo: um gerente de vendas, um desenvolvedor, um gerente de marketing, etc.) e ainda proporciona a oportunidade das pessoas participarem do processo de seleção do software, vinculando a esse o seu compromisso, já que serão os futuros usuários do software. Os graus de importância (GI) variam de 0 (nenhum importância), 0,1 (pouco importante), 0,6 (importância média) e 1 (importante). Essa atividade é muito importante na aplicação do método para garantir o apoio dos colaboradores na fase de implantação do software selecionado. Esse procedimento customiza o processo de seleção de software para as reais necessidades da empresa. O resultado dessa fase, que é verificado no Gate 2, é uma lista de critérios, ponderados pelo grau de importância, que serão a base para a busca e avaliação dos 4

5 softwares. A fase 3 tem foco na busca sistematizada em bases de dados na web para encontrar os softwares que atendam aos critérios especificados (veja figura 1). Assim, nessa fase da pesquisa é importante que sejam vinculadas ao processo de busca palavras chaves bem ajustadas ao software. Nessa busca, muitos softwares são excluídos por não atenderem aos requisitos já definidos. Esses dados devem ser registrados de modo organizado em uma planilha, descrevendo tanto quanto possível os requisitos que estão presentes e aqueles que não estão e principalmente o motivo da eliminação do software da lista final. O principal resultado dessa fase é uma lista consistente de software que serão instalados para uma avaliação mais detalhada. O Gate 3 é uma verificação para garantir a consistência da lista, que servirá como base para a seleção final do software. Se por acaso algum software importante (muito difundido ou adotado) ficar fora dessa lista, todo o trabalho de avaliação não terá a eficiência requerida. A meta da fase 4 é avaliar em profundidade a lista de software definida na fase anterior. Nessa fase, podem-se consultar relatórios disponíveis na web sobre comparações de software de modo que possam ser utilizados como informações adicionais. Essa etapa pode requerer o conhecimento de pessoal técnico para a instalação dos software e configuração do sistema. Esse envolvimento garante que o processo de avaliação será conduzido de modo satisfatório. Todos os critérios devem ser considerados na avaliação e notas (N) devem ser atribuídas para cada um deles, considerando as seguintes possibilidades: 0 não atende ao critério, 3 atende parcialmente e 5 atende completamente. Assim que a avaliação for concluída, a comparação dos softwares pode ser iniciada. O grau de importância dado aos critérios, como definido na fase 2, serão utilizados para ponderar a importância do critério na nota final de cada software de acordo com a seguinte expressão: Nota final = nr i=1 N * GI i nr nr = quantidade total de critérios N = Nota dada ao critério GI = Grau de importância i Finalmente uma lista com a classificação dos softwares é definida e serve como referência para a decisão de qual software deve ser implantado. Essa decisão é validada no gate 4 de modo a verificar se estão de acordo com a estratégia e política da empresa. Fase 1 Definição dos Requisitos Fase 2 Definição dos critérios Fase 3 Elaboração da lista de Software Fase 4 Elaboração da classificação dos Software Requisitos específicos Requisitos Análise do PDP Priorização dos Requsitos pela empresa Critério Pesquisa por Software Lista de Software Avaliação do software Classificação de software Gate 1 Gate 2 Gate 3 Gate 4 Web Data Base Modelos de referência Conhecimentos empíricos Benchmarking Web Data Base Lista de Software Web Data Base Comparação de Software 5

6 Figura 1: Método de seleção e análise de software para auxiliar a melhoria do PDP Uma vez que o software tenha sido escolhido é importante definir um plano de implantação. Para esse fim, é recomendado adotar algum método de gestão de mudança, o que auxilie (1) a verificar os indicadores de desempenho antes e depois da implantação, (2) a definição de um plano de implantação, (3) permita o treinamento das pessoas envolvidas no processo de mudança. No caso da empresa adotar uma abordagem de gestão de processo de negócio (BPM), o MSAS deve ser integrado a ele (COSTA, 2007). A seção seguinte descreve a aplicação do método proposto. 4. Resultados práticos Esse estudo relata o caso de um grupo de empresas brasileiras de base tecnológica, organizadas em uma rede de empresas, que perceberam a necessidade de adotar soluções que apoiassem o PDP e também permitissem o desenvolvimento colaborativo de produtos. Esta rede foi composta inicialmente por 8 empresas de base tecnológica e um grupo de pesquisa da Universidade de São Paulo. Esta parceria teve como objetivo a sistematização e organização do PDP colaborativo e do processo de vendas de produtos sob encomenda. A fim de ajustar-se às metas do projeto conjunto, foram definidos sub-projetos, dos quais um deles foi desenvolver um método de seleção e análise de software para apoiar o PDP, o qual chamamos de MSAS e está sendo descrito nesse artigo. As empresas participantes desse subprojeto foram: Cia1, uma empresa de desenvolvimento de sistemas web; Cia2, uma empresa de desenvolvimento de software; e Cia3, um laboratório de dosimetria. O objetivo nessas empresas foi de avaliar 3 categoria de software: (1) software de gestão de projetos (PM); (2) software de gestão de conteúdo (CM) e (3)software de gestão de clientes (CRM). Dois grupos de pesquisa também foram envolvidos: Lab 1, o grupo de pesquisa 1, cujo foco é na gestão do PDP e conta com cerca de 30 pesquisadores; e o Lab 2, uma organização virtual que administra e gerencia um projeto conjunto com cerca de 600 pesquisadores de 39 grupos de pesquisa. A equipe para o projeto foi composta tanto por pessoas das empresas como por pesquisadores e alunos da Universidade de São Paulo. Essa equipe foi dividida em grupos menores responsáveis pelas categorias de software a serem analisados. A seguir é apresentada uma descrição detalhada de como o método proposto para seleção e avaliação de software foi utilizado nesse projeto. Fase 1 Definição de Requisitos A primeira fase do método proposto começa com a busca por informações sobre as melhores práticas associadas com as três categorias de software focadas pelas empresas (PM, CM e CRM). Essas informações foram baseadas em duas fontes (figura 2). (1) Padrões para a gestão de desenvolvimento de produto ( CMMI (CRISSIS et al, 2003)); o modelo de referência unificado PDPnet (ROZENFELD et al., 2006) e PMBOK - Project Management Body of knowledge (PMI, 2004). (2) Conhecimentos empíricos publicados tais como teses de doutorado, dissertações de mestrado e casos práticos publicados em revistas acadêmicas. Para o caso de softwares de PM, a análise de software proprietários foi importante, pois esses sistemas englobam várias melhores práticas. Assim, dois sistemas de gestão de projetos também foram analisados nessa fase de levantamento de requisitos: MSProject Professional 2002 and PMOffice O passo seguinte foi analisar os dados e consolidar as informações 6

7 das diversas fontes em uma lista de requisitos (veja a coluna de requisitos das tabelas 1, 3 e 5 nos anexos 1, 2 e 3), que foram analisados no Gate 1. Dois especialistas, por exemplo, em gestão de projeto foram consultados para a consolidação dessa análise. PDP Padrão Conhecimentos Empíricos Requisitos CMMI PMBok PDPnet Teses Artigos Fase 2 Definição dos critérios Figura 2: Fase 1- Definição de requisitos Primeiramente, os três grupos analisaram as atividades desenvolvidas pelos PDPs das empresas (figura 3), considerando seus níveis de maturidade. O grupo de PM foi encarregado de analisar as práticas de gestão de projetos no Lab1, Lab 2, Cia1 e Cia2. O grupo de CM investigou as atividades do Lab 2, Cia 1 e Cia2 de como liberavam os documentos de gestão de projetos de PDP, templates e outras informações relacionadas com seus colaboradores. Esse grupo também buscou por práticas que pudessem disseminar conhecimentos e lições aprendidas pelos departamentos das empresas. O grupo de CRM analisou as práticas em PDP da empresa Cia1, Cia2 e Cia3 para obter mais informações sobre seus clientes assim como sobre esse relacionamento (por exemplo, como seus clientes solicitam novas necessidades e como informavam sobre problemas e prazos). Análise do PDP Processo de Desenvolvimento de produtos Nível de maturidade do PDP Critérios Priorização dos Requsitos pela empresa Requisitos para software de Gestão de projetos (PM) Visualizar agenda de determinado projeto Visualizar disponibilidade de uso de recursos Verificar nivelamento de recursos Definição da equipe de projeto Grau de importância Grau de importância Grau de importância para empresa 1 para empresa 2 adotado Alto Alto Alto Alto Médio Alto Médio Baixo Médio Alto Alto Alto Figura 3: Fase 2 Definição de Critérios Uma vez que a análise do PDP tenha sido concluída e os novos requisitos especificados incluídos na lista de requisitos definida na fase 1, a equipe foi capaz de definir o grau de importância para cada requisito, que foram influenciados pelo nível de maturidade da empresa. Para isso, as equipes entrevistaram alguns colaboradores, principalmente aqueles que iriam utilizar os softwares depois de implantados. As informações foram registradas em uma planilha que já continha todos os requisites definidos nas atividades anteriores (figura 3). Um exemplo poder ser obtido no Os colaboradores entrevistados definiram o nível de importância de cada requisito descrito na planilha para sua empresa ou grupo de pesquisa. A finalidade dessa atribuição de pesos fornecidos pelo grau de importância dos requisitos foi de atender completamente às necessidades das empresas. 7

8 Assim, esse grau de importância foi utilizado como base de ponderação dos requisitos na avaliação final do software. O peso final do requisito foi definido considerando sempre o escore mais alto dentre os entrevistados (veja a tabela da figura 3). O grau de importância foi codificado atribuindo ao nível alto o valor 1, ao nível médio o valor 0,6 e para o nível baixo o valor 0,2 e zero para o caso sem importância. O resultado dessa fase foi o estabelecimento dos critérios que foram validados no Gate 2 com os diretores das empresas e dos grupos de pesquisa. Fase 3 Elaboração da lista de Software A primeira atividade executada na fase 3 foi de pesquisar na internet utilizando palavras chave. Para os softwarse de PM foram definidas as seguintes palavras: project management; project planning e product development planning. Para os softwares de CM: contented management; product data management; electronic data management e knowledge management. Para os softwares de CRM: CRM; help desk e client management. Todas as buscas foram realizadas com uma combinação dessas palavras mais as seguintes: tools, solution, system, software e free software. As instruções para pesquisa nas bases de dados da web foram: (1) recuperar em artigos, white paper ou teses encontradas na fase 1 informações sobre analise de software; (2) consultar web sites que abordam o assunto, tais como: and e (3) Consultar os buscadores na internet. A partir dessas buscas foi elaborada uma lista de software que atendiam aos requisitos. Os critérios não funcionais foram avaliados a partir de informações disponíveis no próprio site. Essa primeira avaliação eliminou grande parte dos softwares. A segunda eliminação foi conduzida depois da fase 4 (veja Figura 4). De um total de 27 softwares de PM encontrados, somente oito forma selecionados. No caso dos softwares de CM e CRM somente 5 de 34 e 4 de 20 foram selecionados respectivamente para a próxima fase, utilizando os critérios definidos. PM CM CRM Software não atendiam aos critérios Critérios não funcionais Critérios funcionais Software aprovado para a próxima fase Lista de Software Fase 4 Classificação dos Softwares Figura 4: Fase 3 Elaboração da lista de Software Esta fase teve por objetivo definir uma classificação dos softwares selecionados na fase 3. Para isso, todas as ferramentas selecionadas na fase 3, no caso um total de 17 softwares, foram instaladas (a facilidade de instalação e configuração também foram analisados). Os critérios foram pontuados em uma escala de 0 a 5 (figura 5). O valor 0 foi associado a ausência do critério e o valor 5 foi atribuído quando esse era completamente atendido. Um valor entre esses extremos representou a situação intermediária (somente o valor 3 foi utilizado), ou seja, quando parte do critério era atendido. Como forma de documentar e descrever a atribuição dessas notas, o grupo foi orientado a justificar os motivos desses valores. 8

9 Classificação dos software para PM Critério NF 1 NF 2 NF Notas 3 5 Lista de Software Figura 5: Fase 4 Classificação dos Software As notas atribuídas aos critérios para cada um dos 17 softwares selecionados foram multiplicados pelo seu respectivo grau de importância. Os resultados dessa avaliação e a pontuação final dos softwares são mostrados nos anexos 1,2 e 3. No Gate 4, a implantação dos softwares sobre PM, CM e CRM melhores classificados são discutidos. Foi utilizada a seguinte distribuição para testar e avaliar esses softwares nas empresas: - dotproject (software de PM) foi implantado na Cia1, Lab1 e Lab2; - ezpublish (software de CM) foi implantado na Cia 1e Lab1; - Vtiger (software de CRM) foi implantado na Cia1, Cia2 e Cia3. Depois que o MSAS proposto foi executado, um método de gestão de mudança indicado por Costa (2007) foi aplicado para auxiliar a implantação dos softwares selecionados pelas empresas. 5. Conclusão O método proposto se mostrou útil para a seleção de software para apoiar o PDP, pois pode ser aplicado conjuntamente com mecanismos de busca na internet. Os casos reais de implantação de software relatados em artigos e outros tipos de publicações e o uso de palavras chave predefinidas ajudaram a melhorar o processo de busca. Como conseqüência, a lista de software encontrada foi mais consistente em relação à quantidade e a variedade. Um segundo ponto relevante foi que a análise das melhores práticas elaborada na lista de requisitos, pela própria empresa, contribuiu para melhorar o PDP porque durante a implantação do software algumas melhores práticas podem ser incorporadas na nova rotina, conseqüentemente melhorando o processo. Isso foi relatado no caso de implantação de software de PM na empresa Cia 1. O nivelamento de recursos não era uma meta para a empresa Cia1, mas quando analisaram a lista de requisites sobre PM esta prática foi percebida como necessária. Assim, a empresa Cia1 deu um alto nível de importância para esse requisito. E teve como importante resultado a institucionalização dessa prática na empresa. Outro resultado do método proposto é que ele customiza o processo de seleção do software pelo usuário. O grau de importância de cada critério foi baseado no nível de maturidade do PDP. Assim, esta customização racionalizou o processo de tomada de decisão. As empresas minimizaram o risco de selecionar um software que parecesse ser a melhor escolha pelas suas muitas funcionalidades, mas que poderia ser inadequado para a capacidade técnica e de recursos humanos da empresa. Adicionalmente, isso proporcionou mais chances de sucesso na implantação pela redução de possíveis barreiras (por exemplo, rotinas inadequadas, deficiência de informação e incapacidade técnica). 9

10 Outro benefício percebido foi que o método agiu como um guia para também promover a melhoria do PDP, proporcionando aos colaboradores o senso de confiança e otimismo com o resultado da seleção. Uma das razões para essa atitude positiva por parte dos colaboradores foram: eles compreenderam as necessidades para a implantação de uma nova ferramenta; participaram na definição da importância dos critérios e certamente essa ponderação foi essencial para a seleção final do software; garantiu o compromisso desses colaboradores para a melhoria do PDP com o uso das novas ferramentas. O uso de software livres em pequenas empresas de base tecnológica tem provado ser uma solução prática quando se ajustam às suas necessidades. Podem ser customizados para melhor atender aos requisitos da empresa, já que disponibilizam o código fonte. Algumas das lições aprendidas podem ser descritas: (1) A aplicação de software de CRM para PDP sob encomenda é importante, pois os primeiros requisitos e especificações aparecem durante a fase de venda; (2) Os sistemas de PM mais conhecidos são de marcas proprietárias. Eles têm características suficientes para auxiliar a maioria dos projetos de gestão do ciclo de vida. Contudo, o alto custo para aquisição de licenças, a dificuldade para a customização, treinamentos e necessidade de apoio técnico dificultam sua difusão. Por outro lado, software de gestão de projetos gratuitos mostraram-se maduros suficientes para atender as necessidades das pequenas e médias empresas; (3) Os software de gestão de conteúdo (CM) facilitam a visualização do PDP na internet e também podem ser usados como um sistema de gerenciamento de documentos; (4) Os modelos de referência são importantes para orientar os projetos de melhoria do PDP e garantir uma linguagem comum entre os membros da rede; e (5) A interação entre os colaboradores da empresa durante o processo de seleção dos software contribuiu para que a fase de implantação corresse menos riscos. Evidentemente, este método deveria ser implantado em outros contextos para garantir sua generalização. Adicionalmente, o método proposto pode ser aplicado em conjunto com uma sistemática de métodos de gestão de mudanças relacionados com uma ampla abordagem de BPM e a implantação de uma solução de PDP integrada a uma arquitetura de PLM. Estas tendências seriam pesquisadas em trabalhos futuros. Os autores agradecem às empresas que voluntariamente fizeram parte dessa pesquisa e aos colegas do GEI2 NUMA USP pela colaboração no desenvolvimento desse trabalho e aos órgão fomentadores da pesquisa CAPES e CNPq. Referências BRADFIELD, D. J. & GAO, J. X. A methodology to facilitate knowledge sharing in the new product development process', International Journal of Production Research, 45:7, , BROWNING, T.R. & EPPINGER, S.D. Modeling impacts of process architecture on cost and schedule risk in product development. IEEE Trans. Eng. Manage., 49, , BÜYÜKÖZKAN, G; BAYKASOGLU, A. & DERELI, T. Integration of Internet and web-based tools in new product development process. Production Planning & Control, 18(1), 44 53, CHAI, K-H, XIN, Y. The application of new product development tools in industry: the case of Singapore, v. 53, n. 4., pp , CLARK, K. B. & FUJIMOTO, T. Product Development Performance: strategy, organization and management in the world auto industry. Boston, Harvard Business School Press, COOPER, R. G. Winning at New Products: Accelerating the Process from Idea to Launch. Basic Books, New York,

11 CHRISSIS, M.B.; KONRAD, M. & SHRUM, S. CMMI: guidelines for process integration and product improvement USA: Addison Wesley, COSTA, J. M. H.; ROZENFELD, H. & JUBILEU, A. P. Proposal of a Change Management Method to improve the on-demand NPD Process in Technological SMEs. In International Conference on Engineering Design, ICED 07, Cite des Sciences et de L industrie, Paris, France, august, KARLSSON, C. & ÅHLSTRÖM, P. Technological level and product development cycle time. Journal of product innovation management. 16 (4), , NIJSSEN, E. J., FRAMBACH, R. T. Determinants of the adoption of new product development tools by industrial firms, Ind, Market. Manage., v. 29, n. 2, pp , PAHL, G., BEITZ W. Engineering Design A Systematic Approach. Springer Verlag Berlin Heidelberg New York, PERNICI, B., WESKE, M. Business Process Management. Data & Knowledge Engineering 56, 1 3, PMI PROJECT MANAGEMENT INSTITUTE. A guide to the project management body of knowledge (PMBOK Guide), Third Edition, Pennsylvania, ROZENFELD et al. Gestão do processo de desenvolvimento de produtos uma referência para a melhoria do processo. São Paulo, Saraiva, SÖDERQUIST, K. E. Organising Knowledge Management and Dissemination in New Product Development. Long Range Planning 39, , SOFTWARE ENGINEERING INSTITUTE CMMI for Development, Version 1.2. < cmmi/models> (last accessed 2008), ULRICH, K. & EPPINGER, S. Product Design and Development. 3rd ed. New York, NY: McGraw-Hill VERGANTI, R. Planned flexibility - linking anticipation and reaction in product development projects. Journal of product innovation management, 16 (4), , ANEXO 1 Requisitos Grau de OpenWork Ph Php Dot Gantt Tutos Import. Bench Projekt Collab Project Planner Total 4,02 3,44 4,39 3,44 3,43 4,74 3,81 Requisitos não funcionais 7,04 6,73 8,00 8,00 8,08 8,00 6,85 Linguagem de programação Alto 3,0 3,0 3,0 3,0 3,0 3,0 3,0 Base de dados Alto 0,0 0,0 5,0 5,0 5,0 3,0 3,0 Plataforma Alto 5,0 3,0 5,0 5,0 5,0 5,0 3,0 Status Alto 5,0 5,0 3,0 5,0 5,0 5,0 3,0 Licença Alto 5,0 5,0 5,0 5,0 5,0 5,0 5,0 Custo de obtenção de licença Alto 5,0 5,0 5,0 5,0 5,0 5,0 5,0 Suporte Técnico Médio 0,0 0,0 0,0 0,0 0,0 0,0 0,0 Manual de instalação Baixo 0,6 1,0 0,6 0,6 1,0 0,6 0,6 Manual de usuário Médio 0,0 0,0 0,0 0,0 0,0 0,0 0,0 Tempo de vida do projeto Alto 5,0 5,0 5,0 3,0 3,0 5,0 5,0 Idioma Alto 3,0 3,0 5,0 5,0 5,0 5,0 3,0 Comunidade Alto 5,0 5,0 5,0 5,0 5,0 5,0 5,0 Planejamento de projeto 9,04 7,02 9,57 5,74 5,64 10,96 8,40 Visualizar agenda de determinado projeto Alto 0,0 0,0 5,0 3,0 0,0 5,0 5,0 Visualizar disponibilidade de uso de recursos Alto 5,0 5,0 5,0 0,0 0,0 5,0 5,0 Verificar compartilhamento / nivelamento de recursos Alto 5,0 5,0 3,0 0,0 0,0 5,0 0,0 Definir time de projeto Alto 3,0 3,0 5,0 0,0 0,0 3,0 3,0 Elaborar a WBS (work breakdown structure) Alto 5,0 5,0 5,0 3,0 0,0 5,0 5,0 Visualizar e formatar gráfico PERT Baixo 1,0 1,0 0,0 0,0 0,0 0,0 0,0 Visualizar e formatar gráfico GANTT Alto 5,0 5,0 3,0 5,0 3,0 3,0 3,0 Definir a seqüência das atividades Alto 5,0 5,0 5,0 3,0 3,0 5,0 5,0 Definir e visualizar níveis das atividades Alto 5,0 5,0 5,0 3,0 3,0 5,0 5,0 Definir responsaveis das tarefas Alto 3,0 0,0 5,0 5,0 5,0 5,0 3,0 11

12 Definir a data de início e término das tarefas e/ou a duração das tarefas Alto 5,0 3,0 5,0 5,0 5,0 5,0 5,0 Descrever os recursos necessários Nulo 0,0 0,0 0,0 0,0 0,0 0,0 0,0 Definir milestones Alto 5,0 5,0 5,0 0,0 3,0 5,0 5,0 Visualizar tarefas por recurso Alto 5,0 3,0 5,0 3,0 3,0 5,0 5,0 Visualizar tarefas por projeto Alto 5,0 5,0 5,0 3,0 5,0 5,0 5,0 Visualizar lista de custos por atividade Médio 0,0 0,0 0,0 0,0 0,0 0,0 0,0 Gestão de múltiplos projetos Alto 0,0 0,0 5,0 5,0 5,0 5,0 0,0 Permitir criar templates de projetos Alto 0,0 3,0 3,0 0,0 0,0 5,0 0,0 Permitir criar templates de atividades Alto 0,0 3,0 0,0 0,0 0,0 5,0 0,0 Importar projetos e tarefas Alto 5,0 0,0 3,0 0,0 0,0 5,0 5,0 Exportar projetos e tarefas Alto 5,0 0,0 0,0 0,0 3,0 5,0 5,0 Gravar linha base Médio 0,0 0,0 0,0 0,0 0,0 0,0 0,0 Verificar o andamento das atividades executadas em relação às atividades planejadas Alto 5,0 5,0 5,0 5,0 5,0 3,0 5,0 Registrar resultados de avaliação das tarefas/entregáveis Alto 0,0 0,0 3,0 3,0 0,0 3,0 0,0 Atualizar o cronograma Alto 5,0 5,0 5,0 5,0 5,0 5,0 5,0 Comunicar mudanças (eventos) aos interessados (via ) Alto 3,0 0,0 5,0 3,0 5,0 3,0 5,0 Análise de valor agregado Baixo 0,0 0,0 0,0 0,0 0,0 0,0 0,0 Gerar relatório de acompanhamento Alto 5,0 0,0 0,0 0,0 0,0 3,0 0,0 Tabela 1. Critérios de avaliação para PM Lista de Software PM ceforge.net udpviper.com/html/project.php?project=ipm Tabela 2: Lista de software sobre PM selecionados ANEXO 2 Requisitos Grau de Ez Plone Joomla Simplify import. Publish Tikiwiki Total 7,48 6,44 5,33 8,53 6,41 Requisitos Não Funcionais 8,44 8,44 2,96 8,15 8,30 Linguagem de Programação Médio 1,8 3,0 0,0 3,0 3,0 Banco de Dados Médio 1,8 1,8 0,0 3,0 1,8 Sistemas Operacionais Alto 3,0 3,0 3,0 3,0 3,0 Status Alto 5,0 5,0 5,0 5,0 5,0 Licença Alto 5,0 5,0 0,0 5,0 5,0 Custo de obtenção de licença de uso Alto 5,0 5,0 3,0 5,0 5,0 Suporte Técnico Alto 3,0 3,0 5,0 3,0 3,0 Manual de Instalação Alto 5,0 5,0 0,0 3,0 3,0 Manual de Usuário Alto 5,0 5,0 0,0 3,0 5,0 Tempo de Vida do Projeto Médio 3,0 1,8 0,0 3,0 3,0 Documentação Técnica Alto 3,0 3,0 0,0 3,0 3,0 Múltiplos usuários / permissões Alto 5,0 5,0 0,0 5,0 5,0 Gerenciamento de Conteúdo 6,52 4,43 7,70 8,91 4,52 Gerenciar (adicionar/alterar/excluir) conteúdo de diversas naturezas: file, page, link, etc Alto 5,0 3,0 5,0 5,0 5,0 Controlar Versões de Conteúdos Alto 0,0 0,0 5,0 5,0 0,0 Manter histórico de alteração Alto 0,0 3,0 5,0 5,0 0,0 Incluir Palavras-Chave por conteúdo Alto 5,0 5,0 0,0 5,0 0,0 Incluir Níveis de Prioridade por conteúdo Alto 0,0 0,0 5,0 5,0 0,0 12

13 Gerenciar Grupos de Usuários Alto 5,0 5,0 5,0 5,0 5,0 Publicar conteúdo de forma seletiva para grupos de usuários (incluindo público em geral) Baixo 1,0 1,0 1,0 0,6 1,0 Definir taxonomia para classificação de conteúdo Médio 1,8 0,0 1,8 1,8 1,8 Definir de forma flexível meta informações para cada tipo de conteúdo Alto 5,0 3,0 3,0 5,0 3,0 Submeter conteúdo ao processo de aprovação (via workflow) Revisão de Conteúdo Médio 3,0 3,0 3,0 3,0 3,0 Chek-in e check-out de conteúdo Alto 0,0 5,0 5,0 5,0 5,0 Permitir Notificação de adição/alteração/exclusão de conteúdo Médio 1,8 0,0 0,0 3,0 3,0 Visualizar conteúdo Alto 0,0 5,0 3,0 0,0 0,0 Ordenar e apresentar conteúdo com base em múltiplos critérios Alto 5,0 3,0 5,0 5,0 0,0 Associar comentários a conteúdos Alto 5,0 0,0 5,0 5,0 5,0 Associar vários conteúdos afins Referência Cruzada Alto 5,0 0,0 3,0 5,0 0,0 Recuperar conteúdo com base em múltiplos critérios Alto 5,0 3,0 5,0 5,0 5,0 Permitir Navegação entre conteúdos relacionados Alto 5,0 0,0 3,0 5,0 0,0 Interpretar XML (exportar dados em XML) Médio 1,8 0,0 0,0 0,0 0,0 Realizar backup de conteúdos Alto 3,0 0,0 5,0 5,0 3,0 Tabela 3. Critérios de avaliação para CM Lista de Software CM Tabela 4: Lista de software sobre CM selecionados ANEXO 3 Requisitos Grau de XRMS VTIGER Hipergate Tutos import. Total 7,71 9,51 7,06 6,43 Requisitos Não Funcionais 8,84 9,56 8,27 8,18 Linguagem de programação Alto 5,0 5,0 3,0 5,0 Base de dados Alto 5,0 5,0 5,0 5,0 Sistema operacional Baixo 1,0 1,0 1,0 1,0 Status Alto 5,0 5,0 5,0 5,0 Licença Médio 3,0 3,0 3,0 3,0 Custo de obtenção de licença de uso Médio 3,0 3,0 3,0 3,0 Suporte Técnico Médio 0,0 3,0 3,0 0,0 Manual de Instalação Médio 1,8 3,0 1,8 1,8 Manual de Usuário Alto 5,0 3,0 3,0 3,0 Tempo de Vida do Projeto Baixo 1,0 1,0 1,0 1,0 Idiomas Baixo 1,0 1,0 0,6 0,0 Dependência Baixo 1,0 1,0 1,0 1,0 Documentação técnica Baixo 0,0 1,0 0,0 0,0 Múltiplos usuários Alto 5,0 5,0 5,0 5,0 Comunidade Médio 3,0 3,0 1,8 3,0 Gerenciamento de Clientes 6,57 9,47 5,85 4,68 Registro de gerenciamento de clientes Alto 5,0 5,0 5,0 5,0 13

14 Gerenciamento de prospecção Alto 5,0 5,0 0,0 0,0 Gerenciamento de propostas comerciais Alto 5,0 5,0 5,0 3,0 Gerenciamento do status da proposta Alto 5,0 5,0 5,0 5,0 Gerenciamento de programação de visitas Médio 1,8 1,8 0,0 1,8 Gerenciamento de contato com clientes Alto 5,0 5,0 5,0 5,0 Registro do interesse do cliente em tipos de Alto 5,0 5,0 5,0 5,0 produtos Registro de preferências dos clientes Baixo 0,0 0,6 1,0 0,0 Histórico de consultas dos clientes Médio 0,0 1,8 0,0 0,0 Registro de modo de pagamento dos clientes Médio 0,0 3,0 0,0 0,0 Registro de on uses of proposals(amount) Alto 0,0 5,0 5,0 0,0 Registro de on uses of proposals ($) Alto 0,0 5,0 0,0 0,0 Registro de on most sold products Médio 3,0 3,0 0,0 0,0 Tabela 5. Critérios de avaliação para CRM Lista de Software CRM Tabela 6: Lista de software sobre CRM selecionados 14