Сегодня все чаще мы слышим про ИИ-зацию всего и вся.
Так, генеральный директор Salesforce Марк Бениофф на форуме в Давосе заявил: «Генеральные директора, которые присутствуют здесь сегодня, — это последние управленцы рабочей силой, состоящей только из людей. Мы переходим в мир, где люди и ИИ-агенты будут работать вместе».
Аналогичный прогноз ранее представил генеральный директор OpenAI Сэм Альтман, который написал в эссе «Эпоха интеллекта»: «В конце концов, у каждого из нас может быть личная команда ИИ, состоящая из виртуальных экспертов в разных областях, которые будут работать вместе, чтобы создать практически все, что мы можем себе представить». Позднее Альтман предсказал, что уже в 2025 году появятся первые агенты ИИ, которые «присоединятся к рабочей силе и существенно изменят результаты работы компаний». Сама OpenAI представила первого ИИ-агента Operator в январе 2025 года, но пока его работу нельзя назвать идеальной.
А что же сегодня? Главный тренд ИИ 2026 года — движение к системам, которые самостоятельно принимают решения и действуют без участия человека. Такие технологии называют шагом к универсальному искусственному разуму, способному учиться, анализировать и адаптироваться. Уже сейчас алгоритмы управляют производством, регулируют цепочки поставок и анализируют поведение клиентов без ручного вмешательства. В банках ИИ оценивает кредитные риски и выстраивает стратегии на основе рыночных сигналов.
А где ИИ‑агенты уже дают реальный эффект? В одном из проектов для b2b‑сервиса ИИ‑агент взял на себя первичную диагностику обращений: он анализирует суть запроса, подтягивает историю клиента, проверяет статус услуг и формирует предварительное решение. Оператор подключается уже к структурированному кейсу. В итоге время ответа сократилось почти вдвое, а нагрузка на первую линию поддержки снизилась на 35%. ИИ‑бот в поддержке: как освободить команду от рутины и повысить качество сервиса. Другой частый сценарий — сопровождение клиентов и внутренних команд.
В крупной компании из финансового сектора ИИ‑агент стал «навигатором» по внутренним регламентам и продуктам. Он не просто отвечает на вопросы сотрудников, а подсказывает следующий шаг: какой документ нужен, какую форму заполнить, кому передать задачу. Это снизило количество внутренних запросов к профильным специалистам и ускорило онбординг новых сотрудников. Отдельный класс задач — управление и аналитика. ИИ‑агенты хорошо работают там, где руководителю нужно быстро получить картину происходящего. В одном из кейсов агент ежедневно собирает данные из CRM, ERP и BI‑систем, выявляет отклонения от плана и формирует краткий отчет с комментариями: где просели показатели, какие гипотезы стоит проверить, на что обратить внимание. Это не заменяет аналитиков, но экономит управленческое время.
А теперь давайте разберемся, как и где эти инструменты могут принести реальный эффект для проектной деятельности? Но для этого сначала нужно окунуться в глубину процесса создания технического решения, например бизнес-приложения или внедрения нового бизнес-приложения. В принципе, сами технологии и последовательности примерно похожи.
Как обычно проходит процесс по традиционной технологии WaterFall?
Если вбить в поисковой строке браузера «Этапы разработки ИС», ты мы получим вот такие этапы:
1 Анализ и формирование требований: изучение бизнес-процессов, определение задач и целей системы, формирование требований пользователей и составление ТЗ;
2 Проектирование (архитектура): разработка структуры базы данных, пользовательского интерфейса (UI/UX), алгоритмов и архитектуры взаимодействия компонентов;
3 Разработка (реализация): написание кода, создание программных модулей, настройка технических средств и интеграция систем;
4 Тестирование и отладка: проверка системы на соответствие ТЗ, выявление и устранение ошибок, обеспечение качества;
5 Внедрение: установка системы на оборудование заказчика, перенос данных, обучение персонала и запуск в эксплуатацию;
6 Сопровождение и развитие: техническая поддержка, исправление ошибок, обновление и развитие функциональности системы.
В теории классическая проектная технология выглядит именно так, однако за каждым этапом скрывается своя внутренняя логика, по которой последовательность этапов выстраивается в таком порядке.
Для ответа на вопрос: сможет ИИ-инструмент снизить трудозатраты проектных команд и дать значимый эффект Заказчику – углубимся в практику процесса.
Давайте заглянем за кулису мира внедрений бизнес-приложений и погрузимся в ту самую айтишную техномагию.
Чаще в современном мире внедрения бизнес-приложений все развивается так:
1 Собираются требования от стейкхолдеров (глав функций) в процессе интервью, простыми вопросами-ответами, следуя чек-листам и нет, идя, по хронологии процессов и вперемешку;
2 Заносятся и классифицируются в реестры требований, кто-то ведет таблично, а кто-то заносит в текстовые файлы, с которыми потом трудно работать в плане сортировки группировки;
3 Напротив каждого проставляют признак Fit-Gap, т.е. содержится данное требование в типовой конфигурации Вендора или нет, а бывают и промежуточные случаи, когда что-то и частично содержится, а что-то нужно «допилить»;
4 Потом аналитик обычно среднего уровня (middle) обсчитывает (если умеет) а чаще вообще идет к программисту, и вообще хорошо, если эту оценку валидируют Segnor-спецы (функциональный или технический — архитекторы), но так бывает не всегда;
5 Создается некое подобие ТЗ, которое дальше и идет в работу, затем играются тендеры и прочее.
Так процесс проходит в большинстве случаев при классической проектной технологии. На первый взгляд, все выглядит если и не оптимально и бизнесово, но хотя бы логично и правильно.
Где прячется MUDA?
Однако нам очень интересно, где же тот резерв, где можно сократить непроизводительные трудозатраты проектных команд, т.е. MUDы. А все самое интересное начинается после, на этапе проектирования.
Чем данный этап является по сути? В обычной практике под этапом проектирования скрывается работа по детализации и уточнению требований к будущей информационной системе и проработка технических задач для разработчиков, в ряде случаев внутри этапа помещают работы по созданию модельного стенда для большей наглядности и раскрытия механизмов работы аналогичных технических решений (моделей). Именно поэтому этап Проектирование путают с Моделированием, но цель данного этапа в классической проектной технологии одна – разложить требования заказчиков на мелкие и конкретные задачи для разработчиков.
И вот в рамках работ данного этапа, как правило, и скрывается та самая MUDA. Для наглядности, дорогой читатель, пару примеров:
На одном сложном и достаточно крупном проекте внедрения 1С ERP для крупного холдинга (мультибрендовый авторитейлер) затянулся этап проектирования, с одной стороны у нас же были все методологические вводные для проектного решения (формализованные бизнес-схемы, макеты интерфейсов и тд.), но с другой — тимлиды бесконечно спорили какие объекты брать за основу и дорабатывать существующие объекты типовой конфигурации, причем кардинально, либо написать техническое задание на разработку функционала, что называется «в чистом поле». Данные терзания и метания стоили проекту дополнительно 4-6 месяцев по моим скромным оценкам.
Еще один проект, но с явно выраженным уклоном на Agile – разработку, хотя формально проект шел по классической технологии и был явно крупным (от 150 человек проектных команд в моменте) реализовывал решение на базе 1С для направления ТОРО (класс систем EAM). При наличии технического проекта при переходе в постановку задач для разработки – эскиза проектного решения или рабочей модели при первых же приемо-сдаточных испытаниях нахватали 3-4 тыс замечаний от приемочной комиссии, хотя все бизнес-процессы и схемы были согласованы с Заказчиком.
Бывали примеры, когда сама методологическая база была в процессе становления и это объективно увеличивало сроки постановки задач программистам и сдачу работ на сроки от 3 до8 мес. по разным доменам проекта. И даже при ровном прохождении проекта, этап проектирования может превратиться в какой-то «день сурка», если аналитики со стороны проектной команды сталкиваются с новыми бизнесовыми практиками
И это неудивительно, ведь аналитик не может в голове держать большое количество вариантов будущего поведения информационной системы, нужно, как минимум обладать абстрактным сценарным мышлением, опытом построения поведенческих моделей и прочими нерядовыми способностями
Возьмем простой случай написания сценария для программы, которая будет управлять лифтом в 10-ти этажном доме. Очевидно, что если потенциальный пассажир вызовет лифт (нажимая кнопку) на 1-м этаже, то лифт должен поехать к нему, если он находится выше, чем на 1-м этаже, а если на первом, то открыть двери – очевидно же, не правда ли? С этим справится и аналитик-стажер. Идем дальше, теперь представим, что лифт находится в режиме ожидания на 5-м этаже, и вот, на 1-м нажата кнопка вызова он едет вниз, однако тут же нажимается кнопка вызова на 3-м этаже, очевидно, что лифт должен «подобрать по пути» пассажира с 3-го этажа. Однако как быть если нажмут кнопку вызова на 6-м этаже или пассажир с 3-го этажа (который по пути вниз) вдруг поедет на 9-й этаж, ведь до 1-го всего 2 этажа и он первым по очереди вызвал лифт? А если лифт максимально загружен и едет вниз, но его по пути тоже вызвали – стоит ему останавливаться и только терять время, или, все-таки, просто продолжить свой путь на 1-й этаж?
Возникает очень много вариаций одного и того же процесса, а именно нужно описать от 10 000 сценариев работы программы, которые необходимо предусмотреть и сразу смоделировать, очень часто человеческая логика склонна упрощать количество вариаций, к сожалению.
Таким образом, на одно проектирование одного бизнес-требования может потребоваться от 4-6 дополнительных встреч, но чаще из-за узкой направленности аналитиков и человеческого фактора требуется 8-12 дополнительных уточняющих встреч с одними и теми же специалистами от бизнес-заказчика.
А почему? Потому, что в самом начале собираются и ошибочно упрощается технология управления требованиями к техническому решению и, соответственно, процесс мэппинга деградируется. Так, например, много интеграторы дабы снизить сроки и сложность сбора требований используют в своей практике только артефакт под название функциональные требования, т.е. все высказанные требования от заказчиков «обзываются» функциональными требованиями, однако в них могут присутствовать и функциональные, и что интересно, нефункциональные, и пользовательские, и бизнесовые. Это часто приводит к серьезной путанице в головах аналитиков среднего уровня и даже тимлидов, далее по цепочке – «взрывы мозга» у представителей заказчика обеспечены.
Именно поэтому очень важно разобрать «правильную» технологию управления требованиями к будущему техническому решению. Возьмем более детальную технологию проектирования AI-Tribute, которая уже давала результаты на нескольких реальных кейсах, она состоит из мэппинга разных видов требований (представлена в таблице).
Сопоставление требований для проектного решения.
| Бизнес-цель | Бизнес-задача | Бизнес-требование | Пользовательский сценарий/требование | Результат в ИС | Функционально-техническое требование |
| 1 | 2 | 3 | 4 | 5 | 6 |
| Снизить остатки на складе готовой продукции | Владеть онлайн достоверной информацией о текущих остатках на складе | Разработать отчет в Системе, который будет показывать остатки на складе по номенклатуре и срокам годности в количественном выражении | Пользователь должен иметь возможность сформировать отчет, в произвольной компоновке с расшифровкой по аналитикам, периодам и до первичного документа. Шаг 1 Пользователь задает Организацию. Шаг 2 Пользователь задает Склад. Шаг 3 Пользователь задает другие параметры. | Отчет сформирован, в нем указаны наименования товарных позиций, количество, единицы измерения, сроки истечения годности…. | В Системе в разделе меню «Склад и доставка» должна располагаться гиперссылка на отчет. В меню отчета справа вверху должны располагаться настройки выбора и фильтров. Отчет должен формироваться не более 3-з секунд. Форма не «жесткая», т.е. пустые строки не выводятся в отчет. При выведенном отчете в шапке должна быть кнопка «Обновить»….. |
Из таблицы видно, что функционально-техническое требование заметно более детально – именно оно относится, как правило, к Этапу 2 Проектирование. Так, при работе с бизнес-заказчиками важно отделять процесс сбора и управления требованиями (Этап 1 Анализ и формирование требований) от процесса проектирования. Поэтому колонки 1-5 заполняются с помощью коммуникации с Заказчиком, а колонка 6 – это прерогатива компании – интегратора.
С большой долей уверенности мы нашли место, где ИИ-инструмент может кратно снизить многострадальные хождения к Заказчику для уточнения поведенческой логики работы будущей Системы.
Есть ли реальные AI-инструменты?
Сегодня рынке уже прочно закрепились ИИ-инструменты, которые помогают разработчику в процессе генерации кода.
Так, еще два года назад разработчики писали каждую строку кода вручную. Сегодня инструменты для программиста с искусственным интеллектом ускоряют написание кода на 30-50%, помогают находить ошибки за секунды и генерируют тесты автоматически.
Так, можно выделить основные AI-инструменты: GitHub Copilot — золотой стандарт автодополнения, ChatGPT — универсальный помощник программиста, Claude Opus 4.5 — лидер среди разработчиков в 2026, Tabnine – фокус на конфиденциальности и др.
Но это не касается этапов постановки задач и управления требованиями и экономят трудозатраты конкретных разработчиков, позволяя им меньшим количеством людей справляться с большим объемом задач в единицу времени. Бесспорно здесь есть резервы для сокращения стоимости проектных работ. Однако вернемся к нашим вопросам. Какие ИИ-продукты, могут помочь при проектировании информационных систем при внедрении бизнес-приложений?
Реальный кейс.
Хочу поделиться одним из реальных кейсов, когда проектная команда использовала один из ИИ-инструментов, который подходит для процессов проектирования технического решения на базе собранных бизнес-требований. Так, после долгих сравнений и поисков остановились на использовании продукта с названием — 1Yes.
Далее после первоначального скепсиса (все ожидали много галлюцинаций и необходимости значительных доделок) в процессе реализации проекта по внедрению 1С ERP в промышленном производстве удалось достичь конкретного эффекта, а главное, проработанности проектных сценариев. Учитывая контекст проекта, более 10 функциональных блоков при том, что предприятие не только производило оборудование, но и занималось его сервисом и ремонтом — точное проектное решение должно было с самого начала синхронизировано про кастомизации будущей Системы.
Вот несколько важных аспектов данного ИИ-инструмента, например:
1 Прорабатывает конкретные уточнения шагов и процесса, чтобы превратить простое требование в последовательность гранулярных шагов, сценарий тестирования. 1Yes не просто фиксирует требование – он разворачивает его в детализированный сценарий. Система задаёт уточняющие вопросы, которые аналитик часто пропускает: граничные условия, роли участников, поведение при ошибках. На выходе – не абстрактное «реализовать учёт», а последовательность конкретных шагов с приёмочными критериями, готовая для тестирования. Это снижает риски возвратных итераций с заказчиком;
2 Этот помощник подключается к любой конфигурации на платформе 1С версии 8.3.16 и выше — типовой или полностью кастомной (для более старых версий — это может быть ограничением). Процесс начинается с единоразовой индексации: система анализирует метаданные, их связи и программный код, строя граф с миллионами взаимосвязей. После этого все ответы системы основаны на реальной структуре именно вашей конфигурации, а не на общих знаниях о платформе. Установка ПО на стороне заказчика не требуется — сервис работает через браузер;
3 В своей работе использует LLM-модели frontier-класса, дополненные собственным слоем работы с графом метаданных 1С. Ключевая особенность – модель не работает «вслепую»: контекстом для каждого ответа служит реальный граф конфигурации заказчика, что дополнительно снижает риск возникновения галлюцинаций, характерные для многих универсальных AI-ассистентов при работе с узкоспециализированным кодом;
4 При индексации конфигурации в систему передаются только метаданные и код – без реальных пользовательских данных и бизнес-информации заказчика. Работа с персональными данными не предусмотрена архитектурно, но возможно подключение “прослойки” которая анализирует и маскирует чувствительные данные в момент обращения к LLM. Поэтому с точки зрения информационной безопасности – все предусмотрено;
5 Пользовательский интерфейс пока ограничен (только на русском языке), вариант работы on-premise также возможен;
6 Также нужно выделить потенциальное снижение bus factor. Когда знания о системе зафиксированы в графе Продукта, а не только в головах 2-3 ключевых людей – проект перестаёт быть «заложником» конкретных незаменимых экспертов. Это особенно критично при смене подрядчика или уходе ведущего аналитика из проектной команды;
7 Помощник предлагает два варианта технического решения вместо одного. Система предлагает два альтернативных технических решения с разбором плюсов и минусов каждого. Аналитик выбирает и несёт ответственность за выбор – AI снижает рутину, но не убирает человека из решения. Это важно для сохранения культуры проектной команды;
8 Артефакты для разработчиков соответствуют спецификации OpenSpec , что в свою очередь соответствует Spec Driven Development (SDD) ;
Вместе с тем, нужно понимать, что на рынке найдутся конкурентные AI-инструменты, пишите в комментариях какими пользовались Вы и какие эффекты это принесло? Я же сегодня поделился своим опытом работы с одним инструментом на конкретном кейсе цифровизации.
ИТ-эксперт по цифровизации и автоматизации бизнеса. Архитектор (corp. & solution). Судебный эксперт.