Cómo verificar desde tu oficina que la mano remota hizo bien el trabajo: fotos antes/después, bitácora y los 4 reportes que debes exigir

Tu proveedor de manos remotas ejecutó un ticket a 500 km de distancia. ¿Cómo verificas, sin estar físicamente ahí, que el trabajo se hizo correctamente? La respuesta no es ‘confiar en su palabra’. Es tener un workflow de verificación remota que cierre la distancia operacional entre tu oficina y el sitio. Este artículo cubre los 4 reportes que tu proveedor debe entregar sin que se los pidas, el formato de las fotos y bitácoras, y los criterios objetivos para aceptar o rechazar el trabajo sin desplazarte.

Lo que sigue aplica a data centers con proveedores de manos remotas contratados. El workflow es el mismo si tu proveedor está a 50 km o a 5,000 km. Lo que cambia es la rigurosidad con que exiges el reporte — a mayor distancia, mayor detalle.

Reporte #1: Fotos georeferenciadas antes y después

El reporte base. Sin fotos antes/después, no tienes forma de saber qué hizo la mano remota. Requisitos:

1. Foto ANTES: estado del equipo/rack antes de la intervención. Debe mostrar el slot específico, el número de serie del componente a intervenir, y el contexto (rack adyacente, etiquetado). La mano remota toma la foto con la cámara del ticket abierta en smartphone con timestamp y geolocalización (si el smartphone corporativo lo permite).
2. Foto DURANTE: si la intervención toma más de 5 minutos, una foto del trabajo en progreso. Útil para detectar si el técnico está trabajando en el equipo correcto.
3. Foto DESPUÉS: estado del equipo/rack después de la intervención. Debe mostrar claramente que el trabajo se completó: componente nuevo instalado, cable etiquetado, slot ocupado correctamente.
4. Mínimo 3 fotos por intervención simple. Para intervenciones complejas (rack & stack completo, retiro de equipo viejo), mínimo 6-8 fotos documentando cada paso.

Si tu proveedor solo entrega 1 foto “después”, desconfía. Significa que no documentó el estado previo y no puedes verificar que el cambio fue el solicitado. Exige mínimo 3 fotos como estándar.

Reporte #2: Bitácora de operación con timestamps

La bitácora es el documento que narra cronológicamente qué pasó durante la intervención. Formato sugerido:

1. Hora de llegada al sitio (timestamp con HH:MM).
2. Hora de inicio de trabajo.
3. Identificación del equipo a intervenir (marca, modelo, número de serie).
4. Acción específica ejecutada (no ‘se revisó el servidor’, sino ‘se reemplazó disco SSD en slot 3 del servidor HPE ProLiant DL360 serial ABC123’).
5. Número de ticket asociado.
6. Hora de fin de trabajo.
7. Resultado (completado, parcialmente completado, no completado por X razón).
8. Observaciones o hallazgos no esperados (cables sueltos, polvo excesivo, dispositivo etiquetado incorrectamente).

Esta bitácora se entrega en formato electrónico (PDF, email, sistema de tickets) máximo 4 horas hábiles después de completada la intervención. Si tu proveedor no la entrega dentro de 24 horas, hay problema operativo.

Reporte #3: Diff de configuración (cuando aplique)

Para intervenciones que afectan configuración lógica (cambio de IP, VLAN, ACL), el reporte debe incluir diff antes/después. Para intervenciones físicas (cambio de disco, rack & stack), el equivalente es el etiquetado antes/después:

1. Si el ticket decía “cambiar IP del servidor X de 10.0.0.5 a 10.0.0.10”, el reporte debe incluir pantalla del nuevo ifconfig / ipconfig, con timestamp.
2. Si el ticket decía “etiquetar puertos 1-24 del patch panel con código ABC-001 a ABC-024”, el reporte debe incluir foto del patch panel completo con las etiquetas aplicadas y legibles.
3. Si el ticket decía “reubicar servidor del rack A12 al rack B07”, el reporte debe incluir foto de la nueva ubicación con etiquetado del slot U exacto.

Sin el diff, no tienes forma de saber si el cambio se ejecutó como pediste o como el técnico interpretó. La mano remota eficiente te entrega el diff sin que lo pidas — el diff es parte de la entrega estándar.

Reporte #4: Métricas de salud post-intervención

El reporte que confirma que el equipo sigue funcionando bien después del cambio. Datos que debe incluir:

1. Lectura del display del equipo intervenido (temperatura, humedad, presión, estado de componentes) al momento de cerrar el ticket.
2. Resultado del comando de verificación que aplique (ping al servidor, status de LED del switch, estado de RAID array, etc.).
3. Tiempo de actividad del equipo en las 24 horas posteriores al cambio. Esto lo puedes validar tú desde tu lado consultando tu sistema de monitoreo (DCIM, NMS, BMS).

