Su Template de Datos para el Onboarding de Clientes KYC
Su Template de Datos para el Onboarding de Clientes KYC
- Atributos recomendados para recopilar
- Actividades clave para el seguimiento
- Guía para la extracción de `datos`
Atributos del Onboarding de Clientes KYC
| Nombre | Descripción | ||
|---|---|---|---|
| Hora de Inicio EventStartTime | La `timestamp` que indica cuándo una actividad o `evento` comenzó oficialmente. | ||
| Descripción Este En Por qué es importante Esta Dónde obtener Ubicado en el registro de auditoría, registro de eventos o tablas de historial de flujo de trabajo de Fenergo, a menudo etiquetado como 'Timestamp', 'StartDate' o 'CreationDate'. Ejemplos 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| Nombre de la Actividad ActivityName | El nombre del `evento` de negocio o tarea específica que ocurrió en un punto en el tiempo dentro del proceso de `onboarding`. | ||
| Descripción El Nombre de Actividad describe un solo paso o hito en la trayectoria de El análisis de este Por qué es importante Este Dónde obtener Esta información se encuentra típicamente en las tablas de Ejemplos Datos y Documentos SolicitadosRevisión de Cumplimiento IniciadaSolicitud Aprobada | |||
| Solicitud del Cliente CustomerApplication | El identificador único para el recorrido de `onboarding` de un solo cliente, sirviendo como identificador principal del `case`. | ||
| Descripción La Solicitud del Cliente es el identificador central que agrupa todas las actividades y En Por qué es importante Este es el ID de Dónde obtener Esta es típicamente la clave primaria en la entidad central de gestión de Ejemplos APP-2023-00123APP-2023-00124APP-2023-00125 | |||
| Source System SourceSystem | El sistema de registro del que se extrajeron los `datos`. | ||
| Descripción Este Su uso principal en el análisis es filtrar Por qué es importante Identifica el origen de los datos, lo cual es crucial para la gobernanza de datos, la validación y para asegurar que el análisis se base en la fuente correcta. Dónde obtener Este es típicamente un valor estático agregado durante el proceso de extracción de datos para etiquetar el origen de los registros. Ejemplos FenergoFenergo CLM | |||
| Última actualización de datos LastDataUpdate | El `timestamp` que indica la última vez que los `datos` para este proceso se actualizaron o extrajeron. | ||
| Descripción Este En Por qué es importante Proporciona un contexto crucial sobre la actualidad de los datos, asegurando que los usuarios comprendan cuán actual es el análisis del proceso. Dónde obtener Este valor se genera y se estampa en el conjunto de Ejemplos 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| Departamento del Usuario UserDepartment | El departamento o la unidad de negocio a la que pertenece el usuario que inicia. | ||
| Descripción Este Esta dimensión es crucial para analizar los traspasos de procesos entre diferentes departamentos e identificar Por qué es importante Permite el análisis del rendimiento del proceso por departamento, destacando los traspasos interdepartamentales, los retrasos y la distribución de la carga de trabajo. Dónde obtener Esto puede necesitar unirse desde una tabla separada de usuarios o Ejemplos ComplianceOnboarding de ClientesGarantía de Calidad | |||
| Estado de la Solicitud ApplicationStatus | El resultado actual o final de la solicitud del cliente. | ||
| Descripción Este Esta es una dimensión crítica para el análisis de resultados. Permite filtrar y comparar los flujos de proceso basándose en su resultado final, lo cual es esencial para el Por qué es importante Define el resultado de un caso, lo que permite un análisis potente para comparar las rutas de solicitudes aprobadas versus rechazadas y comprender las tasas de éxito. Dónde obtener Este es típicamente el estado final registrado en la entidad del Ejemplos AprobadoRechazadaCumplimiento PendienteCerrado | |||
| Fecha Objetivo de SLA SlaTargetDate | La fecha para la cual se espera que el `case` de `onboarding` del cliente esté completado. | ||
| Descripción La Fecha Objetivo de SLA representa la fecha límite acordada para completar todo el proceso de Este Por qué es importante Define la fecha de finalización objetivo, crucial para monitorear el cumplimiento de ANS y priorizar casos vencidos. Dónde obtener Esta fecha a menudo se calcula basándose en la fecha de presentación de la solicitud y las reglas de negocio configuradas dentro del módulo de gestión de SLA de Fenergo. Ejemplos 2023-11-15T23:59:59Z2023-12-01T23:59:59Z | |||
| Hora de Finalización EventEndTime | La marca de tiempo que indica cuándo se completó una actividad o evento. | ||
| Descripción Este En Por qué es importante Permite el cálculo de los tiempos de procesamiento de actividades, fundamental para identificar tareas de larga duración y cuellos de botella de rendimiento. Dónde obtener Ubicado en el registro de auditoría o en las tablas de historial de flujo de trabajo de Fenergo, a menudo etiquetado como 'EndDate', 'CompletionDate', o derivado del tiempo de inicio del evento subsiguiente. Ejemplos 2023-10-26T11:30:00Z2023-10-26T15:00:10Z2023-10-27T11:45:00Z | |||
| Puntuación de Riesgo RiskScore | Una puntuación numérica que representa el nivel de riesgo calculado del cliente. | ||
| Descripción La Puntuación de Riesgo ( Este Por qué es importante Cuantifica el riesgo del cliente, permitiendo el análisis de cómo los niveles de riesgo impactan la duración del proceso, el Dónde obtener Este es un resultado clave del módulo de Evaluación de Riesgos del Cliente de Fenergo. Se almacena en el Ejemplos 154585 | |||
| Usuario Iniciador InitiatingUser | El ID de usuario o el nombre de la persona que realizó la actividad. | ||
| Descripción Este Analizar por usuario ayuda a comprender la distribución de la carga de trabajo, el rendimiento individual y la identificación de necesidades de capacitación. Es clave para el Por qué es importante Rastrea qué usuario realizó una acción, permitiendo el análisis de la distribución de la carga de trabajo, el rendimiento del equipo y la asignación de recursos. Dónde obtener Esta información se almacena típicamente en los Ejemplos j.doea.smithSYSTEM | |||
| ¿Es Retrabajo? IsRework | Un indicador booleano que señala si una actividad forma parte de un ciclo de reelaboración. | ||
| Descripción Este Identificar el Por qué es importante Destaca los ciclos de reelaboración ineficientes en el proceso, ayudando a cuantificar el desperdicio e identificar áreas de mejora para aumentar las tasas de acierto a la primera. Dónde obtener Este indicador se deriva utilizando técnicas de Ejemplos truefalse | |||
| Automatizado IsAutomated | Un indicador booleano que señala si la actividad fue realizada por un sistema en lugar de un usuario humano. | ||
| Descripción Este Analizar este indicador es crucial para comprender el nivel de automatización en el proceso. Ayuda a cuantificar el impacto de la automatización en la eficiencia, el costo y la velocidad, e identifica oportunidades para una mayor automatización. Por qué es importante Distingue entre actividades humanas y del sistema, lo cual es vital para el análisis de automatización y la comprensión de los costos de los recursos. Dónde obtener Esto se deriva típicamente del campo 'InitiatingUser'. Se utiliza una lista de IDs de usuario de sistema conocidos para establecer este indicador en verdadero. Ejemplos truefalse | |||
| Canal de Solicitud ApplicationChannel | El canal a través del cual se presentó la solicitud del cliente. | ||
| Descripción Este Esta dimensión se utiliza en el Por qué es importante Identifica el origen de las solicitudes, permitiendo el análisis de la eficiencia del canal, el costo y la experiencia del cliente. Dónde obtener Esta información podría ser capturada en un formulario inicial de entrada de Ejemplos Portal en LíneaSucursalGestor de RelacionesApp móvil | |||
| Cumple con el SLA IsSlaCompliant | Un indicador booleano que señala si el caso se completó dentro de su fecha objetivo de ANS. | ||
| Descripción Este Este campo calculado simplifica el monitoreo y la elaboración de informes de SLA. Permite una fácil agregación para calcular el KPI general de 'Tasa de Adhesión a SLA' y para filtrar y analizar las características del proceso de los Por qué es importante Mide directamente el rendimiento del ANS, permitiendo un cálculo fácil de la Tasa de Adhesión al ANS KPI y el filtrado de casos no conformes. Dónde obtener Esto se deriva al comparar la Ejemplos truefalse | |||
| ID de cliente CustomerId | Un identificador único para el cliente o la entidad legal en proceso de incorporación. | ||
| Descripción El ID de Cliente es la referencia única para la entidad de cliente en el sistema de Este Por qué es importante Vincula el proceso de onboarding a una entidad de cliente única, permitiendo un análisis centrado en el cliente y el enriquecimiento de datos. Dónde obtener Este ID se almacena en el registro del cliente o entidad legal dentro de Fenergo y se asocia con el Ejemplos CUST-98765CUST-98766CUST-98767 | |||
| Motivo de rechazo RejectionReason | Un código o descripción que explica por qué se rechazó una solicitud. | ||
| Descripción Cuando el estado final de una solicitud es 'Rechazado', este Este es un Por qué es importante Proporciona una visión crítica de por qué fallan las solicitudes, lo que permite un análisis de causa raíz para reducir las tasas de rechazo. Dónde obtener Típicamente encontrado en un campo de código de razón o notas asociado con el estado final de rechazo en el Ejemplos Coincidencia en Listas de SancionesDocumentos InválidosViolación de PolíticaCliente Retirado | |||
| Número de Solicitudes de Info Adicional AdditionalInfoRequestCount | El número total de veces que se solicitó información adicional para una solicitud. | ||
| Descripción Esta métrica cuenta las ocurrencias de la actividad 'Información Adicional Solicitada' para cada Este Por qué es importante Cuantifica la fricción del cliente y los retrasos del proceso causados por información inicial incompleta, ayudando a mejorar el paso de recopilación de Dónde obtener Esta es una métrica calculada, derivada al contar el número de Ejemplos 013 | |||
| País Country | El país de domicilio o jurisdicción para la solicitud del cliente. | ||
| Descripción Este Analizar el proceso por país permite comparaciones jurisdiccionales del tiempo de ciclo, los niveles de riesgo y la complejidad del proceso. Ayuda a comprender cómo las diferencias regionales impactan el rendimiento operativo y a asegurar el cumplimiento con las regulaciones locales. Por qué es importante Permite la segmentación del proceso por geografía, clave para analizar el impacto regulatorio y el rendimiento regional. Dónde obtener Esta información forma parte de los Ejemplos EE. UU.GBRSGPDEU | |||
| Propietario del caso CaseOwner | El usuario o equipo principal responsable de gestionar la solicitud a lo largo de su ciclo de vida. | ||
| Descripción El Propietario del Este Por qué es importante Identifica a la persona o equipo responsable de un caso, permitiendo el análisis del rendimiento de los gestores de casos. Dónde obtener Este suele ser un campo específico en la entidad de Ejemplos s.jonesonboarding_team_am.chen | |||
| Tiempo de Procesamiento ProcessingTime | La duración del tiempo dedicado activamente a una actividad. | ||
| Descripción El tiempo de procesamiento, también conocido como tiempo activo, es la duración calculada entre la marca de tiempo de inicio y fin de una sola actividad. Representa el tiempo que un recurso estuvo activamente involucrado en una tarea. Esta métrica es fundamental para el análisis de rendimiento. Se utiliza en dashboards de análisis de cuellos de botella para identificar qué actividades específicas son las que consumen más tiempo, ayudando a enfocar los esfuerzos de mejora donde tendrán el mayor impacto. Por qué es importante Esta métrica calculada mide el tiempo de trabajo activo para cada actividad, lo cual es crucial para identificar Dónde obtener Calculado como la diferencia entre 'EventEndTime' y 'EventStartTime' (EndTime - StartTime). Ejemplos 86400000360000018000000 | |||
| Tipo de Cliente CustomerType | La clasificación del cliente en proceso de `onboarding`, como Individual, Corporativo o Fideicomiso. | ||
| Descripción Este Analizar el proceso por Tipo de Cliente ayuda a identificar diferencias de rendimiento entre segmentos. Es clave para el Por qué es importante Permite la comparación del rendimiento del proceso entre diferentes segmentos de clientes, que a menudo tienen complejidades y ANS variables. Dónde obtener Esta información se almacena típicamente en la entidad del cliente dentro de Fenergo y se vincula al Ejemplos IndividualCorporativoFideicomisoAsociación | |||
Actividades del Onboarding de Clientes KYC
| Actividad | Descripción | ||
|---|---|---|---|
| Caso cerrado | Esta es la actividad final, que significa que el `case` de `onboarding` está administrativamente cerrado en Fenergo, sin esperarse más acciones. Esto se aplica tanto a solicitudes aprobadas como rechazadas y se infiere de un estado final de 'Cerrado'. | ||
| Por qué es importante Esta actividad sirve como el punto final definitivo para todo el proceso. Asegura cálculos precisos del tiempo de ciclo para todos los Dónde obtener Inferido del registro de auditoría de casos de Fenergo al identificar la marca de tiempo cuando el estado del caso se establece como 'Cerrado', 'Completado' u otro estado final. Capturar Identifique la marca de tiempo del cambio de estado final a 'Cerrado' o 'Completado'. Tipo de evento inferred | |||
| Caso creado | Esta actividad marca el inicio del proceso de `onboarding` KYC cuando una nueva solicitud de cliente se crea formalmente en Fenergo. Es típicamente un `evento` explícito registrado con una `timestamp` específica cuando el registro del `case` se guarda por primera vez. | ||
| Por qué es importante Como evento de inicio, esta actividad es esencial para calcular el tiempo de ciclo general del onboarding y analizar el rendimiento. Proporciona la base para todas las mediciones de procesos y el seguimiento de ANS posteriores. Dónde obtener Esto se captura típicamente de la Capturar Utilice la Tipo de evento explicit | |||
| Evaluación de Riesgos Completada | Representa la finalización del proceso interno de clasificación de riesgo, donde al cliente se le asigna una calificación de riesgo basada en varios factores. Esto se infiere de un cambio de estado o de la cumplimentación de un campo de calificación de riesgo. | ||
| Por qué es importante Este es un hito clave en la toma de decisiones que a menudo determina la ruta del Dónde obtener Inferido del registro del historial del caso al identificar cuándo el caso pasa a un estado como 'Riesgo Evaluado' o cuando el campo final 'Customer Risk Rating' se rellena con un valor. Capturar Utilice la Tipo de evento inferred | |||
| Revisión de Cumplimiento Completada | Marca la aprobación formal por parte del departamento de cumplimiento, indicando que se han cumplido todos los requisitos regulatorios. Esto se infiere de la finalización de una tarea o un cambio de estado a 'Cumplimiento Aprobado'. | ||
| Por qué es importante Como un hito importante, la finalización de esta actividad es crítica para el tiempo de ciclo general. Es el punto final para medir el 'Tiempo Promedio de Revisión de Cumplimiento' e identificar cuellos de botella dentro de la función de cumplimiento. Dónde obtener Inferido de la marca de tiempo de finalización de la tarea 'Revisión de Cumplimiento' dentro del flujo de trabajo de Fenergo o del evento de actualización de estado en el historial del caso. Capturar Utilice la Tipo de evento inferred | |||
| Revisión de Cumplimiento Iniciada | Esta actividad marca el inicio de la revisión por parte del departamento de cumplimiento, una etapa crítica y a menudo prolongada. Se infiere cuando el `case` se asigna a la cola de trabajo de cumplimiento o su estado cambia a 'Revisión de Cumplimiento Pendiente'. | ||
| Por qué es importante Esta actividad es el punto de partida para medir el KPI 'Tiempo Promedio de Revisión de Cumplimiento'. Ayuda a identificar cuánto tiempo esperan los Dónde obtener Inferido del registro de auditoría de casos de Fenergo al capturar la marca de tiempo del cambio de estado a 'En Revisión de Cumplimiento' o la asignación del caso a un oficial o equipo de cumplimiento. Capturar Identifique la marca de tiempo del cambio de estado a 'En Revisión de Cumplimiento' o evento de asignación. Tipo de evento inferred | |||
| Revisión de Documentos Completada | Significa la finalización del proceso manual o automático de verificación de la autenticidad y corrección de todos los `documentos` del cliente presentados. Este `evento` se infiere usualmente de la finalización de una tarea de `workflow` o de un cambio de estado en Fenergo. | ||
| Por qué es importante Este es un hito crítico donde ocurren muchos retrasos. Analizar la duración y los resultados de esta actividad ayuda a identificar Dónde obtener Inferido de la marca de tiempo de finalización de la tarea 'Verificación de Documentos' en el flujo de trabajo del caso o de una actualización de estado a 'Documentos Aprobados' en el registro del historial del caso. Capturar Utilice la Tipo de evento inferred | |||
| Solicitud Aprobada | Esta actividad representa la decisión final de aprobar la solicitud del cliente para el `onboarding`. Se infiere del cambio de estado del `case` a un estado final de 'Aprobado' o '`Onboarding` Aprobado'. | ||
| Por qué es importante Este hito clave significa un resultado exitoso antes de los pasos finales de activación de la cuenta. Es esencial para calcular las tasas de aprobación y analizar las propiedades de los clientes con Dónde obtener Inferido del historial del caso o registro de auditoría al encontrar la marca de tiempo del cambio de estado final a 'Aprobado' o un estado positivo terminal similar. Capturar Identifique la marca de tiempo del cambio de estado final a 'Aprobado'. Tipo de evento inferred | |||
| Solicitud Rechazada | Esta actividad es un `evento` terminal que representa la decisión final de rechazar la solicitud del cliente. Se infiere del cambio de estado del `case` a un estado final de 'Rechazado' o 'Denegado'. | ||
| Por qué es importante Como punto final clave del proceso, esta actividad es vital para calcular la 'Tasa de Rechazo de Solicitudes' y analizar las razones del fracaso. Ayuda a identificar puntos comunes de rechazo y a mejorar la calidad de las solicitudes. Dónde obtener Inferido del registro de auditoría del caso al capturar la marca de tiempo cuando el estado final cambia a 'Rechazado'. La razón del rechazo a menudo se almacena en un campo relacionado. Capturar Identifique la marca de tiempo del cambio de estado final a 'Rechazado'. Tipo de evento inferred | |||
| Cuenta Activada | Indica que la cuenta del cliente ha sido creada y activada exitosamente en el sistema bancario central o en el sistema posterior relevante después de la aprobación. Esto puede inferirse de una actualización de estado final en Fenergo post-aprobación. | ||
| Por qué es importante Esta actividad confirma el traspaso exitoso del proceso de Dónde obtener Esto se puede inferir de un estado de Capturar Busque un cambio de estado posterior a la aprobación o un evento de registro de éxito de la integración. Tipo de evento inferred | |||
| Datos y Documentos Solicitados | Este `evento` significa que el sistema o un agente de `onboarding` ha solicitado formalmente información y documentación necesarias al cliente. A menudo se captura como un `evento` explícito cuando se envía una `template` de comunicación estandarizada. | ||
| Por qué es importante Esta actividad marca el inicio de una fase dependiente del cliente. Medir el tiempo desde este punto hasta que se reciben los Dónde obtener Capturado de un registro de eventos asociado a las comunicaciones con el cliente o de un registro de finalización de tareas para 'Solicitar Documentos'. También puede inferirse de un cambio de estado a 'Esperando Información del Cliente'. Capturar Busque un evento registrado de comunicación con el cliente o la finalización de una tarea. Tipo de evento explicit | |||
| Documentos Recibidos | Esta actividad indica que el cliente ha cargado o enviado los `documentos` requeridos, los cuales ahora están disponibles en Fenergo para su revisión. Esto típicamente se infiere cuando el estado del `case` se actualiza a 'Documentos Recibidos' o 'Revisión Pendiente'. | ||
| Por qué es importante Esto marca el final del período de espera del cliente y el comienzo del ciclo de revisión interna. Es crucial para medir los tiempos de respuesta del cliente y los tiempos de cola de procesamiento interno. Dónde obtener Inferido del registro de auditoría del caso, que registra la marca de tiempo de un cambio de estado a 'Documentos Recibidos' o un estado similar. También puede estar vinculado a eventos de carga de documentos. Capturar Identifique la marca de tiempo del cambio de estado a 'Documentos Recibidos' o 'Listo para Revisión'. Tipo de evento inferred | |||
| Información Adicional Solicitada | Representa un bucle de `rework` donde el equipo de `onboarding` debe volver al cliente para solicitar aclaraciones o `documentos` faltantes. Este es un `evento` explícito, típicamente registrado cuando se envía una comunicación al cliente. | ||
| Por qué es importante Esta actividad es un indicador principal de ineficiencia del proceso y de una mala experiencia del cliente. El seguimiento de su frecuencia ayuda a identificar las causas raíz del Dónde obtener Capturado de un registro de eventos de comunicaciones con el cliente o de un cambio de estado a 'Esperando Información Adicional'. El primero es más preciso para capturar el momento exacto de la solicitud. Capturar Busque eventos de comunicación registrados o un cambio de estado a 'Pendiente de Respuesta del Cliente'. Tipo de evento explicit | |||
| Revisión Preliminar Realizada | Representa la finalización de las verificaciones preliminares automáticas o manuales, como la validación básica de `datos` o el cribado de listas de sanciones. Esto a menudo se infiere de un cambio de estado dentro del `workflow` del caso de Fenergo, por ejemplo, pasando de 'Nuevo' a 'Cribado Completado'. | ||
| Por qué es importante El seguimiento de este hito temprano ayuda a identificar problemas iniciales de calidad de Dónde obtener Inferido del historial del caso o registro de auditoría al identificar la marca de tiempo cuando el estado del caso transiciona a un estado que indica que la revisión preliminar está completa, como 'Revisión Preliminar Aprobada' o 'Esperando Documentos'. Capturar Identifique el cambio de estado a 'Revisión Preliminar Completada' o similar del historial del caso. Tipo de evento inferred | |||
| Verificaciones de Antecedentes Iniciadas | Esta actividad marca el punto en el que se activan las verificaciones externas de antecedentes, AML o crédito. A menudo es un `evento` explícito registrado cuando se llama a una integración con un servicio de terceros. | ||
| Por qué es importante El seguimiento de la iniciación y finalización de estas verificaciones es vital para comprender los retrasos causados por dependencias externas. Ayuda a aislar el tiempo de proceso interno del tiempo de espera externo. Dónde obtener Típicamente capturado de los Capturar Busque registros de integraciones de servicios externos o la creación de una tarea de 'Revisión Preliminar'. Tipo de evento explicit | |||
Guías de Extracción
Pasos
- Acceda al módulo de informes: Inicie sesión en la aplicación Fenergo con una cuenta de usuario que tenga permisos suficientes para el módulo de Reporting & Analytics. Navegue hasta el módulo, que suele encontrarse en el menú principal.
- Cree un nuevo informe: Inicie la creación de un nuevo informe personalizado. Seleccione un nombre y una descripción que identifiquen claramente su propósito, por ejemplo, "Registro de eventos de incorporación KYC para Process Mining".
- Defina la fuente de datos principal: Seleccione el objeto de datos o la vista principal que captura la información del ciclo de vida del case. Suele ser una vista preconfigurada como
[CaseWorkflowHistory]o[LifecycleEventsView]. Este objeto debe contener identificadores de case, nombres de evento o estados y timestamps. - Configure las columnas del informe (Atributos): Utilice la interfaz del generador de informes para añadir columnas. Vincule los campos de origen del modelo de datos de Fenergo con los atributos del registro de eventos necesarios. Por ejemplo, mapee
CaseIDde Fenergo comoCustomerApplication,EventTimestampcomoEventStartTimeyEventPerformercomoInitiatingUser. - Construya la lógica de las actividades: Este es el paso más crítico. El informe debe configurarse para generar una fila independiente para cada una de las 14 actividades requeridas. Esto se logra creando bloques lógicos o conjuntos de datos filtrados para cada actividad y combinándolos mediante una función UNION o equivalente dentro del generador de informes.
- Defina la lógica de 'Case Created': Cree el primer bloque. Filtre la fuente de datos para el evento inicial de creación del case. A menudo se basa en el timestamp más antiguo asociado al case o en un tipo de evento llamado 'Case Created'. Mapee la
CreationDateaEventStartTime. - Defina la lógica de actividad basada en el estado: Para las actividades deducidas de cambios de estado (por ejemplo, "Documentos recibidos", "Solicitud aprobada"), cree bloques separados. Filtre la fuente de datos por el valor del campo
Statusespecífico y utilice laStatusChangeDatecomoEventStartTime. - Defina la lógica de actividad basada en tareas: Para las actividades vinculadas a tareas de workflow (por ejemplo, "Revisión de cumplimiento completada"), cree bloques que filtren por
TaskNameyTaskCompletionDate. Use la fecha de finalización comoEventStartTime. - Establezca filtros globales del informe: Aplique filtros a nivel de informe para acotar los datos. Establezca un
Date Rangeespecífico para elEventStartTimepara evitar exportaciones excesivamente grandes. Se recomienda un periodo de 3 a 6 meses para el análisis inicial. Filtre por el tipo de case específico, como "Incorporación de clientes KYC". - Ejecute y previsualice el informe: Ejecute el informe dentro de la interfaz de Fenergo. Previsualice las primeras 100-200 filas para asegurarse de que la estructura de los datos es correcta, todas las columnas están completas y aparecen las diferentes actividades.
- Exporte los datos: Exporte los resultados completos del informe a un archivo CSV o Excel. Este será su archivo de registro de eventos sin procesar.
- Preparación final de los datos: Abra el archivo CSV exportado. Si las columnas
SourceSystemyLastDataUpdateno se pudieron generar directamente en el informe, añádalas manualmente. Indique "Fenergo" comoSourceSystemen todas las filas y la fecha de exportación comoLastDataUpdate.
Configuración
- Requisitos previos: El usuario debe tener acceso al módulo de Reporting & Analytics de Fenergo con permisos para crear y ejecutar informes personalizados.
- Fuentes de datos principales: El informe debe basarse principalmente en los objetos de gestión de cases e historial de workflow de Fenergo. Las fuentes comunes incluyen
[CaseDetails],[CaseStatusHistory]y[WorkflowTaskHistory]. Los nombres exactos pueden variar según su configuración de Fenergo. - Date Range: Es fundamental establecer un filtro de rango de fechas en el timestamp del evento para gestionar el rendimiento. Comience con un periodo reciente de 3 a 6 meses. Para análisis históricos, ejecute el informe por lotes (por ejemplo, trimestral o anualmente).
- Filtros clave: Filtre siempre por el proceso o tipo de case específico, como "Incorporación de clientes KYC", para excluir datos irrelevantes. También es posible que deba filtrar por tipo de entidad legal o jurisdicción, dependiendo de sus objetivos de análisis.
- Definición de actividad: Cada actividad debe definirse utilizando criterios de filtrado específicos en campos como
Status,TaskNameo un campo dedicadoEventType. Confiar en estos campos es clave para aislar cada evento único en el proceso. - Consideraciones de rendimiento: Los informes que combinan muchas fuentes de datos o analizan un rango de fechas amplio pueden ser lentos. Si es posible, programe la ejecución del informe fuera de las horas punta. Evite incluir columnas innecesarias en la exportación para reducir el tiempo de procesamiento.
a Consulta de ejemplo config
/*
This is a logical representation of the configuration needed in the Fenergo Reporting & Analytics module.
The module uses a graphical interface, but this query structure illustrates the required data sources, filters, and unions.
Fields like [CaseLifecycleData].[CaseID] are placeholders for actual Fenergo fields selected in the UI.
*/
-- Base data selection for common attributes
WITH CaseAttributes AS (
SELECT
C.CaseID AS CustomerApplication,
C.SlaTargetDate AS SlaTargetDate,
C.FinalRiskScore AS RiskScore,
C.CurrentStatus AS ApplicationStatus
FROM [CaseDetails] C
WHERE C.CaseType = 'KYC Customer Onboarding'
)
-- 1. Case Created
SELECT
A.CustomerApplication,
'Case Created' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
L.CompletionTimestamp AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CASE_CREATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 2. Initial Screening Performed
SELECT
A.CustomerApplication,
'Initial Screening Performed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Initial Screening' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 3. Data & Documents Requested
SELECT
A.CustomerApplication,
'Data & Documents Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Initial Document Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 4. Documents Received
SELECT
A.CustomerApplication,
'Documents Received' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 5. Document Review Completed
SELECT
A.CustomerApplication,
'Document Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Document Verification' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 6. Background Checks Initiated
SELECT
A.CustomerApplication,
'Background Checks Initiated' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'EXTERNAL_CHECK_INITIATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 7. Risk Assessment Completed
SELECT
A.CustomerApplication,
'Risk Assessment Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Risk Assessment' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 8. Compliance Review Initiated
SELECT
A.CustomerApplication,
'Compliance Review Initiated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Compliance Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 9. Additional Information Requested
SELECT
A.CustomerApplication,
'Additional Information Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Additional Information Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 10. Compliance Review Completed
SELECT
A.CustomerApplication,
'Compliance Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Compliance Review' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 11. Application Approved
SELECT
A.CustomerApplication,
'Application Approved' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Approved'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 12. Application Rejected
SELECT
A.CustomerApplication,
'Application Rejected' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Rejected'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 13. Account Activated
SELECT
A.CustomerApplication,
'Account Activated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Active'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 14. Case Closed
SELECT
A.CustomerApplication,
'Case Closed' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Closed'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'