Alex Sandro de Araújo Silva PROPOSTA DE UM MÉTODO PARA DEFINIÇÃO DE REQUISITOS DE SISTEMAS PLM (PRODUCT LIFECYCLE MANAGEMENT)

Transcrição

1 Tese apresentada à Pró-Reitoria de Pós-Graduação e Pesquisa do Instituto Tecnológico de Aeronáutica, como parte dos requisitos para obtenção do título de Doutor em Ciências no Programa de Pós-Graduação em Engenharia Aeronáutica e Mecânica, Sistemas Aeroespaciais e Mecatrônica. Alex Sandro de Araújo Silva PROPOSTA DE UM MÉTODO PARA DEFINIÇÃO DE REQUISITOS DE SISTEMAS PLM (PRODUCT LIFECYCLE MANAGEMENT) Tese aprovada em sua versão final pelos abaixo assinados: Prof. Luís Gonzaga Trabasso Orientador Prof. Celso Massaki Hirata Pró-Reitor de Pós-Graduação e Pesquisa Campo Montenegro São José dos Campos, SP Brasil. 2011

2 ii Dados Internacionais de Catalogação-na-Publicação (CIP) Divisão de Informação e Documentação Silva, Alex Sandro de Araújo Proposta de um método para definição de requisitos de sistemas PLM (Product Lifecycle Management)/ Alex Sandro de Araújo Silva. São José dos Campos, f. Tese de doutorado Engenharia Aeronáutica e Mecânica Sistemas Aeroespaciais e Mecatrônica Instituto Tecnológico de Aeronáutica, Orientador: Luís Gonzaga Trabasso, PhD. 1. Product Lifecycle Management. 2. Requisitos. 3. Ciclo de vida do produto. I. Comando-Geral de Tecnologia Aeroespacial. Instituto Tecnológico de Aeronáutica. Divisão de Engenharia Mecânica e Aeronáutica. II.Título REFERÊNCIA BIBLIOGRÁFICA SILVA, Alex Sandro de Araújo. Proposta de um método para definição de requisitos de sistemas PLM (Product Lifecycle Management) f. Tese de Doutorado Instituto Tecnológico de Aeronáutica, São José dos Campos. Proposta de um método para definição de requisitos de sistemas PLM (Product Lifecycle Management) CESSÃO DE DIREITOS ALEX SANDRO DE ARAUJO SILVA TÍTULO DO TRABALHO: Proposta de um método para definição de requisitos de sistemas PLM (Product Lifecycle Management) TIPO DO TRABALHO/ANO: Tese de Doutorado/ 2011 É concedida ao Instituto Tecnológico de Aeronáutica permissão para reproduzir cópias desta tese e para emprestar ou vender cópias somente para propósitos acadêmicos e científicos. O autor reserva outros direitos de publicação e nenhuma parte desta tese pode ser reproduzida sem a sua autorização (do autor). Alex Sandro de Araújo Silva Rua Francisca Maria de Jesus, 340, ap. 92 Florada de São José São José dos Campos, SP. CEP

3 iii PROPOSTA DE UM MÉTODO PARA DEFINIÇÃO DE REQUISITOS DE SISTEMAS PLM (PRODUCT LIFECYCLE MANAGEMENT) Alex Sandro de Araújo Silva Composição da Banca Examinadora: Prof. Geilson Loureiro, PhD Presidente INPE Prof. Luís Gonzaga Trabasso, PhD Orientador ITA Prof. Cristiano Ferreira Vasconcellos, Dr. UFSC Eng. Paulo de Mello Lourenção, Dr. EMBRAER Prof. (a) Ligia Soto Urbina, Dra. ITA ITA

4 iv Sou cabra da peste Eu sou cabra de uma terra que o povo padece Mas nuca esmorece, procura vencê, Da terra adorada, que a bela cabôca De riso na bôca zomba no sofrê Não nego o meu sangue, não nego meu nome, Olho para fome e pergunto: O que há? Eu sou brasilêro fio do Nordeste, Sou Cabra da Peste, sou do Ceará. Patativa do Assaré

5 v DEDICATÓRIA Dedico esse trabalho a todas as pessoas que não tiveram a oportunidade de estudar e por isso não desenvolveram todo o seu potencial como humano e intelectual. Consequentemente, estão à margem da sociedade brasileira. Tudo que tenho de bom devo ao meu estudo.

6 vi AGRADECIMENTOS Agradeço a Deus por me dar forcas e inspiração nessa jornada e a minha esposa Fernanda por me apoiar incondicionalmente nessa etapa final e até corrigir o português do trabalho. Gostaria de agradecer a muitas outras pessoas, a meu orientador Prof. Gonzaga pela paciência e sabedoria, ao Prof. Jefferson pela amizade e estímulo nos estudos de doutorado e aos demais colegas do CCM: Janaina, Zanata, Anne, Victor, Juliano, Wilson, Eguti, Borille, Guilherme, Jacson, muito obrigado a todos vocês, pois de alguma forma me ajudaram a terminar esse trabalho, seja por uma conversa de corredor, seja por um sorriso de bom dia. Afinal o que na vida vale mais? A amizade que tenho por todos vocês durará o resto de minha vida. Além disso, gostaria de agradecer a empresa SIEMENS PLM por abrir suas portas a minha pesquisa. Concedendo-me informações valiosas sobre o mercado, dificuldades encontradas, sobre o processo de implantação de seu portfólio e desafios do PLM no Brasil. Pelos diversos treinamentos que pude participar, não participei de mais treinamentos por falta de tempo. Gostaria de agradecer a todas as pessoas da SIEMENS PLM que troquei algumas palavras sobre PLM. Em especial ao Sr. Paulo Oliveira (Paulinho) e Sr. Roberto Novak que foram fundamentais para obtenção de informações sobre ferramentas, mercado e tudo que precisei saber sobre PLM. Aproveito também para agradecer a diretoria Regional do SENAI BA, na pessoa do senhor Leone Peter, por permitir a aplicação do método nos processos de negócio do SENAI CIMATEC.

7 vii RESUMO A proposta desse trabalho é desenvolver o método REQ4PLM para auxiliar empresas no processo de definição de requisitos para seleção de sistemas PLM. No método proposto, os processos do ciclo de vida do produto são modelados e analisados para identificação de stakeholders, seus interesses e indicadores de desempenho. Feito isso, o método proporciona a determinação dos diversos requisitos necessários definição de um sistema PLM por meio da modelagem em um nível de abstração satisfatório, em linguagem SysML, de um sistema sócio técnico composto por processos, software e seus usuários. Após sua a definição, o método é demostrado em um ambiente de desenvolvimento de produtos. O método desenvolvido e sua demonstração são discutidos de forma a analisar a aplicabilidade do método, vantagens e desvantagens e seu posicionamento na literatura encontrada sobre o tema. Ao final do trabalho os resultados são analisados conjuntamente aos objetivos estabelecidos inicialmente, bem como, são apresentadas sugestões para trabalhos futuros no tema abordado.

8 viii ABSTRACT The purpose of this work is to develop the REQ4PLM method that will help companies in the process of defining requirements for the selection of PLM systems. In the proposed method, the product life cycle processes are modeled and analyzed to identify stakeholders, their interests and performance indicators. After that, the method provides the determination of the various requirements definition of a PLM system by modeling a suitable level of abstraction, in SysML language, a socio-technical system composed of processes, software and its users. After its definition, the method is demonstrated in a product development environment. The method developed and its demonstration are discussed in order to analyze the method's applicability, advantages and disadvantages, and its position found in the literature on the subject. At the end of the thesis the results are analyzed together to set goals initially and are given suggestions for future work on the theme.

9 ix LISTA DE FIGURAS Figura 2-1: Mapa de valor PLM adaptado de (GRIEVES, 2006) Figura 2-2: Perspectivas abordadas na modelagem de processos Figura 2-3: Elementos do IDEF0 utilizados para identificar stakeholders Figura 2-4: Relacionamento entre requisitos e modelagem de sistemas. Adaptado de (HULL, et al., 2005) Figura 2-5: Diagrama de contexto de um sistema e interação entre funcionalidades (HULL, et al., 2005) Figura 2-6: Interseção da UML 2.0 e SysML (Fonte: (OBJECT MANAGEMENT GROUP, 2010) Figura 2-7: Taxonomia dos diagramas SysML, fonte: (OBJECT MANAGEMENT GROUP, 2010) Figura 3-1: Modelo de seleção de soluções ERP - Múltiplos filtros. Fonte: (SOUZA e SACCOL, 2008) Figura 3-2: Processo comumente encontrado para a definição de soluções PLM Figura 4-1: Representação dos componentes de um Sistema PLM e suas (adaptado de Grieves, (2006)) Figura 4-2: Sistema PLM e seus elementos: uma nova proposta Figura 4-3: Desenvolvimento do método domínio do problema e da solução Figura 4-4: Diagrama da caixa preta- mostrando a função principal do método desenvolvido Figura 4-5: Diagrama de atividades mostrando as etapas do método desenvolvido Figura 4-6: Abordagem para determinação de indicadores de desempenho do processo Figura 4-7: Processo de determinação de requisitos de implementação

10 x Figura 4-8: Exemplo de diagrama de contexto Figura 5-1: Processo de desenvolvimento de produtos Figura 5-2: Processo de Projetar do produto Figura 5-3: Processo de projetar molde Figura 5-4: Processo de planejamento da manufatura Figura 5-5: Processo de planejamento usinagem 2D Figura 5-6: Processo de planejamento usinagem 3D Figura 5-7: Mecanismo de análise de stakeholder do processo Figura 5-8: Entradas, saídas, mecanismos e controles do Ciclo de Vida do Produto e os stakeholders identificados Figura 5-9: Entradas, saídas, mecanismos e controles do processo projetar produto Figura 5-10: Entradas, saídas, mecanismos e controles do processo de projeto de moldes Figura 5-11: Estrutura de pastas e arquivos criada para gerenciar os dados do processo de desenvolvimento de produtos Figura 5-12: Entradas, saídas, mecanismos e controles do processo Planejar e Controlar manufatura Figura 5-13: Processo de determinação de indicadores de desempenho do processo Figura 5-14: Processo de determinação de requisitos dos stakeholders Figura 5-15: Diagrama de contexto para o processo >Projetar Produto< Figura 5-16: Diagrama de contexto para o processo de >Projetar Molde< Figura 5-17: Diagrama de contexto para o processo de >Planejar e Controlar Manufatura< 130 Figura 5-18: Diagrama de contexto para o processo >Projetar Produto< acrescido do fluxo de informação Figura 5-19: Diagrama de contexto para o processo >projetar molde< acrescido do fluxo de informação

11 xi Figura 5-20: Diagrama de contexto para o processo >Planejar e controlar manufatura< acrescido do fluxo de informação Figura 5-21: Diagrama de Casos de uso Figura 5-22: Diagrama de blocos representando a estrutura do sistema Figura 5-23: Requisitos determinados para PLM Figura 7-1: Modelo BPMN do fluxo de dados no processo de desenvolvimento de produtos

12 xii LISTA DE QUADROS Quadro 1-1: Estímulos ao surgimento do conceito PLM fonte: (AMERI e DUTTA, 2004; GRIEVES, 2006) Quadro 1-2: Situações relevantes para diferentes estratégias de pesquisa. FONTE: YIN (2005) Quadro 1-3: Conteúdo dos capítulos 2 e Quadro 1-4: Conteúdo do capítulo Quadro 1-5: Conteúdo dos capítulos 5 e Quadro 1-6: Conteúdo do capítulo Quadro 2-1: Estágios do ciclo de vida segundo a ISO/IEC 15288: Quadro 2-2: Definição de termos importantes, fonte: (ISO, 2008; TECHNICAL BOARD INTERNATIONAL COUNCIL ON SYSTEMS ENGINEERING (INCOSE), 2010; FREEMAN, 1984) Quadro 3-1 Análise sinótica dos trabalhos existentes relacionados ao auxilio a implementação PLM Quadro 4-1: Mapear e modelar processos Quadro 4-2: Exemplo de análise realizado em stakeholders do processo de mudanças de engenharia Quadro 4-3: Analisar de stakeholders Quadro 4-4: Definir Indicadores de Desempenho Quadro 4-5: Determinar Requisitos para o sistema PLM Quadro 5-1: Ferramentas PLM (CAD/CAM/CAE) utilizados no DPI Quadro 5-2: Planilha típica usada para registrar as modificações realizadas no produto durante seu desenvolvimento

13 xiii Quadro 5-3: Análise de stakeholders identificados nos processos analisados Quadro 5-4: Aplicação do método para criação de indicadores Quadro 5-5: Requisitos obtidos com o método Quadro 6-1: Analise do método desenvolvido em aplicado em ambiente de desenvolvimento de produtos SENAI-CIMATEC Quadro 6-2: Análise sinótica dos trabalhos existentes relacionados ao auxilio a implementação PLM e a contribuição dado pelo desenvolvimento desse trabalho Quadro 7-1: Relação entre perguntas de pesquisa, objetivos e resultados alcançados

14 xiv LISTA DE ABREVIATURAS E SIGLAS ABNT Associação Brasileira de Normas Técnicas. BDD Block Definition Diagram BPMN Business Process Modeling and Notation CAD Computer Aided Design CAE Computer Aided Engineering CAM Computer Aided Manufacturing CASE Computer Aided Software Engineering CCM Centro de Competência em Manufatura CIM Computer Integrated Manufacturing CIMATEC Centro Integrado de Manufatura e Tecnologia CN Controle Númerico CRM Customer Relationship Management EIA - Energy Information Administration EPC - Event Driven Process Chain ERP Enterprise Resource Planning ES Engenharia de Sistemas FNQ Fundação Nacional da Qualidade IBD Internal Block Diagram IDEF0 - Integration Definition for Function Modeling IEC International Electrotechnical Commission INCOSE International Council on Systems Engineering ISO International Organization for Standardization KPI Key Performance Indicator

15 xv NASA - National Aeronautics and Space Administration NIST National Institute of Standards and Technology OMG Object Management Group PDM Product Data Management PERISCOPE PERformance Indicator Scope PKGD Package Diagram PLM Product Lifecycle Management REQ4PLM Requirements for PLM REQD Requirements Diagram ROA - Return On Assets ROI Return On Investment SCM - Supply Chain Management SE Systems Engineering SYSML System Modeling Language TAPP Turbina Aeronáutica de Pequena Potencia TI Tecnologia da Informação UCD Use Case Diagram UML Unified Modeling Language XPDL XML Process Definition Language IGES - Initial Graphics Exchange Specification DWG AutoCAD TM DraWinG SLDPRT SoLiDworks PaRt

16 xvi SUMÁRIO RESUMO... vii ABSTRACT... viii 1. INTRODUÇÃO JUSTIFICATIVA E MOTIVAÇÃO OBJETIVOS GERAL E ESPECÍFICO CONTRIBUIÇÃO DO TRABALHO ABORDAGEM DO TRABALHO METODOLOGIA DA PESQUISA E ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA PRODUCT LIFECYCLE PRECURSORES DO PLM PRODUCT LIFECYCLE MANAGEMENT COMPUTER AIDED DESIGN, MANUFACTURING e ENGINEERING (CAD/CAM/CAE) COMPUTER INTEGRATED MANUFACTURING - CIM PRODUCT DATA MANAGEMENT - PDM ERP, CRM, SCM PLM PRODUCT LIFECYCLE MANAGEMENT GERENCIAMENTO POR PROCESSOS MAPEAR PROCESSOS MODELAR PROCESSOS MÉTODOS DE MODELAGEM DE PROCESSOS INDICADORES DE DESEMPENHO E GERAÇÃO DE VALOR IMPORTÂNCIA DE INDICADORES PARA O GERENCIAMENTO POR PROCESSOS MÉTODOS PARA MEDIR A MELHORIA COM IMPLANTAÇÃO DE PLM ATRIBUTOS PARA UM BOM INDICADOR ANÁLISE DE STAKEHOLDERS IDENTIFICAÇÃO DE STAKEHOLDERS ANÁLISE DE NECESSIDADES DE STAKEHOLDERS PROCESSO DE ENGENHARIA DE SISTEMAS PROCESSO DE ENGENHARIA DE REQUISITOS MODELAGEM DE SISTEMAS SYSTEM MODELING LANGUAGE SYSML ABORDAGENS EXISTENTES PARA PLM ABORDAGENS CONSULTADAS NA LITERATURA ABORDAGEM ENCONTRADA NA INDÚSTRIA... 80

17 xvii 4. DESENVOLVIMENTO DO MÉTODO REQ4PLM ETAPA I MAPEAR E MODELAR PROCESSOS ETAPA II ANALISAR STAKEHOLDERS ETAPA III DEFINIR INDICADORES DE DESEMPENHO ETAPA IV DETERMINAR REQUISITOS PARA O SISTEMA PLM DEMOSTRAÇÃO DO MÉTODO REQ4PLM FERRAMENTA COMPUTACIONAL UTILIZADA DEPARTAMENTO DPI E A INFRAESTRUTURA PLM EXISTENTE MAPEAR E MODELAR PROCESSOS ANALISAR STAKEHOLDERS PROCESSO PROJETAR PRODUTO PROCESSO PROJETAR MOLDE PROCESSO PLANEJAR E CONTROLAR MANUFATURA DEFINIR INDICADORES DE DESEMPENHO DETERMINAR REQUISITOS MODELAGEM DE DIAGRAMAS DE CONTEXTO MODELAGEM DE DIAGRAMAS DE CASOS DE USO E DIAGRAMA DE BLOCOS MODELAGEM DE DIAGRAMA DE REQUISITOS DISCUSSÃO DO MÉTODO REQ4PLM VANTAGENS, DESVANTAGENS E APLICABILIDADE DO MÉTODO DIFICULDADES PARA APLICAÇÃO DO MÉTODO COMPARAÇÃO E POSICIONAMENTO DO MÉTODO PROPOSTO A LITERATURA ENCONTRADA CONCLUSÕES E SUGESTÕES PARA TRABALHOS FUTUROS CONCLUSÕES SUGESTOES PARA TRABALHOS FUTUROS REFERÊNCIAS ANEXOS...166

18 18 1. INTRODUÇÃO Esta tese aborda as etapas iniciais de implementação de sistemas PLM (Product Lifecycle Management) em organizações de desenvolvimento de produto, mais especificamente entre a tomada de decisão por usar sistemas PLM e a definição de quais funções esse sistema precisa apresentar para satisfazer as necessidades dos processos organizacionais e de seus stakeholders. Para elicitar essas funções, é desenvolvida nessa tese uma abordagem sistemática para a elaboração dos requisitos que o sistema PLM deverá atender. O Gerenciamento do Ciclo de Vida do Produto ou Product Lifecycle Management PLM é uma abordagem estratégica, cujas informações sobre produtos e processos são usadas para reduzir desperdícios (tempo, materiais e energia) e aumentar a eficiência organizacional ao longo do ciclo de vida dos produtos (GRIEVES, 2006). Essa estratégia de negócios popularizou-se em diversas indústrias, tais como, aeroespacial e defesa, automotiva, bens de consumo duráveis, entre outras, fazendo o mercado de PLM ter um faturamento aproximado de US$ 20 bi em 2012 (HOJLO, et al., 2008) quando em 2002 era de pouco mais de US$ 2 bi (CIMDATA, 2003). Este capítulo apresenta a justificativa e motivação para o desenvolvimento do trabalho, os objetivos gerais e os específicos. Além disso, a contribuição do trabalho é apresentada de forma sucinta, como também, a abordagem do trabalho e a metodologia de pesquisa adotada. Por fim, a estrutura da tese é resumida e apresentada ao leitor. 1.1 JUSTIFICATIVA E MOTIVAÇÃO A atual conjuntura econômica exige cada vez mais das empresas, uma postura de redução de custos e melhoria da qualidade no desenvolvimento dos produtos e serviços oferecidos aos consumidores. Contudo, estima-se que cerca de 60% 80% do tempo de

19 19 trabalho de um time de desenvolvimento de produto são usados em tarefas que agregam pouco valor ao produto (GRIEVES, 2006). Do mesmo modo, estudos recentes (COMMISSION OF THE EUROPEAN COMMUNITIES UNDER ESPRIT PROGRAMME, 2008) indicam que os engenheiros de uma empresa, constantemente, executam atividades que não estão diretamente relacionadas à engenharia: 11% do tempo de um engenheiro é gasto com atividades de engenharia e criatividade; 34% em atividades administrativas; 31% em comunicação; 24% em espera por aprovações, decisões gerenciais e informação. Nas empresas, é comum copiar dados (contidos em planilhas, arquivos CAD/CAM/CAE e documentos em geral) de produto para realizar uma tarefa específica. Seja para enviar a um fornecedor uma especificação sobre o produto, seja para enviar a um especialista a representação matemática do produto como o objetivo de construir modelos de simulação CAE (Computer Aided Engineering). Contudo, quando alguém copia dados e os envia para um fornecedor, esses dados podem ficar desatualizados e consequentemente ocasionar problemas diversos, tais como: Desperdícios de tempo do fornecedor ou da empresa contratante em reconciliar dados nas versões existentes; Desperdícios de material e energia, por exemplo, quando o produto inclui atividades de manufatura, considerando informações que não estavam atualizadas e consequentemente não condizem com o projeto que foi desenvolvido pela empresa. Silva e Trabasso (2009) abordam esse problema no contexto do desenvolvimento de produtos complexos exemplificado por um motor a jato. Nesse trabalho, os autores relatam

20 20 a existência de quantidade considerável de retrabalho nesse ambiente, onde não existe controle sobre as versões dos dados de engenharia. Para tratar dos problemas relacionados a esse cenário, o conceito PLM surgiu no inicio da década de Naquela época, essa abordagem encapsulava além dos aspectos de engenharia (dados de produto e processos de engenharia), bastante comuns em 1990, os aspectos relacionados a uma plataforma compartilhada para criação, organização e disseminação de conhecimentos relacionados ao produto, por toda a empresa e ao longo de todo seu ciclo de vida. Neste período, existiam vários estímulos que propiciaram o surgimento desse conceito (AMERI e DUTTA, 2004; GRIEVES, 2006). Esses estímulos são mostrados no Quadro 1-1. Quadro 1-1: Estímulos ao surgimento do conceito PLM fonte: (AMERI e DUTTA, 2004; GRIEVES, 2006) Estímulos ao surgimento do conceito PLM Internos Necessidade de inovação dos produtos e consequentes ganhos de market share Conhecimento sobre anseios dos clientes Excelência nas operações Colaboração global Melhoria da qualidade Externos Globalização dos mercados Customização em massa e escala de produção Complexidade dos produtos Prolongamento no ciclo de vida do produto e redução do ciclo de desenvolvimento Restrições e necessidades da cadeia de fornecimento Regulamentação ambiental e sanitária Os estímulos apresentados podem ser relacionados a características da tecnologia e métodos de trabalho relacionados ao conceito PLM que é veiculado na indústria e está presente em pesquisas sobre o gerenciamento do processo de desenvolvimento de produto. Alguns exemplos são apresentados para ilustrar essa relação, posicionando a abordagem PLM como elemento chave para esses projetos:

21 21 A necessidade por Colaboração Global foi o catalisador para o desenvolvimento da tecnologia da informação, que permitiu aos times de projetos poderem atuar não obstante estarem fisicamente espalhados por diversos países, como é o caso do projeto Joint Strike Fighter (JSF, 2006). A necessidade de inovação motivou o desenvolvimento da Plataforma PROPHECY (WRIGHT, 2010) usada no planejamento pré-operatório para implantação de próteses de joelho. PLM é uma abordagem que pode auxiliar as empresas a resolver os problemas relacionados ao acesso a dados e informações sobre seus produtos. Ainda segundo Abramovici (2007), PLM não é simplesmente o uso de software para automatizar os processos ao longo do ciclo de vida do produto, mas aborda um conjunto consistente de métodos, modelos e ferramentas de Tecnologia da Informação (TI) para o gerenciamento de processos, informações e ferramentas relacionadas ao produto. Entretanto, em virtude de envolver conceitos relativamente novos como gestão por processos, engenharia colaborativa e modelagem de negócios, para algumas empresas, os resultados da adoção dessa abordagem não têm apresentado resultados tão expressivos (RANGAN et al., 2008). Essa limitação pode ser atribuída, em parte, às estruturas funcionais que ainda existem nas empresas, à quase inexistência de gerenciamento por processos e à dificuldade em implantar as tecnologias (ferramentas/ software) utilizadas na abordagem PLM (SCHUH et al., 2008). Na indústria, mesmo com a disponibilidade de modelos de referência de projetos para alguns setores e com o desenvolvimento de novos métodos de gestão do ciclo de vida, por exemplo, observa-se que a maior parte das implantações de PLM ainda está em um estágio inicial (ZANCUL, 2009). Grande parte das implantações enfatizam apenas aspectos parciais, como de gestão de documentos de engenharia, sem a perspectiva ampla necessária

22 22 para a gestão do ciclo de vida completo (ZANCUL, 2009). Ainda segundo Zancul (2009), muitas empresas restringem essas iniciativas ao projeto de implantação de sistemas de TI, sem a necessária ênfase na abordagem PLM como um todo. Além disso, PLM é necessariamente um sistema com uma complexidade considerável (LOUREIRO, 1999), pois envolve pessoas (usuários, fornecedores podendo chegar aos milhares de pessoas) que por sua vez têm diversas necessidades, processos de negócio realizados ao longo do ciclo de vida do produto e tecnologias que suportam esses processos (GRIEVES, 2006). Contudo a abordagem adotada na implantação (definição tecnológica e de fornecedores) mostrada por Zancul (2009) define os requisitos de maneira superficial e insuficiente para garantir consistência no que se refere à definição do problema e do que o sistema deve fazer para atender as necessidades dos diversos stakeholders interessados ou mesmo afetados pela aquisição/implantação de um sistema para o gerenciamento do ciclo de vida de produtos. 1.2 OBJETIVOS GERAL E ESPECÍFICO A apresentação e análise da justificativa e motivação do trabalho apresentados na seção 1.1, induzem as seguintes perguntas de pesquisa: 1. Como as empresas podem selecionar requisitos para sistemas PLM de uma forma holística, considerando os aspectos sociotécnicos envolvidos, stakeholders, tecnologia e processos do ciclo de vida do produto? 2. Como garantir que os requisitos estejam relacionados às necessidades dos stakeholders, restrições, metas e objetivos do negócio? Considerando essas perguntas, o objetivo geral dessa tese é propor um método de geração de requisitos para sistemas PLM baseado nos processos do ciclo de vida do produto e seus stakeholders.

23 23 Para a consecução do objetivo geral, foram estabelecidos os objetivos específicos seguintes: Desenvolver o método baseado em ferramentas de análise de stakeholders e de requisitos existentes; Aplicar o método desenvolvido em uma organização de desenvolvimento do produto; Discutir os benefícios do método frente a outras soluções da literatura ou da indústria. 1.3 CONTRIBUIÇÃO DO TRABALHO Os sistemas de informação necessitam de avaliação antes e após sua implantação no ambiente de negócios para garantir que os objetivos estabelecidos sejam, de fato, alcançados. Segundo Eriksson e Penker (2000), é comum chegar à conclusão de que esses sistemas não suportam apropriadamente o negócio em que eles estão inseridos. Ainda segundo esses autores, existem várias razões para isso. Por exemplo, a especificação de requisitos não é realizada de forma correta, o time de implantação não entende satisfatoriamente o negócio ou não entende as mudanças que acontecem tão frequentemente no mercado. Para tanto, diversos métodos foram criados para estruturar o processo de implantações de soluções de TI nas empresas (ERIKSSON e PENKER, 2000). Os métodos desenvolvidos nos trabalhos analisados nos estudos bibliográficos realizados nesse trabalho são variações, em menor ou maior grau, de métodos de auxílio à implantação de sistemas ERP. Além disso, os métodos analisados estão direcionados para selecionar o aplicativo de software desconsiderando o fato de um sistema de informação, especificamente PLM, é de fato um sistema intrinsecamente complexo. A proposta desse trabalho é desenvolver o método REQ4PLM que auxilie as empresas no processo de implantação de sistemas PLM. Diferentemente dos métodos

24 24 analisados, REQ4PLM não está relacionado a somente a fase de seleção de software, mas a todo o ciclo de vida de um sistema PLM, fornecendo requisitos e indicadores para Definição, Implantação e Manutenção de sistemas PLM. Esses requisitos definem o que o sistema deve fazer para atender as necessidades dos stakeholders identificadas pelo método, bem como, os indicadores que medem o atendimento dessas necessidades. Nele, os processos do ciclo de vida dos produtos são modelados e analisados. Feito isso, os stakeholders dos processos são identificados e analisados, em consonância com a modelagem de indicadores de desempenho para medir a satisfação dos stakeholders. Os processos e as necessidades dos stakeholders identificados são usados para a determinação dos diversos requisitos necessários à implantação de um sistema PLM. 1.4 ABORDAGEM DO TRABALHO A abordagem deste trabalho refere-se aos setores de manufatura de bens duráveis e de bens de capital produzidos em série. Destarte, espera-se que o método desenvolvido seja aplicado nas indústrias aeroespacial, automotiva e de eletroeletrônicos. Esse trabalho de doutorado foi desenvolvido no Centro de Competência em Manufatura do Instituto Tecnológico de Aeronáutica e no Centro Integrado de Manufatura e Tecnologia em Salvador BA, ambas as instituições entidades atuam nas áreas apresentadas. Destaca-se também a carência de pesquisa nacional sobre o tema. As especificidades apresentadas não impedem que o método e os resultados sejam aplicados em outras indústrias de manufatura com as devidas modificações e adequações, por exemplo, sistemas para gerenciamento de ativos na indústria de processos. O método desenvolvido pressupõe a utilização da abordagem de Engenharia de Sistemas, que analisa o problema de forma ampla e holística, possibilitando a análise em um mesmo framework, os diversos aspectos sócio técnicos presentes na adoção de uma nova abordagem de negócios, como PLM. Esses aspectos são relacionados aos usuários da

25 25 infraestrutura PLM (stakeholders), a tecnologia e suas funcionalidades e os processos de negócios executados. 1.5 METODOLOGIA DA PESQUISA E ESTRUTURA DO TRABALHO A seleção do instrumental metodológico, de acordo com Marconi e Lakatos (1991) relaciona-se diretamente com o problema a ser estudado; a escolha depende dos vários fatores relacionados com a pesquisa, ou seja, a natureza dos fenômenos, o objeto da pesquisa, os recursos financeiros, a equipe humana e outros elementos que possam surgir no campo da investigação. Os métodos e as técnicas devem adequar-se ao problema a ser estudado, ao tipo de respondentes com quem se vai entrar em contato. Assim, em função dos fatores próprios dessa pesquisa, foram escolhidas as estratégias de pesquisa aplicáveis à tese. Para o desenvolvimento do método foram adotadas as estratégias de Pesquisa Bibliográfica. Para demonstrar o método e discutir os resultados, ele foi aplicado em uma empresa cujas características são representativas no contexto industrial e acadêmico. Segundo Yin (2005), a primeira e mais importante condição para se diferenciar as várias estratégias de pesquisa é identificar, nela, o tipo de questão de pesquisa apresentada. Um esquema básico de categorização pode ser representado pela série: >quem<, >o que<, >onde<, >como< e >por que<, conforme ilustrado pelo Quadro 1-2. Nele são mostradas diferentes estratégias de pesquisa e os tipos de questões que essa estratégia pode auxiliar a responder, além de exigências sob o controle e foco contemporâneos dos eventos.

26 26 Quadro 1-2: Situações relevantes para diferentes estratégias de pesquisa. FONTE: YIN (2005). Estratégia Forma da questão da Exige controle Focaliza pesquisa sobre eventos acontecimentos comportamentais? contemporâneos? Experimento Como, por que Sim Sim Levantamento Quem, o que, onde, Não Sim quantos, quanto Análise de arquivos Quem, o que, onde, Não Sim / não quantos, quanto Pesquisa histórica Como, por que Não Não Estudo de caso Como, por que Não Sim A pesquisa constituiu de quatro fases descritas como se segue: Fase #1 Revisão da Literatura e Levantamento da abordagem de pesquisa. A pesquisa bibliográfica, ou de fontes secundárias, é desenvolvida, abrangendo o material público referente ao tema de estudo (MARCONI e LAKATOS, 1991). A finalidade dessa fase foi colocar o pesquisador em contato direto sobre o que foi publicado a respeito desse assunto, bem como, buscar uma definição precisa dos contornos do problema estudado. A pesquisa bibliográfica foi realizada considerando os assuntos pertinentes à criação do método, sejam eles: Processo de engenharia de requisitos; Processo de engenharia de sistemas; Modelagem de sistemas Identificação e modelagem de processos; Tecnologia PLM; Abordagens existentes para implantação de sistemas PLM. O resultado dessa etapa é apresentado nos Capítulos 2 e 3, cujos conteúdos são apresentados no Quadro 1-3.

27 27 Fase #1 Capítulo 2 Fundamentação Teórica 2.1. Product lifecycle Precursores do PLM Product Lifecycle Management PLM Product Lifecycle Management Gerenciamento por processos 2.5. Indicadores de desempenho e geração de valor Análise de stakeholders 2.7. Processo de engenharia de sistemas Processo de engenharia de requisitos Modelagem de sistemas. Capítulo 3 Abordagens existentes para PLM 3.1. Abordagens consultadas na Academia Abordagem encontrada na Indústria. Quadro 1-3: Conteúdo dos capítulos 2 e 3 Fase #2 Desenvolvimento do método proposto. Esse método foi elaborado a partir da pesquisa bibliográfica sobre o assunto (Fase#1) e a identificação de evidências na indústria por meio de entrevistas com especialistas e documentos coletados nesse ambiente. O resultado dessa fase é apresentado no Capítulo 4, cujos conteúdos são apresentados no Quadro 1-4.

28 28 Fase #2 Capítulo 4 Desenvolvimento do Método REQ4PLM 4.1. Mapear e modelar processos 4.2. Analisar stakeholders Definir indicadores de desempenho Determinar requisitos para osistema PLM. Quadro 1-4: Conteúdo do capítulo 4 Fase #3 Demonstração e discussão de resultados para avaliar o método proposto. A demonstração do método foi realizada por meio da aplicação do método em situações reais de utilização e com isso foi possível obter informações sobre dificuldades de aplicação, pontos de melhoria e a pertinências dos resultados da aplicação. A demonstração do método é apresentada nos capítulos 5 e 6, cujos conteúdos são mostrados no Quadro 1-5. Fase #3 Capítulo 5 Demonstração do Método 5.1. Ferramentas Computacionais utilizadas para a demonstração do método Departamento DPI e a Infraestrutura PLM existente Mapear e modelar processos Analisar stakeholders Definir indicadores Determinar requisitos. Capítulo 6 Discussão sobre o método 6.1. Vantagens, desvantagens e aplicabilidade do método Dificuldades para aplicação do método Comparação e posicionamento do método proposto à literatura encontrada. Quadro 1-5: Conteúdo dos capítulos 5 e 6 Ao final do trabalho (Capítulo 7), os resultados alcançados com o desenvolvimento do método, são analisados de modo confirmar a consecução dos objetivos,

29 29 listar as limitações da abordagem desenvolvida, bem como, sugerir novos trabalhos no tema. O conteúdo desse capítulo é mostrado no Quadro 1-6. Capítulo 7 Conclusão 7.1 Resultados do trabalho. 7.2 Sugestões para outros trabalhos. Quadro 1-6: Conteúdo do capítulo 7

30 30 2. FUNDAMENTAÇÃO TEÓRICA proposto no trabalho. Nesse capitulo é apresentada a fundamentação teórica para elaboração do método 2.1 PRODUCT LIFECYCLE Todo produto concebido pela mente humana possui um ciclo de vida, mesmo que ele não seja formalmente definido. Segundo a norma ISO/IEC (2008, p.10), o ciclo de vida de um sistema varia de acordo com a natureza, propósito, uso e circunstancias intrínseco a cada sistema. Todo estágio tem propósito e contribuição distinta para o ciclo de vida e deve ser considerado em seu planejamento e execução. Assim, os estágios fornecem às organizações um framework em que o gerenciamento tem um alto nível de visibilidade e controle de processos relacionados ao ciclo de vida de um produto. Essa norma estabelece sete estágios genéricos do ciclo de vida de um produto apresentados no Quadro 2-1. Quadro 2-1: Estágios do ciclo de vida segundo a ISO/IEC 15288: 2008 Estágio Propósito Pesquisa exploratória Identificar as necessidades dos stakeholders Explorar ideias e tecnologias Conceito Refinar as necessidades dos stakeholders; Explorar conceitos factíveis; Propor soluções viáveis; Desenvolvimento Refinar requisitos do sistema; Criar a descrição da solução; Construir o sistema; Verificar e validar o sistema; Produção Produzir sistemas; Inspecionar e verificar os sistemas; Utilização Operar o sistema para satisfazer as necessidades dos usuários; Suporte Fornecer a capacidade de manter o sistema em serviço; Retirada do mercado Coletar e descartar o sistema de forma apropriada.

31 31 Ainda, segundo o INCOSE International Council of Systems Engineering o proposito em definir o ciclo de vida de um sistema está em estabelecer um framework para o atendimento das necessidades dos stakeholders de uma maneira ordenada e eficiente (INCOSE, 2011). Com a caracterização do ciclo de vida em fases, é possível obter informações pertinentes sobre desejos dos stakeholders, requisitos e riscos potenciais, para que o sistema concebido obtenha sucesso, os riscos sejam mitigados ou extintos e os requisitos e desejos dos stakeholders sejam atendidos. 2.2 PRECURSORES DO PLM PRODUCT LIFECYCLE MANAGEMENT Antes de analisar o conceito PLM, pode-se ponderar a respeito de sistemas precursores que influenciaram conceitualmente ou tecnologicamente o conceito de PLM como se apresenta atualmente. Os principais precursores do PLM são listados e detalhados em seguida. Computer Aided Design (CAD), Computer Aided Manufacturing (CAM), Computer Aided Engineering (CAD), Computer Integrated Manufacturing (CIM), Product Data Management (PDM) COMPUTER AIDED DESIGN, MANUFACTURING e ENGINEERING (CAD/CAM/CAE) O termo Computer Aided Design (CAD), no vocabulário de engenharia, refere-se à descrição matemática de produtos. Esta representação utiliza um sistema computacional para desenvolver, consistentemente, formas geométricas em duas e três dimensões. Esses sistemas iniciaram como sistemas de auxilio às atividades de desenho mecânico 2D e auxiliavam aos projetistas detalharem os projetos de uma maneira rápida e precisa,

32 32 consequentemente, o nome projeto >auxiliado< por computador (Computer Aided Design). Entretanto, os sistemas CAD rapidamente ganharam funcionalidades que os transformaram de simples sistemas periféricos de auxílio a projeto, em sistemas fundamentais para definição de produtos. Simultaneamente ao desenvolvimento de sistemas CAD, os sistemas CAM e CAE, respectivamente, Computer Aided Manufacturing e Computer Aided Engineering foram desenvolvidos e ganharam diversas funcionalidades ao longo dos anos. A partir dos modelos criados pelos sistemas CAD, o computador pode ser usado para realizar simulações de engenharia, que podem envolver disciplinas como: tensão/deformação, transferência de calor, acústica e eletromagnetismo. Os aplicativos computacionais que realizam essas simulações são denominados CAE. Os sistemas CAM utilizam o modelo geométrico criado em um sistema CAD para elaborar, por exemplo, rotinas de usinagem, trajetórias de ferramentas e simulação de usinagem COMPUTER INTEGRATED MANUFACTURING - CIM A primeira tentativa de integrar ferramentas digitais para desenvolvimento do produto sob uma mesma denominação foi o conceito de Computer Integrated Manufacturing (CIM) (KIMBLE e PRABHU, 1988). A manufatura Integrada por computador (CIM) tem uma extensa história e foi reconhecida desde cedo pela promessa de compartilhar informação entre áreas funcionais de uma empresa. Especificamente, os dados e informações de engenharia poderiam ser transferidos e utilizados pela produção em formato eletrônico. O conceito CIM defendia a ideia de que um sistema de computador poderia integrar as funções necessárias à concepção, engenharia e fabricação de um produto (GRIEVES, 2006; RILEY e COX, 1998).

33 33 Isso ampliou o conceito de fabricação assistida por computador (CAM), que tinha uma premissa muito mais simples de usar descrições matemáticas baseada em CAD para gerar programas de controle numérico (CN) (que são os programas que controlam as ações da fabricação em máquinas automáticas). Em sua forma avançada, as ferramentas CAM definiam a sequencia de máquinas ou mesmo o fluxo de matérias para fabricar um produto. No entanto, as ferramentas CAM estavam relacionadas à manufatura de um único produto, enquanto CIM explicitava uma visão mais ampla de todos os produtos de uma organização, as instalações e recursos de produção (GRIEVES, 2006). Além disso, o design e a engenharia, muitas vezes desenvolvem características de produto que não são manufaturáveis. Esperava-se que com aplicações do CIM, o design e os dados de engenharia seriam usados diretamente para coordenar as máquinas e o processo de produção no chão de fábrica (RILEY e COX, 1998) No entanto, segundo Grives (2006) a solução CIM nunca atingiu seus objetivos e é sempre reconhecida por isso (SCHUH, et al., 2008; GRIEVES, 2006). As tecnologias computacionais disponíveis na época não estavam à altura da tarefa a elas atribuída, assim o conceito CIM foi limitada na sua aplicação. Além disso, a CIM foi de certo modo mais ampla do que o PLM, porque englobava também os conceitos de Enterprise Resource Planning (ERP) e Supply Chain Management (SCM) (GRIEVES, 2006) PRODUCT DATA MANAGEMENT - PDM Os sistemas PDM (Product Data Management) surgiram durante a década de 1980 para controlar e gerenciar informações sobre produto criadas em ferramentas CAD, CAM e CAE (authoring tools) (AMERI e DUTTA, 2004). A necessidade por acesso fácil, rápido e seguro para validar dados era a maior justificativa para os desenvolvimentos relacionados à PDM com uma solução mais disciplinada e dedicada a controlar dados. A funcionalidade principal dos primeiros sistemas PDM, portanto, era prover os usuários com os

34 34 dados requeridos com um único servidor de dados e manter a validade e integridade dos dados, apesar deles estarem sendo continuamente atualizados, bem como controlar a forma com que as pessoas criam e modificam os dados de produto. Com o tempo, as soluções PDM expandiram-se para incluir funcionalidades adcionais, tais como, gerenciamento de mudanças, gerenciamento de fluxos de trabalho e gerenciamento de projetos, mantendo a promessa de promover a engenharia simultânea e o fluxo dos processos de negócio na empresa. Apesar do sucesso na área de engenharia, a primeira geração de sistemas PDM não atendia às demandas de outras áreas funcionais nas empresas, como por exemplo, vendas, marketing, finanças e cadeia de fornecedores. De acordo com Ameri e Dutta (2004), as duas maiores restrições à expansão na aplicação de soluções PDM foram: Escopo limitado, em termos de dados e os usuários a serem atendidos; Dificuldade no uso das soluções. A informação gerenciada pelos primeiros sistemas PDM eram limitadas a informações de engenharia porque eles eram desenvolvidos no início, para suportar e complementar sistemas CAD/CAM/CAE. Além disso, trabalhar com sistemas PDM não era simples e usualmente demandavam de conhecimentos em engenharia. Dessa forma, os primeiros sistemas PDM eram aplicações tipicamente internas, acessíveis somente para engenheiros de produto, manufatura e banco de dados. Os agentes externos, tais como, fornecedores e clientes não possuíam acesso aos serviços dos sistemas PDM. Para melhorar a facilidade no uso e expandir o escopo do PDM para abranger usuários externos, os fornecedores de sistemas PDM começaram a oferecer sistemas integrados à internet com ferramentas de visualização mais adequadas durante a década de Entretanto, a funcionalidade principal permanecia centrada simplesmente em aspectos de engenharia do negócio porque a informação e o paradigma de modelagem de sistemas

35 35 PDM eram baseados numa visão de engenharia, e, por conseguinte, incapaz de ir além desse domínio. Por exemplo, os clientes não podiam configurar e comprar produtos customizados usando sistemas PDM ou o gerente de compras não podia encontrar informações sobre os componentes de preços e as opções de fornecimento em sistemas PDM. Nessa época, além de sistemas PDM existiam outros sistemas corporativos disponíveis para as empresas. Esses sistemas são apresentados no tópico seguinte ERP, CRM, SCM Quase que simultaneamente à evolução dos sistemas PDM, a primeira onda de aplicações corporativas tais como Enterprise Resource Planning (ERP), Customer Relationship Management (CRM) e Supply Chain Management (SCM) introduziram no mercado uma variedade de produtos que estavam preocupados e prover uma maior racionalização e melhoria das práticas de negócio (GRIEVES, 2006). Apesar de essas aplicações melhorarem consideravelmente a eficiência e a eficácia da comunicação entre vários agentes durante o ciclo de vida do produto e apresentarem resultados significativos em comparação ao PDM, elas pouco melhoraram as funções dedicadas ao desenvolvimento de produtos. Portanto, aplicações tais como ERP eram tradicionalmente direcionadas para controlar as transações do negócio ao invés de suportar inovação e criatividade no processo de desenvolvimento de novos produtos. Adicionalmente, aplicações como ERP dependem profundamente de modelos estruturados de dados. Por exemplo, lista de materiais (BOM Bill Of Materials) em processo, busca de informação, monitoramento de processo, elaboração de relatório de custo e planejamento de recursos (AMERI e DUTTA, 2004). Os conceitos referentes ao ciclo de vida do produto e as tecnologias precursoras ao PLM foram apresentadas e discutidas. Com isso, pode-se introduzir o conceito PLM e

36 36 contextualiza-lo dentro de um ambiente industrial e de desenvolvimento de novos produtos. Essa introdução é feita na próxima seção. 2.3 PLM PRODUCT LIFECYCLE MANAGEMENT A produtividade nas organizações sempre foi desafiada por novos paradigmas, desde a primeira revolução industrial na Inglaterra no final do século XVIII ao Sistema Toyota de Produção no Japão pós 2ª. Guerra mundial (WOMACK, et al., 2007). Atualmente, segundo alguns autores, (GRIEVES, 2006; SAAKSVUORI e IMMONEN, 2008), o Gerenciamento do Ciclo de Vida do Produto - Product Lifecycle Management (PLM) é uma alternativa estratégica para aumentar a eficiência na execução dos processos do ciclo de vida do produto adotada por muitas organizações. Entretanto, debatendo-se com consultores nacionais de PLM e empresas desenvolvedoras de tecnologia para PLM, observa-se que a perspectiva das empresas nacionais interessadas nessa abordagem é a de simplesmente adquirir novas ferramentas para realizar os processos atuais. Contudo, a aquisição de novas ferramentas pode, na verdade, dificultar a realização do trabalho se nenhuma atenção for dada aos processos existentes e às pessoas que utilizarão essas ferramentas (GRIEVES, 2006). Além disso, PLM é mais do que a simples soma de elementos, ele também abrange a forma com que esses elementos são integrados e é isso que o torna promissor, segundo alguns autores (GRIEVES, 2006; SAAKSVUORI e IMMONEN, 2008). Segundo Schuh et al (2008), o conceito sobre o que é PLM, ainda não está consolidado totalmente na indústria. A academia postula que PLM não é somente software, pois tem outros elementos importantes, como pessoas e processos, como já foi comentado, enquanto que os fornecedores de serviços e produtos PLM veiculam a mensagem de facilidade na implantação dessa abordagem. Saaksvuori e Immonen (2008) definem Product Lifecycle Management (PLM) com sendo um conceito sistemático para gestão e desenvolvimento do produto. Além da

37 37 informação relacionada ao produto, o conceito PLM proporciona gerenciamento e controle, começando pelo processo de desenvolvimento do produto (projeto do produto, produção e marketing) até o recebimento de pedidos dos clientes, controlando informações relacionadas ao produto durante seu ciclo de até o seu descarte. De outra forma, Stackpole (2003 apud GRIEVES, 2006) define PLM como uma abordagem integrada guiada por informações de todos os aspectos da vida do produto, do projeto, passando pela manufatura, distribuição e manutenção culminando na remoção do produto e descarte final. Segundo Grieves (2006), PLM (Product Lifecycle Management) é uma abordagem integrada e orientada por informações formada por pessoas, processos/práticas e tecnologia para todos os aspectos da vida de um produto, desde design e manufatura, incluindo instalações industriais e manutenção e culminando na remoção do produto do mercado e descarte final. O escritório de consultoria CIMDATA (2008) define, de forma ampla, PLM como sendo uma abordagem estratégica de negócio que aplica um consistente conjunto de soluções que suportam a criação colaborativa, o gerenciamento, a disseminação e o uso de informações que definem o produto, apoiando clientes, projetos e fornecedores desde o conceito até o final da vida do produto ou planta industrial integrando pessoas, processos, sistemas de negócio e informação. Algumas definições, principalmente as encontradas na indústria, deixam dúvidas a respeito dos elementos que compõem PLM e também como esses elementos se influenciam mutuamente. Existem empresas de software que veiculam o termo PLM, simplesmente, como uma estratégia relacionada à aquisição de software, hardware e serviços (treinamento e consultoria). Entretanto, quando se observa detalhadamente o conceito PLM, a tecnologia sempre é o elemento em destaque, isso porque ela é o elemento mais novo, quando

38 38 comparado aos processos e às pessoas. A tecnologia da informação relacionada à PLM, por outro lado, facilita o trabalho das pessoas, auxiliando-as na execução de tarefas com hardware e software (SILVA e TRABASSO, 2009). De fato, analisando as diversas definições apresentadas pode-se concluir que PLM não é simplesmente um software ou um conjunto deles. Trata-se da utilização de uma infraestrutura de Tecnologia da Informação (software e hardware em rede) aliada a processos, que devem ser definidos e executados por diversos usuários, em estágios diferentes do ciclo de vida do produto, objetivando a consecução de metas de negócio de uma empresa. Mas a realidade é muito mais complexa do que essa. Esses elementos (tecnologia, processos e pessoas) estão juntos e transformam um ao outro. As pessoas ou stakeholders mudam a forma de pensar depois de sua interação com tecnologia. Esta se transforma dependendo de como as pessoas a usam, algumas vezes muito diferente das intenções iniciais dos seus desenvolvedores. Os processos ou mesmo práticas transformam e são transformados por pessoas e tecnologia (LATOUR, 1999). Dessa forma, a análise que deve ser feita objetivando a implantação de PLM deve considerar esses elementos chaves: Pessoas e seus desejos, Processos de negócios e a Tecnologias e suas funcionalidades. Mesmo com essa falta de entendimento sobre o que PLM representa apontada por alguns autores (ZANCUL, 2009; SCHUH, et al., 2008), PLM é potencialmente a primeira solução a ser considerada no ambiente de negócios dinâmico e competitivo em que as empresas vivem atualmente. Baseado em recentes pesquisas de mercado, PLM é um dos segmentos de mercado que cresceu rapidamente e irá crescer nos próximos anos. Sua receita total passou de pouco mais de $2 bi em 2001 para uma previsão de mais de $19 bi em 2012 (HOJLO, et al., 2008). Como mencionado anteriormente, PLM tem o potencial diversos benefícios aos processos de negócio ao longo do ciclo de vida dos produtos. Entretanto, esses benefícios

39 39 devem ser traduzidos em termos econômicos para que as organizações possam quantificar e avaliar os efeitos dos benefícios do PLM sobre o negócio. Na Figura 2-1 é apresentado um mapa de valor mostrando o possível impacto da abordagem PLM na capacidade de uma organização gerar valor para seus acionistas. Em geral, o impacto negativo relacionado à aquisição de ativos (investimento em software e hardware) é superado pelo impacto positivo do lucro da organização. Este é gerado pelo aumento de receita e redução dos custos operacionais. Funções Valor Lucro Receita Preço Quantidade Qualidade Pessoal Homem hora Ativos Custos Processos Material Tempo Impacto negativo Energia Impacto moderado Impacto positivo Figura 2-1: Mapa de valor PLM adaptado de (GRIEVES, 2006) Apesar dos benefícios postulados pela academia e veiculados na mídia especializada segundo Schuh et al. (2008) os resultados alcançados em implementações PLM são incipientes. Esses autores apontam algumas causas para isso, quais sejam: PLM é um conceito complexo e existe ainda uma lacuna para o entendimento profundo do que realmente ele significa na prática; As iniciativas de implementação PLM são direcionadas primeiramente em aspectos isolados, tais como, gerenciamento de documentos ou classificação

40 40 de peças, sem a abordagem holística necessária para considerar todo o ciclo de vida de um produto e seus processos; A não existência de referencias literatura que contemplem a implementação da abordagem PLM. De fato, a implantação da abordagem PLM em um ambiente de negócio é complexa, ratificada pelas dificuldades existentes e relatadas. Nas próximas seções são apresentados conceitos que foram utilizados no Capítulo 4 para a proposição do método REQ4PLM. 2.4 GERENCIAMENTO POR PROCESSOS Um dos assuntos relacionados à gestão organizacional que ganhou notoriedade com o estabelecimento da ISO 9001, cuja versão atual é a 2008 (ABNT, 2008), é a Gestão por Processos. Desde que os processos foram inclusos como um dos fundamentos dessa norma o assunto ganhou notoriedade e atualmente é muito discutido pelas organizações. Dentro desse contexto, a modelagem de processos é usada pelas organizações como um método para aumentar a consistência e conhecimento dos processos, e dissecar a complexidade organizacional (INDULSKA, et al., 2009). A modelagem de processos é usada para um grande número de tarefas incluindo (INDULSKA, et al., 2009): Identificar as deficiências do processo utilizando modelos de processo; Adaptar as melhores práticas de negócio; Projetar e comunicar novos desenhos de negócio; Treinar funcionários; Gerenciar a conformidade e risco; Projetar e configurar os sistemas de software.

41 41 Muitas pesquisas têm mostrado a relevância da modelagem de processo em diversas situações ao longo dos anos (ARMISTEAD e MACHIN, 1997; BARTHOLOMEW, 1999; DAVENPORT, 1993; RUMMLER, et al., 2010). A modelagem de processos é um requisito fundamental para programas de qualidade ISO 9000 (OULD, 1995) e é a base para sistemas de informação baseados em processos, tais como ERP (Enterprise Resource Planning) (DREILING, et al., 2006) e gerenciamento de workflows (VAN DER AALST, et al., 2003). A literatura reporta como a modelagem de processos é empregada em diferentes aplicações de negócios, incluindo custeio baseado em atividades, gerenciamento da cadeia de fornecedores, gerenciamento da qualidade total, gerenciamento de fluxos de trabalho, gerenciamento do conhecimento e simulação de negócios (RECKER, 2011). Leis recentes tais como Sarbanes-Oxley Act, por exemplo, contribuíram para o aumento do interesse na modelagem de processo de negócio como uma forma de capturar e documentar os processos de uma organização ou sistema de informação (RECKER, 2011). Contudo Schuh et al. (2008) apontam falhas na adoção de gerenciamento por processos como uma das principais causas de falha na adoção de PLM. Dessa forma, no método elaborado e descrito no Capítulo 4 e testado no Capítulo 5, foi considerada a necessidade de entender os processos de negócios antes de qualquer ação relacionada à aquisição de infraestrutura PLM seja realizada. Dessa forma, o método que será desenvolvido considera o mapeamento e a modelagem de processos como o ponto inicial MAPEAR PROCESSOS Ao longo dos anos, as organizações passaram a mapear suas atividades, a nomear seus processos, e a identificar >entradas<, >saídas<, >recursos<, com o objetivo de cumprir os requisitos normativos de qualidade presentes em normas internacionais e nacionais, como por exemplo ABNT NBR ISO 9001:2008 (ABNT, 2008) e ABNT NBR 15100:2010 (ABNT, 2010).

42 42 O modelo de Excelência em Gestão da Fundação Nacional da Qualidade (FNQ, 2010) define processo como: Um conjunto de atividades preestabelecidas que, executadas numa sequência determinada, conduzirão a um resultado esperado que assegure o atendimento das necessidades e expectativas dos clientes e outras partes interessadas (stakeholders) do processo. Uma empresa, neste conceito, é um "mar de processos, em contínua execução pelas pessoas que compõem sua força de trabalho. Ainda segundo a FNQ (FNQ, 2010), os processos estão inter-relacionados e interagem entre si, de tal forma que, produtos e serviços deles provenientes, constituem a entrada para um ou mais processos na sequência de execução, que busca o atendimento das necessidades e expectativas dos clientes. Pode-se dizer, pois que toda organização é um sistema, ou seja, funciona como um conjunto de processos. A identificação e o mapeamento destes processos permitem um planejamento adequado das atividades, a definição de responsabilidades e o uso adequado dos recursos disponíveis. Cabe ressaltar que muitas organizações desenham seus processos de forma simplificada, modelando apenas as principais etapas de seus ciclos, com objetivo de elaborar um documento bem apresentável, que agrade a quem o leia (incluindo os auditores normativos). Tais organizações estão cometendo um equivoco primário em relação à gestão por processos. As organizações que adotam esse comportamento não gerenciam seus negócios por processo. Apenas dizem que o fazem, mas descumprem sua essência teórica fundamental. O mapeamento das atividades de uma organização é complexo e instável (pois os processos são "vivos, constantemente adaptados ao ambiente que estão inseridos e as pessoas que o executam). Possui inconsistências legítimas e que configuram oportunidades de

43 43 melhoria. E são destas oportunidades que surgem os principais benefícios da gestão por processos MODELAR PROCESSOS Modelar é uma atividade humana que objetiva a análise de um determinado problema ou situação de complexidade considerável. Para tanto, na modelagem considera-se apenas os aspectos mais relevantes em um determinado cenário de interesse. De uma forma geral, a modelagem de processos representa o processo em quatro perspectivas principais (CURTIS, et al., 1992), representadas na Figura 2-2. Figura 2-2: Perspectivas abordadas na modelagem de processos A perspectiva Funcional representa quais elementos do processo são realizados e qual é o fluxo de entidades informacionais (dados e informação).

44 44 A perspectiva Comportamental representa quando e como os elementos do processo são realizados são realizados através do fluxo, interações, condições para tomada de decisão, critérios de entrada e saída e assim por diante. A perspectiva Organizacional representa onde e por quem os elementos do processo são realizados, o mecanismo físico de comunicação usado para transferir entidades informacionais e o hardware físico usado para armazená-los. A perspectiva Informacional representa as entidades informacionais produzidas ou manipuladas pelo processo, entre elas dados, artefatos, produtos e objetos. Essa perspectiva inclui tanto a estrutura de entidades informacionais quanto a relação entre elas. Para fins de análise econômica, as perspectivas apresentadas devem ser complementadas com atributos que sejam capazes de quantificar o custo de cada tarefa do processo, tais como, homem hora, tempo e recursos utilizados para tarefa. De posse dessas informações, o retorno sobre investimento na melhoria dos processos (ROI Return on Investment) pode ser calculado. Essa análise de custos é muitas vezes feita em paralelo com as atividades de modelagem e pode auxiliar na criação de uma perspectiva de Custo do Processo. Dentro de uma empresa, modelagem de processos é a atividade de construção de modelos que podem representam parte dela ou de um grupo de empresas que se tenha interesse. Os aspectos da empresa a serem modelados são definidos de acordo com as necessidades dos usuários, podendo envolver processos de negócio, dados, estrutura organizacional e recursos, entre outros (VERNADAT, 1996; 2002). Por meio da modelagem de processos, o conhecimento sobre a estrutura e a operação da empresa é formalizado para que possa ser compartilhado, analisado e otimizado. De fato, um dos propósitos da modelagem é possibilitar a análise do desempenho da empresa, visando a otimização dos seus processos de negócio. Além disso, os modelos desenvolvidos

45 45 são empregados para documentar processos de negócio, possibilitar simulações e apoiar a implantar sistemas de informação (VERNADAT, 1996; BARBALHO e ROZENFELD, 2002). Na implantação de sistemas de informação, tais como ERP, a modelagem de processos é geralmente empregada para o mapeamento das funções do negócio, considerando o projeto de implantação como pano de fundo. Os modelos de processo também são usados na identificação dos requisitos funcionais e na especificação técnica da estrutura de dados do sistema de informação. Além disso, pesquisas tratam do relacionamento entre modelos de processos de negócio com modelos de sistemas de informação para direcionar a implantação dos sistemas de TI a partir da definição dos processos (ODEH; KAMM, 2003; LANKHORST, 2004). Considerando a definição de modelagem de processos e a discussão dos seus objetivos, no próximo tópico são apresentados os principais métodos de modelagem de processos de negócio MÉTODOS DE MODELAGEM DE PROCESSOS Atualmente, existem diferentes métodos de modelagem de processos disponíveis que possuem semânticas e nomenclaturas especificas. Neste tópico, apresenta-se um resumo dos métodos de modelagem relevantes no contexto deste trabalho, sejam eles: Event-Driven Process Chain - EPC, (DAVIS, 2008; RECKER, 2011), Integration Definition for Function Modeling - IDF0, (US AIR FORCE SYSTEMS COMMAND, 1981; DOD-SYSTEMS MANAGEMENT COLLEGE, 2001) Business Processes Modeling and Notation BPMN, (OMG, 2010; WHITE e MIERS, 2008)

46 46 Cada um dos métodos listados acima pode ser visto em detalhes nas referências fornecidas no texto. O EPC proposto por Dr. August-Wilhelm Scheer é uma notação simples e permite a verificação da consistência do processo à medida que ele é modelado. No entanto, não é uma notação aberta suficientemente para ser suportada por outra ferramenta que não o ARIS TM da empesa IDS Scheer. Os diagramas da notação IDEF0 são simples, mas podem ser difíceis de ser interpretados por analistas de negócio que não estejam adaptados a essa notação e acabam por tornar o uso restrito aos especialistas nessa notação. A notação BPMN é uma linguagem que recentemente tem obtido bastante atenção e aceitação na prática de modelagem de processos de negócio (RECKER, 2008; WHITE e MIERS, 2008). Além disso, BPMN é uma linguagem padrão para modelar processos de negócios onde analistas de negócios, analistas de processos, e engenheiros de software podem igualmente colaborar na definição e implantação de soluções de negócio (OMG, 2010). Por esses motivos a linguagem de processos escolhida para o desenvolvido do trabalho foi o BPMN. Na seção de anexos o leitor encontra a descrição das entidades do BPMN utilizadas nesse trabalho, bem como, outras entidades encontradas comumente em mapas de processos modelados com BPMN. 2.5 INDICADORES DE DESEMPENHO E GERAÇÃO DE VALOR A seção anterior trata de modelagem de processo e a importância dessa abordagem na implantação de melhorias nos processos de negócio. Consequentemente, essa importância pode ser trazida para o contexto de implantação de novas abordagens de negócios, tais como PLM. Nesta seção, apresenta-se a maneira comumente aceita para medir o desempenho dos processos e com isso relacionar ações realizadas a mudanças em parâmetros de controle ou indicadores de desempenho.

47 IMPORTÂNCIA DE INDICADORES PARA O GERENCIAMENTO POR PROCESSOS A importância de indicadores de desempenho parece ser evidente, considerando a necessidade dos gestores corporativos em identificar informações relevantes sobre o comportamento da organização nos processos do ciclo de vida dos produtos e as consequentes tomadas de decisão. Durante a década passada grande progresso foi alcançado pela aplicação de indicadores de desempenho em processos bem comportados, tais como, manufatura e financeiros ou contábeis (ACOSTA, 2004). Entretanto ao longo do ciclo de vida dos produtos existem também processos que não são bem comportados e têm um impacto significativo no desempenho das corporações. Contudo, os indicadores de desempenho também podem ser utilizados para avaliar esses processos. Quando os indicadores de desempenho são monitorados, os impactos na mudança dos processos podem ser medidos e analisados sob um ponto de vista quantitativo e objetivo. A implantação de uma estratégia como PLM possui um longo período de investimento e seus benefícios, mensurados por indicadores de desempenho, não são percebidos imediatamente por causa das atividades de melhoria das condições de trabalho, tais como: Otimização processos de negócios de uma forma não estruturada (trial and error); Mudança nos hábitos de trabalho dos empregados; Resistência a essa mudança; Adoção e aprendizado de novas ferramentas, por exemplo, PDM.

48 48 Outro aspecto que deve ser considerado, é que geralmente PLM é introduzido de forma progressiva, adicionando continuamente complexidade extra aos processos. De fato, segundo a experiência prática do autor, PLM é implantado inicialmente em um projeto piloto específico, e só depois disseminado para toda a empresa. Em concordância a medir e entender melhor se a nova abordagem pode trazer melhorias significativas aos processos do ciclo de vida do produto, é necessário implantar um método de avaliação capaz de analisar os benefícios relacionados com a adoção de PLM, mesmo antes de iniciar a adoção ou quando o sistema já estiver em funcionamento. Dada à importância que os indicadores de desempenho têm para avaliação da melhoria de processos, em particular mudanças ocasionadas pela adoção de PLM, é necessária uma análise de trabalhos existentes sobre esse tópico. Essa análise é feita no próximo tópico desse capítulo MÉTODOS PARA MEDIR A MELHORIA COM IMPLANTAÇÃO DE PLM Pesquisando na literatura pertinente por algum meio de medir a melhoria nos processo pela adoção de abordagem PLM observou-se que, atualmente, não existem muitos trabalhos desenvolvidos nesse sentido. Alguns artigos analisam o retorno sob o investimento dado pela adoção de ferramentas genéricas de TI (Tecnologia da Informação), orientadas à troca e compartilhamento de dados, discussão sobre qual relação entre investimento em TI e o desempenho corporativo (HUAN, OU, et al., 2005; BRYD e TURNER, 2000). Outros artigos são um pouco mais específicos e abordam soluções próximas ao PLM, tais como, CRM, SCM e ERP, direncionando a atenção sob o retorno financeiro (HENDRICKS, et al., 2006; MABERT, et al., 2000). Além disso, é abundante a discussão, sob diferentes pontos de vista, sobre os benefícios em adotar sistemas ERP em diferentes tipos de empresa (MABERT, et al., 2003). Mas poucas publicações versam sobre o impacto ou benefícios alcançados pela adoção da

49 49 estratégia PLM. Alguns documentos são produzidos por empresas de consultoria e mencionam o efeito de soluções específicas (CIMDATA, 2005) para setores industriais específicos ou ainda trazem informações sobre estudos de caso bem definidos (HILL, JR., 2006). Alemanni et al. (2008) apresentam um trabalho alinhado aos objetivos dessa tese. Nele é proposta uma solução, baseada em KPI -Key Performance Indicators (KAPLAN e NORTON, 1996) para avaliar os benefícios introduzidos pela adoção de ferramentas para PLM em uma empresa que atua no setor aeroespacial e de defesa, enfatizando a melhoria criada pela implantação de soluções para PLM nas atividades do dia a dia e a consequente contribuição dessa melhoria em alguns processos chave tais como configuração de produto, gerenciamento da mudança e documentação do desenvolvimento. A respeito de métodos para criação de indicadores, Acosta (2004) apresenta um método de derivar métricas para indicadores de desempenho, seguindo a visão do valor gerado para os clientes do processo. Segundo o autor, o desenvolvimento desse método baseia-se em requisitos operacionais da indústria: simplicidade, reprodutibilidade, aplicabilidade, independência de especialista e alinhamento estratégico aos objetivos organizacionais. O método consiste de sete passos que permitem a derivação de métricas para indicadores de um processo: (1) Identificar qual é o objetivo do processo que se quer criar um indicador. Qual é o objetivo do processo (ou trabalho) pretende definir indicadores? (2) Identificar quem são os clientes que irão receber a saída do processo. Quem é o cliente do seu processo? (3) Registrar o que o cliente enxerga como valor O que o cliente vê como valor? (4) Identificar qual é o processo responsável pela criação de cada valor registrado. Qual é o processo "responsável" para a sua incorporação para cada valor acima? (5) Identificar aspectos no processo mais responsável pela criação de valor. Qual é o aspecto mais relevante para cumprir o item de valor? (6) Encontrar características que podem ser medidas para garantir que a geração de valor para os clientes está sendo considerada.

50 50 Porque é que este aspecto é importante? Apontar algumas das suas características. (7) Encontrar maneiras de como essas características pode ser medida. Como essas características devem ser avaliadas, a fim de serem indicadores do processo? A partir da necessidade de obter uma ferramenta capaz de definir indicadores para a abordagem PLM, o método de Acosta (2004) parece uma opção factível para uso, com as devidas adaptações para o caso especifico de criação de indicadores para implantação de PLM. Após a discussão da importância de indicadores para medir a melhoria dos processos, trabalho direcionados a PLM e possíveis métodos para definição de indicadores que meçam a melhoria nos processos devido a adoção de PLM, no próximo tópico é apresentado atributos que caracterizam um bom indicador de desempenho ATRIBUTOS PARA UM BOM INDICADOR Na maioria das organizações, é comum o uso da análise de retorno sobre o investimento financeiro (ROI Return on Investment) para a tomada de decisão de investimentos (ROULSTONE e PHILLIPS, 2008). Essa análise pode ser realizada para tomada de decisão de qualquer investimento que objetiva melhorar um processo: comprar uma nova máquina-ferramenta ou implementar uma nova tecnologia PLM, tendo diferentes impactos na organização. No caso de PLM, a análise ROI é usada para avaliar o retorno financeiro possível para um investimento em PLM e determinar se os ganhos são substanciais o bastante para justificar os investimentos. A análise ROI também provê um mecanismo para avaliação da magnitude dos benefícios durante o ciclo de vida do projeto de uma implantação de um sistema PLM. (MACKRELL, 2004). A dificuldade que geralmente ocorre, especificamente para benefícios atrelados a sistemas PLM, é a quantificação dos benefícios em termos monetários. Entretanto, sistemas

51 51 PLM proveem benefícios por meio de redução de custos/tempo e possibilitam que a contenção baseada em redução de tempo possa ser convertida em unidades monetárias (MACKRELL, 2004). Os benefícios somados devem ser balanceados aos custos relacionados às aquisições de abordagem e tecnologias. Para tanto, é importante entender a diferença entre indicadores de desempenho e benefícios: indicadores de desempenho são os valores mensuráveis que são usados para quantificar o sucesso em alcançar um determinado beneficio. Um benefício pode ter diversos indicadores relacionados. Contudo, para um benefício desejado deve existir pelo menos um indicador estabelecido. (MACKRELL, 2004). Quando um indicador é novo e não foi previamente medido, é necessário estimalo para justificar o investimento em qualquer solução para melhoria dos processos. indicadores pré-estabelecidos ajudam a abrandar esse problema, mas poucas organizações têm um número substancial de indicadores. Além disso, monitorar indicadores ao longo do tempo pode mostrar o progresso de uma iniciativa PLM (MACKRELL, 2004). Segundo Acosta (2004) os indicadores de desempenho possuem os seguintes atributos: Um nome para o indicador; Uma métrica; Forma de coleta dos dados; Pessoa responsável pela coleta; Frequência da coleta. Formas de análise; Equipe ou pessoa encarregada pela análise dos dados Frequência da análise Um usuário final.

52 52 Indicadores de desempenho são mais do que simples métricas. Eles devem servir para algum propósito gerencial relacionado com o atingimento de objetivos específicos da organização (TOSCANO e OSTINELLI, 1998) e devem ser customizados para cada um desses objetivos (ACOSTA, 2004). Mackrell (2004) aponta ainda os seguintes atributos como constituintes dos indicadores de desempenho: Base line ou referencia inicial Um ponto inicial em que o progresso pode ser determinado. Se historicamente não existem dados, a base line deve ser estimada. Uma meta a ser alcançada Uma meta que a organização deseja alcançar. Isso é usualmente estabelecido como uma porcentagem ou montante de redução de custos. Entretanto, ela pode ser uma quantidade ou redução de tempo no processo considerado. Um prazo determinado para alcançar a meta. Trata-se de um atributo crítico para medir o sucesso na consecução da meta estabelecida >quando<. Mackrell (2004) afirma que a obtenção de indicadores será sempre um desafio, a menos que os stakeholders os entendam e possam associá-los a sua experiência, possam acreditar que eles podem ser precisamente medidos, e aceitar que as metas estabelecidas e o prazo para obtê-las são razoáveis. Os indicadores devem ser uma medida do valor gerado pela escolha de uma determinada solução para melhoria dos processos. Essa geração de valor deve guiar a escolha de uma tecnologia e metodologia. Segundo Moreira (2009, p. 13) o valor está atrás de cada gesto, atitude, movimento ou interferência humana. É algo maior, soberano, que orienta, conduz e induz o que haverá de ser feito. Como elementos

53 53 motivadores e impulsionadores das disposições e empenho humanos, os valores são as grandes razões pelas quais tudo o mais recebe energia. Atribuir valor é uma obrigação de quem recebe, em hipótese alguma de quem entrega alguma coisa. Apesar de Moreira (2009) referir-se a relação entre clientes e empresas, a afirmação acima pode ser extrapolada para implantação de um sistema de informação, por exemplo, PLM. Conforme apresentado anteriormente, somente os stakeholders desse sistema ou dos processos que esse sistema suporta podem atribuir algum valor a ele (SEDDON, et al., 1998; TURUNEN e TALMON, 1998). Devido a isso, é importante considerá-los quando se estiver definindo o que o sistema irá realizar para satisfazer esses stakeholders. Além dos processos de negócio e os mecanismos existentes para avaliar mudanças nos processos, as alterações devem atender os interesses dos stakeholders do processo. A próxima seção concentra-se em formas de identificar stakeholders e analisar seus interesses de forma a obter inputs na definição do que o sistema deve fazer para satisfazê-lo. 2.6 ANÁLISE DE STAKEHOLDERS Análises de índices econômicos dos EUA (e de maneira semelhante de todo o mundo) gastam atualmente, em média, 30% de suas despesas para aquisição de ativos de informática, em comparação com 5% na década de 1960 (CAMERON e GREEN, 2009). Entretanto, apesar da sofisticação do hardware disponível (relativamente barato), e da série de aplicativos de software e técnicas de TI (Tecnologia da Informação) que foram idealizadas e em muitos casos intensamente promovidos, por exemplo aplicativos de software PLM, as organizações ainda deixam de agregar valor comercial esperado quando implementam mudanças baseadas majoritariamente em TI (RANGAN, et al., 2008). Aparentemente, a TI promete muito e os benefícios não são percebidos consistentemente. (CAMERON e GREEN, 2009, p. 298). Cameron e Green (2009, p. 301) advertem que

54 54 delegar a responsabilidade sobre o tema TI aos especialistas em TI da empresa como um dos possíveis motivos para essa dificuldade em usufruir os benefícios e os consequentes maus resultados. Os especialistas em TI simplesmente acabam definindo o projeto e produzindo uma solução. Contudo, as decisões tomadas por eles afetam toda a empresa, mas são tomadas por pessoas que não tem uma visão completa do negócio e sim uma visão limitada e técnica, a de TI. Davenport (1994, p. 15) afirma: Os gerentes gerais ( ) normalmente não conhecem muito sobre computadores. Pode ser que gostem da ideia de usar a tecnologia da informação estrategicamente, ( ) Mas eles raramente sabem com traduzir os seus desejos em investimentos específicos em informática (TI). Dentro desse conceito é importante identificar a verdadeira necessidades dos stakeholders de sistema corporativos e de uma forma ampla de todos os interessados nesse sistema cuja instalação ou implementação o afete ou seja afetada por ele. Os próximos tópicos tratam da forma de identificar e analisar essas partes de forma a identificar suas necessidades, bem antes de qualquer decisão seja tomada e qualquer investimento seja comprometido com essa iniciativa IDENTIFICAÇÃO DE STAKEHOLDERS Mason e Mitroff (1981, p. 23) ajudaram a introduzir a análise de stakeholders na prática de negócios. A definição de stakeholders dada por esses autores é: stakeholder é todo aquele que de dentro ou fora da organização têm interesse no problema e sua solução e ainda segundo eles são entidades concretas que afetam ou são afetadas por uma mudança organizacional. Eles sugerem formas de identificação de stakeholders que incluem considerar: Grupos demográficos, tais como, faixa etária, sexo, cor etc; Relevância, perguntando as pessoas quem eles consideram ser stakeholders chave;

55 55 Estudo de campo etnográfico para descobrir quem de fato tem um interesse válido. Alexander et. al. (2002) distinguem usuários de clientes, gerentes que estão preocupados com o sucesso do sistema, entidades reguladoras, e brevemente discutem o papel das pessoas nas organizações de desenvolvimento. A identificação de stakeholders de um sistema deve considerar todas as pessoas afetadas e que afetam o produto final, os processos do ciclo de vida e as organizações envolvidas no esforço de desenvolvimento do sistema. Loureiro (1999) os investiga separando-os em: stakeholders do produto, stakeholders do processo e stakeholders das organizações que realizam os processos. O método de análise proposto por Loureiro (1999) e demonstrado em seu trabalho relaciona os potenciais stakeholders dos processos como sendo as fontes ou destinos dos mecanismos, controles, entradas e saídas do processo. Para tanto ele utiliza a notação de modelagem de processos IDEF0 (NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY, 1993) representada na Figura 2-3. Controles Entrada Elemento de processo Saída Mecanismos Figura 2-3: Elementos do IDEF0 utilizados para identificar stakeholders Nessa figura, o elemento de entrada possui uma fonte ou origem. O método de Loureiro (1999) sugere que as pessoas ou organizações que originam os inputs como um stakeholder em potencial do processo. De forma semelhante, as pessoas ou organizações que

56 56 recebem as saídas do processo são stakeholders em potencial. Idem para os controles e mecanismos do processo. Dessa forma, os processos de negócios podem ser entendidos como um conjunto de relações entre grupos que tem influência nas diversas atividades que fazem o negócio. Com isso, os processos de negócio tratam como clientes, fornecedores, empregados e financiadores (bancos, acionistas e outros), comunidades e gerentes interagem e criam valor. Entender o negócio e seus processos é entender como essas relações acontecem, ou seja, entender os interesses dos stakeholders nos processos ANÁLISE DE NECESSIDADES DE STAKEHOLDERS Stakeholders incluem não somente beneficiários nas mudanças dos processos, mas também aqueles stakeholders, cujos interesses não devem ser atendidos. Além disso, é impossível satisfazer a todos os stakeholders, mas é fundamental satisfazer os stakeholders fundamentais a mudanças no processo (ALEXANDER, 2007). Portanto, os stakeholders devem ser analisados de forma a obter informações relevantes para tomada de decisão, mitigar riscos e propor formas de amenizar os efeitos não desejáveis quando for necessária uma mudança. No caso do contexto desse trabalho, os stakeholders dos processos devem ser analisados devido a: 1. Os stakeholders são aqueles que devem ficar satisfeitos com a nova abordagem PLM adotada. Portanto entender suas necessidades é fundamental; 2. Os stakeholders podem ser a principal barreira para o sucesso da nova abordagem;

57 PROCESSO DE ENGENHARIA DE SISTEMAS Após a identificação dos stakeholders e de suas necessidades, essas informações junto com a definição dos processos de negócio devem ser utilizadas para definir o que o novo sistema PLM deve fazer. Dessa forma, deve-se definir quais as funções que esse novo sistema deve ter para atender os stakeholders e os processos. Essa seção apresenta a abordagem de engenharia de sistemas para a definição das funcionalidades de um sistema em consonância com as necessidades de stakeholders e os processos de negócios. Certamente, é comum encontrar referencias a uma disciplina chamada Engenharia de Sistemas. Mas, mesmo nunca tendo ouvindo falar dessa disciplina, os termos podem soar familiaes. Os termos Sistemas e Engenharia são bem conhecidos. Ouvindo-os juntos, todos podem ter certa idéia do que seja essa disciplina. O problema é que essas idéias estão frequentemente equivocadas. Para auxilia o leitor, o Quadro 2-2 foi elaborado para fornecer algumas definições úteis ao entendimento da abordagem. Quadro 2-2: Definição de termos importantes, fonte: (ISO, 2008; TECHNICAL BOARD INTERNATIONAL COUNCIL ON SYSTEMS ENGINEERING (INCOSE), 2010; FREEMAN, 1984) Conceito Atividade Elemento Organização Estágio Projeto Processo Sistema PLM Definição Conjunto de tarefas coesas de um processo A parte de um sistema que pode ser implementada para o cumprimento de requisitos específicos. Pessoa ou grupo de pessoas e instalações com uma estrutura de responsabilidade, autoridade e relacionamento. Um período no ciclo de vida de uma entidade que se relaciona a um estado específico de sua descrição ou criação. Um esforço com critérios de início e fim empreendidos para criar um produto ou serviço de acordo com recursos específicos e requisitos. Conjunto de atividades inter-relacionadas ou que interagem para transformar inputs em outputs. São os elementos de Infraestrutura PLM, Processos de negócio e Stakeholders envolvidos no conceito de gerenciamento do ciclo de vida do produto.

58 58 Ferramenta ou software PLM Infraestrutura PLM Sistema Engenharia de Sistemas São os aplicativos de software utilizados na estratégia de gerenciamento do ciclo de vida do produto. Ex. CAD, CAE, CAM, CAPP, PDM, etc. É a rede de computadores utilizada para criar, compartilhar e gerenciar dados de produtos em conjunto com todos os softwares necessários a essa estratégia Uma combinação de elementos inter-relacionados organizados para alcançar um ou mais propósitos estabelecidos. Um conjunto de elementos integrados, subsistemas, ou montagens (assemblies) que realiza um determinado objetivo. Esses elementos incluem produtos (hardware, software, firmware), processos, pessoas, informação, técnicas, instalações, serviços e outros elementos de suporte. Engenharia de Sistemas (ES) é uma abordagem multidisciplinar que permite a criação de sistemas satisfatoriamente. Ela define as necessidades dos stakeholders e funcionalidades requeridas antecipadamente no ciclo de desenvolvimento, documenta os requisitos, e só então prossegue como o projeto (Síntese) e validação(análise) enquanto considera o problema completo: operações, custos e cronograma, eficiência, treinamento e suporte, testes, manufatura e descarte. ES considera ambos, as necessidades de negócios e técnicas de todos os consumidores como o objetivo de prover um produto de qualidade que atenda as necessidades dos clientes. Sistemas são artefatos criados pela mente humana e que consistem de blocos que possuem o mesmo objetivo final e que não pode ser alcançado por cada elemento em separado. Os blocos podem consistir de software, hardware, pessoas, ou qualquer outra unidade (INCOSE, 2010). Engenharia geralmente define disciplinas que usa métodos e ferramentas em uma forma estruturada o desenvolvimento de algo: um produto, uma obra, a operação produtiva, processo de manutenção etc. Considerando as duas definições pode-se dizer que engenharia de sistemas denota métodos que podem ser usados para desenvolver sistemas. Segundo o INCOSE (2011), Engenharia de Sistemas concentra-se na definição e documentação de requisitos de sistemas em fases iniciais, na preparação do projeto de sistemas, e na verificação do sistema em relação ao cumprimento dos requisitos, considerando

59 59 o problema do ponto de vista global: operação, tempo, criação, custo e planejamento, treinamento e suporte técnico e descarte. Engenharia de sistemas integra todas as disciplinas e descreve um processo estruturado de desenvolvimento, da fase de conceito à fase de produção e operação e finalmente colocando o sistema fora de operação. É dada ênfase em aspectos técnicos e econômicos simultaneamente para desenvolver um sistema que atende as necessidades dos usuários. Essa linha de raciocínio holístico também inclui soluções para problemas que surgem somente quando um novo sistema é introduzido. O modelo de processo SIMILAR (BAHIL e GISSING, 1998) fornece uma revisão adequado do processo de engenharia de sistemas. O nome é um acrônimo para: State the problem, Investigate alternatives, Model systems, Integrate, Launch the system, Assess performance, Re-evaluate. No início de qualquer desenvolvimento de produto o que existe inicialmente são as descrições das tarefas que se deve realizar para consecução de objetivos estabelecidos. Dessa forma, uma boa solução só pode ser encontrada se as tarefas forem bem formuladas. Erros nessa fase podem tornar-se extremamente onerosos, em termos de custos e prazo. Portanto, dentro desse contexto, deve-se definir inicialmente o que o sistema deve fazer, ou quais requisitos o sistema deve atender. Entretanto, os requisitos não devem descrever a

60 60 solução. Se o fizessem, isso impediria de avaliar mais de uma solução como alternativa (WEILKIENS, 2006). Uma das importantes tarefas de um engenheiro de sistemas é investigar e ponderar soluções alternativas. Isso significa que, baseado nos requisitos, um engenheiro de sistemas não precisa desenvolver um projeto de sistema, mas normalmente projetos alternativos adicionais. Isso o permite ponderar diversas soluções umas com as outras. Dificilmente vai ocorrer a situação em que todos os benefícios estejam unidos em uma única solução. Isso também significa que diferentes critérios técnicos, financeiros e prioridades sejam considerados (WEILKIENS, 2006). A abordagem de engenharia de sistema é utilizada para solucionar o problema de definição de requisitos por proporcionar uma visão holística do problema e, consequentemente, aborda os diversos aspectos envolvidos, tais como, pessoas, tecnologia e processos. Na próxima seção é apresentado em detalhes o processo de engenharia de requisitos que também é utilizado, com adaptações, para alcançar os objetivos estabelecidos nesse trabalho. 2.8 PROCESSO DE ENGENHARIA DE REQUISITOS De uma maneira simples e direta o processo de engenharia de requisitos é o processo pelo qual engenheiros descrevem o que um sistema deve fazer. O objetivo é simples: apresentar de forma escrita o que o sistema faz. Mas a importância dessa tarefa é muitas vezes subestimada. O investimento médio da indústria no processo de engenharia de requisitos para um sistema é de 2% a 3% do custo total do projeto (YOUNG, 2004). Segundo Young (2004), essa quantidade de investimento é inadequada e é a causa raiz de falha em muitos projetos. Dados da NASA descritos em Hooks e Farry (2001) fornecem o seguinte Alerta: projetos industriais que gastam 2% a 3% do custo total do projeto

61 61 (em todo o ciclo de vida) no processo de engenharia de requisitos, experimentaram um acréscimo de 80% a 200% nos custos do projeto, enquanto os projetos que investiram 8% a 14% do custo total do projeto no processo de engenharia de requisitos tiveram um acréscimo de 0% a 50%. Além disso, a grande maioria dos gerentes pondera as atividades relacionadas a requisitos como sendo constituídas simplesmente pela coleta de requisitos e o gerenciamento de mudanças desses requisitos durante o ciclo de vida do produto (YOUNG, 2004). Na realidade, existem diversas outras atividades relacionadas a requisitos que são necessárias durante o ciclo de vida de um sistema, quais sejam (YOUNG, 2004): Identificar stakeholders; Entender as necessidades dos stakeholders; Identificar requisitos; Esclarecer e reafirmar requisitos; Analisar os requisitos; Definir os requisitos de uma forma que tenham o mesmo significado para todos os stakeholders; Especificar os requisitos; Priorizar os requisitos; Derivar os requisitos. Hull et al (2005) ressaltam a importância de entender o relacionamento entre requisitos e modelagem de sistemas para o processo de engenharia de requisitos. Segundo esses autores esses campos de atuação possuem atividades que se auxiliam mutuamente. Esse

62 62 relacionamento pode ser entendido como camadas sobrepostas em que a inferior suporta a superior e assim sucessivamente. A Figura 2-4 ilustra esse relacionamento. Camada de Requisitos Camada de Modelagem Camada de Requisitos Camada de Modelagem Requisitos de Subsistema Modelagem de Desempenho Requisitos de Sistema Modelagem Funcional Camada de Requisitos Camada de Modelagem Camada de Requisitos Requisitos dos Stakeholders Estabelecimento da Necessidade Modelagem do Uso Figura 2-4: Relacionamento entre requisitos e modelagem de sistemas. Adaptado de (HULL, et al., 2005) As camadas de modelagem da Figura 2-4 explicam e proporcionam o desdobramento na camada seguinte de requisitos desde as primeiras necessidades estabelecidas até aos requisitos de subsistemas (fluxo ascendente à direita). Esse framework proporciona a rastreabilidade para, a partir dos requisitos de subsistemas, retornar as necessidades estabelecidas inicialmente e concluir que aquilo que é proposto na forma de requisitos atendem aos stakeholders (fluxo descendente ao centro). Os requisitos são a definição do que é requerido em cada camada em níveis de detalhamento cada vez maiores. 2.9 MODELAGEM DE SISTEMAS Especificações baseadas em ES frequentemente resultam em uma quantidade significativa de documentos com vários tipos de diagramas e notações, algumas vezes usadas de uma maneira inconsistente (WEILKIENS, 2006).

