gifts2017

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

Опубликовал Павел Пчелинцев (papche) в раздел Управление - Теория учета

В статье приводится опыт внедрения УТ11 в розничной сети.
Приведено решение двух задач позаказного обеспечения розничной точки:
1. Перемещение товара со «Склада обеспечения» на «Розничный склад» по схеме «под заказ».
2. Закупка товара «под заказ клиента» на «Склад обеспечения» и дальнейшее его перемещение на «Розничный склад».
Приведенное решение максимально использует типовую схему работы конфигурации Управление торговлей (11.1.9), но потребовало доработки ряда документов.

Описание

  1. Торговая компания занимается оптовой и розничной торговлей плиткой. Компания состоит из нескольких юридических лиц. Документы создаются в одной управленческой базе. Розничная сеть состоит из 40 розничных точек, с базой постоянно работают 70 пользователей. Потребительский спрос на товары фирмы имеет сезонный характер.
  2. Товар хранится на множестве складов. Склады разделены по функциям (Рисунок 1):
    1. «Розничные склады», которые используются для отгрузки розничным покупателям. Причем за каждой розничной точкой закреплен определенный «Розничный склад» (обычно располагается на относительно небольшом расстоянии от розничной точки). Длительное хранение на «Розничных складах» не используется: в основном на складе хранятся заказанные клиентами товары, а также некоторое количество высокооборачиваемых товаров;
    2. «Склады обеспечения», которые используются всеми торговыми точками для обеспечения товарами «под заказ». Также со «Складов обеспечения» разрешена прямая отгрузка определенным подразделениям (оптовая и розничная продажа).
Рисунок 1. Структура складов компании

Рисунок 1. Структура складов компании

  1. В случае отсутствия товара на «Складах обеспечения» розничные подразделения размещают заявку на закупку. Обработкой заявок на закупку занимается отдел логистики: ответственный за определенную группу товара логист производит анализ возможности осуществления поставки (поставщики, сроки, стоимость), согласует поставку с розничной точкой.
  2. Поступления товаров от поставщиков осуществляются, в основном, на «Склады обеспечения», но в некоторых случаях поставка возможна и на «розничные склады». Выбор склада поступления товара происходит непосредственно перед поставкой (Рисунок 2).
Рисунок 2. Схема товародвижения от поставщика к клиенту

Рисунок 2. Схема товародвижения от поставщика к клиенту

Выявленные проблемы

В результате проведенного анализа работы информационной системы было выявлено две основные проблемы:

  1. Используемая в компании программа «Торговля и Склад» 1С:Предприятие 7.7 (ТиС) перестала справляться с объемом производимых операций. Стали учащаться проблемы с производительностью: блокировки базы, «зависания», медленная работа.
  2. Полуручной режим снабжения товара не соответствует масштабам бизнеса компании и требует построения новой системы. К примеру, оповещение о поступлении (или перемещении) заказанных позиций происходило вне системы: заказанный под определенных заказ товар мог быть перемещен или продан по другому заказу или доставлен не в срок.

Выбор решения

  1. Поскольку сотрудники компании уже давно используют программные продукты 1С, а ТиС, в целом, хорошо зарекомендовал себя на практике, руководство компании предложило провести подбор подходящего решения из линейки программных продуктов Фирмы 1С.
  2. До начала проекта был проведен анализ предложений фирм партнеров 1С, а также поставлена задача разработки комплексного проекта по выбору и внедрению новой Системы на платформе 1С.
  3. В результате проведенного руководством анализа предложений был выбран план проекта нашей фирмы, который содержал следующие пункты:
    1. В качестве базовой конфигурации для внедрения было предложено решение «Управление торговлей» редакции 11.1 (далее «Управление торговлей» или УТ11);
    2. До начала этапа разработки подрядчиком должна быть продемонстрирована возможность осуществления 90% основных операций, осуществляемых на ТиС;
    3. Должен быть разработан детальный план работ по доработке конфигурации и добавлению в нее необходимых функций;
    4. До начала внедрения должна быть завершена разработка конфигурации, перенесены остатки, проведено обучение.

Задачи проекта

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

Задача 1. Перемещение товара со «Склада обеспечения» на «Розничный склад» по схеме «под заказ» (Рисунок 3):

  1. Необходимо обеспечить резервирование товара, находящегося в наличии на «Складе обеспечения», «под заказ клиента»;
  2. Необходимо обеспечить перемещение зарезервированного на «Складе обеспечения» на «Розничный склад», с которого производится отгрузка.
