我假设本文的读者已经初步了解什么是业务能力。如果不是这种情况，请先阅读这篇文章，了解您需要了解的业务能力。

许多组织从业务功能开始，因为有人想以某种方式使用它们。业务能力仍然是一个相对较新的概念，在概念理论方面几乎没有共识和公认的文献，特别是在定义、开发方法、用例和标准方面。

一些组织已尝试建立标准，但其标准的范围仅限于其组织的边界。结果是可用的指导很少，开发结果不同，成功案例很少，并且许多持怀疑态度的利益相关者。

为了支持努力发展业务能力的组织，我总结了我在过去几年中学到的最重要的 12 个经验教训：

1. 了解确切的用例

了解您的用例以确定您到底需要什么。业务能力可以支持许多不同的用例，例如业务和 IT 的一致性，跨合并的公司，或者用于未来预算和项目的战略规划。但是，不要以为所有人都可以使用一张业务能力图！事实上，不同用例所需的业务能力在数量、详细程度、层次数量以及应映射的信息和组件方面会有很大差异。

- 例如，应用程序环境的合理化方法可能只需要一些业务功能和映射信息。这些可能是应用程序、成本信息、底层技术的生命周期以及总体结果的业务满意度。

- 相反，需求管理方法可能需要大量详细的功能。对于这样的用例，可以将 20 多种业务能力映射到一个需求。目标是确定现有解决方案已经涵盖了其中的多少。然后，要映射的信息可能是可扩展性、相互依赖性等。

- 对于合并，您不需要任何详细的能力，因为您必须保持在各公司之间仍然具有可比性的水平。

2. 了解所有利益相关者

确定特定业务能力领域的所有相关利益相关者。如果您只与一个部门合作来确定特定领域的业务能力，则不要期望得到一个整体的业务能力图。以定价为例。它不仅由营销部门完成，而且还受到业务中更多领域的影响。以下领域也会对其产生影响：

• - 开发和生产成本，

• - 战略部的战略方面，

• - 最终必须考虑运输、进口、税收、临时和当地折扣等的当地销售商店。

同样，合同管理不仅在客户购买产品或服务时需要，而且与供应商、业务合作伙伴等也需要。您的组织最终可能会出现在不同的市场中，并且有不同的部门，这些部门都有点不同，使用不同的应用程序，并遵循不同的流程。但是，它们都使用相同的业务能力堆栈，最终代表您公司的业务能力图。

3. 理解和解释流程的差异

准备好与“流程人员”进行激烈的讨论。许多组织在为其组织开发详细而复杂的过程描述方面付出了巨大的努力。此外，流程描述通常比业务能力更成熟，因此总会有一些流程的坚定支持者不将业务能力视为可行的替代方案——一开始。强调业务能力优于流程的优势是业务能力成功的关键因素之一，这就是为什么我将在这里简要提及它们的原因：

首先，业务能力总是尽可能地被定义和命名，以便最大限度地从各种利益相关者那里获得理解。例如，它不得包括公司细节，例如技术或特定流程步骤。相反，两个不同公司之间的流程可能会有很大差异，即使它们的名称相同，实际内容也可能会大不相同。

其次，业务能力始终具有三个组成部分，即流程、人员和技术。作为多个组件的结果，使得业务能力随着时间的推移比其单个组件（例如流程）更稳定。

第三，业务能力的目的是提供公司的详尽视图，而不会重叠。它们是一个理论概念，被选择用于最小化两种不同能力之间的相互依赖关系。这使得单独分析它们成为可能。相比之下，流程反映了公司的实际行为，并且没有针对独立分析进行优化。

有了这些优势，还必须了解业务能力的巨大劣势，这是它们的理论性质。为了从能力中受益，组织需要为自己理解和定义概念——如果没有良好的现有指导方针，这是具有挑战性的。这将我们带到要考虑的第四课。

4. 一遍又一遍地传达这个概念

准备好向组织成员解释业务能力的概念 1000 次甚至更多次——在所有不同的层面上。我花了无数时间来介绍和讨论业务能力的概念。一个主要的收获是共享和能够重用内容应该具有非常高的优先级。

一般来说，准备好回答以下问题：为什么是能力？它对我们目前的情况有何帮助？为什么它比我们尝试的最后两个概念更好？我们为什么要使用它们？你会怎么做？你期待什么结果？行政级别的内容是什么？商业用途？为了我？有无穷无尽的问题。

五、严格指导发展

就您期望的业务能力的外观制定和传达非常清晰的指导。如果您已经搜索过其他组织的业务能力图，您会注意到，根据来源，结果可能会有很大差异。同样，这是由于缺少标准化，因为即使是新的 TOGAF 9.2 也在努力新的数字主题，例如仅在非常高的水平上的业务能力

（更新：TOGAF 试图通过其系列指南：业务能力——它确实提供了迄今为止最好的摘要之一，为业务能力主题提供了一些标准化）。

如果没有集中接受的指导，每个利益相关者将创建在细节、维度、考虑的组件和措辞方面不同的业务能力。所有这些方面都使得以后协调和比较结果变得具有挑战性。

根据我的经验，解释不够详细，不足以以人们独立得出相同结果的方式充分定义业务能力。相反，我更愿意提供一些小例子来说明业务能力图最终应该是什么样子。这样，细节级别、语法、组件、范围等属性变得清晰并立即被捕获。

