Гонка за клиентом

Как не потерять время на старте.

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

«Оптимальное из лучших»

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

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

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

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

При всем богатстве выбора

На этапе выбора программного обеспечения следует обратить особое внимание на возможности интеграции систем между собой. Чем больше вариантов предполагается - тем лучше. Если интеграция предполагается через шину, нужно понимать, есть ли силы и средства поддерживать данное решение. Промышленные шины стоят дорого и стоимость их обслуживания также весьма чувствительна. Можно разработать собственную шину или использовать прямой вызов API при организации межмодульного взаимодействия. Такой подход позволяет сэкономить время и деньги.

Отдельно следует обратить внимание на возможность передачи решений с исходным кодом. Наличие исходников существенно упрощает процесс интеграции и настройки модулей на территории заказчика. Проще искать и устранять ошибки интеграции и настройки. Кроме того, вы получаете возможность развивать решение своими силами, не привлекая вендора. Многие крупные банки сталкиваются с проблемой закрытого кода используемых решений при разработке новых продуктов и модификации существующих. Любое изменение логики работы таких продуктов, не заложенное в штатных настройках приводит к обращению в компанию-поставщика программного обеспечения с заявкой на доработку функционала. Время на реализацию, тестирование и установку таких доработок бывает весьма существенно. Часто данный фактор приводит к смене поставщика или выкупу исходных кодов. Недавний наглядный пример - выкуп исходных кодов Misys Equation «Альфа-банком».

Утром стулья, вечером деньги

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

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

Команда молодости нашей

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

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

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

Объять необъятное

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

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

Учет и нагрузка

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

Нужно обратить внимание на основные моменты, приводящие к успеху:

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

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

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

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