НОВАЦИИ КОНСАЛТ. Услуги психолога, тренинг личностного роста, психологический тренинг "Избавление от лишнего веса Навсегда", материальное стимулирование, психология управления, командообразование, клуб любителей камня "Музыка Земли", минералогические семинары и экскурсии, HR-программы, бизнес тренинги.

Автор: Виктор Барановский

Конечно, основное «право голоса» - за финансовым директором и руководителем ИТ-департамента. Но, тем не менее… Поскольку 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 мин.
Поскольку сбои связи случаются весьма часто, корректная накладная не поступила в учетную систему склада В. В результате «человеческого фактора» (не сверены реквизиты: сумма, количество позиций и штук) сотрудник склада В подтверждает прием товара в учетной системе по старому варианту накладной и создает соответствующее «подчиненное перемещение».
А после синхронизации «родительское» и «подчиненное» перемещения не совпадают и на транзитном складе появляются положительные или отрицательные остатки – в зависимости от сделанных изменений в «родительском» документе. Необходимо очередное выравнивание остатков на складах учетной системы с многочисленными изменениями уже проведенных документов и нарушениями хронологии последовательности отгрузки по партиям.
Решением этой проблемы является присвоение статуса каждому документу с разграничением по правам и признакам.

Материал взят с сайта www.ukrlogist.com

Ваш коментарий будет первым

Только зарегистрированные пользователи могут оставлять коментарии.
Пожалуйста зарегистрируйтесь или войдите в ваш аккаунт.