Неожиданно под санкции попали... стандарты. Магазин ИСО еще работает, а MISRA уже нет.
Может быть, они там думают, что применение стандартов кодирования могло бы улучшить российскую военную технику? Могло бы. Но не улучшает, потому что у разработчиков военной техники совсем другие проблемы :-)
Может быть, они там думают, что применение стандартов кодирования могло бы улучшить российскую военную технику? Могло бы. Но не улучшает, потому что у разработчиков военной техники совсем другие проблемы :-)
Независимая проверка соответствия: зачем нужна сертификация функциональной безопасности?
Дорогая бумага
По определению, сертификация – это «формальная проверка или подтверждение конкретных характеристик объекта, организации или сотрудника». Сертификаты показывают соответствие текущему уровню техники (state of the art, SOTA).
Сертификация безопасности продукта показывает, что риск, связанный с использованием этого продукта, проверили по соответствующему международному стандарту и этот риск оказался приемлемым. Сертификат безопасности обязателен для всех категорий продуктов – от одежды до авионики. Включая, конечно, электронные блоки управления автомобилей. Такой сертификат выдает либо сам производитель продукта (это называется «декларация соответствия»), либо отдельный орган по сертификации. Остаток этой статьи посвящен сертификатам безопасности, выдаваемым внешними организациями.
Дорогая бумага
По определению, сертификация – это «формальная проверка или подтверждение конкретных характеристик объекта, организации или сотрудника». Сертификаты показывают соответствие текущему уровню техники (state of the art, SOTA).
Сертификация безопасности продукта показывает, что риск, связанный с использованием этого продукта, проверили по соответствующему международному стандарту и этот риск оказался приемлемым. Сертификат безопасности обязателен для всех категорий продуктов – от одежды до авионики. Включая, конечно, электронные блоки управления автомобилей. Такой сертификат выдает либо сам производитель продукта (это называется «декларация соответствия»), либо отдельный орган по сертификации. Остаток этой статьи посвящен сертификатам безопасности, выдаваемым внешними организациями.
Кто может выдавать сертификаты?
Цель получения сертификата – повышение доверия к продукту. Органы сертификации (коммерческие организации) получают аккредитацию (от латинского слова «credo», означающего «верить, доверять») в уполномоченных государственных органах. В России это Федеральная Служба по Аккредитации («Росаккредитация») Министерства экономического развития. Компании без аккредитации не могут выдавать сертификаты международного образца.
Цель получения сертификата – повышение доверия к продукту. Органы сертификации (коммерческие организации) получают аккредитацию (от латинского слова «credo», означающего «верить, доверять») в уполномоченных государственных органах. В России это Федеральная Служба по Аккредитации («Росаккредитация») Министерства экономического развития. Компании без аккредитации не могут выдавать сертификаты международного образца.
Когда говорят о сертификации, сразу всплывает аббревиатура TÜV. Это сокращение немецкого Объединения технического надзора (Technischer Überwachungsverein). Раннее единую государственная служба приватизировали и разделили по территориальному признаку: TÜV Süd с главным офисом в Мюнхене, TÜV Nord в Гамбурге, TÜV Rheinland в Кёльне. Кроме немецких организаций, к топ 10 относятся такие компании как Underwriter Laboratories (UL) из США, Büro Veritas (BV) из Франции. В России аккредитованных органов по сертификации в области функциональной безопасности автомобильной техники пока нет. Возможно, SafetyConsult станет первым – следите за обновлениями на этом канале.
• Закон «О безопасности дорожного движения» определяет не только требования к автомобилям, но и требования к дорогам, правила, ответственность за нарушения, права и обязанности государства и его органов, их роль в обеспечении безопасности на дороги. Это закон, обязательный к исполнению.
• Закон ссылается на Технический регламент Таможенного союза «О безопасности дорожных транспортных средств». Техрегламент содержит конкретные технические требования и применяется для оценки безопасности всего автомобиля. На основании технического регламента проводится проверка типа транспортного средства – процедура допуска автомобиля конкретной модели на дороги общего пользования.
• Техрегламент ссылается на Правила Европейской экономической комиссии (ЕЭК) ООН. Венская Конвенция о дорожном движении, принятая в 1968 возлагает на ЕЭК ООН (расположена в Женеве) функции по разработке технических требований к безопасности автомобилей, обязательных к применению во всех странах, подписавших Конвенцию. К ним относится и Россия. Эти правила заимствуются в национальные технические регламенты без изменений. Правила относятся к отдельным компонентам автомобиля, например UN ECE R13 – к тормозной системе, а UN ECE R79 – к рулевой.
• Правила ЕЭК ООН не ссылаются на стандарты ИСО напрямую, но цитируют эти стандарты. Упомянутые выше UN ECE R13 и R79 требуют «…всестороннего рассмотрения, классификации рисков и принятия мер по их снижению до допустимого уровня». И хотя напрямую номер стандарта нигде не упомянут, очевидно, что применение жизненного цикла функциональной безопасности по ИСО 26262 требуется для выполнения этих правил.
• Сертификаты, о которых эта статья, используют для подтверждения соответствия стандартам – как тем, которые цитируют правила ЕЭК ООН, так и другим.
• Закон ссылается на Технический регламент Таможенного союза «О безопасности дорожных транспортных средств». Техрегламент содержит конкретные технические требования и применяется для оценки безопасности всего автомобиля. На основании технического регламента проводится проверка типа транспортного средства – процедура допуска автомобиля конкретной модели на дороги общего пользования.
• Техрегламент ссылается на Правила Европейской экономической комиссии (ЕЭК) ООН. Венская Конвенция о дорожном движении, принятая в 1968 возлагает на ЕЭК ООН (расположена в Женеве) функции по разработке технических требований к безопасности автомобилей, обязательных к применению во всех странах, подписавших Конвенцию. К ним относится и Россия. Эти правила заимствуются в национальные технические регламенты без изменений. Правила относятся к отдельным компонентам автомобиля, например UN ECE R13 – к тормозной системе, а UN ECE R79 – к рулевой.
• Правила ЕЭК ООН не ссылаются на стандарты ИСО напрямую, но цитируют эти стандарты. Упомянутые выше UN ECE R13 и R79 требуют «…всестороннего рассмотрения, классификации рисков и принятия мер по их снижению до допустимого уровня». И хотя напрямую номер стандарта нигде не упомянут, очевидно, что применение жизненного цикла функциональной безопасности по ИСО 26262 требуется для выполнения этих правил.
• Сертификаты, о которых эта статья, используют для подтверждения соответствия стандартам – как тем, которые цитируют правила ЕЭК ООН, так и другим.
Выводы из написанного выше такие:
• ИСО 26262 уже необходим для рулевой и тормозной систем, блоков ADAS и некоторых других. Список компонентов, для которых необходимо пройти жизненный цикл ФБ, будет расширяться.
• Применение ИСО 26262 в проверят во время процедуры одобрения типа транспортного средства.
• Внешняя сертификация по ИСО 26262 отдельных элементов автомобиля необязательна. Рассмотрение сертификатов ФБ отдельных элементов во время процедуры одобрения типа ТС остается на усмотрение органа, проводящего одобрение типа.
Аналогичная ситуация и в авионике, промышленной автоматизации и других областях: нужно следовать жизненному циклу функциональной безопасности на уровне изделия (летательного аппарата, производственной линии и т.п.), но внешняя сертификация отдельных блоков необязательна
• ИСО 26262 уже необходим для рулевой и тормозной систем, блоков ADAS и некоторых других. Список компонентов, для которых необходимо пройти жизненный цикл ФБ, будет расширяться.
• Применение ИСО 26262 в проверят во время процедуры одобрения типа транспортного средства.
• Внешняя сертификация по ИСО 26262 отдельных элементов автомобиля необязательна. Рассмотрение сертификатов ФБ отдельных элементов во время процедуры одобрения типа ТС остается на усмотрение органа, проводящего одобрение типа.
Аналогичная ситуация и в авионике, промышленной автоматизации и других областях: нужно следовать жизненному циклу функциональной безопасности на уровне изделия (летательного аппарата, производственной линии и т.п.), но внешняя сертификация отдельных блоков необязательна
Плюсы, минусы и частые случаи внешней сертификации
Плюсы
Внешняя сертификация ФБ может:
• Убедить заказчиков, что ваш продукт безопасен и вы будете подходящим поставщиком
• Убедить вас, что продукт другой компании безопасен и она будет подходящим поставщиком
• Заменить регулярный аудит поставщика в жизненном цикле безопасности (ИСО 26262-8, гл. 5)
• Заменить меры подтверждения в жизненном цикле безопасности (ИСО 26262-2, гл. 6)
• Позиционировать продукт на рынке, дать преимущество перед конкурентами, показать готовность следовать SOTA. Да и бумага приятная наощупь.
Минусы
Внешняя сертификация ФБ не может:
• Научить пользоваться стандартом ИСО 26262
• Обеспечить полную безопасность использования продукта
• Гарантировать соответствие продукта SOTA за пределами функциональной безопасности
• Гарантировать соответствие продукта целевому применению (орган по сертификации не может знать ваш продукт лучше, чем вы)
Когда сертифицироваться?
Сертифицируются обычно в одном из следующих случаев:
• Компания сталкивается с жизненным циклом функциональной безопасности впервые
• Компания уже создает продукты не для использования в автомобиле (например, ПО для компьютеров и мобильных платформ) и хотят «портировать» этот продукт на автомобиль
• Сертификат требует заказчик
Плюсы
Внешняя сертификация ФБ может:
• Убедить заказчиков, что ваш продукт безопасен и вы будете подходящим поставщиком
• Убедить вас, что продукт другой компании безопасен и она будет подходящим поставщиком
• Заменить регулярный аудит поставщика в жизненном цикле безопасности (ИСО 26262-8, гл. 5)
• Заменить меры подтверждения в жизненном цикле безопасности (ИСО 26262-2, гл. 6)
• Позиционировать продукт на рынке, дать преимущество перед конкурентами, показать готовность следовать SOTA. Да и бумага приятная наощупь.
Минусы
Внешняя сертификация ФБ не может:
• Научить пользоваться стандартом ИСО 26262
• Обеспечить полную безопасность использования продукта
• Гарантировать соответствие продукта SOTA за пределами функциональной безопасности
• Гарантировать соответствие продукта целевому применению (орган по сертификации не может знать ваш продукт лучше, чем вы)
Когда сертифицироваться?
Сертифицируются обычно в одном из следующих случаев:
• Компания сталкивается с жизненным циклом функциональной безопасности впервые
• Компания уже создает продукты не для использования в автомобиле (например, ПО для компьютеров и мобильных платформ) и хотят «портировать» этот продукт на автомобиль
• Сертификат требует заказчик
Наша роль
SafetyConsult не только проведет работы по функциональной безопасности, но и поможет получить сертификат. Будем представлять вас перед органом по сертификации, сэкономим время и деньги на внесение изменений в процессы и в продукт.
Если европейские и американские органы по сертификации станут окончательно недоступны, будем подключать компании из Китая, чтобы наши заказчики работали не обращая внимания на происходящую репетицию апокалипсиса.
SafetyConsult не только проведет работы по функциональной безопасности, но и поможет получить сертификат. Будем представлять вас перед органом по сертификации, сэкономим время и деньги на внесение изменений в процессы и в продукт.
Если европейские и американские органы по сертификации станут окончательно недоступны, будем подключать компании из Китая, чтобы наши заказчики работали не обращая внимания на происходящую репетицию апокалипсиса.
Цифровые инструменты в жизненном цикле функциональной безопасности
Менеджерское мышление говорит нам: для каждой задачи нужен специальный инструмент. Так ли это для задач ФБ?
Safety overhead
Жизненный цикл функциональной безопасности стоит инженерам много часов труда, а предприятию – больших расходов.
Перефразируя Эйнштейна, чтобы безопасно разрабатывать, нужно тратить много усилий – но не больше, чем нужно. Попробуем выразить в человеко-часах. Окончательного ответа на этот вопрос нет, но вот некоторые прикидки. Считается, что применение системно-инженерных практик (управление архитектурой, управление требованиями, плановое версионирование и конфигурация) увеличивают трудозатраты на 20%. Эта цифра кажется устаревшей, так как рассматривает традиционные способы разрабатывать («водопад» или V-модель). Современное ПО, а иногда и железо, разрабатывается по гибкой модели (agile).
Хотя гибкая разработка напрямую стандартами безопасности не запрещается – отчасти потому, что стандарты писали до того, как этот подход стал популярен – «гибкий» и «безопасный» способы сложно использовать вместе. Таким образом, при переходе от «гибкой» разработки к «безопасной» придется не только добавить отдельные шаги, но и изменить сам подход. Поэтому оценка в 30%..50% от всей трудоемкости – в зависимости доли и сложности ПО -- ближе к истине. Но причем тут цифровые инструменты?
Менеджерское мышление говорит нам: для каждой задачи нужен специальный инструмент. Так ли это для задач ФБ?
Safety overhead
Жизненный цикл функциональной безопасности стоит инженерам много часов труда, а предприятию – больших расходов.
Перефразируя Эйнштейна, чтобы безопасно разрабатывать, нужно тратить много усилий – но не больше, чем нужно. Попробуем выразить в человеко-часах. Окончательного ответа на этот вопрос нет, но вот некоторые прикидки. Считается, что применение системно-инженерных практик (управление архитектурой, управление требованиями, плановое версионирование и конфигурация) увеличивают трудозатраты на 20%. Эта цифра кажется устаревшей, так как рассматривает традиционные способы разрабатывать («водопад» или V-модель). Современное ПО, а иногда и железо, разрабатывается по гибкой модели (agile).
Хотя гибкая разработка напрямую стандартами безопасности не запрещается – отчасти потому, что стандарты писали до того, как этот подход стал популярен – «гибкий» и «безопасный» способы сложно использовать вместе. Таким образом, при переходе от «гибкой» разработки к «безопасной» придется не только добавить отдельные шаги, но и изменить сам подход. Поэтому оценка в 30%..50% от всей трудоемкости – в зависимости доли и сложности ПО -- ближе к истине. Но причем тут цифровые инструменты?
Инструменты ФБ vs. MS Excel
Инструменты жизненного цикла ФБ – это программы, автоматизирующие выполнение задач жизненного цикла или предназначенные для управления задачами. Системы управления требованиями или архитектурой -- не инструменты жизненного цикла ФБ. Хотя некоторые инструменты ФБ могут и управлять требованиями, "класть" все системно-инженерные работы в инструмент ФБ означает сделать много ненужной работы, потому что требования, относящиеся к безопасности и не относящиеся к ней, живут по разным жизненным циклам.
Инструменты ФБ снижают затраты на управление жизненным циклом, но не решают задач сами по себе. Каким бы «умным» ни был инструмент, чтобы им пользоваться, нужен человек, который знает стандарты и уметь выполнять нужные задачи. Тогда инструмент возьмет на себя управление задачами, слежение за сроками, предоставит шаблоны. Но инструменты ФБ -- это узко-специализированный товар, который дорого стоит, менеджер задач и табличный редактор с дополнительными функциями за $10.000 в год.
И проблемы на этом не заканчиваются. Жизненный цикл безопасности нуждается в подгонке (tailoring), и если используется инструмент – его тоже придется подгонять. За время работы инженером по ФБ я видел много шаблонов, созданных на основе MS Excel, в которых воплощались особенности конкретных проектов и процессов. В покупных инструментах этого тоже не будет, но будет интерфейс, кастомизации таблиц или возможность писать макросы. Здесь специализированный инструмент проиграет MS Excel, ведь легкая кастомизация – ключ к успеху офисного пакета общего назначения; да и фирмы, создающие инструменты ФБ по качеству продукции и опыту отстают от Microsoft. Табличный редактор инструмента ФБ будет хуже, чем MS Excel, несмотря на нужные для анализа безопасности алгоритмы "из коробки".
Инструменты жизненного цикла ФБ – это программы, автоматизирующие выполнение задач жизненного цикла или предназначенные для управления задачами. Системы управления требованиями или архитектурой -- не инструменты жизненного цикла ФБ. Хотя некоторые инструменты ФБ могут и управлять требованиями, "класть" все системно-инженерные работы в инструмент ФБ означает сделать много ненужной работы, потому что требования, относящиеся к безопасности и не относящиеся к ней, живут по разным жизненным циклам.
Инструменты ФБ снижают затраты на управление жизненным циклом, но не решают задач сами по себе. Каким бы «умным» ни был инструмент, чтобы им пользоваться, нужен человек, который знает стандарты и уметь выполнять нужные задачи. Тогда инструмент возьмет на себя управление задачами, слежение за сроками, предоставит шаблоны. Но инструменты ФБ -- это узко-специализированный товар, который дорого стоит, менеджер задач и табличный редактор с дополнительными функциями за $10.000 в год.
И проблемы на этом не заканчиваются. Жизненный цикл безопасности нуждается в подгонке (tailoring), и если используется инструмент – его тоже придется подгонять. За время работы инженером по ФБ я видел много шаблонов, созданных на основе MS Excel, в которых воплощались особенности конкретных проектов и процессов. В покупных инструментах этого тоже не будет, но будет интерфейс, кастомизации таблиц или возможность писать макросы. Здесь специализированный инструмент проиграет MS Excel, ведь легкая кастомизация – ключ к успеху офисного пакета общего назначения; да и фирмы, создающие инструменты ФБ по качеству продукции и опыту отстают от Microsoft. Табличный редактор инструмента ФБ будет хуже, чем MS Excel, несмотря на нужные для анализа безопасности алгоритмы "из коробки".
Выводы
В завершение хочу поделиться выводами по поводу использования инструментов управления жизненным циклом ФБ на основе 10-летнего опыта работы с ними:
● Нет таких требований и задач жизненного цикла безопасности, которые нельзя решить, используя только офисные пакеты (речь не идет о требованиях к разработке ПО – там есть инструменты, без которых не обойтись)
● Никакой инструмент, как бы дорог он ни был, не заменит исполнителей, разбирающихся в том, что делают.
● Использовать инструменты жизненного цикла ФБ имеет смысл только в том случае, если продукты похожи друг на друга и, проекты будут использоваться повторно.
● Если используете инструменты жизненного цикла ФБ – подгоняйте их под задачи. Правильная подгонка – ключ к успеху.
Последнее и главное, о чем я хочу напомнить: процессы безопасности строится поверх системно-инженерных процессов. Если у нет системы управления требованиями и архитектура в MS Visio, не покупайте инструменты жизненного цикла ФБ – развивайте системно-инженерный инструментарий.
Роль SafetyConsult
Несмотря на весь скепсис по отношению к инструментам жизненного цикла ФБ, который есть в этой статье, мы можем:
* Развернуть на предприятии процессы ФБ согласно ИСО 26262, МЭК 61508 и другим стандартам, и выдать рекомендации по инструментарию
* Настроить различные инструменты ФБ (у нас есть опыт с ANSYS Medini analyze, APIS IQ RM, Isograph Reliability Workbench и другими)
* Создать шаблоны для HARA, FMEA, других документов жизненного цикла функциональной безопасности в "обычных" офисных программах
Посетителям тренингов мы предоставляем шаблоны бесплатно.
В завершение хочу поделиться выводами по поводу использования инструментов управления жизненным циклом ФБ на основе 10-летнего опыта работы с ними:
● Нет таких требований и задач жизненного цикла безопасности, которые нельзя решить, используя только офисные пакеты (речь не идет о требованиях к разработке ПО – там есть инструменты, без которых не обойтись)
● Никакой инструмент, как бы дорог он ни был, не заменит исполнителей, разбирающихся в том, что делают.
● Использовать инструменты жизненного цикла ФБ имеет смысл только в том случае, если продукты похожи друг на друга и, проекты будут использоваться повторно.
● Если используете инструменты жизненного цикла ФБ – подгоняйте их под задачи. Правильная подгонка – ключ к успеху.
Последнее и главное, о чем я хочу напомнить: процессы безопасности строится поверх системно-инженерных процессов. Если у нет системы управления требованиями и архитектура в MS Visio, не покупайте инструменты жизненного цикла ФБ – развивайте системно-инженерный инструментарий.
Роль SafetyConsult
Несмотря на весь скепсис по отношению к инструментам жизненного цикла ФБ, который есть в этой статье, мы можем:
* Развернуть на предприятии процессы ФБ согласно ИСО 26262, МЭК 61508 и другим стандартам, и выдать рекомендации по инструментарию
* Настроить различные инструменты ФБ (у нас есть опыт с ANSYS Medini analyze, APIS IQ RM, Isograph Reliability Workbench и другими)
* Создать шаблоны для HARA, FMEA, других документов жизненного цикла функциональной безопасности в "обычных" офисных программах
Посетителям тренингов мы предоставляем шаблоны бесплатно.
Как "войти" в безопасность. Делаем все правильно с самого начала
First time right, every time right -- John Plant, TRW Inc.
Представьте, что день настал. Руководство компании решило создать продукт с функциональной безопасностью «на борту». Выбрали подходящий стандарта (или стандарты), проанализировали его. Дальше начинается внедрение. Двух одинаковых команд нет, потому что нет двух одинаковых людей. Даже в одной компании и одного офиса команды отличаются. Но если люди разрабатывают электронику и ПО – то смогут и безопасную электронику или ПО. Как говорят в США, that's no rocket science. Вопрос только в правильном подходе и ресурсах. В этой статье рассмотрим частые ошибки и выдадим рекомендации, как делать правильно. Обсуждаемые вопросы и предлагаемые решения относятся как к функциональной, так и к кибер-безопасности, а еще к безопасности целевой функции, безопасности труда и к какой угодно сфере «безопасностных наук».
First time right, every time right -- John Plant, TRW Inc.
Представьте, что день настал. Руководство компании решило создать продукт с функциональной безопасностью «на борту». Выбрали подходящий стандарта (или стандарты), проанализировали его. Дальше начинается внедрение. Двух одинаковых команд нет, потому что нет двух одинаковых людей. Даже в одной компании и одного офиса команды отличаются. Но если люди разрабатывают электронику и ПО – то смогут и безопасную электронику или ПО. Как говорят в США, that's no rocket science. Вопрос только в правильном подходе и ресурсах. В этой статье рассмотрим частые ошибки и выдадим рекомендации, как делать правильно. Обсуждаемые вопросы и предлагаемые решения относятся как к функциональной, так и к кибер-безопасности, а еще к безопасности целевой функции, безопасности труда и к какой угодно сфере «безопасностных наук».
Ошибки
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. Проект пилотный и единственный
Это уже ошибка «для продвинутых». Ее совершают те, кто избежал первых трех ошибок и принял правильное решение – начал пилотный проект. Но тут возникает желание сэкономить и в качестве пилотного завершить (с поддержкой консультантов) «боевой» проект, и полученный в результате продукт предоставить заказчику. Но "боевые" проекты сложны, в них много требований и сложная внутренняя структура. Они не подходят в качестве учебного материала. Попытка убить двух зайцев одним выстрелом заканчивается как всегда: зайцы разбегаются, а пилотный проект становится бесполезным – слишком сложный, чтобы учиться, а процессы еще слишком незрелые, чтобы дать приемлемый результат.