甲方爸爸，我想跟你说几句心里话

文/明道云创始人任向晖

 

 

明道云在业务转型的两年中有两组明显的变化。当我们从面向中小企业的协作SaaS转向了面向中大企业的APaaS领域，一方面业务明显改观，收入臻臻日上，另一方面作为乙方的议价能力则在滑坡。原因很简单，客户变大了，项目变大了，标的额也变大了，自然相较于之前的中小企业客户，售前和售后服务的难度都加大了。除了运营挑战以外，大客户也倾向于严苛的采购流程，无节制的还价议价，以及不友好的支付条款等。这大概就是业务转型必然伴生的痛苦。

 

议价能力的跌落完全在情理和意料之中，我对甲乙方之间的这些不对等关系本身并无怨言，这是再正常不过的商业规律了。客户是衣食父母，更何况是大客户。

 

我要说的心里话更多的是针对甲方爸爸在信息化项目中一部分值得推敲的采购实践。这些实践做法并没有利用议价能力帮助甲方谋得利益，相反容易把甲乙双方带入到双输的境地。我纯粹就事论事地提建议，希望甲方爸爸不要因此落难于我这个乙方。

 

 

 

（1）采购需求的表达

 

我见过各种各样的需求书（RFP），有的长篇大论好几十页，有的简明扼要得只有一张图，还有一些看起来很详尽，但是并不像一个需求的表达，而是一组产品特性。

 

对甲方来说，需求书的目标是为了准确和完整地表达需求，从而能够从供应商那里征求到最靠谱的解决方案，因此最佳的需求表达方式就是“表达需求”本身。你们不用担心软件公司看不懂商业语言，从而跳过需求，直接讲述软件实现方案。就像你去饭店吃饭，只要带着饥肠辘辘的肚子就可以，最多告诉老板想吃点海鲜，完全没有必要带着自己的菜单进去。

 

直接表达实现方案有诸多坏处。第一，它容易让乙方不明就里，将产品能力往实现方案上生搬硬套。第二，它破坏了创造性方法产生的机会，很少有供应商敢于脱离客户方案，给出自己的另类路径。第三，它让产品型公司难以匹配一个既定的实现方案，又让端到端服务型公司不得不进行过于繁重的定制开发或整合。

 

一份合理的RFP可长可短，它可以包含一些具体的技术规格需求，但是更重要的是要将需求的背景和实质讲清楚。我推荐的结构是这样的：

 

1、项目需求概要介绍，提纲挈领地说明需求要点

2、公司的背景介绍，以及为什么会有这个项目产生

3、项目要实现的目标和预计的使用范畴

4、项目的内容范畴和交付物定义

5、技术规格要求，哪些是强制性的，哪些是可选的

6、交付的时间要求，包含可以的分期安排

7、关键评估点，这部分可能是你的需求中最关键的内容，你希望供应商能够提出比较具体的解决方案，以获取采购信任

8、预算限制和其他限制

9、供应商遴选条件

10、答疑联系信息

 

一般而言，一个中等规模的企业IT需求大概需要5-10页的A4纸篇幅来完成。最好用文档，而不是幻灯片与脑图来提供RFP，因为后者难以表达准确的需求信息，而只能提供辅助的概要表达。

 

一份结构清晰，文字通顺的需求书会让服务商更有动力来撰写详尽的解决方案建议书，这个相互投入是保证客户需求被很好满足的前提。我有看到过不少RFP其实是一些竞争产品本身的规格内容，把这样的内容作为甲方的需求内容发给其他供应商，这是缺乏诚意的做法。

 

 

 

（2）买产品还是买服务，你要先定个调

 

软件公司其实鲜明地分为产品型公司和端到端交付型公司。虽然也有集聚两个角色的企业，但是通常也会分为不同的业务部门。甲方爸爸在招标采购中，似乎总是对这个问题视而不见，很少在采购需求中明确自己的倾向。这其实让两种乙方都很为难。产品型公司看到需求后，倾向于将其解释为通过产品特性来满足客户需求，交付型公司倾向于端到端开发和集成，两者都可能满足客户的部分需求，但却是完全不同路径的解决手段。

 

在国际软件市场上，很少有端到端交付型的公司，即使有，也都是基于某个软件产品的专业实施服务，但是在中国市场，具有集成能力的ISV的确是很重要的业态。在有些行业，甚至就是主要服务形式。

 

