01
【先来说说背景】
低代码即「Low-Code」；
简单的说；
早先在数据公司时；
不过，当时还是以数据管理的工具来定义项目，并非是低代码；
2020年底」开始；
现在的公司，将「低代码」平台的使用「规划」到「业务体系」中；
正确的决策；
非核心业务全面集成到低代码平台中，将核心业务的边缘流程，以实践的方式迁出小部分到低代码平台中；
行业趋势」和「业务周期」的整体考虑，才做出的决策；
不过遭到技术部的「稍微」反对；
但是最终的讨论结果，出自部门老大的建议；
边缘业务」迁入，根据「效果」再决策后续规划；
以实践三年后的今天来看，人和人的「差距」确实挺大的；
Boss」层面的决策正确，「部门」层面的执行节奏，「员工」层面的后知后觉；
差距」；
02
【聊聊最初的疑惑】
客观来说；
排斥」情绪；
打破习惯」和诸多「不确定」因素；
主观来说；
技术部为何下意识的反对低代码应用？
否定」的因素；
问题1】平台选择；
如果只是常规的业务数字化转型，建议优先从大的生态选择，比如「某微」或「某钉」，相对而言会更便捷；
【问题2】成本困扰；
简单业务需求从整体协作去考虑，涉及的时间成本、人力成本、以及产品技术的维护成本；
客观的「数字」最有说服力；
【问题3】业务适用性；
所以针对低代码平台的使用；
这种情况下；
所以充分的调研，以及对市场上各种案例的参考，从而客观的分析公司当前的业务阶段，是否有必要引入低代码应用；
问题4】复杂后的维护性；
业务人员还是研发角色？
建议是由业务方将需求对接到研发团队，个人所在的组织中，是一个产品加一个研发，一起负责低代码平台的迭代；
低代码应用具有一定的使用门槛，在使用的时候需要遵循普遍的开发原则和规范，以此保证持续可维护性；
03
【简单聊聊原理】
如果是普遍的共性业务；
如果是行业特色的业务；
从技术角度进行原理的简单分析；
封装」能力；
后端，提供整体的模型驱动能力，封装不同场景下的公共的交互接口，从而实现各个模块的流程和逻辑；
【1】进行纵向的表结构设计，数据存储层面使用键值对的方式，构建搜索查询的逻辑比较复杂；
【3】数据还要提供基础的分析和导入导出能力，以及API层面或者数据通道的搬运能力；
追求功能的全面性；
04
【组织内实践案例】
3年」的实践；
认知」；
纵向」看；
角度没有问题，但是有点孤立；
横向」的从组织的整体来看；
这些普遍不会被集成到产品矩阵中；
信息化」和「数字化」管理，从而打造「标准化」流程；
横向」交集；
有的应用极具行业的特色，有的应用倾向共性业务的管理，有的应用倾向私域客群的维护；
最为关键的是；
对外」的「交互」能力，可以是第三方应用之间的交互，也可以是与内部的产品体系交互；
组织在实践近一年之后，各种核心的业务流程，都全面的信息化和数字化管理，并且从应用层面打通了不同业务的交互路径；
效率」得到极大的提升；
05
【实践带来的反思】
数字化」；
见识到数据层面可以挖掘的价值，智能化的分析决策流程，但是缺乏应用层面的数字化实践；
强烈的追求业务数字化管理，并且有幸见识到了完整的实践过程，才最终形成比较清晰的认知；
后知后觉」的反思；
反思低代码应用；
从而提供，各种「相对简单」的业务流模型搭建；
在业务完成数字化之后，自然可以提升各个场景的统筹效率；
AI领域」来说，其依赖「数字化」的基础，进而推进流程和决策的「智能化」管理；
反思技术的发展；
遥不可及」；
成为当下最大的热点；
06
【最后聊几句问题】
越来越多的业务人员具备「简单」的开发能力，必然会给部分研发人员的带来负面影响；
加剧互联网的「内卷」趋势，本就卷得一塌糊涂的行业，现在更是雪上加霜；
就像现在的「AI智能」一样，领先的公司不会顾及反对的声音一路狂奔，落后的公司一边喊着反对又一边疯狂追赶；
真正的趋势，本着不可逆跟随就好的心态。