BIM Data Enrichment e Gestão da Informação

#0043: Definidas as responsabilidades de cada parte interessada no empreendimento, apontamos alguns caminhos que podem entregar resultados muito interessantes na manipulação de informações em modelos ao longo do ciclo de vida de um ativo.

Volta uma casa (1/7)

Estudando alguns métodos de trabalho com alguns clientes neste início de ano foi possível tirar do papel algumas ideias represadas de vidas profissionais passadas e garantir alguns resultados bem interessantes ao longo do ciclo de desenvolvimento de alguns ativos.

Um ponto que sempre me incomodou foi o fato de algumas empresas acreditarem que seus profissionais deveriam ser super-pessoas que sabem absolutamente de tudo de todo o processo construtivo de um empreendimento, ou seja, o profissional além de deixar o projeto bonito e vendável, ainda tem que saber e incluir nos mínimos detalhes toda informação do ciclo de vida de construção.

Esta abordagem para mim é clara que não possui escala, e escala é sempre aquilo que buscamos para facilitar os fluxos de trabalho tendo como chave a experiência das pessoas, vocês já leram aqui neste espaço que solução que só uma pessoa consegue usar não é uma solução, continua sendo um problema, então ter um fluxo fácil e de boa comunicação é fundamental.

E onde entra a questão de Data Enrichment ou Enriquecimento de Dados para simplificar a ideia? Ela entra quando você define os requisitos de informação do projeto, mas também no momento de dividir as responsabilidades e locais de inclusão das informações.

Conceitualmente, Enriquecimento de Dados é o seguinte:

“O enriquecimento de dados refere-se ao processo de anexar ou aprimorar dados coletados com contexto relevante obtido de fontes adicionais”

O ponto aqui são os dados coletados com contexto relevante de fontes adicionais, fontes essas podendo ser de fabricantes, experiência profissional, cálculos, catálogos etc.

Para dar um exemplo claro: modelos de projetos existem aos montes, mas muitas construtoras recebem esses modelos e precisam estudar as melhores alternativas para um planejamento de obra adequado. Diferentes profissionais precisam seguir com a especificação e compra dos produtos. Existem diversas informações a serem incluídas para operação e manutenção. E por aí vai.

Neste sentido, quanto mais livre e possível for as empresas e profissionais enriquecerem os modelos com informações melhores serão os fluxos de trabalhos e otimização de tecnologias, processos e profissionais.

Ignorando o fato de onde é gerada a informação e partindo direto para o consumo, gerenciamento e enriquecimento, na sequência desenvolvemos algumas ideias do que pode ser feito para melhorar este fluxo.

PropertySets (2/7)

Gerar a informação e poder trabalhar e gerenciar a mesma na sequência sem depender do software de origem é algo que eu considero crucial nesta história, a grande questão é como fazer isto hoje? IFC tende a ser a melhor opção.

Sendo um schema de dados é até relativamente simples conceitualmente enriquecer um arquivo IFC com o tipo de dado que você necessita, existe ferramentas até gratuitas para fazer este tipo de coisa.

O importante é fazer um estudo da documentação para entender o tipo de dado e onde ele deve ser incluído e/ou relacionado. A questão de UX entra em cena novamente aqui, pois ser possível não quer dizer que seja fácil, ir por este caminho pode ter seus percalços e mesmo dúvidas.

Por exemplo: é possível acrescentar um novo Property Set em elementos no schema IFC, mas o Ownerhistory do objeto deveria registrar a informação dos profissionais que estão fazendo a edição? Eu diria que sim, da gama de soluções que eu conheço, nenhuma tem essa possibilidade (mas certeza que alguém deve trabalhar isso..), um exemplo abaixo:

No limite se você quiser inclusive deletar elementos de um IFC e manter estes no projeto bastaria criar um Ownerhistory mudando o status para .DELETED.. Isto é de uma beleza poética muito legal na minha opinião.

Neste ponto do Ownerhistory, uma coisa curiosa retirada direto do site da BuildingSMART: “Direct reference to the end user who currently "owns" this object. Note that IFC includes the concept of ownership transfer from one user to another and therefore distinguishes between the Owning User and Creating User.”

A definição que é colocada é a de transferência de "dono" daquela entidade. Já consegui no IFC transferir de dono o PropertySet e seu conjunto de informações, mantendo o Objeto com o "dono" original, mas infelizmente soluções de mercado não mostram isso a olho nu. 😭

Na minha opinião o conceito de Ownerhistory é muito mal aproveitado, existe a possibilidade de fazer alguns controles muito legais em relação ao estado e ownership das entidades.

IfcElementAssembly (3/7)

Certamente, para mim, é talvez um dos conceitos mais poderosos e ignorados pelo mercado: o IfcElementAssembly.

Se você nunca trabalhou com produtos de manufatura, existe um conceito que é o de montagem dos elementos, ou seja, existe um elemento pai que é formado por diversos objetos filhos, exemplo: um motor completo é feito de diversas peças, parafusos e pormenores, mas o conjunto de tudo isto é o que chamamos de Assembly, ou motor.

Trazendo para a vida AEC, em processos industrializados faz muito sentido trabalhar os objetos como Assemblies/Montagens, porque ao contrário de processo tradicionais em que você vai construindo a obra de maneira unitária, se estamos industrializando quer dizer que estamos formando frentes de trabalho que vão montar/instalar as coisas como uma linha de montagem.

O agrupamento de elementos para frentes de serviço usando o IfcElementAssembly pode facilitar muito a gestão da execução e orçamentação dos objetos e, no limite, até uma otimização de codificação com IfcCost/IfcTask, por exemplo.

