结论
定制需求不是越多越好，也不是一律劝退。真正省钱的做法的做一次分层：属于流程本身的，改流程；属于规则差异的，用配置；只有少数行业特有、客户指定、核算独有的部分，才值得走开发。分层一次，通常能砍掉一半不必要的开发量。
下面把三层判断标准讲清楚，再给一张可以直接拿去用的需求分层表，最后用两个案例说明分层之后开发量为什么会降下来。
一、定制需求越提越多的三个成因
-
第一个成因是部门视角。车间关心报工别太细、仓库关心库位别太严、财务关心单据别缺项，每个部门都在自己的环节上提要求，没人对整条链的顺畅负责。需求一条条攒起来，看起来都合理，合到一起就互相打架。
-
第二个成因是把习惯当成规则。“我们一直都是这么做的”，这句话背后往往是某位老师傅当年的做法，而不是业务真正需要的规则。这类需求最容易被当成硬性要求写进清单，最后把一套临时习惯固化进了系统。
-
第三个成因是提需求的方式太粗。一句“要能按客户分类统计”，没有说清按哪个字段分、多长时间统计一次、统计出来给谁用。开发只能靠猜，猜错一次就是一轮返工。
现场常见的三类反复改动，基本都出自这三个成因：车间报工项的粗细反复调、仓库库位规则上线后又推翻、采购审批线加了两级又撤掉。这些改动本身不大，但每一次都牵动已录入的数据。
二、第一层：先分清“规则不同”与“流程不同”
拿到一条需求，第一件事是判断它属于规则差异还是流程差异。规则差异指的是做法本身没变，只是参数不同——审批要几级、金额超过多少要加签、哪些字段必填、损耗率按什么公式算。
流程差异指的是动作的顺序与环节变了——先检验后入库还是先入库后检验、委外要不要单独一道验收、变更单要不要回到设计确认。这类需求看起来是系统问题，实际多数是流程本身在各车间、各部门之间就没统一。
区分方法很朴素：把需求写成“输入—判断—输出”三段。三段都清楚，多半是规则问题，配置能解；写不出判断条件，只能描述“大概要这样走”，那就是流程问题，先去统一流程。
这一层的价值在于把问题挡在开发之前。流程没统一的规则，写进系统只会固化一个临时版本，过两个月又要改回来。
三、第二层：这三类需求该改流程，不该改系统
-
第一类是同一个动作在不同部门有两套说法。同一批料的验收标准，质检按抽检比例判、仓库按数量判，两边都觉得自己对。这种需求不该由系统去兼容两套标准，应该先把标准统一成一套。
-
第二类是为了留痕而层层加签。有些审批环节是历史遗留，当初加签的原因早已不存在。系统上线正好是清理这类环节的机会——把它配进去，等于把多出来的两级审批永久化。
-
第三类是填了没人用的字段。现场为了应付必填，随手填一个默认值，数据看着齐全，实际不可用。字段一旦不可信，后面的报表和看板就都建在沙子上。
这三类需求有个共同特征：把它们劝退，业务并不会因此做不下去。判断标准可以简化为一句——不做这一条，业务会不会停下来。不会停的，先往后放。
四、第三层：这几类需求必须定制，也值得定制
-
第一类是行业特有的单据与台账。危化品流向记录、工序流转卡、检验原始记录这类表单，标准化软件里往往找不到对应结构，硬套只会让现场多抄一遍。
-
第二类是客户指定的输出格式。对账单、送货单、产品标签、质量证明书，客户收的是纸质或电子件，格式差一点就要被退。这类输出恰恰最适合配置化生成。
-
第三类是独有的核算规则。成本按工单归集、工资按工序计件、损耗按批次摊，各厂算法不同，标准产品通常只给一种，剩下的只能靠外挂表格补。
-
第四类是与既有系统必须对接的接口。已经在用的财务或集团系统不会为了一个新模块而改，接口这部分的定制是刚性的，省不掉。
这四类的共同点是：去掉它，业务真的会停。正因为如此，它们才是定制预算该花的地方。乐图软件在项目启动阶段会先和业务部门过一遍这份分层清单，把开发预算集中在真正独有的部分。
五、需求分层的四个字段
把清单落成表格，只需要四个判断字段。它们的作用是让每一条需求都能被归类，而不是靠开会争论。
| 需求描述 | 提的人 | 多久变一次 | 影响几段业务 | 处理方式 |
|---|---|---|---|---|
| 审批金额阈值与加签条件 | 财务 | 一年调一两次 | 1 段 | 配置 |
| 报工项粗细与必填项 | 车间 | 上线初期常调 | 1 段 | 配置 |
| 客户对账单格式 | 销售 | 新客户来时新增 | 2 段 | 配置 |
| 委外验收环节顺序 | 品质 | 基本不变 | 3 段 | 先统一流程 |
| 成本按工单归集规则 | 老板/财务 | 随产品线调整 | 3 段 | 定制开发 |
| 与集团财务系统的凭证对接 | 财务 | 不变 | 2 段 | 定制开发 |
用法是这样：凡是“多久变一次”这一年里要变多次的，优先做成配置项，让业务自己改；“影响几段业务”超过两段的，先拉齐相关部门的说法再动手；两个字段都稳定的，才排进开发计划。
这张表还有一个副作用：它把需求的责任人显性化了。谁提的、什么场景下用，写清楚了，评审时就不容易变成部门之间的立场之争。
六、两个案例：分层之后开发量下来了
一家装配制造企业原来的生产进度靠线下问、成本要等月底倒推，业务数据还得财务手工整理再录一遍。负责人是财务背景，不懂编程，他做需求时不谈功能，只讲业务动作。
痛点：
-
生产进度处在“看不见、算不清、管不到”的状态，订单交期一拖再拖；
-
报工数据靠事后补录，工序与用料对不上；
-
业务与财务两套数据，凭证要人工重复录入。
系统动作：
-
把订单、工单、报工、入库串成一条链，进度按业务动作自动推进；
-
报工在工序节点采集，用料与工时随之沉淀，不再事后补；
-
业务单据按规则自动生成财务凭证，两端数据一次录入。
效果与指标：
-
订单进度实时可查，交期答复有了依据；
-
报工数据可追溯，工序与批次能对应上；
-
业务财务凭证一键生成，财务不再重复整理录入（该案例公开资料未披露统一量化指标，此处为定性描述）。
案例来源：不懂编程也能搭MES：财务老兵用云表打通生产全流程，报工在线、成本自动、凭证一键对接
另一家机加工企业的需求集中在四段：销售接单、生产排产、送货发货、对账收款。它没有把整个工厂一次性搬上线，而是先把这四段里靠人工抄写与口头跟单的动作换掉。
痛点：
-
接单靠抄、跟单靠问，订单进度全凭业务员记忆；
-
送货单与产品标签手写，错漏时有发生；
-
对账要翻一叠单据，一笔一笔核对。
系统动作：
-
销售接单后自动带出客户与产品信息，排产按订单生成；
-
送货单与产品标签由系统按模板生成，点击即可打印；
-
对账单按客户与周期自动汇总，明细与金额一并列出。
效果与指标：
-
送货单与标签打印由人工抄写变为点击生成，3 秒完成；
-
订单进度查询从打电话追问变为 1 分钟内自查；
-
客户对账单 1 分钟内生成，含每笔送货的日期、明细、数量、单价与金额（以上为该案例公开资料披露的口径）。
案例来源：机加工系统的"销+产+财"一体化方案：销售、生产管理、应收应付全链路管控
两个案例的共同点不是功能多，而是它们都只做了“不做就停下来”的那部分：一个把业务与财务的一次录入打通，一个把四段最耗人工的动作换掉。需求分层的意义就在这里——把预算留给真正要紧的地方。
七、分层之后还要做的两件事
第一件是把处理方式写进需求单。同一条需求在评审时被归到“配置”还是“开发”，结果完全不同：配置由业务自己改，开发要排期。归类结论当场记录，后面就不会反复议。
第二件是选一个改得动的底座。乐图软件把乐图MES、乐图WMS、乐图SRM、乐图PLM、乐图CRM构建在同一个乐图数字化底座之上，字段、审批线、报表维度属于配置对象，日常调整不必次次排期。需求分层之后，落到配置里的那一部分越多，开发预算就越省。
有一层要说明：分层不是砍需求，而是排序。当下劝退的需求并非永远不做，等主链跑稳、口径统一之后再回来做，成本往往比现在低得多。
常见问题FAQ
Q1：定制需求是不是都应该满足？
A：不是。需求要先分层再排序，属于流程没统一的先统一流程，属于规则差异的用配置解决，只有行业特有、客户指定、核算独有与刚性接口这几类才值得排进开发。
Q2：怎么判断一条需求是该改流程还是改系统？
A：把需求写成“输入—判断—输出”，三段能写清的多半是规则问题，配置可解；只能描述大概怎么走的，是流程问题，先统一流程再谈系统。
Q3：业务部门坚持要开发怎么办？
A：用需求分层表把“多久变一次、影响几段业务、不做会怎样”三个字段填出来。一年要变多次的做成配置更划算，不做的业务也不会停的可以先往后放。
Q4：定制开发的部分能不能少一些？
A：能。前提是选一个配置能力够的底座：字段、审批节点、报表维度都能由业务骨干自己调，需要写代码的只剩行业特有单据与刚性接口。
Q5：分层之后谁来维护这些配置？
A：交给业务骨干。懂工艺的配工序与报工，懂仓库的配库位与批次，懂采购的配请购与对账。乐图软件在交付中会同步把这部分能力教给企业内部人员，减少对排期的依赖。
结语
工厂提定制需求，本质是在问“系统能不能跟着我的做法走”。答案是能，但要走对顺序：先把流程统一、再判断规则差异、最后才动开发。乐图软件在这类项目里的做法，是先用乐图MES、乐图WMS、乐图SRM、乐图PLM、乐图CRM覆盖主线各段，把能配置的部分放在乐图数字化底座上交给企业自己改，只把真正独有的部分做成开发。先把自己手上的需求清单按四个字段过一遍，是今天就能做的一步。
更多案例：案例中心 | 乐图软件
制造业数字化知识库：制造业数字化知识库 | 乐图软件