Сведения об авторе: Литовкин Андрей Владимирович (avl@vpcons.ru) — заместитель генерального директора Группы Компаний «Верников и Партнёры», занимается вопросами внедрения САБ с 1987 года. За это время успешно реализован ряд проектов в кредитных организациях разных масштабов — от крупных системообразующих до совсем небольших.

Введение

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

Многие положения этой статьи не бесспорны, поэтому прошу рассматривать ее не как догмат, а как повод для дискуссии среди коллег на вечную тему: «Что лучше и правильнее — разрабатывать самим или приобретать готовое?».

Спор на эту тему, то утихая, то разгораясь с новой силой, продолжается уже не одно десятилетие.

Возможно, Вам будет интересна и моя точка зрения по этому поводу.

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

Итак, приступим.

Попытка классификации банковских систем

Ничего революционно нового в этой области я не могу Вам предложить — я предлагаю классифицировать САБ по признаку разработки, а именно:

• САБ собственной разработки;
• САБ отечественного разработчика;
• САБ зарубежной разработки.

Давайте рассмотрим выделенные классы САБ раздельно, отметим их плюсы и минусы.

САБ собственной разработки

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

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

Что можно сказать об этом типе САБ? Насколько он плох или хорош?

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

• САБ собственной разработки в процессе своего развития (при условии грамотного руководителя разработкой и сопровождением САБ) максимально полно отвечают нуждам банка;
• САБ собственной разработки обладают максимальной мобильностью с точки зрения изменений внешней среды (при условии наличия эффективной структуры управления банком);
• С точки зрения совокупной стоимости владения САБ собственной разработки тоже на высоте. Практически совокупная стоимость владения сравнима с САБ отечественного разработчика;
• Возможность осуществления максимально эффективного контроля со стороны банка над процессом разработки представляется весьма немаловажной.

А что же можно сказать о отрицательных моментах:

• Высочайшие кадровые риски. Речь идет о том, что зачастую высокая мобильность САБ собственной разработки достигается за счет грубейших нарушений классического процесса разработки ПО, особенно в области документирования процесса разработки. Таким образом, чаще всего САБ собственной разработки практически неотчуждаемы от разработчика, что дает возможность разработчику (и небезосновательно) чувствовать себя незаменимым;
• Проблема «закрытости». Что я имею в виду? Да все очень просто! Разработчик варится в собственном соку, в проблемах собственного банка. Поэтому, зачастую, технологические решения других банков остаются за зоной его внимания;
• Ограниченность ресурса разработчика зачастую становится камнем преткновения для осуществления программы комплексного развития банка. Наверняка Вы сталкивались с проблемой, когда разработчик говорит: «Мне не хватает ресурсов для ведения этой сверхсрочной разработки, скажите что отложить». При условии «грамотного» руководства получается очень забавная картинка, которую мне бы хотелось продемонстрировать следующим образом:
  Землекоп получает задание копать колодец в одном месте. Сделав несколько движений лопатой, он получает указание копать колодец в другом месте. Итеративно продолжая процесс, мы приходим к ситуации, когда вся поляна расковыряна лунками разного размера и глубины, причем воды нет ни в одной из них.

САБ отечественного разработчика

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

Поговорим более подробно о плюсах и минусах систем такого класса:

Плюсы:

• Отсутствие кадровых рисков для банка. Проблема разработчиков и обеспечения развития системы — проблема компании. Сопровождающая разработка определяется условиями договора и для банка безразлична;
• Высокая мобильность в области изменений внешней среды. Отечественный разработчик, как правило, контактирует с нормотворческими организациями (НБУ) очень плотно, поэтому о планируемых изменениях в нормативных документах узнает еще на этапе их разработки, что дает ему возможность адекватно изменять свою разработку;
• Невысокая совокупная стоимость владения;
• Как правило, неплохое качество сопровождения и небольшое время реакции на запросы со стороны банка.

Минусы:

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

САБ зарубежного разработчика

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

Поговорим более подробно о плюсах и минусах систем такого класса:

Плюсы:

• Отсутствие кадровых рисков для банка. Проблема разработчиков и обеспечения развития системы — проблема компании. Сопровождающая разработка определяется условиями договора и для банка безразлична;
• Высокая стабильность компании. Как правило, компании, выходящие на международный рынок — это компании, занимающие достаточно прочное положение в своей стране;
• Отсутствие проблемы ограниченности ресурса.

Минусы:

• Высокая начальная стоимость решения;
• Крайне низкая скорость реакции на изменения внешней среды;
• Зачастую отсутствие сопровождения на территории страны;
• Не всегда адекватная реакция на изменения. Зачастую Вы получаете в качестве доработки не совсем то, или совсем не то, что Вам требуется.

Предлагаемая схема экспресс оценки

