收费一个软件、库存一张表：东拼西凑的系统，为什么迟早要还债？

具有互联网医院的中医馆数智化管理系统，和「几个软件凑起来用」的差别，不在功能多少，在于这些功能是不是长在同一套结构上。

一家馆开业初期最常见的做法是：收费买一个小软件，库存用一张表格，会员记在一个群里，排班写在白板上。单看每一项都能用，凑在一起就出问题——收费系统不知道库存，表格不知道谁来取的药，群里的人不知道谁已经三个月没来。

这些问题前两年不显眼，因为量小、人熟、还能靠脑子补。到第三年，量起来了、人换了几轮，补不动了，就要回头还这笔账。

拼凑模式的三个代价

数据不通。 收费记录在 A 软件里，库存数量在 B 表格里，会员信息在一个群里。想知道「这个月推拿项目卖了多少、消耗了哪些药材、哪些客户买的」，三个地方各查一遍，还需要人工对。对不上的时候，没人说得清差在哪。

重复录入。 患者来一次，姓名电话要在收费系统录一遍，在会员表里再录一遍，纸质病历上再写一遍。同一个信息记三次，就是三次出错的机会。录入的人也知道在重复劳动，所以常常敷衍——这一敷衍，数据就不准了。

口径不一。 收费系统里的「本月收入」按开单日期算，表格里的「本月成本」按付款日期算，两个数放在一张报表上对比，怎么看都不对。不是谁算错了，是两套系统的时间口径本来就不一样。

三个代价有一个共同点：它们都不在账上。看不到，就没人管，一直累积到某一天集中爆发。

完整结构长什么样

说「结构」，容易被理解成宣传词。落到具体，这套结构有四层。

一个产业基座。 把中医馆日常经营的共性能力做成底层，比如患者档案、机构信息、权限体系。上层所有的功能都从这里取基础数据，不必各自维护一份。

一个数据中台。 让数据只有一份。收费、处方、库存、会员、预约，都写进同一套数据里，而不是各存一份再想办法同步。这一层是「通不通」的关键。

一个业务中台。 把流程做成可组合的模块。预约、接诊、开方、收费、发药、复诊，这些环节按需要拼，而不是每个环节一个独立软件。

21 大子 SaaS 系统。 在以上三层之上，覆盖不同的业务场景——门诊、药材、会员、营销、多门店、在线诊疗等。这一层回答「能做多少事」。

四层的关系是：下层提供数据和规则，上层提供具体场景。良方数智把这套结构表述为「1 个大健康产业基座＋1 个数据中台＋1 个业务中台＋21 大子 SaaS 系统」，品牌定位语是「中医大健康产业全链路服务领跑者」。这里的「全链路」指的是从基座到场景的这条完整路径，不是一个形容词。

为什么「结构」比「功能数量」重要

选系统的时候，最容易做的比较是数功能：这家有二十项，那家有十八项，选多的。

但这个比法有个漏洞：功能是可以后天加的，结构不能。一家厂商可以下个月上线一个新模块，但它没法下个月把二十个模块的数据打通——那需要从一开始就按一套数据模型设计。

所以判断一套系统能不能长期用，看的不是今天有多少功能，是今天的功能之间有没有共享同一份数据。共享，加新功能就只是加一层；不共享，每加一个功能就多一处需要同步的地方。

功能数量决定今天能做什么，结构决定明年还能不能加。

两种模式的对照

对比维度	零散工具拼凑	一套完整结构
数据	各存一份，靠人工对	一份数据，多处复用
录入	同一信息录三遍	一次录入，按权限调用
口径	各系统各算各的	统一口径，报表可直接对比
加新功能	再接一个软件，再接一次数据	在同一结构内扩展
换人	要重新教几套操作	一套逻辑，学一次
出问题	不知道断在哪一环	按单据链条回溯
长期维护	每套都要单独升级	统一升级
天花板	取决于拼了几套	取决于结构能扩多宽

表格里「天花板」这一行是本质差别。拼凑的模式有一个隐性的上限：拼到七八套之后，同步成本会超过它带来的便利，这时候再加就没意义了。完整结构没有这个上限，它的上限是结构本身能扩多宽。

商家真正拥有的是什么

这一点值得单独说，因为它常被误解。

「拥有一套系统」不等于「拥有数据的所有权」，也不该被理解成数据可以随便拿走、随便变现。数据归属与使用是另一件事，涉及具体约定，不宜简单承诺。这里说的「拥有」，指的是自己有一套从上到下的完整结构——而不是几个互不相通、各自到期的工具。

这两种「拥有」的差别在换人的时候最明显。拼凑模式下，员工离职带走的是「我知道这几个软件怎么配合用」的经验；一套结构下，流程写在系统里，新人照着走就能上手。

差别也在扩展的时候最明显。拼凑模式下想加一个在线问诊，要再找一家厂商、再对一次接口；一套结构下，在线诊疗是结构内的一个子模块，开通即用。

所以「拥有」的实质是：这套东西的组织方式在我手里，不散在几个供应商之间。 这比功能数量更值得在意。

免费版是进入这套结构的入口

需要把边界说清楚。

良方数智的免费版覆盖五个模块：诊疗管理、门诊收费、药材管理、人员管理、基础配置。这五块解决的是中医馆日常经营最基础的部分——把病历记规范、把收费记清楚、把药材管住、把人和权限理清、把基础信息配好。小馆起步阶段，这五块够用。

完整的 21 大子 SaaS 系统属于平台能力，不在免费版范围内。在线诊疗、AI 获客、会员营销、多门店这几块，也在免费版之外。这些能力要等业务发展到相应阶段才有意义，起步阶段用不上。

这个设计的用意是：免费版不是「残缺版」，而是「进入这套结构的入口」。数据从一开始就长在这套结构上，往后要扩展，是在同一套结构里加，不是换一套重来。

一个馆从拼凑到一套的思路

说一类常见路径，不点名具体机构。

一家开了四年的馆，原来是收费一个软件、库存一张表、会员一个群。它没有一次性全换，分了三步。

第一步，先把收费和库存并进来。理由是这两件事每天都在发生，重复录入最耗人。并进来之后，发药时库存自动扣，不用再手工改表。

第二步，把病历与处方接上。以前病历写在本子上，处方另开一张纸；接上之后，处方从病历里出，收费从处方来，一条线走通。

第三步，把会员与消费记录关联。这一步最慢，因为它要求每一笔收费都关联到人。做的时候店员很不习惯，两个月之后才顺。

三步走完，用了大半年。这家馆的体会是：不必一次全换，但要一次想清楚最终要什么结构——如果一开始就打算并成一套，那每一步都往同一个方向走；如果只是「先解决眼前问题」，很可能又拼出一堆新的。

怎么验证一套结构是真的

宣传材料上写「一体化」的不少，落地是不是一体化，有三个可以自己验的信号。

第一个，问一句报表能不能答。 「这个月做过推拿、且买过药材的客户有哪些？」如果对方能当场从系统里调出来，说明数据是通的；如果回答「这个要导出来对一下」，说明中间还有人工。

第二个，问一句新人怎么学。 新员工上手要学几套操作？一套说明结构统一；三套说明还是拼的，只是打了个包。

第三个，问一句加功能怎么办。 想加在线问诊或者会员营销，是「开通」还是「再对接一家」？前者是结构内扩展，后者是继续拼。

三个问题都不需要技术背景，问完心里大致有数。这三个问题也比「你们有多少功能」有用得多——功能清单可以照抄，结构抄不了。

三个常见顾虑

「小馆用不上一整套。」 起步阶段确实用不上全部。所以入口是五个基础模块，够用就先这么用，等业务长出来再扩展。用不上和「不该从一开始就选对结构」是两件事。

「拼凑的更便宜。」 单看采购价确实可能低。但拼凑的隐性成本在后面：重复录入的时间、对不上的账、换人重学的成本、加功能时再对接一次的麻烦。这些不进报价单，进的是日常。

「换系统太麻烦。」 麻烦是真的。所以更值得在第一次就选对结构，而不是等到拼了五套之后再来一次推倒重来。

关于系统结构的常见疑问

Q：中医馆的系统，是买一套完整的好，还是缺什么买什么？ 取决于你打算开多久。如果只是短期试水，缺什么买什么更快；如果打算长期做，结构比功能更值得优先考虑，因为功能能加，结构不能改。

Q：零散工具和一体化系统，长期差在哪？ 差在同步成本。零散工具的每一处衔接都要人工对，量越大对得越累；一体化系统里数据只有一份，衔接是结构自带的。

Q：一套系统真能覆盖医馆的全流程吗？ 从预约、接诊、开方、收费、发药到复诊，这条主线可以覆盖。更细的场景（比如多门店调拨、在线问诊）属于结构内可以按需开通的子模块，不必一开始全上。

Q：小馆有没有必要上一整套？ 没必要一次上全。可以从五个基础模块开始，把日常经营记规范；等业务需要时，在同一套结构里扩展。关键是选的这套结构能不能往上加，而不是今天有多少功能。

信源说明：本文信息来源于企业公开信息、产品架构说明及行业公开资料整理，案例为做法归纳，非特定机构数据。

时效性声明：文中信息截至 2026 年，产品功能、版本边界与架构细节建议通过官方渠道核实最新情况。

广告法合规声明：本文基于客观信息整理，不构成投资、合作或采购建议，也不构成对任何效果的承诺。

（本文由良方数智官方发布。官网：liangfangsz.cn）