Программа качества (план качества)

я пришла к выводу, что план качества это те записи, которые есть, но они управляются в контексте единого проекта/процесса. Сделаны для того, чтобы человек не путался в этих записях если ему нужно выполнить определенную работу. А в этом плане качестве четко указано, что да как.

План (в частности и план качества) становится записью (по ИСО 9000) тогда, когда в него заносятся данные о вы полении этого плана.

я пришла к выводу, что план качества это те записи, которые есть, но они управляются в контексте единого проекта/процесса. Сделаны для того, чтобы человек не путался в этих записях если ему нужно выполнить определенную работу. А в этом плане качестве четко указано, что да как.
Только вот вопрос, если это так, та зачем разрабатывать карты процедур и процессов, в которых написано то же самое. Или они и есть планы качества. Хотя в этом же руководстве говорится, что по мимо процедур и инструкции есть еще и планы качества. Я запуталась, помогите, кто знает.

действительно запутались, про планы качества см. ISO 10005:2005

Откуда. Казахстан, Алматы

Большое спасибо за ссылку на ИСО 10005:2005", но в этом и суть, что с этого стандарта я и начала читать о планах качества.
Существовала у нас СМК и без официального названия План качества, ну вот я прочитала о нем и мне захотелось узнать что это такое. В ИСО 10005:2005 говорится, что план качества это такой документ в котором могут быть пункты:

4: План качества в виде текста (для разработки программного обеспечения, для дисплея, устанавливаемого на подставке)

1 Область применения
Цель данного плана качества заключается в определении методов менеджмента качества, применимых к контракту между фирмой и ее клиентом на систему распределения одежды.
a) Включено
Данный план качества применим разработке и поставке подсистем распределения, управления скидками и маркетинга. Системы управления финансами являются предметом субподрядного договора с субпоставщиком, и поэтому данный план качества касается исключительно вопросов менеджмента субподрядного договора этой части проекта.
b) Исключено
Работа по разработке системы, которую выполняет субпоставщик, предусмотрена заказом на поставку и подробно не рассматривается в этом плане.

2 Цели качества
Заказчик не предъявил никаких особых требований относительно количественного определения целей качества. Таким образом должен применяться стандарт фирмы на выпуск программного обеспечения с неустановленными дефектами категории А, В и С по соглашению с заказчиком. Дефект определяется как характер изменения функции в системе, который является свидетельством несоответствия продукции согласованным требованиям.
Кроме того, также должно учитываться стремление фирмы ввести системы в эксплуатацию в пределах 5% договорного срока на основе предусмотренного договором фактического времени работы системы.

3 Ответственность
Руководитель проекта несет полную ответственность за успешное выполнение проекта, включая обеспечение его соответствия системе менеджмента качества,
действующей в компании, и достижению поставленной цели.
Менеджер по качеству отвечает за аудит проекта и за последующие корректирующие действия на основе аудиторских проверок. Любое необходимое отклонение от системы менеджмента качества должно быть санкционировано менеджером по качеству до того, как это отклонение будет введено в действие.

4 Документация
Некоторые документы для этого проекта содержат ссылки, которые не соответствуют последним требованиям системы менеджмента качества. Действующие ссылки должны сохраняться. Во всех остальных случаях применяется система менеджмента качества.

5 Регистрация данных
Файл проекта и соответствующие данные должны сохраняться в течение, по меньшей мере, 3 лет после истечения гарантийного срока. Их удаление должно проводиться с согласия заказчика. В соответствии с политикой фирмы заказчик может просмотреть зарегистрированные данные, касающиеся выполнения контракта в любое удобное время. Все относящиеся к контракту компьютерные файлы должны поддерживаться, по крайней мере, еженедельно.

6 Ресурсы
Заказчик должен представить образец форм OCR (по крайней мере, 2000), которые будут использоваться при тестировании программы считывания, поставляемой как часть системы. Субпоставщик должен получить и ввести в действие программу считывания, являющуюся частью источника системы управления финансами. Компания разработчиков должна состоять из сотрудников фирмы. В соответствии с этим менеджер по людским ресурсам должен привлекать к работе квалифицированный персонал для выполнения требований к проекту. Менеджером проекта является Дж. Смит.

7 Входные данные для проекта
Исходными данными являются Технические условия KLOB-D-001, разработанные консультантами заказчика. Для ознакомления фирме должны быть представлены документы по маркетингу и ежегодные отчеты.

8 Связь с заказчиком
Все вопросы, касающиеся технических условий должны обсуждаться с заказчиком на совещаниях по проекту через менеджера проекта. Их решение является окончательным. Заказчик не имеет информации о технических характеристиках программного обеспечения, все технические вопросы должны решаться через менеджера проекта или его представителя. Документы совещаний по проекту должны готовиться менеджером проекта. Аналогично, связь с потребителем (вопросы, жалобы или поощрения) должна осуществляться через менеджера проекта

9 Проектирование и разработка
План проекта должен быть представлен в соответствии с календарным планом. Критическими сроками являются приемочные испытания заказчика (к концу октября) и развертывание системы (до апреля следующего года). Должны применяться все фирменные стандарты, на которые дается ссылка в руководстве по разработке программного обеспечения. Анализ и утверждение должны соответствовать требования руководства по качеству.
Заявки на внесение изменений в проект, которые с точки зрения заказчика влияют на работу системы, должны быть утверждены на фирме. Подробности изменений, вносимых в проект заказчиком и фирмой, должны быть одобрены менеджером проекта до начала работы над ним.
Подход к тестированию должен соответствовать требованиям, содержащимся в руководстве по качеству фирмы. Для тестирования программы сбора данных потребуется программа считывания. Для окончательных испытаний маркетинговой подсистемы потребуется дисплей на подставке, чтобы проверить реакцию заказчика. Система распределения в целом должна быть протестирована на фирме перед отправкой и приемкой заказчиком на своем предприятии.

