Búsquedas frecuentes
Tutoriales actualizados
Un Problema es la causa, real o potencial, de uno o varios Incidentes. Se registra para atacar el origen de una falla en lugar de apagar sus consecuencias una por una, porque mientras el Problema siga abierto los Incidentes se van a seguir repitiendo. No hace falta que ya existan Incidentes para darlo de alta: una inspección puede detectar la falla antes de que llegue el primer reclamo. Cada Problema guarda por separado los síntomas observados, la causa de origen y la solución temporal que permite seguir trabajando mientras se busca la definitiva.
Un Problema es la razón de fondo por la que algo falla, y por eso se registra aparte de las fallas concretas que provoca.
La definición incluye la palabra potencial a propósito.
Un Problema existe desde antes de generar un daño visible, y ese matiz es el que permite anticiparse.
La comparación más clara viene del mundo de la salud: el Incidente es el síntoma y el Problema es el diagnóstico.
Una línea de producción mal calibrada es un Problema, y cada producto defectuoso que sale de ella es un Incidente.
Un contenedor retenido en la aduana es un Problema, y cada cliente que reclama su pedido demorado es un Incidente.
La proporción habitual es esa: un Problema del lado de la causa y muchos Incidentes del lado de la consecuencia.
De ahí se desprende la regla de trabajo. Resolver Incidentes alivia el síntoma, pero solo cerrar el Problema detiene la fuente.
Para guardar un Problema alcanza con Estado y Prioridad, además del nombre del registro.
Estado ofrece siete valores: Nuevo, Asignado, En proceso, Esperando respuesta, En espera, Resuelto y Cerrado.
Prioridad ofrece cuatro: Crítica, Alta, Normal y Baja.
Los dos vienen con un valor puesto de fábrica, Nuevo y Normal, así que un Problema se puede abrir en segundos y completarse después.
Acá está la diferencia estructural con el Incidente, que tiene un solo campo de descripción.
El Problema tiene cuatro campos de texto largo, y cada uno responde una pregunta distinta del análisis.
Descripción del Problema cuenta de qué se trata en general.
Síntomas anota lo que se observa desde afuera, que es la evidencia con la que se detectó la falla.
Causa de origen guarda la conclusión del análisis, o sea por qué pasa lo que pasa.
Y Solución temporal o alternativa describe el rodeo que permite seguir operando mientras la solución definitiva se prepara.
Separar síntoma de causa en dos campos distintos no es una formalidad: obliga a distinguir lo que se vio de lo que se dedujo.
Durante una inspección de rutina se detecta que una máquina envasadora pierde presión al final del turno.
El registro se abre con Prioridad Alta antes del primer reclamo.
En Síntomas se anota la pérdida de presión medida, y en Causa de origen, tras el análisis, una válvula gastada.
Como el repuesto tarda dos semanas, en Solución temporal o alternativa se documenta bajar el ritmo de la línea en el último turno.
Ese registro evitó los Incidentes en lugar de administrarlos, que es exactamente para lo que sirve el objeto.
El hub de Atención y servicio al cliente ubica este concepto dentro de un proceso empresarial.
En Servicios en Campo: cómo coordinar Técnicos sin volverte loco vemos cómo se aplica a decisiones y tareas concretas.
EGA Futura Service muestra cómo se refleja dentro de la Plataforma.
Y EGA Futura Activos lo muestra desde otra parte del sistema.
El objeto Problema vive en la aplicación de servicio, junto con los Incidentes y los tickets de atención.
Es el más analítico de los tres y, por eso mismo, el que menos registros acumula.
Problema e Incidente comparten exactamente las mismas listas de Estado y de Prioridad.
Esa simetría permite medir los dos con la misma vara y comparar cuánto tarda la empresa en cerrar una causa contra cuánto tarda en cerrar sus consecuencias.
Pero los campos de contenido son distintos, y esa asimetría también es deliberada.
El Incidente tiene Categoría y Deadline porque se gestiona contra reloj, mientras que el Problema tiene Síntomas, Causa de origen y Solución temporal porque se investiga.
Los campos Area funcional y Ubicación apuntan a los mismos registros que usa el resto del ERP.
Gracias a eso un Problema se puede cruzar con activos, órdenes de mantenimiento e inspecciones del mismo sector, sin duplicar tablas de referencia.
Sobre el objeto se arman Informes que ordenan el trabajo de fondo.
Cuántos Problemas críticos siguen abiertos, cuál es el más viejo sin resolver y qué sector los concentra.
Un Panel de información armado con esos Informes muestra de un vistazo si la empresa está apagando incendios o resolviendo causas.
Estas preguntas ubican al Problema frente al Incidente, aclaran qué datos exige su carga y explican para qué sirve dejar escrita una solución temporal.
El Problema es la causa y el Incidente es la consecuencia visible de esa causa.
Resolver Incidentes atiende los síntomas, mientras que cerrar el Problema corta la fuente que los genera.
Sí, y es una de las formas más útiles de usar el objeto.
Una inspección o una auditoría pueden detectar una falla antes de que llegue el primer reclamo, y anticiparse cuesta mucho menos que reparar.
Además del nombre del registro, solo dos: Estado y Prioridad.
Los dos vienen con un valor por defecto, Nuevo y Normal, así que el registro se puede abrir de inmediato y completarse a medida que avanza el análisis.
Para dejar por escrito cómo se sigue trabajando mientras la solución definitiva no está lista.
Es información operativa que suele viajar de boca en boca, y escribirla en el registro evita que dependa de quién esté de turno.
El nombre de API del objeto es EGAFutura__Problema__c.
Las dos listas de selección exponen los mismos valores para todos los perfiles.
Estado y Prioridad son obligatorios, con los mismos valores por defecto que el Incidente.
| Campo | Tipo | Nota |
|---|---|---|
| EGAFutura__Estado__c | Lista de selección | Obligatorio. Nuevo por defecto |
| EGAFutura__Prioridad__c | Lista de selección | Obligatorio. Normal por defecto |
| EGAFutura__Descripcion_Problema__c | Área de texto larga(32768) | |
| EGAFutura__Sintomas__c | Área de texto larga(32768) | |
| EGAFutura__Causa_origen__c | Área de texto larga(32768) | |
| EGAFutura__Workaround__c | Área de texto larga(32768) | La solución provisoria |
| EGAFutura__Area_funcional__c | Lookup a Area funcional | |
| EGAFutura__Ubicacion__c | Lookup a Ubicación | |
| EGAFutura__Usuario_asignado__c | Lookup a User | |
| EGAFutura__EGA_Futura_ID__c | Numeración automática | Lo genera EGA Futura |
En las dos el valor almacenado coincide con la etiqueta.
| Campo | Valores |
|---|---|
| EGAFutura__Estado__c | Nuevo, Asignado, En proceso, Esperando respuesta, En espera, Resuelto, Cerrado |
| EGAFutura__Prioridad__c | Crítica, Alta, Normal, Baja |
Los cuatro campos de texto largo guardan el análisis en prosa; para agrupar y filtrar en un Informe se usan Estado y Prioridad.
[00:00:00.000]
Vamos a aprender de manera rápida qué es un problema dentro de EGA Futura Service.
[00:00:07.800]
EGA Futura Service es la aplicación de la Plataforma EGA Futura que nos permite administrar servicios, problemas e incidentes que se vincula también con otras aplicaciones de la plataforma como EGA Futura Activos, EGA Futura Clarity, EGA Futura Habitat o EGA Futura Project.
[00:00:34.100]
¿Qué es un problema? Un problema es la causa o potencial causa de uno o más incidentes. Los problemas se pueden ingresar al sistema como respuesta a un gran incidente o un conjunto de incidentes (ahora vamos a ver ejemplos).
[00:00:51.100]
Los problemas también se pueden registrar en la plataforma en presencia o no de incidentes. Porque, por ejemplo, en una inspección podemos detectar un problema que no generó incidentes y ya lo damos de alta, ya lo cargamos, ya lo ingresamos para poder trabajarlo, gestionarlo, resolverlo, administrarlo.
[00:01:10.200]
Vamos a pensar en problemas e incidentes, por ejemplo, supongamos que nuestra empresa importa productos desde Medio Oriente a través de containers que viajan en un barco. Si ese container es retenido en la aduana de nuestro país y contiene un montón de productos que nosotros ya vendimos y tenemos un montón de clientes esperando por esos productos (que no los tenemos porque están retenidos en la aduana y qué tal vez puedan pasar meses hasta que los recibamos en nuestro almacén, en nuestro depósito o en el lugar en donde almacenamos los productos de nuestro inventario, nuestro stock) vamos a tener un montón de incidentes y los incidentes van a ser todas las quejas y los reclamos de nuestros clientes, que los vamos a administrar desde Incidentes.
[00:02:05.100]
Entonces, desde incidentes administramos los incidentes puntuales que este problema genera, entendiendo que mientras no esté resuelto ese problema probablemente se siguen generando más incidentes.
[00:02:19.400]
Otro ejemplo muy particular de un problema es: Supongamos que nuestra empresa fabrica productos y en nuestra línea de producción, en nuestra línea de fabricación hay una falla que provoca fabricar productos defectuosos.
[00:02:33.900]
Esa falla es un problema y mientras ese problema no se resuelva se van a generar un montón de incidentes por parte de nuestros clientes reclamando por esos productos defectuosos.
[00:02:46.200]
Recomiendo mucho ver todos los vídeos de EGA Futura Service para entender bien las diferencias entre problemas, incidentes y tickets de servicio y comprender qué cosa va en cada lugar.
[00:03:01.400]
Para ver todos esos vídeos te recomiendo visitar EGAFutura.com/tutoriales
[00:03:08.000]
Recapitulando: Un problema es la causa o potencial causa de uno o varios incidentes y mientras ese problema no esté resuelto, se pueden generar o no más incidentes en relación a todos los clientes afectados.
Los términos del glosario que empiezan igual que este. Las demás letras se abren acá mismo, sin salir de la página.
Ventas, compras, inventario, finanzas y equipo, con la información al día y disponible desde cualquier dispositivo. Funciona en la nube, así que no hay servidores que mantener.
