×

微信扫一扫,快捷登录!



5.4 技术要素管理

      5.4.1 概 述

    技术管理用于计划、开发和实现技术能力,完成组织战略和运营目标。技术管理是 IT 运维服务管理系统中的一部分,包含了服务工具选择使用维护、知识管理等一系列管理活动的总称。


    5.4.2 目的和收益


    技术管理的目的,是按照运维技术工作的规律性,建立科学的管理工作程序,有计划地、合理地利用技术力量和资源,保证 SLA高标准的完成。


    通过技术管理系统的建立,能够对技术管理的成效进行评价,帮助 IT 运维服务经理分析技术管理不善的原因,制定改进措施,提高服务管理水平。 具体包括:
  • 提高服务质量;
  • 减少人员流失带来的损失;
  • 降低服务成本。

    5.4.3 工具管理


    IT 运维中需要各种服务工具的支持,功能齐全、运行稳定的服务项目会大大提高运维服务的效率,降低成本,提高服务质量。IT服务工具管理包含以下四个方面:

   

   (一)典型服务工具类型

   
  
  (二)服务工具选择


      根据客户需求、服务成本等其他相关因素,判断是否需要服务工具。如果需要的话,在选择时需注意以下几点:

   (1)根据服务内容


    所有的 IT 服务项目都需要建设使用一些同类的工具,但不同的 IT 服务项目所需要的工具会稍有差别,IT服务项目经理应根据项目的特点选择重点建设的内容,如以下示例:
  • 所有 IT 服务项目:服务台、配置管理平台、ITSM 流程管理工具、知识管理工具、文档管理工具;
  • 咨询项目:知识管理、文档管理;
  • 桌面运维服务项目:服务台、配置管理、防病毒管理、补丁管理平台;
  • 数据中心场地服务项目:服务台、环境监控、闭路监控、网络监控;
  • 应用系统运维服务项目:服务台、网络监控、操作系统监控、业务应用服务监控。

   (2)考虑成本


    现在市场上有很多的工具可供选择,当由客户出资时,须根据客户可接受成本选择不同的工具(不同行业的企业可接受成本不同)。如政府、金融行业因为资产充足多以采购市场上已成熟的产品为主,要求高可用性、高稳定性、良好的技术支持;而互联网公司为节省资金多以采用开源工具为主,要求低费用、可自我二次开发。

    当是全外包的项目,需要重点考虑成本,因为此时工具的投资已经是 IT 服务项目本身的成本,内部消化。

   (3)考虑客户的期望


    根据客户关注的重点服务或者关键应用选择成熟度高、实用性高的工具。


   (4)考虑工具的技术架构以及考虑团队的技术水平


    作为 IT 服务经理,都希望所选择的工具,能够切实提高 IT 服务支持的水平,能够持续满足在管理制度建设方面的发展需求,服务管理平台类的工具应该高于当前的项目管理需求而建立。

      基于 B/S 结构的工具易用性较高,不但在访问方式上灵活,切合当前的互联网时代,同时在它同一界面中包含尽可能多的功能和信息,操作简单。所以,在工具选型中应考虑尽可能地选择 B/S架构的工具。

      同时应将 IT服务团队的自身的技术水平列入考虑范围之内,团队技术水平高可选择开源等需要大量维护开发工作的产品。

   (5)要考虑工具的通用性和集成性

    除非一个项目十分特殊另类,一般在考虑工具选择时要考虑工具的通用性。如选择 ITSM 流程管理平台要考虑工具对ITSS中所定义过程的支持力度,以及对项目现有流程制度体系的支持力度。工具对流程制度体系的支持越高,工具带来的效益越明显。

      IT 服务管理,离不开软件工具的集成性,这种集成性主要体现在:服务管理工具与项目管理工具的集成,服务管理工具与监控预警工具、配置管理工具的集成,以及与项目相关的办公自动化系统(OA)的集成性。

      以服务管理平台工具为例,如果能够自动集成网络监控系统采集的告警或者故障信息,同时派发工作任务单并跟踪服务水平协议,那么会有效地提高 IT服务效率。

   (三)服务工具本地化应用

    当服务工具选型结束后,就进入到应用阶段,象所有的软件一样,服务工具也按照下面通常的流程进入应用阶段:
   (1)采 购

      按成本归属,分别由客户进行采购,或者按 IT 服务公司的采购流程进行采购。作为 IT 服务项目经理需要跟踪采购的进程,督促工具按计划及时到位。

   (2)客户化开发及 FAT测试

    制定详细的客户化开发及工厂验收测试(FAT)计划,进行客户化工作;完成工具与 IT 服务项目管理体系的切合,只有切合度高的管理工具才是可用的管理工具。建议由 IT 服务项目经理自己做功能需求整理工作,并全程进行开发质量把控。

    在客户化阶段要根据工具的重要程序,在安装部署设计上做冗余,如监控系统和服务台。具体根据项目成本、现场实际情况采用双机热备或者集群等技术。

       此阶段应有以下文档:
  • 需求稳定:说明客户化的详细需求;
  • 开发计划:客户化开发的计划及人员安排,进度跟踪;
  • 验收测试计划:服务提供商验收测试的计划,人员安排,测试用例;
  • 验收测试报告:包含功能完整性,安全性,与流程体系切合度等内容;
  • 工作安装部署手册:工具的安装部署手册。

   (3)生产安装部署及用户测试(UAT)

    制定详细的生产安装部署及用户测试(UAT)计划,根据《安装部署手册》按计划在开发测试环境进行安装部署,安排客户及内部员工进行用户测试(UAT),及时修改 BUG,最终形成功能齐全、稳定的版本准备生产上线。

      此阶段应有:
  • UAT 用户测试计划:UAT 测试计划及测试用例;
  • UAT 测试报告:对工具的整体是否适合投入使用做出结论,此报告必须有客户的确认;
  • BUG 修改及跟踪:UAT 期间 BUG 内容及修改负责人,时间及进度跟踪。

   (4)上线发布

    制定上线发布计划,并要得到客户的认可,进行初始化,上线发布,正式投入使用。

   (四)服务工具使用中维护

    保持稳定性,按生产系统管理

    IT 服务是离不开 IT 服务工具的,作为 IT 服务项目经理要将 IT 服务工具的稳定性的重视程度提高到足够的高度。现在 IT 服务工具合理清晰的产品体系架构与 7*24 小时不间断运行的技术保障,是实现 IT 服务稳定性的最佳保障,IT 服务项目应将重要的 IT 服务工具当做生产系统进行维护,不轻易移动,关停重启服务,所有的改动都走严格的变更流程进行控制。

    挑选合适的员工进行日常维护(工具维护岗)

    在对工具进行日常维护时,要做到人驾驭工具、人监督工具,不能让工具牵着人的鼻子走,IT服务项目经理应尽可能地安排项目中合适员工专职负责工具的维护和改进,设立专职的工具维护岗 位;不建议将工具的维护全部交给软件供应方。

    适时的改进

      每一种工具都不可能 100%的适合各种 IT 服务项目,作为项目经理需要根据自己所负责项目的特点,并及时跟踪客户的需求变化,对工具进行长期、分阶段的持续改进,以适应项目发展的需要。

   (五)服务工具的淘汰

    服务工具同样具有生命周期的概念,所有的工具都会因各种原因进行最后的淘汰动作。工具淘汰的原因一般有两种:
  • 技术过时落后,有新的工具可以代替;
  • IT 服务项目终止。
    当 IT 服务项目终止时,往往需要将工具移交给接手服务运维的另一方,可能是客户自身的团队,也可能是第三方服务提供商。此时应做以下工作和注意事项:

    工具由客户投资建设

      收集工具管理过程中所有的文档,备份数据和软件拷贝,按照同客户以及第三方协商确定的交接计划进行交接。

   工具由 IT服务项目提供方投资建设

      如果工具是服务项目提供方自己投资建设的,IT 服务项目经理需计算成本,并向客户报告。

       当客户接受时,由客户决定是客户自己买入还是第三方买入。收集工具管理过程中所有的文档,按照同客户以及第三方协商确定的交接计划进行交接。

    当客户不接受时,制定报废计划,向公司汇报,收集工具管理过程中所有的文档,备份数据和软件拷贝。当公司决定将工具免费送给客户,与客户及第三方进行交接;当公司决定收回工具时,在项目撤出前,从生产系统上删除工具系统。

   (四)可能产生的风险和控制

      在 IT 服务工具建设、维护使用中经常遇到以下的风险:

    采购时资金不足

    由于各种原因,多数企业在工具上的投入往往不够,因此在采购市场上好的产品时,会出现资金不足的现象,项目经理可考虑适当的降低标准,根据团队的技术能力采购可二次开发的产品,或者采用开源产品进行自我开发。

      工具单一节点无冗余,稳定性差

    关键的工具应考虑多套产品同时使用,相互备份。如监控类系统,单一系统状态下误报情况较多,且一旦当前系统无法使用就完全失去了监控工具;而多套产品同时使用可提高准确性、可用性。

       技术力量不够、带来的性能问题、安全性

      技术力量不够,带来的性能问题、安全隐患,所以建议在工具选型时,IT 服务项目经理应尽可能的让技术人员参与,听取技术人员的建议,并挑选技术较高的员工做工具的维护。

      与项目实际情况脱离

      服务管理平台类工具最容易产生此类风险,在建设完成后,因管理工具和实际情况差距较大而失败的案例很多,因此在建设服务管理平台类工具时,要特别注意和实际情况的切合。

      缺乏长期改进,久而久之无法适应项目发展需要

    工具需要长期、分阶段的持续改进,才能适应项目发展的需要。不对工具进行改进,工具会越来越和项目实际情况脱离,导致最后无法使用,甚至再次采购,浪费人力、财力。作为项目经理应从一开始就重视工具的持续改进工作,派专人负责,定时检查。

    5.4.4 知识管理

    概 述


      知识管理(Knowledge Management,简称 KM)是网络新经济时代的新兴管理思潮与方法,管理学者彼得·杜拉克早在一九六五年即预言:知识将取代土地、劳动、资本与机器设备,成为最重要的生产因素。受到 90 年代的信息化蓬勃发展,知识管理的观念结合网际网络建构入口网站、数据库以及应用电脑软件系统等工具,成为组织累积知识财富,创造更多竞争力的新世纪利器。

      所谓知识管理的定义为,在组织中建构一个人文与技术兼备的知识系统,让组织中的信息与知识,透过获得、创造、分享、整合、记录、存取、更新等过程,达到知识不断创新的最终目的,并回馈到知识系统內,个人与组织的知识得以永不间断的累积,从系统的角度进行思考这将成为组织的智慧资本,有助于企业做出正确的决策,以适应市场的变迁。
   
      知识管理的核心责任就是能够将运维中产生的知识发现并通过记录的方式固化下来,然后通过教育、规定强制等手段让知识推广使用,从而不断提高运维团队的运维技术水平。

       从概念上知识分为隐性知识(Tacit Knowledge)和显性知识(Explicit Knowledge)两大类。隐性知识是高度个性化而且难于格式化的知识,主观的理解、直觉和预感都属于这一类。显性知识是能用文字和数字表达出来,容易以硬数据的形式交流和共享,比如编辑整理的程序或者普遍原则。

    目 的

    知识管理流程目标是将运维生产过程中产生的各类信息所包含的知识能够最大限度地提取、保留,通过评审后加以应用。包括:
  • 实现知识共享;
  • 实现知识转化;
  • 避免知识流失;
  • 提高运维响应速度和质量;
  • 挖掘、分析 IT 应用信息。

    活 动

    知识管理包括了 IT 服务项目经理对知识的获取、共享、保留(归档)、配合企业知识库管理员入库。
   
   

       知识提取和获取的方法及途径

    IT 服务项目经理首先要考虑本项目需要哪些知识,能从哪些方面获取。将项目相关知识进行分类,可能根据以下方面进行分类:
  • 根据知识的覆盖使用范围分类;
  • 根据知识评分来分类;
  • 按照浏览量来分类;
  • 知识地图同样是知识分类的好方法。

      IT 服务项目常见知识分类示例如下:
  • 项目相关业务知识;
  • 项目相关已知问题(故障)解决方案;
  • 运维相关技术跟踪;
  • 其他知识(消防知识、逃生知识等)。
    IT 服务项目知识的提取和获取一般是在项目内部和项目外部两方面进行的。

    内部提取:日常运维故障典型解决方案的总结、积累,如在建立流程体系时规定必须从已知问题的解决方案中提取知识,这也是 IT 服务项目最实用的知识。

      外部查找:与其他类似项目进行知识共享,在互联网上查找,跟踪供应商发布的知识等。

    知识共享的方法和方式

    项目知识共享分对内共享和对外共享两种。对内共享是要求项目组内成员积极主动地将自己的知识共享给其他员工;对外共享是与其他项目组或者其他公司进行知识共享。知识具有保密性的要求,IT 服务经理要制定知识共享制度,对各种知识设定保密级别,根据保密级别在共享时要进行审批活动。

    知识的保留、归档与入库

    在知识保留、归档及入库时,先根据知识的分类进行分级工作,从以下两个角度进行知识分级,具体的级别可根据实际情况自行定义:
  • 业务重要性角度;
  • 整合、完整性角度。

      知识的归档与入库,建议采用统一的知识管理工具,市场上常见的 ITSM 管理工具也都有知识管理的功能,也可以使用 SVN(Subversion,版本控制系统)、TRAC(开放源码网页界面专案管理、缺陷追踪软体)、WIKI(一种在网路上开放、可供多人协同创作的超文本系统)等开源工具来管理。

    知识入库时应按照分类进行保存,如可以按 IT服务运维对象(网络、主机、数据库、应用)进行分类,也可以按业务进行分类:桌面、邮件、业务系统(如银行核心系统、卡系统)等。

      知识入库时要进行审核性工作,以保证知识质量,做到有用的知识才会进入知识库。同时知识入库后要定期进行知识的评审,看看哪些知识需要更新和整合,哪些知识已经过期,以保证知识的有效性和提高知识的整合度。

      作为 IT 服务项目经理在知识的保留、归档、入库阶段,一方面要重视知识管理工具的建设,一方面要积极协调技术专家一同进行知识的入库审核。

    知识的评审

       IT 服务项目经理应定期组织技术专家团队对知识库的知识进行全面的评审。评审的内容涉及以下方面:
  • 时效性:现阶段是否还有效;
  • 完整性:是否汇总完整,能否与其他知识条目合并;
  • 正确性:知识的内容是否正确。
    评审后应出《知识评审报告》,并根据评审的结果,对知识库中的内容进行更新、删除、合并等维护工作。

       知识的评审工作也是知识重新获取的一大来源。

    关键成功因素

      在知识管理中,一方面是从流程制度考虑:
  • 知识识别与分类是否准确;
  • 知识管理流程是否制定,是否合理。
    另一方面是设置知识使用的衡量指标进行考核,来判断知识管理的成熟度:
  • 知识积累的数量;
  • 知识的利用率;
  • 知识的更新率;
  • 知识的完整性;
  • 各类知识的比重;
  • 知识新增数量与事件、问题发生数量的对比关系。

    可能存在的风险和控制

    知识私有化观念(主动性)

    在知识管理中最容易出现的情况是员工不积极提交知识,员工不愿意和其他员工共享自己所拥有的知识。此时 IT 服务项目经理应该考虑采取措施提高员工提交知识的积极性,如对积极提交完整性高核心知识的员工进行奖励,激励员工共享自己所拥有的知识;也可将知识提交、共享与绩效考核挂钩;最好是建立起良好的团队文化氛围,保持员工的积极性。

    知识共享的风险

    在实际的操作过程中,知识共享确实存在着风险,其中主要是可能会出现核心技术的泄露。所以应做好知识(信息资产)的保密性工作,建立共享安全制度。另一方面也会存在其他部门、项目组不愿意共享知识的现象,IT 服务项目经理应积极与对方进行沟通。

    知识管理工具使用风险

      知识管理工具上线运行之后,员工却不能经常性地使用系统,也不能对知识管理系统进行维护,从而难以保证知识管理系统中知识的数量和质量,在“恶性循环”中使知识管理系统逐渐成为一个华而不实的摆设。所以在管理工具的建设期,IT服务项目经理要考虑工具的易用性。

    持续性风险(知识的有效性、时效性)

    在初始知识提交后,长期没有再评审、再次更新修定,知识甚至已经过时或者随着环境改变而不再正确,但仍保留在知识库中,造成知识的可用性和准确性降低,久而久之,员工会越来越不愿意使用知识系统,知识管理面临失败。因此,IT 服务项目经理要重视知识的定期评审工作,保证知识的可用性和准确性。

    隐性知识很难转化成显性知识

    显性知识可以理解成书面化的文档,隐性知识就是存放在每一个人头脑中的经验和体会,要让每一个人头脑中的这些经验和体会都写出来的确很难。因为平常每一个人工作都很忙,如果非要让忙了一天的员工能在工作时间内静下心把自己的经验和心得写出来,这对绝大多数企业和员工来讲是不现实的。

    很多知识管理项目的一个假定条件就是每一个员工都会把自己的头脑中的知识主动拿出来,但是事实并非如此:而是员工没有这个时间也没有这个动力,如果这个假定条件不成立,那么知识管理项目成功的基础就没有了,所以这个困难必须面对而且必须解决好,不然知识管理系统最终将成为一个摆设。

    解决方法是让知识管理系统完全融合到员工日常的工作中,比如客服服务人员每天处理客户的问题就在知识管理完成,这样就可以让员工一边工作一边积累知识;把知识管理融入到项目管理、客户管理、流程管理、人力资源管理,这样能够真正有效的让员工一边工作一边把知识和经验积累到系统中来。

