最近，有不少欲发力进军O2O的企业家咨询我关于“App”还是“服务号”的选择。而近期在微信公开课上张小龙仿佛又提供了第三条解决路径——微信应用号。那这微信应用号又是什么？作为企业而言，目前拓展线上服务最好的选择又是什么呢？

服务号 vs App

我们先暂且抛开仍在云里雾里的“应用号”不谈，就目前而言，企业对微信服务号与APP的使用还是平分秋色的，需要因地制宜进行选择。

服务号主要竞争力：开发成本低、周期短、无缝更新、推广简便

1.相比于APP，服务号的开发成本与开发周期都要低得多。

由于微信后台已将服务号的基本功能打包为可直观调用、直接插拔的接口，企业只需让微信运营团队进行几小时的自学便可进行服务号的设计与开发。加之，目前市场上服务号定制开发的产业链也已日益成熟，其中有些已有了上市的规模。对于一些微信后台不支持的常用功能（如抽奖等），在这些服务号开发公司的服务主页上都能找到可直接拼装调用的廉价、甚至免费的H5模板。

而相比之下，如果企业意图开发APP实现同样的功能，无论是自营还是外包其开发成本都要动辄几十万，时间周期从2-3月到半年不等。

2.同时，微信服务号的超短开发周期还带来的一个额外的优势，即服务号可以实现无缝更新。

由于服务号的“编程”大多是通过组件“即插即用”的模式进行构架，当运营者想修改公众号中的某个功能或新增某项服务时，可在完全不停摆线上服务的基础上进行直接的“预览并发布”。而对于联网型App的更新，哪怕只是进行微量的调整，运营商必须先关闭服务器，上传新版本软件，然后等待用户下载。这其中所需要担负的时间成本与用户流失风险显然比服务号模式要高的多。

3.除了服务提供本身的成本与效率外，服务号还有一个最重要的优势，那就是微信平台带给服务号的推广与宣传优势。

对于众多公司来说，商机的拓展是个永远的痛点。服务号建筑于社交媒体之上，天生拥有极佳的渠道属性与传播资源。服务号中上传的内容可直接在朋友圈中进行社会化传播，而被内容吸引的微信用户也可直接通过“一键关注”的方式成为服务号的用户。这类巨大的推广优势直接针对众多公司痛点，是一般App的闭合生态所不能比拟的。在网络状的社交媒体上，每一个用户都是传播节点，而服务号则直接将企业接入整个传播体系之中，实现价值规模的增值。

然而，目前依旧有不少企业在开展线上服务时更倾向使用APP而不是服务号。其主要原因也有如下三个方面：

APP主要竞争力：自由度高、点对点互动

1.微信服务号最直观的限制莫过于功能实现的自由度略低。

众所周知，功能的集成化程度越高，其开发的门槛就会相应降低；但与此同时，它能实现的功能种类也就会越受限制。目前微信开放的功能接口依旧十分有限，想实现真正意义上的“自定义”开发，还得借助App才能实现。

2.如果企业想主动跟他的线上用户进行较便捷的沟通与交流，开发APP也无疑是他的绝对首选。

不少使用过服务号的运营者都会发现，企业能像用户群推送信息的周期被限制得很严格，且完全无法对某位个人进行点对点的沟通或营销推广。这并不是微信功能上的“漏洞”，其背后的核心逻辑在于微信目前的定位依旧是社交媒体，因此优先考虑的一定是维护其社交用户的使用体验。为了给用户营造一个“干净”的虚拟社交环境，在相当长的一段时间内，企业绝对无法寄希望于微信团队放开对B2C的信息推送的限制。

3.也是最被各大企业最为顾虑的问题，在于微信号对于用户数据的“霸占”。

只要企业使用服务号，那么他的一切用户数据都将沉淀在微信的远程服务器上，相当于无时无刻不被腾讯公司扼住了咽喉。一方面，微信向企业用户开放的用户信息都仅限于用户昵称、阅读量、转发量等浅表数据。那些能支持用户特征画像与使用场景分析的用户行为数据都被深藏在水面之下。

企业永远不知能用什么样的价格向微信买到本应沉淀在自己本地的用户数据，也更没有机会进行深层次的数据分析。更让多数服务号用户企业不寒而栗的是，目前微信处于发展阶段，其很多运营规则仍高度不透明。

