ЕСППД-ИИ. Как описывать бизнес-процессы для работы с искусственным интеллектом

От автора: откуда взялась эта методика

Я руковожу компанией, которая с 2012 года занимается описанием бизнес-процессов и внедрением систем класса ERP. За это время мы не раз сталкивались с одной и той же проблемой: бизнес-процесс вроде бы можно описать словами, можно нарисовать схему, можно составить таблицу операций, но в момент проверки выясняется, что документ не держит реальное исполнение. В нём не хватает предметов, состояний, источников, ролей, переходов, прикладных носителей, исключений и проверок. Такой документ выглядит убедительно, но не позволяет понять, как именно процесс должен работать в системе и как его проверить.

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

Так возникла ЕСППД-ИИ — Единая система процессно-предметной документации для искусственного интеллекта. Это наш внутренний стандарт работы с документацией, а не государственный ГОСТ, не рекламный продукт и не название компании. В этой методичке я объясняю не все технические детали стандарта, а человеческий маршрут: как начать описывать бизнес-процессы так, чтобы с ними мог работать искусственный интеллект и чтобы результат не превращался в имитацию.

Как читать эту методичку

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

После каждого ответа указан блок «Технологическая опора». Это не просто ссылка на код. Технологическая опора — это отдельная технология ЕСППД-ИИ, у которой есть назначение, входы, выходы, место в общей линии и критерии применения. В ранних подходах часто казалось, что достаточно написать хороший промпт: задать модели роль, входные данные и формат результата. Практика показала, что промпт не удерживает сложную предметную область сам по себе. Поэтому в ЕСППД-ИИ вместо набора разрозненных промптов используются технологии: каждая технология отвечает за конкретный участок работы и производит проверяемый результат.

Что такое технологическая опора

Технологическая опора — это описанный и воспроизводимый способ получить определённый результат в ЕСППД-ИИ. У технологии есть код, название, назначение, входы, выходы, связанные данные, условия остановки и критерии приёмки. Технология нужна не для бюрократии, а для того, чтобы ИИ не каждый раз восстанавливал логику из памяти или контекста разговора.

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

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

Часть I. Зачем бизнес-процессам нужна документация для ИИ

Что такое ЕСППД-ИИ и почему понадобился внутренний стандарт

Вопрос: Что вообще такое ЕСППД-ИИ и почему нельзя просто сказать, что мы описываем бизнес-процессы с помощью LLM?

Ответ: ЕСППД-ИИ — это Единая система процессно-предметной документации для искусственного интеллекта. Проще говоря, это способ описывать сложную предметную область так, чтобы её понимал человек и чтобы с ней мог работать ИИ. Она возникла не как теоретическая конструкция, а как ответ на практическую проблему: обычный текст бизнес-процесса не удерживает всю сложность реального исполнения, а LLM без опорной структуры начинает имитировать недостающие части.

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

ЕСППД-ИИ вводит более строгую рамку. Она требует описывать не только процесс, но и предметы, состояния, события, переходы, роли, источники, маршруты, человекочитаемые формулировки, опорные ядра данных и trace-связи. Это делает документацию тяжелее на входе, но зато результат перестаёт быть свободным пересказом и становится управляемым.

Технологическая опора:

ESPPD-AI-TCH-001 — Область и границы предметного описания. Технология определяет, что именно мы описываем, зачем, для кого, какие контуры включаем и что оставляем вне работы. На вход ей нужны цель применения ИИ, описание предметной области, границы проекта и доступные источники. На выходе получается паспорт границ предметной области.

ESPPD-AI-TCH-022 — Паспорт системы и комплектность. Технология управляет составом документов, технологий, опорных ядер данных, проектных экземпляров, схем, чек-листов и архивных сборок. На вход получает документы, версии, статусы и изменения. На выходе даёт паспорт системы и карту актуальности.

Результат: читатель понимает, что ЕСППД-ИИ — это не название продукта и не набор промптов, а система документации, которая удерживает предметную область для человека и ИИ.

Почему одного промпта недостаточно

Вопрос: Разве нельзя просто написать хороший промпт и попросить LLM описать процесс?

Ответ: Хороший промпт полезен, но он не заменяет предметную структуру. Промпт задаёт модели задачу, стиль и формат результата, но он не создаёт достоверные источники, не определяет состояния предметов, не проверяет роли, не знает, какой маршрут является основным, а какой альтернативным. Если этих данных нет, модель начинает достраивать их вероятностно.

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

Поэтому в ЕСППД-ИИ промпт не исчезает, но перестаёт быть главным носителем логики. Главная логика переносится в технологии и опорные ядра данных. Промпт становится инструментом выполнения операции внутри заданной технологии, а не заменой технологии.

Технологическая опора:

ESPPD-AI-TCH-010 — ОЯД / DGC: Опорное ядро данных. Технология задаёт структуру машинной опоры: реестры объектов, процессов, предметов, ролей, состояний, источников, маршрутов, правил и trace-связей. На вход получает результаты предыдущих технологий. На выходе даёт структурированное ядро, на которое может опираться ИИ.

ESPPD-AI-TCH-019 — Trace-связи и проверяемость. Технология связывает результат с исходными данными, источниками, предметами, ролями, маршрутами, версиями и контрольными точками. На вход получает артефакт, источник, предмет, маршрут и версию. На выходе даёт trace-карту и статус проверки.

Результат: читатель понимает, почему промпт не является технологией сам по себе и почему для сложной предметной области нужна опорная документационная система.

Что значит описать бизнес-процесс для ИИ

Вопрос: Чем описание бизнес-процесса для ИИ отличается от обычной блок-схемы?

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

Если в процессе нет предмета, он превращается в набор глаголов: создать, проверить, согласовать, передать, закрыть. Такой текст кажется понятным, пока его читает человек, который и так знает предметную область. Но для ИИ этого мало. Модель не должна угадывать, что именно создаётся, что проверяется и что закрывается. Это должно быть явно описано.

Поэтому в ЕСППД-ИИ процесс рассматривается вместе с предметом. Например, если процесс связан с технологическим изменением, нужно описать не только действия специалистов, но и сам предмет: технологическое изменение, его состояния, события перехода, документы, роли, источники и прикладные носители. Тогда процесс становится проверяемым.

Технологическая опора:

ESPPD-AI-TCH-003 — Процессная архитектура. Технология описывает процессы, группы процессов, границы, входы, выходы, роли и связи. На вход получает объектную архитектуру, интервью, регламенты и документы. На выходе даёт реестр процессов и первичные паспортные описания.

ESPPD-AI-TCH-004 — Библиотека предметов. Технология выделяет предметы, которыми управляют процессы. На вход получает процессы, документы, данные систем и интервью. На выходе даёт реестр предметов, определения, типы, владельцев и связи предметов с процессами.

Результат: процесс начинает пониматься не как цепочка действий, а как управляемое движение предмета через состояния и проверки.

Часть II. Как начинается работа по ЕСППД-ИИ

С чего начинается описание бизнес-процессов

Вопрос: С чего начинать работу: с интервью, со схемы, с промпта или с таблицы?

Ответ: Начинать нужно с границ предметной области. До того как задавать LLM сложный запрос, нужно понять, что именно мы описываем, зачем это нужно, какие контуры входят в работу, какие источники доступны, какие ограничения есть и что сознательно остаётся за пределами описания.

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

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

Технологическая опора:

ESPPD-AI-TCH-001 — Область и границы предметного описания. На вход получает цель применения ИИ, описание предметной области, заинтересованных участников, доступные источники и ограничения. На выходе даёт паспорт предметной области, перечень включённых и исключённых контуров, список ограничений и статус готовности к дальнейшему описанию.

Результат: определены границы работы, и ИИ не получает права свободно расширять предметную область.

Зачем нужны вопросники

Вопрос: Почему нельзя сразу описывать процессы, а нужно начинать с вопросников?

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

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

В ЕСППД-ИИ вопросники используются как вход в объектную и процессную архитектуру. Они не заменяют интервью и экспертную проверку, но помогают не потерять основные контуры.

Технологическая опора:

ESPPD-AI-TCH-002 — Объектная архитектура предметной области. Технология выделяет устойчивые объекты описания, их группы, уровни и связи. На вход получает паспорт предметной области, интервью, регламенты, организационную структуру и перечень систем. На выходе даёт реестр объектов и их статусы.

ESPPD-AI-TCH-003 — Процессная архитектура. Технология раскрывает процессы внутри объектов и связывает их с ролями, входами, выходами и документами. На выходе даёт реестр процессов и их первичные границы.

Результат: появляется первичный контур объектов и процессов, который можно уточнять, а не придумывать заново.

Как из объекта появляется процесс

Вопрос: Что такое объект описания и как из него появляются процессы?

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

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

Главное — не перепутать объект и процесс. Объект отвечает на вопрос «какую область мы описываем», процесс отвечает на вопрос «что в этой области выполняется».

Технологическая опора:

ESPPD-AI-TCH-002 — Объектная архитектура предметной области. На выходе даёт реестр объектов, группы объектов, связи объектов и статусы раскрытия.

ESPPD-AI-TCH-003 — Процессная архитектура. На выходе даёт реестр процессов, группы процессов, границы процессов и связи процессов.

Результат: область описания перестаёт быть сплошным текстом и раскладывается на устойчивые объекты и процессы.

Как из процесса выделяется предмет

Вопрос: Как понять, какой предмет находится в центре процесса?

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

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

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

Технологическая опора:

ESPPD-AI-TCH-004 — Библиотека предметов. На вход получает процессы, документы, данные систем, интервью и источники. На выходе даёт реестр предметов, определения, типы, владельцев и связи предметов с процессами.

Результат: процесс получает предмет-драйвер, вокруг которого можно строить поведение, маршрут и проверку.

Часть III. Как предмет становится проверяемым

Почему предмет должен иметь состояния

Вопрос: Зачем предмету состояния? Почему нельзя просто назвать предмет и двигаться дальше?

Ответ: Если предмет только назван, он ещё не описан. В реальном процессе предмет живёт: он появляется, уточняется, проверяется, согласуется, отклоняется, исполняется, закрывается, архивируется. Эти изменения и есть состояния. Без состояний невозможно понять, что именно произошло в процессе и какой результат можно считать достигнутым.

Представим предмет «заявка». Она может быть черновиком, может быть отправлена на согласование, может быть согласована, отклонена, исполнена или закрыта. Если в описании процесса не указано состояние заявки, то фраза «заявка обработана» остаётся слишком общей. Для ИИ это опасно: модель может сама решить, что обработанная заявка уже согласована, хотя в реальном процессе это разные состояния.

Поэтому ЕСППД-ИИ требует описывать поведение предмета. Состояния показывают, где предмет находится. События объясняют, что запускает переход. Переходы показывают, как предмет меняет состояние. Контрольные точки показывают, где результат проверяется.

Технологическая опора:

ESPPD-AI-TCH-006 — Поведение предметов. Технология описывает предмет через состояния, события, переходы, действия, владельцев и контрольные точки. На вход получает библиотеку предметов, процессы, роли, источники и прикладные носители. На выходе даёт карту состояний, карту событий, карту переходов, допустимые действия и контрольные точки.

Результат: предмет превращается из названия в управляемую сущность, по которой можно строить маршруты и проверки.

Что такое событие и переход

Вопрос: Чем событие отличается от перехода?

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

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

Для ИИ это тоже критично. Без событий и переходов модель будет описывать процесс как последовательность общих действий. С событиями и переходами она может удерживать логику изменения предмета.

Технологическая опора:

ESPPD-AI-TCH-006 — Поведение предметов. Даёт карту событий и переходов.

ESPPD-AI-TCH-019 — Trace-связи и проверяемость. Связывает событие, переход, роль, источник и результат с проверяемыми данными.

Результат: появляется возможность объяснить не только «что сделали», но и «почему предмет перешёл в новое состояние».

Откуда ИИ должен брать данные

Вопрос: Если ИИ помогает описывать процесс, откуда он должен брать данные?

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

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

Технологическая опора:

ESPPD-AI-TCH-007 — Слой источников данных. Фиксирует, откуда берутся сведения о предметах, процессах, ролях, состояниях, событиях и маршрутах. На выходе даёт реестр источников, типы источников, владельцев, статус доступности и ограничения достоверности.

ESPPD-AI-TCH-013 — СОИ / SRL: Слой опорных источников. Связывает утверждения, инструкции и действия с проверяемыми источниками. На выходе даёт реестр источников, статусы подтверждения, ограничения применимости и предупреждения о неподтверждённых действиях.

Результат: ИИ работает не с догадкой, а с источниковой опорой. Если источника нет, это фиксируется честно.

Что такое прикладной носитель предмета

Вопрос: Что значит, что у предмета есть прикладной носитель?

Ответ: Предмет должен где-то фиксироваться. Он может существовать в документе, карточке, регистре, форме, файле, системе, событии, протоколе или экспертном подтверждении. Это место фиксации называется прикладным носителем. Если предмет не связан с носителем, непонятно, где он появляется, где меняется, кто его видит и как его проверить.

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

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

Технологическая опора:

ESPPD-AI-TCH-008 — Мэппинг предметов на прикладные носители. Технология связывает предметы с документами, объектами систем, регистрами, файлами, формами, карточками и иными носителями. На вход получает библиотеку предметов, поведение предметов, источники данных и перечень прикладных систем. На выходе даёт карту «предмет → прикладной носитель», основной носитель, альтернативные носители, условия выбора и статус подтверждения.

ESPPD-AI-TCH-012 — СЧП / HPL. Переводит машинные и методические термины в человеческий язык.

Результат: предмет получает место фиксации, а человек понимает, с чем именно он работает.

[ВСТАВИТЬ ИЛЛЮСТРАЦИЮ 7]

Иллюстрация 7. Предмет и прикладной носитель.

Зачем нужен маршрут

Вопрос: Если есть процесс, предмет и носитель, зачем отдельно описывать маршрут?

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

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

Маршрут не должен быть слишком общим. В нём должны быть событие запуска, действие, роль, статус перехода, результат и контрольная точка. Тогда маршрут становится не просто описанием, а проверяемой линией движения предмета.

Технологическая опора:

ESPPD-AI-TCH-009 — Маршруты работы с предметами. Технология описывает основные и альтернативные маршруты создания, изменения, согласования, передачи, проверки, закрытия или архивирования предмета. На вход получает предмет, состояние, событие, переход, роль, прикладной носитель, источник данных и ограничение. На выходе даёт основной маршрут, альтернативный маршрут, условия выбора, результат и контрольные точки.

Результат: предмет получает управляемый путь, который можно превратить в инструкцию и сценарий.

Часть IV. Как устроена машинная и человеческая опора

Что такое ОЯД и почему это не просто таблица

Вопрос: Что такое ОЯД и почему нельзя назвать это просто таблицей или Excel-файлом?

Ответ: ОЯД — это опорное ядро данных. Английский технический эквивалент — DGC, Data Grounding Core. Оно хранит структурированную машинную опору: объекты, процессы, предметы, роли, состояния, источники, маршруты, связи, статусы, правила и trace-слои. В текущей реализации ОЯД может храниться в Excel, но Excel — это только носитель. Сущность ОЯД не в формате файла, а в функции: удерживать данные и связи, на которые опирается ИИ.

Если нет ОЯД, модель каждый раз восстанавливает логику из текущего разговора. Сегодня она помнит, что предмет называется так, завтра называет его иначе, послезавтра меняет роль или маршрут. ОЯД нужно для того, чтобы правила не плавали. Человек может читать методичку и документы, а ИИ должен иметь структурную опору.

ОЯД не заменяет человекочитаемый текст. Оно делает этот текст воспроизводимым. Из ОЯД можно собрать проектный экземпляр, таблицы, инструкции, trace-карты и отчёты приёмки.

Технологическая опора:

ESPPD-AI-TCH-010 — ОЯД / DGC: Опорное ядро данных. На вход получает объекты, процессы, предметы, роли, состояния, источники, мэппинги, маршруты, правила представления и правила проверки. На выходе даёт структуру ОЯД, реестры, справочники, связи, trace-слои, контрольные листы и журнал изменений.

Результат: появляется машинная опора, которая удерживает правила и снижает риск галлюцинаций.

Что такое проектный экземпляр

Вопрос: Зачем нужен проектный экземпляр, если уже есть ОЯД?

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

Без проектного экземпляра легко смешать общий стандарт и конкретный проект. Тогда локальная доработка начинает незаметно превращаться в новое общее правило. В ЕСППД-ИИ это разделяется. Если правило относится только к проекту, оно живёт в проектном экземпляре. Если оно оказалось общим, его нужно вынести в технологию стандарта и изменить версию.

Технологическая опора:

ESPPD-AI-TCH-011 — Проектный экземпляр. Технология применяет ОЯД к конкретной предметной области или проекту. На вход получает ОЯД, проектные данные, локальные ограничения, выбранные источники и проектные решения. На выходе даёт проектный экземпляр, проектные статусы, выбранные маршруты, локальные правила, проектные артефакты и отчёт приёмки.

Результат: общее правило отделяется от локального применения.

Зачем нужен слой человеческого представления

Вопрос: Почему нельзя просто вывести данные из ОЯД в документ?

Ответ: Машинная структура удобна для контроля, но неудобна для чтения. В ОЯД могут быть коды, технические имена, служебные роли, статусы и внутренние связи. Если вывести это человеку без обработки, документ станет формально правильным, но плохо читаемым. Человек будет видеть «инициатор изменения», «прикладной носитель», «объект», «переход», но не будет сразу понимать, что должен делать технолог, с каким документом он работает и какой результат должен получить.

Поэтому нужен СЧП — Слой человеческого представления. Английский технический эквивалент — HPL, Human Presentation Layer. Он переводит машинные роли в профессиональные роли, машинные термины в смысловые термины, коды и объекты в понятные названия, а технические формулы в человеческие фразы.

СЧП не уничтожает машинную структуру. Он делает две вещи одновременно: сохраняет trace-связь в ОЯД и даёт человеку понятный текст.

Технологическая опора:

ESPPD-AI-TCH-012 — СЧП / HPL: Слой человеческого представления. На вход получает машинные коды, имена, роли, предметы, прикладные носители, маршруты и контекст документа. На выходе даёт человеческие имена, смысловые имена, профессиональные роли, формулировки для таблиц, формулировки для связного текста и запрещённые формулировки.

Результат: документ становится читаемым человеком, не теряя связи с машинным ядром.

Зачем нужен слой опорных источников

Вопрос: Как отличить подтверждённое действие от догадки модели?

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

СОИ — Слой опорных источников. Английский технический эквивалент — SRL, Source Reference Layer. Он нужен для того, чтобы ИИ и человек видели, где утверждение подтверждено, где подтверждено частично, где требуется сверка, а где действие отклонено.

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

Технологическая опора:

ESPPD-AI-TCH-013 — СОИ / SRL: Слой опорных источников. На вход получает утверждение, процедуру, прикладной объект, инструкцию, источник и статус подтверждения. На выходе даёт реестр источников, ссылки, статусы подтверждения, ограничения применимости и предупреждения о неподтверждённых действиях.

Результат: подтверждённые действия отделяются от предположений.

Часть V. Какие документы получаются на выходе

Какие документы создаются по ЕСППД-ИИ

Вопрос: Что получается в результате описания бизнес-процесса по ЕСППД-ИИ?

Ответ: Результатом не является один большой Word-файл. В зависимости от глубины работы могут появляться разные формы: паспорт предметной области, паспорт процесса, текстовая процессная форма, краткая операционная инструкция, сценарная форма, визуальный атлас, карта состояний, карта источников, карта маршрутов, trace-карта и отчёт приёмки.

Человекочитаемые документы нужны для понимания, обсуждения и согласования. ОЯД нужно для машинной опоры. Trace-связи нужны для проверки. Сценарии нужны для воспроизводимости. Если всё это смешать в один документ, он станет слишком тяжёлым. Поэтому ЕСППД-ИИ разделяет формы результата.

Технологическая опора:

ESPPD-AI-TCH-014 — Текстовая процессная форма. Формирует человекочитаемое описание процесса, операции или процедуры. На выходе даёт паспорт процесса, текстовую блок-схему, описание операции и связи с предметами и ролями.

ESPPD-AI-TCH-015 — Краткая операционная инструкция. Формирует короткую прикладную инструкцию выполнения процедуры. На выходе даёт навигацию, прикладной объект, статус, порядок выполнения и предупреждение.

ESPPD-AI-TCH-018 — Визуальный атлас. Формирует схемы, которые помогают человеку удерживать связи объектов, процессов, предметов, состояний, маршрутов, ролей и источников.

Результат: читатель понимает, что разные формы документов отвечают за разные уровни понимания и проверки.

Чем описание процесса отличается от операционной инструкции

Вопрос: Почему нельзя в одном месте описать и процесс, и действия пользователя?

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

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

Технологическая опора:

ESPPD-AI-TCH-014 — Текстовая процессная форма. Используется для описания процесса и операций на человеческом профессиональном языке.

ESPPD-AI-TCH-015 — Краткая операционная инструкция. Используется для формального прикладного порядка выполнения процедуры.

Результат: процессный смысл отделяется от прикладного выполнения.

Почему нельзя сразу переходить к сценариям

Вопрос: Если цель — проверяемый сценарий, почему не начать сразу со сценариев?

Ответ: Сценарий без предмета, источника, маршрута и инструкции будет воспроизводить ту же проблему, что и свободный текст LLM. Он может выглядеть правильно, но не быть исполнимым. Чтобы сценарий стал проверяемым, нужно сначала знать, какой предмет движется, какой маршрут выбран, какие действия подтверждены источниками, какой результат ожидается и какие проверки нужны.

Сценарная форма появляется после операционной инструкции. Проверяемый сценарий появляется после сценарной формы и подтверждённого маршрута. Это не лишние шаги, а защита от имитации.

Технологическая опора:

ESPPD-AI-TCH-016 — Сценарная форма. Переводит операционную инструкцию в сценарную структуру для проверки или автоматизации. На выходе даёт шаги сценария, условия выполнения, ожидаемые результаты и проверки.

ESPPD-AI-TCH-017 — Проверяемый сценарий. Формирует исполнимый или полуисполнимый сценарий проверки. На выходе даёт сценарный файл, протокол проверки и статус прохождения.

ESPPD-AI-TCH-019 — Trace-связи и проверяемость. Удерживает связь сценария с предметами, источниками, маршрутами и версиями.

Результат: сценарий появляется не как фантазия модели, а как продолжение проверяемой документационной линии.

Часть VI. Как человек и ИИ работают вместе

Почему человек остаётся владельцем смысла

Вопрос: Если ИИ помогает описывать процессы, кто отвечает за смысл?

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

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

Технологическая опора:

ESPPD-AI-TCH-001 — Область и границы предметного описания. Удерживает границы человеческого решения.

ESPPD-AI-TCH-012 — СЧП / HPL. Помогает переводить машинную структуру в человеческий текст, но требует проверки человеком.

ESPPD-AI-TCH-021 — Чек-листовая приёмка. Задаёт контрольные листы готовности технологий и артефактов.

Результат: ИИ рассматривается как помощник в стандартизированной документационной системе, а не как самостоятельный владелец смысла.

Где ИИ действительно полезен

Вопрос: Если ИИ не должен всё придумывать сам, где он полезен?

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

ИИ особенно полезен, когда есть ОЯД, СЧП и СОИ. Тогда модель не просто пишет текст, а использует структурированные данные, переводит машинные элементы в человеческий язык, различает подтверждённые и неподтверждённые источники и сохраняет trace-связи.

