Блог

Как проект с внедрением IBM Planning Analytics в агробизнесе привел к созданию стартапа

История о том, как детальное понимание проблем клиента, помогло команде Планум найти нестандартное решение, оформить его в продукт, еще и заработать.

Вместо предисловия

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

Разработка первых прототипов велась еще за 7 лет до описанных событий. Прототипы применялись к задачам клиентов из разных сегментов бизнеса. У каждого клиента были свои особенности построения бизнес-процессов, на основании которых мы вносили постоянные доработки. Так постепенно наращивался функционал продукта.

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

А если это необходимо, то давайте продавать.
Наша компания изначально оказывала консалтинговые услуги в сфере автоматизации управления результатами бизнеса, внедрением комплексных систем планирования на предприятии, автоматизации сбора и анализа отчетности, — в общем, мы внедряли системы, которые позволяют собственникам и менеджменту бизнеса осуществлять эффективный контроль за движением денежных средств и исполнением производственных программ, а также оперативно принимать решения.
В тот раз мы проводили интеграцию системы IBM Planning Analytics для одного крупного агрокомплекса. Бизнес клиента быстро рос и менеджмент уже ощущал необходимость автоматизации финансовых функций в организации, в том числе установки специализированных систем планирования, бюджетирования и аналитики.
Систему мы внедряли приблизительно год. Это стандартный срок для полноценного внедрения любой крупной системы без косяков. За этот срок необходимо провести аудит всех имеющихся систем, описать существующие бизнес-процессы и взаимосвязи между организационными единицами, разработать план оптимизации и проект будущей архитектуры, согласовать со всеми сопричастными лицами, прописать все в системе, провести первую интеграцию, проверить, доработать и обучить сотрудников клиента с ней взаимодействовать. Только этап с обучением может длиться порядка трех месяцев.
В итоге клиент был счастлив и доволен. Однако без «но» не обошлось.

Неповоротливость системы

Клиент занимается растениеводством. Это значит, что затраты на выращивание культур накапливаются весь вегетативный период, и списываются только, когда продукт созрел, прошел обработку и готов к дальнейшей продаже. У разных культур разный период созревания, который, ко всему прочему, зависит от множества факторов, в числе которых есть и непредсказуемые погодные условия. Кроме этого, объем объемов готовой продукции может значительно отличаться от объемов выращенной культуры, после сортировки и обработки.
Клиент поставил задачу автоматизировать процесс стратегического верхнеуровневого планирования, чтобы можно было “поиграться” с данными и спрогнозировать основные результаты деятельности в различных сценариях с различными вводными условиями, установленными Top-Down*. Так как система на базе Planning Analytics была разработана по методике планирования Bottom-Up*, удовлетворить запрос клиента в текущем решении было непросто. Да и в целом, для задач с постоянным изменением справочников и формул IBM довольно неповоротлив. В итоге на тот момент клиенту комфортно это было сделать в классическом Excel.
Однако комфортно не значит эффективно. У клиента оставались проблемы со сведением плановых данных, хранением и контролем версий документов, централизованным управлением данными, а также пошел первый разрыв с контуром IBM.

Ограниченные возможности для полноценного обмена данными

Клиент использует несколько кредитных линий, и в договоре с банком был пункт о необходимости предоставления регулярной отчетности, операционных и финансовых планов и бюджетов компании. Клиент должен был предоставлять все сопроводительные документы в виде финансовых моделей в Excel, где можно было бы отследить все расчеты, формулы, показатели. Вот здесь и появились первые вопросики к IBM Planning Analytics.
Например, установленная система ограничивала возможности выгрузок в Excel. Ну как, она давала возможность скачать данные в табличный формат. xls, но хардом, без формул. Банку же такой вариант не подходил.
В итоге ответственный сотрудник проставлял вручную все формулы, сверял все с системой, и только после этого направлял отчет кредитору. К слову, там был не один лист, а значит сотрудник терял пару дней, выполняя эту работу.

Риск существенного увеличения затрат

