Как “войти” в безопасность — делаем все правильно с самого начала

First time right, every time right

John Plant, TRW Inc.

Представьте, что день настал. Руководство компании решило создать продукт с функциональной безопасностью «на борту». Выбрали подходящий стандарта (или стандарты), проанализировали его. Дальше начинается внедрение. Двух одинаковых команд нет, потому что нет двух одинаковых людей. Даже в одной компании и одного офиса команды отличаются. Но если люди разрабатывают электронику и ПО – то смогут и безопасную электронику или ПО. Как говорят в США, that’s no rocket science. Вопрос только в правильном подходе и ресурсах. В этой статье рассмотрим частые ошибки и выдадим рекомендации, как делать правильно. Обсуждаемые вопросы и предлагаемые решения относятся как к функциональной, так и к кибер-безопасности, а еще к безопасности целевой функции, безопасности труда и к какой угодно сфере «безопасностных наук».

Ошибки

1. Нанял и забыл

Стандарты безопасности вводят роль «менеджера безопасности» (в ИСО 26262 это «менеджер ФБ», в МЭК 61508 – «инженер ФБ», и т.п.) Часто у руководителей на этом мысль останавливается. У Станислава Лема был рассказ, где всемогущая машина первым делом создала другую всемогущую машину, чтобы делегировать задачи (а та создала третью, и так далее). Следуя тому же ходу мысли, «большой» менеджер (главный инженер, СТО, директор по развитию, иногда даже генеральный директор) создает (нанимает) «маленького» менеджера по безопасности, препоручает ему фронт работ и исчезает.

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

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

2. Инструмент впереди паровоза

Эта ошибка похожа на предыдущую, но делегируют не человеку, а программному инструменту. Здесь будет уместно вспомнить другую американскую поговорку – a fool with a tool is still a fool. Не будем обсуждать полезность инструментов жизненного цикла безопасности – об этом в другой записи. Инструменты (в том числе и программные) применяют для использования в процессе. Но если процесса нет – то нечего и автоматизировать, инструменты негде применять. Прежде чем приобретать инструменты, убедитесь, что они вам зачем-то нужны.

3. Процесс впереди паровоза

Часто во время тренингов до слушателей трудно донести, что для достижения целей безопасности необходимы не только технические решения, но и процессы. Решения, полученные вне процессов, не безопасны в строгом понимании. Здесь речь идет об обратных случаях – когда роль процесса переоценивают. Странно, но некоторые руководители думают, что главное – оформить процессную документацию, а после – «нажимать» на людей, чтобы предприятие «жило» по процессу. Эта ошибка опаснее предыдущих, потому что ведет к недооценке проблемы: возникнет ситуация, когда инженеры формально используют процесс, а на практике документация оторвалась от реального положения дел и безопасность не обеспечена. В лучшем случае руководство узнает об этом от внешнего аудитора (например, проходя аудит как поставщик), в худшем – от судебного эксперта, назначенного при рассмотрении иска от заказчика.

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

Процессная документация готова!

4. Проект пилотный и единственный

Это уже ошибка «для продвинутых». Ее совершают те, кто избежал первых трех ошибок и принял правильное решение – начал пилотный проект. Но тут возникает желание сэкономить и в качестве пилотного завершить (с поддержкой консультантов) «боевой» проект, и полученный в результате продукт предоставить заказчику. Но “боевые” проекты сложны, в них много требований и сложная внутренняя структура. Они не подходят в качестве учебного материала. Попытка убить двух зайцев одним выстрелом заканчивается как всегда: зайцы разбегаются, а пилотный проект становится бесполезным – слишком сложный, чтобы учиться, а процессы еще слишком незрелые, чтобы дать приемлемый результат.

5. Без внятного ТЗ результат… не очень

Последняя ошибка — самая сложная. Эту ошибку трудно заметить и исправить. Состоит она в том, что руководство не понимает, зачем предприятию внедрять процессы безопасности.

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

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

  • Цель – скорейшая сертификация: важен четкий процесс и «красота» документации;
  • Цель – улучшить конструкцию: уделим максимум влияния процессам анализа безопасности (FMEA, FTA, ETA и др. аббр.);
  • Цель – прохождение аудита у заказчика: в первую очередь узнаем, на что важно конкретному заказчику;
  • Цель – создать гибкие процессы, которые будут развиваться и расширяться, в т.ч. в другие области техники: максимум инвестиций в тренинги, и т.п.

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

Как сделать правильно?

На этот вопрос отвечаем рисунком

Правильный путь к внедрению процессов безопасности и не только

Коротко о шагах процесса

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

Роль SafetyConsult

SafetyConsult поможет на всех этапах процесса. У нас есть готовые тренинги, шаблоны, процессные документы и многое другое – это сэкономит время. На этапе «постановка задачи» проконсультируем бесплатно.

Поделиться публикацией

Подпишитесь на наши новости

Будем уведомлять вас о новых публикациях

Читать другие публикации

Анализ безопасности

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

Читать

Квалификация “железа”

Если «железо» не разработано согласно ИСО 26262, то в проект с требованиями безопасности оно попадет только после прохождения процедуры квалификации.Квалификация проводится в контексте проекта, то есть один и тот же

Читать

Забронируйте бесплатную консультацию прямо сейчас

functional safety

Свяжитесь с нами

Напишите нам по любому вопросу и мы ответим вам через мгновение