企业的数字化终究应该是为了业务的发展和变革，而非IT本身。

大家在数字化项目中沟通需求的时候，有没有听IT顾问说过这些话：
——“这是个业务问题，不是个技术问题。”
——“技术上都有办法实现，但首先得把业务梳理清楚”

已经Q3了，大家开始考虑来年的数字化规划了吗？
目前还还缺失什么系统？而哪些功能已经重复建设了？系统之间都打通了吗？
有限的资源应该优先投入到哪里？业务上最急迫、影响最大的问题是什么？

说数字化要实现战略的落地执行，那么如何将战略转化为数字化的具体项目和行动？
说数字化必须要产生利益相关人能感知得到的价值，那么我们对价值的认知，如何才能和我们的相关人保持一致？

数字化需求千丝万缕、规划千头万绪、认知千差万别，落地千难万险。

有没有什么方法，能够让我们全面、系统地来梳理、统一对业务的理解，以及业务与IT之间的关联呢？

你可能听说过一种叫做企业架构的方法。

做企业架构最知名的方法论是TOGAF，大家对它更熟悉的叫法可能是——4A架构。

“业务架构”是4A架构中的一个A。TOGAF中，关于业务架构的大部分内容，其实又是参考的BIZBOK。今天我们就来看看BIZBOK这个专门针对业务架构的方法论。

什么是BIZBOK？什么是业务架构？

BIZBOK全称是“业务架构知识体系”（Business Architecture Body of Knowledge），由业务架构协会（Business Architecture Guild）编撰、维护。这就类似于项目管理有PMKOK、数据管理有DMBOK，它包含了梳理组织架构的全套方法论。

什么是“梳理组织架构”？

以我粗浅的理解，就是要将企业的业务、业务开展所处的环境抽象表达出来。

这样做有什么价值呢？

当企业遇到特定需求或问题，需要对企业业务进行分析时，就能根据一套较为系统的思路和较为全面的框架来开展。

业务架构将成为全集团、跨条线的通用业务语言，能帮助各方在沟通时保持在同一个频道上，大大降低沟通成本。

行动、举措或者说项目，在实施前用业务架构进行全面分析评估，能够保证行动与业务、战略方向一致，这样就能够帮助管理者做出更明智的决策，确定优先级，从而加速战略的落地。

BIZBOK把业务抽象成10样东西来分析，称之为业务架构的10个细分的域（Domain）。

其中内核的4个，相对稳定，分别是：

▪ 能力（Capability）

▪ 价值流（Value Stream）

▪ 组织（Orgainzation）

▪ 信息（Information）

外圈的6个，则相对易变，分别是：

▪ 战略（Strategy）

▪ 干系人（Stakeholder）

▪ 政策（Policy）

▪ 举措（Initiative）

▪ 产品（Product）

▪ 指标（Metric）

BIZBOK对于业务架构的定义就是：

业务架构用全面、多维度的业务视角来描述能力、端到端的价值交付、信息和组织结构，以及这些业务视角与战略、产品、政策、举措和干系人的关联关系。

Business architecture represents holistic, multidimensional business views of: capabilities, end-to-end value delivery, information and organizational structure; and the relationships among these business views and strategies, products, policies, initatives and stakeholders.

业务架构如何梳理？如何应用？

梳理业务架构，一般从核心的4个域开始，逐步扩展，梳理每个域的清单、域之间的相互关系等，形成业务架构知识库。

这些知识，可以通过各种蓝图来展示。蓝图可以理解将知识可视化的图表，从特定的角度来描述业务。

当我们有具体的业务场景时，就可以根据需要，选用相关域的知识和蓝图，来进行分析。

BIZBOK认为业务架构适用的业务场景不限于数字化转型，还包括建立客户为中心的用户体验、新产品/服务推广、全球出海、运营降本增效、企业拆分并购等等等等。

现在大多数方法论都引入了迭代的思想，BIZBOK也建议先梳理部分架构后，就尝试应用于真实业务场景，再用实践中的发现和积累来不断完善知识库和蓝图。

最重要域和蓝图？

在业务架构的10个域中，价值流和能力当属重中之重，而价值流-能力映射图则是最常用的蓝图之一。

如上图这个例子，先用价值流来描述创造价值的过程，再列出每个价值流阶段所需的能力。评估这些阶段和能力的满足和不足、强项和弱项情况，并用红绿灯的颜色标记出来。

于是，在这张蓝图上，价值创造的堵点、业务能力的缺陷一目了然，后续的改进重点和优先级也呼之欲出。

除了优化现有的价值流，当颠覆式创新重塑价值流时，我们也可以用这种方法发现新的能力需求，从而找到应变之策。

什么是价值流？

价值流（Value Stream）展示的是如何为干系人交付端到端价值的过程。它由价值流阶段（Value Stream Stage）组成，每个阶段都是一项增加价值的活动。

与波特的价值链不同，企业有多条价值流，每条价值流都是由某类干系人触发。在梳理价值流时，可以从梳理干系人出发，通常以面向客户的价值流为最高优先级。

每条价值流的命名都是动词+名词的形式；触发的干系人其实就是这个命名的主语。我们还要阐明每条价值流的价值主张，即为干系人带来的价值。

在描述价值流阶段时，命名同样是动词+名词的形式，需明确每个阶段的进入条件、退出条件、价值和涉及的干系人。

价值流初稿梳理出来后，还要通过实际业务场景分析、与其他域尝试交叉映射等方式，来不断验证和完善。

什么是能力？

业务能力（Business Capability）定义了业务做了些什么。

它只说明what，而不限制why、where、和how。

它是组成业务的基础构建块，一项能力可能被许多价值流阶段所需要。

它是聚焦业务、相对稳定的，与技术、自动化程度无关，例如被AI高度赋能的人力资源管理能力，依然是人力资源管理能力。

能力必须可以被清晰、无歧义地定义出来，每项能力都有特定的业务对象的，比如合同、资产等等，它的命名规则为业务对象+名词，比如合同管理、资产管理。

能力需要按颗粒度分层（Leveling），层级数目并没有强制限制，当然分得越细投入越大。

能力还要根据作用、关注能力的干系人被分为三类（Stratification）：

▪ 战略能力，指导战略方向设定；

▪ 核心能力，面向客户；

▪ 支持能力

下图是将一级能力进行分类的一个示例：

梳理能力的产出，是精简、完整、无冗余、聚焦于业务、适用于全集团的一套能力清单和地图。

同样我们可以通过热力图展现能力的具备情况、或者影响力大小、或者自动化程度等情况。

除了价值流和能力，BIZBOK给业务架构的其他几个域同样做了定义、提供了产出蓝图的模板。

并针对不同行业，总结了业务架构的参考模型。

尽管如此，各家公司在梳理业务架构时，还是会有不小的差异；例如培训管理，在有些公司是与人力管理并列的一级能力，在另一些公司则是人力管理下面的二级能力。

业务架构如何指导数字化需求提出？

做过数字化项目的同僚都很清楚，“需求提不好，吃亏不会少；需求拎不清，落地要人命”

作为业务方，我们在提出数字化需求时，可以借助企业架构，站在更广阔的视角来审视一番，回溯需求与战略目标的关系。

用业务架构的语言来描述我们的业务需求，也能够帮助我们更清晰地描述需求内容及范围。

业务架构如何指导IT建设？

当业务架构和IT架构对齐，才能让自动化系统、数据架构发挥出对业务战略、业务能力、干系人的价值。

业务架构不但能为数字化建设输入了业务角度的优先级，业务架构的一些域更是可以直接关联到IT架构，从而推导出IT的行动的优先级和路线图。

▪ IT架构中的数据架构，基于业务架构中的信息地图设计和实现；

▪ IT架构中的应用架构与能力地图对应，IT应用将业务能力自动化。

▪ 业务流程自动化、案例管理自动化、用户交互自动化等方面的设计，应当参考价值流。

将业务架构与IT架构对齐后，IT的投资是业务驱动的，能够更清晰定义ROI。

数字化建设基于集团内统一的业务能力，而不再限定于特定机构或者特定产品/服务的需求，能够避免重复建设、保证系统间的协调。

（以上内容摘录自网络，如有侵权请联系删除）

