etom培训.ppt_第1页
etom培训.ppt_第2页
etom培训.ppt_第3页
etom培训.ppt_第4页
etom培训.ppt_第5页
已阅读5页,还剩49页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

eTOM与SID培训第一次课程 2020年1月11日 自我介绍 李杭 神州泰岳资深BA 服务管理事业部总经理10年的电信OSS系统分析设计和实施经验 2年的其他行业信息化经验目前专注于在业务开通和保障领域 主要在流程方面 负责过的大型项目原北京网通奥运资源管理系统原天津网通资源管理系统原辽宁网通资源管理系统 湖南中烟信息化规划通过美国电子电器工程师协会 IEEE 软件工程师认证 CSDP 课程总体介绍 第一次课程内容 基础知识介绍企业架构 EA 基础知识 包括企业架构的基础知识 介绍几种常见的企业架构方法 Zachman TOGAF NGOSS架构体系介绍 包括背景 构成 eTOM SID TAM TNA eTOM和SID基础知识讲解 包括主要的过程域构成 每个域所包括的内容等时间 半天讲师 李杭第二次课程内容 深入细节深入eTOM和SID的内部 针对NOP所覆盖的领域 详细讲解eTOM的过程域和SID中的数据模型 时间 半天讲师 李杭第三次课程内容 实战演练按照网管中心的组织结构 将eTOM的域落实到每个部门或岗位的职责上 看看是否都可以覆盖全面 选择一个开通流程和一个保障流程 确定eTOM中的流程 并和现在的流程进行对比 看看是否能够吻合 时间 半天讲师 李杭 什么是企业架构 企业架构的概念是在企业信息化过程中提出来的 源自20世纪80年代信息系统的规划与设计领域 企业架构从企业全局的角度将企业管理模式 企业业务流程 企业信息资源 企业信息系统 企业信息化技术创造性的融为一体 系统地考虑与企业信息化相关的业务活动 数据环境 应用系统 技术设备以及它们之间的相互作用关系 并与企业经营 战略目标相结合 指导企业信息化工作 从IT角度来看 企业架构是企业信息化的 建造蓝图 展示了从信息系统角度的总体框架 企业IT架构是企业信息化建设最早设计决策的体现 对企业信息化具有导向和支持的双重作用 1 1996年Clinger Cohen法案的定义 EA是一个集成的框架用于演进或维护存在的信息技术和引入新的信息技术来实现组织的战略目标和信息资源管理目标 2 OPENGROUP的定义 EA是关于理解所有构成企业的不同企业元素 以及这些元素怎样相互关联 3 OMB的定义 EA是业务和管理流程和信息技术间当前和将来关系的显示描述和记录 4 MetaGroup的定义 EA是一个系统过程 它表达了企业的关键业务 信息 应用和技术战略以及它们对业务功能和流程的影响 关于信息技术怎样以及应该如何在企业内实施 EA提供一个一致 整体的视角 以使它与业务和市场战略一致 5 Microsoft的定义 EA是对一个公司的核心业务流程和IT能力的组织逻辑 通过一组原理 政策和技术选择来获得 以实现公司运营模型的业务标准化和集成需求 6 IBM的定义 EA是记录在企业内所有信息系统 它们的相互关系以及它们如何完成企业使命的蓝图 企业架构的发展 Zachman企业架构 Zachman框架是一个由行和列组成的二维结构行基于模型使用 描述者的视角对企业进行描述 最顶层的行表示企业的最一般的描述 层次越低的行对企业的描述越具体 从规划者 所有者 设计者 构建者 实现者和参与者六个视角来划分 建立目标 范围 业务模型 系统模型 技术模型 详细表达 运行功能等模型 列基于人们理解问题时经常涉及的问题的角度定义了各视角的抽象域 从数据 What 功能 How 网络 Where 人员 Who 时间 When 动机 Why 等6个方面的模型 并分别由实体 关系模型 Entity Relationship 流程 I O模型 Input Process Output 节点 链接模型 Node Link 人员 工作模型 People Work 时间 周期模型 Time Cycle 目标 手段模型 Ends Means 来表达 1987年 JohnZachman在IBMSystemsJournal上发表名为Aframeworkforinformationsystemsarchitecture的文章 提出企业架构的初步概念 文中阐述了在信息系统开发工作中对软件体系结构的看法 系统开发是由具有不同关注视点的若干层面人员共同完成的这与认识到系统开发是由不同阶段完成的同等重要 在系统开发中 考察对象不应仅限于数据和功能 还应包括地点 Zachman理论发展到今天 称之为 企业架构框架 简称为 Zachman框架 Zachman也被公认为企业架构领域的理论开拓者 现有的企业架构框架大都由Zachman框架派生而来 Zachman框架 数据 功能 人员 位置 时间 动机 规划者 所有者 设计者 构建者 实现者 参与者 范围 业务概念 业务逻辑 系统规格 组件资产 操作对象 Zachman框架说明 Zachman架构的说明当这个框架应用于企业时 它仅仅是用来分类和组织企业 在这些企业里 企业的管理和企业系统的开发同样重要 的描述形式的逻辑结构 在一个Zachman表格中 有36个方格 每个方格就是一个角色 例如商业拥有者 和每个描述焦点 如数据 的交汇 当我们在表格中水平移动 例如从左到右 时 我们会从同一个角色的角度 看到系统的不同描述 当在表格中竖直移动 例如从上到下 时 我们会看到从不同角色的角度 观察同一个焦点 Zachman框架只告诉我们应该做什么 并没有告诉我们应该如何做 这个框架已经存在了几千年 而且我敢肯定它在以后的几千年将继续存在 稍微有些改变的是我们对它的理解和怎样使用它 Zachman 使用Zachman框架的要点 每一个构架材料应该存在于一个方格中 而且只能存在于一个方格中 在一个构架材料放在哪个方格里不应该含糊不清 如果某个构架材料的确不知道应该放在哪个方格中 问题很有可能处在构架材料本身 仅仅只有当所有的表格都填满了的时候 一个构架才能被称为是完整的构架 当所有的方格都填满了时候 整个表格才有足够的材料定义系统 只有当每个方格都填满了材料的时候 才有足够的信息描述系统 从每个角色 我们现在可以称之为 利益相关者 Stakeholder 的角度观察系统的每个可能的视角 描述焦点 所以一个组织可以使用Zachman表格确保企业构架中的所有重要利益相关者之间的讨论都是合适的 表格的每列的方格都是彼此相关的 例如 Zachman表格的数据列 第一列 从商业拥有者的角度 数据就是关于商业的信息 从数据库管理人员的角度 数据就是数据库中的行和列 尽管商业拥有者对数据的看法和数据库管理员不同 但它们应该是有关系的 一个人可以遵循商业需求 并且显示出设计的数据就是被需求驱动的 如果有商业需求并没有追踪到数据库设计 那么就得想想商业需求是否与企业构架相符 另一方面 如果数据库设计的元素没有需求与之对应 我们就应该问问自己 在数据库层面是否存在不必要的设计 Zachman框架的价值和缺陷 价值确保每个利益相关着能够从描述的焦点考虑 通过把每个焦点精简到每个特殊观众涉及的焦点来提升构架材料的质量 确保每个商业需求能够追踪到技术实现 确保商业方面不会规划出多余没用的功能 确保技术组包含在商业组的规划中 缺陷Zachman框架本身并不是一个完整的解决方案 有太多的问题它都没有描述 Zachman没有给出一步一步构造一个构架的过程 在决定我们将要构建的构架是否是最好的时候 Zachman没有提供更多的信息帮助我们作出决定 就此而言 Zachman也没有给出一种途径展示将来构架的需求 最重要的 从我们的角度 尽管Zachman表格可以帮助组织构架材料 但是它在描述企业复杂性方面几乎什么都没做 TOGAF架构框架 TOGAF简介TOGAF是一个架构框架 简而言之 是一种协助开发 验收 运行 使用和维护架构的工具 它是基于一个迭代 Iterative 的过程模型 支撑最佳实践和一套可重用的现有架构资产 他帮助企业设计 评估 并建立正确的企业架构 TOGAF已被80 的Forbes50 福布斯 的公司使用 并支持开放 标准的SOA参考架构 TheOpenGroup简介TheOpenGroup 简称TOG 是一个非营利标准化组织 是一个厂商中立和技术中立的机构 致力于提出各种技术框架和理论结构 致力于促进全球市场的业务效率 TheOpenGroup下设不同论坛 制定不同的标准 论坛下设不同的工作组 WorkGroup 以确保该领域始终包含最新的科技标准 其中最有名的是架构论坛 ArchitectureForum 和SOA工作组 负责制定TheOpenGroupArchitectureFramework TOGAF 架构框架和制定SOA的相关规范和标准 TOGAF的核心 ADM 初期的目标是确定实现过程涉众 并且让它们面对企业架构工作的内容 该阶段交付基于组织业务法则的架构指导方针 ArchitectureGuidingPrinciples 并且描述用于监控EA实现进展的过程和标准 过程的阶段A用于明确EA远景 架构远景 ArchitectureVision 工件利用业务推动者明确企业架构工作的目的 并且创建基线和目标环境的粗略描述 如果业务目标不清楚 那么该阶段中的一部分工作是来帮助业务人员确定其关键的目标和相应的过程 这些企业架构都必须支持 同样是该阶段中生成的架构工作描述 StatementofArchitecturalWork 勾勒出EA的范围及约束 并且表示出架构工作的计划 阶段B用于详述关于业务领域架构的工作 架构远景 ArchitectureVision 中概括的基线和目标架构在此被详细说明 从而使它们作为技术分析的有用输入 业务过程建模 业务目标建模和用例建模是用于生成业务架构的一些技术 这又包含了所期望状态的间隙分析 阶段C涉及应用和数据 信息 架构的交付 该阶段利用基线和阶段A ArchitectureVision 中开始的目标架构 以及业务间隙分析 业务架构的一部分 的结果 在范围内 并根据架构工作描述 StatementofArchitecturalWork 中所概括的计划 为目前和展望的环境交付应用及数据架构 阶段D利用技术架构的交付完成了TOGAFADM循环的详细架构工作 如前面的阶段里 间隙分析和草案架构用作基线 由于初期对架构指导原则达成一致 建模标记 例如UML 在此阶段中被积极地使用 从而生成各种观点 阶段E的目的是阐明目标架构所表现出的机会 并概述可能的解决方案 此阶段中的工作围绕着实现方案的可行性和实用性 此处生成的工件包括实现与移植策略 ImplementationandMigrationStrategy 高层次实现计划 High levelImplementationPlan 以及项目列表 ProjectList 还有作为实现项目所使用的蓝图的已更新的应用架构 阶段F将所提议的实现项目划分优先级 并且执行移植过程的详细计划和间隙分析 该工作包括评估项目之间的依赖性 并且最小化它们对企业运作的整个影响 在此阶段中 更新了项目列表 ProjectList 详述了实现计划 ImplementationPlan 并且将蓝图传递给了实现团队 随着项目列表的稳定 重点就移动到为每个实现项目明确更具体的目标和推荐 在阶段G中 建立起了治理架构 TOGAF 和开发组织之间的关系 例如 可能由RUP和项目管理知识体系 ProjectManagementBodyofKnowledge PMBOK 的组合 或其他项目管理方法所规定 并且在正式的架构治理下实现所选的项目 阶段的交付内容是开发组织所接受的架构契约 ArchitectureContracts 阶段G最终的输出是符合架构的解决方案 阶段H中的重点转移到实现的解决方案的交付所达到的架构基线的变更管理 该阶段可能会生成为企业架构工作的后继循环设置目标的架构工作请求 RequestforArchitectureWork ADM的迭代过程 TOGAF的内容框架 TOGAF架构内容框架 提供了一个详细的架构工件模型 包括交付物 交付物的工件和架构构建块 到此 我们思考一下 我们再回顾和思考一下 我们是否可以通过TOGAF的架构框架 规划我们云南的NOP平台呢 我们是否需要一切从头开始吗 站在巨人的肩膀上 TMForumSolutionFrameworks TMForumSolutionFrameworks 概述 eTOM EA架构中的业务参考架构 eTOM是一种业务流程框架或模型 为服务提供商提供所要求的企业流程eTOM的目的是通过业务流程的实施来管理企业 帮助企业设置竞争成功的愿景 同时确保有关服务交付和支持的所有关键的企业支撑系统进行集成 eTOM的关注焦点是服务提供商使用的业务流程 流程间的关系 接口的识别 如何利用客户 服务 资源 供应商 合作伙伴以及其他多重流程使用的信息 在电子商务环境下 实现自动化以提高生产率和收入以及改善与客户的关系至关重要 eTOM的使用对象针对服务提供商和网络运营商的决策者 改进企业业务流程 实现企业自动化 业务和运营自动化的行业专家针对业务和运营管理软件的设计者和集成者 先让我们来看看 增加感性认识 了解eTOM 先了解它的业务建模原则 eTOM是一个基于活动 不是基于状态 的结构化的业务过程模型eTOM过程元素由一系列的带有控制流的活动构成一个eTOM过程包括了目标 价值 输入 输出 活动 所需的资源以及CRUD分析和RACI Responsible Accountable Consulted Informed 模型eTOM从第0层 概念层 分解到第3层 0 1 2 3 明确详细的过程和步骤不是eTOM的目的每个eTOM都与SID的ABE关联 了解eTOM 先了解它的业务建模原则 组织视角的过程层次模型 关注业务目标 价值链 环境 财务约束 开发平衡积分卡和产品线 关注产品结构 产品交付和支持过程链 企业层面数据模型 组织结构 识别企业知识 设计功能结构交付业务 建立标准参考模型 开发通用过程和体系 业务数据定义 系统结构 定义业务角色 定义端到端过程的子过程 业务过程流 从业务过程转化到系统功能 一般为跨部门流程 业务过程流 一般为部门内部流程 到岗位 业务过程流 详细到操作步骤 了解eTOM 先了解它的业务建模原则 过程分解原则 了解eTOM 先了解它的业务建模原则 实现原则 了解eTOM 先了解它的业务建模原则 过程视图 Level3实际的例子 互联网专线业务开通流程 OK 下面就开始我们的eTOM之旅吧 0级视图 三大过程域四大功能域五大实体 插入一节 关于产品 服务和资源 概念澄清 产品 服务 资源 客户视角 内部视角 产品 Product 是用来满足人们需求和欲望的物体或无形的载体 能够提供给市场 被人们使用和消费 并能满足人们某种需求的任何东西 包括有形的物品 无形的服务 组织 观念或它们的组合 面向客户的服务 面向资源的服务 产品规格 面向客户的服务规格 面向资源的服务规格 描述 描述 描述 依赖 这个模型就是业务开通系统和资源管理系统之间关联的核心实体 eTOM之旅 1级视图 eTOM之旅 2级视图 eTOM之旅 3级视图 运营域 eTOM之旅 3级视图 运营域 看看eTOM的文档 以问题管理为例 eTOM之旅 业务场景示例 新资源开发流程 工程建设流程 eTOM之旅 业务场景示例 售前流程 eTOM之旅 业务场景示例 售中流程 让我们再来看看SID模型 应用是易变的 数据是不变的 业务系统是以数据为核心的 SID的价值共同的工业和业务术语澄清项目信息需求使企业系统之间的信息交换和互操作更容易实现减少了集成的风险和费用使企

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论