KLWPQ 发表于 2020-2-4 16:10:25

IT服务管理做了什么?

两个方面的工作要做,一方面是清晰目标并梳理流程,同时利用技术手段提高效率。另一方面是为了持久的提供价值,而建设的潜力和能力机制。IT工作的目标,我总结应当有三个:一是准时交付有质量的软件项目,二是保障IT系统的稳定运行,三是及时响应服务请求。运维与保障针对IT系统的保障不是出了事以后救火的思路,而是如何让事情根本就不出现。因为定位故障,解除故障是技术问题,而实话实说,在今天这样一个品牌繁多,种类广泛的IT系统世界里。那一款独立的工具,都只是从一个层面或维度去判断故障,也就是使用任何一款系统去监测IT系统的运行状态,都会出现死角和盲区。 对于IT系统的观测,我认为既应当有集中监测的统一视角,也应当有单个领域的显微镜视角。当然这些是技术手段,不是今天的主题。今天的主题是我们应当向医学界学习,如何能够保障健康,而不是急救。也就是针对IT的隐患预防,而不是基于监测的救火处理。海恩法则指出: 每一起严重事故的背后,必然有29次轻微事态和300起未遂先兆以及1000起事故隐患。那么,如果我们能够识别这些隐患,发现这些先兆,处理这些事态,我们是否可以避免这些故障。这就需要我们有隐患和预案的积累,并且有对隐患的监测和记录,以及对隐患处理的持续跟进的闭环管理。然而我们今天的许多工作是不足的,我们缺少应有的隐患库,大多数预案是针对极端情况的,是针对已经发生了故障的,而不是针对日常隐患的。我们也少有隐患的处理记录,甚至隐患是否都被解决也无法跟进和管理。这需要IT部门做到,事前:系统化的描述IT系统的逻辑,识别系统薄弱环节,进行隐患与预案的管理。事中:能够监测到,并自动化记录隐患的发生,形成事态单,并进行自动化派发,持续跟进事态的处理。事后:对隐患发生的频率、规律、趋势进行统计。服务响应服务目录里面是一些围绕核心应用而展开的典型服务事件清单。那么服务目录的作用可以说是用来界定服务范围的,而这个范围的界定绝对不是为了推卸服务义务,而是为IT部门对这些典型服务事件的性质进行观察和分析的一个基础。也就是这些服务行为的性质是什么,该如何服务。我们建设一个系统的目的,不是要达到人告诉系统,我干了什么,然后量化工作这么简单。而是应该做到让系统告诉人,你应该干什么,应该怎么干。通过系统化的系统,来实现的也不止是流程和规范。我们的理想不是简单的实现流程(为了流程而流程,为量化而量化),如果流程和量化是我们的目标,那就完蛋了,因为它无法带给团队一种应有的状态。我们的理想是,按步骤阶段化的实现以下状态:·   首先、通过集中服务台和规范化的流程,减少多对多的混乱情况,并实现系统告诉人应该怎么干;·   然后、通过规范化服务流程,把低价值的服务外包(或交给新员工),把精力转移到核心服务上。·   再然后、通过流程化,逐步实现调度中心旁路,真正做到资源调度的定位。·   再然后、通过把服务目录与知识结合,逐步让业务用户实现简单问题的自助。·   最后一个目标是通过服务数据,找出需要改进的环节,以达到持续改进的状态。·       除此以外还需要量化业务客户的满意度,让业务部门对当前提供的服务及服务质量,从印象转变为理性。当一个业务用户提交服务请求时,他应当能够看到,这个服务将在何时为您解决,这样一个预期的结果。同时这个预期结果应当成为这个服务单处理人的预期目标,并开始计算剩余时间。用户在服务完毕以后,应当按每一个服务单填写满意度。Ahoova介绍:珠海国津软件凭藉多年的行业经验知识积累、自2009年开始自主研发基于ITIL V3和ISO20000国际标准推出的IT服务管理系统(ITSM),产品国际化程度高,面向全球市场;包括基于ITIL框架的各类相关功能模块:门户管理、请求(事件)管理、问题管理、变更管理、发布管理、配置项(固定资产)管理、知识库管理、服务级别管理、云端SaaS应用、手机端应用等等,功能齐全。整套系统以JAVA开发,B/S结构,历经多年的市场锤炼,产品精细化程度高,可维护性、可扩展性、安全性、跨平台能力、客户自定义能力等等都得到了广大客户的认可,并且可以集成其它的第三方主流企业级应用系统、呼叫中心等等。目前该产品广泛应用于海内外的金融、物流、高等院校、政府机构、制造业及IT外包商等领域,并且在不断地依据客户需求、市场要求快速迭代更新。官网链接:
页: [1]
查看完整版本: IT服务管理做了什么?