Осторожно: WMS – 2. Этап внедрения

Конечно, основное «право голоса» - за финансовым директором и руководителем ИТ-департамента. Но, тем не менее… Поскольку WMS – это практически всегда «штучный продукт», на этом этапе фактически проводится «конкурс презентаций».

Задача поставщика – убедить заказчика, что именно этот продукт в состоянии решить его проблемы (и те, с которыми заказчик пришел к решению поставить систему на складе, и те, которые он еще не заметил..)
Следовательно, на этом этапе – активно посещаем встречи с потенциальными поставщиками, смотрим их презентации, в которых они расписывают преимущества своих продуктов. По возможности – задаем вопросы. Не надо стесняться и считать, что раз вопрос, который вы задаете, не в состоянии понять ваши коллеги, присутствующие на встрече, то лучше промолчать. Во-первых, ответ вам все равно нужен. Во-вторых, а если ответа у поставщика нет? Вот некоторые вопросы, которые лучше не откладывать.

1. Смотрите то, что вам показывают. Обычно представители поставщика не первых встречах показывают презентацию с некоторого успешного проекта. Насколько описание похоже на процессы, происходящие на вашем складе? Когда на презентации для аптечного склада (поштучка, посерийный учет и прочий хардкор) показывают решение для склада бакалеи – кто-то должен озвучить фразу «а как это будет работать у нас?».
2. Обращайте внимание на «железо», которое фигурирует в проекте. Поставщики обычно уверены, что без терминала сбора данных у каждого работника – работа не может проводиться, и все. Даже на поштучном отборе! При этом анатомические особенности отборщика должны выглядеть примерно так:

• в одной руке – ТСД
• во второй руке – стилус терминала (вводим количество штук)
• в третьей руке – отбираемый товар
• в четвертой руке – емкость для отбора товара (коробка или корзинка с ручкой) или поручень толкаемой тележки

Поскольку такие мутанты на складе не встречаются, можно сформулировать каверзный вопрос: «Правильно ли я понял, что мы тратим 1000 уе на оснащение ОДНОГО работника, и в результате получаем снижение его производительности в 1.5 – 2 раза?». Правильно…
Кстати, компьютеры, установленные на складе, вероятно, тоже придется сменить - из-за очевидно низкой производительности, не удовлетворяющей новым системным требованиям.
1. Проанализируйте, что вам НЕ показали. Например, «за кадром» часто остаются вопросы:

• пополнения зоны активного хранения (кто, как, когда)
• выполнения правил партионного учета
• количества «внутренних» документов в системе и необходимого для этого ресурса (сколько операторов учета придется добавить в штат склада при переходе на ячеистую струткуру склада? Хорошо, если одного..)
• работы с товаром, имеющим больше одного штрихкода
• работы со штрихкодом, который встречается на нескольких товарах

4. ОБЯЗАТЕЛЬНО!! Отработка исключений. Каким образом поставщик может продемонстрировать помехоустойчивость и эластичность своего продукта?

Внедрение – первый этап. Изучение того, что мы планируем изменить.

Первый этап – построение модели «как есть». Прежде чем что-то изменить, нужно это изучить.
На этом этапе – желательно удержаться от двух крайностей:

• игнорирование текущей ситуации. «Все равно новый продукт устранит все проблемы, которые мы сейчас сортируем и описываем». Большой соблазн не тратить ресурс на эту работу, а двигаться дальше как можно скорее. Потенциальная опасность потерять наработанные технологии «второго порядка», в основном – взаимодействие между структурными подразделениями склада, а также наработанные правила действия при нештатных ситуациях.
• увлечение моделизмом. Построение максимально подробной модели работы склада в данный момент, причем для анализа собранной информации нужно потратить тоже весьма значительное время. КПД этой работы может оказаться весьма низким, по причине ОЧЕНЬ низкого соотношения полезной информации к общему объему полученного многостостраничного опуса. Простые вещи не стоит называть сложными терминами и пространно описывать ну уж совсем базовые операции.

В общем, можно уверенно сказать: качественная работа на этапе построения модели работы «как есть» (обязательно – с пониманием причинно-следственных связей) – необходимое (но, к сожалению, не достаточное) условие успешности проекта.
Соответственно, игнорирование этого этапа членами проекта со стороны поставщика (все равно изменим - и так все понятно, что вы все делаете неправильно) – очень опасный признак.

Внедрение – второй этап. Разработка техзадания и собственно внедрение

На этом этапе ключевой фактор – корректная постановка техзадания. Основная проблема – корректно отработать все возможные исключения. Очень удобный инструмент в этом случае – стандартная логическая блок-схема (в школе проходили на программировании).
Она позволяет достаточно грамотно и без сложных действий описать все случаи «если-то», и не оставить подвешенной в воздухе какую-то логическую линию последовательности событий

На основании описания запланированных алгоритмов работы – программисты должны предоставить техзадание. Внимание. Если техзадание обязаны по договору писать сотрудники заказчика – очень плохой признак, очевидное желание поставщика программы снять с себя ответственность. Продолжает работать правило «правильно заданный вопрос содержит половину ответа», но «отвечающий» получает замечательную возможность в случае некорректного ответа – обвинить «спрашивающего».

Здесь вариант конфликтов – все то же нежелание программистов «писать техзадания, которые никто не понимает» (писать понятно для персонала склада они обычно не пробовали) – а с другой стороны, неготовность персонала заказчика понять написанное. В результате – вместо техзадания как скелета, на который будут нанизываться все описания и алгоритмы работы склада, получаем не поддающийся описанию и непригодный к использованию набор текстов. В перспективе – очевидный провал проекта и исправление запланированных (как следствие собственной лени) на этом этапе ошибок.

Для профилактики этой проблемы – в проектную группу со стороны заказчика обязательно включайте способных разобраться в техзадании аналитиков. Во-первых, персонал поставщика WMS – не заинтересован в чрезмерной детализации работ на этом этапе, им инетереснее максимально упростить себе написанное задание, чтобы затем побольше находиться в условиях «правового вакуума» и непрописанные в техзадании процессы – закрывать своими старыми заготовками с прежних проектов. Во-вторых, аналитик долже выступить переводчиком «со складского на программистский».
Идеальная ситуация – включение в штатное расписание склада позиции «специалист по складским технологиям». Работа для этого специалиста при внедрении WMS – есть, и ее достаточно на полную занятость.

Кстати. В договоре на поставку – желательно прописать, что «рабочие встречи по обсуждению следующих вопросов…» не тарифицируются. Иначе – заказчик начинает оплачивать сначала некачественно выполненное техзадание, а потом – оплачивает его исправление.

Обратная крайность, которой тоже может болеть команда внедрения (и сотрудники заказчика, и программисты) – чрезмерное усложнение планируемых бизнес-процессов. С одной стороны, техническая возможность системы (WMS – действительно мощный продукт, настройки которого позволяют ну очень много себе позволить в технологиях) позволяет реализовать весьма экзотические технологические схемы. С другой стороны, «мы вот тут такое придумали, надо сделать» - заказчик может предлагать как следует не продуманные схемы работы на разных участках склада, особо не вдаваясь в детали работы и согласования разных бизнес-процессов.
Лучшая профилактика с этой стороны – здоровый скепсис и ориентация на аксиому «работают простые схемы». Чем меньше усложнений мы в систему вносим – тем стабильнее она будет работать. А благими намерениями куда дорога вымощена, мы помним.

В качестве примеров не всегда оправданных решений – можно привести достаточно длинный список разнообразных фантазий:

• динамическое складирование (забыли персоналу склада объяснить, что это такое, и почему постоянно перемещается системой товар по складу)
• сценарий максимального заполнения ячеек хранения (весь весогабарит на весь товар так и не собрали, а система почему-то думает, что в ячейку хранения можно впихнуть бесконечное количество товара с объемом единицу хранения = 0.0000 куб.м.)
• планирование к отгрузке товара из ожидаемого поступления (подвело большое количество ошибок поставщиков, вызвавшее слишком много исправлений в документах)
• отгрузка товара из всех хранимых на складе партий (система выдержала, а вот персонал склада не оценил такой продвинутый сервис для клиентов).

Краткий вывод. Важные условия для успеха проекта:

• Тщательная проработка планируемых бизнес-процессов – важное условие успеха
• Ограничения на «полет фантазии» заказчика – исходя из здравого смысла и настройки на простоту процессов как залог их надежности
• Контроль над разработкой техзадания, пресекание попыток персонала поставщика «протащить» свои старые наработки «втихую». Включение в проект определенных успешных модулей с прежних проектов возможно – как сознательное решение всех членов команды
• Стандартизация склада под единую структуру адресации мест хранения
• Тесное взаимодействие с другими функциональными группами, взаимный поиск оптимальных решений.
• При возможности выбора из нескольких вариантов решений – выбираем более «эластичное» и «помехоустойчивое»,

Внедрение – третий этап. Запуск.

1. Не поддаваться панике. Все пойдет не так, как вы планировали.
2. Переходим на работу в критическом режиме, фиксируем все сбои в работе.
3. в случае возникновения сбоя:

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

4. вести статистику всех сбоев и ошибок системы. Принимать меры (в том числе непопулярные), если ошибка стала периодической (то есть не решили причину, а почему-то беремся с последстаиями)
5. Не забудьте про мотивацию персонала. Работникам на складе – никакой новый продукт не нужен. Им было и так хорошо. Соответственно, мелкий саботаж распоряжений – будет, если вы заранее не заручитесь поддержкой всего коллектива склада, Они должны быть заинтересованы в успехе внедрения. Но мотивация персонала – это уже другая тема…

Проблемы учета товара и документооборота на складах

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

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

Наименование номенклатурных позиций в справочниках

Последствия неправильного именования номенклатурных позиций – их дублирование и пересортица. «Дубли» обычно появляются как следствие не формализованного процесса введения наименований, описывающих свойства товара. Иногда новую позицию номенклатуры создает несколько человек (закупщики, менеджеры направлений или даже операторы складского учета), и каждый называет ее, как ему удобно. Или название переносится из документов поставщиков, которые также могут именовать один и тот же товар по-разному. Тогда и появляются «варианты». Например: «зарядное устройство NOKIA», «NOKIA зарядное устройство», «зарядное устройство NOKIA LCH-12».
Чтобы избежать этого, нужно жестко формализовать процесс внесения новых позиций номенклатуры, прописав иерархию свойств товара, вносимых в базу данных («паспорт товара»), и жесткую последовательность формирования названия. Например:

• введите группу товара: зарядное устройство;
• введите марку производителя: NOKIA;
• введите модель товара: LCH-12;
• введите дополнительную характеристику товара (например, цвет): black.

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

Применение штрихкодирования в учете ТМЦ

Вариант учета ТМЦ с использованием штрих-кода – тоже не панацея. Сегодня на рынке существует огромное количество наименований товаров, и практически всем присвоен штрих-код. Теоретически он не должен повторяться, но на практике через склад довольно часто проходят продукты с одинаковыми штрих-кодами. Т.е. опять приходится сталкиваться с задвоением, но уже кодов ТМЦ с различными наименованиями.
Эта проблема возникает из-за широкого применения «внутренних» штрих-кодов на складах и повторного использования производителями ранее присвоенных штрих-кодов при обновлении ассортимента. Попытка устранить задвоение путем создания на некоторые товары собственного «внутреннего» штрих-кода решает одну частную задачу, но увеличивает общее «поле неопределенности», если процесс не формализован максимально жестко (включая механизм контроля правильности изготовления и правила нанесения стикера поверх штрих-кода поставщика).

Лучший путь решения – конечно, введение EDI. Но это программа-максимум. Положительные результаты приносит и применение терминалов сбора данных и дополнительного ПО для работы со штрих-кодами. В данном случае важна способность программы при сканировании предоставить работнику перечень наименований, имеющих данный штрих-код, и предложить подтвердить одно из них.

Возникает и «обратная» проблема – встречаются случаи, когда идентичный товар из разных партий закупки имеет различные штрихкоды. Кажущееся более простым решение – ввести правило, что у некоторых товаров может быть несколько штрихкодов. Но в результате – мы создаем весьма нежелательный прецедент получаем «дыру» в операционных процессах. Более «надежным», хотя и более трудоемким, является решение всегда соблюдать жесткое правило – идентичный товар не имеет различий не только по цене и основным характеристикам, но и по второстепенным (например, по цветовому исполнению), а также по присвоенному и нанесенному на товар штрих-коду. Естественно, при партионном учете это решение будет реализовываться автоматически, поскольку различные партии и учитываются, и хранятся отдельно.

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

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

Если же создавать приходные накладные в системе заблаговременно, то:

• ошибки ручного ввода документов в учетную систему будут обнаружены на этапе приема товара и исправлены с минимальными усилиями;
• на этапе приема и размещения товара персонал сможет оперировать названиями и/или артикулами, совпадающими с терминологией расходной накладной;
• работник, занятый приемом товара, не нуждается в запоминании всех специфических особенностей в документообороте каждого поставщика, а работает по документам единого формата
• игнорирование поставщиком в расходных документах дополнительных характеристик товара (например, указания цвета) не приведет в последующем к пересортице на складе;
• преднамеренная (попытка добавить к заказу товар, который «завис» у поставщика) или непреднамеренная ошибка ввода при создании документов у поставщика также может быть оперативно выявлена, если при вводе приходной накладной будет произведена сверка расходной накладной поставщика и размещенного у заказа.

Перепроведение документов задним числом, положительные и отрицательные остатки ТМЦ
Одно из основных предназначений информационной базы оперативного учета – получение финансовых и количественных остатков на заданный момент времени. Единственный инструмент для ввода информации – документ, отражающий движение, т.е. приход либо расход расчетных значений. Соответственно, для получения остатков (задолженностей) на заданный момент необходимо просчитать все приходы и расходы от начала существования базы. Этот процесс – достаточно длительная процедура, и для его ускорения существуют такие инструменты, как Точка актуальности и Отчетный период.
Точка актуальности (далее ТА) – это дата и время последнего проведенного документа. Она показывает, что на этот момент в базе рассчитаны все остатки, и при необходимости их получения расчет производить не нужно. Если, для сравнения, сделать «Отчет по остаткам товаров» на ТА и любую более позднюю дату, то для построения первого потребуется меньше времени, так как нет необходимости рассчитывать итоги – надо только сформировать печатную форму.

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

В системе товарооборота существует такое понятие, как партии товаров. В упрощенном варианте, это совокупность ТМЦ одной приходной накладной, которая формируется в группу со своим индивидуальным номером. В БД они хранятся в таблицах регистров. Основные цели партионного учета – возможность разделить поступления ТМЦ на склад по различным признакам и предоставить информацию о движении конкретного товара.
Пример: 1 апреля на склад был принят товар X в количестве 15 шт. 15 апреля поступило еще 20 шт. этого товара, но от другого поставщика и по другой цене. За период с 1 по 30 апреля продано 7 единиц товара. Позже выяснилось, что товар, поступивший 1 апреля, имел дефекты, потому его остатки нужно вернуть поставщику. Чтобы узнать, сколько единиц товара осталось от первого поступления, нужно просто посмотреть движение товара по первой партии и сравнить расход с приходом.

Все вроде выглядит красиво, но вспомним о человеческом факторе. Зачастую люди забывают своевременно проводить документы, связанные с движением и списанием товара, или несвоевременно их изменяют. Обычно списание товара по партиям производится по методу FIFO (по себестоимости первых по времени поставок). Если в рассматриваемый период было два поступления одинакового товара, но от разных поставщиков, сначала со склада спишется весь товар первого поставщика (первой партии), и только после этого начнется списание поступлений от второго (второй партии).
Но вот что происходит, когда документы изменяются и перепроводятся задним числом.

Вариант: положительные остатки

По первой поступившей партии товар уже полностью списан, остаток = 0, началось списание по второй. Общий остаток товара на складе = 6. Но сотрудник, работающий с документами, по какой-то причине изменяет в одном из ранее проведенных документов количество товара из первой партии (который уже списан) с 4 на 3, и документ перепроводится. На первый взгляд, ничего страшного. Но если продолжить списание ТМЦ и в итоге посмотреть движения по партиям, окажется, что по первой партии появился остаток 1 шт., а общий остаток на складе = 7.

Во время дальнейшей работы со второй партии спишутся 6 шт., ведь для учетной системы первой партии уже не существует (хотя остаток по ней числится), поскольку началось списание со второй.

В итоге в учете появится единица товара, которую невозможно провести в документе без выяснения, ручного вмешательства и исправления ошибки. Со стороны пользователей это выглядит как «глюк базы», а на самом деле это «человеческий фактор».
Вариант: отрицательные остатки
Итак, сейчас 17 апреля, время 13.00, идет списание по второй партии.

• Партия 1, товар Х, остаток по партии = 0.
• Партия 2, товар Х, остаток по партии = 3.
• Общий остаток товара Х = 3.

Списание последней единицы ТМЦ партии 1, было в 17 апреля в 11.00.
Вдруг сотрудник создает новый документ на перемещение или реализацию 1 шт. товара Х и проводит его на дату и время 16 апреля, 17.00. Перед нами - классический пример создания документа задним числом, и причины создания такого документа очень убедительные (для автора этого документа). Программа позволит провести такой документ, но запросит: какой датой? Если сотрудник оставит дату без изменения, то по учету на 17.00 16 апреля списание по партии 1 еще не закончилось, товар есть, и документ при проведении спишет его в минус.
В результате получится:
Партия 1, товар Х, остаток по партии = -1. Партия 2, товар Х, остаток по партии = 3. Общий остаток товара Х = 2.
В ходе дальнейшего списания по второй партии без проблем будет списано (и отгружено со склада) 2 шт. товара партии 2. В итоге мы увидим:

• Партия 1, товар Х, остаток по партии = -1.
• Партия 2, товар Х, остаток по партии = 1.
• Общий остаток товара Х = 0.

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

Для ликвидации положительных и отрицательных остатков по партиям многие предприятия выполняют полное последовательное перепроведение документов в учетной базе за определенный период. Это выравнивает хронологию проводок по партиям и, соответственно, исправляет некорректные остатки. Но из-за перепроведения большого количества документов возникают серьезные затруднения в работе. Особенно, если БД распределенная, и все перепроведенные документы вместе с синхронизацией нужно заново выгружать в удаленную базу (этот процесс занимает много времени). После таких «глобальных» перепроведений страдают удаленные базы (филиалы и точки продаж), поскольку в момент синхронизации они не способны работать в базе и проводить реализацию товара.

Самое простое и эффективное решение проблемы положительных и отрицательных остатков – запретить какие-либо изменения остатков перед ТА. Проведение документов должно выполняться только текущей датой и временем. При необходимости «исправить» движение по товару создается отдельный документ, который проводится на общих условиях после текущей ТА.

Проблемы работы в распределенной базе

Если учетная база является распределенной, возникают коллизии и «накладывания» одних проводок на другие с замещением корректных документов некорректными.
Пример: С центрального склада А отправляется товар на склад (магазин) В. Допустим, информационный обмен между центральной и удаленной базами проходит каждый час. Расстояние между пунктами А и В небольшое, и автомобиль доставит товар за 20 мин. Предположим, в базе принят такой порядок движения ТМЦ:

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

В течение следующих 30 мин. на складе А отбирается товар, но в «родительское перемещение» внесены изменения (например, из-за недостачи одного наименования или его дефекта). Через 50 мин. товар доставлен на склад В.

Но склад В еще не получил измененный документ в свою учетную систему – если не будет сбоев связи, это произойдет через 10 мин.

Поскольку сбои связи случаются весьма часто, корректная накладная не поступила в учетную систему склада В. В результате «человеческого фактора» (не сверены реквизиты: сумма, количество позиций и штук) сотрудник склада В подтверждает прием товара в учетной системе по старому варианту накладной и создает соответствующее «подчиненное перемещение».

А после синхронизации «родительское» и «подчиненное» перемещения не совпадают и на транзитном складе появляются положительные или отрицательные остатки – в зависимости от сделанных изменений в «родительском» документе. Необходимо очередное выравнивание остатков на складах учетной системы с многочисленными изменениями уже проведенных документов и нарушениями хронологии последовательности отгрузки по партиям.
Решением этой проблемы является присвоение статуса каждому документу с разграничением по правам и признакам.