Занимаясь разработкой программного обеспечения (ПО) для банков, необходимо знать, что в их работе есть определённые обязательные процессы и процедуры. Многие действия и события необходимо фиксировать и хранить в централизованных архивах: электронных или физических.
Наш клиент – лидирующий розничный банк в Восточной Европе – столкнулся с необходимостью автоматизации процесса кредитования. Банк нашёл вендора для внедрения системы. Но что-то пошло не так: программное обеспечение стало мёртвым грузом.
Прочтите эту историю успеха, чтобы увидеть, как ПСТ Лабс реанимировала внедрённый, но не работающий проект по автоматизации процесса выдачи кредитов, сэкономив для Банка круглую сумму.
«У нас ситуация «Франкенштейн»: необходима реанимационная команда
Известный вендор и крупный игрок на рынке банковского программного обеспечения, чья репутация ни у кого не вызывала сомнений, разработал и внедрил в Банке систему обработки кредитных заявок, строго следуя требованиям заказчика.
Но программа не заработала из-за множества недостатков, которые убили систему в зародыше. Ведь специалисты Банка не учли все возможные тонкости и нюансы, составляя спецификации системы обработки заявок на кредит. А команда вендора слепо воплотила эти спецификации в строчки кода, не проанализировав технические характеристики и описание продукта.
Сергей Ефименко, глава отдела развития бизнеса в банковском секторе компании ПСТ Лабс, согласился рассказать об этом случае.
Руководство Банка связалось с нами и спросило, можем ли мы помочь им в возникшей ситуации и сделать систему рабочей. Группа экспертов из ПСТ Лабс отправилась в Банк для консультаций. Спустя некоторое время наша команда поняла: у нас ситуация «Франкенштейн».
Анализ показал, что автоматизированная система кредитования, внедренная другим вендором, имела несколько критических недостатков:
-
неудобный и контр-интуитивный пользовательский интерфейс;
-
низкая производительность системы;
-
низкая скорость обработки кредитных заявок;
-
плохая интеграция с внутренними системами Банка;
-
слабая масштабируемость системы.
«Дела громче слов»: почему Банк выбрал ПСТ Лабс
Кто-то может сказать, что есть много компаний, которые могут разработать программу для автоматизации коммерческого кредитования.
Почему же Банк выбрал ПСТ Лабс? Дела громче слов. Ранее наша команда успешно внедрила Систему Раннего Предупреждения (СРП) для Банка. СРП продемонстрировала впечатляющие результаты. Поэтому ПСТ Лабс уже была знакома Банку как опытный разработчик финансового ПО.
Также было несколько дополнительных условий, которые повлияли на выбор Банком нашей компании для реализации проекта:
-
наш опыт в банковском домене;
-
наше детальное знание инфраструктуры Банка;
-
краткая, точная и понятная архитектура предложенной нами программы для автоматизации выдачи кредитов.
«Доброе начало – половина дела»: точные требования – первый шаг к успеху
Изучение требований Банка для первоначального тендера показало, что в них многие задачи не были четко определены. А вендор следовал им слепо без оценки и рекомендаций. Поэтому программное решение было разработано без учета подводных камней и скрытых ловушек финансовой сферы.
Нам пришлось начинать работу с самого начала – с технических требований. Ушло два месяца, чтобы написать их правильно, учитывая все этапы процесса выдачи кредитов. Тщательно анализируя требования Банка, команда ПСТ Лабс скрупулезно отбирала только оптимальные варианты решения задач, согласовывая их с заказчиком и предлагая эффективные альтернативы.
Хотя Банк и разрешил нашей команде использовать код и компоненты исходной программы, мы решили разрабатывать совершенно новое решение, так как это было единственным выбором. Старое решение оказалось неэффективным не только по функционалу и интерфейсу, но и по программному коду. Но все необходимо было начинать с составления корректных технических требований, чтобы избежать участи предыдущего ПО.
«Разработка ПО – это игра двух команд»: эффективные команды – отличный результат
Как я упоминал выше, одной из причин провала начального проекта стали неточно разработанные технические требования к продукту. Но были и другие причины. Текучка кадров у разработчика, работавшего над проектом, – еще одна из них. Она сильно повлияла на процесс создания ПО. Представьте, что картину пишут художники разных школ. Конечное произведение вряд ли будет шедевром.
Поэтому Банк выдвинул требование, чтобы состав команды, работающей над проектом, был постоянным. Мы уверили Банк, что это условие будет соблюдено.

Разработка ПО – это игра двух команд: заказчика и разработчика, которые могут достичь необходимых результатов только в тесном сотрудничестве.
Командная работа важна на всех этапах создания программного продукта. Заказчик и разработчик видят будущее ПО с разных сторон. Сложение этих точек зрения воедино позволило команде ПСТ Лабс реализовать в продукте именно тот функционал, который был необходим Банку.
Открытый подход Банка к предложениям команды разработчиков помог избежать потенциальных узких мест и достичь высокой эффективности и производительности системы.
Заключение, или «Выигрывает не бренд, а люди, стоящие за ним»
Представители бизнеса должны слышать предложения вендора. Разработчики видят и анализируют систему изнутри. В свою очередь, разработчик ПО должен предупредить заказчика о возможных проблемах и узких местах, предложить оптимальный выход, сохраняя необходимый набор функций.
Команда ПСТ Лабс понимает, что политика слепого следования техническим требованиям не работает, а ведет в тупик.