Рисунок 3. Схема товародвижения по обеспечению заказа клиента без закупки товара

Рисунок 3. Схема товародвижения по обеспечению заказа клиента без закупки товара

Задача 2. Необходимо обеспечить закупку товара «под заказ клиента» на «Склад обеспечения» и дальнейшее его перемещение на «Розничный склад» (Рисунок 4)

Необходимо обеспечить возможность закупки товара у поставщика «под заказ» на «Склад обеспечения»;

Необходимо обеспечить перемещение товара, поступившего от поставщика «под заказ» со склада поступления на «Розничный склад».

Рисунок 4. Схема товародвижения по обеспечению заказа клиента с закупкой товара у поставщика

Рисунок 4. Схема товародвижения по обеспечению заказа клиента с закупкой товара у поставщика

Задача 3.Необходимо обеспечить информирование продавца о состоянии товародвижения по каждому товару (трекинг по каждой строке Заказа).

Методология внедрения

  1. Для разработки оптимального решения поставленных задач была создана подробная модель хозяйственных операций.
  2. Для моделирования использовалась типовая конфигурация «Управление торговлей» (11.1.9.51), произведен анализ установки различных функциональных опций, наиболее полно соответствующих хозяйственной модели предприятия.
  3. Стратегия разработки бизнес-схем и конфигурации:
    1. При разработке учетных и бизнес-схем использовалась стратегия максимально полного использования типового функционала и минимизации доработок конфигурации;
    2. При выявлении потребности в доработке конфигурации использовалась стратегия минимизации модификации типовых объектов с целью сохранения возможности обновления конфигурации (или отдельных подсистем).

Моделирование в типовой конфигурации УТ11

Задача 1. Перемещение товара со «Склада обеспечения» на «Розничный склад» «под заказ»

  1. Типовая схема, предлагаемая методологией УТ11, при формировании «Заказа клиента» предполагает резервирование товара только на складе отгрузки.
  2. Однако данную задачу можно решить созданием пары логически связанных документов: «Заказ клиента» и «Заказ на перемещение», последний и создает резерв на складе (Рисунок 5).
Рисунок 5. Обеспечение заказа при наличии товара на «Складах обеспечения» (типовая схема УТ11)

Рисунок 5. Обеспечение заказа при наличии товара на «Складах обеспечения» (типовая схема УТ11)

Помимо неудобств, связанных с оформлением дополнительного документа, у данной схемы есть и ряд недостатков:

  • Выписка Заказа клиента и резервирование товара на «Складах обеспечения» разделены во времени и по функциям. За выписку Заказа ответственным является менеджер по продажам, а за Заказ на перемещение предполагается ответственным логист (или снабженец);
  • Резервирование товара происходит документом «Заказ на перемещение», отследить под какой Заказ производится перемещение товара становится затруднительным, что приводит к сложностям в управлении резервами и надежности в выполнении обязательств по Заказу;
  • В Системе не предусмотрен наглядный интерфейс, который позволил бы сформировать Заказы на перемещение по конкретному Заказу клиента. Типовая обработка формирования Заказов на перемещение (по потребностям) предполагает жесткую настройку схем товародвижения (единый «Склад обеспечения», а не совокупность складов).

Задача 2. Необходимо обеспечить закупку товара «под заказ клиента» на «Склад обеспечения» и дальнейшее его перемещение на «Розничный склад»

Типовая схема, предлагаемая методологией УТ11, предполагает использование специальной схемы товародвижения, названной «обособленное обеспечения заказа»: заказ формирует потребность, а при поставке товара по каждой строке Заказа поставщику указывается его назначение – Заказ клиента, для которого предназначена поставка. Данная схема жестко связывает заказ клиента, заказ поставщика и продажу, гарантируя таким образом продажу товара исключительно по данному Заказу (Рисунок 6). Ограничением данной схемы является необходимость поставки только на склад, указанный в заказе, с которого будет осуществляться отгрузка клиенту. Второе ограничение – отсутствие возможности перемещать заказанный «под заказ» товар между складами.

Рисунок 5. Обеспечение заказа при наличии товара на «Складах обеспечения» (типовая схема УТ11)

