Целевая ИТ структура, к которой мы стремились, выглядела так:
Центральной системой становится единая 1С:УНФ. В неё поступают заказы из 3 источников:
• Розничные заказы с сайта - из RetailCRM
• Оптовые заказы вносятся оптовыми менеджерами сразу в УНФ
• Заказы с маркетплейсов поступают из модуля интеграции

Для удобства менеджеров и работы с логистической картой, все заказы обратным переносом попадают в RetailCRM.

После обследования стало понятно, что не все процессы идеально отражаются в методиках 1С:УНФ, и множественные интеграции требовали тестирования. Мы создали полноценную тестовую среду для того, чтобы можно было смоделировать отрисованные процессы на копии системы.
Мы настроили тестовую базу 1С:УНФ, а также развернули тестовые копии всех сопутствующих систем: Ритейл ЦРМ, сайта, всех бухгалтерских баз и даже сделали тестовый личный кабинет маркетплейса. Это позволяло тестировать всю систему ещё на этапе моделирования и устранять ошибки, не дожидаясь перехода в промышленную эксплуатацию.

Первое, что нам потребовалось для моделирования - это перенос нормативно-справочной информации: номенклатуры, спецификаций и контрагентов. Мы помним, что у нас было две системы 1С:УНФ, которые не дружили между собой. Для формирования единой НСИ потребовалась большая работа со стороны команды проекта заказчика. Они подготовили справочники так, что в разных базах у одинаковых товаров совпали артикулы, и их удалось сопоставить.
Мы стали моделировать в базе процесс за процессом и тщательно фиксировали все функциональные разрывы, которые возникали в ходе работы. Одним из них стала работа логистической службы. Дело в том, что логистическая служба привыкла работать с заказами на карте в программе “Управление торговой логистикой”, которая работала в связке с WMS системой. А теперь маршрутизацию заказов на карте предстояло формировать в модуле маршрутизации в RetailCRM. Проблема в том, что в RetailCRM нет понятия маршрутных листов и нет управления доставкой, весь этот блок остался на стороне 1С:УНФ.
Для решения задачи мы сделали передачу в заказе из Ритейла поля Курьер. По этому полю в 1С:УНФ могут формироваться маршрутные листы по рейсу, который шагом ранее был сделан на стороне Ритейла. А дальше - полностью типовая функциональность 1С:УНФ: пакетная отгрузка заказов и формирование Расходной накладной, отчёт о доставке по каждому заказу.

В компании несколько каналов продаж: опт, продажи с сайта, маркетплейсы и агентские продажи. Каждый из них отличается от других на уровне бизнес-процесса. Например, продажи через маркетплейсы - это комиссионная торговля, а опт и сайт должны сопровождаться Расходными накладными. Помимо этого, в каждом из этих каналов есть свои менеджеры и своя система мотивации.
Мы разделили продажи по видам заказов, расположив в каждом свои списки состояний и интегрировали их с РитейлЦРМ. А ещё автоматизировали расчёт бонусов для менеджеров:
• КПИ за выполнение плана менеджером
• КПИ за заказы через социальные сети
• Бонус за продажи новым клиентам.

Настроили процесс управления ценами через статические и динамические виды цен (когда один вид цен зависит от другого по проценту или формуле).
Настроили резервирование товаров на складе и выгрузку остатков в RetailCRM


В результате, по продажам
• Менеджеры работают в RetailCRM в режиме одного окна
• При этом они видят актуальные свободные остатки товаров
• Менеджеры видят все заказы с их актуальными статусами как в RetailCRM, так и в 1С:УНФ
• Руководитель получил возможность автоматически расчитывать бонусы менеджерам в зависимости от результатов их работы

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

Для корректного отражения процессов мы сделали склад адресным и ордерным. Ордерный — значит, что документы движения товаров по складу отделяются от документов управленческого учёта, образуя отдельный контур. Адресный — значит, что у каждого товара, который хранится на складе, появляется ячейка, в которой он лежит. При поступлении товара кладовщик размещает его в конкретную ячейку, а при подборе знает, куда за ним идти. При отгрузке кладовщик сканирует ячейку, товар, и так для каждой строки - вероятность ошибки минимальна!
Во внедрении процессов ТСД помог внешний модуль, который мы интегрировали в работу системы.

А для отражения процесса логистики идеально подошёл модуль управления доставкой в 1С:УНФ. Готовые к доставке заказы логист располагает на логистической карте в RetailCRM и назначает курьера, который передаётся в 1С:УНФ. Далее же всё просто - по дате доставки и курьеру заказы собираются в единый Маршрутный лист, из которого пакетно создаются и печатаются все отгрузочные документы, а заодно меняются состояния заказа.
Заказы в новом состоянии попадают на склад, где их подбирают и формруют расходные ордера на те товары, которые отгуржены в машину.
А далее идёт отчёт о доставке, где каждый водитель отчитывается о доставке и приёме оплат по каждому заказу.

В результате:
• процесс приёмки стал быстрее и удобнее для сотрудников склада
• Автоматизировано формирование маршрутных листов и отгрузочных документов
• Кладовщики пользуются только ТСД и не заходят в базу.
• При подборе товара кладовщики видят, в какой ячейке есть подходящие товары и сканируют ячейки и каждую единицу товара.
• Весь товар на складе оснастили штрихкодами, минимизировав ошибки персонала.

