СМК: Входные и выходные данные для проектирования и разработки. Процессы жизненного цикла продукции Входные требования для проектирования включает
7.3.1 Планирование проектирования и разработки
Руководство ТюмГУ планирует и управляет проектированием и разработкой в соответствии с процедурами «Подготовка учебного процесса» ОП 01.02, «Обеспечение учебно-методическим обеспечением» ПП 01.03.
При оценке потенциала рассматриваются составляющие системы образования, имеющие количественную характеристику:
Кадровый состав;
Материально-техническая база;
Информационная база;
Научно-методическое обеспечение;
Финансовые ресурсы;
Управление системой и ее отдельными элементами.
В ТюмГУ обычно осуществляется проектирование и разработка следующих документов:
4. Учет стратегического и среднесрочного плана развития ТюмГУ.
Разработка новых циклов дисциплин и корректировка действующих обеспечивается выполнением следующих задач:
1. Проектирование курса. Определение результатов обучения.
2. Самоанализ ППС и построение собственной системы педагогической деятельности.
3. Аттестация и технология самообследования университета.
Планирование проектирования и разработки осуществляется на основе календарного плана , содержащегося в Системе программных мероприятий на учебный год. График работ разбивается на этапы проведения работ, каждый из которых детализируется на отдельные задачи.
В графике работ устанавливаются стадии проверки, доработки и согласования документации, этапы верификации и валидации, разделение ответственности и полномочий в области проектирования и разработки между участниками работ.
Руководитель конкретной работы анализирует техническое задание и определяет состав исполнителей по проектированию и разработке (в т. ч. с привлечением сторонних специалистов).
Разработка и проектирование выполняется ТюмГУ самостоятельно или с привлечением сторонних организаций и/или специалистов.
Процедура мониторинга качества научной и учебно-методической литературы складывается из анализа результатов деятельности следующих структурных подразделений:
ЦИТ – организация и поддержка электронной среды университета;
ИБЦ – использование (комплектование, выдача) учебно-методической и научной литературы ;
Издательство – издание учебно-методической и научной литературы;
Факультеты и кафедры – создание и подготовка к опубликованию научной и учебно-методической литературы.
Технические задания для соисполнителей разрабатываются ответственным исполнителем с участием, при необходимости, привлекаемых организаций и/или специалистов. Содержание технического задания определяется ТюмГУ. Техническое задание утверждает ректор.
Договор (контракт) с соисполнителем согласовывают следующие лица (в порядке получения виз):
· Соисполнитель;
· Руководитель структурного подразделения;
· Представитель руководства по качеству;
· Ректор и/или проректор.
Входные данные, относящиеся к требованиям учебного процесса в ТюмГУ, включают:
1. Требования к учебно-организационной документации;
2. Требования к информационному и учебно-методическому обеспечению;
3. Требования к ППС, административно-управленческому и учебно-вспомогательному персоналу;
4. Требования к материально-техническому оснащению;
5. Требования к уровню подготовки абитуриентов;
6. Информацию из стратегического и среднесрочного плана развития ТюмГУ.
7.3.3 Выходные данные проектирования и разработки
Выходными данными по проектированию и разработке являются:
Образовательные программы;
Учебно-методические пособия;
Словари.
Для всякого проектирования и разработки выходные данные должны:
· соответствовать входным требованиям к проектированию и разработке;
· обеспечивать соответствующей информацией по закупкам, производству и обслуживанию;
· определять характеристики результатов проектирования и разработки, существенные для безопасного и правильного их использования.
Комплектность документации по проектированию и разработке определяется техническим заданием. Как правило, комплект документов включает в себя версию на бумажном носителе и электронную версию на CD-ROM.
Ответственным за подготовку документов является ответственный исполнитель.
Копии разработанной документации по проектированию и разработке и их электронные версии хранятся у ответственного исполнителя с последующей передачей в архив.
Учет документации ведет ответственный исполнитель в соответствии с перечнем документации, оговоренным в графике работ. Записи, фиксирующие учет разработанной документации, отражаются в периодических отчетах о проделанной работе.
Выходные данные организационно-методической работы:
§ подготовленные методические разработки,
§ составленные учебно-методические комплексы дисциплин,
§ система расчетов учебной нагрузки,
§ организация системы делопроизводства,
§ составление планов кафедр,
§ подготовка кафедры к самоаттестации и аккредитации.
7.3.4 Анализ проекта и разработки
В процессе проектирования и разработки осуществляется систематический анализ для установления соответствия требований к результатам проектирования и разработки, то есть анализируется качество разработки (п. п. 3.1.1, 3.8.7 ГОСТ Р ИСО 9000 – 2001).
В ТюмГУ используется многоуровневая система анализа качества проектирования и разработки, которая предусматривает выполнение анализа на соответствующих стадиях проектирования и разработки в соответствии с запланированными мероприятиями. Система анализа включает следующие последовательные процедуры:
· внутренний анализ, осуществляемый ТюмГУ в процессе подготовки предварительной и окончательной версий документов проектирования и разработки;
· внутренний анализ, осуществляемый ТюмГУ в процессе доработки (корректировки) документации по замечаниям и/или предложениям Потребителя;
· внешний анализ органами госэкспертизы (при необходимости);
· внешний анализ, осуществляемый Потребителем.
Система анализа проектирования и разработки действует в отношении предварительной и окончательной версий документации. Система сдачи-приемки включает мероприятия по анализу проектирования и разработки на различных уровнях.
Число уровней анализа зависит от условий проектирования и разработки и может варьироваться.
I уровень анализа
Ответственный исполнитель осуществляет анализ и приемку работ по проектированию и разработке в соответствии с техническим заданием от штатных сотрудников ТюмГУ.
В случае наличия замечаний у ответственного исполнителя по представленной документации штатные сотрудники дорабатывают документацию в рабочем порядке.
Подтверждением проведенного анализа и приемки работ является подпись ответственного исполнителя.
II уровень анализа
Ответственный исполнитель работ по договору (контракту) совместно со штатными сотрудниками ТюмГУ осуществляют анализ документации и приемку работ в соответствии с техническим заданием от субподрядных организаций.
Подтверждением проведенного анализа является визирование ответственным исполнителем работ по договору (контракту) акта сдачи-приемки работ от субподрядных организаций.
III уровень анализа
Ответственный исполнитель работ в соответствии с условиями технического задания осуществляет анализ и приемку работ по отдельным разделам документации от привлекаемых специалистов.
В случае наличия замечаний у ответственного исполнителя по представленной документации привлеченные сотрудники дорабатывают документацию в рабочем порядке.
Подтверждением проведенного анализа является визирование ответственным исполнителем акта сдачи-приемки работ от субподрядных организаций.
IV уровень анализа
Анализ с привлечением сторонних организаций и/или специалистов. Решение о привлечении для анализа сторонних организаций и/или специалистов принимает Представитель руководства по качеству.
Подтверждением проведенного анализа является визирование ответственным исполнителем работ по договору (контракту) акта сдачи-приемки работ с привлеченными для анализа сторонними организациями и/или специалистами.
V уровень анализа
Анализ со стороны Потребителя.
В случае наличия замечаний при таком анализе по представленной документации сотрудники дорабатывают документацию в рабочем порядке.
Подтверждением проведенного анализа является подпись акта сдачи-приемки работ со стороны Потребителя.
Материалы по анализу проекта и разработки хранятся в подразделении-разработчике и/или у ответственного исполнителя работ в течение 3-х лет.
7.3.5 Верификация проекта и разработки
Верификация осуществляется в соответствии с запланированными мероприятиями, чтобы удостовериться, что выходные данные проектирования и разработки соответствуют входным требованиям. Деятельность по подтверждению выполнения установленных требований осуществляется в соответствии с запланированными мероприятиями (п. 7.3.1). Предусмотрены следующие этапы верификации для различных вариантов проектирования и разработки:
Ответственным исполнителем;
Специально назначенным сотрудником;
При нормоконтроле.
Отметкой о проведении верификации является подпись соответствующего исполнителя в предусмотренных для этого местах (на разрабатываемых документах, в акте и др.). Записи результатов верификации и всех необходимых действий поддерживаются в рабочем состоянии.
7.3.6 Валидация проекта и разработки
Деятельность по валидации осуществляется в соответствии с запланированными мероприятиями (п. 7.3.1). Предусмотрены следующие этапы валидации для различных вариантов проектирования и разработки:
Заведующим кафедрой;
Деканом или начальником института;
Проректором;
Представителем руководства по качеству;
Ректором.
Отметкой о проведении валидации является подпись соответствующего исполнителя в предусмотренном для этого местах (на разрабатываемых документах, в акте и др.).
В предусмотренных случаях валидация осуществляется Потребителем и/или сторонними организациями.
7.3.7 Управление изменениями проекта и разработки
Изменения разработанной документации могут происходить:
· при обнаружении ошибок;
· при совершенствовании разработанной документации;
· при изменении требований Потребителей.
Изменения разработанной документации могут осуществляться на любой стадии выполнения работ.
Тексты изменений разрабатывает инициатор изменения в соответствии с принятым порядком разработки и утверждения. Внесение изменений в разработанную документацию осуществляется специалистами, выполняющими или выполнившими соответствующую работу, под контролем ответственного специалиста (форма извещения об изменении приведена в приложении к процедуре 01.04.02/ПП 01.04 «Управление документацией и записями»).
Изменения, вносимые в разработанную документацию, анализируются с точки зрения их влияния на другую разработанную документацию по проекту, верифицируются, подвергаются валидации и согласованию в том же порядке, что и разрабатываемая документация (п. п. 7.3.3 – 7.3.6 Руководства по качеству).
Изъятая документация хранится в течение 3-х лет.
Входные данные, относящиеся к требованиям на продукцию, должны быть определены, а записи должны поддерживаться в рабочем состоянии. Эти данные должны включать:
а) функциональные и эксплуатационные требования;
b) подходящие законодательные и регламентирующие требования;
с) там, где это применимо, информацию, взятую из предыдущих аналогичных проектов;
d) другие требования, важные для проектирования и разработки.
Эти входные данные должны анализироваться на адекватность. Требования должны быть полными, недвусмысленными и непротиворечивыми.
Выходные данные проектирования и разработки
Выходные данные проектирования и разработки должны быть представлены в форме, позволяющей провести верификацию относительно входных требований к проектированию и разработке, а также должны быть утверждены до их выпуска.
Выходные данные проектирования и разработки должны:
а) отвечать входным требованиям к проектированию и разработке;
b) обеспечивать соответствующей информацией по закупкам, производству и обслуживанию;
с) содержать критерии приемки продукции или ссылки на них;
d) определять характеристики продукции, существенные для ее безопасности и правильного использования.
Анализ проекта и разработки
На подходящих стадиях должен проводиться систематический анализ проекта и разработки в соответствии с плановыми мероприятиями с целью:
а) оценивания способности результатов проектирования и разработки отвечать требованиям;
b) выявления любых проблем и внесения предложений по необходимым действиям.
В состав участников такого анализа должны включаться представители подразделений, имеющих отношение к анализируемой(ым) стадии(ям) проектирования и разработки. Записи результатов анализа и всех необходимых действий должны поддерживаться в рабочем состоянии.
Верификация проекта и разработки
Верификация должна осуществляться в соответствии с плановыми мероприятиями, с тем чтобы удостовериться, что выходные данные проектирования и разработки отвечают требованиям к входным данным проектирования и разработки. Записи результатов верификации и всех необходимых действий должны поддерживаться в рабочем состоянии.
Валидация проекта и разработки
Валидация проекта и разработки должна осуществляться в соответствии с плановыми мероприятиями, с тем чтобы удостовериться, что полученная в результате продукция способна отвечать требованиям к установленному применению или предполагаемому использованию там, где это известно. Где это практически целесообразно, валидация должна быть завершена до поставки или реализации продукции. Записи результатов валидации и всех необходимых действий должны поддерживаться в рабочем состоянии.
Управление изменениями проекта и разработки
Изменения проекта и разработки должны быть идентифицированы, а записи должны поддерживаться в рабочем состоянии. Изменения должны быть проанализированы, верифицированы и утверждены, если это целесообразно, а также одобрены до внесения. Анализ изменений проекта и разработки должен включать оценку влияния изменений на составные части и поставленную продукцию.
Записи результатов анализа изменений и любых необходимых действий должны поддерживаться в рабочем состоянии.
Процесс закупок
Организация должна обеспечить, чтобы закупленная продукция соответствовала требованиям, установленным к закупкам. Тип и степень управления, применяемые по отношению к поставщику и закупленной продукции, должны зависеть от воздействия закупленной продукции на последующее производство продукции или готовое изделие.
Организация должна оценивать и выбирать поставщиков на основе их способности поставлять продукцию в соответствии с требованиями организации. Должны быть разработаны критерии отбора, оценки и повторной оценки. Записи результатов оценивания и любых необходимых действий, вытекающих из оценки, должны поддерживаться в рабочем состоянии.
Информация по закупкам
Информация по закупкам должна описывать заказанную продукцию, включая, где это необходимо:
а) требования к утверждению продукции, процедур, процессов и оборудования;
b) требования к квалификации персонала;
с) требования к системе менеджмента качества.
Организация должна обеспечить адекватность установленных требований по закупкам до их сообщения поставщику.
Верификация закупленной продукции
Организация должна разработать и осуществлять контроль или другую деятельность, необходимую для обеспечения соответствия закупленной продукции установленным требованиям к закупкам.
Если организация или ее потребитель предполагают осуществить деятельность по верификации на предприятии поставщика, организация должна установить в информации на закупку предполагаемые меры по проверке и метод выпуска продукции у поставщика.
Входные данные, относящиеся к требованиям к продукции, должны быть определены, а записи должны поддерживаться в рабочем состоянии (4.2.4).
Входные данные должны включать в себя:
a) функциональные и эксплуатационные требования;
b) соответствующие законодательные и другие обязательные требования;
c) там, где это возможно, информацию, взятую из предыдущих аналогичных проектов;
d) другие требования, важные для проектирования и разработки.
Входные данные должны анализироваться на достаточность. Требования должны быть полными, недвусмысленными и непротиворечивыми.
Выходные данные проектирования и разработки
Выходные данные проектирования и разработки должны быть представлены в форме, подходящей для проведения верификации относительно входных требований к проектированию и разработке, а также должны быть официально одобрены до их последующего использования.
Выходные данные проектирования и разработки должны:
a) соответствовать входным требованиям к проектированию и разработке;
b) обеспечивать соответствующей информацией по закупкам, производству и обслуживанию;
d) определять характеристики продукции, существенные для ее безопасного и правильного использования.
Примечание - Информация по производству и обслуживанию может включать в себя подробные данные о сохранении продукции.
Анализ проекта и разработки
На соответствующих стадиях должен проводиться систематический анализ проекта и разработки в соответствии с запланированными мероприятиями (7.3.1) в целях:
a) оценивания способности результатов проектирования и разработки удовлетворять требованиям;
b) выявления любых проблем и внесения предложений по необходимым действиям.
В состав участников такого анализа должны включаться представители подразделений, имеющих отношение к анализируемой(ым) стадии(ям) проектирования и разработки. Записи результатов анализа и всех необходимых действий должны поддерживаться в рабочем состоянии (4.2.4).
Верификация проекта и разработки
Верификация должна осуществляться в соответствии с запланированными мероприятиями (7.3.1) с целью удостовериться, что выходные данные проектирования и разработки соответствуют входным требованиям. Записи результатов верификации и всех необходимых действий должны поддерживаться в рабочем состоянии (4.2.4).
Валидация проекта и разработки
Валидация проекта и разработки должна осуществляться в соответствии с запланированными мероприятиями (7.3.1) с целью удостовериться, что полученная в результате продукция соответствует требованиям к установленному или предполагаемому использованию, если оно известно. Где это практически возможно, валидация должна быть завершена до поставки или применения продукции. Записи результатов валидации и всех необходимых действий должны поддерживаться в рабочем состоянии (4.2.4).
Управление изменениями проекта и разработки
Изменения проекта и разработки должны быть идентифицированы, а записи должны поддерживаться в рабочем состоянии. Изменения должны быть проанализированы, верифицированы и валидированы соответствующим образом, а также одобрены до внесения. Анализ изменений проекта и разработки должен включать в себя оценку влияния изменений на составные части и уже поставленную продукцию. Записи результатов анализа изменений и любых необходимых действий должны поддерживаться в рабочем состоянии (4.2.4).
Закупки
Процесс закупок
Организация должна обеспечивать соответствие закупленной продукции установленным требованиям к закупкам. Тип и степень управления, применяемые по отношению к поставщику и закупленной продукции, должны зависеть от ее воздействия на последующие стадии жизненного цикла продукции или готовую продукцию.
Организация должна оценивать и выбирать поставщиков на основе их способности поставлять продукцию в соответствии с требованиями организации. Должны быть разработаны критерии отбора, оценки и повторной оценки. Записи результатов оценивания и любых необходимых действий, вытекающих из оценки, должны поддерживаться в рабочем состоянии (4.2.4).
Информация по закупкам
Информация по закупкам должна описывать заказанную продукцию, включая, где это необходимо, требования:
a) к официальному одобрению продукции, процедур, процессов и оборудования;
b) к квалификации персонала;
c) к системе менеджмента качества.
Организация должна обеспечивать достаточность установленных требований к закупкам до их сообщения поставщику.
Входные данные для проектирования и разработки
Входные данные, относящиеся к требованиям к продукции, должны быть определены, а записи должны поддерживаться в рабочем состоянии (4.2.4). Эти данные должны включать:
a) функциональные и эксплуатационные требования;
b) соответствующие законодательные и обязательные требования;
c) там, где это целесообразно, информацию, взятую из предыдущих аналогичных проектов;
d) другие требования, важные для проектирования и разработки. Эти входные данные должны анализироваться на адекватность. Требования должны быть полными, недвусмысленными и непротиворечивыми.
Выходные данные проектирования и разработки
Выходные данные проектирования и разработки должны быть представлены в форме, позволяющей провести верификацию относительно входных требований к проектированию и разработке, а также должны быть утверждены до их выпуска.
Выходные данные проектирования и разработки должны:
a) отвечать входным требованиям к проектированию и разработке;
b) обеспечивать соответствующей информацией по закупкам, производству и обслуживанию;
d) определять характеристики продукции, существенные для ее безопасного и правильного использования.
История работ в области качества в России.
Говоря о передовом опыте в области управления качеством, нельзя не вспомнить об отечественной практике совершенствования качества.
Какие концепции повышения качества существовали в нашей стране?
1. Концепция БИП (Бездефектного Изготовления Продукции) В основу этой системы был положен механизм активизации участников производственного процесса, стимулирующий их к выявлению и устранению не дефектов продукции, а их причин. После повторного предъявления продукции рабочий лишался премии.
2. Концепция КАНАРСПИ (Качество, Надежность, Ресурс с Первых Изделий) Была внедрена на Горьковском авиационном заводе. Признанная лучшей в стране, система базировалась на следующих принципах:
· универсальность (возможность использования в других отраслях промышленности)
· комплексное обеспечение качества продукции
· проведение исследований, направленных на повышение качества продукции и развитие опытно-конструкторских служб предприятия
· организация всестороннего учета качества выпускаемой продукции
· концентрация внимания на качестве продукции на стадии ее разработки
· привлечение к совершенствованию продукции потребителей
1. Концепция НОРМ В середине 1960-х гг. на Ярославском моторном заводе «Автодизель» была внедрена система НОРМ, в которой за критерий качества был принят один из важнейших технических параметров - ресурс до первого капитального ремонта. Особое внимание уделялось разработке конструкции и технологии, обеспечивающих повышение технического уровня и качества двигателя. В системе НОРМ были использованы и развиты основные элементы Саратовской и Горьковской систем управления качеством выпускаемой продукции.
2. Концепция КСУКП (Комплексная система управления качеством продукции)
В первой половине 1970-х гг. в результате совместного научно-производственного эксперимента предприятий Львовской области, ВНИИ стандартизации Госстандарта СССР и научно-производственного объединения «Система» была разработана и прошла апробацию комплексная система управления качеством продукции.
Главная цель системы заключалась в обеспечении высоких и устойчивых темпов роста качества продукции, выпускаемой предприятием, за счет:
· создания и освоения новых высококачественных видов продукции;
· своевременной постановки на производство новой продукции;
· снятия с производства морально устаревшей продукции;
· улучшения показателей качества выпускаемой продукции путем ее совершенствования и модернизации.
В чем заключалась специфика Российского опыта управления качеством?
Специфика управления качеством в России заключалась в том, что эффективные системы управления качеством создавались на предприятиях военно-промышленного комплекса (ВПК). Именно в ВПК были распространены методы обеспечения качества на стадиях исследования и проектирования новой продукции, статистический контроль качества с применением контрольных карт, специальные стандарты. В недрах ВПК родились КСУКП (комплексные системы управления качеством продукции, в том числе автоматизированные).
СМК: Управление несоответствующей продукцией.
Методика управления несоответствующей продукцией.
1) определяем продукцию, включаемую в область применения СМК,2) определяем, что такое соответствующая продукция,3) определяем, какие механизмы управления применимы к какой продукции (можно в виде таблицы),4) подробно описываем эти механизмы в применении к конкретной продукции: кто за что отвечает, какими полномочиями обладает, что делает.
Пока продукция у нас.
Что мы можем сделать для обеспечения соответствия продукции, когда обнаружено несоответствие?
Первое очевидно: исправить. т.е. в терминах ISO 9000 осуществить коррекцию. Но это не всегда возможно.
Тогда второе: оценить, насколько несоответствие препятствует преднамеренному использованию продукции, и, если приемлемо, то разрешить отклонение. Если возможно, то разрешение на отклонение запрашивается еще и у потребителя, согласен ли он. Заказчик, проанализировав, какие именно функции будут отсутствовать, может счесть это вполне приемлемым и дать разрешение.
Если ни первое, ни второе невозможно, то остается третий вариант: изменить первоначальное применение или вообще отказаться от применения продукции.
Очевидно, что процедуру управления несоответствующей продукцией невозможно полноценно разработать, если
не определена сама продукция, качеством которой управляем в рамках СМК,
не определено, что такое соответствующая продукция, ибо это равносильно тому, что не определена несоответствующая продукция.
Из опыта аудирования: если я из руководства по качеству не могу понять, какая конкретно продукция включена в область применения СМК, то я могу даже не смотреть процедуру управления несоответствующей продукцией, заранее гарантируя, что она формальна.
Механизмы управления в каждом из трех случаев:
Изменить продукцию (коррекция)
указать способ идентификации несоответствующей продукции и ответственного за эту идентификацию,
указать ответственного за предотвращение выпуска и поставки идентифицированной несоответствующей продукции и его полномочия,
указать ответственного за коррекцию,
установить процедуру повторного контроля и ответственного за ее выполнение,
установить, в какой форме делается запись о характере несоответствия и решении о коррекции.
Изменить требования
указать уполномоченного на дачу разрешения на отклонение и его полномочия, а также установить процедуру такого разрешения, включая установление лица, уполномоченного потребителем давать разрешение на отклонение,
установить, в какой форме делается запись о характере несоответствия и разрешении на отклонение.
Изменить применение
установить ответственного за предотвращение первоначального применения потребителем несоответствующей продукции и его полномочия, а также процедуру такого предотвращения,
установить, в какой форме делается запись о характере несоответствия и действиях по предотвращению первоначального применения.
Продукция у потребителя.
Очевидно, что в данной ситуации ни один из описанных выше механизмов не применим: продукция вышла из-под нашего контроля. Все, что мы можем в данном случае, это предпринять действия, снижающие негативные последствия или риск таких последствий для потребителя. В качестве примера тут можно привести всем известные компании по отзыву автомобилей.
Популярное
- Николай михайлович карамзин
- Где можно работать с образованием управление персоналом
- Возможные названия вакансий Можно ли работать и быть ИП одновременно
- Один комментарий на запись “Всегда на связи!
- Нематериальная мотивация продавцов Бонусы для продавцов от производителя
- Как заставить клиента заплатить
- Монополии: примеры в мире и в России
- Под «покровом» Коровайко Коровайко андрей викторович биография
- Формирование системы управления § коллеги и работники, имеющие структурные взаимосвязи с оцениваемыми
- Производственная вибрация