1508
Чек-лист: пять шагов успешной миграции системы автоматизации взыскания
Шаг 1: определите цели внедрения и структуру команды
Важно четко формулировать цель, чтобы она была понятна и бизнесу, и ИТ-партнеру. Как правило, у цели есть несколько уровней. Верхний – это общее обозначение, которое задает основной вектор. Например, импортозамещение или замена системы. Кажется, что речь в обоих случаях идет о переходе с одного решения на другое. На деле импортозамещение предполагает миграцию на отечественный аналог того же уровня, а замена системы подразумевает использование более функционального и гибкого ПО. Чтобы итог полностью соответствовал интересам, нуждам и запросам компании, необходимо разобрать их еще на старте проекта.
Верхнеуровневая цель раскладывается на несколько составляющих. Происходит детализация шагов, необходимых для достижения результата. Так, например, при замене ПО важно сохранить и расширить функциональность, обеспечить интеграционное взаимодействие со смежными системами, выполнить миграцию данных и обучить сотрудников отдела взыскания работе с новым решением. Для каждой из этих целей формулируются свои задачи и назначаются ответственные.
Со стороны банка в проект включаются представители всех подразделений, которые вовлечены в миграцию на новое ПО: отдел взыскания, ИТ-команда, помогающая адаптировать запросы бизнеса под возможности организации, а также специалисты, которые отвечают за закупку и обслуживание инфраструктуры. Полный список участников зависит от размеров банка: чем он крупнее, тем больший уровень кастомизации решения ему нужен и тем больше департаментов будут влиять на принятие решений.
Кроме того, заметную роль играет наличие и вовлеченность в проект спонсора или держателя бюджета. Если его нет или он не погружен в проект, управляющие комитеты – регулярные совещания, участие в которых принимают руководители, связанные с проектом, – будут малоэффективны. При возникновении существенных разногласий в команде именно спонсор принимает решение.
Шаг 2: распишите основные этапы внедрения и выберите оптимальный путь
Сегодня с учетом геополитической конъюнктуры речь обычно идет не просто о внедрении новой системы, а о замене старой. В этом случае финансовая организация может пойти по одному из двух основных путей.
I.Единовременный переход
Речь идет о ситуации, когда одна система полностью заменяется другой в сжатые сроки. Такой подход сокращает переходный период, упрощает управление масштабным проектом и позволяет тратить меньше ресурсов на синхронизацию данных и поддержку, поскольку не нужно одновременно обслуживать оба решения. У такого подхода есть и существенные недостатки: высокий риск ошибок и невозможность вернуться к работе в старой системе.
II.Поэтапный переход
Обычно используется в случаях, когда процессов в текущей системе действительно много или за миграцию отвечает небольшая команда. При определении этапности перевода процессов в новую систему банк может использовать различные критерии. Например, количество пользователей или число зависимостей от других систем. Во втором случае замену начинают с процессов, которые слабее других взаимодействуют со смежными платформами и сервисами.
Для бизнеса особенность поэтапного подхода состоит в том, что проект будет более продолжительным: вместо 3-6 месяцев изменения растягиваются на несколько лет. ИТ-отделу сложнее управлять сразу двумя системами, а затраты на поддержку возрастают вдвое. Увеличивается и нагрузка на сотрудников – из-за необходимости в доработке предыдущего решения для синхронизации данных между старым и новым инструментами.
Получается, на выбор подхода влияет количество и сложность процессов, число зависимостей между ними, размер команды и бюджета. Если речь идет о крупных ИТ-проектах, с инвестициями более 10 млн рублей, банку необходимо провести предпроектное обследование. Оно помогает четко определить границы проекта и детализировать необходимые работы: понять текущее положение вещей, проанализировать задачи и ограничения, распределить роли.
Банк может провести предпроектное обследование своими силами, но это несет определенные риски: человек «изнутри» воспринимает многие этапы взыскания как данность и не подвергает их критике. Из-за этого он, во-первых, может опустить важные детали при формулировании требований, а во-вторых, не увидит узких мест и пространства для оптимизации. Взыскание отличается от других направлений работы банка своей многослойностью: в рамках процесса объединены и раннее дистанционное взыскание, и взаимодействие с судами. А потому доверить обследование лучше ИТ-партнеру – так компания получит взгляд на все многообразие процесса взыскания со стороны.
Запланировать обследование нужно еще на старте: зафиксировать с топ-менеджерами и спонсором целеполагание, детализировать объем работ. Обычно стоимость подготовительного этапа составляет около 10% от суммы внедрения решения.
Шаг 3: реализация процессов в новой системе
Первое, чему важно уделить внимание, – критичные для бизнеса процессы (например, фиксация взаимодействия с клиентами, загрузка и актуализация данных, работа со стратегией взыскания) в новой системе должны быть реализованы так же, как было до миграции. Любые изменения в механике могут сказаться на эффективности и экономии, поэтому необходимо обеспечить абсолютную бесшовность перехода.
К некритичным процессам можно относиться как к MVP – важно сохранить необходимый минимум функциональных возможностей. При этом то, каким именно образом разработчики реализуют эти возможности, не играет существенной роли. Чтобы сделать процесс перехода успешным, ИТ-команде лучше за некоторое время до промышленной эксплуатации предоставить бизнес-заказчику работающий прототип. На нем можно провести пилотирование, собрать от пользователей обратную связь и внести необходимые изменения.
Если раньше обучение специалиста взыскания занимало пару недель, то сегодня банки стремятся сделать интерфейс максимально доступным и интуитивным, чтобы новый сотрудник как можно быстрее приступил к работе. Поэтому важно интегрировать пользователей в процесс разработки – их обратная связь поможет улучшить UI. Кроме того, работа с прототипом помогает конечным пользователям привыкнуть к изменениям и уменьшает шанс неприятия новой системы на финальной стадии.
Этап пилотирования часто вызывает сложности: менеджмент отказывается тестировать систему, функциональность которой не реализована в полной мере. Технологический партнер, ответственный за проект, должен разъяснять, почему работа даже с прототипом критически важна для получения желаемого результата.
Шаг 4: определение метрик для новой системы
Чтобы участники на протяжении всего проекта могли отслеживать прогресс, необходимо разработать метрики. Допустим, оператор отдела взыскания тратит на старт звонка с должником в CRM-системе три секунды – это много или мало? Как быстро происходит соединение? Сколько времени у сотрудника занимает путь от поиска клиента в системе до звонка ему? Для каждого процесса важно понять целевые значения – с опорой на текущее положение вещей и запросы бизнеса, – чтобы у ИТ-команды было понимание, какого результата она должна добиться.
В случае с опытно-промышленной эксплуатацией оценивается эффективность процесса целиком, а не его частностей. Иными словами, не сколько времени уходит на разговор, а сколько звонков сотрудник успевает совершить за час или день. Если в ходе тестирования становится понятно, что это значение устраивает руководителя отдела взыскания, процесс можно считать успешно внедренным.
Беспорядок в данных иногда встречается даже в компаниях с высоким уровнем data-культуры: это особенность работы с большим количеством информации. При миграции из одной системы на другую необходимо задать показатель, при котором переход на новое ПО можно считать успешным, – например, команде удалось перенести 90% от общего объема данных.
Кроме того, есть два важных инструмента, позволяющих минимизировать риски проблем на промышленном контуре. Это использование предпромышленного контура и контура для нагрузочного тестирования. И то, и другое – это «песочницы», которые имитируют работу системы. В первом случае речь идет о пилотировании процессов – как поведет себя инфраструктура, если перейти на новую стратегию или, например, изменить формулы расчетов. Такое тестирование позволяет предотвратить порчу данных в основной системе. Во втором – о тестировании отказоустойчивости решения и его способности стабильно работать под высокой нагрузкой.
Нагрузочное тестирование следует проводить, если у компании много пользователей или процедур со сложными расчетами. В противном случае система в промышленной эксплуатации может просто не выстоять с точки зрения производительности.
Шаг 5: обучение персонала
Метрика, которую сложно оценить на этапе тестирования системы, – это удовлетворенность конечных пользователей: сотрудников отдела взыскания. Чтобы повысить этот показатель, людей необходимо обучать. Например, проводить встречи и мастер-классы, рассылать инструкции и руководства, причем в понятном и наглядном формате. Кроме того, в первое время у сотрудников неизбежно будут возникать вопросы – важно оперативно на них реагировать и давать развернутые ответы, а также обновлять библиотеку полезной информации.
При этом основное внимание необходимо уделить обучению тех, кто занимается администрированием системы автоматизации взыскания: им потребуются консультации разработчиков из ИТ-команды партнера, чтобы в будущем эффективно пользоваться всеми возможностями новой системы.
Когда завершились все этапы разработки и тестирования, метрики соответствуют желаемым, а персонал прошел обучение и дал положительную обратную связь, систему можно считать внедренной. Несмотря на то, что процесс сопряжен с некоторыми сложностями, грамотное планирование и слаженная работа команды помогут добиться успеха и прийти к желаемым бизнес-показателям.