Si la métrica de salud falla en las 24 horas post-intervención y el problema está relacionado con el cambio, la mano remota es responsable de la corrección sin costo adicional (cláusula de retry del SLA). Tu métrica de salud es la que decide si el trabajo fue exitoso.

El formato del reporte consolidado

Un buen reporte consolidado (los 4 en un solo documento) tiene esta estructura:

1. Header con: número de ticket, fecha, hora de inicio/fin, nombre del técnico, nombre del proveedor, datos de contacto.
2. Resumen ejecutivo (3-5 líneas): qué se hizo, resultado, observaciones críticas.
3. Sección de bitácora (tabla con timestamps y acciones).
4. Galería de fotos (mínimo 3, antes/durante/después) con caption descriptivo.
5. Sección de diff de configuración (cuando aplique, con screenshot).
6. Sección de métricas de salud post-intervención.
7. Firma del técnico (digital o en el documento) confirmando que el trabajo se completó según lo solicitado.

Si tu proveedor entrega reportes así sin que se lo pidas, es proveedor maduro. Si tienes que pedirlo cada vez, capacítalo con un ejemplo de lo que quieres. Si después de capacitar sigue entregando reportes deficientes, hay problema operativo que no se resuelve con contrato.

Cómo aceptar o rechazar el trabajo desde tu oficina

Criterios objetivos para decisión:

1. ACEPTAR si: fotos antes/después son claras, bitácora tiene timestamps coherentes con la ventana de trabajo, métricas de salud están en rango, diff de configuración coincide con lo solicitado.
2. PEDIR ACLARACIÓN si: una foto está borrosa o falta contexto, falta un timestamp, una métrica está fuera de rango sin explicación.
3. RECHAZAR si: fotos no coinciden con el ticket solicitado, bitácora con huecos inexplicables, métricas de salud fuera de rango y relacionadas con el cambio, diff no muestra lo que pediste.

El rechazo debe hacerse dentro de las 24 horas posteriores al reporte. Después de eso, la mano remota da por aceptado el trabajo y reclamar es más difícil. Si rechazas, documenta el motivo con cita específica del reporte que falla.

El caso real: cuando la verificación remota evitó un desastre

Operación real en 2024: ticket “cambiar disco duro en slot 5 del servidor ABC12”. La mano remota envió fotos antes/después con disco nuevo instalado y etiquetado correcto. La métrica de salud mostraba el RAID array en estado “optimal”. Pero al día siguiente, nuestro sistema de monitoreo reportó que el servidor tuvo 3 alertas de “predictive failure” en el disco nuevo durante la noche.

Acción: contactamos al proveedor con la evidencia del log de monitoreo. La mano remota volvió al sitio, confirmó que el disco nuevo era refurbished (no nuevo como esperábamos) y procedió al cambio por uno nuevo genuino. Sin la verificación remota con métrica de salud en 24 horas, el disco refurbished hubiera quedado operativo hasta la siguiente falla, 2-3 meses después, con downtime no programado y posible pérdida de datos.

Lecciones operativas:

(1) el reporte de bitácora inmediato no es suficiente — la métrica de salud en 24 horas siguientes es lo que valida el trabajo.

(2) sin foto del disco nuevo con etiqueta de “nuevo” visible, no tienes cómo distinguir nuevo vs refurbished.

(3) tu sistema de monitoreo es la mejor auditoría de la mano remota.

Qué exigirle al proveedor en el contrato

Si estás formalizando la relación con tu proveedor, incluye:

1. Formato estándar de reporte consolidado. Anexo técnico con plantilla que el proveedor debe usar.
2. Entrega del reporte dentro de 4 horas hábiles post-intervención. Penalización si no se entrega.
3. Métricas de salud reportadas en formato estandarizado (CSV o JSON) para integración con tu sistema de monitoreo.
4. Acceso al sistema de tickets del proveedor para ver historial completo. Si tu sistema y el del proveedor son diferentes, integración vía webhooks.
5. Tiempo de respuesta a aclaraciones: máximo 2 horas hábiles para responder a preguntas del cliente sobre el reporte.

El proveedor serio acepta estos términos sin problema. El que se resiste es porque no tiene la operación interna para sostenerlo. Esa es información valiosa para tu decisión de mantener o cambiar de proveedor.

Fuentes

1. Uptime Institute — Operational Sustainability: Management and Reporting of Field Services — https://datacenter.uptimeinstitute.com/
2. ISO/IEC 20000-1:2018 — Service Management: Reporting and Documentation Requirements — https://www.iso.org/standard/70636.html
3. ITIL 4 Foundation — Incident Management and Service Request Fulfillment — https://www.axelos.com/certifications/itil-service-management/itil-4-foundation
4. BICSI 002-2024 — Data Center Operations: Smart Hands Service Delivery — https://www.bicsi.org/standards/data-center
5. TIA-942-B-2023 — Telecommunications Infrastructure Standard for Data Centers — https://www.tia.org/standards/tia-942