您的 KYC 客户入驻数据模板

事件开始时间 (Event Start Time) 是标志活动开始的精确日期和时间。它是流程挖掘的三大支柱之一（另两个是案例 ID 和活动名称）。通过此时间戳数据，可以按时间顺序排列每个案例中的事件，从而还原真实的流程流向。

此属性是所有时间维度分析的基础。它用于计算活动耗时（如有结束时间）、活动间的等待时间（交接时间）以及整个准入流程的总周期。分析这些时长有助于识别瓶颈、衡量 SLA 达成情况，并全面监测流程绩效。

提供事件的时间顺序，这对于还原流程模型和计算所有基于时间的绩效指标至关重要。

位于事件日志、申请审计线索或交易表中，通常标记为“时间戳”、“创建日期”或“开始时间”。

活动名称 (Activity Name) 描述了客户准入旅程中具体的步骤或里程碑，例如“提交申请”、“发起合规审核”或“申请已批准”。每项活动都代表用户或系统执行的特定动作，推动申请在流程中向前流转。

此属性是还原流程图的基础，也是流程挖掘的核心。通过分析不同活动的顺序和频率，分析师可以掌握实际的业务流向、识别常见路径、发现流程偏差，并精准定位返工或重复环节。活动名称的清晰度和一致性对于构建有价值、易理解的流程模型至关重要。

定义了流程步骤，支持对流程流向、瓶颈和变体进行可视化分析。

见于记录业务流程步骤的事件日志、审计线索或交易表。

客户申请 ID (Customer Application ID) 是分配给每个新客户准入请求的唯一标识，贯穿从流程发起至完成或终止的全过程。此标识是连接单个准入旅程中所有活动、事件和数据点的核心纽带，也是流程挖掘中最关键的属性。

在分析中，此 ID 能够还原每个客户的端到端全流程。它支持追踪申请进度、计算总周期，并将其路径与其他案例进行对比。所有流程变体、瓶颈和绩效指标都是基于单个申请进行分析的，而这只有在将此属性准确识别为案例 ID (Case ID) 时才能实现。

对于将所有相关事件归组为单个端到端流程至关重要，是所有流程挖掘分析的基础。

通常位于客户申请或案件管理系统的标题表或主表中。

此属性记录了最近一次数据提取或刷新的日期和时间。它不属于业务流程本身，但作为数据验证和治理的关键元数据，提供了分析数据新鲜度的透明度。

在流程分析中，了解最后一次数据更新时间对于判断洞察结果的时效性至关重要。它能让用户确认数据的当前状态，从而建立信任，并防止因过时信息产生的误读。对于持续监控而言，如果数据刷新延迟或失败，可以使用此属性设置告警，确保流程挖掘仪表板的持续可靠性。

通过显示数据集的更新频率来确保数据透明度，这对于分析的时效性和准确性至关重要。

在数据提取、转换和加载 (ETL) 过程中生成；通常可见于数据集的元数据中。

源系统属性指定了生成特定活动数据的应用程序或平台。在复杂的业务环境中，KYC 流程可能横跨多个系统，例如用于提交申请的 CRM、用于风险评估的专业 KYC 平台，以及用于创建账户的核心银行系统。

按源系统分析流程有助于了解技术架构及其对业务的影响。它可以揭示系统集成问题、系统间的数据延迟，或不同系统记录信息时的差异。对于希望优化入驻流程系统架构的 IT 和流程改进团队来说，这一视角具有极高的参考价值。

提供每个流程步骤发生位置的背景信息，有助于识别跨系统效率低下和数据集成挑战。

通常包含在数据提取或事件日志中，特别是在具有多个集成系统的环境中。

事件结束时间 (Event End Time) 记录了活动结束的精确日期和时间。与开始时间配合使用，可以精确计算每个任务的处理时长。并非所有系统都提供开始和结束时间；有些系统可能只提供代表完成的单一时间戳。

