有个经典的企业数字化段子：做了那么多系统，到最后用户还是导入导出Excel。
很多人用这个段子来揶揄or自嘲企业做数字化转型“无用”，但段子本身揭示了数字化的需求和痛点：业务流程复杂且变动，系统难以及时满足边边角角的需求。
所以永远需要“导入导出Excel”：导入导出是手动打通数据孤岛；Excel是数据的中转站，是易操作的数据处理平台，所见即所得。
本期我们讨论的主题就是Excel、企业数字化和飞书业务三件套。
飞书最初是用Office为团队提供办公协同，后来People致力于组织管理，到这个月飞书发布多维表格、应用引擎和集成平台业务三件套，代表飞书想从产品走向业务，用轻量级前端深化连接千行百业核心系统的数字化能力。
本场直播嘉宾是西贝餐饮集团CEO助理魏骍然和飞书高科技行业解决方案总经理周琪，由我跟科技观察者倪叔共同主持。

餐饮行业的数字化阶段进程

魏骍然 餐饮行业最早都是用最原始的手抄单。前厅把菜谱给客人，看完菜谱点菜，服务员在纸质手抄单子上记下来，把复写的单子前厅留一联，给收银台一联，给后边厨房一联，三联，厨房按照单子去做菜再上菜。之后开始有了点菜宝，前台点菜可以听客人说你记住菜的编码，用点菜宝把菜记下来之后，收银台打单机出了单子之后，再送到厨房出菜。后来，整个 POS 系统比较成熟了，从前厅点了菜之后直接把单子分到收银台和厨房，厨房会自动出纸质单，这样终于把订单接收和厨房生产就连起来了。但那时这套系统只是单店版的，每家店想要装这些东西，得在店里装一个服务器，属于局域网那种感觉。
进入移动互联的时候，手机上出现了跟吃饭相关的APP，最早是点评的 APP 化，后来出了美味不用等，再后来就是美团饿了这样的外卖平台。人们逐渐习惯于在手机上去做餐饮的日常消费，但那时很多店里还不支持在线点餐或在线结账。到15年左右，店里既有手机结账的终端，也有刷银行卡的POS刷卡机，因为很多人还习惯用银行卡结账现场刷卡。
大约在这个时期西贝开始成立自己的数字团队，开发门店里手机点餐排号结账这一整套客用的服务系统。在前厅客用的这套服务系统建立起来之后，西贝又开始往后延伸跟用友之类的合作伙伴去共同开发，把整个的财务系统、门店的KDS生产看板系统，全部都连通在了一起。现在西贝全国 300 多家门店前一天的实时营收数据，第二天早上会发送到所有核心高管的手机上，现在西贝已经习惯于这样的工作方式。
周琪 魏总说的很形象，特别有画面感。我说一个很关键的词，就是被时代推着走。这么多年每个不同的时间段，大家数字化做得不太一样。
我分享我看到的，第一个阶段可能是偏信息化，第二个是大家非常有体感的移动化，第三个阶段我们会看到很多企业都开始去做云化，把IDC这些基础能力都托管给公有云，自己专注核心业务系统的建设。
我觉得现在是来到第四个阶段，在整个市场其实从一个所谓的增量市场转向存量市场，或者是我们增长速度下来的时候，企业真正开始做数字化，以及做整个数据治理，不管是关注整个组织，还是关注企业内部的提效，以及关注企业内部业务系统的连通。讲究更科学、更高效的竞争。当然各个行业可能阶段不一样，但我觉得趋势大概是这个样子。

多维表格和Excel的区别

