Гибкие IT-системы
01.10.2013 от Andrew
Можно бесконечно долго убеждать банкиров как важно иметь гибкую IT-систему, которая позволит быстро и на лету подстраиваться под быстроменяющиеся требования, но большинство верит, что все давно придумано за них и есть волшебные системы в которых вендор заранее предусмотрел все возможные нюансы в виде галочек, которые надо нажать.
На самом деле любые галочки отражают всего лишь чей-то предыдущий опыт и никак не могут предусмотреть всех ситуаций, которые могут возникнуть в будущем. И когда случается что-то новое процесс добавление новой галочки занимает некоторое время. Зачастую очень длительное. А теперь давайте рассмотрим ситуацию на примере того как действительно быстро можно поменять свою систему, если в ней кроме галочек от вендора есть и “программные” возможности кастомизации на стороне банка.
Вчера я получаю уведомление об отказе в операции по карте моей жены следующего содержания:
По Вашей карте проведена операция:
ОТКАЗ! Покупка товара/услуги
Причина: Лимит на снятие наличных будет превышен
Дата: 30/09 16:36
Карта: ***6789
Сумма: 2007.00RUB
Терминал: 432414, APTEKA RIGLA
Захожу в интернет-банк и вижу, что на самом деле превышен общий лимит ежемесячных расходов, установленный мной для дополнительной карты и в 17:30 пишу в банк письмо (благо в этом банке я общаюсь напрямую с многими людьми), что уведомление формируется неправильно – не учитывает тип лимита, который сработал. Через полчаса сотрудник банка мне ответил, что действительно в банке не реализован разбор параметров отклоненных авторизационных запросов и по любому поводу шлется одно и то же сообщение и пообещал подумать, что можно сделать. А сегодня в 11:35 я получил от него следующее письмо:
Я доработал функцию формирования сообщений по отклоненным транзакциям. На вчерашнюю транзакцию ты бы получил следующую причину:
Превышение лимита «Общий лимит расходов» на 1295.96RUB
Прошло всего несколько рабочих часов, в течение которых сотрудник, наверняка, занимался не только удовлетворением моего не самого для него приоритетного пожелания, но и более неотложными текущими задачами. Поверьте, реализовать какую-то новую схему комиссионирования или логики обращения к счетам клиентам в зависимости от условий совершения операции у него заняло бы примерно столько же времени.
Рубрики: Банковская розница, Банковские карты | 2 комментария »»»
07.10.2013 в 17:48
>> что уведомление формируется неправильно — не учитывает тип лимита, который сработал.
Т.е. человек за “несколько рабочих часов” переделал текст СМС но никак не логику работы лимитов, или я не вкурил? :-)
А вообще суть вопроса очень правильная. Действительно комиссионные схемы это всегда тяжело. Именно поэтому ключевой момент это наличие хороших разработчиков внутри банка – тогда все быстро и качественно. Как говорится плохому танцору…
07.10.2013 в 19:18
С лимитами изначально все было в порядке. Просто шаблон SMS-сообщения был настроен так, что формировал одно и тоже сообщение вне зависимости от того действительно ли на счету недостаточно средств или сработал один из финансовых лимитов. А лимиты не только предустановлены, но доступны для корректировки и создания новых/удаления существующих картхолдеру. Теперь SMS сообщение в случае нехватки средств уведомляет о нехватке денег, а а в случае срабатывания лимита информирует о том, что сработал именно лимит и называет его человеческим именем.