В советских домах контроль доступа делали не только через домофоны. Попадались и **электронные кодовые замки** — железо, которое ставили даже там, где о подъездной связи никто не думал.
Почему я называю такой замок суровым? Потому что у него логика простая: ввёл код — прошёл, ошибся — стоишь. Без облаков, без приложений, без «сбой на стороне сервиса» 🙂
Для склада это знакомая философия: минимум лишних звеньев, максимум понятного действия. Если механизм работает в грязи, на износе и без лишней электроники — это уже хороший признак.
У таких решений был свой плюс: их можно было внедрять точечно и без большой инфраструктуры. Минус — любая механика и контактная группа быстро показывают, где слабое место. А дальше всё как на приемке: один плохо отработанный узел ломает весь процесс.
Почему я называю такой замок суровым? Потому что у него логика простая: ввёл код — прошёл, ошибся — стоишь. Без облаков, без приложений, без «сбой на стороне сервиса» 🙂
Для склада это знакомая философия: минимум лишних звеньев, максимум понятного действия. Если механизм работает в грязи, на износе и без лишней электроники — это уже хороший признак.
У таких решений был свой плюс: их можно было внедрять точечно и без большой инфраструктуры. Минус — любая механика и контактная группа быстро показывают, где слабое место. А дальше всё как на приемке: один плохо отработанный узел ломает весь процесс.
Я регулярно вижу одну и ту же историю: в компании появляется новый «ускоритель», и все начинают подгонять процесс под него. Не под задачу, не под SLA, не под ограничения системы — а под модный инструмент.
С ИИ в разработке сейчас ровно так же. Руководство хочет быстрый эффект: пусть код пишет агент, пусть джуны станут «в 2 раза продуктивнее», пусть все пройдут воркшоп и завтра начнут работать по-новому. На бумаге красиво. На складе тоже много чего красиво на бумаге.
Проблема в другом: если процесс кривой, ИИ его не чинит. Он просто быстрее размножает ошибки. Неполные требования, слабая приемка, плохие границы ответственности, отсутствие контроля качества — всё это никуда не девается. Только теперь скорость выше, а разбор инцидента дольше.
Я это вижу как обычную операционку: инструмент должен усиливать уже собранный процесс, а не заменять его. ИИ полезен там, где есть регламент, проверка и понятный результат. Без этого получается не трансформация, а дорогой способ быстрее наделать брака.
С ИИ в разработке сейчас ровно так же. Руководство хочет быстрый эффект: пусть код пишет агент, пусть джуны станут «в 2 раза продуктивнее», пусть все пройдут воркшоп и завтра начнут работать по-новому. На бумаге красиво. На складе тоже много чего красиво на бумаге.
Проблема в другом: если процесс кривой, ИИ его не чинит. Он просто быстрее размножает ошибки. Неполные требования, слабая приемка, плохие границы ответственности, отсутствие контроля качества — всё это никуда не девается. Только теперь скорость выше, а разбор инцидента дольше.
Я это вижу как обычную операционку: инструмент должен усиливать уже собранный процесс, а не заменять его. ИИ полезен там, где есть регламент, проверка и понятный результат. Без этого получается не трансформация, а дорогой способ быстрее наделать брака.
Когда у тебя не один склад, а десятки удалённых точек, Wi\-Fi перестаёт быть «удобством» и становится частью SLA.
У Яндекса для этого сделали два мобильных сканера: под Android и iOS. По сути — карманный инструмент для быстрого обхода сети на месте: замерить параметры, понять, где просадка, и не гонять сетевого инженера на каждый сбой по офису, складу или даркстору.
Логика мне близка: **если проблему можно диагностировать с телефона, её надо диагностировать с телефона**. На складе это экономит не только время ИТ, но и простои на приемке, отгрузке и сборке. Пока руками ищут «почему отвалился Wi\-Fi», операция уже тормозит.
Нормальный операционный подход: меньше выездов, быстрее диагностика, меньше слепых зон. `Комбайн` для сетевика — это не игрушка, а способ держать удалённую инфраструктуру в рабочем режиме.
—
Больше про нутра — @NutraCabinPro
У Яндекса для этого сделали два мобильных сканера: под Android и iOS. По сути — карманный инструмент для быстрого обхода сети на месте: замерить параметры, понять, где просадка, и не гонять сетевого инженера на каждый сбой по офису, складу или даркстору.
Логика мне близка: **если проблему можно диагностировать с телефона, её надо диагностировать с телефона**. На складе это экономит не только время ИТ, но и простои на приемке, отгрузке и сборке. Пока руками ищут «почему отвалился Wi\-Fi», операция уже тормозит.
Нормальный операционный подход: меньше выездов, быстрее диагностика, меньше слепых зон. `Комбайн` для сетевика — это не игрушка, а способ держать удалённую инфраструктуру в рабочем режиме.
—
Больше про нутра — @NutraCabinPro
У меня к таким кейсам один практический вывод: если задача не бьётся в бюджет, люди начинают собирать _обходной контур_.
Здесь вместо «купить ещё одну дорогую карту и закрыть вопрос» человек поставил в обычный ПК серверный GPU с датацентра, да ещё через адаптер. В итоге получил **32 ГБ VRAM** на двух видеокартах и запустил локальную модель на `27B` параметров с нормальной скоростью. И всё это — примерно за £200.
Для склада это звучит знакомо: не всегда нужен идеальный новый контур, иногда нужен рабочий костыль, который выдержит SLA. Главное — не перепутать экономию с самодеятельностью. Если железо, питание и охлаждение не посчитаны, «дёшево» быстро превращается в простой.
Здесь вместо «купить ещё одну дорогую карту и закрыть вопрос» человек поставил в обычный ПК серверный GPU с датацентра, да ещё через адаптер. В итоге получил **32 ГБ VRAM** на двух видеокартах и запустил локальную модель на `27B` параметров с нормальной скоростью. И всё это — примерно за £200.
Для склада это звучит знакомо: не всегда нужен идеальный новый контур, иногда нужен рабочий костыль, который выдержит SLA. Главное — не перепутать экономию с самодеятельностью. Если железо, питание и охлаждение не посчитаны, «дёшево» быстро превращается в простой.
15 лет назад я бы смеялся над фразой «всё работает без настройки». И в серверной, и на складе у нас та же ловушка: сначала хочется собрать идеальную схему, потом допилить, потом ещё чуть-чуть подкрутить. А потом выясняется, что система уже жрёт время, а не экономит его.
В логистике это видно особенно хорошо.
Маршрут, упаковка, маркировка, приемка, SLA — если каждый раз изобретать «свой» процесс, склад быстро превращается в набор костылей. Красивых, аккуратных, но костылей.
Я давно смотрю на это так: если решение не держится без ежедневного шаманства, это не настройка, а долг по операционке.
Нормальная схема — та, что переживает смену, отпуск сотрудника и пиковую нагрузку без ручного вмешательства.
Меньше кастома. Больше стабильности.
И в Linux, и в поставках это обычно выгоднее.
В логистике это видно особенно хорошо.
Маршрут, упаковка, маркировка, приемка, SLA — если каждый раз изобретать «свой» процесс, склад быстро превращается в набор костылей. Красивых, аккуратных, но костылей.
Я давно смотрю на это так: если решение не держится без ежедневного шаманства, это не настройка, а долг по операционке.
Нормальная схема — та, что переживает смену, отпуск сотрудника и пиковую нагрузку без ручного вмешательства.
Меньше кастома. Больше стабильности.
И в Linux, и в поставках это обычно выгоднее.