潘乱 3月22号飞书发布了多维表格、飞书应用引擎和飞书集成平台业务三件套，意味着飞书它从协同办公、组织管理，在更紧密地走进业务。但尽管中国 SaaS 行业发展了这么多年，做了那么多系统，到最后各家公司最习惯的还是导入导出Excel。如果现在大量的使用 Excel 来进行管理，它可能会有什么问题？
魏骍然 Excel 我们以前用的比较原始。比如总部一个部门要下发一个什么东西，需要一个表格来把信息装进去。表格制定完了以后就开始分发，层层往下发，发到中间可能有新版的要求再发一遍。折腾一两次以后，可能有时信息就乱了，而且分发的过程中也经常会有遗漏。
因为餐饮行业属于劳动密集型行业，尤其我们做连锁经营，全国各地都要开店，它跨地域的范围很广，人也多。虽然现在你可以线上随时发这些东西，但是发完以后，是不是每个人都发到了，是不是每个人都看了或怎么样，你没法去追。这些事都很琐碎，你要是用比较传统这种方式，他就会遇到这种问题。
但是现在我们靠飞书把问题相对改善了，相当于所有的东西都是跟你的花名册和任务系统捆绑在一起。你一个文件你丢出去，我想给谁看，我拉拉名单，拉完了以后这些人看不看，收没收到我知道，并且我还能随时点它。用起来很轻松，不需要额外的再去琢磨这个东西怎么用，使用门槛也比较低。
潘乱 周琪你来补充一下，多维表格跟 Excel 有什么样的区别？包括它能够承载的客户业务的维度，包括它功能的深度上，又往什么方向去做拓展呢？
周琪 其实之前见了特别多各行各业的企业，大家基本有一个共同的体感，数字化的尽头就是 Excel。每个系统每个行业在做什么分析的时候，最后很多都是在 Excel 上去做。
我说下多维表格跟 Excel 最核心的区别。我认为多维表格是本质上是一个行列的数据库，而且它实现的最好的功能就是让所有人可以在线同时编辑，而且我可以定义清楚每一列每一行的权限，也就是我可以实现行列权限精准控制。不同人看到的信息是不一样的，从这个基础上你会发现它拓展了非常多业务的可能性。
如果你做一个业务场景的时候，你用 Excel 可能很难搭出来一个业务系统。但是你用多维表格，有了这些行列权限的控制，有了每个不同的字段的定义，可以让这些人轻松的把自己想实现的业务系统给搭建出来，而且因为它没有代码，一线业务人员就可以很轻松的把搭建起来。所以它应用的领域是非常广，而且有点像是让每个人可以搭建一个自己的业务应用这种感觉。

多维表格的应用场景

潘乱 再问一下魏总，在西贝使用多维表格，它能够覆盖什么样的场景？
魏骍然 我们现在多维表格在学着用，举比较典型的两个例子。一个是我们客服部门跟财务部门在用多维表格，把他们的业务流给他打通了。之前因为我们客服部门要接到全国各地客诉或是问题需求，我们400电话有百分之十几到二十的比例是要开发票的，补开发票的。因为我们发票都可以线上开，但线上开有几个月的时限，经常有顾客超了日期打客服电话补开发票，如果顾客打电话过来帮他开发票，以前的流程是接到电话后把顾客需求记下来，给顾客邮箱，顾客把他的消费小票或者消费记录发过来之后，客服人员需要根据消费记录去找到这是什么时间在哪家店消费的，找到对应的这家门店或区域的财务负责人，找到他之后说顾客什么时间把消费凭证发过去。财务发票开好再传回给客服人员，跟顾客再联系要邮箱或者是加微信之类传回去。
后来飞书的效能顾问帮我们用多维表格把这套流程搭起来了。现在客服人员接到这种顾客需求，只需要把消费记录填到表格里，后面流程自动跑，自动提醒。我们全国有300 多家店，十几家分公司有十几位财务负责人，客服人员不需要这个店归哪个区域，这个人是谁，不需要再去找这家店的财务负责人。他只需要把这个东西填进去，把门店选择好，自动跑后面的流程。在财务收到任务提醒之后，把事情处理完，直接再点反馈按钮，把发票回传回去，客服人员收到之后直接给客人回复就好了。相当于这是我们用多维表格把原来一套比较长，比较繁琐，但是很每天有很多种重复型工作的跨部门工作流程给它整个打通。很多原来需要大量电话沟通或者是微信沟通的事情，现在就自动化就完成了。客服人员体验就非常好，提效确实不少。
第二个是我们产品的研发管理。西贝有两三百号人的研发队伍，有九个研发工作室，每个工作室负责的菜系和产品分类又不一样，但是所有的新菜研发出来之后，或者是老菜改良出来新的样子之后，最终都得去到我们的食品工程工作室去做检测。研发工作室同事们，他们每天可能有几十个品甚上百个品在并行地跑，之前就是靠 Excel 表格统计，每天人为的去筛抓进度或者是推进度，去找人把这个事情确认清楚，进度效率相对来说不是那么理想。现在用多维表格把所有的产品，从研发起点到最终交到食品工程工作室去做检测，检测完之后再把结果再反馈怎么样，也是用多维表格把整套流程搭起来。他起的最大作用就是食品工程工作室的同事可以同时对好多个产品的进度做掌控，他不再需要人工一个一个过，同时每个都会有一个结果，它的进度怎么样就一目了然。这是我们比较典型的两个例子。
潘乱 除了多维表格，我看到飞书也推出了项目管理工具飞书项目，这跟多维表格是什么样的关系？飞书项目是面向谁的？
周琪 简单解释一下。表格刚才我们讲过了，是一个行列数据库，它是给业务人员轻松搭建这些应用的。飞书项目跟多维表格最大区别是，飞书项目在多维表格基础上又加了一个流程管理，你不仅可以把业务定义清楚都有哪些步骤，并且你可以把这些步骤定义清楚流程，而且这个流程是非常灵活可配置的。比如刚才像魏总提到，菜品研发，我们可能有内部特别多的业务流程，我们就把流程配置好，我能同时看到刚才也说的多个任务进到什么程度，可以大大加速我们整个菜品研发管理的效率。
就像刚才多维表格一样，它可以用在很多业务场景。我们有些产品研发的同事会用在产研的这些项目管理，因为飞书项目最初是字节内部服务抖音做的一个项目管理工具。另外像刚才讲的这种餐饮里面的门店开店的管理，菜品研发的管理，包括我们可能跨行业的，包括一些比如销售流程的管理，只要有复杂业务流程情况下，用飞书项目会更适合去做整个业务流程的提效，整个业务流程的数字化。

飞书集成平台和飞书应用引擎（aPaaS）的应用场景

潘乱 顺着数字化继续往下聊。飞书业务三件套里的飞书应用引擎和飞书集成平台，西贝具体会在什么样的场景里面使用到？
魏骍然 应用集成平台的话，我们现在把以前我们跟泛微做的审批系统，还有人资管理系统，还有跟用友的合作的财务系统，现在全部都接到飞书里面去了，并且用审批把这些东西都串起来，所以我们现在整个的各项业务和职能的审批管理、工作管理全都在这里面在在跑。另外我们还有一个事情目前正在推，就是把我们自研的门店个人工作台，看能不能跟飞书集成在一起。
飞书发布会我也去了，我听海底捞周总讲到海底捞一个产品管理，用多维表格，从源头一直到给顾客出菜，做了一个产品问题的溯源管理，相当于从采购到仓储到物流到门店到出品全流程，任何一个环节只要出了问题，拍照写说明，往表格里一填，自动向上一个环节去溯源去。这样一环一环的溯到最后，到底问题出在哪？是因为今天出品不合格，还是原料质量有问题，直接把流程在这里边跑起来了。
潘乱 像是飞书应用引擎，跟多维表格是什么样的关系？是低代码和无代码？
周琪 说说我个人理解，其实多维表格像你刚才提到无代码，更适合给到业务人员去搭建自己所需要的一些基础的业务系统，这个会非常高效。但 aPaaS 或者是飞书应用引擎，它其实还是给 IT 人员的，因为它本质上是把 IT人员一些复杂的，重复的，基础的这些开发功能，给封装起来，你只需要去完成你上游应用层的这些代码开发，会大幅提升这些开发的效率。他们两个定位还是有非常明确的差别的。
魏骍然 说到我也补充一下，刚才说到海底捞感触，漏了个最关键的，就是听他们讲完应用之后，我就觉得用多维表格真的就是，我可能不再说是需要依靠程序员大哥们，你有限的时间和精力了。我可能自己把这事我想清楚了，我知道这个东西该怎么弄，我可能自己就搞定了。真的很轻便，但是管用，把很多工作就能优化了。
潘乱 企业的数字化问题不一定都得靠程序员来解决。之前大公司里面可能都是财务、行政、采购这些部门，他们的诉求一般都是先反馈到 IT 部门， IT 部门把它翻译成他所理解的需求去做落地。现在有多维表格之后，之前那些不具备 IT 能力的公司，或者他原来公司里面不具备 IT 能力的那些从事业务的人，他也可以参与到流程的优化里面去。
周琪 从另一个视角你可以这么理解，很多大企业，它是有特别多的定制开发需求或者业务需求，这个时候它实现方式我会找一些外包公司，或者我有自己 IT 团队，我可以去开发去实现。但反过来想，我们特别多的中小企业，或者是一些大企业的边缘的或者创新的部门，它其实没有这么多资源和实力去做这件事儿。
其实本质上多维表格是满足了大量的这些部门的业务的需求，他们自己可以去搭，把想法去沉淀在一个表格上。作为一个业务系统，快速的推进业务往前迭代，整个效率效果上都会比原来得到大幅的提升。本质上是满足了一些业务人员原来的很多需求。
潘乱 有位同学想问一个对于这件事情业务终局的判断，譬如无代码开发，它会是一个平民化的吗？它会是这种主要是一线员工里面的聪明人，还是甲方专家或是乙方专家主导？后面是谁来主导这件事情？
周琪 先说我的理解。如果谈终局，可能我们得分三类系统。第一类可能是一个比较垂直的业务系统，比如像 Salesforce SAP，它是非常垂直的一些业务系统。第二类就是我们刚才提到 aPaaS 或者是飞书应用引擎之类的这些低代码的开发平台。第三类是我们刚才提到的多维表格，其实它本质上从前到后是一个从专业性到灵活性的一个趋势的迭代。所以其实在这种专业系统里面，可能确实是由甲方提需求，乙方来主导实现。
飞书应用引擎就在这种低代码的环节里面，其实我们看到的更多的是甲方跟乙方内部去做这种需求的对接和实现，更多的是提升 IT 的这些研发的效率。回到再往末端，再往这种应用层，再往业务端，像多维表格，它本质上是大幅降低了去搭建业务系统具的成本，所以是由甲方实现。我想清楚了，我马上可以有个东西去把系统实现出来。所以我们经常有个开玩笑是业务系统次日达，所以甲方还是乙方主导实现，在不同的业务系统上，它的定位还是不太一样的。
潘乱 公司他来做低代码是不是有什么前提？如果公司的业务没有实现标准化的抽象，他的数据也没有建立统一的标准的时候，它适合来用低代码吗？
周琪 回到我刚才讲的从专业性到灵活性，如果他们没有想清楚业务形态是什么，也没有想清楚流程或者是业务能不能跑得出来，我可能就用这种多维表格无代码去搭一套就 OK 了。当我想清楚了之后，我希望流程更固化，性能更好，以及实现的这种方式更复杂，我可能不只是基于行列，我还有特别多其他要求的时候，我去用低代码去搭一个平台。当然等我业务变得最复杂的时候，我可能是采购一个专业的业务系统。
我们经常跟客户讲的是叫主干清晰，末端灵活。我们看到很多 CIO 大量的时间在救火，把时间花在的都是末端。这些用低代码无代码的工具能解决的问题，其实是他们大量花时间的地方。我们把问题帮很多CIO解决掉，大家就可以把这个时间效率给提升，第二让业务自身的活力更强了。因为我们现在都说市场变化非常快，你怎么可以敏捷地去响应市场的变化和需求？其实除了很多业务的决策之外，我们的工具能不能跟得上，我们的这些实现方式能不能很快速的把业务需求给落出来，其实还是蛮重要。
潘乱 这是低代码无代码产品，那像是飞书集成平台 Anycross这个产品的核心价值是什么？它面向谁？解决什么问题？它是否有能力去链接客户现在已有的这些系统，并且实现数据的交互。
周琪 飞书集成平台要实现的就是让数据在企业内部高效流动。字节跳动做得很核心一件事是在做信息的分发，而飞书本身也是围绕信息分发，让信息在组织间更高效流动，促进信息给到最合适的人来做业务决策。其中信息一部分就是数据，这个数据除了我们在飞书一些产品内产生的像多维表格，其实很大量的是企业自建的业务系统，集成平台解决的是这些系统跟飞书的有机结合。我们希望实现的一个目标是让数据找人。有了这个问题，找到你，直接通过飞书一点，完成。还有很多BI分析，很多任务执行等，都可以通过这些数据的打通来实现一键的推送。当数据找人这个事情跑起来之后，你会发现业务效率会提升非常大。
第二个是我们怎么跟现在的企业已有的包括自研的系统做集成。我觉得可以比较确定的回答两个。第一个是我们会不会长期持续做这件事，答案一定是确定的。第二是我们能不能实现这件事，也是确定的。但实现的方式它是分优先级的，比如我们其实跟不管是SAP、Oracle、 Salesforce 用友，包括刚才魏总提到的泛微等等，我们都实现了一些打通。但是我们也知道这些不同的产品，它是有不同的版本和特别多的接口的，所以实行的过程是需要时间的。我们是把市面上比较常见的应用实现了接口打通。所以大家在用了飞书之后，马上能实现数据找人、数据流通这么一个效果。当然长期来看，好处是随着我们服务的客户越来越多，所以我们建的系统越来越多。随着我们自己的这些接口的完备性，稳定性、成熟性越高，我们未来可以兼容打通的系统也会越来越多，来帮大家把整个数据串起来，帮大家更好的去实现数据在内部的高效流动。

如何走进千行百业

潘乱 传统企业的服务都相对比较重的，但对要做数字化底座的公司，他们很多 CSM 都是纯互联网背景的，其实是不懂传统企业的。譬如像飞书，你做这些工具可能是随意的拖拉拽，但其实别人他可能点个审批都是要小心翼翼，他其实不敢乱动系统的。当先进工具要跟传统企业的数字化结合的时候，是不是会碰到这个问题？怎么解？
魏骍然 我说说体感，这种必然会有。你像我们现在还有很多同事说是飞书里一些新的功能，自己也没掌握，我还是习惯于用一些传统的。比如我习惯用PPT，尤其一些飞书会议的，它其实很完整。你把文件写下来以后，用云文档直接逐页播放，去线上开会也很好用。但是很多同事，我还是习惯用PPT，我喜欢写 PPT 或怎么样的。这种观念的改变，让大家迈出第一步是可能比较难的，但真的你迈出这一步之后，对于新的东西接入起来，它也不慢。
所以刚才潘老师说这种冲突，你免不了，但是遇到这种冲突的时候，你就想办法，就可能更多是靠磨合，想办法磨合完善冲突，给他磨合掉以后，让人们去接受或者进入一个新的环境去用它。
周琪 其实魏总提的一个点特别好，大家还是挺抗拒改变的，担心用不起来或者担心出问题。我觉得其实飞书在这里其实做了我觉得还比较核心的两个方向，持续在投入。第一个其实是产品本身，我们在一直降低我们产品的使用门槛，大家可以用，而且可以很清晰的知道这个东西怎么用，不至于，我跟你的业务系统打通了，好像你用了不会用就把系统的数据包括很多流程给搞坏了，这个不会。其实我们也是在产品，让大家把功能用起来，把产品本身给用起来，以及给用好，其实这块还是下了非常大的功夫。
我觉得第二个，飞书有特别强的客户成功团队。其实我们很多时候要跟哪些系统打通，并不一定是我们自己会懂，而是客户告诉我们。但我们的好处是在客户告诉我们之后，我们可以基于我们对飞书的了解，对客户业务，对客户系统了解，帮他去实现他想要的效果。而且好处是通过我们服务一个客户，有了这些实践，有了这些经验之后，我们可以把变成一个相对普适的能力，给到行业的更多的客户，告诉他们其实这样效率会更高。所以通过让企业可以安全的拿到自己想要的东西，以及实现更高的价值和效果来去满足企业的需求，并且把需求很好很平稳地沉淀成经验。有可能很多时候固化在我们的一些行业通用的服务这些环境里面去，这种是我们持续在做的。

飞书怎么看待合作伙伴？

倪叔 我想请问一下周琪，像你们飞书是怎么去看待合作伙伴的？飞书的三大件其实对很多产品会产生影响。我这次我参加发布会的时候，甚至有朋友跟我说，诶，华为好像也做类似的事情了，包括金蝶还专门发了一个声明，华为以后虽然跟我们是同行了，但是也会跟我们合作得很好。我们把问题延展一下去看，说飞书怎么去看待它的开放性问题，以及飞书能不能被集成，你觉得？
周琪 说一下我个人理解，其实金蝶回答还挺负责任的。其实在 ToB 领域不像 to C大家竞争非常激烈，你会看到 To B 很多时候大家是一个竞合的关系。举个例子，比如我们也做一些招聘的产品，但我们其实也会跟很多市面上的招聘产品做集成，我觉得大家本质上是一个竞合的关系，本质去跟客户交付的是一个客户价值，让客户真正用产品把价值给做出来。
至于第二个说我们是不是可以被集成，其实我们飞书最强的就是一些开放能力，我们有我们自己的开放平台，有我们非常多的开放能力。比如鲸准这个产品是给投资人做整个投资管理系统的，其实它的整个系统都是基于飞书的开放能力搭建的，底层是由飞书能力去承载的，而且我们能看到飞书很多这些文档里面可插入的一些这种第三方的工具，包括我们这些开放平台实验能力怎么跟第三方去调用，包括我们未来推出的这些开放引擎就是飞书开放引擎。这些开放平台其实也会让大家很好的把飞书给集成到自己的很多业务场景里面去。所以我是觉得长期大家一定是一个竞合的关系，而且长期一定是一个集成跟被集成的关系。
倪叔 还有一个问题想问，对KA来说，很多东西是自研的，不好接。另外KA原有的系统，也没有多少好的SaaS，比如海外的就把salesface 就跟谷歌微软深度集成，国内可能对方api也没弄好。海外天生接口被集成，国内没有很多好的SaaS，也没有好的集成，两位咋看这个问题？
魏骍然 我们是想系统越简便越好，越包容性越强越好，因为我们就吃过这样的亏。一开始我也说了，我们弯路直路，没少走。有时候有一个比较紧急的需求，短期内你就要赶紧上线去用，去跑起来，业务这需要。为了完成任务，我们有时候做开发，把它会写的比较固定，就写死了，过两天就有一个新的东西需要跟他配合起来，需要往一块接。他说发现这不行了，又再重写一遍。如果大家天然就是插拔式的，或者是开关式的，我们作为使用者来说，当然是希望这就能用的东西都都长这样。并且是我两个系统放一块它都能够直接通，不用我再等着大家去把接口再做完了再弄。所以这还是从使用者的愿望，这种包容性或者是开放度越高越好。
周琪 我们其实在服务很多 KA 的时候，他有特别多自己的系统，我们也是一方面看怎么去一次性的解一类问题，而不是一个个的解每个客户单独的问题，这是我们在每次解问题时候一个大的思考。从另一个层面回答，其实飞书本身做的还是一个投入蛮大时间蛮久的一件事，我们本身也是坚信中国的 SARS 市场会成为一个比较繁荣的状态。所以我们在整个 API 生态的搭建，包括我们自己接口的这些标准性、稳定性的这些方面，我们其实投入了非常多精力。
我是觉得 To B 它不太像很多 c 端产品会非常快的得到爆发，但我觉得生态的长期共建是我们非常坚持且非常认可的投入方向。当大家慢慢标准趋同，或者慢慢API生态像海外一样变得非常好了之后，这个时候我们不管是对飞书去服务客户，包括客户本身的这些产品体验也会好起来。只不过可能确实需要时间，但我们还是持续在往这个方向去坚持。
潘乱 我想问，比如飞书想要去切入业务，先从什么再到什么，中间业务思考是怎样的？因为企业内部的这些管理工具，它其实都是有习惯跟迁移成本的。习惯的人越多，企实迁移的成本越高。
周琪 其实我们也是一直在持续尝试。这个问题我觉得可以从两个视角去看。第一个，我们去先做哪些？这些接口的对接可能对客户的体感或者价值带来的更强烈。比如我们可能对接了你的SCP，对接你的这些 Salesforce 之后，会让你整个使用门槛下降，使用体验提升。包括这种拉群，包括数据的这些吞吐分析等等。我觉得这是一类。
其实第二类，我们也是会遵循行业本身的逻辑，其实每个行业都用哪些系统，哪些系统使用频次很高，甚至是有哪些 ISV 是相对比较透明的？所以我们只要是按大逻辑，从客户的这种需求出发，从市场的这些最高优的系统出发，我觉得大方向一定是不会错的。所以我们也是按这个持续在走，因为随着飞书走进行业，跟各个行业耦合的越来越深。其实我觉得这是一个长期持续要回答的一个问题，我们也在按这个方式去解。

