文/明道云创始人任向晖
我写的上一篇《研究一万个数字化概念，不如体验一个软件产品》指出了我们行业中存在的一个问题。过度谈论概念和理念，而忽略了解决客户问题的真正载体——软件产品。
实际上，大多数的企业数字化需求都是由具体的软件产品来解决的。概念和理念的发明，在大多数情况下都是现有软件产品的营销之道。先有概念，再有产品的情况在整个IT行业都极其罕见。反过来说，也只有具体评估了软件产品以后，才能对门类、概念和应用理念有真正深入的认知。
搞明白自己的核心需求
在评估软件产品之前，最重要的是将自己的软件需求厘清。这些需求信息将用于指导后期的评估工作。因为评估工作可能涉及较长的时间，并且有多人协作完成，因此这些需求必须书面记录下来。
软件项目需求包含几个核心的问题：
1）最核心的业务挑战
它需要被表达成一段或者一组范式化的语言。在选型早期阶段，它可以比较概括。
这个句式可以是：
帮助【业务角色】完成【期望达成的功能】，以达成【期望获得的成果】
例如：
帮助人事招聘部门实现智能筛选简历、和业务部门高效协同面试和录用的目的，以实现每月100人以上的招聘工作量。
帮助项目管理部门和总经理办公室实现项目进度和成本的精确管理，以实现更精确的项目报价和更可靠的进度成本控制。
帮助信息部门快速开发部门级应用，以实现用五人以内的支持人员满足公司在行政、人事、运营等环节的数据处理和流程自动化需求。
对于复杂的软件门类，这样的描述可能不是一句，而是一组。在完整的ERP软件选型中，这样的描述可能多达数十行，分别针对不同的职能环节。
2) 软件使用用户范畴和人数（可能和待评估产品的定价有关）
3）软件要管理的记录数量级别（可能和待评估产品的性能指标有关）
4）软件的投入产出预期（决定了预算和价格评估标准，但因为使用ROI的表达，所以它依然保留了弹性）
5）负责选型的决策机制，决策时间表（避免软件项目进入决策泥潭）
企业软件是一个专业化程度很高的行业，对于一般企业客户来说，评估开始前的需求定义不需要过于细节，而是要着眼于期望给自己带来的业务价值。在真正的评估开始之前，功能点甚至都无法列举得出来。但是让我们明确自己所想要得到的成果后，通过横向对比软件产品，自然能够把需求背后的功能点发现出来。
反过来说，如果一上来就勉强地列出需求功能点，然后机械地和待评估产品的功能点去比照，很可能会错失最好的方案，因为不同软件产品来满足需求的方式可能不同，用户要关注并非功能点的定义和多寡，重要的是自己的需求是否能够被满足，甚至最好是能够被创新的方法来满足。
获取Long List
根据软件需求确定软件门类应该是不难的事情。一般大中型企业的IT人员都具备这方面的领域知识。也可以参考我之前写过的32个企业软件门类名称和释义
确定了需求所对应的企业软件门类以后，就可以通过一般案头调研来获取比较完整的厂商和产品名单。在过去几年，随着SaaS产品模式的普及，市场上有几家企业软件行业平台都提供了产品库和云图这样的资源，比如崔牛会、选型宝等。行业研究机构每年也会定期发表不同门类的市场研究报告，其中都会带有代表性厂商和产品列表。
国内的这些Long List目前还停留在产品和公司目录的级别上，他们还不能提供客观的使用评测内容，所以选型客户还是需要从这个长名单开始缩减，将长名单压缩为一个短名单，留下三到五个产品来进行横向比较。
形成Short List
获取Short List的第一个鉴别标准，就是看待评估产品是否能够提供免费的试用版本。
有人认为复杂的企业级软件不适合让客户直接试用，这完全是没有道理的。在企业软件市场上，就连数据库、开发工具、中间件这样的专业产品也都广泛存在免费评估版本，更何况应用产品。在今天的云计算市场中，100%的产品都必须提供试用，无论是SaaS产品开通试用权限，还是私有部署产品获取试用许可证，这是一个基本的筛选标准。有的产品的免费试用是完全自助开通的，有的则仅仅是提交一个联络表单，依然需要人工联络后才能有选择性地开通。我们当然需要找那种能够公开自助试用的产品。
除了免费试用版本以外，企业软件也可能通过提供演示账户（Demo Account）的变通的方法来帮助客户评估。这个方法可以避免用户在试用软件的时候投入过多的精力进行初始化配置，也可以让客户充分体验接近真实使用环境的软件功能。但是Demo Account一般禁止用户进行创建和数据编辑的操作，因此，它只能算是一个评估部分功能的方法。
因此，鉴别企业软件产品质量和适用性的首要评估标准就是检验该产品是否可自助试用。一个不能让用户自助试用的软件产品几乎一定不会是有竞争力的产品，至少不会是最好的产品。在用户试用环节设置过多障碍的产品也一定是实施困难度很高的产品。在形成短名单的过程中用这个硬标准，基本不会误杀无辜。
当然，在企业软件市场，依然存在一些需求是很难通过软件产品直接解决的。比如围绕数据治理和开发环境优化的所谓中台建设。这些本质上属于IT咨询+实施的项目，在实施过程中可能会使用到特定的软件产品，但它的选型过程也是要由实施企业来完成的。对于业主单位来说，并不可能围绕这类项目性需求来直接试用产品，这些是合理的例外。当然，我并不建议企业轻易实施这样的项目，因为高度的复杂性和困难的协作过程，它们实施的成功率非常低。家业足够大的企业希望通过这个过程来锻炼基础能力，可以自便。
在过滤出能够直接评估的软件产品列表后，如果数量依然大于个位数。建议企业还是要通过进一步的案头调研来减少评估产品数量。因为每一个企业软件产品的试用评估都是要耗费精力的，如果五个产品都选择不出适用的，那么50个只会更加选不出。在这种粗选过程中，企业经营年限，产品成熟度周期，厂商团队规模，增值服务伙伴网络，现有客户列表等都是有用的参考要素。
自助测评
客户自助验证是目前中国企业软件市场所处阶段的被迫选择，也是我认为行业亟待解决的效率问题。因为专业的中立评估者的严重缺失，导致在市场上完全没有一个可以直接利用的可靠信息资源。相比较，欧美的企业软件市场中存在很多层次的评价资源体系。从免费的G2网站到昂贵的Gartner，Forrester Research会员，他们都提供了产品特性级别的评价数据。在中立性方面基本可信，在数据翔实度方面更是领先国内很多。
免费的G2企业软件产品评价库
咨询公司的付费服务
企业软件采购是重要的企业理性决策，很难凭借厂商的宣传材料做出选择和决策。所以，在客观中立数据缺失的情况下，软件产品的选择就必须依靠自己的亲自验证。
创建试用任务清单
假设我们筛选出同一品类的5个产品开始试用评估，在正式动手之前，我们需要先创建一个用于横向比较的试用任务清单。这个清单列出了通过软件需要完成的任务内容，通过试用，可以评价每一款产品满足需求的程度。产品可能完美支持了任务需求，得到5分，也可能完全不具备对应功能，从而得0分。
不同的试用项目必然配套了不一样的任务清单，任务清单不需要贴合厂商产品的特性清单，它只需要完全根据企业自己的需求来设计即可。对于多部门共同参与使用的软件，还需要和相关的部门使用者确认这个清单的完整性，验证他们的关键任务需求都能够得到体现。
下表是一个围绕项目管理软件采购需求的评估任务清单。受限于篇幅，我只列举了少数样例任务。实际评估中，一个典型的企业软件评估任务可能会几十到几百个条目组成。当然，如果应用范畴较小，相关的经济利益有限，评估工作自然也可以因繁就简，可以跳过那些软件的基本功能，而专注于几个比较重视的关键能力。
项目管理软件试用评估任务清单 | ||
任务 | 需求 | |
1 | 创建项目 | 支持自定义字段 |
2 | 在项目下添加任务计划列表 | 支持批量创建，支持从PROJ/Excel导入，支持前置任务，任务可分组，任务可有多成员参与 |
3 | 从项目创建项目模版 | 复用现有的项目数据（可选择范畴） |
4 | 记录项目开支、工时 | 开支支持财务科目配置，工时精确到小时 |
5 | 创建资源 | 能够实时显示资源占用情况 |
6 | 任务管理 | 标记任务完成率 |
7 | 通过接口创建/编辑项目 | 与CRM对接，支持向自定义字段写入 |
8 | 通过接口创建任务、资源、开支、工时 | |
9 | 创建计划基线 | |
10 | 进度落后重新安排任务 | |
11 | 打印甘特图 | |
12 | 打印项目任务清单 | |
13 | 打印工时报表 | |
14 | 打印资源利用报表 | |
基于这个清单，在逐个测试软件产品时，可以对每个任务的支持情况评分，从而得到一个相对客观的全面评估结论。有了这个控制用的清单，即使是评估任务通过多人分工进行，也几乎不会影响横向比较的客观度。
要注意的是，对使用性能有较高要求的客户，可以另外增加性能评测指标。比如检索的速度，批量上传数据的速度，执行某项复杂计算所需要的时间等。
给厂商发RFI
接下来的这一步非常关键。虽然企业已经进行主动评估，但是在落实采购选择之前，一定还是要安排厂商进行提案。为了征求提案，企业可以将自己的核心需求表述和评测任务清单转换为RFI（Request for Information），请厂商的售前和销售人员给出完成这些任务的途径。这个说明既可以用文档、截图来表达，也可以用Live Demo来直接表现。
这个过程弥补了企业自行评估时的信息不足。不同软件产品可能有不同的设计理念和逻辑，这导致有些特性未必能够被客户主动发现，实现的路径可能不是最佳的。厂商也可以利用这个机会充分说明产品的灵活度和解决问题的能力。
RFI的响应水平也间接考核了厂商的服务能力和服务态度。业务人员是否精通产品决定了未来能否提供高质量的售后支持。
RFI当然也要求厂商给出报价和服务选项。有了这些信息以后，结合厂商的资质信息，客户就可以进行最终的横向比较，做出正确的采购决策。
在产品能力和价格以外，需要加入到比较过程中的其他重要因素还包括以下几个方面：
产品生命周期：企业软件产品的成熟度很少有奇迹，大部分可用度高的产品要经历必要的迭代改善，通常复杂的门类产品需要2-3年的时间。当然，时间也不是越长越好。10年以上的软件产品很少能够保持固定技术栈的持续迭代。
行业服务经验：主要看的是厂商的现有客户构成中是否包含足够的同行业和同规模的企业。在不同行业中，软件的应用方式和关键功能组合是不一样的，所以有相关服务经验也是一个合理的加分项。
售前服务：在采购之前，能够评估的服务只能来自售前环节。但它也基本能够反映一家厂商的服务水平和态度。通常，售前阶段能够较好地回答客户疑问，给出有效解决方案的厂商，售后也都能够。客户可以通过这个过程评估厂商服务的响应及时度，反馈质量，以及在内部协同产品研发职能的能力，比如提出的需求能否在需求池中记录，能否和产品团队建立沟通。
生态支持：对于复杂软件门类，是否有生态支持也是重要的评价指标。一个成熟的企业软件大概率会影响到一批ISV或者实施商。拥有生态成员的产品通常能够更好地满足行业垂直客户的需求，也能够提供更多的服务选项。
横向比较
通过以上五步漫长的过程，客户就可以将得到可以横向比较的产品列在一个表格中，汇总测评任务清单结果、资质和服务评估项，以及价格。有这些丰富的维度，想买错产品都很难。
产品A | 产品B | 产品C | |
产品测评得分 | |||
任务1 | |||
任务2 | |||
任务3 | |||
性能测试1 | |||
性能测试2 | |||
产品生命周期 | |||
行业服务经验 | |||
售前服务 | |||
生态支持 | |||
价格 |
企业软件产品评估的确是一件累人的事情，但是它的确能够给企业带来重要的成果。数字化建设之所以困难，很大的原因在于相关过程的复杂性。我们能够想办法把这个复杂的过程计划得更加有序和科学，但是不要有不切实际的银弹期望。
在企业软件采购选型过程中，也有几个常见的错误做法。这些错误都和试图简化评估过程有关。
1）员工投票
试图用绝对民主方式来决定复杂企业软件选型是不负责任的做法。你看上面解析的所有步骤，想象如果没有这些信息的人凭借自己的主管感受和直觉来投票，这个结果会有多么不靠谱？民主投票的结果可能还不如抓阄选一家。
2）招标
招标作为一项采购方式，在标准商品采购中发挥很大的作用，它几乎一定能够降低采购成本。但是在标准化程度很低的企业软件市场（没有两个企业软件产品是一样的），招标很难起到这样的作用。相反，它反而鼓励了供应商利用低价进入，再实现供应商锁定效应，从而提高客户总拥有成本。
另外，企业软件的招标技术要求很难起草。因为它既不可能取所有供应商的能力合集，也不能只取它们的交集。软件产品也不可能因为招标客户的技术需求，就立刻升级或修改自己的产品功能。
即使企业采购制度强制要求招标，业务采购者也绝对不敢将最终的选型寄托在开标的一瞬间。
大企业要利用自己的议价能力降低采购成本，在企业软件产品采购过程中，只能在评估结果出来以后，邀请2-3家入围的供应商进行竞争性磋商。这个过程同样可以起到压低价格和避免舞弊的作用。
3）价低者得
这最后的一个错误是不言自明的。如果价格是主要的决策依据，那么何苦还花这么多时间和精力来进行横向评测呢？直接要一个报价单不就完事了么？在成熟企业软件产品中，虽然不那么绝对，但大体体现的还是优质者价高的基本规律。特性丰富，质量可靠的软件产品背后总是离不开大量的研发和质量管理投入，它是没有理由在市场上用低价销售的。
企业未必要追求功能最完善，服务最好和最贵产品，但是选择最便宜的产品却几乎一定是错误的。如果基于最低价的选型是成功的，那么悖论将很快发生，因为那个产品很快就不会是最低价产品。
写到这里，我倒是希望市场上能够有人愿意投入发展一项服务，这个服务用可靠的客观机制来完成独立的软件产品特性评估。它不仅能够节省甲方采购选型的成本，还能够为软件产品厂商提供具体的竞争标尺，推动行业整体进步。像G2这样的服务总归要在中国出现一两个。只要有志于此的创业者不要贪恋厂商的营销费，排名费，他们最终一定能得到企业用户的信任，从而站着把钱挣了。
我的最近文章：
穿越六年艰难转型，明道云终于再获主流投资
数字化转型方案是给谁做的？
研究一万个数字化概念，都不如体验一个软件产品