6. 重用和利用现有输入

尽可能多地重用现有资源——内部和外部。第一个业务能力草案通常比理论所暗示的更接近现状。这一点都不错，因为它有助于组织慢慢地将其思维方式转变为基于能力的观点。了解业务能力图的第一个版本作为您的组织可以使用的起点。在下一步中，进一步整合，确定更多属于一起的能力。此外，确定映射中是否还有一个或另一个进程可以转换。

当涉及到内部资源时，请考虑战略文件、流程描述、组织结构图或应用程序的功能。当涉及到外部资源时，请考虑来自 APQC 或 FrameworX 的全球流程标准。但是，请注意，这些输入源都不是完美的，并且每个都有其优点和缺点。

如何开始对业务能力进行建模以及采取哪些输入是重要的一步。

7.意识到这个概念的缺点

来源的缺点之一是会偏向业务能力的组成部分之一：人员、流程或技术。偏见的类型将取决于您决定的来源。显然，如果您使用流程描述来开发第一个业务能力地图草案，那么结果将在某种程度上相似。将不再有泳道、负责或重复的详细流程步骤。然而，它将明确指出，例如人力资源是从雇佣到解雇的，或者研发具有从研究到专利生命周期管理的能力。

另一方面，如果您开始研究应用程序的功能并在逻辑上对它们进行集群，也会存在偏差。结果很可能存在技术偏差，因为您一个接一个地检查系统并考虑每个技术细节。

最后，如果您从组织结构图开始，您可能很快就会掌握您的第一个业务能力级别。这样的能力图将包括营销、生产和采购等能力。但是，如果您在地图中捕获了太多您不希望出现的组织细节（即人员组成部分），例如部门或区域组织，则存在很高的风险。

8. 着眼长远——不要期待短期结果

准备好无法快速交付结果或快速增加价值。业务能力长期成功的最大风险在于它们是非常理论化的。它们是一个需要时间来为组织增加价值的概念。作为企业架构的大多数领域，这些概念需要被组织内的许多人接受。因此，需要收集、分析数据，并且需要传达并再次接受其影响。

这一切都需要时间，如果关键利益相关者不支持这个想法，附加值可能会很快变为零。此外，高层管理人员必须明白，真正的利益将在长期内实现。短期内甚至可能根本没有正面影响！

因此，尽可能展示业务能力的附加值非常重要，尤其是在讨论该概念的价值时。

9. 寻找每一个试点和展示的机会

这对你来说意味着你必须对机会敏感。您的目标应该是通过试点或展示展示业务能力的价值。如果您不断寻找机会，就会有足够的机会。对那些对你的工作比其他人更感兴趣的利益相关者保持敏感。他们可能只是想法相似，并了解背后的真正潜力。留意早期项目，这些项目可能无法协调一部分景观，或者无法清楚地展示其战略前进方向。所有这些情况都可能为您提供一个很好的机会来展示您草拟的业务能力图的某些价值。

10. 管理期望

在您所做的一切中，不要期望获得 100% 准确的最终结果。企业架构师，尤其是业务架构师，知道他们的工作永远不会提供明确的答案。但是，企业可能不习惯这一点。业务架构师用于提供建议、指导或几个选项。相比之下，业务通常会查看业务案例的确定数量。

由于业务能力是一个企业架构概念，它们被概念化以针对广泛的问题提供建议。他们不是为了提供明确的答案，因为他们总是缺乏一些信息。缺乏信息可能是：

• - 更详细的业务能力级别，

• - 该概念未考虑的相互依赖关系，

• - 未捕获用于分析或在此期间发生变化的信息，

• - 以及来自未参与的领域或解决方案架构师的隐性知识。

11. 根据目标状态和运营模式选择合适的工具

获得工具支持以管理您将拥有的大量数据的更新。有不同的选项，从 Excel 列表、SharePoint 解决方案和各种专业的 EA 工具开始，从精益到高度复杂。最后，该工具也必须适合您的目的。但是，请注意，开发业务功能并将信息映射到它们，以及使用它们并显示结果是一项迭代活动，通常需要比最初预期更多的时间。

因此，从一开始就明智地思考：您需要管理多少数据集？应该有多少人有权查看和编辑数据？你期待什么样的视觉表现？您希望多久允许一次更新或新版本？数据需要什么安全级别？根据您对这些问题的回答，您可以初步了解您需要什么样的工具支持。

12.了解你需要的能力类型

在本文中，我谈到了业务能力。但是，许多人会混淆具有相似概念的人。例如，IT（或技术）能力更侧重于技术和解决方案，这些技术和解决方案可以跨越许多不同的业务能力，因此不能显示在同一个能力图中。例如，识别主数据中的拼写错误和重复数据条目并执行数据清理活动的能力。
另一种越来越流行并经常与业务能力混淆的能力是数字能力。数字能力地图的主要区别在于，它们的目标不是描述公司的所有方面，而是只关注数字化感兴趣的方面。因为它们的用例不同于业务能力的用例，所以它们通常更详细，并且只用一个级别进行描述。

如果您想了解业务能力的用例以及它们如何帮助组织转型，请阅读我的文章“业务能力转型组织的 5 大用例”。

本文：【业务架构】获得正确业务能力的 12 项必备措施

谢谢大家关注，转发，点赞和点在看。