ITOGO
+380 (44) 496-00-46


  • Архив

    «   Декабрь 2017   »
    Пн Вт Ср Чт Пт Сб Вс
            1 2 3
    4 5 6 7 8 9 10
    11 12 13 14 15 16 17
    18 19 20 21 22 23 24
    25 26 27 28 29 30 31
                 

Внедрение WMS. В поисках "гарантированного" метода внесения остатков

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

Как это обычно происходит?
В назначенный час «Ч», когда система развернута на платформе заказчика, номенклатурный справочник WMS синхронизирован с учетной системой, местонахождения склада промаркированы адресами, персонал склада Заказчика прошел обучение, а складские специалисты по учету ТМЦ привели в порядок все «учетные остатки» начинается ИНВЕНТАРИЗАЦИЯ!
Поскольку объем работы достаточно большой, а сроки как обычно очень сжатые, компания-Заказчик готова бросить на эту работу все доступные ресурсы, вплоть до менеджеров из офиса. И, после очередного инструктажа, «боевые отряды» инвентаризаторов, вооруженных инвентаризационными ведомостями либо терминалами сбора данных разбредаются по своим участкам, стеллажам, проходам.
И тут начинает происходить настоящее волшебство. На полках стеллажей материализуются товарные позиции, о наличии которых давно забыли, в тоже время количество актуального товара гораздо меньше учетных остатков; параллельно с этим регистрируются не известные ранее серии товара, находятся экземпляры товара с серийными номерами, которые никогда не приходовались складом.
Самое интересное, что до окончательного завершения инвентаризации, никто и не подозревает о наличии расхождений. И вот, после того, как проделан титанический труд (обычно это более суток напряженной работы) выясняется, что остатки не сходятся с учетными, причем расхождения не в двух-трех позициях, а в десятках и сотнях, в крайних ситуациях могут быть и тысячи «небьющихся» строк.
Как и всем «чудесам», таким «фокусам» с товарными остатками можно найти вполне логичное объяснение. В большинстве случаев различия в остатках могут быть объяснены беспорядком в номенклатурном справочнике компании Заказчика, например, когда товару, который физически хранится на складе и внешне не отличается между собой, соответствуют две-три-четыре номенклатурные позиции в справочнике учетной системы (товар + бесплатная реклама/подарок/акция и прочее). Так же распространённой причиной нестыковок является низкий уровень контроля в процедурах приемки и отгрузки товара, но о них не сейчас.
Запуск процедуры синхронизации учетных остатков с «фактическими» (в кавычках потому что, они фактические только отчасти) в подобной ситуации невозможен, т.к. этим мы моментально перенесем складской беспорядок в оперативный и бухгалтерский учеты. Ни один здравомыслящий руководитель не даст этого сделать. «Лекарство» может быть одно - повторная инвентаризация, но и она не «панацея». Чтобы «лекарство» было действенным второй проход инвентаризации необходимо выполнять, имея на руках товарные остатки по данным оперативного учета. В результате складские остатки неизбежно будут «подогнаны» под учетные. На выполнение этой процедуры необходим срок как минимум 2/3 времени, от затраченного на первый пересчет. Возможно, понадобится и третий пересчет. И если руководство компании Заказчика может пойти на отсрочку запуска работы склада – однозначно необходимо выполнить повторный пересчет «небьющихся» позиций.
Время на повторный пересчет есть не всегда, и, несмотря на то, что все понимают, что с такими остатками начинать промышленную эксплуатацию нельзя, эмоции берут свое, ведь далеко не каждый сможет взять ответственность и перечеркнуть результаты «трудового подвига» и перенести запуск склада на более поздний срок. В результате новая технология и WMS таки вводятся в промышленную эксплуатацию с остатками, полученными в результате «инвентаризации». О том, чем такая «эксплуатация» чревата, вы как минимум догадываетесь, если не пережили подобных ситуаций на личном опыте.
Лично у меня такой опыт был. После пережитого возникло острое желание разработать новую процедуру внесения первоначальных остатков, которая избавит проект от рисков запуска с «кривыми» остатками. Наверняка, кто-то скажет мол «зачем изобретать велосипед» «все уже придумано до нас»! И я с ним отчасти согласен, но, к сожалению, на таких «велосипедах» я не «катался», и не встречал их описания. Более того, я уверен, что подобные технологии внесения остатков давно существуют, но никто не торопится ими делиться )).
Я не претендую на роль Прометея и «божественным огнем» ни с кем делиться не собираюсь, поскольку у меня его нет! Но некоторые мысли как его добыть имеются.

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

