Почему сдавать ИТ-проект в опытно-промышленную эксплуатацию лучше через бизнес-процесс, а не через функционал

Всем привет! Меня зовут Алексей Бакукин, я старший бизнес-аналитик в дивизионе «Цифровой завод» ГК «Цифра». Из названия понятно, что мы занимаемся проектами цифровизации заводов. Чаще всего эти проекты преследуют две цели:

1. Рост прибыли предприятия за счет уменьшения затрат или увеличения выхода продукции.

2. Упрощение процесса, автоматизация типовых действий (отчет, расчет, дашборд и так далее).

Первая цель — это про коммерческий успех компании. Вторая — про изменение привычной работы ее сотрудников — пользователей нового ПО.

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

Как это — через функционал?

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

1. ТЗ – техническое задание. В нем отражается все, что должна уметь внедряемая система или приложение.

2. ПМИ – программа и методика испытаний. Это документ, в котором говорится, что нужно на внедренном приложении показать, в каком порядке и с каким результатом, чтобы приложение считалось готовым к запуску в эксплуатацию, а проект или этап считался закрытым.

То есть финальный этап перед запуском системы или приложения в опытно-промышленную эксплуатацию (ОПЭ) – это сдача ПМИ.

Существует несколько подходов к подготовке ПМИ. Ну ладно, на практике (на моем опыте) применяют лишь два подхода — через функционал и через бизнес-процессы. Причем в большинстве случаев — через функционал. На основе ТЗ и обследования на предприятии заказчика формируется перечень требований по функционалу к системе. Далее эти требования объединяются в группы/разделы, и на основе этого составляется ПМИ. Сценарий прохождения испытаний пишется по шагам работы с функционалом, полученный результат – действие, заложенное в функционале. То есть, чтобы выйти на опытно-промышленную эксплуатацию, достаточно продемонстрировать, что в системе есть весь функционал, заложенный в ТЗ.

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

В результате, к опытно-промышленной эксплуатации мы подойдем со следующим пулом проблем:

1. Отсутствие понимания, зачем тот или иной функционал нужен в системе.

2. Незнание, как этим функционалом пользоваться в работе, как он на эту работу влияет.

3. Если не отрабатывать рабочий процесс во время внедрения системы, проблемы/замечания никуда не денутся и все равно всплывут, но уже во время ОПЭ. А это уже негатив в квадрате, так как вроде система прошла ПМИ и должна работать без замечаний.

Из-за этого опытно-промышленная эксплуатация может затормозиться — пользователи просто не будут проводить свои рабочие процессы через систему, потому что «не работает» и «непонятно, зачем это нужно». А если и дальше будет формальный подход, и этап ОПЭ будет закрыт просто потому, что система соответствует ТЗ, ее использование в промышленной эксплуатации и достижение коммерческих целей предприятия будут под БОЛЬШИМ вопросом.

В чем польза от демонстрации работы ПО через бизнес-процесс

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

При демонстрации работы внедренной системы через бизнес-процесс пользователям будет видна необходимая им часть производственной картины и роль конкретно их звена для успешного достижения целей этого процесса. Но этим польза этого подхода не ограничивается.

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

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

По результатам демонстрации прохождения пользователей сквозь бизнес-процесс «от» и «до» на основе одного или нескольких примеров можно:

1. Отловить узкие места функционала (например, когда в системе нет возможности совершить требуемое действие).

2. Скорректировать схему бизнес-процесса. В результате отработки часто появляется понимание, что процесс можно оптимизировать, сократив лишние шаги.

3. Спрогнозировать, какой эффект принесет реализация бизнес-процесса в работе, и показать это пользователям. Подготовка и формирование отчета с анализом (не самое увлекательное занятие) за 5 минут вместо нескольких часов — очевидный бонус.

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

1. Система отражает реальный бизнес-процесс с учетом всех оптимизаций.

2. Пользователи сами согласовали этот бизнес-процесс и предварительно протестировали функционал, который его обеспечивает. То есть, от системы их уже не тошнит.

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

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

Однако у подхода есть и недостаток, хотя.. может это и не недостаток. Дело в том, что отталкиваясь от бизнес-процесса при разработке и внедрении, можно упустить какое-то требование к функционалу из технического задания. Но если бизнес-процесс можно пройти и без этого требования, то скорее всего оно и не нужно ;-).