10 Закупки
Все оборудование должно закупаться заказчиком (компьютеры через субпоставщика, другое оборудование напрямую). Все другие закупки должны производиться в соответствии с правилами, действующими на фирме.

11 Сборка и ввод в действие
Программа считывания должна быть передана заказчику. Информация в базу данных заказчика должна заноситься после стендовых испытаний. Пока сотрудники фирмы-заказчика не ознакомятся с работой систем, им может потребоваться поддержка при первой сборке.

12 Особые процессы
В этом проекте не содержит особых процессов.

13 Менеджмент конфигурации
Идентификаторы документа должны соответствовать версии руководства по качеству той организации, где был запущен проект, за исключением документов, которые уже были идентифицированы ранее.

14 Собственность заказчика
Любое оборудование, принадлежащее заказчику, должно быть соответствующим образом идентифицировано, пока оно находится во владении фирмы или субпоставщика. Любая собственность заказчика должна быть указана в журнале регистрации проекта.

15 Обращение с продукцией
Программное обеспечение должно поставляться на CD-ROM. Все CD должны быть проверены на вирус.

16 Несоответствия
Ни один программный продукт не должен поставляться с выявленными несоответствиями, кроме косметических, без письменного согласия заказчика. Процедура должна соответствовать требованиям руководства по качеству фирмы и руководства по разработке системы.

17 Мониторинг и измерение
Ход работы над проектом должен заноситься в контрольные листы и регистрироваться в графике работы над проектом еженедельно. Отчет о ходе работы должен быть подготовлен и представлен на совещании с участием заказчика. На отдельные встречи должен приглашаться субпоставщик. Руководитель команды, занимающейся программированием, должен регистрировать любые проблемы, возникающие при тестировании второго и третьего уровня. Необходимо классифицировать проблемы по их происхождению: технические условия (недостающие или неправильные); проектирование (недостаточное или неправильное); программирование (недостаточное, нелогичное, ошибка интерфейса, ошибка при обработке данных).

18 Внутренний аудит
В конце стадии проектирования должны быть проведены аудиторские проверки реализации и эффективности плана качества.
План качества разработан менеджером проекта Программы распределения заказчика и применим ко всем работам, выполняемым по контракту.

Автор Дата
Менеджер по качеству Дата
Документ № KLOB-QP-001 Версия 1

Обратите внимание, что целью данного плана качества является
- определение методов менеджмента качества, применимых к контракту между фирмой и ее клиентом на систему распределения одежды.

Зачем определять методы, которые уже определены в других регламентирующих документах. Зачем опять все описывать.

Если план качества - это запись, почему в стандарте (в примере) говорится, что этот документ определяет методы?

Мне кажется я прочитала все, что могла найти по планам качества на этом сайте, может кто - нибудь по-простому объяснить, что это такое. Я понимаю, что человеку знающему, это кажется настолько простым и банальным, я прошу поделиться с этой простой формулой понимания. Большое спасибо за все.

Огромное спасибо за совет!
Однако моя просьба не случайна и стандарты связанные с планами качества как ИСОшный так и IEEE, да и PMBoK прочитаны. Но. стандарты есть стандарты: советы в них мало конкретные, примеры как-то далеки от реальности. Читаешь, и единственное ценное, что можно почерпнуть так это то, что планы по качеству бывают разные, а мы можем делать и так и эдак, в общем как хотим
Переписать разделы РК в план по качеству проекта и просить настоятельно каждого руководителя проекта к своему проекту помимо Устава, общего плана работ, иерархической структуры работ, плана конфигурации, управления рисками и еще тучу бумаженций- писать еще талмуд под названием План по качеству проекта- не подымается рука. Да еще и план по качеству с такими информативными разделами как цели по качеству проекта, политика в области качества, даже если не расписывать, а ограничиться ссылками- все равно пустая трата бумаги и времени. Как мне кажется подобный план должен содержать поменьше лирики, вещь должна быть ёмкая, регламентировать только то, что нужно. А именно работы, которые хотим проверить, стандарты, которым должны соответствовать, результаты работ, метрики результатов, чтоб проверить получили ли мы то, что хотели или нет, сроки проверки,ответственный за проверку, ну и в таком духе.ничего лишнего,только самое основное.
Так мне кажется. Но это сугубо ощущения. Потому и хотелось посмотреть настоящий реальный план по качеству, по возможности для проектной деятельности. То чем реально пользуются на практике в организациях подобной нашей.
Как-то так

Посмотрите план обеспечения качества здесь на клубке и поищите в интернете.

И Вам за совет спасибо=)
На клубке уже смотрели.
Поискать в интернете?)))ну неужели можно предположить, что я сначала написала в форум просьбу, а погуглить не догадалась=)
К моему безумному сожалению, приличного полноценного примера такого плана в интернете найдено не было.

хотелось посмотреть настоящий реальный план по качеству, по возможности для проектной деятельности. То чем реально пользуются на практике в организациях подобной нашей.
Как-то так

Если вас не удовлетворили
- Программа обеспечения качества (план реализации) подготовленная Службой обеспечения качества Отделения космических систем
- Курс ЛЭТИ по CMMI

Потому и хотелось посмотреть настоящий реальный план по качеству, по возможности для проектной деятельности.

Сомневаюсь, что Вас удовлетворит конкретный ПОКАС

К моему безумному сожалению, приличного полноценного примера такого плана в интернете найдено не было.

в большинстве случаев это, скажем так, конфиденциальная информация.
как правило ПОК не внутренняя потребность, а контрактное требование

И конечно хотелось увидеть реальный план, которым пользовались действительно, а не привели в качестве примера в стандарте.
Кстати в нашем случае план по качеству вовсе не требование определенного заказчика, а собственное желание улучшить свою деятельность

ИМХО это Вам не поможет. Quality plan это план обеспечения качества продукции а не качества деятельности. Качество деятельности обеспечивается системой менеджмента этой деятельности

Я бы конечно поспорила с Вами, потому как уж больно максималистское заявление. Но догадываюсь, что спорить с Вами у меня не хватит авторитета.

Авторитет здесь ни при чем. Если у Вас есть аргументы, выкладывайте.

ИМХО, просто процитирую "План качества (программа обеспечения качества)- документ, точно определяющий, какие процессы, процедуры и соответствующие ресурсы к какому объекту и в какие сроки должны быть применены для соответствия требованиям проекта, продукции, процесса или контракта. (ГОСТ Р 10005)". Так что говорить о том, что ПК обеспечивает только качество продукции- как-то немного упрощенно.

деятельность, которую Вы собираетесь совершенствовать вне конкретного проекта, продукции, процесса или контракта.

P.S. План обеспечения качества обеспечивает нужный уровень качества, улучшение деятельности идет по другим планам качества, которые вытекают из политики в области качества.

назначение плана качества - удовлетворение требованиям конкретного проекта, продукции, процесса или договора. Значит, поддержание и развитие процессов СМК вообще, или увеличение результативности процессов СМК - не являются целями плана качества (хотя могут являться его результатом). Ключевое слово здесь "конкретного".

Видимо, тут различное понимание значения слова "деятельность". А также остального набора терминов.

В моем случае, речь идет о плане качества проекта. Для нас введение практики подготовки планов качества для проектов - нововведение.
Потому не вижу противоречия в своем высказывании, что план качества поможет нам улучшить нашу проектную деятельность .

План обеспечения качества проекта позволит обеспечить качество данного проекта на заданном уровне.
улучшение проектной деятельности это несколько другая деятельность, не обеспечение качества конкретного проекта.
как проектная деятельность связана к отдельно взятым конкретным проектом, портфелем проектов, всем множеством проектов, выполняемым проектной организацией?

Если для любого проекта обеспечение качества будет планироваться и выполняться- это ли не улучшение?

если прежде качество проекта не выполнялось, то будет улучшением в случае обеспечения качества первого проекта, для последующих улучшением уже не будет.

правильно, для последующего проекта это уже будет деятельность,вошедшая в постоянную практику. Но в целом, это шаг на ступень выше,лучше и хотя бы ближе ко второму уровню CMMI=) Маленький шажочек,но все же=)

В результате имеем план обеспечения качества одного проекта, но где же план по улучшение проектной деятельности.

P.S. И будет ли ПОК реальным улучшением проектной деятельности? какую реальную/потенциальную проблему он устраняет?

А зачем? В годовом плане совершенствования деятельности организации, вероятно, вполне достаточно раздела по проектной деятельности и её улучшению=)

достаточно кому и для чего?
ведь улучшение надо проверять, т.е. смотреть динамику
- сокращения проектов с недостаточным качеством за счет отсутствия ПОК
- увеличения проектов с достаточным качеством, за счет применения ПОК.

но самое главное, кто потребитель ПОК? и только затем кто его разработчик?

Динамику улучшений посмотрим в отчете по функционированию смк с данными по всем проектам.

Цель планирования качества- удостовериться в том, что продукт/результат проекта будет соответствовать планируемым целевым показателям. (это надо и руководителю проекта,это надо и заказчику)

Если это надо и заказчику, то при чем тут указанная Вами чисто внутренняя потребность в ПОК.

Так и заказчик: он не требует план качества, но его наличие даст ему уверенность в соответствии результата требованиям=)
К тому же в заинтересованных лицах был указан не только заказчик, но и руководитель проекта

между заинтересованными в документе лицами и потребителем документа, т.е. тем кто будет применять этот документ очень большая разница.
ПОК не для демонстрации, а для снижения рисков необеспечения качества результата проекта.
Руководитель проекта осуществляет цикл PDCA, разработка плана проекта и разработка ПОК проекта его функционал,
какая добавленная ценность ПОКа для руководителя проекта?

К чему эти вопросы,если у Вас есть на них готовые ответы? Скажите как надо и в чем мы не правы.

Ответы есть,
Но сказать как надо может только Ваш биг босс.

Что касается улучшения деятельности по разработке программного обеспечения более привлекательна методология Agile software development.

Что касается ПОК, то как метод улучшения качества валидируемой деятельности требует очень деликатного применения и понимания специфики software development.

А если это не тайна то, может быть на словах расскажите, что из себя этот бизнес-процесс представляет?

Добрый день.
ПОК модификаций продукции реализован на базе надстройки 1С v8.2 Управление процессами от Питер-Софт. Подробно можете посмотреть http://www.piter-soft.ru/automation/.
Внешне это похоже на электронную почту. «Почтовый» сервер и клиент реализованы на 1С. Каждому участнику процесса приходит «электронное письмо». «Письма» всегда идут по единожды утвержденному маршруту.
В модель бизнес процесса ПОК включены действия по обеспечению жизненного цикла продукции: от планирования разработки до реализации продукции потребителю.
Все этапы разделены между исполнителями. Роли исполнителей распределены между руководителями, инженерами, техниками.
В модель включены, кроме всего прочего: валидация продукции, верификация конструкции, аттестация технологической и контрольной оснастки, информирование потребителей о новой разработке через сайт компании. Управление несоответствующей продукцией отдельный процесс и в модель не включено.
Каждый следующий этап не возможно исполнить без данных предыдущего этапа. Каждый последующий исполнитель таким образом контролирует работу предыдущего. В организации назначен руководитель проекта, который контролирует, чтоб процессы «не зависали» на каком-нибудь этапе.
С апреля 2012 года запущено порядка 80 проектов.
С апреля 2012 года в модель внесено несколько улучшений.
Буду рад, если это Вам поможет.

