Business | System analyst

Салют! Сегодня хочу поделиться случаем из практики и назвать его - «Два берега одной реки»

Крупный завод (нефть) — проект описания производственных процессов

Пятый год в профессии БА. За плечами — несколько волн внедрения SAP, пара аудитов и навык разговаривать с технологами на их языке, а не только на языке диаграмм.

Проект: описание и регламентация производственных процессов НПЗ в рамках перехода на процессное управление. Полтора года работы и один из главных уроков карьеры.

‼️Два заказчика — два мира

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

Его позиция:
«Описывайте как есть. Завод — не офис, здесь всегда будут отклонения, и это нормально»

Второй заказчик — руководитель блока процессного управления из корпоративного центра. Чёткая методология, нотация BPMN, жёсткие дедлайны сдачи артефактов в корпоративный репозиторий.

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

На первой совместной встрече они столкнулись лбами. Начальник ПТО сказал, что целевая модель — фантазия людей, которые ни разу не стояли у колонны ректификации. Руководитель из корпоративного центра ответила, что без стандартизации невозможно тиражирование на другие НПЗ холдинга.
Оба были правы. И оба смотрели на меня.

👩‍💻 Как я работала в этих условиях

Первые две недели я пыталась передавать позиции от одного к другому — и быстро поняла, что это ошибка. Я превращалась в ретранслятор конфликта. Тогда переформулировала задачу: найти уровень абстракции, на котором противоречие исчезает.
Пошла в цеха. Неделями ходила с технологами и операторами, смотрела как реально выполняется техническое обслуживание, как обрабатываются отклонения в режимных параметрах. Это дало два результата: заработала доверие начальника ПТО и увидела, что за кажущимся хаосом есть устойчивые паттерны. Это была не анархия — это была незафиксированная система.

✅ Мое решение

Предложила двухслойную модель процессов:

1️⃣ Нормативный слой — как процесс должен выглядеть в эталонных условиях. Чёткий BPMN, роли, точки контроля, KPI — территория руководителя из корпцентра

2️⃣ Операционный слой — типовые отклонения и развилки, которые реально возникают на производстве — территория начальника ПТО, где фиксировалась живая экспертиза завода
Каждый получил своё. Конфликт не исчез — он получил законное место в архитектуре.

‼️ Момент, который запомнился

Процесс планово-предупредительного ремонта установки гидроочистки. Переделывали схему трижды.

Начальник ПТО настаивал: в реальности остановка установки всегда согласовывается неформально с диспетчером за сутки — и только потом идёт официальная заявка.

Руководитель из корпцентра: неформальных согласований в регламенте быть не может.
Я предложила ввести в нормативный слой официальный шаг — «предварительное уведомление диспетчерской службы». Без слова «неформально», но по сути — именно то, что всегда происходило. Легализовали практику, не назвав её хаосом.
Начальник ПТО: «Ну вот, наконец-то по-человечески»

Руководитель из корпцентра: «Это корректно с точки зрения методологии»

Итог
За полтора года — 47 сквозных процессов от приёмки сырья до отгрузки готовой продукции. Модель легла в основу тиражирования на два других завода холдинга.
На финальной презентации начальник ПТО сказал, что впервые видит документацию, которую не стыдно показать оператору пятого разряда. Для меня это была лучшая оценка — лучше любой премии.
На производстве знание живёт не в документах — оно живёт в людях. Задача аналитика — построить мост между этим живым знанием и системой, которая его сохранит.

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Гайд системного аналитика по корректировкам витрин

⏳ 7 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

«Let well alone»: почему в больших проектах мы перестали удалять код

⏳ 6 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Зачем нужны нефункциональные требования к ПО и откуда их взять

⏳ 6 мин | 🟤⚪️⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Салют! Сегодня предлагаю подвести итоги по теме ИИ + аналитик и обсудить - уйдет ли профессия аналитика с рынка?

‼️Мое личное мнение - Нет, не уйдет.

