Las condiciones de recepción, los responsables que asumen, la documentación que debe quedar vigente y los pendientes con fecha, tratados como un mismo expediente — desde la decisión de quien recibe, sea aceptar, aceptar con pendientes, devolver para corregir o rechazar, hasta la confirmación del último pendiente cuando la aceptación fue condicionada.
01 · El problema
La ejecución cierra y el equipo de proyecto declara la entrega. Del otro lado, operaciones, soporte y mantenimiento encuentran que el procedimiento entregado no es la versión que quedó vigente, que nadie fue designado para el segundo nivel de atención, que la capacitación se dictó a personas que ya cambiaron de rol, o que las observaciones del arranque siguen sin responsable ni fecha. El proyecto figura terminado en el cronograma y, en la práctica, sigue vivo: las consultas vuelven durante meses al equipo que lo construyó.
El traspaso se coordina con lo que hay a mano: una planilla de Microsoft Excel con la lista de entregables, carpetas de Microsoft SharePoint con manuales de distintas versiones, una cadena de correo donde se acordó de palabra quién asume el soporte, y reporting de Microsoft Power BI sobre el avance del proyecto. Cada pieza cumple bien su función y ninguna deja constancia de qué condición de recepción falta hoy, quién debía resolverla, con qué vencimiento y quién aceptó formalmente el servicio.
La fecha en que el proyecto termina y la fecha en que operación puede hacerse cargo son dos fechas distintas, y rara vez coinciden.
02 · La solución
La entrega se trata como un expediente con recorrido declarado: las condiciones de recepción se acuerdan antes de que la ejecución termine, cada condición se comprueba contra su evidencia, se designan los responsables que asumen la operación, y quien recibe decide entre aceptar, aceptar con pendientes registrados, devolver para corregir o rechazar con fundamento. Si acepta con pendientes, la operación queda asumida desde la fecha registrada y el expediente sigue en seguimiento hasta que cada pendiente tiene su resolución confirmada.
Cada entrega se arma sobre lo que el Operational Graph ya tiene definido y aprobado: el servicio o el activo que se incorpora, los procesos que pasarán a depender de él, la documentación que debe quedar vigente, los responsables de operación, soporte y mantenimiento, y las dependencias que se heredan. BPMflow lo sostiene —casos, condiciones, plazos, autorizaciones y evidencia—, de modo que las condiciones y los plazos permanecen explícitos y trazables, y no dependen de una lista de verificación que vive en una planilla.
La decisión que dio origen a la iniciativa —criterios, priorización y condiciones aprobadas— entra por Demand and Portfolio Governance. Cuando la entrega incluye trabajos de terceros sobre un activo, cada trabajo conserva su propia aceptación en Contractors, Assets and Interventions. Y la responsabilidad de operación que aquí se acuerda es la que después se pone a prueba en Operational Continuity & Resilience.
03 · Capacidades
Las entregas quedan en una bandeja única, con el servicio o activo involucrado, las condiciones cumplidas y faltantes, los responsables designados y los pendientes por vencer a la vista. Max responde sobre el expediente dentro del contexto autorizado: explica qué condición falta, muestra la evidencia registrada y propone el responsable siguiente.
Define, mientras la ejecución sigue en curso, qué condiciones deben cumplirse antes de asumir la operación y cuáles pueden quedar abiertas bajo una aceptación condicionada: documentación, capacitación, accesos, soporte contratado, repuestos o datos de referencia, según el tipo de entrega.
Cada condición se comprueba contra un documento vigente, un resultado de prueba registrado o la confirmación de un responsable. Una condición sin evidencia queda visible como pendiente y no como cumplida por omisión.
Registra quién asume la operación diaria, quién atiende cada nivel de soporte y quién mantiene el activo o el sistema, con la fecha desde la cual rige esa responsabilidad y el alcance que cubre.
Vincula procedimientos, manuales, planos, configuraciones y contratos de soporte al servicio o al activo que se entrega, con su versión identificada, en lugar de dejarlos como archivos sueltos en una carpeta compartida.
Lo que se acepta sin resolver queda declarado como pendiente, con responsable, fecha comprometida y criterio de resolución. Si llega a esa fecha sin resolverse, escala al responsable acordado y el plazo se renegocia con su motivo registrado, en lugar de diluirse cuando el equipo de proyecto se disuelve.
Registra la decisión de quien recibe —aceptar, aceptar con pendientes, devolver para corregir o rechazar—, y los pendientes que quedan abiertos. La aceptación sin pendientes cierra al quedar registrada; la aceptación condicionada cierra cuando el último pendiente queda resuelto y su resolución la confirma el responsable autorizado o el sistema designado; el rechazo fundado cierra con su motivo y sin transferencia; la devolución para corregir mantiene la entrega abierta. El expediente queda disponible para la operación y para la próxima entrega.
04 · Roles
Recibe el servicio y decide la aceptación.
Qué ve
Las entregas próximas a recepción, con sus condiciones cumplidas y pendientes, la documentación vigente y los responsables propuestos para su área.
Qué hace
Acepta, acepta con pendientes registrados —asume la operación y el seguimiento sigue abierto—, devuelve para corregir o rechaza con fundamento, y confirma desde cuándo asume la operación.
Asume la atención posterior y su carga real.
Qué ve
Qué servicio o activo va a atender, con qué procedimientos, accesos y herramientas, y qué pendientes hereda con sus fechas.
Qué hace
Revisa que lo entregado sea atendible, observa lo que falta e incorpora el servicio a su alcance cuando se cumplen las condiciones bloqueantes, con los pendientes aceptados a la vista.
Prepara la entrega y responde por sus condiciones.
Qué ve
El estado de cada condición de recepción, la evidencia reunida, las observaciones abiertas y el plazo comprometido para resolverlas.
Qué hace
Reúne la evidencia, resuelve o negocia los pendientes, solicita la recepción y responde las devoluciones de quien recibe.
Aporta evidencia y resuelve lo observado a su cargo.
Qué ve
Sus entregables, las observaciones que debe resolver y los pendientes a su nombre, en su propio expediente con acceso acotado.
Qué hace
Entrega documentación y resultados de prueba, responde observaciones y registra la resolución de los pendientes asignados.
05 · Implementación
La implementación parte de una entrega concreta y próxima: alcanza con el contexto mínimo de ese servicio y su equipo receptor, sin un proyecto de arquitectura previo.
1 · Acordar el resultado
Qué entregas entran —un sistema, una instalación, una línea, un servicio—, qué condiciones exige cada tipo, qué pendientes pueden aceptarse sin bloquear la recepción y quién firma por operación, soporte y mantenimiento.
2 · Recuperar contexto y conectar fuentes
Toma el servicio o el activo y sus dependencias desde el inventario operativo, el estado de la ejecución desde la herramienta de gestión de proyectos, y se integra con el repositorio documental autorizado de la organización cuando esa es la fuente de manuales y procedimientos.
3 · Probar el recorrido e incorporarlo
Se prueba con una entrega del período en curso, se ajustan condiciones, plazos y criterios de aceptación, y la operación diaria del recorrido queda bajo control del equipo del cliente.
06 · Escenarios típicos
Varias sedes, proveedores que entregan por partes, equipos receptores que no participaron del diseño y proyectos que terminan sobre el cierre del período: situaciones frecuentes en un portafolio de iniciativas. Los escenarios siguientes son ilustrativos.
Una entrega queda cerrada cuando quien recibe se pronunció con la evidencia a la vista: la aceptación sin pendientes cierra al quedar registrada; la aceptación condicionada cierra cuando el último pendiente queda resuelto contra el criterio acordado y su resolución la confirma el responsable autorizado o el sistema designado; el rechazo fundado cierra con su motivo registrado y sin transferencia. La devolución para corregir no cierra: mantiene el expediente abierto. Conviene empezar por un tipo de entrega concreto y un único equipo receptor.
Project Handover to Operations es una solución transversal de EAFlow sobre el Operational Graph, sostenida por las capacidades de automatización de BPMflow. La herramienta de gestión de proyectos conserva el plan y su avance, la mesa de servicio conserva la atención posterior y el EAM/CMMS conserva el activo: este recorrido reúne las condiciones de recepción, la evidencia y la decisión de quien recibe. La aceptación de un trabajo de contratista sobre un activo y la prueba de los planes de continuidad son recorridos propios, sobre la misma base.
