«Дайте нам аналитику, — просит бизнес айтишников, — правда, мы глубоко в это погружаться не хотим, чётко сформулировать требования не можем и расчётам BI не очень-то доверяем».
Сюр?
Сюр. Но встречается на каждом шагу.
Вопрос решается с помощью Self-service, который даёт всем желающим возможность работать в базе данных на низком уровне. И он может удовлетворить как айтишников, с которых снимается уйма хлопот, так и бизнес-подразделения, которые теперь могут получать все необходимые расчёты ровно в том виде, который их полностью устраивает. То есть это отличный способ дать бизнесу возможность быстро находить ответы на свои вопросы.
Для начала определимся с термином BI. Обычно он обозначает инструменты визуализации данных, которые позволяют строить красивые графики и диаграммы. Мы же у себя в банке под этой аббревиатурой имеем в виду весь спектр компетенций по аналитике, включающий в себя как системы хранилища данных и BI-инструментов, так и всю обеспечивающую их ИТ-команду.
Меня зовут Павел Харламов, я начальник отдела разработки и сопровождения аналитических систем Хоум Банка. Я занимаюсь технической стороной всего, что связано с банковской аналитикой. Устраивайтесь поудобнее, сейчас расскажу, как мы делали Self-service, как он работает на практике, какие риски несёт, из чего состоит и что изменилось после 2022 года.
Когда я только пришёл работать в Хоум Банк в далёком тихом и спокойном 2014 году, у нас была классическая для того времени стандартная архитектура в области анализа данных: большое хранилище, а над ним — единственный BI-инструмент (конкретно — Oracle BI). Всё, что касалось визуальной части, — фильтры, отчёты, дашборды, выгрузки в Excel и так далее — разрабатывалось исключительно ИТ-специалистами. Львиную долю времени нужно было потратить на то, чтобы понять, а что, собственно говоря, требуется получить в конечном результате. У данных гораздо больше вариаций, чем это кажется на первый взгляд, поэтому задача могла лежать в технической разработке один-два месяца и только потом удавалось выйти на продуктив. Потом ещё какое-то время уходило на доработки, потому что внезапно обнаружились неучтённые мелочи. Потом задача докатывалась ещё три-шесть месяцев. Потом данные теряли наконец свою актуальность, потому что бизнес-процессы уже изменились, и приходилось начинать всё заново. Утрирую, конечно, но совсем чуть-чуть.
В общем, это всё было не слишком удобно, и со временем мы всё сильнее убеждались в мысли, что далеко не все задачи можно решить с помощью BI-инструмента. Всё чаще нам нужен был прямой доступ к данным в живом режиме.
То есть — Self-service. Я имею в виду не опцию какой-то отдельной платформы, а скорее общее свойство всего подхода к решению задач бизнес-аналитики, который даёт всем желающим возможность работать в базе данных на низком уровне.
Все части этой системы нужно перманентно дорабатывать, потому что возможности и процессы видоизменяются, но результат получается настолько крутым, что оправдывает все затраченные усилия.
Главная проблема бизнеса — разобраться, что где лежит и как это правильно оценить. На уровне базы данных это просто куча табличек. Да, они описаны. Да, есть комментарии. Да, примерно понятно, как их можно связать. Но собрать данные из сотен табличек в одну очень сложно. Поэтому мы делаем для них сборные, универсальные и подготовленные по чётким требованиям витрин данных. А дальше есть десятки подразделений, и каждое считает что-то своё в формате Self-service. Типовые задачи для BI — это множество мелких отчётов.
Бухгалтерия может посмотреть, сколько компания заработала за день.
Ребята, которые занимаются холодными звонками, — выводить в режиме реального времени на большой красивый дашборд, кем из сотрудников call-центра сколько и каких продуктов продано и сколько они получают отказов — вплоть до детализации по конкретным договорам.
Кадровики оценивают приток и отток персонала: сколько человек в каких подразделениях наняли на какие позиции и сколько они в среднем отработали.
Кредитный отдел может посчитать глубокую аналитику и сложную математику. Например, выяснить, на каком этапе отваливаются клиенты, по каким причинам и как выглядит воронка продаж. Или построить графики проникновения страховок в кредиты и посмотреть, как их количество менялось на протяжении последних пяти лет. Или узнать, сколько машин в месяц наши клиенты передают под залог, какого они возраста и какой марки.
А CRM через сервис проводит аналитику, необходимую для запуска рекламных кампаний и адресных предложений, рассчитывает пул и сегменты клиентов, вычисляет самых горячих из них. Чтобы эффективно запуститься, им нужно проанализировать огромное количество данных: какого клиент пола, когда он совершил последнюю операцию, когда заходил в банковский офис, а когда — заглядывал в приложение. Плюс к этому мы можем подкрутить информацию с внешних источников: скоринги, баллы, рассчитанные мобильными операторами, тематики, подгруженные из соцсетей, и так далее.
BI-инструменты, которые позволяют делать всякие красивые визуализации, — это только верхняя часть айсберга Self-service-аналитики. Под ней скрыт большой пласт прямой работы с данными в хранилище и тоже в парадигме Self-service.
То есть у бизнес-подразделений есть свои учётки прямо в БД, а ещё — пул ресурсов и достаточно широкий спектр полномочий для расчёта всех нужных показателей на низком уровне. Можно создавать свои таблицы, настраивать регулярные джобы, выстраивать собственные правила разработки, загружая любые данные из «ядра» хранилища, а также от соседних подразделений. И все эти расчёты работают в рамках одной общей БД с основной частью хранилища, обеспечивая максимальное быстродействие. Выгружаются в основном уже аккумулированные данные или отдельные срезы, поэтому вся эта зона занимает всего 5% места от общего объёма дисков. Но сами вычисления достаточно сложные, поэтому львиная доля процессорных мощностей (до 60%) уходит именно сюда.
NB для сведущих. Тут под «ядром» мы подразумеваем не какое-то классическое определение Core Data Layer, а в целом всё, что рассчитывается силами ИТ-команд на ежедневной основе. Классического ядра в нашем хранилище нет.
Ядро занимает остальные 95% места (а это суммарно 100+ Тб), его формирование и обеспечение стабильности и качества — как раз работа айтишников. Сюда загружаются данные из всех систем: продуктовых, операционных, внешних и так далее. Начиная с ПО, которым на рабочих местах пользуются операционисты, и заканчивая, к примеру, кредитными бюро или реестром недействительных паспортов от МВД. И нам нужно всё это правильно дотащить в хранилище или корректно рассчитать каждый атрибут. Тут мы берём на себя все вопросы, связанные с правильной интеграцией с системами-источниками, оперативные доработки из-за как всегда неожиданных изменений структур и, конечно, вопросы правильного проектирования модели и нормализации хранимых данных.
Мы занимаемся исходными базовыми вещами и признаками, с которыми работают просто все (к примеру, табличками с договорами, ставка по которым нужна всем, или карточными транзакциями), отвечаем за их расчёт и стабильную ежедневную работу с поддержкой в режиме 24/7. Мы запускаем расчёт базовых данных на ночь и каждое утро выдаём готовые витрины данных, а дальше бизнес-пользователи растаскивают их по своим «песочницам» и досчитывают всё, что им надо, так, как они хотят. ИТ тут вообще не нужен, и всё можно сделать самостоятельно после небольшого обучения на YouTube.
Чтобы кто-нибудь неловкий не положил кривым запросом всю систему, где, например, считаются данные по бухгалтерии, мы даём бизнес-пользователям весьма ограниченный набор команд и скромные доступы. В закрытые фронтальные системы почти никто залезть не может, и все работают во внешнем хранилище. Например, у нас в одной табличке собран процесс взыскания, в другой — методы, в третьей — исковые заявления. А чтобы свести всё воедино, нужно написать код. И такой подход позволяет бизнесу очень быстро получить ответы на свои вопросы, не тратя ресурс разработчиков.
Пользовательские задачи мы обычно вообще не трогаем — если только нас не попросят протащить, например, недостающий признак или готовую выборку из какого-нибудь процессинга. Обычно это происходит, когда для работы ребятам нужен специфический столбец, которому не хватает волшебной галочки над какой-нибудь транзакцией.
В ИТ-команду входит около сорока человек — это разработчики, системные аналитики (зачастую закрывающие и вопросы бизнес-анализа), тестировщики, сопровожденцы и т.д. В самой же базе, где требуются определённые технические скилы, у нас работает почти три сотни человек из разных отделов. Все они реально пишут большие и тяжёлые запросы. Уровень скилов, конечно, варьируется от «мне сосед скинул скрипт, я запускаю его раз в неделю, потому что сам не умею в SQL» до «я вчера написал огромную простыню, но помогите немного план подправить». Каждый пятый руководитель из немассовых подразделений сам работает в БД и умеет писать процедуры. Да и вообще у нас в банке сейчас почти все хорошие аналитики по рискам, специалисты по CRM, финансам или, например, взысканию, умеют делать хотя бы простые базовые вещи в SQL или Python.
Среди наших пользователей есть представители всех банковских блоков и более чем 50 различных управлений: от юристов и безопасников до узконаправленных разработчиков моделей одобрения. При этом подход к работе в БД не привязан к оргструктуре или конкретным личным учёткам. На каждый пул активностей может выделяться отдельная «песочница». Она привязана в первую очередь к бизнес-активностям, а работать в ней могут сотрудники абсолютно разных подразделений. Кроме того, один человек может работать в нескольких «песочницах» сразу. Если же кто-нибудь из сотрудников уволится, личная учётная запись схлопнется, а весь разработанный им функционал останется и остальные соседи по «песочнице» смогут спокойно продолжить допиливать его.
Мы сейчас разделены на Agile-команды, в которых есть разработчики, аналитики и бизнес. Разработчики выдают задачи, сопровождение ставит на продуктив 2–3 раза в неделю, а команда платформы, не погружаясь в конкретные бизнес-задачи, отвечает за то, чтобы всё работало, единые стандарты соблюдались, у всех были нужные доступы, а ошибки и инциденты исправлялись вовремя.
Эта же команда занимается поддержкой, постоянно отвечает на вопросы из серии «почему всё тормозит», «куда пропали данные» и «где находится такая нужная кнопочка». Часть из этих вопросов мы разбираем сами, часть — отправляем в бизнесовые команды, часть — аналитикам.
Первое, что нужно для жизни системы, — это доступы и безопасность. У всех бизнес-подразделений есть свободный доступ ко всем основным витринам сразу. При этом мы не используем для этого AD-авторизацию, то есть классические оракловые учётки, поэтому отдельно очень важно отслеживать блокировку аккаунтов при увольнении сотрудников. Аудиторы этот вопрос очень любят задавать. Чтобы дать такие широкие доступы, нужно очень тщательно замаскировать клиентские данные, PCI DSS и так далее. Для этого нам пришлось полностью перепрофилировать все атрибуты в ядре. Мы разметили их на «персональные данные» и «всё остальное». Кстати благодаря тому, что у нас уже есть полный профиль персональных данных, мы достаточно стандартными операциями можем тиражировать тестовые среды, гарантируя их абсолютную безопасность с точки зрения информации ограниченного доступа.
Второй важный момент — чтобы все эти ребята сумели посчитать всё, что им нужно, но при этом не положили систему, нужно правильно распределить ресурсы железа. Алгоритмы, которые могут динамически выделять их под конкретные запросы, работают не так хорошо, как хотелось бы. Искусственный интеллект, который умеет отличать сложные и осмысленные запросы от кривых и генерирующих бессмысленные терабайты информации, пока не придумали. Поэтому мы просто ввели жёсткое квотирование лимитов сессии, процессорных ресурсов, операций ввода/вывода и дискового пространства. Не всем это нравится, но зато у нас система работает.
Третье — без команды по сопровождению работать ничего не будет. Мы регулярно консультируем пользователей по техническим моментам, рекомендуем лучшие способы работы с теми или иными витринами. Даже собрали специальную мини-презентацию о том, как писать запросы, чтобы они выполнялись наиболее эффективно. Ведём проактивную работу, в том числе делая рефакторинг внутри кода в разных подразделениях. Ходим по отделам и спрашиваем, нужна ли помощь (а заодно проверяем, у кого запущены наиболее тяжёлые процессы).
Сами бизнес-подразделения тоже периодически приходят к нам с вопросами. Зачастую все их проблемы можно решить в два-три хинта. Например, если не хватило ресурсов, можно переписать запрос или разобраться, почему какой-то атрибут считается неправильно. Впрочем, база у нас довольно мощная, так что поток таких жалоб не велик: в большинстве случаев всё работает за счёт железа, даже если в запросе есть косяки с точки зрения производительности.
При таких объёмах нам не хватит рук, чтобы наблюдать за всеми, поэтому четвёртый важный пункт — это Self-service-мониторинг. Сейчас мы реализовали на APEХе приложение для всех пользователей, чтобы они могли залезть в свою «песочницу» и посмотреть:
Всю эту систему мы регулярно дорабатываем и наращиваем её функционал, выводим туда информацию по конкретным витринам, по времени их готовности, по спискам сотрудников в каждой «песочнице» и т.д.
И ещё очень важны джентльменские соглашения. У нас их два.
В первую очередь нужны два основных ингредиента.
В каждом департаменте ребята самостоятельно решают вопрос с кадрами, процесс приёма на работу давно выстроен. В основном набирают кандидатов, у которых уже есть предварительное понимание, как и с чем им придётся работать в техническом плане. Но и будем откровенны — в области анализа данных сейчас сложно встретить резюме без базовых знаний SQL и/или Python.
Но с погружением мы, конечно, помогаем. У нас есть большая красивая инструкция, в которой разобраны самые частые проблемы. Начиная с того, как зайти в систему, получить или поменять пароль и написать запрос в хранилище, и заканчивая инструкцией о том, что делать, если вон та штука не работает, и к кому с каким вопросом можно подходить. А если ребята начинают до неприятного часто жаловаться на неработающие запросы, мы переделываем инструкцию и проводим дополнительное обучение.
А перед тем, как дать доступ к системе, проводим тестирование. Первый тест — на умение писать SQL-запросы, а второй — на знание самой системы по той самой инструкции. Всего в тесте около тридцати вопросов, на 90% из которых придётся ответить правильно. И наша команда постоянно занимается доработкой, постоянно что-то оптимизирует, рефакторит и в целом ускоряет то, что написал бизнес.
Чтобы всё хорошо работало в таком формате, нужна очень опытная команда сопровождения. Я не могу поставить на поддержку новичка: чтобы помогать другим, нужно самому знать систему в идеале. Самый молодой мой сотрудник из Support работает здесь уже почти шесть лет.
Поначалу мы работали исключительно на Oracle BI, купленном ещё когда мы были частью чешской группы. За визуализациями тогда все приходили к ИТ-специалистам. Хранилище использовалось как единственный источник данных, и всё, что нужно было посчитать, протаскивалось через него. Но постепенно мы поняли, что эта система работает всё хуже, нам её категорически не хватает, и начали её видоизменять.
Постепенно мы выделили в хранилище эдакие «песочницы» для разных задач, то есть внутри единой большой базы данных — собственный ресурс для самых технически продвинутых подразделений (а это риски, CRM, финансы, антифрод и т.д.). Используя витрины из «ядра», можно было решать собственные задачи, создавать объекты, писать процедуры, вешать их на джобы и т.д. Теперь логика их расчётов могла изменяться хоть по несколько раз на дню, и это круто, потому что классическая разработка через ИТ-команду такого обеспечить не могла.
В общем, у нас был Oralce BI для отчётов и визуализаций и ядро DWH для подобных строго формализованных задач, но полноценного BI-инструмента ещё не было, а всё, что требовало какой-либо гибкости, решалось непосредственно в БД. Затем технически продвинутые товарищи начали даже писать вспомогательные инструменты самостоятельно — вплоть до десктопных и веб-приложений на С# и Java — лишь бы это помогло при интерактивной работе с БД и визуализации каких-то данных. Свои собственные опенсорс-решения они прикручивали везде, куда могли дотянуться, и плохо просматриваемая область вокруг хранилища росла.
Всю эту деятельность нужно было аккуратненько завернуть в правильное, а главное, безопасное русло. В идеале — разгрузив ИТ, чтобы он занимался только выдачей лицензий и проверкой доступов, а все остальные расчёты ребята из бизнес-направлений делали сами. Тем более что ландшафт постоянно усложнялся, количество источников данных росло и появлялись микросервисы, данные из которых хотелось не протаскивать в хранилище, а визуализировать и анализировать напрямую. Это не считая развивающиеся Big Data-кластер или OLAP-кубы, которыми у нас полностью занимались ребята из финансов.
Сделать это можно было с помощью нормального BI, который будет работать в режиме Self-service. Так к Oracle BI у нас добавился Tableau. А после перехода на 365-й офис — ещё и облачный Power BI. Всё вместе это составило некую экосистему, в которой можно было решать практически любую задачу по аналитике данных самыми разными способами.
На пике, к концу 2021 года, уже около сотни человек, не связанных с ИТ, занимались профессиональной разработкой в системах Tableau и Power BI. Около четырёхсот пользовались дашбордами. И это не считая общедоступных дашбордов, не требующих отдельных лицензий, которые в Power BI массовые подразделения использовали почти поголовно.
А потом наступил 2022 год, и западные вендоры ушли с рынка.
Само хранилище (а оно является источником процентов для 70% BI-дашбордов) размещено в Oracle, и там всё очень интересно с лицензиями. Он вроде бы ушёл, но продолжает работать: контракты проданы и резко выключить систему просто невозможно. Впрочем, года четыре назад Oracle затормозил развитие собственного продукта, и ничего кардинально нового в нём давно уже не происходило, так что никаких негативных последствий от отсутствия обновлений мы пока не ощутили. Конечно, подобные сложные системы, со временем просто обязаны начать разлагаться, глючить и требовать костылей, так что искать замену рано или поздно всё равно придётся. Но не сейчас. Регуляторные задвижки постоянно изменяются, на рынке огромная турбулентность, а чтобы перетащить нашу систему на Postgres или Greenplum, нужно сначала полностью сломать весь формат работы, а потом выстроить его с нуля. На это уйдёт несколько лет и очень много денег. И есть риск растерять команды, которым эти новшества могут не понравиться. К тому же сейчас не самый лучший момент для любых переходов, потому что и бизнес, и требования ЦБ находятся в активных изменениях. Ну и ещё наш банк попал под санкции и у нас только что сильно поменялись продукты и руководство.
В общем, потрясений для нас пока достаточно, продолжаем работать на Oracle и даже запускаем на нём новые системы. Вернёмся к вопросу, когда ситуация стабилизируется и выстроятся новые процессы.
Но если с Oracle и в части БД и в части BI всё пока более-менее стабильно, то Power BI мы окончательно потеряли осенью 2022, а Tableau — летом 2023 года.
Ещё летом 2022 года мы пошли смотреть опенсорс и окунулись в рынок российского BI — там сейчас происходит очень много интересного. В кулуарах ходят захватывающие истории о том, кто, как и через кого доставал какие системы от западных лидеров рынка. Мы покопались в этой информации пару-тройку недель и поняли для себя, что не хотим играть в лотерею «купим — не купим», «продлим — не продлим», а вкладывать большие собственные ресурсы в доработку этих систем — не можем.
Дальше мы пошли смотреть, что рынок предлагает официально, и выяснилось, что у PIX BI, Visiology, Luxms, FineBI и всех прочих инструментов BI, как новых российских, так и тех, что исходят из зарубежных ядерных систем, есть одна большая проблема — все они пока сыроваты и кривоваты. В одной не хватает функционала, другая — время от времени глючит и считает неправильно. Из множества зол предстояло выбрать наиболее удобное.
Так как весь BI у нас построен в формате Self-service и ключевая экспертиза в руках бизнес-подразделений, мы собрали фокус-группу из самых инициативных ребят, которые были готовы составлять требования и пилотировать разные системы. Пару месяцев мы вместе с ними яростно экспериментировали и пришли к выводу, что в первую очередь нужен такой Self-service, который позволит сохранить уже выстроенный и привычный формат работы. То есть такой, в котором визуальная часть полностью на совести бизнеса и айтишники туда вообще не заглядывают. Иначе мы убили бы очень-очень много времени, чтобы своими ручками перенести эти тысячи дашбордов и отчётов, которые раньше лежали в Tableau и Power BI.
Дальше мы пошли смотреть демо, и оказалось, что системы, которые могут позволить такой уровень сервиса из коробки, можно пересчитать по пальцам одной руки. Пару месяцев мы проводили тендеры и в финале выбирали из двух кандидатов. В итоге остановились на «Дельте BI».
Она тоже не без греха, продукт только-только запускался на нашем рынке, и мы её поначалу тоже довольно долго пытались стабилизировать. Но в мае 2023 вышло очередное обновление, в котором пофиксили все основные ошибки, и всё стало весьма неплохо. Но самое главное, в неё уже заложены все необходимые нам функции, а качество с каждой новой версией становится лучше.
К началу лета 2023 мы её внедрили. А теперь активно подгоняем бизнес-пользователей, чтобы они поскорее переносили туда весь свой функционал из Tableau и Power BI.
Если для Tableau и Power BI специалистов на рынке было много, да и обучающих курсов на YouTube — полно, то в начале пути для «Дельты» всего этого пока примерно ноль. Система новая и довольно непонятная, к ней нужно привыкать. И хотя база видеоуроков на канале вендора постепенно наполняется, без глубокого погружения не обойтись. Понимая это, ребята из «Дельты» провели для десяти наших ключевых пользователей большое и сложное шестнадцатичасовое обучение.
Правда, в системе у нас сейчас работает около восьмидесяти человек и выбить два полных рабочих дня, чтобы они бросили все свои дела и пошли учиться, пока не получится — это очень дорого для компании. Поэтому мы сделали на внутреннем портале собственный курс на базе учебных материалов «Дельты», чтобы каждый сотрудник банка мог разобраться, как работать в этой системе, по ходу дела. Большое спасибо за это нашей сервис-деск-команде.
Мы учим не только «Дельте», но и работе в самом хранилище. Потому что знание SQL — это, конечно, хорошо, но знание конкретной архитектуры конкретной базы данных тоже необходимо.
А чтобы защититься от лишних косяков, мы сделали специальный тест на тридцать вопросов и поставили условие, что в систему можно попасть только, когда он будет пройден. За восемь месяцев сдали тест и получили доступ уже сто тридцать семь человек.
Со временем мы столкнулись с тем, что, когда бизнес-подразделения долгое время работают в режиме самоуправства, данные начинают расползаться. Так что, ради их безопасности, политику нужно выстраивать достаточно жёсткую. К тому же разночтения по некоторым показателям могут привести к совершенно конкретному взрыву мозга: возникает множество версий, которые не всегда бьются между собой.
Самые важные правила, которые мы выделили, таковы:
А ещё очень важно помнить, что регуляторы пристально следят за рисками в финансовых организациях. И в том числе за тем, как работает каждая ИТ-система. Они сильно погружаются в нашу работу, и это требует выстраивания процессов в организации на более жёстком уровне. А это неизменно повлияет на всю аналитику и качество данных, а также решений, которые на их основе принимаются.
То есть нам нужно дать широкому количеству бизнес-подразделений возможность решать вопросы с привлечением минимального количества людей. В идеале — вообще без привлечения, исключительно силами руководителей: на этапе передачи формулировки задачи по цепочке, какая-то часть её сути всегда теряется, а реализация аналитической задачи должна быть максимально близка к той мысли, которая эту задачу породила. Сам залез, сам сделал, а если понял, что был неправ, сам же и пересчитал всё заново.
Но ребятам из бизнеса довольно сложно самостоятельно следить за всеми расчётами и корректировать их под какие-то изменения и случайности. Банально — пришёл новичок, накосячил, и всё упало. Упс, придётся поднимать. Их ресурсы ограниченные, далеко не дешёвые и вообще должны расходоваться на другие задачи.
А значит, нужно, с одной стороны, выравнивать единую версию правды, а с другой — в ряде направлений от Self-service отказаться.
Для этого нужно грамотно разделить все процессы, забрать условное ядро — то есть тяжёлые и общеиспользуемые признаки и некоторые процессы — в сторону ИТ, а на откуп бизнес-подразделениям оставить только самое гибкое, экспериментальное и прототипное. Некоторые процессы, например, могут корректироваться по несколько раз в день, и отдавать их айтишникам просто нецелесообразно.
Это на самом деле очень тонкий вопрос, потому что система может работать только при условии глубокой проработки политики работы с информацией. Нужно правильно выстроить и сопоставить бизнес-процессы с данными, которые ими порождаются, а потом разобраться, что куда передаётся, как и где считается. И только когда всё уже видно и прозрачно, можно делать сепарацию.
Это дорогостоящая история, которая подразумевает сильную переработку всего процесса. Такую жёсткую политику с точки зрения управления данными наш банк уже начинал проводить в 2021 году (когда мы были частью группы, нам её приносили чехи), но закончить, к сожалению, не успел. На время мы от этой тактики отошли, потому что в турбулентные времена было немного не до неё, но в 2024 году мы к этому вопросу возвращаемся. А начать планируем с департаментов архитектуры и рисков.
Если всякие финтехи и прочие продвинутые компании довольно гибкие ребята, то компании, которые сильнее связаны с материальным миром, более консервативны, когда речь идёт про аналитику и отчётность. Им обычно очень не хочется в них лезть, а хочется, чтобы ИТ сделал всё быстро и хорошо. Поэтому в первую очередь советую найти единомышленников среди бизнеса и руководства, то есть тех людей, которые будут проводниками этой идеи в массы. А во-вторых, перед тем как начинать переход, нужно создать качественную методологическую основу и подготовиться обучать людей.
Подготовить базу и поставить человека, которому это интересно.
Самые главные умения, которым нужно обучать людей, — это базовый SQL и работа с системой. Нужны хотя бы элементарные уроки, видео и тесты, по результату которых можно будет допускать людей к работе с системой. То есть нужно, чтобы у каждого пользователя была под рукой вся нужная информация и он понимал, к кому обратиться по тому или иному вопросу.
И, когда у первых энтузиастов всё получится, можно будет этот позитивный пример дальше «продавать» внутри своей организации.
Сюр?
Сюр. Но встречается на каждом шагу.
Вопрос решается с помощью Self-service, который даёт всем желающим возможность работать в базе данных на низком уровне. И он может удовлетворить как айтишников, с которых снимается уйма хлопот, так и бизнес-подразделения, которые теперь могут получать все необходимые расчёты ровно в том виде, который их полностью устраивает. То есть это отличный способ дать бизнесу возможность быстро находить ответы на свои вопросы.
Для начала определимся с термином BI. Обычно он обозначает инструменты визуализации данных, которые позволяют строить красивые графики и диаграммы. Мы же у себя в банке под этой аббревиатурой имеем в виду весь спектр компетенций по аналитике, включающий в себя как системы хранилища данных и BI-инструментов, так и всю обеспечивающую их ИТ-команду.
Меня зовут Павел Харламов, я начальник отдела разработки и сопровождения аналитических систем Хоум Банка. Я занимаюсь технической стороной всего, что связано с банковской аналитикой. Устраивайтесь поудобнее, сейчас расскажу, как мы делали Self-service, как он работает на практике, какие риски несёт, из чего состоит и что изменилось после 2022 года.
Когда я только пришёл работать в Хоум Банк в далёком тихом и спокойном 2014 году, у нас была классическая для того времени стандартная архитектура в области анализа данных: большое хранилище, а над ним — единственный BI-инструмент (конкретно — Oracle BI). Всё, что касалось визуальной части, — фильтры, отчёты, дашборды, выгрузки в Excel и так далее — разрабатывалось исключительно ИТ-специалистами. Львиную долю времени нужно было потратить на то, чтобы понять, а что, собственно говоря, требуется получить в конечном результате. У данных гораздо больше вариаций, чем это кажется на первый взгляд, поэтому задача могла лежать в технической разработке один-два месяца и только потом удавалось выйти на продуктив. Потом ещё какое-то время уходило на доработки, потому что внезапно обнаружились неучтённые мелочи. Потом задача докатывалась ещё три-шесть месяцев. Потом данные теряли наконец свою актуальность, потому что бизнес-процессы уже изменились, и приходилось начинать всё заново. Утрирую, конечно, но совсем чуть-чуть.
В общем, это всё было не слишком удобно, и со временем мы всё сильнее убеждались в мысли, что далеко не все задачи можно решить с помощью BI-инструмента. Всё чаще нам нужен был прямой доступ к данным в живом режиме.
То есть — Self-service. Я имею в виду не опцию какой-то отдельной платформы, а скорее общее свойство всего подхода к решению задач бизнес-аналитики, который даёт всем желающим возможность работать в базе данных на низком уровне.
Все части этой системы нужно перманентно дорабатывать, потому что возможности и процессы видоизменяются, но результат получается настолько крутым, что оправдывает все затраченные усилия.
Типовые задачи, которые мы решаем с помощью BI
Главная проблема бизнеса — разобраться, что где лежит и как это правильно оценить. На уровне базы данных это просто куча табличек. Да, они описаны. Да, есть комментарии. Да, примерно понятно, как их можно связать. Но собрать данные из сотен табличек в одну очень сложно. Поэтому мы делаем для них сборные, универсальные и подготовленные по чётким требованиям витрин данных. А дальше есть десятки подразделений, и каждое считает что-то своё в формате Self-service. Типовые задачи для BI — это множество мелких отчётов.
Бухгалтерия может посмотреть, сколько компания заработала за день.
Ребята, которые занимаются холодными звонками, — выводить в режиме реального времени на большой красивый дашборд, кем из сотрудников call-центра сколько и каких продуктов продано и сколько они получают отказов — вплоть до детализации по конкретным договорам.
Кадровики оценивают приток и отток персонала: сколько человек в каких подразделениях наняли на какие позиции и сколько они в среднем отработали.
Кредитный отдел может посчитать глубокую аналитику и сложную математику. Например, выяснить, на каком этапе отваливаются клиенты, по каким причинам и как выглядит воронка продаж. Или построить графики проникновения страховок в кредиты и посмотреть, как их количество менялось на протяжении последних пяти лет. Или узнать, сколько машин в месяц наши клиенты передают под залог, какого они возраста и какой марки.
А CRM через сервис проводит аналитику, необходимую для запуска рекламных кампаний и адресных предложений, рассчитывает пул и сегменты клиентов, вычисляет самых горячих из них. Чтобы эффективно запуститься, им нужно проанализировать огромное количество данных: какого клиент пола, когда он совершил последнюю операцию, когда заходил в банковский офис, а когда — заглядывал в приложение. Плюс к этому мы можем подкрутить информацию с внешних источников: скоринги, баллы, рассчитанные мобильными операторами, тематики, подгруженные из соцсетей, и так далее.
Как выглядит эта система
BI-инструменты, которые позволяют делать всякие красивые визуализации, — это только верхняя часть айсберга Self-service-аналитики. Под ней скрыт большой пласт прямой работы с данными в хранилище и тоже в парадигме Self-service.
То есть у бизнес-подразделений есть свои учётки прямо в БД, а ещё — пул ресурсов и достаточно широкий спектр полномочий для расчёта всех нужных показателей на низком уровне. Можно создавать свои таблицы, настраивать регулярные джобы, выстраивать собственные правила разработки, загружая любые данные из «ядра» хранилища, а также от соседних подразделений. И все эти расчёты работают в рамках одной общей БД с основной частью хранилища, обеспечивая максимальное быстродействие. Выгружаются в основном уже аккумулированные данные или отдельные срезы, поэтому вся эта зона занимает всего 5% места от общего объёма дисков. Но сами вычисления достаточно сложные, поэтому львиная доля процессорных мощностей (до 60%) уходит именно сюда.
NB для сведущих. Тут под «ядром» мы подразумеваем не какое-то классическое определение Core Data Layer, а в целом всё, что рассчитывается силами ИТ-команд на ежедневной основе. Классического ядра в нашем хранилище нет.
Ядро занимает остальные 95% места (а это суммарно 100+ Тб), его формирование и обеспечение стабильности и качества — как раз работа айтишников. Сюда загружаются данные из всех систем: продуктовых, операционных, внешних и так далее. Начиная с ПО, которым на рабочих местах пользуются операционисты, и заканчивая, к примеру, кредитными бюро или реестром недействительных паспортов от МВД. И нам нужно всё это правильно дотащить в хранилище или корректно рассчитать каждый атрибут. Тут мы берём на себя все вопросы, связанные с правильной интеграцией с системами-источниками, оперативные доработки из-за как всегда неожиданных изменений структур и, конечно, вопросы правильного проектирования модели и нормализации хранимых данных.
Мы занимаемся исходными базовыми вещами и признаками, с которыми работают просто все (к примеру, табличками с договорами, ставка по которым нужна всем, или карточными транзакциями), отвечаем за их расчёт и стабильную ежедневную работу с поддержкой в режиме 24/7. Мы запускаем расчёт базовых данных на ночь и каждое утро выдаём готовые витрины данных, а дальше бизнес-пользователи растаскивают их по своим «песочницам» и досчитывают всё, что им надо, так, как они хотят. ИТ тут вообще не нужен, и всё можно сделать самостоятельно после небольшого обучения на YouTube.
Чтобы кто-нибудь неловкий не положил кривым запросом всю систему, где, например, считаются данные по бухгалтерии, мы даём бизнес-пользователям весьма ограниченный набор команд и скромные доступы. В закрытые фронтальные системы почти никто залезть не может, и все работают во внешнем хранилище. Например, у нас в одной табличке собран процесс взыскания, в другой — методы, в третьей — исковые заявления. А чтобы свести всё воедино, нужно написать код. И такой подход позволяет бизнесу очень быстро получить ответы на свои вопросы, не тратя ресурс разработчиков.
Пользовательские задачи мы обычно вообще не трогаем — если только нас не попросят протащить, например, недостающий признак или готовую выборку из какого-нибудь процессинга. Обычно это происходит, когда для работы ребятам нужен специфический столбец, которому не хватает волшебной галочки над какой-нибудь транзакцией.
В ИТ-команду входит около сорока человек — это разработчики, системные аналитики (зачастую закрывающие и вопросы бизнес-анализа), тестировщики, сопровожденцы и т.д. В самой же базе, где требуются определённые технические скилы, у нас работает почти три сотни человек из разных отделов. Все они реально пишут большие и тяжёлые запросы. Уровень скилов, конечно, варьируется от «мне сосед скинул скрипт, я запускаю его раз в неделю, потому что сам не умею в SQL» до «я вчера написал огромную простыню, но помогите немного план подправить». Каждый пятый руководитель из немассовых подразделений сам работает в БД и умеет писать процедуры. Да и вообще у нас в банке сейчас почти все хорошие аналитики по рискам, специалисты по CRM, финансам или, например, взысканию, умеют делать хотя бы простые базовые вещи в SQL или Python.
Среди наших пользователей есть представители всех банковских блоков и более чем 50 различных управлений: от юристов и безопасников до узконаправленных разработчиков моделей одобрения. При этом подход к работе в БД не привязан к оргструктуре или конкретным личным учёткам. На каждый пул активностей может выделяться отдельная «песочница». Она привязана в первую очередь к бизнес-активностям, а работать в ней могут сотрудники абсолютно разных подразделений. Кроме того, один человек может работать в нескольких «песочницах» сразу. Если же кто-нибудь из сотрудников уволится, личная учётная запись схлопнется, а весь разработанный им функционал останется и остальные соседи по «песочнице» смогут спокойно продолжить допиливать его.
Мы сейчас разделены на Agile-команды, в которых есть разработчики, аналитики и бизнес. Разработчики выдают задачи, сопровождение ставит на продуктив 2–3 раза в неделю, а команда платформы, не погружаясь в конкретные бизнес-задачи, отвечает за то, чтобы всё работало, единые стандарты соблюдались, у всех были нужные доступы, а ошибки и инциденты исправлялись вовремя.
Эта же команда занимается поддержкой, постоянно отвечает на вопросы из серии «почему всё тормозит», «куда пропали данные» и «где находится такая нужная кнопочка». Часть из этих вопросов мы разбираем сами, часть — отправляем в бизнесовые команды, часть — аналитикам.
Что нужно сделать, чтобы всё заработало
Первое, что нужно для жизни системы, — это доступы и безопасность. У всех бизнес-подразделений есть свободный доступ ко всем основным витринам сразу. При этом мы не используем для этого AD-авторизацию, то есть классические оракловые учётки, поэтому отдельно очень важно отслеживать блокировку аккаунтов при увольнении сотрудников. Аудиторы этот вопрос очень любят задавать. Чтобы дать такие широкие доступы, нужно очень тщательно замаскировать клиентские данные, PCI DSS и так далее. Для этого нам пришлось полностью перепрофилировать все атрибуты в ядре. Мы разметили их на «персональные данные» и «всё остальное». Кстати благодаря тому, что у нас уже есть полный профиль персональных данных, мы достаточно стандартными операциями можем тиражировать тестовые среды, гарантируя их абсолютную безопасность с точки зрения информации ограниченного доступа.
Второй важный момент — чтобы все эти ребята сумели посчитать всё, что им нужно, но при этом не положили систему, нужно правильно распределить ресурсы железа. Алгоритмы, которые могут динамически выделять их под конкретные запросы, работают не так хорошо, как хотелось бы. Искусственный интеллект, который умеет отличать сложные и осмысленные запросы от кривых и генерирующих бессмысленные терабайты информации, пока не придумали. Поэтому мы просто ввели жёсткое квотирование лимитов сессии, процессорных ресурсов, операций ввода/вывода и дискового пространства. Не всем это нравится, но зато у нас система работает.
Третье — без команды по сопровождению работать ничего не будет. Мы регулярно консультируем пользователей по техническим моментам, рекомендуем лучшие способы работы с теми или иными витринами. Даже собрали специальную мини-презентацию о том, как писать запросы, чтобы они выполнялись наиболее эффективно. Ведём проактивную работу, в том числе делая рефакторинг внутри кода в разных подразделениях. Ходим по отделам и спрашиваем, нужна ли помощь (а заодно проверяем, у кого запущены наиболее тяжёлые процессы).
Сами бизнес-подразделения тоже периодически приходят к нам с вопросами. Зачастую все их проблемы можно решить в два-три хинта. Например, если не хватило ресурсов, можно переписать запрос или разобраться, почему какой-то атрибут считается неправильно. Впрочем, база у нас довольно мощная, так что поток таких жалоб не велик: в большинстве случаев всё работает за счёт железа, даже если в запросе есть косяки с точки зрения производительности.
При таких объёмах нам не хватит рук, чтобы наблюдать за всеми, поэтому четвёртый важный пункт — это Self-service-мониторинг. Сейчас мы реализовали на APEХе приложение для всех пользователей, чтобы они могли залезть в свою «песочницу» и посмотреть:
- какие объекты там хранятся;
- сколько они места занимают;
- какие самые тяжёлые запросы есть прямо сейчас (и срубить их, если необходимо, даже если это запрос соседа);
- у кого из сотрудников есть доступ к базе;
- сколько открыто сессий и какую мощность процессора они используют;
- посмотреть планы запросов.
Всю эту систему мы регулярно дорабатываем и наращиваем её функционал, выводим туда информацию по конкретным витринам, по времени их готовности, по спискам сотрудников в каждой «песочнице» и т.д.
И ещё очень важны джентльменские соглашения. У нас их два.
- Наличие большого рубильника, которым мы в любой момент сможем резко обрубить всю пользовательскую активность ради внутренних расчётов. Правда, на моей памяти пользовались мы им всего один раз, когда произошёл технический отказ оборудования и сильно просела производительность машин.
- Запрет на ночную работу, потому что с 23:00 до 08:30 мы отправляем считаться очередной цикл хранилища. Справедливости ради, здесь всё устроено достаточно гибко, и мы всё-таки можем при необходимости впустить в это время пользователей в БД. Но обычно оставляем только какие-нибудь межсистемные интеграции, у которых запросы, как правило, стабильные, хорошо проработанные и написаны профессионалами. Или, например, у нас уже три месяца сидит проверка ЦБ и задаёт каждому департаменту очень много вопросов, на которые нужно очень быстро отвечать. В таких ситуациях мы тоже можем дать ночной доступ в виде исключения. Но в обычной жизни мы так не делаем. И вообще ночью сотрудники должны отдыхать.
Формат Self-service у нас выстрелил в нескольких случаях
- При аудитах, когда очень много людей из весьма уважаемых компаний приходят и начинают задавать очень много разных вопросов. Так как доступ к данным широк, это отлично помогает отвечать на вопросы вовремя силами десятков сотрудников одновременно.
- Во-вторых, он пригодился на нашем внутреннем банковском конкурсе «Хочешь — делай». Там у нас обычно собираются инициативные команды по реализации любых интересных штук. Всю эту деятельность нужно как-то оценивать и мониторить. Прямой доступ к детальным аналитическим данным даёт этим командам высокую автономность.
- В-третьих, это фокус на ключевых целях по развитию и изменению бизнеса банка. Каждая большая цель состоит из множества отдельных (и даже не всегда очевидных) элементов, за которыми необходимо постоянно и качественно следить. Или, цитируя руководство, «сделать новый уровень показателя частью ежедневной текучки».
Как мы вообще строим работу по Self-service-аналитике
В первую очередь нужны два основных ингредиента.
- Со стороны ИТ — техническое обеспечение, то есть надёжное хранилище и грамотная поддержка.
- Со стороны бизнеса — люди, которые умеют работать с БД или BI-инструментами и писать запросы.
В каждом департаменте ребята самостоятельно решают вопрос с кадрами, процесс приёма на работу давно выстроен. В основном набирают кандидатов, у которых уже есть предварительное понимание, как и с чем им придётся работать в техническом плане. Но и будем откровенны — в области анализа данных сейчас сложно встретить резюме без базовых знаний SQL и/или Python.
Но с погружением мы, конечно, помогаем. У нас есть большая красивая инструкция, в которой разобраны самые частые проблемы. Начиная с того, как зайти в систему, получить или поменять пароль и написать запрос в хранилище, и заканчивая инструкцией о том, что делать, если вон та штука не работает, и к кому с каким вопросом можно подходить. А если ребята начинают до неприятного часто жаловаться на неработающие запросы, мы переделываем инструкцию и проводим дополнительное обучение.
А перед тем, как дать доступ к системе, проводим тестирование. Первый тест — на умение писать SQL-запросы, а второй — на знание самой системы по той самой инструкции. Всего в тесте около тридцати вопросов, на 90% из которых придётся ответить правильно. И наша команда постоянно занимается доработкой, постоянно что-то оптимизирует, рефакторит и в целом ускоряет то, что написал бизнес.
Чтобы всё хорошо работало в таком формате, нужна очень опытная команда сопровождения. Я не могу поставить на поддержку новичка: чтобы помогать другим, нужно самому знать систему в идеале. Самый молодой мой сотрудник из Support работает здесь уже почти шесть лет.
Небольшая ретроспектива по нашим BI-инструментам
Поначалу мы работали исключительно на Oracle BI, купленном ещё когда мы были частью чешской группы. За визуализациями тогда все приходили к ИТ-специалистам. Хранилище использовалось как единственный источник данных, и всё, что нужно было посчитать, протаскивалось через него. Но постепенно мы поняли, что эта система работает всё хуже, нам её категорически не хватает, и начали её видоизменять.
Постепенно мы выделили в хранилище эдакие «песочницы» для разных задач, то есть внутри единой большой базы данных — собственный ресурс для самых технически продвинутых подразделений (а это риски, CRM, финансы, антифрод и т.д.). Используя витрины из «ядра», можно было решать собственные задачи, создавать объекты, писать процедуры, вешать их на джобы и т.д. Теперь логика их расчётов могла изменяться хоть по несколько раз на дню, и это круто, потому что классическая разработка через ИТ-команду такого обеспечить не могла.
В общем, у нас был Oralce BI для отчётов и визуализаций и ядро DWH для подобных строго формализованных задач, но полноценного BI-инструмента ещё не было, а всё, что требовало какой-либо гибкости, решалось непосредственно в БД. Затем технически продвинутые товарищи начали даже писать вспомогательные инструменты самостоятельно — вплоть до десктопных и веб-приложений на С# и Java — лишь бы это помогло при интерактивной работе с БД и визуализации каких-то данных. Свои собственные опенсорс-решения они прикручивали везде, куда могли дотянуться, и плохо просматриваемая область вокруг хранилища росла.
Всю эту деятельность нужно было аккуратненько завернуть в правильное, а главное, безопасное русло. В идеале — разгрузив ИТ, чтобы он занимался только выдачей лицензий и проверкой доступов, а все остальные расчёты ребята из бизнес-направлений делали сами. Тем более что ландшафт постоянно усложнялся, количество источников данных росло и появлялись микросервисы, данные из которых хотелось не протаскивать в хранилище, а визуализировать и анализировать напрямую. Это не считая развивающиеся Big Data-кластер или OLAP-кубы, которыми у нас полностью занимались ребята из финансов.
Сделать это можно было с помощью нормального BI, который будет работать в режиме Self-service. Так к Oracle BI у нас добавился Tableau. А после перехода на 365-й офис — ещё и облачный Power BI. Всё вместе это составило некую экосистему, в которой можно было решать практически любую задачу по аналитике данных самыми разными способами.
На пике, к концу 2021 года, уже около сотни человек, не связанных с ИТ, занимались профессиональной разработкой в системах Tableau и Power BI. Около четырёхсот пользовались дашбордами. И это не считая общедоступных дашбордов, не требующих отдельных лицензий, которые в Power BI массовые подразделения использовали почти поголовно.
Мы строили, строили и наконец построили
А потом наступил 2022 год, и западные вендоры ушли с рынка.
Само хранилище (а оно является источником процентов для 70% BI-дашбордов) размещено в Oracle, и там всё очень интересно с лицензиями. Он вроде бы ушёл, но продолжает работать: контракты проданы и резко выключить систему просто невозможно. Впрочем, года четыре назад Oracle затормозил развитие собственного продукта, и ничего кардинально нового в нём давно уже не происходило, так что никаких негативных последствий от отсутствия обновлений мы пока не ощутили. Конечно, подобные сложные системы, со временем просто обязаны начать разлагаться, глючить и требовать костылей, так что искать замену рано или поздно всё равно придётся. Но не сейчас. Регуляторные задвижки постоянно изменяются, на рынке огромная турбулентность, а чтобы перетащить нашу систему на Postgres или Greenplum, нужно сначала полностью сломать весь формат работы, а потом выстроить его с нуля. На это уйдёт несколько лет и очень много денег. И есть риск растерять команды, которым эти новшества могут не понравиться. К тому же сейчас не самый лучший момент для любых переходов, потому что и бизнес, и требования ЦБ находятся в активных изменениях. Ну и ещё наш банк попал под санкции и у нас только что сильно поменялись продукты и руководство.
В общем, потрясений для нас пока достаточно, продолжаем работать на Oracle и даже запускаем на нём новые системы. Вернёмся к вопросу, когда ситуация стабилизируется и выстроятся новые процессы.
Но если с Oracle и в части БД и в части BI всё пока более-менее стабильно, то Power BI мы окончательно потеряли осенью 2022, а Tableau — летом 2023 года.
Ещё летом 2022 года мы пошли смотреть опенсорс и окунулись в рынок российского BI — там сейчас происходит очень много интересного. В кулуарах ходят захватывающие истории о том, кто, как и через кого доставал какие системы от западных лидеров рынка. Мы покопались в этой информации пару-тройку недель и поняли для себя, что не хотим играть в лотерею «купим — не купим», «продлим — не продлим», а вкладывать большие собственные ресурсы в доработку этих систем — не можем.
Дальше мы пошли смотреть, что рынок предлагает официально, и выяснилось, что у PIX BI, Visiology, Luxms, FineBI и всех прочих инструментов BI, как новых российских, так и тех, что исходят из зарубежных ядерных систем, есть одна большая проблема — все они пока сыроваты и кривоваты. В одной не хватает функционала, другая — время от времени глючит и считает неправильно. Из множества зол предстояло выбрать наиболее удобное.
Так как весь BI у нас построен в формате Self-service и ключевая экспертиза в руках бизнес-подразделений, мы собрали фокус-группу из самых инициативных ребят, которые были готовы составлять требования и пилотировать разные системы. Пару месяцев мы вместе с ними яростно экспериментировали и пришли к выводу, что в первую очередь нужен такой Self-service, который позволит сохранить уже выстроенный и привычный формат работы. То есть такой, в котором визуальная часть полностью на совести бизнеса и айтишники туда вообще не заглядывают. Иначе мы убили бы очень-очень много времени, чтобы своими ручками перенести эти тысячи дашбордов и отчётов, которые раньше лежали в Tableau и Power BI.
Дальше мы пошли смотреть демо, и оказалось, что системы, которые могут позволить такой уровень сервиса из коробки, можно пересчитать по пальцам одной руки. Пару месяцев мы проводили тендеры и в финале выбирали из двух кандидатов. В итоге остановились на «Дельте BI».
Она тоже не без греха, продукт только-только запускался на нашем рынке, и мы её поначалу тоже довольно долго пытались стабилизировать. Но в мае 2023 вышло очередное обновление, в котором пофиксили все основные ошибки, и всё стало весьма неплохо. Но самое главное, в неё уже заложены все необходимые нам функции, а качество с каждой новой версией становится лучше.
К началу лета 2023 мы её внедрили. А теперь активно подгоняем бизнес-пользователей, чтобы они поскорее переносили туда весь свой функционал из Tableau и Power BI.
Без качественного обучения перейти на новый BI-инструмент не получится
Если для Tableau и Power BI специалистов на рынке было много, да и обучающих курсов на YouTube — полно, то в начале пути для «Дельты» всего этого пока примерно ноль. Система новая и довольно непонятная, к ней нужно привыкать. И хотя база видеоуроков на канале вендора постепенно наполняется, без глубокого погружения не обойтись. Понимая это, ребята из «Дельты» провели для десяти наших ключевых пользователей большое и сложное шестнадцатичасовое обучение.
Правда, в системе у нас сейчас работает около восьмидесяти человек и выбить два полных рабочих дня, чтобы они бросили все свои дела и пошли учиться, пока не получится — это очень дорого для компании. Поэтому мы сделали на внутреннем портале собственный курс на базе учебных материалов «Дельты», чтобы каждый сотрудник банка мог разобраться, как работать в этой системе, по ходу дела. Большое спасибо за это нашей сервис-деск-команде.
Мы учим не только «Дельте», но и работе в самом хранилище. Потому что знание SQL — это, конечно, хорошо, но знание конкретной архитектуры конкретной базы данных тоже необходимо.
А чтобы защититься от лишних косяков, мы сделали специальный тест на тридцать вопросов и поставили условие, что в систему можно попасть только, когда он будет пройден. За восемь месяцев сдали тест и получили доступ уже сто тридцать семь человек.
А теперь — ложка дёгтя
Со временем мы столкнулись с тем, что, когда бизнес-подразделения долгое время работают в режиме самоуправства, данные начинают расползаться. Так что, ради их безопасности, политику нужно выстраивать достаточно жёсткую. К тому же разночтения по некоторым показателям могут привести к совершенно конкретному взрыву мозга: возникает множество версий, которые не всегда бьются между собой.
Самые важные правила, которые мы выделили, таковы:
- Для нормальной работы Self-service нужен продвинутый Data Governance. И это касается не только технических средств, но и культуры работы с данными. Каждое подразделение, направление и система должны очень чётко понимать, что они делают. И отвечать за данные, которые генерируют.
- Мёртвый функционал необходимо своевременно удалять (и это, кстати, сложнее, чем создавать что-то новое): качественное масштабирование без такого же качественного удаления невозможно. Поэтому нужно аккуратно и своевременно переносить всё важное, что было создано бизнесом, в условное ядро и брать его на собственную поддержку.
- Необходимо постепенно наращивать команду: опытные разработчики и системные аналитики очень нужны, чтобы разобраться в работе бизнес-подразделений. Классических ресурсов сопровождения на это уже не хватает.
А ещё очень важно помнить, что регуляторы пристально следят за рисками в финансовых организациях. И в том числе за тем, как работает каждая ИТ-система. Они сильно погружаются в нашу работу, и это требует выстраивания процессов в организации на более жёстком уровне. А это неизменно повлияет на всю аналитику и качество данных, а также решений, которые на их основе принимаются.
То есть нам нужно дать широкому количеству бизнес-подразделений возможность решать вопросы с привлечением минимального количества людей. В идеале — вообще без привлечения, исключительно силами руководителей: на этапе передачи формулировки задачи по цепочке, какая-то часть её сути всегда теряется, а реализация аналитической задачи должна быть максимально близка к той мысли, которая эту задачу породила. Сам залез, сам сделал, а если понял, что был неправ, сам же и пересчитал всё заново.
Но ребятам из бизнеса довольно сложно самостоятельно следить за всеми расчётами и корректировать их под какие-то изменения и случайности. Банально — пришёл новичок, накосячил, и всё упало. Упс, придётся поднимать. Их ресурсы ограниченные, далеко не дешёвые и вообще должны расходоваться на другие задачи.
А значит, нужно, с одной стороны, выравнивать единую версию правды, а с другой — в ряде направлений от Self-service отказаться.
Для этого нужно грамотно разделить все процессы, забрать условное ядро — то есть тяжёлые и общеиспользуемые признаки и некоторые процессы — в сторону ИТ, а на откуп бизнес-подразделениям оставить только самое гибкое, экспериментальное и прототипное. Некоторые процессы, например, могут корректироваться по несколько раз в день, и отдавать их айтишникам просто нецелесообразно.
Это на самом деле очень тонкий вопрос, потому что система может работать только при условии глубокой проработки политики работы с информацией. Нужно правильно выстроить и сопоставить бизнес-процессы с данными, которые ими порождаются, а потом разобраться, что куда передаётся, как и где считается. И только когда всё уже видно и прозрачно, можно делать сепарацию.
Это дорогостоящая история, которая подразумевает сильную переработку всего процесса. Такую жёсткую политику с точки зрения управления данными наш банк уже начинал проводить в 2021 году (когда мы были частью группы, нам её приносили чехи), но закончить, к сожалению, не успел. На время мы от этой тактики отошли, потому что в турбулентные времена было немного не до неё, но в 2024 году мы к этому вопросу возвращаемся. А начать планируем с департаментов архитектуры и рисков.
Краткое резюме для тех, кто только начинает строить Self-service
Если всякие финтехи и прочие продвинутые компании довольно гибкие ребята, то компании, которые сильнее связаны с материальным миром, более консервативны, когда речь идёт про аналитику и отчётность. Им обычно очень не хочется в них лезть, а хочется, чтобы ИТ сделал всё быстро и хорошо. Поэтому в первую очередь советую найти единомышленников среди бизнеса и руководства, то есть тех людей, которые будут проводниками этой идеи в массы. А во-вторых, перед тем как начинать переход, нужно создать качественную методологическую основу и подготовиться обучать людей.
Подготовить базу и поставить человека, которому это интересно.
Самые главные умения, которым нужно обучать людей, — это базовый SQL и работа с системой. Нужны хотя бы элементарные уроки, видео и тесты, по результату которых можно будет допускать людей к работе с системой. То есть нужно, чтобы у каждого пользователя была под рукой вся нужная информация и он понимал, к кому обратиться по тому или иному вопросу.
И, когда у первых энтузиастов всё получится, можно будет этот позитивный пример дальше «продавать» внутри своей организации.