拥有结束时间对于绩效分析非常有价值。它支持区分员工处理任务的时间（处理时间）和任务在队列中的等待时间（等待时间），从而创建如“平均合规审核时间”等精细指标。这种细粒度的数据对于精准识别瓶颈并明确改进方向（是增加资源配置还是优化流程交接）至关重要。

支持精确计算活动处理时间，有助于区分实际工作时间和空闲等待时间。

可在事件日志或交易表中与开始时间并列找到。标签可能为“结束时间”、“完成日期”或“修改日期”。

客户类型 (Customer Type) 将申请人分为不同的类别，如“个人”、“企业”、“信托”或“非营利组织”。不同类型的客户往往具有截然不同的准入要求和流程复杂度。

这是分析中的核心细分属性。通过按客户类型过滤流程图和 KPI，机构可以发现显著的变异。例如，企业客户准入通常涉及核实受益所有人等复杂步骤，而个人客户则不需要。这种分析能确保每种流程变体针对其特定细分市场都达到了最高效率，并有助于制定量身定制的改进方案。

支持对流程进行细分，以便针对不同类型的客户比较并优化准入旅程。

通常在申请流程开始时捕获，并存储在主客户表或申请表中。

用户 ID 标识了负责执行流程中特定活动的个人或系统机器人，包括合规官、数据录入员或自动化风险评分引擎。统一的用户标识是进行准确资源分析的关键。

该属性提供了以“人”为中心的流程视角，对于分析工作负载分布、个人及团队绩效以及资源分配至关重要。通过按用户 ID 过滤流程图，管理人员可以了解不同员工处理任务的方式，识别培训需求，并确保工作负荷均衡。此外，它还有助于协作分析，揭示不同人员之间工作的交接情况。

支持对工作量、资源绩效和协作模式的分析，从而实现更优的资源管理和培训。

可在系统审计线索或交易日志中获取，通常关联至创建或最后修改记录的用户。

用户部门指定了执行活动的个人所属的职能组或团队，例如“合规部”、“客户入驻组”或“运营部”。与单一的用户 ID 相比，这提供了更高维度的组织上下文信息。

从部门维度分析流程对于理解跨职能协作和识别系统性瓶颈至关重要。它能直观展示不同团队之间的交接环节（这往往是延迟和低效的主要根源）。这些信息是优化团队结构、明确职责分工以及改善沟通渠道的关键，有助于创造更顺畅的入驻体验。

支持分析流程绩效和跨团队交接，发现提升跨职能协作的机会。

通常可在与用户 ID 关联的用户画像数据中找到，或直接记录在交易信息中。

申请状态 (Application Status) 指明了申请的最终结果，如“已批准”、“已拒绝”或“已撤回”。它代表了流程的业务成果，是绩效衡量的重要维度。

此属性对于基于结果的分析必不可少。它支持对比导向成功结果的路径与导致拒绝的路径。分析师可以借此识别与高拒绝率相关的流程模式，计算“申请拒绝率”等 KPI，并构建“准入漏斗分析”以查看申请人的流失环节。了解申请失败的原因是优化流程、提升成功率的第一步。

定义了每个案例的业务结果，从而支持分析申请被拒的原因以及如何提升获批率。

通常位于主案件或申请表中，指示记录的最终状态。

风险等级是 KYC 流程的核心产出，它根据行业、地域和交易模式等因素对客户进行分类。这一分类决定了申请审核的严格程度及所需的尽职调查深度。

在流程挖掘中，该属性是进行合规性与变体分析的重要维度。按照设计，高风险客户的业务流程应比低风险客户更严谨、更复杂。通过对比不同风险等级的实际流程与标准程序，企业可以检查其是否符合内部政策和监管要求，并解答如“高风险客户是否都经过了强化尽职调查？”或“我们是否在低风险客户身上耗费了过多时间？”等关键问题。

对于合规和风险管理不可或缺，支持分析尽职调查流程是否根据不同风险画像进行了适当调整。

由风险引擎计算或由合规官手动分配。存储在核心客户或申请记录中。

服务水平协议 (SLA) 目标日期是完成客户入驻流程的截止期限。该日期通常由内部政策或合同义务决定，是衡量流程及时性的基准。

该属性是“SLA 绩效监控”仪表板的数据基础。通过对比申请的实际完成日期与 SLA 目标日期，可以计算出“SLA 达成率”。通过分析未能达标的案例，能够识别导致延迟的具体活动或部门，从而实现对工作队列和资源分配的主动管理，最大限度减少 SLA 违约并提升客户满意度。

提供绩效基准，支持衡量 SLA 达成情况并识别存在延迟风险的案例。

通常在创建案例时，基于申请类型或其他标准计算并存储在主申请记录中。

客户 ID (Customer ID) 是客户的唯一标识，在多次互动或申请中保持不变。申请 ID 追踪单次准入旅程，而客户 ID 则能关联同一客户的多次尝试或其他业务流程。

此属性支持跨越单一案例的“以客户为中心”的分析。它对于理解重复申请人、分析长期客户关系，或将准入流程与“贷款申请”、“账户维护”等其他流程相关联非常有价值。虽然对于单一流程视图并非必需，但它为更复杂的、以对象为中心的流程挖掘提供了丰富的数据维度。

支持以客户为中心的视角，将同一客户的多次准入尝试或不同流程关联起来。

通常存在于中央客户主数据系统中，并关联至申请记录。

客户国家 (Customer Country) 明确了申请人的地理位置。在 KYC 流程中，这是至关重要的信息，因为法律法规和风险因素在不同国家之间可能存在巨大差异。

地域分析提供了深层的业务洞察。准入流程可能会根据特定国家的法律要求而有所不同。通过按“客户国家”进行过滤，企业可以验证这些司法区域的特定流程是否得到了正确执行。它还能揭示绩效差异，例如来自高风险国家的申请周期较长（由于强化尽职调查的要求），这有助于企业做出合理的资源预估。

支持基于地理位置分析流程变体和绩效，这对于确保遵守当地法规至关重要。

在申请过程中从客户处获取，并存储在客户或申请记录中。

当申请状态为“已拒绝”时，拒绝原因提供了具体的缘由，例如“资料不全”、“高风险特征”或“触发制裁名单”。这一属性为失败的流程提供了关键背景信息。

分析拒绝原因是“申请拒绝分析”仪表板的核心。它帮助企业进行根因分析，了解入驻流程中最常见的失败点。通过对这些原因进行分类和量化，组织可以明确改进的优先级。例如，如果“资料不全”是首要原因，公司可以重点优化客户填单指南或改进文件上传门户。

提供申请失败的根本原因，支持针对性改进以降低拒绝率并提升客户体验。

通常存储在主申请或案件表中，往往在状态设置为“已拒绝”时填充。

此布尔属性用于区分由软件或机器人执行的任务与由人工执行的任务。自动化活动可能包括初始数据验证、制裁扫描或发送标准化通知。

分析此属性对于评估自动化方案的成效至关重要。通过对比自动化步骤与人工步骤的速度和结果，企业可以发现进一步自动化的机会，从而降低成本并缩短周期。此外，它还有助于监控自动化系统的性能，确保其在端到端流程中运行正常。

有助于衡量流程中自动化的影响和效率，识别进一步实现机器人或系统化改进的机会。

可以是事件日志中的专用字段，也可以基于用户 ID 派生（例如 ID 为 'SYSTEM' 或 'BOT' 时）。

此属性标识了客户提交申请的方式，例如“网页门户”、“移动应用”或“线下网点”。不同渠道可能有不同的数据采集流程和客户体验。

按渠道分析流程有助于评估每个客户触点的绩效和效率。它可以解答如“移动端的申请处理速度是否比网页端快？”或“线下网点提交的申请返工率是否更高？”等问题。这些洞察对于优化全渠道客户旅程和有效配置资源具有重要价值。

支持对比不同提交渠道（如网页、移动端或线下）的流程效率和客户体验。

通常在流程的最开始、申请首次创建时记录。