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