Plantillas de solución para Administración Avanzada de Casos: Parte1 - Ejemplo de manejo de aclaraciones de transacciones de tarjetas de crédito usando IBM Case Manager

IBM Case Manager provee la plataforma y herramientas que un analista requiere para definir e implementar una nueva generación de soluciones de administración de casos. Para acelerar el desarrollo de soluciones en industrias específicas, IBM Case Manager soporta plantillas de solución: colecciones de activos de administración de casos que pueden ser personalizados y extendidos para construir una solución completa. Para ilustrar el concepto de plantillas de solución y cómo las características de IBM Case Manager pueden ser usadas para crear una solución, IBM ha creado dos ejemplos de plantillas que pueden ser usadas como herramientas de aprendizaje para usuarios nuevos de la plataforma. Este tutorial presenta una de estas plantillas: Manejo de aclaraciones de transacciones de tarjetas de crédito. Esta plantilla de ejemplo puede servir como base para clientes que quieren construir soluciones similares. La plantilla puede servir también como herramienta de aprendizaje y referencia para construir otras soluciones en diferentes industrias.

Jeff Douglas, Industry Solutions, Enterprise Content Management, IBM

Jeff Douglas photoJeff Douglas es miembro del equipo de gerencia de producto dentro de la organizacin de administracin de contenido de IBM. Jeff se dedica a integrar el portafolio ECM con las soluciones estratgicas de varias industrias. Jeff ha estado en IBM por 6 aos y ha trabajado en el rea de administracin de la informacin por 18 aos.



02-05-2011 (Primera publicación 13-01-2011)

Antes de empezar.

Introducción

La administración de casos es una función crítica en prácticamente todos los negocios. La capacidad de procesar eficientemente los casos tiene impacto en todos los niveles de la organización, puede tener implicaciones regulatorias y es crítica para mantener la satisfacción y lealtad de los clientes. La implementación efectiva de una solución de administración de casos que cubra las necesidades actuales requiere una plataforma que permita realizar diferentes funciones, incluyendo la administración de contenido, administración de procesos de negocio, reglas de negocio, colaboración y capacidad de análisis. La solución debe poder integrarse de manera transparente con la infraestructura existente, aprovechando estos activos para proveer un contexto completo y consistente a los usuarios por medio de una interfaz diseñada a la medida de su forma de trabajo.

IBM Case Manager provee la plataforma y herramientas que un analista requiere para definir e implementar una nueva generación de soluciones de administración de casos. Para acelerar el desarrollo de soluciones en industrias específicas, IBM Case Manager soporta plantillas de solución: colecciones de activos de administración de casos que pueden ser personalizados y extendidos para construir una solución completa. Para ilustrar el valor de las plantillas de solución y las características de IBM Case Manager, IBM ha creado dos ejemplos de plantillas que pueden ser usadas como herramientas de aprendizaje para usuarios nuevos de la plataforma. Este tutorial presenta una de estas plantillas: Manejo de aclaraciones de transacciones de tarjetas de crédito. Esta plantilla de ejemplo puede servir como base para clientes que quieren construir soluciones similares. La plantilla puede servir también como herramienta de aprendizaje y referencia para construir soluciones en otras industrias.

Después de leer este tutorial, entenderá qué es una plantilla, qué activos incluye este ejemplo y cómo fueron construidos. Este tutorial incluye el código para esta plantilla ejemplo y las instrucciones para extraerlo y desplegarlo.

Prerequisitos

Este tutorial complementa el conocimiento de IBM Case Manager al profundizar en la forma de construir y desplegar una solución. Este tutorial asume que se cuenta al menos con un nivel básico de familiaridad con IBM Case Manager e IBM Case Manager Builder, así como con la plataforma IBM FileNet 8 y sus herramientas. Debe contarse con una instalación de IBM Case Manager y tener experiencia manejando las herramientas para construir una solución de administración de casos. Para mayor información sobre IBM Case Manager, incluyendo una visita guiada, vea la sección de recursos..

Audiencia

Este tutorial está dirigido a analistas de negocio y usuarios de tecnologías de información que buscan complementar su conocimiento de IBM Case Manager mediante el uso de plantillas y ejemplos concretos de construcción de activos.

Despliegue de la plantilla de ejemplo

Ten la sección descargas de este tutorial se incluye un archivo .zip con los artefactos de la solución. Aunque descargar y desplegar la plantilla no es un prerrequisito para este tutorial, es recomendado desplegar la solución de manera previa, de manera que pueda referirse al código directamente cuando sea discutido un tema. Los pasos para desplegar la plantilla y crear una solución a partir de ésta son simples y no deberían tomar más de un par de horas.

Para desplegar la solución, debe extraerse el contenido del archivo zip, creando la siguiente estructura de directorios:

/acmdemo1
	/Assets
		/Credit Card Dispute Management
		/CMTOS Solution Assets
		/Export Manifests
/P8 Assets
/Instructions

Dentro del directorio Instructions se encuentra un archivo llamado Deploying the Credit Card Template.pdf. Este documento contiene instrucciones detalladas para desplegar el ejemplo y ejecutarlo. También existen rutinas de demo que lo guiarán a través de la solución y le ayudarán a familiarizarse con los activos.


Sección 2. Introducción a IBM Case Manager y las plantillas de solución

Visión general de IBM Case Manager

