Как мы автоматизировали работу со складом ЗИП и нашли свою киллер-фичу
Привет, Хабр! Мы продолжаем рассказывать о том, как команда КРОК работает с сервисными контрактами. И сегодня речь пойдет о том, что трудно найти, легко потерять и очень даже возможно забыть… О запчастях!
Под катом история о том, почему мы решили наладить работу с данными по запчастям и комплектующим, как мы это сделали на базе системы собственной разработки и как все это в итоге превратилось в нашу киллер-фичу, высоко оцененную клиентами! Эта статья может оказаться полезна всем тем, кто тоже столкнулся с ростом какой-либо номенклатуры и четко понимает, что в своей работе нужно что-то менять и автоматизировать.
В прошлом посте мы уже рассказывали о том, что для удовлетворения запросов заказчиков, которые перешли на поддержку КРОК вместо вендорской, нам пришлось кратно увеличить размер склада ЗИП. Если сравнивать 2021 и 2023 год, количество конфигурационных единиц (КЕ) на поддержке силами КРОК выросло примерно в 10 раз! Следствием этого стало увеличение количества оборудования на нашем складе в 2 раза. Это в корне изменило все наши процессы…И в этом нет ничего удивительного. Ведь раньше собственный ЗИП мы использовали, например, для оперативного ремонта своими силами по SLA, который не обеспечивал производитель, или для сервиса EOSL-оборудования (вендор уже такое старое не поддерживает, оставалось только нам со своими запчастями). Мы не развивали собственный учет — у нас была налажена схема заказа запчастей у вендора, и нам было вполне достаточно, условно, почты и 1С.
Теперь все иначе, и запчастей на складе много. А это несет свои проблемы:
Их нужно где-то хранить. Количество запчастей выросло кратно, а, значит, нам нужно было избегать лишних запасов
Они стоят денег. Закупая те комплектующие и запчасти, которые, скорее всего, не будут востребованы в таком объеме, мы ухудшаем кешфлоу
Скорость поставки запчастей стала медленнее. Теперь нам нужно ждать каждый заказ порядка 2 месяцев, и большими партиями никто ничего не поставляет
Раньше мы информацию по конфигурациям вообще не собирали и не хранили, так как это было не нужно. Ведь любую запчасть вендор выдавал. Вендор исчез из уравнения, и мы остались с конфигами один на один…
Еще в прошлом году стало понятно, что вручную мы не справимся со всеми этими задачами. Инженеры начали тонуть в заявках, в документации стали появляться белые пятна, а планировать заполнение склада стало проблематично. С этим нужно было что-то делать.
Решение — СУСтематизация!
Обдумав все это, мы стали искать варианты, как можно улучшить наши процессы быстро, а главное — эффективно! Ведь SLA никто не отменял, и часики тикают. Так мы и вспомнили про СУС! И вовсе не про тот, что вы сейчас подумали.
СУС — это наша ситема управления сервисом, собственная разработка. Ее создали в бородатом 2012 году для сервисных подразделений КРОК, чтобы им было удобно вести базу сервисных контактов и управлять ею. Тогда сервис-менеджеры вносили в нее только оборудование, которое было прописано у нас в договоре, и программу его обслуживания (график и сроки обслуживания, в какие сроки должны починить и тд).
В общем, взяли мы старую-добрую СУС и начали вместе с нашими разработчиками допиливать в ней функционал по запчастям. Засучив рукава, мы стали вручную собирать все конфиги по всему оборудованию на поддержке. Инженеры связывались с заказчиками и запрашивали логи, перелопачивали их и составляли списки. Плюс мы начали искать информацию по базам вендоров. Были еще те, кто еще не закрыли порталы, где можно по серийному номеру выгрузить поставочную конфигурацию конкретной единицы оборудования. Зачем нам все эти сложные упражнения, спросите вы? По каждой позиции нам важно понимать ее «набивку»: какие конкретно компоненты и в каком количестве стоят в том или ином сервере или СХД. Дальше мы все это дело суммируем и уже видим всю картину целиком, какие запчасти у нас на поддержке и сколько их по всем контрактам. Из этой точки мы уже можем правильно планировать начальные резервы. А если вдруг появляется запчасть, которой у нас еще нет, срочно ее закупаем!
Всю собранную информацию мы вместе с коллегами-разработчиками порционно вливали в СУС. И вот что у нас получилось:
Но и это еще не все! Как говорится, современные проблемы требуют современных решений. И в случае сервиса вычислительного оборудования — это аналоги для запчастей, которых либо нет/мало в наличии у нас на складе, либо их уже нет вообще. Естественно, в последнее время мы стали гораздо чаще сталкиваться с необходимостью поиска замены для комплектующих. При этом надо понимать, что для одного компонента аналогов может быть 1–2, а для другого — 10–20. Некоторые позиции могут быть взаимозаменяемыми, а другие — нет. В общем, держать такую информацию в разрозненных документах или, не дай бог, в голове — максимально неэффективно! В результате мы начали связывать собранные конфиги между собой в СУС, из чего получился дополнительный функционал «Аналоги запчасти».
Отдельным треком шла работа по повышению производительности системы. Коллеги искали в ней лаги, меняли настройки в работе системы с базой данных (чтобы запросы к БД были построены максимально оптимально), переводили на последнюю версию .NET. А еще к системе прикрутили Jira, чтобы можно было быстро и удобно создавать заявки на выдачу запчастей и в целом сделать процесс движения запчасти более прозрачными.
И в итоге за один квартал мы создали на основе СУС огромную (и удобную) базу знаний по запчастям на поддержке и их аналогам.
Вот такие нотификации СУС отправляет нам в почту
А что за киллер-фича?
В один прекрасный момент мы задумались, как бы нам отследить реальное движение запчастей на складе? Ведь каждый день запчасти используются под ремонт, но разные компоненты расходуются с разной частотой. Допустим, у запчасти A динамика расходования 2 штуки в неделю, а у B — 1 штука в месяц. Мы поняли, что консолидация таких данных за определенный период времени могла бы помочь нам эффективнее планировать закупки и избежать излишков/дефицита запчастей на складе. Именно это мы и сделали!
Так как весь складской учет у нас ведется в 1С, мы еженедельно стали делать компиляцию из трех отчетов:
Отчет, который показывает, когда запчасть передавалась в руки инженеру
Он позволяет увидеть, какие запчасти «убежали» со склада. Но мы ведь не знаем, для чего инженер её берет — для теста, для демо или непосредственно для ремонта. Поэтому мы делаем отчет №2 и это…Еженедельный срез по складу по наличию всех запчастей
Он позволяет оценить, уменьшается ли количество единиц по каждой выданной запчасти. Увидеть, как быстро или медленно они расходуются (как раз то, что выдавалось в руки инженеру). Исходя из этого, мы можем решить, нужно ли нам ещё закупать такие запчасти или нет. Ведь если, допустим, осталась последняя, а у нас ещё там на два года контрактов с оборудованием, в котором она нужна, значит новые нужны как можно скорее.Заказы
Этот срез позволяет посмотреть, есть ли конкретная деталь в уже оформленных заказах.
Эта компиляция позволяет увидеть реальное положение дел и дает возможность корректировки планов закупок. В итоге мы и тратить стали меньше, и без запчастей не остаемся.
И тут случилось самое интересное! Спустя три месяца еженедельного изучения этих отчетов по запчастям, мы начали фиксировать любопытные закономерности в поведении того или иного оборудования. Мы наглядно увидели, как, условно, в сервере вендора M часто выходит из строя запчасть N, а вендора X — запчасть Y. То есть мы, конечно, и раньше это замечали, но в своих выводах опирались на опыт и личные наблюдения. А сейчас мы получили документальное подтверждение своим гипотезам. И в итоге обсуждая сервисный контракт с новым заказчиком, это позволило нам на старте довольно четко спрогнозировать поведение описанного в нем оборудования, частоту его поломок и просчитать затраты на сервис.
Заказчик был приятно удивлен нашим уровнем компетенций, а мы нашли свою киллер-фичу!
Вместо заключения
Проделав все эти упражнения, мы увидели, что:
У нас повысилась точность учета и улучшился контроль движения запчастей
И это относится к выдаче, возврату и в целом ко всему учету, который связан с запчастями после их использования.Мы начали вовремя списывать запчасти
То есть обычно запчасти списываются под проект, чтобы можно было рассчитать общие затраты на него. И вот, допустим, деталь физически вернулась в КРОК, но еще не подгрузилась в 1С, потому что инженер вполне может никому ничего не сказать. И ладно если контракт еще действует какое-то время, а если он закончился, то эти деньги повисли в воздухе.Соответственно, на складе мы занимаем меньше места
Ничего не копится, все своевременно утилизируем. Иронично, но даже несмотря на это, рост по номенклатуре и количеству запчастей у нас такой, что нам все равно пришлось экстренно расширять складские помещения.Себестоимость правильно считается
Мы стали тратить меньше времени на дозакупку
Цикл дозакупки уменьшился кардинально благодаря нашим еженедельным отчетам. Раньше на дозакупку 2 человека тратили по полдня — в сумме 1 день в неделю. И это только на то, чтобы просмотреть все заявки за неделю, обработать их и куда-то вынести инфу, какие запчасти куда выдавались. Собрать и посмотреть, сколько чего в наличии и что надо докупать. А сейчас это все есть в готовом виде и занимает 1 час времени 1 человека.
Следовательно, человеческий фактор сводится практически к нулю
Само собой, это мы за себя говорим. Проблемы на третьей стороне все равно могут быть независимо от нас (задержка с доставкой, повреждение груза и т.д.) Тем не менее сложив все слагаемые, риск того, что у нас на складе в нужный момент чего-то не будет, сводится к минимуму.
В обозримой перспективе мы прикрутим к СУС еще и 1С, чтобы в СУС сразу были видны еще и все запчасти на складе. А там, глядишь, и до BI рукой подать… Но это уже совсем другая история
Подписывайтесь на уютный Telegram-канал КРОК и чувствуйте себя как дома!
