在接下来的文章中，我将重点介绍这种想法的产生方式，以及我认为在完全实现该模型之前需要解决的主要问题。
根据调查，当今的组织对软件代码采购的兴趣越来越小，无论是购买许可证还是租用云功能。相反，他们设想他们购买的最终结果是软件及其提供商可以帮助他们实现。
据我所知，只有少数软件公司冒着引入这种方法的风险。提供托管服务的四大咨询公司中至少有一家与其技术合作伙伴一起提出了按结果付费的原则。不幸的是，我不知道与此想法相关的财务结果，甚至不确定这些供应商和顾问是否仍在遵循这种非传统定价模型。显然，基于结果的定价甚至不接近商业软件行业和公众所熟悉的程度甚至众所周知。
为了说明这一点，以下是对基于结果的软件定价模型的看法：
SaaS不仅是APP销售的一部分，而且是整个生命周期。[我们]甚至在客户成为客户之前就开始利用和衡量客户的成功。UNIT4为客户提供的结果将衡量为客户创造的价值。将来，除了使用我们的APP外，我们可能会因客户创造的结果而获得我们的回报或回报。这是软件即服务APP将在何处结束的扩展视图。我们已经从购买APP的世界变成了将APP作为服务使用的世界。客户越来越多地要求我们研究使用这些APP将产生的最终结果，而不仅仅是我们如何使用APP。我认为随着时间的推移，这些结果将越来越受到诸如KPI之类的驱动，我们可以通过在客户环境中使用我们的APP来影响这些KPI。我们不是在出售APP，而是在构建到APP中的价值功能方面考虑APP。业务成果将取决于我们如何为客户增加价值，而不仅仅是我们所销售的产品和服务。
尽管基于结果的软件定价似乎是一个有趣的讨论点，并且通常是一个不错的想法，并且有可能改变整个商业软件行业，但我认为没有什么考虑需要软件供应商和供应商进行更深入的研究和明确回应。他们的客户才能实现。
尽管该业务模型看起来非常有吸引力，但它不仅可以激励软件公司销售其产品和服务，而且还可以激励供应商和他们的客户对使用这些产品和服务的整体成功深感兴趣。虽然这些想法在理论上似乎听起来很合理，但在实践上看来，情况可能会变得更加复杂，非常模棱两可且充满争议。
想到的第一个问题是如何以货币形式识别，度量和转换特定软件包为客户带来的总体价值。对我来说，这是一个非常复杂的任务。考虑到在不同类型的公司中进行的每个软件项目的所有独特方面，即使是简化版本（即软件的投资回报率（ROI））也很难正确定义和计算。尽管当今许多组织能够跟踪计算和可视化一些关键项目参数的关键绩效指标（KPI），但我目前尚无法正确识别出交付的价值中的哪一部分是由于软件使用所致。
如果不在业务方面同时进行改进，则很少执行软件项目。实际上，通常的做法是使用信息技术（IT）项目作为调整和增强内部业务流程的动力。鉴于企业及其软件APP和系统之间有着极为紧密的联系，因此很难区分哪个企业（软件或相关的企业变更）导致了一定的财务，库存或其他类型的结果。在源于IT增强的效果与源于同时进行的业务增强的效果之间划清界线并不是一件容易的事。组织越大，这项工作就越困难。
不能保证软件成功，这是一个主观的问题。软件供应商成功的观点和定义可能与客户的综合看法有所不同。而且，同一家公司的不同部门或高管可能对成功有不同的定义，因此，对于项目的进展情况，会有不同的看法。这些意见可能包含各种观点，并且从绝对成功到彻底灾难都可能有所不同。尽管一个项目总体上可以被认为是成功的，但是总有一些地方可能没有得到适当的解决。那么，软件供应商是否注定要免费提供此服务，以确保项目各个方面的成功？
接下来的问题是如何正确，客观地衡量软件项目的成功。有很多标准可以考虑。这些标准因软件类型，项目范围，客户行业等而异。显然，决定制造公司的制造执行系统（MES）实施成功的因素将不同于影响大学中学生管理系统的实施的因素。。标准可以是有形的，例如库存水平和利润，也可以是无形的，例如改善的业务流程和学生的满意度。有形的标准通常更容易识别和计算，但是它们没有完整，系统地描述过程。因此，必须将一些无形的参数包括在成功的度量中，这也不是一件容易的事。
ERP软件实施和改进项目是软件供应商及其客户的合资企业。实际上，由于客户方的实体，此类项目通常涉及两个以上的参与者，即软件供应商，技术和实施合作伙伴以及顾问。显然，项目的总体成败不仅仅取决于软件供应商产品和服务的质量。同样，客户高层管理人员和员工的努力以及他们对项目的总体承诺也会影响整体的成功。没有这样的参与，任何商业软件项目都不可能成功。那么，问题是，如果项目同时取决于客户和软件供应商方面的多个因素，那么如何评估项目的整体成功？此外，
由于内部业务流程，管理方法，策略等方面的细节，即使两个组织非常相似且在同一行业中运营，也不会以相同的方式执行两个项目。因此，同一软件APP的用例可能相差很大。根据项目和组织本身的具体情况，可能需要对用于确定某个特定公司的软件系统成功价值的计算技术和方法进行不断修改。所有这些都是额外的成本和复杂性。
从财务管理和计划的角度来看，基于结果的模型对于软件供应商自身而言似乎是具有挑战性的，因为它极大地影响了整个常规软件生命周期。在这种情况下，当前基于工作量的财务策略（即基于软件开发的工时）显然不能很好地工作，因为基于结果的财务策略将需要创建一种新的方法来管理收入流。软件供应商将需要稳定且可预测的现金来源来进行软件开发，因为在基于客户的期望价值是基于结果的付款开始进入项目的最后阶段之前，该软件将需要全面运行。部分或全部交付，或在交付过程中的某个时刻。对于软件供应商来说，基于结果的最终定价和计费方案可能过于极端，因为其中许多公司甚至遭受了相对较软的基于订阅的收入转移。为了使方程式的所有方面在财务上保持稳定，并为基本的运营功能提供足够的资金流，某种混合策略可能很有意义。
最后，关于基于结果的薪酬计划还存在与时间相关的问题。从本质上讲，与软件相关的改进将被衡量和跟踪多长时间？当然，软件供应商可能会要求为整个软件实施和使用生命周期付款，而客户肯定会尽量减少开支，并按项目完成后的财务周期数（例如，按财务期间的数量）对此类付款设置了时间限制。这种基于结果的模型的另一方面涉及软件APP被视为新应用并为客户带来价值的时间有多长？使用一段时间后（以前的数字），测量和比较的依据是什么？如果该值随时间下降，该情况下仍将考虑按付款方式怎么办？最后，
人们不会为了购买软件而购买软件。他们之所以购买它，是因为他们铭记着某种商业成果–他们期望自己的活动带来积极的结果，其中一些是有形的，而另一些是无形的，有些很容易衡量，而另一些则不容易衡量。
使用基于结果的补偿可能是一个共同商定并接受的简化模型的问题，该模型带有一些可测量的参数，这些参数将被输入到最终发票计算中。对于某些软件APP或业务领域，这可能是一个相对简单的任务，例如库存或仓库管理软件的库存水平和库存类别周转时间。但是对于其他软件包，将需要一个更复杂甚至科学的模型来逼近数字，以准确反映现实生活中软件的成功。
这可能还需要公正的价值跟踪审计和计算机构，该机构应具有足够的技能和资格以提供适当的ROI和交付的软件价值计算。相对容易预测，这种顾问和审计师的作用的需求和重要性将逐渐增加。
无论如何，在找到上述概念性问题的解决方案之前，很难期望基于结果的薪酬实践会被广泛接受。但是，随着软件定价模型一定会继续发展，这个主题绝对值得关注和关注。
客服毛燕