走进行业，飞书打算走到多深？

潘乱 走进行业，飞书打算走到多深？比如商业航天或者高端制造，或者是汽车行业里面，里面都有非常多的非常专业系统，且国内基本上现在都没办法复制。飞书要往业务走，想走到多深，你总不可能这些东西都干吧？
周琪 对，边界还是相对清晰的。一些行业的专业系统，你会发现飞书是不碰的，比如像刚才提到的 PLM 系统， 包括一些 ERP 等等，其实这些我们是不碰的，我们更多的是希望跟这些系统做链接，做数据的打通，做这些流程打通，做一些效率的提效。包括我刚才提到像数据找人，像自动化的通知等等。让他的系统架在飞书上，把各个烟囱给打通。我觉得这是一个很核心的点，我觉得边界在这里。
第二个，从我们自身能力出发，其实我们也在给企业很多的灵活性和可能性。因为刚才也提到一个词叫主干清晰，末端灵活。在我们服务客户之前，他可能只有主干，他的末端就是那些Excel。但现在我们去服务很多客户之后，它可以基于飞书应用引擎，基于我们的多维表格来把这些末端，原来这些核心业务系统它无法去实现的这些效果其实给覆盖掉。这样对整个企业的组织生命力，对整个数字化的活力其实是大大的激发了。觉得这是我们可能去服务很多行业客户，真正在发力和真正希望帮客户解决的问题。
倪叔 魏总，问个您具体的，像从您的实践经验出发，有没有一些更加实际的落地的案例或者做法，可以给大家一些数字化上的建议，让大家少踩坑。因为你开始讲你们其实是直路弯路的，走了很多也交过很多学费的。能不能帮助其他的也想做数字化的企业，看我们怎么样能把学费少交一点。
魏骍然 正好我看评论区有同学在问西贝觉得飞书哪里最有价值？其实我可以把这两个事放在一起讲。按照我们这么多年趟过来的经验，数字化绝对不是一个人、两个人或少数人的事情。企业的数字化转型一定是全员的事情，尤其是你做数字化办公转型的时候，你想一定是大家共同参与，才能够在短的时间内或者是理想的时间内，把这个事情给它做到理想的状态。如果你说只是少部分人，大家相当于在转变的过程中，时间成本、人力成本就不可估量了，并且很多变数你是也没法控制的，飞书就可以把人和事充分的联动起来，让每个人都有机会参与其中，让数字化办公与每个人有关，这与飞书的all in one和各个功能细节都有关系，也是我认为飞书价值最大的地方。
我觉得可能行业不同，或者是大家工作习惯不同，比如在互联网行业可能习惯于快速迭代，可能大家对于这种事情习以为常，但对于我们餐饮行业来说，我们可能习惯于自己本身的业务的快速迭代，但不习惯于数字化工作这种新环境适应的快速迭代。如果有别的企业要进行整个工作模式的数字化升级改造，一定是强有力的去组织做全员的参与，这样让会让事情顺利很多，也会能更及早更快的暴露一些问题，让大家去解决它，最终把这个事情去弄好。
周琪 对，其实你会发现我们很多业务系统，它其实是给一个企业的少部分人去用的，但飞书是给一个企业全部的人去用的。其实这一点就会让很多不管是沟通方式，甚至构建企业文化，包括其实大家发动起来做件事会变得更简单。其实基础对整个企业做事情还是蛮重要的。
潘乱 我理解到最后帮飞书贡献收入的，其实大部分也都还是 KA。我有一个问题好奇，中国值得做的 KA可能也就大几千家，能够支撑起规模收入的可能不到 1 万家。类似于这种新经济客户，有些品牌辐射的以及愿意付费的用户，就是这一类的甜点用户飞书是不是已经吃了不少？下面还能再往什么方向去走，去拓展？
周琪 说我个人一些理解。其实飞书整个商业化也就三四年的时间，刚才讲到中国可能就大几千家这些 KA 客户，对我们来来说 KA 客户的数量远还没有这么多，我们还有特别大的空间去增长，我们要持续地不断地去获取更多的 KA 客户的信任，去给大家带来价值。
第二，其实不光是这些头部的客户，其实飞书也服务了巨量的中小型的企业。我们很多中小的客户，其实刚才讲到把多维表格当自己的业务系统，比如真正用飞书项目把自己可能业务流程管起来，把自己研发效能去提升，其实这些都是非常常见的，所以在中小企业我们也是有自己的商业化团队，再去服务这类的客户。
但第三个，飞书发布会上也提到，飞书本身也一直在看海外的机会。因为字节跳动本身也是一个全球化的公司，我们在海外很多地区也有我们自己海外的 Lark 产品在去做海外的商业化，其实我觉得对我们而言还是能看到大量的机会，以及大量的成长空间，只是我们还要继续努力把这些事情给做得更好。
潘乱 可能十个公司就有 10 种不同的管理思路跟流程。如果你要真的要去拓展非常非常多客户，你怎么去抽取这一些通用的、规范的流程，帮助这些公司去做提效呢？可能中小客户不知道自己要什么，中大客户可能觉得自己也很牛逼，觉得数据都是机密不愿意 SaaS， 大型客户肯定妥妥就自研了，人家要搞定制。
周琪 其实说实话，这个确实是我们在商业化过程中遇到的问题，但实际上目前解的都还挺好的。因为你如果看现在飞书的客户已经是来自各行各业了，每个行业对飞书用法其实差异还是蛮大的。我们服务的有像餐饮领域的客户西贝，有像医疗器械的企业联影，其实你会发现大家用的是非常不一样，我们怎么能去满足大家各行各业不同的需求？本质上我觉得还是做两件事情。
第一件事情是明确边界。我们一定是做我们自己擅长的，然后不擅长的，或者是更专业的。我们来去做数据的打通和集成。所以从我们看去服务客户，我们会服务很多所谓的不同行业的通用场景。我举个最简单例子，大家都要开会，我们把这个场景能不能做极致对吧？大家都想写文档等等。我觉得这是第一个通用。
第二，我们其实还会服务很多核心的业务场景，每个行业业务场景它的做法还是挺不一样的。而这个时候其实就需要两个能力。第一个是我们灵活的跟客户的业务场景去结合的能力。不管你基于我们的多维表格，我们的飞书应用引擎，包括我们的这些飞书继承平台的能力去继承，去解决业务场景提效。还有我们一个很核心的是我们有我们的客户成功顾问去深度的提升的服务客户，帮他把这些场景的效率给提升，把场景价值给做出来。我觉得持续沿着这两个方向走，在我明确我们边界基础上，其实你会发现在刚开始我提的飞书在每个行业怎么用，其实是客户在教给我们的，它一定不是互联网公司的用法。