Existen diferentes tipos de aplicaciones de administración de casos. Este tutorial se enfoca en soluciones de administración de casos que por su naturaleza se centran en las personas y que requieren la coordinación de diferentes servicios a través de la organización para proveer un servicio de negocio a un cliente. Típicamente esto incluye la creación de un archivo del caso y un proceso de seguimiento (o conjunto de procesos) que aseguran la entrega del servicio. El equipo de administradores de casos colabora para resolver y cerrar cada caso. Una vez que el caso se ha completado, la información relativa al caso es retenida por requerimientos regulatorios o para soportar procesos de negocio de mayor alcance.

Estos escenarios de administración de casos requieren de trabajo colaborativo, dinámico y enfocado a eventos. En ocasiones, los casos y los procesos que lo soportan tienen ciclos de vida muy largos y pueden incluir el cierre, suspensión y reapertura del caso.

Este tutorial presenta como ejemplo la administración de aclaraciones de transacciones de tarjetas de crédito. En el ejemplo, un cliente llama para aclarar un cargo en el estado de cuenta de su tarjeta de crédito y un caso es abierto para dar seguimiento a la aclaración. Muchas veces, estos casos pueden ser resueltos durante la llamada con el cliente. Pero algunos casos son más complejos y su procesamiento requiere la recolección de información de clientes y terceros, proveniente de diversos sistemas. Resolver un caso de este tipo requiere el trabajo colaborativo de distintos equipos, dentro y fuera de la organización. Existen acuerdos de servicio regulatorios o de la empresa que determinan restricciones de tiempo y maneras de interactuar con el cliente. Entregar este tipo de solución requiere la integración efectiva y el aprovechamiento de un amplio conjunto de capacidades, como se muestra en la Figura 1.

Figura 1. Capacidades requeridas por la administración avanzada de casos
Capacidades requeridas por la administración avanzada de casos

El contenido del caso debe ser recolectado y mantenido en un lugar seguro, además de transmitido de esta misma forma a todos los involucrados. El contexto debe estar completo y ser consistente para todos los usuarios. Los eventos, reglas de negocio y flujos de trabajo ayudan a automatizar partes del proceso para reducir errores, evitar la sobrecarga de los usuarios e incrementar su eficiencia. La colaboración eficiente entre los miembros del equipo es crítica. Proveer transparencia en el proceso es importante, no solo con propósitos operacionales, sino también para poder evaluar el impacto de la solución en el negocio.

IBM Case Manager provee una plataforma que integra capacidades de diferentes productos de IBM Software Group para cubrir los requisitos avanzados necesarios para lograr una adecuada resolución de los casos. La plataforma combina administración de contenido y administración de procesos de negocio junto con integración de reglas, eventos, colaboración y análisis estadísticos para ofrecer un producto integral de administración de casos. Adicionalmente, IBM Case Manager provee un conjunto de herramientas que permiten a los analistas de negocio definir soluciones rápidamente y colaborar con los clientes y el área de tecnología para hacerlas productivas.

Introducción a las plantillas de solución para la administración de casos

Existen soluciones de administración de casos para prácticamente todas las industrias, como puede verse en la Figura 2.

Figura 2. Administración de casos en diferentes industrias
Administración de casos en diferentes industrias

La mayor parte de los tipos de casos son de un alcance vertical, resuelven un problema en una industria específica. Aunque algunos tipos de casos son más bien horizontales, enfocándose a retos que ocurren en diferentes industrias.

Para ayudar al despliegue y entrega de estas soluciones, IBM Case Manager ofrece plantillas de solución. Una plantilla de solución contiene activos de administración de casos que pueden ser aplicables a un problema de negocio en particular. La plantilla de solución puede ser fácilmente personalizada y extendida para construir una solución completa.

Para ilustrar el concepto de plantillas de solución y cómo las características de IBM Case Manager pueden ser usadas para crear una solución, IBM ha creado dos ejemplos de plantillas con la primera versión del producto. Estas plantillas pueden ser usadas como punto de partida para construir una solución. También pueden ser usadas como referencia o herramientas de aprendizaje para quienes buscan construir soluciones propias. La primera plantilla de ejemplo es para la administración de aclaraciones de transacciones de tarjetas de crédito. El resto de este tutorial introduce esta plantilla, describe los activos que contiene y detalla cómo ha sido construida la plantilla. La segunda plantilla se refiere a la administración de reclamos en la industria aseguradora, se describe en la Parte 2 de esta serie.

La administración de aclaraciones de transacciones de tarjetas de crédito

La administración exitosa de las aclaraciones de transacciones de tarjetas de crédito requiere interacciones eficientes entre clientes, comercios, bancos y agencias de tarjetas de crédito. El aumento en el número de aclaraciones en años recientes, en conjunto con el incremente de los requerimientos regulatorios y un mayor foco en la satisfacción y retención de los clientes han puesto una presión significativa en los bancos y agencias de tarjetas de crédito para mejorar la forma en que administran las aclaraciones. Los errores e ineficiencias en el procesamiento de los casos de aclaración pueden resultar en costos adicionales, demoras y eventualmente en aclaraciones no resueltas y decremento de la satisfacción de los clientes.

