segunda-feira, 25 de novembro, 2024
SKA: acesse o site
Início Institucional Criando padrões de Engenharia: Criar métodos descritivos não precisa ser uma dor...

Criando padrões de Engenharia: Criar métodos descritivos não precisa ser uma dor de cabeça

0

 

Por Guilherme Kastner,
Engenheiro de Aplicações na SKA

 

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 que todos entenderão os problemas que podem acarretar quando alguém que não é da 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. 

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. 

Gostou das dicas? Preencha os formulário abaixo para receber em seu e-mail mais conteúdos relacionados ao assunto.

 

DEIXE UMA RESPOSTA

Por favor digite seu comentário!
Por favor, digite seu nome aqui