王靖飞的博客复制网址 | 设为主页| 加入收藏

　　什么是商业架构？

　　作者：PaulHarmon编译：陈晓燕AMT咨询

　　近期，商业架构这个术语经常被提起。我最近参加的两个主要业务流程管理会议上，就有几位演讲人提到了商业架构。同时，一些期刊也刊发了关于商业模型的文章。业务流程管理趋势也在持续地谈论业务流程体系。我研读了一些文章，希望能为这个领域带来些新的理解。

　　企业架构

　　在上世纪90年代，我为切割机联盟写过一篇名为《企业架构》的文章，这个定义在当时还比较新。因为一些软件、企业架构的书，还有JohnZachmann的论文以及由IBM、Oracle等供应商提出的软件架构模型，这个定义才渐渐为人知晓。当时有一个争论持续到今天：企业架构这个术语是否应该包括企业内部所有对架构所作出的努力，还是仅仅指IT架构。IT架构通常包括更具体的应用软件、数据库和技术（或者说基础设施）架构。

　　几乎所有致力于企业架构的人都会同意这样一个说法，就是企业架构这个术语应该包含对商业策略、标准还有组织流程的叙述。大多数人会进一步认为，一个能说明企业目标的具体架构应该一直存在，而且IT架构应该支持此商业架构。不过，细节决定成败。

　　你会发现大部分的企业架构会议的参与者都是IT从业者，他们的讨论都以各种IT架构为中心，企业架构师可能会认为，商业架构只是一个需要能够让业务活动实现自动化的任务而已。因此，很多企业架构师认为商业架构应该由他们而不是由业务经理来开发。

　　这种观点将导致我们得向业务经理详细叙述一个企业应该怎样完成各种任务。我们之中很多人会用商业流程架构作为一个术语，来描述如何定义一项业务以及业务目标如何实现。我们不一定能确定如何给架构命名，但是我们深信这样的架构必须由业务经理来开发。

　　为业务经理定义架构而努力

　　第一个既是为业务经理也是由业务经理本身所做的定义架构的努力，是由MichaelPorter提出的。在他1985年的《竞争优势》一书中，Porter用价值链这个词来描述企业里所有的活动可以怎样被聚合在一起成为能为顾客提供价值的流程。可以看出，Porter更关心一个企业如何安排它的各种活动以及如何盈利。所以，他的模型给出的是对高层次流程的综述。而且他的模型说明，如果你将这些业务活动的成本从你取自顾客的费用中减掉，你就会得到企业的利润。同样，尽管Porter没有为顾客价值主张给出一个单独的模型，他仍然认为谁在价值链里负责安排业务活动就应由谁来实施策略。所以，不同的人有不同的安排流程的方法，从而生产出针对特定市场的产品。

　　哈默（MichaelHammer）和达文波特（TomDavenport）鼓励大型企业将定义业务流程架构和关键流程作为流程重组的第一步。这些努力让相当多的人意识到价值链和业务流程的重要性。

　　Rummler-Brache组织地图

　　GearyRummler和AlanBrache推动了第二个阶段的探索。他们在开展任何一个流程问题分析的时候都会先运用组织地图，然后再详细地叙述构成一个或者多个价值链的业务流程。在这个组织地图里，你可以看到一个只有一条价值链的企业。Rummler通常先用三个通用的核心流程来描述一条价值链，然后将它们扩展以迎合具体的客户需求。和Porter的价值链模型一样，Rummler的注意力不仅仅是放在流程上，他将有关资金来源、竞争对手、客户、市场和分红的信息也包含了进去。这个模型是为了能在一页纸上向业务主管展示他们企业的概况而设计的，它和实施价值链所需要的IT资源没有太大关系。当今大多数流程从业者都会将Rummler-Brache地图当作业务流程架构或者至少是一个业务模型。

　　业务流程架构这个词本身就一直很令人困惑。有些人随意地用这个词来形容价值链里的主要流程。另外一些人则用它来描述更多东西，比如企业目标、价值主张、流程等级，以及经理们用来监控和管理流程效率和有效性的一系列标准。

　　业务流程框架的角色

