引子:夜归人所在的公司是一家中等规模的证券公司。相对同业而言，我们公司算是比较早关注ITIL，并有实际持续行动的证券公司之一。从最初自己看书、内训等一系列准备措施一路走来，我一直是我们公司这个项目的核心成员之一。为此，我个人倾注了相当大的精力。目前，我们公司的ITIL项目正在实施，在实施过程中，我不断总结项目中的得失，希望能与同业分享我的心得，共同提高和成长。 一般而言，证券公司在实施IT项目时，都喜欢“交钥匙工程”，以节省自身的人力消耗保证足够的人力资源投入到重要项目和运维工作中去。从我个人的研究和心得来看，实施ITIL项目应当极力避免用以前我们实施软件和硬件建设类项目的管理方法，基本完全依外部力量。 一方面，这是因为ITIL引入组织实际上是一次管理性的变革，往大了说是管理理念、工作方法和部门文化甚至是企业文化的变革。从技术思维向服务思维转变，不仅影响了相关人员的行为，更重要的是改变了参与人的意识和思考方法。外部力量对这些是无能为力的。另一方面，咨询人员在有限的时间里，很难做到彻底了解企业的方方面面。所以，实施ITIL项目应当投入足够的内部资源，积极配合外部力量，甚至内部应当有强有力的推动力量。 我在项目实施中进行了总结，本人认为以下几方面在项目实施前或实施时应当重点注意。 1.全面认识ITIL 在决定实施ITIL项目前，我们应当全面认识ITIL。一方面，ITIL不可能像某些宣传说的那样可以包治百病，只能解决大部分由于流程管理缺失导致的问题，由于IT组织深层原因导致的问题是无能为力的，有些工作内容有可能是流程不能涵盖的。另一方面，ITIL是个实践总结成而来的框架，在不同环境中的具体实务操作需要自我丰满，这个自我丰满过程咨询公司可以帮上一定的忙，但是他们所起的作用有限，但是没有他们等于行动不便的人失去拐棍。再者，ITI项目实施完毕，并不等于服务质量和运维风险都得到了控制或改善。关于这些问题，我想任何咨询公司都会在交流中回避这些问题，但是作为业主方必须对此有清醒的认识。 那么，是否ITIL就是一个基于商业利益的标准噱头呢？我个人是这样看的：诚然三大厂商围绕ITIL开展商业活动，但是ITIL作为一个知识框架的价值是不用质疑的，至少也是目前解决IT服务质量问题的最重要最被认可的方法之一；按照它的流程去做，跟日常运维流程有关的需要关注问题大部分都得到了关注，尽管得到了关注并不代表就解决了所有问题；不能解决问题的责任不应当归于ITIL本身，而在于对自身问题认识不清，在于自身缺乏解决方案，在于自身的执行力，而不再流程本身。 ITIL版本的更替对大型企业的IT服务部门有一定的影响，但是大部分企业仍就适合从V2开始。原因比较简单，因为V2内的流程我们可能成熟度依旧较低。 2.知识储备 ITIL是一个比较复杂的专业知识领域，同时也是一个解决问题的工具。我们需要使用这个工具解决我们自己的问题，当然***能掌握这个工具。所以，在项目实施前应当提前做好知识储备，从我个人经验来看，一个组织在这方面应当提前一到两年。 2.1组织内部至少一人基本掌握整个知识体系 IT组织内部有人基本掌握整个ITIL知识体系，一方面降低项目过程中的知识沟通障碍，一方面组织自身有知识方面的判断能力。就知识深度需要来看，ITIL FOUNDATION的培训肯定是不够的，这个人应当对ITIL本身有足够的热情和学习时间投入。在一定时间的知识准备后，这个人要有质疑咨询方的基本能力。当然质疑咨询方并不是破坏他们的权威性，而是不能完全跟随咨询方的商业利益，在为组织引入ITIL时充分考虑到与企业现状的结合。咨询师非常熟悉ITIL的理论，也有丰富的咨询经验，但是最了解自己的IT组织的人肯定是IT组织内部的人。有这么一个人，是世界范围内***实践和组织实际情况真正良好结合的保证措施之一。这个人可以把自己组织内部的问题和盘向咨询放托出，并就解决方法提供选择建议。 2.2全员具备一定的ITIL基本知识 IT组织应当极力做到所有员工了解一定的ITIL基本知识，以满足项目价值理解和沟通需要。一方面，在调研访谈时，在流程设计时，在工具实施时，有大量的涉及ITIL专业知识的沟通，如果不能保证信息理解的一致性会使沟通效果大打折扣，延缓项目进度，甚至使项目质量严重下降。另一方面，不能全方位的了解ITIL的基本知识，就无法真正了解ITIL项目的价值，更无法了解实现这些价值需要哪些努力，至于执行效率的保证就更加有难度了。有些单位可能由于培训政策或项目投入的关系，可能难以做到。我个人认为，至少应当保证IT部门的管理者、有关TEAM LEADER、流程经理和核心的流程执行人员受到培训。有这些人存在，有助于形成良好的项目实施环境。 3认真拟清项目收益和困难 项目收益是项目参与人参与项目的动力。根据角色拟清项目收益，加以充分宣传，可以有效推动项目，使项目取得最大限度的成功。相反，这个工作不充分可能会使项目面临难以短期克服的阻力，甚至使项目无法立项或执行失败。根据我个人的经验，项目收益不能完全照搬厂商或咨询方的宣传，应当总结务实的收益，充分联系和结合行业、企业、IT组织和参与人的当前困难和重点关注事项。 我认为，在做项目收益分析时至少要包含如下方面： 3.1个人的 项目工作和后来的流程执行工作最终会落实到每个项目参与人身上，而这些具体任务执行的效率和效果，在管理成熟度并不高的国内企业里纯粹依赖执行力是非常危险的。所以，要想办法提高项目参与人的积极性，尽力推动他们从被动向主动转变。毫无疑问，从08年开始，ITIL/ISO20000已经是一个家家券商CIO都在关注的热点。热点归热点，但是咨询行业对证券业的案例积累，证券业本身的人才和知识积累都刚刚开始。面临新的职业发展方向和个人职业价值的提升机会，任何有点职业追求的IT人都不会放过。个人层面的收益拟定工作就是帮助参与人充分认识到参与ITIL项目对他们个人职业发展的重要意义。 3.2部门的 部门的收益总结我觉得是最重要的，因为IT组织往往是ITIL项目的企业内部发起人。收益总结过程和项目目标概要设定有很大的相关性，也是项目发起的主要理由。在IT组织内部对ITIL的认识肯定存在先后和深度差异的问题，结合IT组织的突出问题和发展方向总结出的收益容易取得大家的共识和共鸣，也就容易形成项目过程中的组织凝聚力。事先分析面临的困难也好有一定的准备，并且做好应对措施，参与人也有一定的心理预期。 3.3企业的 我不太了解世界范围内的ITIL项目发起情况，但是对国内证券行业的ITIL项目有一定的了解。在证券行业大多是IT组织内部人员，基于规范部门工作，甚至直接是降低运维风险的目的来发起项目的。所以，有一些清晰、易懂、实际、能说服公司高层的收益是项目立项的根据，用一套冠冕堂皇的商业说辞太苍白了，显然是不够的，毕竟CEO们都希望支出是“投资”，而不是无谓的开销。同时，事先的困难说明也是服务质量可能短期下降的提前释放。 4.意识教育 大部分人都习惯于按照过去的模式生活和工作，潜意识里抗拒改变自己的生活环境和工作环境。由于意识决定行为，只有意识上接受了变革，有主观的改变意愿的可能，也才会有改变的动力，意识才有可能转变为主动性改变行为。因此，意识改变是第一关，ITIL这类管理变革类项目首先需要变革的是参与人的意识。 从我的摸索的经验来看，可以在项目启动前一年左右，用如下方法来推动IT组织成员的意识转变： 4.1内部ITIL培训。 培训内容主要是一般知识了解、ITIL项目收益等***性的内容为主，可以通过项目案例来让参与人员认同项目。 4.2场景游戏。 在游戏中加深对ITIL价值的认识。这个方法目前广泛应用可能还存在一定的难度，因为目前的游戏大多是厂商设计并且系统依赖较大。希望厂商们能开发一些适合普通IT组织在内部能实施的游戏。 4.3知识竞赛。 制造学习ITIL知识，用ITIL知识，解决自己问题的良好的氛围。有了一定的时间积累之后，只是准备和意识准备会让项目实施水到渠成。 4.4半官方的研讨或沙龙活动。 纯企业官方的活动容易让大家认为是变相的加班，纯私人的资源无法保证，所以企业资源支持引导，个人***活动的形式容易被大家接受。研讨的内容可以是基本理论的学习，也可以具体工作任务和ITIL的融合，也可以邀请咨询师参加研讨。一个融洽、轻松的气氛是活动取得效果的保证。 4.5尝试性的局部流程设计和实施 在培训结束后小规模地尝试设计和实施，可能会被一些咨询师认为是无价值的且可能影响项目实施的士气，但是我个人认为控制好尝试实施和真正咨询和工具落地之间的时间间隔，使之成为项目真正实施前的演练会比较好。正如我们在上游泳课前下了一次水，体验了一下我们可能遇到的问题。如果没有做一些尝试性的工作，甲方项目参与人事先没有足够的实践认知和思考，在项目期间很难提出问题和质疑，导致完全听信咨询师的意见，缺乏实际情况和理论结合的引导。 尽管业界不乏优秀的咨询师，但是你的项目是否能有既吃透理论知识，又有实践经验和行业经验的咨询师呢？IT咨询在证券行业的案例积累并不多，有证券行经验的咨询师更是难得。证券行业的IT和商业、制造业，甚至银行业的IT都有着很大的区别特色，咨询师对此缺乏深度的了解，很难根据证券行业和不同企业做诸多调整。 4.6提前做用户满意度调查。 用户满意度调查不一定能揭示运维工作的风险，但是基本能体现业务部门或用户对IT组织服务的认可程度。通常而言，得分一般都不会很高，这样能带来IT部门上下的紧迫感，从而有改善服务的意识。 我们实施了13456方法，从目前来看人员意识问题已经基本解决了，大家对项目的意义不再持怀疑态度了，也认为我们到了不得不实施ITIL的时候了，项目参与的积极性比较高，项目中分派到相关人员的工作完成基本得到了保证。 5.合适的项目范围和内容 缺少正确的项目定义和范围是导致项目失败的主要因素之一，并且项目管理最重要也是最难做的一件工作就是确定项目的范围。以ITIL V2为例，服务管理模块有10个流程一个功能，这都是自己IT组织迫切需要的吗？投入的资源足够做所有的流程吗？每个流程做到何种执行深度？在我们的所有IT组织范围内都实施吗？这些问题在项目计划之初都必须有个清晰的思路，重点解决组织自身迫切的问题更能使项目容易取得成功。 6.资源准备 项目资源的状况是决定了项目成功的关键因素之一。以下这些资源应当在项目立项时就应当充分考虑。 6.1项目中涉及的角色和人员 6.1.1项目经理 一般而言，咨询方的项目经理是否能胜任不必担心，反而IT组织自己的项目经理是否能胜任其工作需要重点关注。ITIL项目经理需要具备较厚实的技术背景，扎实的管理技能，较强的沟通能力，甚至需要一些政治技巧。因为，项目过程中需要进行大量的领导、沟通、谈判和解决问题的工作，需要管理各方的合理项目预期。在管理变更类的项目中，职能型项目组织里的项目经理显然是不够的。但是，鉴于证券行业的特点，券商IT组织实施ITIL项目必然会采用矩阵型的项目组织甚至职能型项目组织，所以项目经理人选的选择必须弥补这两种组织的不足。我个人认为，ITIL项目的项目经理以IT组织的负责人之一人员为好，强势的项目经理对项目执行力度有极大的帮助。 6.1.2项目架构师 ITIL项目架构师由IT组织内部对ITIL知识体系最熟悉的人担任。我个人觉得，这个人应当由IT组织内部资历较深且在组织内部工作时间较长的人担任。可以在项目立项前一年左右就选拔这样一个人参加ITIL的认证培训，培训后进行ITIL导入本组织的思考和研究。这个人不必和项目经理是同一人，但是至少和项目经理和IT组织的管理层应有比较良好的沟通关系，确保他提出的建议得到足够的重视或采纳。需要注意的是，这个人不是替代咨询师，不是充当项目中的知识权威。他的重要的工作是尽力在项目中与咨询师沟通，确保咨询师的设计充分考虑到IT组织自身特有的情况，通过合理的建议使项目收益最大化。 6.1.3各流程经理 流程经理是流程中的重要角色，需要根据流程特点、备选人员的专业背景、备选人员在IT组织内部的任职经历类综合考虑。虽然流程很多，但是并不意味着要11个具体的人员，有些流程经理是可以角色复用的。如服务台、事件经理可以是同一人，变更和发布流程经理可以是同一人。这些人员的准备应当是对应流程的重要参与人之一，尽早明确可以让其体重进入角色。 6.1.4项目核心成员 项目核心成员是除项目经理、架构师和流程经理之外的将来主要流程执行人员。这些人的经验和感受是设计流程时应当重点考虑的因素之一，通过沟通不仅吸纳了他们好的建议，也可以就他们关注的个人利益与流程控制点达成妥协，降低了他们实施后抵制的心理，对提高项目成功率有极大的好处。不过需要注意的是，在项目过程中如果牵扯了他们太多的时间会引起反效果。所以，在IT组织和咨询师沟通时并不是参加的人越多越好，而是需要平衡考虑诸多的因素。这种考虑多方因素，综合平衡的把控能力是项目经理必须具备的技巧，更是一门艺术。通常根据相关性从核心人员中动态选择部分人员参加具体的研讨。 6.2涉及人员的时间 咨询项目期间，需要运维人员参加比较多的研讨，工具落实期间，由于流程的控制，工作量会增加很多。人员的时间保证是项目成功最重要的因素之一。证券行业的运维人员往往平时的工作已经饱和，交易所和登记公司的周末测试又比较密集。所以，保证他们的参与时间的工作在项目启动前就应当考虑并有所安排。项目之初做一些例行和可重复性工作的梳理，如果有条件可以做一些剥离。在一些交流中，我发现有些专注于证券行业的系统集成公司逐步关注ITIL，并想进入实施领域。我曾经建议他们，可以从流程设计和实施过程中的人力资源外包入手。他们比较熟悉证券行业的IT业务，对系统也比较熟悉。证券公司的IT组织如果得到他们的帮助，项目实施会顺利很多，初期的服务质量下降会比较容易控制。 6.3项目文档的准备 咨询项目一开始，咨询师便会索取IT组织的有关文档。由于大部分券商的IT组织普遍深陷在繁杂的运维事务中，未必每家都有精细的文档管理体系。所以项目基本立项后，应当内部进行一次文档梳理。这项工作咨询最多提供一些基本的方法指导，无法施以援手只能内部努力。 6.4高层 一般而言，IT类项目成功最重要的三个因素是：明确的需求说明、用户参与程度和高级管理层的支持。从行业来看，尽管IT治理已经被有监管职能的证券业协会以指引提出，在监管理念比较先进的深圳证监局也发布了自己辖区内的指引，在一些证监会合规性文件和业务资格审批条件中也开始出现和IT治理有关的条款，但是公司高层忙于业务，对此关注度不高，甚至几乎没有关注。鉴于IT部门在公司内部普遍声音比较弱，公司高层的关注有先天的不足。 我个人认为，从规范运维工作，降低技术风险的角度出发，实施ITIL服务支持的部分流程，有IT组织内部高级管理者的强烈支持就可以了。但是，这种支持的级别也不能再降。如果降低到具体运维TEAM LEADER这个层面，我想项目就不是收益有限的问题，而是如何结束的问题了。如果缺乏强有力的执行权力保证，还会出现咨询师通常担心的强烈抵触危机。如果项目期望高于此，高层关注的要求会更高。 7.沟通协调 由于项目过程中，原本的服务团队投入大量的精力到ITIL项目上，加之团队处于管理转型阶段，IT对外的服务水平一般会有比较明显的降低。如果能对这时的服务水平做一些适当的管理，会降低对业务部门的影响，也有利于项目成果的展现和部门内部沟通状况的改善。 7.1重视沟通管理 从我个人的实际项目经历来看，业务部门和IT部门的沟通渠道不畅是个比较普遍的问题。尽管现在科技发达，通讯手段繁多，好像彼此联系非常方便。但是，联系不能等同于沟通。有效的沟通需要主动支援和主动反馈。IT组织做到和业务部门的主动支援和主动反馈了吗？支援和反馈的质量和结果如何？他们都得必要的管理了吗？这值得引起IT组织高层的重视。 我们曾经遇到过这样一个个案。当我们的咨询师到分支机构去访谈调研时，分支机构的负责人捧出了早已写好的材料。当然，事实并不是这个负责人和IT部门有什么恩怨，而是长时间以来，他们的业务需求没有得到有效的反馈，大部分事件缘由也不是IT部门不作为，仅仅因为历次沟通没有得到有效管理，长期反馈不良，造成了沟通需求的集中释放。 7.2流程设计研讨中的争吵并不可怕 流程设计是各方意志妥协的产物，争吵是不可避免的，充分的争论可以体现各方的需求和意志，降低执行时抵制的程度。项目人员和组织的管理人员只要把争吵控制在流程本身，就没有太大的影响。需要注意的是，争吵需要达成一致的意见，在一些比较难达成一致意见的问题上，CIO要能决断并保证最终决定是尽可能考虑了各方利益。 8.ITIL对组织架构影响深远 8.1及时梳理调整个人和组织的分工 由于流程的导入，使得参与人员的工作职责有了重新划分的需求。原因有如下几点： 1)继续按照原先的职责安排，流程控制的功能无法有效发挥。 2)专业化和关注重点有了转变，某些人的工作重心有所调整。 3)原先分工不甚合理，流程引入后不合理成分加剧，严重影响了工作效率。 4)原先的组织结构可能是基于职能性的，ITIL导入后很多管理活动基于流程，管理制肘不可避免。尽管可以通过角色对应关系可以实现流程，但是管理效率不高。 鉴于上述原因，有必要借此机会进行一次调整。 8.2 宜及早做好组织架构的长期规划 组织架构调整应尽可能预先设计好理想的组织架构，分阶段逐步实现，以降低组织内部的震荡。 同时，适当调整工作职责分工和引进新的岗位，有利于分解流程导致的工作量，降低现有运维人员对于流程引入的抵制和服务满意度的降低。 9.只有CSI才能实现ITIL收益的最大化 9.1功夫在诗外 ITIL的思想其实并无新奇之处，至少我觉得V2是如此。它是由目前一些管理上的方法和工具在IT组织的合集使用，掌握一些管理学上的方法和工具，会使得具体的ITIL活动如虎添翼。 9.2PDCA应当重视 ITIL项目不是一次性就能取得非常明显受益的，需要不断进行持续改善。不同阶段改善不同的不足，长期下去收益才能得到巩固。初期的收益可能是思想理念上的多过实际绩效方面的。 9.3KPI要落实到实处 设置KPI的目的大家都很清楚，但是就我跟很多已经实施过的组织沟通情况来看，鲜有得到有效应用并得到收益的。我所知道的唯一例外是平安科技。就我的理解，公平、公正、公开并和个人工资提职等明显挂钩的KPI才能真正为流程优化提供保证。在KPI负责人分解时可能遇到一个困惑，有些KPI不适合一个人背。对于这种情况，我觉得影响这个KPI的团队的LEADER背是合适的。 9.4抛弃不现实的想法 证券业IT队伍的工作压力普遍是比较大的，在这样的压力面前希望找到一个能一下子解决所有紧急问题的方法。其实，这是不可能的。项目前，我也是这样的想法和期望。在ITIL之外，我同时阅读了一些管理学方面的资料和书籍，慢慢才改变了我的看法。这些紧急的问题，基本上都是由重要但不算太紧急的的问题转变而来。所以从源头上处理这些紧急问题，即拟清组织的重要问题，进行长期规划，逐步实施解决方案。这样，积累一段时间之后，基础工作扎实了，紧急的事件就会越来越少。 以上是我个人的一些粗鄙见解，希望能跟有需要的人士分享。“纸上得来终觉浅，绝知此事要躬行”！