文/明道云创始人任向晖
目前大部份行业分析还聚焦在Open AI,Langchain这些和Generative AI直接相关的企业和产品上。实际上,企业软件市场的感知和行动已经非常迅速。在此项技术进入公众视野18个月后,我们来盘点一下领先的企业软件应用是如何利用Gen AI技术的。
微软
微软的企业应用产品以Dynamics 365和Power Platform为子品牌,提供覆盖销售,客服、项目管理,采购,财务等各业务环节的套件,也提供Power Apps等构建自定义应用的低代码开发平台。这个产品架构已经是国际企业软件厂商的标杆性配置,在满足多元化的企业应用需求方面,这个组合具备足够的完备性,ISV生态也极其繁荣,在全球拥有数十万的增值合作伙伴。
在Gen AI应用方面,微软和其他厂商相比具备突出的优势。这个优势主要来自和Open AI的伙伴关系,允许微软作为Open AI技术的独家商业化途径(除了Open AI自己的ChatGPT产品和API服务),而且Open AI的所有技术服务都运行在微软云(Azure)上。除此之外,微软还拥有Microsoft 365(Office应用相关)这个基础办公产品,它让Gen AI技术拥有更多的应用场景和用户触点。
在未来的很长时间,企业应用和Gen AI技术的结合都会以微软产品作为旗帜标杆。这一点似乎已经很难改变。所以,我们的分析从微软开始。
Dynamics中的Copilot
微软产品从2023年开始陆续加入各种Copilot。它们率先出现在Outlook等通用办公工具上,通过和Microsoft Graph和Bing搜索引擎数据的Grounding,提供了结合上下文的智能性。到今年第一季度,微软已经开始在Dynamics等企业应用中开始部署Copilot能力,目前主要覆盖了客服服务,销售,财务和运营,供应链等主要产品。
在Dynamics应用中,Copilot能够完成哪些工作呢?概括来说就是三大类:
1)根据应用的窗口上下文,让用户可以借助自然语言和系统交互。同时,Copilot也会根据场景提供建议的提示词。
2)根据应用数据上下文,生成邮件,文档等内容。
2)根据应用数据上下文,与其他微软产品进行交互
比如,下图就是在Customer Service应用中出现的Copilot对话。作为用户体验的增强,Copilot生成的内容可以直接复制到应用窗口中,也能够实时进行语言之间的互译。Copilot回答文本中如果带有引用编号的,也可以链接到原始来源信息。
Copilot除了节省用户和本应用交互所花费的时间,它还能够帮助用户在不同应用之间传递数据。比如,在Copilot for Sales应用中,就可以直接根据相关的参与成员信息,在Microsoft Teams中创建Channel,从而快速建立一个相关商机的Deal Room。即便没有Gen AI,这个特性其实也是可以实现的,但是大模型解决了很多过去依靠规则匹配不够完美的场景,使得这一轮依靠Gen AI技术带来的产品迭代把焦点放在了用户体验和使用效率上。在微软产品文档网站提供了每一个应用产品目前的Copilot特性一览,以下是Sales和Customer Service两个应用套件的。
Dynamics Sales
https://learn.microsoft.com/en-us/dynamics365/sales/copilot-overview
Dynamics Customer Service
https://learn.microsoft.com/en-us/dynamics365/customer-service/administer/configure-copilot-features
利用Chat界面和应用交互在大多数情况下只能温和地提高一些效率。比如在一个客服邮件或者对话上直接生成Work Order。但是,在某些情况下,它的确可以帮助用户绕过复杂的设置过程,大幅提高效率。
比如在Marketing - Customer Insight(客户洞察)应用中,Copilot可以直接用对话创建一个Journey。Journey可以理解为一个营销自动化活动的配置,过去它通常需要在一个复杂的UI下配置触发器和动作流程,Copilot的确大幅简化了这个操作。
当然,任何Copilot的自动化操作都不会直接生效于系统,而只是帮助用户预先配置好内容,由用户最终确认后保存生效。如下图,就是根据Copilot给出的建议内容生成的配置预览。
当然,我对此类Copilot应用的实用价值依然心存疑虑。在逻辑简单的情况下,用自然语言来替代可视化流程配置似乎能够帮助用户学习产品和建立使用信心。但是在实际场景中,很多自动化流程的前提条件和执行步骤是非常复杂的,用户想要用自然语言一次性写完配置的提示词几乎不现实。这时候,传统的可视化配置依然是帮助用户减轻脑力负担的最好方法。当一个可视化流程已经铺展在画布上的时候,流程设计者可能有更好的思维垫脚石来进一步扩充或者优化流程,这时候,Copilot也许可以继续用在上下文相关的配置细化过程中。
Power Platform的Copilot
在微软企业产品中,Power Platform承载着非常重要的服务使命。和Dynamics应用套件不一样,Power Platform提供的是一种抽象工具能力,它本身没有确定的业务场景,所有场景均由用户构建而成。所以,Copilot在Power Platform产品中就有两个不同层面的作用。
第一个层面是通过Copilot来用自然语言构建应用、工作流和可视化分析。和前面介绍的Dynamics Copilot能力类似,它也是通过提示词来生成应用产品的DSL(Domain Specific Language),从而实现通过自然语言来生成应用配置。
第二个层面是为每个构建的应用配套一个Copilot,或者说是一个Agent,让它服务这个应用的用户。
截止2024年4月的更新,Copilot for Power Platform已经可以完成:
在Power Apps中,通过描述应用想法生成对应的数据表结构(在Dataverse中),提供增加字段,刷新数据,调整按钮,表单和字段类型的建议。Copilot还能够将完成的Dataverse表格转换成具有完整使用功能,带有后端逻辑的应用。在最新版本中,Pilot还能够通过自然语言生成公式、函数和表达式。这使得低代码工具的最后一点门槛也被进一步降低了。
同样,在Power Automate中,Pilot也可以根据自然语言生成工作流配置,对已有的工作流提供优化建议,还能够直接询问文档答案。
在Power BI中,Pilot可以生成交互图表,数据总结摘要,关键指标,也可以直接向数据提问,得到优化数据结构的建议。同样,在Power BI中也有一个叫做DAX的数据分析表达式可以借助Copilot来生成。
在Power Platform中,还有一个叫做Power Virtual Agents的产品。这其实是一个历史悠久的应用,其原型可以回溯到Office的回形针助手时代。在Gen AI技术加持下,Power Virtual Agent的能力被大幅增强。和过去的PVA不同,用户可以通过自然语言来编排Chatbot回答问题。通过一个对话工作流编排器,PVA也可以连接外部数据源,包括网站搜索和微软自家的文档平台产品Sharepoint。
不过,微软目前依然封闭地使用OpenAI提供的模型,而不像其他企业软件厂商和第三方的RAG工具,大部份都已经允许用户自己选择模型。
在Power产品线中,AI能力加持的最后一块拼图就是为Power Apps创建的任意应用加上Copilot能力。微软也的确做到了这一点,Power Apps的应用设计模块中直接有一个Copilot对象可以拖入到Screen中,配置好数据对象(通常就是应用背后的数据表),就可以直接向数据提问了。
微软产品的Copilot也不总是表达为右侧的聊天边栏。在产品的不同位置上,用户可以在特定对象上看到AI能力的出现。比如在Power Apps的Fx工具栏上,随时可以使用Copilot的类似方式来实现自然语言生成短小的表达式。这的确是一个必要的交互范式,否则在遥远的右边栏中,用户对描述任务所要施加的具体对象就会很困难。
以上就是微软产品中Gen AI能力当前所覆盖的特性。这些特性都是在过去一年左右的时间逐步加入的。可以想象,这还刚刚是一个开始。所以,大部分的Copilot功能依然被标记为Preview,能支持的语言也比较有限。微软似乎也没有为Copilot能力设置单独的商业化版本,大多数都面向Enterprise Edition的应用客户免费提供了(尽管微软计划在2024年10月对Dynamics订阅价格普涨11%)。微软似乎也没有为Copilot的使用设置Token限额,这一切都要拜自有算力所赐。微软不需要因为AI功能的算力成本向其他公司购买API Token。这个优势可能会伴随微软很长时间。
接下来我们再看看微软之外的其他企业软件巨头在这一年中都做了什么。
Salesforce
Salesforce其实早在10年前就对AI的技术融合非常重视。通过收购RelatedIQ,Salesforce开始将机器学习应用到销售、营销和服务有关的业务场景,提供业务分析和预测的相关功能。作为一家以CRM为旗舰产品的厂商,Salesforce很早就通过AI技术提供销售机会预测的特性。
2016年,Salesforce将AI相关的技术整合到Einstein这个子品牌。只是彼时的Einstein还没有那么聪明,它的重点价值在于帮助客户降低了机器学习技术的部署和实施成本,算是一个开箱即用的AI产品。
到了2022年,技术趋势的变化使得Salesforce不得不重新审视和调整AI技术路径。通过两年左右时间,Salesforce已经将部分产品的AI能力置换成了Gen AI技术,并和微软一样,默认选择了Open AI的GPT模型。
Einstein AI
当下,Salesforce依然使用Einstein品牌来承载AI能力。它的落实场景和微软的Dynamics应用比较类似。只是Salesforce强化了通过AI来生成内容的能力。在Salesforce的应用上,随处可见Draft with Einstein的功能,这些能力可以由用户通过一个叫Prompt Builder的平台功能来自定义。这个自定义的过程也是通过提示词工程,把任务指令和上下文数据一起组合发送给模型,得到一个更加个性化的生成结果。
而且,Salesforce今天和微软一样,也是一家平台级产品厂商。它不仅有应用套件,也有Data Cloud数据平台,Mulesoft的数据集成平台,和微软的Microsoft Graph类似,Salesforce也有一个表达数据关联关系的Enterprise Graph。这意味着,给出任何一个数据对象,Salesforce都可以返回所有的关联数据集合。在Prompt Builder中,只要在提示词里加上这段代码就可以让大模型拥有更完善的上下文,生成的各种内容也有了更强的针对性,这在销售和营销场景中至关重要。这个设计看起来很精妙,也很灵活,和Dynamics内置的Copilot能力相比,它给了用户更多的自主场景设计能力。这个区别反映出了两家企业的基因差异。Salesforce还是要比微软更加沉浸在应用场景中,尤其关注销售和营销的方法论落实。微软则是一家典型的技术企业,它始终不会对特定的企业应用场景挖掘得过深(除了Office套件)。
Salesforce虽然没有微软的AI绝对优势,但也没有放弃做一个通用企业AI能力的Builder,除了内置的Sales AI,Marketing AI以外,Salesforce还提供Einstein 1 Copilot Studio,对标微软的Power系列产品,提供了Copilot Builder和Prompt Builder两组工具。在Copilot Builder中,开发者可以编排每个Copilot的自定义Actions,还可以通过一个Planning画布来规划AI工作流。
和微软不同,Salesforce似乎对AI产品的商业化信心很足。Einstein AI作为一个附加订阅项,每用户的列表价格高达50美元每月,包含AI能力的Sales应用坐席打包价格高达500美元每月。Salesforce还提供一个AI Cloud的套装,把Sales GPT, Marketing GPT, Service GPT以及Einstein AI Trust Layer打包在一起,起步定价为每年36万美元。而且,无论什么订阅都还限制AI Credit的使用量,超过了还要买增量包。Einsten AI允许用户选择Open AI以外的其他模型,
其他产品
Salesforce旗下还拥有Mulesoft,Slack和Tableau这三个业界领先产品。他们几乎都是在今年的年初开始发布基于Gen AI的特性。
Mulesoft AI实质上调用了Einstein AI的能力,通过自然语言来生成Mulesoft集成流背后的DSL,从而简化繁复的配置过程。同样,我对这一方式的实用性存疑。即便它有很强的生成能力,也依赖集成所关联的API结构有清晰的语义描述。在我们的经验中,如果对象传递不涉及复杂数据关联,且依靠简单查询就能够获取准确结构的情况下,用AI来调度集成流是非常现实的,但是实际情况中,往往为了获取数据,需要嵌套多轮的查询,获取的数据结构也可能是层次复杂的,API参数名称的定义也可能含混不清,这些因素都可能导致AI处理复杂数据流失败率极高。Mulesoft作为一个专业的集成平台,可能对这些API可读性问题做了一层加强。
Slack AI的使用则简单直接得多。对于一个协作应用,它本身处理的就是大量的文本流。所以Slack AI重点解决搜索回答和摘要信息的问题。它能够对Channel中的未读信息快速摘要,也能够在整个组织中用户可搜索的范围内回答自然语言提出的问题。
Tableau则利用Gen AI技术做出了一个叫做Pulse的功能。它能够快速摘要数据仪表板上的数据变化信息,提取核心指标及其变化,并分析变化的要点和背后的原因。Pulse面向终端用户的产品设计非常简明,而且它并不需要用户用聊天的方式来提问,而是主动汇集信息给用户。这个方式可能比Copilot更令用户满意。
ServiceNow
ServiceNow和Salesforce有相似之处,他们都是从垂直应用市场逐步发展成平台产品企业,只是它的产品范畴和营收规模都要比Salesforce小很多。但在企业软件公司中,ServiceNow对Gen AI应用的重视程度非常高,这可能因为ServcieNow的优势领域在客户服务,内部IT服务,HR服务这几个AI提效非常明显的职能环节。
ServiceNow于2023年底发布Now Assist,把相关的AI能力统一用这个品牌来承载。它首先覆盖了ServiceNow的几个主要套件产品。
Now Assist for ITSM是ServcieNow对其旗舰产品的增强。它首先增强了面向用户的虚拟助理能力,能够提供翔实的历史工单摘要,并能够提供对支持问题的回答,而不仅仅是搜索结果。而且,它还能为完成的支持事件生成最佳实践文档。这些能力增强瞄准了ITSM领域的当下痛点,算得上是Gen AI技术的一个典型高价值应用。Now Assist也用于Customer Service Management和Human Resource Service等套件应用,起到非常类似的作用。
ServceNow也拥有Now Platform这个平台产品,它允许用户用零代码方式来创建应用和工作流。和Salesforce的做法类似,Now Assist在Now Platform中提供自然语言生成代码、工作流和流程Playbook的能力,
Now Assist也已经开始商业化,分别以不同的Add-on订阅形式面向现有的产品订户。Add-on的收费会占原有产品订阅价格的60%左右。对于Customer Servcie场景,Now Assist也提供Credit/Pack模式,面向那些Assist次数消耗较大的场景。
SAP
SAP于2023年9月发布了Joule这个AI子品牌。不太理解为什么SAP要使用热力学科学家焦耳的名字来命名一个AI产品。在大多数场合,SAP依然称它为SAP Business AI。
它首先被用在SAP的人力资源SaaS产品SuccessFactors中,提供候选人与招聘职位的智能匹配,面试问题生成,培训材料的智能推荐以及一个对话式的服务窗口。在SAP的产品线中,SuccessFactors的确是最容易整合,也最容易产生价值的选择。
在最近发布的更新中,SAP据称已经将Joule能力部署到ERP,Finance,CRM和SCM等企业管理套件中。和Salesforce的Mulesoft整合类似,SAP也有一个BTP平台同样整合了Gen AI能力。但SAP的产品实在太庞杂了,而且它的云服务也是一个分布在全球不同区域的隔离体系,所以这个进程会比较缓慢。在我写作本文时,Joule在SAP的S4 HANA套件中的能力只限于应用和功能导航的Copilot。
按照SAP的AI路线图规划,Joule在核心产品上计划提供自然语言交互界面,上下文相关的助手服务,任务自动化(帮助用户实现数据输入,创建报告和流程执行),主动性的数据洞察,对话式的数据分析。 就这些能力而言,SAP的竞争对手们已经开始付诸实施。SAP当然也很清楚Gen AI能力已经不可能成为自己的竞争壁垒,而自己的客户又是规模最大的复杂组织,所以即便自己的产品进步很快,客户也不太可能用很快的速度全面采纳。在Gen AI领域,SAP显然在扮演一个追随者的角色。
小结
全球的企业软件市场规模巨大,从业企业和提供的产品也复杂多样。除了本文介绍的这四家企业,活跃在Gen AI领域的软件公司也非常多。我们没有提及OpenAI,Ahthropic等大模型公司,也没有介绍Langchain,Dify等AI工具链企业。这两者本身并没有身处企业应用市场,它们的成功很大程度上要依赖于Gen AI技术在企业软件市场的成熟落地。没有足够多高价值的应用场景,这些上游技术企业依然没办法赚到钱。2C应用领域当然也会带来巨大的使用规模,但是按照产业规模,消费者市场最终只会被少数企业把持,产业能够参与的机遇会越来越少。企业应用+AI可能是这一波AI技术所能够带来的主要生态价值。
从2022年11月30日OpenAI发布GPT3.5以来的18个月,企业应用市场尝试和采纳Gen AI技术的速度的确前所未有。据麦肯锡的分析报告,全球大型企业2023年在Gen AI上累计花了150亿美元,占到了全球企业软件市场的2%份额。SaaS门类占到这个比例花了整整4年时间。从我们分析的产品微观层面,这些投入中至少有一部份是能够实实在在给客户带来价值的。
这18个月,企业软件产品不仅完成了对Gen AI技术的验证,还已经开始规模性商业化。在内容生成,编码协助,数据分析,检索增强等环节,Gen AI技术已经能够支持产品化和商业化。在分析预测,自动化应用创建,任务自动化领域也能够支持一些初级的应用场景。从本文介绍的四家公司的产品设计和路线图看,业界已经对技术运用方式达成了初步的共识,接下来的加速期将卷入更多的企业软件产品,围绕模型,私有部署服务,算力以及下游的实施咨询服务产业链也一定会很快形成起来。
我的最近文章
再谈私有部署
有了这么多套件,为什么还需要APaaS
终于有人支持CarPlay了