文/明道云创始人任向晖
前两天,一家CRM套件友商发了一篇《为什么不建议企业用低代码平台自建一套CRM系统》的公众号文章。
我不知道他们为什么要写这个。是感受到了竞争的压力吗?在我看来,利用自己的官方营销载体否定竞品或者相关品类是营销者的大忌。这相当于卖公寓楼的房地产商向客户说《为什么不要购买别墅》,完全是贻笑大方的做法。更何况,这篇文章的实际内容驴头不对马嘴,丝毫不尊重事实,它给低代码平台扣的第一个帽子居然是灵活性不够。我高度怀疑是小编直接拿标题去问了DeepSeek一下就匆忙出了稿。这家企业也算是CRM领域的头部厂商了,发这样的文章大大拉低了它在我心目中的形象。
回来说正事。企业到底可不可以零代码构建自己个性化的CRM呢?我的回答当然是肯定的。我虽然不否认CRM套件有自己的生存空间,但是用APaaS来自主构建CRM等应用的确具备一些独特的优势。
我先说明清楚为什么APaaS可以实现CRM应用,然后再说说这样做分别有哪些优势和劣势。我会尽力客观表达,至少不会去让DeepSeek代劳。
不同的实现原理
APaaS可以用来构建CRM,也可以用来构建其他类似的商业应用,是因为这些应用的本质都是围绕关系数据库的流程应用。CRM负责管理线索,商机,客户,订单和明细,产品,销售组织等对象,SRM则负责管理供应商,询价,产品,采购订单和明细。不同的是,套件由系统创建了这些对象,并且跨租户共享这些对象(放到一个表里管理),而APaaS则完全让用户自主创建这些对象,每个对象都专属于一个特定客户。所以,套件能够所谓地开箱即用,而APaaS则通过模版来加速实施过程。无论通过哪种方式,解决的客户问题是一样的。而且,一旦这些对象和逻辑被建立起来,APaaS所提供的数据管理,计算和分析能力和套件产品相比至少是完备和等效的。这两者之间没有高级和低级之分,只有产品定位和商业模式上的差异。
CRM套件的对象逻辑
和套件相比,APaaS着眼于解决综合的问题和个性化的问题。它不拘泥于软件品类的边界,只要是企业数字化需求中的对象和逻辑都可以自主创建。它可以用来解决CRM问题,当然也可以用来解决采购,项目,运输和仓储管理问题。不同的问题只是对应了不同的对象和业务流程。在实战中,APaaS更多被用来解决套件所不擅长的离散问题,比如需要核算复杂佣金,或者实现自动化报价的CRM问题,涉及多事业部门的共享采购中心问题,需要同步实现精确管理会计的营业系统。这些离散需求看似孤立,实则普遍存在于有数字化进阶需求的企业中。
APaaS的对象逻辑
APaaS在灵活性方面的绝对优势
无论是满足客户静态的个性化需求,还是动态的需求变化,APaaS在灵活性方面具备碾压性的优势。如上文说明的,APaaS在业务数据对象,数据呈现方式,权限控制,流程逻辑,数据分析等角度提供了完全的自由性。客户可以实现几张表的小型部门级应用,也可以构建数百张表构成的企业级应用,丰俭由人,繁简自定。它甚至可以是一个渐进的过程,从基础的少数对象开始,逐步扩展成更加复杂的系统。
成熟的套件当然也能够提供一定的灵活性。比如某些应用会提供自定义字段(属性)能力,使得客户能够根据自己的运营需要增加一些自定义标签。但这和APaaS的完全自由定义距离遥远。所以,为了解决千行百业的问题,有些套件厂商也开发了自己的PaaS能力,力图在能力上补足个性化需求的满足。发那篇文章的CRM厂商其实自己就有低代码的PaaS平台,不知道为什么还要揣着明白装糊涂。
在垂直细分市场,通用套件其实让客户很痛苦。我们设想一个做定制家具的厂商,他们的业务流程很难依靠一个标准的CRM应用。比如,他们的设计服务是前置的,也没有完整的标准产品目录,就算有样品,每个客户下单产品的尺寸,颜色,面料均不相同。套件所能解决的问题范畴非常粗浅,真正的业务细节往往不得不再依靠Excel的帮忙。定制家具并不是偶然的例子,在中国的制造和贸易领域,小量定制,甚至单件定制是普遍存在的商业模式,再考虑到产品门类的多样性,其实没有办法用一个固定的套件来解决所有的问题。
业务最佳实践和开箱即用
套件公司最有可能攻击APaaS的点可能在于它的开箱即用特点 。是的,购买任何一个CRM应用都不需要客户再去构建那些基础对象,而且套件厂商也会声称他们的产品带有最佳实践和方法论。这也不完全是吹牛。CRM都带有一些基本的商业方法论,比如SFA(销售流程自动化),这是从西方几十年的Pipeline管理方法中抽象出来的,但是这个方法论和每个行业的最佳实践依然距离遥远。比如,上例中的定制家具厂商赖以成功的最佳实践可能来自售前过程对客户需求和偏好的精确捕捉,以及个性化电子样册的自动化生成。因为在竞争激烈的市场中,谁能快速让消费者眼前一亮,谁就有了更大的胜算。
在这个例子中,最佳实践并非来自一般的SFA逻辑,而是来自这个行业特有的“快速看样”能力。所以,为了促进业务增长,定制家具厂商需要的是一套围绕客户体验的数字化系统,而不是管理销售过程的日志和汇报。聪明的老板能够一眼看到问题的关键所在,从而对数字化系统提出带有产业特征的需求。
问题是谁有这样的经验和兑现能力?
我的答案是具备数字化素养和能力的行业专家,只有在一个行业中深耕数年以上,才能对战略和运营有真正的洞察,才能提出行之有效的解决方案。通用软件公司的所谓最佳实践是难以望其项背的。开箱即用听起来很不错,但开箱即用不等于开箱好用。真正好用的软件解决方案离不开行业人的深度参与。
零代码应用平台提供了这样一个机会。通过大幅降低的技术门槛,让不懂软件开发的行业专家能够主导解决方案的设计。并不是所有的行业专家都对软件和IT领域一无所知。数字化转型的迫切需求推动各个产业中的老板和骨干成员开始探索各种数字化工具。当合适的工具出现时,他们能够快速理解企业应用和数据管理的基本原理,从而迸发出强大的创造力,自行构建贴身好用的应用。在明道云的客户和伙伴中,行业人自己动手的案例比比皆是。前面讲的定制家具行业例子并不是虚构的,我认识一家明道云客户的老板就自己搭建出了覆盖定制家具行业全业务流程的超级应用。这可不仅仅是CRM,包括采购,仓储,物流,财务等所有环节的管理都在这一个平台上实现,数据和业务流程完全贯通。
感谢101家居张总提供截图
有人会说,大多数行业人并没有这样的能力。是的,101家居的张总是罕见的斜杠老板。但是,即便需要通过软件专业人员的帮助,有一个这样的可视化应用搭建工具也是至关重要的,因为在专业服务商服务行业客户过程中,客户可以直观看到实现的过程,服务商也可以轻松提供一个原型版本给客户提出意见。这比黑盒子一样的软件开发过程要让人有信心得多。所以,在实践中,大多数行业解决方案依然是专业服务商来提供的,但是这些解决方案很容易得到行业客户的智力和经验输入,让她们更加切合实际场景的需求。
所以,总结来说,开箱即用并不是什么独特价值。重点是开箱后不能让人惊吓。能够融入行业最佳实践的软件设计才能让行业客户开箱有惊喜。我不是说所有的套件应用都不能让客户满意,我只能说这样的产出是需要厂商和行业客户多年的磨合才能得到。
开放性和扩展性
开放性是指的软件产品与第三方的软硬件产品数据互通的能力。在这个方面,应用平台可以说是做到了极致。比如,通过明道云HAP构建的所有应用都自动提供了平台API能力,所有数据对象的增删改查API都很全面。而且,HAP还提供了集成中心,目前国内外的数百个应用都有预置的集成配置,用户只要一键安装就能够零代码调用。即使不在预置应用的范围内,用户也可以快速通过API文档建立集成。集成一旦配置完毕,就可以在整个组织内复用。
我们理解客户选择一个特定软件产品后所必然面临的局限。虽然不能解决客户100%的问题,但是要给客户解决问题留下通路。所以,广泛地支持第三方应用是对客户选择权的必要尊重。写这篇文章的友商也号称开放共赢,但是我在他们的官网上怎么都找不到完整公开可用的API文档。据说是只提供给付费客户。这是什么意思呢?无非是给第三方应用和开发者制造一些障碍,担心损害自己的业务机会,这点小心思在今天这个时代已经很不入流。你看看微软、Oracle、SAP哪个公司是这样做的?
几年前有一个客户问我,说HAP的API这么完善,那么客户如果想要数据搬家去一家竞品岂不是太容易了?你们不担心客户流失吗? 说实话,我想都没想过这个问题,对于企业软件而言,数据从来都是归属客户的,数据搬进搬出本来就是客户的自由。如果我是客户,在选择一个软件产品之前,肯定要看是不是很容易从这个平台汇出数据。如果数据只能进,不能程序化汇出,那我肯定就不会选择它。
除了开放性,扩展性也是应用平台的一个独特价值。扩展性是指用户对产品本身能力的基础上做自主拓展的空间。比如在HAP平台上我们提供的自定义控件,自定义视图和自定义工作流节点等能力都是扩展性的体现。今天,在AI的帮助下,非开发者甚至可以通过提示词来生成一个非常特殊的控件,放在业务表单上。聪明的用户甚至在HAP上不写代码就实现了仓库平面图视图来可视化呈现每个库位的库存商品数量。扩展性在AI的助力下似乎已经没有了疆界。
套件产品的营销对象更多是企业的业务和管理人员,他们可能对这两个因素缺乏考量,但开放性和扩展性对于IT人员更加敏感,他们会更加理解一个软件工具的弹性对于完成任务有多重要。这也体现了APaaS和套件在客户选型过程中的差异。非IT人员可能会对APaaS的产品特点产生畏惧心理,担心自己难以驾驭,所以有时候我们面对业务团队也有一些无奈。但是软件选型的适配性是针对整个企业而言的。如果客户企业的确面临复杂,多变的需求,那么APaaS在开放性和扩展性方面的优势就是一个重要的选型理由。
到底行不行,试了就知道
在市场上,完全的标准套件,完全的自定义APaaS和两者兼而有之的厂商都存在。那么对于一家特定的企业来说,是不是首先要选对大路呢?
我觉得并不需要。在每一个类别中,都分别有优秀和糟糕的产品。有的套件灵活性也很高,可配置内容繁简得当,也符合目标客户的业务实践;反过来说,低代码平台中也有能力绵弱的。套件和平台兼而有之的厂商常常陷入混乱的营销目标,一会儿营销自己的套件,一会儿又强调敏捷定制的重要性。客户想要从品类的营销词藻中找到自己的正确选择是不可能如愿的。真正Make Difference的是具体的产品选择。
所以本文的标题并不是《建议企业用低代码平台自建一套CRM系统》,因为并非整个品类的产品都是正确的选择。相反,选择套件CRM开箱即用也不一定就是完全错误的选择。
概括来说,HAP适合解决的是个性化程度高,有细分行业特定需求,对销售环节中的商务细节有严苛要求的客户,比如复杂报价,复杂算佣,多层级渠道销售,项目化销售等等。如果你是CRM专家,可以尝试用HAP来为客户构建真正能够解决客户痛点的CRM系统;即使您不是CRM专家,只是想解决自己企业的具体问题,也不妨来动手试一试,看看一家企业到底可不可以用HAP来构建自己的CRM。
攻击友商,前途不大,是骡子是马,拉出来遛遛。
最近文章: