BFM(eTOM)导读

Business Process Framework（BPF）是TMF论坛提出的一个业务流程模型。90年代中期提出的时候也被称为TOM模型（Telecom Operations Map）。但是TOM模型缺少企业管理的内容，另外也缺少对互联网和电子商务催生的新业务支持，在2001年TMF提出了eTOM模型（enhanced TOM）来完善该模型。
到了2009年左右，由于行业内ICT的融合趋势，以及数字化媒体产业以及数字化服务的发展，为了适用行业发展需要，TMF修改了eTOM模型，去掉了电信化的标签，也就是现在的BFM模型。

概述

翻译一段来自TMF的文档描述：

BPF定义了一种企业业务导向的视图。这个视图对于企业中需要通过业务术语来考察企业的使用者会有帮助，例如计划人员，管理人员和战略制定人员，通过视图使用者不需要立即关心这些业务内部是如何组织和操作的。因此，BPF突出了重点问题，例如：流程结构，流程组件，流程交互以及相关联的业务角色和责任。在定义这些视图的时候，BPF还提供了设置系统解决方案需求的基础性建议，例如技术架构，技术选择和执行路径，但这些建议对于这些需求而言是中立的。
因而，BPF可以被看成有两张脸：一张脸是面向业务，客户，产品之类，另外一张是面向支撑业务的解决方案，系统和实现的。
BPF是一个框架，不是一个实现的规格书。用户在使用BPF的时候，通常需要根据自己的业务需求来定制化和扩展BPF的模型，但也需要遵循那些已经被业界公认或既成事实的关键公共参考。

BPF如何工作

1. 定义业务域，BFM定义了8个业务域：

1.1 市场销售域（The Market & Sales domain）
1.2 客户域（The Customer domain）
1.3 产品域（The Product domain）
1.4 服务域（The Service Domain）
1.5 资源域（The Resource Domain）
1.6 业务伙伴域（The Business Partner domain）
1.7 企业域（The Enterprise domain）
1.8 公共域（The Common domain）

2. 过程分解

流程分解是一种结构性的分析方法，流程分解从高层的企业级流程视图开始，通过树状的继承结构逐步分解每一个流程。如下图1.1所示。BPF的框架从Level 0（企业级，也有称为概念视图）开始，Level 1如图1.2所示，Level 1也被成为CxO视图。

图1.1 流程分解

总体而言，BFM有两个主要的过程域：

• 战略准备（Strategy to Readiness）：包括计划，能力交付和生命周期管理。以前版本也被成为SIP（Strategy、 Infrastructure and Product）。
• 运营（Operations）：包括了核心的运营管理过程，这个也被看作是BPF的核心部分。

图1.2 BFM(eTOM)

图1.2包括七个垂直的过程组（Context Verticals），关注的焦点是在服务（Fulfillment）, 保障（Assurance）和Billing & Revenue Management （计费），这三个组也被简称为“FAB”。
运营准备和支持（Operations Readiness & Support (OR&S)）同FAB组有所区分是为了强调OR&S对FAB的支撑使能和自动化。最初OR&S从FAB中分离是为了反应“前台”业务的实时性和“后台”业务的准实时或离线支持的区别，这种区分并不适用于所有的组织（有些组织中可以合入FAB）。举例而言，对于客户的在线和及时支持功能，OR&S需要运行环境已经Ready， 这样FAB的过程才可以顺利工作。
战略准备过程域（Strategy to Readiness (S2R)），包括三个垂直过程组：战略管理（Strategy Management） ，能力交付（Capability Delivery） 和 生命周期管理（Lifecycle Management）。同运营管理不同的是，这些过程组不直接服务于客户，但是随着自动化程度的增强，业务演进的迭代正在加速，以前的一些需要长时间准备的过程正在接近实时达成甚至同步。

BFM的框架还提供了水平的功能组的视图，水平的功能过程组（现在更恰当说法应该是说域（Domain））从功能角度观察模型，关心功能过程组的人是对某一功能的能力建设负责的人，包括关心某一功能的结果的人，及为某一功能提供IT应用的人，体现了CTO的观点。企业内的工作组划分一般也与职能一致。

相比而言关心垂直过程组的人是对端到端的过程的运营、更改和管理及过程输出结果负责和关心的人，而不关心该过程所涉及的工作组及配合关系。这些过程跨越了组织之间的界限，因此端到端的性能是高层管理者特别是COO/CEO关心的问题。垂直过程跨越了组织之间的界限纵向的端到端过程覆盖了横向的多个单元组。

BFM继续分解到Level 2级别，随着级别增加，更多的细节会被呈现出来。看图1.3，Level 2的一个过程会归属于一个水平域并且被会被定位在一个垂直域的位置。某些情况下，一个Level 2的过程会被拉伸跨越多个垂直域(例如“Resource Data Collection and Distribution”)。这是因为这个过程会影响多个垂直过程域。以上面为例，从网元采集的数据被计费（Billing & Revenue Management）使用同时也被用于保障域（Assurance）的支持故障处理（fault handling）或性能评估(performance assessment)。

图1.3 : Level 2 运营流程(OPS)

继续分解就得到Level 3的视图，举一个例子：

图1.4：Level 3 运营(OPS) 过程

战略准备域同运营域类似，可以参考TMF的文档，不再赘述。

3. 过程流程

3.1 概述

过程分解提供了一种对过程定义和内容的基本洞察。如果要进一步理解这些过程是如何运作的，可以通过使用业务流程来检查这些过程是如何支持企业内部更大范围，端到端的流程。
图1.5的过程流程为例，这个例子描述了客户订单的部分处理过程，在这个例子中可以发现几个在BPF的Level 2的OPS的过程，图中加了标签的连线显示了在运营过程中这些过程的实际转移。

图1.5：过程流程 (局部的例子)

过程流程的方法总结有以下一些基本特征：

• 分析了一个典型或特别的场景
• 提供了对过程行为和相互关系的洞察
• 选择在一个合适的过程详细级别上对流程的建模
• 可以使用过程分解（反之亦然）去增强或提炼细节
• 方法的目标是提供仅仅一个过程流程的例子，每种场景中只有部分可能的交互会被描述
• 因为流程是基于特定场景的，所以方法仅仅提供了过程行为的部分视图
• 方法展现了过程动态的视角

3.2 过程交付流程图

图1.6展示了一个更完整一点的例子，场景基于服务过程组(Fulfillment vertical )中的订单受理流程（Production Order to Acceptance）。这里的视图展示了一些在场景中出现的交互过程，经过也很有用，但是却没有给出在这个层级上的行为视图。

图1.6：交互图（Production Order to Acceptance）

图1.7的过程交付图弥补了上面提到的缺点。这个图直接采用了流程分析和建模的工具，使用层级2的过程组件（如果需要也可以采用其他层级的元素）。每一个过程只出现一次，因此过程的交互顺序并不会明确在图中标识出来(在后面的过程动态图中会有)。图中还有一个重要的元素“泳道”，这个图中的泳道展现了BPF运营域的四个水平过程组，因此可以发现在该泳道中的过程元素是来源于水平功能过程组的组件。另外需要注意的是过程间的交付是事件而不是信息，因而这个图可以认为展现的是控制的转移。

图1.7：过程交互流程图（Production Order to Acceptance）

3.3 过程动态流程图

下面一个图1.8展现了另外一个流程图，保障域的故障单处理流程。这个流程从创建一个故障单开始，然后进入服务问题管理过程，资源问题管理过程和参与方功能域的过程（因为流程可能需要交付某些服务给客户）。

图1.8: 过程交互流程图（Trouble Ticket-to-Solution (Assurance)）

尽管交互过程在图上都有标签来标识，但是交互的顺序和依赖关系在图中没有明确标识。因此，我们需要有有另外一种“过程动态流程”图，见下图1.9。

图1.9: 过程动态流程图（Trouble Ticket-to-Solution (Assurance)）

在这个图上，每一个过程可能出现多次，按照流程中的顺序出现在每个步骤中。同图1.8相比，这个图显示了等量的信息，但是从技术角度看更加完整，为进一步的设计提供了更好的基础。

通过这种方式来开发过程流程图对洞察业务很有价值，而且也为校验过程分解提供了更多细节，对辨识应用的业务优先级也有用处。

总结

TMF是电信运营与管理领域的国际性权威组织，是BSS/OSS领域最重要的标准组织之一。BFM(eTOM)模型为整个行业提供了一个基础性的框架，成为事实上的行业标准和共同语言。

参考TMF相关文档