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