Внедрение | Разработка СМК

Добрый день!

В процессе кризиса была смена сотрудников, не было четких задач, etc. СМК не поддерживалась. Вот я теперь разгребаю эту ситуацию. Помогите выбрать направление движения:
1. Заявить, что СМК не работало и новым числом выполнить необходимые действия?
2. Или оформить часть документов задним числом?

Первый вариант привлекает своей простотой, но пока нет понимания как это оформить грамотно.

и не первый и не второй.

а запуск цепочки..

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

ну единственное что задним числом, перенести даты аудита в связи с кризисом и отсутствием необходимых ресурсов

Здравствуйте, коллега!! Однозначного ответа для Вас нет. Нужно обладать дополнительной информацией.
Но в любом случае Вам необходимо понять чем дышит Ваше руководство. Результаты разговора определят дальнейшие Ваши действия. Это банальная и прописная истина, но без нее никуда.

ListoshinSB писал(а):

Добрый день!

В процессе кризиса была смена сотрудников, не было четких задач, etc. СМК не поддерживалась. Вот я теперь разгребаю эту ситуацию. Помогите выбрать направление движения:
1. Заявить, что СМК не работало и новым числом выполнить необходимые действия?
2. Или оформить часть документов задним числом?

Первый вариант привлекает своей простотой, но пока нет понимания как это оформить грамотно.

Здравствуйте! Дело не в "оформить грамотно", а в "понять, что произошло". СМК не поддерживалась - к чему это привело? Увеличение несоответствий (брака продукции)? Рост претензий потребителей? Штрафы надзорных органов? Сравните с предыдущим, соответствующим по продолжительности, "благополучным" периодом (когда СМК поддерживалась). Одного аудита, как считает высказавшийся первым коллега, недостаточно. Нужен комплексный анализ. И лучше, если его сделают компетентные сторонние специалисты (на них, кстати, и свалить проблемы можно как на дохлую лошадь - "эксперты рекомендуют"). Мы не раз этим занимались, и не без пользы, которую замечало даже дистанцировавшееся от СМК высшее руководство предприятия.
Ну, и извините уж, если поддерживать СМК возможно путем оформления документов задним числом, так, может, ну ее такую СМК...Не СМК и была!

denews писал(а):

SvetlanaV писал(а):

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

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

ZHukov писал(а):

все зависит от ваших личных возможностей и подготовки
Если сможете (хватает знаний и опыта), то оцените сами остатки Вашей СМК конечно комиссионно из состава подготовленных специалистов
Если этого нет, то наймите по договору специалиста (можно из органа по сертификации той системы сертификации в которой хотите сертифицироваться
Оплату можно договориться 60 на 40 до и после аудита
Я практиковал проведение такого аудита. Отличие этого аудита от сертификационного - нанятых специалист смотрит все (в отличии от органа по сертификации, который смотрит выборочно)
Специалист провести такой аудит может за 4-10 дней (все зависит от тех задач, которые определите ему вы, размера вашей организации, видов деятельности и т..д.)
Что необходимо вам (ему) оценить:
1 соответствие документации СМК требованиям ГОСТ Р ИСО 9001-2008
2 достаточности документации СМК для выполнения деятельности (не секрет, что руководства по качеству и 6 документированных процедур не достаточно для нормального функционирования СМК) Только не требуйте необходимый перечень - это уже консалтинг а не оценка
3 предполагаемый перечень работ для возобновления работоспособности СМК
4 и.т.д.

Здравствуйте, коллеги. Еще раз уточняю: речь шла об СМК или о совокупности документов, предъявляемых на сертификацию? Цель внедрения и поддержания СМК сводится только к цели пройти аудит? Если так, то да - можно оплатить неэтичный труд "специалиста из ОС". Правда, толку будет немного. Вам же нужно не только оценку получить типа "нет, Ваша система пока к сертификации не готова". Можно "сэкономить" и провести "комиссионый"аудит. Толку не будет вовсе, поскольку комиссия - безупречный способ размыть ответственность и не принять решения. А если хочется, чтобы система заработала - то стоит пригласить нормального консультанта, оговорив с ним конкретные требования к составу и содержанию его услуг, ограничив его на первом этапе рамками:
- анализа приемлемости примененной модели СМК и идентификации необходимых для нее процессов,
- экспертизы документации СМК на адекватность,
- проверки осуществления мониторинга, контроля и анализа процессов СМК,
- необходимости и достаточности ведущихся записей.
По результатам - смотреть, можете ли Вы привести в соответствие систему собственными силами.

Здравствуйте!
Начала писать дипломную работу "Разработка руководства по качеству" для санатория. Подскажите, пожалуйста, какие документы мне следует проанализировать. (В санатории до данного момента отдела по качеству и специалистов не было)

SvetlanaV писал(а):

Здравствуйте, коллеги. Еще раз уточняю: речь шла об СМК или о совокупности документов, предъявляемых на сертификацию? Цель внедрения и подержания СМК сводится только к цели пройти аудит? Если так, то да - можно оплатить неэтичный труд "специалиста из ОС". Правда, толку будет немного. Вам же нужно не только оценку получить типа "нет, Ваша система пока к сертификации не готова". Можно "сэкономить" и провести "комиссионый"аудит. Толку не будет вовсе, поскольку комиссия - безупречный способ размыть ответственность и не принять решения. А если хочется, чтобы система заработала - то стоит пригласить нормального консультанта, оговорив с ним конкретные требования к составу и содержанию его услуг, ограничив его на первом этапе рамками:
- анализа приемлемости примененной модели СМК и идентификации необходимых для нее процессов,
- экспертизы документации СМК на адекватность,
- проверки осуществления мониторинга, контроля и анализа процессов СМК,
- необходимости и достаточности ведущихся записей.
По результатам - смотреть, можете ли Вы привести в соответствие систему собственными силами.

Браво! Молодец! Прям как сам бы ответил! Этот пост можно заносить в ЧаВО как ответ на вопрос типа: "Мы что-то строили-строили пройдем ли мы сертификацию?"

Здравствуйте!
Подскажите пожалуйста! Smile

Актуализируем процедуру по анализу видов и последствий потенциальных отказов (FMEA) в соответствии с новым ссылочным руководством.
В этом руководстве ужесточились критерии оценки значимости, возникновнеия,обнаружения. Понятно, что это рекомендации, но на сколько можно от них отклоняться?
Можно ли частично использовать эти критерии в сторону облегчения (например, в критериях обнаружения отказов до 6 ранга идет автоматический контроль, чего, естественно у нас нет; можно ли его из этих критериев вообще убрать), иначе ПЧР у нас всегда больше 100, чего совсем бы не хотелось Smile

?
Спасибо Smile

ZHukov писал(а):

Alex9994 писал(а):

Nasti писал(а):

Добрый день всем всем всем!
Давненько я тут не была, надеюсь ничего самого главного не пропустила?
У меня такая тема для обсуждения: СМК в проектной организации. Организация занимается ТОЛЬКО подготовкой проектов для строительства (например). Я так подумала, и получается, что можно п.7.3. ИСО 9001 из области деятельности исключить!!! (как это не смешно звучало бы)
Дело в том, что как таковым "разработкой проектов" они не занимаются, а берут НД (ГОСТы и все прочее) и пишут каждый раз похожие проекты с одинаковыми требованиями. Различия только в исходных данных, которые зависят от место положения строительства.

Хотелось бы узнать ваши мнения. Если необходимы другие подробности конкретнее - спрашивайте!

Nasti

Относительно исключения п.7.3 см. http://www.iso.org/iso/iso_catalogue/management_standards/iso_9000_iso_14000/iso_9001_2008/guidance_on_iso_9001_2008_sub-clause_1.2_application
Перевод есть в http://www.klubok.net/Downloads-index-r ... d-342.html
Критерии для исключения, что есть продукция организации
Если Проект для строительства – это не конкретно…

Если это относительно Проекта организации строительства (ПОС) и Проекта производства работ (ППР) , то в общем случае это не дизайн, а планирование оснащения места работы, организации и проведения СМР… т.е п.7.1 стандарта.

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

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

2 ZHukov

В моем посту не подвергалось сомнению, что ПОС и ПРР могут быть

и ПОС и ППР -- может быть продукцией проектной организации,
В общем случае (когда проектная организация несет ответственность и за объект строительства) и ПОС и ППР относительно цели своего применения объекта строительства не определяют требований к нему, т.е. не являются его проектированием и разработкой (п.7.3)
Если организация несет ответственность только относительно ПОС и/или ППР то п.7.3 будет разработка ТЗ на их разработку.

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

п.7.3 к нам относится или все таки нет. И как это лучше доказать?

-------------

Почитала я вспомогательные документы по ссылке. Из приложение А примера 4 все таки следует, что мы ответственные за проектирование и разработку (хотя аудитору наверное можно доказать обратное.) Методом выбора все таки думаю, придется включать в область СМК и проектирование...

Кстати! за журнал, спасибо. Не знала о нем. Может, чего напишу на досуге (когда это будет!!!) Только почему-то там все время говорится о ПОСТСОВЕТСКИХ организациях! непонятно! Мне уже кажется, что на постсоветских наоборот нет нормальных менеджеров по качеству. Все убежали. Слоев слишком много древних, не поднять. И действуют там исключительно "как привыкли". И сертифицируются так же! так что считаю, надо изменить слоган, и брать во внимание эффективные рыночные организации, для которых СМК - это действительно часть системы, и которые не будут просто так тратить деньги на внедрение СМК (как чего то ненужного)

Nasti писал(а):

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

п.7.3 к нам относится или все таки нет. И как это лучше доказать?

ИМХО п. 7.3 к вам относится если ваша организация участвует в разработке и утверждении Технического Задания (ТЗ) на вашу ПСД...

Nasti писал(а):

Почитала я вспомогательные документы по ссылке. Из приложение А примера 4 все таки следует, что мы ответственные за проектирование и разработку (хотя аудитору наверное можно доказать обратное.) Методом выбора все таки думаю, придется включать в область СМК и проектирование...

Одно другому не мешает...
очень даже может быть в области СМК и проектирование и исключение п.7.3

А откуда такое ИМХО? Какими то документами руководствуетесь? какими тогда?
ТЗ мы разрабатываем САМИ и даем заказчику на согласование. Значит, п.7.3 БЫТЬ!!! Smile

Только, если есть подтверждение вашего ИМХО, дайте ссылочку, а?

Nasti писал(а):

А откуда такое ИМХО? Какими то документами руководствуетесь? какими тогда?

ссылу повторяю

Alex9994 писал(а):

Относительно исключения п.7.3 см. http://www.iso.org/iso/iso_catalogue/management_standards/iso_9000_iso_14000/iso_9001_2008/guidance_on_iso_9001_2008_sub-clause_1.2_application
Перевод есть в http://www.klubok.net/Downloads-index-r ... d-342.html
Критерии для исключения, что есть продукция организации.

Nasti писал(а):

ТЗ мы разрабатываем САМИ и даем заказчику на согласование. Значит, п.7.3 БЫТЬ!!! Smile

Только, если есть подтверждение вашего ИМХО, дайте ссылочку, а?

ИМХО в проектном институте:
если продуция - проектно-сметная документация
если разработка проектно-сметной документации -- design -- по п.7.5 стандарта...,
то разработка технического задания на эту проектно-сметную документацию -- design specification -- по п.7.3.
Подтвержение ИМХО.
IAF-PL-01-012 -- APPLICATION GUIDANCE 3 ITEMS.pdf
в
http://isotc.iso.org/livelink/livelink/ ... id=3556397
источник
http://isotc.iso.org/livelink/livelink/ ... ;sort=name
перевод

IAF-PL-01-012 писал(а):

необходимо обратить внимание на определение понятия «Проектирование и разработка», приведенное в пункте 3.4.4. ISO 9000:2000, в его части, относящейся к продукции:
«Набор процессов, которые трансформируют требования в определенные характеристики или в спецификацию продукции….»
ISO 9000:2000 также определяет «Требования» как «потребности или ожидаемые результаты, которые устанавливаются, подразумеваются в общем или обязательны» .
Если организации не предоставлены характеристики продукции, которые необходимы для планирования процессов создании данной продукции, и ей приходится определять эти характеристики на основании требований потребителя и/или регулирующей организации, то это, согласно определению, и является «проектированием и разработкой продукции».

спецификация продукции в случае с ПСД -- design specification (техническое задание на ПСД)...

Т.е. если я правильно поняла, надо еще и отделить ТЗ (как Проектирование) от самого продукта (ПСД).

Если пользоваться определением из ИСО 9000 :
3.4.4 проектирование и разработка (en design and development; fr conception et développement): Совокупность процессов (3.4.1), переводящих требования (3.1.2) в установленные характеристики (3.5.1) или нормативную и техническую документацию (3.7.3) на продукцию (3.4.2), процесс (3.4.1) или систему (3.2.1).

нормативная и техническая документация (en specification; fr spécification): Документы (3.7.2), устанавливающие требования (3.1.2).
Примечания
1 Нормативные документы могут относиться к деятельности (например документированная процедура, технологическая документация на процесс или методику испытаний) или продукции (3.4.2) (например технические условия на продукцию, эксплуатационная документация и чертежи).
2 Термин дан в редакции, отличной от приведенной в ИСО 9000, в соответствии с терминологией, принятой в Российской Федерации.

Тогда как отделить по-правильному ТЗ. Ведь и ТЗ и ПСД представляет интерес для заказчика.

Nasti писал(а):

Т.е. если я правильно поняла, надо еще и отделить ТЗ (как Проектирование) от самого продукта (ПСД).

Зачем еще отделять?
ТЗ и разработанная по нему ПСД…

Вам надо не отделять, а соотнести пункты стандарта к деятельности организации

Nasti писал(а):

Тогда как отделить по-правильному ТЗ. Ведь и ТЗ и ПСД представляет интерес для заказчика.

ТЗ и ПСД представляет интерес не только зля заказчика но и для других заинтересованных лиц…
ТЗ идет в составе ПСД

Nasti писал(а):

получается, ТЗ (п.7.3), а ПСД (п. 7.5)

уточнение
разработка ТЗ (п.7.3), а разработка ПСД (п. 7.5)

Да-да, согласна.
(Блин, сейчас набирала, набирала и все слетело!)

В общем, я сделала модель процессов в своем РК так же как в ИСО (написала только вместо реализации продукта - выполнение проектных работ, вместо продукта - ПСД) . В РК взяла сквозную нумерацию. но разбила по темам цикла ПДСА.
ПЛАНИРУЕМ (из содержания скопировала):
4 Требования к документации (ИСО 9001, п. 4.2) 8
4.1 Политика и цели ООО «Нептунпроект» 8
4.2 Документация интегрированной системы менеджмента ООО «Нептунпроект» 9
4.3 Управление документацией (ИСО 9001, п. 4.2.3) 10
4.4 Управление записями 11
5 Ответственность руководства (ИСО 9001, п. 5) 11
5.1 Обязательства высшего руководства 11
5.2 Представитель руководства 12
5.3 Планирование 13
Экологические аспекты 13
Определение опасностей, оценка рисков и определение мер управления 13
Законодательные и другие требования 13
Цели, задачи и программа 14
6 Создание продукта / процессы жизненного цикла (ИСО 9001, п.7) 14
6.1 Планирование создания продукта ) 14
6.2 Законодательные и обязательные требования (требования к безопасности) 15
6.3 Связь с потребителем 15
6.4 Проектирование 15

И так далее по циклу.
Вот как из практики более удобно нумеровать процессы. По модели или по РК? и тогда с чего начать, чтобы ПРОЦЕДУРЫ (стандарты организации СТО) были достаточно локально обозначены, и можно было добавлять новые СТО, но в это же время было понятно, как они друг от друга отделены.
Как на практике лучше лучше работать?

Nasti писал(а):

Вот как из практики более удобно нумеровать процессы. По модели или по РК? и тогда с чего начать, чтобы ПРОЦЕДУРЫ (стандарты организации СТО) были достаточно локально обозначены, и можно было добавлять новые СТО, но в это же время былор понятно, как они друг от друга отделены.
Как на практике лучше лучше работать?

ИМХО если нет особых требований (типа СТО Газпром)
1) ИСО 9001 требует только описание взаимодействия процессов, возможно нумерация процессов не потребуется...
2) процессы лучще нумеровать по модели
модель процессов лучше строить без привязки к пунктам ИСО 9001
хотя и модель, приведнную в ИСО 9001, можно использовать...
3) процедуры (СТО) сами по себе, процессы -- сами; ИСО 9001 не требует документирования требований (процедур) по процессам (регламентов процессов)
4) СТО лучше нумеровать по порядку идентификации объекта стандартизации, если есть детализация объекта, то можно их группировать. Например СТО 01, СТО 01.1

