Анализ и проектирование систем *

Когда я выкладывал на Хабре кейс по поиску внутренних резервов для развития предприятия (https://habr.com/ru/articles/1038894/), мне казалось что я излагаю какие-то базовые вещи, которые должны быть всем известны. И я очень удивился, когда оказалось что это далеко не так. По этой причине я решил что есть смысл начать объяснять всё сначала. Тем более, что моё понимание бизнес-способностей, как инструмента управления, несколько эволюционировало за время, прошедшее с публикации предыдущих вводных материалов. Поэтому начинаю с новой вводной статьи на тему «что такое бизнес-способности» и предполагаю в дальнейших материалах выкладывать дополнения, формирующие целостное понимание бизнес-способностей и планирования / управления на их основе.

Каждое лето сотни тысяч абитуриентов пытаются понять одну простую вещь:

Поступлю я или нет?

Казалось бы, все данные открыты. Вузы публикуют конкурсные списки, количество мест известно, правила приёма описаны на сайтах.

Но на практике ответить на этот вопрос гораздо сложнее, чем кажется.

Именно из этой проблемы вырос проект AbitList.

Сайт: https://abitlist.ru

Знакомая ситуация. К вам приходит задача: продуктовая команда собрала POC интеграции с внешним провайдером год назад, теперь нужно вывести в production. За это время:

Получил очередное приглашение на мероприятие по цифровизации промышленности. В программе всё знакомо: ERP, MES, PLM, 1С, производственный контур, импортозамещение, интеграции, производственные решения, новые продукты и очередная панельная дискуссия о том, куда движется российская промышленность. Сама по себе такая программа нормальна: предприятиям действительно нужны системы, интеграции и прикладные решения. Но чем больше я смотрю на этот привычный набор слов, тем сильнее возникает один простой вопрос: а что мы сегодня вообще называем цифровой трансформацией?

Внедрение ERP? Интеграцию ERP с MES? Замену импортной PLM? Подготовку регламентов? BI-панель? Электронный документооборот? Производственную аналитику? Новые рабочие места в системе? Всё это может быть полезно, а иногда и совершенно необходимо. Проблема начинается в тот момент, когда обычная автоматизация, внедрение или интеграция начинают называться цифровой трансформацией предприятия.

Эта статья не про конкретную компанию и не про конкретную конференцию. И тем более не про персональные оценки людей, которые занимаются внедрениями. Речь о другом: на рынке сложился язык, в котором слово «цифровизация» часто используется слишком свободно. Иногда под ним понимается реальное изменение способности предприятия управлять собственной деятельностью, но часто — просто поставка цифрового инвентаря: систем, документов, интерфейсов, интеграций и отчётов.

В 2016 году это ещё могло звучать как шаг в будущее. В 2026 году, после скачка ИИ и больших языковых моделей, такая постановка вопроса выглядит уже недостаточной. Поэтому хочется спокойно, без персональных атак, но достаточно прямо спросить: если вы называете свою работу цифровой трансформацией, где ваша методология?

Привет, Хабр! Меня зовут Александр, я работаю в IT с 2006 года, последние годы занимаюсь системным анализом и управлением командами аналитики.

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

Для кого-то T-Shaped — это специалист, который понимает систему шире своей основной области и умеет эффективно взаимодействовать со смежными ролями. Для кого-то — тот, кто должен «уметь всё понемногу». А иногда под этим термином вообще начинают подразумевать сотрудника, который фактически совмещает несколько ролей одновременно. Короче говоря, с T-Shaped все далеко не так однозначно.

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

Команда победителей хакатона разработала AI-платформу для бизнес-аналитики, объединяющую возможности BI-систем и мультиагентного ИИ.

Как они подошли к решению кейса, почему начали с бизнес-анализа, а не технологий, какие выводы сделали на этапе исследования данных и как это повлияло на архитектуру всей системы?

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

Статья будет полезна системным аналитикам и backend-разработчикам, которые проектируют интеграции с внешними API, используют OAuth 2.0 и хотят разобраться в практических сценариях — включая фоновые операции.

Работа проектного института охватывает полный цикл строительного проекта: от изысканий и BIM-моделирования до авторского надзора. Его специалисты уже несколько лет работают в программах комплекта nanoCAD Инженерный BIM (с апреля 2026 года – nanoCAD комплект Инженерия). Но для комплексного BIM-процесса недоставало ключевых звеньев: мощных инструментов архитектурно-строительного моделирования и единой среды для данных.

Было принято решение внедрить nanoCAD BIM Строительство (конфигурация «Архитектура») и CADLib Модель и Архив, чтобы научиться создавать 3D-модели архитектурной части, отработать процедуры информационного моделирования и выпустить собственные автоматизированные шаблоны. Полигоном для экспериментов стал реальный проект малоэтажного гражданского здания.

Привет, Хабр! Меня зовут Анатолий, я руковожу группой автоматизации и управления тестового оборудования в YADRO.

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

Хаотичная работа с тестовыми стендами — это проблема, и я пришел в компанию, чтобы ее решить. Так в YADRO появилась автоматизированная система бронирования тестовых стендов, она же Automated Testing Facility (ATF). В статье расскажу, что она умеет, на каких технологиях основана и почему под наши задачи не подошел Jenkins

Всем привет! В предыдущих двух статьях нашего цикла – шесть основ бизнес-анализа мы с вами разобрали первые два базовых понятия Бизнес-анализа – Заинтересованные стороны (Stakeholders) и Потребность (Need).  Мы выяснили, что аналитик начинает любой проект с определения «кто в игре» для создания рабочей группы проекта и первым делом «ставит диагноз», т.е. определяет истинную потребность заказчика. Но когда потребность сформулирована и решение найдено начинается самая недооценённая часть работы бизнес-аналитика. Потому что даже идеально спроектированное решение может провалиться, если не управлять тем, что происходит между «сейчас» и «потом» — то есть самим изменением.

По данным McKinsey & Company, около 70% инициатив по организационным изменениям не достигают поставленных целей. Причина почти всегда одна и та же: техническая часть выполнена, а человеческая — проигнорирована. Новая система работает, процесс описан, инструкции написаны. Но люди продолжают работать по-старому.

Чтобы не наступить на эти грабли, разберём третье базовое понятие BABOK — Изменение (Change).

Да не вопрос! На самом деле буквально три месяца назад у меня вообще не было никакого AGENTS.md. Он появился автоматом, когда я устанавливал code-review-graph.

История такая: я каждый день провожу стримы на Ютубе, где показываю процесс разработки своего проекта. И однажды в чатике мне посоветовали воспользоваться code-review-graph, чтобы сэкономить токенов в Codex. Я воспользовался советом, запустил установку через терминал — и в проекте автоматом появилась куча инструкций для разных агентов. Среди этих инструкций оказался и AGENTS.md.

Если вы, как и я поначалу, мало что понимаете в этих терминах и для чего они нужны, — сейчас объясню. А если вы полностью в теме — просто покажу кусочек своей «кухни».

Работы в карьере ведутся круглосуточно, и цена ошибки при подсчете объемов добытой породы, контроле устойчивости откосов или оценке работы дробильного оборудования измеряется в реальных деньгах. Маркшейдерская служба осуществляет маркшейдерское сопровождение добычи, фиксирует каждый кубометр добытой породы и следит за тем, чтобы карьер не отклонился от проекта. В этой статье мы расскажем, какие задачи решают маркшейдеры ООО ППП «ГОРНЯК» с помощью программного комплекса nanoCAD Облака точек, как устроен технологический конвейер работы с данными лазерного сканирования и с какими нестандартными вызовами сталкиваются специалисты.

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

Начнём с того, что по-настоящему «вайблю» я где-то с ноября 25 года. До этого моё общение с LLM строилось на копипасте в ChatGPT, DeepSeek, Gemini и обратно. Рука наловчилась, и я в целом не замечала, сколько времени это всё-таки сжирает. Казалось бы, лишнее действие.

Не сказать что я злоупотребляла общением, но когда ты начинаешь кодить, ты очень уверен в себе и думаешь, что всё делаешь правильно. А как только погружаешься в процесс, начинается это… синдром самозванца, выгорание и тревога. Не сочтите меня пессимистом, но всё так и было))

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

А потом случилась революция. И моя компания решила не тормозить.

В проекте пользователям регулярно нужно скачивать наборы документов в виде архива. Изначально архивы формировались только из файлов внутри системы, но задача усложнилась, когда потребовалось добавлять внешние источники. В статье я разбираю решение на базе nginx mod_zip и потоковой генерации архива, позволяющее собирать ZIP «на лету» с минимальной нагрузкой на сервер. Также я подготовил простое демо, где можно всё попробовать самостоятельно.

Циклические испытания материалов – это задача, где важны не только механика установки, но и качество программного контура: нужно управлять нагружением, синхронно снимать данные с датчиков, сохранять результаты и видеть процесс в реальном времени.

В совместном проекте внедрения с Институтом физики твердого тела (ИФТТ) РАН мы проверяли, можно ли использовать Engee как основу для автоматизации установки циклических испытаний композитных материалов. Перед нами стояла прикладная задача: реализовать сбор данных с тензодатчика и датчика перемещения и управление сервоприводом.

Через несколько лет после сдачи проекта новая команда открывает модель. Формально всё на месте: проектная документация сохранена, каталоги и базы данных переданы, архив доступен. Но как только нужно продолжить работу — внести изменение, проверить выпуск или подключить нового подрядчика, — появляется главный вопрос: можно ли понять, почему данные устроены именно так?

Это не критика искусственного интеллекта, а размышления на тему к чему может привести бездумное использование этого весьма полезного инструмента. Осознаём ли мы, что в погоне за прибылью держатели больших языковых моделей разрушают человеческий интеллект.

Не секрет, что генеративные трансформеры ничего не изобретают, а лишь используют большие языковые модели для генерирования (комбинирования) правдоподобных текстов. Соответственно, те, кто использует сгенерированные тексты без должного критического анализа, невольно теряют квалификацию, если, конечно таковая была. Тот, кто никогда не был квалифицированным специалистом, впадает в эйфорию, воображая, что теперь он может решать задачи, не обладая необходимыми знаниями.

Это будет работать до тех пор, пока действительно знающие люди стоят у руля разработок. А вот когда им на смену придут освоившие взаимодействие с ИИ, но не обладающие необходимой квалификацией для трезвой оценки результатов, полученных при помощи ИИ – вот тогда случится беда.

Так же известно, что от версии к версии в модели добавляются скрытые детерминированные механизмы (модель думает), улучшающие адекватность ответов. Соответственно,  чем «умнее» становятся модели, тем больше в них добавляется человеческого фактора. Хорошо это или плохо? Для коммерческого продвижения точно хорошо. В любом случае человеческая предвзятость может накладывать свой отпечаток на ответы ИИ.

Пищей для моделей служат различные источники, достоверность сведений из которых не гарантирована. С генерацией программного кода дело обстоит получше, но в любом случае ничего нового придумано ИИ не будет. Максимум, что может случиться, так это некоторое улучшение (вырождение) результатов, если обучение моделей будет выполняться на результатах других генераций признанных наиболее удачными.

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

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

Кстати, все это мы в свое время обсуждали (да и сейчас продолжаем) в канале Практики FinOps в Telegram. Там сидят те, кто проходил этот путь раньше, - иногда один вопрос в чате экономит неделю собственных экспериментов. Залетайте, если тоже на старте.

Здравствуйте, уважаемые читатели. Вот и настал тот день, когда мы поняли, что наш замечательный проект стал сложным. Спустя три года разработки его поддержка начала требовать значительных ресурсов, внедрение новых фич бизнеса замедлилось, а команда уже давно растеряла прежний интерес. Большинство из разработчиков неоднократно проходили эту стадию. Если посмотреть на ситуацию с другого ракурса, то всё далеко не так уж плохо: проект стал «взрослым», приносит деньги, что позволяет его развивать. Но всё-таки сложность только нарастает, проблемы напоминают снежный ком, и что-то с этим нужно делать.

Решение лежит на поверхности: давайте распилим монолит на микросервисы! Здесь одни достоинства: горизонтальное масштабирование, отдельные команды, независимые сервисы, отказоустойчивость, автономные релизы. Недостатки отсутствуют, ну или почти отсутствуют. А может, если быть честными, их лишь «заметают под ковёр»?

А что если я скажу вам, что при таком подходе мы, скорее всего, получим с десяток микросервисов, которые по цепочке синхронно вызывают друг друга, знают подробности внутреннего устройства каждого, ходят в общие таблицы (крайне запущенный случай), и отказ одного из них вызовет крах всей системы? Прямо как с костяшками домино. Встречайте, Его Величество Распределённый Монолит!