Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
вот это находка.pdf
Скачиваний:
148
Добавлен:
01.06.2015
Размер:
2.36 Mб
Скачать

11.ВЫПУСК ПРОДУКЦИИ

11.1.Планированиевыпускапродукции

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

7.1. Планирование выпуска продукции

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

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

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

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

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

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

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

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

11.2. Процессы, связанныеспотребителем

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

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

Управление качеством. Электрон. учеб. пособие

-163-

11.ВЫПУСК ПРОДУКЦИИ

11.2.Процессы, связанные с потребителем

7.2. Процессы, связанные с потребителем

7.2.1. Определение требований, относящихся к продукции

Организация должна определить:

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

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

в) законодательные и нормативные требования, имеющие отношение к продук-

ции;

г) любые дополнительные требования, определенные организацией.

7.2.2. Анализ требований, относящихся к продукции

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

a) требования к продукции выявлены;

б) требования контракта или заказа, отличающиеся от тех, которые были высказаны ранее, рассмотрены;

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

7.2.3. Взаимосвязь с потребителем

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

a) информации о продукции;

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

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

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

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

Можно вводить детали заказа непосредственно в компьютер также с последующим запросом о подтверждении, которое может быть передано

Управление качеством. Электрон. учеб. пособие

-164-

11.ВЫПУСК ПРОДУКЦИИ

11.2.Процессы, связанные с потребителем

устно, по факсу или Е-mail. При этом информацию сохраняют непосредственно на диске компьютера или распечатывают во всех подробностях.

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

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

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

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

Любые тендеры и заказы потребителей и любые изменения в них должны обрабатываться в соответствии с требованиями п. 4.2.4 стандарта.

11.3.Проектированиеиразработка

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

7.3. Проектирование и разработка

7.3.1. Планирование проектирования и разработки

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

При планировании проектирования и разработки организация должна определять: a) этапы проектирования и разработки;

б) соответствующую деятельность по анализу, проверке (верификации) и утверждению на каждом этапе проектирования и разработки;

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

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

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

К этапам проектирования и разработки можно отнести: маркетинг; анализ контракта;

разработку проекта производства проектной продукции; закупки, связанные с производством проектной продукции;

Управление качеством. Электрон. учеб. пособие

-165-

11.ВЫПУСК ПРОДУКЦИИ

11.3.Проектирование и разработка

производство проектной продукции; реализацию продукции.

Планирование процессов осуществляется с учетом: требований заказчика; политики в области качества; программ качества;

требований нормативно-технической документации.

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

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

Контроль разработки (рис. 11.1) обычно охватывает:

установление целей разработки, планирование хода ее выполнения и ответственных за разработку (п. 7.3.1);

определение необходимых исходных данных для разработки (п. 7.3.2); установление формы выходных материалов в результате разработки

(п. 7.3.3);

анализ по завершению каждой стадии разработки с ответом на вопрос, достигнуты ли желаемые результаты (пп. 7.3.4, 7.3.5 и 7.3.6);

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

(п. 7.3.7).

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

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

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

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

Управление качеством. Электрон. учеб. пособие

-166-

11.ВЫПУСК ПРОДУКЦИИ

11.3.Проектирование и разработка

Рис. 11.1. Контроль разработки

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

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

7.3.2. Входные данные для проектирования и разработки

Входные данные, относящиеся к требованиям к продукции, должны быть установлены, а также должны вестись и сохраняться записи об этом (см. 0Hп. 4.2.4). Эти входные данные должны включать:

a) функциональные и эксплуатационные требования;

б) применяемые законодательные и нормативные требования; в) информацию, полученную из предыдущих аналогичных проектов, где это при-

менимо; г) другие требования, существенные для проектирования и разработки.

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

Главное – потребности ваших потребителей, которые могут быть не всегда ясно выражены. Часто бывает не менее важным знать невысказанные ожидания, которые могут оказаться важными для разработки. Анализ этих

Управление качеством. Электрон. учеб. пособие

-167-

11.ВЫПУСК ПРОДУКЦИИ

11.3.Проектирование и разработка

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

требования законов и регулирующих органов в части охраны здоровья, безопасности, экологии;

