本帖最后由monicazhang于2015-9-2416:59编辑
20150924淡然 续上
2.3IT运维现状以下从管理层、IT运维支持人员、相关用户等几个方面来总结本次访谈，总结的内容完全摘自深圳某公司相关工作人员的访谈记录。 2.3.1管理层对IT服务管理的看法及目标nIT服务管理管理目标
流程化处理IT服务管理工作，提高工作效率；规范和标准化沟通渠道和IT服务管理流程从而保障电信的相关业务得到更好地支撑；完善组织自身的发展，有前瞻性地规划组织的发展方向和进行相关的技术管理储备；- 为组织/部门的相关用户提供高质量的IT服务，提升组织/部门的服务形象；ITSS考试
n衡量标准
- 目前有一些考核、考量办法，但是没有较为准确的、客观的IT服务管理衡量数据；
n管理层看到的主要问题 o人员  信息的沟通不够，导致管理层的意图执行人员理解不清楚，执行人员又没有及时将执行的情况及时反馈； 大部分员工对工作比较敬业，但工作的分配不合理，没有准确的量化数据来反映工作成绩； 没有技术储备，新员工成长较慢，影响了工作效率和服务满意度； 有制度难以执行，没有实质的方法来考核员工的效能，致使流程和制度仅仅局限在纸面上； 由于资源不够和较大的工作量导致响应速度不够及时； 人员流动太快，尤其资深员工的流动导致技术流失严重，同时也导致人力资源匮乏； 受一些客观因素限制，对员工的激励手段不够； 员工工作太被动；
o流程 没有统一的IT服务管理受理界面； 事件的处理过程没有形成规范； 在事件/需求处理过程中没有形成严格的闭环管理； 不能够及时了解不同组的工作情况，对运维情况无法一目了然，不能够清楚地知道员工地工作情况和工作状态； 有很多成文的规章制度，但是缺少方法和工具确保制度的执行； 缺少对流程有效的监控和跟踪；
o工具 需要进一步完善中心协作工作平台，保障相关IT服务管理的流程能够得到体现； n管理层希望通过本项目达到的目标
o人员 采用什么方法可以提高工作人员的服务意识，执行规范流程管理； 如何能够提高工作效率； 对业务/运维统一受理员的技能和工作职责提供建议； 怎么样能够缓解人员流失对IT服务管理带来的负面影响； 如何定义清晰的人员角色和职责，并明确相关工作人员的考核指标； 为了实现IT服务管理，提出对目前新技术开发中心组织架构的建议； 如何在当前人力资源的情况下，优化IT服务，提高管理水平，提高用户满意度；
o流程 在业务/运维有统一受理方面有所建议； 如何规范沟通渠道和事件处理流程，提高响应速度和用户满意度； 如何能够将IT设备实现清晰的管理； 找出现在流程的差距，规范流程，提高服务质量和工作效率； 采用什么样的方式能够使流程管理透明化； 确定可持续发展的IT服务管理的目标； 清晰地定义服务内容；
o工具 采用什么工具可以协助人员可以更好地管理； 目前的工具方面有哪些欠缺； 怎样的工具可以规范流程，可以促进员工的工作，可以使被动的工作变为主动的工作；
2.3.2IT相关使用人员的看法和建议o看法 §流程 后台（中心）重要需求及时完成率不够； 故障维护扣分很严重，对问题处理不够，事件量太大； 除了核心系统的较好的故障申报，一些小的系统的保障流程不完善、保障人员不固定； IT服务的成本化，需要建立成本的意识； 核心业务系统可用性还好，网络末梢会出现一些问题； IT的可用性和支撑约70％可以满足市场需求； 从整体业务上来说，55％的满意度； 很多时候的故障和业务需求不知向谁提出； 现存IT服务不能支持市场的增长，发展滞后； IT服务中断对业务影响非常严重； 对现存的IT机制在排除类似事件的再次发生方面的自信心较弱； 只是在新系统上线或重大变更时提供培训；
§组织/人员 技术部门需要具有完善的业务知识，研发中心业务专家太少； 业务部门受理室的技术流失严重，同时培训不足； 受理热线只是话务员，只能转接电话，无法及时得到业务解释和故障处理； §技术/工具 业务系统的架构需要更加灵活，以适应市场的需要； o建议
§流程 在故障维护方面能够分成优先级别； 需要提高IT成本的意识，并约束相关需求提出部门； 加强网络末梢的维护工作； 业务/故障统一受理台，应该覆盖中心的业务系统、故障维护； ITSS认证80％的事件应该在受理台解决； 明确服务热线的范围，并进行推广；
§组织/人员 技术部门需要具有完善的业务知识，需要更多的业务专家； 希望受理热线不是话务员，提高在线解决问题的能力； 希望能够有不间断的部分部门（如，业务部门处理室等）培训；
2.3.3技术工程师的看法和建议n研发室 v看法
§人员 人员流动快，资深员工的流动导致技术流失严重； 新的员工业务成长周期较长； 有相应的员工考核指标，但是数据的准确性无法控制； 对第三方的服务没有量化指标，没有质量控制； 有热线，但是由于不作任何预处理，所以没有起到应有的作用； 用户没有问题受理意识，直接打电话给相应的工程师，或者直接找相关管理人员； 有些员工只是针对某个单一需求的实现，没有真正对需求的数据和意义负责，如，有可能数据是不正确的，或者是会影响到其它业务；
§流程 靠个人关系取得协作，导致某些事件处理无法及时； 在服务清单中有一些归类，但是不是很科学，比较乱，比较模糊； 对事件处理过程的记录较分散，没有控制； 对事件分级，目前只有A/B/C三类，太粗略，实用性不强； 在处理事件时，没有规范的流程，所以在事件实施质量上和用户满意度上无法控制； 在故障处理、运维、需求实现等方面没有进行关联管理； 配置项没有确定，没有配置管理； 在软件版本控制和原代码管理方面都较弱； 业务部门不能够很好的理解IT部门，没有IT成本的意识； 业务需求太多，而且都很急； 临时需求和业务故障太多，打断原来的计划，降低软件质量； 由于太忙，所以很多需求或故障调整都不能走流程或不能完整走流程； 事务太多：临时开会，与业务部门沟通：需求分析、数据问题（更多的客户抱怨）、地面局的咨询（软件的使用法），项目建议书不断修改，包括：需求文档的反复及功能反复； 需求的反复性较为严重，50％的需求会在需求分析时出现反复，10％的需求会在功能阶段反复； 在软件测试方面很弱； 没有统一受理的机制，很多时候直接接到各种服务请求电话，由于担心破坏关系，只能自己受理。 对于重复发生的故障或事件，没有很有效的回顾和分析机制； 业务需求的质量需要控制； 前台对业务使用不清楚，研发人员需要不停的解释； 经常需要中转其它系统（不在维护范围内的）的故障，很难处理，自己不清楚，但是又不能将电话直接转接过去；
§技术 中心协助平台不能起到流程协助的作用，很多时候，只是记录了事件的流水帐，提供报表； 没有知识库，新人的成长周期很慢； 需要IT部门和业务部门建立良好的沟通； 对于很多业务的运行没有有效的监控工具； v建议 控制业务需求的质量； 由被动的IT的管理提升为主动的IT管理； 提高IT服务质量，提高用户满意度； IT管理的流程化，规范化和标准化，改变目前无序的管理现状；
n运维室 v看法 §组织/人员 人员流动和技术流失的现象严重； 运维室和人事部门在人力资源方面存在分歧； 没有界定热线技术人员，现场技术人员；
§流程 流程混乱，导致很多事件都堆积在运维部门； 桌面和网络末端的管理需要作为工作重点，提升IT部门的形象； 没有定义明确的运维服务清单； 对厂商的依赖较强，同时没有有效的对厂商量化考核； 事件分A/B/C三类，但是实用性不强； 没有完整的闭环流程； 运维工作缺乏规划，在任务的逼迫下，只能做救火员； 对用户没有规划性培训； 对于系统的变更，只有很重要的系统，才会有评估、确认等流程； 事件的紧急程度没有和解决时间要求联系在一起； 没有规范的事件/变更类型的分类依据； 因为管理流程太乱，致使投诉太多； 没有知识积累，相关资料不够； 电话处理和派单应该更加规范； 内部用户报障的渠道：运维室报障手机、运维室受理电话（没有固定接线员）、中心内部及时通、中心受理热线、打个人手机、通过平台报障（不到总量的1％）； 有时工作太忙，导致答应客户解决的问题无法及时解决，引起投诉； 没有配置管理，无法直接判断机器的位置、配置、历史错误等信息等； 业务处理室的系统管理人员技术水平太低下，无法过滤较为简单的故障；
§技术 系统可用率/故障及时解决率/故障发生率/性能指标，数据不准确； 从中心协助平台上获取的员工相关考核数据不准确，且指标项较弱； IT管理工具的配合不足，如桌面管理系统、补丁管理系统等； 数据分析方面的工具不足，不能够分析运维事件的趋势和规律； 没有有效的数据库、系统等监控手段，该方面的维护都很被动； 员工只会在中心协助平台上记录重大事件的一些简单信息； 中心协助平台没有达到协调运维流程处理的目的； 没有灾难备份/恢复；
v建议 需要规范员工作业，尽可能使故障处理技术少量流失； 其它业务方面的运维已经比较成熟，需要通过桌面管理来提升IT部门形象； ITSS培训建立知识库，确保技术资料的完整； 增加IT管理的辅助工具，如桌面监控、系统和数据库监控等； 希望有技术背景的热线人员；
| 
转播
分享
淘帖
()