这不是一个罕见的倒闭故事。它之所以值得写，恰恰因为它太普通：很多小厂商都可能在同一个路口，把市场机会误判成自己的交付能力。

朋友说，他们公司快没了。

一开始我以为这只是项目现场常见的情绪化表达。做系统的人都懂，上线前后，谁没说过几句“项目要死”“公司要完”“我不干了”。

但他很平静。

他说，办公室现在没什么人了。原来二三十人的研发和实施团队，只剩下两三个还在撑。工位空了一大片，桌上还有人走之前没带走的水杯。墙上的白板停留在去年某次项目例会，上面写着几行没擦掉的任务：门诊收费联调、医保结算回归、村医培训安排、验收材料补充。

这些字还在，写字的人已经不在了。

他们是一家医疗信息化公司，原来主要做 PACS，也就是医院影像系统。公司不算大，但在本地有一些客户，日子谈不上很好，也不是完全没活路。后来，老板判断县域医共体建设会带来一波机会，认为只做 PACS 天花板太低，HIS 才是医院的入口和底座。

这个判断并不荒唐。近几年，县域医疗、基层能力提升、区域协同、数据互通，确实不断出现在政策文件、行业会议和招标公告里。只要稍微关注医疗信息化，就很难不被这种气氛影响。

于是，公司买了一套 HIS 源码，准备在此基础上改造、二开，再用一个医院项目打样板。老板的想法很朴素：第一个项目可以少赚，甚至不赚，只要能跑通，就有案例；有了案例，后面的医共体项目就能接上。

可后来发生的事情证明，他们拿到的不是样板工程，而是一口很深的井。

​

01 他们以为自己买到了一套系统

朋友第一次看到那套 HIS 源码时，心里其实有点发虚。

代码能跑，页面也不少。挂号、收费、医生站、护士站、药房、入出院、报表，看起来都有。老板看演示时很满意，觉得这事有谱。

但研发真正打开代码以后，才发现里面有很多说不清的东西。有些字段名像是十年前某家医院的简称，有些逻辑绕了几层，却没人知道为什么。一个收费判断里套着好几个特殊规则，注释只写了四个字：“某院特殊”。还有一些看似没用的开关，删掉怕出事，不删又不知道怎么解释。

最开始大家还乐观。研发觉得，再复杂也是代码，总能读懂；实施觉得，只要先上线，后面慢慢调；老板觉得，第一家医院愿意给机会，已经很不容易，先做进去再说。

后来他们才明白，源码不是产品。

源码只是别人踩过坑以后留下的一部分痕迹。你能买到这些痕迹，却买不到当年为什么这样设计，哪些地方不能动，哪些流程背后牵着医院内部什么关系。

一套 HIS 不是几百个页面加几千张表。它更像医院日常秩序的电子化版本。医生怎么开医嘱，护士怎么执行，药房怎么发药，收费处怎么结算，医保怎么对账，病案室怎么归档，院长怎么看经营数据，信息科怎么处理突发问题，这些东西凑在一起，才叫 HIS。

代码只是最容易被看见的部分。真正难的，是那些没写在代码里的东西。

买到源码，不等于买到产品能力。

可以买到表结构，但买不到业务边界；可以买到页面，但买不到实施方法论。

02 第一个项目从低价中标开始变形

他们很快低价拿下了一个医院项目。

中标那天，公司气氛不错。老板请大家吃了一顿饭，说这个项目是公司的转折点。有人开玩笑说，以后公司就从 PACS 厂商升级成 HIS 厂商了。研发负责人也给团队打气，说大家辛苦一阵子，把这个版本打磨出来，后面就好复制。

这类话，在很多小软件公司都出现过。

那时候，大家还没有意识到，低价中标的那一刻，风险并没有结束，反而正式开始计息。

医院不是一个抽象客户。医院里有门诊、住院、药房、护理、医保、财务、病案、检验、检查、后勤、信息科。每个部门都有自己的流程，也有自己的脾气。

项目刚启动时，需求调研看起来很顺利。医院各科室都说支持信息化建设，也愿意配合医共体工作。可一到具体细节，情况就不一样了。

医生说，原来的系统三步能开的药，现在要点七下。护士说，医嘱执行界面不顺手，忙的时候容易漏看。药房说，库存逻辑不对，实际药品批号和系统批号经常对不上。收费处说，退费流程太绕，患者排队时解释不清。

乡镇卫生院的人也有意见：县医院那套流程太复杂，基层根本用不起来。村医培训时，有人直接问：“这个系统能不能少填一点？我们一天看不了多少病，但表比病人还多。”

这些反馈没有一条是完全无理取闹。可它们堆在一起，就变成了小公司承受不了的重量。

研发改一版，实施去现场试。现场试完，又带回一堆新问题。今天调药房，明天改医保，后天补报表。一个模块刚修好，另一个模块又被影响。

到了后期，很多问题已经不是系统本身能不能改，而是没有人能把需求讲清楚。医院内部不同部门的口径不一致，县医院和基层机构的习惯不一致，旧系统和新系统的数据也对不上。

