Реальная автоматизация мебельного производства

Компания на момент обращения: 10 салонов продаж, головной офис в разных зданиях с производством, итого 25 пользователей 1С.

Какие проблемы испытывали перед обращением.

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

2. Продавцы могли менять цену товара по своему усмотрению;

3. Информацию о продажах передавали продавцы через мессенджер;

4. Расчет зарплаты производственного персонала производился в таблицах Google вручную, что отнимало время у мастера производства и бухгалтера;

5. Отгрузку вели в ПО “Мой склад”, которая в годовом выражении  обходилась дороже, чем 1С:Фреш;

6. Человеческий фактор при работе в нескольких информационных системах, а именно несвоевременные заказы материалов и отгрузки.

Какие цели преследовали при внедрении 1С:УНФ в облаках?

1. Сокращение годового бюджета на программное обеспечение; 

2. Работа всех подразделений компании в едином информационном пространстве;

3. Устранение человеческого фактора при работе производства, отдела закупок, продаж и бухгалтерии;

4. Независимость работы салонов продаж от головного офиса.

Совместно с представителем заказчика сформировали команду разработки и понеслось….

Ход проекта поэтапно (или что было доработано)

1. Вначале были добавлены пользователи из числа сотрудников офиса и салонов продаж для формирования и обработки заказов покупателей. Попробовали, понравилось, вот только цену было неудобно устанавливать, так как в совокупности было около 20 наименований готовой продукции, которые имели от 4 до 6 вариантов размеров и от 6 до 8 вариантов опций, таких как ткань, подъемный механизм, стяжка изголовья, обычные или скошенные углы, оформление пуговицами или стразами и т.д. Перед нами встал вопрос “Как формировать цену на готовую продукцию?”

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

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

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

Поэтому решили отказаться от типового функционала и сделать Универсальные характеристики под параметрические спецификации.

1. Универсальные характеристики под параметрические спецификации: Вначале мы сделали тестовую параметрическую спецификацию и столкнулись с ограничением типового функционала формирования цены готовой продукции, то есть параметры спецификации не влияли на конечную цену. Поэтому мы решили доработать функционал посредством добавления справочников характеристик. Данная разработка была затруднена тем, что делалась для сервиса 1С:Фреш, и мы справились. 

Как это работает? Продавец в салоне создает заказ покупателя, выбирает готовую продукцию из справочника номенклатуры, выбирает характеристику размера, а опции готовой продукции поместили в соседних колонках, заполнение которых в свою очередь работало по аналогии с типовым функционалом. В результате, при проведении заказа создавалась типовая характеристика номенклатуры. 

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

Дополнительно потребовалось доработать складские акты для проведения инвентаризаций в разрезе характеристик готовой продукции.

1. Итак: у нас есть продажи, есть спецификации заказа готовой продукции, как же нам ее изготовить? Воспользоваться типовым функционалом Выполнения этапов, - скажете Вы. 

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

А что если одновременно по спецификации делается несколько операций, например, раскрой и шитье тканей и распил и сборка каркасов, в то время как типовой функционал позволяет выполнять операции последовательно? А что если каркас мы собрали неделю назад и ждем поступления тканей?

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

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

При сканировании этапа производства списывались материалы и начислялась заработная плата.

1. Итак, у нас работают продажи и производство, начисляется сдельная заработная плата. Остаются закупки, так как логист все еще мог забыть заказать ткань. Решили пойти таким путем: всю номенклатуру разделили на 2 категории, та, которая заказывается под заказ покупателя и та, которая требует поддержания складского остатка. Ну а дальше дело техники.

Мы сделали 2 регламентных задания. Одно проверяло остаток на основном складе плюс резервы и соответствие минимальному складскому остатку. Если остаток меньше - дозаказывало до максимального.

Другое смотрит на номенклатуру, которая закупается под заказ покупателя, формирует документ Заказ поставщику на количество ткани из спецификации и отправляет письмо поставщику. Менеджер по закупкам стоит в копии письма.

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

Итог проекта: 

• сокращение издержек на ПО, так как цена 1С УНФ в рамках сервиса 1С:Фреш по сравнению с ПО “Мой склад” ощутимо ниже, что привело к экономии;

• снижение простоев производства по причине несвоевременной закупки материалов;

• снижение издержек в связи с самоуправством продавцов;

• сокращение времени на оформление заказа покупателя;

• автоматизация производства.