Tishanskiysdk.ru

Про кризис и деньги
130 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

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

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

7.3.1 Общие рекомендации

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

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

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

Примеры средств оценивания рисков проектирования и разработки:

— анализ причин и последствий отказов проекта;

— анализ дерева отказов;

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

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

а) внешние входные данные:

— потребности и ожидания потребителей или рынка;

— потребности и ожидания других заинтересованных сторон;

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

— изменения в соответствующих законодательных и других обязательных требованиях;

— международные или национальные стандарты;

— промышленные кодексы установившейся практики.

б) внутренние входные данные:

— политика и цели;

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

— требования к компетентности проектировщиков и разработчиков;

— обратная информация о прошлом опыте;

— записи и данные о существующих процессах и продукции;

— выходы других процессов.

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

— работе, монтаже и применении;

— хранении, погрузочно-разгрузочных работах и поставке;

— физических параметрах и окружающей среде;

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

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

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

Примеры выхода проектирования и разработки:

— данные, подтверждающие сравнение входов для процесса с выходами процесса;

— спецификации на продукцию, в том числе критерии приемки;

— спецификации на процесс;

— спецификации на материалы;

— спецификации на испытания;

— требования к подготовке кадров;

— информация о пользователе и потребителе;

— требования к закупкам;

— протоколы проверки соответствия техническим условиям.

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

7.3.3 Анализ проекта и разработки

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

Объектами таких анализов являются:

— адекватность входов для выполнения заданий по проектированию и разработке;

— ход запланированного процесса проектирования и разработки;

— соответствие целям верификации и валидации;

— оценка потенциальных рисков или причин отказов при использовании продукции;

— данные жизненного цикла, касающиеся характеристик продукции;

— управление изменениями и их последствия в ходе проектирования и разработки;

— определение и устранение проблем;

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

— потенциальное воздействие продукции на окружающую среду.

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

Примеры деятельности по верификации выходов процесса проектирования и разработки:

— сравнения требований к входу по отношению к выходу процесса;

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

— оценка по отношению к аналогам;

— проверка, моделирование и испытания с целью контроля соответствия конкретным требованиям к входным данным;

— оценка уроков, извлеченных из прошлого опыта, таких как несоответствия и недостатки процесса.

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

Участие сторон позволяет фактическим пользователям оценивать выходы с помощью валидации:

— инженерного дизайна до конструирования, монтажа или применения;

— выходов программного средства до монтажа или использования;

— услуг до широкого их введения.

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

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

Анализ методов включает:

— улучшение процессов и продукции;

— применимость выходных данных;

— адекватность записей процесса и анализа;

— деятельность по исследованию отказов;

— будущие потребности процесса проектирования и разработки.

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

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

· превышение сметной стоимости проекта;

· несвоевременного завершения строительства и задержки завершения работ;

· низкого качества работ и объекта;

· конструкционный и технологический;

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

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

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

· обусловить право оперативной замены участника проекта в случае важного нарушения ним обязательств относительно проекта или выявления признаков возможности такого нарушения;

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

· предупредить участников проекта про обязательное их страхование от значащих для проекта рисков;

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

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

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

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

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

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

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

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

Читать еще:  Социальные риски схема

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

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

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

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

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

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

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

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

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

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

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

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

ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОДУКЦИИ

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

7.3.1 Общие методические указания

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

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

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

— анализ причин и последствий отказов проекта;
— анализ дерева отказов;
— прогноз безотказности;
— диаграммы зависимости;
— методы классификации;
— методы моделирования.

ИСО 9001:2000. Системы менеджмента качества. Требования

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

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

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

В ходе планирования проектирования и разработки организация должна устанавливать:

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

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

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

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

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

а) внешние входные данные, такие, как:

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

b) внутренние входные данные, такие, как:

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

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

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

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

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

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

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

ИСО 9001:2000. Системы менеджмента качества. Требования

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

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

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

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

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

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

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

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

7.3.3 Анализ проекта и разработки

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

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

Объектами таких анализов являются:

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

