Geekly articles weekly

如何为Celonis为SAP Process Mining准备数据

以IT服务管理系统（ITSM）中的数据为例。

在上一篇有关SAP Process Mining或如何理解我们的业务流程的文章中，我们讨论了Process Mining及其在公司环境中的应用。 今天，我们想更多地讨论数据模型及其准备过程。 我们将研究组件，它们如何互连，向数据所有者请求什么数据格式以及Celonis为SAP Process Mining生成事件表的方法可能是什么。

CELONIS在SAP PROCESS MINING中的数据模型


SAP Process Mining by Celonis工具中的数据结构非常简单：

  • “事件表。” 这是数据模型的必需部分。 这样的表在每个单独的数据模型中只能是一个。 将在其上自动生成过程图。 见图1。
  • 目录是使用其他分析信息扩展“事件表”的任何其他表。 与她不同，参考信息不会随时间变化。 更准确地说，它不应在我们分析的时间间隔内改变。 例如，它可以是一个表，其中描述了合同，采购项目，某物的应用，员工，法规，承包商和其他某种过程中涉及的对象的属性。 在这种情况下，参考文献将描述这些对象的各种静态属性（数量，类型，名称，名称，大小，部门，地址和其他各种属性）。 目录是可选的。 您可以在没有它们的情况下运行数据模型。 简单地分析这样的过程将变得不那么有趣。

图片
图1. Proces Mining中的数据模型：一个事件表和对流程实例的引用

事件表是SAP HANA内存平台中的标准表（物理存储，而不是逻辑表）。 目录可以表示为标准表（物理存储）和计算表（计算视图）。 除极少数情况外，可能有必要向现有数据模型中添加CSV或XLSX形式的一些小引用。 该功能直接存在于图形界面中。

下面我们将仔细研究数据模型的这两个组件。

“事件表”（又称“事件日志”）至少包含三列：

  1. 流程标识符是每个流程实例的唯一键（例如，引用号，事件号或任务号）。 在图2的示例中，这是“ CASE_ID”列。
  2. 活动。 这是流程中步骤的名称-我们感兴趣的某种事件。 流程图是由活动组成的（“ EVENT”列）。
  3. 事件的时间戳记（列“ TIMESTAMP”）。

图片
图2.示例事件表

Celonis的当前版本的SAP Process Mining在单个数据模型中最多支持1000个唯一事件。 也就是说，上例中“ EVENT”列中的唯一值的数量（在事件表中可能被不同地调用）不应超过1000个。事件本身（即该表中的行）可能很多。 我们已经在一个数据模型中看到了数亿个事件的示例。

时间戳记可以由一列表示，然后由您来确定含义是-步骤3的开始或结束，或者明确显示步骤的开始和结束时如图2所示的两列。 两列版本之间的根本区别在于，系统将能够自动识别彼此并行执行的步骤。 在比较各个步骤的开始时间和结束时间时可以看到这一点。

图片
图3.具有两个时间戳的示例事件表

该表中的所有其他列都是可选的。 也可以使用三个必填列来成功恢复过程图，但是很难摆脱缺少某些东西的感觉。 因此，强烈建议您不要将自己限制在最少的扬声器范围内。

其他列是您感兴趣的任何信息，这些信息在此过程中会更改或与特定事件相关联。 例如，进行事件的员工的姓名，工作组，应用程序的当前优先级。 这里强调时间依赖性并非偶然。 建议您在事件表中仅保留可变数据。 所有其他静态信息最好放在单独的目录中。 换句话说，如果可能，应该对事件日志进行规范化。 这样做并不是为了减少数据量，而是在构建分析报告的阶段促进对PQL表达式的进一步工作。

让一切就绪

如果将带有参考信息的列添加到“事件表”会怎样？ 通常，至少在最初，不会发生任何可怕的事情。 对于任何想法的快速测试，此选项都非常合适。 只会有两个负面影响：不必要地复制数据副本和某些分析公式中的其他困难。 如果所有其他数据都已提交到目录，则可以避免这些困难。 一般来说，最好立即进行操作。

关于许可的一些知识

