学习资料： ITIL先锋论坛专家讲堂直播 300期视频回放
管理的“单位”
从今年公司上半年通过ISO20000认证后，精力更多放在服务平台(ITSM工具)的建设实施上，等到下半年时，对服务管理体系内审时，发现了很多问题，而这些问题在很大程度上应证了我做ISO20000项目的一个担心，即由于体系如此宽广、业务类型众多，在追求通用性与完整框架的同时，对每一个具体的业务类型的约束性大大降低了，更严重的是流程的触动条件是如此缺乏控制，最终导致体系力量被稀释了。现在想起来，在做ISO20000时应该继续当时的思考，突破当时的最大的一个体系模型缺失。写这篇文章，是因为我认为这个问题我们已找到方法去解决了，它是如此重要，甚至解决了我们在体系实施执行时一个困惑，即怎么才能更有效的实施体系，怎么样才能要通用性与项目特性之间把握平衡。
要说的点很多，可能我脑中现在无法找到一种很有序的讲解方法让大家明白。在思考这一个课题时，我脑子中一直觉得它是一个管理“单位”的问题，在我们公司的运维业务中，是由很多不同的项目组成的，而项目类型主要是终端桌面、IDC、软件这几种，由于软件众多，所以项目也就很多，这里可能有人会问，到底什么是项目，项目这个定义，在我们公司并不是一个非常成熟的意识的结果，而是在运营过程中，系统是一个一个开发的，每一个系统在在签订合同后，就成立一个项目组，内部给它一个项目名称与编码进行管理，这主要是开发阶段，而在运维阶段，情况也是类似的，最终就造就了现在的局面，我们有很多项目。现在有了一个“项目”单位，然后我们在运维过程中，根据一些项目业务属性，又划分成几个不同的领域，比如生产制造这一领域中有一些软件项目，我们把这些项目划分在一个业务领域管理，安排一名主管进行负责，而像其它的供应链管理、市场销售管理等也是一样，这样又有了一个“领域”单位，再往上是部门层面了，为什么要谈单位问题呢，是因为管理体系去落实执行，到细节执行层面时，必须考虑一个“颗粒”问题，到底是以整个部门为单位，还是以领域为单位呢，还是以项目为单位，这是最终必须回答并考虑清楚的问题，可能有人会不解，管理体系以部门、领域、项目为单位有什么区别吗？不是同样都要按同一个制度执行吗？如果制度是同一个，不管是以部门、还是领域亦或是项目，最终结果是一样的，只是说法不同而已，从一定程度而言，这个说法也对，但具体在落实执行时，不把约束的触伸到每一个项目，在执行就很容易脱节，而且员工的执行也缺乏更明确的依据，整个体系的监控查核与记录管理很容易混乱。
ISO20000作为一个标准，它强调每个服务要满足标准的要求，当我们根据标准设计了管理体系后，我们会发现不同的服务应用的流程数量可能是不一样的，比如象终端服务一定要做持续性管理吗，一定要做能力管理吗，更细分些，如果我们仅仅是承接一个公司的打印机维护业务，我们需要搞13个流程吗？我想是未必的；再比如我们的软件运维服务，如果当我们只负责软件本身的开发维护，主机层不由我们负责，我们需要做持续性与可用性管理吗？。当我们的服务类型众多时，每一个服务类型又有多种项目形式时，往往不是每一个项目需要执行13个流程的。
在执行层面中，每一个服务项目，有自已相关一些作业要求与计划，如果仅仅考虑以流程的划分方法来管理执行存放记录，如果有50个项目，每一个项目的SLA、监视计划、备份计划、恢复计划、能力计划、服务体制、服务目录等等许多执行环节的内容被分散各个流程中，这时非常需要一个方法把这个服务项目所有相关的要求与内容组合起来，最终这些要素形成一个《项目作业书》（这是我们的叫法），它在符合管理体系的要求的同时，又做了延伸与进一步的解释，它解答了这个项目如何做服务，有哪一些具体的要求。这样每一个项目都有自已的《项目作业书》，新项目成立时，需要编制出来，并做评审，这同时是一个服务设计的过程。项目在服务过程中时，再通过对《项目作业书》的控制来控制服务变更。当每一个年度结束时，通过合同重新签订与年度服务规划来重新发布新一个年度的《项目作业书》，它既强化了体系的控制力，同时更加适用于员工层面的执行、引用、解读。
形成上面的框架后，随之而来的是组织分工的问题，服务需要持续稳定优质，必须依赖于几个方面的力量，技术、流程、执行。这三个方面的力量需要有效配合协同，确切而言，是以下的视角。基本上主要以服务层为主，技术的提升、体系的优化都是服务层提供支援的。
就目前而言，我们的方向性与理论问题解决了，开始往这个努力，如果后续能强有力的执行，相信随着时间的推移，效用会越发明显，而且行政的框架间隔会逐打破，以项目以流程的协同服务作业。当然这其中的难度也是可想而知的。
近来事情挺多，写得干瘪，没有精力铺开展开论述。个人认为这一个思考结果很重要，就不知对别的组织与同行是否有一定的启迪作用。
|
转播
分享
淘帖
()
