ISO20000标准下IT项目中的文档管理

IT服务管理体系

您当前所在位置：首页 > 常见问题&知识园地 > IT服务管理体系

发布时间： 2020-03-31 12:03:34

　　文档是日常工作内容的一种展现形式，完整的文档管理体系下，囊括了从战略到战术，从策划到执行的各层面，大致可分为管理要求和技术文档两类。在建立以ISO20000为标准的IT服务管理体系项目中，应如何规划与建立文档管理制度以适应企业的特点，满足企业的管理要求？

　　在实施ISO20000建设项目的企业中，较多企业缺乏流程和体系的概念，其文档多为基于职能、技术的角度建立起来的诸如管理办法、操作手册类的文件。由于缺乏跨组织的流程文化，这种纵向模块化的文档架构在使用过程中，较多出现“各自为政”的现象，即各职能组之间所建立的文档内容可能存在重复，更有甚者甚至会出现内容冲突的情况。另外，由于缺乏跨组织的流程概念，基于职能角度建立的文档，其管理的颗粒度也因职能部门的“小文化”而异。实施ISO20000就意味着打破职能的界限，引入流程的文化，基于职能角度的文档架构与基于流程的 IT服务管理体系文档架构之间的关系往往是ISO20000建设项目中文档管理需要重点考虑的问题。

　　在解决职能与体系文档之间关系的问题之前，首先须分别梳理两类文档各自的架构。

　　管理者建立IT服务管理体系，有助于组织实现其管理目标。企业的方针、策略是引导体系建设和执行的大方向。流程是为了实现方针、策略而制定的规范化的要求。规范化的流程要求则需要通过操作细则、表单工具予以具体化，可操作，可检查。用标准化的表单工具执行日常工作，将执行过程可视化，结果可量化。

　　随着ISO20000项目的推进，这种“管理要求自上而下地落实，工作结果自下而上地展示”的管理思路体现出来的就是大量的覆盖管理管理要求（如服务交付、服务支持、关系管理等）的，基于流程的体系文档。我们把这种自上而下、自下而上的文档架构可划分为体系文档的四层架构。如下图所示。

　　再来看职能文档。由于职能文档是基于职能部门内部使用，所以称之为纵向条线的文档，更多的是为了规范某一部门、技术小组的工作及技术要求，如《主机管理办法》等，此类文档并非流程所能直接管辖的。从管理的角度分析，职能文档其实也体现了“管理要求自上而下地落实，工作结果自下而上地展示”的要求。基于此，笔者套用体系文档的架构，将职能文档也划分为如下的结构。

　　（不同企业对于“规范”、“办法”的命名习惯、定义等会有不同，此架构中的“管理规范”代表职能层面的规范要求。项目过程中，可根据实际情况调整架构中的阶层名称。）那么以上两类文档之间是否存在关系？存在什么样的关系？是否能够整合为一套管理体系？

　　首先，两个架构图中的方针、目标、组织架构对于企业来说应该是一致的，其展现形式即为一阶文档，所以称之为“IT服务管理总纲”。

　　其次，流程与职能，前者为跨组织的管理规范，后者为组织内部的管理要求，从企业整体管理的高度看，职能文档是串接在流程节点上，针对与该节点的更具体的工作要求。笔者以连续性管理流程为例，分析了流程和职能文档之间的关系。

　　针对ISO20000体系6.3 连续性管理的要求，可形成二阶文档即《连续性管理流程》；流程的活动之一：业务连续性计划演练，其连续性计划设计时需要考虑的若干方面的内容，如培训计划，采购计划，演练计划等方面的要求可以在《连续性计划》这个三阶文档中予以规定；而采购、培训、演练的实施记录等即为遵循三阶的要求生成的四阶文档。

　　从职能维度来看，根据图2中职能文档的架构，对于“连续性计划演练”这项活动，执行连续性计划演练时需要进出机房，则需要遵循《机房进出管理办法》这个二阶文档的要求；具体的，如何执行演练，演练的方案等都在《灾备应急演练方案》这个三阶文档中有定义；最后，演练的结果则体现在《灾备系统测试总结报告》这份四阶文档中。

　　从以上的分析可以看到，流程解决的是“面”的问题，而职能更多解决的是“点”的问题。

　　当然，这种面与点的关系是需要很长一段时间的梳理与整合才能完成的。在ISO20000项目建设过程中，我们可以分阶段实施这种文档管理的要求。根据组织人员的认知发展，通常在一期项目中，以建立IT服务管理体系文档为主，将基于ISO20000标准的流程文档化，可稍带优化职能文档的管理。这个阶段等同于把一本书读厚了，为的是深度了解管理体系的本质。经过半年至一年时间的体系运行，在管理优化项目中，可根据实际需要，一方面具体梳理体系与职能文档之间关系，另一方面，发现并整合重复的文档规定。再经过一年时间的运行与调整。这个阶段等同于把一本书从厚又读薄了，在全面掌握之后，消化吸收，将两类文档之间的“点面”关系充分地梳理清楚，形成适合本组织的实用的管理体系，真正能够做到三个一，即“一个目标，一个体系，一套文档”。

返回上一级