IBM 企业总体架构框架有一个隐含的假设:企业已经具备成熟的组织架构。而对国内企业来说, 特别是中小企业, 问题就在组织架构方面。为此, 我们对 IBM 企业总体架构框架进行了一些调整, 将组织架构作为基础, 将业务架构作为核心, 将 IT 架构作为支持, 由此推出了 IBM-DSAF 框架:
一、企业战略与企业能力匹配性诊断
中国高速发展的经济创造了巨大的市场, 这使得大多数企业在制定战略时都集中于外部的方向性选择, 对企业内部的能力考虑不仔细。例如, “广告王现象” :注重市场, 忽视内部的管理和生产能力。
企业的战略需要相应的企业能力的支撑才能有效执行。而企业的能力通常包括资源、 知识、经验和技能等。
在 IBM-DSAF 中, 基于企业能力理论, 对实施企业战略的能力基础进行了系统的介绍, 并用著名的 VRIO 分析法、 核心能力分析以及动态能力分析等手段, 对战略与企业的能力匹配性进行系统化分析。
二、组织架构
企业的本质是追求经济利益的社会组织。而在任何一种经济组织中, 个人利益是组织成员行为的出发点, 而且, 在组织中, 信息经常是不对称的, 或者说, 每个人并不总是享有同样的信息。这个理念暗示了组织架构的三个重要方面:权力分配、 业绩考核办法和奖励机制。
因此, 一个好的组织架构通过实现决策权与相应信息的有效联系, 从而做出高质量的决策;相应地, 开发出业绩和奖励评估系统, 以便为以个人利益为依据的决策者提供合理的激励,使得他们的决策有利于整个组织的价值。
组织架构是由企业管理者通过组成企业的各种隐性和显性的合同形成的。比如, 决策权力通过正式的或非正式的工作说明分配给相应的雇员, 而业绩评估和奖励则通过正式的或非正式的报酬合同予以确认。
不同公司的最优组织架构是不同的。这种架构的差别不是随意的, 而是一种 系统 的差别,是随着公司相关特征的不同而产生的。一般来说, 相同行业的公司往往都有类似的架构。如果某个行业中重要的环境因素发生了变化, 绝大多数公司都会对自己的决策权力分配以及内部控制系统做出调整。
一个企业的组织架构通常涉及到以下的主题:
权力分配和监督控制
任务分配和工作单位的形成
如何吸引和留住合格的雇员
激励性报酬
个人业绩评估
部门或团队业绩评估
几乎所有的企业管理者都认为, “人” 是企业最重要的资产, 而组织架构就是解决企业中“人” 的问题。
在 IBM-DSAF 中, 引进著名的“活系统模型” (VSM) 作为组织架构工具, 结合 IBM 的 CBM(业务组件模型) , 真正地将业务架构、 IT 架构和组织架构进行了有机整合, 全面详细地揭示了系统化管理的基本原理和主线, 使企业的组织结构更适合现代管理信息技术的运用,最大程度地提高企业的管理和运营效率。
下图是 VSM 的结构图:
VSM 最具有价值的地方是, VSM 是一个面向服务的组织架构工具, 而 IBM 的组件化业务模型 CBM 也是面向服务的业务架构, 在加上信息系统的 SOA(面向服务的架构) , 三者形成了企业的一致性架构, 一种天然的默契。
三、业务架构
企业业务架构(EBA:Enterprise Business Architecture) 又称为企业运营模式, 是企业战略转化为日常运营的机制。业务架构与 IT 架构的结合形成了企业运营的基础平台。
业务架构定义了企业如何创造价值以及企业内外部的协作关系, 描述了企业如何满足客户的需求、 进行市场竞争、 与合作伙伴合作、 建立运营体系、 考核绩效等。
业务架构是基于战略决定企业各组成部分如何运转的工具, 建立了企业战略与日常运营之间的关联关系。宏观层面的企业战略需要通过业务架构来进行分解, 从战略范畴落实到战术范畴。日常运作的组织、 流程、 IT 系统都应该是在业务架构指导下运转的。如果没有业务架构而直接组织和建立企业的日常运营, 就会出现运营与战略的脱节、 各个业务环节缺乏统一协调等问题。
事实上, 所有对企业都存在着业务架构, 有的是有意识设计的架构, 还有一些是无意识地在运用的。精心设计的业务架构会显著提高企业的效率和竞争能力, 使企业避免产生很多管理方面的问题。
1、业务组件
业务组件就是企业的业务模块。在企业架构中, 通过业务组件化把企业的产品、 销售、 采购、 生产、 财务等业务功能转变为业务模块, 具体的方法被称为“业务组件建模” , 简称为CBM(Component Based Modeling)。
CBM 通过企业功能组件化的方式对企业进行重新定义和组合的过程, 在一张图上就可以直观地显示出企业的业务蓝图;CBM 不仅仅是对企业高层次的描述, 而是一个内容丰富的业务模型设计工具, 它采用了一种全新的视角—组件化的方式对企业进行分析和设计。下图是制造企业的一个基本 CBM 框架图:
业务组件模型(CBM) 有着广泛的用途, 在企业管理中主要有以下四项用途:
战略分析
业务模式转型
流程设计
支持 SOA 系统设计
业务组件的定义模板可以在 CBM 总图的基础上, 详细描述组件的价值、 活动、 资源、 考核、IT 支持等信息。由于业务组件是企业架构设计中的基础性工作, 清晰的定义会给后续的流程、 组织、 分布模式、 IT 系统等的设计工作打下坚实的基础。
业务组件具有以下特点:
1. 业务组件是独立的业务模块, 在企业系统中承担特定的职责。组件可以由企业自己完成, 或者由合作伙伴完成。企业组件化的过程也是内部和外部专业化的过程,企业可以通过组件化建立价值网络, 重复利用外部资源来提升自己的竞争力。
2. 组件内部各个活动之间是紧密关联的, 而与外部其它组件的关联程度较低。所以组件是可以独立运作的, 这使专业化分工和外包成为可能。
3. 每个业务组件的输入和输出都高度标准化。组件不能够直接使用其它组件内部的活动或者资源, 只能根据组件之间的标准接口提出服务请求, 从而获得所需的服务。
4. 组件一般都拥有自己的资源, 它们在完成特定的有价值的活动中会消耗这些资源。也存在没有资源的组件, 它们只能通过调用其它组件资源的方式来实现自己的功能。
现在的企业都在向流程化转型, 这是 IT 驱动的必然。然而, 企业流程再造遭遇了许多问题, 问题的根源在于流程再造是一种局部优化, 是基于各个部门内部进行的优化, 针对这种问题, IBM 提出了组件化的方法, 在企业总体层面上进行运营体系的优化, 组件化成为 IBM实践企业架构理论的一大创新。
2、业务流程
业务流程是现代企业运营的核心, 企业架构的任务就是设计出高效的业务流程体系。
传统的流程分析和设计方法, 例如, BPMN 流程管理理论和 SIPOC 流程设计方法等, 都是以优化和自动化单个流程为目标的, 没有考虑如何在企业层面优化和共享相同环节的问题。
在多变的市场环境和激烈的竞争中, 传统的设计方法会使流程变得越来越复杂, 造成流程之间难以共享。由于共享困难, 不同业务部门很容易从自己的角度考虑需求, 制造更多的重复环节。这种情况形成了恶性循环, 造成企业资源的极大浪费, 降低了企业整体的效率。
在 IBM 企业总体架构框架中, 采用组件化的设计理念, 并与传统流程设计方法相结合, 打破部门的界限, 相同的环节在企业中只存在一个, 为企业建立一个整合分享的流程, 最终实现流程的透明化, 标准化, 体系化, 稳定化以及可考核化。
3、组件分布模型
组件分布模型(Location Model) 又被称为属地模型, 是企业业务架构中决定业务活动在什么地点进行执行的模型。通过客户接触程度和作业量两个维度, 对企业的业务组件进行评估, 就可以发现哪些组件可以集中, 哪些组件需要分散处理。
一) 接触客户的程度
衡量一个业务组件或业务活动是否需要面对面地接触客户。把企业的组件按照接触程度进行布局, 就可以决定该组件或活动是集中还是分散。
二) 作业量
从运营作业量的角度来衡量业务组件或业务活动的作业规模, 根据作业量的大小, 决定业务组件或活动专业化或自动化的程度。
在下图中, 左边的评估矩阵说明了每个象限的特点。在设计分布模式的时候, 需要分析各个组件符合四个象限中哪个象限的特点, 并放到相应的位置上。图中右边的矩阵是对四类业务组件的设计方案或改造措施。
在通过评估矩阵发现业务组件的集中或分散的属性以后, 还需要考虑以下的限制性条件,对集中或分散的组件进行调整。
1. 运营成本:在集中或者分散以后, 是否会降低成本, 是否会产生规模效益。
2. 风险控制:是否有利于业务运营中风险点的控制, 降低风险可能带来的损失。
3. 监管要求:政府是否有监管的要求, 会不会对集中或者分散处理产生监管障碍。
4. 接受程度:主要是指外部的合作伙伴或者客户是否对集中或者分散有一定的要求, 能否接受企业的集中或者分散的操作模式。对于企业内部的接受程度不作为重点的考虑对象, 可以通过变革管理等手段来解决。
4、内外包模型
内外包模型是业务架构中决定企业采用何种内外包方式, 即由企业内部完成某个组件的功能, 还是由外部合作伙伴来提供该功能。通过以下的评估矩阵对业务组件的评估(前提是已经确定了企业的业务组件) , 能够发现哪些组件影响企业的核心竞争力, 这些组件需要由企业自己负责;对于哪些在行业内没有差异性的组件, 则可以外包。
每个业务组件可根据上图所示的差异性和同质化、 企业特色和行业通用两个维度进行评估。
通过以上的评估矩阵发现适合外包的组件以后, 还需要考虑以下的限制性条件, 过滤掉由于不满足限制性条件而不能外包的组件:
市场成熟度:在企业运营的地区内, 是否存在能够提供可靠、 高质量、 足够的处理能力的外包商或者合作伙伴。
政府监管:政府是否有监管的要求, 是否允许外包或者由合作伙伴运营特定的业务活动。
外包接受度:企业员工或者客户是否比较容易接受对某业务组件的外包。
外部对企业的接受程度:外包商或者潜在的合作伙伴是否对合作对象有一定的要求, 企业是否符合这样的要求。
外包有很多方式, 我们在此仅仅提出了一些基本的思路。外包最重要的是充分发挥价值网络的优势, 建立企业差异化的、 创新的发展模式。
5、业务架构的治理
设计一个先进的业务架构只是成功的一半, 要管理和实施好业务架构, 还需要做更多的工作, 例如, 从企业管理的层面来讲, 需要相应的系统化管理模式来作为保障;从具体的执行上看, 需要有一种机制来控制和推动业务架构的实施, 这就是业务架构治理, 通常由企业的运营部或者战略发展部来承担这个责任。
业务架构治理的目的:
使业务的运营与企业的要求相符合, 管理多个部门的日常指标, 发现业务运转的趋势并及时做出调整;
分析研究、 设计、 测试新的运营模式和流程, 以解决问题或改进业务指标;
设计业务架构的发展路线图, 根据业务的重要性来决定实施优先级。
业务架构治理是企业治理之下的治理体系的一部分, 企业治理是企业指挥和控制的过程,界定了股东、 董事会、 经理层等利益相关者的关系, 这些利益相关者决定了企业的发展目标和方向。而业务架构治理则明确企业的目标能够在日常运营中实现, 规定相关的职责、 管理流程和方法等, 来保证设计先进的业务架构并加以实施。
业务架构治理使运营与企业战略目标相适应, 通过运营的提升达到业务增长、 成本降低、灵活反应等企业战略目标。业务架构治理由以下几部分组成:
指导原则:规定业务架构的规范和目标, 设计评估指标。
方法:明确设计、 管理以及实施业务架构和模型的方法。
治理流程:主要有合规流程、 更新流程、 沟通流程等。
角色与责任:明确业务架构设计以及日常运营中的管控角色和责任。
四、IT 架构
现代信息技术已经成为企业管理和运营的基础技术, 因此, IT 架构与业务架构是相互支持和相互促进的。对多家企业研究的结果表明, 单独 IT 架构的优化可以为企业带来 2%的业务增长;单独业务架构的优化可以带来 8%的业务增长;而业务和 IT 相互支持, 企业达到总体优化, 则可以带来 20%的业务增长。
IT 架构是企业 IT 建立 IT 系统的基础, 它会指导 IT 的发展方向和项目的开展。企业的 IT
架构能够帮助企业解决以下的问题:
1. IT 如何支持业务的发展?
2. IT 项目开发的理由是什么?如何实现 IT 的投资回报?
3. 企业的技术如何发展?为什么采用某个技术(或产品) ?由谁决定?决定的依
据是什么?
4. 如何向股东和企业管理层展示 IT 的价值?并持续获得支持和投资?
企业 IT 架构的内容包括数据架构、 应用架构和技术架构三个方面。
1) 数据架构
IT 的价值不在于先进的技术和功能强大的软硬件, 而在于能够储存和处理数据、 信息。
数据是对客观事物的真实表现, 企业业务过程中的所有对象的状况都可以用数据记录下来。但数据必须经过加工处理以后, 才能成为对企业有价值的信息。因此, 在考虑企业的 IT 架构时, 首先要考虑的是, 企业需要什么数据?存储什么数据?
数据架构(EDA: Enterprise Data Architecture) 有时被称为概念数据模型(Conceptual Data Model) 、 企业数据模型、 信息模型等, 是指定义企业的数据项以及它们的属性和关联关系。
什么是数据模型?
数据(data) 是描述事物的符号记录。模型(Model) 是现实世界的抽象。数据模型(DataModel) 是数据特征的抽象, 是数据库管理的教学形式框架。
数据模型所描述的内容包括三个部分:数据结构、 数据操作、 数据约束。
1. 数据结构:数据模型中的数据结构主要描述数据的类型、 内容、 性质以及数据间的联系等。数据结构是数据模型的基础, 数据操作和约束都建立在数据结构上。不同的数据结构具有不同的操作和约束。
2. 数据操作:数据模型中数据操作主要描述在相应的数据结构上的操作类型和操作方式。
3. 数据约束:数据模型中的数据约束主要描述数据结构内数据间的语法、 词义联系、 他们之间的制约和依存关系, 以及数据动态变化的规则, 以保证数据的正确、有效和相容。
数据模型按不同的应用层次分成三种类型:分别是概念数据模型、 逻辑数据模型、 物理数据模型。
1. 概念数据模型(Conceptual Data Model) :简称概念模型, 是面向数据库用户的现实世界的模型, 主要用来描述世界的概念化结构, 它使数据库的设计人员在设计的初始阶段, 摆脱计算机系统及 DBMS 的具体技术问题, 集中精力分析数据以及数据之间的联系等, 与具体的数据管理系统(Database Management System, 简称 DBMS) 无关。概念数据模型必须换成逻辑数据模型, 才能在 DBMS 中实现。
2. 逻辑数据模型(Logical Data Model) :简称数据模型, 这是用户从数据库所看到的模型, 是具体的 DBMS 所支持的数据模型, 如网状数据模型(Network Data Model)、 层次数据模型(Hierarchical Data Model)等等。此模型既要面向用户, 又要面向系统, 主要用于数据库管理系统(DBMS) 的实现。
3. 物理数据模型(Physical Data Model) :简称物理模型, 是面向计算机物理表示的模型, 描述了数据在储存介质上的组织结构, 它不但与具体的 DBMS 有关, 而且还与操作系统和硬件有关。每一种逻辑数据模型在实现时都有起对应的物理数据模型。DBMS 为了保证其独立性与可移植性, 大部分物理数据模型的实现工作又系统自动完成, 而设计者只设计索引、 聚集等特殊结构。
在概念数据模型中最常用的是 E-R 模型、 扩充的 E-R 模型、 面向对象模型及谓词模型。在逻辑数据类型中最常用的是层次模型、 网状模型、 关系模型。
企业数据架构的范围要根据实际情况来决定, 可以只包括概念数据模型, 或者进一步包含逻辑数据模型, 物理数据模型通常不包含在内, 它属于系统设计和开发的范畴。企业数据架构所起的作用是规划和指导, 为此, 没有必要加入过多的细节。
企业数据架构可以帮助企业消除信息孤岛, 建立一个共享、 通用、 一致和广泛的企业数据基础平台。在应用系统架构中, 规定了共享数据的用户权限。
2) 应用架构
应用架构的目的是建立企业的业务架构和数据架构与具体的 IT 之间的关联。应用架构不是对某个系统的设计或者需求的分析, 而是定义企业向业务部门提供的整体的 IT 应用系统和功能。
应用架构在 IT 架构中发挥核心的作用, 它能够连接业务架构中的流程、 组件、 功能、 人员, 也能够连接数据架构中数据的管理和使用, 还能够提出对于技术架构和 IT 基础设施的要求。因而, 制定一个完整全面的引用架构对于 IT 系统的建设非常重要。
应用架构是一个全企业的单一视图, 规划定义 IT 系统和他们之间的接口以及集成方式,这样可以避免各个部门从自己的角度出发, 建立很多烟道式的、 重复的、 难以共享的应用系统。应用架构理论的引入, 可以解决企业目前在开发和系统集成过程中面临的很多问题。
3) 技术架构
技术架构是 IT 架构中比较底层的架构, 它定义了如何建立一个 IT 运行环境来支持数据和应用架构, 以保证业务的正常开展。
技术架构不是对软件开发、 硬件系统、 网络通信等的需求分析, 而是设计一个 IT 平台。
技术架构的设计团队成员需要具有丰富的 IT 软件和硬件知识。
通常在业务架构、 数据架构和应用架构设计完成之后再开始技术架构的设计, 保证设计结果能够提供对业务和应用系统的支持并保持一致。
推荐阅读: