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

Бизнес-аналитики начинают с погружения в повседневную работу сотрудников. Например, в одном из проектов, связанных с закупочными процедурами, аналитики выяснили, что исполнители вынуждены вручную дублировать одни и те же данные в двух разных системах – SAP и специализированном ПО. Эта проблема не лежала на поверхности, но именно она съедала сотни человеко-часов в месяц. Только после того, как аналитики докопались до истинной причины, родилось правильное решение – настроить интеграцию между системами.

Руководители и эксперты бизнеса обычно говорят о целях, эффектах, удобстве. Разработчики же мыслят функциями, интерфейсами, базами данных. Без переводчика между ними проект обречён на недопонимание.

Бизнес-аналитик берёт на себя эту роль. Он формализует потребности бизнеса в виде чётких требований – функциональных и нефункциональных, – которые можно проверить и измерить. Это как чертёж для строителя: без него дом может получиться кривым, даже если все кирпичи отличные.

Цифровые проекты стоят дорого. Инвестиционный комитет не выделит миллиарды рублей, если не увидит понятного экономического обоснования.

Здесь бизнес-аналитик выступает в роли финансиста. Он строит организационно-экономическую модель (ОЭМ), в которой рассчитывает, какие физические изменения принесёт проект (сокращение времени, снижение потерь, рост производительности) и как эти изменения конвертируются в деньги. Он различает прямой эффект (снижение затрат) и косвенный (высвобождение времени сотрудников), а также оценивает риски. Благодаря этой модели компания может принимать взвешенные решения о том, какие проекты запускать в первую очередь.

Разработчики и бизнес-пользователи часто говорят на разных языках. Бизнес-аналитик вводит в этот диалог наглядные схемы бизнес-процессов – например, в нотациях EPC или BPMN. На такой схеме видно, кто что делает, в какой последовательности, какие данные передаются и где используются информационные системы.

Эти схемы становятся «общей картой» для всех участников проекта. Когда появляется спорная ситуация, все смотрят на одну и ту же схему и находят компромисс гораздо быстрее.

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

Он проверяет, достигнуты ли ключевые показатели эффективности (КПЭ): активны ли пользователи, заполнены ли системы данными, сократились ли трудозатраты. Если что-то идёт не так, аналитик выявляет причины и предлагает корректирующие меры. Только так можно быть уверенным, что обещанные 50 миллиардов рублей экономии действительно получены.

Исходная ситуация

Газовый сбыт компании был «завязан» на SAP. Из-за санкций существовал реальный риск, что зарубежный вендор прекратит поддержку, и тогда торговать газом станет просто невозможно.

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

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

Команда аналитиков провела интервью с ключевыми стейкхолдерами, изучила экранные формы СЭД и ПО, проанализировала структуру Excel-отчётов. На основе этого аналитики разработали BPMN-схемы «как есть» и «как должно быть», а затем сформулировали требования к интеграции СЭД и ПО.

Закупочные процессы вели в двух системах: основная информация – в SAP, а постановка и контроль задач – в специализированном ПО. Исполнители вынуждены были дублировать одни и те же данные, а из-за нерегулярного заполнения второстепенной системы руководители не видели актуального статуса процессов.

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

Оборудование стареет, подвержено коррозии, но компания не имела инструментов для прогнозирования отказов. Данные о состоянии оборудования были разрознены, часть хранилась на бумаге, а диагностика проводилась без учёта реального технического состояния.

Аналитики провели бенчмаркинг: изучили зарубежный и отечественный опыт внедрения RBI (Risk-Based Inspection) в нефтегазовых компаниях, включая публикации и отраслевые журналы. Для каждой из 10 дочерних компаний они построили дерево КПЭ и финансово-экономическую модель, рассчитали эффекты и инвестиционные показатели.

В компании не было единого подхода к управлению проектами. Большинство проектов (2-й и 3-й категорий) отслеживались в Excel, Project и Outlook – «ручное» управление требовало бесконечных созвонов и уточнений. Охват системой управления проектами составлял лишь 6% от общего числа проектов.

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