Анна Чернобыльская: Сменить АБС – это не один пожар, а целых два пожара. Поэтому, как правило, причин для смены системы не одна, а несколько.
Существуют различные сценарии смены АБС.

Наиболее логичный – когда банк «вырастает» из существующего решения. Как правило, это связано с устаревшей архитектурой. Непромышленная СУБД, не поддерживается централизованная работа, нет настраиваемого документооборота, закрытое решение, устаревший интерфейс, и.т.д.

В этой ситуации смена АБС необходима, и цена перехода тем выше, чем больше банк затягивает неприятное решение. Потому что если АБС уже начала «жать» банку, это означает, что банк растет. Это, конечно, хорошая новость. Но. Рост означает все больше задач для ИТ, параллельно проблемы с АБС продолжают накапливаться. Часть задач реализуется банком самостоятельно, причем эти решения рассматриваются ИТ-службой как временные, что, конечно, влияет на их качество.

В результате, к моменту, когда банк примет решение о внедрении новой АБС, накопится масса проблем – от недовольства пользователей до значительного числа недокументированных изменений в текущей АБС. В результате как выбор АБС, так и само внедрение проходят в условиях цейтнота. Иногда проблемы, связанные с этим, можно минимизировать. Но обычно такая экстремальная замена АБС ведет к убыткам для банка. Самое обидное, что часто возможности, заложенные в новом решении, банк не может из-за такого «скомканного» внедрения использовать.

Немного другая ситуация, когда банк категорически не устраивает функциональность АБС. Как и со случаем устаревшей архитектуры, эта нехватка функциональности связана с ростом банка и является для него существенной проблемой (в короткой перспективе может быть критичнее, чем устаревшая архитектура). Но тут уже больше зависит от действий самого разработчика – функциональность АБС, в отличие от архитектуры, можно и нужно наращивать. И банк тоже внимательно смотрит не только на текущую функциональность, но и на ее динамику, особенно в интересующих банка направлениях.

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

А вот то, будет ли банк менять при смене АБС и разработчика – это вот как раз зависит от качества поддержки. Только это не просто «качество поддержки», а партнерские отношения с клиентом, как не замылено это слово.

Реализует ли компания бесплатно заявки своих клиентов или ждет, пока кто-то не выдержит и заплатит? Как ведет себя, если начинаются проблемы c ИТ-решением (как правило, непонятно, по чьей вине)? Умеет ли искать оптимальное решение в том случае, когда бизнес-подразделения банка и ИТ не могут договориться? Может ли предоставить индивидуальное обслуживание каждому банку – а «индивидуальное» - это именно такое, в котором банк нуждается? Насколько быстро разработчик развивает функциональность используемой банком АБС, или основные инвестиции направляются в новое решение, на котором можно больше заработать за счет перевода клиентов на новые версии?

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


АБЖ: Может ли банк отложить переход на новую систему «до лучших времен»? Может ли разработчик помочь с этим банку?

Анна Чернобыльская: Отсрочить смену АБС довольно часто можно достаточно легко. Как правило, есть накопившиеся самые острые проблемы, их можно оперативно решить (бесплатно или за символическую цену). Более того, эти проблемы, скорее всего, мучают и других клиентов, так что разработчику это в любом случае стоило бы сделать. Многие вендоры не предпринимают этих минимальных мер ровно потому, что им выгоднее фокусироваться на крупных клиентах, где совсем другие цифры доходов. Мелкие и средние банки обслуживаются по остаточному принципу – их запросы на доработки реализуются в последнюю очередь, работы в них выполняют наименее опытные сотрудники и др.

Но рассмотрим вендора, который заботится о каждом своем клиенте. Решить назревшую проблему с текущей АБС, как правило, вполне реально и даже не очень трудоемко. Реализовать наиболее востребованные доработки, сменить индивидуального менеджера, снизить цену сопровождения. В более серьезных случаях необходимо провести комплексный аудит, настроить в АБС правильный документооборот, добавить необходимые отчеты, состыковать с внешними решениями – и она заработает «как новенькая», а вопрос о смене снимется с повестки дня совсем. Чаще всего такой сценарий «вы просто не умеете правильно использовать наше решение» случается при смене ИТ-команды банка.

Но во многих других случаях смена АБС необходима, и, как было изложено выше, если банк объективно вырос из используемого решения, то не стоит затягивать вопрос с его заменой.

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

Однако в жизни часто получается по-другому. Банк (обоснованно) не верит разработчику и при наличии проблем втихую начинает искать другое решение, а разработчик узнает о смене АБС только по получении письма, что клиент отказывается от сопровождения, поскольку уже сменил систему. Разработчику это, понятно, невыгодно, но и банку не всегда.

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

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


АБЖ: Насколько долго банк может работать на старой системе?

Анна Чернобыльская: Стандарты рынка по поводу срока жизни решения меняются со временем. Еще 10 лет назад формулировалось, что «АБС живет пять лет». Но это потому, что в 90-е средний срок перехода был месяц-два, переход, как правило, был тиражным – и это был «хвост иллюзий» 90-х.
Сейчас, думаю, каждый банк, меняя решение, планирует использовать его, как минимум, в течении 10 лет.

Выход для разработчика в том, чтобы, создавая новую АБС, использовать все имеющиеся на данный момент технологии. Например, нашей АБС «Гефест» 15 лет. Но она создавалась на самых современных технологиях того времени (централизованная архитектура, настраиваемый документооборот, полностью открытый код и другие). Благодаря этому у большинства клиентов «Гефеста», перешедших на нее 12-13 лет назад, нет потребности в смене АБС.

Хотя некоторым из них уже требуются технологии нового поколения (настраиваемый эргономичный интерфейс, разделение прикладного и системного кода, погружение в данные при формировании отчетности и т.д.). Эти технологии реализованы в АБС «Центавр Омега», решении нового поколения, которое использует уже свыше 30 банков. Поэтому когда нашим клиентам «Гефеста» понадобится такое решение, они смогут перейти на него с минимальными издержками и сложностями.


АБЖ: Не проще ли вместо полной замены АБС купить и внедрить небольшое решение с требуемым функционалом?

Анна Чернобыльская: Вопрос в том, какому банку проще. Для формирования многих форм отчетности для Центрального банка (например, 128, 129, 135, 302 формы) требуется информация по разным направления деятельности банка: и по кредитным договорам, и по сделкам с ценными бумагами, и по операциям с пластиковыми картами. А вопрос с регламентированной отчетностью, с учетом текущей ситуации, достаточно критичен для любого банка.
Крупные банки для формирования регламентированной отчетности используют специализированные Хранилища данных, куда они загружают информацию из различных ИТ-решений. В этом случае подход best of breed оправдан.

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

Не случайно в майской статье Вашего журнала «АБС для среднего банка: от архитектуры до поддержки» большинство представителей банков сказали, что предпочтут иметь интегрированную систему от одного поставщика «Затраты на настройку, сопровождение, интеграцию различных решений несопоставимо выше, чем издержки при использовании пусть не самого лучшего, но интегрированного решения, даже если не учитывать финансовые аппетиты поставщиков лучших решений и затраты на оборудование. Банк не готов пустить всю свою прибыль на красоту технического решения».
Другое дело, что одновременно переводить все блоки с одной АБС на другую – это безумие. Тут поставщик должен не только предложить банку схему поэтапного перевода различных бэк-офисов, но и обеспечить этот переход. Например, банк «Камский горизонт», недавно перешедший на АБС «Центавр Омега», в качестве бэк-офиса для пластиковых карт использует другое решение. Но для полноценного формирования отчетности в «Омеге» была предусмотрена специальная плоскость учета, позволяющая связывать аналитический и синтетический учет по счетам пластиковых карт.

В другом банке осуществлялся поэтапный переход на АБС различными филиалами банка. Для этого мы создали специализированный шлюз, позволяющий формировать сводную отчетность, используя часть данных из другой АБС. Есть банки, в которых сначала был внедрен определенный бэк-офис, это позволяет банку оценить нас, как поставщика, перед принятием глобальных решений.


АБЖ: Стандартный подход к внедрению ИТ-систем предусматривает проведение обследования, разработку ТЗ, и плохо работает в быстро меняющихся компаниях. Как снизить риски внедрения в современном динамичном мире?

Анна Чернобыльская: Каскадное внедрение предусматривает сначала создание детально проработанного ТЗ, потом его согласование с заказчиком, а потом, собственно, работы в полном соответствии с созданным документом. Такой подход имеет свои плюсы. Он формализует, что получит на выходе клиент и сколько он за это заплатит разработчику.

Но в последние годы резко изменилась мобильность всех отраслей бизнеса, и банки не исключение. А это значит, что к моменту окончания внедрения ТЗ банально устаревает, и в результате банк получает вовсе не то, что хотел, хотя решение формально соответствует ТЗ. Кроме этого, растут требования пользователей, им уже нужно не только решение, соответствующее бизнес-процессам, но и удобное, а сформулировать это заранее в ТЗ далеко не всегда возможно.

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

Понятно, что в крупных и крупнейших банках (например, ВТБ или НКЦ) мы выполняем внедрение каскадным способом на основе детализированного ТЗ. Там совсем другой уровень формализации и документирования бизнес-процессов и более централизованная система управления.

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

Такой подход мы использовали при внедрении системы централизованного управления бизнеса в финансовых группах «Ренессанс Групп» и «ВТБ Капитал». На первом этапе была выстроена система оценки финансовых результатов различных подразделений. Практический результат позволил в дальнейшем развивать решение в различных направлениях (возможность перехода к детальным данным, новые аналитические разрезы, Score-Card для менеджмента).

Думаю, сейчас такая технология актуальна и для CRM-систем. Сначала отдельный блок с конкретной отдачей для бизнеса (в большинстве случаев это кредитный конвейер), потом поэтапное внедрение комплексного CRM-решения (как правило, параллельно с внедрение CRM-подхода в банке).

Практика более десятка наших последних проектов показывает, что итерационный подход применим для большинства банков. В первую очередь, он позволяет быстро реализовывать проекты. Например, в этом году «Фреско-банк» перешел на АБС «Центавр Омега» за 4 недели. В прошлом внедрения в КБ «Радиан» и НКО «ЮМани» потребовали всего по 2 месяца на выполнение.

Но дело не только в скорости, особенно когда ИТ-проект должен решать конкретные вопросы бизнеса. Например, недавний проект по внедрению кредитного конвейера в банке «Актив». В середине лета началось внедрение, и в сентябре кредитный конвейер в банке начал работать. Но после запуска банк увидел, что именно его не устраивает. За несколько итераций решение было доработано под требования банка, и к началу ноября банку получил бизнес-результат – смог обрабатывать втрое больше кредитных заявок без увеличения количества персонала. В целом, итерационный подход позволяет решать вопросы бизнеса и ИТ в более тесной связке, поскольку одновременно с внедрением ИТ-решения могут корректироваться бизнес-процессы, уточняться продуктовый ряд и др. При классическом внедрении это проблематично – все бизнес требования должны быть формализованы до конца обследования.

Источник: АБЖ №12 (214) декабрь 2013,