夜雨聆风维保合同签了，钱也付了，为什么干活还是我？
“我感觉自己不是在为医院服务，而是在给软件公司打工。”
这是某三甲医院信息科工程师小张，在一次加班到深夜后的真实吐槽。那天，HIS系统突然卡顿，临床科室电话被打爆。他一边远程排查，一边联系软件公司的售后。
软件公司客服说：“这个不属于紧急响应范围，明天上班处理。”
小张只好自己熬夜修。
类似的故事，在全国各地的医院信息科里，每天都在上演。
一、维保买了，为什么我还要干活？
先看一个典型场景。
医院每年花几十万购买某核心系统的维保服务，合同上白纸黑字写着：7×24小时响应、故障远程支持、必要时现场服务。
可现实操作中，经常是这样的：
· 系统出个小问题，信息科自己先排查，因为“小事找他们太慢”；
· 电话打过去，客服让你“提交工单、走流程”；
· 好不容易接通工程师，对方却说“这个需要定制开发，不在维保范围内”；
· 如果要额外开发，又要报价、审批、走合同……
临床科室催得急，信息科只能自己动手——改报表、修接口、调参数、甚至绕开系统做补丁。
久而久之，维保公司成了“按兵不动”的后援，信息科成了“随时顶上”的一线。 活干得越来越多，但干的活，本该是软件公司维保该做的。
这就不难理解为什么很多信息科的人会说：“我们不是在为自己的医院干活，是在给软件公司擦屁股。”
二、信息科到底是谁的人？
要回答这个问题，先得看信息科在医院体系中的真实位置。
对医院而言，信息科是“消耗型部门”
临床科室是“创收主力”，行政后勤是“服务支撑”。信息科往往被视为花钱的、修电脑的、拉网线的。
如果系统跑得顺，没人记得信息科；一旦卡顿、断网、数据丢失，信息科第一个背锅。
对软件公司而言，信息科是“免费实施团队”
软件公司心里很清楚：医院的系统维护，其实大量依赖信息科自行消化。
为什么？
· 医院不可能让软件公司的人24小时驻场做所有琐事；
· 信息科熟悉本院业务流程，沟通成本低；
· 信息科“不敢让系统出事”，所以永远愿意兜底。
于是，软件公司“卖维保、收维保费”，但把大量本应自己完成的基础维护、巡检、培训、小修小补，无形中转嫁给了信息科。
信息科，既不是软件公司的员工，却干着软件公司的活；既属于医院，在医院内部话语权和资源却有限。
说难听点，就是“两头不靠岸，干最累的活，背最沉的锅。”
三、信息科，到底为谁服务？
答案其实很明确：信息科存在的唯一理由，是为医院服务。
但现实是，信息科要服务好医院，必须学会管理软件公司，而不是被软件公司牵着走。
现在很多信息科的问题出在这里：
1. 维保合同签得太“大路货”
没有细化服务清单、响应时限、责任边界。结果就是“什么都包，什么都没包”。
2. 缺少对软件公司的考核机制
人家响应慢、推诿、派新手，信息科也没有“扣钱”或“换人”的抓手。
3. 信息科内部缺乏标准运维流程
哪些事信息科自己做，哪些事必须由软件公司解决，没有明确划分。到最后，所有事都压在自己人身上。
结果是：软件公司拿着维保费用，干最少的活；信息科没多拿一分钱，却多干了一堆活。
这不是“给软件公司打工”，是什么？
四、出路在哪里？
信息科要摆脱“编外运维”的尴尬身份，必须要做三件事：
1. 把维保合同谈细、谈透
下次签维保合同时，建议逐条明确：
· 哪些故障必须在多少分钟内响应；
· 哪些类型的修改属于免费服务；
· 超出范围的，如何报价、谁确认；
· 达不到SLA，如何扣减费用。
别把维保当作“买了就完事”，要当作“买了一个可以管理的工具”。
2. 建立自己的运维“防火墙”
信息科内部要明确分工和边界：
· 日常巡检、基础操作培训、数据备份——信息科自己负责；
· 核心系统bug、接口异常、性能调优——必须由软件公司解决。
同时建立台账：哪件事是谁做的，花了多少时间，是否符合合同约定。数据说话，以后好问责。
3. 向上管理，让医院领导听懂“信息科的价值”
很多医院领导不懂技术，他们只看到“信息科老找厂家要钱”。
信息科要学会翻译：
· “这个bug我们不修，临床工作效率下降X%”；
· “接口不升级，未来电子病历评级过不了”；
· “维保不到位，系统一旦瘫痪，全院停摆”。
把技术语言翻译成管理语言、风险语言、钱的语言。 领导听懂了，资源才可能倾斜。
五、写在最后
信息科不是软件公司的免费劳动力。
信息科是医院信息化建设的中枢神经，是连接临床、管理、技术的桥梁。
但现在，太多信息科的兄弟姐妹被夹在中间，做着最难、最累、最不讨好的事。
如果你也是信息科的一员，请记住：
你不为任何软件公司打工。
你为医院服务。
而服务医院最好的方式，就是学会管理好那些软件公司。
从今天开始，别再默默“擦屁股”了。
把边界划清楚，把责任分明白，把合同用到位。
医院的信息化，不该靠信息科的一腔热血硬撑，而应该靠一个成熟、有序、权责清晰的运维体系来保障。
你呢？你今天又给哪家软件公司“打了白工”？
欢迎在评论区说出你的故事。
