KYC客户入职数据模板

事件开始时间是标记活动开始时刻的精确日期和时间。它与案例ID和活动名称共同构成流程挖掘的三项基本要素。带有时间戳的数据可以按时间顺序排列每个案例中的事件，从而还原实际发生的流程。

此属性是所有时间分析的基础。若有结束时间，可据此计算活动处理时间、活动间等待时间（交接时间）以及整个客户准入流程的总周期时间。分析这些时长有助于发现瓶颈、衡量SLA达成情况并监控整体流程绩效。

它提供事件的时间顺序，是发现流程模型和计算各项时间绩效指标的关键。

可在事件日志、申请审计跟踪或交易表中找到，字段名通常为“时间戳”“创建日期”或“开始时间”。

活动名称用于描述客户准入流程中的具体步骤或里程碑，例如“已提交申请”“已启动合规审核”或“申请已批准”。每项活动都代表用户或系统执行的一项操作，推动申请进入下一环节。

此属性是流程图可视化的基础，也是流程挖掘的核心。通过分析不同活动的顺序和频次，分析人员可以了解实际流程，识别常见路径、发现流程偏差，并找出返工或重复操作的环节。活动名称清晰且一致，才能建立有意义、易于理解的流程模型。

它定义了流程步骤，可用于展示和分析流程路径、瓶颈及差异。

可在记录业务流程步骤的事件日志、审计跟踪或交易表中找到。

客户申请ID是分配给每项新客户准入申请的唯一标识，从申请发起到完成或终止始终保持不变。它将单次准入流程中的各项活动、事件和数据点关联起来，是流程挖掘中最关键的属性。

分析时，借助此ID可以还原每位客户的端到端流程，跟踪申请进度、计算总周期时间，并与其他申请的流程路径进行比较。所有流程变体、瓶颈和绩效指标都按申请逐一分析，因此必须正确识别并使用此属性作为案例ID。

它对于将所有相关事件归入同一个端到端流程至关重要，也是所有流程挖掘分析的基础。

通常位于客户申请系统或案例管理系统的表头或主表中。

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

在流程分析中，了解数据上次更新时间有助于判断分析结果是否及时。它能让用户确认数据的时效性，从而更放心地使用数据，并避免因信息过时而产生误判。在持续监控中，还可利用此属性设置提醒，以便在数据刷新延迟或失败时及时获知，确保流程挖掘仪表板持续可靠。

它通过标明数据集的新鲜度提高数据透明度，这对确保分析结果相关且准确至关重要。

在数据提取、转换和加载（ETL）过程中生成，通常位于数据集的元数据中。

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

按源系统分析流程，有助于了解技术环境及其对流程的影响。分析可以揭示系统集成问题、系统间的数据延迟，或不同系统记录信息的差异。这有助于IT和流程改进团队优化支持客户准入流程的系统架构。

它说明每个流程步骤发生在哪个系统中，有助于发现跨系统效率问题和数据集成挑战。

通常包含在数据提取文件或事件日志中，尤其适用于集成了多个系统的环境。

事件结束时间标记活动结束的精确日期和时间。与事件开始时间配合使用，可以准确计算每项任务的处理时间。并非所有系统都会提供开始和结束时间；有些系统只提供表示完成时间的单个时间戳。

结束时间对绩效分析很有价值。它可以支持创建“平均合规审核时间”等详细指标，并区分员工实际处理任务的时间与任务在队列中等待的时间。这样的细分有助于准确识别瓶颈，并判断改进重点应放在资源容量还是流程交接上。

它可以准确计算活动处理时间，帮助区分实际工作时间和空闲等待时间。

可在事件日志或交易表中与开始时间一同找到，字段名可能为“结束时间”“完成日期”或“修改时间”。

客户类型用于将申请人划分为不同类别，例如“个人”“企业”“信托”或“非营利组织”。不同客户类型的准入要求和流程复杂度往往差异很大。

这是分析中的重要细分属性。按客户类型筛选流程图和KPI，组织可以发现显著差异。例如，企业客户准入通常涉及核实受益所有人等复杂步骤，而个人客户无需经过这些步骤。此类分析有助于针对不同客户群体优化流程变体，并制定相应的流程改进措施。

它支持按客户类型细分流程，以便比较和优化不同客户群体的准入流程。

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

用户ID用于标识在流程中负责执行某项活动的人员或系统机器人，例如合规专员、数据录入员或自动风险评分引擎。用户标识保持一致，是准确开展资源分析的关键。

此属性从人员角度呈现流程，有助于分析工作量分配、个人和团队绩效以及资源配置。按用户ID筛选流程图，管理者可以了解不同员工如何处理任务、发现培训机会并确保工作量分配均衡。它还可用于分析协作情况，揭示不同人员之间的工作交接。

它支持分析工作量、资源绩效和协作模式，从而改进资源管理和培训。

可在系统审计跟踪或交易日志中找到，通常关联到创建或最近修改记录的用户。

用户部门用于标明执行活动的用户所属职能组或团队，例如“合规”“客户准入”或“运营”。与单个用户ID相比，它提供了更高层级的组织信息。

从部门角度分析流程，对于了解跨职能协作和发现系统性瓶颈至关重要。它有助于展示不同团队之间的交接，而交接往往是延误和效率低下的主要原因。此信息有助于优化团队架构、明确职责并改善沟通渠道，让客户准入流程更加顺畅。

它支持分析不同团队之间的流程绩效和交接情况，帮助发现改善跨职能协作的机会。

通常可在与用户ID关联的用户资料数据中找到，也可能直接记录在交易中。

申请状态表示申请的最终处理结果，例如“已批准”“已拒绝”或“已撤回”。它体现了流程的业务结果，是衡量绩效的重要维度。

此属性是基于结果开展分析的关键。它可以比较最终成功与被拒绝的申请所经历的流程路径。分析人员可据此识别与高拒绝率相关的流程模式，计算“申请拒绝率”等KPI，并构建“客户准入漏斗分析”，了解申请人在哪个环节退出。了解申请失败的原因，是改进流程、提高成功率的第一步。

它定义了每个案例的业务结果，有助于分析申请被拒的原因以及提高审批通过率的方法。

通常位于案例或申请主表中，用于标明记录的最终状态。

风险等级是KYC流程的重要输出，会根据客户所属行业、所在地区和交易模式等因素对客户进行分类。此分类决定申请所需的审查和尽职调查程度。

在流程挖掘中，此属性是开展一致性检查和流程变体分析的重要维度。按设计，高风险客户的流程应比低风险客户更严格、步骤更多。将不同风险等级客户的实际流程与预期程序进行比较，组织可以检查流程是否符合内部政策和法规要求。它有助于回答“高风险客户是否都接受了强化尽职调查？”或“我们是否在低风险客户身上花费了过多时间？”等问题。

它对合规和风险管理至关重要，可用于分析不同风险等级的客户是否接受了相应的尽职调查流程。

由风险引擎计算，或由合规专员手动指定，并存储在客户或申请主记录中。

服务级别协议（SLA）目标日期是完成客户准入流程的截止日期。此日期通常依据内部政策或合同义务设定，可作为衡量流程及时性的基准。

此属性是“SLA绩效监控”仪表板的基础。将申请的实际完成日期与SLA目标日期进行比较，即可计算“SLA达成率”。分析未达到SLA的案例，有助于找出造成延误的具体活动或部门，从而主动管理工作队列和资源配置，尽量减少SLA超期并提升客户满意度。

它提供绩效基准，可用于衡量SLA达成情况并识别可能延误的案例。

通常在创建案例时，根据申请类型或其他条件计算并存储在申请主记录中。

客户ID是客户的唯一标识符，可在多次交互或申请中保持不变。客户申请ID用于跟踪单次客户准入流程，而客户ID可以关联同一客户的多次准入申请或其他流程。

此属性支持超越单个案例的客户视角分析，可用于了解重复申请人、分析客户的长期关系，或将客户准入流程与“贷款申请”“账户维护”等其他流程关联起来。虽然单流程分析并不一定需要此属性，但它能为更复杂的对象中心流程挖掘提供更多数据。

它支持以客户为中心进行分析，将同一客户的多次准入申请或相关流程关联起来。

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

客户所在国家/地区用于标明申请人的地理位置。在KYC流程中，这项信息至关重要，因为不同国家/地区的法规和风险因素可能存在显著差异。

地理分析可以提供另一层重要洞察。客户准入流程可能因各地法律要求而有所不同。按客户所在国家/地区筛选，企业可以核实是否正确遵循了相应司法管辖区的流程变体。分析还可以揭示绩效差异，例如来自高风险国家/地区的申请周期时间较长，这可能是强化尽职调查要求所致。

它支持按地理位置分析流程差异和绩效，对于确保符合当地法规至关重要。

在申请过程中向客户采集，并存储在客户或申请记录中。

当申请状态为“已拒绝”时，拒绝原因会说明具体原因，例如“材料不完整”“风险等级高”或“命中制裁名单”。此属性为未成功的流程提供了重要背景信息。

分析拒绝原因是“申请拒绝分析”仪表板的基础。企业可借此开展根因分析，了解客户准入流程中最常见的失败环节。对拒绝原因进行分类和量化后，组织便能优先呈现改进事项。例如，如果“材料不完整”是主要原因，公司可以重点优化客户指引或改进材料提交门户。

它揭示申请失败的根本原因，有助于有针对性地改进流程、降低拒绝率并改善客户体验。

通常存储在申请或案例主表中，状态设为“已拒绝”时往往会填写此字段。

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

分析此属性对于评估自动化举措的成效至关重要。比较自动化步骤与人工步骤的速度和结果，企业可以发现进一步自动化的机会，以降低成本、缩短周期时间。它还有助于监控自动化系统的绩效，确保系统在端到端流程中按预期运行。

它有助于衡量流程自动化的影响和效率，并发现进一步采用机器人或系统改进的机会。

可以是事件日志中的专用字段，也可以根据用户ID推断，例如ID为“SYSTEM”或“BOT”时。

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

按渠道分析流程，有助于评估各客户接触点的绩效和效率。分析可以回答“移动端申请是否比网页申请处理得更快？”或“网点提交的申请是否返工率更高？”等问题。这些洞察有助于优化各渠道的客户体验，并合理配置资源。

它支持比较网页、移动端或现场办理等不同提交渠道的流程效率和客户体验。

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