- Вступление
- Ограничения при описании
- Термины и определения
- Параметры проекта
- Обновление конфигурации
- Бизнес цель проекта
- Выбор конфигурации системы
- Ключевой функционал ERP, который сложно внедрять на каждом проекте (по мнению автора)
- Ключевые архитектурные изменения
- Общий подход к управлению запасами
- Предварительные настройки системы
- Замена действий Заказа клиента
- Пример бизнес-процесса
- Оформление Заказа клиента
- Формирование отчета "Анализ заказа клиента"
- Оформление Корректировки заказа клиента
- Оформление Заказа на обеспечение
- Формирование отчета "Анализ заказа на обеспечение"
- Оформление Корректировки заказа на обеспечение
- Рабочее место по обеспечению
- Рабочее место по закупкам
- Изменение подходов к расчету свободного остатка и индикация в отчетах
- Оповещение перед установкой товаров в резерв
- Установка товаров в резерв и оповещение об этом
- Выполнение обмена резервами
- Оформление Перемещения товаров
- Взаимодействие с транспортным отделом
- Оповещение перед снятием товаров с резерва
- Отгрузка товаров клиенту
- Изменение качества товара
Вступление
Все описанное в статье - это субъективное мнение автора исходя из опыта внедрений.
В декабре 2012 года я написал статью по внедрению крупного проекта (//infostart.ru/1c/articles/166856/). На тот момент это был мой первый опыт внедрения такого масштабного проекта в составе большой команды и хотелось поделиться этим опытом.
С тех пор прошло больше 10 лет, за это время я принял участие в проектах по автоматизации разных предприятий и функциональных областей. На каждом проекте было разработано что-то интересное, но эти доработки в большей степени были применимы только на конкретных проектах.
В 2021 году начали проект в дистрибьюторской компании. Имея большой опыт внедрения УПП, периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобно, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала). После завершения этого проекта появилось желание написать статью.
От желания до публикации прошел год :)
Ограничения при описании
В статье описываются доработки, реализованные в рамках автоматизации дистрибьюторской деятельности компании, без производственной части. Описание в статье приведено в объеме достаточном для концептуального понимания бизнес-процесса и выполненных доработок (статья и так получилась очень большой).
Если будет интерес к каким-то отдельным механизмам, то отвечу в комментариях.
Термины и определения
- Склад потребности – склад, с которого планируется отгрузка товара клиенту;
- Склад резерва – склад, где физически находится товар;
- ЗнО – Документ «Заказ на обеспечение». Ключевой объект системы, который является разрезом обеспечения. Вся функциональность, связанная с обеспечением что была в документе «Заказ клиента» вынесена в него.
- Доступный остаток – остаток товара на складе, который не распределен ни одному заказу и его можно отгрузить «сейчас».
- Группа обеспечения - разрез в рамках, которого объединяются разные склады для решения задач обеспечения. Например, «Склады МСК», «Склады ЕКБ», «Склады ДВ» и т.д
- Настройка обеспечения – настройка, в которой для каждой группы обеспечения указывается в каком порядке и на каких группах обеспечения система должна автоматически выполнять поиск доступных складских остатков.
- Сигнальное событие – событие, которое требует участие специалиста отдела логистики, для определения варианта обеспечения потребности.
- Состояние обеспечения – состояние в системе обеспечения, по которому понятно какого товара достаточно, а какого нет.
- Обеспечить – потребность необходимо закупить или произвести (полноценное производство или просто сборка товаров);
- Обеспечен на складе – потребность сопоставилась с доступным остатком на складе;
- Обеспечен к дате – потребность, сопоставленная с доступным ожидаемым поступлением (заказ поставщику, заказ на перемещение, производство, сборка);
Параметры проекта
- Срок проекта (Февраль 2021 по Июнь 2022)
- Февраль по Апрель 2021 – обследование и моделирование;
- Май 2021 по Март 2022 – проектирование, разработка, тестирование, тестовая миграция данных;
- Апрель 2022 АД :), работа всех пользователей в новой системе;
- Май 2022 стабилизация;
- С Июнь 2022 поддержка и развитие системы.
- Команда проекта ИТ
- Руководитель проекта
- Архитектор по финансам (взаиморасчеты, казначейство, упр. учет по методике Заказчика);
- Архитектор по продажам, логистике;
- Архитектор по закупам и транспорту;
- Аналитики – 3 чел.;
- Разработчики по функционалу – 4 чел.;
- Разработчики по интеграциям и загрузке остатков – 4 чел.;
- Ключевые бизнес-пользователи Заказчика – 20 чел.
- Переход в одну базу с нескольких систем, в которых работали от 10 до 15 лет.
- Axapta – 1 база;
- 1С самописная – 7 баз
- 1С на базе УТ 10.3 – 1 база
- Среднее количество одновременно работающих пользователей в одной базе ERP: 450.
Обновление конфигурации
Конфигурация обновляемая;
В июне 2023 года выполнили обновление с релиза 2.5.7.279 на 2.5.12.48 (почти 2 года не обновляли не было необходимости). Все затраты на подготовку обновления, тестирование, обновление рабочей базы и исправление ошибок после обновления составили 597 часов (1 человек 100% и 4 человека не 100% в течение 1,5 месяцев).
Бизнес цель проекта
Повысить оперативность информации, качество данных и бизнес-процессов для принятия управленческих решений.
Выбор конфигурации системы
В начале обследования Заказчиком рассматривались отдельные три базы ERP, УХ и Документооборот. По результатам обследования остановились на одной базе ERP. В начале обследования не было даже бета релиза 2.5.7, но понимание уже было, что к моменту начала разработки хотя бы бета версия уже будет. В результате не имея конфигурации, но представляя по презентациям с форума 1С приняли решение, что будем использовать 2.5.7, т.к. архитектура функционала по обеспечению подходила лучше. К концу обследования релиз 2.5.7 уже появился.
Ключевой функционал ERP, который сложно внедрять на каждом проекте (по мнению автора)
Тут опишу только ключевой функционал, который очень сложно внедрять на каждом проекте. На самом деле по мелочам его на порядок больше, но хочется остановиться именно на фундаментальных моментах, которые вызывают сложности при внедрении.
- Выполнение корректировок заказов в самих заказах; (тут принципиальный методический момент, в УПП как раз использовались отдельные документы). Есть история версий заказов, но, когда нужно собрать разные отчеты по корректировкам заказов, версиями уже не обойтись;
- Обеспечение внутри заказов. Это отдельная боль, она в 2.5.7 стала чуть лучше, за счет того, что «К обеспечению» не приводит к разбиванию строк документа, но с точки зрения наглядности данных и производительности решение все же не удачное.
Например, заказ клиента. На больших предприятиях сотрудники не занимаются массово ручной установкой действия "Резервировать на складе" это делает система автоматически. И тут начинаются проблемы. Заказ клиента мог быть на 50 строк, а после резервирования уже на 500 строк. В результате теряется наглядность, возникают ошибки округления.
К производительности отдельный большой вопрос. Например, есть ходовая позиция товара, которая встречается в 1000 заказов клиентов, товар пришел на склад и согласно бизнес-процессу нужно этот товар зарезервировать в 1000 заказах клиентов. Делается это автоматически и если использовать типовой функционал, то нужно обработать все 1000 заказов, где-то разбить строки и перепровести их. Команда разработки ERP не любит сравнение с УПП, но в УПП достаточно было ввести один документ «Резервирование товаров» и в таб. части перечислить все 1000 заказов. Разниц