随身听第29期：大型动力制造企业配件保障系统优化：图计算在复杂制造业的应用案例（下）
上一期随身听来自点春科技的CTO及副总裁王福强老师介绍了图数据库及其在制造业的一些应用。今天王老师将针对具体的项目进行分享，该案例以建国初期就成立的老牌大型动力制造企业为例，下面我们就一起来了解该企业如何利用图技术提升售后服务的效率和客户体验吧。

项目背景

该公司是建国初期就成立的大型动力制造企业，在国内相关领域排行前三，是国内非常老牌的制造企业。这次项目其实主要是解决他们的配件保障售后服务体系相关的问题。

我们从两个维度来讨论这个项目的痛点：技术上

首先是数据孤岛问题。我们这次主要介绍的是售后保障的项目，那售后相关的数据全都分散存储在各个系统中，例如客户订单系统、工程变更系统，和生产订单管理系统。因为历史遗留问题，很多数据的完整性和数据质量相对较差，而且数据之间的关联关系是割裂的。并且其数据量很大，计算逻辑也很复杂。

从业务角度来看，有以下业务需求痛点：

1、因为前面提到的数据孤岛问题，现有的订单BOM、物料BOM等信息，包括替换物料的关联关系信息（比如A物料可以被B物料替换，B物料可以被C物料替换等）在系统中的维护情况也不明确。而且，在EBS中，维护替换关系都只是物料之间的替换关系，没有准确的按产品之间的关系进行维护，导致替换关系不准确。那前端售后服务业务部门在服务时可能会选错零件。在给客户提供配件咨询服务时，就需要大量的人工查询和确认工作。比如，首先要到各个系统中查询相关数据，要反复进行人工确认等，非常耗时耗力。
2、装机量（产品销售量）是根据库存领料统计，由于领料数量不准，计算结果偏差大。
进入量（不同地区的销售情况）需要人工将产品进入各地首保和维修信息进行汇总，因为没有集成上游CRM等的服务信息，服务订单BOM信息及按配件类型的储备信息，也无法准确估算配件的进入量和储备量信息。在配件保障方面，数据查询就会很慢、不准确。举个例子，客户电话咨询是否有某个配件和什么时候可以到货，售后服务人员需要查询几天甚至一个月才能给到准确的回复，这样的服务质量对客户来说其实是不可接受的，会让客户体验很差。
这是整个项目的业务背景。下面是我罗列了一下这个项目的关键数据。因为企业建立较早，前期数据不完善，所以本次项目针对的是企业最近20年的产品数据。

项目关键数据

一共有10W+的产品型号。这个企业比较特殊，产品型号很多，有些型号产量只有几台，有些则生产了几千台。 订单总量大概有70万单，产品销售了大约有700万台，涉及的数据处理总量约56亿行。
配件保障项目数字简报

这里我也简单解释一下本次项目涉及到一部分名词，方便后续的理解。

备件BOM：是本次项目的产出品，就是服务BOM。
订单BOM：无层级BOM行清单；
二次件：类似树状层级BOM行清单；
组装件：专卖手工组合BOM行清单，基本是一层父子结构 。
备件BOM由（生产）订单BOM、 二次件和组装件组成。

替换件： A部件可被B替换， B可被C替换，C可以替换B，A，属于无条件替换。 或者，C只可替换B，不可替换A，而需要添加额外配件才能替换的属于有条件替换。
公差件：在一定误差范围内，可以互相替换的料件，比如垫片。
装机量：相当于销售量，这里主要指当前年份装机明细。
进入量：某个地区的产品销售量和流入量。流入量指的是比如在苏州销售，但在上海使用，这算是上海的流入量。
制造业名词解释

接下来就跟大家说一下本次项目的三个目标：

1. 配件的精准查询：

由配件识别、配件快速定位、深度定位、替换件定位、组件定位几大功能构成。主要解决前面提到的配件查询慢、不精准，所带来的客户体验不佳等问题。