А вы запрашивали ПОК у своего поставщика УПП1С?

Нет. УПП1С, как программный продукт, не является составной частью ни наших проектов и ни нашей продукции.

Внесение изменений в руководство по качеству пример

Рекомендации по документированию систем менеджмента качества

Технический отчет устанавливает рекомендации по разработке и поддержанию в рабочем состоянии документации, необходимой для обеспечения эффективности системы менеджмента качества и отвечающей конкретным потребностям организации. Использование рекомендаций будет полезно при создании документированной системы согласно требованию стандарта на систему менеджмента качества. Технический отчет может быть использован при документировании не только систем менеджмента по стандартам ИСО 9000, но и других систем менеджмента, например, в области экологии и охраны труда.

Предисловие
Введение
1 Область применения
2 Нормативные ссылки
3 Термины и определения
4 Документация системы менеджмента качества
4.1 Общие положения
4.2 Цели и преимущества
4.3 Политика и цели в области качества
4.4 Руководство по качеству
4.5 Документированные процедуры
4.6 Рабочие инструкции
4.7 Формы
4.8 Планы по качеству
4.9 Технические условия
4.10 Действующие документы
4.11 Записи
5 Процесс документирования системы менеджмента качества
5.1 Ответственность за подготовку документации
5.2 Требования к процедуре документирования системы менеджмента качества
5.3 Использование ссылок
6 Процесс утверждения, выпуска и управления документацией системы менеджмента качества
6.1 Рассмотрение и утверждение
6.2 Рассылка
6.3 Внесение изменений
6.4 Выпуск и управление изменениями
6.5 Неучтенные экземпляры
Приложение А Типовая структура документации системы менеджмента качества
Приложение В Пример структуры текста рабочих инструкций
Библиография

Дата актуализации текста:

Международная организация по стандартизации (ИСО) является всемирной федерацией национальных организаций по стандартизации (комитетов - членов ИСО). Разработка международных стандартов обычно осуществляется техническими комитетами ИСО. Каждый комитет-член, заинтересованный в деятельности, для которой создан технический комитет, имеет право быть представленным в этом комитете. Международные правительственные и неправительственные организации, имеющие связи с ИСО, также принимают участие в работах. Что касается стандартизации в области электротехники, ИСО работает в тесном сотрудничестве с Международной электротехнической комиссией (МЭК).

Международные стандарты разрабатываются в соответствии с правилами, приведенными в Директивах ИСО/МЭК, Часть 3.

Основной задачей технических комитетов является разработка международных стандартов. Проекты международных стандартов, принятые техническими комитетами, рассылаются комитетам-членам на голосование. Их опубликование в качестве международных стандартов требует одобрения по меньшей мере 75 % комитетов-членов, принимающих участие в голосовании.

В особых случаях, когда технический комитет собрал данные, отличающиеся от тех, которые обычно публикуются в качестве международного стандарта, он может принять решение простым большинством голосов своих членов опубликовать технический отчет. Технический отчет носит только информативный характер и не подлежит пересмотру до тех пор, пока приведенные в нем данные будут считаться обоснованными или полезными.

Обращается внимание на то, что некоторые элементы настоящего технического отчета могут быть объектом патентных прав. ИСО не берет на себя ответственность за идентификацию какого-либо или всех таких патентных прав.

Технический отчет ИСО/ТО 10013 был разработан Подкомитетом 3 «Вспомогательные технологии» Технического комитета ИСО/ТК 176 «Менеджмент качества и обеспечение качества».

Настоящее первое издание ИСО/ТО 10013 отменяет и заменяет стандарт ИСО 10013:1995 «Рекомендации по разработке руководства по качеству».

Семейство стандартов ИСО 9000 требует документирования системы менеджмента качества организации.

Технический отчет способствует принятию процессного подхода при разработке и внедрении системы менеджмента качества и улучшению ее результативности.

Для эффективного функционирования организация должна определить многочисленные взаимосвязанные виды деятельности и управлять ими. Любая деятельность, основанная на использовании ресурсов и предполагающая управление с целью преобразования входов в выходы, может рассматриваться как процесс. Как правило, выход одного процесса непосредственно образует вход следующего.

Применение в рамках организации системы процессов, предусматривающей их идентификацию и взаимодействие, а также управление ими, может рассматриваться как «процессный подход».

Преимуществом процессного подхода является постоянный контроль, который он обеспечивает в рамках взаимосвязи процессов в системе процессов, а также их комбинации и взаимодействие.

При документировании системы менеджмента качества каждая организация свободна в выборе количества и состава документов, которые ей необходимы для того, чтобы продемонстрировать эффективное планирование, функционирование, управление и постоянное улучшение системы менеджмента качества и ее процессов.

Документация системы менеджмента качества может распространяться на всю деятельность организации или на отдельные аспекты этой деятельности, например, на конкретные требования, зависящие от вида продукции, характера, процессов, условий контракта, регламентов, установленных государством или самой организацией.

Важно, чтобы требования и содержание документации системы менеджмента качества соответствовали стандартам на качество, требования которых они намерены удовлетворять.

Рекомендации настоящего технического отчета предназначены для применения организациями при документировании системы менеджмента качества и не могут быть использованы как контрактные или законодательные требования или в целях сертификации/регистрации.