事件表与Celonis授予的SAP Process Mining许可相关联。 一个数据模型= 1个许可证= 1个事件日志。 有了一定的保留，我们可以说1个事件日志= 1个业务流程。 注意事项如下：当多个进程放入一个事件日志时可能会出现情况，反之亦然-有意为一个进程创建多个事件日志。 此外，术语“业务流程”可以从数据的角度进行相当广泛的解释。 因此，出于许可目的，出于显而易见的标准，选择了事件日志的数量。 应当依靠这一标准。

目录

目录是可选的，将它们添加到数据模型是可选的。 它们包含可能对过程分析有用的任何其他信息。 但是，与事件表不同，目录中的信息是静态的，它与事件发生的时间无关。

这里应提及一种特殊情况。 当涉及到执行业务流程中步骤的用户数据时，就会出现一个问题：该信息是否参考？ 一方面，是的-这是静态数据。 最好在事件表中只保留一个特定的“ USER_ID”，根据该名称，用户的名称，职位和部门，工作组的成员身份等将与活动相关联。 但另一方面，让我们想象一下，我们在2至3年的时间跨度内分析业务流程。 在此期间，用户可以更改多个职位并在部门或工作组之间切换。 事实证明，这是随时间变化的信息。 在这种情况下，应将其保留在事件表中，这将导致以下事实：在事件日志中，除了“ USER_ID”外，还将出现“工作组”，“位置”，“部门”甚至“全名”（姓）等列在这段时间内也可能会发生变化）。 通常，是否规范用户信息的问题仍由客户自行决定。
目录可以随时添加到现有数据模型中。

要做到这一点很简单：

  1. 在SAP HANA中创建一个表。
  2. 使用“导入数据”按钮将该表添加到常规数据模型中。

    图片
    图4.将表或文件导入现有数据模型
  3. 键（或多个键）在图形界面中指示，新目录通过该键与事件表和/或其他目录关联。 为此，只需单击图标 图片 在一张桌子上，然后在对应的桌子上 图片 在另一个桌子上。

    图片
    图5.通过任意字段（在本例中为CASE_ID）链接数据模型中的表
  4. 在“状态”菜单中，单击“从源重新加载”按钮。 此过程通常需要几秒钟。

    图片 图6.从源代码重新加载数据模型

完成这些步骤后，您可以立即在新报表和现有报表中使用新的分析。 数据模型的丰富不会以任何方式损害分析师的当前工作：所有创建的报告将继续工作，您无需重做或以某种方式更改它们。

对于相对较小的目录，还有另一种可能性：当然不是完全工业版本，但是它也很有用。 它涉及通过图形界面将CSV，XLSX，DBF文件直接加载到数据模型中。 该过程与上述过程完全相同，只是使用预先准备的文件而不是数据库表，该文件随“导入数据”按钮一起加载。

CA表：流程实例参考

先前有关参考书的讨论始于它们是可选的事实。 它们可以从数据模型中完全省略，而仅限于事件表。 这几乎是真的。
确实存在一个强制性参考。 这应该是一个标有状态“ CA Table”的表。 CA是事件链。 而且，您猜对了，该目录中的密钥将为“ CASE_ID”-流程实例的唯一标识符。 这样的参考描述了单个流程实例的静态属性。 来自ITSM的示例：上诉的作者，业务服务，截止日期或成功解决此事件的员工，举止标志等。

图片
图7.示例CA表

但是我并没有欺骗你太多。 如果出于某种原因您决定不将所需目录添加到数据模型，则系统将自行生成该目录。 其工作的结果可以在“状态”选项卡中看到：如果事件表被调用为“ ITSM_EVENTS”，则将与其一起生成表“ ITSM_EVENTS_CASES”，如图8所示。

图片
图8.自动生成的事件链（CA）表

自动生成的CA表将非常简单地描述流程实例：键，事件数，流程持续时间（就像您按流程标识符对事件表进行分组，计算的行数以及第一步和最后一步之间的时间差一样）。 因此，创建您自己的，更有趣的CA表版本是有意义的。 可以随时将其添加到数据模型中。 同时，将CA表添加到模型后，系统会自动从数据模型中删除系统生成的目录（在本例中为“ ITSM_EVENTS_CASES”）。

为什么“ CA Table”很有趣？ 是她在图形界面中显示为过程详细信息。 如果分析师在使用数据模型的过程中发现了一些有趣的事情，并且想深入研究各个特定的示例，那么他将使用“ View CA”报告，即详细信息。 打开此类报告后，您将在其中找到进程的目录（当然，还与事件表结合在一起）。 因此，将“分析人员可以用来理解过程的属性和过程条件的所有内容”添加到“ CA表”中。

图片
图片
图9.综合示例报告“ View CA”

如何将过程引用添加到数据模型：

  1. 在SAP HANA中创建一个表。
  2. 使用“导入数据”按钮将该表添加到常规数据模型中。
  3. 在图形界面中，在表的属性中，需要为其设置角色“带有CA的表”。

    图片
    图10.“带有CA的表”的作用，指示流程实例的目录
  4. 在GUI中，通过进程ID将CA表与事件表相关联。 此步骤的执行方式与常规目录相同-使用键符号key（ 图片 ）对应字段的对面。
  5. 在“状态”菜单中，单击“从源重新加载”按钮。

重要说明： CA表中的 “ CASE_ID”列（在每种情况下，都可能称为“ CASE_ID”列）（其中包含进程标识符并用于与事件表关联）应仅包含唯一值。 这是很合逻辑的。 并且如果由于某种原因不是这样，则在步骤（5）中加载数据模型时，将生成相应的错误（关于不可能在事件表和CA表上执行“ JOIN”操作）。

根据变更历史记录创建数据模型


在实践中，我们遇到了非常不同的数据挖掘数据源。 它们的组成取决于所选的业务流程和客户采用的标准。
最常见的情况之一是来自IT服务管理系统（ITSM，IT服务管理）的数据，因此我们决定首先分析此示例。 实际上，这种方法没有专门针对ITSM的紧密绑定。 它可以应用于其他业务流程，其中数据源是更改历史记录或审核日志。

向IT部门问什么？

如果您不是IT员工，也不是为ITSM提供服务的专家，那么请做好准备，以确保您被要求为“您要卸载什么？”这个问题提出确切的答案。 或“您想从我们这里得到什么？”

这并不总是知道的-到底需要什么。 对业务流程的分析是一项研究，寻找模式并寻求“洞察力”。 如果我们事先知道我们要寻找什么样的“洞察力”，那么这将不再是“洞察力”。 实际上，我想获得“一切”：属性，关系，变化。 但是，正如实践所示，对于一个过于笼统的问题，从来没有一个好的准确答案。

对于“您要卸载什么”这个问题，有两个可能的答案。

该选项是错误的：要求基础卸载应用程序状态中的所有更改以及一组显而易见的属性（例如，优先级，艺术家，工作组等）。 首先，您只有有限的一组分析师：您已经知道要在流程中进行度量（这是属性集的来源），因此Process Mining将变成用于计算流程KPI的工具（非常方便，我必须说，这是一种工具；但是我仍然想更多）。

其次，每个单独的IT部门对请求的解释不同，以将其他请求属性添加到上载中。 例如，优先考虑：在通话中它可以更改。 上诉具有一个优先权，然后工作组的专家对其进行更改，然后以不同的状态结束。 现在的问题是：在您要求的卸货中，哪个时刻对应优先级？ 最初，优先级值似乎应该对应于“事件的日期和时间”列。 但是实际上，通常会发现只有应用程序状态本身才对应于指定的日期和时间，而所有其他列都是卸载时或关闭应用程序时的值。 而且您不会立即知道这一点。

在我看来，还有更好的选择。 您可以采用下表的形式请求数据：

  1. 申诉，事件，任务的编号（SD *，IM *，RT *，...）是ITSM系统中对象的标识符（NVARCHAR）
  2. 时间戳记（TIMESTAMP）
  3. 属性名称（NVARCHAR）
  4. 旧值（NVARCHAR）
  5. 新值（NVARCHAR）
  6. 谁更改了（NVARCHAR）

实际上，这无非是任何属性变化的历史。 在ITSM系统的界面中，可以在选项卡上看到名称为“ History”或“ Journal”的表。

