Приветствую! Меня зовут Максим Торнов. Я более 15 лет занимаюсь развитием управления корпоративными рисками и операционной эффективности компаний.
Данная статья является продолжением цикла моих статей об управлении рисками, контролем и эффективностью в процессах бизнеса, в первую очередь ИТ и ИБ. Однако данная статья будет больше посвящена управлению инцидентами и проблемами бизнес-процессов, в бизнес-функциях компании.
Написать данную статью меня сподвигло наблюдение за тем как происходит использование, а главное управление информацией об инцидентах и проблемах в процессах компаний, процессах отличных от ИТ и ИБ.
Данная статья будет интересна собственникам своего бизнеса, управленцам, людям кто развивает бизнес, и всем причастным, кто ищет пути для максимизации его эффективности и как следствие конкурентности и силы бренда своей компании.
В данной статье я бы хотел высказать свое мнение и узнать ваше по этому поводу.
Проблема
За годы работы в аудите и управлении рисками, снаружи и внутри, я часто наблюдал ситуацию, когда управление инцидентами и проблемами, почему-то считается, что должно происходить только в ИТ, ну максимум плюс ИБ.
Однако, практически в подавляющем большинстве компаний, никто сильно не думал на тему того, а как происходит управление инцидентами и проблемами, например в процессах Бухгалтерского учета и финансов (Finance & Accounting), Управления персоналом (HR), Казначействе (Treasury) и других направления деятельности компании, например таких как Продажи (Sales), Маркетинг и Связи с общественностью (Marketing & PR), Управление поставками и закупками (Supply chain).
Как в данных процессах происходит выявление, фиксация, анализ, приоритизация и дальнейшее СИСТЕМНОЕ и РЕГУЛЯРНОЕ управление возникающими инцидентами и возможно существующими или будущими проблемами?
В моей практике, часто - НИКАК...
Звучит странно и вызывает несогласие? Но это так, в моей практике я наблюдал единичные случаи компаний, в которых процессам управления инцидентами и проблемами в не ИТ-бизнес-процессах уделялось достаточное внимание. Еще меньше случаев, когда можно было бы сказать, что процесс управления инцидентами и проблемами носил системный характер и в достаточной мере можно было сказать, что процесс был эффективен. К сожалению.
Даже в ИТ, часто сбор информации об инцидентах, проблемах, а главное последующий анализ и использование такой информации в управленческих решениях завершались там же где и возникали - в ИТ, максиммум к этому процессу еще присоединялся процесс управления безопасностью, в различных его направлениях и проявлениях. Однако регулярный анализ инцидентов, статистики проводился еще реже... Даже в ИТ и ИБ. Как следствие процесс вроде как есть, но вроде как его и нет.
Резонно возникает вопрос: Так раз нет процесса и управления, так может и не надо? На тему эффективного управления бизнесом, отдельными процессами бизнеса, написана масса литературы. Разбор такой литературы выходит за рамки данной статьи.
Ни у кого не вызывает сомнения, что компания, процесс, отдел, команды, эксперт - это все объекты управления. Также, ни у кого не вызывает сомнений, что и автомобиль это обект управления, таким образом, чтобы пойти дальше, ответьте себе на вопросы ниже, например - если у вас есть автомобиль и вы им управляете, нужно ли вам знать:
Нужно ли и если да, то когда менять масло?
Все ли колеса накачены до нужного давления?
Все ли параметры автомобиля в норме?
И т.д.
Так вот, в современном автомобиле есть масса механизмов по сбору, хранению, анализу и презентации сервисной информации водителю. С тем, чтобы водитель своевременно принял правильное, основанное на достовернной информации решение. Если водитель хочет иметь возможность доехать туда куда он хочет и когда он хочет. Так и с другими объектами управления - вы хотите знать, что с ними происходит, чтобы принять максимально эффективное решение. Или если масла в двигателе мало, колесо спущено - что-то может произойти? Водитель наверное должен быть предупрежден?
Для этого, в контексте управления - информация должна быть полной, точной, своевременной.
Например, многие считают, что финансовая отчетность позволяет узнать положение дел в компании. Возможно, для принятия инвестиционного решения этого для кого-то будет достаточно, но для оперативного управления компанией, знать о происходящем в процессах компании один раз в год? Этого достаточно? Вы серьезно?
Или управление рисками, т.е. прогнозирование потенциальных инцидентов и проблем, через огромные, корявые, часто неактуальные, актуализируемые один раз в год Excel таблицы - реально поможет системно управлять и избегать инцидентов и проблем? Один раз в год? Сомнительно.
По моему мнению, в подобных случаях, вы просто узнаете об инциденте постфактум, уже без возможности оперативно понять корневую причину, проблему, приведшую к инициденту и без возможности как-то эффективно минимизировать потери.
Или, как вариант, управленческая отчетность, ежемесячная, квартальная? А часто в такой отчетности в вашей практике была информация об инцидентах/проблемах в бизнес-процессах, бизнес-функциях компании, за пределами финансов? А даже если была - это с большой долей вероятности были единичные случаи.
Или, например я неоднократкно видел боль и страдание ИТ или ИБ управленцев пытавшихся получить штатные единицы или бюджет на что-либо. Это бесконечная, болезненная игра в поиск правильных формулировок и цифр, с принципом "проси больше", чтобы хоть что-то получить....
Я наблюдал картины, в разных, но приблизительно одинаковых проявлениях, например, когда руководитель HR принимал решение о том, что ну не нужны люди руководителю ИТ, просто потому-что он так решает... и не важно, что руководитель ИТ - это нанятый эксперт ультра-класса в ИТ, знающий что ему и куда нужно, однако убедительно обосновать не мог.
Такие примеры, с тем, что "чутье" говорит нужны ресурсы, но вы не можете нормально обосновать, или когда вы видете что что-то идет не так, но вы не понимаете причин - частые явления.
Однако, выход есть. Если посмотреть на базовые основы управления инцидентами и проблемами в ИТ, можно увидеть, что нечто подобное есть и для других бизнес-процессов.
Теория
Что мы знаем об управлении инцидентами и проблемами в ИТ? Первое, что приходит в голову, это ITIL.
Управление инцидентами и проблемами в ИТ основано в первую очередь на лучших практиках, да, "лучших индустриальных практиках и опыте экспертов" описанных в библиотеке ITIL (Information Technology Infrastructure Library), которая является де-факто мировым стандартом.
Есть и другие варианты, по системному управлению инцидентами и проблемами в ИТ:
ISO/IEC 20000 (Международный стандарт для управления ИТ-услугами). Сертификационный стандарт. Определяет требования к системе управления ИТ-услугами (SMS). Если ITIL — это библ��отека лучших практик "как делать", то ISO 20000 — это список требований "что должно быть", чтобы получить сертификат.
COBIT (Control Objectives for Information and Related Technologies). Управление ИТ с точки зрения эффективности управлления рисками и общекорпоративного контроля. Задает требования к тому, что должно быть реализовано в ИТ и ИБ.
MOF (Microsoft Operations Framework). Это руководство, относится к лучшим практикам, подобное ITIL, описывающее требования и подход к управлению всеми этапами жизненного цикла ИТ-услуг.
VeriSM: Более современная и гибкая модель, ориентированная на предоставление и управление услугами и сервисом в эпоху цифровой трансформации, DevOps и гибких методологий.
Определения
Однако, как это применимо к управлению инцидентами и проблемами в отличных от ИТ/ИБ бизнес-процессах?
Для того, чтобы двинуться дальше, давайте определимся, а что такое "инцидент" и что такое "проблема"?
Что такое инцидент? - Незапланированное прерывание услуги, сервиса или снижение их качества.
Что такое проблема? - Одна или несколько причин фактических или потенциальных инцидентов. Проблема может существовать и без активных инцидентов (например, обнаруженна уязвимость).
Например, в ITIL проблема — это первопричина или потенциальная причина одного или нескольких инцидентов (сбоев в работе услуг, сервисов). В отличие от управления инцидентами (которые являются проявлением симптомов, требующими быстрого устранения), управление проблемами сосредоточено на первопричинах, с целью предотвращения их повторного возникновения.
Очень часто, инциденты это проявления повторяющихся проблем. Игнорирование, замалчивание мнений, сокртытие или искажение информации, игры с информацией и отчетностью, интуитивные управленческие решения, некомпетентность, отсутствие эффективного мониторинга и анализа - это разного рода и значимости проблемы. Проблемы, ведущие к деградации сервисов и услуг или в какой-то момент - полной невозможности их предоставить.
Управление проблемами - это системный и регулярный поиск и устранение корневых причин. Это об эффективности процессов и сервисов компании и как следствие - бизнеса в целом. Это, если хотите - его весьма ценное, конкурентное преимущество, при наличии эффективного процесса управления инцидентами и проблемами во всех процессах компании.
Давайте исслледуем еще немного теории и определений в ИТ. ИТ как сервиса, как услуги для других процессов бизнеса.
Управление инцидентами (Incident Management):
Цель: Максимально быстро восстановить нормальное предоставление услуги или сервиса, минимизировать негативное влияние на бизнес компании.
Ключевые моменты управления инцидентами:
Регистрация и классификация информации об инциденте: Все проблемы и инциденты фиксируются в системе управления инцидентами и проблемами. Это может быть любая система, позволяющая накапливать информацию, формировать отчетность, документировать детали события, ответственных, приоритет и сроки.
Скорость. Часто используется "обходное решение" (Workaround), чтобы быстро вернуть услугу в работу, даже если первопричина не найдена на момент регистрации.
ВАЖНО: При регистрации события, обязательно присваивается его приоритет (обычно на основе влияния, последствий и как следствие - срочности, приоритета реакции). Приоритет позволяет определить из всего потока - что важно и срочно, а что можно отложить на будущее. Принтер печатает с полосами или "свет отключили"?
Управление проблемами (Problem Management):
Цель: Устранить корневые причины инцидентов и предотвратить их повторение.
ВАЖНО: В первую очередь это системый и регулярный процесс по сбору и обработке, последующего анализа и отчетности.
Ключевые моменты управления проблемами:
Идентификация проблем: Анализ трендов инцидентов, оповещений систем, отчетов поставщиков.
Контроль проблемы: Регистрация, установка приоритета (на основе риска для бизнеса).
Поиск ключевой причины (Root Cause Analysis - RCA):
Глубокий анализ с использованием различных методов анализа, например:
5 Why? (5 Почему?)
Диаграмма Ишикавы (Fishbone/Cause-and-Effect). Визуализация всех возможных причин по категориям, например - люди, процессы, оборудование и т.д.
Метод Кепнера-Трего (Структурированный подход к анализу отклонений).
Устранение причины: Разработка и внедрение постоянного исправления (Known Error) через процесс "Управление изменениями".
Закрытие проблемы и отчетность.
Главный фокус: Проактивность и стабильность. Т.е. цель процесса - устранить причину навсегда.
ВАЖНО: Управление инцидентами и проблемами очень тесно взаимосвязаны, например: Обходное решение, найденное при работе с инцидентом, передается в процесс управления проблемами. Постоянное исправление (Known Error), созданное в процессе управления проблемами, попадает в базу знаний для быстрого разрешения будущих инцидентов.
Что важно знать еще в процессе управления проблемами ИТ?
Обязательно определен тот, кто будет решать проблему. Сотрудник/отдел/функция, кто угодно, при этом - ответственный должен обладать необходимыми компетенциями и полномочиями для максимально эффективного решения. Таким образом должны быть определены, знакомые нам уровни поддержки (например, кто будет решать проблему на 1-й, 2-й, 3-й линии) и правила передачи задач по проблеме.
Реализован, принцип приоритизации: чаще всего это матрица, пересечение свойств события - "Влияние vs Срочность". Влияние — например, на сколько потребителей повлияло, Срочность — как быстро происходит деградация, ухудшение ситуации.
Например: Вы разработчик программного продукта, вы продали продукт, клиент пришел с проблемой, кто и как быстро будет решать проблему от внешнего контрагента? Долгое или неправильное решение проблем, может стать инцидентом - нарушение контрактных обязательств, потеря клиента.
Управление инцидентами и проблемами в ИБ
Раз уж мы коснулись ИТ, нельзя пройти мимо практик в ИБ. Очевидно, что хоть ИБ сложно отделимо от ИТ, управление инцидентами и проблемами в информационной безопасности (ИБ) имеет свою специфику, фокус и стандарты.
Здесь на первый план выходят не просто сбои сервисов, а нарушение классических конфиденциальности, целостности и доступности информации. В целом подходы похожи, но давайте разберем отличия.
Основные отличия от подхода к управлению инцидентами и проблемами в ИБ от ИТ:
Цели: Не восстановить сервис, а снизить ущерб, провести расследование, снизить риск, угрозу и восстановить безопасность.
Сильнее ориентация на риски бизнеса: В то время как ИТ ориентировано больше на операционную эффективность компании, ИБ имеет больший фокус на репутационные, регуляторные и правовые последствия для компании (152-ФЗ, ФСТЭК, GDPR и т.д.).
Международные и национальные стандарты (Как и что делать)
ISO/IEC 27035 (Information security incident management) - это международный стандарт, содержащий рекомендации по созданию комплексного процесса управления инцидентами информационной безопасности (ISIM), помогающий организациям эффективно управлять инцидентам безопасности, включая обнаружение, реагирование и восстановление, тем самым снижая последствия и предотвращая их повторение. Стандрат применим к организациям любого размера и типа, охватывает весь жизненный цикл инцидента ИБ, уделяя особое внимание готовности, структурированному реагированию, восстановлению и по��тоянному совершенствованию. Различные части стандарта посвящены принципам (Часть 1) и конкретным рекомендациям (Часть 2) по управлению уязвимостями и реагированию на киберугрозы.
NIST SP 800-61 (Computer Security Incident Handling Guide) — это руководство по эффективной обработке и постоянному совершенствованию процесса управления инцидентами в области ИБ, предлагает четырехэтапный жизненный цикл (1. подготовка, 2. обнаружение и анализ, 3. локализация/устранение/восстановление, 4. действия после инцидента).
Регуляторные требования (GDPR, 152-ФЗ, PCI DSS) - включают требования к управлению инцидентами в области защиты данных
Ключевое в области управления инцидентами кибербезопасности:
Управление инцидентами — подготовка, обнаружение, приоритизация, сдерживание, ликвидация, восстановление, анализ уроков и отчетность (Post-Mortem разбор)
Управление проблемами — это управление уязвимостями, включая патчменеджмент
Чтобы пойти дальше, уже к основной теме данной статьи, давайте резюмируем основное:
Аспект | ИТ-инциденты | ИБ-инциденты |
Главная цель | Восстановить работу сервиса. | Минимизировать ущерб, защитить активы, восстановить безопасность. |
Приоритет | Скорость восстановления. | Правильная последовательность: анализ -> сдерживание -> ликвидация -> восстановление. |
Анализ причины | Root Cause Analysis для предотвращения сбоев. | Расследование (Forensics) для атрибуции, сбора улик, понимания тактики злоумышленника. |
Участие | ИТ-персонал, пользователи. | ИТ + ИБ + юристы + PR + руководство + регуляторы. |
"Проблема" | Корневая причина сбоя. | Уязвимость или недостаток контроля. Управляется через процесс управления уязвимостями. |
Метрики | Mean Time To Repair (MTTR), First Call Resolution or First Contact Resolution (FCR), Down-time. | Mean Time to Detect (MTTD), время до сдерживания, количество скомпрометированных записей/систем, финансовые потери. |
Драйверы | SLA, доступность сервисов. | Соответствие законам, снижение иных присущих рисков. |
Управление инцидентами и проблемами в бизнес-функциях компании
Ну вот мы и подошли к основной теме данной статьи и переходим от ИТ и ИБ, к управлению инцидентами и проблемами бизнес-функций и процессов, управлению функциями и процессами отличными от ИТ и ИБ.
Здесь подход кардинально меняется: фокус смещается с восстановления сервиса и предотвращения кибер-угроз на минимизацию операционных, финансовых, репутационных, регуляторных и иных рисков присущих бизнесу компании.
Ключевой парадигмой становится Устойчивость бизнеса (Business Resilience), Управление бизнес-процессами (Business Process Management) и Эффективность бизнес-процессов (Business Process Efficiency).
Я не сталкивался с каким-то отделльным стандартом, который бы как-то рекомендовал построение процесса управление инцидентами, проблемами в бизнес-функциях организаций. Первое что приходит в голову, это проактивное управление рисками. Т.е. управление инцидентами, проблемами и рисками не один раз в год, а ежедневно, подобно тому как работают ИТ и ИБ.
Общий концептуальный подход
Считается, что управление инцидентами и проблемами в бизнес-процессах — это часть системы управления операционным риском или Operational Risk Management (ORM). Однако, в рамках различных бизнес-процессов, индустрий и риски разные, и я считаю, что термин управление рисками организации или Enterprise Risk Management (ERM) в данном случае гораздо точнее отражает процесс управления рисками всей компании, всех ее процессов.
Однако тема статьи не об управлении рисками. Тему управления рисками оставим за рамками данной статьи. Давайте лишь договоримся, что одна из основных целей управления инцидентами, пробемами и рисками организации это — обеспечить непрерывность и качество выполнения ключевых бизнес-функций. Говоря другими словами, каждая организация хочет максиммизировать эффективность каждого процесса, снизив издержки и как следствие увеличить прибыльность и конкуретность, привлекательность бренда и компании.
Давайте разберем на примерах озвученных ранее функций компании.
А как происходит управление инцидентами и проблемами например в в процессах Бухгалтерского учета и финансов (Finance & Accounting), Управления персоналом (HR), Казначействе (Treasury) и других направления деятельности компании, например таких как Продажи (Sales), Маркетинг и Связи с общественностью (Marketing & PR), Управление поставками и закупками (Supply chain)?
Бухгалтерский учет и финансы (Finance & Accounting)
Часто вы видели, чтобы бухгалтерия вела учет ошибок в своей работе? Не думаю... весьма болезненная тема и вызывает сразу негативную или защитную реакицю у любого бухгалтера/главного бухгалтера. Но, как главный бухгатер, генеральный директор узнают об инцидентах и проблемах бухгалтерии, видят тренды, прогнозируют проблемы? Очень часто - интуитивно и постфактум.
Тем не менее, часто можно услышать - был выбран не тот метод рассчета, регулярные ошибки в рассчетах и/или проводках, некорретно выбран режим налогообложения в рассчетах, проводки скорректированы задним числом и т.д. Все это проблемы и потенциально инциденты.
Что считается инцидентом, а что проблемой?
На мой взгляд проблема - это систематические ошибки/сбои/неточности в процессе, на корректировку и устранение которых уходят ресурсы данной функции. Инцидент, это когда проблема в результате вышла за периметр функции, бизнес-процесса, т.е. например проблема привела к потерям для компании и не ��ажно каким, и в каком объеме в данном случае.
Например:
Ошибка в проводке или отчете (особенно существенная).
Просрочка сдачи отчетности в регуляторы (налоговая, ЦБ, Минфин).
Обнаружение мошенничества или хищения.
Сбой в работе финансового ПО (например, 1С при закрытии периода).
Расхождение данных между системами (например, CRM и бухгалтерия).
Часть примеров выглядят как ИТ инциденты, но так ли это? Не думаю. Корневая причина может крыться в самой бухгатерии, в методах ее управления. Не зная корневых причин, проблемы и инциденты будут повторяться и отнимать у компании ресурсы.
Как управляют? На основе чего?
Инцидентами и проблемами можно управлять, даже если это бухгалтерия. Управление подразумевает хранение и анализ, приоритизацию и т.д. всех негативных событий и последствий. Где и как - выбирает компания. Есть такой процесс - отлично! Нет - ну вспомните игру в "Сапера" на Wndows.
Косвенно, управлять можно через соблюдение стандартов и регламентов: внутренние учетные политики (ПБУ/МСФО), регламенты закрытия месяца/квартала/года, инструкции ЦБ, налогового кодекса.
Процесс управления, по аналгии с ИТ и ИБ:
Обнаружение: Часто через контрольные точки (checkpoints) в процессе закрытия периода, различные аудиты (внутренний/внешний), сверки.
Сдерживание и реагирование: Немедленная блокировка ошибочных операций, исправление проводок (сторно и правильная проводка), экстренный созыв рабочей группы.
Анализ проблем (RCA): Ищут системную причину — недостаток контроля, отсутствие контрольных точек, ошибка в регламенте, некомпетентность сотрудника, баг в ПО. Проводят процессуальный RCA.
Исправление: Обновление регламентов, усиление контрольных процедур (например, введение двойного контроля для определенных операций), обучение сотрудников, доработка ПО.
Метрики: Количество ошибок на период, время на закрытие периода, стоимость исправления ошибки, размер штрафов/пени из-за просрочек.
Звучит красиво, да? А у вас так? Я крайне редко видел компании, где действительно описанный выше подход носил бы системный, регулярный и консистентный характер. Еще меньше компаний, где кто-то вел и анализировал бы статистику по инцидентами проблемам в бухгалтеском учете.
Нет системности - нет эффективности. Все просто.
Управление персоналом (HR)
Давайте разберем еще один пример управления инцидентами и проблемами в бизнес-функции. На мой взгляд важной, одной из основополагающих для любой компании - функции управления персоналом.
Не буду повторять все то, что было сказано выше, просто держите это в уме и давайте разберем.
Что и когда считать инцидентом, а что и когда проблемой?
На мой взгляд зависит от контекста, но вы ответьте для себя самостоятельно:
Ошибка в расчете зарплаты (переплата/недоплата).
Утечка конфиденциальных данных сотрудников (персональных данных).
Конфликт, нарушающий рабочий процесс (включая harassment — домогательства).
Просрочка критическог�� кадрового действия (оформление трудовой книжки, подача сведений в ПФР/ФСС).
Невыполнение обязательств перед сотрудником (например, непредоставление отпуска).
Согласитесь, без контекста, без понимания корневых причин, частотности, последствий сожно сказать, есть ли ситемный характер в проблеме "недоплаты сотруднику за работу в выходной", например - он просто пойдет в трудовую инспекцию, или это частный, редкий случай и "регулярно собираемая и анализируемая" статистика гворит о том, что это уникальный сучай и был решен мгновенно.
Как управляют? На основе чего?
Как и было ранее сказано в блоке о бухгалтерии, частично инцидетами и проблемами помогают управлять стандарты и регламенты: Трудовой кодекс, внутренние HR-политики, правила работы с персональными данными (152-ФЗ), регламенты процессов (прием, увольнение, оценка). Однако, при условии, что они есть и хорошего качества. Но только - частично.
Частично инцидетами и проблемами помогают управлять стандарты и регламенты - но только частично.
Процесс управления:
Реагирование: например, HRBP (бизнес-партнер) или менеджер выступает как "первая линия поддержки". Приоритет — снижение социальной напряженности.
Сдерживание: Компенсация ошибки зарплаты, временное решение конфликта (например, развод сотрудников по разным проектам), уведомление регулятора об утечке.
Анализ проблем: Почему ошибся расчет? (Некорректные исходные данные? Сложность формулы в Excel? Усталость специалиста?). Почему возник конфликт? (Пробелы в корпоративной культуре? Неэффективный менеджер?).
Исправление: Автоматизация расчета через HCM-системы (Human Capital Management), введение дополнительных проверок, тренинг для менеджеров, пересмотр политик.
Метрики: Индекс удовлетворенности сотрудников (eNPS), текучесть кадров, количество перерасчетов, сроки закрытия вакансий.
Казначейство (Treasury)
Попробуйте самостоятельно ответить на вопрос: а ваша или в вашей компании эффективно управляют деньгами? Что вам даст ответ на этот вопрос? Ведь здесь последствия могут быть мгновенными и финансово ощутимыми. Как измеряется эффективность функции в моменте?
Что считается инцидентом?
Просрочка платежа (особенно по кредиту или крупному контрагенту).
Ошибка в платежном поручении (неверные реквизиты, сумма, валюта).
Нехватка ликвидности для выполнения обязательств (кассовый разрыв).
Реализация рыночного риска (например, неблагоприятное движение курса валюты по незахеджированной позиции).
Как управляют? На основе чего?
Стандарты и регламенты: Внутренние лимиты и политики казначейства (кредитные, валютные, ликвидностные), регламенты платежного процесса, требования банков. Как было сказано ранее - если они есть, если они качественные и самое главное - если они соблюдаются.
Процесс управления:
Реагирование (крайне быстрое!): Экстренная связь с банком для отзыва/исправления платежа, срочный поиск ликвидности (межбанковский кредит, продажа активов).
Анализ проблем: RCA срочный и жесткий. Человеческий фактор? Сбой в системе интеграции с банком? Пробел в процедуре проверки? Недооценка рыночного риска
Исправление: Введение четырех- или шести-глаз принципа (multiple eyes) для критических платежей, настройка автоматических алертов о кассовых разрывах, пересмотр хеджирующих стратегий.
Метрики: Стоимость исправления ошибки (проценты за просрочку, штрафы, курсовые разницы), размер кассовых разрывов, количество платежных ошибок.
Но даже варианты перечисенные выше являются просто мерами "здесь и сейчас" без системного, регулярного и консистентного подхода. Анализа и мониторинга. Как происходит сбор, накопление и анализ инцидентов и пробллем у вас? Потушили и пошли дальше?
Общая модель
Общая модель управления инцидентами и проблемами для любых бизнес-процессов (Продажи (Sales), Маркетинг и Связи с общественностью (Marketing & PR), Управление поставками и закупками (Supply chain))
Управление строится по универсальной схеме, встроенной в систему Business Process Management (BPM) и Enterprise Risk Management (ERM):
Процесс = Стандарт. Каждый бизнес-процесс должен быть описан (регламент, SOP — Standard Operating Procedure). Это "базовая линия" нормальной работы.В зависимости от размера и зрелости определяется уровень детализации (да, зрелости бизнеса и процессов - стартап или компания с многолетней историей).
Что есть инцидент?
Инцидент = Отклонение от процесса, ведущее к операционным потерям или различным рискам. Примеры:
Sales: Срыв крупной сделки из-за ошибки в коммерческом предложении.
Supply Chain: Срыв поставки критического сырья на завод.
Что есть проблема?
Проблема = Системная причина отклонения.
Пример RCA:
Почему ошибка в предложении не была обнаружена ранее? (Плохой процесс контроля качества, усталый менеджер).
Почему возник риск срыва поставки? (Зависимость от одного поставщика, отсутствие альтернатив).
Что дальше?
Что поможет в привнесении эффективности в процесс управления инцидентами и проблемами в не ИТ и не ИБ процессы компании. Рекомендации:
Внедрение процесса и системы позволяющей выявлять регистрировать, анализировать и приоритизировать инцидетны и проблемы в бизнес-функциях компании. Проводить СИСТЕМНОЕ и РЕГУЛЯРНОЕ управление возникающими инцидентами и возможно существующими или будущими проблемами.
Инструменты:
Six Sigma (DMAIC) — методология совершенствования процессов, основанная на данных и направленная на минимизацию дефектов и отклонений до уровня, близкого к совершенству, за счет повышения эффективности и результативности процессов.
ERM - управлление рисками предприятий. Регулярный сбор и анализ инцидентов и рисков, как текущих, так и потенциальных. НЕ ОДИН РАЗ В ГОД! А ежедневно.
Корректирующие и предупреждающие действия (CAPA — Corrective and Preventive Actions) из стандарта качества ISO 9001.
Уже не раз упоминавышийся RCA (Root Cause Analysis): Те же методы (5 Why, Fishbone), но применяемые к бизнес-процессам.
Системы управления задачами и системы моделирования процессов, с возможностью отслеживать их выполнение в реальном времени (BAM — Business Activity Monitoring) и автоматически выявлять отклонения (инциденты).
Итог: Единая философия на всех уровнях
Уровень | ИТ-услуги | ИБ | Бизнес-процессы |
Объект | ИТ-сервис (почта, CRM) | Активы и данные | Бизнес-процесс (закрытие квартала, выплата зарплаты) |
Инцидент | Сбой сервиса | Нарушение целостности/конфиденциальности/доступности информации | Отклонение от плана/процесса, ведущее к потерям для компании |
Проблема | Техническая причина сбоя | Уязвимость или пробел в контроле над системой | Отклонение от/недостаток в процессе, компетенциях или регламенте |
Цель | Доступность услуги | Конфиденциальность, целостность, доступность | Операционная эффективность, соблюдение регуляторных требований, минимизация потерь |
Основной инструмент | ITSM-система | SIEM, SOAR, средства расследования | Система BPM, регламенты, CAPA |
Выводы
В бизнес-процессах, бизнес-функциях "управление инцидентами и проблемами" — это не выделенная служба, а часть повседневной операционной деятельности каждого подразделения, функции, отдела, руководителя и владельца процесса.
Через сбор, анализ и управление такими сущностями, как инцидент, проблема, риск, а также проводя анализ корневых причин возможно недопущение или предотвращение повторения через улучшение процессов, а не просто на тушении "пожаров". Как слледствие - это ваше конкуретное преимущество, это то, что позволяет сосредоточиться на развитии компании в ее стремлении достичь своей миссии.
Заключение
Управление инцидентами и проблемами не ограничено только ИТ и ИБ, они лишь отличный пример того, как одна и та же фундаментальная идея (выявление отклонения -> быстрое реагирование -> поиск и устранение коренной причины) адаптируется под разные контексты, риски и языки т.е. - специфику каждого, отдельно взятого или находящегося на пересечении других процессов - бизнес-процесса, бизнес-функции.
Именно эта универсальность применения подхода делает современные организации устойчивыми: будь то атака хакеров, ошибка в платежной ведомости или сбой на производственной линии — система управления инцидентами, проблемами и рисками обеспечивает структурированное восстановление и постоянное улучшение.
Таким образом, если ИТ и ИБ в современном мире стали весьма прозрачны в подходе к управлению инцидентами и проблемами в зоне их ответственности, и даже могут иметь выгоды от этого, выраженные в обосновании - например запроса и получения дополнительных ресурсов. То напротив, бизнес-функции как правило максималльно закрыты и об их эффективности вы сможете узнать только спустя время, когда вам доначислят налоги, начислят пени за вовремя не уплаченный штраф, будет сделан перевод не той суммы и не тому контрагенту, ваш продукт провалится по продажам или когда вы потеряете кллючевых разработчиков из за "токсичной атмосферы" в командах.
Хотите стать лучше, хотите идти в будущее, хотите эффективно конкурировать, хотите быть лучшими? Станьте эффективнее внутри. Делайте что-то иначе от авось, неформально и я так вижу.
Вы можете связаться со мной, если у вас возникнут вопросы или потребуется консультация.
Удачи в построении эффективных и устойчивых процессов.