Структура себестоимости выпуска, по соображениям Андрея и его финансиста, должна была состоять из затрат:
• Прямых материальных (материалы, которые непосредственно относятся к выпуску дивана)
• Прямых нематериальных (сдельная оплата рабочим)
• Косвенных материальных (расходные материалы производства)
• Косвенных нематериальных (внешние услуги, аренда производственных площадей, коммуналка и тд)

Для реализации такой структуры потребовалось, в первую очередь, выверить производственные спецификации на продукцию, указав в них не только точное количество материалов, но и нормочасы на каждую операцию по производству. Этот огромный труд лёг на плечи производственного блока и потребовал много времени.
Для того, чтобы в выпуске учитывались не только материальные затраты, но и начислялась зарплата (и отражались нематериальные затраты), нужно формировать документ "Сдельный наряд” и назначать исполнителей для каждой операции выпуска.

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

В результате:
• Отражается корректная фактическая себестоимость выпусков
• Можно посчитать плановую себестоимость изделия до его выпуска, чтобы назначить корректную розничную цену
• Автоматизирован расчёт сдельной оплаты труда рабочим

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

Мы использовали механизм Анализ бизнеса вместе с детальной проработкой плана счетов в программе. Разделили весь справочник номенклатуры на категории, каждой из которых присвоили свой счёт учёта запасов, и таким образом в Управленческом балансе стали видны не просто “запасы”, а детализация их по видам.

Далее, мы разделили всю выручку на части по видам продаж:
• Маркетплейсы
• Оптовые отгрузки
• Розница и сайт
• Продажи принципалов
• Услуги и прочие продажи

Каждую из них мы вывели в отчёт по анализу бизнеса.


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

В результате
• Финансовая отчётность по форме компании “по клику”
• Отчётность формируется на основании оперативных данных, без экселя
• Настройка плана счетов позволяет видеть отчёты с нужной степенью детализации

Интеграции — одна из интересных вещей в проекте, хотя бы за счёт их количества и взаимосвязей.

Интеграция с сайтом
Сайт на CMS InSales обладает функциональностью обмена CommerceML и может на своей стороне принимать информацию из обмена с 1С. Это дало возможность настроить выгрузку товаров из 1С:УНФ.

Чем обмениваемся:
• Товары, структура каталога - и 1С:УНФ на сайт
• Цены
• Остатки

Интеграция с RetailCRM
Чем обмениваемся:
• заказы, двусторонний обмен товарами, статусами, полем “курьер”
• Остатки, односторонний обмен из 1С:1С:УНФ в RetailCRM
• Виды цен
• Менеджеры
• Доставки
• Оплаты, стороны обмена зависят от типа оплаты

C интеграцией товаров с RetailCRM пришлось побороться. Раньше номенклатура синхронизировалась в RetailCRM из одной из баз 1С:УНФ. Теперь же номенклатура интегрируется из 1С на сайт, а затем с сайта - в ритейлЦРМ. Важно при этом, чтобы потом, при переносе заказов из РитейлЦРМ в 1С:УНФ, эта номенклатура, которая “вернулась, сделав круг”, была узнана в 1С. Эту задачку с многими неизвестными удалось решить с помощью уникальных идентификаторов номенклатуры - ГУИД. Они стали тем уникальным ключом, по которому все системы узнают, что это за позиция, и работают без сбоев.

Интеграция с маркетплейсами
Когда работаешь с несколькими маркетплейсами сразу по системе FBS (товары отгружаются со склада продавца по заказам покупателя), и при этом количество товаров ограничено, важно использовать систему резервирования для своевременной корректировки остатков. Так, если заказ пришёл из одного маркетплейса и встал в резерв, то свободный остаток товаров тут же должен уменьшиться на других маркетплейсах. Этого невозможно достичь без модулей интеграции с автоматическим обменом остатками и заказами.

Маркетплейсы:
• Яндекс.Маркет
• Озон
• Немного позже - СберМегамаркет
• В планах - Wildberries

Чем обмениваемся:
• Остатки свободные на складе
• Заказы из маркетплейсов, статусы заказов
• Отчёты комиссионера

Интеграция с ТСД
Отдельная система для ТСД нужна в том случае, если процессы склада более сложны, чем предполагает методика 1С:УНФ. В нашем случае это так: Есть отдельные процессы приёмки, размещения и подбора товаров, каждый из которых сопровождается отдельным документом на ТСД и в базе.

Чем обмениваемся:
• Задание на приёмку
• Задание на размещение (перемещение по ячейкам)
• Задание на отбор
• Инвентаризация по ячейкам

И вот, все доработки 1С:УНФ сданы, обучение пользователей проведено, система тестируется клиентом.
День Х - день начала Опытно-промышленной эксплуатации неминуемо приближался. Время было неумолимо, так как начинался высокий сезон, и до его начала нужно было обкатать систему живьём.

Выяснилось, что производство не успело проверить спецификации, а этапы были выделены неправильно, и это не позволяло корректно начислять сдельную зарплату рабочим. Подрядчики по ЦРМ не успели реализовать задачи на своей стороне. Обстановка в проектном чате накалялась.

Что же делать - переносить дату запуска? На сколько? Успеют ли подрядчики на этот раз? Нужно было волевое решение. В дискуссию вступил Андрей. Он тщательно выслушал текущую обстановку на фронте проекта, взвесил все предложения и решил: запускаем проект в ОПЭ без сдвига даты, перенос сроков обойдётся дороже. “Достраивать самолёт будем уже в полёте”, решил он.

Мы выделили двух консультантов, которые должны были в режиме 24/7 две недели мгновенно отвечать на все вопросы пользователей и помогать им. Это были напряжённые две недели, но мы выстояли все вместе и запустили систему в работу!