明道云搭好的应用，后续维护交给谁做
去年见过一家做环保装备的企业，自己搭了一套销售应用，搭的人是老板的外甥，学计算机的，边搭边改，老板很满意。今年外甥去了杭州，应用还在跑，但没人敢动：销售想加一个验收日期的字段，不知道加上之后关联的页面会不会出问题；有人提了个权限申请，翻遍公司找不到能改配置的人。老板后来问我：这套东西，接下来交给谁做？
这个问题不止他在想。低代码搭应用，搭的时候痛快，真正的成本在后面：字段谁改、权限谁审、人走了怎么接。三条线摆出来，账就好算了。通篇不评价哪家产品，只讲判断维度。
第一条线：字段和菜单谁改
业务在变，应用就得跟着变。加字段、调菜单是最高频的维护动作。判断标准很具体：改一个字段，要不要走开发排期，还是一个人在后台点两下就能生效。
现成CRM把这类事放在配置层。千营CRM里，「字段设置」支持客户、线索、订单、产品字段自定义，环保装备企业要加环评批复日期、验收日期、质保金比例这类字段，都是配置动作，不动代码，当场生效；「菜单管理」控制各功能模块的可见权限，可以只对自己生效，也可以对全员生效，培训一个销售内勤半天就能接手。这套事不需要养懂代码的人，行政或内勤照文档点一遍就会。有个配套的做法：上线前把要加的字段一次列全，别销售今天提一个明天提一个地零碎加，一次配齐，后面大半年不用动。
第二条线：权限谁审
第二个高频动作是权限。谁能看到哪个菜单、谁能转交客户，得有个明确的口子。判断标准：权限变更是管理在后台勾选配置，还是得找原来搭应用的人写一段逻辑。
现成系统里这些是预设好的：「菜单管理」按人或按全员控制可见范围，数据归属变更走「变更归属人」，转交给谁、什么时候转的，系统里留痕。员工离职，名下几十家客户档案一次转给接手的人；暂时没人跟的单子，「退回客户」退回公海让别人认领。新人入职开账号、老员工调岗改权限，都是标准动作。权限混乱的成本比字段缺失高，客户名单外泄一次，损失就不是配置费能覆盖的了。
审权限还有一个隐性好处：口子只有一处，申请就有处可去。搭出来的应用权限散在各处页面里，谁也说不全一共配了多少处；现成系统的权限集中在后台，出问题顺着配置往下查就行。那家环保装备企业外甥走后，一个权限申请拖了三个星期没人接，这就是口子散掉的直接代价。
第三条线：人走了，交接成本多少
开头那个场景就是第三条线。自建应用的字段逻辑、页面关联、数据流向，多半在搭的人脑子里，文档要么没有，要么过时。更麻烦的是口径没人解释：同一个备注字段，有人填型号、有人填工期，一年之后没人说得清这列到底该放什么，每次维护都变成一次小型考古。有个土办法可以当试金石：让搭应用的人写一份维护手册，字段含义、页面关联、权限规则各写一页。写得出来说明系统脉络还在人脑子里，趁人还在赶紧写；写不出来，说明这套应用已经没人真正懂了，这笔账要按最坏情况算。
现成CRM的交接是另一副样子：功能文档由厂商养着，不用你更新；字段含义是预设的，谁进来都按同一套填；交接清单写不满一页纸，把「角色」配置抄给新人，让他自己在「偏好设置」里把界面配色和布局调顺，半天就能上手干活。「偏好设置」只管配色和布局这类个人偏好，五分钟的事，但恰恰说明该厂商管的厂商管了，该个人定的个人定。
这笔账怎么认
三条线过完，账不难算。自建应用买的是配置自由度，代价是长期的运维人力：养一个专职系统管理员，一年的工资摆在那里；不养，就赌搭应用的人一直在职。业务足够特殊、公司里本来就有IT编制，这笔钱花得值；销售体系两三百人却没有半个技术岗的制造企业，就要掂量掂量配置自由度到底用得上几成。现成的产品牺牲一些自由度，换来的是文档有人更、权限有预设、交接有清单。也不必二选一：拿不准的话先看看项目型CRM里现成的功能覆盖了几成需求，常投标的团队再对照招投标CRM看报备到截标这段，缺口真实存在再谈自建，千营CRM的功能清单可以直接对着缺口挑。算到最后其实是两类人的比价：自建养的是懂系统的人，现成养的是会用系统的人，后者好招得多，也便宜得多。
把话说透一点：低代码的价值在把独有流程固化，现成CRM的价值在把标准流程跑顺。报备、跟进、报价留痕、订单收款这一段，是几乎所有项目制企业共通的流程，现成系统养了多年，通常已经够用；真正独家的那部分流程，才值得单独投入。先分清哪段是共通的、哪段是独家的，选型就省了一半纠结。
本周的动作：把现在在跑的那套应用翻出来，列三个数，去年改过几次字段、权限申请平均几天批下来、搭应用的人现在能不能随时找到。三个数摆在一起，是继续养、还是换，答案自己会浮出来。