团队人数为什么这么多？

倪叔 我想顺着这个话题我们再聊一个问题。重服务其实是飞书非常重的一个标签，一方面它带来了客户的体验很好，但另一方面它带来了很重的团队服务成本，你们怎么去看待这一种取舍？业内在去年其实有一个很大的讨论，在讲飞书的人员的问题，甚至出现过一个说法，拼多多才 7000 人，飞书为什么需要 8000 人？但是我觉得它是放在一个不同的视角去看的。对于飞书来说，是 DAU 这个事更重要，还是 ARR 这个事更重要？我们外部应该怎么去理解飞书这家公司？
周琪 我先说一下我个人理解。其实在发布会上谢欣也大概解释一下这个问题，飞书其实有几千人，但你如果看全球最大的这种 ToB 的公司，都有几万人，其实我们还有很大的成长空间，因为我们也会做更大的市场。我觉得从另一个维度，如果我们讲飞书，整个服务团队的这些效率，我们还是回到一个企业，长期一定是需要去关注自己的盈利能力，要不然其实你很难去构建一个很好的生态，你可能周围的这些合作伙伴不会去跟你玩得很好。所以其实从这个角度，其实本身我们的盈利能力是在持续提升的，我们服务的客户的这种效率也是在持续提升的。
当然为什么早期会铺那么重，其实我觉得本质上还是因为你在走进不同的行业，你有非常大的学习的成本。你的客户怎么用飞书，怎么去帮他把这些业务给做得更好，需要我们去深入客户去把这些事情做出来。但反过来就是当这个事情做到一定程度，其实后面的边际效应也就会比较高了。我们整个产品的适应性，整个产品的所谓的通用性、灵活性，也会得到更强的这些保障。这样我们再去服务新的客户的时候，其实我们的整个服务的这些专业程度，甚至我们服务的这些效率，都是会得到大幅的提升的。
继续阅读
阅读原文
关键词
代码
客户
时候
能力
两个