企业官网建设流程全解析

低代码时代已经过去了。

现此刻, 这个判断极易博得认同。缘何? 缘由是, 诸多有关AI写代码、AI生成页面以及AI自动搭应用的演示情形如波涛般呈涌, 数量渐次繁多。众多人目睹这般演示场面后, 于自然而然的潜意识流动里, 会滋生出一个疑问, 即: 设若AI已然能够将页面以及代码生成出来了, 那么, 像低代码这般具备拖拽特质的平台, 究竟还存有多少的存在价值呢?

这个问题不能简单回答。

倘若探讨的物件是某些轻量级的表单类工具, 又或者是仅仅能够开展请假、报销、登记以及信息收集之类的流程工具, 那么它们实实在在会遭受相当大的冲击。人工智能、在线表格、自动化工具以及标准的软件即服务都在持续向前迈进, 过往依靠做出一个页面的速度足够快便能够打动客户的时期，业已没太过容易达成目标了。

但如果讨论的是企业级应用平台，结论就不能这么下。

企业系统, 真正难的地方, 并非仅仅做出页面, 页面只是用户每日瞧见的入口, 其背后还有业务对象, 还有字段规则, 还有组织权限, 还有流程责任, 还有系统接口, 还有数据一致性, 还有日志追溯, 还有后续迭代。

这些东西才是企业软件的骨架。

所以, 对于这篇文章而言, 首先我们暂且将立场搁置一旁, 不去为任何概念进行言语上的支持, 也不为任何产品去充当宣传的角色。而是单单从企业系统自身这儿开始着手, 琢磨一下低代码究竟是哪些部分正逐步失去其应有的价值, 哪些部分反倒会在此情形下重新被赋予需求。

一、先分清楚，大家说的可能不是同一种低代码

低代码这个词，过去几年被混用了。

一部分产品着重于表单以及审批, 能够使得业务人员迅速构建一份信息登记表格, 拉出一条简易流程。

有些产品更接近在线表格，强调协作、视图、统计和自动提醒。

有一些产品属于流程平台, 其把重点给予审批流, 还有节点, 以及条件分支, 另外是组织权限, 最后加上消息通知。

存在另外一类产品, 其正朝着企业应用平台的方向去进行发展, 除开表单以及流程之外, 还需对数据模型、复杂的权限、报表、接口、主数据、应用发布、日志审计以及运维管理予以处理。

这些东西都被叫做低代码，讨论时就很容易错位。

有一个人声称低代码没用途, 其脑海之中或许思索的是“从中拖拽出几个字段之样态, 并借此实现一个具备增添、删除、修改以及查询功能页面之生成”。另外还有一个人宣称低代码具有价值意义, 其脑海里面所思考的是“借助平台去承接那种跨越不同部门、不同系统且处于持续变动状态的企业应用”。此二人运用的是同一个词汇, 然而谈论的却并非是同一层面的能力。

故而要判定低代码是否存有未来, 首要之举切勿急于给出定论, 应先弄明白: 你口中所提及的是何种样式的低代码呢。

如果只是简单表单型低代码，价值确实在变薄。

曾经, 有个部门打算做客户登记、物品领用以及会议室申请之事, 透过低代码搭建而成耗时甚速。当下有诸多工具均可达成此般效果, AI 亦能够生成一个大致相仿的页面。如此之类能力将会愈发显属基础范畴, 甚至于会演变成诸多办公软件、协同软件之中的默认功能。

但企业应用平台型低代码面对的问题不一样。

它要处理的并非仅是一张表单, 而是致力于一组业务对象间的关系, 像客户与合同、合同和订单、订单跟发票、发票及回款、回款同项目、项目与设备、设备对物料、物料和供应商, 这些对象彼此于前后顺序上存在关系, 在权限范围方面有着边界之分, 于数据度量上存有口径之异, 并且还涵盖跨系统同步的情况, 这些都是它所处理的内容。

在这样的场景当中, 低代码所具备的价值并非处于“少写几行代码”这一范畴, 而是着重体现在, 能够将企业应用里频繁反复出现的基础能力, 沉淀转化为平台。

这两个层次如果不分清，后面的讨论就会跑偏。

二、AI能生成页面，但企业系统难在页面之后

现在很多 AI 应用演示都很漂亮。

你来输入一句话: 帮我去进行一个客户管理系统的制作。迅速地, 列表页面呈现出来了, 详情页面呈现出来了, 按钮呈现出来了, 图表同样呈现出来了。就原型设计、个人工具以及简单后台而言, 这般的能力极具实用性。

但企业系统进入真实业务以后，问题马上变多。

