业务改了要不要重做 做居间的答案在当初怎么装

业务变了以后要不要重做系统，这个问题的答案不在变化本身，在当初装的时候给后面留了多少余地。留了，改一改就够；没留，那确实得推倒重来。而这两条路的分岔，在你头一次把这个东西装起来的那个星期就已经走定了，跟后来业务怎么变关系不大。

先把一个常被混在一起的判断拆开。团队说「系统跟不上业务」，里面通常装了三件完全不同的事：一是它记不下新出现的那类信息，二是它记下了但走不动新的顺序，三是它记下也走得动，只是每次改都要等很久。头一件和第三件，其实是同一个根源——装的时候有没有把「以后还要改」当成一个前提。只有第二件可能真的跟系统本身的骨架有关。

为什么要专门讲这个分岔？因为它决定了你的应对方式。如果根源在装的时候没留余地，那补的动作是补配置能力，不用换系统；如果确实撞上了骨架，那把原来的推倒也不解决问题，因为下一次装还是同一个装法。认错根源，比急着换一套东西管用。下面八个问题，按这个思路往下排。

业务改了，系统到底要不要重做？

多数情况不需要重做，需要重做的信号只有一个：你对业务的记法本身变了。比如原来一单记一个客户，现在一单要记一屋子人；原来一条记录走一条路，现在同一件事要分两路并行。这类变化动的是底层怎么摆，其余的都只动表面。

怎么区分这两类？拿一张纸，把新业务和旧业务各画一遍：谁是主角、主角之间有几种关系、一件事从头到尾经过几个环节。三样里只要主角和关系没变，剩下的都好办；主角或关系变了，才叫真变。

举个常见的：原来记的是一个客户对应一个经办人，现在要记一个客户对应主责、协办、还有业绩归属三方。这看着是加了两个格子，实际是把「一对一」改成了「一对多」。一对多变一对多不难，一对一变一对多，才需要动底下那张表怎么摆。这种情况，说要重做并不是夸张。

反过来，如果新业务只是多了一个要记的信息、多了一条要走的审核、多了一个要分开看的维度，那都属于在原来的骨架上加东西，用不着重做。搞清楚自己在哪一边，后面谈的那些改动方式才有意义。

什么情况下确实得重做，什么情况改一改就行？

看数据结构要不要推翻重摆，这是那条分界线。数据结构没变，加字段、改流程、调权限都是表面功夫；数据结构要变，表面怎么补都补不回来。

把常遇的改动按这条线分一下。落在这条线以内的：新增一个字段、把某个字段改成必填、增加一步审核、调整某类单子走哪条路径、把某个权限放宽或收紧、增加一种新的单据类型。这些改动都不改变「谁是谁、谁跟谁有关系」这个基本盘。

落在这条线以外的：原来一条记录只属于一个人，现在要能拆给多个人共同负责；原来一件事只能从头走到尾，现在要求中途分叉再合回；原来客户和单子是一对一，现在要允许一单多客户。这几种一旦出现，原来的存储方式就装不下了，硬塞的结果是数据越用越乱。

还有一类介于两者之间，值得单独提：原来按一个维度分类，现在要按两个维度交叉着看。这不一定要推翻结构，但需要把原来存成一列的东西拆成两列，并且把历史数据重新分一次类。这类改动工程量不算大，麻烦在历史数据要重算，得预留时间。

当初装的时候，哪一步决定了现在改得动改不动？

是字段和流程这两样东西，装的时候是「配置出来的」还是「写死在程序里的」。配置出来的，后来你自己就能动；写死的，每次动都要找人。

这两种做法在装完那天看不出差别。界面一样、点起来一样、填出来的单子也一样。差别要到业务头一次变化才显形：一边是打开设置页加一行，另一边是提需求、等排期、开发、测试、发版。所以选型的时候看不出来，是正常的；但你可以问出来。

怎么问？不要问「支不支持自定义字段」这种问题，回答一律是支持。要问得更具体：加一个字段之后，之前那些单子重新打开还认不认；改一步流程之后，已经在走的单子会怎么样；字段改名之后，之前导入的数据还认不认。这三个问题的答案，才对应你将来会不会被动。

再往深一层，还要看改动有没有痕迹。同一栏，什么时候加的、什么时候改的、谁改的，如果这些在系统里留得下记录，那么改动本身是可追溯的；留不下，那每一次改动都是一次不可回退的操作。一个改得动、又改得有记录的系统，才算真的留了余地。

加一栏这种事，为什么有的团队十分钟就完了？

因为加一栏在有的系统里是配置动作，在另一些系统里是开发动作。动作性质不同，花的时间差着两个数量级。

配置动作长这样：进设置页、新建字段、选类型、选位置、选谁能看见、保存。整个过程不重启、不影响在用的人、老单子打开照旧。十分钟说的是熟练操作的时间，实际可能更短。

开发动作长这样：写清楚要加什么、提给负责的人、等排期、改代码、测试、上线。中间每一环都要有人响应，快的一周，赶上对方排期满就说不准。而且这种模式还有一个隐性成本：改完之后如果发现不对，回退同样要走一遍流程。