4.“人在屋檐下”，说不定哪日一言不合便有被彻底封号的危险（例如前一段时间的Uber封号案）。

在数据价值日益被重视的今天，这种“全军覆没”的风险显然不少企业所难以接受的，故而宁愿多播一部分资金来开发APP，也要保证自身数据的独立性与可用性。

应用号把微信变成“互联网操作系统”

然而，“应用号”的推出也许会是微信进化的“奇点”，即将打破现在的平衡。虽然目前有关应用号详细的信息还不多，但据近期微信公开课张小龙的演讲，我们还是能比较清晰的把握应用号的定位与微信平台未来的发展方向。

按张小龙的说法，微信的本意不是做一个传播内容的平台，而是一个提供范畴更广泛服务的平台。而“应用号”便是微信未来开展更广泛应用服务的土壤与平台，也是目前“服务号”模式的推广与延伸。可以想象，随着越来越多服务接口的开放，“云计算”技术越来越廉价与普及，植根于微信平台的应用类型也会越来越丰富，能够提供服务的逻辑与功能也会越来越复杂。终有一日，当“应用号”提供服务的种类能与目前的APP分庭抗礼之时，微信将远远不再是与陌陌、米聊、飞信同台竞争的SMS平台，而是极有可能走向了一条不同的进化道路，真正变成一个“连接一切”的泛渠道平台。笔者暂将这种新的产品或商业模式，定名为互联网操作系统。

何为“互联网操作系统”？

操作系统的核心理念是搭建计算机与使用者（包括开发者与最终用户），硬件与软件间的桥梁与接口（interface）。虽然典型的操作系统不直接提供任何功能性的服务，但任何提供功能软件都必须在操作系统的支持下才能更好的运行。开发者能借助操作系统更高效的提供任何可能的服务，用户也可借助操作系统的图形界面更便捷的获取服务。

而当微信被“应用号”的推出拓展成泛渠道平台后，其核心的产品价值与服务逻辑与操作系统是及其相似的。还是以微信平台为例，随着越来越多的常用功能被“云化”并打包为可以远程调用的应用服务接口，越来越多的中小型公司与个体开发者会被吸引来“搭便车”，通过较传统编程方式高效得多的“接口拼接模式”来为其潜在客户提供应用服务。当应用服务规模达到一个临界值时，目前微信的核心服务——SMS反而会成为一个次要的引流入口。

其核心的商业模式也将会转型为：搭建一个开放能力的云平台，通过聚合全产业链的创意、设计与服务能力来为用户提供没有边界的服务与价值。

如此，微信对用户不直接提供任何服务（除SMS外）而能提供任何可能的服务，对企业则变成为企业所最依赖的合作伙伴与服务平台，从而成长为整个移动数据网络中拥有垄断优势的能力聚合者与价值交换节点。这套商业模式是不是与操作系统的基本理念不谋而合?

因此在笔者看来，一切平台型商业模式的本质都是在C端与B端之间打造一个“操作系统”，对于B端降低他们的服务成本与商机获取能力，同时为C端提供各种可能性的服务；而其自身便也成为了整个价值链与产业链的粘合者。在这类跨越千万个终端的“操作系统”之上，众多中小型企业、甚至是个人生产者都将被连入一个商机互通的价值网络之中，在更大规模的高效分工中攫取自身的利益并向市场提供更有价值的服务。

互联网操作系统与传统操作系统的核心区别在哪？

与传统操作系统相比，互联网操作系统继承了它的基本逻辑，而又在多个层面进行了进化与改良。

1.静态到动态。

首先，互联网操作系统提供的服务不再是静态的服务提供端口，即所谓的“A开发软件，B购买使用模式”，而是进化为了一种动态需求对接渠道与信息传输优化平台。在此类平台上，开发者能够与用户进行动态的信息连接，从而更好的把握用户需求。同时，应用的实时定制化开发与无缝更新也拜平台的“互联网化”所赐将得以成为现实。

2.主体从开发者拓展到运营管理者。

另一方面，作为互联网操作系统的开发商与运营商而言，他的角色也将从软件开发者，拓展到这个动态渠道的管理者与运营者。而这个新角色的加入，也将给互联网操作系统运营商以大量的潜在能力与商业机会，例如为应用开发商提供精准的用户画像分析与宣传推广渠道，为用户提供依据其偏好进行内容与应用等大数据云服务。这类前沿商业模式的普及将进一步把数据资本化的趋势推向明朗。

而谁扼住了渠道的咽喉，他也就将获得的发展大数据云服务的天时地利，因为渠道承载的一切B2C交互信息在目前数据归属权不明确的法律框架下，都可被互联网操作系统运营商所截取与驾驭，并最终通过“数据挖掘与机器学习”技术转化为其品牌数据服务的核心竞争力。

我们有理由预判，在不久的将来，渠道服务、操作系统服务与大数据分析服务将出于结构优势而被紧密的联结到一起，而“互联网操作系统”便是以上三种业态强强联合形成的新服务生态。

“平台”、“电渠”都想发展成“系统”

事实上，微信平台将进化为互联网操作系统只是笔者的一个推测。它最终能不能脱下目前SMS服务提供者的外衣，转型为产业链服务能力聚合者也犹未可知。但笔者相信，对于一切定位于智能终端的“平台”或“电渠”，其最终进化方向一定是互联网操作系统。而且，除了腾讯公司外，国内的其他互联网巨头也在不断的朝这个方向进行试水与推进（例如阿里YunOS等）。

本质上讲，无论是电商、O2O还是社交媒体，一切“平台”或“电渠”的核心价值都是个体与个体间的信息连接，并最终通过信息连接的优化驱动“价值链”的生成。而这在底层逻辑与商业模式上与笔者勾画出的“互联网操作系统”是完全契合的。

在实际操作中，一切渠道型企业先天具有垄断倾向与垄断优势。而在某个细分渠道市场上只剩少量寡头进行稳态竞争时（如大众和美团接近垄断团购市场，微信垄断SMS等），市场红利将逐渐消失，各企业的流量规模也将趋于稳定。欲继续提升企业价值，目前盛行的“补贴大战”模式已开始被冷静下来的投资方质疑其合理性与可持续性。在各大电渠不堪”竞争成本“之累时，他们必然将把目光投向横向拓展服务品类与兑价渠道。

例如微信，坐到SMS头把交椅后，最自然的发展思路莫过于为其庞大的用户群体提供更丰富的增值服务与商业机会。然而，任何企业自身的体量与可调动的资源都是有限的，盲目依靠自身闭合的生态系统去拓展服务范畴将必然造成企业内部管理成本的激增与失控。因此，企业在达到一定体量后若想继续服务范畴的拓展，必然要把自身原本封闭的生态边界打开，打造一个容许产业链合作者自由接入、高效协作的能力开放平台，从而接入产业链中更多类型的合作伙伴，来为用户提供更丰富的服务与价值。

对社会分工结构的变革与重构

无论成熟的互联网操作系统最终会被哪家企业缔造，这种商业模式一旦铺展开来，就注定会对整个移动只能服务产业、甚至整个人类社会的分工结构产生深远而不可逆的影响。

颠覆App开发行业

首先，互联网操作系统崛起所带来最直观的影响是对App开发企业的颠覆。这种颠覆不一定是替代效应，更多的是促使产业链中的专业从事APP开发的企业进行战略方向的转型。可以想象，当越来越多的应用与服务可以通过“功能打包，直接拼接”的“服务号模式”在互联网操作系统”上进行低成本、低门槛的开发时，市场将越来越不愿为传统App开发模式的昂贵与低效买单（况且目前已经有了一些提供免费H5应用开发的公司）。届时，目前APP开发产业中的产能过剩与人力成本过高也将被瞬间激化为足以击垮大部分开发公司的核心矛盾。

另一方面，如上文所言，企业倾向使用APP提供服务有一个重要考量是“将数据牢牢攥在手里”。然而随着数据分析产业与数据立法的进一步成熟，笔者窃以为“将数据攥在自己手里”将给企业带来NothingBut虚无的安全感。首先，数据分析机能的获取远远不是租一台服务器就够了。精准的分析需建立在海量的数据积累、前沿的算法支持与尖端的处理器性能之上。而想企业获取数据分析机能实际上需要长期的研发积累与高昂的费用支持。特别的，对于任何数据分析算法而言，分析结果的精准度一定与其“训练样本（相关数据规模）”正相关。

然而，目前任何商业模式的数据积累效率都不及各大渠道商的九牛一毛。于是愈来愈多的企业将会发现，相比于困守本地服务器中的数据孤岛，直接向互联网操作系统运营商”租赁“数据服务不仅在中短期内可以为企业省下一笔数额相当的基建投入成本，更重要的是，当各大渠道商（包含互联网操作系统运营商）形成大规模数据积累后，其数据分析结论的精准性与前瞻性也是非专业数据分析公司所越来越无法比拟的。而这也将很可能导致使用“自有”数据分析支持的企业在与竞争对手的博弈中处于信息上的劣势地位。

可以预测，在来自多方面的压力下，现有APP产业极可能将经历一场如“百团大战”一般的残酷淘汰与洗礼。在此之后，传统App开发的市场空间将必然的被压缩到”高端定制开发”这一隅之地，而其余大部分幸存App开发公司也只得借助这两年积累的开发与设计经验，转型为低溢价的“软件设计咨询公司”。

最后，笔者为当前的APP开发商们提出一点建议。除了及时找准自身在未来市场格局中的定位外，任何应用开发商都应该尽快获取“开发&运营一体化”的核心能力。因为在新技术范式的驱动下，随着“应用号”模式的兴起与用户使用习惯的变迁，用户对数字应用服务的预期也会向获得定制化、交互化转移。而这也就要求相关企业除了具备一次性开发应用开发能力外，更要及时获取提供持续增值服务的运营能力，以迎合“产品服务化”的大趋势。

重构数字互联网服务产业

互联网操作系统一旦普及，其对于产业的重构远远不仅限于颠覆APP开发行业。站在更宏观的角度观察，对于数字互联网服务产业，互联网操作系统也将细化与扩容整个产业分工体系。

众所周知，在生产维度，社会存在的核心价值在于支持了分工体系的构建。而分工的细化与分工范畴的扩容又将在宏观上提升整个产业的生产效率。互联网操作系统的重要价值之一，便是通过优化开发方与使用方的信息对接，促使应用开发这个生产行为进行二次分工——既应用设计与程序编写的分化。

借助互联网操作系统的数据分析平台与应用服务平台，那些里市场最近的个体或公司可更高程度上发挥其在应用“设计”上的优势，借助平台上的功能结构实现廉价快速的原型开发甚至是产品开发，而绕过高成本、高门槛的代码编写。而对于一些需要复杂逻辑支撑的复杂程序，则由更专业的软件开发团队进行基于原型的深度自定义开发或分包。

另一方面，互联网操作系统“接口直观拼装”的开发模式也将会极大程度上降低编程的技术门槛，同时也降低了整个产业的准入门槛。于是在不久的将来，那些只会设计不会编程，或只会编程不会设计的人都可以参与到互联网服务产业中来。届时也将会有更多的人力、能量与热情被释放到整个价值体系里。

催生数据&渠道服务垄断集团的萌芽

作为一个千亿级价值链的“粘合者”，互联网操作系统得益于其极强的平台属性，也将对其运营商的发展起到至关重要的影响。笔者预测，互联网操作系统经过短暂的竞争&补贴期后，必然将催生出一个寡头垄断的数据&渠道服务垄断集团，并成为整个信息服务产业的主导者与支撑者。

首先，互联网操作系统一旦得到良好的初期推广（当然，任何平台型商业模式最难渡过的瓶颈期也是上线初期的启动阶段），便会通过一个正反馈循环迅速形成流量规模与价值规模的“滚雪球”上升——平台的C端用户越多，其对B端用户的吸引力就越大；与平台协作提供服务的B端规模越大，平台价值也就越大，又会带动C端用户规模的上升。在这种“滚雪球”模式的迅猛积累下，一个或几个互联网操作系统巨头将在两三年的时间内快速崛起。

其次，如上文所言，平台型、渠道型企业在数据积累方面有着天生优势。容易想象，当渠道商垄断了某细分市场的流量时，绝大多数该领域的线上交易数据都将“免费”落入该渠道商的囊中。而同时，由于任何用户群体的需求都有多个维度，当企业在某个细分市场获得优势地位后，大多会通过已获得的流量资源与数据资源进行新市场的拓展（就像是微信利用自身在SMS市场的垄断地位拓展移动应用市场一样）。换句话说，互联网操作系统运营商在迅猛崛起后，极有可能继续在横向市场上进行服务范畴的“滚雪球”拓展，从而转型为资源集中化程度更高的“泛渠道”分工与协作优化平台运营者，并形成更加集中化的数据与渠道垄断能力。总结起来，这种渠道优势、数据优势与服务范畴相互“吸引”的现象，注定会催生出数据&渠道垄断集团这种新型商业生态的“种子”。

这类垄断型企业的“种子”一旦形成，得益其于产业链中的独特地位，其在客观上将拥有相当强的稳定性。一方面，任何第三方力量企图撼动已获得垄断地位的平台型企业时同时都将给整个产业链带来极大的震动。试想，即使是现在的微信如果停摆一天将造成整个产业链多大的损失。加之，随着用户的使用习惯对某互联网操作系统的锚定，任何新进入互联网操作系统市场竞争的企业再想“驯化”用户习惯，形成规模增长的“雪球效应”也将付出极高的成本。仅一苹果公司的OS操作系统进行类比，虽然其拥有极明显的硬件优势，但想挑战Windows行业一哥的地位还是难上加难。

而在主观上，除了希望获取垄断权带来的超高议价能力外，在很多情况下，平台型、渠道型企业进行行业垄断往往也是在激烈的市场竞争中进行的“无奈”选择。参看上个世纪20年代美国的工业寡头竞争，垄断寡头之间的竞争往往会格外的超越底线与代价高昂。而互联网技术大规模推广所导致的“技术透明度”增强也将会使垄断集团间的竞争陷入“同质化陷阱之中”。其竞争成本在某些轻资产领域甚至有可能变为企业支出中的最主要构成。

届时，在各数据与渠道垄断寡头背后的资本集团的驱使下，“摩根式兼并”以规避竞争成本将一定历史时期成为各数字化分工协同平台共同的命运（目前滴滴与快的、大众点评与美团的整合也是基于相似的逻辑）。

最可能的竞争结果是在行业中诞生一个多方共同控股的数据&渠道垄断集团（而非单独的企业），为数字化应用服务产业，甚至是整个社会生产体系提供协作效率优化服务与大数据分析支持。

如上文所言，互联网操作系统的垄断是主观、客观合力造就的必然结果，而这种垄断也势必将引起监管方的关注。试想，随着企业的数据规模进一步累积，其对产业动态的洞察能力、预判能力与控制能力甚至超越政府时，政府对数据&渠道垄断集团的反垄断举措也一定会不期而至。试问哪家政府能允许私有企业或某个垄断集团在产业链中拥有绝对议价能力？哪个政府有能容许私有企业握有某个产业链的核心权柄？当然，互联网操作系统在近几年内肯定还是会处于迅猛的爬坡期，并带给缔造他们的公司以巨大的财富，但这种“麦金来繁荣”能持续多久，任何人都尤未可知。

塑造新的社会分工结构

笔者预测，随着数据&渠道垄断集团的崛起，全社会的协作分工结构势必也会进行一次转型与进化。

一方面，数据&渠道垄断集团将作为一个新生“阶层”把持、垄断着协作优化服务，担当不同劳动个体间沟通、协作的“润滑剂”。而随着“互联网作系统”一类的数字化分工协作平台的兴起，现行“公司制”的生产协作模式对于员工的束缚力与垄断力也将被釜底抽薪（也就是被“互联网思维”布道者们广为宣传的“去中心化”）。随着资本流通与商机流通效率的提升，人与人之间将可以实现低成本的异地量子化协作。只要拥有一定资本，自由人可以将资本通过数字化分工协作平台向遍布世界各地的项目进行投资。

与此同时，如果某个体与小团队拥有生产力或创意，世界各地的资本也会向其涌来。于是，世界范围内的自由人量子生产集群便由此诞生。

综合以上，现行“公司分工模式”或许将被互联网所带来的协作沟通效率提升优势所颠覆。而笔者对未来20年社会分工结构的发展的预判可用一个“双层稳态结构”进行描述：顶层即为“数字&渠道垄断集团”运营的大型社会化协作优化平台，底层则为旗下无数自由人及小团队组成生产集群。每个自由人都如“U盘”一般带着自己的知识与生产力嵌插在大平台之上，在世界范围内进行更加精密化的分工与协作。

作者@cuipeng       来源@虎嗅网

文章链接：http://www.huxiu.com/article/137960/1.html?f=index_feed_article