Identificación de caso

Desde el principio, Pega ha seguido la práctica recomendada de gestión de procesos de negocios de reconocer la separación de intereses que existe entre el trabajo y los datos. La Estructura de clase empresarial (ECS) de Pega formaliza esta distinción con sus clases Work- y Data-. Pega utiliza casos de Work-Cover-Extending (Extensión de cobertura de trabajo) que se dividen en una o más etapas (dentro de las cuales hay uno o más flujos de Work-extending [extensión de trabajo]). El propósito de un flujo es administrar datos del negocio, que se implementan mediante una clase de Data-extending (Extensión de datos).

El rol de un Lead System Architect certificado por Pega es decidir qué funciones de Pega Platform™ usar: casos, etapas, pasos, procesos (flujos), subprocesos (subflujos), objetos de datos, casos hijo (subcasos), casos hermano relacionados, componentes, etc., al diseñar una solución. En algunas aplicaciones, un tipo de caso se identifica fácilmente, ya que representa un único proceso de negocio directo. Sin embargo, en otras situaciones, producir un diseño robusto y duradero puede requerir una consideración cuidadosa. Otras dependencias del diseño incluyen creación de reportes, seguridad, bloqueo, extensibilidad y especialización. Considere cuidadosamente todos los requerimientos presentes y futuros potenciales antes de crear el diseño, ya que esto forma la base de la aplicación.

El diseño del caso comienza con la identificación de los procesos en la aplicación. A medida que identifique los tipos de casos, considere las necesidades de especialización para estos tipos de casos. Además, considere detenidamente los futuros requerimientos de extensibilidad antes de implementar los diseños de casos. Por ejemplo, un proceso de Solicitud de compra implica identificar una lista de artículos y la cantidad de cada artículo que se comprará. La lista de elementos se revisa y luego se envía para su aprobación por uno o más aprobadores. Luego, se hace el pedido de la lista de elementos. Cuando el solicitante original finalmente recibe los elementos, el proceso está completo.

 " data-embed-button="image_browser" data-entity-embed-display="view_mode:media.embedded" data-entity-embed-display-settings="" data-entity-type="media" data-entity-uuid="7c10988d-69b2-4630-86c2-d17e87769c2b">

Puede usar varios diseños de casos para representar este proceso de negocio:

• Un único Caso de solicitud de compra para todo el proceso, con subprocesos para cada elemento.
• Un caso de Solicitud de compra para recopilar la solicitud inicial que, cuando se aprueba, genera un solo Caso de pedido de compra.
• Un caso de Solicitud de compra para reunir la solicitud inicial con caso hijo de Pedido de compra por cada artículo de línea.

La decisión sobre qué implementar depende de las Personas que harán el trabajo. Cuando se deben analizar algunos o todos los elementos de línea, tiene sentido usar el patrón de diseño Divide y vencerás. Varias personas trabajando en paralelo pueden procesar la lista LineItems más rápido que si una sola persona tuviera que mirar cada LineItem en sucesión.

Todas las soluciones proporcionadas pueden ser inicialmente viables, pero la solución óptima considera los requerimientos actuales y futuros posibles para minimizar el mantenimiento.

Algunas preguntas básicas para considerar al identificar casos:

• ¿Representa el caso los elementos que requieren procesamiento?
• ¿Hay algún beneficio en dividir el caso (proceso) en varios casos o casos hijo, o son suficientes los procesos paralelos (flujos paralelos)?
• ¿Se requiere un caso adicional o un caso hijo?
• Si se crea un caso hijo, una regla general es que el procesamiento del caso padre depende de la finalización de los casos hijo. ¿Es esto cierto?
• ¿Existen otros requerimientos actuales o futuros, como creación de reportes y seguridad, que se implementen con mayor facilidad ajustando el diseño del caso?

Considere cuidadosamente todas las preguntas. Algunas situaciones pueden no requerir casos adicionales y, en cambio, pueden resultar en un uso ineficiente de los recursos y una solución demasiado compleja. Debido a que la creación de casos implica un procesamiento adicional, siempre asegúrese de tener una buena razón para crear casos adicionales.

El ejemplo de Solicitud de compra ilustra los siguientes puntos:

• Si existen requerimientos de seguridad basados en la aprobación de tipos de elementos de línea individuales, es posible que deba implementar la solución de diseño de casos con casos hijo para elementos de línea individuales.
• Si no hay un requerimiento específico para el procesamiento de elementos de línea, la solución simple que involucra subprocesos podría adaptarse a cada elemento de línea.
• Agregar un caso de Pedido de compra puede ser innecesario a menos que haya un requerimiento que establezca explícitamente la necesidad de hacerlo (por ejemplo, requerimientos especiales de creación de reportes).

La identificación de casos puede ser sencilla, o puede haber situaciones en las que casos o procesos adicionales sean ventajosos. Por ejemplo, hay datos que pueden soportar el procesamiento de casos, como datos de cliente o cuenta. En situaciones en las que es ventajoso usar la infraestructura proporcionada por el procesamiento de casos para datos (como un proceso de aprobación, seguridad o auditoría), entonces proporcionar un caso puede ser más adecuado que actualizar los datos directamente.