Какие преимущества дает данный метод?
При таком внесении первоначальных остатков WMS изначально страхует и подсказывает Инвентаризатору, в каком соотношении числятся остатки задублированных номенклатурных позиций, что изначально может избавить от массы проблем в будущем.
Наибольший эффект может быть достигнут в случае применения терминалов сбора данных, с программным обеспечением, которое поддерживает режим перемещения товара «по инициативе» Исполнителя. «Бумажная» технология будет более трудоемкой.
Для старта работы новой технологии обработки товара не требуется проведения «полной инвентаризации». При этом в течение первого времени технология адресного хранения не будет использоваться. На складе будет несколько (по числу логических/физических складов) виртуальных местонахождений с остатками из учетной системы, комплектация же будет выполняться не по адресам, а по памяти, как это и происходило ранее.
После того, как будут «отшлифованы» процессы приемки и отгрузки, работа оборудования и шлюза между учетной и складской системами, можно приступить к сверке товарных остатков и к их распределению по местонахождениям склада. Технологически процедура будет выполняться как ПЕРЕМЕЩЕНИЕ товарных остатков из виртуальных местонахождений в реальные места хранения. Причем предлагаемая технология ввода первоначальных остатков не требует проводить инвентаризацию сразу всех местонахождений склада, это можно делать постепенно. Инвентаризируя, например, стеллаж в день.
Местонахождения, остатки в которых пересчитаны должны быть соответствующим образом промаркированы (визуально). Это делается для того, чтобы при комплектации Сборщик комплектовал товар из пересчитанных и промаркированных местонахождений исключительно в тех случаях, когда требуется отборка именно их этих ячеек, а не из «виртуальных». Когда же в сборочном листе указано виртуальный адрес – сборщик комплектует товаров оттуда, где найдет, кроме «проинвентаризированных» местонахождений.
Местонахождения, которые не прошли процедуру инвентаризации, должны быть заблокированы в WMS, для того, чтоб они не подбирались системой для размещения нового товара, оприходованного от поставщика, ведь они числятся в системе как пустые. Блокировка с них снимается только после инвентаризации остатков в данном местонахождении.
Размещение товара принятого на хранение, как уже говорилось ранее, производится только в пустые доступные местонахождения и адреса, прошедшие процедуру инвентаризации (с товарным остатком).

Постепенно все местонахождения склада будут инвентаризированы, и новая технология обработки товара заработает на полную мощь.
Необходимо отметить, что запуск новой технологии обработки товара по такому сценарию не будет сопровождаться резким повышением производительности комплектации за счет внедрения системы адресного хранения, зато существенно снизит нагрузку на проектную команду, что даст возможность больше внимания уделить проблемам, которые неизбежно возникнут в других складских процессах.
Разумеется, что такая технология внесения первоначальных остатков может подойти далеко не каждому объекту складской логистики. Например, она явно не подходит для совершенно новых складов, которые запускаются «с нуля». Но в случае автоматизации работающего склада, считаю ее вполне уместной, в особенности, если внедряемая технология подразумевает применение терминалов сбора данных.
Буду рад выслушать Ваши предложения и вопросы по данной теме! Может кто-то готов поделиться другим, более технологичным способом внесения первоначальных остатков в WMS?

ПРОЕКТ АВТОМАТИЗАЦИИ «в столбик» (ч.3)

