Metodología Vessel Baseline y Project Layer: optimización de la gestión de la documentación marítima
30.09.2026
Gran parte de la documentación operativa marítima se reescribe desde cero para cada proyecto, aunque el núcleo del documento (las especificaciones del buque, los datos de los equipos y los procedimientos estándar) a menudo no cambia de un proyecto a otro.Un buque realiza operaciones similares de forma repetida: una serie de trabajos de remolque, proyectos offshore, viajes polares. El buque es el mismo. Los equipos son los mismos. Sin embargo, cada nuevo contrato suele implicar reconstruir toda la documentación, reescribiéndola de la primera a la última página, simplemente porque así es como siempre se ha montado la plantilla.
Lo que realmente cambia suele ser limitado: la ruta, la tarea concreta, las condiciones de operación o los requisitos particulares de un cliente o proyecto. Pero como el documento se redacta en un único archivo y de una sola vez, el contenido específico del buque y el contenido específico del proyecto se reescriben juntos, cada vez, lo que convierte la preparación de la documentación operativa marítima en un esfuerzo repetido y en gran parte duplicado.Existe una forma más precisa de estructurar este tipo de gestión documental del buque: separar el Vessel Baseline (lo que describe al propio buque) del Project Layer (lo que describe la operación concreta), dos componentes con ciclos de vida distintos y reglas de revisión diferentes.
Lo que realmente cambia suele ser limitado: la ruta, la tarea concreta, las condiciones de operación o los requisitos particulares de un cliente o proyecto. Pero como el documento se redacta en un único archivo y de una sola vez, el contenido específico del buque y el contenido específico del proyecto se reescriben juntos, cada vez, lo que convierte la preparación de la documentación operativa marítima en un esfuerzo repetido y en gran parte duplicado.Existe una forma más precisa de estructurar este tipo de gestión documental del buque: separar el Vessel Baseline (lo que describe al propio buque) del Project Layer (lo que describe la operación concreta), dos componentes con ciclos de vida distintos y reglas de revisión diferentes.Vessel Baseline frente a Project Layer
Vessel Baseline: el núcleo estable, vinculado al buque:- Especificaciones del buque y disposición general
- Datos de los equipos clave (equipos de remolque, DP o de clase hielo, según el tipo de operación)
- Procedimientos de emergencia estándar
- Procedimientos estándar de comunicaciones y guardia
- Parámetros y configuración de la operación concreta
- Ruta y plan de travesía
- Condiciones de operación: meteorología, hielo, límites de estado del mar, profundidades
- Evaluación de riesgos específica del proyecto
- Cualquier requisito no cubierto por el Baseline: procedimientos no estándar específicos del cliente o del proyecto
Verificación de aplicabilidad y gestión de cambios
Un Baseline aprobado para un proyecto no queda automáticamente habilitado para el siguiente. Antes de referenciarlo en un nuevo Project Layer, es necesario confirmar expresamente su aplicabilidad:- ¿Han cambiado los equipos descritos en el Baseline?
- ¿Siguen siendo válidos para el nuevo proyecto los certificados a los que hace referencia el Baseline?
- ¿Han cambiado los límites operativos del buque?
- ¿Corresponde el Baseline al tipo de operación que requiere el nuevo proyecto?
Control de versiones
Sin un seguimiento explícito de versiones, separar el Baseline y el Project Layer genera más confusión que valor. El principio es sencillo: cada documento de Project Layer indica el número de revisión del Baseline en el que se basa, una fecha de aprobación y el estado del proyecto, es decir, la información mínima que cualquiera que abra el documento necesita ver de un vistazo.En la práctica, este tipo de seguimiento en Excel o Word solo funciona mientras lo gestiona una sola persona y nada avanza deprisa. En cuanto interviene más de una persona o se desarrollan varios proyectos en paralelo, tiende a degenerar en una carpeta de archivos con nombres como Baseline_v2_final_FINAL(1).docx, donde nadie puede decir con certeza qué versión es la vigente. Sin un procedimiento interno estricto o un sistema específico de gestión documental y de registros (EDMS/RMS), el control de versiones acaba dependiendo de la memoria de una sola persona, que es exactamente el tipo de riesgo que el enfoque Vessel Baseline pretende eliminar.Esto solo funciona cuando el seguimiento de versiones se apoya en una disciplina interna firme o en una herramienta específica, no en una carpeta compartida. Cada documento de Project Layer debe citar expresamente la revisión del Baseline en la que se basa, para que el revisor vea de inmediato qué revisión utiliza un proyecto determinado y pueda juzgar por sí mismo si está vigente.La aprobación nunca es automática
Hacer referencia a un Baseline aprobado previamente acelera el proceso, pero no sustituye la aprobación ni garantiza el resultado. Un nuevo cliente, un nuevo Marine Warranty Surveyor (MWS) o un fletador tienen derecho a exigir una revisión completa, aunque el Baseline ya haya sido aprobado por otra parte: por tener estándares internos distintos, por no estar familiarizados con el formato del documento o por mantener una postura más conservadora ante un tipo concreto de operación.Separar el Baseline y el Project Layer no elimina este riesgo, pero lo reduce: la parte estructurada y ya revisada del documento no se reconstruye desde cero, y una revisión completa del MWS, si se requiere, puede avanzar más rápido que la revisión de un documento elaborado por primera vez. La aprobación del Marine Warranty Surveyor sigue dependiendo del revisor y del proyecto concretos; la separación simplemente reduce el material nuevo que hay que revisar en la documentación del buque.Qué aporta: un ejemplo ilustrativo, no una estadística
Las cifras que siguen ilustran la lógica del ahorro, no son estadísticas de proyectos reales de NautikOne. Los números reales dependen del tipo de buque, del alcance del Baseline y del nivel de exigencia de cada revisor.El primer ciclo (Baseline más el primer Project Layer) supone un esfuerzo comparable a preparar un documento completo desde cero, a veces algo mayor, porque el Baseline se redacta pensando en su reutilización y no como un texto puntual. Los proyectos siguientes (Project Layer más una verificación de aplicabilidad frente a un Baseline existente) requieren notablemente menos: el equipo redacta y revisa solo la parte variable.Un ejemplo ilustrativo: si montar y revisar un documento completo suele llevar en total unas 100 horas, los proyectos posteriores en el mismo buque, una vez establecido el Baseline, podrían rondar las 30–40 horas, siempre que el Baseline supere la verificación de aplicabilidad sin necesidad de actualizaciones significativas. El ahorro de costes se deriva directamente del ahorro de tiempo siempre que el pago esté vinculado al alcance del trabajo y no sea fijo con independencia de este.Cómo se aplica a distintos tipos de operación
Remolque. Baseline: especificaciones del buque, equipos de remolque, tiro a punto fijo (bollard pull), procedimientos de emergencia estándar: el contenido central de referencia de un manual de remolque. Project Layer: configuración del remolque concreto, ruta, criterios meteorológicos. Desencadenante típico de actualización del Baseline: la sustitución de un cable de remolque o de un chigre entre proyectos.Operaciones DP. Baseline: la clase DP del buque, la configuración del sistema DP, la configuración de referencia y una referencia al FMEA vigente, que forman el núcleo del DP Operations Manual. Project Layer: límites operativos específicos del proyecto, requisitos de mantenimiento de posición, interacción con otros buques, incluidos los aspectos del FMEA relativos a interfaces propios de ese proyecto. Desencadenante de actualización del Baseline: una modificación del sistema DP o una revisión del FMEA general tras un incidente o una mejora.Navegación en hielo / polar. Baseline: la clase hielo, las partes del Polar Water Operational Manual (PWOM) que no dependen de la ruta, los procedimientos estándar de gestión del hielo. Project Layer: el sector de hielo concreto, las restricciones estacionales, los requisitos del fletador en cuanto a autonomía o a un práctico de hielo. Desencadenante de actualización: un cambio en las restricciones estacionales o un nuevo sector de hielo no cubierto por el Baseline existente.