Дистанционное обслуживание клиентов: свобода выбора как осознанная необходимость
Николай Кузнецов, генеральный директор ЗАО "РФК" (Москва) Илья Митричев – зам. генерального директора ЗАО "РФК" (Москва)
В настоящее время большинство российских банков уже предоставляют своим клиентам те или иные дистанционные услуги. Хотя этот процесс шёл в последние годы довольно бурно, он далёк от завершения. За исключением нескольких "продвинутых" банков эта услуга ещё не стала массовой: дистанционным обслуживанием редко охвачено более 15-20% клиентов. А опыт передовых в этом отношении банков показывает: при правильном выборе системы и активной маркетинговой политике не только снижаются удельные затраты на РКО, но и существенно возрастают доходы от оказания услуг клиентам. Почему же так происходит? Одна из причин – всё ещё недостаточная информированность различных звеньев банковского менеджмента о свойствах и возможностях различных технологий дистанционного обслуживания, и как следствие неоптимальные управленческие решения по приобретению и внедрению систем. Попробуем осветить некоторые моменты, которые позволят сделать осознанный выбор. Сейчас в банках используются три основных типа систем дистанционного обслуживания. Это, во-первых, системы типа "", появившиеся почти десять лет назад и превратившиеся в настоящее время мощное средство электронного документооборота с большими сервисными и аналитическими возможностями. Во-вторых, это телефонные информационно-платёжные системы с гибко настраиваемыми функциональными возможностями – от автоматизированной справочной голосовой службы до управления счетами клиентов. И, наконец, в-третьих, on-line интернет-технология, которая в отличие от традиционного "Клиент-Банка" позволяет клиенту связываться с банком с любого компьютера в любой точке мира (работает без специализированного программного модуля на стороне клиента). К тому же интерактивность Интернета позволяет в реальном времени создавать документы и контролировать результаты их обработки. Каждый из этих каналов дистанционного обслуживания рассчитан на различные потребности клиентов: они не заменяют, а дополняют друг друга. Чтобы удовлетворить требования всех групп клиентов, банку необходимо иметь все эти каналы. Подобные системы предлагаются как специализированными фирмами по разработке систем дистанционного обслуживания, так и фирмами – разработчиками АБС. Кроме того, какое-то количество банков использует системы собственной разработки. Однако опыт показывает, что внутри одного банка трудно накапливать опыт и отслеживать тенденции в этой области, и нередко возникают неразрешимые проблемы при уходе хотя бы одного ключевого специалиста. Кажущаяся "бесплатность" своих систем оборачивается значительными внутренними издержками или низким качеством обслуживания клиентов. А глубокое знание всех тонкостей собственной системы и возможность её авторской модернизации повышает вероятность злоупотреблений. При этом банку будет весьма трудно разрешить конфликтные ситуации или делегировать ответственность разработчику. Что касается фирм – разработчиков АБС, то за редким исключением разработки систем дистанционного обслуживания проводятся по остаточному принципу и слишком сильно связаны с особенностями (в том числе и ограничениями) АБС. Поэтому при смене АБС приходится менять и всю систему обслуживания клиентов, что кроме финансовых затрат создаёт проблему непрерывности обслуживания. И некоторые разработчики АБС уже пришли к выводу, что эффективней иметь партнёрские отношения со специализированными фирмами, чем вести разработку всех типов систем дистанционного обслуживания. Теперь о подходах к созданию систем комплексного дистанционного обслуживания клиентов. Можно, конечно, приобрести, поставить и каким-то образом сопрячь различные системы разных производителей. Даже если это удастся, установка и обслуживание разнородных систем обойдётся значительно дороже, а их работа будет менее эффективной, чем использование интегрированной системы с единым банковским ядром. Подходы к созданию ядра интегрированной системы также различны. Мы, например, сторонники использования единой промышленной базы данных (на базе Oracle) для работы со всеми группами клиентов независимо от канала связи с банком. Такой подход позволяет легко наращивать количество подсистем и функций по обслуживанию клиентов. А возможности Oracle и при большом количестве клиентов позволяют работать устойчиво и с высокой производительностью. Другой подход – создание надстройки, инвариантной относительно используемой базы данных. Но в таком случае до конца не используются возможности ни одной из СУБД, а использование интерпретаторов существенно снижает производительность. Экономия получается небольшой, так как массовое распространение Oracle привело к существенному снижению его стоимости. А наличие в стандартной поставке Oracle WebDB сокращает затраты на интернет-компоненту системы. Ещё одна разница в подходах состоит в том, создаётся ли такая система как конечный продукт, с профессиональной поддержкой и гарантией, или представляет из себя некий "конструктор" для банковских автоматизаторов. Практика показывает, что при большой тяге наших законодателей и руководства ЦБ к постоянному совершенствованию жизни банковского общества любой универсализм недостаточен и всё равно приходится глубоко внедряться во "внутренности" программы, т.е. обращаться к разработчикам, которые, как правило, гарантируют актуальность своих систем в рамках сопровождения. "Конструктор" провоцирует банковских программистов на не всегда оправданные перманентные усовершенствования, порой приводящие к отказам системы и перебоям в обслуживании. При рассылке же разработчикам стандартных обновлений системы каждый раз требуется их доводка с учётом внесённых изменений. Любая сверхуниверсальность, сверхгибкость и многоплатформенность – обычно не что иное, как стремление создать мнимую привлекательность за счёт внешней эффектности. Большинство из предоставляемых широких возможностей практически не используется. Впрочем, у каждого есть свобода выбора.
