大家下午好，今天给大家伙儿一起来分享一下玉柴的数字化转型过程，以及整一个完整的过程中我们会怎样使用低代码。

  首先介绍下玉柴的概况，玉柴是做传统的汽油发动机起家的。后来国家汽改柴，国内第一款汽油改柴油的发动机就是玉柴生产的。我们现在也做了几个大板块，商务车、客车发动机，IDC的发电机组，船上船用的发动机、农用机械的，工程机械动力系统也都是我们的经营事物的规模。我们现在沿着整个发动机制造产业链，也延伸出了物流供应链的服务。同时，我们的发动机型谱应该也是国内最全的。

  我们的数字化，是在公司的整一个战略转型下去做的。我们定义要做独立的专业动力系统的供应商，因为我们跟其他的厂家不一样，玉柴是独立的发动机厂商身份，我们不与客户去争抢市场，而是作为背后的动力支持。整个玉柴 1235战略里面跟数字化紧密相关的是两个点，一个点是新能源动力，另一个点叫“做全 做新 做强”。

  首先新能源动力，因为新能源实现了电子控制，它比基线控制更精准，在这之上会衍生很多IT需求。比如我们现在做农用机械的无人驾驶，为什么原来做不了？因为原来是手动挡变速箱，我没办法控制它。现在我们通过新能源混动的自动挡变速箱，可以很精确地控制它，并且电力的控制会比机械的控制更精准。所以现在我们有很多的控制程序是写在发动机上面的，整个数字化转型跟动力系统结合就更紧密了。

  第二是做全、做新、做强，它指的是我们要进入更多的领域，出更多的产品，拓展更多不同细分市场。比如说像农业动力，像小麦机、水稻机、收割机，是这种类型下不同的细分市场。但有很多细分板块里的应用，对玉柴来说是不明确的，不可能会提出明确的需求，只能边做边摸索。所以在数字化转型过程中，我们应该降低试错成本，包括时间成本和金钱成本。如果“错”是不可避免的话，那就降低“错”的成本，还要从“错”里面汲取知识。

  所以能够正常的看到玉柴的数字化战略，就是要帮助业务流程创新，同时帮助产品实现智能化转型升级。

  这也是今天早上杨总的分享，为什么我们从传统的信息IT部门，合并了企业管理部做业务流程咨询，然后又把战略、情报、人力、投资又拢在一起，变成一个运营管理线。目的是希望公司从战略、到业务流程、到执行、到IT的落地都可以在一定程度上完成企业数字化战略。从这一块我们会看到会关注运营效率，关注运营效能、关注客户体验以及关注业务创新。

  第一，关注运营效率。我们现在跟业务人员去聊IT需求的时候，我们不再说要什么功能，有几个表单，分别是什么按钮。我们把它变成：你现在提的需求与你板块的哪一个业务指标相关？比如说部门周转率、客户的响应速度等等，我们把它变成一个个的指标，然后把指标在公司的指标数里面去做关联，去看这个指标到底能支撑和关联公司哪个顶层指标，以此来判定这个需求的合理性和紧迫性。所以我们企业内部运营管理，关注运营项目，我们会把几个大的业务流程全部数字化，用数字化的报表或者驾驶舱来反映公司运营的效率与情况，然后再根据运营效率情况去与各个业务部门板块所提的需求来做关联，来降低需求乱提，以及频繁更改的可能性。

  第二，关注运营效能。这部分内容关注的是玉柴与客户、与伙伴上下游之间的关联。我们大家都知道整个企业，特别是离散制造业，光在企业内部做数字化转型，做得再深、再好，都会有个瓶颈。经过这几年的数字化转型，现在我们更关注的是跟上下游领域的协同，不仅我本事强，我还要让我的供应商，我的客户跟着我一起强。我们现在做了几个部分的尝试，是关于生产计划的协同，物料配送的协同、服务的协同以及零部件设计的协同。我们大家都希望打通这几个模块，能够把库存件量减少，同时也帮助供应商去把物料配送到我们的生产线来的时候，能够降本。

  第三，关注客户体验。这也是这两年来投入很大的部分了。具体来讲就是我们大家都希望在客户使用玉柴产品的时候，跟他发生关联关系。后来我们得知，一个装在车里面的东西，凭什么跟客户产生关系？于是我们痛定思痛，我们把客户定位为最终端的使用者的同时，把数字化能力嵌入到主机厂，就是买我发动机的整车商品，然后再通过他们的APP跟客户产生关联。

  举个例子，现在我们和某汽车企业在大力合作，把发动机的运行工况与整车的运行工况拼在一起，作为一个数据模型提交到车队用户使用的APP里。客户就能够用这APP看到他自己车队运行的行驶的速度、油耗，比如是否有突然的油耗下降，有没有偷油的可能，国内排放是否有超标的痕迹，它在长途运输的时候是不是需要定制一些省油的服务。我们也根据路况、海拔的不同，根据发动机运营区间灵活地调整发动机运行的模式，来使整个发动机运行更加节油，把它变成一个节油的服务产品，提供给我们整车的客户使用。

  最后，关注业务创新。刚才说了很多新的系统，很多时候都搞不清楚到底怎么做，那我们会通过数据去支撑。第一块是现在基本上所有的产品研制都会进行仿线年跟华为做了IPD的咨询，构建了需求管理平台跟项目管理平台这两大平台，把客户和用户的实际的需求，收集在我的平台里面，以后跟我产品的模块的设计去做关联关系，以此来判定我的客户的真实需求有没有落到产品上，我产品承接以后有没有实现客户的价值。现在能够正常的看到很多新的市场里面我们都做得很不错。像原来玉柴从来没进入过起重机市场，经过将近小三年的IPD的试点以后，我们现在目前在起重机市场已做了78%，成为客户的主配车型了。这个是我觉得业务创新比较成功的尝试。

  这么多创新，离不开一个坚实的数字化底座。这块底座也来自于我们跟得帆的深度合作，我们把它定位成“玉柴云生态圈”。实际上还有很多得帆提交给我们的基础能力。因我们玉柴在很早以前就跟得帆合作了，我们的SOA，我们的门户都是得帆以前做的。

  现在我们在构建这个生态圈中也引入得帆，得帆低代码aPaaS、iPaaS产品也有所使用。我们应该让得帆的整个技术成为玉柴生态圈的底座，用这个底座去支撑业务创新，去构建若干个APP。这些APP可能上线了半年，一年后会干掉。没关系，只要我的投入成本足够低，那么他试错，该干掉就干掉。一旦使用量很大了，我们就持续投入。这也是数字化底座来给我们大家带来的价值。

  这里我分享两个低代码在玉柴的应用。低代码第一次进入玉柴的时候，其实IT人员是很反对的，他觉得低代码实现是不可能的。

  我们那时候讲先去尝试一下，所以我们就用试验平台来去做尝试。这个试验平台做的是整个发动机的试验室的管理。在装配完成以后，所有发动机都要上台架进行热视。比如你要装上油管，装上润滑油、柴油，跑起来运行一下，看行不行。

  每年玉柴大概生产40万台发动机，但是仅有100来个台架，资源是非常紧缺的。特别是新产品开发的时候，台架是抢来用的。以前出现的情况是发动机放到台架上，我本来预计一天就能跑完试验，结果因为某个零部件没到，它一直占在那里，别的机器排队也不能上去。

  所以试验室的目的其实解决资源跟试验之间的不平衡关系。我们也做了一个小小的尝试，在平台整个开发过程里，IT人员参与的角色发生了转化，变成了老师或者业务顾问，实际做试验平台开发的人员是试验室的业务骨干。我们经过得帆低代码培训以后，去给试验室的管理人员做培训，由他们依据业务经验尝试做一些设计，尝试做一些模型。公司对这一个项目没有投资，纯粹是试验室的领导愿意跟我们大家一起用的得帆低代码来尝试构建和他们自己的管理平台。

  从22年3月1号开始，我们做了开发需求，成立项目组。在22年的5月25号，慢慢的开始试运行了。现在目前二期的迭代开发已完成了，在22年11月份上线功能。整个试验平台做的东西挺多的，包括计划、验线、订单、任务准备、台架试验、机修等等。这些功能全都不是IT人干的，IT主要负责设计系统的架构，梳理业务的流程。里面所有功能开发或者拖拉拽部分，都是我们业务人员自行拉进来的。这有几个好处，没有人会比业务人员更懂他自己的需求，更懂他的痛点。那么他们自己做出来软件系统，他们用起来心里更舒服。他们也尝试给一些功能去命名，比如说某功能以人名命名的，或者小组命名的，要求冠名权，自主性很高。

  从这个项目我们正真看到，低代码确实能够在这种应用场景里面激发业务人员的主动性和积极性。同时业务人员深度地参与了试验平台的开发，所以试验平台自我迭代能力非常强，需要变更的时候，我们要求走IT流程。业务人员现在也能够习惯或者适应，功能变更或业务流程变更的时候，我需要提需求，仅仅是他提需求服务台帮他解决架构网络，他自己去拖拉拽，然后再测试。动作是一样的，只是完成人员由原来IT人员变成了他的业务团队，你们可以理解是变相扩大了IT的实施团队。

  22年精益试验平台功能上线完成以后，它也开始向IPD团队灌输了，这部分内容跟整个IPD变革相互绑定。以前可以不花费用，不花成本占着试验台架，现在不行了。财经会给你算，你占了台架，到底花了多少钱？做什么试验？你要多少钱做这事情，会记录到整个发动机小组研发成本里面的。

  精益试验平台通过计划的拉通协同，跟用得帆的平台去构建出的产品研制项目平台做深度对接。由整个的项目计划延展出试验计划，选出试验清单，去回顾这些试验清单有没有符合需求管理平台里面的实现要点、成长要点，做一个打通，以此来实现整个试验平台的顺畅的流转。

  在这个过程中，试验室的骨干人员，他们都是在现场和我们大家一起联合成立项目组，去做这一个项目。这样后续解决了很多事情，包括后续的宣传、后续的推广、后续的培训，几乎都不需要IT人参与了，只是试验中心的骨干自行给试验的工人去做培训。

  这就是整个精益试验平台的试点过程。在这里玉柴摸清楚了一件事情，低代码在相对简单的应用情况下，由业务人员来拖拉拽简单的业务，是可以在一定程度上完成业务需求的。我们证明这一点后，又进行了更复杂的一个项目。

  更复杂的项目是玉柴的售后服务系统，它是从2022年8月份开始，为什么从这一段时间开始？因为我们在22年前期试验了低代码平台的可行性，所以在8月份我们决定用得帆低代码作为本次构建的主打技术底座。

  这个售后系统呢，给大家做一个简要介绍。玉柴的服务应该来说是行业内口碑比较好的，我们在全国有将近4000家服务站，你只要打电话要求发动机的服务，不管你在海南岛，还是在吉林，还是在新疆，两个小时内一定有人上门做维修。这么复杂的一个业务场景下，我们应该考虑不同地方，比如说西藏、新疆这种地域，白天出去的费用、晚上出去的费用、夏季出去的费用、冬季出去的费用，费用结算模式也复杂，业务流程也复杂。

  整个玉柴售后服务系统不是第一次做了，我们已经历了每三年一个迭代。并且玉柴现在也分成了很多经营体，像我刚才介绍的船用的、公路用的、农用机械板块、车机械板块，每一个的管理模式的业务流程都不一样。这个售后服务系统能覆盖这么多不一样的产品，那么多公司主体。

  它的系统架构、业务流程中，最大的就是服务订单，所谓服务执行，包括有买断的服务，就是我卖完以后不能再出来。还有持续给的服务，以及旧件服务结算、服务索赔，适应的各种各样服务站，有新建站、二级站点、服务站的协议。下面是主数据、物料主数据、客户主数据、共享主数据，还有价格数据、产品档案、物价工时信息、质保信息等等。整个售后系统，跟玉柴的所有系统都有关系，OA、SDP、ERP、EBS、ESI，还有我们下面的公司。不同的公司、不同的主体、不同业务流程、不同的服务结算套路、不同的服务结算流程，都不一样，它非常复杂。

  我们下定决心用低代码来重构整一套玉柴的服务体系。希望重构完以后，能够更敏捷地支撑玉柴的服务系统，也更能去适应不一样公司、不同的业务流。

  售后服务系统应该说倾注了绝大部分能力，它看起来是一个售后服务系统，它的背后包括了低代码aPaaS平台和iPaaS平台，这两个平台深层次地融合。那么因为玉柴使用aPaaS的时间相对来说比较早，所以我们在本地数据、华为云、微软云上有一个版本的，都有几个大的版本,这几个版本都还不一样。我们也是趁这一个项目把承载过这么多的版本做一次刷新，把整个技术栈统一的用户门户重构一次，把原来在Oracle上实现的内容抽出来。所以它看似是一个售后服务系统，它实际上背后代表的是整个业务流程的敏捷化的架构，以及所使用的标准技术栈的迭代和升级。

  讲那么多，能够正常的看到玉柴售后服务系统的目标，瞄准的是玉柴数字化转型中的提升客户满意程度。我们大家都希望未来的客户在无论天南地北，啥地方呼叫玉柴服务，都能精准地导向到你产品所属的公司，能够精准地拉出产品所属公司的业务服务流程，能够精确地计算出这台车何时到服务站、何时修好，以及修好大概会使用多少配件，这些配件价格是多少、工时多少、材料费多少、维修时间多长，能给用户很精准的反馈，方便用户在不同时间、不同地点进入到全国各服务站的时候，都能享受到同样的服务。通过数字化转型方式，结合得帆的技术能力，让我们的客户在使用或者体验会有升级的感觉和“尊贵VIP”的感觉。

  最后我做一个小结。技术作为公司的底层架构，它需要有一个团队去实现。我们成立星网智云的目的也是围绕这个目标。现在星网智云里面，已经不全是IT人员了，还包括了业务人员。我们这样做的目的，就希望把技术这么一个晦涩难懂的东西，放在业务系统的背后，让我们广大的企业用户也好，社会用户也好，接触数字化的服务的时候，不需要去关心后面复杂的逻辑，只需要几个界面跳转就实现功能。

  对企业内部的使用者来讲，可以不再去关心技术对我有什么影响，这一些内容都由数字化转型的团队帮你实现。像试验室那种简单的、拖拉拽就能实现业务流程的，我可以把工具给你，由你自己实施。对于复杂的、大型的、多变的，那由信息化的团队来跟大家一起梳理业务流程，选择工具快速敏捷迭代。

  我们数字化的方法论也开始变化。现在我们基本上要求两个月到三个月一定要出一个迭代，一定要上线一个对用户有意义的功能。也逼得我们的产品经理，产品线的业务顾问，他会绞尽脑汁去思考，我怎么样能把这些功能能够快速的上线给用户使用，也会逼着他们去尽量使用一些与技术不那么大关联的东西，不要动不动上来说全部手敲代码去实现。

  这也是为什么我们在企业内部先做小范围的尝试，再做大面积推广。产品经理也好，运维经理也好，我们都要求大家去做大面积的培训，参加低代码的考试。因为很多时候我们得知只有自己学过了、用过了、了解了，在他的业务过程中，在后续的使用的过程中，他会才会不自觉地去想到去应用低代码技术。

  我们也希望，能够在未来的时间里更多地跟得帆加强技术方面领域的合作，把得帆在技术能力的优势发挥出来，把玉柴以及星网智云在业务咨询，在业务解决方案设计的能力发挥出来，一起去为玉柴、玉柴的上下的供应链以及别的客户去提供数字化转型的服务、信息化的服务、IT的服务！