Ошибки
1. Нанял и забыл
Стандарты безопасности вводят роль «менеджера безопасности» (в ИСО 26262 это «менеджер ФБ», в МЭК 61508 – «инженер ФБ», и т.п.) Часто у руководителей на этом мысль останавливается. У Станилава Лема был рассказ, где всемогущая машина первым делом создала другую всемогущую машину, чтобы делегировать задачи (а та создала третью, и так далее). Следуя тому же ходу мысли, «большой» менеджер (главный инженер, СТО, директор по развитию, иногда даже генеральный директор) создает (нанимает) «маленького» менеджера по безопасности, препоручает ему фронт работ и исчезает.
Внедрение процессов безопасности требует перестройки компании. «Маленький» менеджер не справится без поддержки «большого» менеджмента, коллег и подчиненных. Поддержка коллег и подчиненных из ниоткуда тоже не появится, а если появится – то без организации будет бесполезна.
1. Нанял и забыл
Стандарты безопасности вводят роль «менеджера безопасности» (в ИСО 26262 это «менеджер ФБ», в МЭК 61508 – «инженер ФБ», и т.п.) Часто у руководителей на этом мысль останавливается. У Станилава Лема был рассказ, где всемогущая машина первым делом создала другую всемогущую машину, чтобы делегировать задачи (а та создала третью, и так далее). Следуя тому же ходу мысли, «большой» менеджер (главный инженер, СТО, директор по развитию, иногда даже генеральный директор) создает (нанимает) «маленького» менеджера по безопасности, препоручает ему фронт работ и исчезает.
Внедрение процессов безопасности требует перестройки компании. «Маленький» менеджер не справится без поддержки «большого» менеджмента, коллег и подчиненных. Поддержка коллег и подчиненных из ниоткуда тоже не появится, а если появится – то без организации будет бесполезна.
2. Инструмент впереди паровоза
Эта ошибка похожа на предыдущую, но делегируют не человеку, а программному инструменту. Здесь будет уместно вспомнить другую американскую поговорку – a fool with a tool is still a fool. Не будем обсуждать полезность инструментов жизненного цикла безопасности – об этом в другой записи. Инструменты (в том числе и программные) применяют для использования в процессе. Но если процесса нет – то нечего и автоматизировать, инструменты негде применять. Прежде чем приобретать инструменты, убедитесь, что они вам зачем-то нужны.
Эта ошибка похожа на предыдущую, но делегируют не человеку, а программному инструменту. Здесь будет уместно вспомнить другую американскую поговорку – a fool with a tool is still a fool. Не будем обсуждать полезность инструментов жизненного цикла безопасности – об этом в другой записи. Инструменты (в том числе и программные) применяют для использования в процессе. Но если процесса нет – то нечего и автоматизировать, инструменты негде применять. Прежде чем приобретать инструменты, убедитесь, что они вам зачем-то нужны.
3. Процесс впереди паровоза
Часто во время тренингов до слушателей трудно донести, что для достижения целей безопасности необходимы не только технические решения, но и процессы. Решения, полученные вне процессов, не безопасны в строгом понимании. Здесь речь идет об обратных случаях – когда роль процесса переоценивают. Странно, но некоторые руководители думают, что главное – оформить процессную документацию, а после – «нажимать» на людей, чтобы предприятие «жило» по процессу. Эта ошибка опаснее предыдущих, потому что ведет к недооценке проблемы: возникнет ситуация, когда инженеры формально используют процесс, а на практике документация оторвалась от реального положения дел и безопасность не обеспечена. В лучшем случае руководство узнает об этом от внешнего аудитора (например, проходя аудит как поставщик), в худшем – от судебного эксперта, назначенного при рассмотрении иска от заказчика.
Часто во время тренингов до слушателей трудно донести, что для достижения целей безопасности необходимы не только технические решения, но и процессы. Решения, полученные вне процессов, не безопасны в строгом понимании. Здесь речь идет об обратных случаях – когда роль процесса переоценивают. Странно, но некоторые руководители думают, что главное – оформить процессную документацию, а после – «нажимать» на людей, чтобы предприятие «жило» по процессу. Эта ошибка опаснее предыдущих, потому что ведет к недооценке проблемы: возникнет ситуация, когда инженеры формально используют процесс, а на практике документация оторвалась от реального положения дел и безопасность не обеспечена. В лучшем случае руководство узнает об этом от внешнего аудитора (например, проходя аудит как поставщик), в худшем – от судебного эксперта, назначенного при рассмотрении иска от заказчика.
Если процессы нелогичные, слишком трудоемкие, непроработанные – давление даст дисциплину только на короткое время. Гораздо лучше понять, как компания работает на самом деле и учитывать это при описании процесса. А для этого нужен пилотный проект.
Часто во время тренингов до слушателей трудно донести, что для достижения целей безопасности необходимы не только технические решения, но и процессы. Решения, полученные вне процессов, не безопасны в строгом понимании. Здесь речь идет об обратных случаях – когда роль процесса переоценивают. Странно, но некоторые руководители думают, что главное – оформить процессную документацию, а после – «нажимать» на людей, чтобы предприятие «жило» по процессу. Эта ошибка опаснее предыдущих, потому что ведет к недооценке проблемы: возникнет ситуация, когда инженеры формально используют процесс, а на практике документация оторвалась от реального положения дел и безопасность не обеспечена. В лучшем случае руководство узнает об этом от внешнего аудитора (например, проходя аудит как поставщик), в худшем – от судебного эксперта, назначенного при рассмотрении иска от заказчика.
Если процессы нелогичные, слишком трудоемкие, непроработанные – давление даст дисциплину только на короткое время. Гораздо лучше понять, как компания работает на самом деле и учитывать это при описании процесса. А для этого нужен пилотный проект.Если процессы нелогичные, слишком трудоемкие, непроработанные – давление даст дисциплину только на короткое время. Гораздо лучше понять, как компания работает на самом деле и учитывать это при описании процесса. А для этого нужен пилотный проект.
Часто во время тренингов до слушателей трудно донести, что для достижения целей безопасности необходимы не только технические решения, но и процессы. Решения, полученные вне процессов, не безопасны в строгом понимании. Здесь речь идет об обратных случаях – когда роль процесса переоценивают. Странно, но некоторые руководители думают, что главное – оформить процессную документацию, а после – «нажимать» на людей, чтобы предприятие «жило» по процессу. Эта ошибка опаснее предыдущих, потому что ведет к недооценке проблемы: возникнет ситуация, когда инженеры формально используют процесс, а на практике документация оторвалась от реального положения дел и безопасность не обеспечена. В лучшем случае руководство узнает об этом от внешнего аудитора (например, проходя аудит как поставщик), в худшем – от судебного эксперта, назначенного при рассмотрении иска от заказчика.
Если процессы нелогичные, слишком трудоемкие, непроработанные – давление даст дисциплину только на короткое время. Гораздо лучше понять, как компания работает на самом деле и учитывать это при описании процесса. А для этого нужен пилотный проект.
Часто во время тренингов до слушателей трудно донести, что для достижения целей безопасности необходимы не только технические решения, но и процессы. Решения, полученные вне процессов, не безопасны в строгом понимании. Здесь речь идет об обратных случаях – когда роль процесса переоценивают. Странно, но некоторые руководители думают, что главное – оформить процессную документацию, а после – «нажимать» на людей, чтобы предприятие «жило» по процессу. Эта ошибка опаснее предыдущих, потому что ведет к недооценке проблемы: возникнет ситуация, когда инженеры формально используют процесс, а на практике документация оторвалась от реального положения дел и безопасность не обеспечена. В лучшем случае руководство узнает об этом от внешнего аудитора (например, проходя аудит как поставщик), в худшем – от судебного эксперта, назначенного при рассмотрении иска от заказчика.
Если процессы нелогичные, слишком трудоемкие, непроработанные – давление даст дисциплину только на короткое время. Гораздо лучше понять, как компания работает на самом деле и учитывать это при описании процесса. А для этого нужен пилотный проект.Если процессы нелогичные, слишком трудоемкие, непроработанные – давление даст дисциплину только на короткое время. Гораздо лучше понять, как компания работает на самом деле и учитывать это при описании процесса. А для этого нужен пилотный проект.
Часто во время тренингов до слушателей трудно донести, что для достижения целей безопасности необходимы не только технические решения, но и процессы. Решения, полученные вне процессов, не безопасны в строгом понимании. Здесь речь идет об обратных случаях – когда роль процесса переоценивают. Странно, но некоторые руководители думают, что главное – оформить процессную документацию, а после – «нажимать» на людей, чтобы предприятие «жило» по процессу. Эта ошибка опаснее предыдущих, потому что ведет к недооценке проблемы: возникнет ситуация, когда инженеры формально используют процесс, а на практике документация оторвалась от реального положения дел и безопасность не обеспечена. В лучшем случае руководство узнает об этом от внешнего аудитора (например, проходя аудит как поставщик), в худшем – от судебного эксперта, назначенного при рассмотрении иска от заказчика.
Если процессы нелогичные, слишком трудоемкие, непроработанные – давление даст дисциплину только на короткое время. Гораздо лучше понять, как компания работает на самом деле и учитывать это при описании процесса. А для этого нужен пилотный проект.
4. Проект пилотный и единственный
Это уже ошибка «для продвинутых». Ее совершают те, кто избежал первых трех ошибок и принял правильное решение – начал пилотный проект. Но тут возникает желание сэкономить и в качестве пилотного завершить (с поддержкой консультантов) «боевой» проект, и полученный в результате продукт предоставить заказчику. Но "боевые" проекты сложны, в них много требований и сложная внутренняя структура. Они не подходят в качестве учебного материала. Попытка убить двух зайцев одним выстрелом заканчивается как всегда: зайцы разбегаются, а пилотный проект становится бесполезным – слишком сложный, чтобы учиться, а процессы еще слишком незрелые, чтобы дать приемлемый результат.4. Проект пилотный и единственный
Это уже ошибка «для продвинутых». Ее совершают те, кто избежал первых трех ошибок и принял правильное решение – начал пилотный проект. Но тут возникает желание сэкономить и в качестве пилотного завершить (с поддержкой консультантов) «боевой» проект, и полученный в результате продукт предоставить заказчику. Но "боевые" проекты сложны, в них много требований и сложная внутренняя структура. Они не подходят в качестве учебного материала. Попытка убить двух зайцев одним выстрелом заканчивается как всегда: зайцы разбегаются, а пилотный проект становится бесполезным – слишком сложный, чтобы учиться, а процессы еще слишком незрелые, чтобы дать приемлемый результат.
Это уже ошибка «для продвинутых». Ее совершают те, кто избежал первых трех ошибок и принял правильное решение – начал пилотный проект. Но тут возникает желание сэкономить и в качестве пилотного завершить (с поддержкой консультантов) «боевой» проект, и полученный в результате продукт предоставить заказчику. Но "боевые" проекты сложны, в них много требований и сложная внутренняя структура. Они не подходят в качестве учебного материала. Попытка убить двух зайцев одним выстрелом заканчивается как всегда: зайцы разбегаются, а пилотный проект становится бесполезным – слишком сложный, чтобы учиться, а процессы еще слишком незрелые, чтобы дать приемлемый результат.4. Проект пилотный и единственный
Это уже ошибка «для продвинутых». Ее совершают те, кто избежал первых трех ошибок и принял правильное решение – начал пилотный проект. Но тут возникает желание сэкономить и в качестве пилотного завершить (с поддержкой консультантов) «боевой» проект, и полученный в результате продукт предоставить заказчику. Но "боевые" проекты сложны, в них много требований и сложная внутренняя структура. Они не подходят в качестве учебного материала. Попытка убить двух зайцев одним выстрелом заканчивается как всегда: зайцы разбегаются, а пилотный проект становится бесполезным – слишком сложный, чтобы учиться, а процессы еще слишком незрелые, чтобы дать приемлемый результат.
5. Без внятного ТЗ результат... не очень
Последняя ошибка -- самая сложная. Эту ошибку трудно заметить и исправить. Состоит она в том, что руководство не понимает, зачем предприятию внедрять процессы безопасности.
Причины внедрения процессов безопасности у каждого свои: «отстройка» от конкурентов, выполнение обязательных требований заказчика или закона, стремление соответствовать современному уровню техники, и др. Важно осознать эту причину и действовать так, чтобы прийти к поставленной цели, а не «обеспечить» абстрактную «безопасность».
Проиллюстрируем взаимосвязь между целями и «фокусом» работ на примерах:
· Цель – скорейшая сертификация: важен четкий процесс и «красота» документации;
· Цель – улучшить конструкцию: уделим максимум влияния процессам анализа безопасности (FMEA, FTA, ETA и др. аббр.);
· Цель – прохождение аудита у заказчика: в первую очередь узнаем, на что важно конкретному заказчику;
· Цель – создать гибкие процессы, которые будут развиваться и расширяться, в т.ч. в другие области техники: максимум инвестиций в тренинги, и т.п.
Все это -- отличные пути, ведущие в разные места. Чтобы выбрать между ними, нужно понять, куда нужно двигаться.
Последняя ошибка -- самая сложная. Эту ошибку трудно заметить и исправить. Состоит она в том, что руководство не понимает, зачем предприятию внедрять процессы безопасности.
Причины внедрения процессов безопасности у каждого свои: «отстройка» от конкурентов, выполнение обязательных требований заказчика или закона, стремление соответствовать современному уровню техники, и др. Важно осознать эту причину и действовать так, чтобы прийти к поставленной цели, а не «обеспечить» абстрактную «безопасность».
Проиллюстрируем взаимосвязь между целями и «фокусом» работ на примерах:
· Цель – скорейшая сертификация: важен четкий процесс и «красота» документации;
· Цель – улучшить конструкцию: уделим максимум влияния процессам анализа безопасности (FMEA, FTA, ETA и др. аббр.);
· Цель – прохождение аудита у заказчика: в первую очередь узнаем, на что важно конкретному заказчику;
· Цель – создать гибкие процессы, которые будут развиваться и расширяться, в т.ч. в другие области техники: максимум инвестиций в тренинги, и т.п.
Все это -- отличные пути, ведущие в разные места. Чтобы выбрать между ними, нужно понять, куда нужно двигаться.
Коротко о шагах процесса:
• Постановка задачи: выясняем, какая именно безопасность нам требуется, по каким стандартам, и зачем.
• Проведение гэп-анализа: определяем несоответствие (гэп) между теми процессами разработки, что есть, и теми, что требуют стандарты
• Планирование: рассматриваем найденные несоответствия, планируем их устранение
• Тренинги: при необходимости обучаем сотрудников
• Процессы безопасности (черновик): фиксируем наши идеи о том, как мы будем выполнять требования стандартов, в процессной документации
• Пилотный проект: проводим пилотный проект, чтобы проверить наши идеи на практике. Там, где идеи не проходят проверку, исправляем процессную документацию
• Внедрение процессов: обеспечиваем сотрудников актуальной процессной документацией и средствами для работы
Роль SafetyConsult
SafetyConsult поможет на всех этапах процесса. У нас есть готовые тренинги, шаблоны, процессные документы и многое другое – это сэкономит время. На этапе «постановка задачи» проконсультируем бесплатно.
• Постановка задачи: выясняем, какая именно безопасность нам требуется, по каким стандартам, и зачем.
• Проведение гэп-анализа: определяем несоответствие (гэп) между теми процессами разработки, что есть, и теми, что требуют стандарты
• Планирование: рассматриваем найденные несоответствия, планируем их устранение
• Тренинги: при необходимости обучаем сотрудников
• Процессы безопасности (черновик): фиксируем наши идеи о том, как мы будем выполнять требования стандартов, в процессной документации
• Пилотный проект: проводим пилотный проект, чтобы проверить наши идеи на практике. Там, где идеи не проходят проверку, исправляем процессную документацию
• Внедрение процессов: обеспечиваем сотрудников актуальной процессной документацией и средствами для работы
Роль SafetyConsult
SafetyConsult поможет на всех этапах процесса. У нас есть готовые тренинги, шаблоны, процессные документы и многое другое – это сэкономит время. На этапе «постановка задачи» проконсультируем бесплатно.
⚡Новости SafetyConsult ⚡
Многие иностранные компании ушли с российского рынка после введения санкций. Кроме Zara и IKEA это сделали и компании-сертификаторы.
SafetyConsult начинает сотрудничество с двумя сертификационными компаниями из Китая.
* Сертификация компетенций, продуктов, систем менеджмента.
* Наши партнёры аккредитованы в Китае и Германии.
* Язык общения -- английский; аудит -- по месту пребывания заказчика.
Многие иностранные компании ушли с российского рынка после введения санкций. Кроме Zara и IKEA это сделали и компании-сертификаторы.
SafetyConsult начинает сотрудничество с двумя сертификационными компаниями из Китая.
* Сертификация компетенций, продуктов, систем менеджмента.
* Наши партнёры аккредитованы в Китае и Германии.
* Язык общения -- английский; аудит -- по месту пребывания заказчика.
Мы продолжаем рассказывать вам о разных аспектах безопасности даже в выходные. Stay tuned!
SafetyConsult: Инженерия безопасности pinned «Зачем вы читаете этот канал?»
Обмен информацией для безопасной разработки: что может и что должен предоставить заказчик?
Вряд ли сейчас возможно построить автомобиль, самолёт, даже стиральную машину одной командой. Большинство продуктов появляется на свет в результате распределенной разработки, требования верхнего уровня воплощают совместными усилиями нескольких команд. У требований безопасности здесь две особенности:
· их нужно не только воплотить, но и отследить, и
· на каждом шаге нужно убедиться, что требования безопасности проходят через соответствующие процессы.
Вряд ли сейчас возможно построить автомобиль, самолёт, даже стиральную машину одной командой. Большинство продуктов появляется на свет в результате распределенной разработки, требования верхнего уровня воплощают совместными усилиями нескольких команд. У требований безопасности здесь две особенности:
· их нужно не только воплотить, но и отследить, и
· на каждом шаге нужно убедиться, что требования безопасности проходят через соответствующие процессы.
Разберем пример: компания «А» разрабатывает автомобильное устройство, при этом компания «Б» разрабатывает для этого устройства «железо», а код пишет компания «В». Это делается в интересах компании «К», которая выпускает автомобили.
Компании «Х» и «Y» поставляют «Б» и «В» программные и аппаратные компоненты.
Компании «Х» и «Y» поставляют «Б» и «В» программные и аппаратные компоненты.
Немного о названиях
На практике производителя конечного продукта (в нашем случае – автомобиля) принято называть ОЕМ (сокращение от «Original Equipment Manufacurer», т.е. «производитель оригинального оборудования»); производителя устройств, которые напрямую интегрируется в конечный продукт – «Tier 1» («поставщик первого уровня»), а поставщика специализированных компонентов для интеграции в автомобильные устройства – «Tier 2» («поставщик второго уровня»). Дальше перечисление не идет, обозначения «Tier 3», «Tier 4» и т.п. не приняты.
На практике производителя конечного продукта (в нашем случае – автомобиля) принято называть ОЕМ (сокращение от «Original Equipment Manufacurer», т.е. «производитель оригинального оборудования»); производителя устройств, которые напрямую интегрируется в конечный продукт – «Tier 1» («поставщик первого уровня»), а поставщика специализированных компонентов для интеграции в автомобильные устройства – «Tier 2» («поставщик второго уровня»). Дальше перечисление не идет, обозначения «Tier 3», «Tier 4» и т.п. не приняты.
Процессы безопасной разработки
Прежде чем говорить о требованиях к продукту, разберемся, кто за них отвечает. Чтобы воплощать требования безопасности, нужны подходящие процессы, т.н. «система менеджмента безопасности». Стандарт ИСО 26262-2 описывает жизненный цикл, содержащий функциональный и системный уровень, а также разработку «железа» и ПО. По нашей схеме это охватывает ОЕМ, Tier 1 и Tier 2, то есть компании «К», «А», «Б» и «В». К другим компаниям («X» и «Y») требование о соответствии процессов напрямую не применяется.
Обязанность убедиться в соответствии поставщиков стандартам безопасности лежит на том, кто интегрирует продукт. Это значит, «К» проводит аудит «А», а «А» -- аудит «Б» и «В». На практике аудитом цепочки часто занимается ОЕМ: если продукт нанесет вред конечному пользователю, то отвечать ОЕМ. Компенсацию с поставщиков компонентов запросить можно, если доказать, что вред нанесен по вине поставщика. Но кому нужна возня с юристами -- проще провести аудит и быть спокойным.
Если на «Х» и «Y» не распространяются требования ИСО 26262, не понятно, на чем будет основано наше доверие продуктам этих компаний. Это зависит от того, какую часть устройства они поставляют. Если речь идёт, например, об элементной базе (транзисторах, резисторах и т.п.), достаточно подтверждения системы менеджмента качества (СМК) и тестирования по соответствующему стандарту (например, для элементной базы – по стандартам AECQ). Сложные компоненты (чипы, драйверы и т.п.) интегрируются через процедуру квалификации ПО или оценки компонентов аппаратной части. Об этих процедурах – в следующих постах.
Прежде чем говорить о требованиях к продукту, разберемся, кто за них отвечает. Чтобы воплощать требования безопасности, нужны подходящие процессы, т.н. «система менеджмента безопасности». Стандарт ИСО 26262-2 описывает жизненный цикл, содержащий функциональный и системный уровень, а также разработку «железа» и ПО. По нашей схеме это охватывает ОЕМ, Tier 1 и Tier 2, то есть компании «К», «А», «Б» и «В». К другим компаниям («X» и «Y») требование о соответствии процессов напрямую не применяется.
Обязанность убедиться в соответствии поставщиков стандартам безопасности лежит на том, кто интегрирует продукт. Это значит, «К» проводит аудит «А», а «А» -- аудит «Б» и «В». На практике аудитом цепочки часто занимается ОЕМ: если продукт нанесет вред конечному пользователю, то отвечать ОЕМ. Компенсацию с поставщиков компонентов запросить можно, если доказать, что вред нанесен по вине поставщика. Но кому нужна возня с юристами -- проще провести аудит и быть спокойным.
Если на «Х» и «Y» не распространяются требования ИСО 26262, не понятно, на чем будет основано наше доверие продуктам этих компаний. Это зависит от того, какую часть устройства они поставляют. Если речь идёт, например, об элементной базе (транзисторах, резисторах и т.п.), достаточно подтверждения системы менеджмента качества (СМК) и тестирования по соответствующему стандарту (например, для элементной базы – по стандартам AECQ). Сложные компоненты (чипы, драйверы и т.п.) интегрируются через процедуру квалификации ПО или оценки компонентов аппаратной части. Об этих процедурах – в следующих постах.
Передача системных требований
Независимо от того, участвует в разработке одна команда или больше, по стандартам безопасности нужно дерево требований. Это такая структура, в которой каждое требование связано с требованием верхнего уровня, которое оно воплощает (связь "implement"). Только так можно убедиться, что технические верхних уровней решения воплощены "ниже по течению".
Кроме этого, на каждом уровне проводится анализ безопасности. Анализ проводится по специальному алгоритму чтобы убедиться, что при декомпозиции требований ничего не забыли. В ходе анализа появляются новые требования. Большинство таких требований остаются на том же уровне (например, при анализе ПО появляются требования к ПО), но иногда требования, возникшие при анализе, выставляются на другой уровень (например, при анализе ПО понимаем, что видим недостающее требование системного уровня).
Независимо от того, участвует в разработке одна команда или больше, по стандартам безопасности нужно дерево требований. Это такая структура, в которой каждое требование связано с требованием верхнего уровня, которое оно воплощает (связь "implement"). Только так можно убедиться, что технические верхних уровней решения воплощены "ниже по течению".
Кроме этого, на каждом уровне проводится анализ безопасности. Анализ проводится по специальному алгоритму чтобы убедиться, что при декомпозиции требований ничего не забыли. В ходе анализа появляются новые требования. Большинство таких требований остаются на том же уровне (например, при анализе ПО появляются требования к ПО), но иногда требования, возникшие при анализе, выставляются на другой уровень (например, при анализе ПО понимаем, что видим недостающее требование системного уровня).