"Нюансы внедрения, или на пути к "идеальной АБС" (интервью с В. Мартыновой, заместителем председателя правления Республиканского банка) (Л. Коваленко, "Банковское дело в Москве", N 9, сентябрь 2005 г.)

"Нюансы внедрения, или на пути к "идеальной АБС"
(интервью с В. Мартыновой, заместителем председателя
правления Республиканского банка)

Мало кто вспоминает сегодня отпечатанные на машинке платежки и "бумажные кризисы" начала 90-х, когда РКЦ не справлялись с лавиной документов, а в банках их обработка превращалась в каторжный труд.

Сегодня во всех банках прочно поселились АБС, что свело к минимуму "ручной труд", зато породило новые проблемы: выбора, внедрения, сопровождения, обновления, настройки и прочие. Обо всем этом мы и решили поговорить с профессионалом - заместителем председателя правления ЗАО "Республиканский Банк" Верой Мартыновой. До недавнего времени Вера Гурьевна работала главным бухгалтером этого банка - кому, как не ей, знать все нюансы, связанные с автоматизированными банковскими системами:

- Вера Гурьевна, вы помните первую АБС, с которой вам пришлось работать?

- Конечно, потому что моя первая работа в банке совпала с установкой первой для него программы "Операционный день".

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

- А насколько трудно было вам перестроиться с "ручного труда" на компьютерный?

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

- Собственно, так же эволюционно развиваются и АБС. Кстати, кто играет первую скрипку в этом развитии: разработчики или банкиры?

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

- Чем было в первую очередь продиктовано решение руководства вашего банка о замене прежней системы на другую?

- Именно потребностями бизнеса. До 2003 года мы использовали систему "Diasoft Bank 4x4" компании "Диасофт", разработанную специально под нужды малого банка. При небольших объемах информации, которыми мы прежде оперировали, программа нас полностью устраивала - четко работала, хорошо сопровождалась. Но потом стала нам "тесновата", а развивать эту версию разработчик не собирался.

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

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

- И что же в конечном счете повлияло на ваш выбор?

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

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

А вот ответ типа: "в принципе проводим, но показать не можем" должен настораживать.

Кстати, презентация нашего нынешнего партнера - компании "Програм-Банк" прошла просто идеально. И такая качественная подготовка продукта к продаже тоже заметно повлияла на наше решение.

- Но вот выбор сделан, договор заключен, согласован график внедрения: Как происходит сам процесс внедрения, каковы главные "болевые точки"?

- Вообще-то процесс замены АБС - дело весьма болезненное. Но чем тщательнее проведена подготовительная работа, тем меньшим стрессом для банка он оборачивается. Начинается все, разумеется, с обучения - учились у нас практически все сотрудники: и на рабочих местах, и в учебном центре "Програм-Банка". У ИТ-специалистов была отдельная программа, поскольку им предстояло освоить систему управления базами данных.

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

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

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

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

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

И только после этого "отрубили" старую АБС.

- И на этом все проблемы кончились?

- Некоторые с этого момента только и начались. Что касается основного функционала - ядра системы "Расчетно-кассовое обслуживание", он работает безупречно. Но поскольку "Гефест" - продукт модульный, мы решили приобрести и все предложенные разработчиком модули: "Розничные операции", "Кредиты", "Вклады", "Налоговый учет", "Ценные бумаги". И вот тут нас ждал неприятный сюрприз, причем на очень нужном нам модуле "Вклады", с которым мы помучались немного... И ладно бы причина была в недоработках программы. Сказался пресловутый "человеческий фактор": ушел в другую организацию автор модуля, знавший все нюансы своего продукта. И пошли задержки с реализацией наших заявок...

- Но ведь должна же быть какая-то инструкция?

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

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

К тому же "Гефест" - система открытая, гибкая. У пользователя есть возможность создавать свои настройки или локальные приложения. Например, у нас есть приложения по финансовому мониторингу денежных потоков, по управлению ликвидностью. И наша гордость - расчет нормативов в режиме реального времени для планируемых собственных банковских сделок. Всем известно, насколько это серьезная проблема, и никто из разработчиков пока ее не решил, поскольку этот расчет базируется на аналитическом учете. Аналитика же стандартным решениям не поддается, такие программы всегда уникальны. Мы действительно гордимся, что нам удалось своими силами решить эту задачу, и теперь Инструкция N 110 нас уже не пугает.

- И последний вопрос: как вы себе представляете "идеальную АБС"?

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

Л. Коваленко

"Банковское дело в Москве", N 9, сентябрь 2005 г.