用供应链管理思路降低教培产品成本

本文来自网易云社区

作者：李超

在没有几个人知道互联网是什么时，供应链就已经开始应用在制造业了。在我成为一名互联网产品经理的前几年里，也从未在这个圈子里听到过“供应链”这个词。它的概念是：通过增值过程和分销渠道控制从供应商到用户的流就是供应链，它开始于供应的源点，结束于消费的终点。

和“供应链”相关的名词还有“价值链”，也是供应链的起源，是1985年一个叫MIchael Porter的美国学者提出的，首次将一个企业的整体价值活动联系为一个整体，从生产研发、物流、采购、存储等形成环环相扣的链条，企业必须要考虑整体效率，才能最终提升生产能力、降低成本。这与生态中的食物链很像，在“草-兔子-狼-狮子”的链条下，如果我们把兔子全部杀掉，那么草就会疯长起来，狼也会因为兔子的灭绝而饿死。

在考虑把供应链成本做低时，“产品复杂度”就是那个起决定作用的兔子，当产品本身复杂时，与之相匹配的供应链条也相应复杂，从而导致整体成本上升。

以前一直流行一句话，叫“人人都是产品经理”，其实是因为“处处都是产品”，如果是产品，就有它额供应者，从生产到运输，抑或是从生产到服务，不同节点的供应者就构成了链条，抬眼一看，几乎生活中处处都是供应链。

教培产品也不例外的有其供应链，因而通过“供应链管理“的成熟理论，在控制成本方面，就能对教培行业有指导意义。

1.价格由市场决定，成本由复杂度决定

在竞争越是激烈的领域里，企业的定价权越小，而谁能取胜于市场，往往就是谁的成本控制做得好，而这本质上就是在拼供应链管理的实力。从供应链管理的思路来说，单位成本由批量和品种驱动，批量越大，单位成本越低；品种越多，单位成本越高。这个理论在多个行业试用：

【案例1-硅谷的中餐馆】

在硅谷有很多中餐馆都开不到半年就倒闭，这是其中一家的菜单。这家店最多时能坐30个人，两三个跑堂、两三个厨师，但是它的菜单很吓人：120多种特色家常小菜，任选三样，18美元（也就是相当于100元人民币），这个价格在中国大多数地方也是非常便宜的，一盘小菜的分量很多，一个大腹便便的美国人几乎一盘菜也可以吃饱，在硅谷这样寸土寸金的地方，可想而知是有多么廉价。但是做的人很多，大家都是这么卖，所以也不得不定很低的价格。

【案例2-教培机构“小马过河”的兴衰】

2013年，曾经小马过河是除新东方外，北京地区考试1对1培训营收最大机构。它的创始人是两个原新东方的总裁级人物，其下培养的新东方老师多过千人，这样的两个人在出来创业时，便获得了大量投资。2011年到2013年，小马过河的营收逐年翻倍，客单价可达几万元。

但是后来，在线教育逐渐兴起，小马过河押注线上产品，开发了100多个APP，员工数量快速扩张到了900多人，其中200多人为技术开发团队。同时频繁推出低价产品，以吸引更多学生，但这些学生难以转化为1对1核心高端用户。

最终因为资不抵债，以倒闭收场。

以上两个案例虽然所属行业不同，但是都有两个共同特征：产品种类多、价格低廉，价格由市场决定，而不能为企业增值的“多”只能是起到负面的作用。

什么样的产品，可以进行单一品种的大批量复制，从而形成规模效益呢？

答案是：标准化的产品，因此我们在考虑较低复杂度时，可以先探究一个问题：我们要做出规模、降低成本的产品，它是否是可以标准化的。

2.教培行业以什么为核心产品是具有规模优势的

（1）教师？

我们能看到至少在过去的20年里，几乎所有的教培机构都是走以名师为导向的发展路线。谁能掌握名师资源，谁就能获得生源。在这样的市场背景下，教培行业的核心产品其实就是老师。老师作为一个产品，同时也作为一个人，就有一个特点：每个人讲出来的课都不一样，即使讲同样的内容，也会讲出不一样的水平。这样的产品，我们叫作“非标准化产品”，非标准化成本有几个特点：

首先，边际成本呈锯齿状。一般的产品，在其规模不断扩大时，其单位成本会呈现下降趋势（虽然管理边际成本随规模扩大而增加，但是其生产、营销成本随着规模扩大而减少）。但是当老师作为一个产品时，它就不符合这个规律了。比方说一个机构要招生，首先他培养了一个名师。名师的课很快报满后，为了扩大机构规模，就需要再培养一个名师，并且为新的老师再做一轮营销，总的边际成本并不会随着规模的扩大而减少。

其次，学生试错成本高，导致招生成本高，因为每个老师不同，学生就需要花更多的时间去挑选老师，然后再进行报名。

基于以上两点，当核心产品是老师时，就难以产生规模效益。

（2）课程？

课程是需要老师来上的，如果说老师是非标产品，那么课程可以标准化么？

答案是：可以的。

当产品是名师时，追求的是老师之间的差异，但当产品是课程时，打法就变成了追求的是老师的一致性。课程本身变成了一个团队工作。一节课程不再是全部依靠老师去备课、讲解并自己提炼讲课方式。老师可能只负责课程的一部分内容，比如有教研团队会将课程内容、讲课方式全部制作成标准，再招募老师，经过统一化培训，进行较为一致的课堂演绎。

