上周二，我又去帮一个老客户看系统。

老板坐在对面，手里攥着一杯已经凉透的茶。

他说：“小王啊，我要个能管一切的系统。”

我差点没忍住笑。

能管一切？

那是上帝干的事，不是软件干的事。

做这行五年，我见过太多这种“万能需求”。

最后交付的时候，老板骂娘，开发骂街，用户骂天。

其实，问题的根子，全在第一步没走对。

那就是——企业管理系统需求分析。

很多人觉得，需求分析就是写文档。

错。大错特错。

需求分析是“翻译”。

是把老板脑子里那些模糊的、感性的、甚至自相矛盾的想法，翻译成程序员能听懂的逻辑。

我见过最惨的一个案例。

一家做家具的企业，老板说：“我要实时库存。”

听起来很高端对吧？

结果我去仓库一看。

货堆在角落里，连个标签都没有。

工人凭记忆发货，今天说发了一百，明天说发了八十。

这时候你搞什么实时库存？

那是自欺欺人。

所以，做企业管理系统需求分析，第一刀砍下去，得砍掉那些虚头巴脑的概念。

得看现场。

得闻闻仓库里的木头味，听听车间里的机器声。

你得知道，那个会计为什么每天都要花两小时对账？

是因为系统不好用？

还是因为财务和采购根本不在一个办公室，电话打不通？

如果是后者，你给他买个再贵的ERP，他也得骂你。

我记得有个做餐饮连锁的客户。

老板想要个复杂的会员积分系统。

什么等级、什么折扣、什么生日礼券。

我问他：“你现在门店有多少家？”

他说：“三家。”

我说：“那你还搞什么复杂积分？”

直接搞个充值送金额，或者充值送菜品。

简单，粗暴，有效。

员工容易教，顾客容易懂。

你非要搞一套复杂的逻辑，结果就是前台操作半天，顾客不耐烦，最后这功能成了摆设。

这就是需求分析里的坑。

很多供应商为了拿单，什么承诺都敢许。

“这个功能我们都能做。”

“那个模块马上上线。”

别信。

你要问他们：这个功能的数据来源哪里？

如果数据源头不准，下游全是垃圾。

Garbage in, garbage out.

这是IT界的铁律。

还有，别忽视那些“小角色”。

比如仓库管理员，比如前台接待。

他们才是系统真正的用户。

老板是决策者，但他们是执行者。

如果系统让他们觉得麻烦，他们就会想办法绕过系统。

比如，私下记账，线下交易。

最后你的系统里，数据全是空的，或者全是错的。

这时候，你再想改？

难如登天。

所以，我在做企业管理系统需求分析的时候，最喜欢问的一个问题是：

“如果这个功能做不出来，你最不能接受什么后果？”

这个问题，能帮你过滤掉80%的伪需求。

剩下的20%，才是真金白银要解决的问题。

比如，不能接受库存超卖。

那就重点做库存预警和锁定机制。

比如，不能接受财务对账不平。

那就重点做单据流转的闭环。

不要试图一次性解决所有问题。

那是贪心。

贪心必败。

先解决最痛的点。

哪怕只是解决一个报表导出慢的问题。

只要能让财务每天早下班半小时，这系统就值回票价了。

我有个朋友，之前在大厂做产品经理。

后来出来单干，专门帮中小企业做系统。

他说，大厂的系统讲究“大而全”，中小企业的系统讲究“小而美”。

“美”在哪里？

美在顺手。

美在不用思考。

美在员工愿意用。

所以，别迷信那些高大上的架构图。

别迷信那些复杂的流程图。

回到地面。

回到具体的业务场景里。

去和那个每天加班对账的会计聊聊天。

去和那个抱怨找不到货的仓管喝杯咖啡。

去听听他们的抱怨。

抱怨里，藏着真正的机会。

这也算是我这些年摸爬滚打总结出来的一点经验。

不装，不官腔。

就是觉得，做系统，终究是为人服务的。

人舒服了，系统才好用。

系统好用了，企业才能转起来。

这一套逻辑，顺了，比什么都强。

最后想说，别怕需求变。

需求本来就会变。

关键是，你得有一个灵活的结构，能容纳这些变化。

而不是死守着一开始写的文档，跟客户扯皮。

灵活，才是王道。

好了，茶凉了，我得去下一个客户那儿了。

希望能遇到个讲道理的老板。

或者，至少是个愿意下仓库的老板。