Спецпроекты

О разработке ERP-системы с нуля и под себя

Маркет

В основе современного бизнеса лежат принципы полной цифровизации и автоматизации. О разработке ERP-системы с нуля рассказывает Илья Агошков, партнер и CTO Fibbee.

Что такое для нас ERP

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

Как мы разрабатывали свою ERP

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

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

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

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

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

Функции ERP, которые важны для нас

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

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

Во-вторых, в ERP содержатся рецепты всех наших напитков в том виде, в котором ими удобно управлять нашему бариста, но с учетом ограничений накладываемых возможностями кофемашины, которую мы используем. Мы даем возможность клиентам настраивать вкус напитка под себя сделать его более кофейным или более молочным, но для того, чтобы быть уверенными, что вкус останется на нужном нам уровне, мы каждую из возможных настроек должны точно задать в наших рецептах в терминах, которые можно транслировать в понятные настройки напитка для кофемашины. Например, в некоторых случаях, когда пользователь настраивает свой напиток в сторону «больше кофе/меньше молока», это означает, что мы добавим в напиток дополнительный шот эспрессо. На уровне рецепта мы также задаем такие параметры, как толщина кофейной таблетки, количество воды для пролива, усилие темперовки, предсмачивание, паузы перед проливами, температура молока и т. д., то есть мы полностью на уровне конфигурации напитка в нашей ERP задаем рецепт для напитка. Это обеспечивает нам повторяемость вкуса на каждой точке.

В-третьих, в ERP хранится конфигурации доступных в каждом конкретном комплексе напитков (меню), их цен, локальных промо акций и т.д.

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

В-пятых, наша ERP имеет мобильное API для нашего мобильного приложения. Из приложения заказ попадает в ERP, а оттуда уже в конкретный комплекс.

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

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

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



Комментарии