Ефс сбербанк что это

Обновлено: 27.03.2024

Одна из ключевых задач Программы «Единая фронтальная система» – создание единого пользовательского опыта. Любые интерфейсы, любые экраны, которые видит клиент или сотрудник в мобильном приложении, банкомате или за рабочим местом в отделении банка, должны работать по единым и понятным сценариям.

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

Итак, почему для нас это важно?

Мы — крупнейший банк страны с самой многочисленной сетью отделений. Несмотря на общий тренд диджитализации услуг, у клиентов по-прежнему есть насущная потребность ходить в отделения, звонить в контактный центр. Ежедневно по всей России на передовой фронт-офиса находятся тысячи сотрудников банка. Цель Единой фронтальной системы — помочь сотруднику банка в его работе, а не просто изменить цвет нижней правой кнопки.

Как думаете, сколько примерно экранов видит сотрудник банка? Если экраны, которые видит за день менеджер по обслуживанию, поставить друг на друга, то получится четыре Эйфелевых башни. Почему так много? Потому что в самом большом банке страны очень много процессов, огромное количество продуктов. При этом надёжность системы составляет 99,99%. Такой уровень надежности позволяет бабушке вовремя получить пенсию в отделении, а маме заплатить за кредит или коммунальные услуги без просрочки.

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

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

С чего начинали?

Начали менять систему с самого простого. Договорились с продуктовыми командами, что у нас единая модель обслуживания клиента: когда он к нам приходит, мы его всего один раз находим в системе, определяем его потребность и проводим необходимые операции. Платформа ЕФС позволяет объединить все процессы в единую последовательную цепочку. Над поддержкой и развитием такой цепочки в Программе работают порядка 100 команд, где одни разрабатывают кроссплатформенные процессы (общие для ряда операций и сервисов), а другие занимаются настоящей продуктовой магией.

Как нам удается одновременно поддерживать работу 100 команд?

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

Методом проб и ошибок, постоянной командной работы мы выработали свой рецепт:

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

Итак, раз в три месяца все команды, разработка которых входит в будущий релиз, собираются и договариваются о задачах на квартал. Численность последней такой встречи превысила 400 участников. Задачи команд делятся на бэклоги, разбиваются на спринты, а спринты потом обязательно синхронизируются. Важно, что в процессе обсуждения участники прорабатывают риски и просто «белые» зоны, о которых не подумали или не спланировали ранее. Сценарий такой церемонии просчитан поминутно, а кроме командного планирования, программа включает в себя коммуникацию с архитекторами, дизайнерами и другими смежными экспертами, которые на раннем этапе планирования помогают командам проработать узкие места процесса в целом.

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

Что собственно всё это даёт сотруднику банка?

Рассказываем на примере одной из реальных задач спринта, данные представленных интерфейсов являются тестовыми.

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

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

В решении экран был разделен на 3 части: список платежей, выбор способа оплаты, общая стоимость. Тестирование показало, что на последнем экране сотрудник уже не помнит, что собирался оплачивать. Ни один сотрудник не справился с заданием, уровень UX-критичности был определен как высокий.

В UX-тестировании мы оцениваем две важные метрики:

    количество сотрудников, справившихся с задачей;

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

В программе мы постоянно пробуем новые практики и делимся кейсами: в этой статье мы расскажем о пилоте с новым UX – инструментом, а в аттаче вы сможете посмотреть последнее выступление по теме UX для сотрудников.

Причина, которая подтолкнула нас провести данный пилот, заключается в следующем: при проведении качественных UX-исследований (3-5 человек) мы часто выявляем отклонения от идеального процесса взаимодействия пользователей с нашими digital-продуктами. И для принятия решения о доработках нам необходимо очень быстро подтверждать/опровергать критичность данных отклонений для общей массы клиентов. Для решения данной задачи мы попробовали метод дистанционного немодерируемого тестирования, который позволяет получать необходимые нам количественные данные (50-100 человек*) за 1-2 дня.

Для пилота был выбран облачный инструмент проведения дистанционных юзабилити-тестов Фабуза от компании «Фабрика Юзабилити», который, к слову, используется многими крупными российскими компаниями для решения подобных задач.

Задача для пилота

Клиентам нужно было в мобильном приложении банка оплатить квартплату для клиента банка из другого региона (для пожилой родственницы).
Респонденты: работающие мужчины и женщины (50/50) от 25 до 45 лет не из банковской сферы и не из сферы маркетинга. Из них 50% — активные пользователи мобильного приложения банка, 50% — неактивные (проводят операции раз в месяц или реже). Респонденты должны были проживать в двух заданных регионах: Москва и Новосибирск.
Гипотезы, которые мы проверяли:
• пользователю не очевидно, как в приложении поменять регион;
• пользователю не очевидно, что изменяя регион для оплаты он меняет регион в своем профиле.

Ну и сроки у нас, конечно же, были очень короткие.

Для проверки мы собрали прототип, в котором предполагалось, что пользователь должен оплатить в мобильном приложении счет за родственницу из другого региона.
Далее создали специальный опросник в системе (на это ушло 2 часа), который включал: скрининговые вопросы (пол, возраст, география и т.д.); задания для участников, которые они должны были выполнить в прототипе приложения на собственном телефоне; оценки сложности и отрытые вопросы о трудностях, с которыми они столкнулись.
После этого ссылка на опросник была автоматически отправлена участниками исследования из Москвы и Новосибирска. Участники переходили по ссылке, отвечали на вопросы, выполняли задания, давали оценки и комментарии. Во время исследования инструмент собирал данные, которые в режиме real-time попадали в онлайн-отчёты и аггрегировались:
• Видеозаписи экрана мобильного телефона участников с визуализацией жестов
• Оценки и комментарии участников относительно проблем
• Перемещения участников между страницами прототипа
• Результаты теста (справился/не справился/провалил)
• Время выполнения теста
• Места и количество кликов

За сутки сценарий оплаты на прототипе прошли 57 респондентов из Москвы и Новосибирска. Проанализировав данные по этим участникам (на анализ ушло около 8 часов), мы получили следующие результаты:
• 60% респондентов не смогли быстро выполнить/выполнить данное задание из-за особенностей реализованного в прототипе интерфейса, что подтвердило наши гипотезы.
• Было выявлено несколько популярных маршрутов, которые находили пользователи для решения задач, что очень сильно поможет нам при доработке прототипа и проектировании UX.
• Дополнительно мы получили несколько инсайтов, например: пользователи воспринимают платеж за другого клиента как перевод, не могут найти в профиле возможность изменить регион и т.д.

В комментариях будем рады обсудить ваши предложения, ответить на вопросы и обменяться практиками.

В этой статье мы расскажем о библиотеке компонентов Единой фронтальной системы (ЕФС) и как в целом устроен фронтенд платформы.




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

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

Очевидно, что это неудобно для всех: для клиентов, сотрудников и банка в целом.
Поэтому главная миссия фронтенда ЕФС – заменить существующую сборную солянку и привести все к единой кодовой базе, к единому технологическому стеку с удобным и понятным пользовательским сценарием.

Какие задачи стоят перед разработкой?

    Надежность и безопасность, ведь мы говорим о банковском ПО.

Как устроен фронтенд в ЕФС?

У нас есть команда разработчиков платформы ЕФС, а также прикладные разработчики, задача которых – реализовать бизнес-логику.

В качестве инструментария мы используем набор инструментов от компании Atlassian: JIRA для постановки задач, BitBucket для git-репозиториев и Confluence для документации.

Из чего состоит библиотека?

    Различные UI-элементы: всевозможные селекты, кнопки, большой набор полей с различными типами данных, чекбоксы, радиокнопки и другие элементы формы, с которыми взаимодействует пользователь.




Поддержка браузеров

Целевыми браузерами являются IE8+. Сейчас IE8, если кто-то помнит, это как в свое время был IE6: ужасное API и ужасная отладка. Конечно, время, проведенное за дебагом в IE8, бесценно. Были случаи, когда разработчики проводили несколько дней в попытках найти, в каком месте возникала ошибка, потому что в IE8 очень скудный инструментарий для дебага и он показывает порой, что ошибка возникла совсем в другом месте.

Поддержка IE не случайна, нам приходится работать с железом из браузера: RFID-таблетки, различные принтеры, сканеры и т.д. В вебе нет единого стандарта по работе с железом: в далеком прошлом технологией для работы с ним был выбран ActiveX. Количество ПО, написанного с использованием ActiveX, колоссально, и это не дает нам в одночасье отказаться от поддержки IE и перейти в сторону современных браузеров. В планах — перевод устаревшего ActiveX на Java-апплеты и отказ от IE8.


