Cистемы управления складом
Выбор, внедрение и эксплуатация

Как снизить наиболее частые риски и избежать типовых ошибок в проектах автоматизации склада

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

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

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

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

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

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

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

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

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

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

Иногда бывают ситуации, когда заказчик ограничен в сроках или бюджете и не может себе позволить автоматизацию той длительности и стоимости, которые необходимы для при проектной технологии. В этом случае можно пойти более простым путем – выполнить внедрение по технологии сервисной. Ее основное отличие от проектной в следующем. При проектной технологии сначала создается описание бизнес-процессов объекта (склада) и соответствующей ему логики работы в системе, после чего уже ведется разработка. Т.е. мы хорошо представляем себе конечный результат, прежде чем начать разработку системы. Риск ошибки снижается. В случае с сервисной технологией – работы по постановке задачи и ее разработке ведутся почти параллельно. Это ускоряет проект, но повышает риски не увидеть вовремя разрывы во взаимосвязях процессов и задач по разработке. Этот подход безопасен для небольших складов с несложными процессами. Для крупного склада со сложной технологией товарообработки риск выпасть из сроков, бюджета и вероятность наделать ошибок слишком велики. Там применима только проектная технология.

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

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

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

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

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

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

Логист – специалист, в задачи которого входит сбор и предоставление данных о работе склада, проектирование и перепроектирование бизнес-процессов.

Администратор WMS – сотрудник, которому предстоит стать «суперпользователем», который по окончании проекта будет оказывать поддержку пользователям системы, перенастраивать ее при возникновении новых адресов, товаров, процессов.

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

Ключевые сотрудники, обладающие знаниями о ERP, - сотрудники, которые участвуют в постановке задачи на интеграцию с учетной системой. С ними обсуждаются вопросы обработки данных, передаваемых со склада в торговую систему.

ИТ-специалист/программист – разрабатывает интеграцию складской и учетной систем со стороны учетной, поддерживает изменения системы после проекта (если сопровождение организуется силами заказчика).

Системный администратор – решение технических вопросов, организация рабочих мест, прокладка сети и пр.

Операторы системы – основные пользователи системы. Проходят обучение во время проекта.

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

Со стороны Исполнителя рабочая команда выглядит следующим образом:

Куратор проекта – аналогично куратору Заказчика.

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

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

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

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

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

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

Далее – последовательный подход к внедрению. Существует интересное отличие в стилях управления российских менеджеров и западных. Россияне любят действовать согласно старинной русской пословице – сначала много-много напридумывать, реализовать сложную системную разработку, а потом… на складе по их мнению должно наступить счастье. А получается совсем наоборот – людям трудно освоить сразу большой объем изменений в технологии работы и, в итоге, ряд спроектированных и реализованных сложных системных решений становится ненужным на реальном рабочем складе. Налицо риск лишних трат и неудовлетворительного результата. Западный менеджмент, западные компании стараются следовать путем эволюции, а не революции, постепенно вводя в работу склада все новые и новые функции, что проходит легче, и такой проект обычно бывает более успешным.

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

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

Для того, чтобы ответить на вышеперечисленные вопросы необходимо: ознакомиться со структурой складского комплекса, с товаром и правилами хранения, с технологическими процессами и организационной структурой. А также выяснить возможности интеграции с корпоративной информационной системой (КИС). В результате обследования получаем круг задач, которые необходимо решить в рамках проекта, и условия их решения, что и фиксируется для всех заинтересованных сторон в отчете. Подобная работа по предварительному обследованию позволяет и заказчику и потенциальному исполнителю кратковременно погрузиться в реальную жизнь склада и компании в целом с точки зрения планируемого проекта, что позволяет выявить основную массу рисков до начала проекта и принять меры по снижению вероятности их проявления.

Существует подход к автоматизации складского комплекса, позволяющий достичь результата в кратчайшие сроки, при этом обеспечивает минимальные риски по срокам, стоимости и качеству. Этот подход получил название «Технология Быстрого Результата» или ТБР. Этот подход позволяет весь большой скачок от исходного склада-«черного ящика» к высокотехнологичному автоматизированному объекту разбить на простые, понятные шаги, каждый из которых приводит к очередному улучшающему нововведению в работе склада. Каждый шаг в силу своего размера легко контролируем, что делает управляемым и предсказуемым весь проект в целом.

Существуют также объективные риски, связанные с особенностями корпоративной системы, а также риски, приходящие из внешней по отношению к проекту среды. Например, риски срыва сроков строительства нового склада, подлежащего автоматизации. В частности, в практике AXELOT есть проект автоматизации склада класса «А», довольно большого и непростого по технологии работы с товаром. Несмотря на тщательное планирование и ведение работ по проектной технологии, все равно были паузы в проекте и сдвиг сроков – из-за задержек в строительстве и из-за сложностей, возникших у ИТ-подразделения компании в процессе подготовки корпоративной системы к интеграции.

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

Скачать новую версию (август 09) презентации с заметками к слайдам