要是有一个客户管理系统, 从页面去看的话, 存在客户名称, 还有联系人, 另外有电话, 包括行业, 以及跟进记录。当它真正上线之际, 企业会接着去问:

这些问题都不是页面生成工具能一次解决的。

页面可以很快，但数据关系不清楚，系统就会乱。

字段可以生成，但字段含义不统一，报表就会错。

流程可以画出来，但责任边界不明确，审批就会变成形式。

接口可以调用，但没有权限和日志，后面出了问题就追不回来。

这同样是企业系统跟演示系统最为显著的差异之处。演示系统所追求的是, 呈现出一种看似能够正常使用的状态。而企业系统所追求的则是, 在长时间持续运行的情况下, 依然不会出现任何问题。

今天生成出一个页面, 这并非难事。然而, 三个月过后, 业务规则发生了变化, 系统依旧能够进行修改；半年之后, 组织出现了调整, 权限居然还能够随之变动；一年之后, 要接入 ERP、MES、CRM、财务系统, 数据竟然还能够保持一致；出现了一次错误操作之后, 还能够查明到底是谁在何时修改了哪一个字段。

所以, 靠着AI生成的页面以此来判断低代码是不是失去价值没了用处, 那样所谓的判断本身就有点粗略了。

AI 会对低代码的使用方式予以改变, 然而, 它并未将企业系统里的数据问题加以消灭, 也没有把流程问题予以消除, 更没有把权限问题进行根除, 同时也没有将集成问题予以解决。

三、企业真正缺的，是标准系统之外的补位能力

不少企业已然具备了ERP, 也自有MES, 还有CRM, 亦存在OA, 并且拥有WMS, 同时具备SRM。

按理说，这些系统加起来已经很多了，为什么还会需要低代码？

原因很简单：标准系统有主干能力，但企业现场有大量边缘变化。

ERP 对于采购、库存、生产、财务这些稳定主流程的处理更为擅长, MES 针对车间执行、工序报工、质量记录、设备状态的处理更具优势, CRM 负责管理客户以及销售过程, OA 处理通用审批与协同, WMS 管控仓储, SRM 管理供应商协同。

这些系统各有位置，也各有边界。

企业真正麻烦的，往往是几个系统之间的缝隙。

举个制造企业很常见的场景：质量异常闭环。

车间发觉某批物料上线之后呈现不稳定状况, MES当中有着工单以及工序, 还有报工以及检验记录, ERP里头存在采购订单、供应商、库存批次以及成本信息, OA里或许存在异常审批, 供应商协同系统里又有着整改通知，管理层切实想要的, 是一种从发现、确认、隔离、分析、整改、复检、放行直至追责的闭环, 一张单独的异常表远远无法满足需求。

这个闭环里至少要处理这些内容：

做这类应用, 若用标准系统, 常常会卡在边界之处。ERP并没有十足去承接完整质量整改流程意向, MES也并非全然适合承接供应商准入以及财务影响这种形式局面, OA更是缺乏业务对象以及批次追溯。最终企业极易退回至Excel、微信群、临时表单和人工一汇总的状况。

低代码如果只是一个表单工具，也解决不了这个问题。

但是, 要是它拥有数据模型, 同时具备流程引擎, 并且存在权限控制, 还包含接口集成, 以及有着日志审计, 那么就能够在标准系统之间补上这一段业务闭环。

这才是企业级低代码更实际的位置。

它并非将ERP、MES、CRM推翻后重新去做, 也不是任由业务部门随意搭建起一堆孤立的小工具。它更类似于一个应用补位层面, 这一层面用于承接那样的一些业务, 这些业务是标准系统覆盖不到的, 是变化相对较快的, 且是还必定要和主系统产生关系的。

四、低代码是不是符合软件工程，要看平台能力

有人会问：低代码这么搭应用，真的符合软件工程吗？

这个问题问得很有必要。

然而, 判定软件工程质量时；不能仅仅依据其是否为手写代码来决断。要是仅存在手写代码, 却缺失设计、测试、版本层面之事宜, 缺乏权限、日志以及运维相关环节；那么同样会致使局面陷入混乱不堪之状态。倘若低代码仅仅具备拖拽、配置以及临时上线等方面情况；照样会将企业引入全新的混乱境地之中。

真正要看的，是平台有没有把企业应用里的工程要素管起来。

至少要看几个方面。

1、数据模型

首先, 一个应用并非是由一堆字段搭建而成的。然后, 要明确客户与订单、订单与合同、合同与项目、项目与设备、设备与物料、物料与供应商之间具体是怎样的关系。接着, 需清晰指出其中哪些字段属于主数据。之后, 要说明哪些字段源自交易过程。再之后, 要阐述哪些字段能够被修改。紧接着, 要表明哪些字段需要进行审批。以上这些内容都必须清晰且准确地讲明白。

要是平台仅仅关注表单呈现出的样子, 却不在意业务对象相互之间存在的关系, 那么后续必定会不断地变得愈发混乱。

2、权限体系

企业权限不是简单的管理员和普通用户。

它或许会关联到组织, 以及角色, 和岗位, 还有区域, 再加上部门, 以及项目, 以及客户归属, 以及字段可见性, 以及数据范围, 以及操作动作。比如说销售可不可以查看其他销售的客户, 采购能不能够修改供应商银行账户, 项目经理是否能够查看成本明细, 这些都得要有明确的控制。

权限做不细，低代码应用越多，风险越大。

3、流程和责任

流程不是画几个节点就结束。

哪一步要退回到, 谁能够加签, 谁可以进行转交, 要是超时该怎么去提醒, 条件分支怎样去判断, 审批意见是不是进入日志, 流程结束之后数据状态会怎样改变, 这些均是工程问题。

企业应用里，流程既是效率问题，也是责任问题。

4、接口和集成

低代码应用如果长期孤立运行，最后还是新的信息孤岛。

存在价值的平台, 需连接ERP、MES、CRM、OA、财务处、人事部门以及数据平台, 接口具备鉴权功能、重试机制、异常记录、字段映射和同步状态, 处理失败时, 系统能够提示谁来处理, 而非让业务人员自行猜测。

5、版本和发布

业务人员, 今天有着想要添加字段的想法, 明天怀有想要更改流程的念头, 后天心存想要调整权限的意欲。对于平台而言, 不能使得所有的修改状况, 都直接地对线上方面产生影响。

较为妥当的办法, 是具备测试环境, 拥有发布记录, 存有版本说明, 明确影响范围, 设有回滚机制。特别是当关联到审批、关于财务、涉及库存、关乎客户、有关合同这些数据之际, 绝不可随意改动。

6、日志和审计

企业系统必须得能够回答, 是谁进行了修改, 修改的是什么内容, 在何时进行的修改, 修改之前是什么样子, 修改之后又变成了什么样子, 以及为什么要做出这样的修改。

这项能力平常瞧着没甚突出之处, 在出现问题之际却极为关键, 比如说, 客户回款所用账号被更改了, 供应商资质被予以放行状态了, 合同涉及的金额被进行调整了, 库存所处状态被采用手工方式更改了, 要是查找不到相关记录, 那么系统便不可信了。

从这些标准看，低代码本身不天然代表工程水平差。

真的存在危险的情况是, 将低代码视作那种随手就能搭建的工具, 进而把平台治理这一环节省去, 把数据规范这一环节省去, 把权限设计这一环节省去, 把运维机制这一环节也省去。

企业级低代码的门槛，恰恰在这里。

五、低代码真正有价值的地方，是让变化有秩序

很多宣传会把低代码讲成“快”。

快速开发，快速上线，快速响应业务。

当然, 快是重要的, 然而, 仅仅强调快是不足够的。要是一个企业系统只是单单追求快, 那么, 极容易将混乱以很快速的方式给予放大。

低代码真正有价值的地方，是让变化变得有秩序。

企业每一天, 都处于不停的变化当中, 有组织方面的调整, 有流程方面的调整, 有价格政策相关的调整, 有审批权限的调整，有供应商规则的调整, 有客户分级的调整, 还有项目状态的调整, 然而这些变化, 并不会因为上了ERP或者CRM就化作乌有消失不见的。

标准系统负责主干稳定，低代码平台负责承接变化。

这件事听起来普通，落地时很关键。

比如说, 采购付款账号出现变更, 看上去仅仅是供应商档案之中的一个字段产生变化, 可是实际上, 这有可能牵涉到采购, 可能牵涉到财务, 也可能牵涉到风控以及审计。

一旦采用Excel进行管理操作, 那将会面对极大的风险。变更申请究竟是谁发给我们的, 证照有没有经过认真核验, 财务方面是否完成了复核工作, 原来使用的账号有没有被停用, 历史所进行的付款会不会受到影响, 后续付款的时候是不是会自动启用新的账号, 而这些情况都是很难去追查清楚的。

若径直去改ERP, 好多企业会认为流程太过繁杂, 定制所需成本过高, 调整所花费的周期太长。

具备一定合理性的方式, 是借助低代码搭建一个供应商关键信息变更流程, 即按此顺序: 业务部分提交申请, 此后系统自动去拉取供应商的基础资料, 紧接着对证明材料提出上传要求, 先送交采购进行初步审核, 再由财务展开复核, 在必要的情况下让风控进行确认, 当审批通过之后再同步至ERP或者财务系统, 并且要保留完整的操作日志句号。

这个应用不复杂，但很有用。

需解决的是, 一次具备高风险性质的数据变更, 怎样达成拥有流程, 拥有权限, 拥有记录, 拥有同步, 拥有追溯的状态, 而页面仅仅是承载这些规则的入口。

很多企业真正需要的，就是这一类能力。

六、AI时代，低代码会换一种形态存在

AI 对低代码一定会有影响。

此前搭建应用时, 业务相关人员需撰写需求，实施方面的顾问要构建表格, 从事开发的人员要编写接口, 担任管理职责的人员需配置权限。往后诸多动作会转变为借助自然语言进行交互。

比如：

这些动作，AI 会让搭建和调整效率更高。

然而, 企业并不会由于AI速度极快, 便舍弃、抛弃那基本的管理。AI生成了某一个字段, 那么该字段的含义究竟由谁来予以确认? AI更改了一条流程, 如此一来, 它会不会绕开原本的审批责任? AI增添了一个接口, 它有无可能会超越权限去读取客户的数据? AI修改了报表口径, 这会不会对经营分析产生相关影响?

越是让 AI 进入企业系统，越需要一个稳定的业务结构层。

该结构层需管理对象, 管理字段, 管理关系, 管理流程, 管理权限, 管理接口, 管理日志以及管理版本。倘若低代码平台能够承接这些能力, 那么它便不单单是拖拽工具, 而是会变为AI应用进入企业现场的一层底座。

所以低代码在 AI 时代不会保持原样。

它会从, “人拖拽搭应用”这种情况, 逐渐转变成为, “AI进行辅助搭建, 人承担确认和治理工作, 平台实施运行和管控”。

这一点很重要。

未来会被淘汰掉的, 有可能是那种仅仅只会做简单表单的低代码, 而真正能够被留下来的, 将会是那种可以承接企业应用结构的平台。

七、企业应该怎么判断低代码还值不值得用

对于企业来说，争论低代码有没有过时，意义没有那么大。

更实际的做法，是拿自己的业务场景去判断。

可以问几个问题。

如果这些问题大部分答不上来，那它可能只是一个部门工具。

部门工具不是没有价值，但不要拿它承担企业级应用平台的责任。

要是这些问题能够回答得相对较为清晰明了, 而且能够在实际的业务当中得以运行起来, 那么低代码就仍然会拥有相当明确的存在位置。

企业软件不是谁替代谁这么简单。

专门处理相对稳定的主干问题的是ERP、MES、CRM、OA。负责解决生成、理解、辅助决策和交互效率问题的是AI。要是低代码具备足够扎实的处理状态的性质, 那它们能够解决企业因不停变化而产生的应用交付及业补充充额外份额的问题。

各自有边界，也各自有位置。

结语：低代码没有结束，只是混日子的低代码没那么好过了

所以，低代码时代真的过去了吗？

下述为我的判断, 简单低代码所具有的红利正处于变小的态势, 企业级低代码对应的门槛正呈现变高的情形。

往昔之时, 仅仅是拖表单、画流程以及生成页面这般操作, 便能够使得众多企业产生新鲜感。然而现在这种情况已然行不通了。因为眼下AI其具备生成页面之能力, SaaS在当前的发展态势下做得越发精细, 在线表格以及自动化工具同样是变得越来越强大。由此, 如果低代码一直停滞在“快搭一个页面”这样的层面, 的确是无从继续阐述其中所蕴含的价值了。

但企业真正需要的，不是又多一个页面工具。

企业所需要, 是这样一套平台能力, 它能将相异各异的业务对象管理掌控, 能把复杂繁多的数据关系梳理规整, 让权限边界清晰明确, 让流程规则顺畅妥善, 使系统接口适配良好, 让日志审计细致周全, 甚至能让持续迭代有序进行。

从这个角度看，低代码没有结束。

它仅仅是由“快速开发工具”出发, 朝着企业应用平台的方向迈进, 再向业务系统补位层前行, 进而朝着AI时代的应用承载层持续迈进。

对企业来说，别急着问低代码是不是过时。

需更着重去问的是, 你眼前的这个低代码平台, 究竟仅仅能够辅助部门去制作几张表格, 或者可不可以使企业业务系统得以长久持续运行呢！

这个问题问清楚了，答案自然就出来了。