Содержание:
1. Работа 1С:УПП: автоматизация адресного учета
2. Внедрение адресного учета в программе 1С предприятие УПП: выбор варианта решения задачи
В данной статье я расскажу о своем опыте реализации проекта внедрения адресного учета товаров на складах предприятия в типовой конфигурации «1С:Управление производственным предприятием», а также – как производится настройка 1С:УПП.
1. Работа 1С:УПП: автоматизация адресного учета
В процессе использования конфигурации «Управление производственным предприятием» у Заказчика возникла потребность автоматизировать адресный учет комплектующих и учет готовой продукции в 1С.
Предприятие Заказчика занимается производством различных электронных приборов для автомобилей. К специфике деятельности предприятия можно отнести тот факт, что комплектующими, из которых осуществляется производство готовой продукции, являются однотипные электронные компоненты. Достаточно широкий спектр номенклатуры этих компонентов, их визуальное сходство между собой, однотипная упаковка и маркировка, отличающаяся лишь несколькими символами, - все это приводит к трудностям в работе персонала. Сотрудники склада тратили существенное количество времени на поиск нужных позиций на складе при поступлении заказов из производства. Периодические ошибки приводили к сбоям к графике производства, а в некоторых случаях к производству брака и прямым производственным потерям.
Кроме того, время от времени возникали ситуации, при которых отдельные партии компонентов находились на складе длительное время (т.к. располагались в дальней части склада и сотрудники при комплектации заказов из производства постоянно использовали более новые и более удобно расположенные партии). В результате истекал срок годности компонентов, их приходилось списывать, что приводило к увеличению затрат предприятия.
В связи с этим руководство Заказчика приняло решение о внедрении адресного учета комплектующих (а в дальнейшем и готовой продукции) на складах и автоматизации этого учета в информационной системе предприятия.
1.1. Цели
В 1С:УПП реализация проекта внедрения автоматизированного адресного учета на складах предприятия было обусловлена такими целями:
1. Сокращение количества ошибок при комплектации внутренних заказов не менее чем на 90%, а в идеале свести их к нулю (основная цель).
2. Сокращение времени комплектации внутренних заказов из производства не менее чем на 60% от текущего уровня.
3. Сокращение максимального времени «пролеживания» комплектующих. Реализация фактического расходования комплектующих со склада по методу FIFO.
4. Исключение возможности принятия решений сотрудниками склада «на свое усмотрение», в обход существующей методики при выполнении складских операции.
5. Оптимизация использования складского пространства.
6. Получение в любой момент времени достоверной информации о местонахождении остатков комплектующих на складе (а не только об их количестве). Как следствие сокращение времени проведения инвентаризации на складе на 25%.
Здесь хотелось бы отметить, что изначально цели проекта были сформулированы расплывчато: «навести порядок в работе склада». Однако отсутствие конкретных измеримых показателей, на наш взгляд, таило в себе потенциальную опасность: на завершающей стадии проекта невозможно оценить насколько успешно он был выполнен. Поэтому в процессе обсуждения с Заказчиком цели были переформулированы таким образом, чтобы можно было оценить степень достижения каждой из них. Для каждой цели был определен измеримый показатель (для некоторых достаточно амбициозный). В нашем случае, пользуясь хорошими отношениями с Заказчиком и положительным опытом предыдущего взаимодействия, было отдельно оговорено: что показатели служат сугубо для оценки успешности проекта, и неполное достижение одного или нескольких показателей не являются основанием для непринятия работ. В целом при реализации проектов следует стремиться формулировать измеримые цели, но определять показатели следует очень взвешенно во избежание возможных конфликтов при принятии работ.
1.2. Требования
Заказчиком были выдвинуты следующие требования к разрабатываемой подсистеме:
· Возможность многоуровневой адресации мест хранения на складе. Максимально возможное количество уровней иерархии – три: стеллаж, ярус, ячейка. Возможность алфавитно-цифровой адресации для лучшего визуального восприятия;
· Минимизация ручного ввода информации сотрудниками склада. Все данные, необходимые для оформления операций движения товаров по адресному складу, должны либо вводиться с торгового оборудования (путем считывания соответствующих штрихкодов), либо рассчитываться автоматически самой информационной системой. В частности, адрес ячейки, в которой следует разместить товар или адрес ячейки, из которой следует забрать товар система должна определять автоматически в соответствии с выбранным для данного склада алгоритмом. Такой подход должен позволить сократить количество ошибок пользователей, сократить время на оформление операций, а также подчинить выполняемые действия с товарами на адресном складе четким правилам. (Подробнее о правилах отбора и размещения товаров на адресном складе заказчика, алгоритмах и целях подобного регламентирования будет рассказано далее). Ручной ввод данных в операциях движения товаров по адресному складу допустим в виде исключения (чтобы не тормозить бизнес-процессы при возникновении нестандартных ситуаций). Но все подобные случаи ручного ввода должны быть зафиксированы в системе, для последующего анализа подобных ситуаций и принятия решений об их автоматизации.
· Максимальная интеграция подсистемы адресного учета с используемым торговым оборудованием (сканеры штрихкодов, терминалы сбора данных (ТСД)), как следствие предыдущего пункта. Использование штрихкодов при вводе информации о номенклатуре, количестве, адресе размещения и т.д.
· Минимальные изменения текущих бизнес-процессов предприятия в части складского учета, а также существующих учетных механизмов (регистров). На момент обращения бизнес-процессы оформления, согласования, корректировки торгово-складских документов (внешних и внутренних заказов, накладных на поступление, отгрузку и внутренне перемещение и т.д.) были уже отлажены и в целом устраивали руководство Заказчика. Подсистему адресного хранения необходимо было внедрить отдельным контуром, который бы минимально затронул существующие бизнес-процессы. При этом данные в этом контуре должны полностью коррелироваться с данными типовых учетных механизмов, расхождения недопустимы.
· Максимально плавный и простой для сотрудников переход к использованию механизмов адресного учета.
1.3. Условия и ограничения
В процессе обсуждения Заказчиком были выдвинуты следующие условия по организации проекта внедрения механизмов адресного хранения товаров:
· Возможность поэтапного внедрения механизма. Планировалось постепенно переводить склады предприятия на адресный учет. На разных складах даты начала ведения адресного учета могли различаться. Был определен следующий порядок внедрения:
1. Склад комплектующих;
2. Склад брака;
3. Склад готовой продукции;
При этом на некоторых складах адресный учет не требовался вообще (склад оборудования, склад вспомогательных материалов, склад отходов).
Таким образом, внедряемая подсистема должна предоставлять возможность опционального использование адресного учета на выбранных складах, обеспечивая при этом нормальную работу всех механизмов (например, при перемещении товаров с адресного склада на обычный).
· Контроль вместимости ячеек должен осуществляться на уровне тарных мест (упаковок). То есть следует исходить из предположения, что размеры мест хранения априори превосходят размеры упаковок и в любой ячейке склада может быть размещена любая упаковка (независимо от габаритов) с любым количеством любой номенклатуры. Но при этом в случае, если в ячейке находится какой-либо товар/комплектующая, то эта ячейка считается занятой.
2. Внедрение адресного учета в программе 1С предприятие УПП: выбор варианта решения задачи
Как известно в конфигурации «1С:УПП Производство» отсутствуют какие-либо механизмы для ведения адресного учета на складах. Однако такие возможности есть в более новой конфигурации для производственного учета от фирмы «1С» «1С:ERP. Управление предприятием».
Поэтому для решения поставленной задачи можно было выбрать один из трех вариантов:
· Произвести доработку используемой на предприятии Заказчика ИС на базе конфигурации «1С:Управление производственным предприятием».
· Перевести учет предприятия в ИС на базе конфигурации «1С:ERP. Управление предприятием».
· Организовать внедрение wms системы для целей складского учета, а также обмен данными с основной ИС. Подобных решений на рынке представлено большое множество:
- «Кортес:Адресный склад»
- «ARENA.WMS»
- «PentaWMS»
- «TopLog WMS»
- «YARUS WMS»
- «1С-Логистика:Управление складом»
Это только решения на платформе 1С:Предприятие.
Как и всегда в жизни, каждый из возможных вариантов имел свои достоинства и недостатки. Однако в рамках данной публикации мы не будем сравнивать возможности различных WMS-систем - это тема отдельной статьи.
Отметим лишь, что вариант перехода на «1С:ERP. Управление предприятием» был отклонен по причине несоответствия масштаба решаемой задачи и затрат (времени, финансов) необходимых на внедрение данного решения. Что же касается специализированных WMS-систем, то после ознакомления с ними, Заказчику стало понятно, что их возможности с большим запасом удовлетворяют потребности и зачастую являются избыточными (что на самом деле тоже не всегда хорошо). Однако для заказчика были актуальны вопросы:
- внедрения и дальнейшего сопровождения, второй информационной системы;
- интеграции двух систем, синхронизации данных;
- обучения сотрудников новому интерфейсу, а зачастую и новой логике работы;
- в некоторых случаях необходимость параллельной работы сотрудника в двух системах;
- отдельное независимое от основной КИС лицензирование программных продуктов.
Неопределенность в решении этих вопросов, а также дополнительные затраты (иногда весьма немалые) на приобретение лицензий на данные решения, привели Заказчика выбору в пользу варианта доработки существующей информационной системы.
После согласования организационных вопросов (определения сроков и стоимости работ, ответственных с каждой из сторон) был разработан план-график работ, выполнено проектирование подсистемы и последующая реализация. Подробнее об этих этапах работ, особенностях реализации и сложностях, с которыми пришлось столкнуться, а также о полученных результатах и сделанных выводах, - будет рассказано в следующих частях.
Продолжение ЗДЕСЬ.
Антон Лосев,
специалист отдела внедрения компании "Кодерлайн"