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 поможет на всех этапах процесса. У нас есть готовые тренинги, шаблоны, процессные документы и многое другое – это сэкономит время. На этапе «постановка задачи» проконсультируем бесплатно.
