Неправильный выбор MVP приводит к необходимости его выбросить и все переделать заново. Правильный же выбор, наоборот, позволяет быстро и с минимальными потерями получить отличный результат в условиях сложной динамики рабочей среды.
Подписывайтесь на наш телеграмм канал https://t.me/bit_erp там вы найдете актуальные новости, анонсы, опыт и истории от команды БИТ:ERP.
Как правильно делать MVP при внедрении такого сложного продукта, как 1С:ERP, расскажем на примере внедрения блока "Ценообразование" в крупной торговой организации.
Сразу отметим, что блок ценообразования изначально не выделялся как отдельный и его запуск должен был происходить в рамках запуска блока "Продажи". Это являлось ограничением для нашего MVP, то есть его функциональности должно быть достаточно для запуска блока "Продажи". Это важное замечание, так как заказчик, на этапе внедрения, принял решение существенно изменить действующую систему ценообразования.
Целевая модель, к которой стремились собственники, выглядела не очень сложно:
Единый вид цены, который представлен максимальной ценой за продукцию.
Фиксированные скидки от максимальной цены по каналам продаж.
Дополнительные периодические и разовые скидки, которые назначаются на каналы продаж, контрагентов и номенклатуру.
Цены для сетей рассчитываются отдельно и закрепляются за контрагентом на определенный период.
Но реальность оказалась несколько отличной от целевой модели. А именно:
Установка торговых цен производилась в разрезе ценовых групп - это является ограничением типового функционала.
Торговый прайс представлен большим количеством видов цен, расчет которых отличался от бизнес-единицы к бизнес-единице. И в рамках видов цен использовались разные наценки по ценовым группам.
Цены для сетей устанавливались отдельными документами. Цены были как торговые, так и акционные и имели приоритет над ценами из торгового прайса. Цены имели период действия.
Цены на неликвидные товары устанавливались отдельным документом.
Как таковая, подсистема скидок не использовалась. Скидки могли быть представлены в виде конкретной цены для клиента на определенную ценовую группу/номенклатуру или в виде процента скидки от вида цены, причем процент указывался в самом соглашении с клиентом.
После анализа действующей системы ценообразования стало понятно, что приведение её к целевой модели достаточно трудоемкий процесс, но и запускать 1С:ERP сразу "как есть" тоже не выход. Поэтому приняли решение разработать минимально необходимый функционал для запуска блока "Продажи", без существенного изменения процесса, и уже после его запуска заниматься развитием.
Задачей первой версии MVP было обеспечить заполнение цен в заказе клиента. В его рамках были реализованы следующие фичи:
Загрузка цен из Excel. Причем файлы содержали данные по ценам в разрезе ценовых групп и при загрузке парсились до конкретной номенклатуры. Предварительно потребовалась работа по нормализации НСИ.
Заполнение цен на неликвидные товары в виде скидки на разницу в цене, т.е. завели отдельный вид цен на неликвидные товары и на отклонение от прайсовой цены давали скидку.
Заполнение конкретных цен и скидок контрагентам: реализовали через добавление табличной части в соглашение. Пользователь указывал скидку или конкретную цену по ценовой группе и автоматически заполнялись типовые реквизиты соглашения.
Документ-контейнер для расчета цен по сетям: в документе считались как цены торгового прайса, так и акционные. Рассчитанные цены отражались как фиксированные цены в соглашении с клиентом.
По итогу внедрения MVP 1 получили автоматическое заполнение цен в заказе клиента, но с рядом ограничений:
При добавлении новой номенклатуры или изменении ценовых групп - требуется актуализация цен.
Указание всех цен в соглашении с клиентом, в виде фиксированной цены требует ручного контроля вытеснения цен, то есть на одну и ту же позицию могут одновременно действовать несколько цен, и при сохранении соглашения нужно вручную удалить дубли строк.
Для устранения ограничений и расширения функциональности, в рамках второй версии MVP добавили следующий функционал:
Регламентное задание по актуализации цен при добавлении номенклатуры или изменении ценовых групп. Цену устанавливали единую для всей ценовой группы по заданным видам цен.
Настроили расчет зависимых видов цен. В ERP загружалась минимальная цена, остальные виды рассчитывались. Потребовалось установить наценки для каждого вида цен в разрезе ценовых групп и сразу сделать обработку, которой можно заполнить ставки для всех видов цен, по ценовой группе (новые ценовые группы появлялись редко).
Включили типовой функционал по скидкам, настроили периодические скидки. Теперь пользователи выбирали в соглашении конкретные скидки.
После запуска MVP 2 сохранилось ограничение, связанное с необходимостью контроля вытеснения цен. А так как это в большей степени касалось сетевых клиентов, то в рамках третей версии MVP мы доработали получение цен в заказе клиента.
Если для клиента был создан документ-контейнер с расчетом цен для сетей, то цены брались непосредственно из документа-контейнера, период действия которого совпадал с заказом клиента. То есть получили единую точку расчета цен для сетей. В индивидуальном соглашении указывали только связь с документом контейнером.
Заключение
Как видно, реализация задачи в первичной постановке может не учитывать всей сложности процесса, а попытка сразу реализовать полную функциональность с доработками всех "плюшек" может сильно затормозить процесс внедрения. Это особенно актуально, если запуск блока сильно влияет на другие внедряемые блоки и сам процесс не стабилен с позиции бизнеса. В этом случае лучшим решением будет разработка минимальной рабочей функциональности, которую можно запустить.
Материал подготовила:
Ксения Короткова, Product Owner, БИТ:ERP.
А как вы делаете свои MVP? Пишите в комментариях. Поддержите нас лайками, если материал статьи оказался полезным для вас.
