您的 KYC 客户入户数据模板
您的 KYC 客户入户数据模板
- 建议收集的属性
- 需要追踪的关键活动
- 数据提取指南
KYC 客户入职属性
| 名称 | 描述 | ||
|---|---|---|---|
| 客户申请 CustomerApplication | 单个客户入户旅程的唯一标识符,作为主要的案例标识。 | ||
| 描述 “客户申请”是将单个客户 KYC 入户流程中所有相关活动和事件分组的核心标识符。它支持对申请进行端到端追踪,从初始提交到最终处理(无论是批准、拒绝还是关闭)。 在流程挖掘中,此属性是重建每个申请完整旅程的基础。它支持按申请分析流程流向、周期时间、偏差和瓶颈,从而清晰地展示各个案例的处理方式。 为何重要 这是连接所有相关事件的必备案例 ID,使得分析端到端的客户入户流程成为可能。 获取方式 这通常是 Fenergo 核心案例管理或客户生命周期管理实体中的主键。 示例 APP-2023-00123APP-2023-00124APP-2023-00125 | |||
| 开始时间 EventStartTime | 指示活动或事件正式开始的时间戳。 | ||
| 描述 此属性记录特定活动开始的准确日期和时间。它提供了重建流程流向所需的年代顺序,对于所有基于时间的分析都至关重要。 在流程挖掘中,开始时间用于计算活动时长、活动之间的等待时间以及案例的总周期时间。它构成了事件日志的时间骨架,对于绩效和瓶颈分析至关重要。 为何重要 此时间戳对于按时间顺序排列事件以及计算所有基于时间的指标(如周期时间和持续时间)至关重要。 获取方式 位于 Fenergo 的审计追踪、事件日志或 Workflow 历史表中,通常标记为 'Timestamp'、'StartDate' 或 'CreationDate'。 示例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| 活动名称 ActivityName | 在入户流程的某个时间点发生的特定业务事件或任务的名称。 | ||
| 描述 “活动名称”描述了客户入户旅程中的单个步骤或里程碑,例如“已执行初步筛选”或“申请已批准”。这些活动序列构成了流程图的基础。 分析此属性可以实现流程的可视化,识别常规路径和替代路径,并测量每个步骤的频率。这对于理解正在执行的操作及其顺序至关重要。 为何重要 此属性定义了流程中的步骤,支持创建流程图并分析流程走向和偏差。 获取方式 此信息通常存在于 Fenergo 的工作流或审计日志表中,与案例状态转换或任务完成相关联。 示例 已请求 data 和文件合规审查已启动申请已通过 | |||
| 最后数据更新 LastDataUpdate | 指示该流程数据上次刷新或抽取时间的时间戳。 | ||
| 描述 此属性记录最近一次数据刷新的日期和时间。它提供了所分析数据的时效性背景,对于理解洞察力的及时性非常重要。 在仪表板和报告中,此信息用于告知用户数据的实时程度。它有助于管理用户预期,明确分析反映的是实时运营还是历史快照。 为何重要 提供关于 Data 时效性的关键上下文,确保用户了解流程分析的最新程度。 获取方式 此值在数据提取和加载 (ETL) 过程中生成并标记在数据集上。 示例 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| 源系统 SourceSystem | 提取 data 的记录系统。 | ||
| 描述 此属性标识事件数据的来源系统。对于此流程,来源始终为 Fenergo,但在混合数据集中,它有助于区分数据源。 它在分析中的主要用途是过滤特定系统的数据或验证数据来源。在可能合并多个系统数据以获得整体流程视图的环境中,它能确保数据的清晰性。 为何重要 识别 data 的来源,这对于数据治理、验证以及确保分析基于正确的数据源至关重要。 获取方式 这通常是在数据提取过程中添加的静态值,用于标记记录的来源。 示例 FenergoFenergo CLM | |||
| SLA 目标日期 SlaTargetDate | 客户入户案例预计完成的日期。 | ||
| 描述 “SLA 目标日期”代表约定的完成整个客户申请入户流程的截止日期。它是衡量实际绩效的关键基准。 此属性对于“SLA 合规性监控”仪表板以及计算“SLA 达成率”KPI 至关重要。它能够对存在违约风险的案例进行主动管理,并帮助确定工作的优先级。 为何重要 定义目标完成日期,这对于监控 SLA 合规性以及确定逾期 case 的优先级至关重要。 获取方式 该日期通常根据申请提交日期和 Fenergo SLA 管理模块中配置的业务规则计算得出。 示例 2023-11-15T23:59:59Z2023-12-01T23:59:59Z | |||
| 发起用户 InitiatingUser | 执行该活动的人员的用户 ID 或姓名。 | ||
| 描述 此属性标识负责执行特定任务或事件的特定员工或系统用户。它可以是唯一的 ID、姓名或角色。 按用户分析有助于了解工作量分配、个人绩效并识别培训需求。它是“员工活动分布”仪表板的关键,用于深入分析特定个人或团队执行的活动。 为何重要 追踪执行操作的用户,支持对工作量分配、团队绩效和资源配置进行分析。 获取方式 此信息通常与事件详情一起存储在 Fenergo 的审计日志或任务历史表中,通常显示为“UserID”、“UserName”或“ModifiedBy”。 示例 j.doea.smith系统 | |||
| 用户部门 UserDepartment | 发起用户所属的部门或业务单位。 | ||
| 描述 此属性为执行活动的用户提供组织上下文,例如“合规部”、“入户运营部”或“销售部”。这通常源自用户个人资料信息。 此维度对于分析不同部门之间的流程交接和识别跨职能瓶颈至关重要。它通过支持在团队或部门级别汇总工作,直接为“员工活动分布”仪表板提供数据支持。 为何重要 允许按部门分析流程绩效,突出跨部门交接、延迟和工作负荷分配情况。 获取方式 这可能需要使用“发起用户”ID 从单独的用户或 HR 主数据表中关联。Fenergo 也可能将其作为用户资料的一部分进行存储。 示例 Compliance客户入职质量保证 | |||
| 申请状态 ApplicationStatus | 客户申请的当前状态或最终结果。 | ||
| 描述 此属性指示申请在流程结束时的处理结果,或当前的进行状态。常见值包括“已批准”、“已拒绝”或“进行中”。 这是结果分析的关键维度。它允许根据最终结果过滤和比较流程流向,这对于“申请返工与拒绝”仪表板以及计算“申请拒绝率”等 KPI 至关重要。 为何重要 定义 case 的结果,从而能够对比“已批准”与“已拒绝”申请的路径,并深入分析成功率。 获取方式 这通常是 Fenergo 案例管理系统中记录在案例实体上的最终状态。 示例 已批准已驳回合规待定已结案 | |||
| 结束时间 EventEndTime | 指示活动或事件完成的时间戳。 | ||
| 描述 此属性记录特定活动完成的准确日期和时间。它与开始时间相辅相成,定义了任务的实际持续时间。 在流程挖掘中,结束时间与开始时间一起用于计算每个活动的各环节处理时间。这对于识别流程中哪些步骤最耗时以及分析资源效率至关重要。 为何重要 支持计算活动处理时间,这是识别耗时较长的任务和性能瓶颈的基础。 获取方式 位于 Fenergo 的审计追踪或 Workflow 历史表中,通常标记为 'EndDate'、'CompletionDate',或从后续 event 的开始时间推断得出。 示例 2023-10-26T11:30:00Z2023-10-26T15:00:10Z2023-10-27T11:45:00Z | |||
| 风险评分 RiskScore | 代表客户计算出的风险等级的数字分值。 | ||
| 描述 “风险评分”是衡量客户潜在风险的量化指标,根据管辖区、行业和筛选结果等多种因素计算得出。Fenergo 的规则引擎通常会自动计算此分数。 此属性允许分析风险等级与流程行为之间的关联。例如,分析可以揭示高风险客户是否经历了更长的周期时间或需要更多的人工干预,这对于“风险与合规审查深度分析”仪表板非常有用。 为何重要 量化客户风险,支持分析风险等级如何影响流程时长、返工和最终结果。 获取方式 这是 Fenergo 客户风险评估模块的核心输出。它存储在案例或客户实体中。 示例 154585 | |||
| 国家/地区 Country | 客户申请所属的居住国或管辖区。 | ||
| 描述 此属性指定与客户关联的国家/地区,这通常决定了适用于入户流程的特定监管规则和风险因素。 按国家/地区分析流程可以对不同管辖区的周期时间、风险等级和流程复杂性进行比较。它有助于了解区域差异如何影响运营绩效,并确保符合当地法规。 为何重要 允许基于地理位置对流程进行细分,这对于分析监管影响和区域绩效至关重要。 获取方式 此信息是申请过程中捕获的核心客户数据的一部分,存储在 Fenergo 的客户实体中。 示例 美国GBRSGPDEU | |||
| 处理时间 ProcessingTime | 在一项活动上实际投入工作的时间长度。 | ||
| 描述 Processing Time(也称为活跃时间)是指单个活动从开始到结束 timestamp 之间的计算持续时间。它代表了资源积极参与某项任务的时间。 该指标是性能分析的基础。它被用于瓶颈分析 Dashboard 中,以精准定位哪些特定活动最耗时,从而帮助将改进工作集中在影响最大的环节。 为何重要 该计算指标测量每个活动的实际工作时间,这对于识别性能瓶颈至关重要。 获取方式 计算方式为 'EventEndTime' 与 'EventStartTime' 之差 (EndTime - StartTime)。 示例 86400000360000018000000 | |||
| 客户ID CustomerId | 正在办理入职的客户或法律实体的唯一标识符。 | ||
| 描述 “客户 ID”是主数据系统中客户实体的唯一引用。虽然申请编号是流程的案例 ID,但客户 ID 将入户活动与特定客户联系起来。 此属性允许分析单个客户的入户历史,例如,查看他们是否随时间推移经历了多次入户流程。它还可以将流程数据与其他客户相关数据关联,从而获得更全面的业务视角。 为何重要 将入职流程链接到唯一的客户实体,从而支持以客户为中心的分析和 data 丰富。 获取方式 该 ID 存储在 Fenergo 内的客户或法律实体记录中,并与入户案例相关联。 示例 CUST-98765CUST-98766CUST-98767 | |||
| 客户类型 CustomerType | 入户客户的分类,例如个人、企业或信托。 | ||
| 描述 此属性根据客户的法律结构或与金融机构的关系将客户分为不同类别。不同类型的客户通常遵循不同的入户路径,具有不同的复杂性和尽职调查要求。 按客户类型分析流程有助于识别各细分群体的绩效差异。它是“申请来源与类型效率”仪表板的关键,用于比较周期时间和批准率,从而实现针对性的流程改进。 为何重要 支持比较不同客户群体的流程绩效,因为这些群体通常具有不同的复杂程度和 SLA。 获取方式 此信息通常存储在 Fenergo 内的客户或客户实体上,并链接到申请案例。 示例 个人企业信托合伙制 | |||
| 拒绝原因 RejectionReason | 解释申请为何被拒绝的代码或描述。 | ||
| 描述 当申请的最终状态为“已拒绝”时,此属性提供具体原因。示例包括“背景调查失败”、“文件不全”或“高风险特征”。 这是对失败申请进行根本原因分析的重要属性。它通过对失败原因进行分类,直接为“申请返工与拒绝”仪表板提供支持,帮助企业识别常见问题并实施改进措施,以提高一次通过率。 为何重要 提供关于申请失败原因的关键洞察,支持进行根本原因分析以降低拒绝率。 获取方式 通常存在于 Fenergo 案例工作流中与最终拒绝状态关联的原因代码或备注字段中。 示例 制裁名单匹配无效文件违反政策客户撤回申请 | |||
| 是否已自动化 IsAutomated | 一个布尔值标志,指示该活动是由系统执行还是由人工用户执行。 | ||
| 描述 此属性区分了系统自动执行的任务(例如初步筛选、系统检查)和用户手动执行的任务。这通常通过检查执行用户是否为系统或服务账户来确定。 分析此标记对于了解流程的自动化水平至关重要。它有助于量化自动化对效率、成本和速度的影响,并识别进一步自动化的机会。 为何重要 区分人工活动和系统活动,这对于自动化分析和理解资源成本至关重要。 获取方式 这通常基于“发起用户”字段得出。系统使用已知系统用户 ID 列表将此标记设置为 true。 示例 truefalse | |||
| 是否符合SLA IsSlaCompliant | 一个布尔值标志,指示该 case 是否在 SLA 目标日期内完成。 | ||
| 描述 此属性是已完成案例 SLA 绩效的二元指标。如果最终结束活动的时间戳等于或早于“SlaTargetDate”,则设为“true”,否则为“false”。 此计算字段简化了 SLA 监控和报告。它支持轻松汇总以计算整体“SLA 达成率”KPI,并支持通过过滤来分析合规案例与非合规案例的流程特征。 为何重要 直接衡量 SLA 绩效,便于计算 SLA 达成率 KPI,并过滤出不合规的 case。 获取方式 这是通过将最终案例活动(如“申请已批准”、“申请已拒绝”)的时间戳与“SlaTargetDate”进行比较得出的。 示例 truefalse | |||
| 是否返工 IsRework | 一个布尔值标志,指示活动是否属于返工循环的一部分。 | ||
| 描述 此属性用于识别流程中代表倒退的活动,例如在“合规审查”开始后又回到“文件审查”,或出现任何“请求补充信息”的情况。 识别返工对于理解流程低效和摩擦至关重要。此标记支持直接计算“返工循环率”KPI,并有助于可视化和量化流程中浪费性、重复性步骤的影响。 为何重要 突出显示流程中低效的返工循环,有助于量化资源浪费并识别改进领域,从而提高“一次性通过”率。 获取方式 此标记使用分析活动序列的流程挖掘技术得出。例如,如果“活动 A”后跟着“活动 B”,然后同一案例再次出现“活动 A”,则第二个“活动 A”即为返工。 示例 truefalse | |||
| 案例负责人 CaseOwner | 负责在整个生命周期内管理申请的主要用户或团队。 | ||
| 描述 “案例负责人”是分派负责入户案例的主要个人或小组。此人通常对案例的及时和成功完成负责。 此属性有助于分析案例经理级别的任务量和绩效。它可以用来查看某些负责人是否具有较长的周期时间或较高的拒绝率,从而发现潜在的培训需求或资源分配不均问题。 为何重要 识别 case 的责任人或团队,支持对 case 经理进行绩效分析。 获取方式 这通常是 Fenergo 主要案例实体上的一个特定字段,指示案例分配情况。 示例 s.jonesonboarding_team_am.chen | |||
| 申请渠道 ApplicationChannel | 提交客户申请的渠道。 | ||
| 描述 此属性标识申请的提交来源,例如通过在线门户、实体网点或通过客户经理。来源会影响数据质量和处理要求。 此维度在“申请来源与类型效率”仪表板中使用,旨在比较不同渠道的绩效。它帮助企业了解哪些渠道最高效,以及哪些渠道可能需要流程优化。 为何重要 识别申请来源,支持对渠道效率、成本和客户体验进行分析。 获取方式 此信息可能在 Fenergo 的初始数据录入表单中捕获,或从上游系统传递而来。 示例 在线门户Branch客户经理移动应用 | |||
| 补充信息请求次数 AdditionalInfoRequestCount | 单个申请被要求补充信息的总次数。 | ||
| 描述 此指标计算每个案例发生“请求补充信息”活动的次数。次数越多表示来回沟通越频繁,这会延迟流程并导致糟糕的客户体验。 此属性直接支持“带补充信息请求的案例”KPI。它用于识别具有过度请求的申请,这可能指向初始数据收集问题或复杂的案例要求。分析此项有助于精简信息收集环节。 为何重要 量化因初始信息不完整导致的客户摩擦和流程延迟,助力优化数据收集环节。 获取方式 这是一个计算指标,通过计算每个“客户申请”ID 的“请求补充信息”事件次数得出。 示例 013 | |||
KYC 客户入职活动
| 活动 | 描述 | ||
|---|---|---|---|
| 合规审查已启动 | 此活动标志着合规部门开始审查,这是一个关键且通常耗时较长的阶段。当案例被分配到合规工作队列或其状态变为“待合规审查”时,即可推断出此活动。 | ||
| 为何重要 此活动是测量“平均合规审查时间”KPI 的起点。它有助于识别案例在合规团队正式处理之前等待了多长时间。 获取方式 通过捕获状态更改为“合规审查中”或将 case 分配给合规官/团队的 timestamp,从 Fenergo case 审计日志中推断。 捕获 识别状态更改为“合规审查中”或分配 event 的 timestamp。 事件类型 inferred | |||
| 合规审查已完成 | 标志着合规部门的正式签核,表示已符合所有监管要求。这可以从任务完成或状态更改为“合规已批准”中推断出来。 | ||
| 为何重要 作为一个重要的里程碑,此活动的完成对整体周期时间至关重要。它是衡量“平均合规审查时间”并识别合规职能内部瓶颈的终点。 获取方式 从 Fenergo Workflow 中“合规审查”任务的完成 timestamp 或 case 历史中的状态更新 event 中推断。 捕获 使用合规审查任务完成或状态更新的时间戳。 事件类型 inferred | |||
| 文件审核已完成 | 标志着验证所有提交客户文件真实性与准确性的人工或自动流程已完成。该事件通常根据 Fenergo 中的工作流任务完成情况或状态变化来推断。 | ||
| 为何重要 这是一个经常发生延迟的关键里程碑。分析此活动的持续时间和结果有助于精准定位文件处理中的瓶颈,并支持“一次通过率”等 KPI。 获取方式 从 case Workflow 中“文件验证”任务的完成 timestamp 或 case 历史日志中的“文件已批准”状态更新中推断。 捕获 使用文件审查任务的完成时间戳或相关的状态变更。 事件类型 inferred | |||
| 案件创建 | 此活动标志着 KYC 入户流程的启动,即在 Fenergo 中正式创建新的客户申请。这通常是一个明确的事件,在案例记录首次保存时记录特定时间戳。 | ||
| 为何重要 作为启动 event,此活动对于计算整体入职周期时间和分析吞吐量必不可少。它为后续所有流程测量和 SLA 跟踪提供了基准。 获取方式 这通常从 Fenergo 中主要案例实体的创建时间戳捕获,常存于与客户入户案例或工作流相关的表中。 捕获 使用入户案例记录的创建时间戳。 事件类型 explicit | |||
| 案件已结案 | 这是最后一项活动,表示入户案例在 Fenergo 中已从行政层面关闭,不再有后续操作。这适用于已批准和已拒绝的申请,并从最终的“已关闭”状态中推断得出。 | ||
| 为何重要 此活动是整个流程的最终终点。它确保了对所有案例(无论结果如何)的周期时间进行准确计算,并确认流程已经结束。 获取方式 通过识别 case 状态被设置为“已关闭”、“已完成”或其他终端状态时的 timestamp,从 Fenergo case 审计日志中推断。 捕获 识别最终状态更改为“已关闭”或“已完成”时的 timestamp。 事件类型 inferred | |||
| 申请已通过 | 此活动代表批准客户入户申请的最终决定。这是从案例状态更改为最终“已批准”或“入户已批准”状态中推断出来的。 | ||
| 为何重要 这一关键里程碑标志着在最终账户激活步骤之前的成功结果。它对于计算批准率和分析成功入户客户的属性至关重要。 获取方式 通过查找最终状态更改为“已批准”或类似终端正面状态的 timestamp,从 case 历史或审计日志中推断。 捕获 识别最终状态更改为“已通过”时的 timestamp。 事件类型 inferred | |||
| 申请被拒绝 | 此活动是一个终结事件,代表拒绝客户申请的最终决定。这是从案例状态更改为最终“已拒绝”或“已驳回”状态中推断出来的。 | ||
| 为何重要 作为关键的流程终点,此活动对于计算“申请拒绝率”和分析失败原因至关重要。它有助于识别常见的拒绝点并提高申请质量。 获取方式 通过捕获最终状态更改为“已拒绝”时的 timestamp,从 case 审计日志中推断。拒绝原因通常存储在相关字段中。 捕获 识别最终状态更改为“已拒绝”时的 timestamp。 事件类型 inferred | |||
| 风险评估已完成 | 代表内部风险分类流程的完成,系统会根据各种因素为客户分配风险等级。这通常根据状态变化或风险等级字段的填充情况来推断。 | ||
| 为何重要 这是一个关键的决策里程碑,通常决定随后的工作流路径。分析其持续时间有助于精简关键的合规步骤,并确保风险评估的一致性。 获取方式 通过识别 case 何时移动到“已评估风险”等状态,或何时在最终“客户风险评级”字段中填充数值,从 case 历史日志中推断。 捕获 使用风险等级字段定稿或设置相关状态时的时间戳。 事件类型 inferred | |||
| 已执行初步筛查 | 代表初步自动化或人工检查的完成,例如基础数据验证或制裁名单筛选。这通常根据 Fenergo 案例工作流中的状态变化推断,例如从“新建”变为“筛选完成”。 | ||
| 为何重要 追踪这一早期里程碑有助于识别预审阶段的初始数据质量问题和瓶颈。它将最初的自动化阶段与更密集的人工审查流程区分开来。 获取方式 通过识别 case 状态转换到表示筛查完成(如“筛查通过”或“等待文件”)的状态时的 timestamp,从 case 历史或审计日志中推断。 捕获 从 case 历史记录中识别状态更改为“筛查完成”或类似状态的时间。 事件类型 inferred | |||
| 已收到文件 | 此活动表示客户已上传或提交了所需文件,现在可以在 Fenergo 中进行审查。通常在案例状态更新为“文件已收到”或“待审查”时推断。 | ||
| 为何重要 这标志着客户等待期的结束和内部审查周期的开始。这对于测量客户响应时间和内部处理排队时间至关重要。 获取方式 从 case 审计追踪中推断,该追踪记录了状态更改为“已收到文件”或类似状态的 timestamp。它也可能与文件上传 event 相关联。 捕获 识别状态更改为“已收到文件”或“待审核”时的 timestamp。 事件类型 inferred | |||
| 已请求 data 和文件 | 该事件表示系统或入户专员已正式要求客户提供必要的信息和文件。通常在发送标准化沟通模板时,将其作为明确事件捕获。 | ||
| 为何重要 此活动标志着依赖客户阶段的开始。测量从此时点到收到文件的时间,是分析客户旅程和识别沟通延迟的关键。 获取方式 从与客户沟通相关的事件日志或“请求文件”的任务完成日志中捕获。也可以从状态更改为“等待客户信息”中推断出来。 捕获 查找记录的客户沟通 event 或任务完成情况。 事件类型 explicit | |||
| 背景调查已启动 | 此活动标志着触发外部背景、AML 或信用检查的时间点。这通常是在调用第三方服务集成时记录的明确事件。 | ||
| 为何重要 追踪这些检查的启动和完成情况,对于了解由外部依赖项引起的延迟至关重要。它有助于将内部流程时间与外部等待时间区分开来。 获取方式 通常从记录对外部筛选供应商进行 API 调用的系统日志中捕获,或者从 Fenergo 案例中创建的特定“背景调查”任务中捕获。 捕获 查找外部服务集成或创建“筛查”任务的日志。 事件类型 explicit | |||
| 请求补充信息 | 代表一个返工循环,即入户团队必须联系客户进行澄清或补交缺失材料。这是一个明确的事件,通常在向客户发送沟通信息时记录。 | ||
| 为何重要 此活动是流程低效和客户体验不佳的主要指标。追踪其发生频率有助于识别返工的根本原因,并支持“返工循环率”KPI。 获取方式 从客户沟通的事件日志或状态更改为“等待补充信息”中捕获。前者在捕获准确的请求时刻方面更为精准。 捕获 查找记录的沟通 event 或状态更改为“等待客户响应”的情况。 事件类型 explicit | |||
| 账户已激活 | 指示在批准后,客户账户已在核心银行或相关下游系统中成功创建并激活。这可以从 Fenergo 批准后的最终状态更新中推断出来。 | ||
| 为何重要 此活动确认从入户流程到激活客户状态的成功交接。通过测量从批准到激活的时间,可以发现运营设置中的延迟。 获取方式 这可以从“账户已激活”或“入户完成”等案例状态中推断出来。它也可能是通过与下游系统集成记录的明确事件。 捕获 查找批准后的状态更改或集成成功的日志 event。 事件类型 inferred | |||
提取指南
步骤
- Access the Reporting Module: 使用具有 Reporting & Analytics 模块足够权限的用户账户登录 Fenergo。导航到该模块(通常位于主菜单中)。
- Create a New Report: 开始创建新的自定义报表。选择一个能清晰标识其用途的名称和描述,例如“KYC Onboarding 事件日志 - 用于 Process Mining”。
- Define Primary Data Source: 选择捕获 case 生命周期信息的核心 data 对象或视图。这通常是预配置的视图,如
[CaseWorkflowHistory]或[LifecycleEventsView]。此对象应包含 case 标识符、event 名称或状态以及 timestamp。 - Configure Report Columns (Attributes): 使用报表构建器界面添加列。将 Fenergo data 模型中的源字段映射到所需的事件日志属性。例如,将 Fenergo 的
CaseID映射到CustomerApplication,将EventTimestamp映射到EventStartTime,将EventPerformer映射到InitiatingUser。 - Build Activity Logic: 这是最关键的一步。必须配置报表,为 14 个必需的活动中的每一个生成单独的一行。这可以通过为每个活动创建逻辑块或过滤数据集,并在报表构建器中使用 UNION 或等效函数进行合并来实现。
- Define 'Case Created' Logic: 创建第一个逻辑块。过滤初始 case 创建 event 的数据源。这通常基于与 case 关联的最早 timestamp 或名为“Case Created”的 event 类型。将
CreationDate映射到EventStartTime。 - Define Status-Based Activity Logic: 对于从状态更改推断出的活动(例如“已收到文件”、“申请已批准”),请创建单独的逻辑块。根据特定的
Status字段值过滤数据源,并将StatusChangeDate用作EventStartTime。 - Define Task-Based Activity Logic: 对于与 Workflow 任务相关的活动(例如“合规审查已完成”),创建过滤
TaskName和TaskCompletionDate的逻辑块。将完成日期用作EventStartTime。 - Set Global Report Filters: 应用报表级过滤器来限定数据范围。为
EventStartTime设置特定的“日期范围”,以避免导出文件过大。建议先提取 3 到 6 个月的数据。过滤特定的 case 类型,例如“KYC 客户入职”。 - Run and Preview the Report: 在 Fenergo UI 中执行报表。预览前 100-200 行,以确保 data 结构正确,所有列均按预期填充,并且包含不同的活动。
- Export the Data: 将完整的报表结果导出为 CSV 或 Excel 文件。这就是原始事件日志文件。
- Final Data Preparation: 打开导出的 CSV 文件。如果报表无法直接生成
SourceSystem和LastDataUpdate列,请手动添加。将所有行的SourceSystem设置为“Fenergo”,并将导出 timestamp 设置为LastDataUpdate。
配置
- Prerequisites: 用户需要拥有 Fenergo Reporting & Analytics 模块的访问权限,以及创建和运行自定义报表的权限。
- Core Data Sources: 报表应主要基于 Fenergo 的 case 管理和 Workflow 历史对象构建。常见的数据源包括
[CaseDetails]、[CaseStatusHistory]和[WorkflowTaskHistory]。具体名称可能因您的 Fenergo 配置而异。 - Date Range: 在 event timestamp 上设置日期范围过滤器对于管理性能至关重要。建议先从最近 3 到 6 个月的数据开始。如需进行历史分析,请分批运行报表(例如按季度或按年)。
- Key Filters: 务必按特定的流程或 case 类型(如“KYC 客户入职”)进行过滤,以排除无关 data。您可能还需要根据分析目标按法律实体类型或管辖区进行过滤。
- Activity Definition: 每个活动必须使用针对“状态”、
TaskName或专用EventType字段的特定过滤条件进行定义。依靠这些字段是隔离流程中每个唯一 event 的关键。 - Performance Considerations: 联合多个数据源或扫描大范围日期范围的报表运行速度可能较慢。如果可能,请将报表安排在非高峰时段运行。导出时避免包含不必要的列,以免增加处理时间。
a 查询示例 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]'