【业务架构】业务能力转型组织的前 5 个用例

【业务架构】业务能力转型组织的前 5 个用例

应用业务功能的第一个也是最常见的用例是提供一个通用的、易于理解的和整体的组织视图，可用于将 IT 组件（例如应用程序、数据或技术）映射到它。了解应用层、数据层和技术层的现状和未来前景是企业架构管理的核心。业务能力可以是位于业务层中的链接元素，IT 可以将组件映射到该元素，并且该业务能够轻松理解。

在开始景观评估之前，清楚地了解您在收集数据后想要对数据做什么（以及您实际想要详细评估的内容）、您希望如何存储、共享它以及如何它应该随着时间的推移进行管理和更新。

此用例要求项目确定它们支持的业务能力，并在需求和项目组合流程开始之前集中收集结果。这还要求为整个组织制定业务能力图，并指示每个能力的战略相关性。这可以通过分解现有的业务策略并了解这些策略的实际含义来完成。

考虑这个例子：如果您的公司想要增加数字销售，您的电子商务能力可能具有很高的战略相关性。如果您的组织为此用例收集数据，它将能够基于基础项目显示业务能力的战略重要性——这取决于它们启用的功能。由此产生的分析可能有助于决定是否应该资助一个项目。

一个非常流行的用例是支持组织的需求管理流程。不幸的是，它也是最难实施的一种。为了在能力的帮助下为需求管理流程增加价值，您需要有一个详细的能力图，以及映射到它的环境的非常好的原样透明度。您的 As-Is 环境可能包括应用程序及其功能、系统和支持的技术，甚至是现成的解决方案包。

如果您收集所有这些信息，您可以将传入的需求（例如业务绘制的用户旅程）映射到业务能力，并确定您是否已经在地图中拥有该能力。如果它已经存在，您可以分析映射到它的 IT 组件。您还可以评估它们是否适合满足所描述的需求，或者您是否真的需要开发新的东西。此练习的结果很可能会减少一组功能，因此需要从头开始开发或购买的功能，同时您可以最大限度地重用现有 IT 组件，从而降低成本和所需资源，通过以下方式增强稳定性经过测试的组件，并缩短上市时间。

然而，这种方法通常停留在理论上，因为它不能应用于大型应用程序的领域，不能分离成它的单一功能。因此，他们不允许将其中的单个部分用于新的需求。此外，对现状的描述通常不够详细，无法采用这种方法，因此需要大量的前期工作。

一些组织有数千个应用程序。根据他们启用的业务能力应用业务能力对它们进行集群，这使得优化应用程序环境变得更加容易。目标是拥有这样一个细粒度的业务能力映射，不超过 5 到 10 个应用程序映射到一个业务能力。

这允许每个业务能力集群相互独立地分析应用程序。例如，这可以通过应用时间分析来完成，该分析评估每个应用程序的业务匹配度和 IT 匹配度，并将其分配到矩阵中。业务匹配可能是业务增值、业务关键性、用户数量、部门、使用应用程序的国家或分配收入的结果。 IT 契合度可能是底层技术支持、应用程序安全性、源代码可用性、响应时间、问题等的结果。您可以考虑许多指标，您应该评估您的组织可以评估哪些指标并且对你的目标很有帮助。

如果您将业务适合度放在 x 轴上，将 IT 适合度放在 y 轴上，您将创建以下象限：

左上角，容忍：这些应用程序的业务契合度较低，但它们的 IT 契合度很高。因此，您可以将它们保留在您的组织中，因为它们不会造成任何伤害。右上，投资：这些应用程序具有高度的业务适合度和高度的 IT 适合度。您应该进一步加强它们并进一步投资它们，因为它们是您应用程序的最佳类别。右下角，迁移：这些应用程序具有很高的业务适合度，但 IT 适合度较低。您可能需要它们的功能，但底层技术并不是最优的。您应该考虑更换提供商、迁移到新服务器或做其他事情来增强他们的 IT 匹配度。左下角，消除：这些应用程序的业务契合度和 IT 契合度都较低。您不需要这些应用程序，它们也没有合适的 IT 基础。对它们而言，最好的选择是消除它们以减少应用程序的数量并降低成本。

谢谢大家关注，转发，点赞。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。