Еще одна проблема выявилась в ходе знакомства с предыдущей. Оказалось, что этап заполнения финансовых таблиц и бюджетов в Excel после установки системы планирования IBM Planning Analytics никуда не исчез.
Например, многие сотрудники использовали таблицы Excel для своих дополнительных вычислений внутри отдела. Переносить эти наработки в IBM было довольно затратно, так как формализовать, настроить, протестировать и поддерживать – все это дополнительные часы работы консультантов и программистов, а значит и дополнительные расходы компании. Поэтому достаточное количество корпоративных данных хранилось непосредственно в файлах Excel. Показатели утверждались внутри отдела и только потом переносились в систему Planning Analytics.

Внедрение решения и оформление его в самостоятельный продукт

Устранение проблем клиента в существующей архитектуре системы было крайне затруднительно, поэтому мы решили внедрить нашу платформу Планум, которая тогда еще даже не имела рабочего названия.
Платформа значительно упростила работу с моделями Excel, сделав их динамичными, масштабируемыми и интегрируемыми с внешним контуром, в том числе и с IBM. Любые изменения в моделях (формулы, структура или данные) моментально становились доступны всем пользователям, что позволило сильно повысить систематизацию процесса. Планум полностью взял на себя задачи, которые не ложились в логику текущего решения на базе Planning Analytics и позволил автоматизировать формирование верхнеуровнего стратегического плана с учетом особенностей ведения хозяйственной деятельности клиента (при этом данные можно было вводить как обобщенно так и в детализации).

Почему клиент был счастлив во второй раз?

Во-первых
Наша платформа работает полностью на базе Excel, что для клиента было чрезвычайно важно. Можно было свободно добавлять новые элементы затрат, продукцию и прочие аналитики. Легко добавлялись формулы, создавались полностью кастомные модели с централизованной базой данных и единой структурой. В общем, когда в процессе задействовано множество факторов, которые сложно предусмотреть в начале, Excel остается единственным гибким решением для аналитики. Как ни крути.
Во-вторых
Поступление данных в систему можно было отслеживать в реальном времени. Это позволяло видеть весь процесс целиком, своевременно вносить необходимые корректировки, прогнозы в нескольких сценариях или использовать анализ «что, если» на новых данных.
Все исторические версии документов хранились на сервере, поэтому авторизованные пользователи могли вернуться к показателям недельной давности, например, и сравнить их с текущими. Сотрудникам больше не приходилось хранить множество документов с похожими наименованиями, которые только и отличаются, что припиской «версия от такого-то числа».
В-третьих
Используя платформу клиент мог отстроить полноценную модель бизнеса, где учитывались производственные показатели, затраты, цены, объемы реализации. В итоге всю деятельность бизнеса можно было в любой день привести к одному показателю (если хотите, то можно и к нескольким), который отслеживает менеджмент.
В-четвертых
Платформа интегрировалась с любыми сторонними системами за счет REST API, что позволило наладить полноценный обмен данными между Планумом, IBM и 1С. Пользователи продолжали оформлять планы как им удобно, банк получал данные в той форме, которая требовалась, а интеграция объединяла все это в единую логическую модель.

Мораль

Этот текст был изначально задуман, чтобы показать, что классика стартапов не всегда работает. Создание MVP может быть оправдано либо для массовых продуктов, либо для сферы, где разработчики являются новичками. Да, у команды может быть классная идея, но в силу отсутствия опыта и понимания рынка, ее необходимо протестировать. И в этом случае это оправдано, по крайней мере, чтобы не тратить время и деньги на разработку продукта, на который не будет спроса.
В нашем случае это было не так. По сути, на рынок мы вышли с готовым продуктом, у которого уже был широкий функционал. Но в нашем сегменте, в финансовой аналитике, по-другому и не возможно. Если команда не понимает, чем живет отдел планирования, как работает отдел бухгалтерии, какая у них нагрузка, какие задачи у финансового директора, в чем особенности учета на том или ином предприятии, то успешный старт будет слишком амбициозной задачей.
Если вас заинтересовали конкретные метрики проекта, то можете посмотреть их тут.
2023-05-31 17:30