企业的数字化终究应该是为了业务的发展和变革，而非IT本身。

大家在数字化项目中沟通需求的时候，有没有听IT顾问说过这些话：
——“这是个业务问题，不是个技术问题。”
——“技术上都有办法实现，但首先得把业务梳理清楚”

已经Q3了，大家开始考虑来年的数字化规划了吗？
目前还还缺失什么系统？而哪些功能已经重复建设了？系统之间都打通了吗？
有限的资源应该优先投入到哪里？业务上最急迫、影响最大的问题是什么？

说数字化要实现战略的落地执行，那么如何将战略转化为数字化的具体项目和行动？
说数字化必须要产生利益相关人能感知得到的价值，那么我们对价值的认知，如何才能和我们的相关人保持一致？

数字化需求千丝万缕、规划千头万绪、认知千差万别，落地千难万险。

有没有什么方法，能够让我们全面、系统地来梳理、统一对业务的理解，以及业务与IT之间的关联呢？

你可能听说过一种叫做企业架构的方法。

做企业架构最知名的方法论是TOGAF，大家对它更熟悉的叫法可能是——4A架构。

“业务架构”是4A架构中的一个A。TOGAF中，关于业务架构的大部分内容，其实又是参考的BIZBOK。今天我们就来看看BIZBOK这个专门针对业务架构的方法论。

什么是BIZBOK？什么是业务架构？

BIZBOK全称是“业务架构知识体系”（Business Architecture Body of Knowledge），由业务架构协会（Business Architecture Guild）编撰、维护。这就类似于项目管理有PMKOK、数据管理有DMBOK，它包含了梳理组织架构的全套方法论。

什么是“梳理组织架构”？

以我粗浅的理解，就是要将企业的业务、业务开展所处的环境抽象表达出来。

这样做有什么价值呢？

当企业遇到特定需求或问题，需要对企业业务进行分析时，就能根据一套较为系统的思路和较为全面的框架来开展。

业务架构将成为全集团、跨条线的通用业务语言，能帮助各方在沟通时保持在同一个频道上，大大降低沟通成本。

行动、举措或者说项目，在实施前用业务架构进行全面分析评估，能够保证行动与业务、战略方向一致，这样就能够帮助管理者做出更明智的决策，确定优先级，从而加速战略的落地。

BIZBOK把业务抽象成10样东西来分析，称之为业务架构的10个细分的域（Domain）。

其中内核的4个，相对稳定，分别是：

▪ 能力（Capability）

▪ 价值流（Value Stream）

▪ 组织（Orgainzation）

▪ 信息（Information）

外圈的6个，则相对易变，分别是：

▪ 战略（Strategy）

▪ 干系人（Stakeholder）

▪ 政策（Policy）

▪ 举措（Initiative）

▪ 产品（Product）

▪ 指标（Metric）

BIZBOK对于业务架构的定义就是：

业务架构用全面、多维度的业务视角来描述能力、端到端的价值交付、信息和组织结构，以及这些业务视角与战略、产品、政策、举措和干系人的关联关系。

Business architecture represents holistic, multidimensional business views of: capabilities, end-to-end value delivery, information and organizational structure; and the relationships among these business views and strategies, products, policies, initatives and stakeholders.

业务架构如何梳理？如何应用？

梳理业务架构，一般从核心的4个域开始，逐步扩展，梳理每个域的清单、域之间的相互关系等，形成业务架构知识库。

这些知识，可以通过各种蓝图来展示。蓝图可以理解将知识可视化的图表，从特定的角度来描述业务。

当我们有具体的业务场景时，就可以根据需要，选用相关域的知识和蓝图，来进行分析。

BIZBOK认为业务架构适用的业务场景不限于数字化转型，还包括建立客户为中心的用户体验、新产品/服务推广、全球出海、运营降本增效、企业拆分并购等等等等。

现在大多数方法论都引入了迭代的思想，BIZBOK也建议先梳理部分架构后，就尝试应用于真实业务场景，再用实践中的发现和积累来不断完善知识库和蓝图。

最重要域和蓝图？

在业务架构的10个域中，价值流和能力当属重中之重，而价值流-能力映射图则是最常用的蓝图之一。

