POC 胜过 RFP：为投资决策优化资源

我们中有多少人愿意在不试驾或不让机修工检查的情况下买车？谁会在不走遍房子并检查房子的情况下买房？有多少 CEO 会在不先进行审计的情况下冒险进行新的收购？

这些场景中的每一个都有一个共同点：我们正在积极投入我们的时间和资源，在承诺进行一项将持续一段时间的大规模投资之前，获得我们所从事事项的第一手知识和经验。 为什么购买软件会有一些不同？

考虑到这一点，我们知道为您的企业投资新的软件工具是多么困难。 在评估此类软件投资决策时，我们发现转向更正式的概念验证 (POC) 会导致更容易的评估和更好的结果。

这是因为 POC 是最好的方法之一，不仅可以深入了解平台及其功能，还可以让您的利益相关者根据符合您的特定需求和要求的真实示例来评估该工具。最重要的是，它是评估实际实施解决方案所需时间和资源的唯一方法之一，尤其是在需要根据您的需要定制工具时。

读完这篇文章，您将了解为什么我认为当前的软件采购流程已被破坏，您将了解为什么您不能不投资 POC，最重要的是您将拥有所需的知识，以确保您的下一个 POC 顺利进行。

1

传统软件采购被打破

我不想听起来像危言耸听，但在过去的几年里，我开始相信当前的软件采购流程存在根本性缺陷。 为了说明我的观点，让我们看一下大多数组织在采购软件时使用的当前流程，最典型的是征求建议书 (RFP)。

1. 从一组利益相关者开始，他们创建了一个软件应该能够执行的巨大需求列表。这个需求列表几乎总是反映当前的业务流程，无论这些流程是否是满足基本业务需求的理想解决方案。

2. 少数供应商被要求对要求列表回答是/否，消除他们回答中的任何细微差别，以免造成混淆。如果答案是否定的，供应商将提供定制作为一种解决方案，试图继续考虑采购，但通常很少或不清楚这将如何影响总体时间表和预算。

3. 根据他们回答的分数，顶级供应商被要求展示他们的软件，以便选择供应商。通常，与实际软件功能相比，这些演示的质量与演示者的能力更密切相关。

4. 引入采购团队谈判最终合同并确保满足任何法规、标准和合规性需求。这个过程可能需要几周到几个月的时间，因为双方都在讨论细节和最终合同条款。

如果你以前经历过这个过程，你就会知道每个步骤中有多少陷阱，以及完成整个过程需要多少时间。 无论是协调日历、收集反馈，还是撰写问题和回复，这个过程几乎就像是专门为延长时间表和消耗尽可能多的资源而构建的。此外，每个参与者都有自己的偏见、假设和解释，因此最终做出决定需要无数次会议、电子邮件和评论线程。

最糟糕的是，很遗憾，即使花了这么长时间和大量资源，你仍然可能背负着无法真正解决真正的商业挑战的软件，而这些挑战正是导致你首先开始采购流程的原因。在这一点上，您要么试图定制软件以满足您的业务需求（无论时间或费用如何），要么重新开始整个过程。

2

我们应该怎么做呢？

如果你正在读这篇文章，你和我有一些共同点：我们生活在现实世界中。 有时，企业必须决定跳过这种深度评估。当团队没有时间致力于这种方法并且采购错误平台的风险很低时，这种情况往往会发生，要么是因为成本最低，该工具可以很容易地换成另一个，要么是企业已经拥有资源，他们可以利用对所选平台有直接经验的人。

在几乎所有其他情况下，亲身体验该软件是最好的方式，不仅可以评估该软件的功能，而且可以确定它是否与您的整体业务流程保持一致（或者可能是一个关键工具） 显著改变和改进您的业务流程）。这也是评估软件供应商本身以及您是否愿意在做出任何长期承诺之前与他们开展业务的好方法。

根据我自己的经验，为了有效地评估您想要集成到您的技术堆栈中的任何软件工具，您需要有机会在现实世界中对其进行测试。

我认为这类似于买房：在我为未来 30 年支付数十万美元之前，你最好相信我会亲自去看看房产，同时咨询其他专家以确保在进行这项投资之前没有任何隐藏的骨架。尽管这会花费我一些时间和金钱，但我这样做是因为它会在我最终计算它是否符合我的需求以及是否值得做出承诺时为我提供关键信息。

房间里的大象

这是没有人愿意承认的问题：没有任何软件能够完美地满足业务需求，无论审查得多么严密。如果企业幸运的话，它可以配置软件来非常接近地满足其需求，但更常见的结果是企业要么不得不使用不能完全满足其需求的软件，要么必须定制软件以完全符合其独特的业务需求。

至关重要的是，如果定制是前进的道路（根据我的经验，通常是这样），你需要在签署任何东西之前了解定制的可行性。 如果您等到合同已经签署，您的业务现在就束手无策，您将被迫采用软件供应商实施的任何标准或方法，以便继续使用该平台。

您应该寻找能够平衡开箱即用功能和易于定制的工具，而据我所知，概念验证是真正了解潜在软件供应商如何平衡这两种理想的最佳方式。

3

如何计划有效的概念验证

虽然一小部分开发人员通常可以仅使用免费或试用帐户来评估软件工具，而没有真正的评估截止日期（如果这就是你，我会嫉妒的），但对基础软件工具的长期投资可以构建或发展您的业务需要更多的结构。

当需要收集您的资源并致力于 POC 时，在继续前进之前您需要考虑一些关键事项，以确保您不会浪费宝贵的时间和资源。

1. 没有正式的 POC，你能做出好的决定吗？

虽然这似乎是一个愚蠢的问题，但您需要评估的第一件事是您是否有时间和资源来致力于 POC。

对于以失败而告终的风险很小或没有风险的小型项目，您可能会发现，更好地利用您的资源，将原本用于构建 POC 的内容用于创建成品，而不是创建成品。

如果速度至关重要，那么有时短期的胜利比理想的长期解决方案更重要（特别是如果您可以在未来再次访问该解决方案而无需重复工作）。

2. 您可以为 POC 投入哪些资源？

建立适当的 POC 需要每个相关人员的时间。您需要问问自己，在您的团队中，谁具备进行此评估的知识和能力。

至关重要的是，您需要确保您拥有所有将与软件交互或工作流受软件影响的关键利益相关者的代表。 如果您内部没有这些资源，则需要评估是否可以聘请合作伙伴与您合作。

最后，您必须决定要为 POC 投入多少时间和资源。一个简单的用例通常可以在几周内得到验证和测试，但一个更复杂的项目或大量的利益相关者，可能需要几个月的时间。

由于您自己很难确定适当的时间表，因此这是一个很好的领域，可以根据您的要求询问软件供应商或合作伙伴的意见。 他们对整个流程、所需资源以及影响总体时间表的因素越透明，他们的判断就越有可能可信。

重要提示：清楚了解哪些利益相关者拥有 POC 的哪一部分是确保在此过程中没有重大障碍或减速的关键。POC 的某些部分可能由您的业务和内部利益相关者所有，而 POC 的其他部分将由软件供应商或实施合作伙伴所有。

3. POC 的范围是什么？

简而言之，POC 不是您的最终解决方案。这是一个有效的实施，证明该软件可用于实现您想要的结果。

因此，您需要确定应该在 POC 中表示多少成品。此外，识别您的成品的哪些元素是软件直接拥有或影响的，并将 POC 限制在最终解决方案的那些方面。

为了说明这个概念，让我们举一个使用 Contentful Composable Content Platform 为电子商务 Web 应用程序构建 POC 的例子。

对于此 POC，您首先要确定应在 POC 中评估最终体验的哪些部分。

• 如果您只需要确定为内容和编辑工作流定义结构的难易程度，您可能只关注内容模型和编辑工作流。

• 如果您需要评估端到端的发布管道，您可以添加构建管道和网络应用程序。

• 如果您正在评估客户结帐流程，您将包括产品页面和商业交易。

• 对于这些功能中的每一项，与影响工具或软件（例如电子商务平台、数字资产管理工具或翻译管理系统）的集成也应作为 POC 的一部分进行评估。

对于上述每项功能，您无需完全充实实施。 例如，当您创建内容模型时，主页、产品页面和类别列表页面内容类型（以及任何相应的子内容类型）可能足以进行评估。

请记住：您并不是要构建您的最终解决方案，您只是对软件进行足够严格的测试以验证它是否可以满足您的特定需求。

4. 你成功的标准是什么？

