各位老师好:
今天看到有个问题挺有意思,大家怎么理解的:
关于变更发起的时机,争议颇多。
比如要准备发起一个变更,
1,是先研究清楚了,再发起变更?那些研究数据作为发起变更的数据支撑?
2,还是先发起变更,根据变更,做研究?那些要研究的工作为变更的行动计划?
前者问题还不大,但是后者的话会经常出现问题,比如研究过程中发现,变更不行了,或者行动计划有问题,或制定的计划当初没考虑好,根本无法执行。不在知道大家有没有这方面的感受,这种情况,尤其是变更涉及到各个部门,往往各种事情导致变更行动计划难以推动。
虽说有流程规定什么计划有变,重新召集各个部门评估,重新制定,再重新批准等等一系列麻烦事,麻烦就麻烦而往往不了了之(甚至听说过有的企业把前一个作废,重签的)。
变更其实分几个步骤。
1.变更前的评估这个变更前其实是在变更发起前,在变更发起前变更是否可以进行?其实是要进行一个初步的评估的,这个就包含已有的数据、已有的经验。
2.变更申请这个变更申请其实也包含了一个变更的初步评估,在变更申请是一个正式的申请,在这一步才正式发起变更。在这里相关各部门相关的人员对这个变更的可行性进行评估。
3.根据已经批准的变更申请制定变更方案,在这里边变更方案,包括一些变更需要的行动计划,然后对行动计划要进行风险评估。
另外在实际的管理过程中要有变更联络单,就是变更中发现什么变化要重新启动变更,而是用变更联络单来进行联络进行变化,只要批准变更联络单就可以了,不用重新发起或者废止变更。如果变更终止,需要有变更终止的流程。
一般采用第1个路径。因为从变更管理的目的来说,其根本目的是为了确保这些变化对于产品质量产生的影响处于可控状态。
这也是为什么一般的变更管理将行动划分为两类,一类是变更实施的前置条件,属于变更实施前必须完成的步骤,另一类则属于后置条件,其完成与否不影响变更的实施。这样的划分已经能够将对于最终结果产生影响的行动完全控制到,至于前置条件的更前一步的步骤,则没必要纳入变更管理的范畴。
对于第2个途径,从另一个角度来说,把很多事项都通过变更管理记录,某种意义上是把项目管理归结到了变更管理之中。既降低了项目推进执行的灵活性,又增加了“由于很多信息尚未确定的导致变更的评估不充分、分级不准确等问题”的风险。
1、变更是受控管理,不是随便发起,充分评估风险做降低风险工作,最终基于实施结果是否批准,结果可能批准也可能不批准。
2、商业化阶段肯定是1,变更重在管理,而不是变来变去。但要是其他的研发,技术转移阶段没必要管的那么严格,参考ICH Q10的4个阶段。看你在哪个阶段进行研究,研发?技术转移?商业化?研发阶段的来源是前沿科学技术,文献,技术创新。技术转移的来源是研发资料,是设计空间。商业化的来源是技术转移资料。更多的要说清楚研究的背景和目的就行。
3、研究方案就是来源。这两个选择都是可行的,2的好处在于有一个变更作为牵线将所有的工作串起来,涉及其中的研究过程只能在研究方案,有事是报告中汇总所有的变化,相当于将研究过程作为一个黑箱,所有在变更描述过程就没有清晰的信息;1的好处在于,变更的描述是清晰的,前面的所有工作都作为变更的支持性材料。两个选择都不违反,就跟清洁方法的变更,新的方法总是要有研究的,先研究还是先写变更,不存在逻辑缺陷,程序都走得通。
这{{threadTextType}}正{{isAdminText}}
为帮助审核人员更快处理,请填写举报原因:
为帮助审核人员更快处理,请填写举报原因: