在实施ISO20000以前，比较普遍的情况是，企业实际在IT的各个领域都有容量预估与容量规划的实际操作，也有相应的文档支持，但由于没有建立起ISO20000 体系的管理规范，从部门的组织架构到实际的职责落实，都脱胎于原有的按管理对象划分的方式。

原先各领域之间的横向协作相对松耦合，并没有体现流程化的管理理念，对于推行类似容量管理的横向流程在组织架构上有较大的难度。

所以，从源头上讲，实施容量管理的必要条件是建立一套适合于ISO20000的组织体系。

量计划中反映出企业对于现有IT资源使用的度量，对未来使用量的预测，对怎样满足现在和未来业务需求的服务进行描述。

由于ISO20000标准明确地规定了必须要有容量计划，为了达到认证要求，原分散在各个领域内的容量文档必须进行整合，理顺各领域之间的关系，需要从IT服务的整体观点看待容量报告与容量计划的内容，形成一份完整的容量计划。

在撰写容量计划的过程中，首先要获得尽量准确的业务发展计划，这是IT容量计划的出发点与目标。

从客户的角度来讲，由于部分取决于市场或最终用户的变量，有时并不能提供完全详尽准确的业务计划。

随着产品生命周期变得越来越短，这对于客户自身来讲也是困难的。

此时就需要加强业务关系管理，从业务描述中识别出有关容量计划的因素。

跨越业务与IT的术语鸿沟需要执行业务关系管理的人员具有较强的沟通技巧，以及具备熟悉业务和IT背景情况的资质。

容量管理可以提供从监

控数据中得到的历史记录，以及运用各种建模预测工具所得结果，这将在很大程度上帮助业务关系确定未来的业务计划。

在分析业务计划中的IT资源使用因素时，需要尤其注意新业务推广引入的新应用系统的上线和原有功能的变更将会引起的IT 资源使用的变化。

容量计划必须定期进行回顾与修正，以反映业务的最新动向和外界因素的变化，在有更多信息可以利用时可以经常地更新该计划。

这可能是保持计划准确性的最好手段。

为保证容量计划能够真正贯彻执行，必须指定容量计划执行过程中的相关责任人，并使用文档等手段予以记录。

随着人员的变动，该记录也要相应进行更新维护。

当然，可以采用与岗位关联的方式进行记录，如规定负责人为部门经理等，此时就要注意记录内容必须与组织架构保持一致。

从容量计划的对象上来考虑，ISO20000认证过程中将从时间、人员、资源范围等角度进行考察。

首先要考察计划的执行过程中是否会有流程支持定期的回顾与反馈，以保证计划内容与实际相符。

其次需要把组织内的所有阶层都包含在容量计划的范围内，包括物理的和逻辑的，以确定整个组织都能知晓并遵循容量计划的实施内容。

最后，需要考虑些与服务有关的所有资源，尤其需要注意的是非IT的资源。

如果组织无法将外界的非IT资源纳入管理，就需要在认证过程中予以说明，表明确实考虑过相关的因素。

容量监控是持续贯穿在整个容量管理服务周期内的活动，ISO20000关注于进行容量监控等管理活动的记录证据，即容量报告。

从容量报告中可以看出，哪些资源对于企业维护IT服务质量是必需的，企业采取了怎样的手段进行监控和采样。

对于容量报告中发生的异常，是怎样产生一个容量事件或容量问题的，是通过监控阈值设定触发事件，还是经过生产服务异常，由客户反馈事件?显然，前者是采用了主动性的手段对容量进行监控，后者则成为了被动的处理者。

容量监控阈值列表也是ISO20000关注的一个重要证据，而更为关注的是怎样建立一个不断维护这个监控阈值列表的机制，需要相关的管理制度予以支持。

随着IT管理规模的发展，容量监控不可避免地将引入一系列的工具，代替人为手段进行管理，自动工具的引入将具有解放人力成本、减少人为操作出错的几率 · 固化容量监控的标准等一系列优势。

同样，在事件管理流程中，也有相应的工具来帮助事件管理员进行自动化的事件处理。

在一个大型规模的IT资源管理中，需要建立一套容量监控与事件管理的自动关联机制，以加速容量事件的处理与升级，提高事件处理的效率，同时自动触发容量评估处理的子流程。

最后，由于解决方案自身的复杂性、技术接口的数量巨大以及需要依赖的因素过多，在一个复杂的环境下实施容量管理具有相当大的挑战。

由于缺乏对整体架构、技术方案和客户需求的全方位认识，设计人员、实施人员和客户通常都存在不切实际的预期。

在应用选型方面刻意地提高容量标准将会引致意外的结果，并且通常为其他流程的维护和故障解决带来额外的延迟。