Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Системный и бизнес-анализ доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 25
...
Если я правильно понял идею, и справочники различных сущностей и взаимодействий предполагается выдавать LLM, то чем обусловлен выбор excel для их хранения? Есть ведь множество общедоступных инструментов позволяющих сразу задавать связи между сущностями в различных нотациях?
Да, вопрос справедливый. Excel в моём случае — не принципиальный выбор как «лучшее архитектурное хранилище», а первый рабочий носитель, который позволил быстро собрать связанные справочники сущностей, статусов, маршрутов, источников и проверок.
Сейчас я бы уже точнее формулировал не «Excel-ядра», а «опорное ядро данных»: то есть устойчивый слой предметной логики, который может быть реализован и в Excel, и в XML, и в graph DB, и в Mermaid/ERD, и в другом инструменте. Смысл не в Excel, а в том, чтобы LLM не восстанавливала предметную область заново при каждом запросе.
Думаю, отдельно напишу статью именно об этом: где заканчивается вопрос формата хранения и начинается вопрос процессно-предметного ядра.
Пока читал статью, всё чаще приходила в голову сказка про «суп из топора» в части итеративного создания ценности: начинаем с абстракции, постепенно добавляем структуру, контекст, связи.
Проделана серьёзная работа: связки «проблемы модели – причины – решения» описаны верно, очевидно, что Вы и самостоятельно разбирались долго и глубоко, и в диалоге с LLM выясняли их специфику (это заметно). Создать постоянный репозиторий под LLM-задачи – это реально хорошее с практической точки зрения решение.
Но есть момент, который я, возможно, упустил: какова конечная цель этой работы?
«Наведение порядка и устранение хаоса» – это метод, а не цель. Порядок – это отлично, но на практике цель всегда подчинена задаче. Кто или что является «потребителем» этого репозитория, как часто и для каких задач?
Без ответа на вопрос «зачем» даже самая красивая структура рискует стать артефактом, который жалко выбросить, но непонятно, как использовать. Не будем забывать, что создание этого репозитория – не финал. Поддержка актуальности таких систем – отдельная задача и отдельная стоимость.
Если не NDA – опишите, пожалуйста, полностью задачу, которую пытаетесь решить. Это помогло бы оценить не только качество исполнения, но и масштаб окупаемости усилий.
Спрашиваю не из праздного любопытства – просто вижу параллели со своей практикой.
Допускаю, что задача – генерация документации «на лету» в условиях ограниченного инструментария (недоступны ARIS / Sparx EA / Visual Paradigm). Если так – поделюсь своим костылём, который работает.
Мои аналитики чертят подробные BPM/EPC/Sequence с переиспользованием ключевых артефактов, я сохраняю их в XML или mermaid и отдаю в LLM с одним из отлаженных промптов. Эти форматы LLM читают охотно и корректно. На выходе получаю черновики БТ, пользовательских сценариев и даже тест-кейсов. Да, их приходится «причёсывать», но это не написание с чистого листа и время экономит заметно.
Может, такой подход снизил бы нагрузку на поддержку Вашего репозитория?
Спасибо, это очень точное замечание. Вы правы: «наведение порядка» само по себе не является конечной целью. Это только метод.
Потребитель такого репозитория — не абстрактная LLM, а связка: аналитик, архитектор, проектная команда, ИИ-ассистент и контур проверки результата. Цель — быстрее получать не просто текст, а проверяемые проектные артефакты: паспорт процесса, описание операций, краткие инструкции, сценарии проверки, trace-связи и основания для настройки или доработки системы.
Вы правильно подняли вопрос стоимости поддержки. Если репозиторий живёт сам по себе и не включён в производственную цепочку артефактов, он превращается в красивый склад, который жалко выбросить. Я как раз пришёл к выводу, что ценность появляется только тогда, когда каждый слой становится входом для следующего результата.
Отдельно планирую статью на эту тему: «Зачем нужен репозиторий предметной логики для LLM: кто его потребляет и когда он окупается».
Благодарю за добротную публикацию, перенесшую в 2008...2010 годы, в части: и ексель-ядра, задействованного англосаксонским партнёрами в качестве блокчейн-платформы (- источника правды) при реализации партиссипативной системы управления в пилот-е (-ах) с кайдзен-циклами Go&Look&$ee&Do с 8...72 часовыми спринтами на Gemba cо встроенными циклами Шухарта (PDCA) при построении/внедрении не1С ERP при реинжиниринге процессов при помощи картирования операций для фокуса видимых потерь на АsIs и устранения на ToBe, с параллельным спагетированием и последующим выравниванием на ямадзуми...
Спасибо за ассоциацию с кайдзен, PDCA, Gemba, картированием операций и As-Is/To-Be. Мне кажется, это действительно близкая инженерная линия.
Разница, которую я сейчас пытаюсь нащупать, в том, что предметная модель должна быть пригодна не только для команды улучшений и человека-методолога, но и для работы LLM/ИИ-контура. Поэтому приходится жёстче фиксировать сущности, статусы, переходы, источники и проверяемость. В этом смысле это не отмена старых инженерных дисциплин, а попытка перенести их в среду, где вместе с человеком начинает работать ИИ.
Всю дорогу было ощущение, что статья тоже написана нейросетью
скорее структура человеческая а текст в некоторых местах сгенерен да - я пролистываю такие места )
почему то такой текст сразу заметно! :)
Спасибо, замечание принимаю. Для следующего текста постараюсь сделать меньше гладкого объясняющего полотна и больше конкретных проектных примеров. Здесь я пытался сначала зафиксировать саму рамку проблемы, но понимаю, что на Хабре слишком ровный текст быстро начинает восприниматься как LLM-generated, даже если мысль выросла из практики.
Понимаю это ощущение. Тема как раз пограничная: статья написана по материалу реальной работы с LLM и вокруг LLM, поэтому часть формулировок действительно может восприниматься как слишком гладкая или «нейросетевая».
Для меня здесь важнее другое: проверить, выдерживает ли сама мысль профессиональную критику. Если где-то текст выглядит слишком обобщённым или стерильным, это хороший сигнал для следующих публикаций — нужно давать больше конкретных примеров, проектных ошибок и разборов «было/стало».
Автор столь подробно отвечает, что это маловероятно. Кто любит писать, с нейросеткой не поделится ;-)
И, кстати, не разделяю Вашего ощущения - в тексте нет вот этих нейросетевых залипух, о борьбе с которыми статья: когда слова статистически подобраны, а идеи за ними нет.
Статья хорошая, занес себе в закладки, наверное пригодится подробность и детальность. Но читал пролистывая, многовато буков, сейчас мне кажется так не читают (могу ошибаться). Вывод для себя сделал еще раз - "Подробная и Детальная Спецификация" это основной (важный) фактор успеха проекта на ИИ (диалоге моделью)
Спасибо, что дочитали хотя бы выборочно и вынесли для себя главный смысл. Я бы только чуть уточнил: важна не просто подробная спецификация. Подробной может быть и мёртвая документация на 300 страниц.
Ключевой фактор — проверяемая структура: предмет, состояние, источник, маршрут, роль, событие перехода и сценарий проверки. То есть не объём сам по себе, а возможность пройти от описания к действию и проверить результат.
Я кажется понял ...
Кирилл, добрый день.
Делюсь подходом, который решает ту же боль без «Excel-ядер». Он проверен и работает.
Суть (итеративно):
Берёте любой старый документ или транскрипт встречи. Прогоняете через LLM по прилагаемому промпту (первый проход).
На выходе — глоссарий (все термины, незнакомые помечены [? ТЕРМИН ?]) + очищенный текст.
По этому глоссарию рисуете ERD на Mermaid (сущности, атрибуты, связи, ключи). Это архитектурная база, а не таблица в Excel.
Следующие документы подаёте модели вместе с текущим глоссарием и ERD — LLM отлично парсит Mermaid и не путает сущности.
Новые термины -> дополняете глоссарий и ERD (человек или LLM под контролем).
На этой очищенной базе генерируете чистую документацию (процессы, инструкции, требования) — без галлюцинаций.
Важный совет: не изобретайте промежуточных сущностей вроде «слоистых ядер». ERD + итеративный цикл — проще, архитектурно чище и легко поддерживается.
Скрытый текст
Твоя роль
Опытный системный и бизнес-аналитик (розничная торговля, логистика, РФ)
Цель
Создать Протокол встречи для страницы в Confluence (минимальный копипаст)
Границы уровня Base
Табличное форматирование для Confluence
ОДНА диаграмма в формате ERD (Mermaid)
Требования в едином формате
Время выполнения: 15-20 минут
Входные данные
Транскрипт встречи (файл transcript-*.txt)
Проблемы транскрипта:
Посекундная разбивка фраз спикеров
Шум, отвлечённые разговоры
Ошибки распознавания
Ограничения
Для дальнейшего анализа:
Работай строго по тексту транскрипта
Если требуемая информация не найдена — пиши [НЕТ ИНФОРМАЦИИ]
НЕ добавляй собственные интерпретации и предположения
Приоритет секций (если время ограничено):
Глоссарий + Ключевые инсайты
Принятые решения
Перечень требований
ERD (Mermaid)
Форматирование:
Используй: текст, списки, таблицы
НЕ используй: ссылки, выделение жирным/курсивом
Если автор требования или иной параметр не определён — пиши [НЕ ОПРЕДЕЛЕН]
Задача
Очисти транскрипт от всего, что не относится к бизнес-задаче:
Мемо от системы транскрибации (Тема, Краткое содержание, Ключевые моменты, Принятые решения)
Приветствия и прощания в начале/конце
Личные разговоры (шутки, обсуждения)
Технические обсуждения качества связи
Склей фразы одного спикера в связные абзацы. Убери метки времени.
Выяви и отметь проблемные места: [НЕЯСНО]
Выяви предварительный глоссарий:
[термин]:[описание] — для расшифрованных терминов
[? ТЕРМИН ?]:[описание] — для незнакомых аббревиатур (CAPS + вопрос)
Зафиксируй требования с атрибуцией [автор]
Зафиксируй принятые решения
Построй ERD в формате Mermaid (синтаксис entity relationship diagram). Извлеки основные сущности из разговора (например: Заказ, Товарная позиция, Покупатель, Поставщик, Склад, Статус заказа, Счет, НДС). Укажи атрибуты и связи (один-ко-многим, один-к-одному). Если связь неясна — отметь
[?].
Формат вывода
Титул
Поле Значение Наименование [Заполняет аналитик] Заказчик [Заполняет аналитик] Номер в Jira [Заполняет аналитик] Концепт эпика Для (кто), чтобы (что), необходимо (как) Статус Черновик Аннотация [Краткое описание]
Глоссарий
Термин Сокращение Описание [термин] [если есть] [описание] [? ТЕРМИН ?] [если есть] [требует уточнения]
Предпосылки (AsIs)
[Текст из транскрипта]
Задача бизнеса (ToBe)
[Текст из транскрипта]
Цель задачи
[Измеримая цель если озвучена]
Ключевое решение
[Концептуальный план если озвучен]
Требования
ID Наименование Описание Автор Статус REQ-{Jira}-001 [Название] [Текст] [Автор] Черновик
Ограничения и допущения
ID Наименование Описание Автор Статус SC-{Jira}-001 [Название] [Текст] [Автор] Черновик
ERD (Mermaid)
erDiagram
% Здесь сгенерируй ERD на основе выявленных сущностей
% Пример:
% ЗАКАЗ {
% int номер_заказа PK
% date дата_создания
% string статус
% }
% ПОКУПАТЕЛЬ {
% int id PK
% string фио
% string перс_данные_для_таможни
% }
% ЗАКАЗ ||--|| ПОКУПАТЕЛЬ : оформляетПромпт даю свой, проверенный. Чуток адаптировал его под Вашу задачу (у меня в базе LLM схему чертит под draw.io в mxgraph xml).
Где нужно - допилите под себя.
Должно работать
Подход понятен и, на мой взгляд, вполне рабочий. Если у команды уже есть качественные BPM/EPC/Sequence-схемы с переиспользуемыми артефактами, XML или Mermaid действительно могут быть хорошим машинным входом для LLM.
Я бы только развёл два слоя. Mermaid/ERD/XML хорошо передают структуру связей и схем. Но в моей задаче нужно удерживать ещё и статусы подтверждения источников, основные и альтернативные маршруты, версии, проектные отклонения, человекочитаемые формулировки, операционные инструкции, сценарные формы и приёмку.
То есть я не защищаю Excel как архитектурный идеал. Скорее, говорю о необходимости опорного процессно-предметного ядра. ERD и Mermaid могут быть хорошим представлением этого ядра или одним из его носителей.
По вашему комментарию, скорее всего, сделаю отдельный материал: «Почему ERD и Mermaid полезны, но не заменяют процессно-предметное ядро».
Спасибо, это сильный и полезный комментарий. Я согласен, что глоссарий + ERD/Mermaid — хороший путь для первого структурирования старых документов и транскриптов. Более того, такой подход вполне можно рассматривать как один из рабочих входов в процессно-предметную модель.
Моё уточнение такое: я не считаю Excel обязательным или окончательным носителем. Сейчас я скорее говорил бы об опорном ядре данных. Оно может быть реализовано разными способами: Excel, ERD, Mermaid, XML, graph DB, база данных, ontology-слой.
Но ERD сам по себе обычно фиксирует сущности, атрибуты и связи. В моей задаче дополнительно нужны состояния, события перехода, основные и альтернативные маршруты, статусы подтверждения источников, версии, проектные экземпляры, человекочитаемые формулировки, операционные инструкции и контур приёмки.
Поэтому я бы сформулировал так: ERD и Mermaid не противоречат подходу, а могут быть частью носителя или представления. Но если к ним добавить все эти слои, они фактически начинают выполнять роль того самого опорного ядра.
На этот комментарий хочу ответить отдельной статьёй: «ERD, Mermaid и ОЯД: где заканчивается схема сущностей и начинается проверяемая модель процесса».
Кирилл, всё.
Я увидел 3ю статью, пока что только по диагонали глянул.
Вам бы по-честному с неё начать.
Потому что первые 2 без неё - это серьёзный труд по решению абсолютно абстрактной задачи.
Отвечал в полном недоумении "что же нужно на самом деле"
Всё, паззл сошёлся, вопросы снял.
...
Временно.
Ту статью надо на свежую голову курить и уже предметно обсуждать конкретные вещи
Много лет управляю командами на производственных предприятиях в малом бизнесе. Сейчас встала задача оцифровки бизнес процессов, так как берём крупные ответственные заказв, где возникают высокие риски по неуспеваеию в срок, или заказчик просит изготовить дешевле. Наше привычное ручное управление не способно управлять данными рисками.
ERP нам не по карману. Использование 1с предприятием не позволяет маршрут зимовать состояние заказа на производстве и материальные складские запасы. Работаем вслепую на своей экспертности.
Какую систему для управления бизнес-процессами можно использовать на нашем этапе? Поделитесь, пожалуйста опытом
Делюсь опытом: https://habr.com/ru/articles/1041856/
Спасибо, это очень практичный вопрос. По описанию у вас как раз типичная ситуация малого производства: заказы становятся ответственнее, риски сроков и себестоимости растут, а ручное управление уже не удерживает маршрут заказа, материалы, состояние производства и отклонения.
Я бы здесь не начинал сразу с тяжёлой ERP. Сначала нужен минимальный цифровой скелет управления: заказ, изделие, состав/спецификация, материалы, операции, ответственный, срок, статус, риск, дефицит, факт выполнения и отклонение. Уже вокруг этого можно выбирать инструмент — от аккуратно построенных таблиц и простых low-code/BPM-решений до постепенного перехода к ERP.
Я как раз планирую отдельную статью по этой теме: «Минимальная цифровая модель производства без тяжёлой ERP: заказ, маршрут, материалы, статус, риск».
Там попробую показать не “купите большую систему”, а с какого минимального контура можно начать, чтобы перестать работать вслепую.
Спасибо за Ваш опыт! Крутая статья.
Похоже, этот метод имеет смежное "бытовое" применение.
При создании ИИ-ассистента, мы обнаружили, что если пользователь немного понимает его механику, то ассистент способен упростить довольно сложные задачи. Но если человек мало знаком с ИИ и не мыслит как программист хотя бы немного, то первая же его задача "возьми эти три портянки и дай выкладку" приводит к тому, что ИИ "надумывет" себе тот самый бессмысленный план, затем по нему идёт.
И точно так же возникает задача проверяемого планирования и контроля.
Вы можете как то автоматизировать свою методику? У примеру написать группу скиллов? Мои эксперименты подтвердили эффективность такого подхода. Только задача была иная. Делать полный реверс инжиниринг готовых программных продуктов. И разбирать код. На артефакты архитектурного описания. Включая диаграммы, алгоритмы, справочники, и все что в принципе вам надо для запуска разработки своего ПО по этим документам
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вайбаналитика: как я учил LLM описывать бизнес-процессы, а не имитировать их