63 63 Uma abordagem alternativa é a baseada em modelos, comumente chamada de Engenharia de Sistemas baseada em Modelos. Essa abordagem procura desenvolver um conjunto consistente de modelos que proporcionam visões diferentes de um mesmo sistema para armazenagem e gerenciamento em banco de dados (WEILKIENS, 2006). A abordagem baseada em modelos resulta em um conjunto estruturado de modelos que representam e especificam o sistema em vários níveis de detalhes (visões) tais como operacional, funcional, e de aspectos técnicos. Modelar sistemas auxilia no gerenciamento de sua complexidade, desde que cada modelo e diagrama forneçam uma visão abstrata e a definições do sistema (ou parte dele). Segundo Hull et. al (2005) os sistemas podem ter suas funcionalidades classificadas em modelos conforme a Figura 2-5. Sistemas externos Ameaças externas Usuários Funcionalidade da garantia da qualidade Sistema Funcionalidade de interface Funcionalidade interna Funcionalidade para interação com usuários Figura 2-5: Diagrama de contexto de um sistema e interação entre funcionalidades (HULL, et al., 2005) As funcionalidades internas são os elementos principais para a criação de requisitos de sistemas, porque a ênfase é definir >o que< o sistema irá cumprir. Para identificar essas funcionalidades, o modelo desenvolvido deve ser capaz de indicar o

64 64 comportamento do sistema (behaviour). Nesse trabalho são utilizados diagrama de contexto e de casos de uso para modelagem do comportamento do sistema. A seleção da notação adequada depende do tipo de sistema que está sendo modelado. No caso de um sistema PLM, todas as funções estão, de alguma forma, relacionadas a gerar, manipular e armazenar com segurança dados de produto e dos processos relacionados a essas funções. O modelo ou modelos criados devem mapear o fluxo de dados no contexto do processo analisado. As funcionalidades de interface são necessárias para definir a natureza das interações com outros sistemas. No caso de um sistema PLM, elas mapeiam o fluxo de informação entre os demais sistemas já existentes no ambiente, onde o sistema PLM será implantado. O fluxo pode ser numa única direção ou em ambas e podem existir limitações na rede de computadores e integração entre sistemas. Portanto, pode ser necessário especificar uma arquitetura de rede isenta dessas limitações. A arquitetura física existente pode ser, consequentemente, uma fonte de restrições para o sistema PLM. As funcionalidades para interação com usuários estabelecem os fluxos de informação entre usuários e o sistema. Ademais, o contexto em que os usuários irão trabalhar também deve ser considerado. Como regra geral, as ferramentas já utilizadas devem ser analisadas com exemplos de interface que podem ser reaproveitadas no novo sistema. Por exemplo, planilhas Excel e documentos Word devem ser utilizados para captura de informação devido a sua larga difusão de interface. O sistema PLM deve gerenciar esses arquivos. Dessa forma, a interface torna-se mais acessível aos novos usuários bem como o sistema PLM pode gerenciar dados legados da empresa. Apesar dessas características, as diversas iniciativas para padronizar o processo de engenharia de sistemas (por exemplo, ISO/IEC 15288, EIA-632), não resultaram em nenhuma linguagem de modelagem de sistemas. Isso pode levar a perdas consideráveis em projetos

