8.1 Моделирование бизнес-процесса

Моделирование целевого процесса — этап, на котором разработанное решение приобретает визуальную форму для обсуждения с заказчиком и заинтересованными сторонами. В общем цикле проектирования решения он идёт после выявления первопричин изменений (боли и мотивы заказчика) и анализа текущего решения: далее разрабатывается целевое решение, оно оформляется графически, обсуждается с заказчиком, на основе схемы составляется текстовое описание требований, требования согласуются со всеми заинтересованными сторонами и передаются в разработку. Моделирование бизнес-процессов определяется как процедура создания модели последовательности действий на графическом языке; для целевого процесса чаще всего используется нотация BPMN 2. 0, понятная и бизнес-пользователям, и IT-специалистам и позволяющая зафиксировать системы, в которых будет исполняться функционал.

Альтернативой служит карта сервисного сценария (Service Blueprint), понятная бизнесу и менеджерам, но не дающая системным аналитикам и разработчикам полного понимания процесса, а также CJM — при проектировании целевого процесса она используется для минимизации барьеров клиента, в идеале — их полного отсутствия. При проектировании целевого процесса необходимо учитывать несколько групп аспектов. Цели бизнеса определяют требуемые метрики процесса — время выполнения, количество ошибок и возвратов, уровень клиентской удовлетворённости. Целевая аудитория включает как внутренних клиентов (сотрудников компании), так и внешних пользователей; процесс должен быть понятен и удобен именно для той аудитории, для которой он проектируется — например, процесс для менеджера по продажам должен быть простым и линейным, чтобы не отвлекать его от основной задачи.

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

В финале проектирования бизнес-аналитик проверяет, учтены ли целевые показатели эффективности, требования заинтересованных сторон и потенциальные риски решения.