我的案例

2014 年，平安银行广州分行接连推出各类银行产品，各业务条线都需要配套的电子化平台，用来优化内部管理流程和业务报表。分行用勤哲 Excel 服务器陆续搭了几个这样的系统，最早投用的一个，是流程优化建议的报送审批。

运营条线当时正在做一件事：向全分行征集流程优化建议。征集不难，收口难。

几百个网点各自把建议写成邮件发上来，格式不一、要素不全，有的只写一句"希望简化开户流程"，有的连网点名都没留。管理人员只能一封封看、一条条整理，再线下评审。

科技部要做的，是把这个过程搬上线：为 500 多位用户提供一个电子化的集中处理平台，让上报、审批、补充意见都在系统里完成。

这套系统从开发到测试完成，用了一个半月。

银行不缺开发能力，缺的是排期。科技部的项目池里排着一堆核心系统，一个只服务内部流程的"建议征集"项目，很难抢到优先位置。

按传统 IT 开发方式，这类需要跨部门协同、但流程本身并不复杂的系统，投入大约在 30 到 60 个人月。人力一排，业务部门往往要等上几个月。

用勤哲 Excel 服务器的测算则是 20 到 40 个人月，周期缩短三到五成。原因不神秘：表单、权限、流程、查询这些通用能力平台已经做好了，开发人员只需把业务规则配出来。

2014 年 10 月，分行采购了勤哲 Excel 服务器 2013 版。选择它的理由写得很直白——能解决需求，投入成本低，开发周期短，适合"跨部门协同、流程简单"这一类管理系统。

系统的核心是一张表：网点流程优化建议申报表。所有环节都围着它转。

第一个环节是上报。网点人员填写建议内容、涉及环节、预期效果，提交即进入流程，不必再发邮件、打电话确认收到没有。

第二个环节是初审。初审员按统一口径审阅，给出评分和意见。第三个环节是复审，第四个环节是补充意见与发布——每一步的结论都写回同一张表，形成完整记录。

表单之外，系统还提供了查询与统计：哪些网点提得多、哪类建议集中、评审进度如何，都能按条件调出来。

建议征集最容易走过场：收上来一堆，评的时候凭印象，评完没有下文。这套系统把评审规则明确写进了流程。

初审员对每条申报项目给出"好、一般、差"三档评分。不是一个人说了算——超过半数通过，才进入复审。规则写在系统里，谁也不能临时改口径。

复审员通过后，所有运营人员都可以补充意见。这一步看似多余，实际是把执行层面的经验引进来：坐在网点的人，最清楚一条建议落地会卡在哪。

最后由复审员再次审核，形成结论并发布。一条建议从提出到定论，路径固定、留痕完整。

这套流程设计得比较巧的地方，是它自带制衡。

初审评的是各网点报上来的建议，被考评的是报送单位；终审又反过来制约初审——如果初审把关不严，终审可以否决。两头互相盯着，评分才不至于变成人情。

系统还保留了一票否决的权力。遇到明显不合规、或者与分行导向相悖的建议，可以直接终止，不必走完全部环节。

这些规则听起来像管理制度，实际都落在表间公式和工作流里：分数怎么算、够不够半数、该流转给谁，由系统判断，不靠人记。

平台上线一年，分行陆续建起了多个应用系统，覆盖运营、公司、风控等不同条线。

三个系统的共同点很明显：都是内部管理流程，都需要跨部门协同，都不值得占用核心系统的开发资源。这正是平台型工具最合适的位置。

对银行来说，这类"小而急"的需求从来不少。有了能快速交付的工具，科技部才腾得出手去做真正复杂的事。

这套系统一个半月完成开发和测试，效率之外还有一层原因：用户愿意用。

银行员工每天都在用 Excel，界面熟悉、操作直觉，培训成本几乎为零。系统上线后，网点不必再学一套陌生的操作逻辑，接受度自然高。

对内部管理系统来说，上线只是开始，能不能被用起来才是成败。功能再全，如果一线觉得麻烦，数据就会重新退回邮件和微信群。

平安银行广州分行这套做法的价值，也许就在这里：用熟悉的工具承接陌生的流程，让改变发生得没那么费力。