Но уйдет роль «исполнителя», который тратил 60% времени на оформление, перепечатывание полей из PDF в Excel и написание типовых сценариев.

Останется роль «архитектора», который:

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

__________

‼️ Что изменится в ближайший год

1️⃣ Скорость. То, что раньше делалось за 4–5 дней, будет делаться за 1–2 дня. Но количество итераций согласования вырастет — потому что генерировать стали быстрее, а думать — нет.

2️⃣ Инструменты. Вместо набора разрозненных LLM-сервисов появятся агенты, которые сами делают несколько итераций проверки, держат контекст и выполняют цепочки действий. Аналитик будет управлять ими, а не писать промпты вручную.

3️⃣ Навыки. Ключевыми станут не умение красиво оформить документ или написать SQL, а:
· системное мышление;
· умение формулировать задачи для ИИ (промпт-инжиниринг на уровне архитектуры);
· навык валидации и критической оценки;
· коммуникация — потому что решения все равно согласовываются с людьми.

4️⃣ Входной порог. Младшим специалистам станет сложнее входить в профессию через рутину — ту самую, которую ИИ уже забрал. Теперь «набивать шишки» придется на более сложных задачах, где цена ошибки выше.

__

✅ Что не изменится

1️⃣ Ответственность. За проваленный проект, неправильно спроектированную интеграцию или потерянные деньги отвечает человек, а не нейросеть.

2️⃣ Необходимость понимать бизнес. ИИ не знает, почему поле full нельзя использовать из-за legacy-ограничений или почему заказчик на самом деле хочет не то, что написал в промпте. Это знание остается в головах команды и в процессе коммуникации.

3️⃣ Ценность опыта. Сеньор, который прошел через десятки проектов и знает, где обычно возникают проблемы, будет использовать ИИ эффективнее джуниора, потому что знает, что проверять и на что обращать внимание.

Вместо итога

Профессия не исчезнет, но изменится так же, как изменилась профессия бухгалтера с приходом Excel, или верстальщика с приходом CMS.

Исчезнет ручной труд. Останется архитектурное мышление, ответственность и управление инструментами.

Через год мы будем работать не с промптами, а с агентами. Но сидеть на созвонах, согласовывать противоречивые требования и объяснять разработчикам, почему нельзя сделать «как ChatGPT сказал», будем все так же мы.

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Салют! На днях писала пост про то, как ИИ повлиял на нашу работу. Сегодня привожу пример с моей рабочей жизни)

Пример: Интеграция с внешним API поставщика

Был проект по автоматизации закупок. Нужно было интегрироваться с API крупного поставщика, у которого документация была… как бы помягче… «исторической». Swagger-спеки не было, был PDF на 200 страниц, где описание полей шло вперемешку с юридическими оговорками и примерами на устаревшем XML.

Задача: спроектировать систему обмена данными (заказы, статусы, отгрузки), описать маппинги полей и написать ТЗ для разработки адаптера.

👩‍💻 Как я использовала ИИ

1. Структурирование «мусора»

Я скормила ИИ (через API, с соблюдением всех NDA и анонимизацией данных) выдержки из PDF — только описания методов и схемы объектов.

Промпт был такой:

У меня есть описание REST API (фрагменты). Документация неструктурированная. Выдели все эндпоинты, методы, обязательные и опциональные параметры. Приведи в виде таблицы: эндпоинт, метод, описание, входные параметры (с типами), выходные параметры. Если есть зависимости между вызовами — отметь. Не додумывай, только то, что явно написано

ИИ вытащил структуру за 15 мин, которую я вручную собирала бы 2–3 дня. Да, были неточности — нейросеть иногда путала description поля с примером значения. Но база была готова.

2. Генерация маппингов

Дальше нужно было сопоставить поля поставщика с нашей внутренней моделью данных.

Я подготовила таблицу с нашей схемой (поля, типы, ограничения) и дала задание:

Вот поля поставщика (колонка A), вот наши поля (колонка B). Предложи маппинг. Где нет прямого соответствия — отметь как “требует преобразования” и предложи вариант логики. Где данных не хватает — отметь как “требует уточнения у бизнеса”

ИИ выдал черновик маппинга с 40+ полями. Из них около 30 я приняла без изменений, в 7 добавила свои правки, а 3 действительно пошли на уточнение к заказчику (и оказалось, что эти поля реально не используются — я бы сама копалась полдня).

3. Написание ТЗ для разработчиков

Самый приятный момент. У меня была готова структура: эндпоинты, маппинги, бизнес-сценарии. Нужно было превратить это в ТЗ, которое не вызовет у разработчиков 100500 уточняющих вопросов.

Я использовала ИИ так:

У меня есть описание интеграции. Напиши раздел ТЗ “Логика обработки ошибок” для следующих сценариев: таймаут, 4xx, 5xx, невалидный JSON. Для каждого укажи: что логируем, нужен ли ретрай (с какой задержкой), переходим ли в ручной режим. Стиль — технически точный, без воды

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

Аналогично я накидала:

- описание аутентификации
- примеры запросов/ответов (которые ИИ сгенерировал на основе структуры полей)
- чек-лист для приемки интеграции (разработчик сказал потом: «О, тут даже кейс с пустым массивом учтен — спасибо, я б забыл»)

4. Валидация (ключевой момент!)

И вот тут — самое важное. Я не просто скопировала результат.

Когда ИИ сгенерировал маппинг, я заметила странность: поле delivery_address.line2 он замаппил на наше address_extra, а поле delivery_address.full — на наше address_full. Но в документации поставщика было написано, что line2 используется только если full не заполнен. Это бизнес-логика, которую нейросеть упустила (или она была на другой странице PDF, которую я не скормила).

Я докрутила: добавила условие «если full не пуст — берем его, иначе формируем из line1 + line2».

‼️ Без моей экспертизы это уехало бы в разработку, а потом — баг на тестировании и лишняя итерация.

Что по итогу

Итого: вместо 4–5 рабочих дней я уложилась в 1,5 дня. При этом качество выросло — потому что время освободилось на сложную логику и валидацию, а не на перепечатывание полей из PDF в Excel.

‼️В комментариях оставила небольшой вывод👇

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

«Я в режиме реального времени поясняла структуру запросов / ответов в Postman и разбирала документацию в Swagger», — пишет аналитик, который прошел наш курс, а потом два технических собеседования в международные компании. Приятно, конечно ❤️

Если в 2026 году вы хотите:
— научиться выбирать стиль интеграции под вашу задачу;
— начать проектировать с нуля и описывать интеграции в современных стилях (API: REST, SOAP, gRPC и других, + брокеры сообщений);
— узнать как правильно собирать требования и моделировать в UML;
— подготовиться к собеседованию, решив более 100 заданий;
— запустить свой API на Python.

Значит наш курс для вас!

🚀 Начните с открытых бесплатных
уроков — переходите в бот курса и жмите «Старт»
👇
@studyit_help_bot

🚀 Скидка на курс
от канала — 1 500₽ на Stepik по промокоду BAANDSA до конца марта.

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

📣 На открытом уроке разберёмся, когда программируемые реле позволяют быстрее и проще реализовать автоматизацию. Вы узнаете, чем программируемые реле отличаются от ПЛК, где проходит граница их применения и какие возможности дают современные устройства на практике.

❗️На занятии соберём реальный проект на оборудовании ОВЕН и покажем, как передавать данные в облачный сервис. Урок будет полезен инженерам автоматизации, электрикам и специалистам, которые хотят начать программировать промышленное оборудование.

➡️ Открытый урок пройдёт 24 апреля в 20:00 МСК в преддверии старта курса «Программист АСУ ТП».
Подробности и регистрация: https://clck.ru/3SiGjX

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru