Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASAСкорость и качество работы с данными становятся одним из ключевых конкурентных преимуществ в финтехе, а бизнес все активнее ищет способы сократить путь от данных до отчетности, на основе которой принимаются решения. 26 мая 2026 года «Ассоциация ФинТех» объявила о запуске первого в России отраслевого портала технологического бенчмаркинга FAN — по заявлению разработчиков, сервис сокращает время подготовки такой отчетности в шесть раз. В интервью CNews ведущий специалист по разработке и масштабированию продуктово-ориентированных цифровых сервисов в финтехе Иван Жуков рассказал, почему ускорение отчетности не всегда означает более быстрые и правильные решения, какие элементы инженерной инфраструктуры делают данные пригодными для этого, и почему доверие к данным становится новым ограничителем скорости бизнеса.
03 Августа 2026 14:27 03 Авг 2026 14:27 |
Скорость и качество работы с данными становятся одним из ключевых конкурентных преимуществ в финтехе, а бизнес все активнее ищет способы сократить путь от данных до отчетности, на основе которой принимаются решения. 26 мая 2026 года «Ассоциация ФинТех» объявила о запуске первого в России отраслевого портала технологического бенчмаркинга FAN — по заявлению разработчиков, сервис сокращает время подготовки такой отчетности в шесть раз. В интервью CNews ведущий специалист по разработке и масштабированию продуктово-ориентированных цифровых сервисов в финтехе Иван Жуков рассказал, почему ускорение отчетности не всегда означает более быстрые и правильные решения, какие элементы инженерной инфраструктуры делают данные пригодными для этого, и почему доверие к данным становится новым ограничителем скорости бизнеса.
«Нужно определить, для каких решений используется отчетность»CNews: Сегодня многие компании говорят об ускорении подготовки отчетности за счет автоматизации. Например, портал FAN обещает ускорить ее в шесть раз. Но если бизнес не уверен в качестве этих данных, действительно ли ускоряется принятие решений?
Иван Жуков: Формулировку «сократить время подготовки отчета в шесть раз» я бы сначала уточнил. Подготовка отчетности — это целая цепочка действий, и далеко не все ее этапы можно ускорить за счет автоматизации.
Если задача новая и у нее еще нет конкретного заказчика, значительное время занимает исследовательская работа: нужно понять, какие данные доступны, какие зависимости в них существуют, какие показатели действительно имеют смысл и какие выводы из них можно сделать. Эту работу невозможно полностью заменить готовым инструментом или шаблоном.
Если заказчик уже есть, работа начинается со сбора требований. Обычно это интервью, опрос или формализованное письменное техническое задание. Нужно определить, для каких решений используется отчетность, какие метрики важны, как именно они должны рассчитываться и с какой детализацией предоставляться. После разработки идут проверка результатов, приемка и корректировки. Все это может занимать не меньше времени, чем само построение отчета.
Отдельный пласт работы — согласование самой логики данных: без этого можно быстро получить технически корректный отчет, который тем не менее не будет отвечать на реальный вопрос бизнеса.
Автоматизация действительно в разы сокращает техническую часть — сбор данных, расчет показателей, обновление отчетности. Но это не значит, что во столько же раз сокращается весь путь от бизнес-задачи до решения. Исследование, постановку задачи и согласование логики метрик по-прежнему делают аналитики и бизнес.
CNews: Как вы считаете, какие элементы инженерной инфраструктуры делают данные пригодными для обоснованных решений?
Иван Жуков: С технической стороны компании нужен понятный стек, подходящий под ее задачи, централизованное хранение и нормальный процесс доставки данных из разных систем. При этом важно понимать, какие системы являются источниками, как и с какой периодичностью данные обновляются, что происходит при сбоях и как быстро команда узнает, что какая-то загрузка не прошла или данные пришли не полностью. Иначе можно получить вполне убедительную цифру, которая на самом деле рассчитана на неполных или несинхронно обновившихся данных.
Отдельная задача — привести в порядок сами данные. В разных системах одни и те же клиенты или события могут называться по-разному, поэтому нужны единые справочники, идентификаторы, правила очистки и дедупликации. Централизованное хранилище само по себе эту проблему не решает — без такой работы оно просто соберет все противоречия в одном месте.
Если одна команда считает конверсию одним способом, а другая — другим, то проблема уже не в качестве пайплайна. Должны быть зафиксированы определения метрик, правила расчета и связи между ними — например, в виде дерева метрик. Такая документация необходима, чтобы логика не существовала только в голове конкретного аналитика и не менялась каждый раз вместе с командой.
Не менее важно понимать происхождение данных: откуда взялся показатель, какие преобразования прошел, кто отвечает за его логику. В крупных компаниях изменение одной системы может незаметно повлиять сразу на несколько аналитических продуктов, моделей или бизнес-процессов.
Когда все это выстроено, аналитики быстрее проверяют гипотезы, бизнес принимает решения на единой системе показателей, а модели строятся на стабильных данных. Для меня критерий зрелой инфраструктуры простой: данным должны доверять, а использовать их можно одинаково уверенно и для отчёта, и для модели, которая принимает решение в реальном процессе.
«Важно особо тщательно контролировать целостность движения данных между системами»CNews: Бывали ли в вашей практике случаи, когда итоговые метрики выглядели нормально, а проблема пряталась глубже — на уровне данных или их передачи между системами? Как ее в итоге находили?
Иван Жуков: Да, у меня был такой случай во время работы в крупном банке. После интеграции двух направлений — бизнеса и рисков — часть данных потерялась на уровне справочников. На верхнем уровне это долго не выглядело как очевидная техническая авария: системы продолжали работать, отчётность формировалась, основные показатели не сигнализировали о резком сбое.
Но для конкретного бизнес-процесса последствия оказались серьезными. Часть новых зарплатных клиентов выпадала из формирования предодобренных предложений по кредитам наличными. Банк уже привлек клиента и обладал нужными данными, но из-за ошибки при их сопоставлении не делал ему предложение.
Проблему удалось найти только когда начали прослеживать движение конкретных клиентов между системами и проверять, на каком этапе они перестают попадать в следующий бизнес-процесс. В итоге причина оказалась не в самой модели принятия решения и не в продукте, а гораздо ниже — в данных и справочной логике между системами.
Мы оценили финансовые потери, исправили справочную логику и восстановили передачу данных между системами. После этого поток нормализовался, а выпавшие клиенты вернулись в процесс формирования предложений.
Этот случай показал, что важно особо тщательно контролировать целостность движения данных между системами. Критичные процессы нужно уметь прослеживать по всей цепочке — от события в исходной системе до конкретного действия на его основе.
CNews: А обратная ситуация — когда правильно выстроенная логика данных позволяла увидеть возможность или риск раньше, чем это отразилось бы в стандартной отчетности?
Иван Жуков: Из более свежих примеров могу привести кейс из финтеха. Компания работала с большим числом внешних и внутренних источников сигналов, которые разные направления используют для монетизации. Исторически работа с ними была хаотичной: команды подключали источники независимо друг от друга, общей картины по компании не было.
При этом каждое направление смотрело на свои результаты в рамках собственного бизнеса, и на этом уровне могло выглядеть вполне неплохо. Например, конкретный источник показывал нормальную экономику и конверсию внутри одного направления. Но увидеть, что происходит с теми же данными в других частях бизнеса и как аудитории разных источников пересекаются между собой, было практически невозможно.
В какой-то момент мы построили внутренний сервис, который централизовал работу с этими источниками и одновременно стал интеграционной шиной между ними и системами компании. Появились единые и понятные описания источников, общий процесс их подключения и возможность анализировать данные уже не по отдельным направлениям, а на уровне всего бизнеса.
До этого существовала достаточно интуитивная гипотеза: наиболее ценными должны быть эксклюзивные данные, то есть аудитория, которая встречается только в одном источнике и не пересекается с другими. Казалось логичным, что такой источник дает бизнесу дополнительную аудиторию, которую невозможно получить другим способом.
Когда данные централизовали и посмотрели на результат целиком, картина оказалась обратной. Часть «эксклюзивных» сегментов, которые не выглядели проблемными локально, на уровне компании генерировала убытки. А пересечение между несколькими источниками, наоборот, оказалось более сильным признаком конверсии. Если похожий сигнал независимо появляется в нескольких источниках, доверия к нему больше. Эксклюзивность сама по себе ещё не означает качество — источник может быть единственным именно потому, что сигнал слабый.
По результатам анализа мы разработали бизнес-правила и встроили их в сервис поставки признаков. При обращении по API внутренние системы получают рассчитанный практически в реальном времени набор признаков, который используется в разных сценариях монетизации. Один из таких признаков учитывает свойства источников, их пересечения и применяется при выборе коммуникационной стратегии — то есть результат исследования не остался аналитическим наблюдением: он встроен в рабочий бизнес-процесс и позволяет не тратить деньги на коммуникации с сегментами, которые раньше могли считаться перспективными, но фактически показывали отрицательную экономику.
Поскольку источников и направлений монетизации много, единое правило работает сразу для нескольких бизнес-процессов. В результате удалось не только пересмотреть оценку источников, но и системно сократить неэффективные расходы на коммуникации.
Для меня этот кейс хорошо показывает ограничение локальной аналитики. Можно корректно оценивать источник внутри одного направления и не видеть его реальную экономику на уровне всей компании.
CNews: Если свести к сути — что на самом деле определяет способность компании быстро и надежно принимать решения на данных: скорость их обработки или качество и архитектура, через которую они проходят?
Иван Жуков: В финтехе скорость действительно имеет критическое значение. Рынок быстро меняется, компании работают с большими объемами данных, а многие решения нужно принимать практически в момент взаимодействия с клиентом. Поэтому скорость получения, обработки и использования данных напрямую влияет на бизнес-результат.
Но я бы не противопоставлял скорость качеству данных и архитектуре. Наоборот, скорость во многом является результатом того, насколько хорошо все это выстроено. Если данные разрознены между системами, их приходится долго собирать и сверять, одинаковые показатели рассчитываются по-разному, а для каждого нового исследования или бизнес-задачи значительную часть работы приходится делать заново — компания неизбежно будет принимать решения медленнее.
Хорошая архитектура сокращает этот путь. Когда данные централизованно собираются, их качество контролируется, метрики имеют единые определения, а бизнес-логика документирована и воспроизводима, компания быстрее проводит исследования, проверяет гипотезы и внедряет новые решения. Компания действительно работает быстро, когда она может без долгой ручной работы проверить новую гипотезу, изменить логику или встроить новое решение в бизнес-процесс.
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | ИИ-трансформация BPM-систем: что происходит в 2026 году | 0 | 5 | 06-07-2026 |
| 2 | FINNEXT-2026: ИИ пишет до 35% кода в крупнейших финтехах — и это только начало | 5 | 7 | 30-04-2026 |
| 3 | Договор с интеллектом: ИИ выходит на новый уровень в работе с документами | 5 | 7 | 30-06-2026 |
| 4 | Конференция CNews «Цифровые технологии в финансовом секторе» состоится 8 сентября 2026 года | 0 | 5 | 08-07-2026 |
| 5 | Конференция CNews «Цифровые технологии в финансовом секторе» состоится 8 сентября 2026 года | 0 | 3 | 08-07-2026 |
| 6 | Конференция CNews «Цифровые технологии в финансовом секторе» состоится 8 сентября 2026 года | 0 | 5 | 08-07-2026 |
| 7 | Ответственные за устойчивое | 0 | 5 | 06-10-2025 |
| 8 | Финтех по новым правилам. Опубликован новый выпуск видеоподкаста «CNews.Лица» | 0 | 5 | 08-07-2026 |
| 9 | В РФ четверть компаний не делает бэкапы данных | 0 | 0 | 15-04-2025 |