企业架构概述及业务架构详解

组织的结构对于一个组织的正常运转，良好开展一个具体项目，得到相关干系人的认可是一个非常关键的因素。

我处于一个IT系统集成公司，并担任公司的技术支持部经理，目前公司的组织架构完全是一个职能型组织架构，在开展一个项目时，可以说是有些乱的，现将出现的问题描述如下：

１、资源利用率低（尤其是人力资源）；

２、客户满意度低；

３、销售人员满意度低；

４、不利于团队成员提高，向心力弱；

对于出现的这些问题，我认为主要是没有利用有效的项目管理措施，尤其是没有采用项目经理制，中小企业的人力不可能完全是售前是售前、售后是售后、网络工程师及系统工程师完全分开，经常性的会出现职责重负，一个项目的实施经常会由一位工程师一杆子捅到底，不会涉及到其它人员，这种方式无疑是有风险的。

对于中小IT企业，对于某一技术方面的人才储备应该是采取技术高手和技术员相结合的方式，对于一个项目的具体运行可以在技术支持部的下面为具体的项目成立项目团队，授权一人作为项目经理（可以是专门的），然后来统一调度不同技术能力、技术类别的人来进行实施，采用科学的项目管理技术和知识。

这样，将组织的架构由完全的职能性组织架构向弱矩阵型转变，以达到锻炼技术能力、管理能力、良好执行项目的目的。由于中小企业的项目大多技术要求不高、项目范围较小、客户关系较简单，采用平衡或强矩阵型不太适合。

业务系统运行状况及可用性可视化

IT运维部门核心价值是保障业务系统的正常运行，而支撑业务系统的IT环境又非常复杂，涉及人力、网络、服务器、IDC、机柜、各类应用等等资源。任何一个环节出现问题，都将“牵一发而动全身”。可见，IT系统资源监控与管理非常重要。

因此，我们需要将影响应用系统稳定运行的几个要素数据可视化。比如：基础设施资源使用情况；应用性能指标及系统整体运行情况，如这个系统是否可用、整体健康度等。总体来说，可以用到的常用可视化手段有数据统计、拟物化关系、流程关系、各种图表展现以及3D动画技术等。

网络/硬件/存储/虚拟化等基础资源的可视化

IT基础资源监控涉及的范围很广，通过各种数据统计、图表组合的方式，可将各种设备的性能、容量瓶颈、故障隐患等信息统一呈现。

网络以及业务系统的可视化

网络以及业务系统的可视化，一般采用拟物化关系视图来自动发现真实设备和链路，并生成直观的物理拓扑图、地图拓扑关系图、业务关系视图等。通过这些拓扑图，可以直观查看网络设备、链路之间的关系，以及业务系统设备运行状况、设备组件资源之间的业务链接等 。同时， 不同的故障告警级别，将以不同的颜色第一时间显示在拓扑视图的关联设备和所属地域上。

网络管理物理拓扑可视化

网络管理地图拓扑可视化

业务服务拓扑透视

全物理环境的机房可视化

基于三维实时互动引擎技术的3D机房可视化，可以满足全仿真式机房运维需要，层次化递进浏览监控企业区域、园区数据中心、机房、机柜、设备、端口，想看哪里点哪里，省时省力。

运维服务流程管理的可视化

以事件处理流程为例，可以采用流程关系视图，将事件预警、故障发现、受理、应急恢复的整个过程清晰地可视化展现，以直观查看流程进度。另外，比较复杂的服务流程的考核，可以通过可视化的架构视图理清思路，也可以利用各类报表视图来综合评估。

服务流程可视化

流程考核可视化

运维自动化及运维大数据可视化

智能化运维时代，自动化管理工具对运维的帮助越来越大。关于运维自动化，我们不能忽略的一点是，它对可视化的需求与生俱来。很多自动化 *** 作场景，如果没有可视化呈现，你都没法想象自动化该如何工作！

另外，运维大数据技术涉及的关联挖掘、周期预测、行为学习、规律分析等分析行为，也可以通过各式各样的可视化手段来实现。

运维大数据可视化

最后不难看出，运维管理中监控、流程、自动化、运维大数据这几个重要环节都少不了可视化的呈现，而IT服务其实是一个IT资源、流程、团队管理等不断整合优化的过程，最终都是一个统一的服务体系。想象一下，在运维可视化大屏前体验”一览无遗，把控全局“的感觉吧！

有价值的东西是才值得我们投入时间和精力的，企业架构为什么就值得我们投入时间和精力来学习呢？主要由以下两方面原因：

1、 对公司而言，企业架构可以辅助企业完成业务及IT战略规划。在 业务战略 方面，它定义企业的愿景/使命、目标/目的/驱动力、组织架构、职能和角色。在 IT战略 方面，定义业务架构、数据架构、应用架构和技术架构，是IT战略规划的最佳实践的指引。企业架构是承接企业业务战略与IT战略之间的桥梁与标准接口，是企业信息化规划的核心。

2、对个人而言，有助于职业的健康长远发展，比如成为CIO，首席信息官通过指导对信息技术的利用来支持公司的目标，具备 技术和业务 过程两方面的知识，常常是将组织的技术调配战略与业务战略紧密结合在一起的最佳人选。

企业架构包含了四部分，BA（Business Architecture，业务架构）、DA（Data Architecture，数据架构）、AA（Applications Architecture，应用架构）、TA（Technology Architecture,技术架构）。企业架构由全局战略规划驱动，我们来看下战略、BA、DA、AA、TA五者之间的关系。

如图所示，战略、BA、DA、AA、TA实际位于以下三个层次上：

这五者的核心关系，可以概况为以下几点：

l 环环相扣，上层驱动下层，下层支撑上层。

通过上面的内容，我们知道了战略，业务架构，方案架构的关系。下面我们看下实际工作中架构路线图和实施规划环节是如何 *** 作的。

执行的要点是钉到岗位（左侧），落到文档（右侧），细到机构调整、技术采购、项目研发等工作包。主要有以下环节：

这里需要补充说明的一点是，实施计划不仅仅是从“架构蓝图到研发”的计划，也是从“架构蓝图到IT与非IT的方方面面”。

