Системный и бизнес-анализ

Ранее в «Надёжность, устойчивость, доступность» провели введение в терминологию надежности. В этой статье рассмотрим типовые модели отказоустойчивого кластера.

К сожалению, в текущих публикациях ИТ‑изданий с заголовками «надежность, отказоустойчивость, доступность» и тому подобное не встречал ни моделей надежности, ни расчетов этих самых (показателей) «надежность, отказоустойчивость, доступность», а только качественные критерии: «более надежный», «очень отказоустойчивый» и тому подобное. Инженерная надёжность (например, «Надежность в технике») из научной (инженерной) дисциплины в публикациях ИТ‑журналов (хабр и тому подобное) превратилась в некую менеджерскую дисциплину пусть и с техническими подробностями \ описаниями, например, механизмов переключения резерва, но без математического аппарата (теории вероятности \ теории надежности). С целью популяризации расчетов надежности отказоустойчивых резервируемых структур вычислительной и сетевой инфраструктур ниже предлагается несколько базовых подходов \ моделей \ надёжностных схем.

В статье я расскажу, как мне удалось скачать базу GetCourse с одним только логином и паролем обычного менеджера. Разумеется, скачать можно только то, что доступно самому менеджеру. Но эти данные могут быть очень полезны для аналитики, если хочется видеть картину целиком из сотен и тысяч клиентов.

Привет, Хабр! Я Владислав Тарасенко, системный аналитик в Т‑Банке. Расскажу о том, как проектировал онбординг для аналитиков Мобильного банка.

У нас был онбординг для новых аналитиков, и он не работал. Спустя месяц новички все еще не могли выполнить базовую задачу без помощи наставника. Мы решили подойти к онбордингу как к продукту: с метриками, жизненным циклом, MVP, UAT и поддержкой — и за 320 часов перепроектировали процесс с нуля.

Что изменилось: 

1. Сделали результат онбординга измеримым.
2. Сократили время адаптации: через неделю аналитик готов к работе. 
3. Улучшили автономность: 30% новичков теперь вообще не отвлекают наставников. 
4. Лояльность: оценка удовлетворенности выросла с 7,3 до 9,2 балла. 

Корпоративный ИИ постепенно выходит за пределы диалогового окна. Чтобы языковая модель приносила пользу бизнесу, ей недостаточно уметь отвечать на вопросы. Она должна получать разрешенные данные из информационных систем, работать по заданному сценарию и выдавать результат, который сотрудник может использовать в конкретном процессе.

Такой подход лежит в основе платформы ИИ-агентов, которую развивает Инфостарт. Ее ключевая идея - создавать не универсального цифрового помощника, а отдельных агентов с определенной ролью, источниками данных, правилами и форматом результата…

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

Есть сотрудник. Есть автомобиль. Есть объект заказчика. Нужно проверить документы и оформить допуск.

Что здесь вообще автоматизировать?

Примерно так задача выглядела до тех пор, пока мы не начали разбираться, как этот процесс реально устроен в транспортно-строительной компании на Ямале.

Выбор конфигурации это только начало автоматизации. Дальше приходится определять границы систем, проектировать интеграции, решать, что дорабатывать, а что оставлять типовым, и оценивать стоимость будущего сопровождения.

Этим вопросам будет посвящена секция «Решения 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С.