这个事儿，说大不大，说小不小，却是所有科室都绕不开的“老大难”。林晓在整理历史投诉数据时发现，近三年来，关于“路灯不亮”“下水道堵塞”“健身器材损坏”的投诉，占了社区总投诉量的40%，而这些投诉里，有60%都因为“流程慢”“没人管”被反复投诉。她还翻到了去年行政科做的一份调研：一个简单的路灯维修申请，平均要走5个部门——居民先找社区，社区报给街道，街道再转到中心业务科，业务科派单给维修科，维修科修完了再反馈给社区，最后由社区告知居民。整个流程下来，快则一周，慢则半个月，中间只要有一个环节卡住，就会无限期拖延。

小主，

更让人头疼的是，每个环节都有理由推诿：社区说“我们只是传话的，没权力催维修科”；业务科说“维修科人手不够，我们也没办法”；维修科说“没有明确的维修范围划分，有些活儿不知道该不该我们干”。最后问题没解决，居民怨声载道，各科室还互相埋怨，好好的事变成了“烫手山芋”。

“就从这儿破局！”林晓拍了下桌子，兴奋得差点跳起来。她要做一个“社区公共设施维修申请线上协同模板”——不碰任何科室的核心数据，不改变现有的数据存储方式，就单纯做一个“流程导航图”，把谁该干什么、该在多久干完、需要什么数据、数据从哪儿拿，都明明白白写清楚。

说干就干。林晓先把近三年的维修投诉案例都调了出来，按“路灯”“下水道”“健身器材”“公共门窗”分成四类，统计出每类问题的平均处理时间、常出问题的环节、涉及的部门。然后她又找了业务科的李哲、维修科的老吴，还有社区的网格员小张，趁着午休的时间聊了好几次——不是去“采访”，就是拉着人家吃盒饭，听他们吐槽工作里的难处：

“李哲，你们业务科派维修单的时候，最头疼的是不是不知道维修科谁有空？”

“老吴，你们去修东西，是不是经常找不到小区的设施分布图，得跟社区反复确认位置？”

“小张，居民找你报维修，你是不是总没法跟人家说准啥时候能修好，只能让人家等着？”

这些一线人员的吐槽，成了模板里最关键的“细节”。林晓把这些问题都融进了模板设计里：她在流程里加了“维修科人员排班查询入口”，直接链接到维修科的内部排班表；她把各小区的公共设施分布图做成了缩略图，附在申请单后面，点击就能放大查看；她还给每个环节设了“超时提醒”，要是某个部门在规定时间内没处理，系统会自动给负责人发提醒消息。

模板的框架很快就搭好了。她用Visio画了清晰的流程图，每个节点都标着“责任部门”“办理时限”“所需数据”“数据获取路径”：

1. 社区网格员上报：责任部门（社区），时限（1个工作日），所需数据（居民投诉记录、设施位置信息），数据路径（社区居民投诉台账、中心设施管理系统）；

2. 业务科派单：责任部门（业务科），时限（1个工作日），所需数据（维修科人员排班、设施维修历史记录），数据路径（维修科排班表、业务科维修台账）；

3. 维修科施工：责任部门（维修科），时限（3个工作日，紧急情况1个工作日），所需数据（设施型号、维修材料库存），数据路径（中心设施管理系统、后勤科材料库存系统）；