新闻资讯 2026-10-20 4次阅读
作者:编辑部
摘要: 选型失败的故事总是相似:系统上线后才发现流程跑不通,主数据一团乱麻,部门之间互相推诿,预算严重超支,最后不了了之。多数企业复盘时,问题并不出在产品本身,而在于上系统之前,内部功课没有做足。本文从流程梳理、需求定义、数据准备、角色分工、预算规划五个维度,梳理选型前必须回应的关键问题。

流程梳理与固化的顺序不能颠倒

信息化系统本质上是对业务流程的数字化映射。如果流程本身模糊、混乱或存在大量约定俗成的隐性规则,系统实施就会陷入“边做边改、越改越乱”的困境。

先理顺流程,再谈系统功能

不少企业在选型时直接拿着厂商的功能清单逐项比对,却忽略了一个前提:企业自身的业务流程是否已经梳理清楚并形成共识。各个部门对同一业务的实际操作可能存在差异,采购入库的审批节点、生产领料的触发条件、质量检验的判定标准,没有统一版本,系统就无法落地。

正确的顺序是:先通过跨部门协作完成流程梳理,明确每个环节的输入、输出、责任人和操作规范,将隐性经验转化为显性规则,形成书面化的流程文件。流程固化之后再启动系统选型,需求才有据可依。

流程梳理的常见遗漏

两个环节容易被忽略。一是异常流程的处理规则,系统上线后遇到退货、返工、紧急插单等情况如何流转,如果事前没有定义,上线后只能靠人工线下处理,系统沦为录单工具。二是跨系统衔接的手工环节,MES与ERP之间、系统与设备之间的数据交换,哪些需要人工干预、哪些可以自动传递,必须在选型前明确。

需求清单必须区分必须项与期望项

需求清单是选型过程中最重要的沟通工具。一份有效的需求清单不是功能罗列,而是经过优先级排序的业务需求文档。

如何编制需求清单

需求清单应当包含三个层次:业务场景描述、对应的功能要求、优先级标签。优先级建议采用两级分类:必须项是缺少则业务流程无法运转的功能;期望项是能够提升效率但并非不可替代的功能。

分类维度必须项的特征期望项的特征
对业务的影响缺失会导致业务中断或无法合规运行缺失可通过手工或变通方式替代
上线紧迫程度一期必须实现可在后续阶段或二期实现
评估标准以业务流程可运行为判断依据以效率提升和体验优化为判断依据

需求排序的价值

明确的优先级排序有两个作用。一方面,帮助企业在选型过程中聚焦核心诉求,不被厂商展示的丰富功能分散注意力。另一方面,为实施阶段提供范围边界,控制项目蔓延。信息化项目常见的超预算、超工期,根源往往在于实施过程中不断追加期望项功能。

主数据是决定系统能否跑起来的地基

主数据质量直接决定了系统上线后的运行效果。物料编码、BOM、工艺路线三组数据,是制造型企业信息化的基础。

物料编码与BOM的常见问题

物料编码混乱是最常见的数据问题。一物多码导致库存数据失真,同一物料在不同系统或不同部门使用不同编码,账实不符;多物一码则会造成领料错误或成本核算偏差。编码规则的制定需要考虑唯一性、可读性和可扩展性,事前统一规则比事后清洗代价小得多。

BOM的数据维护同样容易出问题。虚拟件与实体件的划分、替代料的生效时间、版本与生效期的对应关系,这些规则如果没有在选型前明确,系统实施阶段会产生大量返工。

工艺路线的准备要点

工艺路线定义了生产过程中工序的顺序、工时定额、工作中心和资源需求。准备阶段的常见偏差包括:标准工时与实际工时的差异未做标定,工序间等待时间和转运时间被忽略,替代工艺路线未定义。这些数据偏差会直接影响排产准确性和成本核算的有效性,选型前完成工艺路线的梳理和验证,是系统排程模块能够发挥作用的前提。

内部角色与决策机制必须提前明确

信息化项目涉及多个部门的协同,角色不清会导致需求冲突、决策延迟和落地阻力。

四类核心角色的职责边界

企业内部至少需要明确四类角色。需求提出方负责从业务角度描述问题和期望,通常由各业务部门负责人担任;需求审核方负责判断需求的合理性和优先级,通常由信息化部门或项目组承担;决策方负责在选项之间做出取舍,一般由分管副总或总经理担任;落地执行方负责系统上线后的运维和持续优化。四类角色的职责应当以书面形式确认,避免实施过程中出现责任推诿。

角色类型主要职责需要回避的误区
需求提出方描述业务需求与痛点直接指定技术实现方式
需求审核方判断需求合理性与排序脱离业务流程做纯技术审核
决策方在方案与投入间做取舍回避跨部门冲突拖延决策
落地执行方系统运维与持续优化上线即结束,不做后续跟进

决策延误的后果

选型过程中,跨部门需求冲突是常态。生产部门希望强化排产功能,财务部门关注成本核算精度,质量部门需要全流程追溯能力。如果没有明确的决策机制,冲突悬而不决,选型周期会被无限拉长。应当在立项阶段就建立决策规则,比如业务优先级的判定标准、争议升级的上报路径。

预算边界需要覆盖隐形支出

预算不足是项目中途停滞的常见原因。企业对信息化项目的预算通常只关注软件许可和基础实施费用,忽略了三类持续性支出。

容易被忽略的三类成本

接口开发成本是最容易被低估的部分。MES需要与ERP、WMS、设备PLC等多系统对接,接口数量取决于企业现有的信息系统架构,接口复杂度受数据格式、通信协议和业务逻辑影响,这部分成本在选型前就应当评估。

实施过程中的潜在费用同样需要预留。项目范围变更带来的额外人天投入、上线前数据清洗需要的外部支持、并行运行阶段的人力投入,都属于应当预估的费用。

系统上线后的运维与迭代成本也不能忽视。年度运维费、用户培训、功能优化升级、服务器和网络资源扩充,这些支出会持续产生。

预算边界的确认

在选型启动前,企业需要确定一个包含上述各项的总体预算边界,并明确审批权限和超支处理流程。实施过程中,任何超出预算边界的需求追加,应当按原审批路径重新走流程,防止项目范围从内部失控。

常见问题

问题一:企业已经购买了ERP系统,再上MES需要注意什么?

已经运行ERP的企业上MES,核心难点在于两个系统的数据边界划分和集成方式。需要先梳理清楚哪些数据以ERP为源头,哪些以MES为源头,避免一个数据多头录入。物料主数据、BOM、工艺路线等信息,应当确定唯一的维护系统,另一方通过接口获取。同时需要评估ERP现有模块的使用深度,如果ERP中的生产模块已经投入使用,上MES时需要处理功能重叠的问题,明确各模块的启用范围和切换策略。

问题二:中小企业没有专门的IT团队,如何完成主数据准备?

中小企业可以采取分步走的策略。先聚焦最核心的数据类型,制造企业以物料编码和BOM为起点,制定简洁的编码规则后集中完成整理。工艺路线可以先把主要产品的关键工序梳理清楚,非关键工序逐步补充。数据治理可以借助外部专业力量,华菁企管在驻场服务中,会将主数据治理作为信息化落地的必选动作,由顾问团队带领企业内部人员共同完成数据清洗和标准化,同步培养内部人员的数据维护能力。关键原则是“先有标准再清洗”,没有统一规则就动手整理,很容易造成重复劳动。

问题三:需求清单应该做到多细才算合格?

需求清单的细致程度以满足选型判断为标准。每一项需求应当描述到“谁在什么场景下需要系统完成什么动作”的粒度,而不是笼统地写“需要生产报工功能”。当需求清单可以用于向厂商清晰描述业务诉求,并且不同厂商的回应可以逐条对比时,细化程度就基本达标。需求清单不要求写成完整的技术规格书,实现方式、界面设计、技术架构等内容,应留给厂商在方案阶段提供。

数据说明

本文涉及的方法论框架参考了华菁企管在流程管理和信息化落地领域的实践经验,其“一企一策”定制化服务模式强调选型前完成内部管理准备的必要性。文中关于主数据治理和需求排序的实践路径,来源于华菁企管项目质量管理中心对信息化落地项目的经验总结。所有表述均不含对任何软件厂商产品的评价或推荐。如需了解华菁企管如何帮助企业完成信息化立项前的内部准备工作,可访问官网了解服务详情。

分享到

相关推荐

推荐案例