这种方法的优势显而易见：

  1. 简单明了的上传格式。 IT专业人员对系统本身的图形界面很熟悉。 从基础上不应该引起问题。
  2. 我们获得具有所有可能值的所有可能属性的列表。 是的，会有很多，很可能是几百个。 但是筛选出不必要和无趣的内容非常简单，但是每次请求额外的卸载并不总是那么简单，而且总是很长（尤其是当您根本不知道系统中存在哪些属性时）。
  3. 这是一个可靠的数据模型。 除非有意制造虚假信息，否则很难破坏它。
  4. 我们确切地知道每个属性在每个时刻都有什么。 这很重要，因为我们要进行自我测试并确保模型正确。 在分析过程中，我们可以向模型添加中间步骤（“放大”），并在所有其他时间点确定正确的属性值。

第二种选择的缺点也很明显。 在我看来，它们可以解决（与数据不完整的问题相对）：

  1. 用于准备数据的SQL脚本变得有些复杂-与IT基础团队为您进行数据的部分准备（请参见上面的查询的第一个版本）而不用怀疑时的选择相比。 是的，他（脚本）比较复杂，但他一个人。 我认为在ITSM团队和Process Mining团队之间共享数据准备不是一个好主意。 理想情况下，应将整个转换工作移交给Process Mining团队，以使他们了解数据到底发生了什么，并最大程度地减少对源端数据的干扰。 一种简单的数据交换格式有助于实现此目标。
  2. 卸载量很大。 顺序可能是这样的：大型公司为10-30 GB /年。 但是，将这样的卷加载到HANA上根本不是问题，甚至都不被认为是一项任务。 此外，我们仅在试点项目中谈论“上载”，而数据源与HANA之间的ETL / ELT集成（例如，HANA Smart Data Integration）将用于工业运营，而这一项目将不再重要。

我不想说这是从ITSM系统中获取用于流程挖掘任务的数据的唯一正确方法。 但是目前，我倾向于认为这是完成此任务的最方便的格式。 可能还有很多有趣的方法，如果您与我分享这些想法，我将很高兴与他们讨论。

事件表生成


因此，在出口处，我们具有请求，事件，呼叫，任务和其他ITSM对象的属性变化的历史记录。 从这样的表中，可以生成Process Mining数据模型的两个关键组件：事件表和CA表。

要基于更改历史记录生成事件，请执行以下操作：

  1. 从更改历史记录中，收集（有条件的）“属性名称”列的所有唯一值。
  2. 确定您希望在流程图上看到的属性的更改。 对我们来说什么是“事件”？
  3. 创建一个适当的“计算视图”或编写一个SQL脚本，该脚本可过滤更改历史记录中的选定行并生成事件表。

假设变更表如下：

CREATE COLUMN TABLE "SAP_PM"."ITSM_HISTORY" ( "CASE_ID" NVARCHAR(256), "ATTRIBUTE" NVARCHAR(256), "VALUE_OLD" NVARCHAR(1024), "VALUE_NEW" NVARCHAR(1024), "TS" TIMESTAMP, "USER" NVARCHAR(256) );

首先，查看存在的所有属性的列表。 可以在“打开数据预览”菜单中或使用类似以下的简单SQL查询来完成：

 SELECT DISTINCT "ATTRIBUTE" FROM "SAP_PM"."ITSM_HISTORY";

图片
图11. SAP HANA Studio中带有“打开数据预览”命令的上下文菜单

然后，我们确定属性的组成，对我们来说，更改属性是过程中的一个事件。 以下是此类列表的明显候选人列表：

  • 现况
  • 被带去工作
  • 类别已更改
  • 违反截止日期
  • 违反反应时间
  • 请求已返回以进行修订。
  • 第一行错误
  • 工作小组
  • 优先权

当然，这里的主要事件是上诉/事件\应用程序\任务的状态之间的转换。 “状态”属性（VALUE_NEW）本身的值将是我们的处理步骤的名称。 因此，创建事件表作为第一近似可能如下所示：

 CREATE COLUMN TABLE "SAP_PM"."ITSM_EVENTS" ( "CASE_ID" NVARCHAR(256) ,"EVENT" NVARCHAR(1024) ,"TS" TIMESTAMP ,"USER" NVARCHAR(256) ,"VALUE_OLD" NVARCHAR(1024) ,"VALUE_NEW" NVARCHAR(1024) ); INSERT INTO "SAP_PM"."ITSM_EVENTS" SELECT "CASE_ID" ,"VALUE_NEW" AS "EVENT" ,"TS" ,"USER" ,"VALUE_OLD" ,"VALUE_NEW" FROM "SAP_PM"."ITSM_HISTORY" WHERE "ATTRIBUTE" = '' ;

更改其余属性是我们的其他步骤，这些步骤使对过程的研究变得更加有趣。 它们的组成取决于业务分析师的要求，并且可能随着公司中Process Mining惯例的发展而改变。

 INSERT INTO "SAP_PM"."ITSM_EVENTS" SELECT "CASE_ID" ,"ATTRIBUTE" AS "EVENT" ,"TS" ,"USER" ,"VALUE_OLD" ,"VALUE_NEW" FROM "SAP_PM"."ITSM_HISTORY" WHERE "VALUE_OLD" IS NOT NULL AND "ATTRIBUTE" IN ( '   ' ,'  ' ,'  ' ,'  ' ,'    ' ,' 1- ' ,' ' ,'') );

扩展WHERE“ ATTRIBUTE” IN（.....）过滤器中的属性列表，可以增加在流程图上显示的各个步骤。 值得注意的是，各种各样的步骤并不总是一件好事。 有时过于详细的细节只会使您难以理解该过程。 我认为，在第一次迭代之后，您将确定哪些步骤需要执行，哪些步骤应从数据模型中排除（而做出此类决策并快速适应这些决策的自由是另一个主张将转换数据的工作移交给流程挖掘团队方面的论点） 。

过滤器“ VALUE_OLD”不为NULL，很可能将用更适合您的条件和所选属性的值替换它。 我将尝试解释此过滤器的含义。 在ITSM系统的某些流行实施中，在上诉注册（公开）时，将有关对象所有属性初始化的信息输入到日志中。 即，所有字段都标记有一些默认值。 目前，VALUE_NEW将包含相同的初始化值，而VALUE_OLD将不包含任何内容-毕竟，直到此刻为止都没有历史记录。 在此过程中，我们绝对不需要这些记录。 应使用适合您特定条件的过滤器将其卸下。 这样的过滤器可能是：

  • “ VALUE_OLD”不为空
  • “ VALUE_NEW” ='是'
  • 您可以关注时间戳（仅记录对象注册后发生的事件）。
  • 如果系统帐户正在初始化，则可以关注“ USER”字段。
  • 您提出的任何其他条件。

CA表生成


用作事件源的相同更改历史记录对于创建流程实例目录（CA表）也很有用。 算法类似：

1.定义以下属性列表：

一个 在申请工作期间，请勿更改，例如，上诉的作者及其所在部门，基于工作结果的用户等级，违反期限的标志。

b。 它们可以更改，但是我们仅对某些时候的值感兴趣：注册时，结业时，雇用时，从第二行转移到第一行等。

c。 它们可以更改，但是我们只对合计值（最大值，最小值，数量等）感兴趣。

2.创建具有所需列集的对角线表。 我们感兴趣的每个属性都会生成自己的一组行（根据流程实例的数量），其中只有一列将具有值，其余所有列将为空（NULL）。

3.使用按进程标识符分组将对角线表折叠到最终目录中。

放入CA表中有意义的属性示例（实际上，此列表可以更长）：

  • 服务专区
  • IT系统
  • 作者
  • 作者组织
  • 用户对解决方案质量的评价
  • 工作回报数
  • 什么时候上班
  • 创建者
  • 谁关闭
  • 由第1行解决
  • 分类/路由无效
  • 截止期限
  • 违反截止日期

一个属性可以是流程中事件的源，也可以是流程实例的属性。 例如，属性“优先级”。 一方面，我们对上诉登记时它的重要性感兴趣，另一方面，可以将此属性的所有更改事实作为独立步骤提交给流程图。

另一个例子是截止日期。 这是过程的明显参考属性，但是您可以从过程图中进行虚拟步骤：过程中不存在诸如“最后期限”之类的操作，但是如果我们将相应条目添加到事件表中，我们将人为地创建它，并可以可视化位置流程图上其他步骤的执行时间。 这方便快速分析。

通常，当我们基于属性更改的历史记录创建流程属性时，对我们有用的信息可以是：

  • 属性值本身（例如：“用户评分”）
  • 更改它的用户
  • 变更时间
  • 属性取某个值的时间（例如：属性“违反截止期限”对属性值本身不感兴趣，但对它变为与引发的标志相当的时间感兴趣，例如“ yes”或“ 1”）
  • 该属性存在于历史记录中的事实（例如：“大规模事件”，值为“是”）

当然，此列表可以与其他使用属性以及与属性相关的思想一起继续。

现在我们已经确定了感兴趣的属性列表，让我们看一下生成CA表的可能方案之一。 首先，使用上面为自己定义的一组列创建表本身：

 CREATE COLUMN TABLE "SAP_PM"."ITSM_CASES" ( "CASE_ID" NVARCHAR(256) NOT NULL ,"CATEGORY" NVARCHAR(256) DEFAULT NULL ,"AUTHOR" NVARCHAR(256) DEFAULT NULL ,"RESOLVER" NVARCHAR(256) DEFAULT NULL ,"RAITING" INTEGER DEFAULT NULL ,"OPEN_TIME" TIMESTAMP DEFAULT NULL ,"START_TIME" TIMESTAMP DEFAULT NULL ,"DEADLINE" TIMESTAMP DEFAULT NULL );

我们还将需要一个临时表“ ITSM_CASES_STAGING”，该表将使我们能够为流程实例目录中所需的属性列整理出平坦的属性列表：

 CREATE COLUMN TABLE "SAP_PM"."ITSM_CASES_STAGING" LIKE "SAP_PM"."ITSM_CASES" WITH NO DATA;

这将是一个对角线表格-每行中只有两个字段具有值：“ CASE_ID”，即 流程标识符，以及一个具有流程属性的字段。 该行中的其余字段将为空（NULL）。 在最后阶段，我们可以通过简单的聚合轻松将对角线折叠成行，从而获得所需的CA表。

治疗类别的示例：

 INSERT INTO "SAP_PM"."ITSM_CASES_STAGING" ("CASE_ID", "CATEGORY") SELECT "CASE_ID", LAST_VALUE("VALUE_NEW" ORDER BY "TS") FROM "SAP_PM"."ITSM_HISTORY" WHERE "ATTRIBUTE" = '' GROUP BY "CASE_ID" ;

假设作者是上诉历史上第一个注册上诉的非系统用户（在您的特定情况下，标准可能更准确）：

 INSERT INTO "SAP_PM"."ITSM_CASES_STAGING" ("CASE_ID", "AUTHOR") SELECT "CASE_ID", FIRST_VALUE("USER" ORDER BY "TS") FROM "SAP_PM"."ITSM_HISTORY" WHERE "USER" != 'SYSTEM' GROUP BY "CASE_ID" ;

如果我们认为处理器将最后状态“建议的解决方案”放下（并且可以重复提供解决方案，但只有最后一个解决方案是固定的），则该问题已成功解决，那么流程实例的此属性可以表述为：

 INSERT INTO "SAP_PM"."ITSM_CASES_STAGING" ("CASE_ID", "RESOLVER") SELECT "CASE_ID", LAST_VALUE("USER" ORDER BY "TS") FROM "SAP_PM"."ITSM_HISTORY" WHERE "ATTRIBUTE" = '' AND "VALUE_NEW" = ' ' GROUP BY "CASE_ID" ;

用户评分（对此决定感到满意）：

 INSERT INTO "SAP_PM"."ITSM_CASES_STAGING" ("CASE_ID", "RAITING") SELECT "CASE_ID", TO_INTEGER(LAST_VALUE("VALUE_NEW" ORDER BY "TS")) FROM "SAP_PM"."ITSM_HISTORY" WHERE "ATTRIBUTE" = ' ' AND "VALUE_NEW" IS NOT NULL GROUP BY "CASE_ID" ;

登记（创建）的时间只是循环历史上的最早记录：

 INSERT INTO "SAP_PM"."ITSM_CASES_STAGING" ("CASE_ID", "OPEN_TIME") SELECT "CASE_ID", MIN("TS") FROM "SAP_PM"."ITSM_HISTORY" GROUP BY "CASE_ID" ;

反应时间是服务质量的重要特征。 要计算它，您需要知道什么时候第一次出现“开始工作”标志：

 INSERT INTO "SAP_PM"."ITSM_CASES_STAGING" ("CASE_ID", "START_TIME") SELECT "CASE_ID", MIN("TS") FROM "SAP_PM"."ITSM_HISTORY" WHERE "ATTRIBUTE" = '   ' AND 'VALUE_NEW' = '' GROUP BY "CASE_ID" ;

截止日期用于计算KPI，以便及时响应申诉或解决事件。 在此过程中，最后期限可能会反复更改。 要计算KPI，我们需要知道此属性的最新版本。 如果我们要明确跟踪截止日期的变化方式，即在流程图上显示此类情况，则还应该使用此属性在事件表中生成一个条目。 这是属性的示例，同时用作流程的属性和事件的来源。

 INSERT INTO "SAP_PM"."ITSM_CASES_STAGING" ("CASE_ID", "DEADLINE") SELECT "CASE_ID", MAX(TO_DATE("VALUE_NEW")) FROM "SAP_PM"."ITSM_HISTORY" WHERE "ATTRIBUTE" = ' ' AND 'VALUE_NEW' IS NOT NULL GROUP BY "CASE_ID" ;

以上所有示例均为同一类型。 与它们类似，可以使用您感兴趣的任何属性来扩展CA表。 而且，这可以在项目启动后就已经完成，系统允许您在其运行期间扩展数据模型。

当临时对角线表中充满了流程实例的属性时，剩下的就是进行聚合并获得最终的CA表：

 INSERT INTO "SAP_PM"."ITSM_CASES" SELECT "CASE_ID" ,MAX("CATEGORY") ,MAX("AUTHOR") ,MAX("RESOLVER") ,MAX("RAITING") ,MAX("OPEN_TIME") ,MAX("START_TIME") ,MAX("DEADLINE") FROM "SAP_PM"."ITSM_CASES_STAGING" GROUP BY "CASE_ID" ;

之后，我们不再需要临时表中的数据。 可以保留表本身以继续定期重复上述过程，以更新Process Mining中的数据模型：

 DELETE FROM "SAP_PM"."ITSM_CASES_STAGING";

准备和清理试点项目CSV文件的提示


您可能会通过一个试点项目开始与“过程采矿”这一学科相识。 在这种情况下，将无法获得对数据源的直接访问； IT员工和信息安全人员都将拒绝这样做。 这意味着作为试点项目的一部分，我们将必须将数据从公司系统导出到CSV文件，然后将其导入SAP HANA以建立数据模型。

在工业安装中，不会导出到CSV。 相反，将使用SAP HANA集成工具，特别是：智能数据集成（SDI），智能数据访问（SDA）或SAP景观转换复制服务器（SLT）。 但是，为了测试和熟悉该技术，导出到CSV文本文件是组织上更简单的方法。 因此，与您共享一些技巧，以帮助您快速，成功地将数据导入CSV中，以CSV格式准备数据。

导出时文件本身的建议格式要求：

  1. 档案格式：CSV
  2. 编码：UTF8
  3. 字段分隔符：方便您输入的任何字符。 例如，“ |” 或“ ^”或“〜”。 选择的逻辑很简单-我们必须尽量避免在数据本身包含“拆分”时的情况。
  4. 有必要从字段的值中删除分隔符。 是的，您可能会说，为此，实际上有引号。 但是，正如经验所示，带引号的情况也会出现很多问题。 通常，让我们从字段值中删除（或替换）分隔符。 您的试点项目不会受到这种不准确的影响，但是可以显着节省数据准备时间。
  5. 引号：从字段值中删除所有引号。 经常在公司名称中找到引号-例如，Kalinka LLC。 但是有这样的选择：MPZ Kalinka LLC。 现在这是一个很大的困难。 字段值中的引号必须带有“ \”符号，或者被删除，并用其他符号代替。 简单地删除它是最可靠的。 字段值不会因此受到太大影响。
  6. 承运人转移：从字段值中删除所有CHAR（10）和CHAR（13）字符。 否则，将无法从CSV导入。

如果考虑点（4）+（5）+（6），则在选择中使用以下结构是有意义的：

 REPLACE(REPLACE(REPLACE(REPLACE("COLUMN", '|', ';'), '"', ''), CHAR(13), ' '), CHAR(10), ' ') as "COLUMN"

