运维控制中心白皮书2013年9月1日目录运维控制中心 (1)运维控制中心——概况 (3)什么是OCC? (3)OCC由什么构成？ (11)为什么客户需要OCC？ (13)提高业务连续性 (13)提高业务满意度 (14)提高IT支持效率 (14)降低运营成本 (14)OCC是如何工作的？ (15)提供透明化 (15)解决警报 (18)持续改进 (20)OCC前提条件 (21)SAP在客户端OCC中的作用 (21)OCC中的关键角色 (22)OCC 团队负责人 (22)IT运维人员 (技术 /功能) (22)负责业务连续性的质量经理 (23)负责业务流程优化的质量经理 (23)运维控制中心——概况运维控制中心(OCC)是“工厂化运行SAP”的具体体现。

OCC能够确保高度自动化及主动的操作，此举能够在降低运营成本的同时提高IT服务质量，从而提高企业满意度。

此外，OCC 能够不断推动业务流程的改进和IT支持。

运营控制中心与创新控制中心 (ICC) 和SAP任务控制中心 (MCC) 的紧密联系旨在支持这些目标的实现。

图1: OCC，ICC及MCCICC旨在助力SAP客户实现“工厂化建立SAP”。

ICC能够最大程度地使用SAP标准功能，通过端到端的集成验证保护和优化投资，并能够保证上线后平稳无中断的运行。

MCC基于SAP在全球各地的办事处，随时准备为客户提供关键支持。

图1展示了上述三个控制中心。

在OCC，一组IT运营人员负责SAP生产环境的维护。

根据环境和业务流程复杂性的差异，两个运营人员一班制（全职雇员）能够理想地进行环境的维护，通过SLA（服务等级协议）达到4小时内解决业务问题的目标。

什么是OCC?OCC是位于客户现场的IT支持团队，能够积极主动地监控SAP的生产环境（及重要的非SAP应用）。

我们建议客户在IT支持部门内设立OCC办公室。

图2显示了OCC的外观和整体布局。

图 2: OCC布局业务流程状态，IT架构部分组分，所有的关键业务，IT异常事件及警报都会显示在大屏幕上。

当问题出现时，合作伙伴和SAP可以通过视频会议进行沟通。

其他IT支持团队同样可以包含在OCC办公室。

例如，部分服务台团队能够提高跨团队沟通的效率。

OCC办公室是在SAP AGS的帮助下由客户方建立的，由客户方主导，技术团队和IT功能操作人员密切提供帮助。

图3展示了OCC的几个基本概念：∙OCC收集IT构架组件及业务流程在技术层（“应用系统运维”）和功能层（“业务流程运维”）上的监控信息（此模型由第三个基础设施层进行扩展，见图7）。

∙数据存储于SAP解决方案管理器中，并通过“集中监控”（例如OCC办公室的电视屏幕）、报表或仪表盘进行显示。

∙基于上述数据，事件管理流程将生成警报并经过预先处理。

∙持续优化流程意在改善业务及IT难题。

集中监控提供的数据（如趋势数据）对此过程予以了支持。

，有几个过程标准（如“PDCA”，“DMAIC”）可用。

对IT服务管理(ITSM)具有强大的集成和依赖性，即事件管理，问题管理和变更管理。

图3：OCC概念展示OCC能够交付的成果和带来的收益：更高的业务可用性及商业用户满意度OCC的基础架构能够全天候不间断收集和评估所有生产组件的信息。

技术和业务流程异常事件会引发SAP解决方案管理器中央警报收件箱的警报。

IT运营商（技术和功能）能够在第一时间获悉，并立即进行分析和纠正。

根据初始设置，在业务受到影响之前就可以将问题检测出来并予以解决。

至少IT支持有更多的时间来分析形势，并且在收到用户电话前已经开始对问题进行修复。

此外，报警系统可以与SAP解决方案管理器的IT服务管理模块（ITSM）进行集成，并与第三方IT服务管理工具进行同步。

与重新激活的操作方法（即IT支持等待业务用户将问题上报的做法）相比，这种积极主动的做法将带来更高的业务可用性，更佳的IT服务质量，从而提高商业用户满意度。

SAP运营工厂化能够带来更高的IT效率管理和监视活动通常是手动执行(如：“每天早上，检查事务XYZ”)。

这些活动通常可以通过设置SAP解决方案服务器警报进行自动监测替换：监控基础架构主动报告问题和异常事件（警报）。

没有警报表明不需要手动检查，所有一切运行正常。

“事件管理”这一术语描述了从警报创建至关闭的过程，见图4。

在OCC，事件管理是高度结构化的：o IT运营人员一般从SAP解决方案管理器的中央警报收件箱开始工作。

o需要做的工作（例如特定KPI的历史数据）显示在警报环境及知识数据库中。

o“操作指导”会提供详细说明，对运维人员首先要采取的分析步骤进行指导（“操作指导”是SAP解决方案管理器的向导式应用）o如果问题不能得到解决，IT运营人员可以轻松通过点击鼠标创建一个事件，并将其传递给下一级支持人员。

与ITSM的集成可作为服务台水平的双向接口的技术基础。

图 4: 事件管理流程IT运营人员能够解决不需要专业知识的简单问题，以便第二级支持能够腾出更多宝贵资源，专注于项目及持续改进。

SAP解决方案运营状态的整体透明化整体透明化：OCC能够时时报告生产环境状态，包括关键业务流程。

这可通过多种方式进行:o运行SAP的企业希望了解其核心业务流程和技术组件的状态。

SAP解决方案管理器能够提供多种方式来监测“可用性”（技术以及相关的业务流程）。

此外，未来趋势信息等关键性能数据能够在OCC显示器内接近实时地收集并显示。

o除了常见的监控器，客户可能基于其特殊的设置和配置，需要额外的监测数据。

此类需求可能是为了获取关于某关键业务接口的报错细节，或有关业务数据一致性的信息。

这些监控需求可以通过激活额外数据源，或通过使用SAP解决方案管理器提供的严格定义的扩展选项来满足。

o数据需要根据不同的接收人进行相应处理并报告方案。

与CIO相比，IT支持专家需要不同的数据和聚合水平。

为了满足所有的需求，SAP解决方案管理器提供了丰富的报告技术，从静态的PDF文件、高度聚合及互动的仪表盘、直至各级监测数据（技术以及相关的业务流程）。

很多提供的报表已经通过SAP 最佳实践的方式进行了预配置。

∙组件集成的整体透明化在当今IT世界，SAP和非SAP组件相互紧密协同的情况极为常见。

核心生产部件之间的接口成为关键业务，比如接口的可用性，数据的一致性，生产量等等。

关键是要不断监控SAP和非SAP接口和组件的集成。

OCC的的中央显示器能够从多个角度提供状态和性能整合的完整的画面。

具体例子如下：o最终用户体验监控（EEM）展示终端用户视角o PI监测展示跨系统信息流o BI监测展示报表层面o接口通道 (IC) 监测展示接口层面值得一提的是，SAP与非SAP组件都能够纳入这一画面。

例如，CA Wily Introscope 完整版，及SAP IT基础架构管理能够作为关键业务处理的一部分，为非SAP组件提供相应的集成能力。

∙持续改进业务及IT作为OCC的第二个核心流程，SAP建议设立一个不断完善的过程。

一旦启动，持续改进会对问题的根本原因进行结构性的分析及归档。

收集、优先化、测试并实施改进建议。

不断测量改善活动的成功度。

持续的改进能够帮助解决主要运行难题及面临的挑战。

根据改善项目，建议的修改可能影响业务流程或IT支持流程的设置。

这可能会带来新的“工厂化运行SAP”项目的实施。

在瞬息万变的商业世界，IT不能始终处于被动状态。

商业在不断改变业务应用，业务流程及流程配置。

这些变化会引入新的关键业务流程和相应的潜在的异常情况，因此需要OCC的检测控制。

换句话说，对当前业务的分析并不是需求变化的唯一来源。

为避免上述风险，也许除显示器之外，IT支持流程及业务流程也需进行变更。

持续改进是一个结构化的多步骤过程，市场上现已有几个改进流程定义。

比如由戴明博士推广的PDCA循环，共包括4个步骤：计划（Plan），执行（Do），检查（Check）和执行（Act）：图 5: PDCA 循环流程o计划：规划改善先后次序o执行：将第一时间的想法在现实中进行验证o检查：检查结果，并定义新标准o执行：实施新标准流程步骤的数目和背后的改进理论并不重要。

例如DMAIC改进理论或许能提供类似的结果。

然而，重要的方面是建立持续改进IT的理念。

此外，改进过程本身需要得到高级管理层的关注，从而真正解决、纠正新发现的业务挑战及难题。

在建立OCC时，SAP需要考虑将持续改进无缝集成到现有的IT支持环境上。

集成通常是基于两个层面：IT支持工具，和IT支持流程，例如：o数据取自现有的IT支持工具，以推动这一进程。

例如第三方服务台工具的事件管理数据能够帮助识别最终用户经常体验到的痛苦。

不断改进过程中所引发的变更由现有变更请求管理工具进行管理和跟踪。

o根据成熟水平，持续改进现有的事件、问题管理流程可以重复利用概念、角色、流程和程序。

因此，SAP运维作为一个整体将变得更具创新性。

通过提高效率，不但可以释放出在运维环境中需要的资源，同时也可以使IT运维团队在更短的时间段内处理更多的问题。

OCC与ICC和MCC深度集成。

ICC与OCC进行双重集成一方面，不断改进的过程可能带来新的改进项目，这一项目将由ICC进行管理。

另一方面，ICC需要考虑客户需求，以保证当新的应用进入生产环境后的顺利运维。

o在开发过程中，ICC负责执行共同开发标准（例如：编程过程中，描述该做什么和不该做什么）。

产品相关的开发标准可能会定义性能方面的额外要求。

o通过用户测试 (UAT)，ICC需要向OCC递交运维文档，描述包括新发展、系统架构、预期的数据量、重要的新批次处理作业、额外的性能要求在内的业务流程和接口。

一旦启动传输至生产系统这一流程，通常一个由项目和生产支持环境专家组成的联合小组将努力确保顺利运维。

这是通过ICC“集成验证”(IV) 的方法来实现的。

新引进的应用程序通常包括：o技术监控涉及所有的IT环境组件。

技术监测覆盖技术组件的可用性、性能、技术异常和配置。

o对关键业务流程和业务流程步骤的监测——包括关键业务交易、接口、业务异常事件和后台作业。

o根据新应用程序的类型，基本监测业务数据的一致性十分重要（例如：由于相同的业务数据存储在多个系统，新推出的ERP-CRM方案需要监测业务数据的一致性）o估计数据量、增长率、以及它们对硬件设备配置和技术能力的影响o对特殊组成部分的监测，如SAP PI/BI（包括SAP HANA场景）o通知所有IT运营人员及负责人注意警报所有上述列出的项目需要记录到适当的文档。

例如，IT架构和业务流程需要记录。

必须有文档记述IT运营人员在警报的情况下或在一个异常的情况下需做什么。

如前所述，ICC负责提供基本的文档。

这一基本文档由运维方面进行完善，并存储在SAP解决方案管理器中。

然而，为了提高工作效率，文档应该尽可能存储在相关的行动中。