Добрый день!
Наше предприятие является поставщиком автокомпонентов. На сегодняшний день требования автозаводов к предприятиям поставщикам автокомпонентов, это сертификация по ИСО/ТУ 16949.
Посоветуйте какие-нибудь рекомендации о подготовке к данной сертификации

Nasti писал(а):

Да-да, согласна.

И так далее по циклу.
Вот как из практики более удобно нумеровать процессы. По модели или по РК? и тогда с чего начать, чтобы ПРОЦЕДУРЫ (стандарты организации СТО) были достаточно локально обозначены, и можно было добавлять новые СТО, но в это же время былор понятно, как они друг от друга отделены.
Как на практике лучше лучше работать?

Существует классификация этапов по петле качества

Перечень этапов производства код
Общесистемные вопросы 01
Маркетинг 02
Конструкторская подготовка 03
Материально-техническое снабжение 04
Технологическая подготовка 05
Производство 06
Контроль и испытания 07
Упаковка и хранение 08
Реализация 09
Эксплуатация 10
Техническая помощь в эксплуатации 11
Утилизация 12

Пример обозначения СТП «Система менеджмента качества. Порядок разработки, согласования, утверждения и внедрения СТП и внесения в них изменений»:
СТП 01.05-2009, здесь 01 - общесистемные вопросы, 0 - номер группы стандартов по ведению документации, 5 - порядковый номер стандарта в группе, 2009 - год издания.

MalyshevSV писал(а):

Существует классификация этапов по петле качества....

Пример обозначения СТП...

кажется это еще от КС УКП
ИМХО можно и так
только СТП как документ стандартизации перестанет быть легитимным с 01.07.2010 по 184-ФЗ....

ZHukov писал(а):

Alex9994 писал(а):

Nasti писал(а):

получается, ТЗ (п.7.3), а ПСД (п. 7.5)

уточнение
разработка ТЗ (п.7.3), а разработка ПСД (п. 7.5)

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

2 ZHukov

ИМНО Не перебор. Аргументация приведена. Причем ссылки на документы ISO и IAF...
По сути применения ИСО 9001 проектное производство (разработка ПСД) ни чем не отличает производства любой другой продукции...

Краткое резюме
В строительстве проектно-изыскательская организация может нести ответственность за разные этапы жизненного цикла объекта (не путать ЖЦП по ГОСТ Р ИСО 9001) от замысла о его создании до его утилизации.
И отсчет применения п.7.3 и 7.5 идет от того, как организация идентифицирует свою продукцию, в т.ч. и относительно этапов жизненного цикла объекта проектирования:

как пример такого расклада:
- ПСД -- разработка ТЗ (п.7.3), а разработка ПСД (п. 7.5)
- услуга по разработки ПСД -- разработка технологии проектирования (п.7.3), а разработка ПСД (п. 7.5)
- ПСД в составе законченного строительством объекта -- разработка, ПСД, авторский надзор, госприемка законченного строительством объекта (п. 7.3), а сопровождение объекта (п. 7.5)

ИМХО у проектных организаций всегда выбор из двух альтернатив: либо расклад п.7.3 и п.7.5 от продукции или идентификация продукции от желаемого расклада п.7.3 и 7.5.

Nasti писал(а):

Да, про этапы/коды - это из старой-старой версии стандарта. Наверняка, многие из которых не работают.

по версии ИСО 1994г.
п.4.4 управление проектированием
п.4.9 управление процессами
А этапы совсем из другого... из нормативных документов по строительству

Nasti писал(а):

Только вот про процессы и процедуры. Я в общем, согласна. Но в своем частном случае, как раз хочу обозначить процессы: 1-2-3-4 1) ответственность руководства, 2)управление ресурсами, 3) Созданные/выполнение ПСД, 4) Измерение, анализ..
И под все эти процессы разработать внутри процедуры. СТО 1-1-2010 (допустим) и т.д. Только я не знаю насколько это будет жизненно. ?

