EBOM como base da fonte única da verdade
Senhores,
Certa vez em uma conversa com um cliente chave de uma empresa, ouvi a seguinte frase:
“A principal informação de saída de um produto desenvolvido é a sua lista de materiais, pois é assim que nasce a distribuição das atividades, compras e processos produtivos!”
Com base nisso, os convido a pensar em um processo de desenvolvimento de produtos, onde contamos com muitos Stakeholders e colaboradores, sejam eles das engenharias ou outros departamentos, vide o fluxo padrão do PLM, como demonstrado abaixo:
Porém, mesmo dentro da engenharia e desenvolvimento de produtos, contamos com algumas coisas bem complexas:
- Diversas ferramentas de projetos
- CAD para projeto mecânico
- Projeto elétrico
- Desenvolvimento de projetos eletrônicos
- Soluções de simulação
- Ferramentas documentos
O principal problema é que cada um possui as suas próprias ferramentas instaladas em um computador, inclusive salvando os arquivos gerados em diversos repositórios de arquivos. Um caso bem comum são os discos de rede, onde uma equipe salva parte do trabalho no “W”, outros no “S”, assim por diante.
Porém, isso se trata da descontinuidade da informação, a cada processo, seja ele entre equipes de projeto, ou ao quebrar a barreira do departamento de engenharia, acaba causando uma ruptura no desenvolvimento do produto.
Esse post tem como objetivo demonstrar como a EBOM resolve essa situação, assim como do que se ela se trata.
EBOM – Definição
Primeiramente, temos de entender que EBOM se trata de um acrônimo para Engineering Bill Of Materials, traduzido como lista de materiais de engenharia. Se trata da representação virtual do produto com os intens CAD, documentos associados, código fontes e firmware, assim como demais informações.
Antigamente existia o conceito da lista exportada pelo programa CAD, sincronizada com um sistema para gerar a EBOM. Era realmente um botão de conversão que sistemas PLM’s e ERP’s mais antigos possuíam. Entretanto, a partir do momento em que a Dassault Systemes adota a metodologia Model Based, o produto da lista e do CAD passam a serem os mesmos e sincronizados, sem a necessidade de alguma operação. Portanto, poderemos dizer que a EBOM e o CAD são parte da mesma informação.
Mas o que faz parte de uma EBOM? O gráfico abaixo pode nos representar em algumas categorias de informações e separações de categorias de itens inseridos.
Além do que foi listado acima, têm as informações dos itens que mandatoriamente precisam estar inseridas no conjunto de dados como os Part Numbers, que são os códigos dos componentes, os agrupamentos hierárquicos, quantificação de componentes, assim como a maturidade dos objetos.
Entendendo a importância
De nada adianta ter uma lista completa sem ela solucionar qualquer coisa, né? Mesmo dentro da idealização dos produtos, são muitas as pessoas que podem estar colaborando, entre eles.
- Engenharia de produto: onde diretamente nas ferramentas de projeto CAD, o mesmo já vai gerando a lista preliminar, assim como inserindo os itens associados ao produto provenientes de outros produtos.
- Desenvolvimentos de softwares: aqui vem um aspecto importante, o desenvolvedor de software possui os seus repositórios de códigos fontes, como GIT’s e afins. O que poderemos fazer é conectá-los na EBOM, através da plataforma 3DEXPERIENCE. Através dessa pessoa conectada, contamos com o produto produzido e entregue com uma versão de software associada.
- Gestores: o processo deles colaborarem visualizando o produto completo e anexando documentos pertinentes ao desenvolvimento do produto, independente do departamento de engenharia ou fora dele
A lista tem por objetivo funcionar como fonte única da verdade para o produto, ao visualizá-la todos os dados estarão listados e anexados na estrutura. Com tudo poderemos contar com a abordagem Model Based, onde visualizaremos em tempo real a geometria completa, tal qual as informações não desenhadas.
Como criamos a lista?
A EBOM é bem mais livre que a maioria das outras aplicações PLM da Dassault Systèmes. Isso ocorre uma vez que o modelo está no centro de todo o desenvolvimento de produto, qualquer solução de projeto computadorizado nativa ou devidamente conectada pode colaborar com esse tipo de lista.
Os tradicionais SOLIDWORKS e o CATIA V5 possuem as suas interfaces com as estruturas de produto e a Plataforma 3DEXPERIENCE diretamente em suas interfaces, como demonstrado abaixo:
Para as ferramentas nativas, poderemos mencionar duas situações, as soluções CATIA 3DEXPERIENCE e o XDESIGN. Ambos trabalham diretamente com a construção de modelos, a base da EBOM.
Até então falamos de soluções diretamente conectadas ao projeto seja ele 2D ou 3D, assim como eletroeletrônico ou mecânico. Porém, existem situações em que a estrutura nasce antes do projeto ser desenvolvido, ou ajustada posteriormente com os itens complementares. Para tal, entre as situações ilustradas existem duas soluções para uso na Plataforma 3DEXPERIENCE, o arquiteto de produto e o editor de estrutura.
Sobre as soluções, o que temos de registrar é que todas são conectadas entre si, uma vez que não estamos gerindo arquivos, mas todos estão convergindo para a gestão do modelo do produto. Por fim, existem mais soluções que podem ser conectadas, entre elas softwares de projetos que não são da Dassault Systèmes e ferramentas de versionamento e controles de códigos fontes, como o próprio GIT e outros SVN’s.
Sobre a jornada de listas
No post anterior falávamos de MBOM, agora falamos da lista de engenharia e a saída que é consolidada posteriormente. Para voltar ao que foi falado anteriormente, recomento o link abaixo:
https://blogs.solidworks.com/solidworksbrasil/2021/07/como-uma-mbom-pode-auxiliar-no-desenvolvimento-de-produto.html
Também estaremos fazendo mais alguns posts nas próximas semanas, entre elas um trabalho sobre a utilização de produto configurável, assim como um super MBOM.
Se o caso narrado pelo cliente na abertura do post era a demanda por uma lista de produto, com o conteúdo exposto aqui, conseguimos resolver através de uma única solução totalmente continuada.
Sds,
Kastner