Как пишется инцидент менеджмент

.

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

«Инцидент Менеджмент» — система мониторинга, разработанная компанией «Медиалогия». Её основная цель — быстрое реагирование на темы, которые поднимают пользователи соцсетей. Система выявляет и собирает значимые сообщения: негативные оценки, жалобы, вопросы, отзывы, благодарности. Программа в основном мониторит пять популярных в России площадок: «ВКонтакте», Instagram, Facebook, Twitter и «Одноклассники».

Система «Инцидент менеджмент»: как сообщить о своей проблеме

Как работает система «Инцидент Менеджмент»

Система анализирует ключевые слова в пяти соцсетях. Результаты отправляются региональному администратору. Он решает, какие проблемы наиболее острые и требуют реакции представителя власти.

Если по одной теме появляются посты в нескольких соцсетях, то их объединяют в один кейс или «инцидент».

А вот кому его передадут (местным депутатам или министрам), определяет масштаб проблемы. Публично ответить на запрос нужно в течение суток. Проигнорировать проблему местным депутатам или министрам не удастся, поскольку у сотрудников Администрации Президента РФ тоже есть доступ к системе.

Эксперты отмечают, что система не фиксирует негатив вообще, а фокусируется на конкретных вещах. Поэтому её нельзя отнести к политическим системам мониторинга. Она больше административная: отмечает «конкретные претензии конкретного гражданина к конкретной проблеме». «Инцидент Менеджмент» — проект многообещающий. В итоге система должна создать условия для прямой коммуникации местной власти и общества, повысить уровень контроля над чиновниками, сделать управление в регионах более эффективным.

Источник — Проект SFERA Live

Как сообщить о своей проблеме

Сейчас мониторинг ведется в Instagram, Вконтакте, Одноклассники, Facebook и Twitter. Запросы в зависимости от тематики распределяются по районам и региональным министерствам.

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

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

Если вы хотите, чтобы ваше обращение гарантированно попало в систему «Инцидент менеджмент», необходимо указать конкретный адрес, свои контакты и четко обозначить проблему.

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

Инцидент-менеджмент для самых маленьких: как мы учили поддержку и разработку работать сообща

Привет, хабр! Меня зовут Полина. Я несколько лет занималась настройкой и развитием инцидент-менеджмента для eLama.

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

В этой статье я размышляю над некоторыми вопросами, которые занимали меня саму на разных этапах работы над процессом. Например, могло ли введение регламента [работы с инцидентами] быть менее болезненным для всех сторон? О чем можно было позаботиться раньше? Возможно, кому-то будут полезны выводы, к которым я пришла.

Приоритет – всему голова

На мой взгляд, приоритет – одна из самых важных категорий в контексте работы с инцидентами. Пожалуй, даже самая важная.

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

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

О критериях

Критерии определения приоритета проблемы в каком-то смысле первичнее списка возможных приоритетов. На начальном этапе работать можно даже с двумя приоритетами. Например, критичным и нормальным. Гораздо важнее прописать, как определить, к какому из них отнести конкретный инцидент.

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

У вас B2C-сервис, которым пользуется множество небольших клиентов. В этом случае показательным может быть количество заафекченных пользователей.

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

С течением времени и список приоритетов, и их критерии могут меняться. Например, в первой итерации процесса у нас было 5 приоритетов – highest, high, medium, low и lowest. Последний отпал в ходе эволюции, потому что для него не нашлось применения на практике.

Приоритет конкретной проблемы тоже изменчив. Он может стать выше или ниже по мере наблюдения за количеством ошибок, обращений от пользователей, потенциальным риском и так далее. 

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

Второй важный плюс такого подхода – мы перестали отвлекать своих разработчиков на каждую мелочь. Если проблема не критичная, значит, ее обсуждение можно отложить до ближайшей планерки, PBR или передать на проработку продакт-менеджеру. 

О синхронности

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

До введения таблицы приоритетов в моей практике был кейс, когда реакция на крайне серьезную проблему со стороны программистов была долгой. Это случилось потому, что изначально разработка не поняла, насколько критична ситуация. Поддержка в то же время была уверена, что всё под контролем и из-за загруженности входящими обращениями не запрашивала апдейта по текущему статусу. Если работать в рамках понятных для всех сторон приоритетов, такого недопонимания не возникнет.

Я думаю, что попробовать работу по четко прописанным приоритетам можно и нужно, даже если вы еще не работаете с багтрекинговыми системами и даже не регистрируете инциденты. Да, у вас не будет наглядной иконки на тикете, но настройка бизнес-процессов — это, в первую очередь, про мышление и коммуникацию. Инструментальные решения на этом этапе могут быть самыми разнообразными в зависимости от ваших вводных.

Программистский для начинающих

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

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

Изначально вся коммуникация между саппортом и разработкой велась через чат. Как я уже упоминала выше, за передачу информации о проблемах, отрепорченных пользователями, отвечал один конкретный сотрудник поддержки. Его основная суперсила была в том, что он мог сформулировать проблему на понятном для разработчиков языке и перевести менеджерам обратную связь от команды. А еще, в допандемийные времена, добежать до отдела разработки, если на проде возникла серьезная проблема, чтобы обсудить детали голосом. 

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

О поиске общего языка

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

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

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

Анализируя свой опыт, я поняла, что изначально, до внедрения процесса, подходила к этому не совсем правильно. Когда ко мне обращались с проблемой, я предлагала объяснить «как умеешь», а еще лучше просто показать проблему в интерфейсе и после уже сама переводила информацию в нужный формат для разработчиков. Это рабочий, но недальновидный способ решения проблемы. 

Позже мы перешли к формату, где поддержка составляла тикет, а я его корректировала и давала автору обратную связь. Благодаря этому, ребята постепенно освоилили азы языка разработчиков и начали не только лучше формулировать проблемы, но и сами понимать программистов.

Безусловно, это не избавило нас от bus-фактора. Процесс работы с инцидентами по-прежнему координируется и, если честно, я не могу с уверенность сказать, может ли быть иначе. Но процент времени, которое затрачивает инцидент-менеджер непосредственно на переписывание тикетов, значительно сократился.

Опять же – здорово, если у вас уже есть инструменты для упрощения и автоматизации процесса. Например, мы, пользуясь возможностями багтрекинговой системы, кастомизировали форму создания инцидента и для наглядности добавили разные типы тикетов в зависимости от содержания проблемы. Однако это произошло далеко не в первую итерацию процесса. Даже сообщения в чат с разработкой можно и нужно составлять по уму.

Тестировщик в беде не бросит

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

О скрытых ресурсах

В самом начале предполагалось, что проблема bus-фактора будет решена назначением второго инцидент-менеджера. Позже стало понятно, что в нашем случае два человека на этой роли – решение не совсем целесообразное.

В какой-то момент ребята из команды тестирования сами предложили свою помощь. И это было хорошей идеей по многим причинам.

Во-первых, работа с инцидентами тесно связана с отлавливанием некорректного поведения систем, локализацией проблем и написанием багрепортов. Никто не знает об этом больше, чем QA-специалисты.

Во-вторых, находясь на периферии обращений о некорректной работе продукта, тестировщики могут быстрее узнавать об ошибках на бою.

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

О форматах взаимодействия

Традиционно в нашей команде тестировщиков есть специалист, который полностью берет на себя координацию процесса на случай отсутствия инцидент-менеджера. Этот тестировщик обладает не только специальными знаниями, но и глубоко погружен в сам процесс. Кроме этого, на обычной неделе выделяется день, когда он дежурит в роли инцидент-менеджера, что позволяет оставаться в контексте и высвобождает для основного координатора процесса немного времени на работу по другим задачам.

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

Безусловно, работа с инцидентами не является основным фокусом команды QA, да и не всем подошел такой формат. Но даже то участие, которое по мере своих возможностей принимают в процессе заинтересованные тестировщики, в нашем случае обеспечивает достаточную поддержку процесса и ослабляет bus-фактор.

