Я руководитель проектов, работаю с крупными корпоратами и банками первой пятёрки.

Самый ад — это когда проект на стыке двух таких банков. У меня есть живой пример )

На этом проекте:

• Юристы и безопасники из двух банков 4 месяца гоняли договор по кругу. Надо было как-то их договорить и всё-таки начать работать.

• Договор был рассчитан до 2026 года, а бюджет в системе был заложен только на 2025-й. Бухгалтерия возвращала ошибку Not defined и предлагала запланировать бюджет на 2026 год прямо сейчас.

• Уволился ключевой подписант.

• Это был ИТ-директор!

Так что у нас есть все виды бюрократии: комплаенс, Департамент кибербезопасности (ДКБ), риск-чемпионы и, конечно, юристы.

Как я уже говорила, это ад.

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

Что бывает, когда такое не выполняется, мы отлично знаем по взломам доставки еды, например, когда стандарт был, но его не применили.

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

О чём проект

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

Руководство банков договорилось, что мы продолжаем использовать эту модель. Это лучше, чем Qwen, и лучше, чем какие-нибудь ChatGPT или Claude, потому что последние два под санкциями, а первый непредсказуем. Плюс надо же как-то развивать своё производство. Поэтому «лучший российский искусственный интеллект». Все счастливы. Казалось бы, бери и делай.

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

Заключение договора

Как я уже говорила, договор стал адом.

Сначала он проверяется на соответствие типовой форме. Малейшее отклонение — подключаются юристы.

Юристы подключались часто, потому что в договоре упоминается доступ к персональным данным — там пришёл комплаенс. Второй красный флаг — услуги предоставляются дольше 12 месяцев — надо стратегическое планирование. Нужен доступ в контур банка? Ждите безопасников, и они будут очень долго и скрупулёзно ковыряться.

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

По плану на подписание было 6 недель. У нас это заняло 4 месяца при том, что мы спешили как могли. Кто знает специфику одного из этих банков — возможно, догадывается, что это мы ещё быстро уложились.

Интересно, что во время подписания второй банк предоставлял сервис авансом, чтобы проекты не останавливались и пользователи ничего не заметили. Потому что, если бы ассистенты отвалились (а там было переключение моделей на отечественные), это был бы суперприз. За что им огромное спасибо.

Как я попала на проект

Я работала на проекте ещё с зимы. Занималась разработкой, руководила командами, выступала мостом между заказчиками и программистами.

А вот подписанием нового договора занимался мой коллега. Он варился в этом котле 4 месяца, и когда договор наконец-то согласовали, со спокойной душой ушёл в отпуск, попросив меня подхватить активность и довести дело до первого заказа.

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

Чтобы сформировать заказ, надо знать, на сколько денег

Коллега, который ушёл в отпуск и попросил меня присмотреть за подписанием первого заказа, уже его сформировал. Там было указано количество пакетов Гигачата, их типы (Lite, Pro, Max) и суммы, на которые закупаем.

Бюджет был — по договору мы обязуемся за полтора года потратить сумму в N миллионов рублей.

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

И тут начался конфликт бюджетирования!

SAP подняла алерт, и этим алертом занялись опытные специалисты из бухгалтерии.

Договор у нас действовал до июля 2026 года, а бюджет в нашей системе бюджетирования проектов был заложен только на 2025-й.

По логике бухгалтерии: раз договор до 2026-го, то и бюджет должен быть расписан сразу на весь срок. Они требовали запланировать бюджет на 2026 год сейчас, летом 2025-го. Но в банке так не делается. Бюджет на 2026 год планируется только в начале 2026-го. Мы не можем прийти в будущее.

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

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

И как только мы начали разбираться, как это решить, возникла новая проблема.

Уволился ИТ-директор одного из банков

А на его имя был изначально заключён основной договор — и он его курировал.

Надо было искать нового ответственного в структуре, «наследника» не было.

Вот здесь мы реально рисковали увязнуть на неопределённый срок.

Что я сделала

Сначала задолбала вообще всех вопросами. Задавала вопросы до тех пор, пока у всех сторон в согласованиях не начали дёргаться глаза. Я буквально ходила за людьми и следила, чтобы они нажали кнопку. Потом перешли к решениям.

По бюджету — не стали переделывать договор, а протащили допник с патчем. Дополнительное соглашение ходит по другому маршруту, и там пришло гораздо меньше согласователей. В допник добавили всего одно предложение, суть которого в том, что все вопросы, не урегулированные в основном тексте, стороны решают по обоюдному согласию. Это развязало нам руки. А в самом заказе мы пересчитали бюджет так, чтобы он покрывал услуги только до конца 2025 года. Бухгалтерия успокоилась. На согласование этой одной фразы с юристами с обеих сторон ушла всего неделя.

Кажется, многие договоры с крупняками так и подписываются — сначала рамка для комплаенса, потом допники для дела.

Проблему с уволившимся ИТ-директором решили через переговоры. Честно объяснили ситуацию: директора нет, нового ещё не наняли, ждать нельзя. И они пошли навстречу. Мы не стали ждать назначения, а просто переоформили заказ на руководителя более высокого ранга, который уже работал в банке. Это штатная процедура, но почему проблема вообще возникла — второй вопрос.

По всем вопросам ходили и объясняли, что будет, если проект провалится. Я не просто передавала запросы, а приходила к каждому и объясняла, зачем нам это нужно, что это даст пользователям, как это поможет банку. Людям нужно понимать выгоду, чтобы эффективно работать, а не просто следовать регламенту как роботы. Чтобы не утонуть в хаосе, я завела простую таблицу — единый реестр требований. В ней было чётко прописано: кто, что, когда и зачем требует, кто ответственный и какой статус у задачи. Мы проводили ежедневные короткие встречи-синки со всеми участниками из обоих банков. Цель была одна — снять блокеры, а не создать ещё один процесс ради процесса.

Вот примерно такую:

Пинговали лично. Когда документы загружены в ЭДО, их должны согласовать куча людей. Я лично писала каждому, чтобы убедиться, что они увидели. 

Но сообщения в стиле «Сроки горят, это плохо» — это детский сад.

Я писала конкретно: «Иван, добрый день! У нас сегодня дедлайн, пожалуйста, согласуйте заявку, отпишитесь, как нажмёте кнопку».

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

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

Постмортем

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

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

1. На старте собирать не только бизнес, но и риск-чемпионов, ДКБ и комплаенс. Лучше на старте заложить время и проговорить все потенциально скользкие моменты, чтобы по полгода не править договор. Лучше потерять 3 часа в начале, чем месяц потом, пускай сразу договорятся. Главное зафиксировать, до чего договорились. Зная слабые и возможные спорные места, уже понятно, что спрашивать и где будут зарубы.

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

3. Назначить ответственного, который будет «переводить» с языка бизнеса на язык юристов/ИБ и обратно. Например, вместо «Нам нужен доступ к LLM» формулировать «Для реализации функции X-ассистента нам требуется отправлять обезличенные текстовые запросы на внешний API-сервис Y. Вот схема потоков данных и описание мер по их защите».

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

5. Держать руку на пульсе процессов по договорам и взаимодействию с контрагентами, даже если напрямую обычно не участвую. Это поможет быстро отреагировать на форс-мажоры, если коллеги в отпуске/нет ответственного.

Да, бюрократия — это зло, без которого в больших финансовых структурах нельзя. Но можно использовать бюрократию себе во благо. Работать по схеме «кто нам мешает, тот нам поможет».

Сразу скажу, что проблемы такого рода возникают всегда, и они часть нормального процесса. Бюрократия  защищает от финансовых, репутационных и уголовных рисков. Юристы не из вредности проверяют каждую запятую. ДКБ не просто так был против внешней LLM — они боятся утечек данных, и их можно понять. Да, есть цена — снижение эффективности. Но это лучше, чем потом выплачивать миллиардные штрафы или сесть в тюрьму.