我的案例

石化建筑施工企业交付一个项目，并不等于事情结束。保修期内的质量跟进是硬任务，业内叫用户回访：屋面有没有渗、设备基础有没有沉降、管道保温有没有开裂，都要问一遍、记一笔。

这家企业的项目管理部把两件事放在同一个平台上：一是项目电子档案，二是用户回访。平台是用勤哲 Excel 服务器搭的，从建模板到上线，一共花了五天。

项目电子档案相当于项目的履历：工程概况、实物工作量、专业工程划分、项目部人员，谁在什么时间干了哪一段，都记在里面。这份履历要动态更新，还要传给经营、技术、财务多个部门。

过去的问题是信息分散。档案在项目部的电脑里，改动靠拷文件；回访计划在另一张 Excel 上，年底一忙就漏项。两份数据谁也不认识谁，项目编号都对不上。

回访记录本来是最有价值的质量数据：哪个部位容易出问题、哪位项目经理负责的项目投诉少。可它只躺在纸面上，既没法统计，也没法用来评价。

档案模块分成两块：录入和查询。录入还是 Excel 的界面，合同工期、实际竣工日期、项目重要事件、项目部主要成员、作业单位与分包情况，一列一列填，点保存直接进数据库。

表格按合同签订日期所在的年份自动排列。哪一年的项目、哪一年交付的，翻到对应年份就能找到，不必再问“那个 2019 年的罐区项目放哪了”。

项目部成员、分包关系这些信息，过去散在任命文件和分包合同里。现在进同一张表，人员和项目之间建立了可以反查的关系。

查询是这套档案真正被频繁使用的地方。年度范围、承包模式、项目经理、合同金额范围、建设单位、作业单位、分包方名称，七个条件可以任意组合。

组合查询解决的是现实里的问法：“2020 到 2022 年、石化装置、张经理负责、合同额一千万以上的项目有哪些？”过去要几个人分头翻合同，现在选几个条件就出来了。

结果列表里点工程名称，直接进详情。查一个项目曾经的分包方，或者查一个分包方干过哪些项目，都是同一条路径。

回访分四块：年度计划、回访单、完成情况查询、满意度汇总。四块不是四个孤立的表，而是同一条流程的四个截面。

做年度计划时，项目清单从档案里取。系统只允许选未回访的项目，已经回访过的根本不出现在候选里。这一条限制，把“漏项”和“重复回访”同时堵住了。

选定工程名称，建设单位、项目经理、竣工日期这些信息自动带过来，计划员不用再抄一遍。抄写少一次，错的机会就少一次。

回访单在回访结束后填。现场看到的问题、业主的答复、处理意见逐项写清，纸质的签字单拍照或扫描后作为附件上传，和这条记录绑在一起。

有了统一的评分口径，满意度就能按年度汇总。哪个年度交付的项目投诉集中、哪类工程遗留问题多，图上能看出来，不必等业主再打一次电话。

完成情况查询回答的是另一类问题：今年的计划做了几项、还差几项、哪个项目部拖着没去。年底考核项目经理，这一栏比印象可靠。

档案和回访的所有信息，局域网能查，互联网也能查，还能导出成 Excel 带走。项目部门口贴一张二维码，扫开就是这套系统。

对常驻现场的人来说，这一条比功能多少更重要。业主问起三年前的竣工日期，不必回办公室开电脑；在手机上翻到项目，日期、成员、回访记录都在。

系统上线后先在项目管理部推广。五个工作日做出来的东西，能不能用，同事的反馈比验收报告直接。

这套系统能被五天做出来，不是因为功能简单，而是因为两件事本来就是一件事的两面：项目是主体，回访是它在保修期里的后续。只要项目编号这个键立住，剩下的都是引用。

勤哲 Excel 服务器提供的正是这种“表与表之间能挂上钩”的能力：Excel 负责录入的顺手，数据库负责关系的可靠，工作流负责该谁办、办到哪一步。

对施工企业来说，档案不怕多，怕的是各存一份。一份数据只有一处源头，后面无论是查项目、排回访还是算满意度，都不用再对账。