Оглавление
1 Поиск таблетки (с ИИ внутри) от проектной боли: 25 протоколов в месяц, до 100 писем в сутки и риск сокращения бюджета
3. Почему большие промпты не работают?
4. ИИ система управления генерацией проектных документов
4.1 Слои ИИ работы с документами
4.2 Режимы ИИ работы с документами
5. Практическая сборка: Projects, источники и отдельные чаты
6. Масштабирование: что можно сделать дальше
7. Эффекты от внедрения ИИ. Конкретно в цифрах
1 Поиск таблетки (с ИИ внутри) от проектной боли: 25 протоколов в месяц, до 100 писем в сутки и риск сокращения бюджета
В корпоративных внедрениях документация часто выглядит как скучная обязаловка: протоколы, ТЗ, проектные решения, версии, таблицы и блоки согласования. Но в реальных ERP проектах корп уровня документация превращается в производственный конвейер. Если этот конвейер буксует, страдают сроки, маржинальность и доверие заказчика.
Именно с этим мы столкнулись на проекте внедрения «1С:Управление холдингом» в начале года. Моя роль была Корп РП (руководитель корпоративного проекта) со стороны Исполнителя. Проект уровня Enterprise (>10000+ чел/часов), много функциональных направлений, сложные требования к документации и жесткий контур согласований и т.д.
Одним из ключевых этапов стал сбор требований. Нужно было подготовить опросники по функциональным направлениям, провести интервью с бизнесом, зафиксировать требования в протоколах и на их основе собрать ТЗ на систему.
Интервью проводились на протяжении 2,5 месяцев с перерывом на новогодние праздники. Параллельно приходилось постоянно обновлять график встреч, повестки, материалы, опросники, готовить протоколы интервью и вести статусы их согласований.
По итогам всех встреч нужно было подготовить около 50 протоколов интервью. Источников для них было несколько:
- письменные ответы бизнес-пользователей — в пике более 100 писем в сутки;
- опросники — где-то заполненные полностью, где-то частично;
- записи и транскрибации интервью.
Отдельная сложность — противоречивые требования разных функциональных заказчиков. Один блок бизнеса видел целевую картину так, другой — иначе. Команде нужно было не просто переписать ответы в документ, а свести разные позиции в согласуемую конструкцию, успешно их согласовать с участниками.
Я смотрел на эту ситуацию как на управленческий риск проекта – риск сдвига сроков согласования Протоколов, а, значит, и сроков ТЗ.
Если протоколы интервью выходят медленно — едет график. Если документы возвращаются с замечаниями — растет себестоимость. Если заказчик видит хаос в протоколах — падает доверие к команде. Если архитекторы тратят время на ручную сборку текста и форматирование, значит, дорогая экспертиза используется не там, где дает максимальную ценность.
Поэтому задачу я видел не как “попробовать ИИ ради ИИ”, а как найти узкое место в производстве проектной документации, ускорить его с помощью ИИ и снизить потери без расширения команды и срыва сроков.
Проект выполнялся на фоне отраслевого сокращения ИТ-бюджетов. Заказчик запустил процедуру оптимизации ИТ-бюджетов и начал требовать жестко обосновать рентабельность работ на этапе сбора требований. А что дешевле: нанять студентов, которые 10 лет будут спокойно считать в Excel, или заплатить вам сейчас за автоматизацию этого блока?
На этом этапе стало понятно: проблема не в том, что команда плохо работает. Проблема в том, что слишком много квалифицированного времени уходит на черновую сборку документов.
А значит, искать нужно было не “еще людей”, а способ убрать рутину из процесса.
Так появилась гипотеза: можно ли часть черновой работы по сборке документов передать ИИ?
2. Первый эксперимент: ИИ ускорил подготовку черновиков протоколов, но протоколы не прошли фильтры согласований
Идея лежала на поверхности: передать ИИ черновую работу по подготовке проектных документов.
На проекте работали две команды исполнителей. Первая активно использовала ИИ: доля модели в подготовке протокола составляла примерно 40–60%. Вторая применяла ИИ точечно — для выжимок из писем, расшифровок встреч и отдельных формулировок; доля ИИ не превышала 25%.
Гипотеза была простой: если поднять долю ИИ до 80% без потери качества, можно примерно вдвое сократить время на подготовку одного протокола в формате docx.
Здесь может возникнуть логичный вопрос: зачем вообще использовать ИИ для генерации черновиков документов, если часть задач можно автоматизировать иначе (например, автогенарацией в 1С Документооборот)? Ответ простой: да, можно. Но задача тут не просто создать docx файл по шаблону, а наполнять его на основе разношерстных данных без заранее описанной структуры.
На вход ИИ было решено передавать данные, очищенные от информации ограниченного доступа: функциональные выжимки из писем; записи и транскрибации интервью; заполненные опросники; примеры правильно оформленного протокола; корпоративный шаблон протокола интервью.
На выходе команда получала черновик документа, который затем проверял и корректировал функциональный архитектор.
Но в боевых условиях все уперлось в качество.
Мы стали получать негативную обратную связь по протоколам, которые готовились с активным использованием ИИ. При этом документы, собранные вручную с минимальной помощью ИИ, согласовывались в 1,5–2 раза быстрее.
На первый взгляд вывод был неприятный: ИИ не справился с корпоративной документацией для проекта 1С:УХ. Однако, анализ замечаний Заказчика к протоколам прояснил картину.
Основная часть претензий касалась не функционального содержания, а оформления: не тот шрифт, размер 13,5 вместо 14, странные горизонтальные линии, неполное соответствие проектному шаблону, местами неудачные формулировки. Около 36% замечаний к ИИ-протоколам относились к форматированию и несоответствию шаблону. Для сравнения, в протоколах, собранных вручную, доля таких замечаний не превышала 5%. Это сигнал о проблеме контроля качества ИИ-документа.
Первый эксперимент показал неприятную вещь: ИИ действительно может ускорять черновую работу, но без контроля шаблона, фактов и правил оформления он создает новые потери.
Мы экономим время на сборке текста, а потом теряем его на согласованиях, замечаниях и ручном “причесывании” документа.
То есть проблема была не в самом ИИ. Проблема была в том, что мы использовали ИИ как соавтора документа, а не как часть управляемой системы.
|
Метрика |
Что показала |
Управляющее воздействие |
|
Доля ИИ в подготовке протокола |
Первая команда использовала ИИ активнее, но качество просело |
Разделить генерацию, аудит и редактирование |
|
Скорость согласования |
Ручные документы согласовывались в 1,5–2 раза быстрее |
Искать не только скорость генерации, но и качество выхода |
|
Доля замечаний к оформлению |
У ИИ-протоколов около 36%, у ручных — до 5% |
Добавить нормоконтроль шаблона до отправки заказчику |
|
Замечания по смыслу |
Функциональная часть не была провальной |
Не отказываться от ИИ, а встроить его в процесс |
|
Возвраты от заказчика |
Локальная оптимизация выявила новое ограничение. Рутину с помощью ИИ мы сняли с команды, но переложили на ФЗ. |
Управлять всем потоком от входных данных до согласования |
Если разложить ситуацию по логике теории ограничений, первый эксперимент с ИИ не решил ограничение всего процесса подготовки и согласования протоколов, а просто передвинул узкое место с подготовки на согласование и переложил часть работ с команды на Заказчика. До ИИ узким местом была ручная сборка черновиков: аналитики тратили много времени на разбор писем, опросников и транскрибаций. После подключения ИИ черновики стали появляться быстрее. Но новое узкое место возникло дальше по потоку — на контроле качества, оформлении и согласовании.
Для проекта важна не скорость появления текста протоколов само по себе, а скорость появления согласованного документа. Поэтому следующим шагом стало не улучшение одного промпта, а перестройка всего потока подготовки документации.
3. Почему большие промпты не работают?
После первого эксперимента стало понятно: проблема не в том, что ИИ “плохой” или “не готов к боевым условиям”. Проблема в другом: мы пытались двумя-тремя запросами заставить ИИ делать черновик документа.
Человек-эксперт многие шаги делает на опыте: помнит шаблон, стиль заказчика, структуру разделов, типовые формулировки и правила согласования.
ИИ без такой рамки работает иначе. Он хорошо генерирует текст, но плохо понимает, какие требования в конкретном проекте обязательны, какой шаблон считается правильным и где проходит граница между “красиво написал” и “документ можно отправлять заказчику”.
Отсюда возникли четыре проблемы ИИ:
|
Проблема |
Как проявляется |
Риск |
|
Входные данные |
Письма, опросники и транскрибации разного качества |
ИИ путает главное и второстепенное |
|
Потеря фактов |
Важная деталь не попадает в протокол |
Требование теряется до ТЗ |
|
Шаблон |
Текст есть, оформление сломано |
Документ возвращается на доработку |
|
Галлюцинации |
ИИ добавляет неподтвержденное требование |
Возникает спор о границах работ |
Корпоративные документы нельзя стабильно производить через разовые большие запросы в чат. Нужен не “идеальный промпт”, а процесс с источниками, правилами, шаблонами и контрольными точками.
4. ИИ система управления генерацией проектных документов
Поскольку я не только корп РП, а имею некоторые хард скиллы (10+ лет опыта разработки ПО и несколько «спецов»), то ИИ обкатывал самостоятельно. Оговорюсь, что я не профессионал во внедрении ИИ, а только подающий надежды любитель.
ИИ система управления генерацией проектных документов состоит из 4 слоев и 3 режимов работы.
Общие правила построения ИИ системы:
- не смешивать в одном пространстве / проекте работу с разными типами документов (Протокол, ТЗ, Отчеты), один тип документа = одно пространство / проект;
- для каждого режима работы (создание, редактирование, аудит) создаем отдельный чат внутри пространства / проекта.
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 под каждый тип документа. Главное — не смешивать в одном пространстве протоколы, ТЗ, проектные решения и отчеты.
Например, для протоколов интервью создается отдельный проект:
“Работа с протоколами интервью”, вводится Инструкция.
В источники проекта загружаются:
- общие правила оформления корпоративных документов;
- правила формирования именно протокола интервью;
- шаблон протокола в docx;
- рекомендации по заполнению;
- несколько корректно оформленных и согласованных примеров.
Внутри проекта лучше развести три отдельных чата:
- создание протокола интервью;
- редактирование протокола интервью;
- аудит и нормоконтроль протокола интервью.
Так снижается риск смешивания контекста.
Для каждого нового типа документа лучше создавать отдельное рабочее пространство Projects: отдельно для протоколов, отдельно для ТЗ, отдельно для проектных решений, отдельно для отчетов.
Правило простое: один бизнес-домен Projects — одно изолированное рабочее пространство для управления контентом конкретного документа.
Если смешать шаблоны отчетов, ТЗ, ЧТЗ и проектных решений в одной базе знаний, модель начнет переносить правила между документами. В одном месте будет требовать ИБ-блок, в другом — использовать терминологию разработки там, где речь только о сопровождении. Это называется перекрестное загрязнение контекста.
Для старта остается ввести правильную Инструкцию для ChatGPT / Custom GPT и загрузить файлы в Источники: Промпты на каждый слой, Шаблон и Примеры. Создание Промптов - отдельная захватывающая история. Впрочем, об этом лучше писать отдельную статью.
Важно: тут речь не про промышленную замену корпоративному документообороту. Это рабочий контур для ускорения черновой подготовки и контроля качества документов на уровне проектной команды.
6. Масштабирование: что можно сделать дальше
Когда подход начинает работать на одном типе документа, его можно масштабировать на ТЗ, ЧТЗ, проектные решения, инструкции и отчеты. Следующий уровень зрелости — извлекать правила из 10–30 успешных исторических документов одного типа: структуру, формулировки, таблицы, обязательные блоки и типовые отклонения. Но это уже отдельная тема — обратный инжиниринг корпоративной документации.
7. Эффекты от внедрения ИИ. Выводы. Конкретно в цифрах
Я замерял эффекты ИИ не “вообще”, а по конкретным операциям в потоке подготовки документов.
Минимальный набор метрик:
- среднее время подготовки одного черновика;
- количество замечаний к оформлению;
- количество замечаний по смыслу;
- объем ручных правок после ИИ;
- скорость выхода от черновика к согласованному документу.
Если хотите только одну метрику – берите 5.
ИИ превращается в управляемый инструмент повышения производительности когда его эффекты начинаешь измерять.
А что с качеством?
Скорость сама по себе ничего не доказывает. Можно быстро сгенерировать плохой документ и потом потерять все сэкономленное время на замечаниях. Как и произошло у нас на проекте внедрения 1С:УХ.
Поэтому я теперь отдельно смотрю на качество результата.
Первый черновик “Отчета о модификации” на 8 страниц, сделанный ИИ, функциональный архитектор проверил за 10 минут и внес не более 5% правок от общего объема текста. Все правки относились к функциональному контексту, а не к формату документа.
ИИ доказал, что может брать на себя значительную часть черновой и нормоконтрольной работы, но финальная смысловая приемка должна оставаться за экспертом.
Отдельный вопрос - отношение команды. Испугались ли ребята, что ИИ заберет их работу? Нет, наоборот. Когда ИИ снимает рутину, остается больше времени на действительно экспертные задачи и саморазвитие.
Для подразделений корпораций, где нормоконтроль годами был отдельной ручной функцией, у меня тревожные новости: их функция будет одной из первых, где ИИ начнет серьезно менять экономику процесса. Если уже не начал.
Для меня как управленца главный вывод такой: ИИ не спасает проект сам по себе. Он дает эффект только тогда, когда встроен в управляемый поток: входные данные, правила, шаблоны, режимы работы, метрики качества и человек на финальной приемке. Если ИИ просто быстрее генерирует контент для документов, он может перенести проблему дальше — в замечания, возвраты и повторные согласования.
8. Послесловие. Материалы к статье
Если у вас в проекте похожая боль на проектах - протоколы, ТЗ, проектные решения, отчеты, ручной нормоконтроль, возвраты от заказчика и перегруженные архитекторы - этот подход можно адаптировать под ваш контур документов.
В статье я показал логику: метрики, режимы работы ИИ, шаблоны, ограничения и контроль качества. Дальше все зависит от конкретного проекта: типов документов, требований заказчика, регламентов, уровня конфиденциальности и зрелости команды.
Для тех, кто хочет не просто прочитать, а попробовать подход у себя, я подготовил отдельный комплект материалов: инструкцию для проекта, промпты для генерации, аудита и редактирования документов.