65 65 interdisciplinares, por exemplo Projeto TAPP Turbina Aeronáutica de Pequena Potencia (SILVA e TRABASSO, 2009). Segundo Weilkiens (2006), as informações na forma de modelos são de difícil manipulação e compartilhamento, gerando desentendimentos entre a equipe de projeto e a necessidade de ferramentas diferentes, o que, geralmente, ocasiona retrabalhos. Dessa problemática surge a necessidade de linguagem de modelagem de sistemas. Os próximos itens detalham a linguagem SysML desenvolvida pela OMG (Object Management Group) resolve as dificuldades ocasionadas pela falta de uma padronização para modelagem de sistemas SYSTEM MODELING LANGUAGE SYSML SysML é uma linguagem de modelagem orientada a objetos para especificar, analisar, projetar, e verificar sistemas que podem incluir hardware, software, informação, pessoal, procedimentos e instalações. Especificamente, essa linguagem fornece representações gráficas com significado semântico para modelar requisitos, comportamento, estrutura, e integração do sistema com uma análise da engenharia em larga escala (WEILKIENS, 2006). A SysML representa um subconjunto de UML 2.0 (OBJECT MANAGEMENT GROUP, 2010), com as extensões necessárias para atender as necessidades da Engenharia de Sistemas, conforme ilustrado na Figura 2-6. Não utilizada SysML UML reusada pelo SysML: (UML4SysML) UML 2.1 SysML Extensão da UML para SysML Figura 2-6: Interseção da UML 2.0 e SysML (Fonte: (OBJECT MANAGEMENT GROUP, 2010)

66 66 Historicamente, a SysML nasceu a partir de uma iniciativa do International Council on Systems Engineering (INCOSE) para customizar a UML para aplicações de Engenharia de Sistemas. O INCOSE e a OMG (Object Management Group, responsável pela UML), criaram em 2001 um grupo de trabalho que definiu os requisitos de uma linguagem de modelagem de sistemas. Estes requisitos foram publicados em 2003 como uma chamada para propostas de linguagens (UML for Systems Engineering Request for Proposal - UML for SE RFP) (WEILKIENS, 2006). Dessa forma foi então organizado o SysML Partners, um grupo de trabalho composto por representantes do setor industrial e desenvolvedores de ferramentas CASE (Computer Aided Software Engineering). Este grupo iniciou a elaboração da SysML open souce, uma linguagem que respondesse aos requisitos especificados na SE RFP. A versão draft da SysML foi publicada em 2004, enquanto que a versão atual, SysML 1.2, foi publicada em junho de 2010 (OBJECT MANAGEMENT GROUP, 2010). DIAGRAMAS DA SYSML A organização da SysML em diagramas está representada na Figura 2-7. Os nomes dos diagramas foram traduzidos livremente do inglês para português, já que se tratam de elementos normativos. Em caso de dúvida o leitor pode consultar a referencia (OBJECT MANAGEMENT GROUP, 2010).

67 67 bdd [SysML Block Definition] diagrams [diagrams] «block» Diagrama SysML «block» Diagrama comportamental «block» Diagrama de requisitos «constraintblock» Diagrama estrutual notes Diagrama novo «block» Diagrama de ativ idades «block» Diagrama máquinas de estado «block» Diagrama de sequência «block» Diagrama use case «constraintblock» Diagrama de blocos «block» Diagrama interno de blocos «block» Diagrama de pacotes notes Diagrama modificado do UML 2.0 notes Igual a UML 2.0 notes Igual a UML 2.0 notes Igual a UML 2.0 notes Diagrama modificado do UML 2.0 notes Diagrama modificado do UML 2.0 notes Igual a UML 2.0 «block» Diagrama parametrico notes Diagrama novo Figura 2-7: Taxonomia dos diagramas SysML, fonte: (OBJECT MANAGEMENT GROUP, 2010) Diagramas estruturais O diagrama de blocos (Block Definition Diagram BDD) substitui o diagrama de classes (Class Diagram) da UML 2.0. O diagrama interno de blocos (Internal Block Diagram IBD) substitui o diagrama de estrutura composta (Composite Structure Diagram) da UML 2.0. O diagrama paramétrico (Parametric Diagram) é uma extensão SYSML utilizada para analisar parâmetros críticos do sistema. O diagrama de pacotes permanece inalterado.

68 68 O >bloco< é a unidade básica da estrutura em SysML e pode ser usado para representar o hardware, o software, as instalações, o pessoal, ou todo e qualquer outro elemento do sistema. A estrutura do sistema é representada por três tipos de diagramas: Diagrama de blocos; Diagrama interno de blocos e Diagrama de pacotes. O diagrama de blocos descreve a estrutura do sistema: componentes, suas propriedades, operações e relações. O diagrama interno de blocos descreve a estrutura interna de um componente, incluindo suas partes e interfaces. Um quarto diagrama também pode ser considerado como diagrama de estrutura, o diagrama paramétrico, esse diagrama utiliza blocos de restrição para integrar análises de engenharia, tais como modelos de desempenho e confiabilidade com outros modelos SysML. Blocos de restrição podem ser usados para especificar uma rede de restrições que representam expressões matemáticas, tais como { P m 2 } = & e {& = ρv A} V 0 m 0, que são restrições físicas de um sistema. Tais restrições podem ser usadas também para identificar parâmetros críticos de desempenho e as relações com outros parâmetros, coletados ao longo do ciclo de vida do sistema. Diagramas comportamentais O diagrama de atividades (Activity Diagram) foi modificado levemente na linguagem SysML

69 69 Os diagramas de sequência, máquinas de estado e casos de uso (Sequence Diagram, State Chart Diagram, e Use Case Diagram) permanecem inalterados. O comportamento do sistema é representado por quatro tipos de diagramas: Diagrama de atividade; Diagrama de sequência; Digrama de máquinas de estado e Diagrama de casos de uso. Estes diagramas são herdados da UML 2.0 de forma integral e sem modificações. O diagrama de casos de uso fornece uma descrição em alto nível das funcionalidades do sistema na forma de casos de uso (WEILKIENS, 2006; OBJECT MANAGEMENT GROUP, 2010). O digrama de atividades representa o fluxo dos dados e o controle entre atividades. O diagrama de sequência representa a interação entre partes colaborativas de um sistema. O diagrama de máquinas de estado descreve as transições de estado e as respectivas ações que o sistema (ou parte do sistema) executa em resposta a eventos. Além da estrutura e comportamento, a SysML inclui uma construção gráfica para representar requisitos baseados em texto para relacioná-las a outros elementos do modelo. Ela estabelece uma ligação entre as ferramentas de gerenciamento típicas da Engenharia de Requisitos e os demais modelos do sistema. O leitor encontrará detalhes da linguagem SysML nas referências apresentadas. No Anexo A2 do trabalho encontra-se um breve resumo da linguagem SysML.

70 70 No Capítulo 2 foi realizada uma revisão sobre conceitos utilizados na elaboração da proposta de método de auxílio apresentadas neste trabalho. No Capítulo 3 são apresentadas as abordagens comumente utilizadas para seleção e implementação de sistemas PLM. Com isso objetiva-se evidenciar as lacunas existentes e comprovar que o que está sendo proposto é de fato uma contribuição original.

71 71 3. ABORDAGENS EXISTENTES PARA PLM 3.1 ABORDAGENS CONSULTADAS NA LITERATURA Os sistemas de informação necessitam de avaliação antes e após sua implantação no ambiente de negócios para garantir que os objetivos estabelecidos sejam de fato alcançados. Segundo Eriksson e Penker (2000), é comum chegar à conclusão de que esses sistemas não suportam apropriadamente o negócio em que eles estão inseridos. Ainda segundo esses autores, existem várias razões para isso. Por exemplo, a especificação de requisitos não é realizada de forma correta, o time de implantação não entende satisfatoriamente o negócio ou não entende as mudanças que acontecem tão frequentemente no mercado. Para evitar ou minimizar esses problemas,, diversos métodos foram criados para estruturar o processo de implantações de soluções de TI nas empresas (ERIKSSON e PENKER, 2000). Segundo Colombo e Francalanci (2004), o processo de implantação de sistemas de informação, pode ser definido como uma sequencia de passos por meio dos quais, partindo de uma lista inicial, as organizações selecionam soluções de software para serem implantadas. E ainda segundo eles, a seleção de sistemas de informação é normalmente estruturada em três macro fases, quais sejam: Pré-seleção tem como objetivo reduzir o número de alternativas consideradas no processo de seleção; Análise visa possibilitar a obtenção de um entendimento detalhado das características funcionais e tecnológicas Negociação objetiva avaliar a capacidade de fornecedores proverem serviços de pós-venda (suporte) e avaliar a proposta comercial

72 72 Hansmann e Neumann (2002) apresentam uma abordagem para implantação de sistemas ERP (Enterprise Resource Planning). Segundo esses autores, nessa abordagem os processos podem ser considerados como uma fonte de informação para a definição de requisitos, mas a ênfase é dada aos requisitos individuais e frequentemente, dissociados do processo. Na abordagem desses autores, após a fase de seleção do sistema é que ocorre a análise mais detalhada dos processos atuais e a posterior definição do processo futuro. Segundo Zancul (2009), em geral a seleção de sistemas de informação pode ser realizada em dois momentos distintos de um projeto de implementação de software: No inicio do projeto, antes mesmo do mapeamento detalhado do processo atual (AS- IS), Ao longo do projeto, em conjunto ou após a especificação dos novos processos (TO-BE). A escolha adequada de software que atende as necessidades de uma empresa é fundamental para o sucesso de projetos de implantação de software (ZANCUL, 2009). Umble et al. (2003) alertam que possivelmente a implantação de software irá falhar ou o software cairá em desuso quando nela não há alinhamento consistentemente entre os processos de negócio, os aplicativos de software e as necessidades dos stakeholders. Zancul (2008) descreve em um estudo de caso, os problemas encontrados por empresa do setor automotivo em implantar ferramentas PLM atraso de 17 meses em relação ao plano inicial de implantação. Ainda nesse trabalho, esse autor identifica quatro causas principais para as dificuldades encontradas: Seleção de sistema com base em requisitos pouco detalhados, que não refletem todas as necessidades específicas dos processos de negócio; Planejamento do projeto sem considerar o real esforço de implantação necessário;

73 73 Baixo envolvimento dos usuários finais ao longo do projeto (stakeholders); Falta de metodologia para apoiar a implantação do PLM. Hansmann e Neumann (2002) elicitam sete etapas para a implantação de sistemas ERP (Enterprise Resource Planning): (1) Seleção do sistema; (2) Estudo preliminar; (3) Análise da situação inicial (AS IS); (4) Definição do conceito futuro (TO BE); (5) Implementação técnica (customização, configuração, programação); (6) Instalação; (7) Operação. Hansmann e Neumann (2002) propõem ainda que a seleção de software ERP seja realizada nas seis etapas seguintes: (1) Definição dos objetivos; (2) Especificação dos requisitos e atribuição dos pesos de cada requisito; (3) Mapeamento do mercado; (4) Análise e seleção de sistemas favoritos; (5) Testes de sistemas favoritos; (6) Seleção final. Segundo esses autores, a especificação dos requisitos (etapa 2) pode ser derivada da definição dos objetivos como também da documentação existente dos processos. Caso os processos não sejam documentados ou disponíveis, os autores sugerem a realização de uma modelagem em um nível pouco detalhada dos processos, com a documentação das

74 74 deficiências atuais, para apoiar a definição dos requisitos (HANSMANN e NEUMANN, 2002). Na abordagem de Hansmann e Neumann (2002 apud ZANCUL, 2009), após a fase de seleção do sistema é que ocorre a análise detalhada dos processos atuais (AS IS) e a posterior definição do processo futuro (TO BE). Ainda relacionado a sistemas ERP, Sousa e Saccol (2008) apresentam uma metodologia para seleção de sistemas baseada em recomendações presentes na literatura técnica especializada (BANCROFT, et al., 1998; HECHT, 1997; KRASNER, 2000; THEMISTOCLEOUS, et al., 2001; BERGAMASCHI, 1999; COLANGELO FILHO, 2001; MORAES FILHO e WEIGERG, 2002; RICCIO, 2001; SOUZA e ZWICKER, 1999). O método proposto por esses autores está alinhado com a contribuição dos demais autores já citados as funcionalidades das soluções ERP devem adequar-se às necessidades das empresas. Além disso, o método proposto por Sousa e Saccol (2008) aborda também outras dimensões envolvidas, que são usabilidade, a tecnologia, a cultura da empresa e de seus funcionários e, por fim, o lado comercial do negócio. O procedimento proposto pode é ilustrado pela Figura 3-1.

75 75 Procedimentos iniciais Designação de um grupo de responsabilidade; Identificação da sistemática e das necessidades; Determinação dos indicadores de desempenho; Determinação dos demais quesitos a serem avaliados; Determinação de um sistema de pontuação; (a) Seleção prévia Seleção de fornecedores; Seleção de produtos. (b) Avaliação funcional Análise do material de divulgação; Analise das funcionalidades. (d) Avaliação tecnológica e de mercado Seleção de fornecedores; Seleção de produtos. (c) Refinamento da análise Teste do sistema; Avaliação dos detalhes comerciais. Decisão Figura 3-1: Modelo de seleção de soluções ERP - Múltiplos filtros. Fonte: (SOUZA e SACCOL, 2008) O objetivo do método proposto por Souza e Saccol (2008) é eliminar sucessivamente as soluções ERP disponíveis no mercado por meio de diversos filtros de aderência às necessidades da empresa, >filtro (a)< seleção prévia, >filtro (b)< avaliação funcional etc. A aplicação do método é feita por uma série de procedimentos agrupados por etapas/filtros, que respeitam a prioridade das dimensões de avaliação eliminando alternativas a cada etapa e selecionado as mais aderentes às expectativas da empresa.

76 76 Relacionado especificamente ao tema seleção de PLM, somente poucos trabalhos são encontrados e relatados em seguida. Zancul (2009) propõe um método para selecionar sistemas PLM. Para isso ele desenvolve um modelo de referência para um sistema PLM, considerando funcionalidades possíveis, e utiliza esse modelo para selecionar o sistema PLM (software) que melhor se adequa aos processos de uma empresa. Esse método é ainda baseado em métodos utilizados para seleção de sistema de informação, especificamente sistemas ERP. Contudo, segundo Grieves (2006) PLM e ERP são sistemas bastante diferentes, não obstante serem complementares. Schuh et al (2008) apresenta um framework que consiste de um conjunto de modelos de processos de negócio que relaciona conceitos fundamentais, conhecimento corporativo e soluções de software e apoia a implantação da abordagem PLM. Ainda segundo esses autores, faltam pesquisas e publicações relacionadas ao processo de implantação da abordagem PLM. Grieves (2006) aborda o tema implementação de sistemas PLM do ponto de vista estratégico por meio da definição de um planejamento estratégico para PLM: visão, avaliação do status atual, plano de ação e os recursos necessários para implementar esse plano. Além disso, esse autor sugere que sejam utilizados ROI Return on Investments e ROA Return on Assets (PHILLIPS e PHILLIPS, 2007) como indicadores de desempenho para propor e medir os resultados de implantações PLM. Saaksvuori et al (2008) apresenta uma abordagem em que a implantação PLM é definida como sendo um projeto em que diferentes departamentos devem participar de sua implantação.. O projeto pode ser de longo ou curto prazo dependendo da dimesão da empresa e dos recursos disponíveis para investimento. Além disso, segundo o autor, nesse projeto deve ser possível gerenciar aspectos técnicos e mentais do processo de mudança na organização.

77 77 A maioria dos métodos desenvolvidos nos trabalhos analisados são variações, em menor ou maior grau, de métodos de auxílio à implantação de sistemas ERP ou estão direcionados para níveis elevados da organização em que são definidos a visão e estratégia PLM. Além disso, pode-se dizer que os métodos apresentados abordam de forma isolada e, muitas vezes de forma superficial, outras dimensões relacionadas a PLM, tais como, pessoas e processos. Nas abordagens analisadas, os processos podem ser considerados como uma das fontes para a criação dos requisitos, mas não sua fonte principal. Consequentemente, a visão de quais processos os aplicativos de software irão auxiliar pode se perder. Dessa forma, a busca por uma solução para resolver problemas ou dificuldades nos processos podem passar a ser uma busca desalinhada do objetivo principal aumentar a eficiência na realização dos processos. Assim, a definição de requisitos de sistemas PLM é prejudicada, pois ninguém sabe ao certo o que deve ser buscado. Além disso, esses autores propõem poucos indicadores de desempenho para a verificação do sucesso ou fracasso da implantação de aplicativos de software para PLM, resumindo-se a apenas ROI e ROA. Ainda como o objetivo de elucidar a contribuição do trabalho, foi elaborada uma análise sinótica dos principais trabalhos acadêmicos existentes sobre o tema. Essa análise é apresentada no Quadro 3-1.

78 Quadro 3-1 Análise sinótica dos trabalhos existentes relacionados ao auxilio a implementação PLM Autores Características (ZANCUL, 2009) (UMBLE et al., 2003) (GRIEVES, 2006) (SAAKSVUORI et al., 2008) Abordagem utilizada Desenvolvimento de modelos de referência, processos e identificação de boas práticas de implantação de sistemas ERP. Ênfase da proposta Seleção de sistemas PLM em função da aderência dos processos existentes a um modelo de referência desenvolvido. Identificação, em trabalhos anteriores relacionados a ERP, os fatores de sucesso e uma compatibilização desses trabalhos. Boas práticas existentes e os casos de sucesso. Aborda a implantação PLM no nível estratégico. Define visão, avalia a situação atual e planeja as mudanças necessárias a uma estratégia PLM. Definição da estratégia de negócios relacionada a implementação de sistemas PLM. Estrutura a implantação PLM com boas práticas de gerenciamento de projeto. Considera sistema PLM como uma ferramenta para auxílio aos processos. Gerenciamento das mudanças organizacionais e gerenciamento de projetos (projeto de implantação PLM). Uso de indicadores para avaliar a implantação Não aborda. Não aborda. Indica ROI e ROA como indicadores de desempenho, contudo não mostra como obter esses indicadores. Indicadores são abordados de forma implícita (indicadores de projeto): prazos, orçamento, etc. 78

79 Quadro 3-1: Continuação: Autores Características Zancul (2009) Umble et al, 2002 Grieves (2006) Saaksvuori et al (2008) Stakeholders Não usa o conceito de stakeholders. Aborda os usuários do sistema (software para PLM) como um tipo de stakeholder do sistema PLM. Não usa o conceito de stakeholders. Declara somente os usuários do sistema que são um tipo de stakeholder do sistema PLM. Não usa o conceito de stakeholders. Identifica os usuários do sistema PLM e membros da diretoria da empresa Não usa o conceito de stakeholders. Lista somente usuários do sistema PLM. Dimensões analisadas Processos de negócio e funcionalidades PLM Somente aplicativos de software e usuários Processos de negócios, funcionalidades PLM e pessoas. Processos de negócio. Análise de stakeholders do processo e de suas necessidades Não usa Não usa. Não usa. Não usa. Tipos de modelagem usada na proposta Uso de notações específicas de modelagem Nenhuma Nenhuma. Nenhuma. Nenhuma. Nenhuma Nenhuma. Nenhuma. Nenhuma. 79

80 ABORDAGEM ENCONTRADA NA INDÚSTRIA Na indústria a abordagem comumente encontrada para a seleção de sistema PLM é a de uso de questionários que buscam obter informações sobre a empresa e seus processos para que, a partir da análise dessas informações, sugerir um sistema PLM mais adequado ao perfil da empresa. Esse processo é ilustrado pela Figura 3-2. Definição das necessidades do negócio Listar soluções PLM Comparar soluções da lista Responder a questões sobre as necessidades do negócio Listar todos os fornecedores para a criação de uma lista de soluções. Priorização das necessidades e comparação dos fornecedores sob a ótica de priorização Figura 3-2: Processo comumente encontrado para a definição de soluções PLM Esse processo é encontrado, com algumas pequenas variações, em portais na internet de seleção de soluções de TI, tais como, ERP e PLM. Na Figura 3-2, o Passo 1 para a definição de um sistema PLM é o estabelecimento das necessidades organizações. Essa definição é obtida por meio de questionários objetivos de múltipla escolha. Por exemplo, a empresa pode ser questionada sobre qual é o seu negócio e em qual setor industrial ela atua (Manufatura, Processos ou Engenharia). Ainda pode ser questionado número de usuários, como eles estão distribuídos e as funcionalidades que são necessárias para a organização etc.

81 81 O Passo 2 é obter uma lista preliminar de fornecedores que possivelmente atenderão as necessidades organizacionais listadas. O terceiro e último passo (Passo 3) é a comparação de funcionalidades das soluções listadas no Passo 2 considerando as necessidades organizações encontradas no Passo 1. Uma abordagem alternativa pesquisada pelo autor é a elaboração de questionários pré-existentes para a realização do Passo 1 e o envio para possíveis fornecedores. Após o envio das respostas dos fornecedores, as empresas as analisam para selecionar uma lista de fornecedores que podem ser utilizada para uma nova etapa no processo de seleção, por exemplo, testes das soluções selecionadas. No mercado, também, são encontradas consultorias, cujos serviços são direcionados a implementação de soluções PLM no ambiente organizacional. Essa implementação vai desde o desenvolvimento de uma estratégia PLM até o monitoramento dos resultados obtidos pela implementação (IBM, 2011; CIMADATA, 2011). No Capítulo 2 foi realizada uma revisão sobre conceitos utilizados na elaboração da proposta de método de auxílio apresentado nesse trabalho e no Capitulo 3 foram mostrados as abordagens comumente realizadas para implementação de sistemas tais como, PLM. No Capítulo 4 é apresentada a eleaboração do método REQ4PLM utilizando os conceitos apresentados até aqui, objetivando o preenchimento de lacunas identificadas no processo de seleção de aplicativos PLM.

82 82 4. DESENVOLVIMENTO DO MÉTODO REQ4PLM Neste capítulo é apresentado um método de trabalho para auxiliar na identificação dos requisitos de um sistema PLM para ser usados na sua implantação. Esse método apresenta os processos de negócio, seus stakeholders e a infraestrutura PLM como componentes fundamentais de um sistema PLM. Os dois primeiros componentes definem o terceiro, já que os stakeholders estão interessados nos processos e as tecnologias suportam os processos. Na Figura 4-1, os stakeholders têm intereses que podem ser traduzidos em requisitos para o sistema PLM ou processo; a infraestrutura PLM, por sua vez, suporta os processos e os processos podem fornecer requisitos para o sistema PLM. Processos Infraestrutua PLM Stakeholders Requisitos Interesses Sistema PLM Suporte Figura 4-1: Representação dos componentes de um Sistema PLM e suas (adaptado de Grieves, (2006)). A Figura 4-2 apresenta os subsistemas e a hierarquia de um sistema PLM. A melhor infraestrutura possível PLM pode não funcionar bem se os processos de negócio a ela associados não estiverem bem estruturados. A partir dessa perspectiva adicionam-se novos

83 83 componentes à estrutura PLM apresentada e busca-se identificar uma abordagem sistemática para desenvolver os relacionamentos dentro da nova estrutura PLM proposta. Software PLM Infraestrutura PLM Hardware Processos Sistema PLM Usuários Figura 4-2: Sistema PLM e seus elementos: uma nova proposta Essa abordagem de relacionamentos é estruturada a partir de conceitos de Engenharia de Sistemas (ES) apresentada na seção 2.7. Na perspectiva de ES, os problemas são abordados em um processo interativo top-down de síntese e validação que considera o ciclo de vida do sistema, os stakeholders e suas necessidades documentando-as na forma de requisitos e modelos. Para orientar a elaboração do método, utilizou-se a norma de projetos VDI que estrutura o desenvolvimento de uma solução em dois domínios: o domínio do problema e o domínio da solução (CROSS, 2004). A Figura 4-3 mostra que no domínio do problema existem processos com stakeholders e que estes possuem necessidades. No Domínio da Solução há o método proposto que deve ser desenvolvido para selecionar requisitos para sistemas PLM e satisfazer os critérios seguintes:

84 84 Considerar os diversos aspectos envolvidos no processo de implantação, proporcionando uma visão ampla do problema, Garantir a integração desses requisitos ao negócio, e Proporcionar uma maneira de acompanhar o processo de implantação. Relacionadas aos Processos Necessidades Método dos Stakeholders Domínio do problema Domínio de solução Figura 4-3: Desenvolvimento do método domínio do problema e da solução Uma maneira de fazer com que o método proposto considere os diversos aspectos do processo de implantação envolvidos e que esteja integrado ao negócio é fazer com que as necessidades dos stakeholders sejam utilizadas no método. A Engenharia de Sistemas propõe que as necessidades dos stakeholders sejam reescritas na forma de requisitos e que sejam consideradas como matéria prima para a síntese de uma solução ou sistema. Para garantir que o método proporcione uma maneira de acompanhar o processo de implementação PLM, propõe-se que os benefícios auferidos pela implementação, sejam medidos por meio de indicadores de desempenho dos processos, relacionados ao atendimento ou não das necessidades dos stakeholders. O método proposto descrito a seguir atende aos pressupostos acima discutidos. Com o problema apresentado acima, foi desenvolvido o método apresentado nas próximas seções. A função principal do método proposto é apresentada na Figura 4-4 por

85 85 meio de um diagrama da caixa preta (TRABASSO, 2005). Nesse diagrama são mostradas ainda as entradas e saídas do método proposto. Informações sobre processo Necessidades do negócio Auxiliar implantação de Sistemas PLM Indicadores de desempenho Requisitos para o sistema PLM Figura 4-4: Diagrama da caixa preta- mostrando a função principal do método desenvolvido A Figura 4-5 apresenta o desdobramento da função principal (Figura 4-4) em sub funções que compõem o método por meio do diagrama da caixa transparente (TRABASSO, 2005). Informações sobre o processo Mapear e Modelar Processos Mapa de processo Analisar Stakeholders Análise de stakeholders Determinar requisitos Requisitos Necessidades do negócio Mapa de processo Definir indicadores de desempenho Necessidades dos stakeholders Indicadores de desempenho Figura 4-5: Diagrama de atividades mostrando as etapas do método desenvolvido As próximas seções detalham as subfunções do método apresentadas na Figura ETAPA I MAPEAR E MODELAR PROCESSOS Nesta etapa, os processos de negócio devem ser mapeados, modelados e validados com seus participantes. Dentre as diversas notações de modelagem disponíveis, o método prescreve a notação BPNM (Business Process Notation Modeling) (OMG, 2010). Ela foi

86 86 escolhida por ser uma notação de fácil entendimento pelos diversos interessados no processo, desde os analistas de negócios responsáveis pelo primeiro draft do processo, até os técnicos responsáveis por implementá-los em ferramentas de TI, o que preenche uma lacuna nas linguagens de modelagem de processos existentes até então (OMG, 2010). O Quadro 4-1 apresenta um sumário da etapa >mapear e modelar processos<. Quadro 4-1: Mapear e modelar processos Sumário: Mapeamento e modelagem de processos Informações sobre Entrada: os processos Entrevistas, questionários, reuniões, workshops, observação de campo, análise da Modelar processos documentação existente, análise de sistemas Modelos de legados, coleta de evidências. processo Saída: Mapa e Modelo dos processos. Motivação/Descrição Por que? O sistema PLM deve suportar os processos do ciclo de vida do produto. Dessa forma, é natural iniciar o processo de implantação, entendendo os processos de negócio: objetivos, participantes, recursos e métodos utilizados. O que? Coletar e descrever todas as informações relevantes no contexto dos processos do ciclo de vida, particularmente para a implantação de um sistema PLM. Como? As informações são coletadas em entrevistas, questionários, reuniões e workshops, observação de campo, análise da documentação existente, análise de sistemas legados, coleta de evidências etc. Depois disso, os processos são modelados para utilização em outras etapas do método. Onde? A modelagem de processo forma o conhecimento básico usado no método proposto. Os modelos de processo são utilizados em etapas subsequentes do método proposto. Ferramentas: Mapeamento e modelagem de processos, Enterprise Architect TM 4.2 ETAPA II ANALISAR STAKEHOLDERS No método proposto, a Análise de stakeholders consiste em coletar e analisar informações para determinar quem sãos os interessados no processo e o que deve ser levado em conta na implementação do processo PLM. Nessa atividade é utilizado o modelo de

87 87 processo elaborado na atividade 3.1. O Quadro 4-2 mostra, a título de exemplo, a análise stakeholders do processo de gerenciamento de mudanças de engenharia que é uma das funcionalidades de um sistema PLM. Neste exemplo, para cada stakeholder identificado, é feita análise para estabelecer seus interesses com relação ao processo, qual é o seu protagonismo, quais os riscos relacionados aos stakeholders. No exemplo apresentado, os projetistas têm um interesse de >melhorar o controle dos dados criados< possuem o papel de > realizar as mudanças necessárias para atualizar o produto<. Ainda relacionado a esses stakeholders, existe o risco identificado de que >não se comprometam com iniciativa de implementação PLM<, cujo impacto é >alto< para sucesso da iniciativa. Quadro 4-2: Exemplo de análise realizado em stakeholders do processo de mudanças de engenharia Stakeholder Projetistas Gerentes Engenheiros Fornecedores Interesse no processo Melhor controle dos dados do produto Eficiência na manipulação dos dados Os requisitos do produto devem ser respeitados Fornecer insumos para o novo produto modificado Qual é o papel do stakeholder no processo? Realizar mudanças no projeto CAD atual Supervisionar as atividades durante a modificação Aprovar tecnicamente as modificações Conhecimento rápido sobre o que mudou Riscos percebidos Não se envolver na iniciativa de implantação do sistema, pois não partilham da necessidade de melhor acesso à informação. O gerente da área não tem liderança sob restante do grupo Os engenheiros estão sobrecarregados no preenchimento de relatórios e podem não querer participar Descumprimento dos prazos acordados inicialmente Impacto potencial no processo alto alto alto baixo

88 88 No caso de processos, os stakeholders podem ser identificados por meio da análise das entradas, saídas, controles e mecanismos de cada elemento do processo analisado, conforme sugerido por Loureiro (1999). O Quadro 4-3 apresenta um sumário da etapa: Analisar Stakeholders do método desenvolvido. Quadro 4-3: Analisar de stakeholders Sumário: Análise de Stakeholders do processo Entrada: Processo Processo na forma de modelos, informações coletadas no ambiente do processo e outras Analisar stakeholders informações relacionadas aos processos analisados (Ex. Lista preliminar de stakeholders). Saída: Stakeholders Análise dos indivíduos ou organizações (stakeholders) que têm interesse nos processos e, consequentemente, podem ter requisitos para o sistema PLM. Motivação/Descrição Por que? É fundamental atender adequadamente as necessidades dos stakeholders para o sucesso de qualquer solução proposta para melhoria de processos. O que? Identificar e analisar qualquer indivíduo e/ou organização que possuam interesses relacionados aos processos ou interesse na implantação PLM Como? As análises são realizadas utilizando os modelos de processos desenvolvidos, entrevistas, e demais informações coletadas em observação de campo e documentos existentes. Onde? Stakeholders são fontes de requisitos e seus interesses devem ser descritos e analisados para geração desses requisitos em etapas posteriores do método. Ferramentas: Análise de stakeholders 4.3 ETAPA III DEFINIR INDICADORES DE DESEMPENHO Nessa etapa, o método prescreve a criação de indicadores de desempenho para o processo atual, bem como a meta desejada para esses indicadores. Nesta etapa é aplicado o método PERISCOPE (Performance Indicators Scope) (ACOSTA, 2004) que foi escolhido devido a sua simplicidade e reprodutibilidade. Para

89 89 atender aos objetivos deste trabalho, esse método foi adaptado retirando-se etapas já cumpridas pelo método proposto e adicionando-se uma nova atividade em que são definidas uma referência (base line/ meta) para medições absolutas ou relativas e a dimensão de tempo, de acordo com as recomendações de Mackrell (2004). O método PERISCOPE adaptado é apresentado na Figura 4-6. act [Activ ity] Indicadores [Indicadores] Entradas Saida Stakeholders Descrição do processo (from Method) (from Method) Indicadores e seus atributos 1. Identificar v alor para o cliente 6. Definir Base Line/Meta/Prazo 1. O que os stakeholders vêem como valor? 2. Para cada valor acima, qual é o subprocesso "responsável" pela sua incorporação? 3. Qual é o aspecto mais relevante para cumprir o item de valor? 4. Porque é que este aspecto é importante? Apontar algumas das suas características. 5. Como essas características devem ser avaliadas, a fim de ser um indicador do processo? 6. Definir outros atributos: Baseline/Meta/Prazo necessários a iniciativa PLM (from Method) 2. Identificar sub-processo gerador de v alor (from Method) (from Method) 5. Identificar forma de medição (from Method) 3. Identificar aspectos que geram v alor 4. Identificar caracterisiticas desses aspectos (from Method) (from Method) Figura 4-6: Abordagem para determinação de indicadores de desempenho do processo O Quadro 4-4 apresenta o sumário da etapa: Definir Indicadores de Desempenho do método. Nesta etapa os processos de negócios são utilizados como entrada para definição de indicadores. Esses indicadores objetivam obter parâmetros quantitativos para comparar o desempenho da organização na execução de um determinado processo durante e após a implantação de PLM.

90 90 Quadro 4-4: Definir Indicadores de Desempenho Sumário: Definição de indicadores Modelos de Entrada: processo Necessidades dos stakeholders, em especial os Análise de clientes do processo e informações do Definir indicadores de stakeholders processo. desempenho Saída: Análise dos indivíduos ou organizações (stakeholders) que têm interesse nos processos Indicadores de e, consequentemente, podem ter requisitos para desempenho o sistema PLM. Motivação/Descrição Por que? Porque é necessário entender e medir a geração de valor alcançada pelo atendimento das necessidades dos stakeholders em qualquer momento do ciclo de vida da solução proposta (Seleção, Implementação e upgrade do sistema). O que? Definir indicadores de desempenho que caracterizam o atendimento das necessidades dos stakeholders em qualquer momento do ciclo do sistema PLM. Como? Definindo indicadores de desempenho que incorporem geração de valor para os stakeholders do processo Onde? Stakeholders são quem ficarão satisfeitos (ou não) pela introdução de um solução técnica ou metodológica. Após a definição de suas necessidades deve-se medir o atendimento de seus interesse por meio de indicadores de desempenho. Ferramentas: Método PERISCOPE modificado com novos atributos: Baseline, meta e prazo 4.4 ETAPA IV DETERMINAR REQUISITOS PARA O SISTEMA PLM Após a identificação dos stakeholders e de suas necessidades, os requisitos a eles associados podem ser elaborados. Até essa etapa, é comum obter informações vagas e subjetivas. Por exemplo, um gerente de engenharia gostaria de: Aumentar a eficiência do processo de modificação de engenharia. A necessidade exemplificada está no Domínio do Problema, relacionada a um processo específico, o processo de Gerenciamento de mudanças de engenharia. Sabendo-se que os stakeholders têm necessidades relacionadas aos processos, as seguintes perguntas podem ser elaboradas: O que pode ser feito para suprir essa necessidade?

91 91 Porque existem mudanças de engenharia? Porque os stakeholders precisam de eficiência nesse processo? É possível que poucas ou nenhuma resposta seja apresentada pelos stakeholders. É muito mais provável que isso ocorra se a necessidade estiver relacionada a uma tecnologia que os stakeholders não conhecem ou dominam, como é o caso da abordagem de negócios PLM. Contudo, mesmo assim eles são quem devem ficar satisfeitos pela proposição de uma nova abordagem de negócios que alia tecnologia de informação e novos métodos de trabalho. Portanto, os stakeholders devem ter voz na definição dos requisitos, para que um sistema PLM possa ser implantado com êxito. Para isso, é previsto que os requisitos sejam desenvolvidos a partir da análise de informações coletadas em entrevistas semiestruturadas, com roteiros sintéticos que orientam o diálogo estabelecido entre a pessoa que está usando o método proposto e os stakeholders do processo. Esses roteiros podem incluir perguntas semelhantes àquelas apresentadas no inicio dessa seção. Pode-se, também, usar a análise de evidência em documentos existentes e as saídas dos processos como fontes de requisitos (ALEXANDER e STEVENS, 2002). No início das entrevistas, sugere-se apresentar aos stakeholders os objetivos do trabalho para que eles avaliem sua relevância, e de fato colaborem com a proposta, manifestando suas opiniões mesmo em assuntos sensíveis, como >Os problemas e limitações do processo<. A Figura 4-7 resume a etapa de derivação de requisitos dos stakeholders. Nela, os documentos empilhados representam as informações geradas ou recebidas durante o processo e as figuras ovais são as funções necessárias para determinação dos requisitos. A função >Analisar e Modelar< é executada para determinação dos requisitos dos stakeholders em função das necessidades identificadas na etapa anterior. Além disso, por meio dela, criam-se os modelos para atender os requisitos dos stakeholders previamente definidos. Esses modelos

92 92 são analisados e pode-se obter os requisitos funcionais do sistema usados para orientar o processo de implementação de Sistemas PLM. Stakeholders Necessidades dos stakeholders Processos BPMN Modelos SysML Analisar e modelar funcional Derivar Requisitos Resultados da Análise Requisitos Figura 4-7: Processo de determinação de requisitos de implementação. Os requisitos dos stakeholders identificam as capacidades (capabilities) desejadas por eles para melhorar os processos de negócio, sem responder como elas podem ser satisfeitas. Além das capacidades identificadas, outra fonte de requisitos dos stakeholders pode ser as restrições relacionadas à aquisição de soluções tecnológicas ou mesmo à implementação da solução. No caso de sistema PLM, essas restrições estão usualmente associadas a custo e prazo. Os modelos desenvolvidos podem também ser consultados sempre que necessário para desenvolver novos requisitos e implementar novas funcionalidades ao sistema.

93 93 A modelagem de sistemas auxilia o processo de análise, pela introdução de um grau de formalidade à medida que os sistemas são definidos: requisitos dos stakeholders geram modelos que, por sua vez, geram os requisitos funcionais do sistema. O método proposto prescreve o uso dos seguintes diagramas: Diagramas de contexto para identificar os fluxos de informação entre sistema e atores; Diagrama Use Case para definir funcionalidades do sistema que devem atender os fluxos identificados e Diagramas de Blocos para modelar a estrutura do sistema PLM. Os diagramas de contexto (vide Figura 4-8) são utilizados para modelagem da interação do sistema PLM e as diversas entidades externas do ambiente onde o sistema PLM irá atuar. O objetivo desse diagrama é obter informações iniciais sobre os fluxos de ou para o sistema. As entidades externas são os atores do sistema e os fluxos são descritos como fluxos de informação. O diagrama de contexto é um diagrama pré-definido nas abordagem de modelagem de sistemas SYSMOD proposta por Weilkiens (2006) e no trabalho de Loureiro (1999; 2006). Esse diagrama é formalmente composto por elementos padrões SysML e pode ser modelado por qualquer ferramenta que utilize essas linguagens. São utilizados diagramas de bloco e diagrama interno de blocos como diagramas padrão para construção dos diagramas de contexto.

94 94 bdd [SysML Block Definition] v iew [v iew] Actor2 Actor1 «System» Sistema «flow» «actor» outro sistema Actor3 Figura 4-8: Exemplo de diagrama de contexto Casos de uso (use cases) representam as funcionalidades fornecidas ao ambiente e são usados como elementos centrais na análise de requisitos funcionais. As funcionalidades do sistema determinam o propósito de sua existência. Casos de uso auxiliam no refinamento de requisitos de stakeholders em requisitos funcionais, descrevendo-os em maiores detalhes. Numa abordagem top-down, use cases permitem visualizar detalhes do sistema nas etapas iniciais do processo de implementação PLM. Os diagramas de blocos (Block Definition Diagram) foram utilizados para representar a estrutura do Sistema PLM associando funcionalidades aos componentes do sistema. Os blocos possuem informações sobre eles mesmos (atributos), ou fazem referência a outros blocos que estão no seu entorno. O diagrama de blocos para SysML é o diagrama de classes para UML (WEILKIENS, 2006). Devem ser definidas as relações com ambiente em que o sistema irá operar, entre elas: Os sistemas existentes que interagirão com o novo sistema; As pessoas que interagirão com o sistema;

95 95 As ameaças que o sistema deve estar preparado para se defender; Os efeitos adversos que devem ser prevenidos. Definir título do quadro e citá-lo no texto. O Quadro 4-5 apresenta o sumário da etapa de determinação de requisitos. Quadro 4-5: Determinar Requisitos para o sistema PLM Analise de stakeholders Determinar requisitos Requisitos de stakeholders Sumário: Determinação de requisitos Entrada: Análise de stakeholders e todas as informações usadas nessa análise Saída: Requisitos e consequente detalhamento das necessidades dos stakeholders e definição de funções do sistema. Motivação/Descrição Por que? Os requisitos são a base para o desenvolvimento de sistema. Eles determinam o que o sistema vai oferecer. O que? Os requisitos são obtidos a partir das necessidades dos stakeholders e documentados numa estrutura de requisitos. Como? Os requisitos são determinados por meio de técnicas de identificação de informações sobre as deficiências dos processos atuais e modelados em diagramas de requisitos SysML. Onde? O desenvolvimento de requisitos dos stakeholders é um passo intermediário para a obtenção de requisitos do sistema. Ferramentas: Diagramas SysML Entrevistas usando roteiros pré-estabelecidos (Anexo A2) Por fim o Quadro 4-5 apresenta a ultima etapa do método que é a determinação do que o sistema irá realizar na forma de requisitos do sistema PLM. O Capítulo 4 apresentou o método REQ4PLM. A apresentação constitui-se dos de mostrar, justificar e relacionar os componentes usados para obtenção dos objetivos estabelecidos no inicio da pesquisa. No Capítulo 5 é apresentada a aplicação do método em um ambiente de desenvolvimento de produto.

96 96 5. DEMONSTRAÇÃO DO MÉTODO REQ4PLM Neste capítulo é realizada a demonstração do método proposto por meio de sua aplicação em processos do ciclo de vida de produtos. Para isso, foi necessário definir uma empresa que possuísse as seguintes características mínimas: Empresa que desenvolve produtos; Empresa que busca melhorar seus processos relacionados ao ciclo de vida dos produtos; Empresa de fácil acesso ao autor. Considerando os critérios acima, o local escolhido para a demonstração do método foi o Departamento de Desenvolvimento de Produtos Industriais do SENAI CIMATEC em Salvador BA. Os processos analisados dentro dessa organização são os processos do ciclo de vida de produtos desenvolvidos pelo CIMATEC. O DPI (Desenvolvimento de Produtos Industriais) é um departamento do SENAI CIMATEC que presta serviços técnicos de engenharia à indústria baiana e brasileira. A área desenvolve produtos de baixa complexidade cujas etapas consistem em design e concepção, projeto de engenharia, projeto e fabricação de moldes. A relevância da aplicação do método no DPI está nos processos por ele executados, que são semelhantes àqueles encontrados na indústria. As seções 4.1 e 4.2 foram desenvolvidas para fornecer o leitor informações complementares ao entendimento do trabalho. A seção 4.1 descreve a ferramenta CASE utilizada para modelagem de modelos em SysML/UML. A seção 4.2 descreve o ambiente que foi aplicado o método REQ4PLM. As demais seções( ) apresentam a aplicação do método propriamente dita.

97 FERRAMENTA COMPUTACIONAL UTILIZADA O software Enterprise Architect TM (SPARX-SYSTEMS, 2011) é uma ferramenta CASE para especificar, documentar e desenvolver projetos de software, arquitetura empresarial e sistemas em geral. Ela utiliza as linguagens BPMN, UML e SysML como notações de modelagem. As notações disponíveis permitiram usar essa ferramenta para modelagem dos processos executados pelo DPI no desenvolvimento de produtos industriais usando a notação BPMN e possibilitaram também a modelagem do sistema PLM em linguagem SysML e a consequente definição de seus requisitos. 5.2 DEPARTAMENTO DPI E A INFRAESTRUTURA PLM EXISTENTE O departamento DPI desenvolveu, ao longo dos anos, processos para projetar produtos, Projetar Moldes e Planejar e Controlar Manufatura. Constatou-se que os processos possuem diversos desperdícios gerando retrabalhos. Não obstante, esses processos são executados repetidamente pelo DPI no ciclo de vida dos produtos. O DPI não tem produto próprio, mas participa do ciclo de vida de produtos desenvolvidos para seus clientes. Dessa forma, os processos são ajustados conforme as necessidades estabelecidas em contrato de prestação de serviços. As ferramentas PLM como CAD, CAM, CAE foram selecionadas conforme a perspectiva isolada de cada usuário especialista e não a partir de um consenso sobre quais ferramentas seriam as melhores para a realização dos processos. Consequentemente, formouse uma panaceia de ferramentas adquiridas ao longo dos anos desconsiderando-se os aspectos de integração de dados nas várias etapas do ciclo de vida dos produtos em que o DPI participa. Vide Quadro 5-1.

98 98 Quadro 5-1: Ferramentas PLM (CAD/CAM/CAE) utilizados no DPI Ferramentas requeridas CAD CAM CAE PDM Ferramentas utilizadas RHINOCEROS, SOLIDWORKS e AUTOCAD SurfCAM COSMOS, FEMAP e NASTRAN WINDOWS EXPLORER As funcionalidades de ferramentas como PDM são desconhecidas pela maioria dos colaboradores, muito embora afirmações, tais como, algo deveria gerenciar os dados e informações sobre o produto para organizar melhor as coisas puderam ser constatadas ao longo deste trabalho. O intercâmbio de dados entre essas ferramentas é realizado utilizando descrições matemáticas do produto (2D/3D) em formatos de arquivos distintos, tais como, *.stp (STEP) ou *.igs (IGES). As informações não geométricas (atributos e requisitos do produto e processo) são documentadas em diversos formatos (*.doc,*.xls, *.ppt, *.txt, *.pdf e *.mpp). Esses documentos foram padronizados com a utilização de templates, mas não existe controle de revisões ou de acesso a esses templates. Para o gerenciamento dos arquivos é utilizado o software Windows Explorer TM encapsulado no sistema operacional Windows TM. Verificou-se que o processo para elaboração desses arquivos e suas revisões não são transparentes para os integrantes da equipe de desenvolvimento. O processo de gerenciamento das mudanças do produto é de difícil execução por causa dos diversos formatos de informação, entre outros. Por exemplo, se é realizada alguma mudança no produto, todo o desenvolvimento de trajetórias de usinagem deve ser refeito porque não é utilizada uma abordagem de Master Model.

99 MAPEAR E MODELAR PROCESSOS O ciclo de vida dos produtos desenvolvidos no DPI começa com a identificação de uma necessidade no mercado por seus clientes. Como resposta a essa necessidade, é elaborada a concepção inicial do produto e apresentação ao cliente na forma de briefing de Design (Estilo e Funções principais). A concepção inicial inclui a pesquisa de mercado por produtos similares e posicionamento do conceito no mercado de atuação. São avaliados também preço de venda, funções e características físicas tais como peso, cor e forma. Esse estudo resulta na identificação de requisitos do consumidor e restrições do mercado. Constatou-se que esses requisitos não são elaborados e documentados com a participação de todos os interessados no projeto: são criados e usados pelos projetistas com a finalidade única de concepções de produto. Após a anuência do cliente com o conceito apresentado, a etapa de projeto de engenharia é executada, onde as funções do produto são implementadas na forma de soluções de engenharia. Após a conclusão do projeto do produto, ele é usado, quando aplicável, como base para desenvolvimento, manufatura e testes (tryout) de moldes de injeção. Moldes, protótipos e a documentação técnica pertinente são entregues à empresa cliente no final do processo. Ao longo de dois meses de investigação, foi realizada a modelagem dos processos para desenvolvimento de produtos do DPI. Inicialmente, buscou-se um melhor entendimento desses processos, níveis de maturidade, pontos fortes, pontos fracos, riscos e pessoas. Para essa etapa de aplicação do método, as pessoas envolvidas nos processos foram consultadas para se conhecer o que elas faziam, para quem elas se reportavam, quais as informações elas geravam e recebiam. Observou-se como cada pessoa realizava suas tarefas e atividades, registrando tempo médio de realização de cada tarefa e ainda procurou-se entender quais eram as conexões entre as tarefas.

100 100 Além disso, foram analisados documentos (políticas, procedimentos e instruções de trabalho). Por fim, foi investigada a relação com clientes e fornecedores e o impacto dessa relação nos processos. A modelagem dos processos é apresentada nas Figuras 5 1 a 5 6. Nelas encontram-se os modelos dos diversos processos analisados e validados com os seus stakeholders. A Figura 5 1 representa o macro processo analisado e as demais ( Figura 5 2 a 5 6) são subprocessos desse processo.

101 BPMN Desenvolv imento de produtos PedidoAberto SGPS «BusinessProcess» Projetar produto Aprovação interna Figura 5-1: Processo de desenvolvimento de produtos 101 «Pool» DPI Modelos e especificações do produto «BusinessProcess» Desenv olv imento de Pré-Projeto do Molde Pré-Projeto aprovado? sim «BusinessProcess» Projetar Molde Lista de materiais I Lista de materiais II «BusinessProcess» Aquisição de produtos e serv iços Fechamento do molde definido «BusinessProcess» Planejar e controlar a manufatura Lista de serviços Solução definida «BusinessProcess» Manufaturar Molde Produtos e serviços Analisar problema Tryout do molde problema identificado Entrega «Lane» Administração «Lane» NPFR «Lane» NDES BPMN Processos «BusinessProcess» BusinessProcess «Informação» não O simbolo no canto inferior direito indica que existem subprocesso ou tarefas relacionados ao processo. «Informação» Evento O simbolo indica que um determinado evento inicia uma outra etapa do processo. Dados gerados O simbolo indica que informação/energia/material são gerados na atividade(saída) e são utilizados em outras atividades(entrada). As setas indicam o fluxo. «Informação» «Infomação»

102 BPMN Projetar produto Oferta aceita não «BusinessProcess» Desenv olv er conceito Aprovação interna não sim Conceito aprovado? sim não «BusinessProcess» Desenv olv er projeto de Engenharia Aprovação externa(cliente) Aprovação interna Projeto aprovado? Figura 5-2: Processo de Projetar do produto sim Projeto aprovado? Aprovação externa (Cliente) sim 102 link para projetar molde

103 BPMN Projetar Molde Inicio Definir Plano de fechamento Elaborar lista de materiais Detalhar projeto do molde RD-Registro de Desenho Geometria de fechamento Projetar refrigeração Projetar mecanismo de extração Gerar RD Gerar informações necessarias para Tryout Projeto Aprovado Aprovação interna sim fim não Revisar projeto Figura 5-3: Processo de projetar molde Verificar interferencia na montagem do molde 103

104 BPMN Planejar e controlar a manufatura StartEvent3 Realizar reunião inicial de planejamento não Planejamento 2D Planejamento de execução Planejamento 3D Aprovação interna Planejamento aprovado? Figura 5-4: Processo de planejamento da manufatura sim fim 104

105 BPMN Planejamento 2D inicio Definir estratégia de manufatura de cada item Estimar tempo de cada item fim Figura 5-5: Processo de planejamento usinagem 2D BPMN Planejamento 3D Definir programação CNC Definir e moldelar eletrodos Elaborar folhas de setup dos eletrodos inicio Estimar tempo de manufatura Definir ponto de controle fim Figura 5-6: Processo de planejamento usinagem 3D 105

106 106 Após o trabalho de Mapeamento e Modelagem, os modelos foram utilizados como uma ferramenta de comunicação para facilitar o entendimento por todas as pessoas envolvidas diretamente e indiretamente na realização das atividades e tarefas e com aquelas interessadas no resultado gerado pelo processo. O modelo foi apresentado aos stakeholders para avalição e obtenção de informações adicionais sobre os processos e quais eram, segundo os stakeholders, as oportunidades de melhoria dos processos. Essas informações são apresentadas na seção ANALISAR STAKEHOLDERS Após o mapeamento e modelagem dos processos, seus stakeholders foram identificados e analisados conforme o método proposto. Para garantir que stakeholders importantes do processo não fossem esquecidos, os processos foram analisados de forma semelhante àquela apresentada por Loureiro (1999), quanto às entradas, saídas mecanismos e controles relacionados ao processo. Os stakeholders devem possuir uma justificativa para estarem na lista de stakeholders e essa justificativa pode ser detalhada em Interesses e Papéis nos processos, Riscos e Impactos percebidos. A Figura 5-7 resume o procedimento adotado.

107 107 Processo Detalhar Entradas, Saídas, Controles e Mecanismos. Desdobrar Stakeholders Analisar/Detalhar Interesse no processo Papel no processo Riscos percebidos Impacto Figura 5-7: Mecanismo de análise de stakeholder do processo No nível mais elevado do ciclo de vida do produto, o DPI executa os processos mostrados na Figura 5-1. A Figura 5-8 apresenta as entradas, saídas, controles e mecanismos detalhados do ciclo de vida do produto.

108 108 Investidores Diretoria Designers Gerente DPI Clientes Engenheiro produto Investimentos Pedidos Requisitos Restrições de mercado Normas ABNT Padrões gerenciais Ciclo de Vida do Produto Insumos Pessoas Software Máquinas e equipamento Temas para pesquisa tecnológica Reputação Faturamento Produtos/serviços Desperdícios e Desperdícios Concorrentes ABNT Fornecedores Governo Engenheiro MFG Figura 5-8: Entradas, saídas, mecanismos e controles do Ciclo de Vida do Produto e os stakeholders identificados. Os stakeholders identificados na Figura 5-8 influenciam ou são influenciados pelos processos do ciclo de vida do produto, relacionando-se às entradas, saídas, mecanismos e controles do processo. Por exemplo, os fornecedores preocupam-se em suprir necessidades do processo com insumos necessários para sua realização; um engenheiro de manufatura preocupa-se com o produto de tal sorte, que este seja fabricado com custo satisfatório e com a qualidade esperada pelos clientes que também são stakeholders dos processos. Os processos analisados a seguir: Projetar produto, Projetar Molde e Planejar e Controlar Manufatura, foram selecionados em virtude de serem críticos ao sucesso do ciclo de vida do produto e executados pelo DPI. Além disso, segundo relatos de stakeholders, nesses processos residem desperdícios consideráveis à organização PROCESSO PROJETAR PRODUTO Dentro do ciclo de vida dos produtos desenvolvidos pelo DPI há o processo de Projetar Produto detalhado na Figura 5-9. Esse processo define funcionalmente quais soluções

109 109 de engenharia devem ser implementadas para atender as necessidades dos clientes da empresa. Clientes Diretoria Gerente DPI INMETRO Necessidade Restrições Normas ABNT. Projetar Produto Padrões gerenciais. Projeto de produtos Desperdícios Software Hardware Designers e Engenheiros Serviços Designers Engenheiro produto Engenheiro MFG Fornecedores Figura 5-9: Entradas, saídas, mecanismos e controles do processo projetar produto. As maiores preocupações identificadas dos stakeholders relacionadas a esse processo são a redução de retrabalhos, controle de modificações e rastreabilidade das atividades realizadas (definição de quem, quando e porque algo foi feito) já que é comum na empresa, a participação de uma mesma pessoa em vários projetos simultaneamente. Essas preocupações refletem experiências anteriores dos stakeholders no desenvolvimento de projetos semelhantes. O controle de mudanças é realizado usando planilhas Excel TM. Apesar de ser um registro válido para uma auditoria, não existe controle de revisões desse documento e muitas vezes os dados são duplicados em backups durante o projeto, o que pode dificultar a identificação do local da informação correta: no backup, na máquina do engenheiro ou mesmo no servidor de arquivos. O Quadro 4-2 exemplifica como as modificações dos produtos são controladas no DPI. Nele são identificados a data em que a alteração no produto foi solicitada,

110 110 o que foi alterado, por quem foi solicitado, quem executou a alteração e o status dessa solicitação. Quadro 5-2: Planilha típica usada para registrar as modificações realizadas no produto durante seu desenvolvimento. Data: Alteração: Solicitada por: Executada Status Observações por: 11/04/10 Acrescentar arredondamento em determinados cantos internos em 0,8 mm Engenheiro de Manufatura Designer R Facilitar fabricação molde 19/10/10 Criar "parede separação" no engate dos castelos da tampa 11/03/10 Reforçar castelos posteriores para receber PCI (Placa de Circuito Impresso) 11/03/10 Acrescentar novo castelo p PCI (Placa de Circuito Impresso) deixando-o 10 mm da borda anterior 11/03/10 Reduzir a folga lateral entre o Protetor e a Base, na região da passagem dos cabos da baterias (considerar cabos de 6 mm) 21/01/10 Modificar protetor da bateria - inserir ângulo de saída (0,5 graus) em duas nervuras. Cliente Designer EA Geometria modificada (de elíptica para 2 condutos cônicos) Cliente Designer P Cliente Designer EA Cliente Designer P Modificação definida em reunião no dia em SSA Engenheiro de Manufatura Engenheiro Produto EA Modificação realizada, pois nervura impossibilitava a extração da peça do molde. Status: Realizado R, Pendente P, Em Análise - EA O nível de detalhamento do controle de mudanças gera dúvidas sobre qual item realmente foi alterado (arquivo CAD) e onde estão localizados esses arquivos ou informações. Muitas vezes a informação usada para essa verificação é a data do arquivo, o que não garante que os arquivos mais novos representam o produto atual acordado entre os diversos stakeholders (Cliente, Engenheiro de manufatura etc). Além disso, os stakeholders que necessitam da mesma informação em formatos diferentes iniciam um processo de reconciliação de dados do produto de engenharia. Por exemplo, os projetos de molde e as trajetórias de ferramentas devem ser verificadas manualmente para garantir que os dados de moldes e trajetórias de ferramentas estejam

111 111 consistentes com a nova revisão do produto. Os stakeholders do processo também constataram demora na aprovação, tanto interna (DPI) quanto externa (Cliente) como uma oportunidade de melhoria. No caso da aprovação externa, a dificuldade está no acesso a informações por parte do cliente para a tomada de decisão. No caso da aprovação interna, a demora explica-se pela dificuldade de reunir todos os participantes dos projetos uma vez que estão envolvidos em diversas outras atividades. Os stakeholders apontam o aperfeiçoamento do processo de elaboração de documentação técnica (geometrias CAD, relatórios e planilhas), reengenharia dos processos de revisão do produto e realização simultânea das atividades do projeto como uma possível solução para os problemas identificados. Eles reconhecem também que para diminuir erros de projeto é necessário estabelecer fluxos de trabalho robustos, indicadores que mostrem o nível de retrabalhos e uma pronta resposta dos clientes quando solicitado (exemplo: um cliente típico demora no mínimo três dias para responder a alguma solicitação) PROCESSO PROJETAR MOLDE A Figura 5-10 mostra as entradas, saídas, controles (Normas ABNT e Padrões gerenciais) e mecanismos do processo, bem como seus stakeholders da atividade >Projetar molde<. Semelhantemente ao processo de projeto, stakeholders relacionados à execução de atividades são identificados no processo.

112 112 Clientes Diretoria Gerente DPI Normas ABNT Padrões gerenciais Especificações Requisitos Projeto do produto Projetar molde Desperdícios Projeto de Molde Software Hardware Engenheiros, Técnicos Designers Engenheiro produto Engenheiro MFG Fornecedores Figura 5-10: Entradas, saídas, mecanismos e controles do processo de projeto de moldes. Alguns desses stakeholders já foram listados no processo anterior (projeto de produto), mas devem ser novamente analisados, pois o objetivo do processo de projeto de molde é diferente daquele do processo anterior. Problemas com o gerenciamento de modificação do produto/molde são comuns nesse processo. O impacto ocasionado pelo mau gerenciamento ou mesmo falta de gerenciamento, pelo histórico da empresa, pode variar de um retrabalho no projeto do molde a perda de um molde inteiro (custo de R$50.000,00 R$ ,00) quando esse já havia sido manufaturado. Uma das dificuldades existentes nesse processo é o fato não existir uma abordagem de >Master Model< o que acarreta a existência de arquivos diferentes para descrever um único componente do produto. O projetista de moldes muitas vezes copia uma versão do produto para, a partir dessa cópia, projetar o molde. Quando ocorrem mudanças no produto, o que é frequente no ambiente desse estudo de caso devido as suas características de ETO Engineering to Order (ROZENFELD, FORCELLINI, et al., 2006), o projetista não é notificado automaticamente sobre a modificação no produto. Ele é avisado por ou em

113 113 uma conversa com o projetista de produto, e com isso, substitui o arquivo utilizado anteriormente pela nova revisão do produto. A estrutura de pastas criada para armazenar os dados de produto ao longo dos processos do ciclo de vida é mostrada na Figura Nessa figura cada pasta da janela A é relacionada a um único componente do produto. Nelas estão arquivo CAD 3D/2D, s trocados com o cliente sobre a aprovação de cada componente e outros dados utilizados para o projeto. Na janela B estão as cópias desses arquivos (CAD 3D) que têm seus nomes modificados para adequar-se à nomenclatura criada pelo projetista de moldes. Para um mesmo componente, existem nomes diferentes, não obstante tratar-se do mesmo componente. A B Figura 5-11: Estrutura de pastas e arquivos criada para gerenciar os dados do processo de desenvolvimento de produtos. Dessa forma, sempre que ocorrem mudanças no produto, é necessário verificar manualmente a consistência entre informações de projeto do produto e projeto do molde, procurando-se identificar erros ou modificações necessárias geradas pelas mudanças realizadas no produto.

114 114 O tempo necessário para revisar os dados é proporcional à complexidade da modificação, de alguns minutos ou até dois dias, no caso de uma nervura ou quando a modificação é significativa e é necessária a aprovação do cliente, respectivamente. Após a conclusão da modificação do molde, o projetista (Engenheiro de Manufatura) exporta os dados em formato IGES ou em outro formato e os disponibiliza na rede de dados, para que usuários de software CAM e CAE possam, por exemplo, recriar trajetórias de ferramentas ou realizar novas análises de ajuste ao molde com a nova geometria do produto. Os stakeholders recomendam uma revisão detalhada do projeto do produto antes do início do processo Projetar Molde, como uma ação de melhoria para evitar retrabalhos. Constatou-se com os projetistas de moldes, que se não houvesse retrabalhos, se o acesso à informação fosse mais eficaz e houvesse participação efetiva dos fornecedores no processo, este processo teria seu tempo reduzido para, no máximo, três semanas, para produto de mais alta complexidade. Atualmente esse indicador não é medido ou documentado. Além disso, os stakeholders apontam a divisão de atividades e responsabilidades equivocadas como sendo possíveis causas de dificuldades na execução do projeto do molde. Nesse caso pode-se citar a participação de estagiários no processo. A falta de treinamento/ experiência das pessoas é um fator adicional que contribui para o desempenho do processo aquém do esperado. Essa dificuldade é ocasionada devido à alta rotatividade dos colaboradores no CIMATEC. Especificamente no processo de Projetar moldes, essas pessoas necessitam constantemente do suporte de colaboradores mais experientes PROCESSO PLANEJAR E CONTROLAR MANUFATURA O planejamento da manufatura inicia-se quando a superfície de fechamento do molde é definida pelo projetista (Engenheiro de Manufatura). Esse evento inicia diversas

115 115 atividades de planejamento de manufatura, tais como a elaboração de lista preliminar de compras de itens adquiridos para a manufatura do molde e a geração de trajetória de ferramentas em software CAM para a fabricação da cavidade do molde. A Figura 5-12 mostra as entradas, saídas, controles, mecanismos e stakeholders do processo de planejamento da manufatura. Esse processo tem o propósito de garantir que os processos da produção ocorram eficaz e eficientemente e que produzam produtos conforme requeridos pelos clientes. Clientes Diretoria Gerente DPI Departamento de compras Normas ABNT Padrões gerenciais Especificações Restrições Projeto do molde Planejar e Controlar Manufatura Plano de Manufatura Lista de materiais Desperdícios Software Hardware Engenheiros e Técnicos Operador. de máquinas Técnico de Processos Engenheiro produto Engenheiro Manufatura Fornecedores Figura 5-12: Entradas, saídas, mecanismos e controles do processo Planejar e Controlar manufatura. Esse processo consiste em planejar a sequência de operações de manufatura para cada item fabricado na empresa e iniciar processo de compras de itens disponíveis comercialmente, matéria-prima, ferramentas e dispositivos. Para o sequenciamento de

116 116 operações desse processo são considerados os recursos, insumos disponíveis e o prazo de entrega de materiais comprados (matéria prima e itens comercialmente disponíveis). A principal preocupação dos stakeholders desse processo é a lista de compras gerada. Os compradores (Departamento de Compras), localizados em outro setor da empresa, tem que cumprir um processo de compras que atenda os aspectos legais da empresa. Outrossim, os compradores não possuem formação técnica suficiente para realizar as compras e a lista de materiais não contém todas as informações necessárias para a execução das atividades. O período de tempo para realizar uma compra varia de três a oito semanas. É comum, em função dos aspectos citados, o atraso no recebimento dos materiais. Consequentemente, o plano de manufatura desenvolvido é alterado bem como a sequência de operações do plano de manufatura. Os stakeholders sugerem como solução para o problema identificado no processo, a contratação de compradores com perfil técnico de maior conhecimento sobre o assunto. Para auxiliar o controle de atividade de manufatura e tentar reduzir desperdícios, foram criadas folhas de processo com verificações executadas pelos técnicos de processo e operadores de máquinas. Trata-se de uma série de documentos de produção que acompanha os produtos pela fábrica em cada etapa do processo produtivo. Quando o Plano de Manufatura é alterado, as folhas de processo também precisam ser alteradas para que o novo plano seja executado. Essas folhas estão atualmente no formato papel e não possuem controle de revisão, o que dificulta a identificação da versão correta e atualizada da sequência de trabalho. Análise dos Stakeholders A análise de stakeholders é sintetizada no quadro 5-3: Destaca-se os riscos percebidos pelos stakeholders numa possível implementação PLM e finalmente, o impacto desses riscos na iniciativa PLM.

117 117 Quadro 5-3: Análise de stakeholders identificados nos processos analisados Stakeholder Interesse nos processos Papel do stakeholder no processo Riscos percebidos Impacto Clientes O projeto deve ser realizado conforme sua necessidade no custo, prazo e qualidade planejados; As restrições devem ser observadas de modo a ter impacto reduzido no projeto; O projeto deve respeitar normas e regulamentações estabelecidas no país; Fornecer informações de entrada para o desenvolvimento; Usufruir benefícios oferecidos pelos serviços ofertados; Avaliar soluções propostas no desenvolvimento de produtos. O trabalho de definição dos requisitos é uma tarefa que não é contemplada satisfatoriamente. O projeto inicia-se sem algumas definições básicas como funcionalidades; Os clientes procuram inserir funcionalidades na etapa de projeto detalhado de engenharia fazendo com que as áreas de Design e Engenharia realizem retrabalhos para atender essa solicitação. Alto. Acompanhar de perto o projeto. Designers Os designers buscam harmonizar os diversos elementos presentes no projeto forma, cor, textura, funcionalidade para aumentar a percepção de valor dos consumidores; Os requisitos do produto devem ser respeitados durante todo o desenvolvimento. Elaborar briefing com os clientes; Desenvolver as propostas conceituais e apresentálas aos clientes; Aprovar tecnicamente as modificações requisitadas por todos os participantes do projeto. Os designers são impedidos de realizar sua função devido às pressões existentes por prazos e custos. Isso prejudica a qualidade dos produtos desenvolvidos em termos da proposição de valor para o cliente. A etapa de design é quase que omitida ou executada de maneira bastante simplória e resume-se a geração das formas estéticas externas; Alto. Os Designers estão sobrecarregados no preenchimento de relatórios e podem não querer participar de uma iniciativa PLM; Os Designers estão sobrecarregados no desenvolvimento de todo o projeto do conceito a engenharia necessária para implementar funcionalidades como fechamento do produto etc.

118 118 Continuação Quadro 5 3: Análise de stakeholders identificados nos processos analisados Stakeholder Interesse nos processos Papel do stakeholder no processo Riscos percebidos Impacto Engenheiro de Produto Coletar corretamente os requisitos do cliente; Usar os requisitos de uma forma automática; Aumentar a eficiência no acesso à informação; Automatizar tarefas repetitivas; Melhorar o controle dos dados do produto; Melhorar a manufaturabilidade dos produtos; Reduzir retrabalhos; Executar projeto CAD; Desenvolver soluções técnicas para atender os requisitos; Projetar produto seguindo especificações do cliente. Atualmente quem desempenha esse papel são os designers. Os designers assumiram, além do papel de design, o de projetar o produto em sua totalidade; Demora do cliente em inserir informações no processo e responder quando solicitado (no mínimo 3 dias); Alguns engenheiros não entendem a necessidade de melhor acesso a informação como uma possível solução para deficiências dos processos. Alto. Mensurar retrabalhos nos processos; Diminuir erros de projeto; Garantir que todas as etapas sejam realizadas; Estabelecer uma sequência lógica de trabalho que garanta no final o melhor resultado. Gerente DPI Eficiência na manipulação dos dados; Eficiência no desenvolvimento de projetos Aumento da eficiência ao projetar moldes e reduzir retrabalhos; Aumento da receita do departamento projetando mais moldes; Supervisionar as atividades; Acompanhar a execução do projeto; Decidir questões importantes do projeto (gates de projeto); Supervisionar as atividades durante a modificação. Gerente não é propenso a mudanças; Será difícil mudar a visão do gerente em relação a soluções ad hoc de problemas que se repetem sempre. Alto. Eficiência na manipulação dos dados; Eficiência no desenvolvimento de projetos.

119 119 Continuação Quadro 5 3: Análise de stakeholders identificados nos processos analisados Stakeholder Interesse nos processos Papel do stakeholder no processo Riscos percebidos Impacto Diretoria Eficiência no desenvolvimento de projetos; Aumento de faturamento por projeto; Aumento do faturamento com a mesma estrutura existente; Supervisionar o gerente do DPI acompanhando as metas financeira e física dos projetos e representar os interesses do SENAI e FIEB. A diretoria não fornece recomendações ou se envolve diretamente em questões como implementações desse tipo. Alto. Melhoraria dos indicadores de desempenho. Fornecedores Fornecer software, materiais e equipamentos para a realização dos processos; Oferecer produtos e serviços para a realização dos processos; O projeto pode atrasar se alguns fornecedores atrasam o fornecimento de insumos; Médio. Tomar conhecimento rápido sobre mudanças ocorridas. Fornecer insumos para o novo produto modificado. Atrasos na entrega de software, materiais e equipamentos. Governo O governo prescreve procedimentos legais à empresa, tais como a lei de licitações Fiscalizar o atendimento dessas leis com auditorias e consultas frequentes. Mudanças nas leis impactam fortemente no desempenho organizacional da empresa. Alto. Investidores Retorno nesse investimento; Aumento de receitas na prestação de serviços. Investimento no processo: aquisição de recursos e contratação de pessoas. Investidores não participam diretamente do estabelecimento da estratégia da execução dos processos. Com isso, não existe flexibilidade para estabelecimento de metas. Alto. Departamento de Compras Preocupação com a lista de compras gerada; Aquisição de produtos e serviços condizentes com as expectativas dos clientes internos e externos. Realizar o processo de compras relacionadas ao desenvolvimento no prazo/custo planejado. O processo de compras não é adequado e muitas vezes atrasa o desenvolvimento de todo processo; Com esse cenário é necessário mudar o planejamento inicial sem avaliação adequada do novo plano. Alto.

120 120 Continuação Quadro 5 3: Análise de stakeholders identificados nos processos analisados Stakeholder Interesse nos processos Papel do stakeholder no processo Riscos percebidos Impacto Engenheiro de. Manufatura Adequação simples do projeto ao processo; Realização do processo de Projetar Molde após o processo Projetar Produto; Utilização de informações do pré-projeto do molde para o desenvolvimento do produto; Aproveitamento de soluções já usadas em projetos anteriores; Receber os dados do produto para confeccionar o projeto do molde; Projetar molde conforme as necessidades e definir a estratégia de manufatura do produto; Realizar mudanças no projeto CAD, caso necessário. O projetista é resistente a mudanças na forma de trabalho, principalmente na utilização de novas tecnologias; Projetista não entende a necessidade de melhorar acesso à informação Engenheiros não entendem a necessidade de melhorar acesso à informação Alto Padronização de features usados em componentes projetados; Alinhamento entre pré-projeto de ferramentas e o projeto do produto; Manufaturabilidade dos produtos projetados; Melhor controle dos dados do produto e suas revisões; Desenvolvimento do molde conforme as necessidades do cliente (custo, prazo, qualidade planejado). Os requisitos do produto relacionados ao processo produtivo devem ser escritos corretamente para não gerar problemas ou dúvidas na execução das tarefas subsequentes; Melhoria do controle dos dados do produto; Melhoraria da manufaturabilidade do produto.

121 121 Continuação Quadro 5 3: Análise de stakeholders identificados nos processos analisados Stakeholder Interesse nos processos Papel do stakeholder no processo Riscos percebidos Impacto Concorrentes As restrições de mercado devem ser observadas para que o produto desenvolvido tenha diferencial competitivo diante aos seus concorrentes Projetista CAD Coletar corretamente os requisitos do cliente; Usar os requisitos de uma forma automática; Aumentar a eficiência no acesso à informação; Automatizar tarefas repetitivas; Melhorar o controle dos dados do produto; Melhorar a manufaturabilidade dos produtos; Executar projeto CAD; Desenvolver soluções técnicas para atender os requisitos; Projetar o produto seguindo especificações do cliente. Atualmente quem desempenha esse papel são os designers. Os designers assumiram atribuições além das suas: projetar o produto em sua totalidade; Demora do cliente em inserir informações no processo e responder quando solicitado (em média uma semana); Alguns engenheiros não entendem a necessidade de melhorar o acesso à informação. Alto. Reduzir retrabalhos; Medir retrabalhos; Diminuir erros de projeto; Garantir que todas as etapas do processo sejam realizadas; Estabelecer uma sequência lógica de trabalho.

122 122 Continuação Quadro 5 3: Análise de stakeholders identificados nos processos analisados Stakeholder Interesse nos processos Papel do stakeholder no processo Riscos percebidos Impacto ABNT INMETRO A ABNT e INMETRO são órgãos que desenvolvem e fiscalizam as normas técnicas para produtos e serviços no Brasil. Ex. NBR e NBR Normatizar e fiscalizar os produtos e serviços desenvolvidos no DPI. Imposição de novas normas para regulamentação de produtos e serviços desenvolvidos. Médio Operador de máquinas Acessar informações sobre o produto e processo de manufatura quando necessário. Operar equipamentos para executar os processos de manufatura planejados. A falta de sincronização entre as informações (consumida/gerada) pode gerar retrabalhos. A dúvida sobre qual a informação é a correta pode ocasionar perda de eficiência na execução dos processos de manufatura. Alto Técnico de Processos Acessar informações sobre o produto e processo de manufatura quando necessário para planejar a manufatura do produto/molde Desenvolver o planejamento dos processos de manufatura do produto/molde de injeção A falta de sincronização entre as informações (consumida/gerada) pode gerar retrabalhos. A dúvida sobre qual é a informação correta pode ocasionar perda de eficiência na execução dos processos de manufatura. Alto

123 DEFINIR INDICADORES DE DESEMPENHO Após a modelagem de processos e análise de stakeholders, é necessária a elaboração de indicadores que quantifiquem o atendimento das necessidades dos stakeholders com a implantação de um sistema PLM. Para a demonstração do método, foi selecionado o processo >Projetar Produto<. O método utilizado para definir indicadores de desempenho é reapresentado na Figura 5-13 act [Activ ity] Indicadores [Indicadores] Entradas Saida Stakeholders Descrição do processo (from Method) (from Method) Indicadores e seus atributos 1. Identificar v alor para o cliente 6. Definir Base Line/Meta/Prazo 1. O que o cliente vê como valor? 2. Para cada valor acima, qual é o processo "responsável" pela sua incorporação? 3. Qual é o aspecto mais relevante para cumprir o item de valor? 4. Porque é que este aspecto é importante? Apontar algumas das suas características. 5. Como essas características devem ser avaliadas, a fim de ser um indicador do processo? 6. Definir outros atributos: Baseline/Meta/Prazo necessários a iniciativa PLM (from Method) 2. Identificar sub-processo gerador de v alor (from Method) (from Method) 5. Identificar forma de medição (from Method) 3. Identificar aspectos que geram v alor 4. Identificar caracterisiticas desses aspectos (from Method) (from Method) Figura 5-13: Processo de determinação de indicadores de desempenho do processo Os objetivos do processo >Projetar Produto< é dimensionar produtos tecnicamente e economicamente viáveis. Os stakeholders desse processo já foram apresentados na Figura 5-9. O Quadro 5-4 mostra a aplicação do método PERISCOPE modificado para o processo de >Projetar Produto<.

124 124 Quadro 5-4: Aplicação do método para criação de indicadores 1. O que o cliente vê como VALOR? 2. Para cada VALOR acima, qual é o processo "responsável" pela sua incorporação? 3. Qual é o ASPECTO mais relevante para cumprir o item de valor? 4. Porque é que este aspecto é importante? Apontar algumas das suas CARACTERÍSTICAS. 5. Como essas características devem ser avaliadas, a fim de ser um indicador do processo? V1. Produto de fácil manufatura; V2. Projeto sem retrabalho; V3. Garantia de rastreabilidade entre atividades; V4. Garantia da qualidade dos produtos desenvolvidos. V1: o subprocesso de Desenvolver Projeto de Engenharia (P1); V2 e V3: Os subprocessos de Aprovação Interna (P2) e Aprovação Externa (P3); V4: Os subprocessos de Desenvolver conceito (P4) e Desenvolver projeto de engenharia (P1); A1. Para V1. Incorporar boas práticas de manufatura no projeto do produto; A2. Para V2. Realizar aprovações com base em dado/informação; A3. Na fase de concepção do produto, deve-se ter o cuidado de capturar exatamente aquilo que o cliente quer, ou seja, os requisitos devem ser mais bem estabelecidos e gerenciados. A1. Ao incorporar boas práticas de manufatura (soluções já conhecidas), reduz-se o esforço por parte do engenheiro de manufatura em desenvolver processos de manufatura; A2. Ao realizar aprovações durante os processos deve-se conhecer um conjunto de informações suficientes que permitam a correta tomada de decisão pelo decisor. Além disso, não existem regras claras para todos os membros da equipe de quais são os critérios de aprovação. M1. Número de soluções de manufatura anteriores reutilizadas por novo projeto; M2. Número de análises/simulações realizadas antes de submeter a uma aprovação; M3. Tempo gasto para realizar aprovação interna; M4. Tempo de resposta dos envolvidos/cliente; M5. Custos de retrabalhos/projeto.

125 Definir outros atributos: Referência/Meta/Prazo necessários à iniciativa PLM Para M1. Referência: Métrica não computada, mas estimada em 1 solução por novo projeto. Meta: 20 soluções existentes de qualquer nível de complexidade por projeto Prazo: um ano para atingir esse nível de reutilização Para M2. Referência: Métrica não computada, mas estima-se que são realizadas somente análises ad hoc quando surge alguma dificuldade (estimativa uma analise crítica). Meta: Realizar análises necessárias para reduzir retrabalhos Análise de ângulo de saída do produto, Análise de espessura do produto, Análise da resistência mecânica do produto, Análise de montagem do produto (interferências), Análise de simulação de GD&T etc. Prazo: 1 ano Para M3 e M4. Referência: Métrica não computada, mas estima-se que a aprovação interna pode demorar até 3 dias (72h). Meta: A meta estipulada para realizar uma aprovação é 24h. Prazo: O prazo para o atingimento dessa meta é de 6 meses. Para M5. Referência: Métrica não calculada, mas estima-se que custe no mínimo 10% de cada projeto. Meta: 5% é a meta. Prazo: 1 ano é o prazo para o atingimento da meta. Ao final da aplicação do método têm-se as métricas dos indicadores M1-M5 e seus atributos complementares como referência inicial de medição (baseline), metas e prazos.

126 DETERMINAR REQUISITOS Após a análise dos stakeholders, entendimento de suas necessidades organizacionais e a modelagem dos processos de negócio, obtém-se a percepção do problema de uma forma sistêmica. Com isso, pode-se usar essas informações como entradas para a derivação dos requisitos para utilização no processo de implementação de sistemas PLM. Na Figura 5-14 a função >Analisar e Modelar< o sistema PLM tem três entradas para sua consecução, a saber, os stakeholders, suas necessidades e os processos detalhados nas seções anteriores desse capítulo. Essas entradas foram assim definidas porque os stakeholders (e suas necessidades), vão se beneficiar ou impedir a adoção do sistema PLM; os processos modelados em BPMN são fotografias atuais de como funcionam os processos de negócios (quando validados pelos stakeholders). Stakeholders Necessidades dos stakeholders Processos BPMN Modelos SysML Analisar e modelar funcional Derivar Requisitos Resultados da Análise Requisitos Figura 5-14: Processo de determinação de requisitos dos stakeholders.

127 127 Para a demonstração do método, as necessidades dos stakeholders já foram identificadas, direta ou indiretamente no texto. São elas: Reduzir custos com retrabalhos na manufatura dos produtos; Melhorar a rastreabilidade de atividades; Melhorar a qualidade dos produtos desenvolvidos; Melhorar o desempenho ao longo do ciclo do Projeto de produtos; Realizar a revisão detalhada do projeto do produto (considerando manufatura e funcionalidades); Melhorar o processo de compras (esse processo não foi analisado, mas tem impacto importante sob os demais, motivo pelo qual foi incluído). A partir dessas três entradas, foram elaborados diagramas para análise do problema e a consequente derivação de requisitos do sistema PLM MODELAGEM DE DIAGRAMAS DE CONTEXTO Para cada processo analisado foi construído um diagrama de contexto mostrando os diversos atores envolvidos, sistemas já existentes, usuários ou empresas (fornecedores e clientes). Os contextos analisados são: Projeto do produto, Projeto do molde e Planejamento da manufatura mostrados nas Figuras 5-15, 5-16 e 5-17, respectivamente. Os três primeiros diagramas representam o ambiente no qual o sistema PLM estará operando. Neles estão representados, por exemplo, a associação entre os usuários (Projetista CAD, Engenheiro de Manufatura, Engenheiro de Produto e Designers) e o sistema modelado no contexto de projetar um produto. Representa-se também a intenção de propiciar maior acesso aos processos e dados de produto via internet, representada pelo ator WEB.

128 bdd [SysML Block Definition] Context diagram [Context diagram-projeto do produto] «actor» Fornecedor PLM Projetista CAD (from Stakeholders) Gerente DPI (from Stakeholders) «flow» Informação/ Aprovar/Rejeitar Engenheiro de manufatura (from Stakeholders) «System» Sistema PLM «actor» WEB «flow» Dados de produto/aprovar/rejeitar Engenheiro de produto (from Stakeholders) «actor» Clientes Designers (from Stakeholders) (from Stakeholders) Figura 5-15: Diagrama de contexto para o processo >Projetar Produto< 128

129 bdd [SysML Block Definition] Context diagram [Context diagram-projeto do molde] «actor» Departamento de Compras Engenheiro de manufatura (from Stakeholders) (from Stakeholders) Projetista CAD (from Stakeholders) «System» Sistema PLM «actor» Fornecedores Engenheiro de produto (from Stakeholders) (from Stakeholders) «actor» Clientes Dados de produto/aprovar/rejeitar «actor» WEB Informação/ Aprovar/Rejeitar «flow» «flow» Gerente DPI (from Stakeholders) (from Stakeholders) Figura 5-16: Diagrama de contexto para o processo de >Projetar Molde< 129

130 bdd [SysML Block Definition] Context diagram [Context diagram-plano de manufatura] «actor» Departamento de Compras Dados de compras «flow» «actor» ERP-WEBdesk Cotações «flow» «actor» Fornecedores (from Stakeholders) (from Stakeholders) «actor» Fornecedor PLM «System» Sistema PLM «actor» WEB Informação/ Aprovar/Rejeitar «flow» Técnico de processos (from Stakeholders) Engenheiro de manufatura (from Stakeholders) Operador de máquina (from Stakeholders) Gerente DPI (from Stakeholders) Figura 5-17: Diagrama de contexto para o processo de >Planejar e Controlar Manufatura< 130

131 131 Analisando-se os diagramas de contexto, foram identificados os fluxos de informação e de dados entre o sistema e os atores. Com essa informação são modeladas as portas de acesso ao sistema representando, o tipo de dado trocado entre sistema e atores e vice versa. A Figura 5-18 descreve o fluxo de informação entre o sistema PLM e atores no contexto de projeto de produto; o fluxo de informação entre o sistema PLM e atores no contexto de projeto de molde está detalhado na Figura A Figura 5-20 mostra o fluxo de informação entre o sistema PLM e atores no contexto de Plano de manufatura. A modelagem de portas no diagrama de contexto é um mecanismo proposto por para dividir/agrupar formatos diferentes de informação. A preocupação nesse nível de abstração de modelagem é somente prever as interfaces que os atores possuem para trocar dados com o sistema e não como essa troca será realizada. No diagrama da Figura 5-19 o fluxo de informações entre os sistemas PLM e ERP Webdesk ocorre via uma interface (porta ERP) que o sistema PLM deve possuir para esse tipo de fluxo. Nos processos analisados, o sistema ERP Webdesk é utilizado no processo de compras e contratação de serviços. A necessidade de melhorar o processo de compras motivou a incorporação do sistema ERP nos diagramas de contexto e a identificação de funções do sistema PLM que atendam essa demanda. A necessidade de treinamento de alguns colaboradores motivou a modelagem do fornecedor PLM para treinar novos colaboradores no uso do sistema.

132 132 ibd [SysML Internal Block] Context diagram [Projeto de produto] :Clientes «flow» Aprovar/ Rejeitar/ Dados de produto/ Requisitos «flowport» Acesso Web «flow» Dados de produto / Aprovar/Rejeitar «System» :Sistema PLM «flowport» Visualização :WEB «flow» Dados de produto/ Aprovar/Rejeitar «flow» Dados de produto «flowport» Acesso para manutenção «flow» produtos e serviços «flowport» Aprovar/Rejeitar «flowport» CAx port «flow» Dados do produto «flow» «flow» Dados do produto Aprovar/ Rejeitar «flow» «flow» Informações de design Dados CAD/ Dados do molde :Gerente DPI :Designers :Proj etista CADD :Fornecedor PLM :Engenheiro de produto :Engenheiro de manufatura Figura 5-18: Diagrama de contexto para o processo >Projetar Produto< acrescido do fluxo de informação

133 133 ibd [SysML Internal Block] Context diagram [Projeto do molde] :ERP-WEBdesk :Fornecedores «flow» Especificações de componentes «flow» Dados das compras «flowport» ERP Port «flowport» Acesso para manutenção «System» :Sistema PLM «flowport» Acesso Web «flow» Dados dos moldes «flowport» Visualização «flowport» CAx port :WEB «flowport» Aprovar/Rejeitar Dados do molde/ Aprovar/ Rejeitar «flow» Dados dos moldes «flow» «flow» Aprovar/ Rejeitar :Gerente DPI «flow» produtos e serviços «flow» Dados CAD/ Dados do molde «flow» Dados produto/ Dados do molde :Fornecedor PLM :Proj etista CAD :Engenheiro de manufatura Figura 5-19: Diagrama de contexto para o processo >projetar molde< acrescido do fluxo de informação

134 134 ibd [SysML Internal Block] Context diagram [Plano de manufatura] :ERP-WEBdesk E :Departamento de Compras «flow» Dados das compras «flow» Dados das compras Dados das compras «flow» «flowport» ERP Port «flowport» Acesso para manutenção :Fornecedores «flowport» Acesso Web «System» :Sistema PLM «flow» Dados manufatura «flow» Dados processo manufatura :WEB «flow» Dados de «flowport» processos Visualização manufatura «flow» Dados do processo manufatura/aprovar/rejeitar «flow» :Gerente DPI Aprovar/Rejeitar «flowport» «flowport» CAx port Aprovar/Rejeitar «flow» produtos e serviços :Fornecedor PLM «flow» Dados de Planejamento da produção «flow» «flow» Dados de Folha de planejamento processo da produção :Engenheiro de manufatura :Operador de máquina :Técnico de processos Figura 5-20: Diagrama de contexto para o processo >Planejar e controlar manufatura< acrescido do fluxo de informação

135 MODELAGEM DE DIAGRAMAS DE CASOS DE USO E DIAGRAMA DE BLOCOS Após a identificação do fluxo de informação nos diagramas de contexto, um diagrama de casos de uso foi modelado para identificar as funcionalidades do sistema PLM. Esse diagrama é mostrado na Figura Esse diagrama demonstra as funcionalidades que o sistema deve fornecer aos atores: usuários, outros sistemas, fornecedores e clientes. Atender as necessidades dos atores é o propósito de qualquer sistema; a maneira de atendê-los é fornecendo funcionalidades requeridas. Essas funcionalidades são representadas por casos de uso. Um diagrama de blocos foi modelado para representar a estrutura do sistema PLM e auxiliar o diagrama de casos de uso na definição de requisitos do sistema PLM necessário ao atendimento das necessidades dos stakeholders. Esse diagrama é mostrado na Figura 5 22.

136 uc [Use Case] Use cases [Use case model] Dados de produto/aprovar/rejeitar «flow» «actor» WEB (from Context diagram) Visualizar dados do CVP v ia WEB Informação/ Aprovar/Rejeitar «flow» Gerente DPI (from Stakeholders) Visualizar dados do Ciclo de Vida do Produto «actor» Departamento de Compras (from Stakeholders) «flow» Dados de compras Trocar dados com sistema ERP «actor» ERP-WEBdesk Cotações «flow» (from Context diagram) «actor» Clientes (from Stakeholders) Designers (from Stakeholders) Sistema PLM Gerenciar requisitos Aprov ar e Rejeitar Criar dados Ciclo de via web Vida do Produto Gerenciar dados do Ciclo de Vida do Produto Realizar suporte ao sistema Aprov ar e Rejeitar Ler dados Ciclo de Vida do Produto Realizar treinamentos Realizar interv enção via web técnica via web Ler especificações v ia WEB «actor» Fornecedores (from Stakeholders) Figura 5-21: Diagrama de Casos de uso Criar dados do produto Ler dados do produto Cria dados de manufatura Ler dados de manufatura «actor» Fornecedor PLM (from Context diagram) Engenheiro de produto (from Stakeholders) Projetista CAD (from Stakeholders) Engenheiro de manufatura (from Stakeholders) Operador de máquina (from Stakeholders) 136

137 bdd [SysML Block Definition] Structure [Sistema PLM] «System» Context diagram::sistema PLM «block» Context diagram:: CAx Tools «block» Context diagram:: Vault de dados e informações «block» Context diagram:: ERP prov ider/receiv er serv ices «block» Context diagram:: Web serv ices prov ider/receiv er «block» Context diagram:: Office portfolio «block» Context diagram:: CAE tool «block» Context diagram:: CAD Tool «block» Context diagram:: CAM Tool «block» Context diagram:: Vault permanente «block» Context diagram:: Vault em processo «block» Context diagram:: Ferramenta colaborativ a «block» Context diagram:: Gerenciador de s «block» Context diagram:: Editor de texto «block» Context diagram:: PDF tool «block» Context diagram:: Gerenciador de desenhos «block» Context diagram:: CNC files manager «block» Context diagram:: Gerenciador de mudanças de engenharia «block» Context diagram:: Gerenciador de projetos «block» Context diagram:: Gerenciador de requisitos «block» Context diagram:: Ferramenta de v isualização Figura 5-22: Diagrama de blocos representando a estrutura do sistema 137 «block» Context diagram:: Spreadsheet tool

138 MODELAGEM DE DIAGRAMA DE REQUISITOS Após a modelagem dos diversos diagramas e da análise desses diagramas sob a ótica do SysML, os requisitos para a implementação do sistema PLM foram derivados. Considerando as necessidades dos stakeholders alguns desses requisitos são: 1) A necessidade Melhorar o desempenho ao longo do Processo de Projetar Produtos origina o requisito para o sistema PLM O sistema PLM deve melhorar (aumentar) o desempenho ao longo do Processo de Projetar produtos em 10%. 2) A necessidade Reduzir custos com retrabalhos origina o requisito para o sistema PLM O sistema PLM deve reduzir custos com retrabalhos em 10% 3) A necessidade Melhorar a rastreabilidade de atividades origina o requisito para o sistema PLM O sistema PLM deve tornar 100% das atividades rastreáveis (quem fez, o quê fez e quando fez. 4) A necessidade Melhorar a qualidade dos produtos desenvolvidos origina o requisito para o sistema PLM O sistema PLM deve propiciar aumento de qualidade dos produtos desenvolvidos pelo departamento DPI 5) A necessidade Melhorar a qualidade dos produtos desenvolvidos origina o requisito para o sistema PLM O sistema PLM deve auxiliar a melhora a qualidade dos produtos desenvolvidos 6) A necessidade Realizar a revisão detalhada do projeto do produto (considerando manufatura e funcionalidades) origina o requisito para o sistema PLM O sistema PLM deve propiciar a realização de revisão detalhada do produto

139 139 7) A necessidade Melhorar o processo de compras origina o requisito para o sistema PLM O sistema PLM deve melhorar o processo de compras Os requisitos apresentados (1 a 7) foram obtidos diretamente das necessidades dos stakeholders. Analisando-os em conjunto com os diagramas construídos, obtêm-se novos requisitos. Esses requisitos são apresentados no Quadro 5-5. Esse quando foi gerado com informações do software Enterprise Architect TM. Quadro 5-5: Requisitos obtidos com o método REQ001 - Automatização de atividades «Stakeholder» Status: Proposed Priority: High Difficulty: Medium Phase: 1.0 Version: 1.0 A solução PLM deve permitir a automatização de atividades repetitivas dos projetos desenvolvimentos REQ002 - Melhoria da comunicação «Stakeholder» Status: Proposed Priority: High Difficulty: Medium Phase: 1.0 Version: 1.0 O sistema PLM deve facilitar a comunicação entre o time de desenvolvimento e os clientes e fornecedores REQ003 - Reduzir retrabalhos «Stakeholder» Status: Proposed Priority: High Difficulty: Medium Phase: 1.0 Version: 1.0 O sistema PLM deve reduzir o retrabalho nas atividades realizadas ao longo do ciclo do produto REQ004 - Rastreabilidade de atividades «Stakeholder» Status: Proposed Priority: High Difficulty: Medium Phase: 1.0 Version: 1.0 O sistema PLM deve garantir a rastreabilidade das atividades realizadas, por realizar, atrasadas, ao longo do ciclo de vida do produto.

140 140 REQ005 - Padronização «Stakeholder» Status: Proposed Priority: High Difficulty: Medium Phase: 1.0 Version: 1.0 As normas e recomendações de engenharia utilizadas atualmente devem ser incorporadas facilmente aos fluxos de trabalhos no sistema PLM implementado REQ006 - Acesso a informação «Stakeholder» Status: Proposed Priority: High Difficulty: Medium Phase: 1.0 Version: 1.0 Os clientes devem a qualquer momento e lugar acessar os status de projeto e realizar aprovações utilizando uma conexão de internet REQ007 - Acesso a informação Gerente «Stakeholder» Status: Proposed Priority: High Difficulty: Medium Phase: 1.0 Version: 1.0 O gerente DPI deve poder acessar o status de projeto e realizar aprovações a qualquer momento e lugar utilizando uma conexão de internet REQ008 - Acesso a informação Engenheiro de manufatura «Stakeholder» Status: Proposed Priority: High Difficulty: Medium Phase: 1.0 Version: 1.0 O Engenheiro de manufatura deve poder acessar dados de produto ao mesmo tempo em que estes estiverem sendo criados (Não liberados para manufatura) REQ009 - Agilidade de aprovação «Stakeholder» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 O sistema PLM deve permitir maior agilidade na aprovação de etapas dos projetos

141 141 REQ010 - Reconciliação de dados «Stakeholder» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 O sistema PLM deve reduzir o impacto ocasionado pela reconciliação de dados devido à utilização de diversos formatos CAD. REQ011 - Redução de Custos «Stakeholder» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 O sistema PLM deve reduzir custos com retrabalhos na manufatura dos produtos REQ012 - Revisão do produto «Stakeholder» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 O sistema PLM deve facilitar a revisão detalhada do produto (manufatura e funcionalidade) REQ013 - Treinamento das pessoas «Stakeholder» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 As pessoas precisam possuir conhecimento mínimo sobre o processo para participação efetiva nele REQ014 - Melhoria da Qualidade «Stakeholder» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 O sistema PLM deve melhorar a qualidade dos produtos desenvolvidos.

142 142 REQ015 - Processo de compras «Stakeholder» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 O sistema PLM deve fornecer todas as informações necessárias para execução do processo de compras num formato acessível aos compradores e diretamente utilizável no processo REQ016 - Desempenho de Projetar produtos «Stakeholder Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 O sistema PLM deve melhorar o desempenho ao longo do Processo de Projetar produtos. REQ017 - Controle de modificações «Stakeholder» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 O sistema PLM deve controlar as modificações do produto ao longo do ciclo. REQ101 - Integração com sistemas existentes «requirement» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 O sistema PLM deve integrar-se aos sistemas legados já utilizados no processo REQ102 - integração ao ERP «requirement» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 O sistema PLM deve integrar-se ao sistema ERP-Webdesk para trocar dados sobre as compras dos projetos. REQ103 - integração com a WEB «requirement» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 O sistema PLM deve possuir a funcionalidade de integrar-se com a WEB

143 143 REQ104-aprovação/Rejeição de trabalho via WEB «requirement» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 O sistema PLM deve permitir que o gerente DPI possa realizar Aprovações/Rejeições via WEB REQ105 - Aprovação/Rejeição de trabalho via WEB (Cliente) «requirement» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 O sistema PLM deve permitir que o gerente DPI possa realizar Aprovações/Rejeições via WEB REQ186 - Representação gráfica de mudanças de engenharia «Functional» Status: Proposed Priority: High Difficulty: Medium Phase: 1.0 Version: 1.0 O sistema PLM deve possuir uma representação gráfica dos objetos que são impactados numa mudança de engenharia REQ234 - Compartilhamento de informação «Functional» Status: Proposed Priority: High Difficulty: Medium Phase: 1.0 Version: 1.0 O sistema deve ferramentas de compartilhamento de informações/aplicação via internet REQ358 - check in check out «Functional» Status: Proposed Priority: High Difficulty: Medium Phase: 1.0 Version: 1.0 O sistema PLM deve oferecer a possibilidade de realizar check in check out diretamente do aplicativo CAD encapsulado (totalmente integrado) ao sistema PLM RES001 - Payback «Stakeholder» Status: Proposed Priority: High Difficulty: Medium Phase: 1.0 Version: 1.0 O payback do investimento deve acontecer em no máximo 3 anos.

144 144 RES002 - Benefícios para diretoria «Stakeholder» Status: Proposed Priority: High Difficulty: Medium Phase: 1.0 Version: 1.0 A diretoria deve enxergar os benefícios seis meses após a implementação do sistema PLM RES003 - Tempo de implementação «Stakeholder» Status: Proposed Priority: High Difficulty: Medium Phase: 1.0 Version: 1.0 O sistema PLM deve ser implantado em no máximo 6 meses RES004 - Investimento «Stakeholder» Status: Proposed Priority: High Difficulty: Medium Phase: 1.0 Version: 1.0 O investimento total na implantação do sistema PLM não deve ultrapassar R$ ,00 RES005 - ROI «Stakeholder» Status: Proposed Priority: High Difficulty: Medium Phase: 1.0 Version: 1.0 A Federação das Indústrias do Estado da Bahia (FIEB) e a diretoria do SENAI devem obter ROI de no mínimo 25% relativo ao investimento inicial Com os requisitos e restrições apresentados foi desenvolvido o diagrama de requisitos apresentado na Figura Na figura são apresentadas as relações entre os requisitos desdobrados no método REQ4PLM.

145 req [SysML Requirements] Requirements [Implementation Requirements] «trace» «derivereqt» REQ011 - Redução de Custos notes O sistema PLM deve reduzir custos com retrabalhos na manufatura dos produtos REQ014 - Melhoria da Qualidade notes O sistema PLM deve melhorar a qualidade dos produtos desenvolvidos. REQ016 - Desempenho de Projetar produtos notes O sistema PLM deve melhorar o desempenho ao longo do Processo de Projetar produtos. REQ017 - Controle de modifcações notes O sistema PLM deve controlar as modificações do produto ao longo do ciclo. REQ009 - Agilidade de aprovação notes O sistema PLM deve permitir maior agilidade na aprovação de etapas dos projetos RES005 - ROI notes Os investidores e a diretoria da empresas devem obter ROI de no minimo 25% relativo ao investimento inicial (from Stakeholder requirements) (from Stakeholder requirements) «derivereqt» «derivereqt» «derivereqt» (from Stakeholder requirements) (from Stakeholder requirements) (from Stakeholder requirements) (from Stakeholder requirements) «derivereqt» «derivereqt» «derivereqt» REQ003 - Reduzir retrabalhos notes O sistema PLM deve reduzir o retrabalho nas atividades realizadas ao longo do ciclo do produto (from Stakeholder requirements) REQ005 - Padronização notes As normas e recomendações de engenharia utilizadas atualmente devem ser incorporadas facilmente aos fluxos de trabalhos no sistema selecionado (from Stakeholder requirements) «derivereqt» REQ002 - Melhoria da comunicação notes O sistema PLM deve facilitar a comunicação entre o time de desenvolvimento e os clientes e fornecedores (from Stakeholder requirements) REQ004 - Rastreabilidade de atividades notes O sistema PLM deve garantir a rastreabilidade das atividades realizadas, por realizar, atrasadas, ao longo do ciclo de vida do produto (from Stakeholder requirements) «derivereqt» REQ001 - Automatização de atividades «derivereqt» notes A solução PLM deve permitir a automatização de atividades repetitivas dos projetos desenvolvimentos (from Stakeholder requirements) REQ006 - Acesso a informação notes Os clientes devem a qualquer momento e lugar acessar os status de projeto e realizar aprovações utilizando uma conexãoo de internet (from Stakeholder requirements) «derivereqt» REQ010 - Reconciliação de dados notes O sistema PLM deve reduzir o impacto ocasionado pela reconciliação de dados devido a utilização de diversos formatos CAD. (from Stakeholder requirements) «derivereqt» REQ234 - compatilhamento de informação notes O sistema deve ferramentas de compartilhamento de informações/aplicação via internet (from On-line Meeting Tools) «trace» REQ015 - Processo de compras notes O sistema PLM deve fornecer todas as informações necessárias para execução do processo de compras num formato acessível aos compradores e diretamente utilizável no processo (from Stakeholder requirements) «trace» REQ013 - Treinamento das pessoas notes As pessoas precisam possuir conhecimento minimos sobre o processo para participação efetiva nele (from Stakeholder requirements) RES004 - Investimento notes O investimento total não deve ultrapassar R$ ,00 (from Stakeholder requirements) RES003 - Tempo de implementação notes O sistema PLM deve ser implementado em no máximo 6 meses (from Stakeholder requirements) RES001 - Payback notes O payback do investimento deve acontecer em no máximo 3 anos. (from Stakeholder requirements) RES002 - Beneficios para diretoria notes A diretoria deve enxergar os benefícios seis meses após a implementação do sistema PLM (from Stakeholder requirements) REQ012 - Revisão do produto notes O sistema PLM deve facilitar a revisão detalhada do produto (manufatura e funcionalidade) (from Stakeholder requirements) REQ008 - Acesso a informação Engenheiro de manufatura notes O Engenheiro de manufatura deve poder acessar dados de produto ao mesmo tempo que estes estiverem sendo criados(não liberados para manufatura) (from Stakeholder requirements) REQ007 - Acesso a informação Gerente notes O gerente DPI deve poder acessar o status de projeto e realizar aprovações a qualquer momento e lugar utilizando uma conexão de internet (from Stakeholder requirements) REQ186 - Representação gráfica de mudanças de engenharia notes O sistema PLM deve possuir uma representação grafica dos objetos que são impactados numa mudança de engenharia (from Managing Engineering Change) REQ101 - Integração com sistemas existentes notes O sistema PLM deve integrar-se aos sistemas legados já utilizados no processo REQ103 - integrarção com a WEB notes O sistema PLM deve possuir a funcionalidade de integrar-se com a WEB REQ358 - check in check out notes O sistema PLM deve oferecer a possibilidade de realizar check in check out diretamente do aplicativo CAD encapsulado (totamente integrado) no sistema PLM (from CAD Integration) REQ102 - integração ao ERP «derivereqt» notes O sistema PLM deve integrar-se ao sistema ERP-Webdesk para trocar dados sobre as compras dos projetos. «derivereqt» REQ104-aprovação/Rejeição de trabalho via WEB notes O sistema PLM deve permitir que o gerente DPI possa realizar Aprovações/Rejeições via WEB «derivereqt» REQ105 - Aprovação/Rejeiçao de trabalho via WEB(Cliente) notes O sistema PLM deve permitir que o gerente DPI possa realizar Aprovações/Rejeições via WEB Figura 5-23: Requisitos determinados para PLM 145

146 DISCUSSÃO DO MÉTODO REQ4PLM Este capítulo apresenta uma discussão sobre o método proposto neste trabalho de doutorado. Para isso, os seguintes tópicos serão abordados: Vantagens e Desvantagens do método; Dificuldades para aplicação do método; Comparação e posicionamento do método proposto à literatura encontrada. 6.1 VANTAGENS, DESVANTAGENS E APLICABILIDADE DO MÉTODO. Analisando o método desenvolvido no Capítulo 4 e a sua demonstração no Capítulo 5 foi desenvolvido o Quadro 6-1. Neste quadro são apresentadas as vantagens e desvantagens do método com relação aos seus pares, bem como, a aplicabilidade do método em uma organização. Quadro 6-1: Analise do método desenvolvido em aplicado em ambiente de desenvolvimento de produtos SENAI-CIMATEC Vantagens Desvantagens Aplicabilidade Quando a empresa não Empresas de médio e possuir uma cultura pequeno porte orientada a processos implantada, se corre o risco de existirem iterações para que os processos sejam otimizados. Oportunidade para modelar ou remodelar os processos do ciclo de via do produto. Esses processos (modelos) podem também fazer parte de outras iniciativas de melhoria de processos. Identificação de indicadores e requisitos que dizem o que sistema deve fazer para atender as necessidades dos processos e de seus stakeholders Robustez garantida por uma abordagem sistemática, devido à filosofia de engenharia de sistemas e requisitos adotada. Consequentemente, pode existir um retrabalho considerável caso isso ocorra. Necessidade de conhecimentos prioritários para aplicação do método, por abordar os seguintes assuntos: Mapeamento e modelagem de processos; Analise de stakeholders; Empresas com uma cultura de processos já implantada ou que queiram implantar tal cultura. Empresas que desejem se certificar (por exemplo, ISO 9000), necessitam mapear e modelar processos. Com isso podese compartilhar recursos entre essas iniciativas (Certificação ISO e PLM). Empresas pequenas dificilmente terão a maturidade de encarar o problema dessa forma. Consequentemente, casos

147 147 A modelagem realizada será útil para realizar discussões para adotar futuras tecnologias para PLM, ex. Realidade virtual e aumentadas e as novas tecnologias de comunicação. Flexibilidade e customização, devido à acomodação do método aos processos da empresa e as seus respectivos stakeholders. Ao contrario de questionários genéricos encontrados Escalabilidade, o método pode ser aplicado inicialmente a processos prioritários. Em uma segunda rodada outros podem ser abordados com a necessidade mínima de retrabalhos. Modelagem de sistemas; Analise de requisitos; Notações para modelagem de processos e sistemas. Esforço para manter os modelos desenvolvidos atualizados Método desenvolvido somete em língua portuguesa. Isso impede a discussão sobre e ele. Faz necessária sua publicação em outras línguas para isso (ex. Inglês). essas empresas interessem PLM se adequarão as ferramentas adquiridas com processos préconfigurados. Empresas de grande porte Empresas de grande porte possuem estratégias de longo prazo para TI. No caso de multinacionais a definição de infraestrutura de TI é realizada nos países onde existem as matrizes. Nesse caso o método necessita de uma tradução para outras línguas. 6.2 DIFICULDADES PARA APLICAÇÃO DO MÉTODO A demonstração do método REQ4PLM foi realizada no SENAI CIMATEC pelo próprio autor em virtude das limitações inerentes a pesquisa, por exemplo, falta de uma equipe independente e dedicada a essa etapa. Ou mesmo, uma empresa que assumisse o risco e usa-se o método para identificar os requisitos de seu sistema PLM. A aplicação realizada dessa forma pode, para alguns, adicionado um viés a pesquisa e a seus resultados. Entretanto, mais importante do que esse possível viés é constatação por quem concebeu o método das dificuldades em aplicar o método e a proposição de soluções para essas dificuldades. As dificuldades mais significativas são apresentadas nessa seção. A demonstração do método foi realizada As características intrínsecas aos processos do SENAI CIMATEC ou de qualquer outra organização delineiam a necessidade por flexibilidade na aplicação do método:

148 148 Em aplicando o método, ele deve orientar-se aos processos de cada empresa. Essa necessidade foi contemplada pelo fato de ser necessário mapear e modelar os processos de interesse e identificar e analisar stakeholders antes de criar indicadores de desempenho e requisitos para o sistema PLM (processo + pessoas + tecnologia de TI). Com isso busca-se um conhecimento em detalhes de como as tarefas são executadas ou como se quer que elas sejam executadas, bem como dos interessados (stakeholders) e de seus interesses para a partir desse ponto, se possa desdobrar requisitos e indicadores de desempenho para o sistema PLM. Com essa característica, surge uma dificuldade para aplicar o método: é necessário saber técnicas e notações utilizadas para mapear e modelar processos. Nesse caso o autor se esmerou em entender esse assunto bem como a usar a notação de modelagem de processos BPMN. Dessa forma, é pouco provável que outro interessado em aplicar o método obtenha sucesso sem ter um mínimo de conhecimento sobre mapeamento e modelagem de processos de negócios. De forma semelhante, para cada organização interessada em implantar PLM existirá um grupo de stakeholders diferente que possuem interesses sobre o processo. Identificar esses stakeholders e entender suas necessidades é uma etapa realizada com ajuda do método para que com isso sejam identificados requisitos e indicadores desempenho. Com isso, se faz necessário entender as técnicas de identificação e análise de stakeholders para extrair deles toda a informação pertinente. Outra limitação da demonstração realizada está no tamanho da organização onde foi aplicado o método. Possivelmente com o aumento de entrevistados e stakeholders a aplicação por uma única pessoa será bastante difícil. Contudo, uma equipe com o treinamento adequado deve resolver essa possível deficiência devido ao grande volume de informação a ser coletada e não pelo método em si. Além disso, podem ser citadas as dificuldades encontradas em qualquer situação de mudanças em grandes corporações. Como referência a

149 149 esse assunto, o leitor pode consultar Cameron e Green (2009) e se inteirar dos aspectos cognitivos e psicodinâmicos que não foram tratados na pesquisa. Por fim, ressalta-se ainda a modelagem de sistema realizada que confere características significativas ao método desenvolvido, sejam elas: Possibilidade de comunicar a estrutura e os comportamentos desejados do sistema PLM; Maneira de visualizar e controlar as funcionalidades do sistema; Forma de compreender melhor o sistema que se estar elaborando, muitas vezes expondo oportunidades de simplificação e reaproveitamento; Ferramenta para identificar e gerenciar riscos. Essas características proporcionam ao método significativa robustez para definir um sistema PLM que satisfaça ao propósito pretendido de maneira previsível e consistente. Proporcionando dessa forma uma fundação solida que aceita modificações, adaptando-se a novas necessidades do negócio e de tecnologia. Contudo, essas características vêm com um preço a ser pago que são as técnicas e notações de modelagem de sistemas, tais como SysML. Essas devem ser dominadas para que o método seja corretamente aplicado. 6.3 COMPARAÇÃO E POSICIONAMENTO DO MÉTODO PROPOSTO A LITERATURA ENCONTRADA. Nesta seção é apresentada ao leitor uma analise sinótica, semelhante a que foi realizada no capítulo 3. Contudo, posiciona-se o método desenvolvido ressaltando características importantes em relação aos demais existentes. Essa análise é apresenta no Quadro 6-2.

150 150 Quadro 6-2: Análise sinótica dos trabalhos existentes relacionados ao auxilio a implementação PLM e a contribuição dado pelo desenvolvimento desse trabalho Autores Características (ZANCUL, 2009) (UMBLE et al., 2003) (GRIEVES, 2006) (SAAKSVUORI et al., 2008) Abordagem Desenvolvimento de Identificação, em trabalhos Aborda a implantação PLM Estrutura a implantação utilizada modelos de referência, anteriores relacionados a no nível estratégico. Define PLM com boas práticas de processos e identificação de ERP, os fatores de sucesso visão, avalia a situação gerenciamento de projeto. boas práticas de e uma compatibilização atual e planeja as Considera sistema PLM implantação de sistemas desses trabalhos. mudanças necessárias a como uma ferramenta para ERP. uma estratégia PLM. auxílio aos processos. Ênfase da proposta Seleção de sistemas PLM em função da aderência dos processos existentes a um modelo de referência desenvolvido. Boas práticas existentes e os casos de sucesso. Definição da estratégia de negócios relacionada a implementação de sistemas PLM. Gerenciamento das mudanças organizacionais e gerenciamento de projetos (projeto de implantação PLM). REQ4PLM Define requisitos para o sistema PLM e indicadores para serem alcançados após a implantação baseado nos processos de negócios do ciclo de vida do produto. Considera um sistema PLM como composto por software, processos e usuários. Sistémico: Processos, Stakeholders, usuários e funcionalidades tecnológicas analisados simultaneamente. Uso de indicadores para avaliar a implantação Não aborda. Não aborda. Indica ROI e ROA como indicadores de desempenho, contudo não mostra como obter esses indicadores. Indicadores são abordados de forma implícita (indicadores de projeto): prazos, orçamento, etc. Desdobra indicadores que devem validar a satisfação dos stakeholders do processo após a implantação de um sistema PLM

151 151 Continuação - Quadro 6-2: Análise sinótica dos trabalhos existentes relacionados ao auxilio a implementação PLM e a contribuição dado pelo desenvolvimento desse trabalho Autores Características Zancul (2009) Umble et al, 2002 Grieves (2006) Saaksvuori et al (2008) REQ4PLM Stakeholders Não usa o conceito de stakeholders. Aborda os usuários do sistema (software para PLM) como um tipo de stakeholder do sistema PLM. Não usa o conceito de stakeholders. Declara somente os usuários do sistema que são um tipo de stakeholder do sistema PLM. Não usa o conceito de stakeholders. Identifica os usuários do sistema PLM e membros da diretoria da empresa Não usa o conceito de stakeholders. Lista somente usuários do sistema PLM. Elícita os stakeholders dos processos de ciclo de vida e analisa suas necessidades relacionadas aos processos. Dimensões analisadas Processos de negócio e funcionalidades PLM Somente aplicativos de software e usuários Processos de negócios, funcionalidades PLM e pessoas. Processos de negócio. Processos de negócios, stakeholders e funcionalidades PLM. Análise de stakeholders do processo e de suas necessidades Não usa Não usa. Não usa. Não usa. Analisar os principais stakeholders dos processos de negocio para identificar suas necessidades Tipos de modelagem usada na proposta Uso de notações específicas de modelagem Nenhuma Nenhuma. Nenhuma. Nenhuma. Modelagem de sistemas e de processos Nenhuma Nenhuma. Nenhuma. Nenhuma. BPMN, SysML/UML

152 152 Este capítulo discutiu o método desenvolvido no Capitulo 4 e demonstrado no Capitulo 5. Essa discussão consistiu em apresentar: Vantagens e Desvantagens do método; Dificuldades para aplicá-lo; Posicionamento do método proposto à literatura encontrada. No próximo capítulo (Capítulo 7) são apresentadas a conclusão desse trabalho e as sugestões para novos trabalhos que podem dar continuidade a pesquisa realizada aqui.

153 CONCLUSÕES E SUGESTÕES PARA TRABALHOS FUTUROS Neste capítulo são apresentadas as conclusões do trabalho (Seção7.1) e sugestões para trabalhos futuros (Seção 7.2), que podem dar continuidade a pesquisa realizada. 7.1 CONCLUSÕES Este trabalho apresentou a proposta de um método chamado REQ4PLM. Trata-se de um método de auxílio à definição de requisitos para sistemas PLM. Suas características principais são: Utilização de métodos consolidados de engenharia de requisitos na elaboração de requisitos para um Sistema PLM; Estabelecimento de funcionalidades do sistema PLM relacionadas aos interesses dos stakeholders dos processos do ciclo de vida dos produtos; Derivação de requisitos para o sistema PLM para auxiliar as empresas a selecionar, acompanhar a implantação e atualizar a infraestrutura PLM, considerando as necessidades dos diversos stakeholders de processos. O método proposto foi demonstrado usando informações de um ambiente de desenvolvimento produtos com características laboratoriais por se tratar de um centro tecnológico CIMATEC (Centro Integrado de Manufatura e Tecnologia). Esse ambiente possui oportunidades de melhorias semelhantes àquelas encontradas no ambiente industrial o que o tornou atrativo para aplicação do método. Além disso, após a demonstração o método foi discutido em face de outras propostas encontradas na literatura existente. O resultado principal do trabalho é o desenvolvimento de uma forma de visualizar as funcionalidade e estrutura de um sistema PLM adequadas às necessidades dos stakeholders dos processos do ciclo de vida do produto e consequentemente, também, stakeholders de um

154 154 sistema PLM. Essa visão é usualmente negligenciada e substituída simplesmente por uma visão puramente tecnológica relacionada ao tema ou por uma visão isolada dos componentes principais de um sistema sociotécnico, tal como PLM: Pessoas, Processos e Ferramentas. Na demonstração realizada, os processos modelados apresentam oportunidades de melhoria declaradas pelos stakeholders ou identificadas na análise dos processos, sejam elas: No processo atual cada etapa possui sua própria cópia do modelo CAD do produto. Isso dificulta o gerenciamento dos dados e a constante verificação de consistência entre essas cópias, vide Figura 7-1. Na figura são mostrados os tipos de arquivos criados e compartilhados entre as diferentes atividades realizadas. Figura 7-1: Modelo BPMN do fluxo de dados no processo de desenvolvimento de produtos Cabe aqui ressaltar que quando os dados de produto possuem um grau significativo de granularidade: várias versões, tipos e fins, como os apresentados nos processos analisados, se tornam mais difícil gerencia-los e sincroniza-los. Nos processos analisados um esforço considerável da organização é voltado a garantir a rastreabilidade da informação e dos dados nos formatos utilizados. Contudo, para o caso analisado, esse esforço não é suficiente, pois frequentemente nos processo surgem divergências entre as versões dos dados existentes nas diferentes atividades do processo. Por exemplo, nas atividades do

155 155 processo de Planejar e Controlar Manufatura, é frequente não se saber ao certo qual é a versão atualizada do produto que foi projetado. Além disso, essa característica inibe a adoção de iniciativas que propicie a execução de tarefas de projeto do produto e planejamento da manufatura (geração de trajetórias de ferramentas para usinagem de moldes). O projeto do produto contempla de maneira tímida a manufaturabilidade do produto, visto que, quem realiza essas análises não tem todas as qualificações indicadas (o projeto de engenharia é desenvolvido por Designers) para o projeto de engenharia de produtos em polímeros. A avaliação de manufaturabilidade é realizada por engenheiros somente em etapas posteriores o que muitas vezes gera retrabalhos para os Designers. De outra forma, é possível compartilhar informação nos estágios inicias e fazer com que os demais interessados contribuam, já nessa fase inicial, fazendo com que o produto já seja concebido com diversas características de manufatura já bem resolvidas. A aplicação do método limitou-se a tratar de aspectos diretamente relacionados aos stakeholders e de caráter prático e não de aspectos psicológicos conforme delimitação inicial da pesquisa. Entretanto, nessa abordagem é possível inserir analises psicológicas dos stakeholders, como por exemplo, identificar aqueles que são resistentes à mudança e encontrar formas de contornar essa resistência. Relacionando-se perguntas de pesquisa, objetivos propostos e resultados alcançados pode-se obter o Quadro 7-1. Nele é mostrado que os resultados alcançados condizem com o que foi proposto no objetivo do trabalho.

156 156 Quadro 7-1: Relação entre perguntas de pesquisa, objetivos e resultados alcançados. Perguntas de pesquisa Objetivos da pesquisa Resultados da pesquisa Como as empresas podem selecionar requisitos para sistemas PLM de uma forma holística, considerando os diversos aspectos sociotécnicos envolvidos, stakeholders, tecnologia e processos do ciclo de vida do produto? Como garantir que os requisitos estejam relacionados às necessidades dos stakeholders, restrições, metas e objetivos do negócio? Objetivo principal Propor um método de geração de requisitos para sistemas PLM baseado nos processos do ciclo de vida do produto e seus stakeholders. Objetivos Específicos Desenvolver o método baseado em ferramentas de análise de stakeholders e de requisitos existentes; Aplicar o método desenvolvido em uma organização de desenvolvimento do produto; Discutir os benefícios do método frente a outras soluções da literatura ou da indústria. Método desenvolvido no capítulo 4, demostrado no capítulo 5 e discutido no capítulo 6. No método desenvolvido no capítulo 4 são utilizadas notações de modelagem utilizadas no meio industrial: BPMN e SysML. Além disso, foram utilizadas outras ferramentas, tais como, mapeamento e modelagem de processos e identificação e analise de stakeholders. No capítulo 5, o método foi demonstrado usando os processos de um ambiente de desenvolvimento de produtos. No capítulo 6, o método é discutido frente a seus pares acadêmicos e industriais. Com isso mostram-se as lacunas deixadas pelos existentes e cobertas pelo método REQ4PLM. 7.2 SUGESTOES PARA TRABALHOS FUTUROS A definição sistêmica apresentada nesse trabalho pode ser usada como base para novas pesquisas. Nesta seção são apresentadas sugestões de continuidade da pesquisa realizada nesse trabalho. No trabalho apresentado não houve aprofundamento das tecnologias possíveis de serem abordadas, ou mesmo os benefícios em adotá-las. Contudo a visão sistêmica que é dada ao tema pode servir de base para a modelagem detalhada de Sistemas PLM. De posse dessa

157 157 modelagem, como uma maneira de investigar a integração de novas tecnologias relacionadas à Realidade virtual, Realidade aumentada e Inteligência artificial. O método proposto REQ4PLM é uma maneira estruturada de obter requisitos para sistemas PLM baseados nos processos do ciclo de vida dos produtos e de seus stakeholders. Em aplicando o método, pode-se também definir indicadores de desempenho que buscam medir a satisfação dos stakeholders dos processos em relação a suas necessidades. Uma contribuição significativa poderia ser dada no desenvolvimento de trabalhos acadêmicos que propusessem a criação de matching funcional entre as funções documentadas em requisitos e as funções encontradas em pacotes de software para PLM oferecidos pelas empresas do ramo. Isso serviria para verificar a aderência entre as funcionalidades requeridas pelos processos na forma de requisitos e as funcionalidades oferecidas pelos fornecedores de software PLM. O trabalho prevê a elaboração de indicadores de desempenho para avaliar o cumprimento das necessidades dos stakeholders. Entretanto, a contribuição apresentada não detalha como coletar dados e calcular as métricas dos indicadores. Dessa forma, a pesquisa aqui apresentada pode ter continuidade na pesquisa para o cálculo automático das métricas usando os dados extraídos do sistema PLM. Dessa forma, o sistema PLM disponibilizaria telas mostrando em tempo real como está determinado indicador sempre que for necessário, além de ser uma forma de acompanhar a variação dos indicadores no tempo. O método proposto propõe a modelagem dos processos de negócio que se beneficiarão da abordagem PLM. Contudo, no trabalho, não houve menção a modelagem desses processos no sistema PLM propriamente dito. Essa atividade é critica para a real implantação de sistemas PLM e também consome grande parte do tempo de implantação. Para esse assunto sugere-se o desenvolvimento de mecanismos que automatizem a criação de fluxos de trabalho do sistema tomando como base os mapas de processos desenvolvidos em BPMN e exportados em XPDL - XML Process Definition Language (WFMC, 2008) para as

158 158 ferramentas PLM disponíveis no mercado. Com isso, buscar-se-ia reduzir o tempo de implantação e consequentemente seus custos.

159 159 REFERÊNCIAS Associação Brasileira de Normas Técnicas: NBR ISO : Sistema de gestão da qualidade-requisitos. Rio de Janeiro, Associação Brasileira de Normas Técnicas: NBR : Sistema de Gestão da Qualidade-Requisitos para organizações de aeronáutica, espaço e defesa. Rio de Janeiro ABRAMOVICI, M. Future trends in product lifecycle management (PLM). In: CIRP DESIGN CONFERENCE, 17., 2007, Proceedings Berlin: Springer, ACOSTA, L. M. C. A method for deriving performance indicators for product development process. 105f Tese(Mestrado em Engenharia Mecânica e Aeronáutica) Instituto Tecnológico de Aeronautica, São José dos Campos,. ALEMANNI, M. et al. Key performance indicators for PLM benefits evaluation: The Alcatel Alenia Space case study. Computers in Industry, n. 59, p ,2008. ALEXANDER, I. Building what stakeholders desire. IEEE Software, March/April, p , ALEXANDER, I. F.; STEVENS, R. Writing better requirements. London: Pearson Education, AMERI, F.; DUTTA, D. Product lifecycle management: needs, concepts and components. Ann Arbor-MI p. 45. Apostila University of Michigan. ARMISTEAD, C. G.; MACHIN, S. Implications of business process management for operations management. International Journal of Operations & Production Management, v.17, p.86-89, BAHIL, A. T.; GISSING, B. Re-evaluation systems engineering concepts using systems thinking. IEEE Transactions on Systems, Man and Cybernetics, v. 4, p , BANCROFT, N. H.; SEIP, H.; SPRENGEL, A. Implementing SAP R/3: how to introduce a large system into a large organization. 2. ed. Greenwich: Manning Publications Co., BARBALHO, S. C. M.; ROZENFELD, H. Análise da abrangência de metodologias de modelagem de empresas. In: ENCONTRO NACIONAL DA ASSOCIAÇÃO DE PÓS GRADUAÇÃO EM ADMINITRAÇÃO, 26., 2002, Salvador. Anais... [S.l., s.n.] CD- ROM. BARTHOLOMEW, D. Process is back. Industry Week, Nov BERGAMASCHI, S. Um estudo sobre projetos de implementação de sistemas para gestão empesarial. 181f Dissertação(Mestrado em Administração) Faculdade de Economia, Administração e Contabilidade, Univeridade de São Paulo. São Paulo.

160 160 BRYD, T. A.; TURNER, D. E. Measuring the flexibility of the information technology infrastructure: exploratory analysis of a construct. Journal of Management Information Systems, n. 17,. p , CAMERON, E.; GREEN, M. Gerenciando mudanças. São Paulo: Clio Editora, CIMADATA. Industrial Organization Consulting, Disponivel em: < Acesso em: 03 outubro CIMDATA. PDM to PLM: Growth of An Industry. CIMDATA. Ann Arbor, p Relatório de Negócios. CIMDATA. Measuring Business Process Benefits Achieved Using SMARTEAM. CIMDATA. Ann Arbor Relatório de Negócios. CIMDATA. Product Lifecycle Management (PLM) Definition. CIMDATA: Global Leaders in PLM consulting, Disponivel em: < Acesso em: 25 mar COLANGELO FILHO, L. Implantação de sistemas ERP. São Paulo: Atlas, COLOMBO, E.; FRANCALANCI, C. Selecting CRM packages based on architectural, functional, and cost requirements: Empirical validation of a hierarchical ranking model. Requirements Engineering, v. 9, n. 3, p , Aug COMMISSION OF THE EUROPEAN COMMUNITIES UNDER ESPRIT PROGRAMME. Workflow Management for Simultaneous Engineering Networks. ESPRIT programme, Disponivel em: < Acesso em: 21 janeiro CROSS, N. Engineering design methods: Strategies for product design. West Sussex: Jonh Wiley & Sons, ISBN CURTIS, B.; KELLNER, M. I.; OVER, J. Process modeling. Communications of the ACM, v.35, p , DAVENPORT, T. H. Process innovation: reegineering work through information technology. Boston: Havard Business School press, DAVENPORT, T. H. Saving IT s soul. Havard Business Review, march/april, p.11-27, DAVIS, R. ARIS design platform advanced process modelling and administration. London: Springer-Verlag, DOD-SYSTEMS MANAGEMENT COLLEGE. Systems engineering fundamentals. Fort Belvoir: Defense Acquisition Press, DREILING, A. R. et al. Model based software configuration: patterns and languages. European Journal of Information Systems, v.18, p ,

161 161 ERIKSSON, H.-E.; PENKER, M. Business modeling with UML. New York: Jonh Willey & Sons, FNQ. Modelo de Excelência da Gestão, Disponivel em: < Acesso em: 12 Setembro FREEMAN, R. E. Strategic management: a stakeholder approach. Marshfield: Pitman, ISBN GRIEVES, M. Product lifecycle management. New York: McGraw-Hill, HANSMANN, H.; NEUMANN, S. Prozessorientierte Einführung von ERP-Systemen. In: BECKER, J.; KUGELER, M.; ROSEMANN, M. Prozessmanagement: Ein Leintfaden zur prozessorientierten Organisationsgestaltung. Berlim: Springer, HECHT, B. Chose the right ERP software. Datamation, march/spril, HENDRICKS, K. B.; SINGHAL, V. ; STRATMAN, J. K. The impact of enterprise systems on corporate performances: a study of ERP, SCM and CRM system implementations. Journal of Operations Managemen, n. 25, HILL, JR., S. A winning strategy. Manufacturing business technology, Setembro HOJLO, J.; D AQUILA, M.; CARTER, K. The product lifecycle management market sizing report, [s.n.] HOOKS, I. F.; FARRY, K. A. Customer-centered products: Creating Successful Products through smart requirements management. New York: AMACOM, HUAN, S. M. et al. An empirical study of relationship between IT investment and firm performance: a resource-based perspective. European Journal of Operational Research, n. 173, p , HULL, E.; JACKSON, K.; DICK, J. Requirements Engineering. London: Springer, ISBN IBM. PLM Services, Disponivel em: < 01.ibm.com/software/plm/services/index.html>. Acesso em: 03 outubro INCOSE. System engineering handbook. San Diego: [s.n.], v , INDULSKA, M. et al. Business Process Modeling: Perceived benefits. 28th International Conference on Conceptual Modeling. Heidelberg: Springer p INTERNATIONAL STANDARD ORGANIZATION. ISO/IEC 15288:2008: Systems and software engineering - system life cycle processes. [S.l.] JSF. JOIN STRIKE FIGHTER. HISTORY Disponivel em: < Acesso em: 6 Agosto KAPLAN, R. S.; NORTON, D. P. The balanced scorecard. Boston: Havard Business School Press, 1996.

162 162 KIMBLE, C.; PRABHU, V. B. CIM and manufacturing industry in the North East of England. In: PARSAEI, H. R.; KARWOWSKI, W. A survey of some current issues in ergonomics of advanced manufacturing systems. Amsterdam: Elsevier publications, p KRASNER, H. Ensuring e-business sucess by learning from ERP failures. IT PRO, v. 3. n. 52, p , Fev LATOUR, B. Pandora s Hope: essays on the reality of Science Study. Cambridge: Havard Business Press, P LOUREIRO. Introdução a engenharia de sistemas.notas de aula - Instituto Tecnológico de Aeronáutica, São José dos Campos LOUREIRO, G. A system engineering and concurrent engieering framework for the integrated development of products. Tese(Doutorado) Loughborough University, Loughborough MABERT, V. ; SONI, A. ; VENKATARAMANAN, M. A. The impact of organization size on enterprise resource planning (ERP) implementations in the US manufacturing sector. OMEGA, n. 31, p , MABERT, V. A.; SONI, A. ; VENKATARAMANAN, M. Enterprise resource planning survey of US manufacturing firms. Production & Inventory Management Journal, n. 41,. p MACKRELL, J. PLM benefits, metrics, and ROI for PLM. CIMdata, Disponivel em: < Acesso em: 1 Dezembro MARCONI, M. A.; LAKATOS, E. M. Metodologia científica. São Paulo: Atlas, MASON, R.; MITROF, I. Challenging strategic planning assumptions: theory, cases, and techniques. New York: Jonh Wiley & Sons, MORAES FILHO, C. A.; WEIGERG, G. M. L. Seleção de projetos de P&D: Uma abordagem prática. Revista de Administração, São Paulo, v. 32, n. 1, p , jan./mar MOREIRA, J. C. T. Usina de valor. São Paulo: Gente, NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Integration definition for function modeling (IDEF0). [S.l.] OBJECT MANAGEMENT GROUP. Unified Modeling Language. Needham OBJECT MANAGEMENT GROUP. Systems Modeling Language. Needham OBJECT MANAGEMENT GROUP. Business Process Modeling and Notation. Needham OULD, M. A. Business Process: Modeling and Analyst for Re-Engineering and Improvement. Chichester: Jonh Wiley & Sons, 1995.

163 163 PHILLIPS, J. J.; PHILLIPS, P. P. Show me the money. San Francisco: Berrett-Koehler Publishers, RUMMLER, G. E. A. R. A.; R A M I A S, A. L. A. N. J..; R U M M L E R, R. I. C. H. A. R. D. A.. White space revisited creating value through process. San Francisco: Jossey-Bass, RANGAN, R. M. et al. A survey of product lifecycle management implementations,directions, and challenges. Journal of Computing and Information Science in Engineering, v. 5, n. 3, RECKER, J. BPMN Modelling-Who, Where, How and Why. BPTrends, Maio, p. 2-8, RECKER, J. Evaluation of process modeling grammars. Heidelberg: Springer, RICCIO, E. L. Efeitos da tecnoogia de informação na contabilidade: estudo de casos de implementação de sistmas empresariais integrados - ERP Tese(Livre docência ) - Universidade de São Paulo. São Paulo RILEY, L. A.; COX, L. Computer Integrated Manufacturing: Challenges and Barriers to Implementation. The technology interface, New Mexico, December Disponivelem: < Acesso em: 06 Ago ROULSTONE, D. B.; PHILLIPS, J. J. ROI for Technology Projects - Measuring and Delivering Value. Oxford: Butterworth-Heinemann, ISBN ROZENFELD, H. et al. Gestão de Desenvolvimento de Produtos. São Paulo: Saraiva, SAAKSVUORI, A.; IMMONEN, A. Product Lifecycle Management. 3. ed. Berlin: Springer, SCHUH, G. et al. Process oriented framework to support PLM implementation. Computers in Industry, v59, n. 2, p , SEDDON, P. B. et al. The IS Effectiveness Matrix: The importance of Stakeholder and System in Measuring IS Success. In: International Conference on Information Systems, 19, 1998, Helsink, Proceedings [S.l, S.n] SILVA, S. D. A.; TRABASSO, L. G. Características e dificuldades de uma implementação PLM: estudo de caso no desenvolvimento de turbinas a gás. Congresso Brasileiro de Gestão de Desenvolvimento de Produtos. São José dos Campos: IGDP SOUZA, A.; ZWICKER, R. Aspectos envolvidos na seleção e implementação de sistemas ERP. Assembléia Anual do Conselho Latino Americano de Escolas de Administração, 34, 1999, [S.l.]: CLADEA SOUZA, C. A.; SACCOL, A. Z. Sistemas ERP no Brasil: teoria e casos. São Paulo: Atlas, SPARX-SYSTEMS. UML tools for software development and modelling. Enterprise Architect UML modeling tool, Disponivel em: < Acesso em: 10 Fevereiro 2011.

164 164 TECHNICAL BOARD INTERNATIONAL COUNCIL ON SYSTEMS ENGINEERING (INCOSE). Systems engineering handbook: a guide for system life cycle process and activities. San Diego: INCOSE, THEMISTOCLEOUS, M. et al. ERP Problems and application integration issues: a emprirical survey. In: HAWAII INTERNATIONAL COFERENCE ON SYSTEM SCIENCE, 34, 2001, Maui. Proceedings [S.l: HICSS, [s.n], TOSCANO, G.; OSTINELLI, C. A Performace measurement system model from activitybased management accounting perspective. In: ANNUAL CONGRESS OF THE EUROPEAN ACCOUNTING ASSOCIATION, 21, 1998, Antwerp. Proceedings...: Brussels: EAA, TRABASSO, G. Desenvolvimento integrado de produtos. Instituto Tecnologico de Aeronáutica. São José dos Campos Apresentação. TURUNEN, P.; TALMON, J. Stakeholder groups in the evaluation of medical information systems. In: EUROPEAN CONFERENCE ON THE EVALUATION OF INFORMATION TECHNOLOGY, 7, 1998, Dublin. Proceedings... Dublin: [s.n.] UMBLE, E. J.; HAFT, R. R.; UMBLE, M. Enterprise resource planning: Implementation procedures and critical success factors. European Journal of Operational Research, v. 146, n. 2, p , April UNITED STATES AIR FORCE SYSTEMS COMMAND. AFWAL-TR : Function modeling manual(idef0),. Ohio, v. 4. VAN DER AALST, W. M. P. et al. Workflow patterns. Distributed and Parallel Databases, v.14, p. 5-51, VERNADAT, F. B. Enterprise modeling and integration: principles and Applications. [S.l]: Springer, VERNADAT, F. B. UML: towards a unified enterprise modeling language. International Journal of Production Research, v. 17, n. 40, p , WEILKIENS, T. Systems engineering with SysML/UML: modeling, analysis, design. Burlington: Morgan Kaufmann Publishers, WORKFLOW MANAGEMENT COALITION. WFMC-TC-1025 XM: Process Definition Language: XPDL. Hingham, WHITE, S. A.; MIERS, D. BPMN modeling and reference guide. Lighthouse Point: Future Strategies, Book Division, WOMACK, J. P.; JONES, D. T.; ROOS, D. The machine that changed the world. [S.l.]: [s.n.], WRIGHT.MEDICAL GROUP Prophecy, Disponivel em: < Acesso em: 10 jan YOUNG, R.. The requirements engineering handbook. Norwood: Artech House, 2004.

165 165 ZANCUL, E. Estudos de caso sobre a implantação da gestão do ciclo de vida do produto em empresas de manufatura. In: SIMPOSIO DE ENGENHARIA DE PRODUÇÃO, 15, Anais...Bauru: UNESP, 2008, p ZANCUL, E. D. Z. Gestão do ciclo de vida de produtos: seleçao de sistemas PLM com base em modelos de referência., 226f Tese (Doutoado em Engenharia de Produção) - Escola de Engenharia de São Carlos, São Carlos.

166 ANEXOS 166

167 167 A1. BREVE RESUMO DA NOTAÇÃO BPMN Neste anexo são apresentadas as entidades utilizadas neste trabalho e as comumente utilizadas na modelagem de processos de negócio da notação BPMN (Business Process and Notation). O objetivo é apenas orientar o autor quanto à modelagem realizada no trabalho e não realizar uma revisão de modelagem de processo usando BPMN. Para isso o leitor pode consultar as referências apresentadas no texto a respeito do assunto. Os quadros desenvolvidos neste anexo são baseados na instrução normativa desenvolvida pelo Object Management Group (OMG) (OBJECT MANAGEMENT GROUP, 2009) e no livro de Stephen A. White, Derek Miers (WHITE e MIERS, 2008).

168 Atividades Atividades representam o trabalho realizado por uma organização: Elas representam um passo no processo. As Atividades podem ser compostas ou não. Tarefa Uma tarefa é uma atividade simples que é usada para modelar o trabalho é realizado em um processo e não é definida em mais detalhes. BPMN possui diferentes tipos de tarefas: Subprocesso Trata-se de uma atividade composta cujos detalhes são definidos como um conjunto de outras atividades. Subprocesso encapsulado Depende completamente do processo pai. Eles não podem conter pools ou lanes. Processo reutilizável É um processo de negócio definido em outro diagrama de processo, que não depende do processo pai. Gateways Gateways são elementos usados para controlar a divergência e convergência dos fluxos de trabalho. Gateway exclusivo baseado em dados GEBD Divergência: Uma decisão exclusiva tem duas ou mais saídas de fluxo de trabalho, mas somente uma deles será seguido e a decisão depende da avaliação do processo de negócio. Convergência: é usado para unir fluxos de trabalho alternativos. Gateway exclusivo baseado em eventos - GEBE É usado como um elemento de divergência, Esse gateway representa um ponto no processo onde somente um, de muitos fluxos pode continuar, mas baseado em um evento, não em condição baseada em dados como o GEBD. Gateway Paralelo Divergência: é usado para criar fluxos paralelos. Convergência: é usado para sincronizar múltiplos fluxos paralelos em um. O fluxo continua somente após a chegada de todos os fluxos de entrada ao gateway. Gateway Inclusivo Divergência: Indica que somente uma ou mais caminhos no fluxo do processo podem ser ativados de muitos disponíveis, e a decisão é baseada em dados do processo. Convergência: Indica que muitos caminhos de saída de um gateway inclusivo, usados como um elemento de divergência, podem ser sincronizados em apenas um. Gateway Complexo Divergência: é usado para controlar pontos no processo onde existem decisões complexas que não são fáceis de gerenciar com outros tipos de gateways. Convergência: Quando um gateway é usado como um aglutinante de fluxos então existirá uma expressão que determinará qual dos fluxos de entrada será necessário para o processo continuar. 168

169 Swinlanes Pools Um Pool é container para um único processo. O nome do pool pode ser considerado o nome do processo. Existe pelo menos um pool em processo modelado com BPMN. Lane Uma lane é uma subdivisão de um pool e representa um papel ou área organizacional. Artefatos Permite ou fornece informação adicional sobre o processo Annotação Fornece informação adicional sobre o processo ao leitor dos modelos. Grupo É um mecanismo visual que permite o agrupamento de atividades para o propósito de documentação ou análise dos processos. Objeto dado Fornece informações sobre as entradas e saídas de uma atividade, isto é, documentos, dados e outros objetos usados e modificados durante o processo. Objetos dado não tem qualquer efeito sobre o fluxo do processo ou fluxo de informações inerentes ao processo. Objetos de conexão Sequence flow É usado para mostrar a ordem que as atividades serão realizadas em um processo. Is used to show the order that activities will be performed in a Process. Ele é usado para representar a sequencia do fluxo objetos, onde estão presentes atividades, gateways e eventos. Message flow A entidade Message flow é usada para mostrar o fluxo de mensagens entre duas outras entidades ou processos. A entidade Message flow representa mensagem (informação), não o controle do fluxo de informação. Nem todas as entidades Message flow são cumpridas para cada instância do processo e nem existe uma ordem específica para as mensagens. Associação Uma associação é usada para associar informação e artefatos com objetos de fluxo. 169