　　在上世纪90年代末期和本世纪初，一些主要的业务流程框架的出现令业务流程架构取得了巨大的进步（很多人也称这些框架为运营参考模型或框架）。供应链协会的SCOR，TeleManagement论坛的eTOM，以及价值链组织的VCG框架都是通用业务流程框架的好例子。

　　VCG框架将业务流程架构定义为三个级别。同时，与SCOR和eTOM一样，它将第一级和第二级流程与战略决策结合起来并提供评估在各个级别的每一个流程的标准。所以，当供应链经理建立起一套完整的SCOR文档后，他不但获得了流程地图，而且也获得了适用于每个流程层次的评估标准的详细信息，以及展示具体的评估标准是怎样与集团战略目标相关联的信息的表格。因此，VRM、SCOR、eTOM这些框架似乎可以支持对业务流程架构的广义定义。而且对于一些人来说，这些框架提供了一个让业务主管得以实施业务流程架构的捷径。

　　同样重要地，这些运营参考框架有助于业务经理决策。如果业务经理使用框架图以及相关的评估标准和参考点，那么他们就能鉴别出那些亟待改进的流程，并且估算出不同干预措施的价值。本质上，这些业务流程框架让企业能更轻松地将有效的业务流程概念化。

　　业务流程架构和成熟度

　　所有阅读BPTrends的人都知道，我们通常会认为企业倾向于遵循一套通用的流程开发步骤，而这套步骤从大体上来说和SEI的CMMI成熟度评估里的成熟度级别相类似。大部分企业都达到了CMMI第二级，并且专注于定义和重新设计部门级别的流程。仅当从第二级转向第三级和第四级的时候，企业会开始关注与业务流程架构相关的事情。在过去的十年里，企业在成熟度曲线中的上升受到重视，像SCOR、eTOM、VCG这些能向人们展示真正的业务流程架构是怎样的框架也起了推波助澜的作用。

　　业务架构的想法

　　现在，关注业务架构的讨论越来越多。例如，OpenGroup对架构框架（TOGAF）进行了定义，并且将框架中9的组成部分中的一部分留给了业务架构。TOGAF文档中提到，“业务架构方面的知识是任何其他领域里（数据、应用、技术）进行架构相关工作的前提，而且也是架构相关的活动中的第一步，更是其他企业流程（企业计划、战略业务计划、业务流程重组等）里必须考虑的因素”。简单地说，TOGAF起始于IT并且认为其他所有架构都应该支持作为重点的业务架构。然而，就像太多的IT方面的概念一样，TOGAF对业务架构的讨论极其迅速地退化为对任务层面的UML业务类别图的讨论。TOGAF文档显示出作者们根本不知道业务主管的需求，更别说文档的实际意义了。

　　美国政府的FEAF

　　美国政府的联邦企业架构框架（FEAF）是由许多美国政府机构的CIO们一起开发的，为的是让这些政府机构能够符合联邦政府对它们必须拥有企业架构的硬性规定。该FEAF版本中，业务架构处于其他架构（数据架构、应用架构、技术架构）之上，是它们的顶层。然而，FEAF实际上是一个IT方面的努力，而且很多人也认为对于众多政府机构里IT资源的定义和分类，FEAF给予了过多的注意力。

　　最近，美国CIO委员会一直在寻求将它们的业务架构努力详细化的途径，让我们拭目以待。

　　OMG的业务架构SIG

　　业务架构特殊利益组（BASIG）也在为定义业务架构这个术语而努力。BASIG大约两年前在OMG成立。（用OMG的话来说，一个特殊利益组是一个讨论某一特定话题的小组，但这小组并不生成标准。通常，特殊利益组如果能够产生足够的关注，OMG会将其变为一个能提出具体标准的特别工作组。关于BASIG的信息可以在http://bawg.omg.org找到。）到目前为止，这个组已经完成了几份业务架构的白皮书，一份最近的白皮书是这样定义业务架构的：“业务架构向企业提供一个方法，可以将以往分散并且关联度很差的企业能力、企业结构、流程、语义、客户视图和企业的其他方面组织成为一个可随时调用的知识库。各种业务因素和挑战的通用视图可以通过业务架构来提取，这样管理层就能够快速地确定问题的根本原因，并且目标明确地讨论和解决这些问题。”

　　BASIG同时还在发展一个平衡记分卡元模型用来定义平衡记分卡的语义，以及保证未来的软件提供商能够设计出可以有效传递记分卡信息的工具。

　　在OMGBASIG白皮书中，有两点吸引了我：

　　1.Ulrich和McWhorter非常热衷于将业务架构和IT与企业架构分离开来，他们希望业务架构能专注于业务经理们的需求。

　　2.同时，他们似乎无法摆脱其IT背景。与其说他们专注于业务人员需要的工具，倒不如说他们选择了专注于业务架构中的IT基础设施。事实上，他们所建立的是业务架构也许能用到的相关知识模型。

　　在图1中，最顶端部分是我们的目标观众——尝试理解企业是如何运行的业务经理。我们需要考虑，当业务经理需要帮助的时候，他会想些什么、会从哪里寻求答案？大部分业务经理倾向于选择书面的文字文档或者数据表。对企业的业务模型、价值主张来说，一个好的说明长度通常从一段到一页不等。对于很多自己创业的经理，一个业务模型仅仅是一页数据表。

　　图1：业务架构空间

　　在图1的底部，画出了OMGBASIG所作的定义语义模型以及业务架构元素或者远景。很明显，这些是非常重要的。如果大型企业准备搜集业务方面的数据，他们需要一个始终如一的方法来描述这些数据，而且需要把这些数据储存在数据库中并从逻辑上将各种数据元素关联起来。很显然，这些都不是业务主管们所关心的。所以，那些负责IT建模而又对业务架构感兴趣的人才会做这些事情。然而，在大多数情况下，这些人的做法无法得到高层主管的注意。这实际上是从IT的角度来考虑业务问题。

　　那些曾经专注于业务流程架构的人，从Porter和Rummler开始，已经定义了什么样的文档是需要业务总管来做决定的，图1的架构展示了与这个相关的方法论和业务文档。一个流程从业者会假定这些文档应该包含一些高层次的对工作应如何完成的叙述。BPTrendsAssociates有一个企业方法论，此方法论可以教经理如何创造这些文档。在他们的战略地图里，Kaplan和Norton给出了另外一种方法论和给结论建立文档的方法。在《建立业务模型》一书中则描述了另一种途径以及略有不同的文档。以上双方都专注于创造出业务主管们在决策时能用得上的简单文档。对于所有的这一切，关键的一点是那些创造方法论和文档的人都专注于业务而不是IT。他们的方法从上往下，而不是从下往上。换句话说，业务架构可以通过两种途径建成：

　　1.通过专注于语义、元模型以及工具。

　　2.通过专注于业务人员真正用到的方法论和文档。

　　新的商业模式

　　为了说明图1中间的一层，我们可以想一下发生在已经成形的商业模式概念中的事情。哈默（MichaelHammer）总是专注于一个企业的商业模式。他坚称一个企业只能通过改变他做事的方式来获得突破。虽然他并不反对持续改进，但是他认为假如企业能够创新以及改变创造和投送价值给客户的方式，那么企业就能从流程项目里获得更多的回报。

　　从这个角度出发，我们应该问：商业模式究竟是什么？简单地说，商业模式是一个一到三个自然段长的对企业如何盈利的叙述。简而言之，你会说：

　　1.这个企业会生产A。

　　2.我们会把A以每单位B的价钱卖给N个客户。

　　3.我们能够以每单位C的成本生产以及交付这产品/服务。

　　4.如果我们卖出D个单位拿我们就能盈利E。

　　以上任何的假设都可以被质问，但一个企业一旦确定了商业模式，这些假设都应该被投放入市场中接受检验。很明显，创新包括了改变一个或多个假设——改变产品的本质，改变生产程序，改变目标客户等。所以很多当前的创新都专注于商业模式的本质。

　　对商业模式的传统看法已经从上世纪90年代开始快速转变。例如，在2008年《哈佛商业评论》中有一篇由MarkW.Johnson、ClaytonM._christensen和HennigKagermann合写的文章，题目为《重新发明你的商业模式》，这篇文章是一个商业模式获得新关注的很好的例子。实际上，文章的作者已然拓展了传统的商业模式的定义以包含更多的新事物，就像图2里所展示的那样。在文章中，商业模式被定义为“四个一旦被采用就能创造价值的相互关联的元素”。

　　图2：商业模型的元素

　　Johnson、Christensen和Kagermann，以及之后的一些文章，都已经扩展了商业模式的定义以包括流程和主要资源。尽管我们并不知道，假如这些作者真的为某一家企业工作的时候会如何定义流程，但是我们清楚他们很有可能是在说一个能定义流程名字、功能和关系的流程架构，但会止步于流程图和详细的流程分析。换句话说，他们很有可能在说一些像SCOR、VRM、eTOM那样的框架。

　　另外两位做着同样事情的作者AlexanderOsterwalder和YvesPigneur，写了一本相当棒的书，名为《创建商业模式》（Wiley，2010）。Osterwalder和Pigneur为创建商业模式创造了一个方法论并且作出了改进。他们用工作表来作为主要的图表，以引导读者理解他们的方法论，见图3。

　　图3：一个商业模式画布

　　在这个工作表中，作者将“市场”这个词扩展以包含“客户细分”和“渠道”这两个概念，而且他们给出了一个可以记录财务信息的工作表，从商业伙伴到流程到产品/服务再到客户的流动也在此工作表上。实际上，就像Porter、Rummler还有Kaplan和Norton所做的一样，Osterwalder和Pigneur从顶端开始，并且问他们自己业务经理需要什么样的工具来更好地管理企业。他们通过扩展商业模式的含义以及给出搜集能支持业务经理决策的数据的方法论来达成这个目的。

　　业务流程传统

　　老读者们应该会记得，我认为现代的流程管理是从三个不同的传统中发展而来的，而这三个传统当时正在逐渐合并为业务流程管理BPM。其中，一个传统主要专注于业务管理或者组织成效，另一个专注于质量，还有一个专注于IT的运用。如果三个传统已经完全融合那就太棒了，但实际上它们仍然很独立，而且每个都有自己的一套与众不同的术语和模型。业务流程架构的概念，至少从Rummler和Hammer的版本来看，是一个非常商业的概念。运营参考框架也同样是商业概念。相类似的，对商业模式的定义进行扩展以包含流程也是一个商业概念，并且和前面所提到的一样，都是从上往下的。

　　企业架构的概念，以及越来越多的对业务架构的重视，至少从TOGAFBAWG和OMGBASIG的定义来说是由有着IT背景的人所驱动的，而且这些人的方法往往是从下往上。我仍没有见到过任何类似于质量范畴的努力，即使6Sigma团体已经实行精益6Sigma，而且精益6Sigma的从业者已经越来越强调价值流建模。值得肯定的是，属于质量范畴的CMMI已经通过强调第三和第四级的企业需要有一个业务流程架构来引导决策而对企业架构作出了相当多的贡献。

　　换个说法，企业架构已经过于狭隘地专注于对IT资源进行定义和分类，而没有太在乎定义管理者的业务需求。有这样一个正在显现的广泛理解，就是业务人员需要他们自己的架构或者模型，他们自己的方式来描述业务目标和指标。而且，似乎所有人都同意，一个对业务流程架构、关键流程以及相关的绩效评定标准的高层次叙述必须成为这种理解的一部分。

　　然而，关键一点似乎在于这种努力的中心点是否应由业务人员来从上往下完成，或者为他们而创建，还是由IT人员来从下往上完成。

　　业务主管对从下往上的做法很抗拒。在我的经验里，他们很有可能不会叫任何他们用的模型为架构。对于大多数的主管，一个扩展的商业模式或者一个企业地图往往是一个更令他们舒服的概念。在任何情况下，主管们都不需要很多的细节，而且他们会坚持使用一些容易运用和更改的高层次文档或者模型。

　　当前，很多人用很多不同的方法来发展一些概念以及相关模型，以期业务主管能够运用它们来更好地了解企业以及做出决策。对于能代表业务人员所关心的事物的众多模型，它们并没有使用一致术语。但是，很多人都对此非常感兴趣，而且很多从业者都正在使用业务流程架构、业务架构以及商业模式来描述这一新领域。我们期望在问题解决之前，这方面的讨论能更为详尽，而且我们会尝试向BPTrends的读者作进一步的解释。

　　PaulHarmon，著名的咨询师、作家及分析师。在流程管理领域发表过多部重要著作，曾经参与过美国银行、太平洋保险等多家机构的流程重组项目。