Novamente, algumas coisas não são facilmente manipuláveis atualmente, mas nos processos em que usamos esta classe como forma de agrupamento de objetos para frentes de serviço, acabou sendo uma forma bastante interessante de enriquecer o modelo para melhor controle do que esta sendo executado nos CDEs da vida.

Conceitualmente tem diversos pontos a serem considerados aqui, mas não vou me aprofundar nesta discussão, de uma olhada no conceito da BuildingSMART sobre o tema e veja a beleza que isto pode ter nos processos que você esta gerenciando (só valide que é possível você exportar isto de onde você esta gerando a info).

# Hashtags (4/7)

Em tempos mais longínquos não queríamos trabalhar com vários códigos ou tabelas assim como algumas classificações e formas de trabalho acabam fazendo, mesmo que hierarquicamente o conceito seja mil vezes mais fácil de entender.

Bom, indo a fundo no conceito de facetado do sistema de classificação da Omniclass, mesmo que a forma apresentada seja algo completamente insano e de difícil escala, o que imaginamos foi uma simplificação massiva do conceito para resolver um problema complexo à época que era a da “reengenharia” (que de engenharia não tinha nada, era só uma troca de produtos mais caro por outros mais baratos).

Qual era a ideia então? Simples, esquece especificação no modelo, cria-se algo genérico e fora utiliza-se do conceito de facetagem para incluir uma hashtag no objeto e assim fazer a especificação ultra rápida do elemento.

Exemplo: qual a cuba dos banheiros? Whatever no modelo, não quero saber de SKU nesta fase, mas orçamento/suprimentos validando com o time de projetos tem sua lista de produtos homologados e registra a informação da especificação fora da modelagem através do que chamamos na época de hashtag, que como o próprio nome diz, era #deca #P6017.

Lá no texto sobre construção descentralizada este tipo de abordagem cai como uma luva e, principalmente, UX na veia, não precisa ter 200 horas de treinamento para aprender operar esta lógica.

Claro que a coisa tem um pouco mais de tempero e esforço para ser trabalhada e executada, mas no limite, não só de especificação se vive a #, também existe a possibilidade de fazer isto com planejamento, facilities, conceitos e etc.

Criatividade vai longe.

Adaptações (5/7)

Então quer dizer que a partir de agora a gente faz downgrade de tudo, deixa tudo genérico, não se importa com nenhuma informação e o povo que vem pela frente do processo que se exploda para saber o que queremos comunicar?

Não é bem isso que estamos propondo aqui até porque essa é a receita do fracasso, quando equipes não assumem a responsabilidade dos seus próprios atos e decisões, mas já ouvi este tipo de comentário (que no final do dia tem seu fundamento se não é explicado direito).

O que propomos é simplesmente uma questão de pensar a complexidade do processo construtivo e queimar os neurônios para simplificare deixar mais fácil este processo, mas sem que isso seja simplório.

Quando as pessoas enxergam a possibilidade de gerenciar a informação utilizando modelos, muitas vezes o primeiro passo que elas fazem é se vislumbrar com as possibilidades e entupir o projeto de tudo e qualquer detalhe (pense que isto também acontece nos requisitos de informação, BEPs e por aí vai).

Além do vislumbre, existe um mecanismo natural de defesa nesse processo que é o de se garantir em caso das coisas derem errado e a depender da cultura empresarial vigente, é quase uma questão de sobrevivência.

Isto que propomos funciona para tudo? Se não houver o mínimo de senso de ownership e responsabilidade das coisas, não. Se a cultura for colaborativa e responsável, sim, funciona.

Aí é analisar o contexto da empresa.

Responsabilidades e Motivações (6/7)

Dê o nome bonito que for, matriz RACI, matriz de responsabilidade, permissões e o que for, mas entenda que você pode dar todas as condições possíveis para o time jogar, mas se ele não quiser chutar a bola (ou chutar para fora), não tem muito o que fazer.

Em determinadas empresas enriquecer de informação um modelo já foi vencida essa questão há muito tempo, o grande ponto é a que custo?

Processos sempre podem ser melhorados, principalmente com a tecnologia Tony Stark que temos hoje em dia, é praticamente pensar e ter aquela possibilidade feita se você tem os recursos necessários para tanto.

Lógico que a questão custo também vai ser considerada na mudança: custou muito para implantar e custa mais ainda para sair, mas geralmente a conta não é tão simples assim pela quantidade interminável de custos ocultos envolvida no processo.

Então entender as responsabilidade e motivações dos profissionais nos projetos é fundamental para conseguir sucesso em gestão de mudança, é difícil, principalmente pela complexidade de AEC, mas dá sim para fazer gestão simplificando a complexidade.

Risco (7/7)

Já estive dos vários lados da mesa: do que compra, de quem vende, de quem fornece, de quem decide, de quem ajuda a decidir, de quem entrega e claro, de que se fode.

Estando nestes vários papéis uma coisa que você aprende é que não existe, definitivamente, uma única forma de fazer as coisas.

Os melhores profissionais que trabalhei eram aqueles que mais ideias criativas tinham, o legal de entender os conceitos e teorias é ter mais embasamento para botar a pele em jogo, no final do dia é aquilo do próprio mercado financeiro: quanto maior o risco, maior o prêmio (ou o tombo).

O inconformismo de como fazemos as coisas hoje é combustível para pensar diferente e inovar, isto é muito importante. Agregar na discussão com a antítese é também importante, mas sem nunca perder a ternura.

Este hiato de uma semana foi bom para organizar e testar algumas coisas, vamos compartilhando infos por aqui e se quiser ajudar no crescimento do canal só clicar nos botões abaixo:

Obrigado,

Abs.

Tiago Ricotta

Publicado em 16 de Fevereiro de 2022 às 19:32