198
1
0
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
Назад

Бизнес-моделирование: как и зачем его использовать в разработке

Время чтения 1 минута
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
198
1
0
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники

Привет! Меня зовут Дмитрий Кочергов, и я более 16 лет работаю в масштабных российских и международных проектах автоматизации, преподаю проектирование информационных систем в Политехе Петра Великого, веду блог по практике системного и бизнес-анализа в ИТ, занимаюсь фундаментальной наукой в области сильного искусственного интеллекта и пишу статьи на вАЙТИ.

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

Бизнес-моделирование: как и зачем его использовать в разработке

Основные стадии создания АИС

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

Согласно ГОСТ 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) — группа методик, в числе прочего включающая:

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

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

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

  • Схема должна быть лучше, чем любой текст, который мог бы описать ее содержимое. Если диаграмму проще и быстрее объяснить словами, зачем она нужна.
  • Надписи и объекты на схеме вырезайте как минимум в три итерации:
  1. Бритвой Оккама: «многообразие не следует предполагать без необходимости».
  2. Выкидывая вообще все лишние для контекста слова и элементы.
  3. Инверсионной проверкой: мысленно замените надпись на противоположную по смыслу — если получается нонсенс как в абсолюте, так и относительно предмета моделирования, скорее всего, вы написали бесполезное. Например, «Раздел „Новости‟ содержит актуальную повестку», а разве новости пишут про пыль времен?
  • Схема должна показывать необходимый, но достаточный уровень детализации: бессмысленно пытаться ответить на извечные вопросы бытия в одной картинке, в итоге получится хуже, чем 42 из «Автостопом по галактике». Выводите не более семи сущностей на один уровень, убирайте второстепенные детали за рамки модели.

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

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

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

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

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

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

Как понять, что конкретному процессу необходима оптимизация

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

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

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

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

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

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

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

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

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

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

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

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

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

Комментарии0
Тоже интересно
Комментировать
Поделиться
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники