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

Суть работы бизнес- и системного аналитика – документировать жизненный цикл ИТ-решений, от стадии концепции и сбора требований через проектирование к реализации, включая техно-рабочий проект. Артефакты анализа, включая бизнес-модель – это результаты такого документирования. Согласно ГОСТ 34.601-90, выделяют восемь основных стадий создания автоматизированной информационной системы (АИС), первые пять из которых – в компетенции аналитиков (см. таблицу).

Распределение артефактов анализа по стадиям жизненного цикла АИС

Бизнес-анализ в целях разработки АИС в самом общем и кратком представлении выглядит так:

собираем информацию о том, как устроен бизнес заказчика или типичного покупателя на отраслевом рынке, что в нем хорошо, а что не так, чего не хватает;
формулируем бизнес-правила как инструкции (надо) и ограничения (не надо) бизнес-процессов на предполагаемом объекте автоматизации или в организации покупателя;
описываем пользовательские истории (user-stories) как ожидания стейкхолдеров и ключевых пользователей от возможностей АИС;
составляем перечень бизнес-процессов в рамках границ проекта (scope);
исходя из бизнес-правил, рисуем диаграммы бизнес-процессов – схемы с последовательностями работ в удобной нотации, например, BPMN, IDEF0, ARIS EPC, это модель «как есть (as-is)»;
исходя из бизнес-правил и user-stories, с учетом критериев и ограничений оптимизации, рисуем модель бизнес-процессов «как должно стать (to-be)» в той же нотации – делаем реинжиниринг;
проводим GAP-анализ и оцениваем ожидаемые эффекты от реинжиниринга.

Вуаля, мы сформировали бизнес-модель! Остановимся более подробно на последних трех пунктах.

Диаграммы процессов

Для отрисовки процессов применяют разные стандарты – так называемые нотации, или методики.

Одна из самых популярных – BPMN. Она, по сути, где-то на пересечении множеств возможностей SADT, IDEF и диаграммы последовательностей UML и поэтому более всего полезна для подготовки workflow бизнес-процессов, функциональных моделей для процессов с автоматизацией, а также для проектирования системных интеграций.

Язык UML – это почти 800 страниц премудростей инженерной мысли, рисуй-не-хочу! На деле чаще востребованы диаграммы:

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

Семейство IDEF (https://www.idef.com, в рунете - через VPN) – группа методик, в числе прочего, включающая:

IDEF0 – для бизнес-моделей, на которых важно отразить не только входящие сигналы (в т. ч. инициирующие) и результаты, но также ресурсы, инструменты, управляющих агентов и регламенты;
IDEF1X – для реляционных логических и физических схем данных типа «сущность-связь»;
IDEF3 – для статусных моделей объектов данных и моделей информационных потоков, иллюстрирует юзкейсы и пригодится в постановках на разработку функциональных требований.

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

Из опыта могу предложить несколько советов схемопостроения в ИТ:

схема должна быть лучше, чем любой текст, который мог бы описать ее содержимое, если диаграмму проще и быстрее объяснить словами, зачем она нужна;
надписи и объекты на схеме вырезайте, как минимум, в три итерации:
- бритвой Оккама – «многообразие не следует предполагать без необходимости»;
- выкидывая вообще все лишние для контекста слова и элементы;
- инверсионной проверкой: мысленно замените надпись на противоположную по смыслу – если получается нонсенс, как в абсолюте, так и относительно предмета моделирования, скорее всего, вы написали бесполезное: к примеру, «раздел Новости содержит актуальную повестку», а разве новости пишут про пыль времен;
схема должна показывать необходимый, но достаточный уровень детализации, бессмысленно пытаться ответить на извечные вопросы бытия в одной картинке, в итоге получится хуже, чем «42» из Автостопом по галактике, выводите не более семи сущностей на один уровень, убирайте второстепенные детали за рамки модели.

Оптимизация и реинжиниринг

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

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

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

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

Как, исходя из бизнес-модели, понять, что конкретному процессу необходима оптимизация? Предлагаю взглянуть на схему as-is (на примере нотации BPMN) при помощи простого теста:

на диаграмме одного бизнес-процесса количество участников (ролей - дорожек) аналогично или превышает число шагов (работ);
хотя бы в одном операторе исключающего ИЛИ более одного исходящего потока ведут сразу к выходу из процесса;
отсутствуют уведомления ключевых ролей процесса о смене статуса работ;
в одном процессе больше 2 сложных операторов условия;
в одном процессе более 2 эскалаций;
хотя бы в одном операторе объединения И более 3 входящих потоков управления (не по умолчанию);
в одном процессе более 3 завершающих событий-выходов.

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

Важный момент – при выборе вариантов оптимизации советую соблюдать баланс трех факторов:

цена выбора (не только в деньгах);
влияние выбора внутри и вне процесса;
ваше личное отношение (экспертиза).

Выводы: бенефиты для бизнеса

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

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

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

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

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

ЧТО делает система (объект, модуль, приложение, комплекс, решение и т. п.);
КАК система что-то делает.

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

Бизнес-моделирование в ИТ-разработке