Un informe de planta puede fallar de varias maneras: no se actualiza, muestra un total inesperado, deja una sección vacía o presenta una cifra distinta a la que el equipo observó antes. La urgencia suele producir dos mensajes poco útiles: “es un problema de IT” o “los datos de OT están mal”. Ambos adelantan una conclusión antes de describir qué salida cambió, en qué momento y con qué evidencia.

Coordinar IT y OT no significa repartir culpas ni pedir acceso a toda la arquitectura. Significa convertir una observación en una ficha que permita a cada función revisar un tramo verificable. El objetivo inicial no es reparar el informe; es impedir que una hipótesis viaje como diagnóstico y que una decisión operativa se apoye en una salida cuya condición no se entiende.

Esta guía organiza esa conversación. No enseña a reiniciar servicios, cambiar interfaces, modificar reglas, restaurar datos ni conceder permisos. Tampoco evalúa controles de ciberseguridad o continuidad. Cuando la incidencia afecte seguridad, producción, calidad, cumplimiento o una obligación contractual, debe seguir el proceso autorizado de la organización.

Describa el síntoma como una salida concreta

Nombre el informe, la sección, el valor o la exportación que se observó. Añada la ventana a la que se refiere, el momento de consulta y la persona o función que detectó el síntoma. “El informe está roto” no ofrece un punto de partida. “El consolidado de turno B del día indicado no muestra registros a partir de una hora determinada” ya permite preguntar qué hecho se espera ver y qué comprobación es posible.

Conserve una captura, referencia interna o ejemplo que no exponga información sensible. La evidencia observada debe separarse de la interpretación. Una celda vacía es un hecho; “la conexión ha fallado” es una hipótesis hasta que alguien pueda demostrarla. Esta separación permite que IT, OT y operaciones hablen del mismo objeto sin obligarse a aceptar una causa prematura.

Registre el impacto de forma proporcional. Puede ser “no apto para la reunión diaria”, “requiere confirmar antes de comparar turnos” o “salida informativa no disponible”. Evite afirmar una parada de proceso, una pérdida de datos o un incumplimiento si la evidencia solo demuestra un fallo de presentación. La precisión protege tanto a la operación como a la investigación.

Recupere la última salida conocida y su contexto

Busque la última vez que el informe se consideró utilizable. No basta con encontrar una fecha; anote la ventana de datos, el corte, la versión visible y el propósito que tenía aquella salida. Una cifra de ayer puede parecer correcta y haber usado otra definición, otra población o un estado provisional. La última salida válida es una referencia, no una prueba de que el presente deba coincidir.

Compare qué cambió entre ambos momentos solo cuando exista evidencia. Puede haber un cambio de definición, una actualización de fuente, una regla de presentación, un cierre de periodo o una modificación de operación. Si no se conoce, escriba “cambio no confirmado”. Esa frase no es una derrota: reduce el riesgo de que un recuerdo informal se convierta en la base de una intervención técnica.

No solicite restaurar el resultado anterior como solución por defecto. Una recuperación puede requerir evaluación de alcance, seguridad, integridad y autorización. La ficha sirve para explicar por qué una salida anterior es relevante y qué limitación tiene; no concede permiso para reproducirla.

Separe los tramos que pueden revisarse

Divida la salida en preguntas sencillas: ¿la fuente contiene el hecho esperado?, ¿la transformación conocida lo incluye?, ¿la salida usa la ventana correcta?, ¿la presentación muestra un filtro distinto?, ¿hay un propietario que pueda explicar la definición? Cada pregunta debe quedar asociada a una evidencia y a una función que pueda revisarla.

No hace falta revelar credenciales, nombres de cuentas, direcciones o configuraciones. Use identificadores internos y remita a los repositorios o procedimientos con acceso controlado. Un documento de coordinación debe ayudar a entender el recorrido sin multiplicar la superficie de exposición.

Una misma persona puede participar en varios tramos, pero el rol debe quedar claro: quien observa, quien puede explicar el proceso, quien administra una fuente, quien confirma una definición y quien decide escalar. Ninguno de esos roles implica automáticamente que esa persona sea responsable de la causa. La ficha recoge responsabilidad de revisión, no atribución de culpa.

Mantenga una lista corta de hipótesis comprobables

Una hipótesis útil describe qué evidencia la confirmaría o descartaría. Por ejemplo: “la salida excluye registros por un cambio de estado”, “la ventana de consulta termina antes del cierre” o “la fuente todavía no ha publicado la actualización esperada”. Evite hipótesis amplias como “la integración está caída” si no hay una observación que las conecte con el síntoma.

Ordénelas por impacto de uso, no por quién las propuso. Si una diferencia de corte puede explicar el resultado, confírmela antes de abrir una investigación sobre cambios complejos. Si una ausencia de registros afecta una decisión sensible, eleve el límite de uso mientras se revisa. La prioridad debe basarse en la pregunta que el informe ya no puede responder de forma prudente.

Marque cada hipótesis como pendiente, descartada por evidencia, confirmada o transferida a un proceso. No convierta el registro en una conversación interminable. La coordinación gana valor cuando otra persona puede ver qué se observó, qué se comprobó y qué sigue sin conocer.

Ponga límites al uso mientras se investiga

Una incidencia no obliga a detener todas las conversaciones. Puede ser posible usar un informe para describir lo que se veía antes de un corte, pero no para comparar rendimiento completo. Puede ser posible consultar una fuente como indicio, pero no usarla para cerrar una orden. Escriba el límite en la salida, no solo en la ficha interna.

El límite no debe convertirse en una conclusión de calidad, seguridad o cumplimiento. Diga “pendiente de confirmar para esta comparación” en lugar de “dato incorrecto” si todavía no se conoce la causa. Si la decisión es sensible, aplique el criterio y las escaladas que corresponden a la organización. La cautela no sustituye los controles formales.

También declare cuándo debe revisarse el límite. Una fecha, una condición de evidencia o una transferencia a un responsable evita que la etiqueta “provisional” se vuelva permanente por inercia. Si no hay una vía de confirmación disponible, indique ese hecho y limite el uso de manera explícita.

Relacione la incidencia con el cambio autorizado

Cuando exista un cambio registrado, anote su referencia, fecha efectiva y alcance descrito. No asuma que es la causa solo porque ocurrió cerca del síntoma. Un cambio puede coincidir con un cierre de periodo, una actualización tardía o una diferencia de definición que ya existía. La relación temporal sirve para organizar preguntas, no para resolverlas por sí sola.

Si la revisión detecta que se necesita un cambio técnico, documente la necesidad y remítala al proceso de cambio. La ficha debe decir qué salida se ve afectada, qué evidencia existe y qué decisión está limitada. No debe incluir una instrucción operativa ni una aprobación implícita. El responsable autorizado necesitará evaluar riesgos, reversibilidad y verificación conforme a sus controles.

NIST SP 800-82r3, publicado por el National Institute of Standards and Technology, trata la seguridad de tecnología operativa. Consulte la publicación primaria de NIST. NIST describe OT como sistemas y dispositivos programables que interactúan con el entorno físico o gestionan dispositivos que lo hacen. La publicación apoya un enfoque prudente ante datos, activos, arquitectura y acceso; no diagnostica esta incidencia ni prescribe cómo reparar una instalación concreta.

Cierre con una salida documentada

La coordinación puede terminar de cuatro formas: se recupera evidencia que explica el resultado; se limita el uso del informe hasta una revisión; se transfiere una necesidad a un proceso técnico autorizado; o se declara que no hay evidencia suficiente para continuar. Las cuatro son salidas válidas si dejan claro quién recibe el siguiente paso y qué condición permitiría reabrir.

Conserve el registro junto con la versión del informe o la referencia de incidencia. Una futura revisión debe poder distinguir una anomalía nueva de una condición ya conocida. Incluya fecha, participantes, evidencia consultada, decisión de uso, dueño del seguimiento y una frase sobre lo que la ficha no demuestra.

La coordinación efectiva no se mide por la rapidez de una etiqueta. Se mide por la capacidad de que operaciones, IT y OT compartan una descripción verificable, no hagan cambios sin autorización y no vuelvan a discutir la misma suposición en cada reunión.

Prepare una secuencia breve de coordinación

La primera conversación puede seguir una secuencia sencilla. Empiece mostrando la salida afectada y el periodo, no una opinión sobre su causa. Después, lea la última referencia conocida y señale qué evidencia la hace comparable o no comparable. A continuación, enumere los tramos: fuente, transformación, publicación y consumo. Por último, acuerde qué revisión puede hacer cada función y qué uso queda limitado mientras tanto.

Esta secuencia reduce el coste de coordinación porque evita que cada participante reconstruya el contexto desde su propia herramienta. Operaciones puede aportar qué hecho esperaba ver; quien conoce el informe puede explicar la definición visible; IT u OT puede orientar sobre el tramo que debe verificarse conforme al procedimiento. Ninguna aportación debe convertirse en un permiso para cambiar algo. La reunión termina con preguntas asignadas, no con instrucciones informales.

La ficha debe conservar el momento de cada actualización. Un mensaje que diga “ya está revisado” no es suficiente si no indica qué dato se consultó, para qué ventana y qué conclusión permite. Al registrar una comprobación, use una frase comprobable: “se confirmó que la salida usa el corte indicado” o “no se ha confirmado la regla de inclusión”. Esta práctica evita que una respuesta parcial se propague como diagnóstico completo.

Mantenga la comunicación proporcional al impacto

No toda anomalía necesita el mismo canal ni el mismo nivel de detalle. Una diferencia visual en una salida exploratoria puede requerir una nota y una revisión en la siguiente reunión. Una salida que afecta una decisión sensible puede exigir escalar de inmediato por el procedimiento interno. La ficha debe declarar el impacto observado, no inventar una criticidad técnica que todavía no ha sido evaluada.

Al comunicar a dirección o a un equipo consumidor, comparta la condición de uso junto con la cifra. “El informe no es apto para comparar el periodo completo hasta confirmar el corte” es más útil que “hay un problema de datos”. La primera frase permite ajustar una decisión; la segunda puede provocar especulación sin mostrar qué se sabe realmente.

Evite listas de distribución amplias por defecto. Una incidencia puede contener referencias operativas que solo deben compartirse con funciones que necesitan intervenir. Aplique las reglas de información y acceso de la organización. La coordinación necesita transparencia de hechos para los responsables adecuados, no exposición indiscriminada de detalles de sistemas o personas.

Conserve las decisiones de no actuar

En una incidencia, también es una decisión decidir no cambiar nada hasta entender el alcance. Registre ese resultado con la misma claridad que una escalada: qué evidencia falta, qué uso se limita, quién debe revisarlo y cuándo volverá a evaluarse. No actuar no significa ignorar; puede ser la opción responsable cuando un cambio apresurado introduciría más riesgo que la salida degradada.

Un ejemplo de decisión limitada es mantener el informe disponible con una etiqueta de corte conocido, pero impedir que se use para calcular una variación. Otro es reemplazar una reunión de seguimiento por una revisión de evidencia sin prometer una cifra. Estas opciones no arreglan la causa, pero evitan que la organización trate una salida dudosa como si fuera suficiente para comprometer una acción.

La condición de reapertura debe ser verificable. Puede ser una referencia de definición encontrada, una comprobación de población completada, una evaluación de cambio autorizada o la publicación de una salida con corte confirmado. Evite “cuando esté solucionado”, porque no dice qué evidencia demuestra la solución ni quién puede confirmarla.

Aprenda de la ficha sin convertirla en un registro de culpabilidad

Tras cerrar una coordinación, revise si la misma pregunta vuelve a aparecer: ¿la salida carece de corte visible?, ¿no existe un dueño de significado?, ¿los cambios se comunican sin explicar el impacto de informe?, ¿un informe mezcla fuentes sin ficha? Estas observaciones pueden orientar mejoras de gobierno, pero no prueban que una persona o equipo haya cometido un error.

Escriba las mejoras como necesidades de información. Por ejemplo, “hacer visible la fecha de actualización”, “conservar una referencia de versión” o “definir un contacto funcional para este informe”. Esa formulación permite que los equipos colaboren sin que la ficha de una incidencia se transforme en una evaluación de desempeño. Las responsabilidades personales requieren hechos, garantías y procesos diferentes.

