Бизнес-процессы в организации - что это такое и как их описать

Единое окно

Создание системы управления событиями и инцидентами ИБ позволяет организовать «единое окно», в котором в доступном виде предоставляется информация о защищенности и состоянии ИС. Учитывая наличие средств своевременного оповещения и реагирования, такая система становится незаменимым помощником ИБ/IТ-специалистов.

Таким образом, грамотная и последовательная реализация проекта по созданию системы управления событиями — важный этап развития системы менеджмента ИБ, а долгосрочную практическую пользу применения технологий SIEM способны обеспечить правильная постановка задач, полный учет технических особенностей и, разумеется, внимание к деталям

Единое окно

Управление событиями и мониторингом

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

ITIL 4 уделяет большее внимание задаче мониторинга, что даже отразилось в названии практики. Описывается реактивный (классический) и проактивный (упреждающий) мониторинг, вводится понятие «Модель здоровья услуги»

Например, мониторинг полного пути транзакции от запроса клиента до выполнения.

Новое в ITIL 4:

проводится реактивный и упреждающий мониторинг;
проводится активный и пассивный (инициируемый самим ИТ-активом) мониторинг;
введено понятие «Модель здоровья» услуги.

Типы связей между элементами диаграммы BPMN

Типы связей, которые могут быть наведены между элементами на диаграмме BPMN, перечислены в таблицах (Табл. 2 — Табл. 6). При необходимости перечень типов связей может быть изменен.

Элемент, с которым устанавливается связь	Тип связи	Назначение связи
База данных	изменяет	Связь используется, если необходимо отобразить, что в рамках выполнения процесса в базу данных вносятся изменения.
имеет на выходе	Связь используется, если необходимо отобразить, что база данных передается из одного процесса в другой.
создает на выходе	Связь используется, если необходимо отобразить, что в результате выполнения процесса создается новая база данных.
Документ	изменяет	Связь используется, если необходимо отобразить, что в рамках выполнения процесса в документ вносятся изменения.
имеет на выходе	Связь используется, если необходимо отобразить, что документ передается из одного процесса в другой.
создает на выходе	Связь используется, если необходимо отобразить, что в результате выполнения процесса создается новый документ.
Информация	изменяет	Связь используется, если необходимо отобразить, что в рамках выполнения процесса изменяется информация.
имеет на выходе	Связь используется, если необходимо отобразить, что информация передается из одного процесса в другой.
создает на выходе	Связь используется, если необходимо отобразить, что в результате выполнения процесса появляется информация.
ТМЦ	изменяет	Связь используется, если необходимо отобразить, что в рамках выполнения процесса изменяется ТМЦ.
имеет на выходе	Связь используется, если необходимо отобразить, что ТМЦ передается из одного процесса в другой.
создает на выходе	Связь используется, если необходимо отобразить, что в результате выполнения процесса формируется ТМЦ.
Программный продукт	изменяет	Связь используется, если необходимо отобразить, что в рамках выполнения процесса изменяется Информационная система, ее модуль или функция.
имеет на выходе	Связь используется, если необходимо отобразить, что Информационная система, ее модуль или функция передается из одного процесса в другой.
создает на выходе	Связь используется, если необходимо отобразить, что в результате выполнения процесса создается Информационная система, ее модуль или функция.

Таблица 2. Типы связей Процесса с Объектами деятельности

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

Таблица 3. Типы связей Программного продукта

Элемент, с которым устанавливается связь	Тип связи	Назначение связи	Пример использования связи
Процесс	предоставляет входные данные для	Связь используется, если необходимо отобразить, что выполнение процесса осуществляется с использованием документа.

Таблица 4. Типы связей Документа

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

Таблица 5. Типы связей Информации

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

Таблица 6. Типы связей ТМЦ

Подробнее о формировании модели бизнес-процессов см. в Руководство пользователя в главе Создание модели деятельности организации.

« Предыдущая

На уровень выше

Правила описания бизнес-процесса

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

Правила

Завершенность или ответ на ключевой вопрос

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

Краткость и лаконичность

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

Документ включает совокупность данных в большом объеме, но их важно изложить кратко, с акцентом на основные моменты. Лишние детали и отстраненные формулировки отвлекают

Использование типовых нотаций

Существуют общепринятые международные обозначения, которые и должны использоваться в описаниях. Это стандарты IDEF3, BPMN 2.0, BPMN и другие. Они позволяют читать и правильно трактовать бизнес-процесс любому человеку. Применение личных выдуманных обозначений недопустимо.

Понятность

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

Важное отступление: место процесса в системе менеджмента качества (ИСО 9001)

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

