今天由我代表作业帮来介绍公司在低代码平台应用的一些经验和心得。我今天分享的内容包含两部分，一个是作业帮硬件的介绍，另一个是基于明道云的系统能力建设，也是我们自己总结的经验，希望能给大家带来一些启发。
一、关于作业帮
作业帮成立于2014年，在整个业务周期至今，其实已经做了很多业务线。其中两个点是涉及到硬件部分：第一个是2018年，作业帮收购了喵喵机。喵喵机是一个以热敏打印机产品为切入点，切入到错题打印，也就是学生这个场景下的硬件产品。第二个是2021年，作业帮自己做了一套硬件产品生态。在2021年双减政策出台之后，作业帮更多地倾斜到硬件产品上。目前，作业帮以作业帮硬件和喵喵机作为硬件的双品牌战略。
二、需求背景
我们实际业务线是在2021年底才正式上线，面临两个比较大的问题。左边是我们的业务量，右边是我们的业务场景。大家能看到业务量是一个爆发式增长的状态。随着业务增长，我们需要做的系统支持的内容也会越来越多。所以就面临了这两个核心的业务问题，一个是高速增长，一个是场景膨胀。
三、基于明道云的业务系统能力建设
建设方案
基于这两个问题，我们其实一直在思考到底如何快速支持业务的发展，以及如何满足复杂的业务需求。在使用明道云低代码平台之前，我们主要有两种产品形态，一种是自研，另一种是SaaS服务。
但是低代码引入之后，我们面临了三个业务点。我们基于这三个业务场景做了一些分析：我们认为低代码更适用于产品的复杂程度不是特别高，并且需要有一个非常大的灵活属性的这种产品方向。然后SaaS的话，因为是行业内的比较标准的产品服务，经过了很多年的验证，我们认为可能更多地去满足复杂的业务场景。现在这个阶段，自研是一个非常高成本，但是能满足比较个性化需求的开发方式。
建设框架
我们画了一个四象限，把业务复杂度以及行业服务标准这两个坐标作为评估依据。基于复杂度低、无行业标准的这种场景，以及复杂度低、有行业标准，这两个场景下，还有一部分复杂度高、无行业标准的场景，用低代码建设，保证低代码的产品特性能充分发挥起来，解决高效、低成本做系统建设的能力。
剩下的是业务复杂度高，但是无行业标准的这部分，我们选择了自研。另一部分就是相对比较复杂的，比如说ERP、仓库管理系统，我们可能更多地用SaaS服务。这是我们大概的选品标准。
协作方式
我们总结了3种自研方式，一种是自研+网关+低代码，其实网关代表自研的一种衔接方式，第二种是低代码+网关+低代码，第三种是低代码+网关+SaaS。
第一种链路的话，我们认为它能满足特殊场景，对产品交互要求比较高。剩下两种，我们认为依赖SaaS服务以及自研能力，能快速支持业务定制化的场景。所以这三种链路其实在我们的开发过程中是并行的。
流程提炼
基于刚才的三个场景，我提炼了一个流程给大家简单介绍一下。因为我们是做硬件的，所以会涉及到一个售后的过程，它和传统电商的售后过程不一样。传统电商可能依赖于客服能力就做了，但我们有一些硬件产品，需要实际做售后服务。
在这套链路里面其实已经拆解出来了：用户售后服务发起之后，我们的客服人员以及售后人员进行服务受理，坏品会在售后仓进行管理，有可能会报废掉，有可能会进行这个工厂的翻新，也有可能会进行仓内的翻新。
这套流程里面有3个点，第一部分的话是用户端，这个是映射到之前体验的场景上；第二部分是服务端，就是我们自己内部流程的一个转化；另外一个是仓储作业，也是内部的操作作业的一个工作。
以售后服务端发起这个动作来说，它的场景用了“自研+网关+低代码”这种能力。用户需要在手机端发起售后服务，然后由我们的客服人员以及服务工程师去进行后续的服务受理。在这个场景下，用户侧对于体验的要求非常高，目前低代码平台其实无法完全达到我们对于用户场景下的使用诉求，所以我们是通过自研的方式，然后用自研的内容去和网关衔接传递到电话平台上，通过传递的结果去获取到用户诉求。在服务过程中会通过服务公式的处理返回给用户，从而打通这套链路的执行流程。
在这种执行方式下，我们能在保证用户体验的前提下，把系统落地的时效提高70%。正常搭一个售后系统的话，没有两到三个月的时间其实是很难完成的，而我们大概用了20个工作日左右。所以，整个项目下来，我们对于低代码是有一定感触的，而且项目成果在后面也直接帮助我们更好地在公司内部推广低代码平台。
下一部分是服务受理，这部分其实是用低代码+网关+低代码的这种方式解决了数据获取的问题。明道云提供了在流程以及页面中通过API方式获取数据的能力。我们本身有一些自研的表控能力，以及作业帮内部的系统，这些都需要通过API或者网关的形式连接到明道云。
第三种方式是低代码+网关+SaaS。对于我们来说，其实WMS服务相对复杂，除了商品本身的管理以及出入库以外，还涉及到调拨、盘点、库位以及正常销售场景下的链路打通。在这个场景下，我们将WMS的SaaS服务与低代码衔接，完成了这套链路的执行。
我们在实际使用过程中发现，这三种方式能帮助我们更快地建设系统，也保证我们能相对灵活地进行业务迭代。
接下来我会基于售后系统，介绍一下我们的产品结构。我们目前业务场景是退、换、修，基于这三个业务场景，涉及到销售平台的信息引入，OMS订单系统的一些信息引入。除了外部的OMS以及我们自研的OMS以外，还有一些CRM的SaaS，这些场景都会由明道云承接，来保证我们内部的工作流的流转。
标绿的部分是我们现在已经在使用明道云做售后业务场景的支持模块，标黄的部分是我们在尝试依据明道云能力去建设的服务能力。其他部分直接复用了作业帮自研的能力模块。
产品建设思路
其实我们是有一定产品建设思路的。明道云本身是以应用表单和工作流为载体的开发工具，但是对于我们一个相对传统的互联网公司来说，我们希望通过让系统结构、系统边界足够清晰的方式，来保证后续数据使用过程的稳定高效，避免重复迭代，重复地做重置动作。所以，我们用系统去对应应用场景、表单，业务流对应工作流。
举个简单的例子，还是以售后场景举例，因为我们有客服人员在做服务受理，有售后的工程师在做后续的执行动作，所以对于客服系统和售后系统来说的话，其实是相对解耦的一套系统，但是工作流又是相互串联的。
在这种情况下，我们通过工作流保证两边系统的数据一致性。各个角色在自己的系统下闭环，使得应用不会因为工作流内部的串联，导致各个岗位的工作内容解耦了。
产品结构
我们虽然是互联网公司，但也是一个制造型企业，包含产品设计、生产制造、服务履约和用户服务。在这个业务场景下，我们包含前、中、后台。前台可能更偏向于用户体验，会有很多的用户通过前台的端口来去获取硬件的一些服务内容；中台会有一些分发逻辑；后台是内部员工用的一套系统流程。
在整个流程过程中，我们用明道云进行很大部分的中后台系统建设，还有一些我们在验证中的方案，也是希望将来通过明道云来实现。
研发架构
明道云在我们的研发体系中，更偏向于底层的一些服务能力。它会通过网关的形式，和前中后台的系统做衔接。这种设计结构保证了我们的业务动作都能进行高速迭代。
建设建议
最后，我们希望给大家一些建议。我们认为：相对体验性的内容更适合自研或者使用SaaS服务，中后台的模块里，如果没有特别好的外部SaaS能满足的，以及相对复杂、变动较大的业务线，就很适合使用低代码建设。当然，我们对于低代码平台抱有很高的期望，希望后边能进行不断拓展它的应用边界。
四、从提供系统工具到提供工作模式
明道云已经能把用户的本质诉求，提炼成一套低代码能力。我们非常认可“人人都是开发者”这种观念，但是前提是做到了“人人都是产品经理”。
至于赋能，我觉得不只是工具层面的赋能。低代码平台其实是一个革命者，它颠覆了传统的开发逻辑，我们希望从整个公司的运营环境下去考虑低代码对公司的发展或者迭代有什么样的助力。
我例举了四个点，当然肯定不止这些：
- 在传统互联网公司环境下，我们如何配置团队来使用低代码能力？
- 系统建设的标准是什么样的？
- 如何完成一套低代码的履约过程，以及后续的运维方案？
- 在传统的运维基础上，我们怎么进行转化？
本文来自作业帮高级产品经理翟宇，在明道云北京开放日的分享，经校对编辑后整理为演讲精华。
