Функция платформы · Сбер · корпоративные данные

Автоматизация массовых операций по филиальной сети

Перевёл ручную обработку 25–30 юрлиц в одну управляемую массовую операцию: 3,5 часа → 10 минут.

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

3,5 ч → 10 мин

обработка филиальной сети

25–30

юрлиц в одной операции

0

пропущенных филиалов — исключено логикой

Распространение банкротства — поиск по ИНН
Распространение банкротства — поиск головных организаций
Сайдпейдж распространения банкротства
Сайдпейдж с данными о банкротстве и числом организаций
Подтверждение распространения по филиальной сети
Прогресс распространения
Итог: распространено и не удалось распространить
 / 07
Сценарий распространения банкротства по филиальной сети. На скринах — тестовые данные

Проблема

Компании одной филиальной сети связаны общим ИНН. Если банкротом признавался один филиал, статус нужно было проставить всем остальным — вручную, по одной карточке.

По оценке менеджеров, на компанию уходило ~8 минут, в сети — 25–30 компаний. Сценарий повторяющийся, полностью механический и при этом с высокой ценой ошибки: пропущенный филиал означает, что банк принимает финансовое решение по компании с неактуальным статусом банкротства.

Было → стало

Действия пользователя

Было

25–30 раз повторить один сценарий

Стало

Ввод ИНН → проверка списка → подтверждение

Время

Было

~3,5 часа

Стало

~10 минут

Контроль

Было

Нет сводной картины, что уже обработано

Стало

Список затрагиваемых компаний до применения и прогресс после

Риск пропуска филиала

Было

Высокий, зависит от внимательности

Стало

Исключён на уровне логики

Сайдпейдж распространения банкротства на филиальную сеть
Схема сценария до и после

Результат

Роль

Я

Проектировал сценарий целиком — от точки входа до обработки ошибок, защищал решение перед безопасностью, вёл его до релиза.

Команда

  • Системный аналитик — логика связей по ИНН
  • Бэкенд — пакетная обработка
  • Отдел безопасности — согласование модели подтверждения

Ограничения

  • Массовое изменение критичных данных не может выполняться «в один клик» — прямое требование безопасности
  • Изменения необратимы на уровне системы: отката пакетной операции не предусмотрено
  • Состав филиальной сети на момент операции пользователь должен видеть до применения, а не после
  • Срок — 3 недели

Решение 1

Точка входа: система предлагает, а не пользователь ищет

Было: массовой операции не существовало, менеджер сам держал в голове, что филиалы надо обойти.

Выбрал автопредложение при работе с ИНН: пользователь не должен помнить о существовании функции. Он вводит ИНН в своём обычном сценарии — система обнаруживает банкротство хотя бы у одного филиала и предлагает распространить статус.

Альтернативы

  • Отдельный раздел «Массовые операции» — обнаруживается только теми, кто про него знает; сценарий возникает по факту обнаружения банкротства, а не по плану
  • Действие в карточке компании — привязывает массовую операцию к одному филиалу, что концептуально неверно

Проверка: опрос и сбор обратной связи, 12 участников

Решение 2

Контроль вместо скорости

Было: запрос на полную автоматизацию — обнаружили банкротство, разослали по сети без участия человека.

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

Альтернативы

  • Мгновенное применение с undo — откат пакетной операции технически не поддерживается, а данные критичны для финансовых решений
  • Модальное «Подтвердить?» с числом компаний — формально закрывает требование, но пользователь подтверждает вслепую

Проверка: модерируемое коридорное тестирование, 7 участников — по итогам остановился на окне с информацией о филиалах, на которые будет распространено банкротство

Решение 3

Прозрачность выполнения

Массовая операция без обратной связи — источник тревоги: пользователь не знает, применилось ли всё. Спроектировал отображение прогресса с количеством обработанных компаний.

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

Прогресс распространения банкротства
Прогресс выполнения с количеством обработанных компаний

Компромисс

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

Безопасность требование отклонила: массовое необратимое изменение критичных данных не должно происходить без явного подтверждения оператора. Я не стал искать обход и переработал сценарий в полуавтоматический — с обязательным просмотром списка и подтверждением.

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

Проверка

До релиза Коридорное тестирование, 7 участников — по результатам добавили в окно информацию о компаниях
После релиза Опрос менеджеров, 12 человек — время оценивали сами пользователи

Другие фичи

Форма создания клиента: поля, которые нельзя убрать

Смотреть

Управление доменами данных и AI-пространство

Смотреть

Расскажу детали, которые не попали в описание

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

К кейсу