Партнерство банка и IT-компании

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

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

Факторы успеха

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

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

Создание конкурентных преимуществ в области PR–фактора или общедоступного за деньги блока — «Технические возможности» выходят за рамки настоящей статьи, но для удобства изложения, ниже будем называть их вместе «базовые преимущества».

Принимая во внимание, что организовать новые возможности в области базовых преимуществ — дело полезное, но не простое, — можно найти источник преимуществ в правильном выборе АСРБ. Что же важно при выборе АСРБ для банка, с имиджем и деньгами? Согласно канонам маркетинга, оттолкнемся от интересов клиентов банка. Что нужно клиентам банка? Это не сложно, им нужно, чтобы было быстро, удобно, выгодно, всегда и везде, но интерпретация этих слов банком должна зависеть от контекста конкретной рыночной ситуации.

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

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

Успешные в рознице банки демонстрируют новаторство на рынке банковских продуктов и услуг.

Своя команда или IT-компания?

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

Модификация может выполняться и собственной командой разработчиков, но ориентация банков на свою команду ослабевает по ряду причин. Первая — примеры болезненных переходов на коммерческие отношения между банком и новым предприятием, созданным бывшими сотрудниками IT-подразделения банка. Фактическое владение новой компанией уникальным программным продуктом делает это сотрудничество вынужденным, но, естественно, непродолжительным.

Вторая — принципиальное отсутствие у коллективов собственных разработчиков, одновре-менно отвечающих за работоспособность действующей системы, стимулов к ее развитию по требованиям бизнеса. Объективно, IT-подразделения заинтересованы в мероприятиях направленных на повышение надежности, быстродействия, масштабного повышения качества. На этом фоне «мелкие вопросы» текущих изменений по требованиям бизнеса вызывают раздражение.

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

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

Механизм развития системы

Банки, настроенные на успех в рознице, заинтересованы в создании новых продуктов и услуг в диктуемом рынком темпе. Однако, показатели этой динамики могут радикально различаться в зависимости от применяемого механизма модификации системы.

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

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

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

Наряду с задачами обновления номенклатуры банковских продуктов и услуг, возникают задачи интеграции с другими системами, импорта базы данных купленного банка, эксплуатации системы в условиях слабой инфраструктуры связи. Расширение диапазона укрепляет уверенность IT-компаний в целесообразности предложения банкам услуг ведения индивидуальной версии. Однако, не обладая технологией приспособленной к одновременному ведению ряда уникальных версий, производители тиражных продуктов невольно искажают понятие индивидуальной версии. Так называемое VIP-обслуживание тиражных продуктов, допускающее модификацию систем по заказу банка, вступает в сложное взаимодействие с отработанной технологией производства. Это обстоятельство проявляется в затруднениях в формулировании различий «простого» и VIP-обслуживания.

Свобода банка в развитии розничного бизнеса прямо связана с применяемой технологией развития АСРБ.

Практика партнерства

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

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

Бесперебойное выполнение пожеланий, имеющих статус задания со сроком выполнения, требует преобразований на административном уровне:

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

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

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

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

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

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

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

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

Резюме

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

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

Публикация 2004 года в четвертом номере журнала «Банки и технологи» в рубрике Банковские системы. Автоматизация розничного бизнеса. Тенденции рынка.