Библиотека

Наши друзья

Менеджмент.com.ua .:. Интернет-портал для управленцев Consulting.ru Организация времени - тайм менеджмент и управление временем

О сайте

Проект “Vernikov.ru” — это библиотека, содержащая в себе уникальную и качественную подборку аналитических материалов по вопросам экономики, менеджмента и информационных технологий. Материалов в Интернете очень много. Мы не пытаемся опубликовать всё. Мы экономим Ваше время и публикуем только лучшее.

Помимо доступа к материалам, на сайте “Vernikov.ru” любой посетитель, столкнувшись с новыми и сложными задачами, может быстро и бесплатно получить консультацию у профессионалов.

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

Автор: Андрей Литовкин 09 Сентября 2009, 15:55

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Минусы:

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

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

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

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

Минусы:

Высокая начальная стоимость решения;

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

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

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

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

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

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

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

Защитный код
Обновить