我十分建议甲方在发出采购需求时，明确自己在这个问题上的倾向或者要求。你可以这么说：

 

本需求希望由一个主要的软件产品来满足，它应该具备足够的灵活性配置能力来达成项目需求。本项目不希望使用定制开发方式来实现。

 

或者：

 

本需求希望由具有端到端交付能力的服务商来承接，它应该根据本项目需求提供按需定制的开发和交付。

 

又或者：

 

本需求希望有具有端到端交付能力的服务商来承接，并允许选择和集成适应性强的软件产品来提高交付效率，但主要供应商应该承担最终交付的责任。

 

这些选项对需求实现的最终效果有决定性影响，三种情况在软件服务交易中也都很常见。但是，很少有甲方在采购时能够清晰地表达这个倾向。这导致所有的乙方投标者不得不建立自己的假设。其实这些问题明朗化，对所有方都是好事。它也有利于软件行业的健康生态形成，大家各自挣自己善于挣的钱。

 

 

 

（3）招标问题

 

招投标已经是大中型企业信息化建设中司空见惯的做法了。大公司利用自己的议价能力，通过招标来建立供应商竞争，这无可厚非。但是采购招标的很多实践做法，在软件服务门类中会容易扭曲供求关系，产生对采购者不佳的后果。

 

一家大型企业最重要的采购肯定是核心原材料。几乎任何行业的核心原材料都要求试制验证，更何况大多数工业产品的原材料都是标准品，不仅产品之间可以横向比较，而且几乎都有国家或国际标准。这让此类招标项目容易实施，并且可以建立多个供应商之间的基线对比。同质情况下价低者得，这是招标的最重要目标。

 

软件产品和服务大多数是非标准的，而且它不像原材料可以实验室或者车间先进行实验验证。即使可以做软件试用，也只能确认一部分特性能力。这让甲方在供应商之间建立基线对比十分困难。所以软件招标实际上只能对供应商资质、技术能力、产品适配性、价格等多个维度进行专家打分。而且要命的是，价格低者还不一定能在价格维度上得到高分。有的客户追求低价，有的客户则追求投标者投中中位价。这让软件招标项目的可信度大为削弱，控标操作成为客户和供应商不得已的选择。

 

即便招标过程是规范的，它的运作制度也容易伤害需求匹配度。因为正式的招标要求投标人一次性提交所有的投标材料，方案和价格都失去了和客户沟通和修改的机会。开标后即使不流标，最终项目交付出现危机的情况比比皆是。

 

既然招标这个事情在软件门类上这么别扭，我的心里话就是不要用传统招标形式。因为招标并不是唯一的采购方式。除了招标以外，专业采购管理有很多种做法可以充分使用采购者议价能力，降低成本，同时也能够保证业务方的需求能够被得到满足。

 

我建议的软件采购流程包括RFI（Request for Information）和RFP（Request for Proposal）两个步骤，前者只为获取产品和服务的信息，不要求供应商报价，但也不需要供应商付出太多的售前成本。RFI着眼于获取比较广泛的供应商产品和服务信息，资质，过往经验和案例，服务团队组成等标准化内容，供应商不需要提供针对性解决方案设计。RFP阶段则在前期获取信息的基础上遴选少数供应商进行，这个阶段要求供应商提供针对性方案和报价。

 

当提供提案的供应商提交材料后，依然还可以进行多个轮次的需求、方案和价格沟通。在确认少数供应商都能够满足核心需求的前提下，对2-3家供应商进行竞争性价格谈判。

 

这个采购模式虽然比集中招标竞价可能多费一点时间，但是却避免了封闭招标带来的履约风险。总体而言，依然符合甲方的利益。

 

 

除了以上三点以外，我当然还有很多希望甲方爸爸做到的事情，比如多给点预算啊，付款条款更友好一点啦，等等。不过这些问题本质上都是供应商议价能力决定的，所以只能算我们的目标。我们把产品和服务做到有竞争力，自然能够获得更好的回报。我们希望甲方爸爸做出一些促进互利的改变，自然也会要求自己诚意待客，以客为先。

真的，你找不到比我们企业软件行业更实诚的人了。

近期我的文章：

云计算简史

零代码带来的工作和创业机会