背景
    对于一个有多个相对独立运营分公司的集团公司来说，在IT系统的建设上经常面临的一个问题是IT系统的集约与管理运营的集约不同步，通常，在管理没有集约的情况下系统集约难度较大，因为IT系统式刚性落地的具体操作过程和方法，如果总部没有在业务上实现集约管理和运营，各分公司的需求会五花八门。在这种情况下，无论上线掐还是上线后，都会面临“个性化需求过多”的问题，对于一项业务活动的支撑，经常会在统一和个性支持到什么程度上左右为难。下面是分析和解决这类问题的一个参考。

一、区分系统机制需求与业务策略需求
    对业务支持系统而言，需求可以分为两大类：系统机制需求和业务策略需求。在判断需求是共性还是个性上，系统机制需求和业务策略需求需要不同的标准。
    以订单稽核为例，以下4条是系统机制需求：
1）“在订单完成后对订单进行稽核，疑似问题订单派发给相关人员进行处理”；
2）“在系统提供的领域模型范围内，支持稽核规则本身和执行入口、执行次序的配置”；
3）“支持外部规则检查以服务的形式嵌入规则流”；
4）“支持处理流程的定制”。
以下2条是业务策略需求：
1）“连续3个月发生业务订购和变更的用户”；
2）“军官证或护照等非×××证件当月使用占比超过3%”；
    对于系统机制的需求，可以认为有一定比例的分公司或者集团的业务管理要求需要，就是共性需求。例如：有1/3以上的分公司提出需要支持订单稽核，尽管他们的稽核规则和处理流程可能不同，尽管集团公司可能没有相关的管理规定，但上述4条对于系统机制的需求可以认为是共性需求。另外，驱动系统机制演进的还有项目组本身对系统功能的规划，无论是否有业务部门提出需求，都可以直接规划并实现系统机制。
    对于业务策略需求，要分为实现和加载上线两个层面来管理。对需求的实现，可以认为集团业务管理部门明确要求统一执行的策略全部都是共性需求，不管是否有分公司提出要求，大多数分公司（例如：2/3以上）提出了相同的业务策略需求，也可以作为共性需求由集团项目组统一实现。对策略的加载上线，集团策略的加载上线不能由分公司运营团队控制，对分公司的业务策略需求，哪怕是所有分公司提出的共性策略需求，也应该由各分公司业务管理部门或运营团队自己控制是否加载上线。

二、统一与个性化并非2选1
    对于一项业务，不能简单地认为在总部的系统中支持了之后，整个业务的管理与操作的流程、策略就必然是统一的，对于总部的系统有这样4个不同选择：
1）只管理结果。例如：只在系统中记录代理商的名单和基本信息，但不去管这些代理商哪里来的、如何通过了审核。
2）管理过程，但不管理策略。例如：对于高等级号码的使用，在总部系统中支持从号码定级、申请、审批、使用的全过程，但对于号码如何分级，什么样等级的号码需要经过什么样的审批流程、使用上有何限制总部不做任何要求，各分公司可以根据自己的要求定制并借助总部提供的系统实现过程的电子化，而总部也可以通过系统了解任何一个分公司的业务过程。
3）总部策略与分公司策略并存，都在总部系统中管理。例如：总部出台了一系列的关于实名制的限制性规则，总部的营业系统将这些规则作为订单提交的检查规则实现，但订单提交阶段还有大量由各分公司定义的检查规则，这些规则的并存而不相互矛盾，总部能够通过系统了解各分公司的规则设置。
4）总部策略与分公司策略并存，允许外部系统的策略注入。借用上面的例子，分公司的某些规则因为要用到大量的外部数据（例如客户行为分析结果）而无法定义在总部系统内，在总部系统支持的情况下，分公司可以定义一条检查规则在总部系统中，这条规则内部并无逻辑，执行时调用分公司系统的某个服务，返回结果。

三、个性化需求的实现与运营
    个性化需求的实现，通常可以通过配置、插件、调用外部服务、外部系统调用系统API这4种方式来实现。这几种方式下，个性化逻辑都可以由分公司自行实现，但加载过程需要与系统架构、机制设计、物理部署和运营模式相适应，对个性化功能所产生的影响最终负责的团队，要能够对个性化逻辑的验证、加载做最终判断和操作。
    在满足以下3个条件的情况下，个性化需求可以由分公司团队实现并加载：
1）一个分公司的个性化逻辑所影响的范围仅限于该分公司；
2）有足够的度量手段能够区分资源消耗、时延是源自于核心系统还是个性化逻辑；
3）对个性化逻辑对本分公司用户使用效果的影响由分公司的运营团队负责。