В предыдущем материале мы говорили о значении MES для производства и о ситуации на российском рынке MES-решений. Во второй части – опытом делятся ИТ-руководители компаний «Багерстат Рус», «Гедеон Рихтер-Рус», «Селигдар», которые уже прошли путь внедрения.

🔸 По наблюдениям экспертов, проектам чаще всего мешают:

1. хаотичное состояние российского рынка MES-решений,
2. неочевидная окупаемость MES,
3. отсутствие долгосрочной стратегии при выборе решения,
4. слабая коммуникация между ИТ и бизнесом,
5. нагруженный ИТ-ландшафт, в который сложно встроить новую систему.

В статье вы найдете ответы ИТ-руководителей на вопросы:
➖ как обойти ограничения?
➖ с чего именно начать MES-проект?
➖ что ждет рынок MES в ближайшие годы?

🟨 Читайте полную версию материала с цитатами по ссылке

Подписывайтесь на Берегись бэклога 💫

Очередное падение AWS оживило старый спор - облако против «железа». Исследований, где честно сравнивали бы их надёжность, почти нет. Но закономерности видны и без статистики.

⚡️Виталий Секретенко, технический директор из ГК «КОРУС Консалтинг» делится наблюдениями о ситуации на рынке:

Если падает свой сервер - виноват ты. Если падает AWS - это уже «форс-мажор», почти сопоставимый с природным бедствием. И, что парадоксально, многим так даже спокойнее: никто не виноват, страдают все, ответственность растворилась.

🔸Коллективная хрупкость – тренд сезона

За видимой безопасностью облачных решений прячется новая уязвимость – коллективная хрупкость. Компании идут в облако ради скорости, масштабирования и простоты эксплуатации. Локально это выгодно: не нужно держать дата-центр, следить за питанием и железом, думать о бэкапах. Но проблема в том, что таких компаний миллионы. И все сидят на одних и тех же сетях, API, балансировщиках и системах управления AWS.

🔸Как централизация ИТ-решений снижает их надежность?

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

Важно, что проблема не в «плохом AWS». Коллективная хрупкость – это закономерный эффект централизации: архитектуры стали однотипными, провайдеров на рынке единицы, а зависимости теперь сквозные. Надёжность выросла для каждого, но устойчивость всей экосистемы упала.

🔸Итог: что помнить при выборе между облаком и железом?

1. Масштаб и унификация ИТ-решений дают стабильность локально, но ломают её глобально.
2. AWS периодически «падает», но это не освобождает компанию от ответственности за резервирование, изоляцию и создание плана Б.
3. Настоящая надёжность – в деконцентрации, автономности и способности выдержать чужие сбои.

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

А какой вариант работает для вас? Голосуйте и комментируйте ⬇️

👍🏻 – Облако
🔥– Железо

Читайте больше экспертных разборов в Берегись бэклога 💫

Делаем вебинары, которые действительно полезны: вы не просто узнаёте что-то новое, но и получаете инструменты для реальных действий.

Напомним о самых ярких вебинарах:

⚡ «Где заканчиваются готовые решения и начинается кастом?»
Вместе с экспертами компаний «Петрович», «Телематика», «РУСАГРО» поговорили о вызовах цифровизации и обсудили, какие стратегии выбирать крупным компании в условиях быстро меняющегося рынка.
Смотреть

⚡ «Как не превратить систему в монстра?»
Рассмотрели, почему системы становятся слишком «тяжелыми» и внедрять новые функциональные возможности с каждым разом все сложнее. Ответили на вопрос «как выстроить систему так, чтобы ее было легко поддерживать и развивать?»
Смотреть

⚡ «Почему 80% кастомных ИТ-решений терпят крах?»
Разработка уникальных ИТ-решений для бизнеса часто превращается в зону риска из-за неопределенности, разрыва между бизнесом и ИТ, давления сроков и бюджета. Рассказали, как сделать так, чтобы кастомизация не превратилась в проблему для ИТ-команды.
Смотреть

⚡ «Как превратить идею в реальный продукт: 5 важных шагов до старта разработки»
Как подготовиться к разработке кастомных продуктов, минимизировать риски, укладываясь в бюджет и сроки? Как сформулировать требования к решению, которое автоматизирует уникальные бизнес-процессы? Ответы — в этом вебинаре.
Смотреть