En el flujo de ejemplo, un cliente llama para aclarar una transacción. Después de pasar por el sistema automático, un representante de atención al cliente (RAC) toma la llamada y recolecta detalles sobre el caso. Si el representante de atención no puede realizar la aclaración, el caso es transferido a un asesor de aclaraciones, que trabaja el caso hasta su conclusión. El asesor de aclaraciones trabaja con el cliente, el comercio y otros involucrados para revisar el caso y recolectar detalles. Él puede cerrar el caso directamente, confirmando el cargo en el estado de cuenta del cliente o solicitando una devolución. Si el comercio acepta la devolución, entonces se cierra el caso. Si no, el asesor de aclaraciones debe decidir, con base en los detalles del caso, si continuar la investigación con el comercio o simplemente emitir un nuevo estado de cuenta al cliente. En cualquier punto, el RAC o el asesor de aclaraciones pueden dirigir el caso al departamento de fraudes. Además, debe existir un conjunto de reglas que determinen automáticamente si se trata de un potencial fraude. Si el departamento de fraudes acepta el caso, ellos podrían crear un nuevo caso para investigar la cuenta.

La Figura 3 provee una vista de alto nivel de este flujo.

Figura 3. Flujo de alto nivel del flujo de administración de aclaraciones de tarjetas de crédito
Flujo de alto nivel del flujo de administración de aclaraciones de tarjetas de crédito

A través del ciclo de vida del caso pueden llegar documentos de soporte y generarse avisos para el cliente, la mayoría de los cuales son actualizaciones del estado del caso. Todos los participantes tienen acceso a los detalles del caso y es crítico que el contexto sea tan completo y consistente como sea posible, durante su resolución y cuando el caso se cierre.

La plantilla de ejemplo para la administración de aclaraciones de tarjetas de crédito implementa aspectos ilustrativos de este proceso, y provee activos que soportan el procesamiento de una aclaración. Se define un tipo de caso para la investigación de un fraude, pero los detalles de este tipo de caso no se detallan en este tutorial.


Sección 3. Implementación de la plantilla de administración de aclaraciones de tarjetas de crédito

IBM Case Manager permite al analista de negocio diseñar, construir, probar y desplegar una solución utilizando una herramienta llamada IBM Case Manager Builder. Este producto provee un ambiente fácil de usar que permite al analista de negocio describir su solución utilizando terminología que le es familiar, sin preocuparse por la complejidad asociada a la implementación técnica.

Para entender la implementación del ejemplo de administración de aclaraciones de tarjetas de crédito, debe comenzarse conociendo los activos definidos utilizando Case Manager Builder. Después comprender las extensiones realizadas a la plantilla usando FileNet P8 Process Designer (Process Designer). Finalmente, leer sobre algunos de los activos de interfaz con el usuario contenidos en la plantilla.

La estructura del modelo de objetos

Los artefactos de una solución de administración de casos se organizan en un modelo de objetos. Cada solución incluye un descriptor único, provisto por el usuario, que es utilizado como prefijo de todos los activos dentro de la solución. La solución contiene además una o más propiedades, tipos de documentos, roles y tipos de casos. Los tipos de documentos, propiedades y tipos de casos son definidos a nivel de la solución y usados a través de de los tipos de casos definidos.

Cada tipo de caso tiene propiedades, vistas de las propiedades, carpetas y tareas. Todas las propiedades definidas a nivel de tipo de caso son mapeadas a nivel solución para que puedan ser reutilizadas en otros tipos de casos. Los tipos de casos también contienen páginas de usuario que pueden ser personalizadas. Es posible crear nuevas páginas para cubrir las necesidades de los participantes.

La Figura 4 muestra el modelo de objetos de la administración de casos

Figura 4. El modelo de objetos de la administración de casos
El modelo de objetos de la administración de casos

Artefactos de la plantilla de ejemplo

Los activos en esta sección fueron definidos e implementados utilizando IBM Case Manager Builder. En conjunto, representan la definición y estructura de alto nivel de la plantilla.

Propiedades

Hay un número importante de propiedades definidas en la plantilla. Muchas propiedades son utilizadas para almacenar detalles de la aclaración, como información del cliente, la transacción y el comercio. Otras son propiedades asociadas con los tipos de documentos que son importantes para la solución. Finalmente, hay algunas propiedades que no están expuestas directamente al usuario final, pero que juegan roles importantes en el procesamiento de cada caso. Las propiedades son descritas con mayor detalle en la sección Extendiendo la plantilla usando Process Designer.

La Figura 5 muestra la vista de las propiedades en Case Builder

Figura 5. Vista de las propiedades en Case Builder
Vista de las propiedades en Case Builder

En esta vista se puede editar la propiedad Estado de la Aclaración, que es una cadena con una lista de opciones que enumera los posibles estados del caso. Pueden verse los diferentes elementos que pueden determinarse para una propiedad:

  • Tipo
  • Cardinalidad
  • Longitud
  • Valor por defecto
  • Descripción

Roles y bandejas de entrada

Existen diferentes roles definidos para la solución como se muestra en la Tabla 1.

Tabla 1. Roles en la solución
Nombre del rolDescripción
Representante de Atención al Cliente Primer punto de contacto para el cliente. Recolecta detalles sobre el caso, lo cierra si es posible o lo turna al asesor de disputas.
Asesor de aclaraciones Es responsable del caso de aclaración. Una vez que llega a su bandeja de entrada lo procesa desde su revisión hasta su cierre.
Supervisor de aclaraciones Administra un equipo de asesores de aclaraciones. Maneja escalamientos, revisa casos y reasigna trabajo.
Equipo de correspondencia Genera y envía toda la correspondencia de salida al cliente
Auxiliar administrativo Recibe la información del caso de parte de clientes, comercios y terceros.
Equipo de fraudes Investiga casos identificados como fraudes potenciales, incluyendo tarjetas perdidas o robadas y cargos no autorizados.
Legal Usualmente no se involucra en las aclaraciones, excepto en casos que requieran arbitraje y en algunos escalamientos.

Cada rol tiene una bandeja de entrada asociada. La plantilla define una bandeja de entrada personal para manejar las tareas asignadas a individuos o grupos de trabajo.

La Figura 6 muestra la vista del rol RAC en Case Builder

Figura 6. vista rol en Case Builder
vista rol en Case Builder

Tipos de documento

A través del proceso de administración de aclaraciones existen documentos que pueden ser incluidos en el caso. La Tabla 2 lista los tipos que categorizan estos documentos.

Tabla 2. Tipos de documento
Tipo de DocumentoDescripción
Forma de aclaración Captura los detalles del asunto cuando el cliente comienza la aclaración por correo, correo electrónico o fax
Documento de soporte Cualquier documento que es almacenado con el caso, incluyendo recibos, facturas, correos, etc.
Correspondencia Cualquier carta o documento enviado al cliente. Incluye una propiedad que identifica el tipo específico de documento (estado, requerimiento de información, fraude, etc.)
Documento de devolución Documentos enviados a la agencia de tarjetas de crédito o asociación representando el comercio para el procesamiento de una devolución
Encuesta Contiene información sobre el proceso proporcionada por el cliente. El análisis de su contenido ayudará a mejorar el proceso.
Grabación de llamadas Almacena llamadas telefónicas generadas durante el caso

Para los documentos de correspondencia y soporte, se utiliza una propiedad para identificar el tipo específico de documento. Esto es útil para efectos de auditorías, así como para análisis posteriores. Por ejemplo, los documentos de correspondencia tienen propiedades para almacenar la fecha en que fue requerido, la fecha de envío y el tipo de carta. Estas propiedades pueden ser usadas en conjunto para analizar si los acuerdos de servicio relativos a la correspondencia están siendo cumplidos. Los análisis pueden realizarse para todos los documentos de correspondencia o enfocarse en un tipo particular.

La Figura 7 muestra la definición del tipo de documento correspondencia en Case Builder

Figura 7. La vista de tipos de documento en Case Builder
La vista de tipos de documento en Case Builder

Tipos de casos

La plantilla define dos tipos de caso. El primero es administración de aclaración, que define el proceso requerido para resolver una aclaración correspondiente a una transacción. Este es el tipo de caso que detalla este tutorial

El segundo tipo es investigación de fraude, que corresponde a los casos donde la aclaración de una transacción involucra un potencial fraude. Mientras muchos de los procesos que implementa el tipo de caso fraude son similares a los del tipo aclaración, hay dos diferencias fundamentales por las que se creó un nuevo tipo de caso:

  • La forma de abordar cada caso es diferente. En una aclaración, el foco está en una transacción individual, mientras que al investigar un fraude el foco cambia a la cuenta completa. Esta diferencia es importante, pues impacta los detalles del caso y el flujo del proceso.
  • El ciclo de vida de los casos también es diferente. La mayor parte de las aclaraciones individuales son resueltas en días. Por otro lado, un caso de investigación de fraude puede permanecer abierto por un tiempo significativamente mayor, mientras el equipo del caso trabaja en casos individuales asociados a la cuenta.

Estructura del tipo de caso administración de aclaración

Cuando se define un tipo de caso, el analista de negocio puede especificar muchos aspectos de la estructura del caso, desde las tareas que procesa y la interfaz que se presenta al usuario, hasta la estructura de carpetas que se creará para cada instancia del caso.

Carpetas

En IBM Case Manager, una instancia caso es representada como una carpeta de caso en el repositorio de contenido (ECM). Las propiedades del tipo de caso son representadas como propiedades de la carpeta. Adicionalmente, el analista de negocio puede especificar una estructura de subcarpetas que deben crearse en cada nueva instancia del caso.

Para el tipo de caso administración de aclaración, hay dos subcarpetas adicionales: una carpeta de correspondencia y otra para documentos de soporte. Siempre que una nueva instancia de tipo administración de aclaración es creada, también se crea esta estructura de carpetas. La subcarpeta de correspondencia almacena toda la correspondencia que se genera para el cliente. La subcarpeta de documentos de soporte es creada para almacenar cualquier contenido relevante al caso. Contar con esta infraestructura adicional facilita la adición de documentos al caso, así como realizar búsquedas y análisis en el contenido.

La Figura 8 muestra la estructura de carpetas. Cada instancia de la solución de tarjetas de crédito tiene esta estructura.

Figura 8. Estructura de carpetas para la plantilla de aclaraciones de tarjetas de crédito
Estructura de carpetas para la plantilla de aclaraciones de tarjetas de crédito

Vistas

Para ayudar a los participantes a organizar la información del caso, Case Builder permite al analista de negocio crear vistas de las propiedades del caso. Para el tipo de caso administración de aclaración, las propiedades visibles del caso se organizan en los siguientes tres grupos:

Información del cliente:
Toda la información del cliente, incluyendo la cuenta a la que pertenece la transacción en aclaración.
Detalles de la transacción:
Información detallada de la transacción en aclaración
Detalles de la aclaración:
Información sobre la aclaración provista por el asesor de aclaraciones cuando revisa el caso.

La Figura 9 muestra la vista de datos del caso.

Figura 9. Vista de datos del caso para el tipo administración de aclaración
Vista de datos del caso para el tipo administración de aclaración