Приветствую Вас!
В прошлый раз мы остановились на том, что необходимо уделить особое внимание фигуре Технолога, и его "погружению" в проблематику проекта. Сегодня же предлагаю поговорить других аспектах выполнения продолжительных, многоэтапных и технологически сложных проектов. При выполнении длительных проектов рабочую группу проекта, кроме всего прочего подстерегает еще одна «опасность» или, если хотите, угроза – проектные документы, созданные на начальных фазах проекта, имеют свойство утрачивать свою актуальность. В особенности это касается документов, которые описывают предлагаемое решение или требование к решению по какой-либо локальной задаче. Обычно это случается незаметно для глаз даже опытного менеджера проектов: на собрании с участием руководства компании Заказчика принимается решение, которое напрямую не затрагивает задачу или вопрос, описанный одним из созданных ранее документов. Но при дальнейшем детальном рассмотрении оказывается, что принятое решение в одной из своих «плоскостей» противоречит условиям, которые были зафиксированы ранее, либо же происходит их усложнение. В этом случае недостаточно зафиксировать решение Проектного комитета в протоколе совещания. Уже на этапе написания протокола Менеджер Проекта автоматически должен добавит пункт в «Решили» «Произвести актуализацию проектных/технологических документов в связи с решением, изложенным в п.№__». Актуализацию проектных документов выполняет Менеджер Проекта, технологические документы актуализируются одним из аналитиков проекта (возможна схема закрепления документов за конкретными аналитиками). Необходимо помнить, что актуализация документов требует времени, а время - это деньги. Следующим вопросом является: "Кто оплатит изменение технологии, решение о котором принял Проектный Комитет?" А трудозатраты могут быть достаточно ощутимыми. Поэтому, вопрос на выделении бюджета на то или иное "изменение" должен быть оговорен на том же совещании, когда и было принято решение о внесении изменений в согласованную ранее технологию или какой-либо документ. Если этот вопрос не поднять, эта работа будет проделана бесплатно, а ответственность за ее негативное влияние на сроки всего проекта будет лежать на Менеджере Проекта.
Вопрос внесения изменений в технологию «налету» (без детальной проработки и документирования) необходимо категорически исключать уже на ранних стадиях общения с Клиентом. Эту мысль необходимо доносить до Заказчика каждый раз, как только он захочет добавить очередной «бантик», связанный с «динамичностью его бизнеса» и прочими «вескими» причинами. Актуальные согласованные документы, желательно с "мокрыми" подписями участников Проектного Комитета, в этом случае должны быть преградой на пути хаоса, который вносится «волевыми» решениями Заказчика.
Вы должны понимать, что если Вы пойдете на поводу у Заказчика и сделаете «доброе дело» быстро и без лишней бумажной волокиты, Вы ставите под угрозу весть проект, и никто кроме Вас за это отвечать не будет. Даже если документирование и детальный анализ влияния решения Проектного Комитета потребует переносов глобальных сроков проекта, нельзя соглашаться на переход в режим работы «на коленках» - это верный путь к провалу.
На завершающих стадиях сложных проектов неизбежно накапливается целый список требований и работ, которые, по мнению Заказчика, должны непременно быть выполнены. При этом перед Менеджером Проекта со стороны Исполнителя стоит задача контролировать попадание этих задач в границы выполняемого проекта. По возможности он должен отстаивать первоначальные границы, т.к. именно они закладывались в календарные планы работы не только проектной группы, но смежных подразделений и, возможно, внешних подрядчиков. Он как голкипер должен отбивать атаки на ворота совей команды – границ проекта. Каждое пропущенное дополнительное требование – это гол! Все обязательные для реализации требования Заказчика должны качественно документироваться. По договоренности сторон дополнительные пожелания могут быть реализованы в рамках следующих проектов. Если требование критично для старта проекта и «гол» был пропущен, это требование должно быть зафиксировано в соответствующих проектных или технологических документах, а календарные сроки выполнения работ и бюджеты пересмотрены. Если допускать внесение изменений в обход соответствующей процедуре, границы проекта размываются, проект становится неуправляемым и в один «прекрасный момент» проектные работы превратятся в хаотическое затыкание дыр.
Качественно составленные, актуальные и работающие проектные документы это один из механизмов контроля завершения проекта. Именно они в итоге должны выступать мерилом завершенности проекта. Если возникает подозрение, того что критериями выполнения проекта является или может являться некая другая шкала, например, «удовлетворение потребностей клиента» - необходимо инициировать актуализацию критериев завершения проекта через Проектный Комитет со всеми вытекающими последствиями (изменение сроков, бюджетов и т.п.). Эта процедура позволит контролировать статус-кво на проекте.
Необходимо помнить, что проект модернизации технологических процессов с последующей автоматизацией не может быть односторонним.
Успех проекта возможен только в случае активного участия всех заинтересованных сторон, задача Менеджера проекта контролировать и управлять участием Исполнителя и Заказчика в движении к поставленной цели!
Желаю Вам успехов в собственных достижениях! До новых тем!

ПРОЕКТ АВТОМАТИЗАЦИИ «в столбик» (ч.2)

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