Стек технологий

Мы своего рода стартап внутри крупной организации и наш стек технологий фронтенда не сильно отличается от большинства мировых стартапов: react, redux и PostCSS. Все эти технологии зарекомендовали себя с лучшей стороны, к тому же, они позволяют нам поддерживать IE8. Однако, мы не можем резко менять стек технологий, т.к. вокруг него завязана определенная архитектура приложений, например, именно React позволил нам разбить одно огромное приложение на сотни маленьких и подгружать их по требованию, используя SystemJS.

React

Это первая технология, которую мы выбрали по следующим причинам:

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

Как мы подружили React и IE8 ?

Во-первых, мы не обновляем версию React, потому что с какого-то момента они тоже отказались от поддержки IE8. Во-вторых, мы используем es3ify — это loader для webpack, который берет наш ES5 код и перегоняет в ES3. Он просто заменяет некоторые вещи, которые в IE8 не работают.

TypeScript

Второй технологией, которую мы выбрали, был TypeScript, вот почему:

    Строгая типизация
    По нашим стандартам тип any запрещен, однако, бывают исключения из правил, т.к. далеко не всё можно покрыть generic’ами.

Производительность

Во-первых, мы сделали компоненты «глупыми», то есть избавились от state, вынося его на прикладной уровень. Теперь прикладные разработчики решают, как менять state, а в наши компоненты только пробрасываются нужные props.


Есть библиотечный компонент Input, у него в state хранится value, в render он возвращает input и в onChange он меняет state. Не много ли кода для такого компонента? Однозначно много, давайте отрефакторим этот пример:


Код компонента стал короче, а на уровне выше есть компонент Form, который сам решает, как управлять состоянием компонента: через redux или через простейший setState. Input стал проще, и, соответственно, производительнее.

Второе, мы придерживаемся архитектуры чистых компонентов (PureComponent), т.е. все внешние свойства, внутренний state и контекст проходят проверку соответствия предыдущему состояния. Если состояние не изменилось, то нет смысла вызывать render лишний раз. Эту проверку мы осуществляем в методе shouldComponentUpdate, который добавили во все наши компоненты.

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


В данном примере у компонента есть коллбек onClick и в него передается стрелочная функция.
Если ее так задать, то здесь возникает утечка. В IE8 ее особенно видно, потому что при каждом повторном вызове render эта функция создается, она накапливается и возникают тормоза в компоненте. Немного изменим наш пример:


Сам код стал лаконичнее и к тому же, мы избавились от утечки, поскольку callback-функция больше не создается при каждом вызове render.

В планах на будущее — прекращение поддержки IЕ8, что позволит использовать более прогрессивные фронтенд-технологии. Кроме того, мы уже приступили к работе над масштабным проектом интеграции с мобильной платформой ЕФС, приступили к разработке гибридной библиотеки, позволяющая один и тот же код использовать и для web, и для мобильных устройств, используя React Native.

В следующий статье про фронтенд программы ЕФС мы расскажем про то, как мы используем Redux и как он стал сердцем нашей архитектуры, подписывайтесь на наш блог, чтобы не пропустить!

Идеи, предложения и пожелания – пишите, будем рады пообщаться с вами в комментариях к статье.

В разработке Программы «Единая фронтальная система» Сбербанка участвуют больше сотни команд. Каждая команда создает и развивает определенный продукт или сервисный компонент. Для каждой новой инициативы требуется оценить объем «железа», который потребуется для разработки и внедрения этой инициативы. А это большой поток запросов на оценку. О том, как мы решаем эту задачу, читайте под катом.




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

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

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

Что такое сайзинг-модель в ЕФС?

Сайзинг-модель представляет собой шаблон из нескольких разделов. Рассмотрим каждый из них подробнее.

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

В обоих случаях мы получаем от заказчика оценку:

  1. Пикового количества бизнес-операций в час. Этот показатель является ключевым и влияет на требуемые мощности по обработке операций.
  2. Среднего количества бизнес-операций за сутки. Определяет объем хранимых данных.

Внутренняя сеть
Наименование
Комментарий
Пиковое количество бизнес-операций за час
Берется из бизнес-требований либо рассчитывается: операций за сутки/10
Среднее количество бизнес-операций за сутки
Берется из бизнес-требований либо рассчитывается: операций за час*10
Пиковое количество запросов через MQ в секунду (прямая интеграция с внешними системами)
Сумма по взаимодействиям точка-точка через MQ

