14 декабря, пятница 07:59
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

О статье РФК на iFin.ru

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • О статье РФК на iFin.ru

    Опубликованная в журнале "Банки и Технологии" ╧3 2001 и потом продублированная на www.ifin.ru статья "Дистанционное обслуживание клиентов: свобода выбора как осознанная необходимость" представителей ЗАО "РФК" (разработчика система Клиент-Банк), содержит достаточно большое количество очень спорных утверждений, с которыми я не могу согласится.

    Поскольку статья была представлена публично, позволю себе также публично высказать свою точку зрения по затронутым в статье вопросам и прокомментировать сделанные авторами из РФК утверждения.

    BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>За исключением нескольких "продвинутых" банков эта услуга ещё не стала массовой: дистанционным обслуживанием редко охвачено более 15-20% клиентов... Одна из причин √ всё ещё недостаточная информированность различных звеньев банковского менеджмента о свойствах и возможностях различных технологий дистанционного обслуживания, и как следствие неоптимальные управленческие решения по приобретению и внедрению систем.[/quote]

    Указанная авторами причина "о недостаточной информированности банковского менеджмента" - надумана.

    По моему исключительно субъективному мнению, основанному на общении с сотрудниками банков, отвечающих за продвижение услуг, основная причина низкого количества дистанционно обслуживаемых клиентов кроется:

    - либо в полном отсутствии в банках стратегии продвижения услуг удаленного обслуживания,

    - либо в ненадлежащем исполнении медиа-планов, разработанных в соответствии со стратегией продвижения услуг.

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

    Основной затык возникает именно с продвижением услуг.

    Для продвижения услуг удаленного банковского обслуживания, как и для продвижения вообще любых услуг и товаров, необходима стратегия. Основные пункты стратегии должны быть проработаны еще до выбора и внедрения системы. Должны быть определены:

    - стратегические цели (ради чего вообще всё затевается)

    - пути достижения (каким образом будем продвигать услуги)

    - сроки и планируемые результаты (к какому сроку и сколько клиентов в абсолютном и процентном исчисленьях должно быть привлечено к продвигаемой услуге)

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

    Внешней же частью любой стратегии продвижения услуг должен являться медиа-план. В составлении медиа-плана нет ничего особо сложного. Здесь как в "Аквариуме" В.Суворова - надо взять листок бумаги и написать план. План для себя, а не для руководства. План чёткий, реальный, по которому предстоит работать. На вскидку план как минимум должен содержать:

    - определение целевой аудитории, на которую будут направлены все рекламные мероприятия

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

    - разделение рекламных мероприятий на уровни. Как правило, присутствуют первичное информирование (баннеры, пресс-релизы, щитовая реклама, реклама на ТВ и в СМИ) и подробное информирование (рекламные материалы в виде брошюрок в банке, соответствующие разделы на Web-сайте банка)

    - Исходя из рекламного бюджета определение рекламных каналов (интернет, СМИ, щитовая реклама, ТВ и т.д.), прогнозирование эффективности каждого из каналов

    - График проведения рекламных мероприятий

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

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

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

    Возвращаемся к статье.

    BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>Теперь о подходах к созданию систем комплексного дистанционного обслуживания клиентов. Можно, конечно, приобрести, поставить и каким-то образом сопрячь различные системы разных производителей. Даже если это удастся, установка и обслуживание разнородных систем обойдётся значительно дороже, а их работа будет менее эффективной, чем использование интегрированной системы с единым банковским ядром.[/quote]

    IMHO, заблуждение. Я конечно понимаю, что автор стремится навязать так многими проповедуемую сладкую идеологию "комплексного подхода". Да я и сам, как разработчик банковского ПО, не прочь воспользоваться возможностью и подцепив на крючок Интернет-Банкинга очередной банк, продавать в дальнейшем этому банку дополнительные модули для обслуживания клиентов по различным каналам - WAP, SMS, Connected Limited-решения (PC, Palm, WinCE и т.д.), телефонию.

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

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

    Мудрым же решением является выбор систем, основанных на открытых стандартах, общеупотребимых платформах, использующих известные макроязыки для написания скриптов. Мудрым является выбор систем, использующих для интеграции с другими системами CORBA, XML и т.д. Именно тогда не будет сложностей интегрировать системы от различных поставщиков, именно тогда можно будет собирать свой уникальный (и самое главное удовлетворяющий поставленным задачам) вариант решения из модулей от различных разработчиков и не ломать голову над совместимостью.

    BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>Подходы к созданию ядра интегрированной системы также различны. Мы, например, сторонники использования единой промышленной базы данных (на базе Oracle) для работы со всеми группами клиентов независимо от канала связи с банком. Такой подход позволяет легко наращивать количество подсистем и функций по обслуживанию клиентов. А возможности Oracle и при большом количестве клиентов позволяют работать устойчиво и с высокой производительностью.[/quote]

    Выбор Оракла в качестве Сервера БД - достойный выбор. Но не всегда Заказчик готов использовать сию платформу. Одни (причем многие) потенциальные Заказчики тяготеют к решениям на платформе от Microsoft и соответственно к использованию в своих решениях сервера БД MS SQL. Другие стремятся использовать такой же Сервер БД, на котором работает АБС (к примеру Progress, SyBase или DB2/400 на AS/400). Третьи желают минимизировать свои издержки на системном софте и использовать для своих задач (порой и не слишком масштабных) PostgreSQL на Linux'е. Четвертые используют уже существующий и работающий в банке Сервер БД. В общем везде по-разному. Поэтому предоставление потенциальному Заказчику возможности выбора платформы для Сервера БД является исключительно конкурентным преимуществом.

    BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>Другой подход √ создание надстройки, инвариантной относительно используемой базы данных.[/quote]

    Считаю этот пассаж авторов оправданием выбранной двухзвенной идеологии своего Oracle-based решения. Подавляющая часть бизнес-логики в Oracle-based толстом Клиент-Банке от РФК (постоянно и гордо почему-то именуемым "платёжной системой") реализована в виде хранимых процедур на Оракле. Оставшаяся часть бизнес-логики реализована в клиенте, написанном на Borland C++Builder 4.5. Такой подход оправдан только если нагрузка не предполагает быть очень высокой. Иначе придется менять PC c Dual P-III 1GHz, 1Gb RAM и U3SCSI HDD, и переползать на что-то более производительное, уровня 4-х процессорного SunEnterprise 420R с 4Gb RAM и внешних RAID-массивом.

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

    BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>Но в таком случае до конца не используются возможности ни одной из СУБД, а использование интерпретаторов существенно снижает производительность.[/quote]

    Выводы об ущербности инвариантных к Сервер БД решений, о не использовании всех фич Серверов БД и соответственно более низкой производительности беспочвенны.

    Конечно же разработчики, в том числе и БИФИТ, в своих решениях заботятся о поддержке различных Серверов БД. Но это делается не в ущерб производительности. И многие фичи, свойственные конкретным Серверам БД, мы всё-таки стремимся использовать.

    Изречение авторов из РФК об использовании интерпретаторов и снижении производительности, по всей видимости, направлен в сторону Java

    Комментировать сие "мудрое" изречение не буду. Для желающих могу порекомендовать обсудить вопросы производительности и использования Java на серверной стороне в эхе RU.JAVA

    BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>Экономия получается небольшой, так как массовое распространение Oracle привело к существенному снижению его стоимости.[/quote]

    Заявление о массовом использовании Оракла и, как следствие, о снижении стоимости Лицензий на Оракл не выдерживает никакой критики. Оракл, один из самых дорогих Серверов БД. Чего только стоит Лицензионная политика при использовании Оракла в интернет-решениях

    BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>Ещё одна разница в подходах состоит в том, создаётся ли такая система как конечный продукт, с профессиональной поддержкой и гарантией, или представляет из себя некий "конструктор" для банковских автоматизаторов. Практика показывает, что при большой тяге наших законодателей и руководства ЦБ к постоянному совершенствованию жизни банковского общества любой универсализм недостаточен и всё равно приходится глубоко внедряться во "внутренности" программы, т.е. обращаться к разработчикам, которые, как правило, гарантируют актуальность своих систем в рамках сопровождения. "Конструктор" провоцирует банковских программистов на не всегда оправданные перманентные усовершенствования, порой приводящие к отказам системы и перебоям в обслуживании. При рассылке же разработчикам стандартных обновлений системы каждый раз требуется их доводка с учётом внесённых изменений.[/quote]

    Приведенная выше позиция авторов в отношении вопросов гибкости предлагаемых решений является по сути оправданием отсутствия в Клиент-Банке от РФК конструктора форм документов ну и камнем в сторону конкурентов из Банк'с Софт Системс

    В РФК никогда не было и никогда не планировалось вводить в "Клиент-Банк" конструктор форм. Уж больно это серьезная и основательная задача. Да и деньги за эти доработки брали с банков отдельные.

    На отделе же внедрения и суппорта РФК этот зоопарк версий сказывался основательно. Количество возимых установщиками дистрибутивов различных версий было как минимум пять

    На сколько успешно разработчики из БСС справились с задачей встраивания конструктора документов в свой классический Банк-Клиент могут судить сотрудники банков, пользующиеся данной фичей. Ну а большое количество продаж BS-Client 2.0 подтверждение в том числе и востребованности конструктора документов.

    Судя по поступающим к нам в БИФИТ предложениям о доработке существующих форм документов и встраивании новых форм, возможность самостоятельной модификации и добавления форм реально востребована банками.

    BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>Любая сверхуниверсальность, сверхгибкость и многоплатформенность √ обычно не что иное, как стремление создать мнимую привлекательность за счёт внешней эффектности. Большинство из предоставляемых широких возможностей практически не используется. Впрочем, у каждого есть свобода выбора.[/quote]

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

    С уважением, Репан Димитрий
    Компания "БИФИТ" - www.bifit.com
    С уважением, Репан Димитрий
    Компания "БИФИТ" - www.bifit.com

  • #2
    Димитрий,
    мне кажется, на этом форуме все уже всё поняли. Самый тонкий клиент, как и самый длинный маркетинг, конечно же, у Вас ;-). По-моему, уже пора Вам, как и РФК, переносить дискуссию в офлайновые СМИ. Они опубликовались в "Банках и технологиях" -- а Вы напечатайтесь в "Банковских технологиях". Кстати, если убрать из Вашего постинга прямую полемику с РФК, то может получиться вполне пригодная для печати статья.

    Желаю удачи!
    Александр Евтюшкин

    Комментарий

    Пользователи, просматривающие эту тему

    Свернуть

    Присутствует 1. Участников: 0, гостей: 1.

    Обработка...
    X