Cómo digitalizar una obra sin detener el proyecto
La obra lleva meses en ejecución. El cronograma existe, los reportes salen cada semana y cada área ha construido su propia forma de trabajar.
Costos tiene sus Excel. El planner
actualiza el cronograma. Campo reporta avances. Oficina técnica administra
planos, RFIs y observaciones. Gerencia recibe finalmente un dashboard.
Entonces aparece la propuesta: “Tenemos
que digitalizar la gestión del proyecto”.
Y surge una preocupación legítima:
¿Cómo cambiar la forma de trabajar sin
desordenar un proyecto que ya está en marcha?
Ese es probablemente uno de los principales
frenos a la transformación digital en construcción. No es necesariamente falta
de interés en tecnología. Es el temor a que la migración genere más trabajo,
pérdida de información, resistencia del equipo o incluso afecte la ejecución.
La respuesta no es cambiar todo de golpe.
La respuesta es diseñar la transformación
como diseñaríamos cualquier otro proyecto: con alcance, secuencia,
responsables, riesgos y una estrategia de transición.
El problema no es Excel. Es la
fragmentación
Excel sigue siendo una herramienta
extremadamente útil. El problema aparece cuando termina funcionando como la
infraestructura principal de control de un proyecto complejo.
Un archivo para horas-hombre. Otro para
costos. Otro para avances. El cronograma en una aplicación distinta.
Fotografías en WhatsApp. Documentos en correo. Información histórica en discos
locales.
El webinar de SEMCO describe precisamente
ese escenario: cuando la información permanece aislada, encontrar versiones,
trasladar datos manualmente y consolidar reportes consume horas que podrían
dedicarse a analizar ruta crítica, recursos, riesgos y desempeño. Transcripción
webinar oracle 21…
Y hay una consecuencia aún más importante.
Cuando campo y oficina técnica trabajan con
información diferente, la organización puede estar tomando decisiones
correctas sobre información incorrecta o desactualizada. Transcripción
webinar oracle 21…
McKinsey ha identificado la fragmentación
como una de las razones por las que la digitalización de ingeniería y
construcción resulta particularmente compleja: cada proyecto conecta múltiples
especialidades, contratistas y organizaciones, haciendo que implantar una nueva
forma de trabajo sea mucho más que instalar software. McKinsey
& Company
Por eso, digitalizar no significa sustituir
Excel.
Significa reducir las rupturas de
información entre planificación, ejecución y decisión.
El segundo error: digitalizar un proceso
desordenado
Existe una tentación frecuente: comprar
tecnología y después definir cómo utilizarla.
El resultado suele ser un proceso malo
ejecutándose en una herramienta mejor.
El webinar lo resume con una idea
particularmente relevante: podemos tener el mejor software y las mejores
computadoras, pero si responsabilidades, comunicación y flujos siguen desordenados,
lo único que conseguimos es “caos digital”. Transcripción webinar oracle
21…
Un RFI es un buen ejemplo.
Antes de hablar de plataformas deberíamos
saber: quién lo emite, quién realiza la primera revisión, quién aprueba, cuánto
tiempo tiene cada responsable, qué ocurre cuando vence el plazo y dónde queda
registrada la decisión.
Después digitalizamos ese flujo.
No al revés.
PMI plantea la transformación digital bajo
una lógica similar: el éxito no depende únicamente de invertir en tecnología,
sino de alinear personas, procesos y cultura con las herramientas
elegidas. Instituto
de Gestión de Proyectos
El tercer error: intentar transformar
toda la organización al mismo tiempo
Imagine que un equipo lleva ocho años
trabajando con procesos conocidos y, el lunes, recibe cinco módulos nuevos,
nuevas credenciales, nuevos workflows y una instrucción: “Desde hoy trabajamos
así”.
Técnicamente puede ser posible.
Organizacionalmente puede ser una mala
decisión.
McKinsey documentó el caso de un gran
contratista que durante cinco años realizó múltiples iniciativas digitales.
Algunas funcionaron durante los pilotos, pero la organización no logró
escalarlas; trabajadores de campo y oficina terminaron regresando a sus
antiguos métodos. McKinsey
& Company
El aprendizaje es importante:
una implementación técnicamente correcta
puede fracasar por adopción.
En el webinar se propone una alternativa
más pragmática: comenzar con un proyecto piloto de menor complejidad, trasladar
información progresivamente y permitir durante la transición cierta convivencia
entre el método existente y el nuevo sistema. Transcripción webinar oracle 21…
Una ruta de transición que no detenga la
obra
Una migración controlada puede
estructurarse en seis movimientos:
- Diagnosticar antes de comprar.
Identificar dónde se pierde más tiempo: consolidación de avances,
versiones, actualización del cronograma, RFIs, costos, riesgos o
reportabilidad.
- Definir el proceso objetivo.
Establecer responsables, permisos, tiempos de respuesta y reglas antes de
configurar la plataforma.
- Elegir un piloto controlable. Puede
ser un proyecto pequeño, un frente específico o un solo proceso crítico.
- Migrar primero la información indispensable. Cronograma vigente, línea base, calendarios, recursos y datos
necesarios para continuar operando. El histórico puede incorporarse
posteriormente según valor y necesidad.
- Trabajar temporalmente en paralelo cuando el riesgo lo
justifique. El objetivo no es mantener dos
sistemas indefinidamente, sino validar la nueva operación sin comprometer
la ejecución.
- Escalar después de medir. Tiempo
para actualizar información, calidad del cronograma, velocidad de
respuesta, errores, adopción y capacidad de análisis deben demostrar que
el nuevo proceso genera valor.
La lógica es simple: migrar por
capacidad, no por ansiedad tecnológica.
Un caso real: 126.000 actividades
migradas sin interrumpir el control
El proyecto internacional ITER
ofrece una referencia especialmente relevante.
El programa necesitaba sustituir procesos
fragmentados de planificación por una solución unificada. Según Oracle, la
transición hacia Oracle Primavera Cloud incluyó 30 proyectos, cuatro
cronogramas y aproximadamente 126.000 actividades, además de miles de
relaciones externas entre actividades críticas.
Al mismo tiempo se incorporaron alrededor
de 700 usuarios.
Lo relevante para esta discusión es que la
migración se realizó sin interrumpir el reporte mensual de KPI ni las
métricas de Earned Value del programa. Oracle
Ese caso desmonta una de las ideas más
frecuentes alrededor de una transformación:
migrar no necesariamente significa
empezar nuevamente ni detener la operación.
Oracle contempla, por ejemplo, importación
hacia Primavera Cloud mediante archivos P6 XML/XER, Microsoft Project y Excel,
además de mecanismos de integración para sincronizar información entre
plataformas. Oracle
Oracle Primavera Cloud como aliado, no
como punto de partida
Aquí es donde una plataforma como Oracle
Primavera Cloud (OPC) comienza a tener sentido.
No porque “estar en la nube” sea el
objetivo.
Sino porque permite que planificación,
cronograma, recursos, riesgos, costos y colaboración dejen de funcionar
únicamente como archivos separados y comiencen a formar parte de un sistema de control
de proyectos.
En el propio webinar, la demostración
evoluciona desde un Excel aislado hacia Primavera P6 y posteriormente hacia
OPC, donde la información puede analizarse mediante dashboards, trazabilidad de
actividades, archivos, recursos y análisis de riesgos. Transcripción webinar
oracle 21…
Oracle también permite configurar la
incorporación de datos provenientes de P6, Microsoft Project o Excel, lo cual
facilita plantear una adopción progresiva en lugar de un “big bang”
tecnológico. Oracle
El caso de BHI, contratista que
trabaja en construcción, energía, infraestructura y minería, muestra el
resultado de esa lógica: tras estandarizar su programación en Primavera Cloud,
Oracle reporta un incremento del 50% en la eficiencia de sus procesos de
scheduling, además de mejoras en calidad y salud del cronograma. Oracle
No debe asumirse que ese porcentaje será
replicable en todas las organizaciones. Lo relevante es el mecanismo: estandarización,
acceso compartido y una misma fuente de información para tomar decisiones.
La transformación no termina cuando el
sistema entra en producción
Una implementación termina técnicamente cuando la plataforma funciona.
Una transformación termina cuando el equipo
prefiere el nuevo proceso porque le permite trabajar mejor.
El webinar insiste en centrar la adopción
en beneficios y no en la herramienta, capacitar progresivamente y conectar
campo con oficina técnica. Transcripción webinar oracle 21…
Ese punto es decisivo.
El planner debería dedicar menos tiempo a
consolidar archivos y más a analizar desviaciones. El residente debería recibir
información antes de ejecutar. La gerencia debería discutir escenarios y no
versiones. Y oficina técnica debería poder reconstruir qué ocurrió, quién
decidió y con qué información.
Ese es el verdadero salto digital.
No pasar de Excel a la nube.
Sino pasar de administrar archivos a
administrar decisiones.
Y cuando la transformación se diseña
correctamente, el proyecto no necesita detenerse para modernizarse.
Puede mejorar mientras sigue avanzando.
No hay comentarios.