Оглавление

1 Поиск таблетки (с ИИ внутри) от проектной боли: 25 протоколов в месяц, до 100 писем в сутки и риск сокращения бюджета. 2

2. Первый эксперимент: ИИ ускорил подготовку черновиков протоколов, но протоколы не прошли фильтры согласований. 3

3. Почему большие промпты не работают?. 6

4. ИИ система управления генерацией проектных документов. 7

4.1 Слои ИИ работы с документами. 8

4.2 Режимы ИИ работы с документами. 10

5. Практическая сборка: Projects, источники и отдельные чаты.. 11

6. Масштабирование: что можно сделать дальше. 14

7. Эффекты от внедрения ИИ. Конкретно в цифрах. 14

8. Материалы к статье

. 17

1 Поиск таблетки (с ИИ внутри) от проектной боли: 25 протоколов в месяц, до 100 писем в сутки и риск сокращения бюджета

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

Именно с этим мы столкнулись на проекте внедрения «1С:Управление холдингом» в начале года. Моя роль была Корп РП (руководитель корпоративного проекта) со стороны Исполнителя. Проект уровня Enterprise (>10000+ чел/часов), много функциональных направлений, сложные требования к документации и жесткий контур согласований и т.д.

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

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

По итогам всех встреч нужно было подготовить около 50 протоколов интервью. Источников для них было несколько:

1. письменные ответы бизнес-пользователей — в пике более 100 писем в сутки;
2. опросники — где-то заполненные полностью, где-то частично;
3. записи и транскрибации интервью.

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

Я смотрел на эту ситуацию как на управленческий риск проекта – риск сдвига сроков согласования Протоколов, а, значит, и сроков ТЗ.

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

Поэтому задачу я видел не как “попробовать ИИ ради ИИ”, а как найти узкое место в производстве проектной документации, ускорить его с помощью ИИ и снизить потери без расширения команды и срыва сроков.

Проект выполнялся на фоне отраслевого сокращения ИТ-бюджетов. Заказчик запустил процедуру оптимизации ИТ-бюджетов и начал требовать жестко обосновать рентабельность работ на этапе сбора требований. А что дешевле: нанять студентов, которые 10 лет будут спокойно считать в Excel, или заплатить вам сейчас за автоматизацию этого блока?

На этом этапе стало понятно: проблема не в том, что команда плохо работает. Проблема в том, что слишком много квалифицированного времени уходит на черновую сборку документов.

А значит, искать нужно было не “еще людей”, а способ убрать рутину из процесса.

Так появилась гипотеза: можно ли часть черновой работы по сборке документов передать ИИ?  

2. Первый эксперимент: ИИ ускорил подготовку черновиков протоколов, но протоколы не прошли фильтры согласований

Идея лежала на поверхности: передать ИИ черновую работу по подготовке проектных документов.

На проекте работали две команды исполнителей. Первая активно использовала ИИ: доля модели в подготовке протокола составляла примерно 40–60%. Вторая применяла ИИ точечно — для выжимок из писем, расшифровок встреч и отдельных формулировок; доля ИИ не превышала 25%.

Гипотеза была простой: если поднять долю ИИ до 80% без потери качества, можно примерно вдвое сократить время на подготовку одного протокола в формате docx.

Здесь может возникнуть логичный вопрос: зачем вообще использовать ИИ для генерации черновиков документов, если часть задач можно автоматизировать иначе (например, автогенарацией в 1С Документооборот)? Ответ простой: да, можно. Но задача тут не просто создать docx файл по шаблону, а наполнять его на основе разношерстных данных без заранее описанной структуры.

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

На выходе команда получала черновик документа, который затем проверял и корректировал функциональный архитектор.

Но в боевых условиях все уперлось в качество.

Мы стали получать негативную обратную связь по протоколам, которые готовились с активным использованием ИИ. При этом документы, собранные вручную с минимальной помощью ИИ, согласовывались в 1,5–2 раза быстрее.

На первый взгляд вывод был неприятный: ИИ не справился с корпоративной документацией для проекта 1С:УХ. Однако, анализ замечаний Заказчика к протоколам прояснил картину.

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

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

Мы экономим время на сборке текста, а потом теряем его на согласованиях, замечаниях и ручном “причесывании” документа.

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

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

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

3. Почему большие промпты не работают?    

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

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

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

Отсюда возникли четыре проблемы ИИ:

Корпоративные документы нельзя стабильно производить через разовые большие запросы в чат. Нужен не “идеальный промпт”, а процесс с источниками, правилами, шаблонами и контрольными точками.

4. ИИ система управления генерацией проектных документов

Поскольку я не только корп РП, а имею некоторые хард скиллы (10+ лет опыта разработки ПО и несколько «спецов»), то ИИ обкатывал самостоятельно. Оговорюсь, что я не профессионал во внедрении ИИ, а только подающий надежды любитель.

ИИ система управления генерацией проектных документов состоит из 4 слоев и 3 режимов работы.

Общие правила построения ИИ системы:

1. не смешивать в одном пространстве / проекте работу с разными типами документов (Протокол, ТЗ, Отчеты), один тип документа = одно пространство / проект; 
2. для каждого режима работы (создание, редактирование, аудит) создаем отдельный чат внутри пространства / проекта.

4.1 Слои ИИ работы с документами

Слои состоят из:

1 Слой. Контекст пользователя.

Текущая команда в сессии: что именно нужно сделать сейчас.

2 Слой. Базовые правила оформления.

Общие требования к корпоративным документам: шрифты, отступы, таблицы, заголовки, блоки согласования.

3 Слой. Правила конкретного документа.

Отдельная логика для протокола, ТЗ, ЧТЗ, проектного решения или отчета. Здесь живут обязательные разделы, допустимые формулировки и ограничения.

4 Слой. Шаблоны и эталоны.

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

Ключевое правило: ИИ не должен красиво заполнять пустоты. Если данных нет, он должен поставить placeholder и вынести вопрос пользователю.

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

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

ИИ здесь полезен именно тем, что может анализировать контекст. Он должен не просто заменять слова, а понимать, почему конкретная формулировка рискованна или допустима

4.2 Режимы ИИ работы с документами

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

5. Практическая сборка: Projects, источники и отдельные чаты

Описанные базовые подходы можно реализовать в разных популярных LLM- инструментах: ChatGPT, NotebookLM (Gemini) и Claude.

Расскажу про вариант реализации на ChatGPT Projects / Custom GPT.

Представленная тут сборка также без проблем работает в бесплатных и легко доступных китайских AI QWEN и AI KIMI. Насколько качество QWEN / KIMI лучше ChatGPT вопрос открытый (отсылаю любопытных к бенчмаркам).

Для простого старта достаточно отдельного ChatGPT Projects под каждый тип документа. Главное — не смешивать в одном пространстве протоколы, ТЗ, проектные решения и отчеты.

Например, для протоколов интервью создается отдельный проект:

“Работа с протоколами интервью”, вводится Инструкция.

В источники проекта загружаются:

1. общие правила оформления корпоративных документов;
2. правила формирования именно протокола интервью;
3. шаблон протокола в docx;
4. рекомендации по заполнению;
5. несколько корректно оформленных и согласованных примеров.

Внутри проекта лучше развести три отдельных чата:

1. создание протокола интервью;
2. редактирование протокола интервью;
3. аудит и нормоконтроль протокола интервью.

Так снижается риск смешивания контекста.

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

Правило простое: один бизнес-домен Projects — одно изолированное рабочее пространство для управления контентом конкретного документа.

Если смешать шаблоны отчетов, ТЗ, ЧТЗ и проектных решений в одной базе знаний, модель начнет переносить правила между документами. В одном месте будет требовать ИБ-блок, в другом — использовать терминологию разработки там, где речь только о сопровождении. Это называется перекрестное загрязнение контекста.

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

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

6. Масштабирование: что можно сделать дальше

Когда подход начинает работать на одном типе документа, его можно масштабировать на ТЗ, ЧТЗ, проектные решения, инструкции и отчеты. Следующий уровень зрелости — извлекать правила из 10–30 успешных исторических документов одного типа: структуру, формулировки, таблицы, обязательные блоки и типовые отклонения. Но это уже отдельная тема — обратный инжиниринг корпоративной документации.

7. Эффекты от внедрения ИИ. Выводы. Конкретно в цифрах

Я замерял эффекты ИИ не “вообще”, а по конкретным операциям в потоке подготовки документов.

Минимальный набор метрик:

1. среднее время подготовки одного черновика;
2. количество замечаний к оформлению;
3. количество замечаний по смыслу;
4. объем ручных правок после ИИ;
5. скорость выхода от черновика к согласованному документу.

Если хотите только одну метрику – берите 5.

ИИ превращается в управляемый инструмент повышения производительности когда его эффекты начинаешь измерять.

А что с качеством?

Скорость сама по себе ничего не доказывает. Можно быстро сгенерировать плохой документ и потом потерять все сэкономленное время на замечаниях. Как и произошло у нас на проекте внедрения 1С:УХ.

Поэтому я теперь отдельно смотрю на качество результата.

Первый черновик “Отчета о модификации” на 8 страниц, сделанный ИИ, функциональный архитектор проверил за 10 минут и внес не более 5% правок от общего объема текста. Все правки относились к функциональному контексту, а не к формату документа.

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

Отдельный вопрос - отношение команды. Испугались ли ребята, что ИИ заберет их работу? Нет, наоборот. Когда ИИ снимает рутину, остается больше времени на действительно экспертные задачи и саморазвитие.

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

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

8. Послесловие. Материалы к статье

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

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

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