在这样的机制下，一堂课的好坏、内容与老师水平、授课喜好并无直接关系，如果需要扩大规模，招募新的老师，进行同样的培训到上岗，都比培养一个名师成本更低。相比较看来，想做出规模，确实还是以课程作为核心产品更为可行。

（3）服务？

服务是除了标准化课程外，还包含了对学生课后辅导、学习态度、状态等一系列的服务与关注。课程我们已经说过，是可以进行标准化的，那么想要做到服务标准化，虽然也并非易事，但是也已经有成功的套路在，比如通过框定服务内容、服务方式及话术。在教培行业里，最常见的服务就是课后辅导，现在比较流行的“双师模式”（即一个负责线上教学，一个负责课后辅导）就是在做服务标准化的尝试。

举一个跨行业的例子，“爱的果实”这家母婴机构就在服务标准化上做得不错，有成熟的月嫂培训机制，把月嫂的工作拆解成一个个服务项，每个服务项都经过了统一化的培训和考试。在向家庭提供月嫂服务时，月嫂每天要做的工作，都有机构统一的工作列表进行跟进管理。因为能将服务标准化，爱的果实不提供月嫂面试，大批量的好口碑在各大社群里形成共鸣，让这家机构飞速的成长起来。

综上，课程和服务都可以成为教培机构的标准化产品，因而想做大规模的，可以选择这两者作为核心产品。但如果只选择其中一个，课程、服务哪个更适合作为核心产品呢？

我的建议是：服务。

核心产品是什么，要问问家长购买的是什么。只有与家长购买根本目的越接近的产品，才能让家长更快速的决定购买，而这正是降低招生成本的本质所在。而当招生成本小，招生数量才能更加快速的增长，在产品标准化的前提下，这样的快速成长，才能最终形成规模效益。

家长购买的是什么呢？表面上好像是名师、或者服务，但根本的购买动机其实是学生的成绩提升或得到成长。而教培行业由于“预结算，慢结转”的特性，家长往往需要一次性支付一个学期甚至半年的学费，这就会存在一个问题：家长在付费时，并不知道学生是否能因为这些课程而获得提升，那么支撑家长去支付的直接动力就是“信任”。能够更接近于家长诉求的产品，就越容易得到信任。

而服务是“以学生成绩提升为核心，进行的一系列服务”，相比起只销售课程来说，增加课后服务对学生的成绩提升更有保障。因而，服务更适合作为教培产品的核心产品。

3.标准化课程的尝试

现在也有不少机构，已经意识到标准化课程的重要性，但是具体方法都还在探索中，我下面也列举几个业界尝试：

【新东方-搭班模式】即将英语课程拆分成听、说、读、写等多个环节，由不同的老师来教授不同的环节。这样做的特点是，每个老师的受学生喜欢程度都不会超过60%，学生对老师的依赖程度不高。而多个老师由于共同教授同一批学生，形成竞争，会不断提升自己的授课水平，最后几个部分的课都能保持相对一致的水准。

【学而思-统一教研】即将授课内容、方法由教研团队进行统一规划，形成标准化的课堂产品，再招募老师进行统一化培训，进行相对一致的授课演绎。

【学大-销售话术标准化】不推名师，而是标准化的课堂产品推荐话术，对老师也有标准化的框架进行约束。

总的来说，标准化课程的尝试，主要方法就是将课程由一个人单干，改为是一个团队的工作，从而降低老师的差异化和重要程度。

4.从供应链到教培产品，总结复杂度的降低

依照供应链的概念，降低产品复杂度需要从产品线、产品型号、配件的三个方面来进行简化，那么如果对应到教培产品，它们又是什么呢？

（1）产品线相当于服务线类目，文中说的“小马过河”例子中的100多个APP就相当于100多个产品线。创业企业会比较喜欢把“苹果投到不同的篮子里”，但是一旦需要做大做强，最终还是要以仅运作极少数核心产品线为长期运营状态。（要知道乔布斯就是削减了大量的产品线，画了个知名的产品线十字架，才最终盘活了当年奄奄一息的苹果公司）。

（2）产品型号相当于老师的授课水平。如果一个机构里老师的讲课水准各异，无异于课程有不同的型号，这就需要学生通过反复的试听来确认是否有合适的老师。

（3）配件相当于教培服务环节。我们提供服务，不是为了让他感受到“服务周全”，而是以学生的成绩提升或者成长为目标，否则即使投入了大量的成本来提供服务，如果还是对结构无效，最终家长便不会再续费。而“续费率”是评估教培产品是否靠谱的主要考察点，一个续费率不高的教培机构，注定也是走向衰落的。解决方案就是：提供影响学习效果的关键性服务，这就需要教培机构根据用户定位和不断尝试来解决。

综上，在产品管理上，要力求小而美，从而降低整体的运作成本。而这里的“小”，并不是指小众市场，而是指降低产品线、产品型号、配件的复杂度。只要这样的“小”，才能做出规模。

网易云免费体验馆，0成本体验20+款云产品！

更多网易研发、产品、运营经验分享请访问网易云社区。

相关文章：
【推荐】 Docker容器的自动化监控实现
【推荐】 对云环境下访问控制系统的思考