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

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

Рисунок 14 - Схема процесса проектирования

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

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

Итак, обращаясь к приведённому выше тексту стандарта и отталкиваясь от схемы рис. 14, перечислим основные работы, связанные с обеспечением качества на стадии проектирования:

·         анализ требования контракта;

·         контроль за подготовкой, распространением, хранением и изъятием документации;

·         обеспечение взаимодействия участников процесса проектирования и совместимости составных частей проекта (см. стандарт ИСО9001);

·         проверка и подтверждение проекта;

·         рассмотрение готового проекта;

·         контроль за изменениями проекта.

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

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

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

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

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

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

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

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

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

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

Когда говорят о прослеживаемости, имеют в виду:

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

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

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

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

 17 Требования ИСО 9001:2000 к процессам проектирования и разработки

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

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

Примеры:

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

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

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

- вклад поставщиков;

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

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

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

- стандарты отраслей; технологические регламенты;

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

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

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

- технологические разработки;

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

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

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

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

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

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

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

- физических параметрах и внешней среде;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Объекты таких анализов:

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

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

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

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

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

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

- определение и корректировка проблем;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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