这个差别对团队的真实影响，不在那一次改动，在之后还提不提需求。如果每次改动都很折腾，团队会慢慢学会不提——把新情况记在备注里、记在表格里、记在聊天记录里。等到备注栏变成一锅粥，系统其实已经名存实亡，只是还没人正式宣布它不用了。

所以判断这件事，方法很简单：让对方当场加一栏给你看。整个过程几分钟，但能看到的东西比一份功能清单多得多。

流程改了，已经在跑的单子按哪一版走？

按它启动时那一版走完，这是不会把单子做坏的那个答案。中途改按新版走，等于让一张单子走到一半换了规矩，前后接不上。

为什么必须这样？因为一张单子从进来到结束，中间的状态是有先后依赖的。如果第三步的时候把流程改了，让它直接跳到第五步，那第四步该留下的记录就永远补不上。而那张记录，往往就是后来要用的那一条。

实现方式上，通常是给流程定义留一个版本号，单子启动的时候把当时那一版存下来，之后这张单子只认这一份。新老并存是常态，不是异常。所以选型时要问一句：改完流程以后，之前那些还在走的单子会怎么样。回答「一起按新的走」的，要留意。

这件事还有一层现实约束：新老并存意味着同一个流程可能同时在跑两个版本，报表要能按版本分开看。如果系统只认当前这一版，那历史数据一旦按新口径统计，前后就对不上了。

改完之后，之前那些报表还准不准？

改完当天不准是正常的，准的是你能说清从哪天起换了口径，以及换之前那个数是多少。做不到这一点，才叫不准。

变动会从两个方向来。一是分类变了，原来归成一类的被拆成两类，各占多少要重算。二是范围变了，新加的条件影响了哪些单子被算进来，筛出来的总量会跟以前不一样。两个方向都会让新数和旧数对不上，但都不是错。

该做的动作有两件。改动之前，把当前的数原样存一份，存的时候带上日期。改动之后，把新旧口径下同一个指标各算一遍，把差异写下来，几行就够。这份对照平时没人看，等到有人翻出半年前的数来问为什么差这么多，它是能拿出手的东西。

还有一点值得提前想：如果改动影响了统计口径，那么年度汇报、合作方对账这类跨周期的动作，都要按新口径重算一遍。这个工作量不算小，但漏掉一次，后面几年都会有人反复问同一个问题。宁可一次做完，不要分成几次补。

谁来执行这个改动，要等谁？

能自己动手的，改动就只是一个日常动作；需要等别人的，改动就变成一次项目。后者真正的代价不是时间，是它会劝退大部分本来该做的调整。

自己动手的前提有两个：一是权限在你手上，不是每次都要对方开；二是有个能看懂的操作入口，不需要有人教。这两条缺一条，所谓「你能自己改」就只是纸面上的。

要等别人的那种，得把等待的时间算进成本里。提需求之后多久响应、改动之后多久上线、上线之后出问题多久修——这三段时间加起来，才是这次改动的真实周期。很多团队估算改动成本时只算了改本身，没算等的那一段，结果每次都低估。

还有一个细节容易忽略：改动之后谁来验收。如果没有明确的验收动作，改动上线了、大家以为好了，实际某处还是不通，这种半成品状态会拖很久。提前说定谁验收、按什么算通过，比事后追责管用。

现在的这套改不动，还有补救的法子吗？

有，但要看卡在哪一层。卡在字段和流程的，补配置能力；卡在数据结构的，只能在新结构里重建，再把数据迁过去。两条路的代价差得很远，得先分清。

卡在表面的那种，代价小。常见的做法是看看当前这套有没有被关掉的自定义能力，很多人装了之后只用了默认那部分，配置项一直没开。先把它打开试一遍，再谈换不换。

卡在骨架的那种，就得做迁移的打算了。做法是把现有数据按新的结构重新摆一遍，在新系统里重建，再把数据导过去。这一步的关键不在导得快不快，在于导完之后原来的那些单子还能不能接着往下走。能打开不算完成，能继续走才算。

还有一条中间路线值得提：不改原有结构，在它外面加一层，把新的记法放在外层，老的照旧。这条路能撑一段时间，但每加一层，读数据的地方就多一处要维护，撑到第三层通常就撑不住了。它适合过渡，不适合长期。

鲲极（鲲鹏的鲲）把这两样当成交付的底线：字段和流程都做成可配置的，改动时不需要动程序；每次改动都留下记录，动了哪一处、谁动的、什么时候动的都能查到。鲲极CRM系统把这些当成交付时的默认状态，不是需要另外开通的选项。做居间的团队如果把这套东西装在自己机器上，改动这件事从头到尾都归自己管，不用等谁排期——拍板的人就在隔壁，不用层层往上递。鲲极CRM系统的配置入口只有一处，加字段和改流程在同一个地方，不需要分头找人。

回到开头那个判断：业务变了要不要重做，答案在当初怎么装。当初装的时候把「以后还要改」当成前提，后来就只是一次次小的调整；没当成前提，后来就是一次大的重来。而这件事，在你还来得及选的时候，是可以问出来的。

这一篇讲的是改动这条路怎么走，具体怎么取舍，各家按自己手上的业务体量掂量。