Рисунок 6. Типовая схема обеспечения заказа путем поставки товара от поставщика на «Склад обеспечения»

Задача 3.Необходимо обеспечить информирование продавца о состоянии товародвижения по каждому товару (трекинг по каждой строке Заказа)

В УТ11 предусмотрена обработка – «Состояние обеспечения заказов» (Рисунок 7). Обработка является рабочим местом логиста (снабженца) и позволяет управлять резервами заказов (данную обработку возможно вызвать также непосредственно из Заказа клиента). Также предусмотрен отчет «Товарный календарь», который позволяет спланировать приход и расход товара по дням и рассчитать планируемые товарные остатки. Однако, детальное информирование о состоянии товародвижения по строке заказа не предусмотрено.

Рисунок 7. Обработка «Состояние обеспечения Заказа» (типовая)

Рисунок 7. Обработка «Состояние обеспечения Заказа» (типовая)

Выводы

  1. Для решения Задач данного проекта был проведен анализ типовой конфигурации УТ11 и был сделан вывод о возможности модификации конфигурации, используя существующую структуру учетных регистров.
  2. В качестве основной схемы товародвижения выбрана схема с обособленным обеспечением заказа, причем обособленное обеспечение действует как для закупки товара у поставщика, так и при перемещении товара между собственными складами.
  3. Информирование о состоянии товародвижения было решено сделать с помощью динамически рассчитываемого статуса в форме Заказа клиента, а также в журнале Заказов, чтобы менеджер, отвечающий за отгрузку, в любой момент мог информировать клиента о состоянии заказа, и мог предпринять необходимые действия (отгрузить поступивший товар).

Разработка решения

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

В части схемы обеспечения товара были переработаны и разработаны:

  1. Заказ клиента.
  2. Разработаны специальные «мастера» (специальных форм-обработок) для формирования Заказа поставщику и Заказов на перемещение.

Документы Заказ поставщику, Поступление товаров, Заказ на перемещение, Перемещение и Расходная накладная были переработаны, в основном в части логики проведения, процедур ввода на основании и заполнения с помощью «мастеров».

Для мониторинга и управления товародвижением разработана система динамически рассчитываемых статусов (Рисунок 8).

Рисунок 8. Статусы «Состояние обеспечения» при товародвижении

Рисунок 8. Статусы «Состояние обеспечения» при товародвижении

Заказ клиента

В ходе проекта была разработана специальная форма Заказа клиента.

Рисунок 9. Заказ клиента

Рисунок 9. Заказ клиента

Заказ клиента был модифицирован таким образом, чтобы по каждой строке Заказа менеджер мог зарезервировать товар на любом «Складе обеспечения», а также оформить Заявку на «Заказ поставщику». Склад отгрузки («Розничный склад») при этом указывается отдельно (Рисунок 9).

  1. На рассмотренном примере менеджер указал для строк 2,3,5 определенный «Склад обеспечения», а для строк 1,4 – сделал заявку на Заказ поставщику (указатели 1 и 2 на рисунке 9).
  2. В поле «Отгрузка с» Заказа выбран определенный «Розничный склад» (указатель 3 на рисунке 9).
  3. Состояния товародвижения по каждой строке менеджер может увидеть в том числе непосредственно в форме Заказа (указатели 4 и 5 на рисунке 9).
Рисунок 10. Заказ клиента в процессе исполнения

Рисунок 10. Заказ клиента в процессе исполнения

На Рисунке 10 приведен пример Заказа, который уже обработан отделом логистики:

  1. Часть товара уже закуплена и привезена на склад (указатель 1 на рисунке 10);
  2. Другая часть товара заказана (указатель 2 на рисунке 10, создан подтвержденный Заказ поставщику);
  3. Другая часть товара находится в процессе перемещения между складами (указатель 3 на рисунке 10).

Поскольку по каждой строке Заказа, возможно, происходит своя цепочка, весьма актуальным оказалось доработать Систему с тем, чтобы возможно было отследить всю цепочку товародвижения из любого документа цепочки (Рисунок 11): из Заказа клиента, Заказа поставщику и т.д.

Рисунок 11. Структура подчиненности

Рисунок 11. Структура подчиненности

Для мониторинга товародвижения в Журнале заказов добавлен динамически рассчитываемый статус «Состояние обеспечения» (Рисунок 12).

Рисунок 12. Журнал «Заказы клиентов»

Рисунок 12. Журнал «Заказы клиентов»

Состояние обеспечения по каждой строке Заказа можно посмотреть из Журнала, нажав на кнопку «Состояние обеспечения» (Рисунок 13).

Рисунок 13. Форма «Состояние обеспечения»

Рисунок 13. Форма «Состояние обеспечения»

Формирование Заказа поставщику

Для формирования Заказа поставщику «под Заказ клиента» были разработаны две схемы:

  1. Ввод на основании Заказ клиента (для разовых закупок «под заказ»);
  2. Заполнение Заказа поставщику с помощью специальной – «Мастер по заявкам клиентов» – для регулярных поставок от поставщика, когда поставка товара происходит как под различные заказы клиентов, так и для пополнения складских запасов («под склад»).

«Мастер по заявкам клиентов» функционально идентичен типовой обработке «Формирование заказов по потребностям», однако адаптирован специально для целей данного проекта (Рисунок 14).

Рисунок 14.Мастер формирования Заказа поставщику по заявкам клиентов

Рисунок 14.Мастер формирования Заказа поставщику по заявкам клиентов

Данная обработка позволяет:

  1. отобрать список необработанных заявок на поставку (Рисунок 14, указатель 1);
  2. установить в заявках на поставку фактический склад поступления (склад поступления определяет логист непосредственно при утверждении Заказа поставщику, Рисунок 14, указатели 2 и 3)

Формирование Заказов на перемещение

После поступления товара на «Склад обеспечения» возникает необходимость развезти его по «Розничным складам» и сформировать «Заказы на перемещение». В Системе было разработано два варианта осуществления данной функции:

  1. Ввод на основании Заказ клиента;
  2. Пакетное формирование «Заказов на перемещение» с помощью специальной обработки «Формирование заказов на перемещение» (Рисунок 15).
Рисунок 15 Пакетное формирование Заказов на перемещение

Рисунок 15 Пакетное формирование Заказов на перемещение

Данная обработка позволяет сформировать «Заказы на перемещение» из журнала Заказов поставщику по выделенному списку Заказов.

Внедрение

Проект можно условно разделить на следующие основные этапы:

  1. Моделирование Системы, утверждение основных этапов и технологической концепции проекта (2 недели);
  2. Разработка решения и подготовка миграции данных с 1С77 (6 недель);
  3. Обучение персонала (непосредственно перед запуском). Для пользователей была развернута тестовая база с текущими остатками (2 дня);
  4. Запуск Системы произошел в первый рабочий день 2015 года;
  5. Поддержка пользователей (1,2,3 –линия поддержки), параллельная доработка схемы (4 недели);
  6. Поддержка пользователей (3 –линия поддержки, 4 недели).

Команда проекта состояла из Руководителя проекта (Москва) и двух программистов (Регионы). Коммуникация с Заказчиком происходила лично и по скайпу. Разработка велась удаленно на серверах Заказчика.

Результаты проекта

Основным результатом проекта, как это банально не звучит, является ввод в эксплуатацию современной Системы управления предприятием – «1С:Управление торговлей» вместе со всеми ее функциональными и технологическими возможностями, подробно описанные на сайте Фирмы 1С.

Обычно, переход на новую Систему управления предприятием происходит раз в 5-10 лет и является в жизни любого предприятия ключевым. Такое событие возможно сравнить с переездом семьи в новый собственный дом: поменялось расположение розеток, светильников, санузлов и много чего еще, появились новые функции, а некоторые старые изменились и еще нужно к ним «приспособиться».

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

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

Об экономических результатах говорить пока что преждевременно – слишком мало времени прошло с момента запуска Системы. Но можно смело утверждать, что к началу сезона бизнес сможет на 100% использовать преимущества отлаженного механизма обеспечения товара.

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Сергей (Che) Коцюра (CheBurator) 08.03.15 01:27
Спасибо!
Отличный материал - и полезный, и интересный.
2. Сергей (Che) Коцюра (CheBurator) 08.03.15 01:28
3. Сергей (Che) Коцюра (CheBurator) 08.03.15 01:36
Собственно вопросы:

1. возле рис.9 "Заказ клиента был модифицирован таким образом, чтобы по каждой строке Заказа менеджер мог зарезервировать товар на любом «Складе обеспечения»" - менеджер насколько сильно РУКАМи участвует в "резервировании на любом складе обеспечения" - или в основном это рассчитывается и подтавляется автоматом (через мастера) ..?

