在DOORS里做变更控制，最容易出问题的不是提案提不出来，而是前面没把系统边界和角色分清。IBM官方文档把这件事说得很明白，DOORS自带一套Change Proposal System，也就是变更提案系统，适合做内建的提案、评审和应用；如果你要的是更重的、可定制程度更高的变更控制流程，则要走和变更管理工具的集成路线。也就是说，先分清你要的是内建轻流程，还是外接强审批流，后面的配置才不会越做越乱。

　　一、DOORS怎么提交变更提案

　　先把提案入口跑顺，再谈评审。DOORS官方给出的标准路径很直接，在模块窗口里先选中要提案的对象，再走【Tools】【Change Proposal System】【Submit Proposal】。如果这次提案不是改当前这一条，而是要同时作用到多条对象，窗口里还能继续点【Select Objects】，再在【Current Object】、【Selected objects】和【Objects in current view】之间选范围。这样做的好处很实际，改单条、改一批、改当前视图里的筛选结果，都能走同一个入口，不用拆成多次手工提。

　　1、先确认项目已经建好CPS

　　如果项目还没建Change Proposal System，提交入口就算看得到，后面也没有成套的提案存储和评审环境。IBM官方说明里写得很明确，项目级CPS要由有完整权限的人在【Tools】【Change Proposal System】【Setup】【New】里创建，系统会在项目下自动生成一个【Change Proposal System】文件夹，并在里面放Suggestions和Proposals等模块。

　　2、单条提案和批量提案都走同一入口

　　对象选中以后点【Submit Proposal】，如果只是改当前对象，直接继续填提案内容就行；如果要针对多条对象一起提，先点【Select Objects】再选范围。这个设计本身就说明，DOORS的批量提案不是另外一套功能，而是在同一窗口里扩出来的。

　　3、有关联影响时，把提案加进组里

　　IBM官方文档专门提到，提案可以加到group里。实际工作里，这一步很有用，因为一个需求改动常常会连到同模块或跨模块的相关条目，把它们放进同一个组，后面就能一起评审、一起应用，避免某一条先改了，其他关联项还留在旧状态。

　　4、提案提交后不要直接改活数据

　　CPS的意义就是把反馈和正式数据隔开。官方对Change proposal的定义很清楚，它是针对具体对象和具体模块提出的详细修改意见，由评审团队决定接受、拒绝还是暂缓；接受后才会作用到live data。也就是说，提交提案本身不是直接改需求，而是把改动送进受控流程。

　　二、DOORS变更提案审批流怎么配置

　　如果你用的是DOORS自带的CPS，审批流本质上是一条内建的简流程，不是那种任意拖拽节点的流程引擎。IBM官方文档写得很清楚，CPS提供的是一个受控环境，提案会被数据所有者和相关评审人审核，结果通常落在接受、拒绝或暂缓这几种处理上。要把这条流跑顺，关键不是自己画状态图，而是先把模块范围、用户角色和评审权限配对。

　　1、先在项目上做CPS配置

　　标准入口就是【Tools】【Change Proposal System】【Setup】【New】。建立以后，先在【Module】页选纳入评审范围的模块，再在【Users】页加用户。这个步骤决定了后面哪些模块能提案、哪些人能看、哪些人能审。

　　2、角色别混着给

　　IBM官方对角色分工写得很直白。CP Reviewer就是变更提案评审团队成员，也就是很多团队说的CCB，他们负责看提案并决定接受、拒绝或暂缓；CP Manager则更偏系统设置和范围管理。配置时把这两类角色混在一起，后面最容易出现“谁都能提，谁也不敢批”的情况。

　　3、需要评审人补文案时，再开Reviewer可编辑

　　在CPS配置的【Users】页里，IBM官方说明可以允许CP Reviewer编辑他们评审的变更提案。这个开关很关键，关着时更适合严格分工，提案人提、评审人判；开着时更适合协作式澄清，评审人可以直接把提案补完整。审批流配不顺，很多时候不是状态有问题，而是这个权限一开始没想清楚。

　　4、内建流不够时，改走集成式流程

　　如果你的团队要求多级审批、状态映射、外部变更单联动，IBM官方建议的方向不是在CPS里硬改，而是使用Change Management for DOORS这条集成路线。文档里写得很清楚，它支持把已安装的change request process映射到DOORS的变更管理概念上，本质上就是把外部流程状态和DOORS里的提案、评审、应用接起来。

　　三、DOORS变更提案落地前要先定什么

　　很多团队不是不会点菜单，而是上线前没把规则定死，结果提案越来越多，审批却越来越虚。更稳的做法，是在正式启用前先把提案粒度、评审口径和应用时点定清楚。IBM官方资料里已经把几条底线给出来了，提案系统建在项目级，评审由reviewer团队执行，接受后的提案才会作用到live data，这几件事本身就是流程设计的边界。

　　1、先定什么改动必须走提案

　　如果什么小修小补都走CPS，评审会很快堆死；如果关键需求改动又不走提案，流程就会失去约束。更实用的做法，是先把需要正式评审的变更类型收出来，再让这些改动统一进CPS。这个判断和IBM对CPS受控环境的定位是一致的。

　　2、再定评审结论怎么落

　　CPS内建的处理方向就是接受、拒绝、暂缓。与其后面临时解释，不如一开始就把这三类结论在团队里讲清楚，谁能判、判完怎么通知、什么时候应用，先收成固定动作。DOORS官方文档也提到，提案状态变化后系统会自动发邮件通知相关用户。

　　3、最后定什么时候把批准结果真正写回模块

　　批准并不等于马上生效。对集成式变更管理来说，IBM官方写明了，Approved的RCR后面还要通过【Change Management】【Requirements Change Request】【Apply】去应用，而且还能选择在应用后顺手创建baseline。就算你现在用的是内建CPS，这个思路也一样有用，评审和落地最好分成两步，不要混在一起做。

　　总结

　　DOORS怎么提交变更提案，关键是先把CPS建在项目上，再从【Tools】【Change Proposal System】【Submit Proposal】进入，按对象范围和提案分组把改动收进受控流程。DOORS变更提案审批流怎么配置，关键则是先把模块范围、用户角色和评审权限配对；如果只是常规评审，用内建CPS就够了，如果要多级状态和外部工单联动，再切到集成式变更管理。把这两层分开，提案提交和审批落地都会顺很多。