С чего начинается инцидент-менеджмент

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

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

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

Во-первых, занесение проблемы в табличку означало, что оно не потеряется, в отличие от личного сообщения.

Во-вторых, у таблицы была шапка и названия столбцов подсказывали заполняющему, какие данные нужны, чтобы репорт можно было взять в работу для первичной диагностики. Именно тогда у проблем впервые появился такой атрибут, как приоритет.

При этом, на тот момент мы воспользовались теми ресурсами, которые уже были в команде, то есть не потратили никаких дополнительных средств.

Спустя достаточно продолжительное время данные, которые сохранились в табличке, понадобились нескольким отделам. Мы не предполагали, что такая необходимость появится, но оказались к ней готовы.

Признаюсь честно, что это произошло непреднамеренно, но та табличка, в том числе, подготовила почву для перехода на автоматизированный процесс работы с инцидентами через багтрекинговую систему. Менеджеры на личном опыте узнали, насколько удобно видеть в одном месте все отрепорченные инциденты и как упрощает жизнь наличие полей-подсказок. Поэтому когда я пришла к ребятам из саппорта с очередными, более радикальными нововведениями, у меня уже был некоторый кредит доверия.

Заключение

Вот, пожалуй, и все.

Ретроспективно оценивая свой опыт работы над incident management process, я сформулировала для себя, на каких трех слонах и черепахе он базируется. Для меня это:

• приоритизация проблем; 

• общий язык для обмена информацией между командами; 

• люди, готовые поддерживать процесс;

• регистрация инцидентов в любом виде.

Позже мы с командой проделали много работы в других направлениях. Это и автоматизация операций, и категоризация проблем, и составление различных отчетов для разработки и бизнеса и многое другое. Но всё это – сюжеты для совсем других статей. 

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

Ну и последнее, о чем я хочу сказать. Мне кажется важным не относиться к регламенту как к чему-то железобетонному. Регламент – это инструмент, который должен работать во благо компании, а не существовать где-то в параллельной вселенной. Если в процессе появились узкие места или какие-то договоренности стали приносить больше вреда, чем пользы, нужно это подсвечивать и пытаться найти решение. 

Для поддержания актуальности регламента мы применяем итеративный подход. Вводим небольшие изменения и оцениваем их эффективность. И только после этого принимаем решение о дальнейших шагах.

Спасибо за внимание!

01.06.2021 19:34

САМАРА. 1 ИЮНЯ. ВОЛГА НЬЮС.

Читали: 5575

Если вы нашли ошибку в тексте — выделите ее и нажмите CTR+Enter

«Инцидент Менеджмент» — это система мониторинга социальных сетей и один из главных инструментов работы Центра управления регионом Самарской области. Система позволяет находить и обрабатывать сообщения, жалобы и предложения от жителей региона, которые они оставляют в открытых источниках в сети Интернет.

Многие проблемы, возникающие у жителей городов и сел, требуют решения на уровне власти. И решать их в наши дни надо оперативно.

Сделать это можно несколькими способами, один из которых — это система «Инцидент менеджмент», которая и проследит за тем, чтобы проблема была решена местными властями.

Система «Инцидент Менеджмент»: как подать жалобу в органы власти 

  Вариант первый — «Инцидент Менеджмент» в социальных сетях

«Инцидент Менеджмент» — система мониторинга, разработанная компанией «Медиалогия». Её основная цель — быстрое реагирование на темы, которые поднимают пользователи соцсетей. Система выявляет и собирает значимые сообщения: негативные оценки, жалобы, вопросы, отзывы, благодарности. Программа в основном мониторит пять популярных в России площадок: «ВКонтакте», Instagram, Facebook, Twitter и «Одноклассники».

Инструкция, как подать жалобу через соц.сети, ждет вас ЗДЕСЬ.

  Вариант второй — «Инцидент Менеджмент»  через голосовой помощник от «Яндекса» 

Навык для голосового помощника «Алиса» разработала АНО «Диалог». Голосовые сообщения о различных проблемах поступают в систему «Инцидент Менеджмент».

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

Ответ придет на почту пользователя, которая привязана к Yandex ID.

Запустить навык можно везде, куда интегрирована «Алиса». Например, в веб-браузере, приложениях «Яндекс.Карты», «Яндекс.Навигатор», а также в «Яндекс.Станции». Сейчас навык работает во всех регионах России, кроме Москвы.

Сообщение через систему «Инцидент менеджмент» не является формой официального общения с органами государственной власти. Также у голосового помощника есть фильтр, поэтому неконструктивные сообщения не примут к рассмотрению. Вопросы должны касаться полномочий органов власти и местного самоуправления. По данным ЦУР, на Кубани в топ-5 тем, поступающих в систему «Инцидент Менеджмент», вошли вопросы о дорогах, ЖКХ, благоустройстве, коронавирусе и здравоохранении.

Источник — Кубань24

Инцидент — это событие, которое может привести к потере или нарушению операций, услуг или функций организации. Управление инцидентами (IcM ) — это термин, описывающий деятельность организации по выявлению, анализу и устранению опасностей для предотвращения их повторения в будущем. Эти инциденты в рамках структурированной организации обычно обрабатываются либо группой реагирования на инциденты (IRT), группой управления инцидентами (IMT), либо системой управления инцидентами (ICS). Без эффективного управления инцидентами инцидент может нарушить бизнес-операции, информационную безопасность, ИТ-системы, сотрудников, клиентов или другие жизненно важные бизнес-функции.

Содержание

• 1 Описание
  • 1.1 Управление физическими инцидентами
  • 1.2 Компьютерная безопасность управление инцидентами
• 2 Роли
• 3 Программные системы управления инцидентами
• 4 Анализ первопричин
  • 4.1 Человеческий фактор
• 5 См. также
• 6 Ссылки
• 7 Внешние ссылки
• 8 Дополнительно чтение

Описание

Инцидент — это событие, которое может привести к потере или нарушению работы, услуг или функций организации. Управление инцидентами (IcM) — это термин, описывающий деятельность организации по выявлению, анализу и устранению опасностей для предотвращения их повторения в будущем. Если не принять меры, инцидент может перерасти в чрезвычайную ситуацию, кризис или катастрофу. Таким образом, управление инцидентами — это процесс ограничения потенциальных сбоев, вызванных таким событием, с последующим возобновлением работы в обычном режиме. Без эффективного управления инцидентами инцидент может нарушить бизнес-операции, информационную безопасность, ИТ-системы, сотрудников, клиентов или другие жизненно важные бизнес-функции.

Управление физическими инцидентами

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

Планирование реагирования на инцидент — будь то стихийное бедствие, чрезвычайная ситуация, кризис или авария — было выполнено таким образом, чтобы обеспечить эффективную устойчивость бизнеса для обеспечения минимальных потерь или ущерба, будь то к материальным или нематериальным активам этой организации. Эффективное физическое управление инцидентом — оптимальное использование времени и ресурсов и понимание того, как получить больше ресурсов извне, когда это необходимо, посредством четкой и своевременной связи — обеспечивают выполнение плана.

Национальная ассоциация противопожарной защиты заявляет, что управление инцидентами можно описать следующим образом: «[a] n IMS [система управления инцидентами] — это« комбинация помещений, оборудования, персонала, процедур и коммуникаций, действующих в рамках общей организационной структуры., предназначенный для помощи в управлении ресурсами во время инцидентов ».

Физическое управление инцидентами — это реагирование в реальном времени, которое может длиться часами, днями или дольше. Кабинет министров Соединенного Королевства подготовил Национальное руководство по восстановлению (NRG), которое нацелено на местных служб реагирования в рамках реализации Закона о гражданских непредвиденных обстоятельствах 2004 года (CCA). В нем описывается следующее реагирование: «Реагирование включает действия, предпринимаемые для устранения непосредственных последствий чрезвычайной ситуации. Во многих сценариях оно, вероятно, будет относительно коротким и продолжится в течение нескольких часов или дней — быстрое выполнение мероприятий. поэтому сотрудничество, координация и коммуникация имеют жизненно важное значение. Реагирование включает в себя усилия по устранению не только прямых последствий самой аварийной ситуации (например, тушение пожаров, спасение людей), но и косвенных последствий (например, разрушение, интерес СМИ)

Международная организация по стандартизации (ISO), которая является крупнейшим в мире разработчиком международных стандартов, также делает акцент в описании своего документа по управлению рисками, принципам и инструкциям ISO 31000 : 2009 г., что «Использование ISO 31000 может помочь организациям повысить вероятность достижения целей, улучшить идентификацию возможностей и угроз, а также эффективно распределять и использовать ресурсы для управления рисками. атмент «. Это еще раз показывает важность не только хорошего планирования, но и эффективного распределения ресурсов для снижения риска.

Управление инцидентами компьютерной безопасности

Сегодня важную роль играет группа реагирования на инциденты компьютерной безопасности (CSIRT) в связи с ростом преступности в Интернете, и это типичный пример инцидентов, с которыми сталкиваются компаниями в развитых странах по всему миру. Например, если организация обнаруживает, что злоумышленник получил несанкционированный доступ к компьютерной системе, CSIRT проанализирует ситуацию, определит масштаб взлома и предпримет корректирующие действия. Компьютерная экспертиза — одна из задач, включенных в этот процесс. В настоящее время более половины мировых попыток взлома транснациональных корпораций (ТНК) приходится на Северную Америку (57%). 23% попыток происходит в Европе. Наличие хорошо организованной группы реагирования на инциденты компьютерной безопасности является неотъемлемой частью обеспечения безопасной среды для любой организации и становится важной частью общей структуры многих современных сетевых групп.

Роли

Инциденты внутри структурированной организации обычно рассматриваются либо группой реагирования на инциденты (IRT), либо группой управления инцидентами ( IMT). Они часто назначаются заранее или во время мероприятия и передаются под контроль организации, пока инцидент обрабатывается, чтобы восстановить нормальные функции.

Система управления инцидентами (ICS) предназначена для решения более крупных инцидентов, требующих ответа от нескольких агентств. Популярный среди агентств общественной безопасности и юрисдикций в США, Канаде и других странах, он набирает обороты на практике в частном секторе, поскольку организации начинают управлять чрезвычайными ситуациями самостоятельно или совместно с агентствами общественной безопасности. ICS — это механизм управления и контроля, который обеспечивает расширяемую структуру для управления агентствами по чрезвычайным ситуациям. Хотя некоторые детали различаются в зависимости от юрисдикции, ICS обычно состоит из пяти основных элементов: командование, операции, планирование, логистика и финансы / администрирование. Несколько специальных штабных должностей, в том числе по связям с общественностью, безопасности и связи, подчиняются непосредственно командиру инцидента (ИК), когда чрезвычайная ситуация требует создания этих должностей.

Еще одна система реагирования — это командная структура «золото – серебро – бронза», которая используется службами экстренной помощи в Великобритании и других странах. Система имеет три уровня командования: золотой командир устанавливает общую стратегию, серебряный командир непосредственно отвечает за тех, кто находится на месте происшествия, а бронзовые командиры отвечают непосредственно на земле. Отдельное агентство может использовать систему, или несколько агентств могут использовать систему, поскольку они взаимодействуют. Общей чертой систем ICS и Gold-Silver-Bronze является то, что они создают отдельную командную систему для обычной иерархии агентств.

Обычно в рамках более широкого процесса управления в частных организациях управление инцидентами сопровождается анализом после инцидента, когда определяется, почему инцидент произошел, несмотря на меры предосторожности и меры контроля. Этот анализ обычно контролируется руководителями организации с целью предотвращения повторения инцидента с помощью мер предосторожности и часто изменений в политике. Эта информация затем используется в качестве обратной связи для дальнейшей разработки политики безопасности и / или ее практической реализации. В США Национальная система управления инцидентами, разработанная Министерством внутренней безопасности, объединяет эффективные методы управления чрезвычайными ситуациями во всеобъемлющую национальную структуру. Это часто приводит к более высокому уровню планирования действий в чрезвычайных ситуациях, тренировок и обучения, а также к оценке управления инцидентом.

Программные системы управления инцидентами

Программные системы управления инцидентами предназначены для сбор согласованных, чувствительных ко времени, задокументированных данных отчетов об инцидентах. Многие из этих продуктов включают функции для автоматизации процесса утверждения отчета об инциденте или расследования дела. Эти продукты также могут иметь возможность собирать информацию об инцидентах в реальном времени, такую ​​как данные о времени и дате. Кроме того, системы отчетов об инцидентах будут автоматически отправлять уведомления, назначать задачи и эскалации соответствующим лицам в зависимости от типа инцидента, приоритета, времени, статуса и настраиваемых критериев. Современные продукты предоставляют администраторам возможность настраивать формы отчетов об инцидентах по мере необходимости, создавать отчеты об анализе и устанавливать элементы управления доступом к данным. Эти отчеты об инцидентах могут иметь возможность настройки, которая может наилучшим образом подойти организациям, использующим системы. Некоторые из этих продуктов могут собирать изображения, видео, аудио и другие данные. Существуют программные системы управления инцидентами, которые относятся непосредственно к конкретным отраслям.

Анализ первопричин

Человеческий фактор

В ходе анализа первопричин необходимо оценить человеческий фактор. Джеймс Ризон провел исследование по изучению неблагоприятного воздействия человеческого фактора. Исследование показало, что расследования крупных инцидентов, такие как Piper Alpha и Kings Cross Underground Fire, показали, что причины аварий были широко распространены внутри и за пределами организации. Есть два типа событий: активный отказ — действие, которое имеет немедленные последствия и может вызвать аварию — и скрытое или отсроченное действие — события могут занять годы, чтобы получить эффект и обычно сочетаются с инициирующими событиями, которые затем вызывают авария.

Активные сбои — это небезопасные действия (ошибки и нарушения), совершаемые, например, операторами оборудования и руководителями задач. Действия людей, находящихся на интерфейсе человек-система, могут иметь немедленные неблагоприятные последствия.

Скрытые сбои возникают в результате решений, принимаемых в высших эшелонах организации. Их разрушительные последствия могут оставаться бездействующими в течение длительного времени и становятся очевидными только в сочетании с местными пусковыми факторами (например, весенний прилив, трудности с погрузкой в ​​гавани Зебрюгге и т. Д.) взломать защиту системы. Решения, принятые в высших эшелонах организации, могут привести к тому, что события станут более вероятными, а планирование, составление графиков, прогнозирование, проектирование, выработка политики и т. Д. Могут иметь медленный эффект горения. Фактическое небезопасное действие, которое вызывает аварию, можно проследить в организации, а последующие сбои могут быть выявлены, показывая накопление скрытых сбоев в системе в целом, что привело к тому, что авария стала более вероятной и в конечном итоге произошла. Можно применить более эффективные меры по улучшению и снизить вероятность повторения события.

См. Также

• Национальная система управления инцидентами в США
• Скоординированное региональное управление инцидентами ( Нидерланды) в Нидерландах

Ссылки

Внешние ссылки

• Консорциум национальной системы управления инцидентами в Соединенных Штатах
• Законодательство правительства Соединенного Королевства, Закон о гражданских непредвиденных обстоятельствах ( CCA) 2004. (2012)
• Федеральное агентство по чрезвычайным ситуациям (FEMA). (2012)

Дополнительная литература

• Адам Круг (2014-09 / 16), «Примеры использования программного обеспечения для управления инцидентами », Примеры 1 — 34
• Wearne SH Уайт-Хант, К. (2010), Управление срочными и неожиданными ситуациями, Gower Publishing — Примеры