EGA Futura » Capacitación y Soporte
Cuando entran más pedidos de los que una persona puede atender, aparece la pregunta de quién se ocupa de cada uno.
La cola es la respuesta menos intuitiva y casi siempre la mejor: no asignar de entrada y dejar el pedido en un espacio compartido.
Ahí queda visible para todo un grupo, hasta que alguien lo toma y se hace cargo.
El modelo tradicional empuja el trabajo: alguien reparte los pedidos y cada uno queda en la bandeja de su destinatario.
Ese reparto tiene un problema estructural, y es que el que reparte no sabe cuán ocupado está cada uno en ese preciso momento.
El modelo de cola invierte la lógica: el trabajo espera y cada persona toma el siguiente cuando termina el anterior.
Con eso el reparto deja de ser una decisión y pasa a ser una consecuencia de la disponibilidad real.
El criterio más sólido es la especialidad: una cola por cada conjunto de casos que requieren el mismo conocimiento.
El segundo criterio habitual es la geografía, cuando hay equipos en husos horarios distintos o cuando alguien tiene que ir hasta el lugar.
El tercero es el producto o el servicio, cuando la empresa atiende líneas muy distintas entre sí.
Lo que casi nunca funciona es armar colas por urgencia, porque la urgencia cambia con el tiempo y un caso tendría que mudarse de cola solo por envejecer.
El primero es el caso huérfano: cuando algo es responsabilidad de todos, en la práctica no es responsabilidad de nadie.
Se combate mirando la antigüedad del caso más viejo de cada cola, que es el indicador que más rápido revela una cola abandonada.
El segundo es el descreme, que ocurre cuando el equipo toma primero los casos fáciles y deja los difíciles para el final.
El resultado es una cola que parece sana en volumen pero acumula los casos más complejos en el fondo, envejeciendo.
El orden puramente cronológico es justo pero ignora que no todos los casos pesan lo mismo.
El orden puramente por prioridad es eficiente pero condena a los casos de baja prioridad a no salir nunca.
La combinación que suele funcionar mezcla las dos cosas: se atiende por prioridad, pero la antigüedad va sumando peso hasta que un caso viejo termina adelante.
El volumen dice poco por sí solo, porque una cola llena que se vacía todos los días está sana.
Los tres números que importan son el tiempo hasta la primera respuesta, el tiempo hasta la resolución y la antigüedad del caso más viejo.
El primero mide si el cliente se siente atendido, el segundo si el problema se resuelve y el tercero si hay algo abandonado.
El pedido de un cliente o de un área interna se registra como Ticket de servicio.
Cada ticket tiene un propietario, y ese campo admite dos cosas distintas: una persona o un grupo.
Cuando el propietario es un grupo, el ticket pertenece a la cola y queda disponible para cualquiera de sus integrantes.
Cuando el propietario es una persona, el ticket ya tiene dueño y salió de la espera compartida.
El estado del ticket arranca en Nuevo, que es el valor por omisión, o sea el momento en que recién entró.
El segundo valor de la lista es Asignado, y es exactamente el punto en que el caso deja la cola y pasa a tener responsable.
Después siguen En proceso, Esperando respuesta y En espera, que distinguen si la demora es del equipo o del cliente.
Y cierran Resuelto y Cerrado, que separan el momento en que se solucionó del momento en que se dio por terminado.
Además del propietario, el ticket tiene un campo Usuario asignado, y ese admite solo personas.
Esa separación es útil: el grupo puede seguir siendo el propietario mientras una persona concreta lleva adelante el trabajo.
Así la cola conserva la visibilidad del caso y a la vez queda claro quién lo está atendiendo.
La Categoría es obligatoria y ofrece ocho valores: Instalaciones, Maquinarias y equipamientos, Recursos Humanos, Administración, Finanzas, Legales, Software y aplicaciones, y Hardware.
Esa lista es el criterio de especialidad más directo para decidir a qué cola va cada caso.
El Área funcional ubica el caso dentro de la organización y la Ubicación indica el lugar físico, que es el criterio geográfico.
La Prioridad es obligatoria y toma cuatro valores, Crítica, Alta, Normal y Baja, con Normal por omisión.
El Incidente y el Problema comparten con el ticket el mismo juego de estados y de prioridades.
Los tres tienen también el propietario que admite grupo, así que los tres se pueden trabajar en cola.
El Incidente suma además un Deadline con fecha y hora, que es el campo con el que se ordena la atención cuando el compromiso tiene reloj.
Una bandeja compartida guarda mensajes, y una cola guarda casos con estado.
La diferencia práctica es que en la cola se sabe quién tomó cada cosa y en qué punto está, mientras que en la bandeja eso se deduce leyendo.
Las suficientes para que cada una agrupe casos que requieren el mismo conocimiento, y ni una más.
Muchas colas pequeñas producen casos que caen en la cola equivocada y rebotan de una a otra sin avanzar.
El caso envejece, y por eso la antigüedad del más viejo es el indicador que conviene mirar todos los días.
Una cola sana se vacía con regularidad, aunque durante el día se llene varias veces.
Sí, y es la salida correcta cuando quien lo tomó descubre que no es su especialidad.
Alcanza con volver a poner al grupo como propietario para que el caso quede otra vez disponible para todos.
El caso se guarda en EGAFutura__Ticket_servicio__c, cuyo campo Name es un Text de 80 etiquetado Ticket de servicio.
La pieza clave para trabajar con colas es OwnerId, cuyo tipo es Lookup(User,Group) y es obligatorio.
Ese tipo compuesto es lo que habilita que el propietario sea una cola, porque las colas se materializan como registros de Group y su relación con cada objeto vive en QueueSobject.
El campo EGAFutura__Usuario_asignado__c es un Lookup(User), o sea que admite personas solamente.
Conviene tenerlo presente al escribir automatizaciones: para dejar un caso en una cola hay que tocar OwnerId, no este campo.
Son EGAFutura__Estado__c, EGAFutura__Prioridad__c y EGAFutura__Categoria__c, las tres con IsNillable en falso.
En las tres la etiqueta coincide exactamente con el valor almacenado, acentos incluidos, así que un filtro puede usar el texto visible.
Los valores de Estado son Nuevo, Asignado, En proceso, Esperando respuesta, En espera, Resuelto y Cerrado, con Nuevo por omisión.
Los de Prioridad son Crítica, Alta, Normal y Baja, con Normal por omisión, y conviene notar que la escala usa Normal y no Media.
Los de Categoría son Instalaciones, Maquinarias y equipamientos, Recursos Humanos, Administración, Finanzas, Legales, Software y aplicaciones, y Hardware, sin valor por omisión.
El incidente es EGAFutura__Incidente__c y el problema es EGAFutura__Problema__c.
Los tres objetos comparten las mismas listas de Estado y Prioridad, con los mismos identificadores internos, así que una automatización escrita para uno se traslada a los otros sin cambiar valores.
La Categoría está en el ticket y en el incidente; el problema en cambio suma EGAFutura__Causa_origen__c, EGAFutura__Sintomas__c y EGAFutura__Workaround__c, este último etiquetado Solución temporal o alternativa.
El incidente es el único de los tres con EGAFutura__Deadline__c, y su tipo es Date/Time, no Date.
Los campos EGAFutura__Productos__c y EGAFutura__Productos_Unidades__c son resúmenes sobre EGAFutura__Ticket_servicio_Product_Line_Item__c.
Al ser calculados son de solo lectura, así que un proceso que intente escribirlos falla.