朋友说，有段时间他们像是在做“人肉中间件”。系统跑不通的地方，先用 Excel 补；接口传不准的数据，人工核；基层不会用的功能，实施人员远程一步步教；医生急着看诊，研发就在电话这头临时改配置。

低价中标不是胜利，而是项目债务的起点。

03 HIS不是软件项目那么简单

很多没做过医院核心系统的人，会低估 HIS 的复杂度。

他们以为它和其他管理软件差不多，只是行业不同。企业有 ERP，学校有教务系统，医院有 HIS，本质上都是流程管理。

但医院不太一样。

医院系统的每一次卡顿，都可能直接出现在窗口前的患者队伍里。医生站慢一分钟，诊室外的人就开始焦躁。医保结算出一次错，收费窗口就会被堵住。药房库存不准，患者可能拿不到药。住院流程走不通，护士站、医生、财务、病案都会被牵连。

这不是一个普通后台系统。HIS 是医院运行的一部分。它表面上是软件，实际嵌在医院的组织流程里。

所以，一个 HIS 项目真正考验的，也不是单纯写代码的能力。它考验的是厂商对医院业务的理解，对实施节奏的控制，对需求边界的判断，对历史数据和接口的处理，对上线风险的预案，以及持续运维的能力。

小公司最容易犯的错误，是觉得“能开发”就等于“能交付”。

这两者之间，差得很远。开发可以在办公室里完成，交付必须在真实医院里接受检验。真实医院不会按照产品经理设计的流程运行，也不会因为乙方团队辛苦就降低要求。

医生不满意，会直接说。护士用不顺，会直接骂。信息科扛不住压力，会把所有问题都转给乙方。院领导看到基层反映不好，就会重新审视整个项目。

这些都不是合同里几行“系统功能要求”能覆盖的。

医疗信息化看起来是软件，做久了才知道，它真正处理的是流程、责任、习惯和风险。

04 领导一换，项目进入另一种状态

这个项目拖了很久。

拖到后来，医院分管领导换了。

这件事对项目影响很大。原来推动项目的人，至少知道当初为什么要上这个系统，也知道一些历史背景。新领导上任后，看到的是一个迟迟没有验收、科室意见不少、基层反馈一般、乙方又不够稳定的项目。

他当然会谨慎。

站在医院角度，这种谨慎也合理。HIS 是核心系统，一旦签了验收，后面出了问题，谁来负责？如果基层医生不满意，医共体推进受影响，谁来解释？如果系统后续运维跟不上，医院是不是要重新花钱、重新折腾？

于是项目进入一种很尴尬的状态。系统不能停，因为已经有部分业务在用；问题不能少，因为流程还没完全理顺；验收不能签，因为风险还没有消除；尾款不能付，因为验收没有完成；乙方不能撤，因为一撤就更麻烦。

朋友说，最难受的不是被骂，而是看不到尽头。每天都在处理问题，每周都在开协调会，每个月都觉得下个月能验收。可每次快到验收节点，又会冒出新的问题。

一个项目如果拖成这样，已经不再只是技术问题了。它变成了信任问题、组织问题和责任问题。

医院不相信乙方能长期撑住。乙方也没有资源继续无底线投入。双方都知道这个项目有问题，但谁也不能轻易把它停掉。

05 公司被第一个大单拖空了

这家公司原本想通过第一个 HIS 项目打开局面。结果恰恰相反，它被第一个项目拖空了。

研发被绑在这个项目上，实施被绑在这个项目上，老板的精力也被绑在这个项目上。公司原来 PACS 业务的节奏被打乱，新的 HIS 订单又没有真正打开。

他们也去投过一些标。朋友说，有时候拿到招标参数的一瞬间，就知道自己大概率没戏。

这句话很扎心。

做行业久了的人都明白，有些招标文件虽然看起来公开，但参数写法、资质要求、案例条件、技术路线、功能描述，都可能带着明显的方向感。不一定每次都能说清楚问题在哪里，但业内人一看就知道，这不是给你准备的题。

小公司最痛苦的地方就在这里：不投标，没有机会；投标，很多时候只是陪跑；低价冲，可能把自己拖死；正常报价，又很难中；想做大系统，能力和资源不够；退回小模块，又容易被集成商压价。

这时候，公司会越来越焦虑。老板不断找机会，销售不断追项目，研发不断救火，实施不断填坑。表面上大家都还在忙，但公司其实已经失去了节奏。

最后，人开始走。

先走的是年轻研发。他们觉得继续待下去学不到东西，也看不到前景。然后走的是实施。长期出差、长期被骂、长期背锅，谁都扛不住。再后来，骨干也走了。因为他们知道，公司不是暂时困难，而是结构性地撑不住了。

朋友留下来，不是因为多有信心，只是因为项目还没彻底交出去。他说，有时候晚上看到运维群里又跳出消息，心里第一反应不是焦虑，而是麻木。

一个公司死掉，有时候不是轰然倒塌。它是慢慢安静下来的。群里说话的人越来越少，会议取消得越来越多，工位空得越来越快。直到某一天，大家发现，它其实已经不再是一家公司，只是一两个还没结束的项目。

06 县域医共体不是风口那么简单

这件事里，最值得讨论的，不是某个老板有没有眼光，而是很多小厂商都会产生类似误判。

他们看到县域医共体，看到区域医疗协同，看到基层信息化升级，就觉得这是一个风口。

从市场判断上说，这没错。问题在于，政策带来的需求，不会自动变成企业利润。

县域医共体信息化并不是给县医院装一套系统，也不是把县医院系统复制到乡镇卫生院。它要处理的是县、乡、村之间的协同，是医疗、医保、公共卫生和运营管理之间的数据流转，是不同机构、不同人员、不同利益诉求之间的磨合。

县医院希望统一管理，乡镇卫生院希望减轻负担，村医希望系统简单好用，公卫条线希望数据完整，医保部门关心规则和合规，院领导关心指标、报表和责任。

这些需求放在一张蓝图里，看起来很完整；落到一个项目里，就会变得非常具体，也非常难做。

对大厂来说，这种复杂度可以靠产品体系、项目管理、资金储备和客户资源去消化。对小厂商来说，如果没有足够的行业积累，很容易被复杂度反噬。

他们以为自己冲进了一个大市场。其实是走进了一个高强度、长周期、重交付、低容错的项目现场。

07 小厂商不是不能活，但要知道自己该站在哪里

小医疗信息化厂商当然还有活路。只是这条活路，未必是正面去抢医院核心 HIS。

有些公司适合做专科系统，就应该把专科做深。医院不缺泛泛而谈的大平台，缺的是在某个具体场景里真正好用、稳定、能解决问题的产品。

有些公司适合做大厂生态里的组件，就不要非要当总包。成为一个可靠的模块供应商，听起来不够风光，但比硬扛一个自己交付不了的大项目安全得多。

有些公司适合做轻量工具，比如医保审核、病案质控、接口监控、数据治理、运营分析、基层随访、慢病管理。它们不一定站在医院信息化的中心，但如果能解决具体问题，也能活得很好。

还有一点更重要：小公司一定要学会拒绝项目。尤其是那些低价、重定制、验收周期不清晰、付款条件苛刻、客户内部口径不统一的项目。

有些订单不接，只是少赚一点。接了，可能会把公司拖进一个看不到底的坑。

老板最容易在这种时候说一句话：先拿下来再说。

但医疗信息化项目，最怕的就是“先拿下来再说”。拿下来之后，需求会来，问题会来，责任会来，医院的日常运转也会压到你身上。到那时，再说自己资源不够、经验不足、现金流紧张，都已经晚了。

08 医院也要重新理解低价

当然，这件事不能只怪乙方。医院在采购信息化系统时，也需要重新理解“低价”的代价。

HIS 不是买一批电脑，也不是买一套办公软件。它是医院长期运行基础设施的一部分。一个报价低到明显无法覆盖研发、实施、培训、运维和持续升级成本的项目，后面大概率会以另一种方式补回来。

可能是系统质量差，可能是上线周期长，可能是运维没人响应，可能是需求不断扯皮，也可能是乙方公司自己先撑不住。

最后，医院看似省了采购成本，却付出了更高的管理成本和时间成本。更严重的是，系统一旦烂尾，受影响的不只是信息科，而是医生、护士、患者和整个医院的运行。

所以，医院选供应商时，不能只看价格，也不能只看演示。更要看这个团队有没有做过类似项目，有没有稳定的实施人员，有没有持续服务能力，有没有清晰的项目边界，有没有足够的财务健康度。

一个便宜但活不下去的供应商，可能比一个报价略高但能长期负责的供应商更贵。

09 最后

朋友最后跟我说，他们现在还在维持那个项目。不是因为公司还有多少希望，而是系统还在医院里跑。哪怕跑得不漂亮，也不能说停就停。

我听完之后，心里很复杂。

这不是一个多么罕见的故事。它没有惊心动魄的商战，也没有戏剧化的反转。它只是医疗信息化行业里，一个小公司在错误时间、用错误方式、接下错误项目以后，慢慢耗尽自己的过程。

这样的故事之所以值得写，是因为它太普通了。很多小厂商都曾经站在类似的路口。

一边是原有业务的天花板，一边是政策和市场带来的新机会；一边是老板想做大的冲动，一边是团队真实能力的边界。

真正难的，不是看见机会，而是判断这个机会是不是属于自己。

那家小 HIS 厂商的死，表面上死于一个没做完的项目。实际上，死于对行业复杂度的低估，对源码的迷信，对低价中标的侥幸，以及对自身能力边界的忽视。

这可能也是它留给同行最后的提醒。

有些风口，远看是机会。走近了，才发现是深水区。

阅读原文：https://mp.weixin.qq.com/s/nnMDivuuj-WlyMlbCez0EQ