Как ИИ меняет нашу финансовую операционную модель

ИИ дал нам повод переосмыслить то, как организована наша финансовая команда.

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

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

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

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

Люди, ближе всего стоящие к работе, видят лучшие возможности

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

В финансовом отделе мы создали таким образом десятки инструментов.

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

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

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

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

Мы движемся к полной автоматизации

Автоматизация находится в определенном спектре:

• Панели мониторинга объединяют и визуализируют данные, которые раньше хранились в нескольких системах.

Панели мониторинга объединяют и визуализируют данные, которые раньше хранились в нескольких системах.

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

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

• Триггерные рабочие процессы запускаются самостоятельно — по расписанию или в ответ на бизнес-событие.

Триггерные рабочие процессы запускаются самостоятельно — по расписанию или в ответ на бизнес-событие.

• Сквозная автоматизация объединяет все через API, и единственным участием человека остается этап утверждения.

Сквозная автоматизация объединяет все через API, и единственным участием человека остается этап утверждения.

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

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

Нам понадобился финансовый инженер

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

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

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

Как мы строим работу сейчас

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

• Тщательно определите масштаб, потому что правильное выполнение этого шага сэкономит недели в будущем.

Тщательно определите масштаб, потому что правильное выполнение этого шага сэкономит недели в будущем.

• Создайте MVP за три-четыре недели с проверками дважды в неделю. Если дедлайн ускользает, мы сокращаем масштаб, но сохраняем дату.

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

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

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

• Выпустите, зафиксируйте, опубликуйте ссылку в одной общекомандной таблице и стимулируйте внедрение в наших глобальных командах.

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

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

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

Навыки, которые мы развиваем

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

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

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

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

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