对于业务架构，OMG业务架构组给了如下定义：

业务架构是企业治理结构、商业能力与价值流的正式蓝图。业务架构明确定义企业的治理结构、业务能力、业务流程、业务数据。其中，业务能力定义了企业做什么，业务流程定义企业怎么做。具体而言，就是：

我们分别从国外国内来了解一下，业务架构出现的背景，便于我们更好的理解业务架构的使用场景， 业务架构是跨部门跨组织的业务需求，单个小系统的生命周期，根本就没有业务架构环节。

跨系统规划--业务架构在全球出现的背景

国外软件系统经过长期发展，在经过多年实践后，1962年，发表于哈佛商业杂志的的《信息系统总规划》这篇文章，拉开了跨部门、跨组织需求规划的序幕。此后多年，IBM等企业进行了很多实践。

1982年，IBM公布了业务系统规划（Business System Planning,BSP）方法论。这是个重要事件，对业界产生了大而持久的影响。

此后多年，业务架构快速发展，如Togaf、FEAF等。

以上历史告诉我们，业务架构脱胎于跨系统、重视跨系统需求。站在开发者的角度，业务架构就是跨部门、跨组织的业务需求。

信息孤岛—业务架构在国内“火”起来的契机

国内有个现象，一提到业务架构，就会大谈信息孤岛。这是为什么呢？因为国内真正开始重视业务架构设计，就是从解决信息孤岛的痛点开始的。

21世纪初，国内的信息化进程从部门信息化推进到了企业信息化。企业部门间的（集团子公司间的）协同联动需求，带动了IT信息系统间的信息共享和协同联动需求—同时产生了信息孤岛问题（财务、人力资源、采购、销售、OA、CRM各自为战）。

因为信息孤岛所具备的三大弊端，促使业务架构在国内火了起来，以下是三大弊端：

那如何解决信息孤岛的问题呢？

在一系列系统分头建设之前，先设计业务架构，定义统一蓝图，这是根本。数据一张图、数据共享、流程打通、服务编排，都是围绕统一蓝图具体展开。

业务架构是跨系统的，那么它和子系统的关系是什么样的呢？

图中的大V、小V分别表示什么呢？

大V部分，是总体方案的生命周期。在大V的需求阶段，必须研究和定义清楚跨部门、跨组织的业务需求，这些需求往往是跨系统的。例如，客户报修业务功能明显需要呼叫中心系统、CRM系统、工单系统协同联动，才能支持客服接听电话、确认客户资料、记录报修内容、派遣维修工程师上门这一连串 *** 作。

小V部分，是某一个系统的生命周期。在小V的需求阶段，必须分析和定义清楚这一个系统的需求，这些需求往往是系统内的。例如，CRM系统负责客户资料管理。

综上所述，方案级、子系统级这两级生命周期是同时存在的。举个典型的例子，某公司要做一个ERP系统，他会怎么做呢？

由于方案涉及的范围广、部门多，所以有必要做业务架构设计。这时，由业务架构师担纲业务架构设计，并提交《业务架构书》。

假设主要涉及系统A的需求、开发、测试等。

这时需求分析员冲上去，负责《系统A需求说明书》，当然需求分析员要参考上游的《业务架构书》整体约定。

注：这里只所以说是假设，是因为实际 *** 作中可能是实现某个业务功能需要同时开发系统A、系统B、系统C的部分功能， 并不是说一期工程的所有功能必须隶属于同一个系统 。

假设主要涉及系统B的需求、开发、测试等。

这时这时需求分析员冲上去，负责《系统B需求说明书》，当然需求分析员要参考上游的《业务架构书》整体约定。

业务架构要想成功，首当其冲的是，架构师要做正确的事，即在业务架构的实际工作内容上有充足的经验，不能遗漏。

相反，业务架构师分析环节的缺失，意味着业务架构蓝图规划项的缺失，影响从投资角色到方案设计，到实施规划，在到IT工作包和非IT工作包识别等所有后续工作。

业务架构 = 业务功能 + 组织结构 + 业务流程 +业务数据

业务架构的实际工作内容有哪些呢？

业务架构的前身是1982年IBM发布BSP等跨系统规划方法。所以，业务架构本质上是跨系统规划。

但是，业务架构的内容远远超过了跨系统需求分析这个范围，覆盖跨系统业务架构蓝图规划这个更大的范围。究其原因，是业务架构必须发挥从战略向实施过渡的桥梁作用—上街公司战略， 下接IT实施和非IT实施 。

不错，业务架构也涵盖了非IT部分的蓝图！

我们来看下细化的业务架构实际工作模型。

就大的方面而言， 业务功能定义企业做什么，组织结构定义谁来做，业务流程定义怎么做，业务数据提供必要的支撑，因此，业务功能、组织结构、业务流程、业务数据四者，构成了业务架构蓝图的核心。

同时，商业模式揭示的是企业产品、企业核心资源、客户、伙伴、渠道、成本、利润之间的本质关系。商业模式这个现代工具，也是业务架构蓝图的必须规划项。

就小的方面而言， 第一，业务渠道在哪里？组织结构是围绕部门、角色、职能展开的，而组织结构、业务渠道、合作伙伴是紧密相关的。所以，业务架构师在梳理组织结构的同时，应结合渠道战略和合作伙伴战略，定义业务渠道规划，定义合作伙伴规划，这些都是业务架构蓝图的“一等公民”。

第二，价值链在哪里？价值链模型是对一个企业所有生成经营活动的总体描述，是规划业务架构蓝图时的必做项目。可以对业务功能进行三级划分、层层分解：

第三，业务流程 = “主干流程 + 分支流程 + 业务规则”：

例如：买火车票时，“选票-抢票-支付”这个流程是稳定的。、

例如，选座分支流程，靠窗、不靠窗、坐票、卧铺（上下中铺）。

例如，买儿童票、成人票、学生票要进入分支流程。

所以建议一边定义业务流程，一边定义相应的业务规则。

综上，业务架构蓝图的内容应该明确！全面！直观！详细！

上面我们学习了业务架构包含的内容，可能不够直观，我们通过案例来加深我们对每个模块的理解。

