Tickets

Los tickets son la capa de gestión del trabajo humano sobre tus plantas — el lugar donde realmente ocurren la investigación, la asignación, la discusión y la resolución. Mientras que un evento es una señal detectada por la máquina, un ticket es el espacio de trabajo que tu equipo posee: quién está trabajando en él, qué se ha intentado y cómo termina.

Concepto de tickets

Tus plantas generan eventos automáticamente — una parada de red, un límite por sobreproducción, un logger que pierde su fuente. Esos eventos son deliberadamente ligeros: registran qué se detectó, dónde, cuándo y con qué gravedad. No son el lugar adecuado para hacer un seguimiento del trabajo que viene después.

Un ticket es ese seguimiento. Abres un ticket para investigar un problema, se lo asignas a un compañero, reúnes notas y hallazgos en un único hilo, vinculas los componentes y eventos que le conciernen y lo cierras una vez resuelta la situación. Cada cambio queda registrado, de modo que meses después puedes reconstruir exactamente qué pasó y quién hizo qué.

Eventos vs. tickets

Un evento es una señal detectada, normalmente automática y de solo lectura como registro. Un ticket es la historia humana que lo rodea: priorización, asignación, comentarios y resolución. Ambos están vinculados para que la señal y el trabajo para resolverla permanezcan conectados. El título y la descripción de texto libre que llevaban los eventos antiguos se están retirando en favor de los tickets — trata el evento como el disparador y el ticket como el espacio de trabajo.

Los tickets son un subrecurso de la planta: cada ticket pertenece a una planta, y tu acceso a él sigue tu rol en esa planta en lugar de una configuración aparte.

Qué contiene un ticket

Un ticket reúne todo lo relativo a una pieza de trabajo en una única vista:

Título y descripción — un titular breve más la narrativa completa de lo que se está abordando.
Categoría — qué tipo de trabajo es (ver más abajo), para poder filtrar y priorizar los tickets por tipo.
Estado — en qué punto de su ciclo de vida se encuentra el trabajo.
Responsable — la única persona responsable del ticket. Las reasignaciones quedan registradas.
Cronología — una hora de inicio y de fin opcionales para el trabajo, junto a las marcas de tiempo automáticas de creación, actualización y cierre.
Comentarios — una discusión en hilo donde el equipo resuelve el problema.
Menciones — incorpora a un compañero a un ticket con una @mención; recibe una notificación y queda registrado.
Enlaces — conexiones con los eventos, otros tickets y componentes que toca este trabajo.
Registro de actividad — un historial completo y automático de cada cambio realizado en el ticket.

Tickets del sistema

Algunos tickets los abre automáticamente la plataforma en lugar de una persona. Se comportan como cualquier otro ticket — puedes comentar en ellos, asignarlos y cerrarlos — pero están marcados como generados por el sistema para que sepas de un vistazo qué trabajo te ha encolado la plataforma.

Categorías de tickets

Cada ticket lleva una categoría para que tu equipo pueda ordenar y priorizar el trabajo según el tipo de problema que representa:

Categoría	Úsala para
Mantenimiento	Servicio y conservación planificados o rutinarios
Defecto	Un componente defectuoso o un fallo de equipo
Comunicación	Problemas de conectividad o de adquisición de datos con una fuente
Parada	Trabajo ligado a una parada de producción de red o externa
Ambiental	Condiciones provocadas por el clima, la suciedad, las sombras o el entorno
Informativo	Un registro que se conserva para conocimiento, sin acción requerida
General	Cualquier cosa que no encaje en las categorías anteriores

Ciclo de vida del ticket

Un ticket avanza por una secuencia de estados clara para que todos puedan ver en qué punto está el trabajo:

Abierto — creado y a la espera de la priorización inicial.
Detectado — el problema subyacente se ha identificado y confirmado.
En curso — alguien está trabajando activamente en él.
Cerrado — el trabajo ha terminado y la situación está resuelta.

Un ticket cerrado puede reabrirse si el problema vuelve, de modo que una incidencia recurrente mantiene todo su historial junto en lugar de generar cada vez un ticket nuevo y desconectado. Tanto el cierre como la reapertura quedan registrados en el registro de actividad, junto con quién lo hizo y cuándo.

Comentarios y menciones

El hilo de discusión es donde ocurre la resolución real del problema. Cualquiera que trabaje en un ticket puede:

Comentar para registrar hallazgos, decisiones y siguientes pasos.
Editar o eliminar sus propios comentarios — los comentarios editados y eliminados se marcan en lugar de cambiarse silenciosamente, para que el rastro siga siendo honesto.
Mencionar a un compañero con @ para incorporarlo al ticket. La plataforma registra a quién se mencionó, quién lo mencionó y cuándo, y notifica al usuario mencionado.

El ticket también registra qué usuarios fueron notificados sobre él y cuáles lo han visto, para que sepas si las personas adecuadas están al tanto de una incidencia abierta.

Vinculando el panorama general

Un ticket rara vez está aislado. Puedes conectarlo con el resto de la plataforma para que el contexto acompañe al trabajo:

Enlaces a eventos — referencia los eventos que desencadenaron el trabajo o que se relacionan con él. Un evento de parada de red y el ticket de mantenimiento para corregirlo permanecen ligados.
Enlaces a tickets — referencia otros tickets, para que el trabajo relacionado o dependiente sea fácil de navegar.
Enlaces a componentes — adjunta las partes concretas de la planta que conciernen al ticket (un logger, inversor, GAK, string, contador de inyección o sensor de irradiación), y busca entre los componentes de la planta para encontrar el adecuado. Este es el mismo modelo de vinculación que usan los eventos, por lo que la vista de evaluación de componentes y el ticket se mantienen coherentes.

Empieza desde un evento

Cuando un evento necesita investigación o una corrección, abre un ticket y vincula el evento a él. El evento sigue siendo el registro objetivo de lo que detectó la plataforma; el ticket lleva el responsable, la discusión, las menciones, los enlaces a componentes y el historial completo del trabajo.

Historial de actividad

Cada ticket mantiene un registro de actividad automático — una auditoría cronológica de todo lo que le ha sucedido. Nunca tienes que mantenerlo a mano; la plataforma registra cada acción a medida que ocurre:

Creación, cierre, reapertura y eliminación.
Cambios de título, descripción, categoría y estado — capturados con el valor anterior y el nuevo.
Asignación, reasignación y desasignación.
Comentarios añadidos, editados o eliminados, y usuarios mencionados.
Componentes vinculados o desvinculados, y eventos u otros tickets referenciados o sin referenciar.

Este registro es la fuente de verdad del ticket para la rendición de cuentas: las disputas de garantía, las auditorías y las revisiones posteriores a incidentes se apoyan en él, y no puede reescribirse discretamente a posteriori.

Encontrar y revisar tickets

Los tickets se conservan como registro a largo plazo para que puedas gestionar el trabajo diario y revisar el historial más adelante:

Listar y filtrar — navega por los tickets de las plantas a las que tienes acceso, filtrados por planta, categoría, estado o responsable, y ordenados para mostrar primero los más nuevos o más urgentes.
Vista de detalle — abre cualquier ticket para ver su descripción, comentarios, eventos y componentes vinculados, el seguimiento de notificaciones y vistos, y el registro de actividad completo.
Registro histórico — los tickets cerrados permanecen disponibles, manteniendo intacta la historia completa del trabajo pasado y de los problemas recurrentes.

Acceso y permisos

Los tickets son un subrecurso de la planta, por lo que el acceso sigue tu rol de trabajo en la planta principal — no una configuración aparte por ticket. Cualquiera que pueda ver una planta puede leer sus tickets. Más allá de eso, la plataforma distingue la responsabilidad técnica de la comercial:

Roles técnicos — los Operadores y los Technical Managers (y los roles de organización equivalentes) obtienen la administración completa de tickets: crear, editar, asignar, comentar, cerrar, reabrir y eliminar.
Asset Manager (Commercial) puede leer y crear tickets, pero no puede cerrarlos, reabrirlos ni eliminarlos — supervisión comercial sin cambiar el estado técnico de resolución.
Visualizadores pueden leer los tickets pero no modificarlos.

Los cooperadores que tienen el rol de trabajo requerido en una planta compartida se incluyen en los mismos términos. Consulta el Sistema de permisos para conocer el modelo de roles completo.

Funciones relacionadas

Eventos — las señales detectadas por la máquina que motivan la apertura de tickets para investigar y resolver
Evaluación de componentes — la vista de salud por componente a la que los tickets remiten
Sistema de permisos — los roles de trabajo que rigen quién puede leer, crear y administrar tickets
Informes — documentación periódica que se apoya en las incidencias resueltas y las pérdidas de producción