Основные стадии создания АИС
Суть работы бизнес- и системного аналитика — документировать жизненный цикл ИТ-решений: от стадии концепции и сбора требований через проектирование до реализации, включая техно-рабочий проект. Артефакты анализа, включая бизнес-модель, — это результаты такого документирования.
Согласно ГОСТ 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 — для статусных моделей объектов данных и моделей информационных потоков, иллюстрирует юзкейсы и пригодится в постановках на разработку функциональных требований.
Разумеется, это не исчерпывающий список, и наверняка вы столкнетесь с нетривиальными задачами, где помогут другие нотации. Тем не менее не устану повторять, что главное — не форма артефакта, а его содержание и, следовательно, польза для проекта.
Из опыта могу предложить несколько советов схемопостроения в ИТ:
- Схема должна быть лучше, чем любой текст, который мог бы описать ее содержимое. Если диаграмму проще и быстрее объяснить словами, зачем она нужна.
- Надписи и объекты на схеме вырезайте как минимум в три итерации:
- Бритвой Оккама: «многообразие не следует предполагать без необходимости».
- Выкидывая вообще все лишние для контекста слова и элементы.
- Инверсионной проверкой: мысленно замените надпись на противоположную по смыслу — если получается нонсенс как в абсолюте, так и относительно предмета моделирования, скорее всего, вы написали бесполезное. Например, «Раздел „Новости‟ содержит актуальную повестку», а разве новости пишут про пыль времен?
- Схема должна показывать необходимый, но достаточный уровень детализации: бессмысленно пытаться ответить на извечные вопросы бытия в одной картинке, в итоге получится хуже, чем 42 из «Автостопом по галактике». Выводите не более семи сущностей на один уровень, убирайте второстепенные детали за рамки модели.
Оптимизация и реинжиниринг
Когда говорят об автоматизации, или информатизации, в полном цикле проектных работ, часто по умолчанию предполагают выполнение реинжиниринга — анализа и разработки таких рекомендаций по перестройке бизнес-процессов, которые как минимум позволят эту автоматизацию реализовать.
На самом деле реинжиниринг для этого требуется не всегда, и они с проектом внедрения АИС в общем смысле — разные вещи. Можно переделывать процессы без дополнительной автоматизации, можно вместе, а порой с бизнесом и так всё в порядке, достаточно скорректировать с помощью ИТ лишь некоторые параметры, а не всю его схему.
Реинжинирингу нужны смыслы: ради чего мы меняемся и куда идем. Их называют критериями (мерой) оптимизации — эффективностью управляют через ресурсоемкость, оперативность и результативность процессов (треугольник). По природе любой системы существуют некие пределы — ограничения оптимизации, коридор возможностей, выше и ниже пороговых значений которого нам нельзя уходить в процессе изменений по критериям. Чтобы сделать реинжиниринг, необходимо определить критерии и ограничения планируемой оптимизации. Если процесс не слишком трудно хотя бы приблизительно описать с помощью функции, вам очень пригодятся математические методы.
Поскольку реинжиниринг — это про поиск оптимального, важно понимать, что он всегда дихотомичен, у функции есть два экстремума, выше и ниже нуля. Только один из них станет «улучшением» в конкретном кейсе; следует заранее выяснить какой. Не менее критично сохранять фокус внимания на альтернативных издержках — потенциальных возможностях, неизбежно упускаемых с каждым шагом управления при выборе параметров оптимизации. Это цена перемен. С учетом ограничений принципиально нельзя бесконечно расти по всему полю треугольника эффективности.
Отсюда оптимизация бизнес-процессов — это, скорее, о балансе распределения ресурсов и реализации изменений без ухудшения по принципу эффективности Парето: «Всякое изменение, которое никому не приносит убытков, а некоторым людям приносит пользу, является улучшением». Предвижу возражения: всем не угодить, так можно скатиться в бесконечные компромиссы до вырожденного невмешательства, и с этим согласятся критики неоклассической школы экономической теории. Вместе с тем современная расширенная трактовка оптимума Парето — принцип компенсации — допускает локальные «ухудшения», если реинжиниринг в целом принесет достаточно пользы, чтобы их оправдать, поэтому ищите свой баланс.
Как понять, что конкретному процессу необходима оптимизация
Предлагаю взглянуть на схему as-is (на примере нотации BPMN) при помощи простого теста:
- на диаграмме одного бизнес-процесса количество участников (ролей — дорожек) аналогично или превышает число шагов (работ);
- хотя бы в одном операторе исключающего «ИЛИ» более одного исходящего потока ведет сразу к выходу из процесса;
- отсутствуют уведомления ключевых ролей процесса о смене статуса работ;
- в одном процессе более двух сложных операторов условия;
- в одном процессе более двух эскалаций;
- хотя бы в одном операторе объединения «И» более трех входящих потоков управления (не по умолчанию);
- в одном процессе более трех завершающих событий-выходов.
Если вы ответили «да» более чем в трех пунктах из семи, вашу схему (и процесс) стоит оптимизировать — для начала попробуйте устранить соответствующие недостатки. Например, первый пункт свидетельствует о размывании ответственности, чрезмерной зависимости результатов от человеческого фактора и низкой оперативности, значит, можно поработать над сокращением числа участвующих ролей.
Важный момент! При выборе вариантов оптимизации советую соблюдать баланс трех факторов:
- цена выбора (не только в деньгах);
- влияние выбора внутри и вне процесса;
- ваше личное отношение (экспертиза).
Выводы: бенефиты для бизнеса
Как мы убедились, бизнес-модель описывает существующие схемы и правила выполнения тех или иных рабочих процессов, а также может включать рекомендации по их изменению. Что это дает?
Во-первых, и главное, моделирование помогает увидеть происходящее как систему: охватить одним взглядом сразу всех участников, их работу и взаимосвязи. Такое системное видение необходимо стейкхолдерам для самооценки, понимания своего места и отстройки бизнеса в целом от конкурентов, формирования стратегии развития.
Во-вторых, когда вы рисуете диаграммы бизнес-процессов, вне зависимости от объема исходных данных и глубины погружения в контекст обязательно всплывают новые, не выявленные до сих пор вопросы и нюансы, особенно в части логики и целесообразности. Чем подробнее модель, тем больше скрытых возможностей для улучшения она покажет — полезно отмечать их в комментариях прямо на схемах.
В-третьих, если по запросу заинтересованных лиц или в ходе анализа выяснилось, что необходим реинжиниринг, модель подскажет критерии оптимизации — те количественные и качественные характеристики, которые определяют оценку результатов бизнес-процессов, что конкретно и в какую сторону нужно изменить. Более того, ограничения таких изменений также могут стать понятнее благодаря визуализации.
Если взглянуть на бизнес-моделирование не как на последовательность действий, а с точки зрения его сути, важны, прежде всего, две вещи:
- что делает система (объект, модуль, приложение, комплекс, решение и т. п.);
- как система что-то делает.
Более того, можно воспользоваться еще одним бесценным методом науки — индукцией — и сказать: всё, что мы в принципе можем узнать, анализируя предметную область, объект автоматизации, его бизнес-процессы, возможные способы их оптимизации, средства цифровизации, эффекты внедрения и т. д., — это всё про что и как. Такова природа знания. Именно поэтому анализ бесполезен без изучения динамики: с помощью бизнес-модели мы рассматриваем объекты и системы в действии, во всех четырех измерениях пространства и времени. Модель описывает не просто процесс — регулярный поток работ, повторяющихся с определенной периодичностью, каждая итерация которого может отличаться своими особенностями — например, скоростью, затратами, результатами. Исследуя эти флуктуации, мы видим анализируемое во всем объеме его сложности и взаимосвязей с внешним миром.