Часто выход одного процесса образует непосредственно вход следующего.
Применение в организации системы процессов наряду с их идентификацией и взаимодействием, а также менеджмент процессов, направленный на получение желаемого результата, могут быть определены как «процессный подход».
Преимущество процессного подхода состоит в непрерывности управления, которое он обеспечивает на стыке отдельных процессов в рамках их системы, а также при их комбинации и взаимодействии.
При применении в системе менеджмента качества такой подход подчеркивает важность:
a) понимания и выполнения требований;
b) необходимости рассмотрения процессов с точки зрения добавляемой ими ценности;
c) достижения запланированных результатов выполнения процессов и обеспечения их результативности;
d) постоянного улучшения процессов, основанного на объективном измерении.
Приведенная на рисунке модель системы менеджмента качества, основанной на процессном подходе, иллюстрирует связи между процессами (организации — прим.авт.). Эта модель показывает, что потребители играют существенную роль в установлении требований, рассматриваемых в качестве входов

Мониторинг удовлетворенности потребителей требует оценки информации о восприятии потребителями выполнения их требований. Приведенная на рисунке модель охватывает все основные требования настоящего стандарта, но не показывает процессы на детальном уровне.»

Логические операторы

Поскольку BPMN показывает логику выполнения бизнес-процесса, в диаграммах используются логические операторы, которые также называются развилками или шлюзами. Изначально их всего три: OR, XOR и AND.

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

Пример исключающего ИЛИ

В отличие от исключающего или, простое ИЛИ (OR) допускает возможность активации как нескольких веток, так и одной из них. В математическом смысле этот оператор реализует дизъюнкцию или логическое сложение переменных, что показано в таблице истинности на слайде.

Наконец, логическое И (AND) означает активацию всех входящих или исходящих в этот оператор потоков управления, реализуя логическое умножение переменных, т. е. операцию конъюнкции.

Пример логического И

Поскольку алфавит BPMN является избыточным, помимо базовых операторов булевой алгебры (то есть ранее рассмотренных И, ИЛИ и исключающего ИЛИ) в нотации также присутствуют усложнённые вариации этих операторов.

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

Следующий рисунок показывает использование эксклюзивного шлюза по событиям, который запускает движение потока только по той ветке, где событие произойдёт раньше. Например, получено согласие от клиента ИЛИ прошло 5 дней (без новостей от клиента).

Пример использования эксклюзивного шлюза по событиям

Система управления событиями

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

Под событием понимается изменение состояния, которое имеет значение для безопасности, управления или работоспособности ИС или ее компонента, а также зарегистрированная в журнале информация о данном событии.

Конечно же, во главу угла ставятся задачи, которые должна решать система. С учетом этих задач решается вопрос — события с каких элементов IT-инфраструктуры могут дать необходимые исходные данные. Таким образом определяются типы и количество источников событий (Event Sources). При этом в качестве источника выступает не абстрактный компьютер или устройство, а более конкретные объекты: ОС, приложения, СУБД, средства защиты информации и т.п. То есть, например, на одном сервере фактически может находиться N источников событий.

После этого необходимо разобраться, какие именно события из регистрируемых на источнике представляют интерес. Здесь начинается работа по настройке политик аудита и ведения журналов регистрации событий на источниках (Log Management), так как если событие не сгенерировано, то оно не может быть обработано.

Чтобы количественно оценить ожидаемый поток событий, измеряемый в EPS (Events per Second), можно использовать различного рода калькуляторы, предлагаемые производителями SIEM-решений: HP (продукт ArcSight), ЕМС (RSA enVision), IBM (QRadar) и др. При расчете следует учитывать не только средние показатели, но и данные в период пиковых нагрузок, так как некоторые SIEM-решения имеют жесткое ограничение по количеству EPS.

SIEM-решения

После определения перечня источников и значений EPS можно переходить к выбору SIEM-продукта. На сегодняшний день на рынке представлено свыше 80 подобных решений. Для выбора наиболее подходящего целесообразно ориентироваться на следующие ключевые критерии:

реализация — программная или программно-аппаратная, плюс возможность виртуализации;
перечень поддерживаемых штатно источников событий;
показатели EPS;
способы получения событий (Syslog, ODBC, SNMP, FTP и т.д.);
возможность подключения внешних систем хранения данных.

Отдельно стоит сказать об архитектуре SIEM-решений. Это могут быть интегрированные устройства (all-in-one) либо двух-трехкомпонентные комплексы. Распределенная архитектура чаще всего предполагает большую производительность и лучшие возможности по масштабированию, а также позволяет развернуть SIEM-решение в IT-инфраструктурах с несколькими площадками.

Под инцидентом понимается незапланированное прерывание работы ИС или снижение показателей ее работы, а также зарегистрированная в БД инцидентов информация о нем.

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

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

Перейдем к внедрению системы. После установки и инициализации компонентов SIEM-решения производится подключение источников. Здесь существуют два основных варианта:

источник сам инициирует передачу событий (например, отправляет по syslog-протоколу);
события с источника надо забирать.

С первым вариантом все достаточно просто: на источнике указывается IP-адрес устройства, осуществляющего сбор событий (коллектора), и события «текут» в нужную сторону. Второй вариант включает агентный или безагентный сбор информации, причем в некоторых SIEM-системах для части источников доступны оба способа. Агентный способ предполагает использование специальной программы-агента, безагентный — спецнастройки источника событий, такие как создание дополнительных учетных записей, разрешение удаленного доступа и/или использования дополнительных протоколов. Если есть выбор, какой способ подключения использовать, необходимо оценить все плюсы и минусы и по возможности опробовать оба варианта в «пилоте».

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

Когда все источники подключены и роли заданы, выполняется настройка правил обработки событий, отчетов и уведомлений. Пожалуй, это наиболее кропотливая часть внедрения. Работа с событиями и результатами их анализа в большинстве SIEM-продуктов осуществляется с использованием отчетов (Reports) и запросов (Query). Здесь все зависит от возможностей конкретного SIEM-решения и потребностей заказчика.

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

Как правило, SIEM-решения предлагают следующие варианты реакции на заданное событие (цепочку событий):

«красная лампочка» на рабочей панели (Dashboard) администратора;
отправка сообщений по электронной почте или SMS;
выполнение заданного командного сценария (скрипта) на источнике;
создание инцидента ИБ во встроенном или внешнем сервисе HelpDesk/ServiceDesk.

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

Система управления событиями

Ментальный подход в моделировании бизнес-процессов

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

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

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

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

Моделирование бизнес-процессов: для чего нужно и как его провести

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

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

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

Есть три основных подхода в моделировании: функциональный, процессный и ментальный. Каждый подход предполагает, что нужно визуализировать процессы, рисовать схемы.

Функциональный подход. При этом подходе описывают результаты, которые нужно получить, и ресурсы, которые при этом будут задействованы. Без учёта какой-либо последовательности действий.

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

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

Фрагмент функциональной модели бизнес-процесса: входы, выходы и внешние элементыИнфографика: Майя Мальгина для Skillbox Media

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

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

Фрагмент процессной модели бизнес-процесса: основные действия менеджера по продажамИнфографика: Майя Мальгина для Skillbox Media

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

Вот пример ментальной карты процесса снабжения:

Фрагмент ментальной модели. Составлен в свободной форме — все элементы вращаются на орбите процессаИнфографика: Майя Мальгина для Skillbox Media

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

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

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

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

В чем проблема

Для большинства проектных менеджеров (даже Agile) классическим источником best practices для ведения проектов является PMBoK. Те, кто хоть раз заглядывал в PMBoK, помнят, что проект ограничен по времени, уникален, имеет четкий скоуп. Но если посмотреть на большинство проектов в ІТ, особенно в сфере ІТ-аутсорсинга — чаще всего это T&M или Dedicated Team, — то такая форма кооперации больше похожа на сервис. По сути, мы предоставляем клиенту услугу, сервис разработки программного обеспечения, а настоящим проектом можно считать, скорее, Fixed-Price. Так что если у вас с клиентом контракт, по которому вы предоставляете ресурсы, а не конкретный результат, смело можно считать его сервисом

Не то чтобы PMBoK в таком случае вам не подходил, но это означает, что стоит обратить внимание и пристально изучить еще один источник знаний — ITIL (особенно такие разделы, как Service Level Management, Capacity/Availability Management, Request Fulfilment и Incident Management)

PMBoK — американский национальный стандарт управления проектами, который описывает лучшие практики управления проектами. То есть для ограниченного во времени объема работ, который направлен на создание уникального продукта, услуги или результата. Согласно PMBoK, сервис относится к операционной деятельности (не является проектом), а значит, практики PMBoK на него не распространяются (но никто не запрещает их применять).

Как раз такой вид деятельности покрывают практики из ITIL. ITIL (IT Infrastructure Library) — это наиболее широко используемый и общепринятый подход к управлению ІТ-услугами во всем мире. ITIL был разработан относительно независимо от управления проектами, воплощает несколько ценных идей управления и включает проверенные процедуры, которые могут быть полезны также для практики управления проектами.

Подведём итог

Бизнес-процессы — любые операции внутри компании, которые помогают решать бизнес-задачи и зарабатывать. Моделирование бизнес-процессов — описание существующих в компании процессов и документирование требований к ним.
В моделировании бизнес-процессов есть три основных подхода: функциональный, процессный и ментальный. Самый понятный подход для неподготовленного человека — процессный. Он даёт подробный алгоритм действий для сотрудников и глубокую детализацию операций.
Моделировать процессы можно своими силами — если бизнес небольшой и несложный. Если в дальнейшем нужно оптимизировать процессы, лучше привлечь консультантов.
Бизнес-процессы обычно описывают графически — в виде карт и интуитивно понятных схем. Так с ними проще работать.
Смоделировать процесс можно самому: разобрать внутреннюю кухню компании, описать в тексте все алгоритмы и на основе этого построить схему в графическом редакторе.