Читать еще:  Риск портфеля формула

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

Примерами деятельности по верификации выходов процесса проектирования и разработки являются:

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

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

Участие сторон позволяет фактическим пользователям оценивать выходы с помощью таких средств, как:

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

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

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

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

ИСО 9001:2000. Системы менеджмента качества. Требования

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

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

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

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

7.3.5 Верификация проекта и разработки

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

7.3.6 Валидация проекта и разработки

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

7.3.7 Управление изменениями проекта и разработки

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

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

Процесс проектирования и разработки

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

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

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

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

К основным процессам следует отнести процессы жизненного цикла продукции (раздел 7 ГОСТ Р ИСО 9001-2008) от ее разработки, постановки на производство, собственно производства до поставки, т.е. процессы, непосредственно создающие ценность для потребителей.

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

Говоря о процессах управления организацией, следует отметить, что в каждой организации в соответствии с МС ИСО 9000:2000 могут быть выделены процессы управления различными видами деятельности (исследование и разработка, закупки, производство и т.д.) и процессы планирования, организации, руководства, контроля, регулирования и т. д.

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

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

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

Проектирование продукции — это процесс, не прекращающийся до начала успешных продаж продукта.

Согласно ИСО МЭК ТО 15504 бизнес-процесс «Разработка продуктов и услуг» описывается следующим образом:

— разработка концепции новых продуктов/услуг и планов;

— проектирование, создание и тестирование прототипов продуктов/услуг;

-внесение улучшений в существующие продукты/услуги;

— тестирование эффективности новых или усовершенствованных продуктов/услуг;

— подготовка к производству;

— управление процессом разработки продуктов/услуг.

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

В ходе планирования проектирования и разработки организация должна устанавливать:

1. стадии проектирования и разработки;

2. проведение анализа, верификацию и валидацию, соответствующие каждой стадии проектирования и разработки;

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

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

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

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

Входные данные должны включать:

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

2. соответствующие законодательные и другие обязательные требования;

3. там, где это возможно, информацию, взятую из предыдущих аналогичных проектов;

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

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

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

1. соответствовать входным требованиям к проектированию и разработке;

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

3. содержать критерии приемки продукции или ссылки на них;

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

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

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

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

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

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

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

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

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

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

2. актуализация планов по ходу выполнения проектных работ

3. обеспечение процесса проектирования всеми необходимыми средствами

4. выполнение процесса проектирования квалификационным персоналом

5. обеспечение организационного, технического и информационного взаимодействий

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

7. обеспечение соответствия выходных данных проекта входным

8. проведение анализа, верификации и валидации проекта и разработки

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

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

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

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

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

Процесс закупок

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

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

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

1. требования к официальному одобрению продукции, процедур, процессов и оборудования;

2. требования к квалификации персонала;

3. требования к системе менеджмента качества.

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

Читать еще:  Риск премия по акциям

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

Если организация или ее потребитель предполагают осуществить верификацию у поставщика, то организация должна установить предполагаемые меры по верификации и порядок выпуска продукции в информации по закупкам [1, с.8].

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

1. процессом закупок необходимо управлять

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

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

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

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

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

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

7.3.1 Общие рекомендации

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

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

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

Примеры средств оценивания рисков проектирования и разработки:

— анализ причин и последствий отказов проекта;

— анализ дерева отказов;

│ ГОСТ Р ИСО 9001-2001 Системы менеджмента качества. Требования │

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

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

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

│ В ходе планирования проектирования и разработки организация должна устанавливать: │

│ а) стадии проектирования и разработки; │

│ б) проведение анализа, верификацию и валидацию, соответствующих каждой стадии проектирования и│

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

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

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

│ Результаты планирования должны актуализироваться, если это необходимо, по ходу проектирования│

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

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

а) внешние входные данные:

— потребности и ожидания потребителей или рынка;

— потребности и ожидания других заинтересованных сторон;

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

— изменения в соответствующих законодательных и других обязательных требованиях;

— международные или национальные стандарты;