*************************************************************
    返回到首页 《ITSS认证IT服务项目经理培训教材》_试用版连载http://www.ITILxf.com/thread-36762-1-1.htmlITSS、培训、服务、资格、评估、ITSS培训师、ITSS评估师、实施ITSS、ITSS符合性、ITSS服务工程师、ITSS服务项目经理、ITSS标准、ITSS咨询、ITSS工具、IT服务监理、ITSS体系、ITSS服务质量、评价、指标、运维、治理、咨询、ITSS出版物、ITSS产品、服务监理工具、服务质量评价工具、标准符合性评估工具、服务管理工具、服务治理工具、系统监控工具、辅助决策分析、服务支持管理、基础设施监控、ITSS基础教材、ITSS标准、ITSS服务人员培训教材、标准化、专业化、人员(People)、流程[1](Process)、技术(Technology)和资源(Resource),简称PPTR、规划设计(Planning&Design)、部署实施(Implementing)、服务运营(Operation)、持续改进(Improvement)和监督管理(Supervision),简称PIOIS、服务交付规范、资源要求、外包管理、服务交付、分类、代码、服务指南、通用要求、指标体系、ITSS落地实践交流-QQ群:21542747


本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x




上一篇:《ITSS认证IT服务项目经理培训教材》_试用版_20110311-IT---IT服务运营(3)
下一篇:初创团队招募优秀合作伙伴
tom615

写了 325 篇文章,拥有财富 4189,被 6 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

返回顶部