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

Поставщик говорит: «В нашей системе реализована идеология работы операциониста "в одном окне"».

Что в действительности?

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

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

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

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

Поставщик говорит: «Наша система гибко настраивается с помощью конструкторов».

Что в действительности?

Довольно часто этим термином производители программ называют вещи, никакого отношения к конструкторам не имеющие.

• Скриптовой язык (чаще всего Visual Basic), с помощью которого можно создать окно либо задать новый алгоритм формирования проводок. Называть библиотеки Visual Basic конструктором не совсем корректно. По сути, это кусок исходного кода программы, который можно дописывать. Для настройки «тяжелой» бизнес-логики, скорее всего, придется освоить программирование на SQL.

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

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

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

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

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

Совокупные затраты на одного программиста в Москве составляют не менее $2500 в месяц

• Собственно конструкторы. Мне известны конструкторы двух видов для настройки интерфейсов и для настройки бизнес-логики работы (деление зачастую условное). С моей точки зрения, конструктор имеет следующие отличительные признаки:

  а) настраивается специалистом в предметной области и не требует специальных навыков программиста, т. е. настраивается в терминах предметной области;

  б) имеет наглядные средства для добавления новых терминов в предметной области без дополнительного программирования.

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

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

Дотошный читатель спросит: а что если банку не хватит параметров, выведенных поставщиком в условие или в действие?

Вполне резонное замечание! Конструктор должен быть расширяем по параметрам без больших усилий - по крайней мере, без написания какихлибо программных процедур.

На мой взгляд, вся основная логика, получившаяся как результат настройки конструкторов, должна храниться на сервере базы данных в виде хранимых процедур. Соответственно, современные конструкторы должны обеспечивать автоматическую компиляцию результатов своих настроек в текст хранимых процедур базы данных. Мало того, для обеспечения высоких скоростей работы с большими объемами данных (а куда без этого в ритейле?) компиляция должна быть реализована с глубоким пониманием специфики конкретной СУБД!

Поставщик говорит: «Наши решения строятся на одной технологической платформе».

Что в действительности?

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

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

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

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

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

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

Шесть рекомендаций 

Совокупная стоимость владения «За копейку канарейку:»

Не забывайте, что стоимость программной системы - это лишь один из факторов принятия решения. Гораздо большее значение имеет, на наш взгляд, совокупная стоимость владения (TCO, Total Cost of Ownership).

Если вы покупаете дешевое решение, возможно, вы сэкономите на первоначальных вложениях, но в перспективе все может оказаться не так радужно. Относитесь с известной долей иронии к таким заявлениям поставщика, как «наша система установлена в 500 банках, поэтому она хорошо обкатана и работает стабильно».

Любая сложная система нуждается в осмысленном ежедневном сопровождении - это факт. Вопрос в том, кто будет нести на себе основную тяжесть сопровождения?

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

Если ответы отрицательные, лучше планировать в своем штате дополнительные рабочие места.

Стоит очень серьезно отнестись к тому факту, что совокупные затраты на одного программиста в Москве (с учетом зарплаты, налогов, социальных выплат, аренды и так далее) составляют как минимум $2500 в месяц.

Подсчитайте, сколько банк потратит в течение, например, трех лет на покупку и сопровождение системы, но только с учетом стоимости труда своих сотрудников!

Время обслуживания клиента «Эй, моряк, ты слишком долго плавал:»

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

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

Время добавления новых продуктов «Дорого яичко ко Христову дню»

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

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

Она абсолютно непрозрачна. Только программисты могут «читать» программный код, и только для них он чтолибо значит, причем в том случае, если хорошо написан и откомментирован.

И с каждой сменой программиста такие «настройки» имеют серьезные шансы захромать.

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

Отзывы банков о поставщике ритейла «Парень, в общем, неплохой, только рябый, да глухой»

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

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

Вы уверены, что после покупки системы у вас не возникнет проблем со службой поддержки? И даже в этом случае стоит очень внимательно расспросить коллег из банков, которые уже имеют удовольствие (или наоборот?) общения со службой поддержки данного поставщика.

Набор модулей и выбор поставщиков «Не все то золото...»

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

Гораздо правильнее купить лучшие модули у компаний, которые хорошо зарекомендовали себя на рынке именно в данной области.

Профессионалы вполне в силах один раз состыковать модули разных поставщиков - так сейчас работает большинство как российских, так и западных банков.

Определение необходимой функциональности «Cколько вешать в граммах?»

Определитесь с тем, какие именно продукты вы хотите предложить своим клиентам.

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

Скорее всего, вам снова придется тратить деньги и время для повторной покупки того же модуля либо у того же поставщика (из его новой линейки продуктов), либо у другого.