Formas alternativas de encontrar trabajo
La función Get Next Work (Obtener el trabajo siguiente) de Pega es la forma más utilizada para recuperar una asignación que requiere atención. La función Get Next Work (Obtener el trabajo siguiente) está dirigida a las interacciones de plazos cortos con un cliente donde puede que el trabajo requiera una coincidencia de habilidades del operador. La función Get Next Work (Obtener el trabajo siguiente) ahorra tiempo valioso, ya que no devuelve asignaciones que contienen un error o están asociadas con un caso bloqueado.
Esta función está estrechamente vinculada a la configuración de la regla del acuerdo a nivel de servicio (SLA). Las reglas a nivel de servicio proporcionan metas, fechas límite e hitos de fecha límite excedida en los cuales se puede aumentar la urgencia.
Las configuraciones pxGoalTime y pxDeadlineTime de una asignación pueden ajustarse desde su valor inicial. Se utiliza la actividad de API pxAdjustSLATimes. Usted ajusta la fecha límite de una asignación por un motivo específico, no solamente para acelerar o ralentizar el aumento del valor pxUrgencyAssign. La desventaja de este enfoque es que la modificación de fecha límite frecuente impacta en la creación de reportes a nivel de asignación.
Las asignaciones que vuelven a persistir con frecuencia respecto del ajuste del plazo del SLA, el ajuste de pxUrgencyAssign o ambos también puede afectar el rendimiento del sistema.
Primero en entrar, primero en salir (FIFO)
Recuerde el debate sobre la circunstanciación y cómo personalizar la función Get Next Work (Obtener el trabajo siguiente). Suponga que la propiedad pxCreateDateTime de la asignación de la cesta de trabajo se usa como orden principal y no secundario. Dicho requerimiento podría existir para un grupo de trabajo que quiere que las asignaciones de la cesta de trabajo más antiguas se procesen primero, es decir, primero en entrar, primero en salir (FIFO). La definición de reportes pyGetWorkBasket detrás de la página de datos de la lista D_WorkBasket que se usa para mostrar asignaciones de cesta de trabajo puede modificarse de modo que se aplique un orden ascendente en pxCreateDateTime, en contraposición al orden descendente de pxUrgencyAssign, que se aplica de forma predeterminada.
Puede derivar un valor para pxUrgencyAssign posteriormente mediante ingeniería inversa si tiene en cuenta @CurrentDateTime() y la creación de la asignación de la cola de trabajo. El valor de pxUrgencyAssign no debe computarse hasta que aparezca en una UI.
Fecha límite de subcaso común
Suponga una duración de fecha límite de SLA específica del cliente para casos de reclamo. Esa duración se agrega a la propiedad pxCreateDateTime de cada caso de reclamo para establecer el valor DateTime de fecha límite del caso.
Todos los subcasos ClaimUnit de dicho caso deben finalizarse en la fecha límite del caso de reclamo padre. Sin embargo, los tipos de caso ClaimUnit distintos tardan, en promedio, tiempos diferentes en completarse. Para fines de eficacia, el tiempo promedio de finalización de cada tipo de ClaimUnit puede quedar disponible en una página de datos a nivel de nodo.
Cuando se deriva un caso ClaimUnit a una cola de trabajo, se puede computar su propiedad DateTime de pxGoalTime como @CurrentDateTime + (fecha límite del cliente – tiempo promedio de finalización). En este ejemplo, pxGoalTme representa el valor DateTime. El caso ClaimUnit se recupera de la cola de trabajo para que haya tiempo suficiente como para finalizar el trabajo.
Una versión circunstanciada de la ListView de GetNextWork de Assign-WorkBaset puede aplicar un orden ascendente en pxGoalTime, en lugar de usar el orden descendente de pxUrgencyAssign. Una versión circunstanciada de la definición de reportes pyGetWorkBasket también puede aplicar un orden ascendente en pxGoalTime.
La expresión de declaración de la regla para pxUrgencyAssign también puede circunstanciarse. En el siguiente ejemplo, se muestra cómo pxUrgencyAssign puede hacer ingeniería inversa en su valor en función de las propiedades datetime.
pxUrgencyAssign = min(100, 100 * ((CurrentDateTime – pxCreateDateTime) / (pxGoalTime - pxCreateDateTime)))
where: CaseDeadlineDateTime = CaseCreateDateTime + CustomerSLA (Assign-)
and: pxGoalTime = CaseDeadlineDateTime – CaseAvgTimeToComplete
Tenga en cuenta que las unidades de tiempo en el numerador y denominador, ya sean minutos, horas o días, se cancelan entre sí y crean una relación sin unidad. Es sencillo ver que el valor de pxUrgencyAssign será 100 con la fórmula anterior, cuando CurrentDateTime = pxGoalTime. La elección de 100 es arbitraria. Podría usarse cualquier factor, como 80. Ese valor puede definirse como configurable.
Truncar el valor asignado de 100 de pxUrgency es correcto siempre y cuando la consulta de Get Next Work (Obtener el trabajo siguiente) y la consulta de la lista de asignación de la cola de trabajo estén ordenadas de forma ascendente según pxGoalTime, no de forma descendente según pxUrgencyAssign. Es posible usar la misma definición de reportes para ambos propósitos.
Location
Hay situaciones en las que la urgencia no se determina en función del tiempo, sino de otra cosa, como la distancia. Por ejemplo, un conductor quiere que su próxima asignación se determine según la proximidad a su ubicación actual. En la solución de aplicación de reservas de FSG, se usa la ubicación de un conductor para identificar el hotel o el estacionamiento más cercano, donde los asistentes del evento esperan el transporte para ir a un evento o volver de él.
La aplicación de reserva invoca un conector de SQL para que compute la distancia. Es difícil incorporar una llamada de conector de SQL a la implementación GetNextWork proporcionada por Pega. Además, para invocar la acción de Get Next Work (Obtener el trabajo siguiente), se necesita acceso al portal de Pega. Puede usar una forma diferente de acceder a Pega, como una llamada al servicio REST, que implica un solicitante de app en lugar de un solicitante de navegador.
Acción de asignación abierta
Puede configurarse una acción de clic con botón como una asignación abierta; dicha acción requiere una pzInsKey de asignación. Se puede solicitar que una página de datos Assign-WorkBasket proporcione la pzInsKey.
La página de datos Assign-WorkBasket puede llamar a una definición de reportes. La definición de reportes puede filtrar las asignaciones donde el valor pyErrorMessage no es nulo. Un data transform posterior a la consulta puede revisar si el caso asociado a la cesta de trabajo está bloqueado, saltearlo y pasar a la siguiente asignación. La coincidencia de habilidades puede realizarse mediante un subreporte definido respecto de Index-AssignmentSkills que, a su vez, se une a Index-OperatorSkills.
Lanzamiento desde una lista de cola de trabajo calificado
La función Get Next Work (Obtener el trabajo siguiente) no es la única opción que se puede usar para recuperar una asignación de una cola de trabajo calificado, una en la que el trabajo se había enrutado con una actividad ToSkilledWorkBasket.
Suponga que un portal de coordinador de la instalación contiene una vista UIPages donde se muestran las asignaciones de caso de estacionamiento. Esta Persona no debería ver nada en dicha vista a menos que tenga la habilidad de estacionamiento.
La vista es similar a las listas de cola de trabajo que se envían a D_WorkBasket. La diferencia es que la definición de reportes debe tener en cuenta las habilidades del operador y la asignación. Este es un código pseudo-SQL para poder llegar a esto.
Main Report:
Parking work queue assignment list (similar to D_WorkBasket)
JOIN to FSG-Booking-Work-Parking (CASE) WHERE pxRefObjectKey = CASE.pzInsKey
Filters:
pxRequiredSkillCount = COUNT(rows in subreport)
Subreport:
Index-AssignmentSkills JOIN to Index-OperatorSkills (OPSKILL) WHERE pxRequiredSkill = true AND pxSkillName = OPSKILL.pxSkillName
Subreport filters:
pxInsIndexedKey = (main report) pzInsKey pxSKillRating <= OPSKILL.pxSKillRating OPSKILL.pyUserIdentifier = OperatorID.pyUserIdentifier
This Topic is available in the following Module:
¿Quiere ayudarnos a mejorar este contenido?