7 факторов успешного внедрения 1С:WMS
-
Гоголева Екатерина Ведущий специалист отдела логистики
Внедрение «1С:WMS Логистика. Управление складом» – достаточно сложный процесс, часто требующий больших временных и денежных затрат. При этом успех проекта и минимизация затрат во многом зависят от грамотной подготовки и планирования. Давайте рассмотрим факторы, которые, на наш взгляд, являются основными для успешного проекта внедрения WMS на предприятии на всех этапах: от первоначального анализа до непосредственно запуска.
Фактор №1. Определение проблем и потребностей склада
Первое, что необходимо сделать перед началом автоматизации склада – тщательно проанализировать все текущие бизнес-процессы и выявить максимальное количество проблем в них. Проблемы могут быть самые разные! Как пример, кратко рассмотрим наиболее часто встречающиеся проблемы в основных процессах склада:
- Разгрузка товара:
- большое количество машин в момент времени (одновременно на территории находится больше машин, чем мест для разгрузки);
- недостаточно ворот разгрузки или постановочных мест для разгрузки;
- большой объем поставки (при поставке товаров оказывается заставлена вся зона разгрузки, что мешает движению техники и персонала);
- недостаточно техники, то есть не на чем быстро выгрузить или переместить товар;
- недостаточно персонала (некому разгружать товар или состав персонала некорректно спланирован).
-
Приемка товара:
-
отсутствие плана поставки (нет информации о планируемых поступлениях);
-
низкая скорость приемки (товар не маркирован или не хватает людей);
-
ошибки персонала (пересорт товара и количественные ошибки).
-
Размещение товара:
-
недостаточное количество мест хранения;
-
ошибки персонала (сотрудник разместил товар в ячейку А1, а в системе указал ячейку А2 и т.п.);
-
способ размещения товара (паллет целиком – высокая скорость, раскладывание по ячейкам с таким же товаром – низкая скорость).
-
Отбор товара:
-
низкая скорость отбора (отсутствие информации о месте хранения, нет доступа к нужному паллету/товару, например, по причине перетаренности склада);
-
ошибки персонала (пересорт товара и количественные ошибки).
-
Соблюдение дедлайнов:
-
не своевременное начало отбора товара;
-
не своевременное пополнение зоны отбора;
-
отобранный товар не упакован / не проконтролирован;
-
заказы не отобраны ко времени прихода машины на погрузку;
-
документы на отгрузку не готовы к моменту прихода машины.
-
Отгрузка товаров:
-
низкая скорость отгрузки (может возникать при выполнении контроля отгрузки или при раскладывании товара в машине);
-
не определена очередность загрузки товара в машину (водитель руководит погрузкой и сам указывает, что и куда ставить, например, для распределения паллет в авто по весу для равномерной нагрузки на оси).
-
Персонал:
-
недостаток или, наоборот, объективный избыток персонала;
-
отсутствие контроля за скоростью и своевременностью выполнения операций;
-
отсутствие действующей системы мотивации персонала;
-
отсутствие четкого регламента работы (БП, должностные инструкции и т.д.).
После выявления проблем необходимо также учесть плановые изменения показателей склада или его потребности. Другими словами, нужно четко определить и решить, как именно работа склада должна быть улучшена и/или какие изменения в его работе ожидаются. К плановым изменениям можно отнести:
-
увеличение объемов отгрузки (заключение новых договоров);
-
увеличение скорости отгрузки (оборачиваемость склада);
-
увеличение эффективности использования мест хранения (исключение полупустых ячеек, деление склада на зоны и т.д.);
-
снижение ошибок персонала (некачественная приемка, пересорты товаров);
-
изменения мотивации персонала (расчет ЗП исходя из выработки сотрудников, бонусы от количества выполненных операций и т.д.);
-
новые направления бизнеса или изменения законодательства (например, биллинг или работа с ЦМТ).
Фактор №2. Оргструктура проекта
После того как были выявлены все проблемы и потребности склада необходимо решить, кто будет заниматься реализацией проекта, т.е. утвердить оргструктуру или состав проектной команды. Правильный выбор состава проектной команды является залогом успеха всего проекта.
Оргструктура проекта обычно включает в себя следующие роли:
-
заказчик;
-
куратор проекта;
-
руководитель проекта;
-
главный пользователь;
-
специалист.
Кто все эти люди и зачем они нужны? Давайте разберемся.
Заказчик – лицо, которое отвечает за достижение бизнес-целей проекта. Чаще это собственник или директор организации. Он занимается решением проблем на высшем уровне, обеспечивает проект ресурсами.
Куратор проекта – лицо, которое получает конечный продукт проекта. Это может быть директор или замдиректора направления. Он занимается анализом и утверждением плана проекта, информированием заказчика о факторах, которые могут повлиять на конечный продукт проекта.
Руководитель проекта – лицо, которое несет ответственность за проект. Чаще всего это опытный сотрудник, например, директор склада или замдиректора, который осведомлен о всех бизнес-процессах организации. Он занимается решением проблем, возникающих во время проекта, обеспечивает коммуникацию между всеми участниками проекта, контролирует план проекта, определяет роли и обязанности участников проекта.
Главный пользователь – лицо, которое представляет требования конечных пользователей. Чаще всего это начальник склада. Он определяет требования конечных пользователей к продукту проекта, поддерживает связь между пользователями и руководством проекта.
Специалист – лицо или группа лиц, отвечающие за достижение результатов по задачам, где они являются исполнителями. Обычно это представители ИТ службы, программисты, администраторы системы, диспетчеры склада. Каждый специалист занимается выполнением задач, поставленных ему с целью получения конечного продукта, а также участвует в разработке документации и оценке трудоемкости получения продукта.
Также важно отметить, что при внедрении WMS-системы в состав проектной команды обязательно должны входить следующие специалисты: администратор системы, администратор КИС, ИТ инженер.
Администратор WMS— это лицо, которое обеспечивает первую очередь поддержки конечных пользователей. Он наиболее глубоко погружен в логику и настройку системы и способен решить большую часть вопросов пользователей, которые не связаны непосредственно с разработкой.
Администратор КИС — это лицо, которое обеспечивает первую очередь поддержки пользователей КИС. Он занимается контролем за документооборотом между WMS и КИС, разбирается в корректности формирования документов в КИС.
ИТ инженер — это лицо, которое обеспечивает техническое состояние системы, т.е. отвечает за ее работоспособность (сервер, связь, ПК, ТСД и прочее)
Фактор №3. Компетенции специалистов
После утверждения оргструктуры проекта необходимо оценить компетенции сотрудников по вопросам логистики и понять, способны ли они самостоятельно описать текущие бизнес-процессы «как есть», а также – планируемые бизнес-процессы «как будет», учитывая выявленные проблемы и плановые потребности склада. Идеально, когда в составе организации есть свой логист или бизнес-аналитик процессов склада. Но, как правило, в штате таких кадров нет, поскольку услуги подобных сотрудников стоят достаточно дорого, а обеспечить их 100% загрузкой после реализации конкретного проекта весьма проблематично.
Оценивая компетенции сотрудников, важно учитывать особенности работы конкретного склада. Например, если на складе используются только простые процессы (приемка, размещение, отбор и отгрузка товаров, внутренние перемещения, инвентаризация), то свои специалисты почти наверняка смогут самостоятельно описать необходимые бизнес-процессы. Если же на складе используются или планируются более сложные процессы (различные виды контроля при приемке и отгрузке товаров, управление двором, учет ЦМТ, компрессия, подпитка, отбор мелкоштучного товара с выделенной для него зоной и т.д.), свои специалисты корректно описать все бизнес-процессы вряд ли смогут.
Так или иначе, для начала проекта специалисты организации должны хотя бы попытаться самостоятельно описать планируемые бизнес-процессы «как будет» в виде примерного ТЗ. Другими словами, необходимо описать, какой по мнению специалистов компании должна быть логика работы склада и что требуется от системы WMS. Описанием всей логики должен заниматься сотрудник, который наиболее глубоко погружен во все процессы склада, либо досконально их изучил. В идеале этим должен заниматься лично руководитель проекта.
Не страшно, если в ТЗ что-то будет описано не совсем корректно – самое главное, чтобы все процессы были учтены. Если в дальнейшем к работе будут привлекаться внешние специалисты, любые непонятные моменты можно будет обсудить с автором ТЗ и уточнить у него, что именно он имел в виду.
Если в процессе работы участникам проектной команды становится понятно, что самостоятельно они не справляются с описанием бизнес-процессов склада, наиболее правильным решением будет привлечение к процессу более компетентных сторонних специалистов, логистов или бизнес аналитиков, занимающихся оказанием подобных услуг. Сторонние специалисты ознакомятся с подготовленным примерным ТЗ, при необходимости запросят дополнительную информацию и проведут аудит/обследование непосредственно на территории объекта автоматизации.
По итогам своей работы специалисты представят рекомендации для решения выявленных в организации проблем и эффективной реализации плановых потребностей:
-
оценят соответствие текущего складского помещения поставленной цели (может потребоваться его реконструкция);
-
определят необходимое количество складского оборудования (стеллажей, ворот и т.д.) и рассчитают его оптимальное расположение;
-
рассчитают оптимальную численность складского персонала и техники;
-
сориентируют, какой программный продукт лучше всего подойдет для реализации поставленной цели (для склада не всегда требуется отдельная система ВМС – в отдельных случаях возможна автоматизация с помощью корпоративной учетной системы КИС).
Все рекомендации специалистов обычно оформляются в виде Технико-логистического задания (ТЛЗ) – документа, в котором также описываются все бизнес-процессы склада «как есть» и «как будет», логика товародвижения, ролевая модель, топология склада и прочая информация, необходимая для качественного начала проекта автоматизации склада.
Фактор №4. Выбор программного продукта
После проведения тщательного анализа и появления четкого понимания, какой должна быть будущая система и какие задачи она должна выполнять, необходимо перейти к выбору программного продукта. Для автоматизации склада существуют два варианта: реализация адресного учета в КИС и реализация управления складом на базе WMS. Конечный выбор зависит от сложности процессов конкретного склада.
Адресный учет в КИС применим, как правило, только для самых простых процессов: приемка, размещение в зону хранения, внутренние перемещения между ячейками хранения, инвентаризация, отбор из зоны хранения, отгрузка.
Если бизнес-процессы конкретного склада не предусматривают сложную логику, то адресного учета в КИС обычно бывает вполне достаточно. Однако даже в этом случае у данного варианта имеется несколько существенных минусов:
-
если по техническим причинам база КИС временно «зависнет», работа склада тоже остановится;
-
при запуске в базе КИС сложных расчетов и обработок данных работоспособность адресного учета снижается;
-
доработка и развитие КИС до функционала, приближенного к WMS, в перспективе требует существенных временных и финансовых затрат.
Если же на складе используются более сложные процессы (или их использование планируется в будущем), выбирать нужно однозначно WMS, поскольку большинство требуемого функционала для автоматизации склада в данной системе уже есть – это позволяет реализовать большую часть процессов без доработок. Под сложными процессами подразумеваются, например, следующие:
-
подпитка (перемещение товара из зоны хранения в зону отбора при достижении заданного минимума);
-
различные правила приемки, размещения и отбора в зависимости от характеристик товара;
-
компрессия (совмещение неполных паллет по различным правилам);
-
различные виды контроля при приемке и отгрузке товара и т.д.
Если становится понятно, что требуется именно система WMS, необходимо выбрать конкретный программный продукт. На современном рынке представлено большое количество WMS продуктов, которые схожи по своей сути. С их помощью можно автоматизировать практически любой склад. Тем не менее, при выборе нужно обращать внимание на важные детали конкретного программного продукта, а именно:
-
интерфейс: внешний вид программы должен быть удобен и понятен пользователям;
-
удобство работы в программе: быстрота и простота составления отчетов, работы с документами, выполнения различных операций;
-
функциональность: наличие максимального количества требующихся складу процессов в базовом функционале WMS;
-
возможность подключения необходимого оборудования: от принтеров и сканеров до терминалов сбора данных (ТСД);
-
возможность и простота доработки системы специалистами (открытый или закрытый исходный код), наличие гибких настроек для доработки системы без привлечения программистов;
-
стоимость поддержки и/или доработки системы (сама программа может стоить не так дорого, но стоимость часа работы специалиста по ее улучшению может быть существенно выше средней по рынку);
-
насколько активно программный продукт поддерживается разработчиком, как долго он представлен на рынке и как часто обновляется, наличие отзывов;
-
кто является интегратором системы: продажей и внедрением может заниматься как сам разработчик программного продукта, так и какой-либо посредник.
После первичного отбора подходящих программных продуктов необходимо еще раз оценить возможности каждой WMS, наложив планируемые процессы на типовой функционал конкретной системы. Для этого нужно обратиться к ранее описанным в ТЗ требованиям к системе. ТЗ необходимо выслать интеграторам отобранных систем на оценку. После их оценки вы соберете окончательную информацию по стоимости внедрения и необходимым доработкам каждой системы. В итоге вы сможете произвести прямое сравнение и выберете конкретный программный продукт, который подходит вам больше всего.
Для лучшего понимания того, что относится к типовому функционалу системы, а что – к доработкам, рассмотрим простой пример. Типовая приемка товара выглядит следующим образом:
1. сканируем контейнер приемки (паллет);
2. сканируем номенклатуру;
3. указываем количество, статус, партию;
4. подтверждаем приемку контейнера (паллета);
5. товар принят, остаток появился в системе.
Все перечисленное выше – базовые процедуры, относящиеся к типовому функционалу. Если же вам необходимо, например, чтобы при приемке сотрудник указывал какие-то дополнительные реквизиты/характеристики товара, чтобы отображалась какая-либо дополнительная информация и т. п. – это уже относится к доработкам.
Фактор №5. Выбор варианта реализации проекта
После того как окончательно утверждены все требования к системе и выбран конкретный программный продукт, необходимо определить вариант реализации проекта. Существуют три основных варианта:
-
Самостоятельная реализация.
-
Реализация совместно с подрядчиком.
-
Реализация силами подрядчика.
Самостоятельная реализации проекта заключается в том, что все работы по проекту осуществляются собственными силами собранной команды проекта на основании составленного ранее ТЗ или ТЛЗ, подготовленного с участием привлеченных специалистов. К таким работам относятся:
-
анализ и заполнение НСИ (например, в справочнике номенклатуры должны быть заполнены ВГХ, ШК продукции, упаковки, вместимость контейнера/паллета);
-
первичная настройка системы WMS;
-
настройка процессов в системе в соответствии с ТЗ или ТЛЗ;
-
настройка обмена данными между КИС и WMS;
-
подключение дополнительного оборудования (принтеры, ТСД и т.д.);
-
обучение конечных пользователей системы (кладовщики, отборщики товара);
-
маркировка склада;
-
запуск системы в промышленную эксплуатацию;
-
последующее сопровождение системы и пользователей.
Вариант самостоятельной реализации проекта имеет не так много преимуществ. Главное из них – снижение затрат на внедрение за счет максимального использования внутренних ресурсов. Также команда проекта может более гибко подходить к назначению ресурсов и последовательности выполнения работ, поскольку не зависит ни от каких внешних факторов. При этом в варианте самостоятельной реализации проекта существуют следующие ограничения:
-
в штате нужен минимум один квалифицированный программист по выбранному программному продукту;
-
необходимо провести обучение специалистов по выбранному программному продукту, либо нужен бизнес-аналитик или логист, хорошо разбирающийся в конкретной программе и способный самостоятельно провести обучение;
-
практически неизбежны дополнительные затраты на приобретение консультационных услуг по специфике работы выбранной программы.
Кроме того, отсутствие опыта в подобных проектах у членов внутренней команды выливается в затягивание сроков реализации, а также повышает вероятность возникновения непредвиденных сложностей из-за отсутствия «свежего взгляда со стороны». Как результат – высокие риски или вообще не достигнуть целей проекта, или потратить дополнительные временные и финансовые ресурсы на платные консультации от сторонних специалистов. То есть от первоначальной экономии по факту может ничего не остаться.
Вариант реализации проекта совместно с подрядчиком заключается в том, что часть работ команда проекта делает самостоятельно, а другую часть – команда подрядчика. При этом важно грамотно распределить обязанности и задачи. Рассмотрим, какие работы может наилучшим образом выполнить каждая из сторон.
Работы команды проекта | Работы подрядчика |
- первичная настройка системы WMS; - заполнение НСИ (в случае необходимости) - подключение и настройка необходимого оборудования (принтеры, ТСД) - настройка обмена данными со стороны КИС*; - обучение конечных пользователей (подрядчик обучает администратора WMS, а тот уже обучает пользователей системы); - маркировка склада; - первичная поддержка пользователей системы. |
- обследование объекта автоматизации, анализ НСИ (при необходимости); - подготовка ТЗ по внедрению системы WMS; - настройка системы по ТЗ; - обучение специалистов по работе в системе WMS (а также обучение программистов по конфигурации, если это необходимо); - настройка обмена данными между КИС и WMS; - запуск системы и поддержка на время начала работы в системе, устранение выявленных ошибок, консультирование программистов организации и администратора WMS; - последующее сопровождение системы, возможные доработки. |
*Применимо, если обмен осуществляется через шину данных, т. е. выгрузку данных из учетной системы в шину и загрузку данных из шины в КИС делают программисты организации, а обмен между шиной и WMS делают программисты исполнителя. Если же обмен реализован напрямую между базами, то подрядчик выполняет настройку самостоятельно.
Среди преимуществ данного варианта реализации проекта можно выделить некоторое снижение затрат на внедрение системы за счет выполнения части работ специалистами организации. При этом качественное обучение подрядчиком специалиста по работе в системе снижает вероятность последующих обращений к сторонним специалистам за платными консультациями.
Среди недостатков и рисков данного варианта можно отметить вероятность некорректной настройки системы и возникновения ошибок в обмене данными при плохой коммуникации между командой подрядчика и командой проекта. Также существует риск низкокачественного обучения конечных пользователей системы администратором WMS, особенно если у него нет соответствующего опыта или эффективной программы обучения.
Вариант реализации проекта силами подрядчика заключается в том, что основную часть работ по проекту берет на себя подрядчик. Данный вариант не означает, что команда проекта заказчика не будет задействована – она будет оказывать команде исполнителя поддержку в ходе всего проекта, обеспечивать ее необходимыми полномочиями, налаживать коммуникации, решать текущие вопросы, связанные с бизнес-процессами организации, а также поэтапно контролировать и принимать работы по проекту.
У данного варианта есть только один очевидный недостаток – увеличение затрат на внедрение проекта. При этом имеется целый ряд преимуществ:
-
практически полное отсутствие риска не достигнуть целей проекта;
-
четкое соблюдение плановых сроков реализации проекта;
-
качественное обучение специалистов и пользователей системы WMS;
-
«мягкий запуск» системы с минимальным количеством ошибок на старте.
Важно отметить, что успех двух последних вариантов с привлечением подрядчика во многом зависит от выбора конкретного подрядчика. Очевидно: чем он профессиональнее и опытнее, тем успешнее и быстрее будет реализован проект. Давайте рассмотрим основные критерии выбора хорошего подрядчика:
-
статус компании: сертифицирована ли она и является ли непосредственно разработчиком программного продукта (идеальный вариант);
-
размер компании: наличие достаточного количества квалифицированных программистов, возможность выделения полноценной команды для реализации конкретного проекта;
-
количество успешно выполненных проектов, при этом следует обращать особое внимание на проекты по родственным направлениям бизнеса;
-
возможность проведения референсов (демонстрации работы ранее внедренных систем в других организациях);
-
какие гарантии по реализованному проекту предоставляет компания, готова ли оперативно устранять возможные ошибки после закрытия всех этапов проекта;
-
какова репутация компании, имеются ли положительные отзывы о ее работе, которые можно проверить
Фактор №6. Этапы реализации проекта
После выбора варианта реализации проекта необходимо составить план выполнения работ, разделив его на этапы. Давайте рассмотрим основные этапы реализации проекта и их содержание.
Подготовительный этап
Подготовительный этап заключается в «сверке часов» между исполнителем и заказчиком. Необходимо, чтобы у сторон было одинаковое понимание целей и итогов проекта. На данном этапе исполнитель и заказчик должны согласовать процедуры ведения и управления проектом, а также детализировать все требования и нюансы.
Подготовительный этап обычно включает в себя 2 пункта:
-
Обследование объекта автоматизации (в случае необходимости), в результате чего появляется согласованная схема процессов «как будет» в виде ТЗ или ТЛЗ. Оформляется самостоятельно или с помощью привлеченных специалистов.
-
Подготовка устава проекта — специального документа, определяющего цели и рамки проекта, роли и обязанности всех его участников, правила взаимодействия участников, основные этапы и принципы организации работ. Устав обычно идет приложением к договору внедрения.
В уставе обязательно указывается оргструктура проекта, дается полное описание команды заказчика (см. «Фактор №2. Оргструктура проекта») и команды исполнителя. Структура команды исполнителя напоминает структуру команды заказчика, в нее входят:
-
куратор проекта;
-
руководитель проекта;
-
консультант проекта;
-
специалист.
Куратор проекта – лицо, которое контролирует достижение целей проекта. Куратор занимается анализом и утверждением устава проекта, информирует заказчика о факторах, которые могут повлиять на конечный результат проекта.
Руководитель проекта – лицо, которое несет ответственность за проект со стороны исполнителя. Руководитель занимается подготовкой и согласованием проектной документации, созданием отчетов по ходу проекта, решением возможных проблем, возникающих в процессе работы, а также контролирует план проекта и передает результаты заказчику.
Консультант проекта – лицо или группа лиц, отвечающие за качество настройки и работоспособность системы в соответствии с ТЗ.
Специалист – лицо или группа лиц, отвечающие за достижение результатов по конкретным задачам. Обычно это тестировщики и программисты. Специалисты занимаются выполнением задач, которые ставятся им консультантом проекта.
Помимо описания оргструктуры проекта, в устав входит план коммуникаций. Он включает в себя каналы коммуникаций (контактную информацию всех участников проекта: телефон, почта, мессенджеры и т.д.) и матрицу взаимодействия и информирования (кто из участников проекта участвует в плановых совещаниях и включен в список рассылки отчетности по проекту).
Также в уставе приводится иерархическая структура работ (ИСР), которая разрабатывается после выявления всех бизнес-целей заказчика. Цель разработки ИСР – деление проекта на отдельные задачи и подзадачи. Через подзадачи в ИСР описываются все результаты, которые должны быть получены в ходе реализации проекта. Все, что не отражено в подзадачах, не делается в проекте, т.е. ИСР определяет границы проекта и критерии качества приемки по каждой выполненной задаче.
Завершает устав четкий план с графиком работ по проекту, который представляет собой иерархическую структуру работ с указанием плановых сроков реализации каждой задачи.
Этап проектирования
Этап проектирования заключается в подготовке и согласовании технической документации, в которой описывается весь планируемый функционал системы (как система должна быть настроена и как в ней должны выполняться все планируемые операции). На этапе проектирования подготавливаются 2 важных документа:
-
Технический проект – документ, описывающий правила настройки системы. В нем приводятся идентификационная и ролевая модели, дается подробное описание правил выполнения складских операций, указываются требования к аппаратной части и технической инфраструктуре, а также дается описание доработок системы и требований к интеграции (ТЗ на интеграцию).
-
Контрольный пример – документ, описывающий работу системы на конкретном примере. В нем описываются действия пользователей и самой системы по каждому бизнес-процессу. Например, что появляется в WMS на основании документа КИС (вплоть до номенклатуры, партии и статуса), какие действия выполняет оператор или складской сотрудник, что в системе WMS появляется на основании этих действий, что должно появиться в КИС и т.д. Контрольный пример необходим для приемки этапа настройки и доработки системы – именно по нему проходит приемочное тестирование с подтверждением готовности системы к запуску.
Этап настройки и доработки системы
Суть данного этапа состоит, собственно, в настройке системы по ранее согласованному техническому проекту. Этап включает в себя:
-
настройку системы по ТП (топология, базовые процессы, правила выполнения операций, роли сотрудников и прочее);
-
доработки по расширению базового функционала;
-
заполнение НСИ, необходимой для WMS;
-
разработку обменов (интеграции с учетной системы по согласованному ТЗ);
-
настройку оборудования (сервер, сеть, ТСД, принтеры и прочее);
-
физическую маркировку склада (ШК ячеек хранения, ШК сотрудников);
-
приемочное тестирование в соответствии с контрольным примером.
Этап опытно-промышленной эксплуатации
Этап опытно-промышленной эксплуатации заключается в окончательном переводе склада на работу в системе WMS. Данный этап состоит из следующих работ: обучение персонала; тестовая эксплуатация; промышленная эксплуатация.
Обучение персонала проводится по согласованной программе с разделением на теоретическую и практическую части (с инструкциями и тестовыми примерами). Обычно проводят два типа обучения: общее – для складских сотрудников и углубленное – для операторов и администраторов WMS. Параллельно с обучением или сразу после него обычно осуществляют ввод начальных остатков или инвентаризацию склада для отражения корректных остатков по ячейкам хранения в системе WMS. Лучше всего проводить данную работу в момент минимальной загрузки склада, т.е. запланировать этот этап нужно на период минимальных приемок и отгрузок.
Тестовая эксплуатация проводится в режиме тотального контроля за корректность работы всей системы. Это самый напряженный этап, он требует одновременного участия обеих команд проекта (и заказчика, и исполнителя). Именно на данном этапе выявляется основная масса ошибок, причем, как системных, так и у сотрудников предприятия после первоначального обучения. На этом этапе администратор WMS перенимает опыт работы в системе от команды исполнителя, учится самостоятельно находить и устранять основные ошибки. Обычно тестовая эксплуатация занимает 1-2 недели (в зависимости от количества и сложности процессов), но может длиться и дольше – до полного устранения всех системных ошибок и до заметного снижения количества ошибок, возникающих у пользователей системы в процессе работы с ней (т.е. пока люди не привыкнут работать в новой для них системе).
Промышленная эксплуатация – начало полноценной работы организации по всем запланированным бизнес-процессам в системе WMS. Администратор WMS на данном этапе начинает выполнять роль первой линии поддержки пользователей, а команда исполнителя переходит в режим удаленного сопровождения и уже, как правило, взаимодействует только с администратором WMS, помогая ему оперативно решать возникающие вопросы и проблемы. Окончанием этапа опытно-промышленной эксплуатации можно считать устранение всех выявленных ошибок системы и снижение количества ошибок персонала до минимума (критерии приемки этапа указываются в ИСР).
Этап гарантийного сопровождения
Этап гарантийного сопровождения необходим для устранения замечаний, возникающих в процессе эксплуатации системы, в рамках технического проекта. Длительность данного этапа зависит от условий договора. Весь дополнительный функционал, не предусмотренный в ТП, потребность в котором была выявлена уже во время запуска системы, реализуется в рамках нового договора или дополнительного соглашения к действующему договору.
Фактор №7. Технология запуска WMS
Под технологией запуска подразумевается то, как именно будет реализован главный этап проекта – непосредственно его запуск. Что необходимо сделать перед запуском, чтобы он прошел гладко и без «неожиданностей»? Можно выделить 4 основных шага:
-
Оценить персонал – перед началом запуска системы необходимо оценить уровень компьютерной грамотности пользователей. Провести тестирование, чтобы проверить навыки работы людей с мессенджерами, аппаратной техникой, офисными программами и браузером.
-
Выстроить каналы коммуникаций, причем, как внутри подразделений, так и между смежными подразделениями, чтобы каждый сотрудник предприятия четко знал, куда ему обращаться за помощью в случае возникновения той или иной проблемы. Например, можно создать и настроить несколько внутренних чатов для сотрудников по вопросам техподдержки, по вопросам поступления и отгрузки товара и т.д. При этом обязательно нужно назначит ответственных за оперативное реагирование на поступающие вопросы.
-
Подготовить оборудование и материалы – проверить работоспособность сети, оборудования, наличие и исправность ПК, принтеров, убедиться в наличии достаточного количества всех необходимых расходных материалов (бумаги, этикеток для принтеров, стрейч пленки и т.д.).
-
Выполнить маркировку склада – маркировка ячеек должна быть интуитивно понятна и ясна всем сотрудникам склада, в том числе новичкам.
Что касается вариантов запуска WMS, их существует несколько. Выбор конкретного зависит от сложности и интенсивности работы определенного склада. Например, для маленького склада с простыми процессами и низкой интенсивностью можно запустить все процессы сразу («одновременный запуск»). Это самый быстрый и понятный вариант.
Однако большой высокоинтенсивный склад запустить разом бывает достаточно проблематично, а иногда и просто нереально. Поэтому на сложных складах применяется так называемый «мягкий запуск». Он осуществляется в несколько этапов. Сначала запускается приемка и размещение товара (это может быть реализовано на этапе настройки системы в режиме тестовой эксплуатации). Это помогает вымыть не маркированные остатки со склада, а также позволяет сотрудникам привыкнуть к новой системе в целом. Дополнительный плюс здесь заключается в том, что на момент ввода начальных остатков большая часть товара уже будет промаркирована – это значительно снизит трудозатраты. После запуска приемки и размещения товара запускаются внутренние операции, различные перемещения и инвентаризации, а в самом конце подключаются отбор и отгрузка.
Если на складе очень высокая интенсивность и при этом нет возможности временно остановить его работу для ввода начальных остатков, то эту процедуру можно выполнять по группам товаров. Важное условие при этом – группы товаров должны быть разделены по разным зонам и отгружаться раздельно. Допустим, сначала запускается группа товаров «Химия», затем – «Продукты» и т.д.
Также можно выделить еще один вариант запуска WMS – «удаленный запуск». Он означает, что исполнитель выполняет все работы без физического присутствия на предприятии. Обследование, например, может проводиться по видеосвязи: компетентный сотрудник склада может на камеру показывать все процессы склада, параллельно отвечая на вопросы. В данном варианте основная нагрузка по реализации ложится на плечи команды заказчика, а исполнитель максимально качественно обучает и поддерживает специалистов проектной команды.
Основные плюсы данного варианта запуска – сокращение денежных затрат на реализацию проекта, а также качественное обучение и подготовка своих специалистов, способных в будущем минимизировать количество платных обращений за консультациями.
Если у вас возникли какие-либо вопросы, либо вы планируете приступить или уже находитесь на определенном этапе внедрения «1С:WMS Логистика. Управление складом» на предприятии и столкнулись со сложностями, вы можете обратиться за помощью в компанию «СИТЕК». Наши специалисты имеют многолетний опыт работы и сотни успешно реализованных проектов за плечами. Мы готовы оказать вам как простую консультационную поддержку, так и помочь в реализации проекта внедрения «1С:WMS Логистика. Управление складом» на предприятии любого масштаба с нуля «под ключ» или на каком-то конкретном этапе.
____________________________________
Автор статьи: Гоголева Екатерина – ведущий специалист отдела «1С:WMS Логистика. Управление складом».
Дата публикации статьи: 09.08.2021 г.