Procedimiento de inicio de proyecto de reparación naval
Un procedimiento de inicio de proyecto de reparación naval: recepción de especificación, revisión técnica, director de proyecto, paquetes de trabajo, subcontratación, programación y una reunión de inicio de confirmar o revisar.
Cómo funciona
Ajustad los carriles a los nombres de vuestros propios departamentos
Los cinco carriles de rol de aquí, Ventas / cliente, Revisión técnica, Director de Proyecto, Compras y Talleres, reflejan cómo está organizado FAYARD. Si vuestro astillero divide la revisión técnica en carriles separados de mecánica, electricidad e hidráulica en lugar de uno compartido, añadidlos; si compras y el director de proyecto son la misma persona en trabajos menores, fusionad los carriles en lugar de dibujar un traspaso que no ocurre.
Nombrad a las personas, no solo los roles, en cada paso
Poned una persona real en la columna Personas de cada fila, y una estimación realista de carga de trabajo en horas junto a ella, tal como "Revisión técnica del alcance por los responsables de mecánica, electricidad e hidráulica" lleva tres responsables nombrados y una estimación combinada. Eso es lo que permite que el panel de BI de carga de trabajo os muestre a un responsable duplicado entre dos reuniones de inicio activas antes de que aparezca como una fecha de revisión incumplida.
Escribid los criterios de viabilidad detrás de la primera decisión
"¿Alcance completo y técnicamente viable tal como se especifica?" solo es una compuerta útil si los responsables comparten un estándar escrito de lo que cuenta como completo: planos, tolerancias, restricciones de acceso, datos de inspecciones previas. Sin ello, la decisión se convierte en un criterio personal que varía según quién la revise, y el bucle de aclaración se usa de forma incoherente.
Fijad la regla de cuándo un paquete de trabajo va a un subcontratista
"¿La capacidad interna cubre todos los paquetes de trabajo?" debe decidirse según una regla documentada, no una impresión: competencias nombradas que el astillero no tiene, un taller ya reservado por encima de su capacidad para la ventana de dique, o una prueba especializada que el astillero no realiza internamente. Registrad la regla junto a la decisión para que un director de proyecto bajo presión de calendario no pueda saltarse en silencio el paso de subcontratación para mantener una fecha.
Fijad qué significa "confirmado" en la reunión de inicio antes de usar el diagrama
"¿El cliente confirma el alcance, el calendario y el precio en la reunión de inicio?" necesita las mismas tres cosas sobre la mesa cada vez: los paquetes de trabajo, las fechas de dique o atraque y el precio. Si el cliente solo llega a ver una de las tres en la reunión, la rama Confirmado no vale nada como aprobación y las disputas saldrán a la luz más tarde, durante la ejecución, en lugar de aquí.
Mantened el diagrama vivo como sistema de registro del proyecto
Como el diagrama ya lleva responsables y carga de trabajo por paso, mantenedlo actualizado durante la ejecución en lugar de tratarlo como un artefacto de un solo uso para la reunión de inicio: un paquete de trabajo añadido o un responsable reasignado pertenece al mismo diagrama, versionado, de modo que el panel de carga de trabajo y el calendario nunca se desvíen de lo que realmente ocurre en el astillero.
Preguntas frecuentes
¿Por qué la revisión técnica necesita tres disciplinas separadas y una sola decisión?
Porque una especificación de reparación naval rara vez es de una sola disciplina en la práctica, aunque lo parezca sobre el papel: un fallo hidráulico de gobierno suele tener detrás un componente de control eléctrico y un componente mecánico de varillaje. Revisar con los responsables de mecánica, electricidad e hidráulica juntos, y luego pasar por una única decisión de viabilidad compartida, es lo que detecta el hallazgo entre disciplinas antes de que se convierta en una sorpresa a mitad de la reparación. Dividir la revisión en tres firmas separadas sin una decisión compartida es la manera habitual en que un astillero acaba con tres disciplinas, cada una convencida de que el alcance está completo, y nadie que lo haya comprobado como un conjunto.
¿Por qué la decisión de hacer o subcontratar llega después del desglose en paquetes de trabajo y no antes?
Porque "¿la capacidad interna cubre todos los paquetes de trabajo?" solo se puede responder disciplina por disciplina, contra paquetes de trabajo reales con horas reales asociadas, no contra la especificación como un conjunto. Dividir primero el alcance en paquetes de trabajo es lo que convierte "¿podemos hacer esto nosotros mismos?" de una suposición en una lista de comprobación: cada paquete o bien encaja en un taller y un conjunto de competencias disponibles, o no, y solo los paquetes que no encajan necesitan ir a un subcontratista.
¿Qué ocurre si el cliente no confirma en la reunión de inicio?
El diagrama dirige Se solicitan cambios a "Revisar el alcance o el calendario y volver a convocar la reunión de inicio", que vuelve a entrar en la etapa de revisión de riesgo en lugar de en la ejecución. Esto importa porque un alcance o un calendario revisados pueden cambiar el panorama de riesgo, los recursos, o ambos, así que el proceso vuelve a entrar en planificación en lugar de parchear el desacuerdo en silencio y pasar directamente a emitir los paquetes de trabajo.
¿Dónde se reincorpora el trabajo subcontratado al calendario principal?
"Buscar y contratar a un subcontratista para cubrir el hueco" alimenta directamente "Programar los recursos de taller y el turno de dique o atraque", el mismo paso al que llega la vía interna con una respuesta Sí. Eso mantiene la programación como un único paso que tiene en cuenta juntos tanto los paquetes de trabajo internos como los subcontratados, en lugar de dos calendarios separados que hay que conciliar más tarde contra una única ventana de dique seco o atraque.
¿En qué se diferencia esto de un proceso general de solicitud de cambio de proyecto?
Este procedimiento trata de iniciar un proyecto de reparación, desde la especificación de un cliente hasta un trabajo emitido y dotado de recursos; un proceso de solicitud de cambio rige la alteración del alcance, el coste o el calendario después de que un proyecto ya está en marcha y tiene una línea base. La reunión de inicio aquí es el punto donde se acuerdan por primera vez el alcance, el calendario y el precio. Cualquier cambio posterior a ese punto, una vez que los talleres han abierto el trabajo, pertenece a un proceso de control de cambios separado, no a una reunión de inicio revisada.
¿Por qué poner estimaciones de carga de trabajo en filas individuales en lugar de un total único en el proyecto?
Una única estimación de horas a nivel de proyecto oculta exactamente la información que un director de proyecto necesita durante la reunión de inicio: si el cuello de botella es Ventas, un responsable técnico concreto, compras o un taller. La carga de trabajo por fila, totalizada por el panel de BI de carga de trabajo, muestra a un director de proyecto o a un responsable hidráulico con horas repartidas entre varias reuniones de inicio simultáneas antes de que eso se manifieste como una fecha de revisión retrasada, que es el punto más temprano y más barato para detectarlo.