Тренд «сбор бизнес-требований с ИИ» меняет правила игры: теперь автоматизация заявки на оплату расхода можно описывать быстрее и дешевле, что реально снижает стоимость ошибки для новичка, но требует нового навыка — уметь задавать вопросы (и проверять ответы) так же придирчиво, как бухгалтер проверяет НДС.

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

Хорошая новость: ИИ можно использовать как «ускоритель» интервью, декомпозиции и проверки требований. Плохая: если скормить ему кашу из терминов (“сделай автоматизацию расходов”), на выходе получите глянцевый документ, который развалится при первом же вопросе финансового директора. Точнее… при первом же вопросе бухгалтера.

Кейс: автоматизация расходов через заявки на оплату — как собрать бизнес-требования с ИИ

Контекст задачи: что именно автоматизируем

Тезис: «Автоматизация расходов» почти всегда начинается с потока заявок на оплату: кто создаёт, кто согласует, где проверяются лимиты и как платёж попадает в банк.

Обоснование: В РФ распространённый контур выглядит так: 1С (ERP/Бухгалтерия/УХ), согласование в 1С/Битрикс24/Directum/Docsvision/в почте (да, так бывает), затем выгрузка платёжки и отправка через «1С:ДиректБанк» или клиент-банк (СберБизнес, ВТБ Бизнес, Альфа и т.д.). Ошибка на этапе требований приводит к ручным обходам: «согласовали в одном месте, провели в другом, оплатили в третьем».

Практический вывод: Начинайте не с экранов, а с карты потока: от потребности (счёт/акт/аванс) до факта оплаты и отражения в учёте.

Подводный камень: Пытаться «автоматизировать расходы» без определения границ: какие юрлица, какие виды платежей (авансы, налоги, зарплата, командировки), какие исключения (срочные платежи, штрафы, аресты счетов).

Роли и «политика» процесса: кто на самом деле принимает решения

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

Обоснование: Типовой набор ролей: инициатор (сотрудник/закупка), владелец статьи бюджета (ЦФО — центр финансовой ответственности), казначей, бухгалтер, служба безопасности/комплаенс (для новых контрагентов), руководитель. В российских реалиях часто есть «казначейский стоп-лист», лимиты по БДДС (бюджет движения денежных средств), сверка с договором.

Практический вывод: Просите у бизнеса не «согласующих», а таблицу RACI: кто Responsible/Accountable/Consulted/Informed. ИИ отлично помогает собирать и приводить это к форме, но исходные факты даёте вы.

Подводный камень: “Согласует директор” — без условий. Директор согласует всё ровно до того момента, пока поток не станет 200 заявок в день, и не появится «делегируйте на замов».

Как использовать ИИ: сценарий интервью + разбор артефактов

Тезис: ИИ полезнее всего в трёх местах: подготовка интервью, протоколирование/структурирование, поиск противоречий.

Обоснование: Если дать ИИ входные артефакты (регламент казначейства, шаблон заявки, выгрузку полей из 1С, пару примеров “как сейчас”), он быстро соберёт: список вопросов, черновик требований, карту исключений. Но проверять всё равно придётся на людях: ИИ не знает, что у вас «срочная оплата» — это кодовое слово для обхода процесса.

• Перед интервью: генерируем список уточняющих вопросов по ролям (финансы/закупки/бухгалтерия/ИТ).
• Во время: фиксируем решения, термины, исключения, триггеры согласований.
• После: превращаем хаос в структуру: user stories, бизнес-правила, нефункциональные требования, критерии приемки.

Практический вывод: Держите «контракт на точность»: каждый важный факт должен иметь источник — документ, скрин, запись решения (хотя бы в Confluence/Битрикс24/почте).

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

Декомпозиция требований: что должно быть в заявке на оплату (минимум)

Тезис: Требования к заявке — это набор полей + правила заполнения + маршруты согласования + интеграции.

Практический вывод: Описывайте требования в формате «правило + пример + исключение». Это читают и финансисты, и разработчики.

Подводный камень: Пропустить статусы и жизненный цикл (Created/On approval/Approved/Paid/Rejected/Cancelled). Потом начинается «а где моя заявка?» — и возрождается Excel.