举例业务架构蓝图五要素

我们借助业务架构蓝图五要素，管窥一下中国铁路12306平台的业务架构。

目标业务功能—线上购票、线上支付、线上退票等；

目标组织结构—在原组织结构基础上，新建IT运维中心；

目标业务流程—先登录、后抢票、再支付、超时未支付则释放票源；

目标商业模式—线上购票，省事省力（这个仅是价值主张）；

目标业务数据—用户账户、列车时刻表、坐席数据、订单、支付记录等。

举例业务渠道、合作伙伴、价值链

下图分析了证券公司的业务功能与相对应的业务渠道

价值链包括核心业务层和支撑层，这里的核心业务层属于价值链对业务功能和服务的顶级分解。

在做规划时我们常采用GAP分析法，先确定当前现状，然后给出我们的期望，分析目标和期望的差距。如果有人和一个新手这样说，可能是不够的，你至少需要回答以下几个疑问：

疑问一，业务架构师具体要分析什么？怎么才算是战略驱动？

--能否具体到政策文件？战略方针？市场调研？友商对标？

疑问二，从战略到蓝图，中间的逻辑是什么？

--能否具体到小目标分解？小策略制定？

疑问三，我们首先应该怎么做？

--就连一个小的进销存系统，也要先进行业务调研，不是吗？

落地设计步骤

我们看下作者分享的战略驱动的业务架构（BA）设计三步法。

图中的三大步很明确，也非常贴近实际。

优点1：明确的战略驱动起点。方法中明确了三种战略驱动因素（Drvier）的类型，因为实际中就是国家政策、企业战略、对标友商者三者之一触发了后续的调研、规划与实施。

优点2：明确的调研环节。在第一步中，包含了调研环节。

优点3：强调了从战略到蓝图的过渡逻辑。在第2大步中，扎扎实实地规划好业务架构目标/策略，才能确保蓝图充分支撑战略。这一步属于高层级业务架构设计。

优点4：目标蓝图与Gap分析并重。在第3大步。

设计BA目标蓝图这一步属于低层级业务架构设计，其中Gap环节是必须环节，我们必须识别出业务架构的增量有哪些，给出对应的实施措施。

Gap分析的价值在于，它是持续进行架构治理所必需的，除了BA规划环节应用，在AA、DA、TA设计环节也均有应用。

要点明确Driver，做好调研

业务架构设计必需做好的第一件事，就是100%明确战略驱动因素是什么。

业务架构设计必需做好的第二件事，就是调研。 通过调研，广度上理解企业的宏观环境、行业趋势，纵深上理解战略的前因后果、来龙去脉、横向上理解企业的竞争格局、友商动向。

粗看，调研范围很广，让人理不清头绪。细看却有规律，主要三条线，分别是管理层访谈、战略的来龙去脉、可借鉴案例。

要点从战略到蓝图的内在逻辑

从战略到蓝图的内在逻辑，由四个概念支撑起的骨架：

Driver—战略驱动因素

Goal—业务架构目标

Strategy—业务架构策略

Blueprint—业务架构蓝图

这是一个大型企业，推进数字化采购转型如何从战略到蓝图的构建逻辑，相信它有助于我们的理解以下几点。

综上所述，从战略到蓝图的内在逻辑主线是： 确定Driver—目标分解—策略设计—蓝图定义 。逻辑明确，创新有据。

只有业务架构师真正洞悉了战略意图、准确领会了战略动机，之后的业务架构设计工作都是有迹可循的，工作量再大，也不可怕。

工具GAP分析

推进确定Driver

项目假定为：某铁路数字化服务转型工程。

业务架构师（张三）知道业务架构的Driver是整个业务的起点，必须找准、吃透。

张三了解到，数字化转型工程的Driver是公司刚制定的《公司战略规划》。

《公司战略规划》中阐述了数字化服务转型的背景：近年来，互联网技术的发展，提高了各行各业的服务水平，极大方便了人们群众的衣、食、住、行、医、学、玩等方面。从企业的角度而言，借助互联网、大数据等技术，积极推动数字化转型，拥抱以客户为中心的服务模式，能搞提高客户满意度和企业竞争力。

《公司战略规划》中和数字化转型战略的核心表述是：树立以人为本、客户至上的服务理念，创新服务方式，完善服务标准，推动数字化服务转型，提高服务水平。

推进做好调研之管理层访谈

管理层访谈： 不是让业务架构师去了解行业，而是要领会管理层的关注点、主要看法。

通过访谈，业务架构师应了解：

推进做好调研之可借鉴案例研究

研究可借鉴的最佳实践、最佳案例，也是调研的必做内容。

究其原因，业界每个阶段的最佳实践、最佳案例，都反映了业界当时的实践水平。所以，如果业务架构师收集并分了业界当前最佳实践案例，就可以在自己负责的架构设计中更好的把握设计方向、制定设计标准。

业务架构目标和策略包含以下两方面：

推进差距分析

Baseline Business Architecture

Target Business Architecture

上述案列，我们通过GAP分析，识别了业务能力差距和IT能力短板，从而识别业务架构目标与策略，这是采用自底向上的方法。为我们后续环节做准备，比如我们识别出了核心业务需要增强的包括销售、客运、货运、清算、售后，新增的包括增值业务，在制定在业务功能、业务流程、业务数据、组织结构、商业模式模块给出对应的策略。

如：从上图价值链分析中看到，我们新增的业务需求是增值业务，通过电商业务、旅游代理可以实现，再进一步想一下，就会知道我们的目标是增收，接着可以自顶向下思考，增收除了电商业务、旅游代理，我们还可以做保险代理，通过服务门户这个渠道触达用户。

推进确定目标与策略

只有扎扎实实地规划好业务架构目标与策略，才能确保后续业务架构蓝图定义充分支撑战略。

确定业务目标与策略环节，是业务架构设计的高层部分。后续的业务架构蓝图定义，是业务架构设计的低层部分。前者引领者后者的发展方向。由此可见“确定业务架构目标与策略”这一环节的重要性。

这一步，有三种做法。

1)自顶向下：将Driver分解为子目标，将子目标映射到业务架构策略。