Технологическая опора:

ESPPD-AI-TCH-010 — ОЯД / DGC. Даёт машинную опору.

ESPPD-AI-TCH-012 — СЧП / HPL. Даёт человеческое представление.

ESPPD-AI-TCH-013 — СОИ / SRL. Даёт источниковую проверку.

ESPPD-AI-TCH-019 — Trace-связи и проверяемость. Даёт связь результата с исходными данными.

Результат: ИИ используется как усилитель работы, но не как источник неподтверждённой истины.

Часть VII. Как начать применять методику

Первый практический маршрут

Вопрос: С чего начать на реальном проекте?

Ответ: На реальном проекте не нужно начинать с написания полной инструкции или сценария. Начать нужно с границ предметной области, вопросников, объектов, процессов и предметов. Это менее эффектно, чем сразу получить красивый текст от LLM, но именно здесь закладывается проверяемость.

Первый маршрут выглядит так: определить границы, собрать вопросники, выделить объекты, описать процессы, найти предметы, задать состояния, указать источники, построить маршруты, сформировать ОЯД, подготовить человекочитаемые документы, проверить источники и только после этого переходить к сценариям.

Если этот порядок кажется длинным, нужно помнить: альтернатива — быстрый текст, который потом нельзя проверить. ЕСППД-ИИ не удлиняет работу ради формы. Она переносит усилие в начало, чтобы не потерять управляемость на выходе.

Технологическая опора:

ESPPD-AI-TCH-001…ESPPD-AI-TCH-009 — первая линия описания: границы, объекты, процессы, предметы, роли, поведение, источники, мэппинг и маршруты.

Результат: появляется предметная структура, из которой можно строить документы и сценарии.

Когда результат можно считать пригодным

Вопрос: Как понять, что результат уже можно использовать?

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

В ЕСППД-ИИ важна не только генерация документа, но и приёмка. Человек должен видеть, какие ограничения остались, какие источники подтверждены, что требует уточнения и какой следующий шаг допустим.

Технологическая опора:

ESPPD-AI-TCH-019 — Trace-связи и проверяемость. Проверяет связь результата с исходными данными.

ESPPD-AI-TCH-020 — Управление версиями, статусами и архивом. Удерживает актуальность файлов и технологий.

ESPPD-AI-TCH-021 — Чек-листовая приёмка. Даёт контрольные листы и решение о готовности.

Результат: появляется критерий готовности, а не просто ощущение, что текст получился хорошим.

Что делать после первой методички

Эта методичка не заменяет стандарт ЕСППД-ИИ. Она объясняет общий маршрут и помогает человеку понять, зачем нужны технологии, ОЯД, СЧП, СОИ, trace-связи и приёмка. После неё можно переходить к двум направлениям работы.

Первое направление — разворачивать отдельные технологии в самостоятельные документы. Для каждой технологии нужно описать назначение, входы, выходы, структуру данных, правила применения, stop-conditions и критерии приёмки. Это технический слой, по которому дальше сможет работать ИИ.

Второе направление — готовить визуальный альбом методики. Но рисовать его нужно только после того, как методичка удерживает общий смысл. Иначе схемы начнут украшать непрояснённый текст, а не помогать человеку понимать систему.

Технологическая опора:

ESPPD-AI-TCH-018 — Визуальный атлас. Формирует схемы, которые помогают человеку удерживать связи объектов, процессов, предметов, состояний, маршрутов, ролей и источников.

ESPPD-AI-TCH-022 — Паспорт системы и комплектность. Управляет составом стандартов, технологий, ОЯД, проектных экземпляров, схем, чек-листов и архивных сборок.

Результат: методичка становится человеческой входной дверью в стандарт, а не заменой стандарта.

Контрольный вывод

Описывать бизнес-процессы для работы с искусственным интеллектом — значит не просто просить LLM написать текст. Это значит подготовить предметную область так, чтобы ИИ мог работать с ней проверяемо: видеть границы, объекты, процессы, предметы, состояния, источники, маршруты, человеческие формулировки, машинную опору и trace-связи.

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