Планирование качества является одним из аспектов деятельности по внедрению системы менеджмента качества. Документация по планированию качества может распространяться на административное и оперативное планирование, подготовку к внедрению системы менеджмента качества, организационные мероприятия, графики выполнения работ и средства достижения целей в области качества.

РЕКОМЕНДАЦИИ ПО ДОКУМЕНТИРОВАНИЮ СИСТЕМ МЕНЕДЖМЕНТА КАЧЕСТВА

Настоящий технический отчет устанавливает рекомендации по разработке и поддержанию в рабочем состоянии документации, необходимой для обеспечения эффективности системы менеджмента качества и отвечающей конкретным потребностям организации. Использование рекомендаций будет полезно при создании документированной системы согласно требованию стандарта на систему менеджмента качества.

Настоящий технический отчет может быть использован при документировании не только систем менеджмента по стандартам ИСО 9000, но и других систем менеджмента, например, в области экологии и охраны труда.

Примечание. Процедура, процесс документирования которой завершен, называется «письменной процедурой» или «документированной процедурой».

Данный нормативный документ содержит положения, которые посредством ссылок в данном тексте составляют положения настоящего технического отчета. Для датированных ссылок применение последующих публикаций этого документа, содержащего изменения или пересмотренного, не приемлемо. Поэтому сторонам соглашений, базирующихся на данном техническом отчете, рекомендуется пользоваться последним изданием ссылочного нормативного документа. Для недатированных ссылок всегда следует применять последнее издание нормативного документа. Члены ИСО и МЭК ведут перечни действующих международных стандартов.

ИСО 9000:2000. Системы менеджмента качества. Основные положения и словарь.

В данном техническом отчете используются термины и определения, приведенные в стандарте ИСО 9000 и ниже в тексте. В системе менеджмента качества организации допускается использование других терминов для определенных видов документации.

3.1рабочие инструкции

подробное описание порядка выполнения и ведения записей заданий.

ПРИМЕЧАНИЕ 1. Документирование рабочих инструкций не обязательно.

ПРИМЕЧАНИЕ 2. К рабочим инструкциям могут быть отнесены, например, пояснительные записки, карты технического процесса, габаритные планы, модели, технические записки к чертежам, технические условия, инструкции по эксплуатации оборудования, плакаты, видеоматериалы, перечни или любое их сочетание. Рабочие инструкции могут содержать характеристики используемых материалов, оборудования и документации. В случае необходимости в них могут быть включены критерии приемки.

документ, в который вносятся данные, требуемые системой менеджмента качества.

ПРИМЕЧАНИЕ. После заполнения форма становится записью.

классификация документации системы менеджмента качества может строиться на основе протекающих в организации процессов или на структуре внедряемого стандарта качества, а также на их сочетании. Возможно использование других классификаций, отвечающих потребностям организации.

Технический отчет рекомендует описывать структуру документации системы менеджмента качества как иерархическую. Такая структура способствует распределению, поддержанию в рабочем состоянии и усвоению документации. Приложение А иллюстрирует типовую структуру документации системы. Проработка уровней и взаимосвязей зависит от особенности сопутствующих деятельности организации условий.

Степень документированности систем менеджмента качества разных организаций может различаться в зависимости от:

a) размера и вида деятельности организации;

b) сложности и взаимодействия процессов;

c) компетентности персонала.

В документацию системы менеджмента качества могут включаться определения со ссылкой на стандарт ИСО 9000 или общепринятые термины и определения.

Документация системы менеджмента качества включает:

a) политику и цели в области качества;

b) руководство по качеству;

c) документированные процедуры;

d) рабочие инструкции;

f) планы по качеству

g) технические условия;

h) действующую документацию;

Документация системы менеджмента качества может быть представлена в любой форме и на любом носителе.

ПРИМЕЧАНИЕ. Документирование на электронных носителях имеет следующие преимущества:

a) постоянный доступ уполномоченного персонала к актуализированной информации;

b) доступ и внесение изменений легко обеспечиваются и контролируются;

c) распространение и контроль могут осуществляться при первой необходимости путем распечатки копий;

d) доступ к документации отдаленных подразделений;

e) простота и эффективность аннулирования устаревших документов.

Цели и преимущества документирования системы менеджмента качества предусматривают, но не ограничиваются следующим:

a) описание системы менеджмента качества организации;

b) обеспечение информацией взаимодействующих групп с целью лучшего понимания взаимосвязей;

c) доведение до персонала информации об обязательствах руководства в области качества;

d) содействие осознанию работниками их места в организации, позволяя тем самым почувствовать важность их работы;

e) обеспечение взаимопонимания между персоналом и руководством;

f) обеспечение базы для достижения ожидаемых результатов;

g) установление порядка проведения работ для выполнения принятых требований;

h) обеспечение объективных свидетельств выполнения принятых требований;

i) обеспечение четкой, эффективной структуры операций;

j) организационное обеспечение обучения вновь нанимаемых работников и периодической переподготовки;

k) осуществление мер по установлению порядка и сбалансированности действий в организации;

l) обеспечение последовательности операций, основанных на документированных процессах;

m) обеспечение базы для постоянного улучшения;

n) обеспечение доверия потребителей на основе документированных процедур системы;

o) предоставление заинтересованным сторонам информации о возможностях организации;

р) обеспечение ясной для потребителя структуры требований;

q) создание основы для проведения аудита системы менеджмента качества;

r) обеспечение условий для оценивания результативности и постоянно поддерживаемого соответствия системы менеджмента качества.

Политика и цели в области качества должны быть задокументированы в виде самостоятельного документа или включены в руководство по качеству.

Каждая организация должна разработать свое руководство по качеству. Настоящий технический отчет допускает независимо от типа организации гибкость в определении структуры, формата, содержания или метода документирования системы менеджмента качества.

Для малой организации целесообразно дать в руководстве полное описание системы менеджмента качества, включая все требуемые ИСО 9001 документированные процедуры. Крупным транснациональным организациям возможно понадобится разработать несколько руководств (для международного, национального или регионального направлений деятельности) и более сложная иерархия документов.

Руководство по качеству должно содержать область применения системы менеджмента качества, детальное обоснование любого исключения, документированные процедуры или ссылки на них, а также описание процессов, охватываемых системой менеджмента качества, и их взаимодействия.

В руководство по качеству следует включить информацию об организации, в том числе ее название, адрес, данные для связи. Может быть приведена дополнительная информация, например, направление деятельности, историческая справка, сведения о размере организации.

Руководство по качеству должно содержать элементы, предусмотренные пунктами 4.4.2 - 4.4.9. но не обязательно в указанном порядке.

4.4.2Название и область применения

Название и/или область применения руководства по качеству должны указывать, какая организация будет его применять. В руководстве должна быть сделана ссылка на стандарт, на основе которого разрабатывается система менеджмента качества.

В оглавление руководства по качеству должны быть вынесены номер и название каждого раздела и номера страниц, на которых эти разделы расположены.

4.4.4Рассмотрение, утверждение и пересмотр

Руководство должно содержать точные сведения о рассмотрении, утверждении, статусе и дате пересмотра документа.

В случае необходимости характер изменений должен быть указан в документе или его приложениях.

4.4.5Политика и цели в области качества

Если организация принимает решение включить в руководство по качеству политику в области качества, руководство может содержать заявление о политике и целях в области качества. Показатели, конкретизирующие эти цели могут быть по решению организации включены в другие документы системы менеджмента качества. Политика в области качества должна содержать обязательства соответствовать требованиям и постоянно повышать результативность системы менеджмента качества.

Цели, как правило, исходят из политики организации в области качества и должны быть достижимыми. Когда цели представлены в количественном выражении, они становятся показателями и их можно измерять.

4.4.6Организация, ответственность и обязанности

В руководстве по качеству должна быть описана структура организации. Ответственность, обязанности и взаимосвязи могут быть представлены в виде организационных схем, технологических процессов и/или рабочих инструкций. Они могут быть включены в состав руководства или на них должны быть сделаны ссылки.

Руководство по качеству должно содержать перечень используемых, но не включенных в него документов.

4.4.8Описание системы менеджмента качества

В руководстве по качеству должно быть дано описание системы менеджмента качества и ее внедрения в организации. В руководство по качеству следует включить описание процессов и их взаимодействие. Документированные процедуры или ссылки на них также должны быть включены в руководство по качеству.

Организация должна документировать разрабатываемую систему менеджмента качества в соответствии либо с технологическим процессом, либо со структурой выбранного стандарта, либо в любой иной последовательности, отвечающей потребности организации. Полезно использовать перекрестные ссылки на выбранный стандарт и руководство по качеству.

В руководстве по качеству должны быть отражены методы, применяемые организацией для выполнения политики и целей в области качества.

В руководство по качеству могут быть включены приложения, содержащие вспомогательную информацию.

4.5.1 Структура и формат

Структура и формат документированных процедур (на бумажном или электронном носителе) должны быть представлены организацией в виде текстов, схем, таблиц, их сочетания или в другой приемлемой форме в зависимости от потребностей организации. Документированные процедуры должны содержать необходимую информацию (см. 4.5.2 ) и иметь единую идентификацию.

В документированных процедурах могут быть сделаны ссылки на рабочие инструкции, определяющие порядок выполнения работ. Документированные процедуры обычно описывают деятельность, охватывающую несколько функций, в то время как рабочие инструкции обычно относятся к заданиям в рамках одной функции.

Название должно четко указывать документированную процедуру.

Назначение документированной процедуры должно быть указано.

4.5.2.3 Область применения

Должна быть описана область применения документированной процедуры, включая охватываемые или не охватываемые ею аспекты.

4.5.2.4 Ответственность и полномочия

Должны быть определены ответственность и полномочия персонала и/или организационные функции, а также их взаимодействие с другими процессами и деятельностью, описанными в процедуре. Они могут быть приведены в виде блок-схемы и уточняющих описаний.

4.5.2.5 Описание видов деятельности

Уровень детализации описания может зависеть от сложности вида деятельности, используемых методов, уровня квалификации и подготовки персонала, необходимых для выполнения работы. Независимо от уровня детализации должны быть рассмотрены следующие аспекты:

a) определение потребностей организации, ее потребителей и поставщиков;

b) описание процессов в виде текстов и/или блок-схем, относящихся к данному виду деятельности;

c) определение работ, которые должны выполняться, кем или в рамках какой организационной функции, почему, когда, где и как;

d) описание управления процессами и контроля за идентифицированными видами деятельности;

e) выявление потребности в ресурсах, необходимых для выполнения определенной деятельности (в персонале, обучении, оборудовании и материалах);

f) определение соответствующей этому виду деятельности документации;

g) определение входа и выхода процесса;

h) определение измерений, которые следует выполнить. Организация может принять решение о целесообразности включения части приведенной выше информации в рабочие инструкции.

Ведение записей о деятельности в рамках документированной процедуры должно быть описано в этом или в другом (других) ее разделе (разделах). Должны быть определены формы для ведения записей, указаны способы их заполнения, регистрации и хранения.

К документированной процедуре может быть приложена информация в виде, например, таблиц, диаграмм, схем и форм.

4.5.3 Рассмотрение, утверждение и пересмотр

Должны быть приведены сведения о рассмотрении, утверждении, статусе и дате пересмотра документированной процедуры.

4.5.4 Определение изменений

Если практически возможно, в документе либо в соответствующих приложениях должен быть указан характер изменений.

4.6.1 Структура и формат

Рабочие инструкции должны разрабатываться и поддерживаться таким образом, чтобы обеспечивать описание выполнения всех работ, на которых отсутствие таких инструкций может повлиять отрицательно. Могут использоваться различные средства подготовки и представления инструкций.

Рабочие инструкции должны содержать название и принятое для них обозначение (информация приведена в п. 4.6.4 ).

Структура, формат и уровень детализации рабочих инструкций должны отвечать потребностям персонала организации и зависеть от сложности работ, применяемых методов, уровня подготовки, квалификации и мастерства персонала.

Структура рабочих инструкций может отличаться от структуры документированных процедур.

Рабочие инструкции могут быть включены в документированные процедуры или на них должна быть сделана ссылка.

Рабочие инструкции должны описывать критические участки деятельности. Следует избегать детализации, которая не способствует контролю за деятельностью. Подготовка персонала может снизить потребность в детализации инструкций при условии, что этот персонал получает необходимую для правильного выполнения работы информацию.

4.6.3 Виды рабочих инструкций

Хотя не существует требований к структуре или формату рабочих инструкций, эти документы обычно должны отражать назначение и область работ и их цели, а также содержать ссылки на соответствующие документированные процедуры.

В любом случае в рабочих инструкциях должна быть указана последовательность операций, точно отражающая требования и соответствующую деятельность. Во избежание недопонимания и неточностей следует установить определенный формат или структуру и придерживаться их.

Пример рабочей инструкции приведен в приложении В .

4.6.4 Рассмотрение, утверждение и пересмотр

Организация должна обеспечить точные сведения о рассмотрении и утверждении рабочих инструкций, статусе и дате пересмотра.

Если возможно, требования к записям, относящиеся к рабочей инструкции, устанавливаются в этом или в любом другом (других) разделе (разделах). Минимальные требования к записям определены стандартом ИСО 9001. Необходимо указать способы ведения, регистрации и хранения записей и определить формы для заполнения.

4.6.6 Определение изменений

Если практически возможно, характер изменений следует указать либо в документе, либо в приложениях.

Для записи данных, характеризующих соответствие требованиям системы менеджмента качества, разрабатываются и ведутся специальные формы. Каждой форме присваиваются название, номер, обозначение, указываются уровень и дата пересмотра. Если формы даются в приложениях к руководству по качеству, документированным процедурам и/или рабочим инструкциям, на них даются ссылки.

План по качеству является частью документации системы менеджмента качества. Он необходим только при документированной системе менеджмента качества и указывает, как ее следует применять в конкретной ситуации, а также определяет и документально устанавливает, как организация будет выполнять единые для продукции, процесса, проекта или контракта требования. В план по качеству могут быть включены установленные процедуры, рабочие инструкции и/или записи.

Технические условия являются документом требований. Настоящий технический отчет не рассматривает этот вид документа, так как он одинаков для любой продукции и любой организации.

Организация должна предусмотреть использование и управление действующими документами в документированной системе менеджмента качества. Такими документами могут быть: чертежная документация потребителей, технические условия, законодательные и обязательные требования, стандарты, кодексы и руководства по эксплуатации.

Предусмотренные системой менеджмента качества записи говорят о достигнутых результатах или сведения или подтверждают, что деятельность, указанная в документированных процедурах и рабочих инструкциях выполняется. Записи должны отражать соответствие требованиям системы менеджмента качества и установленным требованиям к продукции. Ответственность за ведение записей должна быть определена в документации системы менеджмента качества.

ПРИМЕЧАНИЕ. Записи обычно не включаются в процесс пересмотра, так как не подлежат изменениям.

Документация системы менеджмента качества должна разрабатываться специалистами, занятыми в процессах и осуществлении деятельности, что обеспечит лучшее понимание установленных требований и вовлеченность и заинтересованность персонала.

Изучение и применение действующих документов и ссылок на них может значительно сократить сроки разработки документации системы менеджмента качества, а также поможет выявить области несоответствий в системе менеджмента качества, которые должны быть внесены в документацию и скорректированы.

Организации, внедряющие или планирующие внедрение системы менеджмента качества, должны:

a) определить процессы, необходимые для эффективного внедрения системы менеджмента качества;

b) установить взаимодействие этих процессов;

c) задокументировать процессы, насколько это необходимо, для обеспечения эффективного функционирования этих процессов и управления ими.

Анализ процессов должен явиться обоснованием для определения необходимого в системе менеджмента качества количества документов. Документирование не должно быть самоцелью.

Соответствие установленной приложением А последовательности подготовки документации системы менеджмента качества не является обязательным, так как документирование процедур и рабочих инструкций часто осуществляется до разработки руководства по качеству.

Ниже даны примеры действий, которые могут предприниматься организацией:

a) установите, какая документация по системе менеджмента качества необходима исходя из требований выбранного стандарта;

b) соберите данные о действующих системе менеджмента качества и процессах с помощью анкетирования или интервью;

c) установите и составьте перечень документации действующей системы менеджмента качества с целью определения возможности ее использования;

d) организуйте подготовку группы работников, включив в программу изучение порядка документирования, требований стандарта на систему менеджмента качества или другие необходимые вопросы;

e) организуйте поступление дополнительной документации, включая ссылочные документы от функциональных подразделений;

f) определите структуру и формат разрабатываемой документации;

g) составьте блок-схемы процессов, охватываемых системой качества; (см. приложение В );

h) проведите анализ блок-схемы и внедрите возможные улучшения;

i) обеспечьте валидацию документации путем опытного внедрения;

j) используйте любые приемлемые для организации методы документирования системы менеджмента качества;

k) организуйте рассмотрение и утверждение документации до ее выпуска.

В случае необходимости и в целях ограничения количества документов следует включать ссылки на действующие общепринятые стандарты или другие доступные пользователям документы на систему менеджмента качества.

При использовании ссылок следует избегать процедуры пересмотра, чтобы устранить необходимость внесения изменений, вызванных пересмотром документа, на который сделана ссылка.

Документация до выпуска должна поступать на рассмотрение уполномоченных лиц, чтобы обеспечить ясность, точность и правильность ее изложения и построения. С целью учета действующей практики предполагаемые пользователи также должны иметь возможность ознакомиться с документацией и представить свои замечания. Выпускаемая документация должна утверждаться ответственными за ее внедрение лицами. На каждом экземпляре должно быть проставлено разрешение на выпуск. Сведения о процедуре утверждения документа должны сохраняться.

При рассылке документов уполномоченные лица должны обеспечить поступление к соответствующему персоналу документов, содержащих необходимую информацию для его работы. Правильной рассылке и управлению документацией может, например, способствовать присвоение серийных номеров каждому экземпляру документов, предназначенных для определенных пользователей. Такие документы, как руководство по качеству и план по качеству могут быть посланы и сторонним организациям (например, потребителям, органам по сертификации и законодательным органам).

Необходимо установить процесс инициирования, разработки, рассмотрения, контроля и внесения изменений в документацию. Внесение изменений должно проходить по той же процедуре рассмотрения и утверждения что и при первоначальной разработке документов.

При управлении выпуском и внесении изменений в документы очень важно обеспечить надлежащее утверждение документации уполномоченными лицами в соответствии с установленной процедурой. Способ внесения изменений может устанавливаться организацией.

Установленная процедура должна обеспечивать применение только надлежащей документации. В определенных случаях используемый документ может оказаться не окончательной версией. Пересмотренные документы должны быть заменены последней версией. С целью обеспечения пользователей надлежащими версиями утвержденных документов рекомендуется составить перечень основных документов и установить уровень их пересмотра.

В законодательных целях и/или для сохранения данных организация должна рассмотреть возможность ведения записей по внесению изменений в документацию.

Для использования в тендерах, сторонними пользователями и адресатами специальной рассылки, когда не предусматривается внесение изменений в документацию, следует делать соответствующее указание на таких экземплярах.

ПРИМЕЧАНИЕ. Ненадлежащее обеспечение этого процесса может привести к непреднамеренному использованию устаревших документов.

Уровень «А» описывает систему менеджмента в соответствии с заявленными политикой и целями в области качества (см. 4.3 и 4.4 ).

Уровень «В» описывает взаимосвязанные процессы и деятельность, необходимую для внедрения системы менеджмента качества.

Уровень «С» содержит подробные рабочие документы.

примечание 1. Количество уровней устанавливается в зависимости от потребностей организации.

ПРИМЕЧАНИЕ 2. Формы могут использоваться на всех уровнях структуры.

В.1Рабочие инструкции по стерилизации инструментов

Номер: Trv 2.6 Дата: 15 сентября 1997 года Пересмотр: 0

В.2Инструменты, подлежащие уничтожению

Поместите инструменты, подлежащие уничтожению (например, шприцы, иглы, ножи и инструменты для удаления ниток) в специальный контейнер. Контейнер должен быть уничтожен в соответствии с программой уничтожения отходов.

В.3Инструменты, стерилизуемые путем термообработки

В.2.1 Вытрите выделения, используя утилизируемую ткань.

В.2.2 Опустите инструменты в 10 %-ный хлорный раствор (1 децилитр хлорированной жидкости и 9 децилитров воды). Жидкость должна заменяться дважды в неделю.

В.2.3 Держите инструменты в жидкости не менее двух часов.

В.2.4 Вымойте инструменты щеткой, надев защитные перчатки.

В.2.5 Прополощите и высушите инструменты.

В.2.6 Проверьте, чтобы инструменты были в хорошем состоянии. Поврежденные инструменты должны быть отправлены в ремонт.

В.2.7 Стерилизация в пакете:

- поместите инструменты в термостойкий пакет;

- защитите острые края марлей;

- сложите пакет так, чтобы он стал тугим и непроницаемым;

- запечатайте пакет теплостойкой лентой;

- проставьте дату и установите индикатор температуры;

- положите пакет в горячую печь и оставьте на 30 минут при температуре 180 °С.

Инструменты могут быть использованы в течение месяца после стерилизации, если они хранились в должным образом запечатанном пакете.

В.2.8 Стерилизация в металлическом контейнере:

- поместите термостойкую ткань на дно контейнера для защиты инструментов;

- поместите инструменты на дно контейнера;

- установите в контейнер индикатор температуры;

- оставьте контейнер на 30 минут при температуре 180 °С. Два контейнера используются по очереди через день.

В.4Другие инструменты (например, отоскопы)

Промойте инструменты после помещения в хлорный раствор на 2 ч.

[1] ISO 9001:2000 Системы менеджмента качества. Требования

[2] ISO 9004:2000 Системы менеджмента качества. Рекомендации по улучшению деятельности.

× Помните!
Вся полученная прибыль с сайта идет на развитие проекта, оплату услуг хостинг-провайдера, еженедельные обновления базы данных СНИПов, улучшение предоставлямых сервисов и услуг портала.
Скачайте «ИСО/ТР 10013:2001. Рекомендации по документированию систем менеджмента качества» и внесите свой малый вклад в развитие сайта!

© СНИПОВ.нет 2016. Все права защищены.
Перепечатка материалов сайта только с разрешения правообладателей.