🤖 Типовые задачи, на которые уходит время: сбор требований, user stories, документирование as-is / to-be, ТЗ и спецификации 🤖 Инструменты: ChatGPT, GigaChat, YandexGPT с промптами для аналитика; RAG-ассистенты на корпоративной базе; ИИ для диаграмм и моделирования 🤖 Оркестрация нейросетей: одна модель (Claude) распределяет задачи между специализированными моделями и собирает результат 🤖 Кейс из практики: задача, цепочка ИИ-агентов, результат, что дорабатывалось вручную 🤖 Границы применимости ИИ: контекст, стейкхолдеры, внутрикорпоративные процессы. Критическое мышление.
📆 Когда: 8 сентября в 18:00 (Мск) 👨🎓 ️Спикер: Новичков Александр, L&D-стратег, руководитель образовательных проектов
Собрали подборку из пяти материалов о разных задачах аналитика: от работы с требованиями и взаимодействия с командой до поиска решений и использования ИИ.
Как подготовить задачу так, чтобы сократить количество уточнений и переделок, расставить приоритеты и иногда найти решение без дополнительной разработки.
Кодекс — это скорее рекомендации, чем настоящие правила
Как говаривал капитан Барбосса, «Кодекс — это скорее рекомендации, чем настоящие правила».
Все агенты по натуре тоже пираты. Все ваши промты, правила и скиллы — для них не более чем рекомендации, как и пиратский кодекс. Нет такой инструкции, которую агент не мог бы нарушить.
Причем агент не идет на нарушение сознательно. Взломщик, проникший в ювелирный магазин, знает, что он совершает ограбление. Агенты, ломавшие Hugging Face, не думали о том, что это незаконно. Они просто наилучшим образом пытались выполнить данное им задание.
Так и пираты — они нарушают свой кодекс не потому, что они беспринципные подонки. Просто они хотят наилучшим образом выкрутиться из ситуации, в которую они попали, и если соблюдение правил сулит им неприятности, то к черту такие правила!
— И как же быть?
Принять тот факт, что любые писанные правила не являются гарантией корректной работы агента.
— Но почему?
Потому что они записаны на естественном языке. А язык многозначен, допускает множество интерпретаций. Причем таких, о которых вы и не думали, составляя свои правила.
Изворотливый ум всегда найдет лазейку, удобную для себя интерпретацию, когда он формально ничего не нарушает, но все же выходит за рамки, которые вы хотели обозначить.
Ключевое слово здесь «хотели». Ибо вам и в голову не придет описать все исключительные ситуации, все возможные двусмысленности, которые найдет в ваших словах другой ум — не важно, человеческий или искусственный.
Вот, например, известная шутка:
— Учитель, можно ли курить во время медитации? — Ни в коем случае! — А можно ли медитировать во время курения? — Да пожалуйста!
— Так что делать‑то?
Строить контролирующий контур вне ИИ. Как вариант, можно взять BPM‑систему и поместить агента в жесткие рамки бизнес‑процесса. Об этом регулярно рассказывает Бернд Рюкер, со‑основатель и главный технолог Camunda. Мне его позиция кажется вполне здравой и этот подход реализуемым.
Но там есть свои нюансы — если слишком закрутить гайки, и не учесть краевые сценарии, то агент просто уходит в ступор.
Например, вы дали правило ни в коем случае не выдумывать данные, если их нет. Разумно, не правда ли? — Но вы не учли, что при определенном раскладе, сервис, который эти данные должен предоставить, тупо завис. А у агента нет такой опции сказать, что продолжить работу невозможно, потому что система не отвечает. И он падает. Человек на его месте начала бы возмущаться или просто забил бы и ушел на обед, но агент так не может.
Соответственно, вам придется учесть больше вариантов, когда будете строить BPMN‑модель для процесса с участием агентов.
Если вам не нравится BPM, можно найти и другие решения.
Главное — не полагаться только на ИИ, чтобы управлять ИИ.
Инфостарт завершает прием заявок в программу INFOSTART A&PM EVENT 2026. До 28 августа аналитики, архитекторы, руководители проектов и специалисты по автоматизации могут предложить доклад или практическую активность.
В программе предусмотрены не только классические выступления, но и мастер-классы, воркшопы, круглые столы, тренинги и деловые игры. Около 70% расписания планируется отвести практическим форматам, остальные 30% — докладам с кейсами, рабочими инструментами и разбором ошибок.
Основные направления конференции:
управление проектами и продуктами;
инструментарий и прикладные компетенции аналитика;
архитектура и автоматизация решений на 1С;
управление командами и soft skills.
Полностью готовая концепция на этапе подачи не обязательна: модераторы рассматривают идеи, дают обратную связь и помогают авторам доработать формат.
INFOSTART A&PM EVENT 2026 пройдет 12–14 ноября в Санкт-Петербурге. Прием заявок завершится 28 августа.
Как евангелист не только ЛИМС, но и ноу-код конструкторов приложений, нашел OneBase — Open-source платформа для бизнес-приложений https://onebase.ivantitov.tech/index.html
Open-source платформа для создания бизнес-приложений. Слоган Пишем как в 1С — без 1С. Знакомые концепции 1С (настройка и программирование на русском языке).
Приложение полностью в одном файле (как и DataExpress), метаданные (формы, скрипты) хранятся отдельно в YAML. Доступно использование в качестве хранилища локального файла базы SQLite, а для совместной работы можно развернуть PostgreSQL.
Вобщем будут следить за новостями и попробую собрать какое-нибудь приложение.
В целом точно будет полезно для различных MVP и проверки гипотез.
Новый выпуск «Сколько стоит WMS» — про CAPEX склада
В новом выпуске подкаста «Сначала Процессы» разбираем затраты, которые возникают, когда склад расширяют за счёт дополнительной техники и площадей.
Сколько склад переплачивает за технику и квадратные метры
Говорим о том:
— сколько стоит простой и холостые пробеги ричтраков и как оптимизация маршрутов может сократить расстояние перемещений на 25–37%; — когда вместо покупки ещё одного ричтрака за 2,2–5,7 млн ₽ можно эффективнее использовать существующий парк; — сколько стоит низкая плотность хранения при аренде склада класса А; — как уплотнение хранения с 0,35 до 0,50 позволяет получить эквивалент 1 050 м²; — в каких случаях WMS может отложить расширение склада на 12–24 месяца; — что меняется при переходе на узкопроходное хранение (VNA).
И главное — считаем три сценария в рублях: дополнительная техника, новые площади и инвестиции в WMS + оборудование.
Выпуск: «Сколько склад переплачивает за технику и квадратные метры. Считаем окупаемость WMS через CAPEX»
Шесть профилей, три локальные модели: как родился Hermes-хаб
Модели отвечали на всё. Проблема была в другом: отвечал кто угодно, только не директор, не разработчик и не аналитик.
Девятого июля я собрал первую версию хаба на Mac mini M4. Шесть профилей: директор (он же оркестратор), разработчик, аналитик, аудитор, Wiki-куратор, писатель. Три локальные модели через Ollama, общий адрес http://127.0.0.1:11434/v1, дефолт на всех профилях gemma4:12b. Звучало как готовый штаб.
А штаба не было. Я задавал вопрос директору и получал ответ без единого признака директора. Роли и принципы лежали в SOUL.md каждого профиля, но написаны по-английски и по шаблону: «You are a chief of staff for a systems architect». Формально всё работало. По сути я разговаривал с одним безликим болванчиком в шести шляпах.
Десятого июля я переписал все SOUL.md на русский. Директор стал «chief of staff для системного архитектора», его задача защищать долгосрочный горизонт пользователя от краткосрочного шума.
На следующий день добавил gpt-oss:20b и llama3.2:3b. Вот тут характеры вроде бы ожили. Модель держала роль, отвечала по-русски и применяла правила, а не пересказывала их.
Личность живёт не в модели, а в тексте, который модель читает перед каждым ответом. На русском она работает лучше.
В офисе ИнфоТеКС мы открыли Летний ТехФест и провели воркшоп по Event Storming — это 90 аналитиков, техлидов и ни одной скучной лекции. Всех участников ждали полное погружение в практику и нетворкинг.
P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.
Исследователи Dreadnode проверили, насколько честно LLM-агенты проходят задания по наступательной ИБ. В эксперимент вошли 22 передовые модели семи провайдеров, 23 CTF-задания средней сложности из Cybench и три системных промпта: без запрета на обход правил, с обычным запретом и с жёстким перечнем запрещённых действий. Все 1518 траекторий прошли многоступенчатый аудит.
Результат ставит под сомнение pass rate как меру реальных возможностей. Без запрета 37,1% успешных прохождений были получены с нарушением правил, а жульничала 21 из 22 моделей. Средний pass rate составлял 41,5%, но доля честно решённых заданий — лишь 26,1%. У отдельных моделей оценка завышалась до пяти раз. Агенты искали готовые write-up, клонировали репозитории с решениями, читали файлы с флагами и исследовали служебную инфраструктуру.
Инструкции помогли, но проблему не закрыли. Доля заданий, в которых модель хотя бы пыталась жульничать, снизилась с 33% до 17,8% с обычным запретом и до 8,5% с жёстким. Доля честных решений при этом выросла с 26,1% до 34,4%: модели чаще продолжали самостоятельный поиск. Но даже при максимальных ограничениях восемь моделей получили хотя бы один результат с нарушением правил, а у четырёх возник обратный эффект. Обман также сместился от веб-поиска к исследованию инфраструктуры.
Авторы предлагают отдельно считать solve rate — долю только честных решений. Одного промпта для достоверной оценки мало: нужны изоляция служебных данных, ограничение интернета, аудит траекторий и свежие задания без опубликованных решений.
Снаружи ИИ-ассистент выглядит как окно чата. Но внутри — инференс, векторный поиск, база знаний, RAG-пайплайн, мониторинг и контроль доступа. От того, как всё это собрано, зависит, за сколько секунд приходит ответ, во что обходится каждый запрос и переживет ли сервис наплыв пользователей.
В статье разобрали инфраструктуру по слоям: где держать данные и контекст, каким задачам нужен GPU, а каким хватит CPU, и зачем связке из модели, хранилища и интерфейса контейнеры и Kubernetes. Плюс разница между MVP и production-архитектурой и типичные ошибки при проектировании.
Почему современные интерфейсы иногда усложняют жизнь
Интерфейсы с каждым годом становятся только удобнее: часть задач, например, сейчас можно решить с голосовым помощником. Но новые технологии не всегда делают взаимодействие с системой проще. Пользователи по-прежнему теряются в меню, тратят время на поиск нужных функций и устают от необходимости постоянно принимать лишние решения.
Поговорили об этом с Динарой — она помогает настраивать интерфейсы корпоративных систем для крупных компаний и каждый день ищет баланс между задачами бизнеса, возможностями системы и опытом пользователя.
1️⃣ Как изменилось взаимодействие человека с интерфейсами?
Они стали ближе к человеку. Если раньше компьютер требовал знать команды и мыслить как машина, то сегодня технологии все больше подстраиваются под нас: появились графические интерфейсы, сенсорное управление, голосовые помощники, искусственный интеллект.
Но сама эволюция не гарантирует удобство. Каждое новое решение нужно оценивать не по тому, насколько оно современное, а по тому, помогает ли оно человеку быстрее решать свою задачу.
2️⃣ Почему даже современный интерфейс может утомлять пользователя?
Потому что любая система требует внимания. Если человеку приходится искать нужную функцию, осваивать непривычные сценарии или постоянно принимать лишние решения, растет когнитивная нагрузка. А когда пользователь работает в системе по восемь часов в день, даже небольшие неудобства накапливаются и заметно влияют на его состояние и эффективность.
3️⃣ Получается, «проще» не всегда означает «лучше»?
Именно. Иногда в погоне за минимализмом или новыми трендами мы убираем то, что было интуитивно понятно.
Хороший пример — автомобили. Многие производители перенесли управление важными функциями на сенсорные экраны. В результате даже простое действие требует отвлечься от дороги. Поэтому сегодня часть компаний возвращает физические кнопки для критически важных функций.
4️⃣ Можно ли создать интерфейс, который будет удобен для всех?
Универсального решения не существует. Есть контекст, задачи пользователя и его привычки. Один и тот же подход может отлично работать в мобильном приложении и совершенно не подойти для сложной корпоративной системы.
Поэтому важнее искать не идеальный, а уместный интерфейс — тот, который соответствует конкретной задаче и условиям, в которых человек будет им пользоваться.
5️⃣ Как понять, что новое решение действительно улучшает интерфейс?
Я бы каждый раз спрашивала себя: станет ли пользователю действительно проще после этого изменения? Если решение выглядит современно, но увеличивает количество действий, заставляет переучиваться или сильнее отвлекает, возможно, это не улучшение, а шаг назад.
→ Подробнее своим опытом Динара поделилась в статье.
Считаем окупаемость WMS через бизнес-процессы: новый выпуск подкаста «Сначала процессы»
В управленческом отчёте маржа и операционные расходы выглядят предсказуемо. На складе часть убытков проходит по статьям, которые в эту отчётность не попадают.
Это шестой выпуск подкаста INTEKEY «Сначала процессы» и второй в тематической серии про окупаемость WMS. Предыдущий выпуск серии считал окупаемость через персонал: зарплаты, текучку, стоимость найма. Этот рассматривает только механику складской рутины, без учёта людей.
Новый выпуск подкаста "Сначала Процессы". Окупаемость WMS через изолированный критерий "бизнес-процессы".
Сравнение «12 млн за WMS — дорого» строится относительно нуля. На практике склад уже платит эту сумму каждый день: транспортные компании получают деньги за повторные рейсы из-за ошибок, банки — проценты по кредитам на закупку товара, который физически есть на складе, но его не могут найти.
Брак комплектации 1,5–2% на первый взгляд означает высокую точность. Полная стоимость одной ошибки складывается из нескольких шагов: повторная поездка, приёмка возврата, пересборка заказа, время менеджера на разговор с клиентом, корректировочные документы в бухгалтерии. Для российского B2B это около 4 000 ₽ за случай. При 500 отгрузках в день и 2% брака — больше 200 ошибок в месяц, около 800 000 ₽.
Товар физически лежит на складе, но недоступен для продажи, пока не отражён в системе. Приёмка на 150–250 строк силами трёх человек занимает около 4 часов: разгрузка, подсчёт, разбор накладных, звонки поставщику при расхождениях. Всё это время товар не виден отделу продаж. WMS с ASN (предварительным уведомлением об отгрузке) делает товар доступным к продаже в момент сканирования на воротах и сокращает процесс до 1,5 часов — около 460 000 ₽ в месяц освобождённого ресурса.
Инвентаризация с остановкой склада повторяется четыре раза в год. Прямые расходы на одну такую операцию — около 250 000 ₽ (переработки, доплаты, простои), то есть миллион в год. Цикличный фоновый пересчёт через ТСД убирает необходимость останавливать склад: расхождения фиксируются по мере появления, а не раз в квартал.
Точность остатков около 91% на ручном складе создаёт разрыв между системой и реальностью: закупщик видит в ERP отсутствие товара и заказывает новую партию, хотя старая лежит в другом углу склада. При запасе 90 млн ₽ разрыв 8,5% замораживает около 7,5 млн ₽. При стоимости капитала для бизнеса около 25% годовых это около 160 000 ₽ в месяц дополнительных расходов.
Greenfield по технологии, brownfield по бизнес-правилам
Сегодня в комментариях к чужой статье про greenfield и brownfield в эпоху AI вспомнил свою миграцию 200К строк JS в TypeScript. Тогда я не думал в этих терминах. Теперь вижу: проект был greenfield и brownfield одновременно, и путаница между ними стоила нам двух недель дебага в середине миграции.
Я думал: раз меняем весь стек, это чистый лист
Оказалось: технология была greenfield, стек новый, границы модулей новые, тесты новые. Бизнес-правила остались brownfield на все сто. Восемь лет продакшена, часть логики нигде не задокументирована, живёт только в поведении старого кода. Агент писал типобезопасный, красивый TypeScript и с той же уверенностью ломал правило, о существовании которого никто в команде уже не помнил.
Я думал: раз тесты зелёные, поведение сохранилось
Оказалось: существующее покрытие было тонким именно там, где пряталась история. Странный if с комментарием «не трогать, тут баг у клиента X» тестами не покрывался, потому что баг был найден руками три года назад и с тех пор просто жил в коде. Агент видел if без контекста и оптимизировал его как мёртвый код.
Что сработало: golden-master тесты перед тем, как подпускать агента
Не юнит-тесты на новую логику, а снимок текущего поведения на самых страшных модулях. Прогнали типичные и граничные кейсы через старый код, зафиксировали вывод, потом сравнивали с новым на каждом шаге. Разница ловилась мгновенно, до ревью, до продакшена. Три раза снапшот показал расхождение, которое человек на ревью пропустил бы, слишком похоже на «просто более чистый код».
Главный вывод
В greenfield-части задачи вопрос «правильно ли мы строим» решается быстрой обратной связью и итерацией. В brownfield-части вопрос другой: «сохранили ли мы то, что уже работает». Агент одинаково уверенно предлагает и то, и другое решение, разницу видно только через инструмент вроде golden-master, не через код-ревью на глаз.
Если в проекте есть куски старше пары лет, перед тем как звать агента туда, стоит сначала спросить не «как сделать красиво», а «что именно нельзя сломать, и как я об этом узнаю раньше продакшена».
FinOps по фасттреку: как искать экономию в облаке и не сломать сервис
FinOps часто описывают как полноценную методологию: Inform, Optimize, Operate, процессы, роли, регулярная аналитика, отчётность и культура потребления.
Но на практике российские компании часто приходят с другим запросом: “мы много платим за облако, нужно быстро понять, где можно снизить расходы”.
В новом выпуске «Практики FinOps» поговорили с Вячеславом Бессоновым, генеральным директором Hilbert Team.
Обсудили, как выглядит FinOps по фасттреку: когда не строят сразу всю методологию, а начинают с quick wins, анализа биллинга, гипотез оптимизации, расчёта ROI и проверки, не сломает ли экономия рабочий сервис.
В выпуске разбираем:
почему облачного биллинга часто хватает только для первого среза
какие задачи закрывают FinOps-инструменты, Excel и Python notebooks
почему гипотеза оптимизации не равна готовому решению
как считать оптимизацию как отдельный IT-проект
когда quick win может дать 5–10%, а когда 20–30% требуют серьёзной переработки архитектуры
почему теги у заказчиков всё ещё скорее исключение, чем правило
как делить общую инфраструктуру между продуктами и cost centers
чем отличается экономика on-prem от облака
почему будущее FinOps движется к подходу workload first
как AI-токены становятся новой частью unit-экономики
Отдельно поговорили о российском рынке: неунифицированном биллинге, сложностях мультиоблачной и гибридной инфраструктуры, резервах, внутреннем биллинге и том, почему полноценная фаза Operate часто не начинается, даже если компания уже нашла первые точки экономии.
Новичкам в аналитике: как готовиться к собеседованию и что повторять
Эта подборка статей поможет подготовиться к собеседованиям на разные позиции. Вы лучше поймете, как проходят собеседования, какие вопросы могут задать и как грамотно на них отвечать. В материалах собраны примеры кейсов, технических и поведенческих вопросов, а также советы от экспертов.
Собеседование на бизнес-аналитика: вопросы и как подготовиться. Разбираем, какие блоки вопросов встречаются на собеседовании: про опыт и мотивацию, работу с требованиями, методологии и стандарты, коммуникацию со стейкхолдерами. Делимся советами по подготовке от эксперта с 10-летним опытом в бизнес-анализе.
Собеседование на позицию Data Scientist: о чём спрашивают новичков. Объясняем, что работодатели ждут от начинающего специалиста и какие категории вопросов встречаются: от теории и статистики до поведенческих кейсов. Показываем на примере, как выстраивать ответы по методике STAR.
Освоить профессию в сфере аналитики можно в среднем за год — в зависимости от выбранного курса. А узнать больше о направлениях и задачах разных специалистов можно за несколько часов — это бесплатно. Переходите в каталог и выбирайте направление, чтобы начать учиться — карту привязывать не нужно.
Системный и бизнес‑анализ: 10 бесплатных уроков о требованиях, процессах и архитектуре
Аналитику приходится одновременно разбираться в целях бизнеса, поведении пользователей, устройстве систем и последствиях каждого изменения. Ошибка в требованиях легко превращается в дорогостоящую доработку, а незамеченный риск — в проблему уже после релиза.
Собрали открытые уроки для системных и бизнес‑аналитиков. В программе — ArchiMate и TOGAF, управление рисками, Use Cases, BPMN, нефункциональные требования и архитектурные модели. Уроки проводят преподаватели‑практики: во время встречи можно задать вопросы по теме и посмотреть, как устроено обучение.
4 августа в 20:00. «Как аналитику работать с рисками». Поговорим о выявлении и оценке рисков, которые возникают при изменении процессов, требований и информационных систем.
17 августа в 20:00. «Строим модель в нотации BPMN с помощью ИИ». Разберём применение ИИ при моделировании бизнес‑процессов и посмотрим, где автоматизация помогает аналитику, а где требует проверки.
18 августа в 19:00. «Строим идеальную бизнес‑архитектуру». Поговорим о том, как связать цели компании, бизнес‑возможности, процессы и организационную структуру в единую модель.
Backend без хрупких интеграций: 5 материалов, которые вы могли пропустить
На старте проекта многие решения выглядят простыми: сделать REST API, разнести сервисы, добавить очередь, договориться о моделях данных. Но по мере роста системы выясняется, что именно эти решения определяют, насколько легко её развивать дальше.
Эта подборка будет полезна тем, кто проектирует backend‑системы, работает с API, микросервисами, доменной моделью или просто регулярно сталкивается с вопросом: «как сделать так, чтобы архитектура не мешала разработке через полгода».
Собрали 5 материалов по теме:
Как фронтенд получает данные с сервера: лучшие практики 2026 О том, как backend и frontend договариваются через API, где уместны REST, GraphQL, BFF и Server Components, и почему «быстро отдать JSON» ещё не значит сделать удобный интерфейс для клиента.
А если хотите не только читать, но и разбирать темы с практиками, смотрите дайджест — там собраны бесплатные открытые уроки по разработке, архитектуре и инфраструктуре.
Вы просили — мы сделали. Повторяем вебинары про работу с данными в облаке: от развертывания платформы до ETL-процессов и полноценной BI-аналитики. Регистрируйтесь, чтобы спросить экспертов о важных деталях и получить ответ.
Как развернуть платформу данных в облаке и подготовить данные для аналитики Покажем, как быстро развернуть managed-сервисы Evolution Data Platform, подключить источники данных и построить пайплайны для подготовки данных к аналитике. Разберем интеграцию с PostgreSQL, ADB, S3 и настройку автоматического обновления — без долгого погружения в инфраструктуру. 🧑💻 Для кого: дата-инженеры, аналитики, архитекторы данных. 📅 Когда: 16 июля 11:00 мск. 📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.
ETL в облаке: от хаоса к управляемым процессам Покажем, как выстроить надежную ETL-платформу в облаке на базе Evolution Data Platform. Разберем интеграцию разрозненных источников, управление метаданными и оркестрацию — и покажем всё это в live-демо: от извлечения данных до готовой витрины. 🧑💻 Для кого: дата-инженеры, DevOps, руководители дата-команд. 📅 Когда: 23 июля 11:00 мск. 📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.
Evolution Managed BI: все возможности BI-сервиса в облаке Разберем, как получить максимум от Evolution Managed BI: подключить источники данных, настроить интерактивные дашборды, кеширование запросов и автоматические алерты. Покажем продвинутые возможности сервиса — от виртуальных датасетов до управления доступом. 🧑💻 Для кого: аналитики, BI-разработчики, руководители дата-отделов. 📅 Когда: 30 июля 11:00 мск. 📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.
Это напоминание для тех, кто пропустил первый анонс или отложил регистрацию. На вебинаре разберут, почему дашборд в 1С не всегда помогает управлять процессами, даже если визуально выглядит правильно: на экран попадает слишком много показателей, метрики не связаны с решениями, а данные вызывают вопросы у пользователей.
В фокусе - практический подход к проектированию дашбордов: как определить аудиторию, выбрать показатели под конкретную роль, настроить детализацию и заранее проверить качество источников данных.
Также обсудят типичные ошибки: перенос старых отчетов в новый интерфейс, перегрузку первого экрана, несогласованные статусы, неполные справочники и отсутствие сценариев ежедневного использования.
Вебинар будет полезен руководителям, владельцам процессов, аналитикам и специалистам 1С, которые используют данные учетных систем для контроля продаж, финансов, задач, производства, заказов или клиентской работы.
Дата и время: 20 июля, 16:00 мск Формат: онлайн Стоимость: бесплатно
Заряжаемся перед Робозоном: решаем задачу и погружаемся в атмосферу хакатона от Ozon Tech
«Подумаешь, коробка», — скажете вы. И правда, что может быть проще коробки… когда она одна. А что насчёт миллионов коробок? Бесконечный поток товаров, текущий по сортировочному центру. Конвейеры, сканеры, роботы — элементы сложной логистической системы — направляют и упорядочивают этот поток. И от разработчиков, от их способности создавать эффективные алгоритмы обработки товаров и устранять узкие места зависит, насколько быстро и безошибочно будут двигаться коробки.
Не верите? Тогда попробуйте сами решить задачку из серии «не дай конвейеру захлебнуться коробками».
Представьте: в логистическом центре два конвейера, 1 и 2, сливаются в один основной — конвейер 3, ведущий к сканеру штрихкодов. Поток на линии 1 — 1000 товаров в час, на линии 2 — 500 товаров в час. Сканер на линии 3 обрабатывает до 2000 товаров в час. Но вот беда: в точке слияния конвейеров товары сталкиваются, что приводит к затору. Датчики фиксируют «аварию», система постоянно делает микроостановки, поэтому реальная пропускная способность линии 3 падает до 1100 товаров в час.
Вам поручили придумать решение, которое поможет устранить заторы. Что вы выберете?
А. Увеличить скорость линии 3 до 2500 товаров в час, чтобы она моментально «выдёргивала» товары из точки слияния.
Б. Установить на линиях 1 и 2 логику «светофора» (накопительные буферы), пуская товары пачками по очереди.
В. Ускорить линию 2, чтобы её поток «проскакивал» в окна между товарами с линии 1.
Уверены в своём решении? Тогда проверьте его правильность под спойлером.
Вариант А кажется хорошим решением, но на деле не спасёт ситуацию. Запас по скорости на линии 3 есть и так (2000 > суммарных 1500), и если ускорить принимающий конвейер ещё больше, товары просто будут ехать по нему с большими просветами, но коробки с линий 1 и 2 всё равно будут приходить в точку слияния одновременно и застревать.
Вариант В не только не устранит заторы, но может и усугубить проблему: товары будут сталкиваться на ещё большей скорости, увеличивая риск повреждений.
Вариант Б — единственно верный в данной ситуации. Искусственное притормаживание потоков для формирования управляемых «пачек» (плотный поток с линии 1, затем пауза и сброс товаров с линии 2) повышает общую скорость системы, убирая хаос и микроостановки. Парадоксально, не правда ли?
Ладно, это была всего лишь разминка. Настоящие сложные задачи мы приберегли для хакатона Робозон с призовым фондом 15 000 000 рублей.
конструкция автоматизированного сортировщика товаров сортировочного центра;
интеллектуальная роботизированная система сортировки товаров.
Робозон стартовал 2 июля, регистрация продлится до 23:59 11 июля. Хакатон пройдёт в два этапа. Первый завершится 2 августа, и 11 августа будут известны финалисты. Во второй этап пройдут по 5 лучших команд из каждого трека, чтобы до 6 сентября доработать свои решения и побороться за победу на очной защите 12 сентября в Москве. Победителей наградят 13 сентября на конференции E-CODE.
Ещё больше информации о правилах участия, призах и даже подсказки, кого стоит набирать в команды для разных треков, — на сайте ozon-robozon.ru.
Участвуйте в хакатоне — пусть инженерная мысль помогает управлять многомиллионным потоком товаров.
