低代码高频实践场景系列之六——采购管理SRM系统

本文作者：得帆信息联合创始人兼CTO徐翔轩

采购系统不少，为什么还会冒出低代码？

这几年，很多中大型企业在采购数字化上的投入并不少，普遍构建了专属的采购管理方案：

• 有的企业ERP专门配置采购模块，管订单、到货、结算等核心流程；
• 不少企业上了SRM，管供应商协同、招投标、询价、合同；
• 有的行业还有专门的招采平台和集采平台。
  

但在和客户交流中，我们经常听到一句话：“系统是有的，但大量实际工作，还是在Excel、邮件和微信群里进行。”这类情况的典型表现是：

• SRM承载“标准流程”，但具体项目、具体业务线，就开始“飞单”（脱离系统流转）、“加Excel表格”；
• 上下游协同（业务部门需求—采购—财务—供应商）之间，仍依赖人工催办、邮件确认；
• 很多跨部门、跨系统的“灰场景”，长期游离在系统之外。

于是，企业的采购体系呈现明显的层级割裂：

• 第一层：ERP / SRM等“主系统”，负责核心台账与标准流程；
• 第二层：表格、邮件、IM聊天记录，承载大量实际协同过程；
• 中间缺了一层——把这些“协同过程”系统化、可治理、可沉淀的能力。

低代码，恰恰正成为填补"中间层"的关键工具。

SRM“很难一个系统包打天下”

1

业务线差异极大，SRM标准模型撑不住所有场景

同一集团内部，采购业务场景呈现显著差异：

• 工程类采购‌：项目制、一次性特征突出；
• 制造类采购‌：物料重复采购频率高，强调长期供应商关系与准时交付；
• 服务类采购‌：涵盖人力外包、咨询、营销服务等，需动态调整服务标准与定价策略。

SRM能提供一套比较标准的供应商、询价、招投标、合同、订单流程，但要真正适配到每一条业务线、每一个品类的打法，往往需要大量定制。

2

上下游协同，常常停在“流程两端”

以一个采购需求为例，系统间协同存在明显割裂：

• 前端的需求澄清、规格确认、预算审批，在业务部门的系统里；
• 中间的寻源、比价、合同，在SRM里；
• 验收、绩效评估、付款计划，往往在财务、项目系统里。

这一过程中，大量的沟通、确认、变更，仍然靠邮件和聊天工具，系统里“只有结果，没有过程”。

3

细分问题，SRM“帮不上忙”

SRM系统在以下“外延场景”中表现乏力，比如：

• 供应商绩效分维度评估（交期、质量、配合度），不同业务线权重不同，SRM一般仅支持固定权重模板，无法动态调整；
• 项目制采购，需要按项目维度做预算、控制、分摊，SRM仅支持业务维度核算，导致项目成本与财务难以匹配；
• 尾料采购、小额多次采购等长尾采购，需要SRM简化流程而不是一刀切。

这些场景因业务体量小、规则复杂，难以纳入SRM产品迭代优先级，却实实在在影响着采购效率与治理水平。

在采购领域，低代码扮演两种角色

1

角色一：作为“轻量SRM”，在没有SRM的企业里成为可协同的采购中台

典型适用企业是营收在几亿到几十亿的企业，这些企业一般有如下特征：

• ERP有采购模块，但不擅长对接大量供应商；
• 上SRM投入大、周期长，一时下不了决心；
• 业务上已经有了明确的采购协同需求。

在这类企业里，低代码更多是被当作一个“轻量SRM平台”来用，构建以下内容：

• 供应商档案、准入评估、黑白名单动态更新；
• 简单的询价、比价、定点流程；
• 合同管理、交付跟踪与到货验收；
• 基本的供应商绩效记录。

低代码可实现流程跑通+供应商在线协同，同时与现有ERP做基础数据打通，而不是一开始就追求功能全面。

2

角色二：作为“SRM外延层”，补齐SRM上下游没覆盖的场景

典型适用企业是已经部署SRM的集团型企业，这些企业一般有如下特征：

• 主流程在SRM里流转，业务相对固化；
• 但各业务线有大量“SRM不好改、改一次成本大”的扩展需求。

这时候低代码扮演的是“柔性承载层”：

• 在SRM上游，做需求池、需求澄清、技术评审、预算绑定；
• 在SRM下游，做合同执行跟踪、执行过程中的变更审批、履约绩效、争议记录；
• 在侧翼，做供应商画像、供应商改进计划、专项合作项目等管理。

用一句话概括："主干在SRM，血肉在低代码"，SRM作为核心流程引擎，低代码平台则承载个性化需求、非标流程及跨系统协同。

低代码在采购场景里，有哪些作用？

1

快速做出“业务线自己的那一套”

不同事业部、不同品类的玩法不一样，用低代码可以：

• 共用一套集团级的基础数据与权限体系；
• 在此基础上，为不同业务线做轻量差异化流程和数据模型。

这样既不打破集团统一管理，又不要求所有业务线“全部统一”。

2

把散在Excel和群聊里的内容搬到系统里

采购协同中的过程，如数据需求变更、规格确认、例外批准、供应商沟通记录等，原来都散在“系统外”。

用低代码做成“协同页”，可以以项目/需求/合同为中心，配置或集成需求澄清、规格确认、变更审批、沟通记录等全模块，关联、对应到质量、交期、成本的结果，可视化呈现“过程上下文”，实现"结果-过程"双向追溯。

3

减少对SRM二次开发的依赖

很多企业有这样的困惑：“SRM是好系统，就是每改一次东西都像上一个新项目。”这时，企业可以考虑在SRM外“包”一层低代码应用：

• SRM负责稳定的主数据和主流程；
• 业务方的尝试与变化优先落在低代码层，验证、跑顺后，再决定要不要沉入主系统，避免改动对主系统稳定性和使用成本的影响。

4

做采购视角的过程看板

低代码可以把来自ERP、SRM、项目、财务系统的数据拉通，生成可视化看板，业务问题一目了然，例如：

• 风险预警看板‌：哪些项目的采购风险高？
• 供应商能力看板：哪些供应商在哪个业务线表现好，在哪个表现一般？
• 采购效率看板：哪些品类的长尾采购可以简化流程，释放更多效率？

最后说说边界：低代码不是“另造一个SRM”

客观来说，低代码在采购方面有能力边界：

• 复杂的寻源引擎、招投标引擎、多轮博弈算法，仍需由SRM系统承载；
• 对外大规模开放的供应商门户、生态级的电商/招采平台，有流量与交易属性，不适用低代码能力范围；
• 价格策略、供应链金融、信用体系这些高复杂度模块，往往需要专门系统支撑。

低代码真正适合做的是：把“主系统没覆盖好”但又长期存在的业务过程系统化、协同化，并且支持长期调整。对很多企业来说，与其纠结“要不要再换一套 SRM”，不如先把这些“中间层”的能力，用低代码一点点搭起来。

大家还对哪些内容感兴趣，或者是希望一起探讨相关的方法，欢迎留言和私信联系。希望得帆低代码和我们的实践心得，能帮到越来越多的朋友、客户。