#0040: Enquanto as partes 1 e 2 da ISO 19650 focam na demonstração de conceitos e produção de informação colaborativa em uma cascata de projetos de relativa fácil absorção pelo mercado, a parte 3 já coloca o bode do modelo de ativo na sala e question
#0040: Enquanto as partes 1 e 2 da ISO 19650 focam na demonstração de conceitos e produção de informação colaborativa em uma cascata de projetos de relativa fácil absorção pelo mercado, a parte 3 já coloca o bode do modelo de ativo na sala e questiona: quem é o responsável por incluir as informações de ativos no empreendimento utilizando BIM? | ||
Shall consider (1/7) | ||
| ||
Seguindo nossa saga da série de textos sobre a ISO 19650 começamos a sair um pouco da zona de conforto daquilo que já tínhamos estudado e traduzido antes e começamos a mergulhar em águas um pouco mais profundas e que envolvem mais discussões a cerca de responsabilidades e esforços para execução. | ||
Para mim o entendimento da parte 3 foi de certa forma simples e por um motivo profissional bem forte: é um problema recorrente que me deparo com ele desde 2012 e o fluxo proposto na ISO era um fluxo já desenhado e executado algumas vezes em alguns projetos que participamos. | ||
Quer dizer então que tudo é novo nesta parte? Não é bem assim, tem muita coisa ali que já vivenciamos em projetos especificos de operação e manutenção e os fluxos de trabalho propostos vão bem na veia das dores do processo de FM. | ||
O mais difícil desta parte é a questão da maturidade do mercado para absorver o que estão propondo de forma prática, pois foram raras as vezes em que vi alguém executar o fluxo de coleta de informação para criação de um modelo de as-built utilizando modelos, existindo sempre uma guerra entre projeto vs construção para saber quem deveria ser o responsável por coletar e incluir as informações coletadas no modelo de informação. | ||
Isso confronta também com a falta de disseminação entre a operação dos ativos construídos de tecnologias que vão além do controle de tickets e chamados. | ||
Se você é projetista é legal fazer uma reflexão: quantos gigas de dados você tem no seu servidor que o operador da edificação nem sabe que existe um modelo sobre o assunto, ou se sabe que existe, não sabe se o negócio é de comer ou passar no cabelo não tendo a confiança de que pode realmente utilizar aquele modelo para fazer a manutenção do ativo. | ||
Enfim, saiba que o que vamos falar aqui é de um processo para captura e manutenção de informação em modelos de ativos construídos, é sobre isso que a parte 3 da ISO se trata. | ||
Vamos lá. | ||
Asset-Related EIR (2/7) | ||
Logo de cara já vem pedrada na cabeça em relação à parte 3 da 19650, pois o que o documento fala é que existe um acréscimo a ser feito ali nos requisitos da parte 1 para que a parte 3 possa funcionar legal, e este acréscimo se chama Asset-related Exchange Information Required (Asset-Related EIR). | ||
Se acharam que já estava bom de sopa de letrinhas agora, além da sopa, tem acompanhamentos para complicar a fixação de entendimentos e vai precisar de 50 reuniões da ABNT para definir como traduzir isso. | ||
Explicamos no primeiro texto desta série sobre a ISO 19650 os requisitos de informação gerais para digitalização a informação utilizando BIM, eram eles: requisitos de informação da organização, do ativo, do projeto e de troca de informação. | ||
O que acontece é que a troca de informação posta naquele momento era uma troca de informações para o desenvolvimento do trabalho colaborativo (desenvolvimento do projeto em si) e não sobre como trocar informação depois que a entrega do modelo de ativo está feita. | ||
Em outras palavras, você pode até entregar um COBIE ou modelo papel de pão para o proprietário, mas se ele precisar adicionar informações neste COBIE como ele deve fazer isso? É aí que surge o asset-related EIR que vai especificar como deve ser a produção colaborativa de informação para os proprietários quanto estes tiverem que fazer a manutenção das bases de informações dos modelos dos ativos (ou AIM). | ||
A diferença de desenho entre a parte 1 & 2 para a parte 3 está posta abaixo: | ||
Note que além do acréscimo do asset-related EIR nos requisitos de informação contratuais temos uma dança de cadeiras em que o AIR entra nos requisitos de informações das partes interessadas. | ||
Uma simples mudança que altera totalmente a lógica e o fluxo de trabalho da prática. | ||
2, 2-3 ou 3? (3/7) | ||
| ||
Bom, o que considerar no empreendimento já que existem duas normas da mesma série que que possuem requisitos iguais, mas diferentes? | ||
Aí vai entrar o entendimento do que a própria norma fala sobre quem seguir, pois primeiro ela estabelece que a ISO 19650-3 é destinada para os contratantes e que deve haver uma definição sobre a utilização ou não do processo da ISO 19650-2, pois se o processo for aplicado e o contratante desta parte 2 for diferente da parte 3, vai ser preciso assegurar que as responsabilidade da ISO 19650-2 e ISO 19650-3 estejam claramente definidas e comunicadas entre todas as partes interessadas do processo. | ||
Também será necessário transmitir as partes interessadas da parte 2 os requisitos do ativo da parte 3. | ||
Traduzindo, as partes interessadas em uma simplificação monstro de um cenário não tão atípico: um contratante (incorporadora, investidores, governo, etc) contrata um time de projetos que possui um coordenador que será responsável por fazer o projeto acontecer. Temos uma construtora que vai receber esses projetos e construir. Temos um condomínio que vai operar a edificação ao final do processo e deverá receber um manual do proprietário. | ||
Nesse cenário o contratante é quem decide se ele vai ou não considerar a manutenção futura do modelo do ativo (AIM) já em uma fase de produção colaborativa de projeto. Se ele resolver considerar, o condomínio vai ter que apresentar os requisitos de troca de informação para operação e manutenção dos modelos AIM já na parte de produção colaborativa. | ||
Existe certo ou errado aqui? Não, mas eu tenho uma tendência a crer que é melhor já considerar a parte 3 agora do que depois. | ||
Senta que lá vem a história da razão disso. | ||
CAFM (4/7) | ||
| ||
Era uma vez um projeto de uma instituição financeira fazendo um grande projeto no país em que logo no início do projeto foi combinado uma série de coisas que deveríamos respeitar para que ao final da construção os coordenadores do lado da instituição financeira tivessem cumprido todas as exigências de seus manuais internacionais. | ||
Pois bem, digamos que mesmo sem chamar de ROI, PIR, AIM, EIR, AIR tínhamos ali os requisitos da organização, do projeto, do ativo, e de troca de informação para projetos que tinha o seu modelo já sendo acrescido de algumas informações para operação. | ||
Qual foi o problema? Aos 49 do segundo tempo a instituição financeira tirou da cartola um manual para input de dados em seu software CAFM (Computer Aided Facility Management). O manual trazia um requisito para rateio de área de aluguel que não foi considerado em nenhum momento no desenvolvimento do projeto (e também nos custos). | ||
Resultado: foram 3 semanas de ajustes para fazer o modelo final ter todas as informações que o manual pedia, tudo porque o manual não foi considerado no início da produção colaborativa. | ||
Cláusula contratuais a parte, entendem a importância de pensar esses requisitos no inicio do processo e não no final? A depender do sistema que o contratante esta utilizando para manutenção alguém vai ter um esforço absurdo para adaptar as coisas depois de prontas. | ||
Eventos gatilho (5/7) | ||
| ||
Um conceito muito interessante que a parte 3 da 19650 acaba trazendo é a identificação dos eventos de gatilhos para o gerenciamento das informações do empreendimento. Estes gatilhos são de dois tipos diferentes: os previstos / planejados (foreseen / scheduled) ou reativos (quando não é possível ser previsto). | ||
Bom, os termos já meio que falam por si só: os previstos / planejados são aquelas manutenções que vão ser programadas e se tornar rotineiras, já os reativos são causadas por algum evento fora do controle dos operadores (as vezes a falta da primeira ocasiona a segunda, mas vida que segue). | ||
O que muda então nesse processo? Aqui muda muita coisa pois a norma estabelece que os gatilhos para produção e manutenção da informação nos modelos estão alocados em locais diferentes nos processos produção colaborativa. | ||
Na parte 2 da 19650 o gatilho para produção colaborativa esta colocado depois da contratação e mobilização de projetistas. Na parte 3 o gatilho para produção e manutenção de informação esta logo no início do processo, e por que? Bom, se for uma manutenção reativa a merda aconteceu e você vai ter que contratar alguém para arrumar e atualizar o seu modelo (AIM), logo, pode ser que seja necessário fazer um bid para a manutenção do ativo. (o desenho esta no item 4.1 da parte 3 da 19650 para quem quer ver). | ||
Se for um evento programado o processo vai ocorrer de acordo com os prazos pré-estabelecidos e também vai ter que passar por um bid para que ocorra, mas esta programado. Em ambos os casos os gatilhos é quem dão os inputs para definição dos requisitos para geração da informação nos modelos de manutenção. | ||
Talvez aqui a ISO desconsidere na parte 3 que o contratante possa ter um contrato de cobertura para o ativo que não necessite de um bid e seja possível iniciar o processo no mesmo ponto da parte 2, mas como dito em outros textos sobre esta série ISO, você pode adaptar o processo para a sua necessidade, no hard feelings. | ||
Fazendo todo esse processo bem feito é possível evoluir esse conceito do AIM para habilitar outros módulos de operações como Smart Buildings e Digital Twins. Entre 2016 e 2018 lideramos um projeto bem forte nesta linha e aprendemos muito no processo, no limite, da para criar uma lógica como a que desenhamos abaixo na época: | ||
| ||
Basicamente a ideia era aprender com o comportamento da edificação, afinal, quantas vezes vocês viram os projetistas voltando ao projeto para colher feedback dos usuários e saber se o que eles pensaram que iria ocorrer em relação ao comportomante de uso dos espaços de fato ocorreu? | ||
Gestor AIR/AIM (6/7) | ||
| ||
O melhor para o final? Talvez não o melhor, mas com certeza o mais polêmico. O que entra de recomendação no processo na parte 3 da 19650 é a recomendação para que exista uma parte interessada responsável pela manutenção das informações do ativo. | ||
Bem, até aqui se você é uma empresa de manutenção, não tem muita novidade. A novidade mesmo está no fato de existir essa personalidade quando a parte 2 e a parte 3 estejam combinadas em um contrato, aí é algo que vi poucas vezes no mercado e somente em empresas com um grau de maturidade muito grande em relação aos processos e tecnologias utilizadas. | ||
Neste ponto existe uma discussão que vai além do BIM: a responsabilidade do As-Built. | ||
As-Built esse que para ser feito neste processo de construção de AIR/AIM é preciso um esforço que não vai ser pequeno e para quem é o dono do ativo é lindo, mas e quem vai executar? Vai haver verba para tal? Só pedir sem pagar nada em troca é um pouco complicado no contexto do nível de esforço necessário. | ||
Além disso há de se ter bastante cuidado na geração dos modelos PIR e AIR em termos de coordenação das versões e revisões dos projetos. Após a leitura da parte 3 acredito que melhorou bastante o entendimento de como o AIM é gerado, mas ainda assim falta uma perna de como coordenar os modelos entre os estados no CDE e seus níveis de acesso. | ||
Não é algo simples, mas certamente ter alguém capacitado para tocar o bumbo resolve bastante coisa, uma dica é criar um checklist de atividades baseados nas partes 2 e 3 e a partir daí apontar na matriz de responsabilidade até onde vai a caixinha de cada empresa & profissional para não se perder. | ||
Afinal não existe super-herói, sozinho até dá para fazer bastante coisa, mas é junto que se vai mais longe (momento coach quântico, expedição Marins é o próximo passo). | ||
Organização (7/7) | ||
Já perceberam né? Pode não ter muitos segredos para utilizar os conceitos da série ISO 19650, mas tem muita, muita organização para que tudo funcione e de certo. | ||
Não da muito para utilizar BIM sendo desorganizado e este talvez seja o principal ensinamento da 19650. A parte 3 especificamente é preciso muita, muita organização e sincronização para construir um processo legal e que seja passível de confiança por parte do time de manutenção de utilizar o AIM no processo de manutenção do ativo. | ||
E uma coisa que aprendi na vida é que confiança é a relação da consistência pelo tempo (thanks Jeff Weiner). Na parte da operação com AIM é bem isso, a pergunta para se pensar: se você tiver que furar uma parede na cozinha da sua casa e você tem um AIM na sua mão, você furaria de olho fechado a parede? Se você pegar um cano, na próxima vez você vai furar de olho fechado ou vai questionar a informação que você tem em mãos? | ||
O dia-a-dia do cara na linha de frente de manutenção de um ativo vai ser decidir isso todo santo dia quando receber um AIM ao final da construção de um empreendimento. | ||
Pense nisso enquanto compartilha nosso conteúdo: | ||
Compartilhar conteúdo | ||
Seguir meu Canal | ||
Obrigado, | ||
Abs. | ||
Tiago Ricotta | ||
Publicado em 20 de Janeiro de 2022 às 12:20 |