Бизнес-моделирование в ИТ-разработке
В этой статье поговорим о некоторых важных аспектах бизнес-анализа в части описания автоматизируемых процессов, их оптимизации и реинжиниринга с целью последующей оцифровки и ожидаемой полезности такого моделирования для бизнеса.
Суть работы бизнес- и системного аналитика — документировать жизненный цикл ИТ-решений, от стадии концепции и сбора требований через проектирование к реализации, включая техно-рабочий проект. Артефакты анализа, включая бизнес-модель — это результаты такого документирования. Согласно ГОСТ 34.601–90, выделяют восемь основных стадий создания автоматизированной информационной системы (АИС), первые пять из которых — в компетенции аналитиков (см. таблицу).
Распределение артефактов анализа по стадиям жизненного цикла АИС
Бизнес-анализ в целях разработки АИС в самом общем и кратком представлении выглядит так:
собираем информацию о том, как устроен бизнес заказчика или типичного покупателя на отраслевом рынке, что в нем хорошо, а что не так, чего не хватает;
формулируем бизнес-правила как инструкции (надо) и ограничения (не надо) бизнес-процессов на предполагаемом объекте автоматизации или в организации покупателя;
описываем пользовательские истории (user-stories) как ожидания стейкхолдеров и ключевых пользователей от возможностей АИС;
составляем перечень бизнес-процессов в рамках границ проекта (scope);
исходя из бизнес-правил, рисуем диаграммы бизнес-процессов — схемы с последовательностями работ в удобной нотации, например, BPMN, IDEF0, ARIS EPC, это модель «как есть (as-is)»;
исходя из бизнес-правил и user-stories, с учетом критериев и ограничений оптимизации, рисуем модель бизнес-процессов «как должно стать (to-be)» в той же нотации — делаем реинжиниринг;
проводим GAP-анализ и оцениваем ожидаемые эффекты от реинжиниринга.
Вуаля, мы сформировали бизнес-модель! Остановимся более подробно на последних трех пунктах.
Диаграммы процессов
Для отрисовки процессов применяют разные стандарты — так называемые нотации, или методики.
Одна из самых популярных — BPMN (https://www.omg.org/bpmn). Она, по сути, где-то на пересечении множеств возможностей SADT, IDEF и диаграммы последовательностей UML и поэтому более всего полезна для подготовки workflow бизнес-процессов, функциональных моделей для процессов с автоматизацией, а также для проектирования системных интеграций.
Язык UML (https://www.omg.org/spec/UML) — это почти 800 страниц премудростей инженерной мысли, рисуй-не-хочу! На деле чаще востребованы диаграммы:
классов — для оргструктур, онтологий предметной области, логической схемы данных;
прецедентов — для юзкейсов, бизнес-правил и пользовательских историй;
последовательностей — для схем потоков данных между модулями и компонентами системы, а также с внешним окружением.
Семейство IDEF (https://www.idef.com, в рунете — через VPN) — группа методик, в числе прочего, включающая:
IDEF0 — для бизнес-моделей, на которых важно отразить не только входящие сигналы (в т. ч. инициирующие) и результаты, но также ресурсы, инструменты, управляющих агентов и регламенты;
IDEF1X — для реляционных логических и физических схем данных типа «сущность-связь»;
IDEF3 — для статусных моделей объектов данных и моделей информационных потоков, иллюстрирует юзкейсы и пригодится в постановках на разработку функциональных требований.
Разумеется, это не исчерпывающий список, и наверняка вы столкнетесь с нетривиальными задачами, где помогут другие нотации, тем не менее, не устану повторять, что главное — не форма артефакта, а его содержание и, следовательно, польза для проекта.
Из опыта могу предложить несколько советов схемопостроения в ИТ:
схема должна быть лучше, чем любой текст, который мог бы описать ее содержимое, если диаграмму проще и быстрее объяснить словами, зачем она нужна;
надписи и объекты на схеме вырезайте, как минимум, в три итерации:
бритвой Оккама — «многообразие не следует предполагать без необходимости»;
выкидывая вообще все лишние для контекста слова и элементы;
инверсионной проверкой: мысленно замените надпись на противоположную по смыслу — если получается нонсенс, как в абсолюте, так и относительно предмета моделирования, скорее всего, вы написали бесполезное: к примеру, «раздел Новости содержит актуальную повестку», а разве новости пишут про пыль времен;
схема должна показывать необходимый, но достаточный уровень детализации, бессмысленно пытаться ответить на извечные вопросы бытия в одной картинке, в итоге получится хуже, чем »42» из Автостопом по галактике, выводите не более семи сущностей на один уровень, убирайте второстепенные детали за рамки модели.
Оптимизация и реинжиниринг
Когда говорят об автоматизации, или информатизации, в полном цикле проектных работ часто по умолчанию предполагают выполнение реинжиниринга — анализа и разработки таких рекомендаций по перестройке бизнес-процессов, которые, как минимум, позволят эту автоматизацию реализовать. На самом деле, реинжиниринг для этого требуется не всегда, и они с проектом внедрения АИС в общем смысле — разные вещи. Можно переделывать процессы без дополнительной автоматизации, можно вместе, а порой с бизнесом и так все в порядке, достаточно скорректировать с помощью ИТ лишь некоторые параметры, а не всю его схему.
Реинжинирингу нужны смыслы — ради чего мы меняемся и куда идем. Их называют критериями (мерой) оптимизации — эффективностью управляют через ресурсоемкость, оперативность и результативность процессов (треугольник). И, по природе любой системы, существуют некие пределы — ограничения оптимизации, коридор возможностей, выше и ниже пороговых значений которого нам нельзя уходить в процессе изменений по критериям. Чтобы сделать реинжиниринг, необходимо определить критерии и ограничения планируемой оптимизации. Если процесс не слишком трудно хотя бы приблизительно описать с помощью функции, вам очень пригодятся математические методы.
Поскольку реинжиниринг — это про поиск оптимального, важно понимать, что оно всегда дихотомично, у функции есть два экстремума, выше и ниже нуля. Только одно из них станет «улучшением» в конкретном кейсе, следует заранее выяснить, какое. Не менее критично сохранять фокус внимания на альтернативных издержках — потенциальных возможностях, неизбежно упускаемых с каждым шагом управления при выборе параметров оптимизации: это цена перемен. С учетом ограничений, принципиально нельзя бесконечно расти по всему полю треугольника эффективности.
Отсюда оптимизация бизнес-процессов — это, скорее, о балансе распределения ресурсов и реализации изменений без ухудшения, по принципу Парето-эффективности: «Всякое изменение, которое никому не приносит убытков, а некоторым людям приносит пользу, является улучшением». Предвижу возражения — всем не угодить, так можно скатиться в бесконечные компромиссы до вырожденного невмешательства, и с этим согласятся критики неоклассической школы экономической теории. Вместе с тем, современная расширенная трактовка оптимума Парето — принцип компенсации — допускает локальные «ухудшения», если реинжиниринг в целом принесет достаточно пользы, чтобы их оправдать, поэтому ищите свой баланс.
Как, исходя из бизнес-модели, понять, что конкретному процессу необходима оптимизация? Предлагаю взглянуть на схему as-is (на примере нотации BPMN) при помощи простого теста:
на диаграмме одного бизнес-процесса количество участников (ролей — дорожек) аналогично или превышает число шагов (работ);
хотя бы в одном операторе исключающего ИЛИ более одного исходящего потока ведут сразу к выходу из процесса;
отсутствуют уведомления ключевых ролей процесса о смене статуса работ;
в одном процессе больше 2 сложных операторов условия;
в одном процессе более 2 эскалаций;
хотя бы в одном операторе объединения И более 3 входящих потоков управления (не по умолчанию);
в одном процессе более 3 завершающих событий-выходов.
Если вы ответили «да» более чем в 3 пунктах из 7, вашу схему (ну, и процесс) стоит оптимизировать — для начала попробуйте устранить соответствующие недостатки. Например, п. 1) — свидетельствует о размывании ответственности, чрезмерной зависимости результатов от человеческого фактора и низкой оперативности, значит, можно поработать над сокращением числа участвующих ролей.
Важный момент — при выборе вариантов оптимизации советую соблюдать баланс трех факторов:
цена выбора (не только в деньгах);
влияние выбора внутри и вне процесса;
ваше личное отношение (экспертиза).
Выводы: бенефиты для бизнеса
Как мы убедились, бизнес-модель описывает существующие схемы и правила выполнения тех или иных рабочих процессов, а также может включать рекомендации по их изменению. Что это дает?
Во-первых, и главное, моделирование помогает увидеть происходящее как систему — охватить одним взглядом сразу всех участников, их работу и взаимосвязи. Такое системное видение необходимо стейкхолдерам для самооценки, понимания своего места и отстройки бизнеса в целом от конкурентов, формирования стратегии развития.
Во-вторых, когда вы рисуете диаграммы бизнес-процессов, вне зависимости от объема исходных данных и глубины погружения в контекст, обязательно всплывают новые, не выявленные до сих пор вопросы и нюансы, особенно в части логики и целесообразности. Чем подробнее модель, тем больше скрытых возможностей для улучшения она покажет — полезно отмечать их в комментариях прямо на схемах.
В-третьих, если по запросу заинтересованных лиц или в ходе анализа выяснилось, что необходим реинжиниринг, модель подскажет критерии оптимизации — те количественные и качественные характеристики, которые определяют оценку результатов бизнес-процессов, что конкретно и в какую сторону нужно изменить. Более того, ограничения таких изменений так же могут стать понятнее благодаря визуализации.
Если взглянуть на бизнес-моделирование не как на последовательность действий, а с точки зрения его сути, важны, прежде всего, две вещи:
ЧТО делает система (объект, модуль, приложение, комплекс, решение и т. п.);
КАК система что-то делает.
Более того, можно воспользоваться еще одним бесценным методом науки — индукцией — и сказать: все, что мы в принципе можем узнать, анализируя предметную область, объект автоматизации, его бизнес-процессы, возможные способы их оптимизации, средства цифровизации, эффекты внедрения и т. д. — это все про ЧТО и КАК. Такова природа знания. Поэтому анализ бесполезен без изучения динамики: с помощью бизнес-модели мы рассматриваем объекты и системы в действии, во всех четырех измерениях пространства-времени. Модель описывает не просто процесс — регулярный поток работ, повторяющихся с определенной периодичностью, каждая итерация может отличаться своими особенностями — например, скоростью, затратами, результатами. Исследуя эти флуктуации, мы видим анализируемое во всем объеме его сложности и взаимосвязей с внешним миром.
