第1节　支撑体系

你发放支撑讯号，无论远近也收到。

即使没法讲，感激得到你箭亦为我挡。

——张柏芝，歌曲《即使没法讲》

关于支撑体系

体系，泛指一定范围内，如同类的事物，或者人为地按照一定秩序和内部联系组合而成的整体，是不同系统组成的系统。体系有“人”的行为在其中，所以人是影响体系的最重要因素！因为人除了对体系的认知、学习和执行过程存在差异，同时人也对自身认识水平存在差异。因此，一个优秀的体系设置就应该考虑人在认知、学习和执行中存在的差异。

支撑，这个词并非是企业管理的专用词，做动词用有“顶住，使不倒”的意思，而以名词用则为“用以顶住之物”。

运营和支撑联系在一起，称为“运营支撑”，多为运营类企业（如通信类企业、互联网企业等）在管理中常用的术语。

志在O2O互动的组织既要关注线上，又要关注线下。那么线上线下的完整、安全、高效一站式的运营支撑就显得非常重要了。因此，对支撑内容、支撑流程、支撑标准、支撑组织设置进行规范，那么建立支撑体系就变得顺理成章了。

很多人喜欢做项目，因为项目的具体目标明确、时间明确、资源明确，因此用“毕其功于一役”的目标管理和计划去分解项目，按照时间点分配到项目组各成员，像攻“山头”一样，全力以赴，想尽办法把“山头”攻下来。

如果是一个项目制企业，其特点往往是一年做几个甚至几十个项目，而每个项目的标的比较大。而运营性企业则不同，其特点是每天做的案例很多，而且标的不大，例如接待一个客户，为其办理3元/月的套餐产品。其实就单个案例来讲，占用的企业资源是很大的，但就是由于有几亿个这样的客户存在，使其运营支撑能力能够快速适应如此繁琐的业务要求。

长期以来，运营支撑以快速满足业务运营为己任，而业务KPI指标往往是运营部门扛着，所以运营支撑部门基本上以运营部门的业务指标马首是瞻，这是比较常见的，但有一利必有一弊，这样的弊端其实也是很明显的：

1）很多时候，产品的运营成功与否与支撑的付出没有线性关联关系，因为不是每个创新出来的产品都能运营成功，对于很多不成功或类似POC^[1]的产品，运营支撑部门还是一视同仁的支撑着。

2）为了满足纷繁复杂的创新产品的运营需求，支撑的规则、流程、标准等约束条件和范围都会受到影响。因此，频繁更改产品功能和系统，给业务支撑系统的安全稳定运行留下了隐患。

3）运营部门盯着某几类产品运营的条和线，而业务支撑体系却考虑整个支撑的面和体，因此它们之间的矛盾冲突是难以避免的。有的支撑行为在单一产品运营看来是最优的，但是放在全局，恐怕就未必合适。反之亦然：有的时候运营支撑部门提的方案和建议是从全局运营支撑角度出发的，对某个具体产品的运营并非最佳方案。这方面需要团队间彼此信任、体谅，有充分的时间沟通和交流，众多的产品创新会迫使运营支撑团队将精力聚焦于“事”和“效率”方面，在“人”的因素上自然会吃亏。

4）当创新产品运营快速发展，运营支撑部门所获得的资源情况往往滞后。尽管组织对运营支撑不断加强，人员也在补充，但是这与运营支撑部门的工作广度和深度的扩展速度，以及时间、数量、质量等方面的要求相比，资源远远不足。这就迫使运营支撑体系要么走向规模化的服务蓝领模式，要么打通产业链各节点，使支撑体系外包化或社会化（打通产品链的云服务）。

当某个O2O组织快速发展和成长时，这些代价的付出是值得的；当大家关注于“事”和“效率”的时候，运营支撑的这种努力和牺牲也是容易得到理解的。

因此，运营支撑需要建立一个体系，让我们的运营支撑中涉及的“事”、“效率”和“人”三者有机结合，成为机制。那么这个机制就是“运营支撑体系”。

[1]POC，是Proof of Concept的缩写，意思是为观点提供证据，它是一套建议使用的电子模型，可用于论证团队和客户的设计，允许评估和确认概念设计方案，POC的评价可能会引起规格和设计的调整。