proposta de um método para definição de requisitos de sistemas plm
TRANSCRIPT
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
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, 2011. 182 f. Tese de doutorado – Engenharia Aeronáutica e Mecânica Sistemas Aeroespaciais e Mecatrônica – Instituto Tecnológico de Aeronáutica, 2011. 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). 2011. 182 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 12230-083
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
iv
Sou cabra da pesteSou cabra da pesteSou cabra da pesteSou 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é
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.
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.
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.
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.
ix
LISTA DE FIGURAS
Figura 2-1: Mapa de valor – PLM adaptado de (GRIEVES, 2006) ......................................... 39
Figura 2-2: Perspectivas abordadas na modelagem de processos ............................................ 43
Figura 2-3: Elementos do IDEF0 utilizados para identificar stakeholders .............................. 55
Figura 2-4: Relacionamento entre requisitos e modelagem de sistemas. Adaptado de (HULL,
et al., 2005) ............................................................................................................................... 62
Figura 2-5: Diagrama de contexto de um sistema e interação entre funcionalidades (HULL, et
al., 2005) ................................................................................................................................... 63
Figura 2-6: Interseção da UML 2.0 e SysML (Fonte: (OBJECT MANAGEMENT GROUP,
2010) ......................................................................................................................................... 65
Figura 2-7: Taxonomia dos diagramas SysML, fonte: (OBJECT MANAGEMENT GROUP,
2010) ......................................................................................................................................... 67
Figura 3-1: Modelo de seleção de soluções ERP - Múltiplos filtros. Fonte: (SOUZA e
SACCOL, 2008) ....................................................................................................................... 75
Figura 3-2: Processo comumente encontrado para a definição de soluções PLM ................... 80
Figura 4-1: Representação dos componentes de um Sistema PLM e suas (adaptado de
Grieves, (2006)). ....................................................................................................................... 82
Figura 4-2: Sistema PLM e seus elementos: uma nova proposta ............................................. 83
Figura 4-3: Desenvolvimento do método domínio do problema e da solução ......................... 84
Figura 4-4: Diagrama da caixa preta- mostrando a função principal do método desenvolvido
.................................................................................................................................................. 85
Figura 4-5: Diagrama de atividades mostrando as etapas do método desenvolvido ................ 85
Figura 4-6: Abordagem para determinação de indicadores de desempenho do processo ........ 89
Figura 4-7: Processo de determinação de requisitos de implementação. ................................. 92
x
Figura 4-8: Exemplo de diagrama de contexto ......................................................................... 94
Figura 5-1: Processo de desenvolvimento de produtos .......................................................... 101
Figura 5-2: Processo de Projetar do produto .......................................................................... 102
Figura 5-3: Processo de projetar molde .................................................................................. 103
Figura 5-4: Processo de planejamento da manufatura ............................................................ 104
Figura 5-5: Processo de planejamento usinagem 2D.............................................................. 105
Figura 5-6: Processo de planejamento usinagem 3D.............................................................. 105
Figura 5-7: Mecanismo de análise de stakeholder do processo ............................................. 107
Figura 5-8: Entradas, saídas, mecanismos e controles do Ciclo de Vida do Produto e os
stakeholders identificados. ..................................................................................................... 108
Figura 5-9: Entradas, saídas, mecanismos e controles do processo projetar produto. ........... 109
Figura 5-10: Entradas, saídas, mecanismos e controles do processo de projeto de moldes. .. 112
Figura 5-11: Estrutura de pastas e arquivos criada para gerenciar os dados do processo de
desenvolvimento de produtos. ................................................................................................ 113
Figura 5-12: Entradas, saídas, mecanismos e controles do processo Planejar e Controlar
manufatura. ............................................................................................................................. 115
Figura 5-13: Processo de determinação de indicadores de desempenho do processo ............ 123
Figura 5-14: Processo de determinação de requisitos dos stakeholders. ................................ 126
Figura 5-15: Diagrama de contexto para o processo >Projetar Produto< .............................. 128
Figura 5-16: Diagrama de contexto para o processo de >Projetar Molde< ............................ 129
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 .............................................................................................................................. 132
Figura 5-19: Diagrama de contexto para o processo >projetar molde< acrescido do fluxo de
informação .............................................................................................................................. 133
xi
Figura 5-20: Diagrama de contexto para o processo >Planejar e controlar manufatura<
acrescido do fluxo de informação ........................................................................................... 134
Figura 5-21: Diagrama de Casos de uso ................................................................................. 136
Figura 5-22: Diagrama de blocos representando a estrutura do sistema ................................ 137
Figura 5-23: Requisitos determinados para PLM ................................................................... 145
Figura 7-1: Modelo BPMN do fluxo de dados no processo de desenvolvimento de produtos
................................................................................................................................................ 154
xii
LISTA DE QUADROS
Quadro 1-1: Estímulos ao surgimento do conceito PLM fonte: (AMERI e DUTTA, 2004;
GRIEVES, 2006) ...................................................................................................................... 20
Quadro 1-2: Situações relevantes para diferentes estratégias de pesquisa. FONTE: YIN
(2005). ...................................................................................................................................... 26
Quadro 1-3: Conteúdo dos capítulos 2 e 3 ............................................................................... 27
Quadro 1-4: Conteúdo do capítulo 4 ........................................................................................ 28
Quadro 1-5: Conteúdo dos capítulos 5 e 6 ............................................................................... 28
Quadro 1-6: Conteúdo do capítulo 7 ........................................................................................ 29
Quadro 2-1: Estágios do ciclo de vida segundo a ISO/IEC 15288: 2008 ................................ 30
Quadro 2-2: Definição de termos importantes, fonte: (ISO, 2008; TECHNICAL BOARD
INTERNATIONAL COUNCIL ON SYSTEMS ENGINEERING (INCOSE), 2010;
FREEMAN, 1984) .................................................................................................................... 57
Quadro 3-1 Análise sinótica dos trabalhos existentes relacionados ao auxilio a implementação
PLM .......................................................................................................................................... 78
Quadro 4-1: Mapear e modelar processos ................................................................................ 86
Quadro 4-2: Exemplo de análise realizado em stakeholders do processo de mudanças de
engenharia ................................................................................................................................. 87
Quadro 4-3: Analisar de stakeholders ...................................................................................... 88
Quadro 4-4: Definir Indicadores de Desempenho .................................................................... 90
Quadro 4-5: Determinar Requisitos para o sistema PLM......................................................... 95
Quadro 5-1: Ferramentas PLM (CAD/CAM/CAE) utilizados no DPI .................................... 98
Quadro 5-2: Planilha típica usada para registrar as modificações realizadas no produto durante
seu desenvolvimento. ............................................................................................................. 110
xiii
Quadro 5-3: Análise de stakeholders identificados nos processos analisados ....................... 117
Quadro 5-4: Aplicação do método para criação de indicadores ............................................. 124
Quadro 5-5: Requisitos obtidos com o método ...................................................................... 139
Quadro 6-1: Analise do método desenvolvido em aplicado em ambiente de desenvolvimento
de produtos SENAI-CIMATEC ............................................................................................. 146
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 ............... 150
Quadro 7-1: Relação entre perguntas de pesquisa, objetivos e resultados alcançados........... 156
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
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 – AutoCADTM DraWinG
SLDPRT – SoLiDworks PaRt
xvi
SUMÁRIO
RESUMO ............................................................................................................................................................. vii
ABSTRACT ........................................................................................................................................................ viii
1. INTRODUÇÃO .......................................................................................................................................... 18
1.1 JUSTIFICATIVA E MOTIVAÇÃO ......................................................................................... 18
1.2 OBJETIVOS GERAL E ESPECÍFICO .................................................................................... 22
1.3 CONTRIBUIÇÃO DO TRABALHO ....................................................................................... 23
1.4 ABORDAGEM DO TRABALHO ........................................................................................... 24
1.5 METODOLOGIA DA PESQUISA E ESTRUTURA DO TRABALHO ................................. 25
2. FUNDAMENTAÇÃO TEÓRICA ............................................................................................................ 30
2.1 PRODUCT LIFECYCLE ......................................................................................................... 30
2.2 PRECURSORES DO PLM – PRODUCT LIFECYCLE MANAGEMENT ............................ 31
2.2.1 COMPUTER AIDED DESIGN, MANUFACTURING e ENGINEERING (CAD/CAM/CAE)........ 31
2.2.2 COMPUTER INTEGRATED MANUFACTURING - CIM ....................................................... 32
2.2.3 PRODUCT DATA MANAGEMENT - PDM .......................................................................... 33
2.2.4 ERP, CRM, SCM ............................................................................................................... 35
2.3 PLM – PRODUCT LIFECYCLE MANAGEMENT ............................................................... 36
2.4 GERENCIAMENTO POR PROCESSOS ................................................................................ 40
2.4.1 MAPEAR PROCESSOS ...................................................................................................... 41
2.4.2 MODELAR PROCESSOS.................................................................................................... 43
2.4.3 MÉTODOS DE MODELAGEM DE PROCESSOS .................................................................. 45
2.5 INDICADORES DE DESEMPENHO E GERAÇÃO DE VALOR ......................................... 46
2.5.1 IMPORTÂNCIA DE INDICADORES PARA O GERENCIAMENTO POR PROCESSOS ............. 47
2.5.2 MÉTODOS PARA MEDIR A MELHORIA COM IMPLANTAÇÃO DE PLM............................. 48
2.5.3 ATRIBUTOS PARA UM BOM INDICADOR ........................................................................ 50
2.6 ANÁLISE DE STAKEHOLDERS ............................................................................................. 53
2.6.1 IDENTIFICAÇÃO DE STAKEHOLDERS ............................................................................... 54
2.6.2 ANÁLISE DE NECESSIDADES DE STAKEHOLDERS ............................................................. 56
2.7 PROCESSO DE ENGENHARIA DE SISTEMAS .................................................................. 57
2.8 PROCESSO DE ENGENHARIA DE REQUISITOS .............................................................. 60
2.9 MODELAGEM DE SISTEMAS .............................................................................................. 62
2.9.1 SYSTEM MODELING LANGUAGE – SYSML ...................................................................... 65
3. ABORDAGENS EXISTENTES PARA PLM ......................................................................................... 71
3.1 ABORDAGENS CONSULTADAS NA LITERATURA ........................................................ 71
3.2 ABORDAGEM ENCONTRADA NA INDÚSTRIA ............................................................... 80
xvii
4. DESENVOLVIMENTO DO MÉTODO REQ4PLM.................. ............................................................ 82
4.1 ETAPA I – MAPEAR E MODELAR PROCESSOS ............................................................... 85
4.2 ETAPA II – ANALISAR STAKEHOLDERS ........................................................................... 86
4.3 ETAPA III – DEFINIR INDICADORES DE DESEMPENHO ............................................... 88
4.4 ETAPA IV – DETERMINAR REQUISITOS PARA O SISTEMA PLM ................................ 90
5. DEMOSTRAÇÃO DO MÉTODO REQ4PLM ....................................................................................... 96
5.1 FERRAMENTA COMPUTACIONAL UTILIZADA.............................................................. 97
5.2 DEPARTAMENTO DPI E A INFRAESTRUTURA PLM EXISTENTE ............................... 97
5.3 MAPEAR E MODELAR PROCESSOS .................................................................................. 99
5.4 ANALISAR STAKEHOLDERS .............................................................................................. 106
5.4.1 PROCESSO PROJETAR PRODUTO .................................................................................. 108
5.4.2 PROCESSO PROJETAR MOLDE ...................................................................................... 111
5.4.3 PROCESSO PLANEJAR E CONTROLAR MANUFATURA ................................................... 114
5.5 DEFINIR INDICADORES DE DESEMPENHO ................................................................... 123
5.6 DETERMINAR REQUISITOS .............................................................................................. 126
5.6.1 MODELAGEM DE DIAGRAMAS DE CONTEXTO ............................................................. 127
5.6.2 MODELAGEM DE DIAGRAMAS DE CASOS DE USO E DIAGRAMA DE BLOCOS .............. 135
5.6.3 MODELAGEM DE DIAGRAMA DE REQUISITOS ............................................................. 138
6. DISCUSSÃO DO MÉTODO REQ4PLM .............................................................................................. 146
6.1 VANTAGENS, DESVANTAGENS E APLICABILIDADE DO MÉTODO. ....................... 146
6.2 DIFICULDADES PARA APLICAÇÃO DO MÉTODO ....................................................... 147
6.3 COMPARAÇÃO E POSICIONAMENTO DO MÉTODO PROPOSTO A LITERATURA ENCONTRADA. ............................................................................................................................................ 149
7. CONCLUSÕES E SUGESTÕES PARA TRABALHOS FUTUROS .................................................. 153
7.1 CONCLUSÕES ...................................................................................................................... 153
7.2 SUGESTOES PARA TRABALHOS FUTUROS .................................................................. 156
REFERÊNCIAS ................................................................................................................................................ 159
ANEXOS .............................................................................................................................................................166
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
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
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 1990. 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)
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:
Internos Externos
Est
ímu
los
ao s
urg
imen
to d
o
con
ceit
o P
LM
Necessidade de inovação dos produtos e consequentes ganhos de market share
Globalização dos mercados
Conhecimento sobre anseios dos clientes Customização em massa e escala de produção
Excelência nas operações Complexidade dos produtos
Colaboração global Prolongamento no ciclo de vida do produto e redução do ciclo de desenvolvimento
Melhoria da qualidade Restrições e necessidades da cadeia de fornecimento
Regulamentação ambiental e sanitária
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
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
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
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
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
Quadro 1-2: Situações relevantes para diferentes estratégias de pesquisa. FONTE: YIN (2005).
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.
Estratégia Forma da questão da pesquisa
Exige controle sobre eventos comportamentais?
Focaliza acontecimentos contemporâneos?
Experimento Como, por que Sim Sim Levantamento Quem, o que, onde,
quantos, quanto Não Sim
Análise de arquivos Quem, o que, onde, quantos, quanto
Não Sim / não
Pesquisa histórica Como, por que Não Não Estudo de caso Como, por que Não Sim
27
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.
2.1.Product lifecycle. 2.2.Precursores do PLM – Product
Lifecycle Management. 2.3.PLM – Product Lifecycle
Management. 2.4.Gerenciamento por processos 2.5. Indicadores de desempenho e
geração de valor. 2.6.Análise de stakeholders 2.7.Processo de engenharia de
sistemas. 2.8.Processo de engenharia de
requisitos. 2.9.Modelagem de sistemas.
Capítulo 2 Fundamentação Teórica
3.1. Abordagens consultadas na
Academia. 3.2. Abordagem encontrada na
Indústria.
Capítulo 3 Abordagens existentes para PLM
Fase #1
28
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.
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,
Capítulo 4 Desenvolvimento do Método REQ4PLM
4.1. Mapear e modelar processos 4.2. Analisar stakeholders. 4.3. Definir indicadores de desempenho. 4.4. Determinar requisitos para osistema
PLM.
Fase #2
Capítulo 5 Demonstração do Método
5.1.Ferramentas Computacionais utilizadas para a demonstração do método.
5.2.Departamento DPI e a Infraestrutura PLM existente.
5.3.Mapear e modelar processos. 5.4.Analisar stakeholders. 5.5.Definir indicadores. 5.6.Determinar requisitos.
Fase #3
6.1. Vantagens, desvantagens e aplicabilidade do método.
6.2. Dificuldades para aplicação do método.
6.3. Comparação e posicionamento do método proposto à literatura encontrada.
Capítulo 6 Discussão sobre o método
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.
Quadro 1-6: Conteúdo do capítulo 7
Capítulo 7 Conclusão
7.1 Resultados do trabalho. 7.2 Sugestões para outros
trabalhos.
30
2. FUNDAMENTAÇÃO TEÓRICA
Nesse capitulo é apresentada a fundamentação teórica para elaboração do método
proposto no trabalho.
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 15288 (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
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).
2.2.1 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
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.
2.2.2 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
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).
2.2.3 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
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
1990. 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
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.
2.2.4 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
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
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
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
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.
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
Valor
Lucro
Receita
Custos
Preço
Quantidade
Funções
Processos
Qualidade
Pessoal
Energia
Material
Homem hora
Tempo Ativos
Impacto negativo
Impacto moderado
Impacto positivo
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
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.
2.4.1 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
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
melhoria. E são destas oportunidades que surgem os principais benefícios da gestão por
processos.
2.4.2 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
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
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.
2.4.3 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
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
ARISTM 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
2.5.1 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
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.
2.5.2 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
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
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.
2.5.3 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
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 estima-
lo 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
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
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
“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.
2.6.1 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
� 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.
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
Elemento de processo Entrada Saída
Controles
Mecanismos
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.
2.6.2 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
2.7 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 Definição
Atividade Conjunto de tarefas coesas de um processo Elemento A parte de um sistema que pode ser implementada para o cumprimento de
requisitos específicos. Organização Pessoa ou grupo de pessoas e instalações com uma estrutura de
responsabilidade, autoridade e relacionamento. Estágio 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. Projeto 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. Processo Conjunto de atividades inter-relacionadas ou que interagem para
transformar inputs em outputs. Sistema PLM 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
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
Ferramenta ou software PLM
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.
Infraestrutura PLM
É 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
Sistema 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
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.
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
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
(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
relacionamento pode ser entendido como camadas sobrepostas em que a inferior suporta a
superior e assim sucessivamente. A Figura 2-4 ilustra esse relacionamento.
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).
Camada de Requisitos
Camada de Modelagem
Camada de Requisitos
Camada de Modelagem
Camada de Requisitos
Camada de Modelagem
Estabelecimento da Necessidade
Modelagem do Uso
Requisitos dos Stakeholders
Modelagem Funcional
Requisitos de Sistema
Modelagem de Desempenho
Camada de Requisitos Requisitos de Subsistema
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.
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
Sistema
Sistemas externos
Ameaças externas
Funcionalidade de interface
Funcionalidade interna
Usuários
Funcionalidade para interação com usuários
Funcionalidade da garantia da
qualidade
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
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.
2.9.1 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.
Figura 2-6: Interseção da UML 2.0 e SysML (Fonte: (OBJECT MANAGEMENT GROUP, 2010)
UML 2.1 SysML
Não utilizada SysML
Extensão da UML para SysML
UML reusada pelo SysML: (UML4SysML)
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
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.
bdd [SysML Block Definition] diagrams [diagrams]
«block»Diagrama de
requisitos
notesDiagrama novo
«block»Diagrama de
ativ idades
notesDiagrama modificado do UML2.0
«block»Diagrama máquinas
de estado
notesIgual a UML 2.0
«block»Diagrama de
sequência
notesIgual a UML 2.0
«block»Diagrama use case
notesIgual a UML 2.0
«constraintBlock»Diagrama de blocos
notesDiagrama modificado do UML2.0
«block»Diagrama interno de
blocos
notesDiagrama modificado do UML 2.0
«block»Diagrama de pacotes
notesIgual a UML 2.0
«block»Diagrama
parametrico
notesDiagrama novo
«block»Diagrama
comportamental
«constraintBlock»Diagrama estrutual
«block»Diagrama SysML
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 { }20VmP ×= & e { }AVm 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
� 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
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
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
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
� 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
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
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.
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.
(c) Refinamento da análise � Teste do sistema;
� Avaliação dos detalhes comerciais.
(d) Avaliação tecnológica e de mercado � Seleção de fornecedores; � Seleção de produtos.
Decisão
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
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
Qua
dro
3-1
An
ális
e si
nótic
a do
s tr
abal
hos
exis
tent
es
rela
cion
ados
ao
auxi
lio a
impl
emen
taçã
o P
LM
A
uto
res
Ca
ract
erí
stic
as
(ZA
NC
UL,
20
09
) (U
MB
LE e
t a
l.,
20
03
) (G
RIE
VE
S,
20
06
) (S
AA
KS
VU
OR
I e
t a
l.,
20
08
)
Ab
ord
agem
u
tili
zad
a D
esen
volv
imen
to d
e m
odel
os d
e re
ferê
ncia
, pro
cess
os e
id
entif
icaç
ão d
e bo
as p
rátic
as d
e im
plan
taçã
o de
sis
tem
as E
RP
.
Iden
tific
ação
, em
trab
alho
s an
terio
res
rela
cion
ados
a E
RP
, os
fato
res
de s
uces
so e
um
a co
mpa
tibili
zaçã
o de
sses
tr
abal
hos.
Abo
rda
a im
plan
taçã
o P
LM n
o ní
vel e
stra
tégi
co. D
efin
e vi
são,
av
alia
a s
ituaç
ão a
tual
e p
lane
ja
as m
udan
ças
nece
ssár
ias
a um
a es
trat
égia
PLM
.
Est
rutu
ra a
impl
anta
ção
PLM
co
m b
oas
prát
icas
de
gere
ncia
men
to d
e pr
ojet
o.
Con
side
ra s
iste
ma
PLM
com
o um
a fe
rram
enta
par
a au
xílio
aos
pr
oces
sos.
Ên
fase
da
pro
po
sta
Sel
eção
de
sist
emas
PLM
em
fu
nção
da
ader
ênci
a do
s pr
oces
sos
exis
tent
es a
um
m
odel
o de
ref
erên
cia
dese
nvol
vido
.
Boa
s pr
átic
as e
xist
ente
s e
os
caso
s de
suc
esso
. D
efin
ição
da
estr
atég
ia d
e ne
góci
os r
elac
iona
da a
im
plem
enta
ção
de s
iste
mas
P
LM.
Ger
enci
amen
to d
as m
udan
ças
orga
niza
cion
ais
e ge
renc
iam
ento
de
proj
etos
(p
roje
to d
e im
plan
taçã
o P
LM).
Uso
de
ind
icad
ore
s p
ara
aval
iar
a im
pla
nta
ção
Não
abo
rda.
N
ão a
bord
a.
Indi
ca R
OI e
RO
A c
omo
indi
cado
res
de d
esem
penh
o,
cont
udo
não
mos
tra
com
o ob
ter
esse
s in
dica
dore
s.
Indi
cado
res
são
abor
dado
s de
fo
rma
impl
ícita
(in
dica
dore
s de
pr
ojet
o): p
razo
s, o
rçam
ento
, etc
.
79
Qua
dro
3-1:
Con
tinua
ção
:
A
uto
res
Ca
ract
erí
stic
as
Za
ncu
l (2
00
9)
Um
ble
et
al,
20
02
G
rie
ve
s (2
00
6)
Sa
ak
svu
ori
et
al
(20
08
)
Sta
ke
ho
lde
rs
Não
usa
o c
once
ito d
e st
akeh
olde
rs. A
bord
a os
us
uário
s do
sis
tem
a (s
oftw
are
para
PLM
) co
mo
um ti
po d
e st
akeh
olde
r do
sis
tem
a P
LM.
Não
usa
o c
once
ito d
e st
akeh
olde
rs. D
ecla
ra s
omen
te
os u
suár
ios
do s
iste
ma
que
são
um ti
po d
e st
akeh
olde
r do
si
stem
a P
LM.
Não
usa
o c
once
ito d
e st
akeh
olde
rs. I
dent
ifica
os
usuá
rios
do s
iste
ma
PLM
e
mem
bros
da
dire
toria
da
empr
esa
Não
usa
o c
once
ito d
e st
akeh
olde
rs. L
ista
som
ente
us
uário
s do
sis
tem
a P
LM.
Dim
ensõ
es
anal
isad
as
Pro
cess
os d
e ne
góci
o e
func
iona
lidad
es P
LM
Som
ente
apl
icat
ivos
de
softw
are
e us
uário
s P
roce
ssos
de
negó
cios
, fu
ncio
nalid
ades
PLM
e p
esso
as.
Pro
cess
os d
e ne
góci
o.
An
ális
e d
e s
ta
ke
ho
lde
rs
do
p
roce
sso
e d
e su
as
nec
essi
dad
es
Não
usa
N
ão u
sa.
Não
usa
. N
ão u
sa.
Tip
os
de
mo
del
agem
usa
da
na
pro
po
sta
Nen
hu
ma
Nen
hu
ma.
N
enh
um
a.
Nen
hu
ma.
Uso
de
no
taçõ
es
esp
ecíf
icas
de
mo
del
agem
Nen
hu
ma
N
enh
um
a.
Nen
hu
ma.
N
enh
um
a.
80
3.2 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.
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.
1 2 3
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
Definição das necessidades do negócio
Comparar soluções da lista Listar soluções PLM
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
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.
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
Sistema PLM
Stakeholders Infraestrutua
PLM
Processos
Interesses
Requisitos
Suporte
83
componentes à estrutura PLM apresentada e busca-se identificar uma abordagem sistemática
para desenvolver os relacionamentos dentro da nova estrutura PLM proposta.
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 2221.
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:
Infraestrutura PLM
Software PLM
Hardware
Processos
Usuários
Sistema PLM
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.
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
Domínio do problema Domínio de solução
Processos
Stakeholders
Método Necessidades
Relacionadas
aos
dos
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.
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).
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 4-5.
4.1 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
Auxiliar implantação de Sistemas PLM
Informações sobre processo
Necessidades do negócio
Requisitos para o sistema PLM
Indicadores de desempenho
Mapear e Modelar Processos
Analisar Stakeholders
Determinar requisitos
Definir indicadores de desempenho
Map
a d
e p
roce
sso
Mapa de processo
Necessidades dos stakeholders
Aná
lise
de
sta
keh
old
ers
Informações sobre o processo
Necessidades do negócio
Requisitos
Indicadores de desempenho
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
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
Sumário: Mapeamento e modelagem de processos
Entrada:Entrada:Entrada:Entrada:
Entrevistas, questionários, reuniões,
workshops, observação de campo, análise da
documentação existente, análise de sistemas
legados, coleta de evidências.
Saída:Saída:Saída:Saída:
Mapa e Modelo dos processos. Motivação/Descrição Por quPor quPor quPor queeee? ? ? ?
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?O que?O que?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?Como?Como?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?Onde?Onde?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: Ferramentas: Ferramentas: Ferramentas:
Mapeamento e modelagem de processos, Enterprise ArchitectTM
Modelar processos
Modelos de processo
Informações sobre
os processos
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 Interesse no processo
Qual é o papel do
stakeholder no processo?
Riscos percebidos Impacto potencial
no processo
Projetistas Melhor controle dos dados do produto
Realizar mudanças no projeto CAD atual
Não se envolver na iniciativa de implantação do sistema, pois não partilham da necessidade de melhor acesso à informação.
alto
Gerentes Eficiência na manipulação dos dados
Supervisionar as atividades
durante a modificação
O gerente da área não tem liderança sob restante do grupo
alto
Engenheiros Os requisitos do produto devem ser respeitados
Aprovar tecnicamente
as modificações
Os engenheiros estão sobrecarregados no preenchimento de relatórios e podem não querer participar
alto
Fornecedores Fornecer insumos para o novo produto modificado
Conhecimento rápido sobre o
que mudou
Descumprimento dos prazos acordados inicialmente
baixo
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
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
Sumário: Análise de Stakeholders do processo
Entrada:Entrada:Entrada:Entrada:
Processo na forma de modelos, informações
coletadas no ambiente do processo e outras
informações relacionadas aos processos
analisados (Ex. Lista preliminar de
stakeholders).
Saída:Saída:Saída:Saída:
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 quPor quPor quPor queeee? ? ? ?
É fundamental atender adequadamente as necessidades dos stakeholders para o sucesso de
qualquer solução proposta para melhoria de processos. O que?O que?O que?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?Como?Como?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?Onde?Onde?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: Ferramentas: Ferramentas: Ferramentas:
Análise de stakeholders
Analisar stakeholders
Processo
Stakeholders
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.
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.
act [Activ ity] Indicadores [Indicadores]
Entradas
(from Method)
1. Identificar v alor para o cliente
(from Method)
2. Identificar sub-processo gerador de
valor
(from Method)
Saida
(from Method)
3. Identificar aspectos que geram v alor
(from Method)
4. Identificar caracterisiticas desses
aspectos
(from Method)
5. Identificar forma de medição
(from Method)
1. O que os stakeholders vêem como valor?
2. Para cada valor acima, qual é o sub-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
6. Definir Base Line/Meta/Prazo
(from Method)
StakeholdersDescrição do processo
Indicadores e seus atributos
90
Quadro 4-4: Definir Indicadores de Desempenho
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?
Sumário: Definição de indicadores
Entrada:Entrada:Entrada:Entrada:
Necessidades dos stakeholders , em especial os
clientes do processo e informações do
processo.
Saída:Saída:Saída:Saída:
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 quPor quPor quPor queeee? ? ? ?
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?O que?O que?O que?
Definir indicadores de desempenho que caracterizam o atendimento das necessidades dos
stakeholders em qualquer momento do ciclo do sistema PLM.
Como?Como?Como?Como?
Definindo indicadores de desempenho que incorporem geração de valor para os
stakeholders do processo
Onde?Onde?Onde?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: Ferramentas: Ferramentas: Ferramentas: Método PERISCOPE modificado com novos atributos: Baseline, meta e prazo
Definir indicadores de desempenho
Indicadores de desempenho
Análise de stakeholders
Modelos de
processo
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
são analisados e pode-se obter os requisitos funcionais do sistema usados para orientar o
processo de implementação de Sistemas PLM.
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.
Analisar e modelar funcional
Derivar Requisitos
Resultados da Análise
Requisitos
Processos BPMN
Necessidades dos
stakeholders
Stakeholders
Modelos SysML
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
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;
bdd [SysML Block Definition] v iew [v iew]
«System»Sistema
Actor1
Actor2
Actor3
«actor»outro sistema
«flow»
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
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.
Sumário: Determinação de requisitos
Entrada:Entrada:Entrada:Entrada:
Análise de stakeholders e todas as informações
usadas nessa análise
Saída:Saída:Saída:Saída:
Requisitos e consequente detalhamento das
necessidades dos stakeholders e definição de
funções do sistema.
Motivação/Descrição Por quPor quPor quPor queeee? ? ? ?
Os requisitos são a base para o desenvolvimento de sistema. Eles determinam o que o
sistema vai oferecer. O que?O que?O que?O que?
Os requisitos são obtidos a partir das necessidades dos stakeholders e documentados numa
estrutura de requisitos.
Como?Como?Como?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?Onde?Onde?Onde?
O desenvolvimento de requisitos dos stakeholders é um passo intermediário para a
obtenção de requisitos do sistema. Ferramentas: Ferramentas: Ferramentas: Ferramentas:
Diagramas SysML
Entrevistas usando roteiros pré-estabelecidos (Anexo A2)
Determinar requisitos
Analise de stakeholders
Requisitos de stakeholders
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(4.3 -4.6) apresentam a aplicação do
método propriamente dita.
97
5.1 FERRAMENTA COMPUTACIONAL UTILIZADA
O software Enterprise ArchitectTM (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, formou-
se 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
Quadro 5-1: Ferramentas PLM (CAD/CAM/CAE) utilizados no DPI
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 ExplorerTM encapsulado no sistema operacional WindowsTM. 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.
Ferramentas requeridas Ferramentas utilizadas CAD RHINOCEROS™, SOLIDWORKS™ e AUTOCAD™ CAM SurfCAM™ CAE COSMOS™, FEMAP™ e NASTRAN™ PDM WINDOWS EXPLORER™
99
5.3 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
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.
10
1
Fig
ura
5-1
: Pro
cess
o de
des
envo
lvim
ento
de
prod
uto
s
BP
MN
Des
env
olv
ime
nto
de p
rodu
tos
«Lane» Administração«Lane» NPFR«Lane» NDES
«Pool» DPI
Pe
did
oA
be
rto
SG
PS
«B
usin
ess
Pro
cess
»P
roje
tar
prod
uto
«B
usin
ess
Pro
cess
»P
roje
tar
prod
uto
«Bus
ines
sPro
cess
»D
ese
nvol
vim
ento
de
P
ré-P
roje
to d
o M
olde
«Bus
ines
sPro
cess
»D
ese
nvol
vim
ento
de
P
ré-P
roje
to d
o M
olde
Ap
rova
ção
in
tern
a
Pré
-Pro
jeto
a
pro
vad
o?
«Bus
ines
sPro
cess
»P
roje
tar
Mol
de«B
usin
essP
roce
ss»
Pro
jeta
r M
olde
Mo
de
los
e
esp
eci
fica
çõe
s d
o
pro
du
to
Lis
ta d
e
ma
teri
ais
IL
ista
de
m
ate
ria
is I
I
Fe
cha
me
nto
d
o m
old
e
de
fin
ido
«Bus
ines
sPro
cess
»A
quis
içã
o de
pro
duto
s e
serv
iços
«Bus
ines
sPro
cess
»A
quis
içã
o de
pro
duto
s e
serv
iços
«Bus
ines
sPro
cess
»P
lane
jar
e co
ntro
lar
a
ma
nufa
tura
«Bus
ines
sPro
cess
»P
lane
jar
e co
ntro
lar
a
ma
nufa
tura
Lis
ta d
e
serv
iço
s
«B
usin
ess
Pro
cess
»M
anu
fatu
rar
Mol
de«
Bus
ine
ssP
roce
ss»
Ma
nufa
tura
r M
olde
Pro
du
tos
ese
rviç
os
Try
ou
t d
o m
old
e
An
ali
sar
pro
ble
ma
So
luçã
o
de
fin
ida
En
tre
ga
pro
ble
ma
id
en
tifi
cad
o
sim
nã
o
«In
form
açã
o»
«In
fom
açã
o»
«In
form
açã
o»
«In
form
açã
o»
BP
MN
Pro
cess
os
«B
usin
essP
roce
ss»
Bus
ines
sPro
cess
«B
usin
essP
roce
ss»
Bus
ines
sPro
cess
Eve
nto
Da
do
s g
era
do
s
O s
imb
olo
no
ca
nto
in
feri
or
dir
eit
o i
nd
ica
qu
e
exi
ste
m s
ub
pro
cess
o o
u t
are
fas
rela
cio
na
do
s a
o p
roce
sso
.
O s
imb
olo
in
dic
a q
ue
um
de
term
ina
do
eve
nto
inic
ia u
ma
ou
tra
eta
pa
do
pro
cess
o.
O s
imb
olo
in
dic
a q
ue
in
form
açã
o/e
ne
rgia
/ma
teri
al
são
ge
rad
os
na
a
tivi
da
de
(sa
ída
) e
sã
o u
tili
zad
os
em
ou
tra
s a
tivi
da
de
s(e
ntr
ad
a).
As
seta
s in
dic
am
o f
luxo
.
10
2
Fig
ura
5-2
: Pro
cess
o de
Pro
jeta
r do
pro
duto
BP
MN
Pro
jeta
r pr
odut
o
«B
usin
ess
Pro
cess
»D
ese
nvol
ve
r co
nce
ito«
Bus
ine
ssP
roce
ss»
De
senv
olv
er
conc
eito
Ap
rova
ção
in
tern
aA
pro
vaçã
oe
xte
rna
(cli
en
te)
Co
nce
ito
a
pro
vad
o?
Ofe
rta
ace
ita
«B
usin
ess
Pro
cess
»D
ese
nvol
ve
r pr
oje
to d
e
Eng
enh
aria
«B
usin
ess
Pro
cess
»D
ese
nvol
ve
r pr
oje
to d
e
Eng
enh
aria
Ap
rova
ção
in
tern
a
Pro
jeto
a
pro
vad
o?
Ap
rova
ção
ext
ern
a(C
lie
nte
)
Pro
jeto
ap
rova
do
?
lin
k p
ara
pro
jeta
r m
old
e
sim
nã
o
sim
nã
o
nã
o
sim
sim
10
3
Fig
ura
5-3
: Pro
cess
o de
pro
jeta
r m
olde
BP
MN
Pro
jeta
r M
olde
Inic
io
De
fin
ir P
lan
o d
efe
cha
me
nto
Pro
jeta
r re
frig
era
ção
Pro
jeta
r m
eca
nis
mo
de
ext
raçã
o
Ve
rifi
car
inte
rfe
ren
cia
na
mo
nta
ge
m d
om
old
e
Ge
rar
info
rma
çõe
sn
ece
ssa
ria
s p
ara
Try
ou
t
Ge
rar
RD
fim
Ela
bo
rar
lis
ta d
em
ate
ria
is
Ge
om
etr
ia d
e
fech
am
en
to
De
talh
ar
pro
jeto
do
mo
lde
Ap
rova
ção
in
tern
a
Pro
jeto
Ap
rova
do
Re
visa
r p
roje
to
nã
o
sim
RD
-Reg
istr
o d
e D
esen
ho
10
4
Fig
ura
5-4
: Pro
cess
o de
pla
neja
men
to d
a m
anu
fatu
ra
BP
MN
Pla
neja
r e
cont
rola
r a
man
ufa
tura
Re
ali
zar
reu
niã
oin
icia
l d
ep
lan
eja
me
nto
Sta
rtE
ven
t3
Pla
ne
jam
en
to 2
D
Pla
ne
jam
en
to 3
D
Pla
ne
jam
en
to d
ee
xecu
ção
Ap
rova
ção
in
tern
a
Pla
ne
jam
en
to
ap
rova
do
?
fim
nã
o
sim
10
5
Fig
ura
5-5
: Pro
cess
o de
pla
neja
men
to u
sina
gem
2D
Fig
ura
5-6
: Pro
cess
o de
pla
neja
men
to u
sina
gem
3D
BP
MN
Pla
neja
me
nto
2D
inic
io
De
fin
ir e
stra
tég
ia d
em
an
ufa
tura
de
ca
da
ite
m
Est
ima
r te
mp
o d
eca
da
ite
m
fim
BP
MN
Pla
neja
men
to 3
D
inic
io
De
fin
ir p
rog
ram
açã
oC
NC
De
fin
ir e
mo
lde
lar
ele
tro
do
sE
lab
ora
r fo
lha
s d
ese
tup
do
s e
letr
od
os
De
fin
ir p
on
to d
eco
ntr
ole
Est
ima
r te
mp
o d
em
an
ufa
tura
fim
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 5.4.
5.4 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
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.
Processo
Entradas, Saídas,
Controles e Mecanismos.
Stakeholders
Interesse no processo Papel no processo Riscos percebidos Impacto
Detalhar
Desdobrar
Analisar/Detalhar
108
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.
5.4.1 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
Ciclo de Vida do Produto
Investimentos
Produtos/serviços
Software
Pedidos
Requisitos
Restrições de mercado
Máquinas e equipamento
Pessoas
Faturamento
Padrões gerenciais
Reputação
Temas para pesquisa tecnológica
Normas ABNT
Insumos
Desperdícios e Desperdícios
Investidores Diretoria
Clientes
Gerente DPI Designers
Engenheiro produto
Concorrentes Governo ABNT Fornecedores Engenheiro MFG
109
de engenharia devem ser implementadas para atender as necessidades dos clientes da
empresa.
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 ExcelTM. 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,
Diretoria Clientes Gerente DPI
Designers Engenheiro produto
Projetar Produto
Projeto de produtos
Software
Necessidade
Restrições
Hardware
Designers e Engenheiros
Padrões gerenciais.
Normas ABNT.
Desperdícios
Serviços
Engenheiro MFG Fornecedores
INMETRO
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.
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
Data: Alteração: Solicitada por: Executada por:
Status Observações
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
Cliente Designer EA Geometria modificada (de elíptica para 2 condutos cônicos)
11/03/10 Reforçar castelos posteriores para receber PCI (Placa de Circuito Impresso)
Cliente Designer P
11/03/10 Acrescentar novo castelo p PCI (Placa de Circuito Impresso) deixando-o 10 mm da borda anterior
Cliente Designer EA
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)
Cliente Designer P Modificação definida em reunião no dia 28-10-2010 em SSA
21/01/10 Modificar protetor da bateria - inserir ângulo de saída (0,5 graus) em duas nervuras.
Engenheiro de Manufatura
Engenheiro Produto
EA Modificação realizada, pois nervura impossibilitava a extração da peça do molde.
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).
5.4.2 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
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$200.000,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 e-mail ou em
Projetar molde
Software
Requisitos
Especificações
Hardware
Engenheiros, Técnicos
Padrões gerenciais
Normas ABNT
Projeto do produto Projeto de Molde
Desperdícios
Diretoria Clientes Gerente DPI
Designers Engenheiro produto Engenheiro MFG Fornecedores
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 5-11. Nessa figura cada pasta da janela A é
relacionada a um único componente do produto. Nelas estão arquivo CAD 3D/2D, e-mails
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.
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.
A B
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.
5.4.3 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
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.
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
Planejar e Controlar Manufatura
Software
Especificações
Restrições
Hardware
Engenheiros e Técnicos
Padrões gerenciais
Normas ABNT
Projeto do molde
Plano de Manufatura Lista de materiais Desperdícios
Diretoria Clientes Gerente DPI
Engenheiro produto Engenheiro
Manufatura Fornecedores
Departamento de compras
Operador. de máquinas
Técnico de Processos
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.
11
7
Qua
dro
5-3:
An
ális
e de
st
ake
ho
lders i
dent
ifica
dos
nos
proc
esso
s an
alis
ados
Sta
keho
lder
In
tere
sse
no
s p
roce
sso
s P
apel
do
sta
keho
lder
no
pro
cess
o
Ris
cos
per
ceb
ido
s Im
pac
to
O p
roje
to d
eve
ser
real
izad
o co
nfor
me
sua
nece
ssid
ade
no c
usto
, pra
zo e
qu
alid
ade
plan
ejad
os;
As
rest
riçõe
s de
vem
ser
obs
erva
das
de m
odo
a te
r im
pact
o re
duzi
do n
o pr
ojet
o;
O p
roje
to d
eve
resp
eita
r no
rmas
e
regu
lam
enta
ções
est
abel
ecid
as n
o pa
ís;
Aco
mpa
nhar
de
pert
o o
proj
eto.
For
nece
r in
form
açõe
s de
ent
rada
par
a o
dese
nvol
vim
ento
;
Usu
frui
r be
nefíc
ios
ofer
ecid
os p
elos
ser
viço
s of
erta
dos;
Ava
liar
solu
çõe
s pr
opos
tas
no d
ese
nvol
vim
ento
de
prod
utos
.
O tr
abal
ho d
e de
finiç
ão d
os r
equi
sito
s é
uma
tare
fa
que
não
é co
ntem
plad
a sa
tisfa
tori
amen
te. O
pro
jeto
in
icia
-se
sem
alg
umas
def
iniç
ões
bási
cas
com
o fu
ncio
nalid
ades
;
Os
clie
ntes
pro
cura
m in
serir
func
iona
lidad
es n
a et
apa
de p
roje
to d
etal
hado
de
enge
nhar
ia fa
zend
o co
m q
ue a
s ár
eas
de D
esig
n e
Eng
enha
ria r
ealiz
em
retr
abal
hos
para
ate
nder
ess
a so
licita
ção.
Alto
.
Os
desi
gner
s bu
scam
har
mon
izar
os
dive
rsos
el
emen
tos
pres
ente
s no
pro
jeto
form
a, c
or, t
extu
ra,
func
iona
lidad
e pa
ra a
umen
tar
a pe
rcep
ção
de v
alor
do
s co
nsum
idor
es;
Os
requ
isito
s do
pro
duto
dev
em s
er r
espe
itado
s du
rant
e to
do o
des
envo
lvim
ento
.
Ela
bora
r br
iefin
g co
m o
s cl
ient
es;
Des
envo
lver
as
prop
osta
s co
nce
ituai
s e
apre
sent
á-la
s ao
s cl
ient
es;
Apr
ovar
tecn
icam
ente
as
mod
ifica
ções
req
uisi
tada
s po
r to
dos
os p
artic
ipan
tes
do p
roje
to.
Os
desi
gner
s sã
o im
pedi
dos
de r
ealiz
ar s
ua fu
nção
de
vido
às
pres
sões
exi
sten
tes
por
praz
os e
cus
tos.
Is
so p
reju
dica
a q
ualid
ade
dos
prod
utos
de
senv
olvi
dos
– em
term
os d
a pr
opos
ição
de
valo
r pa
ra o
clie
nte.
A e
tapa
de
desi
gn é
qua
se q
ue
omiti
da o
u ex
ecut
ada
de m
anei
ra b
asta
nte
sim
plór
ia e
res
ume-
se a
ger
ação
das
form
as
esté
ticas
ext
erna
s;
Os
Des
igne
rs e
stão
sob
reca
rreg
ado
s no
pr
eenc
him
ento
de
rela
tório
s e
pode
m n
ão q
uere
r pa
rtic
ipar
de
uma
inic
iativ
a P
LM;
Os
Des
igne
rs e
stão
sob
reca
rreg
ado
s no
de
senv
olvi
men
to d
e to
do o
pro
jeto
do
conc
eito
a
enge
nhar
ia n
eces
sária
par
a im
plem
enta
r fu
ncio
nalid
ades
com
o fe
cham
ento
do
prod
uto
etc.
Alto
.
Clie
ntes
Des
igne
rs
11
8
Con
tinua
ção
– Q
uadr
o 5
– 3:
Aná
lise
de
sta
keh
old
ers i
dent
ifica
dos
nos
pro
cess
os a
nalis
ados
Sta
keho
lder
In
tere
sse
no
s p
roce
sso
s P
apel
do
sta
keho
lder
no
pro
cess
o
Ris
cos
per
ceb
ido
s Im
pac
to
Col
etar
cor
reta
men
te o
s re
quis
itos
do c
lient
e;
Usa
r os
req
uisi
tos
de u
ma
form
a au
tom
átic
a;
Aum
enta
r a
efic
iênc
ia n
o ac
ess
o à
info
rmaç
ão;
Aut
omat
izar
tare
fas
repe
titiv
as;
Mel
hora
r o
cont
role
dos
dad
os d
o pr
odut
o;
Mel
hora
r a
man
ufat
urab
ilida
de d
os p
rodu
tos;
Red
uzir
retr
abal
hos;
Men
sura
r re
trab
alho
s no
s pr
oces
sos;
Dim
inui
r er
ros
de p
roje
to;
Gar
antir
que
toda
s as
eta
pas
seja
m r
ealiz
adas
;
Est
abel
ecer
um
a se
quên
cia
lógi
ca d
e tr
abal
ho q
ue
gara
nta
no fi
nal o
mel
hor
resu
ltado
.
Exe
cuta
r pr
ojet
o C
AD
;
Des
envo
lver
sol
uçõe
s té
cnic
as p
ara
aten
der
os
requ
isito
s;
Pro
jeta
r pr
odut
o se
guin
do e
spec
ifica
ções
do
clie
nte.
Atu
alm
ente
que
m d
esem
penh
a es
se p
apel
sã
o os
des
igne
rs.
Os
desi
gner
s as
sum
iram
, alé
m d
o pa
pel d
e de
sign
, o
de p
roje
tar
o pr
odut
o em
sua
tota
lidad
e;
Dem
ora
do c
lient
e em
inse
rir in
form
açõe
s no
pr
oces
so e
res
pond
er q
uand
o so
licita
do (
no m
ínim
o 3
dias
);
Alg
uns
enge
nhei
ros
não
ente
nde
m a
nec
essi
dade
de
mel
hor
aces
so a
info
rmaç
ão c
omo
uma
poss
ível
so
luçã
o pa
ra d
efic
iênc
ias
dos
proc
esso
s.
Alto
.
Efic
iênc
ia n
a m
anip
ulaç
ão d
os d
ado
s;
Efic
iênc
ia n
o de
senv
olvi
men
to d
e p
roje
tos
Aum
ento
da
efic
iênc
ia a
o pr
ojet
ar m
olde
s e
red
uzir
retr
abal
hos;
Aum
ento
da
rece
ita d
o de
part
amen
to p
roje
tand
o m
ais
mol
des;
Efic
iênc
ia n
a m
anip
ulaç
ão d
os d
ado
s;
Efic
iênc
ia n
o de
senv
olvi
men
to d
e p
roje
tos.
Sup
ervi
sion
ar a
s at
ivid
ades
;
Aco
mpa
nhar
a e
xecu
ção
do p
roje
to;
Dec
idir
ques
tões
impo
rtan
tes
do p
roje
to (
gate
s de
pr
ojet
o);
Sup
ervi
sion
ar a
s at
ivid
ades
dur
ant
e a
mod
ifica
ção.
Ger
ente
não
é p
rope
nso
a m
udan
ças;
Ser
á di
fícil
mud
ar a
vis
ão d
o ge
rent
e em
rel
ação
a
solu
ções
ad
hoc
de p
robl
emas
qu
e se
rep
etem
se
mpr
e.
Alto
.
Eng
enhe
iro d
e
Pro
duto
Ger
ente
DP
I
11
9
Con
tinua
ção
– Q
uadr
o 5
– 3:
Aná
lise
de
sta
keh
old
ers i
dent
ifica
dos
nos
pro
cess
os a
nalis
ados
Sta
keho
lder
In
tere
sse
no
s p
roce
sso
s P
apel
do
sta
keho
lder
no
pro
cess
o
Ris
cos
per
ceb
ido
s Im
pac
to
Efic
iênc
ia n
o de
senv
olvi
men
to d
e p
roje
tos;
Aum
ento
de
fatu
ram
ento
por
pro
jeto
;
Aum
ento
do
fatu
ram
ento
com
a m
esm
a es
trut
ura
exis
tent
e;
Mel
hora
ria d
os in
dica
dore
s de
de
sem
penh
o.
Sup
ervi
sion
ar o
ger
ente
do
DP
I aco
mpa
nhan
do a
s m
etas
fina
ncei
ra e
físi
ca d
os p
roje
tos
e re
pres
enta
r os
inte
ress
es d
o S
EN
AI e
FIE
B.
A d
ireto
ria n
ão fo
rnec
e re
com
enda
ções
ou
se
envo
lve
dire
tam
ente
em
que
stõe
s co
mo
impl
emen
taçõ
es d
esse
tipo
.
Alto
.
For
nece
r so
ftwar
e, m
ater
iais
e e
quip
amen
tos
para
a
real
izaç
ão d
os p
roce
ssos
;
Tom
ar c
onhe
cim
ento
ráp
ido
sobr
e m
udan
ças
ocor
ridas
.
Ofe
rece
r pr
odut
os e
ser
viço
s pa
ra a
rea
lizaç
ão d
os
proc
esso
s;
For
nece
r in
sum
os p
ara
o no
vo p
rodu
to m
odifi
cado
.
O p
roje
to p
ode
atra
sar
se a
lgun
s fo
rnec
edor
es
atra
sam
o fo
rnec
imen
to d
e in
sum
os;
Atr
asos
na
entr
ega
de s
oftw
are,
mat
eria
is e
eq
uipa
men
tos.
Méd
io.
O
gov
erno
pre
scre
ve p
roce
dim
ento
s le
gais
à
empr
esa,
tais
com
o a
lei d
e lic
itaçõ
es 8
666.
F
isca
lizar
o a
tend
imen
to d
essa
s le
is c
om a
udito
rias
e co
nsul
tas
freq
uent
es.
Mud
ança
s na
s le
is im
pact
am fo
rtem
ente
no
dese
mpe
nho
orga
niza
cion
al d
a e
mpr
esa.
A
lto.
R
etor
no n
esse
inve
stim
ento
;
Aum
ento
de
rece
itas
na p
rest
açã
o de
ser
viço
s.
Inve
stim
ento
no
proc
esso
: aqu
isiç
ão d
e re
curs
os e
co
ntra
taçã
o de
pes
soas
. In
vest
idor
es n
ão p
artic
ipam
dire
tam
ente
do
esta
bele
cim
ento
da
estr
atég
ia d
a e
xecu
ção
dos
proc
esso
s. C
om is
so, n
ão e
xist
e fle
xibi
lidad
e pa
ra
esta
bele
cim
ento
de
met
as.
Alto
.
Pre
ocup
ação
com
a li
sta
de c
ompr
as g
erad
a;
Aqu
isiç
ão d
e pr
odut
os e
ser
viço
s co
ndiz
ente
s co
m
as e
xpec
tativ
as d
os c
lient
es in
tern
os e
ext
erno
s.
Rea
lizar
o p
roce
sso
de c
ompr
as r
elac
iona
das
ao
dese
nvol
vim
ento
no
praz
o/cu
sto
plan
ejad
o.
O p
roce
sso
de c
ompr
as n
ão é
ad
equa
do e
mui
tas
veze
s at
rasa
o d
esen
volv
imen
to d
e to
do p
roce
sso;
Com
ess
e ce
nário
é n
eces
sário
mud
ar o
pl
anej
amen
to in
icia
l sem
ava
liaçã
o ad
equa
da d
o no
vo p
lano
.
Alto
.
Dire
toria
For
nece
dore
s
Gov
erno
Inve
stid
ores
Dep
arta
men
to d
e
Com
pras
12
0
Con
tinua
ção
– Q
uadr
o 5
– 3:
Aná
lise
de
sta
keh
old
ers i
dent
ifica
dos
nos
pro
cess
os a
nalis
ados
Sta
keho
lder
In
tere
sse
no
s p
roce
sso
s P
apel
do
sta
keho
lder
no
pro
cess
o
Ris
cos
per
ceb
ido
s Im
pac
to
Ade
quaç
ão s
impl
es d
o pr
ojet
o ao
pro
cess
o;
Rea
lizaç
ão d
o pr
oces
so d
e P
roje
tar
Mol
de a
pós
o pr
oces
so P
roje
tar
Pro
duto
;
Util
izaç
ão d
e in
form
açõe
s do
pré
-pro
jeto
do
mol
de
para
o d
esen
volv
imen
to d
o pr
odut
o;
Apr
ovei
tam
ento
de
solu
ções
já u
sada
s em
pro
jeto
s an
terio
res;
Pad
roni
zaçã
o de
feat
ures
usa
dos
em c
ompo
nent
es
proj
etad
os;
Alin
ham
ento
ent
re p
ré-p
roje
to d
e fe
rram
enta
s e
o pr
ojet
o do
pro
duto
;
Man
ufat
urab
ilida
de d
os p
rodu
tos
proj
etad
os;
Mel
hor
cont
role
dos
dad
os d
o pr
odut
o e
suas
re
visõ
es;
Des
envo
lvim
ento
do
mol
de c
onfo
rme
as
nece
ssid
ades
do
clie
nte
(cus
to, p
razo
, qua
lidad
e pl
anej
ado)
.
Os
requ
isito
s do
pro
duto
rel
acio
nad
os a
o pr
oces
so
prod
utiv
o de
vem
ser
esc
ritos
cor
reta
men
te p
ara
não
gera
r pr
oble
mas
ou
dúvi
das
na e
xecu
ção
das
tare
fas
subs
eque
ntes
;
Mel
horia
do
cont
role
dos
dad
os d
o pr
odut
o;
Mel
hora
ria d
a m
anuf
atur
abili
dade
do
prod
uto.
Rec
eber
os
dado
s do
pro
duto
par
a co
nfec
cion
ar o
pr
ojet
o do
mol
de;
Pro
jeta
r m
olde
con
form
e as
nec
ess
idad
es e
def
inir
a es
trat
égia
de
man
ufat
ura
do p
rodu
to;
Rea
lizar
mud
ança
s no
pro
jeto
CA
D, c
aso
nece
ssár
io.
O p
roje
tista
é r
esis
tent
e a
mud
ança
s na
form
a de
tr
abal
ho, p
rinci
palm
ente
na
utili
zaçã
o de
nov
as
tecn
olog
ias;
Pro
jetis
ta n
ão e
nten
de a
nec
essi
dade
de
mel
hora
r ac
esso
à in
form
ação
Eng
enhe
iros
não
ente
ndem
a n
ece
ssid
ade
de
mel
hora
r ac
esso
à in
form
ação
Alto
E
ngen
heiro
de.
M
anuf
atur
a
12
1
Con
tinua
ção
– Q
uadr
o 5
– 3:
Aná
lise
de
sta
keh
old
ers i
dent
ifica
dos
nos
pro
cess
os a
nalis
ados
Sta
keho
lder
In
tere
sse
no
s p
roce
sso
s P
apel
do
sta
keho
lder
no
pro
cess
o
Ris
cos
per
ceb
ido
s Im
pac
to
As
rest
riçõe
s de
mer
cado
dev
em s
er o
bser
vada
s pa
ra q
ue o
pro
duto
des
envo
lvid
o te
nha
dife
renc
ial
com
petit
ivo
dian
te a
os s
eus
conc
orre
ntes
.
- -
-
Col
etar
cor
reta
men
te o
s re
quis
itos
do c
lient
e;
Usa
r os
req
uisi
tos
de u
ma
form
a au
tom
átic
a;
Aum
enta
r a
efic
iênc
ia n
o ac
ess
o à
info
rmaç
ão;
Aut
omat
izar
tare
fas
repe
titiv
as;
Mel
hora
r o
cont
role
dos
dad
os d
o pr
odut
o;
Mel
hora
r a
man
ufat
urab
ilida
de d
os p
rodu
tos;
Red
uzir
retr
abal
hos;
Med
ir re
trab
alho
s;
Dim
inui
r er
ros
de p
roje
to;
Gar
antir
que
toda
s as
eta
pas
do p
roce
sso
seja
m
real
izad
as;
Est
abel
ecer
um
a se
quên
cia
lógi
ca d
e tr
abal
ho.
Exe
cuta
r pr
ojet
o C
AD
;
Des
envo
lver
sol
uçõe
s té
cnic
as p
ara
aten
der
os
requ
isito
s;
Pro
jeta
r o
prod
uto
segu
indo
esp
eci
ficaç
ões
do
clie
nte.
Atu
alm
ente
que
m d
esem
penh
a es
se p
apel
sã
o os
des
igne
rs.
Os
desi
gner
s as
sum
iram
at
ribui
ções
al
ém
das
suas
: pro
jeta
r o
prod
uto
em s
ua to
talid
ade;
Dem
ora
do c
lient
e em
inse
rir in
form
açõe
s no
pr
oces
so e
res
pond
er q
uand
o so
licita
do (
em m
édia
um
a se
man
a);
Alg
uns
enge
nhei
ros
não
ente
nde
m a
nec
essi
dade
de
mel
hora
r o
aces
so à
info
rmaç
ão.
Alto
.
Con
corr
ente
s
Pro
jetis
ta C
AD
12
2
Con
tinua
ção
– Q
uadr
o 5
– 3:
Aná
lise
de
sta
keh
old
ers i
dent
ifica
dos
nos
pro
cess
os a
nalis
ados
Sta
ke
ho
lde
r In
tere
sse
no
s p
roce
sso
s P
apel
do
sta
ke
ho
lde
r n
o p
roce
sso
R
isco
s p
erce
bid
os
Imp
acto
A A
BN
T e
INM
ET
RO
são
órg
ãos
que
dese
nvol
vem
e
fisca
lizam
as
norm
as té
cnic
as p
ara
prod
utos
e
serv
iços
no
Bra
sil.
Ex.
NB
R 1
413
6 e
NB
R 1
4373
.
Nor
mat
izar
e fi
scal
izar
os
prod
uto
s e
serv
iços
de
senv
olvi
dos
no D
PI.
Im
posi
ção
de n
ovas
nor
mas
par
a r
egul
amen
taçã
o de
pro
duto
s e
serv
iços
des
envo
lvid
os.
Méd
io
Ace
ssar
info
rmaç
ões
sobr
e o
pro
duto
e p
roce
sso
de m
anuf
atur
a qu
ando
nec
essá
rio.
Ope
rar
equi
pam
ento
s pa
ra e
xecu
tar
os p
roce
ssos
de
man
ufat
ura
plan
ejad
os.
A fa
lta d
e si
ncro
niza
ção
entr
e as
info
rmaç
ões
(con
sum
ida/
gera
da)
pode
ger
ar r
etra
balh
os.
A d
úvid
a so
bre
qual
a in
form
ação
é a
cor
reta
pod
e oc
asio
nar
perd
a de
efic
iênc
ia n
a ex
ecuç
ão d
os
proc
esso
s de
man
ufat
ura.
Alto
Ace
ssar
info
rmaç
ões
sobr
e o
pro
duto
e p
roce
sso
de m
anuf
atur
a qu
ando
nec
essá
rio p
ara
plan
ejar
a
man
ufat
ura
do p
rodu
to/m
olde
Des
envo
lver
o p
lane
jam
ento
dos
pro
cess
os d
e m
anuf
atur
a do
pro
duto
/mol
de d
e in
jeçã
o
A fa
lta d
e si
ncro
niza
ção
entr
e as
info
rmaç
ões
(con
sum
ida/
gera
da)
pode
ger
ar r
etra
balh
os.
A d
úvid
a so
bre
qual
é a
info
rmaç
ão c
orre
ta p
ode
ocas
iona
r pe
rda
de e
ficiê
ncia
na
exec
ução
dos
pr
oces
sos
de m
anuf
atur
a.
Alto
INM
ET
RO
AB
NT
Ope
rado
r de
m
áqui
nas
Téc
nico
de
Pro
cess
os
123
5.5 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
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<.
act [Activ ity] Indicadores [Indicadores]
Entradas
(from Method)
1. Identificar v alor para o cliente
(from Method)
2. Identificar sub-processo gerador de
valor
(from Method)
Saida
(from Method)
3. Identificar aspectos que geram v alor
(from Method)
4. Identificar caracterisiticas desses
aspectos
(from Method)
5. Identificar forma de medição
(from Method)
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
6. Definir Base Line/Meta/Prazo
(from Method)
StakeholdersDescrição do processo
Indicadores e seus atributos
124
Quadro 5-4: Aplicação do método para criação de indicadores
1. O que o cliente vê como VALOR?
V1. Produto de fácil manufatura;
V2. Projeto sem retrabalho; V3. Garantia de rastreabilidade entre atividades; V4. Garantia da qualidade dos produtos desenvolvidos.
2. Para cada VALOR acima, qual é o processo "responsável" pela sua incorporação?
V1: o subprocesso de Desenvolver Desenvolver Desenvolver Desenvolver PPPProjeto rojeto rojeto rojeto de de de de EEEEngenharia (P1)ngenharia (P1)ngenharia (P1)ngenharia (P1); V2 e V3: Os subprocessos de Aprovação Aprovação Aprovação Aprovação
Interna (P2)Interna (P2)Interna (P2)Interna (P2) e Aprovação EAprovação EAprovação EAprovação Externaxternaxternaxterna (P3)(P3)(P3)(P3);;;; V4: Os subprocessos de Desenvolver Desenvolver Desenvolver Desenvolver
conceito (P4)conceito (P4)conceito (P4)conceito (P4) e Desenvolver projeto de Desenvolver projeto de Desenvolver projeto de Desenvolver projeto de engenharia (P1)engenharia (P1)engenharia (P1)engenharia (P1);;;;
3. Qual é o ASPECTO mais relevante para cumprir o item de valor?
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.
4. Porque é que este aspecto é importante? Apontar algumas das suas CARACTERÍSTICAS.
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.
5. Como essas características devem ser avaliadas, a fim de ser um indicador do processo?
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
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.
6. Definir outros atributos: Referência/Meta/Prazo necessários à iniciativa PLM
Para M1.
Referência:Referência:Referência:Referência: Métrica não computada, mas estimada em 1 solução por novo projeto.
Meta:Meta:Meta:Meta: 20 soluções existentes de qualquer nível de complexidade por projeto PrazoPrazoPrazoPrazo: um ano para atingir esse nível de
reutilização Para M2.
Referência:Referência:Referência: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:Meta:Meta: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:Prazo:Prazo:Prazo: 1 ano
Para M3 e M4.
Referência:Referência:Referência:Referência: Métrica não computada, mas estima-se que a aprovação interna pode
demorar até 3 dias (72h). Meta:Meta:Meta:Meta: A meta estipulada para realizar uma
aprovação é 24h.
Prazo:Prazo:Prazo:Prazo: O prazo para o atingimento dessa meta é de 6 meses.
Para M5. Referência:Referência:Referência:Referência: Métrica não calculada, mas
estima-se que custe no mínimo 10% de
cada projeto. Meta:Meta:Meta:Meta: 5% é a meta. Prazo:Prazo:Prazo:Prazo: 1 ano é o prazo para o atingimento
da meta.
126
5.6 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).
Figura 5-14: Processo de determinação de requisitos dos stakeholders.
Analisar e modelar funcional
Derivar Requisitos
Resultados da Análise
Requisitos
Processos BPMN
Necessidades dos
stakeholders
Stakeholders
Modelos SysML
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.
5.6.1 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.
12
8
Fig
ura
5-1
5: D
iagr
ama
de
cont
exto
par
a o
pro
cess
o >
Pro
jeta
r P
rodu
to<
bdd
[Sys
ML
Blo
ck D
efin
ition
] Con
text
dia
gra
m [C
ont
ext
dia
gra
m-P
roje
to d
o pr
odut
o]
«S
yste
m»
Sis
tem
a P
LM
«a
cto
r»C
lient
es
(fro
m S
take
ho
lde
rs)
De
sign
ers
(fro
m S
take
ho
lde
rs)
Eng
enh
eiro
de
m
anu
fatu
ra(f
rom
Sta
keh
old
ers
)
Eng
enh
eiro
de
pr
odut
o(f
rom
Sta
keh
old
ers
)
Ge
rent
e D
PI
(fro
m S
take
ho
lde
rs)
Pro
jetis
ta C
AD
(fro
m S
take
ho
lde
rs)
«a
cto
r»W
EB
«a
cto
r»F
orne
cedo
r P
LM
Info
rma
ção
/A
pro
var/
Re
jeit
ar
«fl
ow
»
Da
do
s d
ep
rod
uto
/Ap
rova
r/R
eje
ita
r«
flo
w»
12
9
Fig
ura
5-1
6: D
iagr
ama
de
cont
exto
par
a o
pro
cess
o d
e >
Pro
jeta
r M
olde
<
bdd
[Sys
ML
Blo
ck D
efin
ition
] Con
text
dia
gra
m [C
ont
ext
dia
gra
m-P
roje
to d
o m
olde
]
«S
yste
m»
Sis
tem
a P
LM
«a
cto
r»C
lient
es
(fro
m S
take
ho
lde
rs)
«a
cto
r»D
epa
rtam
ent
o de
C
ompr
as
(fro
m S
take
ho
lde
rs)
Eng
enh
eiro
de
m
anu
fatu
ra(f
rom
Sta
keh
old
ers
)
Ge
rent
e D
PI
(fro
m S
take
ho
lde
rs)
Eng
enh
eiro
de
pr
odut
o(f
rom
Sta
keh
old
ers
)
Pro
jetis
ta C
AD
(fro
m S
take
ho
lde
rs)
«a
cto
r»F
orne
cedo
res
(fro
m S
take
ho
lde
rs)
«a
cto
r»W
EB
Info
rma
ção
/A
pro
var/
Re
jeit
ar
«fl
ow
»
Da
do
s d
ep
rod
uto
/Ap
rova
r/R
eje
ita
r
«fl
ow
»
13
0
Fig
ura
5-1
7: D
iagr
ama
de
cont
exto
par
a o
pro
cess
o d
e >
Pla
neja
r e
Con
trol
ar
Man
ufat
ura<
bdd
[Sys
ML
Blo
ck D
efin
ition
] Con
text
dia
gra
m [C
ont
ext
dia
gram
-Pla
no d
e m
anuf
atur
a]
«S
yste
m»
Sis
tem
a P
LM
«a
cto
r»E
RP
-WE
Bde
sk
«a
cto
r»W
EB
«a
cto
r»F
orne
cedo
r P
LM
«a
cto
r»D
epa
rtam
ent
o de
C
ompr
as
(fro
m S
take
ho
lde
rs)
Eng
enhe
iro d
e
ma
nufa
tura
(fro
m S
take
ho
lde
rs)
«a
cto
r»F
orne
cedo
res
(fro
m S
take
ho
lde
rs)
Ope
rado
r de
m
áqu
ina
(fro
m S
take
ho
lde
rs)
Técn
ico
de
proc
esso
s(f
rom
Sta
keh
old
ers
)
Ger
ent
e D
PI
(fro
m S
take
ho
lde
rs)
Info
rma
ção
/A
pro
var/
Re
jeit
ar
«fl
ow
»
Co
taçõ
es
«fl
ow
»
Da
do
s d
e c
om
pra
s
«fl
ow
»
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 5-19. 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
Figura 5-18: Diagrama de contexto para o processo >Projetar Produto< acrescido do fluxo de informação
ibd [SysML Internal Block] Context diagram [Projet o de produto]
«flowPort»Acesso Web
«flowPort»Acesso paramanutenção
«flowPort»Aprovar/Rejeitar
«flowPort»CAx port
«flowPort»Visualização
«System»:Sistema PLM
«flowPort»Acesso Web
«flowPort»Acesso paramanutenção
«flowPort»Aprovar/Rejeitar
«flowPort»CAx port
«flowPort»Visualização
:Clientes
:Fornecedor PLM
:Projetista CAD
:Designers
:Engenheiro de manufatura
:Engenheiro de produto
:Gerente DPI
:WEB
Dados doproduto
«flow»Dados CAD/Dados do molde
«flow»
produtos eserviços
«flow»
Aprovar/ Rejeitar/Dados de produto/Requisitos
«flow»
Dados de produto /Aprovar/Rejeitar
«flow»
Dados de produto/Aprovar/Rejeitar
«flow»
Dados deproduto
«flow»
Aprovar/Rejeitar
«flow»
Dados doproduto
«flow»
Informaçõesde design
«flow»
D
133
Figura 5-19: Diagrama de contexto para o processo >projetar molde< acrescido do fluxo de informação
ibd [SysML Internal Block] Context diagram [Projet o do molde]
«flowPort»Acesso Web
«flowPort»Acesso paramanutenção
«flowPort»Aprovar/Rejeitar
«flowPort»CAx port
«flowPort»ERP Port «flowPort»
Visualização
«System»:Sistema PLM
«flowPort»Acesso Web
«flowPort»Acesso paramanutenção
«flowPort»Aprovar/Rejeitar
«flowPort»CAx port
«flowPort»ERP Port «flowPort»
Visualização
:ERP-WEBdesk
:Projetista CAD:Fornecedor PLM
:Fornecedores
:Engenheiro de manufatura
:Gerente DPI
:WEB
Especificações decomponentes
«flow»
produtose serviços
«flow» Dados CAD/Dados domolde
«flow»
Dados dascompras
«flow»Dados dosmoldes
«flow»
Dados do molde/Aprovar/ Rejeitar
«flow»
Aprovar/Rejeitar
«flow»
Dados dosmoldes
«flow»
Dados produto/Dados do molde
«flow»
134
Figura 5-20: Diagrama de contexto para o processo >Planejar e controlar manufatura< acrescido do fluxo de informação
ibd [SysML Internal Block] Context diagram [Plano de manufatura]
«flowPort»Visualização
«flowPort»AcessoWeb
«flowPort»Acesso paramanutenção
«flowPort»Aprovar/Rejeitar
«flowPort»CAx port
«flowPort»ERP Port
«System»:Sistema PLM
«flowPort»Visualização
«flowPort»AcessoWeb
«flowPort»Acesso paramanutenção
«flowPort»Aprovar/Rejeitar
«flowPort»CAx port
«flowPort»ERP Port
:ERP-WEBdesk
:WEB
:Fornecedor PLM
:Departamento de Compras
:Fornecedores
:Engenheiro de manufatura :Operador de
máquina
:Técnico de processos
:Gerente DPI
Dados dascompras
«flow»
Dados do processomanufatura/Aprovar/Rejeitar
«flow»
Aprovar/Rejeitar«flow»
Dados deprocessosmanufatura
«flow»
Dados deplanejamentoda produção
«flow»
Folha deprocesso
«flow»
Dados dePlanejamento daprodução
«flow»
Dadosmanufatura
«flow»
Dados dascompras
«flow»
produtos eserviços
«flow»
Dados processomanufatura
«flow»
Dados dascompras
«flow»
E
135
5.6.2 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 5-21. 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.
13
6
Fig
ura
5-2
1: D
iagr
ama
de
Cas
os d
e us
o
uc [U
se C
ase
] Use
ca
ses
[Use
ca
se m
ode
l]
Sis
tem
a P
LM
«a
cto
r»C
lient
es
(fro
m S
take
ho
lde
rs)
«a
cto
r»D
epa
rtam
ent
o de
C
ompr
as
(fro
m S
take
ho
lde
rs)
De
sign
ers
(fro
m S
take
ho
lde
rs)
Eng
enh
eiro
de
m
anu
fatu
ra(f
rom
Sta
keh
old
ers
)
Eng
enh
eiro
de
pr
odut
o(f
rom
Sta
keh
old
ers
)
«a
cto
r»F
orne
cedo
res
(fro
m S
take
ho
lde
rs)
Ge
rent
e D
PI
(fro
m S
take
ho
lde
rs)
Pro
jetis
ta C
AD
(fro
m S
take
ho
lde
rs)
«a
cto
r»E
RP
-WE
Bde
sk
(fro
m C
on
text
dia
gra
m)
«ac
tor»
WE
B
(fro
m C
on
text
dia
gra
m)
Ope
rado
r de
m
áqu
ina
(fro
m S
take
ho
lde
rs)
Vis
ualiz
ar
dado
s do
C
iclo
de
Vid
a do
P
rodu
to
Vis
ualiz
ar
dado
s do
C
VP
via
WE
B
Apr
ova
r e
Re
jeita
r
Apr
ova
r e
Re
jeita
r v
ia w
eb
Ge
renc
iar
requ
isito
s
Cria
r da
dos
do
prod
uto
Ler
dado
s do
pro
duto
Cri
a d
ado
s de
m
anu
fatu
ra
Ler
dado
s de
m
anu
fatu
ra
Ler
esp
eci
fica
çõe
s v
ia W
EB
Troc
ar
dado
s co
m
sist
em
a E
RP
Ge
renc
iar
dado
s do
C
iclo
de
Vid
a d
o P
rodu
to
Ler
dado
s C
iclo
de
V
ida
do
Pro
duto
Cria
r da
dos
Cic
lo d
e
Vid
a d
o P
rodu
to
«a
cto
r»F
orne
cedo
r P
LM
(fro
m C
on
text
dia
gra
m)
Re
aliz
ar
supo
rte a
o si
stem
a
Re
aliz
ar
inte
rve
nçã
o té
cnic
a v
ia w
eb
Re
aliz
ar
trein
am
ent
os
via
we
b
Info
rma
ção
/A
pro
var/
Re
jeit
ar
«fl
ow
»
Da
do
s d
ep
rod
uto
/Ap
rova
r/R
eje
ita
r«
flo
w»
Da
do
s d
e c
om
pra
s«
flo
w»
Co
taçõ
es
«fl
ow
»
13
7
bdd
[Sys
ML
Blo
ck D
efin
ition
] Stru
ctur
e [S
iste
ma
PL
M]
«S
yste
m»
Con
text
dia
gram
::Sis
tem
a P
LM
«b
lock
»C
onte
xt d
iagr
am::
Vau
lt pe
rman
ente
«b
lock
»C
onte
xt d
iagr
am::
CA
D T
ool
«b
lock
»C
onte
xt d
iagr
am::
Ge
renc
iado
r de
m
udan
ças
de
eng
enha
ria
«b
lock
»C
onte
xt d
iagr
am
::Fe
rra
me
nta
cola
bora
tiva
«b
lock
»C
onte
xt d
iagr
am::
Fer
ram
enta
de
v
isua
lizaç
ão
«b
lock
»C
onte
xt d
iagr
am::
Ger
enci
ado
r de
de
senh
os
«b
lock
»C
onte
xt d
iagr
am::
Ge
renc
iado
r de
pr
oje
tos
«b
lock
»C
onte
xt d
iagr
am::
Ge
renc
iado
r de
re
quis
itos
«b
lock
»C
onte
xt d
iagr
am::
Va
ult e
m
proc
ess
o
«b
lock
»C
onte
xt d
iagr
am::
CA
E to
ol
«b
lock
»C
onte
xt d
iagr
am
::C
AM
Too
l
«b
lock
»C
onte
xt d
iagr
am
::E
dito
r de
text
o
«b
lock
»C
onte
xt d
iagr
am::
Spr
ead
shee
t too
l
«b
lock
»C
onte
xt d
iagr
am::
Ge
renc
iado
r de
e
-mai
ls
«b
lock
»C
onte
xt d
iagr
am
::P
DF
tool
«b
lock
»C
onte
xt d
iagr
am
::C
NC
file
s m
anag
er
«b
lock
»C
onte
xt d
iagr
am::
CA
x To
ols
«b
lock
»C
onte
xt d
iagr
am
::V
aul
t de
da
dos
e in
form
açõe
s
«b
lock
»C
onte
xt d
iagr
am
::O
ffice
por
tfolio
«b
lock
»C
onte
xt d
iagr
am
::W
eb s
erv
ice
s pr
ovid
er/
rece
iver
«b
lock
»C
onte
xt d
iagr
am::
ER
P
prov
ide
r/re
ceiv
er
serv
ices
Fig
ura
5-2
2: D
iagr
ama
de
bloc
os r
epre
sent
ando
a e
stru
tura
do
sist
ema
138
5.6.3 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
orequisitoparaosistemaPLM≫OsistemaPLMdevepropiciaraumento
dequalidadedosprodutosdesenvolvidospelodepartamentoDPI≪
5) A necessidade ≫Melhorar a qualidade dos produtos desenvolvidos≪origina
orequisitoparaosistemaPLM≫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
detalhadadoproduto≪
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
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 manufatu ra
«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
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
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
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 (Cl iente)
«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 engen haria
«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
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$100.000,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 5-23. Na figura são apresentadas as relações entre os
requisitos desdobrados no método REQ4PLM.
14
5
req
[Sys
ML
Requ
irem
ents]
Req
uire
men
ts [Im
plem
enta
tion
Req
uirem
ents]
REQ
011
- Red
ução
de
Custo
s
note
sO
sis
tema
PLM
dev
e re
duzi
r cus
tos
com
retra
balh
os n
a ma
nufa
tura
dos
pr
odut
os
(from
Sta
keho
lder
requ
ireme
nts)
REQ
014
- Mel
horia
da
Qua
lidad
e
note
sO
sis
tema
PLM
dev
e me
lhor
ar a
qu
alid
ade
dos
prod
utos
de
senv
olvi
dos.
(from
Sta
keho
lder
requ
ireme
nts)
REQ
016
- Des
empe
nho
de P
roje
tar
prod
utos
note
sO
sis
tema
PLM
dev
e me
lhor
ar o
de
semp
enho
ao
long
o do
Pro
cess
o de
Pro
jeta
r pro
duto
s.
(from
Sta
keho
lder
requ
ireme
nts)
REQ
001
- Aut
omat
izaç
ão d
e at
ivid
ades
note
sA
solu
ção
PLM
dev
e pe
rmiti
r a
auto
matiz
ação
de
ativ
idad
es
repe
titiv
as d
os p
roje
tos
dese
nvol
vime
ntos
(from
Sta
keho
lder
requ
ireme
nts)
REQ
002
- Mel
horia
da
com
unic
ação
note
sO
sis
tema
PLM
dev
e fa
cilit
ar a
co
muni
caçã
o en
tre o
time
de
dese
nvol
vime
nto
e os
clie
ntes
e
forn
eced
ores
(from
Sta
keho
lder
requ
ireme
nts)
REQ
003
- Red
uzir
retra
balh
os
note
sO
sis
tema
PLM
dev
e re
duzi
r o
retra
balh
o na
s at
ivid
ades
real
izad
asao
long
o do
cic
lo d
o pr
odut
o
(from
Sta
keho
lder
requ
ireme
nts)
REQ
004
- Ras
treab
ilida
de d
e at
ivid
ades
note
sO
sis
tema
PLM
dev
e ga
rant
ir a
rast
reab
ilida
de d
as a
tivid
ades
re
aliz
adas
, por
real
izar
, atra
sada
s,
ao lo
ngo
do c
iclo
de
vida
do
prod
uto
(from
Sta
keho
lder
requ
ireme
nts)
REQ
005
- Pad
roni
zaçã
o
note
sAs
nor
mas
e re
come
ndaç
ões
de
enge
nhar
ia u
tiliz
adas
atu
alme
nte
deve
m se
r inc
orpo
rada
s fa
cilm
ente
ao
s flu
xos
de tr
abal
hos
no s
iste
ma
sele
cion
ado
(from
Sta
keho
lder
requ
ireme
nts)
REQ
006
- Ace
sso
a in
form
ação
note
sO
s cl
ient
es d
evem
a q
ualq
uer
mome
nto
e lu
gar a
cess
ar o
s st
atus
de
pro
jeto
e re
aliz
ar a
prov
açõe
s ut
iliza
ndo
uma
cone
xãoo
de
inte
rnet
(from
Sta
keho
lder
requ
ireme
nts)
REQ
007
- Ace
sso
a in
form
ação
G
eren
te
note
sO
ger
ente
DPI
dev
e po
der a
cess
ar o
st
atus
de
proj
eto
e re
aliz
ar
apro
vaçõ
es a
qua
lque
r mom
ento
e
luga
r ut
iliza
ndo
uma
cone
xão
de
inte
rnet
(from
Sta
keho
lder
requ
ireme
nts)
REQ
008
- Ace
sso
a in
form
ação
En
genh
eiro
de
man
ufat
ura
note
sO
Eng
enhe
iro d
e ma
nufa
tura
dev
e po
der a
cess
ar d
ados
de
prod
uto
ao
mesm
o te
mpo
que
este
s es
tiver
em
send
o cr
iado
s(Nã
o lib
erad
os p
ara
manu
fatu
ra)
(from
Sta
keho
lder
requ
ireme
nts)
REQ
017
- Con
trole
de
mod
ifcaç
ões
note
sO
sis
tema
PLM
dev
e co
ntro
lar a
s mo
dific
açõe
s do
pro
duto
ao
long
o do
cic
lo.
(from
Sta
keho
lder
requ
ireme
nts)
REQ
010
- Rec
onci
liaçã
o de
dad
os
note
sO
sis
tema
PLM
dev
e re
duzi
r o
impa
cto
ocas
iona
do p
ela
reco
ncili
ação
de
dado
s de
vido
a
utili
zaçã
o de
div
erso
s fo
rmat
os C
AD.
(from
Sta
keho
lder
requ
ireme
nts)
REQ
009
- Agi
lidad
e de
apr
ovaç
ão
note
sO
sis
tema
PLM
dev
e pe
rmiti
r mai
or
agili
dade
na
apro
vaçã
o de
eta
pas
dos
proj
etos
(from
Sta
keho
lder
requ
ireme
nts)
REQ
012
- Rev
isão
do p
rodu
to
note
sO
sis
tema
PLM
dev
e fa
cilit
ar a
re
visã
o de
talh
ada
do p
rodu
to
(man
ufat
ura
e fu
ncio
nalid
ade)
(from
Sta
keho
lder
requ
ireme
nts)
REQ
015
- Pro
cess
o de
com
pras
note
sO
sis
tema
PLM
dev
e fo
rnec
er to
das
as in
form
açõe
s ne
cess
ária
s pa
ra
exec
ução
do
proc
esso
de
comp
ras
num
form
ato
aces
síve
l aos
co
mpra
dore
s e
dire
tame
nte
utili
záve
lno
pro
cess
o
(from
Sta
keho
lder
requ
ireme
nts)
REQ
013
- Tre
inam
ento
das
pes
soas
note
sAs
pes
soas
pre
cisa
m po
ssui
r co
nhec
imen
to m
inim
os s
obre
o
proc
esso
par
a pa
rtici
paçã
o ef
etiv
a ne
le (from
Sta
keho
lder
requ
ireme
nts)RE
S005
- RO
I
note
sO
s in
vest
idor
es e
a d
ireto
ria
da e
mpre
sas
deve
m ob
ter
ROI d
e no
min
imo
25%
re
lativ
o ao
inve
stim
ento
in
icia
l
(from
Sta
keho
lder
requ
ireme
nts)
RES0
01 -
Payb
ack
note
sO
pay
back
do
inve
stim
ento
de
ve a
cont
ecer
em
no
máxi
mo 3
ano
s.
(from
Sta
keho
lder
requ
ireme
nts)
RES0
02 -
Bene
ficio
s par
a di
reto
ria
note
sA
dire
toria
dev
e en
xerg
ar o
s be
nefíc
ios
seis
mes
es a
pós
aim
plem
enta
ção
do s
iste
ma
PLM
(from
Sta
keho
lder
requ
ireme
nts)
RES0
03 -
Tem
po d
e im
plem
enta
ção
note
sO
sis
tema
PLM
dev
e se
r im
plem
enta
do e
m no
máx
imo
6 me
ses
(from
Sta
keho
lder
requ
ireme
nts)
RES0
04 -
Inve
stim
ento
note
sO
inve
stim
ento
tota
l não
de
ve u
ltrap
assa
r R$
100.
000,
00
(from
Sta
keho
lder
requ
ireme
nts)
REQ
358
- che
ck in
che
ck o
ut
note
sO
sis
tema
PLM
dev
e of
erec
er a
po
ssib
ilida
de d
e re
aliz
ar c
heck
in
chec
k ou
t dire
tame
nte
do a
plic
ativ
o CA
D en
caps
ulad
o (to
tame
nte
inte
grad
o) n
o si
stem
a PL
M
(from
CAD
Inte
grat
ion)
REQ
186
- Rep
rese
ntaç
ão
gráf
ica
de m
udan
ças d
e en
genh
aria
note
sO
sis
tema
PLM
dev
e po
ssui
r um
a re
pres
enta
ção
graf
ica
dos
obje
tos
que
são
impa
ctad
os n
uma
muda
nça
de e
ngen
haria
(from
Man
agin
g En
gine
erin
g Ch
ange
)
REQ
234
- com
patil
ham
ento
de
info
rmaç
ão
note
sO
sis
tema
dev
e fe
rrame
ntas
de
comp
artil
hame
nto
de
info
rmaç
ões/
aplic
ação
via
inte
rnet
(from
On-
line
Mee
ting
Tool
s)
REQ
101
- Int
egra
ção
com
siste
mas
ex
isten
tes
note
sO
sis
tema
PLM
dev
e in
tegr
ar-s
e ao
s si
stem
as le
gado
s já
util
izad
os n
o pr
oces
so
REQ
102
- int
egra
ção
ao E
RP
note
sO
sis
tema
PLM
dev
e in
tegr
ar-s
e ao
si
stem
a ER
P-W
ebde
sk p
ara
troca
r da
dos
sobr
e as
com
pras
dos
pr
ojet
os.
REQ
103
- int
egra
rção
com
a W
EB
note
sO
sis
tema
PLM
dev
e po
ssui
r a
func
iona
lidad
e de
inte
grar
-se
com
a W
EB
REQ
104-
apro
vaçã
o/Re
jeiç
ão
de tr
abal
ho v
ia W
EB
note
sO
sis
tema
PLM
dev
e pe
rmiti
r qu
e o
gere
nte
DPI p
ossa
re
aliz
ar A
prov
açõe
s/Re
jeiç
ões
via
WEB
REQ
105
- Ap
rova
ção/
Reje
içao
de
traba
lho
via
WEB
(Clie
nte)
note
sO
sis
tema
PLM
dev
e pe
rmiti
r qu
e o
gere
nte
DPI p
ossa
re
aliz
ar A
prov
açõe
s/Re
jeiç
ões
via
WEB
«der
iveR
eqt»
«der
iveR
eqt»
«der
iveR
eqt»
«der
iveR
eqt»
«der
iveR
eqt»
«der
iveR
eqt»
«der
iveR
eqt»
«der
iveR
eqt»
«der
iveR
eqt»
«tra
ce»
«der
iveR
eqt»
«der
iveR
eqt»
«der
iveR
eqt»
«tra
ce»
«der
iveR
eqt»
«der
iveR
eqt»
«der
iveR
eqt»
«tra
ce»
Fig
ura
5-2
3: R
equi
sito
s d
eter
min
ados
par
a P
LM
146
6. 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
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.
Quando a empresa não possuir uma cultura orientada a processos implantada, se corre o risco de existirem iterações para que os processos sejam otimizados.
� 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 de médio e pequeno porte
� 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 pode-se 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
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:
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.
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
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.
15
0
Qua
dro
6-2:
Aná
lise
sinó
tica
dos
trab
alho
s ex
iste
ntes
rel
acio
nado
s ao
aux
ilio
a im
plem
enta
ção
PLM
e a
co
ntrib
uiçã
o da
do p
elo
dese
nvol
vim
ento
de
sse
trab
alho
A
uto
res
Ca
ract
erí
stic
as
(ZA
NC
UL,
20
09
) (U
MB
LE e
t a
l.,
20
03
) (G
RIE
VE
S,
20
06
) (S
AA
KS
VU
OR
I e
t a
l.,
20
08
)
RE
Q4
PLM
Ab
ord
agem
u
tili
zad
a D
esen
volv
imen
to d
e m
odel
os d
e re
ferê
ncia
, pr
oces
sos
e id
entif
icaç
ão d
e bo
as p
rátic
as d
e im
plan
taçã
o de
sis
tem
as
ER
P.
Iden
tific
ação
, em
trab
alho
s an
terio
res
rela
cion
ados
a
ER
P, o
s fa
tore
s de
suc
esso
e
uma
com
patib
iliza
ção
dess
es tr
abal
hos.
Abo
rda
a im
plan
taçã
o P
LM
no n
ível
est
raté
gico
. Def
ine
visã
o, a
valia
a s
ituaç
ão
atua
l e p
lane
ja a
s m
udan
ças
nece
ssár
ias
a um
a es
trat
égia
PLM
.
Est
rutu
ra a
impl
anta
ção
PLM
com
boa
s pr
átic
as d
e ge
renc
iam
ento
de
proj
eto.
C
onsi
dera
sis
tem
a P
LM
com
o um
a fe
rram
enta
par
a au
xílio
aos
pro
cess
os.
Def
ine
requ
isito
s pa
ra o
si
stem
a P
LM e
indi
cado
res
para
ser
em a
lcan
çado
s ap
ós a
impl
anta
ção
base
ado
nos
proc
esso
s de
ne
góci
os d
o ci
clo
de v
ida
do p
rodu
to. C
onsi
dera
um
si
stem
a P
LM c
omo
com
post
o po
r so
ftwar
e,
proc
esso
s e
usuá
rios.
Ên
fase
da
pro
po
sta
Sel
eção
de
sist
emas
PLM
em
funç
ão d
a ad
erên
cia
dos
proc
esso
s ex
iste
ntes
a
um m
odel
o de
ref
erên
cia
dese
nvol
vido
.
Boa
s pr
átic
as e
xist
ente
s e
os c
asos
de
suce
sso.
D
efin
ição
da
estr
atég
ia d
e ne
góci
os r
elac
iona
da a
im
plem
enta
ção
de
sist
emas
PLM
.
Ger
enci
amen
to d
as
mud
ança
s or
gani
zaci
onai
s e
gere
ncia
men
to d
e pr
ojet
os (
proj
eto
de
impl
anta
ção
PLM
).
Sis
tém
ico:
Pro
cess
os,
Sta
keho
lder
s, u
suár
ios
e fu
ncio
nalid
ades
te
cnol
ógic
as a
nalis
ados
si
mul
tane
amen
te.
Uso
de
ind
icad
ore
s p
ara
aval
iar
a im
pla
nta
ção
Não
abo
rda.
N
ão a
bord
a.
Indi
ca R
OI e
RO
A c
omo
indi
cado
res
de
dese
mpe
nho,
con
tudo
não
m
ostr
a co
mo
obte
r es
ses
indi
cado
res.
Indi
cado
res
são
abor
dado
s de
form
a im
plíc
ita
(indi
cado
res
de p
roje
to):
pr
azos
, orç
amen
to, e
tc.
Des
dobr
a in
dica
dore
s qu
e de
vem
val
idar
a s
atis
façã
o do
s st
akeh
olde
rs d
o pr
oces
so a
pós
a im
plan
taçã
o de
um
sis
tem
a P
LM
15
1
Con
tinua
ção
- Q
uad
ro 6
-2:
Aná
lise
sinó
tica
dos
trab
alho
s ex
iste
ntes
rel
acio
nado
s ao
aux
ilio
a im
plem
enta
ção
PLM
e a
con
trib
uiçã
o da
do p
elo
dese
nvol
vim
ento
des
se tr
abal
ho
A
uto
res
Ca
ract
erí
stic
as
Za
ncu
l (2
00
9)
Um
ble
et
al,
20
02
G
rie
ve
s (2
00
6)
Sa
ak
svu
ori
et
al
(20
08
) R
EQ
4P
LM
Sta
ke
ho
lde
rs
Não
usa
o c
once
ito d
e st
akeh
olde
rs. A
bord
a os
us
uário
s do
sis
tem
a (s
oftw
are
para
PLM
) co
mo
um ti
po d
e st
akeh
olde
r do
si
stem
a P
LM.
Não
usa
o c
once
ito d
e st
akeh
olde
rs. D
ecla
ra
som
ente
os
usuá
rios
do
sist
ema
que
são
um ti
po d
e st
akeh
olde
r do
sis
tem
a P
LM.
Não
usa
o c
once
ito d
e st
akeh
olde
rs. I
dent
ifica
os
usuá
rios
do s
iste
ma
PLM
e
mem
bros
da
dire
toria
da
empr
esa
Não
usa
o c
once
ito d
e st
akeh
olde
rs. L
ista
so
men
te u
suár
ios
do
sist
ema
PLM
.
Elíc
ita o
s st
akeh
olde
rs d
os
proc
esso
s de
cic
lo d
e vi
da
e an
alis
a su
as
nece
ssid
ades
rel
acio
nada
s ao
s pr
oces
sos.
Dim
ensõ
es
anal
isad
as
Pro
cess
os d
e ne
góci
o e
func
iona
lidad
es P
LM
Som
ente
apl
icat
ivos
de
softw
are
e us
uário
s P
roce
ssos
de
negó
cios
, fu
ncio
nalid
ades
PLM
e
pess
oas.
Pro
cess
os d
e ne
góci
o.
Pro
cess
os d
e ne
góci
os,
stak
ehol
ders
e
func
iona
lidad
es P
LM.
An
ális
e d
e s
ta
ke
ho
lde
rs
do
p
roce
sso
e d
e su
as
nec
essi
dad
es
Não
usa
N
ão u
sa.
Não
usa
. N
ão u
sa.
An
alis
ar o
s p
rin
cip
ais
stakeholders
do
s p
roce
sso
s d
e n
ego
cio
p
ara
iden
tifi
car
suas
n
eces
sid
ades
Tip
os
de
mo
del
agem
u
sad
a n
a p
rop
ost
a
Nen
hu
ma
Nen
hu
ma.
N
enh
um
a.
Nen
hu
ma.
M
od
elag
em d
e si
stem
as
e d
e p
roce
sso
s
Uso
de
no
taçõ
es
esp
ecíf
icas
de
mo
del
agem
Nen
hu
ma
N
enh
um
a.
Nen
hu
ma.
N
enh
um
a.
BP
MN
, Sys
ML/
UM
L
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
7. 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
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
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
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
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
ferramentas PLM disponíveis no mercado. Com isso, buscar-se-ia reduzir o tempo de
implantação e consequentemente seus custos.
159
REFERÊNCIAS
Associação Brasileira de Normas Técnicas: NBR ISO 9001-2008: Sistema de gestão da qualidade-Requisitos. Rio de Janeiro, 2008.
Associação Brasileira de Normas Técnicas: NBR 15100-2010: Sistema de Gestão da Qualidade-Requisitos para organizações de aeronáutica, espaço e defesa. Rio de Janeiro. 2010.
ABRAMOVICI, M. Future trends in product lifecycle management (PLM). In: CIRP DESIGN CONFERENCE, 17., 2007, Proceedings… Berlin: Springer, 2007.
ACOSTA, L. M. C. A method for deriving performance indicators for product development process. 105f. 2004. 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.833–841,2008.
ALEXANDER, I. Building what stakeholders desire. IEEE Software, March/April, p. 62-65, 2007.
ALEXANDER, I. F.; STEVENS, R. Writing better requirements . London: Pearson Education, 2002.
AMERI, F.; DUTTA, D. Product lifecycle management: needs, concepts and components. Ann Arbor-MI. 2004.p. 45. Apostila – University of Michigan.
ARMISTEAD, C. G.; MACHIN, S. Implications of business process management for operations management. International Journal of Operations & Production Ma nagement, v.17, p.86-89, 1997.
BAHIL, A. T.; GISSING, B. Re-evaluation systems engineering concepts using systems thinking. IEEE Transactions on Systems, Man and Cybernetics, v. 4, p.516-527, 1998.
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., 1998.
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.]. 2002. CD-ROM.
BARTHOLOMEW, D. Process is back. Industry Week, Nov. 1999.
BERGAMASCHI, S. Um estudo sobre projetos de implementação de sistemas para gestão empesarial. 181f. 1999. Dissertação(Mestrado em Administração) – Faculdade de Economia, Administração e Contabilidade, Univeridade de São Paulo. São Paulo.
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. 167-208, 2000.
CAMERON, E.; GREEN, M. Gerenciando mudanças. São Paulo: Clio Editora, 2009.
CIMADATA. Industrial Organization Consulting, 2011. Disponivel em: <http://www.cimdata.com/services/consulting/industrial_organizations.html>. Acesso em: 03 outubro 2011.
CIMDATA. PDM to PLM: Growth of An Industry . CIMDATA. Ann Arbor, p. 26. 2003. Relatório de Negócios.
CIMDATA. Measuring Business Process Benefits Achieved Using SMARTEAM . CIMDATA. Ann Arbor. 2005. Relatório de Negócios.
CIMDATA. Product Lifecycle Management (PLM) Definition. CIMDATA: Global Leaders in PLM consulting, 2008. Disponivel em: <http://www.cimdata.com/plm/definition.html>. Acesso em: 25 mar. 2009.
COLANGELO FILHO, L. Implantação de sistemas ERP. São Paulo: Atlas, 2001.
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. 186-203, Aug. 2004.
COMMISSION OF THE EUROPEAN COMMUNITIES UNDER ESPRIT PROGRAMME. Workflow Management for Simultaneous Engineering Networks. ESPRIT programme, 2008. Disponivel em: <http://tmitwww.tm.tue.nl/staff/krouibah/SIMNET.htm>. Acesso em: 21 janeiro 2009.
CROSS, N. Engineering design methods: Strategies for product design. West Sussex: Jonh Wiley & Sons, 2004. ISBN 0-471-87250-4.
CURTIS, B.; KELLNER, M. I.; OVER, J. Process modeling. Communications of the ACM, v.35, p. 75-90, 1992.
DAVENPORT, T. H. Process innovation: reegineering work through information technology. Boston: Havard Business School press, 1993.
DAVENPORT, T. H. Saving IT´s soul. Havard Business Review, march/april, p.11-27, 1994.
DAVIS, R. ARIS design platform advanced process modelling and administration . London: Springer-Verlag, 2008.
DOD-SYSTEMS MANAGEMENT COLLEGE. Systems engineering fundamentals. Fort Belvoir: Defense Acquisition Press, 2001.
DREILING, A. R. et al. Model based software configuration: patterns and languages. European Journal of Information Systems, v.18, p. 583-600, 2006..
161
ERIKSSON, H.-E.; PENKER, M. Business modeling with UML. New York: Jonh Willey & Sons, 2000.
FNQ. Modelo de Excelência da Gestão, 2010. Disponivel em: <http://www.fnq.org.br/site/292/default.aspx>. Acesso em: 12 Setembro 2011.
FREEMAN, R. E. Strategic management: a stakeholder approach. Marshfield: Pitman, 1984. ISBN 0-273-01913-9.
GRIEVES, M. Product lifecycle management. New York: McGraw-Hill, 2006.
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, 2002.
HECHT, B. Chose the right ERP software. Datamation, march/spril, 1997.
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, 2006. 65–82.
HILL, JR., S. A winning strategy. Manufacturing business technology, Setembro 2006.
HOJLO, J.; D’AQUILA, M.; CARTER, K. The product lifecycle management market sizing report, 2007–2012. [s.n.]. 2008.
HOOKS, I. F.; FARRY, K. A. Customer-centered products: Creating Successful Products through smart requirements management. New York: AMACOM, 2001.
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. 984-999, 2005.
HULL, E.; JACKSON, K.; DICK, J. Requirements Engineering. London: Springer, 2005. ISBN 1-85233-879-2.
IBM. PLM Services, 2011. Disponivel em: <http://www-01.ibm.com/software/plm/services/index.html>. Acesso em: 03 outubro 2011.
INCOSE. System engineering handbook. San Diego: [s.n.], v. 3.2.1, 2011.
INDULSKA, M. et al. Business Process Modeling: Perceived benefits. 28th International Conference on Conceptual Modeling. Heidelberg: Springer. 2009. p. 458–471.
INTERNATIONAL STANDARD ORGANIZATION. ISO/IEC 15288:2008: Systems and software engineering - system life cycle processes. [S.l.]. 2008.
JSF. JOIN STRIKE FIGHTER. HISTORY. 2006. Disponivel em: <http://www.jsf.mil/>. Acesso em: 6 Agosto 2010.
KAPLAN, R. S.; NORTON, D. P. The balanced scorecard. Boston: Havard Business School Press, 1996.
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, 1988. p. 133 - 140.
KRASNER, H. Ensuring e-business sucess by learning from ERP failures. IT PRO , v. 3. n. 52, p. 23-27, Fev. 2000.
LATOUR, B. Pandora´s Hope: essays on the reality of Science Study. Cambridge: Havard Business Press, 1999. P. 174-215.
LOUREIRO. Introdução a engenharia de sistemas.Notas de aula - Instituto Tecnológico de Aeronáutica, São José dos Campos. 2006.
LOUREIRO, G. A system engineering and concurrent engieering framework for the integrated development of products. Tese(Doutorado) – Loughborough University, Loughborough. 1999.
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. 235–246, 2003.
MABERT, V. A.; SONI, A. ; VENKATARAMANAN, M. Enterprise resource planning survey of US manufacturing firms. Production & Inventory Management Journal, n. 41,. p. 52–58. 2000.
MACKRELL, J. PLM benefits, metrics, and ROI for PLM. CIMdata , 2004. Disponivel em: <http://www.cimdata.com/publications/articles.html>. Acesso em: 1 Dezembro 2006.
MARCONI, M. A.; LAKATOS, E. M. Metodologia científica. São Paulo: Atlas, 1991.
MASON, R.; MITROF, I. Challenging strategic planning assumptions: theory, cases, and techniques. New York: Jonh Wiley & Sons, 1981.
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. 40-48, jan./mar. 2002.
MOREIRA, J. C. T. Usina de valor. São Paulo: Gente, 2009.
NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Integration definition for function modeling (IDEF0). [S.l.]. 1993.
OBJECT MANAGEMENT GROUP. Unified Modeling Language. Needham. 2009.
OBJECT MANAGEMENT GROUP. Systems Modeling Language. Needham. 2010.
OBJECT MANAGEMENT GROUP. Business Process Modeling and Notation. Needham. 2010.
OULD, M. A. Business Process: Modeling and Analyst for Re-Engineering and Improvement. Chichester: Jonh Wiley & Sons, 1995.
163
PHILLIPS, J. J.; PHILLIPS, P. P. Show me the money. San Francisco: Berrett-Koehler Publishers, 2007.
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, 2010.
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, 2008.
RECKER, J. BPMN Modelling-Who, Where, How and Why. BPTrends, Maio, p. 2-8, 2008.
RECKER, J. Evaluation of process modeling grammars. Heidelberg: Springer, 2011.
RICCIO, E. L. Efeitos da tecnoogia de informação na contabilidade: estudo de casos de implementação de sistmas empresariais integrados - ERP 2001. Tese(Livre docência ) - Universidade de São Paulo. São Paulo. 2001.
RILEY, L. A.; COX, L. Computer Integrated Manufacturing: Challenges and Barriers to Implementation. The technology interface, New Mexico, December 1998. Disponivelem: <http://engr.nmsu.edu/~etti/winter98/manufacturing/riley/riley>. Acesso em: 06 Ago. 2007.
ROULSTONE, D. B.; PHILLIPS, J. J. ROI for Technology Projects - Measuring and Delivering Value. Oxford: Butterworth-Heinemann, 2008. ISBN 978-0-7506-8588-7.
ROZENFELD, H. et al. Gestão de Desenvolvimento de Produtos. São Paulo: Saraiva, 2006.
SAAKSVUORI, A.; IMMONEN, A. Product Lifecycle Management. 3. ed. Berlin: Springer, 2008.
SCHUH, G. et al. Process oriented framework to support PLM implementation. Computers in Industry , v59, n. 2, p. 210-218, 2008.
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]. 1998.
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. 2009.
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. 1999.
SOUZA, C. A.; SACCOL, A. Z. Sistemas ERP no Brasil: teoria e casos. São Paulo: Atlas, 2008.
SPARX-SYSTEMS. UML tools for software development and modelling. Enterprise Architect UML modeling tool , 2011. Disponivel em: <http://www.sparxsystems.com.au/>. Acesso em: 10 Fevereiro 2011.
164
TECHNICAL BOARD INTERNATIONAL COUNCIL ON SYSTEMS ENGINEERING (INCOSE). Systems engineering handbook: a guide for system life cycle process and activities. San Diego: INCOSE, 2010.
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], 2001.
TOSCANO, G.; OSTINELLI, C. A Performace measurement system model from activity-based management accounting perspective. In: ANNUAL CONGRESS OF THE EUROPEAN ACCOUNTING ASSOCIATION, 21, 1998, Antwerp. Proceedings...: Brussels: EAA, 1998.
TRABASSO, G. Desenvolvimento integrado de produtos. Instituto Tecnologico de Aeronáutica. São José dos Campos. 2005. 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.]. 1998.
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. 241-257, April 2003.
UNITED STATES AIR FORCE SYSTEMS COMMAND. AFWAL-TR-81-4023: Function modeling manual(IDEF0),. Ohio, 1981. v. 4.
VAN DER AALST, W. M. P. et al. Workflow patterns. Distributed and Parallel Databases, v.14, p. 5-51, 2003.
VERNADAT, F. B. Enterprise modeling and integration: principles and Applications. [S.l]: Springer, 1996.
VERNADAT, F. B. UML: towards a unified enterprise modeling language. International Journal of Production Research, v. 17, n. 40, p. 4309-4321, 2002..
WEILKIENS, T. Systems engineering with SysML/UML: modeling, analysis, design. Burlington: Morgan Kaufmann Publishers, 2006.
WORKFLOW MANAGEMENT COALITION. WFMC-TC-1025 XM: Process Definition Language: XPDL. Hingham, 2008.
WHITE, S. A.; MIERS, D. BPMN modeling and reference guide. Lighthouse Point: Future Strategies, Book Division, 2008.
WOMACK, J. P.; JONES, D. T.; ROOS, D. The machine that changed the world. [S.l.]: [s.n.], 2007.
WRIGHT.MEDICAL GROUP Prophecy, 2010. Disponivel em: <http://www.wmt.com/prophecy/>. Acesso em: 10 jan. 2011.
YOUNG, R.. The requirements engineering handbook. Norwood: Artech House, 2004.
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, 2008. Anais...Bauru: UNESP, 2008, p.1-12.
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. 2009. Tese (Doutoado em Engenharia de Produção) - Escola de Engenharia de São Carlos, São Carlos.
166
ANEXOS
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).
16
8
Ati
vid
ades
A
tivid
ades
Ativid
ades
Ativid
ades
Ativid
ades
repre
senta
m o
tra
balh
o r
ealiza
do p
or
um
a o
rganiz
açã
o: E
las r
epre
senta
m
um
passo n
o p
rocess
o. A
s A
tivid
ades p
odem
ser
com
post
as o
u n
ão.
Tare
fa
Um
a t
are
fa é
um
a a
tivid
ade s
imple
s q
ue é
usada p
ara
m
odela
r o t
rabalh
o é
realiza
do e
m u
m p
rocesso e
não
é
definid
a e
m m
ais
deta
lhes.
BPM
N p
ossui difere
nte
s t
ipos
de t
are
fas:
Sub
pro
cess
o
Tra
ta-se d
e u
ma a
tivid
ade c
om
posta
cujo
s d
eta
lhes s
ão
definid
os c
om
o u
m c
onju
nto
de o
utr
as a
tivid
ades.
Su
bp
roce
sso
en
cap
sula
do
Depende c
om
ple
tam
ente
do p
rocesso p
ai. E
les n
ão p
odem
conte
r pools
ou lan
es.
Pro
cess
o r
eu
tili
záv
el
É u
m p
rocess
o d
e n
egócio
definid
o e
m o
utr
o d
iagra
ma d
e
pro
cesso, que n
ão d
epende d
o p
rocesso p
ai.
Gat
eway
s G
ate
ways
Gate
ways
Gate
ways
Gate
ways
são e
lem
ento
s u
sados p
ara
contr
ola
r a d
iverg
ência
e c
onverg
ência
dos
fluxos d
e t
rabalh
o.
Ga
tew
ay
excl
usi
vo
ba
sea
do
em
da
do
s –
GE
BD
D
iverg
ência
:D
iverg
ência
:D
iverg
ência
:D
iverg
ência
: U
ma d
ecis
ão e
xclu
siv
a t
em
duas o
u m
ais
saíd
as d
e
fluxo d
e t
rabalh
o, m
as s
om
ente
um
a d
ele
s s
erá
seguid
o e
a d
ecis
ão
depende d
a a
valiação
do p
rocess
o d
e n
egócio
. C
onverg
ência
:C
onverg
ência
:C
onverg
ência
:C
onverg
ência
: é u
sado p
ara
unir
flu
xos d
e t
rabalh
o a
ltern
ativos.
Ga
tew
ay
excl
usi
vo
ba
sea
do
em
ev
en
tos
- G
EB
E
É u
sado c
om
o u
m e
lem
ento
de d
iverg
ência
, E
sse
gate
way
repre
senta
um
ponto
no p
rocess
o o
nde s
om
ente
um
, de m
uitos
fluxos p
ode c
ontinuar,
mas b
ase
ado e
m u
m e
vento
, não
em
condiç
ão b
ase
ada e
m d
ados c
om
o o
GE
BD
.
Ga
tew
ay
Pa
rale
lo
Div
erg
ência
Div
erg
ência
Div
erg
ência
Div
erg
ência
: ::: é u
sado p
ara
cri
ar
fluxos p
ara
lelo
s.
Converg
ência
Converg
ência
Converg
ência
Converg
ência
: ::: é u
sado p
ara
sin
cro
niz
ar
múltip
los f
luxos p
ara
lelo
s
em
um
. O
flu
xo c
ontinua s
om
ente
após a
chegada d
e t
odos o
s
fluxos d
e e
ntr
ada a
o g
atew
ay.
G
atew
ay In
clus
ivo
D
iverg
ência
Div
erg
ência
Div
erg
ência
Div
erg
ência
: ::: In
dic
a q
ue s
om
ente
um
a o
u m
ais
cam
inhos n
o f
luxo d
o
pro
cesso p
odem
ser
ativados d
e m
uitos d
isponív
eis
, e a
decis
ão é
baseada e
m d
ados d
o p
rocesso.
Converg
ência
Converg
ência
Converg
ência
Converg
ência
: ::: In
dic
a q
ue m
uitos c
am
inhos d
e s
aíd
a d
e u
m g
ate
way
inclu
siv
o, usados c
om
o u
m e
lem
ento
de d
iverg
ência
, podem
ser
sin
cro
niz
ados e
m a
penas u
m.
Gat
eway
Com
plex
o
Div
erg
ência
Div
erg
ência
Div
erg
ência
Div
erg
ência
: ::: é u
sado p
ara
contr
ola
r ponto
s n
o p
rocesso o
nde
exis
tem
decis
ões c
om
ple
xas q
ue n
ão s
ão f
áceis
de g
ere
ncia
r com
outr
os t
ipos d
e g
atew
ays.
C
onverg
ência
Converg
ência
Converg
ência
Converg
ência
: ::: Q
uando u
m g
atew
ay é
usado c
om
o u
m a
glu
tinante
de f
luxos e
ntã
o e
xis
tirá
um
a e
xpre
ssão
que d
ete
rmin
ará
qual dos
fluxos d
e e
ntr
ada s
erá
necess
ário
para
o p
rocesso c
ontinuar.
16
9
Sw
inla
ne
s
Po
ols
Um
Pool é c
onta
iner
para
um
únic
o p
rocesso. O
nom
e d
o p
ool pode s
er
consid
era
do o
nom
e d
o p
rocess
o. E
xis
te p
elo
menos u
m p
ool em
pro
cesso m
odela
do c
om
BPM
N.
Lan
e
Um
a lan
e é
um
a s
ubdiv
isão
de u
m p
ool e r
epre
senta
um
papel ou á
rea
org
aniz
acio
nal.
Art
efa
tos
Perm
ite o
u f
orn
ece info
rmaçã
o a
dic
ional sobre
o p
rocesso
An
no
taçã
o
Forn
ece info
rmação
adic
ional so
bre
o p
rocesso
ao
leitor
dos m
odelo
s.
Gru
po
É u
m m
ecanis
mo v
isual que p
erm
ite o
agru
pam
ento
de
ativid
ades p
ara
o p
ropósito d
e d
ocum
enta
ção o
u a
nál
ise
dos p
rocess
os.
Ob
jeto
da
do
Forn
ece info
rmações s
obre
as e
ntr
adas e
saíd
as d
e u
ma
ativid
ade, is
to é
, docum
ento
s, dados e
outr
os o
bje
tos
usados e
modific
ados d
ura
nte
o p
rocesso. O
bje
tos d
ado
não
tem
qualq
uer
efe
ito s
obre
o f
luxo d
o p
rocesso o
u
fluxo d
e info
rmações inere
nte
s a
o p
rocesso.
Ob
jeto
s d
e c
on
ex
ão
Se
qu
en
ce f
low
É u
sado p
ara
mostr
ar
a o
rdem
que a
s a
tivid
ades s
erã
o
realiza
das e
m u
m p
rocesso. Is
used t
o s
how
the o
rder
that
activitie
s w
ill be p
erf
orm
ed in a
Pro
cess. E
le é
usado p
ara
repre
senta
r a s
equencia
do f
luxo o
bje
tos,
onde e
stã
o p
rese
nte
s a
tivid
ades, gate
ways e
evento
s.
Me
ssa
ge
flo
w
A e
ntidade M
ess
age f
low
é u
sada p
ara
mostr
ar
o f
luxo
de m
ensagens e
ntr
e d
uas o
utr
as e
ntidades o
u
pro
cessos.
A e
ntidade M
ess
age f
low
repre
senta
mensagem
(info
rmação
), n
ão o
contr
ole
do f
luxo d
e info
rmaçã
o.
Nem
todas a
s e
ntidades M
ess
age f
low
são
cum
pri
das
para
cada instâ
ncia
do p
rocesso e
nem
exis
te u
ma
ord
em
específic
a p
ara
as m
ensagens.
Ass
oci
açã
o
Um
a a
ssocia
ção é
usada p
ara
associa
r in
form
ação
e
art
efa
tos c
om
obje
tos d
e f
luxo.
17
0
Even
tos
E
ve
nto
Sta
rt
E
ve
nto
in
term
ed
iári
o
E
ve
nto
En
d
Indic
a a
ocorr
ência
ou inic
io d
e u
m p
rocesso. N
ão
exis
te q
ualq
uer
sequence
flo
w c
hegando a
ess
a
entidade.
Evento
s inte
rmediá
rios indic
am
que a
lgum
a c
ois
a
ocorr
eu o
u p
ode o
corr
er
dura
nte
o c
urs
o d
o p
rocess
o,
entr
e o
seu inic
io e
fim
. E
le p
ode s
er
usado n
o f
luxo o
u
anexado a
bord
a d
e u
ma a
tivid
ade.
Evento
End indic
a o
nde u
m p
rocesso irá
acabar.
Um
pro
cesso p
ode t
er
mais
do q
ue u
m e
vento
End. E
sses
evento
s n
ão p
ossu
em
qualq
uer
sequence
flo
w
deix
ando-o.
N
on
e
Não
especific
a q
ualq
uer
com
port
am
ento
part
icula
r.
N
on
e
Indic
a q
ue a
lgum
a c
ois
a o
corr
eu o
u
pode o
corr
er
no p
rocesso. E
le p
ode s
er
usado, som
ente
, no f
luxo d
o p
rocesso.
No
ne
Indic
a q
ue um
a r
ota
/cam
inho d
o
pro
cesso c
hegou a
o f
im. U
m p
rocesso
acaba s
om
ente
quando t
odas a
s ro
tas/c
am
inhos c
hegam
a u
m f
im.
M
en
sag
em
O
pro
cesso inic
ia-se q
uando u
ma
mensagem
é r
ecebid
a d
e o
utr
o
part
icip
ante
do p
rocesso.
M
en
sag
em
Indic
a q
ue u
ma m
ensagem
pode s
er
envia
da o
u r
ecebid
a. Se o
evento
é d
e
recepção
, ele
indic
a q
ue o
pro
cesso
deve a
guard
ar
até
receber
um
a
mensagem
. Esse
tip
o d
e e
vento
pode
ser
usado n
o f
luxo o
u a
nexado a
bord
a
de u
ma a
tivid
ade p
ara
indic
ar
um
flu
xo
altern
ativo.
M
en
sag
em
In
dic
a q
ue u
ma m
ensagem
é e
nvia
da a
outr
o p
rocesso q
uando o
pro
cesso
chega a
o f
im.
T
ime
r
Indic
a q
ue u
m p
rocess
o inic
ia e
m c
ert
o
tem
po o
u e
m u
ma d
ata
especific
ada.
T
ime
r
Indic
a u
m t
em
po d
e e
spera
no p
rocesso
Esse
tip
o d
e e
vento
pode s
er
usado n
o
fluxo d
o p
rocesso o
u a
nexado a
bord
a
de u
ma a
tivid
ade p
ara
indic
ar
um
flu
xo
altern
ativo q
uando a
cabar
o t
em
po d
e
execuçã
o d
a a
tivid
ade.
17
1
Even
tos
E
ve
nto
in
ício
Ev
en
to i
nte
rme
diá
rio
Ev
en
to f
im
C
on
dic
ion
al
O p
rocesso inic
ia q
uando u
ma c
ondiç
ão
de n
egócio
for
verd
adeir
a.
C
on
dic
ion
al
É u
sado q
uando o
flu
xo p
recis
a
aguard
ar
por
um
a c
ondiç
ão d
e n
egocio
seja
atingid
a. E
le p
ode s
er
usado n
o
fluxo indic
ando q
ue d
eve-se a
guard
ar
até
um
a c
ondiç
ão d
e n
egocio
seja
atingid
a o
u a
nexado a
bord
a d
e u
ma
ativid
ade indic
ando u
m f
luxo a
ltern
ativo
quando u
ma c
ondiç
ão e
specific
a é
atingid
a.
S
ina
l
Um
pro
cesso
inic
ia q
uando u
m s
inal de
vin
do d
e o
utr
o p
rocess
o é
recebid
o.
Note
que o
sin
al não
é u
ma m
ensagem
; m
ensagens t
em
cla
ram
ente
definid
o
quem
envia
e q
uem
recebi a m
ensagem
.
S
ina
l É
usado p
ara
envia
r e r
eceber
sin
ais
. Se e
le c
olo
cado n
o f
luxo d
e u
m
pro
cesso e
le p
ode s
er
envia
r ou
receber
um
sin
al. S
e e
le é
colo
cado
anexado a
bord
a d
e u
ma a
tivid
ade, ele
pode s
om
ente
receber
sin
ais
e indic
a
um
a e
xceção
ao f
luxo n
orm
al que é
ativado q
uando o
sin
al é r
ecebid
o.
S
ina
l In
dic
a q
ue u
m s
inal é g
era
do q
uando o
pro
cesso t
erm
ina.
M
últ
iplo
s
Indic
a q
ue e
xis
tem
muitas f
orm
as d
e
inic
iar
o p
rocesso. M
as s
om
ente
um
a
dela
s é
suficie
nte
.
M
últ
iplo
s
Esse
evento
sig
nific
a q
ue e
xis
tem
m
últip
los g
atilh
os r
ela
cio
nados a
o
evento
. T
odos o
s g
atilh
os d
evem
ocorr
er
para
que o
evento
aconte
ça.
M
últ
iplo
s
Indic
a q
ue m
uitos r
esultados p
odem
ser
alc
ançados a
o f
inal do p
rocesso.
Todos o
s r
esultados d
evem
ser
alc
ançados p
ara
que o
pro
cesso
term
ine.
17
2
Even
tos
E
ve
nto
in
ício
Ev
en
to i
nte
rme
diá
rio
Ev
en
to f
im
Co
mp
en
saçã
o
O e
vento
de c
om
pensaçã
o p
erm
ite
manip
ula
r com
pensações.
Quando u
sado
em
um
flu
xo s
equencia
l de p
rocesso,
ele
indic
a q
ue u
ma c
om
pensaçã
o é
necess
ária
para
o f
luxo c
ontinuar.
Q
uando u
sado n
as b
ord
as d
e u
ma
ativid
ade indic
a q
ue e
ssa a
tivid
ade s
erá
com
pensada q
uando o
evento
aconte
cer.
C
om
pe
nsa
ção
Indic
a q
ue o
pro
cesso a
cabou e
que
um
a c
om
pensaçã
o é
necessá
ria.
Lin
k
É u
sado p
ara
conecta
r duas s
eçõ
es d
o
pro
cesso.
Ca
nce
lam
en
to
É u
sado s
om
ente
em
tra
nsações d
e
sub-pro
cessos e
indic
a q
ue a
tr
ansação
deve s
er
cancela
da.
E
rro
Indic
a q
ue u
m e
rro c
onhecid
o é
gera
do q
uando o
pro
cess
o t
erm
ina.
F
im i
me
dia
to
Esse
evento
term
ina o
pro
cesso
im
edia
tam
ente
. Q
uando u
ma d
e f
luxo
de p
rocess
o c
hega a
seu f
im,
indic
ando q
ue o
pro
cesso t
erm
inou
com
ple
tam
ente
.
173
A2. BREVE RESUMO DA NOTAÇÃO SYSML
Neste anexo são apresentadas as entidades utilizadas neste trabalho e as
comumente utilizadas na modelagem de sistemas da linguagem SysML (System Modeling
Language). O objetivo é apenas orientar o autor quanto à modelagem SysML realizada no
trabalho e não realizar uma revisão completa da mesma. 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, 2010) e no livro de Tim Weilkiens (WEILKIENS,
2006).
DIAGRAMA DE BLOCOS
Os elementos centrais segundo o paradigma de modelagem orientada a objetos são
classes e objetos. Estreitamente relacionados às classes estão os componentes na linguagem
UML. Desde que os dois termos estão historicamente relacionados ao desenvolvimento de
software, SysML não os usa dessa forma. Todos os conceitos e objetos estáticos são blocos
em SysML (OBJECT MANAGEMENT GROUP, 2010). Eles têm a função de descrever a
estrutura do sistema e identificar a organização de suas partes. Pode apresentar o fluxo de
informações entre componentes do sistema e definições de interface por meio de portas. O
Quadro A2.1 apresenta os principais elementos de um diagrama de blocos.
174
Quadro A2.1: Principais elementos de um diagrama de blocos (OBJECT
MANAGEMENT GROUP, 2010).
Nome do elemento Definição Origem
Blocos (Blocks) Correspondem a uma extensão do conceito de classe da UML.
SysML
Operações (Operations) São elementos que definem o comportamento do bloco. SysML
Propriedades (Properties): São atributos do bloco SysML
Restrições (Constraints) Propriedades restritivas que o componente deve obedecer. SysML
Atores (Actors): Correspondem a usuários ou outros sistemas que interagem de forma ativa ou passiva com o sistema modelado.
UML
Relações (Relationship): Relacionamentos entre os blocos de um modelo UML
Associação (Association): Indica uma relação entre tipos de instâncias UML
Composição (Composition) Relação entre dois blocos onde um bloco contém outro bloco
UML
Generalização (Generalization):
Relaciona um classificador mais específico com um classificador mais geral. Também é conhecida como herança.
Dependência (Dependency) Define uma relação em que o modelo de um elemento requer outro modelo de elemento para sua especificação ou implementação.
Agregação (Aggregation) Representa uma relação “has-a”, representando que um objeto, representando o “todo”, tem objetos que são suas partes. Agregação é um tipo especial de associação
Porta (Ports): Especificam serviços que o bloco oferece ao ambiente ou serviços que o bloco espera do ambiente
Portas de fluxo (Flow ports) Especificam entradas e saídas de itens que proporcionam fluxo entre blocos e ambiente. São pontos de interações através de dados, material ou energia que entra ou sai do próprio bloco.
A Figura A2.1 mostra graficamente as relações usadas nesse trabalho entre blocos:
175
Figura A2.1: Relações entre blocos utilizadas no trabalho
Um exemplo de diagrama de blocos é apresentado na Figura A2.2. Nele, um
sistema portátil de áudio é representado por blocos que simulam os componentes do
sistema (subsistemas). Cada subsistema é responsável por realizar uma tarefa especifica.
O diagrama contem subsistemas para suprimento de potência, processamento e playback
de sinal sonoro, realizando interfaces com outros dispositivos e o usuário.
Dessa forma, em um estágio, muitas vezes bastante incipiente de desenvolvimento
é possível realizar diversas análises técnicas e propor requisitos que se cumpridos
garantiram o sucesso técnico do sistema desenvolvido. Além disso, os modelos
desenvolvidos podem passar a fazer parte de um legado da empresa que pode ser
reutilizado sempre que necessário.
bdd [SysML Block Definition] Blocks [Blocks]
«block»Block1
«block»Block2
«block»Block3
«block»Block4
«block»Block5
«block»Block6
«block»Block7
«block»Block8
Associação
Dependência
Generalização
Agregação
176
Figura A2.2: Diagrama de blocos representando um sistema portátil de áudio
De maneira geral o diagrama de blocos (Block Definition Diagram) pode apresentar
todos os elementos que compreendem o sistema, além dos usuários, redes inerentes ao
sistema, software, e requisitos.
INTERNAL BLOCK DIAGRAM
As definições de modelos e diagramas de estrutura de cada bloco previamente
definido no diagrama de blocos podem ser detalhados por meio de diagrama interno de blocos
(Block Internal Diagram) ou BID. Os elementos que compõem o BID são similares ao
Diagrama de Blocos, restringindo apenas alguns tipos de associações entre os elementos.
A Figura A2.3 apresenta um exemplo de Internal Block Diagram para um dos blocos
do Block Definition Diagram da Figura A2.2 (diagrama “pai”). Nota-se que os elementos
relativos ao bloco “pai” são herdados para o diagrama interno, tais como portas e definições
de atributos, operações e mensagens.
bdd [SysML Block Definition] Design Model [Design Model]
«block»Player Portáv el de
Audio
«block»subsistema
potencia
«block»Subsistema de processamento
«block»Interface com o
usuário
«block»subsistema de
transporte
«block»Panasonic Li-Ion
CG18650AF
«block»Unidade de recarga - ADP2291
«block»Mmonitoramento de
carga - AD7230
«block»RS232
«block»USB -PL2528
«block»Procesador
TM5320VC5507
«block»Codec com
amplificador - TLV320AIC3107
«block»Memoria
MT42L32M64D2KH-25
«block»Touch screen
«block»Botôes
btntcscmemoria
codec
monitoramento
recargabateria cpu utrrstr
transporteinterfaceprocessamentopotência
177
Figura A2.2: Diagrama interno de blocos do sistema portátil de áudio (SPARX-SYSTEMS, 2011)
Nesse exemplo, o diagrama (Figura A2.2) é detalhado mostrando-se como cada
subsistema é estruturado. Esse diagrama também descreve as relações entre as partes, que
descreve como elas estão funcionalmente ligadas umas as outras - por exemplo, A CPU,
Memória e CoDec (Codificador/Decodificador) estão juntos no subsistema de processamento.
PACKAGE DIAGRAM
Pacotes (packages) são utilizados para agrupar blocos ou outros elementos sobre um
controle único denominado namespace. É bastante utilizado no agrupamento de blocos
relacionados, podendo ser apresentados sobre um nível mais elevado dos diagramas do
projeto. À medida que um sistema complexo denota uma quantidade muito grande de blocos,
os chamados packages são bastante versáteis na organização do projeto, sendo válido também
para promover o reuso dos elementos de modelagem. Podem ser apresentados também como
um sistema ou subsistema, organizando em cada package um conjunto de todos os blocos
ibd [SysML Internal Block] Player Portáv el de Audi o [TheSystem]
proc : Subsistema de processamento
cpu : ProcesadorTM5320VC5507
mem : MemoriaMT42L32M64D2KH-25
codec : Codec comamplificador -
TLV320AIC3107
pwr : subsistema potencia
tr : subsistema de transporte
ui : Interface com o usuário
pmon :Mmonitoramento de
carga - AD7230
bat : PanasonicLi-Ion CG18650AF
: Unidade derecarga - ADP2291
tcsc : Touch screen btn : Botôes
pwr-tr
bat-proc
ui-pwr
tr-proc
proc-ui
178
relativos ao mesmo. Na Figura A2.3 apresenta-se um diagrama de pacotes em que são
mostrados elementos utilizados e organizados em pacotes dos diagramas apresentados
anteriormente (Modelo do Sistema). Ao mesmo tempo, representa-se que requisitos e
restrições são usados aliados ao um modelo operacional (Modelo Operacional) para a
definição do sistema mencionado anteriormente.
Figura A2.3: Exemplo de Diagrama de Pacotes
USE CASE DIAGRAM
O Use Case Diagram descreve o uso de um sistema do ponto de vista dos atores
(entidades com as quais o sistema interage) e as funcionalidades requeridas por esses atores
ao sistema. Ao fornecer essas funcionalidades aos atores, o sistema cumpre em parte, sua
pkg [Package] Systems Engineering Model [package_d iagram]
Requisitos
+ Requirement 1
+ Requirement 2
(from Requirements Model)
Restrições
+ Constraint 1
(from Requirements Model)
Modelo do Sistema
+ Bateria
+ Botôes
+ Codec com amplificador - TLV320AIC3107
+ Interface com o usuário
+ Memoria MT42L32M64D2KH-25
+ Mmonitoramento de carga - AD7230
+ Panasonic Li-Ion CG18650AF
+ Procesador TM5320VC5507
+ RS232
+ Subsistema de processamento
+ subsistema de transporte
+ subsistema potencia
+ Touch screen
+ Unidade de recarga - ADP2291
+ USB -PL2528
+ Player Portável de Audio
Modelo Operacional
+ OperatingDomain
«use» «use» «use»
179
missão, pois ele agora tem funções que atendem os atores e possivelmente alguns
stakeholders.
O exemplo da Figura A2.4 representa alguns casos (funcionalidades) requeridos por
um consumidor de livros que realizar compras com o auxilio de um sistema de busca na
internet. No exemplo o consumidor precisa navegar no catalogo eletrônico de livros, localizar
aquele que mais lhe agrada e quando for o caso requisitar livros não listados no acervo.
Figura A2.4: Diagrama de Casos de Uso (SPARX-SYSTEMS, 2011)
DIAGRAMA DE REQUISITOS ( REQUIREMENT DIAGRAM)
O diagrama de requisitos (Requirement Diagram) apresenta as relações entre os
diversos requisitos existentes de um sistema. Estas relações podem ser utilizadas para
decomposições ou para a rastreabilidade dos requisitos do sistema. Este diagrama proporciona
ao analista de sistemas um controle da derivação e rastreabilidade dos requisitos, conforme
uc [Use Case] Use Cases [Use Cases]
Nav egar em catologo eletronico de liv ros
localizar liv ros
Consumidor
Requisitar liv ro não listado
180
ilustrado na Figura A2.5. Por meio deste diagrama é possível estabelecer regras de
manipulação dos requisitos e apresentação deles de forma integrada.
Figura A2.5: Exemplo de Diagrama de requisitos SysML.
As relações presentes no Diagrama de requisitos são agrupadas em relações de
dependência, tais como cópia, satisfação, derivação, verificação e refinamento, onde cada
uma delas possui características específicas, mostradas no Quadro A2.5.
Quadro A2.5: Relações entre requisitos segundo a linguagem SysML (OBJECT
MANAGEMENT GROUP, 2010)
Relações Características
Derivação Organiza os requisitos numa hierarquia mostrando qual requisito derivou outro. Consequentemente, se o requisito “pai” é modificado, o requisito “filho” no mínimo precisa ser reavaliado.
Cópia Ilustra a relação entre o requisito de um fornecedor e uma cópia criada no cliente, cuja cópia é do tipo read-only. Criando um ambiente de compartilhamento de requisitos.
Satisfação Ilustra a relação entre um requisito e um elemento de modelo que preenche o requisito
Verificação Ilustra a relação entre um requisito e um caso de teste que determina se o sistema obedece ou não ao requisito
Refinamento São todas as relações cujos requisitos têm adicionados mais informações a partir da base de um requisito.
req [SysML Requirements] Specifications [Specifica tions]
REQ011-Gerenciar contas de usuários
REQ019-Acesso seguro
REQ016- Adcionar usuários
REQ017- Remover usuário
REQ021-Armazenar detalhes dos usuários
REQ018-Relatorio na conta do usuário
REQ022-Validar usuário
181
A3 ROTEIRO DAS ENTREVISTAS
1. Objetivo
Obter a confirmação dos usuários sobre a representatividade dos modelos de
processo desenvolvidos. Ainda, procura-se com esse questionário coletar informações sobre
os processos representados nele, tais como, potenciais problemas para a execução dos
processos, sugestões de melhorias e o impacto nos processos desses problemas.
2. Justificativa
Atualmente, o autor trabalha na área onde foi realizada a demonstração do
método. Devido a isso, optou-se por buscar informações muitas vezes de forma não
estruturada para construção da modelagem de processos aproveitando-se da dinâmica do dia
para observar, in loco, como os processos são executados. Contudo, era necessária uma
verificação final acerca dos modelos de processos construídos e obter uma confirmação de
que a modelagem realizada representa de fato aquilo que é executado.
3. Perguntas que direcionaram a entrevistas
1. Você enxerga o que você faz no seu dia a dia neste mapa de processo? Obs: mostrar o mapa desenvolvido nesse momento explicando como os processos acontecem.
2. Gostaria de acrescentar algum aspecto que o mapa de processo não contempla
atualmente?
3. Qual a sua maior preocupação para executar o seu trabalho?
4. Por quê? Qual o impacto disso na execução do seu trabalho?
5. Qual é a sua sugestão para resolver essa situação?
182
4. Entrevistados (alguns stakeholders do processo)
O conjunto de indivíduos que participaram dessa pesquisa são todos os indivíduos
que participam diretamente dos processos estudados. Eles são apresentado no Quadro A2.1.
Quadro A2.1: Descrição dos entrevistados durante a demonstração do método
Entrevistados Idade (Anos)
Experiência (Anos)
Formação
Designer 45 7 Design
Designer 30 3 Design
Engenheiro de produto 33 8 Engenharia Mecânica
Projetistas de moldes 55 30 Engenharia Mecânica
Planejador de processos de manufatura
50 20 Engenharia Mecânica
Programador CAM 40 20 Engenharia Mecânica
FOLHA DE REGISTRO DO DOCUMENTO
1. CLASSIFICAÇÃO/TIPO
TD
2. DATA
07 de novembro de 2011
3. REGISTRO N°
DCTA/ITA/TD-044/2011
4. N° DE PÁGINAS
182 5. TÍTULO E SUBTÍTULO: Proposta de um método para definição de requisitos de sistemas PLM (Product Lifecycle Management)
6. AUTOR(ES):
Alex Sandro de Araujo Silva 7. INSTITUIÇÃO(ÕES)/ÓRGÃO(S) INTERNO(S)/DIVISÃO(ÕES): Instituto Tecnológico de Aeronáutica – ITA 8. PALAVRAS-CHAVE SUGERIDAS PELO AUTOR:
Product Lifecycle Management, Requisitos. Ciclo de vida do produto 9.PALAVRAS-CHAVE RESULTANTES DE INDEXAÇÃO:
Administração de ciclo de vida de produto; Requisitos; Controle de processos; Organização de empresas; Administração; Engenharia de produção. 10. APRESENTAÇÃO: X Nacional Internacional
ITA, São José dos Campos. Curso de Doutorado. Programa de Pós-Graduação em Engenharia Aeronáutica e Mecânica. Área de Sistemas Aeroespaciais e Mecatrônica. Orientador: Luís Gonzaga Trabasso. Defesa em 13/07/2011. Publicada em 2011
11. 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.
12. GRAU DE SIGILO:
(X ) OSTENSIVO ( ) RESERVADO ( ) CONFIDENCIAL ( ) SECRETO