Решения на базе технологий ИИ: как сократить стоимость проекта?
Новые реалии подталкивают российский бизнес не только к замене западных технологий, но и к пересмотру парадигмы бизнес-планирования в целом. Нестабильность экономической ситуации, нарушение привычных цепей поставок, стремительный рост количества данных стимулируют интерес компаний к платформам для бизнес-планирования, которые работают на базе AI/ML. Этот интерес вполне закономерен. Интеллектуальные платформы обеспечивают более высокое качество прогнозирования и уровня сервиса, способствуют сокращению затрат на управление цепями поставок, снижению зависимости от экспертизы специалистов и, как следствие, уменьшению трудозатрат. Они умеют решать различные задачи – прогнозирования, оптимизации, сценарного планирования – качественнее и быстрее, освобождая сотрудников от рутинных операций.
Для многих участников рынка внедрение платформ бизнес-планирования (IBP) на основе AI/ML– принципиально новый опыт, хотя, на рынке уже есть компании, которые успешно применяют их на практике. “Новичков” часто пугает цена вопроса, хотя вопреки распространенному мнению, интеллектуальные платформы стоят не дороже традиционных, а ценности бизнесу приносят намного больше. К тому же бюджет проекта можно существенно оптимизировать, если правильно организовать процесс. Чем больше факторов мы учтем на стадии анализа и дизайна, тем меньше удорожающих корректировок придется вносить на стадии внедрения.
Как минимизировать бюджет на старте и подготовиться к проекту, чтобы процесс внедрения шел в запланированных рамках?
Структурировать видение и ожидания от целевого бизнес-процесса
Представьте сквозной бизнес-процесс, в который вовлечены несколько отделов, например, промо-планирование. Специалисты по планированию, менеджеры торгового маркетинга, финансисты, ИТ команда – все участвуют в процессе в разной степени, но часто никак не связаны друг с другом ни линейными руководителями, ни KPIs. В штатном режиме процесс может работать, но ни у одного участника нет целостного понимания общей картины, не говоря уже о какой-либо документации. Перед тем, как начинать внедрение, придется осознать и описать существующий процесс, а также решить, каким образом компания готова его автоматизировать: как есть с минимальными улучшениями или необходима полноценная работа по реинжинирингу.
Безусловно, реинжиниринг процессов – это естественный компонент любого ИТ-проекта, но так или иначе он влияет на сроки. Поэтому, прежде чем начинать работу, желательно четко представлять тот процесс, который нужно автоматизировать и интеллектуализировать. Это существенно облегчит жизнь разработчикам, ускорит внедрение и снизит финальную стоимость проекта.
Привести данные в порядок
Своевременная ревизия различных данных, включая мастер-данные, которые будут «питать» будущую платформу планирования, − не менее важный фактор для снижения ее стоимости. В одном из наших проектов требовалось загрузить в систему продажи с полки в ключевых торговых сетях (изначально задача состояла в том, чтобы с помощью алгоритмов машинного обучения вычислить корреляцию между отгрузками от производителя на склад торговой сети и продажами с полки). Но данные по продажам оказались в разных форматах: что-то было доступно в Excel, что-то нужно было скачивать со специального портала ритейлера и т. д. И вместо того, чтобы решить не самую сложную задачу и двинуться дальше, нам вместе с заказчиком пришлось заниматься унификацией форматов входящих данных, по сути – перестройкой внутреннего процесса компании.
Эту работу желательно делать до подачи данных в “машину”, иначе каждый раз, рассчитывая прогноз, команде придется грузить их “руками”. Такой путь увеличивает не только стоимость внедрения, но и стоимость владения системой, то есть затраты на запуск, регулярную лицензионную и техническую поддержку решения. Если необходимые для системы данные не формализованы, их качество неоднородно, есть ошибки и несоответствия – лучше устранять эти проблемы до начала проекта. Делать это в процессе внедрения можно, но тогда дополнительных затрат не избежать.
Выбрать приоритетные данные
Любые платформы интегрированного бизнес-планирования ( традиционные и интеллектуальные) питаются большим количеством входящих данных. Чем больше в системе модулей и логик, тем больше данных можно применить. Начиная проект, некоторые заказчики стремятся загрузить в систему максимальное количество факторов: исторические продажи, промо-планы, скачки цен, погоду, уровень запасов, затраты на рекламу, макроэкономические показатели и т.д. Так, безусловно, можно, но выйдет дороже, сложнее и дольше. И не факт, что все эти данные повлияют на качество прогноза.
Один из наших клиентов, для которого мы разрабатывали решение для оптимизации планирования сырья, выбрал сложный подход к формированию бизнес-логики. Этот подход включал десятки ограничений, таких как мощности производственных линий, допустимые схемы перемещений сырья между площадками и другие. Большой объем входящих данных существенно увеличил и сроки, и стоимость проекта, хотя получать пользу от инструмента можно было и с меньшим функционалом.
Для запуска базовой версии платформы мы обычно советуем сосредоточиться на тех источниках, которые способствуют решению основных бизнес-задач. И уже на следующем этапе развития платформы – продумывать и внедрять новые ограничения, к примеру, логистические, или расширять горизонты планирования.
Оставаться в контуре проекта
Контур проекта определяется на этапе анализа и дизайна. Заказчик решает, какой именно функционал он хочет получить и какой бизнес-процесс нужно интеллектуализировать. Под этот контур исполнитель выделяет ресурсы и рассчитывает стоимость. Однако в процессе внедрения заказчик может осознать, что какой-то функционал (которого не было в изначальном ТЗ) тоже был бы полезен. Иногда доработки вполне логичны для достижения лучшего результата, но бывает и по-другому: команда клиента “фонтанирует” идеями, которые не критичны, а скорее желательны, и тратить на них дополнительное время и бюджет нецелесообразно.
В одном проекте мы вместе с заказчиком потратили много времени на продумывание и настройку функционала workflow (логика, согласование планов) с учетом множества условий. В итоге после запуска решения персонал пользуется только частью разработанного функционала, и этого достаточно для нормального функционирования процесса.
Для оптимизации бюджета желательно отступать от изначального контура проекта в исключительных случаях.
Организовать содействие исполнителю на всех уровнях
Проекты по запуску сложных решений, особенно с ИИ, требуют высокого уровня вовлечения внутренней команды в лице владельцев процесса, руководителя проекта и ИТ команды. Каждый из участников имеет критически важное значение, и у каждого своя роль. Многие думают, что если у проекта есть “спонсор” (обычно это топ-менеджер, принимающий решения и распоряжающийся бюджетом) – то этого вполне достаточно, чтобы всё шло гладко и без проблем. Это не совсем так. В одной из компаний мы долго не понимали, почему сотрудники ИТ-департамента не шли на контакт и игнорировали наши запросы на доступ к базам и внутренним системам. Оказалось, что им никто не объяснил, зачем этот проект нужен компании и какой эффект они получат от автоматизации.
Мотивация команды – ответственность проджект-менеджера. Но его задача состоит не только в том, чтобы объяснять сотрудникам важность преобразований, разрабатывать план и назначать встречи. Этот человек должен управлять ожиданиями всех стейкхолдеров, поддерживать коммуникации между исполнителем и заказчиком, контролировать качество и сроки работ, держать команду в тонусе и т. д. Если он не имеет опыта управления большими трансформационными проектами или не заинтересован в результате, удержаться в намеченных рамках будет сложно.
Избегать параллелизации нескольких проектов
Требование внедрять несколько блоков одновременно сильно увеличивает нагрузку на всю проектную команду, снижает ее эффективность и увеличивает стоимость в разы. Если сроки не поджимают, лучше внедрять модули последовательно, а не параллельно.
Не стоит также в процессе внедрения IBP-решения затевать трансформацию связанных с ним систем, например, ERP. Один из наших заказчиков в ходе проекта решил заодно поменять и базу данных, из которой наша платформа черпала данные. Соответственно, нам как исполнителю пришлось переписывать часть архитектуры платформы за короткое время до планового запуска. Проект затянулся и вышел за рамки бюджета.
Два и более трансформационных проекта одновременно – это риск провалить сразу все, не говоря об увеличении бюджета и сроков, а также о критической перегрузке всех вовлеченных команд.
Избегать жестких дедлайнов
Последние два года мы все чаще слышим фразу: «Завтра, а лучше вчера». Фактор срочности – плохой помощник для оптимизации бюджета, но если завтра карета превратится в тыкву (система перестанет работать), то деваться некуда: приходится идти на дополнительные траты, чтобы не застопорить весь бизнес. «Подгонять» проект может также цикличность бизнес-процессов (нужно успеть к началу нового цикла) или наличие общекорпоративной дорожной карты по трансформации бизнеса (сдвиг одного из этапов приведет к перекосу всего плана). Такие вводные часто являются императивом, не предполагающим обсуждения, однако они порождают ряд рисков и увеличивают бюджет. В итоге почти в ста процентах случаев эти риски материализуются, и сроки все равно сдвигаются.
Какова бы ни была причина жесткого дедлайна, нужно понимать, что исполнитель не всегда может физически в него уложиться, даже если увеличить команду в разы и работать 24 часа в сутки, поэтому обе стороны должны трезво взвесить все “за” и “против” прежде, чем подписаться на проект с несдвигаемым дедлайном.
