中建二局深圳分公司用勤哲 Excel 服务器搭了一套劳务管理系统，先解决的就是"考评表收不齐"这件事。要说清它解决了多大的麻烦，得先看这家公司管着多大的摊子。
它是世界 500 强中国建筑股份有限公司旗下的直属区域公司，代表集团在广东、广西、海南、福建、江西等地行使总承包施工的各项管理职能，拥有房屋建筑施工总承包特一级资质。
点多、面广、线长，是这家区域公司最日常的状态。深圳地王大厦、腾讯总部大楼、腾讯滨海大厦、招商银行总部大楼、南方科技大学，这些地标都出自它的工地。
工地分散带来的第一件麻烦事，是"收表"。每到月底，劳务口的人要在几个省份之间来回催：各项目把本月合作的分供商的考评表报上来，再有人把这些表并成一张月度汇总。
月度刚过，季度又来；季度过了还有半年和全年。同一批队伍、同一套指标，只是换了个时间口径，就得重新归一次类、加一次总。
这家公司并不缺系统。OA 有，各专业条线也各自配了管理系统，问题是它们分别由不同公司开发，谁也不认谁的数据。
后果有三层。第一层是重复录入：同一个项目、同一家分供商，在 OA 里填一遍，在专业系统里再填一遍，在 Excel 台账里还有一份。
第二层是维护。系统不是自己开发的，改一个字段要提需求、排期、等版本，后期维护成本极高且不及时。业务在跑，工具却停在原地。
第三层最难补：数据不能有效利用。考评结果散在各处，想按季度横向比一比，只能靠人再去把表翻出来。
所以这次选型，公司看的不是"功能多不多"，而是"能不能自己改、数据能不能通"。
勤哲 Excel 服务器进入这家公司，靠的是一个很朴素的理由：大多数日常工作本来就用 Excel 表格，界面一样，操作一样，业务人员上手几乎没有门槛。
更关键的是角色变了——用户即开发者，开发者也是用户。谁来用，谁就能把表改到自己顺手的样子，不用等外部厂商排期。
系统落地的第一步不是建表，而是把公司的组织机构搬进去。区域公司、分公司、项目部层层挂好，后面所有权限、审批路径才有依据。
组织立住之后，功能模块按业务需要一个个往上长。目前劳务管理已全面应用，其它专业部门正在逐步完善。
模块不是一次性规划完的，而是"需要什么加什么"。这在建筑企业里格外重要——项目形态一直在变，管理系统如果三年不能改，第三年就没人用了。
劳务管理是当前全面应用的核心模块。它管的第一件事，是分供商考评。
各项目按周期给合作队伍打分，数据进入系统后，月度、季度、半年、全年的汇总分析由系统自动完成，不再需要人工二次归集。
这件事的价值不在"省了几张表"，而在"口径一致"。过去各项目自己算自己的，季度汇总时口径对不上，讨论半天还在争数据；现在大家填的是同一张模板，比的是同一把尺子。
考评结果及时出来，分供商绩效就有了连续记录。哪支队伍连续几个周期下滑，招标和派工时心里有数，不必等出了问题再回头翻账。
这套流程里，谁填、谁审、谁看，边界相当清楚。
| 角色 | 在系统里做什么 | 拿到什么 |
|---|---|---|
| 项目部劳务员 | 按周期填报本项目分供商考评数据 | 本项目历次考评记录，可随时回查 |
| 分公司劳务主管 | 审核项目上报数据，汇总全公司考评 | 月度、季度、半年、全年四套汇总分析 |
| 专业部门与领导 | 按权限查看，用于招标与派工决策 | 分供商绩效的连续记录与横向对比 |
考评管的是"用得好不好"，引进管的是"能不能进来"。后者更容易出问题：推荐人一句话、项目部一个章，队伍就进场了，资质、业绩、安全记录留在纸上，人一走就查不到。
这家公司的做法是把引进做成工作流。推荐、审核、审批各环节在系统里排好顺序，谁批的、什么时候批的、附了什么材料，全部留痕。
流程走完，这家分供商才进入合格名录，也才进得了后面的考评范围。引进与考评首尾相接，队伍的全生命周期就有了闭环。
系统目前运行正常稳定，给基层工作人员带来很大方便。基础数据还在逐步积累，积累得越厚，后面能做的分析越多。
公司已经在考虑下一步：对接企业微信，让业务工作在手机上处理。工地上的人本来就不常坐在电脑前，审批能移到手机，流程才真正跟得上现场。
这也是当初选这条路的原因之一——接口开放、能持续改，才谈得上"再上一个台阶"。
建筑企业的信息化，难点往往不在技术，而在"谁最懂业务"。最懂分供商考评的人，是劳务主管，不是软件公司的实施顾问。
勤哲 Excel 服务器把开发能力交回给业务人员：表格怎么排、指标怎么算、审批怎么走，由用的人自己定。IT 部门从"写系统"变成"管平台、管权限、管数据"。
公司对这套系统的评价是"所见即所得"。这四个字听着轻，背后是管理逻辑的转移——工具迁就业务，而不是业务迁就工具。
对管理跨度大、项目形态多的建筑企业来说，这大概比任何一个功能都重要。
