Есть бизнес-процессы, которые на схеме выглядят элементарно. Например, оформление пропуска.
Есть сотрудник. Есть автомобиль. Есть объект заказчика. Нужно проверить документы и оформить допуск.
Что здесь вообще автоматизировать?
Примерно так задача выглядела до тех пор, пока мы не начали разбираться, как этот процесс реально устроен в транспортно-строительной компании на Ямале.
Выбор конфигурации это только начало автоматизации. Дальше приходится определять границы систем, проектировать интеграции, решать, что дорабатывать, а что оставлять типовым, и оценивать стоимость будущего сопровождения.
Этим вопросам будет посвящена секция «Решения 1С: архитектура, учет и кейсы автоматизации» на INFOSTART A&PM EVENT 2026, который пройдет 12–14 ноября в Санкт-Петербурге.
Лицензия на корпоративное ПО давно перестала быть просто ключом «введите и активируйте». Пользователи перераспределяются между инсталляциями, появляются новые кластеры, меняется состав ресурсов, лицензии продлеваются, а вся история изменений постепенно расползается между CRM, договорами, заявками и переписками.
Мы решили посмотреть на лицензию с другой стороны: не как на приложение к договору, а как на полноценный цифровой артефакт, которым можно управлять так же системно, как кодом.
В статье рассказываем, почему мы отказались от стандартных ключей активации и лицензионного сервера, и внедрили собственный подход, который назвали Licensing as Code.
Всем привет! Меня зовут Анатолий, я работаю ИТ-архитектором в Сбере. Занимаюсь развитием направления клиентской лояльности. Сразу же отмечу, что в этой статье не идёт речь о фундаментально правильных решениях. Скорее, наоборот, речь идёт о решениях компромиссных.
В целом, зрелость архитектурной культуры организации можно оценивать соответствием некому условному уровню.
Если в вашей компании уже живёт полноценная система для архитектурных решений в виде Aris, Sparx Enterprise Architect или их аналог, и она умеет всё, что нужно: описывать бизнес-сценарии, собирать связанные с ними решения, показывать и согласовывать их с заказчиками, а потом аккуратно складывать в единый архитектурный репозиторий, то тогда, скорее всего, эта статья не для вас. Вы и так всё это проходили.
А вот если такой системы нет или бюджет на неё пока не выделили, но потребность в наглядной архитектуре и порядке в ней уже назрела, то, возможно, мой опыт позволит вам быстрее и легче достичь «третьего» уровня и успешно его пройти.
«Мы не пишем ТЗ, — гордо сказал мне руководитель агентства. — Мы работаем только по Agile». Хочется порассуждать на тему того, нужно ли в 2026 году писать техническое задание на разработку информационного продукта и в каком виде. Или это все замшелые водопадные технологии, которые уже давно прогрессивным разработчикам и вайбкодерам никуда не уперлись.
Вообще, сам термин «техническое задание» для разработки в последнее время стал встречаться реже — и в обсуждениях и в профильных статьях. Чаще его заменяют словом «требования» (reqirements) или Product vision и это действительно ближе к истине — в таком документе мы фиксируем требования заказчика и видение того, каким должен быть создаваемый продукт, что он должен уметь и как выглядеть. Вне зависимости от подхода к разработке такой документ на старте проекта должен быть обязательно, и при этом быть хорошо проработанным — хотя бы для создания MVP. Потому что и у заказчика проекта и у его разработчика перед глазами должен быть так сказать единый «образ победы» — того продукта, который они совместными усилиями делают. Без такого документа вы не сможете ни бюджет спрогнозировать даже примерно, ни сроки готовности, да и функционал самого продукта может в итоге оказаться совсем не таким, как его представлял себе заказчик. Сколько раз приходилось наблюдать ситуацию, когда не только отдельные фичи, но даже использованные в постановке задачи термины понимались сторонами по‑разному, что приводило к спорам на приемке очередного этапа работ. Поэтому кстати, считаю раздел с терминами обязательным и всегда включаю его в свою документацию — чтобы у всех было единое понимание того, что такое «Заказ», из чего состоит «Заявка», кто такой «Администратор» и тому подобное
Я работаю аналитиком в e‑commerce крупной FMCG‑компании. В маркетплейсах это иногда ощущается как слон в посудной лавке: несколько юридических лиц на каждой площадке, большие объёмы поставок, ограничения по слотам на складах, сложная логистика, переупаковка и подготовка товаров под требования конкретного канала.
Отдельной болью, которую хотелось автоматизировать, был расчёт заказа на Ozon. Для менеджера маркетплейса это был регулярный и довольно трудоёмкий процесс: сначала нужно было собрать данные из разных выгрузок, а уже потом переходить к расчёту.
Состояние российского рынка дистанционного зондирования Земли на август 2026 года
Российский рынок дистанционного зондирования Земли переживает довольно заметный переходный период. Еще несколько лет назад ДЗЗ в России в основном ассоциировалось с государственными космическими аппаратами, а коммерческий рынок данных оставался относительно небольшим. Сейчас ситуация меняется: появляются частные операторы спутников, собственные группировки, наземные станции, платформы доступа к данным и сервисы автоматической аналитики.
Одновременно государство начинает выступать не только владельцем космической инфраструктуры, но и крупным заказчиком данных у различных поставщиков. По оценке руководства Роскосмоса, потенциал российского рынка данных ДЗЗ после запуска новой модели закупок может вырасти более чем в шесть раз — до 31 млрд рублей. При этом уже в 2026 году Роскосмос сообщил о заключении контрактов на предоставление данных ДЗЗ примерно на 5 млрд рублей для федеральных и других государственных органов.
Именно поэтому 2026 год можно считать одним из переломных для российского рынка ДЗЗ.
Лето подходит к концу и я хочу рассказать о своём увлечении последних месяцев — машинном обучении (Machine Learning) на данных Московской биржи. Эта тема уже давно не даёт мне покоя и в этот раз я решил подойти более основательно — активно использовал новейшие языковые модели, типа Claude Sonnet 5, Gemeni 3.7 Flash не только для написания кода, но и для работы с результатами этих скриптов. При этом не использовал полностью автономных агентов — все языковые модели работали как консультанты в чате — все решения принимал я, в том числе какую исходную информацию давать конкретной модели на каждом из этапов.
Предвидя будущие вопросы я сразу отвечу что это мой эксперимент и он не только не зарабатывает, но и пока даже непонятно чем закончится — сейчас это всё в процессе. Эту статью решил написать не чтобы «засветить трейдерским граалем» — которых я кстати считаю что не существует, потому что вся информация общедоступна. Эта статья написана чтобы рассказать как есть об этой ML теме без прикрас и познакомиться с комментариями — среди негатива (обычно так) проскакивают интересные мысли. Я сам не работаю в финансах и моя позиция больше исследовательская, так что раскрыть какие‑то корпоративные секреты я не могу — просто прощупываю путь перед собой.
Российский рынок аналитических решений в последние годы проходит через ряд глобальных изменений - уходили привычные решения, появлялись новые технологии, менялась экономика. В итоге к 2026 году рынок пришел к запросу на доступные решения, близкие к пользователю и отрасли применения, с четко-прослеживаемыми бизнес-эффектами, подходящим форматом поставки и небольшим горизонтом возвратности инвестиций.
Ниже разберем, как эти потребности существующие предложения пытаются закрыть на практике: через семантический слой, ансамбль моделей, RAG по внутренним регламентам, интеграционный слой и ролевые сценарии.
И посмотрим, что из этого выходит.
Допустим, вы решили заняться беспилотными технологиями в стартапе или RnD подразделении при университете. У вас за плечами мобильный робот на условном Arduino. И вот появился заказчик, который хочет автоматизировать свои процессы и даже готов за это заплатить. Вам нужно взять некую технику, обвешать датчиками и приводами, добавить вычислитель и научить автономно двигаться, попутно решая проблему заказчика. У вас всё серьёзно: у проекта есть руководитель, электроникой занимаются электронщики, механикой — конструктора, есть специализация у программистов (системы восприятия, навигации, планирования и тому подобное). Казалось бы, что может пойти не так?
Ниже я хотел бы описать ряд проблем, с которыми столкнулся (как программист) при работе над проектами по созданию беспилотных технологий. Врядли я кого‑то удивлю, наверняка это всё «детские болезни», которые решаются правильным планированием и в зрелых компаниях не встречаются. Но на начальном этапе о них полезно помнить.
Разработчики описывают изменения кодом, инфраструктура — декларативными манифестами, а архитектура до сих пор часто живёт в draw.io и PNG. Почему диаграмма без модели быстро устаревает и как собрать архитектурный control plane из знакомых деталей: API server, графа, CMDB, diff/review и operator pattern? А может нам нужно решение с ResourceDefinition, типизированными связями, Temporal workflows и change sets.
Недавно на Хабре вышла статья «почему 90% проектов на 1С теряют смысл» о том, что внедрение системы ≠ автоматизация бизнеса, которая больно бьёт по самому больному месту российского рынка автоматизации: клиенты, обращающиеся за автоматизацией, на самом деле хотят изменить бизнес — а работа большинства 1С-франчайзи заключается в том, чтобы менять систему — была УПП, стала ERP, а в процессах ничего не изменилось. Это происходит из-за того, что где-то по дороге бизнесовая задача внедрения подменяется технической — и подмена эта остаётся незамеченной, напоминая классический монолог Аркадия Райкина про пиджак:
— К пуговицам претензии есть?
— Нет. Пришиты насмерть, не оторвёшь!
«Перейти со старой системы на новую», «нам нужен Честный знак», «старая версия снимается с поддержки» — вот типичные формулировки, под которыми скрывается пустая трата десятков миллионов рублей. По частям, вроде, всё чётко, а в итоге — теряется 90% смысла автоматизации.
Арсенал аналитика быстро растет, но ценность инструмента определяется не новизной, а тем, помогает ли он быстрее и точнее решать рабочие задачи. Секция «Инструментарий аналитика» соберет практические кейсы о методах, технологиях и подходах, которые уже показали результат в проектах.
На INFOSTART A&PM EVENT 2026 секция будет посвящена работе с требованиями, данными и знаниями, описанию сложных систем, взаимодействию со стейкхолдерами и повышению качества анализа.
Как описывать не только сервисы и связи, но и реальные бизнес-сценарии внутри распределённой системы? Показываю Magic Flows в Viaduct: пошаговые потоки данных, визуальный плеер на C4-модели, автоматическая sequence diagram и документация, привязанная к конкретному процессу.
У нас было 14 лекцией и столько же практических семинаров, 100 заявок в первый день запуска, множество кейсов и теоретической базы всех цветов и размеров, 36 участников и 5 матёрых наставников, защита итоговых проектов. Не то, чтобы это был необходимый минимум для решения кадрового вопроса. Но если начал делать «Нешколу» для поиска бизнес-аналитиков – становится трудно остановиться.
Привет, Хабр, на связи Мария и Александр из департамента бизнес-анализа в ecom.tech. В этой статье мы расскажем, как запустили открытую школу бизнес-анализа, не тратя ни рубля на маркетинг. Поехали!
Список требований к казначейству легко превращается в десятки строк со статусом «закрывается частично». Для бюджета такая оценка почти бесполезна: за одним «частично» может скрываться настройка на пару дней, за другим — отдельная интеграция с банком.
Разберём рабочий способ классифицировать эти разрывы, проверить спорные требования на данных и понять, что действительно придётся дорабатывать в конкретной конфигурации 1С.
Меня зовут Юрий Силантьев, я руководитель практики «ERP и финансы» в К2Тех, отвечаю за проекты внедрения 1С.
Мы занимаемся крупными внедрениями уже 15 лет. Недавно я разбирал подход, применяемый нами в крупных внедрениях 1С. От подготовки и предпроекта до эксплуатации: какие инструменты используем, как фиксируем договоренности и за счет чего удерживаем проект в управляемом состоянии.
Эта статья будет второй в серии и целиком посвящена нулевому этапу — предпроектному обследованию: зачем он нужен, из чего состоит и какие артефакты мы получаем на выходе.
Привет!
С недавних пор я занимаюсь разработкой онлайн-редактора карт mapus.ai и делаю это с большим интересом. Цель: дать возможность любому желающему создавать интерактивные географические карты за минуты, имея одну лишь идею или задачу, сформулированную текстом. Знаний и установки специализированных приложений не требуется, приносить «материал с собой» не обязательно.
Цель этой публикации — показать одну из возможностей продукта. Назовём это навыком Шерлока Холмса: визуализация статистических исследований для поиска закономерностей, подтверждения или опровержения гипотез.
Привычные термины становятся все более запутанными. Если раннее (до 2003 года) система ГОСТ еще была фундаментальна и системно выстроена (причем это были не переводы западных стандартов), то потом система государственной стандартизации стала резко деградировать.
Шесть лет занимаюсь складскими системами на платформе 1С: обследования, внедрения, миграции. Склады — от 5 000 до 40 000 м².
Вопрос из заголовка я слышу чаще любого другого, и задают его совершенно справедливо: в 1С:ERP (а также в УТ и КА) адресное хранение действительно есть, работает и закрывает заметную часть складских задач. Продавцы WMS на этот вопрос отвечают предсказуемо. Мне проще: бывают склады, которым я отвечаю «незачем».
Разбираю, что именно умеет адресное хранение в ERP, что к этому добавляет WMS и по каким признакам понять, по какую сторону границы находится конкретный склад.