О разработке ERP-системы с нуля и под себя
Маркет
17.11.2020, Вт, 13:52, Мск
В основе современного бизнеса лежат принципы полной цифровизации и автоматизации. О разработке 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, строим различную отчетность по продажам/марже/прогнозу расходов ингредиентов и т.д.
Как видно, из перечисленных выше шести функций пять функций очень специфичны именно для нас, тесно интегрированы с нашим железом, и готовых решений тут просто нет. А последняя функция с построением отчетов настолько тривиальна в реализации, что ради нее ставить какую-то чужеродную систему и пытаться ее интегрировать с нашим ПО не имело смысла. Быстрее было самим сделать модуль отчетности.
Получившаяся система заточена под нас, мы можем развивать ее самостоятельно, без привлечения вендора, в нужном нам направлении, и мы не зависим от стратегии вендора и сроков выпуска новой версии коробочного ПО.
Полный текст статьи читайте на CNews
