Portal de Conhecimentoshttp://www.portaldeconhecimentos.org.br/index.php/ RSS das Melhores Praticas do Portal de Conhecimentos. } ABC - Activity Based Costing http://www.portaldeconhecimentos.org.br/index.php/content/view/full9701
Introdução
O sistema ABC de custeio baseado em atividades, é uma nova ferramenta empresarial que tem como objetivos principais medir e melhorar as atividades que compõem os processos de negócios e calcular com precisão os custos dos produtos.Uma empresa, representada por uma sucessão de processo de negócio, que utiliza o sistema de custeio baseado em atividades, consegue identificar quais os recursos e as atividades consumidas por cada produto da empresa, conseguindo alocar de forma coerente os custos indiretos consumidos por cada produto.Esta é uma tentativa de suprir falhas do sistema de custeio tradicional das despesas indiretas, que utiliza o critério de rateio baseado na mão de obra direta, ou nos materiais diretos, entre outros, propiciando o aparecimento de distorções. Esta técnica foi muito útil no passado, quando os custos indiretos (overhead) não ultrapassavam 10% dos custos totais. Atualmente, entretanto, os custos indiretos podem representar até 70% dos custos totais, enquanto que a participação de mão de obra direta reduziu-se sensivelmente, chegando em alguns casos de empresas muito automatizadas, com não mais do que 5% dos custos totais de fabricação. O ABC (Activity Based Costing) determina que atividades consomem os recursos da empresa, agregando-as em centros de custos por atividades. Em seguida, e para cada um desses centros de atividades, atribui custos aos produtos baseado em seu consumo de recursos. Com isso, é possível se determinar quais são os produtos subcusteados e quais são os supercusteados, possibilitando uma melhoria nas decisões gerenciais.O ABC permite ainda que se tome ações para o melhoramento contínuo das tarefas de redução dos custos de overhead, como a melhora dos serviços, avaliação das iniciativas de qualidade, corte de desperdícios, aprimoramento dos processos de negócio da empresa, entre outros.
Artigos
COOPER, R. (1990). “Implementing an activity based cost system”. Journal of cost management, Spring.
Livros
COGAN , S. (1994). Activity based costing (ABC) : a poderosa estratégia empresarial. São Paulo : Pioneira. (Disponível na biblioteca FEA -USP). NAKAGAWA, M. (1991). Gestão estratégica de custos: conceitos, sistemas e implementação. São Paulo: Atlas. (Disponível na biblioteca EP - USP ).
Análise de Valores http://www.portaldeconhecimentos.org.br/index.php/content/view/full9511
Contexto histórico e conceitos
A técnica de Análise de Valores / Engenharia de Valores (AV/EV) é um esforço organizado para atingir o valor ótimo de um produto, sistema ou serviço, promovendo as funções necessárias ao menor custo. Seu surgimento está ligado a pesquisa de novos materiais, de mais baixo custo e mais fácil obtenção, substituindo os materiais escassos devido a II Guerra Mundial. Esta pesquisa ocorreu na General Eletric nos EUA, sendo a técnica de AV/EV formalizada por Lawrence D. Miles em 1947. A análise do valor (AV) é utilizada para produtos já existentes, em fase de produção. A engenharia do valor (EV) é utilizada para projetos e produtos na fase de desenvolvimento. A AV/EV aplica-se portanto em todas as fases do ciclo do produto. Melhores resultados são obtidos quando a metodologia é aplicada aos novos produtos já na fase introdutória, onde os custos de mudanças implementadas são menores e o potencial dos resultados é bastante alto.
Base teórica
A sustentação da AV/EV está consolidada basicamente em quatro áreas, conforme descrito a seguir: -Especialização: reúne e confronta todos os conhecimentos especializados e habilidades disponíveis na organização; -Criatividade: o processo criativo é um processo mental, no qual se combinam e se recombinam as experiências passadas, frequentemente com algumas distorções para formar novas combinações procuradas. Em AV/EV, os processos criativos são dirigidos a redução do custo necessário à realização de uma função, mantendo-se sua confiabilidade. Dentre os vários métodos utilizados para direcionar o processo criativo, em AV/EV o Brainstorming é o mais recomendado; -Reconhecimento e contorno dos Bloqueios Mentais: que podem ser de percepção - "bitolamento" de visão, culturais - tendem a manter o normalmente aceito, emotivos - medo das consequências, e de hábito - oposição às mudanças de costumes; -Análise das funções: o valor propriamente dito é a relação entre o que desempenha a função para um comprador e o seu preço. O conteúdo base de qualquer aplicação da técnica de AV/EV envolve três etapas distintas: estabelecimento das funções, avaliação da função por comparação e desenvolvimento de alternativas para o valor. Pode-se classificar o valor em: funcional - ligado ao desempenho; estético - ligado a vendabilidade; troca - ligado a soma dos dois anteriores. A classificação das funções podem ser: básica - finalidade específica para a qual o ítem foi projetado, secundária - suportam a ação básica e não-necessária - que devem ser eliminadas. As funções são necessariamente avaliadas por comparação. Como primeiro passo para a avaliação de funções deve-se relacionar os componentes, seus custos e suas funções. Para proceder a um estudo de AV/EV, temos inicialmente que seguir alguns critérios que permitam selecionar o produto ou operação adequadas ou viáveis a aplicação da técnica. Estes critérios referem-se a: maior a quantidade a ser produzida, mais pesa o produto no valor bruto produzido, maior o custo de um componente, mais cara a operação de uma sequência dada, vida prevista do produto viabiliza o estudo, modificações resultantes são viáveis. Outro aspecto a ser considerado para proceder-se um estudo de AV/EV refere-se a fase do produto que deve-se aplicar. O ideal seria a utilização de 50% dos esforços dispendidos em EV aplicados na fase de projeto do produto, 40% na fase de preparação para a produção e, finalmente, 10% na própria produção.
Procedimento de realização da AV/EV
Um plano de trabalho viável e consistente é fundamental para a execução da técnica de AV/EV. As etapas seguintes fazem parte da grande maioria dos planos de trabalho existentes: a) fase de orientação: objetivo, desejos reais do consumidor, características e propriedades desejadas, etc. b) fase de informação: coleta de todos os dados e informações disponíveis, as funções devem ser estabelecidas e definidas, avaliação de cada função por comparação. c) fase criativa: determinação de como o custo do produto ou operação poderá ser reduzido para o valor avaliado, por eliminação de funções desnecessárias ou substituição de ítens ou operações. É comum o uso do brainstorming nesta fase. d) fase de análise: as idéias são analisadas e para cada uma escreve-se a resposta adequada, do que falta para funcionar, e não porque é que não funciona. Nesta fase são consideradas alternativas como comprar ou fazer, seleção do processo e do material e problemas de produção. e) fase de planejamento do programa: será planejada a execução do trabalho. Uma sugestão é dividir o projeto em áreas funcionais, facilitando a análise por especialistas. Deve ser feita uma programação para as atividades, considerando-se os tempos e custos envolvidos. f) fase de execução do programa: acompanhamento dos resultados e consequente ajustagem do programa em função do andamento. g) fase final com conclusões e relatório: o processo decisório é de importância capital. Vários elementos devem ser levados em conta: o elemento do conflito, do tempo, do acaso e da estratégia. A utilização de técnicas para a tomada de decisão, como por exemplo a "matriz de decisão" é recomendável. O relatório é fundamental como registro de estudo.
Considerações finais
Para a implementação das idéias de AV/EV, é necessário que uma infra-estrutura seja criada o que por si só garantirá uma série de benefícios para a organização da empresa. Além disso, com a redução dos custos há uma economia real e quantificável obtida após a aplicação. Pontos em que estes benefícios são facilmente notados: material, processo, peças normalizadas, número de componentes, peso, custo de documentação, ferramental, tempo total entre emissão da ordem e entrega do produto. Há uma grande multiplicidade dos planos de trabalho existentes. o sucesso a ser conseguido está diretamente relacionado com a lealdade e entusiamo inspirado nos outros, bem como motivação e incentivo para as pessoas envolvidas. Deve ser salientado a diferença entre AV/EV e técnicas de redução de custos. A AV/EV constitui um esforço deliberado para identificar e selecionar o método de menor custo, entre muitos outros, para satisfazer as necessidades funcionais adequadas. Uma simples idéia que é gerada resultando num menor custo para atingir um requisito de projeto não é AV/EV. Embora a idéia represente provavelmente melhor valor, não houve tentativa para determinar se a idéia representa o melhor valor de um seleção de alternativas, ou se os requisitos de projeto, sendo satisfeitos, representam o real problema.
Livros
BASSO, J. L. (1991). Engenharia e Análise do Valor. São Paulo: IMAM. ( Disponível na biblioteca da EESC - USP ). COLENCI JR, A. (1989). Análise e Engenharia de Valor. São Carlos. /Relatório técnico EESC-USP/. ( Disponível na biblioteca da EESC - USP ). CSILLAG, J. M. (1991). Análise do Valor: metodologia do valor. 3.ed. São Paulo: Ed. Atlas. ( Disponível na biblioteca da EP - USP ).
Sites Relacionados
Value Analysis and Function Analysis System Technique (1996) - DRM Associates. http://members.aol.com/drmassoc/va.html SAVE International (1999). http://www.value-eng.com/ Value Analysis by Theodore C. Fowler (1994). http://mijuno.larc.nasa.gov/dfc/va.html Value Engineering from the Perspective of Competitive Advantage by Edwin B. Dean (1997). http://mijuno.larc.nasa.gov/dfc/ve.html Portal de Conhecimentos - www.portaldeconhecimentos.org.br
Análise de Viabilidade Econômica http://www.portaldeconhecimentos.org.br/index.php/content/view/full9502
Introdução dessa página
Analisar a viabilidade econômica-financeira de um projeto significa estimar e analisar as perspectivas de desempenho financeiro do produto resultante do projeto. Essa análise é de certa forma iniciada na própria definição do portfólio, na fase de Planejamento Estratégico do Produto (PEP), pois, ao escolher um dos produtos para ser desenvolvido, acredita-se, que com os dados disponíveis até então, na viabilidade econômica-financeira de seu projeto. A estimativa de orçamentos para o projeto, resultante da atividade anterior, serve para trazer uma estimativa dos níveis de preço final do produto, que o tornaria viável e cobriria os custos envolvidos.
Fontes
Os conceitos e definições utilizados na criação desta análise, em grande parte, foram elaborados a partir do livro “Gestão de Desenvolvimento de Produtos: Uma referencia para a melhoria do processo.” do Prof. Henrique Rozenfeld. Outros conceitos e métodos de análise econômica-financeira utilizados foram retirados de artigos e livros relacionados à engenharia econômica. [1]Gestão agroindustrial: GEPAI: Grupo de estudos e pesquisas agroindustriais/ coordenador Mário Otávio Batalha. - vol.2 - 3. ed. - São Paulo: Atlas, 2001 [2]MARTINOVICH, M. Como gerenciar o capital de giro. Agenda do Empresário. São Paulo, nO 11, p. 1-6, 1996.
Definições
Na presente atividade do Planejamento do Projeto, são definidos os principais indicadores financeiros do projeto relacionados com o produto final, tais como o custo-alvo do produto, as previsões de retorno do investimento e a análise de suas características, o Valor Presente Líquido – VPL, a Taxa Interna de Retorno – TIR, Método do payback e o Fluxo de Caixa esperado com o novo produto. Essa análise da viabilidade econômica-financeira realizada durante o Planejamento do Projeto é a referencia inicial para as fases seguintes, no desenvolvimento do produto propriamente dito, torna-se um dos critérios mais importantes para se manter a decisão de executar o projeto. Existe a necessidade de uma revisão periódica dessa analise ao longo do projeto, pois na atividade de Planejamento do Projeto, estão disponíveis apenas informações preliminares, e, portanto, passives de mudanças, sobre o ambiente em que o produto irá ser inserido. À medida que as fases do desenvolvimento vão ocorrendo, aproximam-se as condições reais do momento de lançamento do produto, e, portanto, vão aumentando as certezas quanto as características que o produto deve adotar, sua atividade e receptividade no mercado, as condições desse mercado (concorrência efetiva, surgimento de novas tendências, mudanças econômicas etc), e sua relação quanto a preço/volume. Sendo assim, a análise de viabilidade econômica-financeira pode ser refinada e confrontada com a inicialmente planejada, para efeitos de aprendizado quanto à capacidade de previsão no início de um projeto de DP. Essa revisão da viabilidade econômica-financeira ocorre ao final de cada uma das fases do desenvolvimento do produto, juntamente ou não aos gates. Pode também ocorrer a qualquer momento, quando grandes modificações endógenas ou exógenas ao projeto assim demandarem, para se verificar se o produto continuará financeiramente viável ou não.
Mecanismos
O principal elemento que justifica a existência de uma empresa é a geração de lucro. Para os investidores, porém, não basta que o projeto tenha um resultado positivo. Para um projeto de desenvolvimento ser atrativo, é preciso que a quantidade de lucro gerado, o retorno do projeto, seja melhor do que aquele que a empresa poderia obter com outros investimentos, por exemplo, aplicando no mercado financeiro. Portanto, a essência da avaliação econômico-financeira é medir o retorno do projeto de maneira comparável com outros investimentos. O primeiro passo para a realização da análise econômica é a montagem do fluxo de caixa, isto é, a definição do fluxo de entradas e saídas de dinheiro durante o ciclo de vida planejado para o produto.
Fluxo de Caixa
De acordo com Martinovich, fluxo de caixa é um instrumento gerencial fundamental na tomada de decisões empresariais. Seus objetivos são a coleta e a organização dos dados e a geração de subsídios, para a análise de desempenho financeiro e para a realização de previsões orçamentárias. Os três componentes principais de um fluxo de caixa são:
Investimento no novo produto:
Corresponde aos gastos necessários para a geração de benefícios a longo prazo. É a quantidade de dinheiro gasta para o desenvolvimento das especificações e preparação para a produção do produto. Para determinar os gastos com o investimento devem-se levar em consideração alguns fatores:
  • Tipo de Projeto: Dependendo do tipo de projeto o investimento pode ser maior ou menor. Ex.: Em projetos incrementais o investimento necessário deve ser menor que o necessário em projetos radicais, pois criam produtos e processos que são derivados, híbridos ou com pequenas modificações em relação aos projetos já existentes. Já os projetos radicais envolvem significativas modificações no produto ou processo já existente, podendo requisitar novas tecnologias e materiais.
  • Disponibilidade de Recursos: São os gastos para adquirir recursos, como: pessoas, máquinas, equipamentos, veículos, utensílios, computadores etc;
  • Necessidades de adquirir: patentes, tecnologias e licenças;
  • Gastos com estudos, pesquisas de mercado, projetos e capacitação de profissionais;
  • Necessidade de possuir um capital de giro, inclusive para eventuais imprevistos.
Uma forma de calcular o investimento é criar uma conta específica para cada projeto, da qual sairiam todos os pagamentos e gastos efetuados. O maior desafio é computar o custo de pessoa, principalmente para os membros do time que dividem seu tempo entre vários projetos. É preciso também definir claramente o momento em que os custos e receitas serão calculados. Geralmente, esse momento é o final da aprovação do lote piloto, pois, a partir desse momento, os produtos produzidos pela linha poderão ser comercializados dando início aos dois outros componentes do fluxo de caixa, as receitas e os custos e despesas de produção.
Receitas:
Corresponde a estimativa de venda de produtos e subprodutos gerados pela produção. Para o cálculo dessa estimativa deve-se levar em consideração fatores como: preço final e demanda dos produtos.
  • Preço final do produto: Esse valor vai depender do mercado, no qual se deseja vender o produto, do produto produzido, e do lucro esperado pelo fabricante.
  • Demanda dos produtos: Esse valor vai depender do produto (produtos com alto valor agregado geralmente possuem um volume de venda menor), do mercado e da fatia de mercado que esse produto almeja atingir, do preço de venda, da analise locacional e de mercado.
Para estimar a receita, é preciso estimar o valor da demanda dos produtos, em seguida, multiplicá-lo pelo preço final estimado. Além da receita gerada com as vendas outros fatores podem entrar na receita, como: subsídios governamentais, financiamentos e valor residual do investimento.
Custos e despesas de produção:
São os valores gastos diretamente e indiretamente para a produção e comercialização do produto. Os custos são os gastos com um bem ou serviços utilizados para a produção de outros bens. Os principais custos são os seguintes:
  • Matérias primas, embalagens, materiais auxiliares;
  • Mão-de-obra direta;
  • Consumo de energia elétrica, de água e de combustível;
  • Manutenção, seguros, aluguéis, diversos.
As despesas são os gastos como um bem ou serviços utilizados para obtenção de receita. As principais despesas são:
  • Despesas com vendas, financeiras e administrativas;
  • Salários do pessoal administrativos;
  • Impostos e taxas municipais.
Convém diferenciar custos e despesas de produção bem dos investimentos, o que muitas vezes pode ser difícil. Por exemplo, os gastos de uma operação na produção que visa produzir uma peça do protótipo é investimento. O gasto da mesma operação em uma peça idêntica, após a liberação do lote piloto, que será comercializada deve ser já apropriada como custo direto, a ser contabilizado naquele produto específico. O intervalo para o cálculo do Fluxo de Caixa depende da duração do ciclo de vida do produto. Um produto industrial em geral é planejado para ficar alguns anos no mercado e, por isso, o período utilizado é normalmente anual. Calculados esses valores, eles serão somados, obtendo-se um valor final do fluxo de dinheiro esperado na empresa, conforme apresentado no Gráfico 1, a seguir. Gráfico 1 – Exemplo de Fluxo de Caixa.
Indicadores Financeiros
O Gráfico 1 representa uma previsão do montante de dinheiro que entrará ou sairá da empresa em cada um dos períodos (no caso anos) do ciclo de vida do produto. Para sabermos se esse projeto é viável ou não economicamente, precisamos avaliar e comparar esse fluxo com outros investimentos à disposição do dono da empresa. Nesse cálculo, deve-se levar em consideração que o dinheiro possui um valor dependente do tempo, isto é, receber R$500,00 hoje é diferente do que receber esse mesmo valor no próximo ano. Portanto, utilizam-se índices financeiros e parâmetros calculados com os dados do fluxo de caixa que permitem comparações e análises do desempenho financeiro do projeto. A seguir são apresentados três dos indicadores financeiros mais utilizados em projetos de desenvolvimento de produtos.
Valor Presente Líquido - VPL
Método para análise de investimentos que determina o valor presente de pagamentos futuros. Este método consiste em uma fórmula matemático-financeira em que o valor dos investimentos e do fluxo de caixa atual e futuro são convertidos para um valor equivalente na data atual por meio de uma taxa de conversão. Esta conversão é devido ao fato do poder aquisitivo do dinheiro sofrer alterações com o passar do tempo. A taxa de conversão utilizada neste método é a Taxa Mínima de Atratividade (TMA). A figura 1 apresenta a fórmula para o cálculo do VPL. Figura 1 – Fórmula do VPL. O Valor Presente Líquido de um projeto de investimento possui as seguintes possibilidades de resultado:
  • Maior do que zero: significa que o investimento é economicamente atrativo, pois o valor presente das entradas de caixa é maior do que o valor presente das saídas de caixa.
  • Igual a zero: o investimento é indiferente, pois o valor presente das entradas de caixa é igual ao valor presente das saídas de caixa.
  • Menor do que zero: indica que o investimento não é economicamente atrativo porque o valor presente das entradas de caixa é menor do que o valor presente das saídas de caixa.
Entre vários projetos, o mais atrativo é aquele que tem maior Valor Presente Líquido.
Taxa Interna de Retorno - TIR
Estabelece a taxa econômica necessária para igualar o valor de um investimento com seus retornos futuros. Significa a taxa de remuneração que deve ser fornecido pelo projeto de modo que este iguale o seu investimento, após um período. A TIR é calculada utilizando-se a mesma fórmula descrita anteriormente, porém igualando-se o VPL a zero e utilizando a TIR como incógnita de taxa de conversão. Posteriormente a TIR é comparado com a TMA da empresa para verificar o desempenho do projeto, podendo ser:
  • Maior do que a TMA: significa que o investimento é economicamente atrativo.
  • Igual à TMA: o investimento está economicamente numa situação de indiferença.
  • Menor do que a TMA: o investimento não é economicamente atrativo, pois seu retorno é superado pelo retorno de um investimento sem risco.
Entre vários investimentos, o melhor será aquele que tiver a maior TIR.
Método do Payback
O payback é um dos métodos mais simples e, talvez por isso, de utilização muito difundida. Consiste, essencialmente, em determinar o número de períodos necessários para recuperar o capital investido. Tendo essa avaliação, a administração da empresa, com base em seus padrões de tempo para recuperação do investimento, no tempo de vida esperado do ativo, nos riscos associados e em sua posição financeira, decide pela aceitação ou rejeição do projeto. A forma mais fácil de calculá-lo é simplesmente acumulando as entradas e saídas e determinando o período em que houve a transição de um valor positivo para negativo.
Recomendações para análise de viabilidade econômica
Cada um dos indicadores financeiros resulta em informações diferentes, que podem ser utilizados de maneira complementar. O VPL é um método que fornece uma boa noção do montante que será obtido com o projeto, isto é, o valor que será captado, porém, ele não permite uma comparação fácil com outros investimentos. Esse aspecto é grande vantagem da informação obtida na TIR, que fornece um valor facilmente comparável. Mas existem projetos que retornam um bom montante (VPL altamente positivo) e rentáveis (TIR acima da taxa de atratividade) mas cujo período de retorno de investimento é longo, significando que a empresa terá de amargar um bom período de prejuízo até a obtenção do lucro. Portanto, sugerimos o cálculo desses três indicadores. É importante destacar que todos os métodos anteriormente citados dependem de estimativas: da demanda do produto pelo mercado, sua expectativa de crescimento, do preço de venda do produto aceito pelo consumidor final, dos custos envolvidos na produção do produto, sendo essencial a participação e o comprometimento de diferentes partes da organização, principalmente do marketing, engenharias e vendas.
Lições aprendidas
Premissas para o cálculo da viabilidade A definição das premissas é o ponto mais estratégico para se realizar a análise de viabilidade. As premissas englobam as previsões da demanda futura no tempo; o preço de se conseguirá praticar; o custo resultante da operação e basicamente as taxas que servirão de referência no futuro. Não é fácil prever todas essas informações e por isso são consideradas premissas para a análise. Calcular o fluxo de caixa depois de todas essas definições “é mais fácil”. Monitorar a viabilidade durante o desenvolvimento do produto A análise da viabilidade econômica normalmente é realizada no início do desenvolvimento de produto e raramente é “revisitada”. Não tem sentido financeiro recalcular o investimento, pois o dinheiro gasto não volta mais. Porém, uma simulação de toda a análise, ajustando as premissas e verificando de novo os indicadores pode fornecer uma visão de quanto a empresa “acerta” nas suas previsões. Monitorar a análise de viabilidade é importante para se tomar decisões (por exemplo, nos Gates) durante o desenvolvimento para saber se aquele produto / serviço ainda é viável ou não diante de possíveis mudanças das premissas (concorrente lançou algo similar primeiro e os volumes de venda não serão os mesmos; crises financeiras; mudanças nas taxas de referência; etc). Ponderar a análise com possíveis riscos Quando realizamos uma análise de viabilidade, partimos do pressuposto que todas as premissas adotadas estão corretas. Porém, existem riscos que vão além dessas premissas. Basicamente pode-se agrupar os riscos em duas categorias: riscos tecnológicos e riscos mercadológicos. Os riscos da primeira categoria tratam de questões associadas à probabilidade de sucesso (ou fracasso) da tecnologia e soluções adotadas. Isso é mais importante de ser analisado no caso de inovação em tecnologia. Os riscos mercadológicos consideram o sucesso (ou fracasso) que um produto / serviço pode ter no mercado. Deve-se portanto ponderar esses riscos, assim como as premissas quando se realiza a análise de viabilidade dos projetos de desenvolvimento. Ou seja, aquele VPL calculado (por exemplo) só daria certo se existir riscos baixos. Imagine a comparação de dois projetos de desenvolvimento. O primeiro com um VPL alto e o outro com VPL baixo. Qual deve ser priorizado? Depende do risco também. Se a probabilidade de sucesso do segundo for muito maior do que o primeiro, em uma análise de balanceamento do portfólio de projetos de desenvolvimento, pode ser que a segunda opção seja priorizada. Veja para isso a melhor prática sobre gestão de portfólio e consulte também a dissertação que trata da aplicação de opções reais para gestão do desenvolvimento de produto.
Novas contribuições para essa página são bem vindas
Apredizagem Organizacional http://www.portaldeconhecimentos.org.br/index.php/content/view/full9947
Introdução
A aprendizagem organizacional é um tema já bem conhecido nas disciplinas de organização. É um fenômeno sistêmico nas empresas que permanece independente das pessoas. Sim, as organizações podem não ter cérebro, mas são dotadas de sistemas cognitivos que elas mesmo desenvolvem e vão sendo impregnados na sua cultura por meio, principalmente, de rotinas ou procedimentos .Apesar de alguns autores fazerem distinção entre organização de aprendizagem e aprendizagem organizacional, parece bastante razoável analisar e estudar o tema como um único contexto. O que é claro é que a aprendizagem organizacional é uma característica da organização de aprendizagem (a organização que aprende). Neste breve texto, será utilizado o termo organização de aprendizagem para que possa ficar claro que a algumas habilidades típicas da aprendizagem organizacional não garantem por si que uma empresa é uma organização de aprendizagem. Por exemplo: a habilidade "resolução sistemática de problemas" é uma característica das empresas que aprendem. Mas, se o aprendizado baseado na solução de problemas (que é um aprendizado defensivo - aprender como interromper o que não queremos) não for autogerador, ou seja, for gerado somente pelos problemas, ou o aprendido é limitado a como eliminar as situações indesejáveis, a organização não pode ser uma organização de aprendizagem. A época de aprender não é somente quando existem crises. Organização de aprendizagem é por si um conceito, muito mais próximo da filosofia que das técnicas, não podendo ser tratada como uma abordagem para melhorar as empresas. É um conceito que vem sendo desenvolvido há mais de 50 anos e requer a conscientização de que não existe fim, pois a ação e a reação advindas das mudanças externas ou internas, ocorridas no ambiente ou no indivíduo, fazem parte do processo de aprendizagem. Apesar de já ser "antiga" a noção de organização de aprendizagem foi popularizada a partir do livro de Peter Senge, A Quinta disciplina. Desde então, se tornou um conceito mais difundido e uma proposição interessante. O seu principal conteúdo invoca a imagem de pessoas e grupos trabalhando para melhorar a inteligência, a criatividade e a capacidade organizacional. Para isso, segundo Peter Senge, as organizações devem desenvolver cinco disciplinas para continuamente estarem em processo de aprendizagem: maestria pessoal, relacionada com o autoconhecimento; modelos mentais, que trata de imagens que influenciam o modo como as pessoas vêem o mundo; objetivos comuns, aborda as questões relacionadas à clareza e compartilhamento de objetivos; aprendizado em grupo, relacionada ao desenvolvimento de habilidades coletivas e de ações coordenadas; e pensamento sistêmico, um modelo conceitual, formado por um conjunto de conhecimentos ferramentas, que buscam o aperfeiçoamento do processo de aprendizagem como um todo. Na manufatura, as empresas continuamente aplicam ferramentas que facilitam o aprendizado ou mesmo desenvolvem mecanismos de aprendizagem a cada dia. Por exemplo no processo de desenvolvimento de produtos, a necessidade cada vez mais crescente do "aprender antes de fazer", incentivando o uso de ferramentas computacionais mais sofisticadas. Isso requer uma forte ligação com uma base de dados composta não somente por informações mais tradicionais, mas também por conhecimentos gerados, de forma dinâmica, no processo de aprendizagem. Se as empresas vêem desenvolvendo sua capacidade de aprender, por que é tão difícil ser uma organização de aprendizagem? É muito difícil fazer um diagnóstico. Entretanto, algumas questões podem servir como ponto de partida para uma investigação mais detalhada:
  • Será que existe nas pessoas das empresas, além da consciência, a convicção de que é possível ser uma organização de aprendizagem?
  • Os líderes realmente facilitam o compartilhamento de objetivos?
  • As empresas acreditam que a melhor forma de aprender é "fazendo", desprezando outros recursos, como modelos mentais por exemplo?
  • Será que existe uma preocupação muito grande em melhorar o ambiente, por exemplo com a implantação de novos sistemas, novas abordagens de gestão ou ferramentas de engenharia e de fabricação, inibindo ou limitando ações que poderiam alavancar a disciplina de desenvolvimento do indivíduo (maestria pessoal)?
  • A gestão de conhecimento ou competências é feita de forma dinâmica? Ou seja, analisadas em um duplo sentido – saber quais competências e conhecimentos a empresa tem que permite alavancar novos negócios, e por outro lado, quais competências e conhecimentos são necessários desenvolver para atender ou acompanhar as mudanças atuais.
Algumas pesquisas estão sendo desenvolvidas, abordando a questão da aprendizagem organizacional. Algumas procuram descrever os mecanismos de aprendizagem existentes e praticados por empresas, enquanto outras buscam avaliar a capacidade de aprendizagem das organizações por meio da aplicação de questionários "quantificáveis". Também, outras formas de abordagem do tema são encontradas nos diversos centros que possuem grupos de pesquisa nessa área. Isso mostra que a questão é atraente e tem merecido atenção de grupos de pesquisadores e praticantes, principalmente devido à relação entre aprendizagem e capacidade competitiva.
Artigos
ARGYRIS, C.; (1991). Teaching smart people how to learn. Harvard Business Review , v.69, n.3, p. 99-109, May/Jun. (t: 808). FLEURY, A.; FLEURY, MTL.; (1997). Aprendizagem e inovação organizacional: as experiências de Japão, Coréia e Brasil. São Paulo: Atlas. ( Disponível na biblioteca da EESC ). GARVIN, D.A.; (1993). Building a learning organization. Harvard Business Review, Jul/Aug. (t861) KIM, D.; (1993). The link between individual and organizational learning. Sloan Management Review, Fall. MARQUARDT, M. J.; (1996), Building the learning organization. New York: McGraw-Hill. . SENGE, P. M. (1990). Quinta disciplina: arte, teoria e prática da organização de aprendizagem. 14. ed. São Paulo, Editora Best Seller. ( Disponível na biblioteca da FEA - USP ).
Sites Relacionados
MIT - Sloan Management School - THE SOCIETY FOR ORGANIZATIONAL LEARNING http://learning.mit.edu/ ALBANY UNIVERSITY – The learning organization homepage http://www.albany.edu PEGASUS COMMUNICATIONS INC. The Organizational Learning – Resource Library.www.pegasuscom.com STANFORD UNIVERSITY–SLOW– Stanford Learning Organization Webhttp://www.stanford.edu/group/SLOW The Systems ThikerÔ Editado pela Pegasus Communications, Inc. www.pegasuscom.com WOLFF GROUP INC. – http://www.wolff.com/
BOM (Bill of Material) http://www.portaldeconhecimentos.org.br/index.php/content/view/full9510
Importância da BOM
A BOM, ou estrutura de produto é uma das informações fundamentais da manufatura, pois nela registram-se as informações de produtos utilizadas por todos os setores e processos envolvidos com a manufatura do produto. Seu domínio é essencial para o sucesso da implantação de sistemas integrados. Apesar do desempenho desses sistemas estar vinculado à qualidade das informações que eles manipulam, a maioria das empresas não garante que suas informações fundamentais sejam completas e precisas. As informações fundamentais muitas vezes não são estruturadas e gerenciadas de acordo com o tipo de negócio e produto. A falta de qualidade das informações fundamentais tem sido resumida por meio da expressão “garbage in, garbage out”, ou seja, se os processos da empresa estão manipulando informações sem qualidade, consequentemente os resultados alcançados por esses processos também estarão comprometidos. A BOM é também um elemento que gera integração uma vez que suas informações são compartilhadas por quase todos os departamentos da empresa. Logo, a forma como é gerenciada, controlada e estruturada pode diretamente influenciar o sucesso da empresa. Uma empresa almeja ser de classe mundial deve possuir BOMs sólidas, representando os processos e produtos, em sintonia com as estratégias do negócio. É importante destacar ainda a importância da BOM como sendo o ponto mais comum para interface ou integração entre os sistemas ERP (Enterprise Resource Planning) e PDM (Product Data Management) e entre os sistemas ERP e CAD (Computer Aided Design) possibilitando assim o fluxo e a consistência das informações. Apesar da sua importância, GARWOOD (1995) afirma que a BOM tem sido o “calcanhar de Aquiles” da maioria das empresas de manufatura, as quais sempre esbarram nas seguintes questões: o meu produto tem diversos opcionais e alternativas, como conviver com o grande número de estruturas de produto necessárias? Como a estrutura de produto pode refletir diferentes estratégias de estoque? Como conviver com mais de uma estrutura de produto? Quem é o “dono” da estrutura de produto? Como simplificar a estrutura de produto? Como aumentar a precisão das informações?
Definição
Segundo definiu a AMERICAN PRODUCTION AND INVENTORY CONTROL SOCIETY (APICS), em 1992, a estrutura de produto (BOM - bill of material) é uma lista de todas as submontagens, componentes intermediários, matérias-primas e itens comprados que são utilizados na fabricação e/ou montagem de um produto, mostrando as relações de precedência e quantidade de cada item necessário. CLEMENT et al. (1992) acrescentam que, além desses objetos, a BOM também pode conter outros, tais como, instruções de trabalho ou ferramentas requeridas para suportar o processo de manufatura. Através da BOM é estabelecida uma relação pai/filho entre um item e seus componentes diretos.
Tipos de BOM e seus elementos
BOM simples / padrão (flattened / standard BOM)
A BOM mais simples possível é a de dois níveis, um com as matérias-primas e itens comprados, e outro com o produto final. A única razão para a criação de mais níveis são as necessidades do planejamento e controle da produção (PCP), como por exemplo a criação de submontagens ou itens intermediários que precisam ser estocados (GARWOOD, 1995). Uma BOM de vários níveis é a estrutura mais conhecida, também, chamada de BOM padrão.
Item fantasma e pseudo item e (phantoms and pseudo items)
Itens fantasmas são aqueles produzidos no processo de manufatura, possuindo “pais” definidos, porém não são tipicamente estocados. Apesar de existirem fisicamente, são rapidamente consumidos como componentes do item de nível imediatamente superior na BOM. Um pseudo item é um coleção artificial de componentes que são agrupados para propósitos de planejamento. Ao contrário dos itens fantasmas, entretanto, os componentes do pseudo item não podem ser manufaturados juntos para produzir um item pai que exista fisicamente. Por essa razão os pseudo itens nunca possuem inventário.
BOM Molular e de Planejamento (modular and planning BOM)
A modularidade é a capacidade de se construir um produto ou processo complexo a partir de subsistemas menores (chamados módulos), os quais podem ser projetados independentemente e ainda assim funcionar juntos como um todo. Se um produto possui muitas opções de escolha de itens, o número de combinações possíveis torna-se muito grande, dificultando a previsão de vendas e o planejamento mestre de produção de cada item final. Além disso, se for mantida uma BOM para cada configuração diferente do produto, o espaço requerido pode ser muito grande, envolvendo altos custos de armazenagem e manutenção. A solução para este problema é a utilização da BOM modular. Ao invés de se manter uma BOM para cada produto final possível dentro de uma família, são identificadas as opções para cada um dos seus componentes, as quais são organizadas em módulos. Essa análise deve ocorrer no nível de menor variação na configuração, reduzindo assim o número de itens manipulados na previsão de vendas e no planejamento mestre de produção. A BOM utilizada neste caso é considerada a BOM de planejamento, onde definem-se porcentagens de cada item de menor variação de configuração. Outra razão para utilizar a BOM modular acontece nos casos em que o lead time de manufatura é maior do que o lead time de entrega aceito pelo consumidor. Nesses casos, a modularização pode suportar a implantação da estratégia de estoque assemble-to-order, reduzindo o tempo entre a entrada do pedido do cliente e a entrega. A previsão de vendas é feita no nível dos módulos, os quais são fabricados e estocados. Quando ocorre um pedido do cliente, a configuração desejada é produzida utilizando-se os módulos previamente preparados.
BOM genérica (generic BOM)
A estrutura de produto genérica é uma aplicação do conceito de BOM modular para as atividades de vendas técnicas e controle de configurações, assim como a BOM de planejamento é uma aplicação para previsão de vendas e planejamento mestre da produção. Aplicações para a configuração de produtos são uma extensão natural do conceito de BOM modular. Ao invés de módulos predefinidos, com os usados na BOM modular, o configurador pode utilizar algoritmos, regras e condicionais para selecionar e calcular os componentes de um produto e seus requisitos de manufatura. Segundo VAN VEEN & WORTMANN (1987), assim como uma BOM específica descreve exatamente um produto, a BOM genérica descreve uma variedade de produtos (conceito de BOM modular). A BOM genérica não pode ser utilizada diretamente para propósitos de planejamento e manufatura. Ela é apenas um frame para a criação de BOMs específicas no momento necessário, geralmente durante a entrada do pedido do cliente.
BOM de manufatura (Manufacturing BOM)
BOM de manufatura representa a integração lógica da estrutura de produto e do plano de processo. A seqüência de operações é especificada e a cada operação são associados os itens necessários da BOM. A BOM de manufatura é usada como um guia para fabricação e montagem de um produto, sendo que seus níveis refletem o fluxo de produção e pontos de estoque.
Estrutura de Produto para Informação (Information Bill of Material)
As estruturas de produto para informação são relatórios padrões gerados pelos sistemas de informação para suportar análises diversas sobre a BOM e seus itens. Segundo GUESS (1985) e SCHLUSSEL (1995), os principais formatos de BOM para informação são:
  • Estrutura de produto “indentada” (indented bill of material): é uma representação alternativa à estrutura gráfica, sendo mais fácil de ser gerada pelos sistemas computacionais. Os níveis mais altos da BOM são colocados na extrema esquerda da margem e seus componentes são colocados sucessivamente para a direita à medida que se vai descendo ao longo dos níveis. Se um componente é utilizado em dois ou mais itens, ele aparecerá abaixo de cada um de seus itens pais.
  • Estrutura de produto de onde é usado (where-used bill of material): pode ser no formato de nível simples ou multinível. No primeiro tipo são mostrados todos os itens pai nos quais o componente é usado diretamente. No segundo tipo são mostrados todos os itens pai nos quais o componente é usado direta ou indiretamente, isto é, até o produto final, através de uma técnica chamada implosão
  • Estrutura de produto custeada (costed bill of material): é uma extensão do formato “indentado” no qual o custo de cada item é mostrado numa coluna à direita da descrição.
  • Estrutura de produto matriz (matrix bill of material): é um gráfico utilizado para identificar os componentes comuns dentro de uma família de produtos ou famílias similares.
  • Estrutura de produto resumida (summarized bill of material): uma forma de BOM de um nível na qual são listados todos os componentes necessários para a produção do item com suas quantidades. Difere do BOM “indentada” porque não são mostrados os níveis de montagem e os componentes aparecem apenas uma vez com a quantidade total necessária.
Variações da BOM e BOM única
Como os diferentes usuários da BOM possuem diferentes necessidades, tornou-se uma prática comum que cada um deles estrutura-se a sua própria BOM de acordo com essas necessidades individuais. Os exemplos mais comuns de BOM departamental são a BOM criada pela engenharia (E_BOM - Engineering Bill of Material), e a BOM utilizada pelo PCP e pela manufatura (P_BOM - Production Bill of Material ou M_BOM - Manufacturing Bill of Material). A E_BOM, também chamada estrutura de desenho, representa os sistemas funcionais do produto. Já a P_BOM é elaborada a partir da E_BOM, e reflete a transformação da matéria prima e a montagem dos subconjuntos através do processo produtivo. Essa abordagem implica, entretanto, na redundância de informações, e consequentemente no risco de inconsistência, bem como no aumento do esforço e do tempo de resposta das manutenções (GARWOOD, 1995). Devido aos problemas apresentados, diversos autores, como CLEMENT et al. (1992), GARWOOD (1995) e WASSWEILER (1996), consideram que toda empresa deve perseguir o objetivo de ter uma estrutura de produto única que forneça múltiplas visões para suportar as necessidades de todos os usuários. Objetivo esse que é totalmente compatível com o estágio atual de desenvolvimento da tecnologia de informação. GARWOOD (1995) observa que apesar do PCP ser o maior usuário da BOM e o que exige maior precisão das suas informações, ele não é o seu “dono”. Segundo WASSWEILER (1996), nesse novo cenário a BOM passa a ser responsabilidade de todos os seus usuários.
Artigos
AMERICAN PRODUCTION AND INVENTORY CONTROL SOCIETY. Dictionary. (1992). 7.ed. Falls Church, American Production and Inventory Control Society. CLEMENT, J.; COLDRICK, A. SARI, J. (1992). Manufacturing data structures: building foundations for excellence with bills of material and process information. Atlanta, Oliver Wight. 1992. ( Disponível na biblioteca da EESC - USP ). GARWOOD, D. (1995). Bills of material: structured for excellence. 5.ed. Marietta, Dogwood. (t:822). GUESS, V. C. (1985). APICS training aid: bills of material. Revised edition, Falls Church, American Production and Inventory Control Society. OLIVEIRA, C. B. M. (1999). Estruturação, identificação e classificação de produtos em ambientes integrados de manufatura. São Carlos, 1999. Dissertação (Mestrado) – Escola de Engenharia de São Carlos - USP. ( Disponível na biblioteca da EESC - USP ). (t:782) ROZENFELD, H.; OLIVEIRA, C. B. M.(1998) Estruturação e Identificação de Produtos em Ambientes Integrados. Máquinas e Metais, n. 392, p. 100-119, set. (t:796) SCHLUSSEL, B. (1995). Principles of product structuring: how to get the most of your bill of material. In: APICS ANNUAL INTERNATIONAL CONFERENCE, Orlando, 1995. Proceedings. Falls Church, APICS. p.101-103. VAN VEEN, E. A.; WORTMANN, J. C. (1987). Generic bill of material in assemble to order manufacturing. International Journal of Production Research, v.25, n.11, p.1645-1658. (t:828). WASSWEILER, B. (1996). How to achieve and maintain bill of material accuracy. APICS ANNUAL INTERNATIONAL CONFERENCE, New Orleans, 1996. Proceedings. Falls Church, APICS. p.57-59.
Sites relacionados
APICS http://www.apics.org/ Instituição educacional dedicada ao estudo de gerenciamento de recursos. O site contém artigos sobre o assunto. ICM http://www.icmhq.com/ Site dedicado especificamente à Configuraton Management. Apresenta aplicações relacionadas à Bill of Material. AIMASOFT http://www.aimasoft.com/ Fornecedor de soluções que garantem a integração na engenharia, tendo um produto de BOM
Benchmarking http://www.portaldeconhecimentos.org.br/index.php/content/view/full9946
Introdução
Benchmarking é a busca pelas melhores práticas que conduzem uma empresa à maximização da performance empresarial. Uma definição formal dada por David T. Kearns da Xerox Corporation afirma que “Benchmarking é o processo contínuo de medição de produtos, serviços e práticas em relação aos mais fortes concorrentes, ou às empresas reconhecidas como líderes em suas indústrias”. O processo genérico de benchmarking pode ser dividido em duas partes, práticas e métricas. As práticas são definidas como os métodos que são usados; as métricas são o efeito quantificado da instalação das práticas. O benchmarking deve ser abordado investigando-se inicialmente as práticas da indústria. As métricas que quantificam o efeito das práticas podem ser obtidas ou sintetizadas em seguida. O benchmarking é portanto uma compreensão de práticas e depois sua quantificação para mostrar seu efeito numérico. Baseando-se no exemplo da Xerox, pioneira na aplicação do Benchmarking, fica evidente a necessidade de realizar esta atividade de forma bem mais ampla do que comparar operações internas da empresa, ou apenas preocupar-se em desmontar máquinas ou produtos físicos de concorrentes, em um benchmarking de atividades de fabricação. É necessário preocupar-se também em realizar benchmarking de processos de negócios tais como a manutenção, a distribuição, o desenvolvimento de produtos, etc, que diferente de se ter algo físico para desmontar requer que métodos e práticas sejam detalhados e depois comparados com o ambiente externo. Fica claro também que o benchmarking pode levar a compreensão da posição de um concorrente, mas não à criação de práticas superiores àquelas da concorrência, que só será obtida pela descoberta das melhores práticas, onde quer que elas estejam (outros tipos de organizações e não somente os concorrentes). A realização do benchmarking passa por cinco fases genéricas: - Planejamento das investigações de benchmarking, buscando-se responder a três perguntas: O que deve ser usado como marco de referência? Com quem ou o que iremos comparar? Como serão coletados os dados? Enfatiza-se mais uma vez que o importante é reconhecer que o benchmarking é um processo não só para obter metas métricas quantificáveis, mas também, e mais importante, para investigar e documentar as melhores práticas da indústria, as quais irão permitir que essas metas sejam atingidas; - Análise, envolvendo uma cuidadosa compreensão das práticas correntes dos processos da empresa, bem como dos parceiros, afinal o processo de benchmarking é uma análise comparativa. Aquilo que se deseja é uma compreensão do desempenho interno, a partir da qual se possa avaliar as forças e fraquezas: Os parceiros de benchmarking são melhores? Por quê? Quanto? Quais das melhores práticas já estão em uso ou previstas? Como as práticas deles podem ser incorporadas ou adaptadas para implementação? - Integração, é a fase em que busca-se incorporar novas práticas à operação. As descobertas do benchmarking precisam ser comunicadas a todos os níveis organizacionais para se obter apoio, comprometimento e senso de propriedade. É preciso demonstrar, de forma clara e convincente, que elas são corretas e se baseiam em dados concretos e obtidos de diversas fontes. - Ação, as descobertas do benchmarking e os princípios operacionais nelas baseados devem ser convertidos em ações específicas de implementação. Além disso, é preciso que haja medições e avaliações de realizações periódicas. Os progressos em direção aos pontos de referência devem ser reportados a todos os funcionários; - Maturidade, será alcançada quando as melhores práticas da indústria estiverem incorporadas a todos os processos da empresa e quando o benchmarking se torna uma faceta permanente, essencial e autodesencadeada do processo gerencial. A criatividade na execução destas cinco fases genéricas irá diferenciar os resultados que cada empresa obterá na realização do benchmarking. O benchmarking pode beneficiar uma empresa de diversas maneiras: - possibilita que as melhores práticas de qualquer indústria (concorrentes ou não) sejam incorporadas de forma criativa aos processos da empresa; - pode proporcionar estímulo e motivação aos profissionais cuja criatividade é exigida para a execução e implementação das descobertas da investigação; - pode ocorrer também de as pessoas serem mais receptivas a novas idéias e à sua adoção criativa quando estas não se originaram necessariamente na sua própria indústria; - pode também identificar, em outras indústrias (de outros ramos de negócios), avanços tecnológicos que não seriam reconhecidos e, portanto, não aplicados no próprio setor; - finalmente, os envolvidos no processo de benchmarking muitas vezes constatam que os contatos e interações decorrentes do benchmarking têm valor inestimável para o futuro crescimento profissional.
Guia de leitura das informações adicionais
O livro de Camp (1993) foi a principal referência utilizada para a montagem do texto introdutório sobre benchmarking desta homepage. Portanto, no livro encontra-se apresentado de forma muito mais detalhada os conceitos e discussões aqui expostos e principalmente as cinco fases genéricas para a realização do benchmarking, desdobradas em passos de execução com instruções detalhadas e apresentação ilustrativa de casos de empresas. O artigo de Elmuti et. al. (1997), faz uma boa revisão geral sobre o processo de aplicação do benchmarking e suas implicações para o melhoramento contínuo e a vantagem competitiva. Analisa também os benefícios, limitações, custos, implementação e aspectos éticos e legais da aplicação do benchmarking. No livro de Fuld (1993), há uma exposição de métodos práticos e ferramentas para a monitoração de concorrentes, baseando-se em fontes de informação disponíveis tanto fora como dentro da própria empresa. Além disso sugere formas de se organizar e armazenar informações sobre os concorrentes e transmiti-los para os responsáveis pelas decisões na empresa. Outra obra bastante conhecida sobre benchmarking é o livro de Spendolini (1993), que apresenta um modelo genérico do benchmarking, apropriado para qualquer organização, propondo-se um conjunto de ações que um indivíduo, grupo ou uma organização pode seguir para estabelecer seu próprio processo de benchmarking. Divide-se em três partes: a primeira abordando os fundamentos do benchmarking, a segunda apresentando cinco estágios práticos para a realização do benchmarking, e a terceira expondo recomendações de especialistas em benchmarking das melhores práticas. Por fim, nos sites do The Benchmarking Exange e do International Benchmarking Clearinghouse pode-se encontrar textes atualizados e diversos artigos com casos práticos sobre o tema.
Livros
CAMP, R.C. (1993) Benchmarking, o caminho da qualidade total. São Paulo: Pioneira. (disponível na Biblioteca da Engenharia da EESC -USP) ELMUTI, D.; KATHAWALA, Y.; LLOYED, S. (1997) The Benchmarking Process: Assessing Its Value and Limitations. Industrial Management, p. 40 – 50, July-August. (t:583) FULD, L. (1993) Administrando a Concorrência. Rio de Janeiro: Record.(disponível na Biblioteca Comunitária da UFSCar) SPENDOLINI, M.J. (1993) Benchmarking. São Paulo: Makron Books. (disponível na Biblioteca da Engenharia da EESC – USP)
Sites Relacionados
IBC-International Benchmarking Clearinghouse e APQC-American Productivity & Quality Center (1999) http://www.apqc.org The Benchmarking Exchange and Best Practices Homepage (1999) http://www.benchnet.com/index.htm
Brainstorming http://www.portaldeconhecimentos.org.br/index.php/content/view/full9444
Introdução
Pode ser traduzido por tempestade de idéias e constitui-se em um método que auxilia na obtenção de novas idéias com possíveis soluções com para uma área de interesse específica. É adequado para responder questões simples de forma rápida. A questão problema deve admitir diversas soluções. Existem diversos tipos de Brainstorming com tradicional ou clássico, avançado, individual.
Objetivo
Gerar diversas novas idéias/soluções para um problema que admite diversas soluções
Abrangência
Obter idéias para novos produtos e para melhoria dos já existentes Idéias para campanha de publicidade Gestão de projetos com identificar objetivos de clientes, riscos, entregas, recursos, tarefas e responsabilidades.
Passos
1. Pedir que os membros que irão participar do brainstorming leiam os princípios norteadores previamente, antes da sessão. 2. Na sessão de brainstorming propriamente dita, (caso necessário) discutir os princípios. 3. Elaborar um enunciado claro para o problema. 4. Organizar as pessoas em grupos. 5. Deixar o enunciado do problema visível a todos. 6. Informar aos participantes sobre as quatro regras de direcionamento do brainstorming e verificar se houve o entendimento delas. 7. Cada grupo deve eleger alguém para desenvolver função de secretariado, responsável por anotar as idéias e um facilitador, que deve relembrar as regras e estimular a participação de todos 8. Dar início a sessão de brainstorming e encerrá-la após 30 minutos. 9. Agrupar as idéias em categorias com usar checklist para auxiliar. 10. Formar grupo para avaliar as idéias e escolher as melhores. 11. Exposição das idéias selecionadas ao(s) grupo(s) que elaboraram para aprovação. 12. Finalização do brainstorming Resultados Obtenção de um conjunto de boas idéias como solução para o enunciado proposto.
Lições Aprendidas
  1. O grupo de geração de idéias deve ter entre seis e doze participantes. Se desejar trabalhar com mais pessoas, convém dividi-las em grupos que tenham o tamanho mencionado anteriormente. No final, unem-se todas as idéias geradas.
  2. Convém que o grupo de avaliação seja formado por um número í­mpar de pessoas, pois caso não haja consenso e uma votação seja requerida, não ocorra empate.
Regras de Brainstorming
São quatro as regras que direcionam o brainstorming: 1. Críticas são rejeitadas: não se pode criticar nenhuma idéia, o intuito é gerá-las e não as avaliar. Esta regra é considerada crítica para o sucesso do brainstorming. 2. Criatividade é bem-vinda: esta regra serve para incentivar os participantes a realmente falarem todas as idéias que lhe vierem à cabeça, mesmo as mais esdrúxulas, dizendo que devem permitir a criatividade aflorar. 3. Quantidade é necessária: quanto maior o número de idéias geradas, maior a probabilidade de se obter uma solução ótima. Quantidade leva à qualidade, neste caso. 4. Combinação e aperfeiçoamento são requeridos: busca-se que os participantes, além de darem idéias novas, construam e reconstrução idéias outras em cima das já citadas.
Regra 1:
Não passe julgamento em idéias até a conclusão da sessão de brainstorming. Não sugira que uma idéia não trabalhará ou que tem efeitos colaterais negativos. Todas as idéias são potencialmente boas assim não os julga depois até. Nesta fase, evite discutir as idéias nada, como isto envolverão ou criticando inevitavelmente ou os elogiando. Deveriam ser avançadas idéias ambos como soluções e também como uma base reluzir soluções. Até mesmo idéias aparentemente tolas podem reluzir melhor. Então não julgue as idéias até depois do processo de brainstorming. Anote todas as idéias. Não há nenhuma tal coisa como uma idéia ruim. A avaliação de objetos pegados de idéias para cima valioso poder de cérebro que deveria ser dedicado à criação de idéias. Maximize sua sessão de brainstorming só passando tempo que gera idéias novas.
Regra 2:
É muito mais fácil de domesticar uma idéia selvagem que é pensar de um imediatamente válido no primeiro lugar. O ' wilder' a idéia o melhor. Grite idéias estranhas e inexecutáveis para ver o fora o qual eles reluzem. Nenhuma idéia é muito ridí­cula. Declare qualquer idéia estranha. Exagere idéias para o extremo. Use técnicas de pensamento criativas e ferramentas para começar seu pensamento de uma direção fresca. Use software especialista como Caixa de ferramentas de Brainstorming (http://www.brainstorming.co.uk/toolbox/brainstormingtoolbox.html) estimular idéias novas mais facilmente.
Regra 3:
Vá neste momento por quantidade de idéias; reduza a lista depois. Todas as atividades deveriam ser engrenadas para extrair tantas idéias quanto possível em um determinado período. As idéias mais criativas uma pessoa ou um grupo tem que escolher de, o melhor. Se o número de idéias ao término da sessão é muito grande, há uma maior chance de achado uma idéia realmente boa. Mantenha cada idéia pequeno, não descreve isto em detalhes - só captura sua essência. Podem ser pedidas clarificações breves. Pense rapidamente, reflita depois.
Regra 4:
Construa e se expanda nas idéias de outros. Tente e some pensamentos extras para cada idéia. Use as idéias de outras pessoas como inspiração para seu próprio. Pessoas criativas também são as ouvintes boas. Combine algumas das idéias sugeridas para explorar possibilidades novas. É da mesma maneira que valioso poder adaptar e melhorar as idéias de outras pessoas como é gerar a idéia inicial que provoca trens novos de pensamento.
Regra 5:
Toda pessoa e toda idéia tem preço igual . Toda pessoa tem um ponto de vista válido e uma perspectiva sem igual na situação e solução. Nós queremos saber o seu. Em uma sessão de brainstorming você pode pôr sempre puramente idéias dianteiras para reluzir outras pessoas e não da mesma maneira que uma solução final. Por favor participe, até mesmo se você precisa escrever suas idéias em um pedaço de papel e entregar isto. Encoraje participação de todo o mundo.
Classificação de idéias
Checklist contendo diversas categorias que podem ser utilizadas para se classificar as idéias, para que estas possam ser avaliadas.
  1. De demorada implementação
  2. De rápida implementação
  3. De custosa implementação
  4. De barata implementação
  5. De fácil execução
  6. De difícil execução
  7. De fácil assimilação
  8. De difícil assimilação
Links
http://www.brainstorming.co.uk/contents.html. http://www.ppgte.cefetpr.br/gco/estudo_de_caso_gco.pdf.
Business Intelligence (BI) http://www.portaldeconhecimentos.org.br/index.php/content/view/full9446
Definição
Processo de coleta, organização, análise, compartilhamento e monitoração de informações que oferecem suporte a gestão de negócios. Deve-se diferenciar o termo BI de BI software, que são soluções de software para apoiar a BI.
Referências
Definição da wikipedia em português Definição da wikipedia em inglês Texto em uma página de conhecimentos sistematizados sobre tecnologia de processos Definição de software para BI (da PC magazine) Diferenciação entre os termos BI e datawarehouse É uma entrevista bem curta, mas a partir dela pode-se acessar outras definições correlatas, pois muitas vezes as pessoas tratam BI como o software de BI (portais etc) e confundem com o de datawarehouse, que na verdade é mais básico. Porém, muitas empresas para diferenciar o seu produto de BI o denomina de datawarehouse que é a tecnologia que pode estar por trás (pode!) de um sistema / software / portal de BI.
CAD (Computer Aided Design) http://www.portaldeconhecimentos.org.br/index.php/content/view/full9953
Introdução
Com o contínuo avanço tecnológico, a soma de informações e conhecimentos que devem estar sob o domínio do engenheiro cresce ininterruptamente. Os sistemas CAD se propõem a auxiliar a manipulação e criação destas informações, sistematizando os dados de projeto envolvidos, possibilitando uma rápida reutilização de informações quando necessário. Os sistemas CAD deveriam suportar qualquer atividade de projeto na sua criação, modificação, recuperação ou documentação. Apesar da sigla "CAD" incluir o termo " Design", observa-se que são poucos os casos em que o computador efetivamente projeta alguma coisa, servindo mais como uma ferramenta de auxílio à confecção de desenhos de engenharia. Sua maior contribuição ocorre no modelamento dos produtos e componentes, e no detalhamento de seus desenhos. Em alguns sistemas CAD, o termo " design" foi trocado por " drafting", tal sua aplicação como elemento puramente voltado a documentação do projeto, o que em alguns casos pode levar a subutilização do sistema. Outros sistemas que atuam na área de cálculos de engenharia são chamados de CAE ("Computer Aided Engineering"), onde são realizadas outras atividades do tipo análise estrutural por elementos finitos (FEM), análise de escoamento, simulações multi-corpos, análise de tensões, etc ... Existem algumas tentativas relacionadas ao desenvolvimento de sistemas que realmente possam tomar decisões no projeto, a grande maioria delas baseada em técnicas de Inteligência Artificial. Porém, devido às dificuldades em se capturar a lógica do processo de desenvolvimento de um projeto e à quantidade de dados envolvidos, a tarefa se torna bastante complexa, originando poucos resultados práticos. Mesmo com essas dificuldades, os sistemas CAD são de extrema importância para o projeto. As vantagens oferecidas no apoio ao projeto podem ser comprovadas em muitas de suas etapas, indo desde uma melhor documentação e apresentação do produto, com melhoria da qualidade dos desenhos, diminuição de tempo e custos e aumento de produtividade geral, até um melhor gerenciamento do projeto. Por outro lado, os sistemas CAD somente podem ter seu potencial totalmente aproveitado, inclusive justificando-se técnica e economicamente, se estiverem integrados ao processo produtivo como um todo. Em uma estrutura integrada, o CAD proporciona além dos ganhos intrínsicos ao projeto do produto, aumento da eficiência das funções relacionadas ao planejamento, fabricação e qualidade. Em outras palavras, o CAD deve estar integrado com outros sistemas como CAPP, CAM e sistemas de gestão da produção (PCP, MRP, ERP). Atualmente existe uma variedade de opções que devem ser consideradas ao se analisar os sistemas CAD, dentre elas algumas caracterizam a funcionalidade do sistema, ou mesmo sua aplicabilidade integrada com outros. Considerando o tratamento dos dados existem hoje no mercado algumas variações, segue abaixo uma descrição sobre os sistemas 2D e sobre os 3D.
Sistemas 2D
Uma das vantagens de se usar CAD 2D é o rápido treinamento de operadores, geralmente habituados ao uso das pranchetas comuns. Mas o seu uso é limitado, correndo o risco de transformar o sistema em uma simples prancheta eletrônica, pouco mais produtiva que as pranchetas comuns. Para algumas aplicações a representação 2D é suficiente, como por exemplo em projetos de esquemas elétricos, hidráulicos, circuitos e placas eletrônicas, onde não há necessidade de informações volumétricas. Também na criação de vários tipos de croquis, para suportar a produção por exemplo, o CAD 2D é mais apropriado. Neste caso ele deve trabalhar em conjunto com um sistema CAPP, que seria responsável pelo gerenciamento dos dados representados no croquis (como lista de ferramentas, instruções de montagem e/ou inspeção, etc..) No projeto mecânico tem-se utilizado a representação 2D para o desenvolvimento de desenhos de conjunto, pois são mais facilmente alterados. Nessa fase emprega-se grande número de peças normalizadas, que são incluidas no desenho de forma interativa, o que confere uma grande produtividade a esta atividade. Empresas do setor mecânico de pequeno e médio porte preferem utilizar sistemas 2D, pois além do menor custo de aquisição e treinamento de seus funcionários, esse sistemas exigem máquinas menos poderosas. Entretanto, existe hoje no mercado uma série de sistemas 3D que se propõem a preencher essa lacuna. O grande retorno da utilização de CAD 2D está na reutilização das informações, uma vez que é bem mais fácil recuperar e modificar um desenho eletrônico, do que um desenho realizado de forma convencional.
Sistemas 3D
O modelamento 3D apresenta as dificuldades que são próprias do processo de desenho, pois o projetista é obrigado a considerar as três dimensões simultâneamente. Em alguns casos, a utilização do modelo 3D é imprescindível, como, por exemplo, na aplicação de análises por elementos finitos para verificação de tensões, escoamento, temperatura, etc. e ainda quando há a necessidade de se calcular o volume, propriedades de massa e eixo de inércia e verificação de interferêncais.(vide CAE) A seguir são citados os principais métodos de representação 3D:
  • Wireframe
  • CSG
  • Brep
  • Híbrida
  • Baseada em Features
  • Paramétrica
  • Dinâmica
Modelagem por Wireframe
No passado a modelagem por wireframe era o principal método utilizado pelos sistemas CAD, possibilitando ligar linhas entre pontos nos espaços 3D, permitindo a criação de modelos espaciais e garantindo a consistência de vistas 2D derivadas e cotagem associada. Com o avanço tecnológico e maior capacidade de processamento dos computadores, esses sistemas começaram a ser substituídos pelos baseados nos métodos de modelagem sólida. Isto também aconteceu em parte devido a dificuldade de uso dos wireframe quando necessário incorporá-los em softwares de análise ou manufatura, já que não possuem nenhum tipo de informação relacionada a características físicas dos componentes reais.
Modelagem Solida CSG (Constructive Solid Geometry)
Sistemas que são capazes de realizar a modelagem sólida são muito mais poderosos que simples modeladores baseados em wireframe. Esses programas são usados para construir componentes que são objetos sólidos, e não simplesmente uma malha de linhas trançadas. Um modelo CSG é uma árvore binária constituída de objetos primitivos e operadores booleanos. Os primitivos são representados pelas folhas da árvore e os objetos mais complexos são os nós. A raíz da árvore representa o produto completo. Cada primitivo é associado com uma transformação 3D que especifica a posição, orientação e dimensões. Este método caracteriza-se por compor modelos a partir de sólidos. Utilizando sólidos para modelar os componentes, eles passam a adquir propriedades físicas como volume, e caracterizando sua densidade, conseguimos obter outras características como peso e massa. Assim o computador pode calcular várias propriedades físicas desses componentes, como centro de gravidade, momento de inércia, etc. Estes cálculos podem ser utilizados em componentes com formas irregulares, onde o cálculo manual se torna extremamente difícil e trabalhoso. Além de facilitar o uso do modelo em softwares de análise. Este método possui algumas limitações, sendo a principal a presença de um conjunto limitado de operações e primitivos, o que por consequência limita as possibilidades de criação por parte do projetista.
Modelagem Solida Brep (Boundary Representation)
A modelagem Brep é baseada nas técnicas de modelagem de superfícies anteriormente existentes. A primeira geração de modeladores Brep representava objetos sólidos apenas por tabelas de faces, arestas e vértices. Assim ele somente suportava objetos com faces planas. Superfícies curvas eram modeladas por aproximação linear, num processo chamado "facetamento". A segunda geração de modeladores Brep incluiu objetos primitivos com superfícies analíticas, como cilíndros, esferas, cones, etc. Eles permitem a criação de modelos muito mais complexos com geometria "exata". Para tal foi necessário o uso de algoritmos de interseção muito mais complexos. Outros desenvolvimentos em modelagem Brep foram dirigidos a melhorias na efetividade de operações booleanas através de, por exemplo, o uso de diretórios de ocupação espacial, o que reduz o número de verificações de interferência de face. Uma outra área de desenvolvimento foi a expansão do número de formas geométricas que podem ser modelados com Brep. A modelagem Brep possui algumas vantagens sobre a CGS, principalmente no tocante a versatilidade na geração de modelos complexos e na velocidade de verificação de relações topológicas. Isto acontece devido a maneira como o Brep registra as informações do modelo, armazenando os parâmetros das arestas de forma explicita.
Modelagem Sólida Híbrida
Os métodos de modelagem sólida CSG e Brep são frequentemente combinados para gerar modelos de componentes. Cada um desses métodos possui suas limitações, e componentes de difícil criação fazendo uso de um ou outro, podem ser gerados mais facilmente usando uma combinação de ambos os métodos. A maioria dos sistemas modeladores sólido comerciais são híbridos utilizando tanto o método CSG quanto o Brep.
Modelagem Sólida baseada em Features
Um feature pode se definido como um elemento físico de uma peça que tem algum significado para a engenharia. Ele deve satisfazer as seguintes condições:
    • ser um constituinte físico de uma peça;
    • ser mapeável para uma forma geométrica genérica;
    • ser tecnicamente significante, sob o ponto de vista da engenharia; e
    • ter propriedades predizíveis.
O significado técnico de feature pode envolver a função à qual um feature serve, como ele pode ser produzido, que ações a sua presença deve iniciar, etc. Features podem ser pensados como 'primitivas de engenharia' relevantes a alguma tarefa de engenharia. A modelagem por features vem ganhando espaço principalmente dentro da engenharia mecânica. O método permite criar furos, chanfros, rasgos, etc, para serem associados com outras entidades ou faces. A modelagem por features é baseada na idéia de se desenhar utilizando building blocks - blocos de construção. Ao invés de se usar formas analíticas como paralelepípedos, cilíndros, esferas e cones como primitivos, o usuário cria modelo do produto usando primitivos de maior nível que são mais relevantes para sua aplicação específica. Esta abordagem deveria fazer com que os sistemas de modelagem sólida ficassem mais fáceis de serem usados. Entretanto, o conjunto fixo de features oferecido pelos atuais modeladores é muito limitada para uso industrial, o que limita as possibilidades do projetista. Assim fica claro que os features devem ser adaptáveis aos usuários e que a biblioteca de features deve ser extensível. Os esforços para especificação formal de uma linguagem de especificação de features, iniciados em 1990, proporcionaram que a versão mais nova do STEP incluísse features definíveis pelo usuário através de uma linguagem padrão de especificação de features.
Modelagem Sólida Paramétrica
A modelagem sólida paramétrica permite que se crie modelos de produtos com dimensões variacionais. As dimensões podem ser ligadas através de expressões. Ligações bidirecionais entre o modelo e o esquema de dimensionamento permite a regeneração automática de modelos depois de mudanças nas dimensões e atualização automática das dimensões relacionadas. Na figura 3 observa-se um modelo de um eixo escalonado em que a dimensão do diâmetro menor depende do diâmetro maior através da equação Da = Db/2. Caso a dimensão do diâmetro maior seja alterada, a dimensão do diâmetro menor é automaticamente alterada. Caso a dimensão do eixo menor seja alterada, a dimensão do eixo maior pode se automaticamente calculada pela inversa da função relacionamento. Nem todos os sistemas CAD paramétricos provêem esta bi-direcionalidade, devido a complexidade que isto envolve, o que penaliza o projetista, pois este tem que pensar na estruturação das ligações dimensionais antecipadamente, sem o que a alteração do modelo pode implicar em que ele seja refeito.
Artigos
SCHÜTZER, K.; GLOCKNER, C.; CLAASSEN, E. (1998). Support of the development process chain by manufacturing features. In: SEMINÁRIO INTERNACIONAL DE ALTA TECNOLOGIA - DESENVOLVIMENTO DISTRIBUÍDO DE PRODUTO, 3., Piracicaba, 1998. Anais. Piracicaba, UNIMEP.
Dissertações
ANACLETO, R. C. (1991). Aumento da produtividade dos sistemas CAD através da utilização de parametrizados. Dissertação (Mestrado) - Escola de Engenharia de São Carlos, Universidade de São Paulo. ( Disponível na biblioteca da EESC - USP ). KERRY, H. T. (1997). Planejamento de processo automático para peças paramétricas. Dissertação (Mestrado) - Escola de Engenharia de São Carlos, Universidade de São Paulo. ( Disponível na biblioteca da EESC - USP ).
Sites Relacionados
PTC Parametric Technology Corporation Autodesk Computervision Computer Aided Design Software Inc. SolidWorks Company Unigraphics Solutions Inc. Weber Systems Inc.
CAM(Computer Aided Manufacturing) http://www.portaldeconhecimentos.org.br/index.php/content/view/full10025
Introdução
Podemos definir CAM como auxílio via computador da preparação da manufatura, representando as tecnologias usadas no chão de fábrica, dizendo não só a respeito da automação da manufatura, como: CNC (Comando Numérico Computadorizado), CLP (Controle Lógico Programável), coletores de dados (DNC), como também a tomada de decisão, plano operacional, etc. Apesar de toda esta abrangência, o termo CAM , as vezes, ainda é sinônimo da programação CN, conceito que ficou muito difundido com a sigla CAD/CAM, que representa módulos de programação CN em sistemas CAM.
Funções da Programação CN
Os sistemas CN normalmente são utilizados para o cálculo do caminho da ferramenta, a partir da representação geométrica da peça disponível na forma computacional. Outra opção é a simulação final do programa, onde pode-se visualizar a usinagem. Com essas duas funções citadas é possível obter com boa precisão do tempo principal da operação, pois seu cálculo é determinístico, dependo dos movimentos da máquina Os comandos de um programa CN são os responsáveis pelo acionamento de uma máquina CNC, informando todas as etapas de fabricação de uma determinada operação de uma peça . Uma linha de comando de um programa CN pode conter informações sobre o movimento da ferramenta (movimento rápido, interpolação, etc...), informações tecnológicas (velocidade, avanço, etc...), ou informações que acionam funções auxiliares (ligar refrigerante, eixo árvore, etc...). A obtenção dessas informações depende sobre tudo dos dados da peça a ser usinada, considerando-se as limitações da máquina, as características do CNC e da ferramenta . Métodos de Programação CN:
  • Programação direto na máquina - MID (Material Data Input):
Esse método de programação descreve a programação direto no chão de fábrica, sendo viabilizado devido aos recursos dos novos CNC. Neste método, o programador, com a geometria à disposição, define o percurso da ferramenta e transforma em linguagem (função de máquina). É utilizado em eventuais modificações, para otimização de programas na máquina, e na programação de peças relativamente simples em oficinas de fabricação.
  • Programação Manual:
Neste caso, o programador interpreta o desenho da peça, calcula os pontos da trajetória da ferramenta, preenchendo um formulário que poderá ser digitado ou enviado diretamente ao operador da máquina, que digitará diretamente nela . Esse tipo de programação tem sido facilitada pela utilização de ciclos automático, sendo de fácil execução para geometrias não muito complexas.
  • Programação auxiliada por computador:
O mais tradicional método de programação auxiliada por computador é o que utiliza a linguagem APT ("Automatically Programmed Tool"). A função do programador, utilizando esse método, é escrever o programa fonte, aonde definisse a geometria da peça e/ou o percurso da ferramenta, via definição de forma padronizada pela linguagem de entes geométricos e funções auxiliares. Esse programa fonte é trabalhado por um processador, que realiza os cálculos geométricos, determina o contorno da ferramenta e gera um arquivo neutro (CLDATA ou CLFILE) independente da máquina. Posteriormente esse arquivo é pós-processado, gerando um arquivo específico a máquina. Um segundo método é aquele executado pelos modernos sistemas CAD/CAM, onde a entrada é o desenho da peça ou o percurso da ferramenta. Interativamente, no módulo CAM do sistema, inicia-se a programação CN que gerrará um arquivo neutro. Num terceiro novo conceito de programação CN, conhecido na Alemanha como WOP ( "Wertattsoriertierte Programminerung" ), o usuário inicia a programação a partir de um sistema CAD e trabalha interativamente, definindo os parâmetros geométricos, de ferramentas e tecnológicos, através de ícones gráficos. Gera-se também um arquivo neutro, que posteriormente será pós-processado. Vantagens, Desvantagens dos Métodos: A programação direto na máquina e a programação manual, apresentam o inconveniente de não serem produtivas, pois gasta-se muito tempo no cálculo da trajetória da ferramenta. Também, o programador tem de conhecer os códigos específicos de cada marca e modelo. Como agravante à programação direto na máquina, tem-se o fato da máquina permanecer parada durante a programação. A vantagem dos programas auxiliados por computador está no fato da não necessidade da realização dos cálculos da trajetória, transferindo esse trabalho para os recursos computacionais. A grande desvantagem das programações auxiliadas por computador, apesar da geração do arquivo neutro (CLDATA), é a necessidade de um pós-processador para cada tipo de CN. No caso da utilização da linguagem APT, tem-se também a necessidade de se otimizar o programa, o que muitas vezes é feito diretamente pelo operador da máquina, tornando o programa neutro incompatível com o programa fonte. Os sistemas CAD/CAM, apresentam também o inconveniente de serem fechados, não permitindo a integração com outros módulos CAD/CAM, não atendendo as necessidades de um ambiente CIM. A grande vantagem desse método está na facilidade da construção geométrica e na visualização do processo. Requisitos Necessários a um Sistema CN: - Possibilitar a integração com sistemas CAD para diminuir esforços de digitação de dados geométricos; - Trabalhar integrado com sistemas com sistemas CAPP para possibilitar uma integração dentro de um ambiente CIM; - Possuir estrutura modular, para garantir sua implantação gradual e possibilitar expansões; - Oferecer uma interface comum de programação para facilitar a comunicação dos usuários, tanto a nível de escritório quanto no futuro, na programação na máquina CN; - Executar cálculo automático das coordenadas da ferramenta, baseado na geometria da peça, verificação e testes, livrando o usuário para a realização de tarefas voltada ao planejamento de processos, eliminando tarefas mecânicas e repetitivas; - Simular os programas gerados; - Possuir uma base de dados para cadastramento de diversas máquinas CN, para ser possível a geração dos programas para as diferentes máquinas CN; - Possuir interface amigável formada por ícones, facilitando o aprendizado a processistas menos experientes; - Possuir uma tabela de mapeamento do local de armazenagem do programa CN, com sua respectiva identificação, para possibilitar a transmissão DNC. Funções do Controle Numérico Direto (DNC): Os primeiros sistemas DNC foram implementados no final da década de 60 nos EUA e Japão, para gerenciar e distribuir os programas CN. Esperava-se a simplificação do gerenciamento e distribuição de programas, maior velocidade na transmissão dos dados, e maior confiabilidade na operação de transmissão. Inicialmente restringiam-se ao gerenciamento e distribuição dos programas. Em seguida, surgiram comandos simplificados, onde parte das funções do CN eram deslocadas para o computador, barateando-se o hardware do CN, mas aumentava-se o risco de parada da linha. Atualmente, pode-se dizer que o DNC possui várias funções: - integração de outros setores da empresa (engenharia, produção,...); - integração de sistemas CAD com máquinas CN; - gerenciamento e distribuição de programas CN; - correção de dados; - aquisição e processamento de dados da produção e de máquinas CN; - funções parciais de controle da produção e do fluxo de materiais; Diversas são as formas de realização destas funções. A forma clássica, que pode ser chamada de DNC terminal, utilizando-se o terminal anteposto à máquina operatriz intermediando a transmissão de dados. Desse modo o comando centralizado de funções não é possível, sendo a iniciativa da transmissão dos dados a cargo do operador. Uma segunda forma, pode ser chamada de DNC remoto. Ela permite o comando centralizado, e é necessária quando robôs e máquinas operatrizes são utilizadas no contexto de sistemas flexíveis de manufatura. Neste caso os programas são transmitidos e a máquina é preparada remotamente para a usinagem. A decisão da transmissão parte do computador controlando a linha. Benefícios do DNC: Pode-se listar as seguintes vantagens de utilização do DNC: - maior velocidade e segurança na transfer6encia de informações do que quando utilizamos outros meios ; - utilização de componentes padronizados; - melhor organização e maior capacidade disponível para o armazenamento dos programas CN; - maior racionalização do trabalho e rapidez na tomad ade decisões; - controle dos dados da produçào em tempo real; - ajuda a integração da empresa.
Dissertações
NAVARRO, H. A.. (1991) Desenvolvimento de um sistema para programação comando numérico para peças rotacionais, Dissertação (Mestrado) - Escola de Engenharia de São Carlos, Universidade de São Paulo. ( Disponível na biblioteca da EESC - USP ). ROCHA, W. A.. (1992) Metodologia de programação CN variante integrada ao CAPP para a programação de peças prismáticas, Dissertação (Doutorado) - Escola de Engenharia de São Carlos, Universidade de São Paulo.( Disponível na biblioteca da EESC - USP ) ROZENFELD, H. (1992). Implantação distribuída do planejamento de processo assistido por computador na manufatura integrada . São Carlos, 169p. Tese (Livre Docência) - Escola de Engenharia de São Carlos, Universidade de São Paulo. ( Disponível na biblioteca da EESC - USP ).
Livros
KOCHAN, D. .(1985). CAM Developments in Computer – Integrated Manufaturing. ( Disponível na biblioteca da EESC - USP ).
Sites Relacionados
http://www.geocities.com/CapeCanaveral/Lab/2549/cam_nc.htm#capp http://www.geocities.com/CapeCanaveral/Lab/2549/cim.htm http://www.camax.com/prodinfo/smartcam/scnewv10/
CAPP(Computer Aided Process Planning) http://www.portaldeconhecimentos.org.br/index.php/content/view/full10293
Objetivos do Planejamento do Processo
As funções do planejamento do processo são selecionar e definir os processos a serem executados em uma peça de maneira econômica, de acordo com as especificações do projeto, verificando as condições de venda (como volume de vendas e prazos). O documento resultante do planejamento do processo, conhecido como plano de processo, é a base para se realizar o planejamento da produção e serve como referência à produção propriamentre dita. Por isso é que se considera o planejamento do processo como o elo de ligação entre projeto e o planejamento da produção e também o chão-de-fábrica (vide figura 1). Figura 1: Localização do planejamento do processo
Plano de Processo
O plano de processo é um documento que reúne todas as informações necessárias para transformar o desenho do produto em um produto acabado. Cada empresa tem necessidades diferentes de documentação de processo, conforme a realidade do seu chão-de-fábrica, tanto em termos de equipamentos quanto em termos de pessoal. Apesar da diversidade de planos de processo existente, pode-se identificar pelo menos dois conjuntos de informações comuns a todos eles: Plano macro, que determina a seqüência de operações executadas no ambiente fabril, ou seja, especifica a rota pela qual a peça sendo fabricada irá passar. O plano macro é a base para o planejamento e controle da produção.
  • Detalhamentos das operações, que são informações de apoio ao chão-de-fábrica (intruções e croquis para montagem de máquinas e do ferramental, lista de ferramentas, instruções de qualidade , folha de CEP, programas CN, etc. )
O Planejamento do Processo Convencional
O desenvolvimento de um plano de processo inicia-se, geralmente, a partir de um desenho de produto. A partir das informações de projeto, o processista passa a seqüenciar as operações do plano macro. Em uma fase posterior, estas operações são detalhadas, sendo que o nível de detalhe, como já citado, depende de características da empresa. Há poucos anos atrás, o processista documentava o plano de processo utilizando a forma manuscrita e, em alguns casos, digitava em sistemas PCP (Planejamento e Controle da Produção). Esta forma de planejar o processo de fabricação continua sendo empregada em várias empresas de manufatura. Contudo, este modo de planejamento possui uma baixa produtividade, como mostrado na figura 2, na qual 63% do tempo é gasto com a redação do plano. Junto a isto, o tempo utilizado em cálculos diversos e em recuperação de informações totalizam 29% , ou seja, 92% do tempo é empregue em funções que não agregam valor diretamente, e apenas 8% é utilizado em funções como concepção e análise. Figura 2: Tempo gasto no desenvolvimento do processo convencional
O Planejamento do Processo Assistido por Computador (CAPP)
As características do planejamento de processo convencional, que dependem da experiência do processista, resultam em problemas que podem ser resolvidos pela aplicação do computador. As informações produzidas pelo CAPP tornam-se padronizadas, eliminando-se a inconsistência de plano obtidos por processistas diferentes. A qualidade da documentação enviada ao chão-de-fábrica eleva-se também, garantindo o domínio do processo. Existem quatro tipos de CAPP:
  • Planejamento variante
  • Planejamento generativo interativo
  • Planejamento generativo automático
  • Planejamento híbrido
Planejamento do Processo Variante: é aquele que parte de um plano base (ver figura 3), que é modificado para se obter um novo plano. Neste tipo de planejamento utiliza-se planos padrões ligados a famílias de peças ou planos semelhantes, que não requerem a formação de famílias de peças, proporcionando uma sistematização de curto período e investimento. Figura 3: CAPP Variante Planejamento do Processo Generativo Interativo: inicialmente correspondia a edição indireta do plano, onde as informações do planejamento eram geradas pelo processista e enviadas a um digitador, que alimentava o computador com os dados necessários. Normalmente era impresso um formulário que o processista conferia, ou seja, essa forma de trabalho continha idas e voltas que não agregam valor e era sujeita a erros. Em outras empresas, o processista substitui o digitador, colocando as informações diretamente no computador (ver figura 4). Por eliminar a etapa intermediária, achava-se que o ciclo de obtenção de um ciclo seria menor. Tal pressuposto mostrou-se falso, pois o processista experiente normalmente não apresentava habilidade no computador. Com as pressões de produtividade, o processista tornou-se um digitador, não pensando nos processos e sim colocando dados no computador. Ele deixa de realizar as funções para as quais é melhor capacitado Figura 4: CAPP generativo interativo Ambas as atividades acima descritas não são consideradas CAPP interativo, e mantém os problemas do planejamento convencional. No final da década de 90 o computador começou a ser utilizado como um guia na escolha de padrões pré-cadastrados, através de uma interface amigável (ver figura 4). A busca deste padrão é ainda facilitada por uma classificação, que facilita a sua busca. Desta maneira, o processista interage diretamente com o computador com um mínimo de digitação e dificuldade. Quando existir uma relação entre os padrões (por exemplo, a ferramenta "X" só pode ser utilizada na máquina "Y"), o processista não precisa navegar por muitas opções para escolher um padrão (no exemplo, a ferramenta). O sistema verifica o que já foi determinado e só apresenta para seleção aqueles padões que se relacionam com os já escolhidos (por exemplo, uma lista das ferramentas que podem ser utilizada na máquina "Y"). Planejamento Generativo Automático: O princípio deste método de planejamento do processo é baseado no armazenamento de regras e dados de capacidade do processo de fabricação. Através destas informações, um plano de processo poderia ser gerado sem a necessidade de uma pessoa experiente, pois os mecanismos de inferência, decisões, lógicas e algoritmos, interpretariam os dados de projeto e tomariam as decisões sobre o "como fazer".Este é o caso mais completo de planejamento automático. No entanto, podem haver outras formas de planejamento automático, nas quais somente certas funções de planejamento são automatizadas (vide planejamento híbrido). A representação das peças deve estar armazenada no computador de uma forma interpretável pelo sistema CAPP, para que este realize inferências automáticas nas tomadas de decisão. A melhor forma de representação para a inferência automática são os features. Planejamento Híbrido: como cada método apresenta vantagens e desvantagens, a conclusão natural é de que a combinação destes métodos em uma solução híbrida pode alcançar o melhor de cada um dos métodos. A solução híbrida permite a utilização das vantagens de cada método em partes distintas das funções de planejamento de processo. Para uma peça totalmente nova, que não possua plano de processo semelhante, inicia-se o planejamento através do generativo interativo, e em determinados pontos pode-se requisitar que o sistema faça uma inferência automática (cálculo de tempos, cálculo de condições de usinagem, geração de CN para um feature conhecido).Outras peças, de formato mais bem comportado que apresentem uma certa repetibilidade, podem ser melhor planejadas através do método variante (figura 5). Figura 5: CAPP híbrido Pode-se realizar também a geração de planos de processo de maneira totalmente automática, como no caso de peças que podem ser parametrizadas, por exemplo uma engrenagem, a qual pode ser descrita pelo seu passo de base, diâmetro primitivo, módulo, etc. Neste caso o computador interpreta os parâmetros, realiza inferências automáticas e gera o plano de processo (vide artigo sobre caso prático de implantação de um CAPP para peças paramétricas).
Benefícios
A aplicação do CAPP, em qualquer um dos casos, traz um grande número de vantagens sobre o planejamento de processo convencional, entre elas podemos citar: Redução do tempo de planejamento: um dos principais ganhos com a implantação do CAPP é o aumento da produtividade de planejamento do processo. Com isto é possível elaborar os planos de processos com um número reduzido de processistas e curto período de tempo. Agilidade nas revisões: com o CAPP, cada operação do processo pode ser facilmente revisada. O histórico das revisões pode ficar armazenado em uma base de dados, possibilitando o acomplanhamento de todas as modificações. Padronização dos processos: o uso do CAPP pode permitir que todos os parceiros trabalhem com um modelo único de plano de processo, garantindo uma padronização da documentação de processos da fábrica, além de garantir a padronização dos termos adotados. Criação de uma base única de processos: O CAPP permite a criação de uma base de dados única de processos, garantindo a integridade das informações registradas. Aumento da qualidade dos processo: Com o uso do CAPP pode-se adicionar outros tipos de informações aos planos de processos, além das informações descritivas. Assim pode-se fazer uso de informações visuais através de fotografias, gráficos, desenhos, ou então outras instruções detalhadas do processo, como listas dos componentes montados em cada operação, instruções de controle e dispositivos necessários, por exemplo. Existem ainda várias outras vantagens como a redução drástica de papel impresso, agilidade na elaboração e alteração de uma especificação de projeto, alta confiabilidade nos dados por estarem automatizados com fórmulas de cálculos, definição de hierarquia para aprovação de projeto, entre outras. A consequência do uso de CAPP nas outras áreas da empresa são: diminuição de refugos, diminuição do custo ferramentas, diminuição de lead-time e criação de padrões de engenharia. A figura 6 faz um comparativo entre a aplicação de algumas tecnologias considerando seu sucesso e retorno. Observa-se que a aplicação do CAPP é realizada com sucesso em quase 100% dos casos, e o seu retorno supera o de todas as outras analisadas. Devido aos benefícios decorrentes do uso do CAPP, ele é hoje uma ferramenta muito importante para o aumento da qualidade e diminuição de custos da fase de planejamento do processo e da manufatura e consequentemente para o aumento da competitividade da empresa como um todo.
Artigos
CAY, F.; CHASSAPIS, C. (1997) An IT view on perspectives of computer aided process planning research, Computers in Industry, v.34, p.307-337. (t:863) KIRITSIS, D. (1995) A review of knowledge-based expert systems for process planning. Methods and Problems, International Journal of Advanced Manufacturing Technology, v.4, n.10, p.240-262. (t: 864) ROZENFELD, H. (1992). Implantação distribuída do planejamento de processo assistido por computador na manufatura integrada . São Carlos, 169p. Tese (Livre Docência) - Escola de Engenharia de São Carlos, Universidade de São Paulo. ( Disponível na biblioteca da EESC - USP ). ROZENFELD, H. (1994). Sistema CAPP: seus conceitos, casos práticos e desenvolvimentos. Máquinas e Metais, n. 338, p. 124-142, mar. (t144) RIBEIRO,C.E.S.; KERRY,H.T.;PIEBER,E.;ROZENFELD,H. (1996) Aplicação de uma solução CAPP para peças parametrizadas: um caso prático, Máquinas e Metais, 186-1999 ROZENFELD, H. (1998). O CAPP integrou o consórcio modular de produção de caminhões e ônibus da VW. Máquinas e Metais, p. 233-245, abril.
Livros
HALEVI,G.; WEILL, R.D. (1995) Principles of Process Planning: A logical approach, Chapman & Hall, pp.399. ( Disponível na biblioteca da EESC - USP ). (t:301).
Softwares
MetCAPP - AgilTech Manufacturing Engineering Software HMS Software Inc. Software and Consulting for Computer Aided Process Planning, Lean Manufacturing IDFM Inc. - Integrating Data For Management T-Systems do Brasil Ltda- A solucão CAPPE comercializada pela Debis pode ser consultada por meio dos links "produtos e serviços" e novo "produtos e serviços + pacotes de software"e então "capp"
Conceitos Gerais de Desenvolvimento de Produto http://www.portaldeconhecimentos.org.br/index.php/content/view/full9948
Importância do Desenvolvimento de Produto
Não é novidade que desenvolver produtos tem se tornado um dos processos-chave para a competitividade na manufatura. Movimentos de aumento da concorrência, rápidas mudanças tecnológicas, diminuição do ciclo de vida dos produtos e maior exigência por parte dos consumidores exigem das empresas agilidade, produtividade e alta qualidade que dependem necessariamente da eficiência e eficácia da empresa neste processo.
Situação Atual
Um dos fatores bem conhecidos sobre o processo de desenvolvimento de produto é que o grau de incerteza no início deste processo é bem elevado, diminuindo com o tempo, mas é justamente no início que se seleciona a maior quantidade de soluções construtivas. As decisões entre alternativas no início do ciclo de desenvolvimento são responsáveis por 85% do custo do produto final. O custo de modificação aumenta ao longo do ciclo de desenvolvimento, pois a cada mudança, um número maior de decisões já tomadas podem ser invalidadas. Assim, é por si só um desafio gerenciar as incertezas envolvidas num processo de desenvolvimento de produto, onde as decisões de maior impacto têm que ser tomadas no momento em que existe um maior número de alternativas e grau de incerteza. Soma-se a isto: - o fato deste processo se basear num ciclo projetar-construir-testar que geram atividades necessariamente interativas; - de ser uma atividade essencialmente multi-disciplinar (trazendo fortes barreiras culturais sobre a integração); - a existência de uma quantidade grande de ferramentas, sistemas, metodologias, soluções, etc.., desenvolvidas por profissionais/empresas de diferentes áreas, as quais não "conversam" entre si; - e a existência de diversas visões parciais sobre o processo de desenvolvimento de produtos.
Visões Parciais do Desenvolvimento de Produto
Uma grande dificuldade atual para o gerenciamento do processo de desenvolvimento de produto é a existência de diversas visões parciais . No campo de ensino e pesquisa, desenvolver produtos vinha sendo tratado de maneira isolada pelas diferntes áreas de conhecimento especializado. Portanto, ainda hoje profissionais de engenharia tendem a pensar o desenvolvimento de produto como atividades específicas de cálculos e testes (engenheiros químicos em termos de balanços de energia e dimensionamento de equipamentos, engenheiros mecânicos em termos de cálculos e desenhos necessários para processos mecânicos, etc...); " designers" ou programadores visuais como o resultado de estudos de conceito; administradores como algo mais abstrato, independente do conteúdo tecnológico e voltado para os problemas organizacionais e estratégicos; especialistas em qualidade como a aplicação de ferramentas específicas; e muitos outros que poderiam ser aqui listados. Quando transportadas para a prática estas visões podem levar a muitos problemas e ineficiências. Isto porque qualquer desenvolvimento, por maior a hegemonia de um determinado conteúdo tecnológico, implica em conhecimentos de várias destas visões. Este processo é um todo integrado que depende, para um adequado resultado final, a consideração de diversos fatores ligados às mais diversas áreas do conhecimento. Cada visão parcial carrega consigo também uma linguagem e determinados valores próprios, que dificulta a integração entre os profissionais pertencentes a cada uma dessas escolas. Enfrentar esta situação depende do desenvolvimento de uma visão holística, ou seja, da construção uma imagem única e integrada do processo de desenvolvimento de produto. A forma de representá-la empregada pelo Grupo de Engenharia Integrada é por meio do modelo de referência para o processo de desenvolvimento de produto.
Abordagens de estudo do Desenvolvimento de Produto
Existem várias abordagens propostas para a análise e intervenções no processo de desenvolvimento de produto. Elas têm origens em diferentes áreas do conhecimento, valorizando diferentes aspectos deste processo. Algumas das mais importantes são:
  • Estudos de Harvard & MIT: No final da década de 80 e início dos 90 foram desenvolvidos por pessoas ligadas a Harvard e ao MIT importantes projetos de pesquisa relacionados com a manufatura enxuta e a gestão do processo de desenvolvimento de produto. Estes primeiros trabalhos, puramente analíticos, tornaram-se clássicos e comumente referenciados na literatura sobre desenvolvimento de produto (CLARK & FUJIMOTO, 1991 e WOMACK, JONES & ROSS, 1994) e geraram muitos dos conceitos aplicados nesta área. Os conceitos gerados nesta pesquisa têm um escopo de aplicação mais amplo que uma abordagem específica. Eles são atualmente empregados por grande parte das pessoas que estudam e trabalham com o desenvolvimento de produto e, por isso têm uma importância por si próprios dentro desta área. Eles foram também a base de uma abordagem para gerenciar este processo, que é apresentada nos livros de CLARK & WHEELWRIGHT (1993a e b). Nesta abordagem os autores dividem o processo de desenvolvimento de produto em três etapas maiores: Estratégia de Desenvolvimento (onde apresenta uma estrutura para o planejamento e gerenciamento do portfólio dos projetos em andamento); Gerenciamento do Projeto Específico (abordando o gerenciamento, liderança, tipos de interação entre atividades e outros assuntos relacionados com um projeto específico); Aprendizagem (apresentando formas para garantir a melhoria do processo e a aprendizagem organizacional a partir da experiência com o projeto).
  • Stuart Pugh: A abordagem proposta por PUGH (1990 e 1996) possui uma forte influência da experiência prática que este teve trabalhando durante anos como projetista e gerente de projetos em diversas indústrias. Sua principal preocupação era com a busca de uma visão total da atividade de projeto, ou seja, que superasse as visões parciais presentes em cada setor tecnológico específico. Para atingir este objetivo ele dedicou uma grande ênfase à educação e desenvolveu um modelo, que ficou muito conhecido como Total Design. Este modelo possui um conjunto de 6 etapas todas elas interativas e aplicáveis a qualquer tipo de projeto (independente da disciplina tecnológica envolvida). Cada etapa é representada por um cilindro significando que nela são empregados um conjunto específico de conhecimentos compostos por diversas visões tecnológicas parciais.
  • Don Clausing: Este autor teve uma forte influência do trabalho de Pugh e Taguchi. Somando conceitos destes dois autores, com os quais conviveu e trabalhou, à sua própria experiência criou uma abordagem a qual denominou Total Quality Development. Nela há um enfoque muito grande para as técnicas QFD, Método Taguchi e Matriz de Pugh e para os conceitos sobre gerenciamento dos times de desenvolvimento de produto. Inclusive uma de suas principais contribuições é a de mostrar a integração entre o QFD e o método Taguchi. As fases em que ele divide o processo de desenvolvimento de produto são: Conceito (onde ele foca na metodologia do QFD); Design (divide em projeto do subsistemas e projetos das partes); e preparação/produção (dividido em verificação do sistema, prontidão e produção piloto);
  • Prasad: Este autor propõe uma sofisticada abordagem para engenharia simultânea que engloba diversos fatores em uma estrutura bastante independente das fases de um processo de desenvolvimento de produto. Ele divide a engenharia simultânea em duas rodas denominadas Organização do Produto e Processo (Product and Process Organization Wheel - PPO) e a do Desenvolvimento de Produto Integrado (Integrated Product Development Wheel - IPD).Ambas possuem no seu centro a descrição dos quatro elementos de suporte desta metodologia que são: modelos, métodos, métricas e medidas. As duas rodas possuem também um anéis intermediários idênticos que representam os times, ou a estrutura organizacional que dirige as ações dentro do processo de engenharia simultânea. A primeira roda, PPO, aborda os fatores que determinam o grau de complexidade do gerenciamento do desenvolvimento de produto e os fatores organizacionais. A segunda roda, IPD, define de uma maneira bastante flexível a integração do processo de desenvolvimento de produto.
  • APQP da QS 9000: O Manual de Planejamento e Controle da Qualidade do Produto desenvolvido dentro do conjunto de normas da QS 9000 possui uma estrutura que pode muito bem servir como referência para a estruturação e gerenciamento do processo de desenvolvimento de produto. Apesar de não ter sido desenvolvido especificamente para este fim ele resume um conjunto de preocupações, técnicas e um modelo suficientemente detalhado capazes de servir de base para intervenções neste processo.
Paralelamente a estas existe a Proposta do Grupo de Engenharia Integrada, que está em desenvolvimento e tem como objetivo fundamental promover a visão holística do processo de desenvolvimento de produto.
Definições do Processo de Desenvolvimento de Produto
"é o processo a partir do qual informações sobre o mercado são transformadas nas informações e bens necessários para a produção de um produto com fins comerciais" Clark & Fujimoto (1991). “a atividade sistemática necessária desde a identificação do mercado/necessidades dos usuários até a venda de produtos capazes de satisfazer estas necessidades – uma atividade que engloba produto, processos, pessoas e organização”. Total Design de Pugh (1990, p.5). "processo de negócio compreendendo desde a idéia inicial e levantamento de informações do mercado até a homologação final do produto e processo e transmissão das informações sobre o projeto e o produto para todas as áreas funcionais da empresa" Grupo de Engenharia Integrada
Caracterização do Processo de Desenvolvimento de Produto
Uma forma de se caracterizar o processo de desenvolvimento de produto é por meio das seguintes dimensões, as quais estão presentes no modelo de referência desenvolvido pelo Grupo de Engenharia Integrada para a FIM:
  • atividades/fases: Há muitas formas de se classificar as fases e atividades do processo de desenvolvimento de produto. Na Abordagem do Grupo EI e no modelo de referência são identificadas sete fases: Conceber Produto, Conceituar Produto, Pjojetar Produto e Processo, Homologar Produto, Homologar Processo e Ensinar Empresa. O modelo de referência apresenta as atividades dispostas em cada uma destas etapas;
  • recursos: compõe-se de todos conceitos/filosofias, métodos/técnicas e ferramentas/sistemas que podem ser aplicados no processo de desenvolvimento de produto;
  • organização: refere-se a não só a estrutura organizacional responsável e executora das atividades de desenvolvimento de produto como também os elementos como cultura, qualificação profissional, formas de comunicação entre os indivíduos, etc... , ligados aos aspectos de organização do trabalho;
  • informação:dimensão que representa o fluxo de informação existente neste processo: os dados, sua estrutura e o formato como estes circulam (relatórios, fichas, telas de computador, etc...).
Publicações importantes e referências
Belliveau, P.; Griffin, A. & Somermeyer, S. (2002), The PDMA ToolBook 1 for New Product Development, John Wiley & Sons. Cheng, L. C. (2000), Caracterização da gestão de desenvolvimento do produto, in . Clausing, D. (1994), Total Quality Development, ASME Press. Cooper, R. G. (2001), Winning at New Products, Perseus Books Group. Creveling, C. M. (2002), Design for Six Sigma in technology and product development, Prentice Hall. Griffin, A. (1997), 'PDMA research on new product development practices: updating trends and benchmarking best practices', Journal of Product Innovation Management 14(6), 429-458. Mascitelli, R. (2004), The lean design guidebook, Technology Perspectives. Pahl, G. & Beitz, W. (1993), Engineering Desgin, Springer. PMI, P. M. I. (2004), Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos, Project Management Institute. Prasad, B. (1996), Concurrent engineering fundamentals, Prentice Hall. Pugh, S. (1996), Creating innovative products using total design, Addison-Wesley. Rosenau, M. D. (1996), The PDMA handbook of new product development., John Wiley & Sons. Rozenfeld, H.; Forcellini, F. A.; Amaral, D. C.; Toledo, J. C.; Silva, S. L. d.; Allipradini, D. H. & Scalice, R. K. (2006), Gestão de Desenvolvimento de Produtos, Saraiva. Wheelwright, S. C. & Clark, K. B. (1992), Revolutionizing product development, The Free Press. Womack, J.; Jones, D. T. & Roos, D. (2004), A máquina que mudou o mundo, Campus.
DFMA(Design for Manufaturing and Assembly) http://www.portaldeconhecimentos.org.br/index.php/content/view/full9447
Definição
Segundo BOOTHROYD e DEWHURST (1988), Design for Manufacture, DFM, significa diferentes coisas para diferentes pessoas... A chave para o sucesso da aplicação de DFM é a simplificação da manufatura do produto. Enquanto que as técnicas de DFA primeiramente objetivam a simplificação da forma do produto, assim os custos com a montagem são reduzidos. Assim, temos que DFMA é uma filosofia que se utiliza de diversos conceitos, técnicas, ferramentas e métodos para aperfeiçoar a fabricação de componentes ou simplificar a montagem de produtos, utilizando para tal desde a análise de valores de tolerâncias, a complexidade do produto, número mínimo de componentes necessários, layout do produto dentre outros. DFM traduz a busca durante o projeto, em tornar mais fácil a manufatura dos componentes que formarão o produto depois de montado. Enquanto DFA tem por objetivo tornar a montagem do produto o menos custosa e mais otimizada possível.
Utilização
O DFMA pode ser utilizado na análise de produtos em manufatura. Neste caso o produto é desmontado e montado novamente dando ênfase a tempos e custos de manuseio (alimentação e orientação) e junção (inserção) de componentes. Os tempos e custos podem ser encontrados em tabelas, ou através da utilização de softwares específicos ou ainda por observações empíricas. DFMA pode também ser usado durante o desenvolvimento de um produto, visando a otimização e adequação aos meios de montagem e inspeção.
Princípios do DFMA
Existem algumas regras de boa conduta sugeridos pelo DFMA:
  • Projetar para um número mínimo de componentes;
  • Projetar componentes para serem multifuncionais;
  • Utilizar componentes e processos padronizados;
  • Desenvolver uma abordagem de projeto Modular;
  • Utilizar uma montagem empilhada/Uni-direcional;
  • Facilitar alinhamento e inserção de todos os componentes;
  • Eliminar parafusos, molas, roldanas, chicotes de fios;
  • Eliminar ajustes;
  • Procurar padronizar materiais, acabamentos e componentes;
  • Ter sempre em mente as possibilidades de automação;
  • Utilizar e promover o trabalho em equipe.
Existe ainda uma medida da eficiência de um projeto, considerando sua montagem. Assim é calculado a partir de tabelas de tempos e custos, um índice que avalia a qualidade de seu projeto para montagem. Este índice relaciona o número teórico mínimo de todas as peças necessárias, com o tempo total para a montagem das peças. Isso multiplicado por 3, valor característico para um tempo médio padrão para uma montagem livre de embaraços. Deve-se ressaltar a necessidade de avaliar bem a necessidade de um componente, devendo sempre procurar reduzir ao máximo o número de componentes do produto final. Para tal, pode-se fazer uso de três regras básicas para verificar a necessidade de determinado componente: Deve-se então valer da possibilidade de integrar componentes quando possível, pois componentes integrados não precisam ser montados, e geralmente possuem menor custo de fabricação comparados com a soma dos custos das peças separadas.
Exemplos e Aplicações
A seguir segue alguns exemplos de aplicação do DFMA. Nas figuras seguintes, observa-se regras de projeto visando maximizar a facilidade da montagem, reduzindo assim seus custos. Na figura 1 temos a "montagem por cima", caracterizada pela inserção de todos os componentes de um conjunto de tal maneira que eles se encaixem um sobre o outro. Figura 1 - Montagem dos componentes por cima. E na figura 2 temos o "auto alinhamento", onde para facilitar o encaixe entre componentes é realizado desde perfis arredondados a chanfros ou então furos guias. Figura 2 - Montagem utilizando o auto-alinhamento. Na figura 3 observamos a utilização de indicações para orientar a montagem de componentes assimétricos. Figura 3 - Uso de indicações para facilitar a montagem em peças assimétricas No caso de simétricos, como na figura 4, não existe essa necessidade Figura 4 - Peças simétricas em relação a suas possibilidades de montagem.
Livros
BOOTHROYD, G.; DEWHURST, P. (1988). Product design for manufacture and assembly. Manufacturing Engineering, p. 42-46, abril. BRALLA, J. G. (1996). Design for excellence. New York: McGraw-Hill. ( Disponível na EESC - USP ). BRALLA, J. G. (1986). Handbook of product design for manufacturing, McGraw-Hill, Inc., New York, NY, USA.( Disponível na EESC - USP ).
Sites Relacionados
DFMA - Design for Manufacture and Assembly Home Page by Boothroyd Dewhurst, Inc.
Datawarehouses http://www.portaldeconhecimentos.org.br/index.php/content/view/full10286
Introdução
O que é datawarehouse? Uma boa definição seria a de Gupta (1997): "um ambiente estruturado, extensível, projetado para a análise de dados não voláteis, lógica e fisicamente transformados, provenientes de diversas aplicações, alinhados com a estrutura da empresa, atualizados e mantidos por um longo período de tempo, referidos em termos utilizados no negócio e sumarizados para análise rápida". De forma bastante esquemática, a Figura 1 mostra a arquitetura de um datawarehouse, com os sistemas que o alimentam, seus usuários, o DW propriamente dito e os metadados - cada um desses conceitos será melhor apresentado mais à frente: Figura 1 – Arquitetura de um Datawarehouse Do início da década de 90 até os dias de hoje, o conceito e a operação de um data warehouse saíram do âmbito teórico, acadêmico, para a área empresarial, notando-se uma clara tendência no sentido de sua adoção por praticamente todas as empresas que operam em ambientes competitivos - as instituições financeiras, por exemplo, estão começando a fazer uso intensivo desse recurso. Antes da popularização dos data warehouse e das ferramentas ERP (Enterprise Resource Planning), uma verdadeira integração de dados era apenas um sonho - sistemas trocavam dados na forma que atendesse às necessidades de cada um deles, sendo por isso chamado "sistemas integrados", sem que essa integração sequer se aproximasse do que se vê hoje nos ERP, cujos fornecedores tem sistematicamente dado a seus produtos características que os tornam facilmente fornecedores de dados aos warehouses. Cada aplicativo tinha uma visão do que era um cliente, um produto ou ou uma operação; uma visão corporativa das informações disponíveis era praticamente ficção. Dados históricos não existiam de forma organizada e os dados sintéticos disponíveis mostravam quase sempre apenas uma pequena parte da realidade da empresa. ERP e datawarehousing podem suprir estas insuficiências, integrando dados, provendo dados históricos, e permitindo a recuperação de informações de forma sintética ou analítica. A integração dos dados permite a um executivo ter uma visão "corporativa" dos dados; essa integração, ou mais especificamente a migração dos dados mantidos pelos sistemas anteriores, no entanto, não é um processo fácil, nem barato - exige muito planejamento e diz-se que seu custo é 75% do investimento necessário à implantação do warehouse - o assunto é tratado minuciosamente por Inmon (1996). Há algumas versões de datawarehouse que merecem ser individualizadas por suas características especiais: uma delas, é o Operational Data Store (ODS), que opera diretamente conectado aos dados operacionais, objetivando dar suporte a decisões de natureza operacional, com características que permitem a obtenção de tempos de resposta bastante rápidos, algo que um data warehouse clássico não consegue prover. Os data marts (DM) podem ser considerados data warehouses departamentalizados; filosoficamente, são bastante semelhantes àqueles, porém com algumas características peculiares, como por exemplo menor volume de dados e padrão de uso bastante previsível - necessitam tecnologia mais simples e barata, face a esse menor volume e a esse padrão previsível, e tem poucos dados detalhados. Os data marts poderiam ser vistos esquematicamente conforme a Figura 2, que mostra aplicações hipotéticas alimentando data marts voltados para usuários específicos. Os data marts tem muito apelo, porque eles podem ser construídos de forma simples, rápida e barata - já se fala inclusive em "canned data marts", ou "data marts enlatados", que seriam ferramentas extremamente simples e baratas, destinadas a atender a necessidades bastante estruturadas (Radding, 1999). Durante algum tempo, esses data marts independentes foram muito populares. Mas, logo sua arquitetura se mostrou falha: quando uma corporação construía vários desses data marts, o volume de redundância de dados (quase sempre dados analíticos) crescia muito, como crescia o número de programas que faziam o interface entre essas estruturas e os sistemas legados; também cresciam os recursos de hardware envolvidos. Já do ponto de vista da organização, o problema maior talvez seja o de se ter áreas tomando decisões a partir de números diferentes, gerados em função da redundância - quer por erros, quer por diferentes graus de atualização ou critérios de tratamento de dados (o exemplo clássico, embora possa não ser o melhor para esse tema, é o arredondamento versus truncamento de valores). Figura 2 – Arquitetura de data marts Constatada essa realidade, percebeu-se que os data marts independentes não eram a solução, evoluindo-se então para o conceito de data marts dependentes. Em uma arquitetura desse tipo, há um warehouse central que alimenta os marts dependentes; é chamada também arquitetura " hub-and-spoke" (cubo-e-raio), onde os marts são os raios e o warehouse, o cubo. Como vantagens dessa estrutura, apresenta-se a integração de dados no cubo e autonomia de processos e nenhuma redundância de dados nos raios. Os padrões gerais de design de banco de dados ditaram os caminhos de evolução e sofisticação do ambiente de warehousing; em seus primeiros tempos, a normalização de dados clássica era a base para a estruturação; quando a arquitetura cubo-e-raio evoluiu, o padrão passou a ser a normalização e "star join" para o cubo e 'snowflake" para os raios. Uma vez que o warehouse já esteja construído, a próxima etapa será sua exploração, no sentido de buscar, utilizar, as informações nele contidas. Esse trabalho, que é chamado "data mining", permite descobrir padrões importantes, relações de causa e efeito que vinham passando desapercebidas, tendências a longo prazo, etc., de forma a permitir a melhoria dos processos. Uma pergunta interessante que quase imediatamente surge é: pode-se fazer data mining sem um warehouse, atuando sobre os sistemas operacionais? Existe tecnologia para isso? A resposta é que "algum" data mining pode ser feito sem warehouse, mas para "efetivo" mining, warehousing é absolutamente essencial, porque a tecnologia de warehousing prepara os dados brutos para a análise - e isso traz muitos benefícios, porque:
  • uma das características básicas do warehouse é que os dados são integrados à medida em que são armazenados. Isso implica em uniformidade e continuidade de conceitos da empresa: o que é um cliente, um produto, uma transação e assim por diante. Dispondo-se do warehouse, pode-se partir imediatamente para análise, o que não aconteceria numa situação diferente, em que os dados precisariam ser coletados, "limpos" (esse processo de limpeza é conhecido como "data scrubbing") e a seguir juntados para análise - esse processo, quase sempre completamente desestruturado, pode tomar tanto tempo que, ao estar pronto, já tenha sido superada a necessidade de análise (e talvez perdida uma oportunidade preciosa para a organização);
  • além disso, datawarehousing coleciona e organiza dados de forma sistemática, formando uma base de dados históricos - quando ele não é utilizado, e há necessidade de dados históricos, além das dificuldades acima pode-se descobrir que eles simplesmente não existem, e
  • o warehouse contém os dados analíticos e também os sintéticos, e estes podem ser úteis no início de um processo de análise, quando ainda está se planejando um estudo qualquer, especialmente por permitir ganhar tempo nessa fase, ajudando-se a escolher certos caminhos ou descartando-se outros.
Outro tema que vem mostrando sua importância são os metadados - uma definição simples diria que metadados são dados a respeito de dados: como, quando e por quem foram coletados, e como são formatados. Metadados não eram utilizados na primeira geração de warehouses, principalmente porque os usuários tinham pressa em colher os resultados da nova tecnologia, tendo porisso concentrado seus esforços em carregar seus dados; hoje, à medida em que os usuários e administradores dos warehouse amadurecem, pode-se notar cada vez mais ênfase no assunto, evidentemente produto da experiência que se ganhou, fazendo com que os metadados venham se tornando uma ferramenta importante para melhor uso dos warehouses. As ferramentas disponíveis para acesso às informações devem se tornar mais poderosas, principalmente face aos imensos volumes de dados com que terão que se relacionar - isso é válido para gerenciadores de bancos de dados, planilhas e outras ferramentas manejadas pelo usuário final - imagine-se um usuário final tentando rodar uma query que exija a criação de uma tabela temporária com o produto cartesiano de duas tabelas de um milhão de linhas cada...(nesse caso específico, há ferramentas que permitem evitar a degradação que uma query como essa geraria num sistema convencional). Os grandes volumes também impactam a armazenagem de dados (financeira e tecnologicamente) em termos de discos magnéticos, seu ambiente padrão na atualidade. Amadurece porém o conceito de que o datawarehouse não precisa estar necessariamente on-line - algo como "near-line" ou quase em linha, talvez seja satisfatório, e é possível que hardware e software near-line surjam. Uma das técnicas utilizadas para minimizar esses problemas e otimizar o data mining, é a regra conhecida como "80/20" – pode-se afirmar que em qualquer banco de dados muito grande, 80% da informação pode ser encontrada em 20% dos dados – assim, de acordo com a regra, a base de dados pode ser particionada e o volume a ser processado para análise diminui; se ainda assim o volume a ser analisado for muito grande, amostras podem ser coletadas para análise, até que se tenha um conjunto viável e representativo. A Figura 3 ilustra essa regra. Figura 3 – Regra 80/20 Finalizando, cabe reafirmar que este é um assunto que continua evoluindo, e que apesar do relativamente curto espaço de tempo decorrido desde que as ferramentas para datawarehousing se tornaram populares, elas já são consideradas componentes essenciais da arquitetura de Tecnologia da Informação de toda organização de porte.
Artigos
Radding, Alan (1999), "It's in the can: Analytical applications simplify back-end datamarts", in "Datamation", edição de janeiro de 1999.
Livros
Downes, Larry e Mui, Chunka (1998), "Unleashing the Killer App: Digital Strategies for Market Dominance", Harvard Business School Press. Inmon, William H. (1996), "Building the Data Warehouse", John Wiley & Sons. Miller, Stewart S. (1998), "Accelerated SAP", McGraw-Hill Gupta, Vivek R. (1997) "An Introduction to Data Warehousing", in http://www.system-services.com, em 24.08.98. Fornecedor de soluções datawarehouse. Data Warehousing Knowledge Center. Http://www.datawarehousing.org. Centro de Informações e tecnologias de datawarehouse.
Design Review Based on Failure Mode (DRBFM) http://www.portaldeconhecimentos.org.br/index.php/content/view/full9418
Objetivos do DRBFM
- Guiar o engenheiro de design, de maneira acertada, sistemática e criativa, durante todas as fases de um projeto de alteração; - Atingir um design robusto para um processo robusto, de maneira precoce, ainda na fase de design; - Fazer com que, além dos engenheiros de design, a produção, compra, entregador e clientes também participem do processo de alteração; - Conectar ativamente o engenheiro de design ao processo de qualidade e, com isso, terminar com a separação entre o processo de qualidade e o processo de desenvolvimento.
Definições
DRBFM (Design Review Based on Failure Mode) é um método para descobrir problemas e desenvolver medidas preventivas notando e discutindo modificações intencionais (design modifications) e modificações incidentais (changes in part environment). O método encoraja a habilidade do ser humano em achar problemas, e é uma ferramenta prática baseada no FMEA e FTA. É um método de criatividade que acompanha o desenvolvimento e, ao mesmo tempo, uma filosofia para descobertas de design discurso-orientada, ou seja, avaliação de design. O método garante que os produtos mantenham a alta qualidade mesmo após uma modificação. O DRBFM originou-se no reconhecimento de que as modificações trazem consigo o maior potencial de falhas, independentemente se os processos ou sistemas são modificados devido a custos, pressão por inovação ou por novas demandas de produtos. Não obstante, o DRBFM traz um complemento para as possibilidades de falhas e análises de influência (FMEA) e avalia as mesmas através disto. As possibilidades de falhas e informações de FMEA precedentes podem se desejadas, ser utilizadas na análise DRBFM.
Histórico
DRBFM foi desenvolvido na Toyota Motor Corporation por Tatsuhiko Yoshimura, o qual foi, por 32 anos, responsável pela confiabilidade na Toyota. A filosofia por trás do método chama-se GD3 (Cubo GD) ou filosofia Mizen Boushi (traduzindo rudemente: medidas de prevenção). GD3 é abreviação para: Good Design, Good Discussion e Good Dissection. DRBFM é utilizado na filosofia Mizen Boushi para guiar discussões de modos de falhas potencial e causas raiz, e examinar desenhos de protótipos de peças.
Aplicação
O método encoraja a habilidade do ser humano em achar problemas, e é uma ferramenta prática baseada no FMEA e FTA. É amplamente aplicável: tanto desenvolvimento de novas peças, peças envolvendo modificações de engenharia, sistemas, ou sub-componentes.
Abordagem
A abordagem para DRBFM é dividida em duas fases: a fase de análise ("FMEA criativo") e a fase Design Review. Na fase de análise, de um lado as modificações e suas potenciais falhas são compiladas para as funções e a aplicação das exigências. Do outro as possíveis causas de falha e efeitos recíprocos são identificados e as providências para sua eliminação são especificadas no projeto. O resultado desta fase é um projeto robusto, que documenta a base de cada etapa de criação e de desenvolvimento. Durante a fase seguinte de Design Review o projeto robusto é reconstruído e examinado a fim de definir outras falhas potenciais. Na fase de análise os riscos de qualidade verificados são melhorados construtivamente e tentativas são planejadas a fim de comprovar a robustez com as amostras necessárias. Ao mesmo tempo ocorre o ajuste com a produção. A ferramenta de base para ambas as fases dá forma ao formulário de trabalho de DRBFM, no qual os resultados da discussão (análise) e as providências encontradas são documentados detalhadamente (DRBFM worksheet). Procedimentos adicionais de trabalho devem ser documentados em outras tabelas, ou seja, em ferramentas para uma melhor visão geral. Além disso, há, entre outras coisas, a comparação das modificações do sistema e/ou das funções na comparação com o produto predecessor.
O método faz com que:
- o foco seja nas alterações, - a concentração do trabalho de desenvolvimento seja somente nos aspectos críticos do produto, - uma distribuição de tarefas entre o engenheiro de design e a equipe de review torne-se uma aplicação efetiva de alterações com verificação e divulgação simultâneas dos resultados, - as alterações não sejam consideradas isoladamente, mas como um conjunto no sistema, ou seja, que os produtos sejam considerados sistematicamente e como um todo, - o gerente de projeto tenha uma visão geral sobre o status de todas as alterações no projeto, que o mostre, de maneira rápida, se estas estão resolvidas, críticas ou rejeitadas e por quais motivos.
Fontes
SCHMITT, R.; KRIPPNER, D.; BETZOLD, M. Geringere Fehlerkosten – höhere Zuverlässigkeit. Qualität und Zuverlässigkeit, Jahrgang 51, Ausgabe 06, p.66 - 68, 2006. SCHMITT, R. et al. Keine Angst vor Änderungen! Robustes Design für innovative Produkte. Qualität und Zuverlässigkeit, München, Jahrgang 52, Ausgabe 03, p.24 - 26, 2007. SCHORN, M.; KAPUST, A. Im Fluss: Wie Toyota von DRBFM Profitiert. Qualität und Zuverlässigkeit, München, Ausgabe 04, p.56 - 58, 2005. SHIMIZU, H.; IMAGAWA, I.; NOGUCHI, H. Reliability Problem Prevention Method for Automotive Components - Development of GD3 Activity and DRBFM (Design Review Based Failure Mode). In: INTERNATIONAL BODY ENGINEERING CONFERENCE, 2003, Chiba, Japan. Proceedings... Chiba: SAE International, 2003. p.371 - 376.
Sites
WZL RWTH Aachen: Projekt DRBFM – Design Review Based on Failure Mode http://www.drbfm.com/
Forums
Elsmar/Forums/DRBFM
Softwares
SCIO™-DRBFM
Cursos
DRBFM Seminare 2008 International Applied Reliability Symposium 2008
  • Change Point Analysis and DRBFM: A Winning Combination
International Applied Reliability Symposium 2007
  • Design Review Based on Failure Modes - DRBFM
Melhores práticas relacionadas
FMEA , FTA , Mizen Boushi (GD3)
ECM - Engineering Change Management http://www.portaldeconhecimentos.org.br/index.php/content/view/full9456
Introdução
O processo de desenvolvimento de produtos vem sendo alvo de inúmeras melhorias, como conseqüência direta da disputa pelo mercado. As empresas lutam para serem as primeiras a colocar seus produtos e para atender mais prontamente e a uma variedade maior de necessidades dos clientes. Este fato e a necessidade de se incorporar novas tecnologias a produtos cada vez mais inovadores, fazem com que mudanças do produto não possam ser evitadas e a capacidade de incorporar mudanças transformou-se em arma poderosa.
Definições
Modificação de Engenharia Modificação de engenharia é qualquer alteração em uma peça ou conjunto existente no produto, e que afete a forma, interface ou função do mesmo. Observe que a definição é tão geral que não faz distinção entre uma simples revisão e um projeto totalmente novo. Os motivos para uma modificação de engenharia incluem a correção de erros de projeto, melhorias na fabricação ou montagem das peças, melhorias que se tornam necessárias pela ação da concorrência e alterações exigidas pelos clientes. O projeto de produtos se comporta de forma evolucionária e até mesmo a melhor engenharia não seria suficiente para desenvolver um item que não requisitasse modificações durante o seu ciclo de vida. Todavia, as mudanças devem ser gerenciadas para minimizar rupturas ao processo de desenvolvimento de produto (Bedworth, 1990).
"Engineering Change Management" (ECM)
Gerenciamento de modificações de engenharia é o processo que estabelece como as modificações de engenharia são encaminhadas, autorizadas, solucionadas, avaliadas, aprovadas e liberadas para serem introduzidas na produção (seja de protótipos como de série). O processo de modificação de engenharia é considerado um problema de primeira ordem no processo de desenvolvimento de produto (Barkan, 1992). Portanto, é necessário que seja desenvolvida uma investigação profunda das modificações, suas fontes e os possíveis meios de gerenciamento. Esse processo é tão importante que foi sugerido por Barkan como sendo um essencial item de controle para medição da eficácia de toda operação de projeto - abrangendo desde a concepção até a implementação detalhada do mesmo. As conseqüências das modificações de engenharia podem afetar funções além das de engenharia e causar danos no planejamento e execução em virtualmente todos os segmentos do projeto em execução.
Processo de ECM
Algumas propostas de processo de ECM foram apresentadas ao longo dos anos (Benedetto, 1999; Carvalho, 1999; Balcerak, 1992; Smith, 1985; DiPrima, 1982; Huge, 1977) descrevendo, uns mais e outros menos, a preocupação com a integração das funções do ciclo de desenvolvimento. Na maioria das propostas, a preocupação está em garantir a integridade da informação já em estágios avançados de desenvolvimento. O modelo descrito a seguir está sendo implementado na indústria automotiva e tem como preocupação, inserir o processo de ECM já no início do ciclo de vida do produto, ou seja, na etapa de projeto onde o comprometimento com o custo total do projeto é estabelecido e onde há, atualmente, uma deficiência de formalismo para tratar deste assunto.
Organização
O processo de ECM incorpora algumas novas funções na organização dos projetos:
  • Originador do Pedido de Modificação de Engenharia (PME)
  • Comitê de Controle de Modificações de Engenharia
  • Gerente de Modificações de Engenharia
  • Coordenador do PME
  • Avaliadores de PME
Originador do Pedido de Modificação de Engenharia Qualquer pessoa ligada ao desenvolvimento do produto pode iniciar o processo emitindo um Pedido de Modificação de Engenharia para apresentar um problema. Comitê de Controle de Modificações de Engenharia (CCM) As reuniões de avaliação de PMEs podem se tornar mais produtivas se adotados dois tipos de comitê de modificações. O CCM I seria responsável pela:
  • Pré análise do PME (aceitando ou rejeitando-o)
  • Identificação de todas as áreas envolvidas na solução do PME
  • Classificação e priorização da solução do PME
  • Revisão final do PME
  • Assinatura e fechamento do PME
E o CCM II para:
  • Analisar a solução do PME e o seu impacto (custos, prazos, peso, etc.), e aprová-la
  • Definir a efetividade do PME e da Ordem de Engenharia (OE)
  • Autorizar a execução das modificações de projeto
CCM I é constituído de representantes da Engenharia, Produção, Integração de Projeto e o Gerente de Modificações de Engenharia. O CCM II, além destes, tem ainda representantes da Controladoria, de Compras, de Marketing e de Suporte ao Produto. Gerente de Modificações de Engenharia É um membro especial do CCM. Coordena um pequeno grupo com as seguintes atribuições:
  • Verificar se o PME está corretamente preenchido e completo
  • Endereçar o PME para o seu coordenador
  • Acompanhar os prazos de execução do PME
  • Produzir relatórios estatísticos e de status para o CCM
  • Preparar a agenda e moderar as reuniões de CCM
Coordenador do PME O coordenador do PME é responsável por:
  • Coordenar a solução do PME nos times de engenharia
  • Solicitar as avaliações do PME
  • Preparar o PME para encaminhar ao CCM
Avaliadores de PME São responsáveis por:
  • Avaliar a solução do PME identificando todo o seu efeito.
Descrição do Processo
Modificações de engenharia são iniciadas através da emissão de um PME por qualquer pessoa ligada ao desenvolvimento do produto. O PME é encaminhado ao CCM I que pode rejeitar ou aceitar o pedido. Aceito, ele é classificado e priorizado. Nesta etapa também é definido o Coordenador do PME. O pedido é solucionado pelos Times de Engenharia envolvidos, que realizam estudos em CAD e as análises necessárias: “Finite Element Analysis” (FEA), de interferências e distâncias mínimas em mock-up digital (DMU), ergonomia, etc. A solução é encaminhada aos avaliadores que investigam todo o impacto da modificação. É estimado o novo custo do produto, o novo peso, os novos prazos para desenvolvimento. Nestas avaliações são envolvidos os fornecedores e parceiros afetados, seja por modificação de peças ou de ferramentais. Concluídas a solução e as avaliações, o PME é apresentado ao CCM II que pode aprovar, solicitar nova solução ou encerrar o PME se este não for mais aplicável. O PME aprovado tem sua implementação planejada, com a definição da sua efetividade. Alguns PMEs que alteram as mesmas peças ou conjuntos e que podem receber a mesma efetividade são reunidos em uma Ordem de Engenharia (OE). A OE é o documento usado para a definição de todas as peças e desenhos afetados pela modificação de engenharia, e usado para a liberação destes dados para a produção. Planejada, a modificação passa a ser executada pelos projetistas. O responsável pela documentação prepara a estrutura do produto (BoM) para receber os modelos de CAD que os projetistas estão criando ou revisando. O responsável pela documentação verifica e libera os desenhos e demais documentos revisados e criados. Todos estes dados são armazenados nos arquivos adequados. Empresas que ainda não utilizam sistemas de PDM mantém arquivos centrais com os originais assinados dos desenhos de produto, e se utilizam de arquivos distribuídos de cópias, geralmente em microfilmes. Os PMEs e a OE correspondente são encaminhados para o CCM I para
Formulários de PME e de OE
O PME pode conter os seguintes campos:
  • Preenchidos pelo originador: identificação do originador, a descrição do problema, uma sugestão de solução
  • Pelo CCM I: classificação, prioridade, coordenador, assinaturas e datas
  • Pelo Coordenador do PME: descrição da solução
  • Pelos avaliadores: alterações de custos, peso, prazos, etc.
A OE pode compreender os campos:
  • Preenchidos pelo engenheiro ou projetista responsável: identificação do engenheiro/projetista, descrição da modificação, tabela de peças afetadas, assinaturas e datas
  • Pelo CCM II: prioridade da implementação na produção, efetividade, assinaturas e datas.
Novo Número de Peça ou Revisão
Ao se modificar uma peça ou conjunto deve-se decidir entre usar um novo número de peça ou criar uma revisão do antigo número. Normalmente, quando a peça modificada e a anterior não são intercambiáveis, a peça modificada recebe um novo número. Sendo intercambiáveis, aplica-se uma revisão ao desenho da peça ou, na própria peça, caso se use um sistema de gerenciamento de dados de produto. O mesmo critério deve ser aplicado nas próximas montagens em que a peça modificada aparece na estrutura do produto, revisando ou re-identicando os conjuntos. Muitas vezes, os efeitos de uma modificação são propagados para outras peças, pertencentes a outros conjuntos (em outros ramos da estrutura do produto) por estarem próximas ou terem interfaces. Neste caso, estas peças e suas próximas montagens podem ser revisadas ou re-identificadas também. Se a peça modificada é montada em um componente aplicável a vários produtos (e a estruturas de produto diferentes) deve-se avaliar os efeitos em todos estes produtos.
Efetividade
A efetividade de uma modificação de engenharia define a partir de e até quando ela é válida. Pode ser definida ou por datas ou por números de série (ou lote). Usando-se datas, a peça substituída recebe uma data de fim de efetividade, que é o último dia em que pode ser usada no produto. A partir desta data, a peça antiga deve ser substituída por uma nova que recebe a mesma data como a de seu início de efetividade. Efetividades definidas por números de série, determinam os lotes, ou produtos acabados, que serão afetados pela modificação de engenharia, independentemente do tempo. Os módulos de produção dos sistemas de “Enterprise Resource Planning” (ERP) usam a estrutura de produto e as efetividades para explodir as ordens de fabricação planejadas e definir as necessidades brutas até o nível de peças individuais.
Benefícios
O sucesso dos negócios é muito influenciado pela forma que a informação é liberada do projeto e engenharia para a produção, e como as modificações são processadas pelo departamento de engenharia (Kooy, 1986). As empresas cobram das áreas de projeto e engenharia o desenvolvimento dos melhores produtos, liberados no menor tempo possível para a produção. A implementação efetiva de sistemas de ECM garante informações de engenharia acuradas e atualizadas, disponibilizadas a todas as áreas. Um processo formal de ECM deve reduzir:
  • atrasos causados pela cópia e distribuição da informação entre departamentos,
  • a possibilidade que diferentes departamentos estejam usando diferentes versões da informação,
  • o tempo despendido na coleta de documentos e arquivos de diferentes locais.
Um processo otimizado de ECM garante a integridade e a velocidade nas trocas de dados de engenharia. Assegura que os sistemas de ERP usem um arquivo mais acurado de BoM. Erros nas estrutura de produto podem causar a compra de componentes que não são mais necessários, assim como não comprar os componentes certos, resultando tanto em excesso como em falta de estoque. Além disso, a maior velocidade no processo de modificações ajudará as empresas a responder muito mais rápido as mudanças das condições de mercado. Falhas no gerenciamento de modificações de engenharia resultam na introdução não controlada de novos projetos e modificações, que podem levar a deterioração dos objetivos corporativos, considerando o tempo para atingir o mercado e aumento considerável na taxa de retrabalho, de perda de material e de geração de projetos desatualizados (Maull, 1992). A operacionalização de um Comitê de Controle de Modificações é fator de integração entre as diferentes áreas participantes e contribui para a prática de Engenharia Simultânea.
Quando Iniciar o Processo Formal
As primeiras empresas a instalar sistemas de MRP, logo perceberam a necessidade de adotar um processo formal de ECM na fase de produção do ciclo de vida do produto. Mas, durante a fase de projeto, o papel do comitê de controle de modificações era delegado ao engenheiro responsável pelo projeto, o PME não existia, e a OE era emitida a partir da primeira liberação para a produção. O uso de mock-up digital e de sistemas de PDM estão levando à formalização de um processo de ECM já durante a fase de projeto (Carvalho, 1999). Neste caso, o processo pode ser implementado a partir da aprovação da concepção do produto, adotada como ponto de partida para a emissão de PMEs. Estabelecendo uma comunicação eficiente entre os engenheiros de projeto e as demais funções envolvidas no desenvolvimento o uso de um processo formal de ECM na fase de projeto reduz o ciclo e o custo de desenvolvimento e eleva a qualidade do produto. Além disso, estabelece uma “base line” dos dados requeridos para FEA, DMU, construção e teste de protótipos. Assegura também que toda modificação seja adequadamente analisada e estabelece um banco de dados de histórico de projeto. Durante a fase de projeto, as decisões do CCM são dirigidas para atender os planos de construção e teste de protótipos.
Artigos
BALCERAK, K.J. and DALE, B.G. (1992), “Engineering Change Administration: The Key Issue”, Computer-Integrated Manufacturing Systems, Volume 5, 125-132. BARKAN Philip, (1992). “Productivity in Process of Product Development - An Engineering Perspective”. Integrating Design and Manufacturing for Competitive Advantage - Vol. 1, 56-58 BEDWORTH, David D., HENDERSON, Mark R., WOLFE, Philip M., (1990). “Computer Integrated Manufacturing” - McGraw-Hill International Edition - Vol. 1, 599-610. BENEDETTO NETO, H., TRABASSO, L. G. (1997). “Proposal of a framework for efficient management of the engineering change (EC) process”. XIV Congresso Brasileiro de Engenharia Mecânica, Baurú, SP, Brasil. BENEDETTO NETO, H., TRABASSO, L. G. (1999). “Identification of Factors that Affect ECM - Engineering Change Management”. ICED99 - International Conference on Engineering Design, 12th Conference, Munich, Germany. CARVALHO, SERGIO de S. A. (1999). (debis humaitá IT Services Latin America) “Engineering Change Management in the Product Developmenr Phase, an Industrial Case Study”. European Concurrent Engineering Conference, Erlanden-Nuremberg, Germany DIPRIMA, M.R. (1982), “Engineering Change Control and Implementation Considerations”, Production and Inventory Management, 81-87. HUGE, E.C. (1977), ‘‘Engineering Change Control’’, APICS - American Production & Inventory Control Society - 20th Conference Proceedings, Volume 1, 81-93. INSTITUTE OF CONFIGURATION MANAGEMENT (1996). “Change Boards and Change Administration”. KOOY, C. (1986). "Expectations of future production strategies taking into account rapidly advancing technical developments". First European Congress on Technical Production Management, Stuttgart, Germany. MAULL, Dr. ROGER, Prof. HUGHES, DAVID and BENNETT, JAN (1992). "The role of the bill-of- materials as a CAD/CAPM interface and the key interface of engineering change control.", Computing & Control Engineering Journal, March. SMITH, D.A.(1985), ‘‘Establishing a Successful Engineering Change Management Procedure’’, APICS – American Production & Inventory Control Society - 28th Conference Proceedings, Volume 1, 24-25.
Engenharia Simultânea http://www.portaldeconhecimentos.org.br/index.php/content/view/full9945
Introdução
O surgimento de novas tecnologias e a crescente complexidade dos produtos, entre outros fatores, resultam em aumento do lead time de desenvolvimento de produtos. No entanto, para se manterem competitivas, as empresas precisam lançar novos produtos em espaços de tempo cada vez menores. Nesse sentido, as empresas passaram a procurar formas de reduzir seu ciclo de desenvolvimento de produtos. Uma das soluções adotadas pelas empresas, no início dos anos 80, foi o aumento do grau de paralelismo das atividades de desenvolvimento. Atividades que eram realizadas somente após o término e aprovação das atividades anteriores são antecipadas de forma que seu início não dependa dos demorados ciclos de aprovação. Em 1982 foi iniciado um estudo, conduzido pelo DARPA ( Defense Advanced Research Project Agency), sobre formas de se aumentar o grau de paralelismo das atividades de desenvolvimento de produtos. O resultado desse trabalho, publicado em 1988, definiu o termo Engenharia Simultânea, tornando-se uma importante referência para novas pesquisas nessa área.
Definição de Engenharia Simultânea
O estudo realizado pelo DARPA definiu Engenharia Simultânea da seguinte forma (WINNER et al., 1988 apud PRASAD, 1996): "Engenharia Simultânea é uma abordagem sistemática para o desenvolvimento integrado e paralelo do projeto de um produto e os processos relacionados, incluindo manufatura e suporte. Essa abordagem procura fazer com que as pessoas envolvidas no desenvolvimento considerem, desde o início, todos os elementos do ciclo de vida do produto, da concepção ao descarte, incluindo qualidade, custo, prazos e requisitos dos clientes." A partir dessa definição surgiram muitas outras. O conceito de Engenharia Simultânea tornou-se muito mais abrangente, podendo incluir a cooperação e o consenso entre os envolvidos no desenvolvimento, o emprego de recursos computacionais (CAD/CAE/CAM/CAPP/PDM) e a utilização de metodologias (DFx, QFD, entre outras). Outras definições de Engenharia Simultânea são:
  • "Engenharia Simultânea é uma abordagem sistemática para o desenvolvimento integrado de produtos que enfatiza o atendimento das expectativas dos clientes. Inclui valores de trabalho em equipe, tais como cooperação, confiança e compartilhamento, de forma que as decisões sejam tomadas, no início do processo, em grandes intervalos de trabalho paralelo incluindo todas as perspectivas do ciclo de vida, sincronizadas com pequenas modificações para produzir consenso" (ASHLEY, 1992 apud PRASAD, 1996)
  • "Engenharia Simultânea é um ambiente de desenvolvimento, no qual a tecnologia de projeto auxiliado por computador é utilizada para melhorar a qualidade do produto, não somente durante o desenvolvimento, mas em todo ciclo de vida" (ELLIS, 1992 apud PRASAD, 1996)
  • "Engenharia Simultânea é uma metodologia de desenvolvimento de produtos, na qual vários requisitos ( X-abilities) são consideradas parte do processo de desenvolvimento de produtos (manufatura, serviço, qualidade, entre outros). Esses requisitos não servem somente para se atingir as funcionalidades básicas do produto, mas para definir um produto que atenda todas as necessidades dos clientes" (HARTLEY, 1992 apud PRASAD, 1996)
  • "Engenharia Simultânea é a integração do projeto do produto e do processo em toda a empresa" (FINGER, 1993 apud PRASAD, 1996)
Todas essas definições continuam válidas. No entanto, a definição de Engenharia Simultânea deve ser adequada à ênfase atual de se modelar os proceso de negócio das empresas.
Definição orientada a processos de negócio
Com base nos conceitos de modelagem de processos de negócio, pode-se definir Engenharia Simultânea como sendo a filosofia utilizada no processo de desenvolvimento (ou alteração) de novos produtos, visando:
  • aumento de qualidade do produto, com foco no cliente;
  • diminuição do ciclo de desenvolvimento e
  • diminuição de custos.
Esta filosofia toma como base a sinergia entre seus agentes, que devem trabalhar em equipes multifuncionais, formadas por pessoas de diversas área da empresa. Esta equipe deve crescer e diminuir ao longo de sua existência, mantendo sempre um mesmo núcleo de pessoas, que acompanham o desenvolvimento. Durante algumas atividades devem fazer parte desta equipe clientes e fornecedores, quando se trabalhar no conceito de cadeia de suprimentos, conforme a posição da empresa dentro desta cadeia. Todo o trabalho desta equipe deve ser suportado por recursos, métodos e técnicas integradas, tais como: QFD, FMEA,Taguchi, etc. Apesar da repetição, deve-se sempre enfatizar que o foco do trabalho deve estar concentrado nas necessidades do cliente. Apesar de longa, essa definição poderia ainda ser considerada incompleta, pois, por exemplo, não citou a melhoria contínua e outros conceitos, que a tornariam muito mais extensa. É importante ressaltar que todos os elementos da empresa envolvidos nessa definição de Engenharia Simultânea (atividades, informação, organização e recursos) devem ser considerados no modelo do processo de desenvolvimento de produtos. Um exemplo de processo que utiliza a filosofia de Engenharia Simultânea é modelo de referência de desenvolvimento de produtos da Fabrica Integrada Modelo (FIM).
Livros
CARTER, D. E.; BAKER, B. S. (1992). Concurrent engineering: the product development environment for the 1990s. Reading, Mass.: Addison-Wesley. ( Disponível na biblioteca da EP - USP ). PRASAD, B. (1996). Concurrent engineering fundamentals: integrated product and process development. v. 1. New Jersey, Prentice Hall. ( t: 321 ) PRASAD, B. (1997). Concurrent engineering fundamentals: integrated product development. v. 2 .New Jersey, Prentice Hall. ( t: 326 ) ( Disponível na EESC - USP ) SYAN, C. S.; MENON, U. (1994). Concurrent engineering: concepts, implementation and practice. London, Chapman & Hall. ( Disponível na biblioteca da EP - USP ).
Periódicos
Concurrent Engineering: Research and Applications http://www.techpub.com/tech/LibraryIndex_Periodicals.asp?qrystrID=201054 O Concurrent Engineering: Research and Applications é um dos principais periódicos sobre Engenharia Simultânea. Nesse site podem ser consultados os índices das edições mais recentes e encontradas informações sobre assinatura e compra de exemplares atrasados. Além disso são fornecidas instruções para o envio de artigos.
Teses
CHIUSOLI, R. F. (1996). Engenharia Simultânea: estudos de casos na indústria brasileira de autopeças. São Carlos. 147p. Dissertação (Mestrado) - Universidade Federal de São Carlos. MUNIZ JUNIOR, J. (1995). Utilizacao da engenharia simultanea no aprimoramento continuo e competitivo das organizacoes:estudo de caso do modelo usado no aviao emb 145 da embraer. São Paulo. 196p. Dissertação (Mestrado) - Escola Politécnica - Universidade de São Paulo. ( Disponível na biblioteca da EP - USP ).
Associações
Society of Concurrent Engineering http://www.soce.org/ Nesse site podem ser encontrados vários artigos, dados sobre eventos na área, grupos de discussão, entre outras informações sobre Engenharia Simultânea Concurrent Engineering World Wide Web Server http://cewww.eng.ornl.gov/ O Concurrent Engineering Center faz parte do Oak Ridge Centers for Manufacturing Technology criado pelo departamento americano de energia (U.S. Department of Energy) para aumentar a competitividade das empresas em vários setores. Nesse site podem ser encontradas informações sobre sistemas computacionais integrados que apoiam a Engenharia Simultânea.
Estratégia Competitiva http://www.portaldeconhecimentos.org.br/index.php/content/view/full9514
Introdução
Estratégia competitiva é o conjunto de planos, políticas, programas e ações desenvolvidos por uma empresa ou unidade de negócios para ampliar ou manter, de modo sustentável, suas vantagens competitivas frente aos concorrentes. Para Ohmae (1983), “... Sem competidores não haveria necessidade de estratégia, pois o único propósito do planejamento estratégico é tornar a empresa apta a ganhar, tão eficientemente quanto possível, uma vantagem sustentável sobre seus concorrentes. ...”. Para Porter (1985), “A estratégia competitiva visa estabelecer uma posição lucrativa e sustentável contra as forças que determinam a competição industrial.” (pág. 1) O nível de competitividade alcançado pela empresa ou unidade de negócios depende de fatores sistêmicos, estruturais ou empresariais, segundo Coutinho e Ferraz (1994), relacionados, respectivamente, às condições macroeconômicas, político-institucionais, regulatórias, infra-estruturais e sociais do país onde a empresa está instalada, às características do mercado, da concorrência e da configuração da indústria ou setor econômico em que a empresa atua e à capacidade gerencial e operacional da própria empresa. Cabe notar que, embora os dois primeiros conjuntos de fatores refiram-se a condicionantes externos à empresa, o posicionamento estratégico desta - e portanto suas decisões e ações - é que irá definir o impacto de tais oportunidades e ameaças do ambiente externo em seu desempenho. Segundo Montgomery e Porter (1998), o desafio enfrentado pela gerência consiste em escolher ou criar um contexto ambiental em que as competências e recursos da empresa possam produzir vantagens competitivas. Quanto aos fatores estruturais relacionados à competitividade das empresas, Porter (1985) indica que cinco forças determinam a dinâmica da competição em uma indústria: a entrada de novos concorrentes, a ameaça de substitutos, o poder de barganha dos clientes, o poder de barganha dos fornecedores e a rivalidade entre os concorrentes atuais. “A pressão coletiva destas cinco forças determina a habilidade das firmas em uma indústria de ganhar, em média, taxas de retorno sobre o investimento em excesso ao custo de capital. A pressão das cinco forças varia de indústria para indústria e pode se modificar quando a indústria evolui. ...” (pág. 4). As empresas em geral podem adotar três tipos de estratégia competitiva, segundo Porter (1980): estratégia de liderança em custos, estratégia de diferenciação e estratégia de foco. A primeira visa obter vantagens competitivas pela oferta de produtos e serviços (em geral padronizados) a custos mais baixos do que os concorrentes. A segunda busca alcançar vantagens pela introdução de um ou mais elementos de diferenciação nos produtos e serviços, que justifiquem preços mais elevados. E o terceiro tipo de estratégia objetiva obter vantagens competitivas ou pela oferta de produtos e serviços com menores custos, ou pela diferenciação dos mesmos, mas em um segmento de mercado mais localizado ou restrito.A estratégia competitiva de uma empresa será desdobrada em geral em estratégias funcionais como as estratégias de marketing, de produção, financeira e tecnológica, buscando-se compor um todo coeso e harmônico de planos e ações que propiciem a aquisição de vantagens competitivas pela melhoria dos processos de negócios ou de elementos na “cadeia de valor” (Porter, 1985) da empresa. A estratégia competitiva inclui os objetivos de mais longo prazo da empresa ou da unidade de negócios que serão repassados às estratégias funcionais. E, em geral, está baseada em competências acumuladas durante período de tempo relativamente longo. Por isso, a menos que grandes transformações ocorram no ambiente, alterações abruptas ou radicais na estratégia competitiva da empresa não devem ser esperadas. Assim, mesmo que não tenha sido formalizada ou divulgada, a parte mais visível da estratégia competitiva efetivamente implementada por uma empresa - refletida nos produtos e serviços que fornece - dificilmente não será identificável por profissionais que estudam o ramo de atividade em que esta se insere. A parte menos visível da estratégia, e talvez mais importante, diz respeito às competências que a empresa vai construindo e que fundamentarão vantagens competitivas no futuro. A estratégia competitiva adotada fica assim caracterizada pelo modo com que a empresa atende seus clientes. Como destaca Ohmae (1998), a estratégia será boa quando possibilitar entender melhor as necessidades dos clientes e criar valor para eles. Segundo Porter (1985), a vantagem competitiva advém do valor que a empresa cria para seus clientes em excesso ao custo que tem para criá-lo. O planejamento estratégico, ou a formulação da estratégia competitiva, é, portanto, essencial para a empresa, pois esta dificilmente poderá criar condições, simultaneamente, para responder a todas as demandas (necessidades), de todos os possíveis segmentos de mercado. Dificilmente, também, poderá instantaneamente mudar drasticamente as condições de atendimento ou “pular” de um segmento de mercado para outro. Assim, o planejamento estratégico propicia que a empresa identifique em que direção predominante pretende mover-se, orientando as competências (que vai acumulando e adquirindo) para as oportunidades que surgem no mercado de criar valor para seus clientes atuais e potenciais. A longo prazo, segundo Prahalad e Hamel (1998), a competitividade resulta da capacidade de formar competências que propiciam produtos e serviços que não podem ser antecipados.
Livros
ANSOFF, H. I. (1988). The new corporate strategy. Rev. Ed. of: Corpogate strategy.1965. New York: Wiley. ( Disponível na biblioteca da FEA ). COUTINHO, L. G.; FERRAZ, J. C. (1995). Estudo da competitividade da indústria brasileira. 3. ed. Campinas: Papirus. ( Disponível na biblioteca da EESC - USP ). FISHMANN, A. A.; ALMEIDA, M. I. R. (1995). Planejamento estratégico na prática. São Paulo: Atlas. (Disponível na biblioteca da ESALQ). MONTGOMERY, C. A.; PORTER, M. E. (1998). Estratégia: a busca da vantagem competitiva. Rio de Janeiro: Campus. ( Disponível na biblioteca da FFLCH ). OHMAE, K. (1983). The mind of strategist. Harmondsworth. Peguin Books. OHMAE, K. (1998). Voltando à estratégia. In: MONTGOMERY, C.A.; PORTER, M.E. Estratégia: a busca da vantagem competitiva. Rio de Janeiro, Campus. ( Disponível na biblioteca da FFLCH ). PORTER, M. E. (1998). Como as forças competitivas moldam a estratégia. In: MONTGOMERY, C. A. PORTER, M. E. Estratégia: a busca da vantagem competitiva. Rio de Janeiro: Campus. ( Disponível na biblioteca da FFLCH ). PORTER, M. E.; (1985). Competitive advantage. New York: Free Press. ( Disponível na biblioteca da FEA ). PORTER, M. E.; (1980). Competitive strategy. New York: The Free Press. ( Disponível na biblioteca da EESC - USP ). PRAHALAD, C. K.; HAMEL, G.; (1998). A competência essencial da corporação. In: MONTGOMERY, C. A. PORTER, M. E. Estratégia: a busca da vantagem competitiva. Rio de Janeiro: Campus. ( Disponível na biblioteca da FFLCH ). QUINN, J. B.; MINTZBERG, H.; JAMES, R. M.; (1988). The strategy process: concepts, contexts, and cases. Englewood Cliffs: Prentice-Hall. (Disponível na FEA - USP).
Estrutura e Identificação de Produtos http://www.portaldeconhecimentos.org.br/index.php/content/view/full9459
Conceitos Básicos
Fontes:AGERMAN, E.; LINDBERG, L. ;AMERICAN PRODUCTION AND INVENTORY CONTROL SOCIETY ;CLEMENT, J.; COLDRICK, A.; SARI, J. ;ELLIOT, P.M. ;MARÇOLA, J.A. ;RUSK, P.S. ;MATHER, H. F.(vide informações adicionais) As informações fundamentais dos produtos de uma empresa precisam estar representadas de forma completa e precisa para que as suas diversas atividades possam ser executadas (vendas, planejamento, produção, custeio, etc.).] Segundo CLEMENT et al. (1992), para que as informações fundamentais sejam sólidas, elas precisam:
  • representar os processos de manufatura;
  • representar os produtos vendidos e as estratégias e planos para a satisfação dos clientes;
  • ser entendida e satisfazer todos os usuários;
  • ser completa e precisa;
  • ser suportada por boas práticas de controle de alterações.
Diversos autores, tais como CLEMENT et al. (1992), AGERMAN & LINDBERG (1992) e RUSK (1990), identificam as informações fundamentais, as quais podem ser organizadas como:
  • número de identificação;
  • arquivo mestre de informações (descrição, número do desenho de engenharia, nível de revisão,status, custo, produto a que pertence, histórico das últimas alterações de engenharia, tamanho do lote, unidade de medida, comprado ou fabricado, quem planeja ou compra, etc.);
  • desenhos e especificações;
  • estrutura de produto;
  • relatórios de onde é usado;
  • plano de processo e o arquivo mestre de informações sobre os centros de trabalho;
  • outros documentos de suporte.
Dentre essas informações, a estrutura de produto (BOM - Bill of Material) e número de identificação são essenciais, pois são elementos que geram integração, uma vez que suas informações são compartilhadas por quase todos os departamentos da empresa. (MARÇOLA, 1995). Além disso, essas informações distinguem e/ou especificam produtos da empresa. Logo, a forma como são gerenciados, controlados e estruturados pode diretamente influenciar o sucesso da empresa (RUSK, 1990).
Referências
AGERMAN, E.; LINDBERG, L. (1992). The product structure: the backbone of CIM. In: CIRP, 1992. Anais. v.41, n.1-3, p.165-168. (t:832). AMERICAN PRODUCTION AND INVENTORY CONTROL SOCIETY. Dictionary. (1992). 7.ed. Falls Church, American Production and Inventory Control Society. CLEMENT, J.; COLDRICK, A.; SARI, J. (1992). Manufacturing Data Structures: building foundations for excellence with bills of material and process information. Oliver Wight, Atlanta. ELLIOT, P.M. (1985). Non-significant Part Numbering: the better choice for MRP. Production & Inventory Management, v.26, n.4, p.102-108. (t: 831). MARCOLA, J. A. (1995). Proposta e desenvolvimento de um sistema de gerenciamento da produção de sistemas dedicados. São Carlos. Dissertação (Mestrado) – Escola de Engenharia de São Carlos, Universidade de São Paulo. ( Dsponível na biblioteca da EESC - USP). RUSK, P. S. (1990). The role of bill of material in manufacturing systems. Engineering Cost and Production Economics, v.19, n.1, p.205-211, may. (t:830) MATHER, H. F. (1986). Design, bills of materials, and forecasting: the inseparable threesome. Production & Inventory Management, v.27, n.1, p.90-107. (t:829).
FMEA (Failure Mode and Effect Analysis) http://www.portaldeconhecimentos.org.br/index.php/content/view/full9428
Objetivos dessa página
  • Fornecer uma visão ampla e superficial do FMEA, possibilitando ao usuário ter noções de como, quando e porquê aplicar o método
  • Fornecer informações sobre as limitações do método e dicas para evitar erros na execução do mesmo
Definição
FMEA (failure mode and effect analysis) é uma ferramenta usada para aumentar a confiabilidade de um certo produto durante a fase de projeto ou processo. A ferramenta consiste basicamente em sistematizar um grupo de atividades para detectar possíveis falhas e avaliar os efeitos das mesmas para o projeto/processo. A partir dessas possíveis falhas, identificam-se ações a serem tomadas para eliminar ou reduzir a probabilidade de que as mesmas ocorram. Essas ações também podem objetivar aumentar a probabilidade de detecção dessas falhas, para que os produtos que apresentam inconformidades não cheguem ao cliente. Deste modo é obtida uma lista de possíveis falhas, organizada por ordem do risco que elas representam e com respectivas ações a serem tomadas para mitigá-las. Essa lista auxilia na escolha de projetos alternativos com alta confiabilidade durante as etapas iniciais da fase de projeto. Assim garante-se que todas as possíveis falhas de um projeto/processo sejam consideradas e suas probabilidades de ocorrência minimizadas (quando se fizer necessário).
Tipos de FMEA
Geralmente é aceito que existem quatro tipos de FMEAs. As etapas e a maneira de realização da análise são as mesmas, diferenciando-se principalmente quanto ao objetivo. Desta maneira, temos:
  • FMEA de design: São consideradas as falhas que poderão ocorrer com o produto dentro das especificações do projeto. O objetivo desta análise é evitar falhas no produto ou no processo decorrentes do projeto. É comumente denominada também de FMEA de projeto ou produto
  • FMEA de processos: São consideradas as falhas no planejamento e execução do processo, ou seja, o objetivo desta análise é evitar falhas do processo, tendo como base as não conformidades do produto com as especificações do projeto.
  • FMEA de sistemas: São considerados sistemas e subsistemas nas fases conceituais e de projeto. O objetivo desta análise é focalizar nos modos de falhas entre funções do sistema. São inclusas as interações entre sistemas e elementos dos sistemas.
  • FMEA de serviços: São analisados os serviços antes de eles atingirem o consumidor. É usado para identificar tarefas críticas ou significantes para auxiliar a elaboração de planos de controle. Ajudam a eliminar gargalos nos processos e tarefas.
Apesar de as etapas e a maneira de realização da análise serem as mesmas, existem pequenas variações entre cada tipo de análise. Um exemplo de diferença é a definiçã dos índices (serão descritos posteriormente) adotados na elaboração do FMEA. Portanto, neste trabalho serão focados dois tipos de FMEA por serem os mais utilizados e conhecidos: FMEA de design e FMEA de processos.
Mecanismos
Os mecanismos utilizados no FMEA são relativemente simples. O método consiste basicamente em identificar e dispor todos os modos de falha em potencial em uma tabela que facilitará a sua interpretação. Após os modos de falha estiverem sido dispostos na tabela, eles deverão ser analisados e classificados em relação à 3 aspectos: Severidade, detectabilidade e probabilidade. Pela multiplicação desses 3 índices, tem-se à disposição, os modos de falha ordenados de acordo com a sua importância. Desta maneira, obtêm-se uma tabela que auxilia na tomada de decisões de mudanças (relacionadas com o aumento de confiabilidade) no projeto . Posteriormente, serão apresentadas explicações mais detalhadas sobre o funcionamento e elaboração de um FMEA.
Quando se deve utilizar o FMEA
Inicialmente o FMEA foi desenvolvido para ser usado na fase de projetos para evitar, através de análise de falhas em potencial e propostas de ações de melhoria, que ocorram falhas nos projetos de produtos/processos. Porém ela pode ser usada ao longo do ciclo de vida do produto para detectar possí­veis falhas à medida que o sistema envelhece. É importante ressaltar que o FMEA deve ser constantemente revisado e atualizado. Durante a fase de projeto do produto, recomenda-se que se aplique ou atualize o FMEA durante os seguintes estágios:
  • Formulação do conceito
  • Projeto preliminar
  • Conclusão do projeto detalhado
  • Programas de melhoria do projeto
Possivelmente, nas fases iniciais de projeto, as informações sobre o produto estarão limitadas. Ainda assim, é possível desenvolver o FMEA respondendo a perguntas básicas como por exemplo:
  • Como cada parte do produto poderia falhar?
  • Quais mecanismos poderiam produzir estes modos de falha?
  • Quais seriam os efeitos se essas falhas ocorressem?
  • Essas falhas poderiam acarretar em algum perigo?
  • Como essa falha é detectada?
  • O que será planejado durante a fase de projeto para compensar a falha?
O FMEA também é utilizado em produtos que já estão em operação. Neste caso busca-se achar a causa raiz das falhas do sistema para propor soluções de melhoria. Assim, diferentemente do FMEA realizado na fase de projetos, não é necessário prever possíveis falhas, pois neste caso trabalha-se com falhas que já estão ocorrendo no sistema.
Benefícios e informações geradas pelo FMEA
O FMEA traz à empresa um melhor conhecimento dos problemas nos produtos/processos. O método gera uma forma sistemática de se hierarquizar informações sobre as falhas dos produtos/processos, estabelecendo-se, portanto, um sistema de prioridades de melhorias, investimento, desenvolvimento, análises teste e validação. A aplicação da ferramenta gera arquivos que servem como uma referência para o futuro ao nível das evoluções possíveis, da documentação de erros do passado, do desenvolvimento de técnicas avançadas de projeto e do incentivo para a necessidade constante de desenvolvimento. Desta maneira são geradas ações de melhoria no projeto do produto/processo, que devem ser devidamente monitoradas (melhoria contínua). Devido a essa documentação de riscos e prevenção de ocorrência de falhas, o tempo e o custo de desenvolvimento diminuem. Ao mesmo tempo a confiabilidade, qualidade e segurança do produto/processo aumentam. Esse método ajuda a empresa a manter sempre o foco no cliente, garantindo sua satisfação e segurança. Assim, facilita a empresa a identificar características críticas para a qualidade. A análise do FMEA pode ser um ponto inicial para vários outros tipos de análise, por exemplo:
  • Análise de sistema de segurança
  • Análise de planejamento de manutenção
  • Planejamento da produção
  • Análise de nível de reparos
  • Planejamento de testes
  • Análise de apoio à logística
Pode-se observar então, que o FMEA pode ser um método iterativo, pois à medida que são feitas análises adicionais, novas informações, que podem aumentar a precisão do método, surgem. Há também o benefício de incorporar dentro da organização a atitude de prevenção de falhas, a atitude de cooperação e trabalho em equipe. Este último é importante para, entre outros aspectos, capturar o conhecimento coletivo de um time.
Limitações e abusos do FMEA
O FMEA é uma ferramenta extremamente eficiente se aplicada de maneira correta. Porém observa-se na prática muitos FMEAs que não apresentam resultados satisfatórios devido a extrapolação de seus limites pelos projetistas. A eficácia da ferramenta está muito ligada a perícia do projetista, devido ao fato de que os modos de falha precisam ser previstos por ele. Algumas limitações do FMEA estão listadas abaixo:
  • O FMEA não pode ser feito até que o projeto tenha progredido a um certo ponto em que os elementos do sistema tenham sido selecionados até o nível que a análise deseja explorar
  • Se o FMEA for executado muito tarde, ele pode não impactar o projeto de modo eficaz e pode não garantir a confiabilidade do dispositivo
  • Freqüentemente erros humanos e ambientes hostis são negligenciados
  • Os efeitos combinados de falhas coexistentes não são considerados
  • Se o sistema for muito complexo e a análise se estender até o nível de subsistema (ou mais detalhado), o processo pode ser extremamente tedioso e consumir muito tempo
  • Probabilidades de falhas podem ser difíceis de se obter. Obter, aplicar e interpretar esses dados a sistemas únicos, introduz incertezas que são difíceis de se avaliar. Além disso, a maioria dos sistemas se degradam ao decorrer do tempo, portanto possuem status múltiplos.
  • FMEA não analisa perigos ou problemas quando o sistema está operando devidamente
  • É causado um impacto inicial no cronograma do produto e de manufatura
  • Há uma necessidade de se compor um time com uma característica interdisciplinar elevada e posteriormente treiná-los devidamente, gerando custos.
Deve-se tomar muito cuidado também para não se negligenciar alguns itens importantes, como por exemplo:
  • utilitários com Ex.: eletricidade, ar comprimido, água de arrefecimento, óleo lubrificante pressurizado, vapor, etc...
  • Atividades humanas de suporte - Ex.: processo de controle...
  • elementos de interface
Para não tornar o FMEA extremamente tedioso, deve-se ignorar alguns itens que não auxiliam a análise de falhas, como por exemplo:
  • elementos passivos em ambientes não hostis com Ex.: fios elétricos
Como fazer um FMEA
Nesta seção será descrito como fazer um FMEA passo a passo. Serão apresentadas, primeiramente, as informações necessárias para se iniciar a elaboração do FMEA. Posteriormente, será comentada cada coluna da tabela com dicas para a sua elaboração e exemplos.
Informações necessárias
As unidades de análise do FMEA são os sistemas, subsistemas e componentes, assim divididas a fim de sistematizar todo o projeto. Deve-se definir bem a abrangência dessas unidades, não somente ao nível de discretização das funções e desempenhos individuais, mas também no nível de interações entre todas elas. Isso se faz necessário porque alterações em um subsistema podem vir a causar alterações no funcionamento de outro subsistema. O fato de dois subsistemas não estarem contacto direto não significa que não possa haver interação entre eles. Primeiramente deve-se definir o sistema a ser analisado e obter os desenhos, minutas, descrições, diagramas e listas de componentes. Defina bem o que está sendo analisado (uma área, atividade, equipamento...). Depois defina se deve-se analisar o sistema inteiro ou partes dele, e quais são os alvos a serem considerados (pessoal, produto, etc..). Faça um WBS (Work Breakdown Structure ) até elementos convenientes e lógicos. Neste caso pode-se fazer tanto um WBS funcional (de acordo com as funções dos elementos do sistema) ou um de arquitetura. Pode-se considerar também a possibilidade de se fazer ambos. Somente então deve realizar a análise dos elementos (FMEA). Na seção "material para download" está disponível um modelo de Tabela de FMEA para design.
Geral
  • Anexar na tabela todas as hipóteses feitas durante a execução do FMEA e também a definição de notas usadas.
  • Incluir no cabeçalho da tabela a data de revisão do documento
  • Todos os membros do time devem ser listados no cabeçalho da tabela
  • Incluir nome e número do produto (parte do produto) para fácil identificação do mesmo posteriormente
Função
  • Cada função deve ter uma medida associada
  • Cada função deve ser escrita em um contexto de verbo-substantivo
    • Exemplo:
      • O sistema ABC deve desembaçar vidros e aquecer ou esfriar a cabine até 20°C em todas as condições de operação (de -20°C à 50°C)
      • No tempo de 3 a 5 minutos
Modo de falha em potencial
  • Cada função deve ser escrita em um contexto de verbo-substantivo
  • Cada função deve ser escrita como uma antifunção
    • Existem 5 tipos de modo de falhas:
      • Falha completa
      • Falha parcial
      • Falha intermitente
      • Falha devido ao excesso da função
      • Função indesejada
      • Exemplo:
        • O sistema ABC não aquece o veículo nem desembaça o vidro
        • O sistema ABC leva mais que 5 minutos para aquecer a cabine
        • O sistema ABC não aquece o a cabine até 20°C em temperaturas abaixo de 0°C
        • O sistema ABC esfria a cabine para a temperatura de 10°C
        • O sistema ABC liga o desembaçador traseiro
Efeitos potenciais de falha
  • Os efeitos devem ser descritos do modo em que os clientes iriam descrevê-los
  • Efeitos devem incluir: segurança/ corpo regulador; cliente final; clientes internos - manufatura, montagem e serviços
    • Exemplo:
      • Não é possível ver além da janela da frente
      • O ar condicionado deixa a cabine muito fria
      • Não esquenta o suficiente
      • Leva muito tempo para aquecer
Severidade
  • Os índices de severidade devem corresponder, de preferência, aos índices pré-definidos na tabela 2
  • Caso opte-se por usar um critério interno para os índices de severidade, deve-se anexar ao FMEA uma referencia para as tabelas com os índices e explicações de como ela deve ser utilizada.
    • Exemplo:
      • Não é possível ver além da janela da frente com severidade 9
      • O ar condicionado deixa a cabine muito fria com severidade 5
      • Não esquenta o suficiente com severidade 5
      • Leva muito tempo para aquecer com severidade 4
Causas potenciais/mecanismos de falha
  • As falhas devem limitar-se aos interesses do projeto
  • A análise deve manter-se dentro do escopo definido (sistema que está sendo analisado e interface com outros sistemas)
  • Causas em nível de análise de componentes devem ser identificadas como características do sistema (características que podem ser controladas no processo)
  • Geralmente há mais de uma causa de falha para cada modo de falha
  • As causas devem ser identificadas para um modo de falha, e não para um efeito individual
    • Exemplo:
      • Posicionamento incorreto das saídas de ar do desembaçador
      • Caminho incorreto percorrido pelas mangueiras das saídas de ar (provavelmente muito próximas à s fontes de calor)
      • Capacidade inadequada de resfriamento para a aplicação em questão
Ocorrência
  • Os índices de ocorrência devem corresponder, de preferência, aos índices pré-definidos na tabela XXX
  • Caso opte-se por usar um critério interno para os índices de ocorrência, deve-se anexar ao FMEA uma referencia para as tabelas com os índices e explicações de como ela deve ser utilizada.
  • Os índices de ocorrência para o FMEA de projeto são baseados na probabilidade que uma causa pode ocorrer, de acordo com falhas passadas, performances de sistemas similares em aplicações similares.
  • Valores 1 de ocorrência devem ter dados que providenciam uma justificativa para tal valor. Esses dados, ou as fontes desses dados, devem ser incluídos na coluna de ações recomendadas.
    • Exemplo:
      • Posicionamento incorreto das saídas de ar do desembaçador com ocorrência 3
      • Caminho incorreto percorrido pelas mangueiras das saídas de ar (provavelmente muito próximas à s fontes de calor) com ocorrência 6
      • Capacidade inadequada de resfriamento para a aplicação em questão com ocorrência 2
Classe
  • A classificação é usada para definir características potencialmente críticas ou significantes
  • Características críticas (sugere-se que se utilize para severidades 9 ou 10 com ocorrência igual ou maior que 2) devem possuir uma ação recomendada associada
  • Características significantes (sugere-se que se utilize para severidades entre 8 a 4 com ocorrência igual ou maior que 4) devem possuir uma ação recomendada associada
  • Deve-se ter um critério bem definido para cada caso de aplicação caso opte-se por não usar a classificação sugerida
    • Exemplo:
      • Não é possível ver além da janela da frente com severidade 9 - Posicionamento incorreto das saídas de ar do desembaçador com ocorrência 3 - crítica
Controle atual de projeto
  • Controles preventivos são aqueles que ajudam a reduzir a probabilidade que um modo de falha ou causa de falha possa ocorrer com afetam o índice da ocorrência
  • Controles de detecção são aqueles que identificam problemas na fabricação dos produto com índice de detecção associado
  • Se os controles preventivos e de detecção não forem listados em colunas separadas, eles devem incluir uma identificação do tipo de controle (P ou D)
  • Exemplo:
    • Especificações de engenharia (P) com controle preventivo
    • Dados de projetos antigos (P) com controle preventivo
    • Teste funcional com controle de detecção
    • Durabilidade geral de um produto (D) com controle de detecção
Detecção
  • Os índices de detecção devem corresponder, de preferência, aos índices pré-definidos na tabela XXX
  • Caso opte-se por usar um critério interno para os índices de detecção, deve-se anexar ao FMEA uma referencia para as tabelas com os índices e explicações de como ela deve ser utilizada.
  • Detecção é o valor associado a cada tipo de controle de detecção
  • Valores de detecção igual a 1 devem eliminar o potencial para falha devido a deficiência de projeto
    • Exemplo:
      • Especificações de engenharia (P) com sem valor de detecção
      • Dados de projetos antigos (P) com sem valor de detecção
      • Teste funcional com detecção 3
      • Durabilidade geral de um produto (D) com detecção 5
RPN (número de prioridade de risco - risk priority number)
  • RPN é uma multiplicação dos índices de severidade, ocorrência e detecção.
  • É usado o índice mais baixo de detecção parar calcular o RPN
  • Não deve-se usar um limite de RPN como principal elemento para a definir ações recomendadas
    • Exemplo:
      • Não é possível ver além da janela da frente com severidade 9 - Posicionamento incorreto das saídas de ar do desembaçador com ocorrência 3 com teste funcional com detecção 3 com RPN 81
Ações recomendadas
  • Todas características críticas ou significantes devem ter ações recomendadas associadas a elas
  • As ações recomendadas devem focar no projeto e devem ser dirigidas no sentido de mitigar a causa da falha ou eliminar o modo de falha
  • Caso as ações recomendadas não consigam mitigar ou eliminar o potencial para falhas no projeto, as ações recomendadas devem forçar as características a sofrerem uma mitigação de processo o quanto antes em um FMEA de processo.
Responsáveis e data alvo de finalização
  • Deve haver uma pessoa designada para assumir a responsabilidade pelo cumprimento de cada ação recomendada
  • Deve-se colocar um nome e não um título para assumir a responsabilidade por cada ação.
  • Deve-se lembrar que somente pessoas listadas como membro do time podem ser listadas pela responsabilidade de uma ação
  • Deve haver uma data alvo de cumprimento da ação para cada ação recomendada
Resultado das ações
  • O campo ação tomada deve detalhar quais ações ocorreram e quais os resultados de cada ação tomada
  • As ações devem ser completadas até a data alvo de finalização da ação
  • Ao menos que o modo de falha tenha sido eliminado, a severidade não deve mudar.
  • O índice de ocorrência pode ou não diminuir baseado nos resultados das ações
  • O índice de detecção pode ou não diminuir baseado nos resultados das ações
  • Caso os índices de severidade, ocorrência ou detecção não tenham melhorado, devem ser definidas novas ações recomendadas.
FTA - Faut Tree Analysis http://www.portaldeconhecimentos.org.br/index.php/content/view/full9462
Introdução
A crescente necessidade de melhorar a qualidade de produtos e a satisfação dos clientes tem popularizado vários métodos e técnicas que visam melhorar a confiabilidade de produtos e processos, ou seja, aumentar a probabilidade de um item desempenhar sua função sem falhas. Dentre estas técnicas, destaca-se o FMEA (Failure Modes and Effects Analysis), que atualmente é amplamente utilizado nas indústrias de manufatura, em grande parte devido à exigências de normas de qualidade tais como a ISO 9000 e a QS 9000. Outra destas técnicas é a análise da árvore de falhas (Fault Tree Analysis – FTA), que visa melhorar a confiabilidade de produtos e processos através da análise sistemática de possíveis falhas e suas conseqüências, orientando na adoção de medidas corretivas ou preventivas.
A Construção do Diagrama
O diagrama da árvore de falhas mostra o relacionamento hierárquico entre os modos de falhas identificados no FMEA. O processo de construção da árvore tem início com a percepção ou previsão de uma falha, que a seguir é decomposto e detalhado até eventos mais simples. Dessa forma, a análise da árvore de falhas é uma técnica top-down, pois parte de eventos gerais que são desdobrados em eventos mais específicos. Abaixo é mostrado um exemplo de um diagrama FTA aplicado à uma falha em um motor de elétrico. O evento inicial, que pode ser uma falha observada ou prevista, é chamado de evento de topo, e está indicado pela seta azul. A partir desse evento são detalhadas outras falhas até chegar em eventos básicos que constituem o limite de resolução do diagrama. As falhas mostradas em amarelo compõem o limite de resolução deste diagrama. É possível adicionar ao diagrama elementos lógicos, tais como ‘e’ e ‘ou’, para melhor caracterizar os relacionamentos entre as falhas. Dessa forma é possível utilizar o diagrama para estimar a probabilidade de um falha acontecer a partir de eventos mais específicos. O exemplo abaixo mostra uma árvore aplicada ao problema de superaquecimento em um motor elétrico utilizando elementos lógicos.
Comparação entre FTA e FMEA
Apesar da semelhança entre as duas técnicas, no que se refere a finalidade, existem várias diferenças entre elas quanto a aplicação e ao procedimento de análise. A tabela abaixo compara as duas técnicas apresentando suas principais diferenças.
FTA FMEA
Objetivo Identificação das causas primárias das falhas Identificação das falhas críticas em cada componente, suas causas e conseqüências
Elaboração de uma relação lógica entre falhas primárias e falha final do produto Hierarquizar as falhas
Procedimento Identificação da falha que é detectada pelo usuário do produto Análise dos falhas em potencial de todos os elementos do sistema, e previsão das conseqüências
Relacionar essa falha com falhas intermediárias e eventos mais básicos por meio de símbolos lógicos Relação de ações corretivas (ou preventivas) a serem tomadas
Aplicação Melhor método para análise individual de uma falha específica Pode ser utilizado na análise de falhas simultâneas ou correlacionadas
O enfoque é dado à falha final do sistema Todos os componentes do sistema são passíveis de análise
Livros
Informações Adicionais - última verificação 11/11/1999 (voltar para início da página) Clausing, Don. (1994) Total Quality Development: a step-by-step guide to world-class concurrent engineering. Helman H., Andery, P. R. P.. Análise de Falhas (Aplicação dos métodos de FMEA – FTA) Juran J. M., Gryna F. M. Controle da Qualidade: Handbook. Volume III, Makron Books. Pugh, Stuart., Total Design: integrated methods for product engineering. Addison Wesley
Sites Relacionados
Bass Associates Inc. Consulting Engineers. http://www.bassengineering.com/
Gerenciamento de Projetos http://www.portaldeconhecimentos.org.br/index.php/content/view/full9944
Introdução
O mundo corrente apresenta elevado grau de competição, de mudanças, de adaptações constantes. Dentro deste contexto, os projetos vêm assumindo um papel relevante dentro das organizações. A administração participativa faz com que os projetos devam ser executados por equipes integradas, para que todas as tarefas sejam executadas com eficácia e eficiência. Para atender a estes requisitos e obter sucesso, as empresas vêm adotando a prática do Gerenciamento de Projetos.
Definições
Projeto é entendido como um conjunto de ações, executadas de forma coordenada por uma organização transitória, ao qual são alocados os insumos necessários para, em um dado prazo, atingir um objetivo .Sendo este objetivo geralmente especificado em termos de custos, tempo e desempenho. Um projeto é único, tem objetivos definidos e mensuráveis e tem um ciclo de vida. O Gerenciamento de Projetos (GP) oferece uma visão integrada de todos os fatores envolvidos em um projeto para que sejam atingidos os objetivos assumidos. Tem um enfoque humanístico e participativo, orientado para a obtenção de resultados, com a premissa de que os resultados são atingidos por meio do trabalho de pessoas. O GP compreende a concepção de metas e objetivos do projeto, a elaboração de um plano, a execução do plano e a revisão e controle do projeto. Por fim, o GP oferece uma grande variedade de princípios, procedimentos, habilidades, ferramentas e técnicas que são necessários para que possam atingir os objetivos previamente planejados.
Ciclo de Vida do Projeto
Para que se tenha um melhor controle do projeto e se crie interdependência entre as atividades, dividem-se os projetos em algumas fases, constituindo o chamado ciclo de vida do projeto. O ciclo de vida do projeto define quais técnicas de trabalho serão utilizadas em cada fase e quais pessoas estarão envolvidas em cada fase. Cada fase do projeto é caracterizada por um completar um ou mais “marcos”. Os marcos são resultados de trabalhos que podem ser verificados e medidos, por exemplo, um estudo de viabilidade ou a elaboração de um protótipo. A conclusão de uma fase do projeto é caracterizada pela revisão dos trabalhos e dos padrões de desempenhos, para determinar se o projeto terá continuidade e detectar e corrigir os desvios. Existem diferentes versões para o ciclo, desde que as que contêm poucas fases até aqueles que contém mais de uma dezena, dependendo do que se considera como uma fase distinta ou um componente delas. Além disso, depende do tipo de projeto e da complexidade envolvida, o que gera a necessidade de um detalhamento minucioso das fases do projeto.
Processos de um Projeto
Os processos de gerenciamento de projetos descrevem e organizam o trabalho do projeto. Eles são aplicáveis à maioria dos projetos durante todas as suas fases.Os processos podem ser divididos em:
  • i. Processo inicial, é o início do projeto ou de uma fase.
  • ii. Processo de planejamento, onde se planeja organiza o trabalho para cumprir as necessidades do projeto ou da fase.
  • iii. Processo de execução, onde os trabalhos são executados.
  • iv. Processo de controle, que tem por objetivo ajustar o realizado, durante a execução, com o planejado.
  • v. Processo de encerramento, onde o projeto ou fase é aprovado formalmente, e então encerram-se as atividades, realocando-se os recursos.
Áreas de conhecimento de GP
Segundo o PMBOK (Project Management Body of Knowledge), o GP pode ser classificado em 9 áreas de conhecimento:
  • i. Gestão de integração. Esta área inclui os processos necessários para assegurar que os elementos de projeto estão coordenados apropriadamente.
  • ii. Gestão do escopo. Inclui todos os processos necessários para garantir que o projeto contém todo o trabalho necessário, e somente o trabalho necessário, para completar o projeto com sucesso.
  • iii. Gestão de prazos. São os processos necessários para assegurar a conclusão dos trabalhos no prazo planejado.
  • iv. Gestão de custo. Inclui os processos necessários para assegurar que o projeto será completado com as metas de custo e orçamento planejados.
  • v. Gestão da qualidade. Contém os processos necessários para assegurar satisfazer as necessidades empreendidas no projeto.
  • vi. Gestão de recursos humanos. Consiste em otimizar a utilização dos recursos humanos envolvidos no projeto.
  • vii. Gestão de documentação técnica. Contém os processos necessários para assegurar a geração, coleta, disseminação, armazenamento e disponibilização das informações no prazo certo e com acuracidade.
  • viii. Gestão de riscos. Inclui os processos para identificar, analisar e responder pelo risco do projeto.
  • ix. Gestão de aquisições. Inclui os processos para aquisição de recursos e serviços de terceiros.
Gerenciamento de Projetos em Desenvolvimento de Produtos
O processo de desenvolvimento de produto compreende várias fases e suas atividades e utiliza diversos recursos, sendo realizado por uma organização específica (muitas vezes também transitória). Conforme o autor e o tipo de empresa/produto essas fases e atividades correspondentes recebem diversas denominações diferentes (conceituação, projeto, detalhamento, processo, homologação, por exemplo). Assim, o processo de desenvolvimento de produtos pode ser encarado como um projeto amplo e complexo, sendo portantanto factível de ser gerenciado.O gerenciamento de projetos é uma ferramenta para atingir rapidez, eficiência e baixos custos em desenvolvimento de produto. Neste processo, o GP deve conciliar e otimizar a utilização dos recursos (tempo, custo, pessoas, equipamentos etc), coordenando e integrando todas as atividades, recursos e pessoas pertinentes a um projeto, para que sejam atingidos os seus objetivos. Alguns aspectos devem ser observados, como a integração entre o gerente e sua equipe, a delegação de autoridade no projeto, a incorporação de fornecedores, clientes e contratados em uma única equipe etc assim como a qualidade, o controle, a documentação e os riscos. Todo o projeto deve ser estudado, organizado e executado com a total visão do ciclo de vida do projeto e também do produto, visando a manutenção e serviços associados. Consultar também modelos de referência de desenvolvimento de produtos e conceitos de engenharia simultânea.
Ferramentas Específicas utilizadas em GP
WBS. Working Breakdown Structure é uma forma de apresentação do projeto que o explicita em suas partes físicas, em softwares, serviços e outros tipos de trabalho, a qual organiza, define e graficamente mostra tanto o produto a ser feito como o trabalho a ser realizado para obtê-lo. Pode ser considerado como a espinha dorsal de todo o projeto. A WBS consiste em uma criteriosa decomposição tanto do produto como dos processos para obtê-lo, bem como das tarefas administrativas e/ou gerenciais necessárias. Ele pode ser representada como uma árvore, em forma de um organograma, ou como uma relação ou tabela. Redes de Precedência. Uma vez definidas as atividades do projeto e suas respectivas durações deve-se empreender a montagem destas atividades em um sequência temporal, de maneira racional, exequível e eficiente, de forma a dispô-las na melhor ordem para o projeto. Esta montagem deve obedecer à restrições de precedência, conflito de recursos, fluxos de recursos e janelas de oportunidades. Existem diversas técnicas para elaboração destas redes como PERT, P-PERT, PERT-Custo, GERT, CPM, PDM e Corrente Crítica. C/SCSC. Cost / Schedule Control Systems Criteria é uma metodologia que exerce o controle integrado de custos, prazos e do trabalho efetivamente realizado no decorrer de um projeto. Caracteriza-se por prover os gerentes com dados precisos para monitorar seus projetos e por prover uma adequada base de dados que indicam o progresso do trabalho; por relacionar custos, prazos e trabalho técnico; por permitir levantar tendências de evolução de custos e prazos. São analisadas em uma mesma base (custos) a variação de prazos e de custos para que se possa determinar as causas das variações e corrigi-las e também para obter estimativas precisas sobre o resultado final do projeto. Corrente Crítica. Corrente Crítica é uma nova abordagem para gerenciamento de projetos, voltado para a administração de prazos e atividades, baseado na teoria das restrições (TOC). Atua na quebra dos paradigmas de que todo projeto atrasa e estoura no orçamento. Oferece novas métodos de estimativas de tempo, de enfoque de tarefas, de monitoração do projeto, de viabilidade econômica e de formação da rede de precedência. A rede de precedência é formada obecendo às restrições de tempo e recursos, sendo a corrente crítica a seqüência na qual não pode ocorrer nenhum atraso em nenhuma atividade, devendo ser priorizada na administração de tarefas. Para evitar os atrasos, esta seqüência é protegida por reservas chamadas "pulmões", tanto de recursos como de tempo. O projeto é protegido por um "pulmão de projeto". Para diversos projetos que utilizam o mesmo recurso, este é considerado como a primeira restrição, sendo protegido também pelo "pulmão de gargalo". Esta metodologia vem revolucionando o GP, atingindo como resultado final redução do tempo de desenvolvimento em de 20 a 50 %, além de manter o escopo e orçamento planejados.
Livros
DUNCAN, W. R.; & PMI STANDARDS COMMITTEE. (1996). Project management body of knowledge. Pennsylvania: Project Management Institute Publications. GOLDRATT, A. Y. (1997). Corrente crítica. Trad. Thomas Corbett Neto. São Paulo: Nobel. ( Disponível na biblioteca da EESC -USP) MEREDITH, J. R.; MANTEL JR, S. J. (1995). Project management: a managerial approach. New York: Wiley. 3ª edição. ( Disponível na biblioteca da FEA - USP) NICHOLAS, J. M. (1990). Managing business & engineering project: concepts & implementation. Englewood Cliffs, NJ: Prentice Hall. (Disponível na FEA - USP) VALERIANO , D. L. (1998). Gerência em projetos: pesquisa, desenvolvimento e engenharia. São Paulo: Makron Books. ( t: 786 ). ( Disponível na EESC - USP )
Associações
Project Management Institute (PMI). http://www.pmi.org Este site contém informações sobre o PMI, assim como informações sobre seminários, compra de livros, grupos de discussão, empregos e links. O PMI trata de GP de maneira integrada, aplicada em todas as áreas de atuação e conhecimento. PMI Minas Gerais - Brasil http://www.pmimg.org.br PMI São Paulo - Brasil http://www.fea.usp.br/Programas/pmi-sp/index.htm
Sites Relacionados
The Project Management Forum http://www.pmforum.org/warindex.htm O PM Forum é um site voltado ao GP integrado, contendo artigos,estudos de caso, lista de periódicos, corpo de conhecimento (Body of Knowledge) e links para associações profissionais. NASA Polity Directive http://nodis.hq.nasa.gov/Library/Directives/NASA-WIDE/Policies/Program_Formulation/N_PD_7120_4A.html http://nodis.hq.nasa.gov/Library/Directives/NASA-WIDE/Procedures/Program_Formulation/N_PG_7120_5A.html O primeiro site contém as diretrizes da NASA para GP e o segundo é um guia que rege as normas de procedimento e acão em GP, para os projetos da agência. Department of Defense Handbook - Working Breakdown Structure http://www.acq.osd.mil/pm/newpolicy/wbs/mil_hdbk_881/mil_hdbk_881.htm Este site contém o manual de WBS do Departamento de Defesa dos EUA. São dadas explicações conceituais e de desenvolvimento de uma WBS, baseado na norma MIL-HDBK-881. Configuration Management Yellow Pages http://www.cs.colorado.edu/users/andre/configuration_management.html Esta página mantém atualizada uma lista de sites sobre o Gestão de Configuração, relacionando artigos, trabalhos, empregos, conferências e softwares.
Gestão de Portfolio de Projetos http://www.portaldeconhecimentos.org.br/index.php/content/view/full9466
Visão Geral
A gestão de portfólio é um tema que tem crescido bastante nos últimos anos. Esse crescimento pode ser relacionado com vários fatores. Dentre eles estão a busca pelos melhores projetos tanto em termos financeiros quanto estratégicos, e a necessidade de se alcançar os melhores resultados com o mínimo de recursos. A gestão de portfólio é um tema tratado tanto pela gestão de projetos quanto pela gestão de desenvolvimento de produtos. Existem grandes semelhanças entre o foco dados pelas duas áreas, uma vez que o desenvolvimento de produtos é normalmente gerenciamento por projetos. No entanto a gestão de portfólio pela abordagem da gestão de projetos pode ser considerada um pouco mais ampla, pois considera o gerenciamento de todos os tipos de projetos desenvolvidos dentro de uma empresa. Diferentemente da gestão de portfólio no processo de desenvolvimento de produtos que busca tratar apenas dos projetos dos produtos. A gestão de portfólio de projetos de produtos consiste em um processo de decisão realizado no inicio do processo de desenvolvimento de produtos onde é selecionado o conjunto de projetos de produtos que melhor atende aos requisitos e necessidades definidos pela empresa. Esses são os projetos que serão desenvolvidos e produzirão os produtos comercializados futuramente pela empresa. O processo de gestão de portfólio não possui um modelo padrão, pois cada empresa possui características que o tornam particular em cada uma. No entanto os objetivos que o processo deve atingir a fim de alcançar resultados satisfatórios podem ser resumidos em 4: alinhar o portfólio com a estratégia da empresa, maximizar o valor do portfólio, balancear o portfólio e alocação dos recursos disponíveis. A gestão de portfólio usa de vários métodos para alcançar os seus objetivos. Dentre eles estão métodos de avaliação financeira de projetos, gráficos de bolhas, modelos de notas, avaliação de recursos, etc. Um fato notado pelos estudiosos da área é que cada método é mais apropriado para um determinado objetivo. Assim dependendo das necessidades da empresa um método pode se tornar mais atrativo do que outro. Um dos autores mais conhecido sobre gestão de portfólio em desenvolvimento de produtos é Robert G. Cooper. Ele possui uma extensa literatura publicada no tema. Outros autores provenientes da gestão de projetos com boas publicações no assunto são Harvey A. Levine, James S. Pennypacker e Lowell D. Dye.
Ferramentas utilizadas na gestão de portfólio
Valor Comercial Esperado (VCE)
Este método busca maximizar o valor do portfólio considerando restrições financeiras, e introduz a noção de riscos e probabilidades. Ele determina o valor comercial de cada projeto para a empresa. O cálculo do VCE é baseado em uma árvore de decisão que aborda o valor presente líquido do projeto, as probalidades de sucesso técnico e comercial, e também os custos de comercialização e desenvolvimento. Figura 2 - Cálculo do VCE
Modelos de Notas
O modelo de notas pontua os projetos em utilizando critérios pré-definidos. Alguns dos critérios tipicamente usados são: • Alinhamento com a estratégia. • Vantagem associada ao produto • Demanda de mercado • Capacidade de fornecer competências essenciais • Facilidade técnica • Retorno x risco A pontuação de cada projeto serve como base para a classificação. Nota-se que os critérios podem ser ponderados, permitindo um direcionamento dos projetos para um fator de maior interesse.
Livros
Cooper, R. G.; Edgett, S. J. & Kleinschmidt, E. J. (1998), Portfolio management for new products, Perseus Books. Levine, H. A. (2005), Project portfolio management, Jossey-Bass. Maizlish, B. & Handler, R. (2005), IT portfolio management:, John Wiley & Sons. Martino, J. P. (1995), R&D project selection, John Wiley & Sons.
Sites:
  • Product Development Institute
Integração de Empresas /CIM http://www.portaldeconhecimentos.org.br/index.php/content/view/full9950
Nova leitura da sigla CIM
Desde os primórdios da utilização da sigla CIM, a ênfase estava na letra "C" de Computador, ou de uma forma mais ampla, Tecnologia de Informação.Considerava-se CIM como sendo "a utilização do processamento de dados eletrônicos e o fluxo de informações auxiliado por computador em todos os setores da empresa". Nesse período surgiu uma grande quantidade de propostas de modelos CIM, arquiteturas CIM, soluções CIM, etc.. A ênfase agora mudou e a letra hoje então mais importante da sigla CIM é o "I" de Integração, que representa os processo de negócios nas suas diversas visões (estratégias, atividades, informação, recursos e organização) dentro de uma visão holística do negócio (vide figura). O "C", ou seja a Tecnologia de Informação, é o recurso potencializador da integração, quando pensarmos nos sistemas de gestão integradas (ERP). A Tecnologia de Informação tem o potencial de facilitar a integração da organização e de suas pessoas também com o uso de tecnologias como workgroup computing, que envolve workflow, agenda eletrônica em grupo, correio eletrônico e até sistemas PDM. Nesses casos outros fatores, tais como cultura organizacional e capacidade de aprendizado da organização são importantes e muitas vezes inviabilizam o sucesso da aplicação dessas tecnologias . Não se deve esquecer que o domínio do negócio, ou melhor da manufatura de uma forma abrangente (letra "M") continua a ser essencial. De nada adiantaria a melhor estratégia, a melhor organização, os melhores recursos, se não existir um domínio amplo do negócio, desde o desenvolvimento de seus produtos, até a sua comercialização e produção. A Integração parte de uma visão holística da empresa, onde todas as visões fazem parte de um todo unificado. O que sustenta esta visão holística é a compreensão da empresa através de seus processos de negócio (business processes).Logicamente não se pretende aqui diminuir a importância da Tecnologia de Informação na Integração da Manufatura. Graças aos avanços atuais e disponibilidade de equipamentos e sistemas flexíveis e de fácil interconexão é que se pode tratar da Integração como um todo. O potencial da tecnologia é que permitiu que se pensasse em organizações modernas e até virtuais. Existem alguns caminhos a serem ainda desbravados, principalmente na área de normalização, para que um usuário possa integrar sistemas de diversos fornecedores.
Definição de Integração
A palavra integração pode significar tanto o processo de integração, como o seu resultado. Apresenta-se aqui a definição de integração, como resultado de um processo de integração. Integrar é obter uma operação mais eficaz dos processos de negócio de uma empresas e entre eles, compreendendo as pessoas, máquinas e informação, de acordo com os objetivos da empresa (Goranson 1997). Integração significa unificar componentes heterogêneos de uma forma sinérgica. Em uma empresa trata de facilitar o acesso a informação, o controle e fluxo de material, conectando todas as funções e entidades funcionais heterogêneas. Com isso melhora a comunicação, cooperação e coordenação dentro da empresa, de forma que ela se comporte como um "todo" integrado, assim como sua produtividade, flexibilidade e capacidade de gerenciamento de mudança (Vernadat 1996).
Como integrar?
Para se integrar deve-se ter uma visão única (holística) do negócio, compartilhada por todas as pessoas da empresa. Esta visão pode ser representada por seus processos de negócio. Os objetivos da empresa devem estar alinhados com as suas estratégias e com os objetivos pessoais de cada um. Ela deve se tornar parceira dos fornecedores e atender sempre as necessidades de seus clientes. A ações de melhoria adotadas pela empresa devem ser harmônicas entre si. Os sistemas de gestão precisam suportar todos esses requisitos, etc.. Pode-se listar um número maior ainda de características e atividades correspondentes que leva à integração. No entanto o processo de integração depende de dois fatores básicos: educação e metodologia. A integração começa com educação, passa por educação e continua com educação. Utiliza-se aqui o significado amplo do termo educação, que se inicia fora das empresas e continua por toda a vida profissional do indivíduo.A educação influencia principalmente a cultura técnica da empresa e a sua capacidade de aprendizado, passando por motivação e tomando como referência as necessidades e habilidades existentes. Deve-se atuar na educação em todos os níveis da empresa, do presidente e diretoria aos operários ("colaboradores"). Nos primeiros devem estar fundamentados os conceitos de integração, business process, técnicas gerenciais, estabelecimento de estratégias, etc. .Para os últimos, conceitos de suas múltiplas funções, habilidades necessárias, conhecimentos específicos, etc.. Isso para não falar dos níveis intermediários. Esta colocação é propositadamente superficial, com a intenção somente de se destacar a importância da educação, pois quem realmente agrega valor à manufatura de uma forma ampla são as pessoas que trabalham dentro da empresa (o autor deste não considera o termo recursos humanos apropriado neste caso). A metodologia deve proporcionar um frame de métodos, técnicas e ferramentas, que o indivíduo educado (ou grupo de indivíduos) pode acessar e utilizar conforme a sua necessidade específica. É uma referência de como se deve agir para se obter a integração. Pode-se tomar como exemplo a Metodologia de Integração de Empresas (MIE) desenvolvida no NUMA. Ela é uma metodologia de gerenciamento de mudanças (change management) e possui três grandes ciclos que devem ser sempre repetidos: diagnóstico, desenvolvimento de projetos (planejamento e especificação) e implementação/monitoramento. A visão holística da empresa com base no conhecimento e especificação do business process está contida no desenvolvimento de todas as suas fases. A ênfase aqui é criar uma sinergia entre as diversas abordagens de melhoria dos negócios. Quando se analisa, por exemplo, o ciclo de PDCA (plan-do-check-act) da escola da qualidade percebe-se uma certa semelhança com o príncipio de change management. A diferença está em no gerenciamento de mudanças, sempre se tem como referência a imagem única e abrangente da empresa através da visualização de todas as dimensões dos seus processos de negócio, que pode ser obtida por meio da modelagem de empresas.
Considerações adicionais
Devido à visão abrangente apresentada, a integração é influenciada pelos avanços em: planejamento estratégico, novas formas organizacionais, tecnologia de informação, relacionamento entre empresas, métodos de produção etc.. Apresentam-se aqui alguns exemplos que podem influir na integração da manufatura. Integração Homogênea do ponto de vista de tecnologia de informação A integração homogênea parte do princípio que existe uma base de dados única para todos os aplicativos. Isto é conseguido através de sistemas de gestão integrados (ERP), que contém teoricamente todos os aplicativos que uma empresa de manufatura necessitaria. Esses sistemas são bem flexíveis, pois podem ser configurados para diversas alternativas. Uma dificuldade desses sistemas integrados é o seu tempo e custo de implantação (por falta de profissionais que suportem uma implantação rápida) e limitações funcionais para atendes às especificidades de cada negócio. Devido a isso, existem vários aplicativos complementares, que já trabalham integrados com esses sistemas. O problema ainda fica na integração da base de dados, pois os modelos dos sistemas integrados normalmente fazem um uso extenso da integridade referencial, dificultando a troca on-line de dados com aplicativos não nativos no sistema integrado. Alguns sistemas, no entanto, fornecem interfaces de dados padrão, onde se armazenam os dados que se deseja inserir, ficando a criação do relacionamento referencial a cargo do próprio aplicativo. Normalmente, o problema de integração é resolvido pelos fornecedores do sistema complementar e do ERP. Existem sistemas integrados baseados na arquitetura cliente-servidor e outros com base em intranet. Os que rodam em clientes Windows podem fazer uso da tecnologia OLE (object link embedded), o que facilita a integração funcional com outro aplicativo que trabalhe também com o padrão OLE. O mesmo acontece no mundo UNIX com o padrão CORBA. Em futuro próximo aguarda-se que tanto um padrão único seja adotado para qualquer plataforma de hardware. Integração Heterogênea do ponto de vista de tecnologia de informação A integração heterogênea, como o próprio nome diz, preocupa-se em integrar sistemas distintos, desenvolvidos por fornecedores diferentes. Ela toma como base um repositório de dados também conhecido como meta base de dados, que é uma espécie de dicionário de todos os dados que estão nas bases de dados de cada um dos aplicativos a serem integrados. A grande desvantagem aqui é o armazenamento redundante de dados. Por utilizar sistemas diferentes, pode acontecer que em um ambiente heterogêneo exista também uma redundância das funções oferecidas por dois aplicativos ou mais. Nesse caso o modelo do processo de negócio adotado como referência deve prever qual funcionalidade de qual sistema é para ser utilizada na realização de uma atividade. Um padrão que pode colaborar para a efetivação deste tipo de integração é se todos os fornecedores de sistemas integrados oferecerem interfaces em conformidade com padrões (STEP seria tal iniciativa se provesse uma especificação para todos os possíveis objetos -business object - das empresas de manufatura) - vide sites relacionados. Equipes Virtuais A globalização da economia traz, entre outras, uma estratégia de se operar simultaneamente em vários locais distintos. Isso pode ocorrer, por exemplo, no desenvolvimento de um produto, com várias pessoas localizadas em diversos locais trabalhando em grupo e fazendo uso da tecnologia de telecomunicação. Suas atividades seriam suportadas por sistemas de workgroup computing e elas formariam então um time virtual. Automação do Processo de Negócio Uma outra tecnologia disponível parece que pode ser o caminho para a criação de software no futuro. Essa tecnologia tem a sigla BPA (business process automation) ou BPE (business process execution) e seu princípio está na automação de atividades específicas definidas em um BP resultante, por exemplo, de um trabalho de Reengenharia. O desenvolvimento desses building blocks de software específicos seria realizado com um ferramenta de desenvolvimento orientada por objeto com grande produtividade e alto grau de abstração.
Artigos
AGUIAR, A. F. S.; ROZENFELD, H.; RENTES, A. F.; BREMER, C. F.; ALLIPRANDINI, D. H. (1994). Integração da manufatura: o caminho para a modernização. Máquinas e Metais, p.98-113, set. (t:836). GORANSON, H. T.(1997). Human factors and enterprise integration, Workshop 1 Report ICEIMT, 82-87. HANDY, C.; (1995). Trust and the virtual organization. Harvard Business Review, Harvard, v. 73, n.3, p. 40-50. (t:804). PETRIE, C. J. (1992). The Model / Application Link. Report of the Workgroup 1 of the ICEIMT Workshop II. In: Proceedings of the First International Conference on Enterprise Integration Modeling. p.42-46. The MIT Press, Cambridge. ROZENFELD, H. (1996). Reflexões sobre a manufatura integrada por computador (CIM). In: MANUFATURA CLASSE MUNDIAL: Mitos e realidade. São Paulo, 1996. (t:1)
Livros
VERNADAT, F. B. (1996). Enterprise modelling and integration: principles and applications. London: Chapman & Hall. (t:625) SAVAGE,C. M. (1990). Fifth generation management: integrating enterprises through human networkng. Burlington: Digital Press. ( Disponível na biblioteca da FEA - USP ). KOSANKE, K.; NELL, J. G. (1997). Enterprise engineering and integration: building international consensus. INTERNATION CONFERENCE ON ENTERPRISE INTEGRATION AND MODELING TECHNOLOGY. 1997. Procedings. (t: 510)
Sites Relacionados
International Conference on Enterprise Integration and Modeling Techniques http://tools.org/EI/ICEIMT/ É uma conferência em constante desenvolvimento, agregando pesquisadores mundiais na área de integração, fomentada por agências finaciadoras européias e americanas. Já realizou 2 congressos (1992 e 1997), onde os resultados de workshops que tratam de questões em integração são apresentados, assim como novas contribuições. Semântica de plug and play para integração http://www.mel.nist.gov/workshop/jtc1-96/papfultn.htm Site preparado pelo Joint Workshop on Standards com paper definindo dados e processos de sistemas de informação, com o objetivo de identificar oportunidades de colaboração entre organizações utilizando modelos padrão. Neste site pode-se levantar várias informações sobre padrões de interoperacionalidade. Construction IT - STEP Standard:http://www.vtt.fi/cic/links/step.html Siemens - STEP Competence Center: http://www.atd.siemens.de/it-dl/step/index.htm STEP Tools:http://www.steptools.com STEP - A key tool in the global market: http://www.ukcic.org/step/stpgolb1.htm
Lean Production http://www.portaldeconhecimentos.org.br/index.php/content/view/full9635
Introdução
O modo de produção enxuta apresenta as seguintes características gerais: manufatura flexível com menor número de máquinas especializadas, redução de estoques, formação de empregados qualificados e multi-tarefas preparados para trabalhar em equipes, linha de montagem procurando prevenir falhas e evitar reparos finais, relacionamento de cooperação e de longo prazo com fornecedores. Um desempenho superior no desenvolvimento de produtos resultante do modo enxuto, somente será transformado em vantagem competitiva para a empresa se ela tiver toda uma administração voltada para esse modo, o que significa ter a linha de montagem e produção, relacionamento com fornecedores e tratamento com o consumidor final operando em sintonia e de acordo com as regras do modo enxuto de produção. No desenvolvimento de produtos das organizações enxutas, há uma ênfase em equipes multifuncionais com liderança forte, e com participação ativa de especialistas das diversas áreas funcionais sendo valorizados pela atuação dentro da equipe. A conseqüência deste enfoque enxuto no desenvolvimento do produto é a capacidade de projetar e produzir uma maior variedade de produtos atendendo à fragmentação do mercado, conseguindo a fidelidade dos clientes pela qualidade e confiabilidade dos produtos produzidos, representando para as organizações que o empregam um grande salto na produtividade, qualidade dos produtos e resposta rápida às cíclicas exigências do mercado. As companhias que dominam o projeto enxuto apresentam vantagens competitivas pois podem ampliar sua variedade de produtos, atingindo melhor os diferentes segmentos do mercado. Outra possibilidade é uma maior taxa de renovação de produtos, mantendo-os mais atualizados do que a concorrência. Essas duas tendências, que vêm sendo utilizadas pelos produtores enxutos mundiais, afetam significativamente os volumes de produção, conciliando até certo ponto a grande variedade de produtos à venda no sistema de produção artesanal, com um volume elevado de produção, e consequentemente baixos preços e acesso ao mercado de massas, do sistema de produção em massa clássico. Além de maior variedade de produtos ou menores ciclos de renovação, pode-se utilizar este conjunto de vantagens na implementação de um eficiente processo de desenvolvimento de inovações tecnológicas no produto. O projeto enxuto, permite uma aproximação maior entre o setor de pesquisa e desenvolvimento e a engenharia do produto significando em rápida introdução de inovações tecnológicas nos novos modelos, com menor comprometimento da confiabilidade do produto final e de sua manufaturabilidade.
Guia de leitura das informações adicionais
Não há como tratar do assunto Lean Production sem mencionar o principal esforço de pesquisa mundial que tratou deste tema, realizado em meados dos anos 80 pelo IMVP - International Motor Vehicle Program do MIT. Do trabalho deste grupo resultaram as principais referências colocadas nas Informações Adicionais desta página sobre Lean Production. Sem dúvida o livro "A Máquina que mudou o Mundo" (1992) é a obra mais conhecida e fundamental para se compreender a superioridade do sistema de produção enxuta em relação ao sistema de produção em massa tradicional. Esta obra mostra isso contrastando a forma como as montadoras japonesas e particularmente a Toyota, criadora da Lean Production, tratavam dos aspectos fabricação, projeto, gestão de fornecedores e consumidores, com resultados bem superiores aos obtidos pelas montadoras norte-americanas e européias, fiéis seguidoras aquela época do sistema de produção em massa. O artigo de Krafcik (1998), que foi o principal especialista em fábricas da equipe do IMVP - MIT, apresenta basicamente as mesmas linhas de discussão, podendo ser uma opção para uma leitura rápida, mas sem o mesmo detalhamento que o livro trás. Após esta primeira fase do IMVP, e com a enorme repercussão desta pesquisa e do livro, muitas montadoras e empresas de outros setores industriais começaram a reagir buscando implementar os princípios preconizados pela Lean Production. Neste sentido os dois artigos citados da Harvard Business Review (1994) enfatizam a necessidade de se considerar a Lean Production em todas as atividades da empresa e em sua própria estratégia competitiva (e não somente na produção e na fabricação em si). Por fim, o segundo livro do IMVP "A Mentalidade Enxuta" segue esta mesma linha e mostra as experiências e os resultados obtidos por empresas, em diferentes tipos de indústrias, que buscaram implantar a Lean Production. Os sites relacionados permitem que se tenha mais detalhes do trabalho do IMVP e duas de suas derivações mais importantes, o laboratório de Projeto de Sistemas de Manufatura (PSD) e o Lean Enterprise Institute.
Artigos
HAYES, R. H.; PISANO, G. P.; (1994). Beyond world-class: the new manufacturing strategy. Harvard Business Review, p.77-86, Janeiro-Fevereiro. (t:802) KRAFCIK, J. F.; (1988). Triumph of the lean production system. Sloan Management Review, Autumn p. 41-52. WOMACK, J. P.; JONES, D. T.; ROOS, D.; (1992). A Máquina que mudou o mundo. Rio de Janeiro: Campus. ( Disponível na EESC - USP ) WOMACK, J. P.; JONES, D. T.; (1994). From lean production to the lean enterprise. Harvard Business Review, p.93-103. Março-Abril. (t:809). WOMACK, J. P.; JONES, D. T.; (1997). A Mentalidade Enxuta. Rio de Janeiro: Campus(Disponível na biblioteca da UFSCar)
Sites Relacionados
PSD-Production System Design Laboratory(1998)http://lean2.mit.edu/ LEI-Lean Enterprise Institute(1998)http://www.lean.org IMVP - International Motor Vehicle Program (1999)http://web.mit.edu/afs/athena.mit.edu/org/c/ctpid/www/imvp/
MAPA NAVEGÁVEL DE PRÁTICAS PARA A MELHORIA DA APLICAÇÃO DO FMEA NO PROCESSO DE DESENVOLVIMENTO DE PRODUTOS http://www.portaldeconhecimentos.org.br/index.php/content/view/full11436
Introdução
Ao longo dos anos, praticantes e pesquisadores do FMEA têm publicado, em periódicos acadêmicos, trabalhos sobre deficiências do método e sobre propostas para mitigá-las. No entanto, essas deficiências e propostas de melhorias estão dispersas em diferentes trabalhos científicos, impossibilitando ter uma visão do geral e do relacionamento entre elas. Em vista disso, o objetivo desta pesquisa foi levantar, sistematizar e organizar as deficiências e os problemas do FMEA e as respectivas propostas de melhorias. Desta forma, a pesquisa com o título "Sistematização de problemas e propostas de melhorias da aplicação do FMEA no Processo Desenvolvimento de Produtos " foi desenvolvida pelo aluno de IC, Bruno Domiciano Villari, aluno do curso de Engenharia de Produção Mecânica, co-orientado pelo Mestrando Rafael Laurenti e orientado pelo Professor Titular Henrique Rozenfeld, sendo ambos representantes do Grupo de Engenharia Integrada/Núcleo de Manufatura Avançada da Escola de Engenharia de São Carlos da Universidade de São Paulo. Vale ressaltar que a pesquisa foi subsidiada pela FAPESP e teve duração de um ano, iniciada em dezembro de 2008 e finalizada em dezembro de 2009. A essência da pesquisa foi a realização de uma Revisão Bibliográfica Sistemática (RBS), onde seguindo um protocolo para a realização da mesma, 106 artigos foram selecionados como relevantes de um total de 2606 trabalhos científicos. Estes trabalhos foram alcançados por meio de algumas bases de dados, como Compendex, Scopus, Science Direct, ISI Web of Knowledge, Emerald e IEEE xplore. Além disso, pode-se perceber que tais trabalhos científicos eram provenientes de renomadas fontes de publicações tais como Annual Reliability and Maintainability Symposium, International Journal of Quality and Reliability Management entre outros. E assim, dando maior confiabilidae a esta pesquisa. Ainda seguindo o protocolo da RBS, foram levantados 361 problemas que o FMEA apresenta durante sua aplicação, sendo sintetizadas em 37 problemas com o intuito de apresentá-los de maneira mais clara e objetiva. Então, eles foram classificados e sistematizados em uma árvore de causa e efeito, facilitando, assim, a visão do relacionamento entre eles. Já com relação às práticas que foram filtradas pela RBS, somaram-se um total de 161, sendo a prática um termo genérico para abordagem, ferramenta, framework, método, sistemas e diretrizes que pode melhorar a aplicação do FMEA durante o Processo de Desenvolvimento de Produtos (PDP). Dessa forma, as práticas foram separadas resultando em 2 abordagens, 1 ferramenta, 7 frameworks, 71 métodos, 25 sistemas e 55 diretrizes, sendo apresentados pela última seção deste artigo, complementando o mapa navegável que é apresentado. A próxima seção trata dos problemas do FMEA, e a seção seguinte trata das práticas para melhorar aplicação do método.
Problemas identificados do FMEA
Com o intuito de sistematizar os 37 problemas apresentados pela RBS, então, eles foram ranqueados por ordem de freqüência de aparecimento, organizados em classes e receberam um identificador (ID), como pode ser observado pela Tabela 1, que lista os 37 problemas ordenados em ordem decrescente de freqüência de aparecimento nos 106 artigos selecionados durante a RBS. Tabela 1 - Lista dos problemas ordenados pela freqüência de aparecimento nos estudos selecionados da revisão sistemática
ID Classe do problema Problema Freqüência (%)
1.1 RPN Os valores dos RPNs não são precisos 34,91
4.1 Comportamental A realização de um FMEA completo e rigoroso demanda grande quantidade de tempo e recursos 31,13
3.1 Integração PDP A aplicação do FMEA não é integrada com outros métodos e atividades do PDP 24,53
2.1 Temporal Realizado tarde no PDP 21,7
1.2 RPN Os índices são utilizados como se todos tivessem a mesma importância 20,75
1.3 RPN Um mesmo valor de RPN pode representar situações caracterizadas por diferentes níveis de risco 19,81
6.1 Operacional É considerado tedioso pelos praticantes 16,04
1.4 RPN Critérios qualitativos são usados como quantitativos 15,09
5.1 Gestão de conhecimentos Falta de reuso de informações sobre falhas (FMEAs passados e falhas em campo) 14,15
6.2 Operacional É considerado laborioso pelos membros do time 12,26
6.3 Operacional Falhas múltiplas não são consideras 11,32
4.2 Comportamental Dependente da experiência dos membros do time 10,38
4.3 Comportamental Dificuldade em definir ações de melhoria adequadas, considerando a viabilidade (restrições), a chance de sucesso (redução do RPN), e os impactos desfavoráveis (nas pessoas, produto, processo, ambiente) 9,43
1.5 RPN Dificuldade em estimar os valores para os índices 8,49
5.2 Gestão de conhecimentos Falta de uma taxonomia padrão 8,49
6.4 Operacional Os custos das ações de melhoria não são estimados 7,55
6.5 Operacional Os custos de falhas que chegariam aos clientes não são estimados 7,55
1.6 RPN Presença de lacunas na escala de 1 a 1000 do RPN (números primos) 6,6
2.2 Temporal Dificuldade de se obter dados relevantes sobre o projeto do produto/processo 6,6
6.6 Operacional O formulário do FMEA não representa todos os dados relevantes da análise 6,6
1.7 RPN Os índices numéricos não são expressivos (não expressam a realidade) 5,66
4.4 Comportamental Realizado somente por questões contratuais 5,66
1.8 RPN Pequenas mudanças nos valores dos índices levam a grandes alterações do RPN 3,77
2.3 Temporal Aplicado somente após o protótipo ser construído e testado 3,77
4.5 Comportamental FMEA utilizado para checagem e não para se propor melhorias 3,77
4.6 Comportamental Conflito entre os membros do time na atribuição de valores para os índices 3,77
6.7 Operacional Os níveis de complexidade do item de análise não são considerados 3,77
4.7 Comportamental Dificuldade de reunir o time multidisciplinar, fornecedores, e consumidores nas sessões do FMEA 2,83
6.8 Operacional Repetitivo, já que deve estar sempre atualizado 2,83
7.2 Outros Não levados em conta aspectos ambientais na proposição de melhorias 2,83
1.9 RPN RPN não considera o tamanho do lote para atribuir a probabilidade de ocorrência da causa da falha 1,89
4.8 Comportamental Falta de entendimento da importância do FMEA 1,89
1.10 RPN O índice de Severidade é definido pelo projetista e não pelo consumidor 0,94
6.10 Operacional Falta de agrupamento de modos de falhas (mecânica, elétrica, etc.) 0,94
6.9 Operacional Não existem critérios para selecionar itens que serão analisados pelo FMEA 0,94
7.1 Outros Não considera (previne) falhas originadas em diferentes departamentos da organização 0,94
7.3 Outros Dificuldades em se definir os modos de falhas de sistemas críticos de segurança em tempo real (marca-passos, airbags, etc.) 0,94
A seguir, com o intuito de relacionar os 37 problemas encontrados e definir os problemas que são causas raiz, foi construída uma árvore de causa e efeito. Durante a construção da árvore ocorreram iterações com especialistas. Os especialistas opinaram sobre a existência dos relacionamentos entre os problemas, e, a partir das opiniões, alguns problemas foram eliminados, outros foram inseridos, e ainda outros foram considerados como fatos. A árvore de causa-efeito é apresentada abaixo pela Figura 1 (clique para abrir em tamanho grande em uma nova janela). As cores simbolizam as classes que os problemas pertencem. Sendo que, os problemas sugeridos para serem atacados são os retângulos com borda vermelha. Figura 1 - Árvore de causa e efeito dos problemas e deficiências do FMEA
Melhorias propostas para o FMEA
A RBS proporcionou a extração subjetiva de 161 práticas por meio da análise dos 106 artigos selecionados, sendo que tais práticas foram classificadas em abordagens, ferramentas, frameworks, métodos, sistemas ou diretrizes. Ressaltando que, estas práticas têm como intuito melhorar a aplicação do FMEA, e assim, proporcionar um PDP mais isento de falhas. Cada prática apresentada abaixo possui um link. Este link leva à uma página da web que disponibiliza além de sua descrição, um ícone que possibilita fazer o download do artigo proveniente da RBS, e que apresenta a prática de maneira completa, proporcionando, assim, um conhecimento mais aprofundado sobre cada prática. Para contribuir com o mapa navegável, uma planilha do excel foi anexada a este artigo, sendo apresentada por ela, o nome do artigo proveniente da RBS, a prática introduzida pelo artigo, o tipo de prática adotada (abordagens, ferramentas, frameworks, métodos ou sistemas) e as diretrizes alcançadas pela prática. Em seguida, são apresentadas as práticas de acordo com sua classificação.
Abordagens
  • Abordagem chamada ROMDA (Reliability Optimization Method through Degradation Analysis) que adota o FMEA para prever a confiabilidade de um produto
  • Abordagem chamada FuRBaR (Fuzzy Rule-Based Bayesian Reasoning) para priorizar falhas no FMEA
Ferramentas
  • Ferramenta (planilha excel) de apoio a tomada de decisão baseada no QFD e no FMEA, que considera pessoas, tecnologia e organização
Frameworks
  • Framework para capturar e analisar modos de falha devido a interações entre sistemas/componentes
  • Framework para racionalização falhas em sistema em múltiplos níveis de abstração
  • Framework que modela o comportamento de um sistema para análise de risco e confiabilidade
  • Framework que usa fuzzy methodology (FM) para prever o comportamento de sistema
  • Framework para prever e atualizar o índice de ocorrência baseado na lógica Fuzzy
  • Framework para reusar conhecimentos do FMEA por meio de modelagem de conhecimentos
  • Framework iFMEA (intelligent FMEA)
Métodos
  • Método FMETA (Failure Mode and Effect Tree Analysis)
  • Método estatístico de clusterização para identificar falhas potenciais
  • Método que integra FMEA, diagrama de Ishikawa, análise de Pareto com o método HACCP para manufatura de batata chips
  • Método que integra FMEA, diagrama de Ishikawa, análise de Pareto com o método HACCP para processamento industrial de salmão
  • Método que integra FMEA, diagrama de Ishikawa, análise de Pareto com o método HACCP para processamento industrial de polvo comum
  • Método melhorado de FMEA para o calculo do RPN
  • Método para fechar a lacuna no desenvolvimento de hardware e software usando o FMEA
  • Método Expanded FMEA (EFMEA)
  • Método Bouncing Failure Analysis (BFA)
  • Método para a avaliação da priorização do RPN na análise do FMEA
  • Método para priorização de modos de falhas usando a lógica fuzzy
  • Método chamado Priority-Cost FMECA (PC-FMECA)
  • Método que usa a teoria Grey para calcular o RPN do FMEA
  • Método que usa a lógica Fuzzy combinada com a teoria Grey para calcular o RPN do FMEA
  • Método chamado Design Process FMEA
  • Substitui o RPN do FMEA pelo UPN (Utility Priority Number)
  • Programação linear fuzzy aplicada aos métodos QFD e FMEA
  • Método FMEA modificado que identifica riscos de falhas que têm a mesma causa
  • Método FMEA que usa a abordagem Evidential Reasoning (ER - racionalização por evidência)
  • Método Timed FMEA
  • Método Total FMEA (TFMEA)
  • Método chamado Fuzzy Utility Theory based FMEA (FUT-based FMEA)
  • Método que usa o Overall Equipment Efficiency (OEE) para melhorar a aplicação do FMEA
  • FMEA para projeto baseado em risco
  • Método para integração do FMEA com o QFD
  • Método para o cálculo do RPN sem transformar valores qualitativos em quantitativos
  • Método FMEA que usa diagrafos e matrizes
  • Método para promover interações entre os métodos QFD e FMEA
  • Método FMEDA (Failure Mode Effect and Diagnostic Analysis)
  • Método FMEA aplicado para melhorar a confiabilidade de sistemas eletrônicos
  • Método probabilistic FMEA (pFMEA)
  • Método que usa o sistema de inferência fuzzy (fuzzy inference system) no FMEA para estimar o risco a partir de opiniões de especialistas sobre a quantificação de variáveis lingüísticas
  • Método FMEA com aspectos financeiros de risco e o modelo ABC (Actived-Based Cost)
  • Método para a análise de severidade baseado na linguagem UML
  • Método que combina o FMEA e o FAHP (Fuzzy Analytic Hierarchy Process) para avaliar riscos de componentes verdes
  • Método que combina o FMEA e o FAHP (Fuzzy Analytic Hierarchy Process) para a avaliação dos riscos de componentes verdes
  • Método Group-based Failure Effects Analysis (GFEA)
  • Método FMEA melhorado
  • Método Smart FMEA
  • Método scenario-based FMEA
  • Método para analisar modos de falhas usando FTA
  • Método que integra o QFD e o FMEA
  • Método Bayes Networking FMEA (BN-FMEA)
  • Método para modelar o conhecimento e realizar diagnóstico sobre falhas usando Polychromatic sets theory
  • Método que aplica Fuzzy Cognitive Maps (FCM) no FMEA
  • Método que usa Fuzzy Cognitive Maps (FCM) com um modelo de sistema para a análise do FMEA
  • Método qualitativo de integração da qualidade assegurada e da predição da confiabilidade por todo o ciclo de desenvolvimento de produto
  • Método mFMEA (multiple Failure Mode and Effects Analysis)
  • Método FMEA que usa a lógica probabilística approximate reasoning
  • Método FMEA aplicado em um sistema de decisão
  • Método Life Cost-Based FMEA
  • Método para priorizar falhas no FMEA
  • Método FMEA aplicado no gerenciamento da gestão técnica de riscos no PDP
  • Método alternativo para salvar custos da preparação do FMEA
  • Método de repriorização de modos de falhas do FMEA para proposição de ações corretivas
  • Método que integra o o FMEA e o modelo de Kano
  • Método FMEA que usa linguagem fuzzy de modelagem
  • Método Inter-Crossing
  • Método Function-Failure Design Method (FFDM)
  • Método para simplificar o FMEA baseado na lógica Fuzzy
  • Método para implementar o FMEA em um ambiente colaborativo
  • Método para geração do FMEA no projeto conceitual
  • Método FMAG (for FMEA generation)
  • Método FMEA invertido
  • Método que integra FMEA e FTA no processo de especificação de requisitos
  • FMEA usado na avaliação de custos de garantia
  • Método cost-oriented FMEA
  • Avaliação de risco no FMEA usando média geométrica ponderada fuzzy
  • Método para a aplicação do FMEA baseado na lógica Fuzzy
  • Método FMEA baseado na teoria Fuzzy
  • Método que combina o conceito de green design com os métodos FMEA e TRIZ
Sistemas
  • Sistema baseado no processo de racionalização causal para automatizar a análise do FMEA
  • Sistema de confiabilidade e análise de modos de falhas que adota a lógica fuzzy, baseado no procedimento do FMEA
  • Sistema chamado Enhanced FMEA (E-FMEA)
  • Sistema FMEA baseado em conhecimento que usa a lógica fuzzy
  • Sistema para automatizar o FMEA de componentes que sofrem mudanças incrementais
  • Sistema para gerar automaticamente árvores de falhas (FTA) e tabelas de FMEA que usa a modelagem Multi-level Flow Modeling (MFM)
  • Sistema de manutenção virtual para apoiar o FMEA
  • Sistema baseado na web para apoiar à elaboração do FMEA
  • Sistema web de apoio à elaboração do FMEA
  • Projeto de uma base de dados relacional para armazenar informações do FMEA e automatizar o processo de aquisição informações
  • Sistema para auxiliar a aplicação do FMEA
  • Software de simulação numérica de modos de falhas
  • Sistema FMEA Streamlining
  • Sistema para automatizar todo o ciclo de desenvolvimento de sistemas de circuitos elétricos/eletrônicos
  • Software para automatizar o FMEA
  • Software FMES (Failure Modes and Effects Simulation)
  • Sistema para aplicar o FMEA de maneira incremental
  • Sistema para automatizar a análise de segurança de projetos elétricos
  • Sistema que combina racionalização funcional e estrutural para a análise da segurança de projetos elétricos
  • Sistema para automatizar o FMEA para análise de falhas múltiplas
  • Sistema AutoSteve para análise de falhas múltiplas
  • Software para automatizar a aplicação do FMEA em circuitos elétricos chamado FLAME
  • Sistema para o FMEA incremental automatizado
  • Sistema baseado em conhecimento para a análise de modos de falha e efeitos
  • Software de racionalização baseada em modelo
Diretrizes
  • Integrar os métodos FMEA e QFD
  • Integrar os métodos FMEA e FTA
  • Usar dados de falhas em testes e em campo nas análises de falhas
  • Usar análise de clusters para identificar modos de falha de componentes
  • Integrar o design axiomático e o FMEA
  • Reaproveitar conhecimentos gerados em análise de falhas passadas para utilizá-los em novas análises
  • Usar taxonomia padrão
  • Aplicar o método HACCP em conjunto com o FMEA
  • Aplicar o diagrama de Ishikawa em conjunto com o FMEA
  • Usar a análise de Pareto para priorizar os RPNs
  • Usar um software para apoiar a aplicação do FMEA
  • Usar um software para modelar e simular o sistema para capturar modos de falhas, efeitos e causas
  • Automatizar a aplicação do FMEA usando processo de racionalização causal (causal reasoning process)
  • Priorizar falhas para a proposição de ações de melhoria utilizando a Lógica Fuzzy
  • Dar maior peso ao índice Ocorrência
  • Validar modos de falhas críticos e a resposta do sistema a falhas por meio de simulações
  • Ordenar, do menor para o maior, os valores dos RPNs em um gráfico Scree Plot e priorizar os RPNs a serem atacados que comporem a inclinação mais acentuada
  • Para um mesmo modo de falha, ranquear por viabilidade as ações de melhoria e selecionar a mais adequada
  • Retirar o índice Detecção
  • Segmentar a severidade nas classes segurança, operacionalidade e estética
  • Calcular o custo que as falhas poderiam incorrer
  • Usar a teoria Grey para calcular o RPN
  • Considerar como possíveis modos de falhas para o FMEA erros advindos das áreas: conhecimento, análise, comunicação, execução, mudança e organização
  • Avaliar a interdependência das ações de melhoria para decidir a ordem de implementação
  • Integrar o FMEA com as rotinas de testes de CAD/CAM
  • Identificar falhas originadas pela mesma causa
  • Priorizar falhas para a proposição de ações de melhoria utilizando usa a abordagem Evidential Reasoning (ER - racionalização por evidência)
  • O FMEA deve ser aplicado por todos os departamentos da empresa
  • Se todas as possíveis falhas de um subsistema conduzem ao mesmo efeito, então é aceitável considerar o subsistema como um único componente com modos de falhas amplamente definidos
  • Se o efeito final de falhas dentro de um subsistema depende de qual componente é considerado, então o subsistema deve ser quebrado em componentes mais específicos
  • A resolução dos índices de severidade e ocorrência deve ser entre 3 à 5
  • Antes de se iniciar o FMEA, deve ser definido o nível de risco considerado inaceitável
  • Considerar as interações entre os modos e efeitos de falhas
  • Gerar taxa de falhas para cada categoria importante (segurança, detectada, segurança, não detectada, perigo, detectado, perigo não detectado) em modelos de segurança
  • Quando for identificado que uma única falha pode causar a falha simultânea de vários componentes de um sistema, deve-se propor o uso de redundâncias, isto é, componentes que têm a mesma função mas seus princípios de funcionamento são diferentes
  • Integrar os métodos FMEA e FFA (Functional Failures Analysis)
  • Usar modelos virtuais para apoiar a análise do FMEA
  • Antes de iniciar o FMEA, derivar um diagrama de bloco funcional ou hierárquico, claramente identificando a sequência do fluxo funcional e dependências ou independências das funções e operações. Um diagrama na forma de árvore é particularmente recomendado
  • Antes de inicial o FMEA, identificar o nível o qual a análise deve iniciar. O grau de detalhes depende do estágio que as análises são conduzidas
  • Capturar modos de falhas devido a interações entre componentes de um módulo
  • Definir o índice de severidade sob o ponto de vista do cliente
  • FMEA é um documento vivo e deve sempre ser atualizado sempre que o produto é modificado, um novo modo de falha é identificado, ou um projeto a prova de falhas é implementado
  • Usar um checklist de causas de falhas
  • Todas as informações incluídas no FMEA devem conter detalhes suficientes para que as partes envolvidas sejam capazes de executar ações específicas e de vinculá-las com a parte responsável na cadeia de suprimentos.
  • Deve ser especificado um valor quantificável (que possa ser medido) para uma função, para que as partes envolvidas da cadeia de suprimentos possam ter um entendimento claro e uma interpretação comum da função
  • As especificações de engenharia devem estar presentes detalhadamente no FMEA, as quais incluem requisitos funcionais, de confiabilidade, de segurança e de durabilidade do sistema, subsistema e componentes.
  • O relatório do FMEA deve ser parte do pacote de engenharia (desenhos, especificações de testes, etc.) que é compartilhado com toda cadeia de suprimentos
  • Os colaboradores envolvidos com o projeto e manufatura do produto devem discutir, revisar e atualizar os relatórios do FMEA, em diferentes momentos do processo de desenvolvimento do produto
  • Os times de FMEA da cadeia de suprimentos envolvidos devem concordar com uma escala comum para a atribuição do índice de detecção
  • Estabelecer um processo que garanta a inclusão de entradas dos fornecedores e clientes para o desenvolvimento do DFMEA
  • Deve ser estabelecida uma ligação entre DFMEA e PFMEA
  • Usar o DFMEA para gerar o plano de teste e verificação de projeto
  • Usar o PFMEA para gerar o plano de controle do processo
  • Garantir que os colaboradores entendam com utilizar o FMEA em seu trabalho
  • Integrar os métodos FMEA e TRIZ
SISTEMATIZAÇÃO DE PROBLEMAS E PROPOSTAS DE MELHORIAS DA APLICAÇÃO DO FMEA NO PROCESSO DE DESENVOLVIMENTO DE PRODUTOS
Medição de Desempenho http://www.portaldeconhecimentos.org.br/index.php/content/view/full10033
Introdução
Para Neely et al. (1995), medição de desempenho pode ser compreendida como a técnica usada para quantificar a eficiência e a eficácia das atividades de negócio. A eficiência vai tratar da relação entre utilização econômica dos recursos, levando em consideração um determinado nível de satisfação. Por sua vez, a eficácia avalia o resultado de um processo onde as expectativas dos diversos clientes são ou não atendidas. O’Mara et al,(1998), acrescenta que um sistema de medição de desempenho não apenas fornece dados necessários para a gerencia controlar as várias atividades da empresa, mas também influenciam as decisões e o comportamento organizacional. Já Stainer & Nixon (1997), afirmam que um sistema de medição focado em metas, pode ser um instrumento valioso para propor mudanças na administração de processos. Neste sentido, para Martins (1999), existe uma divisão temporal na formulação de sistemas de medição de desempenho. Antes da década de 90, onde os sistemas se baseavam apenas em indicadores financeiros e, após a década de 90, onde um grande número de sistemas passa a buscar também o uso das dimensões de desempenho. Para Bititci et al, (1997), existe um número incontável de organizações que possuem extensos sistemas de medição de desempenho baseados em práticas financeiras e de custos. Desta maneira, por serem fundados em técnicas e métodos tradicionais, elas falham em apoiar os objetivos estratégicos das empresas e não promovem melhoramento contínuo. Indicadores de desempenho tradicionais são baseados em sistemas contábeis. Retorno sobre o investimento (ROI), retorno sobre o patrimônio, retorno sobre vendas, variação nos preços, vendas por funcionário, lucro por unidade produzida e produtividade são alguns exemplos de indicadores de desempenho tradicionais. No entanto, tais indicadores possuem muitas limitações. A mais significante delas, é que esses indicadores são em grande parte baseados em sistemas gerenciais que focam o controle e redução dos custos de mão-de-obra (Business Week, 1988). De acordo com Noble (1997), os indicadores tradicionais são também limitados porque: a) os resultados financeiros são em algumas vezes muito velhos para serem úteis; b) tentam quantificar o desempenho e outros esforços de melhoria somente em termos financeiros; c) possuem um formato predeterminado que é utilizado pelos vários departamentos. Todo registro é inflexível e ignora o fato de que cada qual tem suas únicas e próprias características, prioridades e contribuição; d) tendem a ser inconsistentes com o conceito de melhoria contínua; e) não são aplicáveis as novas técnicas gerenciais que dão às operações de chão de fábrica mais responsabilidade e autonomia em qualidade, produção, manutenção preventiva e planejamento. Bititci et al. (1997), afirma que a grande maioria dos pesquisadores atualmente acredita na existência da necessidade de formulação de sistemas de medição de desempenho que contemplem não apenas os indicadores financeiros. White (1996) afirma que parte destas pesquisas surge a partir da clara necessidade de cada empresa utilizar medidas as quais são relevantes para sua própria situação. Por outro lado, alguns dados são comuns a todas as empresas. A padronização é uma forma de evitar a proliferação desnecessária de medidas e ter a certeza que importantes variáveis estão sendo corretamente medidas. Desta forma, pode-se observar na literatura, propostas de sistemas de medição de desempenho. Algumas das mais relevantes segundo Martins (1999), são: Balanced Scorecard (BSC) (Kaplan & Norton, 1992); SMART – Performance Pyramid (Cross & Linch, 1990); Sistema de Medição de Desempenho Integrado. (Bititci et al. 1997). Portanto, a partir da constatação de que somente indicadores tradicionais não são capazes de explicitar a realidade da empresa de forma geral, Neely et al (1995) propõe uma análise de medição de desempenho em três níveis: os indicadores de desempenho individuais, um sistema de medição de desempenho e como este sistema se relaciona com o ambiente (Neely et al, 1995). Dentro desta discussão, a análise dos indicadores passa pelas seguintes questões:
  • Que indicadores serão utilizados?
  • Para que eles são utilizados?
  • Quanto irá custar?
  • Que benéficos eles trarão?
Desta maneira, para Neely et al (1995), os indicadores de desempenho individuais fazem parte de um conjunto maior que pode ser chamado de dimensões de desempenho, e que por sua vez, são divididos em qualidade, tempo e flexibilidade. Assim, pode-se ver um sistema de indicadores de desempenho como um conjunto integrado de dimensões de desempenho, desdobradas em indicadores individuais, que visam prover informações sobre desempenho para determinados fins. Para Meyes (1994), Neely et al. (1996), Eccles & Pyburn (1992), e Bititci, (1995), um sistema de indicadores de desempenho deve conter dados para monitorar o passado e planejar o futuro. Os indicadores de desempenho tradicionais e os não financeiros, devem ser integrados dentro de um sistema único, onde se deve considerar informações dos vários sistemas para fornecer o nível necessário de dados em termos de acuracidade e confiabilidade. Os administradores, ao configurá-lo, devem resolver questões como o desenvolvimento de metodologias para a coleta das medidas, assim como a sua periodicidade e destino. Devem prover a solução para conflitos entre os vários indicadores, a inclusão do reflexo da cultura organizacional e o apropriado equilíbrio do sistema com o ambiente que o circunda, levando em consideração as medidas internas (da própria organização) e externas (consumidores e concorrentes). Ao longo do tempo, o desenho de qualquer sistema de indicadores de desempenho deve refletir as operações básicas do suporte organizacional, sempre lembrando da importante relação intrínseca entre indicadores de desempenho e estratégia. Um dos mais conhecidos sistemas de indicadores é o Balanced Scorecard, proposto por Kaplan & Norton (1992), o qual é baseado em quatro perspectivas (financeira, clientes, interna e aprendizado e crescimento organizacional) e no princípio de que um sistema de medição deve fornecer aos administradores, respostas as algumas perguntas. Desta maneira, Bititci (1995), afirma que pesquisadores como Neely et al, (1995), Norton & Kaplan (1992), Eccles. & Pyburn. (1992), Meyes. (1994) e O’mara, et al. (1998), conduziram seus estudos na percepção da ligação entre indicadores de desempenho e planos estratégicos ou fatores de sucessos críticos dos negócios. Em suma, a necessidade de um conjunto de indicadores integrados que suportem a estratégia global da empresa está efetivamente estabelecida. Portanto, o objetivo geral de um sistema de medição de desempenho, é conduzir a empresa à melhoria de suas atividades, pelo fornecimento de medidas alinhadas com o ambiente atual da companhia e os objetivos estratégicos, de forma a permitir o monitoramento do progresso no sentido de atingir esses objetivos. Essas medidas podem ser vistas como a essência da melhoria do desempenho.
Artigos
BITITCI, U. S. et al. (1997). Integrated performance measurement systems. International Journal of Operations & Production Management. v 17. no. 5. pp 522-534; CARPINETTI, L.C.R. (2000). Proposta de um modelo conceitual para o desdobramento de melhorias estratégicas. Gestão & Produção. v.7, no.1; HRONEC, S. M. (1994). Sinais vitais. São Paulo: Makron Books, KAPLAN, R. S. & NORTON, D.P. (1992). The balanced scorecard – measures that drive performance. Harvard Business Review. Jan-Fev. pp 71-79; LEBAS, M. J. (1995). Performance measurement and performance management. International Journal of Production Economics. no. 41. pp 23-35; MARTINS, R. A . (1999). Sistemas de medição de desempenho: Um modelo para estruturação do uso. Tese (Doutorado) – Escola Politécnica. São Paulo. Universidade de São Paulo; MEYES, C. (1994). How the right measures help teams excel. Harvard Business Review. v 72. no. 3. Mai-Jun. pp 95-63; NEELY, A. et al. (1995). Performance measurement system design: A literature review and research agenda. International Journal of Production Economics. no. 4, pp 80-116; NOBLE, J. S. (1997). An integrated dynamic performance measurement system for improving manufacturing competitiveness. International Journal of Production Economics. no. 48, pp 207-225; O’MARA, C. E. et al. (1998). Performance measurement and strategic change. Managing Service Quality. v 8, no. 3, pp 179-182; STALK, G J. (1988). Time – the next source of competitive advantage. Harvard Business Review, Jul-ago, pp 41-51; SUWIGNJO, P. et al. (2000). Quantitative models for performance measurement system. International Journal of Production Economics. no. 64. pp 231-241; TAKASHINA, N. T. & FLORES, M. C. X. (1999). Indicadores da qualidade e do desempenho: Como estabelecer metas e medir resultados. Rio de Janeiro. Qualitymark Editora; WHITE, G.P. (1996). A survey and taxonomy of strategy-related performance measures for manufacturing. International Journal of Operations & Production Management. v 16, no. 3, pp 42-61.
Sites Relacionados
Grupo de pesquisa da Qualidade http://tigre.prod.eesc.sc.usp.br/producao/qualidade/index.htm Performance Measurement Association www.performanceportal.org
Mizen Boushi (GD3) http://www.portaldeconhecimentos.org.br/index.php/content/view/full9615
Introdução
A filosofia Mizen Boushi foi desenvolvida e validada com sucesso pela Toyota Motor Company. É também chamada de cubo GD (GD3), significa "medidas de prevenção". Se refere a um processo disciplinado focado nas fases iniciais do projeto de produtos e processos que suportam “lean manufacturing” e geram qualidade robusta. Checklists padronizados de projeto de produto e processo são cruciais para esse rigoroso processo.
Objetivo
O objetivo de Mizen Boushi é descartar a "mentalidade de solucionador de problema" e impedir dificuldades, antes das mesmas existirem. Isso compreende identificar as possibilidades de falha já durante a fase de desenvolvimento e utilizar o conhecimento do produto precedente e de falhas de processo. Assim, não somente a confiabilidade do produto é melhorada, mas, em conseqüência, todos os envolvidos - os departamentos, clientes e fornecedores – as relações internas e externas do processo de desenvolvimento do produto são adicionalmente otimizados. Um antibugging preventivo ocorre, no qual a confiabilidade do produto e a otimização das relações organizacionais são verificadas ainda durante o desenvolvimento do produto. Assim uma alavanca de ajuste crucial fica disponível, a fim de reduzir os custos decorrentes de falha.
Fontes
MORGAN, J. M.; LIKER, J. K. The Toyota Product Development System: Integrating People, Process and Technology. New York: Productivity Press, 2006. SCHMITT, R.; KRIPPNER, D.; BETZOLD, M. Geringere Fehlerkosten – höhere Zuverlässigkeit. Qualität und Zuverlässigkeit, Jahrgang 51, Ausgabe 06, p.66 - 68, 2006. SCHMITT, R. et al. Keine Angst vor Änderungen! Robustes Design für innovative Produkte. Qualität und Zuverlässigkeit, München, Jahrgang 52, Ausgabe 03, p.24 - 26, 2007. SCHORN, M.; KAPUST, A. Im Fluss: Wie Toyota von DRBFM Profitiert. Qualität und Zuverlässigkeit, München, Ausgabe 04, p.56 - 58, 2005.
Definições
"O conceito por trás de Mizenboushi consiste no conjunto das três fases: Good Design, Good Discussion und Good Dissection e, por isso, é chamado de Cubo GD (GD3). Nestas três fases, diferentes ferramentas estabelecidas do departamento de gerência da qualidade são interconectadas sistematicamente. Nisso inclui-se os métodos QM Design Review Based on Failure Mode (DRBFM), possibilidade de falha e análise de influência (FMEA), Quality Function Deployment (QFD), Fault Tree Analysis (FTA) bem como Design Reviews (DR). As causas de falhas que podem resultar das alterações na construção, implementação de demandas de clientes ou de tecnologias inovadores utilizadas são assim identificadas e evitadas.
Conceito
O conceito GD3 é baseado em um procedimento estruturado, onde os componentes já desenvolvidos e avaliados são deixados de lado, a fim de concentrar nas alterações substanciais do produto. Através de exames detalhados das alterações do produto - causadas pela situação inicial descrita acima - é possível analisar as influências da alteração no produto como um todo (sistema), assegurando assim a confiabilidade contínua do sistema. Por esse motivo é compreensível que Mizenboushi representa uma adição significativa no ciclo de desenvolvimento, especialmente para empresas que fabricam com o sistema de blocos ou oferecem produtos customizados ao cliente. Mas Mizenboushi fornece também uma sustentação apropriada para a indústria automobilística, já que muitos fabricantes de carro iniciam seus novos desenvolvimentos a partir de modelos precedentes.
Histórico
Mizen Boushi foi desenvolvido pelo Dr. Tatsuhiko Yoshimura na Toyota. Atualmente Yoshimura trabalha na General Motors e a auxilia na melhoria da qualidade do desenvolvimento de produtos.
As três fases do Cubo-GD
A filosofia Mizen Boushi é ilustrada a seguir (adaptado de SCHORN, 2005).
Good Design
Esta primeira fase serve para um projeto robusto de produto, que consiste em componentes provados do produto, a fim de limitar assim as alterações ao fundamental. Aqui as falhas ocultas são ativamente procuradas dentro do produto, do processo de fabricação do produto bem como nas relações internas e externas. Esta fase é suportada metodicamente, entre outras coisas, por QFD a fim de reconhecer e traduzir as demandas do cliente. Porque justamente na tradução das demandas do cliente nos critérios de qualidade, a nossa experiência mostra que é importante que estas demandas sejam precisamente convertidas. Os fabricantes devem, a cada modificação de produto, analisar com exatidão as influências dos grupos de construção modificados nos critérios de qualidade, a fim de evitarem falhas ou não preenchimento das demandas do cliente. Uma regra básica do Good Design para uma confiabilidade elevada é não alterar projetos robustos existentes. É necessário identificar os componentes chave, a fim de melhorar adicionalmente a confiabilidade.
Good Discussion und Good Dissection
Estas fases auxiliam nos respectivos estágios do processo de desenvolvimento na formulação e conversão das medidas aos problemas identificados. Dentro destas duas fases o método DRBFM é utilizado, dentre outros. Ele promove a condução de discussões direcionadas durante todo o processo de desenvolvimento. Seu formulário próprio serve à documentação do resultado e ao acompanhamento adicional das medidas. Informações – tais como análise do sistema, análise funcional e o status das medidas - resultantes de um FMEA ou FTA, servem como base de discussão, a fim de analisar o efeito das alterações. O objetivo principal destas fases é garantir o processo de desenvolvimento através de monitoração constante da confiabilidade do novo produto bem como da habilidade do processo de produção. Além disso, há também a monitoração e a documentação da confiabilidade com base nos resultados de testes de protótipo e das investigações de campo. O exame intensivo dos dados de processamento e o uso eficiente dos dados de campo no desenvolvimento de novos produtos e processos de produção asseguram que as falhas conhecidas não causem problemas de confiabilidade com o cliente, que levem a custos de garantia e serviços.
Resumo
GD3
Good Design Good Discussion Good Dissection
Identificação dos potenciais de falhas Prevenção de falha no desenvolvimento Identificação de falhas em protótipos
Minimização de Alterações Discussões relacionadas aos métodos como DRBFM Análises através de diversos métodos QM
Análise passo a passo Derivação e aplicação de medidas Derivação e aplicação de medidas
Auxílio metódico
Modelagem de Empresas http://www.portaldeconhecimentos.org.br/index.php/content/view/full9500
Introdução
Para permitir a integração de empresas é preciso que todos os elementos que a compõem, sejam eles homens, máquinas e sistemas computacionais, entre outros, sejam capazes de trocar informações entre si numa profundidade além da simples troca física de dados. Isto passa necessariamente pelo desenvolvimento de uma visão holística dentro da empresa, isto é, o desenvolvimento de uma imagem única e integrada nas pessoas que fazem parte desta organização. É por meio da atuação de pessoas possuidoras desta imagem ampla e integrada e, portanto, capazes de considerar a interação entre múltiplos fatores, que se desenvolve e sedimenta a integração da manufatura. Um dos mecanismos que podem auxiliar as pessoas a obter esta imagem integrada da empresa são os modelos de empresa. Modelos de empresa são representações de uma organização real que servem como uma referência comum para todos os seus membros, sejam eles pessoas, sistemas ou recursos. Este modelo forma uma infra-estrutura de comunicação que pode ter diversas aplicações. A partir do modelo de empresa qualquer pessoa pode adquirir uma visão geral sobre as operações, possibilitando análises, previsão de impactos das atividades, identificação de pontos de melhorias, entre outros, servindo, assim, como uma representação da visão holística. Com o apoio dos modelos de empresa é possível uma avaliação mais apurada do papel dos recursos nos processo de negócio e a análise e projeto da integração destes recursos com os demais. Existem atualmente diversas propostas direcionadas à modelagem de empresas. Há princípios, etapas, e uma grande quantidade de metodologias e ferramentas, também conhecidas como frameworks de modelagem. Apesar de todo este desenvolvimento e da importância que esta área vem recebendo dentro das organizações ainda persistem grandes barreiras para a aplicação destes modelos. Uma das principais barreiras é a complexidade gerada pela quantidade grande de elementos necessários para a representação destes tipos de sistemas. Um exemplo de modelo de empresas é o desenvolvido pelo Grupo de Engenharia Integrada para o processo de desenvolvimento (figura 1) O Modelo de Empresa como uma Infra-estrutura para integração Fonte: VERNADAT(1996), p.86 (deixar esta figura no meio do texto acima
Definição de Modelo de Empresa
Segundo VERNADAT (1996, p.24):
  • modelo: pode ser definido como "uma representação (com maior ou menor grau de formalidade) da abstração de uma realidade expressa em algum tipo específico de formalismo" ;
  • modelo de empresa: é um tipo específico de modelo formado por um conjunto de modelos que procuram representar as diferentes visões da empresa. É formado por um conjunto consistente e complementar de modelos descrevendo vários aspectos de uma organização e que tem por objetivo auxiliar um ou mais usuários de uma empresa em algum propósito".
Possíveis aplicações de um modelo de empresa
  • obter uma maior compreensão da empresa;
  • adquirir e registrar conhecimentos para uso posterior;
  • racionalizar e garantir o fluxo de informações;
  • projetar e especificar uma parte da empresa (funções, informação, comunicação, entre outros);
  • servir como base para análises de partes ou aspectos da empresa;
  • base para a simulação do funcionamento da empresa;
  • base para tomada de decisões sobre operações e a organização da empresa; e
  • base para o desenvolvimento e implantação de softwares de forma integrada;
Elementos a serem representados num modelo de empresa
  • a funcionalidade e comportamento da empresa em termos de processos, atividades, operações básicas e eventos que os iniciam;
  • processo, fluxo e pontos das decisões que têm que ser tomadas;
  • os produtos, suas logísticas e ciclos de vida;
  • os componentes físicos ou recursos, como máquinas, ferramentas, dispositivos de armazenagem e movimentação, podendo apresentar seus layout, capacidades, etc..;
  • as aplicações, softwares, em termos de suas capacidades funcionais;
  • os dados e informações, seus fluxos na forma de ordens, documentos, dados discretos, arquivos de dados ou bases de dados complexas;
  • conhecimento e know-how da empresa, regras específicas de decisão, políticas de gerenciamento interno, regulamentação, etc..;
  • indivíduos, especialmente suas qualificações, habilidades, regras, papéis e disponibilidades;
  • responsabilidade e distribuição de autoridade sobre cada um dos todos os elementos aqui descritos, ou seja, sobre as pessoas, materiais, funções, etc..;
  • eventos excepcionais e políticas de reação a eles; e
  • tempo, porque a empresa é um sistema dinâmico.
Benefícios
Os benefícios básicos da modelagem de empresa são VERNADAT (1996):
  • construção de uma cultura, visão e linguagem compartilhadas;
  • formalização do know-how e memória dos conhecimentos e práticas da empresa;
  • suportar decisões para melhoria e controle das operações da empresa, onde, inclui-se a introdução dos recursos da tecnologia de informática como um dos principais habilitadores para esta melhoria.
Barreiras e Dificuldades
A principal barreira para a modelagem de empresas está na complexidade e os altos custos envolvidos na geração destes modelos. Isto porque organizações são sistemas altamente complexos e que exigem a representação de diferentes tipos de elementos (informação, organização, métodos, conhecimento, etc..) com grandes e diversificadas interações entre si. Assim, os projetos que envolvem modelagem são geralmente longos e demandam esforços de uma grande equipe, além da contribuição de todos os profissionais da empresa. ainda riscos do modelo gerado não encontrar-se num nível suficiente de detalhamento e consistência conforme os objetivos pretendidos ou, ao contrário, derivar num modelo tão detalhado e complexo que inviabilize a visão ampla da empresa.
Conceitos Importantes para Compreender Modelagem de Empresas
  • Processo de Negócio: a maioria das ferramentas de modelagem de empresas e conceitos envolvidos nesta área estão baseadas no conceito de processos de negócio, assim denomina-se freqüentemente esta atividade de modelagem de processos de negócio.
  • Análise de Sistemas: grande parte dos conceitos sobre modelagem de empresas são comuns aos empregados pelos profissionais da área de análise de sistemas. Muitos diagramas, métodos específicos e formas de levantamento de dados são oriundos e, portanto os mesmos que esta área. Assim, para dominar os conceitos envolvidos com modelagem de empresas é importante possuir um básico sobre análise de sistemas (suas metodologias como a Abordagem Estruturada, métodos específicos como Diagramas-Entidade-Relacionamento, etc...)
Requisitos Básicos
(ROSS,1977, apud VERNADAT, 1996)
  • clareza sobre o objetivo a ser atingido com a modelagem;
  • escopo adequado à abrangência do domínio do problema que se pretende atacar com a modelagem;;
  • coerência entre as diferentes visões do modelo, não ignorando nenhum aspecto importante do problema;
  • nível de detalhe, isto é, a precisão ou granularidade, seja suficiente.
Princípios de Modelagem de Empresas
  • Separação de Conceitos: este é o princípio segundo o qual a técnica de modelagem precisa abordar a empresa a partir de um conjunto de elementos menores e distintos, ou seja, abordá-la "aos pedaços", formando um conjunto de elementos onde cada um representa uma única e funcional parte do domínio do problema tais como produto, processo, planta. Segundo este princípio não há a possibilidade de modelagem baseadas em abordagens que consideram "a empresa como um todo";
  • Decomposição Funcional: segundo este princípio a técnica de modelagem de empresa precisaria permitir o mapeamento hierárquico de todas as funções da empresa, começando da definição de funções mais macro, decompondo-as num conjunto de subfunções até a descrição das funções mais específicas. Por exemplo: "analisar mercado" é uma função numa empresa que poderia ser decomposta em "identificar consumidores", "desevolver perfil de consumidores" , "homologar", "produzir lote piloto", etc..., as quais, por sua vez, poderiam ser decompostas em outras subfunções, até níveis mais específicos como uma função específica de uma aplicação de software.
  • Modularidade:para diminuir a complexidade, facilitando o gerenciamento das alterações e mesmo a manipulação do modelo, é preciso que a técnica de modelagem permita a definição de módulos que possam ser combinados ou reusados num projeto de modelagem posterior;
  • Generalização: este conceito é similar ao utilizado em modelagem de objetos e de dados na área de informática. Segundo este princípio a técnica de modelagem de empresas deve possibilitar a criação de classes que agrupem os objetos segundo propriedades idênticas. Assim uma propriedade definida para uma classe é transferida para todos os objetos que compõem esta classe. (Veja por exemplo o artigo de MERTINS, JOKEL e JäKEL (1997), onde apresenta-se exemplos da utilização de técnicas de modelagem de empresas orientada a objetos);
  • Reusabilidade: o método de modelagem deve permitir que o modelo possa ser construído com base em blocos predefinidos ou modelos parciais ambos agrupados por propriedades semelhantes tal que se garanta, tanto quanto possível, a reutilização de partes do modelo em novos modelos;
  • Separação entre Comportamento e Funcionalidade: uma técnica de modelagem de empresa deve garantir a separação entre funcionalidades, ou seja o que a empresa faz, do comportamento, ou seja, de como ela o faz, ou seja, descreve seus estados para atingir a funcionalidade proposta. Esta separação proporciona flexibilidade ao modelo diminuindo o efeito da modificação e facilitando o entendimento;
  • Separação entre Processos e Recursos: similar ao item anterior, a técnica de modelagem deve permitir a separação entre processos, no sentido de "coisas" que devem ser feitas, dos recursos, que são bens materiais e informações necessárias para fazê-lo;
  • Conformidade: este princípio diz respeito a acurácia da representação. Os constructs utilizados pelo método de modelagem devem permitir uma sintaxe e semântica claras, consistentes, não redundantes e capazes de lidar com o domínio da aplicação do modelo de empresa;
  • Visualização: a técnica de modelagem deve proporcionar também uma linguagem de representação de fácil comunicação (fácil leitura e representação) e suportada por uma não ambígua e clara representação gráfica;
  • Simplicidade versus Adequação: este princípio, de forma resumida, é o que exige " que a técnica de modelagem deve ser rica o suficiente para expressar o que precisa ser expresso" (VERNADAT, 1996, p. 82), ou seja, que ela seja a mais simples possível sem que haja perda na adequação ao propósito do modelo, ou seja, que ela balanceie o trade off entre simplicidade e adequação.
  • Gerenciamento da Complexidade: qualquer técnica de modelagem de empresa deve ser capaz de lidar com sistemas de alto grau de complexidade, pois, os sistemas organizacionais são complexos e dinâmicos e, em caso de menor complexidade a modelagem de empresas perde seu grande poder de auxílio, pois o próprio bom senso e linguagem comum poderia ser utilizada;
  • Rigor da Representação: o modelo não dever ser ambíguo e muito menos redundante, permitindo a verificação de propriedades, análises e até mesmo simulações do comportamento do sistema, ou da empresa;
  • Separação entre Dados e Controles: particularmente para os modelos de empresa é preciso que haja uma distinção entre dados necessários para a realização de um processo, dos controles, que também são dados, só que utilizados pelo processo para definições de como e quando operar (neste aspecto modelo de empresa apresenta algumas características semelhantes de sistemas computacionais de tempo real);
Processo de Modelagem de Empresas
O processo de modelagem de empresa pode ser contextualizado por meio da figura abaixo, conforme Vernadat (1996): Como entradas deste processo tem-se: conhecimento sobre a empresa (conhecimento sobre a empresa que está sendo modelada e que reside espalhado entre todos os funcionários e pessoas que trabalham na organização); ontologia do domínio (uma formalização de algum conhecimento em termis de conceitos abstratos e axiomas); biblioteca de modelos conjunto de modelos e objetos que o profissional de modelagem ou a empresa já possuem e que podem ser reaproveitadas dependendo do objetivo da modelagem. Os controles que guiam os modelos do processo são os objetivos para os quais serão empregados os modelos, a metodologia de modelagem adotada e as métricas que avaliam o andamento deste processo. A execução deste processo é de responsabilidade das pessoas (engenheiros de empresa ou analistas de empresa) devidamente conhecedoras da ontologia do domínio do problema da empresa e dos métodos de representação dos modelos. Como resultado final obtém-se o próprio modelo de empresa, composto por diversos modelos consistentes e coerentes entre si, tais como modelos de processo, modelo de dados, entre outros.
Tipos de Metodologias de Modelagem de Empresas
Diversas metodologias podem ser utilizadas para desenvolver modelos de empresa, variando em níveis de sofisticação e abrangência. Na realidade um modelo pode ser desenvolvido desde a partir de uma simples linguagem gráfica reproduzida à mão até empregando frameworks sofisticados que empregam diferentes visões e modernos conceitos como orientação à objeto. Baseando-se no trabalho de DOUMEINGTS, VALLESPIR & CHEN (1995), podemos classificar os tipos de metodologias de modelagem em:
  • Modelos de referência e Arquiteturas (Frameworks): conjunto de modelos contemplando uma coleção invariante de building blocks (elementos fundamentais) a partir dos quais podem ser projetados ou representados todo um sistema integrado. Ex.: (framework ARIS, ISO, entre outros);
  • Formalismos de modelagem: um formalismo de modelagem é um conjunto de elementos selecionados capaz de representar uma parte da realidade, relativa a um subconjunto do domínio do problema. Um mesmo formalismo pode ser utilizado em diferentes frameworks e um framework de modelagem normalmente é composto por diferentes tipos de formalismos;
  • Abordagens Estruturadas: abordagens que cobrem o desenvolvimento da arquitetura de desenvolvimento de Integração de Empresas, detalhando, passo-a-passo todo o seu desenvolvimento.
Metodologias de Modelagem de Empresa
Os métodos mais amplamente difundidos na área são os seguintes frameworks: ISO, CEN ENV 40003,CIMOSA, IDEFX/SADT, ARIS entre OUTROS.
Referências Básicas
VERNADAT, F.B. (1996). Enterprise Modelling and Integration: Principles and Applications. London: Chapman & Hall.
Referência Bibliográfica Complementar
ARIS – Toolset Methods Manual – version 3.0 IDS PROF. SCHEER, 1995 (Trata-se do Manual deste software que suporta a modelagem segundo a arquitetura ARIS e que faz um interessante resumo sobre este framework. Uma descrição maior pode ser analisada em Scheer, 1993). BRANDIMARTE, P.; CANTAMESSA, M.; (1995). Methodologies for designing CIM systems: a critique. Computers in Industry, v.25, p.281- 293. (t:866) (os autores fazem uma interessante discussão sobre a importância, perspectivas e barreiras para a modelagem de empresas. Apesar de um pouco antigo trata-se ainda de um trabalho de grande valor) MARCA, D.; MCGOWAN, C. L. IDEFO/SADT: business process and enterprisa modelling. San Diego: Ecletic Solutions Corporation, 392p. (Biblioteca Central EESC - USP) (É um trabalho bastante didático sobre IDEF0 e dirigido para a aplicação prática desta metodologia de modelagem, com muitos exemplos. O único ponto fraco é que ele não se aprofunda nos demais níveis) MERTINS, K.; JOCHEM, R.; JÄKEL, F.W. (1997). A tool for object-oriented modelling and analysis of business processes. Computers in Industry, v.33, p.345-356. (t:824). (interessante por mostrar uma ferramenta de modelagem com conceitos de orientação à objetos. Deve despertar maior interesse para especialistas no assunto). RENTES, A. F. Proposta de um metodologia de integração com utilização de conceitos de modelagem de empresas. São Carlos. Tese (Doutorado) - Escola de Engenharia de São Carlos, Universidade de São Paulo. (Disponível na biblioteca da EESC - USP). (Este trabalho é interessante porque o autor inseri a modelagem de empresa como peça fundamental de uma metodologia de integração. Assim pode-se perceber o potencial, importância e forma de aproveitamento da modelagem de empresas num contexto de intervenção prática). ROZENFELD, H. (1996). Reflexões sobre a manufatura integrada por computador (CIM). In: MANUFATURA CLASSE MUNDIAL: MITOS E REALIDADE. São Paulo, 1996. (t:1) (Traz uma importante discussão sobre a importância dos modelos de empresa) USCHOLD, M.; KING, M.; MORALEE, S.; ZORGIOS, Y. (1998). The enterprise ontology. The Knowledge Engineering Review, v.13, n.1, p.31-89. (t:856) (os autores apresentam o resultado de um esforço no sentido de erigir uma ontologia para modelagem de empresas. Deve despertar maior interesse para especialistas e pesquisadores na área de modelagem) VERNADAT, F. B. (1996). Enterprise modelling and integration: principles and applications. London: Chapman & Hall. (Este é um dos mais importantes trabalhos já publicados sobre este assunto. O autor compilou e sistematizou uma ampla gama de conceitos, ferramentas, técnicas e outras informações sobre este assunto. É também uma boa referência para quem deseja começar a estudar este assunto)
Principais Periódicos sobre o Assunto
International Journal of Production Research International Journal of Computer Integrated Manufacturing Systems Computers in industry Concurrent engineering: research and applications Journal of materials processing technology Journal of intelligent manufacturing Journal of Design and Manufacture International journal of Operations & Production Management Computer integrated manufacture systems
Ferramentas de Modelagem
1) ARIS É uma família de ferramentas de modelagem cujo software principal se chama ARIS Toolset. Trata-se de uma das ferramentas de modelagem mais sofisticadas do mercado pois possui uma metabase de dados que assegura a consistência dos dados de diversos modelos representando visões diferentes de uma empresa. Ela tem como princípio o framework de modelagem ARIS. Outro caráter distintivo desta ferramenta é que ela é uma das únicas que foi desenvolvida especificamente para a aplicação em modelagem de empresas. Site Brasil. http://www.ids-scheer.com.br Site Internacional http://www.ids-scheer.com 2) VISIO Uma ferramenta de modelagem extremamente conhecida. Trata-se também de uma família contendo aplicações para as mais diversos usos, compreendendo gráficos de apresentação, desenvolvimento de software e desenho arquitetônico. Tem como seu principal fator de distinção a amigável interface gráfica e a grande biblioteca de modelos e objetos (realmente uma quantidade enorme distribuída entre os produtos desta família). É simples de utilizar e não exige muito em termos de plataforma de software, porém é menos rica em recursos de análise como simulação. Site Internacional http://www.visio.com/ 3) Micrografix Flow Chart É uma ferramenta de modelagem bastante simples e conhecida. Na verdade Flow Chart é o nome dado a um dos produtos deste fabricante, de forma que toda a linha possui produtos destinados a diversos outros tipos de modelagem, além do desenvolvimento de modelos de empresa. É simples, fácil de usar e possui dentro da linha de produtos uma quantidade maior de pacotes facilitando a análise, como por exemplo um produto específico para a simulação de processos de negócio. Site Internacional http://www.micrografx.com/enterprise/graphicssuite/flowcharter/ 4) Intalio 5) Mega 6) Casewise
Sites Relacionados
Warwick University Lista de sites sobre business process http://bprc.warwick.ac.uk/bp-gold.html#SEC1 Business Process Resource Center (Centro de estudos sobre Business Process da Universidade de Warwick) http://bprc.warwick.ac.uk/
Modelo de Referência do Processo de Desenvolvimento de Produto da Fábrica Integrada Modelo http://www.portaldeconhecimentos.org.br/index.php/content/view/full9684
O que é o Modelo de Referência da FIM?
O modelo de referência para o processo de desenvolvimento de produto da Fábrica Integrada Modelo (FIM) é uma representação deste business process desenvolvida pelo Grupo de Engenharia Integrada com base em conceitos de modelagem de empresas. Esta representação é fruto de oito anos de pesquisas e trabalhos de consultoria realizados na área de desenvolvimento de produto; contando também com a contribuição de diversos especialistas que durante esses anos puderam conhecer este modelo e criticá-lo, contribuindo para o seu desenvolvimento. Este modelo de referência é importante por ser uma representação da visão holística do processo de desenvolvimento de produto. Nele são apresentadas as principais dimensões de um processo de negócio (veja as formas de representação do modelo) no maior nível de detalhamento e escopo possíveis. O Grupo Engenharia Integrada procura desenvolver um modelo detalhado e aplicável a maioria dos casos práticos, servindo, assim, de base para as pesquisas e intervenções práticas realizadas pelo Grupo de Engenharia Integrada(veja as aplicações do Modelo de Referência da FIM). Atualmente, além da atualização e aprimoramento do modelo de referência atual,o Grupo de Engenharia Integrada vem realizando um esforço para seu desdobramento em modelos de referência específicos a determinados contextos, ou seja, indústrias e tipos de projeto de desenvolvimento específicos.
Aplicações do Modelo de Referência da FIM
O modelo de referência é um elemento central e que distingüe a atuação em pesquisa e prestação de serviços do Grupo de Engenharia Integrada. Como representação da visão holística ele dá suporte para que as atividades do grupo em qualquer destes campos sejam guiadas conforme esta visão sobre o processo de desenvolvimento de produto. No âmbito da pesquisa ele auxilia na integração dos membros do grupo e dos conhecimentos gerados em áreas específicas. Pode também ser aplicado em intervenções práticas como parâmetro para análise de processos de desenvolvimento de produto existentes. E, mais importante ainda, este modelo é um dos elementos centrais dos cenários de integração sobre desenvolvimento de produto. Estes cenários são aplicados em novas formas de ensino do processo de desenvolvimento de produto e na avaliação de soluções existentes para este processo.
Formas de Representação do Modelo de Referência da FIM
Atualmente este modelo está representado em quatro formatos diferentes. Em todos eles busca-se representar as dimensões principais de um processo de negócio: organização, informação, recursos e atividades :
  • Representação Resumida: é uma breve descrição do modelo na forma de texto e em planilha eletrônica onde constam as 6 fases principais, uma descrição destas etapas maiores ou uma lista das atividades principais realizadas em cada uma delas, conforme pode ser visto no item Descrição do Modelo de Referência desta home page.
  • SADT extendido: trata-se da representação que segue o método SADT (Structured Analysis and Design Technics), incorporando os conceitos que o estendem conforme a proposta de ROZENFELD ( ). Esta representação é composta por três níveis de detalhamento. O primeiro nível, denominado Analógico, dispõe as fases principais do processo numa ordem temporal e assemelha-se à representação das fases da APQP contidas na QS 9000. O segundo nível é o diagrama IDEF0 modificado. Além das atividades e fluxo de informação contém também a especificação dos recursos e organizações necessários a cada atividade, eliminado por outro lado os fluxos de controle existentes. O último nível de detalhamento é um formulário em editor de texto que descreve detalhadamente cada uma das atividades apresentadas no modelo anterior;
  • ARIS Toolset 3.0: é uma representação do modelos segundo o framework de modelagem ARIS e que emprega a ferramenta ARIS Toolset 3.2;
  • Script: é uma história fictícia de um processo de desenvolvimento de produto que representa uma "instância", ou uma possível ocorrência, do modelo de referência. Esta é arepresentação mais concreta e detalhada do modelo. O script é também um dos elementos do cenário de integração construído pelo Grupo de Engenharia Integrada e descreve a história sobre o desenvolvimento de um dos produtos da FIM envolvendo seus personagens.
Descrição Resumida do Modelo de Referência da FIM
O primeiro nível da descrição do Business Process Desenvolvimento de Produto é a visão analógica apresentada na figura abaixo, a mesma que inicia todas as representações do modelo de referência. Em seguida é apresentada uma breve descrição de cada uma das fases Conceber Produto: É a fase inicial do desenvolvimento do produto. Tem início com idéias e informações de mercado tais como pesquisas encomendadas e/ou realizadas pelos dirigentes, observações de concorrentes, necessidades de melhoria, opinião de clientes, etc. As propostas de projetos de novos produtos reveladas a partir destas atividades são avaliadas com a técnica de Análise de Atratividade (baseada em conceitos de análise do valor e que considera fatores Mercadológicos e da Estratégia Competitiva da empresa). Após a discussão e aprovação de uma das propostas, um grupo composto por pessoas da alta gerência e um coordenador de produto definem as diretrizes deste produto: como custo, retorno esperado, data de lançamento, especificação final do produto, etc. Este coordenador acompanha todo o ciclo de vida do produto, sendo, portanto, a “melhor interface” entre a alta administração e a equipe de desenvolvimento. Inicia-se nesta fase a aplicação de conceitos de workgroup computing com o intuito de aumentar a eficácia e eficiência do time de desenvolvimento. No final desta fase prepara-se também um cronograma com os marcos principais do projeto, o qual é baseado no modelo de referência. Inicia-se, assim, a aplicação dos conceitos de gerenciamento de projetos que devem acompanhar todo o desenvolvimento. Conceituar Produto: Consiste em complementar as diretrizes obtidas anteriormente com uma definição detalhada das características técnicas do produto. Esta atividade é desempenhada por um time multifuncional, composto por engenheiros de qualidade, processo, projeto, marketing e outros, liderados pelo coordenador de produto. O trabalho do time é guiado pela filosofia de engenharia simultânea e auxiliado por sistemas de workgroup computing. Utilizando a Casa da Qualidade do QFD (Quality Function Deployment) são desdobradas as necessidades dos clientes em características técnicas a serem satisfeitas pelo produto. Todas as informações sobre o projeto são arquivadas de forma sistemática, garantindo a sua reutilização em fases posteriores com o emprego de sistemas de gerenciamento de dados de engenharia (PDM). Uma vez definidas as características técnicas, são gerados conceitos e suas respectivas estruturas de produto preliminar (BOM). Estas estruturas servião de base para decisões make or buy e uma previsão de custos (esta última podendo utilizar a filosofia de custo ABC). Fornecedores parceiros estratégicos podem então ser chamados à participar do desenvolvimento já nesta fase. Os diferentes conceitos especificados para o produto são avaliados, suas diretrizes detalhadas e validadas e é tomada a decisão, em conjunto com a alta administração (representada por um conjunto de diretores denominado grupo de concepção) de dar-se continuidade ao projeto, investindo ou não mais recursos no detalhamento do conceito considerado mais promissor. Projetar Produto e Processo: nesta fase realiza-se o detalhamento do produto pelo mesmo time multifuncional, acrescido agora de especialistas de áreas específicas. Informações de produtos semelhantes são recuperadas de forma sistemática utilizando ferramentas como Sistemas de Classificação e Tecnologia de Grupo, Estrutura e Identificação de Produtos e PDM. Caso trate-se de um produo modular realiza-se a especificação da família completa de produtos. A partir destas informações, novos desenhos e processos são elaborados em detalhe com apoio de sistemas CAD e CAPP. Suas características são calculadas, verificadas e dimensionadas com o apoio de diversas ferramentas como técnicas de DFMA (Design for Manufacturing and Assembly), protótipo eletrônico e CAE (Computer Aided Engineering). Antes do detalhamento de um componente, toma-se a decisão definitiva de make or buy, agora com previsões de custos mais precisas e realistas em relação às obtidas na fase de conceito. Nesta fase também devem ser tomadas decisões quanto à procedência do item, ou seja, o nome do fornecedor, o volume e o preço, para que surpresas não aconteçam durante a fase de fabricação e busque-se otimizar o fluxo na cadeia de valor onde está inserida a empresa. Para as atividades de dimensionamento mais simples podem ser empregadas ferramentas automáticas. Um exemplo é o desenho parametrizado e as ferramentas de CAM e CAPP. Juntas estas ferramentas podem automatiza totalmente o detalhamento de um componente simples, iniciando pela geração do seu desenho até a composição do código CN. Após o detalhamento existe uma montagem eletrônica do conjunto final, onde a cadeia dimensional é verificada, aperfeiçoando-se as especificações do detalhamento, sem impedir que essas informações já estejam sendo utilizadas por outras pessoas. Paralelamente podem ser iniciadas as construções dos protótipos onde a ferramenta de prototipagem rápida pode ser de grande auxílio. Ela permite que sejam gerados protótipos de maneira rápida e com baixo custo visando diferentes tipos de verificação do projeto, em alguns casos, podendo assumir o papel funcional das peças. Estes protótipos podem ser utilizados também para otimização do projeto (visando sua maior robustez) com o auxílio do método Tauguchi. Um princípio para o trabalho das pessoas nessa fase é a qualidade assegurada nos serviços. Isso significa que as informações produzidas em um estágio já são liberadas para o time dar continuidade aos trabalhos dependentes dessa informação, antes da sua aprovação, garantindo assim um trabalho paralelo. Toda informação é controlada por um sistema PDM (Product Data Management), garantindo a sua integridade. Caso uma informação, por exemplo um desenho, seja reprovada, fica fácil rastrear as atividades dependentes. Além disso o envio de tarefas entre os membros do time acontece através de um gerenciador de workflows, que otimiza o fluxo de informações. A qualquer momento, um dos membros do time pode considerar um item como sendo crítico, isto é, um item que apresenta uma dificuldade técnica, econômica ou de escassez de um recurso que torne seu desenvolvimento incompatível com as metas planejadas. Pode ser um problema de importação, desenvolvimento de dispositivos, entrega de protótipos, falta de capacidade de uma máquina ou equipamento de teste, etc. Nesses casos é convocada uma reunião extraordinária com todos os membros do time, a fim de manter o desenvolvimento do item conforme as necessidades de projeto. Eles são considerados gargalos do desenvolvimento e devem ser acompanhados com maior atenção conforme os conceitos de gerenciamento de projetos. No final da fase de detalhamento acontecem reuniões para analisar os potenciais de falhas do projeto e processo. Conforme a QS 9000, norma que teve seus requisitos considerados na construção do modelo, aplica-se a técnica de FMEA (Failure MOdel and Effect Analysis. Ao final desta fase são desenvolvidos todos os detalhamentos do projeto, ou seja, análise do fluxo de processo , croquis de fabricação, de setup de equipamento, de inspeção, lista de ferramental, procedimentos de qualidade, etc. Homologar Produto: Utilizam-se aqui as premissas e regras da ISO 9000 e QS 9000, definindo-se um programa de testes do produto, um plano de processo do protótipo, plano de controle para o protótipo, os itens a serem comprados e os serviços externos para a sua construção. A seguir são realizadas as atividades de planejamento, fabricação e montagem do protótipo, onde são feitos testes e uma avaliação sobre os resultados obtidos. Aplicam-se aqui as técnicas de projeto de experimentos, montando-se ao final um relatório dos testes realizados. Com base neste relatório e tendo-se em mãos as possíveis falhas levantadas durante o Projetar Produto o FMEA de produto é finalizado e o produto é homologado. Na homologação verifica-se o cumprimento das diretrizes do produto por meio de reuniões de avaliação com as equipes envolvidas no seu desenvolvimento. Homologar Processo: Com o protótipo aprovado, parte-se para a definição de um cronograma interno de implantação do produto na empresa. São detalhados planos de montagem, planos de controle e é verificada a capabilidade dos processos por meio dos índices de capabilidade. Ao final da produção piloto são avaliadas as falhas do processo de fabricação e tomam-se as medidas pertinentes para eliminá-las. Estas falhas são comparadas com aquelas previstas no FMEA de processo e é avaliada a eficácia das ações corretivas derivadas desta análise, gerando novos índices de risco. Ao final deste esforço o processo é homologado em reunião com toda a equipe. Ensinar Empresa: Consiste em diversas atividades com o objetivo de transmitir as informações sobre o produto e seus processos para as demais áreas da empresa e para a avaliação crítica do desenvolvimento visando a melhoria contínua do processo de desenvolvimento de produto. O primeiro deles é um conjunto de esforços tais como: preparação de manuais de manutenção, de aplicação, catálogos para venda, etc. Com esse material realizam-se cursos e palestras para pessoas das áreas de marketing, vendas, assistência técnica, planejamento e fabricação, a fim de divulgar os conceitos e características do novo produto. Sistemas de informação para apoio às outras atividades da empresa, relacionados com o produto, tais como software de apoio a vendas ou assistência técnica, são desenvolvidos nesta fase. Com todas estas atividades realizadas chega-se ao fim do esforço de desenvolvimento. Os principais elementos envolvidos com o processo (Coordenador, diretoria e time de desenvolvimento) podem então se reunir para uma avaliação crítica visando acumular as experiências geradas com este desenvolvimento (segundo o conceito de learning enterprise). É analisado o cumprimento das diretrizes iniciais, identificados pontos críticos, relatados eventos problemáticos, pontos fortes e fracos e, por fim, elabora-se uma lista com potenciais ações de melhoria.
Artigo
ROZENFELD,H Modelo de Referência para o Desenvolvimento Integrado de Produtos. Anais em CD do XVII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇAO / 3RD INTERNATIONAL CONGRESS OF INDUSTRIAL ENGINEERING – Gramado, 1997
Sites Relacionados
Fábrica Integrada Modelo - apresenta o ambiente de manufatura que está sendo desenvolvido dentro do Núcleo de Manufatuda Avançada (NUMA) e suas aplicações. O modelo de referência é um dos elementos fundamentais para a geração deste ambiente.
Método de seleção e análise de software (MSAS) http://www.portaldeconhecimentos.org.br/index.php/content/view/full9429
Introdução
Existem muitas ferramentas, métodos e software que podem ser utilizados como suporte ao gerenciamento do processo de desenvolvimento de produto. A aplicação de ferramentas e métodos são fatores importantes para a melhoria contínua do PDP. Contudo, a seleção destas práticas depende de decisões que estão associadas a duas questões: (1) a adoção ou (2) difusão dessas ferramentas. A adoção está relacionada com a decisão de se usar ou não uma determinada ferramenta. Por outro lado, a difusão está associada ao número de empresas que já tem vem adotando determinada ferramenta. (CHAI, 2006, NIJSSEN & FRAMBACH, 2000). Nijssen and Frambach (2000) concluem que uma empresa pode obter ajuda (por exemplo, de consultorias ou de agências de pesquisa de Mercado) para selecionar uma ferramenta adequada e também para saber como utilizá-la. Assim, embora para grandes empresas seja possível contratar consultorias para avaliar e indicar soluções mais viáveis e ajustadas aos requisites da empresa, esse caminho não é tão simples para as PMEs. Uma vez que em geral elas não dispõem de capital financeiro suficiente para pagar por consultorias externas, mas também têm necessidades por ferramentas que sejam adequadas à sua realidade, ou seja, em termos de custo, requisitos culturais e tecnológicos. Oportunamente, uma grande quantidade de softwares livres e gratuitos podem ser utilizados para auxiliar o PDP das empresas. Assim, as PMEs podem obter vantagens utilizando essas ferramentas, desde que faça a escolha mais adequada. Esse fato reforça a necessidade de um método de apoio para esse processo de decisão.
Definições
O método proposto nesse trabalho está ilustrado na figura 1 e pode ser dividido e 4 fases. Figura 1: Método de seleção e análise de software A primeira fase desse método tem como finalidade auxiliar na elaboração da lista de requisitos da empresa. Esses requisitos específicos da empresa são obtidos por meio de entrevistas com as pessoas que estão relacionadas com as atividades para as quais está se buscando apoio (ou áreas de conhecimento vinculadas ao PDP). Contudo, uma PME pode não ser capaz de definir adequadamente todos esses requisitos. Como apoio à essa fase, o MSAS propõe uma consulta a bases de dados que contenham exemplos de consolidação de requisitos tais como a análise das melhores práticas de modelos de referência, pois elas podem indicar alguns requisitos. O conhecimento empírico é outra fonte de consulta, tais como: jornais especializados, web sites e relatos de casos em revistas. Essa investigação auxilia as empresas em preparar uma lista inicial de requisitos. Os requisitos dessa fase são verificados no Gate 1, cujo objetivo é avaliar se a quantidade e a qualidade dos requisitos definidos são suficientes para se passar para a próxima fase. Se não, é necessário retornar ao processo de especificação dos requisitos consultando de modo complementar as diversas fontes de dados. O objetivo da segunda fase é produzir critérios que serão utilizados na avaliação do software. Para isso, duas atividades foram consideradas: a primeira foi analisar o PDP da empresa em busca de outros requisitos específicos, os quais são fundamentais para que a seleção do software seja eficiente e eficaz (por exemplo, linguagem de programação, base de dados, sistema operacional, etc.). A outra atividade é a de definição de prioridades para os requisitos. Essa atividade deve ser conduzida a partir de entrevistas com o maior número possível de colaboradores da empresa. A partir da entrevista é possível definir o grau de importância de cada requisito para a empresa (vinculados a diversas áreas e com nível operacional diferentes, por exemplo: um gerente de vendas, um desenvolvedor, um gerente de marketing, etc.) e ainda proporciona a oportunidade das pessoas participarem do processo de seleção do software, vinculando a esse o seu compromisso, já que serão os futuros usuários do software. Os graus de importância (GI) variam de 0 (nenhum importância), 0,1 (pouco importante), 0,6 (importância média) e 1 (importante). Essa atividade é muito importante na aplicação do método para garantir o apoio dos colaboradores na fase de implantação do software selecionado. Esse procedimento customiza o processo de seleção de software para as reais necessidades da empresa. O resultado dessa fase, que é verificado no Gate 2, é uma lista de critérios, ponderados pelo grau de importância, que serão a base para a busca e avaliação dos softwares. A fase 3 tem foco na busca sistematizada em bases de dados na web para encontrar os softwares que atendam aos critérios especificados (veja figura 1). Assim, nessa fase da pesquisa é importante que sejam vinculadas ao processo de busca palavras chaves bem ajustadas ao software. Nessa busca, muitos softwares são excluídos por não atenderem aos requisitos já definidos. Esses dados devem ser registrados de modo organizado em uma planilha, descrevendo tanto quanto possível os requisitos que estão presentes e aqueles que não estão e principalmente o motivo da eliminação do software da lista final. O principal resultado dessa fase é uma lista consistente de software que serão instalados para uma avaliação mais detalhada. O Gate 3 é uma verificação para garantir a consistência da lista, que servirá como base para a seleção final do software. Se por acaso algum software importante (muito difundido ou adotado) ficar fora dessa lista, todo o trabalho de avaliação não terá a eficiência requerida. A meta da fase 4 é avaliar em profundidade a lista de software definida na fase anterior. Nessa fase, podem-se consultar relatórios disponíveis na web sobre comparações de software de modo que possam ser utilizados como informações adicionais. Essa etapa pode requerer o conhecimento de pessoal técnico para a instalação dos software e configuração do sistema. Esse envolvimento garante que o processo de avaliação será conduzido de modo satisfatório. Todos os critérios devem ser considerados na avaliação e notas (N) devem ser atribuídas para cada um deles, considerando as seguintes possibilidades: 0 não atende ao critério, 3 atende parcialmente e 5 atende completamente. Assim que a avaliação for concluída, a comparação dos softwares pode ser iniciada. O grau de importância dado aos critérios, como definido na fase 2, serão utilizados para ponderar a importância do critério na nota final de cada software de acordo com a seguinte expressão: Nota final = Soma (N*GI)/nr nr = quantidade total de critérios N = Nota dada ao critério GI = Grau de importância Finalmente uma lista com a classificação dos softwares é definida e serve como referência para a decisão de qual software deve ser implantado. Essa decisão é validada no gate 4 de modo a verificar se estão de acordo com a estratégia e política da empresa. Resultados importantes Como conseqüência, a lista de software encontrada foi mais consistente em relação à quantidade e a variedade. Um segundo ponto relevante foi que a análise das melhores práticas elaborada na lista de requisitos, pela própria empresa, contribuiu para melhorar o PDP porque durante a implantação do software algumas melhores práticas podem ser incorporadas na nova rotina, conseqüentemente melhorando o processo. Outro resultado do método proposto é que ele customiza o processo de seleção do software pelo usuário. O grau de importância de cada critério foi baseado no nível de maturidade do PDP. Assim, esta customização racionalizou o processo de tomada de decisão. As empresas minimizaram o risco de selecionar um software que parecesse ser a melhor escolha pelas suas muitas funcionalidades, mas que poderia ser inadequado para a capacidade técnica e de recursos humanos da empresa. Adicionalmente, isso proporcionou mais chances de sucesso na implantação pela redução de possíveis barreiras (por exemplo, rotinas inadequadas, deficiência de informação e incapacidade técnica). Outro benefício percebido foi que o método agiu como um guia para também promover a melhoria do PDP, proporcionando aos colaboradores o senso de confiança e otimismo com o resultado da seleção. Uma das razões para essa atitude positiva por parte dos colaboradores foram: eles compreenderam as necessidades para a implantação de uma nova ferramenta; participaram na definição da importância dos critérios e certamente essa ponderação foi essencial para a seleção final do software; garantiu o compromisso desses colaboradores para a melhoria do PDP com o uso das novas ferramentas. O uso de software livres em pequenas empresas de base tecnológica tem provado ser uma solução prática quando se ajustam às suas necessidades. Podem ser customizados para melhor atender aos requisitos da empresa, já que disponibilizam o código fonte. (1) A aplicação de software de CRM para PDP sob encomenda é importante, pois os primeiros requisitos e especificações aparecem durante a fase de venda; (2) Os sistemas de PM mais conhecidos são de marcas proprietárias. Eles têm características suficientes para auxiliar a maioria dos projetos de gestão do ciclo de vida. Contudo, o alto custo para aquisição de licenças, a dificuldade para a customização, treinamentos e necessidade de apoio técnico dificultam sua difusão. Por outro lado, software de gestão de projetos gratuitos mostraram-se maduros suficientes para atender as necessidades das pequenas e médias empresas; (3) Os software de gestão de conteúdo (CM) facilitam a visualização do PDP na internet e também podem ser usados como um sistema de gerenciamento de documentos; (4) Os modelos de referência são importantes para orientar os projetos de melhoria do PDP e garantir uma linguagem comum entre os membros da rede; e (5) A interação entre os colaboradores da empresa durante o processo de seleção dos software contribuiu para que a fase de implantação corresse menos riscos. O método proposto pode ser aplicado em conjunto com uma sistemática de métodos de gestão de mudanças relacionados com uma ampla abordagem de BPM e a implantação de uma solução de PDP integrada a uma arquitetura de PLM.
Publicações importantes e referências citadas na descrição
COSTA, J. M. H, AMARAL, C.S.T, ROZENFELD, H. Method of analyzing and selecting software to support npd process management: experiences and lessons learned. 15 International Product Development Management Conference, IPDMC, Hamburg, Germany, 29 de junho e 1 julho de 2008.
Organização para Desenvolvimento de Produtos http://www.portaldeconhecimentos.org.br/index.php/content/view/full9682
Conceitos Básicos
Fontes : CLAUSING, D.P. ;VALENTI, M. (vide informações adicionais) Um estudo recente, elaborado pela ASME (American Society of Mechanical Engineers) e publicado pela National Science Foundation, identificou as principais filosofias, tecnologias e ferramentas utilizadas pelas empresas bem sucedidas em seu processo de desenvolvimento de produtos (Valenti, 1996). Como parte deste estudo foram levantadas, junto a professores universitários e profissionais de empresas, as habilidades que as pessoas precisam adquirir para utilizar de forma consistente estas filosofias, tecnologias e ferramentas. Observou-se uma grande ênfase dada ao trabalho em equipe, à comunicação, ao pensamento criativo e à utilização de filosofias que visam uma sinergia entre a área de projeto e de manufatura. Estes dados refletem a preocupação atual em se modificar o perfil das pessoas que trabalham de forma convencional, como no caso específico de desenvolvimento de produtos, exercendo atividades de forma seqüencial e não tendo uma visão do todo. Em meados deste século, o processo de desenvolvimento de produtos era realizado de forma seqüencial, ou seja, cada área funcional da empresa, após executar suas atividades de desenvolvimento, transferia a documentação acabada para o departamento seguinte que então dava início a execução de outras atividades. Os profissionais envolvidos nesta abordagem de desenvolvimento tradicional, eram especialistas, que conheciam muito bem o escopo técnico dos produtos mas que não tinham visão do todo em relação ao processo de desenvolvimento. Essa abordagem era possível uma vez que esses produtos não possuíam grande sofisticação tecnológica. Com o avanço da tecnologia e crescente complexidade dos produtos, essa abordagem tornou-se ineficiente. Além disto, as empresas começaram a apresentar diversos problemas e limitações, tais como: dificuldade de projetar com simplicidade, falta de atenção com a qualidade do produto, tempos excessivos de desenvolvimento, inexistência de integração entre as fases de projeto e produção, falta de foco no cliente, pouco envolvimento com fornecedores no desenvolvimento de produtos e falhas no processo de melhoria contínua. Atualmente, com a filosofia de Engenharia Simultânea, as atividades do processo de desenvolvimento passaram a ser efetuadas de forma concorrente. Além disto, as decisões envolvidas com este processo passaram a levar em consideração os requisitos e as experiências das diversas áreas envolvidas. Quanto aos profissionais, vários autores defendem que as atividades relacionadas com o desenvolvimento de produtos devem ser realizadas por um time multifuncional, entitulado por PDT (Product Development Team). Segundo Clausing (1994), para o sucesso da aplicação da Engenharia Simultânea, os membros deste time não devem ser pessoas extremamente especializadas, mas que combinem bem escopo e profundidade de conhecimento (veja figura abaixo). Quando necessário, o PDT deve consultar pessoas especializadas que, apesar de um perfil mais técnico, também devem ser comunicativas e ter conhecimento da integração de seu trabalho com outras áreas. Para exemplificar esta situação, pode-se supor que alguns dos integrantes do PDT tenham o seguinte perfil: engenheiros projetistas que possuem conhecimentos de processo de fabricação; engenheiros processistas que conhecem bem a "voz do cliente" e as funcionalidades do produto. Ao longo do desenvolvimento do produto, caso estes profissionais tenham a necessidade da aplicação de uma técnica mais específica, como a Análise por Elementos Finitos, eles devem recorrer a um especialista que apresente uma visão geral do projeto e que seja comunicativo. Perfil dos profissionais em desenvolvimento de produtos (Clausing, 1994).
Artigos
CLAUSING, D. P. (1994). Total quality development: a step-by-step guide to world class concurrent engineering. The American Society of Mechanical Engineers. New York. ( t: 322 ) (Disponível na biblioteca da EESC - USP) VALENTI, M. (1996). Teaching tomorrow’s engineers. Mechanical Engineering, p.64-69, July. ( t: 32 )
PDM (Product Data Management) http://www.portaldeconhecimentos.org.br/index.php/content/view/full9513
Situação Atual
Devido à pressão da concorrência, a melhoria do processo do desenvolvimento de produto com a adoção da engenharia simultânea vem sendo um dos maiores desafios entrentados pelas empresas. Isto significa lançar produtos no mercado em uma maior frequência, em um menor tempo (time-to-market) e com a qualidade exigida pelos clientes. A fim de atingir esses requisitos, muitas empresas adotam métodos , técnicas da engenharia simultânea para tentar melhorar sua engenharia, assim como sistemas de informação. Porém na maioria das vezes esbarram na dificuldade de implantação, englobando a dificuldade de se gerenciar as informações criadas e as atividades a serem realizadas. Apesar do grande desenvolvimento da tecnologia da informação a maioria das indústrias de manufatura controla as informações de engenharia na forma de papel. Segundo AMR, cerca de 80% das indústrias ainda usam um sistema manual, baseado em papel, para controlar as modificações de engenharia.Os problemas decorrentes desta situação são muitos e afetam diretamente o desempenho do processo de desenvolvimento de produtos. Cópias de desenhos desatualizadas, circulação lenta de documentos, excesso de papel, alto índice de retrabalho, dificuldade de se obter informações dos produtos são problemas comuns na maior parte destas empresas. Os sistemas de gerenciamento de dados do produto (PDM) se destacaram no meio dos anos 90 como uma das principais ferramentas para a concretização da engenharia simultânea, gerenciando as informações e atividades de desenvolvimento de produto.
Conceito de PDM
Product Data Management (PDM) é uma tecnologia de software que visa gerenciar todas as informações e processos relativos ao ciclo de vida de um produto. Entendendo-se ciclo de vida como todo o período compreendido desde a concepção de um produto até sua obsolescência, passando pelas etapas de projeto e produção. A tecnologia PDM propõe-se a explorar ao máximo os benefícios da engenharia simultânea, controlando a informação e distribuindo sistematicamente para as pessoas que a necessitam. Várias nomenclaturas como, PIM (Product Information Management), TDM (Technical Document Management), TIM (Technical Information Management) e EDM (Electronic Document Management) são usadas com significados semelhantes. Porém todos estes sistemas podem ser classificados dentro de dois grupos distintos: PDM e EDM. Sistemas EDM (Electronic Document Management) são todos aqueles focados no gerenciamento de documentos podendo ou não estar relacionados à engenharia. Já os sistemas PDM são voltados para o gerenciamento do produto e de suas partes, possuindo assim funcionalidades especiais como controle da estrutura de produto e controle das modificações de engenharia.
Funcionalidades
As funções de um sistema PDM podem ser divididas e classificadas de várias formas. Segundo PDMIC, as funcionalidades de um sistema PDM podem ser divididas basicamente em gerenciamento de dados do produto e gerenciamento do processo. O gerenciamento de dados do produto abrange o controle da estrutura de produto, classificação de componentes e classificação de documentos. O gerenciamento do processo inclui todas as funcionalidade relativas ao fluxo de trabalho, tais como o processo de aprovação de um produto e de modificação de engenharia. Segundo GASCOIGNE as funções de um sistema PDM podem ser divididas em funções de usuário e funções complementares, como descrito abaixo:
Funções do usuário:
  • Gerenciamento do ciclo de projeto: controla a criação e aprovação de documentos e partes do produto, a circulação (por meio de workflow), segurança e o acesso aos dados, relacionamento entre os dados, check-in e check-out;
  • Alterações de engenharia: sistematização do processo de modificações de engenharia (ECM), controle de versões e revisões;
  • Estrutura de produto: controla a lista de materiais (BOM), estrutura de partes e de documentos, gerenciamento da configuração do produto;
  • Classificação: sistema de identificação e classificação de componentes e ferramentas de buscas rápidas e recuperação de informações;
  • Gerenciamento de projetos: funções de planejamento e controle de projetos, controle de prazos e alocação de recursos (vide gerenciamento de projetos).
Funções complementares:
  • Comunicação: viabiliza a comunicação e notificação entre os usuários, e mantém interface com o sistema de e-mail;
  • Transferência de dados: mecanismos de troca de dados entre usuários do sistema, e entre diferentes aplicativos;
  • Visualização: mecanismos de visualização rápida de imagens e redlines (anotações eletrônicas) sem a necessidade de executar o aplicativo de origem;
  • Administração: configuração e customização, controle de usuários, administração do sistema.
Estrutura de um Sistema PDM
Existe uma grande variedade de sistemas PDM disponíveis no mercado. Eles podem se diferenciar em vários aspectos tais como domínio de aplicação, arquitetura do sistema, abrangência de funcionalidades, preço, etc.. Porém, a maior parte utiliza os mesmos princípios para gerenciar as informações. A figura abaixo mostra esquematicamente a estrutura de um sistema PDM, seguida pela descrição de seus principais elementos.
  • Vault (cofre): o vault é o local onde os arquivos gerenciados ficam armazenadas. É a parte do sistema que garante a segurança das informações e o controle de acesso dos usuários;
  • Metadados: além do vault o sistema possui uma base de dados com metadados (informação sobre informação). Estes dados são informações sobre os arquivos, que permitem que estes sejam gerenciados. Alguns exemplos de metadados são: descrição do arquivo, autor, part number, data de criação, etc..
  • Integração: para obter as informações eficientemente á necessário que o sistema PDM esteja integrado com os aplicativos que geram as informações. Atualmente a integração com os sistemas CAD se encontra mais evoluída nos sistemas comerciais, mas existe a preocupação em se desenvolver integração com outros sistemas como MRP, ERP, CAPP, etc..
  • Interface: a interface dos sistemas comerciais são geralmente gráficas e permite que o usuário acesse as informações disponíveis rapidamente, na forma de imagens, tabelas e gráficos.
Benefícios
O maior problema que envolve essa tecnologia, impedindo sua rápida expansão, é a dificuldade do processo de implantação dos sistemas PDM. Geralmente estes processos são lentos, caros e exigem uma significativa adaptação técnica e cultural na empresa. Entretanto, muitos casos de sucesso estão mostrando que os benefícios de um sistema em funcionamento justificam sua utilização. O principal resultado obtido é a redução de time-to-market, ou seja, tempo de lançamento do produto no mercado, através da eliminação de atividades improdutivas e da organização das informações do produto. Além disso o sistema contribui para a melhoria da qualidade do produto e para a redução do custo do produto e do seu processo de desenvolvimento.
Artigos
GASCOIGNE, B. (1995) PDM: The essential technology for concurrent engineering. World Class Manufacture. v. 2, n. 1, p. 38-42. (t:200). SWANTON, B. (1997). Are PDM/EDM systems really controlling product data? The Report on Manufacturing; AMR 1997. (t:342)
Teses
PIKOSZ, P. (1997); Product Data Management in the Product Development Process; Machine and Vehicle Design; Chalmers University of Technology, Sweden OMOKAWA, R.(1999); Utilização de sistemas PDM em ambientes de engenharia simultânea: O caso de uma implantação em uma montadora de veículos pesados.; USP,São Carlos.
Softwares
Altris Software, Inc. (1999). http://www.altris.com/ Site da empresa Altris, com informações dos produtos e de casos de implantação. Cyco Group http://www.cyco.nl/ DocuShare http://docushare.xerox.com/ Metaphase http://www.metaphasetech.com/ Entrada Sofwares http://www.entradasoftware.com/ NovaSoft Systems, Inc. Home Page http://www.NOVASOFT.com/ Sherpa http://www.sherpa.com/ Smart Solutions http://www.smarteam.com/ Eventos KALTHOFF International (1999). http://www.kalthoff.com/ Site propaganda da Conferência Kalthoff Internacional. Sites Relacionados CAENet (1999). http://www.penton.com/cae/ Site trata Computer Aided Engineering, abrangendo CAD, CAM , CAE e PDM. Contém informações básicas e artigos. CIMDATA (1999). http://cimdata.com Site da empresa de consultoria CIMData que pesquisa o mercado de CAD e PDM. Contém notícias e artigos. John Stark Associates (1999). http://www.johnstark.com/ Site da consultoria John Stark especializada em desenvolvimento de produtos. Contém bastante conteúdo sobre desenvolvimento de produtos e sistemas PDM, incluindo links e bibliografia. PDM Information Center (1999). http://www.pdmic.com/ Site específico sobre PDM. Contém informações básicas, artigos e uma lista com as principais empresas que desenvolvem e implementam sistemas.
Pesquisa de mercado http://www.portaldeconhecimentos.org.br/index.php/content/view/full10581
Introdução
A pesquisa de marketing é a função que integra o consumidor, o cliente e o público ao profissional de marketing por meio de informação - infomração usada para identificar e definir as oportunidades e os problemas de marketing, gerar, aperfeiçoar e avaliar as ações de marketing, monitorar o desempenho de marketing e facilitar o entendimento do marketing e facilitar o entendimento do marketing como um processo. A pesquisa de marketing especifica as informações necessárias para o atingimento desses aspectos, define os métodos para a coleta das informações, gerencias e implementa o processo de coleta, analisa e comunica as respostas e suas implicações." Definição oficial de pesquisa de marketing - American Marketing Association. Essa definição ressalta o papel da pesquisa de marketing como um auxílio ao processo de tomada de decisão. Um aspecto importante é a inclusão da especificação e interpretação da informação necessária. Freqüentemente a pesquisa de marketing é vista apenas como o processo de coleta e análise de dados para o uso de outras pessoas. A empresas podem obter e manter uma vantagem competitiva pelo uso criativo das informações do mercado. Assim, a pesquisa de marketing é definida como a entrada de informação para a tomada de decisão e não simplesmente a avaliação de decisões que já forma tomadas. Apenas a pesquisa de marketing, no entanto, não é garantia de sucesso; o uso inteligente da pesquisa é que é o fator chave para as conquistas negociais. Uma maior competitividade depende mais da forma como as informações são usadas do que das pessoas que possuem ou não as informações. No Processo de Desenvolvimento de Produtos, a Pesquisa de Marketing tem participação fundamental no sucesso do lançamento e na melhoria de produtos existentes. É fundamental que as organizações mantenham foco no cliente para o planejamento da qualidade. As três áreas necessárias para o planejamento da qualidade são:
  • Medir a satisfação atual do cliente;
  • Medir as necessidades do cliente na melhoria e no desenvolvimento de produtos;
  • Medir a fidelidade e retenção do cliente;
  • Medir a satisfação do cliente: medir a qualidade em atributos específicos que os clientes:
    • Características de valor para o cliente;
    • Características que representem benefícios;
    • Características superiores à produto similares.
Etapas de uma Pesquisa de Marketing
1. Reconhecimento do Problema de Pesquisa 2. Planejamento da Pesquisa 3. Execução da Pesquisa 4. Comunicação dos Resultados
Alternativas de pesquisa de Marketing:
1. Pesquisa de Produto 2. Testar conceito 3. Determinar desenho ótimo do produto 4. Testes de embalagem 5. Modificações no produto 6. Posicionamento e Reposicionamento da marca 7. Teste de marketing 8. Pesquisa de satisfação 9. Pesquisa de importância 10. Pesquisa de fidelização
Participação de pesquisa de Marketing no PDP
Planejamento EstratégicoProduto: A oportunidade é atrativa e adequada à empresa? • Pesquisa de mercado • Análise da concorrência • Ambiente de negócio Projeto Informacional: Quais os requisitos do produto que atendem a oportunidade? • Pesquisa de mercado • Análise da concorrência • Ambiente de negócio ProjetoConceitual: A concepção de produto é competitivo e atende às expectativas do mercado? • Teste de conceito • Escolha de alternativas de conceito Projeto Detalhado Preparação Produção: O protótipo atende às exigências técnicas e do cliente? • Testes de embalagem • Teste de conceito de protótipo • Análise de desempenho Técnico Lançamento Produto: O mercado demonstra aceitação pelo produto? • Testes de marketing • Testes de campo
Para o planejamento do processo de pesquisa devem ser realizadas as seguintes atividades
1. Identificação do cliente ou nicho de mercado 2. Construção do briefing de pesquisa 3. Planejar a Pesquisa de Marketing 4. Organização da proposta de pesquisa 5. Organização dos instrumentos de pesquisa 6. Essas etapas serão apresentadas e discutidas na seqüência deste capítulo.
Construção Instrumento de coleta de dados
Recomenda-se que um instrumento de coleta de dados para obtenção da demanda do cliente seja constituído das seguintes etapas: Etapa 1: Organização da fase qualitativa (ou pesquisa preliminar); Etapa 2: Elaboração da árvore de qualidade demandada dos resultados da fase qualitativa; Etapa 3: Elaboração do questionário fechado; Etapa 4: Atribuição dos pesos aos itens dos requisitos do cliente
Referências e Links
Nas referências e links abaixo você pode obter informações adicionais sobre Pesquisa de Marketing. 1. AAKER, D. A , KUMAR, V. DAY, G. S. Marketing Research, Sixth edition, Jonh Wiley & Sons. New York, 1998. 2. CHURCHILL, G. A. Marketing: Criando Valor para os clientes. Editora Saraiva 2 ed. 2000. 3. BOYD, H. W., WESTFALL, R. Pesquisa mercadológica. Rio de Janeiro: Fundação Getúlio Vargas, 1973. 788 p. 4. KOTLER, P. Administração de Marketing: análise, planejamento e controle. São Paulo: Atlas, 1981. 384 p. FMG: 1996 - viii, 187p. 5. MATTAR, F. N. Pesquisa de Marketing - metodologia, planejamento, execução e análise. São Paulo: Atlas, 1993 - VI, VII. 6. MALHOTRA, Naresh. Pesquisa de marketing: Uma orientação Aplicada. 3 edição Ed. Bookman. 2001. 7. PLATOON, J.; BARCLAY, I. New product development from past research to future applications. Industrial Marketing Management, New York, NY, v. 27, n. 3, p.197-212, may 1998. O site do IBOPE contém exemplos de pesquisas. Acesse o link http://www.numa.sc.usp.br/saate/index.php/saate/Aplicar-a-Técnica/Pesquisa-de-mercado e veja mais detalhes da pesquisa de mercado .
Referências para Software
É um sistema on-line para a realização de Surveys. http://www.surveymonkey.com/home.asp
Material para Download
Descreve um breve e genérico roteiro para e elaboração de um questionário. Com certeza o documento sugere algumas diretrizes importantes, já que esse processo requer maior conhecimento do objetivo da pesquisa.
Planejamento de Experimentos (DOE) http://www.portaldeconhecimentos.org.br/index.php/content/view/full9417
Introdução
Dentro da indústria, em especial no desenvolvimento de produto, muitas vezes é necessário obter informações sobre produtos e processos empiricamente. Neste momento o trabalho das pessoas envolvidas com o problema assemelha-se ao de pesquisadores ou cientistas que precisam projetar experimentos, coletar dados e analisá-los. Experimentos são empregados para resolver problemas de fabricação, decidir entre diferentes processos de manufatura, diferentes conceitos de produto, entender a influência de determinados fatores, etc... Além disso esta tarefa torna-se cada vez mais importante na medida que se intensifica a base tecnológica dos produtos e as exigências governamentais e de clientes aumentando a necessidade de emprego de experimentos durante todas as etapas do ciclo de vida do produto. O Planejamento de Experimentos (em inglês Design of Experiments, DOE) é uma técnica utilizada para se planejar experimentos, ou seja, para definir quais dados, em que quantidade e em que condições devem ser coletados durante um determinado experimento, buscando, basicamente, satisfazer dois grandes objetivos: a maior precisão estatística possível na resposta e o menor custo. É, portanto, uma técnica de extrema importância para a indústria pois seu emprego permite resultados mais confiáveis economizando dinheiro e tempo, parâmetros fundamentais em tempos de concorrência acirrada. A sua aplicação no desenvolvimento de novos produtos é muito importante, onde uma maior qualidade dos resultados dos testes pode levar a um projeto com desempenho superior seja em termos de suas características funcionais como também sua robustez. No entanto, deve-se ficar claro que esta ferramenta não substitui o conhecimento técnico do especialista da empresa sobre o assunto e nem mesmo trata-se de uma “receita de bolo” de como realizar um planejamento. O domínio do problema é de fundamental importância. O conhecimento do especialista sobre o problema conjugado com a técnica (em casos especiais somando-se ainda o auxílio de especialistas em planejamentos de experimentos) é que irá permitir bons planejamentos de experimentos, ou seja, planejamentos mais rápidos (menos pontos), de menor custo e que possibilitem aos seus idealizadores responderem, baseado em inferência estatística, a resposta a seus problemas. Apesar de novas, as principais técnicas de planejamento de experimentos já existiam e potencialmente poderiam estar sendo sistematicamente aplicadas na indústria desde muitos anos. Porém, a grande maioria destas técnicas requer uma quantidade exaustiva de cálculos tornando fundamental o emprego dos recursos de informática. Um fator que tem impulsionado a aplicação industrial do planejamento de experimentos são as ferramentas computacionais de análise estatística e soluções corporativas que cada vez mais facilitam a realização das análises e manutenção e gerenciamento de dados. Neste sentido a tendência é que tais técnicas tornem-se cada vez mais próximas de aplicações práticas e, portanto, cada vez mais utilizadas. É preciso estar claro também que, em estatística, Planejamento de Experimentos designa toda uma área de estudos que desenvolve técnicas de planejamento e análise de experimentos. Há atualmente todo um arsenal de técnicas, com vários níveis de sofisticação e uma quantidade não menor de livros sobre o assunto. Nesta página são listados os tipos mais conhecidas e de aplicação mais freqüente na indústria.
Glossário
  • Fatores ou Tratamentos: são as variáveis de controle ou entrada.
  • Níveis: correspondem às faixas de valores das variáveis de controle
  • Variável resposta: parâmetro de saída, resultante de uma variação nas variáveis de entrada.
  • Aleatorização: é a prática de realizar a escolha das corridas (ou pontos experimentais) por meio de um processo aleatório (tal como dados ou sorteio). Esta prática simples em muitos casos garante as condições de identidade e independência dos dados coletados e evita erros sistemáticos.
  • Blocos: são agrupamentos de dados para eliminar fontes de variabilidade que não são de interesse do expectador;
veja também um glossário com os principais termos sobre estatística em http://www.animatedsoftware.com/statglos/statglos.htm
Tipos de Planejamento
  • Tratamento em pares;
  • Tratamento em blocos;
  • Quadrado Latino;
  • Quadrado Greco-Latino;
  • Quadrado Hiper-Greco-Latino ;
  • Experimentos Fatoriais ;
Etapas para o desenvolvimento de um Planejamento de Experimentos
Coleman & Montgomery (1993) propõem as seguintes etapas para o desenvolvimento de um Planejamento de Experimentos na Indústria:
  • Caracterização do problema
  • Escolha dos fatores de influência e níveis
  • Seleção das variáveis de resposta
  • Determinação de um modelo de planejamento de experimento
  • Condução do experimento
  • Análise dos dados
  • Conclusões e recomendações
Um experimento planejado é um teste, ou série de testes, no qual são feitas mudanças propositais nas variáveis de entrada de um processo, de modo a podermos observar e identificar mudanças correspondentes na resposta. O processo pode ser visualizado como uma combinação de máquinas, métodos e pessoas, que transforma um material de entrada em um produto. Este produto de pode ter uma ou mais características de qualidade observáveis. Algumas das variáveis do processo são controláveis, enquanto outras são não controláveis. Algumas vezes, esses fatores não controláveis são chamados fatores ruído. Todas essas características devem ser analisadas para o planejamento do experimento, incluindo ainda a especificação do objetivo do estudo.
Objetivo
Os planejamentos de experimentos podem ser usados tanto no desenvolvimento do processo quanto na solução de problemas do processo, para melhorar o seu desempenho ou obter um processo que seja robusto ou não-sensível a fontes externas de variabilidade. Os métodos de planejamento de experimentos podem, também ser úteis no estabelecimento do controle estatístico de um processo. Por exemplo, suponha que um gráfico de controle indique que o processo está fora de controle, e que o processo tenha várias variáveis de entrada controláveis. A menos que saibamos quais variáveis de entrada são as importantes, poderá ser muito difícil trazer o processo de volta ao controle. Os métodos de planejamento experimental podem ser usados para identificar essas variáveis influentes do processo. O planejamento de experimentos é uma ferramenta de engenharia importante para melhorar um processo de fabricação, mas tem também extensiva aplicação no desenvolvimento de novos processos. A aplicação dessas técnicas bem cedo no desenvolvimento do processo pode resultar em: 1. Produção melhorada 2. Variabilidade reduzida e conformidade mais próxima da nominal; 3. Tempo de desenvolvimento reduzido 4. Custos totais reduzidos. No planejamento de novos processos os benefícios são: 1. Avaliação e comparação de configurações de planejamento básicas; 2. avaliação de materiais alternativos; 3. Determinação dos parâmetros-chave do planejamento do produto que têm impacto sobre o desempenho.
Procedimento Geral para Aplicação
1 Reconhecimento e relato do problema
Na prática, geralmente é difícil perceber que existe um problema que exige experimentos planejados formais, de modo que pode não ser fácil obter-se um relato do problema claro, preciso e aceito por todos. No entanto é absolutamente essencial desenvolver completamente todas as idéias sobre o problema e sobre os objetivos específicos do experimento. Usualmente é importante solicitar entradas de todas as partes envolvidas com engenharia, qualidade, marketing, cliente, gerência e operadores (que em geral, têm muito discernimento que costuma ser ignorado). Um relato claro do problema e dos objetivos do experimento costuma contribuir substancialmente para uma melhor compreensão do processo e para uma eventual solução do problema.
2 Definir objetivos do experimento
A partir de uma boa definição do problema é mais natural a elaboração do objetivo do experimento. Esse objetivo deve ser não tendencioso, específico, mensurável e de resultado prático.
3 Escolha da variável-resposta
Na seleção da variável-resposta, o experimentador deve ter certeza de que aquela variável realmente fornece informação útil sobre o processo em estudo. Muitas vezes, a média ou o desvio padrão (ou ambos) da característica medida será a variável-resposta. Respostas múltiplas não são raras. A capacidade do medidor é, também, um fator importante. Se a capacidade do medidor é baixa, então apenas efeitos grandes de fatores serão detectados pelo experimento, ou será necessária replicação adicional. De onde vem o embasamento para seleção das variáveis respostas e controle, ou seja: de teoria, de especialistas/experiência, experimentos anteriores. Onde estes experimentos se ajustam dentro do estudo do processo ou sistema?
4 Listar para cada variável resposta
1. Listar para cada variável resposta o nível normal em que rodará no processo e a distribuição ou amplitude de operação norma, a precisão ou amplitude aos quais ela pode ser medida e como.
5. Listar para cada variável controle
Listar para cada variável controle o nível normal em que rodará no processo e a distribuição ou amplitude de operação normal, a precisão ou amplitude a qual ela pode ser agrupada (para o experimento, não somente em operação na fábrica) e a precisão em que pode ser medida. Avaliar a finalidade da colocação da variável controle e o efeito de previsão (no mínimo qualitativo) que o cenário terá em cada variável resposta.
6 Escolha dos fatores e dos níveis
A pessoa que conduz o experimento deve escolher os fatores que devem variar, os intervalos sobre os quais esses fatores variarão e os níveis específicos nos quais cada rodada será feita. Exige-se conhecimento do processo para fazer isso. Esse conhecimento é em geral, uma combinação de experiência prática e conhecimento teórico. É importante investigar todos os fatores que possam ser importantes e evitar ser excessivamente influenciado pela experiência passada, particularmente nos estágios inicias do experimento ou quando o processo não está ainda muito amadurecido. Quando o objetivo é a varredura dos fatores ou caracterização do processo, é em geral, melhor manter baixo o número de níveis de fatores. (em geral, são usados dois níveis). Os passos dois e três são realizados simultaneamente, ou o passo 3 pode ser feito antes, em algumas aplicações.
7 Listar e rotular
Listar e rotular interações conhecidas ou supostas
8 Listar restrições
Listar restrições no experimento, como a facilidade de alterar a variável controle, métodos de aquisição de dados, materiais, duração, número de corridas, tipo de experimento, unidade (necessidade de um planejamento spli-plot), regiões experimentais irrelevantes ou não viável, limitação para aleatorização, ordem das rodadas, custo de mudança no cenário da variável controle, etc.
9 Dar preferência
Dar preferência aos planejamentos em andamento, se não existir, incluir blocos e aleatorização
10 Escolha do planejamento experimental
Se os seis primeiros passos forem feitos corretamente, este passo será relativamente fácil. A escolha do planejamento envolve consideração sobre o tamanho da amostra (número de replicações), seleção de uma ordem adequada de rodadas para as tentativas experimentais, ou se a formação de blocos ou outras restrições de aleatorização estão envolvidas.
11 Realização do experimento
Quando da realização do experimento, é de vital importância monitorar o processo, para garantir que tudo esteja sendo feito de acordo com o planejamento. Erros no procedimento experimental nesse estágio, em geral, destruirão a validade do experimento. O planejamento geral, do início até o fim, é crucial para o sucesso. É fácil subestimar os aspectos logísticos e de planejamento em um ambiente industrial complexo.
12 Análise de dados
Métodos estatísticos deve ser usados para analisar os dados, de modo que os resultados e conclusões sejam objetivos e não opinião. Se o experimento foi planejado corretamente e se foi realizado de acordo com o planejamento, então o tipo de métodos estatísticos exigidos não será complicado. Muitos pacotes estatísticos excelentes estão disponíveis para ajudar na análise de dados, e métodos gráficos simples desempenham um papel importante na interpretação dos dados. A análise dos resíduos e a verificação da validade do modelo são outros itens importantes. Se possível propor técnicas de apresentação e análise tais como plots, ANOVA, regressão, t test, etc.
13 Conclusões e recomendações
Uma vez analisados os dados, o experimento deve acarretar conclusões práticas sobre os resultados e recomendar um curso de ação. Métodos gráficos são em geral, usados nesse estágio, particularmente na apresentação dos resultados para outras pessoas. Seqüências de acompanhamento e testes de confirmação devem ser também realizados para validar as conclusões do experimento. Os passos 1 a 3 são usualmente chamados planejamento pré-experimental. Para o sucesso do experimento é vital que esses passos sejam realizados tão bem quanto possível.
Exemplos de objetivos
O planejamento de um experimento pode ter as seguintes finalidades: 1. Determinação de quais variáveis são mais influentes na resposta y; 2. Determinação do valor a ser atribuído aos x´s influentes de modo que y esteja perto da exigência nominal; 3. Determinação do valor a ser atribuído aos x´s influentes de modo que a variabilidade em y seja pequena; 4. Determinação de valor a ser atribuído aos x´s influentes de modo que os efeitos das variáveis não-controláveis sejam minimizados.
Tipos de Planejamentos
Classificação do Planejamentos de Experimentos Aplicação Estrutura Informações obtidas
Completamente Aleatorizado com um único fator Apropriado quando seomente um fator experimental está sendo estudado O efeito do fator é estudado por meio da alocação ao acado das unidades experimentais aos tratamentos (níveis do fator). Os ensaios são realizados em ordem aleatória. Estimativa e comparações dos efeitos dos tratamentos Estimativas da variância
Fatorial Apropriado quando vários fatores devem ser estudados em dois ou mais níveis e as interações entre os fatores podem ser importantes Em cada repetição completa do experimento todas as combinações possíveis dos níveis dos fatores (tratamentos) são estudadas. A alocação das unidades experimentais aos tratamentos e a ordem de realização dos ensaios são feitas de modo aleatório. Estimativas e comparações dos efeitos dos fatores Estimativa dos possíveis efeitos de interações Estimativa da variância
Fatorial 2k em blocos Apropriado quando o número de ensaios necessáios para o planejamento em k fatores em 2 níveis é muito grande para que sejam realizados sob condições homogêneas O conjuto completo de tratamentos é divido em subconjuntos de modo que as interações de ordem mais alta são confundidas com os blocos. São tomadas observações em todos os blocos. Os blocos surgem geralmente como conseqüência de rstrições de tempo, homogeneidade de materiais, etc. Fornece as mesmas estimativas do planejamento fatorial, exceto algumas interações de ordem mais alta que não podem ser estimadas porque estão confundidas com os blocos.
Fatorial 2k fracionário apropriado quando existem muitos fatores (k muito grande) e não é possível coletar observações em todos os tratamentos Vários fatores são estudados em dois níveis, mas somente um subconjunto do fatorial completo é executado. A formação dos blocos algumas vezes é possível. Estimativas e comparações dos efeitos de vários fatores Estimativa de certos efeitos de einteração (alguns efeitos podem não ser estimáveis) Certos planejamentos fatoriais fracionários 9quando k é pequeno) não fornecem informações suficientes para estimar a variância
Blocos aleatorizados Apropriado quando o efeito de um fator está sendo estudado e é necessário controlar a variabilidade provocada por fatores pertubadores conhecidos. Estes fatores pertubadores (material, tempo, pessoas, etc.) são divididos em blocos ou grupos homogêneos São tomadas observações correspondentes a todos os tratamentos (níveis do fator) em cada bloco. Usualemte os blocos são considerados em relação a um único fator pertubador. Estimativas e comparações dps efeitos dos tratamentos livres dos efeitos do bloco Estimativas dos efeitos do bloco Estimativa da variância
Blocos Incompletos Balanceados Apropriado quando todos os tratamentos não podem ser acomodados em um bloco Os tratamentos testados em cada bloco são selecionados de forma balanceada: dois tratamentos quaisquer aparecem juntos em um mesmo bloco o mesmo número de vezes que qualqer outro par de tratamentos Idêntico ao planejamento em blocos aleatorizados. Os efeitos de todos os tratamentos são estimados com igual precisão
Blocos Incompletos Parcialmente Balanceados Apropriado quando um planejamento em blocos incompletops balanceados necessita de um número de blocos excessivamente grandes Alguns pares de tratamentos aparecem juntos n1 vezes, outros pares aparecem juntos n2 vezes,..., e os pares restantes aparecem juntos m vezes. Idêntico ao planejamento em blocos aleatorizados, mas os efeitos dos tratamentos são estimados com diferentes precisões
Quadrados Latinos Apropriado quando um fator de interesse está sendo estudado e os resultados podem ser afetados por duas outras variáveis experimentais ou por duas fontes de heterogeneidade. É suposta a ausência de interações O quadrado latino é um arranjo para permitir dois grupos de restrições de bloco. Os tratamentos são distribuídos em correspondência à s colunas e linhas de um quadrado. Cada tratamento aparece uma vez em cada linha e uma vez em cada coluna. O número de tratamentos dever ser igual ao número de linhas e colunas do quadrado. Os blocos são formados em relação a duas variáveis pertubadoras, as quais correspondem à s colunas e linhas do quadrado. Estimativas e comparações dos efeitos dos tratamentos livres dos efeitos das duas variáveis bloco. Estimativas e comaprações dos efeitos das duas variáveis de bloco Estivativa da variância
Quadrados de Youden Similares aos quadrados latinos, mas o número de linhas, colunas e tratamentos não precisam ser iguais Cada tratamento ocorre uma vez em cada linha. O número de tratamentos deve ser igual ao número de colunas. Os blocos são formados em relação a duas variáveis pertubadoras Idêntico ao planejamento em quadrados latinos
Hierárquico Experimentos com vários fatores em que os níveis de um fator (B) são similares mas não idênticos para diferentes níveis de outro fator (A). Ou seja, o j-ésimo nível de B quando A está no nível 1 é deferente do j-ésimo nível de B quando A está no nível 2 e assim por diante Os níveis do fator B estão aninhados abaixo dos níneis do fator A Estimativas e comparações dos efeitos dos fatores Estimativa da variância
Superfície de resposta O objetivo consiste em fornecer mapas empíricos ou gráficos de contorno. Estes mapas ilustram a forma pela qual os fatores, que podem ser controlados pelo pesquisador, influenciam a variável resposta Os níveis dos fatores são vistos como pontos no espaço de fatores (muitas vezes multidimensional) no qual a resposta será registrada Mapas que ilustram a natureza e a forma da superfície de resposta
Artigos Relacionados
COLEMAN, D. E.; MONTEGOMERY, D. C. (1993). A systematic approach to planning for a designed industrial experiment. Technometrics, v.35, n.1
Livros
BOX, G. E. P.; HUNTER, W. G.; HUNTER, J. S. (1978). Statistics for experimenters. New York: John Willey. ( Disponível na biblioteca IP ) MONTGOMERY, D. C. (1997). Introduction to statistical quality control. 3rd. ed. New York: Wile. (Disponível na biblioeca da EESC - USP). MONTGOMERY, D. C. Design and analysis of experiments. 6 ed, John Wiley & Sons, 2005. CORNELL, J. A. Experiments with mixtures, Wiley, New York, 1981. WERKEMA, M. C. C.; AGUIAR, S. (1996). Planejamento e análise de experimentos: como identificar as principais variáveis influentes em um processo. Belo Horizonte: Ufmg. (Disponível na biblioteca da EESC - USP). WERKEMA, M. C. C.; AGUIAR, S. (1996). Otimização estatística de processo: como determinar a condição de operação de um processo que leva ao alcance de uma meta de melhoria. Belo Horizonte: Fundação Cristiano Ottoni. (Disponível na biblioteca da EESC - USP).
Revistas
Technometrics - Periodicidade Quadrimestral - Aborda métodos estatísticos para as áreas de química, física e engenharia. Grande parte dos artigos aborda o planejamento de eperimentos. http://www.asq.org/products/journals/techmet.html Journal of Quality Technology - Periodicidade Quadrimestral - Métodos, aplicações e tópicos relacionados com a tecnologia da qualidade. Foca principalmente em técnicas estatísticas e aborda com freqüência artigos sobre Planejamento de Experimentos. http://www.asq.org/products/journals/jqt.html Associações ASQ-American Society for Quality(1998) http://www.asq.org/
Software
Statistica - Desenvolvedor Stat Soft - É um dos sistemas com melhor interface gráfica e com grandes possibilidades em termos de análises gráficas.http://www.statsoft.com/ SAS - Desenvolvedor SAS - É um dos melhores sistemas e está entre os mais amplamente utilizados por estatísticos. http://www.sas.com/ MINITAB - Desenvolvedor Minitab - Trata-se de um software clássico em termos de análise estatística. Amplamente difundido tem como seu forte o fato de possuir seus procedimentos de cálculo bastante validados. http://www.minitab.com/ Interactive Statistical Pages - Página Web que realiza análises estatísticas. Possui uma grande quantidade de links de softwares sobre estatística na internet. Tem a facilidade de prover vários softwares e mesmo a realização, dentro desta página, de algumas análises estatísticas básicas. http://members.aol.com/johnp71/javastat.html
Sites relacionados
Visual Statistics(1998) http://www.mhhe.com/business/opsci/doane/
Processo de Negócio (business process) http://www.portaldeconhecimentos.org.br/index.php/content/view/full9678
Introdução
Possuir uma visão holística de um negócio é importante para seu gerenciamento e a modelagem do negócio torna esta visão abstrata em algo mais tangível para uma grande parte das pessoas da empresa. Desta forma consegue-se permear esta visão para toda organização. A visão holística de um negócio é aproximadamente representada por um processo de negócio (business process - BP).
Definição e localização
BP é um fenômeno que ocorre dentro das empresas. Compreende um conjunto de atividades realizadas na empresa, associadas às informações que manipula, utilizando os recursos e a organização da empresa. Forma uma unidade coesa e deve ser focalizado em um tipo de negócio, que normalmente está direcionado a um determinado mercado/cliente, com fornecedores bem definidos (figura abaixo). Como recursos pode-se entender técnicas, métodos, ferramentas, sistemas de informação, recursos financeiros e todo o conhecimento envolvido na sua utilização. A organização engloba não somente os aspectos organizacionais e estruturais das empresas, como também os seus agentes, ou seja, as pessoas com sua qualificação, motivação, etc.. A capacidade de aprendizado da empresa também é um dos elementos da organização de um BP. Este foco no negócio é importante, pois é comum encontrar diversos negócios de uma empresa compartilhando os mesmos elementos estruturais e recursos, o que dificulta a definição do BP (e em muitos casos a própria operação da empresa). Se o compartilhamento de recursos for inevitável, o conhecimento dos BPs que utilizam esses recursos traz este fato à consciência de uma forma sistemática, auxiliando então no seu gerenciamento (que não deixa de ser complexo). O BP é algo natural que acontece hoje em todas as empresas, mas muitas vezes ele é mascarado por disfunções estruturais, principalmente naquelas empresas que ainda trabalham com uma organização burocrática funcional. A existência de atividades, que não agregam valor ao produto, também dificulta a identificação dos BP. Em algumas empresas a existência dos BP não era consciente. Os novos requisitos dos clientes, competição mais acirrada e a disponibilidade de tecnologia de informação mais flexível fizeram com que fosse necessário se identificar os BP. Assim se consegue gerenciar os negócios de uma forma mais efetiva, focalizando-se nas exigências dos clientes [GAR95]. Exemplos típicos de BP são:
  • Liderança dos Negócios
  • Planejamento Estratégico
  • Desenvolvimento de Produto
  • Venda de Produto
  • Fabricação de Produto
  • Atendimento ao Cliente
  • Consolidação de Resultados
Em alguns sites listados pode-se obter uma lista de processos de negócio de referência.
Business process é o ponto comum de várias abordagens
Mesmo sem ser explicitamente citado como business process (BP), ele é utilizado em diversas abordagens atuais, como se procura mostrar a seguir de uma forma bem sucinta (vide figura abaixo). São analisadas aqui a Reengenharia, o Sistema de Qualidade, o Custo Baseado em Atividades (ABC) e a implantação de sistemas integrados (ERP). A ênfase atual de se definir os business processes das empresas advém da febre da Reengenharia. Pode-se dizer que a Reengenharia é que forneceu este termo com o significado atual de conjunto de atividades, que normalmente são realizadas por diversos departamentos de uma empresa. Normalmente uma Reengenharia do Negócio, onde a estrutura organizacional da empresa sofre alterações para ficar enxuta e preparada para os desafios da concorrência, deveria ser precedida pela Reengenharia do Processo. Nesta última o BP deveria ser identificado e melhorado, à luz do potencial da tecnologia de informação, partindo-se de um white paper, ou seja, sem vínculo com a situação atual. A obtenção de um Sistema de Qualidade segundo a norma ISO 9000 exige um certo formalismo dos procedimentos em vigor na empresa.Um resultado natural da preparação para a certificação segundo a ISO 9000 deveria ser uma melhoria dos processos atuais, apesar que muitas empresas preocupam-se somente com a certificação. Estas perdem a chance de obter os verdadeiros ganhos que a abordagem da qualidade fornece. Observa-se então que os BPs tornam-se uma referência para a formalização dos procedimentos. A abordagem de ABC (Activity Based Costing) é um método alternativo ao custeio clássico por absorção. O ABC propõe que se direcione os custos indiretos para os produtos, pois eles são cada vez mais significativos nas empresas de manufatura. Devido às caracteristicas semelhantes do custo por absorção, afirma-se que o verdadeiro ganho está no ABM (Activity Based Management). O ABM preconiza que se deve analisar as atividades visando a sua otimização, antes de serem custeadas através de seus direcionadores de custo. Percebe-se então que o conhecimento do business process é essencial para a prática do ABM. Em algumas empresas a definição das atividades para o ABC/M parte do estabelecimento dos BPs. A referência para a implantação de sistemas de gestão integrado ERP também são os BPs da empresa. Os istemas mais avançados já estruturam até as suas funções com base em BPs e muitas vezes fornecem modelos de referência a serem adotados por uma emrpesa específica. Além dessas abordagens pode-se utilizar os BPs como referência para a realização de atividades de benchmarking.
Diferença entre estrutura organizacional e business process
Estrutura organizacional de uma empresa agrega seus departamentos, áreas, setores, etc., conforme a denominação adotada na empresa. BP já foi anteriormente definido, e representa o conjunto de atividades da empresa, na realização de seu negócio. A visão departamentalista da empresa deve ser substituída pela visão por processos. No entanto, muitas empresas adotam essa nova filosofia até a última conseqüência obtendo resultados negativos. Em um banco ou uma seguradora é mais simples estruturar a empresa segundo os seus BPs. Isto é mais difícil nas empresas de manufatura. Isto é exemplificado aqui com o setor de Engenharia. Criar um setor que só cuide do desenvolvimento de novos produtos pode ser um desvio da filosofia por processos. O desenvolvimento de produtos é essencialmente multidisciplinar. Corre-se o risco de se criar um nicho de especialistas, que em pouco tempo estarão ultrapassados. O desenvolvimento de produtos deve ser realizados por time multifuncionais, composto por pessoas de diversas áreas, para exatamente poder unir os seus diferentes skills atualizados. Um departamento específico para desenvolvimento de produtos poderia neste caso ser somente um catalisador e gerenciador deste processo. Um departamento de engenharia então dentro deste conceito deve ter sua competência bem aprimorada para gerenciar o processo de desenvolvimento de produtos, fornecendo “consultores internos” nas atividades mais técnicas, como por exemplo em cálculos estruturais, para diversos times. Além disso, outros tipos de consultores do departamento de engenharia devem atuar como atores em outros processos, como mostra a figura abaixo.
Comentários Finais
Como pôde ser visto nesta sucinta apresentação, a determinação dos BPs é um ponto em comum de algumas abordagens em uso atualmente.A organização inteira deve pensar em termos de BP. O mapa do BP é essencial como base de referência para discussões, a fim de apoiar a obtenção sistemática de uma a visão holística da empresa. Para que os BPs possam servir de referência para essas diversas abordagens e mesmo para a manufatura integrada, eles devem ser mapeados (modelados)
Artigos
ALLIPRANDINI, D. H. (1995). Metodologia para intervenção na manufatura com orientação nos processos e baseada nas abordagens CIM e da qualidade. São Carlos, 1996. Tese (Doutorado) - Escola de Engenharia de São Carlos, Universidade de São Paulo. ( Disponível na biblioteca da EESC - USP ). BARRET, J. (1993). Process visualization: getting the vision right. Oracle Magazine, USA, v.7, n.1, p. 69-78, fall. (t 307) CATELLI, A.; GUERRERO, R. (1994). Uma análise crítica do sistema "ABC - Acvity Based Costing". JORNADA DE CONTABILIDADE, ECONOMIA E ADMINISTRAÇÃO DO CONE SUL, 17., Santos, 1994. Anais. p. 119-136. ( t306 ) GARVIN, D. A. (1995). Leveraging process for strategic advantage. Harvard Business Review, Harvard, v. 73, n. 5, p. 76-90. (t:799). NESS, J. A.; CUCUZZA, T.G. (1995). Tapping the full potentials of ABC. Harvard Business Review, Harvard, v. 73, n. 4, p. 130-138, jul. (t:462). ROZENFELD, H. (1995). Ambiente distribuído de soluções para suportar a engenharia simultânea. Máquinas e Metais, p. 211-223, março. (t:800 ). ROZENFELD, H.; AGUIAR, A. F. S.; SUGA, R.; FURUIUTI, R. (1995). Desenvolvimento de uma ferramenta computacional para modelagem de empresas. In: CONGRESSO BRASILEIRO DE ENGENHARIA MECÂNICA, Belo Horizonte, 1995. Anais. ABM. (t:801) ROZENFELD, H. (1996). Reflexões sobre a Manufatura Integrada por Computador (CIM). In: MANUFATURA CLASSE MUNDIAL: Mitos e Realidade. São Paulo, 1996. (t: 1). WOOD, T.; CALDAS, M. P. (1995). Quem tem medo de eletrochoque? Identidade, terapias convulsivas e mudança organizacional. Revista de Administração de Empresas, São Paulo, v. 35, n. 5, p. 13-21. (t:862)
Livros
HAMMER, M.; CHAMPY, J. (1994). Reengenharia: revolucionando a empresa em função dos clientes, da concorrência e das grandes mudanças da gerência. 17. ed. Rio de Janeiro: Campus. ( Disponível na biblioteca da FEA - USP ) MOREIRA, D. A. (1994). Reengenharia: dinâmica para mudança. São Paulo: Pioneira. ( Disponível na biblioteca da EESC - USP )
Sites relacionados
O American Productivity & Quality Center http://www.apqc.org trata de várias questões de integração e coordenada o International Benchmarking Clearinghouse, que em conjunto com a Arthur Andersen desenvolveu um Business Process Framework. Na área de download do APQC pode-se obter este processo.
Product-Service Systems and Sustainablity http://www.portaldeconhecimentos.org.br/index.php/content/view/full9501 O conceito de sistemas produto-serviço apregoa que o atendimento a uma demanda específica (consumidores, por exemplo) deve ser pensado não somente em termos dos produtos demandados, mas sim através de um mix produto-serviço. Tal conceito objetiva promover reduções drásticas nos impactos ambientais associados à produção e consumo de produtos. A definição clássica é a seguinte: A Product-Service System can be defined as the result of an innovation strategy, shifting the business focus from designing and selling physical products only, to selling a system of products and services which are jointly capable of fulfilling specific client demands. http://www.uneptie.org/pc/sustain/design/pss.htm http://www.uneptie.org/pc/sustain/reports/pss/pss-imp-7.pdf Produto Modular http://www.portaldeconhecimentos.org.br/index.php/content/view/full9676
Introdução
A modularidade surgiu como vantagem competitiva na indústria de computadores na década de 60, demonstrando grande importância no processo de desenvolvimento de produto. Este conceito já é usado na produção desde o início do século, porém seu uso em projetos é uma tendência atual, não só no ramo de tecnologia da informação, mas também na indústria em geral. Esta abordagem tem sido uma tendência crescente na indústria automobilística, devido em grande parte à complexidade de seus produtos e a dificuldade de controle de seus fornecedores. Isso tem levado a grandes avanços nesta área de pesquisa.
Modularidade
Modularidade é uma estratégia para construir processos ou produtos complexos a partir de pequenos subsistemas que podem ser desenvolvidos individualmente, mas que funcionam como um conjunto integrado. A modularidade é viabilizada pela divisão das informações em visíveis e ocultas. As informações visíveis são decisões que influenciam decisões subsequentes do processo. São divididas em três categorias:
  • arquitetura, que especifica os módulos do sistema e suas funções;
  • interfaces, que descrevem em detalhes a interação entre os módulos , sua conexão e comunicação;
  • padrões, para verificar a conformidade do módulo à configuração do produto ou processo e medir seu desempenho em relação aos demais módulos.
Os parâmetros ocultos são decisões que não afetam o desenvolvimento além dos módulos locais. Esta divisão entre as informações visíveis e ocultas deve ser precisa, sem ambigüidade e completa, senão a modularidade perde seus efeitos e faz com que enfraqueça a integração dos módulos.
Produto Modular
Produtos modulares são produtos, sistemas ou componentes que executam suas funções através da combinação de diferentes módulos. Os módulos são componentes, subsistemas e mecanismos que interagem com módulos distintos resultando em diferentes variantes do produto. Deste modo, a modularidade permite a produção de diferentes produtos pela combinação de componentes padrão.
Tipos de Modularidade
Baseado nas interações com o produto, três categorias de modularidade podem ser definidas:
  • Component-swapping modularity. Ocorre quando dois ou mais diferentes módulos são combinados com uma plataforma básica criando variantes de produtos pertencentes à mesma família.
  • Compontent-sharing modularity. É o caso complementar ao anterior. Várias plataformas básicas, divindo o mesmo módulo, formam diferentes variantes de produto pertencentes à diferentes famílias.
  • Bus Modularity. Ocorre quando uma plataforma básica pode ser trocada por um ou vários módulos. Este tipo permite a variação no número e na localização dos módulos.
Vantagens
A modularidade possibilita que se tenha uma gama variada de produtos, com respostas rápidas às mudanças de desejo e necessidades dos consumidores. Com estrutura modular de produto, os engenheiros têm maior liberdade para projetar seus módulos, sem dependência direta de outras etapas de projeto. Devido a esta independência, aumenta-se a intensidade de inovações no projeto, pois os engenheiros podem criar e testar diferentes soluções dentro de seus próprios módulos, devendo respeitar somente as regras visíveis ou interfaces do sistema. Outro reflexo imediato é o alcance mais rápido de soluções melhoradas pois os problemas são resolvidos com maior facilidade. Com este método, os fornecedores têm a sua atuação no processo de desenvolvimento de produtos facilitada, devido à independência que lhes é conferida. Além disso, o produto modular facilita a logística/distribuição com a diminuição de fornecedores, através da delegação de subsistemas menores aos fornecedores dos módulos.
Exemplos
Os exemplos apresentados são casos práticos da IBM, Mercedes-Benz e Kodak, demonstrando formas distintas de modularidade. 1 . IBM Em 1964, a IBM desenvolveu o Sistema/ 360 que consistia de uma família de computadores de diferentes tipos e aplicações, todos porém utilizando o mesmo conjunto de informações e podendo compartilhar periféricos. Os projetistas do Sistema/ 360 dividiram o projeto de processadores e periféricos em informações visíveis e ocultas. As regras visíveis foram estabelecidas e reforçadas por um escritório central, fazendo com que os módulos das máquinas funcionassem quando juntas. Com essa abordagem e a possibilitação de compatibilidade com os softwares existentes, a IBM obteve como resultado um enorme sucesso comercial e financeiro para a companhia e seus clientes. A modularidade também aumentou os domínios da IBM a longo prazo, já que várias empresas passaram a produzir módulos compatíveis à suas máquinas, como impressoras, terminais, memórias, softwares e eventualmente até mesmo CPU's. 2. Mercedes-Benz A modularidade foi implantada na Mercedes-Benz, no Alabama, no projeto de um utilitário esportivo. Ao invés de gerenciar um complexo sistema de fornecedores, contendo centenas deles, a empresa estruturou o produto em poucos e grandes módulos. O cockpit, por exemplo, incluindo air bags, ar condicionado, coluna de direção, volante, etc, formam um módulo separado, fornecido pela Delphi Automotive Systems. A Delphi, por sua vez, é responsável pelo gerenciamento dos fornecedores dos componentes do cockpit. As especificações da Mercedes-Benz tornaram-se visíveis para os fornecedores coordenarem as atividades de seus subfornecedores. 3. Kodak Com a modularidade, a Kodak nos anos 90 venceu a concorrência com a Fuji e aumentou sua participação no mercado. A Kodak desenvolveu diferentes modelos de uma mesma plataforma em comum. Entre 1989 e 1990, a empresa reprojetou seus produtos de modo que compartilhassem módulos e processos de produção em comum, que resultou em reduzido tempo de desenvolvimento de produto e baixos custos. Este tipo de modularidade foi citado anteriormente como component-swapping modularity, mas também é conhecida como plataforma de produtos.
Artigos
BALDWIN, C. Y; CLARK, C. B.; (1997). Managing in age of modularity. Harvard Business Review, Cambridge, September-October. KUSIAK, A; HUANG, C.; (1996). Development of modular products. IEEE Transactions on Components, Packaging, and Manufacturing Technology-Part A. v. 19, n. 4, p. 523-538. (t:810) ROBERTSON, D; ULRICH, K.; (1998). Planning for product plataforms. Sloan Management Review. v. 39, n. 4, p. 19-31, Summer. (t:797). MARX, R.; ZILBOVICIUS, M.; SALERNO, M. S.; (1997). The modular consortium in a new VW truck plant in Brazil: new forms of assembler and suppleir relationship. Integrated Manufacturing Systems, v. 8, n. 5, p.292-298, December. (t:798).
Especialistas
Karl Ulrich's Home Page http://grace.wharton.upenn.edu/~ulrich/ Karl T. Ulrich é professor da The Wharton School - University of Pennsylvania. É um dos autores mais citados nos artigos sobre produto modular. Mantém em sua home-page diversos artigos sobre produto modular, disponíveis em versão pdf além de links para outros sites sobre desenvolvimento de produto.
Sites Relacionados
Harvard Business School - Technology & Operations Management (TOM) - Working Papers http://www.hbs.edu/units/tom/working_papers/ Esta página mantém artigos (disponíveis para download) sobre modularidade e desenvolvimento de produto, escritos por Kim B. Clark e pela equipe do TOM.
Projeto Robusto / Método Taguchi http://www.portaldeconhecimentos.org.br/index.php/content/view/full9674
Descrição geral
O método Taguchi/Projeto Robusto pode ser entendido como uma nova abordagem da qualidade voltada para o projeto do produto e do processo. Esta abordagem foi desenvolvida pelo Prof. Taguchi e por ele denominada de controle de qualidade off-line. Segundo Taguchi, a qualidade é medida pelo desvio que uma característica funcional apresenta em relação ao valor esperado da mesma. Os fatores chamados "Ruído" (temperatura, umidade, poeira, deterioração, etc.) causam tais desvios e resultam em perda de qualidade do produto. Este "prejuízo" pode ser avaliado através de uma "função perda" que foi inicialmente proposta pelo professor Taguchi. A proposta do método Taguchi é a de determinar a função perda do produto e otimizá-la empregando técnicas estatísticas. Estas análises permitem identificar os parâmetros ótimos de projeto que minimizam ou mesmo eliminam as influências dos fatores ruído no desempenho do produto. Assim, em lugar da tendência tradicional de isolar o produto dos fatores ruído, o que pode ser de difícil execução e/ou encarecer o processo produtivo, o método de Taguchi ambiciona realizar projetos que eliminem os efeitos dos fatores ruído no produto. Por exemplo, CLAUSING (1994) apresenta um exemplo de projeto de um sistema de alimentação de copiadoras onde, num enfoque tradicional, uma equipe se concetrava em desenvolver complexos mecanismos para orientar a página antes da alimentação. Outra equipe, aplicando o método Taguchi, direcionou estes esforços no sentido de desenvolver um mecanismo de alimentação com uma pequena influência da orientação inicial da página. Utilizando-se o método Taguchi pretende-se obter produtos robustos o suficiente para assegurar alta qualidade a despeito de flutuações que venham ocorrer no processo produtivo e no ambiente de uso do produto. O trabalho do Dr. Taguchi, além de uma nova abordagem para a área de qualidade, serviu também para consolidar o conceito de Projeto Robusto, ou seja, o de projetar produtos que minimizem os fatores ambientais. Assim, Projeto Robusto consolidou-se como o conceito/filosofia de projetar produtos minimizando a influência dos fatores ruído, o que pode ser alcançado com diversas outras técnicas ou mesmo a partir da experiência e bom senso dos projetistas. Já o " método Taguchi" engloba o conjunto de técnicas propostas para atingir este objetivo de um Projeto Robusto, as quais incluem a otimização pela função perda e projetos de experimentos fatoriais com matrizes ortogonais.É preciso frisar também que o método Taguchi foi desenvolvido com uma grande preocupação de facilitar sua aplicação prática, o que lhe rendeu grande fama entre as empresas e profissionais, principalmente japoneses, e, por outro lado muitas críticas de especialistas em estatística. Há um conjunto grande de obras que apresentam as limitações dos procedimentos adotados por Taguchi, visando a diminuição da complexidade do método principalmente quanto à otimização. E, somado a estes problemas de ordem técnica, existe também outra barreira para sua adoção que é a necessidade de quantidade de testes que, para produtos complexos ou mais caros, pode tornar-se inviável.
Definição
Método Tagchi é uma abordagem da engenharia de qualidade "off line" que busca aumentar a robustez dos produtos por meio da diminuição dos efeitos dos parâmetros "ruido" no seu desempenho.
Conceitos Teóricos:
  • Fontes de ruído
  • Qualidade Robusta
  • Controle da Qualidade "off line"
  • Controle da Qualidade "on line"
  • Função Perda
  • Relação Sinal/Ruído
  • Etapas Básicas
Fontes de Ruído
Ruídos ou fatores de perturbação são os fatores que causam a variabilidade da função do produto. Tais ruídos podem ser enquadrados em três tipos: 1. Ruídos Externos: decorrem tanto das condições de utilização do produto quanto do ambiente em que o produto é utilizado, como, por exemplo, falha na operação do produto, umidade do ar, tensão da rede de energia, poeira, temperatura ambiente, etc.; 2. Ruídos Internos ou Ruídos Degenerativos: estão ligados às características próprias do produto, do processo ou serviço que o produto sofre antes de chegar no mercado, e procuram estabelecer valores (ou níveis) dos fatores (ou parâmetros) que têm influência no valor estabelecido para a saída (ou resposta) do sistema, com baixa variação em torno desse valor. 3. Variações na Produção: corresponde à variabilidade entre unidades do produto manufaturados sob as mesmas especificações.
Qualidade Robusta:
É uma abordagem para a garantia da qualidade, também chamada de método Taguchi em referência ao seu criador, com enfoque no projeto do produto e do processo. Seu princípio fundamental é o de que, para assegurar uma qualidade consistente, deve-se procurar projetar produtos que sejam insensíveis a despeito de flutuações que venham ocorrer no processo de produção e no ambiente de uso do produto, ou seja, o produto e o processo de produção, devem ser projetados de modo que o seu desempenho seja o menos sensível a todos os tipos de ruídos.
Controle de Qualidade “off line” (ou fora de linha)
São os esforços aplicados à qualidade do projeto, o que inclui qualquer atividade de projeto e desenvolvimento que ocorre antes da fabricação do produto. É o controle da qualidade aplicado durante o projeto do produto e durante o projeto do processo.
Controle de Qualidade “on line” (ou na linha)
É o controle de qualidade exercido durante a produção ou manufatura do produto
Etapas básicas para Aplicação da Metodologia Taguchi
  • Identificação dos Fatores
  • Planejamento e Condução dos experimentos
  • Predição dos novos níveis ótimos de parâmetros
  • Validação dos Resultados
Etapa 1: Identificação dos Fatores
Nesta etapa realiza-se a identificação dos fatores (ruído e fatores principais do ambiente e processo de fabricação) e os parâmetros de produto (processo) relevantes. Para cada um deles são previstas as possíveis influências e interações com os demais. Esta é uma etapa importante pois a não consideração de um determinado fator ou parâmetro pode distorcer ou impedir a obtenção da função perda, a qual irá guiar os projetistas em direção ao projeto mais robusto.
Etapa 2: Planejamento e Condução dos Experimentos
Depois de finalizar o projeto e protótipos do produto realiza-se a etapa de planejamento da coleta de dados experimentais. Estes dados irão permitir a construção da função perda e da relação sinal /ruído. Isto é feito utilizando-se conceitos de planejamento de experiementos, em especial os planejamentos fatoriais. Aliás, o emprego destes planejamentos é uma das características fundamentais do método Taguchi. Para realizar o planejamento deve-se iniciar pela escolha do tipo de planejamento, ou seja, pela escolha da matriz ortogonal que melhor se aplica ao problema. A escolha das matrizes dependem principalmente do número de fatores e da quantidade de corridas (ou seja, de casos de experimentos) que poderiam ser realizados conforme a disponibilidade de tempo e custo. Em seguida são especificados valores para os diferentes níveis dos parâmetros. Com estes dados basta aleatorizar as corridas e programar a realização dos ensaios. Ao final deste trabalho, com o plano de testes 'em mãos', são realizados os ensaios e as coletas de dados respeitando os cuidados exigidos pelo tipo de teste específico.
Etapa 3: Predição dos Níveis Ótimos dos Parâmetros
É realizada uma otimização dos parâmetros do produto levando-se em consideração a relação sinal/ruído. Isto significa obter um modelo estatístico desta relação com os dados coletados no experimento e aplicar, neste modelo, técnicas de otimização para encontrar os valores dos parâmetros ótimos dos produtos. Ao final desta etapa tem-se um conjunto de valores de parâmetros (ou características) do produto que tornam seu desempenho robusto e estável em relação às características ambientais e às variações do processo.
Etapa 4: Validação dos Resultados
Como os níveis ótimos dos parâmetros obtidos anteriormente são fruto de um modelo estatístico, e portanto uma aproximação da realidade, deve-se realizar uma etapa de validação dos resultados encontrados, ou seja, verificação dos níveis ótimos especificados para os parâmetros. Isto é feito conduzindo um experimento com um protótipo cujos parâmetros são ajustados conforme os valores ótimos obtidos na fase anteior. Os resultados deste experimento devem coincidir com àqueles encontrados por meio do modelo, dentro, é claro, da devida margem de segurança. Caso isto ocorra significa que o modelo obtido é confiável e portanto pode-se aprovar estes parâmetros como especificações para o projeto. Ao contrário, ocorrendo uma significativa diferença entre os modelos, deve-se reavaliar os resultados dos experimentos e seu planejamento. Provavelmente algum parâmetro do produto ou fator ruído não tenha sido considerado ou algum problema tenha ocorrido durante a condução dos experimentos, entre outras possíveis distorções.
Glossário
  • Característica funcional: é uma característica bem definida de um produto, relacionada à sua funcionalidade;
  • Fatores controláveis: são fatores cujos ajustes nominais podem ser controlados pelo projetista ou engenheiro de processo.
  • Ruídos : são fatores ligados ao ambiente ou ao processo de fabricação que causam variações no desempenho do produto.
  • Parâmetros de ruído: são os fatores que causam os ruídos e que podem ser sistematicamente variados num experimento de projeto de parâmetros.
  • Método de controle de qualidade “off line” (ou fora de linha): é o método de qualidade usado durante o projeto do produto e do processo para garantir a melhoria da qualidade de um produto.
  • Método de controle de qualidade “on line” (ou na linha): é o método usado durante a produção do produto para melhorar e manter a qualidade de um produto.
  • Perda de desempenho: é a perda causada pelo afastamento de uma característica funcional em relação valor desejado.
  • Fator de Sinal: é uma variável empregada para alterar o valor de uma característica funcional em direção a um valor desejado. O projetista não determina os ajustes desse fator , entretanto, ele pode querer projetar o produto ou processo para ser muito sensível à mudanças no fator de sinal.
  • Relação Sinal/Ruído (no projeto de parâmetros): é uma medida da variabilidade do desempenho do produto.
Informações Adicionais
PHADKE, M. S.; (1989). Quality engineering using robust design. Englewood: Prentice Hall. ( Disponível na biblioteca da EESC - USP). ROSS, P.; (1995). Taguchi techinique for quality engineering: loss function, orthogonal experiments, parameters and tolerance design . 2ed. New York: McGraw-Hill. ( Disponível na biblioteca da FEA - USP ). TAGUCHI, G.; (1986). Introduction to quality engineering : designing quality into products and processes. Trad. por Sekkeisha. 6. ed. Tokyo : The Organization. ( Disponível na biblioteca da EP - USP ).
Sites Relacionados
Strategy for industrial experimentation Forum virtual para discussão de técnicas de planejamento de experimentos e Taguchi. Contém vários papers e recebe comentários. http://www.mcb.co.uk/services/conferen/nov98/sie/
Ferramentas Computacionais
SDSS -Esta empresa dispõe de vários produtos que cobrem várias áreas de estatítica tais como CEP, Planejamento de Experimentos, Amostragem, etc... Inclui também um banco de dados para integrar os dados destes pacotes. Entre os módulos afirma que um trabalha com o método Taguchi. http://www.spss.com/software/quality/
Periódicos Importantes
Technometrics -Periodicidade Quadrimestral - Aborda métodos estatísticos para as áreas de química, física e engenharia. Grande parte dos artigos aborda o planejamento de experimentos .http://www.asq.org/products/journals/techmet.html. Quality Progress - Periodicidade Mensal - Aborda assuntos gerais ligados a área de qualidade. É voltada para profissionais que atuam em empresas.http://qualityprogress.asq.org/ Journal of Quality Technology - Periodicidade Quadrimestral- Métodos, aplicações e tópicos relacionados com a tecnologia da qualidade. Foca principalmente em técnicas estatísticas e aborda com freqüência artigos sobre Planejamento de Experimentos. http://www.asq.org/products/journals/jqt.html
Projetos Mecânicos Utilizando Geometric Dimensioning and Tolerancing (GD&T) e Simulação Monte Carlo http://www.portaldeconhecimentos.org.br/index.php/content/view/full9639
Introdução
O sistema cartesiano, que ainda é ensinado nas faculdades de engenharia e praticado pelas empresas na-cionais, está obsoleto porque aumenta o custo dos produtos. Para que os produtos industriais brasileiros sejam competitivos é necessário que os engenheiros utilizem as modernas ferramentas de projetos que estão sendo aplicadas nos países industrializados. A norma QS-9000 contem a relação destas ferramentas. A norma QS-9000 A publicação da norma QS-9000 foi uma iniciativa da General Motors, Ford e Chrysler com o objetivo de fabricar produtos competitivos. Ela contém o que há de melhor na prática da engenharia automobilística americana. Seus conceitos são absolutamente gerais e podem ser utilizados pelos demais segmentos industriais, principalmente as ferramentas de engenharia, dentre as quais se encontra o GD&T.
GD&T e a Simulação Monte Carlo
O GD&T é a nova ferramenta de cotação que substituiu o sistema cartesiano. Ele trabalha em parceria com a simulação Monte Carlo. O GD&T define as tolerâncias dimensionais e geométricas dos componentes e a simulação Monte Carlo as ajusta segundo o critério de qualidade descrito a seguir.
Critério de Qualidade da QS-9000
O critério de qualidade adotado pela norma QS-9000 é o controle dos processos. Por exemplo, as polias do motor ao lado devem ser paralelas. Não basta estabelecer isoladamente as tolerâncias dimensionais e geométricas dos componentes, porque esta característica é uma cota resultante, que depende das tolerâncias dos demais componentes e do processo de montagem. Segundo a norma acima citada, é necessário ajustá-las de tal modo que se obtenha um índice de capabilidade Cp>1,67.
Hitórico do GD&T
O criador do GD&T foi Stanley Parker, engenheiro inglês da fábrica de torpedos da marinha britânica, localizada na cidade de Alexandria, Escócia. Nessa época, 1940, acreditava-se que o erro era inevitável. Tudo que era produzido, não importa o quê, continha um percentual de peças ruins. O modelo industrial da época tinha obrigatoriamente duas etapas: fabricar e inspecionar, para retirar as peças ruins do lote produzido. Stanley Parker, pressionado pelo esforço de guerra, provocou uma grande controvérsia ao realizar uma experiência inédita. Montou produtos que funcionaram bem utilizando peças reprovadas na inspeção. Ele constatou que a característica crítica na montagem dos produtos é o afastamento em relação ao centro (true position), portanto o campo de tolerância deve ser circular e não quadrado. O sistema cartesiano utiliza campos de tolerância quadrados e reprova as peças cujos centros dos elementos se localizam na zona hachurada, provocando um grande desperdício, uma vez que a área do círculo é 57% maior que a do quadrado inscrito. Stanley Parker concluiu que as peças reprovadas, na verdade, eram peças boas. O que estava errado era o conceito de peça ruim. Assim nasceu o GD&T, que utiliza campos de tolerâncias cilíndricos. Esta foi a primeira alteração sofrida pelo sistema cartesiano, 300 anos após a sua criação.
O desenvolvimento do GD&T
Ao longo do tempo diversos novos conceitos foram incorporados ao GD&T, como os princípios de máximo e mínimo material, a condição de independência, a zona de tolerância projetada, as zonas de tolerâncias compostas, os datuns, etc. No estágio atual o GD&T é composto de 290 regras, cuja aplicação é normalizada pelas associações de normas técnicas dos diversos países, algumas delas citadas adiante. Na última revisão da norma técnica americana, ASME Y14.5, 1994, houve mais de 100 alterações, e outras tantas estão em vias de acontecer. Para projetar produtos competitivos os engenheiros e técnicos precisam constantemente atualizar os seus conhecimentos de GD&T. Os softwares de CAD ajudam a elaborar os modelos e desenhos, mas a cotação, que é a parte mais sensível dos projetos devido ao impacto na qualidade e no custo, continua a ser feita pelo cérebro humano. Nos Estados Unidos a ASME (American Society of Mechanical Engineers) realiza periodicamente um "provão de GD&T". As empresas treinam os seus profissionais e os incentivam a obter a certificação. Dentro em breve isto se tornará uma exigência que fatalmente atingirá as empresas brasileiras. Visite o site http://www.mw.eng.br para fazer um teste de GD&T nos moldes do provão da ASME. Cálculo dos Índices de Capabilidade Cp/Cpk A ferramenta ideal para calcular os índices Cp/Cpk é a simulação Monte Carlo. Ela executa a montagem virtual de um grande número de conjuntos, combina aleatoriamente os valores das tolerâncias dos componentes (reproduz o que acontece na linha de montagem) e fornece o histograma da distribuição, os índices de capabilidade Cp/Cpk, e a relação das tolerâncias que mais contribuem para a variação das características funcionais. Esta atividade deve ser realizada na engenharia, na fase de desenvolvimento do produto, antes da fabricação do ferramental. Exemplo da Aplicação de GD&T e Simulação Monte Carlo Visite o site http://www.mw.eng.br Identificação das Características Chave (Key Characteristics) A simulação Monte Carlo também relaciona as tolerâncias pela sua ordem de importância e identifica as principais responsáveis pela qualidade do produto (Key Characteristics). Esta informação é muito importante porque coloca em evidência os processos mais sensíveis. Custo & Qualidade do Produto As tolerâncias não identificadas como características chave devem ser alargadas ao máximo para reduzir o custo. O conjunto final de tolerâncias é a solução de compromisso ideal entre custo e qualidade, capaz de atender aos índices de capabilidade especificados. Relação dos Benefícios Obtidos
  • Nas operações de produção o emprego do GD&T reduz o custo direto dos produtos pelos seguintes motivos:
  • Utiliza campos de tolerâncias 57% maiores.
  • Elimina o sucateamento de peças boas.
  • Garante ZERO DEFEITO dimensional na fabricação dos componentes devido a utilização de calibres calibres funcionais, um conceito exclusivo do GD&T.
Normas Técnicas de GD&T NBR 6409, Associação Brasileira de Normas Técnicas. ASME Y14.5M 1994, American Society of Mechanical Engineers, USA. BS 308, Parts 2 e 3, British Standards Institution. CSA B78.2, Canadian Standards Association. NF E 04-552 ENR, AFNOR, France. ISO 1101, 5458, 5459, 2692,2692 DAM I, 10578 e 2768-2, Internacional. Livros sobre GD&T GEO-METRICS III, Lowell W. Foster FUNDAMENTALS OF GD&T, Alex Krulikowski INTERPRETATION OF GD&T, Daniel E. Puncochar ENGINEERING DRAWING AND DESIGN, David A. Madsen DIMENSIONING, TOLERANCING, AND GAGING APPLIED, Gary Gooldy Sites de GD&T e Simulação Monte Carlo http://www.mw.eng.br http://www.etinews.com/ http://www.tec-ease.com/ http://www.eai.com/ http://www.mimetek.com
Prototipagem Rápida (Rapid Prototyping) http://www.portaldeconhecimentos.org.br/index.php/content/view/full10032
Introdução
Nos últimos anos surgiu uma nova família de máquinas altamente inovadoras que permitem, com tecnologias e materiais diferentes, obter um protótipo de um modelo ou de um molde, de maneira precisa e rápida a partir do modelo sólido gerado no sistema CAD 3D. Tais máquinas, conhecidas como máquinas de Prototipagem Rápida, permitem obter peças físicas acabadas, de modo automático, de qualquer forma e em dimensões finais, com complexidade e detalhes que não permitiriam sua obtenção em máquinas convencionais de usinagem, ou tornariam sua execução demorada ou complexa em centros de usinagem numericamente comandados. Dessa forma, tais máquinas possibilitam uma maior velocidade e menor custo na obtenção de protótipos se comparado aos processos tradicionais de usinagem. Além disso, em certos casos estas técnicas permitem a obtenção de matrizes capazes de produzir uma quantidade limitada de peças, ideal para o emprego na produção de lotes pilotos. Tal tecnologia possibilita que as empresas possam desenvolver produtos mais rapidamente (menor time to market) e com menor custo, e, principalmente, com um acréscimo na qualidade por meio de uma melhor avaliação do projeto. Leva também à uma diminuição das incertezas e riscos . É o caso do ferramental, por exemplo, cujo risco de perda por falhas no projeto diminui drasticamente e também, do produto que, uma vez tornado físico pode ser melhor avaliado antes da decisão de dar continuidade ao seu desenvolvimento. Segundo Wohlers (1998), o custo das mudanças de projeto ao longo do ciclo de desenvolvimento do produto, aumenta aproximadamente em cerca de uma ordem de magnitude conforme passa-se de uma fase para a seguinte conforme indicado na figura 1. Figura 1 – Custo de alteração de projeto ao longo de ciclo de desenvolvimento do produto (Wohlers, 1998).
Conceitos
Prototipagem Rápida é uma tecnologia que possibilita produzir modelos e protótipos diretamente a partir do modelo sólido 3D gerado no sistema CAD. Ao contrário dos processos de usinagem, que subtraem material da peça em bruto para se obter a peça desejada , os sistemas de prototipagem rápida geram a peça a partir da união gradativa de líquidos, pós ou folhas de papel. Camada por camada, a partir de seções transversais da peça obtidas a partir do modelo 3D, as máquinas de prototipagem rápida produzem peças em plásticos, madeira, cerâmica ou metais. Os dados para as máquinas de prototipagem são gerados no sistema CAD no formato STL , que aproxima o modelo sólido por pequenos triângulos ou facetas. Quanto menor forem estes triângulos, melhor a aproximação da superfície, ao custo naturalmente de maior tamanho do arquivo STL e tempo de processamento. Um vez que o arquivo STL é gerado, as demais operações são executadas pelo próprio software que acompanha as máquinas de prototipagem rápida. Basicamente estes softwares irão, além de operações básicas de visualização, gerar as seções tranversais do modelo que será construído. Tais dados são então descarregados para a máquina que irá depositar as camadas sucessivamente até que a peça seja gerada. As figuras 2 , 3 e 4 ilustram esquematicamente os processos de estereolitografia ( SLA), Sinterização seletiva (SLS - Selective Laser Sintering) e LOM ( Laminated Objet Manufaturing) Figura 2 - Processo de Estereolitografia ( SLA – 3D Systems Inc.). ( http://www.3dsystems.com/) Figura 3 - Processo de Sinterização Seletiva ( SLS – DTM Corp.). ( http://www.dtm-corp.com/Technology/sls_process.htm ) Figura 4 - Processo LOM. ( http://helisys.com/ )
Histórico
Sistemas de Prototipagem rápida surgiram inicialmente em 1987 com o processo de estereolitografia (StereoLithography - SL) da empresa americana 3D Systems, processo que solidifica camadas (layers) de resina foto-sensível por meio de laser. O sistema SLA-1, o primeiro sistema de prototipagem disponível comercialmente foi um precursor da máquina SLA - 250, bastante popular nos dias de hoje. Após a empresa 3D Systems iniciar a comercialização de máquinas SL nos EUA, as empresas japonesas NTT Data e Sony/D-MEC passaram a comercializar suas versões de máquinas de estereolitografia em 1988 e 1989, respectivamente. Em seguida, em 1990, a empresa Eletro Optical Systems - EOS na Alemanha, passou a comercializar o sistema conhecido como Stereos. Logo após vieram as tecnologias conhecidas como Fused Deposition Modeling (FDM) da empresa americana Stratasys, Solid Ground Curing (SGC) da israelense Cubital e Laminated Object Manufacturing (LOM), todas em 1991. A tecnologia FDM faz a extrusão de filamentos de materiais termoplásticos camada por camada, semelhante à estereolitografia, só que utilizando um cabeçote de fusão do material em vez de cabeçote laser. SGC , também trabalha com resina foto-sensível a raios UV, só que solidifica cada camada numa única operação a partir da utilização de máscaras criadas com tinta eletrostática numa placa de vidro. LOM solidifica e corta folhas de papel (atualmente folhas de termoplásticos reforçado com fibras) usando laser controlado por computador. Sistemas de sinterização (Selective Laser Sintering - SLS) da empresa americana DTM e o sistema Soliform de estereolitografia da japonesa Teijin Seiki tornaram-se disponíveis em 1992. Usando calor gerado pelo laser , SLS funde pós metálicos e pode ser utilizado para obtenção direta de matrizes de injeção. Em 1993, a americana Soligen comercializou o produto conhecido por Direct Shell Production Casting (DSPC), que utiliza um mecanismo de jato de tinta para depositar líquido agregante em pós cerâmicos para produção de cascas que podem por sua vez serem utilizados na produção de moldes e peças injetadas em Alumínio, processo este desenvolvido e patenteado pelo MIT (Massachussets Institute of Technology). Em 1994 muitas outras tecnologias e sistemas surgiram:
  • ModelMaker da empresa americana Sanders Prototype, usando sistema de jato de cera ( ink-jet wax);
  • Solid Center da empresa japonesa Kira Corp., utilizando um sistema laser guiado e um plotter XY para produção de moldes e protótipos por laminação de papel. ;
  • Sistema de estereolitografia da empresa Fockele & Schwarze (Alemanha);
  • Sistema EOSINT, da empresa alemã EOS, baseado em sinterização;
  • Sistema de estereolitografia da empresa japonesa Ushio
O sistema Personal Modeler 2100 da empresa BPM Technology (EUA) foi vendido comercialmente a partir de 1996 (BPM significa Ballistic Particle Manufacturing). A máquina produz peças a partir de um cabeçote a jato de cera. No mesmo ano a empresa Aaroflex (EUA) passou a comercializar o sistema SOMOS em estereolitografia da multinacional DuPont, e a empresas Stratasys (EUA) lançou seu produto Genisys, baseado em extrusão , similar ao processo de FDM, mas utilizando sistema de prototipagem desenvolvido no Centro de Desenvolvimento IBM (IBM´s Watson Research Center). No mesmo ano, após oito anos comercializando produtos em esterolitografia, a empresa 3D Systems (EUA) comercializou pela primeira vez seu sistema Actua 2100, sistema baseado em impressão a jato de tinta 3D. O sistema deposita materiais em cera camada por camada através de 96 jatos. No mesmo ano, Z Corp. (EUA) lançou o sistema Z402 3D para prototipagem baseado na deposição de pós metálicos em 3D. Outras tecnologias e empresas apareceram e desapareceram durante os anos. Companhias como a Light Sculpting (EUA), Sparx AB (Suécia) e Laser 3D (França) desenvolveram e implementaram sistemas de prototipagem, mas não tiveram impacto industrial. Nos EUA, atualmente somente uma empresa estrangeira, a israelense Cubital, mantém escritórios de venda (Wohlers, 1998).
Aplicações
As técnicas de prototipagem rápida podem ser aplicadas às mais diversas áreas tais como, automotiva, aeronáutica, marketing, restaurações , educação, paleontologia e arquitetura. A figura seguinte ilustra como estas técnicas têm sido utilizadas nos EUA: Figura 5 – Aplicações de prototipagem rápida em diferentes áreas produto (Wohlers, 1998). Figura 6 - Exemplos de aplicação de técnicas de prototipagem rápida na fabricação de moldes. WOHLERS, T. (1998). Rapid Prototyping & Tooling - Worldwide Progress Report, Colorado, USA CLARK, K.B., FUJIMOTO, T. (1991) Product development performance: strategy, organization and management in the world auto industry. Boston-Mass.: Harvard Business School Press. ( Disponível na biblioteca da FEA - USP ).
Sites Relacionados
The Rapid Prototyping Home Page: http://www.cc.utah.edu/~asn8200/rapid.html Wohlers Associates: http://www.wohlersassociates.com/ The Rapid Prototyping Database: http://www.icom.cz/mcltd/RPdatabase.html Rapid Prototyping in Europe and Japan: http://itri.loyola.edu/rp/toc.htm The world of Rapid Prototyping: http://ecoleing.uqtr.uquebec.ca/geniedoc/gmm/productique/rpworld.htm
QFD (Quality Function Deployment) http://www.portaldeconhecimentos.org.br/index.php/content/view/full10294
Objetivos dessa página
  • fornecer uma visão ampla e superficial do QFD, indicando ao visitante onde ele pode buscar informações adicionais;
  • mostrar com um pouco mais de detalhes onde este método pode ser aplicado no processo de desenvolvimento de produtos;
  • colocar à disposição do visitante ferramentas para download de formulários, roteiros e planilhas que o auxiliarão a aplicar um tipo de QFD (por enquanto, aguardamos contribuições para aumentar o conteúdo de material gratuito).
Se você já conhece o QFD vá direto para a seção que traz o material gratuito para download visando sua aplicação
Fontes
Grande parte do material inicial dessa página foi elaborada a partir da página existente do NUMA e confeccionada por Manuel Otelino. Na ocasião, diversas partes de sua dissertação de mestrado foram utilizadas. Utilizamos também novos conhecimentos documentados no livro QFD do Prof. Cheng. Agora que este conteúdo está aberto à comunidade em geral, convidamos a todos para adicionar as suas contribuições.
Definições e histórico
A definição mais genérica e tradicional do QFD é um método de sistemático de projetar a qualidade de um produto ou serviço. Ele traduz as necessidades do cliente em características do produto ou serviço. Porém sua aplicação pode ser muito mais ampla do que essa definição tradicional indica. Seus princípios são tão gerais, que ele pode ter vários tipos de aplicações. Sua origem remonta no movimento da gestão da qualidade total (TQM), que evolui da garantia da qualidade pela inspeção, para a garantia da qualidade pelo controle do processo e cada vez mais a ênfase atual é na garantia da qualidade no desenvolvimento de produtos. E considera-se essa prática um avanço do desenvolvimento de produtos. No início era somente uma técnica para desdobrar por meio de matrizes as necessidades dos clientes em características técnicas de produto. Hoje o conceito de QFD é bem mais amplo e se divide em dois grupos o QFDr (quality function deployment in a restricted sense) e o QD (quality deployment). O QFDr, também conhecido em português como o processo gerencial de desenvolvimento do produto orientado para cliente, é um modelo de referência para gestão do desenvolvimento de produtos. Ou seja, o QFDr define as atividades e padrões para se realizar o processo de desenvolvimento de produtos (PDP). O QD, desdobramento da qualidade, corresponde à técnica original. Confira no site do QFD institute a história do QFD. No do Prof. Cheng existe uma visão histórica muito bem estruturada (capítulo 2.2). livro sobre QFD Assim a definição mais atual e completa do QFD é dual, devido aos dois focos complementares, porém de natureza distinta: 1. QFDr é uma referência para a gestão do desenvolvimento de produtos (GDP) com foco na sistematização do PDP 2. QD é um método para desdobrar a voz do cliente em características (de qualidade, funcionais, de custo e confiabilidade) do produto ou serviço - foco na sua aplicação operacional durante o PDP Nessa página estaremos apresentando somente o QD, com ênfase na Gestão do Desenvolvimento de Produtos. O QD pode ser empregado durante todo o processo de desenvolvimento de produto e tem por objetivo auxiliar o time de desenvolvimento a incorporar no produto as reais necessidades dos clientes. A nova versão do QD introduziu o modelo conceitual no desdobramento da qualidade. Devido à difusão de métodos mais tradicionais nos USA, principalmente pela American Supplier Institute (ASI) e Europa, o termo QFD ainda é empregado, mas somente como QD. Assim, é comum observar publicações que utilizam o termo QFD, mas que tratam somente do desdobramento da qualidade do produto. Algumas vezes associa-se o QD à confecção da casa da qualidade, também conhecida como primeira casa da qualidade. O próprio criador do QFD Akao insiste em dizer que QFD não é a primeira casa da qualidade, pois é bem mais que isso. Além disso, muitas aplicações do QD nem necessitam da primeira casa da qualidade.
Mecanismos e princípios
Os elementos principais do QD são as tabelas, matrizes e modelo conceitual. A tabela é o elemento que pode representar de forma hierárquica diversas características envolvidas no QD, que podem ser tanto entradas como saídas, por exemplo: requisitos dos clientes, do produto, do processo etc. As matrizes relacionam duas tabelas. Por meio de um conjunto de matrizes parte-se dos requisitos expostos pelos clientes e realiza-se um processo de desdobramento transformando-os em especificações técnicas do produto. As matrizes servem de apoio para o grupo orientando o trabalho, registrando as discussões, permitindo a avaliação e priorização de requisitos e características e, ao final, será uma importante fonte de informações para a execução de todo o projeto. Neste trabalho com as matrizes realizam-se algumas operações básicas de extração, relação e conversão, em que:
  • a extração é o processo de criar uma tabela a partir de outra, ou seja, de utilizar os elementos de uma tabela como referência para se obter os elementos de outra tabela.
  • a relação é o processo de identificar a intensidade do relacionamento entre os dados das duas tabelas que compõem a matriz.
  • a conversão é o processo de quantificar a importância relativa dos dados de uma tabela em função da intensidade da relação destes com os dados da outra tabela. Nesse processo é também considerada a importância relativa dos dados que compõem a tabela que será convertida.
O modelo conceitual relaciona as tabelas e matrizes. Define a sequência de desdobramentos. Pode-se realizar desdobramentos relacionados com a qualidade do produto (característica de qualidade ou qualidade projetada), com a tecnologia (processo de fabricação), com o custo e com a confiabilidade. Na definição de uma aplicação específica do QD, o primeiro passo é definir o modelo conceitual, ou seja, quais desdobramentos serão realizados. A força do QFD está em tornar explícitas as relações entre necessidades dos clientes, características do produto e parâmetros do processo produtivo, custos, confiabilidade permitindo a harmonização e priorização das várias decisões tomadas durante o processo de desenvolvimento do produto, bem como em potencializar o trabalho de equipe. Outro aspecto importante a considerar é que, por ser um método que se baseia no trabalho coletivo, os membros da equipe desenvolvem uma compreensão comum sobre as decisões, suas razões e suas implicações, e se tornam comprometidos com iniciativas de implementar as decisões que são tomadas coletivamente.
Tipos ou versões de QFD
QFD das Quatro Fases
Foi a primeira versão existente do QFD. Criado por Macabe e divulgado nos EUA por Don Clausing (CLAUSING, 1993) e pela American Supplier Institute (ASI). Definia uma sequência rígida de desdobramento da qualidade: planejamento do produto (características de qualidade com qualidade projetada com requisitos do produto); componentes, planejamento do processo e planejamento da produção.
QFD estendido
É uma evolução do anterior. Don Clausing no seu livro clássico Total Quality Development (TQD) propõe uma aplicação integrada do QFD (QD) ao processo de desenvolvimento de produtos (TQD), com ênfase no ensaio de experimentos com base no Robust Design. Suas matrizes representando o desdobramento de características de qualidade de sistemas, subsistemas, componentes e processos,
QFD das Quatro Ênfases
Criado pelos Professores Akao e Mizuno fomentados pela Union of Japanese Scientists and Engineers (JUSE). Adicionou ao conceito de qualidade total a necessidade de se considerar a qualidade durante o desenvolvimento de produtos. A relação entre as matrizes neste tipo de QFD pode ser vista na figura abaixo. Na primeira casa (A casa da qualidade) faz-se o desdobramento dos requisitos do cliente transformando-os em especificações do produto. Em seguida na casa do Planejamento dos Componentes estes requisitos do produto são desdobrados em requisitos para os componentes do produto. Na casa do Planejamento dos Processos, os requisitos gerados na etapa anterior, requisitos dos componentes, são transformados em requisitos dos parâmetros de processo e estes, por sua vez, são desdobrados nos requisitos dos padrões de operação do processo. Garante-se com esta abordagem que toda a especificação de produto, componentes, processos e padrões de operação estejam orientadas à s necessidades dos clientes.
A Matriz das Matrizes
Criado por Bob King e divulgado pela Goal/QPC. É uma extensão da versão das quatro ênfases (KING, 1989). Todas as versões apresentadas anteriormente não possuíam o modelo conceitual. Esta ferramentao nao funciona
Desdobramento da qualidade (QD)
É o método mais flexível e pragmático. O modelo conceitual mostra qual a melhor combinação de correlação entre as matrizes, focando no que é essencial. Foi descrito na seção Elementos, mecanismos e princípios.
Casa da Qualidade
Também conhecida como a primeira casa da qualidade. Apesar de não ser um método de QFD propriamente dito, pois ele pode acontecer no início de alguns métodos (como o QFD das quatro fases), ela é algumas vezes a única matriz empregada. A essa matriz foram agregadas várias tabelas que auxiliam a calcular o grau de importância de um requisito do cliente (qualidade exigida) a partir: (a) da análise da natureza do requisito segundo o grau de percepção do cliente (requisito óbvio, excitante etc); (b) de uma avaliação comparativa com os principais concorrentes (benchmarking) e (c) de um fator que mede o impacto deste requisito na venda (argumento de venda). O caso 2 de aplicação mostra um exemplo acadêmico dessas tabelas, que ficam incorporadas à casa da qualidade.Dentro do material para download, pode-se baixar planilhas, formulários e checklists, para se aplicar este método de QFD.
Aplicações
O QFD pode ser aplicado em planejamento estratégico, no desenvolvimento de produtos, para avaliar custos e muito mais. A sua aplicação mais usual é na gestão do desenvolvimento de produtos, foco desta página. No livro do Cheng existem relatos de aplicações na indústria de alimentos, automotiva, autopeças, de materiais e software. As aplicações abrangem definição de características dos produtos, processos de fabricação, melhoria do processo de desenvolvimento de produtos, melhoria do serviço de atendimento a clientes, definição de requisitos de usabilidade, entre outras. Por enquanto temos somente dois casos de aplicação em ambientes acadêmicos ou voltadas para o ensino de QFD, ou seja, aplicações didáticas.
Caso 1 de aplicação acadêmica: Fábrica Integrada Modelo (FIM)
Essa aplicação foi realizada em 1998 e é uma aplicação acadêmica realizada em um ambiente que procurava representar uma fábrica real, a FIM. Foi realizado o QFD do projeto do redutor de velocidades. Neste exemplo de aplicação do QFD foi empregada somente a casa da qualidade, compreendendo desde a pesquisa de mercado, a manipulação dos dados originais até o preenchimento da casa. Para tando, seguiu-se os passos da metodologia desenvolvida por PEIXOTO (1998) que conjuga os diferentes métodos dos principais autores sobre QFD e inova-os no aspecto do desdobramento das falhas potenciais do produto. Como se limitou apenas à Casa da Qualidade, o QFD na Fábrica Integrada modelo (FIM) é utilizado apenas como uma ferramenta para introduzir a "voz do cliente" no processo de desenvolvimento do produto. Essa é uma aplicação alternativa do QFD, muito encontrada na literatura e em casos reais em empresas.
Caso 2 de aplicação: Exemplo do desdobramento de alguns requisitos de uma impressora
Este é um exemplo didático em uma apresentação power point, que mostra passo a passo como foi sendo desenvolvido o QFD de uma impressora. A matriz vazia e depois completa utilizada como material didático de apoio também estão disponíveis
  • Apresentação power point com o passo a passo
  • Matriz vazia
  • Matriz preenchida
Recomendações para aplicação
O texto a seguir foi adaptado do livro sobre QFD do Prof. Cheng. Primeiramente deve-se saber se a empresa conhece o potencial do QFD ou não. Caso ela conheça deve-se colocar a pergunta o que se pretende atingir com o QFD?. Se a respostar estiver relacionada com a fase de pré-desenvolvimento, quando o planejamento estratégico da empresa é desdobrado em um portfólio de projetos de desenvolvimento, com grande integração entre a áreas de marketing, engenharia e diretoria, deve-se empregar somente a casa da qualidade. No entanto, quando o produto for muito inovador, as informações dessa matriz devem ser aprimoradas durante a fase de projeto informacional e conceitual, após a aprovação do desenvolvimento do produto e levantamento de informações de mercado mais focadas para aquele produto. Se for durante a fase de projeto de desenvolvimento, deve-se construir um modelo conceitual que abranja as atividades e níveis de detalhamento desejados. Conforme as dimensões que se deseja desdobrar, mais refinado deve ser o modelo conceitual. Um cuidado a ser tomado aqui é começar pequeno, ou seja, utilizar inicialmente uma matriz e conforme o time de desenvolvimento adquirir experiência, mudar de patamar de maturidade e aplicar outras matrizes. Deve-se focar nos elementos e parâmetros críticos do produto para não aumentar desnecessariamente o tamanho das tabelas e matrizes. Essa é uma causa frequente do fracasso na aplicação de QFD. Outras recomendações mais específicas podem ser consultadas no livro de QFD do Prof. Cheng (resumidas na tabela 2.16 do próprio livro).
Benefícios da aplicação do QFD no desenvolvimento de produtos
  • Foco no consumidor;
  • Considera a concorrência;
  • Registro das informações;
  • Interpretações convergentes das especificações;
  • Redução do tempo de lançamento e reparos após o lançamento;
  • Seu formato visual ajuda a dar foco para a discussão do time de projeto, organizando a discussão;
  • Aumenta o comprometimento dos membros da equipe com as decisões tomadas;
  • Os membros da equipe desenvolvem uma compreensão comum sobre as decisões, suas razões e implicações.
Novas contribuições para essa página são bem vindas
Esperamos algumas contribuições para registrar alguns casos reais de aplicação. Estamos ainda compilando algumas aplicações de publicações existentes para inserir aqui. Os anais dos congressos de QFD e do CBGDP do IGDP trazem o relato de muitas aplicações. Conforme forem sendo inseridas neste portal novas publicações sobre aplicações, iremos colocar o link nessa seção. Mas você pode procurar neste site outros conteúdos relacionados com QFD, clicando nas palavras chave relacionadas.
Como aprender: roteiro de estudo
Existem muitas possibilidades de estudo do QFD, dependendo do foco de sua aplicação. Por enquanto vamos colocar um roteiro genérico. Roteiro de estudo 1: Vamos descrever aqui uma aplicação abrangente e atual, mas com foco na aplicação do método QD (quality deployment).
  1. Obtenha as informações e gerais iniciais estudando a melhor prática QFD deste site, considerando como uma introdução sobre o assunto..
  2. Estude os capítulos 2.4.1; 4; 5; 6; 7 e 8 do livro sobre QFD do Prof. Cheng (esse material é bem completo e detalhado)
  3. Selecione alguns dos casos presentes no mesmo livro, que possa estar relacionado com o seu problema para estudar em maior profundidade
  4. Tente utilizar o material para download deste site para exercitar a realização da (primeira) casa de qualidade e analise os casos colocados aqui.
Especialistas
O Prof. Cheng é o maior especialista brasileiro em QFD. Confira o registro deste especialista neste site.
Instituições, eventos e sites
  • QFD Institute - Instituto formado em 1993 para divulgar o QFD.
  • Veja a definição de QFD na Wikipedia, que apresenta diversos outros links relacionados com o tema.
Softwares para aplicação do QFD
  • O QFD designer é o software mais conhecido de QFD. A empresa distribuidora deste software no Brasil é a Vicente Luz Consultores Associados Ltda.
  • Muitas aplicações são realizadas com planilhas excell, como o próprio exemplo para download deste site.
  • A solução da Sigma zone integra o QFD com FMEA e critérios de seleção de Pugh
  • Esta empresa possui vários templates para aplicação de QFD
Cursos on line e outras fontes de ferramentas QFD gratuitas
  • Existem muitas opções. Digite no google QFD e excell para conhecer muitas opções
  • Este tutorial de como preencher a (primeira) casa da qualidade é simples e bem feito em flash.
  • Neste site pode-se entrar em contato com uma comunidade relacionado ao QFD e ter acesso a tutoriais e templates de matrizes de QFD
Melhores práticas relacionadas
Por enquanto, como estamos ainda iniciando a inserção de conteúdo no portal de conhecimentos, vou listar somente algumas melhores práticas que utilizam o QFD, mas no futuro pretendemos associar com hyperlinks, conforme o conteúdo for inserido. As seguintes melhores práticas podem estar relacionadas com o QFD.
  • Planejamento estratégico
  • Planejamento estratégico de produtos
  • Matriz de Pugh
  • Gerenciamento de parâmetros críticos de produto
  • Processo de desenvolvimento de produtos
  • Gestão do desenvolvimento de produtos
  • Gestão da qualidade total
  • TRIZ - Teoria da Solução Inventiva de Problemas
  • FMEA (failure mode and effect analysis) - análise do modo e efeito de falhas
  • FTA (failure tree analysis) - análise da árvore de falhas
  • VCO (voice of customer) - voz do cliente (integrada normalmente à casa de qualidade)
  • DFSS (design for six sigma)
E outros que vamos inserir no futuro
Publicações importantes e referências citadas na descrição
OHFUJI, T.; MICHITERU, O; AKAO, Y. (1997). Método de desdobramento da qualidade (1): elaboração e exercício da matriz da qualidade. Belo Horizonte: Escola de Engenharia da UFMG. ( Manual de aplicação do desdobramento da função da qualidade, v. 1). ( Disponível na biblioteca da EESC - USP ). OHFUJI, T.; MICHITERU, O; AKAO, Y. (1997). Método de desdobramento da qualidade (1): elaboração e exercício da matriz da qualidade. Belo Horizonte: Escola de Engenharia da UFMG. ( Manual de aplicação do desdobramento da função da qualidade, v. 2). ( Disponível na biblioteca da EESC - USP ). CHENG, L. C. (1995). CHENG, L.C.; MELO FILHO, L.D.R. Desdobramento da função qualidade na gestão do desenvolvimento de produtos. São Paulo, Editora Blücher, CLAUSING, D. (1994). Total quality development: a step by step guide to world class concorrent engineering. New York: ASME press. ( t: 322 ).
Material para download
Por enquanto temos somente um método de QFD e suas ferramentas correspondentes para download gratuito.
Método 1: Método para confecção da casa da qualidade
Arquivos principais
Descrição Arquivo para Download
Roteiro de aplicação da primeira casa da qualidade do QFD: Contém os passos para a criação da primeira casa da qualidade, indicando quais os outros documentos a serem aplicados, e também uma lista de lições aprendidas.
Planilha da casa da qualidade: É uma planilha Excell associada ao roteiro, que contém algumas regras automáticas, descritas no roteiro.
Arquivos auxiliares (são arquivos citados no roteiro)
Descrição Arquivo para Download
Critérios para aplicação do QFD (1ª casa da qualidade): Critérios gerais para auxiliar o preenchimento da planilha, indicando padrões de valores relacionados com o cálculo da importância geral do requisito do cliente; benchmarking dos requisitos dos produtos concorrentes; definição do argumento de venda; e as fórmulas para cálculo do índices que resultam no peso do requisito do cliente (cálculos efetuados automaticamente pela planilha).
Critérios de Kano: Checklist para definir a categoria do requisito e respectivo valor, que entra no cálculo da importância do requisito.
Matriz de transformação de requisitos do cliente em requisitos do produto
Critérios para definir o grau de dificuldade técnica e a reutilização
Exemplo de aplicação
Descrição Arquivo para Download
Exemplo 1: É a planilha da casa da qualidade preenchida com um exemplo de um produto fictício de um despertador de cabeceira, com um dispositivo para ser colocado no travesseiro e assim não acordar, ao despertar, outras pessoas que estejam no mesmo ambiente (realizados por alunos do curso SEP 171 na USP em 2005).
Exemplo didático passo a passo em power point
Descrição Arquivo para Download
Apresentação Power Point didática que acompanha passo a passo a aplicação da planilha QDF com base no roteiro (M001-A01). É mais abrangente que a propria aplicação do QFD, pois apresenta uma possibilidade de se transformar a voz dos clientes (necessidades) em requisitos dos clientes. Somente após a definição desses requisitos é que se começa a trabalhar com a planilha.
Você pode fazer o download total de todo o material existente aqui para aplicação prática desse método de QFD.
Descrição Arquivo para Download
Todo o material existente aqui para aplicação prática
QS-9000 - ISO/TS 16949 http://www.portaldeconhecimentos.org.br/index.php/content/view/full9672
Introdução
Para garantir a qualidade de seus produtos a indústria automobilística desenvolveu normas para seus fornecedores como, por exemplo, os procedimentos: Chrysler's Supplier Quality Assurance Manual, Ford's Q-101 Quality System Standards e General Motors' NAO Target for Excellence. A existência de inúmeras normas gerava, para os fornecedores, esforços desnecessários para atender a todos os requisitos. Muitas vezes, duas normas exigiam praticamente o mesmo documento, porém com diferente formatação. Em outros casos algumas empresas exigiam procedimentos extremamente burocráticos sendo que outras já utilizavam soluções mais eficientes. Em 1988, durante a conferência da Divisão Automotiva da ASQC (American Society for Quality Control), foi criada uma equipe de trabalho para discutir as preocupações dos fornecedores com relação à duplicação de esforços e de documentação necessária para satisfazer às exigências das três maiores indústrias automotivas norte-americanas. Este grupo trabalhou na harmonização dos procedimentos de qualidade das Big Three (Chrysler, Ford e GM) e desenvolveu a norma QS-9000 como uma interpretação da ISO-9000 para o setor automotivo.
Objetivo
O objetivo da QS-9000 foi de definir os requisitos fundamentais de qualidade dos fornecedores, internos ou externos, de peças, serviços e materiais para a Chrysler, Ford e General Motors, proporcionando melhoramento contínuo e enfatizando prevenção de defeitos, redução de variações, diminuição de refugo e redução de custos. Portanto a QS-9000 é dirigida para garantir a qualidade mais alta possível com o menor aumento de custos que não agregam valor ao produto, homogeneizando os requisitos específicos das empresas (Big Three) e dividindo por toda a cadeia produtiva a responsabilidade sobre a documentação e garantia da qualidade. Na uniformização proposta através da QS-9000 foram editados manuais de referência para os fornecedores:
  • QS-9000 - Quality System Requirements
A QS-9000 é dividida em três seções: Seção 1 - Requisitos Comuns: é constituída do texto exato da ISO 9001 com requisitos adicionais da indústria automobilística e dos fabricantes de caminhões; Seção 2 - Requisitos Adicionais: inclui requisitos além do escopo da ISO-9000 e específicos do setor automotivo como, por exemplo, o PPAP (Production Part Approval Process - Processo de Aprovação de Produção de Peça); Seção 3 - Requisitos Específicos dos Clientes: contém requisitos únicos de cada uma da três montadoras que continuam existindo num nível inferior de informações como, por exemplo, símbolos de itens de segurança ou peças críticas.
  • Advanced Product Quality Planning and Control Plan (APQP)
Estabelece as etapas, procedimentos e documentação necessários, durante o desenvolvimento do produto, para assegurar a qualidade exigida pelo cliente. É um modelo de referência para o processo de desenvolvimento de produto a ser adotado pelas fornecedoras das montadoras automobilísticas. Com base neles as indústrias fornecedoras definem os seus processos padrão para desenvolvimento de produto (veja item abaixo sobre o APQP).
  • Failure Mode and Effects Analysis (FMEA)
Define uma metodologia e um padrão para a aplicação do FMEA, procurando diagnosticar potenciais falhas que poderiam influenciar a performance do produto.
  • Measurement Systems Analysis
Determina os requisitos necessários para a avaliação dos meios de medição.
  • Fundamental SPC
Define procedimentos para o controle estatístico dos processos. Production Part Approval Process (PPAP) Este manual contém os requisitos necessários para a elaboração do Processo de Aprovação de Produção de Peça (PAPP em português).
  • Quality System Assessment (QSA)
Contém os requisitos de conformidade da norma QS-9000.
A QS 9000 não existe mais !!
A QS 9000 que foi criada no âmbito da Automotive Industry Action Group (veja link abaixo) para atender às três grandes montadoras americanas Chrysler, Ford e General Motors. Algumas montadoras européias quiseram adotar a QS 9000 e levaram para a ISO. Hoje a QS 9000 foi substituída pela ISO TS 16949.
Informações adicionais
The Automotive Industry Action Group http://www.aiag.org/ : Associação Norte Americana dos motadores de veículos e dos fornecedores da indústria automobilística, que foi determinante para a criação da QS 9000 e que hoje adotou a TS 16949. Bureau Veritas Quality International (BVQI) http://www.bvqina.com/qs9000.html : É um órgão certificador de várias normas incluindo a TS 16949.
Advanced Product Quality Planning and Control Plan (APQP)
Como está escrito acima o APQP é um modelo de referência a ser adotado por fornecedoras da indústria automotiva. Veja informações adicionais sobre esse modelo a seguir. Site sobre o APQP em português http://www.apqp.com.br/website/index.html : Neste site pode-se ler sobre a história e os principais conceitos sobre o APQP. Na verdade é um site de um software que apóia a implementação do APQP (o quality manager). Para uma visão introdutória vale a pena ler. APQP na wikipedia http://en.wikipedia.org/wiki/Advanced_Product_Quality_Planning : O verbete sobre APQP na wikipedia em inglês é bem sucinto e completo.
A VW usa a norma VDA 6.3 no lugar da APQP
Veja neste fórum a explicação da diferença entre a VDA 6.3 e a APQP http://elsmar.com/Forums/showthread.php?t=8063
Set-Based Concurrent Engineering (SBCE) http://www.portaldeconhecimentos.org.br/index.php/content/view/full9636
Definições
Segundo ROZENFELD, et al. (2006), a abordagem da Engenharia Simultânea é tratada no processo de desenvolvimento convencional como uma forma de eliminar a prática de “atirar por sobre o muro” (uma atividade após a outra) ou a engenharia ponto-a-ponto, e evoluir em direção ao processamento paralelo de atividades. Entretanto, as empresas ocidentais que adotaram o desenvolvimento paralelo não quebraram o paradigma da engenharia ponto-a-ponto, pois a prática básica permanece a mesma – o time continua interagindo com uma única solução (gerada na fase conceitual). No processo de desenvolvimento convencional, o plano é seguido até que ocorra uma falha ou problema, qualquer que seja a razão, então se segue uma série de loop-backs iterativos, ou modificação de planos e recursos. Com isso, durante a execução, os resultados do trabalho executado são empurrados através das atividades (KENNEDY, 2003). A visão sistêmica da solução (e muitas vezes só de parte dela) só é conseguida nos phase gates. Esses gates, além de representarem represas de informação, muitas vezes levam a esperas e estoques desnecessários (SOBEK, et al. 1999). A abordagem SBCE difere significativamente desse processo a equipe conduz o processo sem definir um conceito inicial, mas sim vários. Os participantes do desenvolvimento pensam, desenvolvem e comunicam conjuntos de soluções em paralelo e relativamente independentes. Conforme o projeto progride, o time de desenvolvimento vai gradualmente restringindo essas soluções, baseando-se no conhecimento que é agregado ao projeto durante o seu desenvolvimento. Focar na convergência a partir de várias possibilidades, em vez de refinar uma única boa idéia para otimizá-la, permite que os atores trabalhem em conjunto, diminuindo significativamente a quantidade de correções e retrabalhos no processo. Segundo SOBEK, et al. (1999), O objetivo da SBCE é: (1) evitar o abandono prematuro de boas idéias para garantir uma eficiência do planejamento; (2) reduzir os riscos e o retrabalho e a sensação de “correr atrás do planejamento”. Assim, comparado com o desenvolvimento de uma alternativa única, o SBCE reduz, na prática, o tempo de desenvolvimento. A SBCE estende o conceito da engenharia simultânea para permitir o atraso de decisões de modo a manter opções de projeto em aberto até que seja estritamente necessário defini-las (WALTON, 1999). O projeto baseado em conjuntos é: um ciclo de desenvolvimento simples e repetitivo que consegue alta inovação em produtos e sistemas de manufatura, evitando o risco através de redundância, robustez e captura de conhecimento (KENNEDY, 2003). A equipe de desenvolvimento, portanto, não define especificações rígidas no início do projeto, ao invés disso, estabelecem um conjunto de possibilidades para cada subsistema do produto (sistema), muitas das quais são carregadas até estágios avançados do projeto (WARD et al, 1995). Esses conjuntos consideram todas as perspectivas funcionais e de manufatura, criando uma redundância ao risco, ao mesmo tempo em que mantém flexibilidade. O projeto final do sistema é desenvolvido através da combinação sistemática e estreitamento desses conjuntos, onde as alternativas são descartadas de acordo com o aumento do conhecimento e da confiança (KENNEDY, 2003). A Figura 1 ilustra de maneira esquemática o projeto “ponto-a-ponto” e o projeto baseado em conjuntos. Figura 1 – Projeto “ponto-a-ponto” e projeto baseado em conjuntos De acordo com SOBEK, et al. (1999) a essência da SBCE está fundamentada em três princípios, apresentados a seguir:
  • Mapear o espaço de projeto
  • Integrar pela intersecção
  • Estabelecer a exeqüibilidade antes do comprometimento
O mapeamento do espaço de projeto corresponde a identificação do conjunto de alternativas ou faixa de valores que serão levados adiante. Todos os envolvidos no projeto são liberados para desenvolver o seu trabalho, conquanto que fiquem dentro de determinados limites, isto é, o seu espaço de projeto. A integração pela intersecção significa procurar por soluções dentro das intersecções dos conjuntos ou intervalos dos valores. Estabelecer a exeqüibilidade antes do comprometimento refere-se a obrigação de todos os envolvidos manterem a consistência com o projeto pré-existente. A abordagem SBCE depende da implementação integrada e conjunta das ações relacionadas aos princípios. Entretanto, esforços para implementar apenas alguns princípios falharão, pois o sistema deve ser altamente integrado. A mudança para um ambiente distribuído e simultâneo deveria envolver uma mudança correspondente no método de projeto para um processo baseado em conjuntos. Apesar de parecer que o Toyota Product Development System é “aberto”, ele é bastante padronizado. A padronização passa pelos aspectos relacionados aos padrões de competências para o desenvolvimento de um projeto, pelos processos de trabalho e pelos padrões de projeto. A prática de padronização e a atenção gerencial aos processos sociais que estão envolvidos no processo de desenvolvimento permitem que a Toyota alcance um impressionante nível de integração (ROZENFELD, et al. 2006).
Fontes
ROZENFELD, H.; FORCELLINI, F. A.; AMARAL, D.C.; TOLEDO, J.C.; SILVA, S.L.; ALLIPRANDINI, D.H.; SCALICE, R.K.. Gestão de Desenvolvimento de Produtos: uma referência para melhoria do processo. São Paulo: 542p, Editora Saraiva, 2006. SOBEK, D. K.; WARD, A. C.; LIKER, J. K. Toyota’s principles of set-based engineering. Boston: Sloan Management Review, winter 1999. KENNEDY, M. N.. Product development for the lean enterprise. Richmond: Oaklea Press, 2003. WALTON, M. Strategies for Lean Product Development: A Compilation of Lean Aerospace Initiative Research. Cambridge: Massachusetts Institute of Technology, 1999. (Research Paper 99-02). WARD, A. C.; LIKER, J.K.; CRISTIANO, J.J.; SOBEK II, D.K.. The second Toyota paradox: how delaying decisions can make better cars faster. Boston: Sloan Management Review, spring 1995.
Simplify da Tomoye http://www.portaldeconhecimentos.org.br/index.php/content/view/full9951 Conjunto de princípios e práticas que caracterizam a habilidade da organização, de forma consistente, criar novos conhecimentos, disseminá-los e incorporá-los em novos produtos e processos. O conhecimento é visto como um ativo corporativo que deve ser gerido como outros ativos mais tangíveis, por meio da definição de princípios, processos e infra-estrutura. Sistemas ERP http://www.portaldeconhecimentos.org.br/index.php/content/view/full10006
Introdução
Com o avanço da Tecnologia da Informação as empresas passaram a utilizar sistemas computacionais para suportar suas atividades. Geralmente, em cada empresa, vários sistemas foram desenvolvidos para atender aos requisitos específicos das diversas unidades de negócio, plantas, departamentos e escritórios. Por exemplo, o departamento de planejamento da produção utiliza um sistema próprio e o departamento de vendas utiliza outro. Dessa forma, a informação fica dividida entre diferentes sistemas. Os principais problemas dessa fragmentação da informação são a dificuldade de obtenção de informações consolidadas e a inconsistência de dados redundantes armazenados em mais de um sistema. Os sistemas ERP ( Enterprise Resource Planning) solucionam esses problemas ao agregar, em um só sistema integrado, funcionalidades que suportam as atividades dos diversos processos de negócio das empresas. Os sistemas ERP surgiram a partir da evolução dos sistemas MRP ( Material Resource Planning). Neles, foram agregados as funções de programação mestre da produção, cálculo grosseiro de necessidades de capacidade, cálculo detalhado de necessidade de capacidade, controle do chão de fábrica, controle de compras e, mais recentemente, Sales & Operations Planning. Dessa forma, os sistemas MRP deixaram de atender apenas as necessidades de informação referentes ao cálculo da necessidade de materiais, para atender às necessidades de informação para a tomada de decisão gerencial sobre outros recursos de manufatura. O MRP passou, então, a ser chamado de MRP II ( Manufacturing Resource Planning - Planejamento de Recursos de Manufatura). Com o objetivo de ampliar a abrangência dos produtos vendidos, os fornecedores de sistemas desenvolveram mais módulos, integrados aos módulos de manufatura, mas com escopo que ultrapassa os limites da manufatura. Como exemplo, foram criados os módulos de Gerenciamento dos Recursos Humanos, Vendas e Distribuição, Finanças e Controladoria, entre outros. Esses novos sistemas, capazes de suportar as necessidades de informação para todo o empreendimento, são denominados sistemas ERP.
Estrutura típica dos sistemas ERP
Os sistemas ERP são compostos por uma base de dados única e por módulos que suportam diversas atividades das empresas. A figura abaixo apresenta uma estrutura típica de funcionamento de um sistema ERP. Os dados utilizados por um módulo são armazenados na base de dados central para serem manipulados por outros módulos. Figura 1 - Estrutura típica de fucionamento de um sistema ERP (DAVENPORT, 1998) Os módulos citados na figura acima estão presentes na maioria dos sistemas ERP. Além deles, alguns sistemas ERP possuem módulos adicionais, tais como: Gerenciamento da Qualidade, Gerenciamento de Projetos, Gerenciamento de Manutenção, entre outros.
Implantação de sistemas ERP
As funcionalidades dos módulos de um sistema ERP representam uma solução genérica que reflete uma série de considerações sobre a forma que as empresas operam em geral. Para flexibilizar sua utilização em um maior número de empresas de diversos segmentos, os sistemas ERP foram desenvolvidos de forma que a solução genérica possa ser customizada em um certo grau. Na implantação de um sistema ERP, a customização é um compromisso entre os requisitos da empresa e as funcionalidades disponíveis no sistema. Inicialmente, na maioria das vezes, os processos de negócio das empresas precisam ser redefinidos para que seus requisitos se aproximem das funcionalidades do sistema. Então, a primeira medida de customização é a seleção dos módulos que serão instalados. A característica modular permite que cada empresa utilize somente os módulos que necessite e possibilita que módulos adicionais sejam agregados com o tempo. Em seguida, para cada módulo, são feitos ajustes nas tabelas de configuração para que o sistema se adeque da melhor forma possível aos novos processos de negócio. Mesmo com a customização, a solução pode não atender a alguns requisitos específicos das empresas. Nesses casos, as empresas precisam utilizar outros sistemas complementares ou abandonar seus requisitos específicos e adotar processos genéricos. Por esse motivo, a decisão de implantação de um sistema ERP só deve ser tomada após uma análise detalhada dos processos da empresa e das funcionalidades dos sistemas ERP. Além disso, é muito importante que as empresas considerem, desde o início da implantação, os impactos que a redefinição dos processos e a introdução do sistema terão na estrutura, cultura e estratégia da organização.
Benefícios da utilização de sistemas ERP
As utilização de sistemas ERP otimiza o fluxo de informações e facilita o acesso aos dados operacionais, favorecendo a adoção de estruturas organizacionais mais achatadas e flexíveis. Além disso, as informações tornam-se mais consistentes, possibilitando a tomada de decisão com base em dados que refletem a realidade da empresa. Um outro benefício da implantação é a adoção de melhores práticas de negócio, suportadas pelas funcionaldades dos sistemas, que resultam em ganhos de produtividade e em maior velocidade de resposta da organização.
Utilizção de sistemas ERP no processo de desenvolvimento de produtos
Apesar de não possuírem um módulo específico para o processo de desenvolvimento de produtos, os sistemas ERP tem diversas funcionalidades que suportam as atividades desse processo dispersas entre seus módulos. Entre essas funcionalidades estão: gerenciamento de dados de produtos, gerenciamento da BOM( Bill of Materials), planejamento de processo macro, APIs para sistemas CAD( Computer Aided Design) e gerenciamento de fluxo de trabalho. Na aplicação de sistemas ERP no desenvolvimento de produtos, devem ser analisadas as sobreposições de funções entre esses sistemas e os sistemas de engenharia (CAD/CAE/CAM/CAPP/PDM) e exploradas as possibilidades de integração entre eles.
Sobreposição de funções e integração entre sistemas ERP e PDM
Em geral, as sobreposições de funções entre sistemas ERP e PDM são: Gerenciamento da Estrutura de Produto ou BOM, Gerenciamento de Mudanças de Produto, e Gerenciamento dos Dados e Características do Produto. O ponto comum de uma possível integração entre sistemas ERP e PDM é a Estrutura de Produto (BOM). Com a sobreposição de funções, o problema é como se obter vantagens competitivas na passagem dos dados da engenharia para a manufatura. Ainda não existe uma abordagem definida, mas algumas soluções possíveis são:
  • Transmissão, em uma direção, dos dados da BOM para o sistema ERP utilizando APIs ( Application Program Interface) dos fornecedores de pacotes;
  • APIs bidirecionais nas quais o ERP envia para o sistema PDM informações necessárias para a análise de custo e modificações;
  • Possibilitar que o ERP obtenha a BOM diretamente do PDM quando esta for criada e mantenha estes dados com status de “em projeto” até que a atividade esteja completada. Enquanto isso os dados ficam sobre o controle do PDM.
Um dos benefícios de uma efetiva integração entre sistemas ERP e PDM deve ser a eliminação de dados redundantes e a redução do ciclo de transferência de dados da engenharia para a manufatura. Deve-se observar que, atuamente, alguns sistemas ERP estão incorporando às suas soluções funcionalidades completas de um sistema PDM, distribuídas ao longo de seus módulos.
Sobreposição de funções e integração entre sistemas ERP e CAPP
A sobreposição de funções entre sistemas ERP e CAPP ocorre nas informações sobre seqüência de operações de fabricação, equipamentos utilizados e tempos (plano de processo macro). Geralmente, os sistemas ERP dispõe de um módulo de Apoio à Gestão de Produção em Processos, no qual são geradas as informações do plano macro. Estas informações são básicas para o funcionamento do sistema. No entanto, os sistemas ERP não têm podem gerar e gerenciar todos os detalhamentos do plano de processo necessários em um ambiente de Engenharia Simultânea. Para gerar e gerenciar os detalhamentos do plano macro (FMEA, Plano de Controle, Condições de Usinagem, Ferramental, entre outros) é necessária a utilização de sistemas CAPP. Como no caso da integração entre sistemas PDM e ERP, ainda não existe uma abordagem definida para a integração entre CAPP e ERP. Atualmente a transferência dos dados da engenharia para a produção muitas vezes ocorre por duplicação de atividades ou ainda por digitação dos dados no sistema ERP.
Artigos
DAVENPORT, T.H. (1998). Putting the enterprise into the enterprise system. Harvard Business Review. Julho-Agosto, p.121-131. (t: 827).
Livros
CORRÊA, H.L.; GIANESI, I.G.N.; CAON, M. (1997). Planejamento, programação e controle da produção: MRP II / ERP: conceitos, uso e implantação. São Paulo: Atlas. ( Disponível na biblioteca da EP - USP ). CURRAN, T; KELLER, G.; LADD, A. (1997). SAP R/3 business blueprint: Understanding the Business Process Reference Model. Prentice Hall. KELLER, G.; TEUFEL, T. (1998). SAP R/3 process oriented implementation: Iterative Process Prototyping. Addison-Wesley. KIRCHMER, M. (1998). Business process oriented implementation of standard software. Springer-Verlag. LAUDON, K. C.; LAUDON, J. P. (1998). Management information systems. Upper Saddle River: Prentice Hall. ( Disponível na biblioteca da FEA - USP ).
Software
Fornecedores de sistemas ERP: Baan – http://www.baan.com Datasul - http://www2.datasul.com.br/ JD Edwards - http://www.jdedwards.com/ Microsiga - http://www.microsiga.com.br/ MKGroup (Computer Associates) - http://www.mkgroup.com/ Oracle - http://www.oracle.com/applications/ Peoplesoft - http://www.peoplesoft.com/ SAP - http://www.sap.com/ SENIOR SISTEMAS - http://www.senior.com.br/ eGESTOR - http://www.egestor.com.br
Sistemas de Classificação e Tecnologia de Grupo http://www.portaldeconhecimentos.org.br/index.php/content/view/full10014
Introdução
A Tecnologia de Grupo (TG) é uma filosofia de manufatura na qual peças ou outros objetos (planos de processo, produtos, montagens, ferramentas, etc.) similares são identificados e agrupados para se aproveitar as vantagens de suas similaridades nas diversas atividades da empresa (projeto, manufatura, compras, planejamento e controle da produção, etc.). Segundo HYER & WEMMERLÖV (1984) o aproveitamento dessas similaridades ocorre de três maneiras:
  • executando atividades similares em conjunto, evitando assim perda de tempo com as alterações necessárias para mudar de uma atividade para outra não relacionada (ex.: a fabricação em seqüência de duas peças com características similares reduz tempo de setup entre as operações);
  • padronizando as atividades similares e relacionadas, focando assim apenas nas diferenças necessárias e impedindo duplicação de esforços (ex.: redução da variedade de parafusos utilizados);
  • armazenando e recuperando informações de forma eficiente, principalmente as relacionadas com um problemas repetidos, reduzindo assim o tempo de procura por informações, bem como eliminando a necessidade de resolver novamente um problema já solucionado (ex.: utilizar em um novo produto, componentes de um outro já existente);
  • realizando as atividades acima estar-se-á também reduzindo a proliferação desnecessária de novos itens (peças compradas e fabricadas, dispositivos de fixação, ferramentas, etc.).
A Tecnologia de Grupo reúne os objetos com atributos similares em famílias, que são definidas por TATIKONDA & WEMMERLÖV (1992) como uma coleção de objetos que dividem características específicas (de projeto, manufatura, compras, etc.) identificadas para um propósito bem definido. Todos os objetos em uma família requerem métodos similares de tratamento e manuseio, e os ganhos de eficiência são atingidos pelo processamento conjunto dessas peças. O projeto e a manufatura são os principais campos de aplicação da TG. Na manufatura os ganhos de eficiência vêm da: redução dos tempos de setup, programação em seqüência de peças de uma mesma família, melhoria no controle do processo, planos de processo e instruções padronizadas, formação de células de manufatura e aumento da qualidade. As vantagens no projeto são obtidas principalmente da recuperação de informações, da padronização de itens e conseqüente não proliferação desses itens. Por exemplo, quando os engenheiros recuperam desenhos existentes para suportar novos produtos e quando peças são padronizadas para prevenir sua proliferação. Segundo TATIKONDA & WEMMERLÖV (1992), três tipos de atividades são necessárias na implementação da TG:
  • determinação dos atributos críticos dos objetos que representarão o critério para esse pertencer ou não a uma família;
  • alocação dos objetos para as famílias estabelecidas;
  • recuperação dos membros da família e as informações relativas;
  • representação da família e suas classes por atributos sob a forma de códigos ou numa base de dados relacional.
Na execução dessas atividades de implementação da Tecnologia de Grupo, os sistemas de classificação surgem como uma poderosa ferramenta de auxílio. Segundo TATIKONDA & WEMMERLÖV (1992), os Sistemas de Classificação podem assistir a Tecnologia de Grupo nas atividades de implementação fornecendo uma estrutura para classificar os objetos em famílias baseada em atributos selecionados para esses objetos. Diversos Sistemas de Codificação e Classificação (SCC) foram desenvolvidos nas últimas décadas, sendo selecionados de acordo com as necessidades de cada empresa, não existindo um sistema universal. Esses sistemas iniciaram com o uso de códigos alfanuméricos, porém com o avanço da tecnologia da informação alguns deles têm representado as características das peças através de atributos em bases de dados relacionais. GROOVER (1987) e HYER & WEMMERLÖV (1984), resumem os principais benefícios de um SCC bem projetado:
  • formação de famílias de peças e células de máquinas (utilização pouco empregada atualmente, uma vez que já existem algoritmos matemáticos específicos e mais eficientes para esse tipo de aplicação; por ex.: algoritmo genético);
  • recuperação efetiva e rápida de desenhos, projetos e planos de processos;
  • racionalização e redução de custos em projetos;
  • padronização do projeto do produto;
  • estatísticas de peças seguras e confiáveis;
  • estimativa acurada dos requisitos das máquinas-ferramenta, carga de máquina racionalizada e gastos otimizados de capital;
  • racionalização de ferramental e redução do tempo de preparação da máquina e do tempo total de produção;
  • racionalização do projeto do ferramental e redução do tempo e do custo do projeto e fabricação do ferramental;
  • padronização de processos e ferramental;
  • racionalização do planejamento e programação da produção;
  • contabilidade de custos e estimativa de custos mais acuradas;
  • melhor utilização das máquinas-ferramenta, dispositivos e mão-de-obra;
  • melhoria da programação do NC, e uso efetivo de máquinas e centros de usinagem;
  • estabelecimento de uma base de dados principal.
Na utilização de Sistemas de Classificação, para apoio à implementação da Tecnologia de Grupo, é importante que a estrutura de classificação atenda aos objetivos de aplicação, e sejam flexíveis para suportar futuras alterações no produto ou introdução de novos de produtos, novas tecnologias de produto e processo, e integração da base de dados. A habilidade dos sistemas de classificação mais recentes (os quais não utilizam códigos) de armazenar os atributos exatos da peça em base de dados relacional aumenta muito a flexibilidade e a facilidade de uso, mas não reduz a importância de decidir qual dado deve ser capturado. Com o advento dos sistemas gerenciadores de base de dados relacional, os princípios acima expostos puderam ser adotados, fazendo com que os SCC baseados em códigos de muitos dígitos caíssem em desuso, pois ele era dúbio e a classificação de um produto dependia em demasia da habilidade da pessoa que o codificou. Além disso esses códigos não permitiam uma evolução dos critérios adotados para o significado de um dígito. Se um dígito, por exemplo, representasse uma faixa de valor de uma dimensão, essa faixa deveria ser sempre significativa para empresa. O código não serviria, se houvesse uma necessidade de se identificar produtos com diferentes valores de dimensão dentro daquela faixa. Isso é eliminado com o uso de base de dados, pois o valor exato de cada produto é armazenado e a busca pode ser mais precisa. Hoje estão surgindo sistemas de gerenciamento de componentes e suprimentos (CSM - component supplier management), que oferecem o suporte para busca de componentes além de uma empresa específica. Isto promete revolucionar a busca por componetes semelhantes no desenvolvimento de produto (vide sites relacionados) Muita confusão tem ocorrido entre a Tecnologia de grupo (TG), e os sistemas de classificação e o projeto de células de manufatura. Deve estar bem claro que o sistema de classificação é um meio para a implantação da TG, e a célula de manufatura é uma das aplicações de TG.
Artigos
GROOVER, M.P. (1987). Automation, production systems, and computer integrated manufacturing. Englewood Cliffs: Prentice Hall. ( Disponível na biblioteca da EESC - USP ). HYER, N. L.; WEMMERLÖV, U. (1984). Group technology and productivity. Harvard Business Review, v.62, n.4, p.140-149. (t:835) TATIKONDA, M.V.; WEMMERLÖV, U. (1992). Adoption and implementation of classification and coding systems: insights from seven case studies. International Journal of Production Research, v.30, n.9, p.2097-2110. (t:834). HYER, N. L.; WEMMERLÖV, U. (1985). Group technology oriented coding systems: structures, applications, and implementation. Production and Inventory Management, 2nd quarter, p.55-78. (t:859) HYER, N. L.; WEMMERLÖV, U. (1989). Group technology in US manufacturing industry: a survey of concurrent practices. International Journal of Production Research, v.27, n.8, p.1287-1304. (t:833). ROZENFELD, H.; OLIVEIRA, C.B.M. (1997). Codificação e estruturação de produtos em ambientes integrados de manufatura. São Carlos. Máquinas e Metais. (t: 363).
Sites Relacionados
http://www.aspectdv.com/ Aspect Development, Inc. is a software, data content, and services company providing component and supplier management (CSM) solutions to manufacturers. Aspect's client/server software applications and omponent/supplier information databases focus primarily on improving the product development cycle by accelerating time to market, lowering product development costs, and enabling higher quality output through the enterprise-wide sharing and reuse of component, supplier, and design information. http://www.ihs.com/ Information Handling Services (IHS) is the world's largest single source of engineering, technical and regulatory information - all brought to your desktop for fast, easy searching. Whether accessing the information from CD-ROM, the Internet, or online, you are getting the most comprehensive databases available for everything from semiconductors and mil specs to corporate standards and government parts.IHS also provides turnkey electronic document management solutions, webhosting and development, electronic catalog development, document conversion, and professional services http://www.computex.com/ ICI is a major supplier of Component and Supplier Management (CSM) software and services. ICI develops, markets, implements, and supports ItemQuest and ItemWeb CSM software products. These high Return On Investment (ROI) decision support software solutions are revolutionizing the ways manufacturing companies are managingcomponents and suppliers, and are an integral part of effective Supply Chain Management (SCM). ICI's numerous unique capabilities result in unparalleled ROI returns and a multitude of enterprise-wide benefits.
Supply Chain Management http://www.portaldeconhecimentos.org.br/index.php/content/view/full9670
Introdução
Supply Chain Management (SCM - Gestão da Cadeia de Suprimentos) tem representado uma nova e promissora fronteira para empresas interessadas na obtenção de vantagens competitivas de forma efetiva e pode ser considerada uma visão expandida, atualizada e, sobretudo, holística da administração de materiais tradicional, abrangendo a gestão de toda a cadeia produtiva de uma forma estratégica e integrada. SCM pressupõe, fundamentalmente, que as empresas devem definir suas estratégias competitivas e funcionais através de seus posicionamentos (tanto como fornecedores, quanto como clientes) dentro das cadeias produtivas nas quais se inserem. Assim, é importante ressaltar que o escopo da SCM abrange toda a cadeia produtiva, incluindo a relação da empresa com seus fornecedores e clientes, e não apenas a relação com os seus fornecedores. SCM também introduz uma importante mudança no paradigma competitivo, na medida em que considera que a competição no mercado ocorre, de fato, no nível das cadeias produtivas e não apenas no nível das unidades de negócios (isoladas), como estabelece o tradicional trabalho de PORTER (1980). Essa mudança resulta num modelo competitivo baseado no fundamento de que atualmente a competição se dá, realmente, entre "virtuais unidades de negócios", ou seja, entre cadeias produtivas. Atualmente, as mais efetivas práticas na SCM visam obter uma "virtual unidade de negócio", providenciando assim muito dos benefícios da tradicional integração vertical, sem as comuns desvantagens em termos de custo e perda de flexibilidade inerentes à mesma. Uma virtual unidade de negócios é então formada pelo conjunto de unidades (geralmente representadas por empresas distintas) que compõe uma determinada cadeia produtiva, conforme ilustra a Figura 1. Uma unidade de negócios pode então participar de diversas virtuais unidades de negócios, como é o caso, por exemplo, de várias empresas de autopeças que atuam em virtuais unidades de negócios lideradas por grandes montadoras. Figura 1: Competição entre "Virtuais Unidades de Negócios" Em termos práticos, o modelo enfatiza que cada unidade dessa virtual unidade de negócios deve se preocupar com a competitividade do produto perante o consumidor final e com o desempenho da cadeia produtiva como um todo. Isso acarreta numa necessidade de gestão integrada da cadeia produtiva, requerendo um estreitamento nas relações e a criação conjunta de competências distintas pelas unidades (empresas) da mesma. Por exemplo, o modelo de consórcio modular, implementado pela VW e sete fornecedores de autopeças na nova fábrica de caminhões e chassis de ônibus da montadora também pode ser usado para ilustrar o conceito de virtual unidade de negócios. Na nova planta, a parte final da cadeia produtiva foi concentrada num único local para, sobretudo, dar mais competitividade a uma virtual unidade de negócios dentro do negócio ( business) de caminhões e chassis de ônibus (COLLINS et al. 1997; PIRES, 1998 a; PIRES 1998 b).
Objetivos e Práticas da Supply Chain Management
Um objetivo básico na SCM é maximizar e tornar realidade as potenciais sinergias entre as partes da cadeia produtiva, de forma a atender o consumidor final mais eficientemente, tanto através da redução dos custos, como através da adição de mais valor aos produtos finais (VOLLMANN & CORDON, 1996). Redução dos custos tem sido obtida, através da diminuição do volume de transações de informações e papéis, dos custos de transporte e estocagem, e da diminuição da variabilidade da demanda de produtos e serviços, dentre outros. Mais valor tem sido adicionado aos produtos, através da criação de bens e serviços customizados, do desenvolvimento conjunto de competências distintas; através da cadeia produtiva e dos esforços para que, tanto fornecedores como clientes, aumentem mutuamente a lucratividade. Práticas eficazes na SCM têm sido implementadas em todo mundo, as quais têm visado a simplificação e obtenção de uma cadeia produtiva mais eficiente. Resultados positivos têm sido obtidos principalmente através de procedimentos como os listados abaixo.
· Reestruturação e consolidação do número de fornecedores e clientes:
Significa reestruturar (geralmente através de redução) o número de fornecedores e clientes, construindo e aprofundando as relações de parceria com o conjunto de empresas com as quais, realmente, se deseja desenvolver um relacionamento colaborativo e com resultado sinérgico.
· Divisão de informações e integração da infra-estrutura com clientes e fornecedores:
A integração de sistemas de informações/computacionais e a utilização crescente de sistemas como o EDI ( Electronic Data Interchange), entre fornecedores, clientes e operadores logísticos têm permitido a prática, por exemplo, da reposição automática do produto na prateleira do cliente ( Efficient Consumer Response). Tais práticas têm proporcionado, sobretudo, trabalhar com entregas just-in-time e diminuir os níveis gerais de estoques. Também, a utilização de representantes permanentes ( In plant representatives) junto aos clientes tem facilitado, dentre outras coisas, um melhor balanceamento entre as necessidades do mesmo e a capacidade produtiva do fornecedor, bem como uma maior agilidade na resolução de problemas.
· Desenvolvimento conjunto de produtos:
O envolvimento dos fornecedores desde os estágios iniciais do desenvolvimento de novos produtos ( Early Supplier Involvement) tem proporcionado, principalmente, uma redução no tempo e nos custos de desenvolvimento dos mesmos.
· Considerações logísticas na fase de desenvolvimento dos produtos:
Representa a concepção de produtos que facilitem o desempenho da logística da cadeia produtiva, geralmente também envolvendo a escolha de um operador logístico eficiente para administrar a mesma;
· Integração das estratégias competitivas na cadeia produtiva:
Implica na compatibilização da estratégia competitiva e das medidas de desempenho da empresa à realidade e objetivos da cadeia produtiva como um todo.
Outsourcing na Cadeia de Suprimentos
Um outro conceito importante na SCM é o de " outsourcing", o qual começou com áreas tidas como periféricas (como a de informática) e agora chega a áreas como manufatura, manutenção, distribuição e marketing. Outsourcing é uma prática em que parte do conjunto de produtos e serviços utilizados por uma empresa (na realização de uma cadeia produtiva) são providenciados por uma empresa externa, num relacionamento colaborativo e interdependente. A empresa fornecedora desenvolve e continuamente melhora a competência e a infra-estrutura para atender o cliente, o qual deixa de possuí-los total, ou parcialmente. O cliente continua, entretanto, mantendo uma estreita e colaborativa integração com o fornecedor. É importante notar que a visão contemporânea de outsourcing vai além das práticas rotuladas de "sub-contratação" ou "terceirização", freqüentemente conduzidas no Brasil nos últimos anos. Outsourcing significa, essencialmente, a opção por uma relação de parceria e cumplicidade com um ou mais fornecedores da cadeia produtiva, numa decisão tipicamente estratégica, abrangente e de difícil reversão. Por sua vez, sub-contratação (ou terceirização) tem significado apenas um negócio, uma decisão operacional, mais restrita e relativamente de mais fácil reversão. Nos últimos anos o interesse pela SCM tem crescido muito no mundo e no Brasil. Os avanços têm sido muito significativos tanto na área de serviços como na manufatura. Nesta última, onde reside o interesse do NUMA, os maiores desenvolvimentos têm ocorrido na indústria automobilística, a qual tem sido uma das principais responsáveis pela introdução das práticas mais inovadoras e efetivas na área.
Referências Bibliográficas (do texto)
COLLINS, R.S.; BECHLER, K.; PIRES, S.R.I. (1997); Outsourcing in the Automotive Industry: From JIT to Modular Consortia. European Management Journal, Vol. 15, No. 5. PIRES, S.R.I. (1998 a); Gestão da Cadeia de Suprimentos e o Modelo de Consórcio Modular, Revista de Administração-USP, Vol. 33, No.3. PIRES, S.R.I. (1998 b); Managerial Implications of the Modular Consortium Model in a Brazilian Automotive Plant, International Journal of Operations & Production Management, Vol. 18, No. 3. PORTER, M. (1980); Competitive Strategy . New York, Free Press. VOLLMANN, T.E. & CORDON, C. (1996) ; Making Supply Chain Relationships Work. M2000 Business Briefing, Nº 8, IMD, Lausanne.
Artigos na área
AMATO NETO, J. (1996); Globalsourcing e padrões de fornecimento no complexo automobilístico brasileiro. Anais do 16º ENEGEP, Piracicaba, Outubro. BALLOU, R. (1997); Business Logistics - Importance and Some Research Opportunities, Revista Gestão & Produção, V. 4, No. 2. BARROS, L. (1997); A Global View of Industrial Logistics, Gestão & Produção, Vol. 4, n. 2, agosto. BIDAULT, F. & BUTLER, C. (1995); Buye-Supplier Cooperation for Effective Innovation, M2000 Executive Report, Number 17, September. BOWERSOX, D. & CLOSS, D. (1997); Brazilian Logistics: A Time for Transition, Revista Gestão & Produção, V. 4, No. 2. DYER, J. (1996); How Chrysler Created an American Keiretsu, Harvard Business Review, July-August. GOBBO JÚNIOR, J. A. & PIRES, S.R.I. (1997); Gestão da Cadeia de Suprimentos: um estudo de caso no setor de máquinas rodoviárias. Anais do 17º ENEGEP, Gramado, Outubro. HARTLEY, J. L.; ZIRGER, B. J.; KAMATH, R. R. (1997); Managing the buyer - supplier interface for on-time performance in product development. Journal of Operations Management, v.15, n.1, p. 57-70. KANTER, R. M. (1994). Colaborative advantage: the art of alliances. Harvard Business Review, p. 96-108, July-August. LAU, R. & HURLEY, C. (1997); Outsourcing Through Strategic Alliances, Production and Inventory Management Journal, Second Quarter. MIRANDA, N.G. & CORRÊA, H.L (1996); Uma análise parcial da rede de suprimentos da indústria automobilística brasileira. Revista de Administração-USP, V. 31, No. 1. RODRIGUES, S.A. & PIRES, S.R.I. Gestão da Cadeia de Suprimentos como um novo modelo competitivo: um estudo empírico. Anais do 17º ENEGEP, Gramado, Outubro, 1997. SALERMO, et al. (1998); Mudanças e persistências no padrão de relações entre montadoras e autopeças no Brasil , Revista de Administração- USP, Vol. 33, No. 3. TWIGG, D. (1997). A typology of supplier involvement in automotive industry. Coventry-UK Warwick Business School. (Research Paper, 271)
Livros na área
BOWERSOX, D. & CLOSS, D.(1996); Logistical Management - The Integrated Supply Chain Process, McGraw-Hill, New York, 729p. CHRISTOPHER, M. (1992); Logistics and Supply Chain Management - Strategies for Reducing Costs and Improving Services, Pitman Publishing, London, 231p. LAMMING, R. (1993) Beyond Partnership: Strategies for Innovation and Lean Supply. United Kingdon: Prentice-Hall, 299p. MERLI, G. (1994); Comakership - A Nova Estratégia para os Suprimentos, Qualitymark Editora, Rio de Janeiro, 249 p. NISHIGUSHI, T. (1994). Strategic Industrial Sourcing: the Japanese Advantage. New York: Oxford University Press, 318p.
Periódicos com trabalhos na área
Harvard Business Review - http://www.hbsp.harvard.edu/products/hbr/index/html European management Journal Production Planning & Control International Journal of Production & Operation Management Revista de Administração (RAUSP) Sloan Management Review - http://web.mit.edu/smr-online/
Dissertações / Teses na área
AMARAL, D. C. (1997); Colaboração cliente-fornecedor no processo de desenvolvimento de produto: integração, escopo e qualidade do projeto do produto – estudos de caso na indústria automobilística brasileira. São Carlos. 193p. Dissertação (Mestrado), Universidade Federal de São Carlos. AMATO NETO, J. (1993); Desintegração Vertical / "Verticalização" e o novo padrão de relacionamento entre empresas: o caso do complexo automobilístico brasileiro. São Paulo, 236 p., Tese (Doutorado), Escola Politécnica da Universidade de São Paulo. RODRIGUES, S. A. (1998); Gestão da Cadeia de Suprimentos: conceitos, inovações e um estudo empírico. Santa Barbara d`Oeste. 152p. Dissertação (Mestrado), Faculdade de Engenharia Mecânica e de Produção, Universidade Metodista de Piracicaba. SCARVA DO CARMO, L.F.R.R. (1999); Análise e Perspectivas da Aplicação da Supply Chain Management na Indústria Automobilistica no Brasil. Rio de Janeiro, 85p., Dissertação (Mestrado), Pontifícia Univ. Católica do Rio de Janeiro.
Especialistas
Prof. Sílvio R. I. Pires, Professor NUMA, sripires@sc.usp.br, Professor de Gestão da Produção da UNIMEP, sripires@unimep.br Prof. Antonio P. S. Ayres, Assessor de Logística – Caterpillar, Professor de Gestão da Produção da UNIMEP, apsayres@unimep.br Prof. Thomas Vollmann, Production Management Professor, IMD (International Institute for Management Development), Suiça. http://www.imd.ch Prof. Robert Collins, Production Management Professor, IMD (International Institute for Management Development), Suiça. http://www.imd.ch
Sites relacionados
Supply Chain Management - Publicação on-line de artigos na área. http://www.manufacturing.net/magazine/logistic/pointpgs/webex.htm Production and Operation Management - Definições de termos ligados ao à área. http://www.pom.edu/pom/ Supply Chain Management Resource Web Page - Publicações e instituições sobre atuante na área http://www.createcom.com/supply-chain.html#link2 SAPICS (Educational Society for Supply Chain Management) - busca prover educação, informação e conhecimento por meio de cursos, seminários, conferências, visitas à fábricas, venda de material, websites e publicações na área. http://www.sapics.org.za/mission.html
System Dynamics http://www.portaldeconhecimentos.org.br/index.php/content/view/full9645
Introdução
A observação histórica do mundo à nossa volta revela um fato imponente: a maior constante de todos os tempos é a mudança. O crescimento acelerado de mudanças econômicas, tecnológicas e sociais desafia cientistas, engenheiros, políticos e executivos, entre outros, a aprender continuamente. Ao mesmo tempo, a complexidade dos sistemas em que vivemos também está crescendo. Muitos dos problemas que enfrentamos surgem como efeitos colaterais indesejados de nossas ações passadas. Frequentemente, soluções adotadas para resolver problemas importantes falham, tornam o problema pior, ou criam novos problemas. Tomada de decisão e aprendizado em um mundo que apresenta crescente complexidade dinâmica requer que nos tornemos pensadores sistêmicos, ou seja, requer que expandamos as fronteiras de nossos modelos mentais e desenvolvamos ferramentas para compreender como a estrutura de sistemas complexos afeta o seu comportamento. System Dynamics é uma perspectiva e um conjunto de ferramentas conceituais que pode nos auxiliar a compreender a estrutura e a dinâmica de sistemas complexos. System Dynamics também é um método rigoroso de modelagem que utiliza simulações em computador para definir organizações e políticas mais efetivas. Juntas, essas ferramentas permitem a criação de simuladores gerenciais (Sterman, 2000) – mundos virtuais onde espaço e tempo podem ser comprimidos e desacelerados de tal forma a permitir a experimentação de efeitos colaterais de longo prazo, aprendizado, e o projeto de estruturas e estratégias de alto desempenho.
Origem e formalismo
A origem da disciplina de System Dynamics é atribuída ao trabalho pioneiro de Jay W. Forrester iniciado cerca de 40 anos atrás no Massuchussets Institute of Technology. Suas raízes encontram-se nas teorias de controle e dinâmica não linear. Portanto, existem rigorosos fundamentos matemáticos para a teoria e modelos desenvolvidos nessa área. As práticas de modelagem em System Dynamics podem ser utilizadas para melhorar a nossa compreensão das maneiras pelas quais o desempenho de uma empresa está relacionado com a sua estrutura interna e políticas de operação, incluindo consumidores, competidores e fornecedores, a fim de engenheirar estruturas que permitam o alcance do(s) objetivo(s) desejado(s). Modelos realísticos e úteis de empresas e processos de negócio são quase sempre de tal complexidade e não linearidade que soluções analíticas não são conhecidas. Nesse contexto, muitas das ferramentas matemáticas que estudamos tem aplicação limitada. Modelar o comportamento humano é bem diferente de modelar sistemas físicos. Portanto, além de uma base sólida em matemática de sistemas dinâmicos, modelar sistemas que envolvem seres humanos, também requer conhecimento em psicologia, tomada de decisão, e comportamento organizacional.
O Processo de Modelagem
Um típico processo de modelagem é iterativo, partindo da definição do problema, construção do modelo de acordo com o formalismo desejado, e finalmente a definição de políticas de intervenção no sistema. A adequada articulação do problema é provavelmente o passo mais importante. Os resultados de uma etapa podem levar à revisão de etapas anteriores. A Figura 1 apresenta uma descrição mais detalhada do processo de modelagem e o contextualiza na dinâmica do próprio sistema sendo modelado. Modelagem efetiva envolve constante iteração entre experimentação e aprendizado no mundo real assim como também no virtual. Figura 1: Processo de modelagem no contexto do sistema sendo modelado (Sterman, 2000) Complexidade e o Papel da Simulação Baseada em Computador De acordo com Sterman (2000), a maior parte das pessoas pensa em complexidade em termos do número de componentes em um sistema ou do número de combinações a serem consideradas para a tomada de uma decisão. O problema de otimizar a programação da produção de automóveis levando em conta as preferências do consumidor em termos de modelo, cor, opcionais, etc. é altamente complexo. Entretanto, nesse caso, a complexidade é associada com encontrar a solução ótima em meio a uma quantidade astronômica de opções. Tal tipo de complexidade é chamada de complexidade combinatória ou complexidade de detalhes. Complexidade dinâmica, por sua vez, pode surgir mesmo em sistemas com baixa complexidade combinatória como é o caso de processos produtivos com operações simples mas que apresentam quebras e atrasos no fluxo de informação suportando a tomada de decisão. Esse tipo de complexidade se deve a interações entre os agentes do sistema ao longo do tempo. A Figura 2 ilustra essas idéias ao considerar possíveis padrões de crescimento de uma empresa medidos, por exemplo, através de volume de vendas ao longo do tempo: Figura 2: Padrões de Crescimento de uma Empresa (adaptado de Forrester, 1975) Com a Figura 2, Forrester (1975) explica que a curva A representa um tipo muito raro de empresa, a qual simplesmente cresce saudável e sem empecilhos durante todo o seu ciclo de vida. Mais frequentemente, entretanto, encontramos o comportamento descrito na curva B, onde após um período de aparente sucesso, uma sequência sucessiva de crises leva à falência ou venda do negócio. Frequentemente, o comportamento descrito em C (estagnação) também é encontrado. Porém, dentre as empresas que apresentam tendências de crescimento a longo prazo, o padrão mais comum é o descrito na curva D, onde crescimento é acompanhado por repetidas crises. Nesse contexto, alguns especialistas defendem que modelagem matemática formal pode ao máximo prover precisão quantitativa para definições preexistentes de problemas. Porém, não podem levar a conceitos fundamentalmente novos. Ao contrário, formalizar modelos qualitativos e testá-los através de simulação pode levar a mudanças radicais na maneira como compreendemos a realidade Alguns argumentam ainda que a formalização analítica força o modelador a omitir aspectos importantes do problema a fim de preservar a tratabilidade, permitir que teoremas sejam provados, ou mesmo omitir a inclusão de variáveis soft para as quais valores numéricos não existem. Além de tais limitações sob o ponto de vista de modelagem analítica, a complexidade dos modelos mentais envolvidos no projeto e análise de empresas e processos de negócio excede facilmente a nossa capacidade de entender suas implicações. Ou seja, modelos típicos são muito grandes e complexos para serem simulados mentalmente. Simulação baseada em computador, portanto, é o único meio prático de testar as hipóteses geradas. A Figura 3 apresenta o modelo dinâmico de um processo de produção para estoque. A estrutura é considerada simples, sendo que é composta por apenas uma entrada e uma saída. Entretanto, é suficiente para ilustrar os principais elementos de modelagem utilizados em System Dynamics assim como efeitos dinâmicos não lineares entre as principais variáveis que descrevem o sistema Figura 3: Modelo de processo de produção para estoque (adaptado de Fowler, 1999) O modelo acima permite analisar a relação existente entre a responsividade e a estabilidade do sistema. Por exemplo, suponhamos que a partir de um estado de estabilidade, a taxa de demanda do consumidor sofre um aumento repentino. Podemos obter estimativas sobre como o sistema irá responder a essa mudança através de simulação. A Figura 4 apresenta os resultados. Nesse caso, a resposta é levemente oscilatória e existe inicialmente uma grande discrepância entre o estoque requisitado e o estoque disponível até que eventualmente o sistema entra em uma nova configuração de equilíbrio Figura 4: Resposta do sistema a um aumento repentino na demanda (Fowler, 1999) Em uma situação como essa, várias políticas de reposição de estoque podem ser testadas. Uma solução natural para a falta de estoque disponível inicialmente parece ser aumentar a velocidade de resposta do sistemas através de uma política mais sensível às variações na demanda. Neste caso, suponhamos que essa sensibilidade seja duplicada. O resultado, conforme apresentado na Figura 5, é que o sistema não retorna a um estado de equilíbrio, oscilando indefinitivamente. Tais oscilações podem significar sérias dificuldades gerenciais em respeito ao gerenciamento dos recursos produtivos acompanhadas de prejuízo financeiro. Tudo isso acontecendo em um contexto onde a demanda, após o aumento inicial, permanceu constante até o fim da análise. Uma situação relativamente simples, porém cada vez mais rara em um contexto globalizado. Figura 5: Comportamento do sistema diante de uma política de reposição de estoques mais sensível à variações na demanda (Fowler, 1999)
Considerações Finais
Um princípio fundamental em System Dynamics explicita que a estrutura de um sistema determina o seu comportamento ou padrões de desempenho. Entretanto, as pessoas tem a forte tendência em atribuir o comportamento de outros indivíduos a fatores relacionados a humor, caráter, e disposição, ao invés de fatores situacionais tais como aqueles criados por restrições do próprio sistema no qual estão inseridos. A tendência em culpar a pessoa ao invés do sistema é tão grande que os psicólogos chamam isso de "erro fundamental de atribuição". Em sistemas complexos, pessoas diferentes trabalhando sob a mesma estrutura, tendem a se comportar de maneira semelhante. Quando associamos comportamento a personalidade perdemos de vista como a estrutura do sistema formatou nossas opções. Quando atribuímos o comportamento às pessoas e não ao sistema, o foco gerencial se torna a adimistração de conflitos e culpa ao invés do projeto e implementação de processos onde pessoas comuns podem atingir resultados extraordinários (Sterman,2000)
Livros
FINE, C. H. (1998). Clockspeed: Winning Industry Control in the Age of Temporary Advantage. Reading, Massachusetts, Perseus Books. FORRESTER, J. W. (1975). Collected Papers of Jay W. Forrester. Cambridge, Massachusetts, Wright-Allen Press, Inc. RITCHIE-DUNHAM, J. L., & RABBINO, H. T. (2001). Managing from Clarity: Identifying, Aligning and Leveraging Strategic Resources. England, John Wiley & Sons, Ltd. STERMAN, J. D. (2000). Business Dynamics: systems thinking and modeling for a complex world. Boston, Massachusetts, McGraw-Hill.
Periódicos
FOWLER, A. (1999). Feedback and feedforward as systemic frameworks for operations control. International Journal of Operations & Production Management. Vol. 19, No. 2, pp. 182-204. KEATING, E. K., OLIVA, R., REPENNING, N. P., ROCKART, S., & STERMAN, J. D. (1999). Overcoming the Improvement Paradox. European Management Journal. Vol. 17, No. 2, pp. 120-134. REPENNING, N. P., GONÇALVES, P., & BLACK, L. (2001). Past the Tipping Point: The persistence of firefighting in product development. California Management Review. Vol. 43, No. 4, pp. 44-63. STERMAN, J. D. (2001). System Dynamics Modeling: Tools for learning in a complex world. California Management Review. Vol. 43, No. 4, pp. 8-25. TOWILL, D. R. (1996). Industrial dynamics modeling of supply chains. Logistics Information Management. Vol. 9, No. 4, pp. 43-56.
Referências Online
System Dynamics Group. Massachusetts Institute of Technology: http://web.mit.edu/sdg/www/ Ventana Systems, Inc.: http://www.vensim.com/ SAP - Strategic Enterprise Management: http://www.sap.com/
Associações
System Dynamics Society: http://www.systemdynamics.org/
TOC (Theory of Constraints) http://www.portaldeconhecimentos.org.br/index.php/content/view/full9634
Breve Histórico
Criada pelo físico israelense Eliyahu M. Goldratt na década de 80, a Teoria das Restrições foi inicialmente fundamentada em programas de computação com o objetivo de desenvolver e implementar um sistema de programação de produção com capacidade finita, para resolver problemas de chão de fábrica. Este sistema ficou conhecido como OPT (Optimized Production Technology) e sua aplicação tornou-se para muitos sinônimo de Teoria das Restrições. Ficou constatado na prática, entretanto, que o simples uso de um software não garante à empresa um processo auto-sustentado de melhoria contínua. Para tal, era necessário antes de mais nada que fossem quebrados certos paradigmas que regem as organizações, mudando a forma de agir e pensar das pessoas. Tornou-se evidente, portanto que era realmente preciso desenvolver um método em que se permitisse criar, comunicar e implementar uma boa solução para a produção. A primeira experiência bem sucedida de abordar o que foi depois chamado de “O Processo de Raciocínio da Teoria das Restrições” se deu através da publicação de “A Meta”, um livro técnico escrito de maneira romanceada por Goldratt juntamente com Jeff Cox. “A Meta” não somente foi a base na qual foi sedimentada a Teoria das Restrições, como também foi muito útil em aplicações industriais via implementação dos conceitos de programação da produção delineados na obra.
Conceitos
De acordo com os pressupostos presentes na Teoria das Restrições, restrição é qualquer coisa que limita um sistema em conseguir maior desempenho em relação a sua meta. Na analogia da corrente, restrição seria o elo mais fraco. Pode-se afirmar, devido às flutuações estatísticas presentes, que todo sistema possui pelo menos uma restrição ou que toda corrente possui sempre um elo mais fraco. Tal afirmativa pode ser comprovada ao se analisar a realidade dos sistemas produtivos. Se tais sistemas não possuem restrições, ou seja, se nada limita seus desempenhos, qual seria então seu lucro líquido? Uma vez que não existe nenhuma empresa capaz de gerar um lucro operacional infinito, fica claro que sempre existirá ao menos uma restrição que limitará o ganho de qualquer tipo de organização. Existem diversos tipos de restrições. Estas podem ser físicas, como uma máquina com baixa capacidade produtiva, despreparo ou baixo número de empregados, ou então restrições não físicas, como as restrições de política da empresa, comportamentais, culturais ou de mercado. Entretanto, como bem salienta Goldratt, as restrições físicas podem ser consideradas, na maioria das vezes, como reflexos das restrições comportamentais ou de procedimentos da organização. Ainda segundo Goldratt, toda organização é formada ou constituída com um propósito principal e que este é, na verdade, determinado por seus proprietários ou por seus acionistas, que investem recursos com um determinado objetivo. Se a empresa possui ações negociadas no mercado de capitais, certamente a meta é “ganhar mais dinheiro tanto agora como no futuro”. Definido o objetivo, a empresa deve agora encontrar as medidas necessárias para guiar e controlar seus esforços na direção de sua meta. Para Goldratt, medidas financeiras são necessárias por dois motivos principais. A primeira é controle, ou seja, saber até que ponto a empresa está conseguindo alcançar o objetivo de gerar dinheiro. A outra razão, e talvez a mais importante delas, é induzir que as partes façam o que é bom para a organização como um todo. Tradicionalmente, são usadas três medidas para se avaliar a “saúde” das empresas: o lucro líquido (medida absoluta), o retorno sobre o investimento (medida relativa) e o fluxo de caixa (condição necessária muito importante à sobrevivência da companhia). Estas, quando julgadas em conjunto, são suficientes para fornecer as informações financeiras necessárias à administração de uma empresa. O uso destas medidas, porém, são muito úteis nos relatórios da alta cúpula administrativa, mas diz muito pouco quando se pretende medir o impacto das ações locais no resultado global do sistema. Assim, a Teoria das Restrições definiu três novos elementos que não apenas auxiliam nas tomadas de decisões da diretoria da empresa, como também nas decisões operacionais locais. São eles : Ganho (Throughput) : índice pelo qual o sistema gera dinheiro através das vendas. É importante observar na definição que o ganho só é obtido quando o produto (ou serviço) ofertado é efetivamente vendido. Desta forma evita-se qualquer confusão entre produção e ganho. Se o que foi produzido não for realmente vendido não se obtém ganho. Inventário (Inventory) : todo o dinheiro que o sistema investe na compra de coisas que pretende vender. Aqui, inventário deve ser entendido no seu sentido mais amplo, incluindo máquinas, equipamentos, instalações, construções, materiais, etc.. Esta definição é a mesma do convencional significado de ativo, com exceção ao que se refere ao inventário de material. Goldratt considera que não se deve atribuir valor ao produto conforme este vai sendo manipulado pelo sistema produtivo, uma vez que todo conceito de valor acrescido ao produto faz parte de um distorcido processo de otimização local. O objetivo é acrescentar valor à empresa e não ao produto. Como bem salienta Goldratt, o fato de não se levar em conta no cálculo do inventário o valor agregado ao mesmo, não significa que não se tenha estas despesas. Tais gastos, para ele, aparecem na terceira medida denominada Despesa Operacional. Despesa Operacional (Operating Expenses) : todo o dinheiro que o sistema gasta transformando Inventário em Ganho. Despesa Operacional pode ser entendida, portanto, como todo dinheiro que sai ou é perdido pelo sistema. Goldratt menciona que passou a adotar, no início de 1987, o nome atual teoria das restrições. Para ele, um melhor entendimento da psicologia provocou nele uma mudança da ênfase em regras e princípio para um foco em um processo iterativo. Além disso, as significativas ramificações que este processo teve para áreas como contabilidade, distribuição, marketing e projeto do produto quase o forçou aquela escolha de palavras. Pode-se dizer, que a Teoria das Restrições se divide hoje em três grandes grupos de atuação: os diagramas de causa-e-efeito denominados de Processos de Raciocínio com suas cinco ferramentas fundamentais (árvore da realidade atual, diagrama de dispersão de nuvem, árvore da realidade futura, árvore de pré-requisitos e árvore de transição), o uso das definições ganho, inventário e despesa operacional como norteadores para tomadas de decisões e seus aplicativos em gerenciamento de distribuição, marketing, gerenciamento de projetos (denominado Corrente Crítica), o método Tambor-Pulmão-Corda, entre outros.
Livros
GOLDRATT, E. M. (1990). A síndrome do palheiro: garimpando informação num oceano de dados. Trad. Claudiney Fullmann. São Paulo, Nobel. ( Disponível biblioteca FEA ). GOLDRATT, E. M. (1994). Mais que sorte... Um processo de raciocínio. Trad. por Claudiney Fullmann. São Paulo, Educator. (t:) GOLDRATT, E. M. (1998). Corrente Crítica. Trad. por Thomas Corbett Neto. São Paulo, Nobel. ( Disponível biblioteca EESC - USP ) GOLDRATT, E. M.; COX, J. (1992). Meta: um processo aprimorado contínuo. Trad. por Claudiney Fullmann. 2. ed. São Paulo, Educator. ( Disponível na biblioteca EESC - USP ). GOLDRATT, E. M.; Fox, R. E. (1992). A corrida pela vantagem competitiva. Trad. por Claudiney Fullmann. São Paulo, Educator. ( Disponível biblioteca EESC - USP) NOREEN , E.; Smith, D.; Mackey , J. T. (1996). A teoria das restrições e suas implicações na contabilidade gerencial. Trad. por Claudiney Fullmann. São Paulo, Educator. (t: 823) SRIKANTH, M. L.; UMBLE, M. (1995). Synchronous manufacturing: principles for world class excellence. Cincinnati: South-Western Publishing Co. (t: 787)
Artigos
GOLDRATTI, E. M. (1988). Computerized shop floor scheduling. International Journal of Production Research, v. 26, n. 3, p. 443-445. (t:793). LEE., T.; PLENERT, G. (1996). Maximizing prodct mix profibality - what's the best analysis tool. Production Planning & Control, v. 7, n. 6, p. 547- 553. (t:789) . SCHRAGENHEIM, E.; RONEN, B. (1990). Drum-buffer-rope shop floor control. Production and Inventory Mangement Journal, p.18-22, third quarter. (t:791). SCHRAGENHEIM, E.; RONEN, B. (1991). Buffer management: a diagnostic tool for production control. Production and Inventory Management Journal, p. 74-79, second quarter. (t: 790) SPENCER, M. S. (1991). Using "the goal"in an MRP system. Production and Inventory Management Journal, p. 22-27, fourth quarter. (t:792). SPENCER, M. S.; COX , J. F. (1995a). Master production scheduling development in a theory of constraints environment. Production and Inventory Management Journal, p.8-14, first quarter. (t:788). SPENCER, M. S.; COX, J. F. (1995b). Optimum production technology (OPT) abd the theoy of constraints (TOC): analysis and genealogy. International Journal of Production Research, v. 33, n. 6, p. 1495-1504. (t; 794).
Sites relacionados
Crazy About Constraints- A web site dedicated to providing resources and information about the Theory of Constraints, the Thinking Process, Synchronous Manufaturing, and other techniques developed by Dr. Eliyahu Goldratt. http://www.rogo.com/cac/ H. William Dettmer On TOC - Tu Dinh Nguyen has posted an excerpt from an article by H. William Dettmer on Goldratt's Theory of Constraints titled: A system-level approach to continous improvement . http://www.saigon.com/~nguyent/dettmer2.html Constraint Accounting Measurements - This site constains an abundance of useful information, including thoughts & research on TOC from Jonh Casparini , links to numerous TOC sites, TOC articles & books. http://users.aol.com/caspari0/toc/main.htm TOC: its usefulness and applicability - A research report submitted to the Faculty of Management by Johannes Gerhardus Steenkamp. http://www.wits.ac.za/wits/library/mngment/steenkam.html Theory of Constraints - A web site dedicated to providing resources and information about the Theory of Constraints . http://www.chief.co.il/TOC/ Selection of Operations Management Methodologies in Disparate Cost Environment - http://me.mit.edu/groups/lfm/working_papers/1995_abstracts/kurz.html City University Constraints Archive - The management "Theory of Constraints" From part 1 of the comp.constraints FAQ: subject: [1-20] TOC. http://web.cs.city.ac.uk/archive/constraints/toc.html TQM BBS/ Principles - Practice - http://deming.eng.clemson.edu/pub/tqmbbs/prin-pract/ SMITH, J. J. (1994). Theory of constraints and MRP II: from theory to results. http://www.rogo.com/cac/JJsmith.html.
TRIZ (Teoria da Solução Inventiva de Problemas) http://www.portaldeconhecimentos.org.br/index.php/content/view/full9507
Introdução
A TRIZ começou a ser desenvolvida durante os anos 50, por G. S. Altshuller, na ex-URSS. Altshuller (1969, 1974, 1979, 1980, 1984, 1989) estudou patentes de diferentes áreas, com o objetivo de buscar alternativas mais eficazes aos métodos para a solução criativa de problemas então disponíveis - especialmente, aos métodos puramente psicológicos. Esta abordagem diferenciou-se das anteriores por focalizar-se nos registros do produto criativo das áreas técnicas - as patentes. Altshuller e sua equipe procuraram definir quais os processos envolvidos na obtenção das soluções criativas contidas nas patentes. Estudando problemas que haviam sido resolvidos de forma criativa e procurando deles retirar informações que pudessem ser utilizadas para a solução de outros problemas, Altshuller encontrou certas regularidades no processo de solução de problemas. Com base nas regularidades identificadas, elaborou uma metodologia para a solução de problemas, a qual denominou TRIZ
Histórico e estrutura
A TRIZ considerada clássica - desenvolvida por Altshuller e seus colaboradores - é composta por diversos métodos para a formulação e a solução de problemas, uma base de conhecimento e padrões da evolução dos sistemas técnicos. É uma unanimidade entre os principais autores que a TRIZ ainda está no início de seu desenvolvimento e que muitos conhecimentos científicos ainda serão adicionados à base de dados e métodos mais eficazes serão desenvolvidos e/ou unificados com os já existentes na TRIZ e em áreas correlatas. Vem ocorrendo uma expansão do uso da TRIZ para áreas não técnicas (administração, pedagogia e outras). Por falta de intercâmbio científico com os países ocidentais durante o regime comunista da ex-URSS, a difusão da TRIZ no Ocidente somente vem ocorrendo há pouco mais de uma década, com intensidade maior a partir de 1995. Com a doença e o falecimento de Altshuller, o desenvolvimento da TRIZ passou a ser liderado por seus antigos colaboradores. A estrutura da TRIZ clássica é mostrada na Figura 1. Figura 1 - Estrutura da TRIZ Clássica
Conceitos fundamentais
Os conceitos fundamentais da TRIZ são a idealidade, a orientação à contradição e o uso de recursos existentes num sistema. Na TRIZ, um sistema técnico é entendido como o preço pago pela execução de funções e, quanto mais evoluído o sistema, menor tende a ser esse preço. Assim, os sistemas técnicos evoluem no sentido do aumento da idealidade (ou seja, mesmo sem existir um sistema específico para isso, a função é executada). A evolução dos sistemas técnicos é um processo governado por certos padrões (Tabela 1), os quais direcionam o sistema técnico rumo ao ideal. Idealmente, nenhum sistema existe, mas, as funções necessárias são executadas. Tabela 1 - Padrões da evolução dos sistemas técnicos (adaptado de Altshuller, 1979)
Padrões Explicações
Padrões da criação de sistemas técnicos Completeza do sistema Um sistema técnico deve ter motor, transmissão e sistemas de operação, controle e sustentação e proteção.
Capacidade de condução de energia Um dos subsistemas de um sistema técnico tem de ser capaz de conduzir energia, no mínimo.
Sincronização dos ritmos Subsistemas dos sistemas técnicos devem ter ritmos de operação compatíveis.
Padrões do +movimento Inesgotabilidade do desenvolvimento técnico Sistemas técnicos podem ser desenvolvidos, através de melhorias e associação a outros, indefinidamente.
Aumento da idealidade do sistema técnico Sistemas técnicos tendem a utilizar mais informação e menos material, energia, espaço e tempo.
Desigualdade da evolução dos subsistemas Subsistemas, especialmente de sistemas complexos, tendem a desenvolver-se desigualmente.
Transição para o supersistema Quando o desenvolvimento de um sistema técnico isolado chega ao limite, esta transição pode ser necessária.
Padrões de tendência Simplificação do sistema Sistemas tornam-se mais complicados e, depois, mais simples. A eficácia aumenta com a simplificação.
Transição para o subsistema A eficácia de um sistema aumenta com a transição para o subsistema.
Transição da instrumentação para a automatização A eficácia de um sistema aumenta com a automatização.
Aumento da participação de sistemas C-S no sistema A eficácia de um sistema aumenta com o crescimento da participação de sistemas C-S (campo-substância).
Como ilustração, na Tabela 2 são mostradas as etapas de evolução do automóvel com motor de combustão interna. Tabela 2 - Etapas da evolução do automóvel (adaptado de Savransky, 1996)
Estágio de evolução Descrição Exemplo: automóvel com motor de combustão interna
Formação 0 Descoberta científica ou tecnológica para a qual, muitas vezes, não se conhece aplicação. Teorias de Carnot, Watt e outros (termodinâmica clássica).
1 O sistema ainda não existe, mas, há elementos importantes para seu surgimento. Desenvolvimento dos primeiros motores de combustão interna.
2 O novo sistema surge, resultante de invenção do nível 3 ou 4 (solução de uma contradição e/ou uso de princípio científico pouco conhecido). Desenvolvimento lento. Primeiros automóveis: construídos com tecnologia das carruagens, artesanais e caros.
Otimização 3 A sociedade reconhece a importância do novo sistema. O desenvolvimento é rápido. Muitas patentes são concedidas. Ford e outros iniciam a produção em massa e o grande mercado de automóveis.
4 O sistema atinge a maturidade e seu desenvolvimento satura-se. Incorporação de mecânica sofisticada, como transmissão automática, controle de tração e de freios, injeção de combustível, etc.
5 Possibilidades de desenvolvimento do sistema original são esgotadas.
Evolução 6 Melhorias no sistema são conseguidas com outras tecnologias. Surge a próxima geração, que substituirá o sistema original. Incorporação de elementos eletrônicos, permitindo melhorias de desempenho. Veículos elétricos, híbridos etc.
Formação 7 (= 2) Coexistência do sistema antigo com o novo. Veículos com motor de combustão interna, elétricos, híbridos etc.
Contradições podem ser definidas como requisitos conflitantes com relação a um mesmo sistema técnico. Por exemplo, a haste de um ferro de soldar deve ser longa, para não queimar a mão do soldador e deve ser curta, para facilitar o controle da operação. Uma solução extremista seria fazer a haste muito longa. Isso evitaria queimaduras, mas, prejudicaria a precisão do controle. Uma solução que procura contornar a contradição seria fazer a haste não muito curta, nem muito longa: um meio termo é estabelecido. A orientação à contradição consiste em não procurar evitá-la, mas, resolvê-la criativamente. Como um exemplo de solução que resolve a contradição, a haste poderia ter forma similar à de uma ferradura. Assim, o cabo seria longo (para a transmissão de calor) e seria curto (para um controle adequado). A identificação e solução das contradições de um sistema técnico aproxima-o do ideal. Existem diferentes tipos de contradições: as contradições administrativa, técnica e física são as mais importantes para a solução de problemas em sistemas técnicos. Os recursos de um sistema podem ser definidos como quaisquer elementos do sistema ou das cercanias que ainda não foram utilizados para a execução de funções úteis no sistema. A utilização de recursos torna o sistema mais próximo do ideal. Há casos em que a simples procura por recursos não aproveitados em um sistema leva a soluções inventivas. Existem diferentes classes de recursos: internos; externos; naturais; sistêmicos; funcionais; espaciais; temporais; de campo; de substância; de informação. Um exemplo do uso de recursos do sistema é o turbocompressor utilizado em motores de combustão interna, que transforma parte da energia dos gases de combustão em sobrepressão do ar alimentado. Neste caso, o recurso utilizado corresponde à energia.
Descrição de algumas partes da TRIZ
Padrões da evoluçãoOs padrões da evolução dos sistemas técnicos correspondem às regularidades encontradas por Altshuller (1979) em análises de sistemas técnicos oriundos de diferentes áreas. Na Tabela 1, é apresentado um resumo dos padrões da evolução dos sistemas técnicos. Os padrões da evolução dos sistemas técnicos descrevem como poderá ocorrer o desenvolvimento de um sistema técnico na direção do sistema técnico ideal. Os padrões podem ser utilizados para prever como um determinado sistema deve ser desenvolvido e definir as tarefas de desenvolvimento. São, portanto, úteis para orientar a solução de problemas técnicos, para previsão tecnológica e definição de estratégias e táticas de desenvolvimento, na etapa de planejamento de produto. Desenvolvimento da criatividade pessoalEsta parte da TRIZ não é baseada no estudo de patentes, mas em uma outra fonte de informação: biografias de pessoas consideradas criativas. Altshuller concentrou-se neste estudo em seus últimos anos de trabalho. O desenvolvimento da criatividade pessoal não se destina, diretamente, à solução de problemas técnicos. A ênfase é no aumento da capacidade criativa dos indivíduos. Deriva da preocupação de Altshuller com a dificuldade de implementação de idéias criativas. O desenvolvimento da criatividade pessoal baseia-se no estudo de uma grande quantidade de biografias. A partir do estudo das biografias, Altshuller e seu colaborador Vertkin desenvolveram uma estratégia apresentada de forma similar à de um jogo de xadrez: o ambiente executa movimentos contra a pessoa e a pessoa executa movimentos contra o ambiente hostil. Altshuller e Vertkin delinearam seis partes principais da estratégia criativa pessoal: a definição de uma meta socialmente significativa; o planejamento e controle dos movimentos contra o ambiente; a administração da capacidade de trabalho e do tempo; a tecnologia adequada para a solução de problemas (TRIZ); a capacidade de suportar os ataques do ambiente e formas de obtenção contínua de resultados. Solução de problemas com a TRIZEsta é a parte da TRIZ mais importante para o desenvolvimento de produtos e processos. A classificação dos diferentes métodos da TRIZ, mostrada na Figura 1, é feita com base nos critérios de grau de inovação e etapa principal do processo de solução atendida pelo método. O grau de inovação diferencia entre problema de reengenharia (problema de reprojeto) e problema de inovação. A etapa do processo de solução diferencia entre análise preliminar ou solução. A seguir, são descritos os métodos de análise preliminar de problemas, seguidos pelos métodos para a geração de soluções. Métodos para análise preliminar de problemasOs métodos para análise preliminar de problemas na TRIZ são a análise de restrições, a análise função - componente (também conhecida como análise de interações) e a análise para previsão da evolução. A análise de restrições consiste na análise da situação problemática, na qual se procura estabelecer as restrições necessárias e remover as restrições imaginárias. A análise função - componente é utilizada no reprojeto de sistemas, com a finalidade de melhorar a qualidade e minimizar custos. Esta análise inclui um algoritmo para a análise funcional de um sistema, sendo as saídas do algoritmo definições do problema compatíveis com os métodos de solução de problemas da TRIZ. A análise para previsão da evolução consiste no estudo do sistema técnico, seu supersistema e seus subsistemas no presente, no passado e no futuro. Procura-se identificar em que fase de sua evolução o sistema se encontra. A previsão da evolução ou a indicação de possibilidades de desenvolvimento é, então, feita por analogia, utilizando-se os padrões da evolução dos sistemas técnicos (Tabela 3). Métodos para solução de problemasOs métodos utilizados para a solução de problemas na metodologia TRIZ são a análise de interações, a análise de contradições, o método dos princípios inventivos, o método da separação, a análise C-S, o método das partículas e o ARIZ - Algoritmo para a Solução Inventiva de Problemas. Como meio de apoio para a solução de problemas é utilizada a base de informações sobre efeitos físicos, químicos e geométricos. O método para a solução de problemas mais conhecido da TRIZ - método dos princípios inventivos - é apresentado a seguir. Método dos princípios inventivosO método dos princípios inventivos envolve a utilização de parâmetros de engenharia e princípios inventivos. Este foi o primeiro dos métodos para a solução de problemas criados por Altshuller (1969). Os parâmetros de engenharia correspondem à generalização das grandezas envolvidas em problemas técnicos de diferentes áreas. Conforme o tipo de problema, estas grandezas devem ser maximizadas, minimizadas ou mantidas ao redor de um valor meta. Os trinta e nove parâmetros de engenharia são mostrados na Tabela Os princípios inventivos são sugestões de possibilidades de solução para um determinado problema. Foram obtidos a partir da generalização e agrupamento de soluções repetidamente utilizadas na criação, desenvolvimento e melhoria de sistemas técnicos de diferentes áreas. Esse trabalho foi feito a partir da análise de uma quantidade muito grande de patentes (mais de 2 milhões de patentes). Os quarenta princípios inventivos formulados por Altshuller são mostrados na Tabela 3. Tabela 3 - Parâmetros de engenharia (Altshuller, 1969) 1 Peso do objeto em movimento 2 Peso do objeto parado 3 Comprimento do objeto em movimento 4 Comprimento do objeto parado 5 Área do objeto em movimento 6 Área do objeto parado 7 Volume do objeto em movimento 8 Volume do objeto parado 9 Velocidade 10 Força 11 Tensão ou pressão 12 Forma 13 Estabilidade da composição 14 Resistência 15 Duração da ação do objeto em movimento 16 Duração da ação do objeto parado 17 Temperatura 18 Brilho 19 Energia gasta pelo objeto em movimento 20 Energia gasta pelo objeto parado 21 Potência 22 Perda de energia 23 Perda de substância 24 Perda de informação 25 Perda de tempo 26 Quantidade de substância 27 Confiabilidade 28 Precisão de medição 29 Precisão de fabricação 30 Fatores externos indesejados atuando no objeto 31 Fatores indesejados causados pelo objeto 32 Manufaturabilidade 33 Conveniência de uso 34 Mantenabilidade 35 Adaptabilidade 36 Complexidade do objeto 37 Complexidade de controle 38 Nível de automação 39 Capacidade ou produtividade O processo de aplicação do método dos princípios inventivos é mostrado na Figura 2. Há duas opções para a aplicação deste método. Se, após a análise do sistema técnico e seleção de parâmetros a melhorar não forem identificados conflitos (i.e. a melhoria do parâmetro não implica na piora de outros parâmetros), os princípios inventivos podem ser utilizados simplesmente como itens de um checklist. A outra opção implica na identificação de contradições (parâmetros contraditórios no problema), transformação desses contradições em contradições entre parâmetros de engenharia e posterior consulta da matriz de contradições. Essa matriz pode ser consultada online aqui. Na matriz de contradições, as entradas são, para cada contradição, nas linhas, o parâmetro de engenharia a ser melhorado e, nas colunas, o parâmetro que tende a degradar-se com isso. No cruzamento das linhas com as colunas, estão os números correspondentes aos princípios inventivos mais utilizados para a solução da mesma contradição entre parâmetros de engenharia nas patentes estudadas para a construção da matriz. Uma vez identificados os princípios inventivos aplicáveis, procura-se soluções para a contradição, a partir dos mesmos. Isto não significa que outros princípios inventivos não possam resultar em soluções adequadas. Savransky (1998a) argumenta que a compilação feita para estabelecer a matriz de contradições é antiga e sua validade estatística pode ter diminuído. Assim, recomenda utilizar, também, outros princípios inventivos. Tabela 4 - Princípios inventivos (Altshuller, 1969) 1 Segmentação ou fragmentação 2 Remoção ou extração 3 Qualidade localizada 4 Assimetria 5 Consolidação 6 Universalização 7 Aninhamento 8 Contrapeso 9 Compensação prévia 10 Ação prévia 11 Amortecimento prévio 12 Equipotencialidade 13 Inversão 14 Recurvação 15 Dinamização 16 Ação parcial ou excessiva 17 Transição para nova dimensão 18 Vibração mecânica 19 Ação periódica 20 Continuidade da ação útil 21 Aceleração 22 Transformação de prejuízo em lucro 23 Retroalimentação 24 Mediação 25 Auto-serviço 26 Cópia 27 Uso e descarte 28 Substituição de meios mecânicos 29 Construção pneumática ou hidráulica 30 Uso de filmes finos e membranas flexíveis 31 Uso de materiais porosos 32 Mudança de cor 33 Homogeneização 34 Descarte e regeneração 35 Mudança de parâme-tros e propriedades 36 Mudança de fase 37 Expansão térmica 38 Uso de oxidantes fortes 39 Uso de atmosferas inertes 40 Uso de materiais compostos Figura 2 - Solução de problemas com os princípios inventivos (Altshuller, 1974) Por exemplo, no projeto de latas para conter bebidas gaseificadas, deseja-se diminuir a quantidade de material utilizado para fabricar a lata - de modo a reduzir custos - e, ainda assim, manter sua integridade estrutural, possibilitando o empilhamento. Se a quantidade de material utilizada é diminuída, a carga admissível também diminui, o que é indesejável. Logo, os parâmetros conflitantes podem ser: no 4 - comprimento do objeto parado e no 11 - tensão ou pressão. Consultando a matriz de contradições, obtém-se os seguintes princípios: no 1 - segmentação ou fragmentação; no 14 - recurvação; e no 35 - mudança de parâmetros e propriedades. A partir do princípio no 1, pode-se chegar a uma das concepções existentes - latas corrugadas. Essa solução aumenta a resistência mecânica das latas, mas, não economiza material. As latas de alumínio utilizadas atualmente podem ser consideradas exemplos do princípio no 14: a forma recurvada da lata faz com que a pressão interna aumente a resistência mecânica. O princípio no 35 poderia levar a uma concepção que incluísse uma modificação no material das latas, como um tratamento térmico, para aumento de resistência. Diversas outras soluções poderiam ser geradas, com base nos princípios sugeridos pelo uso da matriz de contradições. Além dos três princípios sugeridos, não podem ser descartados os outros princípios inventivos. As soluções encontradas e outras soluções interessantes também poderiam ser obtidas através da aplicação de outros princípios inventivos.
Glossário
  • Contradição técnica: consiste num par de requisitos contraditórios com relação a um mesmo sistema. Por exemplo: "o automóvel deve ser espaçoso e ter boa penetração aerodinâmica."
  • Contradição física:consiste num par de requisitos contraditórios referentes a um mesmo objeto (elemento de um sistema). Por exemplo: "o porta-malas do automóvel deve ser grande (para conter toda a bagagem) e deve ser pequeno (para não reduzir o espaço dos passageiros e não tornar o veículo muito grande)."
  • Idealidade: a idealidade de um sistema técnico é a razão entre o número de funções desejadas e o número de funções indesejadas que o mesmo executa.
  • Recursos: podem ser definidos como quaisquer elementos do sistema ou das cercanias que ainda não foram utilizados para a execução de funções úteis no sistema. A utilização de recursos torna o sistema mais próximo do ideal.
  • Método dos Princípios Inventivos: foi o primeiro método para a solução criativa de problemas desenvolvido por Altshuller. Embora tenha sido desenvolvido para solucionar problemas técnicos, também é muito útil na solução de outros tipos de problemas. O método dos princípios inventivos baseia-se no uso dos parâmetros de engenharia, dos princípios inventivos e da matriz de contradições.
  • Parâmetros de engenharia:são variáveis genéricas encontradas em problemas de diversas áreas, como "velocidade de um objeto em movimento", "complexidade de um objeto" ou "manufaturabilidade".
  • Princípios inventivos: são heurísticas ou dicas com relação a possíveis soluções. Por exemplo, para solucionar um determinado problema, pode ser interessante fazer "uso de atmosferas inertes" ou "uso de objetos descartáveis e baratos".
  • Matriz de contradições: matriz para a escolha dos princípios inventivos historicamente mais utilizados para a solução de uma determinada contradição entre parâmetros de engenharia.
  • Análise C-S: análise de campo-substância, a qual consiste na modelagem de um problema em termos de campos e substâncias, posterior modificação para um campo-substância solução e busca de significado real para essa modificação.
  • Método da separação:é um método para a solução de contradições físicas. Isso pode ocorrer através da separação dos requisitos contraditórios no espaço, no tempo, no sistema ou conforme condições.
  • Método das partículas:é um método baseado no método da empatia, que consiste em levar o usuário a tentar colocar-se dentro do problema e, a partir daí, gerar soluções através de suas ações imaginárias dentro da situação problemática. Altshuller verificou, no uso prático da empatia, que as pessoas têm dificuldade em imaginar ações como corrosão, explosão ou outras, que as destruiriam. Assim, propôs que, no lugar de pessoas, se imagine uma multidão de "homenzinhos espertos" a realizar as ações necessárias. Mais recentemente, se propôs a substituição dos homenzinhos por partículas.
  • ARIZ: é o acrônimo russo para Algoritmo para a Solução Inventiva de Problemas. Trata-se de um algoritmo para (re)formular um problema e serve como guia no uso das técnicas para a solução de problemas da TRIZ. Existem várias versões, sendo que a última desenvolvida por Altshuller é o ARIZ-85.
Artigos
FEY, V. R., RIVIN, E. I., VERTKIN, I. M. Application of the Theory of Inventive Problem Solving to Design and Manufacturing Systems. In: CIRP, 1994, Annals ..., v.43(1), p.107-110. SAVRANSKY, S. D. TRIZ: The Methodology of Inventive Problem Solving. http://www.jps.net/triz/Tech1Rev.htm, 1996.
Livros
ALTSHULLER, G. S. Innovation Algorithm. Worcester: Technical Innovation Center, 1999 (1a ed. russa, 1969). ALTSHULLER, G. S. Forty Principles. Worcester: Technical Innovation Center, 1998 (1a ed. russa, 1974). ALTSHULLER, G. S. Creativity as An Exact Science - The Theory of The Solution of Inventive Problems. 1a. ed. Luxemburg: Gordon & Breach, 1984 (1a ed. russa, 1979). ALTSHULLER, G. S. Flügel für Ikarus: Über die Moderne Technik des Erfindens. Leipzig: Urania, 1980. ALTSHULLER, G. S. (sob o pseudônimo ALTOV, H.) And Suddenly the Inventor Appeared. Worcester: Technical Innovation Center, 1990 (1a ed. russa, 1984). ALTSHULLER, G. S.; ZLOTIN, B.; ZUSMAN, A.; PHILATOV, V. Searching for New Ideas: From Insight to Methodology - The Theory and Practice of Inventive Problem Solving. Kishinev: Kartya Moldovenyaska, 1989 (Publicado em inglês como Tools of Classical TRIZ. Southfield: Ideation International, 1999). MALMQUIST, J., AXELSSON, R., JOHANSSON, M. A Comparative Analysis of the Theory of Inventive Problem Solving and the Systematic Approach of Pahl and Beitz. In: ASME - DETC, 1996, Irvine. Proceedings of The DSTC. Irvine: ASME, 1996. SALAMATOV, Y. TRIZ: The Right Solution at the Right Time - A Guide to Innovative Problem Solving. Hattem: Insytec, 1999. SAVRANSKY, S. D. TRIZ for Engineers. Berlin: Springer, 2000.
Sites Relacionados
Existe uma grande quantidade de sites sobre TRIZ. A seguir são relacionados alguns dos mais úteis para o estudo e uso efetivo da TRIZ:
  • Altshuller Institute for TRIZ Studies - Venda de material para estudo, alguns artigos, informação sobre conferências
  • The TRIZ Journal - Muitos artigos, de qualidade variável
  • Páginas de Kalevi Rantanen - Muito bons exemplos, especialmente referentes aos princípios inventivos
  • TRIZ Empire - Conceitos, informações introdutórias e links
  • Matriz de contradições on-line - Matriz de contradições em java, muito prática
Ferramentas Computacionais
Principais fornecedores de software baseado na TRIZ:
  • Ideation International
  • Invention Machine
  • CREAX
  • Insytec
  • IQ-Plus
Periódicos Importantes
Izobretenia - Journal do Altshuller Institute for TRIZ Studies - Periodicidade semestral - Artigos sobre TRIZ, de boa qualidade: http://www.aitriz.org/ TRIZ Journal - Periodicidade Mensal - Publica artigos teóricos e aplicados sobre TRIZ, de qualidade variável: http://www.triz-journal.com
TRM (Technology roadmap) http://www.portaldeconhecimentos.org.br/index.php/content/view/full9509
1) Introdução
Atualmente as empresas sofrem uma competição crescente no mercado global. Devido à essa grande competição sofrida pelo mercado e o investimento cada vez menor na área de P&D faz-se extremamente necessário garantir que os investimentos estão alocados nos desenvolvimentos corretos e nos momentos corretos. É de suma importância que os investimentos estejam alinhados com a estratégia da empresa a médio e longo prazo. Para isso, é necessário que os diversos setores tenham uma visão unânime do rumo em que a empresa está indo. Atualmente há uma necessidade das empresas de base tecnológica fazerem um balanço de market pull e technollogy push de seus produtos. Os produtos de market pull são aqueles produtos que já são demandados pelo mercado. Os produtos de techonology push são aqueles que ainda não são demandados pelo mercado mas que a empresa tem capacitação tecnológica suficiente para “empurrá-los” para o mesmo. Deste modo a empresa deve ter um equilíbrio entre produtos inovadores e produtos com tecnologias já dominadas pelo mercado. O Technology Roadmapping é um método visual que tem como objetivo prever as necessidades futuras do mercado e alinhar a ações presentes na empresa para que se faça um planejamento estratégico e de desenvolvimento de produtos. Desta forma a empresa poderá adquirir capacitações tecnológicas de modo a garantir a satisfação das necessidades futuras do mercado.
2) O que é TRM
O Technology Roadmapping (TRM) é um método de gerenciamento usado para suportar o planejamento estratégico tecnológico da empresa. Ele auxilia na estruturação, desdobramento, comunicação e estabelecimento da visão de futuro da organização e na sua integração com os planos de mercado, produto e tecnologia (PHAAL et al., 2001b). Em resumo, pode-se dizer que o TRM fornece um método gráfico para se estabelecer uma relação entre as necessidades futuras de mercado, a tecnologia atual da empresa, a tendência da tecnologia no mundo, programas de pesquisa e desenvolvimento. Desta maneira, a empresa poderá tomar decisões que otimizam os investimentos de capital em P&D e que, ao mesmo tempo, estão alinhados com a estratégia da empresa. Pode-se pensar no TRM como um mapa da evolução de tecnologias e produtos que não foram ainda desenvolvidos.
3) Fontes
Oliveira, M.G. Integração do Technology Roadmapping e da Gestão de Portfólio para apoiar a macro-fase de pré-desenvolvimetno do PDP. Dissertação. Engenharia de Produção, EESC-USP, 2009. Solange Gomes Leonel, Lin Chih Cheng, Diógenes Cecilio da Silva Jr, Pedro Henrique Ferreira Drummond; Uma Forma de Agregar a Voz dos Clientes nas Etapas Iniciais de Criação de uma Empresa de Base Tecnológica (EBT) de Origem a Acadêmica. XXIV Simpósio de Gestão da inovação tecnológica. Outubro de 2006 Sungjoo Lee, Yongtae Park; Customization of technology roadmaps according to roadmapping purposes: Overall process and detailed modules. Department of Industrial Engineering, School of Engineering, Seoul National University. Novembro de 2004 Neto, P.M. ; Planejamento de novos produtos por intermédio do método Technology Roadmapping (TRM) em uma pequena empresa de base tecnológica do setor de internet móvel. 2005 Marie L. Garcia, Olin H. Bray; Fundamentals of technology roadmapping. Strategic Business Development Department Sandia National Laboratories. Abril de 1997 Robert Phaal, Clare J.P. Farrukh, David R. Probert ; Developing a Technology roadmapping system. Engineering Department, University of Cambridge, CB2 1RX, UK. 2005
4) Tipos de TRM
O método TRM é bastante flexível e abrangente. A falta de padronização para se criar um TRM fez com que existissem diversos tipos do mesmo. Phaal et al. (2001c e 2004) e Probert & Radnor (2003) identificaram diversos tipos de roadmaps e os classificaram segundo seu formato e propósito. Segundo o propósito do roadmap foram identificados 8 tipos principais: roadmap de produto, serviços, planejamento estratégico, planejamento a longo prazo, planejamento do conhecimento, planejamento de programas, planejamento de processos e planejamento de integração. Em relação ao formato do roadmap, foram identificados 8 tipos principais: roadmaps de camadas múltiplas, barras, tabelas, de gráficos, representações pictóricas, flow charts, camadas simples e texto. Para caracterizar e compreender as variações dos Roadmaps, Kappel (2001) elaborou uma taxonomia que possui 4 grandes áreas de aplicação do TRM: · Roadmaps de Ciência/Tecnologia: visam compreender melhor o futuro, identificando tendências, gerando previsões e definindo metas de desenvolvimento para o setor; · Roadmaps de Indústria: objetivam estabelecer as expectativas de desenvolvimento da tecnologia em termos de custo e desempenho para a competitividade de um setor; · Roadmaps de Produtos - Tecnologia: buscam alinhar as decisões de desenvolvimento de produto com as tendências de mercado e de tecnologia de uma empresa; e · Roadmaps de Produto: objetivam articular a direção e o cronograma da evolução de um produto e/ou famílias de produtos de uma empresa.
5) Benefícios gerados pelo TRM
Muitas empresas cometem o equívoco de visar somente os benefícios gerados pelo roadmap em si. É importante ressaltar que grande parte dos benefícios gerados pelo Roadmap se encontra no processo de seu desenvolvimento e não no mapa em si. Isso se dá ao fato de a elaboração do TRM ser um processo que exige uma equipe multifuncional, desta maneira diversas informações e perspectivas de diversas áreas são trocadas. É importante notar que o principal benefício gerado pelo processo de TRM é o compartilhamento de conhecimentos e uma visão comum de todos os departamentos da empresa do rumo que a mesma está tomando. Por ser um método gráfico, a comunicação entre vários departamento é facilitada. Torna-se também mais fácil identificar gaps no processo de alinhamento nas metas a médio e longo prazo e nas atividades presentes na empresa. A abordagem da metodologia TRM possui um grande potencial para dar suporte ao planejamento dos negócios, além de provir uma integração entre as perspectivas de tecnologia, produtos e negócios da empresa. O TRM facilita o balanceamento entre o market pull e technology push, ou seja, o equilíbrio entre os produtos demandados pelo mercado com os produtos ofertados pela capacidade tecnológica. O Roadmap apresenta um meio de migração entre o estado atual dos negócios à visão de longo prazo, fornecendo os elos entre as diversas camadas. A competitividade da empresa aumenta ao se garantir que os inverstimentos em P&D estão sendo alocados na área e no tempo corretos e alinhados com a sua estratégia a longo prazo. Além disso, é possível realizar uma prioriazação de desenvolvimentos mais consistente e segura no médio e longo prazo.
6) Processo de aplicação do TRM
Antes de apresentar o processo de aplicação é importante ressaltar que o processo de elaboração do roadmap é considerado o responsável pela real agregação de valor ao método, e não apenas o resultado final, o Roadmap em si (PHAAL et al., 2004; RADNOR & PROBERT, 2004; ALBRIGHT & KAPPEL, 2003). Assim, a adoção de um processo eficiente é um requisito indispensável para sua aplicação. Seguindo a taxonomia de Kappel (2001), o trabalho adota a aplicação do roadmap de produto-tecnologia. Neste tipo, o processo está baseado no trinômio mercado/negócio, produto/serviço e tecnologia/recurso e estabelece relações de causa e efeito entre o trinômio, visando construir um plano temporal para o planejamento estratégico de desenvolvimento da empresa. A lógica de integração entre os três componentes baseia-se no estabelecimento de relações explícitas entre know-why (saber porque), know-what (saber o que) e know-how (saber como), ao longo do tempo (PHAAL et al., 2001a; GARCIA, 1997). A construção do roadmap de produto-tecnologia pode seguir dois caminhos: o primeiro através da abordagem de market pull (puxado pelo mercado) e o outro technology push (empurrado pela tecnologia). Na primeira abordagem o roadmap seguirá as necessidades do cliente, enquanto que na segunda, o que direcionará serão os produtos vindos do desenvolvimento interno da empresa (NETO, 2005). Entre os processos de aplicação disponíveis na literatura para o roadmap de produto-tecnologia, o desenvolvido por Robert Phaal, Clare J.P. Farrukh e David R. Probert (PHAAL et al., 2001a, 2003 e 2004) consiste em um processo estruturado em seminários que visam prover um ambiente de comunicação e resolução de problemas entre uma equipe multidisciplinar instruída por um agente externo qualificado no processo de TRM. O procedimento de aplicação do TRM, chamado de T-Plan pelos autores, tem como objetivo auxiliar as organizações na geração do primeiro Roadmap. É importante notar que o foco do T-Plan está nas grandes empresas, no entanto devido ao nível de detalhamento existente no manual de aplicação (Phaal et al., 2001a) e pelo fato dele possuir uma metodologia voltada para uma iniciativa rápida, ele foi escolhido para ser seguido no trabalho. A figura 3 ilustra as etapas do processo proposto pelo T-Plan. Figura 3 - Processo de aplicação do T-Plan (PHAAL et al., 2001) Outros processos sobre aplicação do TRM, como os apresentados por Albright & Kappel (2003), por Clark & Wheelwright (1993) e Whalen (2007) são encontrados na literatura. O de Albright & Kappel (2003) apresenta em maiores detalhes meios que auxiliam a formulação da estratégia com relação ao mercado, produto e tecnologia. Já os outros dois tem foco maior na integração das áreas funcionais da empresa com as estratégias, possibilitando um alinhamento entre elas e o planejamento estratégico.
7) Processo de Adaptação do TRM
Para o método atender as particularidades de cada organização é necessário sua adaptação, sendo este ponto uma dificuldade para sua adoção pelas empresas. A compreensão do ambiente de aplicação pode ser considerada um dos fatores mais importantes para a adaptação do TRM em relação a necessidade da organização. Segundo Phaal et al. (2001a), o processo de adaptação do TRM deve estar acontecer durante a etapa de planejamento. Os principais elementos de adaptação do Roadmapping apresentados pelos autores são: o horizonte de planejamento, a estrutura do roadmap e o processo de construção do roadmap. Portanto, para que a aplicação do TRM seja eficiente, torna-se essencial a sua adaptação às circunstâncias específicas de cada organização (PHAAL et al., 2004).
8) Processo de Adaptação do TRM
Para o método atender as particularidades de cada organização é necessário sua adaptação, sendo este ponto uma dificuldade para sua adoção pelas empresas. A compreensão do ambiente de aplicação pode ser considerada um dos fatores mais importantes para a adaptação do TRM em relação a necessidade da organização. Segundo Phaal et al. (2001a), o processo de adaptação do TRM deve estar acontecer durante a etapa de planejamento. Os principais elementos de adaptação do Roadmapping apresentados pelos autores são: o horizonte de planejamento, a estrutura do roadmap e o processo de construção do roadmap. Portanto, para que a aplicação do TRM seja eficiente, torna-se essencial a sua adaptação às circunstâncias específicas de cada organização (PHAAL et al., 2004).
Visão holística do negócio http://www.portaldeconhecimentos.org.br/index.php/content/view/full9667
Origem da palavra
A palavra hólos veio do grego e significa inteiro; composto. Segundo o dicionário, holismo é a tendência a sintetizar unidades em totalidades, que se supõe seja própria do universo. Sintetizar é reunir elementos em um todo; compor.
Definição
A visão holística de uma empresa equivale a se ter uma "imagem única", sintética de todos os elementos da empresa, que normalmente podem ser relacionados a visões parciais abrangendo suas estratégias, atividades, informações, recursos e organização (estrutura da empresa, cultura organizacional, qualificação do pessoal, assim como suas interrelações).
Importância
Todo empresário e o seu pessoal gerencial deveriam ter uma visão holística de sua empresa. Essa visão possui diferentes ênfases e graus de abstração. No entanto, a visão do todo ( a imagem única) é essencial para que eles cumpram o seu papel. Algumas empresas possuem pessoas com essa visão, e normalmente elas se destacam de suas concorrentes. Porém uma grande parte dos dirigentes atingiu seu posto vindo de uma área específica, trazendo assim uma visão distorcida do todo. É comum encontrar gerentes empolgados com os recursos computacionais, outros achando que a solução está somente na estrutura organizacional, outros que consideram suas máquinas e equipamentos como sendo a salvação da empresa, etc... Com uma visão holística é mais seguro tomar decisões relativas a uma das visões específicas, pois a influência desta decisão sobre as outras visões da empresa é observada à priori. Se esta visão holística for então formalizada, pode-se discutir problemas específicos sem se perder a abrangência, nivelando-se o conhecimento entre os participantes da discussão. No entanto, é impossível representar o todo de forma completa. Este todo é algo abstrato, que forma uma unidade na mente dos dirigentes. Pensar a empresa como um conjunto de businees processes é o formalismo existente mais próximo para a obtenção da visão holística. Esses conceitos garantem a obtenção da Integração de Empresas/CIM.
Artigos
GARVIN, D. A.; (1995). Leveraging Process for Strategic Advantage. Harvard Business Review. v. 73, n. 5, p. 76-90. (t:799). ROZENFELD, H.; (1996). Reflexões sobre a Manufatura Integrada por Computador (CIM). MANUFATURA CLASSE MUNDIAL: MITOS E REALIDADE .São Paulo ,1996. ( t:1)
Sites Relacionados
Tópicos principais de um livro que trata de holismo no ambiente empresarial http://www.ramboll.dk/ramboll/pub/uk/htm/general/holistic_operations/holistic_operations_page2.htm
Workgroup Computing/Workflow http://www.portaldeconhecimentos.org.br/index.php/content/view/full9637
Introdução
O trabalho em equipe, cada vez mais, tem se tornado essencial para as empresas que buscam qualidade e agilidade em seus processos de negócios. Porém, em muitos casos, o sucesso de uma equipe esbarra na falta de comunicação e integração entre as pessoas e áreas envolvidas. As soluções usadas tradicionalmente para a distribuição da informação baseiam-se na circulação de papéis, cartas e memorandos, geralmente transportados de mesa em mesa por meio de um mensageiro. A comunicação entre as pessoas é feita por telefone, fax ou quadros de avisos. Vários inconvenientes estão relacionados há esses métodos, dentre eles estão:
  • Excesso de papel;
  • Inconsistência da informação;
  • Circulação deficiente da informação;
  • Reuniões improdutivas;
  • Comunicação ineficiente.
Computação Colaborativa
Computação Colaborativa - Workgroup Computing - é parte de um conceito que surgiu há muitos anos, chamado de Trabalho Cooperativo Suportado por Computador (CSCW – Computer Supported Cooperative Work). CSCW reúne um conjunto de técnicas, sistemas e tecnologias para utilização de computadores com a finalidade de prover suporte ao trabalho em grupo de pessoas que possuem um objetivo comum de negócio. Este conceito só começou a ser popularizado nos últimos anos devido ao avanço da tecnologia da informação e de recursos como os computadores pessoais e as redes locais de computadores. A Computação Colaborativa propõe uma maneira inovadora de se resolver os problemas citados inicialmente e fornecer novos recursos para suportar o trabalho em grupo. Os principais objetivos a ser atingir são:
  • Possibilitar o trabalho em grupo de pessoas separadas fisicamente;
  • Eliminar ações improdutivas no processo de negócio;
  • Melhorar a criação colaborativa de produtos do trabalho, como documentos, projetos, especificações, etc.;
  • Auxiliar na tomada de decisões;
  • Comunicar os membros dos grupos de trabalho sobre eventos importantes;
  • Fortalecer a sinergia entre os membros dos grupos de trabalho.
O conceito de Workgroup Computing abrange várias tecnologias e ferramentas de suporte ao trabalho em grupo que podem, porém, apresentar uma grande diversidade de aplicações e funcionalidades. As principais aplicações podem ser classificadas dentro das seguintes categorias:
  • Correio eletrônico: O correio eletrônico foi uma das primeiras e mais importantes ferramentas de Workgroup Computing, e é hoje uma das mais utilizadas. Permite a comunicação a nível local (dentro da empresa) e global (Internet), entre pessoas e grupos. Apresenta várias vantagens como rapidez, flexibilidade e capacidade de integração com outros aplicativos (editores de textos, planilhas, etc.).
  • Agenda eletrônica em grupo: A agenda eletrônica é uma ferramenta que permite a sobreposição de várias agendas pessoais, auxiliando na alocação de tempo e compromissos, como reuniões, de uma equipe. A maior vantagem desta ferramenta é a agilidade que oferece nos agendamentos de reuniões de grandes equipes.
  • Vídeo conferência: Este sistema permite a comunicação remota com recursos de áudio e vídeo. É de grande utilidade na redução de custos no trabalho de um equipe globalmente distribuída. Alé disso permite a realização de teleconferências e cursos à distância.
  • Sistema de apoio à decisão em grupo: É uma ferramenta que auxilia uma equipe na tomada de decisões, melhorando o aproveitamento das reuniões.
  • Sistemas de gerenciamento de documentos: Estes sistemas visam gerenciar documentos eletrônicos de forma a garantir a segurança, a organização e a consistência das informações. Para isso, estes sistemas fornecem recursos de busca rápida, controle de versão e status, anotações eletrônicas ( redlines), entre outros (vide PDM).
  • Gerenciadores de fluxo de trabalho ( Workflow): Sistemas de workflow são aqueles que automatizam um processo, acelerando o fluxo de tarefas e eliminando ações improdutivas. Devido à importância dos sistemas de Workflow esse tópico será detalhado a seguir.
Workflow
Workflow é a tecnologia que engloba um conjunto de ferramentas que permitem a automação do fluxo de trabalho. A principal função de um sistema Workflow no contexto de Workgroup Computing é a automação de um processo estruturado e a eliminação de tarefas improdutivas. Um processo estruturado é aquele em que todas as suas etapas se repetem frequentemente de maneira parecida, e portanto pode ser programado para que as etapas ocorram automaticamente. Essa habilidade de um sistema Workflow de definir a seqüência de etapas que a informação deve passar é chamada de roteamento. O roteamento é definido por regras que estabelecem o próximo passo do processo, que pode acontecer de forma seqüencial, paralela ou condicional. A implantação de um sistema Workflow apresenta várias dificuldades que variam desde uma adaptação cultural da empresa, adaptação à plataforma de hardware e software, análise de custo e benefício e na maioria das vezes um processo de reengenharia, ou seja, reestruturação do processo de negócio. Entretanto, a maioria dos "cases" de implantação de Workflow apresentam resultados bastante convincentes. Entre os principais benefícios de uma aplicação de Workflow estão:
  • Controle do processo: fundamental para as empresas que buscam certificação ISO 9000 e QS 9000.
  • Produtividade: com a eliminação das tarefas improdutivas o processo diminui o gasto de tempo e aumenta os ganhos.
  • Padronização do processo: permite que as pessoas possam visualizar o processo e que as informações sejam organizadas.
  • Rastreabilidade: O status do processo pode ser identificado a qualquer momento permitindo a realização de auditorias.
A Solução da FIM
Na Fábrica Integrada Modelo está implementado uma solução de Workgroup Computing para apoiar o trabalho das equipes no processo de desenvolvimento de produtos. A aplicação está baseada em uma rede local de computadores e no sistema operanional Windows NT. As principais ferramentas utilizadas são aplicativos comerciais, como o Microsoft Office, que a maioria das já empresas possuem. O objetivo é mostrar que mesmo com aplicações comuns é possível criar soluções mais sofisticadas. As ferramentas utilizadas são apresentadas a seguir. O Microsoft Exchange é usado como gerenciador de correio eletrônico. Ele permite a comunicação entre as pessoas e a distribuição de informações para grupos de pessoas por meio de listas. Aplicativos como Word, associados ao Exchange dispõem um recurso que possibilita a edição de um documento por várias pessoas em lugares diferentes ao mesmo tempo. Um usuário distribui um documento base para o grupo e cada um faz anotações e envia o documento de volta. Ao receber todas as anotações o documento é compilado. O Microsoft Schedule+ é uma agenda eletrônica que gerencia compromissos individuais e em grupo. Um dos recursos mais utilizados é o agendamento de reuniões. O sistema automaticamente identifica um horário disponível a todos e prepara uma convocação enviada pelo correio eletrônico. Para a comunicação remota é utilizado um sistema de vídeo conferência. O equipamento é o Intel ProShare. Ele possibilita a realização de reuniões entre duas pessoas em lugares diferentes com recursos de áudio e vídeo. Esse sistema também possui ferramentas para a troca e a edição conjunta de documentos. Um sistema de Workflow foi aplicado, usando o software AutoManager Workflow, para automatizar o processo de criação e aprovação de desenhos. Esse fluxo de trabalho apresenta tarefas seqüências, paralelas e condicionais, e recursos para o controle e rastreabilidade da informação. ELLIS, C. A.; GIBBS, S.; J. REIN, G. L. (1991). Groupware - some issues and experiences. Communications of the ACM, v.34, n.1 Jan. (t:812) GRUDIN, J. (1994). Computer-supported cooperative work: history and focus. IEEE Computer, May. (t:811) PESSANHA, K. (1996). Correio eletrônico e workgroup computing. São Paulo: Berkeley Brasil. (Disponível na biblioteca da FSP - USP) TIBERTI, A. J. (1996). Desenvolvimento de um sistema gerenciador de fluxo de trabalho para um ambiente de suporte a atividades de engenharia. São Carlos. Dissertação ( Mestrado ) - Escola de Engenharia de São Carlos, Universidade de São Paulo. ( Disponível na biblioteca da EESC - USP ).
Sites Relacionados
Special Interest Group on Supporting Group Work (http://www.acm.org/siggroup/) Workflow Management Coalition (http://www.aiim.org/wfmc/) Videocomference.com (http://www.videoconference.com/) Colaborative Estrategies (http://www.collaborate.com/)
Índices de Capabilidade do Processo (Cp, CpK) http://www.portaldeconhecimentos.org.br/index.php/content/view/full9914
Introdução
Os índices e taxas que medem a capabilidade, ou seja, a capacidade de um dado processo fabricar produtos dentro da faixa de especificação, surgiram dos estudos sobre Controle Estatístico de Processo (CEP) realizados pelo Dr. Walter Shewhart do Bell Laboratories na década de 20. Seu surgimento se confunde com o próprio nascimento da área de qualidade. É que o trabalho inicial realizado no Bell Laboratories foi a base das principais técnicas e ferramentas que fariam nascer nas empresas americanas os departamentos de qualidade durante a segunda guerra. Outro subproduto destas técnicas foi também o surgimento da American Society for Quality Control - ASQC (hoje denominada ASQ) . Acontecimento que também é um marco no nascimento da área de estudo e de atuação profissional de qualidade. Assim, o Controle Estatístico de Processo é uma das ferramentas mais clássicas na área de qualidade e com certeza uma das mais comprovadas e empregadas no meio prático. Desde seu surgimento tem sido aplicada aos mais diversos processos, situações e regiões em todo o mundo. Há também um grande conhecimento acumulado sobre sua aplicação, principais benefícios e restrições. O objetivo do controle estatístico do processo é aprimorar e controlar o processo produtivo por meio da identificação das diferentes fontes de variabilidade do processo. Utilizando conceitos de estatística procura-se separar os efeitos da variabilidade causada pelas chamadas Causas Comuns, ou seja, àquelas inerentes à natureza do processo produtivo, das Causas Especiais, ou àquelas derivadas da atuação de variáveis específicas e controláveis sobre o processo. A técnica é composta de uma ferramenta principal denominada Gráficos de Controle que permite identificar se o processo está sob controle estatístico, situação em que atuariam somente causas comuns. O controle estatístico é implantado por meio de um ciclo em que coleta-se dados do processo, monitora-se sua situação (verificando se o mesmo permanece sob controle estatístico) e posteriormente realizam-se análises e propostas de melhorias para atingir patamares melhores de desempenho. Os índices de capabilidade podem ser obtidos diretamente dos dados registrados nas cartas de controle e medem, para um processo sob controle estatístico, a relação entre a faixa de tolerância especificadas para uma dada característica de projeto do produto e a variabilidade natural do processo produtivo destinado a obtenção daquela característica (a variabilidade devida as causas comuns). Se a variabilidade do processo é muito maior ultrapassando os limites de especificação é possível estimar a probabilidade de produção de peças fora da especificação. Se esta probabilidade é muito alta pode-se inferir que o processo não é capaz de produzir àquela característica mesmo que peças conformes possam estar sendo obtidas. Mudanças significativas neste processo ou mesmo a adoção de processos alternativos podem então ser necessárias para tornar este processo capaz estatisticamente. Estes índices são de extrema importância para o profissional que trabalha no desenvolvimento de produto por duas grandes razões. Nas fases iniciais de projeto, a avaliação de séries históricas dos índices de capabilidade obtidos de peças similares pode permitir que os processistas e projetistas escolham processos e especificações dos produtos coerentemente adequadas, garantindo a obtenção de características do produto por meio de processos altamente capazes estatisticamente. Outra importante aplicação destes índices no desenvolvimento de produto é durante a homologação do processo. Nesta etapa os índices podem ser utilizados para avaliar a capabilidade do processo, identificando processos problemáticos à tempo de correções antes da entrada em linha de produção.
Índices e Taxas de Capabilidade de Processo
Abaixo apresenta-se os índices de capabilidade apresentados por IQA(1997). Além destes existe uma grande quantidade de índices propostos na literatura para as mais diversas aplicações.
Índices
Capabilidade (Cp) (Conhecido como Capabilidade de Máquina) : Definido como o intervalo de tolerância dividido pela capabilidade do processo, ou seja, 6 vezes o desvio padrão estimado considerando a ausência de causas especiais. Ele é independente da centralização do processo o desvio padrão é estimado considerando processos estáveis: Desempenho (Pp): Intervalo de tolerância dividido pelo desempenho do processo, ou seja, pelo desvio padrão estimado pelas leituras individuais. Também independentemente da centralização. Superior de Capabilidade (CPU) : variação superior da tolerância dividida por 3 vezes o desvio padrão estimado pela capabilidade do processo. Inferior de Capabilidade (CPL): variação inferior da tolerância dividida pela dispersão superior real do processo. Capabilidade (Cpk): é o índice que leva em conta a centralização do processo e é definido como o mínimo entre CPU e CPL.
Taxas
Taxa de Capabilidade (CR): é inverso de Cp. É igual a 1/Cp; Taxa de Desempenho (Pp): é o inverso de Pp. É igual a 1/Pp;
Etapas básicas para a medição de Capabilidade de Processo
São basicamente duas as etapas para a condução de um estudo de capabilidade do processo: 1. Verificação do Controle Estatístico do Processo: nesta etapa são preparados os gráficos de controle para a coleta de dados (sem os limites) e estes são entregues para a produção. Estes dados são então levantados e a partir de uma análise gráfica (ou mesmo utilizando testes estatísticos) verifica-se a existência de causas especiais atuando no processo. Se existirem causas especiais atuando deve-se identificá-las e eliminá-las até que o processo esteja sobre controle estatístico. 2. Avaliação dos Índices: uma vez garantido o controle estatístico do processo identifica-se todos os dados que compõem o período sobre controle do processo. Estes dados são então utilizados para a geração dos índices.
Análise da Capabilidade de Processo na FIM
No processo de desenvolvimento de produto da FIMo estudo de capabilidade do processo é utilizado durante a fase de homologação do produto. Emprega-se para os cálculos uma ferramenta computacional. Glossário Estes itens do glossário são parte do glossário do manual de Controle Estatístico do Processo (CEP) da QS 9000, que é extremamente interessante e detalhado. São apresentados aqui definições dos conceitos principais:
  • Aleatoriedade: uma condição na qual os valores individuais não são previsíveis, apesar deles poderem vir de uma distribuição definível;
  • Amostra: nome dado ao subgrupo, ou seja, um ou mais eventos ou medições utilizados para analisar o desempenho de um processo;
  • capabilidade de processo: faixa total de variação inerente de um processo estável;
  • Carta de controle: uma representação gráfica de uma característica de um processo, mostrando os valores de alguma estatística obtida daquela característica, uma linha central, e um ou dois limites de controle;
  • Limites de Controle: uma linha ou linhas em uma carta de controle utilizada como uma base para julgar a estabilidade do processo. A variação além de um limite de controle é evidência de que causas especiais estão afetando o processo. Limites de controle são calculados a partir dos dados do processo e não devem ser confundidos com as especificações de engenharia;
  • Causa Comum: fonte de variação que afeta todos os valores individuais do resultado do processo sendo estudado; na análise da carta de controle ele representa parte da variação aleatória do processo;
  • Causa Especial: fonte de variação que é intermitente, freqüentemente imprevisível e instável às vezes chamado de causa assinalável . É sinalizado a partir de um ponto além dos limites de controle ou uma seqüência ou outro padrão não aleatório de pontos dentro dos limites de controle;
  • Controle Estatístico: condição descrevendo um processo do qual todas as causas especiais de vatiação tenham sido eliminadas, restando apenas as causas comuns, i.e., a variação observada pode ser atribuída a um sistema constante de causas ocasionais; evidenciada numa carta de controle pela ausência de pontos além dos limites de controle e pela ausência de padrões não-aleatórios ou tendências dentro dos limites de controle;
  • Desempenho de processo: faixa total da variação global do processo (6?s);
  • Desvio-padrão: uma medida da dispersão do resultado do processo ou a dispersão de uma estatística amostral do processo (ex. de médias de subgrupos); denotado pela letra grega ? (sigma), ou a letra s (padra desvio padrão da amostra);
  • Processo Estável: processo sob controle estatístico.
Referências Bibliográficas
IQA . Fundamentos de controle estatístico de processo CEP. 1997. (Existem muitos livros sobre este assunto mas este manual, que faz parte da documentação da QS 9000, é bastante didático e traz uma explicação detalhada sobre os pontos fundamentais sobre este assunto. É recomendado para quem deseja aprender sobre CEP com o intuito de aplicação.Caso esteja interessado apenas em obter uma visão geral sobre este assunto deve-se consultar um bom livro texto introdutório sobre estatística para engenharia ou negócios.)
Sites Relacionados
Veja os mesmos que DOE.