Внешняя сеть
Наименование
Комментарий
Пиковое количество бизнес-операций за час
Берется из бизнес-требований либо рассчитывается: операций за сутки/10
Среднее количество бизнес-операций за сутки
Берется из бизнес-требований либо рассчитывается: операций за час*10

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

  1. В России 12 часовых поясов, отделения и клиенты распределены по всем часовым поясам, время работы отделений – 10–12 часов в сутки.
  2. Наибольшее количество пользователей и операций сосредоточено в часовом поясе Москвы, этот пояс определяет пиковую нагрузку.
  3. График распределения нагрузки по часам имеет два пика — утром и после обеда, в целом одинаков для всех часовых поясов с учетом временного сдвига.


Рисунок 1. Упрощенная архитектура ЕФС

Архитектура ЕФС основана на классической трехзвенной архитектуре

  1. Презентационный слой. Чаще всего – просто nginx со статикой, в специальных случаях добавляется сервер приложений.
  2. Сервера приложений с бизнес-логикой.
  3. Базы данных.

Раздел 2. Параметры модели

Параметры разбиты на три группы:

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


Расчетные коэффициенты

В таблице приведено описание коэффициентов, для себя выработали значения. Если интересно, задавайте вопросы в комментариях – поделимся экспертными оценками.


Раздел 3. Модель расчета

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

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

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

Ниже приведены формулы, которые мы используем для расчета.

Считается как перемножение пикового числа пользователей на число запросов в секунду.

Количество Web-серверов внутренней сети


На выходе сайзинг-модели мы получаем оценку «железа» для промышленной среды.
В мировой практике выделяют три основные модели сайзинга:

В программе ЕФС у нас комбо из «Транзакционной модели» и «Тестовой модели». Так как мы обладаем информацией о количестве пиковой нагрузки бизнес-операций, но также руководствуемся показателями, полученными из проведённого нагрузочного тестирования. Но есть особые случаи, когда в ЕФС внедряется новый функционал, которого не было в других системах, и нам на вход поступают предполагаемые данные, тогда мы действуем по аналогии с «Пользовательской моделью».

На платформе Единой фронтальной системы (ЕФС) разрабатываются фронтальные процессы для системы «Сбербанк Онлайн» (мобильное приложение и веб-версия), а также для сотрудников отделений, специалистов по прямым продажам первого уровня. Программа по разработке этой системы является одной из ключевых и стратегических для Сбербанка.

2020: Запуск единого рабочего места операторов на базе ЕФС

26 февраля 2020 года «Сбербанк» сообщил TAdviser о запуске тиража собственной разработки — единого рабочего места (ЕРМ) операторов первых линий, обслуживающих корпоративных клиентов. Запуск ЕРМ планируется на 1 марта 2020 года.

Сбербанк запускает единое рабочее место операторов собственной разработки

Опытная эксплуатация разработки показала, что благодаря ей экономится 17–20 секунд (примерно 6%) среднего времени обработки контакта. В месяц это 2900 часов.

На 26 февраля 2020 года идут подготовительные работы по организации тиража и обучению операторов — пользователей ЕРМ. Увеличение численности операторов будет происходить планомерно.

Единое рабочее место (ЕРМ) операторов первых линий ЦКР («Центра корпоративных решений») для направлений «операционная поддержка УСО» и «техническая поддержка ДБО» разрабатывается на базе банковской платформы «Единая фронтальная система» (ЕФС) с использованием модульного подхода, позволяющего легко подключить (в зависимости от потребности и готовности) дополнительные инструменты или сервисы. На февраль 2020 года ЕРМ состоит из следующих модулей: идентификации клиентов, аутентификации, CTI-панели, карточки клиента, истории вопросов, интеллектуального помощника, базы знаний, регистрации обращений, уведомлений, поиска в CRM.

ЕРМ содержит консолидированную из девяти систем-источников информацию: «CRM Корпоративный», ЕКС, СББОЛ, Way4, СНУИЛ, БФС (геообъекты), ФП «Выплаты», ФП ЗД (зарплатные договора). Это позволяет сократить количество программных окон на рабочем столе оператора.

2018: Результаты разработки за год