2. 配件保障支持能力：
配件计划保障功能业务蓝图设计。由总部装机量、总部储备量、区域进入量、区域储备量几大功能构成。该企业的配件保障需要一定的预投放能力，例如，在上海有1万个产品，根据每个产品的保障比例进行规划。例如，像经常需要替换的产品，1万个产品需要20%的保障量，就需要2000个这类型的配件放在上海分公司进行配件保障。另外还需要根据装机量、区域进入量、区域储备量进行综合的计算分析，从而得出每个地区的配件保障规划。

3. 知识问答，也就是简化版的知识图谱：
用户使用微信小程序或客户端咨询问题的时候，使用语音或文字提问，系统根据语音或文字输入提取关键字分析，系统自动回答问题。

该配件保障项目的整体架构：

主要是将SAP、TC、工程变更系统、QAS系统、EBS系统等系统数据，经过数据的清洗、加工，及关系的识别等等，再由设计BOM、生产BOM、工程BOM等，生成服务BOM，提供售后支持部门的配件精准查询 ，和配件保障活动。
因为前期对客户的数据和业务流程等理解得不透彻，所以走了一些弯路。在最开始实施的过程中，我们是采用了关系型数据库的解决方案，就是使用MySQL作为数据的存储与加工平台，数据的清洗，加工，及后期生成服务BOM，都是在MySQL关系型数据库中进行的。
通过生产订单BOM，对数据进行清洗和打标签，针对不同的数据，打不同的标签，以便于后期进一步处理。整个过程还是比较繁琐、复杂的。比如，从生产订单BOM过来的数据，要对数据进行标注，这是哪个系统过来的数据，这个是成品，还是组装件，还是虚拟件，针对不同的类型，后面会对应不同的处理逻辑，等等。
下面这个图是我们的业务处理逻辑，我们可以看到从原始数据表开始，经过一系列的JOIN、查询和前面的标签过滤，生成中间表，再JOIN其它不同的表，再生成中间结果表，这其中就有物料信息表，里面有各种各样的数据标签，通过这些标签做数据分析处理，由此产生前面提到的新品投放量等结果数据。
物料基础信息组装
由此可以看出，利用关系型数据库做这个项目，会产生很多关联关系的操作来过滤和打标签，最终才产生相应的结果。
装机量计算
这是装机量计算逻辑，这个物料信息表就是上一步我们计算出来的中间结果表，再跟原始信息表做join，进行打标签的过程，这中间又会产生很多中间结果，最后才会得到我们想要的结果。

上面简单介绍了一下利用关系型数据库为存储计算平台的方法，这里面主要有以下几个问题：

1、计算效率低。大家也可以看到，在数据抽取的阶段要进行数据打标签，在数据处理的阶段，要对数据反复进行JOIN，根据标签进行过滤等操作，最后才能得到想要的结果。这个计算效率还是比较低的。

2、数据量大，需要分库分表进行集群化。因为数据量比较大，约200G的原始数据，几十亿行的数据，在进行大量的JOIN操作时，数据库的压力也是非常大的，性能也非常不好。这时，我们就考虑了分库分表的操作，根据不同的年份，不同的产品数据，分散到大约10台Mysql数据库进行操作。这样性能才得到缓解。

3、因为业务逻辑经常变化，销售数据，生产数据也是不断在更新，数据就需要重新计算，传统关系型数据库解决方案，需要全部跑一遍计算逻辑，这些重复计算，耗时耗力。在第一版程序上线前，我们测试发现全量数据重新计算需要接近一个月时间，这是不可接受的。后来经过一些建索引等优化，可以在大约5天时间跑出来。这个时效客户也不是太满意的，因为客户的数据变化其实是比较频繁的。
利用关系型数据库为存储计算平台的方法的痛点

因此，我们决定重新做解决方案。最终，我们选定TigerGraph图技术来解决这个问题。

因为，经过内部技术讨论，发现图数据库天然适合这类的场景。比如说，产品和产品的关系，订单和产品的关系，订单和地域，产品和物料的关系，物料之间的替换关系，物料之间的层级关系，这些组织关系就很适合用图数据库来表示。
前面提到的，像变更关系的变更，我们之前用关系型数据库做的时候，如果有新的变更关系，原来的a变成b，原来没有这个关系，我们就需要全部更新到BOM系统，数据全部重新跑一遍。而在图数据库里面，只用插入和修改这个关系就好了，不需要大量的重复计算。
针对客户的业务场景，做了一个简单的图数据库建模（如下图），订单和产品之间，产品跟物料，物料和产品型号，订单属于哪个集团，这里面还没有加订单和地域之间的关系，物料之间的层级关系，变更关系等关系。
制造业图数据库建模
数据导入也是非常简单的，在原始的系统里面很多数据的关系虽然有，但是如果用关系型数据库去做，容易有数据孤岛和数据之间关联关系割裂的问题。 而用图数据库，只需要把数据导入到对应的地方，把关系导入到对应的边，就非常容易构建模型了。这张图就是我们实际项目中导入的模型的一个示例。
制造业数据导入
还有像配件的精准查询，我们也是通过非常简单的GSQL语言来实现。GSQL语言可以写成接口的方式，方便上层应用（配件保障系统）做一些数据的调用和查询。
图数据解决方案——配件数据精准查询

最后总结一下经过后期改造，应用图技术之后取得的收益：

1）原来大约有10亿的库存资金占压，预计可以减少20%以上。前面提到客户是需要做一些配件的预投放，因此会有库存资金占压的问题。因为之前的流入量、进入量和变更关系在系统里面的数据并不准确，导致配件保障有很大的问题。客户提到，2019年他们的库存数据占了10亿的库存资金。例如A配件变成B配件了，但是售后服务人员在查询A配件时，发现A配件已经没有库存，实际上这个A配件已经变成可以被B配件替换，但是这个替换关系没有在系统里面更新。这就导致工作人员继续下单A配件，生产了一堆A配件，而B配件却没有被消耗，导致库存的积压和浪费。而如果用图技术来解决这个问题，预计可以减少20%以上的积压。

2）原来配件相关的查询工作需要3天到1个月时间，现在可以做到即时查询出备件备品。只要输入某一个产品，某一个型号或者产品编码，基本可以做到即时的查询。

3）对备品备件的生产投放，可以做到心中有 “数”。比如，某一个产品在一个地方到底销售多少，流入多少，根据不同产品的不同投放量，需要做多少的配件保障，可以做到心中有数，而不只是根据资深人员的经验“拍脑袋”做决策。

4）技术维度上，计算效率相对关系型数据库要高。因为涉及大量关系的计算，图数据库要比关系型数据库更合适。我们用MySQL方案来解决的时候需要用十台机器做集群才能解决，而使用TigerGraph单台就可处理所有数据。

5）数据不需要重复计算，只需要针对需要的部分进行变更操作就好了，计算量大幅减少。原来五天才能完成的计算工作，4小时内就可以完成，效率提高近30倍。
经过后期改造，应用图技术之后取得的收益

本周四直播倒计时：如何利用图技术提升银行APP获客和网贷反欺诈及监管能力？

本期图课堂课程将详细讲解如何基于TigeGraph图数据库灵活构建网贷申请客户关系网络，实现规则参数自适应调整，帮助网贷欺诈案调人员快速、准确地识别欺诈客户，并基于预警能力，拦截欺诈风险。同时，利用图数据库进行贷后非现场验检和贷后复盘审视总结，优化后续贷款规则和流程，识别欺诈惯犯和团伙。
直播时间为9月29日周四上午10:30-11:30。
直播报名

相关资源

TigerGraph Blog

分类

最新帖子