другие требования законодательства; результаты исследования рынка; стандарты и отраслевая практика; прошлый опыт.

Входными данными проекта производства проектной продукции являются документы:

контракт (дополнения к контракту); задание на проектирование; протокол анализа договора;

нормативно-техническая документация; данные предыдущих аналогичных проектов.

7.3.3. Выходные данные проектирования и разработки

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

Выходные данные проектирования и разработки должны:

a) удовлетворять входным требованиям к проектированию и разработке;

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

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

и правильного использования.

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

Выходные материалы в результате разработки могут иметь разный вид, например:

инженерный проект в виде чертежей и расчетов; проект одежды в виде эскизов и спецификаций используемых мате-

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

ликации; разработка продукта питания в виде рецепта;

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

использовать.

Управление качеством. Электрон. учеб. пособие

-168-

11.ВЫПУСК ПРОДУКЦИИ

11.3.Проектирование и разработка

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

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

7.3.4. Анализ проектирования и разработки

На выбранных этапах в соответствии с планом (см. 1Hп. 7.3.1) должен проводиться систематический анализ проектирования и разработки для того, чтобы:

a) оценить способность результатов проектирования и разработки соответствовать требованиям;

б) идентифицировать все проблемы и предложить необходимые действия.

В состав участников таких анализов должны включаться представители служб, связанных с анализируемым(и) этапом(и) проектирования и разработки. Должны вестись и сохраняться записи о результатах анализа и всех необходимых действиях (см. 2Hп. 4.2.4).

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

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

Решая, сколько раз следует проводить анализ, необходимо учитывать: имеются ли естественные фазы или стадии разработки; если какой-либо недостаток не выявлен до поздних стадий разработки,

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

временной график разработки.

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

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

Управление качеством. Электрон. учеб. пособие

-169-

11.ВЫПУСК ПРОДУКЦИИ

11.3.Проектирование и разработка

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

Хотя цели таких действий, как анализ разработки и проектирования (п. 7.3.4), проверка разработки и проектирования (п. 7.3.5), оценка разработки и проектирования (п. 7.3.6) отличаются друг от друга, между ними возможны значительные пересечения и взаимосвязи. Во многих случаях то или иное действие может производиться при выполнении всех трех требований стандарта, например испытания прототипов и оценка результатов этих испытаний – важная составная часть всех трех действий.

7.3.5. Проверка (верификация) проекта и разработки

В соответствии с планом (см. 3Hп. 7.3.1) должна быть выполнена проверка для обеспечения уверенности в том, что выходные данные отвечают входным требованиям для проектирования и разработки. Должны вестись и сохраняться записи о результатах проверки и всех необходимых действиях (см. 4Hп. 4.2.4).

Верификация – подтверждение на основе представления объективных свидетельств того, что установленные требования были выполнены. Если образно, то верификация – это процедура сопоставления того, что сделано (или еще пока делается), с тем, что было задумано (предписано) сделать, т. е. сопоставление законченного или промежуточного результата с входными требованиями – «взгляд назад».

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

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

выполнение альтернативных расчетов; сравнение новой разработки с аналогичными (выполненными ранее),

если таковые имеются; проведение испытаний и демонстраций;

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

но в заказе.

Управление качеством. Электрон. учеб. пособие

-170-

11.ВЫПУСК ПРОДУКЦИИ

11.3.Проектирование и разработка

7.3.6.Утверждение проекта и разработки

В соответствии с планом (см. 5Hп. 7.3.1) должно проводиться утверждение проекта и разработки для обеспечения уверенности в том, что получаемая продукция способна отвечать требованиям для ее установленного или предполагаемого использования, если последнее известно. Когда это практически возможно, утверждение должно быть завершено до начала поставки или применения продукции. Должны вестись и сохраняться результаты утверждения и всех необходимых действий (см. 6Hп. 4.2.4).

Валидация – подтверждение на основе представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, выполнены. Образно говоря, валидация – это процедура сопоставления того, что задумано сделать (или еще пока делается), с тем, что необходимо потребителю для конкретного применения, т. е. сопоставление планируемого или промежуточного результата деятельности с текущими выходными требованиями – «взгляд вперед».

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

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

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

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

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

Управление качеством. Электрон. учеб. пособие

-171-