⚡ «Order Management System (OMS): обратная сторона омниканальности»
С ИТ-директором ГК «ГАЛА-ЦЕНТР» рассмотрели лучшие практики взаимодействия с клиентами через различные каналы в B2B и B2C-сегментах. Поговорили о проблемах, возникающих при отсутствии выстроенной системы омниканальности и предложили практические способы их решения.
Смотреть

Находите больше полезных статей и вебинаров в Берегись бэклога 💫

⚡️Инженер передовой развертки – кто это и почему его называют «золотым» специалистом?

Держим руку на пульсе ИТ-рынка и трендов заказной разработки. Сегодня — о новой профессии, Frontier Deployment Engineer (FDE, инженер передовой развертки).

Спрос на этих специалистов вырос на 800% за год. OpenAI, Anthropic и Cohere активно нанимают FDE, которые не просто разрабатывают модели, но помогают бизнесу внедрять их под конкретные процессы, от банков до промышленности.

«Потребности крупного банка отличаются от задач стартапа, создающего ИИ-продукт, — говорит Кэт де Йонг, глава отдела прикладного ИИ в Anthropic. — Инженеры передовой развертки помогают компаниям понять, как именно использовать ИИ с пользой».

Что по цифрам?
✅ OpenAI планирует расширить команду FDE до 50 человек к концу 2025 года
✅ Anthropic увеличивает команду передовой развертки в 5 раз.
✅ Один из пионеров идеи — компания John Deere, которая при помощи инженеров передовой развертки создала ИИ-инструменты для снижения использования пестицидов на 60–70%.

❓ Что это значит для российского рынка
В России такие специалисты пока редкость, но запрос уже формируется. Многие компании ищут универсалов на стыке ИТ и бизнеса — тех, кто может не просто подключить модель, но встроить её в операционные процессы и показать эффект. По сути, это следующая ступень развития для solution-архитекторов, пресейлов и ИИ-консультантов, которые понимают язык бизнеса и умеют доводить ИИ-проекты до реальной отдачи.

Подробнее — по ссылке

Читайте больше новостей в Берегись бэклога 💫

— Навайбкодим по-быстрому?
— Да, но есть нюанс.

Всё чаще на встречах с клиентами и партнёрами слышим слово «вайбкодинг». В обзоре RSpectr рассуждали о том, почему ИИ не способен заменить ИТ-отдел.

Раньше разработчик был исполнителем и писал код сам, постоянно сверяясь с ТЗ. Теперь он часто выступает как соавтор: формулирует идею, ограничения, «настроение» будущего решения. А дальше подключает ИИ.

Полина Ефремова, директор по развитию направления «Заказная разработка» КОРУС Консалтинг:

Вайбкодинг – не замена, а продолжение классической разработки. Человек задаёт направление и характер, а ИИ превращает идею в рабочий прототип.

По сути, это следующий шаг после no-code: порог входа снижается, скорость проверки гипотез растёт. Бизнес собирает MVP сам, без длинных согласований и десятков спринтов. Мы уже видим, как компании тестируют ИТ-продукты, чат-боты, лендинги, собранные с помощью GenAI.

Но видим и закономерность: рано или поздно «вайб» заканчивается. В какой момент? Как только появляются требования к устойчивости, сложной архитектуре и безопасности продукта. Дальше работают инженеры, потому что вайбкодинг – это только начало классической enterprise-разработки. Он сможет визуализировать продукт, но не выстроит CI/CD и не проверит SLA интеграций. Тут эстафета снова переходит к людям.

Кажется, что будущее за гибридными командами, где вайбкодеры задают направление, а инженеры доводят идею до продакшена. Проверим?

Что думаете о вайбкодинге?

😐 — хайп и не более
🤔 — применимо, но с ограничениями
👍 — точно новая эра для no-code

Подписывайтесь на «Берегись бэклога» 💫

Когда дал ИИ контекста больше, чем себе

Если вспомнили похожий случай, наши комментарии ждут только вас⬇️

Подписывайтесь на Берегись бэклога 💫

