Как мы сделали ИИ-ассистента для решения управленческих задач. Взгляд архитектора

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

 

Что изменилось в разработке бизнес-ПО

 

 

Для начала поясню, исходя из чего я сделал вывод, что подходы к разработке бизнес-ПО меняются.

Платформа 1С позволяет создавать бизнес-приложения через классическую быструю разработку (RAD). Благодаря этой бизнес-модели в 1990-х и начале 2000-х годов фирма «1С» смогла успешно отстроиться от конкурентов и получила одно из главных преимуществ на рынке.

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

• метаданные;

• автоматическая генерация форм;

• управление данными через ORM;

• механизмы прав;

• транзакционность;

• серверная логика;

• и многое другое.

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

 

 

В классической разработке бизнес-ПО вне платформы 1С разрабатывать гораздо сложнее.

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

Там разработчику необходимо:

• проектировать модели данных;

• писать SQL-запросы по добавлению новых сущностей и скрипты миграции, чтобы при обновлении базы таблицы и индексы перестроились правильно;

• с нуля строить механизмы авторизации;

• продумывать интеграции;

• обеспечивать CI/CD.

По сравнению с разработкой на платформе 1С это требует гораздо более сложных архитектурных решений и высокой инженерной дисциплины.

 

 

Появление LLM изменило этот баланс и заметно ускорило разработку – особенно для веб-решений. Стало гораздо проще писать код и тесты, генерировать интерфейс. В результате преимущество 1С как среды быстрой разработки стало уже не таким явным.

 

При этом и экосистема 1С не стоит на месте – появляются 1С:Напарник, MCP-серверы и другие инструменты, ускоряющие разработку на 1С. С их помощью гораздо легче решаются тяжелые задачи, которые мы очень не любим делать – рефакторинг кода, подготовка тестов, написание документации. У 1С-ников реально исполнилась мечта – мы наконец-то можем перестать документировать код сами, теперь за нас это спокойно может сделать LLM.

 

Новая парадигма: 1С + LLM + Web

 

Благодаря LLM мы сейчас входим в новую парадигму разработки бизнес-ПО. Мы можем использовать не только 1С в связке с LLM, но и присоединить к ним современный веб-стек, потому что нужно помнить, что клиенту нужен красивый интерфейс. У нас, конечно, есть 8.5 и 1С:Элемент, но по части интерфейса преимущества по-прежнему остаются у веб-приложений.

 

 

Конечно, у веба тоже есть свои плюсы и минусы. Но с помощью ИИ сейчас в вебе можно значительно ускорить следующие операции:

• Быстро описать сущности.

• Сгенерировать для них CRUD-операции – создания (Create), чтения (Read), обновления (Update) и удаления (Delete).

• Быстро построить программные интерфейсы REST API.

• Быстро создать веб-интерфейс.

• Быстро сделать интеграцию с 1С.

Вход в разработку рядом с 1С именно в бизнес-приложениях стал значительно проще.

 

 

Но некоторые вещи стали сложнее: например, порог входа в создание прототипа стал ниже, а порог входа в создание действительно качественного продукта – выше, потому что архитектуру по-прежнему должен проектировать человек.

Да, LLM уже может предложить архитектурное решение и серьезно помочь в его разработке. Но результат все равно приходится проверять, корректировать и адаптировать под реальные ограничения системы. Кроме того, теперь необходимо уметь управлять поведением самой LLM. Поэтому инженерная работа не стала проще – во многом она стала сложнее.

 

 

И я понял, что пришло время переосмыслить роль разработчика 1С.

Разработчик 1С теперь должен быть не только специалистом по платформе, носителем отраслевых знаний и экспертом по автоматизации конкретных бизнес-процессов. Ему теперь приходится становиться архитектором решений. Ему нужно лучше понимать интеграции, взаимодействие разных систем и технологий, принципы их работы.

Кроме этого, мы фактически получили для себя сейчас новую роль – оператора ИИ-систем.

 

 

Использование ИИ-технологий позволяет нам перейти от разработки просто бизнес-приложений к разработке «мышления».

Раньше мы могли на 1С быстро создавать учетные системы и управленческие приложения.

А теперь появилась возможность создавать для бизнеса интеллектуальные сервисы, системы анализа, помощники принятия решений. Это расширило продуктовый горизонт экосистемы 1С.

 

 

Если раньше в 1С мы описывали объекты, реквизиты и связи, то при создании ИИ-ассистента мы описываем уже совсем другие сущности: шаги анализа, методики и структуру рассуждения. По сути, это тоже метаданные, только метаданные для мышления.

 

Идея разработки ИИ-ассистента для управленческих задач

 

 

А теперь от теории перейдем к практике.

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

Цель продукта – создать ИИ-ассистента, который должен:

• принимать на вход управленческую проблему;

• структурировать ее;

• анализировать с помощью определенных методик (о них расскажу позже);

• формировать варианты решений;

• и выдавать воспроизводимый результат.

При этом он должен работать не как чат бот, а как полноценный инструмент анализа.

 

 

Методологической основой работы этого инструмента стал ТРИЗ.

Мы с Алексеем Лустиным давно интересуемся этой темой, и первоначальная идея как раз состояла в том, чтобы попробовать автоматизировать применение ТРИЗ. В частности, в продукт заложен алгоритм решения изобретательских задач ARIZ-85В.

Мы рассматривали и другие методики: TOC, SCAMPER, RCA. Но на текущем этапе решили сосредоточиться именно на ТРИЗ.

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

 

Коротко о ТРИЗ

 

 

Для тех, кто с ТРИЗ раньше не сталкивался, коротко напомню, что это такое.

ТРИЗ – теория решения изобретательских задач, созданная в Советском Союзе Генрихом Альтшуллером.

Он проанализировал огромный массив патентов и попытался найти повторяющиеся закономерности: как возникают сильные изобретательские решения и можно ли превратить этот процесс из озарения в более системную технологию.

В ТРИЗ входят:

• 40 изобретательских приемов;

• матрица противоречий;

• алгоритм решения изобретательских задач АРИЗ;

• стандарты решения задач (76 стандартов в последней версии);

• законы развития технических систем;

• и другие инструменты.

Самое интересное, что в Советском Союзе он не получил большого распространения. Зато его начали активно использовать в других странах – особенно в инженерных компаниях.

• Компания Samsung в 2000 году с помощью ТРИЗ придумала пылесос, который встроен в ручку.

• Intel использовали ТРИЗ-овские методики для преодоления технологических барьеров в чипах.

• В компании Procter & Gamble с помощью ТРИЗ изобрели многослойный памперс.

• А в компании General Electric ТРИЗ успешно применялся не только при разработке продуктов, но и при оптимизации процессов.

При знакомстве с этой методикой часто оказывается, что многие решения мы уже сейчас неосознанно принимаем на основе алгоритмов ТРИЗ. Например, я, когда начинал читать литературу по теме, периодически ловил себя на мысли: «Так я ведь именно так и решаю подобные задачи».

 

 

Если хочется познакомиться с ТРИЗ глубже, я обычно рекомендую начать с книги Генриха Альтшуллера «Найти идею». Это скорее фундаментальный учебник, к которому приходится возвращаться. Я сам читал его больше двух лет: прочитал часть, отложил, осмыслил, вернулся снова. И, по-хорошему, такую книгу можно перечитывать постоянно – каждый раз обнаруживаешь в ней что-то новое.

Есть и более прикладной вариант – книга Сергея Фаера «Траблшутинг. Как решать нерешаемые задачи». Она читается гораздо легче и построена в основном на практических кейсах. Мы с дочерью ее прочитали практически за один вечер: я рассказывал задачу, мы вместе пытались найти решение, а потом смотрели правильный ответ. Причем в этой книге показывается применимость ТРИЗ не только в технических областях, но и, например, в бизнесе и маркетинге. Вообще Сергей Фаер большую часть своей деятельности посвятил выборам, и в частности выборы отлично ложатся на ТРИЗовские методики. А деньги там большие.

 

 

Кстати, в этой же книге я встретил интересную историю про фирму «1С». Те, кто застал большие компьютерные выставки 1990-х и начала 2000-х, наверняка помнят, как это выглядело: огромное количество посетителей, множество стендов, и на каждом стенде бесплатные рекламные материалы – буклеты, каталоги, листовки, мерч. В условиях высокой конкуренции 1С нужно было придумать способ сделать бренд заметным прямо внутри выставочного пространства.

С помощью ТРИЗ придумали решение: на стенде 1С посетителям дарили большой, крепкий, яркий желтый пакет, куда можно было сложить все материалы, которые выдавали на других стендах.

К вечеру большая часть народа ходила по выставке с желтыми пакетами. Классическое решение для привлечения внимания к бренду – пакет по ТРИЗу.

 

Архитектура продукта

 

 

Но вернемся к нашему продукту.

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

• пользователь;

• веб-приложение;

• серверная логика;

• AI-ассистенты;

• механизмы хранения данных;

• и отдельным слоем:

  • AI-обработчики;

  • внешний API к LLM;

  • и файлы задач, ответов и диаграмм.

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

При этом мы не создаем себе серьезных ограничений на будущее: JSON – стандартный формат, данные из которого при необходимости можно перенести в СУБД и дальше работать с ними там.

Вывод: хранение данных в виде текста вместо базы данных ускоряет и улучшает разработку приложения. Такой у нас инсайт получился.

 

Интерфейс приложения и возможности

 

 

Ну и теперь наконец перейдем непосредственно к самому приложению.

Оно называется Artificer – это инструмент для решения изобретательских задач.

В верхней части интерфейса находится пайплайн, который содержит 10 этапов по алгоритму ТРИЗ. Каждый этап разбивается на шаги, и в общей сложности весь анализ проходит за 41 шаг.

 

 

Справа пользователь может выбрать один из четырех типов задач:

• Технико-физическая;

• Информационно-технологическая;

• Организационно-людская;

• Денежно-экономическая.

Это сделано потому, что задачи разной природы имеют в решении свои нюансы.

А поскольку все решения под капотом реализованы через промпты, этот выбор позволяет нам корректировать нюансы формирования промптов.

 

 

Покажу, как это выглядит на практике.

На слайде сверху видны 10 этапов алгоритма ТРИЗ. А ниже – шаги каждого этапа, которые нужно заполнить своими данными.

Обратите внимание, для демонстрации я взял организационную задачу про наставничество.

 

 

На первом шаге первого этапа мы описываем условие исходной задачи:

Есть сотрудники, крутые спецы, но они не хотят помогать молодежи. Отдельно выстраивать структуру наставничества не хочется, постоянного потока новичков нет.

Обратите внимание, что у каждого шага справа есть кнопка «Помочь», по нажатию на которую LLM предлагает свой вариант формулировки для текущего шага.

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

И далее модель начинает проводить нас по алгоритму решения задачи.

 

 

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

Но когда сама последовательность действий уже заложена в интерфейс, ситуация меняется. Пользователю не обязательно досконально знать всю теорию. Система показывает следующий шаг, объясняет, что нужно сделать, а результат формируется с помощью LLM – человек его только проверяет и при необходимости корректирует.

 

 

Кроме того, мы сделали автоматическое построение диаграмм. В ТРИЗ визуальное представление задачи играет важную роль, поэтому на определенных этапах система сама формирует необходимые схемы. Для этого мы используем Mermaid: LLM генерирует описание диаграммы, а приложение уже визуализирует его.

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

 

 

Дальше система последовательно проводит пользователя по этапам ТРИЗ.

Например, один из важных элементов – формирование ИКР, идеального конечного результата.

Для нашего кейса система может сформулировать его примерно так:

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

 

 

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

 

 

И в конечном итоге на десятом этапе у нас формируется ТЗ на изобретение.

Например, в нашем кейсе одним из вариантов стала концепция микронаставничества:

Разработать и внедрить систему кратких обучающих сессий (5-10 минут), интегрированных в текущие рабочие процессы (утренние планерки, завершение задач), где эксперты разбирают типовые кейсы с фиксацией решений в общей базе знаний. Организовать закрепление новичков за наставниками на конкретные задачи с возможностью быстрых консультаций через корпоративные чаты. Внедрить автоматизированный учет помощи (баллы за микросессии и решенные вопросы) с конвертацией в премии или статусные привилегии. Создать в CRM/базах знаний маркировку частых вопросов новичков и механизм автоматического предложения экспертам дополнять базу знаний при ответах в чатах. Критерии успеха: тестирование системы 3-5 экспертами и 2-3 новичками в течение 2 недель, охват более 70% запросов через систему, сокращение времени адаптации на 30%, отсутствие жалоб на перегрузку.

Причем все это было сформировано нейросетью самостоятельно на основе заложенного нами алгоритма и системы промптов – при сравнительно небольшом участии пользователя.

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

• привязать часть вознаграждения наставника к результатам новичка – поощрять не просто сам факт наставничества, а выдавать наставнику премию, зависящую от выполнения KPI новичка;

• организовать для наставника микровознагражение через ачивки, которые выдаются в CRM (помог коллеге решить вопрос – система автоматически это зафиксировала), конвертировать эти достижения в деньги или внутренний рейтинг;

• автоматизировать заполнение FAQ – встроить в него документы, вебинары.

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

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

Для ТРИЗ это практически готовое противоречие. Мне особенно понравилось, как система усилила его в процессе анализа: «Я пашу 24/7, а зарплата не растет».

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

Таким же образом решаются технико-физические, информационно-технологические и денежно-экономические задачи.

 

Используемый для создания ИИ-ассистента технологический стек

 

 

Теперь несколько слов об используемых технологиях.

На самом деле конкретный стек здесь не важен.

• Для интерфейса подобного ИИ-ассистента можно использовать, например, 1С:Элемент или классические фреймворки Next.js, Nuxt – вайбкодинг с любыми фронтенд-движками работает очень хорошо.

• Для дизайн-системы удобно использовать готовые библиотеки компонентов вроде shadcn/ui. Там большое количество элементов, которые хорошо подходят именно для бизнес-приложений: формы, таблицы, диалоги, панели, навигация и другие.

• Для генерации схем и диаграмм мы использовали Mermaid. LLM генерирует текстовое описание схемы, а приложение автоматически превращает его в визуальную диаграмму. В дальнейшем этот подход можно развивать: например, позволять пользователю не только видеть автоматически созданные диаграммы, но и редактировать их, корректировать отдельные элементы и использовать получившуюся модель на следующих этапах анализа.

• Для хранения данных на этапе прототипа мы использовали JSON-файлы. А в дальнейшем можно перейти на колоночную СУБД, например.

• Отдельный компонент – AI-шлюз. Мы экспериментировали с разными вариантами подключения моделей, в том числе с локальными, чтобы их можно было развернуть внутри закрытого контура компании. Сейчас основной вариант у меня работает с облачными моделями через OpenRouter.

 

Изменения в процессе разработки

 

 

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

• Раньше значительная часть работы разработчика заключалась в том, чтобы спроектировать базу данных и написать код.

• Теперь мы уже проектируем метамодели и сценарии рассуждения.

И здесь интересно сравнить понимание технологии и предметной области для двух миров – разработчиков 1С и классических веб-разработчиков.

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

• А у разработчиков 1С, наоборот, сильная сторона – это предметная область, а к технологии нам еще нужно адаптироваться, многие технологические вещи для нас еще непонятны.

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

 

 

При этом нам с приходом LLM приходится осваивать новые компетенции:

• работу с промптами;

• новые подходы к дизайну систем;

• фактически возникает новая архитектура интеллектуальных систем.

Но вместе с этими возможностями появляются и новые риски.

• LLM может работать нестабильно. Один и тот же запрос может приводить к немного разным результатам.

• Есть проблема галлюцинаций. Ответы модели необходимо проверять.

• Есть риск потери структуры.

 

Главные выводы

 

 

Главные выводы, которые я получил:

• LLM не заменяют платформу 1С.

• Они расширяют быструю разработку бизнес-приложений (RAD) за ее пределы.

• Разработчики получили новые инструменты – мы теперь можем делать другие, более интеллектуальные системы.

• Разработка смещается от кода на более высокий уровень – к архитектуре мышления.

 

 

Если раньше мы быстро создавали учетные системы, то теперь мы можем быстро создавать интеллектуальные системы. И для разработчиков 1С, как мне кажется, это довольно важная точка роста: она позволяет по-другому сформулировать свою ценность внутри компании и понять, куда развиваться самому.

Продукт уже сейчас используется в рамках нашего направления Инфостарт Консалтинг. Скоро мы планируем выкатить облачную редакцию, а на конференции INFOSTART A&PM EVENT 2026 мы с Алексеем планируем провести по этому приложению мастер-класс.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.