ИХНО совершенно не жизненно...
1) в общем виде ответственность -- не процесс...
2) привязка процессов к разделам стандарта в общем случае не жизнеспособна, жизненной ее делает профессионал в менеджменте и ИСО 9001, а без такого профессионала такие процессы не продемонстрировать...
3) аналогично и с процессом измерение, анализ...
4) Процессы не требуют стандартизации...
5) что будете делать, когда придется переопределить границы процессов и когда процедура будет касаться нескольких процессов... например документооборот

Nasti писал(а):

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

Кроме вас ни кто не решит как надо....

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

в результате получилось примерно

Цитата:

01.1- Словарь основных терминов
01.2 - Общие положения
02 - Стандарт организации, порядок разработки, утверждения, регистрации, оформления, изменения и внедрения
03 - Договор, порядок заключения, ведения и учета (в итоге поглотил и 04 -Субподряд)
06 - Проектирование. Управление (поглотил 05 - внутренний субподряд)
07 - Замечания к проектно-сметной документации.
08 - Делопроизводство
09 - Авторский надзор
10 - Изыскательские материалы. Порядок подготовки
12 - Проектно-сметная документация. Идентификация
13 - Обучение персонала
14 - Проверки качества внутренние. Порядок планирования и проведения
15 - Проектно-сметная документация. Оформление и выпуск
16 - Расчеты. Правила Оформления
17 - Чертежи. Правила оформления

Корректирующие и предупреждающие действия приведены в РК
11 - Документацией системы менеджмента качества. Управление -- тоже перекочевал в РК...

А насколько жизненным оказался словарь? Это словарь терминов СМК или вообще по предприятию? Интересно.

Вы эти разделы указали в РК, или это были разделы РК?

и почему именно в такой последовательности?

Я тут в соответствии с прогр. 1С пронумеровала отделы.
1 административно-управленческий персонал
...
3 технологический отдел
4 отдел изысканий
5 ..
6 отдел разработки

и так далее

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

Nasti писал(а):

А насколько жизненным оказался словарь? Это словарь терминов СМК или вообще по предприятию? Интересно.

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

Nasti писал(а):

Вы эти разделы указали в РК, или это были разделы РК?

С РК это ни как не связано

Nasti писал(а):

и почему именно в такой последовательности

Когда рождалась последовательность 08 уже действовал...
Остальное случайным образом... записали объекты стандартизации, чтобы увидеть систему и пронумеровали в том же порядке как записали...
С учетом что 08 уже есть... остальные остатки КС УКП (34 стандарта) даже не трогали, преемственность сохранилась только по делопроизводству...
Сертификация проходила при численности около 400, через 4 года численность практически удвоилась.... ну и объекты стандартизации появились сверх предварительного списка.

Весь набор ДП очень случаен, он очень зависит от специфики проектного института
Как пример, другой институт численностью около 50 чел обошелся одним РК, в котором изложил 6 ДП, требуемых стандартом….

Nasti писал(а):

Так вот, может быть использовать эти направления? Хотя будет не совсем корректно, и ведь отделы - это часть процессов.

Можно, но в другом, в номенклатуре дел например.

SergeevLV писал(а):

Наше предприятие готовится к сертификации по ISO 9001:2008.
На предприятии работает 8 человек.

А руководителей из них сколько?

SergeevLV писал(а):

При построении СМК создано 25 документированных процедур

На 8 -- явный перебор. ИМХО можно обойтись 1-2 документа уровня Руководство по качеству и документированные процедуры

SergeevLV писал(а):

около 100!!!! документов о качестве, 41 протокол качества.

может быть гораздо больше... все зависит от специфики вас и вашего бизнеса и его объемов...

SergeevLV писал(а):

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

не без этого

SergeevLV писал(а):

Посоветуйте, как упростить систему, или если можно, стратифицироваться по другому стандарту,

По другому стандарту -- отраслевой специфике ИСО 9001?

SergeevLV писал(а):

хоть для малого бизнеса. Заранее спасибо.

есть руководство по применения ИСО 9001 для малого бизнеса
ISO 9001 for Small Businesses

Внедрение | Разработка СМК | Подготовка к сертификации