Ну вот мы и добрались до самого интересного. Уровни, уровни, зачем все это нужно? А вот зачем!

Я достаточно долго мучился, пытаясь свести свое интуитивное понимание взаимоувязки САБ-банк к некоему достаточно строгому виду.

В результате мне попалась на глаза книга по квантово-экономическому анализу — КЭА (лихой термин, не правда ли?), написанная несомненно выходцами из Советского союза. И сразу все встало на свои места.

Разделим системы на уровни:

• САБ собственной разработки — Разработка уровня 1;
• САБ отечественной разработки — Разработка уровня 2;
• САБ зарубежной разработки — Разработка уровня 3.

Аналогично разделим на уровни и банки:

• Банк уровня 1 — небольшой банк;
• Банк уровня 2 — средний банк;
• Банк уровня 3 — крупный банк;

А после этого все достаточно легко укладывается в следующую таблицу, которую мы назовем таблицей допустимых состояний:

Что у нас получается?

В строгом соответствии с КЭА:

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

Аналогичную таблицу можно построить и для проведения экспресс-оценки выбора категории решения для филиалов многофилиального банка.

Вместо заключения. А что бы выбрал автор?

Это, пожалуй, самый интересный вопрос. Ответ на него сродни диагностике по телефону, но, тем не менее, можно попробовать, хотя и с некоторыми оговорками предложить некоторый рецепт, который должен сработать. Но сначала оговорки:

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

Итак, рассмотрим предлагаемую экспресс-методику оценки:

• Проводим анализ состояния и стратегии развития банка на период, который мы хотим обеспечить САБ;
• На основании данного анализа констатируем текущее состояние и конечное состояние банка, например: сейчас — «банк уровня 1», через 5 лет — «банк уровня 2»;
• На основании таблицы допустимых состояний определяемся с классом системы, которая будет максимально удовлетворять требованиям банка от текущего момента, до конца эксплуатации.
• Проводим процедуру выбора системы по методике, описанной ранее, уделяя особое внимание классу представленных систем.

Наверное, получилось не очень понятно, попробую продемонстрировать этот подход на примерах:

• «Банк уровня 1» без ожидаемой динамики. Если это вновь создаваемый банк — то это либо начало собственной разработки, при наличии соответствующих ресурсов, либо САБ отечественного разработчика, практически в минимальной комплектации и, возможно, с оплатой лицензий в рассрочку;
• «Банк уровня 1» — «Банк уровня 2». Выбор достаточно прозрачен — САБ отечественной разработки;
• «Банк уровня 1» — «Банк уровня 3». У Вас мания величия. Ваши амбиции непомерны — пройдите сначала шаг, описанный в п.2, а потом уже принимайте решения, поскольку к тому моменту Ваше видение ситуации изменится существенным образом;
• «Банк уровня 2» без ожидаемой динамики. Выбор достаточно прозрачен — САБ отечественной разработки;
• «Банк уровня 2» — «Банк уровня 3». Вот в этом случае потребуется дополнительно оценить уровень транснациональных амбиций Вашего банка. Если он достаточно высок — САБ зарубежной разработки, если нет — САБ отечественной разработки;
• «Банк уровня 3» без ожидаемой динамики. Сложный выбор, потому, что, с одной стороны, надо оценить степень уникальности функционала, и принимать решение «Покупать — Разрабатывать», с учетом этого фактора, затем уровень транснациональных амбиций Вашего банка. Если он достаточно высок — САБ зарубежной разработки, если нет — САБ отечественной разработки;

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

Теперь несколько слов о проблеме выбора САБ для многофилиального банка. Как уже было описано выше — в Вашем банке могут одновременно сосуществовать филиалы всех уровней. Как же поступить в данном случае?

Мне видятся два пути для решения данного вопроса. А критерием для выбора может служить Ваше видение того, насколько однородной Вы хотите видеть информационную структуру Вашего банка на уровне прикладной системы (САБ):

• Ставится требование получить однородное решение. В таком случае выбирается решение «САБ отечественной разработки». Это решение достаточно полно покроет область автоматизации рутинных операций (расчеты, касса и т.д.), но будет явно недостаточно для решения аналитических проблем центрального аппарата многофилиального банка. Для решения этих вопросов потребуется внедрение отдельной аналитической системы. Выбор аналитической системы — тема отдельного разговора, хотя эта процедура ничем не отличается от описанной в предыдущих статьях.
• Возможно также решение, при котором для автоматизации филиалов используется один тип САБ — «САБ отечественной разработки», а для автоматизации центрального офиса другой тип — как правило «САБ зарубежной разработки». Вполне работоспособный вариант. Несколько более тяжелое внедрение, но результат стоит того.

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

Удачи Вам в реализации проектов выбора и внедрения САБ, да и не только в них!