Chirkov.net: блог

Андрей Чирков
август 2006 года

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

Россия – страна процессинговых центров.

Эта расхожая в карточной среде фраза близка к истине. Так уж повелось, что у нас в стране каждый более-менее крупный банк желает иметь свой собственный процессинговый центр (далее по тексту – ПЦ). Далеко не всегда это оправдано с экономической точки зрения, но, тем не менее, банки продолжают их создавать. На текущий момент более 700 банков так или иначе причастны к обслуживанию пластиковых карт (Банк России ежеквартально выпускает отчет о количестве эмитентов и эквайеров) и около 300 из них имеют официальные статусы в международных платежных системах (к сожалению точной информации на этот счет нет). Процессинговых центров под международные карты в форме in-house мне удалось обнаружить аж 84 и еще 10 в виде процессинговых компаний, обслуживающих того или иного крупного principal`a (и за редким исключением полностью им контролируемых).
Таким образом, примерно каждый третий российский банк-участник международных платежных систем имеет свой собственный процессинговый центр. Казалось бы куда уж больше… Но опыт соседнего Казахстана показывает, что это еще не предел – там из 36 банков 21 банк работает с картами и 13 (т.е. 62% всех работающих с картами) уже имеют или находятся в стадии запуска собственного ПЦ.
Причины, по которым банки создают собственные ПЦ, можно разбить на несколько групп:

• Экономические: объемы бизнеса банка таковы, что плата за услуги стороннего ПЦ превышает затраты на создание и содержание собственного процессинга. При существующих тарифах на процессинговое обслуживание и ценах на программно-аппаратные комплексы ПЦ можно достаточно условно считать, что экономически обосновано иметь собственный процессинговый центр при активной эмиссии, превышающей 100,000 карт. Впрочем, экономические мотивы редко являются решающими при принятии такого решения (существуют и банки с эмиссией в 5,000 карт и собственным ПЦ);
• Технологические: собственный ПЦ позволяет банку быть более самостоятельным и технологичным в продуктовом плане, не зависеть от готовности и ресурсов стороннего процессинга, быстрее внедрять новые продукты и услуги и т.п.;
• Политические: которые бы я разбил на две подкатегории:
  • удовлетворение амбиций руководителей или собственников банка: у всех есть и у меня должно быть;
  • cвязанные с возможными рисками. Опасения связаны как с передачей информации о клиентах и внутренних оборотах банка в сторонний ПЦ, так и с риском возникновения различных проблем у стороннего ПЦ (достаточно свеж в памяти пример Гута-банка, обслуживание которого в системе VISA было приостановлено летом 2004 года и обслуживаемые в его процессинговом центре многие банки были вынуждены оперативно решать возникшую проблему, меняя спонсора и ПЦ).

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

Кому поручить выбор?

Возможных вариантов ответов на этот вопрос три:

1. Выбирать самостоятельно имеющимися силами. Хорошо если у банка есть специалисты, которым можно поручить такой выбор. К процессу выбора, на мой взгляд, должны быть привлечены специалисты из следующих областей: карточные технологии, IT, розничный бизнес.
2. Привлечь руководителя проекта со стороны с опытом реализации подобных проектов. Позволяет сократить время, но несет риск возможной «зашоренности» этого специалиста на том или ином решении, с которым он уже работал.
3. Привлечь консалтинговую компанию. Мне известны случаи проведения тендеров «Платежными технологиями», «ОТР» и «IBS». На мой взгляд, такое решение оправдано тогда, когда компания-консультант выступает системным интегратором, обеспечивая не только выбор решения, но и его последующее внедрение.

Главное стоит очень четко понимать, что решая КТО будет выбирать, мы часто предопределяем и ЧТО этот КТО нам в итоге выберет.

Из чего выбирать?

В данном контексте мы будем рассматривать только готовые решения для процессирования международных карт, так как писать свое программное обеспечение для ПЦ это сизифов труд, а локальные карты без государственной поддержки неумолимо вытесняются международными.
Если банк уже является участником платежной системы и работает с каким-то банком-спонсором, то в первую очередь необходимо поинтересоваться его позицией по поводу приобретения спонсируемым банком собственного ПЦ и реализацией межхостового (host-to-host или H2H) интерфейса. Банк-спонсор может в принципе отказаться от реализации такого проекта, жестко регламентировать готовность делать H2H только с программным обеспечением от конкретного вендора (поставщика) или ограничить перечень вендоров с которыми он технологически готов работать. Одновременно у банка-спонсора стоит поинтересоваться стоимостью H2H соединения, которая диктуется лицензионной политикой вендора банка-спонсора и может сильно колебаться для межхостов с различными системами. Данная информация позволит сузить выбор (исключив из него вендоров с которыми банк-спонсор отказался поддержать H2H соединение), дифференцировать и учесть затраты на H2H для различных вендоров или вообще принять решение, что свобода выбора решения для ПЦ банку важнее, чем сохранение отношений с текущим спонсором и рассмотреть вопрос миграции на другого спонсора.
Самый простой способ получить список вендоров – это обратится в международные платежные системы и они предоставят список рекомендованных поставщиков. Не стоит думать, что есть список «сертифицированных» поставщиков ПЦ. В рамках проекта сертификации банка (сертифицируется именно банк с конкретным программно-аппаратным комплексом) можно сертифицировать даже самописное программное обеспечение ПЦ, но в то же время гораздо проще проходить сертификацию с программным обеспечением, которое уже сертифицировалось в каком-либо банке (и чем больше было таких сертификаций, тем быстрее и проще пройдет процесс). Обычно региональные офисы платежных систем предоставляют список вендоров, которые работают на данном рынке. На рынке России и СНГ в настоящее время представлены следующие компании (перечислены в алфавитном порядке):

Вендор	Предлагаемое решение	Примечание
ACI Worldwide (США)	BASE24 BASE24-es (новый продукт, разработанный абсолютно независимо от BASE24)	Старейший и крупнейший из существующих вендоров, имеет представительство в Москве.
Card Tech Limited (CTL, Великобритания)	CTL Online + Prime	Разработка за рубежом. Имеет дочернюю компанию в Москве.
Compass Plus (Россия)	TranzWare	Головной офис в Магнитогорске, в Москве только представительство.
OpenWay (Бельгия)	Way4	Фактически разработка находится в Санкт-Петербурге. Отличается от остальных решений, представленных в таблице), объединением front- и back-office «2 в 1».
TietoEnator (Латвия)	TietoEnator Card Suite (ранее назывался TransMaster)	Входит в скандинавский IT-холдинг TietoEnator, разработка карточных решений находится в Латвии (бывшая компания «Konts»). Имеет дочернюю компанию в Москве.
Банковский Производственный Центр (БПЦ, Россия)	SmartVista
Рукард (Россия)	Софит	Фактически решение тиражируется только среди банков, находящихся на процессинговом обслуживании в компании.
Открытые системы и транзакции (Россия)	OST-24	Фактически решение тиражируется только среди банков, находящихся на процессинговом обслуживании в компании.
Программные Системы и Технологии (ПСИТ, Россия)	OST-24	Прецедентов сертификации 3Card-F под международные карты пока не было, хотя начало проекта в СКБ-Банке (Екатеринбург) анонсировано еще в 2005 году.

ТАБЛИЦА

Конечно же, этими поставщиками мировой список хостовых вендоров далеко не исчерпывается – существуют еще Mosaic Software, RS2, Nomad Software и многие другие компании не представленные на нашем рынке. Можно приобрести решение для процессингового центра и у них, принимая во внимания трудности связанные с локализацией продукта и его поддержкой.
Кроме проблем, связанных с локализацией и поддержкой, оказываемой из другой страны, на отбор вендоров чаще всего оказывают влияние следующие факторы:

• Наличие у вендора стабильной клиентской базы, гарантирующей его финансовую стабильность в долгосрочном периоде;
• Опыт реализации схожих проектов и наличие «идеальных референсов» (т.е. референсов, которые могут служить образцом для подражания, например «Русский Стандарт», для банка, который в своем развитии делает ставку на потребительское кредитование);
• Существующие «на рынке» отзывы о вендоре (клиентоориентированность, качество поддержки и т.п.);
• Личные отношения. Не секрет, что большинство вендоров четко ассоциируются с конкретными личностями владельцев (для российских компаний) или топ-менеджеров (для иностранцев);
• Сотрудничество с прямыми конкурентами. Многие банки опасаются, сотрудничать с вендором, который уже обслуживает их прямого конкурента и может, в интересах конкурента, ограничивать доступ к новому функционалу;
• Насколько вендор потенциально заинтересован в данном проекте (ведь понятно, что компания, обслуживающая в основном грандов, даже если и возьмется за проект в небольшом банке, будет выделять ему ресурсы по остаточному принципу).

Если оценивать распространенность тех или иных решений, то распределение российского рынка между различными поставщиками на основе открытой информации можно оценить следующим образом (возможны небольшие погрешности в пределах «плюс-минус 1 инсталляция хоста», но принципиально они картины не меняют):

Пояснения:

• дробные числа означают, что в каком-то ПЦ фронтальное решение комбинируется из двух и соответственно каждая из участвующих компонент получила 0,5 баллов (например ПЦ Сбербанка, который использует одновременно и SmartVista и Way4)
• инсталляции Софита посчитаны для всех банков, имеющих in-house и 1 инсталляция для всего Рукарда (имеющего распределенную процессинговую сеть из более чем 10 компаний в различных регионах)

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

Дальше остается составить перечень тех вендоров, которые будут приглашены к участию в тендере (вряд ли в рамках одного тендера можно представить соперничество ACI и ПСИТ).

Как выбирать?

На первом этапе необходимо сформировать видение требований к будущему ПЦ всех причастных к его выбору подразделений. В банке должен появится согласованный документ, который бы описывал идеальный процессинговый центр. Главное избавится от противоречивых требований различных подразделений и в дальнейшем расставить приоритеты по важности и срокам внедрения. Какими-то функциями ПЦ банк может пожертвовать ради снижению цены проекта или ускорения внедрения, внедрение каких-то функции может быть отсрочено (например на первом этапе запускается процессинговый центр по полосе, потом он сертифицируется на EMV, потом запускается Интернет-банк, потом …).
После формирования такого рабочего документа можно сформировать официальный запрос коммерческого предложений (Request For Proposals – RFP) для рассылки вендорам. Этот документ обязательно должен содержать следующую информацию (которая поможет вендорам адекватно оценить проект и чем он более будет детализован, тем лучше для обоих сторон):

• Краткое представление банка;
• Описание существующего карточного бизнеса;
• Описание планов по развитию карточного бизнеса;
• Объемные характеристики проекта (карты, устройства, транзакции) на ближайшую перспективу (2-3 года) и в долгосрочном плане (5-10 лет);
• Планируемая схема интеграции процессингового решения в IT-инфраструктуру банка (АБС, фронтальная система обслуживания клиентов, call-центр и т.п.), возможные интерфейсы к ним. Это очень важный момент – банк должен сразу представлять, какую роль карточки играют в его продуктовом ряду. Либо это самостоятельный продукт, и тогда учетные функции могут быть возложены на бэк-офис ПЦ. Либо карточка это инструмент доступа клиента к многочисленным банковским продуктам, ведущимся в другой банковской системе (вклады, кредиты и т.п.) и тогда необходима интеграция процессинговой системы с этой розничной системой;
• Перечень необходимой функциональности с указанием на степень важности каждой позиции (при этом в обязательном порядке необходимо потребовать чтобы вендор не только односложно ответил «Да/Нет», но и кратко описал реализацию). Особое внимание следует уделить четкости и понятности формулировок, а такжеих смысловой группировке вопросов;
• Перечень работ, которые планируется выполнять силами поставщика (например полная интеграция системы в IT-инфраструктуру банка, сертификационные процедуры в платежных системах и т.п.);
• Особые условия и пожелания (обязательство реализовать проект за определенный срок, выделенная команда на проект, размер ответственности, график платежей).

Следует учитывать, что обычная практика лицензирования вендоров заключается в лицензировании как функционала (возможностей ПЦ) так и объемных характеристик обслуживаемого проекта (количество финансовых институтов, карт, транзакций, устройств, H2H-интерфейсов и т.п.). Совсем не обязательно платить сразу за все функции и объемы, которые Вам могут понадобиться в обозримом будущем (могут ведь и не понадобится – жизнь не стоит на месте). Можно попросить вендоров зафиксировать стоимость интересующих позиций на определенный срок (т.н. «рамочные» условия).
Кроме этого в RFP обычно запрашивается интересующая потенциального клиента информация о вендоре. Чаще всего это:

• История компании;
• Собственники;
• Клиенты;
• Контакты тех клиентов, которые готовы рекомендовать вендора;
• Типичные сроки реализации проекта.

На подготовку коммерческих предложений (с рекомендациями вендора по необходимой аппаратной платформе и системному программному обеспечению) на практике вполне достаточно отвести 2-3 недели.
Проанализировав и сопоставив все предложения можно оценить стоимость и ориентировочные сроки реализации проекта с тем или иным вендором, а также расходы на дальнейшую поддержу и модернизацию системы. С большой долей вероятности можно предполагать, что большинство предложений по уровню цен будет примерно одинаковым.
Текущая коньюктура рынка позволяет оценить проект по созданию полнофункционального EMV-совместимого ПЦ в банке ассоциированном участнике платежных систем VISA и MasterCard в $500,000. Здесь учтены только стоимость лицензий и работ вендора, без затрат на приобретение серверного оборудования, HSM, системного программного обеспечения и программного обеспечения третьих фирм (например ATM-контроллеров, систем EMV-персонализации и пр., которые у одних вендоров реализованы, а в случае с другими их придется покупать отдельно у сторонних поставщиков). Сравнивая предложения очень важно учесть все затраты на проект в комплексе.
После сбора и анализа всех коммерческих предложений возможно часть вендоров будет отсеяна, так как не сможет обеспечить обязательный функционал, архитектура их решений не будет соответствовать топологии банка (распределению продуктов и их учета по подразделениям), выйдет за рамки утвержденного бюджета или планируемого срока реализации проекта, не сможет продемонстрировать достаточный опыт в реализации аналогичных проектов. Настоятельно рекомендую выборочно обзвонить заявленных клиентов каждого вендора и поинтересоваться их мнением об эксплуатируемой системе, причем для составления объективной картины обзванивать лучше представителей нескольких причастных к эксплуатации подразделений (IT, карты, розница).
Следующим этапом можно назначить c отобранным вендорами презентации коммерческих предложений и их решений. Не стоит довольствоваться только слайдами PowerPoint, хотя, конечно же, показать всю систему в рамках 1-2 дневной презентации Вам никто не сможет просто физически. На первой презентации необходимо оценить архитектуру предлагаемого решения и возможности ее интеграции с другими системами, а также детально познакомится с некоторыми наиболее важными для банка элементами (например рабочее место оператора, возможности параметризации договоров, настройка комиссий и лимитов и т.д.), которые позволят оценить соответствие заявленных возможностей их фактической реализации. На этом этапе также кто-то из претендентов может быть исключен из дальнейшего рассмотрения.
После этого формируется короткий список вендоров для детального рассморения – на мой взгляд, 2-3 являются вполне достаточным количеством. Организуя референс-визиты к клиентам каждого вендора, желательно посмотреть изнутри не только на флагманского клиента каждого вендора (у которого конечно же все хорошо и он всем доволен, так как на него работает добрая половина сотрудников компании-поставщика), но и на произвольно выбранного клиента, сопоставимого с конкретным проектом. При референс-визите в конкретный банк важно пообщаться с максимально широким кругом сотрудников этого банка-клиента и собрать их мнения о предлагаемой системе. Также, если позволяет время, стоит затребовать еще одну, более детальную демонстрацию решения или возможность сотруднику банка на пару дней присоединится к обучающимся в учебном центре вендора клиентам.

Цена вопроса.

Собрав на предыдущих этапах максимум информации о вендорах и его решениях можно переходить к долгожданной фазе ценовых переговорах. Любой вендор при подаче предложения закладывает определенную «подушку» на торг, таковы правила игры. Менеджеры поставщика может и рады были бы сразу называть окончательную цену, но большинство покупателей программного обеспечения считают, что «софт ничего не стоит», и поэтому цена будет «как договоришься», главное торговаться азартнее. Искусство ценовых переговоров заключается в том, чтобы нащупать зыбку грань, за которой проект перестает быть интересным для поставщика. Эта грань определяется большим количеством факторов, например:

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

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

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

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

Договор дороже денег.

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

Об откатах…

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

В заключение

Начиная проект надо четко понимать три вещи:

1. зачем это банку,
2. сколько это стоит,
3. возможные сроки реализации проекта.

Реальный бюджет на создание полноценного процессингового центра не может быть менее $500,000, а срок его запуска в эксплуатацию занимает 6-12 месяцев (бывают быстрые проекты запуска «с нуля» за 3-4 месяца, но это скорее исключение). Команда опытных профессионалов рано или поздно запустит любой процессинг, но грамотно проведенный тендер позволит избежать многих подводных камней и непредвиденных расходов.

Статья была опубликована:

• журнал “ПЛАС” №6(116) за 2006 год
• журнал “Банки и технологии” №4 за 2006 год