2. там же - насколько автоматизировано оформление заявки на Заказ поставщику? как выбираются поставщики? - по прихоти менеджера? )полу)автоматом по каким-то критериям? иначе как-то?
4. Александр Зубцов (iov) 08.03.15 01:40
аналогичную задачу решал только заказы формировались со склада на розничной точке + на складах и других розничных точках + в заказах поставщику + под заказ на обеспечение. И самое главное товары разных групп со своими правилами обеспечения ))).
А и оплата как пожелает клиент - хоть сусликами.
5. Maxim Goncharov (maxx) 08.03.15 12:39
Отличный отчет

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

6. Павел Пчелинцев (papche) 08.03.15 13:17
(3) CheBurator, спасибо за интерес и отзыв!
По сути:
1. В форме подбора (доработанной стандартной) отображаются остатки по складам обеспечения (их 5 шт), продавец сам решает где резервировать. Другой логики не заложено и не требовалось.
2. Логист работает с определенными товарными группами и поставщиками. Собственно выбор поставщика не автоматизирован.
Сам бизнес-процесс для фирмы новый, пока идет притирка (административная), через пару-тройку месяцев можно подумать да совершенствованием Системы.
7. Павел Пчелинцев (papche) 08.03.15 13:27
(5) maxx, спасибо!
1. Трудозатраты проекта - 4 человеко-месяца вместе в внедрением и обучением, собственно разработка - 2 чел мес.
Там не только логистика была, еще и расчет зарплаты и еще по мелочи...
2. 70 постоянных пользователей (в тексте было), обучение в группах (5 потоков).
3. Доработки практически завершены. Выпущено 70 сборок. Через пару недель, вероятно, будут новые требования..
8. Константин Юрин (kostyaomsk) 08.03.15 15:04
Интересно про автоматизацию складов. Главное иллюстрированно. Тоже требует вдумчивого чтения.
9. Maxim Goncharov (maxx) 09.03.15 16:14
(7) То есть получается, проект в часов 600

Просто хочу понять стоимость и сроки внедрения УТ 11 для серьезных торговых компаний, у которых бизнес-процессы основные налажены в другом софте (той же 7.7.), и понимают , что им надо переходить на новые системы решая старые проблемы, не теряя при этом ничего что были и как багаж приобретая ещё кучу нового, что за годы сообщество придумало.
10. Сергей Маслов (LexSeIch) 10.03.15 06:20
Мир этому дому!
Интересная статья. Особенно порадовало оформление и аккуратность предоставления материала. Автору плюс.
11. Сергей (Che) Коцюра (CheBurator) 10.03.15 20:38
Весьма странно что мало отзывов и комментариев
Либо ут11 никому не интересна
Либо она настолько улачная что все есть и все всем понятно
12. Александр T (AlexAuto) 11.03.15 11:25
рис.11 а если в заказе 100-200 позиций это как же будет выглядеть структура подчиненности???
13. Павел Пчелинцев (papche) 11.03.15 13:49
(12) AlexAuto,
Очень эффектно будет выглядеть, как будто внутри джунглей амазонки оказался ))
Если серьезно - проблемы в этом не наблюдается пока что...
14. Александр T (AlexAuto) 11.03.15 15:00
(13) Проблемы начнутся в процессе работы когда "портянка" из документов в структуре будет листа на три ))) и в этих джунглях надо разобраться ...
15. Сергей Ярцев (SerLeon) 08.12.15 00:37
По поводу задач 1 и 2, все-таки мне кажется проще дать возможность менеджерам самостоятельно вводить заказ на перемещение (с некоторыми ограничениями - только по обособленным позициям в заказе клиента), логика следующая: при формировании заказа клиента, менджер решает как будет обеспечиваться заказ, если нужен заказ поставщику - он ставит назначение обособленно, если нужно зарезервировать товар на другом складе и впоследствии переместить - ставит обособленно и тут же создает на основании заказ на перемещение. Опять же в заказе на перемещение товар можно зарезервировать на складе или поставить обособленно (тогда он будет заказан у поставщика отделом закупок).
Такая схема не требует особых доработок заказа клиента (для удобства можно вывести таблицу остатков по всем складам, которая заполняется при выделении строки заказа или добавить в панель навигации заказа отчет и т.д.)
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа