先谈谈对两个版本划分过程组的粗浅看法：
2011版的过程组：服务交付、关系、解决、控制
2005版的过程组：服务交付、关系、解决、控制、发布
我们都知道ISO20000是服务管理体系的标准，从管理体系的四个角度理解：交付是管理向客户持续交付符合SLA要求的各项服务指标、关系管理是用于沟通改进客户的满意度和管理外包商、解决过程是维持服务交付的质量、控制管理主要是针对服务交付过程中的风险，与之比较2005版中的发布过程组则显得有些不伦不类，发布管理显然与上述的四个过程组不是属于同一个范畴同一个level，因为发布属于一个服务活动而不是服务管理的不同视角，所以把发布管理调整到控制过程组是比较合理的。另外，如果把发布管理调整到服务交付过程组也似乎相比2005版更好一些，这个就不多说了。
发布管理的定义：collection of one or more new or changed configuration items deployed into the live environment as a result of one or more changes
案例：某公司的生产环境每月平均有80多个系统功能性的变更，每个变更都采用一个发布来部署，这些变更原先每天都有，造成对生产环境的持续冲击，运维部门的压力很大，为了控制变更风险，公司要求常规变更必须都放在每月两个的发布窗口中实施，认为这样就可以降低风险，结果导致每个发布窗口拥堵了30多个变更等待实施，一来分散的风险现在集中了，二来造成部署人员在发布窗口的工作紧张压力更大，实际上导致变更风险的加大。从这个简单的案例分析：这个公司并没有认识到变更管理和发布管理的相互作用，只是以为将变更集中在一起实施就可以降低风险，较好的策略应当是在CAB中对这些RFC进行分析归并，将多个相关的变更请求合并成一个发布来减少变更的数量，从而达到降低变更风险的目的，从这个角度看将发布管理调整到控制过程组也确实是有道理。
