Концепт проекта решения бизнес-задач. Что это и как его подготовить?

Когда вы задумываетесь о проекте автоматизации, то хотите решить какую-то конкретную задачу или нацелены на развитие ИТ в широком плане?

Именно это мы уточняем первым делом, начиная общение с каждым новым клиентом. Выясняем характер запроса.

Примеры широких запросов (когда нет привязки к конкретной бизнес-задаче):

• Внедрить «1С:ERP»
• Сменить старую платформу ИТ-системы на новую
• Реализовать комплексное развитие ИТ-системы (например, чтобы не отставать от конкурентов)

Примеры узких запросов (когда привязка к конкретной бизнес-задаче есть):

• Автоматизировать учет на производстве для обеспечения прослеживаемости
• Повысить клиентский сервис
• Посчитать достоверную фактическую себестоимость

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

Мы часто встречаем истории, когда при старте автоматизации этап разработки концепта был упущен. Решили автоматизировать производство, взяли продукт и начали внедрять. А когда на выходе получили какой-то результат, осознали, что хотели-то вообще другого. Концепт необходим, чтобы договориться. Это еще не детальное описание бизнес-процессов, но уже достаточно точное понимание предстоящего проекта.

1. Формулировка бизнес-задачи или нескольких бизнес-задач через вопрос «зачем»
Клиент: «Хотим автоматизировать производство».
Мы: «Зачем»?
Клиент: «Хотим иметь оперативные данные о том, что происходит в производстве».
Мы: «Зачем»?
Клиент: «Хотим в оперативном режиме контролировать отклонения технологических параметров производства для контроля за качеством продукции».

Такой короткой чередой вопросов мы пришли к тому, что автоматизация производства необходима клиенту для обеспечения оперативного контроля производственных процессов в целях обеспечения качества продукции.

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

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


3. Определение организационных и логических границ проекта
Исходя из целей ИТ проекта необходимо определить организационные (перечень подразделений) и логические границы проекта.
Например, если мы автоматизируем производство, то начальная логическая граница – это приемка сырья и передача его на производство со склада ТМЦ. Конечная – передача упакованного готового продукта на склад готовой продукции.
При этом планирование заявки на производство остается за границами проекта в системе планирования. А задача планирования по рабочим центрам на основании полученной заявки на производство решается внутри задачи автоматизации производства.


4. Определение перечня функций ИТ системы
Если на прошлом шаге мы очертили границы, то теперь мы внутри определяем, какие функции должны быть в системе. Важно: мы не прорабатываем бизнес-процессы детально. Мы определяем список функций для того, чтобы оценить масштаб проекта.
Опять же, если мы говорим про проект автоматизации производства, то одной из значимых составляющих является определение состава учетных точек на производстве и выполняемых на них операций.


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


6. Укрупненное описание списка организационных изменений, необходимых для обеспечения работоспособности автоматизированной системы
К таким могут относиться, например, выявление новых ролей/должностей на предприятии.
Как правило, новая система несет в себе новые функции, и мы должны понимать, кто эти функции будет выполнять – текущие или новые сотрудники. Поэтому здесь возможно появление новых людей, либо назначение новых функциональных обязанностей тем, кто уже работает.


7. Определение технических условий для обеспечения работоспособности системы
Какое оборудование и техника нам понадобятся? (Проводные/беспроводные каналы связи, промышленные компьютеры, учетное оборудование и т.д.)


8. Разработка план-графика проекта
На основании всего вышеописанного выбираем технологию реализации проекта и разрабатываем план-график с наложением необходимых ресурсов как функциональных специалистов, так и ИТ специалистов для обеспечения проекта.


9. Расчет бюджета проекта


10. Определение необходимых ИТ ресурсов для обеспечения поддержки внедренной системы
Чем больше систем мы внедряем, тем больше усилий нужно на их поддержку. Соответственно еще на этапе проектирования проекта мы должны понять, какие ИТ ресурсы нам будут необходимы для поддержки этой ИТ системы, чтобы заранее заложить их в предстоящие затраты.


11. Расчет окупаемости и целесообразности инвестиций в проект*
Расчет окупаемости инвестиций – это отдельный комплексный вопрос, в котором все не так однозначно. На практике чаще всего есть бизнес заказчик (профильный директор по направлению), который четко понимает, зачем ему нужен тот или иной проект. И если такое необходимо, именно он делает оценку окупаемости проекта. Ситуация, когда оценку окупаемости делает интегратор из позиции «убедить клиента в необходимости делать проект», в нашей практике встречается редко. Но у нас по этому поводу есть мысли и мы готовы их обсуждать. Где-нибудь в кулуарах (например, на нашей конференции «Цифровизация пищевой отрасли – 2023»).

В разработке концепта проекта должны участвовать люди, которые имеют личный практический опыт выполнения подобного рода проектов. Если концепт будет построен на основании только теоретических гипотез, в нем может появиться большое количество невидимых подводных камней, которые люди с опытом обошли бы заранее.

На практике проработка этих пунктов применительно к конкретному проекту занимает от 1 до 3 недель.

Кажется очевидным, что разработка концепта является необходимым стартовым этапом для любого проекта. Странно начинать проект без ответа на те вопросы, которые мы описали выше. При этом всегда есть два варианта: делать концепт самим или с привлечением внешнего партнера.

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

И даже если у вас есть сильный внутренний ИТ отдел, который имеет опыт разработки похожих систем и который хорошо знает бизнес, мы тем не менее рекомендуем вам привлекать для разработки концепта внешний ресурс. Таким образом вы получите альтернативное мнение «второго доктора» в противовес своему (подобного рода решения всегда несут в себе большую долю субъективного мнения эксперта).

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

Отраслевая экспертиза в данном случае – это про точность.