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