Стандарты управления рисками

Риск-менеджмент как технология управления за последние 10-15 лет переживает за рубежом и в России период своего активного становления. Особую важность приобретает проблематика формирования единого понимания цели и задач системы риск-менеджмента, применяемой терминологии, организационной структуры и самого процесса риск-менеджмента, адаптированных к современным российским условиям. Мировая практика предлагает один из универсальных подходов к решению данной проблемы – унификация и стандартизация в области управления рисками.

Согласно определению Международной организации по стандартизации (ISO - ИСО), стандарт – нормативный документ, который разработан на основе консенсуса, принят признанным на соответствующем уровне органом и устанавливает для всеобщего и многократного использования правила, общие принципы и характеристики, касающиеся различных видов деятельности или их результатов, и который направлен на достижение оптимальной степени упорядоченности в определенной области. Стандарты должны быть основаны на обобщенных результатах науки, техники и практического опыта и направлены на достижение оптимальной пользы для общества

В последние годы отчетливо проявилась тенденция к тиражированию в ряде стран, в том числе в России, стандартов управления рисками, разработанных впервые 10 – 15 лет назад и касающихся преимущественно техногенных опасных факторов. К их числу следует отнести ГОСТ 27.310-95 «Анализ видов, последствий и критичности отказов», ГОСТ Р 51901-2002 «Управление надежностью. Анализ риска технологических систем», ГОСТ Р 51897‑2002 «Менеджмент риска. Термины и определения», а также ГОСТ ы ИСО/ТО 12100-1 и 2 - 2002 «Безопасность оборудования. Основные понятия, общие принципы конструирования» и другие.

Далее стали разрабатываться и принимались стандарты управления рисками в деятельности хозяйствующих субъектов, такие как:

- ГОСТ Р 51901.2-2005 Менеджмент риска. Системы менеджмента надежности,

- ГОСТ Р 51901.13-2005 Менеджмент риска. Анализ дерева неисправностейи ряд других В течение 5-6 лет было разработано 8 стандартов риск-менеджмента, и эта работа далеко не закончена. В 2009 г. был подготовлен и в августе 2010 г. принят новый стандарт - ISO 31000 «Общие указания по принципам и реализации менеджмента риска».

Повышенное внимание со стороны консультантов в области риск-менеджмента, действующих на российском рынке, уделяется документу «Управление рисками организаций. Интегрированная модель», разработанному Комитетом спонсорских организаций комиссии Тредвея (Committee of Sponsoring Organizations of the Treadway Commission, COSO)

Русским обществом управления риском кроме рекомендаций COSO в качестве базового рассматривается Стандарт по управлению рисками Федерации европейских ассоциаций риск-менеджеров (FERMA), который является совместной разработкой Института риск-менеджмента (IRM), Ассоциации риск-менеджмента и страхования (AIRMIC) и Национального форума по риск-менеджменту в общественном секторе (ALARM) (2002 г.).

Жизненный цикл дефекта

Дефект – обнаруженная в процессе разработки, тестирования или эксплуатации ошибка в разрабатываемом приложении.

Жизненный цикл дефекта (bug workflow) – последовательность этапов, которые проходит дефект на своём пути с момента его создания до окончательного закрытия. Для лучшего восприятия изображается в виде схемы с возможными статусами и действиями, которые приводят к смене этих статусов.

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

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

• Новый (статус присваивается автоматически после внесения дефект -репорта)
• Открыт (дефект получает данный статус после того, как была проведена его валидация руководителем команды и данная ошибка действительно должна быть исправлена)
• Отклонён (присваивается также после анализа нового дефекта руководителем команды в случае, если описанная ошибка уже ранее была внесена в систему (дубликат) или же по каким-то причинам не требуется её исправление)
• Исправлен (присваивается специалистом разработки после того, как ошибка была устранена)
• Повторно открыт (при повторном возникновении ошибки после её предварительного исправления)
• Закрыт (после окончательного исправления дефекта и проведении дополнительной проверки).

Причины нотификации

Способы нотификации

Политика нотификации