2)自底向上：通过Gap分析，找到能力短板，从能识别业务架构目标与策略。

3)上述两种做法相结合，循环展开，互为验证。

铁路系统数字化转型，提高服务水平是Driver，如何才能达到这个终极目标。

答案是：

组织结构视图包括三个模块，组织结构、业务渠道、合作伙伴。

组织结构及改进主要描述部门设置、岗位设置、岗位职责等；合作伙伴及改进主要描述加强与供应链上下游的合作伙伴之间的关系。业务渠道创新也是业务架构设计的常见策略，下面会举例说明。

组织结构 下图是运用GAP分析的方法，画出当前组织结构和目标组织结构，并表示出变动点。

新手业务架构师往往认为组织结构没啥好设计的。其实恰恰相反，一旦组织结构需要变革，必然影响重大。

从上图，我们可以看出来，之前企业自己做IT开发，目前公司计划在做开发的同时，自己也做IT运维。相应的，企业组织结构新增了IT运维中心。

业务架构师应尽早明确组织结构的可能变化。因为无论是新建部门，还是部门增强、人员能力增强，都属于TOGAF中的能力增量，是需要后续非IT工作包实现的。

不仅如此，组织结构的变化还影响整个企业的治理结构，从经营管理，到制约监督，再到绩效考核。

总之，业务架构师虽然经常被当做跨系统软件需求分析师降级使用，但真正承担业务架构蓝图规划任务的业务架构师，是必须能扛得起很多“非IT”规划的。

渠道：在百度百科上的解释是“比喻达到某种目的的途径“，业务渠道就是用户为了达成业务目的的途径。如下图，列车长通过补票终端这个渠道帮助用户完成补票，客运公司通过大屏幕告知乘客车次信息。

业务渠道 业务渠道创新示例

网站、手机APP、补票终端、大屏实现了购票、补票、查看车次信息线上线下联动，提升了用户体验和公司内部效率。

感悟 ：由上图可知，业务渠道不是完全孤立的业务架构蓝图规划项。它和业务流程、业务功能、组织结构是相互呼应的。因此，我们规划业务渠道时，也应考虑这些。

关于渠道联动，有同行这样总结：

企业是由一系列为顾客制造价值的活动和功能组成的。我们的业务功能就源自于可以为顾客制造价值的活动和功能。

企业的价值链展示了企业的设计、生产、营销、运输等为顾客创造价值的一系列活动、功能以及业务流程之间的连接情况。价值链有两个主要的组成部分：

核心业务（创造主要的顾客价值）

支持活动（为核心业务提供支持服务）

继续来看运输公司数字化服务的案例，业务架构师，面对运输企业数字化服务转型的任务，经过潜心研究，给出了下图的价值链划分结构。

有的同学可能会有疑问，为什么会在核心业务模块同时存在客运和货运两个区别较大的业务类型？在实际工作中可能只负责客运、货运其中一个模块。前面我们业务架构出现的背景也有提到在国内业务架构是为了解决信息孤岛发展起来的。业务架构师就是要在全局做规划，而不是梳理单个系统。

以上我们已经整理了价值链，现在我们要分解功能域了。下图是一级功能域分解图。

接下来，做业务能力Gap分析，我们可以看到新增的一级功能域有4个，增强的一级功能域有13个。

通过价值链分析到一级功能域划分的转变，我们会有以下收获：

第一， 价值链分析模型为后续功能域划分奠定了基础。管理支持+核心业务这个业务功能呢域划分框架确实很好用。并且广受业界认同，在沟通的过程中自然也容易被其他人接受。

第二，类似“上车前、上车中、下车后”时间轴思维，是业务架构师必备的分析技能，同时，是甲方企业领域专家们经常使用的分析习惯。

业务架构设计不仅要定义出目标架构，还要使用GAP分析法，识别出需要增强的架构能力，为后续实施做准备。具体包括业务功能变化与增量、组织结构变化与增量、业务流程变化与增量、业务数据变化与增量。

商业模式揭示的是企业产品、企业核心资源、客户、伙伴、渠道、成本、利润之间的本质关系。简单说，就是为什么同样的事，有的企业行，有的企业不行。

制定商业模式时并不是说全局只有一个商业模式，我们可以根据我们的目标分别制定商业模式 ，比如上述案例中，该铁路运输公司的目标有三个：便民、增收、增效。我们就可以设计三个商业模式。

就铁路企业的数字化服务转型而言，要便民，应支持随时通过网络、电话、手机App获取企业服务。

就铁路企业的数字化服务转型而言，要增效，可以借助硬件设备和智能控制系统，促进取消、检票等环节的数字化转型，提升效率。

感悟商业画布，借助九个小格子，构建了简介高效的系统化思维环境，是个了不起的发明。

从上述例子可以看出，商业模式有如下优势：

个人认为，商业模式融合了BRD和MRD的内容：

BRD：商业需求文档，关注为谁（客户细分）、解决什么问题（价值主张）、需要做什么（关键活动）、花费什么资源（关键资源）、性价比（成本/收入）如何。

MRD:市场需求文档，关注消费者怎么触达（渠道通路）、怎么获得合作伙伴。

业务流程视图是应用架构的输入，也是业务架构中最落地、篇幅最大的章节。

作者在文章中对业务流程的协作方法进行了论述，结论是简单的业务流程可以采用流程图的方式绘制，业务流程分支较多且复杂的强烈建议使用文本化描述。

业务流程定义规范

要点是“1个主干+N个分支”方式的流程分解

要点是“阶段化+步骤化”，并附每步业务或数据模型规则

要点是“注明在主干流程的分叉位置”，并附每步的业务或数据模型规则

这部分为可选

这部分很重要，上面也有提到，业务流程视图是应用架构的输入，所以对这块再总结一下。

我们发现，分支流程和业务场景有完美的对应关系。识别分支流程，就是场景化思维。相反，如果不区分主干流程、分支流程，后续业务需求变更会波及一大片，而不是改一个分支流程这么简单了。这太不专业。

业务功能很多，业务场景更多，业务流程定义了什么呢？业务流程定义一个业务功能，其中包括多个业务场景。比如购票包括了多人购票、购买儿童票等。

