Criando padrões de Engenharia – Parte 3: Códigos 2
Senhores,
Dando continuidade à série de postagens sobre códigos e os padrões de engenharia, passamos a falar dos métodos descritivos. Garanto a vocês que este método é o mais temerário para qualquer equipe e todos entenderão os problemas que poderão acarretar quando alguém "não de engenharia" toma as decisões de funcionamento das nomenclaturas.
Descritivos dimensionais
Descritivos em nomes de arquivos podem ser uma verdadeira dor de cabeça a todos. É muito comum começarmos a desenvolver um arquivo com determinado dimensional ou característica e ele virar outro componente. Imaginem uma série de componentes como descrito a seguir
Nome do arquivo Descritivo
VGI3-1-1500-1 Viga I 3” 1ª alma – 1500mm – tipo 1
PC100-200-2-1200-2 Perfil C 100 x 200 x #2 – 1200mm comprimento tipo 2
Os nomes, como podem ser vistos, são únicos e os componentes poderão ser alocados em qualquer pasta, inclusive em uma pasta exclusiva do tipo de cada componente. Poderia, por exemplo, criar uma pasta para cada tipo de perfil e colocar todas as variações de tamanho dos mesmos ali armazenados.
Qual o problema disso?
Nem todos os componentes são facilmente encontráveis ou gerenciáveis facilmente desta forma. Armazenamento para pasta por famílias de componentes nomeados funciona melhor para componentes comerciais e não para componentes fabricados.
Itens fabricados são desenvolvidos sob demanda de um determinando equipamento. É algo muito comum surgir alterações solicitadas a partir de uma demanda de setores de produção, requisição comercial ou por alterações de projetos. Muitos componentes são criados para determinado projetos. Caso os arquivos estejam amarrados por descritivos, ao alterarmos uma peça, poderemos ter que tomar alguma decisão:
• Renomear um arquivo e correr o risco de quebrar vínculos de referências; ou
• Criar um novo arquivo com um novo descritivo, sendo que o anterior corra o risco de nunca mais ser utilizado.
Continua depois da publicidade |
Eu conheço apenas um caso onde a aplicação de descritivos é o mais adequado para a peças de fabricação, na aplicação de ferramentas de automação de projetos. Nas demais situações, se trata de um tiro no pé, sinceramente.
Descritivos por atributos fiscais
Atributos fiscais são um mal sem fim junto a nomenclatura de arquivos de engenharia que deveriam ser banidos. Em mais de uma empresa eu vi situações do tipo:
Prefixo Descritivo
1- Componente com fabricação interna
2- Componente com fabricação terceirizada
3- Subconjunto
4- Montagem final
O problema é imaginar que esse tipo de atributo nos códigos pode causar um problema sem procedência nas engenharias, arquivos com geometrias duplicadas. Imaginem o cenário abaixo:
• Cria-se uma peça com foco para fabricação interna, pensando em um código “1-“
• A peça foi utilizada em inúmeros projetos, mas ao fabricar um lote de peças, as máquinas utilizadas no processo não estavam disponíveis. Com isso, chegou-se a conclusão que a peça deveria ser terceirizada.
• Como o sistema não suporta que o prefixo “1-“ seja aplicado para fabricação externa, o componente necessitará de um novo arquivo em duplicidade geométrica, mas contando com uma nova nomenclatura, iniciando em “2-“.
Quais os problemas que isso poderá ocasionar?
• Será necessária a alteração das montagens onde os componentes estão inseridos?
• Caso exista a necessidade de alteração geométrica, quais arquivos deverão ser alterados?
Quando se trata de nomenclatura de montagens, coisas similares ocorrem. Um conjunto final pode virar subconjunto, assim como o contrário também ocorre.
Tudo tem que ser pensado para que seja o menos traumático na aplicação desse método de codificação. Lembro que esse tipo de codificação foi visto em mais de um caso, nunca achei uma facilidade prática e funcional a isso.
Em todas as vezes que vi esse método, se tratava da equipe de implantação de um sistema ERP tomando uma decisão com o administrativo da empresa cliente, sem a consulta do time de engenharia. Quando uma regra de codificação duvidosa estiver em uso, teremos de pensar a origem da mesma.
Na próxima postagem estaremos falando de famílias e subfamílias em códigos de conjuntos.
Sds,
Kastner
Técnico de aplicações da SKA Automação de Engenharias desde setembro de 2004. Trabalhou com diversas Soluções Autodesk, SolidWorks. Nos últimos anos o trabalho tem sido focado na melhoria da comunicação das engenharias com os seus clientes dentro das corporações como a fábrica, administrativo e outros setores.
Mais artigos:
- 11/12 O que as fazendas verticais nos mostram em relação a manufatura aditiva?
- 05/10 8 justificativas técnicas para o processo de gestão de mudanças
- 07/09 Ensino de engenharias e novas demandas de 2020
- 03/08 Os 3 sistemas essenciais para manter uma fábrica em operação
- 01/07 Suporte a projetos de instalações
