7 тонн менеджмента
РусскийEnglishУкраїнська
Главная
Новости
Группа компаний
Продукты и услуги
Стоимость услуг
Семинары и тренинги
Партнерам
Библиотека
Карьера
Контакты

САБ. Готовое решение или собственная разработка?

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Плюсы:

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

Минусы:

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

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

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

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

Плюсы:

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

Минусы:

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

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

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

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

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

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

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

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

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

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


Разработка уровня 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» без ожидаемой динамики. Сложный выбор, потому, что, с одной стороны, надо оценить степень уникальности функционала, и принимать решение «Покупать — Разрабатывать», с учетом этого фактора, затем уровень транснациональных амбиций Вашего банка. Если он достаточно высок — САБ зарубежной разработки, если нет — САБ отечественной разработки;

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

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

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

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

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

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

Авторизация

Логин

Пароль

Зарегистрироваться

Забыли пароль?

Специальные предложения

Наши интернет-проекты

Наши клиенты

Вадим Морозов,
Коммерческий директор ООО Интерэлектрокомплект:

Высокая компетентность консультантов ГК «Верников и Партнеры», в области управления позволила нашей компании выйти на качественно более высокий уровень организации процессов планирования и избежать всех «подводных камней», которые могли проявиться в ходе столь сложного проекта.

Вверх
Rambler's Top100 Рейтинг@Mail.ru
Дизайн и программное обеспечение — ЭЛКОС (ELCOS)