После проведения аудита технологических процессов в состоянии «AS-IS» (как есть) наступает этап проектирования новой технологии «To-Be» (как должно быть). На этой фазе проекта необходимо уделить особое внимание погружению заказчика в новую технологию работы подразделения, во всех ее проявлениях и мелочах.
В большей степени погружение в новую технологию должно коснуться будущего Технолога. Технолог – это специалист со стороны Заказчика, который после завершения проекта, будет контролировать работу новых процессов, адаптировать их под изменения окружающей среды и обучать новых исполнителей. На период проекта Технолог должен быть максимально освобожден от выполнения своих «основных» обязанностей и быть по максимуму задействованным в проектных работах (минимум 50 % рабочего времени).
В большинстве случаев выбор будущего Технолога становится «краеугольным камнем» всего проекта. Технолог должен сочетать в себе знание всех нюансов «старой схемы работы», осознавать необходимость изменений и быть в них заинтересованным. В дальнейшем он до мелочей должен будет овладеть новой технологией выполнения процессов и быть готовым нести за нее ответственность. Технолог должен обладать неоспоримым авторитетом в компании Заказчика не только в глазах ее руководства, но и среди рядовых сотрудников. Отсутствие такого «технологического лидера» со стороны Заказчика не раз приводило к сложностям при выполнении проектных задач, а порой являлось причиной приостановки сложного продолжительного проекта. Без такого человека на проекте приступать к реинжинирингу и проектированию работы такого сложного механизма, как логистический контур компании, просто бессмысленно.
Зачастую выполнение роли Технолога на себя берёт один из топ-менеджеров компании, т.к. по его мнению, он наиболее осведомлен о работе компании в настоящий момент и лучше всех понимает, что необходимо получить в результате проекта. На первый взгляд такое предложение может показаться заманчивым, и нет необходимости сразу отказываться от такого «влиятельного» технолога, но при этом необходимо очень четко контролировать выполнение ролевых обязанностей. Случаются и обратные ситуации, когда на роль технолога выдвигают человека, который изначально не способен справиться с этой ролью. Действия менеджера проекта в первом и во втором случае должны быть аналогичны. И при первом же нарушении, которое обычно происходит из-за дефицита времени, недостатка квалификации или же необходимости решения более насущных для фирмы проблем - поднимать вопрос о назначении другого специалиста, соответствующего всем выдвинутым выше критериям.
Если этого не сделать и оставить на роли технолога человека, который таковым по сути не является - Вы должны быть готовы самостоятельно нести ответственность за работоспособность и «живучесть» спроектированной технологии в условиях компании Заказчика.
При этом необходимо помнить, что наличие Технолога не освобождает от детального документирования всех решений принимаемых в рамках проекта, а так же от создания набора регламентной документации (согласно действующей Методике Описания Бизнес Процессов).
Необходимо как можно раньше начинать знакомство Заказчика (обычно в лице Технолога) с внедряемой Информационной системой: ее архитектурой, особенностями реализации тех или иных функций. «Ранее знакомство» позволит минимизировать количество возможных проблем на фазе автоматизации, которые связаны с ложными представлениями Заказчика о возможностях «всесильных» систем управления (WMS, TMS, YMS и т.п.), так же это даст возможность привлечь Технолога в качестве дополнительного ресурса на этап настройки и тестирования прототипа Информационной системы.
Продолжение следует...

ПРОЕКТ АВТОМАТИЗАЦИИ «в столбик» (ч.1)

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

С моей точки зрения, именно на этом этапе не стоит торопиться. Для проектного менеджера фаза начала проекта является наиболее значимым этапом, т.к. именно в этот период цели проекта, изложенные в коммерческом предложении, должны обрести четкие, понятные и измеримые очертания. Документом, который может включить в себя все значимые аспекты будущего проекта, является Проектное задание.
Проектное задание должно представлять собой точный четкий и, по возможности, не трактуемый документ. В нем должны быть зафиксированы цели и задачи проекта, конкретно сформулированы критерии выполнения проекта, описана структура действий, посредствам которых будут достигаться поставленные цели. В нем должна быть описана структура проектной команды и распределены полномочия и обязанности участников проекта, сформирован список участников Проектного Комитета. В Проектном Задании должен быть указан Менеджер Проекта со стороны Заказчика. Это именно то лицо со стороны Заказчика, куда Вы (как менеджер проекта со стороны Исполнителя) должны обращаться при первой необходимости.
Одним из наиболее значимых приложений к Проектному заданию является Календарный План Проекта. В этом документе список задач детализируется и обретает конкретные очертания и привязки ко времени, пространству и ресурсам, которые будут задействованы в выполнении работ. Необходимо обязательно совместить расписание выполнения задач с графиком отпусков и общегосударственными праздниками, согласовать и синхронизировать календарь проекта со смежными подразделениями, которые хоть как-то будут принимать участие в проектных работах.
Готовый комплект проектных документов должен быть согласован с Заказчиком. До того, как будут расставлены все точки над «i» начинать какое-либо движение по проекту нельзя, причем категорически. Вас могут обвинить в бюрократии и волоките, но в своей позиции вы должны быть непоколебимы, т.к. проектные документы это не просто бумажки, а правила игры с очень высокими ставками. И вы, как ни кто другой, должны понимать это. И только после того, как проектные документы утверждены, можно засучив рукава приниматься за работу.
Продолжение следует.....

Приветствие!

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