Просмотр исходного текста страницы Современная IТ-стратегия для динамичного банка — исполнение по заказу

[[:Категория:Владимир Рахтеенко (Статьи)|Владимир Рахтеенко]], генеральный директор ООО «Заказные ИнформСистемы».
* «Современная IТ-стратегия для динамичного банка — исполнение по заказу»<ref> «Банки и технологии», № 4-2003, стр. 32-36.</ref>

Заголовок статьи может удивить читателя, привыкшего к тому, что в течение последних лет ему настойчиво предлагают покупать тиражные разработки автоматизированных банковских систем (АБС), да и выбирать сейчас действительно есть из чего. Правда, выбор этот нелегок. Почитав рекламные материалы и поговорив с персоналом фирм-разработчиков, Вы заметите, что на первый взгляд все предлагаемые продукты очень похожи: все «идут от документа», все «работают в технологии клиент-сервер», практически все уже работают на промышленной СУБД и т. д. Да и предлагаемый набор банковских функций практически один и тот же: во всех системах есть все, что нужно, и даже больше того. Однако при более внимательном рассмотрении обнаруживается, что под терминами «клиент-сервер», «документы» и даже «технологии Oracle» понимаются достаточно разные вещи. При детальном изучении функционала, Вы нередко убеждаетесь, что предлагаемая система не полностью отвечает (или полностью не отвечает) потребностям Вашего банка. Естественно, встает вопрос о доработке продукта конкретно для Вас, и бойтесь тех, кто скажет, что это дешево.

В этой статье мы бы хотели представить иную стратегию автоматизации — заказную разработку банковской системы, обосновать ее жизненность и конкурентность по сравнению с традиционным подходом.

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

== Три причины для автоматизации ==

Анализируя ситуацию, мы пришли к выводу, что в настоящее время есть три причины, по которым предприятия-заказчики начинают проекты автоматизации.

* ''Первая'' — технологические трудности массового обслуживания клиентов. Конкурентная борьба на ритейл-рынке, предоставление массовых услуг с необходимым качеством и низкой себестоимостью вынуждают внедрять операционные системы, поддерживающие соответствующие бизнес-процессы. Как правило, внедрения информационных технологий (ИТ) в таких случаях доводятся до положительного результата, поскольку современный уровень ритейл-обслуживания на бумажных технологиях просто невозможен. Заказчиками автоматизации такого рода выступают розничные банки, крупные пенсионные фонды, страховые и биллинговые компании (от телекоммуникационных до ЖКХ).

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

* ''Вторая причина'' — потеря управляемости вследствие стремительного роста масштаба бизнеса. Если цель автоматизации в первом случае — обслуживание клиентов, то здесь — это обслуживание руководства, которое ощущает хронический недостаток необходимой информации. Такие внедрения проходят гораздо сложнее и нередко сопровождаются реинжинирингом бизнес-процессов, поскольку, как минимум, требуют постановки учета во всех подразделениях компании, причем учета не бухгалтерского, а управленческого, на основе которого руководство смогло бы оценивать ситуацию и принимать оперативно-тактические решения.

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

* ''Третья причина'' для внедрения нового проекта автоматизации встречается не столь часто: она обусловлена такой жесткой конкуренцией, которая вынуждает идти на структурные, качественные изменения в деятельности организации и интенсифицировать делопроизводство и бизнес на отдельных производственных участках. Цель такой направленной автоматизации — снизить риски, повысить качество, увеличить эффективность.

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

Решение, направленное на повышение управляемости или интенсификацию «узких мест» производственного процесса, должно быть интегрированным и вбирать все основные бизнес-процессы, которые составляют ноу-хау всякого крупного бизнеса. Именно тут будет полезна, а зачастую и просто необходима, заказная разработка ПО.

<graph>
digraph G{
 node [style=filled fillcolor=aliceblue fontsize=10 shape=note] 
 edge[color=blue dir=back]   
 root [label="Причины автоматизации" shape=invhouse fontsize=16 fillcolor=gold]
  root -> "Технологические трудности" -> "Массовое обслуживание" 
 root -> "Потеря управляемости" -> "Рост бизнеса" 
 root -> "Структурные\nизменения\nбизнеса" -> "Конкуренция" 
}
</graph>

== Почему именно заказная разработка? ==

Попробуем обосновать этот тезис. В растущих динамичных компаниях постоянно идут перемены. Это их качество, весьма полезное для развития основного бизнеса в конкурентной среде, губит традиционный подход к их автоматизации. Даже для описания бизнеса и составления технического задания на автоматизацию требуются месяцы, а иногда и годы. За это время картина настолько сильно меняется, что к моменту подписания ТЗ впору начинать создавать его новую версию. По оценкам<ref>Приводимым в обзорах журнала [http://knowhow.virtech.ru/asp/qa.asp?noparma=ziwk&gid=76.0  Journal of Defense Software Engineering]</ref> в больших проектах автоматизации на этапах проектирования и программирования объем дополнительных требований заказчика составляет от 2 до 10 % в месяц. Для отечественных компаний эта величина еще больше, поскольку динамика их развития в несколько раз выше. Соответственно, серьезная IТ-фирма должна обеспечивать адекватную динамику изменения своего продукта — информационной системы, включая программный код, проектную и пользовательскую документацию и т. п.

По существующим оценкам ресурсы, которые затрачиваются на IТ-проект, описываются '''показательной''' функцией от его размера (с основанием приблизительно равным 1,8). Это означает, что замах на систему вдвое большего масштаба потребует втрое больше ресурсов, а рост масштаба системы в три раза увеличит расходы в пять-шесть раз и т. п. (см. рисунок).

[[Image:Зависимость затрат от размеров IT-проекта (2003).gif|frame|Рисунок. Зависимость затрат от размеров IT-проекта]]

Зная эту динамику изменяемости затрат и обычные масштабы проектов автоматизации, не приходится удивляться тому, что даже на Западе более 90 % внедрений ERP-систем не укладываются ни в плановые сроки, ни в бюджеты. Для нашей динамичной бизнес-среды с неустоявшейся практикой ведения проектов это тем более справедливо.

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

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

''Гибкость и постоянная способность ПО к изменениям в сочетании с обозримой сложностью и невысокой стоимостью доработок — необходимые качества современных корпоративных IТ-проектов.''

== Особенности современной заказной разработки ==

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

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

Проанализировав реальные проекты внедрения и определив оптимальные масштабы корпоративного ПО, мы разработали банковскую систему нового класса — комплексную и в то же время вполне обозримую и изменяемую.

В ее основе — учетно-аналитическое ядро, которое содержит все основные таблицы (их менее 70) с описаниями типов данных и бизнес-процедур. Технология объектно-ориентированного программирования позволила заложить в основу системы такие механизмы, которые обеспечивают наращивание функционала без увеличения размерности системы. Новые типы данных и функции, то есть новые банковские продукты и услуги, описываются в виде метаданных и не требуют программирования, а внесение изменений в бизнес-процессы банка не требует перепрограммирования.

Это означает, что по требованию заказчика в системе можно быстро описать новые банковские продукты и бизнес-процессы для их обработки. Естественно, что в ее базовом варианте поддерживаются все наиболее стандартизированные банковские продукты и процессы. Коротко говоря, к базовому функционалу легко и быстро можно нарастить именно те ветви бизнес-процесса, которые нужны конкретному банку. А попутно интегрировать в единую информационную среду все ранее установленные компоненты автоматизации производства третьих фирм, работа которых банк удовлетворяет.

== Затраты на адаптацию ==

Многолетний опыт автоматизации банков показывает, что традиционные тиражные АБС и ERP-системы удовлетворяют запросы заказчика не более чем на <tt>70-80 %</tt>. Это в лучшем случае. Остальное дорабатывается в процессе внедрения. Заметьте, что трудоемкость таких доработок — это пятая (а то и третья) часть времени и усилий, которые были затрачены на разработку универсальной АБС, то есть десятки и сотни человеко-лет. Причем адаптация и изменение ПО остро требуется именно для уникальных бизнес-технологий в наиболее конкурентных подразделениях банка.

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

Сравним стоимость двух проектов доработки исходной банковской системы по требованию конкретного заказчика: в случае готовой АБС и при специализированной заказной разработке. Объективными показателями для оценки таких затрат выступают:

* объем программного кода исходной системы
* количество необходимых изменений в исходной системе

Оговоримся еще раз, мы рассматриваем проекты автоматизации в средних и крупных банках, цель которых — повышение управляемости и/или интенсификация деятельности в определенных областях бизнеса. В том и в другом случае требуется комплексное интегрированное решение, способное взаимодействовать с уже работающими в банке системами. А задачи управления, как и задачи интенсификации бизнеса, заведомо предполагают, что бизнес-решение будет индивидуальным и потребует столь же индивидуальной IТ-поддержки.

Что означает для заказчика переделка и адаптация <tt>20%-30%</tt> от большой и сложной ''универсальной'' банковской интегрированной системы, пронизанной внутренними связями? Удовлетворит ли его сложная и долгая настройка-подгонка сотен параметров, в результате которой он все равно останется с ''тиражным'' решением? Крупный банк, как правило, будет стараться реализовать в АБС свои наработанные бизнес-процессы и хорошо, если его требования не затронут базовых механизмов исходной системы. Иначе, настояв на своем, он рискует приобрести такую уникальную версию системы, которая вообще не будет способна к дальнейшему развитию.

В итоге процесс «натягивания» готовой АБС на банк оборачивается длительным согласованием требований (читай — борьбой) разработчика и клиента, поскольку интересы сторон находятся в явном противоречии. Банку нужен индивидуальный подход и фактически заказная разработка именно того функционала, который его не устраивает в исходном ПО. А разработчику нужно уложить требования банка в «прокрустово ложе» готовой универсальной АБС, чтобы минимизировать изменения в системе, не приспособленной к быстрому созданию новых ветвей бизнес-процесса.

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

Кстати, затраты на доработку и адаптацию зарубежных тиражных АБС еще выше, чем на отечественные.

Теперь оценим трудозатраты на заказную разработку-доработку на основе специализированного объектно-ориентированного ядра АБС. Как мы уже упоминали, трудозатраты на создание самого ядра оцениваются в человеко-месяцах или в ''единицах'' человеко-лет. Причем основные ресурсы вкладывались не в описание конкретных элементов бизнес-логики, а в ''инструментарий'' для быстрого описания произвольных технологических цепочек. Соответственно, создание полноценного модуля типа «Кредиты», «Ценные бумаги» или «Налоговый учет в соответствии с Главой 25 НК РФ» в такой системе занимает не годы, а недели, редко — месяцы. Совокупные расходы на создание ядра-прототипа и индивидуальной версии АБС для банка остаются в пределах десятков, но никак не сотен человеко-лет. Разница стоимости проекта на порядок — в пользу специализированной заказной разработки.

== Риски современных IТ-проектов ==

И последнее. Остановимся кратко на рисках проектов внедрения автоматизированных систем и их эксплуатации в банках. Фактически, говоря о темпах изменения требований в проектах, мы уже затронули эту тему. Риск зайти в процессе внедрении совсем не туда, куда намеревались, велик и для заказчика, и для разработчика. Чем масштабнее внедряемая система, тем дороже цена ошибки. Согласовав ТЗ, разработчик приступает к адаптации своей системы. И даже строгая дисциплина ведения проекта не спасет от того, что представленная через несколько месяцев версия утратит свою актуальность. Всем знакома ситуация, когда и система внедрена, и акты подписаны, а персонал банка с ней не работает.

Современная заказная разработка имеет гораздо меньше шансов зайти в тупик. Любой грамотный разработчик не возьмется за автоматизацию слабо формализованных процессов. Проведя обследование, он составит только предварительное описание проекта, которое будет уточняться и детализироваться в ходе исполнения. Отличие предлагаемого подхода в том, что наш специализированный инструментарий — объектно-ориентированное ядро системы позволяет быстро промоделировать новую функцию или бизнес-процесс. В зависимости от сложности и новизны задачи это займет от пяти часов до трех дней работы аналитика. На основе этой модели мы вместе с заказчиком уточняем ТЗ и создаем рабочую версию нового функционального блока. Эта версия, в свою очередь, может быть модифицирована в пределах двух дней.

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

Компания «Заказные ИнформСистемы» работает на рынке создания банковского и корпоративного ПО уже более 7 лет. Описанные в этой статье технологии заказной разработки успешно применяются нами в крупных проектах и наряду с дружным коллективом квалифицированных сотрудников составляют наше главное ноу-хау.

== Ссылки ==
<references />

[[Категория:Владимир Рахтеенко (Статьи)]]
[[Категория:Банковская автоматизация]]
[[Категория:Банки и технологии (Публикации)]]
[[Категория:2003 год (Статьи)]]

{{replicate-from-custiswiki-to-lib}}