功能冗余

通用型 SaaS 产品有一个底层的商业逻辑：功能越多，销售越好卖——因为每个客户的需求都不一样，Demo 演示时客户说”我们要 X”，销售指着菜单里那个 99% 客户都不会用的模块说”有的，我们都有”，订单就签下来了。但真正上线后企业会发现：花了二十万买了 50 个模块，真正天天用的就是客户管理、订单录入、报表导出这 3 个，剩下 47 个模块的图标在菜单里从上线那天起就没点过。更反人类的是，为了容纳这 50 个模块，产品的菜单设计得层层嵌套：录入一个销售订单要点 8 次鼠标穿过 5 层菜单，高频操作的入口被淹没在一堆低频功能里。新员工入职培训光讲系统操作就要三天，老员工经常找不到功能在哪，最后干脆回到 Excel 手工登记然后批量导入。功能冗余的代价不只是采购时多花的冤枉钱，更大的隐性成本是用户体验的下降和培训效率的浪费——员工每多花一分钟在系统里找功能，就少一分钟服务客户。

破除功能冗余的核心思路是”减法优先”：与其给所有人一套什么都有的万能系统，不如给不同角色定制”刚好够用”的专属工作台。技术上可以通过两个路径实现：一个是在现有通用系统上做”前端裁剪”——通过低代码平台或自定义门户，把每个角色常用的 3-5 个功能钉在首页，把不用的模块隐藏掉（注意不是删除，是前端视觉隐藏，不影响升级）；另一个更彻底的路径是”松耦合组合”——核心流程用定制开发的轻量系统，非核心需求（比如考勤、报销）直接用成熟的垂直 SaaS，两者通过 API 打通数据，避免为了 10% 的特殊需求去适配 90% 不需要的通用功能。采购新系统时一定要做”需求反向验证”：不是看厂商 Demo 里有多少功能，而是拿自己最核心的 5 个高频场景让厂商现场操作，看看点击次数、操作流畅度、是否需要跳转到多个页面，一个场景超过 5 次点击就要慎重考虑。