预约演示
欢迎拨打电话咨询
400-056-2908
电话咨询
免费试用
在线咨询
返回
更快,更简单,更全面发现业务中的问题
PQL,Process Query Language,
由望繁信开发的一种针对流程数据模型定制的领域特定查询语言,
在特定的流程引擎Process Engine上执行,来满足高效的流程查询和分析。
营运资本:
是衡量一个企业的短期财务状况和资金流动性的关键指标,不断优化企业资金流动性是企业营运资本优化的关键。常见的优化营运资本的方式有:减少库存,更快回款,延长负债偿还周期等。
1. 计算每个客户的超时付款率
计算每个客户的超时付款率此例中以更快回款为目标,统计O2C(Order to Cash,订单到收款)的流程中客户的超时付款率,以该超时付款率为指标衡量客户的质量来帮助企业优化营运资本。超时付款率高的客户,企业在与该客户达成交易时,对于回款的周期更偏向预期会晚,可以为了企业营运资本的管理提前做好规划,在预期回款的月份中提前准备更多其他渠道的流动资金来源,而不是预期该客户的打款会在其中。
客户3004699是本例中的优质客户,订单量最多且超时付款率最低,客户管理上建议注重客情维护,争取达成更多的交易量。其他超时付款率大于90%的客户,应建立更完备的客户信用评定制度,提前了解客户财务状况等信息,并建立客户档案,对客户资信实行动态管理,对资信下降的客户及时采取减少发货、实行担保和加强催收等预防和减少风险的措施;对资信差、长期拖欠货款的客户必要时停止发货。在对企业未来现金流的预测中根据客户资信不同,采用科学的方法预估回款金额及时间。
2. 计算每个供应商的付款周期分箱案例占比
此例中以预估付款周期为目标,统计PTP(Purchase to Pay,采购到付款)的流程中不同供应商的付款周期,就此来帮助企业优化营运资本。早付款会导致资金提前流出,如果营运资本运营不善有现金流断裂的风险;晚付款可能会有相应的罚款,或者不再享有之前的现金折扣等。对于付款周期的把控有助于企业更好地优化营运资本。
此例数据集中全流程是从“接收发票”开始,到“按票付款”结束,所以案例的吞吐时间代表一个案例的付款周期。在对供应商zjklzy的付款流程中,一个月以上付款周期的订单数最多,占zjklzy的订单中的17.66%。如果依赖该供应商的货物量较大,付款周期超过30天会直接影响在供应商的客户信用评定体系中评分,评分较低时,可能会产生逾期付款罚金,后续可能也会引起断货危机。企业与供应商batgs交易量大,且只有3.13%的订单付款周期在一个月以上,继续保持按时付款有利于维护长期良性合作。
吞吐时间的计算在流程挖掘中极为重要,也是效率高低的直接表现:通常情况下,吞吐时间长的效率低。本章中举例说明可以灵活运用PQL多种计算方式计算吞吐时间。
1、计算每个案例的吞吐时间
在时效分析中对于吞吐时间的计算是最直观且有效的指标,对于只有一列时间戳的数据集,和活动开始时间列与活动结束时间列都有的数据集,PQL提供CALC_THROUGHPUT()语句和CALC_THROUGHPUT_WITH_STARTTIME()语句两种可方便得计算各种情况下的间隔时长。在不考虑其他因素影响下,同种业务流程中耗时越长的我们可以视为效率越低。
1.1 适用于只有活动结束时间一列时间戳的数据集
此例中的数据集只有活动结束时间一列时间戳,计算案例的吞吐时间时CALC_THROUGHPUT()语句更适用。
1.2 适用于有活动开始时间与活动结束时间两列时间戳的数据集
此例中的数据集有活动开始时间与活动结束时间两列时间戳,计算案例的吞吐时间时CALC_THROUGHPUT_WITH_STARTTIME()语句更适用。
2. 计算每个案例中活动间间隔时间
计算案例中活动间的间隔时长在效率分析中非常常见:
- 对于只有一列时间戳的数据集,其节点的吞吐时间=0。如果该时间戳列为活动的结束时间,则该活动的吞吐时间_边,也就是上个活动结束到这个活动结束间的时长可视为该节点的处理时长;如果该时间戳列为活动的开始时间,则下一个活动的吞吐时间_边,也就是这个活动开始到下一个活动开始间的时长可视为该节点的处理时长;
- 对于有活动开始时间与活动结束时间两列时间戳的数据集,节点间的间隔时间可视为等待时间,等待的时长是无意义的拖延,可从缩短等待时长入手提高效率。
2.1 案例中连续的活动间间隔时间
在一个案例中连续发生的活动间间隔的时间,可以通过多种PQL语句的方式实现,包括并不限于本章中的例子。在连续活动中可看到:1)从“创建发票”到“创建清账凭证”平均耗时73.05天,收款周期长,后续可加强催收机制,或对超时付款的客户设定相应的罚金,或以现金折扣吸引客户更快付款等;2)从“创建销售订单”到“超时发货”之间的平均耗时有69.19天,发货前耗时长,可能是由于生产环节耗时长,需采取相应措施缩短工期,也可能是销售订单后的发货环节疏忽,则需要设置相应的责任人与提醒机制等。
2.1.1 通过ACTIVITY_LAG()/ACTIVITY_LEAD()返回上一节点/下一节点
第一种方式是对于当前节点,其吞吐时间_边即该节点与上一节点间的间隔时间,可以通过ACTIVITY_LAG()输出上一节点的内容。
2.1.2 通过SOURCE()/TARGET()实现活动表中不同行的值合并到同一行
第二种方式是通过SOURCE()和TARGET()函数将不同行合并到临时表中的同一行,之后可通过时间差值函数得到同一行中两个时间戳列的差值。
2.2 案例中从某活动开始/结束到另一个活动开始/结束的间隔时间
此例中的表中流程如下,如果我们将全过程分阶段分为:1)第一次发货前的时长;2)从第一次发货到最后一次清账结束的时长,来观察这两个阶段在案例总用时中大致占了多少。可以通过CALC_THROUGHPUT()或者CALC_THROUGHPUT_WITH_STARTTIME()语句中灵活应用CASE_START(), FIRST_OCCURRENCE['activity'], LAST_OCCURRENCE['activity'], CASE_END() 来实现获取案例中某特定节点到另一特定节点的时间差值的计算。
通过第一次发货到最后一次清账的间隔时长计算,得到了每个订单发货后到收款前的阶段时长。此例中可看到最长的订单在耗时111.74天才在发货后回款,这可能会影响到企业资金链,小型的企业甚至抵御不住1个月的资金链断裂的危机,客户的回款管理对于企业的财务状况而言非常重要。
3. 计算每个案例中某一活动的用时时间
对于有活动开始时间与活动结束时间两列时间戳的数据集,计算案例中活动的用时在效率分析中更加准确。
通过节点用时计算,可定位全流程中耗时最长的节点,在不考虑其他因素的情况下,我们可以视其效率较低。根据节点的业务意义,针对性地提出提高效率的方法:比如流程中节点设置不合理,可能是工作内容不该由目前的人员来执行,也可能是节点的流程位置设置不对,导致节点的工作内容中涵盖返工或者信息不全,需额外花工时沟通掌握全部信息等。对于同一节点,也可横向对比该节点的操作人员的耗时长短,用于评估该人员的工作效率高低,进而下钻低效的根因。
4. 统计多个案例的吞吐时间相关指标
以不同维度为分组去统计吞吐时间在效率分析中是必要的,从整体层面到分组的层层把控,既有助于横向对比各组表现,也有利于定位痛点层层下钻。
通过时间趋势上的统计,可看到案例的吞吐时间在略有波动的逐月下降,效率在逐月提升。企业在2019年11月实施新的流程管理措施,在最初实施的11月平均耗时101.09天,时长不降反升,一度让流程管理部门感到迷惑与沮丧,但12月平均耗时86.31天有大幅度下降,下钻分析原因,原来是实施初期员工对于新流程不熟悉,出现较多的误操作情况,熟悉新流程后效率大大提升。
在一个采购订单中有多个发票是常见的情况,统计一个采购订单的清账周期(从收到发票到清账的用时)的时候不能简单地计算清账的最晚时间与收到发票的最早时间的时间差额,更合理的计算方法是根据发票号统计每个发票的清账周期,再把同一个采购订单中的所有发票的清账周期加起来得到一个采购订单的清账周期。在没有发票号的情况,也可以尝试用相应的活动配对去计算——例如第一次收到发票与第一次清账的时间差值对应第一张发票的清账周期,第二次收到发票与第二次清账的时间差值对应第二张发票的清账周期等。
更科学地计算一个采购订单的清账周期,能帮助企业在资金规划上可预测性更强,对于未来的资金状况更有把握,关系的不仅是资金链的存续,更是企业短期规划时的经营方针:富余的资金不仅可以用于企业日常运营,也可以多渠道短期投资。
1. 有发票号的时候,根据发票号计算发票的清账周期
当有发票号时,计算同一张发票号中从“收到发票”到“创建清账凭证”的时间差值,作为该发票的清账周期。所以,此例中caseid1的发票号100从收到发票到创建清账凭证的时间差值是8天。在下图中,同一发票的对应活动“收到发票”和“创建清账凭证”用同一颜色标注,方便观察。
2. 没有发票号的时候,假设根据匹配活动后计算发票的清账周期
如果没有发票号,假设一个案例中第一次“收到发票”和第一次“创建清账凭证”都是在针对第一张发票操作,所以将两者的时间差值作为第一张发票的清账周期。在下图中,同一发票的对应活动“收到发票”和“创建清账凭证”用同一颜色标注,方便观察。
任何流程在运转的过程中都不可避免地会出现变更或是修改,变更活动本身或随即而来的其他活动从表面看会增加流程运转的时长,但不可一概而论——如果是推动流程进步(比如规范化)的变更其正向影响需要跟其增加的时长综合考量。由此,对于变更的分析与管理便应运而生。
1. 分析每种变更都发生在什么时候
此例中通过统计修改类活动的上一节点(变更来源),来观察什么节点后经常发生变更。在此例中,“修改订单数量”经常发生在“创建销售订单”之后,如果以后创建销售订单的时候更谨慎,在确定订单数量之后再创建将大大减少此类变更。
2. 分析变更发生的频次,其对案例吞吐时间的影响
2.1 根据案例中是否有变更活动分类,观察频次及吞吐时间
如果案例中有发生修改类活动,那么则视为有变更活动的订单,将订单据此分类后可对比有变更活动的订单和没有变更活动的订单的数量占比与案例的吞吐时间。可以观察到有变更活动的订单的案例平均吞吐时间更长。
2.2 当两个活动间有修改活动时,观察频次及吞吐时间
此例中观察如果在两个特定的节点中间有修改类活动出现,其对时长的影响有多少。如下图,如果在创建销售订单之后,进行修改类的活动(“修改订单数量”, “修改订单价格”, “修改支付条款”, “修改货币类型”这四种修改类节点),对创建发货单时长的影响。
从销售订单直接到交货单平均耗时15.73天,如果中途有变更活动,其平均耗时会延长至36.35天,增加了20.62天的耗时,可从此例中看出,变更分析对于企业业务的时效性是有很大积极意义的。
3. 分析不同变更导致的额外用时
此例中探寻如果发生了变更活动,变更活动会造成的额外用时有多少。通常情况下,我们将变更活动的用时以及变更活动结束后到下一节点前的等待时间相加考虑为变更活动的额外用时(下图情况1),但如果变更活动是一个案例中的最后一个节点,那么就只是变更活动的用时,没有了之后的等待时间(下图情况2)。
此例中,平均每次变更造成的额外用时是20.46天。在四种修改类活动中,“修改订单价格”造成的额外用时最多,平均有29.70天,在流程中对于订单价格需要更规范的管理,尽量减少该方面的修改。另外“修改订单数量”的出现频次很高,也造成了平均多花19.14天,也需要对此类修改更为注重管理。
权责分配是指企业根据其经营战略、生产经营的特点、组织结构的设置和内部控制的要求等,在工作分析的基础上,明确各部门或岗位的工作内容、工作职责和工作权限的过程。权责分离管理渗透在企业的运营过程中,如:业务与会计职责分离,财产保管与会计职责分离,交易权与财产保管权分离,会计内部职能分离等。此例中以简单的示例:发起“请求审批”的部门和“审批通过”的部门在权责分离管理中必须是不同的部门,统计不符合该条权责分离管理规定的案例数量与部门表现。
此例中A部门没有违规操作,B部门在3个订单中2个订单都违规操作既发起“请求审批”,又“审批通过”。审批的目的是为了监督、审查和决策,如果发起“请求审批”和“审批通过”的人员是同一人,那么其监督和审查的目的就无法达到,这个违规流程的背后不仅有其中人员工作的疏漏,还暗藏着舞弊的漏洞。
流程智能从此刻开始
关于流程挖掘
产品
解决方案
资讯中心
关于我们