В 2018 году были усовершенствованы архитектура ЕФС, процессы разработки и вывода функционала в промышленную среду, сообщил Сбербанк в отчете о своей деятельности за 2 квартал 2019 года. Также была внедрена возможность многоверсионности, благодаря которой технологические сервисы и клиентский функционал могут развиваться независимо и итерационно в собственных релизных циклах.




В рамках разработки ЕФС в 2018 году Сбербанк реализовал функционал дистанционного банковского обслуживания по документарным операциям (аккредитивы, инкассо) через «Сбербанк Бизнес Онлайн», который позволяет клиенту направлять заявления/запросы/письма в банк в электронном виде, отслеживать их статусы онлайн и видеть реестр своих сделок.

Этот сервис позволяет сократить время обслуживания клиентов по аккредитивам и инкассо и повысить удовлетворенность клиентов, заявляют в Сбербанке.

Еще одним ключевым событием в области ЕФС Сбербанк называет начало этапа массового тиража системы на всех клиентов в трех каналах дистанционного банковского обслуживания в 2018 году.

2017: Новая версия ЕФС

В 2017 году была разработана новая версия платформы ЕФС 7.0 с более высоким уровнем надежности и производительности за счет поддержки режима развертывания в многоблочной архитектуре и режима Stand-In, обеспечивающего повышение отказоустойчивости и бесшовное обновление функциональных подсистем платформы. Также было начато массовое внедрение нового целевого процесса разработки ЕФС с использованием «инструментальных средств разработки. В Сбербанке поясняют, что это позволит одной команде реализовывать решения для всех каналов, максимально переиспользовать уже реализованные объекты и сервисы, уменьшить число ошибок за счет авто-генерации типовых функциональных блоков, а также сократить время обучения новых сотрудников.

Ожидаемый эффект от внедрения целевого процесса разработки ЕФС – сокращение объема ручной разработки в два раза.

Практики DevOps были внедрены для всех приложений ЕФС. Использование DevOps сокращает время на обновление приложений и позволяет избежать ошибок ручной установки параметров. Покрытие кода автоматическими модульными тестами достигло 80%, что привело к снижению количества ошибок на этапе тестирования в два раза, заявляет Сбербанк.

Кроме этого, в 2017 году банк определил стандарт качества платформы ЕФС. Его выполнение контролируется по 12 метрикам. Использование стандарта вдвое сократило количество ошибок на этапе тестирования и позволило добиться того, что 50% ошибок устраняются в течение 8 часов.

Определены разработчики Единой фронтальной системы Сбербанка

В мае 2016 года Сбербанк определил подрядчиков по созданию "Единой фронтальной системы" (ЕФС), которая позиционируется как новая платформа трансформации банковского бизнеса [1] .

Компания "Техносерв Консалтинг" выбрана разработчиком фронтальной системы для блоков «Розничный бизнес» и «Управление благосостоянием», AT Consulting - для блоков «Корпоративный бизнес» и «CIB».

Максимальная цена первого лота составляла 297 млн рублей, "Техносерв Консалтинг" предложила выполнить работы за 178,2 млн рублей.

Второй лот был оценен в 198 млн рублей. Сумма, за которую согласилась выполнить работу AT Consulting, составила 131,5 млн рублей.



Единая фронтальная система позволит Сбербанку обеспечить единый клиентский опыт и ускорить вывод на рынок новых продуктов

Генеральным подрядчиком Сбербанка по созданию Единой фронтальной системы является компания "Сбербанк-Технологии".

К участию в закупке были приглашены компании, имеющие опыт реализации не менее трех проектов по разработке фронтальных систем в период с 2013 г. (при этом пользовательская аудитория проекта должна составлять не менее 10 000 пользователей). Участники конкурса должны иметь не менее 40 разработчиков со знаниями языка программирования Java, 20 системных аналитиков, 20 разработчиков со знанием языка программирования JavaScript, css, html и 5 архитекторов. Специалисты проектной команды участника должны обладать сертификатами Java Senior Specialist (не менее 10 специалистов) и Oracle Professional (не менее 1).

Отдельно в документации оговаривались максимальные ставки специалистов:

№ п/п Роль в проекте Стоимость оплаты чел./дня специалистов, руб. без НДС Стоимость оплаты чел./дня специалистов, руб. с НДС
1 Главный разработчик не более 18 980,00 не более 22 396,40
2 Ведущий аналитик/разработчик не более 14 440,00 не более 17 039,20
3 Ведущий аналитик/Бизнес-аналитик не более 14 440,00 не более 17 039,20
4 Аналитик/разработчик не более 10 690,00 не более 12 614,20
5 Ведущий разработчик (Java Script) не более 10 690,00 не более 12 614,20

Общая оценка заявки участников зависела на 50% от предложенной стоимости выполнения работ и на 50% от качества выполнения тестового задания.

Задачи системы

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

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

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

Также, как ожидается, ЕФС позволит сократить время проведения операций, упростить интерфейс сотрудников отделений, ускорить адаптацию к работе новичков, снизить количество ошибок.

Руководство программы ЕФС

В конце 2018 года руководителем программы «Единая фронтальная система» стал Алексей Поддубный. По информации TAdviser, он был назначен на эту должность после того, как из Сбербанка ушла Елена Батурова, которая ранее руководила проектом ЕФС, а также Вадим Шаробаев, который под ее руководством отвечал за этот проект в Сбертехе. Подробнее здесь.

На платформе Единой фронтальной системы (ЕФС) разрабатываются фронтальные процессы для системы «Сбербанк Онлайн» (мобильное приложение и веб-версия), а также для сотрудников отделений, специалистов по прямым продажам первого уровня. Программа по разработке этой системы является одной из ключевых и стратегических для Сбербанка.

2020: Запуск единого рабочего места операторов на базе ЕФС

26 февраля 2020 года «Сбербанк» сообщил TAdviser о запуске тиража собственной разработки — единого рабочего места (ЕРМ) операторов первых линий, обслуживающих корпоративных клиентов. Запуск ЕРМ планируется на 1 марта 2020 года.

Сбербанк запускает единое рабочее место операторов собственной разработки

Опытная эксплуатация разработки показала, что благодаря ей экономится 17–20 секунд (примерно 6%) среднего времени обработки контакта. В месяц это 2900 часов.

На 26 февраля 2020 года идут подготовительные работы по организации тиража и обучению операторов — пользователей ЕРМ. Увеличение численности операторов будет происходить планомерно.

Единое рабочее место (ЕРМ) операторов первых линий ЦКР («Центра корпоративных решений») для направлений «операционная поддержка УСО» и «техническая поддержка ДБО» разрабатывается на базе банковской платформы «Единая фронтальная система» (ЕФС) с использованием модульного подхода, позволяющего легко подключить (в зависимости от потребности и готовности) дополнительные инструменты или сервисы. На февраль 2020 года ЕРМ состоит из следующих модулей: идентификации клиентов, аутентификации, CTI-панели, карточки клиента, истории вопросов, интеллектуального помощника, базы знаний, регистрации обращений, уведомлений, поиска в CRM.

ЕРМ содержит консолидированную из девяти систем-источников информацию: «CRM Корпоративный», ЕКС, СББОЛ, Way4, СНУИЛ, БФС (геообъекты), ФП «Выплаты», ФП ЗД (зарплатные договора). Это позволяет сократить количество программных окон на рабочем столе оператора.

2018: Результаты разработки за год

В 2018 году были усовершенствованы архитектура ЕФС, процессы разработки и вывода функционала в промышленную среду, сообщил Сбербанк в отчете о своей деятельности за 2 квартал 2019 года. Также была внедрена возможность многоверсионности, благодаря которой технологические сервисы и клиентский функционал могут развиваться независимо и итерационно в собственных релизных циклах.




В рамках разработки ЕФС в 2018 году Сбербанк реализовал функционал дистанционного банковского обслуживания по документарным операциям (аккредитивы, инкассо) через «Сбербанк Бизнес Онлайн», который позволяет клиенту направлять заявления/запросы/письма в банк в электронном виде, отслеживать их статусы онлайн и видеть реестр своих сделок.

Этот сервис позволяет сократить время обслуживания клиентов по аккредитивам и инкассо и повысить удовлетворенность клиентов, заявляют в Сбербанке.

Еще одним ключевым событием в области ЕФС Сбербанк называет начало этапа массового тиража системы на всех клиентов в трех каналах дистанционного банковского обслуживания в 2018 году.

2017: Новая версия ЕФС

В 2017 году была разработана новая версия платформы ЕФС 7.0 с более высоким уровнем надежности и производительности за счет поддержки режима развертывания в многоблочной архитектуре и режима Stand-In, обеспечивающего повышение отказоустойчивости и бесшовное обновление функциональных подсистем платформы. Также было начато массовое внедрение нового целевого процесса разработки ЕФС с использованием «инструментальных средств разработки. В Сбербанке поясняют, что это позволит одной команде реализовывать решения для всех каналов, максимально переиспользовать уже реализованные объекты и сервисы, уменьшить число ошибок за счет авто-генерации типовых функциональных блоков, а также сократить время обучения новых сотрудников.

Ожидаемый эффект от внедрения целевого процесса разработки ЕФС – сокращение объема ручной разработки в два раза.

Практики DevOps были внедрены для всех приложений ЕФС. Использование DevOps сокращает время на обновление приложений и позволяет избежать ошибок ручной установки параметров. Покрытие кода автоматическими модульными тестами достигло 80%, что привело к снижению количества ошибок на этапе тестирования в два раза, заявляет Сбербанк.

Кроме этого, в 2017 году банк определил стандарт качества платформы ЕФС. Его выполнение контролируется по 12 метрикам. Использование стандарта вдвое сократило количество ошибок на этапе тестирования и позволило добиться того, что 50% ошибок устраняются в течение 8 часов.

Определены разработчики Единой фронтальной системы Сбербанка

В мае 2016 года Сбербанк определил подрядчиков по созданию "Единой фронтальной системы" (ЕФС), которая позиционируется как новая платформа трансформации банковского бизнеса [1] .

Компания "Техносерв Консалтинг" выбрана разработчиком фронтальной системы для блоков «Розничный бизнес» и «Управление благосостоянием», AT Consulting - для блоков «Корпоративный бизнес» и «CIB».

Максимальная цена первого лота составляла 297 млн рублей, "Техносерв Консалтинг" предложила выполнить работы за 178,2 млн рублей.

Второй лот был оценен в 198 млн рублей. Сумма, за которую согласилась выполнить работу AT Consulting, составила 131,5 млн рублей.



Единая фронтальная система позволит Сбербанку обеспечить единый клиентский опыт и ускорить вывод на рынок новых продуктов

Генеральным подрядчиком Сбербанка по созданию Единой фронтальной системы является компания "Сбербанк-Технологии".

К участию в закупке были приглашены компании, имеющие опыт реализации не менее трех проектов по разработке фронтальных систем в период с 2013 г. (при этом пользовательская аудитория проекта должна составлять не менее 10 000 пользователей). Участники конкурса должны иметь не менее 40 разработчиков со знаниями языка программирования Java, 20 системных аналитиков, 20 разработчиков со знанием языка программирования JavaScript, css, html и 5 архитекторов. Специалисты проектной команды участника должны обладать сертификатами Java Senior Specialist (не менее 10 специалистов) и Oracle Professional (не менее 1).

Отдельно в документации оговаривались максимальные ставки специалистов:

№ п/п Роль в проекте Стоимость оплаты чел./дня специалистов, руб. без НДС Стоимость оплаты чел./дня специалистов, руб. с НДС
1 Главный разработчик не более 18 980,00 не более 22 396,40
2 Ведущий аналитик/разработчик не более 14 440,00 не более 17 039,20
3 Ведущий аналитик/Бизнес-аналитик не более 14 440,00 не более 17 039,20
4 Аналитик/разработчик не более 10 690,00 не более 12 614,20
5 Ведущий разработчик (Java Script) не более 10 690,00 не более 12 614,20

Общая оценка заявки участников зависела на 50% от предложенной стоимости выполнения работ и на 50% от качества выполнения тестового задания.

Задачи системы

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

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

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

Также, как ожидается, ЕФС позволит сократить время проведения операций, упростить интерфейс сотрудников отделений, ускорить адаптацию к работе новичков, снизить количество ошибок.

Руководство программы ЕФС

В конце 2018 года руководителем программы «Единая фронтальная система» стал Алексей Поддубный. По информации TAdviser, он был назначен на эту должность после того, как из Сбербанка ушла Елена Батурова, которая ранее руководила проектом ЕФС, а также Вадим Шаробаев, который под ее руководством отвечал за этот проект в Сбертехе. Подробнее здесь.

Автор статьи

Куприянов Денис Юрьевич

Куприянов Денис Юрьевич

Юрист частного права

Страница автора

Читайте также: