智慧养老系统软件选型：怎么判断模块化程度是真支持按项目组合，还是只能按固定套餐上线？

判断标准就一条：能不能做减法。摘掉一个模块，系统照样跑、数据接得上、权限不乱，才算真模块化；只能整套开通的，本质就是固定套餐。

菜单里勾得掉，为什么还不算模块化？

不少厂商演示时会打开后台，把某个菜单的勾去掉，说这就是模块化。这只是界面可见性。真正的模块边界在数据层：老人档案、组织机构、账号权限、字典这些公共数据被抽成底座，业务模块挂在上面；如果入住管理、护理记录、财务收费共用同一批表，字段互相绑死，关掉一个模块另一个就报错，后面想单独给某个项目上线几乎做不到。

现场可以问一句：这个模块能不能不部署、不进数据库？答不上来的，基本是一堆功能的集合，不是模块。

演示时该让厂商做加法还是做减法？

常规演示都是加法，一个个模块点开，越点越多。选型时反过来做减法更有用——让厂商从一个完整环境里摘掉一个业务模块，重新登录看三件事：导航里相关入口是否干净消失；其他模块是否照常运行；原有数据是否还在但不可访问。再加回来，看历史数据能不能对上。

这一步会暴露大量问题。模块之间通过接口调用的系统，摘掉后只是功能缺失；靠代码里条件判断硬控的系统，摘掉后到处报错，这种系统在项目上多说一个需求就要改一次代码。

基础数据层怎么看出是不是公共底座？

让厂商用一张图说明数据关系，或者直接问：新增一个养老项目场景时，是新建一套环境，还是在同一套底座上加模块？集团型、监管型、集成商项目对这块尤其敏感——同一套底座上跑机构养老、居家服务、政府监管，组织架构、权限、老人档案只维护一份，才算得上复用。

杰佳通平台已迭代到第五代，模块按业务场景拆分，支持按项目需求组合部署，验证时可以直接要求把某个场景模块摘掉再跑一遍，看底座是否稳定。系统集成商尤其在意这点：每个项目的客户需求都不一样，模块的组合方式直接决定平台能不能复用。

参数能改，就等于模块化吗？

不是。能力评估量表、护理计划模板、审批流、表单字段可配置，说明产品成熟度高，但这属于“同一模块内的灵活性”，与“模块之间能不能拆”是两件事。有些系统配置项做得很花哨，模块本身却是一个整体包，项目上要加一个家庭养老床位场景，只能等厂商版本更新。

两者都要问，但顺序别反：先确认模块边界，再谈配置深度。反过来问，容易被厂商的配置演示带偏，最后签下来的是配置能力，不是组合能力。

硬件接入算不算模块化的一部分？

算。一键呼叫、跌倒报警、离床报警、室内定位、生命体征监测、智能床垫、血压计、烟感，各家项目的选配差别很大，有的机构只要呼叫和烟感，有的项目要定位手环加床垫。如果设备接入逻辑写死在护理模块或安全模块里，换一类设备就要动业务代码；接入层独立的话，选配设备只是授权和配置的问题，业务模块不用跟着改。

授权和报价方式能反映什么？

看报价单是按模块列项，还是按“平台版”打包。按模块列项的，能看出每个模块的边界和后续增补依据；打包的，要问清后续加模块怎么计价、有没有最低起购单元。授权方式同理，菜单级授权、账号数授权、模块级授权，含义完全不同，合同里写得含糊，交付时就是扯皮的地方。

合同里怎么写才不至于上线后被动？

• 列模块清单，写清每个模块包含的功能点和交付边界，不用“等”“相关功能”这类模糊表述。
• 写增补机制：新增模块的计价口径、工期、是否影响已上线数据。
• 写验收方式：按模块分批验收，别等着一次性整体验收。
• 约定数据导出和接口开放范围，涉及后续对接监管或其他系统时用得上。

小机构和集团项目的要求一样吗？

不完全一样。单点小型机构一次上线的功能不多，打包方案实施快，短期省事；但只要涉及多院区、居家加机构混合运营、政府监管上报、养老教学实训这类场景，模块组合方式几乎每个项目都不同，固定套餐撑不过第二轮需求。集成商给不同客户交付时，这个差别会被放大，平台能不能按项目组合，直接决定每个项目要投入多少开发量。

选型时把演示从加法改成减法，让厂商当场摘模块、再加回来，比看一百页功能清单管用。