Al participar como coordinador BIM en la PMO que lleva la gestión del portafolio de proyectos de una de las vicepresidencias (VP) de Antamina (mina de gran envergadura en Perú) la solicitud que me presentaron fue la de implementar BIM, luego de un par de reuniones a la interna de la PMO y luego con los que dirigían la VP les comunicaba que tomando en cuenta el escenario que planteaban lo que podría generar era la documentación base para una implementación BIM, ya que una implementación a nivel organizacional requería de un tiempo mayor del que se disponía. Esta propuesta fue aceptada, por lo que di inicio a generar el primero de siete documentos.
Debo agregar agregar que en paralelo a generar esta documentación, daría soporte a nivel BIM de una planta pre piloto que estaba en etapa de licitación, al estar esta etapa en curso no genere los requerimientos de información del cliente, una plantilla del Plan de ejecución BIM; aun así en reuniones internas expresaba porque la necesidad y la utilidad de estos documentos donde el objetivo principal es que lo solicitado por el cliente/contratante converse con los entregables a presentar por el consultor.
Para tangibilizar la identificación de requerimientos de la implementación BIM, genere un informe tomando como punto de inicio los requerimientos del cliente/owner, que se habían decantado por el uso de una plataforma (software) que contaba con distintos módulos para la gestión y administración de los archivos que se generarían en cada proyecto. Es decir, que cuenta con un módulo para el control documentario (entorno común de datos - ECD), módulo para modelado BIM 3D, para generar constructibilidad del modelo BIM 3D y para la previsualización.
El escenario se ponía más interesante, en paralelo a generar la documentación BIM tendría que integrar el uso gradual de esta plataforma.
.png?width=2074&height=1064&name=Cristhi%C3%A1n%20Solano%20(1).png)
Para generar la documentación inicialmente tuve que hacer un reconocimiento de cuáles eran los flujos de trabajo utilizado desde la periferia (esto enfocado a las etapas de ingeniería conceptual y pre factibilidad); elaborando estos flujos de trabajo ubique dos puestos/roles que se tendrían que integrar al proceso y que a nivel organizacional siempre son de ayuda por un lado estaba un programador quien puede dar solución (a nivel de software por temas de interoperabilidad por ejemplo) generando y no teniendo que adquirirla, más aún, cuando la solución en el mercado no existe o si existe no se ajusta a las necesidades específicas del proyecto. El otro puesto era el de un control documentario que tuviera referencias de las distintas etapas del proyecto a nivel de ingeniería o en su defecto capacitar al colaborador de TI que estaba a cargo de dicha función.
La revisión de la infraestructura existente (hardware) fue un punto a tomar en cuenta para luego no tener inconvenientes al utilizar la plataforma seleccionada tomando en cuenta la magnitud del peso de los archivos que se generarían en proyectos congestionados por distintas disciplinas.
Lo mencionado líneas arriba también lo tendría que hacer con las empresas con las que trabajaba o había trabajado el owner ahí es donde me fue de utilidad el haber laborado en distintos proyectos con distintas empresas y en distintas etapas, más aun los compañeros con los que trabaje en su momento estaban en empresas en las que aún no he laborado cubriendo así un abanico más amplio para poder tener referencias y poder ubicar cuellos de botella con los que se encontraban distintos contratistas y consultores al trabajar con el owner.
Podemos visualizar que todo comienza por mapear procesos, personas e infraestructura con el objetivo de optimizar los flujos de trabajo. El trabajo colaborativo entonces no solo aplica a trabajar de la mano entre distintas disciplinas sino también transversalmente a los distintos stakeholders que participan del proyecto. Leer más
