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

Ошибки в техническом задании

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

Если речь идет, скажем о WMS, считается, что это касается только склада, а значит, его специалистам и карты в руки (причем это – в лучшем случае). Мало кто вспоминает о том, что после внедрения системы «правила игры» изменятся для всех подразделений, которые так или иначе со складом контактируют: для отделов производства, продаж, закупок, маркетинга, информаци онных технологий и т.д.

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

Сбыт и продажи

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

Посмотрим на конкретном примере:

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

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

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

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

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

Четкость и точность для всех подразделений — залог успешной автоматизации компании.

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

Из практики:

Возникает событие — WMS не позволяет принять самый обычный товар. На выяснение причин уходит время, а оказывались они весьма банальны – вес паллеты был указан 20 т. Ясно, что сотрудник, который вводил данные, в спешке просто забыл поставить запятую. Кладовщик на такую ошибку даже внимания не обратил бы, а система не смогла найти подходящего носителя и отказалась принимать товар.

Компьютерная программа, в отличие от человека, не может «соображать на ходу» и не приемлет компро миссов. К примеру, если в ней заложено правило, что склад принимает товар, срокгодности которого истек не более чем на 2/3, из него не будет исключений. Просрочку на 1 день при общем сроке хранения 6 месяцев любой кладовщик посчитал бы несущественной, а WMS такой товар принять не позволит. Т.е., внедрив АСУ, компания и каждый ее сотрудник будут просто вынуждены четко соблюдать установленные правила, поскольку любое их нарушение, вольное или невольное, будет приводить к сбоям и осложнениям.

Производство

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

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

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

От наличия и корректности данных о весогабаритных характерис тиках грузов напрямую зависит возможность рационально использовать полезный объем склада и прочие ресурсы. Ведь если, скажем, на производстве решили паковать чуть больше продукции на паллету, ее высота увеличится (пусть даже на 3–5 см!), и она может просто не войти в складскую ячейку. А увеличение веса единицы хранения ограничено несущей способностью стеллажей. Порой отсутствие этих цифр может дорого обойтись складу и компании в целом. В то же время грамотная работа с информацией о габаритах грузов позволяет оптимизировать потребность в ресурсах. Благодаря, например, внедрению определенных алгоритмов размещения.

Как правило, размеры ячеек хранения в многономенклатур ных складах задаются по максимальной высоте паллет, с которыми приходится работать – чаще всего 1,8–2 м. Но в ассортименте ведь есть и мелкие паллеты – по 60, 80, 120 см. Треть, а то и половина объема ячеек, в которых они хранятся, пустует, в то время как компании приходится дополнительно закупать оборудование или арендовать складские площади.

На одном из отечественных предприятий нашли интересный выход – проанализировали статистику с тем, чтобы определить среднее процентное соотношение паллет разной высоты, и переделали часть стеллажей согласно полученным данным, уменьшив высоту ячеек до 60, 90 и 120 см и, соответственно, увеличив количество ярусов. Параллельно разработали алгоритм размещения грузов в зоне хранения с учетом весогабаритных характеристик, чтобы система автоматически подбирала ячейку нужной высоты для каждой прибывшей паллеты. Благодаря этому емкость зоны хранения увеличи лась примерно на 15–20%. Но подобные решения дают ожидаемый эффект лишь при условии, что вся необходимая информация поступает в складскую систему своевременно и в полном объеме, а это в немалой степени зависит от смежных подразделений и правил взаимодействия с партнерами.

Маркетинг

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

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

ІТ отдел

О месте и роли отдела информационных технологий в процессах внедрения и обслуживания АСУ, казалось бы, и говорить излишне – каждый знает, какмно го зависит от его специалистов в этом нелегком деле. Начиная с того, как технически будут реализованы процессы взаимодействия WMS с ERP, будет ли происходить обмен данными автоматически или «в ручном режиме» (с кнопочкой «выгрузить», о которой шла речь выше). Кроме того, на отдел ІТ ложится достаточ но большой объем работ по обслуживанию оборудова ния, которое появляется на складе (WI FI, точек доступа, радиотерминалов, принтеров печати этикеток и т.п.), а также каналов связи.

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

Недавно приходится столкнуться с ситуацией когда в компании завершается внедрение WMS, установлена операционная система, 15 минут до запуска склада в промышленную эксплуатацию. И тут выясняется, что на одном из принтеров необходимо настроить или переустановить драйвер. Права доступа на сервер специалистов службы поддержки поставщика системы строго регламентированы, внести изменения в драйвера принтера они не могут. Обращаются к ІТ отделу и слышат в ответ: «Оформляйте заявку, скажите, какие надо внести изменения в настройках драйвера, либо просите добавить вам необходимые права. По инструкции у нас два часа на решение данного вопроса – вернемся с обеда и все сделаем». Тогда руководителю проекта со стороны заказчика приходится звонить директору компании, чтобы ускорить решение вопроса. Но таких проблем не возникало бы, если бы схема взаимодействия между отделами изначально была лучше продумана. Как, впрочем, и порядок согласования времени проведения регла ментных работ. Обычно ІТ службы прежде всего и в первую очередь отвечают за сопровождение ERP сис темы, а обслуживание WMS для них – лишь дополни тельная нагрузка. И часто они упускают из виду, что складская система управляет процессами в режиме реального времени, и если она останавливается, склад фактически не может работать. Причем причина остановки не имеет значения – будь то сбои в канале связи, отказ WI FI или перезагрузка сервера.

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

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

Система работы с системой

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

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

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

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

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

Как итог хотелось бы еще раз перечислить те составляющие проекта внедрения WMS, которые помогают оптимальным образом «вписать» автоматизированную систему в систему работы компании. Это:

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

Без этого трудно надеяться, что АСУ буквально с первых дней станет действенным инструментом для повышения эффективности работы компании.