此外，当CSV文件准备就绪时，需要将其复制到HANA服务器的一个声明为可以安全导入文件的文件夹中（例如，/ usr / sap / HDB / import）。 只要文件是“干净的”，从本地CSV文件将数据导入HANA是一个相当快的过程：

  • 将来表的每一行都在文件的一行中，并且只有一行；
  • 所有行的列数相同；
  • 引号要么成对出现要么根本不存在；
  • 字段值中的引号或者带有“转义”-符号“ \”，或者完全不存在；
  • UTF-8编码（而不是导出到Windows系统时发生的UTF8-BOM）。

要在导入之前检查CSV文件并查找问题区域（如果存在）（可能性为99％），可以使用以下命令：

1.检查文件开头的BOM字符：

文件 data.csv

如果命令的结果是这样的：“ UTF-8 Unicode（带BOM）文本”，则意味着编码为UTF8-BOM，您需要从文件中删除BOM字符。 您可以按以下方式删除它：

sed -i'1s / ^ \ xEF \ xBB \ xBF //'data.csv

2.文件的每一行的列数应该相同：

cat data.csv | awk -F»;“'{print NF}'|排序| uniq

或像这样：

对于以美元表示的我（ls * .csv）; 回显$ i; 猫$我| awk -F';' '{print NF}'| 排序 uniq -c; 回声 完成

更改“;” 在参数F中，您所用的字段分隔符是什么。
这些命令的结果是，您可以通过每行中的列数来获得行的分布。 理想情况下，您应该获得以下内容：

EKKO.csv
79536 200

该文件包含79536行，所有行均包含200列。 没有具有不同列数的行。 应该是这样。

这是一个错误结果的示例：

LFA1.csv
73636 180
7181

在这里，我们看到大多数行包含180列（很可能这是正确的列数），但是有些行的第181列。 即，这些字段之一的值中包含分隔符。 我们很幸运，只有7条这样的行-可以轻松地手动查看它们并以某种方式进行更正。 您可以看到行数不等于180的行，如下所示：

cat data.csv | awk -F“;” '{if（NF！= 180）{print $ 0}}'

有关使用上述命令的说明。 这些命令将不注意引号。 如果定界符包含在用引号引起来的字段中（这意味着从导入数据库的角度来看这里一切都很好），则使用此方法进行检查将显示错误的问题（额外的列）-分析结果时也应考虑在内。

3.如果引号未配对并且不能解决此问题，则可以从文件中删除所有引号：

sed -i's /“ // g” data.csv

这种方法的危险在于，如果字段值包含分隔符，则行中的列数将发生变化。 因此，在导出阶段必须从字段值中删除分隔符（删除或替换为其他字符）。

4.空字段

面对这种格式的空字段值阻止成功导入数据的情况：

;“”

其中“;” 在这种情况下是字段分隔符的符号。 即，该字段是两个双引号（纯空字符串）。 如果突然无法导入数据，并且怀疑问题可能是空字段，请尝试将NULL替换为“”

sed -i's /;”” /; NULL / g'data.csv

（用“;”代替分隔符选项）

5.在数据中查找“脏”数字格式可能很有用：

;“ 0” （数字包含空格）
；“ 100.10-” （数字后面的符号“-”）
布加迪3/4“ 300起重机 -英寸尺寸用双引号表示-导出时会自动导致引号不成对的问题。

不幸的是，这不是详尽的清单，列出了导入数据库的不方便数据格式的可能问题。 最好从实践中了解您的选择：您遇到了哪些好奇的错误？ 您如何检测和消除它们。 分享评论。

结论


通常，用于流程挖掘的数据模型非常简单：一个事件表以及（可选）其他参考书。 但是正如通常发生的那样，只有在至少完成一个完整的任务周期后，它才看起来很简单-然后整个过程是完整可见的，并且工作计划很清晰。 我希望本文能帮助您了解第一个Process Mining项目的数据准备。 通常，准备过程如下所示：

  1. 向数据所有者请求更改历史记录
  2. 检查和清理上传文件（准备CSV文件）
  3. 导入到SAP HANA
  4. 活动桌建设
  5. 建立CA表（流程参考）

而且，实际上，这是数据模型准备开始的地方，而最有趣的部分就是过程挖掘。 如果您在实施Process Mining项目期间有任何疑问，请随时在评论中写下，我们将竭诚为您服务。 祝你好运！

Fedor Pavlov，SAP CIS平台专家

Source: https://habr.com/ru/post/zh-CN462565/

More articles:


All Articles