流程驱动与菜单过程：两种系统设计出发点的差别
同一套 LIMS 需求，一个团队交付了 327 个菜单、历时八个月；换一种思路，菜单降到 46 个、交付缩到两个半月。差别不在技术高低，而在项目第一天选择的出发点。
先看一个真实场景
一家公司给客户交付了一套内部管理系统，上线三个月以后是这样的：菜单三百二十七个，客户全员培训了一周，还是没人记住入口在哪；交付花了八个月，上线那天需求已经变了两版；当初写这套系统的人离职以后，剩下的同事没人敢动它的代码。
问题出在哪？不是程序员不努力，不是框架选错了，也不是需求方太善变------是从第一天开始，团队就站在错误的一边看这个系统。
左边这条路：菜单过程模式
这条路大家最熟：把一件事拆成很多功能，一个功能做一个页面，再把页面按角色分给不同的人。系统、模块、菜单三级目录；一个功能一个页面，页面之间靠人跳转；权限靠手工配置谁看得见哪个按钮。至于流程------很多团队所谓的"流程"，就是点了提交按钮之后改一下状态字段。
它的本质是：用页面承载业务，认为页面越多，业务就表达得越清楚。
这是它的信仰，也是它的陷阱：需求每来一次，菜单就长一层，最后长成一张没人看得懂的地图。
右边这条路：流程驱动模式
另一条路是这样的：先把客户的管理活动画成一条流程，用引擎驱动各个部门在这条线上协作，完成业务闭环。
每个人只有四个入口：发起、待办、在途、抄送。表单挂在节点上，节点走到谁，谁才去填。权限不是配出来的，是流程走出来的。需求变了，改的是流程模型，不是页面。
它的本质是：用流程承载业务，菜单只是这句话的载体。
一张表看懂差别
- 出发点：一个从功能出发，一个从流程出发；
- 用户入口：一个是几百个菜单靠记忆找，一个只有发起、待办、在途、抄送；
- 权限来源：一个靠手工配置，一个是流程走到那里才有；
- 协作方式：一个是人在页面之间跳，一个是数据在节点之间流；
- 应对变化：一个要改页面、改权限、再重新培训，一个改流程模型，当天生效。
真正的难点从来不是技术
既然优劣一目了然，为什么大多数团队还在左边？因为真正的难点从来不是技术，是思维。从学校到培训班，教的都是功能树加权限模型；甲方的验收单也是按菜单数量写的；市场上同行长什么样，那就是标准答案。
要跳出来需要三样东西：流程、实体、单据的基础理论；一款真正能落地的流程引擎；至少一次完整的项目实践。
一个真实的转变
说个真事。一位做 LIMS 的老板，带着技术负责人和设计原型，来现场办公两周。第一天，他接受流程思维，推翻了原有的设计；第三天，他反弹了------这样不行，我这套系统就没有菜单了，客户接受不了，市场上所有 LIMS 都是按模块菜单做的。
问题其实可以反过来问：如果您的产品跟别人一模一样，不能跟别人区分开，您要卖给客户，就只能拼界面、拼价格、拼关系，是没有竞争力的。简单好用的产品没有客户会拒绝，操作习惯从来不是问题------大道至简。
他连续两周晚上没睡好，一直在琢磨这套思想，最后想通了，满载而归。临走时可以理直气壮地说一句：我们是基于流程驱动的业务系统，他们是系统模块菜单过程的系统。
差多少：数据对比
同一套 LIMS 需求：菜单从 327 个降到 46 个，减少 86%；交付周期从 8 个月降到 2.5 个月，缩短 69%；定制代码量减少约七成；客户培训从 5 天降到半天。
省下来的不是钱，是团队最贵的东西------时间和高级人力。
冷静一下：它不是万能的
流程驱动不是万能的。它适合多人协作、有顺序、会重复发生的业务。三种场景请老老实实用传统方式：
- 纯查询统计------领导看板、BI 分析，没有流转就没有流程；
- 系统配置页------参数设置、字典维护、日志查看，单人单次操作；
- 高频写入------工业采集、秒级数据，走专有的实时链路。
正确的姿势是组合：外面一圈流程驱动负责业务闭环，中间一层实体管理负责数据维护，最上面一层报表大屏负责看数据。三者不是替代关系，是分工关系。
小结
带走三句话：
- 两种模式解决问题的目标相同，出发点不同：一个从功能出发，一个从流程出发。
- 流程驱动不是少做功能，而是换一种组织方式，菜单少 80% 不是砍需求换来的。
- 难的是思维不是技术，需要理论、引擎、实践三件事同时到位。
最后送大家一句话：世界是物质的，物质是运动的，运动是有规律的，规律是可以认识的，认识是发展变化的。