Почему сдавать ИТ-проект в опытно-промышленную эксплуатацию лучше через бизнес-процесс, а не через функционал
Всем привет! Меня зовут Алексей Бакукин, я старший бизнес-аналитик в дивизионе «Цифровой завод» ГК «Цифра». Из названия понятно, что мы занимаемся проектами цифровизации заводов. Чаще всего эти проекты преследуют две цели:
Рост прибыли предприятия за счет уменьшения затрат или увеличения выхода продукции.
Упрощение процесса, автоматизация типовых действий (отчет, расчет, дашборд и так далее).
Первая цель — это про коммерческий успех компании. Вторая — про изменение привычной работы ее сотрудников — пользователей нового ПО.
Бытует мнение, что главное — это реализация первой цели. Только вот если компания действительно ее хочет достичь, то второй целью жертвовать никак нельзя. Обычно, как изменится жизнь сотрудников с внедрением новой системы, объясняют через функционал этой системы. Но на мой взгляд, это не самое эффективное решение задачи. Лучше это делать через бизнес-процесс. Ниже объясню суть метода и почему так правильнее.
Как это — через функционал?
Возьмем усредненный типовой проект внедрения, которым на предприятии занимается компания-подрядчик. В разрезе проекта требуется вести и заполнять груду документов, которые появляются до, во время и на этапе закрытия проекта. В общем, описание всего не имеет смысла, и для уменьшения «воды» оставим только то, что важно для статьи:
ТЗ – техническое задание. В нем отражается все, что должна уметь внедряемая система или приложение.
ПМИ – программа и методика испытаний. Это документ, в котором говорится, что нужно на внедренном приложении показать, в каком порядке и с каким результатом, чтобы приложение считалось готовым к запуску в эксплуатацию, а проект или этап считался закрытым.
То есть финальный этап перед запуском системы или приложения в опытно-промышленную эксплуатацию (ОПЭ) – это сдача ПМИ.
Существует несколько подходов к подготовке ПМИ. Ну ладно, на практике (на моем опыте) применяют лишь два подхода — через функционал и через бизнес-процессы. Причем в большинстве случаев — через функционал. На основе ТЗ и обследования на предприятии заказчика формируется перечень требований по функционалу к системе. Далее эти требования объединяются в группы/разделы, и на основе этого составляется ПМИ. Сценарий прохождения испытаний пишется по шагам работы с функционалом, полученный результат – действие, заложенное в функционале. То есть, чтобы выйти на опытно-промышленную эксплуатацию, достаточно продемонстрировать, что в системе есть весь функционал, заложенный в ТЗ.
Такой подход может создавать сложности для восприятия системы пользователями. Поставим себя на место среднестатистического оператора станка/технолога/доменщика/литейщика/формовщика и еще кого-нибудь, кому в один заход вываливается гора информации по функционалу решения — и для разных пользовательских ролей, и для администратора ПО, и для специалистов по безопасности. Пользователь задаст резонный вопрос: зачем ему все это нужно. Он не увидит общей картины, как в нее вписана его работа и какую пользу конкретно он получит от новой системы. Как следствие, особую заинтересованность в использовании внедренного ПО он вряд ли проявит.
В результате, к опытно-промышленной эксплуатации мы подойдем со следующим пулом проблем:
Отсутствие понимания, зачем тот или иной функционал нужен в системе.
Незнание, как этим функционалом пользоваться в работе, как он на эту работу влияет.
Если не отрабатывать рабочий процесс во время внедрения системы, проблемы/замечания никуда не денутся и все равно всплывут, но уже во время ОПЭ. А это уже негатив в квадрате, так как вроде система прошла ПМИ и должна работать без замечаний.
Из-за этого опытно-промышленная эксплуатация может затормозиться — пользователи просто не будут проводить свои рабочие процессы через систему, потому что «не работает» и «непонятно, зачем это нужно». А если и дальше будет формальный подход, и этап ОПЭ будет закрыт просто потому, что система соответствует ТЗ, ее использование в промышленной эксплуатации и достижение коммерческих целей предприятия будут под БОЛЬШИМ вопросом.
В чем польза от демонстрации работы ПО через бизнес-процесс
Другой подход – составлять ПМИ через сдачу бизнес-процессов. По результатам обследования мы получаем перечень бизнес-процессов, которые описывают деятельность предприятия, и ПМИ формируется уже на основе этих бизнес-процессов. Сценарий прохождения пишется по шагам выполнения процесса. Полученный результат – это результат процесса, в основном — выходной документ или передача информации. Успех прохождения испытаний будет определяться тем, можно ли пройти бизнес-процесс на основе данной системы или нет.
При демонстрации работы внедренной системы через бизнес-процесс пользователям будет видна необходимая им часть производственной картины и роль конкретно их звена для успешного достижения целей этого процесса. Но этим польза этого подхода не ограничивается.
![AS IS AS IS](https://habrastorage.org/getpro/habr/upload_files/4e0/b7d/2be/4e0b7d2befecf1258c9e942fe1e6defa.jpeg)
![TO BE TO BE](https://habrastorage.org/getpro/habr/upload_files/c97/9fb/a9f/c979fba9fb451d8f7eec505aed483730.jpeg)
Еще до того, как дойти до сдачи ПМИ, при внедрении, пользователям обычно демонстрируется все созданное (можно, конечно, ничего не демонстрировать и сразу выходить на ПМИ, но ничем хорошим обычно это не кончается). И по результатам этих промежуточных демонстраций есть возможность отработать с заказчиком все детали бизнес-процесса в ходе конфигурации. Наиболее качественно это можно сделать при демонстрации по конкретным ролям с настроенными политиками безопасности, которые потом и будут использоваться в жизни (а не под учетной записью админа).
Совет: не торопитесь конфигурировать сразу все варианты/примеры/образцы для демонстрации бизнес-процесса, например, все шаблоны анализов, пока вы точно не убедитесь, что бизнес-процесс согласован с заказчиком. Дело в том, что заказчик не всегда может сразу определить свои ожидания от бизнес-процесса. Это значит, что могут быть замечания, и поступать они будут не сразу, а постепенно. Следовательно, если у вас уже все собрано, придется отрабатывать эти изменения по всем созданным примерам. Так что, лучше отработать процесс на одном-двух примерах, а потом уже спокойно тиражировать на все остальные варианты.
По результатам демонстрации прохождения пользователей сквозь бизнес-процесс «от» и «до» на основе одного или нескольких примеров можно:
1. Отловить узкие места функционала (например, когда в системе нет возможности совершить требуемое действие).
2. Скорректировать схему бизнес-процесса. В результате отработки часто появляется понимание, что процесс можно оптимизировать, сократив лишние шаги.
3. Спрогнозировать, какой эффект принесет реализация бизнес-процесса в работе, и показать это пользователям. Подготовка и формирование отчета с анализом (не самое увлекательное занятие) за 5 минут вместо нескольких часов — очевидный бонус.
Отработка замечаний по бизнес-процессу по сути воплощает Agile-подход: пользователям это даст быстрое первое представление о работе с функционалом, а взамен разработчик/интегратор получит адекватную обратную связь, основанную на опыте пользователей. Как следствие, к этапу ОПЭ мы придем со следующими бонусами:
Система отражает реальный бизнес-процесс с учетом всех оптимизаций.
Пользователи сами согласовали этот бизнес-процесс и предварительно протестировали функционал, который его обеспечивает. То есть, от системы их уже не тошнит.
Пользователям очевидны плюсы применения системы в работе в масштабе бизнес-процесса или всего предприятия, и они с бОльшим желанием используют предоставленный им функционал.
Общие вопросы функционирования системы уже отработаны, и проблемы могут возникнуть только при нестандартных ситуациях.
Однако у подхода есть и недостаток, хотя.. может это и не недостаток. Дело в том, что отталкиваясь от бизнес-процесса при разработке и внедрении, можно упустить какое-то требование к функционалу из технического задания. Но если бизнес-процесс можно пройти и без этого требования, то скорее всего оно и не нужно ;-).