业务规则多如牛毛，如何避免业务规则碎片化？围绕业务步骤定义业务规则，业务步骤可以是主干流程步骤，分支流程步骤。

关于是否使用业务流程图：越是核心的业务流程，越是分支多、业务规则多，此时建议采用文本化规范，这样呈现的信息更加全面。不复杂的业务流程，可以沿用流程图的方式。

这篇文章对企业架构进行了概述，详细讲述了业务架构出现的背景及实际攻略，并通过实际案例加深我们对业务架构的理解。

我们来一起回顾一下文章中涉及到的概念之间的关系。

战略驱动的业务脚骨设计实战步骤，精华在于，从战略到业务架构蓝图的跨度太大，逻辑链条接不上气，所以分两步走

如果读完之后感觉通过企业架构可以提升自我、有利于公司发展，就行动起来吧！

前几天参与了公司组织的”引航计划“培训。

公司TOP分享了，”新零售战略漫谈“。

品牌事业部TOP分享了，"品牌管理，企业变革对于管理者的挑战与机遇”，如智能智造对品牌的挑战与机遇。

两位TOP分享的都是技术变革所引起的企业变革的话题。

让我印象特别深刻的是两位TOP对于变革都是积极拥抱的，变革的第一性原理都是

"一切以顾客为中心，以满足顾客需求为目的”。

这让我陷入深思，

企业的核心竞争力是 ”快速响应“、”挖掘“、”引领“顾客的需求,一切以"顾客(用户)需求"为中心。

哪么信息系统建设的原则也是必须支撑企业的核心竞争力来搭建。

目前我们公司搭建的信息系统如何 

能否支撑未来企业的高速发展

如果需要变革或优化，方向又是什么？

工业时代，信息化建设一般以"前台+后台"的平台化架构来搭建，所有的软件系统都是基于这种方向来规划、设计。

一、前台、后台系统的定义

前台，每个前台系统就是一个用户的触点,是用户直接使用或交互的系统。

例如，网站、手机APP、微信公众号等都属于前台范畴。

后台，每个后台系统管理企业的核心资源(计算+数据),以规范处理企业底层核心资源和企业的核心可追溯单据为主要目的(采购、销售、财务订单等)，它们的变更需要严瑾的申报审批流程和更高级别的测试部署要求，天然导致它们变更频率低、变化成本高、变化周期长。

例如，财务系统、OMS系统、客户管理系统、仓储物流管理系统等。

基础设施、计算平台作为企业的核心计算资源，也属于后台的一部分。

前台、后台系统来源有两种

1、花大价钱外采，实施，需要每年支付大量的服务费，定制化困难。

2、花大价钱自建，一身的补丁，年久失修，同样变更困难。

有人会说，现有的版本较低，可重新搭建新的后台系统。

但是由于前、后台系统天然的特性，重建也只是推倒了一个“烟囱”，只是新建一个差不多的“烟囱”,建的越多，后期的运维会越艰难（天港城、DRP、AFS、FMS等)。

二、前台+后台系统框架的僵局

"前台系统"是用户直接使用或交互的系统,而企业的核心竞争力是 ”快速响应用户的需求"。

所以前台系统为 用户而生 ，需要快速的创新迭代、越快越好。

“后台系统"的目标，主要是为了实现企业资源的数字化管理，解决企业管理的效率问题，而不是完全为了服务于前台系统。

后台系统往往是稳定至上，越稳定越好。

前台系统是需要快而美，快速迭代。

这样前台、后台系统的的配速不区配。

而企业会不断发展，顾客(用户)需求的不断变化，后台修改的“成本”、“危险”也只会越来越高。

后台系统对于变化，天然会选择保持稳定性与可靠性，响应速度会越来越慢，甚至无法响应，或者将很多的业务逻辑不断的加到前台系统，造成前台系统不断膨胀，渐渐拖垮前台系统，同时用户的满意度下降，企业的竞争力自然也随之下降。

这样前台需要的快而美、后台系统的稳定可靠天生就陷入僵局 。

我们公司是不是也慢慢体现这种特点

顾客需求多、变动频繁，而信息平台的响应速度也是越来越慢 或直接说NO

哪有没有解决之道？或有没有路径来处理？

移动互联网时代的弄潮儿，国内毫无疑问是阿里、腾讯、华为等。

其中阿里从最初的淘宝、天猫、支付宝、蚂蚁金服、阿里云等，业务不断扩展，阿里的技术团队在业务的不断摧化下，经过多年的努力，将自己的技术和业务能力沉淀出一套综合平台（大中台、小前台的系统框架)，具备了对前台业务变化及创新的快速享应能力。

阿里的信息平台中，引入了中台的业务架构。

中台业务架构是将一些基础公用的业务服务抽像出来，形成 共享平台 ，提供给所有的前台业务使用。

一、中台定义

中台为前台而生，目的就是更好的服务前台规模化建设，更好的响应服务引领用户。

前台系统中的通用业务能力"沉降"到中台，为前台减肥，恢复前台的响应力。

后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本。

中台是在“前台”与“后台”之间添加一组变速轮，将前台、后台的速率进行区配，在”前台“与”后台“之间搭建桥梁，易于前台使用，将后台资源顺滑流向用户，响应用户。

中台作为桥梁，链接了用户与企业核心资源，可以将业务沉淀在中间层，覆予这些能力更强的灵活度和更低的变更成本，为前台提供强大的能力炮火。

二、中台的核心价值

1、以用户为核心的持续化创新能力，是中台建设的核心目标，业务响应能力和创新能力，是互联网时代企业综合能力的核心体现。

2、中台建设根本上是为了解决企业响应慢困境， 弥补顾客需求快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的矛盾，沉淀业务能力，打通并顺滑链接前台需求与后台资源，帮助企业不断提升用户响应速度。

在未来企业信息化平台的建设过程中，我们需要建设自己的中台层。

公司现建立了比较强大的信息化平台,如SAP、OMS、CRM、WMS、SRM、POS、OA等。

也建立了较强大的系统流程运维、研发团队，有较强的软件项目开发、运维经验。

随着新技术发展（如移动互联网、物联网等）、顾客生活方式的变化、人工材料成本上升、个性化需求等各种因素，公司战略也会变动，相应的信息化系统为了支撑业务的变化也会调整。

如最近公司"新品牌"的创建，就是为了适应这种变化，对于这种变化，信息化平台如何变化，我的思考如下（仅是我个人思考，有可能全是错的）

新品牌

一、顾客定位，相对于现有品牌顾客会 年轻、更爱美、有个性、有相应的经济能力，是随着互联网发展成长起来的群体。

二、产品定位，相对于现有品牌价位会偏低，多样化、年青化、舒适。

三、销售渠道，线上线下融合，购物更方便、快捷、售前、售后体验好。

四、供应链渠道快捷，可直接采购、或外协加工，供应链需敏捷反应。

信息系统规划及方向

顾客年青化、线上线下融合、敏捷供应链，基于互联网时代的特性，信息系统的搭建也需要基于"共享服务中心”的IT架构来实施、搭建。

“共享服务中心”的IT架构。

一、可以避免重复功能的建设、维护带来的成本浪费。

二、可以最大程度避免需要打通不同系统间实现业务交互带来的集成协作成本（如SAP、OMS、WMS、POS、CRM等）。

三、业务可持续沉淀、形成可重用的服务中心，为业务的快速发展、创新带来价值。

四、可以让企业具备跟互联网企业一样的业务快速创新、试错的能力。

五、信息中心，往核心业务和数据运营团队进化，更快、更好的支持业务发展，培养即精通业务，又熟悉技术的复合型人才。

2019年或之后的很长一段时间，我们应搭建相应“共享服务服心”

一、统一库存服务中心

   统一库存共享和分配的过程，提高库存的管理能力，实现全渠道库存的可视、可控。

二、统一会员服务中心

        统一各个业务线分散的用户体系，统一用户数据、存储及服务接口。

三、统一商品服务中心

       商品是所用用户、系统的入口，对数据的质量要求很高，高质量的数据是所有业务的基础

四、统一的交易服务中心

       交易业务领域的服务中心，包括交易流程、订单管理、结算、营销、评价等。

五、统一的物流服务中心等一系列的中心

服务中心构建好后，相应的“全渠道销售平台”信息平台，自然也水到渠成。

共享服务中心的IT架构，在前台、后台系统之间搭建中台，会更快、更好的响应顾客需求、提升组织效率。

同时共享服务中心的搭建，对于研发组织、研发流程有新的优化与要求。

应避免或淘汰目前的“项目制”的实施SOA的误区。

何谓IT运维管理？在了解这个概念之前，我们首先需要了解一下什么是IT管理？

天天客服IT运维管理中心专家龙少文解释：IT管理是在信息化运营阶段通过运维管理制度的规范，IT管理系统工具的支持，引导和辅助IT管理人员对各种IT资源进行有效的监控和管理，保证整个IT系统稳定、可靠和永续运行，为业务部门提供优质的IT服务，以较低的IT运营成本追求业务部门较高的满意度。

简而言之，可以理解IT运维管理为：在网络的基础设施建设完成之后，整个网络处于运行状态，IT部门采用相关的管理方法，对运行环境(包括物理网络，软硬件环境等)、业务系统等进行维护管理，我们把这种IT管理的工作简称为IT运维管理。

IT运维管理包含内容

IT运维是IT管理的核心和重点部分，也是内容最多、最繁杂的部分，主要用于IT部门内部日常运营管理，涉及的对象分成两大部分，即IT业务系统和运维人员。其管理内容又可细分为七个子系统：

第一、设备管理：对网络设备、服务器设备、 *** 作系统运行状况进行监控，对各种应用支持软件如数据库、中间件、群件以及各种通用或特定服务的监控管理，如邮件系统、DNS、Web等的监控与管理;

第二、数据/存储/容灾管理：对系统和业务数据进行统一存储、备份和恢复;

第三、业务管理：包含对企业自身核心业务系统运行情况的监控与管理，对于业务的管理，主要关注该业务系统的CSF(关键成功因素CriticalSuccessFactors)和KPI(关键绩效指标KeyPerformanceIndicators);

第四、目录/内容管理：该部分主要对于企业需要统一发布或因人定制的内容管理和对公共信息的管理;

第五、资源资产管理：管理企业中各IT系统的资源资产情况，这些资源资产可以是物理存在的，也可以是逻辑存在的，并能够与企业的财务部门进行数据交互;

第六、信息安全管理：该部分包含了许多方面的内容，目前信息安全管理主要依据的国际标准是ISO17799，该标准涵盖了信息安全管理的十大控制方面，36个控制目标和127中控制方式，如企业安全组织方式、资产分类与控制、人员安全、物理与环境安全、通信与运营安全、访问控制、业务连续性管理等;

第七、日常工作管理：该部分主要用于规范和明确运维人员的岗位职责和工作安排、提供绩效考核量化依据、提供解决经验与知识的积累与共享手段IT运行维护管理的每一个子系统中都包含着十分丰富的内容，实现完善的IT运维管理是企业提高经营水平和服务水平的关键。

IT运维管理面临的难题

IT运维管理是一门探讨如何提高网络应用性能的课题，怎样利用网络管理做到企业IT基础设施建设的管理、合理分配网络资源、保障生产业务、对网络规划和新业务上马提供支撑，而其最核心的目的是保障企业生产业务。

日常IT运维管理面临诸多难题，具体体现在以下多个方面：

网络设备

在企业IT基础设施的搭建过程中，底层的网络设备厂商和类型多样且复杂。随之而来的问题是：如何将不同厂商的网络和应用管理产品在界面级、消息

级和数据级集成起来实现统一管理？如何让IT管理员了解到整个网络全局的运行情况、发展趋势和可能存在的故障隐患点，以便及时采取相应措施，实现事前管

理。

拿曾经碰到过的一个典型客户来说，它的网络中有11种厂商的路由交换设备，还有存储设备，安全设备，UPS等。同时还拥有：小型机，服务器等，上层的业务系统有OA和CRM等。这样大而复杂的一个网络环境，该怎么管呢？

科学的运维管理思路告诉我们，首先需要解决的是对IT基础设施的管理，管理范围要能覆盖到机房所有硬件设备。这一点是前提和基础。其次，才是对各种应用系统做到很好的监控。最后，才能为业务系统提供足够的保障。

网络流量

在绝大多数的企业网络中，存在不同程度的网络延迟，造成重要业务和应用时断时续，这直接成为企业业务的杀手。另外，网络的带宽也是企业关心的重

点。比如，哪个时间段很拥挤，哪个时间段很空闲，有没有规律，怎么样去调查拥塞的原因，网络带宽都是被谁占用了，是被哪些客户端、哪些应用或者异常应用所

占用了。这些都是摆在每一个企业运维管理领域中很实际的问题。

　该如何很好的解决这些问题呢？

根据多年的运维管理经验得出，对于这种情况，需要采用流量分析的方式。通过对出口流量或者监控对象进行采集，进行24小时实时的监控和分析，可

以对流量进行多角度多层次的挖掘分析，比如按照流量、数据包个数、连接数、协议等类别分析当前网络的负载情况，为网络的优化配置提供参考。通过报表分析展

现流量特征，让IT管理员明白流量被谁、被何种应用、被何种异常行为占用得怎么样。

IT运维管理怎么样帮助IT管理员判断和控制安全问题，也就是作为与防病毒、防火墙、IPS等安全产品不同的角色，从网络的整体情况要能够判断未知的安全问题，并提供修复方案，

在不影响正常网络运行状况下将安全问题防患于未然。如果IT管理员能针对异常行为的特征建立自动告警，在某些安全攻击出现前发现故障隐患，并提供连动的判

断和处理机制，这样IT管理员可以及时采取了措施避免业务遭受损失。如果能在对问题特征自动告警的同时，自动记录问题的原始数据以供事后分析，这样IT管

理员可以再现数据异常行为、捕捉网络数据异动入侵记录，对症下药制订策略防止问题的再次发生。

业务系统

针对日益复杂的业务系统，现有的运维管理系统更多的强调的是功能的展现。比如，从业务主机负载、数据库服务器负载、数据库、中间件、应用系统、

网际流量、进程状况等等不同角度实施联合监控，强调的是性能参数指标的多少，或者是界面的美观程度。当然，这是落实业务系统管理环节所采用的方法。

但事实上，作为企业自身来说，无论采用哪种监控也好，IT管理手段或者运维管理系统也罢，其核心总是需要围绕保障和改进企业的业务系统。

　这就提出一个问题，如何来保障又如何改进企业的业务系统呢？

首先，需要了解清楚业务系统所涉及的具体环节，针对每一个环节进行管理落实。按照科学运维管理的建设思路，分为：用户-网络-硬平台-软平台-

业务系统这五个环节。需要从这五个环节所涉及到的五个方面去做工作。这五个方面分别是：全局的性能管理、故障和事件管理、资源的使用状况管理、安全管理和

数据分析管理。其次，通过性能和历史数据的反映，又可以做到对业务系统提供改进决策的指导。

当然，对于如何保障和改进业务系统这个问题，目前业界众说纷纭，没有统一的标准。但有一点是肯定的，就是需要从企业用户的角度出发，通过明确的管理思路作为指引，使用软件+服务的方式和企业用户共同探索和研究，最终达到对业务的保障和改进。

当前IT运维管理的任务

在企业网络运维早期，IT运维管理侧重于网络、硬件等设备。随着业务系统涉及的环节日益增多，单一的网络管理已经不足以满足管理需求，越来越多的企业已经将关注点从单一网络转变到当前的业务系统，落实保障业务系统的各个环节成为重中之重。

因此，我认为，当前国内用户最关心的莫过于如何保障业务系统的正常运行。IT运维系统应该从业务角度切入，以业务为导向，通过对整个业务系统的关注，落实业务系统的各个环节，从而来达到保证业务系统稳定运行和透明化管理的目的。

IT基础架构随着运营商业务的不断发展和3G业务的不断临近，以及从全面服务客户的角度出发，充分实现应用系统共享的需求越发明显，面向服务的架构（SOA）已成为使企业实现IT与业务紧密结合，提高业务流程灵活性，从而真正帮助企业快速响应外部变化，是企业发展、创新的重要IT工具。（1）应用集成阶段各运营商都在进行企业应用集成平台的建设，应用集成技术分为三个阶段：第一阶段的应用集成技术是在中间件基础之上，发展丰富的连接与转换技术及全面的元数据（META DATA）管理与应用能力，解决信息共享与信息交换的问题，同时也使得企业的应用系统容易维护与管理，为企业节省运行及维护费用。这种应用集成技术所解决的问题更多地集中在数据层面，而不是业务层面。第二阶段的应用集成技术是在业务流程管理/集成（BPM/BPI）基础上，对企业业务流程进行自动处理、管理和监控。第二代应用集成技术更多关注业务层面的问题，然后由业务层面下移分析技术层面。第二代应用集成技术是目前主流的企业应用集成技术。第三代应用集成技术是在第二代集成技术的基础上，采用最新的技术规范对集成技术本身进行规范，其主要目标在于实现企业业务的“可复用性”、“可扩展性”和“灵活性”。第三代应用集成技术突破了以往应用集成技术的局限，基于最新的技术规范，不仅能缩短EAI/BPI集成平台的实施周期，更为重要的是能基于共性的行业知识、更规范的技术标准，修改现有集成平台，不断开发并集成新应用。（2）应用整合的工具和技术从应用整合所使用的工具和技术来划分，可以分成下面多个层次，分别是界面整合、数据整合、应用整合、流程整合和业务对业务的整合（B2Bi）。界面整合是把原有零散的系统的界面集中在一个新的、通常是浏览器的界面中，实现统一接入、统一认证和内容的统一展示；数据整合是为新的商业目的，提供一个可访问已有的多个数据库系统的新的接口。即通过提取和可能的转化过程，实现对应用所使用的数据的定向和传输；应用整合是为了实现企业内部不同应用系统之间的互连，通过应用集成实现数据在多个系统之间的同步和共享；流程整合层用于将不同的应用系统连接在一起，进行协同工作，并提供商业流程管理的相关功能，包括流程设计、监控和规划，实现业务流程的管理；业务对业务的整合也成为与合作伙伴的整合，是整合的最高层次和未来发展方向。实现了产业链上下游伙伴之间的业务整合。近年来，运营商竞争的焦点已经逐步由网络质量的竞争转向后台IT支撑系统的竞争，IT支撑系统的竞争未来会逐渐转向通过复杂的服务流程进行更深层次的以客户服务为中心的竞争。因此，在各应用系统实现面向客户的发展过程中，运营商首先应进行IT基础架构的整体规划设计，然后逐步建立企业级数据中心，建立良好的整合机制，使其能迅速适应新业务上线，尽快建立面向客户的服务能力。目前，一些运营商的IT基础架构已经开始逐步向SOA发展，未来应该根据本企业的实际情况和应用集成技术的发展继续进行系统整合，加强各系统之间的集成，以更好的支持新业务及原有业务的开展。 IT支撑系统发展现状1BSS系统BSS系统主要实现对电信span>业务、电信资费、电信营销的管理，以及对客户的管理和服务的过程，它所包含的主要系统包括：计费系统、客服系统、帐务系统、结算系统以及经营分析系统等。目前国内各电信运营商的基本发展情况如下：●中国移动：中国移动从2001年起开始建设全省集中、一体化的业务运营支撑系统（BOSS），经过了BOSS 10、15以及20的建设，目前正在考虑向下一代BOSS即NGBOSS的演进。●中国电信：中国电信各省公司从2003年起陆续按照企业信息化战略规划（ITSP）的思路开始规划自身的BSS/OSS系统，原有系统模块的划分有所变化，但系统功能仍然保留。系统建设仍逐渐由本地网集中向省集中过渡，功能模块之间将共享核心数据模型。●中国网通：网通集团和下属各省公司按照既定的IT系统架构和IT规划在稳步的进行整合和建设的工作，整体思路在朝着综合业务、数据共享和管理集中的方向演进。●中国联通：联通BSS也是以省为中心分别建设各个子系统，包括综合营账、综合结算、专业计费、客服等，目前正在启动新一代BSS系统试点工程，提出了“两分两合”的系统架构以及统一软件功能需求和业务需求的要求，其重点在于构建稳定的综合帐务系统和灵活的CRM系统。总体上，各大电信企业都在朝着集中化方向大力建设BSS系统，BSS系统的支撑力度和服务质量总体上有了显著提高。随着竞争的日益加剧、业务和资源的形式多样化以及客户服务质量要求的提高，各运营商都在加强对市场的反应速度和应对措施，因此构建快速高效的BSS系统、缩短推出新业务和新产品的周期已经成为争取市场份额的关键。2OSS系统 ●中国移动：经过几年的大力发展，目前各省公司围绕各专业网络，建立了以话务网管、数据网管和传输网管为主体的网络支撑系统，形成了比较完备的网络管理体系，基本能够支撑各项业务开通及服务保障功能的实现。●中国电信：继续落实和推进CTG-MBOSS的发展思路，加大了省集中化的建设力度，在梳理、分析各地市公司现有系统的基础上，逐步在各省公司建设了以综合网管和综合资源管理系统为主的综合类OSS，极大的提升了网络部门的支撑服务能力。●中国网通：由于企业组织架构以及管理等诸多方面原因，中国网通的OSS在建设模式、系统功能、技术架构等方面都比较复杂，其OSS还处于比较分散的状况，仅长途话务网管等少数系统实现了统一规划与建设。目前，网通集团与各省公司正在根据发展规划中的目标与思路，探索有自身公司特色的OSS建设模式。总的来看，OSS已经得到了国内各大电信运营企业的高度重视，并且已经成为企业核心竞争力的组成部分。但是国内OSS与国际先进运营商的OSS仍有较大差距，在建设过程中还面临不少的技术和管理方面的问题。比如，在建设综合的网管系统过程中，如何针对日益复杂的专业网络，建立一套完整、合理、规范的资源模型，如何使系统适应不断调整的组织架构和业务流程等，都是今后在建设过程中需要重点解决的问题。3MSS系统MSS系统是面向管理的支撑系统。狭义的MSS包括财务系统、人力资源系统、工程管理系统、OA系统、电子邮件系统及企业信息门户等。广义的MSS除包含上述系统外，还包括基于BSS、OSS、狭义MSS基础上面向管理需求的数据综合挖掘及分析，如企业级的运营决策支撑系统、企业工单流系统，以及包含网络资源和码号资源在内的企业资源管理系统（ERP）等。目前国内各电信运营商的发展情况基本如下：●中国移动：中国移动的MSS建设已由早期OA系统的建设升华到企业统一信息平台的建设。包含人力、财务等的MIS系统的建设在继续向纵深方向发展的同时，也不断扩展管理内容，向企业的资源管理系统（ERP）方向发展。●中国电信：中国电信从2003年制定企业信息化战略规划（IT-SP），一年后推出CTG-MBOSS规范，细化了包括MSS在内的各IT支撑系统的建设思路。经过近几年的发展，MSS逐渐向省集中方向发展，同时各省公司也正在以财务系统为突破口分别进行有关MSS系统的试点。●中国网通：中国网通自2004年制定《网通集团信息化系统总体规划》以来，发布了MSS的整体发展蓝图，系统按照北方省和南方省分别规划建设，主要包括ERP的建设、OA与门户的建设等。●中国联通：中国联通在2002年提出了UNI-IT信息化架构，2003年在山东、浙江两省分公司试点ERP系统，2005年6月已完成全公司ERP系统的集成，并且逐渐加入人力资源、网络资源管理等功能，MSS系统的雏形也在2005年6月基本完成。总体来说，国内各运营商MSS的建设基本采取集团、省两级建设模式，逐步向纵深化发展，但同时也分别结合了本企业的发展特点，进行有重点、有突破性的建设，其中突破口一般是企业的最关注的方向，如财务管理、人力资源管理等。

以上就是关于it企业组织架构全部的内容，包括:it企业组织架构、IT运维可视化有哪些作用、企业架构概述及业务架构详解等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！