Por que refazemos o IDS em cada projeto?

Doze projetos, doze IDS, zero biblioteca.

Cada projeto novo começa do zero. O gestor abre o editor de IDS, cria as facetas, define as propriedades, calibra a cardinalidade, testa, corrige, testa de novo. Seis semanas depois, o IDS está pronto. No projeto seguinte, o mesmo gestor faz tudo outra vez — porque o IDS anterior não é reutilizável. Estava calibrado para aquele modelo, aquele schema, aquela nomenclatura. E ninguém versionou, documentou ou publicou numa biblioteca institucional.

O IDS é artefato técnico complexo. Cada specification tem applicability com faceta Entity e possivelmente Classification ou Property; requirements com facetas calibradas por cardinalidade, dataType e restriction; e ifcVersion declarado. A buildingSMART publica listas de subentidades de IfcElement para referência — mais de 140 entradas em IFC4X3. Sem biblioteca institucional, o redator redigita essas listas a cada projeto, com risco de omissão e erro a cada vez.

O custo de refazer o IDS não é só o tempo. É a perda de melhoria acumulada. O IDS do projeto 1 tinha um defeito de faceta que foi corrigido. O IDS do projeto 2 foi escrito do zero e herdou o mesmo defeito. O IDS do projeto 3 corrigiu outro defeito — mas sem registro, o projeto 4 vai repetir os dois.

A §11.2 da ABNT NBR ISO 19650-1 define o nível de informação necessária como organizacional, não como pontual. Se o LOIN é organizacional, o IDS que o traduz também deveria ser. Mas sem biblioteca versionada, o IDS morre com o projeto.

1. 1

   IDS escrito do zero em cada projeto · nenhum IDS anterior é reutilizado. Cada projeto começa com facetas novas, propriedades novas, restrictions novas.

2. 2

   Semanas de elaboração recorrentes · o tempo de elaboração do IDS se repete a cada projeto sem redução. Não há ganho de escala.

3. 3

   Defeitos recorrentes entre projetos · o mesmo erro de faceta, cardinalidade ou restriction aparece em IDS de projetos diferentes. Ninguém aprendeu com o anterior.

4. 4

   Lista de entidades redigitada a cada vez · o redator lista manualmente as subentidades de IfcElement no IDS, em vez de puxar de biblioteca curada.

5. 5

   Nenhum repositório institucional de IDS · os IDS de projetos anteriores vivem em pastas de projeto, sem catálogo, sem busca, sem versão.

1. 1

   IDS tratado como entregável de projeto · cada IDS é artefato do projeto, não do portfólio. Quando o projeto encerra, o IDS arquiva junto.

2. 2

   Sem biblioteca institucional · a organização não tem repositório versionado de specifications reutilizáveis. Cada redator começa do zero.

3. 3

   IDS calibrado demais para o modelo específico · o IDS foi escrito para o modelo de um projeto, com entidades e Psets que só existem naquele contexto. Não é portável.

4. 4

   Sem padrão de nomenclatura entre IDS · cada redator nomeia specifications, facetas e restrictions de maneira diferente. Reutilizar exige decifrar antes.

5. 5

   Sem processo de revisão e publicação · o IDS não passa por ciclo de aprovação e publicação institucional. Cada um é draft perpétuo.

1. 1

   Custo recorrente sem ganho · a organização paga o custo de elaboração do IDS a cada projeto sem acumular melhoria. O investimento não gera ativo.

2. 2

   Defeitos que se repetem · sem registro de lições, o mesmo erro de faceta ou restriction reaparece em projetos subsequentes.

3. 3

   Inconsistência entre projetos · cada IDS exige propriedades diferentes para o mesmo tipo de entregável. O fornecedor não sabe o que esperar.

4. 4

   Dependência de indivíduo · o IDS depende de quem sabe escrever. Se o redator sai, o conhecimento vai junto.

5. 5

   Escalada de complexidade · sem biblioteca, cada IDS novo tenta ser mais completo que o anterior. A complexidade cresce sem curadoria.

Curto prazo (30 dias):

1. Inventariar os IDS existentes. Listar todos os IDS de projetos anteriores com suas specifications, entidades, Psets e versão de schema.

2. Identificar specifications reutilizáveis. Separar as specifications que são genéricas (servem para qualquer projeto da tipologia) das que são específicas do contexto.

3. Publicar a primeira versão da biblioteca. Reunir as specifications genéricas em repositório versionado com nomenclatura padronizada.

Médio prazo (60-90 dias):

4. Instituir ciclo de curadoria. Após cada projeto, as lições aprendidas atualizam a biblioteca: defeitos corrigidos, specifications novas, restrictions refinadas.

5. Adotar referência bSI para listas de entidades. Usar as listas de subentidades publicadas pela buildingSMART como base, em vez de redigitar.

6. Padronizar nomenclatura. Criar convenção de nomes para specifications, facetas e restrictions que permita busca e reutilização sem decifrar.

1. 1

   Biblioteca institucional, não IDS de projeto · o IDS é ativo organizacional versionado, não entregável de projeto que morre no arquivo.

2. 2

   Partir da biblioteca, calibrar para o contexto · cada projeto puxa specifications da biblioteca e calibra — não recria do zero.

3. 3

   Listas de referência bSI, não digitação manual · as subentidades de IfcElement (140+ em IFC4X3) vêm de publicação curada, não de memória do redator.

4. 4

   Curadoria contínua · cada projeto devolve lições à biblioteca: defeitos corrigidos, restrictions refinadas, specifications novas versionadas.

• buildingSMART IDS 1.0Information Delivery Specification. Cada specification tem applicability e requirements com facetas, cardinalidade, dataType e restriction. A complexidade justifica biblioteca reutilizável — reescrever a cada projeto é risco e desperdício. A bSI publica listas de subentidades de IfcElement para referência.
• ABNT NBR ISO 19650-1:2022Conceitos e princípios. §11.2 define o nível de informação necessária como organizacional. Se o LOIN é organizacional, o IDS que o traduz também deveria ser — não pontual por projeto.
• ABNT NBR ISO 19650-2:2022Fase de entrega. §5.2.1 c) exige critério de aceitação por requisito. Se o critério é redigido do zero a cada vez, a consistência entre projetos é casualidade.
• ABNT NBR ISO 7817-1:2024Level of information need (LOIN). O LOIN é a origem do IDS. Se o LOIN é estável entre projetos de mesma tipologia, o IDS que o traduz também pode ser — desde que exista biblioteca.
• ISO 29481-3Information delivery manual, Part 3. Formaliza o IDS. A especificação permite modularidade de specifications — cada specification é unidade reutilizável por desenho.