Нефункциональные требования: то, что всплывает на внедрении (и больно)

Тезис: В автоматизации расходов нефункциональные требования (права, аудит, скорость, отказоустойчивость) часто важнее отдельных полей.

• Аудит: кто и когда поменял сумму/реквизиты/статью ДДС.
• Права: доступ по юрлицам, ЦФО, проектам (иначе «видим чужие платежи»).
• Интеграции: 1С ↔ ECM (Directum/Docsvision) ↔ банк, обмен статусами.
• SLA: сколько времени заявка может висеть без решения; эскалации.

Практический вывод: В требованиях фиксируйте «что будет считаться инцидентом» и кто его разбирает (ИТ/финансы).

Подводный камень: «Права настроим потом». Потом — это когда уже утекли данные по зарплатным платежам, и всем стало резко интересно.

Два кейса из практики: один норм, другой учебный (как не надо)

Кейс №1 (удачный): Компания на 400 сотрудников, заявки на оплату шли через почту. Собрали бизнес-требования за 2 недели: 6 интервью, разбор регламента, вытащили из 1С справочники статей ДДС и ЦФО. ИИ использовали для протоколов и списка противоречий (например, «срочность» — это 2 часа или до конца дня). Внедрение заняло 8 недель: формы, маршруты, интеграция с 1С и выгрузка в банк. Ручные согласования сократились примерно вдвое, а количество «забытых» заявок — почти до нуля, потому что появились статусы и эскалации.

Кейс №2 (неудачный): «Сделайте автоматизацию расходов» без границ и без владельца процесса. Требования писали “всем миром”, ИИ красиво оформил, но никто не подтвердил бизнес-правила. На UAT (приемочные тесты) выяснилось, что у каждого отдела своё понимание лимитов: кто-то считает по договору, кто-то по месяцу, кто-то по оплате. Итог: переделка маршрутов, конфликтные встречи, и внедрение растянулось в 2 раза. Мораль: ИИ ускоряет, но не заменяет принятие решений.

Про рынок и карьеру: зачем это тем, кто «войти в IT»

Тезис: Навык «разработка бизнес-требований» для процессов типа заявок на оплату — это прямой мост в BA (business analyst), системных аналитиков и внедренцев 1С/ECM.

Обоснование: На российском рынке вакансии аналитиков регулярно требуют: описание AS-IS/TO-BE (как сейчас/как будет), BPMN (нотация схем процессов), user stories, интеграции с 1С, понимание финансовых документов. По деньгам: джуны-аналитики в регионах часто стартуют примерно от 80–120 тыс. ₽, в Москве/СПб — выше; специалисты с 2–3 годами и доменом «финансы/казначейство/1С» нередко уходят в 160–250 тыс. ₽ и дальше, если умеют говорить с бизнесом без магии.

Практический вывод: Если вы новичок, берите узкий домен (заявки на оплату, бюджеты, казначейство) и делайте портфолио: схема процесса + требования + прототип формы + список бизнес-правил.

Подводный камень: Учить только «как рисовать BPMN». Рынку нужно, чтобы вы умели договориться, что считать «оплатой», и где будет точка контроля.

Похожими разборами и практическими методологиями я делюсь на https://itokno.ru — это удобная база, куда можно возвращаться, когда в проекте снова кто-то предложит “просто автоматизировать”.

Экспертный вердикт и инструмент: чек-лист требований для заявок на оплату

1. Границы: какие юрлица, виды платежей, валюты, срочные/несрочные, исключения?
2. Справочники: откуда берём ЦФО, статьи ДДС, договоры, контрагентов — 1С или вручную?
3. Маршруты: правила согласования по сумме/статье/проекту/инициатору. Кто владелец маршрута?
4. Лимиты: что такое «превышение», что такое «резерв», на каком горизонте бюджет проверяем?
5. Статусы: полный жизненный цикл заявки, кто и когда может менять статус, что логируем?
6. Интеграции: платежка в банк, статусы из банка, отражение в учёте. Где «истина» по факту оплаты?
7. Приёмка: критерии приемки (AC) и 10–15 тест-кейсов на исключения: смена реквизитов, частичная оплата, отмена, дубль.

Частые вопросы