管理 学会应用最佳实践并优化您的操作。

了解商业流程管理的指标

业务流程由指标控制。了解有关商业流程管理(BPM)和指标的角色,请参阅IT经理的本书章节。

下面是IT服务管理、资源规划和治理的体系结构和模式的摘录:…

为Cobbler的孩子制作鞋子,由Charles T.Betz写作。它是互联场部门的摩根Kaufmann的许可印刷;版权所有2006.单击此处以下载完整的章节“了解商业流程管理的指标”。

3.1指标:从进程到数据的网关

正如您所见,以过程为中心的思维是现代商业实践的标志。COBIT,CMM和ITIL,在他们的基础上是流程框架。他们专注于整体功能性能力和活动序列(业务流程)为客户添加价值(内部或外部)。

业务流程需要优化,并优化它们必须测量它们。指标管理的概念对于处理改进框架(如六西格玛)至关重要。流程由指标控制

有关业务流程管理的更多信息

了解Oracle认为为什么BPM系统成为游戏更换者

听听这个播客关于亮点的亮点2013 Gartner BPM Summit

看看这个视频BPM中间件平台的移动趋势

什么是度规?度规是一种度量。这是信息,不是活动,是信息驾驶活动。

信息是什么?信息是可操作的、与上下文相关的数据。所以,他们的指标就是数据。

这将我们很好地带来了下一个主要的架构观点:数据。当架构系统(定义为人的组合,过程和技术)时,“数据”的概念至关重要。框架意味着共享数据,但他们在讨论其含义方面并不遥远,这是重要的。

在将主要框架解读为需求规范时,就出现了对一致数据架构的需求;然而,到目前为止,主要的框架都对这一现实持谨慎态度,将其委托给一些未指明的其他论坛(默认为咨询公司或供应商应用程序产品的知识产权)。

趋势总是带到极端,而且业务流程管理(BPM)也不例外。BPM思维的一个不幸的极端(这种极端没有被其谨慎的思想领导者所代表,但在一些实践者中很明显)是流程就是一切,数据什么都不是的想法,或者是一些纯粹的技术问题,其考虑可以交给开发人员。

这样做的后果很明显企业架构透视:进程无法完全优化,因为过程管理的“事情”仍然不清楚过程利益相关者。在许多情况下,冗余是结果:两个进程可能是管理相同的,但是通过两个不同的名称调用它。或者 - 例如,在给定的过程上下文中,具有配置项的广泛ITIL的配置项和变更的概念,可以在给定的过程上存在。

当前的供应商环境使这种情况更加复杂,许多供应商都在销售重复的产品,这些产品使用不同的术语引用相同的逻辑概念——有时,这似乎是一种有意为之的策略,以制造产品差异化的假象,但实际上并不存在。如果没有一个健全的、产品独立的数据视角,ITRP及其实施者将成为产品供应商的人质。

视图本书需要流程和功能,数据和系统数据是最精确的。即使在口头,概念层面,它也为系统互操作性,业务规则和应用程序设计提供了基础。IT管​​理领域所需的数据是一个令人乐趣的话题。这不是不可能的,因为有些似乎感觉到 - 运行它所需的数据结构,虽然在某些方面棘手,与其他功能区域的数量和复杂性相当。

它度量

业务流程需要指标,并且在最常见的情况下,摘要使用指标来评估和指导过程称为“绩效管理”或“商业绩效管理(有时缩写为BPM,与业务流程管理混淆)。

分层度量结构是性能管理的特征和支持它的商业智能方法。指标的层次结构可能从简单的操作报告到复杂,派生的领先指标。这种方法已经在许多类型的业务活动中成立了很好的建立,现在关注现在是衡量它。不幸的是,没有与公司绩效的标准财务措施相当的IT指标套件。这是一些标准机构,学者和其他玩家的活动领域。

最成熟的商业智能软件为基于指标构建表达式提供了健壮的支持。在投资于功能有限的服务级管理工具之前,值得将其视为业务智能问题的一个特殊情况,并通过标准业务智能或数据仓库技术进行处理。

ITIL和COBIT都有广泛的指标覆盖,这本书不会复制。但是,考虑来自这些框架的几个例子。

示例1:更改管理。ITIL在“更改管理”部分中,要求跟踪追溯到变更的事件的数量。这意味着存在单独的事件和更改数据实体,可以联接在一起并概括以导出计数。这是一个明确的数据要求陈述。

实施例2:技术过时。COBIT,在获取和维护技术基础设施控制目标中,呼吁公制“of Comminal商业流程,由过时(或很快)基础设施支持。”这意味着业务流程和技术实体的存在。技术实体需要某种生命周期状态或过时的属性(依次意味着维护此信息的过程)。一个良好的数据架构师还会质疑业务流程是否应直接与技术平台绑定或首先绑定到IT服务,然后依赖于技术。

IT性能度量是一个重要且不断发展的领域;关于具体IT度量的讨论,请参阅参考资料和脚注。这里的讨论主要集中于度量管理的架构需求,包括它们基于干净的、规范化的、架构良好的数据(在大多数讨论中被忽略的一个方面)。

汇总和尺寸

大多数报告的特征是需要按照标准层次结构总结详细的数据。在数据仓库中,这样的标准层次结构称为“维度”。在ITSM和IT治理领域中,这些公共维度包括以下内容:

  • 组织层次结构
  • 组织和IT战略目标
  • 应用程序组合(卷入组织层次结构和服务级别协议或SLA)
  • 服务(在ITSM意义上,如果与应用程序分离)
  • 计划或项目组合
  • 数据主题领域(分层的,而不是关系的)
  • sla
  • 企业日历
  • 企业运营地点和层级(例如,区域和区域)

企业的数据仓库组(例如,日历和地点)中的一些将得到很好的理解;其他人将是新的。数据仓库中的一个众所周知的挑战是“不合格的尺寸”,即在不同系统上不同步的尺寸 - 例如,不同的业务行业使用的不同日历。在寻求一致性的过程中可能出现难以解决的过程和政治困难。通常,尺寸应由IT组合和架构过程(最好是数据管理指导)管理,并且应由操作流程管理事实。

应用程序组合可能是最重要和最困难的。组织可能有10个或更多不同的应用程序列表,这导致了关于IT正在做什么以及谁拥有它的无休止的困惑。

项目组合也可能是痛苦的来源。与系统一样,人们倾向于用无数不精确的名称来指代项目。项目的记录制度是什么?是否每个引用项目的系统都使用明确的项目标识符或从记录系统派生的选择列表?或者只是随意输入的项目名称,没有检查准确性?

另一个问题是“慢慢改变维度”的具有挑战性的话题。假设事件由应用程序组合和组织层次结构提出,多年来趋势报告。然后重组发生。应该如何处理?有三种方法,所有的利弊需要深入理解。

一个相关的问题是建立公共IT引用数据(通常称为“主数据管理”,或在业界称为MDM)。维度一致性是MDM的一个问题,但MDM的含义更广泛(例如,Server可能不是真正的维度,但确保有一个准确的单一列表是MDM的问题)。见图4.26及相关讨论。

通常,基于指标的流程管理控制需要仔细和清晰的结构化数据。因此,本章转向对IT管理中涉及的概念性数据结构的详细检查。

表的内容

深入挖掘企业绩效管理软件

搜索数据管理
搜索AWS.
搜索内容管理
搜索甲骨文
搜索树液
搜索SQL.服务器
关闭