如上图这个例子，先用价值流来描述创造价值的过程，再列出每个价值流阶段所需的能力。评估这些阶段和能力的满足和不足、强项和弱项情况，并用红绿灯的颜色标记出来。

于是，在这张蓝图上，价值创造的堵点、业务能力的缺陷一目了然，后续的改进重点和优先级也呼之欲出。

除了优化现有的价值流，当颠覆式创新重塑价值流时，我们也可以用这种方法发现新的能力需求，从而找到应变之策。

什么是价值流？

价值流（Value Stream）展示的是如何为干系人交付端到端价值的过程。它由价值流阶段（Value Stream Stage）组成，每个阶段都是一项增加价值的活动。

与波特的价值链不同，企业有多条价值流，每条价值流都是由某类干系人触发。在梳理价值流时，可以从梳理干系人出发，通常以面向客户的价值流为最高优先级。

每条价值流的命名都是动词+名词的形式；触发的干系人其实就是这个命名的主语。我们还要阐明每条价值流的价值主张，即为干系人带来的价值。

在描述价值流阶段时，命名同样是动词+名词的形式，需明确每个阶段的进入条件、退出条件、价值和涉及的干系人。

价值流初稿梳理出来后，还要通过实际业务场景分析、与其他域尝试交叉映射等方式，来不断验证和完善。

什么是能力？

业务能力（Business Capability）定义了业务做了些什么。

它只说明what，而不限制why、where、和how。

它是组成业务的基础构建块，一项能力可能被许多价值流阶段所需要。

它是聚焦业务、相对稳定的，与技术、自动化程度无关，例如被AI高度赋能的人力资源管理能力，依然是人力资源管理能力。

能力必须可以被清晰、无歧义地定义出来，每项能力都有特定的业务对象的，比如合同、资产等等，它的命名规则为业务对象+名词，比如合同管理、资产管理。

能力需要按颗粒度分层（Leveling），层级数目并没有强制限制，当然分得越细投入越大。

能力还要根据作用、关注能力的干系人被分为三类（Stratification）：

▪ 战略能力，指导战略方向设定；

▪ 核心能力，面向客户；

▪ 支持能力

下图是将一级能力进行分类的一个示例：

梳理能力的产出，是精简、完整、无冗余、聚焦于业务、适用于全集团的一套能力清单和地图。

同样我们可以通过热力图展现能力的具备情况、或者影响力大小、或者自动化程度等情况。

除了价值流和能力，BIZBOK给业务架构的其他几个域同样做了定义、提供了产出蓝图的模板。

并针对不同行业，总结了业务架构的参考模型。

尽管如此，各家公司在梳理业务架构时，还是会有不小的差异；例如培训管理，在有些公司是与人力管理并列的一级能力，在另一些公司则是人力管理下面的二级能力。

业务架构如何指导数字化需求提出？

做过数字化项目的同僚都很清楚，“需求提不好，吃亏不会少；需求拎不清，落地要人命”

作为业务方，我们在提出数字化需求时，可以借助企业架构，站在更广阔的视角来审视一番，回溯需求与战略目标的关系。

用业务架构的语言来描述我们的业务需求，也能够帮助我们更清晰地描述需求内容及范围。

业务架构如何指导IT建设？

当业务架构和IT架构对齐，才能让自动化系统、数据架构发挥出对业务战略、业务能力、干系人的价值。

业务架构不但能为数字化建设输入了业务角度的优先级，业务架构的一些域更是可以直接关联到IT架构，从而推导出IT的行动的优先级和路线图。

▪ IT架构中的数据架构，基于业务架构中的信息地图设计和实现；

▪ IT架构中的应用架构与能力地图对应，IT应用将业务能力自动化。

▪ 业务流程自动化、案例管理自动化、用户交互自动化等方面的设计，应当参考价值流。

将业务架构与IT架构对齐后，IT的投资是业务驱动的，能够更清晰定义ROI。

数字化建设基于集团内统一的业务能力，而不再限定于特定机构或者特定产品/服务的需求，能够避免重复建设、保证系统间的协调。

（以上内容摘录自网络，如有侵权请联系删除）