En la sección Personalizar la página de trabajo utilizando una eForm se explica cómo utilizar una eForm para presentar esta información al RAC y al asesor de aclaraciones.

Tareas

La Figura 3 muestra un flujo de tareas de alto nivel para manejar un caso de aclaración. La Figura 10 muestra el mismo flujo, mapeando las actividades del proceso con tareas de la plantilla.

Figura 10. Flujo de alto nivel para aclaración de operaciones de tarjetas de crédito
Flujo de alto nivel para aclaración de operaciones de tarjetas de crédito

Cada una de las cajas en la Figura 10 corresponde a tareas en el tipo de caso administración de aclaración. La Figura 11 muestra las tareas listadas en IBM Case Manager Builder.

Figura 11. Tareas definidas para el tipo administración de aclaración
Tareas definidas para el tipo administración de aclaración

Revisar aclaración y cerrar caso son las únicas tareas requeridas para este tipo de caso. Son soportadas por otras tareas opcionales, la mayoría de las cuales son instanciadas al establecer las propiedades del caso. Un participante puede instanciar las siguientes tareas explícitamente:

  • Solicitar carta
  • Revisar caso
  • Solicitar copia de recibo

La tarea revisar aclaración es la tarea principal del caso. La Figura 12 muestra el flujo de tareas:

Figura 12. Flujo de la tarea revisar aclaración
Flujo de la tarea revisar aclaración

Cuando se abre el caso se inicia la tarea revisar aclaración y se presenta al RAC. Después de recolectar información inicial, el RAC puede elegir entre cerrar el caso, turnarlo al departamento de fraudes o procesar la aclaración. Si decide procesar la aclaración se pasa el control a un asesor de aclaraciones, y desde este momento él es responsable del caso hasta su cierre. En este flujo, el proceso de devolución, el inicio de investigación de fraude y el cierre del caso son pasos automáticos que establecen propiedades del caso que inician nuevas tareas. La siguiente sección muestra cómo hacerlo.


Sección 4. Extendiendo la plantilla usando Process Designer

Cuando el analista de negocio está implementando su solución basada en una plantilla, hay partes donde debe utilizar Process Designer para implementar características adicionales. En esta plantilla, Process Designer ha sido usado para añadir pasos de integración para realizar actividades específicas. Process Designer has sido usado además para establecer valores en las propiedades de las bandejas de entradas, administrar el estado del caso y configurar grupos de trabajo. Adicionalmente, Process Designer integra una eForm en la interfaz del usuario, como se describe en la sección Personalizar la página de trabajo utilizando una eForm de este tutorial.

Uso de Process Designer para establecer valores de las bandejas de entrada

Es una práctica común utilizar funciones o campos de sistema para establecer valores de las propiedades de los casos o de las bandejas de entrada. Esto se realiza fuera de Case Builder, en Process Designer. La integración entre estas dos herramientas facilita moverse entre ellas para extender la solución.

Al moverse entre estas herramientas debe tomarse en cuenta las siguientes recomendaciones:

Antes de abrir una solución en Process Designer, hay que asegurarse que se ha guardado y cerrado la solución en Case Builder.
Si ambas herramientas están abiertas es posible que los cambios realizados en una sean sobrescritos por la otra. La mejor opción es tener la solución abierta solo en una herramienta a la vez.
Al abrir la solución de Process Designer hay que asegurar que se usa la opción del menú Archivo > Solución > Edición.
Al navegar al directorio de la solución y seleccionar el archivo de definición de la solución se provee todo el contexto de la solución a Process Designer.
En Process Designer, las propiedades de los casos son referenciadas por su nombre simbólico.
De hecho, esto es así en todas las aplicaciones fuera de Case Builder. Por ejemplo, si la solución de tarjeta de crédito tiene un identificador de solución CCDM, todas las propiedades, documentos, tipos, roles, etc. Tendrán un prefijo CCDM_. El nombre simbólico de la propiedad case owner definida en Case builder sería CCDM_CaseOwner. Es importante notar la capitalización y los espacios removidos.
Las propiedades del caso, las propiedades de cada instancia y los campos de datos de flujo de trabajo son entidades diferentes.
Cuando un tipo de caso es definido en Case Builder, éste es modelado como una carpeta en FileNet P8 Content Engine. Cuando se define una propiedad para un tipo de caso, ésta es modelada como una propiedad de la carpeta. Aquí es donde los valores de las propiedades de cada instancia del caso son almacenados. Los campos de datos de flujo de trabajo deben ser inicializados con las propiedades del caso. Case Builder realiza esta operación automáticamente, pero cuando se definen pasos en Process Designer, debe realizarse de manera manual. Consideremos como ejemplo que se quiere establecer el valor de una columna de la bandeja de entrada. Cuando un investigador de fraudes ve su bandeja de entrada, ésta luce como en la Figura 13.
Figura 13. valores de columnas de la bandeja de entrada en Process Designer
valores de columnas de la bandeja de entrada en Process Designer

La Figura 13 muestra el flujo de la tarea evaluar fraude tal como fue creada en Case Builder. Pueden observarse los valores pre asignados para el paso evaluar fraude. Los valores para CCDM_AsignedDate son establecidos utilizando una función de sistema (systemtime), mientras que para CCDM_WorkItem se utiliza un campo de sistema (F_StepName). Estos valores aparecerán en la bandeja de entrada cuando ésta sea desplegada. Esta es la manera más simple para acceder funciones y campos de sistema para usarlas en las bandejas de entrada.

