您的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遵循情况，并识别存在延迟风险的案件。

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

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

此属性支持超越单个案例的客户视角分析。它可用于了解重复申请者、分析客户的长期关系，或将入驻流程与“Loan Application”“Account Maintenance”等其他流程关联起来。对于单流程视图而言，它并非必需，但能为更复杂的对象中心流程挖掘提供更丰富的数据。

支持以客户为中心查看数据，将同一客户的多次入驻尝试或相关不同流程关联起来。

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

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

地理分析可以提供另一层重要洞察。开户流程可能因各国家/地区的法律要求而不同。按客户所在国家/地区筛选，公司可以验证是否正确执行了这些司法管辖区差异化流程。该分析还可以揭示性能差异，例如来自高风险国家/地区的申请周期时间更长，这可能是强化尽职调查要求所导致的预期结果。

它支持按地理位置分析流程变体和性能，对于确保符合当地法规至关重要。

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

当申请状态为“已拒绝”时，拒绝原因会说明具体原因，例如“文档不完整”“风险画像较高”或“命中制裁名单”。该属性为失败流程提供了关键背景信息。

分析拒绝原因是“申请拒绝分析”仪表板的基础。它有助于企业开展根因分析，了解开户流程中最常见的失败点。通过对这些原因进行分类和量化，组织可以确定改进优先级。例如，如果“文档不完整”是主要原因，公司可以重点优化客户指引或改进文档提交门户。

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

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

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

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

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

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

此属性用于标识客户提交申请的方式，例如“Web Portal”“Mobile App”或“In-Branch”。不同渠道可能采用不同的数据采集流程，并带来不同的客户体验。

按渠道分析流程，有助于评估各客户触点的表现和效率。您可以了解：“Mobile App提交的申请是否比Web Portal提交的申请处理得更快？”或“在网点提交的申请返工率是否更高？”这些洞察有助于优化全渠道客户旅程，并合理分配资源。

支持比较Web、Mobile或线下提交等不同渠道的流程效率和客户体验。

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