现在您已经确定了责任方、概念验证的总体范围以及您将投入 POC 的时间量，最后一个难题是确定POC可以被视为成功的结果。

每个 POC 都有一套略有不同的成功标准，参与其中的每个人都必须获得相同的结果，这一点至关重要。

最重要的是，将您的成功标准集中在实现最终结果上，而不是如何实现该结果。 在使用创新工具和颠覆性技术时，完成任务的过程可能与您习惯的不同，这不一定是坏事。

定义成功标准的一个关键方面是不仅要考虑成功的结果是什么，还要考虑谁有知识和经验来公平地确定是否已经实现了该结果。

例如，在不部署代码的情况下进行布局更改可能需要由内容作者和 UI 设计师进行评估，以确保灵活性和易用性，同时遵守品牌指南。确保对于每个成功标准，所有主要利益相关者都同意谁做最后决定。

关于成功标准的最后一点：虽然很容易将您的评估重点放在软件的功能上，但成功的另一个要素是您的团队和软件供应商能够合作的程度。

在做出投资决策时，不仅仅是选择合适的软件，还要确保您投资的合作伙伴愿意投入自己的资源并确保您取得业务成果。

4

如何识别潜在的 POC 候选人

我相信你现在已经看到了，概念验证会消耗你大量的时间和资源，当你考虑采购一个新的软件工具时，你可能会评估不止一个选项。

将这些选项与并行 POC 并排评估是识别工具之间的差异化因素、每个解决方案中的差距的最佳方法之一，它们可以帮助您在做出决定时回答各种关键问题。

话虽这么说，构建过多的 POC 会迅速降低您希望通过这种前期投资实现的回报。以下是我们关于在并行运行多个 POC 时如何决定应邀请哪些工具参加聚会的想法。

1.筛选你的选择

评估多个选项时要做的第一件事是要求供应商向您展示他们的工具的作用。 询问他们该工具的工作原理，他们倾向于如何与客户合作，并让他们向您展示如何使用该工具。

在此期间，让他们解释他们作为公司的理念，以及该理念如何在工具中体现出来。

通过倾听他们所说的话以及他们如何回答您的问题，您将能够识别出明显不适合解决您的业务需求和与您的团队合作的人。

2. 上手体验

尽可能以非承诺的方式试用产品。 大多数软件供应商都提供自助免费试用或提供免费增值服务，让您可以在构建正式 POC 之前试用该工具。

通常免费试用或免费增值产品提供有限的功能和/或工作流程，但这是查看该工具是否倾向于与您的业务及其流程保持一致的好方法。

重要的是，团队成员可以利用自己的时间试用该工具，并突出他们认为最有潜力解决问题的人。

3.询问朋友

不要害怕进入你的网络并四处询问你以前的同事或业务联系人正在使用的工具。 他们会很高兴地告诉您他们喜欢的工具或他们所忍受的痛苦经历。

重要的是，在收集此类反馈时尽量广撒网。 任何个人实施只能代表该团队的意见和建议，因此请尝试收集多个观点。

热烈的推荐可能是一个很棒的工具的例子，但它也可以很容易地代表公司内部的简单工作流程和有才华的个人。

确保询问他们如何开展业务的问题，以了解其如何与您自己的流程保持一致，并尝试就每种工具获得多个意见，以了解糟糕的体验是常见趋势还是单一的糟糕实施。

4.询问供应商

最后，在与任何供应商进行 POC 之前，请他们告诉您他们希望如何与您合作。看看他们愿意为你的 POC 投资哪些资源，并请他们深入了解与该公司的 POC 往往是什么样子的。理想情况下，这应该是双方之间的协作活动，并且每个人都应该投资于取得成功的结果。

5

结束恶性循环

展望未来，越来越多的市场竞争导致技术供应商更加透明、开放，并致力于让人们在做出重大投资决策之前尝试他们的产品。

此外，微服务的发展导致软件供应商的兴起，它们愿意相互依赖，帮助企业构建技术平台，推动其走向未来。

所有这一切都意味着放弃过时的软件采购流程的时机已经成熟，这些流程需要您在确定该工具是否合适之前进行大量财务投资。 所有支持构建 POC 和快速原型的人请举手。

我不能保证 POC 会比 RFP 需要更少的时间或资源，但我保证当你开始实施时你会走得更远。