Sin embargo, estos valores no son almacenados con el caso a menos que sean asignados a la instancia del caso subyacente. Para pasos de usuario como el flujo de tareas creado en Case Builder, Case Manager maneja esta asignación de manera automática. Para las asignaciones posteriores que ocurren para el paso evaluar fraude, Case Manager automáticamente provee un mapeo entre el dato en el flujo de trabajo generado de la propiedad del caso y la propiedad correspondiente que es almacenada con la instancia del caso, como se muestra en la Figura 14.

Figura 14. Mapeo de los campos de flujo de trabajo a propiedades del caso
Mapeo de los campos de flujo de trabajo a propiedades del caso

Case Manager hace este mapeo automáticamente solo para pasos creados en Case Builder. Cuando se crean pasos en Process Designer que asignan propiedades del caso y requiere que éstas sean almacenadas en el caso, se debe hacer el mapeo de manera manual o asignar los valores directamente en las propiedades del caso asociadas con la instancia.

Administración del estado del caso

Los hitos pueden ser un mecanismo muy útil para dar seguimiento del progreso de un caso, dar inicio a nuevas actividades o administrar tiempo y escalamientos.

Desafortunadamente, la versión actual de IBM Case Manager no soporta la definición de hitos que se extiendan a diferentes casos. Para modelar esta capacidad, la solución de tarjetas de crédito utiliza una propiedad del caso llamada Dispute Case State. Esta propiedad da seguimiento al estado actual del caso y puede ser usada de manera similar a un hito.

Un uso importante de esta propiedad es iniciar tareas automáticas. Por ejemplo, la tarea evaluar fraude se inicia cuando se cumple la siguiente condición:

Dispute Case State = 'Fraud'

La propiedad toma este valor cuando el RAC o el asesor de aclaraciones presionan Submit to Fraud en la pantalla de revisión del caso. Este funcionamiento está especificado en la tarea review dispute item en Process Designer, como se muestra en la Figura 15. La ruta seleccionada es el conector entre review dispute e initiate fraud investigation. Es una ruta condicional, dependiente de que se provea la respuesta submit to fraud.

Figura 15. Ruta condicional en Process Designer
Ruta condicional en Process Designer

El paso initiate fraud investigation es un paso de asignación. Su implementación se muestra en la Figura 16, que muestra seleccionados la tarea review dispute item y el paso initiate fraud investigation.

Figura 16. Manipulación de estados de casos en Process Designer
Manipulación de estados de casos en Process Designer

Hacen falta dos cosas en este paso. Primero, debe solicitarse el envío de una carta para informar al cliente que este caso ha sido dirigido al departamento de fraudes. Para hacer esto, se establece el valor de la propiedad fraud request letter a verdadero, lo que crea una instancia de la tarea automática generate letter.

Posteriormente, el caso será enviado al departamento de fraudes para su evaluación, estableciendo el estado del caso a fraud.

En cada caso, se almacena la asignación estableciendo directamente el valor en la propiedad de la instancia en la carpeta del caso.

	F_CaseFolder.CCDM_DisputeCaseState = "Fraud"

Se utiliza el prefijo F_CaseFolder y el nombre simbólico de la propiedad CCDM_DisputeCaseState. El valor es almacenado con el caso y se inicia la tarea de revisión de fraude.


Sección 5. Manteniendo una política de punto único de contacto para el caso

Administración de grupos de trabajo

Administrar eficientemente las aclaraciones es crítico para la satisfacción y retención de clientes. Para mejorar la eficiencia y simplificar la interfaz con el cliente, los bancos insisten en una política de punto único de contacto. Esto implica que una vez que un caso es asignado a un asesor, este asesor es responsable por el caso hasta que sea cerrado. Desde la perspectiva del cliente, es importante que este único responsable se mantenga, sin importar cuantas personas interactúen con el caso tras bastidores.

La implementación de este modelo en la solución para tarjetas de crédito hace uso exhaustivo de los grupos de trabajo. Una vez que un asesor de aclaraciones es asignado en la tarea revisar disputa, las siguientes tareas serán asociadas directamente a este individuo, en lugar de al rol asesor de aclaraciones.

Para esta implementación deben completarse los siguientes pasos:

  1. Crear una propiedad del caso llamada owner.
  2. Crear un grupo de trabajo llamado CaseOwner dentro de cada tarea que dirija trabajo al asesor de aclaraciones
  3. Usar Process Designer para añadir la asignación del dueño del caso, como se muestra en la Figura 17. El dueño del caso es asignado al final del paso revisar aclaración dentro de la tarea revisar aclaración. La función userid()regresa el nombre del usuario actualmente trabajando con el caso.
Figura 17. Asignación de la propiedad del caso
Asignación de la propiedad del caso

Una vez que se almacena el valor de la propiedad puede ser utilizado en otras tareas. Por ejemplo, la tarea automática añadir documento es iniciada cuando un documento del tipo documento de soporte es ingresado al sistema. Un miembro del equipo de auxiliares procesa el documento y el responsable del caso es notificado para que revise el documento. Este flujo se muestra en la Figura 18.

Figura 18. Asignación del grupo de trabajo
Asignación del grupo de trabajo

Cuando se crea esta tarea en Case Builder, se crea un grupo de trabajo llamado CaseOwner. Al inicio de este flujo de tareas, el valor de la propiedad owner es asignado en el grupo de trabajo, de manera que el trabajo que se genere sea dirigido a su bandeja de trabajo personal. Esto asegura que el responsable del caso vea y procese el nuevo documento directamente.

La propiedad owner en conjunto con los grupos de trabajo es utilizada en todas las partes de la solución para implementar la política de punto único de contacto. Además, esto permite a los supervisores analizar los casos agrupados por responsable, de manera que pueden dar seguimiento a la carga de trabajo de los asesores y medir sus niveles de servicio. Para reasignar trabajo, un supervisor simplemente necesita volver a asignar la propiedad owner de un caso desde la página de detalle del caso.


Sección 6. Los activos de interfaz de usuario

Dentro de la solución de tarjetas de crédito, existen diferentes partes donde la interfaz de usuario puede ser personalizada para cubrir las necesidades de un rol particular. En la plantilla de tarjeta de crédito, las páginas de trabajo del RAC y el asesor de aclaraciones están personalizadas utilizando una eForm. La propia página de trabajo ha sido personalizada para proveer más información del caso al participante antes de que empiece a trabajar con un elemento en particular.

Personalización de la página de trabajo

Cuando el RAC selecciona un elemento de su bandeja de entrada, los detalles del caso se presentan en el widget de información del lado derecho. El RAC puede ver los documentos en el caso así como información histórica (ver figura 20). Adicionalmente, el RAC puede utilizar el widget en el fondo de la página para buscar casos relacionados, por identificador de caso o por el nombre del cliente.

Figura 19. La página de trabajo para la plantilla de administración de aclaraciones
La página de trabajo para la plantilla de administración de aclaraciones

Esta página incluye diferentes personalizaciones. Primero, utiliza una hoja de estilos personalizada (provista por el producto) para dar una apariencia diferente al fondo. Para cambiar la hoja de estilos deben seguirse los siguientes pasos:

  1. Seleccionar Editar página en la esquina superior derecha de la página
  2. Presionar Personalizar
  3. Seleccionar la pestaña Cambiar estilos
  4. Seleccionar de la colección de estilos
  5. Presionar Guardar para guardar los cambios
  6. Repetir para cada página en la que se quiera cambiar el estilo, ya que los cambios a nivel de espacio no están soportados.

Una segunda personalización se refiere al identificador del caso. Por defecto, los identificadores de caso tienen el siguiente formato:

<solution descriptor>_<case type name>_<unique numeric id>

Entonces, un identificador por defecto para un caso de administración de aclaración podría ser: CCDM_ManageDisputeItem_000000100004.

Puede resultar útil crear una versión más corta de identificador para ayudar en la presentación y búsqueda. En el ejemplo, el identificador del caso ha sido acortado mediante la eliminación de la información del tipo de caso. Puede encontrarse más información sobre la personalización de identificadores de caso en la sección de recursos.

Para proveer la funcionalidad de información y listado de casos, la página de trabajo ha sido personalizada mediante la adición de tres widgets. La capacidad para listar todos los casos para un cliente particular es provista por la adición de un widget al final de la página ligado al widget de bandeja de entrada utilizando el JavaScript adapter widget.

Cuando se selecciona un renglón en la bandeja de entrada, el widget de la bandeja de entrada envía el nombre del cliente del renglón seleccionado como información de entrada al JavaScript adapter widget. El adaptador utiliza el nombre del cliente en una consulta, y genera un evento para el widget de listado de casos, como se muestra en la Figura 20.

Figura 20. Liga de la bandeja de entrada con el widget de listado de casos
Liga de la bandeja de entrada con el widget de listado de casos

En el lado derecho se ha añadido el widget de información del caso y se ha ligado con el widget de bandeja de entrada. Esta liga se logra editando el widget de la bandeja de entrada. El ejemplo envía el renglón seleccionado al widget de comandos, que es un widget no visible en cada página que puede publicar eventos. Se selecciona una acción específica (retrieve case info), que provee la información del caso y después publica este evento. El widget de información del caso recibe y procesa el evento y llena sus propios campos con la información recibida.

Presentación de un documento en la interfaz de usuario.

En cualquier punto del procesamiento de un caso de aclaración, un participante puede añadir nuevo contenido. Cuando esto ocurre, un elemento de trabajo es enviado al asesor de aclaraciones para que pueda revisar el documento y actualizar el caso como sea requerido. La Figura 21 muestra la vista personalizada que el asesor de aclaraciones utiliza para revisar un nuevo documento.

Figura 21. Página de revisión de documentos nuevos.
Página de revisión de documentos nuevos.

Esta vista es presentada como parte de la tarea añadir documento. Esta tarea es iniciada siempre que un nuevo documento de soporte se añade al caso. Este nuevo documento es automáticamente presentado en la vista del asesor de aclaraciones, como se muestra en la Figura 21.

Para proveer esta capacidad se aprovecha el hecho de que para las tareas que tienen como prerrequisito un nuevo documento, el anexo de inicio es llenado automáticamente con el nuevo documento. Para configurar esta vista deben realizarse los siguientes pasos:

  1. Abrir el flujo de tareas en Case Builder
  2. Crear un anexo llamado NewDocument
  3. Guardar y cerrar la solución
  4. Abrir la solución son Process Designer y abrir el flujo de trabajo.
  5. En las propiedades del flujo de trabajo, asignar el anexo NewDocument como el anexo de inicio
  6. Guardar la solución y cerrar Process Designer
  7. Abrir la página de trabajo en IBM Manager Client y editar las propiedades del widget de selección de archivos para que envíe el documento a la vista.

Personalización de la página de trabajo utilizando eForms

Dentro de la plantilla de tarjetas de crédito, se utiliza una eForm para proveer a los participantes una vista consolidada de las propiedades del caso. Los detalles del origen de la información se ocultan, permitiendo a que los participantes se enfoquen en el trabajo que deben completar.

Las eForms pueden ser usadas para proporcionar una vista actualizada de las propiedades del caso mientras se mueve a través de diferentes pasos y diferentes participantes. La Figura 22 muestra la interfaz de usuario para el RAC cuando recolecta detalles iniciales sobre el caso.

Figura 22. Página de trabajo del RAC.
Página de trabajo del RAC.

El widget de la izquierda es una eForm que reemplaza al widget de datos del caso. El RAC puede ingresar detalles sobre el caso. Esta eForm es estática, toda la información es ingresada de manera manual. Sin embargo, esta eForm puede ser fácilmente extendida para incluir la lógica para recuperar los datos del cliente o de la transacción de una base de datos una vez que se ha provisto información inicial. Un sistema de reglas podría ejecutarse en segundo plano para utilizar información que proporciona el RAC y dinámicamente habilitar o deshabilitar campos o incluso añadir y remover campos para guiar al RAC en la recolección de información adecuada para el caso.

Cuando el RAC completa su trabajo en esta página, la eForm y s estado es guardado en un documento. La Figura 23 muestra una vista de la página de trabajo personalizada para el asesor de aclaraciones.

Figura 23. Uso de una eForm en la página de trabajo del asesor de aclaraciones.
Uso de una eForm en la página de trabajo del asesor de aclaraciones.

El asesor de aclaraciones tiene una vista de la eForm del lado izquierdo. Toda la información provista por el RAC es preservada, y el asesor puede continuar modificando la forma. Adicionalmente, la eForm ha sido guardada como un documento con el caso. Los participantes pueden abrir el documento para tener una vista de solo lectura de los detalles de la aclaración. Este documento contendrá siempre la información más actualizada sobre el caso.

La integración de esta eForm en la solución de administración del caso es simple.

Esta integración requiere trabajar con eForms Designer, IBM Case Manager Client, IBM Case Manager Builder y Process Designer. Deben realizarse los siguientes pasos:

  1. Diseñar la eForm en eForms Designer, como se muestra en la Figura 24. Los nombres de las celdas deben coincidir con los nombres simbólicos de las propiedades del caso para que los datos de la forma sean transferidos a las propiedades una vez que la forma sea sometida.
    Figura 24. Diseño de la eForm en eForm Designer.
    Diseño de la eForm en eForm Designer.
  2. Personalizar los detalles de la página en Case Manager Client. Puede utilizarse como base la eForm de la página de trabajo. Esta página incluye el widget con la eForm, que eventualmente contedrá la nueva eForm.
  3. Registrar la página con el nombre Gather Customer Data
  4. Abrir la tarea revisar aclaración en Case builder. Puede crearse un anexo que almacene el documento de la eForm y añadirlo como parámetro de los pasos donde aparecerá. La Figura 25 muestra como se añade el paso iniciar aclaración.
    Figura 25. Creaciónde un anexo para guardar el documento de la eForm.
    Creaciónde un anexo para guardar el documento de la eForm.
  5. Asignar el diseño de página del paso iniciar aclaración para que sea la página personalizada, como se muestra en la Figura 26.
    Figura 26. Configuración de la página de trabajo personalizada.
    Configuración de la página de trabajo personalizada.
  6. Guardar y cerrar la solución
  7. Desde Process Designer, abrir la solución y el flujo de tareas revisar aclaración
  8. En las propiedades del flujo de trabajo, seleccionar la pestaña Anexos
  9. Asignar el valor del anexo a la nueva eForm, como se muestra en la Figura 27
    Figura 27. Asociación de la eForm con el nuevo anexo.
    Asociación de la eForm con el nuevo anexo.
  10. Guardar los cambios en Process Designer
  11. Desplegar nuevamente la solución desde Case Builder para dirigir el trabajo a la página de trabajo personalizada.

Sección 7. Conclusión

Las plantillas de solución son una parte importante de la plataforma IBM Case Manager. Constituyen un acelerador para que los clientes construyan sus propias soluciones utilizando esta plataforma. Como parte de la primera versión de IBM Case Manager, IBM ha creado dos plantillas de ejemplo para que sirvan como herramientas de aprendizaje y evaluación de las herramientas. Este tutorial introduce la plantilla de ejemplo de administración de aclaraciones de transacciones de tarjetas de crédito, describe los activos que contiene y da una idea de cómo fueron construidos algunos de ellos. Después de leer este tutorial el lector deberá estar familiarizado con el concepto de plantillas y tener un mejor entendimiento de cómo utilizar IBM Case Manager en conjunto con oras herramientas de la plataforma IBM FileNet P8 para construir una solución completa de administración de casos.


Descargar

DescripciónNombretamaño
Artifacts of the CCDM solutionccdm.zip1050KB

Recursos

Aprender

Obtener los productos y tecnologías

  • Build your next development project with IBM trial software, available for download directly from developerWorks.

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Information mgmt
ArticleID=650758
ArticleTitle=Plantillas de solución para Administración Avanzada de Casos: Parte1 - Ejemplo de manejo de aclaraciones de transacciones de tarjetas de crédito usando IBM Case Manager
publish-date=05022011