Почему все говорят про Open Source? ⚡

Отвечает Виталий Секретенко, технический директор ГК «КОРУС Консалтинг»:

Решения с открытым кодом сегодня в центре обсуждения, потому что их использование напрямую влияет на операционную стабильность бизнеса. Open Source помогает ИТ-директорам закрыть ключевые задачи: сохранить устойчивость архитектуры и снизить зависимость от вендоров.

Что open source может дать бизнесу?
➕ прозрачность кода и быстрый поиск уязвимостей
➕ высокая скорость развития и обновлений
➕ более дешевые эксперименты с ML и ИИ
➕ гибкая интеграция новых решений в сложные ИТ-ландшафты
➕ возможность формировать внутренние стандарты и компетенции

Для компаний, которые развивают собственные системы и используют заказную разработку, OS – это ещё и способ ускорять работу команд без дополнительных лицензионных платежей.

Какие ограничения Open Source наши знакомые ИТ-директора называют чаще всего?
Бизнес сталкивается с нестабильным доступом к зарубежным репозиториям типа GitHub, PyPI, DockerHub. Сохраняется риск внезапной недоступности критичных библиотек. Это заставляет постоянно контролировать цепочки поставки ПО, держать локальные зеркала и быть готовыми к миграциям. На ситуацию влияет и снижение участия российских команд в международных OS-проектах: меньше глобального ревью кода и доступа к лучшим практикам, поэтому растёт нагрузка на внутренние компетенции.

Чего ждать от Open Source в 2026–2027?
➡️ будет расти использование OS в инфраструктуре: контейнеризация, DevOps, мониторинг, СУБД, виртуализация
➡️ могут появиться альтернативные зарубежные источники библиотек и решений – например, китайские экосистемы Huawei/Baidu/Alibaba
➡️ обязательным элементом архитектуры будет локальное дублирование артефактов, созданных с помощью OS

Согласны с прогнозом?

Читайте больше экспертных разборов в Берегись бэклога 💫

Low-code или классическая разработка — что выбирать в 2026 году? ⚡️

Когда ландшафт разрастается, а изменений в бизнес-процессах всё больше, ИТ-директору важно понимать: что строить быстро, а что — долго и основательно. На вопрос отвечает Елена Никитина, руководитель направления заказной разработки, ГК «КОРУС Консалтинг».

🔸 Когда подходит low-code/no-code?

Если нужно объединить мелкие раздробленные процессы с минимальными затратами, быстро запустить внутренние сервисы или протестировать бизнес-гипотезы на этапе проверки идеи.

🔸Когда нужна классическая разработка?

Если важны архитектура, сложные интеграции и глубокая кастомизация — например, при создании корпоративных систем, отраслевых платформ или нагруженных модулей аналитики.

При этом тренд на ИИ усиливает разделение между подходами. Подробнее — в карточке к посту и в статье «ИТ-тренды 2026 года: что ждет бизнес и рынок в России».

⬇️А что вы выбираете чаще — конструктор или классическую разработку?

Подписывайтесь на Берегись бэклога 💫

По данным McKinsey, 25–40% ИТ-проектов превышают сроки или бюджет минимум в 2 раза.

Чаще всего дело не в технологиях, а в управляемости: требования, объём работ и изменения по ходу проекта оказываются сложнее, чем казалось. В заказной разработке это проявляется особенно ярко. Если недооценить проект, сценарии выглядят так:

👻 План: 9 месяцев. Реальность: 2 года

На старте всё казалось понятным. Но затем всплыли интеграции, ограничения и реальные бизнес-процессы. План пришлось пересобирать — и сроки постепенно вышли за рамки первоначальной оценки.

👻 Бюджет растёт быстрее, чем проект

Смета выглядела аккуратно, пока не появились «маленькие уточнения»: пара дополнительных сценариев, новая интеграция, перенос логики в другой модуль. По отдельности вроде мелочи, вместе — пересмотр бюджета и новые согласования.

👻 «Мы не так поняли друг друга»

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

⚡Знакомо?
В следующем посте эксперты КОРУСа расскажут, какие инструменты помогут избежать этих сценариев.

А пока поделитесь, как у вас обстановка на проектах? ⬇️