此篇先前发过，后来因为某些原因删了，今日偶然翻出再看，觉得删了可惜，决定再放出来留存。低代码平台用在销售、设计环节上还是很有帮助的，这能避免过程中许多不必要的熵增带来的低效。
以下内容 偶为戏言
如有巧合 请勿关联
高校里各业务系统的表格数字还没对齐，“中台”概念来了，说要“去烟囱”化，要“赋能”。在发现带头大哥悄悄的不再提及，不免有些慌乱，再把概念收缩到“数据中台”。在业务“数据孤岛”还并没打通时，“低代码”概念又来了，说要干掉程序员，把数字化的能力交还给业务人员。每一次，这些“运动”都似乎能成为2B的新风口，好象再不立马参与进去，就会错过数字信息化转型领域的变革。很多“玩家”，利用这个机会，再一次紧锣密鼓地进行商业化布局，如明道云、如阿里云、如华为云，如此等等，一众的“云车商”。
往前倒数到二十多年前，这都不算新鲜事。比如VB／VC，比如Delphi，这些工具比现在低代码开发环境的生产力要高出许多，能力也强大的多（一方面确实实现起来方便，一方面也得益于Windows操作系统的普及）。
时隔多年，“低代码”概念重新又热，这无非是用“低代码”的这个概念，重新封装了表单、工作流等能力，包装成面向业务应用层的低代码平台。那么，这个低代码的“点”是什么呢？操作可视化？提高研发生产力？用户能自行开发？… … 其实这些“点”在软件产品和服务领域，不能算是重点。
那什么是重点呢？在回答这个问题前，先思考下以下这些问题，其本质也就是方案要如何落地的问题：
(1) 低代码平台的用户是谁？
(2) 存有行业生态吗？
(3) 在业务价值链中处于何种地位？
(4) 从哪里获取收益？
这些问题若没交代清楚，代码量再低（况且，这个“低”也没法量化），又有何用呢？
下面来试着解答上述那些问题：
(1) 低代码平台的用户是谁？
低代码用户，目标人群有两类：一是开发人员，二是业务人员。
若是开发人员，那么其旨在快速开发，提高生产力，因此，可视化等等能力，都是实现这个目标的辅助手段。
若是业务人员，又分两类：一是甲方的业务人员（花钱的），二是乙方的业务人员（服务的）。服务软件的本质，是把业务过程流程化并以程序方式实现。因此无论是哪方的业务人员，不仅要非常清楚业务流程，还要具备些软件思维，方能更好的运用此类工具，而实际中，这恰是“短板”，哪怕是花了较大精力和时间去培训，也未必做的好。原因无它，有一点可以知道的，是无关乎KPI。
(2) 存有行业生态吗？
单就高校领域管理系统而言，目前仍未见有效的行业生态出现。原因有很多，私以为校方目前业务系统还是以招投标方式进行，且学校信息化基础建设并没有建成（相应的平台标准出台与规划缺失），很多基础公共能力没有定义和实现，这也导致最终的实现必然还是项目化、单体化、烟囱化。
(3) 在业务价值链中处于何种地位？
从服务软件的整个商业过程来看，包括销售、设计、开发、交付、实施、运维等等所有环节，其整体效率是这些环节效率的级连。而开发工具，只是软件开发环节的生产效率，在当下高校项目建设上，这并不能完全决定软件业务的成败。
试以设计和实施两个环节效率简单说明：
(a) 设计
通常，客户需求越多，设计周期就会相应延长许多，这对甲乙双方来说，都是较大的成本开销。甲方的心理是你们乙方号称是解决方案专家，那你们要推荐一个类似可行的业务方案，并在此基础上根据学校现状进行适配；乙方的心理是项目就是项目，你们要我什么姿势，我就什么姿势。加上双方业务人员沟通过程的某些“疏漏”，这就势必导致反反复复，改来改去。而这种反复，又导致开发人员的不断反复，效率级连降低。当然，有人要说了，双方业务人员的责任心到位、专业知识到位，讨论清楚再设计，完了再开发，不就没这么多事了。理是这么个理，实际却是：你懂业务吗？都是专家会不如你？你以为的只是你以为的。
(b) 实施
实施很重要的一个步骤是实施人员要对应用数据进行初始化，这也是最容易有问题的一个环节。一是大多学校数据治理不到位，数据质量不高，二是要求实施人员对数据来源要非常清楚。还有个较常出现的问题是新的业务周期到了，发现原有业务系统数据又跑不对了。数据不正确导致服务有问题，由此带来的影响，可大可小。至少从甲方心理上，多多少少会有些不耐烦。钱都花了，一个固定姿势都反复整不对。
吊诡的是，实施人员还常常身兼数职，比如“设计”，三言两语就可直接交与开发去实现，所谓“敏捷开发”。大抵唆过猪腰子，猪长啥样不重要，再不济手机上也见到过图片的。浮桥看久了，文德桥也不会有问题，反正都是桥。至于秦淮河上其它桥是不是能依葫芦画瓢复制，哪管那许多；正月十五那天桥会不会垮，到时再说好了，大不了临时加桥墩，再不行就限流，还不行就熔断，总之桥是万万不会垮的。
赵括为将，其父以为不可，其母以为不可，大臣以为不可，秦王知之，白起知之，恐怕是丽春院的姑娘也知之，独赵王以为可。大抵是属鞋匠的，挨着缝就能上；若是沾边潘驴邓小闲，就更好使了。
类似以上种种，导致甲乙双方最后都被折腾的精疲力竭。甲方花钱买了个不痛快，本以为是夫子庙的，原来却是珠江路的；乙方也不痛快，只花了珠江路的钱，还想整夫子庙的，又加钟点又加姿势，还不给钱，翻台率都整低了。当然，这过程还是很酸爽的，能时时有。
对于如何压缩上述过程中不必要的低效周期，目前看似缺有效的解决办法，至少我是不知能如何做。但有一点是能确定的，那就是“康威定律”在此过程中发挥着积极作用。那是不是招一个名叫“康威”的来祭天就成了？如同当初起明皇宫时，扔了个叫“田得满”的老汉到前湖里，方立起了宫殿。这招好不好使的，我不知道，我只知道幸好我名不是“康威”。
(4) 从哪里获取收益？
若只是考虑开发一个环节，收益是明眼可见的，即或可提升现有生产率，这个“或可”，是基于韭菜下锅炒前，都加工好了，无需再去洗切。当然，偶见黄茎，摘出扔掉就好。
那其它环节是否能得益呢？思路跳出来，把它放到整个商业过程中来看，或有可取之处。
(a) 销售环节
销售环节的长周期，对于甲乙双方来说，也是一种巨大成本。这种长周期高成本的主要原因，甲方需要花费一定的时间去反复了解，需各种POC（Proof of Concept）。而乙方常见的做法是，要么写一大篇PPT，说些模棱两可、高大上的概念；要么就是基于已有业务系统做做演示。这中间不管甲方提什么，都先答应。这个过程体现出的低效，是可见的。
这个过程，能否用通过低代码平台配置的方式，快速搭建近似最终方案的业务模型，加载演示数据（或者直接采用图片方式），实现快速的业务验证，从而改进销售流程、缩短销售周期呢？
对于甲方来说，其目的无非是验证要买的服务软件是否就是他想要的，确保不会买错，若在此过程中甲方能所见即所得，那么乙方的胜算也会更高。对于乙方来说，即使没有销售成功，及早撤退也能节省一定的成本。
(b) 设计环节
销售环节做的很多只是较粗的功能示意，到了设计阶段，设计人员会和校方业务人员进行深入沟通以便设计。同样的，这个过程能做的，除了常规要做的，还有业务流程的梳理，以及明确某些重要场景的细节。而这些都或可通过低代码平台去快速沟通实现。
(c) 开发环节
适用的低代码平台，在设计环节就能通过可视化方式画出页面或流程，然后由此生成对应的代码，适配对应的事件处理，从而节省一定的开发时间，提升生产效率。
(d) 实施环节
实施环节，可以通过低代码平台明确实施人员要做什么，怎么做。
根据以上设想，“低代码”或可成为多个环节的一种新组合生态。在这个业务生态中，各个环节都可以拆分或组合，比如销售、设计、实施等业务环节都可以独立进行。独立小团队或个人都能参与其中。通过业务环节的拆分和组合，每个参与者都能做自己最擅长的那个部分。比如实施，既可以自己实施，也可以由认证伙伴实施。
不过，这种众包的服务模式，在传统软件业务模式中恐不大可能做到，因为建设能力闭环可控才是信任的基础和按期交付的保障。
此外，还要面对业务的复杂度问题。大部分低代码平台能做到表单驱动和工作流驱动，高级一点的还可以做些业务建模。但是，无论哪种，都不能做到满足任意复杂度的业务。对于高校传统三大业务系统学工、人事、教务来说，某种程度上其业务流程、数据逻辑，基本有规范可依，其非核心业务，或可利用低代码平台快速搭建，如数据收集、如申请流程，等等。而有些场景，由于业务既不规范也不确定，常常需要调整的，低代码就不容易应对了。
“低代码”这个风口还能吹多久，不知道，谁能首先商业化落地或可做得吹鼓手。但这对于一个复制学习能力极强的一个环境来说，投入大再没有些壁垒，恐怕也撑不了太久，风吹过也就吹过了，本就是丽春院赎来做妾的。对那些不想花钱也想入非非的，吃吃韭菜炒鸡蛋就好了，想多了会睡不着，想太多更会失心疯。或许能靠臆想兴奋，但是胡僧药吃多了都会丧命。有这闲心，不如买只有工业大麻概念的股票，运气好的话，还能高潮。
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/171184.html