Diseño de casos

El primer paso de la actividad de diseño de casos en la fase de preparación consiste en revisar el backlog de los tipos de caso y en crear el tipo de caso para cada Microjourney^™ que se haya priorizado para el Minimum Lovable Product (MLP). Es importante asegurarse de que lo que planea desarrollar tenga sentido.

El objetivo de la actividad de diseño de casos consiste en:

• Crear los tipos de casos fundamentales y las asociaciones entre ellos a modo de preparación para la fase de Desarrollo.
• Validar el alcance funcional del Microjourney con el Product Owner.
• Asegurarse de que el diseño del caso aplica las prácticas recomendadas desde el inicio.

Usando Directly Capture Objectives (DCO), el Business Architect, el System Architect y el Product Owner colaboran para modelar el tipo de caso en etapas y pasos. Esta actividad divide el tipo de caso en las partes que lo componen.

Una vez que se acordaron los pasos y las etapas con el Product Owner, en otros debates se definen las Personas involucradas en el tipo de caso y los objetos de datos necesarios para completar el procesamiento. Al final de las sesiones de DCO, tiene una representación visual del tipo de caso que debe ser validado por el Product Owner.

Para asegurarse de que se adopten las prácticas recomendadas para el diseño de casos desde el inicio, el System Architect (SA) lidera los aspectos de diseño técnico del tipo de caso dentro de la sesión de DCO.

El SA se asegura de que el diseño de casos tenga en cuenta lo siguiente:

• Flujo de trabajo
• Personas y canales
• Datos
• Reutilización
• Escala

En la siguiente imagen, haga clic en + para obtener más información sobre las etapas y los pasos del diseño de casos.

La combinación de etapas y pasos determina el flujo de trabajo del caso. En la mayoría de los negocios, hay varias combinaciones de trabajo:

• Algunos trabajos se pueden ejecutar en secuencia.
• Algunos trabajos se pueden realizar en paralelo.
• Algunos trabajos pueden ser óptimos; esto es aplicable solo en condiciones especiales.  

Al inicio del proyecto, los diferentes tipos de trabajo influyen en el diseño del caso. En función de las conclusiones de los talleres con el Product Owner, el Lead System Architect (LSA) considera las prácticas técnicas recomendadas. Cuando sea apropiado, este puede decidir crear tipos de caso adicionales (por ejemplo, permitir el trabajo paralelo mediante casos hijo).

Otra consideración del diseño del caso es la asignación de trabajo, que se analiza y acuerda al principio del proyecto. La asignación de trabajo define la manera en la que el trabajo se dirige hacia las Personas vinculadas con el tipo de caso. Para definir el modelo de asignación de trabajo, se debe comprender el modelo operativo del negocio.

Hay dos modelos para la asignación de trabajo:

• Modelo push: En un modelo push, el sistema o un gerente del equipo asigna el trabajo al usuario adecuado de forma manual.
• Modelo pull: En un modelo pull, se asigna trabajo al usuario de forma automática en función de un conjunto de reglas de negocio.

Con el enfoque de Pega Express^™, las Personas se asocian con etapas dentro de un tipo de caso para representar la interacción de la Persona durante el caso. También se asocian con canales para indicar de qué manera la Persona puede acceder a la aplicación (por ejemplo, por correo electrónico o usando una página web de autoservicio). 

Como Pega Platform puede asociar una Persona con un canal, usted puede ocuparse de la UI y los procesos específicos del canal a fin de crear una experiencia de usuario que sea adecuada para esa situación en particular.

Como parte de las sesiones de DCO que se realizan durante la fase de preparación, el Product Owner y el Business Architect (BA) mapean las Personas a las etapas para asegurarse de que se traten los escenarios de negocio dentro del alcance del tipo de caso. Como parte de estos debates, es importante entender qué tipo de interacciones puede generar la Persona dentro de un canal específico. Por ejemplo, puede ser posible crear un reclamo a través de un canal de autoservicio, pero no por correo electrónico. 

Seguridad en función de la Persona y el canal

También se definen los derechos de acceso a los datos y los procesos para el tipo de caso. Los derechos de acceso pueden influir en el diseño del tipo de caso de diferentes maneras, por ejemplo:

• Excluir trabajo o datos de canales específicos.
• Separar el trabajo en diferentes etapas dentro del tipo de caso.
• Crear un tipo de caso completamente nuevo.  

En función de los requerimientos de seguridad, el SA debe determinar cuál será el diseño del tipo de caso para cubrir las necesidades de seguridad.

Al principio del proyecto, usted necesita tener una comprensión general de los objetos de datos vinculados al tipo de caso para asegurarse de que el diseño se ajuste a las necesidades de datos. 

El System Architect debe comprender lo siguiente para cada objeto de datos:

• Disponibilidad y prontitud
• Retención y archivado 

La disponibilidad de los datos se refiere a la fuente de los datos. Algunos datos pueden estar disponibles en sistemas externos. Los usuarios pueden capturar otros datos directamente, y algunos datos tal vez no estén disponibles, sino que se deban crear a medida que avanza el caso. La prontitud de los datos hace referencia a con cuánta rapidez se pueden recuperar datos de otros sistemas y con cuánta frecuencia cambian los datos.

Dada la concienciación cada vez mayor de los requerimientos de privacidad de los datos, las reglas de retención de datos del cliente influyen directamente en la actividad de modelado de datos asociada con el diseño del caso. Para identificar estas reglas desde el principio, el SA debe diseñar el tipo de caso para optimizar la gestión de datos dentro del caso. 

Ejemplo: El flujo de trabajo de un banco puede capturar los detalles del banco en el último momento posible dentro del caso para evitar tener información del banco hasta que sea necesario. Además, el flujo de trabajo puede necesitar un paso automático de eliminación de los detalles del banco cuando ya no exista un motivo de negocio legítimo para retener los datos.

Al comienzo del proyecto, identifique las áreas clave en el tipo de caso que puedan ser útiles para otros tipos de caso o MLP posteriores. Esto le da al SA información para orientar la actividad de diseño del caso durante la fase de preparación y permitir la reutilización del tipo de caso en su totalidad o de partes del tipo de caso (por ejemplo, procesos específicos, datos e interfaz de usuario). La práctica recomendada consiste en identificar los aspectos en común desde el punto de vista técnico y del negocio. Luego, especificar y diseñar los aspectos en común como reglas o componentes para utilizar en varios tipos de caso.

Considere la frecuencia y los volúmenes de los casos a la hora de diseñar el tipo de caso para la escala. La escala también considera la interacción de las Personas con el tipo de caso. 

Diferentes miembros del equipo usan la escala para diseñar el tipo de caso:

• El Product Owner y el BA revisan el flujo de trabajo para decidir qué niveles de automatización implementar en el tipo de caso.  
• El System Architect considera los mecanismos para acceder a los datos del tipo de caso y almacenarlos.

Cuando ocurren casos de manera frecuente y en grandes volúmenes, céntrese en el diseño del caso para maximizar el procesamiento directo y así lograr el mejor rendimiento posible en el menor tiempo.   

Reconocer el volumen del caso orienta las conversaciones de diseño iniciales hacia considerar las necesidades de datos asociadas con los tipos de caso. Este reconocimiento pone de relieve los cambios necesarios en el modelado del caso inicial para garantizar que el acceso a los datos sea eficiente y esté optimizado, y así evitar una carga indebida sobre las interfaces y los tiempos de respuesta. 

Durante la fase de preparación, tome nota de estos aspectos como historias de usuario y agréguelos al backlog para una mayor elaboración durante el proyecto. 

Compruebe sus conocimientos con la siguiente actividad.