266
Выбор ПО для ПЦ, или C чего начинается тендер?
В рамках данной статьи ее автор Андрей Чирков, директор по продажам компании "Компас Плюс", предлагает вниманию читателей журнала “ПЛАС“ ряд систематизированных рекомендаций, базирующихся на его пятилетнем опыте работы в области продаж процессинговых решений. Возможно, некоторые приводимые в ней соображения окажутся полезными не только при выборе решений для процессинговых центров. Как известно, взгляд компании-поставщика процессингового решения на такой ответственный момент, как подготовка и проведение тендера, по понятным причинам может по целому ряду аспектов принципиально отличаться от видения банка. Для того чтобы картина была более объективной, в рамках настоящей публикации мы приводим комментарии Сергея Лукьянова. Предложив данному специалисту с многолетним опытом работы в карточном бизнесе выступить в качестве независимого эксперта, мы преследовали сразу две цели – с одной стороны, предоставить читателям возможность сравнить мнения двух профессионалов в своей области, с другой – посмотреть на ситуацию одновременно с обеих сторон, т. е. глазами вендора и глазами банка, которые в ходе тендера по определению находятся по разные стороны “баррикад“. А за 13 лет своей деятельности на карточном рынке С.Лукьянову неоднократно приходилось выступать и с той, и с другой позиции. По понятным причинам по ряду вопросов мнения автора статьи и эксперта могут принципиально расходиться – очевидно, что каждое из них не может претендовать на статус абсолютно бесспорного. Истина же, как мы полагаем, лежит где-то посередине. "...Андрей Чирков: Завершив ценовые переговоры и оговорив финальные коммерческие условия с каждым из участников укоротившегося списка, не стоит делать окончательный выбор и объявлять тендер завершенным. Правильнее будет определить двух “финалистов“, из которых один будет основным претендентом на победу, а второй “запасным игроком“ (конечно же, им о распределении реальных ролей сообщать не следует), и приступить к согласованию пакета договоров. В условиях конкуренции оба вендора будут куда сговорчивее и более склонны к уступкам. Только добившись от основного финалиста комфортных для себя договорных условий, можно объявлять тендер закрытым и подписывать договоры с победителем (а может быть, в процессе согласования договоров лидер окажется малосговорчивым и пересядет на “скамейку запасных“). Сергей Лукьянов: На первый взгляд, такой подход представляется беспроигрышным – завершать тендер выбором контрагента не на основании интегрально лучшего коммерческого предложения, а на основании лучшего по условиям контракта. В том числе и по финансовым. В то же время необходимо отдавать себе отчет в том, что такая практика в принципе ломает схему проведения тендеров и выявления победителя, поскольку на этапе согласования договоров соперники могут довольнотаки значительно изменить параметры своих коммерческих предложений, и аутсайдер “на вираже“ сможет обойти формального лидера. Выиграет ли банк в этом случае – скорее всего да, однако оба вендора проиграют, прогнувшись под клиента, что в результате неминуемо скажется на качестве и сроках исполнения проекта..."
Эта расхожая в карточной среде фраза близка к истине. Так уж повелось, что в России каждый более-менее крупный банк стремится обзавестись своим собственным процессинговым центром (ПЦ). Далеко не всегда это оправданно с экономической точки зрения, но тем не менее банки продолжают их создавать. На текущий момент более 700 отечественных банков так или иначе причастны к обслуживанию пластиковых карт (как известно, Банк России ежеквартально выпускает отчет о количестве эмитентов и эквайеров), и около 300 из них имеют официальные статусы в международных платежных системах. Процессинговых центров под международные карты в форме in-house удалось обнаружить целых 84 и еще 10 – в виде процессинговых компаний, обслуживающих того или иного крупного принципиального члена (и за редким исключением полностью им контролируемых).
Таким образом, примерно каждый третий российский банк-участник международных платежных систем имеет свой собственный процессинговый центр. Казалось бы, куда же больше?! Однако опыт соседнего Казахстана показывает, что и это еще не предел – там из 36 коммерческих банков 21 банк работает с картами и 13 банков (62%) уже создали или находятся в стадии запуска собственного ПЦ. Причины, по которым банки создают собственные ПЦ, можно условно разбить на несколько групп: – Экономические: объемы бизнеса банка таковы, что плата за услуги стороннего ПЦ превышает затраты на создание и содержание собственного процессинга. При существующих тарифах на процессинговое обслуживание и ценах на программно-аппаратные комплексы ПЦ можно достаточно условно считать, что экономически обоснованно иметь собственный процессинговый центр при активной эмиссии, превышающей 100 000 карт.
Впрочем, экономические мотивы редко являются решающими при принятии такого решения (существуют и банки с эмиссией в 5000 карт и собственным ПЦ). – Технологические: собственный ПЦ позволяет банку быть более самостоятельным и технологичным в продуктовом плане, не зависеть от готовности и ресурсов стороннего процессинга, быстрее внедрять новые продукты и услуги и т.п. – Политические, которые условно можно разделить на две подкатегории:
• “У всех есть, и у меня должно быть“.
• Связанные с возможными рисками.
Опасения связаны как с передачей информации о клиентах и внутренних оборотах банка в сторонний ПЦ, так и с риском возникновения различных проблем у стороннего ПЦ (например, в случае банкротства банка-спонсора – вспомним свежий пример Гута Банка, обслуживание которого в Visa International было приостановлено летом 2004г., в результате чего многие обслуживаемые им банки были вынуждены менять спонсора и, соответственно, обслуживающий процессинговый центр).
На взгляд автора, в процессе принятия решения о создании собственного ПЦ технологические и политические мотивы играют существенно большую роль, чем экономические факторы.
С.Лукьянов: При этом нередко ощутимую роль в принятии решения банком строить in-house процессинг играют собственные амбиции и интересы менеджера, отвечающего за розницу и пластиковые карты. Если это человек с технологическим уклоном, не боящийся взять на себя ответственность за сложный IT-проект, видящий свое собственное развитие именно в реализации проекта in-house, то именно он чаще всего и склоняет чашу весов на сторону собственного ПЦ. Несомненно, реализация такого проекта существенно повышает личный статус менеджера на рынке. Итак, по тем или иным причинам решение о создании собственного ПЦ в банке принято.
Возможных вариантов ответов на этот вопрос три: • Выбирать самостоятельно имеющимися силами. Хорошо, если у банка есть специалисты, которым можно поручить такой выбор. К процессу выбора, на мой взгляд, должны быть привлечены специалисты из следующих областей: карточные технологии, IT, розничный бизнес.
С. Лукьянов: Команда менеджеров и специалистов, принимающих участие в подготовке принятия решения, должна быть подобрана таким образом, чтобы максимально учесть все интересы стейкхолдеров банка: акционеров, топ-менеджеров, менеджеров проекта, банковских специалистов, клиентов. Руководить данной командой, быть ее “дирижером“ – непростая задача.
• Привлечь руководителя проекта с соответствующим опытом со стороны. Такой подход позволяет сократить время, но несет риск возможной “зашоренности“ данного специалиста на том или ином решении, с которым он уже работал.
С.Лукьянов: Подобная “зашоренность“ в большинстве случаев объясняется отнюдь не узким кругозором специалиста, но так называемым эффектом памяти предыдущего опыта. Дело в том, что субъективно менеджер, имеющий опыт успешного внедрения ПО некого вендора, с которым удачно сработался и получил глубокие знания по продукту и сервису этой конкретной компании, поневоле становится “заложником“ удачного былого сотрудничества. При этом менеджер не желает зла своему банку, напротив: он стремится минимизировать его и свои риски на предмет сроков и качества внедрения решения, поскольку все это уже проходил однажды, а бывает, что и неоднократно. • Привлечь консалтинговую компанию. Мне известны случаи проведения тендеров рядом компаний, включая “Платежные технологии“, “ОТР“, IBS и аналогичные структуры. На мой взгляд, такое решение оправданно только тогда, когда компания-консультант одновременно выступает системным интегратором, обеспечивая не только выбор решения, но и его последующее внедрение.
: В данном случае ответственность компании-консультанта за конечный результат дополнительно повышает качество выбора банка. Однако следует отметить, что при таком подходе существует вероятность возникновения уже упомянутого “эффекта памяти предыдущего опыта“, аналогичного описанному в предыдущем варианте. Нельзя забывать, что сегодня в СНГ практически нет компаний-консультантов или интеграторов, где бы работали специалисты с опытом внедрения двух и более программных продуктов для in-house процессинга. Поэтому выбор в данном случае также будет предопределен на 95%.
В любом случае, самое важное – очень четко понимать: решая, КТО будет ответственен за осуществление выбора, мы часто предопределяем и то, ЧТО он нам в итоге выберет.
В данном контексте мы будем рассматривать только готовые решения для процессирования международных карт, так как писать свое собственное программное обеспечение для ПЦ – это сизифов труд (причем как с точки зрения ресурсоемкости, так и результативности), а локальные карты без государственной поддержки сегодня, как правило, неумолимо вытесняются международными.
Если банк уже является участником платежной системы и работает с какимлибо банком-спонсором, то в первую очередь необходимо поинтересоваться позицией последнего по поводу приобретения спонсируемым банком собственного ПЦ и реализацией межхостового (H2H) интерфейса. Нельзя не принимать во внимание, что банк-спонсор может в принципе отказаться от реализации такого проекта, жестко регламентировать свою готовность создания H2H только с программным обеспечением от конкретного вендора (поставщика) или ограничить перечень вендоров, с которыми он технологически готов работать. Одновременно у банкаспонсора стоит поинтересоваться стоимостью H2H соединения, которая диктуется лицензионной политикой вендора банкаспонсора и может сильно разниться для межхостов с различными системами.
Данная информация позволит сузить выбор (исключив из него решения вендоров, с которыми банк-спонсор отказался поддержать H2H), дифференцировать и учесть затраты на реализацию H2H для продуктов различных вендоров или же вообще принять решение, что свобода выбора решения для ПЦ банку важнее, чем сохранение отношений с текущим спонсором, и рассмотреть вопрос миграции. Самый простой способ получить список вендоров – это обратиться в платежные системы, которые предоставят список рекомендованных поставщиков. Однако не стоит заблуждаться насчет того, что у них имеется некий список “сертифицированных“ поставщиков ПЦ. В рамках проекта сертификации банка (а сертифицируется именно банк с конкретным программноаппаратным комплексом) можно сертифицировать даже “самописное“ программное обеспечение ПЦ, но в то же время гораздо проще проходить сертификацию с программным обеспечением, которое уже сертифицировалось данной платежной сиcтемой в каком-либо банке (и чем больше было таких сертификаций, тем быстрее и проще пройдет аналогичный процесс в вашем банке). Обычно региональные офисы платежных систем предоставляют список вендоров, которые работают на местном рынке. Для СНГ это следующие компании . Конечно же, этими поставщиками мировой список хостовых вендоров далеко не исчерпывается – существуют еще Mosaic Software, RS2, Nomad Software и многие другие компании, не представленные на нашем рынке. Можно приобрести решение для процессингового центра и у них, принимая, однако, во внимание трудности, связанные с локализацией продукта и его поддержкой.
Кроме проблем, связанных с локализацией и поддержкой, оказываемой из другой страны, на отбор вендоров чаще всего оказывают влияние следующие факторы:
• Наличие у вендора стабильной клиентской базы, гарантирующей его финансовую стабильность в долгосрочном периоде;
• Опыт реализации схожих проектов и наличие “идеальных референсов“ (т. е. референсов, которые могут служить образцом для подражания, например “Банк Русский Стандарт“, для банка, который в своем развитии также делает ставку на потребительское кредитование);
• Существующие “на рынке“ отзывы о вендоре (клиентоориентированность, качество поддержки и т. п.); 
• Личные отношения. Не секрет, что большинство вендоров четко ассоциируются с конкретными личностями владельцев (для российских компаний) или топ-менеджеров (для иностранцев);
• Сотрудничество с прямыми конкурентами. Многие банки опасаются сотрудничать с вендором, который уже обслуживает их прямого конкурента и может в интересах конкурента ограничивать доступ к новому функционалу;
• Насколько вендор потенциально заинтересован в данном проекте (ведь понятно, что компания, обслуживающая в основном “грандов“, даже если и возьмется за проект в небольшом банке, будет выделять ему ресурсы по остаточному принципу).
Если рассматривать распространенность тех или иных решений, то распределение российского рынка между различными поставщиками на основе открытой информации можно оценить исходя из рис.1 (возможны небольшие погрешности в пределах “плюс-минус 1 инсталляция хоста“, но принципиально они картины не меняют). Таким образом, тройка лидеров по количеству инсталляций определяется достаточно явно – это компании OpenWay, “Компас Плюс“ и БПЦ.
Обычно банки также оценивают структуру клиентской базы потенциальных поставщиков по уровню участия их банковклиентов в платежной системе. И, разумеется, вхождению банков-клиентов в перечень крупнейших финансовых институтов. Дальше остается выбрать перечень тех вендоров, которые будут приглашены к участию в тендере (поскольку вряд ли в рамках одного тендера можно представить соперничество, например, ACI и ПСИТ).
На первом этапе необходимо сформировать четкое видение требований к будущему ПЦ всех причастных к выбору банковских подразделений. В банке должен появиться документ, который бы описывал идеальный процессинговый центр. Главное – избавиться от противоречивых требований различных подразделений и в дальнейшем расставить приоритеты по важности и срокам внедрения. Какими-то функциями ПЦ банк может пожертвовать ради снижения цены проекта или ускорения внедрения, внедрение каких-то функций может быть отсрочено (например, на первом этапе запускаем процессинговый центр “по полосе“, потом сертифицируем его на EMV, потом запускаем Интернет-банк, и т. д.).
С. Лукьянов: Помочь выработать такое видение команде ЛПР может вопрос – “какие проблемы стоят перед банком, которые он сможет решить с помощью in-house?“
После формирования такого рабочего документа можно сформировать официальный запрос коммерческого предложения (Request For Proposals – RFP) для рассылки вендорам. Этот документ обязательно должен содержать следующую информацию (которая поможет вендорам адекватно оценить проект, и чем более он будет детализован, тем лучше): • краткое представление банка; • описание существующего карточного бизнеса; • описание планов по развитию карточного бизнеса; • объемные характеристики проекта (карты, устройства, транзакции) на ближайшую перспективу (2–3 года) и в долгосрочном плане (5–10 лет); • планируемая схема интеграции процессингового решения в IT-инфраструктуру банка (АБС, фронтальная система обслуживания клиентов, call-центр и т.п.), возможные интерфейсы к ним. Это очень важный момент – банк должен сразу представлять, какую роль карточки играют в его продуктовом ряду. Либо это самостоятельный продукт, и тогда учетные функции могут быть возложены на бэк-офис ПЦ. Либо карточка – это инструмент доступа клиента к многочисленным банковским продуктам, ведущимся в другой банковской системе (вклады, кредиты и т. п.), и тогда необходима интеграция процессинговой системы с этой розничной системой; • перечень необходимой функциональности с указанием степени важности каждой позиции (при этом в обязательном порядке необходимо потребовать, чтобы вендор не только односложно ответил “Да/Нет“, а хотя бы кратко описал реализацию).
С.Лукьянов: Идеально, когда команда лиц, принимающих решения, сможет синтезировать функцию критериев по параметрам предложения вендора с фиксацией величин весовых коэффициентов по каждому значимому параметру. При этом как раз и происходит расстановка приоритетов по параметрам предложения; • Перечень работ, которые планируется выполнять силами поставщика (например, полная интеграция системы в IT-инфраструктуру банка, сертификационные процедуры в платежных системах и т. п.); особые условия и пожелания (обязательство реализовать проект за определенный срок, выделенная команда на проект, размер ответственности, график платежей). С. Лукьянов: Говоря о сроке, следует отметить, что очень часто банк, решаясь на проект, закладывает в RFP достаточно жестко определенный срок, исходя из собственных соображений. Однако в процессе подготовки и проведения тендера по выбору ПО и вендора, после нескольких этапов уточнений требований к ПО, все первоначально намеченные сроки, как правило, оказываются нереальными. При этом под ними подписывается вендор, выигравший тендер, и, разумеется, сам банк. На этом фоне имеет смысл прописывать в RFP не срок (конкретную календарную дату) реализации того или иного этапа проекта, а длительность проекта в неделях или месяцах.
Следует учитывать, что обычная практика лицензирования вендоров заключается в лицензировании как функционала (возможностей ПЦ), так и объемных характеристик обслуживаемого проекта (количество финансовых институтов, карт, транзакций, устройств, H2H-интерфейсов и т. п.). Совсем не обязательно платить сразу за все функции и объемы, которые вам могут понадобиться в обозримом будущем (могут ведь и не понадобиться – жизнь не стоит на месте). Можно попросить вендоров зафиксировать стоимость интересующих позиций на определенный срок (т. н. рамочные условия). Кроме этого, в RFP обычно запрашивается интересующая потенциального клиента информация о вендоре. Чаще всего это: • история компании; • собственники; • клиенты; • контакты тех клиентов, которые готовы рекомендовать вендора; • типовые сроки реализации проекта. На подготовку коммерческих предложений (с рекомендациями вендора по необходимой аппаратной платформе и системному программному обеспечению) на практике вполне достаточно отвести 2–3 недели. Проанализировав и сопоставив все предложения, можно оценить стоимость и ориентировочные сроки реализации проекта с тем или иным вендором, а также расходы на дальнейшую поддержу и модернизацию системы. С большой долей вероятности можно предполагать, что большинство предложений по уровню цен будет примерно одинаковым.
Текущая конъюнктура рынка позволяет оценить проект по созданию полнофункционального EMV-совместимого ПЦ в банке – ассоциированном участнике платежных систем Visa и MasterCard в 500 000 долл. США. Здесь учтены только стоимость лицензий и работ вендора, без затрат на приобретение серверного оборудования, HSM, системного программного обеспечения и программного обеспечения третьих фирм (например, ATM-контроллеров, систем EMV-персонализации ипр., которые у разных вендоров могут как входить в поставку, так и не входить, т.е. может возникать необходимость их приобретения на стороне). Сравнивая предложения, очень важно учесть все затраты на проект в комплексе. После сбора и анализа всех коммерческих предложений, возможно, часть вендоров будет отсеяна, так как не сможет обеспечить обязательный функционал, архитектура их решений не будет соответствовать топологии банка (распределению продуктов и их учета по подразделениям), выйдет за рамки утвержденного бюджета или планируемого срока реализации проекта, не сможет продемонстрировать достаточный опыт в реализации аналогичных проектов. Настоятельно рекомендуется выборочно обзвонить заявленных клиентов каждого вендора и поинтересоваться их мнением об эксплуатируемой системе, причем для составления объективной картины обзванивать лучше представителей нескольких причастных к эксплуатации подразделений (IT, карты, розница).
Следующим этапом можно назначить проведение c отобранными вендорами презентаций коммерческих предложений и их решений. Не стоит довольствоваться только слайдами PowerPoint, хотя, конечно же, показать всю систему в рамках 1–2-дневной презентации вам никто не сможет просто физически. На первой презентации необходимо оценить архитектуру предлагаемого решения и возможности ее интеграции с другими системами, а также детально ознакомиться с некоторыми наиболее важными для банка элементами (например, рабочее место оператора, возможности параметризации договоров, настройка комиссий и лимитов и т.д.), которые позволят оценить соответствие заявленных возможностей их фактической реализации. На этом этапе также кто-то из вендоров может быть исключен из дальнейшего рассмотрения.
После этого формируется короткий список вендоров для детального рассмотрения – на мой взгляд, 2–3 являются вполне достаточным количеством. Организуя референс-визиты к клиентам каждого вендора, желательно посмотреть изнутри не только на флагманского клиента (у которого, конечно же, все хорошо и он всем доволен, так как на него работает добрая половина сотрудников компании-поставщика), но и на произвольно выбранного клиента, сопоставимого с конкретным проектом. При референсвизите в конкретный банк-клиент важно пообщаться с максимально широким кругом его сотрудников и собрать их мнения. Также, если позволяет время, стоит затребовать еще одну, более детальную, демонстрацию решений или возможность вашему сотруднику на пару дней присоединиться к специалистам других банков, обучающимся в учебном центре вендора.
Собрав на предыдущих этапах максимум информации о вендорах и его решениях, можно переходить к долгожданной фазе ценовых переговоров. Любой вендор при подаче предложения закладывает определенную “подушку“ на торг, таковы правила игры. Менеджеры поставщика, возможно, и рады были бы сразу называть окончательную цену, но большинство покупателей программного обеспечения попрежнему считает, что “софт ничего не стоит“, и поэтому цена будет “как договоришься“. Искусство ценовых переговоров заключается в том, чтобы нащупать зыбкую грань, за которой проект перестает быть интересным для поставщика. Эта грань определяется большим количеством факторов, например: • степень сложности конкретного проекта (сложный проект дороже, простой – дешевле); • наличие у вендора свободных ресурсов в текущий момент времени (если есть свободные люди, что на практике бывает крайне редко, – цена может снизиться, а если людей придется отвлекать от уже идущих проектов, то вендор будет менее сговорчив при торге); • степень важности конкретного клиента и возможность использования этого проекта в дальнейшем в качестве значимого для других потенциальных клиентов референса (первый клиент на новом рынке, миграция с конкурентного решения, пилотное внедрение новой разработки, внедрение в банке-лидере рынка) повышают шансы на скидку; • коммерческие успехи вендора в последнее время (длинная череда проигрышей стимулирует вендора получить проект “любой ценой“, в то время как многочисленные успешные продажи ведут как к недостатку ресурсов, так и к формированию “звездной болезни“ и соответствующих ценовых амбиций).
Главное в ценовых переговорах – аргументированный торг. Просить скидку просто потому, что хочется подешевле, не вполне корректно и неэффективно. На мой взгляд, существуют два основных аргумента для снижения цены: 1. Конкурент предлагает все то же самое, но дешевле (вариант – “больше за те же деньги“). В данной ситуации стоит “открыть карты“ и обозначить конкретные предложения конкурентов. Ваш оппонент либо предоставит просимую скидку, либо обоснует, почему конкурирующее предложение не может сравниваться с его предложением напрямую (возможно, вы не учли каких-то нюансов).
2. Запросы поставщика загоняют ваш проект за грань рентабельности. В данной ситуации вполне уместно показать модель окупаемости и продемонстрировать, что такая ценовая политика вендора делает проект убыточным, поэтому он либо меняет свое предложение (предлагая какую-то этапность платежей, скидку и “добирая“ недополученную прибыль впоследствии, с ростом вашего бизнеса), либо реализация проекта теряет всякий смысл для покупателя.
При ведении переговоров стоит учитывать, что вендоры гораздо охотнее идут не на снижение цены, а на предоставление скидок в виде увеличения функционала, объемных характеристик проекта, предоставление дополнительных лицензий за те же деньги или снижение цен на условия будущих покупок (“рамочные“ цены). Также следует учитывать, что самое “дешевое“ предложение далеко не всегда самое лучшее – должна быть выработана достаточно понятная система критериев сравнения и оценки предлагаемых решений по различным показателям, характеризующим приобретаемое решение, а также степени их значимости для конкретного проекта (надо очень четко понимать, что один и тот же фактор в различных проектах может получать существенно различающиеся весовые коэффициенты).
Завершив ценовые переговоры и оговорив финальные коммерческие условия с каждым из участников укоротившегося списка, не стоит делать окончательный выбор и объявлять тендер завершенным. Правильнее будет определить двух “финалистов“, из которых один будет основным претендентом на победу, а второй “запасным игроком“ (конечно же, им о распределении реальных ролей сообщать не следует), и приступить к согласованию пакета договоров. В условиях конкуренции оба вендора будут куда сговорчивее и более склонны к уступкам. Только добившись от основного финалиста комфортных для себя договорных условий, можно объявлять тендер закрытым и подписывать договоры с победителем (а может быть, в процессе согласования договоров лидер окажется малосговорчивым и пересядет на “скамейку запасных“). С.Лукьянов: На первый взгляд, такой подход представляется беспроигрышным – завершать тендер выбором контрагента не на основании интегрально лучшего коммерческого предложения, а на основании лучшего по условиям контракта. В том числе и по финансовым. В то же время необходимо отдавать себе отчет в том, что такая практика в принципе ломает схему проведения тендеров и выявления победителя, поскольку на этапе согласования договоров соперники могут довольнотаки значительно изменить параметры своих коммерческих предложений, и аутсайдер “на вираже“ сможет обойти формального лидера. Выиграет ли банк в этом случае – скорее всего да, однако оба вендора проиграют, прогнувшись под клиента, что в результате неминуемо скажется на качестве и сроках исполнения проекта.
В процессе согласования договоров нельзя забывать, что проекты договоров предоставляет поставщик, который многократно обкатал их на предыдущих клиентах и учел все возможные для себя риски. Естественно, о рисках покупателя в таком договоре если что-то и сказано, то очень поверхностно. Более того, обычная практика вендоров – лимитировать любую свою ответственность по договору небольшим процентом от его суммы или даже фиксированной суммой. Менеджеры вендора “собаку съели“ на согласовании таких договоров, и на каждое возражение покупателя у них заготовлено вполне логичное объяснение, почему это именно так и никак иначе быть не может. Поэтому за свои права и ответственность вендора по договору придется побороться, и конкуренция будет в этом хорошим подспорьем. Не стоит также забывать, что любые слова “сейла“ остаются просто словами конкретного человека, заинтересованного скорее подписать договор и получить свой бонус. И только будучи перенесенными на бумагу и скрепленными печатью, эти слова приобретают статус обязательства.
С.Лукьянов: Согласование договора – очень сложный двухсторонний процесс уступок, при этом риски присутствуют и у той, и другой стороны. Известен случай, когда “жупелом“ заключения контракта с компанией-конкурентом сильно “напугали“ вендора-лидера рынка, и он согласился на условиях договора, более лояльных банку, чем исходные. Каково было чувствовать себя в данной ситуации “вендору-сопернику“, которого банк явно использовал как инструмент для достижения своих целей? Нельзя не принимать во внимание, что все это – не только бизнес, но еще и чисто человеческие отношения менеджеров, которые часто мигрируют от банка к банку, и след прошлых сделок тянется за ними довольно долго. В таком разрезе модель с выбором окончательного вендора на основании стандартного тендера и подписание затем с ним контракта, на мой взгляд, более честна и прозрачна.
P. S. Итак, начиная проект, необходимо четко понимать три ключевых момента: • зачем это банку, • сколько это стоит, • возможные сроки реализации проекта. Реальный бюджет на создание полноценного процессингового центра не может быть менее 500000 долл. США, а срок его запуска в эксплуатацию занимает 6–12 месяцев (бывают быстрые проекты запуска “с нуля“ за 3–4 месяца, но это скорее исключение). Команда опытных профессионалов рано или поздно запустит любой процессинг, но грамотно проведенный тендер позволит избежать многих подводных камней и непредвиденных расходов. С.Лукьянов: Автор данной статьи рекомендует проводить тендер по так называемой внутренней схеме, или “квази“-тендер.
Это часто с успехом применяется небольшими банками, но неприемлемо для крупных ведущих финансовых институтов по различным причинам. Что имеется в виду? Внутренний тендер позволяет многократно, на этапе коммерческих переговоров с потенциальными поставщиками, “утрясать“ ценовые параметры предложения, возвращаясь “бумерангом“ от одного вендора к другому, пока окончательный вариант не будет выбран. Менеджер проекта уже знает победителя или по крайней мере пару финалистов тендера, но путем давления с помощью предложений конкурентов достигает низшей цены оферты от интересующего его поставщика. На первый взгляд, это несомненный выигрыш для банка, но не стоит увлекаться, иначе проект станет коммерчески малоинтересен вендору, что повлечет возможные проволочки с внедрением, а также увеличит вероятность того, что поставщик все отыграет на последующих этапах жизни проекта. Крупные банки проводят тендер по классической “открытой“ схеме с четко прописанными правилами выбора победителя, с фиксацией величины весовых коэффициентов по каждому значимому параметру функционала поставляемого решения и по параметрам сервиса вендора. При этом уже на первом этапе в RFP банк может зафиксировать максимальную стоимость проекта (с учетом цены лицензии и сервисной поддержки, а также стоимости внедрения), в которую будут обязаны уложиться все предложения конкурентов. На втором этапе, когда определится short list (как правило, пара полуфиналистов), уточняются параметры поставляемого решения, и стоимость проекта может несколько измениться в ту или иную сторону. Банк также может ввести ограничения на рост стоимости проекта (в пределах 15–25%). Финалист обязан заключить контракт с мотивированным повышением стоимости, не превышающим максимальное значение данного ограничения. В противном случае контракт заключается со вторым полуфиналистом. В чем тут выигрыш банка? В том, что такой тендер возможно провести для очень крупного и сложного проекта в очень сжатые и прогнозируемые сроки, что в случае “квази“тендера может растянуться на годы выбора решения. А это по сегодняшним меркам непозволительная роскошь.
Редакция журнала ПЛАС
Текст статьи читайте в журнале Плас № 6 за 2006 год сс. 2-10.
