12.2.1 一个运营团队的变迁：从运营后台的演进路线说起
一个运营后台系统的演进一般会经历以下4个阶段。对于产品经理来说可能会更关注系统结构和功能上的变化，但如果能够跳出系统逻辑，我们会看到这种演进往往伴随的是运营团队组织结构的调整与变迁。
1.V1阶段：CRUD
在一个业务最开始的Demo阶段，其运营后台根据数据库中所有与业务相关的数据表实现最基本的CRUD功能即可，即实现数据的增加（Create）、读取（Retrieve）、更新（Update）和删除（Delete），所有的运营动作反映到数据层本质上都是这些操作。在这个阶段可以不需要产品经理，绝大部分工程师的程序设计课的最后一个大作业就是完成这样一个运营后台。
以机票业务为例，核心的数据表至少包括与机票库存和报价相关的政策表、机票订单表、机票搭售保险表，以及其他与交易相关的数据表（如支付表pay等）。因此一个简单的机票运营后台至少应该包括政策管理、机票订单管理、搭售保单管理等页面，每个管理页面均应实现CRUD功能，支持对数据表中数据的增删查改等操作，如图12-8所示。
图12-8 机票运营后台V1阶段：CRUD
2.V2阶段：流程化
Demo阶段这种基于数据表的运营后台，在业务开始起步并真正上线运行时会遇到一些流程性问题。以完成一次机票订单出单为例，不仅需要在机票订单管理页面回填机票的票号进行出票，还需要在保单管理页面对与订单对应的每个乘客回填保单号并进行保险出保，因此在系统上一般会选择将这些出单操作统一聚合在同一页面，如单独的出单页面或合并在订单管理中单个订单的详情页中。在这一阶段，产品团队对运营后台系统的改造，核心是将业务流程进行拆解，并在系统目录结构和内部逻辑中体现，以减少运营人员切换页面的时间成本，让运营人员能够在一个页面中完成一个完整的运营子流程。
与此同时，我们也开始组建运营团队，常见的做法是按流程对运营团队进行人员和KPI的切分，包括售前组负责机票政策维护、售后组负责订单出单等，售后组根据情况会进一步切分为出单组和退改组。这一阶段的系统在运营团队完成流程化后的形态示意如图12-9所示。
图12-9 机票运营后台V2阶段：流程化
3.V3阶段：自动化与模块化
随着业务量的快速上涨，接下来又面临新的问题：运营团队的线性扩张完全支撑不了业务量的指数级上涨。
一个解决方案是使其中许多重复的流程自动化完成，例如在机票出票流程中，一部分会从全球机票分销系统GDS（eTerm客户端登录，俗称黑屏系统）中出票，还有一部分会从航空公司（主要是廉价航空）官网上出票。产品团队与技术团队会以出票量作为优先级判定标准分别开发系统进行对接，实现系统自动出票以代替人工出票。
尽管如此，产品团队与技术团队在改造系统时也不是一蹴而就的，因此仍然需要运营团队来支撑当前未能自动化的一些运营流程。而此时运营团队会面临新的管理问题：一个完整的出单流程需要一线运营人员登录GDS或航空公司官网进行出票，这意味着一个新入职的运营人员需要同时学习eTerm指令运营手册和航空公司官网代购运营手册，同时作为出单组的成员还需要登录保险公司的系统进行出保操作，因此也需要学习相应的保险运营手册。在学习了这些手册之后，还需要一段适应时间，一般来说在这段时间内新人会显著低于熟手的效率与产能。因此一旦有团队成员离职，加上招聘本身需要的周期，会对团队整体的业务支撑能力产生不小的影响。
所以，在团队管理方面，会倾向于将运营流程进一步模块化，将机票出票与保险出保的工作从人员上分开，这样一来新入职的运营人员只需要学习部分运营手册就可以上岗，缩短了培训和试岗时间，能更快地进入熟手的状态。模块化的本质是对能力的抽象，因此在同一个平台操作出票和退票两种流程的人员也可以放在一起组成票务组，甚至还可以按操作平台分为GDS组和官网代购组。这样一来也利于招聘时对候选人进行差异化画像，GDS组可以从传统旅行社中招聘那些熟悉eTerm系统的人，这类人入职后可以直接上岗，而官网代购组有时需要登录国外航空公司官网，因此可以招聘那些懂英文的高校实习生。最后，不同的运营小组之间可以通过交叉轮岗的机制，逐渐让所有成员都有机会学习其他模块的技能，这样在某模块中的人员请假或离职时能够通过人员调度平衡运营力量，增加团队的机动应变能力。
以上这些变化的示意如图12-10所示，这一阶段运营后台的系统框架与基本流程不变（方框）。与上一阶段相比，这一阶段的主要变化在运营后台的内功方面，也就是运营流程自动化方面。运营团队经过调整后组织形式发生了较大变化（下图椭圆框与右侧组织架构部分）。
图12-10 机票运营后台V3阶段：自动化与模块化
4.V4阶段：SaaS化与API化
运营平台以及运营团队发展到V3阶段实际上已经相当成熟了，如果希望继续支撑更大的业务量，那么一个可见的趋势是将平台开放，将人力资源与成本向合作伙伴转移。
一种转移方式是平台SaaS化，即将企业的运营平台开放给合作伙伴使用，将一部分业务和运营成本同时转移给合作伙伴。当然这种开放本身和平台的业务经营策略有关，一些平台类企业从最初就是完全SaaS化的，如去哪儿网、淘宝等；而另一些平台则是从自营开始逐步发展为自营+SaaS化的，如携程、京东等，此时企业的运营团队的核心能力也将从用户运营向客户运营扩展。
另一种转移的方式则是平台API化，即开放API接口，将一部分研发成本转移给合作伙伴，同时与他们分享收益，如去哪儿网的运价直连合作、淘宝开放平台等。
这种SaaS化与API化的开放平台方式为企业放大了管理杠杆、扩大了运营半径，所以能够支撑更大规模的业务量，为企业赢得用户侧的竞争优势；同时这种方式也将合作伙伴在一定程度上与企业绑定在同一利益共同体当中，为企业赢得供应链侧的竞争优势。