— промышленные кодексы установившейся практики;

б) внутренние входные данные:

— политика и цели;

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

— требования к компетентности проектировщиков и разработчиков;

— обратная информация о прошлом опыте;

— записи и данные о существующих процессах и продукции;

— выходы других процессов;

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

— работе, монтаже и применении;

— хранении, погрузочно-разгрузочных работах и поставке;

— физических параметрах и окружающей среде;

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

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

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

Примеры выхода проектирования и разработки:

— данные, подтверждающие сравнение входов для процесса с выходами процесса;

— спецификации на продукцию, в том числе критерии приемки;

— спецификации на процесс;

— спецификации на материалы;

— спецификации на испытания;

— требования к подготовке кадров;

— информация о пользователе и потребителе;

— требования к закупкам;

— протоколы проверки соответствия техническим условиям.

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

│ ГОСТ Р ИСО 9001-2001 Системы менеджмента качества. Требования │

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

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

│поддерживаться в рабочем состоянии. │

│ Входные данные должны включать: │

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

│ б) соответствующие законодательные и другие обязательные требования; │

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

│ г) другие требования, важные для проектирования и разработки. │

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

│недвусмысленными и непротиворечивыми. │

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

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

│провести верификацию относительно входных требований к проектированию и разработке, а также должны│

│быть официально одобрены до их последующего использования. │

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

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

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

│ в) содержать критерии приемки продукции или ссылки на них; │

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

7.3.3 Анализ проекта и разработки

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

Объектами таких анализов являются:

— адекватность входов для выполнения заданий по проектированию и разработке;

— ход запланированного процесса проектирования и разработки;

— соответствие целям верификации и валидации;

— оценка потенциальных рисков или причин отказов при использовании продукции;

— данные жизненного цикла, касающиеся характеристик продукции;

— управление изменениями и их последствия в ходе проектирования и разработки;

— определение и устранение проблем;

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

— потенциальное воздействие продукции на окружающую среду.

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

Примеры деятельности по верификации выходов процесса проектирования и разработки:

— сравнения требований к входу по отношению к выходу процесса;

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

— оценка по отношению к аналогам;

— проверка, моделирование и испытания с целью контроля соответствия конкретным требованиям к входным данным;

— оценка уроков, извлеченных из прошлого опыта, таких как несоответствия и недостатки процесса.

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

Участие сторон позволяет фактическим пользователям оценивать выходы с помощью валидации:

— инженерного дизайна до конструирования, монтажа или применения;

— выходов программного средства до монтажа или использования;

— услуг до широкого их введения.

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

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

Анализ методов включает:

— улучшение процессов и продукции;

— применимость выходных данных;

— адекватность записей процесса и анализа;

— деятельность по исследованию отказов;

— будущие потребности процесса проектирования и разработки.

│ ГОСТ Р ИСО 9001-2001 Системы менеджмента качества. Требования │

│ 7.3.4 Анализ проекта и разработки │

│ На соответствующих стадиях должен поводиться# систематический анализ проекта и разработки в│

│соответствии с запланированными мероприятиями (7.3.1) с целью: │

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

│ б) выявления любых проблем и внесения предложений по необходимым действиям. │

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

│отношение к анализируемой(ым) стадии(ям) проектирования и разработки. Записи результатов анализа и│

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

│ 7.3.5 Верификация проекта и разработки │

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

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

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

│поддерживаться в рабочем состоянии. │

│ 7.3.6 Валидация проекта и разработки │

│ Валидация проекта и разработки должна осуществляться в соответствии с запланированными│

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

│требованиям к установленному или предполагаемому использованию, если оно известно. Где это│

│практически возможно и целесообразно, валидация должна быть завершена до поставки или применения│

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

│ 7.3.7 Управление изменениями проекта и разработки │

│ Изменения проекта и разработки должны быть идентифицированы, а записи должны поддерживаться в│

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

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

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

│ Записи результатов анализа изменений и любых необходимых действий должны поддерживаться в│

Ссылка на основную публикацию
Adblock
detector