Si se decide emprender una mejora, mantenga separada la evidencia de incidencia y el trabajo futuro. La primera explica qué se observó en una fecha concreta; el segundo puede requerir diseño, priorización, pruebas y aprobación. Mezclarlos puede hacer creer que una modificación futura ya está autorizada o que la causa ha quedado demostrada cuando todavía se investigaba.

Compruebe que el relevo no pierda el contexto

Una incidencia puede cruzar turnos o equipos. Antes de cerrar una reunión, deje una nota que permita a quien llegue después continuar sin reinterpretar el síntoma. Debe contener la salida afectada, la ventana, el último estado conocido, las evidencias consultadas, las hipótesis que quedan abiertas, los límites de uso y la siguiente persona o función que debe revisar. Un relevo no necesita una crónica de cada conversación; necesita lo suficiente para no repetir una suposición ya descartada.

Evite trasladar la ficha como una orden informal. Si el siguiente paso requiere acceso, cambio, comunicación externa o intervención sobre un proceso, el relevo debe remitir al flujo autorizado. La coordinación puede mantener la continuidad de la evidencia mientras los responsables valoran riesgos y autorizaciones. Esa separación es especialmente útil cuando el informe se usa en un entorno con múltiples sistemas y consecuencias operativas.

Cuando se aporte evidencia nueva, añada fecha, origen y efecto sobre la hipótesis. No borre la observación anterior para que el registro parezca lineal. Una revisión posterior puede necesitar saber por qué una explicación se descartó o por qué se cambió el límite de uso. Mantener ese historial breve protege la trazabilidad sin convertir la ficha en un repositorio técnico exhaustivo.

Verifique el resultado antes de declararlo resuelto

Una salida que vuelve a mostrar cifras no necesariamente ha recuperado el significado esperado. Antes de comunicar que la incidencia ha terminado, compare el periodo, la población, la definición y el corte con la pregunta original. Si solo se ha restaurado la visualización, diga exactamente eso. Si se ha confirmado una condición distinta, actualice el límite de uso y la referencia de versión.

La comprobación debe ser proporcional. Puede consistir en confirmar una muestra, cotejar una salida contra una fuente declarada o pedir al propietario funcional que valide el uso concreto. No presente una comprobación limitada como certificación global. Si la decisión requiere una garantía mayor, transfiera el resultado al proceso que pueda aplicarla con los controles apropiados.

Al cerrar, escriba una frase final que distinga evidencia y alcance: “la salida vuelve a estar disponible para el periodo indicado; esta ficha no valida otros periodos ni cambios futuros”. Esa cautela no resta valor al trabajo de IT u OT. Hace que el resultado sea reutilizable sin prometer más de lo que la revisión demostró.

Límites y siguiente paso

Esta página no resuelve incidencias técnicas, no otorga permisos, no configura sistemas ni determina responsabilidades personales. Tampoco sustituye gestión de cambios, respuesta a incidentes, continuidad, seguridad, calidad o gobierno de datos. Su finalidad es ordenar la evidencia de un informe fallido antes de que la organización decida cómo actuar.

El siguiente paso es crear una ficha para una sola salida afectada: síntoma, ventana, última referencia útil, evidencia, hipótesis, función revisora, límite de uso y condición de cierre. Si el recorrido del dato es desconocido, consulte cómo documentar el linaje entre historian y MES.

Preguntas frecuentes

¿Quién debe decidir si el fallo pertenece a IT o a OT?

La ficha no lo decide de entrada. Describe fuente, transformación, salida y evidencia para que las funciones responsables revisen el tramo que les corresponde.

¿Se debe restaurar un informe antiguo mientras se investiga?

Solo mediante el procedimiento autorizado. La ficha puede registrar la última salida válida y su límite, pero no aprueba restauraciones ni cambios de configuración.

¿Una discrepancia de cifras prueba que hay una incidencia técnica?

No. Puede deberse a corte, definición, cobertura, transformación o presentación. La revisión debe conservar esas alternativas hasta que exista evidencia.

¿Qué información no conviene incluir en la ficha compartida?

No incluya credenciales, configuraciones sensibles, rutas innecesarias ni detalles que amplíen la exposición. Remita a referencias internas con acceso controlado.

¿Cuándo se cierra la coordinación?

Cuando se registra una conclusión respaldada, una limitación de uso o una transferencia al proceso competente con propietario y siguiente revisión.