回复icetrob发表于：2007/5/21 10:47:00悬赏金额：
200积分 状态：
已解决
因为各单位的认证情况不同，体制不同，所以在内部评审/管理评审中出现的问题也不尽相同，希望大家能把各自单位在内部评审/管理评审中出现的问题拿出来分享，同时希望大家能把解决方法也公布出来，或者发表一下您对问题的看法，或者是提出您的解决思路。
公布一下活动规则：
1.本次活动面对所有仪器信息网用户。
2.活动以在本贴后跟贴的方式进行，另外开贴不予奖励。
3.发贴内容只要符合本次活动主旨（内部评审/管理评审所有相关问题）即可，但有两点要求，一是谢绝灌水，没有任何意义的回复贴就免了；二是不要有重复内容，最好是自己的经验经历。
4.奖励幅度视跟贴情况而定，原则上在有40个跟贴结贴并给予奖励，每贴奖励分值＝200/跟贴贴数。
5.对于同一用户来说，只要跟贴内容不一样，可以多次跟贴，积分奖励按“跟贴次数*每贴奖励分值”计算。
总之一点，只要是关于内部评审/管理评审的所有的问题都可以拿到这里来讨论。
希望大家能踊跃参加，谢谢。
原文由 chailang 发表:
我也很郁闷啊，实验室的药品试剂要验收，但是以前都没有验收过，现在就全部推到一起来要验收，都不知道怎么办了。两个多月了都没整改完，估计是要挨罚了。 |
试剂药品的验收可以制定不同的验收方法，对过去的工作是没有必要去补充验收材料的。整改可以采取制定验收程序、作业指导书来规范，并且对从整改之日起新购得试剂药品进行验收，提供验收证据就可以了
melu 回复于：2008/11/15 15:44:33
一、目前管理评审中存在的主要问题
1、对管理评审的概念理解不清，管理评审和内审混淆，把管理评审雷同于实验室的内部审核，特别是第一次实行新版质量体系的单位在管理评审时仅仅是讨论内审中应该处理的问题，把管理评审与内审等同操作，这样的管理评审是起不到应有作用的。
2、职能部门对管理评审的程序不熟悉，造成计划不够详尽、评审目的不明确。这种模糊操作、流于形式的评审，是不能解决实际问题的。管理评审内容格式化，重点不突出，没有将应该解决的问题列入评审内容，出现年复一年雷同的评审结论。
3、将管理评审与实验室的发展方针分离考虑，认为管理评审是质量管理体系运行的“特有产物”，属一般技术管理范畴，不能与实验室的经营发展、人力资源配置、组织机构等重大决策相提并论。
4、管理评审输入资料不完整。由于对管理评审应该评审哪些内容不清楚，往往造成管理评审会上只是关注内审时发现的问题及整改情况，没有对实验室整体资源状况等进行分析，更没有对制定的质量目标进行分析。因此使得管理评审不完整，不能收到应有的效果。
5、各职能部门准备不充分，输入的信息质量不高，报喜不报忧。 对于较敏感或难以解决的问题，评审时避重就轻，无法抓住关键问题和薄弱环节，解决不了主要问题。
6、纠正／预防措施不具体，落实不到位。管理评审中列出的问题，有些因涉及体制、机制或职责等重大敏感问题，需做进一步研究才能确定的纠正措施。这就容易造成列出的问题及改进措施，由于责任不清，计划性不强，纠正措施难以落实到位等现象。在管理评审时提出了一些问题，但没有责任部门负责跟踪落实，也没有验收和效果评价。管理评审在整个管理体系中是管理环的一个环节，而管理评审本身也应该是一个小的管理闭环，由于缺乏对提出问题的跟踪落实，从而造成管理评审只是履行了一种形式，而未起到完善和改进质量体系的作用。
7．准备问题
评审的问题很大一部分出现在准备上，这不仅仅是说某个项目的评审准备，甚至可能是整个组织内部对评审工作没有制定相关的标准和规范，没有建立组织级过程。
评审资源没有得到保证，资深评审人员其他工作比较多，没有投入足够的时间。
评审计划草率、不合实际，或没有及时调整，或实施不力。
项目经理没有为评审或改正保证足够的时间。
现象1：被评审人员缺少自我检查，或因计划不合理，提交文档是“粗稿”。
提交的文档是应该经过被评审人员自己充分检查过的文档，不能把查问题的责任完全推给评审人员。应该有类似“冒烟测试”的过程，明显未达到要求的文档退回修改后再提交评审。
现象2：评审人员到评审会议时才看文档或才看到文档，而没有提前阅读文档并解决大部分问题。
正式会议评审的准备不够充分，不做准备而完全靠评审会议上的有限时间来进行评审是评审失败80%的原因。造成这一现象的原因可能是评审人员事情太多，也可能是因为评审人员对会议有依赖心理，不愿意阅读文档，只希望到会议上听别人解说。
现象3：没有足够的时间改正已经发现的错误，如果没有有效的跟踪，久而久之可能忘记，或者不具备对开发团队的指导意义，造成错误可能会流转到下一环节。
2．焦点问题
就某个文档而评审该文档，没有对照已有的成果和标准。需求和设计是软件开发项目的中间文档，前面会有一些约定输入，也可能会要求遵守相关标准。除非是对这些输入的内容已经了如指掌，可以敏感地发现互相之间的不一致性；否则一定要考虑仔细对照相关的输入。
就某个系统而评审该系统，没有考虑相关系统。当客户或企业已经开发了多个软件系统之后，系统之间的相关性必须是考虑的因素，这些相关性包括数据之间的关系、业务之间的关系、用户管理、系统管理的一致性，操作习惯和界面的关联性和软件复用等。
过多地讨论问题如何改正，评审的目的主要在于指出问题。而一旦正确地确认了问题之后，解决问题就容易得多。大多数都能很快找到解决方案，而一时无法给出解决方案的问题可以在评审后研究讨论。
在小问题上花太多时间，捡芝麻丢西瓜。在一些无关紧要的事情上纠缠不清，争执不下，造成时间的浪费。当然要注意的是，有些细节是项目成败的关键，所以要分清什么是重要的细节，什么是不重要的细节。
评审与评价混淆，评审的目的是指出具体问题以便改进，评价是给最终工作结果及人员工作绩效下结论。
3．人员问题
评审人员搭配不合理，遗漏一些角度或一些层次的人员。和每个软件开发项目团队的人员搭配一样，评审人员的搭配也应该尽可能合理，考虑全面性和有效性。可以用上述评审角色层次结构与角度结构（可进一步完善）来发现选拔各个层次和角度的评审人员，建立公司级别的评审人员库，在需要评审的项目中针对具体情况组合评审队伍。
无论是企业内部还是用户都有可能找不到合格的评审人员，如用户看不懂建模图形，或者企业内部缺乏具备相关行业业务知识和相关经验的技术人员等。评审人员的素质对评审效果起决定性的作用，因此评审人员的选拔是很重要的。如果确实没有合适的人选，那么在评审准备阶段进行评审所需的知识和技能的培训是很有必要的。《问题解决心理学》说：“用有关的过去经验来解决当前问题的一个主要障碍就是，首先要找到相关的过去经验”来进行类比，而“类比思维的核心是通过一个映射的过程，将知识从一种情景转换到另一种情景”。而如果整个企业都找不到有人具备“有关的过去经验”，会大大影响评审的效果。
如果评审人员对必要性认识不足，认为评审不过是一种形式，不去努力发现问题，则评审必然是没有什么效果的。如果管理层对评审的必要性认识不足，就有可能造成资源不到位。
软件开发队伍中总有一些被业内称为“大忽悠”的人士，这种人对专业技术或行业知识一知半解、不懂装懂，却能爬得很快。他们为了掩盖自己的不足，有可能吹毛求疵地找一些小毛病，来显示自己还能发现问题。
孔子说：“知之为知之，不知为不知，是知也。”在评审过程中应当要有实事求是的态度，不知道的事情应当问清楚，不要不懂装懂，盲目地下结论。
杨振宁说：“知之为知之，不知也要知。”为了做好评审，评审准备阶段应当尽可能花时间使“不知”变为“知之”。
4．会议效果问题
什么都完全靠会议讨论来解决问题是不切实际的，会前不做任何准备必将影响评审效果。
会上蜻蜓点水，走马观花，没有深入考察要评审的文档发现潜在的问题。
注意力不集中，会议跑题。开会时东拉西扯，动不动就不着边际，离题万里。
对文档中某些术语概念的认知有差异、争执不下，纠缠不清。对于同一个词汇，不同人的理解不一样，争来争去最后才发现说的不是同一件事。
评审内容遗漏了关键部分，评审内容的完整性可以通过CheckList来保证。
虎头蛇尾，对发现的问题缺乏有效的跟踪及纠正措施，没有规定跟踪责任人。
天平室用的温湿度计未校准。
配置标准样品的房间没有排风扇（原话不是这么说的，但是就是这个意思）。
光谱室未做有效隔离（反正整改的时候就是在光谱室外面放换鞋子的架子，进光谱室要先换鞋子）
气瓶未固定
原始记录修改的地方未盖个人章
某仪器未贴准用证
人员无上岗证
仪器使用登记表填写不规范
纯水仪制的水未定期验证
内审和管理评审不符合项的整改比较难做，一般原因分析都是那几条：人员责任心不强、对体系文件熟悉理解不够。。。，所以整改的措施也只能是批评教育、学习体系文件，都是做表面文章。各责任部门都不愿意好好改，都是只作表面文章。
jswmz 回复于：2007/5/22 13:20:00
sharkwein 回复于：2007/10/18 17:46:00
06年版本的内部评审表格
您现在的位置：